**** BEGIN LOGGING AT Wed Mar 18 02:59:58 2015 Mar 18 05:15:26 abelloni: there? Mar 18 07:54:51 otavio: here Mar 18 09:49:10 morning all Mar 18 10:13:22 mornin Mar 18 10:13:44 morning all Mar 18 10:15:39 does anyone know how MACHINE_KERNEL_PR is supposed to work? I don't really get the idea and there is no documentation on it... or what would be the preferred way of installing multiple kernel ipk's in the rootfs? is that possible at all? Mar 18 10:16:18 Jin^eLD: no, that's not what that's for Mar 18 10:17:02 aha, someone suggested that it was for such a case yesterday Mar 18 10:17:13 hi hi Mar 18 10:17:15 IIRC MACHINE_KERNEL_PR was an earlier means of ensuring that PR for recipes that depend on the kernel got updated Mar 18 10:17:18 then I'll start over with my question: is it possible to install multiple kernel ipk's in the rootfs? Mar 18 10:17:24 aha, I see Mar 18 10:18:03 Jin^eLD: no, we don't support that I'm afraid - kernel packages end up getting called "kernel*" no matter what the recipe is called, so there can only be one Mar 18 10:18:04 bluelightning hm I have made a recipe for linux-backports stuff, with a small modified kernel-module classes Mar 18 10:18:22 bluelightning is there an easy way to trigger an rebuild whe tne linux-kernel version is changed? Mar 18 10:18:29 when the Mar 18 10:18:45 Jin^eLD: it is something people have asked for, so we may end up doing it in future (especially if someone sends patches) Mar 18 10:19:07 I see hmm Mar 18 10:19:13 woglinde: that should happen automatically based on signatures - the kernel is in the dependency chain for those already Mar 18 10:19:21 okay Mar 18 10:19:33 bluelightning: is it something on opkg level or is it something where the differences would be ensured through different package names? Mar 18 10:19:39 than it was really a local problem, because we renamed it serval times Mar 18 10:19:49 or I renamed Mar 18 10:20:02 and the older name modules and packages where laying around Mar 18 10:20:35 Jin^eLD: it's both at the metadata level and opkg; I don't necessarily have the details, but I do know it's complicated Mar 18 10:21:08 I see Mar 18 10:21:13 woglinde: that's probably the old renamed recipe issue which is not specific to the kernel - once a recipe is renamed, bitbake doesn't know how to remove files staged by the old recipe Mar 18 10:21:24 woglinde: there is a bug open for that Mar 18 10:32:01 anyone know if it's possible to make wic honor OpenEmbedded rootfs size settings such as IMAGE_ROOTFS_EXTRA_SPACE when it creates its filesystems? it seems to ignore whatever amount of free space I specify in my images, probably since it reads the rootfs tarball when it creates its filesystem and partitions Mar 18 11:08:17 what's the proper way to activate systemd in an image? I just threw http://pastebin.com/X4WzcR7x in my local.conf to see what would happen. Mar 18 11:08:29 spoiler alert. it didn't quite work Mar 18 11:08:52 tasslehoff use master it comes as default or so Mar 18 11:12:50 woglinde: wish I could. we're using 1.4 on an old product, and I'm trying to move from angstrom-setup-scripts to using the yocto releases "directly" Mar 18 11:32:32 the rootfs builds, but the sdk fails because systemd-dev and libudev-dev both try to install libudev.so Mar 18 12:36:32 re Mar 18 12:36:47 tasslehoff fix it Mar 18 17:21:22 what was the motivation for adding -e to #!/bin/sh in /etc/init.d/networing script? Mar 18 17:21:41 because of that installing procps breaks networking Mar 18 17:21:55 presumably the same as the motivation for any other time you use set -e, but i'd suggest using git blame Mar 18 17:21:59 because the sysctl from procps behaves differently and the whole networking script gets aborted Mar 18 17:24:02 the problem with set -e, among other things, is it's not always obvious when the script exited, or where it exited in the script, or why.. there's no context shown. explicit exits on failure are better, but verbose and folks often forget to do it.. Mar 18 17:30:13 yeah, true, well I know wher it exits Mar 18 17:30:20 and I know that it does not exit with busybox sysctl Mar 18 17:31:14 debugged this particular issue with the networking script Mar 18 18:17:01 Jin^eLD: out of curiosity, why does the real sysctl error out? Mar 18 18:20:30 kergoth: because we have no sysctl.conf Mar 18 18:20:40 ah Mar 18 18:20:40 just touching it would be enough I guess Mar 18 18:20:43 makes sense Mar 18 18:21:02 course then there's a question of who owns that file and whatnot Mar 18 18:21:18 yes.. but somehow the procps sysctl causes the script to abort when sh -e is used, while busybox'es sysctl does not cause the script to abort Mar 18 18:21:24 right... Mar 18 18:21:38 but imho something like that should not break networking Mar 18 18:22:18 yeah, i expect the set -e is the wrong approach regardless, though i could certainly see getting a sysctl.conf added at some point too Mar 18 18:22:22 * kergoth shrugs Mar 18 18:23:14 -e is weird indeed, I'd rather go for specific checks and bailouts where needed instead of such globalization... **** ENDING LOGGING AT Thu Mar 19 02:59:58 2015