| *** Xagen <Xagen!~Xagen@2600:1700:211:7e60:b58a:89ad:a475:a7ef> has quit IRC (Ping timeout: 250 seconds) | 00:02 | |
| *** Xagen <Xagen!~Xagen@2600:1700:211:7e60:f400:f0b8:e30b:7511> has joined #yocto | 00:03 | |
| *** BCMM <BCMM!~BCMM@user/bcmm> has quit IRC (Ping timeout: 244 seconds) | 00:14 | |
| *** twinning[m] <twinning[m]!~twinningm@2001:470:69fc:105::e5db> has joined #yocto | 00:51 | |
| *** jwillikers <jwillikers!~jwilliker@ics141-1.icsincorporated.com> has quit IRC (Remote host closed the connection) | 01:10 | |
| *** tp43_ <tp43_!~ndeem@2001:1970:502b:d701:a199:1a3e:abd1:ac4c> has joined #yocto | 01:38 | |
| *** amitk <amitk!~amit@103.208.71.148> has joined #yocto | 04:03 | |
| *** paulg <paulg!~paulg@104-195-159-20.cpe.teksavvy.com> has quit IRC (Ping timeout: 250 seconds) | 04:17 | |
| *** tp43_ <tp43_!~ndeem@2001:1970:502b:d701:a199:1a3e:abd1:ac4c> has quit IRC (Ping timeout: 252 seconds) | 04:23 | |
| *** tkoskine <tkoskine!tkoskine@kapsi.fi> has quit IRC (*.net *.split) | 04:30 | |
| *** tkoskine <tkoskine!tkoskine@kapsi.fi> has joined #yocto | 04:30 | |
| wCPO | Can WIC add empty space at the end of the image? I need a bigger WIC image, so I can use systemd-repart when running in QEMU to add a extra partition | 04:45 |
|---|---|---|
| *** leon-anavi <leon-anavi!~Leon@78.130.197.211> has joined #yocto | 04:48 | |
| wCPO | IMAGE_ROOTFS_EXTRA_SPACE🎉 | 04:55 |
| *** alinucs_ <alinucs_!~abo@215.ip-51-38-235.eu> has joined #yocto | 05:20 | |
| *** alinucs <alinucs!~abo@215.ip-51-38-235.eu> has quit IRC (Ping timeout: 252 seconds) | 05:21 | |
| *** tgamblin <tgamblin!~tgamblin@2607:fea8:c29d:d7c0:fa88:8bc5:c0d2:27cc> has quit IRC (Remote host closed the connection) | 05:26 | |
| *** tgamblin <tgamblin!~tgamblin@2607:fea8:c29d:d7c0:fa88:8bc5:c0d2:27cc> has joined #yocto | 05:27 | |
| *** te_johan <te_johan!~te_johan@212-107-146-91.customers.ownit.se> has joined #yocto | 05:57 | |
| te_johan | moin moin, i'm having issues with post install scripts failing to change owner during do_rootfs: copyfile | 05:58 |
| te_johan | the poky repo is owned by my user and the build is done in docker with uid and gid 1000. so bitbake copies the file and afterwards it tries and restore the owner to the original owner. I don't understand why it would want to change owner at all. I've seen other have similar issues mentioning a change in PSEUDO_IGNORE_PATHS. | 06:00 |
| te_johan | does anyone have any insight in who ownership of files are changed in bitbake:utils:copyfile? | 06:03 |
| *** te_johan <te_johan!~te_johan@212-107-146-91.customers.ownit.se> has quit IRC (Quit: Ping timeout (120 seconds)) | 06:16 | |
| *** te_johan <te_johan!~te_johan@212-107-146-91.customers.ownit.se> has joined #yocto | 06:19 | |
| *** amitk <amitk!~amit@103.208.71.148> has quit IRC (Remote host closed the connection) | 06:32 | |
| *** amitk <amitk!~amit@103.208.71.148> has joined #yocto | 06:34 | |
| *** frieder <frieder!~frieder@170-77-142-46.pool.kielnet.net> has joined #yocto | 06:35 | |
| *** override_ <override_!~override@ec2-3-138-201-125.us-east-2.compute.amazonaws.com> has quit IRC (Ping timeout: 252 seconds) | 06:42 | |
| *** override_ <override_!~override@ec2-3-138-201-125.us-east-2.compute.amazonaws.com> has joined #yocto | 06:43 | |
| *** LetoThe2nd <LetoThe2nd!uid453638@id-453638.highgate.irccloud.com> has joined #yocto | 06:47 | |
| *** goliath <goliath!~goliath@user/goliath> has joined #yocto | 07:08 | |
| *** yannd <yannd!~yann@88.120.44.86> has quit IRC (Ping timeout: 252 seconds) | 07:11 | |
| *** eduardas <eduardas!~eduardas@93.93.57.5> has joined #yocto | 07:12 | |
| *** te_johan <te_johan!~te_johan@212-107-146-91.customers.ownit.se> has quit IRC (Quit: Ping timeout (120 seconds)) | 07:18 | |
| barath | this is related to a question I had yesterday, about packages being assigned (their names contain) both aarch64 and our custom machine name which has the aarch64 architecture, and whether that can cause issues | 07:19 |
| barath | I now see there's a variable called PACKAGE_ARCH, which can be set per recipe (?) to define the "actual" arch... would that fix some packages being "assigned" this machine we have defined instead of the arch it's actually built for? does it make sense to invest time in doing that? | 07:20 |
| *** te_johan <te_johan!~te_johan@212-107-146-91.customers.ownit.se> has joined #yocto | 07:22 | |
| *** yannd <yannd!~yann@88.120.44.86> has joined #yocto | 07:25 | |
| LetoThe2nd | yo dudX | 07:26 |
| *** te_johan_ <te_johan_!~te_johan@212-107-146-91.customers.ownit.se> has joined #yocto | 07:27 | |
| *** te_johan <te_johan!~te_johan@212-107-146-91.customers.ownit.se> has quit IRC (Quit: Client closed) | 07:28 | |
| *** rfuentess <rfuentess!~rfuentess@2a01:cb14:87e:2200:8500:1f3c:76ee:bbf4> has joined #yocto | 07:30 | |
| qschulz | barath: yes set per recipe, that would make sense though you have to be "careful" so that you make machine specific only what's needed otherwise you'll have a ton of technically duplicate recipes/packages between two different machines | 07:36 |
| barath | yes that's what I'm investigating... while investigating why some packages always are rebuilt even tho we have sstate cache files from another machine | 07:37 |
| *** zyga-mbp <zyga-mbp!~zyga@31.0.173.147> has quit IRC (Ping timeout: 252 seconds) | 07:37 | |
| qschulz | barath: you could also technically introduce another arch, an intermediate one which is common to your machines, provided the outcome of a recipe is identical for both machines (i.e. compiler flag and architecture, etc.) | 07:37 |
| barath | so is that "best practice"? ie that when you define a machine, you should actually set the package arch to the underlying PACKAGE_ARCH? | 07:37 |
| qschulz | barath: no | 07:37 |
| barath | hm I see... | 07:37 |
| *** zyga-mbp <zyga-mbp!~zyga@178.182.246.167.nat.umts.dynamic.t-mobile.pl> has joined #yocto | 07:37 | |
| barath | :D okay | 07:38 |
| barath | so what's usually done? I imagine this is something people do a lot: define a machine using the aarch64 arch and then build custom recipes (or even systemd, which has some of its packages marked as aarch64 and then some with our custom machine name) | 07:38 |
| qschulz | you set the PACKAGE_ARCH to MACHINE_ARCH if anything in the recipe uses something that can change between machines of the same "base" architecture (aarch64, cortexa8-hf, ... whatever) | 07:39 |
| qschulz | e.g. using MACHINE in there, or an override with a MACHINEOVERRIDES | 07:39 |
| barath | hm okay, so it's for being specific when the difference between arch variants becomes important for a recipe | 07:40 |
| qschulz | arch variants or machines, yes | 07:40 |
| barath | hm okay | 07:41 |
| barath | so let's take system. I some of the systemd packages are built for aarch64, some for our custom machine name | 07:41 |
| barath | is that "okay"? we've done this for ages, so it obviously works | 07:41 |
| barath | but it feels very strange now that I've tested package feeds and some are put in aarch64 and some under our custom machine name | 07:41 |
| *** BCMM <BCMM!~BCMM@user/bcmm> has joined #yocto | 07:41 | |
| qschulz | well, it seems it does not since you're having trouble with sstate-cache re-use :p | 07:41 |
| *** BCMM <BCMM!~BCMM@user/bcmm> has quit IRC (Client Quit) | 07:42 | |
| *** BCMM <BCMM!~BCMM@user/bcmm> has joined #yocto | 07:42 | |
| qschulz | systemd package specific to your custom machine should have PACKAGE_ARCH set to MACHINE_ARCH | 07:42 |
| barath | :D yeah, question is whether this is to blame | 07:42 |
| barath | it's been hard for me to nail down exactly where/why the hashes start differing between hosts, a lot of base hashes seem different | 07:42 |
| barath | > systemd package specific to your custom machine should have PACKAGE_ARCH set to MACHINE_ARCH | 07:43 |
| barath | hm. I see that the systemd-conf package is stored under our machine name, while the systemd package itself is marked as/stored under aarch64 | 07:43 |
| barath | sorry if these are noob questions, I'm trying to align our yocto usage with something that approaches best practice/actually how it's meant to be used instead of hacks everywhere... | 07:45 |
| *** florian <florian!~florian@dynamic-093-131-096-150.93.131.pool.telefonica.de> has joined #yocto | 08:04 | |
| *** camus <camus!~Instantbi@58.246.136.202> has quit IRC (Read error: Connection reset by peer) | 08:11 | |
| *** camus1 <camus1!~Instantbi@58.246.136.202> has joined #yocto | 08:11 | |
| *** d0ku <d0ku!~d0ku@178.43.56.75.ipv4.supernova.orange.pl> has joined #yocto | 08:13 | |
| *** camus1 is now known as camus | 08:14 | |
| *** cody <cody!~cody@user/cody> has quit IRC (Quit: You have been idle for 30+ days) | 08:19 | |
| *** m1kr0[m] <m1kr0[m]!~m1kr0matr@2001:470:69fc:105::c827> has quit IRC (Quit: You have been idle for 30+ days) | 08:19 | |
| RP | kanavin_: looks like your build found a bitbake socket file race :/ | 08:20 |
| *** m1kr0[m] <m1kr0[m]!~m1kr0matr@2001:470:69fc:105::c827> has joined #yocto | 08:20 | |
| *** m1kr0[m] <m1kr0[m]!~m1kr0matr@2001:470:69fc:105::c827> has left #yocto | 08:20 | |
| kanavin_ | RP: I saw that one in a previous master-next build too | 08:25 |
| RP | kanavin_: I think it is harmless and just a race over removing the file so the code should be ignoring it? | 08:26 |
| kanavin_ | RP: this one was a master build https://autobuilder.yoctoproject.org/typhoon/#/builders/20/builds/4233 | 08:27 |
| RP | or it should be waiting for bitbake to shut down before deleting | 08:27 |
| kanavin_ | RP: and happens *only* in buildtools :-/ | 08:27 |
| RP | kanavin_: buildtools is a new test and is unusual in that it is running bitbake | 08:27 |
| RP | kanavin_: http://git.yoctoproject.org/cgit.cgi/yocto-autobuilder-helper/commit/?id=0b1925161871ed0ffa5a63e5c83152a568aee157 | 08:28 |
| RP | kanavin_: we can blame rburton | 08:28 |
| *** te_johan_ <te_johan_!~te_johan@212-107-146-91.customers.ownit.se> has quit IRC (Quit: Leaving...) | 08:46 | |
| *** te_johan <te_johan!~te_johan@212-107-146-91.customers.ownit.se> has joined #yocto | 08:46 | |
| *** rfuentess <rfuentess!~rfuentess@2a01:cb14:87e:2200:8500:1f3c:76ee:bbf4> has quit IRC (Ping timeout: 240 seconds) | 08:48 | |
| *** rfuentess <rfuentess!~rfuentess@amarseille-656-1-20-91.w81-251.abo.wanadoo.fr> has joined #yocto | 08:50 | |
| *** Guest93 <Guest93!~Guest93@mail.chora.dk> has joined #yocto | 09:02 | |
| *** Guest93 <Guest93!~Guest93@mail.chora.dk> has quit IRC (Client Quit) | 09:03 | |
| *** leon-anavi <leon-anavi!~Leon@78.130.197.211> has quit IRC (Remote host closed the connection) | 09:05 | |
| *** leon-anavi <leon-anavi!~Leon@78.130.197.211> has joined #yocto | 09:05 | |
| *** wooosaiiii <wooosaiiii!~wooo@89-212-21-243.static.t-2.net> has quit IRC (Remote host closed the connection) | 09:24 | |
| *** wooosaiiii <wooosaiiii!~wooo@89-212-21-243.static.t-2.net> has joined #yocto | 09:24 | |
| *** florian <florian!~florian@dynamic-093-131-096-150.93.131.pool.telefonica.de> has quit IRC (Ping timeout: 252 seconds) | 09:25 | |
| *** camus <camus!~Instantbi@58.246.136.202> has quit IRC (Remote host closed the connection) | 09:38 | |
| *** camus <camus!~Instantbi@58.246.136.202> has joined #yocto | 09:38 | |
| *** goliath <goliath!~goliath@user/goliath> has quit IRC (Quit: SIGSEGV) | 09:38 | |
| *** argonautx <argonautx!~argonautx@i5E86705F.versanet.de> has joined #yocto | 09:40 | |
| *** florian <florian!~florian@port-217-146-132-69.static.as20676.net> has joined #yocto | 09:54 | |
| *** kanavin_ <kanavin_!~Alexander@2a02:2454:29b:3b00:d35d:e3cf:58b5:748b> has quit IRC (Ping timeout: 240 seconds) | 10:06 | |
| *** kanavin <kanavin!~Alexander@82.119.0.16> has joined #yocto | 10:10 | |
| *** manuel1985 <manuel1985!~manuel198@2a02:1748:dd5c:f290:7848:b419:eae2:e315> has joined #yocto | 10:11 | |
| *** goliath <goliath!~goliath@user/goliath> has joined #yocto | 10:24 | |
| ad__ | hi, is it normal that wic tool insert an empty space between emmc partitions ? | 10:52 |
| ad__ | wic ls shows a partition without fstype | 10:53 |
| *** xantoz_ is now known as xantoz | 11:02 | |
| *** hansihe <hansihe!~Hans@84-52-214.116.3p.ntebredband.no> has quit IRC (Remote host closed the connection) | 11:09 | |
| *** cocoJoe <cocoJoe!~cocoJoe@xb9b5dc3e.cust.hiper.dk> has quit IRC (Quit: Client closed) | 11:13 | |
| *** vd <vd!~vd@bras-base-mtrlpq2848w-grc-41-70-53-240-121.dsl.bell.ca> has quit IRC (Quit: Client closed) | 11:24 | |
| *** zyga <zyga!~zyga@178.182.246.167.nat.umts.dynamic.t-mobile.pl> has joined #yocto | 11:30 | |
| *** zyga-mbp <zyga-mbp!~zyga@178.182.246.167.nat.umts.dynamic.t-mobile.pl> has quit IRC (Read error: Connection reset by peer) | 11:31 | |
| *** prabhakarlad <prabhakarlad!~prabhakar@pc.renesas.eu> has quit IRC (Quit: Client closed) | 11:43 | |
| *** rfuentess <rfuentess!~rfuentess@amarseille-656-1-20-91.w81-251.abo.wanadoo.fr> has quit IRC (Remote host closed the connection) | 11:48 | |
| *** rfuentess <rfuentess!~rfuentess@amarseille-656-1-20-91.w81-251.abo.wanadoo.fr> has joined #yocto | 11:51 | |
| *** prabhakarlad <prabhakarlad!~prabhakar@pc.renesas.eu> has joined #yocto | 12:03 | |
| *** jwillikers <jwillikers!~jwilliker@ics141-1.icsincorporated.com> has joined #yocto | 12:05 | |
| *** florian <florian!~florian@port-217-146-132-69.static.as20676.net> has quit IRC (Remote host closed the connection) | 12:07 | |
| *** florian <florian!~florian@port-217-146-132-69.static.as20676.net> has joined #yocto | 12:11 | |
| *** jwillikers <jwillikers!~jwilliker@ics141-1.icsincorporated.com> has quit IRC (Remote host closed the connection) | 12:25 | |
| *** hmw[m] <hmw[m]!~hmwmatrix@2001:470:69fc:105::3c7c> has joined #yocto | 12:37 | |
| *** jwillikers <jwillikers!~jwilliker@ics141-1.icsincorporated.com> has joined #yocto | 12:37 | |
| *** zyga <zyga!~zyga@178.182.246.167.nat.umts.dynamic.t-mobile.pl> has quit IRC (Ping timeout: 244 seconds) | 12:39 | |
| *** zyga-mbp <zyga-mbp!~zyga@178.182.246.167.nat.umts.dynamic.t-mobile.pl> has joined #yocto | 12:39 | |
| *** jordemort <jordemort!~jordemort@2001:470:69fc:105::2d9> has quit IRC (Quit: Bridge terminating on SIGTERM) | 12:42 | |
| *** shoragan[m] <shoragan[m]!~shoraganm@2001:470:69fc:105::39> has quit IRC (Quit: Bridge terminating on SIGTERM) | 12:42 | |
| *** berton[m] <berton[m]!~fabiobert@2001:470:69fc:105::ce36> has quit IRC (Quit: Bridge terminating on SIGTERM) | 12:42 | |
| *** Emantor[m] <Emantor[m]!~emantorm]@2001:470:69fc:105::8eb> has quit IRC (Quit: Bridge terminating on SIGTERM) | 12:42 | |
| *** kayterina[m] <kayterina[m]!~kayterina@2001:470:69fc:105::960> has quit IRC (Quit: Bridge terminating on SIGTERM) | 12:42 | |
| *** t_unix[m] <t_unix[m]!~tunixmatr@2001:470:69fc:105::9ea> has quit IRC (Quit: Bridge terminating on SIGTERM) | 12:42 | |
| *** rostam98[m] <rostam98[m]!~rostam98m@2001:470:69fc:105::ca0e> has quit IRC (Quit: Bridge terminating on SIGTERM) | 12:42 | |
| *** barath <barath!~barath@2001:470:69fc:105::21a> has quit IRC (Quit: Bridge terminating on SIGTERM) | 12:42 | |
| *** ejoerns[m] <ejoerns[m]!~ejoernsma@2001:470:69fc:105::252> has quit IRC (Quit: Bridge terminating on SIGTERM) | 12:42 | |
| *** jwillikers[m] <jwillikers[m]!~jwilliker@2001:470:69fc:105::626a> has quit IRC (Quit: Bridge terminating on SIGTERM) | 12:42 | |
| *** SamuelDolt[m] <SamuelDolt[m]!~samdoltma@2001:470:69fc:105::4898> has quit IRC (Quit: Bridge terminating on SIGTERM) | 12:42 | |
| *** Alban[m] <Alban[m]!~albeugaen@2001:470:69fc:105::34b4> has quit IRC (Quit: Bridge terminating on SIGTERM) | 12:42 | |
| *** Saur[m] <Saur[m]!~saur2000m@2001:470:69fc:105::dce> has quit IRC (Quit: Bridge terminating on SIGTERM) | 12:42 | |
| *** Spectrejan[m] <Spectrejan[m]!~spectreja@2001:470:69fc:105::1609> has quit IRC (Quit: Bridge terminating on SIGTERM) | 12:42 | |
| *** meck[m] <meck[m]!~meckmeckd@2001:470:69fc:105::3a51> has quit IRC (Quit: Bridge terminating on SIGTERM) | 12:42 | |
| *** shoragan|m <shoragan|m!~shoragans@2001:470:69fc:105::c9f> has quit IRC (Quit: Bridge terminating on SIGTERM) | 12:42 | |
| *** PascalBach[m] <PascalBach[m]!~bachpmatr@2001:470:69fc:105::1d3b> has quit IRC (Quit: Bridge terminating on SIGTERM) | 12:42 | |
| *** moto_timo[m] <moto_timo[m]!~mototimom@2001:470:69fc:105::c94> has quit IRC (Quit: Bridge terminating on SIGTERM) | 12:42 | |
| *** dwagenk <dwagenk!~dwagenk@2001:470:69fc:105::103d> has quit IRC (Quit: Bridge terminating on SIGTERM) | 12:42 | |
| *** jonesv[m] <jonesv[m]!~jonesvmat@2001:470:69fc:105::4616> has quit IRC (Quit: Bridge terminating on SIGTERM) | 12:42 | |
| *** batcha[m] <batcha[m]!~batcha88m@2001:470:69fc:105::dd0e> has quit IRC (Quit: Bridge terminating on SIGTERM) | 12:42 | |
| *** agherzan <agherzan!~agherzan@2001:470:69fc:105::e1fe> has quit IRC (Quit: Bridge terminating on SIGTERM) | 12:42 | |
| *** ndec[m] <ndec[m]!~ndecmatri@2001:470:69fc:105::9c0> has quit IRC (Quit: Bridge terminating on SIGTERM) | 12:42 | |
| *** WadeBerrier[m] <WadeBerrier[m]!~wberrierm@2001:470:69fc:105::3f0e> has quit IRC (Quit: Bridge terminating on SIGTERM) | 12:42 | |
| *** twinning[m] <twinning[m]!~twinningm@2001:470:69fc:105::e5db> has quit IRC (Quit: Bridge terminating on SIGTERM) | 12:42 | |
| *** hmw[m] <hmw[m]!~hmwmatrix@2001:470:69fc:105::3c7c> has quit IRC (Quit: Bridge terminating on SIGTERM) | 12:42 | |
| *** k4wsys[m] <k4wsys[m]!~k4wsysmat@2001:470:69fc:105::e339> has quit IRC (Quit: Bridge terminating on SIGTERM) | 12:42 | |
| *** CarlesFernandez[ <CarlesFernandez[!~cfernande@2001:470:69fc:105::e590> has quit IRC (Quit: Bridge terminating on SIGTERM) | 12:42 | |
| *** halstead[m]1 <halstead[m]1!~halsteadm@2001:470:69fc:105::d0ef> has quit IRC (Quit: Bridge terminating on SIGTERM) | 12:42 | |
| *** khem <khem!~khemmatri@2001:470:69fc:105::b81> has quit IRC (Quit: Bridge terminating on SIGTERM) | 12:42 | |
| *** Pierre-jeanTexie <Pierre-jeanTexie!~pjtexierm@2001:470:69fc:105::f2f> has quit IRC (Quit: Bridge terminating on SIGTERM) | 12:42 | |
| *** michaelo[m] <michaelo[m]!~michaelom@2001:470:69fc:105::d101> has quit IRC (Quit: Bridge terminating on SIGTERM) | 12:42 | |
| *** behanw[m] <behanw[m]!~behanwmat@2001:470:69fc:105::c96> has quit IRC (Quit: Bridge terminating on SIGTERM) | 12:42 | |
| *** lexano[m] <lexano[m]!~lexanomat@2001:470:69fc:105::3110> has quit IRC (Quit: Bridge terminating on SIGTERM) | 12:42 | |
| *** falk0n[m] <falk0n[m]!~falk0nmat@2001:470:69fc:105::ce60> has quit IRC (Quit: Bridge terminating on SIGTERM) | 12:42 | |
| *** kranzo[m] <kranzo[m]!~kranzomat@2001:470:69fc:105::dd3e> has quit IRC (Quit: Bridge terminating on SIGTERM) | 12:42 | |
| *** jordemort <jordemort!~jordemort@2001:470:69fc:105::2d9> has joined #yocto | 12:44 | |
| *** WadeBerrier[m] <WadeBerrier[m]!~wberrierm@2001:470:69fc:105::3f0e> has joined #yocto | 12:45 | |
| *** mihai <mihai!~mihai@user/mihai> has joined #yocto | 12:52 | |
| *** lexano[m] <lexano[m]!~lexanomat@2001:470:69fc:105::3110> has joined #yocto | 12:53 | |
| *** Alban[m] <Alban[m]!~albeugaen@2001:470:69fc:105::34b4> has joined #yocto | 12:53 | |
| *** kayterina[m] <kayterina[m]!~kayterina@2001:470:69fc:105::960> has joined #yocto | 12:53 | |
| *** Saur[m] <Saur[m]!~saur2000m@2001:470:69fc:105::dce> has joined #yocto | 12:53 | |
| *** Emantor[m] <Emantor[m]!~emantorm]@2001:470:69fc:105::8eb> has joined #yocto | 12:53 | |
| *** khem <khem!~khemmatri@2001:470:69fc:105::b81> has joined #yocto | 12:53 | |
| *** shoragan[m] <shoragan[m]!~shoraganm@2001:470:69fc:105::39> has joined #yocto | 12:53 | |
| *** Pierre-jeanTexie <Pierre-jeanTexie!~pjtexierm@2001:470:69fc:105::f2f> has joined #yocto | 12:53 | |
| *** ejoerns[m] <ejoerns[m]!~ejoernsma@2001:470:69fc:105::252> has joined #yocto | 12:53 | |
| *** moto_timo[m] <moto_timo[m]!~mototimom@2001:470:69fc:105::c94> has joined #yocto | 12:53 | |
| *** t_unix[m] <t_unix[m]!~tunixmatr@2001:470:69fc:105::9ea> has joined #yocto | 12:53 | |
| *** berton[m] <berton[m]!~fabiobert@2001:470:69fc:105::ce36> has joined #yocto | 12:53 | |
| *** agherzan <agherzan!~agherzan@2001:470:69fc:105::e1fe> has joined #yocto | 12:53 | |
| *** barath <barath!~barath@2001:470:69fc:105::21a> has joined #yocto | 12:53 | |
| *** jwillikers[m] <jwillikers[m]!~jwilliker@2001:470:69fc:105::626a> has joined #yocto | 12:53 | |
| *** SamuelDolt[m] <SamuelDolt[m]!~samdoltma@2001:470:69fc:105::4898> has joined #yocto | 12:53 | |
| *** hmw[m] <hmw[m]!~hmwmatrix@2001:470:69fc:105::3c7c> has joined #yocto | 12:53 | |
| *** shoragan|m <shoragan|m!~shoragans@2001:470:69fc:105::c9f> has joined #yocto | 12:53 | |
| *** Spectrejan[m] <Spectrejan[m]!~spectreja@2001:470:69fc:105::1609> has joined #yocto | 12:53 | |
| *** meck[m] <meck[m]!~meckmeckd@2001:470:69fc:105::3a51> has joined #yocto | 12:53 | |
| *** rostam98[m] <rostam98[m]!~rostam98m@2001:470:69fc:105::ca0e> has joined #yocto | 12:53 | |
| *** behanw[m] <behanw[m]!~behanwmat@2001:470:69fc:105::c96> has joined #yocto | 12:53 | |
| *** halstead[m] <halstead[m]!~halsteadm@2001:470:69fc:105::d0ef> has joined #yocto | 12:53 | |
| *** falk0n[m] <falk0n[m]!~falk0nmat@2001:470:69fc:105::ce60> has joined #yocto | 12:53 | |
| *** CarlesFernandez[ <CarlesFernandez[!~cfernande@2001:470:69fc:105::e590> has joined #yocto | 12:53 | |
| *** twinning[m] <twinning[m]!~twinningm@2001:470:69fc:105::e5db> has joined #yocto | 12:53 | |
| *** michaelo[m] <michaelo[m]!~michaelom@2001:470:69fc:105::d101> has joined #yocto | 12:53 | |
| *** k4wsys[m] <k4wsys[m]!~k4wsysmat@2001:470:69fc:105::e339> has joined #yocto | 12:53 | |
| *** ndec[m] <ndec[m]!~ndecmatri@2001:470:69fc:105::9c0> has joined #yocto | 12:53 | |
| *** batcha[m] <batcha[m]!~batcha88m@2001:470:69fc:105::dd0e> has joined #yocto | 12:53 | |
| *** jonesv[m] <jonesv[m]!~jonesvmat@2001:470:69fc:105::4616> has joined #yocto | 12:53 | |
| *** kranzo[m] <kranzo[m]!~kranzomat@2001:470:69fc:105::dd3e> has joined #yocto | 12:53 | |
| *** PascalBach[m] <PascalBach[m]!~bachpmatr@2001:470:69fc:105::1d3b> has joined #yocto | 12:53 | |
| *** dwagenk <dwagenk!~dwagenk@2001:470:69fc:105::103d> has joined #yocto | 12:53 | |
| *** florian_kc <florian_kc!~florian@port-217-146-132-69.static.as20676.net> has joined #yocto | 13:02 | |
| *** te_johan <te_johan!~te_johan@212-107-146-91.customers.ownit.se> has quit IRC (Remote host closed the connection) | 13:11 | |
| *** te_johan <te_johan!~te_johan@212-107-146-91.customers.ownit.se> has joined #yocto | 13:12 | |
| RP | kanavin: I sent a patch for it. rburton you're off the hook ;-) | 13:16 |
| kanavin | RP: cheers. qemu 6.1 update is ready too. | 13:17 |
| kanavin | RP: I'm generally going to focus on updates that AUH can't handle during the freeze period. | 13:18 |
| kanavin | RP: the ones that it can do can be done repeatedly until merge window reopens :) | 13:18 |
| kanavin | e.g. python 3.10 is coming | 13:18 |
| *** te_johan <te_johan!~te_johan@212-107-146-91.customers.ownit.se> has quit IRC (Ping timeout: 245 seconds) | 13:20 | |
| RP | kanavin: sounds good, thanks. I have wondered about even putting everything together on different branch | 13:22 |
| kanavin | RP: my stuff that's ready (or in active testing) is usually here http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=akanavin/package-version-updates | 13:23 |
| kanavin | 'qemu 6.1 wip' is now tested, I just need to write a proper commit message | 13:24 |
| RP | kanavin: I'll leave it for now but people generally ignore the freeze so we'll see what happens, I have to queue things somewhere | 13:25 |
| kanavin | RP: master-next-next? | 13:25 |
| RP | kanavin: or master-next2 | 13:26 |
| *** whuang0389 <whuang0389!~whuang038@2607:9880:2d78:22:e00d:f295:3005:6ffb> has joined #yocto | 13:33 | |
| zyga-mbp | hello | 13:46 |
| zyga-mbp | I'm trying to package a go program I'm trying to understand how to handle dependencies exactly | 13:46 |
| zyga-mbp | my -staticdev packages (which all use go-mod.bbclass) contain /usr/lib/go/pkg/mod/cache/ full of downloaded files from what should really be other packages | 13:47 |
| *** te_johan <te_johan!~te_johan@c-fc02225c.021-148-73746f7.bbcust.telenor.se> has joined #yocto | 13:47 | |
| zyga-mbp | am I doing this wrong by trying to package each dependency separately? | 13:47 |
| zyga-mbp | should I strive to remove pkg/mod from the -staticdev packages? (or change go-mod.bbclass) | 13:48 |
| zyga-mbp | right now I end up with clashes for files like "/usr/lib/go/pkg/mod/cache/download/github.com/kr/pty/@v/list" which are clearly an implementation detail of how go modules work internally | 13:48 |
| *** d0ku <d0ku!~d0ku@178.43.56.75.ipv4.supernova.orange.pl> has quit IRC (Ping timeout: 252 seconds) | 13:49 | |
| zyga-mbp | (cc agherzan for awareness) | 13:49 |
| *** tnovotny <tnovotny!~tnovotny@ip4-83-240-26-162.cust.nbox.cz> has joined #yocto | 13:51 | |
| *** te_johan <te_johan!~te_johan@c-fc02225c.021-148-73746f7.bbcust.telenor.se> has quit IRC (Ping timeout: 245 seconds) | 13:55 | |
| zeddii | zyga-mbp. there's no proper solution for go.mod yet. We need a fetcher module for go.mod processing, so we can properly get those dependencies, mirror, cache, license, etc, on them. | 14:01 |
| zyga-mbp | I've found some of the things I need in a meta-sca layer, it's built using a custom gosrc.bbclass | 14:02 |
| *** dvorkindmitry <dvorkindmitry!~dvorkindm@5.167.98.73> has joined #yocto | 14:02 | |
| zeddii | I've spent quite a bit of time working on a proper fetcher for it, or other ways to manually handle go.mod to generate SRC_URI entries, and I'm not happy with it. | 14:02 |
| zeddii | zyga-mbp, I've been through that as well, it won't really help what you want. | 14:02 |
| zeddii | well, it will a bit. | 14:02 |
| zeddii | but it's similar to what I've used for adding the depenencies on the SRC_URI as individual fetches. | 14:03 |
| zeddii | that can work, but it doesn't scale well, unless you automate it. | 14:03 |
| zeddii | but trying to package all the dependencies separately will fail, so you can throw out that idea :D | 14:03 |
| zyga-mbp | I'm entirely lost after a day of poking at the .bbclasses and trying various things | 14:03 |
| zyga-mbp | should I just package my top-level program and totally ignore the rest? | 14:04 |
| zyga-mbp | (making something that cannot be really built offline) | 14:04 |
| zeddii | if you don't care about it fetching things during the compile, and don't need mirroring, archiver, etc, you can do that. | 14:04 |
| zyga-mbp | while I'm very comfortable with go itself I'm not familiar with the details of how go modules are implemented by the toolchain, all the files that were clashing or were being added to the packages challenge my ignorance there | 14:05 |
| zyga-mbp | zeddii is there anyone working on this for the next release? anything I can try to align with | 14:06 |
| zeddii | I'm having a run at it :D | 14:06 |
| zyga-mbp | or backport something limited to an otherwise-dunfell layer to do sensible packages? | 14:07 |
| zeddii | since once go removes vendored support, we are absolutely hosed. | 14:07 |
| zyga-mbp | yeah | 14:07 |
| zyga-mbp | zeddii what are your plans for go-mod support? | 14:07 |
| zyga-mbp | and is the work in meta-sca useful or is it a dead end from your pov? | 14:08 |
| zeddii | zyga-mbp: there's a lot of 'it depends' on the packaging front. step 1 is getting the fetcher aware enough to get the sources, put them in downloads, setup the env so they are used first by go.mod, just for the build. | 14:08 |
| zeddii | not really useful there. | 14:08 |
| zyga-mbp | the mod format is quite elaborate | 14:08 |
| zeddii | step 2 are you building static, etc, then you don't even package up those depends. | 14:08 |
| zyga-mbp | it can use other versions than prescribed IIRC | 14:08 |
| zeddii | zyga-mbp, I spent 5 hours reading the docs, and yes, I concur :D | 14:09 |
| zyga-mbp | hmm, can you clarify what you mean by step 2? | 14:09 |
| zeddii | meaning, you don't care about packaging the dependencies, just ignore them, if the final app is statically linked, since it won't need them at runtime. I have many different go applications that we just statically link. We then queue the discussions about dynamic or static go apps ... | 14:10 |
| zeddii | but I'm not an expert in the bizarre go build process. My loathing of it is well documented :D | 14:11 |
| zeddii | I've searched in vain to see if there are any 3rd party parsers of go.mod, nothing I've found. So it will likely be a matter of letting go.mod doing it's thing in the fetch phase, grabbing the results of that, shuffling them into the right places for downloads, etc | 14:11 |
| zyga-mbp | I wonder if anything can be learned from fedora, debian or suse | 14:11 |
| zeddii | nothing that I've seen. | 14:12 |
| zyga-mbp | IIRC they do support go.mod builds now | 14:12 |
| zeddii | due to the different and non-cross builds. | 14:12 |
| zeddii | I checked buildroot as well, nothing super re-usable that I've seen. | 14:12 |
| zeddii | well, technically we can support go.mod builds as well, it's just wrong :D | 14:12 |
| zyga-mbp | is cross a big factor? I mean apart from CGO it's mostly effortless | 14:12 |
| zeddii | it's not the cross part, it's the host contamination part. | 14:13 |
| zeddii | and most of the things I build, are all CGO. | 14:13 |
| zyga-mbp | I see | 14:13 |
| zyga-mbp | I'll think about what to do | 14:14 |
| zyga-mbp | I'd love to help on go mod support, except that I have some commitments to fulfill first | 14:14 |
| zyga-mbp | zeddii thank you for the time and explanations | 14:15 |
| zeddii | I won't be digging into it until after the release myself. | 14:15 |
| zeddii | feel free to ping me if you start looking and we can coordinate. | 14:15 |
| zyga-mbp | which release? | 14:15 |
| zyga-mbp | ack, I'll surely will | 14:15 |
| zeddii | yocto 3.4 | 14:15 |
| zeddii | ~this October | 14:15 |
| zeddii | I lack some of the go knowledge, but have a lost of the rest. So I may ping you when I get lost in a moment of "what is go doing here" :D | 14:16 |
| *** mihai <mihai!~mihai@user/mihai> has quit IRC (Remote host closed the connection) | 14:18 | |
| *** Xagen <Xagen!~Xagen@2600:1700:211:7e60:f400:f0b8:e30b:7511> has quit IRC (Quit: Textual IRC Client: www.textualapp.com) | 14:19 | |
| *** sakoman <sakoman!~steve@172.243.4.16> has joined #yocto | 14:19 | |
| *** cocoJoe <cocoJoe!~cocoJoe@xb9b5dc3e.cust.hiper.dk> has joined #yocto | 14:32 | |
| *** Guest2 <Guest2!~Guest2@145.253.222.69> has joined #yocto | 14:36 | |
| Guest2 | Hi, I actually use dunfell. Now I've experienced a bug in the freescale network driver. Do you think it's easy to update the driver to today's version without updating the whole yocto version? | 14:38 |
| Guest2 | Or is it better to update to a newer yocto release as a whole? | 14:39 |
| Guest2 | Partial update vs. full update, so to speak | 14:39 |
| Guest2 | for instance I saw many changes and fixes in https://github.com/torvalds/linux/commits/master/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c | 14:41 |
| *** obcecado <obcecado!pcaetano@tilde.institute> has quit IRC (Ping timeout: 248 seconds) | 14:45 | |
| *** obcecado <obcecado!pcaetano@tilde.institute> has joined #yocto | 14:46 | |
| JPEW | sgw: I suspect we need to skip the package creation code in create-sdpx.bbclass in cases where no packages are actually created (e.g. native). I'm not sure the best way to do that | 14:51 |
| JPEW | Although.... I thought we were already doing that, since we call oe.packagedata.packaged in the loop where we create the package SPDX files :/ | 14:53 |
| JPEW | sgw: Ah, OK. That error comes from read_subpackage_metadata itself, which we always call unconditionally so that we have the correct view of the packages | 14:57 |
| sgw | JPEW: Not sure which is why I took the approach. I probably should have shared that with you. | 14:57 |
| sgw | earlier | 14:57 |
| *** Xagen <Xagen!~Xagen@2600:1700:211:7e60:b869:5fbf:c91b:c911> has joined #yocto | 15:02 | |
| Xagen | how do you fix devtool when you get `ERROR: Something went wrong with source extraction - the devtool-source class was not active or did not function correctly`? | 15:02 |
| *** goliath <goliath!~goliath@user/goliath> has quit IRC (Quit: SIGSEGV) | 15:05 | |
| *** eduardas <eduardas!~eduardas@93.93.57.5> has quit IRC (Quit: Konversation terminated!) | 15:05 | |
| *** d0ku <d0ku!~d0ku@178.43.56.75.ipv4.supernova.orange.pl> has joined #yocto | 15:07 | |
| *** tnovotny <tnovotny!~tnovotny@ip4-83-240-26-162.cust.nbox.cz> has quit IRC (Quit: Leaving) | 15:10 | |
| *** Guest2 <Guest2!~Guest2@145.253.222.69> has quit IRC (Quit: Guest2) | 15:18 | |
| *** rber|res <rber|res!~rber|res@ppp-94-66-232-217.home.otenet.gr> has joined #yocto | 15:18 | |
| *** eduardas <eduardas!~eduardas@93.93.57.5> has joined #yocto | 15:19 | |
| vmeson | tlwoerner: where is this pseudo, seccomp thread? | 15:23 |
| rburton | vmeson: https://sourceware.org/pipermail/libc-help/2021-August/005985.html | 15:24 |
| vmeson | rburton: thanks | 15:26 |
| *** rfuentess <rfuentess!~rfuentess@amarseille-656-1-20-91.w81-251.abo.wanadoo.fr> has quit IRC (Remote host closed the connection) | 15:28 | |
| rburton | last post in the thread is a @gentoo account but mentions we and CrOS, so presumably is a googler | 15:28 |
| tlwoerner | vmeson: libc-help mailing list | 15:29 |
| *** vd <vd!~vd@bras-base-mtrlpq2848w-grc-41-70-53-240-121.dsl.bell.ca> has joined #yocto | 15:35 | |
| *** DataDrake|zzz <DataDrake|zzz!~DataDrake@solus/team/DataDrake> has joined #yocto | 15:38 | |
| *** DataDrake|zzz is now known as DataDrake | 15:39 | |
| DataDrake | I think zyga-mbp stepped away, but regarding his tweet about go modules in bitbake, there's an easier solution. upstream could generate tarballs with vendored deps easily enough: https://golang.org/ref/mod#go-mod-vendor | 15:40 |
| vmeson | fyi migration guide: https://docs.yoctoproject.org/migration-guides/migration-3.4.html#override-syntax-changes | 15:41 |
| zeddii | DataDrake, yes. that's the same approach we we talking about. | 15:41 |
| DataDrake | ah, great minds think alike | 15:41 |
| zeddii | but the complications start to arrive when we move it into a fetcher/downloads format and get the env setup properly for builds that may not be vendored | 15:42 |
| DataDrake | that's fair. I figured it might be a reasonable request of upstream to generate the tarballs like this and am looking into doing it myself, personally | 15:44 |
| zeddii | it solves licensing issues, and avoid needing to process go.mod (which no sane person would do), and then we arrive at the getting it used by the build parts, which are the same regardless of how we get the sourced into the sysroot | 15:45 |
| DataDrake | I think I follow | 15:46 |
| DataDrake | we have a similar system in Solus where we use a chroot container to perform isolated builds and we definitely prefer to not need networking enabled wherever possible. for us the major "offenders" are Go, Rust, Node, and Java stuff. | 15:48 |
| zeddii | the usual criminals, yes :D | 15:49 |
| zeddii | we need something in place for go before they remove go mod vendor'd build. things get painful then | 15:50 |
| DataDrake | oh shoot, I didn't realize that was on the chopping block | 15:50 |
| zyga-mbp | DataDrake hey! | 15:52 |
| *** te_johan <te_johan!~te_johan@c-fc02225c.021-148-73746f7.bbcust.telenor.se> has joined #yocto | 15:52 | |
| DataDrake | hi :) | 15:53 |
| zeddii | most of the complex go builds I support, we've set GO111MODULE=off (with vendor being the second choice). When that goes away, we need a full go mod solution. That's mainly what I'm referring to. | 15:53 |
| zyga-mbp | DataDrake I'm trying to wrap my head around things but my strongest argument so far (with myself) is that we need to make both yocto and go sides happy, and that's mainly around fetcher, without getting the very complex problem in the way (multi-version), while, and this is probably more important to my corporate life than to most, having clear license situation | 15:54 |
| *** eduardas <eduardas!~eduardas@93.93.57.5> has quit IRC (Quit: Konversation terminated!) | 15:54 | |
| zyga-mbp | I lean towards building apps, not libraries, fetching the code with `go download` somehow and still tying into the license checker | 15:54 |
| DataDrake | I definitely don't have a straight answer for licensing, that's hard | 15:54 |
| zyga-mbp | but those are early thoughts from a walk in the park | 15:55 |
| zyga-mbp | I need more time to research this | 15:55 |
| DataDrake | go mod vendor feels like a good half-way measure, but I realize that Go modules have been a bit of a moving target | 15:56 |
| zyga-mbp | given that go has nice tooling and libraries for working with modules I think the best solution will work based on those, without re-inventing the wheel | 15:56 |
| DataDrake | yeah, there might be some deeper magics in there somewhere | 15:56 |
| zyga-mbp | I read https://golang.org/ref/mod briefly | 15:57 |
| zyga-mbp | it's certainly complex | 15:57 |
| zyga-mbp | I wonder if things like patching are sensible in this case | 15:57 |
| zyga-mbp | given that bitbake doesn't (seem to, please correct me if I'm wrong) do multi-version things | 15:57 |
| DataDrake | you honestly might have a better time of working with them to find something that works | 15:57 |
| DataDrake | they may not have remotely considered this sort of thing | 15:58 |
| agherzan | I guess the problem is the same as with the rust projects | 15:58 |
| zyga-mbp | I was trying to package a single binary with a check.v1 dependency | 15:58 |
| zyga-mbp | and realized that internally chec.v1 depends on two versions of the same package | 15:58 |
| zyga-mbp | because various dependencies pinned different versions for their own testing | 15:59 |
| DataDrake | yeah, that's pretty common | 15:59 |
| zyga-mbp | only a fetcher that can understand go.mod properly would untangle that | 15:59 |
| zyga-mbp | and build the (single, more recent) version of the dependency | 15:59 |
| zyga-mbp | but there's a lot of other details, like the sum database and the proxy files and the list files | 15:59 |
| zyga-mbp | so I just need a moment to constrain this in my head | 16:00 |
| zyga-mbp | anything that is impossible is not worth doing | 16:00 |
| zyga-mbp | what remains must be right | 16:00 |
| zyga-mbp | hey agherzan :) | 16:00 |
| *** te_johan <te_johan!~te_johan@c-fc02225c.021-148-73746f7.bbcust.telenor.se> has quit IRC (Ping timeout: 256 seconds) | 16:00 | |
| zeddii | in my travels, there's no real way to shoot for re-use (in a packaging sense) of any of the dependencies. | 16:00 |
| zyga-mbp | I don't really want re-use, I want compliance and correctness | 16:00 |
| zyga-mbp | and not to cheat offline buillds | 16:01 |
| agherzan | zyga-mbp: There is no need for reuse at this point to be honest - for your specific usecase | 16:01 |
| zyga-mbp | (that's just robustness over time) | 16:01 |
| agherzan | Compliance on the other hand... | 16:01 |
| zyga-mbp | agherzan agree | 16:01 |
| zyga-mbp | *agreed | 16:01 |
| zyga-mbp | yeah, licensing is important | 16:01 |
| zeddii | that's what I mean. you just need to get them fetched and put into downloads in the right format, so they are available when go mod goes looking during the build, or you can otherwise get them into the sysroot. | 16:01 |
| zeddii | but considering them as anything more than source, is pretty much doomed. | 16:02 |
| DataDrake | I personally went down this route with Haskell on Solus, it was not fun and I still don't know if I made the right decision | 16:02 |
| zyga-mbp | agherzan as a data point, I found this: https://github.com/priv-kweihmann/meta-sca/tree/14900f6eca1aa7b70197379cfb9395542cb1277c/recipes-go -- it's a huge lot of auto-generated recipes that use custom gosrc.bbclass | 16:02 |
| zyga-mbp | DataDrake what did you end up doing? | 16:03 |
| DataDrake | apparently what everyone else thinks is the wrong thing lol | 16:03 |
| *** florian_kc <florian_kc!~florian@port-217-146-132-69.static.as20676.net> has quit IRC (Ping timeout: 245 seconds) | 16:03 | |
| DataDrake | I use cabal to handle the build process and have individually packaged the deps | 16:03 |
| DataDrake | Macros: https://github.com/getsolus/ypkg/blob/f0bc1356ad62740e6edcbac4c59e23c36fae46bd/ypkg2/rc.yml#L75 | 16:04 |
| DataDrake | Example pkg: https://dev.getsol.us/source/haskell-stack/browse/master/package.yml | 16:05 |
| DataDrake | networking is on because we were still on an older version of cabal that couldn't do offline yet | 16:05 |
| *** rcw <rcw!~rcwoolley@45.72.203.103> has joined #yocto | 16:05 | |
| DataDrake | Setup.hs doesn't resolve dependencies which I found annoying | 16:05 |
| *** agherzan <agherzan!~agherzan@2001:470:69fc:105::e1fe> has left #yocto | 16:06 | |
| DataDrake | whereas Cabal does that and more | 16:06 |
| *** agherzan <agherzan!~agherzan@2001:470:69fc:105::e1fe> has joined #yocto | 16:06 | |
| *** agherzan <agherzan!~agherzan@2001:470:69fc:105::e1fe> has left #yocto | 16:06 | |
| *** agherzan <agherzan!~agherzan@2001:470:69fc:105::e1fe> has joined #yocto | 16:06 | |
| zyga-mbp | DataDrake does haskel have multi-version libraries? | 16:07 |
| zyga-mbp | or is the ecosystem smaller / more stable? | 16:07 |
| DataDrake | it can actually | 16:07 |
| zyga-mbp | (go is notoriously fragmented IMO) | 16:07 |
| agherzan | The more I think about it, the more I find the per mod recipe approach unfeasible zyga-mbp | 16:07 |
| zyga-mbp | what do you do about them? | 16:07 |
| zyga-mbp | agherzan I really agree | 16:07 |
| zyga-mbp | I think a tool-based approach that can create a recipe and extract, recursively, all the licenses is required | 16:08 |
| zyga-mbp | agherzan so only apps are packagec | 16:08 |
| zyga-mbp | *packaged | 16:08 |
| zeddii | 'er yah. | 16:08 |
| agherzan | Yes. | 16:08 |
| zyga-mbp | the downside is that you cannot patch anything | 16:08 |
| DataDrake | I honestly don't lol. I hold things back if I need to and sometimes I even patch the .cabal files to allow newer versions that were tested on hackage | 16:08 |
| zeddii | run away from creating recipes. | 16:08 |
| agherzan | We need to sort out the licensing part of it. | 16:08 |
| zeddii | it won't scale, and you'll have thousands | 16:08 |
| agherzan | Exactly. | 16:08 |
| zyga-mbp | yes | 16:08 |
| zyga-mbp | even fedora caved a little | 16:08 |
| agherzan | How did the rust guys do this? | 16:09 |
| zyga-mbp | for the record, fedora still requires you to tell about each bundled package | 16:09 |
| agherzan | How do they handle the license in the bitbake recipes? | 16:09 |
| zyga-mbp | but not package them separately | 16:09 |
| DataDrake | I think we are sort of getting to the point where networked builds are unavoidable and I definitely don't have a one-size-fits-all answer to that | 16:09 |
| agherzan | Could it be that https://github.com/meta-rust/meta-rust/blob/master/recipes-example/rustfmt/rustfmt_1.4.2.bb#L165 is the sum of all the licenses? | 16:10 |
| zyga-mbp | that would be.. extremely convenient! | 16:10 |
| *** mihai <mihai!~mihai@user/mihai> has joined #yocto | 16:11 | |
| zyga-mbp | agherzan given that REUSE guys asked me to create a custom license to express 3-clause BSD license with a specific copyright as a custom spdx entry | 16:11 |
| vmeson | tlwoerner: or anyone interested, you mihgt take a look at: https://pink.exherbo.org— seccomp-bpf and seccomp-notify based application sandbox https://github.com/sydbox | 16:11 |
| agherzan | I'm wondering if crate-bitbake queries the license for all crates and sets that correctly. | 16:11 |
| zyga-mbp | seccom-notify is nice! | 16:11 |
| zyga-mbp | agherzan I would not be surprised if it was broken | 16:12 |
| zyga-mbp | but I'm drained today, I'm off to read a book | 16:12 |
| vmeson | agherzan: Could be, I'm not sure if the meta-rust folks have been particularily attentive to licensing. | 16:12 |
| zyga-mbp | I'll collect my thoughts tomorrow | 16:12 |
| agherzan | zyga-mbp: a Go book? :) | 16:12 |
| zyga-mbp | it was nice to see you again DataDrake :-) | 16:12 |
| DataDrake | adding license information to the go.mod wouldn't be rocket science I don't think | 16:12 |
| zyga-mbp | agherzan no, bee keeper manual | 16:12 |
| DataDrake | you too zyga-mbp! | 16:12 |
| zyga-mbp | DataDrake go.mod is strictly managed by the compiler | 16:12 |
| zyga-mbp | it's probably not the best place for license data | 16:13 |
| DataDrake | I meant more as a "hey go devs, can we have this?" | 16:13 |
| DataDrake | go.mod specified the license for the current module and then can harvest from the deps | 16:13 |
| agherzan | Let's just drop mod for now. And use the License as the sum of all dependencies. | 16:13 |
| zyga-mbp | given how go handled vendoring (heavy handed) I doubt it would work without someone at google really paying attention | 16:13 |
| zyga-mbp | agherzan .mod cannot be dropped | 16:14 |
| agherzan | Ideally, done with something similarly to https://docs.rs/crate/cargo-bitbake/0.3.15 | 16:14 |
| zyga-mbp | anyway, I'm off, more tomorrow :) | 16:14 |
| DataDrake | yeah, just brainstorming | 16:14 |
| agherzan | zyga-mbp: mod as in the mod class. | 16:15 |
| zyga-mbp | ah | 16:15 |
| zyga-mbp | it actually works fine for apps alone | 16:15 |
| zyga-mbp | we just need to get the license data in | 16:15 |
| zyga-mbp | it's unable to handle deps / libraries | 16:15 |
| zyga-mbp | so we can package just the top-level package | 16:15 |
| agherzan | Exactly | 16:15 |
| agherzan | Let's do that and see how to handle the licensing. | 16:16 |
| *** frieder <frieder!~frieder@170-77-142-46.pool.kielnet.net> has quit IRC (Remote host closed the connection) | 16:16 | |
| DataDrake | that's why I was thinking of proposing it to the Go devs, to help out | 16:16 |
| zyga-mbp | DataDrake I think it's certainly opening a conversation | 16:17 |
| DataDrake | if rustfmt can do it and Go is statically linked by default, there's compelling justification for it | 16:17 |
| *** goliath <goliath!~goliath@user/goliath> has joined #yocto | 16:17 | |
| DataDrake | s/rustfmt/cargo | 16:19 |
| agherzan | I like that. | 16:19 |
| *** jwillikers <jwillikers!~jwilliker@ics141-1.icsincorporated.com> has quit IRC (Remote host closed the connection) | 16:19 | |
| *** jwillikers <jwillikers!~jwilliker@ics141-1.icsincorporated.com> has joined #yocto | 16:21 | |
| *** tp43_ <tp43_!~ndeem@2001:1970:502b:d701:a199:1a3e:abd1:ac4c> has joined #yocto | 16:22 | |
| *** florian <florian!~florian@port-217-146-132-69.static.as20676.net> has quit IRC (Quit: Ex-Chat) | 16:26 | |
| *** splatch <splatch!~lukasz@2.ip-54-38-52.eu> has quit IRC (Read error: Connection reset by peer) | 16:26 | |
| mihai | https://www.gentoo.org/support/news-items/2021-08-24-eudev-retirement.html | 16:26 |
| *** argonautx <argonautx!~argonautx@i5E86705F.versanet.de> has quit IRC (Quit: Leaving) | 16:27 | |
| rburton | hang on is that saying that gentoo are using our musl patches for systemd to build systemd's udev for non-glibc platforms | 16:31 |
| *** tp43_ <tp43_!~ndeem@2001:1970:502b:d701:a199:1a3e:abd1:ac4c> has quit IRC (Ping timeout: 252 seconds) | 16:31 | |
| *** Tokamak <Tokamak!~Tokamak@107.117.203.34> has joined #yocto | 16:35 | |
| mihai | or OE submitted those patches to eudev, as I understand it | 16:36 |
| *** jwillikers <jwillikers!~jwilliker@ics141-1.icsincorporated.com> has quit IRC (Quit: jwillikers) | 16:36 | |
| RP | that is 404 for me? :/ | 16:37 |
| *** jwillikers <jwillikers!~jwilliker@ics141-1.icsincorporated.com> has joined #yocto | 16:37 | |
| mihai | try this https://archives.gentoo.org/gentoo-dev/message/dff4bf35636efef95f6d7926823b4e8d | 16:40 |
| mihai | although the first link should also work | 16:40 |
| mihai | oh wait, it's saying that thanks to OE | 16:43 |
| mihai | 's patches on udev, musl is now working with systemd | 16:44 |
| mihai | right | 16:51 |
| mihai | nvm | 16:51 |
| *** DataDrake <DataDrake!~DataDrake@solus/team/DataDrake> has left #yocto (Leaving) | 16:51 | |
| mihai | https://gitweb.gentoo.org/repo/gentoo.git/tree/sys-fs/udev/udev-249-r2.ebuild#n24 | 16:51 |
| mihai | rburton: ^^ | 16:51 |
| *** leon-anavi <leon-anavi!~Leon@78.130.197.211> has quit IRC (Quit: Leaving) | 17:12 | |
| *** amitk <amitk!~amit@103.208.71.148> has quit IRC (Ping timeout: 252 seconds) | 17:17 | |
| *** te_johan <te_johan!~te_johan@c-fc02225c.021-148-73746f7.bbcust.telenor.se> has joined #yocto | 17:19 | |
| rber|res | Is it a known issue, that latest and greatest master does not build pkgconfig-native? | 17:25 |
| *** zyga-mbp <zyga-mbp!~zyga@178.182.246.167.nat.umts.dynamic.t-mobile.pl> has quit IRC (Ping timeout: 252 seconds) | 17:26 | |
| rber|res | https://pastebin.com/4DiYnBkv | 17:27 |
| *** te_johan <te_johan!~te_johan@c-fc02225c.021-148-73746f7.bbcust.telenor.se> has quit IRC (Ping timeout: 245 seconds) | 17:27 | |
| *** zyga-mbp <zyga-mbp!~zyga@31.0.173.147> has joined #yocto | 17:30 | |
| *** te_johan <te_johan!~te_johan@c-fc02225c.021-148-73746f7.bbcust.telenor.se> has joined #yocto | 17:38 | |
| *** rburton <rburton!rburton@user/rburton> has quit IRC (Ping timeout: 250 seconds) | 17:45 | |
| *** rburton <rburton!rburton@user/rburton> has joined #yocto | 17:47 | |
| rber|res | Wow it seems to be a problem with running it in an unprivileged container ;) | 17:49 |
| *** bps <bps!~bps@user/bps> has quit IRC (Ping timeout: 250 seconds) | 17:51 | |
| JaMa | rber|res: yes https://bugzilla.yoctoproject.org/show_bug.cgi?id=14519 | 17:58 |
| rber|res | JaMa, Thanks! | 17:59 |
| *** Tokamak <Tokamak!~Tokamak@107.117.203.34> has quit IRC (Ping timeout: 244 seconds) | 18:04 | |
| vd | hi there -- in a device tree, how can I attach a pinmux config not related to a specific node? (i.e. these are gpio pins hog) | 18:05 |
| vd | Is there a way to create a dummy node to attach the pinctrl-0 to maybe? | 18:05 |
| *** jmiehe <jmiehe!~Thunderbi@user/jmiehe> has joined #yocto | 18:06 | |
| *** Tokamak <Tokamak!~Tokamak@172.58.187.83> has joined #yocto | 18:08 | |
| rburton | mihai: the patches that we mark with DON'T USE THESE? | 18:09 |
| mihai | :)) | 18:13 |
| mihai | rburton: I guess so | 18:13 |
| *** LetoThe2nd <LetoThe2nd!uid453638@id-453638.highgate.irccloud.com> has quit IRC (Quit: Connection closed for inactivity) | 18:16 | |
| *** Tokamak <Tokamak!~Tokamak@172.58.187.83> has quit IRC (Read error: Connection reset by peer) | 18:18 | |
| *** Tokamak <Tokamak!~Tokamak@107.117.203.50> has joined #yocto | 18:26 | |
| *** zyga-mbp <zyga-mbp!~zyga@31.0.173.147> has quit IRC (Ping timeout: 252 seconds) | 18:31 | |
| *** zyga-mbp <zyga-mbp!~zyga@31.0.173.147> has joined #yocto | 18:35 | |
| *** xtopher_ <xtopher_!sid495823@id-495823.tinside.irccloud.com> has quit IRC (Ping timeout: 240 seconds) | 18:38 | |
| *** JPEW <JPEW!sid500061@id-500061.helmsley.irccloud.com> has quit IRC (Ping timeout: 240 seconds) | 18:38 | |
| *** rmmr <rmmr!sid240755@id-240755.helmsley.irccloud.com> has quit IRC (Ping timeout: 240 seconds) | 18:38 | |
| *** JPEW <JPEW!sid500061@id-500061.helmsley.irccloud.com> has joined #yocto | 18:38 | |
| *** xtopher_ <xtopher_!sid495823@id-495823.tinside.irccloud.com> has joined #yocto | 18:38 | |
| *** rmmr <rmmr!sid240755@id-240755.helmsley.irccloud.com> has joined #yocto | 18:38 | |
| *** Tokamak <Tokamak!~Tokamak@107.117.203.50> has quit IRC (Ping timeout: 252 seconds) | 18:41 | |
| *** JosefHolzmayr[m] <JosefHolzmayr[m]!~theyoctoj@2001:470:69fc:105::e785> has joined #yocto | 19:01 | |
| JosefHolzmayr[m] | yo dudX | 19:02 |
| JosefHolzmayr[m] | ah, thats how it looks from this side. | 19:02 |
| mihai | yo | 19:06 |
| mihai | from this side | 19:06 |
| * JosefHolzmayr[m] is just tinkering with Matrix/Element | 19:11 | |
| *** yannd <yannd!~yann@88.120.44.86> has quit IRC (Ping timeout: 244 seconds) | 19:17 | |
| *** goliath <goliath!~goliath@user/goliath> has quit IRC (Quit: SIGSEGV) | 19:25 | |
| *** yannd <yannd!~yann@88.120.44.86> has joined #yocto | 19:29 | |
| *** cocoJoe <cocoJoe!~cocoJoe@xb9b5dc3e.cust.hiper.dk> has quit IRC (Quit: Client closed) | 19:36 | |
| whuang0389 | noob linux question. can I use install command to copy a folder over? | 19:42 |
| nohit | hi, does yocto work on WSL2 ? | 19:47 |
| RP | nohit: basically yes but see the notes in the docs | 19:49 |
| nohit | ok thx | 19:52 |
| *** bps <bps!~bps@80.71.142.18.ipv4.parknet.dk> has joined #yocto | 19:58 | |
| JosefHolzmayr[m] | @whu | 20:00 |
| JosefHolzmayr[m] | whuang0389 nope, such needs cp. check the existing recipes for examples, its important to get uid/gid and permissions right. | 20:01 |
| whuang0389 | thanks! | 20:04 |
| *** goliath <goliath!~goliath@user/goliath> has joined #yocto | 20:12 | |
| RP | vmeson: I did quickly poke at centos7 again. What is really odd is that it claims it is running "/home/pokybuild/yocto-worker/reproducible-centos/build/build-st/tmp/work/x86_64-linux/cargo-native/1.54.0-r0/wrapper/target-rust-ccld" and it fails yet I've edited that script and it isn't being run | 20:30 |
| vmeson | RP: that's more progress that I've had. I'm wrestling with docker. I guess I could use one of the yocto.io boxes, but I prefer not to do that. | 20:34 |
| *** amitk <amitk!~amit@103.208.71.148> has joined #yocto | 20:35 | |
| RP | vmeson: I'm just using one of them... | 20:35 |
| vmeson | yeah, if I don't wrestle docker to the ground, I'll do the same after dinner. | 20:36 |
| *** amitk <amitk!~amit@103.208.71.148> has quit IRC (Ping timeout: 252 seconds) | 20:52 | |
| *** rewitt3 <rewitt3!~rewitt@134.134.137.82> has quit IRC (Remote host closed the connection) | 21:19 | |
| *** rewitt3 <rewitt3!~rewitt@134.134.139.87> has joined #yocto | 21:19 | |
| RP | vmeson: I'm starting to wonder if the rust binaries are too old to run on the centos7 kernel :/ | 21:27 |
| RP | er, too new | 21:27 |
| smurray | heh, had me scratching my head there for a sec | 21:29 |
| *** rewitt3 <rewitt3!~rewitt@134.134.139.87> has quit IRC (Remote host closed the connection) | 21:37 | |
| *** rewitt3 <rewitt3!~rewitt@134.134.139.80> has joined #yocto | 21:37 | |
| RP | vmeson: I think what happens is that the ccld wrapper has a #!/bin/sh and that causes it to execve() /bin/sh. That links to libtinfo and it finds the sysroot one rather than the system one, which then can't find the libc it wants since it is using the system interpreter/loader rather than the uninative one which knows where our C lib is | 21:50 |
| RP | only happens on centos7 as there are big differences between the system libs and buildtools/uninative | 21:52 |
| RP | think the unknown syscall is clone3 and a red herring | 21:54 |
| *** rewitt3 <rewitt3!~rewitt@134.134.139.80> has quit IRC (Remote host closed the connection) | 21:58 | |
| * RP gives in to sleep | 21:58 | |
| *** rewitt3 <rewitt3!~rewitt@134.134.139.80> has joined #yocto | 21:58 | |
| *** zyga-mbp <zyga-mbp!~zyga@31.0.173.147> has quit IRC (Ping timeout: 244 seconds) | 22:07 | |
| *** zyga-mbp <zyga-mbp!~zyga@31.0.173.147> has joined #yocto | 22:10 | |
| *** whuang0389 <whuang0389!~whuang038@2607:9880:2d78:22:e00d:f295:3005:6ffb> has quit IRC (Ping timeout: 256 seconds) | 22:30 | |
| *** rber|res <rber|res!~rber|res@ppp-94-66-232-217.home.otenet.gr> has quit IRC (Ping timeout: 252 seconds) | 22:33 | |
| *** florian_kc <florian_kc!~florian@dynamic-093-131-096-150.93.131.pool.telefonica.de> has joined #yocto | 22:34 | |
| *** tp43_ <tp43_!~ndeem@2001:1970:502b:d701:a199:1a3e:abd1:ac4c> has joined #yocto | 22:45 | |
| *** r4ge <r4ge!~timp@114-134-7-183.static.lightwire.co.nz> has joined #yocto | 22:50 | |
| *** rber|res <rber|res!~rber|res@ppp-2-86-147-203.home.otenet.gr> has joined #yocto | 22:52 | |
| *** dev1990 <dev1990!~dev@dynamic-78-8-55-226.ssp.dialog.net.pl> has quit IRC (Quit: Konversation terminated!) | 22:56 | |
| *** tp43_ <tp43_!~ndeem@2001:1970:502b:d701:a199:1a3e:abd1:ac4c> has quit IRC (Ping timeout: 252 seconds) | 23:06 | |
| *** manuel_ <manuel_!~manuel198@185.68.248.44> has joined #yocto | 23:24 | |
| *** manuel1985 <manuel1985!~manuel198@2a02:1748:dd5c:f290:7848:b419:eae2:e315> has quit IRC (Ping timeout: 252 seconds) | 23:26 | |
| *** goliath <goliath!~goliath@user/goliath> has quit IRC (Quit: SIGSEGV) | 23:27 | |
| *** florian_kc <florian_kc!~florian@dynamic-093-131-096-150.93.131.pool.telefonica.de> has quit IRC (Ping timeout: 252 seconds) | 23:36 | |
| *** tp43_ <tp43_!~ndeem@2001:1970:502b:d701:a199:1a3e:abd1:ac4c> has joined #yocto | 23:53 | |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!