**** BEGIN LOGGING AT Fri Nov 15 02:59:58 2019 Nov 15 04:52:38 New news from stackoverflow: Yocto build failed while upgrading to pulseaudio 12.0 Nov 15 06:07:47 khem: Alright got it working. Now I just had to add KERNEL_DEVICETREE_append = "overlays/ads7846-overlay.dtb" Nov 15 06:12:12 cool, submit a documentation patch if you think we can improve it for future Nov 15 07:21:43 Alright.. I will Nov 15 08:34:00 good morning Nov 15 09:00:22 I am trying to add to multilib rootfs lib32-glibc-gconvs. If I add the normal 64bit package glibc-gconvs then all other convs are added automatically. eg iso utf etc. But this is not happening with the lib32-glibc-gconvs. In order to add the lib32-conv I want I have to add it by hand. Nov 15 09:01:51 Is this known issue for gconvs? Does anyone knows how to add all of them for lib32 without explicitly add them all of them in IMAGE_INSTALL? Nov 15 09:23:55 Morning everybody, reposting since we're more during normal operating hours for #yocto :) some progress made on debugging the basehash changed issue in our vendor BSP layer. We uncommented RP's line in siggen.py to generate a sigbasedata. The diffsigs is tasks added to the task dependencies. Any idea how to find the recipe/class we should behead? Nov 15 10:22:24 About the problem I wrote about I compared the files: pkgdata/runtime/glibc-gconvs and pkgdata/runtime/lib32-glibc-gconvs and found out that RRECOMMENDS_glibc-gconvs has all the cons written but it is not happening the same with RRECOMMENDS_lib32-glibc-gconvs. I am trying now to figure out why and how RRECOMMENDS_lib32-glibc-gconvs is generated. Nov 15 10:42:17 qschulz: which tasks are being added? Nov 15 10:46:24 RP: diffsigs sigbasedata sigdata for base_files.do_install => [+base-files/base-files_3.0.14.bb.do_compile pseudo/pseudo_git.bb.do_populate_sysroot:virtual:native] Nov 15 10:46:58 RP: BSP layer for rocko that we're trying to use on thud if that helps in any way (thud 2.6.4) Nov 15 10:47:32 RP: diffsigs sigbasedata sigdata for os-release.do_compile => [+os-release/os-release.bb.do_configure] Nov 15 10:52:43 qschulz: base-files isn't a very common dependency as it happens Nov 15 10:53:00 qschulz: that sounds a lot like something bbappending the useradd class Nov 15 10:54:09 although its not quite right as I'd have expected it to have appeared as a different form Nov 15 10:55:04 qschulz: base-files do_compile is usually empty and wouldn't run under pseudo so its as if something is editting the base-files recipe Nov 15 10:56:52 RP: what I'm puzzled about is I usually get this error when I mistakenly save a recipe while bitbake is building/parsing. So I'm surprised how that is possible from within bitbake execution without us touching anything Nov 15 10:57:26 FYI, we do have useradd errors in one of our custom recipes after those basehash errors Nov 15 10:58:09 qschulz: I have to admit I don't remember all the context of the problem you're debugging but it seems odd that base-files is changing. Does the BSP edit that recipe? Nov 15 10:58:18 `useradd: group bluetooth exists - if you want to add this user to that group, use -g.` while it works (TM) currently in our layer without that vendor's layers Nov 15 10:59:22 RP: I haven't really given any context tbf. We have received a very ugly BSP (they require manual merging of two directories, manually resolving conflicts and whatnot) and we're trying to integrate it in ours for starters Nov 15 11:00:40 and they *really* want us to not do anything else than this bullshit. Plan is just to have something an image that kinda works good enough so we can clean all of this Nov 15 11:01:58 so I'd assume that they are doing some nasty stuff, I just wanted some pointers on where to look. maybe someone has experience with those BSP layers "snickily" modifying core things and could help orient our debugging session :) Nov 15 11:03:46 RP: find . | grep useradd returns nothing in vendor layers Nov 15 11:06:01 qschulz: and base-files ? Nov 15 11:07:36 qschulz: it sounds like there is something nasty going on but our syntax is so flexible I'm struggling to give specific advice Nov 15 11:07:53 qschulz: I'd probably start minimising the test case in your position Nov 15 11:08:07 reduce it to a "bitbake base-files" or similar Nov 15 11:08:20 then start deleting bits of the BSP that should have no effect Nov 15 11:10:08 RP: ok, following the advice I'm giving to everybody then. Starting small :) Nov 15 11:10:17 Just read yesterday's LWN article on the Yocto Project 3.0 release by RP. It's a good one and I understand the whole hash equivalence thing a lot better now! Nov 15 11:10:40 (I can share a subscriber link if anyone without an LWN subscription wants to read it) Nov 15 11:12:41 I'm trying to create a fully reproducible ramdisk and I'm down to /var/cache/ldconfig/aux-cache Nov 15 11:13:26 RP: Do you have plans to post that to the mailing list or should I do that? Nov 15 11:16:00 RP: I'll let you know if we make progress/find the issue. Thanks for your time Nov 15 11:16:52 does anyone know why for lib32-glibc-locale recipe adds RRECOMMENDS_lib32... for binaries but not gconv, localedatas and charmaps? Nov 15 11:27:53 paulbarker: I had no plans... Nov 15 11:28:02 paulbarker: glad you found it useful! :) Nov 15 11:32:16 Hi there. I need some help regarding the bitbake cache. Nov 15 11:32:17 I create a recipe which install configuration files to my device. It looks like SRC_URI = "file://configs/*", do_install part and FILES_${PN}. Let it be "my-configs_01.bb" Nov 15 11:32:17 When I need to add another one config, I just add it to the recipe "files" directory, install it via "do_install" and add to FILES_${PN}. Nov 15 11:32:17 Problem itself: file added to recipe, but when I try to build image bitbake says "No such file or directory". So I need to run "-c cleanall my-configs" before building image. After "cleanall" everything is OK Nov 15 11:32:18 I thought it's some kind of caching (sstate maybe?). I'm wondering if there is a "good" way to update recipe content without running "cleanall" every time Nov 15 11:36:20 In my Build Appliance getty is not starting. I'm using systemd. Do somebody experience same problem? Nov 15 11:36:35 copycat88: it does sound a bit like a caching bug :/ Nov 15 11:36:55 copycat88: we've had reports of this on and off for a while but I've not had something I could reproduce Nov 15 11:37:24 copycat88: its not sstate, its the fetcher code not finding the right set of files to hash Nov 15 11:37:53 who expands the * and when.. ? Nov 15 11:38:09 ernstp: the fetcher would have to at parsing time Nov 15 11:38:30 RP: got it. BTW, Yocto version is 2.5. I can provide more information if it could help Nov 15 11:38:54 copycat88: first question unfortunately is "does this happen with master?" Nov 15 11:39:01 copycat88: without the * you probably don't have any issue... Nov 15 11:41:11 what do you think about added a | sort | in "find . | cpio -o -H newc" in IMG_CMD_cpio ... ? Nov 15 11:43:05 RP: good question) Well, I'll test in nearest feature, and report again in case of same issue Nov 15 11:44:42 ernstp, thanks, I'll try Nov 15 11:45:10 copycat88: but then you need to list all the files explicitly Nov 15 11:50:59 copycat88: One thing which would really make this easy to fix would be to add a test case which fails to the fetcher so bitbake-selftest shows the problem Nov 15 11:51:09 copycat88: bitbake/lib/bb/tests/fetch.py Nov 15 11:53:44 New news from stackoverflow: Unable to resolve Error: pulseaudio-server rdepends on Nov 15 12:14:21 copycat88: don't use * in SRC_URI. You can put a dir in SRC_URI and everything in it will be taken. Nov 15 12:17:09 qschulz, hmmm, sounds very promising. Will try Nov 15 12:42:21 Hi, its me again. Iam not able to get a list with size of every chosen package with BUILDHISTORY. Is there something i need to know? Nov 15 12:42:43 I inherited buildhistory and then i set BUILDISTORY_COMMIT = "1" Nov 15 12:48:08 GeneralStupid: BUILDHISTORY_FEATURES = "image" Nov 15 12:48:37 but that should work by default Nov 15 12:49:42 the list should be in tmp/buildhistory/images//*//installed*.txt Nov 15 12:51:09 we have it with BUILDHISTORY_COMMIT="0" BTW Nov 15 12:51:24 where did you put this? it should be in local.conf Nov 15 12:59:33 it is in local.conf. i will just retry it Nov 15 13:00:08 so there was no BH_FEATURES in my config - i added it right now Nov 15 13:00:30 Does anyone know why lib32-glibc-locale adds RRECOMMENDS_lib32-glibc-binaries but not RRECOMMENDS_lib32-glibc-gconvs localedatas and charmaps? The glibc-locale addes RRECOMMENDS to all. Nov 15 13:02:00 GeneralStupid: it should be fine without since the default has image already in it Nov 15 13:03:49 hmm do i need to force a rebuild ? Nov 15 13:04:23 GeneralStupid: a cleansstate command on the image hopefully does the trick Nov 15 13:06:36 LetoThe2nd: it does. great! Nov 15 13:06:51 This is amazing. 2 Mb of libc ;) Nov 15 13:06:52 Nov 15 13:06:52 Nov 15 13:07:07 sorry my terminal had a lag Nov 15 13:48:38 hm is there a way to debug the kernel building process, it looks like my defconfig is not used Nov 15 13:49:13 and on top: is there a reason why libc is used instead of e.g. uclibc? Nov 15 13:50:22 musl is supported if you want. glibc is just the default one AFAICT Nov 15 13:50:56 GeneralStupid: in a nutshell: because most things work nicely with glibc. Nov 15 13:51:10 but its 2 Mib :) Thats why i ask Nov 15 13:51:27 udev and all of this blkid stuff is also not needed Nov 15 13:51:47 GeneralStupid: for most people 2mib are less of a problem than the pains of uclibc Nov 15 13:51:53 GeneralStupid: check that your bbappend is taken into account, check that you have defconfig in your SRC_URI. You can use bitbake -e virtual/kernel to see which file is taken Nov 15 13:52:00 GeneralStupid: and udev is certainly not pulled in by default Nov 15 13:52:26 if you run bitbake -c menuconfig virtual/kernel you'll see the menuconfig with the defconfig that is used during compilation Nov 15 13:52:30 LetoThe2nd: maybe via imx layer? Nov 15 13:52:37 GeneralStupid: well, maybe? Nov 15 13:52:46 qschulz: this sounds great! Nov 15 13:53:38 GeneralStupid: have you added NO_RECOMMENDATIONS somewhere? That way you know it's either dependencies (so look for PACKAGECONFIGs of recipes or DEPENDS) or installed in the image "manually" Nov 15 13:54:05 if you don't want a package you can use PACKAGE_EXCLUDE. That way you know which recipe cannot build because of that package Nov 15 13:54:31 you can also use bitbake -u taskexp to check the recipe/tasks dependencies Nov 15 13:54:31 what does the switch -e output? Nov 15 13:55:42 GeneralStupid: hum. did you actually watch the livecoding session like i already sugegsted a ocuple of times? Nov 15 13:56:16 GeneralStupid: because they contain a lot of answers and explanations to the things you asked over the last couple of days. Nov 15 13:56:31 LetoThe2nd: ok i will start it right now Nov 15 13:57:10 GeneralStupid: you can probably skip #1 - quick start, but #2 und #3 will certainly show you many interesting, yet basic things. Nov 15 13:59:05 plus, for the general record: anybody who feels liks chiming in, please add/comment to https://stackoverflow.com/questions/58863254/how-to-manage-meta-layers-for-a-yocto-project-build-configs-in-git Nov 15 13:59:27 i think we (ab)use this post for further reference, as this is certainly a recurring topic Nov 15 14:04:05 LetoThe2nd: yes i already skipped one. But it starts to get interesting and looks helpful :D Nov 15 14:14:06 chandana73: AUH (auto upgrade helper) can be used to check for recipe upgrades http://git.yoctoproject.org/cgit/cgit.cgi/auto-upgrade-helper/tree/README Nov 15 14:14:59 chandana73: it uses devtool under the hood Nov 15 14:16:29 chandana73: like all layers in meta-openembedded, updating recipes is a community effort. per recipe "maintainer" responsibility only applies to oe-core Nov 15 14:16:38 LetoThe2nd: I feel like it's always a hot topic. Can't we have a nice wiki page for that? Nov 15 14:17:50 qschulz: go ahead Nov 15 14:18:20 RP: regarding the bitbake exclude local dirs patch, so i will add as default git fether SCM dirs is it fine? Nov 15 14:19:36 alimon: I think so. I'm struggling to see a case which that would break? Nov 15 14:20:59 RP: the unique case is when people uses CVS directory to store sources isn't a CVS repo Nov 15 14:21:18 RP: i see more difficult that people uses .DIR to store valid sources Nov 15 14:22:05 alimon: surely people don't do that though? Nov 15 14:22:26 so thanks a lot and have a nice weekend Nov 15 14:22:31 If they do, they could override the value? Nov 15 14:22:50 RP: skilled people dosen't :), so we are fine Nov 15 14:24:10 New news from stackoverflow: QA Issue in yocto build while trying to pack symlink in my image Nov 15 14:27:40 RP: i will send a v2 with new default value Nov 15 14:28:12 LetoThe2nd: I don't use any of those solutions :) Nov 15 14:28:25 (we handle them manually so nothing worth sharing) Nov 15 14:28:45 qschulz: nah, i mean: feel free to pour the things said into a wiki page :) Nov 15 15:05:36 alimon: thanks Nov 15 15:05:50 alimon: btw, can ptest-runner output in a lava consumable way? Nov 15 15:05:57 alimon: I was asked this recently Nov 15 15:10:18 RP: yes we have a lava test definition for do tha Nov 15 15:10:21 that* Nov 15 15:11:31 RP: https://github.com/Linaro/test-definitions/tree/master/automated/linux/ptest Nov 15 15:11:41 alimon: they were wondering if we should have ptest-runner be able to output directly like that? Nov 15 15:12:27 RP: yes we can do it, i mean now we have ptest output and xml output, so we can add lava output support Nov 15 15:12:35 alimon: I thought I'd at least mention the idea as making that an option might be interesting Nov 15 15:12:50 and would mean OE images with ptest installed become more directly testable with lava Nov 15 15:13:00 RP: agree by default use ptest output and choose for LAVA compatible Nov 15 15:13:27 RP: right the wrapper will not needed... Nov 15 15:14:16 RP: In the same topic, ndec commented me about to continue the integration of OE runtime/testimage tests and LAVA Nov 15 15:14:42 alimon: I've been asked about that a few times but don't know where that stands now Nov 15 15:15:47 RP: yeah i mean i have some kind of idea and we have the bug but isn't trivial Nov 15 15:16:08 alimon: definitely not trivial Nov 15 15:17:29 RP: i will spend sometime trying to breakdown the tasks to have more clear path to implement Nov 15 15:17:50 alimon: that would help a lot Nov 15 15:19:39 live session (retry of tuesdays topic!) on https://www.twitch.tv/yocto_project - starting in 10 minutes Nov 15 15:20:07 LetoThe2nd: gl Nov 15 15:20:22 thx Nov 15 15:54:09 can we add some specific feature from the BSP intop the image? Nov 15 16:07:43 BobPungartnik: I think you'll have to be more specific with your question - not sure what you're asking Nov 15 16:10:10 hmm, git-subtrac is rather interesting. doesn't avoid all the issues with submodules, but definitely helps with some Nov 15 16:20:21 Nov 15 16:21:09 I just had a thought to use some BSP ressource like a specific BUS controler, justo to show integrataion between BSP and aother Layers Nov 15 16:22:14 that doesn't really make sense Nov 15 16:22:37 a bsp layer just holds recipes that build things that get installed in an image like any other layer. presumably it provides a bootloader and kernel for use on target Nov 15 16:22:45 another layer isn't going to 'use' a bus controller Nov 15 16:29:18 * kergoth ponders Nov 15 16:41:08 * armpit but a layer can be in a Bus controller Nov 15 17:12:51 hello Nov 15 17:33:48 hi Nov 15 17:43:54 JPEW: hi! Nov 15 18:24:40 Ha, I'm trying out swaywm and trying to get copy+paste working... didn't realize I sent that test message :) Nov 15 19:03:40 JPEW, that was a choice of a test message.. could have been worse ; ) Nov 15 21:37:35 we've modified our fstab file to mount efivars, however, not all our kernel's support efivars Nov 15 21:37:56 we were wondering if we should make this a DISTRO_FEATURE, or if there's already a config for this Nov 15 21:46:40 I think we'll just add "efivars" to DISTRO_FEATURES to enable/disable it. Then we'll just verify that it's configured in the kernel if it's in DISTRO_FEATURES. If anyone has a better way let me know. Nov 15 23:38:57 hi all- can someone give me some advice about a simple bitbake recipe? Nov 15 23:39:21 I'm pulling down `figlet` from github and running "inherit autotools" Nov 15 23:45:05 but bitbake is downloading the source to tmp/work/aarch64-poky-linux/figlet/version/git, but it's running `make` in .../figlet/version/build Nov 15 23:45:41 how do I point autotools to the git directory for the source? Nov 15 23:46:22 toner: S = "${WORKDIR}/git", see other git recipes Nov 15 23:46:51 aha, cool thanks! Nov 15 23:48:38 hmm, it is still not finding the Makefile Nov 15 23:49:01 I tried adding EXTRA_OEMAKE = "'BUILDDIR=${S}'" too, but no dice Nov 15 23:49:06 * toner continues reading Nov 16 00:04:09 ah, I got it working with autotools-brokensep Nov 16 00:05:33 I also had to add INHIBIT_PACKAGE_STRIP and INHIBIT_PACKAGE_DEBUG_SPLIT hmm **** ENDING LOGGING AT Sat Nov 16 02:59:57 2019