**** BEGIN LOGGING AT Thu Aug 07 02:59:58 2014 Aug 07 03:16:58 JaMa: thanks for that, good to know you aren't perfect... Aug 07 03:17:03 ;) Aug 07 05:56:58 so you slipped by this time... Aug 07 08:50:43 morning all Aug 07 08:51:29 morning Aug 07 09:25:21 hi bl Aug 07 10:20:07 hi woglinde Aug 07 10:48:46 JaMa: building nodistro + meta-oe I've got Aug 07 10:48:48 NOTE: multiple providers are available for jpeg (jpeg, libjpeg-turbo) Aug 07 10:48:48 NOTE: consider defining a PREFERRED_PROVIDER entry to match jpeg Aug 07 10:49:11 worth to add one default provider for nodistro? Aug 07 10:49:12 ant_work: there's nothing that can be done about that Aug 07 10:49:33 I see pending libjpeg commits, that's why I sort out the issue Aug 07 10:50:09 if you add layers, you're going to get situations like this; you just need to make the selection as it recommends Aug 07 10:50:36 I think a line in default_providers.inc would solve Aug 07 10:51:18 as for bluez Aug 07 10:51:19 it would solve it yes, but should that be making selections based on something in another completely separate layer? Aug 07 10:51:42 no, it should prefer what is in oe-core ofc Aug 07 10:52:18 still doesn't seem right to me Aug 07 10:53:16 how did the 'Distro's' handle the transition? It's anything new afaik Aug 07 10:53:42 yes but there those distros expect to have meta-oe and therefore they must make a selection Aug 07 10:54:02 see. Gentoo: libjpeg-turbo is the new default JPEG implementation Aug 07 10:54:57 2 years ago Aug 07 10:55:36 fo the distros based on meta-oe, well they just declare their P_Providers Aug 07 10:55:55 obviously the ideal situation would be if there was no selection at all, i.e. we didn't have two recipes Aug 07 10:56:46 not sure how realistic that would be though Aug 07 10:58:37 JaMa: I can't seem to reproduce the failure with boost, however I have found how to stop it looking for boost altogether (which I think is the right thing to do, it only needs it for the oqgraph storage engine which we probably don't want to have on by default) Aug 07 11:17:34 hello all Aug 07 11:18:09 may be its really a dump question but does anybody know whoch package creates /etc/exports file on first boot Aug 07 11:18:23 with systemd emabled Aug 07 11:18:28 enabled Aug 07 11:35:48 ant_work: that's there for ages Aug 07 11:36:34 bluelightning: I'll test if it fixes my build issue when you send v2, have you also fixed readline dependency? Aug 07 11:36:40 eyebleed Aug 07 11:36:49 yes, it's long Aug 07 11:36:58 time to fix it? Aug 07 11:37:33 sane distros probably did already Aug 07 11:37:47 I care about default as you know Aug 07 11:38:23 atm meta-oe is 'toxic' Aug 07 11:38:25 sigh Aug 07 11:38:49 hmm Aug 07 11:45:36 JaMa: I have yes, I've just added that to DEPENDS Aug 07 11:48:35 JaMa: bluelightning: seems SuSE and Fedora already switched to jpeg-turbo Aug 07 11:48:38 http://debian.2.n7.nabble.com/jpeg8-vs-jpeg-turbo-td2921094.html Aug 07 11:49:08 (this was last year, still reading last posts ;) Aug 07 11:51:30 JaMa: I just noticed it is looking for libaio as well, just trying to figure out what to do with that Aug 07 15:13:54 I know this question came up a few weeks ago, but I can't find the response.. Aug 07 15:14:14 I've got a customer who is making a small change to the glibc recipe and wants to AVOID having everything in the system rebuild.. Aug 07 15:14:40 is there a way to tell the system to ignore the change (for the chksum) for the task or overall glibc? Aug 07 15:22:29 fray_: not in simple and reliable way AFAIK Aug 07 15:22:48 Hmm.. for some reason I thought you could just say "here use this as the hash" Aug 07 15:22:53 fray_: some ideas are in https://bugzilla.yoctoproject.org/show_bug.cgi?id=5970 Aug 07 15:23:08 just want to void the 'rebuild everything' cycle to test.. the production builds wouldn't do that Aug 07 15:23:19 there was RFC about locked sstate from RP, but I think that the changes weren't merged yet Aug 07 15:23:55 ya.. I've seen those patches.. that could be part of the solution.. (I've got others that I think one of my engineers has or will be sending) that triggers an error if something IS going to be built from source.. Aug 07 15:23:57 that sounds like exactly what locked sstate is intended to let you do, indeed Aug 07 15:24:13 (we've got customers who want to prevent rebuilds, unless authorized) Aug 07 15:24:22 the error one hit the list already, was looking those over yesterday, looks useful Aug 07 15:24:25 but in this case it's a bit vice versa IMHO Aug 07 15:24:28 good Aug 07 15:24:32 yup Aug 07 15:24:48 locked sstate will allow you to easily continue using the old glibc sstate when the metadata were changed Aug 07 15:24:55 unless you lock everything except glibc Aug 07 15:25:22 ya.. catch is we want to use the 'new' glibc, and 'old' everything else.. (just to speed of the debug cycle) Aug 07 15:25:31 since we're not changing headers, or APIs.. that should be fine.. Aug 07 15:25:32 and this week there was patchset about read-only sstate which can be another part of puzzle Aug 07 15:25:46 ya, thats the one from us I think.. Aug 07 15:25:56 yes :) Aug 07 15:29:24 I wonder (as a local hack) if I can just write something that injects a locally defined 'hash'.. Aug 07 15:29:56 then if set it can remain constant for other recipes... Aug 07 16:46:33 * darknighte -current gets up to stretch legs Aug 08 02:51:28 * khem is seeing if darknighte is still stretched **** ENDING LOGGING AT Fri Aug 08 02:59:59 2014