**** BEGIN LOGGING AT Fri Dec 21 03:00:02 2018 Dec 21 11:20:36 hi Dec 21 11:21:59 guys, I have a weird issue on 2.5.1, I have a .bbappend file that modifies a postinst hook i.e. pkg_postinst_ontarget_${PN}_append()... When I do a clean build the changes from the postinst are there, but if I later do any further changes to my postinst function and build again - the changes are not picked up Dec 21 11:22:54 I did some searching but I only found references to SIGGEN_EXCLUDERECIPES_ABISAFE and this package is not listed there if you run bitbake -e Dec 21 11:23:03 its the msmtp recipe btw Dec 21 11:23:26 any clues why this is happening? is there a known bug? or did I miss something? Dec 21 11:25:44 Hello. I am trying to add some CI to a layer. And I would like to know the recipes on a layer. Is there any way to: "bitbake-layers show-recipes" but just for a layer? Dec 21 11:39:47 I'm really puzzled, this is nicely reproducible on my system, not even sure how to debug it? Dec 21 11:40:54 if I modify do_install_append() it gets rebuild as it should Dec 21 14:41:12 Jin^eLD: sounds like bitbake can't see the variable being used for some reason, happens occasionally. add it explictly to vardeps Dec 21 14:41:43 ribalda: there's a bug for that, because yes it would be useful :) Dec 21 14:42:02 ribalda: i've got a bit of awk to filter the show-recipes output as a work around Dec 21 14:42:10 rburton: well I do not use a variable in the postinst hook... so what should I be adding? the hook itself? Dec 21 14:42:23 let me paste the recipe Dec 21 14:42:26 weird Dec 21 14:42:38 anyway i'm outta here for christmas now Dec 21 14:42:40 byeeee Dec 21 14:43:09 https://git.digitalstrom.org/dss-oe/dss-oe/blob/master/yocto/dS/meta-digitalstrom-devel/recipes-extended/msmtp/msmtp_%25.bbappend#L25 Dec 21 14:43:13 damn, missed you :) Dec 21 14:44:08 ok will read up on vardeps, but since I am not using any variables there, just a good old fashioned _append to an existing hook I am really puzzled on what is happening Dec 21 14:44:31 rburton: thanks Dec 21 14:54:12 RP: the glibc change I added seems to hold well on both gold and bfd linker Dec 21 14:54:48 all builds look to work Dec 21 16:21:12 yep, all my master-next builds of all qemu targets for c-i-f-cmdline worked fine. Dec 21 16:58:26 vmeson: do you use gold linker Dec 21 16:59:05 khem: not intentionally! Shall I and if so, how do I enable that? Dec 21 17:02:14 likely still: DISTRO_FEATURES', 'ld-is-gold' Dec 21 17:02:46 * vmeson tries that on master-next Dec 21 17:03:18 yes DISTRO_FEATURES_append = " ld-is-gold" Dec 21 17:15:44 khem: fails for glibc when building build-x86_64-oe-linux/elf/dl-object.o Dec 21 17:19:32 * vmeson tries a build from scratch while away for a bit. Dec 21 17:35:58 vmeson: exactly so you need the patch I did here http://git.openembedded.org/openembedded-core-contrib/commit/?h=yoe/mut Dec 21 18:03:32 vmeson: cool, things seem to be working ok Dec 21 18:03:44 khem: any thoughts on that ppc glibc change? Dec 21 18:11:47 * khem looks Dec 21 18:11:55 How does a package add a file to sudoers.d? If we create the directory in `do_install` then it conflicts with the sudo package's copy of sudoers.d during image assembly, but if we don't create the directory then the do_install fails (since the directory isn't there in ${D}). Dec 21 18:14:03 RP: which change are you pointing to ? Dec 21 18:16:15 khem: the glibc version piece in gcc Dec 21 18:16:25 khem: you were worried about side effects on musl Dec 21 18:16:36 I think it should be ok Dec 21 18:17:05 khem: ok, that was my gut instinct Dec 21 18:19:55 khem: with your change, my ld-is-gold build has managed to compile glibc as you'd expect. Dec 21 18:21:12 RP: musl does not have atomic fenv Dec 21 18:21:46 RP: so if we force it from configure then we might miscompile toolchain for musl Dec 21 18:23:13 khem: hmm, we may need to rebuild gcc for musl ppc then Dec 21 18:23:53 thats what my hunch was, now question is what was it doing before these changes Dec 21 18:24:03 was it detecting glibc >= 2.28 Dec 21 18:24:08 or ignoring it Dec 21 18:28:50 My assumption is that somehow I need to mark the directory as "belonging to sudo instead of me", but I don't see an obvious way to do that. (Here's the recipe I'm writing https://paste.ubuntu.com/p/DVfBZdjh9y/ ). Dec 21 18:30:25 khem: it depended on virtual/libc so I suspect it would say no to it Dec 21 18:30:37 khem: we probably need to confirm that Dec 21 19:04:43 khem: but sysvinit seqfaults so le kernel panics for x86-64 and glibc2.28 on master-next. Dec 21 19:06:43 * vmeson checks if systemd is also borked before considering adding glibc-2.29 to the mix. Dec 21 19:07:52 oh and I did successfully boot all the qemus on master-next before adding ld-is-gold. Dec 21 19:18:30 RP: I think we can live with musl/ppc undertainity for now Dec 21 19:18:35 who uses ppc anyway :) Dec 21 19:21:34 vmeson: cool thanks for helping out Dec 21 19:21:45 sysvinit segfault hmm Dec 21 19:22:58 RP: I am building musl/ppc with master-next lets see Dec 21 19:25:00 RP: using --with-glibc-version kind of makes it glibc tied so we should try to avoid this by fixing the testcases which fail Dec 21 19:25:06 in gcc configure Dec 21 19:25:12 maybe cache the results Dec 21 19:34:15 RP: what error do we see if we do not use --glibc-version in configure Dec 21 19:44:29 khem: systemd itself seems mostly okay but journald, mount, and more? are not happy. Does anyone care about system sanity with glibc-2.28 and ld-is-gold? Dec 21 20:03:22 khem: I'm dropping that DF from my images for now at least. Dec 21 20:41:19 mcfletch: i expect you could create it and install files there, but add sudoers.d/* rather than sudoers.d itself to the FILES variable, so the package manager doesn't think it's claiming ownership of the directory as a whole Dec 21 20:44:04 kergoth: yeah, that's what I'd tried in the paste I posted. Dec 21 20:47:45 In the end I hacked around it by adding a bbappend to make sudoers.d extend staging and add /etc/sudoers.d to sysroot_dirs Dec 21 20:48:36 Then made the user creation a separate .bb that *just* inherits from extrausers. Dec 21 20:49:22 And then a whole separate .bb for setting up the sudoers.d file, and with that it seems to work. Dec 21 21:00:59 Next up I figure out how to make the authorized keys get owned by the product user, but not today, I think. Dec 21 22:20:37 khem: there is no error, I just noticed it as a regression compared to how it worked previously Dec 21 22:21:10 khem: although I believe there is some kind of corruption in configure since if glibc isn't present the next test fails Dec 21 22:21:29 RP: I think we need that option for enabling ssp in glibc Dec 21 22:22:13 khem: currently with musl gcc-cross rebuilds. We can just let that continue to happen and key the configure option off TCLIBC Dec 21 22:22:33 khem: just sad that we have to since having one gcc-cross shared by both would have been nice from a build perspective Dec 21 22:23:58 RP: when we build gcc-cross then glibc-headers are not yet available now right ? Dec 21 22:24:12 khem: correct Dec 21 22:24:20 yeah then we will need this option Dec 21 22:24:38 otherwise the tests to enable ssp will fail Dec 21 22:24:45 khem: I didn't see where ssp was hooked off it though Dec 21 22:24:56 I guess I didn't look correctly :/ Dec 21 22:26:42 RP: gcc configure pokes and sets TARGET_GLIBC_MAJOR and TARGET_GLIBC_MINOR Dec 21 22:27:01 either from cmdline or from features.h from glibc Dec 21 22:28:29 khem: right, I just didn't catch where ssp uses that Dec 21 22:29:16 RP: let me check I am just serving from memory Dec 21 22:29:17 https://patchwork.ozlabs.org/patch/405790/ Dec 21 22:30:31 RP: we can set it to 2.18 then behavior will be same for musl and glibc Dec 21 22:30:50 and we will get the compiler built correctly as well Dec 21 22:31:33 ppc/sf/e500 are rare combinations Dec 21 22:31:43 its probably ok to ignore it now Dec 21 22:35:51 I see that more and more arch features are now trying to use the notion of knowing glibc version Dec 21 22:36:00 see https://patches-gcc.linaro.org/patch/1516/ Dec 21 22:36:04 another attempt Dec 21 22:36:50 https://gcc.gnu.org/ml/gcc-patches/2015-05/msg01522.html Dec 21 22:42:03 RP: we should probably add gcc_cv_libc_provides_ssp=yes to gcc configure anyway Dec 21 22:44:10 ah yes so this is the mail I was referring to w.r.t ssp https://gcc.gnu.org/ml/gcc-patches/2013-11/msg00619.html Dec 21 22:46:59 khem: hmm. I need to go and look at this in more detail. I think I must have missed GCC_GLIBC_VERSION_GTE_IFELSE Dec 21 22:47:27 * RP needs to sleep but will take a look tomorrow Dec 21 22:49:57 no worries, I think we have to separate out musl and glibc cross-compilers Dec 21 22:50:29 since I see gcc learning more and more about glibc features that is not going to be good for musl Dec 21 22:50:46 so we have to reset this anyway Dec 22 00:38:52 RP: I ran core-image-minimal tests with qemuppc/musl and they all passed whereas qemuppc/glibc it crashed in sysvinit :) Dec 22 00:39:08 RP: should we switch to musl as default library then ? **** ENDING LOGGING AT Sat Dec 22 03:00:02 2018