Wednesday, 2022-04-06

*** GLumen_ <GLumen_!> has quit IRC (Ping timeout: 246 seconds)00:02
*** leon-anavi <leon-anavi!~Leon@> has quit IRC (Quit: Leaving)00:08
*** sakoman <sakoman!> has quit IRC (Quit: Leaving.)00:21
*** qschulz <qschulz!> has quit IRC (Remote host closed the connection)00:32
*** qschulz <qschulz!> has joined #yocto00:35
*** lowfi <lowfi!~lowfi@user/lowfi> has joined #yocto00:47
*** troth <troth!> has quit IRC (Ping timeout: 248 seconds)00:50
*** troth <troth!> has joined #yocto01:05
*** sakoman <sakoman!> has joined #yocto01:07
*** starblue <starblue!> has quit IRC (Ping timeout: 248 seconds)01:11
*** starblue <starblue!> has joined #yocto01:13
*** kevinrowland <kevinrowland!~kevinrowl@> has quit IRC (Quit: Client closed)01:17
*** troth <troth!> has quit IRC (Ping timeout: 248 seconds)01:20
*** troth <troth!> has joined #yocto01:27
*** lowfi <lowfi!~lowfi@user/lowfi> has quit IRC (Quit: Leaving)01:44
*** troth <troth!> has quit IRC (Ping timeout: 260 seconds)01:51
*** troth <troth!> has joined #yocto02:09
*** xmn <xmn!> has quit IRC (Ping timeout: 246 seconds)02:10
*** jclsn0 <jclsn0!> has joined #yocto03:00
*** jclsn <jclsn!> has quit IRC (Ping timeout: 246 seconds)03:02
*** sakoman <sakoman!> has quit IRC (Quit: Leaving.)03:12
*** troth <troth!> has quit IRC (Ping timeout: 268 seconds)03:25
*** troth <troth!> has joined #yocto03:36
*** Circuitsoft <Circuitsoft!> has quit IRC (Quit: Connection closed for inactivity)04:03
*** troth <troth!> has quit IRC (Ping timeout: 240 seconds)04:31
*** rfried <rfried!> has quit IRC (Quit: Ping timeout (120 seconds))04:39
*** rfried <rfried!> has joined #yocto04:39
*** prabhakarlad <prabhakarlad!> has joined #yocto04:45
*** troth <troth!> has joined #yocto04:48
*** dti is now known as dtometzki04:49
*** prabhakarlad <prabhakarlad!> has quit IRC (Ping timeout: 250 seconds)04:52
*** prabhakarlad <prabhakarlad!> has joined #yocto04:57
*** mvlad <mvlad!~mvlad@2a02:2f08:4114:c500:24d7:51ff:fed6:906d> has joined #yocto05:34
*** rob_w <rob_w!~rob@2001:a61:60c9:601:2dae:3828:a9e3:5e84> has joined #yocto06:01
LetoThe2ndvvn: yeah thats why I said to put it into there.06:25
LetoThe2ndRP: i know, i asked, and i am thankful for the answer, even if it makes me unhappy :-/06:26
LetoThe2ndyo dudX06:26
*** simonew <simonew!> has joined #yocto06:36
*** kroon <kroon!> has joined #yocto06:40
kayterina[m]Hello. What happens if I use variable D in FILES?06:46
kayterina[m]I know it does not include the script, but why?06:46
*** mckoan|away is now known as mckoan06:47
mckoangood morning06:47
LetoThe2ndkayterina[m]: I'd guess that is because the ${D} path is the absolute host path, and FILES is relative to the resulting rootfs. And that usually long path just does not exist on your output rootfs.06:49
*** simonew <simonew!> has quit IRC (Ping timeout: 250 seconds)06:57
kayterina[m]$IMAGE_ROOTFS is the resulting rootfs path?07:03
*** huseyinkozan <huseyinkozan!~hk@> has joined #yocto07:05
*** frieder <frieder!> has joined #yocto07:07
kayterina[m]and how do I see that FILES or any other variable is relative to some directory?07:08
*** simonew <simonew!~simonew@> has joined #yocto07:12
*** Schlumpf <Schlumpf!~Schlumpf@> has joined #yocto07:24
*** dev1990 <dev1990!> has joined #yocto07:37
*** leon-anavi <leon-anavi!~Leon@> has joined #yocto07:41
*** alejandrohs <alejandrohs!~alejandro@user/alejandrohs> has quit IRC (Ping timeout: 268 seconds)07:44
qschulzkayterina[m]: I guess this is something we could add to the documentation07:45
*** goliath <goliath!~goliath@user/goliath> has joined #yocto07:47
*** dlan <dlan!~dennis@gentoo/developer/dlan> has quit IRC (Quit: leaving)07:59
*** dlan <dlan!~dennis@gentoo/developer/dlan> has joined #yocto07:59
qschulzamahnui[m]: please be careful when you send patches that you only send it once. If you modify a patch and want to send a new version, please use git send-email -v2 or git format-patch -v208:04
qschulz(or v3, v4, etc... and explain just below the three dashes what changed between v1 and v2, v2 and v3, etc...)08:05
*** alejandrohs <alejandrohs!~alejandro@user/alejandrohs> has joined #yocto08:06
*** dacav <dacav!> has joined #yocto08:14
*** rperier <rperier!> has quit IRC (Remote host closed the connection)08:24
*** rperier <rperier!> has joined #yocto08:25
*** Belgarion <Belgarion!> has quit IRC (Ping timeout: 256 seconds)08:25
*** Belgarion <Belgarion!> has joined #yocto08:26
*** OutBackDingo <OutBackDingo!~quassel@> has quit IRC (Read error: Connection reset by peer)08:26
*** OutBackDingo <OutBackDingo!~quassel@> has joined #yocto08:27
*** frosteyes <frosteyes!~frosteyes@> has quit IRC (Ping timeout: 272 seconds)08:27
*** frosteyes <frosteyes!~frosteyes@> has joined #yocto08:28
*** GNUmoon <GNUmoon!~GNUmoon@gateway/tor-sasl/gnumoon> has quit IRC (Ping timeout: 240 seconds)08:28
*** mvlad_ <mvlad_!~mvlad@2a02:2f08:4114:c500:24d7:51ff:fed6:906d> has joined #yocto08:28
*** mvlad <mvlad!~mvlad@2a02:2f08:4114:c500:24d7:51ff:fed6:906d> has quit IRC (Remote host closed the connection)08:28
*** vladest <vladest!~Thunderbi@2001:1715:9d9c:c530:d6d6:7366:5da8:23b6> has quit IRC (Remote host closed the connection)08:31
*** GNUmoon <GNUmoon!~GNUmoon@gateway/tor-sasl/gnumoon> has joined #yocto08:31
*** vladest <vladest!~Thunderbi@2001:1715:9d9c:c530:3521:88ed:77f9:87e8> has joined #yocto08:31
* RP just came across a patch from 2017 trying to fix tinfoil's wait_event. 5 years later we might have got there!08:45
LetoThe2ndRP: oatch hard and patch fast!08:46
*** simonew <simonew!~simonew@> has quit IRC (Quit: Client closed)08:55
*** simonew <simonew!~simonew@> has joined #yocto08:57
*** lexano <lexano!~lexano@> has quit IRC (Ping timeout: 246 seconds)09:01
*** florian_kc <florian_kc!> has joined #yocto09:10
*** Emantor_ <Emantor_!> has quit IRC (Quit: ZNC -
*** lexano <lexano!~lexano@> has joined #yocto09:14
*** Emantor <Emantor!> has joined #yocto09:14
*** florian <florian!> has joined #yocto09:17
amahnui[m]qschulz: I'm really sorry about that. I was using git format -v2 but somehow it was not reflecting on the list.09:31
amahnui[m]I will make sure to do so in the subsequent patches. Thanks09:31
dirtyflagi need to get executed a bbappend only for one machine, without throwing errors for other, what's the proper way ?09:36
qschulzamahnui[m]: how did you sent the mail after running git format-patch?09:38
qschulzdirtyflag: you can't09:38
qschulzdirtyflag: only way to do it is to have machine specific variables in your bbappend09:38
qschulz(c.f. OVERRIDES/MACHINEOVERRIDES and override syntax)09:39
dirtyflagqschulz: ok thanks. So in a do_deploy() i can check MACHINE ?09:39
amahnui[m]qschulz:  I ran `git send-email -1 --to`09:39
qschulzamahnui[m]: yeah that's incorrect09:39
dirtyflagthanks a lot09:39
qschulzdirtyflag: you can have: do_deploy_machine09:40
dirtyflagi see. thanks !09:40
qschulzamahnui[m]: two ways: git send-email -1 -v2 ...09:40
qschulzamahnui[m]: or git format-patch -v2 .. + git send-email *.patch ...09:40
qschulzamahnui[m]: to be fair, git is not very user friendly :)09:41
amahnui[m]qschulz: Thanks a lot for the clarification, I will make sure to that using either of this commands you sent.09:42
*** Schiller <Schiller!> has joined #yocto09:57
SchlumpfHi, does anybody have seen bitbake BrokenPipeErrors in at hatdknott?10:02
*** prabhakarlad <prabhakarlad!> has quit IRC (Quit: Client closed)10:08
*** starblue <starblue!> has quit IRC (Ping timeout: 260 seconds)10:15
*** starblue <starblue!> has joined #yocto10:17
Saur[m]amahnui: I recommend using the second variant suggested by qschulz  above as that allows you edit the patch files before they are sent, e.g., to be able to add comments (after the line with three dashes "---"), which is especially useful when sending updated patches to inform what has changed compared to the previous version of the patches.10:20
*** Schlumpf <Schlumpf!~Schlumpf@> has quit IRC (Quit: Client closed)10:20
*** Schlumpf <Schlumpf!~Schlumpf@> has joined #yocto10:21
amahnui[m]Saur: Thanks a lot I think that is what I will go for.10:28
qschulzamahnui[m]: don't forget to use subdirectories or remove patches between git send-email executions or you'll send all patches (if you use *.patch) and not only the ones you wanted to send now10:34
LetoThe2ndI'm seeing gdk-pixbuf failing on master for riscv. Anybody aware of problems there?10:39
rburtonkhem is my go-to for riscv10:40
amahnui[m]qschulz: I'm sorry I don't understand since I never had an option to pass the specific patch I'm sending. Please could you explain more?10:40
LetoThe2ndrburton: yeah sure, but I (usually) don't pester the VIPs unless I have asked the commons :)10:41
qschulzamahnui[m]: when you use *.patch, the shell will expand this to all files currently listed in the current directory, which ends with .patch10:41
qschulzif you do not remove the patch from v1 when you want to send a v2, then you'll send both v1 and v2 patches, because *.patch will match both10:41
qschulze.g.: git format-patch -1 && git send-email *.patch && git format-patch -1 -v2 && git send-email *.patch, will send the v1 patch twice10:42
rburtonfwiw, this is why i rarely bother with the format-patch/send-email split unless needed10:43
LetoThe2ndand to be honest, this doesn't exactly sound like a riscv-only thing: (glib-compile-resources:2605920): GLib-GObject-CRITICAL **: 10:36:14.842: g_object_unref: assertion 'G_IS_OBJECT (object)' failed10:44
LetoThe2nd../gdk-pixbuf-2.42.6/tests/resources.gresource.xml: Failed to close file descriptor for child process (Operation not permitted).y10:44
amahnui[m]qschulz: Oh okay I understand you clearly now. I remember seeing that on one of the patches I sent which conatined 2 patches instead of 1 patch on the maling list.10:46
amahnui[m]I will do that 🙏10:46
qschulzrburton: I like it this way because I do a last minute check of the commit and I'm also entirely sure of what's being sent10:47
qschulzbut to each their own workflow :)10:47
rburtoni use 'git show' for that10:47
rburtonyeah, each to their own :)10:47
*** troth <troth!> has quit IRC (Ping timeout: 246 seconds)10:56
amahnui[m]rburton: I just ran git show on my command line and it showed the most recent change I made and some very useful information too. I will use this command  as well so that I will use the format-patch command when I finally think the patch is ready to be submitted10:56
*** LocutusOfBorg <LocutusOfBorg!> has quit IRC (Quit: ZNC 1.8.2+deb1 -
*** LocutusOfBorg <LocutusOfBorg!> has joined #yocto11:01
*** prabhakarlad <prabhakarlad!> has joined #yocto11:02
*** troth <troth!> has joined #yocto11:11
*** amitk_ <amitk_!~amit@> has joined #yocto11:11
*** amitk <amitk!~amit@> has quit IRC (Ping timeout: 268 seconds)11:14
*** simonew <simonew!~simonew@> has quit IRC (Quit: Client closed)11:14
JaMarburton: new progressbar for stalled tasks works great :)11:24
JaMaNOTE: recipe ltp-20220121-r0: task do_rm_work: Succeeded11:24
JaMaBitbake still alive (no events for 600s). Active tasks:11:24
JaMaBitbake still alive (no events for 1200s). Active tasks:11:24
*** ChanServ sets mode: +o ndec11:27
*** ndec changes topic to ""Welcome to the Yocto Project | Learn more: | Join us or Speak at Yocto Project Summit (2022.05) May 17 - 19, more: | Join the community: | IRC logs available at | Having difficulty on the list or with someone on the list, contact YP community mgr ndec""11:28
ndechi there.. in case you missed the noise on Twitter and LinkedIn.. be aware that we will have our next YP Summit in May, more at We have opened the CFP for now, will open registration shortly.11:29
*** Tyaku <Tyaku!> has joined #yocto11:31
TyakuHi, I am using Yocto to create an image for RaspberryPI3. The image is using meta-raspberrypi. Currently I am stuck with two things: I'm not able to integrate the SPI, and i'm also not able to get the serial console working.11:32
TyakuIn my local.conf I set this: ENABLE_UART = "1" and ENABLE_SPI_BUS = "1"11:33
TyakuWhen the linux boot, nothing get out on serial line. And I don't have /dev/spixxx devices. I try to enable the modules but no changes11:34
rburtonagherzan: ^^^ meta-rpi question for you11:36
*** simonew <simonew!~simonew@2a01:c23:c55b:1100:85eb:b39d:d4bc:e97d> has joined #yocto11:39
*** Schiller <Schiller!> has quit IRC (Quit: Client closed)11:41
*** prabhakarlad <prabhakarlad!> has quit IRC (Quit: Client closed)11:43
*** bps2 <bps2!~bps@> has joined #yocto11:54
agherzanTyaku: is that a rpi3 or cm3?11:55
agherzanAlso, what version of meta-raspberrypi are you using?11:56
*** bps <bps!~bps@user/bps> has quit IRC (Ping timeout: 268 seconds)11:57
agherzanAre you using uboot, if yes, can you try without it?11:58
TyakuIt's a raspberry pi3, I found something interesting: When I flash a SDCard it works ! When I use the network boot, then the serial console is not working and spidev is not created !12:14
TyakuOh, I just see that I can't cat /boot when using network boot. So there is something wrong in my /etc/fstab I think12:14
TyakuI think there is something wrong with the NFS, So the problem is not related to meta-raspberry (Jesus)12:18
*** prabhakarlad <prabhakarlad!> has joined #yocto12:28
vvnrburton: hi! Regarding our previous conversation, I think the machine configuration is also an integration point for hardware-specific packages since in practice a product will likely need a custom one instead of using a generic one (i.e. to integrate the bootloader of choice, preferred providers, encryption, some hardware acceleration drivers, etc.)12:35
vvnSo in theory one could build an image for a generic machine, but a complete product would likely require a custom distro as well as custom machine configurations (and likely custom images). Would you agree?12:39
*** Schlumpf <Schlumpf!~Schlumpf@> has quit IRC (Quit: Client closed)12:46
*** simonew <simonew!~simonew@2a01:c23:c55b:1100:85eb:b39d:d4bc:e97d> has quit IRC (Ping timeout: 250 seconds)12:46
*** simonew <simonew!~simonew@2a01:c22:726b:5c00:5fd:8563:7368:2e3b> has joined #yocto13:08
*** simonew <simonew!~simonew@2a01:c22:726b:5c00:5fd:8563:7368:2e3b> has quit IRC (Client Quit)13:09
jclsn[m]Does anyone has experience with mirroring source repos to Artifactory? Seems like you need an ftp server, which I am not sure Artifactory provides13:17
*** ar__ <ar__!~akiCA@user/akica> has joined #yocto13:19
jclsn[m]I only can PUT and GET files with curl.13:20
*** codavi <codavi!~akiCA@user/akica> has joined #yocto13:21
jclsn[m]Seems like I have to pull the tarballs with a shell script before building hmm13:22
*** ar__ <ar__!~akiCA@user/akica> has quit IRC (Ping timeout: 268 seconds)13:24
*** xmn <xmn!> has joined #yocto13:25
*** kroon <kroon!> has quit IRC (Quit: Leaving)13:26
*** goliath <goliath!~goliath@user/goliath> has quit IRC (Quit: SIGSEGV)13:30
landgrafjclsn[m]: ?13:31
*** simonew <simonew!~simonew@2a01:c22:726b:5c00:5fd:8563:7368:2e3b> has joined #yocto13:37
*** bps3 <bps3!~bps@> has joined #yocto13:37
*** bps2 <bps2!~bps@> has quit IRC (Ping timeout: 240 seconds)13:40
rfs613To share the downloads directory across multiple local yocto trees, is there a difference between setting DL_DIR in each (local.conf etc) versus making "downloads" a symlink? eg. what is the recommended approach, if any?13:44
qschulzrfs613: if you set DL_DIR correctly, there's no manual step required (the symlinking)13:45
*** simonew <simonew!~simonew@2a01:c22:726b:5c00:5fd:8563:7368:2e3b> has quit IRC (Quit: Client closed)13:46
qschulzrfs613: and since you should do the same for SSTATE_DIR, it's two steps less than doing the symlinking manually :)13:46
rfs613is this a reasonable use for auto.conf or site.conf ?13:46
rburtonyou could put it in site.conf13:47
rburtonsite.conf works well if you have a eg company-wide layer13:47
rburtonso it can set proxies, central mirrors, etc13:47
rfs613ok thanks. I noticed that bitbake uses os.path.normpath() in some places, which is known to break symlinks.13:50
rfs613so I guess that's another reason to use DL_DIR / SSTATE_DIR13:50
vvnqschulz: do you know if downstream users of AGL define their own machine configuration files or if they use the upstream ones solely?13:50
qschulzvvn: is this question really aimed at me?13:51
*** sakoman <sakoman!> has joined #yocto13:57
smurrayvvn: AGL upstream supports various dev boards, anyone doing a product pretty much would have to have their own BSP with a machine for their custom h/w (even if it's somewhat minimal to provide a devicetree + kernel config on top of the silicon vendor's BSP)13:58
vvnqschulz: oops nope it was for smurray, sorry.13:59
qschulzvvn: no worries, was surprised because I never played with AGL before :D14:00
vvnsmurray: so adding a custom foo.conf machine which requires a vendor bsp is somewhat common I assume14:02
smurrayvvn: yes14:03
vvnsmurray: how does AGL deal with adding support for a vendor BSP, does it use custom machine configurations too or does it use overrides extensively?14:03
*** simonew <simonew!~simonew@2a01:c22:726b:5c00:5fd:8563:7368:2e3b> has joined #yocto14:05
smurrayvvn: there are no custom machine configurations in upstream (*), AGL upstream only targets dev boards that (at least so far) have existing machine .conf's in vendor BSPs14:05
*** Minvera <Minvera!~Minvera@user/Minvera> has joined #yocto14:06
smurrayvvn: the * is that we do carry some tweaks to vendor BSPs to e.g. consistently enable some kernel configs and fix wayland configuration issues14:06
*** simonew <simonew!~simonew@2a01:c22:726b:5c00:5fd:8563:7368:2e3b> has quit IRC (Client Quit)14:07
smurrayvvn: that's done with effectively local.conf tweaks and bbappends, and we try to avoid anything really significant14:07
smurrayvvn: and there's actually one custom machine in tree at the moment that I can think of, but it's to target a specific kernel for running in VMs with a bunch of virtio features enabled14:09
amahnui[m]Hello everyone,14:09
amahnui[m]I just wanted ask if there's any outreachy applicant in the chat I  wish to connect14:09
smurrayvvn: but for some customer engagements around AGL that I've been involved with for Konsulko, we've done what I described, a small product-specific BSP layer on top of the vendor BSP, then a corresponding distro layer14:12
amahnui[m]I also wish to ask how many cores is recommended for an 8gb ram machine when running bitbake core-image-sato14:16
amahnui[m]The machine as 8GB of RAM nad 8 cores14:17
*** bps2 <bps2!~bps@> has joined #yocto14:18
*** GLumen_ <GLumen_!> has joined #yocto14:20
*** Wouter0100 <Wouter0100!> has joined #yocto14:21
*** bps3 <bps3!~bps@> has quit IRC (Ping timeout: 260 seconds)14:21
*** goliath <goliath!~goliath@user/goliath> has joined #yocto14:23
vvnsmurray: so something like meta-<company>-bsp with a foomach.conf machine configuration file which does 'require conf/machine/beaglebone.conf' and tweaks, as well as meta-<company>-distro with a foodist.conf which customize the software stack further.14:24
*** Schiller <Schiller!> has joined #yocto14:25
amahnui[m]Please how do I call PARALLEL_MAKE  in my conf/local.conf file in the case that iit is not present there14:26
qschulzamahnui[m]: I'm not entirely certain limiting PARALLEL_MAKE in conf/local.conf would be enough (disclosure: I suggested it in private), but just set PARALLEL_MAKE="-j 4" in conf/local.conf for example14:27
smurrayvvn: yeah, something along those lines.  If the foomach machine is much different from an existing board, the .conf might be a modified copy or a from scratch written one.  There's sometimes cruft in the dev board configs you might not want to have to work to undo14:27
amahnui[m]qschulz: thanks I'll add it there rather.14:29
vvnsmurray: I see. That's what I wondering if I do well or not. In the example of meta-ti/beaglebone, the BSP machine conf is lacking many things I need (preferred drivers for hardware acceleration, different bootloader, some machine dependencies and tweaks...) but I do not want to miss an upstream fix, so require beaglebone.conf seems safe, even though it's a bit ugly...14:31
vvnI was using a custom include file to add these tweaks, but then it becomes distro specific and it is a bit more obfuscated than a custom machine config :/14:33
smurrayvvn: yeah, there can be grey areas14:36
*** goliath <goliath!~goliath@user/goliath> has quit IRC (Quit: SIGSEGV)14:38
rfs613does the autobuild run dunfell branch with meta-openembedded layer?14:41
vvnsmurray: true and it can get frustrating. Ideally a machine conf can be generic enough not to be overridden, but the reality is choosing an alternative bootloader, preferred drivers, custom boot scripts and whatnot requires a custom config and loading the distro with overrides or include files can become quickly cumbersome14:44
*** florian_kc <florian_kc!> has quit IRC (Remote host closed the connection)14:48
rfs613build #3472 seems to be dunfell-nut branch + meta-selftest layer... but I had to dig the log to find this. Is there another way to search?14:48
*** Schiller <Schiller!> has quit IRC (Quit: Client closed)14:53
jclsn[m]landgraf: I understand how authentication works for Artifactor, but I don't see how I can simply add the URL as SOURCE_MIRROR_URL.14:55
jclsn[m]Does Bitbake support that?14:55
rburtonwget will respect .netrc for authentication details14:57
*** dgriego <dgriego!~dgriego@user/dgriego> has joined #yocto15:00
*** Tyaku <Tyaku!> has quit IRC (Quit: Lost terminal)15:01
jclsn[m]Ah you can access the Artifactory repos with https. I thought it would only be possible via the REST API15:01
jclsn[m]Wonder if it can also push like this15:01
*** mckoan is now known as mckoan|away15:04
fabatera[m]Hi!... (full message at
sakomanrfs613: In general, no, most autobuilder runs don't include meta-openembedded.  Near release times I do run meta-oe tests to check that nothing is broken15:27
sakomanrfs613: khem does lots of test runs:
rfs613sakoman: that's the feeling I got after browsing around a bit. Thanks for confirming. I'm seeing some fuzz warnings from a recent CVE patch in polkit, trying to see if it shows up in autobuilder as well.15:29
landgrafjclsn[m]:  bitbake fetcher uses wget for https, wGET does GET and don't PUT just because of its name :)15:31
Saur[m]fabatera: No, one recipe cannot affect another recipe in any way.15:32
kergothHmm, wonder if anyone else would find of use. Going through my layers for potential submissions15:34
jclsn[m]<landgraf> "jclsn:  bitbake fetcher uses..." <- Yeah I get it. So this means I have to PUT manually via a script, which shouldnt be too bad. It’s not like you have to do it every day.15:37
*** bps2 <bps2!~bps@> has quit IRC (Ping timeout: 240 seconds)15:44
rburtonzeddii: it appears that the xtf-image:testimage integration is broken in master. just tried it, and the boot appears to hang.15:47
vvnkergoth: not sure actually. It makes me think about having 'include conf/${MACHINE}-${DISTRO}.inc' upstream in meta/conf/bitbake.conf. It seems nice, but in the end too much include files and variables and overrides make the project cumbersome, and downstream machine/distro/image files to support an actual product often end up simpler and more intuitive. Just my opinion.15:48
kergothThe above bbclass just provides an explicit lever for a build to override a distro, so i don't think it's as bad as directly crossing the distro/machine/image boundaries15:49
kergothbut it's a good point15:49
*** GillesM <GillesM!> has quit IRC (Quit: Leaving)15:55
*** GillesM <GillesM!> has joined #yocto15:55
*** GillesM <GillesM!> has quit IRC (Remote host closed the connection)15:55
*** Mike23 <Mike23!> has joined #yocto15:58
*** sakoman <sakoman!> has quit IRC (Quit: Leaving.)16:05
*** sakoman <sakoman!> has joined #yocto16:09
*** manuel <manuel!~manuel@2a02:1748:dd5c:f290:c553:9012:6082:a89a> has joined #yocto16:13
manuelHi all. How can I build a yocto image with a patched initramfs? I'd like to carry this patch over to my yocto image:
vvnmanuel: it seems like this patch is meant for the initramfs-tools package. So create a recipes-devtools/initramfs-tools/initramfs-tools_%.bbappend file in your layer which adds SRC_URI += ""16:20
vvnand make sure that initramfs-tools is installed as part of whatever initramfs image you are using.16:21
manuelvvn: Makes sense, thank you. How come initramfs-tools is optional? That patch is patching some very fundamental things when booting linux (that is, mounting the rootfs and switching root into it). If initramfs-tools is not in place, what is providing this functionality then?16:26
vvnmanuel: actually initramfs-tools is just a tool from Debian used to create an initramfs image. I guess it is run on the target itself to generate /boot/linux-initramfs.img or whatever. It isn't an initramfs package per-se if I'm not mistaken, but a target package.16:29
smurrayit's not used by OE/Yocto at all that I can see16:30
vvnmanuel: (re)generating the initramfs image from the target itself is one way of doing it, but you may build it elsewhere, like core-image-minimal-initramfs. Or your own recipe.16:30
vvnsmurray: it's listed here, but I'm guessing it's not widely used :)16:31
manuelvvn: Alright, I understand. Wasn't aware this is just the Debian way of doing things. But it all makes sense. Thanks! I know how to proceed now.16:32
smurrayvvn: ah, I did look in the layer index just now, but missed it16:33
vvnmanuel: and those scripts are just one implementation for mounting the rootfs and switching to it. systemd does it on its own (if part of an initial ram disk for sure). You may have your very own script doing this manually as well.16:33
smurraymanuel: perhaps take a look at recipes-core/initrdscripts/ and the scriptlets it pulls in, that's what's used in the example initramfs images in oe-core16:33
manuelvvn, smurray: cool, will look into that. If I have a systemd system, is this initramfs-framework recipe getting used or whatever systemd comes up with?16:39
vvnmanuel: totally up to you. If you want a full systemd stack, you may set INITRAMFS_SCRIPTS = "systemd-initramfs" and INITRAMFS_IMAGE = "core-image-minimal-initramfs" in your local.conf or distro.16:40
smurrayvvn: btw, did you happen to get an expired certificate warning from
vvnsmurray: nope16:51
smurrayvvn: hrm, okay16:51
*** Mike23 <Mike23!> has quit IRC (Quit: Client closed)16:51
RPzeddii: do you use any systems with make 4.2.1 for testing the kernel builds?16:55
smurrayhalstead: sort of looks like the SSL cert on expired about an hour and a half ago16:56
* rfs613 builds kernels with make 4.2.1 16:56
RPrfs613: we're seeing hangs occasionally with it :/16:57
*** ecdhe <ecdhe!~ecdhe@user/ecdhe> has joined #yocto16:57
*** florian <florian!> has quit IRC (Quit: Ex-Chat)16:58
rfs613RP: hmm, interesting - I've not seen any hang FWIW. I typically do a dozen builds when I am rebasing LTS kernels. And if I am debugging something, I may do many many more (though those are usually incremental)16:58
zeddiiRP: all my systems are Make 4.2.1 it appears17:00
RPzeddii: hmm, so how common is this bug :/17:05
vvnhaving a layer in a meta/ directory won't clash as long as the layer name is unique, right?17:06
RPrfs613: it is rare but does seem to happen on the autobuilder periodically, either in the kernel or perl17:06
JaMaLetoThe2nd: find the corresponding sigdata files and run bitbake-diffsigs on them17:06
JaMaLetoThe2nd: ups, replying to some old message17:07
*** frieder <frieder!> has quit IRC (Remote host closed the connection)17:07
* RP suspects is missing in 4.2.1 causing t17:07
rfs613RP: it seems that ubuntu-20.x has this included in their make-4.2.1 packcage17:21
rfs613which may explain why I don't see it17:21
*** vvn <vvn!> has quit IRC (Read error: Connection reset by peer)17:21
*** gsalazar <gsalazar!> has quit IRC (Ping timeout: 272 seconds)17:21
*** vvn <vvn!> has joined #yocto17:22
rfs613am looking at and specifically the make-dfsg_4.2.1-1.2.diff.gz file17:22
RPrfs613: that would explain it17:22
RPit is generally redhat systems where this shows up that don't have that17:22
RPzeddii: are yours redhat derived or debian?17:23
rfs613looks like it was patched  Wed 11 Jul 2018 according to
RPthat might help explain things but complicates a fix :/17:23
rfs613there seem to be two potential hangs, SV 51400 and SV 5115917:24
vvnDo not rest your foot on the power cord guys17:24
rfs613vvn: what about the ethernet cord? :P17:25
rfs613khem: has anyone reported issue with the recent CVE fixes for polkit in meta-openebedded?17:29
rfs613i've just figured out that two of them are colliding, which evidently results in the fuzz warning.17:30
rfs613i'll post a fix, just giving a heads up17:31
smurrayrfs613: odd, I've been doing test builds locally with meta-oe with that change (d5eef01f, I assume) and I've not seen a fuzz warning17:32
rfs613smurray: this is on dunfell, the two commits are 67ec3e04 and 17e93117:35
smurrayrfs613: ah, okay17:35
*** goliath <goliath!~goliath@user/goliath> has joined #yocto17:45
*** kevinrowland <kevinrowland!~kevinrowl@> has joined #yocto17:52
*** prabhakarlad <prabhakarlad!> has quit IRC (Quit: Client closed)18:06
halsteadsmurray: I'll look into it.18:10
smurrayhalstead: okay, thank you18:11
halsteadsmurray: I just forced the renewal. How does it look now?18:13
smurrayhalstead: looks good now, Firefox is happy18:14
smurrayhalstead: thanks!18:14
halsteadsmurray: It shouldn't need to be forced. Thank you for the ping.  We are moving this into a new system before the next renewal so it won't happen again.18:15
smurrayhalstead: cool, good to know18:15
*** huseyinkozan <huseyinkozan!~hk@> has quit IRC (Quit: Konversation terminated!)18:16
*** jmiehe <jmiehe!~Thunderbi@user/jmiehe> has joined #yocto18:17
LetoThe2ndkhem: are you aware of any gdk-pixbuf woes on kirkston/master with riscv at the moment?18:46
*** prabhakarlad <prabhakarlad!> has joined #yocto18:50
LetoThe2ndits not even riscv related, but it completely falls over, even for qemux8618:54
*** mvlad_ <mvlad_!~mvlad@2a02:2f08:4114:c500:24d7:51ff:fed6:906d> has quit IRC (Remote host closed the connection)18:56
*** jmiehe <jmiehe!~Thunderbi@user/jmiehe> has quit IRC (Quit: jmiehe)19:22
vvnif you're bsp relies on systemd-cryptsetup to boot an encrypted rootfs, is it ok to have PACKAGECONFIG:append = " cryptsetup" in a systemd_%.bbappend file in both the BSP and distro layers?19:25
*** kevinrowland <kevinrowland!~kevinrowl@> has quit IRC (Quit: Client closed)19:39
*** kevinrowland <kevinrowland!~kevinrowl@> has joined #yocto19:43
*** prabhakarlad <prabhakarlad!> has quit IRC (Quit: Client closed)19:44
*** amitk_ <amitk_!~amit@> has quit IRC (Ping timeout: 268 seconds)19:47
*** mrnuke <mrnuke!~mrnuke@2601:2c1:8501:182d::c66> has quit IRC (Ping timeout: 260 seconds)20:17
*** mrnuke <mrnuke!> has joined #yocto20:24
*** leon-anavi <leon-anavi!~Leon@> has quit IRC (Remote host closed the connection)20:33
smurrayvvn: to me that's a distro thing, ideally the BSP doesn't care if a distro uses sysvinit, systemd, or something else20:35
vvnsmurray: true, but I'm writing an initrd service for systemd to create the root subvolume if it doesn't exist (we can't do that via the .wks file). Without it the boot obviously fails. I'm not sure where this recipe belongs :/20:38
smurrayvvn: I'd still argue the selection of systemd and using cryptsetup are distro choices.  But I realize in practice it can be easier to blend things together, and tbh it's not the end of the world IMO if it's for your own product and unlikely to need that flexibility20:43
vvnsmurray: no but you're totally right. The confusing thing is that the bsp in fact *requires* a specific distro crafted for it, i.e. systemd + cryptsetup + musl (if such light libc works). While the rootfs may honor the principle of orthogonal machine/distro/image20:45
vvnsmurray: like would it make sense to have poky-initramfs.conf or poky-altcfg-initramfs.conf for instance?20:47
smurrayvvn: to do something along the lines of ?20:51
vvnsmurray: exactly20:52
smurrayvvn: usually I'd expect the initramfs to not have enough in it that it'd need a full new distro conf20:52
smurrayvvn: but I've defined convenience machines and distros for somewhat similar multiconfig stuff for containers, so I could see doing it that way20:53
vvnsmurray: a distro conf for it my be handy to remove DISTRO_FEATURES and override some PACKAGECONFIG, otherwise it can be complicated since the distro conf is read after the multiconfig20:55
vvnI mean that DISTRO_FEATURES:remove in the INITRAMFS_MULTICONFIG might not work if the distro is appending features20:55
smurrayvvn: yeah, I could see that.  I guess I've never encountered an initramfs with enough stuff in it that it mattered20:56
vvnsmurray: I'm currently building the initramfs with my normal distro (glibc) and it works fine. With INITRAMFS_MULTICONFIG and forcing the distro in there my bsp will continue to work with any distro/image combination for the rootfs. Such "light" distro variant might just be handy to speed things up a bit, but absolutely not mandatory.20:58
smurrayvvn: yeah21:00
vvnI will encounter the same problem actually for containers and portable services, preferring linux-dummy for the kernel...21:02
smurrayheh, indeed.  I've done both overriding the PREFERRED_PROVIDER in the mulitconfig .conf and just doing it with a derived "container" machine .conf21:04
vvnsmurray: do you have a preferred approach?21:05
*** Minvera <Minvera!~Minvera@user/Minvera> has quit IRC (Remote host closed the connection)21:05
vvnSo far I think that for the end product, being explicit and defining such alternative distro and machine would help, instead of cluttering some multiconfig or the local.conf21:06
smurrayvvn: for AGL I settled on doing it in the container multiconfig(s) with a PREFERRED_PROVIDER overide there because it's so far been easier to support building for a handful of different MACHINEs that way21:06
*** sakoman <sakoman!> has quit IRC (Quit: Leaving.)21:07
vvnindeed, you need to scale easily and not duplicate all distro and machine configs everytime you have a new board variant21:08
smurrayvvn: on thing I'll note is that vendor BSPs sometimes have implicit dependencies on their kernel (usually for custom headers for userspace stuff they want to pull in)21:08
smurrayerr, one21:09
*** rob_w <rob_w!~rob@2001:a61:60c9:601:2dae:3828:a9e3:5e84> has quit IRC (Quit: Leaving)21:10
*** camus1 <camus1!~Instantbi@2409:8a1e:911c:7f00:704b:4b0d:8dc4:7c21> has joined #yocto21:57
*** camus <camus!~Instantbi@2409:8a1e:9115:e190:704b:4b0d:8dc4:7c21> has quit IRC (Ping timeout: 268 seconds)22:00
*** camus1 is now known as camus22:00
*** codavi <codavi!~akiCA@user/akica> has quit IRC (Ping timeout: 246 seconds)22:04
amahnui[m]Hello everyone, Everytime I run `bitbake core-image-sato`, The process gets stuck at 44%  `Initialising tasks:  44% |#################                      | ETA:  0:00:03` and I dont know why it does so. I clone another poky repo and tried again but I ended up with this Please how do I do to make it work.22:21
vvnamahnui[m]: you might try to restart the build from scratch by removing the build/ directory and start again22:29
amahnui[m]vvn: Thanks I will try that out as well22:32
vvnsmurray: do you consider the base-files bbappend providing a machine fstab to reside in the distro layer as well, or the bsp?22:34
*** davidinux <davidinux!~davidinux@> has quit IRC (Ping timeout: 246 seconds)22:35
smurrayvvn: probably distro, but it could be messy.  Some of this comes down to just how likely you are to be actually building the distro for different machines, really22:37
vvnsmurray: currently only one hardware but will likely have different platforms in the near future (getting rid of the beaglebone slowly)22:39
smurrayvvn: but if I'm given a BSP that forces a specific partition scheme, I'd personally consider it broken unless there's some h/w reason for it.  There are vendor BSPs that end up there because they basically are decreeing a partition scheme compatible with booting Android with a bunch of small partitions for bootloader bits22:40
vvnthat was the point of using openembedded in fact22:40
smurraysome of this can be handled by using machine overrides in the distro layer22:41
smurrayor BBFILES_DYNAMIC to add bbappends driven by the presence of BSP layers22:42
vvnhum, crypttab is very machine specific but fstab can be generic (/dev/mapper/foo is used).22:43
vvnsmurray: yeah it's always either the bbappend lives in the bsp layer with :foomach overrides or in the distro layer with :foodist:foomach overrides22:44
smurrayat the end of the day I'd probably get it working on the one machine, and be prepared to do some rework when you do get around to resuing it on another22:44
smurrayerr, reusing22:44
kevinrowlandcan I search IRC archives somehow? I know in the past I've asked about doing something like `devtool deploy-target` but without the whole `devtool` part.. can't find the discussion :|22:46
smurraythe log location is mentioned in the channel header22:46
vvnkevinrowland: literally googling yocto irc archives ;)
vvn/topic as well indeed22:47
kevinrowlandI meant search _programmatically_. grep I guess would've been a better verb22:47
kevinrowlandI clicked through to some days where I thought the conversation occurred but couldn't find it22:48
*** BhsTalel <BhsTalel!~BhsTalel@> has joined #yocto22:48
vvnkevinrowland: google this: "devtool deploy-target site:"22:48
kevinrowlandoh, yes, of course :)  plus my username, I should be able to find it22:48
*** dev1990 <dev1990!> has quit IRC (Quit: Konversation terminated!)22:49
*** Wouter0100 <Wouter0100!> has quit IRC (Read error: Connection reset by peer)22:51
*** Wouter0100 <Wouter0100!> has joined #yocto22:51
vvnsmurray: the more it goes, the more I see this as "Does it end up in the final rootfs? If yes, distro layer, otherwise bsp layer".22:53
BhsTalelHello everyone, sorry if I interrupted a ongoing discussion, but I reached this Yocto IRC to ask about how to contribute to Yocto core (bitbake, poky layers, etc), I already asked the question in the mailing list of Yocto, but I want to understand more the flow. Thanks22:53
*** sakoman <sakoman!> has joined #yocto22:54
smurrayBhsTalel: the links here might help you:
vvnBhsTalel: no need to apologize, that's the point of a channel ;-)22:56
smurrayvvn: maybe?  If e.g. /boot is in the rootfs it may complicate that distinction22:57
vvnsmurray: what about files interpreted by both the initramfs and the rootfs, like crypttab and fstab? ;)22:57
* vvn is becoming crazy22:57
smurrayheh, as I said earlier, perhaps get it working, then come back and try adapting it to a second BSP / machine and rework it to clean things up at that point22:59
smurrayor wait for someone with a better idea than me to come on the channel ;)22:59
vvnsmurray: I am just concluding that true orthogonality between machine/distro/image is just a myth23:00
vvnsmurray: I'm pretty much there, I have working layers for my product, just never been really satisfied with the organization.23:01
smurrayvvn: I think at the end of the day, one could add a whole bunch of extra configuration to machine .conf's to allow distros to parameterize things, but because so many usecases are different, nothing in that space can be easily hashed out23:06
smurrayvvn: so we end up needing to carry that extra metadata at a higher level than the plain BSP23:07
smurrayvvn: but there are others who have been doing OE a lot longer than I have that might have a different view of that23:07
*** xmn <xmn!> has quit IRC (Ping timeout: 248 seconds)23:11
*** kevinrowland <kevinrowland!~kevinrowl@> has quit IRC (Quit: Client closed)23:12
kergothI don’t think it’s a myth, but it is sometimes necessary to have an integration/product layer which pulls the pieces together and doesn’t hold to one of the orthogonal axes. But you can always implement custom features for the features variables, that’s what they’re for, machine enables a feature but the distro has to enable it also to integrate it23:26
kergothThat’s what we’ve done at mentor, added “mel-“ prefixed new bsp features in machine_features23:27
BhsTalel@vvn Can you put a brief summary for me, because I did not catch the topic history.23:29
vvnBhsTalel: just discussing the grey area of the yocto design: machine/distro/image are orthogonal, meaning that if you do your job well and still have hair to pull out, you must be able to build any combination of the three.23:31
kergothIt’s common to fuzz the boundaries due to schedule constraints, if not ideal23:32
*** goliath <goliath!~goliath@user/goliath> has quit IRC (Quit: SIGSEGV)23:35
*** bps2 <bps2!> has joined #yocto23:36
BhsTalelThe way I handle the three of them is creating packagegroups that conditionally activate some recipes based on DISTRO_FEATURES that are enabled/disabled in distros which are also conditionally enabled/disabled based on MACHINE_FEATURES, for example, if rs485 machine feature is enabled, then the rs485 distro feature is enabled and finally the23:37
BhsTalelpackagegroup-rs485 get enabled in a generic packagegroup that is included in all of my images.23:37
vvnkergoth: for the context, my product is based on meta-ti's beaglebone, where I use a different bootloader, an update framework, and an encrypted rootfs partition which requires a specific systemd service. Ideally I would like to be able to build my distro, or poky, or any distro with this BSPs. I ended up creating a custom machine configuration which requires conf/machine/beaglebone.conf and juggle23:37
vvnwith recipes between meta-bsp/recipes-core and meta-distro/recipes-bsp.23:37
vvnYou often end up with distro-specific machine and machine-specific distros, in contrary to the ideal generic swappable approach23:39
amahnui[m]<BhsTalel> "Hello everyone, sorry if I..." <- Hi BhsTalel are you an applicant too?23:39
*** bonalais <bonalais!> has joined #yocto23:41
BhsTalelamahnui[m] I did not get the meaning, sorry my english is not that perfect. Did you mean I am a Yocto engineer ?23:42
vvnBhsTalel: for example with an encrypted rootfs, which is a "distro" design, but with a huge impact on the machine (.wks file, initramfs, services, crypttab, key management and so on), do you define custom features?23:42
*** kevinrowland <kevinrowland!~kevinrowl@> has joined #yocto23:42
amahnui[m]BhsTalel: No I meant outreachy applicant23:42
BhsTalelvvn I would create new feature that handles all of an encrypted rootfs and depends on a specific wks format, I am not seeing a problem between creating new distro feature and handling a wks file23:47
BhsTalelamahnui[m] I'm not getting your point yet, sorry =(23:48
*** Starfoxxes <Starfoxxes!~Starfoxxe@2a02:8070:5390:d00:12bf:48ff:feb8:38c8> has quit IRC (Ping timeout: 252 seconds)23:50
*** Starfoxxes <Starfoxxes!~Starfoxxe@2a02:8070:5390:d00:12bf:48ff:feb8:38c8> has joined #yocto23:51
vvnBhsTalel: so let's say you have a luks+btrfs rootfs partition, you would add a custom "luks" and "btrfs" machine feature and respective distro feature, and e.g. enabling a given service in the initramfs image if COMBINED_FEATURES includes "luks" and "btrfs". Same for WKS_FILE = "${@bb.utils.contains('COMBINED_FEATURES', ..., 'encrypted.wks', 'classic.wks'... Something like that?23:54
amahnui[m]<BhsTalel> "amahnui I'm not getting your..." <- BhsTalel: I thought you might be part of outreachy as I am part of it as well but its okay though. I guess your'e not. sorry for bothering23:58

Generated by 2.17.2 by Marius Gedminas - find it at!