**** BEGIN LOGGING AT Wed Feb 17 02:59:56 2021 Feb 17 07:50:06 yo dudX Feb 17 07:50:15 good morning Feb 17 07:50:36 g'morning Feb 17 08:14:12 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? Feb 17 08:21:18 mseeber: are only the cached git repo accesses problematic? Feb 17 08:24:01 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. Feb 17 08:24:47 mseeber: ok, but all recipes that access some form of archive/tarball are happy? Feb 17 08:25:00 They do work, yes Feb 17 08:25:33 i see. what release are you on? Feb 17 08:28:53 poky version is sumo Feb 17 08:29:07 meh. Feb 17 08:29:27 check if it also fails on dunfell, and if not, go hunting for the patch in the git fetcher. Feb 17 08:29:37 if it still fails then, please report a bug. Feb 17 08:30:07 repectively, if it still fails on master. Feb 17 08:30:13 alright, thanks Feb 17 08:30:50 mseeber: or maybe the remote is _that_ slow and you're stuck waiting Feb 17 08:32:15 mihai: then the effect would be witnessed on something recent too, probably. unless there already is handling for it in place. Feb 17 08:32:44 in any case i think all effort on sumo support is wasted :) Feb 17 08:32:48 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 Feb 17 08:32:56 probably not, i did test with and without nfs, so the remote repo is probably fine Feb 17 08:34:16 well, I have sumo working and maintained quite well so it's not completely wasted time with it... Feb 17 08:34:49 * LetoThe2nd hands mcfrisk the "sumo volunteer"-badge! Feb 17 08:35:01 (pun intended!) Feb 17 09:00:30 * mcfrisk tried to get permission to maintain sumo publicly... Feb 17 09:01:39 mcfrisk: let me know when you make it, i'll buy you some new pants! Feb 17 09:11:36 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 ) Feb 17 09:30:44 Hi Guys Feb 17 09:31:18 LAYERSERIES_COMPAT_meta-XYZ = "thud" Feb 17 09:31:30 i ve cloned with dunfell branch Feb 17 09:32:13 what happens if i change this line ' LAYERSERIES_COMPAT_meta-XYZ = "thud" ' to ' LAYERSERIES_COMPAT_meta-XYZ = "dunfell" ' or just comment it Feb 17 09:32:26 would it break things ? Feb 17 09:32:49 LetoThe2nd: tried, but failed :( no need for new pants Feb 17 09:33:05 mcfrisk: aww. Feb 17 09:34:48 LetoThe2nd can you help me please !!! Feb 17 09:35:34 mcfrisk: https://sumowrestling.fandom.com/wiki/Mawashi Feb 17 09:35:43 i m working on existing yocto project & triying to optimize boot time. Feb 17 09:36:16 medaliyou: go and find out. it might work if there are no specific dependencies, it might break if there are. Feb 17 09:36:34 alright , thank you Feb 17 09:56:38 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 :/ Feb 17 10:57:09 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 Feb 17 10:58:18 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.. Feb 17 10:58:29 and git annex too Feb 17 11:02:53 mcfrisk: right, I can see why it does it, I was just being dumb with my previous fix :/ Feb 17 11:12:16 I have this recipe which has some files in ${S}// 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 Feb 17 11:12:43 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 :/ Feb 17 11:13:13 how dirty is it to look into ${B}// to make a mapping of UUIDs to package-name? Feb 17 11:44:18 RP: if (srcdate && rpmExpandNumeric("%{?use_source_date_epoch_as_buildtime}")) { Feb 17 11:44:34 so where do we set the default macros ? Feb 17 11:49:53 dl9pf: package_rpm.bbclass, see the --defines I think Feb 17 11:50:38 --define "%source_date_epoch_from_changelog 1" Feb 17 11:51:02 --define "%clamp_mtime_to_source_date_epoch 1" Feb 17 11:51:40 dl9pf: hmm, I don't see the changelog piece here Feb 17 11:52:00 ah ... ignore, thats suse specific Feb 17 11:52:35 --define "%use_source_date_epoch_as_buildtime 1" Feb 17 11:52:46 that sounds promising Feb 17 11:53:04 compared with https://en.opensuse.org/openSUSE:Reproducible_Builds#With_OBS Feb 17 11:53:15 so let's try mtime and buildtime and see Feb 17 11:53:26 dl9pf: mtime is already there I think Feb 17 11:53:38 checking package_rpm.bbclass now Feb 17 11:55:29 qschulz it seems that you need to roll your own packaging function Feb 17 11:56:38 ptsneves: I can do something by reading the source directory but that feels wrong somehow :/ Feb 17 11:58:08 sent a v2 Feb 17 11:58:37 i do not think it feels wrong. Why? You will roll the packaging function in the recipe scope so it is localized. Feb 17 12:00:00 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) Feb 17 12:00:31 qschulz: If my local "make do_install an sstate task" change does go in it would break that Feb 17 12:01:24 RP: mmmm how so? is there a cleandirs somewhere that would remove the ${S} or ${B} directory before do_package is run? Feb 17 12:02:07 basically, I have ${S}/package-name/transaltions/ which gets installed into ${D}/usr/share/translations/ Feb 17 12:02:39 and UUID != packagename, so for now I do a glob search in S, to get package-name-UUID mapping Feb 17 12:03:15 and I manually append /usr/share/translations/UUID to FILES_${PN}- Feb 17 12:03:33 qschulz: if do_install comes from sstate, ${S}/${B} won't be populated Feb 17 12:04:18 RP: duh, obviously. /me facepalms himself :) Feb 17 12:05:18 qschulz: could you install some symlink which would help the code know where things go? Feb 17 12:05:45 package it off into the -dev where you don't care Feb 17 12:06:14 dl9pf: https://autobuilder.yoctoproject.org/typhoon/#/builders/117/builds/3 is running with it Feb 17 12:07:29 dl9pf: I'm worried your test "reproduced" for you :/ Feb 17 12:09:33 RP: I'd still need to manually package them (getvar(fiels_pn), setvar(files_pn)) instead of using do_split_packages then :/ Feb 17 12:09:47 i'll ask upstream to change how they do it and use subdirs for those files too :) Feb 17 12:15:49 RP do_install has a setscene version? Feb 17 12:17:11 ptsneves: not yet but I have patches and ideas Feb 17 12:17:16 it did produce these numbers, but with the dunfell selftest Feb 17 12:17:51 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 Feb 17 12:18:02 my build machine just crashed running the selftest ... Feb 17 12:18:58 @RP :O what is the rationale? This sounds quite a change. Feb 17 12:18:59  qschulz then stage into the D dir a file with the layout of how you want things packaged...although things are tricky. Feb 17 12:19:08 dl9pf: I probably shouldn't see that as an achievement, right? :) Feb 17 12:19:45 ptsneves: it would allow repackaging without rebuilding everything. It also makes binary only distribution easier Feb 17 12:21:56 Is it possible to compile two different repositories in the same recipe? Feb 17 12:22:15 RP do you already have an RFC for it? Feb 17 12:22:36 ptsneves: my patches don't quite work Feb 17 12:22:52 I would like to combine 2 repos into one package if that's somehow possible Feb 17 12:22:54 TheComet yes. Just merge them into a way they both work, or just call the build system for each of the repos Feb 17 12:23:12 TheComet: you can put multiple entries in SRC_URI Feb 17 12:23:12 TheComet i mean merge them in the WORKDIR. Feb 17 12:23:52 Ah I would need to write my own do_compile() to call make twice? Feb 17 12:23:59 RP  you comfortable in sharing them already? Feb 17 12:24:11 TheComet if they are independent yes. Feb 17 12:24:26 Alright thanks Feb 17 12:24:46 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 Feb 17 12:24:47 RP: probably a faulty DIMM Feb 17 12:25:06 Is that the best way though, or is there an easy way to merge the compile results of two recipes into one package? Feb 17 12:25:22 Because I do think I should leverage the default do_compile()/do_install() stuff Feb 17 12:26:51 TheComet It depends, but it is style. Conventionally you have different recipes for each repo. Are these 2 repos usable independently? Feb 17 12:27:32 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 Feb 17 12:27:42 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? Feb 17 12:28:20 TheComet so i would not build them together. If they have very similar way of building you can just have a common .inc file Feb 17 12:30:27 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 Feb 17 12:31:05 i may be wrong but i think you can do that in the packagegroup Feb 17 12:31:27 I haven't looked at packagegroup at all but I think that might be exactly what I need Feb 17 12:31:33 I'll look into it thanks! Feb 17 12:31:59 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. Feb 17 12:32:17 above all fullfil you client needs and think of your future self as a maintainer Feb 17 12:33:29 I sure hope I don't have to maintain this dumpsterfire in the future :D Feb 17 12:35:33 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 Feb 17 12:36:22 lol Feb 17 12:36:30 lmao Feb 17 12:37:16 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 Feb 17 12:38:13 i dont think so but you can RDEPENDS on specific versions Feb 17 12:38:24 or version semantics Feb 17 12:39:32 TheComet: RDEPENDS_foo = "bar (=1.0.0)" Feb 17 12:44:36 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)" Feb 17 12:45:21 TheComet you can. What did it not achieve? Feb 17 12:45:54 TheComet: dependencies don't make sense in PACKAGES Feb 17 12:46:04 ah, sorry, I misread Feb 17 12:46:07 It's saying "Nothing PROVIDES foo" Feb 17 12:46:14 "bitbake foo-1.0.0" seems to work though Feb 17 12:46:21 ahh Feb 17 12:46:32 because the recipe should be foo_1.0.0.b Feb 17 12:46:38 foo_1.0.0.bb Feb 17 12:46:38 Oooh, of course Feb 17 13:40:37 Does `DISTRO_FEATURES += "usbgadget"` add the kernel modules, or should I enable them manually? Feb 17 13:42:10 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. Feb 17 13:44:07 jonesv[m]: look at meta/recipes-core/packagegroup-base Feb 17 13:45:02 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. Feb 17 13:48:33 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). Feb 17 13:49:04 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. Feb 17 13:49:51 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? Feb 17 13:50:25 I did it in `local.conf`, because I don't have my distro yet (but I want to put it in the distro eventually) Feb 17 13:50:47 But I'm using the default linux-yocto, and maybe I need to append something for it to support usbgadget Feb 17 13:51:07 jonesv[m]: check /proc/config.gz first. Feb 17 14:24:10 rauc status Feb 17 14:50:44 RP: https://autobuilder.yoctoproject.org/typhoon/#/builders/117/builds/3 seems done, error seems unrelated ? Feb 17 14:54:51 dl9pf: yes, other master-next issues, sorry :( Feb 17 15:05:09 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 Feb 17 15:05:58 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 Feb 17 15:06:59 (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 Feb 17 15:14:53 hey guys , what to do if qemu-native Feb 17 15:15:05 keeps on failing on do_compile Feb 17 15:15:29 qemu-3.0.0/linux-user/syscall.c:8526: undefined reference to `stime' Feb 17 15:17:57 medaliyou: what's the distribution of your host machine? which version of Yocto are you building? Feb 17 15:17:58 isnt that an issue of glibc mismatch? Feb 17 15:18:41 looks like you need a newer uninative Feb 17 15:19:26 BB_VERSION = "1.40.0" Feb 17 15:19:26 BUILD_SYS = "x86_64-linux" Feb 17 15:19:27 NATIVELSBSTRING = "ubuntu-20.04" Feb 17 15:19:27 TARGET_SYS = "arm-tdx-linux-gnueabi" Feb 17 15:19:28 MACHINE = "colibri-imx7" Feb 17 15:19:28 DISTRO = "tdx-x11" Feb 17 15:19:29 DISTRO_VERSION = "2.6-snapshot-20210217" Feb 17 15:19:29 TUNE_FEATURES = "arm armv7a vfp thumb neon callconvention-hard" Feb 17 15:19:29 TARGET_FPU = "hard" Feb 17 15:19:39 dl9pf: trying again https://autobuilder.yoctoproject.org/typhoon/#/builders/117/builds/4 Feb 17 15:20:36 i rebuilded glibc Feb 17 15:21:33 medaliyou: ubuntu 20.04 is not supported for thud Feb 17 15:21:48 Not completely sure what I'm looking for, actually 🤔. Feb 17 15:22:03 either yoi should work in a container (with an older host OS installed) or move to a newer YP version. Feb 17 15:22:11 (container or VM) Feb 17 15:22:16 jonesv[m]: hum what is not clear about it? Feb 17 15:22:35 medaliyou: why you don't use TDX BSP 5.2 ? Feb 17 15:22:36 should i consider migrating existing layers (since 2018) to dunfell ? Feb 17 15:23:33 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" 😕 Feb 17 15:24:21 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 Feb 17 15:24:31 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. Feb 17 15:24:42 LetoThe2nd: also it says "CONFIG_USB_NET_CDCETHER=m", but `modprobe cdc_ether` can't find it Feb 17 15:25:30 jonesv[m]: have you looked at the packagegroup i named? to see which modules it actually tries to pull in? Feb 17 15:26:25 jonesv[m]: you probably need to add kernel-module- 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 Feb 17 15:26:45 is the migrating process hard (i mean i have kernel patches and various modules hodling on kernel v 4.14.9X) '=( '=( Feb 17 15:27:17 ``` Feb 17 15:27:35 qschulz: the distro feature is essentially just triggering a packagegroup that RRECOMMENDS a bunch of kernel-modules. Feb 17 15:27:45 (if i read it correctly) Feb 17 15:29:06 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 Feb 17 15:29:36 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? 😀 Feb 17 15:33:58 hi guys Feb 17 15:34:13 I am on the master channel right now Feb 17 15:34:45 and I noticed that the kea package is from a development branch, not from the master Feb 17 15:34:46 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- Feb 17 15:35:08 is it an mistake, or is it intentional? Feb 17 15:35:19 linums: was that not because that was where the release commit tag was? Feb 17 15:35:45 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. Feb 17 15:36:26 @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 Feb 17 15:36:27 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 Feb 17 15:37:33 Hi yocto started to create a folder morgue in the deploy/ipk/ARCH/morgue and it is putting the current install files there Feb 17 15:37:33 but I am right though, that dev version should not be under the yocto master Feb 17 15:41:01 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 😀 Feb 17 15:44:54 linums: master appears to use 1.8.2 which is a main release? Feb 17 15:57:24 yeah, I've checked, I'm a little late from the master Feb 17 15:57:46 at the time I've cloned it, it was using 1.7.10 Feb 17 16:04:44 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? Feb 17 16:05:28 qschulz: Ya, probably. Do you want to open a PR? Feb 17 16:05:46 JPEW: I could, do you have CI to test I'm not breaking stuff :D Feb 17 16:06:07 qschulz: Yes! I actually just got it working with GitHub actions yesterday! Feb 17 16:06:36 qschulz: https://github.com/garmin/pyrex/blob/master/DEVELOPING.md#testing Feb 17 16:07:49 linums: right, we fixed things to only get even numbers Feb 17 16:08:33 seee,cool, thanks Feb 17 16:16:18 JPEW: oh wow, the Github actions don't look super straightforward :o Feb 17 16:16:53 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.. Feb 17 16:17:21 Using a github action to trigger something in my environment seems a lot less dangerous.. just an observation Feb 17 16:17:23 fray: wasn't it already the case with Travis which was the defacto standard for CI/CD in FOSS? Feb 17 16:17:43 or maybe I misunderstood what you said? Feb 17 16:18:06 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.. Feb 17 16:18:39 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.. Feb 17 16:18:42 qschulz: Travis and GitHub actions are pretty equivalent for my purposes Feb 17 16:19:16 (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..) Feb 17 16:19:46 when it comes to CI/CD infrastructure.. you don't want to be tightly coupled to other parts, IMHO.. or it will restrict upgrading.. Feb 17 16:19:55 fray: Ya, It would be nice if there was some standardized "CI language" that worked anywhere Feb 17 16:20:08 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 Feb 17 16:22:01 (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) Feb 17 16:22:13 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 Feb 17 16:22:15 great work for the person who sells the service contract.. :) Feb 17 16:22:22 fray: Travis and Github actions are (were) free Feb 17 16:22:31 bugzilla was free too.. ;) Feb 17 16:22:32 Travis is no more Feb 17 16:22:33 so for FOSS projects, it makes sense Feb 17 16:22:44 JPEW: hence the "were" :) Feb 17 16:23:07 the point is following their precise language that is specific leads to lock-in.. if you know that going in.. fine.. no problem.. Feb 17 16:23:17 fray: what companies do is their problem and I would see Jenkins or similar stuff then, that YOU own :) Feb 17 16:23:28 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 Feb 17 16:23:41 fray: free stuff always comes with a price :) Feb 17 16:24:05 it's any software interface you don't control. just have to make informed decisions on where and how you use the tooling.. Feb 17 16:24:14 fray: on more or less the same topic, it's sad that github is where all the work is done :/ Feb 17 16:24:21 I've seen IMHO a lack of informed decisions and people jump into github thinking it's "the only way" Feb 17 16:24:28 they're going to be burned when those interfaces change Feb 17 16:25:06 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 Feb 17 16:25:33 (I never did like gitlab or sourceforge.. never really understood why, but I never liked them -- likely interface) Feb 17 16:25:40 fray: proprietary software.. can't trust it :) especially since it's not something you can self-host Feb 17 16:26:05 there are definitely parts of github I don't like as well.. but I can [for the most part] ignore them Feb 17 16:26:46 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.. Feb 17 16:27:45 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') Feb 17 16:27:59 also ends up leading to commit messages of 'Latest work' Feb 17 16:28:09 great, that was helpful.. :| Feb 17 16:28:28 don't get me started on this :) Feb 17 16:29:18 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.. Feb 17 16:29:28 I do that by accident, but I know better.. these guys don't think that is a problem Feb 17 16:29:55 goes from working to not working over night, and all that happened was a simple file rename... Feb 17 16:30:17 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" Feb 17 16:30:56 and when I do that in 3 commits, they squash them when they take my pull request.. (drives me nuts) Feb 17 16:31:12 * fray is now venting Feb 17 16:31:39 (non-linux, non-work projects I work on) Feb 17 16:31:55 Linux related don't seem to do that.. and my work projects would never allow that.. Feb 17 16:34:21 fray: "fix" and "upgrade" commit titles with no log are the best, change my mind Feb 17 16:39:09 right after I get the tracking chip in my COVID-19 vaccine from Bill Gates Feb 17 16:45:57 is there a way to exclude content from the sdk Feb 17 17:35:01 mischief exclude packages or some files from a package used in the sdk? Feb 17 17:37:17 fg Feb 17 17:37:49 kyanres wrong console :D Feb 17 17:43:07 ptsneves: packages... they are part of MACHINE_ESSENTIAL_EXTRA_RDEPENDS Feb 17 17:43:41 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 Feb 17 17:44:04 can i just unset MACHINE_ESSENTIAL_EXTRA_RDEPENDS in a new image recipe to shrink the sdk size? Feb 17 17:45:36 you can set it with MACHINE_ESSENTIAL_EXTRA_RDEPENDS = "" or you can MACHINE_ESSENTIAL_EXTRA_RDEPENDS_remove = "your package" Feb 17 17:45:46 mischief have you tried it? Feb 17 17:48:18 O_O I blame WSL2 + VcXsrv for shitty focus, but I'm just glad there was no password involved Feb 17 17:56:04 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 Feb 17 18:02:35 hi all! Feb 17 18:04:43 fray, you getting hit with the Storm Canada sent us ? Feb 17 18:04:53 nope.. just cold here Feb 17 18:05:40 Our friends in TX are having their pools freeze over Feb 17 18:13:08 temps here over night have been between -22F and -10F for the past two weeks Feb 17 18:13:22 day time has been -10F to 0F... Feb 17 18:13:25 so it's been cold Feb 17 18:37:54 if "poky" embeds openembedded-core, why does meta-openembedded do the same? Feb 17 18:39:50 meta-openembedded doesn't embedd openembedded-core Feb 17 18:40:30 You can do 'bitbake, openembedded-core & meta-yocto' combined (poky) or individually.. Feb 17 18:40:40 meta-openembedded is just a layer to be added on top.. Feb 17 18:43:41 aren't meta-openembedded/meta-oe, openembedded-core/meta and poky/meta the same layer? Feb 17 18:44:56 no Feb 17 18:45:06 openembedded-core/meta and poky/meta is the same.. Feb 17 18:45:15 meta-openembedded is completely different Feb 17 18:46:05 what is meta-openembedded/meta-oe then Feb 17 18:46:27 meta-openembedded is a repository of multiple layers maintained by the OpenEmbedded group. Feb 17 18:46:54 Inside of that is a generic layer, meta-oe that covers things that didn't fit anywhere else.. Feb 17 18:47:08 otherwise meta-python and such are more clear containers of various components Feb 17 18:47:42 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.. Feb 17 18:49:46 fray: ok meta-openembedded/meta-oe is more of a "meta-misc" layer, right? :D Feb 17 18:52:52 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" Feb 17 18:54:00 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. Feb 17 18:54:13 systemd is core, you can't boot a device without an init framework. Feb 17 18:54:55 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. Feb 17 18:55:00 well it's a choice, you could argue that sysvinit is core and systemd is an alternative :) Feb 17 18:55:21 sysvinit and systemd are equally supported and maintained. Recipes are expected to support both of them equally Feb 17 18:55:26 fray: I understand better with the framework approach Feb 17 18:56:00 Some of hte gnome recipes are required for non-gnome components.. which starts pulling in more and more dependencies.. Feb 17 18:56:10 still openembedded-core/meta/recipe-* could be in meta-openembedded, since well, they're recipes Feb 17 18:56:17 some of them are simply used to validate things like keyboard, mouse, Wayland/Weston, etc. Feb 17 18:56:37 everything in openembedded-core is tested as a unit. Feb 17 18:56:58 ok Feb 17 18:57:00 meta-openembeded's layers can be tested together or individually -- but that is not part of the 'core' testing Feb 17 18:57:43 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" Feb 17 18:58:23 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.. Feb 17 18:58:44 Yocto Project for instance only tests poky (which in-turn tests bitbake, openembedded-core and meta-yocto) Feb 17 18:59:18 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 Feb 17 18:59:23 'er tradeoffs.. Feb 17 18:59:35 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? Feb 17 18:59:40 layers are not precise things, but we've tried to set best practices around them -- but everything has to start somewhere Feb 17 18:59:55 No, bare minimum is bitbake and openembedded-core Feb 17 19:00:15 I regularly build small systems with just those two.. or add a third layer that has BSP level support.. Feb 17 19:00:24 fray: right, I somehow included "python" in my bare minimum example scenario ^^ Feb 17 19:00:33 it's when I want to expand beyond small systems that I usually start adding parts from meta-openembedded.. Feb 17 19:00:41 python itself is part of openembedded-core.. Feb 17 19:00:48 additional python modules come from meta-python Feb 17 19:01:06 bitbake / openembedded-core are the minimum you need for a working system.. Feb 17 19:07:43 fray: python2 is part of openembedded-core, meta-python is python3, right? Feb 17 19:08:44 python2 WAS part of openembedded-core until it went EOL.. Then it moved into meta-python2 in meta-openembedded (repository) Feb 17 19:09:07 fray: anyway thank you, I'll switch to bitbake + openembedded-core + mylayer now Feb 17 19:09:17 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 Feb 17 19:09:43 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. Feb 17 19:10:33 If it's not in openembedded-core it's optional Feb 17 19:10:58 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() Feb 17 19:18:59 fray: bitbake has no dunfell branch, right? how does oe synchronize with the correct bitbake version? Feb 17 19:20:24 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 Feb 17 19:21:48 fray: only layer repositories (including yours) should follow the branch convention and have e.g. a dunfell branch in them, correct? Feb 17 19:34:28 yes, it's recommended, but not required... the branch can be whatever you want, but then it's difficult for others to find.. Feb 17 20:00:05 fray: having a "dunfell" branch is great if you share your layer I think, not necessary at all if your layer is private. Feb 17 20:04:04 bitbake seems to have "-dunfell" prefixed tags. Feb 17 20:16:04 bitbake for dunfell is 1.46 Feb 17 20:27:41 ptsneves: i tried it just now. the sdk installer still has stuff i dont want in it, and i do not understand why. Feb 17 20:28:01 i feel like i am missing a doc or something that would help me understand how sdk is made. Feb 17 20:31:14 oh. m( of course, MACHINE_ESSENTIAL_EXTRA_RDEPENDS is pulled by packagegroup-core-boot. Feb 17 22:00:46 RP: Reproducibility summary for rpm: same=9866 different=1513 different_excluded=56 missing=0 total=11435 Feb 17 22:00:46 unused_exclusions=['babeltrace2-ptest', 'cups', 'efivar', 'git', 'go_', 'libcap-ng', 'libproxy', 'ltp', 'meson', 'rsync', 'syslinux-misc'] Feb 17 22:10:07 dl9pf: Good start! Not as bad as I thought it would be Feb 17 22:10:47 JPEW: that was just a macro missing, let's see what is left Feb 17 22:11:26 which macro? Feb 17 22:12:04 --define "use_source_date_epoch_as_buildtime 1" Feb 17 22:12:39 dl9pf: Ah, nice! Feb 17 22:12:54 but the oe-selftest did crash my server twice today, so I have no local build so far Feb 17 22:13:26 dl9pf: Ya, the world reproducible build test is brutal Feb 17 22:17:23 core-image-minimal just finished ... glibc-*locale* glibc-charmap* glibc-gconv os-release, libgcc-s libstdc++ Feb 17 22:23:50 seems like some created files have the build-time as mtime in the rpm Feb 17 22:29:19 e.g. /etc/securetty , /usr/share/i18n/localedata Feb 17 22:30:13 they do have buildtime vs. source_date_epoch Feb 17 22:32:13 looks to me like files that we copy in or create, and a lot of folders created with install -d ... Feb 17 22:40:49 no diff in the binaries themselves so far. all just mtime (?) Feb 17 23:33:48 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 Feb 17 23:34:26 ghost files don't exist.. they are owned by the package, but no contents.. dev is the same.. Feb 17 23:34:34 (dev is 'created' at the time the package is installed) Feb 17 23:36:53 ok Feb 17 23:37:00 thanks for the explanation Feb 17 23:37:34 so the question is back to where 'now' comes from Feb 17 23:37:42 in the header for content Feb 17 23:37:55 I don't know the implementation, but I had assumed the 'now' was at the time the package was _installed_ not built.. Feb 17 23:38:07 but if the now is calculated "when built", then it'll need some sort of patch Feb 17 23:40:57 it is build time in my diffoscope ... Feb 17 23:41:25 ya, so you'll have to patch and capture the 'now' and allow it to be passed in... Feb 17 23:41:33 dl9pf: can you separate out the package_rpm.bbclass change and send it alone so we can merge that bit? Feb 17 23:41:47 dl9pf: sounds like good progress at least Feb 17 23:42:49 yes Feb 17 23:42:54 https://usercontent.irccloud-cdn.com/file/JJBRkeaR/image.png Feb 17 23:43:59 RP: yes, will send a separate patch tomorrow Feb 17 23:44:05 Zzzzz Feb 17 23:44:32 the files are links and dirs for example ... Feb 17 23:46:25 dl9pf: I've been wondering how those get the correct timestamps in the ipk/debs :/ Feb 17 23:46:54 if it's using time() or date() then it can likely be intercepted Feb 17 23:48:53 i still think we end-up in: Feb 17 23:49:03 https://usercontent.irccloud-cdn.com/file/x3uzSnry/image.png Feb 17 23:51:17 dl9pf: we'd really want SDE in there... Feb 17 23:53:01 in the morning ... Feb 17 23:53:52 dl9pf: yes, I'm heading to bed :) **** ENDING LOGGING AT Thu Feb 18 02:59:56 2021