| dl9pf | rpm metadata ... some hashes and the BUILDTIME ... all in the rpm header | 00:04 |
|---|---|---|
| *** ayoung <ayoung!~ayoung@2601:19c:4680:ee30::83cb> has quit IRC | 00:04 | |
| *** bps <bps!~bps@80.71.142.18> has quit IRC | 00:07 | |
| *** ayoung <ayoung!~ayoung@2601:19c:4680:ee30::83cb> has joined #yocto | 00:13 | |
| *** adelcast1 <adelcast1!~adelcast@2603-8080-1e08-7cd8-823f-5dff-fe15-cf0d.res6.spectrum.com> has joined #yocto | 00:17 | |
| dl9pf | SIGMD5, SHA1HEADER, SHA256HEADER, BUILDTIME ... everything else is fine | 00:24 |
| *** linums <linums!~linums@84.198.214.27> has quit IRC | 00:24 | |
| *** Dracos-Carazza <Dracos-Carazza!~Dracos-Ca@94.31.101.91> has quit IRC | 00:24 | |
| *** linums <linums!~linums@apn-94-44-121-7.vodafone.hu> has joined #yocto | 00:24 | |
| fray | ya, it's important when checking RPMs on a rebuild to only diff the actual contents that are not actually package specific.. | 00:25 |
| fray | for security purposes packages do get information when they were built to avoid 'look-alikes' | 00:25 |
| fray | it might be possible set those values -- but if you are actually building them then you wanted a new one for some reason. | 00:25 |
| fray | From a 'diff' perspective, there is an rpm-diff somewhere.. which will avoid the signatures and buildtime.. (or at least used to) so you can look for equivalency | 00:26 |
| dl9pf | uff ... https://github.com/rpm-software-management/rpm/issues/1467 | 00:27 |
| *** Dracos-Carazza <Dracos-Carazza!~Dracos-Ca@94.31.101.91> has joined #yocto | 00:28 | |
| fray | I've done things with RPM if FIPS mode before.. it's not as hard as people think.. | 00:31 |
| *** zeddii <zeddii!~zeddii@cpe04d4c4975b80-cm64777d5e8820.cpe.net.cable.rogers.com> has quit IRC | 00:31 | |
| fray | FIPS doesn't say you can have MD5 or SHA1.. it says you can't use them in security critical components. | 00:31 |
| fray | So for RPM, you would need to document where they are used, and that they are NOT security critical. And then provide an implementation of the functions that can ONLY be used in those particular places and not "general usafge" | 00:32 |
| *** adelcast1 <adelcast1!~adelcast@2603-8080-1e08-7cd8-823f-5dff-fe15-cf0d.res6.spectrum.com> has quit IRC | 00:32 | |
| fray | This is no different then other protocols that require md5 hashes or sha1 hashes.. again not for security but for 'magic numbers', as security should be handled with other methods | 00:32 |
| *** mrc3 <mrc3!~mrc3@linaro/mrc3> has quit IRC | 00:33 | |
| dl9pf | i mean in 'this will stick around for quite some' | 00:33 |
| *** adelcast1 <adelcast1!~adelcast@2603-8080-1e08-7cd8-823f-5dff-fe15-cf0d.res6.spectrum.com> has joined #yocto | 00:33 | |
| fray | it will that is what happens when you have an installed base.. | 00:33 |
| fray | the work to dump MD5SUM and SHA1 _started_ almost 10 years ago | 00:34 |
| dl9pf | so basically our diff needs to adapt and skip these | 00:34 |
| fray | Red Hat though rejected many of the changes for various reasons (good and bad) | 00:34 |
| fray | yes, there is already an 'rpm-diff' that will skip those headers (or there was last time I used it) | 00:34 |
| dl9pf | https://github.com/kholia/ReproducibleBuilds/blob/master/rpm-compare | 00:34 |
| dl9pf | or rpm-diff | 00:35 |
| RP | dl9pf: We really do want deterministic rpms. Can we not set BUILDTIME to SOURCE_DATE_EPOCH? | 00:35 |
| fray | that is what I'd recommend.. but I do question why we are rebuilding RPMs (if they're already cached).. | 00:35 |
| fray | if the input to the RPM (binaries and metadata) are different.. then we know the RPM will be different.. If they are the same, then we know the RPM output is the same (except for those fiends) | 00:36 |
| fray | 'er.. fields | 00:36 |
| *** leon-anavi <leon-anavi!~Leon@78.130.197.211> has quit IRC | 00:36 | |
| fray | RPM itself should never be generating specific output, only packaging. Considering under the hood it's a compresses cpio with additional metadata (the header) | 00:37 |
| RP | fray: the input is the same. We just need to find a way to be able to set those fields the same too and then this should work | 00:38 |
| RP | dl9pf: keep in mind we can patch rpm if needed | 00:38 |
| RP | prefer not to obviously | 00:38 |
| fray | the hashes are just that, hashes. So if something changes in the header they'll change.. we can't "set" them.. or validation will fail.. | 00:38 |
| fray | the date is the only piece we really can set.. | 00:38 |
| RP | fray: so it might just be BUILDTIME and if we have to patch it to set that... | 00:39 |
| fray | yes | 00:39 |
| * RP -> Zzzz | 00:40 | |
| fray | night | 00:40 |
| dl9pf | ok, let's ponder tomorrow about BUILDTIME | 00:42 |
| fray | (for FIPS, integrity validation can still used unapproved hashes, but must be backed up by an approved mechanism. This is where package signatures come in as the 'approved' backup) | 00:45 |
| *** aquijoule__ <aquijoule__!~richbridg@089144195127.atnat0004.highway.a1.net> has joined #yocto | 00:46 | |
| *** zeddii <zeddii!~zeddii@cpef4c11490699d-cmf4c11490699b.cpe.net.cable.rogers.com> has joined #yocto | 00:48 | |
| *** linums <linums!~linums@apn-94-44-121-7.vodafone.hu> has quit IRC | 00:48 | |
| *** aquijoule_ <aquijoule_!~richbridg@089144195127.atnat0004.highway.a1.net> has quit IRC | 00:48 | |
| *** linums <linums!~linums@84.198.214.27> has joined #yocto | 00:48 | |
| *** csd <csd!~csd@78.80.197.35.bc.googleusercontent.com> has quit IRC | 00:49 | |
| *** csd <csd!~csd@78.80.197.35.bc.googleusercontent.com> has joined #yocto | 00:49 | |
| *** zeddii <zeddii!~zeddii@cpef4c11490699d-cmf4c11490699b.cpe.net.cable.rogers.com> has quit IRC | 00:55 | |
| *** adelcast1 <adelcast1!~adelcast@2603-8080-1e08-7cd8-823f-5dff-fe15-cf0d.res6.spectrum.com> has quit IRC | 00:55 | |
| *** zeddii <zeddii!~zeddii@cpe04d4c4975b80-cmf4c11490699b.cpe.net.cable.rogers.com> has joined #yocto | 00:57 | |
| *** intera91 <intera91!521f818d@cpc142184-mcam2-2-0-cust140.18-3.cable.virginm.net> has quit IRC | 01:13 | |
| *** andycooper <andycooper!uid246432@gateway/web/irccloud.com/x-awhlysidxhwpylpg> has quit IRC | 01:20 | |
| *** vineela <vineela!vtummala@nat/intel/x-gmjdszkdupcedvxe> has quit IRC | 01:29 | |
| *** goliath <goliath!~goliath@clnet-p04-043.ikbnet.co.at> has quit IRC | 01:47 | |
| *** linums <linums!~linums@84.198.214.27> has quit IRC | 01:52 | |
| *** stephano <stephano!~stephano@73.240.0.134> has quit IRC | 01:52 | |
| *** linums <linums!~linums@84.198.214.27> has joined #yocto | 01:53 | |
| *** adelcast1 <adelcast1!~adelcast@2603-8080-1e08-7cd8-823f-5dff-fe15-cf0d.res6.spectrum.com> has joined #yocto | 01:59 | |
| *** sakoman <sakoman!~steve@rrcs-66-91-142-162.west.biz.rr.com> has quit IRC | 02:16 | |
| *** sakoman <sakoman!~steve@rrcs-66-91-142-162.west.biz.rr.com> has joined #yocto | 02:21 | |
| *** rcw <rcw!~rcwoolley@216.154.64.65> has quit IRC | 02:54 | |
| *** dev1990_ <dev1990_!~dev@dynamic-78-8-2-137.ssp.dialog.net.pl> has joined #yocto | 03:04 | |
| *** dev1990 <dev1990!~dev@dynamic-78-8-165-125.ssp.dialog.net.pl> has quit IRC | 03:05 | |
| *** mrc3 <mrc3!~mrc3@linaro/mrc3> has joined #yocto | 03:06 | |
| *** imcleod_ <imcleod_!~imcleod@c-67-165-189-101.hsd1.il.comcast.net> has quit IRC | 03:11 | |
| *** ahadi <ahadi!~ahadi@i59F44CD4.versanet.de> has quit IRC | 03:13 | |
| *** ahadi <ahadi!~ahadi@89.244.126.193> has joined #yocto | 03:14 | |
| *** dreyna <dreyna!~dreyna@c-71-202-37-249.hsd1.ca.comcast.net> has quit IRC | 03:40 | |
| *** f0h <f0h!~f0h@farfarello.0xf0.eu> has quit IRC | 03:49 | |
| *** f0h <f0h!~f0h@farfarello.0xf0.eu> has joined #yocto | 03:50 | |
| *** imcleod_ <imcleod_!~imcleod@2601:249:8200:1ba1:af65:6e6f:10d:e757> has joined #yocto | 03:55 | |
| *** f0h <f0h!~f0h@farfarello.0xf0.eu> has quit IRC | 03:57 | |
| *** f0h <f0h!~f0h@farfarello.0xf0.eu> has joined #yocto | 03:57 | |
| *** dreyna <dreyna!~dreyna@c-71-202-37-249.hsd1.ca.comcast.net> has joined #yocto | 04:21 | |
| *** linums <linums!~linums@84.198.214.27> has quit IRC | 04:40 | |
| *** linums <linums!~linums@apn-94-44-120-135.vodafone.hu> has joined #yocto | 04:40 | |
| *** imcleod_ <imcleod_!~imcleod@2601:249:8200:1ba1:af65:6e6f:10d:e757> has quit IRC | 04:42 | |
| *** linums <linums!~linums@apn-94-44-120-135.vodafone.hu> has quit IRC | 04:45 | |
| *** linums <linums!~linums@84.198.214.27> has joined #yocto | 04:46 | |
| *** crawler <crawler!~crawler@86-94-123-234.fixed.kpn.net> has quit IRC | 04:55 | |
| *** crawler <crawler!~crawler@2a02-a459-aaac-1-8f7b-0-30f1-ad8a.fixed6.kpn.net> has joined #yocto | 04:57 | |
| *** Ad0 <Ad0!~Ad0@93.124.245.194> has quit IRC | 05:43 | |
| *** Ad0 <Ad0!~Ad0@93.124.245.194> has joined #yocto | 05:44 | |
| *** Ad0 <Ad0!~Ad0@93.124.245.194> has quit IRC | 05:53 | |
| *** Ad0 <Ad0!~Ad0@93.124.245.194> has joined #yocto | 06:03 | |
| *** armpit <armpit!~armpit@c-67-181-203-136.hsd1.ca.comcast.net> has quit IRC | 06:16 | |
| *** alessioigor <alessioigor!~alessioig@93-47-228-8.ip115.fastwebnet.it> has joined #yocto | 06:17 | |
| *** vijay <vijay!a4a45f09@164.164.95.9> has joined #yocto | 06:25 | |
| *** AndersD <AndersD!~AndersD@h83-209-96-136.cust.a3fiber.se> has joined #yocto | 06:32 | |
| *** B0ned1ger <B0ned1ger!~B0ned1ger@82-135-139-249.static.zebra.lt> has joined #yocto | 06:32 | |
| *** minimaxwell <minimaxwell!~minimaxwe@atoulouse-258-1-35-192.w90-55.abo.wanadoo.fr> has joined #yocto | 06:34 | |
| *** AndersD_ <AndersD_!~AndersD@h83-209-96-136.cust.a3fiber.se> has joined #yocto | 06:35 | |
| *** AndersD <AndersD!~AndersD@h83-209-96-136.cust.a3fiber.se> has quit IRC | 06:38 | |
| *** beneth` <beneth`!~beneth@irc.beneth.fr> has joined #yocto | 06:38 | |
| *** w00die <w00die!~w00die@212.91.255.186> has quit IRC | 06:57 | |
| *** w00die <w00die!~w00die@212.91.255.186> has joined #yocto | 06:59 | |
| *** dreyna <dreyna!~dreyna@c-71-202-37-249.hsd1.ca.comcast.net> has quit IRC | 06:59 | |
| *** thaytan <thaytan!~thaytan@159.196.146.150> has quit IRC | 07:01 | |
| *** thaytan <thaytan!~thaytan@159.196.146.150> has joined #yocto | 07:03 | |
| *** aleblanc <aleblanc!~textual@192-222-183-114.qc.cable.ebox.net> has quit IRC | 07:04 | |
| *** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has joined #yocto | 07:06 | |
| *** zyga <zyga!~zyga@unaffiliated/zyga> has joined #yocto | 07:13 | |
| *** ENPJ <ENPJ!~John@ppp-88-217-43-227.dynamic.mnet-online.de> has joined #yocto | 07:14 | |
| *** agust <agust!~agust@p508b6a6d.dip0.t-ipconnect.de> has joined #yocto | 07:19 | |
| *** jobroe <jobroe!~manjaro-u@p579eb8f7.dip0.t-ipconnect.de> has joined #yocto | 07:26 | |
| *** georgem_home <georgem_home!uid210681@gateway/web/irccloud.com/x-vvdbbfbwidrhvbko> has quit IRC | 07:27 | |
| *** goliath <goliath!~goliath@clnet-p04-043.ikbnet.co.at> has joined #yocto | 07:32 | |
| *** LetoThe2nd <LetoThe2nd!uid453638@gateway/web/irccloud.com/x-mcquttbcaolallwa> has joined #yocto | 07:33 | |
| *** rcoote <rcoote!~rcoote@ip-176-198-112-234.hsi05.unitymediagroup.de> has joined #yocto | 07:40 | |
| *** mckoan|away is now known as mckoan | 07:41 | |
| *** frsc <frsc!~frsc@i59F4B6E1.versanet.de> has joined #yocto | 07:45 | |
| *** B0ned1ger <B0ned1ger!~B0ned1ger@82-135-139-249.static.zebra.lt> has quit IRC | 07:48 | |
| *** B0ned1ger2 <B0ned1ger2!~B0ned1ger@82-135-139-249.static.zebra.lt> has joined #yocto | 07:48 | |
| LetoThe2nd | yo dudX | 07:50 |
| mckoan | good morning | 07:50 |
| mihai | g'morning | 07:50 |
| *** gsalazar <gsalazar!955a6fad@gateway/web/cgi-irc/kiwiirc.com/ip.149.90.111.173> has joined #yocto | 07:54 | |
| *** fl0v0 <fl0v0!~fvo@i59F44F8B.versanet.de> has joined #yocto | 08:01 | |
| *** bps <bps!~bps@80.71.142.18> has joined #yocto | 08:13 | |
| mseeber | Greetings, I have set up a NFS share for the download cache on my build host and this seems to cause a do_fetch job for linux-imx to hang (no network/hd io at all), in comparison, placing the download cache outside the share seems to work fine. Could this be caused by bad mount options or file permission problems? | 08:14 |
| LetoThe2nd | mseeber: are only the cached git repo accesses problematic? | 08:21 |
| mseeber | I just teste that by removing the linux-imx related files from the download cache. While running a new build it hangs during fetch again and only created the lock file. | 08:24 |
| LetoThe2nd | mseeber: ok, but all recipes that access some form of archive/tarball are happy? | 08:24 |
| mseeber | They do work, yes | 08:25 |
| *** leon-anavi <leon-anavi!~Leon@78.130.197.211> has joined #yocto | 08:25 | |
| LetoThe2nd | i see. what release are you on? | 08:25 |
| mseeber | poky version is sumo | 08:28 |
| LetoThe2nd | meh. | 08:29 |
| LetoThe2nd | check if it also fails on dunfell, and if not, go hunting for the patch in the git fetcher. | 08:29 |
| LetoThe2nd | if it still fails then, please report a bug. | 08:29 |
| LetoThe2nd | repectively, if it still fails on master. | 08:30 |
| mseeber | alright, thanks | 08:30 |
| mihai | mseeber: or maybe the remote is _that_ slow and you're stuck waiting | 08:30 |
| *** manuel_ <manuel_!~manuel198@089144217062.atnat0026.highway.a1.net> has joined #yocto | 08:31 | |
| LetoThe2nd | mihai: then the effect would be witnessed on something recent too, probably. unless there already is handling for it in place. | 08:32 |
| LetoThe2nd | in any case i think all effort on sumo support is wasted :) | 08:32 |
| mcfrisk | mseeber: yes, check if you can manually download the SRC_URI's of the affected recipe, the repos and servers can indeed be really slow | 08:32 |
| mseeber | probably not, i did test with and without nfs, so the remote repo is probably fine | 08:32 |
| mcfrisk | well, I have sumo working and maintained quite well so it's not completely wasted time with it... | 08:34 |
| * LetoThe2nd hands mcfrisk the "sumo volunteer"-badge! | 08:34 | |
| LetoThe2nd | (pun intended!) | 08:35 |
| *** bps <bps!~bps@80.71.142.18> has quit IRC | 08:36 | |
| *** Yumasi <Yumasi!~guillaume@2a01:e0a:5cb:4430:a218:d301:729d:d5b3> has joined #yocto | 08:37 | |
| *** JosephAntony <JosephAntony!a5e17a63@165.225.122.99> has joined #yocto | 08:37 | |
| *** oberstet <oberstet!~oberstet@213.170.219.39> has joined #yocto | 08:49 | |
| *** manuel_ <manuel_!~manuel198@089144217062.atnat0026.highway.a1.net> has quit IRC | 08:50 | |
| * mcfrisk tried to get permission to maintain sumo publicly... | 09:00 | |
| LetoThe2nd | mcfrisk: let me know when you make it, i'll buy you some new pants! | 09:01 |
| *** frsc <frsc!~frsc@i59F4B6E1.versanet.de> has quit IRC | 09:08 | |
| qschulz | codeaurora.org is sometimes painfully slow, so I wouldn't be surprised that's what's going on with linux-imx taking ages (also, the kernel is a pretty big repo, so delta resolving is long ) | 09:11 |
| *** frsc <frsc!~frsc@i59F4B6E1.versanet.de> has joined #yocto | 09:16 | |
| *** vijay <vijay!a4a45f09@164.164.95.9> has quit IRC | 09:29 | |
| *** medaliyou <medaliyou!29e2aabb@41.226.170.187> has joined #yocto | 09:30 | |
| medaliyou | Hi Guys | 09:30 |
| medaliyou | LAYERSERIES_COMPAT_meta-XYZ = "thud" | 09:31 |
| medaliyou | i ve cloned with dunfell branch | 09:31 |
| medaliyou | what happens if i change this line ' LAYERSERIES_COMPAT_meta-XYZ = "thud" ' to ' LAYERSERIES_COMPAT_meta-XYZ = "dunfell" ' or just comment it | 09:32 |
| medaliyou | would it break things ? | 09:32 |
| mcfrisk | LetoThe2nd: tried, but failed :( no need for new pants | 09:32 |
| LetoThe2nd | mcfrisk: aww. | 09:33 |
| medaliyou | LetoThe2nd can you help me please !!! | 09:34 |
| LetoThe2nd | mcfrisk: https://sumowrestling.fandom.com/wiki/Mawashi | 09:35 |
| medaliyou | i m working on existing yocto project & triying to optimize boot time. | 09:35 |
| LetoThe2nd | medaliyou: go and find out. it might work if there are no specific dependencies, it might break if there are. | 09:36 |
| medaliyou | alright , thank you | 09:36 |
| *** manuel_ <manuel_!~manuel198@62.99.131.178> has joined #yocto | 09:47 | |
| *** bps <bps!~bps@80.71.142.18> has joined #yocto | 09:50 | |
| RP | gah, the reason the font files date from 2018 isn't because they get an old date, its because that was when I made that local checkout of the tree :/ | 09:56 |
| *** mseeber <mseeber!~mseeber@2a02:2450:1159:680:464d:d23b:600a:b6a3> has quit IRC | 09:56 | |
| *** manuel_ <manuel_!~manuel198@62.99.131.178> has quit IRC | 10:01 | |
| *** manuel1985 <manuel1985!~manuel198@62.99.131.178> has joined #yocto | 10:02 | |
| *** B0ned1ger2 <B0ned1ger2!~B0ned1ger@82-135-139-249.static.zebra.lt> has quit IRC | 10:06 | |
| *** B0ned1ger <B0ned1ger!~B0ned1ger@82-135-139-249.static.zebra.lt> has joined #yocto | 10:07 | |
| *** mseeber <mseeber!~mseeber@static-91-137-63-64.net.encoline.de> has joined #yocto | 10:26 | |
| mcfrisk | RP: fun with git and file time stamps, been there too. https://git.wiki.kernel.org/index.php/Git_FAQ#Why_isn.27t_Git_preserving_modification_time_on_files.3F https://stackoverflow.com/questions/2179722/checking-out-old-file-with-original-create-modified-timestamps | 10:57 |
| mcfrisk | my fun involved ikiwiki and RSS feeds which went crazy after re-checkout of a repo, and git lfs which didn't have reproducible time stamps.. | 10:58 |
| mcfrisk | and git annex too | 10:58 |
| *** ptsneves <ptsneves!b0dd7824@176.221.120.36> has joined #yocto | 11:00 | |
| RP | mcfrisk: right, I can see why it does it, I was just being dumb with my previous fix :/ | 11:02 |
| qschulz | I have this recipe which has some files in ${S}/<package-name>/ but install all of them to let's say datadir. The filename are UUIDs, so they don't have the package-name in it. I wanted to use do_split_packages in populate_packages_prepend as suggested in the documentation | 11:12 |
| qschulz | it works just fine with shlibs because they have the packagename in their filename, so easy match, but for the aforementioned files, it's a bit more complex :/ | 11:12 |
| qschulz | how dirty is it to look into ${B}/<package-name>/ to make a mapping of UUIDs to package-name? | 11:13 |
| *** JosephAntony <JosephAntony!a5e17a63@165.225.122.99> has quit IRC | 11:25 | |
| *** B0ned1ger2 <B0ned1ger2!~B0ned1ger@78-60-213-230.static.zebra.lt> has joined #yocto | 11:31 | |
| *** frsc <frsc!~frsc@i59F4B6E1.versanet.de> has quit IRC | 11:32 | |
| *** frsc <frsc!~frsc@i59F4B6E1.versanet.de> has joined #yocto | 11:33 | |
| *** B0ned1ger <B0ned1ger!~B0ned1ger@82-135-139-249.static.zebra.lt> has quit IRC | 11:34 | |
| *** B0ned1ger2 <B0ned1ger2!~B0ned1ger@78-60-213-230.static.zebra.lt> has quit IRC | 11:35 | |
| dl9pf | RP: if (srcdate && rpmExpandNumeric("%{?use_source_date_epoch_as_buildtime}")) { | 11:44 |
| dl9pf | so where do we set the default macros ? | 11:44 |
| *** kpo_ <kpo_!~kpo@bwu34.internetdsl.tpnet.pl> has quit IRC | 11:44 | |
| *** kpo_ <kpo_!~kpo@bwu34.internetdsl.tpnet.pl> has joined #yocto | 11:45 | |
| RP | dl9pf: package_rpm.bbclass, see the --defines I think | 11:49 |
| dl9pf | --define "%source_date_epoch_from_changelog 1" | 11:50 |
| dl9pf | --define "%clamp_mtime_to_source_date_epoch 1" | 11:51 |
| RP | dl9pf: hmm, I don't see the changelog piece here | 11:51 |
| dl9pf | ah ... ignore, thats suse specific | 11:52 |
| dl9pf | --define "%use_source_date_epoch_as_buildtime 1" | 11:52 |
| RP | that sounds promising | 11:52 |
| dl9pf | compared with https://en.opensuse.org/openSUSE:Reproducible_Builds#With_OBS | 11:53 |
| dl9pf | so let's try mtime and buildtime and see | 11:53 |
| RP | dl9pf: mtime is already there I think | 11:53 |
| dl9pf | checking package_rpm.bbclass now | 11:53 |
| *** sstiller <sstiller!~sstiller@p200300f07f10f4002f0226d408d91988.dip0.t-ipconnect.de> has joined #yocto | 11:53 | |
| ptsneves | qschulz it seems that you need to roll your own packaging function | 11:55 |
| qschulz | ptsneves: I can do something by reading the source directory but that feels wrong somehow :/ | 11:56 |
| dl9pf | sent a v2 | 11:58 |
| ptsneves | i do not think it feels wrong. Why? You will roll the packaging function in the recipe scope so it is localized. | 11:58 |
| *** B0ned1ger <B0ned1ger!~B0ned1ger@78-60-213-230.static.zebra.lt> has joined #yocto | 11:58 | |
| ptsneves | i guess your goal is to solve the problem for the domain. If you do it only in that domain there is no dirtyness. At most you will take a hit in maintainability, in the sense that if you break the assumptions in the future you will break the recipe in the best case or pack incorrectly in the worse(can be mitigated) | 12:00 |
| RP | qschulz: If my local "make do_install an sstate task" change does go in it would break that | 12:00 |
| *** B0ned1ger2 <B0ned1ger2!~B0ned1ger@82-135-139-249.static.zebra.lt> has joined #yocto | 12:00 | |
| qschulz | RP: mmmm how so? is there a cleandirs somewhere that would remove the ${S} or ${B} directory before do_package is run? | 12:01 |
| qschulz | basically, I have ${S}/package-name/transaltions/<UUID> which gets installed into ${D}/usr/share/translations/ | 12:02 |
| qschulz | and UUID != packagename, so for now I do a glob search in S, to get package-name-UUID mapping | 12:02 |
| qschulz | and I manually append /usr/share/translations/UUID to FILES_${PN}-<package-name> | 12:03 |
| *** B0ned1ger <B0ned1ger!~B0ned1ger@78-60-213-230.static.zebra.lt> has quit IRC | 12:03 | |
| RP | qschulz: if do_install comes from sstate, ${S}/${B} won't be populated | 12:03 |
| qschulz | RP: duh, obviously. /me facepalms himself :) | 12:04 |
| RP | qschulz: could you install some symlink which would help the code know where things go? | 12:05 |
| RP | package it off into the -dev where you don't care | 12:05 |
| RP | dl9pf: https://autobuilder.yoctoproject.org/typhoon/#/builders/117/builds/3 is running with it | 12:06 |
| *** georgem_home <georgem_home!uid210681@gateway/web/irccloud.com/x-ikhcfizjuipfbzwb> has joined #yocto | 12:06 | |
| RP | dl9pf: I'm worried your test "reproduced" for you :/ | 12:07 |
| qschulz | RP: I'd still need to manually package them (getvar(fiels_pn), setvar(files_pn)) instead of using do_split_packages then :/ | 12:09 |
| qschulz | i'll ask upstream to change how they do it and use subdirs for those files too :) | 12:09 |
| ptsneves | RP do_install has a setscene version? | 12:15 |
| RP | ptsneves: not yet but I have patches and ideas | 12:17 |
| dl9pf | it did produce these numbers, but with the dunfell selftest | 12:17 |
| RP | dl9pf: I'd be interested what you get with master. I'm worried it doesn't match what we see on the autobuilder, admittedly with master | 12:17 |
| dl9pf | my build machine just crashed running the selftest ... | 12:18 |
| *** tgoodwin <tgoodwin!~tgoodwin@static-96-234-151-198.bltmmd.fios.verizon.net> has joined #yocto | 12:18 | |
| ptsneves | @RP :O what is the rationale? This sounds quite a change. | 12:18 |
| ptsneves | qschulz then stage into the D dir a file with the layout of how you want things packaged...although things are tricky. | 12:18 |
| RP | dl9pf: I probably shouldn't see that as an achievement, right? :) | 12:19 |
| RP | ptsneves: it would allow repackaging without rebuilding everything. It also makes binary only distribution easier | 12:19 |
| *** TheComet <TheComet!~hpom0@193.72.56.76> has joined #yocto | 12:21 | |
| TheComet | Is it possible to compile two different repositories in the same recipe? | 12:21 |
| ptsneves | RP do you already have an RFC for it? | 12:22 |
| RP | ptsneves: my patches don't quite work | 12:22 |
| TheComet | I would like to combine 2 repos into one package if that's somehow possible | 12:22 |
| ptsneves | TheComet yes. Just merge them into a way they both work, or just call the build system for each of the repos | 12:22 |
| RP | TheComet: you can put multiple entries in SRC_URI | 12:23 |
| ptsneves | TheComet i mean merge them in the WORKDIR. | 12:23 |
| TheComet | Ah I would need to write my own do_compile() to call make twice? | 12:23 |
| ptsneves | RP you comfortable in sharing them already? | 12:23 |
| ptsneves | TheComet if they are independent yes. | 12:24 |
| TheComet | Alright thanks | 12:24 |
| RP | ptsneves: http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/t222&id=a6ea95b13b94b5879c2728c9587811a426d7c479 and http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/t222&id=135b129b24fc170c522722324b4ece082a706395 | 12:24 |
| dl9pf | RP: probably a faulty DIMM | 12:24 |
| TheComet | Is that the best way though, or is there an easy way to merge the compile results of two recipes into one package? | 12:25 |
| TheComet | Because I do think I should leverage the default do_compile()/do_install() stuff | 12:25 |
| ptsneves | TheComet It depends, but it is style. Conventionally you have different recipes for each repo. Are these 2 repos usable independently? | 12:26 |
| TheComet | ptsneves: They are yeah. Well, one of them has a "soft" runtime dependency on the other, but they can be built and run without knowing about each other | 12:27 |
| ptsneves | or the outputs of repo making somethin unit which has a business sense? If only business sense maybe you could consider it a package group, even though a package group for 2 recipes...is unconventional? | 12:27 |
| ptsneves | TheComet so i would not build them together. If they have very similar way of building you can just have a common .inc file | 12:28 |
| TheComet | ptsneves: My problem is my client wants to bundle multiple programs into a single revision/version. He'd rather have a single "foo-1.0.0" package that contains exact versions of each repo rather than having muliple "bar-1.0.0" and "baz-1.0.0" packages where it's possible to accidentally have incompatible versions installed together | 12:30 |
| ptsneves | i may be wrong but i think you can do that in the packagegroup | 12:31 |
| TheComet | I haven't looked at packagegroup at all but I think that might be exactly what I need | 12:31 |
| TheComet | I'll look into it thanks! | 12:31 |
| ptsneves | even so. If you see the package group as being unnecessary maintenance for you, and you do not have any special convention it also does not hurt. | 12:31 |
| ptsneves | above all fullfil you client needs and think of your future self as a maintainer | 12:32 |
| TheComet | I sure hope I don't have to maintain this dumpsterfire in the future :D | 12:33 |
| *** imcleod_ <imcleod_!~imcleod@2601:249:8200:1ba1:af65:6e6f:10d:e757> has joined #yocto | 12:34 | |
| ptsneves | TheComet well embedded has a "history" of such things, but this is where Yocto actually brings value. It tries to isolate each dumpsterfire in it's own dumpster. :D | 12:35 |
| malinus | lol | 12:36 |
| TheComet | lmao | 12:36 |
| TheComet | Can I specify exact versions in PACKAGES? e.g. PACKAGES = "foo-1.0.0-r0 bar-1.0.0-r0"? If that works then I think this is the solution I'll go with | 12:37 |
| ptsneves | i dont think so but you can RDEPENDS on specific versions | 12:38 |
| ptsneves | or version semantics | 12:38 |
| RP | TheComet: RDEPENDS_foo = "bar (=1.0.0)" | 12:39 |
| TheComet | Hmm, can I not "bitbake foo"? I created a foo-1.0.0.bb wich defines PACKAGES = "packagegroup-foo" and RDEPENDS_packagegroup-foo = "bar (=1.0.0) baz (=1.0.0)" | 12:44 |
| ptsneves | TheComet you can. What did it not achieve? | 12:45 |
| RP | TheComet: dependencies don't make sense in PACKAGES | 12:45 |
| RP | ah, sorry, I misread | 12:46 |
| TheComet | It's saying "Nothing PROVIDES foo" | 12:46 |
| TheComet | "bitbake foo-1.0.0" seems to work though | 12:46 |
| ptsneves | ahh | 12:46 |
| ptsneves | because the recipe should be foo_1.0.0.b | 12:46 |
| ptsneves | foo_1.0.0.bb | 12:46 |
| TheComet | Oooh, of course | 12:46 |
| *** vineela <vineela!~vtummala@134.134.139.72> has joined #yocto | 13:18 | |
| *** andycooper <andycooper!uid246432@gateway/web/irccloud.com/x-buxtigmffcfvckiw> has joined #yocto | 13:28 | |
| *** koobla23 <koobla23!50f3ae5c@80.243.174.92> has joined #yocto | 13:39 | |
| jonesv[m] | Does `DISTRO_FEATURES += "usbgadget"` add the kernel modules, or should I enable them manually? | 13:40 |
| jonesv[m] | When I `ls /lib/modules/$(uname -r)`, I don't see any usb-related modules, but I'm not sure if I should add e.g. `g_ether` myself to my kernel. | 13:42 |
| LetoThe2nd | jonesv[m]: look at meta/recipes-core/packagegroup-base | 13:44 |
| LetoThe2nd | jonesv[m]: AFAICS, usbgadget just enables a bunch of specific kernel modules, but that seems neither exhaustive nor checking/modifying the kernel config. to me it looks more like some relic. | 13:45 |
| jonesv[m] | <LetoThe2nd "jonesv: AFAICS, usbgadget just e"> I see. Also I only enabled it in DISTRO_FEATURES, but it is not listed there (only in COMBINED_FEATURES, which I guess means that I should have it in MACHINE_FEATURES, too). | 13:48 |
| LetoThe2nd | rewording... enables means "add to RRECOMMENDS". so if i'm not mistaken, they are installed if the kernel config provides them, but nothing fails if they're not there. | 13:49 |
| LetoThe2nd | jonesv[m]: well stupid, but obvious question: did you do the distro_features add in a suitable place? e.g. distro, machine or local.conf? | 13:49 |
| jonesv[m] | I did it in `local.conf`, because I don't have my distro yet (but I want to put it in the distro eventually) | 13:50 |
| jonesv[m] | But I'm using the default linux-yocto, and maybe I need to append something for it to support usbgadget | 13:50 |
| LetoThe2nd | jonesv[m]: check /proc/config.gz first. | 13:51 |
| *** koobla23 <koobla23!50f3ae5c@80.243.174.92> has quit IRC | 14:01 | |
| *** svogl <svogl!50f3ae5c@80.243.174.92> has joined #yocto | 14:02 | |
| *** TheComet <TheComet!~hpom0@193.72.56.76> has quit IRC | 14:08 | |
| *** Ad0 <Ad0!~Ad0@93.124.245.194> has quit IRC | 14:17 | |
| *** minimaxw1ll <minimaxw1ll!~minimaxwe@atoulouse-258-1-35-192.w90-55.abo.wanadoo.fr> has joined #yocto | 14:18 | |
| *** minimaxwell <minimaxwell!~minimaxwe@atoulouse-258-1-35-192.w90-55.abo.wanadoo.fr> has quit IRC | 14:20 | |
| *** mbulut <mbulut!~nameclash@ip1f121f26.dynamic.kabel-deutschland.de> has joined #yocto | 14:21 | |
| *** Ad0 <Ad0!~Ad0@93.124.245.194> has joined #yocto | 14:21 | |
| *** mbulut <mbulut!~nameclash@ip1f121f26.dynamic.kabel-deutschland.de> has quit IRC | 14:23 | |
| ENPJ | rauc status | 14:24 |
| *** mbulut <mbulut!~nameclash@ip1f121f26.dynamic.kabel-deutschland.de> has joined #yocto | 14:24 | |
| *** awafaa_ is now known as awafaa | 14:26 | |
| *** minimaxw1ll is now known as minimaxwell | 14:34 | |
| *** TheComet <TheComet!~hpom0@193.72.56.76> has joined #yocto | 14:40 | |
| dl9pf | RP: https://autobuilder.yoctoproject.org/typhoon/#/builders/117/builds/3 seems done, error seems unrelated ? | 14:50 |
| RP | dl9pf: yes, other master-next issues, sorry :( | 14:54 |
| *** kaspter <kaspter!~Instantbi@2409:8a1e:911f:ee70:f0ba:ded9:f1f6:7520> has joined #yocto | 14:57 | |
| *** sstiller <sstiller!~sstiller@p200300f07f10f4002f0226d408d91988.dip0.t-ipconnect.de> has quit IRC | 15:03 | |
| *** armpit <armpit!~armpit@2601:202:4180:a5c0:7db1:8052:decd:2a75> has joined #yocto | 15:04 | |
| qschulz | I'm wondering how qt native binaries can be found by qmake5 recipes.. It seems QT_EXTERNAL_HOST_BINS needs to be preprended to any binary, since it does not end with a slash, a slash should be added between QT_EXTERNAL_HOST_BINS and the binary | 15:05 |
| qschulz | but... that would mean we break outside-of-Yocto builds since QT_EXTERNAL_HOST_BINS does not seem to be defined, which means I now have /qmake instead of qmake | 15:05 |
| qschulz | (basically, I have a qmake5 recipe which calls lrelease, Yocto complains it cannot find lrelease even though it's in the recipe-sysroot-native dir already | 15:06 |
| *** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has quit IRC | 15:11 | |
| *** linums <linums!~linums@84.198.214.27> has quit IRC | 15:13 | |
| medaliyou | hey guys , what to do if qemu-native | 15:14 |
| medaliyou | keeps on failing on do_compile | 15:15 |
| medaliyou | qemu-3.0.0/linux-user/syscall.c:8526: undefined reference to `stime' | 15:15 |
| *** linums <linums!54c6d61b@84.198.214.27> has joined #yocto | 15:16 | |
| qschulz | medaliyou: what's the distribution of your host machine? which version of Yocto are you building? | 15:17 |
| ptsneves | isnt that an issue of glibc mismatch? | 15:17 |
| ptsneves | looks like you need a newer uninative | 15:18 |
| medaliyou | BB_VERSION = "1.40.0" | 15:19 |
| medaliyou | BUILD_SYS = "x86_64-linux" | 15:19 |
| medaliyou | NATIVELSBSTRING = "ubuntu-20.04" | 15:19 |
| medaliyou | TARGET_SYS = "arm-tdx-linux-gnueabi" | 15:19 |
| medaliyou | MACHINE = "colibri-imx7" | 15:19 |
| medaliyou | DISTRO = "tdx-x11" | 15:19 |
| medaliyou | DISTRO_VERSION = "2.6-snapshot-20210217" | 15:19 |
| medaliyou | TUNE_FEATURES = "arm armv7a vfp thumb neon callconvention-hard" | 15:19 |
| medaliyou | TARGET_FPU = "hard" | 15:19 |
| RP | dl9pf: trying again https://autobuilder.yoctoproject.org/typhoon/#/builders/117/builds/4 | 15:19 |
| medaliyou | i rebuilded glibc | 15:20 |
| *** King_InuYasha is now known as Conan_Kudo | 15:20 | |
| *** Conan_Kudo is now known as King_InuYasha | 15:20 | |
| qschulz | medaliyou: ubuntu 20.04 is not supported for thud | 15:21 |
| jonesv[m] | <LetoThe2nd "jonesv: check /proc/config.gz fi"> Not completely sure what I'm looking for, actually 🤔. | 15:21 |
| fray | either yoi should work in a container (with an older host OS installed) or move to a newer YP version. | 15:22 |
| fray | (container or VM) | 15:22 |
| LetoThe2nd | jonesv[m]: hum what is not clear about it? | 15:22 |
| mckoan | medaliyou: why you don't use TDX BSP 5.2 ? | 15:22 |
| medaliyou | should i consider migrating existing layers (since 2018) to dunfell ? | 15:22 |
| jonesv[m] | LetoThe2nd: Does this mean that my DISTRO_FEATURES += usbgadget did not add the modules to my kernel? I'm never sure about which kernel module I'm looking for... I think that "cdc_ether" is for a USB host, and I never know what "u_ether" is. And I never seem to find "g_ether" 😕 | 15:23 |
| qschulz | medaliyou: thud is unmaintained so, short answer yes. Otherwise, backport https://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/meta/recipes-devtools/qemu?id=b8809d338005eeea4085692281dda20fe85dc52d and expect more breakage for other packages that can't build on ubuntu 20.04 | 15:24 |
| LetoThe2nd | jonesv[m]: i said: the distro feature will not modify the kernel config. so if your kernel config does not build the usb gadget modules, then adding the distro feature won't have any effect. | 15:24 |
| jonesv[m] | LetoThe2nd: also it says "CONFIG_USB_NET_CDCETHER=m", but `modprobe cdc_ether` can't find it | 15:24 |
| LetoThe2nd | jonesv[m]: have you looked at the packagegroup i named? to see which modules it actually tries to pull in? | 15:25 |
| *** kpo_ <kpo_!~kpo@bwu34.internetdsl.tpnet.pl> has quit IRC | 15:25 | |
| *** kpo_ <kpo_!~kpo@bwu34.internetdsl.tpnet.pl> has joined #yocto | 15:26 | |
| qschulz | jonesv[m]: you probably need to add kernel-module-<something> to your IMAGE_INSTALL and/or select the correct usb gadget module. Run menuconfig and search for the gadget driver and it should explain what it's for | 15:26 |
| *** Anarky <Anarky!~Anarky@lfbn-lyo-1-1731-121.w90-65.abo.wanadoo.fr> has quit IRC | 15:26 | |
| medaliyou | is the migrating process hard (i mean i have kernel patches and various modules hodling on kernel v 4.14.9X) '=( '=( | 15:26 |
| *** mseeber <mseeber!~mseeber@static-91-137-63-64.net.encoline.de> has quit IRC | 15:26 | |
| jonesv[m] | <LetoThe2nd "jonesv: have you looked at the p"> ``` | 15:27 |
| LetoThe2nd | qschulz: the distro feature is essentially just triggering a packagegroup that RRECOMMENDS a bunch of kernel-modules. | 15:27 |
| LetoThe2nd | (if i read it correctly) | 15:27 |
| qschulz | medaliyou: BSP components don't necessarily require an update (or for that matter, most package recipes actually). You can always fix a version and use that one forever if you feel like it | 15:29 |
| jonesv[m] | I know it probably all sounds obvious to you, but for me it's not always super easy to find which package goes with which kernel module which goes with which key in the defconfig, and that's for when I know which module does what I need 🙈. For USB I know two modes (host/gadget), but it's not like there is a "usb_host" and a "usb_gadget" modules, right? 😀 | 15:29 |
| *** frsc <frsc!~frsc@i59F4B6E1.versanet.de> has quit IRC | 15:31 | |
| *** frsc <frsc!~frsc@i59F4B6E1.versanet.de> has joined #yocto | 15:31 | |
| *** ssajal <ssajal!~ssajal@bras-base-otwaon0147w-grc-08-70-49-162-56.dsl.bell.ca> has joined #yocto | 15:31 | |
| linums | hi guys | 15:33 |
| linums | I am on the master channel right now | 15:34 |
| linums | and I noticed that the kea package is from a development branch, not from the master | 15:34 |
| qschulz | jonesv[m]: no, because the point of a gadget device is to assume many different roles, and that we cannot pick for you. Yocto takes .ko files from the kernel recipe and create a package for each of those, prefixed wuith kernel-module- | 15:34 |
| linums | is it an mistake, or is it intentional? | 15:35 |
| RP | linums: was that not because that was where the release commit tag was? | 15:35 |
| qschulz | jonesv[m]: unfortunately, figuring out which kernel modules you need and how to enable them in the kernel is not a mission for Yocto, but you only. | 15:35 |
| *** Kyubi <Kyubi!~Kyubi@2601:647:4080:f10:e508:a6ae:f5f:3ee8> has joined #yocto | 15:35 | |
| linums | @RP: I have to check it in the kea's source, so far, I've seen the initional log m3essage describing, that it is not a production release | 15:36 |
| qschulz | that's the fine line between build systems and BSP components. Especially since BSP components are rarely the same for people so we cannot always help appropriately | 15:36 |
| hmw1 | Hi yocto started to create a folder morgue in the deploy/ipk/ARCH/morgue and it is putting the current install files there | 15:37 |
| linums | but I am right though, that dev version should not be under the yocto master | 15:37 |
| jonesv[m] | <qschulz "that's the fine line between bui"> Right. Yes that makes sense 🙂. In this case I was a bit confused because from the documentation, it really sounds like adding "usbgadget" will add a bunch of modules, but it requires the kernel to be compiled with the corresponding options. That makes sense now that I know it, though 😀 | 15:41 |
| *** Kyubi <Kyubi!~Kyubi@2601:647:4080:f10:e508:a6ae:f5f:3ee8> has quit IRC | 15:42 | |
| RP | linums: master appears to use 1.8.2 which is a main release? | 15:44 |
| *** Anarky <Anarky!~Anarky@lfbn-lyo-1-1731-121.w90-65.abo.wanadoo.fr> has joined #yocto | 15:47 | |
| *** TheComet <TheComet!~hpom0@193.72.56.76> has quit IRC | 15:50 | |
| *** AndersD_ <AndersD_!~AndersD@h83-209-96-136.cust.a3fiber.se> has quit IRC | 15:50 | |
| *** Kyubi <Kyubi!~Kyubi@149.199.62.131> has joined #yocto | 15:54 | |
| linums | yeah, I've checked, I'm a little late from the master | 15:57 |
| linums | at the time I've cloned it, it was using 1.7.10 | 15:57 |
| *** B0ned1ger <B0ned1ger!~B0ned1ger@78-60-213-230.static.zebra.lt> has joined #yocto | 15:59 | |
| *** B0ned1ger2 <B0ned1ger2!~B0ned1ger@82-135-139-249.static.zebra.lt> has quit IRC | 16:02 | |
| *** B0ned1ger <B0ned1ger!~B0ned1ger@78-60-213-230.static.zebra.lt> has quit IRC | 16:04 | |
| qschulz | JPEW: just started to have a slightly deeper look at pyrex's Dockerfile. In ours, we also pass --no-install-recommends to apt. Wouldn't it make sense to add it to pyrex's too? | 16:04 |
| JPEW | qschulz: Ya, probably. Do you want to open a PR? | 16:05 |
| qschulz | JPEW: I could, do you have CI to test I'm not breaking stuff :D | 16:05 |
| JPEW | qschulz: Yes! I actually just got it working with GitHub actions yesterday! | 16:06 |
| JPEW | qschulz: https://github.com/garmin/pyrex/blob/master/DEVELOPING.md#testing | 16:06 |
| RP | linums: right, we fixed things to only get even numbers | 16:07 |
| linums | seee,cool, thanks | 16:08 |
| *** minimaxwell <minimaxwell!~minimaxwe@atoulouse-258-1-35-192.w90-55.abo.wanadoo.fr> has quit IRC | 16:11 | |
| *** svogl <svogl!50f3ae5c@80.243.174.92> has quit IRC | 16:12 | |
| qschulz | JPEW: oh wow, the Github actions don't look super straightforward :o | 16:16 |
| fray | I've seen a lot of interesting integrations with github actions -- but I'm always concerned about building something tightly coupled to someone elses environment.. | 16:16 |
| fray | Using a github action to trigger something in my environment seems a lot less dangerous.. just an observation | 16:17 |
| qschulz | fray: wasn't it already the case with Travis which was the defacto standard for CI/CD in FOSS? | 16:17 |
| qschulz | or maybe I misunderstood what you said? | 16:17 |
| fray | defacto standards around CI/CD were never.. they were localized to projects or even companies.. but I'd never even heard of Travis until working on GTA V (FiveM) stuff.. | 16:18 |
| fray | but anyway, same sort of problem.. the CI/CD infrastructure of the day changes regularly as the methods and procedures (and whatever is en vogue) change.. | 16:18 |
| JPEW | qschulz: Travis and GitHub actions are pretty equivalent for my purposes | 16:18 |
| fray | (to be clear, I'm not saying Travis, GitHub actions, or others are inherently bad or anything, just some implementations using them woudl worry me as being too tightly coupled to an 'uncontrolled' interface..) | 16:19 |
| fray | when it comes to CI/CD infrastructure.. you don't want to be tightly coupled to other parts, IMHO.. or it will restrict upgrading.. | 16:19 |
| JPEW | fray: Ya, It would be nice if there was some standardized "CI language" that worked anywhere | 16:19 |
| fray | think of all the people who loved bugzilla, heavily modified it and then found they couldn't upgrade to the latest version without re-doing all of their modifications.. same problem | 16:20 |
| fray | (or on the commercial size, think of everyone that loves salesforce, heavily modified it.. and is now stuck in a permanent support contract for upgrades because all the modifications require significant work for every upgrade) | 16:22 |
| JPEW | fray: I don't think it's *quite* as bad as that example because we aren't necessarily hacking to core CI infrastructure... we mostly just have to express what we were doing on one another way to make it work on another | 16:22 |
| fray | great work for the person who sells the service contract.. :) | 16:22 |
| qschulz | fray: Travis and Github actions are (were) free | 16:22 |
| fray | bugzilla was free too.. ;) | 16:22 |
| JPEW | Travis is no more | 16:22 |
| qschulz | so for FOSS projects, it makes sense | 16:22 |
| qschulz | JPEW: hence the "were" :) | 16:22 |
| fray | the point is following their precise language that is specific leads to lock-in.. if you know that going in.. fine.. no problem.. | 16:23 |
| qschulz | fray: what companies do is their problem and I would see Jenkins or similar stuff then, that YOU own :) | 16:23 |
| fray | but locking yourself into github, to me, is something I don't want to do.. I want to USE github for thing, but not be locked into their ecosystem | 16:23 |
| qschulz | fray: free stuff always comes with a price :) | 16:23 |
| fray | it's any software interface you don't control. just have to make informed decisions on where and how you use the tooling.. | 16:24 |
| qschulz | fray: on more or less the same topic, it's sad that github is where all the work is done :/ | 16:24 |
| fray | I've seen IMHO a lack of informed decisions and people jump into github thinking it's "the only way" | 16:24 |
| fray | they're going to be burned when those interfaces change | 16:24 |
| fray | I _LIKE_ github, I don't mind Microsoft owning them.. but like anything else, I worry it has a commercial focus -- so things will eventually change | 16:25 |
| fray | (I never did like gitlab or sourceforge.. never really understood why, but I never liked them -- likely interface) | 16:25 |
| *** B0ned1ger <B0ned1ger!~B0ned1ger@78-60-213-230.static.zebra.lt> has joined #yocto | 16:25 | |
| qschulz | fray: proprietary software.. can't trust it :) especially since it's not something you can self-host | 16:25 |
| fray | there are definitely parts of github I don't like as well.. but I can [for the most part] ignore them | 16:26 |
| fray | the only thing that regularly trips me up on github.. I want to see a list of comments often, and I always click the worng part of the display and end up seeing a SINGLE commit, not the overall list of commits.. | 16:26 |
| *** linums <linums!54c6d61b@84.198.214.27> has left #yocto | 16:27 | |
| fray | but this seems to be rare outside of certain groups to want that kind of access.. I'm involved in a project where people claim history doesn't matter.. other then for reverts of the last commit in case something doesn't work.. (I find that 'short sighted') | 16:27 |
| fray | also ends up leading to commit messages of 'Latest work' | 16:27 |
| fray | great, that was helpful.. :| | 16:28 |
| qschulz | don't get me started on this :) | 16:28 |
| fray | the other one that bugs the hell out of me.. they mv a file from one directory to another (no problem), but then start changing it.. and do the move + change in a singel commit.. | 16:29 |
| fray | I do that by accident, but I know better.. these guys don't think that is a problem | 16:29 |
| *** B0ned1ger <B0ned1ger!~B0ned1ger@78-60-213-230.static.zebra.lt> has quit IRC | 16:29 | |
| fray | goes from working to not working over night, and all that happened was a simple file rename... | 16:29 |
| fray | or the other one "I don't like the spacing of this component, so I'm going to re-indent the file, move it to another director AND change 5 lines... all in one commit" | 16:30 |
| *** linums <linums!~linums@apn-94-44-225-50.vodafone.hu> has joined #yocto | 16:30 | |
| fray | and when I do that in 3 commits, they squash them when they take my pull request.. (drives me nuts) | 16:30 |
| * fray is now venting | 16:31 | |
| fray | (non-linux, non-work projects I work on) | 16:31 |
| fray | Linux related don't seem to do that.. and my work projects would never allow that.. | 16:31 |
| *** mrc3 <mrc3!~mrc3@linaro/mrc3> has quit IRC | 16:32 | |
| qschulz | fray: "fix" and "upgrade" commit titles with no log are the best, change my mind | 16:34 |
| *** zyga <zyga!~zyga@unaffiliated/zyga> has quit IRC | 16:38 | |
| fray | right after I get the tracking chip in my COVID-19 vaccine from Bill Gates | 16:39 |
| *** zyga <zyga!~zyga@unaffiliated/zyga> has joined #yocto | 16:40 | |
| mischief | is there a way to exclude content from the sdk | 16:45 |
| *** mrc3 <mrc3!~mrc3@linaro/mrc3> has joined #yocto | 16:53 | |
| *** B0ned1ger <B0ned1ger!~B0ned1ger@82-135-139-249.static.zebra.lt> has joined #yocto | 16:55 | |
| *** Yumasi <Yumasi!~guillaume@2a01:e0a:5cb:4430:a218:d301:729d:d5b3> has quit IRC | 17:01 | |
| *** Kyubi <Kyubi!~Kyubi@149.199.62.131> has quit IRC | 17:06 | |
| *** frsc <frsc!~frsc@i59F4B6E1.versanet.de> has quit IRC | 17:12 | |
| *** linums <linums!~linums@apn-94-44-225-50.vodafone.hu> has quit IRC | 17:14 | |
| *** linums <linums!~linums@apn-94-44-225-50.vodafone.hu> has joined #yocto | 17:15 | |
| *** fl0v0 <fl0v0!~fvo@i59F44F8B.versanet.de> has quit IRC | 17:17 | |
| *** Kyubi <Kyubi!~Kyubi@149.199.62.131> has joined #yocto | 17:21 | |
| *** B0ned1ger2 <B0ned1ger2!~B0ned1ger@78-60-213-230.static.zebra.lt> has joined #yocto | 17:25 | |
| *** Wouter01000 <Wouter01000!~Wouter010@84-80-174-188.fixed.kpn.net> has quit IRC | 17:26 | |
| *** Wouter01000 <Wouter01000!~Wouter010@84-80-174-188.fixed.kpn.net> has joined #yocto | 17:26 | |
| *** B0ned1ger <B0ned1ger!~B0ned1ger@82-135-139-249.static.zebra.lt> has quit IRC | 17:29 | |
| *** B0ned1ger2 <B0ned1ger2!~B0ned1ger@78-60-213-230.static.zebra.lt> has quit IRC | 17:29 | |
| *** kaspter <kaspter!~Instantbi@2409:8a1e:911f:ee70:f0ba:ded9:f1f6:7520> has quit IRC | 17:30 | |
| *** minimaxwell <minimaxwell!~minimaxwe@atoulouse-258-1-35-192.w90-55.abo.wanadoo.fr> has joined #yocto | 17:33 | |
| ptsneves | mischief exclude packages or some files from a package used in the sdk? | 17:35 |
| *** mckoan is now known as mckoan|away | 17:37 | |
| kyanres | fg | 17:37 |
| ptsneves | kyanres wrong console :D | 17:37 |
| mischief | ptsneves: packages... they are part of MACHINE_ESSENTIAL_EXTRA_RDEPENDS | 17:43 |
| mischief | so the sdk for even core-image-minimal of my machine is way bigger than i'd like it to be, and i dont think they are needed for my purposes | 17:43 |
| mischief | can i just unset MACHINE_ESSENTIAL_EXTRA_RDEPENDS in a new image recipe to shrink the sdk size? | 17:44 |
| *** roussinm <roussinm!~mroussin@bras-base-qubcpq0336w-grc-33-174-93-106-232.dsl.bell.ca> has joined #yocto | 17:45 | |
| ptsneves | you can set it with MACHINE_ESSENTIAL_EXTRA_RDEPENDS = "" or you can MACHINE_ESSENTIAL_EXTRA_RDEPENDS_remove = "your package" | 17:45 |
| ptsneves | mischief have you tried it? | 17:45 |
| kyanres | O_O I blame WSL2 + VcXsrv for shitty focus, but I'm just glad there was no password involved | 17:48 |
| *** bps <bps!~bps@80.71.142.18> has quit IRC | 17:53 | |
| *** dreyna <dreyna!~dreyna@c-71-202-37-249.hsd1.ca.comcast.net> has joined #yocto | 17:54 | |
| *** dreyna_ <dreyna_!~dreyna@c-71-202-37-249.hsd1.ca.comcast.net> has joined #yocto | 17:55 | |
| *** Kyubi <Kyubi!~Kyubi@149.199.62.131> has quit IRC | 17:56 | |
| ptsneves | kyanres hmm i also do it a lot of times. The thing is fg and ctrl-z are so strong in muscle memory that we do it without thinkning. A big enough password even if in muscle memory will trigger a "something is wrong" :D | 17:56 |
| *** B0ned1ger <B0ned1ger!~B0ned1ger@82-135-139-249.static.zebra.lt> has joined #yocto | 17:59 | |
| *** dreyna <dreyna!~dreyna@c-71-202-37-249.hsd1.ca.comcast.net> has quit IRC | 17:59 | |
| *** Kyubi <Kyubi!~Kyubi@149.199.62.131> has joined #yocto | 18:00 | |
| *** matteo <matteo!~matteo@redhat/matteo> has joined #yocto | 18:02 | |
| matteo | hi all! | 18:02 |
| armpit | fray, you getting hit with the Storm Canada sent us ? | 18:04 |
| *** jbaxter <jbaxter!~jbaxter@nat-ies.mentorg.com> has joined #yocto | 18:04 | |
| fray | nope.. just cold here | 18:04 |
| armpit | Our friends in TX are having their pools freeze over | 18:05 |
| *** manuel1985 <manuel1985!~manuel198@62.99.131.178> has quit IRC | 18:05 | |
| *** minimaxwell <minimaxwell!~minimaxwe@atoulouse-258-1-35-192.w90-55.abo.wanadoo.fr> has quit IRC | 18:06 | |
| *** Kyubi <Kyubi!~Kyubi@149.199.62.131> has quit IRC | 18:09 | |
| *** minimaxwell <minimaxwell!~minimaxwe@atoulouse-258-1-35-192.w90-55.abo.wanadoo.fr> has joined #yocto | 18:11 | |
| fray | temps here over night have been between -22F and -10F for the past two weeks | 18:13 |
| fray | day time has been -10F to 0F... | 18:13 |
| fray | so it's been cold | 18:13 |
| *** gsalazar <gsalazar!955a6fad@gateway/web/cgi-irc/kiwiirc.com/ip.149.90.111.173> has quit IRC | 18:15 | |
| *** ENPJ <ENPJ!~John@ppp-88-217-43-227.dynamic.mnet-online.de> has quit IRC | 18:23 | |
| *** dahints <dahints!d4cc47cc@212.204.71.204> has joined #yocto | 18:24 | |
| vdl | if "poky" embeds openembedded-core, why does meta-openembedded do the same? | 18:37 |
| *** LetoThe2nd <LetoThe2nd!uid453638@gateway/web/irccloud.com/x-mcquttbcaolallwa> has quit IRC | 18:39 | |
| *** Kyubi <Kyubi!~Kyubi@149.199.62.131> has joined #yocto | 18:39 | |
| fray | meta-openembedded doesn't embedd openembedded-core | 18:39 |
| fray | You can do 'bitbake, openembedded-core & meta-yocto' combined (poky) or individually.. | 18:40 |
| fray | meta-openembedded is just a layer to be added on top.. | 18:40 |
| vdl | aren't meta-openembedded/meta-oe, openembedded-core/meta and poky/meta the same layer? | 18:43 |
| fray | no | 18:44 |
| fray | openembedded-core/meta and poky/meta is the same.. | 18:45 |
| fray | meta-openembedded is completely different | 18:45 |
| vdl | what is meta-openembedded/meta-oe then | 18:46 |
| fray | meta-openembedded is a repository of multiple layers maintained by the OpenEmbedded group. | 18:46 |
| fray | Inside of that is a generic layer, meta-oe that covers things that didn't fit anywhere else.. | 18:46 |
| fray | otherwise meta-python and such are more clear containers of various components | 18:47 |
| fray | layers.openembedded.org can be explored for more info on what these are. Also each layer should have a README file (in the layer itself) that explains what it's purpose is.. | 18:47 |
| vdl | fray: ok meta-openembedded/meta-oe is more of a "meta-misc" layer, right? :D | 18:49 |
| vdl | I'm still struggling to understand the reason of existence for openembedded-core. Like why is there systemd or gnome recipes in there, that's not "core" | 18:52 |
| *** felipealmeida <felipealmeida!~felipealm@177.16.108.71> has quit IRC | 18:53 | |
| fray | openembedded-core is the collection of everything deamed to be a core component. A core component is something that needs to be provided together in a unified way to enable unified testing of the overall system. | 18:54 |
| fray | systemd is core, you can't boot a device without an init framework. | 18:54 |
| fray | OE supports three frameworks.. "minimal" (none or busybox), "sysvinit" or "systemd". Since these are core functionality they have to be integrated into core in order to make sure all other layers have the components to use these parts consistently. | 18:54 |
| vdl | well it's a choice, you could argue that sysvinit is core and systemd is an alternative :) | 18:55 |
| fray | sysvinit and systemd are equally supported and maintained. Recipes are expected to support both of them equally | 18:55 |
| vdl | fray: I understand better with the framework approach | 18:55 |
| fray | Some of hte gnome recipes are required for non-gnome components.. which starts pulling in more and more dependencies.. | 18:56 |
| vdl | still openembedded-core/meta/recipe-* could be in meta-openembedded, since well, they're recipes | 18:56 |
| fray | some of them are simply used to validate things like keyboard, mouse, Wayland/Weston, etc. | 18:56 |
| fray | everything in openembedded-core is tested as a unit. | 18:56 |
| vdl | ok | 18:56 |
| fray | meta-openembeded's layers can be tested together or individually -- but that is not part of the 'core' testing | 18:57 |
| fray | poky is simply a combination of the two common pieces (bitbake/oe-core) and the Yocto Project layer, meta-yocto. It's a "hey this is easier for newbies to have the right versions of everything" | 18:57 |
| fray | but people like Wind River, don't ship 'poky', they ship bitbake, openembedded-core, meta-yocto as individual components.. (while others liek Xilinx DO ship poky. It's how you want to use/package it..) But the Yocto Project development process ensures they always stay in sync.. | 18:58 |
| fray | Yocto Project for instance only tests poky (which in-turn tests bitbake, openembedded-core and meta-yocto) | 18:58 |
| fray | if parts and pieces were moved into different layers, it changes the testing matrix.. Sometimes it might even make more logical sense, but significantly complicate testing.. so that has been one of the traceoffs | 18:59 |
| fray | 'er tradeoffs.. | 18:59 |
| vdl | so let's say you want to get rid of the "glued-together approach" and go poky-less (because it's just a reference distro after all), the bare minimum for your project is having checked out: bitake, openembedded-core and meta-openembedded for additional recipes, right? | 18:59 |
| fray | layers are not precise things, but we've tried to set best practices around them -- but everything has to start somewhere | 18:59 |
| fray | No, bare minimum is bitbake and openembedded-core | 18:59 |
| fray | I regularly build small systems with just those two.. or add a third layer that has BSP level support.. | 19:00 |
| vdl | fray: right, I somehow included "python" in my bare minimum example scenario ^^ | 19:00 |
| fray | it's when I want to expand beyond small systems that I usually start adding parts from meta-openembedded.. | 19:00 |
| fray | python itself is part of openembedded-core.. | 19:00 |
| fray | additional python modules come from meta-python | 19:00 |
| fray | bitbake / openembedded-core are the minimum you need for a working system.. | 19:01 |
| *** felipealmeida <felipealmeida!~felipealm@177.42.48.84> has joined #yocto | 19:03 | |
| vdl | fray: python2 is part of openembedded-core, meta-python is python3, right? | 19:07 |
| *** felipealmeida <felipealmeida!~felipealm@177.42.48.84> has quit IRC | 19:08 | |
| fray | python2 WAS part of openembedded-core until it went EOL.. Then it moved into meta-python2 in meta-openembedded (repository) | 19:08 |
| vdl | fray: anyway thank you, I'll switch to bitbake + openembedded-core + mylayer now | 19:09 |
| fray | python3 is standard now, as it is the only supported version upstream. meta-python used to have both python2 and python3 support.. and has moved to only python3 for the same reason | 19:09 |
| vdl | It might look like I'm nitpicking here but it's kinda important for me to figure out the bare minimum simply for software shipping and also contributing upstream. | 19:09 |
| fray | If it's not in openembedded-core it's optional | 19:10 |
| fray | bitbake is the engine (similar to mmake) it doesn't know how to do anything, but schedule tasks [and provide some library functions like fetch and unpack() | 19:10 |
| *** felipealmeida <felipealmeida!~felipealm@177.42.48.84> has joined #yocto | 19:18 | |
| vdl | fray: bitbake has no dunfell branch, right? how does oe synchronize with the correct bitbake version? | 19:18 |
| *** zyga <zyga!~zyga@unaffiliated/zyga> has quit IRC | 19:19 | |
| fray | bitbake is a separate project.. so it's numerically driven.. I don't remember what the dunfell version is.. There is a page on wiki.yoctoproject.org that captures it | 19:20 |
| *** zyga <zyga!~zyga@unaffiliated/zyga> has joined #yocto | 19:20 | |
| vdl | fray: only layer repositories (including yours) should follow the branch convention and have e.g. a dunfell branch in them, correct? | 19:21 |
| *** imaami <imaami!~imaami@imaami.fi> has quit IRC | 19:33 | |
| *** imaami <imaami!~imaami@imaami.fi> has joined #yocto | 19:33 | |
| fray | yes, it's recommended, but not required... the branch can be whatever you want, but then it's difficult for others to find.. | 19:34 |
| *** mihai <mihai!~mihai@unaffiliated/mihai> has quit IRC | 19:53 | |
| *** zyga <zyga!~zyga@unaffiliated/zyga> has quit IRC | 19:53 | |
| *** kpo_ <kpo_!~kpo@bwu34.internetdsl.tpnet.pl> has quit IRC | 19:53 | |
| *** mihai <mihai!~mihai@unaffiliated/mihai> has joined #yocto | 19:53 | |
| *** kpo_ <kpo_!~kpo@bwu34.internetdsl.tpnet.pl> has joined #yocto | 19:54 | |
| *** mihai <mihai!~mihai@unaffiliated/mihai> has quit IRC | 19:54 | |
| *** dahints <dahints!d4cc47cc@212.204.71.204> has quit IRC | 19:55 | |
| *** mihai <mihai!~mihai@unaffiliated/mihai> has joined #yocto | 19:56 | |
| *** derRichard <derRichard!~derRichar@static.16.105.130.94.clients.your-server.de> has quit IRC | 19:58 | |
| *** oberstet <oberstet!~oberstet@213.170.219.39> has quit IRC | 19:58 | |
| *** mihai <mihai!~mihai@unaffiliated/mihai> has joined #yocto | 19:58 | |
| *** derRichard <derRichard!~derRichar@static.16.105.130.94.clients.your-server.de> has joined #yocto | 19:58 | |
| *** B0ned1ger2 <B0ned1ger2!~B0ned1ger@82-135-139-249.static.zebra.lt> has joined #yocto | 20:00 | |
| vdl | fray: having a "dunfell" branch is great if you share your layer I think, not necessary at all if your layer is private. | 20:00 |
| *** B0ned1ger <B0ned1ger!~B0ned1ger@82-135-139-249.static.zebra.lt> has quit IRC | 20:03 | |
| vdl | bitbake seems to have "-dunfell" prefixed tags. | 20:04 |
| *** linums <linums!~linums@apn-94-44-225-50.vodafone.hu> has quit IRC | 20:05 | |
| *** linums <linums!~linums@natx-145.kulnet.kuleuven.be> has joined #yocto | 20:05 | |
| *** mihai <mihai!~mihai@unaffiliated/mihai> has quit IRC | 20:08 | |
| *** mihai <mihai!~mihai@unaffiliated/mihai> has joined #yocto | 20:08 | |
| *** linums <linums!~linums@natx-145.kulnet.kuleuven.be> has quit IRC | 20:12 | |
| *** linums <linums!~linums@apn-94-44-225-50.vodafone.hu> has joined #yocto | 20:14 | |
| *** gpanders <gpanders!~gpanders@c-73-228-7-205.hsd1.nm.comcast.net> has quit IRC | 20:15 | |
| *** gpanders <gpanders!~gpanders@c-73-228-7-205.hsd1.nm.comcast.net> has joined #yocto | 20:15 | |
| sakoman | bitbake for dunfell is 1.46 | 20:16 |
| *** gpanders <gpanders!~gpanders@c-73-228-7-205.hsd1.nm.comcast.net> has quit IRC | 20:17 | |
| *** zyga <zyga!~zyga@unaffiliated/zyga> has joined #yocto | 20:18 | |
| *** gpanders <gpanders!~gpanders@gateway/tor-sasl/gpanders> has joined #yocto | 20:18 | |
| *** linums <linums!~linums@apn-94-44-225-50.vodafone.hu> has quit IRC | 20:20 | |
| *** gpanders <gpanders!~gpanders@gateway/tor-sasl/gpanders> has quit IRC | 20:21 | |
| *** gpanders <gpanders!~gpanders@gateway/tor-sasl/gpanders> has joined #yocto | 20:22 | |
| *** linums <linums!~linums@84.198.214.27> has joined #yocto | 20:22 | |
| mischief | ptsneves: i tried it just now. the sdk installer still has stuff i dont want in it, and i do not understand why. | 20:27 |
| mischief | i feel like i am missing a doc or something that would help me understand how sdk is made. | 20:28 |
| *** aidanh_ <aidanh_!~aidanh@unaffiliated/aidanh> has joined #yocto | 20:29 | |
| *** aidanh <aidanh!~aidanh@unaffiliated/aidanh> has quit IRC | 20:29 | |
| *** aidanh_ is now known as aidanh | 20:29 | |
| *** minimaxwell <minimaxwell!~minimaxwe@atoulouse-258-1-35-192.w90-55.abo.wanadoo.fr> has quit IRC | 20:30 | |
| mischief | oh. m( of course, MACHINE_ESSENTIAL_EXTRA_RDEPENDS is pulled by packagegroup-core-boot. | 20:31 |
| *** zyga <zyga!~zyga@unaffiliated/zyga> has quit IRC | 20:34 | |
| *** OnkelUlla <OnkelUlla!~uol@ptx.hi.pengutronix.de> has quit IRC | 20:35 | |
| *** linums <linums!~linums@84.198.214.27> has quit IRC | 20:37 | |
| *** linums <linums!~linums@apn-94-44-225-50.vodafone.hu> has joined #yocto | 20:38 | |
| *** B0ned1ger <B0ned1ger!~B0ned1ger@78-60-213-230.static.zebra.lt> has joined #yocto | 20:41 | |
| *** mrc3 <mrc3!~mrc3@linaro/mrc3> has quit IRC | 20:42 | |
| *** B0ned1ger2 <B0ned1ger2!~B0ned1ger@82-135-139-249.static.zebra.lt> has quit IRC | 20:44 | |
| *** B0ned1ger <B0ned1ger!~B0ned1ger@78-60-213-230.static.zebra.lt> has quit IRC | 20:46 | |
| *** linums <linums!~linums@apn-94-44-225-50.vodafone.hu> has quit IRC | 20:52 | |
| *** linums <linums!~linums@apn-94-44-225-50.vodafone.hu> has joined #yocto | 20:53 | |
| *** linums <linums!~linums@apn-94-44-225-50.vodafone.hu> has quit IRC | 20:54 | |
| *** linums <linums!~linums@natx-145.kulnet.kuleuven.be> has joined #yocto | 20:54 | |
| *** mrc3 <mrc3!~mrc3@linaro/mrc3> has joined #yocto | 20:55 | |
| *** linums <linums!~linums@natx-145.kulnet.kuleuven.be> has quit IRC | 20:56 | |
| *** linums <linums!~linums@apn-94-44-225-50.vodafone.hu> has joined #yocto | 20:56 | |
| *** rcoote <rcoote!~rcoote@ip-176-198-112-234.hsi05.unitymediagroup.de> has quit IRC | 20:57 | |
| *** mbulut <mbulut!~nameclash@ip1f121f26.dynamic.kabel-deutschland.de> has quit IRC | 20:59 | |
| *** Kyubi <Kyubi!~Kyubi@149.199.62.131> has quit IRC | 21:03 | |
| *** B0ned1ger <B0ned1ger!~B0ned1ger@78-60-213-230.static.zebra.lt> has joined #yocto | 21:04 | |
| *** linums <linums!~linums@apn-94-44-225-50.vodafone.hu> has quit IRC | 21:08 | |
| *** B0ned1ger <B0ned1ger!~B0ned1ger@78-60-213-230.static.zebra.lt> has quit IRC | 21:09 | |
| *** linums <linums!~linums@natx-145.kulnet.kuleuven.be> has joined #yocto | 21:09 | |
| *** aleblanc <aleblanc!~textual@192-222-183-114.qc.cable.ebox.net> has joined #yocto | 21:10 | |
| *** aleblanc <aleblanc!~textual@192-222-183-114.qc.cable.ebox.net> has quit IRC | 21:12 | |
| *** linums <linums!~linums@natx-145.kulnet.kuleuven.be> has quit IRC | 21:20 | |
| *** linums <linums!~linums@apn-94-44-225-50.vodafone.hu> has joined #yocto | 21:20 | |
| *** minimaxwell <minimaxwell!~minimaxwe@atoulouse-258-1-35-192.w90-55.abo.wanadoo.fr> has joined #yocto | 21:31 | |
| *** OnkelUlla <OnkelUlla!~uol@ptx.hi.pengutronix.de> has joined #yocto | 21:35 | |
| *** minimaxwell <minimaxwell!~minimaxwe@atoulouse-258-1-35-192.w90-55.abo.wanadoo.fr> has quit IRC | 21:36 | |
| *** vineela <vineela!~vtummala@134.134.139.72> has quit IRC | 21:38 | |
| *** ENPJ <ENPJ!~john@2001:a61:3a84:9501:6d11:2e24:da03:67e7> has joined #yocto | 21:52 | |
| *** ENPJ <ENPJ!~john@2001:a61:3a84:9501:6d11:2e24:da03:67e7> has joined #yocto | 21:53 | |
| *** ENPJ <ENPJ!~john@2001:a61:3a84:9501:6d11:2e24:da03:67e7> has left #yocto | 21:54 | |
| *** minimaxwell <minimaxwell!~minimaxwe@atoulouse-258-1-35-192.w90-55.abo.wanadoo.fr> has joined #yocto | 21:56 | |
| *** minimaxwell <minimaxwell!~minimaxwe@atoulouse-258-1-35-192.w90-55.abo.wanadoo.fr> has quit IRC | 22:00 | |
| dl9pf | RP: Reproducibility summary for rpm: same=9866 different=1513 different_excluded=56 missing=0 total=11435 | 22:00 |
| dl9pf | unused_exclusions=['babeltrace2-ptest', 'cups', 'efivar', 'git', 'go_', 'libcap-ng', 'libproxy', 'ltp', 'meson', 'rsync', 'syslinux-misc'] | 22:00 |
| *** vineela <vineela!vtummala@nat/intel/x-ptdcmewswpyppqvl> has joined #yocto | 22:01 | |
| *** zyga <zyga!~zyga@unaffiliated/zyga> has joined #yocto | 22:04 | |
| *** tgoodwin <tgoodwin!~tgoodwin@static-96-234-151-198.bltmmd.fios.verizon.net> has quit IRC | 22:08 | |
| JPEW | dl9pf: Good start! Not as bad as I thought it would be | 22:10 |
| dl9pf | JPEW: that was just a macro missing, let's see what is left | 22:10 |
| JPEW | which macro? | 22:11 |
| dl9pf | --define "use_source_date_epoch_as_buildtime 1" | 22:12 |
| JPEW | dl9pf: Ah, nice! | 22:12 |
| dl9pf | but the oe-selftest did crash my server twice today, so I have no local build so far | 22:12 |
| JPEW | dl9pf: Ya, the world reproducible build test is brutal | 22:13 |
| *** medaliyou <medaliyou!29e2aabb@41.226.170.187> has quit IRC | 22:15 | |
| *** mihai- <mihai-!~mihai@unaffiliated/mihai> has joined #yocto | 22:15 | |
| *** tgamblin <tgamblin!~tgamblin@cpe64777de11593-cm64777de11590.cpe.net.cable.rogers.com> has quit IRC | 22:15 | |
| *** tgamblin <tgamblin!~tgamblin@cpe64777de11593-cm64777de11590.cpe.net.cable.rogers.com> has joined #yocto | 22:16 | |
| dl9pf | core-image-minimal just finished ... glibc-*locale* glibc-charmap* glibc-gconv os-release, libgcc-s libstdc++ | 22:17 |
| *** mihai <mihai!~mihai@unaffiliated/mihai> has quit IRC | 22:18 | |
| dl9pf | seems like some created files have the build-time as mtime in the rpm | 22:23 |
| *** ENPJ_ <ENPJ_!~quassel@2001:a61:3a84:9501:6d11:2e24:da03:67e7> has joined #yocto | 22:25 | |
| *** beneth` <beneth`!~beneth@irc.beneth.fr> has left #yocto | 22:25 | |
| *** linums <linums!~linums@apn-94-44-225-50.vodafone.hu> has quit IRC | 22:25 | |
| *** linums <linums!~linums@natx-145.kulnet.kuleuven.be> has joined #yocto | 22:26 | |
| dl9pf | e.g. /etc/securetty , /usr/share/i18n/localedata | 22:29 |
| dl9pf | they do have buildtime vs. source_date_epoch | 22:30 |
| *** linums <linums!~linums@natx-145.kulnet.kuleuven.be> has quit IRC | 22:30 | |
| *** linums <linums!~linums@apn-94-44-225-50.vodafone.hu> has joined #yocto | 22:32 | |
| dl9pf | looks to me like files that we copy in or create, and a lot of folders created with install -d ... | 22:32 |
| *** ptsneves <ptsneves!b0dd7824@176.221.120.36> has quit IRC | 22:37 | |
| *** ENPJ_ is now known as ENPJ | 22:38 | |
| dl9pf | no diff in the binaries themselves so far. all just mtime (?) | 22:40 |
| *** minimaxwell <minimaxwell!~minimaxwe@atoulouse-258-1-35-192.w90-55.abo.wanadoo.fr> has joined #yocto | 22:51 | |
| *** comptroller <comptroller!~comptroll@47-213-222-227.paolcmtc01.res.dyn.suddenlink.net> has quit IRC | 22:53 | |
| *** ENPJ <ENPJ!~quassel@2001:a61:3a84:9501:6d11:2e24:da03:67e7> has quit IRC | 22:57 | |
| *** minimaxwell <minimaxwell!~minimaxwe@atoulouse-258-1-35-192.w90-55.abo.wanadoo.fr> has quit IRC | 22:59 | |
| *** B0ned1ger <B0ned1ger!~B0ned1ger@78-60-213-230.static.zebra.lt> has joined #yocto | 23:05 | |
| *** B0ned1ger <B0ned1ger!~B0ned1ger@78-60-213-230.static.zebra.lt> has quit IRC | 23:10 | |
| *** zyga <zyga!~zyga@unaffiliated/zyga> has quit IRC | 23:16 | |
| *** agust <agust!~agust@p508b6a6d.dip0.t-ipconnect.de> has quit IRC | 23:18 | |
| *** gendevbot <gendevbot!~devbot@176.235.187.234> has quit IRC | 23:21 | |
| *** gendevbot_ <gendevbot_!~devbot@176.235.187.234> has joined #yocto | 23:21 | |
| *** vineela <vineela!vtummala@nat/intel/x-ptdcmewswpyppqvl> has quit IRC | 23:22 | |
| *** vineela <vineela!~vtummala@134.134.139.72> has joined #yocto | 23:28 | |
| *** mrpelotazo <mrpelotazo!~mrpelotaz@HSI-KBW-078-042-006-202.hsi3.kabel-badenwuerttemberg.de> has quit IRC | 23:30 | |
| dl9pf | hmm I see in rpm sources, there is a fakeStat call that takes 'now' and does not obey source_date_epoch ... for %ghost and %dev | 23:33 |
| fray | ghost files don't exist.. they are owned by the package, but no contents.. dev is the same.. | 23:34 |
| fray | (dev is 'created' at the time the package is installed) | 23:34 |
| dl9pf | ok | 23:36 |
| dl9pf | thanks for the explanation | 23:37 |
| dl9pf | so the question is back to where 'now' comes from | 23:37 |
| dl9pf | in the header for content | 23:37 |
| fray | I don't know the implementation, but I had assumed the 'now' was at the time the package was _installed_ not built.. | 23:37 |
| fray | but if the now is calculated "when built", then it'll need some sort of patch | 23:38 |
| dl9pf | it is build time in my diffoscope ... | 23:40 |
| fray | ya, so you'll have to patch and capture the 'now' and allow it to be passed in... | 23:41 |
| RP | dl9pf: can you separate out the package_rpm.bbclass change and send it alone so we can merge that bit? | 23:41 |
| RP | dl9pf: sounds like good progress at least | 23:41 |
| *** mrpelotazo <mrpelotazo!~mrpelotaz@HSI-KBW-078-042-006-202.hsi3.kabel-badenwuerttemberg.de> has joined #yocto | 23:42 | |
| dl9pf | yes | 23:42 |
| dl9pf | https://usercontent.irccloud-cdn.com/file/JJBRkeaR/image.png | 23:42 |
| *** mrpelotazo <mrpelotazo!~mrpelotaz@HSI-KBW-078-042-006-202.hsi3.kabel-badenwuerttemberg.de> has quit IRC | 23:43 | |
| dl9pf | RP: yes, will send a separate patch tomorrow | 23:43 |
| dl9pf | Zzzzz | 23:44 |
| dl9pf | the files are links and dirs for example ... | 23:44 |
| *** mrpelotazo <mrpelotazo!~mrpelotaz@HSI-KBW-078-042-006-202.hsi3.kabel-badenwuerttemberg.de> has joined #yocto | 23:45 | |
| RP | dl9pf: I've been wondering how those get the correct timestamps in the ipk/debs :/ | 23:46 |
| fray | if it's using time() or date() then it can likely be intercepted | 23:46 |
| dl9pf | i still think we end-up in: | 23:48 |
| dl9pf | https://usercontent.irccloud-cdn.com/file/x3uzSnry/image.png | 23:49 |
| RP | dl9pf: we'd really want SDE in there... | 23:51 |
| *** linums <linums!~linums@apn-94-44-225-50.vodafone.hu> has quit IRC | 23:51 | |
| dl9pf | in the morning ... | 23:53 |
| RP | dl9pf: yes, I'm heading to bed :) | 23:53 |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!
