*** M4x4dib <M4x4dib!~m4x4dib@2601:2c3:c100:fa50:b98e:8ad6:391c:584f> has joined #yocto | 00:42 | |
*** meow` <meow`!~sbourdeli@88.164.199.67> has quit IRC | 00:52 | |
*** extorr <extorr!extor@unaffiliated/extor> has joined #yocto | 01:14 | |
*** ByteLawd <ByteLawd!extor@unaffiliated/extor> has quit IRC | 01:15 | |
*** csd <csd!~csd@78.80.197.35.bc.googleusercontent.com> has quit IRC | 01:16 | |
*** jaeckel <jaeckel!~jaeckel@unaffiliated/jaeckel> has quit IRC | 01:18 | |
*** csd <csd!~csd@78.80.197.35.bc.googleusercontent.com> has joined #yocto | 01:24 | |
*** kpo <kpo!~kpo@gl127-35.master.pl> has quit IRC | 01:25 | |
*** gpanders <gpanders!~gpanders@c-73-26-133-58.hsd1.nm.comcast.net> has quit IRC | 01:30 | |
*** gpanders <gpanders!~gpanders@c-73-26-133-58.hsd1.nm.comcast.net> has joined #yocto | 01:30 | |
*** jaeckel <jaeckel!~jaeckel@sleipnir.jaeckel.eu> has joined #yocto | 01:30 | |
*** tperrot_ <tperrot_!~tprrt@shells.bootlin.com> has joined #yocto | 01:47 | |
*** gpanders <gpanders!~gpanders@c-73-26-133-58.hsd1.nm.comcast.net> has quit IRC | 01:47 | |
*** gpanders <gpanders!~gpanders@c-73-26-133-58.hsd1.nm.comcast.net> has joined #yocto | 01:48 | |
*** gnac <gnac!~gnac@172.56.42.225> has quit IRC | 01:52 | |
*** dmoseley <dmoseley!~dmoseley@24.96.56.90> has quit IRC | 01:52 | |
*** SWAT <SWAT!~swat@ubuntu/member/swat> has quit IRC | 01:52 | |
*** R0b0t1 <R0b0t1!~R0b0t1@unaffiliated/r0b0t1> has quit IRC | 01:52 | |
*** tlwoerner <tlwoerner!~tlwoerner@unaffiliated/tlwoerner> has quit IRC | 01:52 | |
*** darknighte <darknighte!sid214177@pdpc/supporter/professional/darknighte> has quit IRC | 01:52 | |
*** alex88 <alex88!~alex88@unaffiliated/alex88> has quit IRC | 01:52 | |
*** tperrot <tperrot!~tprrt@shells.bootlin.com> has quit IRC | 01:52 | |
*** alejandrohs <alejandrohs!~alejandro@cpe-68-201-52-49.elp.res.rr.com> has quit IRC | 01:52 | |
*** chrysh_ <chrysh_!~chrysh@someserver.de> has quit IRC | 01:52 | |
*** marble_visions <marble_visions!~user@68.183.79.8> has quit IRC | 01:52 | |
*** lpoulain <lpoulain!lpoulain@gateway/shell/linaro/x-ntjhrxrunvsizaqc> has quit IRC | 01:52 | |
*** rfs613 <rfs613!~rfs613@rfs.netwinder.org> has quit IRC | 01:52 | |
*** rr123 <rr123!~xxiao@159.89.184.51> has quit IRC | 01:52 | |
*** ka6sox <ka6sox!~ka6sox@nasadmin/ka6sox> has quit IRC | 01:52 | |
*** yocton <yocton!~quassel@51.15.170.227> has quit IRC | 01:52 | |
*** champagneg <champagneg!~gchamp@ipagstaticip-d73c7528-4de5-0861-800b-03d8b15e3869.sdsl.bell.ca> has quit IRC | 01:52 | |
*** minimaxwell <minimaxwell!~minimaxwe@204.ip-51-254-215.eu> has quit IRC | 01:52 | |
*** gnac <gnac!~gnac@172.56.42.225> has joined #yocto | 01:53 | |
*** dmoseley <dmoseley!~dmoseley@24.96.56.90> has joined #yocto | 01:53 | |
*** SWAT <SWAT!~swat@ubuntu/member/swat> has joined #yocto | 01:53 | |
*** R0b0t1 <R0b0t1!~R0b0t1@unaffiliated/r0b0t1> has joined #yocto | 01:53 | |
*** tlwoerner <tlwoerner!~tlwoerner@unaffiliated/tlwoerner> has joined #yocto | 01:53 | |
*** darknighte <darknighte!sid214177@pdpc/supporter/professional/darknighte> has joined #yocto | 01:53 | |
*** alex88 <alex88!~alex88@unaffiliated/alex88> has joined #yocto | 01:53 | |
*** alejandrohs <alejandrohs!~alejandro@cpe-68-201-52-49.elp.res.rr.com> has joined #yocto | 01:53 | |
*** chrysh_ <chrysh_!~chrysh@someserver.de> has joined #yocto | 01:53 | |
*** marble_visions <marble_visions!~user@68.183.79.8> has joined #yocto | 01:53 | |
*** lpoulain <lpoulain!lpoulain@gateway/shell/linaro/x-ntjhrxrunvsizaqc> has joined #yocto | 01:53 | |
*** rfs613 <rfs613!~rfs613@rfs.netwinder.org> has joined #yocto | 01:53 | |
*** rr123 <rr123!~xxiao@159.89.184.51> has joined #yocto | 01:53 | |
*** ka6sox <ka6sox!~ka6sox@nasadmin/ka6sox> has joined #yocto | 01:53 | |
*** yocton <yocton!~quassel@51.15.170.227> has joined #yocto | 01:53 | |
*** champagneg <champagneg!~gchamp@ipagstaticip-d73c7528-4de5-0861-800b-03d8b15e3869.sdsl.bell.ca> has joined #yocto | 01:53 | |
*** M4x4dib <M4x4dib!~m4x4dib@2601:2c3:c100:fa50:b98e:8ad6:391c:584f> has quit IRC | 01:55 | |
*** minimaxwell <minimaxwell!~minimaxwe@204.ip-51-254-215.eu> has joined #yocto | 01:58 | |
*** kaspter <kaspter!~Instantbi@58.246.136.202> has joined #yocto | 01:58 | |
*** gpanders <gpanders!~gpanders@c-73-26-133-58.hsd1.nm.comcast.net> has quit IRC | 01:58 | |
*** gpanders <gpanders!~gpanders@c-73-26-133-58.hsd1.nm.comcast.net> has joined #yocto | 01:59 | |
*** gpanders <gpanders!~gpanders@c-73-26-133-58.hsd1.nm.comcast.net> has quit IRC | 02:00 | |
*** gpanders <gpanders!~gpanders@c-73-26-133-58.hsd1.nm.comcast.net> has joined #yocto | 02:01 | |
*** sakoman <sakoman!~steve@72.173.249.164> has quit IRC | 02:16 | |
*** M4x4dib <M4x4dib!~m4x4dib@2601:2c3:c100:fa50:b98e:8ad6:391c:584f> has joined #yocto | 02:33 | |
*** M4x4dib <M4x4dib!~m4x4dib@2601:2c3:c100:fa50:b98e:8ad6:391c:584f> has quit IRC | 02:38 | |
*** kaspter <kaspter!~Instantbi@58.246.136.202> has quit IRC | 02:46 | |
*** kaspter <kaspter!~Instantbi@58.246.136.202> has joined #yocto | 02:46 | |
*** georgem_home <georgem_home!uid210681@gateway/web/irccloud.com/x-hqhfodvgztwgvkbn> has quit IRC | 03:03 | |
*** linums <linums!~linums@catv-80-99-160-36.catv.broadband.hu> has quit IRC | 03:14 | |
*** NiksDev <NiksDev!~NiksDev@192.91.101.31> has quit IRC | 03:16 | |
*** mrc3 <mrc3!~mrc3@linaro/mrc3> has quit IRC | 03:42 | |
*** linums <linums!~linums@catv-80-99-160-36.catv.broadband.hu> has joined #yocto | 03:46 | |
*** roussinm <roussinm!~mroussin@bras-base-qubcpq0336w-grc-47-76-71-204-197.dsl.bell.ca> has quit IRC | 03:54 | |
*** mrc3 <mrc3!~mrc3@linaro/mrc3> has joined #yocto | 03:55 | |
*** Spooster <Spooster!~Spooster@c-68-61-72-182.hsd1.mi.comcast.net> has quit IRC | 04:51 | |
*** arpa <arpa!4e1b400a@78-27-64-10.bb.dnainternet.fi> has joined #yocto | 05:06 | |
*** jobroe <jobroe!~manjaro-u@p579eb790.dip0.t-ipconnect.de> has joined #yocto | 05:17 | |
*** AndersD <AndersD!~AndersD@h83-209-96-136.cust.a3fiber.se> has joined #yocto | 05:42 | |
*** arpa <arpa!4e1b400a@78-27-64-10.bb.dnainternet.fi> has quit IRC | 05:44 | |
*** AndersD_ <AndersD_!~AndersD@h-17-226.A137.corp.bahnhof.se> has joined #yocto | 05:45 | |
*** AndersD <AndersD!~AndersD@h83-209-96-136.cust.a3fiber.se> has quit IRC | 05:47 | |
*** rob_w <rob_w!~rob@unaffiliated/rob-w/x-1112029> has joined #yocto | 06:00 | |
*** camus <camus!~Instantbi@58.246.136.202> has joined #yocto | 06:02 | |
*** kaspter <kaspter!~Instantbi@58.246.136.202> has quit IRC | 06:02 | |
*** camus is now known as kaspter | 06:03 | |
*** RobertBerger <RobertBerger!~rber@ppp-2-86-155-249.home.otenet.gr> has joined #yocto | 06:04 | |
*** arpa <arpa!d98c63fb@217.140.99.251> has joined #yocto | 06:19 | |
*** agust <agust!~agust@pd95f1cdf.dip0.t-ipconnect.de> has joined #yocto | 06:19 | |
*** arpa <arpa!d98c63fb@217.140.99.251> has quit IRC | 06:19 | |
*** frsc <frsc!~frsc@i59F4B42A.versanet.de> has joined #yocto | 06:23 | |
*** kaspter <kaspter!~Instantbi@58.246.136.202> has quit IRC | 06:23 | |
*** kaspter <kaspter!~Instantbi@58.246.136.202> has joined #yocto | 06:24 | |
*** manuel1985 <manuel1985!~manuel198@2a02:1748:dd5c:f290:2159:8592:80e6:8802> has quit IRC | 06:32 | |
*** mckoan|away is now known as mckoan | 06:40 | |
*** fl0v0 <fl0v0!~fvo@89.244.127.215> has joined #yocto | 06:56 | |
*** extorr <extorr!extor@unaffiliated/extor> has quit IRC | 06:59 | |
*** extorr <extorr!extor@unaffiliated/extor> has joined #yocto | 07:00 | |
RobertBerger | Hi | 07:04 |
---|---|---|
RobertBerger | Any devtool experts here? | 07:04 |
*** tnovotny <tnovotny!~tnovotny@ip4-83-240-26-162.cust.nbox.cz> has joined #yocto | 07:22 | |
*** yannholo <yannholo!~yannholo@fs-141-0-205-41.fullsave.info> has joined #yocto | 07:25 | |
*** manuel1985 <manuel1985!~manuel198@62.99.131.178> has joined #yocto | 07:28 | |
*** jobroe_ <jobroe_!~manjaro-u@p579eb00b.dip0.t-ipconnect.de> has joined #yocto | 07:29 | |
*** jobroe <jobroe!~manjaro-u@p579eb790.dip0.t-ipconnect.de> has quit IRC | 07:30 | |
mcfrisk | gah, 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 |
RP | abelloni: Looks like a "fun" build for SWAT :(. I triaged a couple of bits | 07:36 |
RP | mcfrisk: One will look at every recipe in the taskgraph and then run the task whether it would have run in the original command or not | 07:37 |
RP | mcfrisk: the other will run the specified task on if it was in the original task graph | 07:38 |
RP | s/on/only/ | 07:38 |
RP | mcfrisk: so I think you'd want --runonly | 07:39 |
mcfrisk | RP: 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 |
RP | mcfrisk: oh, sorry, I misunderstood. It will run them all since there is no sstate associated with the task | 07:42 |
RP | mcfrisk: we don't have a way to do what you describe, that isn't an easy thing to express/discover :/ | 07:44 |
*** mbulut <mbulut!~nameclash@ip1f121f26.dynamic.kabel-deutschland.de> has joined #yocto | 07:45 | |
mcfrisk | RP: 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 |
RP | mcfrisk: 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 not | 07:51 |
*** prabhakarlad <prabhakarlad!c18ddb18@pc.renesas.eu> has joined #yocto | 07:52 | |
mcfrisk | and 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 recompiled | 07:52 |
RP | mcfrisk: I'm surprised as the fetch tasks should see the sources already present and run quckly | 07:52 |
RP | mcfrisk: we do that on the autobuilders for example https://autobuilder.yoctoproject.org/typhoon/#/builders/83/builds/2117 step 14 which took about 60s | 07:54 |
RP | abelloni: I triaged one of the a-full builds, there is a second which probably can have some of the entries copied over | 07:57 |
mcfrisk | RP: does that have a local download pre-mirror? | 07:57 |
RP | mcfrisk: yes, it isn't from scratch | 07:58 |
mcfrisk | RP: 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_!~richbridg@213-225-10-171.nat.highway.a1.net> has quit IRC | 08:06 | |
*** aquijoule_ <aquijoule_!~richbridg@213-225-10-171.nat.highway.a1.net> has joined #yocto | 08:06 | |
abelloni | RP: ah right, I was looking at the qemux86-64-ptest failure of that build | 08:07 |
*** psnsilva <psnsilva!~psnsilva@161.230.35.203> has joined #yocto | 08:12 | |
*** Bunio_FH <Bunio_FH!~bunio@81-18-201-214.static.chello.pl> has quit IRC | 08:13 | |
*** Bunio_FH <Bunio_FH!~bunio@81-18-201-214.static.chello.pl> has joined #yocto | 08:17 | |
RP | abelloni: there are a ton of issues there, I've tried to help a bit... | 08:20 |
abelloni | yes, I'm very late triage, I'm on it right now | 08:20 |
abelloni | triaging | 08:20 |
RP | abelloni: I was meaning in that build. Would be good to be up to date before triage today though | 08:27 |
*** M4x4dib <M4x4dib!~m4x4dib@2601:2c3:c100:fa50:b98e:8ad6:391c:584f> has joined #yocto | 08:32 | |
*** kaspter <kaspter!~Instantbi@58.246.136.202> has quit IRC | 08:33 | |
*** kaspter <kaspter!~Instantbi@58.246.136.202> has joined #yocto | 08:33 | |
*** camus <camus!~Instantbi@58.246.136.202> has joined #yocto | 08:36 | |
*** kaspter <kaspter!~Instantbi@58.246.136.202> has quit IRC | 08:37 | |
*** camus is now known as kaspter | 08:37 | |
*** thekappe <thekappe!c65a42b1@198.90.66.177> has joined #yocto | 08:43 | |
thekappe | "Hello world !" [cit.] | 08:44 |
thekappe | Doeas anyone ever worked with the "stateless-rootfs" FEATURE ? | 08:44 |
*** goliath <goliath!~goliath@clnet-p04-043.ikbnet.co.at> has joined #yocto | 09:02 | |
rburton | mcfrisk: runall=fetch will *definitely* only fetch what is missing from DL_DIR, so you've got problems with that persisting between builds | 09:03 |
rburton | zeddii: should meta-virt work with gcc11? | 09:07 |
mcfrisk | rburton 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 |
mcfrisk | a lot of do_fetch taks do get executed and that put me off to wrong path. will check the timings instead. | 09:31 |
rburton | iirc they run but do nothing as the files exist | 09:31 |
mcfrisk | yep, and seem to be fast. I can even increase parallel options as fetching isn't memory limited like real compilation | 09:32 |
*** M4x4dib <M4x4dib!~m4x4dib@2601:2c3:c100:fa50:b98e:8ad6:391c:584f> has quit IRC | 09:34 | |
*** Lihis <Lihis!~Lihis@ns3006753.ip-151-80-42.eu> has quit IRC | 09:40 | |
*** Lihis <Lihis!~Lihis@ns3006753.ip-151-80-42.eu> has joined #yocto | 09:41 | |
RP | abelloni: looks like there is a git config setup issue on fedora33 | 09:42 |
thekappe | guys, If I need to port systemd vXXXX >243 to thud which has v239, Which can be a good strategy ? | 10:54 |
rburton | stop using thud | 10:59 |
rburton | to backport, copy the recipes and verify the output carefully | 11:00 |
thekappe | I really can't at the moment | 11:02 |
thekappe | I've already tried to copy the recipes but it's no so straightforward | 11:02 |
rburton | No, it's not | 11:02 |
thekappe | yap, I've noticed | 11:03 |
rburton | You'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 |
thekappe | damn | 11:04 |
rburton | If 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 recipes | 11:06 |
*** JaBen <JaBen!Thunderbir@gateway/vpn/mullvad/jaben> has joined #yocto | 11:08 | |
thekappe | I am the support | 11:10 |
thekappe | the developer | 11:10 |
thekappe | and the tester | 11:10 |
thekappe | the repo mainter and the issue tracker | 11:11 |
thekappe | I maybe be a little short of workforce at the moment | 11:11 |
RP | kanavin: 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 IRC | 11:15 | |
*** meow` <meow`!~sbourdeli@88.164.199.67> has joined #yocto | 11:16 | |
*** freanux <freanux!~freanux@unaffiliated/freanux> has joined #yocto | 11:26 | |
*** prabhakarlad <prabhakarlad!c18ddb18@pc.renesas.eu> has quit IRC | 11:30 | |
*** georgem_home <georgem_home!uid210681@gateway/web/irccloud.com/x-cgoetttuuzspyhfa> has joined #yocto | 11:50 | |
*** yannholo <yannholo!~yannholo@fs-141-0-205-41.fullsave.info> has quit IRC | 11:52 | |
*** thekappe <thekappe!c65a42b1@198.90.66.177> has quit IRC | 11:56 | |
*** camus <camus!~Instantbi@58.246.136.202> has joined #yocto | 12:09 | |
*** kaspter <kaspter!~Instantbi@58.246.136.202> has quit IRC | 12:11 | |
*** camus is now known as kaspter | 12:11 | |
kanavin | RP: so far, there's actually nothing that would warrant a second iteration :) | 12:13 |
*** jobroe_ <jobroe_!~manjaro-u@p579eb00b.dip0.t-ipconnect.de> has quit IRC | 12:14 | |
*** prabhakarlad <prabhakarlad!c18ddb18@pc.renesas.eu> has joined #yocto | 12:15 | |
zeddii | rburton: I'm working on gcc11 support in meta-virt now. uprevs and such to fix issues. | 12:16 |
*** linums <linums!~linums@catv-80-99-160-36.catv.broadband.hu> has quit IRC | 12:19 | |
*** linums <linums!~linums@catv-80-99-160-36.catv.broadband.hu> has joined #yocto | 12:21 | |
*** rcoote <rcoote!~rcoote@2a02:908:692:81c0:71ec:66db:4b21:cbe2> has joined #yocto | 12:33 | |
*** ahalaney <ahalaney!~ahalaney@068-184-200-203.res.spectrum.com> has joined #yocto | 12:35 | |
*** rcoote <rcoote!~rcoote@2a02:908:692:81c0:71ec:66db:4b21:cbe2> has quit IRC | 12:41 | |
*** argonautx <argonautx!~argonautx@i59F77FC4.versanet.de> has joined #yocto | 12:41 | |
*** eFfeM1 <eFfeM1!b9b86d22@185.184.109.34> has joined #yocto | 12:44 | |
eFfeM1 | Hi, we want ot use an sstate dir shared between multiple users, but somehow every once in a while we get messages like this one | 12:45 |
eFfeM1 | Exception: 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 |
eFfeM1 | mktemp: 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 denied | 12:45 |
*** caiortp <caiortp!~caiortp@92-108-245-63.cable.dynamic.v4.ziggo.nl> has joined #yocto | 12:45 | |
eFfeM1 | The 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 |
eFfeM1 | the sstate dir is on the same system | 12:46 |
mckoan | eFfeM1: sstate dir shared between multiple users doesn't work AFAIK | 12:47 |
RP | kanavin: I saw quite a bit of discussion. I'm not sure I agree with just removing that expat change for example :/ | 12:47 |
RP | mckoan: it should | 12:49 |
*** paulg <paulg!~paulg@104-195-159-20.cpe.teksavvy.com> has quit IRC | 12:50 | |
RP | eFfeM1: It shouldn't be using XXXXXXX directly but replacing that with a tmp file mask :/ | 12:50 |
eFfeM1 | mckoan I found references that it should, even with NFS on an NFS dir | 12:50 |
eFfeM1 | RP, ahhh | 12:50 |
RP | the autobuilder does exactly that | 12:50 |
*** rcoote <rcoote!~rcoote@2a02:908:692:81c0:84e7:69a1:ef6c:26e2> has joined #yocto | 12:51 | |
*** Spooster <Spooster!~Spooster@c-68-61-72-182.hsd1.mi.comcast.net> has joined #yocto | 12:51 | |
kanavin | RP: I looked into expat, and wrote a followup | 12:51 |
eFfeM1 | still struggling with another issue at the moment but that at least gives a hint on where to look | 12:51 |
kanavin | RP: expat ptests were never enabled in the first place | 12:51 |
RP | zeddii: I had wondered if that was what you'd done :) | 12:51 |
RP | zeddii: I do hate it when your own sanity tests complain about your sanity :/ | 12:52 |
qschulz | eFfeM1: 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!~caiortp@92-108-245-63.cable.dynamic.v4.ziggo.nl> has quit IRC | 12:52 | |
kanavin | RP: the rest was Khem indulging in bike-shedding to be honest which he does sometimes :-/ | 12:52 |
qschulz | if 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 package | 12:53 |
eFfeM1 | qschulz yes cleansstate would be a pain | 12:53 |
qschulz | eFfeM1: 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 webservers | 12:54 |
RP | kanavin: well, there were questions which needed answering in some areas | 12:54 |
RP | qschulz: we use atomic renames to avoid that | 12:54 |
kanavin | RP: I guess you should hold off the items that prompted a discussion, but I still don't see what I could do about them realistically | 12:55 |
kanavin | RP: 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 was | 12:57 |
*** ayoung <ayoung!~ayoung@2601:19c:4680:ee30:b6cc:8682:e628:1585> has joined #yocto | 12:57 | |
RP | kanavin: I was going to look at just pulling some and that started worrying about patch inter-dependencies | 12:57 |
eFfeM1 | qschulz 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 |
eFfeM1 | meanwhile I peeked into sstate_create_package and it has | 12:58 |
eFfeM1 | TFILE=`mktemp ${SSTATE_PKG}.XXXXXXXX` | 12:58 |
RP | eFfeM1: but mktemp is supposed to replace that, its a pattern | 12:59 |
eFfeM1 | and the system has a good mktemp, so the filename is a indeed odd | 12:59 |
eFfeM1 | RP, I know | 12:59 |
eFfeM1 | so this is very strange | 12:59 |
RP | eFfeM1: I wonder if pseudo is breaking things somehow | 12:59 |
eFfeM1 | pff, that is an area I did not venture in before | 13:00 |
*** geheimnis` <geheimnis`!~geheimnis@23.226.237.192> has quit IRC | 13:00 | |
eFfeM1 | but I can try to add some debugging code; after my current job finishes | 13:00 |
kanavin | RP: 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 |
qschulz | eFfeM1: except if all your users have a webserver, in which case, they all sync their sstate-cache when a sstate-cache entry is needed | 13:02 |
* alephan < https://matrix.org/_matrix/media/r0/download/matrix.org/RVjoYWaGxlzCYbGoyKegFJhl/message.txt > | 13:02 | |
*** paulg <paulg!~paulg@104-195-159-20.cpe.teksavvy.com> has joined #yocto | 13:03 | |
eFfeM1 | qschulz that is an interesting idea | 13:07 |
eFfeM1 | for now I found another clash, this one does not have the XXXXX pattern in the name | 13:07 |
eFfeM1 | ./c8/97/sstate:qtwebsockets:aarch64-sorama-linux:5.15.3+gitAUTOINC+43f9a2dbf9:r0:aarch64:3:c897b6b269a45a33e78a40993b40e8e5902a7af6df075e7189fad549a8e5ae26_deploy_source_date_epoch.tgz | 13:08 |
*** geheimnis` <geheimnis`!~geheimnis@23.226.237.192> has joined #yocto | 13:10 | |
*** armpit <armpit!~armpit@2601:202:4180:a5c0:8589:f92a:54a1:6475> has quit IRC | 13:10 | |
kanavin | RP: I can write better commit messages to those items which caused discussions, but there's nothing to actually change in those patches | 13:12 |
*** armpit <armpit!~armpit@2601:202:4180:a5c0:899e:2fa0:8320:d89b> has joined #yocto | 13:13 | |
*** dev1990_ <dev1990_!~dev@217.96.227.206.ipv4.supernova.orange.pl> has quit IRC | 13:14 | |
*** dev1990 <dev1990!~dev@217.96.227.206.ipv4.supernova.orange.pl> has joined #yocto | 13:15 | |
*** zkrx <zkrx!~slimshady@194.230.138.56> has quit IRC | 13:15 | |
qschulz | alephan: 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 answer | 13:19 |
qschulz | (I think it's usually because of formatting or messages being too long | 13:19 |
alephan | qschulz: exactly I'll repost | 13:19 |
*** M4x4dib <M4x4dib!~m4x4dib@2601:2c3:c100:fa50::e272> has joined #yocto | 13:19 | |
alephan | Thanks a lot | 13:19 |
*** paulg <paulg!~paulg@104-195-159-20.cpe.teksavvy.com> has quit IRC | 13:21 | |
alephan | There 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 |
alephan | runqemu - ERROR - Native sysroot directory [...]/build/tmp-newlib/work/x86_64-linux/qemu-helper-native/1.0-r1/recipe-sysroot-native/usr/bin doesn't exist | 13:23 |
alephan | See https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/scripts/runqemu#n1548 | 13:23 |
alephan | I'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 IRC | 13:25 | |
*** stwcx <stwcx!~stwcx@194.233.100.113> has joined #yocto | 13:28 | |
*** boo <boo!021955e8@2.25.85.232> has joined #yocto | 13:29 | |
alephan | qschulz: did this ^ do the trick? | 13:29 |
RP | kanavin: if you could tweak the messages I think that would help | 13:29 |
RP | kanavin: can we figure out whether there are ptests not listed in fast/slow ? | 13:32 |
*** zkrx <zkrx!~slimshady@194.230.138.56> has joined #yocto | 13:32 | |
zeddii | alejandrohs: do you ever use WSL2, or just an observer on the state of things ? | 13:33 |
*** ahalaney <ahalaney!~ahalaney@068-184-200-203.res.spectrum.com> has quit IRC | 13:33 | |
*** c4t3l_home <c4t3l_home!~rcallicot@139.138.156.11> has joined #yocto | 13:33 | |
*** ajhalaney <ajhalaney!~ahalaney@068-184-200-203.res.spectrum.com> has joined #yocto | 13:33 | |
*** dev1990 <dev1990!~dev@217.96.227.206.ipv4.supernova.orange.pl> has quit IRC | 13:33 | |
*** dev1990 <dev1990!~dev@217.96.227.206.ipv4.supernova.orange.pl> has joined #yocto | 13:34 | |
RP | kanavin: I did notice the cruft in puzzles recipe does actually do something but I'm going to ignore it | 13:34 |
RP | kanavin: I never agreed with it in the first place, rburton probably would argue for it :) | 13:34 |
*** paulg <paulg!~paulg@104-195-159-20.cpe.teksavvy.com> has joined #yocto | 13:34 | |
eFfeM1 | zeddii 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 system | 13:35 |
*** ecdhe_ <ecdhe_!~ecdhe@unaffiliated/ecdhe> has joined #yocto | 13:35 | |
eFfeM1 | suspect 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 system | 13:36 |
zeddii | heh. 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 |
zeddii | but they've messed up the networking so badly, that I was looking to throw scorn at someone :D | 13:38 |
*** ecdhe <ecdhe!~ecdhe@unaffiliated/ecdhe> has quit IRC | 13:38 | |
qschulz | alephan: it did, fingers crossed it'll get people to asnwer it now :) | 13:48 |
*** c4t3l_home <c4t3l_home!~rcallicot@139.138.156.11> has quit IRC | 13:49 | |
*** c4t3l_home <c4t3l_home!~rcallicot@139.138.156.11> has joined #yocto | 13:50 | |
*** kaspter <kaspter!~Instantbi@58.246.136.202> has quit IRC | 13:50 | |
*** kaspter <kaspter!~Instantbi@58.246.136.202> has joined #yocto | 13:50 | |
alephan | Cheers! | 13:54 |
*** eduardas <eduardas!~eduardas@82-135-139-249.static.zebra.lt> has joined #yocto | 13:55 | |
*** sakoman <sakoman!~steve@172.243.4.16> has joined #yocto | 13:57 | |
*** psnsilva <psnsilva!~psnsilva@161.230.35.203> has quit IRC | 13:59 | |
*** psnsilva <psnsilva!~psnsilva@161.230.35.203> has joined #yocto | 13:59 | |
*** lucaceresoli <lucaceresoli!~lucaceres@77.244.183.192> has joined #yocto | 14:04 | |
*** kaspter <kaspter!~Instantbi@58.246.136.202> has quit IRC | 14:04 | |
RP | alephan: I think the key question is what you're running before calling runqemu | 14:16 |
RP | and whether we'd expect that to restore the helper | 14:16 |
alephan | RP: that is a good point. And I think that gives me the answer to the problem | 14:17 |
alephan | I'm building a zephyr application. | 14:17 |
RP | alephan: meta/conf/machine/include/qemu.inc:EXTRA_IMAGEDEPENDS += "qemu-system-native qemu-helper-native" | 14:19 |
RP | alephan: that is how we do it with core | 14:19 |
alephan | Exactly. | 14:19 |
alephan | In zephyr that is done with a `DEPENDS_append_qemuall` in the recipe | 14:20 |
rburton | zeddii: found fedora has a patch to fix xen-tools | 14:21 |
rburton | hm, fetch failing with do_unpack: Unpack failure for URL: 'git://git.yoctoproject.org/yocto-kernel-cache;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/git.yoctoproject.org.yocto-kernel-cache; shallow clone not enabled | 14:21 |
*** paulg <paulg!~paulg@104-195-159-20.cpe.teksavvy.com> has quit IRC | 14:21 | |
zeddii | rburton: aha. nice. We were just going to mask it, but that works better. | 14:23 |
*** kpo_ <kpo_!~kpo@bwu34.internetdsl.tpnet.pl> has quit IRC | 14:23 | |
zeddii | I don't think I did anything odd with the kernel-cache repo that would have caused that 2nd thing though. | 14:24 |
*** kpo_ <kpo_!~kpo@bwu34.internetdsl.tpnet.pl> has joined #yocto | 14:24 | |
alephan | RP: 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 |
alephan | So even if the dependency is fine, it won't bring in the bindir of native sysroot for the wrapper's recipe | 14:25 |
alephan | There is another dependency that makes that explicit somewhere | 14:25 |
RP | alephan: 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 testimage | 14:25 |
alephan | That's it! | 14:26 |
*** prabhakarlad <prabhakarlad!c18ddb18@pc.renesas.eu> has quit IRC | 14:26 | |
alephan | But that is only for a testimage | 14:26 |
alephan | How come it doesn't fail on normal images in the core? | 14:26 |
rburton | zeddii: https://src.fedoraproject.org/rpms/xen/blob/rawhide/f/xen.gcc11.fixes.patch is the fedora one. no idea if its 'right' or being upstreamed. | 14:26 |
RP | alephan: I'm not quite sure, I'd have assumed it was the EXTRA_IMAGEDEPENDS | 14:27 |
alephan | I'll dig a bit. Thanks for the hints. | 14:28 |
RP | dl9pf, smurray: https://autobuilder.yoctoproject.org/typhoon/#/builders/121/builds/41/steps/11/logs/stdio ? :/ | 14:29 |
RP | new lua dependency? | 14:29 |
*** bps <bps!~bps@27-reverse.bang-olufsen.dk> has quit IRC | 14:30 | |
smurray | RP: yeah, I rebased the meta-agl next branch which picked up the new wireplumber recipe, it now has a Lua dependency | 14:31 |
smurray | RP: my apologies, I forgot that all layers are getting tested in meta-agl now, was only testing meta-agl-core | 14:32 |
*** paulg <paulg!~paulg@104-195-159-20.cpe.teksavvy.com> has joined #yocto | 14:36 | |
*** prabhakarlad <prabhakarlad!c18ddb18@pc.renesas.eu> has joined #yocto | 14:37 | |
*** ecdhe_ is now known as ecdhe | 14:39 | |
*** eFfeM1 <eFfeM1!b9b86d22@185.184.109.34> has quit IRC | 14:39 | |
*** paulg <paulg!~paulg@104-195-159-20.cpe.teksavvy.com> has quit IRC | 14:41 | |
*** drofty <drofty!~drofty@103.127.23.213> has joined #yocto | 14:42 | |
drofty | ERROR: Task (/home/drofty/yocto/poky/meta/recipes-core/glibc/glibc_2.31.bb:do_unpack) failed with exit code '1' | 14:43 |
drofty | HOW TO SOLVE THIS PLS HELP | 14:43 |
*** meow` <meow`!~sbourdeli@88.164.199.67> has quit IRC | 14:43 | |
*** meow` <meow`!~sbourdeli@88.164.199.67> has joined #yocto | 14:44 | |
*** linums <linums!~linums@catv-80-99-160-36.catv.broadband.hu> has quit IRC | 14:45 | |
v2d | moto-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 setup.py as usual? (setuptools extension really just add new variables to their setup.py) | 14:46 |
*** yannholo <yannholo!~yannholo@fs-141-0-205-41.fullsave.info> has joined #yocto | 14:48 | |
qschulz | drofty: 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 |
v2d | s/add/expect/ | 14:49 |
smurray | RP: meta-oe is added as a dependency, any ideas on why that's not enough to get lua? | 14:50 |
*** dev1990_ <dev1990_!~dev@217.96.227.206.ipv4.supernova.orange.pl> has joined #yocto | 14:51 | |
*** dev1990 <dev1990!~dev@217.96.227.206.ipv4.supernova.orange.pl> has quit IRC | 14:52 | |
drofty | hey qschulz https://pastebin.com/BA63gvjZ here is the log .. should i delete this and run bitbake again ? /home/drofty/yocto/poky/build/downloads/git2/sourceware.org.git.glibc.git | 14:53 |
drofty | this file | 14:53 |
*** linums <linums!~linums@catv-80-99-160-36.catv.broadband.hu> has joined #yocto | 14:53 | |
drofty | i have 100mbps internet still files are getting downloaded at 250KBps ._. any way to increase the speed? | 14:54 |
*** paulg <paulg!~paulg@104-195-159-20.cpe.teksavvy.com> has joined #yocto | 14:54 | |
*** yannholo <yannholo!~yannholo@fs-141-0-205-41.fullsave.info> has quit IRC | 14:56 | |
*** AndersD_ <AndersD_!~AndersD@h-17-226.A137.corp.bahnhof.se> has quit IRC | 14:59 | |
*** bps <bps!~bps@80.71.142.18> has joined #yocto | 15:00 | |
*** tnovotny <tnovotny!~tnovotny@ip4-83-240-26-162.cust.nbox.cz> has quit IRC | 15:03 | |
*** sbach <sbach!~sbachmatr@192.184.90.156> has quit IRC | 15:20 | |
*** sbach <sbach!~sbachmatr@192.184.90.156> has joined #yocto | 15:20 | |
*** Nithesh <Nithesh!a5e17a9a@165.225.122.154> has joined #yocto | 15:20 | |
Nithesh | Hi | 15:20 |
Nithesh | PACKAGECONFIG[gtk] = "--with-gtk3,--without-gtk3,gtk+3" | 15:20 |
Nithesh | what does this line mean | 15:21 |
Nithesh | qschulz | 15:21 |
JPEW | Nithesh: https://docs.yoctoproject.org/ref-manual/variables.html?#term-PACKAGECONFIG | 15:22 |
Nithesh | JPEW i couldn't understand there | 15:23 |
Nithesh | how is gtk disabled here | 15:23 |
JPEW | Nithesh: Bascially, if "gtk" is in "PACAKGECONFIG" it's enabled, otherwise it is disabled | 15:24 |
Nithesh | then how --without-gtk3 work | 15:25 |
JPEW | If "gtk3" is *not* in PACAKGECONFIG, that gets added to the configure arguments | 15:25 |
Nithesh | ok thanks | 15:26 |
rburton | oh, conflicting packageconfig support got merged? | 15:27 |
*** Nithesh <Nithesh!a5e17a9a@165.225.122.154> has quit IRC | 15:28 | |
qschulz | rburton: yup a few releases ago | 15:29 |
rburton | somehow missed that! | 15:29 |
*** nate100 <nate100!880210b6@gateway/web/cgi-irc/kiwiirc.com/ip.136.2.16.182> has joined #yocto | 15:29 | |
qschulz | docs.yoctoproject.org is super slow for me, same for some of you? | 15:30 |
nate100 | Any advice on getting the Yocto Eclipse plugin working? It seems that the repository is empty/broken? http://downloads.yoctoproject.org/releases/eclipse-plugin/2.6.1/neon/, https://imgur.com/a/1pu9KmT | 15:35 |
nate100 | On that note, is that project deprecated/not in use? Hasn't been updated since 2.6.1 | 15:36 |
qschulz | rburton: documented since dunfell, might predates that even? | 15:36 |
RP | smurray: if you changed the dependencies that would be the issue | 15:37 |
qschulz | nate100: https://docs.yoctoproject.org/ref-manual/migration-2.7.html#eclipse-support-removed | 15:38 |
RP | smurray: we had to turn off autodetection :( | 15:38 |
smurray | RP: I've got a fix to the meta-pipewire layer.conf in hand, will push shortly | 15:38 |
RP | smurray: let me know if I need to change the autobuilder config | 15:39 |
RP | smurray: with fixes pending for OE-Core we may be able to renable autodetection again | 15:39 |
RP | kanavin: I hacked expat-ptest into fast and it all passes: http://autobuilder.yocto.io/pub/non-release/20210506-11/testresults/qemux86-64-ptest-fast/ | 15:42 |
RP | kanavin: I'll send a patch to add that | 15:42 |
*** frsc <frsc!~frsc@i59F4B42A.versanet.de> has quit IRC | 15:44 | |
*** nate100 <nate100!880210b6@gateway/web/cgi-irc/kiwiirc.com/ip.136.2.16.182> has quit IRC | 15:44 | |
*** AndersD <AndersD!~AndersD@h83-209-96-136.cust.a3fiber.se> has joined #yocto | 15:47 | |
*** frsc <frsc!~frsc@i59F4B42A.versanet.de> has joined #yocto | 15:48 | |
*** AndersD_ <AndersD_!~AndersD@h-17-226.A137.corp.bahnhof.se> has joined #yocto | 15:48 | |
*** goliath <goliath!~goliath@clnet-p04-043.ikbnet.co.at> has quit IRC | 15:49 | |
*** AndersD <AndersD!~AndersD@h83-209-96-136.cust.a3fiber.se> has quit IRC | 15:51 | |
smurray | RP: I believe it should be good now | 15:55 |
JaMa | rburton: Saur: ping2 https://lists.yoctoproject.org/g/yocto/message/53345 | 15:56 |
RP | smurray: thanks | 15:57 |
drofty | how to set sstate mirrors can i use it for free? m building dunfell version | 15:59 |
*** meow` <meow`!~sbourdeli@88.164.199.67> has quit IRC | 15:59 | |
*** mbulut <mbulut!~nameclash@ip1f121f26.dynamic.kabel-deutschland.de> has quit IRC | 16:01 | |
*** meow` <meow`!~sbourdeli@82-65-82-156.subs.proxad.net> has joined #yocto | 16:02 | |
v2d | what is MACHINE_GUI_CLASS? | 16:03 |
*** meow` <meow`!~sbourdeli@82-65-82-156.subs.proxad.net> has joined #yocto | 16:03 | |
Scorpi | Hi, 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 files | 16:03 |
Scorpi | at least not in tmp/deploy/ipk/ | 16:04 |
qschulz | Scorpi: if nothing changed in the recipe or dependencies of this recipe, then it's not rebuilt | 16:06 |
qschulz | Scorpi: and it's bitbake <recipe> BTW :) | 16:06 |
Scorpi | qschulz: I changed the recipe | 16:06 |
Scorpi | qschulz: yeas, it's the same in this case (busybox) | 16:06 |
Scorpi | qschulz: I made a change to the defconfig, and now reverted that change and created a custom recipe with a .bbappend with the config change | 16:07 |
Scorpi | qschulz: so I guess it should be rebuilt | 16:07 |
*** fl0v0 <fl0v0!~fvo@89.244.127.215> has quit IRC | 16:07 | |
qschulz | Not necessarily | 16:08 |
qschulz | if the bbappend applied to the bb is identical to the modified bb you had before, it won't be rebuilt | 16:08 |
Scorpi | qschulz: I won't, as it comes with a config snipset that was not present before | 16:09 |
Scorpi | qschulz: I also saw that the patch, configure, compile steps etc. where done | 16:10 |
Scorpi | qschulz: then I noticed that the ipk files had old timestamps, which should not be the case I think | 16:10 |
Scorpi | qschulz: in the log file, I can see that the configure step invokes merge_config with my config snipset, so it seems to work as intended | 16:12 |
*** bps <bps!~bps@80.71.142.18> has quit IRC | 16:14 | |
qschulz | Scorpi: which release are you on? | 16:15 |
*** frsc <frsc!~frsc@i59F4B42A.versanet.de> has quit IRC | 16:16 | |
*** meow` <meow`!~sbourdeli@82-65-82-156.subs.proxad.net> has quit IRC | 16:18 | |
*** meow` <meow`!~sbourdeli@82-65-82-156.subs.proxad.net> has joined #yocto | 16:19 | |
Scorpi | qschulz: 3.1.3 | 16:20 |
qschulz | I'm not entirely sure but I think that release is using the hash equivalence server | 16:21 |
qschulz | which 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 cache | 16:22 |
*** rob_w <rob_w!~rob@unaffiliated/rob-w/x-1112029> has quit IRC | 16:22 | |
Scorpi | okay, makes sense | 16:24 |
Scorpi | can I wipe that specific files from the sstate cache using bitbake? | 16:25 |
qschulz | bitbake -c cleansstate <recipe> but... why? | 16:26 |
Scorpi | To get the ipk files in tmp/deploy, as I deleted them | 16:27 |
Scorpi | I thought that there were the build result, which is regenerated when it is missing when I invoke bitbake again | 16:30 |
ecdhe | I'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 |
ecdhe | How can I prepare a second filesystem for `wic' to copy to my fat partition? | 16:32 |
qschulz | Scorpi: or remove your whole TMPDIR, that should make Yocto install them again | 16:33 |
*** mckoan is now known as mckoan|away | 16:34 | |
qschulz | just don't remove the sstate-cache and downloads directories, the rest is safe to delete | 16:34 |
qschulz | (well maybe there's some hashserv files but I'm not on 3.1+ so can't say for sure) | 16:34 |
Scorpi | qschulz: -c cleansstate works | 16:35 |
*** eFfeM1 <eFfeM1!b9b86d22@185.184.109.34> has joined #yocto | 16:43 | |
qschulz | Scorpi: yes but only for that package, if you remove more, the others still won't be available | 16:44 |
*** c4t3l_home <c4t3l_home!~rcallicot@139.138.156.11> has quit IRC | 16:45 | |
*** c4t3l_home <c4t3l_home!~rcallicot@139.138.156.11> has joined #yocto | 16:49 | |
*** renegade <renegade!~renegade@2601:241:8a00:46e0:649a:6fcd:d26a:d56b> has joined #yocto | 16:53 | |
renegade | Hi 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 recipes | 16:53 |
eFfeM1 | qschulz 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 directory | 16:55 |
eFfeM1 | haven't found a decnt way to fix it | 16:55 |
eFfeM1 | actaually just discovered an os.umask(0o022) after a fork in bitbake/lib/pyinotify.py | 16:57 |
eFfeM1 | no idea if that is realted | 16:57 |
eFfeM1 | related | 16:57 |
*** eFfeM <eFfeM!~fmeulenbr@a97014.upc-a.chello.nl> has joined #yocto | 16:59 | |
RP | eFfeM1: the idea is the sstate code should be using a different umask but I can't remember what/where | 17:05 |
*** kpo <kpo!~kpo@gl23-35.master.pl> has joined #yocto | 17:14 | |
eFfeM | RP 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 |
RP | eFfeM: meta/classes/sstate.bbclass: bb.note("Using umask 0o002 (not %0o) for sstate packaging" % omask) | 17:25 |
RP | eFfeM: but I didn't look in detail | 17:25 |
eFfeM | RP ah ok didn't find that one, still I noticed a dir with mode 755 | 17:26 |
eFfeM | RP anyway, that will help me to proceed | 17:26 |
eFfeM | thanks a lot! | 17:27 |
*** c4t3l_home <c4t3l_home!~rcallicot@139.138.156.11> has quit IRC | 17:29 | |
yates | i'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@103.127.23.213> has quit IRC | 17:32 | |
*** AndersD_ <AndersD_!~AndersD@h-17-226.A137.corp.bahnhof.se> has quit IRC | 17:34 | |
yates | there 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 subfoldres | 17:35 |
*** psnsilva <psnsilva!~psnsilva@161.230.35.203> has quit IRC | 17:36 | |
yates | can someone help me understand where yocto is getting this from? | 17:36 |
*** psnsilva <psnsilva!~psnsilva@161.230.35.203> has joined #yocto | 17:37 | |
yates | and what are these .scc files there? | 17:38 |
*** blueness_ <blueness_!~blueness@gentoo/developer/blueness> has quit IRC | 17:38 | |
*** blueness <blueness!~blueness@gentoo/developer/blueness> has joined #yocto | 17:39 | |
*** c4t3l_home <c4t3l_home!~rcallicot@139.138.156.11> has joined #yocto | 17:41 | |
*** paulg <paulg!~paulg@104-195-159-20.cpe.teksavvy.com> has quit IRC | 17:42 | |
renegade | I believe kernel meta comes from here http://git.yoctoproject.org/cgit/cgit.cgi/yocto-kernel-cache/ | 17:44 |
renegade | I'm not sure how the arch subfolder is populated, I ran into a similar issue | 17:45 |
*** paulg <paulg!~paulg@104-195-159-20.cpe.teksavvy.com> has joined #yocto | 17:55 | |
*** kpo__ <kpo__!~kpo@gl23-35.master.pl> has joined #yocto | 17:56 | |
*** eFfeM <eFfeM!~fmeulenbr@a97014.upc-a.chello.nl> has quit IRC | 17:56 | |
*** kpo <kpo!~kpo@gl23-35.master.pl> has quit IRC | 17:57 | |
*** prabhakarlad <prabhakarlad!c18ddb18@pc.renesas.eu> has quit IRC | 17:59 | |
matthewcroughan | Does anybody in Yocto do this kind of analysis? https://r13y.com/ | 18:00 |
*** eFfeM1 <eFfeM1!b9b86d22@185.184.109.34> has quit IRC | 18:01 | |
sakoman | matthewcroughan: https://www.yoctoproject.org/reproducible-build-results/?branch=master | 18:01 |
matthewcroughan | Interesting, so do you have the same issues with GCC that Nix does? | 18:03 |
matthewcroughan | And so is there a test framework that you use for images? | 18:03 |
matthewcroughan | The raw test results is in json, I'm wondering how the QEMU image is ran, for example. | 18:03 |
khem | kanavin: 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 I | 18:04 |
khem | have 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, its | 18:04 |
khem | still 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!c18ddb18@pc.renesas.eu> has joined #yocto | 18:06 | |
matthewcroughan | sakoman: How do I find out what it was that "wasn't" reproducible.? | 18:07 |
matthewcroughan | The excluded packages. | 18:07 |
ecdhe | To 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 |
ecdhe | But if I have a fat32 filesystem that shouldn't be mounted, how do I copy files to it? | 18:20 |
ecdhe | Can I generate a second rootfs? | 18:20 |
ecdhe | How do I tell e.g. the uboot recipe that u-boot.bin belongs in the second partition? | 18:21 |
*** manuel1985 <manuel1985!~manuel198@62.99.131.178> has quit IRC | 18:25 | |
*** LetoThe2nd <LetoThe2nd!uid453638@gateway/web/irccloud.com/x-fpjnshtlxptdmqxw> has joined #yocto | 18:29 | |
renegade | do something like this for a second rootfs part --source rootfs --ondisk mmcblk0 --fstype=ext4 --label root2 --align 4096 --fixed-size=2G | 18:29 |
LetoThe2nd | yo dudX | 18:29 |
renegade | that being said I can't seem to generate a proper third rootfs | 18:30 |
ecdhe | renegade: wouldn't a line like that would generate a second partition that would get a second copy of the same rootfs? | 18:31 |
ecdhe | I was looking to make a different rootfs (perhaps called bootromfs) | 18:31 |
renegade | ah my bad, yes that will be a copy | 18:31 |
LetoThe2nd | ecdhe: sounds like you want a build-in-build. yay multiconfig! | 18:32 |
kergoth | hmm, yeah, you might need a second image recipe for that, then have wic pull in that image binary.. | 18:33 |
kanavin | RP: right, then we'd need to see if it still passes with expat version update, and whether dropping the patch affects the output | 18:33 |
*** yates <yates!~user@fv-nc-f7af8b91e1-234237-1.tingfiber.com> has quit IRC | 18:34 | |
renegade | he could use rawcopy as a source to copy that image? | 18:34 |
kanavin | khem, 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 |
RP | kanavin: right, those are the next logical steps. I would like to have the testing if we can | 18:36 |
kanavin | khem, 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 tagged | 18:36 |
renegade | since we are talking wic. Why is an extended partition tacked on the end when I make more than 4 partitions? | 18:37 |
renegade | I 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 partition | 18:38 |
kanavin | RP: 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 output | 18:38 |
RP | renegade: don't you need an extended partition table for more than 4 entries? | 18:39 |
kergoth | renegade: 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 issue | 18:39 |
kergoth | but not 100% sure on that.. | 18:39 |
renegade | https://imgur.com/a/3UaUpDi | 18:39 |
RP | kergoth: matches some recollection I have too :) | 18:39 |
RP | kanavin: I'm wondering if we could somehow detect ptests that weren't listed, add some kind of sanity check | 18:39 |
kergoth | hmm, 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 |
renegade | how would i use gpt? All i'm doing is changing a .wks file right now and hoping for the best | 18:41 |
renegade | https://pastebin.com/8ZNi6u1S | 18:42 |
kanavin | RP: it'd be extra tricky because we also have ptests that exist, but are commented out due to being broken in various ways | 18:43 |
*** yates <yates!~user@fv-nc-f7af8b91e1-234237-1.tingfiber.com> has joined #yocto | 18:44 | |
yates | sorry if i missed the answer to my earlier question - had to reboot | 18:44 |
yates | is the channel logged? | 18:45 |
RP | kanavin: we could create a list of ones we know to ignore? | 18:47 |
yates | re: 5.8.13+gitAUTOINC+b976de4f41_3c5d210805-r0 | 18:47 |
yates | khem: do you have any thoughts? | 18:48 |
kanavin | RP: I wonder if ptest class could include ptest-packagelists.inc directly and simply check the presence of ${PN}-ptest in there | 18:50 |
kanavin | the list would need to be accessible to the class though, which probably means it needs itself to become a class | 18:51 |
LetoThe2nd | RP: https://twitter.com/TheYoctoJester/status/1390379236876247043 | 18:53 |
yates | has anyone noticed that converting task-depends.dot files to pdf using dot can take an extraordinary amount of time? | 18:56 |
kanavin | yates, don't. It's a text file and totally human readable. | 18:56 |
yates | dot task-depends.dot -Tpdf -o task-depends.pdf | 18:56 |
rfs613 | yates: yup, i gave up after hours and hours. | 18:56 |
LetoThe2nd | yates: sures. anyone == everybody who ever treid, in that context. | 18:56 |
kanavin | yates, if you have specific questions, it's better to quickly hack together a python script that massages the dot into the answer | 18:57 |
yates | ah. well it appears i'm not alone.. | 18:58 |
rfs613 | yates: i tried some of the suggestions on https://stackoverflow.com/questions/10766100/graphviz-dot-very-long-duration-of-generation | 18:58 |
kergoth | oe-depends-dot in oe-core is a better bet. or just grep. :) | 18:58 |
kergoth | than rendering, that is | 18:59 |
LetoThe2nd | kergoth: ag FTW | 18:59 |
kergoth | or rg, yeah :) | 18:59 |
LetoThe2nd | kergoth: ripgrep? | 19:01 |
kergoth | yeah | 19:01 |
LetoThe2nd | because of a specific reason? just curious? | 19:04 |
rfs613 | because rust, of course ;-P | 19:06 |
LetoThe2nd | rfs613: thats the answer i expect(ed) in many cases, but not by kergoth :) | 19:06 |
*** goliath <goliath!~goliath@clnet-p04-043.ikbnet.co.at> has joined #yocto | 19:07 | |
kergoth | I originally switched for performance reasons, along with some of the options grep has, like -x | 19:08 |
kergoth | but my dotfiles fall back to ag or even ack depending on what i've installed, they all get the job done | 19:09 |
LetoThe2nd | kergoth: ah interesting. | 19:09 |
kergoth | https://beyondgrep.com/feature-comparison/ is pretty thorough | 19:09 |
renegade | any ideas on how i can use gpt instead of mbr? | 19:10 |
kergoth | i 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 dotfiles | 19:10 |
LetoThe2nd | kergoth: yeah | 19: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 |
rfs613 | yates, you might also be interested in 'bitbake -g --ui=taskexp TARGET' | 19:11 |
ecdhe | LetoThe2nd: maybe I do, maybe I don't | 19:20 |
*** psnsilva <psnsilva!~psnsilva@161.230.35.203> has quit IRC | 19:21 | |
ecdhe | LetoThe2nd: 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@194.230.138.56> has quit IRC | 19:21 | |
*** lucaceresoli <lucaceresoli!~lucaceres@77.244.183.192> has quit IRC | 19:21 | |
LetoThe2nd | ecdhe: https://youtu.be/YvdkvxAIIGQ | 19:22 |
ecdhe | LetoThe2nd: watching now | 19:28 |
ecdhe | Seems 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 build | 19:29 |
ecdhe | building a filesystem is building an object that comprises many other built objects | 19:30 |
LetoThe2nd | ecdhe: *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, ofc | 19:31 |
yates | is linux-yocto/5.8.13+gitAUTOINC+b976de4f41_3c5d210805-r0 some sort of a code for dynamaic fetches? | 19:31 |
c4t3l_home | inception builds | 19:31 |
* LetoThe2nd must resist urge to make contraception pun | 19:32 | |
yates | baby builds | 19:32 |
yates | (motivated by George Carlin's "Baby-Maybe" skit in the 70s) | 19:33 |
* c4t3l_home giggles and spills coffee | 19:33 | |
yates | Papa-Stopper, "Embyr-NO" ... | 19:34 |
yates | ok, i'll shutup now. | 19:34 |
LetoThe2nd | well we could call it "evil builds" and "mini me"s, for non-mc and mc builds? | 19:35 |
yates | folks, i'm truly confused. i mean, more than usual. | 19:36 |
LetoThe2nd | mission: accomplished. | 19:37 |
yates | the motivating problem: http://paste.ubuntu.com/p/smYx75j3mX/ | 19:37 |
yates | LetoThe2nd: you are cruel | 19:38 |
yates | so i traced things as far as the line in run.do_kernel_metadata: bsp_definition=$(spp ${includes} --find -DKMACHINE=qemucsky -DKTYPE=standard) | 19:39 |
yates | i 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 |
yates | i further found there are not ..kernel-meta/bsp folders for my board: qemucsky | 19:40 |
*** zkrx <zkrx!~slimshady@194.230.138.56> has joined #yocto | 19:40 | |
yates | what i can't figure out is: where is this folder coming from? | 19:40 |
yates | i thought it may be from here, but it looks different: https://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto/tag/?h=v5.8.13 | 19:41 |
LetoThe2nd | yates: yoctoized kernels are.... special. i've never used those, i personally favor vanilla ones. you might want to read the kernel-dev-manual | 19:41 |
yates | like, a LOT different. different structgure. | 19:41 |
sakoman | matthewcroughan: see line 30 here: https://git.openembedded.org/openembedded-core/tree/meta/lib/oeqa/selftest/cases/reproducible.py | 19:42 |
yates | LetoThe2nd: are you saying the linux-yocto kernel is not based directly on a mainline kernel? pfft!!!! | 19:43 |
yates | ok, i'm a dumbass... | 19:43 |
LetoThe2nd | yates: based on? yes. equivalent? no. | 19:43 |
zeddii | 'er no, that's wrong. | 19:44 |
zeddii | but unfortunately, my day is done. no time to discuss. will be back tomorrow. | 19:44 |
yates | zeddii: i'll pay your overtime! | 19:45 |
yates | name your price. (in Raymond Reddington style...) | 19:45 |
LetoThe2nd | I'm wrong? Film at 11 ;-) | 19:45 |
yates | how 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'8 | 19:49 | |
yates | l8r | 19:49 |
renegade | looks like this will let me use gpt bootloader --ptable gpt | 19:56 |
*** rcoote <rcoote!~rcoote@2a02:908:692:81c0:84e7:69a1:ef6c:26e2> has quit IRC | 20:04 | |
*** eduardas <eduardas!~eduardas@82-135-139-249.static.zebra.lt> has quit IRC | 20:14 | |
*** psnsilva <psnsilva!~psnsilva@161.230.35.203> has joined #yocto | 20:30 | |
*** prabhakarlad <prabhakarlad!c18ddb18@pc.renesas.eu> has quit IRC | 20:32 | |
*** manuel_ <manuel_!~manuel@2a02:1748:dd5c:f290:c553:9012:6082:a89a> has joined #yocto | 20:37 | |
*** manuel1985 <manuel1985!~manuel198@2a02:1748:dd5c:f290:c5b2:fdff:b718:9edf> has joined #yocto | 20:47 | |
matthewcroughan | sakoman: interesting.. so Yocto considers GCC reproducible? | 20:57 |
khem | yates: what was question you had for me ? | 20:58 |
khem | matthewcroughan: most of package in oe-core are reprodcible | 20:58 |
matthewcroughan | And GCC is in oe-core, yet Nix can't call it reproducible. I wonder what the difference is. | 20:59 |
matthewcroughan | Does Yocto consider "reproducible" to mean something different than what Nix means? | 20:59 |
khem | matthewcroughan: do you mean gcc package itself or the output of it ? | 21:00 |
matthewcroughan | The GCC binary. | 21:00 |
matthewcroughan | The output of the recipe. | 21:00 |
matthewcroughan | Nix 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 |
khem | yes, its maked as reproducible, why does nix mark it not so | 21:01 |
matthewcroughan | https://r13y.com/diff/9849af16e34e39b94dffede2bedb4fe45992133b4be5fe4d26c2c3820379122b-177b2699c9f6b676ac4f4ec85438dda0f93a00fd01a0e6fe3d9111bf2420f72d.html | 21:01 |
matthewcroughan | There 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 |
matthewcroughan | Does the reproducible-build-results stuff run under that same scrutiny? | 21:06 |
matthewcroughan | 2 systems, 2 times, 2 kernels? | 21:06 |
*** manuel1985 <manuel1985!~manuel198@2a02:1748:dd5c:f290:c5b2:fdff:b718:9edf> has quit IRC | 21:10 | |
*** psnsilva <psnsilva!~psnsilva@161.230.35.203> has quit IRC | 21:11 | |
*** manuel1985 <manuel1985!~manuel198@2a02:1748:dd5c:f290:b1d2:8f1d:3e46:b9a1> has joined #yocto | 21:14 | |
*** aidanh <aidanh!~aidanh@unaffiliated/aidanh> has quit IRC | 21:18 | |
yates | hi khem | 21:18 |
rburton | matthewcroughan: yes | 21:20 |
*** aidanh <aidanh!~aidanh@unaffiliated/aidanh> has joined #yocto | 21:22 | |
yates | the motivating problem: http://paste.ubuntu.com/p/smYx75j3mX/ | 21:23 |
yates | so i traced things as far as the line in run.do_kernel_metadata: bsp_definition=$(spp ${includes} --find -DKMACHINE=qemucsky -DKTYPE=standard) | 21:23 |
yates | i 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 |
matthewcroughan | rburton: how do I reproduce the results? | 21:24 |
yates | what i can't figure out is: where is this folder coming from? | 21:24 |
rburton | matthewcroughan: oe-selftest -r reproducible | 21:24 |
yates | khem: where is this folder coming from? | 21:25 |
yates | i thought it may be from here, but it looks different: https://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto/tag/?h=v5.8.13 | 21:25 |
yates | my guess is that there is no qemucsky folder under kernel-meta/bsp, hence the bitbake error. | 21:28 |
yates | i don't understand where the bsp folders that are there are coming from. | 21:28 |
yates | what does the encoding "5.8.13+gitAUTOINC+b976de4f41_3c5d210805-r0" mean? | 21:31 |
*** psnsilva <psnsilva!~psnsilva@161.230.35.203> has joined #yocto | 21:37 | |
yates | khem: ? | 21:38 |
*** c4t3l_home <c4t3l_home!~rcallicot@139.138.156.11> has quit IRC | 21:53 | |
*** nslu2-log <nslu2-log!~nslu2-log@leia.nas-admin.org> has quit IRC | 22:05 | |
*** nslu2-log <nslu2-log!~nslu2-log@leia.nas-admin.org> has joined #yocto | 22:07 | |
*** bps <bps!~bps@80.71.142.18> has joined #yocto | 22:15 | |
*** argonautx <argonautx!~argonautx@i59F77FC4.versanet.de> has quit IRC | 22:18 | |
*** goliath <goliath!~goliath@clnet-p04-043.ikbnet.co.at> has quit IRC | 22:19 | |
*** renegade <renegade!~renegade@2601:241:8a00:46e0:649a:6fcd:d26a:d56b> has quit IRC | 22:23 |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!