| *** 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:34 | |
| *** davidinux <davidinux!~davidinux@45.11.80.26> has quit IRC (Ping timeout: 240 seconds) | 01:04 | |
| *** davidinux <davidinux!~davidinux@45.11.80.32> has joined #yocto | 01:06 | |
| *** jclsn <jclsn!~jclsn@2a04:4540:6527:8100:2ce:39ff:fecf:efcd> has quit IRC (Ping timeout: 256 seconds) | 01:17 | |
| *** jclsn <jclsn!~jclsn@2a04:4540:6541:2200:2ce:39ff:fecf:efcd> has joined #yocto | 01:19 | |
| *** geoffhp <geoffhp!~geoff@syn-023-241-067-081.res.spectrum.com> has joined #yocto | 03:33 | |
| *** parthiban <parthiban!~parthiban@122.165.245.213> has joined #yocto | 04:06 | |
| *** parthiban <parthiban!~parthiban@122.165.245.213> has left #yocto | 04:06 | |
| *** MrCryo <MrCryo!~MrCryo@user/MrCryo> has joined #yocto | 04:30 | |
| *** MrCryo <MrCryo!~MrCryo@user/MrCryo> has quit IRC (Remote host closed the connection) | 04:33 | |
| *** Jones42_ <Jones42_!~Jones42@user/Jones42> has quit IRC (Ping timeout: 252 seconds) | 05:24 | |
| *** rob_w <rob_w!~bob@host-82-135-31-73.customer.m-online.net> has joined #yocto | 06:02 | |
| *** enok <enok!~Thunderbi@94.191.153.21> has joined #yocto | 06:08 | |
| *** rfuentess <rfuentess!~rfuentess@154.45.232.215> has joined #yocto | 06:18 | |
| *** Kubu_work <Kubu_work!~kubu@lfbn-nan-1-335-137.w82-120.abo.wanadoo.fr> has quit IRC (Quit: Leaving.) | 06:27 | |
| *** michael_e <michael_e!~michael_e@user/michael-e:30278> has joined #yocto | 06:30 | |
| *** michael_e <michael_e!~michael_e@user/michael-e:30278> has quit IRC (Client Quit) | 06:32 | |
| *** ederibaucourt <ederibaucourt!~ederibauc@lmontsouris-657-1-69-118.w80-15.abo.wanadoo.fr> has quit IRC (Quit: ZNC 1.8.2 - https://znc.in) | 06:34 | |
| *** ederibaucourt <ederibaucourt!~ederibauc@lmontsouris-657-1-69-118.w80-15.abo.wanadoo.fr> has joined #yocto | 06:34 | |
| *** ctraven <ctraven!~ctraven@139.68.81.2> has quit IRC (Ping timeout: 268 seconds) | 06:35 | |
| *** ctraven <ctraven!~ctraven@139.68.81.2> has joined #yocto | 06:35 | |
| *** goliath <goliath!~goliath@user/goliath> has joined #yocto | 06:36 | |
| *** enok <enok!~Thunderbi@94.191.153.21> has quit IRC (Ping timeout: 240 seconds) | 06:36 | |
| *** zpfvo <zpfvo!~fvo@i59F5CE7A.versanet.de> has joined #yocto | 06:38 | |
| *** ablu <ablu!~m-bfyrfh@user/Ablu> has quit IRC (Ping timeout: 255 seconds) | 06:45 | |
| *** ablu <ablu!~m-bfyrfh@user/Ablu> has joined #yocto | 06:45 | |
| *** shoragan_ is now known as shoragan | 06:49 | |
| *** mckoan|away is now known as mckoan | 07:04 | |
| *** c-thaler <c-thaler!~c-thaler@213.221.121.44> has joined #yocto | 07:21 | |
| *** polprog <polprog!~ath0@user/polprog> has quit IRC (Ping timeout: 272 seconds) | 07:22 | |
| *** enok <enok!~Thunderbi@94.191.152.74> has joined #yocto | 07:48 | |
| *** leon-anavi <leon-anavi!~Leon@46.55.231.62> has joined #yocto | 07:49 | |
| *** Kubu_work <Kubu_work!~kubu@202-122-190-109.dsl.ovh.fr> has joined #yocto | 07:57 | |
| *** enok <enok!~Thunderbi@94.191.152.74> has quit IRC (Quit: enok) | 08:18 | |
| *** enok <enok!~Thunderbi@94.191.152.74.mobile.tre.se> has joined #yocto | 08:19 | |
| *** halloy4985 <halloy4985!~halloy498@165.225.124.180> has joined #yocto | 08:21 | |
| halloy4985 | Hi , Is there a way to revert a patch applied by cleansstate | 08:23 |
|---|---|---|
| JaMa | if cleansstate task applies patches for you than you live in very weird universe | 08:28 |
| halloy4985 | Haha .I mean clenasstate doesnt do it for me . Do you have a way to revert patches applied on EXTERNAL_SRC SRC_URI meaning source is locally not fetched. | 08:32 |
| *** halloy4985 is now known as max_eip | 08:32 | |
| JaMa | remove them from SRC_URI if you don't want them to be applied | 08:33 |
| *** Jones42 <Jones42!~Jones42@user/Jones42> has joined #yocto | 08:38 | |
| max_eip | Bro i want to apply the patch. But dont want to commit to mainline. | 08:40 |
| max_eip | Problem is if i cleansstate , i can see some files modified which cause no problem just i dont like . I want cleansstate to do_unpatch so no change is observed in my local code. | 08:41 |
| JaMa | first you wanted to revert it now you want to apply it, if you use EXTERNAL_SRC (I assume you meant EXTERNALSRC) then you're responsible for applying the changes there bro | 08:41 |
| max_eip | I think we miscommunicated. Thanks for your time. | 08:43 |
| LetoThe2nd | JaMa: hey bro I want a beer | 08:45 |
| JaMa | LetoThe2nd: I need beer, now! :) | 08:46 |
| LetoThe2nd | JaMa: apply from external source? | 08:47 |
| JaMa | sometimes, when internal fridge source gets empty | 08:47 |
| *** max_eip <max_eip!~halloy498@165.225.124.180> has quit IRC (Remote host closed the connection) | 08:49 | |
| *** enok <enok!~Thunderbi@94.191.152.74.mobile.tre.se> has quit IRC (Ping timeout: 255 seconds) | 08:51 | |
| *** sukbeom6 <sukbeom6!~sukbeom@121.172.255.83> has joined #yocto | 08:59 | |
| *** shivamurthy_ <shivamurthy_!sid359794@id-359794.helmsley.irccloud.com> has joined #yocto | 08:59 | |
| *** OnkelUll_ <OnkelUll_!~user@dude03.red.stw.pengutronix.de> has joined #yocto | 08:59 | |
| *** wCPO0 <wCPO0!~wCPO@mail.klausen.dk> has joined #yocto | 08:59 | |
| *** rsalveti_ <rsalveti_!sid117878@id-117878.uxbridge.irccloud.com> has joined #yocto | 09:00 | |
| *** dmoseley_ <dmoseley_!~dmoseley@d4-50-177-189.evv.wideopenwest.com> has joined #yocto | 09:00 | |
| *** benkard <benkard!~mulk@p5b112e4a.dip0.t-ipconnect.de> has joined #yocto | 09:00 | |
| *** fullstop_ <fullstop_!~fullstop@user/fullstop> has joined #yocto | 09:00 | |
| *** rsalveti <rsalveti!sid117878@id-117878.uxbridge.irccloud.com> has quit IRC (Read error: Connection reset by peer) | 09:01 | |
| *** dl9pf <dl9pf!sid395223@user/dl9pf> has quit IRC (Read error: Connection reset by peer) | 09:01 | |
| *** wCPO <wCPO!~wCPO@mail.klausen.dk> has quit IRC (Read error: Connection reset by peer) | 09:01 | |
| *** mulk <mulk!~mulk@p5b112e4a.dip0.t-ipconnect.de> has quit IRC (Read error: Connection reset by peer) | 09:01 | |
| *** OnkelUlla <OnkelUlla!~user@dude03.red.stw.pengutronix.de> has quit IRC (Read error: Connection reset by peer) | 09:01 | |
| *** sukbeom <sukbeom!~sukbeom@121.172.255.83> has quit IRC (Read error: Connection reset by peer) | 09:01 | |
| *** shivamurthy <shivamurthy!sid359794@id-359794.helmsley.irccloud.com> has quit IRC (Ping timeout: 268 seconds) | 09:01 | |
| *** patersonc <patersonc!sid614485@id-614485.hampstead.irccloud.com> has quit IRC (Ping timeout: 268 seconds) | 09:01 | |
| *** denix <denix!sid553794@id-553794.ilkley.irccloud.com> has quit IRC (Ping timeout: 268 seconds) | 09:01 | |
| *** fullstop <fullstop!~fullstop@user/fullstop> has quit IRC (Excess Flood) | 09:01 | |
| *** patersonc_ <patersonc_!sid614485@id-614485.hampstead.irccloud.com> has joined #yocto | 09:01 | |
| *** dl9pf <dl9pf!sid395223@id-395223.helmsley.irccloud.com> has joined #yocto | 09:01 | |
| *** dmoseley <dmoseley!~dmoseley@d4-50-177-189.evv.wideopenwest.com> has quit IRC (Read error: Connection reset by peer) | 09:01 | |
| *** denix <denix!sid553794@id-553794.ilkley.irccloud.com> has joined #yocto | 09:01 | |
| *** asriel <asriel!~asriel@user/asriel> has quit IRC (Ping timeout: 268 seconds) | 09:01 | |
| *** shivamurthy_ is now known as shivamurthy | 09:01 | |
| *** rsalveti_ is now known as rsalveti | 09:01 | |
| *** wCPO0 is now known as wCPO | 09:01 | |
| *** benkard is now known as mulk | 09:01 | |
| *** sukbeom6 is now known as sukbeom | 09:01 | |
| *** asriel <asriel!~asriel@user/asriel> has joined #yocto | 09:01 | |
| *** fullstop_ is now known as fullstop | 09:02 | |
| *** enok <enok!~Thunderbi@c-1e4ce655.06-290-73746f71.bbcust.telenor.se> has joined #yocto | 09:05 | |
| *** mvlad <mvlad!~mvlad@2a02:2f05:8810:9600:e88e:21ff:fe65:be18> has joined #yocto | 09:08 | |
| *** OnkelUll_ is now known as OnkelUlla | 09:08 | |
| *** mbulut__ <mbulut__!~mbulut@ip1f128e51.dynamic.kabel-deutschland.de> has joined #yocto | 09:09 | |
| *** ardo <ardo!~ardo@host-80-180-168-240.pool80180.interbusiness.it> has quit IRC (Ping timeout: 246 seconds) | 09:28 | |
| * RP wonders if we can merge the remaining unpack change with the fatal error for S=WORKDIR now | 09:46 | |
| JaMa | RP: I'm seeing quite a few failures in meta-virtualization and meta-security from UNPACKDIR changes (so I'm more concerned than with gcc-14) | 09:47 |
| JaMa | I was also thinking about re-sending https://lists.openembedded.org/g/openembedded-core/message/197098 but didn't want to add another thing on your mind or AB queue :) | 09:48 |
| RP | JaMa: other layers haven't adapated to the workdir changes yet, but they kind of can't/won't until I make things error | 09:49 |
| RP | JaMa: at least that patch won't break core :) | 09:50 |
| JaMa | yeah, I'm just concerned when these big changes land so soon after each other (which will make the triage of build failures in other layers more complicated) and people might not notice the "silent breakage" like ross did in "gawk: fix readline detection" | 09:51 |
| JaMa | I'm glad I had gcc-14 in our world builds for couple months to catch all issues caused by that before the UNPACKDIR change lands, but other people maybe didn't do this in time | 09:52 |
| *** Guest13 <Guest13!~Guest13@132.198.137.78.rev.vodafone.pt> has joined #yocto | 09:53 | |
| Guest13 | regarding to my issue yesterday with samba rburton , looks like the issue is when i select a different machine (colibri-imx6), it works fine with tegra for example.. where can i start | 09:54 |
| JaMa | Guest13: bitbake-getvar | 09:54 |
| Guest13 | JaMa for what? | 09:55 |
| JaMa | Guest13: SRC_URI, LIC_FILES_CHKSUM, DL_DIR, .. | 09:55 |
| rburton | JaMa: i do try and look at the buildhistory for most patch series but don't do it all the time | 09:55 |
| JaMa | rburton: yes, buildhistory is great and thank you for looking at it | 09:56 |
| rburton | Guest13: maybe colibri-imx8 broke samba. with a fresh poky and meta-oe, build samba for qemuarm. if that works, then its the BSP or your tooling or some other weird mangled build tree problem. | 09:56 |
| JaMa | rburton: I wouldn't have noticed this one as we have PREFERRED_VERSION_gawk = "3.1.5" (cough gplv2) | 09:57 |
| RP | JaMa: the configure breakage is worrying :/ | 09:58 |
| JaMa | RP: yes, I have seen few of those, but luckily they were fatal for what was explicitly enabled | 09:58 |
| RP | logically I should wait and let gcc 14 settle. My own sanity say I should merge this and move on :/ | 09:59 |
| rburton | hm i wonder if its possible to extract the autoconf test list and results | 10:03 |
| * rburton has a cunning plan | 10:05 | |
| *** rob_w <rob_w!~bob@host-82-135-31-73.customer.m-online.net> has quit IRC (Remote host closed the connection) | 10:16 | |
| *** rob_w <rob_w!~bob@host-82-135-31-73.customer.m-online.net> has joined #yocto | 10:17 | |
| *** ardo <ardo!~ardo@host-79-33-76-22.retail.telecomitalia.it> has joined #yocto | 10:17 | |
| Guest13 | interesting, my bbappend file was messing samba's fetch up.... am confused ;_: | 10:26 |
| Guest13 | FILESEXTRAPATHS:prepend := "${THISDIR}/files:" | 10:26 |
| Guest13 | SRC_URI:colibri-imx6 = " file://imx6/smb.conf" | 10:26 |
| Guest13 | SRC_URI:jetson-tx2-devkit = " file://tx2/smb.conf" | 10:26 |
| Guest13 | do_install:append:colibri-imx6() { | 10:26 |
| Guest13 | DST=${D}/etc/samba/smb.conf | 10:26 |
| Guest13 | install -d ${DST} | 10:26 |
| Guest13 | install -m 0644 ${WORKDIR}/smb.conf ${DST} | 10:26 |
| Guest13 | } | 10:26 |
| Guest13 | do_install:append:jetson-tx2-devkit() { | 10:26 |
| Guest13 | DST=${D}/etc/samba/smb.conf | 10:26 |
| Guest13 | install -d ${DST} | 10:26 |
| Guest13 | install -m 0644 ${WORKDIR}/smb.conf ${DST} | 10:27 |
| Guest13 | } | 10:27 |
| Guest13 | FILES:${PN} += "/etc/samba/smb.conf" | 10:27 |
| *** rob_w <rob_w!~bob@host-82-135-31-73.customer.m-online.net> has quit IRC (Remote host closed the connection) | 10:30 | |
| JaMa | Guest13: SRC_URI:colibri-imx6 abd SRC_URI:jetson-tx2-devkit are obviously wrong, maybe you wanted to use :append:override here | 10:32 |
| rburton | Guest13: yeah that would be utterly breaking the fetch | 10:34 |
| rburton | Guest13: mainly it _does not download the sources_ | 10:34 |
| rburton | golden rule of "why is this thing behaving weird": did you break it? verify it works without your local changes first. | 10:35 |
| Guest13 | ahhh, i was overriding the SRC_URI | 10:35 |
| Guest13 | instead of adding/appending the files | 10:35 |
| JaMa | yes and using bitbake-getvar or bitbake -e if you don't understand the syntax at all | 10:35 |
| rburton | for example "bitbake-getvar -r samba SRC_URI" will show that there is no tarball in the SRC_URI entry | 10:36 |
| JaMa | well use bitbake-getvar even if you understand the syntax well, because one can always for get about some nasty .bbappend or .inc file hiding somewhere | 10:36 |
| *** Guest13 <Guest13!~Guest13@132.198.137.78.rev.vodafone.pt> has quit IRC (Quit: Client closed) | 10:38 | |
| mcfrisk | I always check my changes with bitbake -e. Even trivial things may not be so trivial when a lot of layers, bbappends etc are involved and a silly monkey (me) banging the keyboard with typos etc... | 10:38 |
| *** florian <florian!~florian@port-217-146-132-69.static.as20676.net> has quit IRC (Ping timeout: 252 seconds) | 10:48 | |
| *** florian <florian!~florian@port-217-146-132-69.static.as20676.net> has joined #yocto | 10:51 | |
| *** Esben <Esben!~Srain@user/Esben> has joined #yocto | 11:01 | |
| *** Vonter <Vonter!~Vonter@user/vonter> has quit IRC (Ping timeout: 260 seconds) | 11:04 | |
| *** lexano <lexano!~lexano@pool-174-119-69-134.cpe.net.cable.rogers.com> has joined #yocto | 11:07 | |
| *** florian__ <florian__!~florian@port-217-146-132-69.static.as20676.net> has joined #yocto | 11:12 | |
| *** Vonter <Vonter!~Vonter@user/vonter> has joined #yocto | 11:16 | |
| *** krissmaster <krissmaster!~kriss@213.239.83.90> has joined #yocto | 11:17 | |
| *** florian <florian!~florian@port-217-146-132-69.static.as20676.net> has quit IRC (Ping timeout: 268 seconds) | 11:17 | |
| *** florian <florian!~florian@port-217-146-132-69.static.as20676.net> has joined #yocto | 11:19 | |
| *** OnkelUlla <OnkelUlla!~user@dude03.red.stw.pengutronix.de> has quit IRC (Remote host closed the connection) | 11:25 | |
| *** polprog <polprog!~ath0@user/polprog> has joined #yocto | 11:32 | |
| *** jmiehe <jmiehe!~Thunderbi@user/jmiehe> has joined #yocto | 11:34 | |
| *** rber|res <rber|res!~rber|res@089144210060.atnat0019.highway.a1.net> has quit IRC (Read error: Connection reset by peer) | 11:52 | |
| *** wooosaiiii <wooosaiiii!~Thunderbi@89-212-21-243.static.t-2.net> has quit IRC (Quit: wooosaiiii) | 12:05 | |
| *** wooosaiiii <wooosaiiii!~Thunderbi@89-212-21-243.static.t-2.net> has joined #yocto | 12:05 | |
| *** OnkelUlla <OnkelUlla!~user@dude03.red.stw.pengutronix.de> has joined #yocto | 12:13 | |
| RP | process_possible_migrations() in runqueue is taking over 1200s to complete a migration pass :( | 12:19 |
| RP | looks like it is stuck in unihash queries | 12:19 |
| *** Jones42 <Jones42!~Jones42@user/Jones42> has quit IRC (Ping timeout: 260 seconds) | 12:31 | |
| *** Jones42 <Jones42!~Jones42@user/Jones42> has joined #yocto | 12:36 | |
| *** enok <enok!~Thunderbi@c-1e4ce655.06-290-73746f71.bbcust.telenor.se> has quit IRC (Ping timeout: 264 seconds) | 12:39 | |
| *** wooosaiiii <wooosaiiii!~Thunderbi@89-212-21-243.static.t-2.net> has quit IRC (Quit: wooosaiiii) | 12:39 | |
| *** wooosaiiii <wooosaiiii!~Thunderbi@89-212-21-243.static.t-2.net> has joined #yocto | 12:40 | |
| RP | JPEW: around? I'm seeing some hashserver performance issues, was there a way to get server statistics ? | 12:58 |
| RP | JPEW: I've written up my findings so far and emailed | 13:07 |
| JPEW | I'm in and out this morning. 'bitbake-hashclient stats' (I think that's the command) might be useful | 13:09 |
| *** c-thaler <c-thaler!~c-thaler@213.221.121.44> has quit IRC (Quit: Client closed) | 13:10 | |
| RP | JPEW: thanks, that is what I wasn't spotting | 13:13 |
| RP | bitbake-hashclient --address wss://hashserv.yoctoproject.org/ws stats gives "average": 0.06250257539454776 | 13:13 |
| RP | For 38000 tasks, that would be a problem :( | 13:13 |
| JPEW | Ya | 13:13 |
| RP | locally it is "average": 0.0004462178160857849 | 13:13 |
| JPEW | I wonder if the support for parallel queries would help | 13:14 |
| JPEW | Is the server CPU bound? | 13:16 |
| RP | JPEW: I don't have access to the server, we'll need michael for that. I'm at least trying to give us a way to quantify and show where the issue is | 13:17 |
| JPEW | Ya. I'll see if I can dig up the parallel patches and you can see if they help | 13:18 |
| JaMa | "average": 0.00014738774137496095 (over local unix://) I win :) | 13:20 |
| *** enok <enok!~Thunderbi@c-1e4ce655.06-290-73746f71.bbcust.telenor.se> has joined #yocto | 13:23 | |
| *** Kubu_work <Kubu_work!~kubu@202-122-190-109.dsl.ovh.fr> has quit IRC (Ping timeout: 268 seconds) | 13:36 | |
| *** Jones42 <Jones42!~Jones42@user/Jones42> has quit IRC (Remote host closed the connection) | 13:37 | |
| *** Jones42 <Jones42!~Jones42@212.121.145.5> has joined #yocto | 13:38 | |
| JPEW | RP: Parallel support is already in; is BB_HASHSERVE_MAX_PARALLEL set on the AB? | 13:44 |
| RP | JPEW: it is not. What should we set that to? | 13:49 |
| RP | JPEW: if the problematic code is doing this: https://git.yoctoproject.org/poky/commit/?h=master-next&id=37c0c8890261cc0e52239cdd70844653fa1c91d3 (i.e. single get_unihash() calls), would we benefit from that? | 13:50 |
| JPEW | Ah, ya, that would not help | 13:51 |
| JPEW | Wait, that is parellel | 13:52 |
| RP | JPEW: I'm making it more parallel with that patch? | 13:52 |
| RP | (which is unmerged) | 13:52 |
| JPEW | Ah, OK. Yes, that looks correct and should help | 13:52 |
| RP | JPEW: I don't think it will change much :(. What is a reasonable value for that variable? 100? | 13:53 |
| JPEW | You can try 100 I guess, but that seems a little high to me, at least until we can verify that the hashserve itself can actually handle 100 requests (e.g. doesn't become CPU bound, run out of TCP connections, etc.) | 13:54 |
| JPEW | I suppose 100 might at least tell us if it will fix the problem | 13:55 |
| *** Xagen <Xagen!~Xagen@syn-098-006-114-013.biz.spectrum.com> has joined #yocto | 13:55 | |
| RP | JPEW: I can put 10 into the configs, see if it helps. Setting 100 locally didn't seem to speed things up that much | 13:56 |
| JPEW | It won't since the local server can't parallelize the SQL queries | 13:56 |
| RP | JPEW: I was trying against the public server | 13:57 |
| RP | JPEW: it is bad. https://valkyrie.yoctoproject.org/#/builders/17/builds/13 - 1hour 20 and still not past setting up the tasks :( | 13:59 |
| JPEW | Is that the new AB? | 14:01 |
| RP | JPEW: yes | 14:01 |
| RP | well, a test cluster modelling it | 14:01 |
| JPEW | It's _too_ fast :) | 14:01 |
| RP | ? | 14:01 |
| JPEW | It the hash server close? | 14:02 |
| JPEW | Or still hosted on the YP infra | 14:02 |
| RP | JPEW: it is probably on the wrong continent atm :( | 14:03 |
| *** Guest13 <Guest13!~Guest13@132.198.137.78.rev.vodafone.pt> has joined #yocto | 14:03 | |
| JPEW | Ya, that doesn't help. The parallel connections will help a little, since they should reduce the average connection latency | 14:03 |
| JPEW | But.... you'll need a lot to overcome that level of latency (probably too many) | 14:04 |
| RP | JPEW: crazy thought. If hashequiv of task A isn't present, is there any point in looking up hashes for tasks which depend on A ? | 14:04 |
| Guest13 | I have a quick question: bitbake-getvar -r z-image --value IMAGE_ROOTFS outputs /home/ubuntu/z/builder/build/tmp/work/p3768_0000_p3767_0001-poky-linux/z-image/1.0-r0/rootfs however, the rootfs is not here (it only has a "temp" folder with logs). Where can I find the rootfs? (I need to debug if a certain service was installed correctly) | 14:04 |
| JaMa | Guest13: if you're using rm_work, then it was probably already removed | 14:04 |
| JPEW | RP: Have to think on that one; gut instinct is... yes | 14:04 |
| RP | JPEW: have a think. Reporting makes sense, sure but I think there might be an optimisation short cut once a leaf dependency doesn't match | 14:05 |
| *** enok <enok!~Thunderbi@c-1e4ce655.06-290-73746f71.bbcust.telenor.se> has quit IRC (Ping timeout: 268 seconds) | 14:08 | |
| RP | "Please stop pasting release notes (or at least the user mentions) in your commit messages. GitHub spams every single person mentioned in every commit like this that you push." - https://github.com/daregit/yocto-combined/commit/1342b314a0fcb2f68171ff5c396f015b1c42dfe2#commitcomment-142281540 | 14:13 |
| mcfrisk | github crazy | 14:15 |
| JPEW | Heh, fun | 14:16 |
| JaMa | yeah even #NN trigger notifications in often unrelated PRs or issue tickets :/ | 14:16 |
| mcfrisk | I hope spammers figure this out soon | 14:19 |
| JaMa | is this yocto-combined something which should replace combo-layer or something unofficial? in which case why RP noticed that (go spammed as well because he is committer there) | 14:19 |
| JaMa | ? | 14:20 |
| RP | JaMa: nothing to do with me. I get all kinds of spam from github. This is probably due to my S-o-b or as the committer | 14:21 |
| RP | "You are receiving this because you authored the thread." - no I didn't | 14:22 |
| JaMa | wangmingyu84 authored and rpurdie committed on Nov 16, 2021 | 14:22 |
| JaMa | if the thread starts by the commit .. even when it's just "Submodule poky updated from 5ce6bb to aa9b00" yeah GH is crazy | 14:23 |
| JaMa | I've disabled most of my notifications there, but then I sometimes miss something and these @mentions are evil indeed, I think I kept those notifications enabled | 14:25 |
| RP | JaMa: I "commit" enough changes I get a ton of weird stuff | 14:25 |
| JaMa | co-pilot should sort out what @mentions are just unintentional drive-by mention in commit message and where the people really meant to summon someone | 14:26 |
| *** LocutusOfBorg <LocutusOfBorg!~locutusof@151.58.174.15> has quit IRC (Ping timeout: 240 seconds) | 14:32 | |
| qschulz | It's one of the "issues" with Mastodon as well, if someone answers you, you'll be by default added with your @ to the answers of that answer except if they remove you | 14:34 |
| *** rfuentess <rfuentess!~rfuentess@154.45.232.215> has quit IRC (Remote host closed the connection) | 14:37 | |
| *** Xagen <Xagen!~Xagen@syn-098-006-114-013.biz.spectrum.com> has quit IRC (Quit: Textual IRC Client: www.textualapp.com) | 14:41 | |
| *** Kubu_work <Kubu_work!~kubu@202-122-190-109.dsl.ovh.fr> has joined #yocto | 14:41 | |
| *** Xagen <Xagen!~Xagen@syn-098-006-114-013.biz.spectrum.com> has joined #yocto | 14:43 | |
| JaMa | RP: FYI: I'm testing UNPACKDIR changes as they are today in master-next and noticed that for recipe with npm.bbclass the sources are now in "duplicated" ${WORKDIR}/git/git" e.g. jsdoc-to-ts-native/1.0.0/git/git/README.md for recipe with S = "${WORKDIR}/git", I'm trying to figure out if it's caused by npm/npmsw or something else in this recipe, so just FYI | 14:50 |
| *** enok <enok!~Thunderbi@c-1e4ce655.06-290-73746f71.bbcust.telenor.se> has joined #yocto | 14:53 | |
| RP | JaMa: was that with a clean builddir or an existing one? | 14:55 |
| *** dmoseley_ <dmoseley_!~dmoseley@d4-50-177-189.evv.wideopenwest.com> has quit IRC (Quit: ZNC 1.9.0 - https://znc.in) | 14:56 | |
| JaMa | it's reproducible after cleansstate | 14:56 |
| JaMa | git -c gc.autoDetach=false -c core.pager=cat -c safe.bareRepository=all clone -n -s /OE/build/downloads/git2/github.com.enactjs.jsdoc-to-ts.git/ /OE/build/luneos-styhead/tmp-glibc/work/x86_64-linux/jsdoc-to-ts-native/1.0.0/sources-unpack/git/ | 14:56 |
| JaMa | this seems to work, but then it's probably moved to subdirectory instead, adding debug to base.bbclass to see why | 14:57 |
| RP | JaMa: I'd guess there is a [dirs] creating ${S} somewhere | 14:57 |
| RP | we should probably make the shutil.move more robust | 14:58 |
| *** mbulut__ <mbulut__!~mbulut@ip1f128e51.dynamic.kabel-deutschland.de> has quit IRC (Ping timeout: 240 seconds) | 14:58 | |
| *** dmoseley <dmoseley!~dmoseley@d4-50-177-189.evv.wideopenwest.com> has joined #yocto | 14:58 | |
| *** LocutusOfBorg <LocutusOfBorg!~locutusof@151.58.174.15> has joined #yocto | 15:10 | |
| *** enok <enok!~Thunderbi@c-1e4ce655.06-290-73746f71.bbcust.telenor.se> has quit IRC (Ping timeout: 260 seconds) | 15:13 | |
| *** florian__ <florian__!~florian@port-217-146-132-69.static.as20676.net> has quit IRC (Ping timeout: 264 seconds) | 15:22 | |
| JaMa | RP: I think it's npmsw fetcher creating ${S} in https://git.openembedded.org/bitbake/tree/lib/bb/fetch2/npmsw.py#n277 which is called from base.bbclass between deleting bb.utils.remove(workdir + '/' + basedir, True) and shutil.move to it | 15:31 |
| RP | JaMa: it is hardcoded as S in there which it shouldn't be :( | 15:33 |
| RP | That code is plain wrong :( | 15:33 |
| JaMa | there are even more issues in that code :/ | 15:33 |
| RP | JaMa: not entirely surprising :( | 15:34 |
| JaMa | I have some fixes for it in https://git.openembedded.org/bitbake-contrib/log/?h=jansa/master but it's a mess so I haven't finished it to usable version | 15:34 |
| JaMa | setting S to ${UNPACKDIR}/git for these recipes with npmsw:// is usable work around, right? | 15:35 |
| JaMa | I was testing a change to switch S to UNPACKDIR for all our recipes before, but that was causing quite a few conflicts between branches (so if needed I would keep it only for npmsw recipes for now) | 15:37 |
| RP | JaMa: can you try https://git.yoctoproject.org/poky/commit/?h=master-next&id=d1b23a8bb792e119d6817332f3995fbe36b53073 ? | 15:38 |
| JaMa | sure, sec | 15:42 |
| JaMa | yes, this seems to work | 15:44 |
| JaMa | thanks | 15:44 |
| RP | JaMa: great, I'll queue that as it shouldn't know anything about S | 15:44 |
| *** mckoan is now known as mckoan|away | 15:45 | |
| JaMa | one less skeleton ready to jump as soon as you merge UNPACKDIR change :) | 15:45 |
| JaMa | zeddii: are you already looking at meta-virtualization failures from https://git.openembedded.org/openembedded-core/commit/?id=cc4ec43a2b657fb4c58429ab14f1edc2473c1327 ? | 15:46 |
| RP | JaMa: yes! | 15:46 |
| JaMa | zeddii: khem fixed some go recipes in meta-oe already, but the changes in meta-virtualization will be a bit bigger and will need you to adjust your scripts to generate e.g. recipes-containers/docker-compose/src_uri.inc | 15:47 |
| zeddii | Jama: yes, but I'm traveling until the weekend, so it won't be before then. | 15:48 |
| JaMa | ack | 15:48 |
| JaMa | zeddii: also please merge https://lists.yoctoproject.org/g/meta-virtualization/message/8730 to kirkstone when you're back | 15:49 |
| halstead | JPEW: the new hashserv is in North America but it's set up to be distributed to multiple continents. We only have the one end point right now. I can check on CPU. | 15:49 |
| khem | JaMa: I was wondering if I should merge the UNPACKDIR in meta-openembedded now, world builds are clean for x86_64 | 15:51 |
| khem | one oscam recipe is showing some issue it uses svn fetcher I plan to switch to using a git mirror for it | 15:51 |
| JaMa | have anyone seen Armin lately? meta-oe kirkstone and scarthgap are broken for a while and multiple people were complaining (I didn't because I'm still grateful to him and khem that I no longer need to maintain meta-oe :)) | 15:52 |
| khem | armpit is in room here | 15:52 |
| RP | khem: he is very quiet though! | 15:53 |
| khem | RP: seems so :) | 15:54 |
| JaMa | yes, I've seen one e-mail from him on May 14 and Apr 28 before that, so very quiet lately | 15:54 |
| halstead | JPEW: the AWS frontend and the database aren't CPU or IO bound that I can see. | 15:56 |
| halstead | It might be some connection limit. I'll check. | 15:57 |
| RP | halstead: you can clearly see the issue at the top of https://valkyrie.yoctoproject.org/#/builders/17/builds/12/steps/12/logs/stdio "Bitbake still alive (no events for 7200s). Active tasks:" | 15:58 |
| RP | halstead: that means it didn't run anything for 7200s as it spent that time trying to talk to the hash server | 15:58 |
| JaMa | khem: or if you're willing to add https://lists.openembedded.org/g/openembedded-devel/message/110244 to scarthgap and https://lists.openembedded.org/g/openembedded-devel/message/110196 to fix parsing which is broken since April 30 | 16:00 |
| khem | let me see | 16:05 |
| JPEW | Seems likely that it's the latency then | 16:06 |
| JPEW | Let me see if I can measure it | 16:06 |
| JaMa | RP: found another npmsw issue related to UNPACKDIR I think :/ will debug more and let you know | 16:08 |
| *** Kubu_work <Kubu_work!~kubu@202-122-190-109.dsl.ovh.fr> has quit IRC (Quit: Leaving.) | 16:11 | |
| *** yudjinn <yudjinn!~yudjinn@c-73-153-47-71.hsd1.co.comcast.net> has quit IRC (Ping timeout: 264 seconds) | 16:15 | |
| RP | JaMa: :( I can't say I'm surprised unfortunately | 16:20 |
| *** Esben <Esben!~Srain@user/Esben> has quit IRC (Remote host closed the connection) | 16:22 | |
| qschulz | tlwoerner: fighting with extlinux + non-fitImage builds on a Rockchip device right now | 16:23 |
| qschulz | tlwoerner: somehow, the kernel+dtb aren't installed in the /boot partition | 16:23 |
| qschulz | trying to debug who's installing it there and based on what variable, if you have any hint, I'll take it :) | 16:23 |
| *** florian__ <florian__!~florian@78.48.173.77> has joined #yocto | 16:24 | |
| *** nerdboy <nerdboy!~nerdboy@gentoo/developer/nerdboy> has quit IRC (Remote host closed the connection) | 16:28 | |
| *** leon-anavi <leon-anavi!~Leon@46.55.231.62> has quit IRC (Quit: Leaving) | 16:30 | |
| JPEW | RP: Sent a patch to bitbake-hashclient that can be used to measure the roundtrip latency | 16:30 |
| *** zpfvo <zpfvo!~fvo@i59F5CE7A.versanet.de> has quit IRC (Remote host closed the connection) | 16:35 | |
| *** nerdboy <nerdboy!~nerdboy@47.143.129.159> has joined #yocto | 16:39 | |
| RP | halstead: ^^^ | 16:48 |
| RP | JPEW: thanks! | 16:48 |
| halstead | JPEW: Thanks in the meantime I'm tweaking connection handling to see if we can increase throughput. | 16:49 |
| RP | JPEW: should we add a "time 50 dummy queries" option too ? | 16:53 |
| RP | JPEW: that would tell whether the database base or the connection is the holdup? | 16:53 |
| JPEW | `bitbake-hashclient stress` will do that | 16:54 |
| RP | halstead, JPEW: Given https://autobuilder.yoctoproject.org/typhoon/#/builders/108/builds/6028 has been going 19 hours, I'm not convinced this is a geo issue | 16:55 |
| JPEW | Rp: Ya fair | 16:56 |
| halstead | hashserv.yoctoproject.org and the typhoon cluster are have 6ms latency | 16:58 |
| halstead | hashserv.yoctoproject.org and the valkyre cluster are have 181ms latency | 16:59 |
| RP | halstead: it means valkyrie will be slower but it probably isn't the only issue :/ | 16:59 |
| RP | 10000 requests in 239.2s. 41.8 requests per second | 17:00 |
| RP | Average request time 0.02391578s | 17:00 |
| RP | Max request time was 3.89533072s | 17:00 |
| halstead | I've tweaked settings to allow many more simultaneous connections. Lets see if we can get some load on the system now. | 17:00 |
| RP | "10000 requests in 9.5s. 1048.2 requests per second" was a local server | 17:01 |
| JaMa | "10000 requests in 1.5s. 6642.2 requests per second" is my local | 17:02 |
| RP | JaMa: that was a domain socket though and not over http? | 17:02 |
| JaMa | yeah unix:// again | 17:02 |
| RP | halstead: "bitbake-hashclient --address wss://hashserv.yoctoproject.org/ws stress" is the time we need to improve somehow :/ | 17:03 |
| RP | halstead: "10000 requests in 186.1s. 53.7 requests per second" this time | 17:05 |
| JPEW | RP: just sent a patch to improve the stress stats reporting | 17:12 |
| *** sudip <sudip!~sudipmukh@78.40.148.182> has quit IRC (Ping timeout: 252 seconds) | 17:13 | |
| RP | JPEW: that runqueue getunihashes change to runqueue breaks bitbake :( | 17:13 |
| JPEW | For me, the average round trip time for stress (0.108) and ping (109) are pretty close, which makes me believe the database is not the problem | 17:13 |
| RP | ERROR: libxdamage-1_1.1.6-r0 do_package: Cache unihash 7b0e8235065c28cb2a4726c08f44ce3a48cbd0548af279f9c3ad851a71e44e46 doesn't match BB_UNIHASH 10eb130e8cec19ba27bb4d9176fa1255ce1747fdc5977b231e316f7fbf297b3e | 17:13 |
| JPEW | Weird. I'll have to take a look | 17:14 |
| RP | JPEW: it'll be some kind of cache coherency issue | 17:14 |
| JPEW | RP: For sure | 17:14 |
| *** sudip <sudip!~sudipmukh@78.40.148.182> has joined #yocto | 17:14 | |
| RP | I did worry a bit when I tweaked the code, clearly I need to look deeper | 17:14 |
| * JPEW needs to eat lunch | 17:15 | |
| * RP also needs to find food | 17:15 | |
| RP | JPEW: give the idea of stopping queries when one fails some thought. The more I think about it, the more I think this could help a lot | 17:16 |
| RP | not all queries, just queries that would use that hash as part of the next hash | 17:16 |
| qschulz | I added INHERIT += "buildhistory" in conf/local.conf and did two builds with two different machines | 17:18 |
| qschulz | I only have the buildhistory for the second machine | 17:18 |
| qschulz | I removed build/buildhistory but it doesn't get regenerated | 17:19 |
| qschulz | what am I doing wrong here | 17:19 |
| RP | qschulz: different branches maybe? | 17:19 |
| RP | qschulz: did you set it to commit? | 17:19 |
| qschulz | RP: the default is commit, but didn't want to look into this, so disabled it after | 17:20 |
| qschulz | the thing is, I don't have buildhistory directory anymore, why is not recreating it? | 17:20 |
| halstead | 10000 requests in 36.3s. 275.5 requests per second on typhoon | 17:20 |
| halstead | 10000 requests in 254.5s. 39.3 requests per second on valkyrie | 17:21 |
| RP | halstead: sounds like JPEW is right and it is latency | 17:22 |
| RP | qschulz: it will if you build new things? | 17:22 |
| RP | qschulz: it behaves differently to other bits of the code, it doesn't restore from sstate, it logs | 17:22 |
| qschulz | RP: invalidating the cache you mean... true, could try that | 17:22 |
| qschulz | RP: i'm trying to identify who's pulling a package into the rootfs, I think/hope buildhistory could help with that | 17:23 |
| qschulz | but not too familiar with it, so probably hitting a nail with the wood part of the hammer :) | 17:23 |
| JaMa | the depends files will help and buildhistory is useful for other things as well, so good to get familiar even when there are other ways to query this | 17:24 |
| halstead | 275.5 r/s still seems low. 500 r/s should be an easy target. | 17:24 |
| qschulz | JaMa: yes, but I really want the RDEPENDS part, I'm not at all interested in why the recipe is built (its the kernel, I know why :) ) | 17:25 |
| JaMa | qschulz: yes, buildhistory/images/qemux86_64/glibc/core-image-minimal/depends-nokernel-nolibc-noupdate-nomodules.dot shows the RDEPENDS | 17:25 |
| RP | halstead: builds on typhoon are also running slowly, just probably not as slowly as valkyrie :/ | 17:26 |
| qschulz | RP: yup, added a package, the image is rebuilt -> new buildhistory directory | 17:27 |
| JaMa | halstead: how can I know if wss://hashserv.yoctoproject.org/ws from here is hitting typhoon or valkrie? | 17:29 |
| *** alimon <alimon!~alimon@189.172.223.21> has joined #yocto | 17:29 | |
| halstead | JaMa: I'm measuring from those clusters to hashserv.yoctoproject.org. There is only one v2 hashserv right now and it's in North America | 17:30 |
| JaMa | I see 34.221.58.120 and 10000 requests in 240.7s. 41.6 requests per second | 17:30 |
| halstead | I'll get an EU copy up once we solve the performance issue were latency isn't a concern. | 17:31 |
| JaMa | aha thanks, I thought there were 2 hashservs, not 2 clusters accessing the same hashserv, sorry for noise | 17:31 |
| *** florian__ <florian__!~florian@78.48.173.77> has quit IRC (Ping timeout: 264 seconds) | 17:31 | |
| qschulz | JaMa: seems like my kernel-module-* packages are pulling in kernel-<version> which pulls in kernel-image which pulls in kernel-image-fitImage | 17:34 |
| qschulz | but it doesn't make sense to me that kernel-module-* would RDEPENDS on the kernel | 17:36 |
| JaMa | doesn't the kernel package provide e.g. modules.dep files? | 17:38 |
| qschulz | JaMa: it provides modules.builtin, modules.builtin.modinfo and modules.order in /lib/modules/*/ | 17:43 |
| qschulz | JaMa: that was a very nice hint, thank you | 17:43 |
| qschulz | tlwoerner: did you test your /boot merging with a device that doesn't have kernel-modules in MACHINE_EXTRA_RRECOMMENDS? | 17:45 |
| *** tgamblin <tgamblin!~tgamblin@d24-150-219-207.home.cgocable.net> has quit IRC (Ping timeout: 256 seconds) | 17:51 | |
| *** tgamblin <tgamblin!~tgamblin@d24-150-219-207.home.cgocable.net> has joined #yocto | 17:52 | |
| *** florian__ <florian__!~florian@dynamic-078-048-173-077.78.48.pool.telefonica.de> has joined #yocto | 17:59 | |
| *** florian_kc <florian_kc!~florian@78.48.173.77> has joined #yocto | 18:03 | |
| *** florian__ <florian__!~florian@dynamic-078-048-173-077.78.48.pool.telefonica.de> has quit IRC (Read error: Connection reset by peer) | 18:04 | |
| *** florian__ <florian__!~florian@dynamic-078-048-173-077.78.48.pool.telefonica.de> has joined #yocto | 18:05 | |
| *** florian_kc <florian_kc!~florian@78.48.173.77> has quit IRC (Ping timeout: 256 seconds) | 18:09 | |
| *** Guest13 <Guest13!~Guest13@132.198.137.78.rev.vodafone.pt> has quit IRC (Ping timeout: 250 seconds) | 18:18 | |
| qschulz | tlwoerner: I also assume we should make the MACHINE_ESSENTIAL_EXTRA_RDEPENDS depend on UBOOT_EXTLINUX being 1 otherwise we add packages to the image that the user didn't need | 18:21 |
| *** enok <enok!~Thunderbi@c-1e4ce655.06-290-73746f71.bbcust.telenor.se> has joined #yocto | 18:31 | |
| *** dkl <dkl!~dkl@prometheus.umask.eu> has quit IRC (Quit: %quit%) | 18:35 | |
| *** dkl <dkl!~dkl@prometheus.umask.eu> has joined #yocto | 18:36 | |
| *** dkl <dkl!~dkl@prometheus.umask.eu> has quit IRC (Remote host closed the connection) | 18:36 | |
| *** dkl <dkl!~dkl@prometheus.umask.eu> has joined #yocto | 18:36 | |
| *** bryan <bryan!~AdminUser@2600:1010:a11c:fba4:1ac0:4dff:fe33:40b8> has joined #yocto | 18:44 | |
| *** yudjinn <yudjinn!~yudjinn@75-166-45-136.hlrn.qwest.net> has joined #yocto | 18:46 | |
| *** bryan <bryan!~AdminUser@2600:1010:a11c:fba4:1ac0:4dff:fe33:40b8> has quit IRC (Client Quit) | 18:46 | |
| *** bgreen <bgreen!~AdminUser@2600:1010:a11c:fba4:1ac0:4dff:fe33:40b8> has joined #yocto | 18:46 | |
| *** bgreen is now known as bryan | 18:47 | |
| *** bryan is now known as bgreen | 18:48 | |
| *** ptsneves <ptsneves!~Thunderbi@89.151.29.72> has joined #yocto | 18:53 | |
| *** Starfoxxes <Starfoxxes!~Starfoxxe@2a02:8070:5381:8b40:c8c3:30c9:3e95:2fad> has quit IRC (Quit: Leaving) | 18:53 | |
| *** Saur_Home <Saur_Home!~Saur_Home@94-137-113-31.customers.ownit.se> has quit IRC (Quit: Client closed) | 19:02 | |
| *** Saur_Home <Saur_Home!~Saur_Home@94-137-113-31.customers.ownit.se> has joined #yocto | 19:02 | |
| *** florian__ <florian__!~florian@dynamic-078-048-173-077.78.48.pool.telefonica.de> has quit IRC (Ping timeout: 256 seconds) | 19:10 | |
| *** jpuhlman- <jpuhlman-!~jpuhlman@50.240.203.141> has quit IRC (Read error: Connection reset by peer) | 19:15 | |
| *** jpuhlman <jpuhlman!~jpuhlman@50.240.203.141> has joined #yocto | 19:16 | |
| *** florian__ <florian__!~florian@dynamic-078-048-173-077.78.48.pool.telefonica.de> has joined #yocto | 19:22 | |
| bgreen | Is this a good place to ask about issues with bitbake's multiconfig feature? | 19:37 |
| bgreen | I'll start with a basic question about multiconfig: if I have a multiconfig configuration that only changes MACHINE, is it necessary to also set a new TMPDIR? I had hoped not, but my experience is suggesting otherwise. | 19:51 |
| *** Jones42 <Jones42!~Jones42@user/Jones42> has quit IRC (Ping timeout: 260 seconds) | 19:54 | |
| RP | bgreen: it depends how compatible the MACHINEs are with each other and how well the BSPs are written | 20:03 |
| RP | in theory it should work but there are ways things could break | 20:04 |
| bgreen | In my use case, I am trying to use multiconfig to build an "mfg" image that is different from a regular image mainly in having a differently-configured kernel. So the mfg multiconfig does MACHINE:append = "-mfg", and the machine config for mfg sets a different value for PREFERRED_PROVIDER_virtual/kernel | 20:06 |
| bgreen | I will for example run 'bitbake main-image mc:mfg:mfg-image' to build the regular and mfg image at the same time | 20:07 |
| RP | it would probably work if the MACHINES were two different names. Same name for MACHINE might make it tricky | 20:08 |
| bgreen | but something odd happens. sometimes, a task for a particular recipe will get executed twice, concurrently - once for each config. | 20:08 |
| bgreen | but the MACHINES are two different names. ie. am62xx and am62xx-mfg | 20:08 |
| RP | are they two different dirs under work ? | 20:09 |
| bgreen | no, they aren't. the recipe has a default package arch, so MACHINE_ARCH which is common | 20:10 |
| RP | which would be a problem in this case | 20:10 |
| RP | that is why it is breaking | 20:10 |
| bgreen | how is that a problem in this case? I was thinking I wouldn't need a separate TMPDIR. | 20:10 |
| RP | you've told it to run the builds concurrently. Usually two MACHINES would have different MACHINE_ARCH so it would work. In this case they don't | 20:11 |
| JaMa | any idea what would be causing pseudo issues in clean TMPDIR with today's master-next? path mismatch [2 links]: ino 29766796 db '/OE/build/oe-core/tmp-glibc/work/qemux86_64-oe-linux/base-files/3.0.14/packages-split/base-files/etc/issue' req '/OE/build/oe-core/tmp-glibc/work/qemux86_64-oe-linux/base-files/3.0.14/sstate-build-package/package/etc/issue'. multiple recipes, but always between package and | 20:11 |
| JaMa | sstate-build-package | 20:11 |
| RP | JaMa: with the recent PSEUDO_IGNORE_PATHS bits? I've not tested those yet | 20:12 |
| bgreen | why would two MACHINES have different MACHINE_ARCH? can't you have two machines with same underlying aarch64 architecture? | 20:12 |
| bgreen | for machine specific recipes of course, there are build directories for each. | 20:13 |
| RP | bgreen: MACHINE_ARCH are machine specific packages, not archtiecture specific packages | 20:13 |
| JaMa | RP: I don't have "base/bitbake.conf: Move S/B to PSEUDO_IGNORE_PATHS unconditionally" yet | 20:14 |
| bgreen | you are right, I misspoke. There are separate directories for each machine arch | 20:14 |
| *** Haxxa <Haxxa!~Haxxa@116.255.4.123> has quit IRC (Quit: Haxxa flies away.) | 20:15 | |
| RP | JaMa: ok, that is probably good. I don't know why you're seeing that though, it worked in all the tests I ran | 20:15 |
| JaMa | yes, it's strange, it worked in different build dir before, now I've switched to "smaller" build to reproduce the npmsw issue in isolation with public recipe and it started to fail everywhere, but will investigate | 20:16 |
| RP | bgreen: I don't know the failure you saw and I'd expect tasks to run in parallel if they're in separate work directories. I can't really comment further | 20:16 |
| JaMa | http://errors.yoctoproject.org/Errors/Build/184179/ for some reason this doesn't show the 2 do_package failure from pseudo aborts | 20:16 |
| bgreen | so, the packages which have PACKAGE_ARCH set to MACHINE_ARCH to build in separate directories. | 20:17 |
| bgreen | but many recipes do not set PACKAGE_ARCH to MACHINE_ARCH. | 20:17 |
| *** Haxxa <Haxxa!~Haxxa@116.255.4.123> has joined #yocto | 20:17 | |
| RP | bgreen: but those are identical between the machines ? | 20:17 |
| RP | in theory they should be. If they're not, that would be a problem | 20:18 |
| *** mvlad <mvlad!~mvlad@2a02:2f05:8810:9600:e88e:21ff:fe65:be18> has quit IRC (Remote host closed the connection) | 20:18 | |
| RP | bgreen: the yocto-check-layer tests would check some of these things | 20:19 |
| bgreen | most recipes don't have PACKAGE_ARCH set to MACHINE_ARCH. The default for PACKAGE_ARCH is TUNE_PKGARCH | 20:20 |
| bgreen | for MACHINE=am62xx, thats PACKAGE_ARCH=aarch64, by default. majority of packages build under the aarch64 dir | 20:20 |
| bgreen | and boost shouldn't be built once for MACHINE=am62xx and again for MACHINE=am62xx-mfg. And its not, but the do_package task is getting invoked twice, concurrently | 20:21 |
| *** yudjinn <yudjinn!~yudjinn@75-166-45-136.hlrn.qwest.net> has quit IRC (Ping timeout: 268 seconds) | 20:22 | |
| RP | bgreen: what it means is that something in boost is machine specific so either you fix that or mark it machine specific | 20:22 |
| RP | it shouldn't be machine specific. The yocto-check-layer tests would help track down which recipes have problems like this | 20:23 |
| bgreen | I've looked and I don't see anything. But I'll check again. | 20:23 |
| RP | bgreen: it could be a dependency of boost? | 20:24 |
| bgreen | I'll take a look at yocto-check-layer. | 20:24 |
| bgreen | Its rather hard to tell what might be causing this. | 20:24 |
| RP | yocto-check-layer was designed to try and show where layers have issues like this... | 20:25 |
| RP | that and some of the oe-selftest sstatetests | 20:26 |
| JaMa | or you can try scripts/sstate-diff-machines.sh, I'm still using this to detect issues like this | 20:26 |
| RP | that is probably the better one to try | 20:26 |
| bgreen | in the log I get these two lines in close proximty and then a failure ends up happening: | 20:26 |
| bgreen | NOTE: Running task 6926 of 8368 (/opt/srv/jenkins/root/workspace/AM62x/test_build/oe/meta-aos/recipes-support/boost/aosboost_1.71.0.bb:do_package) | 20:26 |
| bgreen | NOTE: Running task 7395 of 8368 (mc:mfg:/opt/srv/jenkins/root/workspace/AM62x/test_build/oe/meta-aos/recipes-support/boost/aosboost_1.71.0.bb:do_package) | 20:26 |
| bgreen | thanks, I'll take a look at those tools to see if they can help track it down. | 20:29 |
| JaMa | khem: you have clean world build with meta-oe/master-next with oe-core/master-next? I've started to test UNPACKDIR from oe-core/master-next a bit more today and I'm still seeing e.g. nodejs-oe-cache-native failure which doesn't seem to be fixed in meta-oe/master-next, will send it once I get my build tests usable again | 20:33 |
| RP | bgreen: in tmp/stamps/xxx there will be two do_package siginfo files. bitbake-diffsigs might show an interesting difference | 20:34 |
| *** yudjinn <yudjinn!~yudjinn@c-73-153-47-71.hsd1.co.comcast.net> has joined #yocto | 20:34 | |
| JaMa | RP: fwiw: the pseudo issues is reproducible in the other build directory as well if I force rebuild of e.g. base-files, will bisect what's causing that | 20:34 |
| JaMa | lucky me, base-files doesn't take long to rebuild :) | 20:35 |
| khem | JaMa: yes however, its with yoe distro, so there might be some packages which are left out | 20:36 |
| *** enok <enok!~Thunderbi@c-1e4ce655.06-290-73746f71.bbcust.telenor.se> has quit IRC (Ping timeout: 240 seconds) | 20:36 | |
| khem | JaMa: noticed few more this morning, pick the latest master-next always | 20:37 |
| khem | and also latest master-next of oe-core | 20:37 |
| RP | JaMa: FWIW I tried a bitbake base-files -C unpack a few times and I didn't see any errors | 20:37 |
| khem | JaMa: https://snips.sh/f/dqBdd6FdsD qemux86_64/glibc | 20:38 |
| khem | JaMa:clean build was with musl, which has a bit less packages supported | 20:39 |
| JaMa | khem: https://git.openembedded.org/meta-openembedded-contrib/commit/?h=jansa/master&id=f0a77ff0db231b30eaca7d05b93cec4dbe1f4afd is the one I was seeing now | 20:40 |
| *** ptsneves <ptsneves!~Thunderbi@89.151.29.72> has quit IRC (Ping timeout: 240 seconds) | 20:40 | |
| JaMa | but it could be some gremlins somewhere, now I'm "seeing" things with pseudo as well, who knows .. ah I guess I know now | 20:41 |
| JaMa | I've switched to python 3.13 to test something about 2 hours ago and then forgot that I did | 20:42 |
| JaMa | ok, regular oe-core/master failed the same, so it probably is python 3.13 | 20:47 |
| RP | JaMa: hmm. What did they do in python 3.13?! :/ | 20:58 |
| JaMa | I've saved the TMPDIR for later to compare | 20:58 |
| JaMa | but after switching back to 3.12 it works again | 20:59 |
| RP | JaMa: might be a missing glibc function intercept :/ | 20:59 |
| JaMa | 3.13 doesn't even pass own testsuite when pgo is enabled, so it might be anything at this point | 21:01 |
| bgreen | @RP I checked tmp/stamps. I'm not seeing two do_package sigdata files, but in one build tree I see these two: | 21:03 |
| bgreen | 1.71.0-r1.do_packagedata_setscene.f51d3b74a0d2df55aa3f5b287808ea90c7ca9a1806d8bb830d3be537ec01e544.am62xx_esr | 21:03 |
| bgreen | 1.71.0-r1.do_packagedata_setscene.f51d3b74a0d2df55aa3f5b287808ea90c7ca9a1806d8bb830d3be537ec01e544.am62xx_esr_mfg | 21:03 |
| bgreen | am62xx_esr and am62xx_esr_mfg are the two MACHINEs. I'm not sure if this is evidence of a MACHINE-specific dependency | 21:03 |
| *** dmoseley <dmoseley!~dmoseley@d4-50-177-189.evv.wideopenwest.com> has quit IRC (Quit: ZNC 1.9.0 - https://znc.in) | 21:04 | |
| *** dmoseley <dmoseley!~dmoseley@d4-50-177-189.evv.wideopenwest.com> has joined #yocto | 21:06 | |
| *** Xagen <Xagen!~Xagen@syn-098-006-114-013.biz.spectrum.com> has quit IRC (Ping timeout: 264 seconds) | 21:16 | |
| *** dmoseley <dmoseley!~dmoseley@d4-50-177-189.evv.wideopenwest.com> has quit IRC (Quit: ZNC 1.9.0 - https://znc.in) | 21:21 | |
| RP | bgreen: no, that isn't. packagedata has some quirks in that is extracted per machine. That is different to do_package | 21:22 |
| rburton | khem: did you know openssl fails to build with qemurisc32 | 21:25 |
| RP | rburton: is there a patch pending for that? | 21:25 |
| rburton | yes! | 21:26 |
| rburton | khem: stand down :) | 21:26 |
| *** dmoseley <dmoseley!~dmoseley@d4-50-177-189.evv.wideopenwest.com> has joined #yocto | 21:26 | |
| rburton | like a fool i thought i'd check my pciutils rewrite on EVERY MACHINE IN CORE | 21:26 |
| * RP merges the WORKDIR change | 21:27 | |
| RP | it needs to go in then we can build upon it | 21:27 |
| JaMa | added https://bugzilla.yoctoproject.org/show_bug.cgi?id=15490 for pseudo-python-3.13 issue - for future - don't look :) | 21:29 |
| khem | rburton:https://patchwork.yoctoproject.org/project/oe-core/patch/20240513230528.4115348-1-raj.khem@gmail.com/ | 21:31 |
| khem | and always peek into yoe/mut contrib branch, you will always find fun stuff there | 21:31 |
| JaMa | kinky stuff | 21:32 |
| rburton | khem: if you have a spare ten minutes, looking at pciutils symbol versioning wrappers and telling me if they can be replaced with something that doesn't involve textrel warnings would be nice :) https://git.kernel.org/pub/scm/utils/pciutils/pciutils.git/tree/lib/internal.h#n16 | 21:32 |
| rburton | to me it feels like ARGH WHAT IS THAT ARGH is a suitable response, but i'm not sure | 21:33 |
| khem | RP:btw. top 4 patches on https://git.yoctoproject.org/poky-contrib/log/?h=yoe/mut are already submitted to ml, you may want to cherry-pick them | 21:33 |
| *** dmoseley <dmoseley!~dmoseley@d4-50-177-189.evv.wideopenwest.com> has quit IRC (Quit: ZNC 1.9.0 - https://znc.in) | 21:35 | |
| khem | rburton: hopping into car atm, will take a look once at desk again later today | 21:35 |
| rburton | khem: only if you're bored, i ripped the recipe apart and it started textrel warning at me. found where, realised i ran out of C/gcc knowledge, added an INSANE_SKIP :) | 21:36 |
| JaMa | khem: thanks for meta-oe backports! | 21:38 |
| *** dmoseley <dmoseley!~dmoseley@d4-50-177-189.evv.wideopenwest.com> has joined #yocto | 21:38 | |
| *** zwelch <zwelch!~zwelch@fluffy.mandolincreekfarm.com> has quit IRC (Read error: Connection reset by peer) | 21:46 | |
| *** zwelch <zwelch!~zwelch@fluffy.mandolincreekfarm.com> has joined #yocto | 21:46 | |
| *** florian__ <florian__!~florian@dynamic-078-048-173-077.78.48.pool.telefonica.de> has quit IRC (Ping timeout: 260 seconds) | 21:55 | |
| *** jmiehe <jmiehe!~Thunderbi@user/jmiehe> has quit IRC (Quit: jmiehe) | 21:56 | |
| *** goliath <goliath!~goliath@user/goliath> has quit IRC (Quit: SIGSEGV) | 22:56 | |
| *** brrm <brrm!~brrm@ip-078-043-203-234.um18.pools.vodafone-ip.de> has quit IRC (Ping timeout: 255 seconds) | 23:10 | |
| *** brrm <brrm!~brrm@2a02:8071:b700::1c89> has joined #yocto | 23:13 | |
| *** mrpelotazo <mrpelotazo!~mrpelotaz@user/mrpelotazo> has quit IRC (Ping timeout: 268 seconds) | 23:39 | |
| *** mrpelotazo <mrpelotazo!~mrpelotaz@user/mrpelotazo> has joined #yocto | 23:40 | |
Generated by irclog2html.py 4.0.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!