Wednesday, 2021-02-17

dl9pfrpm metadata ... some hashes and the BUILDTIME ... all in the rpm header00:04
*** ayoung <ayoung!~ayoung@2601:19c:4680:ee30::83cb> has quit IRC00:04
*** bps <bps!~bps@> has quit IRC00:07
*** ayoung <ayoung!~ayoung@2601:19c:4680:ee30::83cb> has joined #yocto00:13
*** adelcast1 <adelcast1!> has joined #yocto00:17
dl9pfSIGMD5, SHA1HEADER, SHA256HEADER, BUILDTIME ... everything else is fine00:24
*** linums <linums!~linums@> has quit IRC00:24
*** Dracos-Carazza <Dracos-Carazza!~Dracos-Ca@> has quit IRC00:24
*** linums <linums!> has joined #yocto00:24
frayya, it's important when checking RPMs on a rebuild to only diff the actual contents that are not actually package specific..00:25
frayfor security purposes packages do get information when they were built to avoid 'look-alikes'00:25
frayit might be possible set those values -- but if you are actually building them then you wanted a new one for some reason.00:25
frayFrom 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 equivalency00:26
dl9pfuff ...
*** Dracos-Carazza <Dracos-Carazza!~Dracos-Ca@> has joined #yocto00:28
frayI've done things with RPM if FIPS mode before.. it's not as hard as people think..00:31
*** zeddii <zeddii!> has quit IRC00:31
frayFIPS doesn't say you can have MD5 or SHA1.. it says you can't use them in security critical components.00:31
fraySo 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!> has quit IRC00:32
frayThis 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 methods00:32
*** mrc3 <mrc3!~mrc3@linaro/mrc3> has quit IRC00:33
dl9pfi mean in 'this will stick around for quite some'00:33
*** adelcast1 <adelcast1!> has joined #yocto00:33
frayit will that is what happens when you have an installed base..00:33
fraythe work to dump MD5SUM and SHA1 _started_ almost 10 years ago00:34
dl9pfso basically our diff needs to adapt and skip these00:34
frayRed Hat though rejected many of the changes for various reasons (good and bad)00:34
frayyes, there is already an 'rpm-diff' that will skip those headers (or there was last time I used it)00:34
dl9pfor rpm-diff00:35
RPdl9pf: We really do want deterministic rpms. Can we not set BUILDTIME to SOURCE_DATE_EPOCH?00:35
fraythat is what I'd recommend.. but I do question why we are rebuilding RPMs (if they're already cached)..00:35
frayif 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.. fields00:36
*** leon-anavi <leon-anavi!~Leon@> has quit IRC00:36
frayRPM 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
RPfray: 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 work00:38
RPdl9pf: keep in mind we can patch rpm if needed00:38
RPprefer not to obviously00:38
fraythe 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
fraythe date is the only piece we really can set..00:38
RPfray: so it might just be BUILDTIME and if we have to patch it to set that...00:39
* RP -> Zzzz00:40
dl9pfok, let's ponder tomorrow about BUILDTIME00: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__!> has joined #yocto00:46
*** zeddii <zeddii!> has joined #yocto00:48
*** linums <linums!> has quit IRC00:48
*** aquijoule_ <aquijoule_!> has quit IRC00:48
*** linums <linums!~linums@> has joined #yocto00:48
*** csd <csd!> has quit IRC00:49
*** csd <csd!> has joined #yocto00:49
*** zeddii <zeddii!> has quit IRC00:55
*** adelcast1 <adelcast1!> has quit IRC00:55
*** zeddii <zeddii!> has joined #yocto00:57
*** intera91 <intera91!> has quit IRC01:13
*** andycooper <andycooper!uid246432@gateway/web/> has quit IRC01:20
*** vineela <vineela!vtummala@nat/intel/x-gmjdszkdupcedvxe> has quit IRC01:29
*** goliath <goliath!> has quit IRC01:47
*** linums <linums!~linums@> has quit IRC01:52
*** stephano <stephano!~stephano@> has quit IRC01:52
*** linums <linums!~linums@> has joined #yocto01:53
*** adelcast1 <adelcast1!> has joined #yocto01:59
*** sakoman <sakoman!> has quit IRC02:16
*** sakoman <sakoman!> has joined #yocto02:21
*** rcw <rcw!~rcwoolley@> has quit IRC02:54
*** dev1990_ <dev1990_!> has joined #yocto03:04
*** dev1990 <dev1990!> has quit IRC03:05
*** mrc3 <mrc3!~mrc3@linaro/mrc3> has joined #yocto03:06
*** imcleod_ <imcleod_!> has quit IRC03:11
*** ahadi <ahadi!> has quit IRC03:13
*** ahadi <ahadi!~ahadi@> has joined #yocto03:14
*** dreyna <dreyna!> has quit IRC03:40
*** f0h <f0h!> has quit IRC03:49
*** f0h <f0h!> has joined #yocto03:50
*** imcleod_ <imcleod_!~imcleod@2601:249:8200:1ba1:af65:6e6f:10d:e757> has joined #yocto03:55
*** f0h <f0h!> has quit IRC03:57
*** f0h <f0h!> has joined #yocto03:57
*** dreyna <dreyna!> has joined #yocto04:21
*** linums <linums!~linums@> has quit IRC04:40
*** linums <linums!> has joined #yocto04:40
*** imcleod_ <imcleod_!~imcleod@2601:249:8200:1ba1:af65:6e6f:10d:e757> has quit IRC04:42
*** linums <linums!> has quit IRC04:45
*** linums <linums!~linums@> has joined #yocto04:46
*** crawler <crawler!> has quit IRC04:55
*** crawler <crawler!> has joined #yocto04:57
*** Ad0 <Ad0!~Ad0@> has quit IRC05:43
*** Ad0 <Ad0!~Ad0@> has joined #yocto05:44
*** Ad0 <Ad0!~Ad0@> has quit IRC05:53
*** Ad0 <Ad0!~Ad0@> has joined #yocto06:03
*** armpit <armpit!> has quit IRC06:16
*** alessioigor <alessioigor!> has joined #yocto06:17
*** vijay <vijay!a4a45f09@> has joined #yocto06:25
*** AndersD <AndersD!> has joined #yocto06:32
*** B0ned1ger <B0ned1ger!> has joined #yocto06:32
*** minimaxwell <minimaxwell!> has joined #yocto06:34
*** AndersD_ <AndersD_!> has joined #yocto06:35
*** AndersD <AndersD!> has quit IRC06:38
*** beneth` <beneth`!> has joined #yocto06:38
*** w00die <w00die!~w00die@> has quit IRC06:57
*** w00die <w00die!~w00die@> has joined #yocto06:59
*** dreyna <dreyna!> has quit IRC06:59
*** thaytan <thaytan!~thaytan@> has quit IRC07:01
*** thaytan <thaytan!~thaytan@> has joined #yocto07:03
*** aleblanc <aleblanc!> has quit IRC07:04
*** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has joined #yocto07:06
*** zyga <zyga!~zyga@unaffiliated/zyga> has joined #yocto07:13
*** ENPJ <ENPJ!> has joined #yocto07:14
*** agust <agust!> has joined #yocto07:19
*** jobroe <jobroe!> has joined #yocto07:26
*** georgem_home <georgem_home!uid210681@gateway/web/> has quit IRC07:27
*** goliath <goliath!> has joined #yocto07:32
*** LetoThe2nd <LetoThe2nd!uid453638@gateway/web/> has joined #yocto07:33
*** rcoote <rcoote!> has joined #yocto07:40
*** mckoan|away is now known as mckoan07:41
*** frsc <frsc!> has joined #yocto07:45
*** B0ned1ger <B0ned1ger!> has quit IRC07:48
*** B0ned1ger2 <B0ned1ger2!> has joined #yocto07:48
LetoThe2ndyo dudX07:50
mckoangood morning07:50
*** gsalazar <gsalazar!955a6fad@gateway/web/cgi-irc/> has joined #yocto07:54
*** fl0v0 <fl0v0!> has joined #yocto08:01
*** bps <bps!~bps@> has joined #yocto08:13
mseeberGreetings, 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
LetoThe2ndmseeber: are only the cached git repo accesses problematic?08:21
mseeberI 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
LetoThe2ndmseeber: ok, but all recipes that access some form of archive/tarball are happy?08:24
mseeberThey do work, yes08:25
*** leon-anavi <leon-anavi!~Leon@> has joined #yocto08:25
LetoThe2ndi see. what release are you on?08:25
mseeberpoky version is sumo08:28
LetoThe2ndcheck if it also fails on dunfell, and if not, go hunting for the patch in the git fetcher.08:29
LetoThe2ndif it still fails then, please report a bug.08:29
LetoThe2ndrepectively, if it still fails on master.08:30
mseeberalright, thanks08:30
mihaimseeber: or maybe the remote is _that_ slow and you're stuck waiting08:30
*** manuel_ <manuel_!> has joined #yocto08:31
LetoThe2ndmihai: then the effect would be witnessed on something recent too, probably. unless there already is handling for it in place.08:32
LetoThe2ndin any case i think all effort on sumo support is wasted :)08:32
mcfriskmseeber: yes, check if you can manually download the SRC_URI's of the affected recipe, the repos and servers can indeed be really slow08:32
mseeberprobably not, i did test with and without nfs, so the remote repo is probably fine08:32
mcfriskwell, 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@> has quit IRC08:36
*** Yumasi <Yumasi!~guillaume@2a01:e0a:5cb:4430:a218:d301:729d:d5b3> has joined #yocto08:37
*** JosephAntony <JosephAntony!a5e17a63@> has joined #yocto08:37
*** oberstet <oberstet!~oberstet@> has joined #yocto08:49
*** manuel_ <manuel_!> has quit IRC08:50
* mcfrisk tried to get permission to maintain sumo publicly...09:00
LetoThe2ndmcfrisk: let me know when you make it, i'll buy you some new pants!09:01
*** frsc <frsc!> has quit IRC09:08 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!> has joined #yocto09:16
*** vijay <vijay!a4a45f09@> has quit IRC09:29
*** medaliyou <medaliyou!29e2aabb@> has joined #yocto09:30
medaliyouHi Guys09:30
medaliyouLAYERSERIES_COMPAT_meta-XYZ = "thud"09:31
medaliyoui ve cloned with dunfell branch09:31
medaliyouwhat happens if i change this line ' LAYERSERIES_COMPAT_meta-XYZ = "thud" ' to ' LAYERSERIES_COMPAT_meta-XYZ = "dunfell" ' or just comment it09:32
medaliyouwould it break things ?09:32
mcfriskLetoThe2nd: tried, but failed :( no need for new pants09:32
LetoThe2ndmcfrisk: aww.09:33
medaliyouLetoThe2nd can you help me please !!!09:34
medaliyoui m working on existing yocto project & triying to optimize boot time.09:35
LetoThe2ndmedaliyou: go and find out. it might work if there are no specific dependencies, it might break if there are.09:36
medaliyoualright , thank you09:36
*** manuel_ <manuel_!~manuel198@> has joined #yocto09:47
*** bps <bps!~bps@> has joined #yocto09:50
RPgah, 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 IRC09:56
*** manuel_ <manuel_!~manuel198@> has quit IRC10:01
*** manuel1985 <manuel1985!~manuel198@> has joined #yocto10:02
*** B0ned1ger2 <B0ned1ger2!> has quit IRC10:06
*** B0ned1ger <B0ned1ger!> has joined #yocto10:07
*** mseeber <mseeber!> has joined #yocto10:26
mcfriskRP: fun with git and file time stamps, been there too.
mcfriskmy 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
mcfriskand git annex too10:58
*** ptsneves <ptsneves!b0dd7824@> has joined #yocto11:00
RPmcfrisk: right, I can see why it does it, I was just being dumb with my previous fix :/11:02
qschulzI 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 documentation11:12
qschulzit 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
qschulzhow dirty is it to look into ${B}/<package-name>/ to make a mapping of UUIDs to package-name?11:13
*** JosephAntony <JosephAntony!a5e17a63@> has quit IRC11:25
*** B0ned1ger2 <B0ned1ger2!> has joined #yocto11:31
*** frsc <frsc!> has quit IRC11:32
*** frsc <frsc!> has joined #yocto11:33
*** B0ned1ger <B0ned1ger!> has quit IRC11:34
*** B0ned1ger2 <B0ned1ger2!> has quit IRC11:35
dl9pfRP: if (srcdate && rpmExpandNumeric("%{?use_source_date_epoch_as_buildtime}")) {11:44
dl9pfso where do we set the default macros ?11:44
*** kpo_ <kpo_!> has quit IRC11:44
*** kpo_ <kpo_!> has joined #yocto11:45
RPdl9pf: package_rpm.bbclass, see the --defines I think11:49
dl9pf--define "%source_date_epoch_from_changelog 1"11:50
dl9pf--define "%clamp_mtime_to_source_date_epoch 1"11:51
RPdl9pf: hmm, I don't see the changelog piece here11:51
dl9pfah ... ignore, thats suse specific11:52
dl9pf--define "%use_source_date_epoch_as_buildtime 1"11:52
RPthat sounds promising11:52
dl9pfcompared with
dl9pfso let's try mtime and buildtime and see11:53
RPdl9pf: mtime is already there I think11:53
dl9pfchecking package_rpm.bbclass now11:53
*** sstiller <sstiller!> has joined #yocto11:53
ptsnevesqschulz it seems that you need to roll your own packaging function11:55
qschulzptsneves: I can do something by reading the source directory but that feels wrong somehow :/11:56
dl9pfsent a v211:58
ptsnevesi 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!> has joined #yocto11:58
ptsnevesi 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
RPqschulz: If my local "make do_install an sstate task" change does go in it would break that12:00
*** B0ned1ger2 <B0ned1ger2!> has joined #yocto12:00
qschulzRP: mmmm how so? is there a cleandirs somewhere that would remove the ${S} or ${B} directory before do_package is run?12:01
qschulzbasically, I have ${S}/package-name/transaltions/<UUID> which gets installed into ${D}/usr/share/translations/12:02
qschulzand UUID != packagename, so for now I do a glob search in S, to get package-name-UUID mapping12:02
qschulzand I manually append /usr/share/translations/UUID to FILES_${PN}-<package-name>12:03
*** B0ned1ger <B0ned1ger!> has quit IRC12:03
RPqschulz: if do_install comes from sstate, ${S}/${B} won't be populated12:03
qschulzRP: duh, obviously. /me facepalms himself :)12:04
RPqschulz: could you install some symlink which would help the code know where things go?12:05
RPpackage it off into the -dev where you don't care12:05
RPdl9pf: is running with it12:06
*** georgem_home <georgem_home!uid210681@gateway/web/> has joined #yocto12:06
RPdl9pf: I'm worried your test "reproduced" for you :/12:07
qschulzRP: I'd still need to manually package them (getvar(fiels_pn), setvar(files_pn)) instead of using do_split_packages then :/12:09
qschulzi'll ask upstream to change how they do it and use subdirs for those files too :)12:09
ptsnevesRP do_install has a setscene version?12:15
RPptsneves: not yet but I have patches and ideas12:17
dl9pfit did produce these numbers, but with the dunfell selftest12:17
RPdl9pf: I'd be interested what you get with master. I'm worried it doesn't match what we see on the autobuilder, admittedly with master12:17
dl9pfmy build machine just crashed running the selftest ...12:18
*** tgoodwin <tgoodwin!> has joined #yocto12: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
RPdl9pf: I probably shouldn't see that as an achievement, right? :)12:19
RPptsneves: it would allow repackaging without rebuilding everything. It also makes binary only distribution easier12:19
*** TheComet <TheComet!~hpom0@> has joined #yocto12:21
TheCometIs it possible to compile two different repositories in the same recipe?12:21
ptsnevesRP do you already have an RFC for it?12:22
RPptsneves: my patches don't quite work12:22
TheCometI would like to combine 2 repos into one package if that's somehow possible12:22
ptsnevesTheComet yes. Just merge them into a way they both work, or just call the build system for each of the repos12:22
RPTheComet: you can put multiple entries in SRC_URI12:23
ptsnevesTheComet i mean merge them in the WORKDIR.12:23
TheCometAh I would need to write my own do_compile() to call make twice?12:23
ptsnevesRP  you comfortable in sharing them already?12:23
ptsnevesTheComet if they are independent yes.12:24
TheCometAlright thanks12:24
RPptsneves: and
dl9pfRP: probably a faulty DIMM12:24
TheCometIs that the best way though, or is there an easy way to merge the compile results of two recipes into one package?12:25
TheCometBecause I do think I should leverage the default do_compile()/do_install() stuff12:25
ptsnevesTheComet It depends, but it is style. Conventionally you have different recipes for each repo. Are these 2 repos usable independently?12:26
TheCometptsneves: 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 other12:27
ptsnevesor 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 unconventional?12:27
ptsnevesTheComet so i would not build them together. If they have very similar way of building you can just have a common .inc file12:28
TheCometptsneves: 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 together12:30
ptsnevesi may be wrong but i think you can do that in the packagegroup12:31
TheCometI haven't looked at packagegroup at all but I think that might be exactly what I need12:31
TheCometI'll look into it thanks!12:31
ptsneveseven 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
ptsnevesabove all fullfil you client needs and think of your future self as a maintainer12:32
TheCometI sure hope I don't have to maintain this dumpsterfire in the future :D12:33
*** imcleod_ <imcleod_!~imcleod@2601:249:8200:1ba1:af65:6e6f:10d:e757> has joined #yocto12:34
ptsnevesTheComet 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. :D12:35
TheCometCan 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 with12:37
ptsnevesi dont think so but you can RDEPENDS on specific versions12:38
ptsnevesor version semantics12:38
RPTheComet: RDEPENDS_foo = "bar (=1.0.0)"12:39
TheCometHmm, can I not "bitbake foo"? I created a wich defines PACKAGES = "packagegroup-foo" and RDEPENDS_packagegroup-foo = "bar (=1.0.0) baz (=1.0.0)"12:44
ptsnevesTheComet you can. What did it not achieve?12:45
RPTheComet: dependencies don't make sense in PACKAGES12:45
RPah, sorry, I misread12:46
TheCometIt's saying "Nothing PROVIDES foo"12:46
TheComet"bitbake foo-1.0.0" seems to work though12:46
ptsnevesbecause the recipe should be foo_1.0.0.b12:46
TheCometOooh, of course12:46
*** vineela <vineela!~vtummala@> has joined #yocto13:18
*** andycooper <andycooper!uid246432@gateway/web/> has joined #yocto13:28
*** koobla23 <koobla23!50f3ae5c@> has joined #yocto13: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
LetoThe2ndjonesv[m]: look at meta/recipes-core/packagegroup-base13:44
LetoThe2ndjonesv[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
LetoThe2ndrewording... 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
LetoThe2ndjonesv[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 usbgadget13:50
LetoThe2ndjonesv[m]: check /proc/config.gz first.13:51
*** koobla23 <koobla23!50f3ae5c@> has quit IRC14:01
*** svogl <svogl!50f3ae5c@> has joined #yocto14:02
*** TheComet <TheComet!~hpom0@> has quit IRC14:08
*** Ad0 <Ad0!~Ad0@> has quit IRC14:17
*** minimaxw1ll <minimaxw1ll!> has joined #yocto14:18
*** minimaxwell <minimaxwell!> has quit IRC14:20
*** mbulut <mbulut!> has joined #yocto14:21
*** Ad0 <Ad0!~Ad0@> has joined #yocto14:21
*** mbulut <mbulut!> has quit IRC14:23
ENPJrauc status14:24
*** mbulut <mbulut!> has joined #yocto14:24
*** awafaa_ is now known as awafaa14:26
*** minimaxw1ll is now known as minimaxwell14:34
*** TheComet <TheComet!~hpom0@> has joined #yocto14:40
dl9pfRP: seems done, error seems unrelated ?14:50
RPdl9pf: yes, other master-next issues, sorry :(14:54
*** kaspter <kaspter!~Instantbi@2409:8a1e:911f:ee70:f0ba:ded9:f1f6:7520> has joined #yocto14:57
*** sstiller <sstiller!> has quit IRC15:03
*** armpit <armpit!~armpit@2601:202:4180:a5c0:7db1:8052:decd:2a75> has joined #yocto15:04
qschulzI'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 binary15:05
qschulzbut... 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 qmake15: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 already15:06
*** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has quit IRC15:11
*** linums <linums!~linums@> has quit IRC15:13
medaliyouhey guys , what to do if qemu-native15:14
medaliyoukeeps on failing on do_compile15:15
medaliyouqemu-3.0.0/linux-user/syscall.c:8526: undefined reference to `stime'15:15
*** linums <linums!54c6d61b@> has joined #yocto15:16
qschulzmedaliyou: what's the distribution of your host machine? which version of Yocto are you building?15:17
ptsnevesisnt that an issue of glibc mismatch?15:17
ptsneveslooks like you need a newer uninative15:18
medaliyouBB_VERSION           = "1.40.0"15:19
medaliyouBUILD_SYS            = "x86_64-linux"15:19
medaliyouNATIVELSBSTRING      = "ubuntu-20.04"15:19
medaliyouTARGET_SYS           = "arm-tdx-linux-gnueabi"15:19
medaliyouMACHINE              = "colibri-imx7"15:19
medaliyouDISTRO               = "tdx-x11"15:19
medaliyouDISTRO_VERSION       = "2.6-snapshot-20210217"15:19
medaliyouTUNE_FEATURES        = "arm armv7a vfp thumb neon callconvention-hard"15:19
medaliyouTARGET_FPU           = "hard"15:19
RPdl9pf: trying again
medaliyoui rebuilded glibc15:20
*** King_InuYasha is now known as Conan_Kudo15:20
*** Conan_Kudo is now known as King_InuYasha15:20
qschulzmedaliyou: ubuntu 20.04 is not supported for thud15:21
jonesv[m]<LetoThe2nd "jonesv: check /proc/config.gz fi"> Not completely sure what I'm looking for, actually 🤔.15:21
frayeither 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
LetoThe2ndjonesv[m]: hum what is not clear about it?15:22
mckoanmedaliyou: why you don't use TDX BSP 5.2 ?15:22
medaliyoushould 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
qschulzmedaliyou: thud is unmaintained so, short answer yes. Otherwise, backport and expect more breakage for other packages that can't build on ubuntu 20.0415:24
LetoThe2ndjonesv[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 it15:24
LetoThe2ndjonesv[m]: have you looked at the packagegroup i named? to see which modules it actually tries to pull in?15:25
*** kpo_ <kpo_!> has quit IRC15:25
*** kpo_ <kpo_!> has joined #yocto15:26
qschulzjonesv[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 for15:26
*** Anarky <Anarky!> has quit IRC15:26
medaliyouis the migrating process hard (i mean i have kernel patches and various modules hodling on kernel v 4.14.9X) '=( '=(15:26
*** mseeber <mseeber!> has quit IRC15:26
jonesv[m]<LetoThe2nd "jonesv: have you looked at the p"> ```15:27
LetoThe2ndqschulz: 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
qschulzmedaliyou: 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 it15: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!> has quit IRC15:31
*** frsc <frsc!> has joined #yocto15:31
*** ssajal <ssajal!> has joined #yocto15:31
linumshi guys15:33
linumsI am on the master channel right now15:34
linumsand I noticed that the kea package is from a development branch, not from the master15:34
qschulzjonesv[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
linumsis it an mistake, or is it intentional?15:35
RPlinums: was that not because that was where the release commit tag was?15:35
qschulzjonesv[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 #yocto15: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 release15:36
qschulzthat'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 appropriately15:36
hmw1Hi yocto started to create a folder morgue in the deploy/ipk/ARCH/morgue and it is putting the current install files there15:37
linumsbut I am right though, that dev version should not be under the yocto master15: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 IRC15:42
RPlinums: master appears to use 1.8.2 which is a main release?15:44
*** Anarky <Anarky!> has joined #yocto15:47
*** TheComet <TheComet!~hpom0@> has quit IRC15:50
*** AndersD_ <AndersD_!> has quit IRC15:50
*** Kyubi <Kyubi!~Kyubi@> has joined #yocto15:54
linumsyeah, I've checked, I'm a little late from the master15:57
linumsat the time I've cloned it, it was using 1.7.1015:57
*** B0ned1ger <B0ned1ger!> has joined #yocto15:59
*** B0ned1ger2 <B0ned1ger2!> has quit IRC16:02
*** B0ned1ger <B0ned1ger!> has quit IRC16:04
qschulzJPEW: 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
JPEWqschulz: Ya, probably. Do you want to open a PR?16:05
qschulzJPEW: I could, do you have CI to test I'm not breaking stuff :D16:05
JPEWqschulz: Yes! I actually just got it working with GitHub actions yesterday!16:06
RPlinums: right, we fixed things to only get even numbers16:07
linumsseee,cool, thanks16:08
*** minimaxwell <minimaxwell!> has quit IRC16:11
*** svogl <svogl!50f3ae5c@> has quit IRC16:12
qschulzJPEW: oh wow, the Github actions don't look super straightforward :o16:16
frayI'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
frayUsing a github action to trigger something in my environment seems a lot less dangerous..  just an observation16:17
qschulzfray: wasn't it already the case with Travis which was the defacto standard for CI/CD in FOSS?16:17
qschulzor maybe I misunderstood what you said?16:17
fraydefacto 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
fraybut 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
JPEWqschulz: Travis and GitHub actions are pretty equivalent for my purposes16: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
fraywhen 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
JPEWfray: Ya, It would be nice if there was some standardized "CI language" that worked anywhere16:19
fraythink 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 problem16: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
JPEWfray: 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 another16:22
fraygreat work for the person who sells the service contract.. :)16:22
qschulzfray: Travis and Github actions are (were) free16:22
fraybugzilla was free too.. ;)16:22
JPEWTravis is no more16:22
qschulzso for FOSS projects, it makes sense16:22
qschulzJPEW: hence the "were" :)16:22
fraythe point is following their precise language that is specific leads to lock-in.. if you know that going in.. fine.. no problem..16:23
qschulzfray: what companies do is their problem and I would see Jenkins or similar stuff then, that YOU own :)16:23
fraybut 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 ecosystem16:23
qschulzfray: free stuff always comes with a price :)16:23
frayit's any software interface you don't control.  just have to make informed decisions on where and how you use the tooling..16:24
qschulzfray: on more or less the same topic, it's sad that github is where all the work is done :/16:24
frayI've seen IMHO a lack of informed decisions and people jump into github thinking it's "the only way"16:24
fraythey're going to be burned when those interfaces change16:24
frayI _LIKE_ github, I don't mind Microsoft owning them..  but like anything else, I worry it has a commercial focus -- so things will eventually change16:25
fray(I never did like gitlab or sourceforge.. never really understood why, but I never liked them -- likely interface)16:25
*** B0ned1ger <B0ned1ger!> has joined #yocto16:25
qschulzfray: proprietary software.. can't trust it :) especially since it's not something you can self-host16:25
fraythere are definitely parts of github I don't like as well.. but I can [for the most part] ignore them16:26
fraythe 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@> has left #yocto16:27
fraybut 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
frayalso ends up leading to commit messages of 'Latest work'16:27
fraygreat, that was helpful.. :|16:28
qschulzdon't get me started on this :)16:28
fraythe 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
frayI do that by accident, but I know better.. these guys don't think that  is a problem16:29
*** B0ned1ger <B0ned1ger!> has quit IRC16:29
fraygoes from working to not working over night, and all that happened was a simple file rename...16:29
frayor 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!> has joined #yocto16:30
frayand when I do that in 3 commits, they squash them when they take my pull request.. (drives me nuts)16:30
* fray is now venting16:31
fray(non-linux, non-work projects I work on)16:31
frayLinux related don't seem to do that.. and my work projects would never allow that..16:31
*** mrc3 <mrc3!~mrc3@linaro/mrc3> has quit IRC16:32
qschulzfray: "fix" and "upgrade" commit titles with no log are the best, change my mind16:34
*** zyga <zyga!~zyga@unaffiliated/zyga> has quit IRC16:38
frayright after I get the tracking chip in my COVID-19 vaccine from Bill Gates16:39
*** zyga <zyga!~zyga@unaffiliated/zyga> has joined #yocto16:40
mischiefis there a way to exclude content from the sdk16:45
*** mrc3 <mrc3!~mrc3@linaro/mrc3> has joined #yocto16:53
*** B0ned1ger <B0ned1ger!> has joined #yocto16:55
*** Yumasi <Yumasi!~guillaume@2a01:e0a:5cb:4430:a218:d301:729d:d5b3> has quit IRC17:01
*** Kyubi <Kyubi!~Kyubi@> has quit IRC17:06
*** frsc <frsc!> has quit IRC17:12
*** linums <linums!> has quit IRC17:14
*** linums <linums!> has joined #yocto17:15
*** fl0v0 <fl0v0!> has quit IRC17:17
*** Kyubi <Kyubi!~Kyubi@> has joined #yocto17:21
*** B0ned1ger2 <B0ned1ger2!> has joined #yocto17:25
*** Wouter01000 <Wouter01000!> has quit IRC17:26
*** Wouter01000 <Wouter01000!> has joined #yocto17:26
*** B0ned1ger <B0ned1ger!> has quit IRC17:29
*** B0ned1ger2 <B0ned1ger2!> has quit IRC17:29
*** kaspter <kaspter!~Instantbi@2409:8a1e:911f:ee70:f0ba:ded9:f1f6:7520> has quit IRC17:30
*** minimaxwell <minimaxwell!> has joined #yocto17:33
ptsnevesmischief exclude packages or some files from a package used in the sdk?17:35
*** mckoan is now known as mckoan|away17:37
ptsneveskyanres wrong console :D17:37
mischiefptsneves: packages... they are part of MACHINE_ESSENTIAL_EXTRA_RDEPENDS17:43
mischiefso 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 purposes17:43
mischiefcan i just unset MACHINE_ESSENTIAL_EXTRA_RDEPENDS in a new image recipe to shrink the sdk size?17:44
*** roussinm <roussinm!> has joined #yocto17:45
ptsnevesyou can set it with MACHINE_ESSENTIAL_EXTRA_RDEPENDS = "" or you can MACHINE_ESSENTIAL_EXTRA_RDEPENDS_remove = "your package"17:45
ptsnevesmischief have you tried it?17:45
kyanresO_O I blame WSL2 + VcXsrv for shitty focus, but I'm just glad there was no password involved17:48
*** bps <bps!~bps@> has quit IRC17:53
*** dreyna <dreyna!> has joined #yocto17:54
*** dreyna_ <dreyna_!> has joined #yocto17:55
*** Kyubi <Kyubi!~Kyubi@> has quit IRC17:56
ptsneveskyanres 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" :D17:56
*** B0ned1ger <B0ned1ger!> has joined #yocto17:59
*** dreyna <dreyna!> has quit IRC17:59
*** Kyubi <Kyubi!~Kyubi@> has joined #yocto18:00
*** matteo <matteo!~matteo@redhat/matteo> has joined #yocto18:02
matteohi all!18:02
armpitfray,  you getting hit with the Storm Canada sent us ?18:04
*** jbaxter <jbaxter!> has joined #yocto18:04
fraynope.. just cold here18:04
armpitOur friends in TX are having their pools freeze over18:05
*** manuel1985 <manuel1985!~manuel198@> has quit IRC18:05
*** minimaxwell <minimaxwell!> has quit IRC18:06
*** Kyubi <Kyubi!~Kyubi@> has quit IRC18:09
*** minimaxwell <minimaxwell!> has joined #yocto18:11
fraytemps here over night have been between -22F and -10F for the past two weeks18:13
frayday time has been -10F to 0F...18:13
frayso it's been cold18:13
*** gsalazar <gsalazar!955a6fad@gateway/web/cgi-irc/> has quit IRC18:15
*** ENPJ <ENPJ!> has quit IRC18:23
*** dahints <dahints!d4cc47cc@> has joined #yocto18:24
vdlif "poky" embeds openembedded-core, why does meta-openembedded do the same?18:37
*** LetoThe2nd <LetoThe2nd!uid453638@gateway/web/> has quit IRC18:39
*** Kyubi <Kyubi!~Kyubi@> has joined #yocto18:39
fraymeta-openembedded doesn't embedd openembedded-core18:39
frayYou can do 'bitbake, openembedded-core & meta-yocto' combined (poky) or individually..18:40
fraymeta-openembedded is just a layer to be added on top..18:40
vdlaren't meta-openembedded/meta-oe, openembedded-core/meta and poky/meta the same layer?18:43
frayopenembedded-core/meta and poky/meta is the same..18:45
fraymeta-openembedded is completely different18:45
vdlwhat is meta-openembedded/meta-oe then18:46
fraymeta-openembedded is a repository of multiple layers maintained by the OpenEmbedded group.18:46
frayInside of that is a generic layer, meta-oe that covers things that didn't fit anywhere else..18:46
frayotherwise meta-python and such are more clear containers of various components18:47 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
vdlfray: ok meta-openembedded/meta-oe is more of a "meta-misc" layer, right? :D18:49
vdlI'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@> has quit IRC18:53
frayopenembedded-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
fraysystemd is core, you can't boot a device without an init framework.18:54
frayOE 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
vdlwell it's a choice, you could argue that sysvinit is core and systemd is an alternative :)18:55
fraysysvinit and systemd are equally supported and maintained.  Recipes are expected to support both of them equally18:55
vdlfray: I understand better with the framework approach18:55
fraySome of hte gnome recipes are required for non-gnome components.. which starts pulling in more and more dependencies..18:56
vdlstill openembedded-core/meta/recipe-* could be in meta-openembedded, since well, they're recipes18:56
fraysome of them are simply used to validate things like keyboard, mouse, Wayland/Weston, etc.18:56
frayeverything in openembedded-core is tested as a unit.18:56
fraymeta-openembeded's layers can be tested together or individually -- but that is not part of the 'core' testing18:57
fraypoky 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
fraybut 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
frayYocto Project for instance only tests poky (which in-turn tests bitbake, openembedded-core and meta-yocto)18:58
frayif 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 traceoffs18:59
fray'er tradeoffs..18:59
vdlso 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
fraylayers are not precise things, but we've tried to set best practices around them -- but everything has to start somewhere18:59
frayNo, bare minimum is bitbake and openembedded-core18:59
frayI regularly build small systems with just those two.. or add a third layer that has BSP level support..19:00
vdlfray: right, I somehow included "python" in my bare minimum example scenario ^^19:00
frayit's when I want to expand beyond small systems that I usually start adding parts from meta-openembedded..19:00
fraypython itself is part of openembedded-core..19:00
frayadditional python modules come from meta-python19:00
fraybitbake / openembedded-core are the minimum you need for a working system..19:01
*** felipealmeida <felipealmeida!~felipealm@> has joined #yocto19:03
vdlfray: python2 is part of openembedded-core, meta-python is python3, right?19:07
*** felipealmeida <felipealmeida!~felipealm@> has quit IRC19:08
fraypython2 WAS part of openembedded-core until it went EOL..  Then it moved into meta-python2 in meta-openembedded (repository)19:08
vdlfray: anyway thank you, I'll switch to bitbake + openembedded-core + mylayer now19:09
fraypython3 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 reason19:09
vdlIt 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
frayIf it's not in openembedded-core it's optional19:10
fraybitbake 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@> has joined #yocto19:18
vdlfray: bitbake has no dunfell branch, right? how does oe synchronize with the correct bitbake version?19:18
*** zyga <zyga!~zyga@unaffiliated/zyga> has quit IRC19:19
fraybitbake is a separate project.. so it's numerically driven.. I don't remember what the dunfell version is.. There is a page on that captures it19:20
*** zyga <zyga!~zyga@unaffiliated/zyga> has joined #yocto19:20
vdlfray: only layer repositories (including yours) should follow the branch convention and have e.g. a dunfell branch in them, correct?19:21
*** imaami <imaami!> has quit IRC19:33
*** imaami <imaami!> has joined #yocto19:33
frayyes, 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 IRC19:53
*** zyga <zyga!~zyga@unaffiliated/zyga> has quit IRC19:53
*** kpo_ <kpo_!> has quit IRC19:53
*** mihai <mihai!~mihai@unaffiliated/mihai> has joined #yocto19:53
*** kpo_ <kpo_!> has joined #yocto19:54
*** mihai <mihai!~mihai@unaffiliated/mihai> has quit IRC19:54
*** dahints <dahints!d4cc47cc@> has quit IRC19:55
*** mihai <mihai!~mihai@unaffiliated/mihai> has joined #yocto19:56
*** derRichard <derRichard!> has quit IRC19:58
*** oberstet <oberstet!~oberstet@> has quit IRC19:58
*** mihai <mihai!~mihai@unaffiliated/mihai> has joined #yocto19:58
*** derRichard <derRichard!> has joined #yocto19:58
*** B0ned1ger2 <B0ned1ger2!> has joined #yocto20:00
vdlfray: 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!> has quit IRC20:03
vdlbitbake seems to have "-dunfell" prefixed tags.20:04
*** linums <linums!> has quit IRC20:05
*** linums <linums!> has joined #yocto20:05
*** mihai <mihai!~mihai@unaffiliated/mihai> has quit IRC20:08
*** mihai <mihai!~mihai@unaffiliated/mihai> has joined #yocto20:08
*** linums <linums!> has quit IRC20:12
*** linums <linums!> has joined #yocto20:14
*** gpanders <gpanders!> has quit IRC20:15
*** gpanders <gpanders!> has joined #yocto20:15
sakomanbitbake for dunfell is 1.4620:16
*** gpanders <gpanders!> has quit IRC20:17
*** zyga <zyga!~zyga@unaffiliated/zyga> has joined #yocto20:18
*** gpanders <gpanders!~gpanders@gateway/tor-sasl/gpanders> has joined #yocto20:18
*** linums <linums!> has quit IRC20:20
*** gpanders <gpanders!~gpanders@gateway/tor-sasl/gpanders> has quit IRC20:21
*** gpanders <gpanders!~gpanders@gateway/tor-sasl/gpanders> has joined #yocto20:22
*** linums <linums!~linums@> has joined #yocto20:22
mischiefptsneves: i tried it just now. the sdk installer still has stuff i dont want in it, and i do not understand why.20:27
mischiefi 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 #yocto20:29
*** aidanh <aidanh!~aidanh@unaffiliated/aidanh> has quit IRC20:29
*** aidanh_ is now known as aidanh20:29
*** minimaxwell <minimaxwell!> has quit IRC20:30
mischiefoh. m( of course, MACHINE_ESSENTIAL_EXTRA_RDEPENDS is pulled by packagegroup-core-boot.20:31
*** zyga <zyga!~zyga@unaffiliated/zyga> has quit IRC20:34
*** OnkelUlla <OnkelUlla!> has quit IRC20:35
*** linums <linums!~linums@> has quit IRC20:37
*** linums <linums!> has joined #yocto20:38
*** B0ned1ger <B0ned1ger!> has joined #yocto20:41
*** mrc3 <mrc3!~mrc3@linaro/mrc3> has quit IRC20:42
*** B0ned1ger2 <B0ned1ger2!> has quit IRC20:44
*** B0ned1ger <B0ned1ger!> has quit IRC20:46
*** linums <linums!> has quit IRC20:52
*** linums <linums!> has joined #yocto20:53
*** linums <linums!> has quit IRC20:54
*** linums <linums!> has joined #yocto20:54
*** mrc3 <mrc3!~mrc3@linaro/mrc3> has joined #yocto20:55
*** linums <linums!> has quit IRC20:56
*** linums <linums!> has joined #yocto20:56
*** rcoote <rcoote!> has quit IRC20:57
*** mbulut <mbulut!> has quit IRC20:59
*** Kyubi <Kyubi!~Kyubi@> has quit IRC21:03
*** B0ned1ger <B0ned1ger!> has joined #yocto21:04
*** linums <linums!> has quit IRC21:08
*** B0ned1ger <B0ned1ger!> has quit IRC21:09
*** linums <linums!> has joined #yocto21:09
*** aleblanc <aleblanc!> has joined #yocto21:10
*** aleblanc <aleblanc!> has quit IRC21:12
*** linums <linums!> has quit IRC21:20
*** linums <linums!> has joined #yocto21:20
*** minimaxwell <minimaxwell!> has joined #yocto21:31
*** OnkelUlla <OnkelUlla!> has joined #yocto21:35
*** minimaxwell <minimaxwell!> has quit IRC21:36
*** vineela <vineela!~vtummala@> has quit IRC21:38
*** ENPJ <ENPJ!~john@2001:a61:3a84:9501:6d11:2e24:da03:67e7> has joined #yocto21:52
*** ENPJ <ENPJ!~john@2001:a61:3a84:9501:6d11:2e24:da03:67e7> has joined #yocto21:53
*** ENPJ <ENPJ!~john@2001:a61:3a84:9501:6d11:2e24:da03:67e7> has left #yocto21:54
*** minimaxwell <minimaxwell!> has joined #yocto21:56
*** minimaxwell <minimaxwell!> has quit IRC22:00
dl9pfRP: Reproducibility summary for rpm: same=9866 different=1513 different_excluded=56 missing=0 total=1143522:00
dl9pfunused_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 #yocto22:01
*** zyga <zyga!~zyga@unaffiliated/zyga> has joined #yocto22:04
*** tgoodwin <tgoodwin!> has quit IRC22:08
JPEWdl9pf: Good start! Not as bad as I thought it would be22:10
dl9pfJPEW: that was just a macro missing, let's see what is left22:10
JPEWwhich macro?22:11
dl9pf--define "use_source_date_epoch_as_buildtime 1"22:12
JPEWdl9pf: Ah, nice!22:12
dl9pfbut the oe-selftest did crash my server twice today, so I have no local build so far22:12
JPEWdl9pf: Ya, the world reproducible build test is brutal22:13
*** medaliyou <medaliyou!29e2aabb@> has quit IRC22:15
*** mihai- <mihai-!~mihai@unaffiliated/mihai> has joined #yocto22:15
*** tgamblin <tgamblin!> has quit IRC22:15
*** tgamblin <tgamblin!> has joined #yocto22:16
dl9pfcore-image-minimal just finished ... glibc-*locale*   glibc-charmap* glibc-gconv os-release,  libgcc-s libstdc++22:17
*** mihai <mihai!~mihai@unaffiliated/mihai> has quit IRC22:18
dl9pfseems like some created files have the build-time as mtime  in the rpm22:23
*** ENPJ_ <ENPJ_!~quassel@2001:a61:3a84:9501:6d11:2e24:da03:67e7> has joined #yocto22:25
*** beneth` <beneth`!> has left #yocto22:25
*** linums <linums!> has quit IRC22:25
*** linums <linums!> has joined #yocto22:26
dl9pf e.g. /etc/securetty , /usr/share/i18n/localedata22:29
dl9pfthey do have buildtime vs. source_date_epoch22:30
*** linums <linums!> has quit IRC22:30
*** linums <linums!> has joined #yocto22:32
dl9pflooks to me like files that we copy in or create, and a lot of folders created with install -d ...22:32
*** ptsneves <ptsneves!b0dd7824@> has quit IRC22:37
*** ENPJ_ is now known as ENPJ22:38
dl9pfno diff in the binaries themselves so far. all just mtime (?)22:40
*** minimaxwell <minimaxwell!> has joined #yocto22:51
*** comptroller <comptroller!> has quit IRC22:53
*** ENPJ <ENPJ!~quassel@2001:a61:3a84:9501:6d11:2e24:da03:67e7> has quit IRC22:57
*** minimaxwell <minimaxwell!> has quit IRC22:59
*** B0ned1ger <B0ned1ger!> has joined #yocto23:05
*** B0ned1ger <B0ned1ger!> has quit IRC23:10
*** zyga <zyga!~zyga@unaffiliated/zyga> has quit IRC23:16
*** agust <agust!> has quit IRC23:18
*** gendevbot <gendevbot!~devbot@> has quit IRC23:21
*** gendevbot_ <gendevbot_!~devbot@> has joined #yocto23:21
*** vineela <vineela!vtummala@nat/intel/x-ptdcmewswpyppqvl> has quit IRC23:22
*** vineela <vineela!~vtummala@> has joined #yocto23:28
*** mrpelotazo <mrpelotazo!> has quit IRC23:30
dl9pfhmm I see in rpm sources, there is a fakeStat call that takes 'now' and does not obey source_date_epoch ... for %ghost and %dev23:33
frayghost 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
dl9pfthanks for the explanation23:37
dl9pfso the question is back to where 'now' comes from23:37
dl9pfin the header for content23:37
frayI don't know the implementation, but I had assumed the 'now' was at the time the package was _installed_ not built..23:37
fraybut if the now is calculated "when built", then it'll need some sort of patch23:38
dl9pfit is build time in my diffoscope ...23:40
frayya, so you'll have to patch and capture the 'now' and allow it to be passed in...23:41
RPdl9pf: can you separate out the package_rpm.bbclass change and send it alone so we can merge that bit?23:41
RPdl9pf: sounds like good progress at least23:41
*** mrpelotazo <mrpelotazo!> has joined #yocto23:42
*** mrpelotazo <mrpelotazo!> has quit IRC23:43
dl9pfRP: yes, will send a separate patch tomorrow23:43
dl9pfthe files are links and dirs for example ...23:44
*** mrpelotazo <mrpelotazo!> has joined #yocto23:45
RPdl9pf: I've been wondering how those get the correct timestamps in the ipk/debs :/23:46
frayif it's using time() or date() then it can likely be intercepted23:46
dl9pfi still think we end-up in:23:48
RPdl9pf: we'd really want SDE in there...23:51
*** linums <linums!> has quit IRC23:51
dl9pfin the morning ...23:53
RPdl9pf: yes, I'm heading to bed :)23:53

Generated by 2.17.2 by Marius Gedminas - find it at!