**** BEGIN LOGGING AT Wed Aug 03 02:59:58 2016 Aug 03 11:54:11 Thi shappened before, but I thought it "went away" Aug 03 11:54:13 * satisfy_dependencies_for: Cannot satisfy the following dependencies for packagegroup-core-x11-utils-dev: Aug 03 11:54:13 * x11-common (= 0.1-r47) * Aug 03 11:54:13 * opkg_install: Cannot install package packagegroup-core-x11-utils-dev. Aug 03 12:37:48 Crofton|work: is this the adding meta-oe and then removing it issue? Aug 03 12:37:59 ? Aug 03 12:38:06 I do not remove meta-oe Aug 03 12:38:24 definitely some form of Heisenbug Aug 03 12:48:41 no x11-common in meta-oe, so not sure how there would be linkage anyway Aug 03 12:48:59 Crofton|work: packagegroups aren't rebuilt when the dependencies are modified, so if you have switched provider from x11-common to xserver-common, the packagegroup will still rdepend on the old one Aug 03 12:49:10 this was a clean build Aug 03 12:49:18 hmm Aug 03 12:49:40 * Crofton|work wonders Aug 03 12:49:53 why two providers also? Aug 03 12:49:56 seems stupid Aug 03 12:51:30 tried cleaning the packagegroup Aug 03 12:55:17 rebuilding the packagegroup doesn't seem tpo help Aug 03 12:55:23 this is with krogoth btw Aug 03 13:04:10 what are the reasons to enforce an utf-8 locale? and en_US.utf-8 instead of C.utf-8? System builds fine with 'C' locale Aug 03 13:21:13 ah, Add a magical incantation: VIRTUAL-RUNTIME_xserver_common = "xserver-common" Aug 03 13:21:35 I need to make a list of dumb things in the oe universe Aug 03 13:21:37 VIRTUAL-RUNTIME_xserver_common = "xserver-common" Aug 03 13:21:42 tabs versus spaces Aug 03 13:21:56 poky versus oe-core Aug 03 14:44:52 Crofton: here's my list https://github.com/twoerner/oe-misc/blob/master/notes (although some/most of it might be too old now) Aug 03 14:55:01 good list, but you have a little different focus Aug 03 14:55:14 I'm interested in stamping out these stupid conflicting things we have Aug 03 14:55:23 that jsut create confusion Aug 03 14:55:37 yeah, I am very cranky this morning Aug 03 15:17:34 Crofton: it's well earned Aug 03 15:20:37 being cranky? Aug 03 15:43:52 ensc|w: C.utf-8 isn't distro agnostic, though Fedora and Debian both provide it iirc Aug 03 15:43:59 ensc|w: see bitbake 8902c29638411d312e6fc4a197707e5742652e15 for more info Aug 03 15:56:40 joshuagl: I removed this code and the related check from bitbake and everything builds fine. non-C locale are pita as they require changes in the infrastructe and have strange LC_COLLATE effects Aug 03 16:01:31 ensc|w: "everything builds fine" from a clean slate? I'd be surprised, the change wasn't made lightly Aug 03 16:02:00 it's understood that the non-C locale is a PITA but was deemed necessary Aug 03 16:02:28 note: I didn't author the change so can't defend it in detail but I know RP didn't make the change lightly Aug 03 16:03:19 joshuagl: ok, I do not bitbake world, but e.g. qt5 based images are building fine with C Aug 03 16:03:43 from sstate or from scratch? Aug 03 16:04:13 from scratch Aug 03 16:04:43 using master means usually scratch ;) Aug 03 16:05:32 well, it hasn't changed since yesterday :-) Aug 03 16:05:49 can you bitbake ca-certificates-native ? Aug 03 16:08:33 ensc|w: basically we build on distros where C.utf8 doesn't exist :( Aug 03 16:08:55 ensc|w: if it exists on your distro, using it is probably fine but its not a standard Aug 03 16:09:55 joshuagl: builds fine... Aug 03 16:13:29 RP: problem is, that checks and values are really hardcoded; I am not sure whether en_US.utf-8 is available everywhere. Another problem is, that it is not needed Aug 03 16:30:05 ensc|w: en_US is a standard part of glibc upstream which C.utf8 isn't so its more available. We *need* a utf-8 locale else python3 gets locked into ascii only mode and if you try bitbake in ascii only mode, it doesn't work well Aug 03 16:33:29 RP: why does it not work? As I said, I build images with C locale. python3 character conversion exceptions can happen with utf-8 locales too (e.g. when some package gives out messages in koi8 encoding or so Aug 03 16:36:47 ensc|w: Try changing LC_ALL to be C in bitbake's code and in bitbake.conf, and your environment and you will find the builds fail quite badly. The reason is that python3 picks a default encoding at load time based on the environment setting. If your locale setting isn't a utf-8 based one, it gets locked into acscii mode. The python authors specifically disallow changing this default after load time. To work around this, we'd have to manually set binary m Aug 03 16:37:05 ensc|w: I did post about this on the mailing lists at the time, nobody has offered me a better solution Aug 03 16:37:40 ensc|w: you could argue this is pretty horrible of python to do this and I'd probably agree but I can't change that Aug 03 16:38:17 RP: I patched bitbake and set LC_ALL=C; at least qt5 based images are building fine Aug 03 16:40:40 ensc|w: all I can tell you is what I experienced when I originally came to this conclusion, and I did quite some research and experimentation with it. DIid you change the bitbake.conf value? Aug 03 16:41:04 RP: yes Aug 03 16:41:32 ensc|w: then I don't know why its working for you but I still suspect its finding a utf-8 locale somehow Aug 03 16:42:49 ensc|w: we need the utf8 in the environment since at some points we run python scripts from within bitbake and some of those also have the same locale problem (esdk, devtool, recipetool, bitbake-layers suffer in particular) Aug 03 16:43:41 RP: e.g. the run.do_install file of ca-certificates-native (which was asked by joshuagl) can be found at http://pastebin.com/uH9Nwz2y Aug 03 16:44:35 ensc|w: you are running bitbake in a shell which is set to a C locale right? Aug 03 16:46:05 RP: LC_* is not set, but LANG=C Aug 03 16:47:00 ensc|w: I suspect its still finding utf-8 somehow. Trouble is some of this is also dependent on distro patches and setup :/ Aug 03 16:47:33 ensc|w: I was very reluctant to use en_US but in the end it was the only way to work on a decent spectrum of distros :( Aug 03 16:54:50 RP: I am pretty sure that locale stays C; all the sanity checks triggered and had to be removed ;) 'ps wwwwe' shows an utf-8 free environment too Aug 03 16:55:38 I will run builds on non-fedora systems and see whether problems happen there... Aug 03 18:51:03 for what it is worth, I understand now why config files don't make it to the sysroot, it seems to be a "feature" only headers and libraries are installed there and not the complete package.... **** ENDING LOGGING AT Thu Aug 04 02:59:58 2016