**** BEGIN LOGGING AT Wed Feb 16 02:59:57 2011 Feb 16 03:01:41 03Tom Rini  07org.openembedded.dev * r2d615a19a6 10openembedded.git/recipes/linux/linux-2.6.30/at91/ (3 files): Feb 16 03:01:41 Revert "Remove some patches, which was moved by previous linux patch" Feb 16 03:01:41 I pulled this patch in prematurely which broke the at91 machines, Feb 16 03:01:41 so back this out. Sorry folks! Feb 16 03:01:41 This reverts commit cfa8a2a8b291cb0a3426a3120ce31e6e74970e37. Feb 16 05:11:21 03Tom Rini  07org.openembedded.dev * r3123b4d1cf 10openembedded.git/recipes/tasks/task-qt4-x11.bb: Feb 16 05:11:21 task-qt4-x11: Move libqtxmlpatterns4 to RRECOMMENDS Feb 16 05:11:21 Fixes qt4 4.6.x images. Feb 16 05:11:21 Signed-off-by: Tom Rini Feb 16 05:11:23 03Tom Rini  07org.openembedded.dev * r295db8cb3f 10openembedded.git/recipes/ (images/qt4e-base-image.bb tasks/task-qt4e.bb): Feb 16 05:11:23 qt4e-demo-image: Switch to using task-qt4e.bb Feb 16 05:11:23 In task-qt4e.bb put the xmlpatterns bits in RRECOMMENDS for QT 4.6.x Feb 16 05:11:23 Signed-off-by: Tom Rini Feb 16 07:31:52 Jay7: was afk yesterday evening, thanks for fixing the oestats thingie Feb 16 07:32:03 & gm everyone Feb 16 07:35:35 good morning Feb 16 07:45:09 03Martin Jansa  07master * ree63bd5d2e 10openembedded.git/recipes/tasks/task-base.bb: Feb 16 07:45:10 task-base: bump PR to pick changes from nokia900.conf Feb 16 07:45:10 * lack of coffee made me thing that MACHINE_KERNEL_PR bump in Feb 16 07:45:10 648bd1c785fae9de66001dc588720366b9ebda2c is what I need, sorry for Feb 16 07:45:10 that Feb 16 07:45:10 Signed-off-by: Martin Jansa Feb 16 08:43:14 morning Feb 16 08:59:20 morning Feb 16 08:59:41 sh#t :( my buildhost hangs this night Feb 16 09:00:10 bummers Feb 16 09:03:44 Jay7: until yesterday the lenght of failure logs on tinderox could not exceed 24kb. Is it wanted limit? see http://tinderbox.openembedded.net/public/logs/task/25563737.txt Feb 16 09:04:33 ant_work: no, but I didn't changed anything about this.. Feb 16 09:04:57 ka6sox: haven't you limit on POST size anywhere? Feb 16 09:05:30 size? not seen one... Feb 16 09:05:34 ok Feb 16 09:05:53 but large number of small POSTS are difficult on server Feb 16 09:05:59 much better to batch results Feb 16 09:06:01 yes, I know.. Feb 16 09:06:15 but lets say for only 1 recipe in a build Feb 16 09:06:17 then send Feb 16 09:06:47 it's a bit hard to catch Feb 16 09:07:00 easier to put all data after build Feb 16 09:07:13 for entire distro that would be hard Feb 16 09:07:21 can you separate by package? Feb 16 09:07:26 then send by package? Feb 16 09:07:29 well.. may be you are right Feb 16 09:07:55 there is no 'package processed' event in bitbake as far I know Feb 16 09:07:57 I would rather not see 5MB of data all @ 1 time Feb 16 09:08:01 task and build Feb 16 09:08:38 no milestones of packages built..even so they are staged? Feb 16 09:09:24 it should be possible to catch by latest package task Feb 16 09:10:03 do_package iirc Feb 16 09:10:07 I would think that monitoring the log output you would catch start of package build task. Feb 16 09:10:10 right Feb 16 09:10:26 do_package does have some debuggging output I've seen. Feb 16 09:10:30 but there is do_rootfs for images Feb 16 09:10:31 hey ka6sox are you on oe-devel? Feb 16 09:10:42 XorA|gone, yep Feb 16 09:11:01 ka6sox: you never commented on my emails about wiki.openembedded.net being broken for captcha Feb 16 09:11:05 ka6sox: we should ask kergoth or RP about best way Feb 16 09:11:09 ka6sox: its very confusing Feb 16 09:11:26 XorA|gone, I did...here but you missed them... Feb 16 09:11:39 you shouldn't have been on the list you were on Feb 16 09:11:43 that is fixed Feb 16 09:11:50 last thursday your time. Feb 16 09:11:54 ka6sox: ah, right, cool, yeah Ive been on hols and in Japan working at moment Feb 16 09:12:04 ah... Feb 16 09:12:23 I was driving to San Francisco fixing it. Feb 16 09:12:33 ka6sox: dont drive and code :-D Feb 16 09:12:52 no, I asked the DBA and wikimaster to fix it :D Feb 16 09:13:03 hehe Feb 16 09:13:05 best way Feb 16 09:13:14 ya, thats their baby... Feb 16 09:13:26 now to add varnish and make it run real smooth Feb 16 09:13:35 not teflon? Feb 16 09:14:07 there are like 10 ways to do it...we started with varnish and it works. Feb 16 09:14:25 just coat your shoulders in teflon then Feb 16 09:14:34 I have 21 mediawiki with varnish Feb 16 09:14:44 15 on one server Feb 16 09:15:37 if it really becomes a problem I'll do something about caching the php Feb 16 09:15:38 * Jay7 like typo3 because you may have one codebase for all sites Feb 16 09:16:07 qt4-embedded_4.7.1.bb do_configure failed Feb 16 09:16:17 Jay7, the 15 mediawiki is 1 codebase symlinked Feb 16 09:16:28 why my qt4-embedded_4.7.1 build requires mysql5_5.1.40 ? Feb 16 09:16:31 ka6sox: that's right :) Feb 16 09:18:19 * XorA|gone has much more fun with Alfresco than mediawiki :-D Feb 16 09:19:19 * Jay7 prefers dokuwiki for small-sized wikis Feb 16 09:19:39 OE's one is small-sized :) Feb 16 09:21:27 there are a lot of good projects out there. Feb 16 10:21:27 * pb_ stabs microchip Feb 16 10:21:31 poxy pic icsp interface Feb 16 10:24:34 How is gcc tests going? Feb 16 10:25:45 slowly.. Feb 16 10:25:59 otavio: khem reverted his patch from master Feb 16 10:26:11 my buildhost hangs tonight Feb 16 10:26:23 Right. My build still fails using minimal Feb 16 10:26:25 :-( Feb 16 10:26:41 so I'm restarting now only ben-nanonote builds Feb 16 10:27:17 angstrom-2010.x/collie was successfull Feb 16 10:28:48 pb_, I stopped using it years ago....wierdest risc thing I've ever used Feb 16 10:32:39 yeah, the instruction set is a bit funky. I prefer AVR normally but in this case the comparable atmel parts were way more expensive. Feb 16 10:33:07 pic12f1822 is actually quite a cool chip, you get hardware uart, hardware i2c/spi, temperature sensor, capsense and a bunch of other stuff for about $0.50. Feb 16 10:33:22 only problem is that I can't erase the flash :-} Feb 16 10:34:11 pb_: gamma rays ? neutron beam? vodoo? Feb 16 10:34:16 doesn't help. all the stuff I used to programme on is "legacy" Feb 16 10:34:43 ant_work, neutrinos Feb 16 10:35:01 oh, Higg's boson, yes Feb 16 10:35:43 we had to glue tantalum meta top and bottom of RAM chips because we couldn't afford space grade RAM. Feb 16 10:35:56 s/meta/metal. Feb 16 10:36:09 and 12bits to get 8 good ones. Feb 16 10:39:28 pb_, that is a lot of value for a small price. Feb 16 10:39:33 good luck Feb 16 10:43:55 eFfeM_work: Hello Feb 16 10:44:31 eFfeM_work: I received your reply about the pull request. Feb 16 10:57:29 Nothing like a good OE build to warm up the place :D Feb 16 11:00:16 Philippe: lol Feb 16 11:02:14 oc Feb 16 11:02:30 it is -28 outside here, so all little bits help Feb 16 11:03:48 Philippe: -28 ! where are you? Feb 16 11:05:34 otavio: ok; for reviewing git pull is not that convenient (or I am too git n00bish) Feb 16 11:05:43 mckoan, Finland Feb 16 11:05:59 eFfeM_work: no problem. I can set my SMTP to send the mails Feb 16 11:06:17 eFfeM_work: but did you checked the changes? Feb 16 11:06:46 nope, saw your mail, but can't easily access the git stuff (or don't know how to do so easily) Feb 16 11:06:51 eFfeM_work: about cups 1.4.6 I can do really soon, just after merging it. Feb 16 11:07:00 otavio: great Feb 16 11:07:17 eFfeM_work: did you get the link? Feb 16 11:07:25 for git, yes Feb 16 11:07:34 eFfeM_work: I am with problems to push from here ... Feb 16 11:07:46 eFfeM_work: so if you can merge what seems OK for you, it would be nice. Feb 16 11:07:49 is git send-email an option for you ? Feb 16 11:07:56 eFfeM_work: it can be Feb 16 11:08:03 eFfeM_work: I need to setup it only Feb 16 11:08:34 can't do too much form work anyway (and tonight I am performing a social duty I agreed on two years ago ;-) ) Feb 16 11:10:06 eFfeM_work: ahah OK :-) Feb 16 11:10:12 eFfeM_work: so it is a no-go for today Feb 16 11:10:15 eFfeM_work: no problem Feb 16 11:13:31 probably; if the changes are mailed anyone can pick it up (and I can review and ack from here; that is something I typically do while a build is running) Feb 16 11:15:33 eFfeM_work: OK Feb 16 11:15:36 eFfeM_work: will send them Feb 16 11:19:45 eFfeM_work: sending them all Feb 16 12:09:41 03Mario Schuknecht  07org.openembedded.dev * r37832a3474 10openembedded.git/recipes/linux/ (linux-2.6.24/hipox/hipox-phy.patch linux_2.6.24.bb): Feb 16 12:09:41 linux-2.6.24: phy handling fixed for hipox machine Feb 16 12:09:41 * phy switching enabled Feb 16 12:09:41 * link status handling fixed Feb 16 12:09:41 Signed-off-by: Mario Schuknecht Feb 16 12:09:41 Acked-by: Steffen Sledz Feb 16 13:02:19 I'm having trouble adding libnet-dev to my SDK, it comes up with "satisfy_dependencies_for: Cannot satisfy the following dependencies... libnet *", is there any way I can see what is the dependancy it's worried about. Feb 16 13:22:05 ERROR: QA Issue with libgettextlib: package libgettextlib contains bad RPATH...gettext_0.18.bb Feb 16 13:22:12 any clue? Feb 16 14:30:53 mckoan: i have the exact problem Feb 16 14:35:48 martinmeba: I'm rebuilding but I guess it will be the same Feb 16 14:35:53 yeah Feb 16 14:36:00 i think it started in the last few days Feb 16 14:36:19 because QA check was enabled and later fixed.. Feb 16 14:36:21 martinmeba: yes, sure. I wonder who introduced such error Feb 16 14:37:20 see [PATCH] insane.bbclass: fix the check for bad RPATH Feb 16 14:39:10 Yes Feb 16 14:39:16 So we need to fix the RPATH issue, if possible Feb 16 14:40:56 so patch/456 ? Feb 16 14:40:57 poky may be of use here Feb 16 14:41:25 No, that patch made the RPATH erors be fatal Feb 16 14:41:34 JaMa posted a patch i thought to make it not fatal, for now Feb 16 14:41:41 But I mean we should fix the actual QA error that shows Feb 16 14:42:53 ie for the db one, maybe we just update to 5.1.19 like poky did, since it's backwards compat Feb 16 14:43:01 and apparently doesn't have the problem Feb 16 14:44:20 martinmeba: 573 makes it not fatal, but as Tartarus said use it only if you need to build it quick, otherwise better to fix the issue Feb 16 14:44:32 yeah Feb 16 14:44:39 i think i need to build it quick Feb 16 14:44:55 i need to let a unit soak in a thermal chamber and everything just broke Feb 16 14:45:50 what about reverting the patch that cause it? Feb 16 14:46:10 mckoan: yes - that is probably best Feb 16 14:47:04 03Otavio Salvador  07master * r48ee8fa099 10openembedded.git/recipes/cdparanoia/cdparanoia_svn.bb: Feb 16 14:47:04 cdparanoia (svn): use build variables to fix packaging when using empty prefix Feb 16 14:47:04 Signed-off-by: Otavio Salvador Feb 16 14:47:04 Signed-off-by: Frans Meulenbroeks Feb 16 14:48:04 definitely would be, at least until the whole implication is solved Feb 16 14:49:04 mckoan: that's actually worst solution Feb 16 14:49:12 Well, yeah, what jaMa said Feb 16 14:49:15 We have problems Feb 16 14:49:18 mckoan: that error will still be there Feb 16 14:49:20 We shouldn't mask them Feb 16 14:49:25 We have time to fix them Feb 16 14:49:28 Lets fix them Feb 16 14:49:39 And look at poky when needed since they've had that check for a while Feb 16 14:49:48 mckoan: best _temporary_ solution is _show_ it, but not fatal (like 573 does) Feb 16 14:50:01 I haven't the foggiest idea about how to solve it Feb 16 14:50:04 mckoan: hidding that problem from log won't help anyone and nobody will fix it Feb 16 14:50:19 mckoan: than pw-am.sh 573 is for you Feb 16 14:50:48 I guess I will have to raise my hand and say I don't know where to start Feb 16 14:51:51 khem fixed this in binutils the th patch is noisy, heh Feb 16 14:52:10 martinmeba: let's do this tricky stuff Feb 16 14:52:10 he fixed it also in python-sqlite Feb 16 14:52:18 martinmeba: contrib/patchwork/pw-am.sh 573 Feb 16 14:52:32 http://pastebin.com/wy4sepAe Feb 16 14:53:30 mckoan: thanks Feb 16 14:56:41 my lousy external compiler was choking on a file in gnutls (easy to workaround) and now libtiff. was there any well known issue with earlier gcc's failing to do sysroot properly, especially around libtool? Feb 16 14:57:46 google hit on several things. I just don't understand how I'm passing --sysroot= on almost every line, but it's still looking in the default sysroot instead of the OE staging dir Feb 16 15:16:58 so with patch 573, I also get QA errors in gnutils, tiff, acl Feb 16 15:21:55 also neon, gnome-vfs-plugin, schroedinger, libcdio++, libiso9660++ Feb 16 15:22:47 martinmeba: but your build continues, right? Feb 16 15:22:51 yes Feb 16 15:32:03 eFfeM_work: you pushed only one of the patches? Feb 16 15:35:59 martinmeba: what about to roll-back to a stable version? -2 days Feb 16 15:38:23 * mckoan alway take note about working versions (his own tagging method) http://www.kaeilos.com/latest-changes Feb 16 15:38:36 git reset --hard 6a97f8c4f99330848b8dbe7e54b3560eceb486c8 Feb 16 15:39:12 martinmeba: if you are in a hurry Feb 16 15:39:42 mckoan: thanks Feb 16 15:41:02 mckoan: did you read what I said :/ Feb 16 15:43:01 JaMa|Off: about hiding/ignoring the problem? yes Feb 16 15:45:19 then in what aspect is " stable version? -2 days" better than current head + 573? Feb 16 15:46:29 JaMa|Off: I don't know, I read martinmeba comment about further problems, sorry :-) Feb 16 15:47:17 I perfectly understand his feelings, some time happens that you have no time to dig in the code Feb 16 15:48:39 after his sudden crisis, he/we could go ahead solving the problem ;-) Feb 16 15:50:38 otavio: I pushed cdparanoia; I felt quite comfortable with that one and as I am listed as maintainer for that version I felt quite comfortable pushing it Feb 16 15:52:56 otavio: wrt e.g. sdk.bbclass: our policy requires two acks for it (and frankly atm I cannot really review it); cmake probably too, and for some of the other things these are recipes where I have no knowledge about; I've added acks for the ones I feel they are ok (and if there is a 2nd ack I'm happy to push them). Feb 16 15:54:41 need to leave now, later.... Feb 16 16:15:00 well as far as I can tell the problem isn't libpcap which is the only dependancy libnet lists in the .bb file Feb 16 16:16:09 is I bitbake libnet on it's own every thing is fine, so why can't I add it to the SDK? Feb 16 16:42:09 otavio, khem: my builds of angstrom-2010 and minimal for ben-nanonote (mipsel) was fine Feb 16 16:45:33 Jay7: even sdk? Feb 16 16:45:39 khem: mine keeps failing Feb 16 16:46:06 otavio: no, console-image, x11-image, opie-image Feb 16 16:46:23 otavio: did you mean native-sdk-image? Feb 16 16:46:35 meta-toolchain Feb 16 16:46:39 ah Feb 16 16:46:48 well.. I can test it later Feb 16 16:48:43 otavio: started Feb 16 16:54:05 Jay7: nice Feb 16 16:54:17 Jay7: so we will know if it fails just for me or for you too Feb 16 16:56:48 03Martin Jansa  07master * r28637f3e90 10openembedded.git/recipes/openmoko-3rdparty/ (openmoko-gps_0.0.1+svnr9.bb openmoko-gps_svn.bb): Feb 16 16:56:48 openmoko-gps: bump SRCREV, fix QA issues, fix hardcoded path, use bindir/datadir and rename recipe Feb 16 16:56:48 Signed-off-by: Martin Jansa Feb 16 16:56:49 03Martin Jansa  07master * r97240c982e 10openembedded.git/recipes/mokoeightball/ (files/fixpath.patch mokoeightball_svn.bb): Feb 16 16:56:49 mokoeightball: fix hardcoded paths and QA issues Feb 16 16:56:49 Signed-off-by: Martin Jansa Feb 16 16:58:30 hi JaMa|Off Feb 16 16:58:33 ah you're off Feb 16 16:58:42 JaMa|Off, ping me when you're not off anymore Feb 16 16:58:49 GNUtoo|laptop: just arrived Feb 16 16:59:10 JaMa, ok, what should we do to reguards to -ggdb in SHR Feb 16 16:59:15 I want to be able to debug FSO Feb 16 16:59:27 so we need some compilation flags for debuggings Feb 16 16:59:46 How bug debugging? Feb 16 16:59:51 what's wrong with -dbg packages? Feb 16 16:59:56 Stepping into libc too or no? Feb 16 17:00:07 JaMa, without -ggdb -dbg packages aren't helpful really Feb 16 17:00:51 don't need -ggdb, -g is sufficient, unless the compiler defaults are strange Feb 16 17:00:59 Well, ok, also true Feb 16 17:01:02 But we don't do -g Feb 16 17:01:07 (A change from poky) Feb 16 17:01:23 JaMa, they don't have debugging symbols: Feb 16 17:01:32 (advantage of -g over -ggdb is that if the debug format changes in the system you don't have to go and update it everywhere) Feb 16 17:02:00 anything lacking debug symbols should be caught and a warning issued IMHO.. -dbg packages are incredibly important for any device that goes into the field Feb 16 17:02:05 Tartarus: ah I thought that sane-toolchain-eglibc.inc had -ggdb Feb 16 17:02:13 JaMa, nope Feb 16 17:02:17 angstrom does Feb 16 17:02:22 yup reading it now Feb 16 17:02:22 and I swear we used to default to it Feb 16 17:02:26 * Tartarus is got log'ing Feb 16 17:02:31 (recently in Poky I put in an enhancement that added corresponding sources to the -dbg packages.. so you can do debugging on the device or remotely without having your original build tree) Feb 16 17:02:47 nope, I'm crazy Feb 16 17:02:52 JaMa, http://www.pastie.org/1567574 Feb 16 17:03:08 On non-debug builds we default to just -O2 Feb 16 17:03:13 debug builds get -g Feb 16 17:03:23 (and there's minor games being played against *glibc) Feb 16 17:03:27 Tartarus I remember way back when (before OE) -ggdb and such were used in our builds Feb 16 17:03:53 ...way back when... roughly 1998 or so.. ;) Feb 16 17:04:15 heh Feb 16 17:04:30 543f79f0298ff23b03339172e8a2f3f05784495e should still default to -g, no? Feb 16 17:04:31 (hard to believe it's been that long since the PPC Reference releases) Feb 16 17:04:56 JaMa, BUILD_OPTIMIZATION is host run stuff Feb 16 17:05:15 indeed on target no -g Feb 16 17:05:18 that is to say: Feb 16 17:05:28 http://pastebin.com/D7ddkJjM Feb 16 17:05:28 Which also means we have some silliness in sane-toolchain* Feb 16 17:05:33 do you see some -g Feb 16 17:06:08 GNUtoo|laptop, as a local fix, add BUILD_OPTIMIZATION += "-g" (or some other -g variant) Feb 16 17:06:12 er Feb 16 17:06:14 FULL Feb 16 17:06:23 and FULL_OPT_pn-glibc += "-g" too Feb 16 17:06:28 if you want to step into libc stuff Feb 16 17:06:57 yes but could we add that to SHR? Feb 16 17:07:30 Yes, JaMa may want to look at angstrom bits again and maybe we update sane-toolchain* to be a little less silly (and also drop -g from host run tools?) Feb 16 17:07:52 * Tartarus goes back to not procrastinating on something else Feb 16 17:07:54 * JaMa agree that it should be fixed in sane-toolchain Feb 16 17:08:37 * JaMa won't look into it today, need to pack stuff for skiing and leaving in 4 am so want to go to bed early today Feb 16 17:09:03 JaMa, will you look into it at some point? Feb 16 17:09:56 GNUtoo|laptop, you could try too :) angstrom-* gets it right except I think for debug symbols to *glibc (see what I said above for fix), of course khem points out that w/ -fomit-frame-pointers debugging is always sub-optimal Feb 16 17:10:02 really, hiding irc now Feb 16 17:10:43 ok thanks Feb 16 17:10:45 Procrastination is a valuable time-management technique, though. :) Feb 16 17:12:51 I am having issues with the 2008.1 os branch using glibc Feb 16 17:39:02 martinmeba: you have to describe the problem Feb 16 17:39:21 we have not (yet) developed mind reading skills Feb 16 17:44:34 OK, what the heck Feb 16 17:45:02 do_package_qa should show up in *.dot right? Feb 16 17:45:12 (when INHERIT += "insane" of course) Feb 16 18:23:02 hmmm boost has issues Feb 16 18:23:22 ERROR: QA Issue with boost: package boost contains bad RPATH /home/gnutoo/embedded/oe/oetmps/htcdream/sysroots/armv6-novfp-oe-linux-gnueabi/bin in file /home/gnutoo/embedded/oe/oetmps/htcdream/work/armv6-novfp-oe-linux-gnueabi/boost-1.45.0-r9.2/packages-split/boost/usr/lib/libboost_wave.so.1.45.0 Feb 16 18:23:28 is it a bad compiler flag? Feb 16 18:25:24 basically, yes Feb 16 18:26:16 so what would be the fix? Feb 16 18:27:03 So, if I follow things right, stop passing -rpath manually Feb 16 18:27:12 ok Feb 16 18:27:13 * Tartarus doesn't have a good example handy Feb 16 18:27:23 I'll grep for rpath Feb 16 18:29:55 03Martin Jansa  07master * r25eaf1dd9a 10openembedded.git/recipes/gnome/libsoup-2.4_2.33.6.bb: Feb 16 18:29:55 libsoup-2.4: add 2.33.6 version needed for newer webkit-efl Feb 16 18:29:55 Acked-by: Khem Raj Feb 16 18:29:55 Acked-by: Klaus Kurzmann Feb 16 18:29:55 Tested-by: Klaus Kurzmann Feb 16 18:29:56 Signed-off-by: Martin Jansa Feb 16 18:30:07 03Martin Jansa  07master * r8e80816f04 10openembedded.git/recipes/glib-2.0/ (7 files in 2 dirs): Feb 16 18:30:07 glib-2.0: add 2.28.0, needed by newer libsoup Feb 16 18:30:07 Acked-by: Khem Raj Feb 16 18:30:07 Acked-by: Klaus Kurzmann Feb 16 18:30:08 Tested-by: Klaus Kurzmann Feb 16 18:30:08 Signed-off-by: Martin Jansa Feb 16 18:30:09 03Martin Jansa  07master * rf202b0d8a4 10openembedded.git/conf/distro/include/preferred-shr-versions.inc: Feb 16 18:30:10 SHR: drop P_V for glib-2.0 (upgrades from 2.26.1 to 2.28.0) Feb 16 18:30:10 Acked-by: Khem Raj Feb 16 18:30:10 Acked-by: Klaus Kurzmann Feb 16 18:30:11 Tested-by: Klaus Kurzmann Feb 16 18:30:11 Signed-off-by: Martin Jansa Feb 16 18:32:58 khem: I was refering to the earlier part of the discussion about the RPATH issues Feb 16 18:42:42 hi, I'm having problems building a kernel for which I've just written the recipe: http://paste.pocoo.org/show/339796/ Feb 16 18:43:46 something weird's happening, (apart from error) because there's trying to build headers for 2.6.32 headers and kernel is actually 2.6.37 Feb 16 18:46:39 some recipe like glibc unset LDFLAGS Feb 16 18:46:41 I'll try that Feb 16 18:46:49 but I bet I would have GNU Hash issue Feb 16 18:46:56 but I could workarround Feb 16 18:48:57 pespin: if you look in openembedded/conf/distro/angstrom-, you will see a note about the kernel vs. header version Feb 16 18:51:04 martinmeba, ok thanks, so that's not a problem then Feb 16 18:51:22 yeah - probably not Feb 16 18:51:27 ay idea on why are the errors appearing though? Feb 16 18:51:35 i'd have to see your kernel recipe Feb 16 18:51:37 no idea Feb 16 18:53:10 martinmeba, http://paste.pocoo.org/show/339779/ Feb 16 18:55:36 btw, this is the actual log file -> http://paste.pocoo.org/show/339803/ Feb 16 18:56:42 meh Feb 16 18:58:02 pespin: this doesn't look like an issue with your kernel Feb 16 18:58:28 it is blowing up before that Feb 16 18:58:42 martinmeba, machine config maybe? I've done it some minutes ago too Feb 16 18:59:14 i am not sure - I have to run. good luck Feb 16 18:59:38 ok, thanks anyway :) Feb 16 18:59:48 If someone wants to have a look at machine config -> http://paste.pocoo.org/show/339805/ Feb 16 19:00:04 khem, mind bumping uClibc rev to 0f4516e32c3a2186e6b6f074cfc6a57bde90e9cc ? Feb 16 19:00:49 03Martin Jansa  07master * rde373354c2 10openembedded.git/recipes/tasks/task-shr-feed.bb: Feb 16 19:00:49 task-shr-feed: add bison and automake Feb 16 19:00:49 Signed-off-by: Martin Jansa Feb 16 19:01:07 khem, i'd like to call it final but if you could give it a whirl it would be great -- TIA Feb 16 19:03:19 disabling LDFLAGS didn't fix the RPATH issue Feb 16 19:07:18 blindvt: well with thumb broken uclibc bump is not going to happen in OE Feb 16 19:07:33 khem, um, hey Feb 16 19:07:45 Is insane.bbclass fully working (ie hitting RPATH errors) for you? Feb 16 19:07:46 blindvt: most of armv5 and below use thumb by default Feb 16 19:08:03 Tartarus: all I build it native-sdk-image Feb 16 19:08:10 and it works with stringent checks Feb 16 19:08:19 darn thumb1 Feb 16 19:08:23 are you sure? Feb 16 19:08:37 minimal isn't able to his RPATH errors for me Feb 16 19:08:41 try building db in your setup Feb 16 19:08:42 blindvt: I could not find moments to fix it myself yet Feb 16 19:08:55 blindvt: hopefully its fixable Feb 16 19:09:15 khem, so.. given that current git supposedly is not worse CAS-wise than it was before, but only adds better code if gcc supports it, it should be fine Feb 16 19:09:17 Tartarus: I use minimal Feb 16 19:09:21 and angstrom Feb 16 19:09:22 yes, i know Feb 16 19:09:34 and i'm only hitting any RPATH errors on not minimal Feb 16 19:09:40 blindvt: that part is ok Feb 16 19:09:40 ie the db recipe Feb 16 19:09:52 blindvt: problem happens with the move of atomics.h Feb 16 19:10:10 Tartarus: whats error Feb 16 19:10:26 db is full of RPATH errors Feb 16 19:10:35 khem, how so? The very same atomic.h should be picked up, isn't it Feb 16 19:11:07 sec, testing a fix for db itself and don't have a spare term open Feb 16 19:11:47 blindvt: I think it was not Feb 16 19:12:25 blindvt: I would like thumb1 to be alive in uclibc Feb 16 19:12:28 hmmm Feb 16 19:12:39 it would be easy if it was autotools Feb 16 19:12:47 but boost is not autootools but bjam Feb 16 19:12:55 I can't find where is the RPATH set Feb 16 19:13:01 so I'll try to prepare some commits Feb 16 19:13:08 and maybe someone else will fix it Feb 16 19:13:38 khem, there is only one arm-specific atomic.h and that never had thumb1 specific code, i.e. it's working as it was before (or not, with that race-window). Nothing changed, AFAICS Feb 16 19:17:12 khem, but anyway. If thumb1 nptl potential compare-and-swap race is the only thing you're not sure about i'm inclined to call it a release since it doesn't break on all 0 physical arm <= 5 boxes that i have :P Feb 16 19:17:52 03Martin Jansa  07master * rc391037389 10openembedded.git/recipes/bt-gps/bt-gps.bb: Feb 16 19:17:53 bt-gps: fix hardcoded paths, fix QA issues, use bindir/datadir variables Feb 16 19:17:53 Signed-off-by: Martin Jansa Feb 16 19:18:58 i'm quitting my job so have to cleanup my boxes there. bbl Feb 16 19:19:00 * blindvt & Feb 16 19:20:00 is there an easy way to tell bitbake to skip the packages that didn't work and make an image anyway with whatever did work? Feb 16 19:20:05 blindvt: sure we can always call for next release Feb 16 19:20:28 blindvt: and it should be called 1.0 as discussed and also bestowed upon by Erik Feb 16 19:20:35 blindvt: give me today Feb 16 19:20:42 I might find time to fix it for thumb Feb 16 19:20:50 in some hackish way atleast Feb 16 19:25:47 otavio: my builds of meta-toolchain are fine Feb 16 19:26:41 Jay7,what combo and is db built? Feb 16 19:27:24 {angstrom-2010.x, minimal}/ben-nanonote/meta-toolchain with khem's gcc updates Feb 16 19:27:44 something is up w/ insane... Feb 16 19:28:26 db-5.0.21-r3 was built ok Feb 16 19:28:40 which it shouldn't Feb 16 19:29:01 try kaeilos Feb 16 19:29:06 Tartarus, do you have any idea on how to disable theses rpath stuff with bjam? Feb 16 19:29:15 http://tinderbox.openembedded.net/packages/db/ Feb 16 19:29:30 look there for statistic Feb 16 19:29:35 yeah Feb 16 19:30:39 http://tinderbox.openembedded.net/public/logs/qa/2202483.txt Feb 16 19:30:45 how does everyone not hit it? Feb 16 19:31:40 hm.. Feb 16 19:32:07 hmmm rpath issues are general? Feb 16 19:33:23 maybe its a sysroot libtool thing Feb 16 19:33:34 ah ok Feb 16 19:33:37 then I'll wait Feb 16 19:34:00 for? Feb 16 19:34:04 the fix Feb 16 19:34:05 boost isnt autoconf is it? Feb 16 19:34:11 boost is bjam Feb 16 19:34:21 so you need to fix it Feb 16 19:34:23 so I bet I've to fix it Feb 16 19:34:30 but I've no idea how Feb 16 19:34:38 JaMa, touched it the last time Feb 16 19:36:15 basically I've no idea on where is rpath generated Feb 16 19:36:18 and on how to fix Feb 16 19:36:32 I grepped for it in run.do_compile.N Feb 16 19:36:56 it found nothing Feb 16 19:43:08 demigod2k, try bitbake -k Feb 16 19:44:59 Philippe: I tried that. Does work great for doing the rest of the packages but I think since the image is dependent on those which failed, it refuses to do the image :( Feb 16 19:46:07 Philippe: my current solution is to generate the dependency graph, check the *.dot file, and try to remove everything (which might be under a lot of hierarchy like task-base, etc) which failed Feb 16 19:47:52 demigod2k, good luck with that. Might be easier to fix the package that failed Feb 16 19:48:36 Ya that was the other approach. My saga for the week has been using an external toolchain. For console-image about 15-20 have failed in very difficult ways :( Feb 16 19:50:07 I did manage to solve a few but others have become a real annoyance just in the way of getting my first image Feb 16 19:57:13 it seem that it's only during linking that there is an RPATH problem Feb 16 20:00:07 RPATH is a link thing, yes Feb 16 20:02:01 yes I know Feb 16 20:02:07 but sometimes there are hacks Feb 16 20:02:24 like TARGET_CC += "--gnu-hash" Feb 16 20:02:39 the gnu hash is for linking Feb 16 20:02:54 but something it goes (uselessly) into compile stuff as well Feb 16 20:02:59 and is only used at linking Feb 16 20:04:24 Tartarus: I can try to reproduce it Feb 16 20:04:41 Tartarus: the issue would be mostly that db needs libtool love Feb 16 20:05:16 hmmm interesting variable RPATH_LINK Feb 16 20:10:55 Tartarus: I have a gcc niggle that I need to sort out Feb 16 20:11:05 then I have uclibc/thumb atomics Feb 16 20:11:18 then if time permits I will look into db Feb 16 20:11:45 * khem wish to have a monster machine which could build OE in less than hr from scratch Feb 16 20:14:00 * blindvt wishes to have an account on khem's super-fast dream machine :) Feb 16 20:14:42 blindvt: heh Feb 16 20:14:59 khem, pstaging helps if you don't play with the toolchain Feb 16 20:15:11 yeah pstaging is not for me Feb 16 20:15:20 unfortunately Feb 16 20:15:25 I hack toolchains Feb 16 20:15:50 oh with oe-core it might change a bit with individual sysroots Feb 16 20:18:39 khem: 8-cored xeon with SSD Feb 16 20:19:00 yeah or even ramfs Feb 16 20:19:07 my 6-cored phenom build console image about 1h20m Feb 16 20:19:19 with single disk Feb 16 20:19:43 really thats impressive give phenom is like 4 times less in price than i7 Feb 16 20:19:48 still have no ability to buy second HDD :( Feb 16 20:20:08 I have been meaning to built a box on my own Feb 16 20:20:17 I have lowest phenom (1055T with 95TDP) Feb 16 20:20:17 new egg chickens out Feb 16 20:20:32 hmm nice Feb 16 20:20:43 we should also consider performance/dollar Feb 16 20:21:05 btw, I'm doing benchmarking WRT bb threads/make threads Feb 16 20:22:05 fastest build was 6/5 Feb 16 20:22:34 5/6 and 5/7 differs for 3-4 min Feb 16 20:26:34 donate me 2x$70 and I'll provide full-time build-testing system :) Feb 16 20:27:35 khem, re db, 5.1.x is fine and backwards compat w/ 4.x / 5.0.x and already in poky, so i'm gonna go with that Feb 16 20:27:39 may be even with queueing web-interface :) Feb 16 20:27:48 that + --disable-rpath to gettext does it Feb 16 20:28:10 Tartarus: ok set DP to 5.1.x Feb 16 20:28:31 gonna just drop the old ones and rfc is Feb 16 20:28:35 s/is/it/ Feb 16 20:28:39 even better Feb 16 20:28:56 well may be keep 4.x around Feb 16 20:29:05 just if someone is locking it Feb 16 20:29:11 externally? Feb 16 20:29:27 internally I am concerned Feb 16 20:29:31 externally I dont control Feb 16 20:29:32 no one pins db Feb 16 20:29:36 ok Feb 16 20:30:28 I think oldest distro we care now is angstrom 2008 Feb 16 20:30:43 +1 Feb 16 20:31:07 natty is definitely faster than f14 Feb 16 20:31:47 kaeilos too? Feb 16 20:32:00 but, non sysroot libtool distros have RPATH problems Feb 16 20:32:13 Maybe that's a point in favor of not making it a fatal QA error yet Feb 16 20:32:40 hi Feb 16 20:32:44 which distro does not use libtool Feb 16 20:32:45 can you summarize what you're saying? Feb 16 20:33:03 all I caught was the keywords and using external toolchain I've been fighting libtool/sysroot problems today Feb 16 20:33:41 khem, 2.4? Feb 16 20:33:46 angstrom 2008.1, kaeilos Feb 16 20:34:08 Tartarus: yes new keilos uses new libtool Feb 16 20:34:19 its only angstrom 2008 which still uses 2.2 Feb 16 20:35:14 hmm earlier once I went into workdir I could execute temp/run.do_* scripts and it would do stuff Feb 16 20:35:26 but now I have to go inside the builddir Feb 16 20:35:34 hmm Feb 16 20:35:34 otherwise it says nothing to build Feb 16 20:36:17 likely the bb.build changes, think its using cwd to subprocess to switch dirs instead of cd, should probably change it back so the run script is more usable Feb 16 20:36:19 khem, 'kaeilos' is where I see errors Feb 16 20:36:44 kergoth: most likely Feb 16 20:37:02 kergoth: I am using bb master Feb 16 20:37:04 khem: want to open a bug for it? Feb 16 20:37:30 kergoth: in bugzilla against bb ? Feb 16 20:37:38 yeah, just so we don't forget about it Feb 16 20:37:52 I think we abandoned bugz Feb 16 20:38:07 many devs think that Feb 16 20:38:09 heh, fair enough, i never really used it, though i should have Feb 16 20:38:11 I have no problem in filing Feb 16 20:38:22 okay, email to bitbake-dev instead? :) Feb 16 20:38:27 ok Feb 16 20:38:31 then it'll sit in inboxes until we fix it Feb 16 20:38:35 which is something Feb 16 20:38:40 heh Feb 16 20:39:06 * kergoth going on vacation tomorrow until wed of next week Feb 16 20:39:14 yay Feb 16 20:39:16 wow good for you Feb 16 20:39:21 where are you going to Feb 16 20:40:51 just to visit my fiance's family, she hasn't seen them in a while Feb 16 20:41:01 ok cool Feb 16 20:41:24 anyone coming to atten ELC in SFO in apr Feb 16 20:41:48 I hope so Feb 16 20:42:39 I meant anyone from folks in this room :) Feb 16 20:42:58 I mean I hope I can Feb 16 20:43:03 haha ok Feb 16 20:43:16 I'd like to.. don't know if that'll happen though, will see Feb 16 20:43:26 not me (& khem, enjoy your vacation) Feb 16 20:43:48 * khem passes the enjoy part over to kergoth Feb 16 20:44:12 hehe Feb 16 20:44:50 * Jay7 skip ELC but hope to attend on ELC-E Feb 16 20:46:12 sigh Feb 16 20:46:19 I don't understand bjam Feb 16 20:46:25 I don't know well rpath Feb 16 20:46:48 so I really want to fix but it seem that I will end with a lot of frustration and spend a lot of time on it Feb 16 20:47:10 GNUtoo|laptop: pass in -Wl,rpath,/usr/lib Feb 16 20:47:13 to LDFLAGS Feb 16 20:47:21 ah? Feb 16 20:47:22 I'll try Feb 16 20:47:29 oops, misread, kergoth, enjoy your vacation Feb 16 20:47:32 good idea Feb 16 20:47:46 GNUtoo|laptop: btw -Wl,-rpath,/usr/lib Feb 16 20:48:22 yes because m rpath is not correct Feb 16 20:48:23 I know Feb 16 20:48:27 it point to sysroot's rpath Feb 16 20:48:31 hehe Feb 16 20:48:34 which...is kind of absent on target Feb 16 20:50:14 khem: have you had time to look at the gcc-cross-sdk issue? Feb 16 20:50:43 khem: it is reproducable with minimal and it seems to be i586 specific since Jay7 has built it fine. Feb 16 20:52:49 otavio: havent so far Feb 16 20:53:00 I will see if I have time today or tomorrow Feb 16 20:54:14 it seem better but now fails to build,hmmm Feb 16 20:55:47 I'll try to fix Feb 16 20:56:19 khem: there's anything I can look at to check? I can do that easily here since I have rest built. Feb 16 20:57:46 otavio: it needs to be looked into I dont have anything on top of head that I could ask you to do Feb 16 20:57:50 ah Feb 16 20:57:54 thanks a lot Feb 16 20:58:04 try to reproduce it on arm e.g. in your env Feb 16 20:58:21 khem: any machine to use? Feb 16 20:58:48 otavio: qemuarm Feb 16 20:59:05 khem: just setting the machine and doing bitbake gcc-cross-sdk ought to be enough, right? Feb 16 20:59:11 yes Feb 16 20:59:34 it would make sure that its not related to something your settings are doing Feb 16 21:00:34 otavio: on which distro/machine have you error? Feb 16 21:00:48 Jay7: minimal/i586-generic Feb 16 21:01:47 I'll try to build gcc-cross-sdk Feb 16 21:02:11 Jay7: nice .. I am building it for qemuarm Feb 16 21:11:10 I did that: Feb 16 21:11:12 LDFLAGS += "-Wl,-rpath,/usr/lib" Feb 16 21:11:19 in boost_1.45.0.bb Feb 16 21:11:22 and still Feb 16 21:11:43 ERROR: QA Issue with boost-date-time: package boost-date-time contains bad RPATH /usr/lib:/home/gnutoo/embedded/oe/oetmps/htcdream/sysroots/armv6-novfp-oe-linux-gnueabi/bin in file /home/gnutoo/embedded/oe/oetmps/htcdream/work/armv6-novfp-oe-linux-gnueabi/boost-1.45.0-r9.2/packages-split/boost-date-time/usr/lib/libboost_date_time.so.1.45.0 Feb 16 21:11:52 gcc.jam does that: Feb 16 21:13:02 "$(CONFIG_COMMAND)" -L"$(LINKPATH)" -Wl,$(RPATH_OPTION:E=-R)$(SPACE)-Wl,$(RPATH) -Wl,-rpath-link$(SPACE)-Wl,"$(RPATH_LINK)" -o "$(<)" $(START-GROUP) "$(>)" "$(LIBRARIES)" $(FINDLIBS-ST-PFX) -l$(FINDLIBS-ST) $(FINDLIBS-SA-PFX) -l$(FINDLIBS-SA) $(END-GROUP) $(OPTIONS) $(USER_OPTIONS) Feb 16 21:13:10 so I wonder Feb 16 21:13:15 how to change that RPATH_LINK Feb 16 21:13:22 maybe I export it? Feb 16 21:18:05 I'll try harder Feb 16 21:18:13 with the LDFLAGS variable Feb 16 21:19:58 khem: it seems to build. Feb 16 21:20:10 khem: Now I am even more confused hehehe Feb 16 21:20:29 Packaged contents of gcc-cross-sdk into /home/otavio/hacking/embedded-linux/tmp/deploy/ipk/x86_64-armv5te-sdk/gcc-cross-sdk_4.5-r31.2+svnr168622_x86_64-armv5te-sdk.ipk Feb 16 21:22:33 strange strange Feb 16 21:22:42 the compilation log doesn't contain anymore that: Feb 16 21:22:50 /usr/lib/home/gnutoo/embedded/oe/oetmps/htcdream/sysroots/armv6-novfp-oe-linux-gnueabi/bin Feb 16 21:23:30 bad grep Feb 16 21:23:31 it does Feb 16 21:23:48 and it's passed after that: Feb 16 21:23:52 -Wl,-rpath,/usr/lib Feb 16 21:24:01 so as it's passed after it it takes precedence Feb 16 21:24:30 maybe I pass to USER_OPTIONS Feb 16 21:24:31 ? Feb 16 21:24:42 but I don't know bjam at all Feb 16 21:24:58 last time I digged into it it was very hard and very undocumented Feb 16 21:28:02 khem: yes; it built fine. Feb 16 21:28:12 khem: so it looks to be something related to i586 Feb 16 21:28:19 I wonder if i should make the oe.types bits a bit more picky, for consistency in recipes Feb 16 21:32:09 ok maybe I found how Feb 16 21:32:54 kergoth, i'm all for it, yes. What about auto-detection of the type btw? hmz, let me be noisy about un-typed vars Feb 16 21:33:35 well, right now, for example, the boolean type can be y/n, yes/no, true/false, t/f, whatever.. flexibility is good, but we all know that's just going to lead to inconsistency in the metadata.. Feb 16 21:34:06 oh darn.. let me first find a box where i can checkout bb and oe for a start Feb 16 21:34:58 I don't see autodetection being a good thing, better to be explicit Feb 16 21:38:14 cf.sf.net rejects ssh nowadays, great. HP and vanderbilt had boxes too, IIRC Feb 16 21:38:34 what a pita. back to square 1 Feb 16 21:41:45 what an irony. you've installed several petaflops worth of heating and now you're back to looking for an acceptable host with a gig of ram or two. Feb 16 21:42:03 ? Feb 16 21:42:09 nm Feb 16 21:44:04 ERROR: Task 13 (/storage/oe/testbuilder/openembedded/recipes/gcc/gcc-cross-sdk_4.5.bb, do_compile) failed with exit code '1' Feb 16 21:44:06 otavio: ^ Feb 16 21:44:50 wow! NICE Feb 16 21:44:59 Jay7: so you is able to reproduce it Feb 16 21:45:00 good Feb 16 21:45:01 i586-generic Feb 16 21:45:14 Jay7: is it possible for it to be on the release arches? Feb 16 21:45:16 | make[4]: *** [ios_init.lo] Error 1 Feb 16 21:49:33 otavio: i don't know.. Feb 16 21:50:24 hm.. strange that it is not shown on oestats Feb 16 21:50:56 sigh Feb 16 21:51:03 STILL.....the same issue Feb 16 21:52:20 Jay7: I think toolchain-sdk is not built too ofthen Feb 16 21:52:51 it didn't replace a thing! Feb 16 21:52:54 otavio: did you tried to set PARALLEL_MAKE="" for gcc-cross-sdk? Feb 16 21:53:05 -Wl,-R -Wl,"/home/gnutoo/embedded/oe/oetmps/htcdream/sysroots/armv6-novfp-oe-linux-gnueabi/bin" Feb 16 21:53:30 - echo "using gcc : target : ${CXX} : ${CFLAGS} ${CXXFLAGS} ${LDFLAGS} ;" >> tools/build/v2/user-config.jam Feb 16 21:53:30 + echo "using gcc : target : ${CXX} : ${CFLAGS} ${CXXFLAGS} ${LDFLAGS} ${libdir} ;" >> tools/build/v2/user-config.jam Feb 16 21:53:35 Jay7: no however I see no reason why it'd change something since it fail to find a library on /lib ... it seems to be looking at the /wrong/ path Feb 16 21:53:35 oops Feb 16 21:53:43 ah Feb 16 21:53:54 ah no I pasted only 2 lines Feb 16 21:53:57 anyway Feb 16 21:54:06 Jay7: libc_nonshared.a Feb 16 21:54:15 otavio: then this is more likely libtool issue Feb 16 21:54:24 Jay7: possibily Feb 16 21:54:45 Jay7: but why it works for arm and fails for i586? Feb 16 21:54:55 that is good question Feb 16 21:55:06 toolset.flags $(toolset).link RPATH $(condition) : : unchecked ; Feb 16 21:55:07 I'm not skilled enough to answer :) Feb 16 21:55:29 sigh Feb 16 21:55:38 why do I have to go trough bjam again..... Feb 16 21:55:58 Jay7: me neither Feb 16 21:56:33 otavio: btw.. I'll try to build for qemux86 Feb 16 21:56:37 it is i686 Feb 16 21:56:45 let's check Feb 16 21:57:16 03Chris Larson  07master * r4b134d69dc 10openembedded.git/classes/native.bbclass: (log message trimmed) Feb 16 21:57:16 native: fix duplicating virtclass-native entries in OVERRIDES Feb 16 21:57:16 A function was called from ${@} in OVERRIDES which was supposed to return the Feb 16 21:57:16 bits to prepend when in virtclass context, yet it *set* overrides instead, Feb 16 21:57:16 returning None. This resulted in 1) adding an extra virtclass-native to Feb 16 21:57:16 OVERRIDES each time it was expanded, and 2) appending None, causing Feb 16 21:57:17 'localNone' to be in overrides rather than the expected 'local'. Feb 16 22:02:02 GNUtoo|laptop: bjam has a option hardcode-dll-paths which is true by default. But I did not found out how to disable it. The docu says that it shuld be disabled when using stage instead of install as target. this was true but only on my host with x86 but not with the oe recipe Feb 16 22:02:24 ohhh Feb 16 22:02:28 thanks a lot!!!! Feb 16 22:03:48 kergoth yeah Feb 16 22:04:50 GNUtoo|laptop: I hope it helps a bit Feb 16 22:05:46 if it works it will help a lot!!!! Feb 16 22:05:54 and I know how to pass options Feb 16 22:05:56 so.... Feb 16 22:06:32 03Chris Larson  07master * r3023955451 10openembedded.git/classes/autotools.bbclass: Feb 16 22:06:32 autotools: symlink where we can Feb 16 22:06:32 Signed-off-by: Chris Larson Feb 16 22:06:32 Acked-by: Khem Raj Feb 16 22:06:32 I really hope it'll work Feb 16 22:06:33 03Chris Larson  07master * re0528492ef 10openembedded.git/classes/autotools.bbclass: Feb 16 22:06:34 autotools: cleanup Feb 16 22:06:34 Signed-off-by: Chris Larson Feb 16 22:06:34 Acked-by: Khem Raj Feb 16 22:06:34 hmmmm Feb 16 22:06:35 03Chris Larson  07master * r80549f1f6f 10openembedded.git/classes/autotools.bbclass: Feb 16 22:06:35 autotools: split out a oe_autoreconf function Feb 16 22:06:36 This functionality logically belongs in its own function, and it makes it Feb 16 22:06:36 easier to explicitly run against subdirs in certain cases. Feb 16 22:06:37 Signed-off-by: Chris Larson Feb 16 22:08:19 good nite Feb 16 22:42:56 03Chris Larson  07master * r1954f18268 10bitbake.git/lib/bb/runqueue.py: Feb 16 22:42:56 runqueue: pass a copy of the RunQueueStats to events Feb 16 22:42:56 This avoids cases where the stats are modified after the event is fired but Feb 16 22:42:56 before it's dispatched to the UI. Feb 16 22:42:56 Signed-off-by: Chris Larson Feb 16 22:47:09 03Chris Larson  07master * r778571f155 10bitbake.git/lib/bb/runqueue.py: Feb 16 22:47:10 runqueue: simplify RunQueueStats.copy Feb 16 22:47:10 Signed-off-by: Chris Larson Feb 16 22:50:10 yikes, cia is lagggging Feb 16 22:50:14 hrm Feb 16 22:55:07 otavio: failed for qemux86 too Feb 16 22:55:14 Jay7: good Feb 16 22:55:18 http://tinderbox.openembedded.net/builds/127681/ Feb 16 22:56:16 hrm, probably shouldn't have pushed the autotools changes. doubt they'll break anything, haven't here, but i'll hold off on other things, no point risking problems in the release unnecessarily Feb 16 22:56:28 meh Feb 16 22:56:28 hm... Feb 16 22:56:39 oestats show two failed package Feb 16 22:56:49 gcc-cross and gcc-cross-sdk Feb 16 22:57:05 hmm, if an oe build is making pandora skip, its probably time to back off on the number of threads, eh.. Feb 16 22:57:06 heh Feb 16 22:58:03 kergoth: btw, is there any event saying that all tasks related to one package are completed? Feb 16 22:58:58 ka6sox fear that pushing all data after build may cause high load Feb 16 22:59:10 per task as well.. Feb 16 22:59:40 so post per package may be something in the middle Feb 16 22:59:48 no, there used to be, but bitbake doesn't work on a recipe level nowadays Feb 16 22:59:54 03Chris Larson  07master * r8eafb12208 10bitbake.git/lib/bb/siggen.py: Feb 16 22:59:54 siggen: add bb.data, bb.parse imports Feb 16 22:59:54 Signed-off-by: Chris Larson Feb 16 22:59:55 (afaik, anyway) Feb 16 23:00:30 I have thought about catching some task but seems different packages may have different tasks Feb 16 23:00:50 e.g. do_rootfs for images Feb 16 23:01:30 03Chris Larson  07master * re9e174e578 10bitbake.git/lib/bb/cooker.py: Feb 16 23:01:30 cooker: don't choke if we have nothing to parse Feb 16 23:01:30 If all our recipes were cached, there's no reason to fire off any parsing Feb 16 23:01:30 progress events at all. Feb 16 23:01:30 Signed-off-by: Chris Larson Feb 16 23:01:35 yeah, there's no real way to know when a recipe is "done". this is another case where it'd be good to have a nice hook for "our build is going to run these tasks here..", since you could easily gather them together by FILE Feb 16 23:01:55 StampUpdate may be that, not sure, but its definitely not explicitly for that, afaik Feb 16 23:02:39 03Chris Larson  07master * r718448e96d 10bitbake.git/lib/bb/ui/uihelper.py: Feb 16 23:02:39 uihelper: import bb.build, kill commented lines Feb 16 23:02:39 Signed-off-by: Chris Larson Feb 16 23:03:53 well.. then may be just check for collected data size per task and post when it is exceeded some limit Feb 16 23:04:40 post'ing after the build have other good side - no need to post tasks changes Feb 16 23:05:50 another good thing - we may have command-line tool that may post unsent data Feb 16 23:06:20 e.g. build on notebook w/o inet, then get connection and post all data to oestats server Feb 16 23:08:24 well.. kexecboot got new icons and font Feb 16 23:08:39 no more that ugly font Feb 16 23:09:00 * Jay7 going to merge changes Feb 16 23:20:21 florian: you about? Feb 16 23:26:30 ka6sox-farfarawa: garnet is still down FYI Feb 16 23:26:31 khem: the sdk.bbclass does nothing on the gcc-cross-sdk build since it failed to Jay7 too. Feb 16 23:26:44 khem: and using same tree it has built fine for arm Feb 16 23:26:51 khem: in my same build machine Feb 16 23:27:21 otavio: sdk class is inherited in -sdk recipes Feb 16 23:27:36 so it is not totally moot Feb 16 23:28:25 khem: sure but if it was the cause it would be for arm too, no? Feb 16 23:28:47 khem: and do not fail to Jay7 Feb 16 23:28:49 yes and no Feb 16 23:28:59 keep in mind that arm is entirely different than x86 Feb 16 23:29:09 but i586 is similar to x86 Feb 16 23:29:20 so there could be build host contamination somewhere Feb 16 23:29:27 khem: right. I agreed. But Jay7 do not has it applied and it failed to him Feb 16 23:31:11 khem: qt-tools-sdk depends on it for + -I${STAGING_DIR}/${HOST_SYS}${target_libdir}/dbus-1.0/include" Feb 16 23:31:53 khem: and I couldn't hard code it since I were using micro. For minimal hardcoding it ought to work but seems wrong Feb 16 23:33:12 I would be vary of adding anything to classes Feb 16 23:33:17 what exactly I have not applied? :) Feb 16 23:33:31 Jay7: my sdk change Feb 16 23:33:34 * Jay7 on tree with gcc updates Feb 16 23:33:37 ah, ok Feb 16 23:34:04 khem: if you want, I can try Feb 16 23:35:18 khem: building. Will let you know if it changes anything tomorrow Feb 16 23:46:35 hi Feb 16 23:46:45 I spent hours of rebuilds Feb 16 23:46:51 and I still have bad rpath Feb 16 23:47:56 I tried many ways to pass the rpath Feb 16 23:47:59 some succeded Feb 16 23:48:00 but.... Feb 16 23:48:13 the "some" added to rpath instead of replacing Feb 16 23:48:20 at the end here's what I have: Feb 16 23:48:31 GNUtoo|laptop: It doesn't pass -rpath by default at all for me. Feb 16 23:48:38 So I have no idea where your rpath comes from. Feb 16 23:48:40 from #boost Feb 16 23:48:52 he uses boost trunk Feb 16 23:48:56 so there is 2 options Feb 16 23:49:06 or oe passed rpath in some ways I didn't see Feb 16 23:49:19 or....the trunk fix that issue Feb 16 23:56:08 which DISTRO do you see this on? Feb 16 23:59:21 SHR Feb 17 00:01:17 k Feb 17 00:01:20 hmm, unrelated Feb 17 00:01:31 Why does ncurses and readline mangle PKGV rather than PV? Feb 17 00:01:39 That's messing with versioned explode_deps Feb 17 00:07:24 still rpath Feb 17 00:07:28 what should I do Feb 17 00:09:49 ERROR: QA Issue with boost: package boost contains bad RPATH /home/gnutoo/embedded/oe/oetmps/htcdream/sysroots/armv6-novfp-oe-linux-gnueabi/bin:/usr/lib in file /home/gnutoo/embedded/oe/oetmps/htcdream/work/armv6-novfp-oe-linux-gnueabi/boost-1.45.0-r9.2/packages-split/boost/usr/lib/libboost_wave.so.1.45.0 Feb 17 00:10:48 * Jay7 -> sleep Feb 17 00:11:47 well, does boost let you see how it's compiling and what it's passing and all that? Feb 17 00:13:06 I'm not sure it's boost Feb 17 00:13:20 could it be oe? Feb 17 00:13:29 where should I look for OE? Feb 17 00:13:40 Well Feb 17 00:13:46 I would see how boost is being compiled Feb 17 00:13:50 bitbake -e? Feb 17 00:13:52 since clearly rpath is coming in from somewhere Feb 17 00:13:58 and then see if I could see where it was coming from Feb 17 00:13:58 indeed Feb 17 00:14:10 what do you mean by that: Feb 17 00:14:13 I would see how boost is being compiled Feb 17 00:14:16 I looked into: Feb 17 00:14:21 *boost recipe Feb 17 00:14:26 *boost inc file Feb 17 00:14:33 log.do_compile Feb 17 00:14:35 (boost-with-bjam.inc) Feb 17 00:14:40 And if boot hides the actual flags Feb 17 00:14:41 *log.do_compile Feb 17 00:14:44 un-hide them Feb 17 00:14:47 *run_do_compile Feb 17 00:14:49 ahhh ok Feb 17 00:14:56 *gcc.jam Feb 17 00:15:30 I think it doesn't hide them Feb 17 00:15:37 I see clearly -wl etc.... Feb 17 00:15:45 I looked in oe Feb 17 00:15:48 I'll try bitbake -e Feb 17 00:15:48 And you saw -rpath in what? Feb 17 00:15:58 in the link part Feb 17 00:16:03 Right Feb 17 00:16:05 So, fix that :) Feb 17 00:16:23 how? Feb 17 00:16:33 I didn't see in LDFLAGS Feb 17 00:16:36 or something like that Feb 17 00:17:05 See where it comes from and yet bitbake -e might help you match up parts of the build log with where it comes from Feb 17 00:17:07 I'll try bitbake -e Feb 17 00:17:12 afk a bit Feb 17 00:17:14 ok Feb 17 00:17:27 I just got bitbake -e idea now Feb 17 00:17:33 if I had it before.... Feb 17 00:17:39 because I looked everywhere Feb 17 00:17:43 including in boost Feb 17 00:17:48 it really seem to be in boost Feb 17 00:17:50 but.... Feb 17 00:18:01 I was told by someone in #boost that it was unlikely Feb 17 00:19:03 sysroot_stage_dir $from/bin $to/home/gnutoo/embedded/oe/oetmps/htcdream/sysroots/armv6-novfp-oe-linux-gnueabi/bin Feb 17 00:19:07 is the only occurence I have Feb 17 00:20:46 bitbake -e failed Feb 17 00:20:51 last hope is boost trunk Feb 17 00:55:59 03Tom Rini  07master * re9a3f884c2 10openembedded.git/recipes/ncurses/ncurses_5.7.bb: Feb 17 00:55:59 ncurses: Move ${PATCHDATE} into PV rather than just PKGV Feb 17 00:55:59 This was making explode_deps unhappy. Feb 17 00:55:59 Signed-off-by: Tom Rini Feb 17 00:56:04 03Tom Rini  07master * rf10edf6093 10openembedded.git/recipes/readline/readline_6.1.bb: Feb 17 00:56:04 readline 6.1: Move 'p2' into PV and out of PKGV Feb 17 00:56:04 Otherwise we have problems with readline. Feb 17 00:56:04 Signed-off-by: Tom Rini Feb 17 01:11:13 Tartarus: what problems did those cause? Feb 17 01:14:39 PKGV isn't in explode_deps, so ncurses-dev wouldn't install since it wanted (5.7-r16) not (5.7+2010...-r16) Feb 17 01:19:20 Tartarus: we should be able to fix that.. Feb 17 01:19:31 something to look into more closely at some point Feb 17 01:24:13 upgrades of ncurses are constantly broken .... Feb 17 01:26:52 The name is appropriate, indeed. Feb 17 01:35:01 mwester: I wasnt around in the bad old days but all the layers of complication would sure seem to do it Feb 17 01:35:30 autotools, etc. always a nightmare **** ENDING LOGGING AT Thu Feb 17 02:59:57 2011