**** BEGIN LOGGING AT Thu Nov 21 02:59:57 2019 Nov 21 07:01:40 how can i get a python function in a bbclass to run before the do_install task? Nov 21 07:02:35 i have tried do_install[prefuncs] += "function_name " but i dont see any print outputs in the log.dorootfs log Nov 21 07:02:53 not having much luck with the mega manual or google... Nov 21 07:24:50 I have an issue that might not be Yocto-specific, but maybe someone recognizes it. I have a dhcp server (dhcp-server, dhcp-server-config) installed on my board (using Yocto Sumo). But when the server is started as a regular daemon it seems to hang badly. It does not respond to DHCP requests, and I can only kill it with kill -9. If I start the server manually though, with the -f flag, it works as expected. Nov 21 08:13:38 adelcast RP: I also was debugging an opkg crash from poky master after innocent looking opkg tar ball was in sstate cache. had to port valgrind to native and found out the libarchive error path problems. just ran out of time polishing and publishing the patch :( Nov 21 08:30:22 mcfrisk: any idea why we started generating these ipks all of a sudden? Nov 21 08:37:48 what is the recommended way to handle multiple distros? I have a local.conf which sets DISTRO to a specific distro in meta/recipes-core/images. to build another distro I would have to edit local.conf? Nov 21 08:38:25 rcrudo: you can just put it in through the call Nov 21 08:38:38 DISTRO="yourdistro" bitbake your-image Nov 21 08:38:59 (assuming that you kept the ?= assignment in local.conf= Nov 21 08:40:52 anyone know how to run a python function before do_install of a bitbake recipe ? Nov 21 08:44:28 New news from stackoverflow: What is the meaning of '__anonymous' function in a yocto/bitbake recipe? Nov 21 08:49:37 LetoThe2nd: I see. In that case I'd have to keep in local.conf only settings which applies for all distros Nov 21 08:49:49 rcrudo: yep Nov 21 09:14:56 kanavin: dude are you reading my mind Nov 21 09:15:10 kanavin: 11pm i scribbed down 'port p11-kit to meson' and 'update gettext' Nov 21 09:16:07 kanavin: unfortunately one of my patches i have here is moving autopoint to -minimal Nov 21 09:16:56 haha and i just prepped 'remove console-tools' Nov 21 09:19:24 I would like to store the revision of my custom layer used during the build in a file in the resulting file system. Is there any way to get that info into the i.e. image recipe? Nov 21 09:21:05 iceaway: look at the buildinfo, buildstats stuff. Nov 21 09:21:19 LetoThe2nd: thanks, will have a look! Nov 21 09:23:58 RP: I had an old sstate cache dir not wiped in months and been updating poky master and rebuilding a lot in the last 8 months. still have tree available for debugging but haven't had time to polish all patches, e.g. to enable valgrind for native when host version nolonger works etc.. Nov 21 09:25:51 qschulz: is there a way to get an output of the overridings for a recipe? Nov 21 09:26:53 GeneralStupid: bitbake-layers show-appends Nov 21 09:27:04 ah wait... are you talking bbappends or OVERRIDES? Nov 21 09:27:32 bbappends, see above. OVERRIDES, use bitbake -e and look for a line starting with OVERRIDES Nov 21 09:28:04 or read the log.do_fetch to see the order in which directories are "traversed"/checked Nov 21 09:50:11 quick question: is it possible to devtool deploy-target glibc? Nov 21 09:59:46 * LetoThe2nd thrusts mcfrisk and compares with a flying pig. Nov 21 10:05:33 rburton: mentioning you just because you answered to some glibc devtool stuff a while ago on the ML. Is it possible to devtool deploy-target glibc? Nov 21 10:05:45 dirname: error while loading shared libraries: libresolv.so.2: cannot open shared object file: No such file or directory Nov 21 10:06:21 that's what my people get when trying. Nov 21 10:09:48 FYI, glibc from thud with a patch implementing what's being discussed here: https://groups.google.com/forum/#!topic/generic-abi/bX460iggiKg Nov 21 10:10:52 qschulz: ok this lists my bbappend file... Amazing. But maybe i should have mentioned that its using my overridden SRC_URI ... But not my overriden LOCALVERSION for example Nov 21 10:14:14 qschulz: thats why i tried to use a different defconfig name... Its always using the default defconfig. Is it a good idea to override the "FILESEXTRAPATH" instead of prepending? Nov 21 10:15:16 GeneralStupid: no. Because only the directory pointed by your bbappend will be used for everything in that recipe, including everything in the original one Nov 21 10:15:27 and it'll break if there is a bbappend applied after yours Nov 21 10:15:37 or before Nov 21 10:16:09 what's the machine you're building for Nov 21 10:23:19 hello hello. Nov 21 10:25:34 rburton, thanks for sorting the lrzsz issue :) Nov 21 10:27:16 qschulz: imx6. its imx6ullevk. Nov 21 10:33:36 GeneralStupid: put your defconfig in a subdirectory named imx, that should make it work Nov 21 10:34:08 GeneralStupid: meta-foo/recipes-kernel/linux//imx Nov 21 10:35:04 GeneralStupid: but really, try to also document yourself on the OVERRIDES mechanism, it's pretty powerful and that's not the only time you'll encounter it or scratch your head about something that does not get applied Nov 21 10:35:21 qschulz: re your append topic idea: qou're right, this probably can use some explanations. Nov 21 10:38:18 GeneralStupid: let me know if that works. Anyhow, learning about OVERRIDES can't hurt :) Nov 21 10:41:45 GeneralStupid: also, FYI, you don't need to recompile every time, you can check with bitbake virtual/kernel -c menuconfig if the options of your defconfig are (un)selected. Nov 21 10:43:46 qschulz: never used devtool deploy :) Nov 21 10:44:32 kanavin: if you like poking at gettext you might be interested in my autopoint and gettext-tiny branches. neither actually work yet but WIP Nov 21 10:44:59 rburton: never did either :/ Do you know who I could ping about that? Nov 21 10:45:43 qschulz: devtool deploy-target only works for packages you actually have in your workspace, AFAIK Nov 21 10:45:54 qschulz: try bluelightning_ Nov 21 10:46:02 (if he hasn't gone to bed) Nov 21 10:46:25 GeneralStupid: why imx? => https://github.com/Freescale/meta-freescale/tree/thud/recipes-kernel/linux/linux-imx-4.9.123 the defconfig is specific to either imx or imx8 so you need to have your defconfig as specific or more specific. Nov 21 10:48:11 GeneralStupid: https://github.com/Freescale/meta-freescale/blob/thud/conf/machine/imx6ullevk.conf#L7 which is more specific than https://github.com/Freescale/meta-freescale/blob/thud/conf/machine/include/imx-base.inc#L327 and https://github.com/Freescale/meta-freescale/blob/thud/conf/machine/include/imx-base.inc#L73 (though I have never seen/used the EXTENDER stuff Nov 21 10:49:09 LetoThe2nd: devtool modify -x glibc, devtool build glibc, devtool deploy-target glibc is what they do (not the exact commands but that's their workflow) Nov 21 10:50:17 bluelightning_: maybe you'll be helpful :) Is it possible to devtool deploy-target glibc? what my people get when trying: dirname: error while loading shared libraries: libresolv.so.2: cannot open shared object file: No such file or directory; FYI, glibc from thud with a patch implementing what's being discussed here: https://groups.google.com/forum/#!topic/generic-abi/bX460iggiKg Nov 21 10:50:35 qschulz: *might* work. in my experience devtool work the better the more simple and canonical the recipes in question are. Nov 21 10:50:48 @all: or even better, how do you debug the glibc :) ? Nov 21 10:51:43 qschulz: Ahhh NXP Nov 21 10:52:02 qschulz: it should work... but glibc is quite a beast, I guess there are complications Nov 21 10:52:09 LetoThe2nd: my worry is that this deploy-target stuff depends on some glibc stuff on the target and that it breaks in the middle of the transfer. But 1) no experience in deploy-target, I don't even know how it does it, 2) no experience in glibc either :/ Nov 21 10:52:18 I certainly haven't tried it myself, maybe I can give it a shot tomorrow Nov 21 10:52:43 qschulz: it depends on a shell and ssh/scp being fully functional, AFAICS Nov 21 10:52:49 qschulz: deploy-target is basically tar over ssh Nov 21 10:53:04 bluelightning_: alright! Do you want me to ping you tomorrow at one point? Nov 21 10:53:09 GeneralStupid: TI is doint it as well ;) Nov 21 10:53:24 qschulz: sure Nov 21 10:55:27 bluelightning_: thanks for the explanation, now there's only 2) which isn't going to be easy to tackle :D I don't know how much glibc is involved/safe in that tar/ssh combination. I'll let you sleep tight and ping you tomorrow when I arrive at the office (2-3hours before now in your timezone) Nov 21 10:57:19 qschulz: ok, I should be around Nov 21 10:58:20 rburton, may I ask that you act on the AUH patches please :) Nov 21 10:58:30 (not sure if you're planning to anyway) Nov 21 11:00:56 rburton, what is autopoint for? Nov 21 11:01:14 kanavin: its basically gettextize Nov 21 11:01:30 we historically disable it, and do it ourselves in autotools.bbclass Nov 21 11:01:47 trying to remove that kludge Nov 21 11:01:59 rburton, tbh I have no particular interest in gettext other than getting it up to date Nov 21 11:02:19 shame :) Nov 21 11:11:35 * RP wonders what to prioritise. hashequiv debugging is eating time, meanwhile patches mount up :/ Nov 21 11:13:40 RP: if there's a show of hands, mine goes to hashequiv Nov 21 11:21:14 can't we have a show of metal? Nov 21 11:24:10 LetoThe2nd, https://cdn.iwastesomuchtime.com/February-16-2012-17-16-27-Selection009.jpg Nov 21 11:25:14 kanavin: exactly that. Nov 21 11:33:40 Im using Sumo in my current yocto build and I have a simple recipe that has a "require .inc" in the top. Nov 21 11:34:23 If I modify the .inc file, the package isn't rebuilt - am I missing something or is this how it is supposed to be? Nov 21 11:36:40 bojones: What are you modifying in the inc file? Bitbake dependencies are more granular than recipe or inc files Nov 21 11:37:35 LetoThe2nd: I quite like mercury as liquid metal at room temperature is quite cool... Nov 21 11:38:13 I removed a patch from the SRC_URI in the .inc file Nov 21 11:40:41 rburton, I have a patch that fixes lrzsz now Nov 21 11:40:49 bojones: I recommend dumping the env using `bitbake -e ` and looking at how SRC_URI is set, see if your change is picked up or if it's clear what's gone wrong Nov 21 11:45:03 New news from stackoverflow: Yocto: patch kernel module Makefile Nov 21 11:46:41 gah, found the "hashequiv" corruption issue which isn't hashequiv at all Nov 21 11:49:14 RP: hrhrhr Nov 21 11:50:28 RP: on a more serious note, can you (or somebody else) give me a short rundown on multiconfig? we're just getting started with it, and have quite a confusing time in understanding what can be set/left out/overwritten where Nov 21 11:52:37 FWWW the local.conf (or generally, the build) still needs to have a valid DISTRO/MACHINE setting combination. with MACHINE obviously being able to be overwritten later Nov 21 11:53:42 OK I ned to remove a couple of packages from an SDK, anyone know how? Nov 21 11:59:25 I just investigated some more... There was a SRC_URI[md5sum] and SRC_URI[shasum} defined in the .inc file. Nov 21 11:59:41 If I remove those, it seems to work Nov 21 11:59:55 Why would you have those defined for a SRC_URI? Nov 21 12:03:49 because SRC_URIs that fetch tarballs need to provide checksums Nov 21 12:03:50 LetoThe2nd: biggest confusion with multiconfig is that local.conf is one of the multiconfigs Nov 21 12:04:12 LetoThe2nd: then the others are added to it as other build options Nov 21 12:04:49 LetoThe2nd: you can set anything in a multiconfig however you need to be mindful about sharing TMPDIR, if the builds all use the same one, they need to be compatible (i.e. same DISTRO) Nov 21 12:05:03 RP: so if thats the confusion,whats the correct mindset? Nov 21 12:05:16 so changing MACHINE is fine, if you change DISTRO, set TMPDIR too Nov 21 12:05:26 hmmm Nov 21 12:05:32 LetoThe2nd: well, just realise that local.conf is your first multiconfig Nov 21 12:06:05 bitbake bash builds whatevr local.conf is set to. bitbake mc:A:bash multiconfig A's bash target Nov 21 12:06:29 having a TMPDIR for several DISTROs is actually bad? (didn't realize taht) Nov 21 12:06:56 LetoThe2nd: the same TMPDIR with different distros means it will uninstall and install other things Nov 21 12:07:09 assuming the distro configs are different Nov 21 12:07:19 and if they're not different, why do you have them? Nov 21 12:07:40 ah, /me confused TMPDIR and SSTATE one more time Nov 21 12:08:03 it can't uninstall and reinstall in a multiconfig build the same way as it normally would Nov 21 12:08:29 kay, good point. Nov 21 12:08:35 will try to keep that in mind Nov 21 12:09:05 loads of new ways to shoot yourself in the foot :) Nov 21 12:09:11 (or worse) Nov 21 12:09:25 yeah Nov 21 12:09:38 thats my fear if we start acutally using it in production. Nov 21 12:09:46 thx, will try and inverstigate. Nov 21 12:10:05 LetoThe2nd: its quite neat, just requires a little thought Nov 21 12:13:19 RP: additional question: best practise to set TMPDIR depending on mc? some override syntax? Nov 21 12:13:56 LetoThe2nd: set it in the multiconfig conf file? Nov 21 12:14:17 LetoThe2nd: I can't even remember if we did multiconfig overrides :/ Nov 21 12:15:58 RP: hm. din't like that as we want to carry the mc file with the layers. Nov 21 12:30:03 qschulz: so do i need to fork the kernel? Do i need to create a custom machine (i wanted to do this later) Nov 21 12:40:37 LetoThe2nd: I often use TMPDIR = "${TOPDIR}/tmp-XXX" Nov 21 12:41:45 adelcast: when you're around I have answers to some of our questions Nov 21 12:42:17 RP: would TMPDIR_distro1 = ... also work? Nov 21 12:42:27 LetoThe2nd: yes Nov 21 12:45:13 New news from stackoverflow: How can I call functions from an Anonymous Python Function in bb recipe files? Nov 21 12:54:17 RP: coworker seems to be happy Nov 21 13:00:24 I have DISTRO_FEATURES_remove="x11" in distro/conf, why would bitbake compile libx11-1_1.6.3-r0? Nov 21 13:00:55 kayterina: probably something depends on it. Nov 21 13:01:29 and no, DISTRO_FEATURES are no magic bullets. they're only as good as the recipes that either evaluate them, or not. Nov 21 13:02:14 PACKAGECONFIG_remove += "x11"? Nov 21 13:02:26 kayterina: DEPENDS (TM) Nov 21 13:02:50 if the package in question has that switch, then probably. Nov 21 13:02:57 but it really all dependes. Nov 21 13:06:18 qschulz: Hm i raised the version of my layer but sstill no success. This makes no sense to me Nov 21 13:20:21 why is KERNEL_DEFCONFIG := "my_def" not working? Nov 21 13:24:35 ok iam starting to figure it out. kernel-imx is not using kernel.bb Nov 21 13:30:55 ok ok so there is a do_preconfigure task. They are taking a hardlinked defconfig file :) Nov 21 13:30:58 Amazing. Nov 21 13:48:46 Hi, anybody here? Nov 21 13:50:31 GeneralStupid: what are you doing? Nov 21 13:51:13 I've a little question about 'gstreamer1.0-plugins-bad' in meta-oe and I'm not sure, if should send a patch to the mailing-list... Nov 21 13:52:10 you have a bbappend with your defconfig in it. It should be in a path with more priority than the original one. Here it seems to me it is "imx" that is used in meta-freescale. So you need AT LEAST to name your subdirectory "imx". Or it can be something more specific (on the right side of "imx" in OVERRIDES variable). Nov 21 13:52:19 the defconfig HAS to be named "defconfig" Nov 21 13:54:11 GeneralStupid: and it's KBUILD_DEFCONFIG, not KERNEL_DEFCONFIG AFAICT. This is only handled by recipes which are inheriting kernel-yocto bbclass which is not that common and is not the case of linux-imx IIRC Nov 21 13:54:30 dstriker: ask, don't ask to ask Nov 21 13:54:36 dstriker: also that recipe is in oe-core Nov 21 13:54:53 different BSPs have different customs. It's best to devshell into them and figure out how to override the configs. and lot of testing.. Nov 21 13:55:29 I build an image with zbar enabled in gstreamer1.0-plugins-bad, so right now I need to create a seperate bbappend-file, where I: Nov 21 13:56:25 add zbar to DEPENDS, remove '--disable-zbar' from EXTRA_OECONF, append '--enable-zbar' to EXTRA_OECONF Nov 21 13:56:25 qschulz: But that means NXP is doing some bad recipe style? Nov 21 13:56:31 GeneralStupid: why? Nov 21 13:56:55 GeneralStupid: I mean, what seems wrong to you (not judging, really asking) Nov 21 13:57:16 dstriker: right, so send a patch to add a pacakgeconfig for the zbar option so you can just toggle the packageconfig Nov 21 13:57:50 in the recipe of 'gstreamer1.0-plugins-bad' it says: "# these plugins have no corresponding library in OE-core or meta-openembedded:" and zbar is in there... so I was not sure, if I should send a patch or not... Nov 21 13:58:02 yes please do send a patch Nov 21 13:58:12 okay, thanks Nov 21 13:58:19 dstriker: https://www.yoctoproject.org/docs/current/mega-manual/mega-manual.html#var-PACKAGECONFIG Nov 21 13:58:31 please use that Nov 21 14:01:36 dstriker: the comment dates from the original commit which is in 2013. The zbar recipe was more recently added so no problem :) Nov 21 14:04:30 so, to remove a recipe, only through the dot diagram I can find the dependencies? Nov 21 14:06:02 kayterina: its the most reliably ways AFAIK. Nov 21 14:07:59 qschulz: i think it would be "common sense" to inherit from kernel.bbclass or something like that Nov 21 14:08:30 For me it feels bad to have this highly customazible yocto recipes but they are not working because NXP is doing their own stuff Nov 21 14:11:19 GeneralStupid: it inherits from kernel.bbclass, not kernel-yocto.bbclass. Nov 21 14:11:43 qschulz: Ah ok then it makes sense, a bit Nov 21 14:11:56 GeneralStupid: I've never used or seen kernel-yocto.bbclass. In any BSP I've used. Ever. Nov 21 14:12:09 Iam not able to add a task in a bbappend file? Nov 21 14:12:21 GeneralStupid: you are :) Nov 21 14:12:38 Or does ".bb" include ".bbclass" in the manual. Ok Nov 21 14:12:59 GeneralStupid: "inherit foo" will inherit foo.bbclass Nov 21 14:13:22 include and require need the file extension, but inherit assumes it's only bbclass that are inherited Nov 21 14:15:30 New news from stackoverflow: In Yocto, how do I specify a version restriction of package A to be the current version of package B? Nov 21 14:26:38 qschulz: ok now ${B} is not working :D Nov 21 14:28:49 GeneralStupid: I'll need a bit more than that :) Nov 21 14:37:04 RP: what's the policy for fixing bugs in old and unmaintained software in Yocto? I'm pretty sure we've found some bugs in libdbus-c++ which is still in meta-openembedded but is dead for the last ~3 years already. Nov 21 14:37:11 qschulz: they are copying defconfig to ${B}/.config . So now i just try to echo "" > ${B}/.config . That the build fails... But its working :D Nov 21 14:37:25 but my new task is in the list Nov 21 14:37:33 sorry for mentioning. Not really targetted to you but YP community as a whole. Nov 21 14:38:26 qschulz: well, if the recipe is still there I'd guess a patch would be taken Nov 21 14:38:36 In my mind, you try to fix upstream and send a patch to build systems while your patch gets reviewed/merged upstream. But here, it's never going to make it to upstream and it's slightly changing the behaviour Nov 21 14:39:15 GeneralStupid: What are you doing? I'm absolutely not following you. Why are you resetting .config? Nov 21 14:39:25 What are you trying to achieve? Nov 21 14:39:46 qschulz: upstream is definitely the preferred model, as you say its not always possible Nov 21 14:41:28 qschulz: i want to use a custom defconfig. Or is there a better way? Nov 21 14:41:34 RP: okay, we'll work on a patch and send something in the next few weeks and we can discuss from there Nov 21 14:41:47 GeneralStupid: I explained you twice already what to do. Nov 21 14:42:19 your bbappend only has a FILEEXTRAPATHS_prepend := "" in it. That should be enough Nov 21 14:42:54 hi Nov 21 14:43:17 your defconfig NAMED defconfig (exactly like this) in meta-foo/recipes-kernel/linux//imx/defconfig (defconfig here is the name of the file not a directory) Nov 21 14:43:41 your bbappend is meta-foo/recipes-kernel/linux/linux-imx_%.bbappend Nov 21 14:43:50 that should be enough for a custom defconfig. Nov 21 14:44:22 If that is not enough we have to work out the OVERRIDES thing and try to find out which file is taking precedence and why Nov 21 14:46:09 qschulz: FILE* * EXTRAPARH or FILE*S*EXTRAPATH Nov 21 14:46:19 I have the the FILES EXTRAPATH Nov 21 14:47:29 GeneralStupid: I can't never type that one correctly. Nov 21 14:47:33 what's the recommended way to have a `_append` only be applied, if a certain IMAGE feature is enabled? Nov 21 14:47:34 Ah ok Nov 21 14:47:43 GeneralStupid: https://www.yoctoproject.org/docs/2.6.2/mega-manual/mega-manual.html#var-FILESEXTRAPATHS Nov 21 14:47:58 i.e. `do_install_append() {..}` Nov 21 14:48:17 T_UNIX: IMAGE_FEATURE can be used only in image recipes Nov 21 14:48:33 you can use DISTRO_FEATURES and MACHINE_FEATURES in there though Nov 21 14:48:42 -.-' Nov 21 14:48:49 there/recipes Nov 21 14:49:00 T_UNIX: I've been there :) Nov 21 14:49:26 T_UNIX: what do you want to do exactly? Nov 21 14:50:01 hmm.. maybe I'm going wrong about it: In production I'm using systemd to set capabilities to allow an application to modify the date Nov 21 14:50:20 for development purposes, however, I'd like to allow users to modify date as they please. Nov 21 14:50:58 so there is `busybox.conf`. But it seems broken in combination with the barebox.{no,}suid split. Nov 21 14:54:42 s;barebox;busybox; Nov 21 14:57:10 qschulz: https://github.com/Freescale/meta-fsl-arm/blob/master/classes/fsl-kernel-localversion.bbclass This is pulled in and for me it looks like its always taking the default defconfig out of $WORKDIR Nov 21 15:00:56 so, to remove "qemu-native" I must remove every package that points to qemu-native. through IMAGE_INSTALL_remove? and if it still gets compiled, I missed something? Nov 21 15:03:58 kayterina: what makes you so sure you don't need qemu-native? Nov 21 15:04:15 kayterina: -native means its being built for the development host, not for your target. Nov 21 15:04:29 and it being pulled in means that something acutally needs it. Nov 21 15:04:38 ha ha.I just want to remove something Nov 21 15:05:09 but what if I don;t use qemu? Nov 21 15:05:42 thats why qemu-native is a particularly bad example. there are recipes that use it under the hodd to do things that you do not obviously see. Nov 21 15:06:06 so if you want to remove qemu, just becasue you want to remove qemu - then chances are that you are just being wrong. Nov 21 15:06:34 hm.... Nov 21 15:07:11 kayterina: basically all things that start with "I just want to" are wrong with high probability. Nov 21 15:09:02 iik. ok, x11 and libxau xproto libx11, I don't have graphics,so I don't need them. Nov 21 15:10:18 RP, I have a bit of spare cycles if you need help with something Nov 21 15:15:46 kayterina: use a distro that disables x11, then, or your own (see DISTRO_FEATURES) Nov 21 15:16:01 qschulz: but there are many places that are like `PACKAGECONFIG = "bb.utils.contains("${IMAGE_FEATURES}", 'foo', 'add_x', '')}"` Nov 21 15:16:08 obviously not exactly like that Nov 21 15:16:34 I was just wondering whether PACKAGECONFIG would recognize that its value depends on `IMAGE_FEATURES` Nov 21 15:17:12 lxdm for example: `DISTRO_TYPE ?= "${@bb.utils.contains("IMAGE_FEATURES", "debug-tweaks", "debug", "",d)}"` Nov 21 15:17:28 kanavin: thanks, I just got to the bottom of the thing which has been really bothering me (the empty ipks). For better or worse most of the issues I'm looking at are hard to reproduce autobuilder failures :/ Nov 21 15:19:20 GeneralStupid: sorry was afk. Yes it takes the defconfig out of WORKDIR. But the defconfig that is put in WORKDIR depends on FILESEXTRAPATHS and OVERRIDES. It should be fine, you're debugging the wrong thing I think Nov 21 15:19:26 kergoth: we've gone through this with leto: it all depends. DISTRO_FEATURES_REMOVE+="x11" didn't do it for me. perhaps because I am on older yocto and vendor's layer based on meta-freescale Nov 21 15:19:58 so removing them by hand seems more certain Nov 21 15:20:10 T_UNIX: where? Nov 21 15:21:15 T_UNIX: if I remember correctly what LetoThe2nd told me. IMAGE_FEATURES can't be used outside of image recipes. And if I remember correctly... from experience it cannot. Nov 21 15:21:38 qschulz: not entirely correct. Nov 21 15:21:49 it depends on where they have been set. Nov 21 15:21:58 qschulz: ok good to know -.- Nov 21 15:22:06 LetoThe2nd: all ears Nov 21 15:22:08 it the usual: "conf things are global, recipe things are local" Nov 21 15:22:50 so if you happen to set them in local.conf, you can *technicall* trigger on them everywhere. and if you set them in your image recipe, you cannot. Nov 21 15:23:15 what does this tell us? don't use the first technique, as it will confuse everybody including your future self. Nov 21 15:23:25 LetoThe2nd: ah yes, I always forgot this conf/local.conf thingy. thanks! Nov 21 15:23:49 RP, I'll keep doing long-delayed recipe updates then Nov 21 15:24:06 shame that the lrzsz thing blew up like this Nov 21 15:24:23 that seems a bit odd. Because you'd obviously create an developer image. That's a local recipe. Nov 21 15:24:50 that is not odd at all, its just the evalutaion scheme. Nov 21 15:24:54 yet you'd need the corresponding IMAGE_FEATURE to be set in `local.conf` or in the distro conf? Nov 21 15:25:07 and IMAGE_FEATURES being a variable just like all others, no special Nov 21 15:25:12 kanavin: I'm just drowning on these hard to reproduce issues. I know its even harder for others to find the time to dive in and help though :( Nov 21 15:25:25 kanavin: the lrzsz thing I think had calmed down now Nov 21 15:25:33 T_UNIX: depending on what exactly you need to do, you could always do it but put that feature in a separate package. Then create a new image recipe with that specific package in it Nov 21 15:25:52 always do it = always have your do_install_append Nov 21 15:27:10 kayterina: removing them by hand is unlkikely to work at all unless you find each and every recipe that depends on them, which will be many. i'm assuming you mean DISTRO_FEATURES_remove, since the variable you mentioned doesn't exist, though? Nov 21 15:27:27 in this particular case it seems http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/recipes-core/busybox/busybox.inc#n16 breaks expected behavior by busybox. Nov 21 15:27:55 yes... Nov 21 15:28:01 RP, here's an idea: can we somehow give more people some kind of control over the autobuilder? If I or other people have no rights there, it follows that we're clueless in the face of those failures. Nov 21 15:28:56 kanavin: you mean ssh access? Nov 21 15:29:02 i.e. busybox.conf is basically ignroed, if your applet is within the `suid` binary. If you put it into the `.nosuid` split, it will never be able to gain suid. Nov 21 15:29:25 kanavin: its available to anyone who has need, just takes time to setup Nov 21 15:29:41 T_UNIX: and usually when you think something is a good idea and only a handful of recipes are doing it in upstream layers (and some maintained by YP people), it's usually not a good tale :) Nov 21 15:29:55 yeah, sure. Nov 21 15:30:27 anyone know how to run a python function from a bbclass before do_install of a bitbake recipe ? Nov 21 15:30:54 but, as LetoThe2nd explained, this particular point is not reasonable. It's just owed to the evaluation priorities/order. Nov 21 15:30:55 do_install[prefuncs] += "your_function" Nov 21 15:31:13 then define python your_function() { } as usual Nov 21 15:32:00 mm, i did exactly that but i dont see any print output in log.do_rootfs Nov 21 15:32:20 ive tried printing with just print() and bblog Nov 21 15:33:07 https://www.yoctoproject.org/docs/latest/dev-manual/dev-manual.html#getting-source-files-and-suppressing-the-build : The fetch command there appears to be incorrect, the one that worked for me is here: https://www.yoctoproject.org/docs/latest/ref-manual/ref-manual.html#migration-2.5-bitbake-changes Nov 21 15:33:48 T_UNIX: I'm sorry that's going too far in busybox behavior (or maybe you can explain a bit more beginner-friendly for me from the point of view of Yocto). Maybe depending on what you're going to work on, you can contribute that back to the appropriate layers :) good luck Nov 21 15:34:43 T_UNIX: no, its just not the intended use case that you are describing for IMAGE_FEATURES. the documentation pretty much clearly explains where it shall be set, what it means, and how it shall be extended if needed. https://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html#usingpoky-extend-customimage-imagefeatures Nov 21 15:37:21 T_UNIX: if "developer image" means to you "add just this couple of packages", then you don't need them anyways. then you just extend IMAGE_INSTALL. but if "developer image" means for you "this and this and this have to beuilt differently, and this and that." thenyou are effectively changing the ABI of the image. and that is *EXACTLY* what a DISTRO is about. Nov 21 15:38:15 T_UNIX: feel free to argue about badly picked names (we have quite a few of those and used to the complaints), but the mindset and architectural underpinnings are *VERY* clear here. Nov 21 15:45:59 LetoThe2nd: hm... how would you classify the passwordless root access? Nov 21 15:47:27 or maybe let me rephrase: how would you classify changing the suid behavior of busybox? Nov 21 15:48:04 T_UNIX: i would classify that being part of an image ABI. Nov 21 15:48:16 and hence to be affected by the distribution. Nov 21 15:49:55 of course, other opinions are valid too. Nov 21 15:50:24 RP: I just saw your opkg-utils patch on the ml, so without pipeline opkg-build was failing silently.... Nov 21 15:50:52 following that logic, wouldn't allowing "root no passwort" be an ABI break too? Nov 21 15:51:35 i.e. if the image was a blackbox you're interacting with on a binary level. Nov 21 15:51:50 it would, you are absolutely correct. Nov 21 15:52:14 yet it's a image feature? Nov 21 15:52:17 mind, i explicitly said that the names are far from being perfect. Nov 21 15:53:03 but OTOH, who would want a variable that goes like PREDEFINED_BUNCH_OF_TUNING_SCREWS_THAT_MAGICALLY_AFFECTS_THE_IMAGE_IF_USED_AS_INTENTED? Nov 21 15:53:28 and hence, we're stuck with "IMAGE_FEATURES". Nov 21 15:53:54 I guess I just need to let that sink for a moment to get the described concepts more clearly/straight in my head :) Nov 21 15:53:54 Hi #yocto! I'm facing the problem that own written task gets the error message "basehash value changed from to The metadata is not deterministic and this needs to be fixed." What could be the problem? Nov 21 15:54:29 silviof: in the simplest case your task somewhere expands date or such. Nov 21 15:54:30 silviof: most likely something with DATE or DATETIME in it Nov 21 15:54:38 * LetoThe2nd hi5es qschulz Nov 21 15:54:40 LetoThe2nd: shoot. too slow. Nov 21 15:54:50 LetoThe2nd: so thanks for explaining the concepts behind and especially for pointing out that names *might* sometimes be a bit odd :) Nov 21 15:54:52 AH Nov 21 15:55:35 Ah - oh thanks. will ook for this LetoThe2nd anf qschulz Nov 21 15:56:56 silviof: a task is parsed multiple times I guess and if it changes between the times, it complains with the same message. What is the most straightforward change between the two parsings (parses? damn English is hard at that time of the day) is the current date Nov 21 15:56:57 LetoThe2nd: I guess we're both currently like https://i.imgflip.com/274faw.jpg :-D Nov 21 15:58:15 I have included $DATETIME, but after removing I have still this message. Can I have a list of variables which get changed many times at pasring time? Nov 21 15:58:22 qschulz: Nov 21 15:58:56 mcfrisk: were you able to get to the bottom of why opkg was crashing? Nov 21 16:02:12 silviof: which yocto version? Nov 21 16:03:06 qschulz: 2.3.4 Nov 21 16:04:50 qschulz: Ok, i watched the .config file and your right. Its my configuration. But when i boot the Image, it displays "Linux version 4.9.123-imx+g6a71cbc08975 (oe-user@oe-host) (gcc version 8.2.0 (GCC) ) #1 SMP PREEMPT Wed Nov 20 14:47:52 UTC 2019" but i built today Nov 21 16:05:59 qschulz: maybe ... I forgot the "gunzip" step Nov 21 16:06:11 silviof: bitbake -S none yourrecipe; bitbake -S printdiff yourrecipe; if it's changing between parse runs, that would show it, since the first writes the data and the second compares to it Nov 21 16:07:28 qschulz: Ahh thanks. Nov 21 16:07:28 It seems that I can also ignore this stuff when I set "BB_HASH_IGNORE_MISMATCH". Because I want a relation between imagenames (with DATETIME) I go this way. Thnaks for your help. Nov 21 16:07:54 kergoth: whaaaaaaaaat. And I here about it just now /o\? Thanks!!!! Nov 21 16:08:05 qschulz: thanks a lot Nov 21 16:09:01 GeneralStupid: my pleasure. Nov 21 16:10:44 silviof: be careful with your use of DATETIME. The mismatch is there for a reason, so if your task does not get retriggered because of a changed DATETIME but you're still using it to do some things... might get the wrong datetime I think Nov 21 16:10:51 silviof: and you should thank kergoth as well :) Nov 21 16:11:24 yeah, it's a fair point, excluding a varibale from the checksum will mean changes to it don't re-run the tasks.. sometimes that's just what you want, other times not so much Nov 21 16:11:34 adelcast: nice thing abot empty payloads, i didn't know opkg didn't support meta packages yet Nov 21 16:12:10 kergoth: sorry think the answer came from qschuld. thanks a lot. 🙂 Nov 21 16:12:14 Piraty: I am a bit mystified myself, I thought it already did Nov 21 16:13:08 haven't had a chance to poke around, but I am almost certain that there are already supported virtual packages that installed correctly Nov 21 16:13:49 actually maybe virtual packages just don't have a payload, mmm Nov 21 16:15:28 ehm, virtual packages is a differenct concept than meta packages (for me at least) Nov 21 16:15:53 meta meaning empty, just to provide sth like "base-system" that depends on everyhing relevant Nov 21 16:16:22 virtual meaning sth like "java" which can be provided by different packages which all fulfill the virtual package requirement Nov 21 16:16:36 yes, sorry, I meant meta packages Nov 21 16:17:55 ok, I just looked inside packagegroup-core-buildessential Nov 21 16:18:34 which is a meta package....it does have a data.tar.xz which is *almost* empty Nov 21 16:19:54 just opening the file with vim I get that it has ./ as content Nov 21 16:20:55 on a truly empty payload, like in the one RP found, there was no content.....now I am wondering if all the created meta packages are *almost* empty and maybe they shouldn't...mmmmm Nov 21 16:22:23 adelcast: I suspect they contain an entry for "." Nov 21 16:22:30 moto-timo: https://www.youtube.com/watch?v=VpK27pI64jQ Nov 21 16:22:49 ^^ Sweeten your yocto build times with icecream Nov 21 16:23:01 icecream has some drawbacks Nov 21 16:23:05 thank you for saving me finding it Nov 21 16:23:26 adelcast: forwarded you my "fix" for opkg-build Nov 21 16:23:32 Piraty: It's not perfect, but it saves us a whole lot of time Nov 21 16:23:43 adelcast: curious what you make of it and how you think we should proceed Nov 21 16:23:59 RP: the odd thing is that if I run unxz data.tar.xz on one of the metapackages, I get a newly created data.tar file, mmm Nov 21 16:24:12 JPEW: default icecream doesn't allow VPN interfaces ( i think there is PR on their github for that though) which makes it highly dependant on secure infra Nov 21 16:24:28 JPEW: in particular, some of the things that have a lot of compile time, like WebKit, must be better with distributed compile :) Nov 21 16:24:37 Oh, ya. You'd have to have a *really* fast VPN to make it worth while anyway Nov 21 16:25:13 moto-timo: Indeed it does. I didn't cover webkit in my presentation, but it's a pretty similar setup to qemu, which was a huge improvement Nov 21 16:25:20 the beneficial use case is with co-located massive numbers of nodes Nov 21 16:25:29 adelcast: just checked and they do indeed have a "." entry Nov 21 16:26:17 moto-timo: Also, this the container setup we use internally for all our builds: https://github.com/garmin/pyrex Nov 21 16:26:24 instead of one aging dual Xeon box with 40 "cores", you could have 1000s. Nov 21 16:27:07 moto-timo: Ya. As long as you have the bandwidth to back it up :) Nov 21 16:27:16 RP: ok, then it might just be harmless....is just that the "." entry hide the empty payload bug for a while Nov 21 16:27:27 adelcast: RP: howto even create truly empty tar archives? tar -caf . on an empty one still gives ./ as content Nov 21 16:27:28 JPEW: thank you Nov 21 16:27:52 moto-timo: Pyrex also supports podman, so you don't need root privledges to run it :) Nov 21 16:28:01 I've been thinking a lot about containerized builds specifically for ancient distros Nov 21 16:28:10 JPEW: BONUS! Nov 21 16:28:16 RP: by the way your patch looks good and makes sense, I will pull it in Nov 21 16:28:34 whenever i hear pyrex i think of the glass lid of my frying pan. Nov 21 16:28:39 seriously. Nov 21 16:28:58 I think of my former life doing a lot more chemistry and beakers and such Nov 21 16:29:00 moto-timo: I don't have it in yet, but I have been working on an image that can run oe-selftest also. Nov 21 16:29:02 adelcast: thanks! :) Nov 21 16:29:25 JPEW: maybe we can collaborate on that, or at least I can be a guineau pig Nov 21 16:29:40 Piraty: I believe this will work tar cvf empty.tar --files-from /dev/null Nov 21 16:29:49 ah Nov 21 16:30:03 moto-timo: Ya, that would be great! kergoth has already been trying it out also (and found and fixed a number of bugs) Nov 21 16:30:10 adelcast: we could probably save some space if we lose the "." entry... Nov 21 16:30:29 adelcast: indeed, now vim pukes at me Nov 21 16:30:57 (opening that empty tar) Nov 21 16:31:12 adelcast: I wasn't keen on the bash dependency but for opkg-build it probably doesn't matter Nov 21 16:31:31 JPEW: not surprised kergoth would be interested :) Nov 21 16:31:39 moto-timo: The hard part with oe-selftest is qemu (as you pointed out). However, I think the solution to that is actually just to run qemu outside the container. Due to the magic of uninative, it just works AFAICT Nov 21 16:32:14 now i'm hungry. Nov 21 16:32:24 JPEW: I had the same instinct, but hadn't thought through the implementation details yet Nov 21 16:32:58 JPEW: nice, oe-selftest support would be helpful Nov 21 16:33:11 * kergoth is using pyrex most days now, not all, but most Nov 21 16:33:45 kergoth: I meant to ask, are you using a custom built image, or pulling the prebuilt ones? Nov 21 16:33:49 i just don't trust the sanity of my hosts anymore, regardless of distro. there's a reason i use asdf or pyenv to install global pythons in the homedir rather than using the host python.. and that's true for every langauge-specific setup Nov 21 16:34:07 kergoth: I second and third that sentiment. Nov 21 16:34:32 I use pipenv for everything. everytime. Nov 21 16:34:50 even use homebrew on linux for a newer neovim on some of them :) Nov 21 16:34:51 the overhead is trivial Nov 21 16:36:13 oh yeah, pipenv is handy. i tried poetry, i think it's nicer in theory than reality though. completely ditching setup.py means pip install . doesn't work, stuck with their tooling at the moment, and doing a full version lockdown of deps recursively can cause problems if one of your deps depends on a different version of one of its deps depending on the python verison you're using, end up having to Nov 21 16:36:15 re-update/lock when you change python versions.. course pipenv probably hits that one too.. Nov 21 16:39:18 JPEW: i've been using a locally built stock pyrex image just to pick up those fixes, but will probably switch back to prebuilt since everything got merged and you updated the release, just haven't gotten around to it Nov 21 16:39:34 might need to play with a customized dockerfile for mentor / MEL needs eventually, but for now this is good Nov 21 16:39:37 moto-timo, when will the meta-py2 layer git published? Nov 21 16:40:48 RP: mmm, you are right, I haven't realized pipefail is a bashism Nov 21 16:42:49 adelcast: its why I changed the first line sh -> bash Nov 21 16:43:19 RP: hehe, I missed that part...I guess I need more coffee Nov 21 16:43:32 armpit: I have a script using 'git filter-branch' that is mostly there, but 'git filter-repo' is now the favored approach. Essentially, I want to inject the "From meta-openembeddecd commit: foo" into thee commit messages from meta-pythonn git history Nov 21 16:44:13 armpit: my priorities have changed very recently and I also have Thanksgiving to work on meta-python2, since it is mostly owntime. Nov 21 16:44:24 RP: targets that use lighterweight shells are unlikely to run opkg-build, I think? Nov 21 16:44:56 if anybody uses 'git filter-repo' or 'git filter-branch' and knows how to do what I am suggesting above... I'm all ears Nov 21 16:44:57 adelcast: that was my thinking, installing bash when you're building ipks doesn't sound too onerous Nov 21 16:45:11 my sed foo is failing me for some dumb reason Nov 21 16:45:22 I'll send what I have to the ML Nov 21 16:45:30 moto-timo, its more in the light of having it available for folks to participate in Nov 21 16:45:42 not the its perfect Nov 21 16:45:54 armpit: yes, but I strongly desire to keep the former history in the new repo. Nov 21 16:46:25 armpit: and I am 80% there. Nov 21 16:50:48 RP: regarding the extra "." entry, I think that should be an easy fix to opkg-build, I'll build a patch, now that opkg works with empty archives Nov 21 16:51:33 adelcast: ok, sounds good :) Nov 21 17:00:21 RP: regarding: http://lists.openembedded.org/pipermail/openembedded-core/2019-November/289566.html It's very possible that might break something in oe-selftest Nov 21 17:08:43 JPEW: what kind of thing may break? Nov 21 17:23:41 RP: I don't have a specific and I haven't seen anything in my testing, just a heads up. Nov 21 17:24:37 Otherwise, I think I have core-image-sato and core-image-full-cmdline reproducible Nov 21 17:25:01 At least, with rbutons pod2man patches Nov 21 17:38:20 perl won't be reproducbile with my patches Nov 21 17:52:05 rburton: we had some questions about those and the status in the call earlier Nov 21 17:53:01 RP: I am seeing nodejs-native builds failing on AB due to missing libatomic.so on host this is new I wonder what changed in master-next Nov 21 17:54:02 RP: i thought i put all my thoughts into the relevant bugs Nov 21 17:54:04 maye not Nov 21 18:00:42 might be this patch https://git.openembedded.org/meta-openembedded/tree/meta-oe/recipes-devtools/nodejs/nodejs/0005-Link-atomic-library.patch Nov 21 18:00:52 but this existed before as well so why now Nov 21 18:01:03 see https://autobuilder.yoctoproject.org/typhoon/#/builders/88/builds/122 Nov 21 18:01:45 oh centos-7, it has very old gcc ( 4.8 IIRC ) and does not install libatomic by default hmmm Nov 21 18:02:57 RP: doing a build in a container with no py2 Nov 21 18:03:29 but blindly asking for libatomic is not good Nov 21 18:03:56 we should ensure that gcc intrinsics do not have atomics before falling back to libatomic Nov 21 18:05:51 hmm, did the glibc-locale host-user-contaminated issue ever get resolved? Nov 21 18:05:56 rburton: thanks. I figured if we could work out the current status we could then divide and conquer Nov 21 18:06:01 kergoth: yes! Nov 21 18:06:14 kergoth: its a makefile bug iirc Nov 21 18:06:27 ah, awesome Nov 21 18:06:28 kergoth: i haven't seen it since the race in the makefile was sorted Nov 21 18:06:38 ok people Nov 21 18:06:42 * kergoth removes chown hack from one of his layers Nov 21 18:06:44 bets on first recipe to fail without host python2? Nov 21 18:06:59 kergoth: http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=8102c55bc1851233d3c5632e47e0adfddc4b23f8 Nov 21 18:08:08 kergoth: not quite makefile but kind of http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=fb20d734612d403b3e41a1a781714fd5f63f7e35 :) Nov 21 18:08:22 thanks Nov 21 18:08:27 rburton: xcb ? Nov 21 18:08:35 good guess Nov 21 18:08:50 inherit autotools pkgconfig python3native Nov 21 18:08:52 but maybe not Nov 21 18:09:05 i can smell dinner, i'll return in an hour and let you know :) Nov 21 18:28:46 kergoth: we fixed it by https://git.openembedded.org/openembedded-core/commit/?id=57e2e498ffb675d274aa95b10c14bd81742d2761 not particularly pretty fix but gets jobs done Nov 21 18:42:54 huh its still building Nov 21 18:43:55 damn i forgot how much i love the topre switches in this happy hacking keyboard. kind of makes me sad given i can't use all my nice cherry-compatible keycaps with it.. Nov 21 18:46:09 Currently 13 running tasks (6822 of 7186) 94% |###################################### | that far through a sato build without any py2 on the host Nov 21 18:46:28 any bets on what task number it fails at? or, will it build? Nov 21 18:47:20 Price is Right rules? I'll guess 6822 :) Nov 21 18:51:16 too low! Nov 21 18:51:27 ~5500, tried to build python-native Nov 21 18:51:29 which needs host py Nov 21 18:51:44 huh. python-native needs host python? interesting Nov 21 18:51:50 hillariously it tried to use py3 on the host but the source isn't py3 friendly Nov 21 18:51:56 hah Nov 21 18:51:58 yeah it bootstraps a parser Nov 21 18:58:58 its python, rightly named Nov 21 18:59:22 maybe it should be now called burmese python Nov 21 19:15:15 adelcast: I am using the latest patch you posted to ml and I am seeing opkg is taking like 10+ mins in do_rootfs its largish image but I think something has slowed down Nov 21 19:19:59 Currently 20 running tasks (9467 of 12548) 75% |############################## | and only python-native failed so far! Nov 21 19:23:48 rburton: Too bad. No new set of encyclopedias for me :(\ Nov 21 19:34:52 https://autobuilder.yoctoproject.org/typhoon/#/builders/91 - that graph looks periodic?! :/ Nov 21 19:39:12 RP: build times? Nov 21 19:40:13 tgamblin: yes, of our performance tests Nov 21 19:40:40 those are isolated to run in a contained way so should be consistent Nov 21 19:40:59 It certainly does look periodic Nov 21 19:45:21 tgamblin: and it shouldn't be :/ Nov 21 19:45:38 * RP really can't afford to look into that right now Nov 21 19:46:38 New news from stackoverflow: My other imx7d pico android things start kit died, again Nov 21 20:11:35 rburton: nice! :) Nov 21 20:11:56 RP: very periodic. what day is the spike on i wonder Nov 21 20:12:08 rburton: the ubuntu perf doesn't do that Nov 21 20:12:24 rburton: that is a good question. Its as if there is a cron job Nov 21 20:12:40 RP: i was thinking a weekly purge job causing IO Nov 21 20:13:03 rburton: or a man page indexer or similar Nov 21 20:15:55 that shouldn't take so long, but yes something like that Nov 21 20:25:31 rburton: probably tracker :) Nov 21 20:26:37 hmm, had a great idea to do with the autobuilder, went to file the bug, got distracted and now can't remember what it was Nov 21 20:30:30 * RP did remember and filed it Nov 21 21:16:22 RP: looks like you sent last batch of oe-core patches to bitbake-devel ML Nov 21 21:17:11 RP: sanlock is showing sstate errors https://autobuilder.yoctoproject.org/typhoon/#/builders/88/builds/123 I cant co-relate it to anything in recipe Nov 21 21:17:38 Exception: KeyError: 'getpwuid(): uid not found: 6000' Nov 21 21:20:17 JPEW: you may want to look at that backtrace, its from your code :) Nov 21 21:20:38 khem: I'm guessing this recipe generates something with build UID leakage into its target Nov 21 21:20:58 khem: pseudo is quite correctly saying uid 6000 doesn't exist on the target Nov 21 21:21:08 6000 is the UID of pokybuild on that worker iirc Nov 21 21:21:26 so its host contamination into the target package Nov 21 21:21:33 the backtrace could be better Nov 21 21:21:53 JaMa: gah, sorry :( (thanks) Nov 21 21:23:19 khem: the reason its showing up is we enabled hash equivalence but I suspect a bug in the sanlock recipe Nov 21 21:23:24 RP: I know it needs sanlock user/group which I added but it still fails Nov 21 21:23:44 RP:yes thats what I am interested in fixing Nov 21 21:26:10 khem: let me see if can build it locally to debug Nov 21 21:28:03 RP: cp -a libsanlock.so /mnt/b/yoe/build/tmp/work/core2-32-yoe-linux-musl/sanlock/3.8.0-r0/image//usr/lib Nov 21 21:28:05 cp -a libsanlock_client.so /mnt/b/yoe/build/tmp/work/core2-32-yoe-linux-musl/sanlock/3.8.0-r0/image//usr/lib Nov 21 21:28:07 cp -a libsanlock.so.1 /mnt/b/yoe/build/tmp/work/core2-32-yoe-linux-musl/sanlock/3.8.0-r0/image//usr/lib Nov 21 21:28:09 cp -a libsanlock_client.so.1 /mnt/b/yoe/build/tmp/work/core2-32-yoe-linux-musl/sanlock/3.8.0-r0/image//usr/lib Nov 21 21:28:11 will that do it Nov 21 21:28:21 khem: yes Nov 21 21:28:30 khem: they will be owned by the build user Nov 21 21:28:38 right -a Nov 21 21:29:08 khem: do a chown root.root afterwards Nov 21 21:30:00 its in its makefiles so maybe replace cp -a with install -D 0755 ? Nov 21 21:30:10 khem: right Nov 21 21:30:29 khem: or a blanket do_install_append chown Nov 21 21:30:33 khem: depends on context really Nov 21 21:40:45 maybe fixing makefile is better Nov 21 21:45:47 RP: Hmm, that is annoying. Is that something the QA check would have caught, but couldn't because outhash calc ran first? Nov 21 21:49:56 JPEW: probably, yes Nov 21 21:52:49 RP: Would it be better to bail out without reporting a hash in that case (maybe just issue a warning)? Nov 21 21:55:42 JPEW: probably, we should check the QA tests pick it up though Nov 21 21:57:40 OH GOD why does llvm take over 10 minutes to package Nov 21 22:00:07 ha Nov 21 22:00:24 right package finished in 12 minutes Nov 21 22:00:26 rburton: bitbake -P ;-) Nov 21 22:00:36 means you'd have to rerun it though Nov 21 22:00:46 i know why really, its the fact that its is HUUGE Nov 21 22:01:26 ah, debug sources Nov 21 22:03:49 khem: +do_install_append () { Nov 21 22:03:49 + chown root.root ${D} -R Nov 21 22:03:54 khem: that fixed it locally FWIW Nov 21 22:06:04 RP: cool. I am testing this https://git.openembedded.org/meta-openembedded-contrib/commit/?h=yoe/mut&id=f5322c407c21aed29857cce4ab3ca86aa82cb061 Nov 21 22:07:31 khem: ok Nov 21 22:19:30 hm py2 really does appear to need py2 to build Nov 21 22:19:56 hmm. Anyone else doing any active build tests on Fedora 31? Nov 21 22:23:21 rburton: that seems odd, there must be a way to bootstrap it..especially since cpython is written in C mostly.. Nov 21 22:23:22 tgamblin: I'm building on Fedora 31 Nov 21 22:25:01 JPEW: done an update recently? I'm running into "corrupt GNU build attribute note: wrong note type: bad value" when building poky. Wasn't happening prior to the update, but maybe it's something else Nov 21 22:25:15 kergoth: for native you might be able to get away with not regenerating, but we might be doing something to force the regen Nov 21 22:25:29 tgamblin: No, I think I'm a bit behind Nov 21 22:26:12 tgamblin: Ya, I have 333 package updates pending Nov 21 22:32:12 JPEW: K. I'll keep pok(y)ing around Nov 21 22:32:32 It seems that someone has asked about the issue on the Fedora subreddit under a different context Nov 21 22:32:51 Well, maybe I'll put off updating a little longer :) Nov 21 22:33:19 Not a bad idea! Nov 21 22:36:32 JPEW, khem: Worryingly if I bypass that keyerror, there is no QA warning :( Nov 21 22:36:44 Thats not good Nov 21 22:37:36 no Nov 21 22:37:49 do i investigate or file a bug I wonder Nov 21 22:38:28 You can file a bug to make outhash calc fail more gracefully and assign it to me at least Nov 21 22:38:40 Unless you already have a sufficent patch Nov 21 22:39:16 JPEW: not yet Nov 21 22:40:21 NOTE: Tasks Summary: Attempted 12502 tasks of which 12340 didn't need to be rerun and 1 failed. Nov 21 22:40:26 well strike me down with a feature Nov 21 22:40:33 erm, feather Nov 21 22:40:53 rburton: wow! Nov 21 22:40:56 oe-core world minus python and u-boot builds without py2 on the host Nov 21 22:41:16 i was expecting some bits to call /usr/bin/python directly, but apparently not Nov 21 22:46:43 rburton: yes, quite surprising Nov 21 22:47:32 JPEW, khem: do_package_qa sees uid as 0, the sstatesig code sees uid as 1000 Nov 21 22:48:19 rburton: nice Nov 21 22:55:28 JPEW, khem: the files in package/ are owned by build UID, when they get to package-split they've been "fixed" to root/root, probably by the packaging fixup code Nov 21 22:56:08 so the end packages are correct but the data written into the sstate object includes package/ Nov 21 22:56:40 hence why the QA doesn't see it but hashequiv does Nov 21 22:56:54 files get stripped so the hardlink doesn't help Nov 21 23:03:39 If anyone has some spare cycles, the remaining failures on https://autobuilder.yoctoproject.org/typhoon/#/builders/86/builds/499 looks reproducible (postinst failing with reproducible builds) Nov 21 23:03:49 so close... Nov 21 23:13:19 * RP -> sleep Nov 21 23:17:18 New news from stackoverflow: Toolchain build using yocto Nov 22 00:06:23 Mailing lists are offline for the move. Nov 22 01:13:58 halstead: so mails i sent to the list in the last hour are lost in the ether? Nov 22 01:14:06 forgot about the migration Nov 22 01:15:29 rburton, If all goes according to plan they will eventually show up. They may be rejected if I messed up a configuration. Nov 22 01:18:50 Looks like I was one second too late. Nov 22 01:45:48 heh Nov 22 01:45:52 one second! **** ENDING LOGGING AT Fri Nov 22 02:59:57 2019