**** BEGIN LOGGING AT Mon Nov 29 02:59:57 2010 Nov 29 05:05:55 hi all Nov 29 05:22:08 FFS... why are we building uclibc without large file support? Nov 29 05:22:36 every second library is broken Nov 29 05:22:48 because large file support assumes a certain amount of RAM? Nov 29 05:23:21 but disabling large file support doesnt work anyway Nov 29 05:24:02 i can't beleive that its ever worked Nov 29 05:24:26 Is the problem disabling it, or trying to make it a machine feature? (I'm not sure if it was enabled or disabled originally) Nov 29 05:24:53 its a DISTRO_FEATURE, which is not enabled for micro-uclibc Nov 29 05:25:12 so presumably micro-uclibc has always been broken Nov 29 05:25:46 last week i fixed enough things to get micro-image building. But console-image is just failure after failure... Nov 29 05:26:00 Hmmm... Looking at my notes I see that it is partially enabled and partially not on the legacy SlugOS distro builds. Not sure what the status is on the latest builds; never tried it! :) Nov 29 05:26:21 hiya mwester Nov 29 05:26:23 But that's not uclibc, so perhaps that would explain the lack of issue there. Nov 29 05:26:30 greetings mr. ka6sox. Nov 29 07:02:31 gm Nov 29 07:48:48 good morning Nov 29 07:57:20 hi mckoan Nov 29 08:00:38 mckoan: can you unpin mythtv in kaeilos-2009-preferred-versions.inc ? kaeilos is the only one left pinning this version (angstrom moved to 0.23 last weekend) Nov 29 08:19:22 eFfeM_work: sure thx Nov 29 08:19:28 03Marco Cavallini  07master * r130df6b03b 10openembedded.git/conf/distro/include/kaeilos-2009-preferred-versions.inc: kaeilos-2009-preferred-versions.inc: upgraded mythtv to 0.23 Nov 29 08:22:32 mckoan: thanks, I will expire 0.22 later today, that one had some issues and was not maintained any more anyway Nov 29 08:54:09 ka6sox: nice, so if you have some spare time, it would be nice if you can test it :) I just have ts7250 and ts7800 available Nov 29 08:59:01 ynezz, maybe later this week. pretty busy one for me. Nov 29 09:10:05 ka6sox: take it easy, I'm pretty busy till January/2011 also... Nov 29 09:35:40 hi all, I had given a bitbake base-image .. and even after all steps are over without error i am not able to find the Nov 29 09:36:00 uImage and u-boot.bin files Nov 29 09:36:37 also anyone know whether the openembedded can create the ramdisk.gz and ramfs.img files ..? Nov 29 09:38:12 The channels seems so sleepy without any response.. Nov 29 09:39:04 ranjith: look into deploy subdir of your TMPDIR Nov 29 09:39:07 Can anyone atleast say the time when the channel will be alive ..? Nov 29 09:40:05 hm.. i hvae looked in the folder ~/build/tmp/deploy/glibc/images/beagleboard Nov 29 09:40:09 ranjith: about 20-23 hours in CET Nov 29 09:40:22 ok Nov 29 09:40:33 +-2-4 hours :) Nov 29 09:40:41 its ok.. Nov 29 09:40:48 thanks for that information.. Nov 29 09:41:03 and regarding the beaglboard foder under deploy.. Nov 29 09:41:30 i found files with names uImage-2.6.32-r91+gitr5fc29e7b2a76a64a739f857858ef0b98294aa155-beagleboard Nov 29 09:41:39 ranjith: this is kernel image Nov 29 09:41:48 and u-boot-beagleboard-2010.03+r66+gitrca6e1c136ddb720c3bb2cc043b99f7f06bc46c55-r66 Nov 29 09:41:50 ok Nov 29 09:42:12 Is there a OE-port for m68k hardware? Nov 29 09:42:31 i tried using these u-boot and uImage files to boot my Beaglboard xm Nov 29 09:42:42 but it says no u0boot.bin found Nov 29 09:43:07 i had also renamed these files respectively as uImage and u-boot.bin Nov 29 09:43:12 hm.. not sure where to look for u-boot.bin Nov 29 09:43:19 ok Nov 29 09:43:21 ah, yes Nov 29 09:43:28 second is u-boot Nov 29 09:44:03 ranjith: ask on #beagleboard about that files Nov 29 09:44:10 ok Nov 29 09:45:00 any idea about where the ramdisk.gz and ramfs.img files will be in oe directory structure..? Nov 29 09:45:12 or these files are not created by oe..? Nov 29 09:46:02 not sure about this.. Nov 29 09:46:36 imho you can ask this on #beagleboard too but say that you asking about OE case Nov 29 09:47:25 does angstrom-distribution have xm image? Nov 29 09:48:34 the beagleboard xm is coming with a card which has angstrom in it.. so angstrom might be having the xm image .. Nov 29 09:48:59 there you go. Nov 29 09:53:23 ranjith: man find Nov 29 09:53:51 ka6sox: I guess beagleboard target should work for beagleboard-xm as well Nov 29 09:54:10 only difference being, beagleboard-xm doesn't have NAND memory in it.. Nov 29 09:54:16 eFfeM_work: you mean to use find .. or was asking whetheri got it or not ..? Nov 29 09:54:38 xc0ffee: yes you are right.. Nov 29 09:54:45 find in timdirfor those files Nov 29 09:54:51 find in tmpdir for those files Nov 29 09:55:41 ranjith: basically this not user or distro support channel, so your questions are really offtopic here and to be honest pretty basic... Nov 29 09:55:42 you probably need to have a file called 'boot.scr' which is supposed to manage the problem of no NAND device.. Nov 29 09:56:45 but, as per http://markmail.org/message/z5sqbigmdyhgiqp2, even if the decice doesn't have boot.scr, everything should work on the fly.. Nov 29 09:56:48 give it a try Nov 29 09:56:50 the build/tmp/deploy/glibc/images/beagleboard/dir has files for uImage and u-boot but what my doubt was whether we can generate the ramdisk.gz and ramfs.img files using oe.. Nov 29 09:56:58 anyway i shall askin #beagle. Nov 29 09:57:25 xc0ffee: ok.. i shall try that. Nov 29 09:57:42 grg: stll awake? Nov 29 09:58:33 * ant_work hopes he isn't after one night of uclibc-fixing ;) Nov 29 09:58:43 xc0ffee: but before that i need to findout how to get the ramdisk.gz and ramfs.img files.. Nov 29 09:59:06 eFfeM_work: have you built uclibc images recently or only uclibc++? Nov 29 09:59:18 ah, uclibc saga continues :) Nov 29 09:59:31 yes, I'm a bit surprised it was so broken Nov 29 09:59:33 eFfeM_work: is there any user channel for openembedded ..? Nov 29 10:00:29 yes, see http://www.openembedded.org/index.php/Mailing_lists Nov 29 10:00:41 ah, no irc, just ML Nov 29 10:02:24 ok Nov 29 10:03:03 there's angstrom distro channel somewhere Nov 29 10:03:27 and they have angstrom-users mailing lists also Nov 29 10:03:55 #angstrom Nov 29 10:04:22 ynezz, which version of the opencores ethernet does that patch support? Nov 29 10:04:24 * Jay7 is counting channel activity per hours :) Nov 29 10:06:08 ka6sox: who knows, I don't have ts7300 :) It's patch courtesy of "Ian Thompson " Nov 29 10:06:37 okay, I'll try several different ones. Nov 29 10:06:44 ka6sox: but I thought, that there's some default preloaded in ts7300 which should work with the one in kernel tree Nov 29 10:07:08 right, second ethernet..but no phy. Nov 29 10:08:41 ah Nov 29 10:09:04 daughter card. Nov 29 10:09:49 see if it even enumerates. Nov 29 10:10:12 anyways...up really too late...2am...nn Nov 29 10:11:57 well.. according to overall activity from 2010-05-29 most active hours are 21-22 UTC :) Nov 29 10:13:38 https://spreadsheets.google.com/ccc?key=0AhY8lmfkCabTdHprNGE5NDhzQlFsTWt4SnhqNUdlNHc&authkey=CM2hpfQP Nov 29 10:13:44 activity graph :) Nov 29 10:26:42 ibot, news Nov 29 10:28:14 ibot: news Nov 29 10:41:31 gm mickey|office, ericben Nov 29 10:42:01 good morning eFfeM_work Nov 29 10:42:19 morning eFfeM_work,hi folks Nov 29 10:50:17 03Graham Gower  07org.openembedded.dev * rcdb73aacf0 10openembedded.git/recipes/util-linux-ng/ (2 files in 2 dirs): Nov 29 10:50:17 util-linux-ng_2.17.bb: Fix for uClibc when DISTRO_FEATURES lacks "largefile". Nov 29 10:50:17 ../shlibs/blkid/src/.libs/libblkid.so: undefined reference to `lseek64' Nov 29 10:50:17 Signed-off-by: Graham Gower Nov 29 10:50:17 Signed-off-by: Eric Bénard Nov 29 10:50:21 03Graham Gower  07org.openembedded.dev * r471555d4ac 10openembedded.git/recipes/gettext/gettext_0.18.bb: (log message trimmed) Nov 29 10:50:21 gettext_0.18.bb: Fix build when uclibc lacks large file support. Nov 29 10:50:21 mipsel-oe-linux-uclibc-libtool: compile: mipsel-oe-linux-uclibc-gcc Nov 29 10:50:21 -march=mips32 -std=gnu99 -DHAVE_CONFIG_H -DEXEEXT=\"\" -DEXEEXT=\"\" Nov 29 10:50:36 03Graham Gower  07org.openembedded.dev * r7defefaf2d 10openembedded.git/recipes/libxml/libxml2.inc: (log message trimmed) Nov 29 10:50:37 libxml2: Fix build when DISTRO_FEATURES lacks "largefile". Nov 29 10:50:37 mipsel-oe-linux-uclibc-libtool: compile: mipsel-oe-linux-uclibc-gcc Nov 29 10:50:37 -march=mips32 -DHAVE_CONFIG_H -I. -I./include -I./include -D_REENTRANT Nov 29 10:50:37 -isystem/mnt/oe/tmp/sysroots/mipsel-oe-linux-uclibc/include Nov 29 10:50:43 -isystem/mnt/oe/tmp/sysroots/mipsel-oe-linux-uclibc/include Nov 29 10:50:43 -fexpensive-optimizations -fomit-frame-pointer -frename-registers -Os -Wall Nov 29 10:50:43 -Wl,-rpath-link -Wl,/mnt/oe/tmp/sysroots/mipsel-oe-linux-uclibc/lib -Wl,-O1 -o Nov 29 10:50:43 .libs/gio-querymodules gio-querymodules.o Nov 29 10:50:44 03Eric Bénard  07org.openembedded.dev * rcb0419cc5f 10openembedded.git/recipes/ (3 files in 2 dirs): Nov 29 10:51:21 CC intel.lo Nov 29 10:51:21 In file included from /mnt/oe/tmp/sysroots/mipsel-oe-linux-uclibc/include/errno.h:29:0, Nov 29 10:51:21 from intel.c:32: Nov 29 10:51:21 /mnt/oe/tmp/sysroots/mipsel-oe-linux-uclibc/include/features.h:216:5: error: #error It appears you have defined _FILE_OFFSET_BITS=64. Unfortunately, uClibc was built without large file support enabled. Nov 29 10:51:22 In file included from /mnt/oe/tmp/sysroots/mipsel-oe-linux-uclibc/include/stdio.h:72:0, Nov 29 10:51:39 03Eric Bénard  07org.openembedded.dev * r3bd272a80f 10openembedded.git/recipes/qt4/ (qt-demo-init/qtdemo-init qt-demo-init_0.1.bb): Nov 29 10:51:39 qt-demo-init: correctly handle qtdemo for qt4-x11 Nov 29 10:51:39 Signed-off-by: Eric Bénard Nov 29 11:13:04 03Koen Kooi  07org.openembedded.dev * r147ee4f35b 10openembedded.git/recipes/ffmpeg/omapfbplay_git.bb: Nov 29 11:13:04 omapfbplay: bump SRCREV for v4l2 fixes Nov 29 11:13:04 Signed-off-by: Koen Kooi Nov 29 11:20:59 03Koen Kooi  07org.openembedded.dev * r152cf43ce7 10openembedded.git/recipes/ti/ (3 files): Nov 29 11:20:59 ti framework components: add version 3.20.00.22 Nov 29 11:20:59 FC 3.x is intended for SYS/BIOS 6 users. DSP/BIOS 5 users (including most DVSDK users) should continue to use FC 2.x releases! Nov 29 11:20:59 Signed-off-by: Koen Kooi Nov 29 13:25:25 Hi, is anyone using libgsmd? Nov 29 13:31:29 hi Nov 29 13:35:16 is there an MACHINE target present that can is use for an atom 330 CPU ? Nov 29 13:40:23 i686? Nov 29 13:49:10 Jay7 i thing its the "ion" target ( asusrock 330 is exactly the moard i have ) Nov 29 13:50:53 damm harddrive chrashed ... need reboot(fix it ) ..(:-(( Nov 29 13:53:11 pwgen: checked Poky? Nov 29 14:36:58 How can I enable core dumps on my beagle? I have no ulimit-function, and can't figure out what provides it. Nov 29 14:43:17 tasslehoff: I think ulimit is part of the shell Nov 29 14:43:45 tasslehoff: on the system I'm currently working on, the busybox shell seems to have a working ulimit Nov 29 14:44:20 tasslehoff: alternatively, I'm sure you could install bash, etc Nov 29 14:45:17 cbrake: hm. yeah. the kernel seems to have it enabled, so probably it's busybox acting up. thanks. Nov 29 14:46:22 kergoth: gm. Found an issue in parallel-parsing. If there is a parse error, it seems to hang at 99% forever. Nov 29 14:46:53 weird. Nov 29 14:46:58 okay, will investigate Nov 29 14:48:05 and if you kill it at that point, the children are left alive Nov 29 14:48:26 foerster: kergoth_: same thing here Nov 29 14:48:36 several ctrl c are required to exit it Nov 29 14:49:11 parse errors are thrown as exceptions, iirc, so just likely need to review the exception handling wrt the multiprocessing usage Nov 29 14:49:56 do anybody using klibc or kexec on mipsel targets? Nov 29 14:51:10 kergoth_: that's correct. An exception is thrown for ParseError Nov 29 14:51:28 kergoth_: btw, the process server works nicely now: https://github.com/foerster/bitbake/compare/parallel-parsing...separate-ui-and-server Nov 29 14:51:51 exception handling is a bit weird in multiprocessing. if i remember correctly, the exception gets thrown both in the child and in the server Nov 29 14:51:58 nice Nov 29 14:52:00 yes Nov 29 14:52:09 I ran into the same problem with Ctrl-C Nov 29 14:52:34 well, similar problem at least. With the signals, they're sent to all processes in the group Nov 29 14:52:38 not sure on the exceptions Nov 29 14:52:53 hmm Nov 29 14:54:05 i don't see shutdown ever being called - could it be that the errored recipe doesn't increment self.current int he parser, so we never trigger that? Nov 29 14:58:14 yeah, i think you're right. current is only incremented as we receive results -- if we got no result for that recipe, the final count wil never hit the total Nov 29 15:01:10 * kergoth_ ponders Nov 29 15:01:41 hm. you could always throw the exception back on the result queue, and check if it's an exception or result Nov 29 15:01:48 yeah i thought about that too Nov 29 15:02:16 the other option would be to not go based on current, do soemthing based on the input queue being empty and the threads being done or not Nov 29 15:02:20 maybe a joinable input queue Nov 29 15:02:44 * kergoth_ gets caffeine Nov 29 15:03:58 joinable queue looks good, but you still need to pass the parse error back some way so we can show it Nov 29 15:04:02 a third option would be to let the child handle sending the UI the exception log message, and hand back an empty list for the recipe info -- if there is no info, we know something broke Nov 29 15:04:34 hrm Nov 29 15:05:22 that reminds me Nov 29 15:05:33 i think its really really really lame the way bb.event figures out if its the worker, etc Nov 29 15:05:36 what kind of crap is that Nov 29 15:05:51 better to just register an event handler than dispatches other events, from the worker Nov 29 15:05:59 Nov 29 15:06:15 yea. I only glanced in there, but was certainly thinking "wtf" Nov 29 15:06:30 then the parse processes could do the same thing, just dispatch the events it fires back to the server via a third queue, or something Nov 29 15:08:00 We can certainly clean up lots of things. When you get a chance, check out the process based server. It's pretty simple, but is a good start to cleaning things up. Nov 29 15:08:07 will do Nov 29 15:08:16 removes some of the odd circular dependencies Nov 29 15:08:19 * kergoth_ is currently catching up on email from the thanksgiving break Nov 29 15:08:23 very good Nov 29 15:08:47 but again, my changes were intentionally left fairly minimal, as I didn't want to overhaul the whole thing in the initial change. Nov 29 15:10:01 its a good step in the right direction, can always improve further as we go Nov 29 15:13:37 does anyone else think its silly that the parsing process doesn't stop when you hit a parse error? Nov 29 15:13:44 it's not going to be able to build anyway Nov 29 15:13:49 so why make us wait before we can go fix it? Nov 29 15:14:40 Yea, I think it's silly Nov 29 15:15:03 pushed the bits to pass back the exception to the server as you suggested, fastest fix Nov 29 15:15:17 long term need to revisit how best to handle all events / log messages from the children Nov 29 15:15:25 ok Nov 29 15:15:37 + result = self.result_queue.get() Nov 29 15:15:38 + if isinstance(result, Exception): Nov 29 15:15:38 + raise result Nov 29 15:15:39 heh Nov 29 15:15:43 easy :) Nov 29 15:15:55 *cough* hack *cough* :) Nov 29 15:15:57 haha Nov 29 15:16:02 hehe Nov 29 15:16:18 no, that's the easiest way, without reworking major parts for now Nov 29 15:16:23 * kergoth_ nods Nov 29 15:17:37 of course, we risk losing traceback information doing it this way, I'm not sure its part of the exceptiono bject Nov 29 15:17:46 and even if it was, traceback info isn't pickleable Nov 29 15:18:03 but, our exception handling is a big pile of crap all over, not just here ;) Nov 29 15:18:28 having the whole thing a single process made for lots of interesting design choices Nov 29 15:18:39 s/choices/accidents/ Nov 29 15:18:43 ;) Nov 29 15:18:55 and having to handle KeyboardInt all over was crappy too. The new process server eliminates that problem at least. Nov 29 15:19:08 * kergoth_ takes a look at that branch Nov 29 15:19:55 now, the UI always handles keyboard int and tells the server to shutdown or whatever. Though, during parsing it doesn't stop nicely, you can just ctrl-c 3 times to force stop though Nov 29 15:20:57 that 3 times thing only really makes sense while tasks are executing. ideally we'd handle it differently when tasks aren't running yet Nov 29 15:22:58 I also played with allowing the UI to register an event mask (to avoid generating 8000 RecipeParsed events), but it didn't seem to make much impact on the overall execution time Nov 29 15:23:48 huh. that's kind of surprising Nov 29 15:25:00 may put it back in to try again. I was playing around with lots of things trying to squeeze some performance, so may have had other items conflicting. Nov 29 15:25:12 foerster: couldn't we avoid saving num_cached and checking for truncation entirely? If it does get truncated, its likely that the pickle.load() will error out on the one that wasn't fully written, and the cache will be seen as invalid. Nov 29 15:26:10 yes, I thought of that. Currently, it's wasteful and just throws away the whole cache. But you're correct, since we're saving entry by entry, we can salvage all that we've read. Nov 29 15:26:11 and of course, we could potentially not ditch the entire cache when one load() fails, now that we save it incrementally. we could rebuild only what we have to Nov 29 15:26:14 * kergoth_ nods Nov 29 15:27:15 I didn't have a chance to dive into any consequences or impact that would have, so haven't looked into it yet. Nov 29 15:28:31 hmm, are you sure you want to change the parsing processes to daemons? that means they won't be automatically joined on exit, which seems dangerous to me, though it avoids the danger of a deadlock.. hmm Nov 29 15:28:35 * kergoth_ thinks Nov 29 15:29:22 "When a process exits, it attempts to terminate all of its daemonic child processes." Nov 29 15:29:26 it just kills them Nov 29 15:30:17 ah, so that makes sure they always end up dead Nov 29 15:30:22 yep Nov 29 15:30:27 cool Nov 29 15:31:13 looks good to me. there's a couple of debugging things commented out that can go away, but for the most part looks good Nov 29 15:31:17 * kergoth_ tests it out a bit Nov 29 15:32:13 Yea, it needs some final clean up. Nov 29 15:33:26 kergoth_: do you use the fork queue to keep up to date with the repo you forked from? It was allowing me to pull in stuff from your repo when y ou pushed, now it's showing me a boatlod of commits. Nov 29 15:33:27 hmm. Nov 29 15:34:11 i did a rebase a while back to clean up the history a bit -- just the 'try this, revert this, try that' stuff, that probably confused it :) Nov 29 15:34:30 hm, ok. that could be. Nov 29 15:34:58 it's showing commits from 2008 up to april of this year. weird. Nov 29 15:35:04 so its likely showing commits that are already in your branch, i just marked the ones i knew i already has as ignored Nov 29 15:35:08 huh, thats weird Nov 29 15:35:43 i changed the integration branch to parallel-parsing, but maybe that's what screwed it up. Nov 29 15:35:50 oh well. Nov 29 15:36:07 well, we're likely getting all this stuff merged in the near future anyway, I wouldn't worry about it too much Nov 29 15:36:30 yea, I was just trying to use github to bring in your latest change, so i could keep mine in sync Nov 29 15:36:33 * kergoth_ nods Nov 29 15:36:36 can always cherry pick it for now Nov 29 15:36:49 yea Nov 29 15:36:53 or rebase -i yours on top of the current pp branch Nov 29 15:36:57 or.. :) Nov 29 15:37:28 should i use fetch from yours, or pull? Nov 29 15:37:38 pull == fetch + merge Nov 29 15:37:46 so that depends on whether you want to use merge or rebase Nov 29 15:38:00 well, my parallel-parsing is the same as yours, minus the latest commit Nov 29 15:38:07 so merge is ok Nov 29 15:39:45 or not :) Nov 29 15:42:36 hmm, looks like pickle.load/pickle.dump end up constructing a fresh Unpickler/Pickler on each call -- doubt its much overhead, but might as well construct it ahead of time instead Nov 29 15:42:38 * kergoth_ pokes at cache.py Nov 29 15:43:42 kergoth_: what's the policy on old, unused code/files? There are a number of things that are broken/unused - should they be removed? Nov 29 15:50:11 I'd say just drop them all, this is what an SCM is for, we can bring them back if we need to Nov 29 15:50:30 good, that's what I was thinking. Nov 29 15:51:36 damn. I need to learn git better. I ended up having to fix a merge conflict with your branch. Now, when trying to rebase my branch, i'm getting more conflicts. bah Nov 29 15:52:19 maybe that's how it's supposed to go, just getting conflicts is frightening :) Nov 29 15:52:28 check into git rerere Nov 29 15:52:36 it records conflict resolutions Nov 29 15:52:43 and will use them again if you ever hit that exact conflict again Nov 29 15:52:49 can be handy when dealing with different branches Nov 29 15:52:51 ah, cool. Nov 29 15:53:23 git config --global rerere.enabled 1 Nov 29 15:53:42 * foerster takes note of rerere Nov 29 15:53:51 never have to run it directly, its automatic Nov 29 15:55:29 now that we can save the cache incrementally, i wonder if we should -- save it as we get it, rather than waiting and doing a big sync at the end Nov 29 15:55:57 worth trying Nov 29 15:56:33 ok, i'm going to bastardize the branch github - pushing after rebase on current parallel-parsing Nov 29 16:03:12 kergoth_: just fyi, i rebased and force pushed separate-ui-and-server Nov 29 16:03:22 yep, looking now Nov 29 16:03:29 * kergoth_ goes to get some food Nov 29 16:11:25 hi all :) Nov 29 16:11:51 is anything wrong with current master branch ? Nov 29 16:12:08 i'm getting a lot of error on a fresh enviroment :( Nov 29 16:40:25 40d081740d35a454181a6389f1b1f85a0c9ce8e1 removed proper handling of busybox' CONFIG_LFS. It should have added a line for CONFIG_FDISK_SUPPORT_LARGE_DISKS and retain the CONFIG_LFS line Nov 29 16:42:33 I'm facing a lot of error while generating the recipe cache :( Nov 29 16:43:17 alx_: pastebin the errors Nov 29 16:43:53 oky Nov 29 16:54:44 blindvt`: ouch, I send a fix for this sorry Nov 29 16:55:25 ericben, TIA Nov 29 16:56:13 blindvt`: where is CONFIG_LFS used ? Nov 29 16:56:47 blindvt`: what mean TIA ? Nov 29 16:57:11 thanks in advance? Nov 29 16:57:45 ah ok ;-) Nov 29 16:58:07 on google I got : "transcient ischemic attack" ;-) Nov 29 16:58:22 lol Nov 29 16:58:25 so I was thinking this was a joke :-D Nov 29 16:58:28 yea, probably not that Nov 29 17:07:10 03Eric Bénard  07org.openembedded.dev * ref3323fac4 10openembedded.git/recipes/busybox/busybox-config.inc: (log message trimmed) Nov 29 17:07:10 fix busybox' CONFIG_LFS Nov 29 17:07:10 blindvt noticed on IRC that : Nov 29 17:07:10 commit 40d081740d35a454181a6389f1b1f85a0c9ce8e1 Nov 29 17:07:10 removed proper handling of busybox' CONFIG_LFS Nov 29 17:08:48 TIA's are not fun Nov 29 17:08:52 mini-strokes Nov 29 17:10:17 hey guys, i deleted the files in my tmp/deploy/images/... dir Nov 29 17:10:36 how do i rebuild them? i tried bitbake again and it didn't work Nov 29 17:11:19 gandhijee: bitbake -c clean then bitbake Nov 29 17:12:41 o Nov 29 17:12:54 bluelightning: does that make it recompile all the packages? Nov 29 17:13:15 gandhijee: no, it will just rebuild the image Nov 29 17:13:19 cool Nov 29 17:13:20 thanks Nov 29 17:13:24 np Nov 29 17:13:36 i've been trying to figure that out all night =/ Nov 29 17:15:44 gandhijee: the reason it won't do it automatically is that there's a stamp file present that says it's already been done Nov 29 17:19:07 bluelightning: can i not make a micro and minimal image? Nov 29 17:19:18 and have them in the deploy? Nov 29 17:22:56 uff pastebin upgrading :( Nov 29 17:23:42 there are other sites - http://pastie.org/ Nov 29 17:25:20 foerster|away, http://pastebin.com/BCnWdABS Nov 29 17:31:21 foerster|away, forgot to say angrstrom/qemux96/bitbake 1.8.19 Nov 29 18:11:31 03Prabindh Sundareson  07org.openembedded.dev * r89afeb7aec 10openembedded.git/recipes/ti/ (3 files): Nov 29 18:11:31 xgxperf: updated to SRCREV 77, fix build failure Nov 29 18:11:31 Signed-off-by: Prabindh Sundareson Nov 29 18:11:31 Signed-off-by: Denys Dmytriyenko Nov 29 18:52:04 Hi. I want to add GSM support. I have been looking around and found gsmd (moko), freesmartphone. There may be others. I want to do GSM 07.10 multiplexing - I want voice and data channels open. I think gsmd is deprecated. Anyone using any of this? Can offer advice? Nov 29 18:52:57 Guys, How I can keep my debug symbols in generated packages? Is there a simple way? I'm generating a lot of stuffs with CLAGS="-g -O0" and appraently, this symbols are being "tractored" Nov 29 18:57:43 gandhijee: separate images should be able to coexist yes Nov 29 18:58:42 fidencio: look for DEBUG_BUILD and INHIBIT_PACKAGE_STRIP options in your local.conf Nov 29 18:58:58 I think they are in the example config file, they just need to be uncommented Nov 29 19:00:01 bluelightning: both are commented Nov 29 19:00:29 bluelightning: many thanks Nov 29 19:00:29 fidencio: ok, you should uncomment both if you want debugging symbols Nov 29 19:00:35 np Nov 29 19:30:04 good morning all ! Nov 29 19:30:29 hi Nov 29 19:30:56 anyone has any patches that should be considered for release please speakup Nov 29 19:36:56 any new issues crop up with parallel parsing, or should I merge it? Nov 29 19:37:15 kergoth_: nothing new here Nov 29 19:37:18 k Nov 29 19:45:29 03Chris Larson  07master * rc7b3ec8195 10bitbake.git/lib/bb/ (cache.py cooker.py): Nov 29 19:45:29 Implement parallel parsing support Nov 29 19:45:29 This utilizes python's multiprocessing module. The default number of threads Nov 29 19:45:29 to be used is the same as the number of available processor cores, however, Nov 29 19:45:29 you can manually set this with the BB_NUMBER_PARSE_THREADS variable. Nov 29 19:45:39 03Chris Larson  07master * r09333737cb 10bitbake.git/lib/bb/cooker.py: Nov 29 19:45:39 cooker: save progress chunk value (total/100) Nov 29 19:45:39 Signed-off-by: Chris Larson Nov 29 19:45:40 03Chris Larson  07master * r64feb03bc2 10bitbake.git/ (lib/bb/ui/knotty.py lib/progressbar.py setup.py): Nov 29 19:45:40 Experimental usage of the 'progressbar' module Nov 29 19:45:46 Signed-off-by: Bob Foerster Nov 29 19:45:46 03Chris Larson  07master * r992cc25245 10bitbake.git/lib/bb/ (cache.py cooker.py): (log message trimmed) Nov 29 19:45:47 cache: create and use a RecipeInfo class Nov 29 19:45:47 This class holds the particular pieces of information about a recipe which are Nov 29 19:45:48 needed for runqueue to do its job. Nov 29 19:45:48 By using it, I think we improve code clarity, reduce method sizes, reduce Nov 29 19:45:49 overuse of primitive types, and prepare for parallel parsing. In addition, Nov 29 19:45:51 this ditches the leaky abstraction whereby bb.cache attempted to hide the Nov 29 19:45:51 03Chris Larson  07master * r1e0c4dbcbe 10bitbake.git/lib/bb/cache.py: Nov 29 19:45:53 poor CIA Nov 29 19:45:59 03Chris Larson  07master * rf6d0a5c219 10bitbake.git/lib/bb/cooker.py: (log message trimmed) Nov 29 19:46:00 cooker: show progress bar before initializing the cache Nov 29 19:46:00 This ensures that the time spent loading the cache from disk occurs with the Nov 29 19:46:00 progress bar up. Though the progress bar stays at 0% during this period, I Nov 29 19:46:00 think this is an improvement over the multi-second stall which occurred Nov 29 19:46:12 knotty: drop the ETA from the progressbar for now Nov 29 19:46:12 Currently, the progress bar is an indication of the processing of our recipes, Nov 29 19:46:12 which includes loading the cache file, then for each recipe, either adding the Nov 29 19:46:12 existing cached information to the CacheData or parsing the recipe from disk. Nov 29 19:46:12 These tasks clearly take different amounts of time, so the ETA is unreliable Nov 29 19:46:19 03Chris Larson  07master * rd5a3c78bd0 10bitbake.git/: (log message trimmed) Nov 29 19:46:19 Merge branch 'feature/parallel-parsing' Nov 29 19:46:20 * feature/parallel-parsing: Nov 29 19:46:20 cache: change to more incremental format Nov 29 19:46:21 cooker: pass back child exceptions to the server Nov 29 19:46:21 cache: bump cachever per master Nov 29 19:46:22 cache: ensure 'pn' is included in the pkgvars Nov 29 19:47:16 Without explicitly joining the thread, it's possible for the process to end Nov 29 19:47:16 (e.g. after a bitbake -p) and kill off the thread without waiting for it to Nov 29 19:47:16 exit cleanly. So, register the thread join with atexit. Nov 29 19:47:16 Signed-off-by: Chris Larson Nov 29 19:47:16 03Chris Larson  07master * r4fe4ffbef3 10bitbake.git/lib/bb/cache.py: Nov 29 19:50:47 kergoth_: just thought of it - if we don't store the number of cache entries, we cannot do the cache progress bar Nov 29 19:51:01 ah, good call Nov 29 19:51:31 although, we could use the progress through the file Nov 29 19:51:40 check our position in the file as pickle reads from it Nov 29 19:51:45 * kergoth_ scratches head Nov 29 19:51:48 hmm Nov 29 19:52:04 i was heating up some food an had that "aha" moment Nov 29 19:52:08 hehe Nov 29 19:52:46 well, its easy enough to add the total back if we need to, just bump the cachever again Nov 29 19:52:58 right Nov 29 19:53:03 kergoth: so we can now switch to upstream master of bitbake now ? Nov 29 19:53:08 khem: yep Nov 29 19:53:31 though if you want to do more testing of things, you could test foerster's server rework branch Nov 29 19:53:34 :) Nov 29 19:54:07 kergoth_: may be later Nov 29 19:54:47 kergoth_: I'm doing a fresh build with my version - so far so good. On task 2585 of 5041 :) Nov 29 19:54:48 I think we should seriously consider releasing bitbake 1.11 or 1.12 in the near future with this. not sure if we should do the server rework before or after that, but getting a release out which performs better is important Nov 29 19:54:52 foerster: nice Nov 29 19:55:13 yes, performance of parallel-parsing is a gigantic plus - no longer painful Nov 29 19:56:51 khem: I've problems with klibc for mips Nov 29 19:57:01 JFYI Nov 29 19:57:08 will investigate today Nov 29 19:57:11 Jay7: hmm Nov 29 19:57:36 klibc fails to build for mipsel at least Nov 29 19:57:57 one time it fails to build, second time it fails to install Nov 29 19:58:08 not sure, may be first time was race issue Nov 29 19:58:16 Jay7: how exactly Nov 29 19:58:40 http://tinderbox.openembedded.net/packages/1147180/ Nov 29 19:58:45 this is installation fail Nov 29 19:59:20 http://tinderbox.openembedded.net/packages/1147162/ Nov 29 19:59:26 this is race issue with kernel Nov 29 19:59:39 (not about klibc) Nov 29 20:00:04 well staging_packager seems like some parallel race Nov 29 20:00:05 http://tinderbox.openembedded.net/packages/1146647/ Nov 29 20:00:16 this is fail of klibc do_compile Nov 29 20:00:24 install fail is strange because if this happens for mips it should happen for other arches Nov 29 20:00:30 http://tinderbox.openembedded.net/packages/1146353/ Nov 29 20:00:33 this is same Nov 29 20:00:41 but for minimal Nov 29 20:01:00 it fails on do_compile when I've tried to build linux-kexecboot Nov 29 20:01:01 hmmm compile failure might make sense Nov 29 20:01:06 do u have the build tree somwhere Nov 29 20:01:18 but when I've tried to build klibc it fails on do_install Nov 29 20:01:37 it is master branch Nov 29 20:05:20 * foerster is off to put up xmas lights while it's mild outside (and before wife kills him). Nov 29 20:14:29 03Kristoffer Ericson  07org.openembedded.dev * rbe2d92be96 10openembedded.git/conf/machine/ben-nanonote.conf: Nov 29 20:14:29 /conf/machine/ben-nanonote.conf Nov 29 20:14:29 * Add screen information to machine file Nov 29 20:14:29 Signed-off-by: Kristoffer Ericson Nov 29 20:16:23 khem: I'll ask for picking kristoffer's commit into release branch Nov 29 20:16:31 it does no harm Nov 29 20:16:57 Jay7: ok, DNH is fine but is it needed ? Nov 29 20:17:15 mm.. DNH? Nov 29 20:17:26 ah Nov 29 20:17:31 understood :) Nov 29 20:17:56 khem: it is needed to build any other distro for nanonote Nov 29 20:18:05 because of LOGO_SIZE at least Nov 29 20:18:21 I need this to build linux-kexecboot Nov 29 20:18:39 Jay7: ok Nov 29 20:18:41 thx Nov 29 20:19:46 oh.. other funny klibc build error Nov 29 20:20:09 I suspect it should be used with PARALLEL_MAKE="" Nov 29 20:20:17 hmmm Nov 29 20:20:35 now it was angstrom-2008.1/collie Nov 29 20:21:55 well.. now waiting for locale generation to finish failing :) Nov 29 20:22:51 | /var/tmp/oe/angstrom/arm/work/collie-angstrom-linux-gnueabi/klibc-1.5.20-r1.0/klibc-1.5.20/usr/klibc/../include/sys/resource.h:15: error: conflicting types for 'getrusage' Nov 29 20:22:52 | /var/tmp/oe/angstrom/arm/sysroots/collie-angstrom-linux-gnueabi/kernel/include/linux/resource.h:73: note: previous declaration of 'getrusage' was here Nov 29 20:24:42 hm.. I should do more testbuilds.. I suspect multiple things Nov 29 20:25:54 resource.h should just be symlink to kernel provided resource.h Nov 29 20:27:00 ah.. Nov 29 20:27:16 khem: sorry, it's my side Nov 29 20:27:33 latest errors Nov 29 20:27:50 He he...missing patches Nov 29 20:27:56 I've disabled patches to check mipsel build and have forgot re-enable them Nov 29 20:28:02 stupid me Nov 29 20:28:32 Khem: pls have a look at ML wrt uclibc Nov 29 20:28:50 several failures Nov 29 20:29:27 for both minimal and Angstrom-2008.1 Nov 29 20:29:51 * Tartarus needs to sort out his failures from over the weekend still, ugh Nov 29 20:29:53 patches are there Nov 29 20:29:54 ltrace for x86 is busted Nov 29 20:36:53 Tartarus: hmm Nov 29 20:36:59 what way Nov 29 20:37:18 http://tinderbox.openembedded.net/public/logs/task/11663548.txt Nov 29 20:37:46 ant_mob: do you mean the patches from grg ? Nov 29 20:37:53 ant_mob: yes I will take them Nov 29 20:40:38 Tartarus: which MACHINE/distro Nov 29 20:42:33 foerster|away: looks like a triple-^C to interrupt a parse on your branch doesn't result in syncing what we've parsed so far to the cache, so it has to start over again next build -- that's not the case in master Nov 29 20:43:59 khem: afk, bbl 1 h Nov 29 20:44:04 k Nov 29 20:44:32 khem: minimal/qemux86 Nov 29 20:44:45 Tartarus: hmmm ok Nov 29 20:44:56 I do build this combo Nov 29 20:45:01 which image should I try Nov 29 20:45:56 aint I stupid Nov 29 20:45:57 nm Nov 29 20:46:28 nas-server-image or just ltrace ;) Nov 29 20:48:12 oh boy I built 54 images but none of them build ltrace Nov 29 20:48:43 got sits probably a notch higher than OE Nov 29 20:48:49 s/got/god/ Nov 29 20:48:57 just Nov 29 20:49:23 someone is pounding tinderbox its sooo slow Nov 29 20:52:46 is there a mail archive somewhere which presents OE ml in mbox format ? Nov 29 20:52:58 or raw Nov 29 20:54:32 Tartarus: take that, builds fine for me on two machines Nov 29 20:54:45 thats on uclibc and eglibc each Nov 29 20:55:32 khem: I guess it's getting host stuff :) Nov 29 20:55:50 could be Nov 29 20:55:58 or it's a parellel problem Nov 29 20:56:01 lemme see if arch.h for x86 is ok Nov 29 20:56:14 haven't dug Nov 29 20:56:37 arch.h should define this Nov 29 20:58:21 #define DECR_PC_AFTER_BREAK 1 is there in sysdeps/linux-gnu/i386/arch.h Nov 29 20:58:29 so I wonder why it did not work for you Nov 29 20:59:51 Tartarus: you need to reproduce this I guess Nov 29 21:00:08 and make it fail and hopefully catch the error Nov 29 21:00:12 I can start build of ltrace Nov 29 21:00:16 whis distro/machine? Nov 29 21:00:21 *which Nov 29 21:00:28 Jay7: ok MACHINE=qemux86 DISTRO=minimal Nov 29 21:00:43 I can do it on demand, just don't have the time atm to dig into it :( Nov 29 21:01:09 I see that on both rhel5 and ubuntu804 Nov 29 21:01:10 started Nov 29 21:01:38 Tartarus: Its ok on ubuntu 10.10 and 10.04 AFAICT Nov 29 21:02:14 should be done in a hour Nov 29 21:02:58 hour ? Nov 29 21:03:04 Tartarus: 8.04/hardy? Nov 29 21:03:05 did u do it from scrach Nov 29 21:03:12 higher limit :) Nov 29 21:03:26 yes, clean build Nov 29 21:04:49 s/higher/upper/ Nov 29 21:08:17 hrw: yeah Nov 29 21:09:36 hm.. half of tasks are done Nov 29 21:10:04 * Jay7 dreaming about bitbake UI with overall progress bar Nov 29 21:13:10 bluelightning: I've prepared testbuilder to build from your branch Nov 29 21:13:21 hi Jay7 Nov 29 21:13:24 will run it tonight Nov 29 21:13:31 great :) let me know how it goes Nov 29 21:21:02 bluelightning: your git repo is not fetchable in OE Nov 29 21:21:19 khem: no? what happens? Nov 29 21:21:26 bluelightning: for some reason gitorious has issues with bb git fetcher Nov 29 21:21:39 if I do the git clone on commandline it works Nov 29 21:21:50 but fails when bitbake does it Nov 29 21:21:55 the very same command Nov 29 21:22:03 hmm, that's not good :( Nov 29 21:22:26 I have seen similar problem with another recipe for lnx kernel which is also hosted on gitorious Nov 29 21:22:54 bluelightning: I was trying to use the git recipes of opie Nov 29 21:23:03 thru the inc file you have added Nov 29 21:23:09 but this was no success Nov 29 21:23:14 oh.. Nov 29 21:23:22 so still stuck to old opie recipes Nov 29 21:23:28 many of them dont build with gcc 4.5 Nov 29 21:23:46 we should do brainstorm on this issue imho.. Nov 29 21:23:55 khem: so I hear... haven't had time to test that here Nov 29 21:24:11 bluelightning: btw, khem have fixed opie-notes at least Nov 29 21:24:22 bluelightning: please check recipe and patch Nov 29 21:24:26 Jay7: saw that one, will have to try merging that upstream Nov 29 21:25:16 bluelightning: I would have switched minimal to use git but then gitorious tanked me Nov 29 21:25:42 I still have no clue whats wrong with gitorious interaction with bb git fetcher Nov 29 21:25:48 only difference between git from cmdline and git from bb is tty Nov 29 21:26:02 hmm Nov 29 21:26:04 git started from bb have no tty (afaik) Nov 29 21:26:21 is it expected to be there somehow Nov 29 21:26:32 Jay7: is it the same version of git? are we using git-native or similar Nov 29 21:26:52 bluelightning: I was not seen that bug before Nov 29 21:26:54 bluelightning: I was using git-native Nov 29 21:27:01 will try tonight Nov 29 21:27:05 bluelightning: but same happened with git from build host Nov 29 21:27:55 second possible issue may be e.g. closed stdin Nov 29 21:28:24 or stdout/stderr.. Nov 29 21:28:45 and environment can affect this too Nov 29 21:29:59 bitbake -b openembedded/recipes/opie-notes/opie-notes_cvs.bb -c fetch Nov 29 21:30:02 ERROR: Fetch failed: Unable to fetch URL git://gitorious.org/opie/opie.git;protocol=git;subpath=core/pim/notes from any source. Nov 29 21:32:58 khem: try to change fetcher to show you command line Nov 29 21:33:14 then try to run it w/o tty Nov 29 21:33:19 e.g. via ssh Nov 29 21:33:42 ssh -T Nov 29 21:34:30 and may be -n to redirect stdin to /dev/null Nov 29 21:35:10 khem: I just tried that and it worked here... ? Nov 29 21:35:42 well, to be precise I tried building the 1.2.4 version from my branch, but it's equivalent Nov 29 21:40:15 bluelightning: hmmm Nov 29 21:40:41 khem: I'm currently trying a full opie-image build from my branch, we'll see if anything fails Nov 29 21:41:09 to avoid pain for users we could just upload tarballs for 1.2.4 to the angstrom mirror site Nov 29 21:41:42 bluelightning: yeah Nov 29 21:41:44 when building the *_cvs versions though the git fetcher has to be able to do the job Nov 29 21:41:52 or to sources.openembedded.org Nov 29 21:42:01 send the info to ka6sox Nov 29 21:42:42 bluelightning, do you have opie sources? Nov 29 21:42:57 ka6sox: I do yes Nov 29 21:43:24 this happens on two different machines Nov 29 21:43:27 one at my home Nov 29 21:43:35 and another at osuosl Nov 29 21:43:45 but both run some sort of ubuntu Nov 29 21:44:04 I'm running ubuntu (10.10) here so I suspect that's not it Nov 29 21:45:53 bluelightning: thats the one I am running Nov 29 21:46:05 bluelightning: can you try with bitbake master Nov 29 21:46:15 khem: ok sure Nov 29 21:46:18 I wonder if its something to do with fetcher itself Nov 29 21:46:24 kergoth_: I'll check into that and figure out how to fix it. I have the "shutdown" portion in cooker to handle that, but it's commented out right now b/c it was causing problems. Nov 29 21:46:38 ah Nov 29 21:49:11 kergoth_: also, I was doing a long build, and it got hung up waiting for a compile task, but that process was marked as status T in ps, which means stopped. Weird. Nov 29 21:49:41 without looking into it yet, my guess is it has something to do with queue the communication queue and multiple processing writing or something Nov 29 21:50:52 bluelightning: I recompile all packages and I continuing missing mey debbuging symbols Nov 29 21:51:04 bluelightning: Need I clean all tmp stuffs? Nov 29 21:51:25 fidencio: how did you recompile all packages? Nov 29 21:52:01 khem: it could be... I have to admit I had some issues similar to this before but I assumed it was a transient issue (server problems or such) Nov 29 21:52:54 I updated the svn version in my local.conf and bitbake -v package Nov 29 21:53:10 CFLAGS="-g -O0" bitbabke -v package Nov 29 21:55:37 bluelightning, what versions do you need for Angstrom? Nov 29 21:56:10 ka6sox: 1.2.4 and latest; I am planning on releasing 1.2.5 soon Nov 29 21:56:31 1.2.3 will be removed shortly (change already in my bluelightning/opie-fixes OE branch) Nov 29 21:56:40 bluelightning: or if you move to github then it might work for me :) Nov 29 21:56:52 okay please put the 1.2.4 tarball someplace and the correct md5sum. Nov 29 21:57:04 and I'll get them on the sourcemirror Nov 29 21:57:11 bluelightning: ok cool. when you remove 1.2.3 you should also remove all the recipes that are in OE for that Nov 29 21:57:23 or move them to obsolete Nov 29 21:57:47 ka6sox: unfortunately if you're hoping to make fetching for OE work it might not be that easy, as opie recipes don't all fetch from one single source Nov 29 21:58:02 khem: yep that's what I was planning Nov 29 21:58:07 bluelightning: ok cool Nov 29 21:58:20 bluelightning: I wonder if others also see same problem as me Nov 29 21:58:36 bluelightning: did it work with bb master for you btw ? Nov 29 21:58:44 khem: (removing recipes I mean; moving to github might not be straightforward) Nov 29 21:58:50 bluelightning: ok Nov 29 21:59:07 khem: I'm throwing out my tmp atm, some other issues Nov 29 21:59:46 bluelightning: ok Nov 29 21:59:48 bluelightning, okay I guess we can just break them up into what fits the various recipies Nov 29 21:59:54 you also need to throw out downloads Nov 29 22:00:07 khem: why's that? Nov 29 22:00:17 bluelightning: because thats where the problem is happening for me Nov 29 22:00:20 it cant fetche Nov 29 22:00:29 khem: ah right I see Nov 29 22:00:50 fidencio: if the package is already built, asking it to build again won't rebuild it Nov 29 22:01:13 fidencio: you'd need to do a "bitbake -c clean packagename" first Nov 29 22:01:43 bluelightning: The package was updated. I really need to do it? Nov 29 22:02:32 fidencio: how was it updated? either PR or the version must change for it to be rebuilt otherwise nothing will be done Nov 29 22:02:53 I change the SVN rev in my local.conf Nov 29 22:03:33 ka6sox: tinderbox seems to be kaput Nov 29 22:03:35 ka6sox: yes that would work Nov 29 22:03:51 ka6sox: NOTE: oestats: error sending task, disabling stats Nov 29 22:04:10 khem, I'll look in a minute Nov 29 22:04:12 fidencio: ok, so if the SVN rev was definitely picked up by that recipe then it will be rebuilt Nov 29 22:04:26 fidencio: btw I don't think specifying CFLAGS like that will do anything Nov 29 22:04:36 bluelightning, okay let me know about each packages source package as we add them. Nov 29 22:16:19 khem: ok, just tested and this time "the remote end hung up unexpectedly" :( Nov 29 22:18:10 yo Nov 29 22:18:14 so you got it Nov 29 22:18:28 now retry with your old bitbake Nov 29 22:18:52 somewhere on google I read it was how the git repo was set Nov 29 22:19:00 may be run git gc or something Nov 29 22:19:06 on the repo Nov 29 22:19:12 remote repo I mean Nov 29 22:19:45 We should clean our dl dirs more often Nov 29 22:20:35 khem, Tartarus: ltrace was build fine Nov 29 22:20:46 DISTRO=minimal MACHINE=qemux86 bitbake ltrace Nov 29 22:21:03 http://tinderbox.openembedded.net/builds/107443/ Nov 29 22:44:36 okay so the tarball needs to be busted up so the individual packages can find their source. Nov 29 22:58:15 hmm... avahi may need some butchering to build without ipv6... Nov 29 22:58:44 how safe is it to use sysroot_stage_all_append() to stage additional kernel headers, similar to kernel.bbclass? Nov 29 22:59:27 I mean, using sysroot_stage_all_append() in the recipe Nov 29 23:09:34 khem: it seems to me the glib-2.0 vs.uclibc issue in minimal (gconvert.c:55:2: error: #error GNU libiconv not in use but included iconv.h is from libiconv) is still open Nov 29 23:25:07 khem: argh..now perl_5.8.8.bb fails too... Nov 29 23:25:41 (minimal - uclibc - armv5te) Nov 29 23:27:08 Tartarus: is it normal we build target perl ? seems new to me... Nov 29 23:27:33 in normal images, I mean Nov 29 23:34:44 perl faiuls now 'cause: #error It appears you have defined _FILE_OFFSET_BITS=64. Unfortunately, uClibc was built without large file support enabled. Nov 29 23:34:51 again... Nov 29 23:41:51 same for sqlite :/ Nov 29 23:42:27 khem: definitely long way toward a buildable minimal-uclibc Nov 29 23:44:41 well.. I'm starting opie-images build from bluelightning/opie-fixes branch Nov 29 23:48:40 ant__, its just like eating an elephant Nov 29 23:48:48 do it one bite at a time Nov 29 23:48:54 grg: :p Nov 29 23:49:30 Jay7: ok... am trying to track down what's going wrong with git fetcher Nov 29 23:49:31 grg: whe shoulkd ask blindvt and khem why Nov 29 23:49:39 no large file Nov 29 23:50:26 grg: angstrom builds with older toolchain/uclibc Nov 29 23:50:36 that's just funny Nov 29 23:51:42 ant__, angstrom leaves large file support enabled Nov 29 23:51:52 oh, *just* that? Nov 29 23:52:11 ok, it enables a lot of extra stuff that isnt there for minimal or micro Nov 29 23:52:35 I see, still the sizes make me perplex Nov 29 23:53:56 http://pastebin.ca/2006352 Nov 29 23:53:59 ^^ Nov 29 23:54:23 I'm desperately trying to fulfill that list...just minimal-uclibc missing Nov 29 23:54:45 though, I don't expect big surprises wrt size savings Nov 29 23:56:04 largefile is enabled in minimal-uclibc Nov 29 23:56:11 but not in micro-uclibc Nov 29 23:56:18 khem: hmm. Nov 29 23:56:41 ant__: that issue with libiconv is a catch 22 Nov 29 23:56:46 I never got around to fix it Nov 29 23:56:53 satisfactorily Nov 29 23:58:11 I was lost reading the m4 when I tried first patch around (--with-libiconv=gnu) and somehow worked Nov 29 23:58:43 ant__: I could build x11-image with uclibc Nov 29 23:58:49 for difference arches Nov 29 23:59:00 I think thats how far one could stretch uclibc Nov 29 23:59:13 something is wrong for armv5te Nov 29 23:59:18 I wont be thrilled to compile a gnome image on uclibc Nov 29 23:59:24 its simply out of scope Nov 29 23:59:39 have you seen the size of images? Nov 29 23:59:52 I dont know what, it builds fine here for qemuarm, omap5912osdk Nov 30 00:00:13 well uclibc plays a small role in images of that size Nov 30 00:01:06 he he Nov 30 00:01:09 Syslog support (UCLIBC_HAS_SYSLOG) [Y/n/?] (NEW) Large File Support (UCLIBC_HAS_LFS) [N/y/?] n Nov 30 00:01:14 ^^ Nov 30 00:01:26 x11 image is around 36M Nov 30 00:01:52 her euclibc configures w/out large file Nov 30 00:02:11 ant__: hmmm is that on minimal-uclibc ? Nov 30 00:02:15 minimal Nov 30 00:02:28 well seee there is a difference Nov 30 00:02:40 minimal is for eglibc and minimal-uclibc is for uclibc Nov 30 00:02:46 in essence they are both minimal Nov 30 00:02:49 you get it ? Nov 30 00:03:04 yes, still don't like it Nov 30 00:03:13 why ? Nov 30 00:03:30 angstrom catch 3 libc in one distro (3 includes) Nov 30 00:03:35 DISTRO=minimal-uclibc should be used if you want minimal distro with uclibc Nov 30 00:04:00 well there are many ways to do things and minimal's way is one of them Nov 30 00:04:11 khem: it is clear, user-error at my side ;) Nov 30 00:04:15 I can tell you many ups and downs of both approaches Nov 30 00:04:37 btw. its same for micro Nov 30 00:04:51 there is a micro-uclibc Distro Nov 30 00:04:57 so the LIBC var is pointless Nov 30 00:05:08 setting it, I mean Nov 30 00:05:32 and infact it makes sense to have a separate distro if you chose uclibc because its not compatible with glibc/eglibc and a lot can go wrong Nov 30 00:05:46 yes with minimal LIBC is pointless Nov 30 00:06:15 well you can still choose between eglibc and glibc if you want based on libc Nov 30 00:06:21 that will sort of work Nov 30 00:06:23 in the uclibc case, sure Nov 30 00:06:27 if you have DISTRO=minimal Nov 30 00:06:41 yep, tested both flavours ;) Nov 30 00:06:51 third was playing dirty.... Nov 30 00:07:01 let see minimal-uclibc immediately Nov 30 00:07:08 ok Nov 30 00:07:13 you will be happier Nov 30 00:07:20 he he Nov 30 00:19:08 khem: try editing your bitbake/lib/bb/fetch/git.py and add --progress to the clone command line Nov 30 00:19:19 this seems to make it more reliable for me Nov 30 00:22:59 khem: scratch that, it seems to work without it :/ Nov 30 00:27:52 bluelightning: so I should do nothing ? Nov 30 00:28:10 bluelightning: so it works with older bb ? Nov 30 00:28:17 but not with master is that whats the case Nov 30 00:29:53 I haven't found anything conclusive other than what you've described - that it works outside of bitbake and not within even if you use the same command Nov 30 00:30:09 well, for me sometimes it does work within Nov 30 00:30:18 which makes testing a bit difficult :/ Nov 30 00:30:26 bluelightning: yeah Nov 30 00:30:44 I think it probably has something to do with what Jay7 explained Nov 30 00:30:53 inside fetcher it does not have tty Nov 30 00:30:57 outside it does Nov 30 00:31:16 try to experiment via ssh :) Nov 30 00:31:17 he also explained how to emulate the fetcher behaviour outside of fetcher manualy Nov 30 00:31:28 * Jay7 is still not sleeping.. Nov 30 00:32:00 Jay7: is like windows7 you turn the lid off still the damn machine does not go to sleep :) Nov 30 00:32:15 kinda :) Nov 30 00:32:40 I'm moving sources to nfs Nov 30 00:33:51 khem: build is going on Nov 30 00:34:37 khem: about klibc, see how debian packages it http://packages.debian.org/source/sid/klibc Nov 30 00:34:50 hm.. Nov 30 00:35:06 ant__: have they anything wrt mipsel? Nov 30 00:36:34 03Khem Raj  07master * r928119c972 10openembedded.git/site/powerpc-common: Nov 30 00:36:34 powerpc-common: Cache alignof variables for postgresql Nov 30 00:36:34 Signed-off-by: Khem Raj Nov 30 00:38:46 ant__: libklibc and klibc-utils Nov 30 00:38:49 is what we need I think Nov 30 00:39:15 the -floppy should be our static-utils I suppose Nov 30 00:39:55 we need to fix the paths in klcc (the target one in -dev) Nov 30 00:40:12 is pointing to ssysroot Nov 30 00:40:42 khem, dunno why oestats is being a pill...django is fragmented (with stuff everywhere) I think I'll restart melo :( Nov 30 00:42:41 ka6sox: hmm k Nov 30 00:42:42 khem: try: ssh -T -n localhost "git clone -n http://git.gitorious.org/opie/opie.git /tmp/gitorious.org.opie.opie.git" Nov 30 00:42:55 khem: argh sorry wrong url Nov 30 00:43:08 khem: try: ssh -T -n localhost "git clone -n git://gitorious.org/opie/opie.git /tmp/gitorious.org.opie.opie.git" Nov 30 00:43:24 khem, just tell me when Nov 30 00:44:13 ka6sox: how long will melo be down ? Nov 30 00:44:22 if its few mins then go ahead right now Nov 30 00:44:23 5 minutes? Nov 30 00:44:26 k Nov 30 00:44:27 kk Nov 30 00:44:44 bluelightning: seems to be hung Nov 30 00:45:15 Initialized empty Git repository in /tmp/gitorious.org.opie.opie.git/.git/ Nov 30 00:45:20 thats where its stuck Nov 30 00:45:35 give it some time, it should eventually come back Nov 30 00:45:46 damn, mine worked :( Nov 30 00:46:03 yeah worked Nov 30 00:46:06 here too :) Nov 30 00:46:08 heh Nov 30 00:46:26 its something about gitorious that bb fetcher does not like Nov 30 00:46:58 I wonder if its some sort of return code that it does not like Nov 30 00:47:48 khem: well, right now I can't get it to fail here anymore... so it's intermittent Nov 30 00:48:05 or at least it seems that way to me Nov 30 00:48:49 bluelightning: ok for me with bb fetcher it fails all the time Nov 30 00:49:03 and whateever way I try to reproduce it passes 100% Nov 30 00:49:08 one thing you could try if you're able to make it consistently fail is change over to the http protocol, see if that makes a difference Nov 30 00:49:33 instead of git://gitorious.org use http://git.gitorious.org (in the recipe) Nov 30 00:49:52 nope Nov 30 00:49:56 tried that already Nov 30 00:50:04 doh :( Nov 30 00:50:22 one fine day I will debug it Nov 30 00:50:27 today is not that dat Nov 30 00:52:32 bbfetcher seems quite unhappy with gitorious. Nov 30 00:53:25 khem, its back Nov 30 00:56:22 03Denys Dmytriyenko  07master * r1eaa6f913a 10openembedded.git/recipes/font-update-common/font-update-common_0.1.bb: Nov 30 00:56:22 font-update-common: explicitly set LICENSE to MIT, as part of OE metadata Nov 30 00:56:22 Signed-off-by: Denys Dmytriyenko Nov 30 00:57:36 ka6sox: ok Nov 30 00:58:08 03Denys Dmytriyenko  07master * r508877ce37 10openembedded.git/recipes/policykit/ (policykit_0.9.bb policykit_0.96.bb): Nov 30 00:58:08 policykit: update LICENSE to LGPLv2+ Nov 30 00:58:08 Signed-off-by: Denys Dmytriyenko Nov 30 00:58:25 ka6sox: go to http://tinderbox.openembedded.net/ Nov 30 00:58:28 and click Nov 30 00:58:39 or say http://tinderbox.openembedded.net/packages/ Nov 30 00:58:56 khem, when do you plan on making the release? Nov 30 01:00:02 khem, I see grg's failed build about 45mins ago Nov 30 01:00:08 gnome-vfs Nov 30 01:00:13 :) Nov 30 01:00:15 working on it Nov 30 01:00:31 grg: I think coming friday Nov 30 01:00:36 grg, not something you did... Nov 30 01:01:00 oh tinderbox is better behaved now though slow Nov 30 01:01:24 grg: but now on I am only taking something thats absolutely needed Nov 30 01:01:50 khem, i hope to get micro-uclibc/console-image building... i will have more fixes coming Nov 30 01:03:34 grg: sure, I think I fixed the sdk issues did you try again ? Nov 30 01:04:25 grg: cool. I could take them in as long as they happen to be safe and well before friday Nov 30 01:04:27 khem, yeah, i had other failures... i think it may have been gettext related. So i since fixed gettext and haven't tried meta-toolchain again Nov 30 01:04:44 will get on to that today Nov 30 01:04:52 grg: ok let me know Nov 30 01:05:01 ok time to drive home now Nov 30 01:05:02 ttyl Nov 30 01:05:06 bye Nov 30 01:18:39 nite all **** ENDING LOGGING AT Tue Nov 30 02:59:57 2010