**** BEGIN LOGGING AT Thu Jun 09 02:59:58 2016 Jun 09 07:42:13 kergoth, paulg_: for delayed deletion ionice is great, make the rm have lowest priority for IO ops Jun 09 10:54:32 do_rootfs is barfing on me, not sure why Jun 09 10:54:33 Package 'grub' has no installation candidate Jun 09 10:54:52 Package grub is not available, but is referred to by another package. Jun 09 10:54:52 This may mean that the package is missing, has been obsoleted, or Jun 09 10:54:52 is only available from another source Jun 09 11:05:56 hi! bitbake seems to ignore a recipe I added. Is there a way to force the cache to reload besides deleting it entirely? Jun 09 11:09:43 LeifSo: could you describe what you have done? Jun 09 11:10:07 CTtpollard: I added a directory to a layer I'm using and added a file to that layer Jun 09 11:10:35 now it seems to me, that bitbake didn't notice the extra directory within the layer leading to skipping the recipe Jun 09 11:11:05 LeifSo: you'll probably have to make it visible to bblayers.cong Jun 09 11:11:06 *f Jun 09 11:11:40 CTtpollard: just added a directory, not an entire layer :) Jun 09 11:11:47 also, have you instructed the image.bb you're building or local.conf to build your new recipe/ Jun 09 11:12:13 CTtpollard: there's a wildcard within the layer, that covers the added directory+recipe Jun 09 11:12:30 CTtpollard: yeah, no luck building it explicitly Jun 09 11:12:51 when I provide the recipe explicilty (-b $file), it works. Jun 09 11:14:45 is there a way to dump all the directories bitbake searches for recipes? Jun 09 11:27:47 solution: build$ rm -rf tmp/cache Jun 09 11:28:34 too soon -.- Jun 09 11:30:01 is there some magic that'll make bitbake quietly skip recipes? E.g. naming convention whatever? Jun 09 11:34:51 LeifSo: asking because a recipe isn't being parsed, or because you want it to be ignored? Jun 09 11:35:07 turned out the layer.conf proclaimed another directory inbetween -.- ${LAYERDIR}/recipes-*/*/*.bb Jun 09 11:35:32 rburton: bitbake didn't find it Jun 09 11:36:05 yeah that happens :) Jun 09 11:37:01 the wildcard was correct. Could have needed a hint when running with e.g. '-D' like: "you're looking for recipe z. Found it at x/y/z, but x/y is not matched by your layer.conf's." Jun 09 11:38:39 rburton: since bitbake does so many things automagically I figured it might skip something somewhere.. Jun 09 11:42:58 I created a class for dev purposes that does nothing but set the root pw. Now packaging the system fails, because the corresponding package cannot be found, because not files were packed -.- Jun 09 11:43:20 why would it go wandering around the file system in places you didn't specify? Jun 09 11:43:47 ALLOW_EMPTY=1 to generate a package with no content Jun 09 11:44:30 LeifSo but there is such class already? extrausers Jun 09 11:45:21 jaskij: exactly. As far as I understood, you need to create some .bb and inherit from extrausers, to actually use it Jun 09 11:45:46 LeifSo yes, you inherit it in the image recipe Jun 09 11:45:57 ah, okay Jun 09 11:46:55 jaskij: thanks :) Jun 09 11:47:14 LeifSo or jest use debug-tweaks Jun 09 11:48:46 jaskij: I assume debug-tweaks enables passwordless login? Jun 09 11:49:34 jaskij: I just saw, that debug-tweaks are already enabled Jun 09 11:50:27 but ssh access is not granted using root/root. What's set by default? Jun 09 12:02:37 root/no password Jun 09 12:13:18 rburton: does not work here -.- Jun 09 12:13:44 'permission denied' Jun 09 12:51:52 might that be related to using open ssh instead of dropbear? Jun 09 12:56:38 can someone guide how to install bzr and dos2unix on yocto Jun 09 12:57:38 https://layers.openembedded.org/layerindex/branch/master/recipes/?q=bzr says that nobody has written a recipe for bzr, so you'd need to write a recipe yourself Jun 09 12:58:09 for dos2unix, you can write your own recipe or just use "tr" Jun 09 13:03:32 what about scipy and libnfc installation on yocto Jun 09 13:18:51 has anyone tried scipy on yocto Jun 09 13:19:28 could someone hint how to add task logs sstate cache? Curently there are no logs saved for the things which are in sstate cache which makes it harder to debug issues which generate bad data to it. Jun 09 14:06:31 kergoth: around? Could do with discussing some scope problems with you... Jun 09 15:18:45 anyone here has any experience with meta-ti? Jun 09 16:08:33 rburton: good idea, would you suggest the idle class, or best effort at the lowest priority? would idle slow it down too much? guess it depends on how quickly one needs the space freed Jun 09 16:08:49 RP: I'm in back to back meetings this morning, still going on Jun 09 16:08:54 kergoth: my nicerm just uses ionice -c3 Jun 09 16:08:57 appears to help Jun 09 16:08:59 * kergoth nods Jun 09 16:09:04 but i've not done tests Jun 09 16:15:59 * kergoth tweaks bgrm to ionice to 3 by default to test it out for a while and see Jun 09 16:18:11 kergoth: basically if you put a line like foo=${@' '.join([d.getVar('D', True) + x for x in (' '.join([d.getVar('FILES_bash-' + p, True) or '' for p in ['lib', 'dev', 'staticdev', 'doc', 'locale', 'ptest']])).split()])} into do_install, it fails with Exception name 'd' is not defined Jun 09 16:18:26 ah, yes, i've hit that on a number of occasions over the years Jun 09 16:18:45 kergoth: the problem is "generator expressions, dict comprehensions and set comprehensions are executed in a new scope. List comprehensions are not, but only in Python 2.x. In Python 3 they all use a new scope. " Jun 09 16:18:56 kergoth: so that expression works in py2 but not in py3 Jun 09 16:19:13 kergoth: so do we add d to globals in utils.better_eval() or ??? Jun 09 16:22:03 I'm assuming that scope can only access globals, not locals, similar to how locals specified in eval can't be used from inside a def'd function, so has to be passed in or set as global? Jun 09 16:31:53 ah, indeed. eval can only set locals and globals, can't define the enclosing scope Jun 09 16:31:55 makes sense Jun 09 16:32:33 hmm Jun 09 16:35:05 kergoth: I think we're going to have to change better_eval somehow, I just can't decide how :/ Jun 09 16:35:10 hmm Jun 09 16:38:20 RP: i wonder if we could create our own enclosing scope rather than either locals or globals by nesting the expression in a def'd function and calling that, passing d as an argument Jun 09 16:39:13 kergoth: we probably could, I have to admit I dislike the amount of that we already do though :/ Jun 09 16:39:35 i.e. exec 'def foo(d): return ' in ns; result = ns['foo'](d) Jun 09 16:39:36 agreed Jun 09 16:39:54 i'm not a fan of the generated function definitions we have already, but there's only so much we can do given the limitations of exec and eval Jun 09 16:39:58 it's either that or set it as global Jun 09 16:40:48 i guess global could work, not really seeing a downside, since we control both namespaces anyway. we shouldn't need to alter the global in our functions Jun 09 16:40:54 * kergoth ponders Jun 09 16:42:23 would be nice if you could control the enclosing scope/context in eval/exec, but given it has to be done at compile time, and compilation is a prior step, i can see why that would be problematic Jun 09 16:42:41 kergoth: The bigger question is what to do with DataContext() - currently that is in local scope and could potentially be a lot more dangerous in global :/ Jun 09 16:44:50 hmm, possibly Jun 09 16:46:33 if it's a new global scope for each one, so they can't affect one another, it might be fine. a generator expression doesn't leak into the global scope anymore the way it used to in python 2 Jun 09 16:46:38 hmm Jun 09 16:48:04 might be best off going the enclosing function route just to be safe, though Jun 09 16:48:16 though that wouldn't help context, woudl it.. Jun 09 16:48:17 hrmph Jun 09 16:54:46 rburton, paulg_: there we go, https://github.com/kergoth/dotfiles/blob/master/scripts/bgrm is what i use, now with both ionice and delay options, inspired by your scripts Jun 09 16:56:14 if you're curious, the temporary file is used to allow it to only remove the bits whose mv has succeeded, while leaving the rest alone. it was either that or a for loop with saving the args into a variable, but that can be error prone due to quoting and separator selection Jun 09 16:56:24 heh Jun 09 17:10:55 Hi, under which layer do I add an initscript if I am using the systemd init system so that it gets installed under /usr/lib/systemd/ ? currently I use systemvinit and add the init script as a bbappend to meta/recipes-core/initscripts/ and it gets installed under the /etc/init.d/ . Jun 09 17:11:20 layer is irrelevent Jun 09 17:11:35 inherit systemd, install the service to ${D}${systemd_unitdir}, and set SYSTEMD_SERVICE Jun 09 17:13:03 oh..ok..thanks! Jun 09 18:23:41 Hmm, should probably pull argparse_oe into bitbake so we can use it for bitbake-layers & other scripts there Jun 09 18:31:18 * paulg wonders if build-appliance gets nightly build coverage. Jun 09 18:32:20 ERROR: Nothing RPROVIDES 'libgl' (but /home/paul/poky/meta/recipes-core/packagegroups/packagegroup-self-hosted.bb RDEPENDS on or otherwise requires it) Jun 09 18:32:50 forgot opengl in your DISTRO_FEATURES? that's when i've hit errors like htat Jun 09 18:33:30 ah, could be. Guessing if I didn't care about gemu gfx I could just dump it from the list. Jun 09 18:33:37 probably Jun 09 18:33:42 * kergoth shrugs Jun 09 18:40:57 kergoth, yep, this was essentially a vanilla config I started with for this, with no DISTRO_FEATURES Jun 09 18:41:08 I added DISTRO_FEATURES_append = " opengl" and it STFU. Jun 09 18:41:28 odd that this isn't sucked in by default when you specify build-appliance as the target... Jun 09 18:42:15 * paulg is contemplating having a nightly build of build-appliance confirm that it can build itself. Jun 09 18:42:53 want it to be as vanilla as possible, w/o meta-kitchen-sink, meta-vortex-of-crap, etc. Jun 09 18:43:10 so wasn't expecting to have to add features. Jun 09 18:46:00 doing *anything* to the global config based on what recipe you happen to be building isn't smart, would lead to non-deterministic builds Jun 09 18:46:16 but yes, i'd expect either qemu to default to no gl or nodistro to default to opengl Jun 09 19:05:26 kergoth, yeah qemu is probably a better place for that. Jun 09 20:46:20 paulg: build-appliance coverage: https://autobuilder.yoctoproject.org/main/builders/build-appliance Jun 09 20:46:50 kergoth: would you agree that putting d into the global scope is probably the best way forward for now? Jun 09 20:47:12 kergoth: probably take a copy of get_context() and then inject it? Jun 09 20:49:12 I would think so. If we can find a way to improve it further from there, we can do so at some point in the future. Jun 09 20:52:34 * paulg checks out the link from RP Jun 09 21:02:01 RP, but as far as you know, there is no regular "can build-appliance rebuild itself" test, right? Jun 09 21:02:30 * paulg thinks build-tarball has more python3 goo in it than build appliance does... Jun 09 21:10:34 paulg: I'd love to see a testimage test for build-appliance that we could run to test that Jun 09 21:11:12 paulg: https://bugzilla.yoctoproject.org/show_bug.cgi?id=9713 Jun 09 21:11:14 Bug 9713: normal, Medium+, 2.2 M1, ross.burton, IN PROGRESS REVIEW , packagegroup-self-hosted.bb needs to be updated for python3 Jun 09 21:12:34 * paulg has the individual list of python3 sub pkgs needed to augment that ; turns out to be about 13 more than the 42 it has now. Jun 09 21:12:54 paulg: I'd love a patch Jun 09 21:13:07 I'm working on it ; trying to find the time. Jun 09 21:13:23 I need the same patch for meta-overc anyway. Jun 09 21:13:40 RP if you want to assign that to me, go ahead. Jun 09 21:28:00 paulg: I'll let you and rburton 'fight' over it :) Jun 09 21:39:40 RP, I'll just log in and leave a note indicating what the list is and that I can submit a patch eventually, so that rburton has the opportunity to move onto other things if he wants. Jun 09 21:39:51 assuming I can recall my login. :) Jun 09 21:40:49 * paulg suspects his desktop in the office can recall the login Jun 09 21:42:01 paulg putting info there would be most helpful Jun 09 21:46:26 need to finish what I'm on in the next 15m and then I'll try and login from offsite where I am now... Jun 09 21:49:01 kergoth: does http://git.yoctoproject.org/cgit.cgi/poky/commit/?h=master-next&id=b62d68e2985594776137678f79ec5fffe107022e seem reasonable ? Jun 09 22:11:01 paulg: email if you can't, ross.burton@intel.com. its sad we don't test that anymore. Jun 09 22:12:33 rburton, I've been implicitly testing it for a while now (manually :-/ ) since with meta-overc you can generate what is essnentially the build applicance but with a kernel and grub. Jun 09 22:13:02 and the normal stuff like tab completion etc etc that make using it as a build server not suck. Jun 09 22:13:07 rburton: needs automating. We could file a bug... Jun 09 22:13:20 RP: going to fire a mut if thats okay? Jun 09 22:13:37 rburton: yes, more than ok but can you pull the bitbake patch in -next please? Jun 09 22:13:46 yeah i rebased to master-next Jun 09 22:13:51 rburton: thanks Jun 09 22:14:26 rburton: been meaning to sort patches but been having so much fun with multiconfig Jun 09 22:14:53 I did have bitbake parse and load three different MACHINE settings into memory at once :) Jun 09 22:15:13 Downside is the parsing from cache failed but that didn't surprise me Jun 09 22:15:25 one step at a time... Jun 09 22:16:47 cool Jun 09 22:32:55 RP, managed to fumble my way in; bug 9713 updated. Jun 09 22:32:56 Bug https://bugzilla.yoctoproject.org/show_bug.cgi?id=9713 normal, Medium+, 2.2 M1, ross.burton, IN PROGRESS REVIEW , packagegroup-self-hosted.bb needs to be updated for python3 Jun 09 22:34:00 paulg: thanks! Jun 09 22:36:01 * RP -> Zzzz Jun 09 22:36:42 * paulg wanders off for food Jun 09 22:47:52 RP: looks fine to me (bitbake d in globals patch) **** ENDING LOGGING AT Fri Jun 10 02:59:59 2016