**** BEGIN LOGGING AT Thu Dec 09 02:59:57 2010 Dec 09 03:06:53 03Khem Raj  07master * r8805bb48b9 10openembedded.git/recipes/binutils/ (13 files in 2 dirs): Dec 09 03:06:53 binutils-2.21: Add recipes for binutils 2.21 release Dec 09 03:06:53 Signed-off-by: Khem Raj Dec 09 03:07:05 03Khem Raj  07master * r6454b9669d 10openembedded.git/recipes/binutils/binutils_git.bb: Dec 09 03:07:05 binutils_git.bb: Move to master now that 2.21 is released Dec 09 03:07:05 Signed-off-by: Khem Raj Dec 09 03:09:02 03Joshua Lock  07master * r6c086dab25 10bitbake.git/lib/bb/cooker.py: (log message trimmed) Dec 09 03:09:02 bitbake/cooker: fix idle command processing in servers Dec 09 03:09:02 idle command processing in each of the servers does not handle an explicit Dec 09 03:09:02 None return value, which means the goggle UI ends up repeatedly adding Dec 09 03:09:02 "Tasks Summary:" rows to the list. Dec 09 03:09:09 03Joshua Lock  07master * r38f59ad6db 10bitbake.git/lib/bb/ui/crumbs/runningbuild.py: Dec 09 03:09:09 bitbake/crumbs: do the test for ignored messages sooner Dec 09 03:09:09 Move the test for ignored messages to the start of the message handling loop to Dec 09 03:09:09 avoid doing work for messages which are only going to be ignored. Dec 09 03:09:09 Signed-off-by: Joshua Lock Dec 09 03:09:20 bitbake/goggle: interaction tweaks Dec 09 03:09:20 Set the goggle window to a more sane default size (640x480) and hook up the Dec 09 03:09:20 close button. Dec 09 03:09:20 Signed-off-by: Joshua Lock Dec 09 03:09:20 03Joshua Lock  07master * rd2c4d0b2af 10bitbake.git/lib/bb/ui/crumbs/runningbuild.py: Dec 09 03:09:27 Due to some recent change *somewhere* we need to explicitly look at the Dec 09 03:09:27 name attribute on the instances class, rather than the name attribute of Dec 09 03:10:14 the instance. Dec 09 03:10:14 Signed-off-by: Joshua Lock Dec 09 03:10:14 03Joshua Lock  07master * r0debaba644 10bitbake.git/lib/bb/server/xmlrpc.py: (log message trimmed) Dec 09 03:10:14 bitbake/xmlrpc: Modify xmlrpc server to work with Python 2.7 Dec 09 03:10:15 Python 2.7's library changes some of xmlrpclib's internal implementation such Dec 09 03:11:16 Signed-off-by: Joshua Lock Dec 09 04:25:26 03Richard Purdie  07master * r6b6ae76ba5 10bitbake.git/lib/bb/data_smart.py: Dec 09 04:25:26 bitbake/data_smart: Refactor _append/_prepend code to remove duplication Dec 09 04:25:26 Signed-off-by: Richard Purdie Dec 09 04:25:33 03Richard Purdie  07master * rba95240541 10bitbake.git/lib/bb/data_smart.py: (log message trimmed) Dec 09 04:25:33 bitbake/data_smart: Fix append/prepend/override ordering issue Dec 09 04:25:33 Where a variable name consisted of an append/prepend combined with an override Dec 09 04:25:33 and there was also an append/prepend to the variable, the override could be lost Dec 09 04:25:33 if the override was not in OVERRIDES. Dec 09 05:34:11 03Chris Larson  07master * r5670134ab2 10bitbake.git/lib/bb/taskdata.py: Dec 09 05:34:11 cooker: use re match, not search in re_match_strings Dec 09 05:34:11 We want to match the requested pattern at the beginning of the string, Dec 09 05:34:11 otherwise things behave in an unintuitive manner wrt ASSUME_PROVIDED (e.g. Dec 09 05:34:11 ASSUME_PROVIDED += "gtk+" will also assume foo-gtk+ is provided), and the user Dec 09 05:34:22 03Chris Larson  07master * re48e9a2150 10bitbake.git/lib/bb/taskdata.py: Dec 09 05:34:22 taskdata: use 'any' in re_match_strings Dec 09 05:34:22 Signed-off-by: Chris Larson Dec 09 06:35:08 gm Dec 09 06:43:19 fidencio: hey! :) Dec 09 06:48:34 03Khem Raj  07master * r55b4c60e08 10openembedded.git/recipes/binutils/ (binutils-cross-sdk_2.21.bb binutils-cross_2.21.bb): Dec 09 06:48:34 binutils-cross-sdk_2.21.bb,binutils-cross_2.21.bb: Use binutils_2.21.bb instead of git version Dec 09 06:48:34 Signed-off-by: Khem Raj Dec 09 07:31:33 hi khem Dec 09 07:32:40 good morning Dec 09 07:34:29 khem, patches looks good. Dec 09 07:36:15 release 2010.12 is in today's LWM weekly letter, in the "Brief Items" section Dec 09 07:37:31 khem: your patches to recipes/gcc/gcc-configure-sdk.inc gcc-package-cross.inc and gcc-package-target.inc fix the sdk problem, you have my ack for these Dec 09 08:09:37 good morning Dec 09 08:11:55 This morning the server power supply has decided to infect the entire office with his stinks, a prelude to a fire :-D Dec 09 08:13:19 * mckoan replaced PSU before having to call the fire department Dec 09 08:20:37 mckoan, good plan(tm) Dec 09 09:51:14 someone with issues booting kernel when u-boot was built with gcc-4.5? same u-boot built with older toolchain works ok. I have it on armv7a (nokia900) Dec 09 10:08:00 JaMa: may happen, but I'm not sure Dec 09 10:15:41 mckoan: it's hanging forever after showing Dec 09 10:15:48 "Starting kernel" here Dec 09 10:16:08 JaMa: so may be the kernel and not uboot Dec 09 10:17:55 same kernel binary for both u-boots Dec 09 10:18:29 also current toolchain makes it 10kB smaller.. Dec 09 10:19:51 JaMa: no clue, sorry Dec 09 10:44:51 hi everyone Dec 09 10:45:12 i just build environment oe Dec 09 10:45:22 i have a question Dec 09 10:45:49 i use linux- ubuntu on ARM Dec 09 10:46:06 there is any distro for it Dec 09 10:46:12 in oe Dec 09 10:46:17 recipes Dec 09 10:48:55 gm Dec 09 11:46:41 is the release-tag final now? Dec 09 11:56:18 tasslehoff: I think yes Dec 09 11:56:30 tasslehoff: maybe a stable branch will follow on that release Dec 09 11:56:53 tasslehoff: good question though, I will address it Dec 09 11:57:43 likewise: cool. we're planning a release in march, and I'm pondering if I should follow dev or stay stable :) Dec 09 11:58:50 03Daniele Ricci  07master * r61cf049e1d 10openembedded.git/recipes/freesmartphone/libfreesmartphone-glib_git.bb: Dec 09 11:58:50 libfreesmartphone-glib: bump SRCREV and version, now depends on fso-specs Dec 09 11:58:50 Signed-off-by: Daniele Ricci Dec 09 11:58:50 Signed-off-by: Martin Jansa Dec 09 11:58:57 I see there's a branch at the same point as the tag now. Dec 09 11:59:02 03Martin Jansa  07master * r84ab2a190e 10openembedded.git/recipes/freesmartphone/ (fso-specs_git.bb libfso-glib_git.bb): Dec 09 11:59:02 fso-specs,libfso-glib: bump SRCREV and PV Dec 09 11:59:02 Signed-off-by: Martin Jansa Dec 09 11:59:51 tasslehoff: tag it's finall, branch will be probably removed later Dec 09 12:01:57 JaMa: my proposal: can we rename or fork the branch so that we can do 2010.12.1 ? Dec 09 12:02:28 i.e. so that 2010.12 is the first release, and also the branch root for stable bug fixes only. Dec 09 12:03:51 I wasn't on OEDEM but ie koen on ML said "At OEDEM we decided that the release would be a tag, not branch of .dev." Dec 09 12:04:14 I guess nobody volunteered to maintain such branch Dec 09 12:05:01 JaMa: it was decided that the actual users maintain it Dec 09 12:05:12 jama: so not pre-assigned people Dec 09 12:05:15 yes that's why SHR has shr/testing2011.1 Dec 09 12:05:25 which is based on this tag Dec 09 12:07:25 Thanks for clarifying. Dec 09 12:16:48 jama the problem is branch users have many different ideas what maintenance policies should be Dec 09 12:19:27 Crofton|work: I'm not sure if that's true. We never spoke with any. Dec 09 12:19:55 Crofton|work: that issue was mainly brought up by the maintainer police. Dec 09 12:20:06 * Crofton|work notes constant low level chatter about the stable branch from people who do not like ho w it is maintained Dec 09 12:22:14 Crofton|work: that's because currently the people who chatter are not maintaining it Dec 09 12:22:30 Crofton|work: I think we should simply put the users in command Dec 09 12:23:22 exactly Dec 09 13:55:32 foerster: we have what appears to be a race in the way we shut down the server / ui. for me, i only see the bug when running bitbake with: taskset -c 1 bitbake autoconf-native, which runs it under one cpu only. it basically acts like a deadlock, hangs on server/ui exit at the end of the build Dec 09 13:56:20 ok. try that. taskset -c 1 makes it run on one cpu? Dec 09 13:56:29 yeah Dec 09 13:56:29 d'oh, "I'll try that".. Dec 09 13:56:30 can't type Dec 09 13:57:18 interesting to note - the use of cache.tell() doesn't cause overhead, but using that, we're firing events again for every load, which incurs a cost of ~2 seconds it seems Dec 09 13:58:02 oops. well, we can still do the modulo thing to chunk it up Dec 09 13:58:11 sort of Dec 09 13:58:22 the values from cache.tell vary Dec 09 13:58:31 so i don't think it's that simple Dec 09 13:58:31 my current theory about the deadlock is the event_queue feeder thread not being done with its work when the server is joined Dec 09 13:58:48 hmm, maybe we should just go back to storing the total in the cache file :) Dec 09 13:58:53 haha Dec 09 13:59:02 that, or use a fuzzy comparison to see if it's within some bound Dec 09 13:59:06 either that or we'd have to check with some sort of tolerance Dec 09 13:59:07 yeah Dec 09 13:59:10 or round it first Dec 09 14:01:16 do i have to clean autoconf-native or anything? Dec 09 14:01:34 nope. but the problem is its a race, so maybe the magic incantation is different on your box ;) Dec 09 14:01:52 i did notice one thing that confused me -- if you do the server.stop() just before the UI exits, rather than after it exits, the stop hangs. which seems strange, unless the clear() is happening more than once or something? unrelated issue, probably. i couldn't confirm where it is when it hangs, pdb.set_trace() didn't work just before server exit for some reason Dec 09 14:03:11 hmm. task SRC_DISTRIBUTECOMMAND Dec 09 14:03:23 failed Dec 09 14:03:34 weird Dec 09 14:03:44 | cp: cannot stat `/home/foerster/dev/openembedded/dev/build/tmp/work/x86_64-linux/autoconf-native-2.65-r10.0/autoconf-2.65/autoconf-2.65.tar.bz2': No such file or directory Dec 09 14:04:56 also strange. best clean first -- it shouldn't behave any differently from a build perspective under taskset or not under taskset Dec 09 14:05:36 cleaning, will try again Dec 09 14:06:54 still fails, weird Dec 09 14:07:57 Bear in mind that a process that has put items in a queue will wait before terminating until all the buffered items are fed by the “feeder” thread to the underlying pipe. (The child process can call the Queue.cancel_join_thread() method of the queue to avoid this behaviour.) Dec 09 14:08:04 from py docs Dec 09 14:08:16 right Dec 09 14:09:02 thats why i was thinking that might be the problem. i tried emptying the queue from the ui before it exits, but then again you have the server and ui racing, if the ui empties any remaining items before the server stops adding items.. Dec 09 14:09:07 * kergoth shrugs Dec 09 14:09:16 oddly fun to work on this sort of problem Dec 09 14:09:16 hm. Dec 09 14:09:27 right, though also annoying ;) Dec 09 14:09:35 indeed Dec 09 14:10:32 what i was going to do was have the ui tell the server stop, then after that empty the queue, and have the server wait for the queue to be empty before it exits Dec 09 14:10:38 "Remember also that non-daemonic processes will be automatically be joined." Dec 09 14:10:40 but then i hit the .stop/.clear hang Dec 09 14:10:52 they say just to remove the join Dec 09 14:11:05 hmm Dec 09 14:11:20 How do you control the order files are packaged in Dec 09 14:11:28 hmmm, so the server won't be joined until the UI process exits, still might have an issue though Dec 09 14:11:34 i'll test that, since i can reproduce Dec 09 14:11:40 I have some going into ${PN} but I want them in ${PN}-examples Dec 09 14:11:52 Crofton|work: add ${PN}-examples to PACKAGES before ${PN} Dec 09 14:11:56 use =+ instead of += Dec 09 14:12:06 ok Dec 09 14:12:10 I was thinking that Dec 09 14:12:23 the meaning is a ltittle funny Dec 09 14:12:30 since you would think "subtract" Dec 09 14:13:29 think of +=/=+ as more like list operations on a space separated list. Dec 09 14:13:34 -= would remove an element from that list Dec 09 14:14:08 urh Dec 09 14:14:10 I saw - Dec 09 14:14:40 that is cleare Dec 09 14:14:45 need to get my contacts in Dec 09 14:21:08 kergoth_: we could try using a "Manager" - it says those queues aren't prone to such deadlocks Dec 09 14:21:52 foerster: huh, worth trying anyway Dec 09 14:22:30 or, what if we have the server use cancel_join_thread()? Dec 09 14:38:04 hi kergoth Dec 09 14:38:39 hey pb__ Dec 09 14:43:04 kergoth_: updated cache progress events https://github.com/foerster/bitbake/commit/ff086b864b60cf76e5c48cda4d42d59a0b027ccd Dec 09 14:43:18 seems to shave off most of the previous overhead Dec 09 14:45:53 foerster: ah, nicely done Dec 09 14:46:07 * kergoth_ tests cancel_join_thread Dec 09 14:46:51 kergoth_: also, try putting a timeout in the join, and then inspecting the queue Dec 09 14:47:00 maybe that will provide some insight Dec 09 14:48:05 could call join in a loop with timeout to test Dec 09 14:49:02 03Michael Smith  07master * r8e91420560 10openembedded.git/recipes/iproute2/ (3 files in 2 dirs): Dec 09 14:49:02 iproute2: upgrade to 2.6.35.1 Dec 09 14:49:02 Upgrade 2.6.35 to 2.6.35.1. The new version fixes "ip route get" and Dec 09 14:49:02 "ip addr flush". Dec 09 14:49:02 Signed-off-by: Michael Smith Dec 09 14:50:46 canceling the join of the event queue thread fixes it Dec 09 14:50:56 so we at least know for certain that that was the cause Dec 09 14:51:19 sweet. Does not joining the queue thread cause any problems? Dec 09 14:51:25 no idea :) Dec 09 14:51:29 hah Dec 09 14:51:36 i guess what it was trying to feed will never make it to the UI Dec 09 14:51:44 well, only problem of concern is -- is it still running? Dec 09 14:51:51 that thread get's wiped out still, I assume Dec 09 14:51:58 my pthreads-fu is weak Dec 09 14:52:00 i'd assume so Dec 09 14:52:24 so i'd guess the UI just never gets those remaining events, but its likely the UI is on its way out anyway, since our UIs dont clear out the queue when they're exiting Dec 09 14:52:34 right Dec 09 14:52:52 alternatively, we could do the join loop with queue emptying Dec 09 14:53:00 don't know if that would have any benefit or not Dec 09 14:53:05 yeah, don't know Dec 09 14:53:18 this is the thing that bugs me about multiprocessing. okay, it has all these classes that look nifty and all Dec 09 14:53:23 but there's a crapload of ways to do things Dec 09 14:53:35 where's the guidelines to tell me when to use which? :) Dec 09 14:53:36 and not many good examples Dec 09 14:53:38 yeah Dec 09 14:54:10 when it works though, it does make things quite nice Dec 09 14:54:16 personally, i'd rather stick to queues than proxies, it seems like using proxies just encourages thinkiing about the problem in the wrong way Dec 09 14:54:41 managers do look somewhat interesting in general though Dec 09 14:54:55 yes, but if we only use the manager to provide a safe queue, it'd be different. Dec 09 14:55:06 plus, the manager can be long lived, and clients could later connect to it Dec 09 14:55:11 and use the same queues Dec 09 14:55:22 right Dec 09 14:55:25 there's some api in there for connecting to the manager i believe Dec 09 14:55:42 but, that's more of a drift from where we are now. cross such bridges if/when necessary Dec 09 14:55:48 right Dec 09 14:56:23 did you have a chance to play with my ^C handling, or should I bring in the way you did it? Dec 09 14:56:36 mine was dead simple, but seemed to work Dec 09 14:57:00 i saw you also found a way to join the cache sync thread, right? Dec 09 14:58:04 i'm experimenting with your new branch + 2 small changes, one for the sync join yeah, the other is a slight change to the shutdown Dec 09 14:59:56 I did hit one issue with the current way of doing things. if you actually bitbake something instead of doing -p, and ^C the parsing, it will continue to try to build -- returning False rather than raising an exception appears to be a problem, because none of the people that *run* updateCache (as opposed to the command that runs it for -p) check for successful parsing completion Dec 09 15:00:16 so i think we may want to keep the sys.exit()s for the incomplete parses, or revamp those Dec 09 15:00:23 or add a new exception Dec 09 15:00:25 ah, ok Dec 09 15:00:48 but, i'm still looking into it Dec 09 15:00:55 might be missing a cleaner method Dec 09 15:01:30 hrm Dec 09 15:02:02 although, all the buildTargets() does is registers the idle command after switching into the parsing state, it should still know to exit the idle function when the cooker enters the shutdown state Dec 09 15:02:21 but maybe we have a race, its possible the state is being overwritten with a new value after its set to shutdown, perhaps Dec 09 15:02:37 since the state machine doesn't do an explicit A->B transition to check sanity or anything Dec 09 15:02:43 * kergoth_ re-reads the code in question Dec 09 15:06:17 yea, right now, it's crapping all over the floor if i ^c twice during parsing, when actually trying to build something Dec 09 15:08:01 File "/home/foerster/dev/openembedded/dev/bitbake/lib/bb/server/process.py", line 112, in idle_commands Dec 09 15:08:01 retval = function(self, data, False) Dec 09 15:08:01 File "/home/foerster/dev/openembedded/dev/bitbake/lib/bb/cooker.py", line 712, in buildTargetsIdle Dec 09 15:08:01 rq.finish_runqueue(True) Dec 09 15:08:01 File "/home/foerster/dev/openembedded/dev/bitbake/lib/bb/runqueue.py", line 1052, in finish_runqueue Dec 09 15:08:22 ouch Dec 09 15:08:34 some funny business happening - we probably do need a better way to abort parsing Dec 09 15:09:44 yeah.. before buildTargets registers its idle function, it creates the runqueue and crap all based on our incomplete parse Dec 09 15:09:47 not good Dec 09 15:10:21 sys.exit on any unclean parse shutdown? Dec 09 15:11:21 that's what i have it doing for now, but ideally the cooker should be able to shut itself down cleanly rather than raising SystemExit :) something to revisit in the future Dec 09 15:19:39 kergoth: I like the idea of runqueue and crap :) Dec 09 15:19:53 kergoth: care to join the tsc channel for a second? Dec 09 15:20:09 the ui probably needs to check for queue errors now so it can detect when the server exits, no? Dec 09 15:21:53 * kergoth_ chuckles Dec 09 15:22:45 foerster: no, the systemexit gets caught by the code that's handling teh command, and raises CookerCommandFailed in the finishAsyncCommand or whatever Dec 09 15:23:15 kergoth_: awesome, even better. Dec 09 15:29:43 I think I am having the issue where cleaning a task does not really clean it Dec 09 15:29:47 does that ruing a bell? Dec 09 15:33:16 foerster: https://github.com/kergoth/bitbake/commits/separate-ui-and-server has my current changes on top of yours -- will still need to rebase on master again later, and perhaps rebase -i to merge some of the commits to clean up the history (well, we don't have to, but we'll probably want to, but can wait until just before we merge) Dec 09 15:34:47 of course, the danger with using multiprocessing's finalizers is i don't know how portable they are across python versions :) will have to verify 2.7 is happy Dec 09 15:35:28 but i think its slightly cleaner than the finalize() bits Dec 09 15:36:41 cool. I'll bring your changes in. Dec 09 15:37:26 should make better use of a TODO, either in a separate file, the readme, or on github or oe's wiki, or something Dec 09 15:43:25 kergoth_: did you see the little bit in bin/bitbake blocking ^C? I don't like it, b/c it could cause problems if the server for some reason hangs Dec 09 15:43:50 but not sure what else to do - it helps get rid of some ^C stack traces when the user tries to abuse us Dec 09 15:43:52 thats not theoretical Dec 09 15:44:00 i kept having to kill bitbake debugging this issue ;) Dec 09 15:44:07 right Dec 09 15:44:34 i thought maybe to block it, then join with a few second timeout or something Dec 09 15:45:00 what's the danger if that bit isn't there? Dec 09 15:45:12 should we just catch keyboardinterrupt and forcibly terminate the server if we have to? Dec 09 15:45:13 just extra uncaught ^c exceptions Dec 09 15:45:16 * kergoth_ nods Dec 09 15:45:40 that would probably work too Dec 09 15:47:34 i guess the higher up you are when you catch keyboard interrupt, the better Dec 09 15:47:49 without catching, you'd get a stack track showing server.join Dec 09 15:47:49 other than that, everything is looking good here so far Dec 09 15:48:01 wait, that's odd. I'm always getting ERROR: Command execution failed: Exited with 1 | ETA: --:--:-- Dec 09 15:48:06 hmmm Dec 09 15:48:11 strange Dec 09 15:48:18 cache loads, parsing doesn't happen Dec 09 15:48:19 wtf Dec 09 15:48:45 bisect my changes? :) Dec 09 15:48:51 any attempt at parsing and it bails Dec 09 15:48:58 yea, let me try Dec 09 15:50:11 http://dustin.github.com/2010/03/28/git-test-sequence.html is interesting, from the useful git tidbits department -- could use it to make sure the individual commits in a branch don't cause breakage, at any point, so as to avoid breaking other people's bisects with unrelated problems, before merging it Dec 09 15:52:10 hmm. resurrect sys.exit usage causes me breakage Dec 09 15:53:03 commit ebdf3db3b612c1d56c8a71adb8bdffb327ca9582 Dec 09 15:53:38 hmm, well, maybe we should revisit the interrupted parsing for a build issue then Dec 09 15:54:01 it's not even getting into parsing here Dec 09 15:54:07 no interrupts at all Dec 09 15:54:08 :) Dec 09 15:54:44 what i mean is, drop that commit for now and revisit the issue it fixed later, since it clearly causes other problems Dec 09 15:56:09 curious what the hell it's doing though Dec 09 15:57:31 agreed Dec 09 15:57:39 it's bailing in updateCache Dec 09 15:57:46 considering those should only be hit when shutting down Dec 09 15:57:51 why is state shutdown or stop there when parsing? Dec 09 15:57:53 right Dec 09 15:57:53 i don't see how it could happen in a normal run Dec 09 15:57:54 right Dec 09 15:58:20 ericben|away: thanks Dec 09 15:58:41 eFfeM_work: did the gcc patch I gave helped your case ? Dec 09 15:58:44 gm all Dec 09 15:59:47 kergoth_: should have been cookerAction, not cookerState I believe Dec 09 15:59:52 state is (clean, parsing, parsed) Dec 09 16:00:22 oh, yes, that's my fault Dec 09 16:00:25 master merged the two :) Dec 09 16:00:28 ah Dec 09 16:00:31 maybe we should get that rebase done :) Dec 09 16:00:57 probably wise Dec 09 16:01:06 http://lwn.net/Distributions/#embed Dec 09 16:01:11 its just state - initial, parsing, running, shutdown, stop now Dec 09 16:01:17 which i think is much less confusing Dec 09 16:01:17 search for 'OpenEmbedded' Dec 09 16:01:25 kergoth_: agreed Dec 09 16:01:31 release is mentioned Dec 09 16:01:40 khem: nice Dec 09 16:02:01 I pinged Jonathan to add it Dec 09 16:02:58 hi khem Dec 09 16:03:55 hi Dec 09 16:04:04 while looking at the sdk problem, I found that when installing the sdk -tar -C / -xjf meta-toolchain.... we change the rights of /usr and /usr/local to 775 ! Dec 09 16:04:32 hmm Dec 09 16:04:33 which is not a good thing ... Dec 09 16:04:44 right Dec 09 16:05:13 I have a patch for this : I do a chmod -R go-w before doing thez fakeroot tar in meta-toolchain.bb Dec 09 16:05:21 is that an acceptable fix ? Dec 09 16:08:26 ericben: sounds ok to me. Send to ml Dec 09 16:09:04 I think we should update news section more often with OE dev news Dec 09 16:09:12 however small it is Dec 09 16:09:42 khem: if you have access to the homepage of the wiki: is it possible to add http://wiki.openembedded.org/index.php/Presentations somewhere : this can be interesting for peoples to have an easy access to this Dec 09 16:11:47 I dont Dec 09 16:12:41 concerning local generation with qemu : it seems qemu 0.13 hangs for ever when building into a virtualmachine run by virtualbox Dec 09 16:12:55 switching back to 0.12.5 works Dec 09 16:13:40 for me (no virtualbox) it seems to build much longer, but it finishes ok in the end Dec 09 16:13:42 khem: are you aware of big changes in qemu's configuration or code which could explain this ? Dec 09 16:13:54 JaMa: I did wait about 6 hours ! Dec 09 16:14:18 kergoth_: rebased onto master Dec 09 16:14:57 https://github.com/foerster/bitbake/commits/separate-ui-and-server Dec 09 16:14:58 ericben: hmmm, I just saw that it fixed a crash Dec 09 16:15:40 ericben: I think I will add the cross locale generation to eglibc Dec 09 16:15:44 khem: I can reproduce this 100% case until now (on different host either linux or windows as the native os) Dec 09 16:15:53 and get rid of qemu Dec 09 16:16:18 ericben: ok reinstate 0.12.5 if you like Dec 09 16:16:58 ericben: here it's about 50min, while normally (qemu-kvm in gentoo box) it's in about 10min Dec 09 16:17:39 ericben: but for gentoo I'm not building all targets.. Dec 09 16:25:03 foerster: i really wonder why multiprocessing doesn't run atexit functions when shutting down, seems very strange to me. in addition, it registers its exit functions with atexit, and also runs them explicitly in its Process Dec 09 16:25:07 quite strange Dec 09 16:25:12 * kergoth_ might have to try to get ahold of the upstream Dec 09 16:25:23 hmm Dec 09 16:30:53 kergoth_: yea, seems odd Dec 09 16:30:54 JaMa: Hey! Dec 09 16:31:23 JaMa: we have a serious problem with hours hehehe Dec 09 16:31:58 fidencio: hey Dec 09 16:32:10 hmm Dec 09 16:32:43 JaMa: a question. How you compile EFL with debug support? Are you using task-efl-x11-core (or something like this Dec 09 16:32:46 )? Dec 09 16:32:51 kergoth_: http://mail.python.org/pipermail/python-list/2009-March/1196649.html we're not the only ones confused Dec 09 16:33:11 huh, indeed Dec 09 16:33:22 * kergoth_ tries a minimal test case Dec 09 16:33:58 fidencio: without debug Dec 09 16:34:16 JaMa: 'cause I'm creating an image using e-wm*, but I can't found when eina,evas,edje ... are compiled. So, I can't add debug :-( Dec 09 16:34:48 JaMa: and EFL are segfaulting here. I think that is a stupid problem with efreet and freescale hardware Dec 09 16:34:58 fidencio: and task-x11-illume Dec 09 16:36:10 fidencio: #DEBUG_BUILD = "1" Dec 09 16:36:10 #PACKAGE_STRIP = "no" Dec 09 16:36:26 to your local.conf (without #) and bump EFL_SRCREV to force rebuild :) Dec 09 16:36:39 yeah, minimal test case shows the same behavior. atexit registered in the main process gets run when it exits fine, but not the one in the Process Dec 09 16:36:42 * kergoth_ shakes head Dec 09 16:36:53 JaMa: Yeap. I do it. Dec 09 16:37:10 surely, there must be some reason :) Dec 09 16:37:14 But I need to create my image with *-dbg packages Dec 09 16:37:15 so, anyone know if git submodule stopped sucking? Dec 09 16:37:22 or if its best to use alternatives like braid? Dec 09 16:37:28 or mr, or.. Dec 09 16:37:34 JaMa: the packages were created Dec 09 16:37:37 fidencio: -dbg packages are built by default Dec 09 16:37:51 fidencio: you can opkg install those on target Dec 09 16:37:54 fidencio: IMAGE_FEATURES += "dbg" will add all -dbg packages to any image you build Dec 09 16:38:18 also with ~200MB eglibc-dbg :/ Dec 09 16:38:23 hehe Dec 09 16:38:29 maybe it needs a blacklist :) Dec 09 16:38:31 kergoth_: but it fails because there's packages that -dbg were not createad Dec 09 16:38:32 khem: any idea why is eglibc-dbg so big nowadays? Dec 09 16:38:38 fidencio: then those packages should get fixed :) Dec 09 16:38:50 khem: or can we split eglibc-dbg ie to eglibc-static-dbg? Dec 09 16:38:58 kergoth_: nhaaaaaaam. hehehee. ok. I'll try again and will send patches Dec 09 16:39:02 hehe Dec 09 16:39:19 as JaMa said, can always install them manually, but might be faster to fix the recipes with no -dbgs :) Dec 09 16:40:33 kergoth_: bitch. I was looking for a lazy way. heheeh Dec 09 16:40:52 fidencio: iirc you work for profusion, right? do you work on webkit-efl too? Dec 09 16:41:40 JaMa: nops. But antognolli, k-s, jprvita, demarchi and acidx (@ #edevelop) can help you :-) Dec 09 16:43:38 ok thanks Dec 09 16:45:12 JaMa: you're welcome! Dec 09 16:45:32 it's amazing how much time oe/bitbake can suck up. i wonder if i'd have the *time* to add another project. hrmph Dec 09 16:45:52 kergoth_: /me too Dec 09 16:45:56 bbl Dec 09 16:48:50 hmm, my u-boot-fu is rusty, i should look for a guide for getting something useful on my sheevaplug Dec 09 16:49:34 kergoth_: which gcc version are you using for u-boot builds? Dec 09 16:49:44 none yet :) Dec 09 16:50:20 kergoth_: I'm just building 4.3 to check if 4.5 is cause for my boot problems (when I build u-boot with 4.2.1 it works ok) Dec 09 16:50:26 ah Dec 09 16:50:29 interesting Dec 09 16:51:10 so better to practise your -fu somewhere safe :) Dec 09 16:51:25 i did all kinds of crap in u-boot in the past, like making sure the production guys entered in a mac address before the system would boot, etc. Dec 09 16:51:46 hmm, i wonder if itd be possible to arrange filters on the oe list to only show me specific subsets of patches. itd be really nice to only see the ones that touch the recipes you maintain, etc Dec 09 16:52:00 or, maybe could do something with patchwork for that and archive all patches in gmail :) Dec 09 16:52:17 * kergoth_ notices he has to mute a *lot* of patch threads in the oe ml for things he doesn't care about Dec 09 16:53:15 * JaMa is just deletes the patches and threads which doesn't touch anything I ever use and keeping whole history only in gmail folder Dec 09 16:53:43 i guess auto-archiving all patch threads to mailing lists could make sense, with a saved search to look at them explicitly Dec 09 16:53:59 since i use my inbox as things that require action, 90% of the patches don't, so.. Dec 09 16:54:00 hmm Dec 09 17:23:29 kergoth: yah, that sounds like an area where patchwork might be useful. Dec 09 17:23:39 can't think of any way to do it with straightforward MUA filters. Dec 09 17:28:58 03Andreas Oberritter  07org.openembedded.dev * rddd56fb6cb 10openembedded.git/recipes/linux/linux-omap-hah_2.6.31.bb: Dec 09 17:28:58 linux-omap-hah: remove unused variable CVS_TARBALL_STASH Dec 09 17:28:58 Signed-off-by: Andreas Oberritter Dec 09 17:28:58 Acked-by: Stefan Schmidt Dec 09 17:30:33 yeah, really need to be able to inspect the patches themselves, run lsdiff from patchutils, whatever Dec 09 17:30:58 right Dec 09 17:31:21 I guess you could do it in a plugin, given a suitable mua, but something like patchwork is probably a more generally useful place for it Dec 09 17:31:37 * kergoth_ nods Dec 09 17:31:42 i don't exactly use procmail anymore ;) Dec 09 17:31:53 heh Dec 09 17:32:13 i think my work mail server might support sieve, but i don't think it has the very useful plugins for it Dec 09 17:32:17 ah well Dec 09 17:41:24 * cbrake unpacks panda board Dec 09 17:41:28 nice Dec 09 17:42:40 hi kergoth and cbrake Dec 09 17:42:47 cbrake: I'll get mine in the next week :-) Dec 09 17:44:01 hey woglinde Dec 09 17:45:08 woglinde: hello Dec 09 17:46:55 foerster: separated ui/server seems reliably faster than unseparated for me in this test, testing with one cpu with taskset, autoconf-native. getting times of ~236 seconds unseparated, 208-220 seconds separated -- :) still testing though Dec 09 17:47:21 sweet Dec 09 17:47:37 gotta jet, dentist appointment. see ya for now Dec 09 17:47:39 considering xmlrpc used to be *slower*.. Dec 09 17:47:40 later Dec 09 18:01:17 gm Dec 09 18:01:23 hey eFfeM Dec 09 18:01:37 kergoth_ Hi! Dec 09 18:02:22 khem, tried the gcc patch for mediatomb today, but not success, same failure (actually libgcc.so already seemed to have the proper info in it Dec 09 18:08:44 03Philip Balister  07org.openembedded.dev * r604fe17b54 10openembedded.git/recipes/autoconf/autoconf.inc: Dec 09 18:08:44 Revert "autoconf.inc: Use 'which' to find m4" Dec 09 18:08:44 This reverts commit 8da17586c547f365ae667eb2608ba89a1c375afc. Dec 09 18:08:44 This commit broke autoconf running on the target. I spoke with Tom Rini and he Dec 09 18:08:44 approved the revert of his commit. Dec 09 18:08:54 03Philip Balister  07org.openembedded.dev * r5f62651cbf 10openembedded.git/recipes/uhd/uhd.inc: uhd : Fix packaging for examples and test programs. Dec 09 18:14:02 khem, can you commit the fix you made for me yesterday? Dec 09 18:14:07 it looks good Dec 09 18:31:48 03Andreas Oberritter  07org.openembedded.dev * rc1d9a905c2 10openembedded.git/recipes/openssl/openssl.inc: Dec 09 18:31:48 openssl: allow to add configure options through EXTRA_OECONF Dec 09 18:31:48 Signed-off-by: Andreas Oberritter Dec 09 18:31:48 Acked-by: Michael Smith Dec 09 18:33:00 hms Dec 09 18:33:10 no rw for obi yet? Dec 09 18:34:12 woglinde: i just pushed my second commit ;) Dec 09 18:39:08 fine Dec 09 18:41:20 hmm... bitbake from git is a total mistery; nothing that worked still works Dec 09 18:41:33 CMoH: what do you mean? Dec 09 18:41:50 well, there's no more bitbake -i Dec 09 18:42:03 that's correct, it doesn't exist in the 1.10 releases either Dec 09 18:42:34 it will be resurrected in a better form in the future. it can't be implemented the way it was anymore, due to architectural changes Dec 09 18:42:38 i see; well i just moved from my setup based on 1.8.18 to this git master Dec 09 18:42:56 1.11.0 Dec 09 18:42:59 that would be a massive change, yes. the master branch was separated from 1.8 2 years before 1.10 finally released. Dec 09 18:43:21 still it seems ubuntu and gentoo (also your openembedded manual) are all based on 1.8 Dec 09 18:44:07 OE doesn't require 1.10 yet. Dec 09 18:44:11 so that's not too surprising Dec 09 18:44:29 did you have an issue other than -i? Dec 09 18:44:30 yeah... humpf... and there are no layers or bbappend recipes in 1.8 Dec 09 18:44:46 that's not quite correct, they're just available in a different way Dec 09 18:44:55 Crofton|work: Can I add your Tested-by Dec 09 18:45:04 please do Dec 09 18:45:12 you'd probably want to leverage collections.bbclass and amend.bbclass if you want to use the 1.8 mechanisms, but since that's not the direction going forward, i wouldn't recommend it Dec 09 18:45:14 kergoth_, i'm very interested in what you mean Dec 09 18:45:24 i see Dec 09 18:45:30 do a bit of googling for those, you'll find the instructions Dec 09 18:45:36 obi should send keys to cbrake or me Dec 09 18:45:41 so what's the direction you'd recommend? Dec 09 18:45:46 er, sorry, its still collections.inc, not collections.bbclass. Dec 09 18:45:53 use 1.10 or master and deal with the lack of -i. Dec 09 18:45:57 would be my advice. Dec 09 18:46:05 ah, that's the least of my problems :) Dec 09 18:46:06 we're likely releasing 1.11 in the next few weeks Dec 09 18:46:15 well, we can't fix problems without reports. Dec 09 18:46:19 i haven't heard of any outstanding issues Dec 09 18:46:29 there are a grand total of 2 people working on bitbake Dec 09 18:46:39 ah, i'd better read the manual - first i wanted a confirmation that it's been really changed Dec 09 18:46:41 well, 3 now Dec 09 18:46:49 great job! Dec 09 18:47:12 i don't mind helping, if you're having trouble, just ask Dec 09 18:47:37 thanks - i will; though usually i try to find some docs first Dec 09 18:47:54 you won't find much ;) Dec 09 18:48:00 there's the OE manual, but beyond that.. Dec 09 18:48:08 the bitbake documentation is weak at best Dec 09 18:49:04 well my first shock was ERROR: Nothing to do. Use 'bitbake world' to build everything Dec 09 18:49:24 as far as i knew, i'd have to provide a package - where's the world thing coming from? Dec 09 18:49:41 khem any new clue on the mediatomb issue ? Dec 09 18:49:46 what exactly was the bitbake command you ran? Dec 09 18:50:02 that error will only happen if 1) your BBFILES isn't correct, or 2) you didn't specify a package Dec 09 18:50:03 03Roman I Khimov  07org.openembedded.dev * r9c3dfa69e8 10openembedded.git/recipes/at/ (at-3.1.12/at-parallel-make-fix.patch at_3.1.12.bb): Dec 09 18:50:03 at 3.1.12: fix parallel make fix Dec 09 18:50:03 Use dummy target to avoid race with double yacc invocation. Dec 09 18:50:03 Signed-off-by: Roman I Khimov Dec 09 18:50:06 just bitbake Dec 09 18:50:13 true Dec 09 18:50:13 well, what do you expect? Dec 09 18:50:20 bitbake doesn't read your mind to know what you want to build Dec 09 18:50:27 lol, no Dec 09 18:50:41 is there any "world" recipe ? Dec 09 18:50:59 like my portage world file Dec 09 18:51:31 world is reserved word :) Dec 09 18:53:14 eFfeM: is this recipe upstream ? Dec 09 18:53:19 khem, yes Dec 09 18:53:59 world is magic Dec 09 18:54:06 what does it do? Dec 09 18:54:12 let me try to reproduce it. If you are lucky I will reproduce it Dec 09 18:54:13 it builds every provider, unless that provider is provided by multiple recipes, in which case it builds the preferred one Dec 09 18:54:21 khem: http://cgit.openembedded.org/cgit.cgi/openembedded/tree/recipes/mediatomb/mediatomb_0.11.0.bb Dec 09 18:54:25 so it builds everything, but for e.g. virtual/kernel, it only builds the preferred kernel Dec 09 18:54:34 i see Dec 09 18:54:38 remember that bitbake was based on portage originally, so world *should* seem familiar to you Dec 09 18:54:49 :) Dec 09 18:55:03 khem, thanks (it is configure to find js), btw I compiled for armv5te (sheevaplug), distro minimal Dec 09 18:55:08 also, this behavior was the same in 1.8. you hvae to specify a package to build, and world builds everything Dec 09 18:55:21 but remember that OE has, what, nearly 8,000 recipes or something now -- you *really* don't want to build world Dec 09 18:55:38 it'll take a long time just to construct the runqueue to start the build, and the actual build is likely to take a week Dec 09 18:55:38 well... my current real problem is bitbake console-image does nothing Dec 09 18:55:43 what do you mean? Dec 09 18:55:58 you're going to have to elaborate when you report a problem, ideally a pastebin of the exact output or error you're seeing Dec 09 18:56:08 nothing at all Dec 09 18:56:12 i get a new prompt Dec 09 18:56:20 eFfeM: as long as arch is arm it should be reproducable Dec 09 18:56:21 interesting Dec 09 18:56:24 try 1.10. Dec 09 18:56:32 git checkout -b 1.10 origin/1.10 Dec 09 18:56:34 in the git repo Dec 09 18:56:36 bitbake -D console-image the same Dec 09 18:56:38 then run it again Dec 09 18:56:45 khem, will try to create a small usecase using the code generated by configure Dec 09 18:56:50 kk Dec 09 18:56:56 its likely that the error is occurring too early on, before the UI exists to display the error, a bug in bitbake Dec 09 18:57:05 with 1.10 you're certain to see it, or nearly so Dec 09 18:57:08 03Frans Meulenbroeks  07org.openembedded.dev * r4537344b82 10openembedded.git/recipes/initrdscripts/initramfs-uniboot_1.0.bb: Dec 09 18:57:08 initrdscripts/initramfs-uniboot_1.0.bb: DESCRIPTON -> DESCRIPTION Dec 09 18:57:08 (saw this on the poky ML) Dec 09 18:57:08 Signed-off-by: Frans Meulenbroeks Dec 09 18:57:18 03Frans Meulenbroeks  07org.openembedded.dev * r2d32ea408f 10openembedded.git/: Merge branch 'org.openembedded.dev' of git.openembedded.org:openembedded into org.openembedded.dev Dec 09 18:57:24 eFfeM: well one way is that you add STAGING_DIR/lib to -L Dec 09 18:58:07 eFfeM: its good to do git log before pushing Dec 09 18:58:12 khem, would that help? anyway it seems worth trying Dec 09 18:58:56 kergoth_, what is each of the UIs good for? Dec 09 18:59:09 ncurses/depexp (which seems to like -g)/knotty Dec 09 18:59:23 knotty is the default UI, the commandline, noninteractive one Dec 09 18:59:33 khem, true, actually did a pull just before it and forgot the --rebase (actually in config I also have autosetuprebase = always but that does not seem to work as I expected) Dec 09 18:59:42 afk for a while Dec 09 18:59:49 there's an ncurses one which isn't working at the moment, the idea with that one is its like the commandline one, but has a separate window for the current active tasks, and one to input commands like -i used to, but its not there yet Dec 09 18:59:51 i.e. the one you get when building a package off command-line or running other commands, Dec 09 19:00:03 bitbake foo -> runs knotty Dec 09 19:01:27 i'll have to try 1.10 - using -u depexp -g i get a nice gtk-based window, next a progress bar "parsing metadata" and next a crash Dec 09 19:02:39 If I run configure on the target, what does it use for CFLAGS? Dec 09 19:02:52 03Martin Jansa  07master * rd1f84edcb2 10openembedded.git/recipes/webkit/ (4 files in 2 dirs): Dec 09 19:02:52 webkit-efl: bump SRCREV and add patch for scrolling issue Dec 09 19:02:52 Signed-off-by: Martin Jansa Dec 09 19:06:50 CMoH: knotty is the only one that's getting attention right now. Dec 09 19:07:01 though the poky/yocto folks have done some work on goggle recently Dec 09 19:07:11 so i take that back, but its still the primary Dec 09 19:07:38 also, you shouldn't need -g if you're using depexp, they're independent pieces of functionality Dec 09 19:17:17 yeah, before i handed it a package to build Dec 09 19:17:53 hmmm - it seems to work with 1.10.1 Dec 09 19:18:03 err 1.10.0 Dec 09 19:22:07 i guess i'll see the results in 2-3 hours :( Dec 09 19:23:41 it's much faster than 1.8 though with runqueue and these things Dec 09 19:24:23 master is faster yet than 1.10, particularly with the parsing. not sure why you're seeing problems with it Dec 09 19:32:05 03Khem Raj  07master * rc1facf79a2 10openembedded.git/recipes/js/js_1.5.bb: Dec 09 19:32:05 js_1.5.bb: Beat it to respect LDFLAGS Dec 09 19:32:05 * Fixes QA errors like below Dec 09 19:32:05 ERROR: QA Issue with js: No GNU_HASH in the elf binary: Dec 09 19:32:05 '/scratch/oe/work/armv7a-oe-linux-gnueabi/js-1.5-r2/packages-split/js/usr/lib/libjs.so' Dec 09 19:32:32 eFfeM: hmmm I have libtool 2.4 and mediatomb needs to update libtool macros I think Dec 09 19:32:38 so I get bitten Dec 09 19:33:34 khem, I have another issue Dec 09 19:33:44 gcc -v -o hello hello.c -mfloat-abi=hard Dec 09 19:33:48 leads to failiure Dec 09 19:33:51 on target Dec 09 19:34:24 http://pastebin.com/2t6QAkBJ Dec 09 19:35:28 eFfeM: http://pastebin.com/kBLMTUxn Dec 09 19:35:51 Crofton|work: thats wrong usage for OE armv7/gcc Dec 09 19:36:04 we dont support hard float abi Dec 09 19:36:06 yet Dec 09 19:36:08 what is the right usage Dec 09 19:36:11 I want to fo that Dec 09 19:36:38 just gcc -v -o hello hello.c should select correct float abi Dec 09 19:36:54 -mfloat-abi=softfp Dec 09 19:37:00 is the one you should use Dec 09 19:38:26 hmm Dec 09 19:38:34 I need to figure out why I am confused Dec 09 19:39:27 there are two things one is presense of FP hardware itself second is using FP registers in ABI to pass function arguments Dec 09 19:39:35 yeah Dec 09 19:39:48 so you have two params Dec 09 19:39:56 kergoth_, unfortunately i don't have the time to learn how to debug it in order to get you a good bug report Dec 09 19:39:56 ok, there is code in tune-cortexa8 to switch it Dec 09 19:40:01 -mfpu and -mfloat-abi Dec 09 19:40:03 but iti is still using softfp Dec 09 19:40:07 CMoH: np, hopefully i'll run into it at some point Dec 09 19:40:09 but if you assist me i'd be willing to do it Dec 09 19:40:29 mfpu tells the compiler that you can use fpu for generating code Dec 09 19:40:34 i'm not sure how without sprinkling prints in the code :) Dec 09 19:40:45 hi, it seems that anoncvs.handhelds.org(128.31.0.23):2401 is down so I can't fetch ipkg Dec 09 19:40:57 -mfloat-abi tells it that you should use FP registers according to ABI when passing params to functions Dec 09 19:41:02 yeah Dec 09 19:41:07 as i really not care a about ipkg is there a way ho to disable building it? or build opkg instead? Dec 09 19:41:11 I have some understanding of the differences :) Dec 09 19:41:20 it isn't fetching ipkg, its fetching ipkg-utils, most likely Dec 09 19:41:23 we don't build ipkg anymore Dec 09 19:41:26 -mfloat-abi=softfp says that calling conventions do not use FP regs Dec 09 19:41:30 yeah ipkg-utils, sorry Dec 09 19:41:31 kergoth_, is it possible to run bitbake from within the git repo? i mean without installing it into /usr etc Dec 09 19:41:42 CMoH, yes Dec 09 19:41:54 just set your path to the git repo bitbake/bin I thinnk Dec 09 19:41:56 I do that Dec 09 19:42:19 yep Dec 09 19:42:31 at one time that was the only way to run it ;) Dec 09 19:42:46 only crazy people install bitbake Dec 09 19:42:51 hehe Dec 09 19:43:04 lol Dec 09 19:43:25 i really quite like the idea, but the problem is its disassociated from OE. i'd really rather use buildout or git submodule or something in the oe repo to pull down exactly the version it needs, but.. Dec 09 19:43:28 i'd also ask you on how to make a .deb off it (i'm not familiar with ubuntu but...) Dec 09 19:43:57 the debian metadata isn't maintained upstream, the debian folks do it Dec 09 19:44:12 you'd have to copy the debian dir from their source package and modify it to create a package for 1.10 Dec 09 19:45:26 i see - thanks Dec 09 19:49:25 so how can i get rid of ipkg-utils? Dec 09 19:51:22 you don't. its required to build opkg-based root filesystems Dec 09 19:51:31 the tarball is available on our mirrors, as far as i know Dec 09 19:51:38 the native is Dec 09 19:51:40 handhelds.org is down and isn't coming back, apparently. Dec 09 19:54:53 yup Dec 09 19:55:02 the problem is in setup.py it seems Dec 09 19:55:18 i've updated bitbake-9999.ebuild to use the git repo Dec 09 19:55:47 now running it directly from the git repository it works; installing it via the ebuild produces an unusable bitbake Dec 09 19:56:38 what's the behavior? Dec 09 19:56:52 it does nothing Dec 09 19:57:10 gah, we haven't killed those prints of unpackaged files, particularly in the kernel, yet? Dec 09 19:57:16 this is agonizingly slow Dec 09 20:01:15 kergoth_ thanks, so if I download it manually and put it in sources it bypass the do_fetch task? Dec 09 20:01:38 ashen: yeah, do_fetch only fetches what it has to. if its already there, it should skip it and move on Dec 09 20:21:42 kergoth_: errr...got link to mirror with tarballs? I can't find anything;o/ Dec 09 20:34:58 Applying patch fix-ecore-fb-initialization.patch fails... Dec 09 20:35:00 is it normal? Dec 09 20:35:36 is it a problem on my side(my computer just powered off due to empty battery) Dec 09 20:46:14 khem, was afk, thanks for the patch, thought it was a js issue, I have libtool 2.4 too, saw your pastebin, will give it a shot Dec 09 20:46:21 thanks for your help Dec 09 20:50:35 * kergoth_ decides to temporarily use github for the bitbake todo - https://github.com/kergoth/bitbake/wiki/TODO Dec 09 20:52:25 kergoth_: looks good enough there Dec 09 20:52:38 none of the other UIs work right now, I'm playing with them a bit Dec 09 20:53:23 cool, that's a good idea Dec 09 20:53:55 they all must be quite old - all reference MsgBase and puke, and event.sofar for ParseProgress Dec 09 20:54:09 * kergoth_ nods Dec 09 20:54:19 current master has some updates for goggle from poky for some of that Dec 09 20:54:25 ok Dec 09 20:54:29 i was just playing with goggle Dec 09 20:54:34 perhaps i need to look at what they did Dec 09 20:56:18 cute, i like that github backs their wikis with git Dec 09 20:56:31 * Jay7 have described how kexecboot works on kexecboot.org Dec 09 20:57:16 I need some native english speaker to fix texts there :) Dec 09 20:57:23 03Eric BĂ©nard  07org.openembedded.dev * r8c56bc9a03 10openembedded.git/recipes/meta/meta-toolchain.bb: (log message trimmed) Dec 09 20:57:23 meta-toolchain: fix directories rights Dec 09 20:57:23 Actual sdk change rights of /usr and /usr/local to 775 when Dec 09 20:57:23 untaring the archives with sudo ... giving group write access Dec 09 20:57:23 to these directories. Dec 09 20:57:32 03Klaus Schwarzkopf  07org.openembedded.dev * ra5781edff2 10openembedded.git/recipes/opensync/msynctool_0.22.bb: Dec 09 20:57:32 msynctool_0.22: fixed SRC_URI Dec 09 20:57:32 Signed-off-by: Klaus Schwarzkopf Dec 09 20:57:32 Signed-off-by: Eric BĂ©nard Dec 09 20:57:37 03Klaus Schwarzkopf  07org.openembedded.dev * r157adffd31 10openembedded.git/recipes/asterisk/asterisk_1.2.24.bb: (log message trimmed) Dec 09 20:57:37 asterisk_1.2.24: Set correct Checksum Dec 09 20:57:37 Tilghman Lesher wrote on asterisk-users@lists.digium.com: Dec 09 20:57:37 Due to a licensing issue with some of the files we distributed with previous Dec 09 20:57:37 tarballs, we removed those files from archived tarballs in order to avoid Dec 09 20:57:45 u2nl_1.3: fixed SRC_URI Dec 09 20:57:45 new version avalible. Dec 09 20:57:46 Signed-off-by: Klaus Schwarzkopf Dec 09 20:57:46 Signed-off-by: Eric BĂ©nard Dec 09 20:57:47 03Klaus Schwarzkopf  07org.openembedded.dev * r21747e1784 10openembedded.git/recipes/redfang/redfang.bb: Dec 09 20:57:47 redfang: fixed SRC_URI Dec 09 20:57:48 Signed-off-by: Klaus Schwarzkopf Dec 09 20:57:55 Signed-off-by: Eric BĂ©nard Dec 09 20:57:55 03Klaus Schwarzkopf  07org.openembedded.dev * r2a53e4713e 10openembedded.git/recipes/dasher/dasher-gpe_0.0-svn.bb: Dec 09 20:57:56 dasher-gpe_0.0-svn: fixed SRC_URI Dec 09 20:57:56 Signed-off-by: Klaus Schwarzkopf Dec 09 20:58:01 and goggle is broken afaik, even with their changes Dec 09 20:58:05 Signed-off-by: Eric BĂ©nard Dec 09 20:58:05 03Klaus Schwarzkopf  07org.openembedded.dev * r5a0067a970 10openembedded.git/recipes/esc/esc-gst_6.bb: Dec 09 20:58:05 esc-gst_6: fixed SRC_URI Dec 09 20:58:05 Signed-off-by: Klaus Schwarzkopf Dec 09 20:58:05 Signed-off-by: Eric BĂ©nard Dec 09 20:58:06 03Klaus Schwarzkopf  07org.openembedded.dev * r75abfabf5b 10openembedded.git/recipes/gtk2-ssh-askpass/gtk2-ssh-askpass_0.3.bb: Dec 09 20:58:06 gtk2-ssh-askpass_0.3: fixed SRC_URI Dec 09 20:58:14 03Klaus Schwarzkopf  07org.openembedded.dev * r038f37dc6c 10openembedded.git/recipes/litestream/litestream_1.3RC3.bb: Dec 09 20:58:14 litestream_1.3RC3: fixed SRC_URI Dec 09 20:58:15 Signed-off-by: Klaus Schwarzkopf Dec 09 20:58:16 Signed-off-by: Eric BĂ©nard Dec 09 20:58:16 03Klaus Schwarzkopf  07org.openembedded.dev * rebf2b36c38 10openembedded.git/recipes/mathomatic/mathomatic_12.4.2.bb: Dec 09 20:58:17 mathomatic_12.4.2: fixed SRC_URI Dec 09 20:58:17 Signed-off-by: Klaus Schwarzkopf Dec 09 20:58:18 Signed-off-by: Eric BĂ©nard Dec 09 20:58:18 03Klaus Schwarzkopf  07org.openembedded.dev * re4d21b8c78 10openembedded.git/recipes/esc/esc-media_5.bb: Dec 09 20:58:26 Signed-off-by: Klaus Schwarzkopf Dec 09 20:58:26 Signed-off-by: Eric BĂ©nard Dec 09 20:58:27 03Klaus Schwarzkopf  07org.openembedded.dev * rc8c00df694 10openembedded.git/recipes/maxima/maxima_5.21.1.bb: Dec 09 20:58:27 maxima_5.21.1: fixed SRC_URI Dec 09 20:58:28 Signed-off-by: Klaus Schwarzkopf Dec 09 20:58:29 Signed-off-by: Eric BĂ©nard Dec 09 20:58:29 03Klaus Schwarzkopf  07org.openembedded.dev * rfb73531e5c 10openembedded.git/recipes/scsi-idle/scsi-idle_2.4.23.bb: Dec 09 20:58:30 scsi-idle_2.4.23: fixed SRC_URI Dec 09 20:58:30 Signed-off-by: Klaus Schwarzkopf Dec 09 20:58:37 Signed-off-by: Eric BĂ©nard Dec 09 20:58:37 03Klaus Schwarzkopf  07org.openembedded.dev * rff004eb674 10openembedded.git/recipes/sidplay-base/sidplay-base_1.0.9.bb: Dec 09 20:58:37 sidplay-base_1.0.9: fixed SRC:URI Dec 09 20:58:37 Signed-off-by: Klaus Schwarzkopf Dec 09 20:58:37 Signed-off-by: Eric BĂ©nard Dec 09 20:59:29 kergoth_: the recent changes to goggle don't make it work in master, so I don't know what they were doing :) Dec 09 20:59:58 in fact, the main culprit is RunningBuild, which references outdated event types Dec 09 21:00:17 they were making it work with poky's bitbake, i would assume -- i'm sure there's more to be done to get it working with master from there Dec 09 21:00:23 ah Dec 09 21:00:26 i'm on it Dec 09 21:00:28 :) Dec 09 21:00:40 * foerster is having fun not working on work stuff today Dec 09 21:00:52 kergoth_: foerster: what do you call ui when talking of bitbake ? (maybe stupid question sorry) Dec 09 21:01:10 ericben: master supports multiple user interfaces. Dec 09 21:01:23 kergoth_: not really :) Dec 09 21:01:26 the default commandline one, as well as an X11 dependency explorer, a broken ncurses interface, etc Dec 09 21:01:28 it's supposed to, but doesn't Dec 09 21:01:31 well, in theory, it should Dec 09 21:01:33 yeah :) Dec 09 21:01:56 kergoth_: ah ok. How can I try this ? Dec 09 21:01:57 i'm going to fix up RunningBuild now to fix some of the problems Dec 09 21:02:06 this is part of why i have thought the UIs should be separated from bitbake proper, as separate python scripts which import bb and do their thing Dec 09 21:02:22 some of bitbake's commandline options make no sense for some UIs Dec 09 21:02:49 ok bitbake -u things in lib/bb/ui Dec 09 21:02:57 ericben: yes Dec 09 21:03:51 of course, we could always put the broken UIs on a branch, too -- nothing in the tree should be broken when we do a release Dec 09 21:04:51 well, we'll see if we can easily fix any of them Dec 09 21:04:55 but, we're in danger of causing 'bitbake' to have more dependencies on python modules just for specific UIs, keeping them all in one repo Dec 09 21:05:05 * kergoth_ nods Dec 09 21:05:30 easiest way is to remove -u from options for now Dec 09 21:05:40 that's true Dec 09 21:05:55 or, only list knotty Dec 09 21:06:09 if someone wants to run another, they can still specify it directly Dec 09 21:06:15 thats probably best, as we know from -i, user's really dislike commandline options vanishing :) Dec 09 21:06:22 s/'s/s/ Dec 09 21:06:52 yea, i see references to -i, but in docs and everything, but found that it doesn't exist Dec 09 21:07:38 hmm, we could create a 'daemonize' UI, which spawns a bitbake server with an xmlrpc interface and prints the connection info, for use by potential non-python UIs (e.g. eclipse plugin) Dec 09 21:07:47 (later on) Dec 09 21:08:07 yes. Dec 09 21:08:40 of course, to do that either the process server would need an optional mechanism to add an xmlrpc server, or the UI would need to be the one controlling the spawn of the server Dec 09 21:10:32 is ecore broken? Dec 09 21:11:03 or is it me(computer battery finished in the middle of a build) Dec 09 21:11:15 Applying patch fix-ecore-fb-initialization.patch fails... Dec 09 21:11:50 GNUtoo|laptop: hi, what is the name of the recipe (I can try it now) Dec 09 21:12:07 else I can try to fix Dec 09 21:12:09 ecore_svn Dec 09 21:12:12 and look into it Dec 09 21:12:19 just that I had other stuff to do Dec 09 21:12:23 such as going to bed Dec 09 21:12:26 (tired) Dec 09 21:13:06 hi btw Dec 09 21:16:22 cool pandaboard should ship in 3 days only 3 weeks late not bad Dec 09 21:17:29 GNUtoo|laptop: answer in a few seconds, other tasks are building and ecore should come soon Dec 09 21:18:14 ok thanks Dec 09 21:18:20 GNUtoo|laptop: ecare is configuring so the patch seems to be applied Dec 09 21:19:06 ah strange then Dec 09 21:19:10 I'll look Dec 09 21:19:13 GNUtoo|laptop: 1 second I was not on head Dec 09 21:19:15 thanks a lot Dec 09 21:19:49 I suspect packaging staging and already-applied patches Dec 09 21:19:52 GNUtoo|laptop: restarting build Dec 09 21:20:01 I cleaned and still nothing Dec 09 21:20:24 ahhh ok Dec 09 21:20:25 sorry Dec 09 21:20:32 basically I cleaned ecore Dec 09 21:20:35 and not ecore-native Dec 09 21:20:41 I only looked at the recipe name Dec 09 21:20:47 sorry Dec 09 21:21:39 3622 tasks remaining I was on stable ;) Dec 09 21:22:00 so if you don't get news from me that means ecore_svn builds Dec 09 21:23:35 ericben, ^^^ Dec 09 21:23:41 should be an error from my side Dec 09 21:27:45 03Andreas Oberritter  07org.openembedded.dev * rf7f9648d31 10openembedded.git/recipes/vsftpd/vsftpd_2.0.5.bb: Dec 09 21:27:45 vsftpd-2.0.5: don't run pkg_postinst on host Dec 09 21:27:45 Signed-off-by: Andreas Oberritter Dec 09 21:34:01 03Andreas Oberritter  07org.openembedded.dev * r186d009f4c 10openembedded.git/recipes/libsdl/pushover_0.0.1.bb: Dec 09 21:34:01 libsdl: depend on virtual/libsdl instead of libsdl-x11 Dec 09 21:34:01 Signed-off-by: Andreas Oberritter Dec 09 21:34:04 03Andreas Oberritter  07org.openembedded.dev * r1b5ee5b117 10openembedded.git/recipes/python/python-pygame_1.9.1.bb: Dec 09 21:34:04 python: depend on virtual/libsdl instead of libsdl-x11 Dec 09 21:34:04 Signed-off-by: Andreas Oberritter Dec 09 21:34:06 03Andreas Oberritter  07org.openembedded.dev * r618653b0b6 10openembedded.git/recipes/efl1/ecore.inc: Dec 09 21:34:06 efl1: depend on virtual/libsdl instead of libsdl-x11 Dec 09 21:34:06 Signed-off-by: Andreas Oberritter Dec 09 21:34:09 03Andreas Oberritter  07org.openembedded.dev * r561f8a77b5 10openembedded.git/recipes/vlc/ (vlc.inc vlc_0.9.2.bb): Dec 09 21:34:09 vlc: depend on virtual/libsdl instead of libsdl-x11 Dec 09 21:34:09 Signed-off-by: Andreas Oberritter Dec 09 21:34:23 03Andreas Oberritter  07org.openembedded.dev * r062dbf9ad8 10openembedded.git/recipes/quake/ (4 files): Dec 09 21:34:23 quake: depend on virtual/libsdl instead of libsdl-x11 Dec 09 21:34:23 Signed-off-by: Andreas Oberritter Dec 09 21:34:35 03Andreas Oberritter  07org.openembedded.dev * r18d59f5fad 10openembedded.git/recipes/ffmpeg/ (ffmpeg.inc ffmpeg_svn.bb): Dec 09 21:34:35 ffmpeg: set default license to GPLv2+, because --enable-gpl is used. Dec 09 21:34:35 * See http://www.ffmpeg.org/legal.html Dec 09 21:34:35 Signed-off-by: Andreas Oberritter Dec 09 21:34:40 03Andreas Oberritter  07org.openembedded.dev * re9e434d00a 10openembedded.git/recipes/libtheora/libtheora_0.9+1.0alpha7.bb: Dec 09 21:34:40 libtheora: depend on virtual/libsdl instead of libsdl-x11 Dec 09 21:34:40 Signed-off-by: Andreas Oberritter Dec 09 21:34:53 03Andreas Oberritter  07org.openembedded.dev * rba6079a882 10openembedded.git/recipes/nogravity/nogravity_2.0.bb: Dec 09 21:34:53 nogravity: depend on virtual/libsdl instead of libsdl-x11 Dec 09 21:34:53 Signed-off-by: Andreas Oberritter Dec 09 21:35:05 03Andreas Oberritter  07org.openembedded.dev * r6fccd90300 10openembedded.git/recipes/gstreamer/gst-plugins-bad_0.10.20.bb: Dec 09 21:35:05 gst-plugins-bad: update EXTRA_OECONF (mjpegtools, sdl) Dec 09 21:35:05 * Fix build with mjepegtools installed, by disabling mpeg2enc and mplex. Dec 09 21:35:05 The configure script of gst-plugins-bad wants to use AC_TRY_RUN for Dec 09 21:35:05 both of them, which doesn't work when cross-compiling. Dec 09 21:36:40 can someone please comment on the future of CVS_TARBALL_STASH? i think it should at least be removed from the documentation and from local.conf.sample, if bitbake >= 1.10 doesn't support it Dec 09 21:39:40 We need to set a flag day or something for dropping bitbake 1.8 support Dec 09 21:39:48 (and thus bumping python min up too) Dec 09 21:50:11 Tartarus, bug the tsc :) Dec 09 21:53:25 some of the build systems I support use OpenDNS which unfortunately uses redirects on many HTTP errors. This results in bitbake fetching the OpenDNS 'wrapper' as a source which then fails. Would it make sense to use a wget FETCHCOMMAND that has --max-redirect=0 to avoid this? any reason why this wouldn't be desireable for default behavior? Dec 09 21:54:42 tharvey: seems like it's conceivable that the canonical way to fetch a source may involve redirects Dec 09 21:56:12 it may be possible to traverse the redirect chain and keep bitbake updated with "the end of the linked list", but some package homes may update the redirect chain frequently Dec 09 21:56:12 yes, I suppose so Dec 09 21:57:23 URL restructuring, moving to a different hosting provider, redirect from http://path/to/server/latest to http://path/to/server/, things like that Dec 09 21:58:00 maybe we could just look at the fetched source and do a sanity check to see if it is an error message or the legit tarball Dec 09 21:58:16 ya... guess the best approach is to avoid using evil redirectors like opendns Dec 09 21:58:18 check to see if the "file" utility recognizes it as it's purported file type Dec 09 21:58:32 or if it's bigger than some nominal size, ~2KB Dec 09 21:58:52 You know? Dec 09 21:59:00 Optional integrity checking would be great Dec 09 21:59:15 and catch these Dec 09 21:59:18 wouldn't want to avoid integrity check - in this case the fetch is foobar Dec 09 21:59:36 Right Dec 09 21:59:42 And the integrity check will catch Dec 09 21:59:46 more interested in detecting the bad fetch to go on and try a mirror instead of thinking its good Dec 09 21:59:51 oh... I follow Dec 09 22:00:13 you mean bitbake check the md5 and if fail try a mirror before bailing? Dec 09 22:00:17 No Dec 09 22:00:18 wait. tharvey, how does it continue if the md5sum is foobared? Dec 09 22:00:22 I mean *.bz2 -> bzip2 -t Dec 09 22:00:24 and so on Dec 09 22:00:31 kergoth_: https://github.com/foerster/bitbake/commit/c5ec30133257d7cc1eda6fcec70dd4110e0769f4 Dec 09 22:00:44 mrj10, it doesn't continue - bitbake fails. What I'm after is avoiding the failure by trying a mirror Dec 09 22:00:50 ah, i see Dec 09 22:00:58 Tartarus, that would work... Dec 09 22:01:06 like that better than assuming a filesize Dec 09 22:01:08 strange that it doesnt do that already, seems like a good idea Dec 09 22:03:07 any bb'ers want to add that? kergoth ? :) Dec 09 22:18:33 khem: any idea concernign this gcc error : http://tinderbox.openembedded.net/public/logs/task/8666826.txt Dec 09 22:18:37 ? Dec 09 22:20:37 tharvey: is there any benefit to putting the filesize AND md5sum in the recipe, so for a particular failure you mostly know whether it is due to incorrect filesize or due to in-network or on-disk bit-flippage? Dec 09 22:20:51 khem: where trying samba-3.5.6 I get this one : http://pastebin.com/yuiYX2CM Dec 09 22:21:27 mrj10, that sounds like too much overhead to metadata - I like the optional quicktest of tarballs idea Dec 09 22:22:14 ericben, run the gcc command from the command line and try to reduce the compiler flags to identify if there is a culprit Dec 09 22:22:26 kergoth_: depexp back to life now too: http://erafx.com/tmp/screenshot-depexp.png Dec 09 22:22:34 nice Dec 09 22:22:43 grg: I'm trying to identify the reason Dec 09 22:23:02 at some point itd be cool to create something that lets you visually navigate the graphviz graphs, click around to get details, etc Dec 09 22:23:09 someday.. Dec 09 22:23:22 yea. Well, now that we have some good basics back to functional, that's a start! Dec 09 22:23:29 yep, definitely Dec 09 22:23:31 tharvey: yeah, i agree, there are upsides but the overhead likely outweighs me Dec 09 22:23:58 * kergoth_ just realized he forgot to add i18n stuff to the TODO.. unicode chars in variable names, translation of bitbake internal messages, etc.. Dec 09 22:24:05 i'm checking now whether libmagic (what "file kergoth_: goggle works, but it doesn't show much data other than tasks running Dec 09 22:24:34 * foerster doesn't know what all it's supposed to do anyway Dec 09 22:24:55 * kergoth_ either Dec 09 22:25:08 ugh Dec 09 22:25:08 it used to capture MsgBase and take action based on MsgWarn, MsgError, etc Dec 09 22:25:21 were those moved elsewhere into other event classes, or what? Dec 09 22:25:28 foerster: busybox do_configure hangs when using teh split server, not with master, somehow Dec 09 22:25:28 kergoth: do we need more features or a more specialized tool than what already exists for navigating large graphviz graphs? Dec 09 22:25:43 kergoth_: fml Dec 09 22:25:44 :) Dec 09 22:25:46 foerster: we use LogRecord from the python logging module now, it carries a log level which translates to debug/warn/error/etc Dec 09 22:25:53 is it T status? Dec 09 22:26:00 yep Dec 09 22:26:03 e.g. http://code.google.com/p/jrfonseca/wiki/XDot , http://zvtm.sourceforge.net/zgrviewer.html http://www.kde.org/applications/graphics/kgraphviewer/ Dec 09 22:26:08 how many levels deep? Dec 09 22:26:14 php 5.3.3 does that to me Dec 09 22:26:16 every time Dec 09 22:26:19 too many Dec 09 22:26:20 :) Dec 09 22:26:22 but not in master Dec 09 22:26:33 the last 5 levels of processes are all T Dec 09 22:26:37 i think it's doing it -- thinking we're a fork bomb maybe? Dec 09 22:26:41 hmm Dec 09 22:26:56 the weird thing is, the only difference between this and master is *ONE* extra process Dec 09 22:27:00 wtf? Dec 09 22:27:04 i know Dec 09 22:27:23 i have a new php recipe here for newest version which does the exact same. Dec 09 22:27:27 no idea why Dec 09 22:27:37 maybe i should try a runqueue rewrite sooner rather than later, persist the workers in a pool, no re-forking for every task Dec 09 22:27:42 see if that helps Dec 09 22:28:45 not sure, that's some bullshit though if the system thinks we're forkbombing :) Dec 09 22:29:11 limit of num processes is umlimited here, so i dunno Dec 09 22:30:24 yeah, very strange. my first thought was it was an attempted read from stdin -- do_configure's can hang that way if they prompt blind instead of checking to see if its a tty Dec 09 22:30:30 but that wouldn' tmake any sense given master works Dec 09 22:30:55 right, nothing in that regard changed Dec 09 22:32:02 (speaking of which, the way bb.build handles all the file descriptor stuff is ugly as hell, we need to get that stuff using subprocess) Dec 09 22:32:20 I haven't even looked in there yet Dec 09 22:32:42 does dup'ing of fds to get them redirected to the log or tee Dec 09 22:32:53 pre-subprocess that was probably a fine way to get it done, but.. Dec 09 22:33:26 this T thing is just strange. hmm Dec 09 22:33:29 * kergoth_ googles Dec 09 22:33:40 i couldn't find anything Dec 09 22:33:48 :( Dec 09 22:33:56 the processes are being sent a SIGSTOP (or SIGTOSTOP, etc) Dec 09 22:34:02 but i have no idea how to find out who Dec 09 22:34:22 my guess would be the kernel or the shell Dec 09 22:34:43 hm Dec 09 22:35:54 tharvey: python-magic provides bindings to libmagic, which looks to support all the filetypes we need (mostly just gzip and bzip2). would need to ascertain whether a (optional, perhaps) dependence on that would be acceptable. if not, i think we can implement simple magic-number-based tests ourselves for the small subset of source types we care about Dec 09 22:36:48 let me know if you can find anything. This is the last biggie I think there is with the process server :) Dec 09 22:36:53 i'm out for now Dec 09 22:36:53 sound more reasonable than looking for filename extensions Dec 09 22:36:54 later Dec 09 22:37:07 later Dec 09 22:38:11 yeah, it can detect a broader range of nefariousness on the part of your DNS provider, ISP, or other intermediaries (airport wifi gateway) Dec 09 22:40:51 heh, gotta love it when you wget a tarball and get an html file Dec 09 22:41:06 really annoying for sure Dec 09 22:42:28 kergoth_, what do you think about an optional per-type integrity check based off the magic of the file? Dec 09 22:42:43 doesn't seem unreasonable Dec 09 22:43:05 i have a patch somewhere that implements do_unpack using python's modules for it, sadly too slow, but checking integrity likely isn't Dec 09 22:45:55 just checking the magic gets you 99.9% of the way there, it seems like Dec 09 22:46:08 nice Dec 09 22:47:52 well, it might be useful to differentiate between a valid .bz2 file that just happens not to pass md5sum, which might indicate some URL changes on the server, and something that's not a .bz2 file at all Dec 09 22:48:38 doesn't seem like you'd have bitbake actually *do* anything different for one vs. the other, but you could have a more informative error message Dec 09 22:48:41 all of the fetching and unpacking stuff is likely to be rewritten in the near future Dec 09 22:48:58 what are those of you with ancient build systems using for the python2.6 requirement for bitbake master? my u7.10 system doesn't have packages for it - not sure if its a can of worms to build and install manaully Dec 09 22:49:00 bb.fetch is being replaced by a new module which handles fetching and unpacking, so is able to be smarter about "unpacking" things like scm repositories Dec 09 22:49:18 oh, nice Dec 09 22:49:38 tharvey: i found a buildout that builds a local python of whatever version you like, and gives you a virtualenv for it Dec 09 22:49:45 that's what i usually use, personally Dec 09 22:50:07 sounds reasonable.... do you recall where you got it? Dec 09 22:50:32 heh... my build system is getting more and more archaic and difficult to deal with - I'm going to be at a full chroot soon Dec 09 22:50:44 in fact I would switch now if there was a quick simple howto for that Dec 09 22:51:20 if all you want is a chroot from a debian based system, its pretty straightforward Dec 09 22:51:23 debootstrap to build it Dec 09 22:51:35 then i usually use schroot to enter it, since it manages the bind mounts for /proc, etc automatically Dec 09 22:52:25 tharvey: http://svn.plone.org/svn/collective/buildout/python Dec 09 22:52:52 then edit buildout.cfg and you can see what python versions it'll build, i just killed all but the one i wanted Dec 09 22:52:57 both under extends and parts Dec 09 22:53:04 then python bootstrap.py; bin/buildout Dec 09 22:53:08 so basically you install a VM of a debian ver that you want, then use debootstrap on it? are there bootstrap readily avail to avoid the process of setting up the VM? Dec 09 22:53:35 what distro are you running? Dec 09 22:55:32 ubuntu Dec 09 22:56:38 ubuntu has debootstrap pkg but I was more curious how I could get a quick for example u8.04 bootstrap w/o creating an u8.04 vm Dec 09 22:57:07 liked your previous reasons for building on an 'old' system, but perhaps not as old as my current u7.04 system :P (I don't have perms to update it) Dec 09 22:59:34 03Philip Balister  07org.openembedded.dev * r5806128d5b 10openembedded.git/recipes/uhd/uhd_git.bb: uhd : Bump SRCREV to pick up latest uhd fixes. Dec 09 22:59:34 03Philip Balister  07org.openembedded.dev * r6c0ce137ba 10openembedded.git/recipes/autoconf/autoconf.inc: autoconf : Bump PR after earlier revert. Dec 09 23:03:04 tharvey: debootstrap can build either debian or ubuntu chroots of a variety of versions Dec 09 23:03:14 hmm Dec 09 23:03:21 not sure how old they go though Dec 09 23:03:40 for rpm based distros there are a few similar tools, febootstrap, mock, etc Dec 09 23:03:51 * kergoth_ was trying to construct a set of useful chroots at one point Dec 09 23:04:25 ah... I thought it just built from your host system - I'll read up on it - thanks Dec 09 23:04:28 for debian i have.. etch, lenny, potato, sarge, sid, squeeze, and woody Dec 09 23:04:40 no, it pulls the packages from the apt feeds for what its building Dec 09 23:05:53 what is diff between debootstrap and cdebootstrap? Dec 09 23:05:59 no idea :) Dec 09 23:06:08 last time i tried the c one though it didn't have the config files necessary to do much Dec 09 23:06:11 i'd stick to the regular one Dec 09 23:06:15 k Dec 09 23:06:37 do a dpkg -L debootstrap|grep debootstrap/scripts Dec 09 23:06:42 those are the ones you have to choose from Dec 09 23:06:54 or ls /usr/share/debootstrap/scripts ;) Dec 09 23:25:44 ah ha Dec 09 23:26:10 Some signals cause a process to stop: SIGSTOP (stop!), SIGTSTP (stop from tty: probably ^Z was typed), SIGTTIN (tty input asked by background process), SIGTTOU (tty output sent by background process, and this was disallowed by stty tostop). Dec 09 23:26:17 SIGTTIN looks promising here Dec 09 23:26:27 the question is why the behavior would be different with the server Dec 09 23:26:28 hmmmm Dec 09 23:30:57 oh fuck it, i'm changing bb.build to use subprocess Dec 09 23:31:21 arg Dec 09 23:31:38 i2c-dev.h gets staged from two packages it appears Dec 09 23:34:45 kergoth_: is bb master usable now? Dec 09 23:50:30 Jay7: should be, yes Dec 09 23:50:36 its all i use Dec 09 23:50:48 ok, I'll run TB tonight Dec 09 23:51:10 will build images for my zauruses to test on real HW Dec 09 23:51:14 weekend is coming :) Dec 09 23:52:26 :) Dec 09 23:52:31 seems perl is problem for yocto/poky too Dec 09 23:54:30 People who write Makefiles by hand should be shot Dec 09 23:55:00 i2c-tools installs a file called i2c-dev.h into include/linux Dec 09 23:55:07 over writing the version from the kernel Dec 09 23:55:14 there we go Dec 09 23:55:22 bb.build uses bb.process, which is oe.process, which uses subprocess Dec 09 23:55:23 :) Dec 09 23:55:36 *much* simpler Dec 10 00:06:59 Crofton|work, people who use autotools should be shot :) Dec 10 00:07:13 heh Dec 10 00:07:28 i agree though, there are some bad makefiles out there Dec 10 00:08:03 the i2c-tools ones are not grim, except where they overwrtite the kernel header I need Dec 10 00:08:15 dinner time though, so it will wait until the morning Dec 10 00:35:26 does bitbake need python-pysqlite2 (it's ubuntu package)? Dec 10 00:38:08 i see for 1.8.18 both gentoo and ubuntu add it as dependency Dec 10 00:38:25 yes, you need that or something else to provide the db Dec 10 00:38:36 bitbake will complain/mention what the choices are if you don't have it installed Dec 10 00:38:37 for the cache? Dec 10 00:39:13 hmm... i just uninstalled it from my ubuntu machine and bitbake didn't - i know it has a sanity check from the time when i installed it first time Dec 10 00:39:32 i'm using the git 1.10.1 tag for testing Dec 10 00:39:47 its behavior - therefore my question here Dec 10 00:44:06 well... i guess further tests will yield an answer Dec 10 00:44:21 khem: concerning samba compilation problem (tested on armv5) : gcc-4.5 : fails (in fact it's -O2 which makes it fail, compiling rpc_parse/parse_prs. with -O0 works fine) gcc-4.5 without linaro patches : builds fine, gcc-4.5.2-rc (svn 167585) without linaro patches : builds fine. Linaro targets armv7 so maybe we should not include their patches for arm < v7 to avoid trouble ? Dec 10 00:48:13 ericben: usually linaro patches are generic arm Dec 10 00:48:29 ericben: and if there are issues we find then we should raise it with linaro guys Dec 10 00:48:39 eventually those linaro changes are going upstream Dec 10 00:48:46 so we will hit it now or later Dec 10 00:49:04 ericben: but thank you big for identifying that its a linaro problem Dec 10 00:49:16 khem: ok, I'll try to identify the patch creating the problem Dec 10 00:49:33 ericben: if you have time fine otherwise dont bother Dec 10 00:49:59 what you can do is send me the preprocessed file which caused the crash Dec 10 00:50:12 I will then reduce it and see what can be done Dec 10 00:50:25 and meanwhile use -O0 workaround for non armv7 arms Dec 10 00:50:27 for samba Dec 10 00:50:30 khem: do you plan to update the linaro patch serie ? there are new svn commits 99421 to 99440 Dec 10 00:50:30 if thats ok Dec 10 00:50:39 ericben: yes Dec 10 00:51:24 ericben: so if you send me the preprocessed output it will make my life easier to verify if its already fixed or not Dec 10 00:51:50 khem: generating the file Dec 10 00:53:19 merci Dec 10 00:56:27 ericben: I see the patch for gcc 4.5.2 from you Dec 10 00:56:41 ericben: better would be identify the false commit Dec 10 00:56:49 and we can disable that for non armv7 Dec 10 00:57:12 ericben: I want toolchain versions to be manageable its already too many there Dec 10 00:57:22 maintaining them becomes a nightmare Dec 10 00:57:36 khem: yes, but isn't it useful to have a gcc-4.5.2 (stable version due next week) instead of having a moving 4.5 ? Dec 10 00:58:16 I understand having many revisions is hard to maintain but shouldn't we at least provide the latest stable ? Dec 10 01:03:13 khem: OK mail sent Dec 10 01:04:08 03Khem Raj  07master * ra91b9a2922 10openembedded.git/recipes/gcc/ (7 files): Dec 10 01:04:08 gcc/gcc-cross/gcc-cross-intermediate: Generate libgcc_s.so as a linker script stub Dec 10 01:04:08 Signed-off-by: Khem Raj Dec 10 01:04:08 Acked-by: Eric BĂ©nard Dec 10 01:09:00 ericben: as gcc development goes once they start a release branch like 4.4 or 4.5 then its only open for bugfixes Dec 10 01:09:28 ericben: and 4.5.1 = 4.5.0 + bugfixes and gcc-4.5.2 = gcc-4.5.1 + bug fixes Dec 10 01:09:31 and so on Dec 10 01:09:40 at anytime the branch is better than the last rec Dec 10 01:09:42 rev Dec 10 01:10:01 thats why we decide to track the branch rathar then releases Dec 10 01:10:17 and this way we can keep using and moving forward without much hassle at all Dec 10 01:10:37 while this is true for gcc other projects may have more radical dev model where we can not do this Dec 10 01:10:43 depends on project to project Dec 10 01:11:06 ericben: once 4.5.2 release we will move to that Dec 10 01:11:09 essentially Dec 10 01:11:24 I hope its understandable Dec 10 01:12:22 khem: ok I understand this. The question is are linaro patches as stable & tested as is the gcc branch ? Dec 10 01:12:41 ericben: well linaro is a new thing Dec 10 01:12:50 my understanding is that linaro only targets armv7 so I'm not sure they test their optimizations on armv4 v5 or v6 Dec 10 01:12:52 it just started this year sometime Dec 10 01:13:15 ericben: they target armv7 sure but there goal is also do no harm to other arms Dec 10 01:13:32 so we can provide them valuable feedback Dec 10 01:13:32 yes I know this project is recent and thanks to hrw explanation I now understand what is their goal :) Dec 10 01:14:03 eventually all linaro patches should land in upstream gcc Dec 10 01:14:11 yes. The only problem is to have a gcc which can be unstable and is used as a default for minimal, angstrom 2010.x and other distros Dec 10 01:14:34 ericben: well linaro patches are from CSL toolchain Dec 10 01:14:42 so I believe they are high quality Dec 10 01:15:07 some of their patch come from CSL, not all (or it's not marked as this in the log) ? Dec 10 01:15:12 and yes there can be regressions like the one with apache that we are seeing Dec 10 01:15:19 but we need to help linaro to go forward Dec 10 01:15:22 whee Dec 10 01:15:37 bb.build is completely switched to using a new bb.process module now, finally got the kinks worked out of -D Dec 10 01:15:38 ericben: 99% are from CSL Dec 10 01:15:38 btw, do you know the future of CSL now mentor purchased them ? Dec 10 01:15:45 ah ok Dec 10 01:15:47 few patches related to version bump are not :) Dec 10 01:15:50 believe me Dec 10 01:15:51 :) Dec 10 01:15:57 I have seen them 1 by 1 Dec 10 01:16:13 kergoth_ is their lord Dec 10 01:16:16 ask him Dec 10 01:16:17 :) Dec 10 01:16:41 * kergoth_ has no idea what the plans are, never know with acquisitions Dec 10 01:16:58 ericben: I wonder whats the perf gain on say armv4 with linaro patches Dec 10 01:17:13 ericben: I bet its better than vanilla gcc 4.5 Dec 10 01:17:34 leave armv7 where its clear that it will kick ass Dec 10 01:17:35 khem: if I find time I'll try to run nbench to see on an arm920t Dec 10 01:17:43 ericben: cool you are my man Dec 10 01:17:56 khem: but I'm quite sure this will be next year :-D Dec 10 01:18:04 * khem was delegating benchmarking it to ericben indirectly Dec 10 01:18:22 no worries its better than never Dec 10 01:18:49 there are two issues right now thats reported against 4.5 in OE Dec 10 01:18:54 w.r.t code generation Dec 10 01:18:57 one is this one Dec 10 01:19:03 and there is another one bugzilla Dec 10 01:19:08 which I am verifying against trunk Dec 10 01:19:16 and that seems to be generic issue Dec 10 01:19:41 in fact I was quite unluncky today, while a training, I told a guy : look OE is good to compile big things like apache or samba and I tried samba ... and that failed ;-) Dec 10 01:20:11 too bad samba issue is known to us Dec 10 01:20:17 eFfeM_work ran into Dec 10 01:20:22 JaMa also ran into it Dec 10 01:20:32 you should follow IRC closely :) Dec 10 01:20:59 khem: unfortunatly 24h/day is not enough :-D Dec 10 01:21:09 you can now tell the guy that yes shit happens but we are on top of it Dec 10 01:21:42 ericben: I have keyword highlights and I leave it running and it keeps filtering messages for me when I am not here Dec 10 01:21:43 he saw this with the sdk problem that your patch fixed yesterday evening :) Dec 10 01:21:54 then I come and read them and I know what I am interested in Dec 10 01:22:18 khem: interesting one day I'll look how to configure irssi to do this kind of thing ;-) Dec 10 01:22:22 yeah probably we should start raising bugs in bugzilla Dec 10 01:22:24 for reference Dec 10 01:22:31 and not leave it here Dec 10 01:22:35 or on the mailing list Dec 10 01:22:54 I am not too happy with our ml archiving Dec 10 01:23:00 we should do a better job Dec 10 01:23:02 irc is cool for direct discussion but diving in irc archives is quite a pain Dec 10 01:23:26 I think using bugzilla more effectly is a good way Dec 10 01:23:59 for mailing list it's easier : you can subscribe and use mail client to search into the mails and use the mails as a big knowledge database :) Dec 10 01:24:36 but yes bugzilla is here to track bugs Dec 10 01:25:27 the only thing is not to be lazy and file the bug into bugzilla Dec 10 01:26:59 well bugzilla is same Dec 10 01:27:10 and it send mail to ml too Dec 10 01:27:28 so we should use it more Dec 10 01:28:35 yes I do think so Dec 10 01:28:52 and its on reliable infra Dec 10 01:29:40 I consider bugzilla a tool more than just a bug tracker Dec 10 01:29:54 you can do nice things using it w.r.t projects Dec 10 01:38:04 ok bug filed Dec 10 01:39:26 :) Dec 10 01:39:29 goota go now Dec 10 01:39:33 are you sure the mail goes to the list ? Dec 10 01:39:46 time to go to bed. bye ! Dec 10 01:39:47 should if not we can set it up Dec 10 01:57:05 woot! Dec 10 01:57:10 * kergoth does a little dance Dec 10 01:59:14 i just got past the last issue remaining with the separated ui/server :D Dec 10 01:59:38 excellent Dec 10 02:00:10 fixing bb.build to use subprocess did it, i suspect its the close_fds, something with one of the open fds in the worker Dec 10 02:00:15 was hoping that was the case Dec 10 02:32:39 kergoth: you got it fixed? Dec 10 02:32:50 no longer see it with bb.build using subprocess Dec 10 02:33:16 interesting Dec 10 02:33:41 indeed. i hate doing something like that, not really knowing the root cuase Dec 10 02:33:43 *but* Dec 10 02:33:52 i found a thing that stated what can cause a process to stop Dec 10 02:33:56 it's not just SIGSTOP Dec 10 02:34:09 right, ttin, ttout Dec 10 02:34:09 there's a different event that stops a process if the process tries to read from a tty while its backgrounded Dec 10 02:34:11 yeah Dec 10 02:34:20 thats my working theory, but i have no idea what fd its trying to read or why :P Dec 10 02:34:27 but none of those are backgrounded, are they? Dec 10 02:34:51 not sure what the definition of backgrounded is, from the perspective of what's sending the signal Dec 10 02:35:08 either way, the bb.build change had to happen, so we'll see -- if it crops up again we can dive into it again Dec 10 02:35:19 i have a test case here that fails every time for me Dec 10 02:35:26 so i can try your change and see if it fixes it too Dec 10 02:35:55 my local php 5.3.3 recipe goes to sleep every time Dec 10 02:35:59 that would be good, give me second Dec 10 02:36:24 okay, the top 3 commits on my github master Dec 10 02:36:42 was surprisingly painless to get done Dec 10 02:36:57 ok, i'll bring em in and try it Dec 10 02:37:44 the only real headache was implementing tee in python for the shell tasks Dec 10 02:38:01 but that was fairly minor Dec 10 02:39:01 fml Dec 10 02:39:14 php didn't fail any more (before bringing in your change) Dec 10 02:39:23 wtf Dec 10 02:39:34 it was broken 100% every time for the past week Dec 10 02:39:42 i had to keep switching back to master to get past it Dec 10 02:39:51 wait Dec 10 02:39:52 lied Dec 10 02:39:57 i thought it was in do_configure Dec 10 02:40:01 it's in do_compile, just went to sleep Dec 10 02:40:05 ah Dec 10 02:40:08 good Dec 10 02:40:27 \_ sh -c pear -q info PHP_Archive 2>/dev/null|grep 'API Version' Dec 10 02:40:37 that is where it's causing problems. Dec 10 02:40:39 huh Dec 10 02:40:41 ok, let me bring those in Dec 10 02:40:52 php does some crazy shit during compile :) Dec 10 02:41:18 apparently Dec 10 02:49:45 ok, running again Dec 10 02:52:24 woo Dec 10 02:52:26 kergoth: fixed Dec 10 02:52:53 nice **** ENDING LOGGING AT Fri Dec 10 02:59:57 2010