Wednesday, 2024-05-22

*** 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 #yocto00: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 #yocto01: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 #yocto01:19
*** geoffhp <geoffhp!~geoff@syn-023-241-067-081.res.spectrum.com> has joined #yocto03:33
*** parthiban <parthiban!~parthiban@122.165.245.213> has joined #yocto04:06
*** parthiban <parthiban!~parthiban@122.165.245.213> has left #yocto04:06
*** MrCryo <MrCryo!~MrCryo@user/MrCryo> has joined #yocto04: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 #yocto06:02
*** enok <enok!~Thunderbi@94.191.153.21> has joined #yocto06:08
*** rfuentess <rfuentess!~rfuentess@154.45.232.215> has joined #yocto06: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 #yocto06: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 #yocto06: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 #yocto06:35
*** goliath <goliath!~goliath@user/goliath> has joined #yocto06: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 #yocto06:38
*** ablu <ablu!~m-bfyrfh@user/Ablu> has quit IRC (Ping timeout: 255 seconds)06:45
*** ablu <ablu!~m-bfyrfh@user/Ablu> has joined #yocto06:45
*** shoragan_ is now known as shoragan06:49
*** mckoan|away is now known as mckoan07:04
*** c-thaler <c-thaler!~c-thaler@213.221.121.44> has joined #yocto07:21
*** polprog <polprog!~ath0@user/polprog> has quit IRC (Ping timeout: 272 seconds)07:22
*** enok <enok!~Thunderbi@94.191.152.74> has joined #yocto07:48
*** leon-anavi <leon-anavi!~Leon@46.55.231.62> has joined #yocto07:49
*** Kubu_work <Kubu_work!~kubu@202-122-190-109.dsl.ovh.fr> has joined #yocto07: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 #yocto08:19
*** halloy4985 <halloy4985!~halloy498@165.225.124.180> has joined #yocto08:21
halloy4985Hi , Is there a way to revert a patch applied by cleansstate08:23
JaMaif cleansstate task applies patches for you than you live in very weird universe08:28
halloy4985Haha .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_eip08:32
JaMaremove them from SRC_URI if you don't want them to be applied08:33
*** Jones42 <Jones42!~Jones42@user/Jones42> has joined #yocto08:38
max_eipBro i want to apply the patch. But dont want to commit to mainline.08:40
max_eipProblem 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
JaMafirst 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 bro08:41
max_eipI think we miscommunicated. Thanks for your time.08:43
LetoThe2ndJaMa: hey bro I want a beer08:45
JaMaLetoThe2nd: I need beer, now! :)08:46
LetoThe2ndJaMa: apply from external source?08:47
JaMasometimes, when internal fridge source gets empty08: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 #yocto08:59
*** shivamurthy_ <shivamurthy_!sid359794@id-359794.helmsley.irccloud.com> has joined #yocto08:59
*** OnkelUll_ <OnkelUll_!~user@dude03.red.stw.pengutronix.de> has joined #yocto08:59
*** wCPO0 <wCPO0!~wCPO@mail.klausen.dk> has joined #yocto08:59
*** rsalveti_ <rsalveti_!sid117878@id-117878.uxbridge.irccloud.com> has joined #yocto09:00
*** dmoseley_ <dmoseley_!~dmoseley@d4-50-177-189.evv.wideopenwest.com> has joined #yocto09:00
*** benkard <benkard!~mulk@p5b112e4a.dip0.t-ipconnect.de> has joined #yocto09:00
*** fullstop_ <fullstop_!~fullstop@user/fullstop> has joined #yocto09: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 #yocto09:01
*** dl9pf <dl9pf!sid395223@id-395223.helmsley.irccloud.com> has joined #yocto09: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 #yocto09:01
*** asriel <asriel!~asriel@user/asriel> has quit IRC (Ping timeout: 268 seconds)09:01
*** shivamurthy_ is now known as shivamurthy09:01
*** rsalveti_ is now known as rsalveti09:01
*** wCPO0 is now known as wCPO09:01
*** benkard is now known as mulk09:01
*** sukbeom6 is now known as sukbeom09:01
*** asriel <asriel!~asriel@user/asriel> has joined #yocto09:01
*** fullstop_ is now known as fullstop09:02
*** enok <enok!~Thunderbi@c-1e4ce655.06-290-73746f71.bbcust.telenor.se> has joined #yocto09:05
*** mvlad <mvlad!~mvlad@2a02:2f05:8810:9600:e88e:21ff:fe65:be18> has joined #yocto09:08
*** OnkelUll_ is now known as OnkelUlla09:08
*** mbulut__ <mbulut__!~mbulut@ip1f128e51.dynamic.kabel-deutschland.de> has joined #yocto09: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 now09:46
JaMaRP: 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
JaMaI 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
RPJaMa: other layers haven't adapated to the workdir changes yet, but they kind of can't/won't until I make things error09:49
RPJaMa: at least that patch won't break core :)09:50
JaMayeah, 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
JaMaI'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 time09:52
*** Guest13 <Guest13!~Guest13@132.198.137.78.rev.vodafone.pt> has joined #yocto09:53
Guest13regarding 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 start09:54
JaMaGuest13: bitbake-getvar09:54
Guest13JaMa for what?09:55
JaMaGuest13: SRC_URI, LIC_FILES_CHKSUM, DL_DIR, ..09:55
rburtonJaMa: i do try and look at the buildhistory for most patch series but don't do it all the time09:55
JaMarburton: yes, buildhistory is great and thank you for looking at it09:56
rburtonGuest13: 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
JaMarburton: I wouldn't have noticed this one as we have PREFERRED_VERSION_gawk = "3.1.5" (cough gplv2)09:57
RPJaMa: the configure breakage is worrying :/09:58
JaMaRP: yes, I have seen few of those, but luckily they were fatal for what was explicitly enabled09:58
RPlogically I should wait and let gcc 14 settle. My own sanity say I should merge this and move on :/09:59
rburtonhm i wonder if its possible to extract the autoconf test list and results10:03
* rburton has a cunning plan10: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 #yocto10:17
*** ardo <ardo!~ardo@host-79-33-76-22.retail.telecomitalia.it> has joined #yocto10:17
Guest13interesting, my bbappend file was messing samba's fetch up.... am confused ;_:10:26
Guest13FILESEXTRAPATHS:prepend := "${THISDIR}/files:"10:26
Guest13SRC_URI:colibri-imx6 = " file://imx6/smb.conf"10:26
Guest13SRC_URI:jetson-tx2-devkit = " file://tx2/smb.conf"10:26
Guest13do_install:append:colibri-imx6() {10:26
Guest13    DST=${D}/etc/samba/smb.conf10:26
Guest13    install -d ${DST}10:26
Guest13    install -m 0644 ${WORKDIR}/smb.conf ${DST}10:26
Guest13}10:26
Guest13do_install:append:jetson-tx2-devkit() {10:26
Guest13    DST=${D}/etc/samba/smb.conf10:26
Guest13    install -d ${DST}10:26
Guest13    install -m 0644 ${WORKDIR}/smb.conf ${DST}10:27
Guest13}10:27
Guest13FILES:${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
JaMaGuest13: SRC_URI:colibri-imx6 abd SRC_URI:jetson-tx2-devkit are obviously wrong, maybe you wanted to use :append:override here10:32
rburtonGuest13: yeah that would be utterly breaking the fetch10:34
rburtonGuest13: mainly it _does not download the sources_10:34
rburtongolden rule of "why is this thing behaving weird": did you break it? verify it works without your local changes first.10:35
Guest13ahhh, i was overriding the SRC_URI10:35
Guest13instead of adding/appending the files10:35
JaMayes and using bitbake-getvar or bitbake -e if you don't understand the syntax at all10:35
rburton for example "bitbake-getvar -r samba SRC_URI" will show that there is no tarball in the SRC_URI entry10:36
JaMawell use bitbake-getvar even if you understand the syntax well, because one can always for get about some nasty .bbappend or .inc file hiding somewhere10:36
*** Guest13 <Guest13!~Guest13@132.198.137.78.rev.vodafone.pt> has quit IRC (Quit: Client closed)10:38
mcfriskI 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 #yocto10:51
*** Esben <Esben!~Srain@user/Esben> has joined #yocto11: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 #yocto11:07
*** florian__ <florian__!~florian@port-217-146-132-69.static.as20676.net> has joined #yocto11:12
*** Vonter <Vonter!~Vonter@user/vonter> has joined #yocto11:16
*** krissmaster <krissmaster!~kriss@213.239.83.90> has joined #yocto11: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 #yocto11: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 #yocto11:32
*** jmiehe <jmiehe!~Thunderbi@user/jmiehe> has joined #yocto11: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 #yocto12:05
*** OnkelUlla <OnkelUlla!~user@dude03.red.stw.pengutronix.de> has joined #yocto12:13
RPprocess_possible_migrations() in runqueue is taking over 1200s to complete a migration pass :(12:19
RPlooks like it is stuck in unihash queries12:19
*** Jones42 <Jones42!~Jones42@user/Jones42> has quit IRC (Ping timeout: 260 seconds)12:31
*** Jones42 <Jones42!~Jones42@user/Jones42> has joined #yocto12: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 #yocto12:40
RPJPEW: around? I'm seeing some hashserver performance issues, was there a way to get server statistics ?12:58
RPJPEW: I've written up my findings so far and emailed13:07
JPEWI'm in and out this morning. 'bitbake-hashclient stats' (I think that's the command) might be useful13:09
*** c-thaler <c-thaler!~c-thaler@213.221.121.44> has quit IRC (Quit: Client closed)13:10
RPJPEW: thanks, that is what I wasn't spotting13:13
RPbitbake-hashclient --address wss://hashserv.yoctoproject.org/ws stats gives "average": 0.0625025753945477613:13
RPFor 38000 tasks, that would be a problem :(13:13
JPEWYa13:13
RPlocally it is "average": 0.000446217816085784913:13
JPEWI wonder if the support for parallel queries would help13:14
JPEWIs the server CPU bound?13:16
RPJPEW: 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 is13:17
JPEWYa. I'll see if I can dig up the parallel patches and you can see if they help13: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 #yocto13: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 #yocto13:38
JPEWRP: Parallel support is already in; is BB_HASHSERVE_MAX_PARALLEL set on the AB?13:44
RPJPEW: it is not. What should we set that to?13:49
RPJPEW: 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
JPEWAh, ya, that would not help13:51
JPEWWait, that is parellel13:52
RPJPEW: I'm making it more parallel with that patch?13:52
RP(which is unmerged)13:52
JPEWAh, OK. Yes, that looks correct and should help13:52
RPJPEW: I don't think it will change much :(. What is a reasonable value for that variable? 100?13:53
JPEWYou 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
JPEWI suppose 100 might at least tell us if it will fix the problem13:55
*** Xagen <Xagen!~Xagen@syn-098-006-114-013.biz.spectrum.com> has joined #yocto13:55
RPJPEW: I can put 10 into the configs, see if it helps. Setting 100 locally didn't seem to speed things up that much13:56
JPEWIt won't since the local server can't parallelize the SQL queries13:56
RPJPEW: I was trying against the public server13:57
RPJPEW: it is bad. https://valkyrie.yoctoproject.org/#/builders/17/builds/13 - 1hour 20 and still not past setting up the tasks :(13:59
JPEWIs that the new AB?14:01
RPJPEW: yes14:01
RPwell, a test cluster modelling it14:01
JPEWIt's _too_ fast :)14:01
RP?14:01
JPEWIt the hash server close?14:02
JPEWOr still hosted on the YP infra14:02
RPJPEW: it is probably on the wrong continent atm :(14:03
*** Guest13 <Guest13!~Guest13@132.198.137.78.rev.vodafone.pt> has joined #yocto14:03
JPEWYa, that doesn't help. The parallel connections will help a little, since they should reduce the average connection latency14:03
JPEWBut.... you'll need a lot to overcome that level of latency (probably too many)14:04
RPJPEW: 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
Guest13I 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
JaMaGuest13: if you're using rm_work, then it was probably already removed14:04
JPEWRP: Have to think on that one; gut instinct is... yes14:04
RPJPEW: have a think. Reporting makes sense, sure but I think there might be an optimisation short cut once a leaf dependency doesn't match14: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-14228154014:13
mcfriskgithub crazy14:15
JPEWHeh, fun14:16
JaMayeah even #NN trigger notifications in often unrelated PRs or issue tickets :/14:16
mcfriskI hope spammers figure this out soon14:19
JaMais 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
RPJaMa: 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 committer14:21
RP"You are receiving this because you authored the thread." - no I didn't14:22
JaMawangmingyu84 authored and rpurdie committed on Nov 16, 202114:22
JaMaif the thread starts by the commit .. even when it's just "Submodule poky updated from 5ce6bb to aa9b00" yeah GH is crazy14:23
JaMaI'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 enabled14:25
RPJaMa: I "commit" enough changes I get a ton of weird stuff14:25
JaMaco-pilot should sort out what @mentions are just unintentional drive-by mention in commit message and where the people really meant to summon someone14:26
*** LocutusOfBorg <LocutusOfBorg!~locutusof@151.58.174.15> has quit IRC (Ping timeout: 240 seconds)14:32
qschulzIt'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 you14: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 #yocto14:41
*** Xagen <Xagen!~Xagen@syn-098-006-114-013.biz.spectrum.com> has joined #yocto14:43
JaMaRP: 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 FYI14:50
*** enok <enok!~Thunderbi@c-1e4ce655.06-290-73746f71.bbcust.telenor.se> has joined #yocto14:53
RPJaMa: 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
JaMait's reproducible after cleansstate14:56
JaMagit -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
JaMathis seems to work, but then it's probably moved to subdirectory instead, adding debug to base.bbclass to see why14:57
RPJaMa: I'd guess there is a [dirs] creating ${S} somewhere14:57
RPwe should probably make the shutil.move more robust14: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 #yocto14:58
*** LocutusOfBorg <LocutusOfBorg!~locutusof@151.58.174.15> has joined #yocto15: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
JaMaRP: 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 it15:31
RPJaMa: it is hardcoded as S in there which it shouldn't be :(15:33
RPThat code is plain wrong :(15:33
JaMathere are even more issues in that code :/15:33
RPJaMa: not entirely surprising :(15:34
JaMaI 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 version15:34
JaMasetting S to ${UNPACKDIR}/git for these recipes with npmsw:// is usable work around, right?15:35
JaMaI 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
RPJaMa: can you try https://git.yoctoproject.org/poky/commit/?h=master-next&id=d1b23a8bb792e119d6817332f3995fbe36b53073 ?15:38
JaMasure, sec15:42
JaMayes, this seems to work15:44
JaMathanks15:44
RPJaMa: great, I'll queue that as it shouldn't know anything about S15:44
*** mckoan is now known as mckoan|away15:45
JaMaone less skeleton ready to jump as soon as you merge UNPACKDIR change :)15:45
JaMazeddii: are you already looking at meta-virtualization failures from https://git.openembedded.org/openembedded-core/commit/?id=cc4ec43a2b657fb4c58429ab14f1edc2473c1327 ?15:46
RPJaMa: yes!15:46
JaMazeddii: 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.inc15:47
zeddiiJama: yes, but I'm traveling until the weekend, so it won't be before then.15:48
JaMaack15:48
JaMazeddii: also please merge https://lists.yoctoproject.org/g/meta-virtualization/message/8730 to kirkstone when you're back15:49
halsteadJPEW: 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
khemJaMa: I was wondering if I should merge the UNPACKDIR in meta-openembedded now, world builds are clean for x86_6415:51
khemone oscam recipe is showing some issue it uses svn fetcher I plan to switch to using a git mirror for it15:51
JaMahave 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
khemarmpit is in room here15:52
RPkhem: he is very quiet though!15:53
khemRP: seems so :)15:54
JaMayes, I've seen one e-mail from him on May 14 and Apr 28 before that, so very quiet lately15:54
halsteadJPEW: the AWS frontend and the database aren't CPU or IO bound that I can see.15:56
halsteadIt might be some connection limit. I'll check.15:57
RPhalstead: 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
RPhalstead: that means it didn't run anything for 7200s as it spent that time trying to talk to the hash server15:58
JaMakhem: 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 3016:00
khemlet me see16:05
JPEWSeems likely that it's the latency then16:06
JPEWLet me see if I can measure it16:06
JaMaRP: found another npmsw issue related to UNPACKDIR I think :/ will debug more and let you know16: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
RPJaMa: :( I can't say I'm surprised unfortunately16:20
*** Esben <Esben!~Srain@user/Esben> has quit IRC (Remote host closed the connection)16:22
qschulztlwoerner: fighting with extlinux + non-fitImage builds on a Rockchip device right now16:23
qschulztlwoerner: somehow, the kernel+dtb aren't installed in the /boot partition16:23
qschulztrying 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 #yocto16: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
JPEWRP: Sent a patch to bitbake-hashclient that can be used to measure the roundtrip latency16: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 #yocto16:39
RPhalstead: ^^^16:48
RPJPEW: thanks!16:48
halsteadJPEW: Thanks in the meantime I'm tweaking connection handling to see if we can increase throughput.16:49
RPJPEW: should we add a "time 50 dummy queries" option too ?16:53
RPJPEW: that would tell whether the database base or the connection is the holdup?16:53
JPEW`bitbake-hashclient stress` will do that16:54
RPhalstead, JPEW: Given https://autobuilder.yoctoproject.org/typhoon/#/builders/108/builds/6028 has been going 19 hours, I'm not convinced this is a geo issue16:55
JPEWRp: Ya fair16:56
halsteadhashserv.yoctoproject.org and the typhoon cluster are have 6ms latency16:58
halsteadhashserv.yoctoproject.org and the valkyre cluster are have 181ms latency16:59
RPhalstead: it means valkyrie will be slower but it probably isn't the only issue :/16:59
RP10000 requests in 239.2s. 41.8 requests per second17:00
RPAverage request time 0.02391578s17:00
RPMax request time was 3.89533072s17:00
halsteadI'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 server17:01
JaMa"10000 requests in 1.5s. 6642.2 requests per second" is my local17:02
RPJaMa: that was a domain socket though and not over http?17:02
JaMayeah unix:// again17:02
RPhalstead: "bitbake-hashclient --address wss://hashserv.yoctoproject.org/ws stress" is the time we need to improve somehow :/17:03
RPhalstead: "10000 requests in 186.1s. 53.7 requests per second" this time17:05
JPEWRP: just sent a patch to improve the stress stats reporting17:12
*** sudip <sudip!~sudipmukh@78.40.148.182> has quit IRC (Ping timeout: 252 seconds)17:13
RPJPEW: that runqueue getunihashes change to runqueue breaks bitbake :(17:13
JPEWFor 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 problem17:13
RPERROR: libxdamage-1_1.1.6-r0 do_package: Cache unihash 7b0e8235065c28cb2a4726c08f44ce3a48cbd0548af279f9c3ad851a71e44e46 doesn't match BB_UNIHASH 10eb130e8cec19ba27bb4d9176fa1255ce1747fdc5977b231e316f7fbf297b3e17:13
JPEWWeird. I'll have to take a look17:14
RPJPEW: it'll be some kind of cache coherency issue17:14
JPEWRP: For sure17:14
*** sudip <sudip!~sudipmukh@78.40.148.182> has joined #yocto17:14
RPI did worry a bit when I tweaked the code, clearly I need to look deeper17:14
* JPEW needs to eat lunch17:15
* RP also needs to find food17:15
RPJPEW: 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 lot17:16
RPnot all queries, just queries that would use that hash as part of the next hash17:16
qschulzI added INHERIT += "buildhistory" in conf/local.conf and did two builds with two different machines17:18
qschulzI only have the buildhistory for the second machine17:18
qschulzI removed build/buildhistory but it doesn't get regenerated17:19
qschulzwhat am I doing wrong here17:19
RPqschulz: different branches maybe?17:19
RPqschulz: did you set it to commit?17:19
qschulzRP: the default is commit, but didn't want to look into this, so disabled it after17:20
qschulzthe thing is, I don't have buildhistory directory anymore, why is not recreating it?17:20
halstead10000 requests in 36.3s. 275.5 requests per second on typhoon17:20
halstead10000 requests in 254.5s. 39.3 requests per second on valkyrie17:21
RPhalstead: sounds like JPEW is right and it is latency17:22
RPqschulz: it will if you build new things?17:22
RPqschulz: it behaves differently to other bits of the code, it doesn't restore from sstate, it logs17:22
qschulzRP: invalidating the cache you mean... true, could try that17:22
qschulzRP: i'm trying to identify who's pulling a package into the rootfs, I think/hope buildhistory could help with that17:23
qschulzbut not too familiar with it, so probably hitting a nail with the wood part of the hammer :)17:23
JaMathe 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 this17:24
halstead275.5 r/s still seems low.  500 r/s should be an easy target.17:24
qschulzJaMa: 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
JaMaqschulz: yes, buildhistory/images/qemux86_64/glibc/core-image-minimal/depends-nokernel-nolibc-noupdate-nomodules.dot shows the RDEPENDS17:25
RPhalstead: builds on typhoon are also running slowly, just probably not as slowly as valkyrie :/17:26
qschulzRP: yup, added a package, the image is rebuilt -> new buildhistory directory17:27
JaMahalstead: 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 #yocto17:29
halsteadJaMa: I'm measuring from those clusters to hashserv.yoctoproject.org. There is only one v2 hashserv right now and it's in North America17:30
JaMaI see 34.221.58.120 and 10000 requests in 240.7s. 41.6 requests per second17:30
halsteadI'll get an EU copy up once we solve the performance issue were latency isn't a concern.17:31
JaMaaha thanks, I thought there were 2 hashservs, not 2 clusters accessing the same hashserv, sorry for noise17:31
*** florian__ <florian__!~florian@78.48.173.77> has quit IRC (Ping timeout: 264 seconds)17:31
qschulzJaMa: seems like my kernel-module-* packages are pulling in kernel-<version> which pulls in kernel-image which pulls in kernel-image-fitImage17:34
qschulzbut it doesn't make sense to me that kernel-module-* would RDEPENDS on the kernel17:36
JaMadoesn't the kernel package provide e.g. modules.dep files?17:38
qschulzJaMa: it provides modules.builtin, modules.builtin.modinfo and modules.order in /lib/modules/*/17:43
qschulzJaMa: that was a very nice hint, thank you17:43
qschulztlwoerner: 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 #yocto17:52
*** florian__ <florian__!~florian@dynamic-078-048-173-077.78.48.pool.telefonica.de> has joined #yocto17:59
*** florian_kc <florian_kc!~florian@78.48.173.77> has joined #yocto18: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 #yocto18: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
qschulztlwoerner: 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 need18:21
*** enok <enok!~Thunderbi@c-1e4ce655.06-290-73746f71.bbcust.telenor.se> has joined #yocto18:31
*** dkl <dkl!~dkl@prometheus.umask.eu> has quit IRC (Quit: %quit%)18:35
*** dkl <dkl!~dkl@prometheus.umask.eu> has joined #yocto18: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 #yocto18:36
*** bryan <bryan!~AdminUser@2600:1010:a11c:fba4:1ac0:4dff:fe33:40b8> has joined #yocto18:44
*** yudjinn <yudjinn!~yudjinn@75-166-45-136.hlrn.qwest.net> has joined #yocto18: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 #yocto18:46
*** bgreen is now known as bryan18:47
*** bryan is now known as bgreen18:48
*** ptsneves <ptsneves!~Thunderbi@89.151.29.72> has joined #yocto18: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 #yocto19: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 #yocto19:16
*** florian__ <florian__!~florian@dynamic-078-048-173-077.78.48.pool.telefonica.de> has joined #yocto19:22
bgreenIs this a good place to ask about issues with bitbake's multiconfig feature?19:37
bgreenI'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
RPbgreen: it depends how compatible the MACHINEs are with each other and how well the BSPs are written20:03
RPin theory it should work but there are ways things could break20:04
bgreenIn 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/kernel20:06
bgreenI will for example run 'bitbake main-image mc:mfg:mfg-image' to build the regular and mfg image at the same time20:07
RPit would probably work if the MACHINES were two different names. Same name for MACHINE might make it tricky20:08
bgreenbut something odd happens.  sometimes, a task for a particular recipe will get executed twice, concurrently - once for each config.20:08
bgreenbut the MACHINES are two different names.  ie. am62xx and am62xx-mfg20:08
RPare they two different dirs under work ?20:09
bgreenno, they aren't.  the recipe has a default package arch, so MACHINE_ARCH which is common20:10
RPwhich would be a problem in this case20:10
RPthat is why it is breaking20:10
bgreenhow is that a problem in this case?  I was thinking I wouldn't need a separate TMPDIR.20:10
RPyou'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't20:11
JaMaany 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 and20:11
JaMasstate-build-package20:11
RPJaMa: with the recent PSEUDO_IGNORE_PATHS bits? I've not tested those yet20:12
bgreenwhy would two MACHINES have different MACHINE_ARCH?  can't you have two machines with same underlying aarch64 architecture?20:12
bgreenfor machine specific recipes of course, there are build directories for each.20:13
RPbgreen: MACHINE_ARCH are machine specific packages, not archtiecture specific packages20:13
JaMaRP: I don't have "base/bitbake.conf: Move S/B to PSEUDO_IGNORE_PATHS unconditionally" yet20:14
bgreenyou are right, I misspoke.  There are separate directories for each machine arch20:14
*** Haxxa <Haxxa!~Haxxa@116.255.4.123> has quit IRC (Quit: Haxxa flies away.)20:15
RPJaMa: ok, that is probably good. I don't know why you're seeing that though, it worked in all the tests I ran20:15
JaMayes, 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 investigate20:16
RPbgreen: 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 further20:16
JaMahttp://errors.yoctoproject.org/Errors/Build/184179/ for some reason this doesn't show the 2 do_package failure from pseudo aborts20:16
bgreenso, the packages which have PACKAGE_ARCH set to MACHINE_ARCH to build in separate directories.20:17
bgreenbut many recipes do not set PACKAGE_ARCH to MACHINE_ARCH.20:17
*** Haxxa <Haxxa!~Haxxa@116.255.4.123> has joined #yocto20:17
RPbgreen: but those are identical between the machines ?20:17
RPin theory they should be. If they're not, that would be a problem20:18
*** mvlad <mvlad!~mvlad@2a02:2f05:8810:9600:e88e:21ff:fe65:be18> has quit IRC (Remote host closed the connection)20:18
RPbgreen: the yocto-check-layer tests would check some of these things20:19
bgreenmost recipes don't have PACKAGE_ARCH set to MACHINE_ARCH.  The default for PACKAGE_ARCH is TUNE_PKGARCH20:20
bgreenfor MACHINE=am62xx, thats PACKAGE_ARCH=aarch64, by default.  majority of packages build under the aarch64 dir20:20
bgreenand 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, concurrently20:21
*** yudjinn <yudjinn!~yudjinn@75-166-45-136.hlrn.qwest.net> has quit IRC (Ping timeout: 268 seconds)20:22
RPbgreen: what it means is that something in boost is machine specific so either you fix that or mark it machine specific20:22
RPit shouldn't be machine specific. The yocto-check-layer tests would help track down which recipes have problems like this20:23
bgreenI've looked and I don't see anything.  But I'll check again.20:23
RPbgreen: it could be a dependency of boost?20:24
bgreenI'll take a look at yocto-check-layer.20:24
bgreenIts rather hard to tell what might be causing this.20:24
RPyocto-check-layer was designed to try and show where layers have issues like this...20:25
RPthat and some of the oe-selftest sstatetests20:26
JaMaor you can try scripts/sstate-diff-machines.sh, I'm still using this to detect issues like this20:26
RPthat is probably the better one to try20:26
bgreenin the log I get these two lines in close proximty and then a failure ends up happening:20:26
bgreenNOTE: 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
bgreenNOTE: 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
bgreenthanks, I'll take a look at those tools to see if they can help track it down.20:29
JaMakhem: 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 again20:33
RPbgreen: in tmp/stamps/xxx there will be two do_package siginfo files. bitbake-diffsigs might show an interesting difference20:34
*** yudjinn <yudjinn!~yudjinn@c-73-153-47-71.hsd1.co.comcast.net> has joined #yocto20:34
JaMaRP: 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 that20:34
JaMalucky me, base-files doesn't take long to rebuild :)20:35
khemJaMa: yes however, its with yoe distro, so there might be some packages which are left out20:36
*** enok <enok!~Thunderbi@c-1e4ce655.06-290-73746f71.bbcust.telenor.se> has quit IRC (Ping timeout: 240 seconds)20:36
khemJaMa: noticed few more this morning, pick the latest master-next always20:37
khemand also latest master-next of oe-core20:37
RPJaMa: FWIW I tried a bitbake base-files -C unpack a few times and I didn't see any errors20:37
khemJaMa: https://snips.sh/f/dqBdd6FdsD qemux86_64/glibc20:38
khemJaMa:clean build was with musl, which has a bit less packages supported20:39
JaMakhem: https://git.openembedded.org/meta-openembedded-contrib/commit/?h=jansa/master&id=f0a77ff0db231b30eaca7d05b93cec4dbe1f4afd is the one I was seeing now20:40
*** ptsneves <ptsneves!~Thunderbi@89.151.29.72> has quit IRC (Ping timeout: 240 seconds)20:40
JaMabut it could be some gremlins somewhere, now I'm "seeing" things with pseudo as well, who knows .. ah I guess I know now20:41
JaMaI've switched to python 3.13 to test something about 2 hours ago and then forgot that I did20:42
JaMaok, regular oe-core/master failed the same, so it probably is python 3.1320:47
RPJaMa: hmm. What did they do in python 3.13?! :/20:58
JaMaI've saved the TMPDIR for later to compare20:58
JaMabut after switching back to 3.12 it works again20:59
RPJaMa: might be a missing glibc function intercept :/20:59
JaMa3.13 doesn't even pass own testsuite when pgo is enabled, so it might be anything at this point21: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
bgreen1.71.0-r1.do_packagedata_setscene.f51d3b74a0d2df55aa3f5b287808ea90c7ca9a1806d8bb830d3be537ec01e544.am62xx_esr21:03
bgreen1.71.0-r1.do_packagedata_setscene.f51d3b74a0d2df55aa3f5b287808ea90c7ca9a1806d8bb830d3be537ec01e544.am62xx_esr_mfg21:03
bgreenam62xx_esr and am62xx_esr_mfg are the two MACHINEs.  I'm not sure if this is evidence of a MACHINE-specific dependency21: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 #yocto21: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
RPbgreen: no, that isn't. packagedata has some quirks in that is extracted per machine. That is different to do_package21:22
rburtonkhem: did you know openssl fails to build with qemurisc3221:25
RPrburton: is there a patch pending for that?21:25
rburtonyes!21:26
rburtonkhem: stand down :)21:26
*** dmoseley <dmoseley!~dmoseley@d4-50-177-189.evv.wideopenwest.com> has joined #yocto21:26
rburtonlike a fool i thought i'd check my pciutils rewrite on EVERY MACHINE IN CORE21:26
* RP merges the WORKDIR change21:27
RPit needs to go in then we can build upon it21:27
JaMaadded https://bugzilla.yoctoproject.org/show_bug.cgi?id=15490 for pseudo-python-3.13 issue - for future - don't look :)21:29
khemrburton:https://patchwork.yoctoproject.org/project/oe-core/patch/20240513230528.4115348-1-raj.khem@gmail.com/21:31
khemand always peek into yoe/mut contrib branch, you will always find fun stuff there21:31
JaMakinky stuff21:32
rburtonkhem: 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#n1621:32
rburtonto me it feels like ARGH WHAT IS THAT ARGH is a suitable response, but i'm not sure21:33
khemRP: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 them21:33
*** dmoseley <dmoseley!~dmoseley@d4-50-177-189.evv.wideopenwest.com> has quit IRC (Quit: ZNC 1.9.0 - https://znc.in)21:35
khemrburton: hopping into car atm, will take a look once at desk again later today21:35
rburtonkhem: 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
JaMakhem: thanks for meta-oe backports!21:38
*** dmoseley <dmoseley!~dmoseley@d4-50-177-189.evv.wideopenwest.com> has joined #yocto21: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 #yocto21: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 #yocto23:13
*** mrpelotazo <mrpelotazo!~mrpelotaz@user/mrpelotazo> has quit IRC (Ping timeout: 268 seconds)23:39
*** mrpelotazo <mrpelotazo!~mrpelotaz@user/mrpelotazo> has joined #yocto23:40

Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!