**** BEGIN LOGGING AT Mon Apr 18 02:59:57 2011 Apr 18 05:34:22 hii Apr 18 05:36:02 i am having trouble in updating kernel from 2.6.32 to 2.6.38 Apr 18 05:36:21 it fails on do_stage Apr 18 05:36:44 can anyone help?? Apr 18 05:38:23 ?? Apr 18 07:21:59 ping stefan_schmidt Apr 18 07:22:50 woglinde: pong Apr 18 07:23:03 * stefan_schmidt is looking to a week of great weather :) Apr 18 07:23:43 hm your patchweekend wasnt this sucessfull Apr 18 07:24:31 woglinde: like the ones before... Apr 18 07:24:41 woglinde: I have tested which ones still apply Apr 18 07:24:46 60 out of 158 Apr 18 07:25:06 and I was going through them to see if any are imprtant Apr 18 07:25:27 ah okay Apr 18 07:25:35 so you did it in your own Apr 18 07:25:49 well, nobody showed interest in IRC or mail Apr 18 07:25:55 like the ones before :) Apr 18 07:26:01 hm Apr 18 07:26:13 And I wasn't in the mood to pester people to look at it. The weather was to nice :) Apr 18 07:26:13 you didnt asked when I was on irc Apr 18 07:28:17 woglinde: hmm, I asked. Hopefully the message got not lost Apr 18 07:28:26 woglinde: you have been on IRC all day? Apr 18 07:28:30 no Apr 18 07:28:37 but in the evenings I was Apr 18 07:28:39 ah, ok Apr 18 07:28:48 but so hunted memleaks in navit Apr 18 07:28:50 *g* Apr 18 07:28:55 well, as I said. I was not in the mood to pester people Apr 18 07:29:02 woglinde: thats great as well :) Apr 18 07:29:25 And the old patchwork is in this state for some months now. People had a chance to look at it. :) Apr 18 07:29:45 * stefan_schmidt is going to write a summary in the next hour wrt patchwork Apr 18 07:34:27 stefan_schmidt, the old patchwork should be gone right? its frozen? Apr 18 07:35:24 ka6sox-home: give it some more days please. :) Apr 18 07:35:35 ka6sox-home: I'm just sitting on a mail regarding it. Apr 18 07:35:55 good nite ka6sox-home Apr 18 07:35:57 ka6sox-home: I would say we leave it as is for the rest of the week and kill it next weekend. Apr 18 07:36:08 I won't be turning it off...I just thought about 5-6months ago it got switched Apr 18 07:36:10 nite woglinde Apr 18 07:36:21 ;) Apr 18 07:37:02 ka6sox-home: yeah, we just wanted to give people time moaning if anything important is sitting there Apr 18 07:37:31 kk Apr 18 07:37:34 ka6sox-home: Time is over I would say and we should kill it to make it more clear which one is the current one Apr 18 07:38:46 right, I have seen confusion on that point. Apr 18 07:51:08 hi tasslehoff Apr 18 07:51:40 gm woglinde Apr 18 07:52:28 woglinde: I'm trying to port the patches from openjdk-1.8.5 to openjdk-1.10.1 . May I ask some questions? Apr 18 07:52:42 aehm Apr 18 07:52:51 we/I are doing this too Apr 18 07:53:05 Cool. Apr 18 07:53:22 Can I help in any way? Apr 18 07:54:32 hm first be aware all revs after 1.8 have arm thumbee support disabled Apr 18 07:55:18 mkneissl but ask yes Apr 18 07:55:42 second there is a m4 bug which prevents us to give icedtead our ecj Apr 18 07:56:11 so its using javac and ecjlibs to make there own ecj Apr 18 07:57:17 gm ant Apr 18 07:57:30 good morning Apr 18 07:58:05 03Henning Heinold  07org.openembedded.dev * ra263524ca2 10openembedded.git/recipes/cacao/ (cacao-native_hg.bb files/cacao-shutdownguard.patch): Apr 18 07:58:05 cacao-native: add fix for vm-shutdown and multiple threads are involved Apr 18 07:58:05 * bump PR Apr 18 07:58:05 03Henning Heinold  07org.openembedded.dev * r2b31a5434c 10openembedded.git/recipes/icedtea/icedtea6-native.inc: Apr 18 07:58:05 icedtea6-native: add libxext-native to the dependencies Apr 18 07:58:06 * bump PR Apr 18 08:05:36 woglinde: have you seen the build failur due to schroedinger? Apr 18 08:05:49 ant yes Apr 18 08:05:54 let me reproduce here Apr 18 08:06:10 looks like a orc/schroedinger missmatch Apr 18 08:06:15 or missing include Apr 18 08:06:23 dont know why paul cannt google it Apr 18 08:06:26 it is like stdint.h is missing, no int16_t Apr 18 08:06:38 and only "inform us" Apr 18 08:06:41 he he Apr 18 08:06:57 it was too late last night when I discovered it... Apr 18 08:07:06 too late for debuging Apr 18 08:07:10 ah okay Apr 18 08:07:14 so you will fix it Apr 18 08:07:17 fine Apr 18 08:07:38 I did a grep for stdint and had some matches in /schroedinger Apr 18 08:07:44 good morning Apr 18 08:07:57 iirc is schroorc- something Apr 18 08:09:46 woglinde: Well, the questions might be very stupid. There's a patch to atomic_linux_zero that's casting from jlong to jint in 1.8. Should this still be done in 1.10? Apr 18 08:10:46 hm Apr 18 08:11:12 which filename? Apr 18 08:22:46 woglinde: zero-cmpswap-long.patch Apr 18 08:24:15 hm I think its still needed Apr 18 08:28:16 woglinde: And now the stupid question: Why does casting from long to int work here? Apr 18 08:29:06 it always works but you will lost precission Apr 18 08:39:23 woglinde: I don't havwe time until thi sevening to fix it. I'd tray the couple of top patches tere http://diracvideo.schleef.org/git?p=schroedinger.git;a=summary Apr 18 08:39:40 * ant_work kicks and replaces keyboard Apr 18 08:54:43 ant evening is okay Apr 18 09:04:18 hi mickeyl Apr 18 09:10:53 morsche woglinde Apr 18 09:13:39 good morning Apr 18 09:19:05 moin florian Apr 18 09:19:13 hrw: will you come to LinuxTag? Apr 18 09:19:18 florian: or you? Apr 18 09:19:38 florian organized the booth Apr 18 09:19:51 I will be there but most time on navit booth Apr 18 09:19:58 morning all Apr 18 09:20:39 hi bluelightning Apr 18 09:21:04 mickey|office: hi Apr 18 09:21:16 mickey|office: The plan is to be there... :) Apr 18 09:21:58 mickey|office: nope - Ubuntu/Linaro Developers Summit at same time Apr 18 09:24:32 hrw: ah, pity Apr 18 09:24:35 florian: ok, cool Apr 18 09:24:56 mickey|office: indeed Apr 18 09:25:08 too far...and I've been to 3 conferences in 3months...time to stay home. Apr 18 09:25:14 mickey|office: maybe we will get an option to meet before your family will expand Apr 18 09:25:21 hm who can edit the wiki frondpage? Apr 18 09:25:38 woglinde: admins? Apr 18 09:25:46 hrw: that'd be cool, but the time frame is short now :) ETA is 25th of may Apr 18 09:26:01 hrw, what do you need? Apr 18 09:26:08 mickey|office: Sabine and child are fine? Apr 18 09:26:15 ka6sox-home: rather woglinde Apr 18 09:26:28 oh right Apr 18 09:26:34 ka6sox-home making news we have booth for linuxtag Apr 18 09:26:35 woglinde, what do you need? Apr 18 09:26:54 okay let me look @ Robert's email and pull the important bits and post Apr 18 09:27:20 hrw: thanks, everything ok so far, she's real big by now, but according to the doc, everything is operating within the normal parameters. Apr 18 09:27:42 woglinde: I am also one of admins so in future I can also edit if you need something to be done Apr 18 09:27:44 mickeyl oh thats news Apr 18 09:27:59 so you joined us Apr 18 09:28:00 mickey|office: Don't believe anything they say about weight ;) Apr 18 09:28:16 hrw, go ahead...its late for me...I am just reviewing design before bed. Apr 18 09:28:49 hrw maybee wiki page who can edit main page Apr 18 09:28:51 *g* Apr 18 09:28:53 mickey|office: will you be on Saturday 14th in Berlin? Apr 18 09:30:03 * hrw lands at SXF on 17:35 Apr 18 09:30:20 hrw: i'm not sure, i'll try to coordinate with morphis, as we have to meet to discuss some FSO issues Apr 18 09:30:23 * florian just filled the LinuxTag wiki for ordering furniture Apr 18 09:30:28 saturday would probably be the fullest day Apr 18 09:30:55 mickey|office: so visit Szczecin on sunday :D Apr 18 09:31:14 woglinde: http://wiki.openembedded.org/index.php?title=Special%3AListUsers&username=&group=sysop Apr 18 09:31:26 hehe Apr 18 09:31:35 A large and a small table... let's see if we get these. Should be better than the infopoint for our purposes... Apr 18 09:31:56 mickey|office: I am serious Apr 18 09:32:37 hrw: hmm, there's a train that doesn't take long, right? Apr 18 09:32:38 We need to think about some image targets for kids :-) Apr 18 09:32:38 hm laibsch is still admin Apr 18 09:32:45 florian: yeah Apr 18 09:33:43 mickey|office: Berlin -> Angemunde -> Szczecin usually but there are also direct ones Apr 18 09:33:53 mickey|office: or ~150km by autobahn Apr 18 09:34:34 mickey|office: A simple thing to do would be one with GCompris - this might work on some tablet pretty well. Apr 18 09:35:13 florian is the booth number settled or open? Apr 18 09:37:28 woglinde: settled... one sec Apr 18 09:37:54 7.2b 112 Apr 18 09:41:01 florian: do we have some >7" touchscrens for gcompris? Apr 18 09:43:12 hrw: the simpad but it might not have enough ram... Apr 18 09:43:26 need to search if i can find anything useful here Apr 18 09:43:42 florian: I still have that frontpage progear somewhere in basement. xga 10" TS but only 112MB ram Apr 18 09:44:16 hrw: better than the simpad :) Apr 18 09:44:37 florian: I can send it to someone but do not want it back ;) Apr 18 09:44:49 florian: MACHINE=progear Apr 18 09:44:53 hrw: is it that bad? ;) Apr 18 09:44:58 stefan_schmidt: I think we should check again /patch/1917/ Apr 18 09:45:13 florian: I do not use it at all. it only "gather dust" Apr 18 09:45:26 a skeye.pad might be cool... ideal for kids becuse they are hard to break Apr 18 09:45:34 it looks like in order to optimize boot time modutils / module-init-tools goes to S02 Apr 18 09:45:49 florian: slow, ugly, heavy, old. but runs X11 just fine and (as it is x86) works fine Apr 18 09:46:09 florian: any kernel works on it. OE iirc has .30 set for it Apr 18 09:46:36 florian: 5GB pata 2.5" hdd inside, orinoco pcmcia wifi in slot, usb 1.1 ports Apr 18 09:46:52 florian: http://marcin.juszkiewicz.com.pl/tag/progear/ Apr 18 09:46:59 best for kids seems to be iphone (if it only would allow for different user logins) Apr 18 09:47:20 ant_work: 1917? Apr 18 09:47:29 patchwork Apr 18 09:47:39 thats arm hw caps backport to stable and should already be in the old stable branch for ages Apr 18 09:47:48 ant_work: had to keep an eye on it and big lose if stolen Apr 18 09:47:49 http://patchwork.openembedded.org/patch/1917/ Apr 18 09:48:21 oh..sorry..lemme check again Apr 18 09:48:25 :) Apr 18 09:49:10 http://patches.openembedded.org/patch/1917/ Apr 18 09:49:13 argh Apr 18 09:49:27 flew in the other one... Apr 18 09:49:27 ant_work: thats the _new_ patchwork. That one will stay Apr 18 09:49:45 ant_work: just ping for it on the list for this one :) Apr 18 09:51:50 hrw: heh... yes I see it _is_ ugly :-) Apr 18 09:54:12 florian: :D Apr 18 09:54:26 hi gnutoo Apr 18 09:55:02 hi Apr 18 10:09:26 morning Apr 18 10:10:10 morning Jay7 Apr 18 10:10:24 ka6sox-home: hi Apr 18 10:10:30 any interesting news? :) Apr 18 10:10:56 yes, autobuilder is working much better now. Apr 18 10:11:23 what used to take 5days is going to be done in <2days Apr 18 10:11:33 cool :) Apr 18 10:11:46 my speed change was lower Apr 18 10:12:05 the SSD's are writing 500MB/sec sustained Apr 18 10:12:52 one testbuild of one distro for testing-next is 1h30m now.. was about 2-2:30 Apr 18 10:13:25 I am testing QEMUARM and QEMUMIPS Apr 18 10:13:43 the 2011.3 it seems Apr 18 10:14:22 ka6sox-home: nice ssds Apr 18 10:14:41 hrw, ya, glad we got them...solved a few problems. Apr 18 10:15:17 I/O loading went from 80-100% to <4% Apr 18 10:18:32 amazing Apr 18 10:18:50 I have corsair ssd here - 235MB/s Apr 18 10:19:17 erasing of several GBs at once can nearly kill i/o Apr 18 10:19:25 I have a pair of 200GB OWC Mercury Pros setup as RAID0 Apr 18 10:19:35 I am looking into Trim. Apr 18 10:19:37 hrw: using ext3? Apr 18 10:20:46 ext4 Apr 18 10:21:00 florian, I have heard various stories about using ext4 and whether trim works with RAID cards. Apr 18 10:26:59 * Jay7 just have 2 WD Black in RAID0 here Apr 18 10:27:09 with ext4, yes Apr 18 10:29:49 Jay7: we have these here too... not too bad but we needed to get five in order to get two working properly for longer than a week :-/ Apr 18 10:30:14 florian ugh Apr 18 10:30:22 looks like a monday charge Apr 18 10:30:24 florian, what failed? Apr 18 10:31:37 ka6sox-home: the surface obvioulsly, one was bad on arrival and didn't even survive the raid sync. but the ones we have now are working properly for several months now. Apr 18 10:31:45 florian: raid10 is your choice then :) Apr 18 10:32:21 since they are scratch disks I just went for all out speed. Apr 18 10:33:07 woglinde: yeah... the guy at the shop told us they had somethign like this with anther disk some time ago. a big box of brand new disks and all broken Apr 18 10:33:20 or even better is raid10 + wd raptors :) Apr 18 10:33:56 Jay7: heh indeed... and a new case :-) Apr 18 10:34:07 or 16 10k spin 500GB DP SAS :D Apr 18 10:34:08 and good cooling system :) Apr 18 10:34:20 and move it as far as possible :) Apr 18 10:36:34 03Andreas Oberritter  07master * r156d0bcaea 10openembedded.git/recipes/streamripper/streamripper_1.64.6.bb: (log message trimmed) Apr 18 10:36:34 streamripper: fix depends and license Apr 18 10:36:34 - Prefer the shared libmad over the one included in streamripper. Apr 18 10:36:34 - glib-2.0 is required to build streamripper. Apr 18 10:36:34 - libfaad2 will get picked up if built before streamripper. Make Apr 18 10:36:34 builds consistent. Apr 18 10:36:34 - No need to set RDEPENDS_${PN} (already set by shlibdeps). Apr 18 11:29:19 hi , i ve tried to use "apt-get" on mingw32 but i got command not found on windows , how can i fix this issue ? any way to download it from net ? Apr 18 11:32:03 ? Apr 18 11:32:24 lol Apr 18 11:32:25 didnt know debian runs on windows natively Apr 18 11:35:00 hej , are packages such as vi(m), wget, etc. going to oe-meta or is there some super secret layer I am missing ? ;) Apr 18 11:35:22 mlip meta-oe repos your are searching Apr 18 11:35:45 http://cgit.openembedded.org/cgit.cgi/meta-openembedded/ Apr 18 11:36:16 I have a working oe configuration using layers, but I am missing some smaller apps like vim ;/ Apr 18 11:37:53 mlip: many recipes are missing in meta-oe, please add what you find usefull and send patches Apr 18 11:38:57 JaMa|Work, have the ssh key been copied to the meta-oe, or is it a pull/patch based principle with some maintainers only ? Apr 18 11:39:23 you can push to meta-oe-contrib repo Apr 18 11:39:42 then you send pull request to ML and koen will pull it to main repo Apr 18 11:40:03 JaMa|Work: is meta-oe == OE - oe-core? :) Apr 18 11:40:13 Jay7: no Apr 18 11:40:36 JaMa|Work, ok that sound good, thx Apr 18 11:40:38 Jay7: meta-oe consist mostly from recipes /me or koen needed for your targets Apr 18 11:40:47 s/your/our/ Apr 18 11:41:03 others are welcome to add stuff they need Apr 18 11:41:37 but stuff wont add itself automatically and needs cleanup before adding Apr 18 11:42:08 well, ok Apr 18 11:42:19 ant_work: btw some parts for spitz are already in meta-shr too Apr 18 11:43:17 ant_work: but ie klibc is failing to build because we're not staging kernel sources Apr 18 11:43:25 I still have to realize how to integrate the Z family... Apr 18 11:43:33 BSP layer? Apr 18 11:43:37 living where? Apr 18 11:44:04 meta-shr layer http://git.shr-project.org/git/?p=meta-shr.git;a=summary Apr 18 11:44:39 isn't a BSP necessary for each machine? Apr 18 11:45:43 second, I'd like to add it to 'default', not only shr or angstrom Apr 18 11:45:53 ant_work: for now I'm using meta-shr for everything and after cleanup and testing it can be torn from it to separate bsp Apr 18 11:46:08 I'm waiting to see some examples, finally Apr 18 11:46:29 ant_work: but for testing/developing it's easier to have it in less layers (at least for me) Apr 18 11:46:46 ant_work: see meta-ti http://git.angstrom-distribution.org/cgi-bin/cgit.cgi/meta-texasinstruments/ Apr 18 11:47:48 ant_work: and for those spitz related recipes use https://gitorious.org/shr/meta-shr, sorry haven't pushed it to git.shr-project.org yet Apr 18 11:48:30 JaMa|Work: I appreciate you pionering the move, remember however we have all 6 Zaurus models to push Apr 18 11:49:10 not only spitz Apr 18 11:49:44 spitz is only model I can test on.. that's why I started with it for myself to abandon oe.dev sooner Apr 18 11:49:45 surely it's better to have only as many layers as really necessary Apr 18 11:50:28 ant_work: and I'll be glad to use meta-zaurus bsp if you do it :) Apr 18 11:50:53 I was wondering about smthg like that :p Apr 18 11:51:06 * JaMa|Work already moved oe.dev tmpdir from fast raid to slow archive.. Apr 18 11:51:35 :) Apr 18 11:51:51 btw , these bb files has just points to source codes and patches? Apr 18 11:51:59 for example think about some opensource library Apr 18 11:52:02 i get it from svn Apr 18 11:52:02 JaMa|Work: any idea about where to host the machine-layers? I se ti has own repo but the majority shouldn't Apr 18 11:52:10 i try to compile the source code Apr 18 11:52:26 ant_work , sry i m not pro too... Apr 18 11:52:49 ant_work: git.oe.org would be best imho Apr 18 11:53:00 when i try to compile opensource library for some machine , i got so many errors , its because of they r intel based ? Apr 18 11:53:11 for example clutter Apr 18 11:53:23 i tried latest version Apr 18 11:53:34 JaMa|Work: yep, agreed Apr 18 11:53:35 directly tried compiled and got many errors Apr 18 11:53:36 JDuke128: clutter should cross-compile just fine Apr 18 11:54:11 can you not just build it within OE? Apr 18 11:54:36 ant_work: meta-ti locatin is where it's now because koen is waiting for board/yocto-tsc decision about repo hosting policies, but that's vendor bsp.. I don't think we have sharp contributors :) Apr 18 11:54:58 * woglinde wonders too how well spreading machine support will work Apr 18 11:55:32 ant_work: so you can start with meta-zaurus on github/gitorious and move it later when such things are decided Apr 18 11:55:47 right Apr 18 11:55:57 ant_work: but waiting for repo is weak excuse :) Apr 18 11:56:06 he, it's not just that Apr 18 11:56:13 yousee: what is core? Apr 18 11:56:17 klibc is clore? Apr 18 11:56:54 from koen's definition Apr 18 11:56:54 OE-core still isn't fleshed out completely, but the current way of Apr 18 11:56:55 thinking is "if enough layers depend on , should get Apr 18 11:56:55 considered for oe-core". Apr 18 11:57:10 my doubt is: where are those needed background-recipes expected? Apr 18 11:57:23 so I'm waiting for the water to calm :) Apr 18 11:57:40 so again, don't worry about such things now.. you can add it to meta-zaurus and then move it to meta-oe or even oe-core when more people find it usefull Apr 18 11:57:53 bluelightning , can i install any source code by just 3 steps for any machine ? "./configure" , "make" , "make install" but i ve seen some source codes includes patches.Why ? Apr 18 11:58:06 water is too calm IMHO because everybody is waiting for something :) Apr 18 11:58:08 ant_work: imho, all libcs should be in core Apr 18 11:58:19 I think soo Apr 18 11:58:34 JDuke128: well, bitbake/OE takes care of all of that for you Apr 18 11:58:57 okay but why patches required sometimes? Apr 18 11:59:07 JDuke128: re patches, sometimes some things need to be fixed in OE quicker than fixes can be applied upstream Apr 18 11:59:21 i ve seen oe is applying some diff files on source codes ,why Apr 18 11:59:33 JDuke128: also sometimes patches are needed for cross-compiling and upstream may not care about cross-compilation Apr 18 11:59:42 yes, some recipes are not cross-friendly Apr 18 12:00:09 because for example some source codes on intel uses simd and arm it requires neon Apr 18 12:00:15 so , diff patch for that? Apr 18 12:00:44 no, even deeper issues with paths Apr 18 12:01:34 some source codes on intel uses simd and arm it requires neon , how they fix this problem so ? Apr 18 12:01:43 if no patch Apr 18 12:02:37 JDuke128: surely that's something handled by the compiler/toolchain? Apr 18 12:03:36 bluelightning , i c Apr 18 12:03:44 bluelightning , its compiler does Apr 18 12:04:04 bluelightning, so you mean diff files on path issues used Apr 18 12:04:11 JDuke128 *sigh* I told your yesterday mostly the compiler deals with it Apr 18 12:04:24 but there is handcrafted assembler too Apr 18 12:04:41 JDuke128: sometimes it's about paths or other cross-compile fixes and other times it's about fixing a bug that is not fixed upstream Apr 18 12:05:11 JDuke128 are you doing this for fun? Apr 18 12:05:15 ideally for the latter type of patches the patch gets submitted upstream and later can be removed from OE Apr 18 12:05:16 woglinde , yes i mean handcrafted assembler Apr 18 12:05:36 JDuke128 or did your boss confrotated with the stuff you cannt handle yet? Apr 18 12:11:58 JaMa|Work: btw, I've noticed NATIVE_INSTALL_WORKS operates differently in oe-dev and oe-core Apr 18 12:12:15 i.e. in mtd-utils RP removed it from the oe-core recipe Apr 18 12:12:38 but instll of -native fails in oe-dev *without* N.I.W. Apr 18 12:14:38 finally, in oe-core the same recipe has a longer EXTRA_OEMAKE: they add 'BUILDDIR=${S}' Apr 18 12:15:35 ...I'v committed it like that but a grep afterwards reveals only another recipe (from oe-core maybe) does that in OE-dev Apr 18 12:15:51 I understand it is superfluous Apr 18 12:44:39 hi all Apr 18 12:45:18 I'm having problem with yocto 1.0 using poky-image-core Apr 18 12:45:30 it seems that udev-1 script is never started at boot Apr 18 12:45:55 there are no links to that in the /etc/rc*.d/ directories Apr 18 12:46:13 is this normal? Apr 18 12:56:34 arg .. .i want a oe on my centos box but that os ships python 2.4 only , grrr Apr 18 12:56:56 2.4 suckz Apr 18 12:56:57 now Apr 18 12:57:03 yeah Apr 18 12:57:06 and centos suckz too Apr 18 12:57:12 in my opinion Apr 18 12:57:16 dont say that Apr 18 12:57:44 rob_w: I recommend using minimalistic chroot environment for OE builds Apr 18 12:57:55 hmmm Apr 18 12:58:05 or lxc container :) Apr 18 12:58:33 which is mostly the same :) Apr 18 12:58:44 * JaMa|Work maintains shr-chroot based on gentoo and since then less build issues from people building SHR :) Apr 18 12:59:00 and whole shr-chroot is in git repo :) Apr 18 12:59:14 is that a chroot for oe ? Apr 18 12:59:20 with some latestest python ? Apr 18 12:59:24 * Jay7 is using debian 6.0.1 lxc container on top of archlinux :) Apr 18 13:00:05 rob_w: it's not official oe way, but works and has working python version (2.7 currently) Apr 18 13:00:54 can you point me to that git , please Apr 18 13:02:02 rob_w: http://git.shr-project.org/git/?p=shr-chroot.git;a=summary some instructions how to use it are here: http://git.shr-project.org/git/?p=shr-chroot.git;a=summary Apr 18 13:17:34 03Antonio Ospite  07master * r5a0bfc1862 10openembedded.git/recipes/ezx/moto-boot-usb-native_git.bb: Apr 18 13:17:34 ezx/moto-boot-usb-native_git.bb: update SRCREV Apr 18 13:17:34 This brings in the following fixes: Apr 18 13:17:34 - require an interactive confirmation when trying to flash the Apr 18 13:17:34 bootloader Apr 18 13:17:35 - don't send unsupported query command to gen-blob Apr 18 13:17:35 Signed-off-by: Antonio Ospite Apr 18 13:17:36 03Antonio Ospite  07master * r80ad4406b3 10openembedded.git/files/device_table-ezx.txt: Apr 18 13:17:37 files/device_table-ezx.txt: change some indentation Apr 18 13:17:37 Just to make columns more distinguishable. Apr 18 13:17:38 Signed-off-by: Antonio Ospite Apr 18 13:17:38 03Antonio Ospite  07master * r62c2d235be 10openembedded.git/recipes/ezx/ezx-gen-blob_git.bb: Apr 18 13:17:45 ezx/ezx-gen-blob_git.bb: update SRCREV Apr 18 13:17:45 The new version fixes a problem which made gen-blob not working when Apr 18 13:17:45 compiled with recent gcc versions. Apr 18 13:17:45 Signed-off-by: Antonio Ospite Apr 18 13:17:46 03Antonio Ospite  07master * r890db97d19 10openembedded.git/recipes/ezx/ezx-gpiotool_svn.bb: Apr 18 13:17:46 ezx/ezx-gpiotool_svn.bb: make the recipe build again Apr 18 13:17:47 Pass ${LDFLAGS} in order to make the following error go away: Apr 18 13:17:48 ERROR: QA Issue with ezx-gpiotool: No GNU_HASH in the elf binary Apr 18 13:17:48 This is a workaround until the upstream Makefile is fixed properly. Apr 18 13:17:49 While at it remove the unused do_stage() function. Apr 18 13:17:49 Signed-off-by: Antonio Ospite Apr 18 13:17:50 03Antonio Ospite  07master * r570cfe69d4 10openembedded.git/recipes/linux/openezx-kernel_git.bb: Apr 18 13:17:54 linux/openezx-kernel_git.bb: update recipe to build 2.6.38 Apr 18 13:17:54 Signed-off-by: Antonio Ospite Apr 18 13:17:54 03Antonio Ospite  07master * r3940064e65 10openembedded.git/files/device_table-ezx.txt: Apr 18 13:17:54 files/device_table-ezx.txt: Add /dev/snd and /dev/ttyS1 Apr 18 13:17:54 The /dev/snd directory is needed for the device nodes under it to be Apr 18 13:44:34 any idea what happened to gst-plugins-base-meta Apr 18 13:45:09 hm got lost in the last dynmaic transition? Apr 18 13:45:23 appears to be lost Apr 18 13:45:37 strap jama and paul Apr 18 13:45:51 ok Apr 18 13:46:59 ? Apr 18 13:49:21 t-plugins-base-meta is unbuilable now Apr 18 13:50:23 can you pastebin error? Apr 18 13:51:04 http://pastebin.com/a9tXS8rP Apr 18 14:02:21 xbmc is unable to be linked for cross compile on amd64 systems with libexpat1-dev installed to target of i686. Apr 18 14:04:31 dandel hm Apr 18 14:04:35 could be Apr 18 14:04:51 dandel find out if it's a failure in xmbc configure Apr 18 14:04:59 it's linker Apr 18 14:05:02 no useing the right pkg-config Apr 18 14:05:12 it's trying to use /usr/lib/libexpat.so Apr 18 14:05:16 no the linker before gets telled what to use Apr 18 14:05:27 e.g. path and lib Apr 18 14:05:45 i removed my locally installed libexpat1-dev package to see if it would fix the issue Apr 18 14:06:22 1 sec... pasting the log on to pastebin. Apr 18 14:06:23 dandel *sigh* Apr 18 14:06:31 no please!!! Apr 18 14:06:43 I wouldnt help Apr 18 14:06:52 better pastebin do_configure Apr 18 14:06:55 log Apr 18 14:08:56 umm..here's the config log of do_configure: http://pastebin.com/Q5XqARmz Apr 18 14:10:54 bleh... it's fighting with the locally installed packages... removed libexpat from the system and it links libexpat, and now it complains about libz :/ Apr 18 14:11:50 the specific error goes like this anyways: /usr/lib/libz.so: could not read symbols: File in wrong format Apr 18 14:11:52 hm I think some one should be make Paul Menzel aware of oe-core Apr 18 14:12:29 i also have the specific libtool line that instigated the failure. Apr 18 14:12:56 dandel by the way x86 and x64 are nt that well tested in oe Apr 18 14:13:14 I figured that much. Apr 18 14:13:31 however, it's still supposed to be a valid combination. Apr 18 14:13:51 why is autoreconfig calles twice? Apr 18 14:14:11 hmm? Apr 18 14:14:28 oh no its calld thrice Apr 18 14:14:39 oh... bootstrap calls configure once. Apr 18 14:14:58 hm ah okay internal clones of dvdnav Apr 18 14:15:41 woglinde, i'm actually also on top of this updating xbmc to include 10.2 (i686 only). Apr 18 14:16:08 because the sourceforge repository was abandoned a few months ago, and last updated in january. Apr 18 14:16:32 Crofton|work: strange I've reverted that disjunctive PACKAGES_DYNAMIC commit and still have the same error as you Apr 18 14:16:55 dandek this goes wrong checking for XML_ParseBuffer in -lexpat... yes Apr 18 14:17:04 dandel it should use the one from oe Apr 18 14:17:22 yes, but here's the command that's thrown. Apr 18 14:17:34 dont know at the moment if expat has pkg-conf support Apr 18 14:17:44 than it would be easy to fix Apr 18 14:17:45 libtool: link: /usr/bin/ccache i686-angstrom-linux-gcc -march=pentiumpro --sysroot=/opt/openembedded/oetmp/sysroots/i686-angstrom-linux -shared .libs/version.o .libs/ucs4.o .libs/latin1.o .libs/utf16.o .libs/utf8.o .libs/parse.o .libs/render.o .libs/field.o .libs/frametype.o .libs/compat.o .libs/genre.o .libs/frame.o .libs/crc.o .libs/util.o .libs/tag.o .libs/file.o .libs/metadata.o /usr/lib/libz.so -march=pentiumpro -Wl,-O1 -Wl,--hash-style=gnu -W Apr 18 14:17:45 l,-soname -Wl,libid3tag.so.0 -o .libs/libid3tag.so.0.3.0 Apr 18 14:18:07 hm Apr 18 14:18:08 this is for libz error (after i removed libexpat. Apr 18 14:18:11 mom Apr 18 14:18:14 yes Apr 18 14:18:14 JaMa|Work, caching? Apr 18 14:18:23 I'm in another rat hole atm Apr 18 14:18:24 thats an libtool think Apr 18 14:18:43 and for expat it's: | i686-angstrom-linux-libtool: link: /usr/bin/ccache i686-angstrom-linux-gcc -march=pentiumpro --sysroot=/opt/openembedded/oetmp/sysroots/i686-angstrom-linux -shared -fPIC -DPIC .libs/psymbol.o .libs/pscan.o .libs/ploader.o .libs/pinfo.o .libs/pcontrol.o .libs/serial.o .libs/logging.o .libs/context.o .libs/cpluff.o .libs/util.o .libs/list.o .libs/hash.o .libs/thread_posix.o /usr/lib/libexpat.so -ldl -march=pentiumpro --sysroot=/op Apr 18 14:18:44 t/openembedded/oetmp/sysroots/i686-angstrom-linux -O2 -O2 -Wl,-O1 -Wl,--hash-style=gnu -Wl,-soname -Wl,libcpluff.so.0 -o .libs/libcpluff.so.0.0.3 Apr 18 14:18:53 i figured out that it was libtool already. Apr 18 14:19:17 * dandel now removes libz1g-dev from local install. Apr 18 14:19:31 thats not the fix Apr 18 14:19:33 Crofton|work: ah my fault (doing bitbake gst-plugins-base-meta instead angstrom-task-gnome) Apr 18 14:20:16 woglinde, i know that, but it's the only way i can fix it "simply" to find other libtool errors. Apr 18 14:21:17 i just find it strange that bitbake xfce46-image works but not bitbake xbmc after applying a few fixes for the x86 systems Apr 18 14:21:27 dandel unrecognized options: --with-libtool-sysroot, Apr 18 14:21:44 seems you need to remove the m4 macros at all places Apr 18 14:21:58 so libtool gets generated the right way Apr 18 14:22:11 eh?! Apr 18 14:22:25 removed libz and now it built lol. Apr 18 14:23:37 woglinde, I'm not on the best dev system to begin with (ubuntu 10.10 amd64) so i know for certain that libtool gets all sort of bugs just from being on this distro. Apr 18 14:25:13 dandel sysroot is not working so libtool picks up the host libs Apr 18 14:25:33 thats becauce libtool isnt regenrated the right why with autoreconf Apr 18 14:25:51 normaly removing all libtool m4 macros helps Apr 18 14:26:03 look at other recipes for instance sdl Apr 18 14:27:17 i know where the bug is in the xbmc tree. Apr 18 14:27:27 o.O Apr 18 14:27:41 there is actual no bug in xmbc Apr 18 14:27:48 its just libtool Apr 18 14:29:48 is it possible that lib/cpluff/configure.ac does not have the right macro? Apr 18 14:30:14 hm is expat used there? Apr 18 14:30:21 yes Apr 18 14:30:33 can you pastebin the file? Apr 18 14:32:05 http://pastebin.com/wvBQSavy Apr 18 14:32:52 no thats okay Apr 18 14:33:10 as I said when the sysroot flags is working it will pick up the right lib Apr 18 14:35:11 woglinde, i can help ya with setting up a system that mirrors mine if your cpu supports 64-bit systems and figure out what is going on ><; Apr 18 14:37:46 dandel *sigh* I know what is needed to fix it Apr 18 14:37:58 ok, and? Apr 18 14:38:43 remove the m4-libtool macros from all dirs Apr 18 14:39:50 look at recipes/libsdl/libsdl-1.2.14.inc Apr 18 14:40:32 hmm... Apr 18 14:40:45 i found the problem, i think. Apr 18 14:41:09 instead of rm -f acinclude/$i Apr 18 14:41:24 use find $i | xarg rm Apr 18 14:41:25 http://pastebin.com/7ZLLJ4Dw Apr 18 14:41:32 *sigh* Apr 18 14:41:35 that's from aclocal.m4 Apr 18 14:42:41 dont you understand what I said? Apr 18 14:42:44 re crofton Apr 18 14:43:05 i'm tring to find the instances of that tho. Apr 18 14:43:08 copy the function from sdl Apr 18 14:43:19 replace rm -f acinclude/$i with Apr 18 14:43:26 find $i | xarg rm Apr 18 14:44:00 or rm -f Apr 18 14:44:49 btw. aclocal.m4 is generated from acinclude.m4 all other m4 macros specified in configure.ac Apr 18 14:47:38 found in configure.in: AC_PROG_LIBTOOL Apr 18 14:49:30 *sigh* Apr 18 14:50:02 Hey guys Apr 18 14:50:13 yes thats the old command to get libtool support, but till now all libtool versions have backport support for iut Apr 18 14:50:48 hmm... i wonder: https://github.com/xbmc/xbmc/blob/master/lib/cpluff/m4/lib-ld.m4 Apr 18 14:53:03 woglinde, does that look like the offending m4 file to you? Apr 18 14:55:04 *sigh* I give up Apr 18 14:55:30 you can do it woglinde! Apr 18 14:55:55 no he isnt listen to my advices Apr 18 14:56:11 I think I will fix it silently this evening Apr 18 14:56:33 good luck =) Apr 18 14:56:41 woglinde, might be a good idea to look at boxee also. ><; Apr 18 14:57:03 it uses the same code base as xbmc, so therefore it should also experience the same bugs. Apr 18 15:21:55 hi Apr 18 16:33:30 How to install a compiler on target? I tried installing gcc on rokre6 but when i try to compile "gcc try1.c" it gives an error, http://pastebin.com/df6z9YQK Apr 18 17:02:02 anyone?? Apr 18 17:02:11 How to install a compiler on target? I tried installing gcc on rokre6 but when i try to compile "gcc try1.c" it gives an error, http://pastebin.com/df6z9YQK Apr 18 17:22:28 On the target you probably just want gcc Apr 18 18:18:28 JaMa, ping? Apr 18 18:21:31 pong Apr 18 18:22:46 JaMa, can you do this automated pull requests to oe-ml throught gitorious, or do you use a script ? Apr 18 18:22:56 s/automated/nicely formated/g Apr 18 18:23:13 using script Apr 18 18:23:32 is it somewhere online ? ;) Apr 18 18:25:59 in oe-core repo Apr 18 18:26:10 scripts/send-pull-request and create-pull-request Apr 18 18:30:13 JaMa, ty Apr 18 18:31:04 yw Apr 18 18:53:46 Crofton|work: please test gst -meta fix I just pushed Apr 18 18:53:59 03Martin Jansa  07master * r275aaa6726 10openembedded.git/recipes/gstreamer/gst-plugins-package.inc: (log message trimmed) Apr 18 18:53:59 gst-plugins-package: add ${PN}-meta to PACKAGES directly instead from populate_packages_prepend Apr 18 18:53:59 * reported by Paul on OE ML Apr 18 18:53:59 http://lists.linuxtogo.org/pipermail/openembedded-devel/2011-April/031873.html Apr 18 18:53:59 * and Crofton on IRC Apr 18 18:54:00 * not really sure how PACKAGES_DYNAMIC can influence this, but now it Apr 18 18:54:01 works, -e output checked and doesn't look like space or something Apr 18 18:56:11 03Pau Espin Pedrol  07master * r244ca48a1b 10openembedded.git/recipes/e17/elfe_svn.bb: Apr 18 18:56:11 elfe: bump SRCREV Apr 18 18:56:11 Signed-off-by: Pau Espin Pedrol Apr 18 18:56:11 Signed-off-by: Martin Jansa Apr 18 19:04:26 JaMa, now I am back to firefox failure, thanks :) Apr 18 19:30:28 03Koen Kooi  07org.openembedded.dev * r8c10f13f1a 10openembedded.git/contrib/angstrom/sort.sh: Apr 18 19:30:28 angstrom feed sorter: catch up with latest oe-core changes Apr 18 19:30:28 Signed-off-by: Koen Kooi Apr 18 19:33:20 03Koen Kooi  07org.openembedded.dev * r3dd08dc4fa 10openembedded.git/recipes/powervr-drivers/ (libgles-omap3.inc libgles-omap3/rc.pvr): Apr 18 19:33:20 libgles-omap3: fix 81xx initscript ES detection Apr 18 19:33:20 Even is the 125 core is marked ES5 im OMAP3 the 81xx SoCs use a different memorymap and init, so we tag it as ES6 Apr 18 19:33:20 Signed-off-by: Koen Kooi Apr 18 19:43:32 http://pastebin.com/SP1YYdbd Apr 18 19:43:41 any ideas what this error is from Apr 18 19:45:23 Crofton|work: using devshell or generated toolchain? Apr 18 19:45:38 writing a bb file for sip Apr 18 19:46:08 wrong LD_FLAGS? having -Wl prefix before ld options? Apr 18 21:31:32 03Kumar Gala  07master * race0252661 10openembedded.git/recipes/kexec-tools/ (7 files): (log message trimmed) Apr 18 21:31:32 kexec-tools: Add a git recipe Apr 18 21:31:32 (Initially from Kumar, further updated by Tom) Apr 18 21:31:32 Add a recipe to build kexec-tools from git. While we're at it, make a Apr 18 21:31:32 new kexec-tools.inc for the very common bits and use that all around as Apr 18 21:31:32 well as switch to INC_PR. Apr 18 21:31:32 Signed-off-by: Kumar Gala Apr 18 21:43:01 ant__: kexec-tools git ^ Apr 18 21:43:57 broken.. Apr 18 21:44:24 :) Apr 18 22:04:03 JaMa: ping Apr 18 22:04:10 broken how? Apr 18 22:04:45 Oh my, DER Apr 18 22:05:49 03Tom Rini  07master * r2205aea575 10openembedded.git/recipes/kexec-tools/kexec-tools.inc: Apr 18 22:05:49 kexec-tools.inc: PR -> INC_PR Apr 18 22:05:49 Spotted by Martin, oops. Apr 18 22:05:49 Signed-off-by: Tom Rini Apr 18 22:33:55 JaMa: good that somebody is following kexec-tools. Apr 18 22:34:30 btw today on kexec ML was asked about 2.0.3 release... Apr 18 22:34:59 time for a new release soon Apr 18 22:52:15 fwiw, we can now compile schroedinger. see ML Apr 18 22:52:33 handy Apr 18 22:53:23 the missing definitions are strange, though Apr 18 22:53:46 I'm using the latest dev.openembedded.org branch, but I get a no provider for gst-plugins-base-meta trying to build angstrom-x-image Apr 18 22:54:02 is angstrom-x-image supposed to work? Apr 18 22:58:24 03Tom Rini  07master * r6148e6fb18 10openembedded.git/recipes/kexec-tools/kexec-tools_git.inc: Apr 18 22:58:24 kexec-tools_git: Set protocol=git Apr 18 22:58:24 Signed-off-by: Tom Rini Apr 18 23:06:09 pwgen: still there? Apr 18 23:06:30 * kergoth thinks its *incredibly* fucking stupid that the default git:// protocol is rsync, not GIT Apr 18 23:07:11 he Apr 18 23:07:26 is that one of those annoying legacy issues? did git:// URLs predate the git protocol? Apr 18 23:08:24 It's possible, but the amount of rsync git urls in the metadata has to be tiny, it'd be worth potential breakage to optimize for the common case Apr 18 23:08:28 imo Apr 18 23:09:34 can the git tool support an rsync url? Apr 18 23:09:44 yupp: compiing angstrom-x-image ... 91000 /12010 Apr 18 23:09:59 Nedlinpopo: yes Apr 18 23:10:13 "Git natively supports ssh, git, http, https, ftp, ftps, and rsync Apr 18 23:10:14 protocols." Apr 18 23:10:19 maybe you can just make it explicit then. rsync urls for rsync, git urls for git Apr 18 23:10:27 what do you mean? Apr 18 23:10:34 that wouldn't make any sense. Apr 18 23:10:38 we still have to tell bitbake to use the git fetcher Apr 18 23:10:44 which means a git:// url scheme in the SRC_URI Apr 18 23:10:55 what tells the git fetcher what protocol to use to fetch is the protocol parameter Apr 18 23:11:05 yeah, but the tool could be indepent from the sourc Apr 18 23:11:14 ? Apr 18 23:11:25 no idea what you're talking about. we can specify to use rsync explicitly just fine. Apr 18 23:11:30 we're talking about the default Apr 18 23:11:40 git://foo;protocol=rsync works fine Apr 18 23:11:55 are you saying we should make it *require* explicit? Apr 18 23:11:56 i'm saying that the left half of a URL *is* the protocol, not the tool Apr 18 23:12:00 no Apr 18 23:12:06 that would mean rsync:// would always use git? Apr 18 23:12:10 ant__: i wish i would have a working kexec for the netwalker. Apr 18 23:12:14 or we wouldn't support rsync both with and without git? Apr 18 23:12:29 all you'd do is lose us functionality on one end or the other Apr 18 23:12:30 no, it means you need to say what tool independant of the transport and location Apr 18 23:12:45 which is already the case. the url scheme controls the tool, not the transport Apr 18 23:12:55 you're just wanting to flip that around for no reason? Apr 18 23:13:00 so you'd need to say FETCH_TOOL=git SRC_URI=rsync://sme.where. Apr 18 23:13:03 that'd be even more of a compatibility nightmare Apr 18 23:13:14 so we on ly support one url at a time now? Apr 18 23:13:27 and you can assume in the naive case that the protocol is the tool Apr 18 23:14:03 you're just flipping around protocol vs tool for no reason, and losing us the ability to use multiple protocols/tools in a single SRC_URI. Apr 18 23:14:13 no, I think there is a compelling reason Apr 18 23:14:40 in that the meaning of the protocol section of a URI is the left half, which specifys a protocol, not a tool Apr 18 23:14:40 you can already specify the protocol and the tool just fine, using a url parameter rather than a variable, which means its bound to that url, retaining our flexibility Apr 18 23:15:06 yes, but that is an abuse of a URL imho Apr 18 23:15:11 so you want to change everything, breaking every recipe, to gain us absolutely nothing Apr 18 23:15:12 smooth Apr 18 23:15:14 good luck with that Apr 18 23:15:36 you said yourself that the naive case is the common one. it shoudl not break anything Apr 18 23:15:41 or very little Apr 18 23:16:27 I don't see a compelling reason to break everything because you don't like how we use the URI Apr 18 23:16:45 pwgen: about that damned orc compiler, I have no idea...I hammered the schroedinger recipe and grepping for stdint found out the empty orc-stdint.h Apr 18 23:17:06 there must be a reason behind that removal... Apr 18 23:17:14 Now, I could see an argument for this in a potential future new file format, since compatibility wouldn't be a concern Apr 18 23:17:44 I'm saying the problem you hav eis because you didn't use the URI as intended. which probably isn't your fault, but it seems to me the current non-optimal situation is a result of that. Apr 18 23:17:50 actually, it is my fault Apr 18 23:17:57 I wrote the original fetch code in bitbake Apr 18 23:18:00 :) Apr 18 23:18:09 isn't it a fault of the git tool accepting many protocols loosely Apr 18 23:18:23 well, this won't be the only case where we have multiple tools able to handle a given URI Apr 18 23:18:36 consider curl vs wget vs urllib, potentially Apr 18 23:19:01 sure, but you're not using urls that start with wget:// or curl:// Apr 18 23:19:34 right, that's a fair point. the problem is that today its the fetcher that decides what urls it owns, the user can't really exert direct control over it Apr 18 23:20:00 agreed, I think that may be what you want though. Apr 18 23:20:29 the fact that it goes by scheme is really just how it happens to do it today, it could theoretically use whatever aspect its likes, its just that generally the association between tool and scheme has been tight enough for that to get the job done Apr 18 23:20:48 I think also, there may be a reasonable heuristic that works most of the time, as you said earlier. and allows for more specificity for complicated scenarios Apr 18 23:21:19 well, we could go with a solution like you suggest, but avoid the problem with supporting multiple uris by ditching the variable method and using a parameter to explicitly specify the fetcher to use, rather than relying on the default Apr 18 23:21:39 then we swap the meanings the way you suggest without sacrificing flexibility Apr 18 23:21:41 but.. that said.. Apr 18 23:21:42 yeah, or, maybe a source dictionary? Apr 18 23:21:44 our parameters suck too Apr 18 23:21:56 ours don't match the rfc wrt url parameters Apr 18 23:22:02 the beginning separator is ;, not ? Apr 18 23:22:20 * kergoth was reworking our url parsing to use urlparse just the other day, that + our file uris are the two deviations Apr 18 23:22:29 ant__: schroedinger is including the orc stuff. instead of stdint.h. that fails with 4.12 but not in 4.10 . Apr 18 23:22:58 (using // in the file uri implies a netloc follows, which is why we have to reconcatenate the 'hostname' and 'path' components in our fetching code in places) Apr 18 23:23:08 yes, the orc header is purposedly empty Apr 18 23:23:08 yeah, that could use some help. I don't know what the thing to do there is, maybe support both for a while and hase out the old way? Apr 18 23:23:23 can you think of a cleaner way to supply our own parameters without breaking the ability to pass both query and params also to *upstream*? Apr 18 23:23:26 s/hase/phase Apr 18 23:23:28 maybe we need a different separator entirely Apr 18 23:23:36 soemthing outside the format of a URI Apr 18 23:23:46 * kergoth thinks Apr 18 23:23:52 I like a dictionary approach Apr 18 23:24:26 that's basically what the parameters are, key/value pairs. the thing is, our file format doesn't really directly support anything but key/value pairs. i'd almost be happier if we just used json or yaml or something.. Apr 18 23:24:27 heh Apr 18 23:24:42 it would be really nice to be able to have namespaces for our metadata Apr 18 23:24:46 ant__: i have no idea how to fix it in a nice way. maybe oe can apply a patch or go back to orc 4.10 ..... Apr 18 23:24:48 the url case is just one of many Apr 18 23:25:11 * kergoth mutters Apr 18 23:25:24 src = { 'url' : 'git://somewhere/repo', 'proto':'rsync', 'params': {paramsdict}} Apr 18 23:25:31 like a python dictionary Apr 18 23:26:08 pwgen: the bad part of that schroedinger story is that we just build it...gst-plugins pulled by bluetooth... Apr 18 23:26:41 and it was failing last weekend :/ Apr 18 23:27:29 ant__: i have no clue if schroedinger must be compiled with orc support, maybe a simple disable on configure can help .. what is orc ?? Apr 18 23:27:40 hmm, the problem is, to do any sort of format change we should really do it via a new file format, rather than supporting that from the metadata, I think. the more work we do from python in the metadata, the more we slow down the parsing process, both up front and at task start Apr 18 23:27:43 seems to be a better compiler Apr 18 23:27:52 for the purpose Apr 18 23:28:29 pwgen: I'll let fix that stuff to the devs using it Apr 18 23:28:49 maybe other plugins are failing Apr 18 23:28:50 kergoth: or a version of the file format Apr 18 23:28:59 Okay, so I take back what I said earlier, I do like the idea of revamping how we specify our urls, but I don't think it'd be worth the pain to try to implement today Apr 18 23:29:21 * kergoth thinks Apr 18 23:29:38 ant__: are there packages depending on orc 4.12 ? Apr 18 23:31:34 is bitbake okay wiht me running multiple instances of it with the same tmp directory Apr 18 23:31:39 I'd like to see a file format that's actually parsable without having to have lexer states :| Apr 18 23:31:45 not likely, no Apr 18 23:31:54 I don't think we lock everything we need to Apr 18 23:32:02 that's what my gut says, but I've been too chicken to try Apr 18 23:32:25 I'd say it'd probably work for something simple like a bitbake -e or -g, which doesn't do any real work Apr 18 23:32:29 but I wouldn't dare anything beyond that Apr 18 23:32:33 okay Apr 18 23:32:38 pwgen: no Apr 18 23:32:44 NEWS: Orc bug fix. Bump orc requirement to 0.4.10, which makes sure Apr 18 23:32:44 everyone works right. Apr 18 23:32:51 how does bitbake decide what version of a recipe to use? Apr 18 23:32:54 I think what would be ideal would be to bind the bitbake server to the tmpdir, and let the bitbake UI/client spot the pipe or whatever in there and communicate with the existing server Apr 18 23:33:05 that way you wouldn't need two actual processes stepping on each others data Apr 18 23:33:26 but bitbake has too much global state right now for multiple builds in a single server process to work Apr 18 23:33:26 hmm Apr 18 23:33:53 it defaults to the latest version, unless DEFAULT_PREFERENCE is in the recipe, or PREFERRED_VERSION_ is specified, or it's in a prioritized layer Apr 18 23:34:00 (BBFILE_PRIORITY_ = s/)$/<)/ Apr 18 23:34:11 bah Apr 18 23:34:12 close enough Apr 18 23:34:58 O Apr 18 23:35:01 blah Apr 18 23:35:09 seems a little heavy handed, but maybe. Maybe you can simplify the computation of each task in the dependancy tree to be stateless so you can run a million bitbake processes Apr 18 23:35:12 * kergoth can't type today, apparently Apr 18 23:35:26 * Nedlinpopo can't type every day, so don't feel bad. Apr 18 23:37:02 pwgen: I meant schroedinger just needs orc-4.10 Apr 18 23:37:06 What tasks are currently being executed isn't stored anywhere in the filesystem, today. All we record is what has been run to completion, and what hasn't. We'd have to track more about task execution in the filesystem, I think Apr 18 23:38:28 ant__: so lets define 4.10 still as required version when the problem is fixed in schroedinger or orc, coohse the new versions . Apr 18 23:40:30 hmm Apr 18 23:40:41 might want to cache the generated runqueue as well, otherwise we'd have to regenerate it in each process.. also, reading the recipe cache from disk and writing it out is nontrivial. It gets pulled entirely into ram, and it's like 100-150 megs of python objects, to be used to generate the runqueue Apr 18 23:40:43 yeah, that might very well be Apr 18 23:41:05 (which is terrible, and lame, but using something like sqlite *kills* our performance) Apr 18 23:42:20 heh, amazing how that works. it's almost like someone spent a lot of time working on making object access fast and reliable ;) Apr 18 23:44:52 heh. sadly the list of things we need to improve/fix in bitbake is pretty massive. gets the job done, but that's about the best that can be said for it at this point Apr 18 23:46:21 c'est la vie Apr 18 23:46:43 heh, such is the case with many projects, i'm sure Apr 18 23:47:58 I've never met a programmer who thought they were done Apr 18 23:53:32 good night Apr 19 00:19:25 a feature that might be a nice-to-have in future is for bitbake to retry a download that fails checksum Apr 19 02:35:23 khem, how long did your regression normally take...wasn't it like 5.5-6days? **** ENDING LOGGING AT Tue Apr 19 02:59:57 2011