**** BEGIN LOGGING AT Wed Jun 09 02:59:57 2010 Jun 09 05:39:54 hi all, Jun 09 05:40:20 can you fix db_5.0.21.bb ? Jun 09 05:40:33 all downloads links are broken Jun 09 05:41:22 03Khem Raj  07org.openembedded.dev * r803bf45d6d 10openembedded.git/recipes/gcc/gcc-cross_4.5.bb: Jun 09 05:41:22 gcc-cross_4.5.bb: Add libelf-native to DEPENDS Jun 09 05:41:22 * libelf is needed for LTO Jun 09 05:41:22 Signed-off-by: Khem Raj Jun 09 05:41:32 03Khem Raj  07org.openembedded.dev * r73145d4831 10openembedded.git/recipes/libelf/libelf_0.8.13.bb: Jun 09 05:41:32 libelf_0.8.13.bb: Provide libelf-native using BBCLASSEXTEND. Jun 09 05:41:32 Signed-off-by: Khem Raj Jun 09 06:15:25 Hi, Nikunj here from Bangalore, INDIA. Can someone tell me how to build rootfs using OE with ANGSTROM Distro and OMAP5912OSK Machine.?? Jun 09 06:16:20 Nikunj, have you tried reading the very fine documentation instead of having the instructions spoon fed to you by another person? Jun 09 06:18:07 yup.. I saw openembedded.org already . Nothings working out. I have built "helloworld" package succesfully. rootfs is required now. Jun 09 06:18:35 If you have any useful link kindly do share with me. Jun 09 06:19:21 Nikunj, http://wiki.openembedded.net/index.php/Getting_started Jun 09 06:19:43 http://docs.openembedded.org/usermanual/usermanual.html Jun 09 06:24:15 angstrom also has it's own tutorial here http://www.angstrom-distribution.org/building-angstrom Jun 09 06:25:01 grg, It doesnot show how to build a root file system for the distro I am using. already checked both of'em. "rootfs" folder isnt getting created alonwith "work", "deploy" etc., further "images" directory doesnot exist under tmp/build. Jun 09 06:27:02 Nikunj, http://docs.openembedded.org/usermanual/usermanual.html#id415073 Jun 09 06:28:10 grg, doesit mean , rootfs doesnot gets created alongwith command "$ bitbake helloworld" ? Jun 09 06:28:56 no. that just creates the helloworld package Jun 09 06:30:00 Cool, cleared a major doubt. ! Jun 09 06:30:55 grg, Thanks a Ton.! Jun 09 06:42:46 03Vladimir Sorokin  07org.openembedded.dev * re4d74a2f94 10openembedded.git/recipes/ipset/ (files/Makefile.patch ipset.inc ipset_4.2.bb): (log message trimmed) Jun 09 06:42:46 ipset: Initial commit Jun 09 06:42:46 If you want to Jun 09 06:42:46 * store multiple IP addresses or port numbers and match against the collection Jun 09 06:42:46 by iptables at one swoop; Jun 09 06:42:46 * dynamically update iptables rules against IP addresses or ports without Jun 09 06:42:47 performance penalty; Jun 09 06:54:17 good morning Jun 09 07:02:35 hi Jun 09 07:11:26 hi Jun 09 07:15:01 03Vladimir Sorokin  07org.openembedded.dev * r5f0fe8217c 10openembedded.git/recipes/flex/flex_2.5.35.bb: Jun 09 07:15:01 flex-2.5.35: create lex and flex++ symlinks Jun 09 07:15:01 Were missing in this version, which for example lead to build failures Jun 09 07:15:01 for packages depending on flex-native. Jun 09 07:15:01 Signed-off-by: Vladimir Sorokin Jun 09 07:15:02 Signed-off-by: Roman I Khimov Jun 09 07:15:13 03Roman I Khimov  07org.openembedded.dev * rb96ee9edc8 10openembedded.git/recipes/flex/ (flex.inc flex_2.5.31.bb flex_2.5.35.bb): Jun 09 07:15:13 flex: convert to INC_PR Jun 09 07:15:13 Signed-off-by: Roman I Khimov Jun 09 07:18:04 03Roman I Khimov  07org.openembedded.dev * r6486ab8a0f 10openembedded.git/recipes/dropbear/ (4 files): Jun 09 07:18:04 dropbear: switch to INC_PR Jun 09 07:18:04 Signed-off-by: Roman I Khimov Jun 09 07:18:06 03Roman I Khimov  07org.openembedded.dev * r44f496d37d 10openembedded.git/recipes/dropbear/ (dropbear.inc dropbear/init): Jun 09 07:18:06 dropbear: support comma-separated list of addresses in port spec Jun 09 07:18:06 Signed-off-by: Roman I Khimov Jun 09 07:21:34 03Vladimir Sorokin  07org.openembedded.dev * ra933f26993 10openembedded.git/recipes/perl/libtree-simple-perl_1.18.bb: Jun 09 07:21:34 libtree-simple-perl: Initial commit Jun 09 07:21:34 A simple tree object in Perl. Jun 09 07:21:34 Signed-off-by: Vladimir Sorokin Jun 09 07:21:34 Signed-off-by: Roman I Khimov Jun 09 07:44:55 03Martin Jansa  07org.openembedded.dev * r0005d44efd 10openembedded.git/recipes/navit/navit_svn.bb: Jun 09 07:44:55 navit: bump PR after libgps naming fix Jun 09 07:44:55 Signed-off-by: Martin Jansa Jun 09 07:47:24 morning Jun 09 07:48:13 hi hrw Jun 09 07:48:16 good morning Jun 09 07:49:46 gettext-native-0.18-r1 build fails, is it normal? http://pastebin.com/rzT8Nb2b Jun 09 07:50:30 khem: with newer target gcc, I've moved only a bit further :/ collect2: COLLECT_LTO_WRAPPER must be set. Jun 09 07:51:09 JaMa: 4.5.0? Jun 09 07:51:42 hrw: yes Jun 09 07:52:21 opkg files gcc | grep lto -> no lto-wrapper Jun 09 07:53:45 hrw: FYI: this is only on target when building with -flto Jun 09 07:54:31 hrw: khem said lto it's not ready for prime time, but wanted me to rerun benchmarks with -flto.. Jun 09 07:54:42 khem: maybe you know gettext better than others Jun 09 07:55:56 mckoan: which autoconf version do you have? Jun 09 07:56:03 mckoan: it worked fine with 2.65 Jun 09 07:56:40 JaMa: Debian lenny's autoconf (GNU Autoconf) 2.61 Jun 09 07:56:52 mckoan: and automake-native 1.11 Jun 09 07:57:10 everything worked ontil a few weeks ago Jun 09 07:57:43 I can't change the distro packages Jun 09 07:58:00 OE should work with Debian too Jun 09 07:58:28 mckoan: http://thread.gmane.org/gmane.comp.handhelds.openembedded/33147/focus=33220 Jun 09 07:58:50 mckoan: not host version, but -native in OE.. Jun 09 07:59:07 PREFERRED_VERSION_autoconf = "2.65" Jun 09 07:59:22 and automake-native? Jun 09 07:59:40 PREFERRED_VERSION_automake-native = "1.10.3" Jun 09 07:59:53 switching to the newer Jun 09 07:59:57 thx Jun 09 08:00:04 yw Jun 09 09:06:00 khem: NOTE: /usr/libexec/gcc/arm-angstrom-linux-gnueabi/4.5.1/lto-wrapper is not packaged Jun 09 09:10:56 ping hrw Jun 09 09:11:21 ~seen hrw Jun 09 09:11:24 hrw is currently on #maemo #oe. Has said a total of 13 messages. Is idling for 1h 20m 15s, last said: 'JaMa: 4.5.0?'. Jun 09 09:12:10 hi woglinde Jun 09 09:12:22 hrw could you do me a fovour Jun 09 09:12:27 uos favour Jun 09 09:12:36 woglinde: what I have to do? Jun 09 09:12:45 could build me navit for the bug 1.0? Jun 09 09:12:53 the recipe is in oe.dev Jun 09 09:13:07 woglinde: I do not have trees for OE builds Jun 09 09:13:24 yeah you have to copy the recipe over Jun 09 09:13:31 woglinde: so it would take me few hours to do build Jun 09 09:13:42 and see if it works out of the box Jun 09 09:14:00 I have latest rootfs running Jun 09 09:14:13 I tried with sdk to build navit Jun 09 09:14:21 but wasnt sucessful Jun 09 09:14:39 woglinde: catch jconnolly maybe Jun 09 09:14:46 hm Jun 09 09:14:51 he sleeps now I think Jun 09 09:14:55 yes Jun 09 09:14:56 okay thanks anymway Jun 09 09:15:08 woglinde: will you be on LT on friday? Jun 09 09:15:17 unfornatly no Jun 09 09:15:21 ok Jun 09 09:15:24 ~seen florian Jun 09 09:15:25 florian <~fuchs@Maemo/community/contributor/florian> was last seen on IRC in channel #edev, 1d 13h 21m 13s ago, saying: 'hi chouimat'. Jun 09 09:15:34 kindergarden has free and I have to nurse toby Jun 09 09:16:37 ok Jun 09 09:16:46 jo flroian Jun 09 09:16:59 I am at the navit booth this year Jun 09 09:17:42 strange that the touchscrenen on bug not works when the accel sensor is connected Jun 09 09:18:38 woglinde: strange indeed Jun 09 09:18:57 flo_lap: how goes LT? Jun 09 09:25:01 woglinde: hi Jun 09 09:31:05 NOTE: package neon-0.25.5-r4: task do_qa_configure: Started Jun 09 09:31:07 FATAL: This autoconf log indicates errors, it looked at host includes. Jun 09 09:44:21 JaMa: about Gentoo, binutils-2.20.1-r1 is now stable, still toolchain-binutils.eclass is unchanged Jun 09 09:45:24 ant_work: yes, I didn't report it on gentoo bugzilla, waiting for you to confirm you have same issue :) Jun 09 09:46:00 ant_work: because I'm also using gcc-4.5 on my host and maybe my bug will be considered as less supported configuration Jun 09 09:46:55 I got ar: can't set BFD default target to `i686-pc-linux-gnu': Invalid bfd target without using gcc-4.5 Jun 09 09:47:44 Don't know if we should reopen http://bugs.gentoo.org/298571 Jun 09 09:51:48 ant_work: not sure if "stabilize" bug is right place for it, as for me it works only with that development snapshot :) Jun 09 09:53:18 is there a way to bitbake a native package with bitbake -b if BBCLASASEXTEND="antive" is there ? (as there iis no xx-=native.bb file any more ) Jun 09 09:53:21 well, we have to trust khem: our builds are exposing an hidden issue Jun 09 09:53:56 eFfeM: with bitbake-1.10 or master just prefix -b path with virtual:native:some_path Jun 09 09:54:35 ah, ok guess that is a good reason to go to 1.10 (actually was hoping that there would be a 1.10 tarball at some point in time Jun 09 10:10:49 ant_work: do you have x86 or amd64 gentoo? Jun 09 10:10:59 x86 Jun 09 10:11:04 thx Jun 09 10:31:00 ant_work, khem: http://bugs.gentoo.org/show_bug.cgi?id=323319 Jun 09 12:33:14 /win13 Jun 09 12:44:16 woglinde: did you add lldb to OE yet? Jun 09 13:00:08 zecke: how do you say "eject a CD" in german? Jun 09 13:00:24 ausholen Jun 09 13:00:25 ? Jun 09 13:00:37 ant_work: that just sounds rude :-) Jun 09 13:00:54 Auswerfen Jun 09 13:01:04 * ant_work is on the phone with a supplier just incapable of transfering EDI orders :/ Jun 09 13:01:13 srry :/ Jun 09 13:01:44 you nasty German with your EDI dialects ... Jun 09 13:02:33 and the open source parsers usxxx Jun 09 13:03:51 mickeyl: I owe you a beer Jun 09 13:04:29 :) Jun 09 13:17:03 mickeyl: good afternoon Jun 09 13:17:39 good afternoon pb Jun 09 13:24:01 our building work has commenced this week, all very exciting. Jun 09 13:44:03 grabbed another bug Jun 09 13:44:06 ERROR: Build of /home/koan/devel/openembedded/recipes/qt4/qt4-x11-free_4.6.2.bb do_install failed Jun 09 13:44:18 | mv: `/home/koan/devel/build/kaeilos/tmp/work/armv5te-oe-linux-gnueabi/qt4-x11-free-4.6.2-r17.2/image/usr/bin/qtdemo' and `/home/koan/devel/build/kaeilos/tmp/work/armv5te-oe-linux-gnueabi/qt4-x11-free-4.6.2-r17.2/image/usr/bin/qtdemo' are the same file Jun 09 13:44:52 looks like the Append an E to the qtdemo file han not been tested with qt/X11 Jun 09 13:51:46 03Martin Jansa  07org.openembedded.dev * r23619bee5f 10openembedded.git/recipes/efl1/elementary_svn.bb: Jun 09 13:51:46 elementary: try to fix upgrade path from older -themes and -configs subpackage Jun 09 13:51:46 Signed-off-by: Martin Jansa Jun 09 13:51:53 03Martin Jansa  07org.openembedded.dev * rfddbd9804e 10openembedded.git/recipes/qt4/ (2 files in 2 dirs): Jun 09 13:51:53 qt-4.7.0-beta1: build fix for demos/browser Jun 09 13:51:53 * to fix it properly someone should package libQtMediaServices (now it's built but not packaged) Jun 09 13:51:53 and results to NOTE: Couldn't find shared library provider for libQtMediaServices.so.4 Jun 09 13:51:53 * so demos/browser won't probably work on target as it's now Jun 09 13:51:53 Signed-off-by: Martin Jansa Jun 09 13:55:43 03Khem Raj  07org.openembedded.dev * r03f5456ed0 10openembedded.git/recipes/gcc/gcc_4.5.bb: Jun 09 13:55:43 gcc_4.5.bb: Add lto to gcc package. Jun 09 13:55:43 Signed-off-by: Khem Raj Jun 09 13:56:38 patched recipes/qt4/qt-4.6.2.inc, and sent an email to ML to RFC it Jun 09 13:57:32 denix: what about it? Jun 09 13:58:14 eFfeM: you can build a virtual native package like this bitbake -b virtual:native: gm all Jun 09 13:58:39 hi khem Jun 09 13:58:48 mckoan: hello Jun 09 13:59:46 khem: thx.. building benchmark with -flto now Jun 09 14:00:14 JaMa: you have to sort of repackage target gcc Jun 09 14:00:47 JaMa: one fine day all packages could be built with -flto Jun 09 14:01:13 khem: I already did.. Jun 09 14:01:21 khem: before you pushed it :) Jun 09 14:01:38 OE gcc recipes are hard to follow ;( Jun 09 14:01:52 JaMa: you can also improve it a bit by adding -fwhole-program at link step Jun 09 14:02:24 hrw: they can be simplified but the problem is complex Jun 09 14:02:58 we churn out so many types of gcc ( cross native sdk target) and so many versions (3.x to 4.5) Jun 09 14:03:26 hrw: I always think of improvements. Jun 09 14:03:51 hrw: one thing I am working on is to separate our runtime library builds Jun 09 14:04:28 khem: one step would be to drop x.y.z releases where z < latest (unless needed by some strange ports) Jun 09 14:04:33 that way we can have the tools and runtime libraries in separate recipes Jun 09 14:04:47 hrw: thats already done for gcc 4.5 Jun 09 14:05:05 hrw: unfortunately I cant do it for older releases Jun 09 14:05:12 as people have tied versions Jun 09 14:06:14 khem: gcc-x.y.z.inc cleanups (common code) Jun 09 14:06:28 hrw: thats hairy part Jun 09 14:06:36 yep Jun 09 14:06:47 if I change one line I have build all gcc to make sure it does nt have any fallouts Jun 09 14:07:30 which suxx Jun 09 14:07:35 yes Jun 09 14:07:42 and I have a slow machine :) Jun 09 14:08:12 I wonder if we can switch gcc 4.4 also to drop the minor releae Jun 09 14:08:15 release Jun 09 14:09:04 JaMa: so try with -flto and then with -flto -fwhole-program link steps and see if it makes any difference Jun 09 14:09:10 182 files in recipes/gcc/ Jun 09 14:09:18 but cant get idea how to improve it Jun 09 14:10:13 once we are able to separate out runtime library builds things will ease out Jun 09 14:10:38 another think that would help is if we could reuse build trees Jun 09 14:11:03 then we wont have to build gcc bootstrap separately Jun 09 14:11:23 we can go into same build tree and resume build where we left Jun 09 14:11:34 its more like gcc is unified src build approach Jun 09 14:11:44 s/gcc is/gcc's/ Jun 09 14:13:31 npviewer.in takes 5% of cpu hmmm Jun 09 14:14:39 Hi. What was the latest glibc version to be added to OE before the new staging style? Jun 09 14:15:37 2.9? Jun 09 14:20:15 khem, thanks, didn't try it yet, got sidetracked in something else, but will try later Jun 09 14:29:59 mario-goulart: only eglibc 2.12 has been added post new stagign Jun 09 14:30:15 mario-goulart: glibc versions were all there before too Jun 09 14:31:12 khem: were all glibc versions adapted to the new staging style? Jun 09 14:31:23 mario-goulart: I hope so Jun 09 14:31:31 mario-goulart: do u see any issues ? Jun 09 14:32:42 khem: no, not at all. The case is that we are using the old staging style here, but we need to upgrade to a newer glibc version. The version we want is on the dev branch. Jun 09 14:33:15 mario-goulart: then use eglibc Jun 09 14:33:24 I am sure that have new staging Jun 09 14:34:02 khem: Hmmm. I think that'd be a too radical move. Jun 09 14:34:29 mario-goulart: try an experiment and you will be surprised how easy it is Jun 09 14:34:43 afterall eglibc is glibc+some fixes Jun 09 14:34:55 I was thinking about cherry-picking the latest glibc version before the move to the new staging style. Jun 09 14:35:01 ping mickeyl Jun 09 14:35:41 mario-goulart: ah when then you have your answers choose whichever youwant Jun 09 14:37:01 pb_, could you please sed -i -e s/absolsute/absolute/ lib/bb/parse/parse_py/BBHandler.py Jun 09 14:37:21 khem: alright. Thanks. Jun 09 14:38:08 blindvt_: I'm not sure that I have write access to the bitbake repository at the moment (and in fact I'm not even quite sure where it is). you'd probably do better asking kergoth or RP for that. Jun 09 14:38:54 pb_: his problem got sorted out Jun 09 14:39:11 pb_: how is house construction going on Jun 09 14:41:35 GNUtoo|laptop: pong Jun 09 14:43:02 03Marco Cavallini  07org.openembedded.dev * r05592a8274 10openembedded.git/recipes/qt4/qt-4.6.2.inc: Jun 09 14:43:02 qt-4.6.2.inc: solved a bug when trying to append an empty string to the qtdemo file when building Qt/X11 (QT != Qt/E) Jun 09 14:43:02 * Now checking if [ -n ${QT_LIBINFIX} ] before mv qtdemo Jun 09 14:43:13 03Marco Cavallini  07org.openembedded.dev * rabb60bbc40 10openembedded.git/conf/distro/include/kaeilos-2009-preferred-versions.inc: kaeilos-2009-preferred-versions.inc: some distro version updates and mainly automake-native 1.11 Jun 09 14:44:29 pb_, sorry, i ment in fact RP :( Jun 09 14:44:44 RP, could you please sed -i -e s/absolsute/absolute/ lib/bb/parse/parse_py/BBHandler.py Jun 09 14:44:48 heh, righto Jun 09 15:27:40 hey all Jun 09 15:29:17 g'day kergoth Jun 09 15:30:45 hey pb_ Jun 09 15:36:00 man.. i'm starting to regret ever starting this variabler reference tracking code Jun 09 15:36:50 Ha Jun 09 15:37:31 the most annoying bit is the failure mode -- it's difficult to identify when a reference occurred that wasn't tracked, at least for all the code that isn't subject to static analysis, which means events, the methodpool, and everything in the bb and oe python packages Jun 09 15:38:39 exported vars are annoying as well, unless i start trying to track references to shell variables.. either all exported vars are included for every shell value, or we figure out which of the exported vars is utilized, but thats a danger too, since some things are exported for child processes Jun 09 15:39:26 what it comes down to, for shell at least, is that I think we need to 1) audit our exported variables, and 2) distinguish between *emitted* into the shell script and *exported* from the shell script -- the former is usable only as shell variables in the tasks, the latter for ./configure, etc Jun 09 15:39:32 * kergoth ponders Jun 09 15:41:41 Aside: bitbake -e needs a way to show me flags Jun 09 15:41:55 i need to know the final contents of a variable flag Jun 09 15:42:37 Tartarus: its just a can of worms.. or more likely, a nested set of cans of worms Jun 09 15:42:49 hehe Jun 09 15:43:16 its to the point that it could be used, but the failure mode still worries me Jun 09 15:46:25 greetings! I'm trying to build a toolchain with 'bitbake meta-toolchain', but tmp/staging/armv7a-angstrom-linux-gnueabi/usr/lib/libboost_* doesn't end up in the tarball, do I need to explicitly add boost somehow? Jun 09 15:47:30 hmm Jun 09 15:47:33 i wonder Jun 09 15:48:09 what if i introduced a filter -- references to a variable that isn't encompassed by the signature (or is blackedlisted) during a task execution raises an exception Jun 09 15:48:16 I'm not sure if it matters, but I'm using the boost 1.33.1 recipe since newer ones don't seem to have serialization Jun 09 15:48:29 s/blacked/black/ Jun 09 15:49:33 oneshel: take a look at openembedded/recipes/meta/meta-toolchain.bb Jun 09 15:50:07 hmmmmm Jun 09 15:50:13 maybe its time i started integrating this into bitbake Jun 09 15:50:14 kergoth: yep I've been digging through there, trying to understand it, I'll keep looking, thanks Jun 09 15:50:18 that'd make it easier to introduce a filter Jun 09 15:50:35 oneshel: specifically, look at TOOLCHAIN_HOST_TASK and TOOLCHAIN_TARGET_TASK Jun 09 15:50:45 those are vars holding the packages installed Jun 09 15:50:50 hi all Jun 09 15:50:54 defaulting to task-sdk-host and task-sdk-bare, respectively Jun 09 15:50:56 kergoth: ok great, thanks again! Jun 09 15:50:58 np Jun 09 15:51:05 talking about meta-tolchain, does anyone could help me on that topic http://www.mail-archive.com/openembedded-devel@lists.openembedded.org/msg06096.html Jun 09 15:51:08 please ? Jun 09 15:57:30 heh, that person could be a tad more patient Jun 09 15:57:36 ask a question, leave two minutes later? Jun 09 16:02:23 hrm Jun 09 16:02:46 maybe.. hmm Jun 09 16:04:08 if i could get bitbake to generate a signature for the task its about to execute, then *in the worker process* for that task, set a global flag to instruct getVar to raise an exception if any requested variable isn't in that flag Jun 09 16:04:29 kergoth, may i push this to bb master? sed -i -e s/absolsute/absolute/ lib/bb/parse/parse_py/BBHandler.py Jun 09 16:04:43 go for it, typo fixes are a no brainer :) Jun 09 16:04:49 kergoth, thanks Jun 09 16:05:19 found one in oe yesterday that could actually affect code, though i'm not entirely sure in what way :| Jun 09 16:05:34 s/PSTAGE_TMDPDIR_STAGE/PSTAGE_TMPDIR_STAGE/ in packaged-staging.bbclass Jun 09 16:05:40 kergoth, are all typos ok to push without asking? Jun 09 16:05:50 i'd say so, yeah. Jun 09 16:05:57 k Jun 09 16:06:11 absolute worst case something can be reverted, of course, but for cosmetic stuff that won't impact the user its awfully unlikely :) Jun 09 16:10:16 kergoth, btw.. I was thinking if it would be acceptable to implement BBHandle.py (for example, didn't profile it yet) in C or C++? Or is this against established rules/taste ? Just curious for now, didn't write a single line nor look yet Jun 09 16:16:34 blindvt: i'd suggest doing some heavy profiling first. the actual parse isn't a huge part of the time spent, much is taken up executing anonymous python, etc Jun 09 16:16:48 we'd certainly be open to it, of course Jun 09 16:19:24 blindvt: might be easiest to do it with cython or something, rather than having to deal with the c api yourself :) Jun 09 16:19:45 but definitely profile before spending time on it Jun 09 16:20:20 kergoth, k. And another question: i was adjusting debug output like so: http://paste.debian.net/76764/ ; What i'm wondering now is that i'm still seeing like 8930 occurances of "Parsing: ...xyz.bb". Can't we store them in the DB and parse that instead of walking the filesystem (or is that done already and i'm just blind?) Jun 09 16:21:14 the initial cache only holds dependency information for construction of the runqueue Jun 09 16:21:21 the recipes are all -reparsed- when executing each task Jun 09 16:21:36 they werent in the past, in the past we kept shit in memory, but the ram usage was out of control Jun 09 16:21:53 iirc RP tried caching the whole things, but wasn't hugely beneficial Jun 09 16:22:09 he'd probably recall more details than i, i wasn't working on oe/bitbake for a 2-3 year period Jun 09 16:22:19 and this stuff went in at that time, iirc Jun 09 16:22:40 a coworker has a patch to cache the parsed recipes until all the tasks for that recipe are executed Jun 09 16:22:44 but it doesn't greatly affect build time Jun 09 16:22:55 which is why i mention profiling first, it won't necessarily improve it the way you think it will Jun 09 16:24:04 RP, do you remember if putting the .bb into the DB when priming the parser and consequently only "parsing" the cached entry from the DB was benefical, by chance? Jun 09 16:24:13 * blindvt nods kergoth Jun 09 16:24:53 i have some experimental alternative parsers floating around, one using pyparsing.. the code is much cleaner, but sadly it was actually slower Jun 09 16:25:00 :) Jun 09 16:25:41 definitely worth looking into this stuff though. anything we can do to improve performance, even just the appearance of it, is a good thing Jun 09 16:25:51 that initial parse time probably isn't hugely signifiant to a build, but it *feels* slow Jun 09 16:26:01 heh Jun 09 16:26:40 i'll get me some real data to see what could make sense. Still, touching every recipe more than once if it's mtime didn't change just _sounds_ wrong :) Jun 09 16:26:48 agreed Jun 09 16:27:20 one thing that would be good is to audit our anonymous python usage, shift things we can to ConfigParsed time, rather than recipe parsed, etc Jun 09 16:27:33 well, I dunno, the filesystem cache is pretty efficient. if you really do need the textual contents of the file repeatedly, I doubt you will see much benefit from caching it locally versus letting the kernel do that. Jun 09 16:27:35 since all anonymousp ython has to be re-run at the end of the parse of every recipe Jun 09 16:28:00 hmm, good point, didn't think about that.. but how large is that cache, and how long is it kept around? Jun 09 16:28:16 variable size (essentially all of "free" memory), and indefinitely Jun 09 16:28:23 ah Jun 09 16:28:31 the kernel will only start throwing cached data out if it thinks it can do something more useful with that ram Jun 09 16:28:39 maybe that explains why changing the behavior is of limited benefit, then Jun 09 16:28:39 kergoth, a bitbake micro-base-image; bitbake -c clean gcc;time bitbake -c clean gcc; should not spit out 25 seconds for the second clean invocation, but more like 1 or 2 Jun 09 16:28:51 admittedly it doesn't always get that choice right, but I suspect in this case its heuristics will do pretty much the right thing Jun 09 16:30:00 * kergoth really hopes we can change things so it can avoid reparsing recipes when config files change, that would really improve the perceived performance Jun 09 16:30:09 pb_, yes, but i don't want to benchmark dentry/inode caches but only do the work that is unavoidable, bitbake-wise :) Jun 09 16:30:19 kergoth: right, it sucks that touching local.conf means an instant coffee break Jun 09 16:33:51 sounds like we need better handling of dirty variables Jun 09 16:34:43 currently there's no tracking of what variables reference what other variables, so we can't flow through dirty state. that's what i'm working on Jun 09 16:34:58 uhuh that would be pretty involved. Not my call Jun 09 16:35:12 pretty involved is an understatement, my head hurts Jun 09 16:35:15 :) Jun 09 16:35:19 :) Jun 09 16:35:50 * blindvt leans back and watches kergoth doing real work Jun 09 16:35:56 its possible we could make better use of zecke's ast objects, re-exec them rather than reparsing and then re-execing them Jun 09 16:36:00 but i don't know much that would benefit us Jun 09 16:36:36 i'm stuck dealing with the variable ref stuff whether i want to or not, you're welcome to keep pounding in the parsing end of things :) Jun 09 16:37:12 blindvt: http://github.com/kergoth/OE-Signatures - would welcome any comments on the code, if you have a chance at some point Jun 09 16:39:44 kergoth: add there 'recover interactive mode' :) Jun 09 16:40:14 kergoth, we can store arbitrary python object in the DB, so storing the ast with a checksum/mtime there and using that should be an immediate improvement, i blindly guess. Parsing all recipes, regardless if off the DB or off the disk is unwarranted if nothing changed. Since we have the AST in the DB, we can selectively look if the .bb changed and only re-parse them if it's called for Jun 09 16:40:17 heh, open a bug in the bts, that has nothing to do with this, its an independent issue Jun 09 16:40:36 blindvt: would certainly be worth trying, and probably not terribly difficult to pull off Jun 09 16:40:49 hell, a first pass could be really lazy and use a python shelf :) Jun 09 16:40:59 but i'm most likely talking BS out of thin air. Let's get back to doing something ;) Jun 09 16:41:05 * kergoth nods Jun 09 16:42:59 * blindvt goes to prepare a mail or two to khem Jun 09 17:01:02 * kergoth <3 pyprof2calltree Jun 09 17:02:39 kernprof.py nosetests; pyprof2calltree -i nosetests.prof -k -> browse in kcachegrind Jun 09 17:12:40 khem, ok. I'm open to discussion, but at least IMHO it's better than what was there before. Jun 09 17:13:19 and i'd be grateful for any and all input on the "feature/dep picking heuristics" plea for comments/advises :) Jun 09 17:21:04 blindvt: ok Jun 09 17:21:26 blindvt: 'ipv6' is a DISTRO_FEATURES item today Jun 09 17:21:41 er, maybe its combined features, actually Jun 09 17:21:42 khem, and please test that stuff before you push it. I only did compile tests against qemux86 Jun 09 17:21:45 * kergoth looks Jun 09 17:23:14 kergoth, is this observation correct? Jun 09 17:23:15 +# X, Y = ${@features_to_uclibc_settings(d)} Jun 09 17:23:15 +# unfortunately doesn't seem to work with bitbake, workaround: Jun 09 17:23:41 you can't define multiple variables in a single assignment in a recipe Jun 09 17:23:44 blindvt: thx for heads up but I have bitten before so I will make sure :0 Jun 09 17:23:47 perhaps i should have returned a set instead Jun 09 17:23:48 not supported by our file format Jun 09 17:24:00 * blindvt nods kergoth Jun 09 17:24:10 should likely use an anonymous python function or ConfigParsed event handler if it doesn't require reciep specifics Jun 09 17:24:26 k, np. Would have been fancy but it's not important Jun 09 17:24:52 blindvt: right now I am trying to debug why shadow/login does not work with uclibc Jun 09 17:25:21 once I finish that I will set up a regular automatic testing of uclibc/nptl on arm/mips/ppc Jun 09 17:25:38 so you can add them to supported list in 1.0 release Jun 09 17:26:54 hmmm it seems JaMa|Sports is practicing for the World cup opener :) Jun 09 17:27:45 khem, i want to put oe conf's into downloads so people can easily build small image for their need. Jun 09 17:28:48 i think rob's badly-written-shell-script-to-build-an-outdated-setup thing is a really, really bad idea, so oe. Jun 09 17:29:48 oe conf ? Jun 09 17:30:11 you mean local.conf or the whole /conf dir Jun 09 17:30:16 I did not get it Jun 09 17:34:23 khem, just local.conf per arch+flavors Jun 09 17:34:40 ah Jun 09 17:34:45 khem, KISS Jun 09 17:36:57 khem, shadow and bb login worked fine last time i tried. What do you see? But let's move that bit into #uclibc i'd say Jun 09 17:39:07 blindvt: no its very much OE interest too because thats what I am using Jun 09 17:39:34 blindvt: its not using busybox login but shadow's login Jun 09 17:40:04 03Koen Kooi  07org.openembedded.dev * rc9214a4406 10openembedded.git/recipes/qt4/qt4.inc: qt4: first part of mediaservices packaging Jun 09 17:40:37 khem, i won't boot into something that it not officially upstream, so what about getting that configury stuff in first? ;P Jun 09 17:41:10 blindvt: heh well I may find a bug in uclibc Jun 09 17:41:31 blindvt: the git version renaming I will try right now Jun 09 17:41:33 heresy Jun 09 17:48:06 khem, once the configury is in i'll start to forward the virtualized coreutils for I don't want coreutils, not even for bootstrapping, and there's no technical reason to force them Jun 09 17:50:14 RP: Is bea72c2fecde175add169bb55df1922b048030c8 the commit which starts the migration to the new staging style? Jun 09 17:50:16 kergoth, what are you referring to with the anon python function or ConfigParsed event handler? Jun 09 17:51:18 03Tom Rini  07org.openembedded.dev * r9176b8adbf 10openembedded.git/recipes/gcc/gcc-csl-arm-2007q3.inc: Jun 09 17:51:19 gcc-csl-arm-2007q3: Switch to FILESPATHPKG Jun 09 17:51:19 Signed-off-by: Tom Rini Jun 09 17:51:29 03Tom Rini  07org.openembedded.dev * r8b7a068f7c 10openembedded.git/recipes/ncurses/ncurses.inc: Jun 09 17:51:29 ncurses{,-native,-sdk}: Drop unnecessary FILESPATH Jun 09 17:51:29 Signed-off-by: Tom Rini Jun 09 17:51:29 03Tom Rini  07org.openembedded.dev * rd428b64c30 10openembedded.git/recipes/bluez/ (bluez-utils3.inc bluez.inc): Jun 09 17:51:29 bluez: Switch to FILESPATHPKG Jun 09 17:51:29 Signed-off-by: Tom Rini Jun 09 17:51:30 03Tom Rini  07org.openembedded.dev * r0c7fd5d39f 10openembedded.git/recipes/php/php-native.inc: Jun 09 17:51:30 php-native: Drop unnecessary FILESPATH Jun 09 17:51:31 Signed-off-by: Tom Rini Jun 09 17:51:32 03Tom Rini  07org.openembedded.dev * rf11b2ef702 10openembedded.git/recipes/clutter/clutter-gtk.inc: Jun 09 17:51:33 clutter-gtk: Drop unnecessary FILESPATH Jun 09 17:51:33 Signed-off-by: Tom Rini Jun 09 17:51:34 03Tom Rini  07org.openembedded.dev * rea0f1b38ff 10openembedded.git/recipes/gtk+/gtk+-fastscaling_2.10.14.bb: Jun 09 17:51:34 gtk+-fastscaling: Switch to FILESPATHPKG Jun 09 17:51:35 Signed-off-by: Tom Rini Jun 09 17:51:35 03Tom Rini  07org.openembedded.dev * rccaab1f22e 10openembedded.git/recipes/dpkg/dpkg-native.inc: Jun 09 17:52:57 kergoth, oh, and could oe have global generic scripts for dummy functions? Consider do_setscene() {:} resp. the generated run.script. beating the disk by writing a gazillion of those identical dummies should be avoidable, isn't it Jun 09 17:55:57 kergoth, perhaps we could have something like "override do_configure" / "do_configure dummy" in oe that routes to one common 'dummy(){:}' script? Jun 09 17:58:06 kergoth, also, the whole common env setup stanza could live in a commonly sourced script Jun 09 18:00:57 you folks apparently have way too much resources at your disposal ;) Jun 09 18:09:03 blindvt: i have a patch *somewhere* which made bitbake not even bother executing a task if its value is empty Jun 09 18:09:15 didn't even show an 'executing task' messsage Jun 09 18:09:16 heh Jun 09 18:09:28 python () {} is an anonymosu python function, run at the end of hte parse for each recipe Jun 09 18:09:37 ConfigParsed is an event fired at the end of the bitbake.conf and INHERIT parse Jun 09 18:09:57 kergoth, you're the man. Where is that \"*somewhere*\" ? :) Jun 09 18:10:33 kergoth, yes, but were you referring to my patch? Should i have done something differently? Jun 09 18:12:05 kergoth, do you mean that i/libc/the system should resolve featureDeps at ConfigParsed? Jun 09 18:13:48 kergoth, thing is that in my POV eligible providers should take the available features into account: If there's no ipv4, then sysvinit (due to it using inet_*()) is just not buildable and not an option as runlevel provider (or however it's called) Jun 09 18:14:06 haven't looked at the patches closely, was referring to your "X, Y = " .. when setting multiple variables programmatically, you generally want either an anonymous python function or configparsed Jun 09 18:14:12 you could do that. Jun 09 18:14:27 anonymous python, check for missing feature, raise SkipPackage() if it doesn't have what it needs Jun 09 18:15:17 that's the exception that underlies COMPATIBLE_MACHINE and COMPATIBLE_HOST Jun 09 18:16:16 so i'd put REQUIRED_FEARURE="ipv4" into sysvinit and (after handling REQUIRED_FEATURE in some class) be done. Sounds like a plan Jun 09 18:16:22 right Jun 09 18:16:28 see base.bbclass, search for COMPATIBLE Jun 09 18:16:29 i'd prefer a whitelist approach though. Less work Jun 09 18:17:28 HANDLED_FEATURES="whitespace separated list" || raise SkipPackage() Jun 09 18:18:02 damn,i have no idea where i put this commit that made it not run empty tasks Jun 09 18:18:09 too many branches in too many trees Jun 09 18:19:12 HANDLED_FEATURES can be automatically filled for autotool packages via configure.ac's arg handing. Would catch most of nls and !ipv6 at least Jun 09 18:19:44 kergoth, great idea, many thanks! Jun 09 18:19:59 np Jun 09 18:20:12 i have 9 personal topic branches in my github repo for bitbake Jun 09 18:20:17 and none of those have this damn commit Jun 09 18:20:24 hrmph Jun 09 18:21:01 oh yes and it would also catch --{dis,en}able-{shared,static} for autotools. Sweet! Jun 09 18:21:21 great thing Jun 09 18:21:49 in some of those cases you may want to raise smoething other than skippackage, since skippackage silently makes it not buildable.. some combinations may just be errors Jun 09 18:21:52 heh Jun 09 18:22:42 i need something to search the contents of git repositories, across my system Jun 09 18:22:46 both branch names and commit content Jun 09 18:22:52 i misplace shit i worked on way too often Jun 09 18:24:18 kergoth, gitk --all views through all branches, so there must be some way to cross-branch search for either a patch or a string (unless they iterate which would be unfair and not helpful) Jun 09 18:24:45 i'll likely script something Jun 09 18:24:56 could use locate or mr to find the repositories to consider, then git for-each-ref is my friend Jun 09 18:26:57 well, at least making bitbake not bother emitting a shell script, etc for an empty task is easy enough Jun 09 18:27:09 what i'd done was rather more complex since i didn't want to see it running the tasks at all Jun 09 18:27:16 which meant implementing a more useful version of the 'check' flag Jun 09 18:27:17 hi, can anyone point me in the right direction... I followed the Getting started guide, but I run into errors all the time... (output is here: http://pastebin.com/a7JWD4cL) Jun 09 18:27:20 and making the cooker use it Jun 09 18:28:06 knee: possibly a chrpath thing. try installing it on your host or baking chrpath-native, perhaps? Jun 09 18:28:12 * kergoth hasn't seen that himself Jun 09 18:28:55 kergoth: chrpath-native is unused Jun 09 18:30:06 ah Jun 09 18:32:03 re Jun 09 18:35:13 kergoth: thanks.. :) chrpath was the problem Jun 09 18:35:21 np Jun 09 18:36:07 kergoth, well my git-foo is pretty bad. For your amusement: http://www.mail-archive.com/uclibc@uclibc.org/msg04918.html Jun 09 18:38:05 jo Jun 09 18:38:20 woglinde, heya Jun 09 18:39:20 hi blindvt Jun 09 18:59:30 khem, so.. what do you think? Jun 09 19:11:23 JaMa|Sports, f1b326c83be0d95571b991d8d2ee239982380b6b Why was that needed given update-alternatives should handle this just fine? I suspect this is not the correct fix Jun 09 19:36:02 blindvt: u-a name was the same "run-parts" but the link was created once as /bin/run-parts and once as /usr/bin/run-parts Jun 09 19:36:35 blindvt: so you need unique u-a name.. and to create new u-a name for _same_ thing is bad idea. Jun 09 19:36:47 blindvt: that's what that error in commit message says Jun 09 19:44:39 hey JaMa what sports did you do ? Jun 09 19:45:40 khem: today gym+pool, yesterday football tenis and tomorrow bike trip :) Jun 09 19:45:48 JaMa: cool Jun 09 19:45:55 my bike arrived yesterday Jun 09 19:46:08 so far 20 miles already on it since last everning Jun 09 19:46:35 great, here is quite unreliable weather now :/ Jun 09 19:46:47 even here it is cloudy Jun 09 19:47:07 it rained a bit in the morning and I was worrried but then it dried up Jun 09 19:47:09 first few nice days only this week Jun 09 19:47:22 JaMa: cool where are you located ? Jun 09 19:47:26 and yesterday was worst rain I have seen in few years.. Jun 09 19:47:35 Prague Jun 09 19:47:40 ah nice place Jun 09 19:47:50 I had to bribe the police Jun 09 19:47:56 lol :) Jun 09 19:47:59 JaMa, thing is that debian-utils on my debian box lives in /bin as does the run-parts from busybox. So assuming that debianutils in oe is not using the wrong prefix (didn't look), the busybox recipe should have made sure to do a /bin/run-parts.busybox like for the other u-a bins of busybox Jun 09 19:48:02 otherwise they will give me a ticket Jun 09 19:49:37 blindvt: I moved it to same place as debian-utils from OE had (and someone IIRC hrw) also confirmed it's right way to move it Jun 09 19:49:48 khem: speed or alcohol? Jun 09 19:49:55 khem: or wrong parking? Jun 09 19:50:09 none . He just saw my german license plate Jun 09 19:50:15 and non german looks Jun 09 19:50:52 I drove out of the restaurant onto road and he said that I made a wrong turn :) Jun 09 19:50:57 I knew he needs money Jun 09 19:51:05 :-) Jun 09 19:51:37 03Vladimir Sorokin  07org.openembedded.dev * reb768a77fb 10openembedded.git/recipes/at/ (at-3.1.8/use-ldflags.patch at_3.1.8.bb): Jun 09 19:51:37 at: fix GNU hash QA error (force LDFLAGS) Jun 09 19:51:37 Signed-off-by: Vladimir Sorokin Jun 09 19:51:38 and two non germans trying to converse in german was fun Jun 09 19:51:49 yeah non german looking guys in german cars usually have enough money for poor police man :) Jun 09 19:52:32 khem: btw lto, whole is now running Jun 09 19:52:43 JaMa: cool Jun 09 19:52:49 any improvements Jun 09 19:53:11 JaMa: heh not me Jun 09 19:53:17 khem: I'll upload all 3 as soon it finishes (I haven't look on -flto results and now I want to keep device working.. :) Jun 09 19:53:28 sure Jun 09 19:54:04 03Vladimir Sorokin  07org.openembedded.dev * rc20fd61ff1 10openembedded.git/recipes/rp-pppoe/ (rp-pppoe-3.8/use-ldflags.patch rp-pppoe_3.8.bb): Jun 09 19:54:04 rp-pppoe: fix GNU hash QA error (force LDFLAGS) Jun 09 19:54:04 Signed-off-by: Vladimir Sorokin Jun 09 19:54:04 Signed-off-by: Roman I Khimov Jun 09 19:56:28 JaMa, that's pretty odd. How can i reproduce this? Jun 09 19:56:52 03Vladimir Sorokin  07org.openembedded.dev * r66d805ee07 10openembedded.git/recipes/perl/libxml-simple-perl_2.18.bb: Jun 09 19:56:52 libxml-simple-perl: add missing runtime dependency Jun 09 19:56:52 Signed-off-by: Vladimir Sorokin Jun 09 19:56:52 Signed-off-by: Roman I Khimov Jun 09 19:59:05 blindvt: what? your debianutils OE build doesn't install it to /usr/bin/run_parts? Jun 09 20:00:25 03Roman I Khimov  07org.openembedded.dev * r1ae5bb5c1d 10openembedded.git/recipes/perl/libio-compress-base-perl_2.015.bb: Jun 09 20:00:25 libio-compress-base-perl: remove useless FILES definition Jun 09 20:00:25 Already included by cpan-base. Jun 09 20:00:25 Signed-off-by: Roman I Khimov Jun 09 20:00:26 03Roman I Khimov  07org.openembedded.dev * r28db918bae 10openembedded.git/recipes/perl/libxml-simple-perl_2.18.bb: Jun 09 20:00:26 libxml-simple-perl: s/RDEPENDS/RDEPENDS_${PN}/ Jun 09 20:00:26 Sorry, slipped through. Jun 09 20:00:26 Signed-off-by: Roman I Khimov Jun 09 20:00:27 JaMa, let me retry with that patch backed out Jun 09 20:00:28 03Roman I Khimov  07org.openembedded.dev * r3708fbc078 10openembedded.git/recipes/perl/libcompress-zlib-perl_2.015.bb: Jun 09 20:00:28 libcompress-zlib-perl: add missing dependencies Jun 09 20:00:28 Signed-off-by: Roman I Khimov Jun 09 20:00:29 03Roman I Khimov  07org.openembedded.dev * r9a86032281 10openembedded.git/recipes/perl/libio-compress-zlib-perl_2.015.bb: Jun 09 20:00:29 libio-compress-zlib-perl: remove useless FILES Jun 09 20:01:46 03Roman I Khimov  07org.openembedded.dev * r68f4b0402c 10openembedded.git/recipes/perl/perl_5.10.1.bb: Jun 09 20:01:46 perl 5.10.1: fix sporadic "Use of uninitialized value $x in scalar assignment" Jun 09 20:01:46 See this for further details: Jun 09 20:01:46 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=480533 Jun 09 20:01:46 Signed-off-by: Roman I Khimov Jun 09 20:03:03 03Roman I Khimov  07org.openembedded.dev * r97721acc3b 10openembedded.git/recipes/procps/procps.inc: Jun 09 20:03:03 procps: handle pgrep through alternatives Jun 09 20:03:03 * pgrep can be provided by busybox Jun 09 20:03:03 * remove useless FILES definition along the way Jun 09 20:03:03 Signed-off-by: Roman I Khimov Jun 09 20:03:28 blindvt: odd, now checking on my gentoo box and debian box that both have debianutils /bin/run-parts Jun 09 20:03:59 JaMa, yea, that's why i said it's dubious and tend to NAK it Jun 09 20:04:39 03Roman I Khimov  07org.openembedded.dev * r3447260716 10openembedded.git/recipes/perl/ (perl-rdepends_5.10.1.inc perl_5.10.1.bb): Jun 09 20:04:39 perl 5.10.1: a bit more module runtime dependencies Jun 09 20:04:39 Signed-off-by: Roman I Khimov Jun 09 20:04:41 03Roman I Khimov  07org.openembedded.dev * rb29fca216e 10openembedded.git/recipes/perl/libmail-spf-perl_2.007.bb: Jun 09 20:04:41 libmail-spf-perl: add missing perl dependencies Jun 09 20:04:41 Signed-off-by: Roman I Khimov Jun 09 20:04:43 JaMa, still, i want to know how somebody tripped it Jun 09 20:06:15 JaMa, apart from that, debianutils-3.2.3 is out and the old ones should be ditched if that new one works out fine Jun 09 20:07:37 03Roman I Khimov  07org.openembedded.dev * r29faf9558e 10openembedded.git/recipes/spamassassin/spamassassin_3.3.1.bb: Jun 09 20:07:37 spamassassin: add prepackaged rules Jun 09 20:07:37 sa-update is preferred way to get rules with spamassassin 3.3.1, but then Jun 09 20:07:37 you have no rules at all out-of-the-box which is undesired in some situations. Jun 09 20:07:37 Pack default rules to spamassassin-rules. Jun 09 20:07:38 Signed-off-by: Roman I Khimov Jun 09 20:07:39 03Roman I Khimov  07org.openembedded.dev * r38f014bf1f 10openembedded.git/recipes/spamassassin/ (files/spamassassin.init spamassassin_3.3.1.bb): Jun 09 20:07:39 spamassassin: remove lsb bits from init script Jun 09 20:07:40 Signed-off-by: Roman I Khimov Jun 09 20:07:43 03Roman I Khimov  07org.openembedded.dev * r6147958955 10openembedded.git/recipes/spamassassin/spamassassin_3.3.1.bb: Jun 09 20:07:43 spamassassin: add missing perl dependencies Jun 09 20:07:43 Signed-off-by: Roman I Khimov Jun 09 20:07:44 03Roman I Khimov  07org.openembedded.dev * r217dac1304 10openembedded.git/recipes/perl/libio-zlib-perl_1.10.bb: Jun 09 20:07:44 libio-zlib-perl: add missing dependency Jun 09 20:07:44 Signed-off-by: Roman I Khimov Jun 09 20:09:20 blindvt: feel free to change it to /bin/run_parts Jun 09 20:09:31 ~lart jama for not splitting up navit Jun 09 20:09:31 * ibot judo chops jama for not splitting up navit Jun 09 20:09:43 JaMa, just rebuilt on a debian testing box with the file://run-parts.in.usr-bin.patch removed, micro-base-image. No hickup. NAK for that patch. See: tar -tvf tmp/deploy/images/qemux86/micro-micro-base-image-uclibc-ipk-*-qemux86.rootfs.tar | awk '{if($3){print}}' Jun 09 20:10:32 JaMa, yea, but i can't for i have no write privileges :P Jun 09 20:10:32 woglinde: graphics libs? Jun 09 20:10:39 sound too Jun 09 20:10:41 JaMa, please fix ;) Jun 09 20:10:46 blindvt: send patch, I'll apply Jun 09 20:10:47 NOTE: multiple providers are available for runtime evas-loader-png (evas-native, evas) Jun 09 20:10:55 darn Jun 09 20:11:18 woglinde: now with QML someone should split it :) Jun 09 20:11:37 jama and maptool Jun 09 20:11:42 dont need maptool on device Jun 09 20:11:46 woglinde: navit-icons was worst pain.. that's why I started with it.. Jun 09 20:12:11 jama yeah I will checkt in the svg patches for qtpainter as fast as I can Jun 09 20:12:20 than only svg is needed Jun 09 20:12:25 for qpainter Jun 09 20:12:46 gtk-draw would still require the png's Jun 09 20:12:48 woglinde: do you have some benchmarks for svg/png rendering on slow device? Jun 09 20:12:54 not yet Jun 09 20:13:14 dont have rellay slow devices Jun 09 20:13:17 beside simpad Jun 09 20:14:03 woglinde: I was discussing on #foss-gps about rendering vector data / png tiles.. for maps, but also no benchmark Jun 09 20:14:41 woglinde: but I think that highly optimized vector rendering could be faster than loading loads of png from slow uSD Jun 09 20:14:51 woglinde: from my POV freerunner is quite slow :) Jun 09 20:15:10 woglinde: so as soon as you have an patch I can test it here Jun 09 20:15:33 jama yes I know Jun 09 20:19:26 JaMa, . Jun 09 20:20:40 blindvt: ok, i'll do it, mmt Jun 09 20:21:11 JaMa, no hurry. take your time Jun 09 20:23:02 I'm trying to find which version I've checked when I said: Jun 09 20:23:03 15:16 < JaMa> what's better place for run-parts? busybox installs it to /bin/run-parts, debianutils to /usr/bin/run-parts, and u-a then fails, I'll move one of them, but not sure which is better Jun 09 20:23:07 15:27 < hrw> JaMa: debian one Jun 09 20:26:15 ah my problem with shadow was because pam modules were not installed Jun 09 20:26:38 now it works like a charm after I add it to DISTRO_FEATURES for uclibc Jun 09 20:26:58 blindvt: now I can review your patches in the evening Jun 09 20:27:12 khem yeah cool Jun 09 20:27:24 debugging does help Jun 09 20:27:30 khem, features are the key today ;) Jun 09 20:28:17 heh seems so Jun 09 20:28:52 pb_, should i fork the busybox ipv6 vs features/dep heuristics into a separate thread along a summary? Jun 09 20:29:19 blindvt: I have big enough uclibc based system booted in qemu that I can try to do a native compile of uclibc Jun 09 20:29:28 ob qemu Jun 09 20:29:32 i usually hate to do that, but perhaps i should have brought it up separately in the first place Jun 09 20:29:48 dunno Jun 09 20:30:11 blindvt: did you check your debianutils package? Jun 09 20:30:24 blindvt: mine really has /usr/bin/run_parts Jun 09 20:30:40 blindvt: see http://build.shr-project.org/tests/shr-unstable/ipk//armv4t/debianutils_2.30-r1.4_armv4t.ipk Jun 09 20:32:50 blindvt: test -z "/usr/bin" || /OE/tmpdir-dev/sysroots/x86_64-linux/usr/bin/mkdir -p "/OE/tmpdir-dev/work/armv5te-angstrom-linux-gnueabi/debianutils-2.30-r1/image/usr/bin" /OE/tmpdir-dev/sysroots/x86_64-linux/usr/bin/install -c run-parts tempfile '/OE/tmpdir-dev/work/armv5te-angstrom-linux-gnueabi/debianutils-2.30-r1/image/usr/bin' Jun 09 20:33:16 so SHR and Angstrom builds have it /usr/bin, so that patch you sent is not enough... Jun 09 20:33:48 JaMa, i baked micro-base-image with uclibc off OE master, targeting qemux86 Jun 09 20:36:19 JaMa, since debian itself puts run-parts straight into /bin i'm inclined to blame others to somehow misconfigure debianutils, don't you think? Jun 09 20:37:40 JaMa, either way. putting run-parts into /usr/bin/ is against established common usage and as such that behaviour is a bug there and not in busybox. Jun 09 20:37:50 blindvt: it does seem rather unrelated to the other patches that you sent, so that might be a good idea Jun 09 20:38:07 pb_, will do in a minute Jun 09 20:38:56 03Khem Raj  07org.openembedded.dev * r246c80637b 10openembedded.git/recipes/shadow/ (5 files in 2 dirs): Jun 09 20:38:56 shadow-4.1.4.2: Add patches to support dots in login id. Jun 09 20:38:56 Signed-off-by: Khem Raj Jun 09 20:40:05 03Khem Raj  07org.openembedded.dev * r0f5be314dd 10openembedded.git/contrib/qemu/run-qemu.sh: Jun 09 20:40:05 run-qemu.sh: Suppport option to boot into single user shell. Jun 09 20:40:05 Signed-off-by: Khem Raj Jun 09 20:40:26 blindvt: I agree to move it back to /bin, but first we should fix why debianutils is usually misconfigured while building with OE (Makefile.am looks ok and log.do_configure too..) Jun 09 20:41:31 pb__: why does micro not use /usr Jun 09 20:41:50 khem: because /usr is unnecessary Jun 09 20:42:07 bindir in micro is set to /bin (instead of /usr/bin) ? Jun 09 20:42:22 pb__: while that may be true many packages have now started to rely on /usr Jun 09 20:42:43 JaMa: effectively, yes Jun 09 20:42:45 so micro may end up in some troubles Jun 09 20:42:51 khem: which ones? can they not be fixed? Jun 09 20:43:06 pb__: they can be fixed Jun 09 20:43:16 blindvt: ^ see? Jun 09 20:43:16 like someone reported yesterday about gcc Jun 09 20:43:48 and changing gcc to behave distro specific is something we have not done yet Jun 09 20:44:14 it shouldn't be distro specific as such, it just needs to respect ${prefix} Jun 09 20:44:18 gcc assumes that on linux system headers are in /usr/include Jun 09 20:44:22 JaMa, try rsh some-debianbox 'which run-parts' Jun 09 20:45:05 JaMa, try rsh some-debianbox 'which run-parts | grep -q /usr/ && echo there is a problem || echo nothing to do with micro' Jun 09 20:45:11 blindvt: already tried..22:03:20 < JaMa> blindvt: odd, now checking on my gentoo box and debian box that both have debianutils /bin/run-parts Jun 09 20:45:49 blindvt: but all distros exept micro will install it to /usr/bin/ so first fix debianutils recipe and then we can remove it from busybox Jun 09 20:46:32 JaMa, this thing has nothing to do with micro. Your distro is foobar for installing debianutils with --prefix=/usr instead of / Jun 09 20:47:41 re Jun 09 20:47:50 wb Jun 09 20:48:24 blindvt: see log.do_configure from any distro != micro Jun 09 20:48:47 blindvt: --prefix=/usr --exec_prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin Jun 09 20:48:53 03Tom Rini  07org.openembedded.dev * r8cd716868a 10openembedded.git/recipes/ncurses/ (4 files): Jun 09 20:48:54 ncurses: Switch to INC_PR and BBCLASSEXTEND. Fix ncurses-sdk and terminfo Jun 09 20:48:54 RSUGGESTS needs to use ${PN} not ncurses otherwise ncurses-sdk will try Jun 09 20:48:54 ncurses-terminfo (wrong) not ncurses-sdk-terminfo (right). Jun 09 20:48:54 Signed-off-by: Tom Rini Jun 09 20:48:56 khem: right, so it just needs patching to use sysroot/${includedir} and it will be fine. Jun 09 20:48:59 JaMa, and yes, i'm now aware that micro collapses usr. There must be an option to mimic usual behaviour, isn't there Jun 09 20:49:01 blindvt: and Makefile.am is installing all utils to bindir Jun 09 20:50:44 blindvt: great, so now you see my point? Jun 09 20:51:28 JaMa, which knob do i have to toggle to make micro also use usr? Jun 09 20:51:48 blindvt: see micro.conf Jun 09 20:51:50 blindvt: use minimal Jun 09 20:52:01 if you want to use /usr Jun 09 20:52:20 "knob"? its just prefix, set the prefix variable with an override Jun 09 20:52:25 prefix_local = "/foobar" Jun 09 20:52:32 and bitbake minimal-image is less than 1000 tasks Jun 09 20:52:52 take like 3 hours on machines I have Jun 09 20:55:47 kergoth, "knob" as in comment out *prefix setting in micro.conf Jun 09 21:01:43 kergoth: with the pnum changes now there are double copies of patches in build tree :( Jun 09 21:01:51 with quilt Jun 09 21:05:13 khem: you mean the unpacking of the patches into WORKDIR? Jun 09 21:05:18 yeah Jun 09 21:05:25 just need to move the patch detection logic into a function and make both patch and unpack use it Jun 09 21:05:26 may be quilt should be fixed Jun 09 21:05:30 it isn't quilt Jun 09 21:05:31 not to copy Jun 09 21:05:31 its do_unpack Jun 09 21:05:44 quilt behaves the same way it always did Jun 09 21:05:53 import copies the patches Jun 09 21:06:10 yeah but now that patches are there may be quilt can just use them instead of copying again Jun 09 21:06:39 btw FILESDIR = "${@os.path.dirname(bb.data.getVar('FILE',d,1))}/gdb-${PV}" seems useless Jun 09 21:07:12 filesdir has been deprecated for a long, long time Jun 09 21:07:17 that is useless, yeah Jun 09 21:08:41 hmm Jun 09 21:08:53 the quilt thing could likely be done in oe.patch instead of modifying quilt itself Jun 09 21:09:04 just symlink the patch into patches/ in the import method, rather than running quilt import Jun 09 21:09:20 and add to series, of course Jun 09 21:09:30 kergoth_: you wouldnt believe there still are like 192 files which contain FILESDIR Jun 09 21:09:35 hah Jun 09 21:09:40 kergoth: yeah that seems a better idea Jun 09 21:09:43 this is what happens when we don't make big obvious annoying warning messages Jun 09 21:11:00 * khem nods Jun 09 21:13:05 kergoth: where is quilt import used ? Jun 09 21:13:16 khem: gentoo binutils maintainer forwarded me to this bug http://sourceware.org/bugzilla/show_bug.cgi?id=4970, any idea? Jun 09 21:13:58 khem: line 240 of openembedded/lib/oe/patch.py Jun 09 21:15:34 kergoth: ah I was looking in patch.bbclass Jun 09 21:15:53 should be pretty easy to add, just change that Import method to make the symlink adn append to series rather than calling quilt import Jun 09 21:16:02 patch["file"] is already the localpath of the uri Jun 09 21:16:15 so can use it directly from its location in the tree, not from workdir or anywhere else Jun 09 21:16:24 cool Jun 09 21:16:28 that will speed it up Jun 09 21:16:59 btw. we should also get rid of patches being copied to build area Jun 09 21:17:02 i'll see about fixing the unpack to not bother copying patches. need to resurrect some do_patch unit tests before i go moving the logic around, to make sure i don't break i Jun 09 21:17:07 cool Jun 09 21:17:09 not sure what you mean Jun 09 21:17:19 I meant what you just addressed Jun 09 21:17:25 * kergoth nods Jun 09 21:17:34 it doesn't know how to identify a patch anymore, since it may be going by filename and all Jun 09 21:17:38 just need to make that logic common Jun 09 21:19:00 hmm i c Jun 09 21:19:23 patches are just a special case. since do_patch is python, and we know its python, and will be using the files directly from their local paths, there's no point copying it, but other files are used by shell tasks, which don't have the ability to traverse FILESPATH to resolve the url to the path outside of workdir Jun 09 21:19:44 khem: benchmarks: http://pastebin.ca/1880021 Jun 09 21:20:36 JaMa: so now you see the difference :) Jun 09 21:20:53 yeah nice Jun 09 21:20:53 if we ever add helpers for the shell tasks to use to interact with the bitbake backend via xml/rpc, we could avoid copying the majority of the files, if we wanted to Jun 09 21:20:56 1211836.4 lps Vs. 752616.3 lps Jun 09 21:21:34 khem: pity that you said it's not ready to be enabled globally yet Jun 09 21:21:48 khem: otherwise I would rebuild my gentoo box :) Jun 09 21:22:20 JaMa: thats like 60% improvement Jun 09 21:22:38 JaMa: you could certainly Jun 09 21:22:45 but there may be rough edges Jun 09 21:22:54 its not been tried in real world yet Jun 09 21:23:42 khem: I'll wait with it for 4.5.[12] Jun 09 21:26:34 JaMa: it will prolly be 4.6 Jun 09 21:26:46 JaMa: btw Process Creation Test has regressed with lto Jun 09 21:26:50 and whole-program Jun 09 21:28:03 khem: also all Arithmetic tests are failing with any gcc-4.5 :/ Jun 09 21:28:44 yeah I wonder Jun 09 21:28:49 that must be a bug somewhere Jun 09 21:28:58 if you want we can look into it Jun 09 21:29:28 not today.. 23:30 and I should adjust bike breaks a bit before trip tomorrow.. Jun 09 21:30:00 khem: but its bench.tar.gz from here http://www.anime.net/~goemon/benchmarks.html Jun 09 21:30:35 khem: here is newer version http://code.google.com/p/byte-unixbench/ Jun 09 21:31:07 khem: newer has also some X11 tests and I got ICE while building it (with older revision of gcc) Jun 09 21:35:55 JaMa: cool Jun 09 21:36:02 I think we should add a recipe for it Jun 09 21:49:39 pb_, or think m68k vs coldfire; think m68k|coldfire|bfin|etc vs. MMU. bfin == !MMU; for some m68k or coldfire MMU is optional for others !MMU is a hard constraint. Think floatingpoint HW support (disregarding Multimedia extensions like mmx/sse and whatnot), think softfp vs VFP etc. Jun 09 21:50:46 pb_, i don't seem to be able to find neither a solver nor facility to express hard/soft constraints at all? Jun 09 21:52:14 (in this respect; there are normal package dependencies and a basic approach to handle e.g. thumb or nls but in a brittle manner, IMHO) Jun 09 21:53:13 hmmm Jun 09 21:53:29 * kergoth thinks about resurrecting his patches that switched bitbake to using the python logging module Jun 09 21:56:05 sheesh, its been over 6 months since i did the old incarnation of that - http://thread.gmane.org/gmane.comp.sysutils.bitbake.devel/1065 Jun 09 21:56:11 kergoth, what i find _extremely_ ugly is the os.system(.*tee) call. There must be a superior way Jun 09 21:56:28 there is Jun 09 21:57:33 just open the pipe and read its data bit by bit, printing it if debugging is enabled, and writing to the file Jun 09 21:57:38 rather than doing the lazy route Jun 09 21:57:40 kergoth, heh, that exact patch exposes but doesn't touch that popen(tee) uglyness :) Jun 09 21:57:45 heh :) Jun 09 21:57:54 blindvt: thanks for your latest mail, but I still don't quite understand what specific problem you are trying to solve. Jun 09 21:58:01 Anyone have experience compiling with omap3_pm_defconfig - Hillman's power management kernel? Jun 09 21:58:03 i expect that tee stuff has been there since the initial implementation Jun 09 21:58:34 he robtow Jun 09 21:58:46 pb_, not sure if you saw what i just said. Here it is again: http://paste.debian.net/76806/ Jun 09 21:58:49 woglinde - good afternoon :-) Jun 09 21:58:51 robtow unfornatly not Jun 09 21:58:56 for the logging, i think bb.msg can just go away once we move to the logging module Jun 09 21:59:11 can use a handler which sends the messages over the pipe between client/server as the Msg events behind the scenes Jun 09 21:59:26 woglinde - I am looking to see how low I can reduce power consumption on the Overo Gumstix (water module), to be specific. Jun 09 21:59:37 blindvt: patches welcome ;) Jun 09 22:00:03 we should resurrect the bitbake TODO file Jun 09 22:00:06 add things like that to it Jun 09 22:00:23 blindvt: I didn't see that, but I think I had gathered that much from your email. I guess what I am struggling to understand is what you want to do with this information and where you want to have it exposed. Jun 09 22:00:25 kergoth, is there syscall support in python, like os.syscall(tee,whatever) ? Jun 09 22:00:37 that wouldnt' be a portable way to do it Jun 09 22:00:41 woglinde - the sort of thing you needed for NavIt, I'm sure. Jun 09 22:00:45 NOT Jun 09 22:00:46 you don't need to fork off a tee process at all Jun 09 22:00:50 just use python to do it Jun 09 22:00:58 kergoth, not exactly portable, yea Jun 09 22:01:16 blindvt: to take your specific example of softfp vs vfp (vs fpa, for the sake of argument), gcc knows what fp system is in use and will, in general, just do the right thing. if you need to adapt your code for it, there are preprocessor macros you can test. Jun 09 22:01:40 pb_, i'd expose it per package via HANDLED_FEATURES, for example Jun 09 22:02:33 blindvt: right, but to what end? Jun 09 22:03:24 are you trying to create some mechanism by which a distro configuration can be somehow auto-negotiated between a machine and a set of packages? Jun 09 22:03:39 pb__: FPU is a machine feature IMO and what calling conventions for fp to use should also be tied to machine Jun 09 22:03:41 pb_, my "problem" is that i somehow need to configure the kernel (i usually use one) and the libc to provide the features that my target needs to provide. I have setups that do not need networking and i have setups that want IPv6 only Jun 09 22:05:00 pb_, so, for the IPv6-only setups (which either come in via distro or user, dunno?), i have to configure kernel/libc accordingly and also pick the packages that suit Jun 09 22:05:06 blindvt: that kind of stuff would, generally, go in the distro configuration. Jun 09 22:05:25 indeed, that's more or less the whole raison d'etre for the distro configuration in the first place. Jun 09 22:06:53 pb_, and for those IPv6 only setups, i have a dozend of arches that i want to build for: All gcc supported arches both with and without mmu/FP/shared-library-support/nls/whatnot Jun 09 22:07:12 blindvt: sure, that's fine. architecture is orthogonal to distro. Jun 09 22:08:07 well, perhaps orthogonal is the wrong word. architecture is a different but subservient degree of freedom. Jun 09 22:08:22 pb__, but how can i sanely express such setups? How do i know if i need to build networking support into libc and kernel? How do i know that i can disable networking altogether or just ipv4 or just ipv6 ? Jun 09 22:09:31 is MACHINE_FEATURES and DISTRO_FEATURES insufficient? COMBINED_FEATURES contains the items supported by both machine and distro, it seems like a solid fit for that sort of thing Jun 09 22:10:20 pb_, network support and flavors is a distro feature, and imho the user can either a) pick umong the distro-provided features or b) impose his choice unto the distro. That's the bottom-up or top-down part of my question Jun 09 22:11:49 i was planning on adding a USER_FEATURES, personally, to let the user override the distro Jun 09 22:11:53 haven't gotten around to it.. Jun 09 22:12:10 blindvt: well, the oe way of thinking about that would be that each distro sets the set of features that it includes, and the user gets to pick the distro which most closely matches his desires. Jun 09 22:12:42 RP: any tips on determining process context at a given point in the bitbake code? it's not entirely clear in which context a given method is used Jun 09 22:12:43 hmm Jun 09 22:12:46 kergoth, COMBINED_FEATURES contains ext2 and vfat?! Jun 09 22:13:01 why would it? Jun 09 22:13:11 those are distro, not distro+machine Jun 09 22:13:23 kergoth: yeah, you could do that. it would have to come with a fairly large health warning about not sharing your binaries with other users of the "same" distro, since what you now have is not really that distro anymore, but it does seem to be a feature which is often requested. Jun 09 22:13:48 could always put a +dirty or something onto the distro string, in the motd, etc, too Jun 09 22:14:14 yeah. and, clearly, it doesn't let you do anything that you can't already do via local.conf or local hacks to the .conf files. Jun 09 22:14:17 kergoth, how are filesystems concerned about the machine? I mean they are arguably concerned about the HW abstraction layer, but not the HW itself, no? Jun 09 22:14:23 they aren't Jun 09 22:14:28 and i didn't say they were Jun 09 22:14:32 which is why they aren't in combined features Jun 09 22:14:43 combined features, again, contains the elements common to distro and machine Jun 09 22:15:24 RP: nevermind, i think i may have a handle on it Jun 09 22:18:23 i have to go to bed. g'night all Jun 09 22:18:41 * kergoth ponders Jun 09 22:26:05 kergoth: I have a/b/c.txt how can I extract just c.txt from that string in python Jun 09 22:26:15 os.path.basename(path) Jun 09 22:26:29 (also useful: dirname, join, splitext, ..) Jun 09 22:26:47 is there echo equivalent Jun 09 22:26:53 I want to write it into another file Jun 09 22:26:56 or rather append it Jun 09 22:27:06 open(path, "a").write(os.path.basename(foo)) Jun 09 22:27:27 course, you're better off doing f = open(path, "a"); f.write(blah); f.close() Jun 09 22:27:35 (explicitly closing is usually a good idea) Jun 09 22:27:37 but either will work Jun 09 22:29:34 hmmm, i think switching to logging will be rather less painful than i thought Jun 09 22:29:51 hm wasnt python doing closing for you? Jun 09 22:30:05 when the object goes away, yeah Jun 09 22:30:39 good policy to close it explicitly, however, so the lifetime is known, and it doesn't stay open while someone else messes with it Jun 09 22:30:47 if you're on 2.5+, you can use 'with' for it Jun 09 22:41:29 kergoth: btw http://pastebin.com/BT0itEmj Jun 09 22:41:33 what do you think :) Jun 09 22:41:45 * khem is using pastebinit Jun 09 22:41:54 nice little cmd utility Jun 09 22:42:19 see os.symlink :P Jun 09 22:42:27 don't need to spawn a subprocess at all Jun 09 22:42:37 kergoth: heh ok let me improve it :) Jun 09 22:42:40 :) Jun 09 22:46:44 kergoth: ://pastebin.com/3wcF2mii Jun 09 22:46:53 http://pastebin.com/3wcF2mii Jun 09 22:47:12 one minor nitpick, use os.path.join() rather than + with "/" Jun 09 22:47:17 other than that, looks good to me Jun 09 22:51:47 kergoth: 3rd and final http://pastebin.com/aqdiQQ29 Jun 09 22:52:01 looks good to me Jun 09 22:52:03 tested it? Jun 09 22:52:39 on one recipe yes as we speak :) Jun 09 22:53:02 but I can do a full build from scratch for say native-sdk-image Jun 09 22:53:35 right now it assumes that series file is called series and patches folder is called patches Jun 09 22:54:06 I have seen that some packages have patches as a normal dir then one has to change the default patches path for quilt Jun 09 22:55:02 right now it imports and applies one patch at a time Jun 09 22:55:19 may be we should change it to import all in one go i.e. symlink Jun 09 22:55:26 and then quilt push all Jun 09 22:55:47 this helps sometimes when I have to refresh more than one patch Jun 09 22:56:19 then I dont have to iterate -c clean and -c patch tasks until all patches are fixed Jun 09 22:56:37 I can just cd into the build tree and quilt push/pop by hand Jun 09 23:05:26 why would you have to -c clean? Jun 09 23:07:11 nice, i got the conversion of bb.msg to logging to work with master Jun 09 23:08:35 because it stops at the first patch it cant apply atm Jun 09 23:08:44 so I dont have the rest of series Jun 09 23:08:58 because it does import+patch in a loop Jun 09 23:09:08 I was suggesting to import all + patch all Jun 09 23:09:12 in one go Jun 09 23:09:22 gotta go Jun 09 23:09:39 I have started a minimal-image build from scratch lets see :0- Jun 09 23:10:52 that class is supposed to read in the current state of the patch set, guess it doesn't work Jun 09 23:23:45 anyone have any thoughts on http://github.com/kergoth/BitBake/commits/logging ? Jun 09 23:23:47 top two commits Jun 09 23:44:56 ugh, the handling of exceptions from python functions from the metadata right now is a giant pain in my ass Jun 09 23:46:59 "ERROR: Task 32 (/home/kergoth/Code/oe/openembedded/recipes/stage-manager/stagemanager-native_0.0.1.bb, do_setscene) failed with 256" Jun 09 23:47:03 that's really fucking helpful, thanks Jun 09 23:47:22 * kergoth grumbles Jun 09 23:47:51 running with -D doesn't help, which means the exception isn't getting to the toplevel handler, something is swallowing it first Jun 09 23:53:48 kergoth - I feel your pain. Jun 10 00:51:54 03Bernhard Reutner-Fischer  07org.openembedded.dev * r070e46f293 10openembedded.git/recipes/uclibc/uclibc_git.bb: (log message trimmed) Jun 10 00:51:54 uclibc_git: keep PV at "git" Jun 10 00:51:54 With this change, you can put Jun 10 00:51:54 PREFERRED_UCLIBC_VERSION="git" into your conf/local.conf Jun 10 00:51:54 once or set PREFERRED_VERSION_uclibc{*}="git" and need Jun 10 00:51:55 not adjust local.conf if the git revision was changed. Jun 10 00:51:55 Signed-off-by: Bernhard Reutner-Fischer Jun 10 00:51:57 03Khem Raj  07org.openembedded.dev * r428c2de6d2 10openembedded.git/lib/oe/patch.py: (log message trimmed) Jun 10 00:51:57 lib/oe/patch.py: Dont import patches but symlink them instead Jun 10 00:51:57 * This patch removes the usage of quilt import Jun 10 00:51:58 instead it creasted a symlink to the patch in the patches Jun 10 00:51:58 directory and synthesizes the series file which otherwise Jun 10 00:51:59 would be done automatically by quilt import. Jun 10 00:51:59 * This should help a bit in reducing build time as it avoids Jun 10 00:52:00 03Khem Raj  07org.openembedded.dev * r0dc02df572 10openembedded.git/conf/distro/minimal-uclibc.conf: (log message trimmed) Jun 10 00:53:55 damn, i thought i had this Jun 10 00:54:44 it *works*, but the logging levels arent working correctly Jun 10 01:04:57 03Khem Raj  07org.openembedded.dev * rbfe9198dda 10openembedded.git/lib/oe/patch.py: Jun 10 01:04:57 Revert "lib/oe/patch.py: Dont import patches but symlink them instead" Jun 10 01:04:57 pushed wrong branch. It needs to be reviewed before pushing. Jun 10 01:04:57 This reverts commit 428c2de6d27dd49274b9884c3123b053c42af0ce. Jun 10 01:18:14 god this is weird Jun 10 01:18:16 hmm Jun 10 01:20:09 i set the log level for this logger, then later on in the same process its been reset, yet i can't see any way that could happen :| Jun 10 01:28:34 damnit, what the fuck Jun 10 01:37:27 whew Jun 10 01:37:28 finally Jun 10 02:05:08 03Khem Raj  07org.openembedded.dev * r8b17bc55a9 10openembedded.git/recipes/gdb/ (gdb-7.1/gdb-tcsetpgrp.patch gdb_7.1.bb): Jun 10 02:05:08 gdb_7.1: Add patch to shut a warning when we boot into shell. Jun 10 02:05:08 * [tcsetpgrp failed in terminal_inferior: Inappropriate ioctl for Jun 10 02:05:08 * device] Jun 10 02:05:08 this warning is pretty annoying when debugging on a shell which Jun 10 02:05:09 does not have a proper console device allocated and no job control. Jun 10 02:05:10 Signed-off-by: Khem Raj Jun 10 02:19:19 hmmm Jun 10 02:20:38 something is still swallowing exceptions whole Jun 10 02:20:40 :( Jun 10 02:43:36 whew, all betteer Jun 10 02:43:51 few more usages of bb.msg to kill inside of bitbake itself, but everything is happy now **** ENDING LOGGING AT Thu Jun 10 02:59:57 2010