Thursday, 2021-05-06

*** M4x4dib <M4x4dib!~m4x4dib@2601:2c3:c100:fa50:b98e:8ad6:391c:584f> has joined #yocto00:42
*** meow` <meow`!~sbourdeli@> has quit IRC00:52
*** extorr <extorr!extor@unaffiliated/extor> has joined #yocto01:14
*** ByteLawd <ByteLawd!extor@unaffiliated/extor> has quit IRC01:15
*** csd <csd!> has quit IRC01:16
*** jaeckel <jaeckel!~jaeckel@unaffiliated/jaeckel> has quit IRC01:18
*** csd <csd!> has joined #yocto01:24
*** kpo <kpo!> has quit IRC01:25
*** gpanders <gpanders!> has quit IRC01:30
*** gpanders <gpanders!> has joined #yocto01:30
*** jaeckel <jaeckel!> has joined #yocto01:30
*** tperrot_ <tperrot_!> has joined #yocto01:47
*** gpanders <gpanders!> has quit IRC01:47
*** gpanders <gpanders!> has joined #yocto01:48
*** gnac <gnac!~gnac@> has quit IRC01:52
*** dmoseley <dmoseley!~dmoseley@> has quit IRC01:52
*** SWAT <SWAT!~swat@ubuntu/member/swat> has quit IRC01:52
*** R0b0t1 <R0b0t1!~R0b0t1@unaffiliated/r0b0t1> has quit IRC01:52
*** tlwoerner <tlwoerner!~tlwoerner@unaffiliated/tlwoerner> has quit IRC01:52
*** darknighte <darknighte!sid214177@pdpc/supporter/professional/darknighte> has quit IRC01:52
*** alex88 <alex88!~alex88@unaffiliated/alex88> has quit IRC01:52
*** tperrot <tperrot!> has quit IRC01:52
*** alejandrohs <alejandrohs!> has quit IRC01:52
*** chrysh_ <chrysh_!> has quit IRC01:52
*** marble_visions <marble_visions!~user@> has quit IRC01:52
*** lpoulain <lpoulain!lpoulain@gateway/shell/linaro/x-ntjhrxrunvsizaqc> has quit IRC01:52
*** rfs613 <rfs613!> has quit IRC01:52
*** rr123 <rr123!~xxiao@> has quit IRC01:52
*** ka6sox <ka6sox!~ka6sox@nasadmin/ka6sox> has quit IRC01:52
*** yocton <yocton!~quassel@> has quit IRC01:52
*** champagneg <champagneg!> has quit IRC01:52
*** minimaxwell <minimaxwell!> has quit IRC01:52
*** gnac <gnac!~gnac@> has joined #yocto01:53
*** dmoseley <dmoseley!~dmoseley@> has joined #yocto01:53
*** SWAT <SWAT!~swat@ubuntu/member/swat> has joined #yocto01:53
*** R0b0t1 <R0b0t1!~R0b0t1@unaffiliated/r0b0t1> has joined #yocto01:53
*** tlwoerner <tlwoerner!~tlwoerner@unaffiliated/tlwoerner> has joined #yocto01:53
*** darknighte <darknighte!sid214177@pdpc/supporter/professional/darknighte> has joined #yocto01:53
*** alex88 <alex88!~alex88@unaffiliated/alex88> has joined #yocto01:53
*** alejandrohs <alejandrohs!> has joined #yocto01:53
*** chrysh_ <chrysh_!> has joined #yocto01:53
*** marble_visions <marble_visions!~user@> has joined #yocto01:53
*** lpoulain <lpoulain!lpoulain@gateway/shell/linaro/x-ntjhrxrunvsizaqc> has joined #yocto01:53
*** rfs613 <rfs613!> has joined #yocto01:53
*** rr123 <rr123!~xxiao@> has joined #yocto01:53
*** ka6sox <ka6sox!~ka6sox@nasadmin/ka6sox> has joined #yocto01:53
*** yocton <yocton!~quassel@> has joined #yocto01:53
*** champagneg <champagneg!> has joined #yocto01:53
*** M4x4dib <M4x4dib!~m4x4dib@2601:2c3:c100:fa50:b98e:8ad6:391c:584f> has quit IRC01:55
*** minimaxwell <minimaxwell!> has joined #yocto01:58
*** kaspter <kaspter!~Instantbi@> has joined #yocto01:58
*** gpanders <gpanders!> has quit IRC01:58
*** gpanders <gpanders!> has joined #yocto01:59
*** gpanders <gpanders!> has quit IRC02:00
*** gpanders <gpanders!> has joined #yocto02:01
*** sakoman <sakoman!~steve@> has quit IRC02:16
*** M4x4dib <M4x4dib!~m4x4dib@2601:2c3:c100:fa50:b98e:8ad6:391c:584f> has joined #yocto02:33
*** M4x4dib <M4x4dib!~m4x4dib@2601:2c3:c100:fa50:b98e:8ad6:391c:584f> has quit IRC02:38
*** kaspter <kaspter!~Instantbi@> has quit IRC02:46
*** kaspter <kaspter!~Instantbi@> has joined #yocto02:46
*** georgem_home <georgem_home!uid210681@gateway/web/> has quit IRC03:03
*** linums <linums!> has quit IRC03:14
*** NiksDev <NiksDev!~NiksDev@> has quit IRC03:16
*** mrc3 <mrc3!~mrc3@linaro/mrc3> has quit IRC03:42
*** linums <linums!> has joined #yocto03:46
*** roussinm <roussinm!> has quit IRC03:54
*** mrc3 <mrc3!~mrc3@linaro/mrc3> has joined #yocto03:55
*** Spooster <Spooster!> has quit IRC04:51
*** arpa <arpa!> has joined #yocto05:06
*** jobroe <jobroe!> has joined #yocto05:17
*** AndersD <AndersD!> has joined #yocto05:42
*** arpa <arpa!> has quit IRC05:44
*** AndersD_ <AndersD_!> has joined #yocto05:45
*** AndersD <AndersD!> has quit IRC05:47
*** rob_w <rob_w!~rob@unaffiliated/rob-w/x-1112029> has joined #yocto06:00
*** camus <camus!~Instantbi@> has joined #yocto06:02
*** kaspter <kaspter!~Instantbi@> has quit IRC06:02
*** camus is now known as kaspter06:03
*** RobertBerger <RobertBerger!> has joined #yocto06:04
*** arpa <arpa!d98c63fb@> has joined #yocto06:19
*** agust <agust!> has joined #yocto06:19
*** arpa <arpa!d98c63fb@> has quit IRC06:19
*** frsc <frsc!> has joined #yocto06:23
*** kaspter <kaspter!~Instantbi@> has quit IRC06:23
*** kaspter <kaspter!~Instantbi@> has joined #yocto06:24
*** manuel1985 <manuel1985!~manuel198@2a02:1748:dd5c:f290:2159:8592:80e6:8802> has quit IRC06:32
*** mckoan|away is now known as mckoan06:40
*** fl0v0 <fl0v0!~fvo@> has joined #yocto06:56
*** extorr <extorr!extor@unaffiliated/extor> has quit IRC06:59
*** extorr <extorr!extor@unaffiliated/extor> has joined #yocto07:00
RobertBergerAny devtool experts here?07:04
*** tnovotny <tnovotny!> has joined #yocto07:22
*** yannholo <yannholo!> has joined #yocto07:25
*** manuel1985 <manuel1985!~manuel198@> has joined #yocto07:28
*** jobroe_ <jobroe_!> has joined #yocto07:29
*** jobroe <jobroe!> has quit IRC07:30
mcfriskgah, can someone explain what the difference between "bitbake --runall=fetch foo" and "bitbake --runonly=fetch foo" is? does any of them run the task only for those recipes which need to be recompiled and where sstate is not uptodate?07:36
RPabelloni: Looks like a "fun" build for SWAT :(. I triaged a couple of bits07:36
RPmcfrisk: One will look at every recipe in the taskgraph and then run the task whether it would have run in the original command or not07:37
RPmcfrisk: the other will run the specified task on if it was in the original task graph07:38
RPmcfrisk: so I think you'd want --runonly07:39
mcfriskRP: Thanks! darn, I'm running --runonly=fetch and it seems to run fetch for all tasks even if they don't need to be compiled, so ignoring the sstate. I'm trying to switch to offline builds and need to hack the real bitbake run to work without any networking inside the build container to be sure. And need to run a fetch task before that in online mode and that is too slow atm..07:41
RPmcfrisk: oh, sorry, I misunderstood. It will run them all since there is no sstate associated with the task07:42
RPmcfrisk: we don't have a way to do what you describe, that isn't an easy thing to express/discover :/07:44
*** mbulut <mbulut!> has joined #yocto07:45
mcfriskRP: hmm, the problem for me is that BB_NO_NETWORK is not enough. I really need to break all networking in the build environment to make sure that recipe build scripts don't access random Internet/intranet servers etc. Hence build must be split to an online fetch step to update local caches, followed by an offline build.07:47
RPmcfrisk: This is what --runonly=fetch was designed for but it will run all the fetch tasks as it can't tell if the cache is up to date or not07:51
*** prabhakarlad <prabhakarlad!> has joined #yocto07:52
mcfriskand when I do this, build time for full sstate one is doubled from 30 to 60 minutes. the fetch'ing of all recipes takes too long. Should only be done incrementally somehow, only if recipe needs to be recompiled07:52
RPmcfrisk: I'm surprised as the fetch tasks should see the sources already present and run quckly07:52
RPmcfrisk: we do that on the autobuilders for example step 14 which took about 60s07:54
RPabelloni: I triaged one of the a-full builds, there is a second which probably can have some of the entries copied over07:57
mcfriskRP: does that have a local download pre-mirror?07:57
RPmcfrisk: yes, it isn't from scratch07:58
mcfriskRP: I'll check in detail what's wrong with my setup. I also should have a full local DL_DIR and nothing needs to be fetched again. Thanks a lot!08:01
*** aquijoule_ <aquijoule_!> has quit IRC08:06
*** aquijoule_ <aquijoule_!> has joined #yocto08:06
abelloniRP: ah right, I was looking at the qemux86-64-ptest failure of that build08:07
*** psnsilva <psnsilva!~psnsilva@> has joined #yocto08:12
*** Bunio_FH <Bunio_FH!> has quit IRC08:13
*** Bunio_FH <Bunio_FH!> has joined #yocto08:17
RPabelloni: there are a ton of issues there, I've tried to help a bit...08:20
abelloniyes, I'm very late triage, I'm on it right now08:20
RPabelloni: I was meaning in that build. Would be good to be up to date before triage today though08:27
*** M4x4dib <M4x4dib!~m4x4dib@2601:2c3:c100:fa50:b98e:8ad6:391c:584f> has joined #yocto08:32
*** kaspter <kaspter!~Instantbi@> has quit IRC08:33
*** kaspter <kaspter!~Instantbi@> has joined #yocto08:33
*** camus <camus!~Instantbi@> has joined #yocto08:36
*** kaspter <kaspter!~Instantbi@> has quit IRC08:37
*** camus is now known as kaspter08:37
*** thekappe <thekappe!c65a42b1@> has joined #yocto08:43
thekappe"Hello world !" [cit.]08:44
thekappeDoeas anyone ever worked with the "stateless-rootfs" FEATURE ?08:44
*** goliath <goliath!> has joined #yocto09:02
rburtonmcfrisk: runall=fetch will *definitely* only fetch what is missing from DL_DIR, so you've got problems with that persisting between builds09:03
rburtonzeddii: should meta-virt work with gcc11?09:07
mcfriskrburton RP: yep, I confirmed with some instrumentation that running "bitbake -k --runonly=fetch foo" takes only 140 seconds which is decent for a fully uptodate DL_DIR and large project. there is something else making my builds slower.09:30
mcfriska lot of do_fetch taks do get executed and that put me off to wrong path. will check the timings instead.09:31
rburtoniirc they run but do nothing as the files exist09:31
mcfriskyep, and seem to be fast. I can even increase parallel options as fetching isn't memory limited like real compilation09:32
*** M4x4dib <M4x4dib!~m4x4dib@2601:2c3:c100:fa50:b98e:8ad6:391c:584f> has quit IRC09:34
*** Lihis <Lihis!> has quit IRC09:40
*** Lihis <Lihis!> has joined #yocto09:41
RPabelloni: looks like there is a git config setup issue on fedora3309:42
thekappeguys, If I need to port systemd vXXXX >243 to thud which has v239, Which can be a good strategy ?10:54
rburtonstop using thud10:59
rburtonto backport, copy the recipes and verify the output carefully11:00
thekappeI really can't at the moment11:02
thekappeI've already tried to copy the recipes but it's no so straightforward11:02
rburtonNo, it's not11:02
thekappeyap, I've noticed11:03
rburtonYou're upgrading fundamental parts of the stack on a release which has been unmaintained for 18 months.  It's not going to be easy at all.11:04
rburtonIf you're using thud for new development I hope you have a support contract, so maybe ask whoever provides that if they have updated systemd recipes11:06
*** JaBen <JaBen!Thunderbir@gateway/vpn/mullvad/jaben> has joined #yocto11:08
thekappeI am the support11:10
thekappethe developer11:10
thekappeand the tester11:10
thekappethe repo mainter and the issue tracker11:11
thekappeI maybe be a little short of workforce at the moment11:11
RPkanavin: I started picking off bits of your patchset. I assume you'll be working on a second iteration so I should probably wait on that before going too much further?11:14
*** JaBen <JaBen!Thunderbir@gateway/vpn/mullvad/jaben> has quit IRC11:15
*** meow` <meow`!~sbourdeli@> has joined #yocto11:16
*** freanux <freanux!~freanux@unaffiliated/freanux> has joined #yocto11:26
*** prabhakarlad <prabhakarlad!> has quit IRC11:30
*** georgem_home <georgem_home!uid210681@gateway/web/> has joined #yocto11:50
*** yannholo <yannholo!> has quit IRC11:52
*** thekappe <thekappe!c65a42b1@> has quit IRC11:56
*** camus <camus!~Instantbi@> has joined #yocto12:09
*** kaspter <kaspter!~Instantbi@> has quit IRC12:11
*** camus is now known as kaspter12:11
kanavinRP: so far, there's actually nothing that would warrant a second iteration :)12:13
*** jobroe_ <jobroe_!> has quit IRC12:14
*** prabhakarlad <prabhakarlad!> has joined #yocto12:15
zeddiirburton: I'm working on gcc11 support in meta-virt now. uprevs and such to fix issues.12:16
*** linums <linums!> has quit IRC12:19
*** linums <linums!> has joined #yocto12:21
*** rcoote <rcoote!~rcoote@2a02:908:692:81c0:71ec:66db:4b21:cbe2> has joined #yocto12:33
*** ahalaney <ahalaney!> has joined #yocto12:35
*** rcoote <rcoote!~rcoote@2a02:908:692:81c0:71ec:66db:4b21:cbe2> has quit IRC12:41
*** argonautx <argonautx!> has joined #yocto12:41
*** eFfeM1 <eFfeM1!b9b86d22@> has joined #yocto12:44
eFfeM1Hi, we want ot use an sstate dir shared between multiple users, but somehow every once in a while we get messages like this one12:45
eFfeM1Exception: bb.process.ExecutionError: Execution of '/workdir/build-xavier-nx/tmp/work/armv8a_tegra-sorama-linux/cuda-nvdisasm/10.2.89-1-r0/temp/run.sstate_create_package.10212' failed with exit code 1:12:45
eFfeM1mktemp: failed to create file via template ‘/workdir/build-xavier-nx/../files/bitbake/sstate-cache/bb/a5/sstate:cuda-nvdisasm:armv8a_tegra-sorama-linux:10.2.89-1:r0:armv8a_tegra:3:bba5d5db21e3f24d4d85064b9bd2354bb67833210254ca47f8fe29c1133be669_package_write_deb.tgz.XXXXXXXX’: Permission denied12:45
*** caiortp <caiortp!> has joined #yocto12:45
eFfeM1The root cause is that the file already exists and is created by a different user, but why would a 2nd user want to overwrite this file?12:46
eFfeM1the sstate dir is on the same system12:46
mckoaneFfeM1: sstate dir shared between multiple users doesn't work AFAIK12:47
RPkanavin: I saw quite a bit of discussion. I'm not sure I agree with just removing that expat change for example :/12:47
RPmckoan: it should12:49
*** paulg <paulg!> has quit IRC12:50
RPeFfeM1: It shouldn't be using XXXXXXX directly but replacing that with a tmp file mask :/12:50
eFfeM1mckoan I found references that it should, even with NFS on an NFS dir12:50
eFfeM1RP, ahhh12:50
RPthe autobuilder does exactly that12:50
*** rcoote <rcoote!~rcoote@2a02:908:692:81c0:84e7:69a1:ef6c:26e2> has joined #yocto12:51
*** Spooster <Spooster!> has joined #yocto12:51
kanavinRP: I looked into expat, and wrote a followup12:51
eFfeM1still struggling with another issue at the moment but that at least gives a hint on where to look12:51
kanavinRP: expat ptests were never enabled in the first place12:51
RPzeddii: I had wondered if that was what you'd done :)12:51
RPzeddii: I do hate it when your own sanity tests complain about your sanity :/12:52
qschulzeFfeM1: it's dangerous because if one user does a cleansstate, it's gone for everybody. And I assume Yocto isn't really built to handle sstate-cache that disappears after parsing everything?12:52
*** caiortp <caiortp!> has quit IRC12:52
kanavinRP: the rest was Khem indulging in bike-shedding to be honest which he does sometimes :-/12:52
qschulzif that is somehow working, I guess having two users recreating the sstate-cache from scratch at the same time could result in both users trying to install the same package12:53
eFfeM1qschulz yes cleansstate would be a pain12:53
qschulzeFfeM1: what you can do if you want to share the sstate-cache, is to have them all (or a main server) have a webserver exposing the sstate-cache directory and set up SSTATE_MIRRORS in local.conf to point to those webservers12:54
RPkanavin: well, there were questions which needed answering in some areas12:54
RPqschulz: we use atomic renames to avoid that12:54
kanavinRP: I guess you should hold off the items that prompted a discussion, but I still don't see what I could do about them realistically12:55
kanavinRP: cmake with qt needs a clear test that would confirm that nothing breaks with patch removal, and there isn't, as no one anymore remembers what the original issue really was12:57
*** ayoung <ayoung!~ayoung@2601:19c:4680:ee30:b6cc:8682:e628:1585> has joined #yocto12:57
RPkanavin: I was going to look at just pulling some and that started worrying about patch inter-dependencies12:57
eFfeM1qschulz yes but putting it on a server would require that someone every once in a while updates the server cache (and I fear that someone then is going to be me :-)12:58
eFfeM1meanwhile I peeked into sstate_create_package and it has12:58
eFfeM1        TFILE=`mktemp ${SSTATE_PKG}.XXXXXXXX`12:58
RPeFfeM1: but mktemp is supposed to replace that, its a pattern12:59
eFfeM1and the system has a good mktemp, so the filename is a indeed odd12:59
eFfeM1RP, I know12:59
eFfeM1so this is very strange12:59
RPeFfeM1: I wonder if pseudo is breaking things somehow12:59
eFfeM1pff, that is an area I did not venture in before13:00
*** geheimnis` <geheimnis`!~geheimnis@> has quit IRC13:00
eFfeM1but I can try to add some debugging code; after my current job finishes13:00
kanavinRP: right, the gi-docgen thing is tightly coupled with pango/gdk-pixbuf update. meson update is followed by a couple patches that fix things. Same for gnu-efi update. dnf/libdnf updates are best taken together. The rest should be self contained.13:01
qschulzeFfeM1: except if all your users have a webserver, in which case, they all sync their sstate-cache when a sstate-cache entry is needed13:02
* alephan < >13:02
*** paulg <paulg!> has joined #yocto13:03
eFfeM1qschulz that is an interesting idea13:07
eFfeM1for now I found another clash, this one does not have the XXXXX pattern in the name13:07
*** geheimnis` <geheimnis`!~geheimnis@> has joined #yocto13:10
*** armpit <armpit!~armpit@2601:202:4180:a5c0:8589:f92a:54a1:6475> has quit IRC13:10
kanavinRP: I can write better commit messages to those items which caused discussions, but there's nothing to actually change in those patches13:12
*** armpit <armpit!~armpit@2601:202:4180:a5c0:899e:2fa0:8320:d89b> has joined #yocto13:13
*** dev1990_ <dev1990_!> has quit IRC13:14
*** dev1990 <dev1990!> has joined #yocto13:15
*** zkrx <zkrx!~slimshady@> has quit IRC13:15
qschulzalephan: your message is sent to the IRC channel as a link, not as actual message. If you can just make sure we get the text directly, you'll have a much bigger chance to have an answer13:19
qschulz(I think it's usually because of formatting or messages being too long13:19
alephanqschulz: exactly I'll repost13:19
*** M4x4dib <M4x4dib!~m4x4dib@2601:2c3:c100:fa50::e272> has joined #yocto13:19
alephanThanks a lot13:19
*** paulg <paulg!> has quit IRC13:21
alephanThere seems to be a bug when using `runqemu` in builds done from sstate mirrors. In this case, STAGING_BINDIR_NATIVE will not be populated for `qemu-helper-native` so the `runqemu` script will fail with:13:23
alephanrunqemu - ERROR - Native sysroot directory [...]/build/tmp-newlib/work/x86_64-linux/qemu-helper-native/1.0-r1/recipe-sysroot-native/usr/bin doesn't exist13:23
alephanI'm trying to figure out if this is a known issue or somehow specific to `dunfell`. Is anyone aware of this?13:23
*** stwcx <stwcx!~stwcx@2604:880:a:6::c9c> has quit IRC13:25
*** stwcx <stwcx!~stwcx@> has joined #yocto13:28
*** boo <boo!021955e8@> has joined #yocto13:29
alephanqschulz: did this ^ do the trick?13:29
RPkanavin: if you could tweak the messages I think that would help13:29
RPkanavin: can we figure out whether there are ptests not listed in fast/slow ?13:32
*** zkrx <zkrx!~slimshady@> has joined #yocto13:32
zeddiialejandrohs: do you ever use WSL2, or just an observer on the state of things ?13:33
*** ahalaney <ahalaney!> has quit IRC13:33
*** c4t3l_home <c4t3l_home!~rcallicot@> has joined #yocto13:33
*** ajhalaney <ajhalaney!> has joined #yocto13:33
*** dev1990 <dev1990!> has quit IRC13:33
*** dev1990 <dev1990!> has joined #yocto13:34
RPkanavin: I did notice the cruft in puzzles recipe does actually do something but I'm going to ignore it13:34
RPkanavin: I never agreed with it in the first place, rburton probably would argue for it :)13:34
*** paulg <paulg!> has joined #yocto13:34
eFfeM1zeddii did a build under WSL2 work for you? I tried it a few times but somewhere halfway I ended up in a total hangup of my system13:35
*** ecdhe_ <ecdhe_!~ecdhe@unaffiliated/ecdhe> has joined #yocto13:35
eFfeM1suspect it may be better if you can use ext2 filesystems under WSL2; that is in the insider program, but I did not want to put a non-mainstream windows version on my system13:36
zeddiiheh. yah. I don't want to do builds, but was looking for the better I/O on WSL2 versus the original, when I was poking at repos.13:38
zeddiibut they've messed up the networking so badly, that I was looking to throw scorn at someone :D13:38
*** ecdhe <ecdhe!~ecdhe@unaffiliated/ecdhe> has quit IRC13:38
qschulzalephan: it did, fingers crossed it'll get people to asnwer it now :)13:48
*** c4t3l_home <c4t3l_home!~rcallicot@> has quit IRC13:49
*** c4t3l_home <c4t3l_home!~rcallicot@> has joined #yocto13:50
*** kaspter <kaspter!~Instantbi@> has quit IRC13:50
*** kaspter <kaspter!~Instantbi@> has joined #yocto13:50
*** eduardas <eduardas!> has joined #yocto13:55
*** sakoman <sakoman!~steve@> has joined #yocto13:57
*** psnsilva <psnsilva!~psnsilva@> has quit IRC13:59
*** psnsilva <psnsilva!~psnsilva@> has joined #yocto13:59
*** lucaceresoli <lucaceresoli!~lucaceres@> has joined #yocto14:04
*** kaspter <kaspter!~Instantbi@> has quit IRC14:04
RPalephan: I think the key question is what you're running before calling runqemu14:16
RPand whether we'd expect that to restore the helper14:16
alephanRP: that is a good point. And I think that gives me the answer to the problem14:17
alephanI'm building a zephyr application.14:17
RPalephan: meta/conf/machine/include/ += "qemu-system-native qemu-helper-native"14:19
RPalephan: that is how we do it with core14:19
alephanIn zephyr that is done with a `DEPENDS_append_qemuall` in the recipe14:20
rburtonzeddii: found fedora has a patch to fix xen-tools14:21
rburtonhm, fetch failing with do_unpack: Unpack failure for URL: 'git://;type=kmeta;name=meta;branch=yocto-5.10;destsuffix=kernel-meta'. No up to date source found: clone directory not available or not up to date: /builds/persist/downloads/git2/; shallow clone not enabled14:21
*** paulg <paulg!> has quit IRC14:21
zeddiirburton: aha. nice. We were just going to mask it, but that works better.14:23
*** kpo_ <kpo_!> has quit IRC14:23
zeddiiI don't think I did anything odd with the kernel-cache repo that would have caused that 2nd thing though.14:24
*** kpo_ <kpo_!> has joined #yocto14:24
alephanRP: I'm not sure how this actually works. Because when the sstate mirror is used, do_populate_sysroot_setscene won't populate the native recipe sysroot.14:24
alephanSo even if the dependency is fine, it won't bring in the bindir of native sysroot for the wrapper's recipe14:25
alephanThere is another dependency that makes that explicit somewhere14:25
RPalephan: meta/classes/testimage.bbclass:TESTIMAGEDEPENDS_append_qemuall = " qemu-native:do_populate_sysroot qemu-helper-native:do_populate_sysroot qemu-helper-native:do_addto_recipe_sysroot" if you're using testimage14:25
alephanThat's it!14:26
*** prabhakarlad <prabhakarlad!> has quit IRC14:26
alephanBut that is only for a testimage14:26
alephanHow come it doesn't fail on normal images in the core?14:26
rburtonzeddii: is the fedora one.  no idea if its 'right' or being upstreamed.14:26
RPalephan: I'm not quite sure, I'd have assumed it was the EXTRA_IMAGEDEPENDS14:27
alephanI'll dig a bit. Thanks for the hints.14:28
RPdl9pf, smurray: ? :/14:29
RPnew lua dependency?14:29
*** bps <bps!> has quit IRC14:30
smurrayRP: yeah, I rebased the meta-agl next branch which picked up the new wireplumber recipe, it now has a Lua dependency14:31
smurrayRP: my apologies, I forgot that all layers are getting tested in meta-agl now, was only testing meta-agl-core14:32
*** paulg <paulg!> has joined #yocto14:36
*** prabhakarlad <prabhakarlad!> has joined #yocto14:37
*** ecdhe_ is now known as ecdhe14:39
*** eFfeM1 <eFfeM1!b9b86d22@> has quit IRC14:39
*** paulg <paulg!> has quit IRC14:41
*** drofty <drofty!~drofty@> has joined #yocto14:42
droftyERROR: Task (/home/drofty/yocto/poky/meta/recipes-core/glibc/ failed with exit code '1'14:43
*** meow` <meow`!~sbourdeli@> has quit IRC14:43
*** meow` <meow`!~sbourdeli@> has joined #yocto14:44
*** linums <linums!> has quit IRC14:45
v2dmoto-timo: thanks for your suggestion regarding python3-protobuf-distutils-native. However that is for building a custom recipe with custom do_install. Wouldn't it be better to extend the setuptools.bbclass so that we can build|install with as usual? (setuptools extension really just add new variables to their
*** yannholo <yannholo!> has joined #yocto14:48
qschulzdrofty: you have a path to a log file a few lines above, read it to start debugging or post here the important content (where the error comes from)14:49
smurrayRP: meta-oe is added as a dependency, any ideas on why that's not enough to get lua?14:50
*** dev1990_ <dev1990_!> has joined #yocto14:51
*** dev1990 <dev1990!> has quit IRC14:52
droftyhey qschulz here is the log .. should i delete this and run bitbake again ?  /home/drofty/yocto/poky/build/downloads/git2/
drofty this file14:53
*** linums <linums!> has joined #yocto14:53
droftyi have 100mbps internet still files are getting downloaded at 250KBps ._. any way to increase the speed?14:54
*** paulg <paulg!> has joined #yocto14:54
*** yannholo <yannholo!> has quit IRC14:56
*** AndersD_ <AndersD_!> has quit IRC14:59
*** bps <bps!~bps@> has joined #yocto15:00
*** tnovotny <tnovotny!> has quit IRC15:03
*** sbach <sbach!~sbachmatr@> has quit IRC15:20
*** sbach <sbach!~sbachmatr@> has joined #yocto15:20
*** Nithesh <Nithesh!a5e17a9a@> has joined #yocto15:20
NitheshPACKAGECONFIG[gtk] = "--with-gtk3,--without-gtk3,gtk+3"15:20
Nitheshwhat does this line mean15:21
NitheshJPEW i couldn't understand there15:23
Nitheshhow is gtk disabled here15:23
JPEWNithesh: Bascially, if "gtk" is in "PACAKGECONFIG" it's enabled, otherwise it is disabled15:24
Nitheshthen how  --without-gtk3 work15:25
JPEWIf "gtk3" is *not* in PACAKGECONFIG, that gets added to the configure arguments15:25
Nitheshok thanks15:26
rburtonoh, conflicting packageconfig support got merged?15:27
*** Nithesh <Nithesh!a5e17a9a@> has quit IRC15:28
qschulzrburton: yup a few releases ago15:29
rburtonsomehow missed that!15:29
*** nate100 <nate100!880210b6@gateway/web/cgi-irc/> has joined #yocto15:29 is super slow for me, same for some of you?15:30
nate100Any advice on getting the Yocto Eclipse plugin working? It seems that the repository is empty/broken?,
nate100On that note, is that project deprecated/not in use? Hasn't been updated since 2.6.115:36
qschulzrburton: documented since dunfell, might predates that even?15:36
RPsmurray: if you changed the dependencies that would be the issue15:37
RPsmurray: we had to turn off autodetection :(15:38
smurrayRP: I've got a fix to the meta-pipewire layer.conf in hand, will push shortly15:38
RPsmurray: let me know if I need to change the autobuilder config15:39
RPsmurray: with fixes pending for OE-Core we may be able to renable autodetection again15:39
RPkanavin: I hacked expat-ptest into fast and it all passes:
RPkanavin: I'll send a patch to add that15:42
*** frsc <frsc!> has quit IRC15:44
*** nate100 <nate100!880210b6@gateway/web/cgi-irc/> has quit IRC15:44
*** AndersD <AndersD!> has joined #yocto15:47
*** frsc <frsc!> has joined #yocto15:48
*** AndersD_ <AndersD_!> has joined #yocto15:48
*** goliath <goliath!> has quit IRC15:49
*** AndersD <AndersD!> has quit IRC15:51
smurrayRP: I believe it should be good now15:55
JaMarburton: Saur: ping2
RPsmurray: thanks15:57
droftyhow to set sstate mirrors can i use it for free? m building dunfell version15:59
*** meow` <meow`!~sbourdeli@> has quit IRC15:59
*** mbulut <mbulut!> has quit IRC16:01
*** meow` <meow`!> has joined #yocto16:02
v2dwhat is MACHINE_GUI_CLASS?16:03
*** meow` <meow`!> has joined #yocto16:03
ScorpiHi, bitbake <package> does not re-generate ipk files here. The timestamp is the old one, and removing the old ones does not generate new ipk files16:03
Scorpiat least not in tmp/deploy/ipk/16:04
qschulzScorpi: if nothing changed in the recipe or dependencies of this recipe, then it's not rebuilt16:06
qschulzScorpi: and it's bitbake <recipe> BTW :)16:06
Scorpiqschulz: I changed the recipe16:06
Scorpiqschulz: yeas, it's the same in this case (busybox)16:06
Scorpiqschulz: I made a change to the defconfig, and now reverted that change and created a custom recipe with a .bbappend with the config change16:07
Scorpiqschulz: so I guess it should be rebuilt16:07
*** fl0v0 <fl0v0!~fvo@> has quit IRC16:07
qschulzNot necessarily16:08
qschulzif the bbappend applied to the bb is identical to the modified bb you had before, it won't be rebuilt16:08
Scorpiqschulz: I won't, as it comes with a config snipset that was not present before16:09
Scorpiqschulz: I also saw that the patch, configure, compile steps etc. where done16:10
Scorpiqschulz: then I noticed that the ipk files had old timestamps, which should not be the case I think16:10
Scorpiqschulz: in the log file, I can see that the configure step invokes merge_config with my config snipset, so it seems to work as intended16:12
*** bps <bps!~bps@> has quit IRC16:14
qschulzScorpi: which release are you on?16:15
*** frsc <frsc!> has quit IRC16:16
*** meow` <meow`!> has quit IRC16:18
*** meow` <meow`!> has joined #yocto16:19
Scorpiqschulz: 3.1.316:20
qschulzI'm not entirely sure but I think that release is using the hash equivalence server16:21
qschulzwhich means if a task with a different hash ends up producing the same output than another task, the tasks that follow are taken from the sstate cache16:22
*** rob_w <rob_w!~rob@unaffiliated/rob-w/x-1112029> has quit IRC16:22
Scorpiokay, makes sense16:24
Scorpican I wipe that specific files from the sstate cache using bitbake?16:25
qschulzbitbake -c cleansstate <recipe> but... why?16:26
ScorpiTo get the ipk files in tmp/deploy, as I deleted them16:27
ScorpiI thought that there were the build result, which is regenerated when it is missing when I invoke bitbake again16:30
ecdheI'm figuring out wic right now.  I've got a WKS file that describes the partitions needed by my target platform's boot ROM (the typical fat32 partition up front.)  The boot ROM requires the presense of a first-stage boot loader with a specific filename.  This file does not need to appear anywhere on the booted target's rootfs, only on the FAT partition.16:32
ecdheHow can I prepare a second filesystem for `wic' to copy to my fat partition?16:32
qschulzScorpi: or remove your whole TMPDIR, that should make Yocto install them again16:33
*** mckoan is now known as mckoan|away16:34
qschulzjust don't remove the sstate-cache and downloads directories, the rest is safe to delete16:34
qschulz(well maybe there's some hashserv files but I'm not on 3.1+ so can't say for sure)16:34
Scorpiqschulz: -c cleansstate works16:35
*** eFfeM1 <eFfeM1!b9b86d22@> has joined #yocto16:43
qschulzScorpi: yes but only for that package, if you remove more, the others still won't be available16:44
*** c4t3l_home <c4t3l_home!~rcallicot@> has quit IRC16:45
*** c4t3l_home <c4t3l_home!~rcallicot@> has joined #yocto16:49
*** renegade <renegade!~renegade@2601:241:8a00:46e0:649a:6fcd:d26a:d56b> has joined #yocto16:53
renegadeHi i'm trying to reduce the size of the image. I see python3 is really big. Is there a way to reduce the size of it? Not seeing anything specific in the recipes16:53
eFfeM1qschulz RP wrt my sstate problem: I found that even if I start my bitbake with a umask 0000 it still creates dirs in sstate with mode 755 and other users then cannot write into that directory16:55
eFfeM1haven't found a decnt way to fix it16:55
eFfeM1actaually just discovered an os.umask(0o022) after a fork in bitbake/lib/pyinotify.py16:57
eFfeM1no idea if that is realted16:57
*** eFfeM <eFfeM!> has joined #yocto16:59
RPeFfeM1: the idea is the sstate code should be using a different umask but I can't remember what/where17:05
*** kpo <kpo!> has joined #yocto17:14
eFfeMRP suspected that but haven't found it yet, I've been peeking into sstate.bbclass, that one uses bb.utils.mkdirhier which in turn calls some os.makedirs function or so (forgot the exact name)17:22
RPeFfeM: meta/classes/sstate.bbclass:       bb.note("Using umask 0o002 (not %0o) for sstate packaging" % omask)17:25
RPeFfeM: but I didn't look in detail17:25
eFfeMRP ah ok didn't find that one, still I noticed a dir with mode 75517:26
eFfeMRP anyway, that will help me to proceed17:26
eFfeMthanks a lot!17:27
*** c4t3l_home <c4t3l_home!~rcallicot@> has quit IRC17:29
yatesi've specified version 5.8.13 of the kernel in my image and am seeing linux-yocto/5.8.13+gitAUTOINC+b976de4f41_3c5d210805-r0 under the tmp/work directory. does this come from a repo?17:32
*** drofty <drofty!~drofty@> has quit IRC17:32
*** AndersD_ <AndersD_!> has quit IRC17:34
yatesthere is a kernel-meta folder under there with an "arch" subfolder that looks somewhat like the arch folder in the linux kernel tree, but it's missing quite a few subfoldres17:35
*** psnsilva <psnsilva!~psnsilva@> has quit IRC17:36
yatescan someone help me understand where yocto is getting this from?17:36
*** psnsilva <psnsilva!~psnsilva@> has joined #yocto17:37
yatesand what are these .scc files there?17:38
*** blueness_ <blueness_!~blueness@gentoo/developer/blueness> has quit IRC17:38
*** blueness <blueness!~blueness@gentoo/developer/blueness> has joined #yocto17:39
*** c4t3l_home <c4t3l_home!~rcallicot@> has joined #yocto17:41
*** paulg <paulg!> has quit IRC17:42
renegadeI believe kernel meta comes from here
renegadeI'm not sure how the arch subfolder is populated, I ran into a similar issue17:45
*** paulg <paulg!> has joined #yocto17:55
*** kpo__ <kpo__!> has joined #yocto17:56
*** eFfeM <eFfeM!> has quit IRC17:56
*** kpo <kpo!> has quit IRC17:57
*** prabhakarlad <prabhakarlad!> has quit IRC17:59
matthewcroughanDoes anybody in Yocto do this kind of analysis?
*** eFfeM1 <eFfeM1!b9b86d22@> has quit IRC18:01
matthewcroughanInteresting, so do you have the same issues with GCC that Nix does?18:03
matthewcroughanAnd so is there a test framework that you use for images?18:03
matthewcroughanThe raw test results is in json, I'm wondering how the QEMU image is ran, for example.18:03
khemkanavin: I dont mean to indulge in wasting time. it has become very hard to upgrade to newer major release is what we hear from lot of users and I am also witness myself one of the reason is we break them all the time.  so I am trying to pay attention to some packages that impact us here and . we can not cover unknown cases, but where we know we should be considerate, unfortunately powertop is used in some RDK profile, which I18:04
khemhave now punted out, so that change does not bother RDK,  but probably we want projects to use our stuff and not carve our way to insulate themselves, there are field issues which we have spend 4 months to find our that someone thought it was ok to disable certain option in curl. so if someone is reviewing stuff, pay attention and try to reason on usability grounds too, there is an effort to upgrade to dunfell, and year plus, its18:04
khemstill not done due to these kind of issues, I am being asked to not upgrade yocto anymore, and most probably I have to give in this time.18:04
*** prabhakarlad <prabhakarlad!> has joined #yocto18:06
matthewcroughansakoman: How do I find out what it was that "wasn't" reproducible.?18:07
matthewcroughanThe excluded packages.18:07
ecdheTo get `wic' will interpret a .wks file with the line 'part / --source rootfs'  to mean that it should create a partition, the partition should be mounted at /, and yocto's root filesystem should be copied there.18:20
ecdheBut if I have a fat32 filesystem that shouldn't be mounted, how do I copy files to it?18:20
ecdheCan I generate a second rootfs?18:20
ecdheHow do I tell e.g. the uboot recipe that u-boot.bin belongs in the second partition?18:21
*** manuel1985 <manuel1985!~manuel198@> has quit IRC18:25
*** LetoThe2nd <LetoThe2nd!uid453638@gateway/web/> has joined #yocto18:29
renegadedo something like this for a second rootfs part --source rootfs --ondisk mmcblk0 --fstype=ext4 --label root2 --align 4096 --fixed-size=2G18:29
LetoThe2ndyo dudX18:29
renegadethat being said I can't seem to generate a proper third rootfs18:30
ecdherenegade: wouldn't a line like that would generate a second partition that would get a second copy of the same rootfs?18:31
ecdheI was looking to make a different rootfs (perhaps called bootromfs)18:31
renegadeah my bad, yes that will be a copy18:31
LetoThe2ndecdhe: sounds like you want a build-in-build. yay multiconfig!18:32
kergothhmm, yeah, you might need a second image recipe for that, then have wic pull in that image binary..18:33
kanavinRP: right, then we'd need to see if it still passes with expat version update, and whether dropping the patch affects the output18:33
*** yates <yates!> has quit IRC18:34
renegadehe could use rawcopy as a source to copy that image?18:34
kanavinkhem, that's why here I have insisted on setting up rolling master builds, precisely so we avoid big bang updates where a million things break anyway, regardless of how careful we are. I don't think being nitpicky about powertop and friends is going to fundamentally change that.18:35
RPkanavin: right, those are the next logical steps. I would like to have the testing if we can18:36
kanavinkhem, here we're almost done with pushing those builds all the way to 3.3 - in addition to dunfell builds which have been going almost since dunfell was tagged18:36
renegadesince we are talking wic. Why is an extended partition tacked on the end when I make more than 4 partitions?18:37
renegadeI have 1 boot, 2 rootfs, 1 bootenv, 3rd rootfs. If I open the image in disks the 3rd rootsfs seems to be pushed after an extended partition18:38
kanavinRP: I'll try to compile a list of other ptests that are not listed, I guess it could be a simple grep and tweaking/sorting the output18:38
RPrenegade: don't you need an extended partition table for more than 4 entries?18:39
kergothrenegade: that doesn't have anything to do with wic, but the limitations of a dos style partition table. presumably if you used gpt it wouldn't have that issue18:39
kergothbut not 100% sure on that..18:39
RPkergoth: matches some recollection I have too :)18:39
RPkanavin: I'm wondering if we could somehow detect ptests that weren't listed, add some kind of sanity check18:39
kergothhmm, i should probably suggest rolling master CI builds at work too, fixing things when we switch to the next release is always a pain...18:41
renegadehow would i use gpt? All i'm doing is changing a .wks file right now and hoping for the best18:41
kanavinRP: it'd be extra tricky because we also have ptests that exist, but are commented out due to being broken in various ways18:43
*** yates <yates!> has joined #yocto18:44
yatessorry if i missed the answer to my earlier question - had to reboot18:44
yatesis the channel logged?18:45
RPkanavin: we could create a list of ones we know to ignore?18:47
yatesre: 5.8.13+gitAUTOINC+b976de4f41_3c5d210805-r018:47
yateskhem: do you have any thoughts?18:48
kanavinRP: I wonder if ptest class could include directly and simply check the presence of ${PN}-ptest in there18:50
kanavinthe list would need to be accessible to the class though, which probably means it needs itself to become a class18:51
yateshas anyone noticed that converting files to pdf using dot can take an extraordinary amount of time?18:56
kanavinyates, don't. It's a text file and totally human readable.18:56
yatesdot -Tpdf -o task-depends.pdf18:56
rfs613yates: yup, i gave up after hours and hours.18:56
LetoThe2ndyates: sures. anyone == everybody who ever treid, in that context.18:56
kanavinyates, if you have specific questions, it's better to quickly hack together a python script that massages the dot into the answer18:57
yatesah. well it appears i'm not alone..18:58
rfs613yates: i tried some of the suggestions on
kergothoe-depends-dot in oe-core is a better bet. or just grep. :)18:58
kergoththan rendering, that is18:59
LetoThe2ndkergoth: ag FTW18:59
kergothor rg, yeah :)18:59
LetoThe2ndkergoth: ripgrep?19:01
LetoThe2ndbecause of a specific reason? just curious?19:04
rfs613because rust, of course ;-P19:06
LetoThe2ndrfs613: thats the answer i expect(ed) in many cases, but not by kergoth :)19:06
*** goliath <goliath!> has joined #yocto19:07
kergothI originally switched for performance reasons, along with some of the options grep has, like -x19:08
kergothbut my dotfiles fall back to ag or even ack depending on what i've installed, they all get the job done19:09
LetoThe2ndkergoth: ah interesting.19:09
kergoth is pretty thorough19:09
renegadeany ideas on how i can use gpt instead of mbr?19:10
kergothi still like ack as a fallback as it can be built into a single portable script, nothing to install, so i keep a copy in the dotfiles19:10
LetoThe2ndkergoth: yeah19:10
ad__hi, what is proper way to modify a script that is part of a lower layer recipe "files://" that i can't touch ?19:11
rfs613yates, you might also be interested in 'bitbake -g --ui=taskexp TARGET'19:11
ecdheLetoThe2nd: maybe I do, maybe I don't19:20
*** psnsilva <psnsilva!~psnsilva@> has quit IRC19:21
ecdheLetoThe2nd: do you have some prior art for this kind of thing that I can poke through now that I understand better what I'm looking for?19:21
*** zkrx <zkrx!~slimshady@> has quit IRC19:21
*** lucaceresoli <lucaceresoli!~lucaceres@> has quit IRC19:21
ecdheLetoThe2nd: watching now19:28
ecdheSeems like build in a build is a weird way to describe this... if you build "grep" and you build an image that includes grep, then you have a build in a build19:29
ecdhebuilding a filesystem is building an object that comprises many other built objects19:30
LetoThe2ndecdhe: *shrug* you are free to call it whatever you deem more fitting. i will stick with build in build. just for the sake of the "yo dawg" meme, ofc19:31
yatesis linux-yocto/5.8.13+gitAUTOINC+b976de4f41_3c5d210805-r0 some sort of a code for dynamaic fetches?19:31
c4t3l_homeinception builds19:31
* LetoThe2nd must resist urge to make contraception pun19:32
yatesbaby builds19:32
yates(motivated by George Carlin's "Baby-Maybe" skit in the 70s)19:33
* c4t3l_home giggles and spills coffee19:33
yatesPapa-Stopper, "Embyr-NO" ...19:34
yatesok, i'll shutup now.19:34
LetoThe2ndwell we could call it "evil builds" and "mini me"s, for non-mc and mc builds?19:35
yatesfolks, i'm truly confused. i mean, more than usual.19:36
LetoThe2ndmission: accomplished.19:37
yatesthe motivating problem:
yatesLetoThe2nd: you are cruel19:38
yatesso i traced things as far as the line in run.do_kernel_metadata: bsp_definition=$(spp ${includes} --find -DKMACHINE=qemucsky -DKTYPE=standard)19:39
yatesi found ${includes} is "-I/edg/build-csky-toolchain/tmp/work/qemucsky-poky-linux/linux-yocto/5.8.13+gitAUTOINC+b976de4f41_3c5d210805-r0/kernel-meta"19:39
yatesi further found there are not ..kernel-meta/bsp folders for my board: qemucsky19:40
*** zkrx <zkrx!~slimshady@> has joined #yocto19:40
yateswhat i can't figure out is: where is this folder coming from?19:40
yatesi thought it may be from here, but it looks different:
LetoThe2ndyates: yoctoized kernels are.... special. i've never used those, i personally favor vanilla ones. you might want to read the kernel-dev-manual19:41
yateslike, a LOT different. different structgure.19:41
sakomanmatthewcroughan: see line 30 here:
yatesLetoThe2nd: are you saying the linux-yocto kernel is not based directly on a mainline kernel? pfft!!!!19:43
yatesok, i'm a dumbass...19:43
LetoThe2ndyates: based on? yes. equivalent? no.19:43
zeddii'er no, that's wrong.19:44
zeddiibut unfortunately, my day is done. no time to discuss. will be back tomorrow.19:44
yateszeddii: i'll pay your overtime!19:45
yatesname your price. (in Raymond Reddington style...)19:45
LetoThe2ndI'm wrong? Film at 11 ;-)19:45
yateshow cool is it that Daniel, from the original Stargate movie, is our Blacklist FBI CI?19:46
LetoThe2nd"more confused than usual"19:48
* LetoThe2nd also calls it a day. gn'819:49
renegadelooks like this will let me use gpt bootloader --ptable gpt19:56
*** rcoote <rcoote!~rcoote@2a02:908:692:81c0:84e7:69a1:ef6c:26e2> has quit IRC20:04
*** eduardas <eduardas!> has quit IRC20:14
*** psnsilva <psnsilva!~psnsilva@> has joined #yocto20:30
*** prabhakarlad <prabhakarlad!> has quit IRC20:32
*** manuel_ <manuel_!~manuel@2a02:1748:dd5c:f290:c553:9012:6082:a89a> has joined #yocto20:37
*** manuel1985 <manuel1985!~manuel198@2a02:1748:dd5c:f290:c5b2:fdff:b718:9edf> has joined #yocto20:47
matthewcroughansakoman: interesting.. so Yocto considers GCC reproducible?20:57
khemyates: what was question you had for me ?20:58
khemmatthewcroughan: most of package in oe-core are reprodcible20:58
matthewcroughanAnd GCC is in oe-core, yet Nix can't call it reproducible. I wonder what the difference is.20:59
matthewcroughanDoes Yocto consider "reproducible" to mean something different than what Nix means?20:59
khemmatthewcroughan: do you mean gcc package itself or the output of it ?21:00
matthewcroughanThe GCC binary.21:00
matthewcroughanThe output of the recipe.21:00
matthewcroughanNix can't reproduce it, because when GCC is compiled, it for some reason changes the entrypoint memory address in the ELF header. And therefore a few other things.21:01
khemyes,  its maked as reproducible, why does nix mark it not so21:01
matthewcroughanThere is supposed to be no diff, but there is.21:02
matthewcroughan"Each build is run twice, at different times, on different hardware running different kernels."21:02
matthewcroughanDoes the reproducible-build-results stuff run under that same scrutiny?21:06
matthewcroughan2 systems, 2 times, 2 kernels?21:06
*** manuel1985 <manuel1985!~manuel198@2a02:1748:dd5c:f290:c5b2:fdff:b718:9edf> has quit IRC21:10
*** psnsilva <psnsilva!~psnsilva@> has quit IRC21:11
*** manuel1985 <manuel1985!~manuel198@2a02:1748:dd5c:f290:b1d2:8f1d:3e46:b9a1> has joined #yocto21:14
*** aidanh <aidanh!~aidanh@unaffiliated/aidanh> has quit IRC21:18
yateshi khem21:18
rburtonmatthewcroughan: yes21:20
*** aidanh <aidanh!~aidanh@unaffiliated/aidanh> has joined #yocto21:22
yatesthe motivating problem:
yatesso i traced things as far as the line in run.do_kernel_metadata: bsp_definition=$(spp ${includes} --find -DKMACHINE=qemucsky -DKTYPE=standard)21:23
yatesi found ${includes} is "-I/edg/build-csky-toolchain/tmp/work/qemucsky-poky-linux/linux-yocto/5.8.13+gitAUTOINC+b976de4f41_3c5d210805-r0/kernel-meta"21:24
matthewcroughanrburton: how do I reproduce the results?21:24
yateswhat i can't figure out is: where is this folder coming from?21:24
rburtonmatthewcroughan: oe-selftest -r reproducible21:24
yateskhem: where is this folder coming from?21:25
yatesi thought it may be from here, but it looks different:
yatesmy guess is that there is no qemucsky folder under kernel-meta/bsp, hence the bitbake error.21:28
yatesi don't understand where the bsp folders that are there are coming from.21:28
yateswhat does the encoding "5.8.13+gitAUTOINC+b976de4f41_3c5d210805-r0" mean?21:31
*** psnsilva <psnsilva!~psnsilva@> has joined #yocto21:37
yateskhem: ?21:38
*** c4t3l_home <c4t3l_home!~rcallicot@> has quit IRC21:53
*** nslu2-log <nslu2-log!> has quit IRC22:05
*** nslu2-log <nslu2-log!> has joined #yocto22:07
*** bps <bps!~bps@> has joined #yocto22:15
*** argonautx <argonautx!> has quit IRC22:18
*** goliath <goliath!> has quit IRC22:19
*** renegade <renegade!~renegade@2601:241:8a00:46e0:649a:6fcd:d26a:d56b> has quit IRC22:23

Generated by 2.17.2 by Marius Gedminas - find it at!