**** BEGIN LOGGING AT Thu May 14 02:59:57 2009 May 14 06:35:23 good morning May 14 07:49:47 good morning May 14 08:35:33 morning May 14 08:40:15 hi hrw May 14 08:47:54 hi mckoan May 14 08:47:59 * hrw just got 2 sheevas May 14 08:49:06 hrw: at last! :-D May 14 09:17:20 Hi all May 14 09:22:19 I'm working with a beagleboard and I need to debug a program that uses wxWidgets. The problem is that I can't build wxWidgets with debug support (it looks like no recipe is available for this). May 14 09:22:50 is there a way to build them with debug support? May 14 09:23:05 morning all May 14 09:23:57 hey RP May 14 09:24:05 morning RP May 14 09:26:21 03Robert Schuster  07org.openembedded.dev * r73a335bf9f 10openembedded.git/recipes/llvm/ (2 files): May 14 09:26:21 llvm2.6-native: SRCREV -> SRCPV May 14 09:26:21 llvm2.6: SRCREV -> SRCPV May 14 09:26:22 03Robert Schuster  07org.openembedded.dev * r265c4780f4 10openembedded.git/recipes/llvm/ (4 files in 2 dirs): May 14 09:26:22 New recipes by Xerxes Ranby (xerxes@zafena.se) May 14 09:26:24 llvm2.6 2.5+svnr20090409: New recipe. May 14 09:26:28 llvm2.6-native 2.5+svnr20090409: New recipe. May 14 09:26:30 llvm-native.inc: Depend on cmake-native. May 14 09:26:32 03Robert Schuster  07org.openembedded.dev * r940735573b 10openembedded.git/recipes/llvm/ (2 files): May 14 09:26:35 llvm2.6-native 2.5+svnr20090409: Removed (replaced by newer snapshot). May 14 09:26:37 llvm2.6 2.5+svnr20090409: Dito. May 14 09:31:07 03Robert Schuster  07org.openembedded.dev * r5c5e0a1bc2 10openembedded.git/recipes/cacao/files/cacao-disable-stackbase-check.patch: cacao: Added missing patch. May 14 09:42:08 good morning May 14 09:53:47 hi florian May 14 09:53:51 hi zecke May 14 09:53:59 hey! May 14 09:54:02 hi RP May 14 09:58:00 RP: wish me luck... I finally want to do something about the parser :} May 14 10:01:36 zecke: I wish you luck too May 14 10:01:45 parsing time annoys me May 14 10:02:12 zecke: parsing is slow as never before...ok 6600+ recipes, I know May 14 10:02:14 zecke: ohh good guy! May 14 10:02:45 ant_work: parsing is not slower, the data structure should scale linearily... :) May 14 10:02:59 ant_work: you just have more data May 14 10:03:22 I'm still under the impression a few months ago was faster May 14 10:04:14 ant_work: oh well, benchmark then? May 14 10:04:23 he he May 14 10:04:46 was not meant to be a joke. if we think web pages load slower than before we benchmark and have a regression suite... May 14 10:04:57 I plan to go back to my /tmp in ram solution May 14 10:05:05 I got some nice improvements May 14 10:05:14 if you think parsing gets slower and does not scan linearily with the number of recipes, benchmark... May 14 10:05:53 do you think the disk i/o has big effect on it or is more CPU task (I think) May 14 10:06:12 benchmark, show data :) May 14 10:06:23 it ain't that hard, just proper engineering May 14 10:09:19 zecke: the point is I'd like to have /tmp in ram but /deploy *out* of ram but this leads now to a can of new issues May 14 10:09:47 zecke: good luck! May 14 10:10:21 ant_work: the point is. If you think it got slower... then don't try to hack around it... find out the _root_ cause May 14 10:10:29 ant_work: everyone will benefit, it takes the same amount of time May 14 10:10:54 * RP does run profiles occassionally and removes hot spots May 14 10:10:59 I'm new to python-timings... May 14 10:11:02 ;) May 14 10:11:02 ant_work: it might be well like a couple of new overrides or some more immediate assignments... May 14 10:11:04 but them people at new ones... May 14 10:11:09 Im pretty sure zecke is right about the linearity May 14 10:11:11 but then people add new ones :/ May 14 10:11:19 ant_work: time bitbake -p foo May 14 10:11:19 but in past few months we went from 4000 to 6000 recipes May 14 10:11:45 It is linear but human perception of time means 4000 -> 6000 seems non linear May 14 10:12:01 I suspect there's mileage in cleaning out some of the recipies for old versions of things. May 14 10:12:57 zecke: What are you planning to do with the parser? May 14 10:13:24 RP: first of all a proper syntax tree and evaluating it... this will probably end up in a net slowdown May 14 10:13:36 (i will start with it after this last netscape plugin fix...) May 14 10:13:54 zecke: Will this include history tracking of variables?> May 14 10:14:30 ant_work: the point is: with "time" you have everything you need. and everyone can use that. May 14 10:14:42 or at least variable dependencies? May 14 10:14:58 RP: not immediately, it could fall out naturally (history tracking) May 14 10:15:42 zecke: When I have this some thought a while ago, I reasoned that the way forward for speed was to be able to track what depends on what May 14 10:16:07 zecke: from recreating cache to 'Executing runqueue'? May 14 10:16:11 So if I change SRCREV_pn-foo in my local.conf, it doesn't have to reparse everything as it knows only the foo recipe is influenced by the change May 14 10:17:01 RP: sometimes it works like this..just 1 recipe is reparsed May 14 10:17:13 ant_work: really?! :) May 14 10:17:27 Yep, I'v eseen it ! May 14 10:17:40 ant_work: I wrote the cache handling in bitbake ;-) May 14 10:17:45 just recipes, if youtouch /conf i different May 14 10:17:49 RP: quick steal ant_works version of bitbake, it obviouly evolved May 14 10:17:57 ;) May 14 10:20:03 my point is broonie's one: clean out old cruft May 14 10:20:05 XorA: :) May 14 10:20:29 BBCLASSEXTEND will gain some time back May 14 10:20:38 You core-devs...what's the support-deadline for linux-2.4 e.g.? May 14 10:20:41 RP: one way would be an extra cache with the syntax tree of all recipes... then changing the conf/local.conf would reduce the parsing to re-evaluating... May 14 10:21:09 RP: but dependency tracking (e.g. PROVIDES, DEPENDS...) is tricky specially with embedded python code to manipulate it... May 14 10:21:10 zecke: That data structure would be huge though May 14 10:21:29 zecke: There is only a small list of variables we need to cache though May 14 10:21:45 RP: yes, the question is, will it be faster than rereading... and actually it will not :} (unless I do jedi tricks) May 14 10:22:01 03Dmitry Eremin-Solenikov  07org.openembedded.dev * r6cf180ff0c 10openembedded.git/: Merge branch 'org.openembedded.dev' of git://git.openembedded.net/openembedded into org.openembedded.dev May 14 10:22:03 03Dmitry Eremin-Solenikov  07org.openembedded.dev * r7819d379e1 10openembedded.git/: Merge branch 'org.openembedded.dev' of git://git.openembedded.net/openembedded into org.openembedded.dev May 14 10:22:03 03Dmitry Eremin-Solenikov  07org.openembedded.dev * r0628081b03 10openembedded.git/recipes/madwifi/ (4 files in 2 dirs): May 14 10:22:03 madwifi: compilation fixes May 14 10:22:03 Fix compilation of madwifi-ng May 14 10:22:05 1) for powerpc arches with recent kernels (which provide no PPC_MERGE config) May 14 10:22:07 2) for 2.6.30-rc kernels which provide no more netdev->priv May 14 10:22:09 Signed-off-by: Dmitry Eremin-Solenikov May 14 10:22:13 03Dmitry Eremin-Solenikov  07org.openembedded.dev * rd4a2ec9e83 10openembedded.git/: Merge branch 'org.openembedded.dev' of git://git.openembedded.net/openembedded into org.openembedded.dev May 14 10:22:16 03Dmitry Eremin-Solenikov  07org.openembedded.dev * rf7ee7a1961 10openembedded.git/recipes/linux/linux-2.6.28/at91sam9g20ek/defconfig: May 14 10:22:19 linux-2.6.28: Provide a default config for at91sam9g20ek board May 14 10:22:23 Signed-off-by: Dmitry Eremin-Solenikov May 14 10:22:30 zecke: We might need to add information to the python functions about which variables they change May 14 10:22:40 RP: one thing we have to do is to forbid manipulating DEPENDS from python code... or through one place and then use something like gcc assembler syntaxn and say which registers were clobbered May 14 10:22:45 RP: hehe, agreed May 14 10:23:08 zecke: Its solvable :) May 14 10:23:27 zecke: my gut instinct is the only way we can go faster is with some kind of tracking like that May 14 10:23:53 Collapsed to a small set of variables which we cache as per the current arrangement so we don't have all the data to wade through May 14 10:24:24 and then we can remove my horrible hack of caching the expanded data :/ May 14 10:24:39 I still can't believe we get away with that ;-) May 14 10:24:53 RP: with older metadata... lexing and parsing took like nothing... running all the anonymous python things... May 14 10:25:33 zecke: What do those functions all do and can we find better ways to do it? May 14 10:26:12 RP: another thing to consider is persistant cache in some form of network storage ideally probably a real SQL database May 14 10:26:21 RP: so clusters of build machines can share it May 14 10:27:05 XorA: ouch May 14 10:27:27 XorA: I once tried metadata in sql for bitbake and it was a world of pain May 14 10:28:05 RP: just need the stuff that is in bb_persist_data.sqlite3 May 14 10:28:16 XorA: Ah, that would be fine May 14 10:28:27 RP: so that multiple build machines get the save git versions May 14 10:28:33 s/save/same/ May 14 10:28:46 Makes a lot of sense May 14 10:29:04 XorA: you are paid by oracle? :D May 14 10:29:13 'get real sql database' May 14 10:29:14 hrw: I wish :-) May 14 10:29:35 hrw: but last I checked postgres was a real db :-D May 14 10:32:02 btw: is there any difference parsing from a recent checkout vs. old checkout + lot of pulls? Anyone timed? May 14 10:32:45 ant_work: If there is something's seriously buggy... May 14 10:33:02 he...there is db and db May 14 10:33:15 I hope git is in good shape :) May 14 10:33:43 try with msacces :=) May 14 10:34:27 only problems git seems to cause is it creates blah_ver.REMOTE.bb files which upsets bitbake a bit when I forget to clear them May 14 10:35:30 That's a configuration option; I've never noticed it beign the default (but then I never do pulls, always update+merge). May 14 10:35:34 ant_work: Shouldn't make any difference at all May 14 10:35:51 broonie: its mergeing that makes them May 14 10:36:11 broonie: I think the difference is you probably never make conflicting commit May 14 10:36:31 XorA: I get lots of conflicts, but the behaviour I have is to handle them CVS style. May 14 10:36:40 broonie: eeeeewwwwwwwww May 14 10:37:32 broonie: I'd seek help ;-) May 14 10:37:41 actually I guess its probably git mergetool that creates those files May 14 10:37:44 * broonie has never adjusted the default. May 14 10:37:47 XorA: Yes. May 14 10:37:53 broonie: nor have I May 14 10:38:05 Probably changed since I last cloned something new. May 14 10:42:47 lmbench on sheeva takes eons May 14 10:43:18 apparently my sheeva has arrived at home! May 14 10:46:42 RP: some autoinject the libc6 dependencies (IIRC) May 14 10:46:53 RP: or automake things May 14 10:47:52 zecke: right. I wonder how else we could do it... May 14 10:49:31 03Florian Boor  07org.openembedded.dev * rf3ba294a0e 10openembedded.git/conf/distro/include/sane-srcdates.inc: sane-srcdates.inc: set rosetta src date. May 14 10:49:34 03Florian Boor  07org.openembedded.dev * r25802e54c4 10openembedded.git/recipes/gsoko/ (gsoko-0.4.2-gpe6/fix_install.patch gsoko_0.4.2-gpe6.bb): gsoko: Remove one fix of two for the same issue. May 14 10:50:39 ant_work: wish that patch was a proper OE patch May 14 10:54:46 RP: not much May 14 10:55:00 RP: I think some "static" clobber/used variables May 14 11:02:08 XorA: if you don't like to patch the patches, try kexec-tools-2.0 :) May 14 11:02:27 XorA: kexec/arm is upstream May 14 11:03:29 zecke: That would work May 14 11:03:48 03Koen Kooi  07org.openembedded.dev * r1e32aeba17 10openembedded.git/recipes/mozilla/fennec_hg.bb: fennec: add libnotify to depends, reorder fields May 14 11:10:08 ant_work: patch doesnt work May 14 11:11:47 hm...it appears was tested on collie...different kernel? May 14 11:29:17 mickey|zzZZzz: Does this ring a bell? "./libpython2.6.so: undefined reference to `_PyParser_Grammar'" May 14 11:35:28 ant_work: its just garbage in patch May 14 11:38:14 ant_work: NOTE: package kexec-tools-static-1.101-r5: task do_compile: completed May 14 11:41:22 03Graeme Gregory  07org.openembedded.dev * r55e9491677 10openembedded.git/: Merge branch 'org.openembedded.dev' of git+ssh://git@git.openembedded.net/openembedded into org.openembedded.dev May 14 11:41:26 03Graeme Gregory  07org.openembedded.dev * r8bef3a222f 10openembedded.git/recipes/kexec/ (files/kexec-arm-atags.patch kexec-tools-static_1.101.bb): May 14 11:41:26 kexec-tools-static_1.101.bb : fix compile on newer kernels based on work done May 14 11:41:26 by Peter Chubb May 14 11:44:51 03Dmitry Eremin-Solenikov  07xora/angstrom-srcpv * r6cf180ff0c 10openembedded.git/: Merge branch 'org.openembedded.dev' of git://git.openembedded.net/openembedded into org.openembedded.dev May 14 11:44:52 03Dmitry Eremin-Solenikov  07xora/angstrom-srcpv * r7819d379e1 10openembedded.git/: Merge branch 'org.openembedded.dev' of git://git.openembedded.net/openembedded into org.openembedded.dev May 14 11:44:54 03Dmitry Eremin-Solenikov  07xora/angstrom-srcpv * r0628081b03 10openembedded.git/recipes/madwifi/ (4 files in 2 dirs): May 14 11:44:54 madwifi: compilation fixes May 14 11:44:55 Fix compilation of madwifi-ng May 14 11:44:57 1) for powerpc arches with recent kernels (which provide no PPC_MERGE config) May 14 11:44:59 2) for 2.6.30-rc kernels which provide no more netdev->priv May 14 11:45:01 Signed-off-by: Dmitry Eremin-Solenikov May 14 11:45:05 03Koen Kooi  07xora/angstrom-srcpv * r8126c9725a 10openembedded.git/recipes/udev/udev_141.bb: udev 141: continue cleaning out udev legacy stuff May 14 11:45:08 03Koen Kooi  07xora/angstrom-srcpv * ra6abba0064 10openembedded.git/contrib/angstrom/build-feeds.sh: May 14 11:45:11 angstrom feed builder: allow builder to override machinelists on the commandline May 14 11:45:13 * usage: sh build-feeds.sh machine1 machine2 machineN May 14 11:45:15 03Koen Kooi  07xora/angstrom-srcpv * r1e32aeba17 10openembedded.git/recipes/mozilla/fennec_hg.bb: fennec: add libnotify to depends, reorder fields May 14 11:45:20 03Dmitry Eremin-Solenikov  07xora/angstrom-srcpv * rd4a2ec9e83 10openembedded.git/: Merge branch 'org.openembedded.dev' of git://git.openembedded.net/openembedded into org.openembedded.dev May 14 11:45:23 03Graeme Gregory  07xora/angstrom-srcpv * r55e9491677 10openembedded.git/: Merge branch 'org.openembedded.dev' of git+ssh://git@git.openembedded.net/openembedded into org.openembedded.dev May 14 11:45:28 03Florian Boor  07xora/angstrom-srcpv * rf3ba294a0e 10openembedded.git/conf/distro/include/sane-srcdates.inc: sane-srcdates.inc: set rosetta src date. May 14 11:45:31 03Graeme Gregory  07xora/angstrom-srcpv * r017ba4b198 10openembedded.git/: Merge branch 'org.openembedded.dev' of git+ssh://git@git.openembedded.net/openembedded into xora/angstrom-srcpv May 14 11:45:34 03Florian Boor  07xora/angstrom-srcpv * r25802e54c4 10openembedded.git/recipes/gsoko/ (gsoko-0.4.2-gpe6/fix_install.patch gsoko_0.4.2-gpe6.bb): gsoko: Remove one fix of two for the same issue. May 14 11:45:39 03Koen Kooi  07xora/angstrom-srcpv * r5391c3d2f4 10openembedded.git/recipes/gcc/ (gcc-4.3.3.inc gcc-cross_4.3.3.bb gcc_4.3.3.bb): May 14 11:45:42 gcc 4.3.3: fix regression from 4.3.1 that caused fortran to get disabled for linux-gnueabi May 14 11:45:44 * powerpc people are welcome to enable fortran as well :) May 14 11:45:46 03Robert Schuster  07xora/angstrom-srcpv * r5c5e0a1bc2 10openembedded.git/recipes/cacao/files/cacao-disable-stackbase-check.patch: cacao: Added missing patch. May 14 11:45:51 03Robert Schuster  07xora/angstrom-srcpv * r940735573b 10openembedded.git/recipes/llvm/ (2 files): May 14 11:45:54 llvm2.6-native 2.5+svnr20090409: Removed (replaced by newer snapshot). May 14 11:45:56 llvm2.6 2.5+svnr20090409: Dito. May 14 11:45:58 03Dmitry Eremin-Solenikov  07xora/angstrom-srcpv * rf7ee7a1961 10openembedded.git/recipes/linux/linux-2.6.28/at91sam9g20ek/defconfig: May 14 11:46:03 linux-2.6.28: Provide a default config for at91sam9g20ek board May 14 11:46:05 Signed-off-by: Dmitry Eremin-Solenikov May 14 11:46:07 03Robert Schuster  07xora/angstrom-srcpv * r73a335bf9f 10openembedded.git/recipes/llvm/ (2 files): May 14 11:46:10 llvm2.6-native: SRCREV -> SRCPV May 14 11:46:12 llvm2.6: SRCREV -> SRCPV May 14 11:46:14 03Robert Schuster  07xora/angstrom-srcpv * r265c4780f4 10openembedded.git/recipes/llvm/ (4 files in 2 dirs): May 14 11:46:19 New recipes by Xerxes Ranby (xerxes@zafena.se) May 14 11:46:21 llvm2.6 2.5+svnr20090409: New recipe. May 14 11:46:23 llvm2.6-native 2.5+svnr20090409: New recipe. May 14 11:46:25 llvm-native.inc: Depend on cmake-native. May 14 11:46:27 03Tom Rini  07xora/angstrom-srcpv * r657105b567 10openembedded.git/recipes/gcc/ (4 files): gcc*4.3.3: Switch to INC_PR, start at r3 May 14 11:46:30 03Graeme Gregory  07xora/angstrom-srcpv * r8bef3a222f 10openembedded.git/recipes/kexec/ (files/kexec-arm-atags.patch kexec-tools-static_1.101.bb): May 14 11:46:39 kexec-tools-static_1.101.bb : fix compile on newer kernels based on work done May 14 11:46:41 by Peter Chubb May 14 11:46:54 Crofton|work: can I get some patchwork priviledges? May 14 11:49:07 XorA: good...how far are kexec-tools-2.0? May 14 11:49:48 ant_work: I wont look at that, I have very little interest in zauruses May 14 11:50:15 and beagleboard? May 14 11:50:29 does that need kexecboot? May 14 11:50:36 * ant_work hides May 14 11:51:35 I only worked on tosa because I got bored for a week and I happen to have the OE one as no-one else wants it May 14 11:55:40 I see, I'll try to bump to kexec-tools-2.0. Less patches needed hopefully. Just wondering about how to add uImage support: in kexecboot or in kexec-tools? Jay7 suggests the latter. May 14 11:56:14 support = strip 64bytes May 14 11:56:37 we don't take in account .gz images May 14 11:56:43 ant_work: there is more to it than that May 14 11:56:52 oh you realised :-) May 14 11:57:21 well, I think I was the only one compressing a uImage :) May 14 11:57:30 I was badly needing that 4kb! May 14 11:57:48 XorA, sure! May 14 11:57:53 XorA: iirc yousaid I compressed the decompressor May 14 11:58:06 hehe yup May 14 12:00:01 XorA, done May 14 12:01:43 Crofton|work: cheers, I have now applied a patch :_D May 14 12:08:25 Hi May 14 12:08:57 Did the commit that renamed packages/ to recipes/ essentially cut of direct access to all previous history? May 14 12:09:18 "git log $blah" never goes beyond Mar 17 for me, it seems May 14 12:09:37 git log --follow file May 14 12:10:21 Ah, alright May 14 12:10:45 rename is not handled well in git May 14 12:11:11 well, yes and no May 14 12:12:02 Apparently, git is smart enough to detect a "false rename" were the file is destroyed but recreated with the same content elsewhere May 14 12:12:21 it works sometimes May 14 12:12:26 mtn expressly needed the "mtn mv" command for that or it would not recognize it May 14 12:12:49 can I set --follow as default? May 14 12:12:58 git doesn't track renames at all. May 14 12:12:58 I'm sure it can be done, I guess the question is how May 14 12:13:21 broonie: what do you mean? I'd say your statement is not true May 14 12:13:24 All it's doing is taking a guess that a file may have been renamed. May 14 12:13:30 no May 14 12:13:36 "git mv" exists May 14 12:13:42 no guesswork there May 14 12:13:58 There is no metadata recorded by git for file renames, git mv is just syntactic sugar that does the add and rm operations for you. May 14 12:14:02 hi kergoth May 14 12:15:16 tracking renames was where they dropped the ball on git May 14 12:15:27 I see May 14 12:15:33 XorA: wv :) May 14 12:15:46 lets switch back to mtn then May 14 12:15:54 --follow does not work on directories :-( May 14 12:16:12 only on explicit files May 14 12:16:14 I guess the arm kernel guys are probably cursing the lack of renames these days :-) May 14 12:16:26 after the huge arm upheaval May 14 12:16:49 It's mostly just register definitions, the interesting stuff is all in the source anyway. May 14 12:16:58 (not just ARM either, everything moved under arch). May 14 12:17:59 broonie: do you know the reasoning for that big reorg? May 14 12:21:09 zecke: Makes things nicer for the build system AIUI. May 14 12:21:25 ant_work: linux-kexecboot is broken by the new toolchain :-) May 14 12:28:25 ~curse console-image for its 2600 tasks May 14 12:28:26 May you be reincarnated as a Windows XP administrator, console-image for its 2600 tasks ! May 14 12:34:02 broonie, you think they would have fixed git first :) May 14 12:34:57 Crofton|work: It seems to cope with the renames fine for me. May 14 12:38:17 what is everyone complianing aboutthen May 14 12:48:13 bbl - food May 14 12:50:05 moo May 14 13:10:28 hi raster May 14 13:10:39 florian: beep! May 14 13:11:06 Anyone else here who suffers from python failing to build? May 14 13:18:41 03Jeremy Lainé  07org.openembedded.dev * rb530076ad1 10openembedded.git/recipes/linux/linux-2.6.29/boc01/defconfig: linux-2.6.29: reduce boc01 kernel size May 14 13:21:26 hi kergoth May 14 13:40:46 argh.. May 14 13:40:57 task-base builds ppp which req libpcap which req BT May 14 13:42:27 I am considering split of task-base into recipes per task May 14 13:43:50 but no.. it does not fix it May 14 14:03:28 03Sergey Lapin  07org.openembedded.dev * rcfbb95b3bb 10openembedded.git/: Merge branch 'org.openembedded.dev' of git@git.openembedded.net:openembedded into afeb9260-tmp May 14 14:03:38 03Sergey Lapin  07org.openembedded.dev * rd02457b03a 10openembedded.git/recipes/dvd+rw-tools/ (9 files in 2 dirs): dvd+rw-tools: Added new recipe May 14 14:28:43 03Sergey Lapin  07org.openembedded.dev * r5abc720bf3 10openembedded.git/conf/machine/ (afeb9260-180.conf afeb9260.conf include/afeb9260.inc): May 14 14:28:43 AFEB9260: add 180MHz config, split machine conf May 14 14:28:43 I really do this just because I need to support 2 board variants May 14 14:28:43 180 MHz and default 166MHz. Each one needs different May 14 14:28:43 setup for at91bootstrap and (probably) u-boot. May 14 14:36:20 hi kergoth, kergoth_, kergoth__, kergoth___, kergoth____ May 14 14:36:25 03Mike Westerhof  07stable/2009 * r8013917e07 10openembedded.git/recipes/monit/ (monit-4.10.1/no-strip-in-makefile.patch monit_4.10.1.bb): May 14 14:36:25 monit: add patch to remove -s in install. May 14 14:36:25 Signed-off-by: Koen Kooi May 14 14:36:25 Acked-by: Philip Balister May 14 14:36:27 03Koen Kooi  07stable/2009 * r942330dd5a 10openembedded.git/conf/checksums.ini: May 14 14:36:30 checksums.ini: sync with .dev May 14 14:36:32 Acked-by: Marcin Juszkiewicz May 14 14:36:34 Signed-off-by: Koen Kooi May 14 14:36:36 03Sergey Lapin  07org.openembedded.dev * r3fd24860b7 10openembedded.git/recipes/u-boot/ (u-boot-git/afeb9260/AFEB9260-network-fix.patch u-boot_git.bb): u-boot_git: updated for latest version for afeb9260 May 14 14:37:01 oh, sorry, and kergoth_____ May 14 14:37:16 that's quite the uber-tail you have there May 14 14:41:15 03Sergey Lapin  07org.openembedded.dev * r84feccc2c5 10openembedded.git/recipes/linux/ (5 files in 2 dirs): linux: added 2.6.30-rc4 May 14 14:41:17 03Sergey Lapin  07org.openembedded.dev * r215a464bbd 10openembedded.git/recipes/linux/linux_2.6.28-rc6.bb: AFEB9260 is not supported with 2.6.28-rc6 kernel anymore May 14 14:44:10 hi otavio May 14 14:44:46 otavio: can you ack my stable/2009 patches? python 2.6 ones May 14 14:45:31 hrw: let me take a look May 14 14:46:51 thx May 14 14:48:44 bye May 14 14:57:53  May 14 15:02:37 hrw: I think I've done it May 14 15:02:42 hrw: please check May 14 15:02:50 thx May 14 15:03:24 otavio: patchwork needs to grab mails May 14 15:12:08 hrw: oh yes May 14 15:12:26 hrw: I'll update my patchset to dev too and try to push it this WE May 14 15:23:08 03Marcin Juszkiewicz  07stable/2009 * ra52a4633c2 10openembedded.git/classes/patch.bbclass: (log message trimmed) May 14 15:23:08 patch.bbclass: use hashlib with Python 2.5+ - removes DeprecationWarning May 14 15:23:08 Patch.bbclass change removes DeprecationWarnings too but has to keep May 14 15:23:08 compatibility with Python 2.4 so I had to use try/except block because May 14 15:23:10 hashlib is 2.5+ May 14 15:23:12 Signed-off-by: Marcin Juszkiewicz May 14 15:23:14 Acked-by: Koen Kooi May 14 15:23:16 03Richard Purdie  07stable/2009 * r8633a47ed9 10openembedded.git/bitbake/lib/bb/ (COW.py cache.py cooker.py data_smart.py runqueue.py): (log message trimmed) May 14 15:23:19 bitbake: Update to work without warnings with python 2.6 May 14 15:23:21 Some time ago I fixed BitBake trunk to not generate DeprecationWarnings May 14 15:23:23 when used with Python 2.6. Some time later Richard Purdie backported it May 14 15:23:25 into bitbake-1.8 branch. Now I tested it with stable/2009 and want to May 14 15:23:27 get it inside. May 14 15:23:29 Signed-off-by: Richard Purdie May 14 15:52:05 cu tomorrow May 14 16:03:46 morning May 14 16:05:12 ah, back to just one kergoth May 14 16:05:21 indeed. May 14 16:06:00 kergoth: good morning May 14 16:09:59 morning May 14 16:10:23 pb___: you see the mvl6 announcements? :) May 14 16:38:42 kergoth: yah, good work! May 14 16:39:22 oh, while you're around, any opinion on http://thread.gmane.org/gmane.comp.handhelds.openembedded/23680 ? May 14 16:50:04 kergoth: yeah, looks good. I kind of feel that this whole area of bitbake behaviour needs a bit of rethinking, and that's maybe another thing I'd like to change as part of some putative OE-ng, but your patch looks like a decent thing to do given the constraints of the current infrastructure. May 14 16:50:53 agreed. bitbake's default behavior of using the latest is something that should never have been allowed, but to make that more explicit i think would require better interfaces for the user to express what they want in their build May 14 16:52:50 right, exactly. with hindsight, the whole way that version selection is done was a bit of a dim idea, and it's made worse by the fact that versioned DEPENDS have never really worked so even individual recipes have no real control over what versions they get. May 14 16:53:16 this is causing us a bit of a headache at my company, actually. I think I will probably end up having to fix up the versioned depends support in at least some minimal way. May 14 16:54:53 ultimately, the "right way" to solve this for most people is probably to exhume something like oecommander and give people a (semi-)graphical tool to control versions on a per-package basis: either let them float to the latest, or freeze them at the current versions, or set them explicitly to a specific revision. May 14 16:55:21 plus. obviously, the right bits to handle cascading versioned dependencies through packages and whatever conflict resolution that implies May 14 16:55:39 kind of like aptitude for source packages I suppose May 14 16:56:46 gm May 14 16:56:52 hi likewise May 14 16:57:14 obviously you wouldn't want that frontend to be the only way of exercising control, so there'd have to be some documented backend format as well for distro maintainers or other people who want to distribute their configurations, but in practice I suspect most "casual users" would end up using the tool rather than hacking the version definitions by hand. May 14 16:57:21 * kergoth nods May 14 16:57:24 that would be quite nice May 14 16:57:25 I'd love to see the user run a project setup script which goes out and yanks down all the bits they want to build, and their deps, like apt, as you say, and then bitbake just builds what they've got in their project dir. then if they want to update to a newer version, they ask it to update the version in their local area. a setup like that would make it *much* easier to improve usability for the app/kernel dev use case, also, since it could easily be made to May 14 16:57:42 * florian -> home, bbiab May 14 16:59:30 A bitbake feature request: have softlinks in the tmp/work///temp/ directory, where the pidless softlink points to the most recently run script and log May 14 17:00:03 hey likewise May 14 17:00:04 heh, my big concern with the various ideas being thrown around is how to go about making them happen without a rewrite, since rewrites seem to cause problems, take forever, worry the userbase, split development effort, .. May 14 17:00:12 Did you say you have any 4xx targets around? May 14 17:00:16 kergoth: your last comment seems to have gotten chopped at "... could easily be made t". May 14 17:00:41 kergoth: yah, indeed, that is a problem May 14 17:01:09 oh, right, was thinking it could even pull down a source tree from an scm that contains the recipe, rather than just metadata, so the user could more easily develop and use bitbake for the modify/compile/test/deploy cycle May 14 17:01:16 Tartarus: e300 (MPC8315E and 13E), and one 4xx (AMCC460EX) May 14 17:01:21 stupid colloquy.. xchat is smartenough to split long lines May 14 17:01:30 likewise, is the 460EX 'free' ? May 14 17:01:41 Tartarus: free in what sense? :-) May 14 17:01:52 Like I could give you a console-image? :) May 14 17:01:56 Tartarus: released to the wild? May 14 17:02:02 Our dht-walnut is spewing crap on console at boot May 14 17:02:17 and ocotea networking isn't working for some reasom May 14 17:02:19 *reason May 14 17:02:20 bbiab, gotta go finish re-potting my banana plant May 14 17:02:44 Tartarus: I just got home (I'm UTC+1) and only brought the MPC8315E devkit with me this time. May 14 17:03:02 likewise, k May 14 17:03:07 Tartarus: so yes it's free, but it's Too Far Away From Me, Too Far I Just Can't See May 14 17:03:12 Could you have the 460EX for tomorrow? May 14 17:03:28 Tartarus: no I planned on working on the 15E devkit from home. May 14 17:03:32 Ah, k May 14 17:04:11 Tartarus: crap during u-boot or Linux? May 14 17:04:29 walnut has uboot i think May 14 17:04:37 and yeah, power-up, crap out serial port May 14 17:04:45 tried all the normal uart speeds May 14 17:04:46 Tartarus: I had kernel crap once, which was old u-boot versus new DTB. May 14 17:05:07 Tartarus: Let me check my email thread on that one, might have been u-boot crap... May 14 17:05:14 ok May 14 17:05:38 If we weren't busy with 'work', I could get someone to throw a BDI on there and reflash u-boot or something May 14 17:05:49 I'm gonna see how the walnut stuff fairs w/ qemu, heh May 14 17:08:22 Tartarus: "FSL U-Boots use /soc8315@e0000000 node to search and fixup serial nodes' clock-frequency properties." "This makes FSL U-Boots fail to fixup the clock frequencies, and that leads to serial ports misbehaviour." May 14 17:08:54 Tartarus: but that only explained the kernel serial crapping out I think May 14 17:09:01 yeah May 14 17:09:10 this board worked before it got boxed up and moved around May 14 17:09:18 might have even worked after the move May 14 17:09:43 Tartarus: what do you need me to do on the 460EX? May 14 17:10:08 likewise, just boot a console-image up so we have some proof that gcc 4.3.3 builds working stuff May 14 17:11:53 Tartarus: is the gcc-4.3.3 now in git for angstrom/ppc? May 14 17:12:42 Nope, just did a local change May 14 17:12:46 Test then get it committed :) May 14 17:12:51 (Well, approved, heh) May 14 17:13:05 Tartarus: k, I can test only for e300. You didn't change binutils? May 14 17:13:39 binutils wasn't held back May 14 17:17:10 I need a good deal of Battlefield Heroes to shake off todays (documentation) work first May 14 17:18:15 hah May 14 17:29:04 ok, qemu isn't going to be helpful :( oh well May 14 17:35:29 03Theodore A. Roth  07org.openembedded.dev * r86999e9433 10openembedded.git/recipes/evtest/evtest_1.23.bb: May 14 17:35:29 evtest: Fixed GNU_HASH QA error. May 14 17:35:29 Signed-off-by: Theodore A. Roth May 14 17:35:29 Acked-by: Denys Dmytriyenko May 14 18:06:50 re May 14 18:16:21 wb pb___ May 14 18:27:00 re May 14 18:28:58 kergoth: what do you see as the advantages of locking down versions vs just branching/tagging the OE meta data? I guess you would get fixes to the meta data, and still keep the version. May 14 18:29:25 right, you get bugfixes, they only affect PR, not PV. May 14 18:30:08 course, the obvious downside is class changes could still break you May 14 18:30:38 but i dont see this as a replacement for branching/tagging, just a slightly more sane default within the context of a single tmp existance, and a convenient and less intrusive way to keep things where you are May 14 18:31:07 cbrake: that, plus it allows you to cherry-pick updates to some packages without having to do a wholesale upgrade of your entire filesystem May 14 18:32:04 if you branched the whole repo then you end up having to pull across the new revisions at the SCM level, which gets a bit tedious especially when there are interactions with classes. May 14 18:32:11 that's true. course, oyu can do that with actual cherry picking, but maintaining a long lived branch with cherry picks is a royal pain in the ass. if you have to change the commit when you cherry pick, git no longer has any idea that those two are the same thing, so keeping track of what you'ved pulled over and what you ahvent in a pain May 14 18:32:16 heh :) May 14 18:35:17 03Chris Larson  07org.openembedded.dev * rc0622e65a9 10openembedded.git/classes/ (4 files): May 14 18:35:17 First pass of cleanup of messages outputted to the user. May 14 18:35:17 OpenEmbedded outputs a lot of messages that the user is likely to never May 14 18:35:17 care about. We should only output something when it reflects upon their May 14 18:35:17 recipe (i.e. unpacking their sources, applying their patches), or is quite May 14 18:35:21 significant or unusual. May 14 18:35:23 Signed-off-by: Chris Larson May 14 18:35:25 03Chris Larson  07org.openembedded.dev * r9699a955d4 10openembedded.git/classes/ (base.bbclass packaged-staging.bbclass patch.bbclass): May 14 18:35:28 Shorten some full paths printed to the user. May 14 18:35:30 Adds a base_path_out convenience function, which prepares a full path for May 14 18:35:32 display to the user. The initial implementation just makes it relative to May 14 18:35:34 ${TOPDIR}. This function is then used for some messages outputted to the May 14 18:35:36 user (packaged-staging, patch application, clean, unpack tasks). May 14 18:35:38 Signed-off-by: Chris Larson May 14 18:35:39 yeah, exactly. if you're happy to maintain your own, effectively isolated metadata tree then this is all a non-problem: in the limit you can just delete all the .bb files except the single version of each package that you want to keep. but, once you go down that route, it gets increasingly difficult to re-sync with the main branch and that in turn means you end up duplicating a lot of work that's being done in mainline. May 14 18:36:30 and in some cases even when maintaining an isolated metadata tree, you may want to keep multiple versions long term. if you dont want to break anyone, ever, then you shouldnt remove old versions of recipes ever either, in which case a lockdown becomes useful May 14 18:37:02 * kergoth wanders off to find more caffeine May 14 19:23:09 can you guys run 'openssl speed md5 sha1 sha256 sha512 des des-ede3 aes-128-cbc aes-192-cbc aes-256-cbc rsa2048 dsa2048' command on your devices and send me output? May 14 19:33:30 hrw|gone, it's a new "bench" ... nice idea ! May 14 19:37:11 * XorA is confused by the sheeva u-boot May 14 19:38:26 * florian not yet ;) May 14 19:38:49 hrw|gone: That's a good idea... May 14 19:39:16 My new build system wont allow me to set the mmap_min_addr to 0 as OE wants :( Any suggestions ? May 14 19:39:53 hi rkirti May 14 19:39:54 rkirti: your root right? May 14 19:40:29 ok sheeva owners, how the hell to I flash this beast? May 14 19:40:38 florian: hello :) May 14 19:40:49 XorA: as in ? May 14 19:41:03 rkirti: you can only affect /sys filesystem as root May 14 19:41:20 XorA: isnt using the command with sudo enough ? May 14 19:41:25 rkirti: no May 14 19:41:36 rkirti: your redirecting the wrong command using sudo :-) May 14 19:41:45 rkirti: you redirected the sudo not the echo May 14 19:42:16 heh yes echo and sudo don't play that nice with each other :) May 14 19:42:44 echo 0 | sudo tee /sys/blah/blah May 14 19:42:54 rkirti: get a root shell (sudo su) and enter the command there May 14 19:42:58 XorA: oh ok May 14 19:43:11 solutions flood... :) May 14 19:43:33 florian, XorA : done :) thanks May 14 19:43:48 sorted! now tell people nice things about us :-D May 14 19:58:17 what insane u-boot is on the sheeva :-( May 14 20:00:11 Marvell u-boot of course! May 14 20:00:40 seems it supports no devices apart from nand, thats gonna make reflashing dificult May 14 20:00:50 you can use usb May 14 20:01:07 usbstart is a bit shit. works um, 60% of the time May 14 20:01:27 XorA you know it has jtag built in via the usb mini jack? May 14 20:01:37 it recognises my device, then bitches about the partition table May 14 20:01:48 you can just plug it in an fire up openocd (svn) and reflash May 14 20:02:05 03Chia-I Wu  07fso/milestone5.5 * r565c62378e 10openembedded.git/recipes/udev/ (4 files in 4 dirs): fastboot: udev-static-devices: New package to provide static dev nodes. May 14 20:02:05 03Chia-I Wu  07fso/milestone5.5 * r2b38193c50 10openembedded.git/recipes/udev/ (files/links.conf udev-118/openmoko/init udev_118.bb): fastboot: udev: Update init script to support udev-static-devices. May 14 20:02:32 XorA: http://www.cyrius.com/debian/kirkwood/sheevaplug/unpack.html may be helpful. May 14 20:04:00 print_part of 0 May 14 20:04:00 ## Unknown partition table May 14 20:06:53 switch to SDHC card reader and it likes that better :-( May 14 20:09:40 now how do I make and flash a UBI :-) May 14 20:10:15 florian: Hi May 14 20:10:59 hi dth1 May 14 20:12:01 florian: i just restartet the virt machine, not enough disk space ;.( May 14 20:13:18 dth1: you can confgure it to remove things it doesn't need any more. this helps quite a lot May 14 20:13:19 XorA, on x86 or your target/ May 14 20:13:38 BB will spit out a simple ubi/ubifs image that'll fill the partition you write it to May 14 20:14:15 mickey|zzZZzz: ping May 14 20:14:20 florian: let me guess, in the local.conf? May 14 20:14:23 BB spit me out a link to a non existant ubi May 14 20:14:42 eh? May 14 20:14:53 it made a link to a ubi file it never created May 14 20:15:00 that's odd May 14 20:16:05 what's the preferred graphical image for BB? x11-image? May 14 20:16:08 setting mine up atm May 14 20:16:28 curses and ext2load just crashes :-( May 14 20:17:09 dth1: yes... INHERIT += "rm_work" May 14 20:17:23 gah I hate it when new toys are annoying May 14 20:17:52 * Tartarus does a console-image 1st May 14 20:18:31 XorA: Most toys are shipped with bad booloaders May 14 20:18:49 OE definately does not produce a UBI May 14 20:19:01 XorA, it used to / should May 14 20:19:32 mkfs.ubifs -r /home/dp/openembedded/build/tmp/rootfs/console-image -o /home/dp/openembedded/build/tmp/deploy/glibc/images/sheevaplug/Angstrom-console-image-glibc-ipk-2009.X-test-20090514-sheevaplug.rootfs.ubifs -m 2048 -e 129024 -c 4096 May 14 20:19:33 /home/dp/openembedded/build/tmp/work/sheevaplug-angstrom-linux-gnueabi/console-image-1.0-r0/temp/run.do_rootfs.9265: line 599: mkfs.ubifs: command not found May 14 20:19:43 someone forgot some dependencies I guess May 14 20:20:01 XorA, did you downgrade mtd-utils-native? May 14 20:20:03 it's all in there May 14 20:20:17 I have touched anything to do with mtd May 14 20:20:50 what version built? May 14 20:21:02 1.0.0+git-r8 May 14 20:21:40 indeed, too old May 14 20:21:55 need 1.2.0+git, or 1.3.0, whatever exists and is higher May 14 20:21:57 someone has forgetten so set something in angstrom.conf I bet May 14 20:22:20 and probably everyone has the newer installed on their desktop :-) May 14 20:23:19 DEFAULT_PREFERENCE = "-1" May 14 20:23:27 with a comment that it doesnt compile May 14 20:23:39 that'll explain it :-) May 14 20:24:44 check the ml archives May 14 20:24:49 florian: INHERIT += "rm_work" so ok? May 14 20:25:35 dth1: yes May 14 20:27:59 florian: witch machine do you use for compiling image? May 14 20:28:13 well it compiles for me, now for some ubi making :-) May 14 20:28:56 dth1: Most of the time I use an IBM hs20 blade. May 14 20:29:39 florian: how many professors? May 14 20:30:14 you still have slave labour in .de florian? May 14 20:31:03 florian: is there a way in which I can get all the packages built for an image listed out in order ? something like -c listtasks, but here I am looking for package names ,to know the order in they are built for an image.. May 14 20:31:03 dth1: none... too expensive ;) it has two cpus May 14 20:31:24 XorA: need a new job? May 14 20:31:34 florian: no, keeping professors in blades :-) May 14 20:31:57 *gg* May 14 20:32:19 need a job that will pay for linuxtag :-) May 14 20:33:39 XorA: it might be easier to search for a well paid job and enjoy the fact not having to care... linuxtag is cheap luckily. May 14 20:34:01 Berlin is cheap and we should get a pile of free tickets. May 14 20:34:01 * kergoth is kind of surprised at the limited number of responses to freeze.inc, given it changes default behavior May 14 20:34:09 denix: did you have a chance to test it out? May 14 20:34:34 rkirti: uh... not that i'm aware of May 14 20:38:17 florian: ok..can I get my logic/thought-flow verified here ? I ll be doing many test builds to see how they go about the process - mamona's nearly done, poky port of maemo is up next - and I wanted to look at how they are going about the process, especially the distros that I am looking at. But I dont want to be around and keep checking what bitbake did.. May 14 20:38:20 kergoth, obviously everyone saw our conversation yesterday and thinks it is awesome May 14 20:38:26 haha May 14 20:38:58 florian: AFAIK, bitbake logs in the WORKDIR give me info on what happened at the package level, but I want a distro level overview. May 14 20:39:49 florian: if only I could redirect and save all the terminal output (that could actually be possible) ? May 14 20:42:12 rkirti: well... why do you think it is that important to find out how bitbake schedules the tasks? May 14 20:42:57 rkirti: You don't need to fix bitbake, you are supposed to 'feed' it :) May 14 20:45:23 florian: umm..I need the order of the packages at the lower level (kernel, base libs etc) to know what I am supposed to work on...this is ofcourse for a later time, when I am looking at the full maemo-image and that will be after I have ported the stack first ,but since I am anyways doing test builds right now, I thought I could record this data. May 14 20:46:25 * XorA thought freeze.inv was cool May 14 20:46:31 but I didnt see any emails about it May 14 20:47:32 kergoth sent something to the dev list May 14 20:47:35 rkirti: Usually bitbake just does the right thing... the only thing you have to do is to know your dependencies and decide about a good packaging. May 14 20:49:13 yay I have .ubi files now :-) May 14 20:50:21 florian: "decide about a good packaging" as in ? Shouldn't I be using the fixed maemo format ? May 14 20:54:30 rkirti: not necessarily... the package format can be adjusted and you can do good or less good file selection. May 14 20:54:52 XorA: I have a hungry baby ;) May 14 20:55:13 florian: not a fair exchange Im afraid May 14 20:55:50 florian: ok. /me didnt know about this freedom. May 14 20:57:02 kergoth: I like freeze.inv -- gives us more options, and is easy to use. As I continue to think about it -- it will be nice for developing a feature as can still sync latest code, and yet not have full re-builds triggered all the time May 14 20:59:12 XorA: :-) May 14 21:02:13 does bugspam get cc'd here? if anyone fancies reviewing bug 3014 i'd appreciate it May 14 21:02:23 Crofton|work: I havent seen any email, so it either never arrived or I got over eager with delete :-) May 14 21:02:44 heh May 14 21:04:32 about this freezing thing, I'm re-reading the emerge man May 14 21:04:51 I always use --update (-u) May 14 21:05:32 but this is not default! May 14 21:06:07 fwiw --update (-u) May 14 21:06:07 Updates packages to the best version available, which may not always be the highest version number due to masking for testing and development. This will also update direct dependencies which may not be what you want May 14 21:38:15 Whee, got current'ish .dev booting on my BB, on mmc May 14 21:39:21 and the built-in enet works on this crazy hub too, yay May 14 21:46:11 woowoo Im booting from ubifs :-) May 14 21:53:42 meh, so the sd card driver doesnt work :-( May 14 21:54:56 great yet another broken arm mmc driver May 14 22:00:13 03Angus Ainslie  07fso/milestone5.5 * rf668045aed 10openembedded.git/recipes/images/fso-paroli-image.bb: fso-paroli-image : add udev-static-devices to the image May 14 22:00:22 03Angus Ainslie  07fso/milestone5.5 * rc19d6e0c1e 10openembedded.git/recipes/udev/udev-static-devices.bb: udev-static-devices : add the real tar to RDEPENDS May 14 22:09:25 soo.. somewhat loaded question, but how safe is it to update? May 14 22:09:52 * kergoth thinks about using autoconf tracing to get a list of with/enable configure options, and compare against EXTRA_OECONF, and warn on missing options May 14 22:10:33 Soopaman, my fresh checkout as of yesterday evening (~24h ago) built clean May 14 22:10:40 and seems to run ok May 14 22:10:46 (fso/milestone5.5 branch) May 14 22:24:36 anyone hear of work to add a .bb for ftgl? May 14 23:20:48 03Jeremy Lainé  07xora/angstrom-srcpv * rb530076ad1 10openembedded.git/recipes/linux/linux-2.6.29/boc01/defconfig: linux-2.6.29: reduce boc01 kernel size May 14 23:20:48 03Sergey Lapin  07xora/angstrom-srcpv * rd02457b03a 10openembedded.git/recipes/dvd+rw-tools/ (9 files in 2 dirs): dvd+rw-tools: Added new recipe May 14 23:20:48 03Sergey Lapin  07xora/angstrom-srcpv * rcfbb95b3bb 10openembedded.git/: Merge branch 'org.openembedded.dev' of git@git.openembedded.net:openembedded into afeb9260-tmp May 14 23:20:50 03Sergey Lapin  07xora/angstrom-srcpv * r3fd24860b7 10openembedded.git/recipes/u-boot/ (u-boot-git/afeb9260/AFEB9260-network-fix.patch u-boot_git.bb): u-boot_git: updated for latest version for afeb9260 May 14 23:20:53 03Sergey Lapin  07xora/angstrom-srcpv * r5abc720bf3 10openembedded.git/conf/machine/ (afeb9260-180.conf afeb9260.conf include/afeb9260.inc): May 14 23:21:11 AFEB9260: add 180MHz config, split machine conf May 14 23:21:11 I really do this just because I need to support 2 board variants May 14 23:21:11 180 MHz and default 166MHz. Each one needs different May 14 23:21:11 setup for at91bootstrap and (probably) u-boot. May 14 23:21:11 03Sergey Lapin  07xora/angstrom-srcpv * r84feccc2c5 10openembedded.git/recipes/linux/ (5 files in 2 dirs): linux: added 2.6.30-rc4 May 14 23:21:13 03Sergey Lapin  07xora/angstrom-srcpv * r215a464bbd 10openembedded.git/recipes/linux/linux_2.6.28-rc6.bb: AFEB9260 is not supported with 2.6.28-rc6 kernel anymore May 14 23:21:18 03Theodore A. Roth  07xora/angstrom-srcpv * r86999e9433 10openembedded.git/recipes/evtest/evtest_1.23.bb: May 14 23:21:21 evtest: Fixed GNU_HASH QA error. May 14 23:21:23 Signed-off-by: Theodore A. Roth May 14 23:21:25 Acked-by: Denys Dmytriyenko May 14 23:21:41 03Chris Larson  07xora/angstrom-srcpv * rc0622e65a9 10openembedded.git/classes/ (4 files): May 14 23:21:41 First pass of cleanup of messages outputted to the user. May 14 23:21:41 OpenEmbedded outputs a lot of messages that the user is likely to never May 14 23:21:41 care about. We should only output something when it reflects upon their May 14 23:21:43 recipe (i.e. unpacking their sources, applying their patches), or is quite May 14 23:21:45 significant or unusual. May 14 23:21:47 Signed-off-by: Chris Larson May 14 23:21:49 03Chris Larson  07xora/angstrom-srcpv * r9699a955d4 10openembedded.git/classes/ (base.bbclass packaged-staging.bbclass patch.bbclass): May 14 23:21:52 * kergoth thinks our cia hooks shoiuld only notify about the merge commit itself, not all the commits it merged May 14 23:22:13 Shorten some full paths printed to the user. May 14 23:22:13 Adds a base_path_out convenience function, which prepares a full path for May 14 23:22:13 display to the user. The initial implementation just makes it relative to May 14 23:22:13 (14 lines omitted) May 14 23:31:01 whats the scoop on x servers nowadays, is xserver-xorg-kdrive just the xorg sources built with --enable-kdrive? May 14 23:31:08 * kergoth 's out of the loop May 15 01:51:05 kergoth: are you still here? May 15 01:55:23 kergoth: anyway, I tried your freeze patch and versions.conf works from conf directory, but not from the temp... May 15 02:29:38 denix0: well, it's including the one in tmp. look for yourself. May 15 02:29:51 denix0: run with -D -D to confirm May 15 02:36:58 I know it's including it, but it doesn't seem to work for me :) May 15 02:37:21 let me enable some debug messages May 15 02:38:00 ah, I see the problem May 15 02:38:34 wrong TMPDIR May 15 02:38:48 it doesn't honor my local.conf May 15 02:39:50 as you include freeze.inc and versions.conf before local.conf May 15 02:47:11 denix0: ahh, damn, i wonder how best to work around taht.. most things are lazy in bitbake, but inclusion happens right then and there May 15 02:47:23 denix0: i'll give it some thought, let me know if you come up with anything :) May 15 02:48:15 would it work if freeze.inc gets included after local.conf? May 15 02:48:41 yes, but then local.conf wouldn't be able to override the versions.conf preferences May 15 02:48:47 i guess we could switch it to ?= for its prefs May 15 02:49:10 ah, then if you have PREFERRED_VERSION there it wouldn't work... May 15 02:49:14 right May 15 02:49:42 actually, we could just move the include of the versions.conf files out of the freeze.inc directly into bitbake.conf May 15 02:49:53 although.. hrmph May 15 02:49:55 what a pain :P May 15 02:49:59 * kergoth thinks May 15 02:50:35 guess versions.conf loading after local.conf but before the distro, and using ?= would probably be best May 15 02:51:01 denix0: can you try moving freeze.inc below local.conf, and change the two freezeline vars to use ?=? May 15 02:51:16 denix0: (note: you'd probably have to use \?= in the regex :) May 15 02:51:31 * kergoth doesn't have a build setup in front of him, at home in bed atm :) May 15 02:51:32 freeze.inc already before local.conf May 15 02:51:53 right, I'm saying try omving it after (below, in the file, not before), and use ?= May 15 02:52:17 ah, too tired - read below as before :) May 15 02:52:20 hehe May 15 02:56:57 * kergoth wonders if you could use bb.parse to do a lazy include/require that happens at the end of the recipe parse, from an anonymous python function May 15 02:59:22 ah, if someone would enhance bitbake for multi-threaded cache rebuild... **** ENDING LOGGING AT Fri May 15 02:59:58 2009