**** BEGIN LOGGING AT Fri Jul 01 02:59:57 2011 Jul 01 08:23:49 hi all Jul 01 09:17:05 RP__: ping Jul 01 09:22:25 yuke: pong Jul 01 09:23:19 RP__: meet one issue when keep libdir_native=/lib/usr and libdir=/usr/lib64, may need your help Jul 01 09:23:37 yuke: ok, what's the problem? Jul 01 09:23:50 RP__: as libdir=/usr/lib64, all the native lib actually installed to {sysroot}/usr/lib64 Jul 01 09:24:34 while libdir_native=/usr/lib, so the LDFLAG actaully point to {sysroot}/usr/lib, thus the linkage will failure Jul 01 09:25:42 RP__: in bitbake.conf: export BUILD_LDFLAGS = "-L${STAGING_LIBDIR_NATIVE} Jul 01 09:26:08 yuke: Have you tried putting libdir = "${libdir_native}" into native.bbclass? Jul 01 09:26:09 STAGING_LIBDIR_NATIVE={sysroot}/usr/{libdir_native} Jul 01 09:26:52 aha, good idea. that will solve this issue. i will try Jul 01 09:27:11 RP__: thanks Jul 01 10:37:47 heh, watching top as webkit tries to link is scary. ld just keeps using more and more of the system's memory Jul 01 15:42:02 Good Morning All ! Jul 01 15:42:18 hi nitink1 Jul 01 15:42:33 hi RP__ Jul 01 16:34:16 nitink1: Can you take a look at the perl and libxml-parser-perl QA RAPTH errors those two packages generate please? Jul 01 16:34:39 RP__: sure Jul 01 16:35:07 nitink1: There is some discussion on the mailing list and these things are going to become bb.fatal() soon Jul 01 16:35:43 RP__: I see, so just try bitbake perl libxml-parser-perl, and look into error logs, right ? Jul 01 16:35:54 nitink1: that should do it, yes Jul 01 16:36:13 ok, I will look into it Jul 01 17:07:03 RP__: these warnings right? : WARNING: QA Issue: package perl-module-compress contains bad RPATH /build_disk/poky_build/build0/tmp/sysroots/qemux86/usr/lib in file /build_disk/poky_build/build0/tmp/work/i586-poky-linux/perl-5.12.3-r1/packages-split/perl-module-compress/usr/lib/perl/5.12.3/auto/Compress/Raw/Zlib/Zlib.so Jul 01 17:07:19 nitink1: yes Jul 01 17:07:54 only in log.do.package right ? Jul 01 17:08:14 why is the core-image-minimal cpio.gz output so huge for MACHINE ?= "atom-pc" Jul 01 17:08:40 its 38345477 bytes! Jul 01 17:09:00 mgross: something certainly sounds wrong... Jul 01 17:09:03 mgross: master? Jul 01 17:09:14 yup. tips of the day. Jul 01 17:10:54 mgross: Did you get the recent eglibc fixes? Jul 01 17:11:02 That could have been pulling in libc-dev Jul 01 17:11:04 how would I know? Jul 01 17:11:20 mgross: which revision are you using? Jul 01 17:11:35 version of libc-dev? Jul 01 17:11:42 mgross: another sign would be libc-dev being installed into your image Jul 01 17:15:15 RP__: are there any commits depicting how to fix the QA RPATH issue ? Jul 01 17:16:30 readelf -h doesn't tell me much what am I looking for? Jul 01 17:16:54 nitink1: somewhere the compiler/linker is being told -rpath XXX where XXX is correct Jul 01 17:17:05 nitink1: you need to find where and fix it Jul 01 17:17:15 I tend to blame libtool.. ;) Jul 01 17:17:21 you mean incorrect, not correct, right ? Jul 01 17:17:29 nitink1: right Jul 01 17:17:47 looks like I got 82MB of locallation cruft : 82308 ./usr/include/eglibc-locale-internal-core2-poky-linux Jul 01 17:18:05 mgross: update to latest master, that has been fixed Jul 01 17:18:27 RP__, fray, no commits yet fixing similar things ? Jul 01 17:18:37 trying back in about 1 hr ;) Jul 01 17:18:49 nitink1: similar things have been fixed before but you have the info you need above Jul 01 17:19:03 nitink1: it depends how the rpath is getting into the commandline as to how you fix it Jul 01 17:19:08 * RP__ -> afk Jul 01 17:19:41 RP__: thank you Jul 01 17:20:08 nitink1 I'm working on multilib things before I have to leave this evening Jul 01 17:20:33 fray: I understand Jul 01 17:25:32 nitin, I take it this is perl blowing up? Jul 01 17:25:59 we (WR) ended up having to hack both perl to get rid of the -rpath's.. they seem to get embedded in all of the Makefiles for some reason.. it's a real pain to fix Jul 01 17:26:57 fray: good to know, I was thinking this would be easy to fix :) Jul 01 17:30:50 perl sucks.. Jul 01 17:34:00 cool, beagleboard xm revc now boots up with a framebuffer, although the colors are all weird and the ethernet doesn't work and it keeps dropping/resyncing the display :-| Jul 01 17:34:09 win some, lose some Jul 01 17:34:13 heh Jul 01 17:34:38 I demand to see dvhart in there posthaste Jul 01 17:34:42 *here Jul 01 17:34:44 man Jul 01 17:34:49 nothing ruins a joke like a mistype Jul 01 17:36:36 oh Jul 01 17:36:43 I guess that's why ethernet doesn't work -- it's usb ethernet and usb doesn't work Jul 01 18:57:01 RP__, fray: fixed the perl warning Jul 01 18:59:44 BTW I think btrfs (recipe) has some type of missing dependency.. I did a bitbake -k world (after making some changes on a previous world build) and btrfs failed trying to find /usr/include/uuid/uuid.h -- I re-ran the world build and it worked Jul 01 19:03:15 also, gcc won't rebuild if something changes either.. it -always- fails on a configure message about being unable to be reconfigured Jul 01 20:30:00 fray: thanks for reporting these, I will try them myself Jul 01 21:14:13 hi, Jul 01 21:14:16 what does that means: Jul 01 21:14:18 fatal: reference is not a tree: 53fe2b2aa38a6d26d74d680b3d250f8effa7a775 Jul 01 21:14:33 I've that when checking out a git repo within a recipe Jul 01 21:15:11 nitink: great! Jul 01 21:15:25 On a positive note I'm not seeing any other QA warnings on mips Jul 01 21:16:08 GNUtoo: It sounds like the revision is invalid? Jul 01 21:16:28 ok Jul 01 21:16:48 RP__: hi, I have a fetch issue with zaurusd (svn o-hand) Jul 01 21:17:31 nitink: any luck with the libxml-parser one? Jul 01 21:17:31 I use autorev Jul 01 21:17:34 and it's not invalid Jul 01 21:17:37 it seems it needs a SRCREV with oe-core Jul 01 21:17:41 strange then Jul 01 21:18:20 ant__: I suspect I'm missing some context here Jul 01 21:19:00 it seems the fetcher used in oe-core is mopre picky Jul 01 21:19:07 rp__ː i FɪXɛD THɛ ʍɑKɛʍɑKɛʀ OF THɛ Pɛʀʟ, WHɪCH FɪXɛD BOTH Pɛʀʟ ɑND ʟɪBXʍʟ-PɑʀSɛʀ Jul 01 21:19:27 now I'm cleaning my tmpdir but I just added the zaurusd_svn recipe and tried to build it Jul 01 21:19:46 same recipe is ok in oe-dev Jul 01 21:20:38 fwiw I bothered the poor bluelightning about that but he's happily afk ;) Jul 01 21:23:34 nitink: l33t Jul 01 21:28:04 RP__: ping Jul 01 21:28:19 sgw: pong Jul 01 21:28:35 nitink: ok, great, I didn't realise it fixed both :) Jul 01 21:28:56 RP__: any reason not to branch now with master and let you continue pushing to master (we can cherry-pick to M2 as needed). Jul 01 21:29:20 * pidge is chomping at the bit. Jul 01 21:29:40 so what should I do? the revision is valid, it's the last one Jul 01 21:29:40 * sgw wants to take pictures of kids Jul 01 21:29:57 the recipe is libfsobasics Jul 01 21:30:29 it's in meta-smartphone Jul 01 21:32:21 ( http://git.shr-project.org/git/?p=meta-smartphone.git;a=blob;f=meta-fso/recipes-freesmartphone/freesmartphone/libfsobasics_git.bb;h=1d751ca1c39b62c580f97ce3fbc822ec53246efa;hb=refs/heads/master ) Jul 01 21:33:08 * sgw has to bail Jul 01 21:33:52 maybe I'll refetch Jul 01 21:41:04 sgw: no good reason Jul 01 21:44:02 RP__: Ok so pidge can branch and start the M2 build Jul 01 21:44:43 sgw: I'm probably going to do another pass over patches now Jul 01 21:44:54 sgw: but I'm not aware of anything really pressing Jul 01 21:45:14 Ok, can we let pidge branch first? Jul 01 21:45:51 So pidge can grab the current HEAD and start from there, we can cherry-pick as needed next week. Jul 01 21:46:10 ok, give me a few moments Jul 01 21:46:58 Ok, I stirred the pot I have to run, I will check my email after 5:00. Jul 01 21:49:04 RP__/sgw I'm getting ready to leave.. (within the next hour).. do you have any time to look att he top few commits of the mhatle/ml branch and see if you have any questions before I do leave/ Jul 01 21:51:41 sgw RP__: Ok, master is set. now to branch/tag the rest. rc1 starts @ 3:30 Jul 01 21:52:16 fray: I'll take a look Jul 01 21:54:15 RP__ just an FYI.. I do not expect this to be "finished" code.. I suspect you won't liek the way the multilib_header.bbclass is named/implemented.. but it's the concept that matters Jul 01 21:56:28 fray: Can you add the missing file(s) please? :) Jul 01 21:56:35 whats missing? Jul 01 21:56:40 fray: the .bbclass Jul 01 21:56:59 http://git.pokylinux.org/cgit.cgi/poky-contrib/commit/?h=mhatle/ml&id=281ec73627f6b2d173b75d079385f8545140ea4a Jul 01 21:57:01 it's there Jul 01 21:57:08 fray: gah, sorry Jul 01 21:57:13 it's just -small- Jul 01 21:57:22 np.. (I did forget it many tries ago) ;) Jul 01 21:58:09 fray: No questions, the branch and patches look reasonable, thanks Jul 01 21:58:24 fray: I can think of a nicer way to handle this but I can sort that Jul 01 21:58:24 ok.. I'm sending a final status + some details email now Jul 01 21:58:50 (make it part of the standard do_install and just list the appropriate headers in a variable) Jul 01 21:58:57 RP__ I expected as much.. detecting of colliding libraries (automatic) is something I couldnt figure out how to do.. since insane runs after sysroot runs Jul 01 21:59:04 RP__ that works Jul 01 21:59:13 fray: What's your gut feeling on this stuff? Jul 01 21:59:32 it's working right now.. but there are a lot of variables missing.. things I had to hard code into the environment.. Jul 01 21:59:38 fray: think it will work out in a relatively straight forward way? Jul 01 21:59:47 like the lib64- and other prefixes... Jul 01 21:59:55 but everything else worked realtively straight forward.. Jul 01 21:59:59 fray: Thats fine, I knew the packaging stuff was needing some TLC Jul 01 22:00:16 I don't see anything that majorly concerns me -- other then detection of problems, before you've gone all the way to the rootfs step Jul 01 22:01:17 for the oe-multilib-header.. there are two things we need.. bitsize and arch.. if we have those we can hard-code in the list.. (I don't like hard coding, but it's likely the best way..) otherwise we need to define the available varients for an architecture family in a variable.. (siteinfo like is what I'd suggest we end up doing, if we do that) Jul 01 22:02:02 fray: ok Jul 01 22:06:03 RP__ sent out the final status email.. at the end is some technical bits about the RPM conflict resolution if you want to play with it at all Jul 01 22:06:14 (beyond using what I have there) Jul 01 22:06:55 ... once we get the lib -> lib64 mapping complete.. it'll be much easier to spot the conflicts with the shell snippets I sent earlier.. Jul 01 22:09:23 http://pastie.org/2152077 -> I'll clean and retry Jul 01 22:09:24 fray: cool, thanks for the work on this, its appreciated Jul 01 22:09:43 no problem.. I should be back on the 12th or 13th.. depending on flights and everything Jul 01 22:09:56 I'm happy with the proof of concept though.. Jul 01 22:11:18 fray: equally, I'm happy that we can get the core class to do what we need (although I know Ke is having fun with the lib64 thing) Jul 01 22:11:33 Ohh I bet he is.. ;) Jul 01 22:11:56 (post 1.1) I'm looking forward to investigating the new debian approach and seeing if we can make that a configurable option as well.. Jul 01 22:12:42 I'm thinking though between the debian file renaming, debug options and eventually multilib options.. creatings "fedora" class, similar to the debian one might be a good idea.. it'll give people control over the outcome of the build and the way things are structured.. Jul 01 22:13:07 a simple .conf that adds the distro "style" and changes the libdir and related should be easy to implement [once everything else works] Jul 01 22:13:17 should also make a good proof of concept of it's own... Jul 01 22:16:27 RP_: sorry to insist: NOTE: package zaurusd-0.0+svn20090501-r24: task do_fetch: Started Jul 01 22:16:28 ERROR: Function 'Fetcher failure for URL: 'svn://svn.o-hand.com/repos/misc/trunk;module=zaurusd;proto=http'. Please set SRCREV to a valid value' failed Jul 01 22:19:30 ok M2.rc1 is off and running. Jul 01 22:20:03 ant__: and what is SRCREV set to? Jul 01 22:20:24 there is no SRCREV in oe-dev recipe Jul 01 22:20:35 SRCDATE = "20090501" Jul 01 22:20:41 ant__: oh, ouch Jul 01 22:21:13 ant__: Send a patch for the most recent svn revision? :) Jul 01 22:21:18 I'm browsing around but can't find it.. http://autobuilder.pokylinux.org/sources/svn/svn.o-hand.com/repos/misc/trunk/zaurusd/ Jul 01 22:21:54 answer is 415 Jul 01 22:22:06 great, thx Jul 01 22:23:01 gotcha Jul 01 22:23:10 ant__: Its 426 in the oe-core recipe btw Jul 01 22:23:25 but I don't think zaurusd changed between 415 and 426 Jul 01 22:23:44 having a .git repository would be a dream ;) Jul 01 22:23:55 ant__: Its actually closer than you think to happening Jul 01 22:24:03 ^_^ Jul 01 22:25:27 I'm putting together updated bits for meta-zaurus. I'll send the tarball to bluelightning for further processing then (meta-handhelds) Jul 01 22:31:06 RP__: imagine what...I did not know zaurusd was already there ;) Jul 01 22:31:43 same error Jul 01 22:32:12 | mv: cannot stat `.../work/armv4t-oe-linux-gnueabi/eglibc-2.13-r5+svnr14157/image/usr/bin/localedef Jul 01 22:32:20 * fray has an odd feeling.. I shouldn't start additional work cause I'm going to be gone on vacation -- but yet I still have a few minutes before I call it quits.. Jul 01 22:32:22 what should I do? Jul 01 22:33:31 should I ask on #oe? Jul 01 22:34:03 GNUtoo, usually the error is simply the source of the 'mv' isnt there.. beyond that I don't have enough context to help sorry Jul 01 22:34:30 yes I know the file isn't there, here's the previous paste: Jul 01 22:34:42 http://pastie.org/2152077 Jul 01 22:34:48 I already cleaned and retried Jul 01 22:35:01 it's in do_install_locale of eglibc Jul 01 22:35:11 do I need something special in local.conf? Jul 01 22:35:23 as a workaround in the do_install_locale, you could simply do a || : after the mv.. Jul 01 22:35:33 hm...there was buzz around that Jul 01 22:35:35 it's not really a solution, but as a workaround it might let you continue Jul 01 22:35:35 I'll look Jul 01 22:35:37 thanks a lot Jul 01 22:36:00 because I've not yet switched to oe-core Jul 01 22:36:05 each time I try to compile it Jul 01 22:36:09 in your local.conf do you have "ENABLE_BINARY_LOCALE_GENERATION = "1" Jul 01 22:36:09 It fails Jul 01 22:36:11 like for now Jul 01 22:36:17 no Jul 01 22:36:24 I'll add it Jul 01 22:36:25 you need to use the sample local.conf Jul 01 22:36:30 that is likely your problem then.. Jul 01 22:36:31 ahhh Jul 01 22:36:40 I imported my configs from oe.dev Jul 01 22:36:43 note, ENABLE_BINARY_LOCALE_GENERATION = 0 is expected to work.. Jul 01 22:36:45 the configs have changed Jul 01 22:36:51 oh ok Jul 01 22:36:56 thanks a lot!!!! Jul 01 22:37:01 I'd suggest you start with a new local.conf and then add in your settings.. Jul 01 22:37:08 (many are the same, many new ones.. a few deprecated ones) Jul 01 22:37:40 if ENABLE_BINARY_LOCALE_GENERATION (not set or 0) is the cause of the mv failure.. please file a bug on bugzilla.yoctoproject.org Jul 01 22:37:55 (or at a minimum post to the oe-core list the issue and that you think it's that value) Jul 01 22:37:55 NOTE: package eglibc-2.12-r18: task do_install_locale: Succeeded Jul 01 22:37:59 ah ok there is a bugzilla Jul 01 22:38:03 nice Jul 01 22:38:07 at least 2.12 is ok Jul 01 22:38:11 the one on oe was....mostly abandoned Jul 01 22:38:25 the bugzilla is yocto project "specific".. but we're accepting oe-core bugs since we rely on that code.. and many of the maintainers are yocto project folks Jul 01 22:38:40 ok Jul 01 22:39:02 the oe bugzilla is more or less abandoned.. cause filing bugs, w/o anyone able [or more importantly willing] to take responsibility does not good.. the yocto folks are willing to do this Jul 01 22:39:57 then I'll fill a lot of bugs if I hit them Jul 01 22:39:58 fray: one of the biggest issue were the insufficient runtime tests Jul 01 22:40:14 ant__ that is still an issue, but we're getting better.. Jul 01 22:40:18 we at least have -some- now.. Jul 01 22:40:28 some guinea pigs? Jul 01 22:40:53 at Wind River we're regularly running the LSB test suite and reproting progress.. (of course this only covers IA and Power) Jul 01 22:41:04 ok Jul 01 22:41:25 there are regular boot and test cycles (on qemu) for all four ia, arm, power and mips... these are mostly run by the yocto project folks Jul 01 22:41:47 as bonus ;) Jul 01 22:41:51 (our goal is to be able to build an LSB compliant system, but at this point oe-core/Yocto wont be LSB compliant -- nor will we be filing compliance paperwork) Jul 01 22:42:21 we're roughly 90% of the way there.. and it's about as far as we're likely to go for now.. (LSB is a requirement of a lot of "larger" embedded system.. mostly telco) Jul 01 22:42:31 I see your pain Jul 01 22:43:03 at WR, when we switch to oe-core/yocto as our base, we will need to do the remainder of the work for LSB compliance -- at least up to the point our customers demand.. Jul 01 23:05:13 fray, it fails just the same Jul 01 23:05:20 and I cleaned eglibc 2.13 Jul 01 23:05:26 and I already sent the bug Jul 01 23:05:50 what should I do at that point? Jul 01 23:07:01 bitbake -e shows: Jul 01 23:07:06 ENABLE_BINARY_LOCALE_GENERATION="1" Jul 01 23:07:17 and: Jul 01 23:07:26 LIMIT_BUILT_LOCALES="POSIX en_US en_GB" and LOCALE_UTF8_ONLY="1" Jul 01 23:25:40 anyone? Jul 01 23:33:58 GNUtoo: trying to see if I can repro here but don't have a very fast build machine Jul 01 23:34:07 ok thanks a lot Jul 02 00:10:37 I need to go to sleep Jul 02 00:11:04 sorry GNUtoo, I can't repro for qemux86 and arm build is going to take some time Jul 02 00:11:16 ok np Jul 02 00:11:23 I've done a bugreport Jul 02 00:12:02 http://bugzilla.yoctoproject.org/show_bug.cgi?id=1209 Jul 02 00:12:31 thanks! **** ENDING LOGGING AT Sat Jul 02 02:59:57 2011