**** BEGIN LOGGING AT Sat Apr 30 02:59:58 2016 Apr 30 06:47:05 hi Apr 30 06:47:20 do I still need to switch from dash to bash in ubuntu before building something with jethro? Apr 30 16:02:00 dv_: OE-core worked with dash equally well, why did you have to change to bash Apr 30 18:17:00 khem: oe-core hasn't always worked with /bin/sh as dash. i think that was fixed a few releases ago, though Apr 30 18:17:10 dv_: dash as /bin/sh is fine in jethro afaik Apr 30 18:17:15 * kergoth yawns Apr 30 18:17:34 note that dash as the user shell won't work with the setup scripts, it's only valid as /bin/sh Apr 30 19:18:01 kergoth: I think OE-core and most 'blessed' layers (meta-oe, etc) are dash-safe for code in recipes and included scripts Apr 30 19:18:12 kergoth: upstream software is a different story Apr 30 19:19:10 kergoth: I still get bug reports every now and then that turn out to be bashisms instead of OE/angstrom bugs Apr 30 19:19:51 so personally, I'd say: don't use dash Apr 30 19:20:17 (I realize that's is 'being part of the problem') Apr 30 20:05:55 kergoth: but he is talking about jethro Apr 30 20:06:28 not very old layers, where I would agree with you Apr 30 20:07:24 khem: his question was whether the dash issue was *fixed* in jethro, which clearly implies theyw ere using an old yocto version, or had hit the issue in teh past, and wanted to know if it was fixed Apr 30 20:07:28 to which i said yes Apr 30 22:13:13 ah right, I just have forgotten about older releases :) Apr 30 22:54:58 I've been staring at this for days, time to ask for help :/ Apr 30 22:56:05 I'm trying to build my own minimal chroot/image to use as a rkt stage1. Suffice to say, it's sort of like a minimal initramfs image that just contains systemd-nspawn and dependent libraries. Apr 30 22:57:33 I have a parallel systemd-rkt-stage1_xx.bb that builds a systemd with the minimal options I want, and I have a image-aci-stage1.bb modelled off core-image-minimal-initramfs.bb Apr 30 22:59:15 My problem is: when building my image, it tries to do systemd-rkt-stage1:do_populate_sysroot, which (rightly) complains that the systemd executables conflict with the real systemd package that I'm using in my real (bootable) filesystem image. Apr 30 23:00:11 I don't understand: a) why PACKAGE_INSTALL turns into :do_populate_sysroot (afaics it just needs do_package?) Apr 30 23:01:00 and b) how core-image-minimal-initramfs doesn't hit similar problems with (eg) /init Apr 30 23:08:37 images aren't staged or packaged. and even if they were, /init isn't included in the specific paths that go into the sysroot Apr 30 23:10:45 kergoth: I'm having a problem with a package that will go into the image, not the image itself (if I understand your reply correctly). Apr 30 23:12:00 I basically have two systemd packages with conflicting filenames - and I'd like to install one each into separate images. Apr 30 23:12:26 that sounds like a terrible idea for a variety of reasons, but you could work around it by changing what goes into the sysroot for one or both recipes Apr 30 23:12:42 i.e. sysroot_stage_all () { :; } in systemd-rkt-stage1 Apr 30 23:12:52 What makes them both even need to go into sysroot? Apr 30 23:13:53 (or: how might I find that out?) Apr 30 23:14:28 bitbake -g yourimage, then read task-depends.dot Apr 30 23:15:21 I haven't played with -g before - neat. Apr 30 23:16:15 best to just view the files directly, don't try to render them with graphviz, the graph is so massive it's impossible to make any sense of visually Apr 30 23:16:20 but the data, that's useful Apr 30 23:21:40 hrm. It seems I misunderstood the situation - the complaint about conflicting files occurs during do_packagedata. Apr 30 23:21:51 kergoth: thanks, I'll go stare some more with my new information. Apr 30 23:22:58 if there's a conflict in packagedata, then the two recipes are providing at least some of the same binary packages, that won't do Apr 30 23:24:13 kergoth: yeah, that's my problem. I thought it wouldn't/shouldn't be an issue since I was installing into separate images. Apr 30 23:24:38 the packages and package feeds are common. Apr 30 23:24:59 kergoth: right, this is what I'm discovering... Apr 30 23:25:12 this would really be a lot easier to just do it with two build directories and change the configuration of the existing systemd recipe Apr 30 23:25:19 otherwise you'll need to rename all the binary packages Apr 30 23:25:40 kergoth: yes, so how do I do two different builds of the one package? Apr 30 23:25:56 i don't understand the question Apr 30 23:26:02 that was really what I wanted to do, but I didn't see an obvious way to do so. Apr 30 23:26:22 kergoth: is it possible/easy to build systemd using two different PACKAGECONFIGs, for example? Apr 30 23:26:26 ? Apr 30 23:26:31 i don't se ethe confusion here Apr 30 23:26:38 you can alter systemd's pcckageconfig in local.conf Apr 30 23:26:42 use two build dirs, change it in one, lnot hte other Apr 30 23:26:44 do two builds Apr 30 23:26:44 done Apr 30 23:27:10 oh right, but then I can't drag one of those builds into a dependency of the other build. Apr 30 23:27:40 or .. I guess I can by just knowing where the output from the first is going to be... Apr 30 23:27:48 not directly, no. if you need both in the same build then you have no choice but to change all the package names so there's no conflict in any of the content between the two recipes Apr 30 23:28:02 i'd prototype both and see what seems cleanest given your requirements Apr 30 23:28:21 yeah, I think I'm concluding that moving all the files around in one of the systemd's is what I'll have to do. Apr 30 23:29:30 That isn't actually that bad a solution for this specific case actually (since I can tell rkt what command lines to use to find it's stage1 systemd) Apr 30 23:29:42 kergoth: thanks, this has been helpful. Apr 30 23:29:49 * kergoth nods Apr 30 23:29:49 np Apr 30 23:30:18 I started work on a flexible mechanism for creating new configuration-based variants of a recipe. i.e. busybox and busybox-minimal. i never finished it, though. and it doesn't address the sysroot conflict, only the package conflict. but that sort of thing might have been useful for this sort of case too Apr 30 23:30:19 hmm Apr 30 23:30:44 https://github.com/kergoth/meta-named-configs-prototype/blob/master/recipes-core/busybox/busybox_1.23.2.bbappend for example Apr 30 23:30:51 * kergoth ponders **** ENDING LOGGING AT Sun May 01 02:59:58 2016