ChanServ changed the topic of #yocto to: Welcome to the Yocto Project | Learn more: https://www.yoctoproject.org | Join us or Speak at Yocto Project Summit (2021.11) Nov 30 - Dec 2, more: https://yoctoproject.org/summit | Join the community: https://www.yoctoproject.org/community | IRC logs available at https://www.yoctoproject.org/irc/ | Having difficulty on the list or with someone on the list, contact YP community mgr ndec
dev1990__ has quit [Quit: Konversation terminated!]
Guma has joined #yocto
<Guma> Hello Everyone. I am fairly new to Yocto. I have yocto project "DISTRO_VERSION = "2.0.3". I was able to build and flush my dev board. Board boots fine. After SDK was generated I installed it to /opt/apq8053-sdk/. Next I sourced in environment-setup-armv7a-vfp-neon-oe-linux-gnueabi. Now I have my cmake external project that I am trying to cross compile. Now when I try to run "cmake -DCMAKE_TOOLCHAIN_FILE=${OE_CMAKE_TOOLCHAIN_FILE} .."
<Guma> from my project build/ folder I get error. Quick check of env variables is that OE_CMAKE_TOOLCHAIN_FILE is not defined. I also looked at "/opt/apq8053-sdk/sysroots/x86_64-oesdk-linux/usr/share" and I do not see cmake/ folder with expected OEToolchai
<Guma> nConfig.cmake
<Guma> I also googled around and found this "There seems to be a bug in the imminent Yocto Project 2.5, Sumo, release. Here, sysroots/x86_64-chargestorm-linux/usr/share/cmake/OEToolchainConfig.cmake seems to be omitted."
<Guma> I am on older version then 2.5
<Guma> A temporary solution suggested was to add TOOLCHAIN_HOST_TASK += "nativesdk-cmake-dev"
<Guma> Is this correct suggestion? If so where do I add this line?
<Guma> I this proper place to add "meta/classes/populate_sdk_base.bbclass"
Vonter has quit [Ping timeout: 256 seconds]
Vonter has joined #yocto
gioyik has quit [Remote host closed the connection]
gioyik has joined #yocto
<moto-timo> 2.0.3 was released January of 2016. 5 years ago. please get your vendor to update
<moto-timo> ^6 years ago
<Guma> moto-timo I will try but for now I like to get this going. Any help is welcomed...
goliath has joined #yocto
Guma has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Guma has joined #yocto
camus has joined #yocto
camus1 has joined #yocto
camus has quit [Ping timeout: 240 seconds]
camus1 is now known as camus
Guma has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Guma has joined #yocto
sakoman has quit [Quit: Leaving.]
stephano[away] is now known as stephano
stephano has quit [Quit: Textual IRC Client: www.textualapp.com]
vd has quit [Quit: Client closed]
vd81 has joined #yocto
vivien1 has joined #yocto
vivien1 has quit [Client Quit]
camus has quit [Ping timeout: 256 seconds]
camus has joined #yocto
Guma has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
gioyik has quit [Remote host closed the connection]
gioyik has joined #yocto
amitk has joined #yocto
Ad0 has quit [Ping timeout: 268 seconds]
xmn has quit [Ping timeout: 240 seconds]
Vonter has quit [Ping timeout: 256 seconds]
thekappe has quit [Ping timeout: 252 seconds]
Vonter has joined #yocto
vd81 has quit [Quit: Client closed]
vivien1 has joined #yocto
vivien1 has quit [Client Quit]
vd has joined #yocto
mariusz1 has joined #yocto
alessioigor has joined #yocto
alessioigor has quit [Client Quit]
ziga has joined #yocto
zpfvo has joined #yocto
ziga has quit [Quit: Leaving]
ziga has joined #yocto
manuel1985 has quit [Ping timeout: 240 seconds]
lucaceresoli has joined #yocto
gioyik has quit [Quit: WeeChat 3.3]
alessioigor has joined #yocto
alessioigor has quit [Client Quit]
zpfvo has quit [Ping timeout: 240 seconds]
zpfvo has joined #yocto
Vonter has quit [Ping timeout: 256 seconds]
zpfvo has quit [Ping timeout: 240 seconds]
zpfvo has joined #yocto
Saur[m] has quit [Quit: You have been kicked for being idle]
mvlad has joined #yocto
zpfvo has quit [Ping timeout: 256 seconds]
zpfvo has joined #yocto
florian has joined #yocto
<ziga> I added this recipe to the image https://github.com/meta-qt5/meta-qt5/blob/master/recipes-qt/qwt/qwt-qt5_6.1.5.bb but I can't see the /usr/lib/libqwt-qt5.so being installed on the target? Where can I see at which location these libraries are installed?
<ziga> I already found out that it was installed as /usr/lib/libqwt.so
leon-anavi has joined #yocto
<qschulz> ziga: oe-pkgdata-util find-path '*libqwt*'
<qschulz> this will return the package (if built) in which the file is available, you install the package in your image and you should be good to go
<ziga> Very useful! I will use this!
<ziga> I was toggling to the target and using ldconfig -p | less up untill now...
j7lc8l[m] has joined #yocto
<coldspark29[m]> qschulz: Any idea how to use kas in combination with pyrex?
<qschulz> coldspark29[m]: use kas checkout, then pyrex to debug your stuff I'd say?
camus has quit [Read error: Connection reset by peer]
<coldspark29[m]> Ah guess you just use kas to checkout
camus has joined #yocto
<coldspark29[m]> Yeah I could have thought of that myself actually. My first impulse is always asking someone else and while I hit the send button, I answer my own question ^^
<hmw[m]> Hi,
<hmw[m]> i'm trying to add KF5ModemManagerQt to a cmake project using a yocto sdk ( where the package is inlcude) but im getting build issues
<hmw[m]> fatal error: modemsignal.h: No such file or directory
mariusz1 has quit [Ping timeout: 240 seconds]
<qschulz> coldspark29[m]: glad to have play the role of rubber duck :)
<qschulz> hmw[m]: wild guess but your cmake project does nto use the CFLAGS/CXXFLAGS/LDFLAGS correctly
<qschulz> i.e. usually overridden directly in the CmakeLists.txt
<coldspark29[m]> qschulz: Interesting that there even is a term for it ^^
<hmw[m]> <qschulz> "i.e. usually overridden directly..." <- how do i fix it ?
<hmw[m]> i excluded all CMAKE_C_FLAGS CMAKE_CXX_FLAGS CMAKE_LDFLAGS_FLAGS
florian has quit [Remote host closed the connection]
camus1 has joined #yocto
camus has quit [Remote host closed the connection]
camus1 is now known as camus
<kanavin_> RP: sorry for pushy language, I should've toned it down
<kanavin_> RP: the more I look at it, the more it seems like universe is best way out for repro tests
<kanavin_> this whole virtual/ and alternatives thing has grown organically over the years, and needs to be somehow redesigned i'd say
<coldspark29[m]> Any idea how insert linebreaks in the generated local.conf with kas?
<coldspark29[m]> * insert linebreaks for comments in the
<RP> kanavin_: universe isn't the right thing and there is a "design" kind of there, it just isn't well documented. I'll reply in a bit, basically I think we need to ensure the virtual/XXX or the recipes are all used somewhere in core and if they aren't, it suggests a different problem
<RP> we should probably test that somehow
<kanavin_> RP: but go-runtime is used, it just isn't packaged - we need to ensure the latter bit
<dacav> Hi. I've got here a 3rd party bsp layer (from xilinx) that fails to apply a patch to qemu. The patch is named '0010-configure-Add-pkg-config-handling-for-libgcrypt.patch'. Is this familiar to anyone?
<rburton> JPEW: ha wow
<kanavin_> dacav, you need to ask xilinx perhaps?
<qschulz> coldspark29[m]: we don't have enough info or context. In any case, I think it's just YAML syntax so just go with that and look for answers specific to YAML
<coldspark29[m]> Yeah, I am just looking into that but can't find it. What i basically want is to write explanatory comments like int he original local.conf created by Yocto
<dacav> kanavin_: yes. That would be a route. Just wondering if someone saw such a problem here.
<qschulz> coldspark29[m]: multiline string is usually started with the | character IIRC
<dacav> Interestingly, the same patch is also applied by poky
<coldspark29[m]> qschulz: Yes, but only for everything that follow the comment
<coldspark29[m]> I am trying something like this... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/bfafb660bd73d5c2770236e8f7b3306cbd50537d)
<RP> kanavin_: if it is used somewhere, it should get packaged in world builds :/
<kanavin_> RP: and yet it doesn't, and that's the original problem that got me so agitated ;)
<qschulz> coldspark29[m]: did you try a scalar with a # comment in it? does it make it to the local.conf?
dev1990 has joined #yocto
<kanavin_> it only gets packaged if you build it directly, or if you build an image that includes something that depends on it
<kanavin_> RP: to reproduce, 'bitbake go-helloworld', inspect tmp/deploy/rpm
<kanavin_> go-helloworld rpms will be there, but go-runtime rpms will not
<RP> kanavin_: does helloworld actually need go-runtime ?
<kanavin_> RP: just building to confirm
<RP> kanavin_: I see go.bbclass only has a DEPENDS, not an RDEPENDS
<RP> kanavin_: go-target and packagegroup-go-sdk-target should be the things which trigger the rpms to get built
<kanavin_> RP: yes, go-helloworld does actually have go-runtime in .spec
<kanavin_> but the rpm is not there :-/
<coldspark29[m]> qschulz: No a # does not land in the local.conf
<RP> kanavin_: there isn't anything telling bitbake it may be a runtime dependency :/
<RP> kanavin_: I suspect the dependency comes in as part of an image
d0ku has joined #yocto
<kanavin_> RP: yes, and as we don't have images with go-helloworld in repro tests, and rely on 'world' to sweep up everything, go-runtime ends up not being tested
<kanavin_> and possibly others
<hmw[m]> <qschulz> "hmw: wild guess but your cmake..." <- i needed to change:
<hmw[m]> target_link_libraries(xtest Qt5::Core Qt5::DBus KF5::ModemManagerQt )
<hmw[m]> find_package(Qt${QT_VERSION_MAJOR} COMPONENTS Widgets DBus Xml REQUIRED)
<kanavin_> RP: that's why I proposed lifting those exclusions in world
<RP> kanavin_: I'm more worried about why the packagegroup and compiler don't pull it in
<RP> kanavin_: the fact the rpm's don't get built does suggest there is a bit of a dependency glitch somewhere though :/
<coldspark29[m]> @qschulz Oh yes a scalar works. Didn't know what it is
<coldspark29[m]> Thanks :)
<RP> kanavin_: I see you're running builds. I'd just warn the ab isn't at full strength and has a lot of new workers and "new" issues with them :/
<kanavin_> RP: right, I guess I'll let this one run through, but not start any new ones until halstead declares completion.
<RP> kanavin_: I think it will be for me to get things working at this point :/
<kanavin_> RP: sorry, do you mean fixing rdepends or should I cancel the ongoing a-full?
<RP> kanavin_: His side looks to be mostly done but there are a few issues the new systems are highlighting
<kanavin_> I just built 'go' and go-runtime isn't there :-/ there's a serious issue there it seems
<RP> kanavin_: the a-full is ok, I just wanted to warn it may see some interesting failures
<RP> kanavin_: I do have a large queue in -next too which may overlap with some of yours
<kanavin_> RP: only the go repro bits, the rest are manual (e.g. not from auh) package updates that weren't yet done by others
<kanavin_> new systemd for example, which would benefit from a-full
<RP> kanavin_: ok, fair enough
<RP> a number of the patches in -next have issues :(
<kanavin_> RP: yes, coming from me they wouldn't :) but it's also good to encourage others to send updates :-/
<RP> kanavin_: I know, I tend to try and let others add them where possible though ;-)
<RP> kanavin_: I think adding do_build[rdeptask] += "do_package_write_rpm" to package_rpm.bbclass does what we want
<RP> ipk/deb will need similar
<kanavin_> RP: yes, I was just looking at what that fateful do_build change actually contained
<kanavin_> it dropped do_build[credeptask] += "do_package_write_rpm"
mariusz1 has joined #yocto
<kanavin_> or do you mean adding do_package_write_rpm[recrdeptask] += "do_package_write_rpm" ?
<kanavin_> otherwise that change would be effectively reverted, no?
<RP> kanavin_: I'm suggesting rdeptask instead of recrdeptask
<kanavin_> aah
<RP> it is a compromise but should be much less overhead
<kanavin_> my bitbake-fu isn't that good - maybe it's a good thing that over the years I haven't had to learn much about those things, as that means it 'just works' almost all of the time ;)
<kanavin_> I need to look up rdeptask vs recrdeptask now
<RP> kanavin_: one is recursive, one isn't
<RP> kanavin_: and yes, it is nice in many ways people haven't needed to care :)
<kanavin_> RP: the downside is the bus factor is close to 1 :(
<RP> kanavin_: yes :(
Vonter has joined #yocto
<RP> kanavin_: I've queued a build with the rdeptask change in, we'll see
<kanavin_> RP: cheers :)
<coldspark29[m]> How can I checkout a certain branch like gatesgarth with kas?
<coldspark29[m]> Putting it in refspec didnt't work and I can't find anything on it in the documentation
<qschulz> coldspark29[m]: give the commit hash
<qschulz> +it
<coldspark29[m]> Ah okay, this seems a bit bad for the overview though
<coldspark29[m]> Would be nice to specify the branch
<coldspark29[m]> * the branch by name, but well
<qschulz> I disagree
<qschulz> you want reproducibility
<qschulz> using a branch will not guarantee that
<coldspark29[m]> True
<qschulz> it might work somehow but I don't think it's a good idea anyway
<coldspark29[m]> We are currently using repo and it specifies the branch. I thought that this was intended somehow
<RP> kanavin_: your build has some fun with the mdadm upgrade and udev :/
<coldspark29[m]> I like kas much better than repo though :)
camus has quit [Ping timeout: 256 seconds]
camus has joined #yocto
d0ku has quit [Ping timeout: 240 seconds]
camus1 has joined #yocto
camus has quit [Read error: Connection reset by peer]
camus1 is now known as camus
<ziga> I managed to build my application with "bitbake application" and it was compiled as "tmp/work/cortexa8hf-neon-poky-linux-gnueabi/application/1.0-r0/application-1.0/fotovolt_gui". But when I include it in my image with "IMAGE_INSTALL += "application" I can't find it on the target. Any idea?
<ziga> I edited the recipes with "devtool edit-recipe application" and "devtool edit-recipe image".
<qschulz> ziga: oe-pkgdata-util list-pkg-files application
<qschulz> it'll show the files that the package you install contains
<coldspark29[m]> @schulz: Any idea how to use environment variables in a yaml script for kas? I need to expand one for the url of a repository
<qschulz> I assume you forgot to have an install target in your cmake or a proper do_install (the former is better)
<coldspark29[m]> s/schulz/qschulz/
<qschulz> coldspark29[m]: there's autocompletion usually in your IRC/matrix client so you don't have to type it by hand :)
<qschulz> coldspark29[m]: no I don't know, you could always do a small sed before running kas though
<coldspark29[m]> True
<ziga> Okay! I will take a look at that and report back if I can't solve!
<ziga> Thank you!
<coldspark29[m]> There should be support for it in kas though
<coldspark29[m]> I actually can't believe it isn't ^^
<ziga> @qschulz I used "oe-pkgdata-util list-pkg-files application" and it returned an empty list. Probably I really have to do what you said.
<coldspark29[m]> Seems like yaml doesn't support environment variables though.
<qschulz> ziga: add an install target in your cmake :)
<ziga> I use qmake... :/
<ziga> What now?
<qschulz> ziga: propbably possible too, look at other qmake recipes
<ziga> Ok. I have to dive a bbit. Thanky again!
<coldspark29[m]> Time of a github issue! ☝️
<coldspark29[m]> s/of/for/
<qschulz> coldspark29[m]: provide a usecase too so it's easier to convince people to work on it
<qschulz> BTW, weren't you supposed to send a patch? I don't remember :p
<qschulz> Ah yes, the EDITOR stuff
<qschulz> but that was for pyrex :)
<coldspark29[m]> qschulz: JPEW is not in favor of the idea. He said he hasn't come up with a good solution yet.
<coldspark29[m]> He wants to implement it in general, but said our idea would create problems. I don't really see why, but well
<coldspark29[m]> s/in general/somehow/
<rburton> kanavin_: re your toolchain question, i've been meaning to switch meta-arm to use multiconfig for the machines where you have a 64-bit primary core but a 32-bit A or M core on the side, instead of using those binary compilers.
<coldspark29[m]> > <@qschulz:libera.chat> BTW, weren't you supposed to send a patch? I don't remember :p
<coldspark29[m]> * JPEW is not in favor of the idea. He said he hasn't come up with a good solution yet.
<qschulz> coldspark29[m]: ah I see you opened an issue on Github, missed that one :)
<qschulz> coldspark29[m]: would have been great to have the discussion on the github issue :)
<qschulz> I might send a patch to "force" him to answer on the github issue/PR so that we have a trace somewhere :)
<coldspark29[m]> qschulz: Yeah, IRC is volatile
<qschulz> or if you have the logs of the discussion, it'd be great to add it to the issue
<coldspark29[m]> We discussed it here
<qschulz> coldspark29[m]: we have logs though
Vonter has quit [Ping timeout: 240 seconds]
<qschulz> so just need to get the date at which this discussion happened and we'll find the logs :)
<coldspark29[m]> qschulz: Can't find the logs in Matrix. No idea why
<coldspark29[m]> He said I could build my own docker image for Pyrex https://github.com/garmin/pyrex/blob/master/DEVELOPING.md#building-images-locally
<coldspark29[m]> I am too lazy though
<coldspark29[m]> devtool edit-recipe is not important enough to go through all of that hassle
Vonter has joined #yocto
<coldspark29[m]> I guess I can try editing the dockerfile
<coldspark29[m]> Prove my point and make a PR
sherbrechtsmeier has joined #yocto
sherbrechtsmeier has quit [Client Quit]
<hmw[m]> hi i'm planning to convertet a project from qmake to cmake can a bb file support both ??
<qschulz> hmw[m]: both at the same time wouldn't make much sense, but yes, qmake and cmake based projects are supportde
<hmw[m]> <qschulz> "hmw: both at the same time..." <- i meen that i don´t like changing it back and forward when i need to build a "old" application
<qschulz> hmw[m]: have two recipes then, with the same name but a different version and put DEFAULT_PREFERENCE = "-1" in the old one
<qschulz> then you just need to select the reciep to build in your loca.conf with PREFERRED_VERSION_application = "<old_version<"
<qschulz> if you don't do anything, then the newer version will be built
<qschulz> it;s likely possible to have both qmake and cmake but i'm not sure it's worth the headaches it can potentially produce :)
akiCA has joined #yocto
<JPEW> coldspark29[m]: GitHub issue is fine :)
<coldspark29[m]> Hmm I just tried adding all the requiered editors in the Dockerfile and also set an `alias vi="vim"`, but it still doesn't find vi
akiCA has quit [Quit: Leaving]
<kanavin_> rburton, right, but this is for the 32 bit primary core to host a compiler for the rtos core
<rburton> oh you want an on-target compiler?
tgamblin_ has quit [Quit: Leaving]
tgamblin has joined #yocto
<coldspark29[m]> <JPEW> "coldspark29: GitHub issue is..." <- Thanks, which container would be the one running devootl. I just tried adding them in the Alpine container which is probably wrong.
<coldspark29[m]> s/devootl./devtool?/
<coldspark29[m]> s/devootl./devtool?/, s/them/Vim/
akiCA has joined #yocto
Vonter has quit [Ping timeout: 256 seconds]
cperon has quit [Ping timeout: 240 seconds]
suy|m has quit [Ping timeout: 240 seconds]
glembo[m] has quit [Ping timeout: 240 seconds]
jaskij[m] has quit [Ping timeout: 240 seconds]
expert[m] has quit [Ping timeout: 240 seconds]
Emantor[m] has quit [Ping timeout: 240 seconds]
j7lc8l[m] has quit [Ping timeout: 240 seconds]
T_UNIX[m] has quit [Ping timeout: 240 seconds]
codavi has joined #yocto
akiCA has quit [Ping timeout: 256 seconds]
lukma has quit [Ping timeout: 256 seconds]
lukma has joined #yocto
<coldspark29[m]> Hmm I tried adding vi to all Ubuntu image, but it still doesn't work. No idea...
Vonter has joined #yocto
<JPEW> coldspark29[m]: Not sure what you mean, Pyrex doesn't have an alpine container?
<JPEW> qschulz, coldspark29[m]: Also: https://github.com/garmin/pyrex/issues/72
<qschulz> JPEW: yeah I saw :)
<coldspark29[m]> Its in images/Dockerfile
<JPEW> coldspark29[m]: We compile a few utilites from source to include in the images
<coldspark29[m]> But it's Alpine ...
<JPEW> coldspark29[m]: Right, so we use Alpine, but that image isn't included in the final (it's a multi-stage build)
<JPEW> You want one of the images that ends in -base
<JPEW> coldspark29[m]: Sorry, you want the image that is `FROM ${PYREX_BASE} as pyrex-base`
<JPEW> line ~620 or so
jaskij[m] has joined #yocto
expert[m] has joined #yocto
glembo[m] has joined #yocto
cperon has joined #yocto
suy|m has joined #yocto
<kanavin_> rburton, yes
<kanavin_> rburton, or rather the customer
<kanavin_> they want to compile on cortex-a linux for cortex-m rtos
<kanavin_> and cortex-a is 32 bit, to make it extra fun
Emantor[m] has joined #yocto
T_UNIX[m] has joined #yocto
<rburton> you'd hope it wouldn't be impossible to make a custom gcc recipe that mostly included the standard recipes but changed the target to arm-m
j7lc8l[m] has joined #yocto
sakoman has joined #yocto
<kanavin_> rburton, only if I could land it in oe-core, which I doubt
<kanavin_> otherwise you need to copy everything into a private layer, and tweak, creating a recipe fork
xmn has joined #yocto
<rburton> if customer is happy with using the standard gcc, i'd ask khem about how to do that
<kanavin_> they are, I'm just not sure how to do it without a mass-copy-tweak
<rburton> require gcc_11.2.bb
<rburton> and
<rburton> erm
<rburton> <handwavy>
<rburton> yeah. might need a bit of abstraction in the recipe
<rburton> would they be happy with clang :)
<kanavin_> there needs to be a way to specify the canadian target somehow
<kanavin_> without hardcoding it, and with being able to have several canadian targets somehow
<kanavin_> and no copy-tweaking ;)
<RP> kanavin_: I still think some wrappers setting the no compiler libs flags might work ;-)
<rburton> looks like a gcc for arm-a can't build for arm-m though
camus1 has joined #yocto
<RP> rburton: really? :(
<rburton> assuming i'm remembering right and kanavin wanted a -m target
<rburton> if its all A then yeah, nostdlib ftw!
<rburton> we have a side plan of removing use of the binary compilers in meta-arm
<rburton> as they're ick
camus has quit [Read error: Connection reset by peer]
camus1 is now known as camus
<kanavin_> the customer says "for an arbitrary arm micro-controller"
<rburton> they really should specify A or M
<rburton> as they really should know, and it makes a differene
TundraMan is now known as marka
Vonter has quit [Ping timeout: 256 seconds]
* RP wonders how long before kanavin_ notices his Pending patch additions
<coldspark29[m]> Does anyone else work with Freescale here?
mariusz1 has quit [Ping timeout: 256 seconds]
sherbrechtsmeier has joined #yocto
Guest225 has quit [Quit: Ping timeout (120 seconds)]
<qschulz> coldspark29[m]: ask your question, otherwise people usually don't answer to open questions like that ;)
<vmeson> coldspark29[m]: Many people use freescale boards. Maybe more people would respond if you were to ask a more specific question.
<vmeson> qschulz: right.
florian has joined #yocto
<coldspark29[m]> qschulz: Well Freescale uses a setup script
<coldspark29[m]> which basically sets up the build directory. It overwrite all configurations I have made with kas and without it, it doesn't work. So I am wondering if Freescale relies on repo and this script, whether I should go with kas at all
<rburton> fwiw, there's likely no real reason to use their setup script if you want to use kas
<coldspark29[m]> I mean I could just do all the modifications from the script myself somehow, but it doesn't seem reasonable to duplicate efforts. Also, if Freescale does update their repo one day, I would have to do it all over
<coldspark29[m]> rburton: Yeah, I am just not seeing the advantage of kas yet
Vonter has joined #yocto
<coldspark29[m]> It seems like a cleaner solution than repo, but if I have to rewrite the script, it might just get too much work.
<rburton> just use oe-init-build-env from oe-core
Vonter has quit [Ping timeout: 240 seconds]
<coldspark29[m]> Ah seems like I just had a typo and the bblayers.conf was faulty
<coldspark29[m]> It does compile now
<qschulz> coldspark29[m]: meh, you probbaly don't need any of this stuff, just include the layers this script is adding to your kas.yaml file and add the ACCEPT_FSL_EULA variable to your local.conf (though.. one is not supposed to automate that, hence probably the script)
<coldspark29[m]> Although it shows me an error when I clone the first time
<coldspark29[m]> `2022-01-04 16:19:38 - ERROR - Total 321 (delta 134), reused 318 (delta 134)`
<qschulz> coldspark29[m]: that's not enough info unfortunately for us to be able to help you
Vonter has joined #yocto
<coldspark29[m]> It is our own repository on Gerrit that I am cloning via ssh. It shows an error, but everything works afterwards.
<coldspark29[m]> s/repository/meta-layer/
sherbrechtsmeier has quit [Quit: Client closed]
Tokamak has joined #yocto
<coldspark29[m]> If I take it out of the cloning list, there is no error. All other layers come from Github or Gitlab. I think Gerrit and ssh is just not well supported or there is an issue with our Repo.
<coldspark29[m]> qschulz: Is there a way to let kas setup Pyrex as well?
<coldspark29[m]> When I I let it checkout pyrex, it complains that there is no layer.conf inside, because it is technically not a layser I guess
<qschulz> kas is for production, pyrex for dev
<qschulz> so just clone and setup pyrex manually
nodeboy[m] has quit [Quit: You have been kicked for being idle]
<qschulz> you're trying to have kas do the same thing as repo but that's not really what it's for?
nodeboy[m] has joined #yocto
nodeboy[m] has left #yocto [#yocto]
olani has joined #yocto
florian has quit [Ping timeout: 256 seconds]
TundraMan has joined #yocto
marka has quit [Ping timeout: 240 seconds]
florian has joined #yocto
Tokamak has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
TundraMan is now known as marka
Tokamak has joined #yocto
camaronut has joined #yocto
<camaronut> Hi all, happy new year!
<camaronut> RP: back on the 29th, you had sent me a tip regarding a fix on master with rpmbuild and XZ_TRHEADS.  It turns out dunfell already has that patch, it looks like it was cherry picked.  https://git.yoctoproject.org/poky/commit/?id=2691f9aa0d9e4ee8faec5b5fc35a136fbecc8fac.
<camaronut> Since then I've added more debugging output to rpmbuild.  It turns out the SSL package is occasionally getting no files added to it's linked list of things to do, so it's effectively trying to create an empty cpio archive inside the RPM, which is only caught when it attempts to close out the cpio by writing a trailer.
<RP> rburton: what was the cause of the cpio thing you were seeing?
<RP> rburton: camaronut was seeing it with dunfell
<rburton> hm
<RP> camaronut: it seems strange that a zero length list of files would do that, sounds like a bug :/
<RP> camaronut: did you find a fix?
<RP> rburton: it may be you just worked around it?
<rburton> my problem was was insane parallism causing fork() to fail
<rburton> i just reduced XZ_THREADS a lot
<rburton> oh and ZSTD_THREADS too
<rburton> as some rpms use zstd instead
<rburton> on my machine, there are 256 'cores', BB_NUMBER_THREADS and PARALLEL_MAKE is set to 32, but ZSTD_ and XZ_THREADS is 8
<RP> rburton: dunfell wouldn't be using zstd though
<rburton> true
<RP> rburton: perhaps it is a different issue, just sounded similar
<camaronut> RP: not yet.  I got stalled up trying to understand the linked list they're using to add files.  The debug I had was in the while() loop that added files to the cpio.  That while loop is never entered.
<qschulz> also, if built within a container, you have a few other settings to set right? like max number of pids and mount a tmpfs in /tmp for some reason
<qschulz> but eh, that's all I can bring to the discussion :p
Tokamak has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<rburton> mine was obvious as the package log was full of permission denied errors
<camaronut> qschulz: we are using a docker container...
<RP> camaronut: might be worth a look at that code upstream, see if any fixes were made
<camaronut> 72 thread machine
<camaronut> RP: Yup.  Upstream reimplemented the OpenMP changes that were proposed for building the packages.
<camaronut> RP: I'll look some more.
<qschulz> camaronut: pids_limit = 1000000 in containers.conf (for podman)
<qschulz> + --tmpfs /tmp for podman run too
<qschulz> that was what was needed for us to make it work
<camaronut> qschulz: thanks for the tip!  I'll take a look at those for our setup.
florian has quit [Ping timeout: 256 seconds]
argonautx has joined #yocto
locutusofborg_ is now known as locutusofborg
locutusofborg has quit [Changing host]
locutusofborg has joined #yocto
locutusofborg is now known as LocutusOfBorg
Guma has joined #yocto
camus has quit [Ping timeout: 240 seconds]
camus has joined #yocto
Guma__ has joined #yocto
Guma has quit [Ping timeout: 256 seconds]
Guma__ is now known as Guma_
Guma_ has quit [Client Quit]
Guma has joined #yocto
Guma has quit [Client Quit]
zpfvo has quit [Remote host closed the connection]
Guma has joined #yocto
<codavi> Is there any specific reason why 'SECURITY_CFLAGS' variable (-D_FORTIFY_SOURCE=2 -Wformat etc) gets added to 'CC' rather than 'CFLAGS' ? Readily noticeable in SDK environment-setup file.
<codavi> This makes it hard to make a debug build for apps but Poky/SDK itself is built regularly (not debug) without doing something to remove security flags from 'CC'
Tokamak has joined #yocto
tlhonmey has joined #yocto
goliath has quit [Quit: SIGSEGV]
leon-anavi has quit [Quit: Leaving]
d0ku has joined #yocto
Guma has quit [Quit: Textual IRC Client: www.textualapp.com]
Guma has joined #yocto
Tokamak has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Guma has quit [Client Quit]
Guma has joined #yocto
Guma has quit [Client Quit]
Guma has joined #yocto
Guma has quit [Client Quit]
tlhonmey has quit [Quit: Client closed]
Vonter has quit [Ping timeout: 256 seconds]
tlhonmey has joined #yocto
Guma has joined #yocto
Guma__ has joined #yocto
Guma has quit [Ping timeout: 256 seconds]
Vonter has joined #yocto
Tokamak has joined #yocto
goliath has joined #yocto
Guma__ is now known as Guma
amitk has quit [Ping timeout: 240 seconds]
amitk has joined #yocto
amitk has quit [Ping timeout: 256 seconds]
amitk has joined #yocto
florian has joined #yocto
florian has quit [Ping timeout: 240 seconds]
d0ku has quit [Ping timeout: 256 seconds]
d0ku has joined #yocto
Vonter has quit [Ping timeout: 240 seconds]
amitk_ has joined #yocto
amitk has quit [Ping timeout: 240 seconds]
d0ku has quit [Ping timeout: 256 seconds]
risca has joined #yocto
amitk_ has quit [Ping timeout: 240 seconds]
Guma has quit [Quit: Good Night Everyone...]
florian has joined #yocto
ziga has quit [Quit: Leaving]
ziga has joined #yocto
<kanavin_> RP: I noticed immediately, but didn't have the heart (or guts) to tell you off :) besides, webkit ignored all of my submissions so far, or maybe I'm using the wrong channel somehow
<kanavin_> at least openssl should be fairly simple
<JPEW> kanavin_: Did you go though WebKit bugzilla?
<kanavin_> JPEW, I think so - you can check the links in the patches I submitted
<kanavin_> there's a script that creates bugzilla tickets from the command line and attaches the patch from what I remember
<JPEW> kanavin_: Ya, thats what I did
mvlad has quit [Remote host closed the connection]
yates has joined #yocto
<yates> is there a way to generate a call graph (dependency graph) for an application built within yocto?
<rburton> nothing yocto specific
<rburton> assuming you mean at the binary level, and not package management level
<yates> yes, at the binary level. anything non-yocto specific?
<yates> (read: anything, anywhere, that can do this?)
<yates> i was looking at sourcetrail and lucidchart
<yates> how are you, rburton? Happy New Year
<RP> kanavin_: the webkit one needs someone with ruby knowledge. I'm sure I could figure it out but there are other more pressing issues
<RP> kanavin_: I was just wondering if you'd say anything :)
chep` has joined #yocto
chep has quit [Read error: Connection reset by peer]
chep` is now known as chep
ziga has quit [Ping timeout: 240 seconds]
mrpelotazo has quit [Read error: Connection reset by peer]
<camaronut> RP: I looked through the upstream rpm git logs.  There's a few changes that mention they fix data races, but the patches would not apply cleanly to what Dunfell currently has.  I just forklifted rpm 4.16.1.3.bb (and files) from hardknott and ran my repro script.  So far I've repackaged openssl 11 times and it's fine.  I'll continue to run the
<camaronut> script overnight and report back the results.
goliath has quit [Quit: SIGSEGV]
mrpelotazo has joined #yocto
<RP> camaronut: thanks for the info. sakoman might fine it interesting too
<jonmason> Not sure if there is a job board, but here is one from a recruiter that hit me up earlier today. https://jobs.sleepnumber.com/job/san-jose/sr-embedded-software-engineer/1020/8443966496
<jonmason> Honestly, I'm concerned why a bed would even need YP
<fray> Sleep number has a lot of IoT in their controllers now
<jonmason> I can be paranoid
lucaceresoli has quit [Ping timeout: 256 seconds]
florian_kc has joined #yocto
florian has quit [Ping timeout: 240 seconds]
Vonter has joined #yocto
Vonter has quit [Ping timeout: 240 seconds]
goliath has joined #yocto
<tlhonmey> jonmason:  Because obviously you need to be able to adjust the firmness of your bed from your smartphone.  What other way would there be to do it?
florian_kc has quit [Ping timeout: 240 seconds]
<RP> jonmason, rburton: https://autobuilder.yoctoproject.org/typhoon/#/builders/113/builds/1880/steps/13/logs/stdio - was this master-next, the autobuilder or something in meta-arm?
florian_kc has joined #yocto
<jonmason> RP: I assume this is something in the past 24h, correct?
Vonter has joined #yocto
argonautx has quit [Quit: Leaving]
codavi has quit [Ping timeout: 240 seconds]