Friday, 2021-03-19

*** nslu2-log <nslu2-log!> has quit IRC00:01
*** nslu2-log_ <nslu2-log_!> has quit IRC00:02
*** zkrx <zkrx!> has quit IRC00:06
*** goliath <goliath!> has quit IRC00:07
*** zkrx <zkrx!> has joined #yocto00:26
opellohi, i'm trying to use some older layers with a newer poky release, and am having a few problems with the kernel and u-boot recipes being vendor provided and older, such that i'm trying to say RPROVIDES_u-boot-mkimage += "u-boot-tools" which doing that (and -native versions) complainx about virtual/kernel having an unmet dependency (nothing PROVIDES u-boot-tools-native, u-boot-mkimage-native RPROVIDES u-boot-tools-native)... but apparently ...00:30
opello... that's insufficient?00:30
opellocomplains* even00:31
*** bps <bps!~bps@> has quit IRC00:32
*** georgem_home <georgem_home!uid210681@gateway/web/> has quit IRC00:41
*** tedfernau <tedfernau!> has quit IRC00:45
*** leon-anavi <leon-anavi!~Leon@> has quit IRC01:03
*** bobo <bobo!> has quit IRC01:14
*** ssajal <ssajal!> has quit IRC01:14
*** sakoman <sakoman!~steve@> has quit IRC02:40
*** kaspter <kaspter!~Instantbi@> has joined #yocto03:06
*** ahadi <ahadi!> has quit IRC03:06
*** ahadi <ahadi!> has joined #yocto03:13
*** itseris <itseris!> has joined #yocto03:26
*** fatalhalt <fatalhalt!~fatalhalt@2601:244:4d01:52df:225:90ff:feda:2428> has joined #yocto04:06
*** Kyubi <Kyubi!~Kyubi@> has quit IRC04:50
yatesRobertBerger: you're on!04:55
*** Kyubi <Kyubi!~Kyubi@> has joined #yocto05:03
*** jobroe <jobroe!> has joined #yocto05:28
*** beneth <beneth!> has joined #yocto05:30
*** JaMa <JaMa!> has quit IRC05:31
*** dreyna <dreyna!~dreyna@2601:646:4201:e280:508e:5d7f:90be:919f> has quit IRC05:34
*** JaMa <JaMa!> has joined #yocto05:34
*** JosephAntony <JosephAntony!a5e10863@> has joined #yocto06:11
*** kpo_ <kpo_!> has quit IRC06:12
*** kpo_ <kpo_!> has joined #yocto06:13
*** AndersD <AndersD!> has joined #yocto06:31
*** bobo <bobo!> has joined #yocto06:45
*** agust <agust!> has joined #yocto06:47
*** ENPJ <ENPJ!~ENPJ@2001:a61:3a33:7901:6de9:a24b:3d4e:f73b> has joined #yocto06:57
*** ThomasD13 <ThomasD13!> has joined #yocto07:01
*** jobroe <jobroe!> has quit IRC07:03
*** B0ned1ger2 <B0ned1ger2!> has joined #yocto07:06
*** jobroe <jobroe!> has joined #yocto07:07
*** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has joined #yocto07:17
*** bobo <bobo!> has quit IRC07:27
*** alexlarsson <alexlarsson!> has joined #yocto07:32
*** mckoan|away is now known as mckoan07:36
mckoangood morning07:36
hmw1good morning07:40
*** zyga-mbp <zyga-mbp!~zyga@unaffiliated/zyga> has joined #yocto07:53
*** hpsy <hpsy!~hpsy@2c0f:fc89:8022:9245:a4e0:cdd5:31f8:b108> has joined #yocto08:19
*** yannholo <yannholo!> has joined #yocto08:19
*** Yumasi <Yumasi!~guillaume@2a01:e0a:5cb:4430:71ee:168f:367c:6d70> has joined #yocto08:30
*** zyga-mbp <zyga-mbp!~zyga@unaffiliated/zyga> has quit IRC08:30
*** fl0v0 <fl0v0!~fvo@> has joined #yocto08:34
*** kpo_ <kpo_!> has quit IRC08:36
*** kpo_ <kpo_!> has joined #yocto08:37
*** hpsy <hpsy!~hpsy@2c0f:fc89:8022:9245:a4e0:cdd5:31f8:b108> has quit IRC08:45
*** rubdos <rubdos!~rubdos@2a02:578:859d:700:8b44:5716:382d:a7da> has quit IRC08:49
*** rubdos <rubdos!~rubdos@2a02:578:859d:700:8b44:5716:382d:a7da> has joined #yocto08:49
*** mihai <mihai!~mihai@unaffiliated/mihai> has joined #yocto08:54
*** ahadi <ahadi!> has quit IRC08:56
*** ahadi <ahadi!> has joined #yocto08:57
*** hpsy <hpsy!~hpsy@2c0f:fc89:8012:be3f:a4e0:cdd5:31f8:b108> has joined #yocto08:59
*** manuel1985 <manuel1985!~manuel198@2a02:1748:dd5c:f290:c5b2:fdff:b718:9edf> has joined #yocto09:09
*** goliath <goliath!> has joined #yocto09:12
*** Firuxabade <Firuxabade!~firuxabad@2001:e68:544d:97df:d883:3182:1191:8ed9> has joined #yocto09:13
*** psnsilva <psnsilva!~psnsilva@> has joined #yocto09:23
*** Firuxabade <Firuxabade!~firuxabad@2001:e68:544d:97df:d883:3182:1191:8ed9> has quit IRC09:24
*** gsalazar <gsalazar!> has joined #yocto09:28
*** manuel1985 <manuel1985!~manuel198@2a02:1748:dd5c:f290:c5b2:fdff:b718:9edf> has quit IRC09:31
*** simonpe^^ <simonpe^^!> has joined #yocto09:34
*** tnovotny <tnovotny!> has joined #yocto09:37
*** gsalazar <gsalazar!> has quit IRC09:40
*** hpsy <hpsy!~hpsy@2c0f:fc89:8012:be3f:a4e0:cdd5:31f8:b108> has quit IRC09:43
*** Blackbetty <Blackbetty!> has joined #yocto09:48
Blackbettyhello, do you guys use kas? is there an irc channel for kas?09:48
* derRichard uses it from time to time09:50
derRichardno idea whether there is an irc for it09:50
Blackbettycouldnt find it anywhere09:50
derRicharddoes it matter?09:50
BlackbettyI wonder if there is any possibility to maintain layers order from kas.yml09:51
Blackbettykas team decided to stick with alphabetic ordering which kinda destroys my build09:51
Blackbettylooking for a way to get in touch with them ;)09:53
*** Bunio_FH <Bunio_FH!> has quit IRC09:53
derRichardi'd try their github09:54
*** Bunio_FH <Bunio_FH!> has joined #yocto09:55
*** georgem_home <georgem_home!uid210681@gateway/web/> has joined #yocto10:03
*** Firuxabade <Firuxabade!~firuxabad@2001:e68:544d:97df:d883:3182:1191:8ed9> has joined #yocto10:03
simonpe^^I'm looking for a compatibility matrix between imx evk boards and fslc kernel/u-boot versions. Is there such a thing?10:10
simonpe^^What I need is a u-boot with a certain commit for the u-boot patches we have for other boards to work, and the currently supported stuff by NXP is all on zeus and we run dunfell10:16
simonpe^^And for some stupid reason there is a version dependency on u-boot from the imx kernels10:16
simonpe^^I can't for the life of me figure out what they have messed up to end up in that situation10:16
*** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has quit IRC10:23
*** Kyubi <Kyubi!~Kyubi@> has quit IRC10:27
*** mrslash <mrslash!> has joined #yocto10:42
rburtonBlackbetty: no irc for kas annoyingly, the google group is the best way10:43
Blackbettyrburton: derRichard: thank you, I already posted in the topic.10:44
rburtonkanavin_: config.log is *huge*10:44
*** JosephAntony <JosephAntony!a5e10863@> has quit IRC11:15
*** mrslash <mrslash!> has quit IRC11:16
*** Sponge5 <Sponge5!> has joined #yocto11:18
*** tnovotny <tnovotny!> has quit IRC11:19
*** B0ned1ger <B0ned1ger!> has joined #yocto11:23
*** B0ned1ger2 <B0ned1ger2!> has quit IRC11:27
*** B0ned1ger <B0ned1ger!> has quit IRC11:28
*** mckoan is now known as mckoan|away11:33
*** zyga <zyga!~zyga@unaffiliated/zyga> has joined #yocto11:33
*** Firuxabade <Firuxabade!~firuxabad@2001:e68:544d:97df:d883:3182:1191:8ed9> has quit IRC11:35
*** adosch <adosch!> has joined #yocto11:38
RP is a fun failure, its caused by my sstate cleanup patches :(11:49
RPI think it is exposing a race11:49
*** lumbergeek <lumbergeek!~geek@> has joined #yocto11:53
lumbergeekOk, my google foo apparently sucks.  Is there a database of available packages out there that can be used in a build?11:53
lumbergeekmany thanks!  i feel like I was bouncing all over and never quite found my way there11:59
*** manuel1985 <manuel1985!~manuel198@2a02:1748:dd5c:f290:c5b2:fdff:b718:9edf> has joined #yocto12:09
*** manuel1985 <manuel1985!~manuel198@2a02:1748:dd5c:f290:c5b2:fdff:b718:9edf> has quit IRC12:14
*** Firuxabade <Firuxabade!~firuxabad@2001:e68:544d:97df:d883:3182:1191:8ed9> has joined #yocto12:35
*** ThomasD13 <ThomasD13!> has quit IRC12:43
*** Firuxabade <Firuxabade!~firuxabad@2001:e68:544d:97df:d883:3182:1191:8ed9> has quit IRC12:47
*** rcoote <rcoote!~rcoote@2a02:908:692:81c0:fcd7:52e:1af4:518c> has joined #yocto13:00
*** plntyk <plntyk!> has quit IRC13:03
*** zyga <zyga!~zyga@unaffiliated/zyga> has quit IRC13:06
*** zyga <zyga!~zyga@unaffiliated/zyga> has joined #yocto13:08
*** ecdhe_ <ecdhe_!~ecdhe@unaffiliated/ecdhe> has joined #yocto13:24
Sponge5Hi, until now I've been using separate weston.ini files with separate .bbappends for each machine (each machine has a dedicated layer). I've now replaced those with weston.ini.patch and a base weston.ini, but I still have 5 .bbappends. How can I clean this up even further?13:26
*** kothz <kothz!~geek@> has joined #yocto13:26
Sponge5The idea is to have 5x weston.ini.patch and just one .bbappend (or no .bbappends at all)13:27
*** jobroe_ <jobroe_!> has joined #yocto13:27
*** kpo <kpo!> has joined #yocto13:28
*** jobroe_ <jobroe_!> has quit IRC13:32
*** zyga <zyga!~zyga@unaffiliated/zyga> has quit IRC13:33
*** lumbergeek <lumbergeek!~geek@> has quit IRC13:33
*** goliath <goliath!> has quit IRC13:33
*** kpo_ <kpo_!> has quit IRC13:33
*** jobroe <jobroe!> has quit IRC13:33
*** ecdhe <ecdhe!~ecdhe@unaffiliated/ecdhe> has quit IRC13:33
*** zyga <zyga!~zyga@unaffiliated/zyga> has joined #yocto13:35
*** otavio_ <otavio_!> has joined #yocto13:37
*** goliath <goliath!> has joined #yocto13:41
*** sakoman <sakoman!~steve@> has joined #yocto13:42
derRichardi'm analysing a build issue, all files in the rootfs are owned by the build users. looks like the fakeroot mechanism didn't work. and indeed, looking into the image's pseudo.log i see tons of messages such as: find_dev: select returned neither a row nor done: database disk image is malformed13:42
derRichardcan it be the case that pseudo fails silently instead of aborting the build in case of such fatal errors? :-(13:43
*** leon-anavi <leon-anavi!~Leon@> has joined #yocto13:50
*** Chrys <Chrys!a5e15f2b@> has joined #yocto13:56
ChrysHello everyone :)13:57
ChrysIn my recipe, i modify u-boot env file in the "${WORKDIR}".13:57
ChrysProblem is, when using devtool modify... It prompt an error because the construction of the path for this is quite modified.13:57
ChrysWhat would be the workaround?13:57
*** plntyk <plntyk!> has joined #yocto13:59
*** B0ned1ger <B0ned1ger!> has joined #yocto14:07
*** caiortp <caiortp!> has quit IRC14:08
Sponge5I found the answer to my question:
Sponge5Kind of14:12
*** B0ned1ger <B0ned1ger!> has quit IRC14:12
*** kaspter <kaspter!~Instantbi@> has quit IRC14:17
*** mrslash <mrslash!> has joined #yocto14:25
*** linums <linums!> has joined #yocto14:34
derRichardhmm, yes. pseudo ignores fatal sqlite errors :-(14:38
*** Blackbetty <Blackbetty!> has quit IRC14:40
*** ssajal <ssajal!> has joined #yocto14:40
sgwMorning folks, swatting a couple of failures.14:49
sgwRP: have we seen liblzma: memory allocation failed before?  This smells a little like an Autobuilder intermittent I could not find any bugzilla entries14:50
*** BobPungartnik <BobPungartnik!~BobPungar@> has joined #yocto14:54
derRichardsgw: does you have many cpus?14:55
derRichard*do you14:55
*** BobPungartnik <BobPungartnik!~BobPungar@> has quit IRC14:57
sgwderRichard: it's has 56 cpu with 128G memory, seems 3 packages failed with memory issues14:57
*** champagneg2 <champagneg2!> has quit IRC14:57
yatessgw: holy cow!14:58
*** Chrys <Chrys!a5e15f2b@> has quit IRC14:58
*** champagneg2 <champagneg2!> has joined #yocto14:59
sgwyates:  this is part of the YP Autobuilder infrastructure, not unsurprising actually14:59
sgwThe memory failure is though!14:59
derRichardsgw: yeah, then xz might run out of memory.14:59
derRichardi'm facing the same issues on super large build systems14:59
derRichardlet me find the fix14:59
*** marc1 <marc1!> has quit IRC15:00
*** marc1 <marc1!> has joined #yocto15:00
derRichardsee in poky15:01
derRichardcommit 27ff81bfd880280607c79dce2f724c8bfafce02d15:01
derRichardAuthor: Mike Looijmans <>15:01
derRichardDate:   Fri Mar 20 15:45:20 2020 +010015:01
derRichard    classes/populate_sdk_base: Implement xz compression options15:01
derRichardmaybe you hit an other place where parallel compression is done...15:01
sgwderRichard: this is a recent master build on the autobuilder, I would think that fix is in.  I have to bail for an hour, back after meeting15:01
*** Firuxabade <Firuxabade!~firuxabad@2001:e68:544d:97df:d883:3182:1191:8ed9> has joined #yocto15:02
derRichardyeah but maybe yet another bug of the same class..15:02
*** azimazlan_ <azimazlan_!~firuxabad@2001:e68:544d:97df:d883:3182:1191:8ed9> has joined #yocto15:02
derRichardlike i said, another parallel compression going one somewhere15:02
sgw3 likely15:02
derRichardfor 56 cpus, only 128gb ram is a little too few15:03
derRichardeven on my 24 core system with 128gb ram, i'm hitting such issues15:03
sgwderRichard: it's funny to think that's small!15:03
JPEWxz seems particularly bad about that for some reason15:03
yateswhat is xz?15:03
JPEWA compression tool15:04
derRichardin parallel mode it wastes per core tons of memory15:04
JPEWyates: I believe it's the tool that does LZMA compression15:05
yateslooks like 7z does it too15:07
*** linums <linums!> has quit IRC15:16
yateskergoth: yesterday, when discussing 'do_build[recrdeptask] += "do_deploy"', you spoke of build-time dependencies and run-time dependencies. what is a run-time dependency?15:17
RPsgw: we've not seen that one for a long time. Which worker was it?15:17
*** linums <linums!> has joined #yocto15:18
*** azimazlan_ <azimazlan_!~firuxabad@2001:e68:544d:97df:d883:3182:1191:8ed9> has quit IRC15:21
sgwRP: debian10-ty-115:21
RPsgw: hmm, strange to hit that now...15:23
vdlhi all -- I assume that it is still unsafe to build multiple distros using the same build/ directory, correct?15:25
RPvdl: not so much unsafe as inefficient15:26
sgwOk, I will file it as a AB intermittent so we can track15:26
vdlRP: if your project includes multiple distros, how do you deal with it, simply one build-foo/ directory per distro?15:28
RPvdl: that or multiconfig15:28
vdlRP: but multiconfig is useful when you can a link at build time between 2 distincts images, like embedding a dist/mach/image combination into another dist/mach/image combination, correct?15:29
JPEWvdl: multiconfig has many uses, that's one of them15:30
RPvdl: multiconfig would also allow you to build two different distro configs in parallel in separate tmpdirs15:30
RPone distro could have images including images from the other, lots of possibilities15:31
JPEWvdl: For example, we have multiple products we can choose to build, and build each on in it's own multiconfig. This allows us to choose to build one or more with a single invocation of bitbake15:31
JPEWvdl: We us this tool to wrangle it all, but at the end of the day, it's just multiconfig:
*** AndersD <AndersD!> has quit IRC15:32
kergothyates: scroll down to Dependencies15:33
kergothas i've linked or directed you to 4 or 5 times now15:33
*** aleblanc <aleblanc!> has quit IRC15:33
vdlJPEW: RP: I understand that multiconfig is the way to go if you need to build multiple distro combinations at once, even though if they aren't packaged together (but they could)15:38
*** aleblanc <aleblanc!> has joined #yocto15:39
vdlFinally I need to prepare a release archive, like <customer>-release-<version>.tar.xz including the .wic image, README and so on. Is there a way to integrate this step within the single invokation of bitbake?15:40
*** aleblanc <aleblanc!> has quit IRC15:40
yateskergoth: i don't appreciate being addressed in this manner. we all know yocto is a huge, sprawing tool, with multiple sources of documentation. i guarantee that i will ask another question for which i've already been directed, just because my brain (like many others) is not good at absorbing the large amount of inter-related, parallel information which yocto requires15:43
tlwoerneri want to compare the boot times of various builds/tweaks. is there a way to get one of those nice kernel timestamp thingies on the console right as the login prompt is appearing?15:44
RPvdl: you could add a task to an image or add a recipe which does it15:44
yatesat least not instantly and/or perfectly15:46
vdlRP: an image recipe with IMAGE_FSTYPES = "tar.xz" seems the way to go, but I fail to depends on image-a.wic being deployed. I tried do_rootfs[depends] += "image-a:do_build" without success15:46
RPvdl: personally, I'd just write a recipe with a custom task which does it15:47
RPtrying to reuse the image code is probably going to just be a pain15:48
vdlyates: I do not wish to step into this topic, but people in the open source community often expect you to look up for questions already answered. For example this channel is logged, so you can easily ask again your question to google with your username to retrieve your last interaction about the topic.15:49
vdlRP: I see. How do you ensure that your recipe is called after image-a.wic has been deployed? (do you have any example in mind I could look into?)15:50
RobertBergerShould we all attend "From Yocto + Buildroot to Ubuntu core" and ask some questions?
tlwoernerRobertBerger: lol15:51
RPvdl: you'd just do something like do_mytask[depends] = "imagerecipe:do_image_complete" I don't have a specific example in mind15:53
vdlRP: so you're not even inheriting an image, correct? This way you need to handle the archiving yourself instead of relying on IMAGE_FSTYPES = "tar.xz" for example, am I correct?15:56
RPvdl: Correct, that is how I would do it15:58
RPvdl: tar commands aren't complex15:58
vdlThey aren't complex, but since the archiving is abstracted by yocto already, it'd be nice to re-use it.15:59
*** linums <linums!> has quit IRC16:07
*** linums <linums!> has joined #yocto16:07
vdlRP: it looks like a good candidate for something like a release.bbclass supporting RELEASE_FSTYPES and a file listing similar to IMAGE_BOOT_FILES (e.g. RELEASE_FILES = "some-image.wic;sdcard.img some-doc.txt;README" and so on)16:10
RPvdl: reuse is nice but you aren't wanting a large portion of what the image code is doing (building a rootfs from packages)16:15
linumsI'm building yocto for arm (rpi) now16:15
linumsAnd I regularly run into segmentation fault issues, and those are disappearing when I re-run the build16:16
RPvdl: What you're after to do is something like a 5 line custom task vs a ton of work with classes and variables for  reusable code16:16
linumsDo anyone has a clu why can it happen?16:16
RPlinums: checked you memory for errrors?16:16
linumsSo it might be the device16:17
vdlRP: isn't the archiving code distinct from building a rootfs from packages? I understand what you're saying though, I'm just surprised such class doesn't exist yet. I wanted to avoid writing a custom script or recipe before making sure such infrastructure doesn't exist yet.16:19
RPvdl: I think you'd struggle to separate the rootfs and image archive code as it stands today16:21
*** Sponge5 <Sponge5!> has quit IRC16:21
RPlinums: random segfaults which don't reproduce are usually hardware or a kernel problem, most often bad memory16:21
RPI have seen bad virtualisation before too16:22
vdlRP: ho ok, so unfortunately the archiver class (or whatever it's called) is currently bound to the creation of a rootfs from packages.16:23
vdlthat's unlucky16:23
vdlJPEW: how does whisk compare to a tool like kas? They look similar tome16:25
linumsRP: now I fear it's from the swap file, since the ram seems ok, but thanks, I guess that is the issue16:27
*** sgw <sgw!~sgw@2601:642:c400:ecf0:e84a:317d:c341:256c> has quit IRC16:35
paulgGuess we should all pull up our tent pegs and go home.16:37
*** kyrix <kyrix!~ashwoods@> has joined #yocto16:39
*** sgw <sgw!~sgw@2601:642:c400:ecf0:9c7a:1b9d:bd52:c567> has joined #yocto16:47
sgwRP: I am digging into the other set of selftest failures in WIC, but the log files seems to have gone already, is that normal?16:47
*** Firuxabade <Firuxabade!~firuxabad@2001:e68:544d:97df:d883:3182:1191:8ed9> has quit IRC16:48
*** bobo <bobo!> has joined #yocto16:51
RPsgw: is this the rawcopy one? I have a fix for that16:52
RPsgw: you probaby need a s/build/build-renamed/ in the path?16:52
sgwThere does not seem to be a build-renamed in /home/pokybuild/yocto-worker/oe-selftest-debian/build/ or /home/pokybuild/yocto-worker/oe-selftest-debian/build/build16:53
RPsgw: selftest will run in build-st-<pid>16:54
RPsgw: (it runs multiple in parallel)16:54
sgwThis is a file not found issue in wic looking for the .ext416:54
sgwRight, the -<pid> that I am trying to find is gone16:54
sgwRP: I wanted to look at the build tmp/deploy dir area16:56
*** aleblanc <aleblanc!> has joined #yocto16:56
RPsgw: hmm, I thought failed builds were preserved16:57
*** kiwi_29 <kiwi_29!> has joined #yocto16:57
RPsgw: I have a fix out for the wic/ext4 one, I spent most of the day figuring that one out. Its caused by my sstate cleanup patch16:58
sgwRP: I thought they were also, Ok, I will swat those out as handled then.16:58
sgwRP: thanks for that update and I hope you can break away and have a good weekend.16:59
*** kiwi_29 <kiwi_29!> has quit IRC17:00
*** kiwi_29 <kiwi_29!> has joined #yocto17:00
SaurRP: Wasn't the idea with commit 73d538f2 (bitbake.conf: Prevent pyc file generation in pseudo context) that fakeroot tasks should no longer create .pyc files? Because we are having occasional pseudo aborts after upgrading to Gatesgarth (24.0.2) when we create our final image. We use our own tool, which is similar to wic. We finally managed to get the psudo.log from one of the failed builds and found this: path mismatch [1 link]: ino 1208517:07
Saur2760 db '.../poky/bitbake/lib/bb/ui/__pycache__/__init__.cpython-38.pyc' req '.../poky/bitbake/lib/bb/ui/__pycache__/uievent.cpython-38.pyc.140666647610112'. And when I check the environment the tool is running in, I cannot see PYTHONDONTWRITEBYTECODE being set.17:07
SaurOr does that change only apply to fakeroot python tasks?17:08
*** champagneg2 <champagneg2!> has quit IRC17:10
RPSaur: good questions. Would need to be debugged, I don't know offhand how it should/would work out. The intent was to disable them17:11
RPSaur: I think the option is python version dependent17:12
*** champagneg2 <champagneg2!> has joined #yocto17:12
RPSaur: I'd have to grep, I don't remember17:25
SaurRP: :) Ok, then I can just as well grep myself. ;)17:26
*** leon-anavi <leon-anavi!~Leon@> has quit IRC17:28
SaurOk, for fakeroot, FAKEROOTBASEENV is the environment that is used when starting bitbake-worker.17:28
*** Yumasi <Yumasi!~guillaume@2a01:e0a:5cb:4430:71ee:168f:367c:6d70> has quit IRC17:35
SaurAnd if I understand the code in bitbake-worker correctly, none of the environment that was used to start the bitbake-worker is left when it actually starts a task. Instead it is then the environment from FAKEROOTENV that is used. So this means that adding PYTHONDONTWRITEBYTECODE=1 to FAKEROOTBASEENV does in fact not affect python code started by, e.g., a fakeroot shell task. :(17:38
*** zyga <zyga!~zyga@unaffiliated/zyga> has quit IRC17:39
*** psnsilva <psnsilva!~psnsilva@> has quit IRC17:39
SaurThankfully this means that it should be simple to solve the problem we are seeing by just adding FAKEROOTENV += "PYTHONDONTWRITEBYTECODE=1" to our distro.conf.17:40
SaurI'll send a corresponding patch for OE-Core as well.17:41
SaurMeh, I have a strong feeling I will have to create a test case for this as well... :)17:46
*** bobo <bobo!> has quit IRC17:46
*** rcoote <rcoote!~rcoote@2a02:908:692:81c0:fcd7:52e:1af4:518c> has quit IRC17:52
*** kyanres <kyanres!> has quit IRC17:53
RPSaur: sounds like good progress on figuring out the issue :)18:03
SaurThe weirdest thing is that we are only seeing this fail when building the image for one out of all the products we build images for...18:05
*** bobo <bobo!> has joined #yocto18:09
*** zyga <zyga!~zyga@unaffiliated/zyga> has joined #yocto18:17
JPEWvdl: Ya, it overlaps with kas some18:18
JPEWEspecially if you do whisk + pyrex (build in a container)18:19
*** zyga <zyga!~zyga@unaffiliated/zyga> has quit IRC18:20
*** jwessel <jwessel!~jwessel@> has left #yocto18:21
*** fl0v0 <fl0v0!~fvo@> has quit IRC18:27
*** yannholo <yannholo!> has quit IRC18:27
*** dreyna <dreyna!~dreyna@2601:646:4201:e280:8ec:f86e:d0fb:6a62> has joined #yocto18:32
*** zyga <zyga!~zyga@unaffiliated/zyga> has joined #yocto18:34
*** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has joined #yocto18:43
*** B0ned1ger <B0ned1ger!> has joined #yocto18:44
*** B0ned1ger <B0ned1ger!> has quit IRC18:48
*** oobitots <oobitots!> has joined #yocto18:54
*** oobitots <oobitots!> has quit IRC19:07
*** bobo <bobo!> has quit IRC19:08
*** oobitots <oobitots!> has joined #yocto19:20
*** zyga <zyga!~zyga@unaffiliated/zyga> has quit IRC19:36
*** zyga <zyga!~zyga@unaffiliated/zyga> has joined #yocto19:37
*** BCMM_ <BCMM_!~BCMM@unaffiliated/bcmm> has joined #yocto19:37
*** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has quit IRC19:38
*** aleblanc <aleblanc!> has quit IRC19:45
*** BCMM_ is now known as BCMM19:47
vdlJPEW: and kas does handle multiconfig already19:48
*** aleblanc <aleblanc!> has joined #yocto19:50
*** champagneg2 <champagneg2!> has quit IRC19:51
*** champagneg2 <champagneg2!> has joined #yocto19:53
*** oobitots <oobitots!> has quit IRC20:03
*** yizhao <yizhao!~zhaoyi@> has quit IRC20:08
*** aleblanc <aleblanc!> has quit IRC20:09
*** leon-anavi <leon-anavi!~Leon@> has joined #yocto20:21
*** gpanders <gpanders!~gpanders@gateway/tor-sasl/gpanders> has quit IRC20:23
*** gpanders <gpanders!~gpanders@gateway/tor-sasl/gpanders> has joined #yocto20:24
*** mrslash <mrslash!> has quit IRC20:27
moto-timokas handles multiconfig very well, it's just not well documented20:33
* moto-timo still needs to try whisk20:34
moto-timoJPEW: do you run whisk/pyrex in any cloud providers?20:35
JPEWmoto-timo: K8s on baremetal20:38
moto-timoJPEW: the battlestar cluster... but at work also?20:38
JPEWOpenStack maybe? I'm not exactly sure20:39
JPEWNot "in the cloud" its all on-prem20:39
moto-timogot it20:39
JPEWIf someone want to fund a trial on AWS, I'd be up for it :)20:39
JPEWBut I can't throw down a few $1000 to try it myself20:40
moto-timoat some point here I'll be testing AWS/Azure/GCE... need to be agnostic to the provider20:40
*** B0ned1ger <B0ned1ger!> has joined #yocto20:40
JPEWmoto-timo: Right, AWS was just an example20:40
moto-timoyeah... this is mostly own money20:40
moto-timoI can't actually tell you what providers we use internally20:41
moto-timoso I live vicariously through open source projects that have donated compute slices20:41
moto-timobut I have seen a cluster crash and burn, be restarted, crash and burn and then had to be taken out back and shot in the head20:42
moto-timono free lunch20:42
JPEWmoto-timo: Right. That's why my latest expirement was to build my own cluster20:43
* JPEW Really needs to get labgrid working on that again20:43
moto-timoJPEW: and why I have an rpi cluster20:43
JPEWmoto-timo: What's the build time like on that?20:44
* moto-timo needs to get labgrid and ceph running20:44
JPEWmoto-timo: Oh, I tried ceph... it's actually what took down my cluster20:44
moto-timoJPEW: ugh... I'm not to that point yet. still working on the ansible bring up20:44
moto-timodon't tell me that20:44
JPEWIt's.... slower then molassas... and I have 4Gbit links (LCAP) between my servers20:44
moto-timothere has GOT TO BE something better than NFS20:45
moto-timoor CIFS/samba20:45
*** B0ned1ger <B0ned1ger!> has quit IRC20:45
JPEWSo far, my best option has been local for working dir, share sstate over NFS20:45
JPEWYou could probably share sstate of CEPH and that would work fine20:45
JPEW*over CEPH20:46
moto-timosstate is the sticky wicket that doesn't scale well to the cloud :(20:46
moto-timothat was my intent. sstate over ceph20:46
moto-timoI figure hadoop would be slower than molasses20:46
JPEWYa, that might be better. I was trying to use it for the working volume, had a build with took over 10 hours, timed out, and broke tekton somehow20:47
moto-timooh... no that's not how I wanted to use it20:47
JPEWIt never recovered, so I had to re-image the cluster20:47
* moto-timo feels slightly less panicked now20:47
moto-timoI still need to expand the PDU drivers for labgrid and enable PXE boot20:48
rburtonyou can do sstate over http to fetch and then push back through some other means post-build20:48
rburtonwhich removes the NFS aspect but give you bigger windows when stuff can get built twice as you don't push as often20:49
moto-timoyeah... post build write is what I want to experiment with20:49
rburtonthat's what paulbarker did20:49
JPEWWe do that with rsync.... it's too slow IMHO20:49
rburtonbackblaze, http to fetch and sync post-build with b2sync20:49
moto-timoI figure if the options are "might build twice" or "zero sstate", I'll take the first.20:50
rburtonfor small clusters, i'm still happy with NFS for fast and shjared20:50
rburtonespecially when i have someone i can say "i want a NFS share" to :)20:50
moto-timoKonrad also commented on the slowness of rsync... instead suggested tarballs20:50
* moto-timo asks moto-timo for an NFS share20:51
rburtonyou should have a word with moto-timo, he sounds like a lame admin20:51
moto-timoit's friday and nearly beer-thirty20:51
* moto-timo is a lazy greedy curmudgeon sometimes20:51
JPEWmoto-timo: What's the aversion to NFS?20:51
moto-timoI've heard too many stories about brittleness and failures and weird slowdowns20:52
moto-timoand it's old tech... feels like something should be better by now20:52
moto-timoalso... security folks have been very very "NOPE" about it20:53
JPEWWell.... you *do* know that if you use CEPH as a shared disk, it does so over NFS protocol :)20:53
moto-timoyeah... don't remind me.20:53
moto-timoof course, the security folks' solution is FUSE ssh20:54
* JPEW belgh20:54
* moto-timo runs to find a bucket20:54
JPEWNFS4 is way better than NFS320:54
moto-timoSo I've heard from multiple sources... so my data is old I think20:55
*** manuel1985 <manuel1985!~manuel198@2a02:1748:dd5c:f290:c5b2:fdff:b718:9edf> has joined #yocto20:55
* JPEW Wrote an NFS4 server from scratch for an RTOS.... fun times!20:55
moto-timoalso, you can get very many Gbits over fiber these days20:55
moto-timoJPEW is a madman20:55
*** snikulov <snikulov!~snikulov@> has joined #yocto20:56
moto-timorpi pcie is only 1x so you'd saturate it very easily with normal network20:56
moto-timobut that might be "fast enough" for a home lab that cost less than a used car20:56
JPEWRight, I didn't really notice it being slow before I had 4GB LCAP links20:57
moto-timoand doesn't need a nuclear reactor to power it20:57
* moto-timo dreams of 10Gbit backbone in the LAN20:57
moto-timostuff is starting to get affordable on eBay20:58
JPEWI bought a switch that can do 10Gbit... just need the NICs on my servers20:58
JPEW.... some day20:58
moto-timoJPEW: there are some nics that are not expensive on eBay... take a look20:58
moto-timobroadcom I think20:58
moto-timomy problem is my mobos are old so the base throughput won't benefit21:00
moto-timonot going to complain about the price I paid for the compute power though...21:00
JPEWmoto-timo: Ditto... I found some pretty cheap Dell R610s21:02
*** zkrx <zkrx!> has quit IRC21:08
*** zkrx <zkrx!> has joined #yocto21:12
JaMahmm python3 PACKAGECONFIG can no longer be used to disable gdbm (it worked fine in gatesgarth with 3.8) in master with 3.9 it fails with:21:13
JaMaThe necessary bits to build these optional modules were not found:21:13
JaMa_dbm                  _gdbm21:13
moto-timojust oe-core? can you file a bug?21:14
JaMayes, will debug a bit more and then send a fix or bug report21:16
*** sbach <sbach!~sbachmatr@> has quit IRC21:18
*** sbach <sbach!~sbachmatr@> has joined #yocto21:18
*** aidanh_ <aidanh_!~aidanh@unaffiliated/aidanh> has joined #yocto21:19
*** aidanh <aidanh!~aidanh@unaffiliated/aidanh> has quit IRC21:21
*** aidanh_ is now known as aidanh21:21
*** adosch <adosch!> has quit IRC21:24
*** snikulov <snikulov!~snikulov@> has quit IRC21:27
*** snikulov <snikulov!> has joined #yocto21:27
*** manuel1985 <manuel1985!~manuel198@2a02:1748:dd5c:f290:c5b2:fdff:b718:9edf> has quit IRC21:30
*** snikulov <snikulov!> has quit IRC21:35
*** snikulov <snikulov!> has joined #yocto21:35
*** yocti <yocti!> has joined #yocto22:13
*** psycor4m4 <psycor4m4!> has joined #yocto22:13
*** ak77 <ak77!> has quit IRC22:13
*** fitzsim` <fitzsim`!> has joined #yocto22:13
*** King_InuYasha <King_InuYasha!~King_InuY@fedora/ngompa> has quit IRC22:13
*** psycor4m4 is now known as psycorama22:13
*** fitzsim` is now known as fitzsim22:13
*** ak77 <ak77!> has joined #yocto22:14
*** agust <agust!> has quit IRC22:16
*** ahadi <ahadi!> has quit IRC22:16
*** hackspider <hackspider!> has joined #yocto22:16
hackspiderHi guys, is it wise to set the machine in the distro conf?22:17
*** ahadi <ahadi!> has joined #yocto22:17
derRichardi'd not do it. actually i'm not even sure whether this is allowed22:29
derRichardusually you have more than one machine22:30
*** zyga <zyga!~zyga@unaffiliated/zyga> has quit IRC22:38
*** ENPJ <ENPJ!~ENPJ@2001:a61:3a33:7901:6de9:a24b:3d4e:f73b> has quit IRC22:41
*** leon-anavi <leon-anavi!~Leon@> has quit IRC22:44
*** aleblanc <aleblanc!> has joined #yocto22:53
hackspiderMy setup is more like this: I've got a reference board with the most likely hardware config. For this hardware (machine) I've created a machine config for this. If a customer wants exactly this config he gets an own meta layer with an image recipe for his applications/sources. But if the customer needs a custom hardware with removed or added23:00
hackspiderperipheral he gets also an own machine config in his meta layer to adapt uboot/kernel/kernel_modules. Does this make sense so far?23:00
hackspiderWhat I then did was to create in the meta layer of the reference board a distro config where I defined what I needed in the distro (musl, systemd,etc.). But know I wonder where to set the machine config. Should I add a distro in all customer specific meta layers where I define the machine or should I add it to env variables with every build?23:06
*** aleblanc <aleblanc!> has quit IRC23:09
*** simonpe^^ <simonpe^^!> has quit IRC23:15
RobertBerger@hackspider: for your use case I would use MACHINEOVERRIDES23:17
derRichardyes, sounds like a case for MACHINEOVERRIDES23:25
hackspiderI haven't known this variable yet, but this seems like the way to go. So I need a distro file in each customer layer with a require statement to the distro of the refernce distro so I can set the MACHINEOVERRIDES value? So basically each customer gets an "own" distro?23:25
*** yates <yates!> has quit IRC23:28
RobertBerger@hackspider - nope why in the distro?23:29
RobertBerger@hackspider: you have a "default" machine config for all and whoever wants to make a change can extend it by an override. Let me try to find an example.23:30
RobertBergerThere he uses some eval board as the "base" and adds his own stuff in addition to it.23:31
hackspiderBut where do I define the machine to use? Since something needs to point to the correct <machine>.conf23:35
*** fatalhalt <fatalhalt!~fatalhalt@2601:244:4d01:52df:225:90ff:feda:2428> has quit IRC23:35
hackspiderlets say in the meta-referencehardware layer I defined a "referencehardware.conf" and then in a customer layer lets say meta-customer I have a "customhardware.conf" machine file with a require statement to "referencehardware.conf". But where do I specify to use "referencehardware.conf"23:38
*** otavio_ <otavio_!> has quit IRC23:45
RobertBerger@hackspider: as usual in the machine.conf23:46
RobertBergerMACHINEOVERRIDES .= ":zc706-zynq7" this adds to the list also zc706-zynq723:46
RobertBergermaybe you should also check how override lists work23:47
*** otavio_ <otavio_!> has joined #yocto23:47
RobertBergerbitbake busybox -e | grep ^OVERRIDES=23:48
RobertBergerbitbake busybox -e | grep ^MACHINEOVERRIDES=23:48
RobertBergerif you see the output of MACHINEOVERRIDES you could imagine like at the left it's more generic and at the right is more specific and further right overrides further left23:49
RobertBergerBTW the machine to use you define in local.conf23:51

Generated by 2.17.2 by Marius Gedminas - find it at!