**** BEGIN LOGGING AT Mon Dec 07 02:59:58 2015 Dec 07 05:50:57 morning all Dec 07 10:36:52 hi Dec 07 10:40:31 I have a recipe wich inherit from cmake. I'd like to add c++ headers in the -dev package. With cmake I can put headers in usr/include// but then bitbake tells me that this directory (and all .h in it) are not shipped. Dec 07 10:41:08 I'd like to avoid a FILES_${PN}-dev += "${includedir}/*" or something close Dec 07 10:45:25 I saw that the recipe (poky) to build taglib inherit from cmake and include headers in their -dev package. But I don't see how they succeeded. Does someone know how to ship directly headers? Dec 07 14:22:05 damnit! Dec 07 14:30:21 say i build two different versions of a package that only differ in a (runtime) configuration file. what's the recommended approach to avoid having to build the package twice? Dec 07 14:31:17 i guess one approach would be to install different configuration files in do_install. is there a way to do that without rerunning earlier steps? Dec 07 14:31:58 i'm being a bit vague deliberately. not sure if it's even worth the trouble. Dec 07 14:32:40 bit vague as in i might be approaching things wrong in the first place :) Dec 07 16:12:50 hello, are there any plans/examples of embedded pypy support in yocto? Dec 07 16:20:56 outch ! Dec 07 16:21:13 bang Dec 07 16:23:44 hello, are there any examples/plans for embedded pypy support? Dec 07 16:26:07 huh, a pile of builds failed at the same time Dec 07 16:26:29 oh, right Dec 07 16:26:30 whoops Dec 07 16:42:10 joshuagl: do you plan to backport libgudev to jethro or will you take my gst-* patches to fix builds without gudev? Dec 07 17:03:15 rburton: I'm testing latest tune changes with scripts/tune/test.sh script http://git.openembedded.org/openembedded-core-contrib/log/?h=jansa/tune2-test and even when the found issues probably aren't caused by one of my changes, there will be some follow-up fixes Dec 07 17:04:00 JaMa: ok, they're in mut now. shall i remove them, or can the fixes follow in later? Dec 07 17:06:15 did you include all of them or just some? Dec 07 17:07:03 moin Dec 07 17:07:39 Testing DEFAULTTUNE armv7at-neon (48/78) for fake MACHINE fake-thunderx (11/44) Dec 07 17:08:17 using memres bitbake for this test is couple orders faster :) Dec 07 17:56:40 * armpit fake-thunderX.... made me laugh Dec 07 18:33:09 Those should have been caught really early on in the design Dec 07 18:42:15 otavio: http://errors.yoctoproject.org/Errors/Details/22213/ <— lttng-modules fail :( Dec 07 19:01:47 whois RP Dec 07 19:01:57 (missing / ooops) Dec 07 19:14:08 * paulg figures RP better be RP. :) Dec 07 19:15:07 whois tells you if the person is active and/or in the current chennl Dec 07 19:15:23 i.e.: whois fray Dec 07 19:15:24 : idle : 0 hours 0 mins 6 secs (signon: Mon Nov 30 12:48:52 2015) Dec 07 19:22:40 Just ran into a failure due to a recipe obeying TUNE_CCARGS directly rather than via HOST_CC_ARCH. It'd be nice to exert some more control over what vars can be referenced from where Dec 07 19:22:49 * kergoth ponders Dec 07 19:35:29 * fray decides building for 'qemux86-84' isn't going to work too well, and picks a more proper name.. ;) Dec 07 19:35:54 ...and 5 minutes stairing at it trying to figure out why it wasn't working Dec 07 19:36:22 * kergoth chuckles Dec 07 19:36:35 shouldn't it fail early given the machine was invalid? Dec 07 19:37:02 comedy of errors colluded to giving me a bad tune as well as some python exceptions.. Dec 07 19:37:14 it DID say somewhere in the message set about the machine,b ut it was burried in the other crap Dec 07 19:37:25 so of course I thought it was the other crap causing the bad machine.. ;) Dec 07 19:37:44 ugh Dec 07 19:37:46 hate it when that happens Dec 07 21:47:20 kergoth: you understand -S right Dec 07 21:47:47 for the most part, yes Dec 07 21:47:49 * kergoth wonders whatever happened to the auto-dbg packaging bits Dec 07 21:48:11 oh yes, RP mentioned that to me on friday Dec 07 21:48:15 we have competing branches :) Dec 07 21:49:07 kergoth: i was hoping 'bitbake world -S none ; git checkout foo ; bitbake world -S printdiff' would show me the differences in metadata introduced by foo Dec 07 21:49:19 but its spending its time moaning on about various stupid things Dec 07 21:49:28 rburton, fi you are inclined, see the patch I just sent to oe-core.. :P This turned into a real problem for us on mingw32 Dec 07 21:49:44 a core-image-minimal toolchain for qemux86-64 went from a few hundred MB, to 1.6 GB.. Dec 07 21:50:01 almost all of the size difference is attributable to the original change.. Dec 07 21:50:01 ha Dec 07 21:50:08 rburton: the thing to remember is that -S printdiff will check both SSTATE_DIR and STAMPS_DIR. the former is a "find the sstates which are closest to the things we want to build, then compare those to the present" Dec 07 21:50:23 but if all you want to do is an equivalent of bitbake-whatchanged, thats overkill and not at all what you're looking for Dec 07 21:50:31 it's all cause windows doesn't have a concept of symlinks.. so tar, winzip, etc will simply duplicate code for each symlink.. Dec 07 21:50:37 kergoth: yeah whatchanged but without the actual build Dec 07 21:50:41 so i advise overriding SSTATE_DIR to an empty directory if you're wanting to do something like what you're wanting Dec 07 21:50:45 having a dozen unnecessary symlinks to toolchains that ren't actually builtis a problem Dec 07 21:50:46 righto Dec 07 21:50:51 that way it only examines STAMPS_DIR and doesn't check sstate at all (theres' nothing to check) Dec 07 21:50:59 should get better results that way Dec 07 21:51:07 admittedly i've never messed with world, but it should work fine afaik Dec 07 21:51:18 'universe' is way more fun then world.. ;) Dec 07 21:51:22 hehe Dec 07 21:51:25 i always forget about that one Dec 07 21:51:36 it's a great way to see the strangest failures.. Dec 07 21:51:43 oh, that reminds me. bitbake-whatchanged is now of limited usefulness, it modifies STAMPS_DIR, and now STAMPS_DIR ends up in the checksums Dec 07 21:51:49 so it cluters up the output with those changes Dec 07 21:51:51 clutters, even Dec 07 21:51:56 that seems to be less then optimal Dec 07 21:52:00 indeed Dec 07 21:52:14 erm yeah patch or bug please :) Dec 07 21:52:45 kergoth: so set SSTATE_DIR to /my/empty/dir ; git checkout works ; bitbake world -S none ; git checkout broken ; bitbake world -S printdiff? Dec 07 21:53:43 yep Dec 07 21:54:14 * rburton tries Dec 07 21:57:30 hmph still not working Dec 07 21:57:43 Task xserver-xf86-config:do_fetch couldn't be used from the cache because: Dec 07 21:57:43 We need hash 2a5ddaed8367faf79ca990a978b1a00c, closest matching task was f31bb145eb335d6bb07a8b4167c76acc Dec 07 21:57:43 Checksum for file xorg.conf changed from d41d8cd98f00b204e9800998ecf8427e to c6d249b6c47777305afbc33a299d831b Dec 07 21:57:44 lies Dec 07 21:57:57 my diff is just a change to the packageconfig logic Dec 07 21:58:44 hmm, that's odd. remnants in STAMPS_DIR? wipe tmp before the -S none? Dec 07 21:58:49 * kergoth shrugs Dec 07 21:58:50 yeah maybe Dec 07 22:01:49 Hi, I have a quick question. Does Yocto have any tools that will synchronize an SDK across multiple workstations? Dec 07 22:01:58 kergoth: still bust :/ Dec 07 22:02:20 hmm, really odd. try bitbake-whatchanged and grep out the stamps_dir change delta? Dec 07 22:11:52 adtec: not with the standard SDK; the extensible SDK (which is effectively in beta in 2.0) provides the ability to update an existing install to a newer published version Dec 07 22:11:58 kergoth: looks like i really need a build at some point Dec 07 22:15:55 bluelightning: Thank's for the info! Do you know if there is a release date set? Dec 07 22:16:16 adtec: well, it's already in the 2.0 release Dec 07 22:16:41 bluelightning: Oh, good point. I will have to check it out then! Dec 07 22:17:11 unfortunately we're a bit short on documentation Dec 07 22:17:25 but briefly building it is as simple as bitbake -c populate_sdk_ext Dec 07 22:18:11 to publish it so you can upgrade from it you run oe-publish-sdk /path/to/sdk/installer.sh /path/to/http/shared/directory Dec 07 22:18:29 then from each installed instance you run devtool sdk-update Dec 07 22:18:56 you can have the server URL pre-set in the installed SDK by setting SDK_UPDATE_URL when you build the ext SDK Dec 07 22:20:02 Very interesting. I've been reading up on Puppet and Chef automation tools, but it would be nice to keep everything under Yocto. Dec 07 22:22:05 rburton: hmm, that shouldn't be necessary, must be a bug somewhere Dec 07 22:52:45 hm Dec 07 22:53:01 replacing libjpeg with jpeg-turbo means debian-named packages go backwards in version Dec 07 22:53:25 lilbjpeg_9a -> libjpeg_8d+1.4.4 Dec 07 22:53:41 don't really want to epoch it Dec 07 23:08:58 should see how debian does it. they use libjpeg-turbo by default iirc (as does every other major distro afaikO), could see how the migration was handled Dec 07 23:33:19 kergoth: we have been using libjpeg-turbo Dec 07 23:33:30 what issues do u see ? Dec 07 23:34:34 none, look above to rburton's comment Dec 07 23:34:56 I signed in late Dec 07 23:39:32 kergoth: we need to beat up the printdiff logic so it works :/ Dec 07 23:40:01 kergoth: I had various ideas I was testing like preferring dates. Having an ability to ignore the sstate mirrors also sounds desirable Dec 07 23:50:48 RP: howdy Dec 07 23:51:06 RP: I was reading through yuor email about autotools Dec 07 23:51:43 There was a study done by Electric Fence on OE and they report that we spend about 25-30% time in confgure step Dec 07 23:52:29 one approach could be to use caches input to configure and not reconfigure at all Dec 07 23:52:53 this would make the builds more reproducible as well Dec 07 23:55:49 khem`: I've wondered about that. The caches actually buy very little in most cases from what I've see Dec 07 23:56:22 khem`: Not running autoreconf but say patching instead sounds good until you try and figure out the details in practise. I'm sure it could be done though. Dec 07 23:56:49 RP: yes practically it could be a hard nut Dec 07 23:56:51 khem`: FWIW I have a few more interesting findings coming, particularly in that limiting configure to a single CPU core seems to help a lot from a cache trash perspective Dec 07 23:57:10 I look at it as a same features being config'ed in and out on all builds Dec 07 23:57:16 khem`: I just posted on LKML today asking questions too. No answers yet though :/ Dec 07 23:57:25 makes it good we might loose flexibility Dec 07 23:58:02 oh so pinning it to single CPU is better ? Dec 07 23:58:04 khem`: I can't help shake the feeling this usecase is exposing some nasty issue in the kernel :/ Dec 07 23:58:08 khem`: massively Dec 07 23:58:22 huh, interesting Dec 07 23:58:25 hmm smells like scheduler Dec 07 23:58:37 khem`: Its dcache loads Dec 07 23:58:39 RP: did you try different distros ? Dec 07 23:58:53 khem`: no, I have tried rebuilding kernels and playing though Dec 07 23:59:17 * RP needs to write the next performance post... Dec 08 00:00:40 khem`: feels like there is still something else to though, that might be scheduler. Or something in the pipe handling/process teardown Dec 08 00:01:05 khem`: btw rburton's comment earlier was about versions going backwards for debian renaming in the switch from libjpeg to libjpeg-turbo: [15:53:25] lilbjpeg_9a -> libjpeg_8d+1.4.4 Dec 08 00:02:49 * kergoth ponders Dec 08 00:03:27 I wonder if anyone else does full linux system / distro rebuilds the way we do, other than other embedded projects like buildroot. i.e. the desktop distros Dec 08 00:05:08 RP: if you have configed kernels then try to change default scheduler Dec 08 00:05:13 and see if that changes some params Dec 08 00:06:02 build loads may be a special case for kernel tuning now a days Dec 08 00:07:23 khem`: There is basically one scheduler these days, I did try changing some of the parameters in sysctl and also at compile time like START_DEBIT Dec 08 00:12:08 kergoth: I am doing bitbake -k world on nios2 now and then, does it count ? **** ENDING LOGGING AT Tue Dec 08 03:00:17 2015