**** BEGIN LOGGING AT Fri Mar 05 02:59:57 2021 Mar 05 07:48:16 good morning Mar 05 08:20:38 bonjour Mar 05 09:32:21 howdy Mar 05 09:32:22 * dwagenk sent a long message: < https://matrix.org/_matrix/media/r0/download/matrix.org/AdBDHoKmtQFCNWySKemJRRzt/message.txt > Mar 05 13:54:41 zeddii: bison is pretty complicated.... it might depend on how the #ifdefs are generated. I'm *pretty* sure I got all the places in bison where it needs to do the translation Mar 05 13:55:50 I'll sort it out. I've got a handle on it now at least, these could be the last two that I missed. I may have missed a call to bison when I put flags into the makefile. Mar 05 13:56:20 zeddii: OK Mar 05 13:56:55 but unfortunately, my disk has really gone in that builder now, so I'm going to have to get a new one today and pick it up later. figures. Mar 05 13:57:05 luckily, all my in progress work is off the machine and safe. Mar 05 14:09:24 zeddii: Heh, fun. I wrecked my local autobuilder cluster earlier this week and still haven't gotten around to re-imaging it... It's just a software problem though Mar 05 15:12:01 https://reproducible-builds.org/reports/2021-02/ - we get a mention Mar 05 15:13:25 Hi i'm trying to build my root fs from scratch but get een error on mariadb i think that mariadb dowload location is changed Mar 05 15:16:23 the work/armv7at2hf-neon-oe-linux-gnueabi/mariadb/10.5.8-r0/mariadb-10.5.8/ dir is empty Mar 05 15:19:25 Hi all. To which mailing list shoud patches for yocto-kernel-tools (https://git.yoctoproject.org/cgit/cgit.cgi/yocto-kernel-tools) be send to? Mar 05 15:38:15 in classes/insane.bbclass there's a check for $D vs ${D}, i'm curious what this check is for? does /bin/sh not understand ${D} vs $D? Mar 05 15:40:10 tlwoerner: the postinst checker? Mar 05 15:40:35 rburton: yes Mar 05 15:40:46 expanded-d Mar 05 15:41:00 in a postinst you don't want bitbake to expand $D because thats how they tell if they're running in on target or at rootfs time Mar 05 15:41:09 need to use $D so bash expands Mar 05 15:45:54 so postinst's get called twice? once during build, once on-target? and something needs to distinguish between these two cases, and the $D vs ${D} is the hack that's used to indicate which case? Mar 05 15:55:40 yes. if it succeeds on rootfs time then it doesnt run at first boot Mar 05 15:55:52 (this logic predates the pkg_postinst_on_target stuff) Mar 05 15:56:13 if at rootfs time, $D is in the envrionment Mar 05 15:56:29 so you want to delay the expansion to postinst execution time, which means using $D as bitbake doesnt expand those Mar 05 15:56:37 i suspected $D was imported somehow Mar 05 15:56:52 clever :-) Mar 05 16:10:08 rburton: thanks :-) Mar 05 16:10:51 zeddii: can you put a README in yocto-kernel-tools please? :) Mar 05 16:37:54 RP: Yay! Mar 05 16:39:22 to deactivate selinux in the image, do I have to do anything more but putting IMAGE_INSTALL_remove += "selinux" into my image recipe? Mar 05 16:40:02 selinux is enabled by both packages on the target image as well as DISTRO_FEATURES .. so it depends on if you want it available, but off.. or gone completely Mar 05 16:59:56 fray: best case, gone completely Mar 05 17:02:50 chrysh: if selinux is in IMAGE_INSTALL, you can just not put it there in the first place. Otherwise, it might be pulled in by other stuff as build time or runtime dependency and then IMAGE_INSTALL_remove won't be enough Mar 05 17:03:10 so this should work to remove it completely?: IMAGE_INSTALL_remove += "selinux" Mar 05 17:03:12 DISTRO_FEATURES_remove = "selinux" Mar 05 17:03:30 I want at least deactivate it in my local.conf for now to see whether the image builds Mar 05 17:03:42 if you REALLY don't want selinux in your image, you can just remove the recipe and see what's not building anymore, and little by little fix the recipes/PACKAGECONFIG/variables that add selinux as a depenency Mar 05 17:03:45 it's a vendor image, so I am not sure it will build without Mar 05 17:04:00 good point Mar 05 17:37:24 hello, I'd like to be sure that I understand correctly: if my distro sets INIT_MANAGER = "mdev-busybox", then recipes like openssh that inherit update-rc.d will no longer autostart their daemons via init scripts in my rootfs? Mar 05 18:01:35 RP: seen your reply on glib-2.0 THISDIR thread, should I send https://git.openembedded.org/openembedded-core-contrib/commit/?h=jansa/master&id=20e95beb61271e0282485a278845261a863dd50b as minimal fixup for my mess? (testing it locally already) Mar 05 18:08:03 JaMa: hmm, probably. I'm worried about this thing in general though :/ Mar 05 20:32:27 hmmm https://autobuilder.yoctoproject.org/ is saying `502 Bad Gateway Mar 05 20:32:27 ` Mar 05 20:35:13 eduardas: we kind of have the rc.d mechanism working with busybox-init too Mar 05 20:35:43 so in most cases the init scripts will run with busybox shell Mar 05 21:24:13 Guest27389: we're in the autobuilder maintenance window Mar 05 21:25:42 yeah i see Mar 05 21:27:29 Guest27389: it is coming back online now Mar 05 21:50:09 since beaglebone-yocto isn't based on manufacturer meta-ti's beaglebone definition, does it support graphics and all? Mar 05 21:54:18 hardware acceleration* Mar 05 22:18:49 What is the format (for multiconfig) for a recipe to depend on a task? I was trying "mc:mymc:myrecipe:do_deploy" but I got the error "must have exactly one ':' character" Mar 05 22:18:58 that was via do_foo[depends] = Mar 05 22:19:05 fray: use mcdepends, not depends Mar 05 22:19:07 different flag Mar 05 22:19:19 ahh Mar 05 22:19:20 thanks Mar 05 22:19:22 np Mar 05 22:27:42 fray: mc:destmc:srcmc:recipe:task Mar 05 22:28:12 fray: The mcdepends only takes effect if the current mc is destmc Mar 05 22:43:35 thanks that helps Mar 05 22:44:46 what is the destmc for the default? Mar 05 22:47:26 fray: An empty string Mar 05 22:47:39 e.g. mc::srcmc:recipe:task Mar 05 22:49:08 fray: And I *think* you can do mc:${BB_CURRENT_MC}:srcmc:recipe:task to make it always (well... *almost*) match whatever the current mc is Mar 05 22:49:31 I see references to 'mc:default' Mar 05 22:49:32 Ohh Mar 05 22:49:42 The annoying part that I have not yet gotten around to fixing is that BB_CURRENT_MC = "default", which doesn't work Mar 05 22:49:46 Ya Mar 05 22:50:10 There is an impedence mismatch w.r.t. the base (default) configuration Mar 05 22:50:28 ugh, I'm not getting an error "Uninative selected but not configured correctly, please set UNINATIVE_CHECKSUM .. only thing I did was enable the multiconfig!? Mar 05 22:50:29 You can work around it by adding two lines, one with ${BB_CURRENT_MC} and one with "::" Mar 05 22:50:40 fray: Hmm, not sure Mar 05 22:51:24 wipe and rety Mar 05 22:51:47 Ugh, I didn't set TMPDIR in my mc.. I bet I broke it there Mar 05 22:52:08 Oh, ya. You pretty much need a dedicated TMPDIR for each mc Mar 05 22:53:11 fray: You might find our "use a multiconfig for each product" wrangling tool interesting: https://github.com/garmin/whisk Mar 05 22:53:51 ok.. turning on multiconfig is breaking it.. ugh.. not sure what I did wrong Mar 05 23:03:51 it was a DISTRO loaded by an MC was failing.. even though the main distro didn't load it.. ugh **** ENDING LOGGING AT Sat Mar 06 02:59:57 2021