**** BEGIN LOGGING AT Wed Mar 24 02:59:57 2021 Mar 24 06:19:02 hmm pseudo related trouble in dunfell, nativesdk recipes are failing at do_package with "Cannot change ownership to uid 0, gid 0: Operation not permitted" after applying poky updates from the past 6 weeks Mar 24 07:09:18 so turns out S is now ignored by pseudo. So if anything sets S and expects permissions to be preserved from there will fail. As workaround don't use S to the path where files are but set S to WORKDIR and in do_install append the other paths. Not sure I follow this.. Mar 24 07:32:29 Hmmm, question - why does NodeJS always fail twice or thrice on a fresh compile on dunfell? If I compile again, it is no problem. Mar 24 07:34:15 Build system is a Ryzen 3400G, 2x8 GB 3200 MHz DDR4 non-ecc memory, and an ssd SATA drive. Mar 24 07:35:21 Could it be that I run out of RAM or CPU cores? Mar 24 07:59:50 As far as I can tell, my only nodejs recipes come from meta-oe. Mar 24 08:12:34 Am I the only one seeing this consistently? :o Mar 24 08:40:29 I see this happen on thud occasionally. Mar 24 08:41:08 I think something is borked in the build instructions, like internally it is building stuff out-of-order Mar 24 08:41:43 I bumped up the RAM on our build VM and it went away. Mar 24 08:42:05 resoum: Did you do a full rebuild? Mar 24 08:42:17 Yup, had to do a -c cleansstate Mar 24 08:42:25 Ok, that explains it Mar 24 08:42:26 Otherwise it just kept on failing. Mar 24 08:42:50 Then yes, the explanation is that 14 GB of memory is probably not enough for building this Mar 24 08:42:52 hey guys Mar 24 08:43:25 what is the correct way to tell bitbake to build all QT5 libraires and my QT5 App statically ? Mar 24 08:43:30 wertigon: 2 Gig of RAM per CPU seemed to be about where the build failures stopped. Mar 24 08:43:51 YMMV of course... Mar 24 08:44:10 resoum: Aha, I have only 1.75 GB per thread :/ Mar 24 08:44:39 2 is reserved for the APU on my CPU Mar 24 08:44:55 It feels like a bug somewhere, but I really do not have the time to dig in to it if RAM solves it. Mar 24 08:45:15 I can get around this with multiple compiles Mar 24 08:45:29 Yeah, that is how I generally do it too. Mar 24 08:45:53 bitbake nodejs and boost, and then fire off the full image builds. Mar 24 08:46:24 I just do full image like, 3 or 4 times :) Mar 24 08:46:33 Yuck Mar 24 08:46:48 -k option Mar 24 08:46:49 Whenever I get a failure like that, I cleansstate the offender, build it manually, and go back to the image build. Mar 24 08:47:10 Our build server is much more beefy and does not seem to encounter the problem. Mar 24 08:48:05 Ok so if I cleansstate and check logs I get this, only two rebuilds necessary this time, but... Mar 24 08:48:30 Pastebin coming up Mar 24 08:53:37 https://pastebin.com/qJnS9ui0 Mar 24 08:54:02 obviously slightly censored :) Mar 24 08:54:40 The people paying me want as little info to leak as possible Mar 24 09:14:59 So what is interesting here is that it consistently fails on the same things. Mar 24 09:16:27 1st run: Release/node, Release/cctest, Release/mkcodecache, Release/embedtest Mar 24 09:16:39 2nd run: Release/node, Release/cctest, Release/mkcodecache Mar 24 09:16:52 3rd run: Release/node Mar 24 09:16:59 4th run: Success Mar 24 09:17:34 Running again with a cleansstate I get: Mar 24 09:18:02 1st run: Release/node, Release/cctest, Release/mkcodecache Mar 24 09:18:09 2nd run: Release/node Mar 24 09:18:20 3rd run: Success Mar 24 09:24:32 So it is the same steps I'm always failing on and the reason is either OOM or tests/targets are performed in the wrong order Mar 24 09:24:52 Good to know atleast :) Mar 24 10:26:39 bitbake parallel options which only take into account avalaible cores/threads is just wrong, amount of RAM is more often the limiting factor. One needs find out what the limits for RAM are, and tweak BB_NUMBER_THREADS and PARALLEL_MAKE down. Mar 24 10:33:48 Hi, just checking, variable or conditional in DISTRO_VERSION is a bad idea, correct? I wanted to distinguish between our dev and release, but this variable has proven to be difficult with conditionals :) Mar 24 10:35:10 I saw some other projects changing their image names, i.e adding version or datestamp in the image name instead of fiddling with DISTRO_VERSION Mar 24 10:36:39 hi there, i am trying to verify a current HAB setup on an imx6 board. for that i wanted to use the u-boot hab_status command. to get that we enabled IMX_HAB in the u-boot config. but the command still isn't available. any ideas what else we might be missing? Mar 24 10:37:28 creich: how did you enable IMX_HAB option? Mar 24 10:38:32 mcfrisk: I wonder if setting PARALLEL_MAKE to "-l " would help at that. Mar 24 10:38:35 timemaster: using DISTRO_VERSION is good, we use it. but note that SDK version information in yocto is quite broken and buildhistory data for SDK can be annoying to handle if meta/classes/buildhistory.bbclass doesn't have "BUILDHISTORY_DIR_SDK = "${BUILDHISTORY_DIR}/sdk/${DISTRO}-${TCLIBC}-${SDK_ARCH}-${TUNE_PKGARCH}/${IMAGE_BASENAME}"" Mar 24 10:38:51 we used the menuconfig and saved the def_config that should be used Mar 24 10:39:39 atm we try to verify that the build used the correct config using some other options like the 'date' command from the misc setup Mar 24 10:40:03 but as for the hab_status, should there anything else be needed? or is it supposed to be that one option only? Mar 24 10:40:55 mario-goulart: that could help, sure. then would also need to do the same for ninja etc Mar 24 10:41:41 mcfrisk: but how to change it dynamically? anonymous python functions are not being parsed in distro configuration context for some reason which I couldn't track down Mar 24 10:42:56 timemaster: we change it for every build which re-generates conf/local.conf Mar 24 10:43:03 e.g. for all clean builds Mar 24 10:43:03 mcfrisk: oh, good point. Mar 24 10:43:44 mcfrisk: yep, it seems to me like the easiest way too Mar 24 10:46:25 Hi all, are all of the testing frameworks (testimage, selftest, ptest) meant to run on target? I'm looking for a way to test the existence of files in the filesystem on host, what should I use? Mar 24 10:46:57 timemaster: oh sorry, it looks like we do use anonymous python, e.g. DISTRO_VERSION := "${@get_distro_version(d)}" in distro config. That checks git tree status and provides a pure tag for clean and a unique has and "dirty" for all non-clean builds. Mar 24 10:47:16 /has/hash/ Mar 24 10:49:37 mcfrisk: Ok, so if I understand you correctly, I should simply remove two threads from the build chain options? :) Mar 24 10:51:14 mcfrisk: oh really, this works for you? that's great then, and this is in your local.conf or .conf? Mar 24 10:52:47 timemaster: distro config. but if I'd do it now, I'd put this into the generated local.conf. we basically have a 'configure' script for bitbake builds. Mar 24 10:53:27 wertigon: or don't blindly add threads per core, but limit this to e.g. 2 gigs of RAM per thread. Mar 24 10:53:57 mcfrisk: yeah, once you have a proper build server it makes sense.. since there is not much automation currently on our side, I would like yocto itself to take care of such things Mar 24 10:54:37 but the RAM limit depends on what you need to build, for C projects almost everything is fine. for C++ with templates, build time RAM usage can explode. Try building chromium, webkit etc to find out. Mar 24 10:55:41 creich: that should be it, check that arch/arm/mach-imx/hab.o exists after compilation, that should help you Mar 24 10:55:44 mcfrisk: would it be possible to share your get_distro_version function? Mar 24 10:58:43 timemaster: not directly. we use git submodules for all meta layers so a base repo "git describe --abbrev=8 --dirty --always" will be fine, except for dirty builds we also add "git submodule status | awk '{print $2, $1}' | sort | sha1sum | cut -c1-6" Mar 24 10:59:14 qschulz: thx, we'll check that Mar 24 11:10:09 mcfrisk: thanks for pointers, that will save some time :) I was asking mainly to check where you have a definition of that function.. I am expecting something like def get_distro_version(d): somewhere in distro conf, which doesn't work for me.. bitbake immediately throws parsing error Mar 24 11:12:31 cause inherit doesn't for me in distro conf either, which is otherwise a good place for such stuff Mar 24 11:13:48 timemaster: in distro.conf "require classes/distroversion.bbclass", then that class only has get_distro_version() python function which returns the string. nb, we also use that with another custom bbclass to fill in same info to /etc/os-release Mar 24 11:17:31 mcfrisk: cool, so this is how to fool bitbake so it accepts python in distro conf, thank you very much for that! Mar 24 11:20:27 timemaster: not sure if this is cool, or just overly complex and part of the 'fun' of bitbaking /facepalm Mar 24 11:21:33 everything would be a lot simple to just fill in DISTRO_VERSION to local.conf... Mar 24 11:22:30 mcfrisk: well, yes... after trying ten different easy ways which works on other places in yocto, I end up with this.. Mar 24 11:25:27 the problem with local.conf is that it is a temporary configuration storage, if you have some infrastructure around which fills it for you, then you are ok, but if you just want to clone the repo, run source and happily watch all the configuration growing automatically using native templating infrastructure, local.conf is just not enough Mar 24 11:25:32 timemaster: you can use INHERIT in conf files to include a class which can add functions Mar 24 11:26:15 RP: that might work, good point.. tried only inherit Mar 24 11:30:33 with latest dunfell, I also hit sstate warning incremented to error of missing manifest files. I guess I have some custom stuff which generated empty manifest files.. Mar 24 11:38:14 mcfrisk: I think we'll have to back that one out, it will stay in master though Mar 24 11:39:43 RP: I've seen this a lot in the past, the warning, and I'm sure it's a bug in our setup, but I haven't figured out what and where it comes from. Looks like "inherit allarch" and another custom bbclass that we use results in missing do_prepare_recipe_sysroot etc manifest files... Mar 24 11:42:23 mcfrisk: that seems odd as prepare_recipe_sysroot is not a setscene task so would never have a manifest Mar 24 11:43:35 hi, currently I am used to using bitbake and devtool in my standard yocto workspace, and use an SDK for application development. I am looking into the eSDK but I don't understand how devtool modify should work in the eSDK environment? where will it find the recipe files? are they also included in the eSDK? Mar 24 11:45:44 RP: but there is a manifest file missing, and it looks like our bbclass uses MACHINE_ARCH when it should be using PACKAGE_ARCH.. Mar 24 11:48:20 mcfrisk: Ok, I'll make sure to add a recommendation to buy more RAM for build machines then :) Mar 24 11:48:49 Unfortunately we do build qtwebengine Mar 24 11:49:17 I have no idea why nodejs though Mar 24 11:57:45 what is the official way for a sstate cached task to re-do_deploy and overwrite output files? Or is manual cleanup of tmp/deploy the only solution? "The recipe blabla is trying to install files into a shared area when those files already exist." Mar 24 11:59:48 mcfrisk: -c deploy -f but that will taint your sstate-cache and you'll need to clean it later Mar 24 12:00:22 I think Yocto detects when files from deploydir are removed and reinstall them but I am definitely not sure this is true Mar 24 12:00:37 qschulz: hmm, or should recipes provide a "do_clean" task which cleans up the deployed files? Mar 24 12:04:29 mcfrisk: mmmm good point, clean might work too? Mar 24 12:13:08 qschulz: nah, clean doesn't work. just cleaning the deployed file is not enough. would need to clean the manifest file too. Mar 24 12:40:37 if this is in a custom layer "require conf/machine/include/qemu.inc" does it get from the poky/meta layer or from the custom layer? Mar 24 12:41:57 i.e., from poky/meta/conf/... or from poky/meta-custom/conf/...? Mar 24 12:44:37 or does it try one then the other? Mar 24 12:44:50 How Does It Work(TM)? Mar 24 13:05:33 is there a way for modifying a distro without editing the files manufacturer provides directly or creating own distro ? Mar 24 13:05:42 similar to bbappend Mar 24 13:06:12 you can override many things in your local.conf Mar 24 13:07:43 okay Mar 24 13:08:24 nohit: just create your own distro that requires your manufacturer distro conf file Mar 24 13:08:25 i would like to remove splash screen and make it permanent Mar 24 13:08:41 nohit: not sure this is done in distro but more in image recipe? Mar 24 13:09:53 nohit: might also be a hard dependency (DEPENDS/RDEPENDS) in one of the packages/recipes included in your image recipe Mar 24 13:10:18 oh yes its in image receipe Mar 24 13:11:16 yates: see https://docs.yoctoproject.org/bitbake/bitbake-user-manual/bitbake-user-manual-metadata.html#require-directive Mar 24 13:22:17 I'm looking around for oe-selftest usage and I can't seem to find a good example of a sysroot verification. I simply want to check if the files appear in sysroot after a successful build Mar 24 13:30:47 smurray: thanks - i looked in the bbum but could not find that. Mar 24 13:31:29 low-priority question: how are the docs (e.g., https://docs.yoctoproject.org/bitbake) generated? Mar 24 13:34:36 yates: http://git.yoctoproject.org/cgit/cgit.cgi/yocto-docs/ Mar 24 14:09:16 yates: rburton: http://git.openembedded.org/bitbake/tree/doc for https://docs.yoctoproject.org/bitbake I think. https://docs.yoctoproject.org/ is handled in the git repo pointed by rburton Mar 24 14:13:19 when i have a custom kernel, with a custom uapi, shouldn't yocto use these kernel headers as glibc kernel-headers? Mar 24 14:13:36 or another way asked, where does the glibc recipe take the kernel uapi headers from? Mar 24 14:18:03 linux-kernel-headers recipe Mar 24 14:18:16 derRichard: kernels are machine specific recipes Mar 24 14:18:29 ahhhh, linux-kernel-headers Mar 24 14:18:30 thx! Mar 24 14:18:41 this is why i miss stuff Mar 24 14:19:01 so making glibc dependent on kernel headers is basically making any package non-reusable by other machines Mar 24 14:19:13 which is extremely inefficient Mar 24 14:19:59 if you want to add an entry to the uapi, you need to create a recipe that install a header file into the sysroot which will be used by the kernel, kernel modules and userspace applications that requires it Mar 24 14:21:07 the problem is less complicated. my kernel is 5.4 but linux-kernel-headers seems to use 5.2 Mar 24 14:21:14 so, i miss new stuff Mar 24 14:25:28 derRichard: makes sense to upgrade linux-kernel-headers recipe AND USE IT FOR ALL MACHINES Mar 24 14:26:16 derRichard: since 5.4 is an LTS, we probably have/had a recipe for that in oe-core/poky Mar 24 14:27:00 thx, this is what i was about to do :) Mar 24 14:27:51 the Linux-kernel-headers are ONLY used by userspace. The versions and content do NOT have to match the running ekrenl.. Mar 24 14:28:01 I would NOT upgrade it, as you can break glibc/musl, etc.. Mar 24 14:28:29 as long as the linux-kernel-headers are the same or older then the running kerenl, it will work fine Mar 24 14:29:30 people need to stop thinking there is something magic in the linux-kernel-headers.. there isn't, it's just defining the APIs used by the system libc. The Linux kernel folks have promised that they will remain backwards compatible in newer versions of the kernel -- so there is no reason to upgrade it (as a user) even if you are rolling foward your kernel version. Mar 24 14:29:58 Additionally, programs that are trying to talk to module interfaces should NOT be using it as a foundation for ioctl and similar. As ioctls are not part of the defined glibc mechanisms Mar 24 14:31:42 (best way to handle this, think of the system as userspace and kernel space. linux-kernel-headers, libc, etc are all userspace. Linux _kernel_ and modules are all kernel space.. When building, one should space should not refer to another. Mar 24 14:33:46 fray: well now the question is... what derRichard Is missing in 5.2 kernel headers Mar 24 14:34:06 since socketcan folks broke the uabi, i need to use 5.4 heards on both sides Mar 24 14:34:15 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=f5223e9eee651e005c0f6d6d078909087601b7e9 Mar 24 14:34:37 struct socketaddr_can now has differenct sizes :( Mar 24 14:34:44 (this needs to be fixed anyway) Mar 24 14:34:49 but for now i need to work around that Mar 24 14:35:36 Any userspace driver that needs specific knowledge of a kernel interface (magic numbers, including ioctl) should carry it's own knowledge. Often this is done with a copy of a specific chunk of the driver's (kernel) header in the userspace driver.. Mar 24 14:35:50 For well defined interfaces, glibc handles the interactions/translations for you Mar 24 14:37:20 not if due to a kernel bug the uabi was broken Mar 24 14:37:24 ...which is here the case Mar 24 14:37:29 in this case, I would verify that glibc has no references to can.h (I'm pretty sure it doesn't, as it has no specific knowledge of can inteface, unlike sockets/pipes/tcp/ip.. Mar 24 14:38:09 Assuming glibc does NOT have direct knowledge of the can.h interfaces, then you can carry a temporary copy of it -- or patch linux-kernel-headers with the one file. Either will work fine.. Mar 24 14:38:10 * derRichard checked Mar 24 14:38:31 This is a bit of an unusual situation as it should be a "more" stable interface.. Mar 24 14:39:01 where I usually see this is ioctls and other 'magic numbers' that userspace programs are trying to get access. In those cases, the right answer is always to include a copy of the magic numbers within the userspce component.. Mar 24 14:39:09 Ya, that one is a little annoying because it's a change in the socket address type Mar 24 14:39:36 i found that an hour ago, will talk later to socket can folks. IMHO this is a bad bug Mar 24 14:39:53 but for now i need to get my application stack in shape again Mar 24 14:39:56 since they placed it at the end of the structure, theoretically it's compatible.. but ya.. iffy.. Mar 24 14:40:13 I'd almost consider defining a new structure specifically to resolve this issue.. i.e. can_new.. can_2.. etc etc etc Mar 24 14:40:20 breaking an existing interface is not a good idea Mar 24 14:40:27 derRichard: Is the problem that the program is receiving the address into a `struct sockaddr_can` struct? Mar 24 14:40:29 (even for a less used interface like CAN) Mar 24 14:40:56 JPEW: yes. i use recvfrom() on AF_CAN Mar 24 14:41:30 Ya, the recieve buffer should be something else... "struct sockaddr" maybe? That ensures it's big enough and you typecast it to the specific type (I think) Mar 24 14:41:56 (for a VERY long time, CAN required a local to the app copy of the can headers.. just as an FYI..) Mar 24 14:42:57 JPEW: let me check that the application really does (it was not written by me) Mar 24 14:43:04 *what the Mar 24 14:47:57 derRichard: Ah, how unfortunate: it looks like the struct sockaddr only reserves 14 bytes for sa_data, but the sockaddr_can has 17 data bytes, so even that wouldn't fix it :( Mar 24 14:48:46 derRichard: Oh, right, use "struct sockaddr_storage". It's big enough :) Mar 24 14:51:51 * armpit rust is nuts Mar 24 14:53:00 qschulz: JPEW: should i add a recipes-kernel/linux-libc-headers/ recipe to my layer? Mar 24 14:53:18 i'm not sure that the best way is Mar 24 14:53:33 i don't really want to copy linux-libc-headers.inc into my layer Mar 24 14:54:40 derRichard: No, fray is correct. If your application needs specific kernel API, it should have it's own copy of the header... a lot of libraries that wrap kernel functionality do this (e.g. libdrm) Mar 24 14:55:45 JPEW: and what about can-utils? they use can too with recvfrom() Mar 24 14:55:47 it will break too Mar 24 14:56:35 Ya, that's a bug in can-utils Mar 24 14:56:49 They should be using struct sockaddr_storage Mar 24 14:58:00 just checked, they have their own copy of can.h. so, they are safe Mar 24 14:58:20 derRichard: They still should be using struct sockaddr_storage Mar 24 14:58:33 Otherwise, they have to be kept in lock-step with the kernel Mar 24 14:59:24 Well, maybe not since they pass their own size I guess Mar 24 14:59:58 and why is poky even upgrading thir recipes-kernel/linux-libc-headers/? Mar 24 15:00:21 you say every application has to ship their own headers, which makes only kind of sense Mar 24 15:01:27 derRichard: linux-libc-headers is the copy of the headers for libc Mar 24 15:02:14 RP: yes, these headers will then be available in sdks, right? Mar 24 15:02:28 derRichard: since the sdk contains libc, yes Mar 24 15:02:42 i'm using kernel 5.4 and want the headers from 5.4 in my sdk, and not 5.2. :) Mar 24 15:02:56 IIUC i need to move linux-libc-headers to 5.4 then Mar 24 15:03:51 derRichard: correct. But just use a plain upstream kernel for linux-libc-headers, not some machine hacked up one Mar 24 15:04:01 of course, yes Mar 24 15:04:07 in my case a plain kernel will do it Mar 24 15:04:27 derRichard: if a plain kernel wouldn't do it, there would be an issue somewhere Mar 24 15:05:02 agreed Mar 24 15:05:31 so i'll have my own linux-libc-headers in my layer with 5.4 upstream such that it matches my upstream 5.4 kerel Mar 24 15:05:34 *kernel Mar 24 15:11:34 @derRichard: https://bugzilla.yoctoproject.org/show_bug.cgi?id=13955 Mar 24 15:14:17 What are the best practices to include custom systemd udev rules for your platform? Mar 24 15:17:22 not sure about best practices, but I'd expect just jamming *.rules in your FILES_${PN} and shuffling them into the proper places in your recipe is more than sufficient Mar 24 15:18:12 and I'd expect .bbappend-ing the various recipes that splat in other rules would be decent path forward when editing existing rule-sets Mar 24 15:30:15 I'm getting myself into a funky state with kas/bitbake. It looks like one of the patches I applied in a `bbappend` already has been applied to the source the last time this built. I have since edited another part of the recipe, and now the bbappend is failing to apply the patch a second time Mar 24 15:30:56 I'd like it to either: Not apply the patch twice in a row because it already did that.... or clean everything so it downloads source, and rebuilds everything and applies the patch to a clean state Mar 24 15:31:18 I don't know if the former is possible... and `bitbake -c cleanall ` mysteriously doesn't fix my problem Mar 24 15:31:48 do I need to run some other command other than cleanall to "go back to a time before patches were applied?" Mar 24 15:36:53 Spooster: no, -c cleanall does that. Is it possible you have your patch twice in SRC_URI? Mar 24 15:37:14 It must be something silly like that Mar 24 15:38:25 unfortunately, in the bbapend I'm aware of, the patch is only listed once Mar 24 15:38:31 but I'd suspect something somewhere is bring it in Mar 24 15:38:55 vdl: I'm just working on that and what I'm trying to do is to have udev-.bb recipe which plops out multiple PACKAGES, where each package has just one udev rule. Then either specify the package in .conf or .conf Mar 24 15:40:57 qschulz: .bbappend for the curious. My only guess at the moment, is that I might have to read more about what `FILESEXTRAPATHS_prepend := /${THISDIR}/files` is doing... because it's probably doing exactly that Mar 24 15:41:03 https://pastebin.com/g2ySjeFF Mar 24 15:43:49 Dear community, Mar 24 15:44:28 Is there a way to replace program (like tar) from work/hosttols directory? And replace it with -native one build from Yocto ? Mar 24 15:44:51 The problem is that I do use the old machine to build recent yocto Mar 24 15:45:13 and tar is not supporting features needed by contemporary yocto/OE Mar 24 15:45:14 Spooster: did you check the files/ directory for the recipe you're appending to? Mar 24 15:47:09 I only have one patch in the files I'm appending... Mar 24 15:47:11 lukma: run install-buildtools Mar 24 15:47:21 and the recipe's original source doesn't have any patches to speak of Mar 24 15:48:59 Sponge5: got it Mar 24 15:50:00 btw is there some kind of naming convention for custom tty? like ttyCUSTOMER[0-9] or customer-tty-[0-9], etc.? Mar 24 15:53:00 rburton: I will check this option :-), thanks Mar 24 15:53:31 checking `bitbake-layers show-appends`, I see that only my one .bbappend is being applied Mar 24 15:53:57 I just moved the recipe to it's own folder to make sure other nearby files and recipes weren't causing trouble Mar 24 15:55:00 Spooster: when you do -c cleanall, do you still have a workdir for your recipe? Mar 24 15:59:42 qschulz: I think yes... it looks like `build/tmp/work/raspberrypi4_64-poky-linux/weston-init` persists after a `bitbake -c cleanall weston-init` Mar 24 16:01:04 I'm not sure I expected to fine `weston-init` under `raspberrypi4` like that... Mar 24 16:01:21 the recipes comes from poke/meta/recipes-graphics/wayland Mar 24 16:03:32 (I think I'm at like... a negative typing accuracy at this point... *find, *recipe, *poky/) Mar 24 16:04:12 rburton: Is the install-builtools script doing the same as installing https://downloads.yoctoproject.org/releases/yocto/yocto-3.1.5/buildtools/x86_64-buildtools-nativesdk-standalone-3.1.5.sh ? Mar 24 16:04:17 yes Mar 24 16:04:44 rburton: I do manually downlod those tools and install them Mar 24 16:05:13 despite of that the OE/Yocto uses the tar from ./hosttols/ directory which is a sym link to system's old tar Mar 24 16:05:34 maybe only the extended one includes tar? Mar 24 16:06:05 nope the 3.2 non-extended one definitely includes tar Mar 24 16:06:33 you need to source the setup script before doing oe-init-build-env, and if hosttools already exists it won't get updated Mar 24 16:06:52 update... while the folder still exists, the contents of the folder are indeed being wiped out by the `bitbake -c cleanall` Mar 24 16:08:29 rburton: It may be that I had hosttols setup earlier Mar 24 16:08:37 so those won't get updated Mar 24 16:09:59 running `bitbake -c fetch` and bitbake -c unpack` shows that the file and patch are already coming in... and the `weston.ini` is somehow "pre-patched" Mar 24 16:10:49 Spooster: how did you create your patch for weston.ini? Mar 24 16:11:16 it seems to me there's a mismatch between your development environment for the patch and the sources in Yocto Mar 24 16:11:54 rburton: Why hosttols links are not updated? Is this a design decision? Mar 24 16:12:12 I copied the file on the running system, made my changes, ran a diff, and formatted it accordingly Mar 24 16:12:23 Hi, I am trying to generate an archive of source files used in the rootfs to scan with a separate tool regarding license compliance. I tried using the archiver class but this currently includes build dependencies, not just the runtime dependencies. As far as I can tell, there currently is no mechanism for filtering this, right? Mar 24 16:13:02 I actually want to verify I didn't much around in the src from /poky/meta... that might have been something silly I did Mar 24 16:14:22 yep... I think I mucked around in my source files at one point Mar 24 16:28:49 Spooster: hehe Mar 24 16:39:48 hehe exactly Mar 24 16:39:57 tyvm Mar 24 16:42:20 glad you found out by yourself, that would have been a tricky one to debug. Mar 24 16:50:41 rburton: wondering if seeing https://autobuilder.yoctoproject.org/typhoon/#/builders/65/builds/3256 is the meson change? :/ Mar 24 16:50:47 oobitots51: ^^^ Mar 24 16:50:52 RP: i suspect it is :( Mar 24 16:50:57 shall try to replicate Mar 24 16:54:24 RP: i expect that's because i tested on arm64 so it can run native Mar 24 16:54:28 i'll do a rebuild with qemux86 Mar 24 16:54:52 rburton: right, the failures all look cross related Mar 24 16:55:15 i suspect i just need to pass another option Mar 24 16:55:21 sorry about that Mar 24 16:55:35 rburton: np, happens :) Mar 24 16:56:05 rburton: I'll abort, drop that bit and retry which will confirm it is that change Mar 24 17:05:21 does each tag(e.g. yocto-3.2.2) has its upstream branch so I can track and merge any changes for each stable releases, if any Mar 24 17:05:51 it appears to be a fixed tagged tarball to me Mar 24 17:06:37 rr123: 3.2 is the gatesgarth branch Mar 24 17:07:15 codenames in repos are easier to match than having every repo use the same version scheme Mar 24 17:07:24 $ git branch --contains yocto-3.2.2 -r Mar 24 17:07:25 origin/gatesgarth Mar 24 17:08:30 agree, the quick-build doc uses 'git checkout tags/yocto-3.2.2 -b my-yocto-3.2.2' which is what most newcomers will follow, but it can not be pulled-merged in the process, I will assume gatesgarth has the up-to-date 3.2 code then Mar 24 17:08:56 rr123: we should perhaps change change. Mar 24 17:09:04 michaelo: ^^^ - might be worth a look Mar 24 17:12:05 personally i actually prefer 3.2 to gatesgarth, honestly after a while i forgot the name but I appreciate the first letter keeps some order to stay sane, now the question, is yocto-3.2 the same as gatesgarth(i.e. the tip of all 3.2.x releases), or is it just the first 3.2 checkpoint, sort of 3.2.0? Mar 24 17:12:36 rr123: 3.2.0 I suspect Mar 24 17:13:23 a little ambiguous to the paranoid, anyway I got it, thanks Mar 24 17:13:35 rr123: it is effectively impossible to make "3.2" work for all the repos that would use it unfortunately Mar 24 17:21:24 JaBen: I guess you could use buildhistory which lists all packages installed in an image and archive to get the source of said packages? Mar 24 17:32:18 @qschulz: hm... I had a similar idea involving the rootfs manifest... but I wasn't sure if and how I would be able to integrate that in the yocto build itself. from the top of my head I wouldn't be able to tell if parsing individual package names to the archiver class is possible. Would you have a rough idea where to start? Mar 24 17:40:19 rr123: bookmark https://wiki.yoctoproject.org/wiki/Releases to preserve sanity Mar 24 17:42:22 @qschulz: imo the "clean" way would be being able to parse a flag to the archiver class itself, maybe extend the COPYLEFT_RECIPE_TYPES with rdepends and depends though I'm not sure how hard it would be to access the package meta-info "depends or rdepends?". I think I'll might look into it, if you guys agree on this approach Mar 24 18:00:40 rr123, RP: do you mean we should add "git branch --set-upstream-to=origin/gatesgarth my-yocto-3.2.2" to the documentation, so that people can later run "git pull" on their branch? Mar 24 18:01:28 michaelo: yes, or I just do: git checkout -t origin/gatesgarth -b my-3.2.x Mar 24 18:03:21 rr123: yes, indeed much better. I was indeed thinking about my-3.2.x for the local branch name. Good catch, thanks! Mar 24 18:05:47 Then I'll probably replace the "git tag" command by "git branch -a" to find out which remote branch to pick, together with a reference to the correspondance between release names and version numbers. Mar 24 18:06:13 I'll propose something to the docs@ mailing list for review. Thanks again Mar 24 18:06:46 cool, thanks! Mar 24 19:06:16 last time i worked with yocto is 2017, any major changes since then? after I tested with x86 build and now I want to cleanall for the whole build, is there a command or I just brutally `rm -rf build/`? Mar 24 19:07:21 you could always bitbake you_image -c cleanall Mar 24 19:07:56 plan to do a raspberry pi 4 build to warm up cross-build steps, and last but not least, i'm a debian guy so i don't really use rpm, is deb/ipk as golden as rpm as far as yocto's test procedure goes(are they both tested as much somehow)? Mar 24 19:08:19 cleanall will spend ages carefully wiping your sstate, so that's not a good idea Mar 24 19:08:39 rr123: opkg and rpm are equally good, dpkg less tested Mar 24 19:08:48 if you want to blast the build, just rm -rf tmp Mar 24 19:09:03 it can rebuild entirely from sstate-cache, so leave that be unless you'll never need it again Mar 24 19:10:05 itbake -c cleanall core-image-minimal -- does not really do much, it probablly only delete that final image Mar 24 19:10:42 yeah i don't need this for x86 so I intend to remove all sstate and tmp Mar 24 19:14:40 * rr123 did `rm -rf build` after saved the downloads directory there Mar 24 20:21:47 Hi, anyone an idea on the following: I'm trying to backport python 3.7.6 to yocto gatesgarth as I have a program that can't use 3.8 or 3.9.. Mar 24 20:21:47 I copied over the recipe and all files, but when building the rootfs I get a compile error in meson-0.55.1 Mar 24 20:21:58 from setuptools import setup Mar 24 20:21:58 ModuleNotFoundError: No module named 'setuptools Mar 24 20:23:50 however the meson recipe has an inherit setuptools3 line Mar 24 20:24:52 any idea what can be wrong here? If I reset all of recipes-devtools to the last hash that has 3.7.6 everything builds but that gives me other old packages Mar 24 20:25:51 why package-management is an image feature and not a distro feature? Mar 24 21:33:31 vmeson: my concerns about valgrind seem founded ;-) Mar 24 21:43:13 Saur|home: I'm trying a slightly more invasive util-linux cleanup patch in master-next Mar 24 22:48:26 is glibc the only officially supported c lib in yocto? any plan for official musl support Mar 24 22:49:02 where deep embedded system might find it useful(no gtk, no GUI, etc) Mar 24 22:49:05 rr123: musl is available Mar 24 22:49:37 rr123: poky-tiny uses it as one example Mar 24 22:56:26 it isn't 'extensively used' so I guess it provides a base for others to leverage, other than that you're on your own. will look into for more, so far the newest check in is 2020.8 for 5.8 kernel upgrade Mar 24 22:57:47 i'm trying to do some RTS, but i'm getting this error when setting up the build environment: Please set a MACHINE in your local.conf or environment Mar 24 22:58:13 the whole message is here: http://paste.ubuntu.com/p/375bZhGRZd/ Mar 24 22:58:20 RTS == Really Tricky Shit Mar 24 22:58:50 but there IS a conf/local.conf and it DOES have a MACHINE setting Mar 24 23:01:37 and there is a layer added to bblayers.conf which has a conf/machine/xyz.conf file for the MACHINE setting xyz Mar 24 23:02:36 here's my RTS: http://paste.ubuntu.com/p/wzxC2Cnj65/ Mar 24 23:03:14 well, no. try here: http://paste.ubuntu.com/p/HTkBtw6jNj/ Mar 24 23:04:14 are there any other environment variables setup by oe-init-build-env besides BBPATH, BB_ENV_EXTRAWHITE, and BUILDDIR? Mar 24 23:06:00 also note that i did not emit all the comments into the local.conf file - shirley that doesn't matter? Mar 24 23:07:48 RP: isn't there newlib too? Mar 24 23:12:29 for env is it 'bitbake -e' Mar 24 23:15:48 rr123: are you talking to me? Mar 24 23:28:38 rr123: we do test world builds for musl so it does have some support Mar 24 23:29:32 yates: yes, there is a newlib option Mar 24 23:29:59 yates: that error means MACHINE wasn't set when bitbake checked it so somehow it isn't being set **** ENDING LOGGING AT Thu Mar 25 02:59:56 2021