| theonewithhands | hello, does anyone have experience extending the image-buildinfo bbclass? | 00:11 |
|---|---|---|
| *** theonewithhands <theonewithhands!~theonewit@c-24-9-152-216.hsd1.co.comcast.net> has quit IRC (Ping timeout: 250 seconds) | 00:29 | |
| *** nerdboy <nerdboy!~nerdboy@gentoo/developer/nerdboy> has quit IRC (Remote host closed the connection) | 00:53 | |
| *** nerdboy <nerdboy!~nerdboy@gentoo/developer/nerdboy> has joined #yocto | 00:54 | |
| *** nerdboy <nerdboy!~nerdboy@gentoo/developer/nerdboy> has quit IRC (Remote host closed the connection) | 00:59 | |
| *** nerdboy <nerdboy!~nerdboy@47.143.129.173> has joined #yocto | 01:01 | |
| *** theonewithhands <theonewithhands!~theonewit@c-24-9-152-216.hsd1.co.comcast.net> has joined #yocto | 01:11 | |
| *** theonewithhands <theonewithhands!~theonewit@c-24-9-152-216.hsd1.co.comcast.net> has quit IRC (Ping timeout: 250 seconds) | 01:15 | |
| *** xmn <xmn!~xmn@pool-108-46-142-76.nycmny.fios.verizon.net> has joined #yocto | 01:26 | |
| *** jclsn <jclsn!~jclsn@2a04:4540:6543:a600:2ce:39ff:fecf:efcd> has quit IRC (Ping timeout: 255 seconds) | 01:28 | |
| *** jclsn <jclsn!~jclsn@2a04:4540:654d:f00:2ce:39ff:fecf:efcd> has joined #yocto | 01:30 | |
| *** dankm <dankm!~dan@user/dankm> has quit IRC (Remote host closed the connection) | 02:07 | |
| *** dankm <dankm!~dan@user/dankm> has joined #yocto | 02:08 | |
| *** Daanct12 <Daanct12!~danct12@user/danct12> has joined #yocto | 02:29 | |
| *** mbulut <mbulut!~mbulut@31.18.142.72> has quit IRC (Ping timeout: 246 seconds) | 02:52 | |
| *** Danct12 <Danct12!~danct12@user/danct12> has quit IRC (Quit: ZNC 1.9.0 - https://znc.in) | 03:02 | |
| *** Danct12 <Danct12!~danct12@user/danct12> has joined #yocto | 03:02 | |
| *** wooosaiiii <wooosaiiii!~Thunderbi@89-212-21-243.static.t-2.net> has quit IRC (Ping timeout: 252 seconds) | 03:53 | |
| *** wooosaiiii <wooosaiiii!~Thunderbi@89-212-21-243.static.t-2.net> has joined #yocto | 03:53 | |
| *** alessioigor <alessioigor!~alessioig@185.178.95.238> has joined #yocto | 03:55 | |
| *** Raman <Raman!~Raman@2405:201:d02e:4053:316d:39aa:282e:b8be> has joined #yocto | 04:05 | |
| Raman | Can someone tell me why there is a limitation of 20 on number of parallel bb tasks. If I am building on high performance servers, should I do? | 04:09 |
| Raman | BB_NUMBER_THREADS = "64" | 04:09 |
| Raman | PARALLEL_MAKE = "-j 64" | 04:09 |
| Raman | Just want to know it's a general guidance or some known issues exist. | 04:09 |
| *** mrpelotaz0 <mrpelotaz0!~mrpelotaz@user/mrpelotazo> has quit IRC (Quit: Hasta la vista!) | 04:18 | |
| *** mrpelotazo <mrpelotazo!~mrpelotaz@user/mrpelotazo> has joined #yocto | 04:20 | |
| *** Lihis <Lihis!~Lihis@2001:41d0:e:f34::1> has quit IRC (Quit: Quitting) | 04:33 | |
| *** shoragan <shoragan!~shoragan@user/shoragan> has joined #yocto | 04:47 | |
| *** leon-anavi <leon-anavi!~Leon@46.55.231.62> has joined #yocto | 05:30 | |
| *** amitk <amitk!~amit@58.84.60.54> has joined #yocto | 05:41 | |
| *** Kubu_work <Kubu_work!~kubu@lfbn-nan-1-335-137.w82-120.abo.wanadoo.fr> has joined #yocto | 05:54 | |
| *** Lihis <Lihis!~Lihis@2001:41d0:e:f34::1> has joined #yocto | 05:56 | |
| *** rob_w <rob_w!~rob@2001:a61:603a:7001:cac:9298:129d:72c0> has joined #yocto | 05:57 | |
| *** frieder <frieder!~frieder@89.244.121.50> has joined #yocto | 05:58 | |
| *** tgamblin <tgamblin!~tgamblin@d24-150-219-207.home.cgocable.net> has quit IRC (Remote host closed the connection) | 06:05 | |
| *** tgamblin <tgamblin!~tgamblin@d24-150-219-207.home.cgocable.net> has joined #yocto | 06:05 | |
| *** mvlad <mvlad!~mvlad@2a02:2f05:8111:a400:e88e:21ff:fe65:be18> has joined #yocto | 06:10 | |
| *** Raman <Raman!~Raman@2405:201:d02e:4053:316d:39aa:282e:b8be> has quit IRC (Quit: Client closed) | 06:34 | |
| *** Xagen <Xagen!~Xagen@99-135-179-142.lightspeed.austtx.sbcglobal.net> has quit IRC (Ping timeout: 268 seconds) | 06:35 | |
| *** Xagen <Xagen!~Xagen@99-135-179-142.lightspeed.austtx.sbcglobal.net> has joined #yocto | 06:35 | |
| AdrianF | Raman: It's a trade of between RAM and CPU cores. For example, with your settings bitbake starts 64 make processes which start 64 g++ processes. If each of the g++ processes allocates 2GB of RAM you need 8TB of RAM. Probably there is a high risk for failed builds due to OOMs. | 06:50 |
| AdrianF | Raman: This is probably a good starting point: https://docs.yoctoproject.org/singleindex.html#term-BB_NUMBER_THREADS | 06:51 |
| *** mckoan|away is now known as mckoan | 07:00 | |
| *** ehussain <ehussain!~Thunderbi@2400:adc5:122:ef00:453:6e24:a14c:9543> has joined #yocto | 07:04 | |
| *** rfuentess <rfuentess!~rfuentess@lfbn-lyo-1-1566-5.w90-52.abo.wanadoo.fr> has joined #yocto | 07:07 | |
| *** PaowZ <PaowZ!~Vince@2a01:e0a:144:d020:2165:857b:e2ea:f3b9> has joined #yocto | 07:07 | |
| *** rob_w_ <rob_w_!~bob@2001:a61:603a:7001:5eb6:68f8:905a:1bc9> has joined #yocto | 07:08 | |
| philipl_ | JPEW: In a sense that the hash equivalence database may contain "spurious" entries (i.e. entries that may never be referred to again)? | 07:15 |
| *** zpfvo <zpfvo!~fvo@185-59-142-46.pool.kielnet.net> has joined #yocto | 07:18 | |
| *** Raman <Raman!~Raman@2405:201:d02e:4053:316d:39aa:282e:b8be> has joined #yocto | 07:22 | |
| *** prabhakalad <prabhakalad!~prabhakar@147.161.225.104> has quit IRC (Quit: Konversation terminated!) | 07:23 | |
| *** prabhakalad <prabhakalad!~prabhakar@147.161.225.104> has joined #yocto | 07:23 | |
| *** Raman <Raman!~Raman@2405:201:d02e:4053:316d:39aa:282e:b8be> has quit IRC (Client Quit) | 07:24 | |
| *** Jones42 <Jones42!~Jones42@user/Jones42> has joined #yocto | 07:25 | |
| *** florian_kc <florian_kc!~florian@dynamic-077-177-163-182.77.177.pool.telefonica.de> has joined #yocto | 07:33 | |
| *** altru <altru!~altru@static-css-ccs-204145.business.bouyguestelecom.com> has joined #yocto | 07:42 | |
| *** florian_kc <florian_kc!~florian@dynamic-077-177-163-182.77.177.pool.telefonica.de> has quit IRC (Ping timeout: 240 seconds) | 07:51 | |
| *** enok <enok!~Thunderbi@94.191.136.242.mobile.tre.se> has joined #yocto | 07:52 | |
| *** enok <enok!~Thunderbi@94.191.136.242.mobile.tre.se> has quit IRC (Ping timeout: 256 seconds) | 08:00 | |
| *** enok <enok!~Thunderbi@94.191.136.242.mobile.tre.se> has joined #yocto | 08:04 | |
| *** ahussain <ahussain!~Thunderbi@2404:3100:182e:b76a:fbb7:328b:eb9e:b4d9> has joined #yocto | 08:11 | |
| *** ray-san <ray-san!~ray-san@195.50.168.194> has joined #yocto | 08:11 | |
| *** ahussain1 <ahussain1!~Thunderbi@72.255.51.71> has joined #yocto | 08:15 | |
| *** ahussain <ahussain!~Thunderbi@2404:3100:182e:b76a:fbb7:328b:eb9e:b4d9> has quit IRC (Ping timeout: 255 seconds) | 08:15 | |
| *** ehussain <ehussain!~Thunderbi@2400:adc5:122:ef00:453:6e24:a14c:9543> has quit IRC (Ping timeout: 272 seconds) | 08:15 | |
| *** ahussain1 is now known as ehussain | 08:15 | |
| *** ahussain <ahussain!~Thunderbi@154.80.31.206> has joined #yocto | 08:17 | |
| *** ehussain <ehussain!~Thunderbi@72.255.51.71> has quit IRC (Ping timeout: 252 seconds) | 08:19 | |
| *** ahussain is now known as ehussain | 08:19 | |
| *** mbulut <mbulut!~mbulut@ip1f128e48.dynamic.kabel-deutschland.de> has joined #yocto | 08:20 | |
| *** Daaanct12 <Daaanct12!~danct12@user/danct12> has joined #yocto | 08:49 | |
| Jones42 | what's the most idiomatic way to change/overwrite a recipe's task order? i.e. change "addtask T before do_X after do_A" to "addtask T before do_Y after do_A" | 08:50 |
| *** Daanct12 <Daanct12!~danct12@user/danct12> has quit IRC (Ping timeout: 268 seconds) | 08:51 | |
| Jones42 | should I change the varflags of do_X/Y or should I just deltask and add it again? or is there a better way? | 08:52 |
| kanavin_ | Jones42, it helps if you explain what the problem is | 08:54 |
| Jones42 | sure! I'm using kernel-fitimage.bbclass and I'd like to move "assemble_fitimage before do_install after do_compile" to "before do_deploy" | 08:56 |
| Jones42 | (give me a second to find the explanation in my notes...) | 08:57 |
| Jones42 | I want do decouple the rootfs generation from the kernel's assemble-fitimage generation, because I need to put the rootfs' dm-verity hash into the fitimage. | 09:01 |
| Jones42 | It's a bit complicated to explain: I don't need the fitimage for the kernel do_install. But do_rootfs depends on the kernel's do_package/do_install | 09:06 |
| Jones42 | so by moving the assemble fitimage a step "later" (before do_install -> before do_deploy), I can build the rootfs (and my ext4.verity image) without having to assemble_fitimage first. | 09:08 |
| Jones42 | so by the time I assemble_fitimage, I have the rootfs.ext4.verity roothash and can put said hash into the fitimage. | 09:09 |
| mcfrisk | Jones42: the "before" and "after" for the tasks needs to be adjusted where they are set, IMO. I'm using meta-security dm-verity-img.bbclass for a /usr partition, fwiw. | 09:14 |
| *** xmn <xmn!~xmn@pool-108-46-142-76.nycmny.fios.verizon.net> has quit IRC (Ping timeout: 264 seconds) | 09:19 | |
| Jones42 | mcfrisk: hmm... I hoped I could overwrite it somewhere because wanted to avoid messing with any "official" files. But I think that's indeed not possible due to the local scope of each recipe :/ | 09:21 |
| *** altru <altru!~altru@static-css-ccs-204145.business.bouyguestelecom.com> has quit IRC (Ping timeout: 250 seconds) | 09:22 | |
| kanavin_ | Jones42, I don't think it's possible to reorder tasks after the fact, you're probably better off writing a new class, or maybe adding a new task into the correct position | 09:23 |
| *** enok <enok!~Thunderbi@94.191.136.242.mobile.tre.se> has quit IRC (Ping timeout: 256 seconds) | 09:25 | |
| RP | Jones42: the constraints do "stack" so you can addtask again and add new constraints. You can't change existing ones though without deleting the task | 09:28 |
| Jones42 | kanavin_,RP: thanks! I found the addtask code, but if I can't "bbclassappend" or overwrite the task's varflags from outside the recipe, then the only solution seems to be to write a new class | 09:30 |
| Jones42 | wait - I could just bbappend the recipe that inherits the class, right? | 09:31 |
| kanavin_ | yes, for sure | 09:31 |
| Jones42 | nice, that might be the least ugly solution. :-) | 09:32 |
| mcfrisk | Jones42: what kind of problem are you solving? I had issues using dm-verity-img.bbclass with .wic images and ended up with two image recipe solution: one for dm-verity-img, another for .wic. then connecting output from dm-verity to .wic was a bit ugly but it worked. trying to upstream the bits and pieces at some point when there is a clear path to do so... | 09:35 |
| Jones42 | mcfrisk: It's one of those "It should be simple in practice, but how do people actually make it work?"-Problems... | 09:39 |
| Jones42 | I'm having a simple fitimage, no initramfs and a dm-verity rootfs. all in a wic image | 09:40 |
| Jones42 | I'm using the image_types_verity.bbclass as seen on TV, er, on one of the CLT2024 talks. I wasn't aware of the meta-security dm-verity-img.bbclass. I only found that one later | 09:42 |
| Jones42 | https://patchwork.yoctoproject.org/project/oe/patch/20240423102102.1926313-1-u.oelmann@pengutronix.de/ | 09:42 |
| *** altru <altru!~altru@static-css-ccs-204145.business.bouyguestelecom.com> has joined #yocto | 09:43 | |
| Jones42 | My issue is that for some reasons, my do_rootfs has dependencies on my kernel's do_package->do_install->do_assemble_fitimage->do_compile | 09:43 |
| mcfrisk | yes, saw those patches and was wondering what the use case really is, compared to meta-security. The problem for me was the ordering of image processing tasks, which can't be changed so easily. I use uki image with kernel and initrd, signed for uefi secure boot, then /usr on dm-verity partition tied to the kernel command line. Then tpm backed rootfs is created on first boot, with machine specific key. | 09:44 |
| Jones42 | So that all explodes when I want to get my u-boot script with the roothash into my fitimage, when the fitimage is already built before my rootfs is dond | 09:44 |
| Jones42 | *done | 09:45 |
| mcfrisk | sounds quite similar to my problems with wic image type | 09:45 |
| mcfrisk | also had to generate the roothash and then feed it back to initrd cmdline | 09:46 |
| Jones42 | the wic image was no problem for me, since that one was built as very last step. By then I have the fitimage with the roothash as part of the u-boot script and the rootfs.ext4.verity that I can just rawcopy like in that example | 09:49 |
| Jones42 | https://git.yoctoproject.org/meta-security/tree/wic/beaglebone-yocto-verity.wks.in | 09:49 |
| *** altru <altru!~altru@static-css-ccs-204145.business.bouyguestelecom.com> has quit IRC (Ping timeout: 250 seconds) | 09:49 | |
| Jones42 | Also, I'm passing the verity params via the kernel cmdline, so I can save the initramfs | 09:49 |
| Jones42 | ( https://www.kernel.org/doc/html/latest/admin-guide/device-mapper/dm-init.html ) | 09:49 |
| mcfrisk | Jones42: my dm-verity image recipe https://gitlab.com/Linaro/trusted-reference-stack/trs/-/commit/d85a15d892b96e7bad4814eb2e193450bdc958a4 | 09:53 |
| mcfrisk | Jones42: and initrd recipe https://gitlab.com/Linaro/trustedsubstrate/meta-ledge-secure/-/blob/systemd_uki/meta-ledge-secure/recipes-ledge/images/ledge-initramfs-systemd.bb?ref_type=heads | 09:55 |
| Jones42 | mcfrisk: ah, I was about to ask how you install packages into a seperate partition. rootfs_usr_strip explains that :-) | 10:00 |
| Jones42 | I'm in this secure-boot-rabbithole for a few months now, and I'm surprised how complicated those things still are and how much manual scripting still is required | 10:02 |
| mcfrisk | Jones42: yea, hackity hack :). I add the roothash to the uki tooling which embeds it to kernel command line, and kernel passes that to systemd for mounting. uki.bbclass from https://gitlab.com/mikko.rapeli/poky/-/commit/fafbb58863cd9130a9a5100cde3cad3465209769 | 10:04 |
| mcfrisk | many of these pieces are almost(tm) ready for upstreaming, but some reference builds are needed to make sure they keep working. secure boot should not be this hard... | 10:05 |
| *** alessioigor <alessioigor!~alessioig@185.178.95.238> has quit IRC (Remote host closed the connection) | 10:07 | |
| *** alessioigor <alessioigor!~alessioig@185.178.95.238> has joined #yocto | 10:07 | |
| *** sakoman <sakoman!~sakoman@98.142.47.158> has quit IRC (Ping timeout: 264 seconds) | 10:21 | |
| *** mckoan <mckoan!~marco@host-95-229-48-41.business.telecomitalia.it> has quit IRC (Ping timeout: 256 seconds) | 10:21 | |
| *** mckoan <mckoan!~marco@host-95-229-48-41.business.telecomitalia.it> has joined #yocto | 10:21 | |
| *** sakoman <sakoman!~sakoman@98.142.47.158> has joined #yocto | 10:37 | |
| *** Guest348 <Guest348!~Guest348@ip-85-93-163-76.wscnet.cz> has joined #yocto | 10:40 | |
| *** berton <berton!uid641616@id-641616.ilkley.irccloud.com> has joined #yocto | 10:42 | |
| *** ehussain <ehussain!~Thunderbi@154.80.31.206> has quit IRC (Remote host closed the connection) | 11:16 | |
| *** ahussain <ahussain!~Thunderbi@2404:3100:182e:b76a:ad2e:c83:49de:d859> has joined #yocto | 11:16 | |
| *** ahussain is now known as ehussain | 11:18 | |
| *** Guest39 <Guest39!~Guest39@79.171.149.174> has joined #yocto | 11:27 | |
| *** Daaanct12 <Daaanct12!~danct12@user/danct12> has quit IRC (Quit: WeeChat 4.3.3) | 11:38 | |
| *** PIBA <PIBA!~PIBA@mail.anedo.de> has joined #yocto | 11:41 | |
| *** goliath <goliath!~goliath@user/goliath> has joined #yocto | 11:43 | |
| PIBA | has anyone suggestions for good trainings for yocto beginner in english or german ? | 11:44 |
| Jones42 | PIBA: german will be tough, but I can share some of my bookmarks | 11:47 |
| Jones42 | https://www.youtube.com/watch?v=XmDtz6n2I5A https://www.youtube.com/watch?v=YbLe84JCSFg https://www.youtube.com/watch?v=zCMHy2PjsaM | 11:48 |
| Jones42 | The Yocto youtube channel has some good quality videos: https://www.youtube.com/@TheYoctoProject/videos | 11:48 |
| Jones42 | Bootlin has some open source training documents: https://bootlin.com/training/yocto/ | 11:49 |
| Jones42 | Also https://a4z.gitlab.io/docs/BitBake/guide.html | 11:50 |
| Jones42 | but most of the time I just ctrl+F the https://docs.yoctoproject.org/singleindex.html or the sources | 11:50 |
| PIBA | ty I will check it out ^^ | 11:51 |
| Jones42 | as with most things, you learn by doing... prepare for a bumpy ride though... ;-) | 11:52 |
| PIBA | Yeah, I am already in it, I started with this https://www.youtube.com/watch?v=ThTl4FItfMI&list=PLD4M5FoHz-TxMfBFrDKfIS_GLY25Qsfyj&index=1 and go parallel step by step through the manual | 11:54 |
| Jones42 | be aware of the renamings. There was a change in the override syntax (from underscore to colon) and a inclusive language change https://wiki.yoctoproject.org/wiki/Inclusive_language | 11:56 |
| Jones42 | not sure when that happened though, just be aware of it and don't let it confuse you | 11:57 |
| PIBA | I noticed that point already and some other weird things XD I managed to kill my qemu with his fourth vid or at least a part of it | 12:01 |
| *** Guest39 <Guest39!~Guest39@79.171.149.174> has quit IRC (Quit: Client closed) | 12:03 | |
| mckoan | PIBA: our trainings are here https://koansoftware.com/training/ email me for details | 12:05 |
| *** Guest0 <Guest0!~Guest0@ns-02.wenglor.com> has joined #yocto | 12:05 | |
| mckoan | PIBA: online or in-person ? | 12:06 |
| Guest0 | Hello, I have a more general question: if you have a yocto based os that is build for multiple devices (x86 and aarch64) + custom applications, how can one run the automated tests for those apps for each of the devices? | 12:09 |
| PIBA | i think online is more likely mckoan | 12:09 |
| *** alessioigor <alessioigor!~alessioig@185.178.95.238> has quit IRC (Ping timeout: 250 seconds) | 12:11 | |
| mcfrisk | Guest0: one option is qemu and oeqa, see https://docs.yoctoproject.org/dev/singleindex.html#performing-automated-runtime-testing | 12:12 |
| rburton | if you want to run the tests _on target_ then oeqa can do that, although it's not used much. it should still work though... another option would be labgrid or lava. | 12:12 |
| Jones42 | or tbot | 12:14 |
| Guest0 | do they have anything to do with ptest? | 12:17 |
| mcfrisk | and a lot of board/SoC/variant specific details for automatic flashing, power control, recovery, and then the test framework for tests (or oeqa, possibly exported from bitbake build), and then the framework for managing the whole test farm and infra around it. ptest run as part of oeqa, for example. | 12:17 |
| rburton | Guest0: ptest is a way of packaging up tests inside a package so you can run them on target | 12:18 |
| rburton | so yes if you have a custom app called foo, then the recipe also packaging its own tests would be one way | 12:18 |
| Guest0 | thanks for the details, much appreciated! | 12:19 |
| *** rber|res <rber|res!~rber|res@213-225-12-86.nat.highway.a1.net> has quit IRC (Remote host closed the connection) | 12:27 | |
| *** rber|res <rber|res!~rber|res@213-225-12-86.nat.highway.a1.net> has joined #yocto | 12:28 | |
| *** florian_kc <florian_kc!~florian@port-217-146-132-69.static.as20676.net> has joined #yocto | 12:31 | |
| Guest348 | I have an archive with a pre-built application and I want to have it unpacked and the contents just copied to the image without DNF (or perhaps something else?) trying to guess what the files actually mean. | 12:35 |
| Guest348 | Regardless of whether I use bin_package class or copy the files over in do_install, DNF complains, during do_rootfs, that nothing provides some 64bit dependencies, which is probably correct, but it is absolutely out of my power to fix that, since I'm targeting arm and I can't just remove the odd parts of the app and rebuild. I also know for a fact | 12:35 |
| Guest348 | that the app works just fine if I just copy the files over. | 12:35 |
| Guest348 | Is it possible to inhibit this behavior and just make it copy the files over? | 12:35 |
| kanavin_ | Guest348, it helps if you inspect what is in the .spec for the package, and how it gets there. I think there's a way to suppress generating those auto-dependencies, but I need to see what is it specifically. | 12:44 |
| kanavin_ | you find the .spec in ${WORKDIR} for the recipe | 12:44 |
| rburton | Guest348: 32-bit arm target? | 12:44 |
| Guest348 | It's an i.MX8 so I believe it's 64-bit. | 12:46 |
| *** Guest348 <Guest348!~Guest348@ip-85-93-163-76.wscnet.cz> has quit IRC (Quit: Client closed) | 12:50 | |
| *** Guest348 <Guest348!~Guest348@ip-85-93-163-76.wscnet.cz> has joined #yocto | 12:59 | |
| Guest348 | kanavin_ there's a lot of lines like Requires: libc.so.6()(64bit). So basically all of the ones that DNF says "nothing provides" about (libdl.so.2(GLIBC_2.2.5)(64bit) libdl.so.2(GLIBC_2.3.3)(64bit) liblttng-ust.so.0()(64bit) libm.so.6(GLIBC_2.2.5)(64bit) libpthread.so.0(GLIBC_2.2.5)(64bit) librt.so.1(GLIBC_2.2.5)(64bit)) and then some. Now for how | 13:00 |
| Guest348 | it got there, my best guess is that it is automatically extracted somehow from the files I want to copy over. Since if I replace the archive with a different one that only contains text files, it copies the files to the image without any issues. | 13:00 |
| kanavin_ | Guest348, do_package does this for shared libraries. I don't remember off the top of my head how to suppress this, but there is a way. | 13:01 |
| kanavin_ | and it's not dnf-specifc, you would get the same errors with opkg or apt | 13:01 |
| Jones42 | uh, so I tried to "deltask/addtask" in a bbappend to change the task order that's set in the bbclass, but it seems as if the bbclass' addtask was executed *after* my bbappend, so my deltask is not working as intended. are there any other ideas or do I really have to create my own bbclass? | 13:05 |
| *** Guest348 <Guest348!~Guest348@ip-85-93-163-76.wscnet.cz> has quit IRC (Quit: Client closed) | 13:09 | |
| *** Saur_Home <Saur_Home!~Saur_Home@94-137-113-31.customers.ownit.se> has joined #yocto | 13:11 | |
| *** frieder <frieder!~frieder@89.244.121.50> has quit IRC (Remote host closed the connection) | 13:20 | |
| *** alessioigor <alessioigor!~alessioig@185.178.95.238> has joined #yocto | 13:20 | |
| *** Guest348 <Guest348!~Guest348@ip-85-93-163-76.wscnet.cz> has joined #yocto | 13:21 | |
| rburton | Guest348: try setting EXCLUDE_FROM_SHLIBS="1" in the recipe | 13:25 |
| rburton | that should stop the shared library depends being extracted at all | 13:25 |
| rburton | you'll be entirely responsible for ensuring depends are installed, obviously | 13:25 |
| Guest348 | kanavin_ Great tip. The do_package and do_packagedata info in ${WORKDIR}/pkgdata/runtime and ${WORKDIR}/pkgdata/runtime-reverse contains files with FILERDEPENDS:path_to_a_file: a bunch of space separated packages like libpthread.so.0(GLIBC_2.17)(64bit) and also a bunch of FILERPROVIDES which I also probably don't want. Now I just need to figure out | 13:27 |
| Guest348 | the next step. Thanks. | 13:27 |
| rburton | the issue is you've got precompiled libraries that link to specific library versions and they're either not in the sysroot when your recipe builds (ie solve that by DEPENDing on lttng-ust) or the versions don't quite match with what we're shipping. | 13:28 |
| Guest348 | rburton setting EXCLUDE_FROM_SHLIBS="1" has no effect. I did a cleanall and ran bitbake again. I'm not sure if it's related, but the ${WORKDIR}/pkgdata/shlibs2 directory was already empty even before adding this setting. | 13:31 |
| *** PIBA <PIBA!~PIBA@mail.anedo.de> has quit IRC (Quit: Client closed) | 13:35 | |
| *** Saur_Home <Saur_Home!~Saur_Home@94-137-113-31.customers.ownit.se> has quit IRC (Quit: Client closed) | 13:41 | |
| *** Saur_Home <Saur_Home!~Saur_Home@94-137-113-31.customers.ownit.se> has joined #yocto | 13:59 | |
| Guest348 | kanavin_ I found a way to supress the behavior I added | 14:00 |
| Guest348 | python package_do_filedeps() { | 14:00 |
| Guest348 | print('SKIPPING') | 14:00 |
| Guest348 | } | 14:00 |
| Guest348 | to my recipe. Is this something that looks like the right way to do that or did I do something dumb? The image builds and the files are there. | 14:00 |
| rburton | Guest348: setting SKIP_FILEDEPS="1" would do the same thing | 14:01 |
| rburton | (package_do_filedeps() calls oe.package.process_filedeps() and the first line of that is to return early if that is set) | 14:01 |
| rburton | but yes that's the function i meant when i was skimming package.py | 14:02 |
| Guest348 | I'll have to try that. The manual says SKIP_FILEDEPS is "…removal of all files from the “Provides” section of an RPM package…" and I clearly want the depends. How can I easily find the source for this that you mention? | 14:04 |
| yocton | RP: sorry about the line wrapped patch :( we recently had to change our git-sendemail config. We'll look a it and resend | 14:06 |
| RP | yocton: np, it happens | 14:15 |
| RP | yocton: I'm happy to have the fixes! | 14:15 |
| *** altru <altru!~altru@static-css-ccs-204145.business.bouyguestelecom.com> has joined #yocto | 14:18 | |
| rburton | yocton: if smtp continues to be a pain, b4 send works well | 14:20 |
| RP | v2 is applied, thanks! | 14:21 |
| yocton | rburton: does it integrate with Google Oauth stuff? | 14:21 |
| rburton | yocton: it does something like sending to lore which then forwards | 14:21 |
| yocton | rburton: Oooohhhh sounds lovely | 14:22 |
| *** Guest348 <Guest348!~Guest348@ip-85-93-163-76.wscnet.cz> has quit IRC (Quit: Client closed) | 14:27 | |
| *** Guest0 <Guest0!~Guest0@ns-02.wenglor.com> has quit IRC (Quit: Client closed) | 14:36 | |
| *** altru <altru!~altru@static-css-ccs-204145.business.bouyguestelecom.com> has quit IRC (Ping timeout: 250 seconds) | 14:40 | |
| *** jmiehe <jmiehe!~Thunderbi@user/jmiehe> has joined #yocto | 15:01 | |
| *** jmiehe <jmiehe!~Thunderbi@user/jmiehe> has quit IRC (Quit: jmiehe) | 15:06 | |
| *** beroset <beroset!~beroset@2600:1700:f90:2250::1d> has joined #yocto | 15:15 | |
| beroset | I've submitted an upstream patch to cracklib that should allow us to eliminate the currently maintained yocto patch for cracklib: https://github.com/cracklib/cracklib/pull/86 | 15:17 |
| beroset | The patch uses various htole* functions, but the original 2015 patch in yocto says "We can't use the endian.h, htobe* and be*toh functions because they are not available on older versions of glibc, such as that found in RHEL 5.9." | 15:19 |
| beroset | Is that still a concern? | 15:19 |
| *** xmn <xmn!~xmn@2600:4040:9398:a200:f9f1:2818:d9d5:2809> has joined #yocto | 15:19 | |
| RP | beroset: I suspect not, thankfully! | 15:24 |
| *** mbulut <mbulut!~mbulut@ip1f128e48.dynamic.kabel-deutschland.de> has quit IRC (Ping timeout: 268 seconds) | 15:32 | |
| beroset | I was hoping that was the case! The idea was to fix a problem, not to cause an additional one. | 15:38 |
| *** alessioigor <alessioigor!~alessioig@185.178.95.238> has quit IRC (Remote host closed the connection) | 15:45 | |
| *** alessioigor <alessioigor!~alessioig@185.178.95.238> has joined #yocto | 15:46 | |
| *** alessioigor <alessioigor!~alessioig@185.178.95.238> has quit IRC (Remote host closed the connection) | 15:48 | |
| RP | beroset: thankfully we have moved on since then! | 15:49 |
| *** rbox <rbox!~user@user/rbox> has quit IRC (Quit: ZNC 1.8.2 - https://znc.in) | 15:49 | |
| *** rbox <rbox!~user@user/rbox> has joined #yocto | 15:51 | |
| RP | beroset: it is nice to reduce the number of patches we're carrying | 15:52 |
| beroset | That was my intent. Is there a list of such patches I could consult? There may be more I can do to upstream them. | 15:52 |
| RP | beroset: you grep for Upstream-Status: on OE-Core to get an idea of the status of them | 15:53 |
| beroset | RP: thanks! I'll try that. | 15:54 |
| *** florian <florian!~florian@port-217-146-132-69.static.as20676.net> has quit IRC (Quit: Ex-Chat) | 16:03 | |
| *** florian_kc <florian_kc!~florian@port-217-146-132-69.static.as20676.net> has quit IRC (Ping timeout: 256 seconds) | 16:06 | |
| RP | abelloni: the reproducibility issues look like some kind of world build issue with virtual/ PROVIDES recipes | 16:09 |
| RP | abelloni: what I don't understand is what changed :( | 16:09 |
| *** zpfvo <zpfvo!~fvo@185-59-142-46.pool.kielnet.net> has quit IRC (Remote host closed the connection) | 16:09 | |
| khem | RP: seeing https://snips.sh/f/G-UyWJwYxG quite often these days when cancelling ( Ctrl+c ) a bitbake invocation the sad part is it persists on subsequent runs unless -ccleansstate is run for the failing recipe and it usually runs into next recipe which was also perhaps building something when CTRTL+c was used and list goes on. Practically deleting tmp is the reasonable solution to make progress | 16:10 |
| khem | which causes recipes from devtool workspace to rebuild even nothing changed for them they are not used from sstate for whatever reason | 16:11 |
| RP | khem: always glibc-locale or various recipes? | 16:11 |
| khem | it could be any recipe | 16:11 |
| RP | khem: it sounds like cleanup is being done outside pseudo and the pseudo db isn't updated :( | 16:12 |
| khem | yeah I was suspecting that pseudo is being bypassed somehow, but dont see particularly how will that happen. The build is running inside a container | 16:14 |
| RP | khem: it is more that files will be deleted when pseudo isn't preloaded into memory | 16:14 |
| khem | I have seen this on native system too, so I think container is not in picture here | 16:14 |
| RP | khem: there are two possible improvements: a) when pseudo loads, iterate the DB and delete any entries not present on disk, or b) when it hits this corner case, check if something exists on disk and if not, delete the entry | 16:16 |
| RP | fray: thoughts? | 16:16 |
| mckoan | hello, I'm not an expert at kernel 'audit'. I am trying to enable auditd in my minimal image but I get errors with auditctl. Yocto kirkstone | 16:17 |
| khem | yeah, IMO a robust cleanup would go long way, because I have seen this being reported by few devs as well | 16:17 |
| RP | khem: it would be slow and not necessarily catch all issues as there are genuine ways this can be a real problem | 16:18 |
| mckoan | root@qemuarm:~# auditctl -w /etc/passwd -p wa -k user_identity | 16:19 |
| mckoan | Error sending add rule data request (Invalid argument) | 16:19 |
| RP | khem: perhaps a cleanup command... | 16:19 |
| mckoan | Question: do I need SElinux to use auditd or it should work as is? | 16:19 |
| *** ehussain <ehussain!~Thunderbi@2404:3100:182e:b76a:ad2e:c83:49de:d859> has quit IRC (Quit: ehussain) | 16:27 | |
| *** rob_w_ <rob_w_!~bob@2001:a61:603a:7001:5eb6:68f8:905a:1bc9> has quit IRC (Ping timeout: 240 seconds) | 16:28 | |
| khem | RP: yeah even if its a cmd that will help a lot | 16:28 |
| khem | far better than deleting tmp and rebuilding browser from devtool workspace | 16:28 |
| *** vthor <vthor!~thor@user/vthor> has quit IRC (Ping timeout: 268 seconds) | 16:29 | |
| *** rob_w <rob_w!~rob@2001:a61:603a:7001:cac:9298:129d:72c0> has quit IRC (Quit: Leaving) | 16:33 | |
| RP | khem: someone just needs to write it. Feel free to file a bug about needing such a tool | 16:35 |
| *** rfuentess <rfuentess!~rfuentess@lfbn-lyo-1-1566-5.w90-52.abo.wanadoo.fr> has quit IRC (Remote host closed the connection) | 16:39 | |
| *** vthor <vthor!~thor@2806:10a6:6:8a03:bb8d:6cd9:4f3a:1a3d> has joined #yocto | 16:43 | |
| *** mckoan is now known as mckoan|away | 16:53 | |
| *** leon-anavi <leon-anavi!~Leon@46.55.231.62> has quit IRC (Remote host closed the connection) | 17:00 | |
| *** Saur_Home <Saur_Home!~Saur_Home@94-137-113-31.customers.ownit.se> has quit IRC (Quit: Client closed) | 17:15 | |
| *** Saur_Home <Saur_Home!~Saur_Home@94-137-113-31.customers.ownit.se> has joined #yocto | 17:15 | |
| *** florian_kc <florian_kc!~florian@dynamic-077-177-163-182.77.177.pool.telefonica.de> has joined #yocto | 17:53 | |
| *** florian_kc <florian_kc!~florian@dynamic-077-177-163-182.77.177.pool.telefonica.de> has quit IRC (Ping timeout: 255 seconds) | 17:58 | |
| *** leon-anavi <leon-anavi!~Leon@46.55.231.62> has joined #yocto | 18:02 | |
| *** leon-anavi <leon-anavi!~Leon@46.55.231.62> has quit IRC (Remote host closed the connection) | 18:12 | |
| *** florian_kc <florian_kc!~florian@dynamic-077-177-163-182.77.177.pool.telefonica.de> has joined #yocto | 18:28 | |
| *** berton <berton!uid641616@id-641616.ilkley.irccloud.com> has quit IRC (Quit: Connection closed for inactivity) | 18:52 | |
| *** PaowZ <PaowZ!~Vince@2a01:e0a:144:d020:2165:857b:e2ea:f3b9> has quit IRC (Ping timeout: 240 seconds) | 18:54 | |
| *** xmn <xmn!~xmn@2600:4040:9398:a200:f9f1:2818:d9d5:2809> has quit IRC (Ping timeout: 246 seconds) | 19:00 | |
| *** Jones42 <Jones42!~Jones42@user/Jones42> has quit IRC (Ping timeout: 246 seconds) | 19:15 | |
| *** RyanEatmon <RyanEatmon!~reatmon@192.91.75.29> has quit IRC (Remote host closed the connection) | 19:17 | |
| *** RyanEatmon <RyanEatmon!~reatmon@192.91.75.12> has joined #yocto | 19:17 | |
| vvn | hi there -- in order to provide sstate and downloads mirrors to developers built by the CI, do you guys sync DL_DIR/SSTATE_DIR after a successful CI build, or do you setup the CI to use the mirrors directly as its DL_DIR/SSTATE_DIR? | 19:39 |
| RP | vvn: more the latter | 19:40 |
| *** alessioigor <alessioigor!~alessioig@185.178.95.238> has joined #yocto | 19:42 | |
| vvn | RP: is the latter robust in case of failing builds? e.g. if you have broken recipes, you'll end up polutting the mirrors? | 19:43 |
| *** alessioigor <alessioigor!~alessioig@185.178.95.238> has quit IRC (Remote host closed the connection) | 19:43 | |
| RP | vvn: the hashes will likely be different so the pollution generally doesn't matter | 19:46 |
| vvn | ok, it may just result in wasting a bit of space, but nothing worrying I presume | 19:47 |
| RP | vvn: we're not worrying about it | 19:47 |
| vvn | I guess with the former method I can use PREMIRRORS and SSTATE_MIRRORS in my site.conf for both the CI and the developers | 19:54 |
| *** rber|res <rber|res!~rber|res@213-225-12-86.nat.highway.a1.net> has quit IRC (Read error: Connection reset by peer) | 20:16 | |
| *** Saur_Home2 <Saur_Home2!~Saur_Home@94-137-113-31.customers.ownit.se> has joined #yocto | 20:17 | |
| *** Saur_Home <Saur_Home!~Saur_Home@94-137-113-31.customers.ownit.se> has quit IRC (Ping timeout: 250 seconds) | 20:20 | |
| *** Jones42 <Jones42!~Jones42@user/Jones42> has joined #yocto | 20:24 | |
| kanavin_ | vvn, syncing separately means there's a window of time where latest sstate isn't available, and developers will face long local builds | 20:24 |
| *** Jones42 <Jones42!~Jones42@user/Jones42> has quit IRC (Ping timeout: 255 seconds) | 20:28 | |
| vvn | that's a good point, the sync time isn't negligible | 20:29 |
| beroset | kanavin_: guess what got closed today? https://github.com/cracklib/cracklib/issues/74 | 20:30 |
| kanavin_ | vvn, the good news is, you can write to DL_DIR and SSTATE_DIR directly, and share that as a r/o http thing | 20:30 |
| vvn | kanavin_: can you have PREMIRRORS/DL_DIR and SSTATE_MIRRORS/SSTATE_DIR pointing to the same content respectively? (wondering if the CI and developer can share the same site configuration) | 20:35 |
| vvn | it's a bit pointless to have PREMIRRORS and SSTATE_MIRRORS defined for the CI, but it would allows to have this configuration statically defined in site.conf for the company | 20:36 |
| kanavin_ | vvn, that I don't know | 20:36 |
| kanavin_ | but I would say yes | 20:37 |
| kanavin_ | beroset, yeah I got notified by email. Is there a version update and a patch we can drop associated with that? | 20:38 |
| RP | khem: I did look through our gdb patches and was tempted to drop them all and see what still breaks | 20:40 |
| beroset | kanavin_: yes to both. The new version of cracklibhasn't been released yet, but is planned to be 2.10. I'm not sure how to point to the patch, but I think it's the only one currently associated with cracklib. | 20:41 |
| beroset | Unrelated to that, I'm moving a project from mickledore to scarthgap. Do I need to delete my tmp-glibc directory before rebuilding? Or is there a smarter way to do such an upgrade? | 20:45 |
| kanavin_ | beroset, in theory that isn't necessary. but in practice bitbake will more or less delete all recipe workdirs anyway due to having to rebuild them | 20:47 |
| beroset | kanavin_, thanks! | 20:49 |
| *** mbulut <mbulut!~mbulut@ip1f128e48.dynamic.kabel-deutschland.de> has joined #yocto | 20:51 | |
| *** alessioigor <alessioigor!~alessioig@185.178.95.238> has joined #yocto | 21:00 | |
| *** Kubu_work <Kubu_work!~kubu@lfbn-nan-1-335-137.w82-120.abo.wanadoo.fr> has quit IRC (Quit: Leaving.) | 21:04 | |
| *** alessioigor <alessioigor!~alessioig@185.178.95.238> has quit IRC (Remote host closed the connection) | 21:17 | |
| *** alessioigor <alessioigor!~alessioig@185.178.95.238> has joined #yocto | 21:17 | |
| *** mvlad <mvlad!~mvlad@2a02:2f05:8111:a400:e88e:21ff:fe65:be18> has quit IRC (Remote host closed the connection) | 21:29 | |
| *** alessioigor <alessioigor!~alessioig@185.178.95.238> has quit IRC (Remote host closed the connection) | 21:39 | |
| *** tangofoxtrot <tangofoxtrot!~tangofoxt@user/tangofoxtrot> has quit IRC (Remote host closed the connection) | 22:14 | |
| *** tangofoxtrot <tangofoxtrot!~tangofoxt@user/tangofoxtrot> has joined #yocto | 22:19 | |
| *** geoffhp <geoffhp!~geoff@syn-107-185-062-133.res.spectrum.com> has quit IRC (Quit: Leaving) | 22:39 | |
| *** warthog9 <warthog9!warthog9@proxy.monkeyblade.net> has quit IRC (Quit: Leaving) | 23:03 | |
| *** warthog9 <warthog9!warthog9@proxy.monkeyblade.net> has joined #yocto | 23:06 | |
| *** florian_kc <florian_kc!~florian@dynamic-077-177-163-182.77.177.pool.telefonica.de> has quit IRC (Ping timeout: 252 seconds) | 23:27 | |
| *** ssweeny <ssweeny!c6d723798b@user/ssweeny> has quit IRC (Quit: Gateway shutdown) | 23:35 | |
| *** ssweeny <ssweeny!c6d723798b@user/ssweeny> has joined #yocto | 23:35 | |
Generated by irclog2html.py 4.0.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!