| *** GLumen_ <GLumen_!~Gregory@97-126-1-223.tukw.qwest.net> has quit IRC (Ping timeout: 246 seconds) | 00:02 | |
| *** leon-anavi <leon-anavi!~Leon@46.55.231.62> has quit IRC (Quit: Leaving) | 00:08 | |
| *** sakoman <sakoman!~steve@dhcp-72-253-6-214.hawaiiantel.net> has quit IRC (Quit: Leaving.) | 00:21 | |
| *** qschulz <qschulz!~weechat@ns326003.ip-37-187-106.eu> has quit IRC (Remote host closed the connection) | 00:32 | |
| *** qschulz <qschulz!~weechat@ns326003.ip-37-187-106.eu> has joined #yocto | 00:35 | |
| *** lowfi <lowfi!~lowfi@user/lowfi> has joined #yocto | 00:47 | |
| *** troth <troth!~troth@c-24-8-35-226.hsd1.co.comcast.net> has quit IRC (Ping timeout: 248 seconds) | 00:50 | |
| *** troth <troth!~troth@c-24-8-35-226.hsd1.co.comcast.net> has joined #yocto | 01:05 | |
| *** sakoman <sakoman!~steve@dhcp-72-253-6-214.hawaiiantel.net> has joined #yocto | 01:07 | |
| *** starblue <starblue!~juergen@dslb-188-109-107-144.188.109.pools.vodafone-ip.de> has quit IRC (Ping timeout: 248 seconds) | 01:11 | |
| *** starblue <starblue!~juergen@dslb-094-221-183-068.094.221.pools.vodafone-ip.de> has joined #yocto | 01:13 | |
| *** kevinrowland <kevinrowland!~kevinrowl@165.225.243.0> has quit IRC (Quit: Client closed) | 01:17 | |
| *** troth <troth!~troth@c-24-8-35-226.hsd1.co.comcast.net> has quit IRC (Ping timeout: 248 seconds) | 01:20 | |
| *** troth <troth!~troth@c-24-8-35-226.hsd1.co.comcast.net> has joined #yocto | 01:27 | |
| *** lowfi <lowfi!~lowfi@user/lowfi> has quit IRC (Quit: Leaving) | 01:44 | |
| *** troth <troth!~troth@c-24-8-35-226.hsd1.co.comcast.net> has quit IRC (Ping timeout: 260 seconds) | 01:51 | |
| *** troth <troth!~troth@c-24-8-35-226.hsd1.co.comcast.net> has joined #yocto | 02:09 | |
| *** xmn <xmn!~xmn@cpe-72-225-198-203.nyc.res.rr.com> has quit IRC (Ping timeout: 246 seconds) | 02:10 | |
| *** jclsn0 <jclsn0!~jclsn@95.163.161.178.dynamic-pppoe.dt.ipv4.wtnet.de> has joined #yocto | 03:00 | |
| *** jclsn <jclsn!~jclsn@149.233.143.255.dynamic-pppoe.dt.ipv4.wtnet.de> has quit IRC (Ping timeout: 246 seconds) | 03:02 | |
| *** sakoman <sakoman!~steve@dhcp-72-253-6-214.hawaiiantel.net> has quit IRC (Quit: Leaving.) | 03:12 | |
| *** troth <troth!~troth@c-24-8-35-226.hsd1.co.comcast.net> has quit IRC (Ping timeout: 268 seconds) | 03:25 | |
| *** troth <troth!~troth@c-24-8-35-226.hsd1.co.comcast.net> has joined #yocto | 03:36 | |
| *** Circuitsoft <Circuitsoft!uid393878@id-393878.lymington.irccloud.com> has quit IRC (Quit: Connection closed for inactivity) | 04:03 | |
| *** troth <troth!~troth@c-24-8-35-226.hsd1.co.comcast.net> has quit IRC (Ping timeout: 240 seconds) | 04:31 | |
| *** rfried <rfried!~rfried@practical-trainings.com> has quit IRC (Quit: Ping timeout (120 seconds)) | 04:39 | |
| *** rfried <rfried!~rfried@practical-trainings.com> has joined #yocto | 04:39 | |
| *** prabhakarlad <prabhakarlad!~prabhakar@pc.renesas.eu> has joined #yocto | 04:45 | |
| *** troth <troth!~troth@c-24-8-35-226.hsd1.co.comcast.net> has joined #yocto | 04:48 | |
| *** dti is now known as dtometzki | 04:49 | |
| *** prabhakarlad <prabhakarlad!~prabhakar@pc.renesas.eu> has quit IRC (Ping timeout: 250 seconds) | 04:52 | |
| *** prabhakarlad <prabhakarlad!~prabhakar@pc.renesas.eu> has joined #yocto | 04:57 | |
| *** mvlad <mvlad!~mvlad@2a02:2f08:4114:c500:24d7:51ff:fed6:906d> has joined #yocto | 05:34 | |
| *** rob_w <rob_w!~rob@2001:a61:60c9:601:2dae:3828:a9e3:5e84> has joined #yocto | 06:01 | |
| LetoThe2nd | vvn: yeah thats why I said to put it into there. | 06:25 |
|---|---|---|
| LetoThe2nd | RP: i know, i asked, and i am thankful for the answer, even if it makes me unhappy :-/ | 06:26 |
| LetoThe2nd | and | 06:26 |
| LetoThe2nd | yo dudX | 06:26 |
| *** simonew <simonew!~simonew@dynamic-095-118-095-248.95.118.pool.telefonica.de> has joined #yocto | 06:36 | |
| *** kroon <kroon!~kroon@89-253-118-72.customers.ownit.se> has joined #yocto | 06:40 | |
| kayterina[m] | Hello. What happens if I use variable D in FILES? | 06:46 |
| kayterina[m] | FILES_${PN}="${D}${sysconfdir}/init.d/myscript.sh" | 06:46 |
| kayterina[m] | I know it does not include the script, but why? | 06:46 |
| *** mckoan|away is now known as mckoan | 06:47 | |
| mckoan | good morning | 06:47 |
| LetoThe2nd | kayterina[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!~simonew@dynamic-095-118-095-248.95.118.pool.telefonica.de> has quit IRC (Ping timeout: 250 seconds) | 06:57 | |
| kayterina[m] | $IMAGE_ROOTFS is the resulting rootfs path? | 07:03 |
| *** huseyinkozan <huseyinkozan!~hk@31.223.46.138> has joined #yocto | 07:05 | |
| *** frieder <frieder!~frieder@i59F72634.versanet.de> has joined #yocto | 07:07 | |
| kayterina[m] | and how do I see that FILES or any other variable is relative to some directory? | 07:08 |
| *** simonew <simonew!~simonew@5.199.177.94> has joined #yocto | 07:12 | |
| *** Schlumpf <Schlumpf!~Schlumpf@62.157.232.203> has joined #yocto | 07:24 | |
| *** dev1990 <dev1990!~dev@dynamic-78-8-240-254.ssp.dialog.net.pl> has joined #yocto | 07:37 | |
| *** leon-anavi <leon-anavi!~Leon@46.55.231.62> has joined #yocto | 07:41 | |
| *** alejandrohs <alejandrohs!~alejandro@user/alejandrohs> has quit IRC (Ping timeout: 268 seconds) | 07:44 | |
| qschulz | kayterina[m]: I guess this is something we could add to the documentation | 07:45 |
| *** goliath <goliath!~goliath@user/goliath> has joined #yocto | 07:47 | |
| *** dlan <dlan!~dennis@gentoo/developer/dlan> has quit IRC (Quit: leaving) | 07:59 | |
| *** dlan <dlan!~dennis@gentoo/developer/dlan> has joined #yocto | 07:59 | |
| qschulz | amahnui[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 -v2 | 08: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 #yocto | 08:06 | |
| *** dacav <dacav!~dacav@h94-245-9-203.cust.a3fiber.se> has joined #yocto | 08:14 | |
| *** rperier <rperier!~quassel@234.ip-51-91-57.eu> has quit IRC (Remote host closed the connection) | 08:24 | |
| *** rperier <rperier!~quassel@234.ip-51-91-57.eu> has joined #yocto | 08:25 | |
| *** Belgarion <Belgarion!sebastian@dedi.brokenbrain.se> has quit IRC (Ping timeout: 256 seconds) | 08:25 | |
| *** Belgarion <Belgarion!sebastian@dedi.brokenbrain.se> has joined #yocto | 08:26 | |
| *** OutBackDingo <OutBackDingo!~quassel@46.23.82.140> has quit IRC (Read error: Connection reset by peer) | 08:26 | |
| *** OutBackDingo <OutBackDingo!~quassel@46.23.82.140> has joined #yocto | 08:27 | |
| *** frosteyes <frosteyes!~frosteyes@185.53.130.211> has quit IRC (Ping timeout: 272 seconds) | 08:27 | |
| *** frosteyes <frosteyes!~frosteyes@185.53.130.211> has joined #yocto | 08: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 #yocto | 08: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 #yocto | 08:31 | |
| *** vladest <vladest!~Thunderbi@2001:1715:9d9c:c530:3521:88ed:77f9:87e8> has joined #yocto | 08: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 | |
| LetoThe2nd | RP: oatch hard and patch fast! | 08:46 |
| *** simonew <simonew!~simonew@5.199.177.94> has quit IRC (Quit: Client closed) | 08:55 | |
| *** simonew <simonew!~simonew@5.199.177.94> has joined #yocto | 08:57 | |
| *** lexano <lexano!~lexano@174.119.69.134> has quit IRC (Ping timeout: 246 seconds) | 09:01 | |
| *** florian_kc <florian_kc!~florian@port-217-146-132-69.static.as20676.net> has joined #yocto | 09:10 | |
| *** Emantor_ <Emantor_!~Emantor@magratgarlick.emantor.de> has quit IRC (Quit: ZNC - http://znc.in) | 09:14 | |
| *** lexano <lexano!~lexano@174.119.69.134> has joined #yocto | 09:14 | |
| *** Emantor <Emantor!~Emantor@magratgarlick.emantor.de> has joined #yocto | 09:14 | |
| *** florian <florian!~florian@port-217-146-132-69.static.as20676.net> has joined #yocto | 09: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. Thanks | 09:31 |
| dirtyflag | i need to get executed a bbappend only for one machine, without throwing errors for other, what's the proper way ? | 09:36 |
| qschulz | amahnui[m]: how did you sent the mail after running git format-patch? | 09:38 |
| qschulz | dirtyflag: you can't | 09:38 |
| qschulz | dirtyflag: only way to do it is to have machine specific variables in your bbappend | 09:38 |
| qschulz | (c.f. OVERRIDES/MACHINEOVERRIDES and override syntax) | 09:39 |
| dirtyflag | qschulz: ok thanks. So in a do_deploy() i can check MACHINE ? | 09:39 |
| qschulz | dirtyflag: https://docs.yoctoproject.org/bitbake/bitbake-user-manual/bitbake-user-manual-metadata.html#conditional-syntax-overrides | 09:39 |
| amahnui[m] | qschulz: I ran `git send-email -1 --to openembedded-core@lists.openembedded.org` | 09:39 |
| qschulz | amahnui[m]: yeah that's incorrect | 09:39 |
| dirtyflag | thanks a lot | 09:39 |
| qschulz | dirtyflag: you can have: do_deploy_machine | 09:40 |
| dirtyflag | i see. thanks ! | 09:40 |
| qschulz | amahnui[m]: two ways: git send-email -1 -v2 ... | 09:40 |
| qschulz | amahnui[m]: or git format-patch -v2 .. + git send-email *.patch ... | 09:40 |
| qschulz | amahnui[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!~Schiller@dynamic-002-247-252-132.2.247.pool.telefonica.de> has joined #yocto | 09:57 | |
| Schlumpf | Hi, does anybody have seen bitbake BrokenPipeErrors in runqueue.py at hatdknott? | 10:02 |
| *** prabhakarlad <prabhakarlad!~prabhakar@pc.renesas.eu> has quit IRC (Quit: Client closed) | 10:08 | |
| *** starblue <starblue!~juergen@dslb-094-221-183-068.094.221.pools.vodafone-ip.de> has quit IRC (Ping timeout: 260 seconds) | 10:15 | |
| *** starblue <starblue!~juergen@dslb-094-221-183-068.094.221.pools.vodafone-ip.de> has joined #yocto | 10: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@62.157.232.203> has quit IRC (Quit: Client closed) | 10:20 | |
| *** Schlumpf <Schlumpf!~Schlumpf@62.157.232.203> has joined #yocto | 10:21 | |
| amahnui[m] | Saur: Thanks a lot I think that is what I will go for. | 10:28 |
| qschulz | amahnui[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 now | 10:34 |
| LetoThe2nd | I'm seeing gdk-pixbuf failing on master for riscv. Anybody aware of problems there? | 10:39 |
| rburton | khem is my go-to for riscv | 10: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 |
| LetoThe2nd | rburton: yeah sure, but I (usually) don't pester the VIPs unless I have asked the commons :) | 10:41 |
| qschulz | amahnui[m]: when you use *.patch, the shell will expand this to all files currently listed in the current directory, which ends with .patch | 10:41 |
| qschulz | if 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 both | 10:41 |
| qschulz | e.g.: git format-patch -1 && git send-email *.patch && git format-patch -1 -v2 && git send-email *.patch, will send the v1 patch twice | 10:42 |
| rburton | fwiw, this is why i rarely bother with the format-patch/send-email split unless needed | 10:43 |
| LetoThe2nd | and 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)' failed | 10:44 |
| LetoThe2nd | ../gdk-pixbuf-2.42.6/tests/resources.gresource.xml: Failed to close file descriptor for child process (Operation not permitted).y | 10: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 |
| qschulz | rburton: 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 sent | 10:47 |
| qschulz | but to each their own workflow :) | 10:47 |
| rburton | i use 'git show' for that | 10:47 |
| rburton | yeah, each to their own :) | 10:47 |
| *** troth <troth!~troth@c-24-8-35-226.hsd1.co.comcast.net> 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 submitted | 10:56 |
| *** LocutusOfBorg <LocutusOfBorg!~locutusof@93-50-192-18.ip153.fastwebnet.it> has quit IRC (Quit: ZNC 1.8.2+deb1 - https://znc.in) | 10:58 | |
| *** LocutusOfBorg <LocutusOfBorg!~locutusof@93-50-192-18.ip153.fastwebnet.it> has joined #yocto | 11:01 | |
| *** prabhakarlad <prabhakarlad!~prabhakar@pc.renesas.eu> has joined #yocto | 11:02 | |
| *** troth <troth!~troth@c-24-8-35-226.hsd1.co.comcast.net> has joined #yocto | 11:11 | |
| *** amitk_ <amitk_!~amit@103.208.69.67> has joined #yocto | 11:11 | |
| *** amitk <amitk!~amit@103.208.69.126> has quit IRC (Ping timeout: 268 seconds) | 11:14 | |
| *** simonew <simonew!~simonew@5.199.177.94> has quit IRC (Quit: Client closed) | 11:14 | |
| JaMa | rburton: new progressbar for stalled tasks works great :) | 11:24 |
| JaMa | NOTE: recipe ltp-20220121-r0: task do_rm_work: Succeeded | 11:24 |
| JaMa | Bitbake still alive (no events for 600s). Active tasks: | 11:24 |
| JaMa | /OE/lge/build/webosose/kirkstone/oe-core/meta/recipes-kernel/linux/linux-yocto_5.15.bb:do_fetch | 11:24 |
| JaMa | Bitbake still alive (no events for 1200s). Active tasks: | 11:24 |
| JaMa | /OE/lge/build/webosose/kirkstone/oe-core/meta/recipes-kernel/linux/linux-yocto_5.15.bb:do_fetch | 11:25 |
| rburton | \o/ | 11:25 |
| *** ChanServ sets mode: +o ndec | 11:27 | |
| *** ndec changes topic to ""Welcome to the Yocto Project | Learn more: https://www.yoctoproject.org | Join us or Speak at Yocto Project Summit (2022.05) May 17 - 19, 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"" | 11:28 | |
| ndec | hi 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 https://yoctoproject.org/summit. We have opened the CFP for now, will open registration shortly. | 11:29 |
| *** Tyaku <Tyaku!~Tyaku@lfbn-orl-1-19-210.w92-152.abo.wanadoo.fr> has joined #yocto | 11:31 | |
| Tyaku | Hi, 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 |
| Tyaku | In my local.conf I set this: ENABLE_UART = "1" and ENABLE_SPI_BUS = "1" | 11:33 |
| Tyaku | When 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 changes | 11:34 |
| rburton | agherzan: ^^^ meta-rpi question for you | 11:36 |
| *** simonew <simonew!~simonew@2a01:c23:c55b:1100:85eb:b39d:d4bc:e97d> has joined #yocto | 11:39 | |
| *** Schiller <Schiller!~Schiller@dynamic-002-247-252-132.2.247.pool.telefonica.de> has quit IRC (Quit: Client closed) | 11:41 | |
| *** prabhakarlad <prabhakarlad!~prabhakar@pc.renesas.eu> has quit IRC (Quit: Client closed) | 11:43 | |
| *** bps2 <bps2!~bps@193.89.194.60> has joined #yocto | 11:54 | |
| agherzan | Tyaku: is that a rpi3 or cm3? | 11:55 |
| agherzan | Also, what version of meta-raspberrypi are you using? | 11:56 |
| *** bps <bps!~bps@user/bps> has quit IRC (Ping timeout: 268 seconds) | 11:57 | |
| agherzan | Are you using uboot, if yes, can you try without it? | 11:58 |
| Tyaku | It'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 |
| Tyaku | Oh, I just see that I can't cat /boot when using network boot. So there is something wrong in my /etc/fstab I think | 12:14 |
| Tyaku | https://pastebin.com/C57kYW7V | 12:17 |
| Tyaku | I think there is something wrong with the NFS, So the problem is not related to meta-raspberry (Jesus) | 12:18 |
| *** prabhakarlad <prabhakarlad!~prabhakar@pc.renesas.eu> has joined #yocto | 12:28 | |
| vvn | rburton: 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 |
| vvn | So 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@62.157.232.203> 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 #yocto | 13: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 provides | 13:17 |
| jclsn[m] | s/has/have/ | 13:18 |
| *** ar__ <ar__!~akiCA@user/akica> has joined #yocto | 13:19 | |
| jclsn[m] | I only can PUT and GET files with curl. | 13:20 |
| *** codavi <codavi!~akiCA@user/akica> has joined #yocto | 13:21 | |
| jclsn[m] | Seems like I have to pull the tarballs with a shell script before building hmm | 13:22 |
| *** ar__ <ar__!~akiCA@user/akica> has quit IRC (Ping timeout: 268 seconds) | 13:24 | |
| *** xmn <xmn!~xmn@cpe-72-225-198-203.nyc.res.rr.com> has joined #yocto | 13:25 | |
| *** kroon <kroon!~kroon@89-253-118-72.customers.ownit.se> has quit IRC (Quit: Leaving) | 13:26 | |
| *** goliath <goliath!~goliath@user/goliath> has quit IRC (Quit: SIGSEGV) | 13:30 | |
| landgraf | jclsn[m]: https://stackoverflow.com/questions/63738191/how-to-pass-global-options-to-wget-and-curl-in-yocto ? | 13:31 |
| *** simonew <simonew!~simonew@2a01:c22:726b:5c00:5fd:8563:7368:2e3b> has joined #yocto | 13:37 | |
| *** bps3 <bps3!~bps@193.89.194.60> has joined #yocto | 13:37 | |
| *** bps2 <bps2!~bps@193.89.194.60> has quit IRC (Ping timeout: 240 seconds) | 13:40 | |
| rfs613 | To 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 |
| qschulz | rfs613: 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 | |
| qschulz | rfs613: and since you should do the same for SSTATE_DIR, it's two steps less than doing the symlinking manually :) | 13:46 |
| rfs613 | is this a reasonable use for auto.conf or site.conf ? | 13:46 |
| rburton | you could put it in site.conf | 13:47 |
| rburton | site.conf works well if you have a eg company-wide layer | 13:47 |
| rburton | so it can set proxies, central mirrors, etc | 13:47 |
| rfs613 | ok thanks. I noticed that bitbake uses os.path.normpath() in some places, which is known to break symlinks. | 13:50 |
| rfs613 | so I guess that's another reason to use DL_DIR / SSTATE_DIR | 13:50 |
| vvn | qschulz: do you know if downstream users of AGL define their own machine configuration files or if they use the upstream ones solely? | 13:50 |
| qschulz | vvn: is this question really aimed at me? | 13:51 |
| *** sakoman <sakoman!~steve@dhcp-72-253-6-214.hawaiiantel.net> has joined #yocto | 13:57 | |
| smurray | vvn: 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 |
| vvn | qschulz: oops nope it was for smurray, sorry. | 13:59 |
| qschulz | vvn: no worries, was surprised because I never played with AGL before :D | 14:00 |
| vvn | smurray: so adding a custom foo.conf machine which requires a vendor bsp is somewhat common I assume | 14:02 |
| smurray | vvn: yes | 14:03 |
| vvn | smurray: 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 #yocto | 14:05 | |
| smurray | vvn: 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 BSPs | 14:05 |
| *** Minvera <Minvera!~Minvera@user/Minvera> has joined #yocto | 14:06 | |
| smurray | vvn: the * is that we do carry some tweaks to vendor BSPs to e.g. consistently enable some kernel configs and fix wayland configuration issues | 14:06 |
| *** simonew <simonew!~simonew@2a01:c22:726b:5c00:5fd:8563:7368:2e3b> has quit IRC (Client Quit) | 14:07 | |
| smurray | vvn: that's done with effectively local.conf tweaks and bbappends, and we try to avoid anything really significant | 14:07 |
| smurray | vvn: 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 enabled | 14: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 connect | 14:09 |
| smurray | vvn: 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 layer | 14:12 |
| amahnui[m] | I also wish to ask how many cores is recommended for an 8gb ram machine when running bitbake core-image-sato | 14:16 |
| amahnui[m] | The machine as 8GB of RAM nad 8 cores | 14:17 |
| *** bps2 <bps2!~bps@193.89.194.60> has joined #yocto | 14:18 | |
| *** GLumen_ <GLumen_!~Gregory@97-126-1-223.tukw.qwest.net> has joined #yocto | 14:20 | |
| *** Wouter0100 <Wouter0100!~Wouter010@entry.nbg.netvos.nl> has joined #yocto | 14:21 | |
| *** bps3 <bps3!~bps@193.89.194.60> has quit IRC (Ping timeout: 260 seconds) | 14:21 | |
| *** goliath <goliath!~goliath@user/goliath> has joined #yocto | 14:23 | |
| vvn | smurray: 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!~Schiller@dynamic-002-247-252-132.2.247.pool.telefonica.de> has joined #yocto | 14:25 | |
| amahnui[m] | Please how do I call PARALLEL_MAKE in my conf/local.conf file in the case that iit is not present there | 14:26 |
| qschulz | amahnui[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 example | 14:27 |
| smurray | vvn: 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 undo | 14:27 |
| amahnui[m] | qschulz: thanks I'll add it there rather. | 14:29 |
| vvn | smurray: 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 |
| vvn | I 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 |
| smurray | vvn: yeah, there can be grey areas | 14:36 |
| *** goliath <goliath!~goliath@user/goliath> has quit IRC (Quit: SIGSEGV) | 14:38 | |
| rfs613 | does the autobuild run dunfell branch with meta-openembedded layer? | 14:41 |
| vvn | smurray: 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 cumbersome | 14:44 |
| *** florian_kc <florian_kc!~florian@port-217-146-132-69.static.as20676.net> has quit IRC (Remote host closed the connection) | 14:48 | |
| rfs613 | build #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!~Schiller@dynamic-002-247-252-132.2.247.pool.telefonica.de> 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 |
| rburton | wget will respect .netrc for authentication details | 14:57 |
| *** dgriego <dgriego!~dgriego@user/dgriego> has joined #yocto | 15:00 | |
| *** Tyaku <Tyaku!~Tyaku@lfbn-orl-1-19-210.w92-152.abo.wanadoo.fr> 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 API | 15:01 |
| jclsn[m] | Wonder if it can also push like this | 15:01 |
| *** mckoan is now known as mckoan|away | 15:04 | |
| fabatera[m] | Hi!... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/188212870bac9d4e979d21fef2b8dbf845aa3f76) | 15:22 |
| sakoman | rfs613: 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 broken | 15:27 |
| sakoman | rfs613: khem does lots of test runs: https://autobuilder.yoctoproject.org/typhoon/#/builders/88 | 15:29 |
| rfs613 | sakoman: 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 |
| landgraf | jclsn[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 |
| kergoth | Hmm, wonder if anyone else would find https://github.com/MentorEmbedded/meta-mentor/blob/master/meta-mentor-common/classes/user_features.bbclass of use. Going through my layers for potential submissions | 15: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@193.89.194.60> has quit IRC (Ping timeout: 240 seconds) | 15:44 | |
| rburton | zeddii: it appears that the xtf-image:testimage integration is broken in master. just tried it, and the boot appears to hang. | 15:47 |
| vvn | kergoth: 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 |
| kergoth | The 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 boundaries | 15:49 |
| kergoth | but it's a good point | 15:49 |
| *** GillesM <GillesM!~gilles@105.61.128.77.rev.sfr.net> has quit IRC (Quit: Leaving) | 15:55 | |
| *** GillesM <GillesM!~gilles@105.61.128.77.rev.sfr.net> has joined #yocto | 15:55 | |
| *** GillesM <GillesM!~gilles@105.61.128.77.rev.sfr.net> has quit IRC (Remote host closed the connection) | 15:55 | |
| *** Mike23 <Mike23!~Mike23@cpe90-146-41-24.liwest.at> has joined #yocto | 15:58 | |
| *** sakoman <sakoman!~steve@dhcp-72-253-6-214.hawaiiantel.net> has quit IRC (Quit: Leaving.) | 16:05 | |
| *** sakoman <sakoman!~steve@dhcp-72-253-6-214.hawaiiantel.net> has joined #yocto | 16:09 | |
| *** manuel <manuel!~manuel@2a02:1748:dd5c:f290:c553:9012:6082:a89a> has joined #yocto | 16:13 | |
| manuel | Hi all. How can I build a yocto image with a patched initramfs? I'd like to carry this patch over to my yocto image: https://gitlab.com/manuel_wagesreither/debian-image-creator/-/blob/master/src/files/initramfs.patch | 16:15 |
| vvn | manuel: 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 += "https://gitlab.com/manuel_wagesreither/debian-image-creator/-/blob/master/src/files/initramfs.patch" | 16:20 |
| vvn | and make sure that initramfs-tools is installed as part of whatever initramfs image you are using. | 16:21 |
| manuel | vvn: 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 |
| vvn | manuel: 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 |
| smurray | it's not used by OE/Yocto at all that I can see | 16:30 |
| vvn | manuel: (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 |
| vvn | smurray: it's listed here, but I'm guessing it's not widely used http://layers.openembedded.org/layerindex/recipe/56835/ :) | 16:31 |
| manuel | vvn: 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 |
| smurray | vvn: ah, I did look in the layer index just now, but missed it | 16:33 |
| vvn | manuel: 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 |
| smurray | manuel: perhaps take a look at recipes-core/initrdscripts/initramfs-framework_1.0.bb and the scriptlets it pulls in, that's what's used in the example initramfs images in oe-core | 16:33 |
| manuel | vvn, 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 |
| vvn | manuel: 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 |
| smurray | vvn: btw, did you happen to get an expired certificate warning from layers.openembedded.org? | 16:50 |
| vvn | smurray: nope | 16:51 |
| smurray | vvn: hrm, okay | 16:51 |
| *** Mike23 <Mike23!~Mike23@cpe90-146-41-24.liwest.at> has quit IRC (Quit: Client closed) | 16:51 | |
| RP | zeddii: do you use any systems with make 4.2.1 for testing the kernel builds? | 16:55 |
| smurray | halstead: sort of looks like the SSL cert on layers.oe.org expired about an hour and a half ago | 16:56 |
| * rfs613 builds kernels with make 4.2.1 | 16:56 | |
| RP | rfs613: we're seeing hangs occasionally with it :/ | 16:57 |
| *** ecdhe <ecdhe!~ecdhe@user/ecdhe> has joined #yocto | 16:57 | |
| *** florian <florian!~florian@port-217-146-132-69.static.as20676.net> has quit IRC (Quit: Ex-Chat) | 16:58 | |
| rfs613 | RP: 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 |
| zeddii | RP: all my systems are Make 4.2.1 it appears | 17:00 |
| RP | zeddii: hmm, so how common is this bug :/ | 17:05 |
| vvn | having a layer in a meta/ directory won't clash as long as the layer name is unique, right? | 17:06 |
| RP | rfs613: it is rare but does seem to happen on the autobuilder periodically, either in the kernel or perl | 17:06 |
| JaMa | LetoThe2nd: find the corresponding sigdata files and run bitbake-diffsigs on them | 17:06 |
| JaMa | LetoThe2nd: ups, replying to some old message | 17:07 |
| *** frieder <frieder!~frieder@i59F72634.versanet.de> has quit IRC (Remote host closed the connection) | 17:07 | |
| * RP suspects https://git.savannah.gnu.org/cgit/make.git/commit/?id=78b5fec6898c26956d00548427cda1101cb80f8a is missing in 4.2.1 causing t | 17:07 | |
| RP | it | 17:08 |
| rfs613 | RP: it seems that ubuntu-20.x has this included in their make-4.2.1 packcage | 17:21 |
| rfs613 | which may explain why I don't see it | 17:21 |
| *** vvn <vvn!~vivien@bras-base-mtrlpq2848w-grc-41-70-53-240-211.dsl.bell.ca> has quit IRC (Read error: Connection reset by peer) | 17:21 | |
| *** gsalazar <gsalazar!~gsalazar@132.120.90.149.rev.vodafone.pt> has quit IRC (Ping timeout: 272 seconds) | 17:21 | |
| *** vvn <vvn!~vivien@bras-base-mtrlpq2848w-grc-41-70-53-240-211.dsl.bell.ca> has joined #yocto | 17:22 | |
| rfs613 | am looking at https://packages.ubuntu.com/focal/make and specifically the make-dfsg_4.2.1-1.2.diff.gz file | 17:22 |
| RP | rfs613: that would explain it | 17:22 |
| RP | it is generally redhat systems where this shows up that don't have that | 17:22 |
| RP | zeddii: are yours redhat derived or debian? | 17:23 |
| zeddii | ubu | 17:23 |
| rfs613 | looks like it was patched Wed 11 Jul 2018 according to http://changelogs.ubuntu.com/changelogs/pool/main/m/make-dfsg/make-dfsg_4.2.1-1.2/changelog | 17:23 |
| RP | that might help explain things but complicates a fix :/ | 17:23 |
| rfs613 | there seem to be two potential hangs, SV 51400 and SV 51159 | 17:24 |
| vvn | Do not rest your foot on the power cord guys | 17:24 |
| rfs613 | vvn: what about the ethernet cord? :P | 17:25 |
| rfs613 | khem: has anyone reported issue with the recent CVE fixes for polkit in meta-openebedded? | 17:29 |
| rfs613 | i've just figured out that two of them are colliding, which evidently results in the fuzz warning. | 17:30 |
| rfs613 | i'll post a fix, just giving a heads up | 17:31 |
| smurray | rfs613: odd, I've been doing test builds locally with meta-oe with that change (d5eef01f, I assume) and I've not seen a fuzz warning | 17:32 |
| rfs613 | smurray: this is on dunfell, the two commits are 67ec3e04 and 17e931 | 17:35 |
| smurray | rfs613: ah, okay | 17:35 |
| *** goliath <goliath!~goliath@user/goliath> has joined #yocto | 17:45 | |
| *** kevinrowland <kevinrowland!~kevinrowl@165.225.243.0> has joined #yocto | 17:52 | |
| *** prabhakarlad <prabhakarlad!~prabhakar@pc.renesas.eu> has quit IRC (Quit: Client closed) | 18:06 | |
| halstead | smurray: I'll look into it. | 18:10 |
| smurray | halstead: okay, thank you | 18:11 |
| halstead | smurray: I just forced the renewal. How does it look now? | 18:13 |
| smurray | halstead: looks good now, Firefox is happy | 18:14 |
| smurray | halstead: thanks! | 18:14 |
| halstead | smurray: 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 |
| smurray | halstead: cool, good to know | 18:15 |
| *** huseyinkozan <huseyinkozan!~hk@31.223.46.138> has quit IRC (Quit: Konversation terminated!) | 18:16 | |
| *** jmiehe <jmiehe!~Thunderbi@user/jmiehe> has joined #yocto | 18:17 | |
| LetoThe2nd | khem: are you aware of any gdk-pixbuf woes on kirkston/master with riscv at the moment? | 18:46 |
| *** prabhakarlad <prabhakarlad!~prabhakar@pc.renesas.eu> has joined #yocto | 18:50 | |
| LetoThe2nd | hm. | 18:53 |
| LetoThe2nd | its not even riscv related, but it completely falls over, even for qemux86 | 18: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 | |
| vvn | if 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 |
| vvn | s/you're/your/ | 19:26 |
| *** kevinrowland <kevinrowland!~kevinrowl@165.225.243.0> has quit IRC (Quit: Client closed) | 19:39 | |
| *** kevinrowland <kevinrowland!~kevinrowl@165.225.243.0> has joined #yocto | 19:43 | |
| *** prabhakarlad <prabhakarlad!~prabhakar@pc.renesas.eu> has quit IRC (Quit: Client closed) | 19:44 | |
| *** amitk_ <amitk_!~amit@103.208.69.67> 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!~mrnuke@c-98-195-139-126.hsd1.tx.comcast.net> has joined #yocto | 20:24 | |
| *** leon-anavi <leon-anavi!~Leon@46.55.231.62> has quit IRC (Remote host closed the connection) | 20:33 | |
| smurray | vvn: to me that's a distro thing, ideally the BSP doesn't care if a distro uses sysvinit, systemd, or something else | 20:35 |
| vvn | smurray: 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 |
| smurray | vvn: 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 flexibility | 20:43 |
| vvn | smurray: 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/image | 20:45 |
| vvn | smurray: like would it make sense to have poky-initramfs.conf or poky-altcfg-initramfs.conf for instance? | 20:47 |
| smurray | vvn: to do something along the lines of http://docs.yoctoproject.org/dev-manual/common-tasks.html#bundling-an-initramfs-image-from-a-separate-multiconfig ? | 20:51 |
| vvn | smurray: exactly | 20:52 |
| smurray | vvn: usually I'd expect the initramfs to not have enough in it that it'd need a full new distro conf | 20:52 |
| smurray | vvn: but I've defined convenience machines and distros for somewhat similar multiconfig stuff for containers, so I could see doing it that way | 20:53 |
| vvn | smurray: 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 multiconfig | 20:55 |
| vvn | I mean that DISTRO_FEATURES:remove in the INITRAMFS_MULTICONFIG might not work if the distro is appending features | 20:55 |
| smurray | vvn: yeah, I could see that. I guess I've never encountered an initramfs with enough stuff in it that it mattered | 20:56 |
| vvn | smurray: 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 |
| smurray | vvn: yeah | 21:00 |
| vvn | I will encounter the same problem actually for containers and portable services, preferring linux-dummy for the kernel... | 21:02 |
| smurray | heh, indeed. I've done both overriding the PREFERRED_PROVIDER in the mulitconfig .conf and just doing it with a derived "container" machine .conf | 21:04 |
| vvn | smurray: do you have a preferred approach? | 21:05 |
| *** Minvera <Minvera!~Minvera@user/Minvera> has quit IRC (Remote host closed the connection) | 21:05 | |
| vvn | So 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.conf | 21:06 |
| smurray | vvn: 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 way | 21:06 |
| *** sakoman <sakoman!~steve@dhcp-72-253-6-214.hawaiiantel.net> has quit IRC (Quit: Leaving.) | 21:07 | |
| vvn | indeed, you need to scale easily and not duplicate all distro and machine configs everytime you have a new board variant | 21:08 |
| smurray | vvn: 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 |
| smurray | err, one | 21: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 #yocto | 21: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 camus | 22: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 |
| vvn | amahnui[m]: you might try to restart the build from scratch by removing the build/ directory and start again | 22:29 |
| amahnui[m] | vvn: Thanks I will try that out as well | 22:32 |
| vvn | smurray: 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@217.138.219.172> has quit IRC (Ping timeout: 246 seconds) | 22:35 | |
| smurray | vvn: 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, really | 22:37 |
| vvn | smurray: currently only one hardware but will likely have different platforms in the near future (getting rid of the beaglebone slowly) | 22:39 |
| smurray | vvn: 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 bits | 22:40 |
| vvn | that was the point of using openembedded in fact | 22:40 |
| smurray | some of this can be handled by using machine overrides in the distro layer | 22:41 |
| smurray | or BBFILES_DYNAMIC to add bbappends driven by the presence of BSP layers | 22:42 |
| vvn | hum, crypttab is very machine specific but fstab can be generic (/dev/mapper/foo is used). | 22:43 |
| vvn | smurray: yeah it's always either the bbappend lives in the bsp layer with :foomach overrides or in the distro layer with :foodist:foomach overrides | 22:44 |
| smurray | at 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 another | 22:44 |
| smurray | err, reusing | 22:44 |
| kevinrowland | can 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 |
| smurray | the log location is mentioned in the channel header | 22:46 |
| vvn | kevinrowland: literally googling yocto irc archives ;) https://www.yoctoproject.org/irc/ | 22:46 |
| vvn | /topic as well indeed | 22:47 |
| kevinrowland | I meant search _programmatically_. grep I guess would've been a better verb | 22:47 |
| kevinrowland | I clicked through to some days where I thought the conversation occurred but couldn't find it | 22:48 |
| *** BhsTalel <BhsTalel!~BhsTalel@102.157.33.91> has joined #yocto | 22:48 | |
| vvn | kevinrowland: google this: "devtool deploy-target site:https://www.yoctoproject.org/irc/" | 22:48 |
| kevinrowland | oh, yes, of course :) plus my username, I should be able to find it | 22:48 |
| *** dev1990 <dev1990!~dev@dynamic-78-8-240-254.ssp.dialog.net.pl> has quit IRC (Quit: Konversation terminated!) | 22:49 | |
| *** Wouter0100 <Wouter0100!~Wouter010@entry.nbg.netvos.nl> has quit IRC (Read error: Connection reset by peer) | 22:51 | |
| *** Wouter0100 <Wouter0100!~Wouter010@entry.nbg.netvos.nl> has joined #yocto | 22:51 | |
| vvn | smurray: 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 |
| BhsTalel | Hello 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. Thanks | 22:53 |
| *** sakoman <sakoman!~steve@dhcp-72-253-6-214.hawaiiantel.net> has joined #yocto | 22:54 | |
| smurray | BhsTalel: the links here might help you: https://wiki.yoctoproject.org/wiki/Newcomers#How_to_Contribute | 22:55 |
| vvn | BhsTalel: no need to apologize, that's the point of a channel ;-) | 22:56 |
| smurray | vvn: maybe? If e.g. /boot is in the rootfs it may complicate that distinction | 22:57 |
| vvn | smurray: what about files interpreted by both the initramfs and the rootfs, like crypttab and fstab? ;) | 22:57 |
| * vvn is becoming crazy | 22:57 | |
| smurray | heh, 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 point | 22:59 |
| smurray | or wait for someone with a better idea than me to come on the channel ;) | 22:59 |
| vvn | smurray: I am just concluding that true orthogonality between machine/distro/image is just a myth | 23:00 |
| vvn | smurray: I'm pretty much there, I have working layers for my product, just never been really satisfied with the organization. | 23:01 |
| smurray | vvn: 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 out | 23:06 |
| smurray | vvn: so we end up needing to carry that extra metadata at a higher level than the plain BSP | 23:07 |
| smurray | vvn: but there are others who have been doing OE a lot longer than I have that might have a different view of that | 23:07 |
| *** xmn <xmn!~xmn@cpe-72-225-198-203.nyc.res.rr.com> has quit IRC (Ping timeout: 248 seconds) | 23:11 | |
| *** kevinrowland <kevinrowland!~kevinrowl@165.225.243.0> has quit IRC (Quit: Client closed) | 23:12 | |
| kergoth | I 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 it | 23:26 |
| kergoth | See COMBINED_FEATURES | 23:26 |
| kergoth | That’s what we’ve done at mentor, added “mel-“ prefixed new bsp features in machine_features | 23:27 |
| BhsTalel | @vvn Can you put a brief summary for me, because I did not catch the topic history. | 23:29 |
| vvn | BhsTalel: 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 |
| kergoth | It’s common to fuzz the boundaries due to schedule constraints, if not ideal | 23:32 |
| *** goliath <goliath!~goliath@user/goliath> has quit IRC (Quit: SIGSEGV) | 23:35 | |
| *** bps2 <bps2!~bps@80.71.142.18.ipv4.parknet.dk> has joined #yocto | 23:36 | |
| BhsTalel | The 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 the | 23:37 |
| BhsTalel | packagegroup-rs485 get enabled in a generic packagegroup that is included in all of my images. | 23:37 |
| vvn | kergoth: 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 juggle | 23:37 |
| vvn | with recipes between meta-bsp/recipes-core and meta-distro/recipes-bsp. | 23:37 |
| vvn | You often end up with distro-specific machine and machine-specific distros, in contrary to the ideal generic swappable approach | 23:39 |
| amahnui[m] | <BhsTalel> "Hello everyone, sorry if I..." <- Hi BhsTalel are you an applicant too? | 23:39 |
| *** bonalais <bonalais!uid502939@id-502939.tinside.irccloud.com> has joined #yocto | 23:41 | |
| BhsTalel | amahnui[m] I did not get the meaning, sorry my english is not that perfect. Did you mean I am a Yocto engineer ? | 23:42 |
| vvn | BhsTalel: 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@165.225.243.0> has joined #yocto | 23:42 | |
| amahnui[m] | BhsTalel: No I meant outreachy applicant | 23:42 |
| BhsTalel | vvn 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 file | 23:47 |
| BhsTalel | amahnui[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 #yocto | 23:51 | |
| vvn | BhsTalel: 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 bothering | 23:58 |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!