**** BEGIN LOGGING AT Fri Jul 29 02:59:56 2011 Jul 29 06:53:36 khem: do you have a sec? Jul 29 07:55:45 can anybody tell me what 'task-base-extended' is. I searched through all recipes and could not find what it is or what it does... Jul 29 08:34:52 helloow? Jul 29 08:35:14 moo Jul 29 08:57:01 hi all Jul 29 08:57:29 hi bluelightning Jul 29 09:02:06 hi gnutoo Jul 29 09:03:57 hi Jul 29 09:06:30 woglinde, btw it's not related to oe directly but it seem that the bug with the maps in navit not finding my town has been solved(maptool issue) Jul 29 09:07:06 yes Jul 29 09:07:08 good Jul 29 09:07:53 yes it's very good Jul 29 10:09:04 hi, I've issues in shr-core Jul 29 10:09:06 it says: Jul 29 10:09:19 | /tmp/ccHnAgUE.s:275: Error: lo register required -- `add pc,r3,#(0xffff0fc0-0xffff0fff)' Jul 29 10:09:25 I remember thoses address Jul 29 10:09:29 it's cmpxchg Jul 29 10:10:01 at least 0xffff0fc0 is cmpxchg Jul 29 10:10:38 JaMa, any idea? Jul 29 10:10:46 it's from that package: Jul 29 10:11:01 eglibc-initial-2.13-r9+svnr14157 Jul 29 10:11:27 oops I lost the console log Jul 29 10:11:36 anyway it was in libc-start or something like that Jul 29 10:20:04 http://www.pastie.org/2289074 Jul 29 10:20:20 oops forget that paste Jul 29 10:28:05 GNUtoo|laptop: that's because armv5te is now compiled with -mthumb :( Jul 29 10:32:40 it's a bad choice that -mthumb and -mthumb-interwork are now specified in the TUNE_CCARGS Jul 29 10:38:17 sorry, connection issues(wifi far away+vpn) Jul 29 10:38:39 ensc|w, ok http://www.pastie.org/2289076 here I see -mthumb Jul 29 10:38:49 the target is om-gta02 which is armv4t Jul 29 10:38:55 should I add that: Jul 29 10:39:07 ARCHITECTURE_arm = "ARM" Jul 29 10:39:11 or something like that Jul 29 10:39:20 I don't remember the exact syntax off hand Jul 29 10:40:00 ARM_INSTRUCTION_SET = "arm" Jul 29 10:40:02 rather Jul 29 10:41:05 GNUtoo|laptop: yes it's known.. Jul 29 10:42:08 ok Jul 29 10:42:12 then I'll wait Jul 29 10:42:21 GNUtoo|laptop: http://lists.linuxtogo.org/pipermail/openembedded-core/2011-July/007069.html Jul 29 10:43:01 GNUtoo|laptop: I won't be here for next week+weekend.. so if you're using oe-core-contrib/shr, feel free to update it when it's fixed in master Jul 29 10:45:40 GNUtoo|laptop: the problem is that ARM_INSTRUCTION_SET is no longer respected by new tune-* Jul 29 10:46:07 ah ok ouch Jul 29 10:46:31 but I was able to build n900 image yesterday after few more changes.. Jul 29 10:46:37 ok nice Jul 29 10:46:47 do rebuild from scratch.. Jul 29 10:47:17 as package arch is changed from armv7a to armv7a-vfp-neon Jul 29 10:47:35 I didn't build for n900 yet Jul 29 10:48:30 so there is armv7a without neon? Jul 29 10:48:34 like for palm-pre? Jul 29 10:48:38 (it seem to have a broken neon) Jul 29 10:49:27 real bug is in eglibc's libc/ports/sysdeps/unix/sysv/linux/arm/nptl/bits/atomic.h Jul 29 10:49:35 ok Jul 29 10:49:57 the userspace part of cmpxchg kernel implementation Jul 29 10:52:34 GNUtoo|laptop: you can limit tunables from machine config, but configs in meta-palm weren't updated and seems wrong now Jul 29 10:54:49 ok Jul 29 10:58:15 can I put TUNENAME_pn-eglibc = "armv4" in local.conf? Jul 29 11:03:51 better to wait for proper solution, if you can play with n900 for now Jul 29 11:04:39 ok Jul 29 11:05:02 I'm out of space for building for oe.dev anyway Jul 29 11:06:36 * JaMa removed oe.dev workdir already.. Jul 29 11:08:36 ok Jul 29 13:00:30 Hi, I'm trying to compile valgrind using yocto for my ARM board but I get "ERROR: Nothing PROVIDES 'valgrind'" Jul 29 13:00:39 the recipe exists in recipe-devtools Jul 29 13:02:17 mrAlmond: COMPATIBLE_HOST = '(i.86|x86_64).*-linux' Jul 29 13:02:34 mrAlmond: if you're building it for arm then you need newer version which supports arm (not yet in oe-core) Jul 29 13:02:40 yes valgrind dont work this good enough on arm Jul 29 13:02:43 maybee its changed Jul 29 13:02:45 find out Jul 29 13:03:00 3.6.1 should support ARM Jul 29 13:03:14 yocto version is 3.6.0 Jul 29 13:03:21 ah 3.6* should support it Jul 29 13:03:39 so test it without COMPATIBLE_HOST and if it works, report with patch removing COMPATIBLE_HOST Jul 29 13:03:59 ok tnx!! Jul 29 13:04:32 there was discussion on oe-devel ML few months back.. strange that ther is also COMPATIBLE_HOST in oe.dev.. Jul 29 13:06:10 configure: error: Unsupported host architecture. Sorry Jul 29 13:06:25 so probably we need to integrate 3.6.1 Jul 29 13:06:36 mrAlmond yes go on Jul 29 13:07:06 from the valgrind site : 16 February 2011: valgrind-3.6.1, for X86/Linux, AMD64/Linux, ARM/Linux, PPC32/Linux, PPC64/Linux, X86/Darwin and AMD64/Darwin (Mac OS X 10.5 and 10.6) is available. (release notes). Jul 29 13:07:29 I will try to integrate it Jul 29 13:12:22 why does valgrind depends on virtual/libx11 ? Jul 29 13:16:24 maybe it has a ui? Jul 29 13:16:45 look at the packaging, it is possible the x and non x parts get packaged seperately also Jul 29 13:16:57 alleyoop is a nice gui to valgrin Jul 29 13:16:58 d Jul 29 13:17:02 which uses qt I think Jul 29 13:17:06 Crofton : ok tnx Jul 29 13:17:40 uhm...checking for a supported CPU... no (arm) configure: error: Unsupported host architecture. Sorry Jul 29 13:17:52 looks like something here is wrong Jul 29 13:18:03 also with 3.6.1 Jul 29 13:18:25 urg do we have a var for /usr/etc ... Jul 29 13:19:20 don't think so Jul 29 13:19:31 iirc, /usr/etc isn't in FHS and no modern systems use it Jul 29 13:19:44 heh Jul 29 13:19:47 yeah Jul 29 13:19:55 gnuradio sticks some files in there Jul 29 13:19:58 stupid files Jul 29 13:19:59 usr/etc is used by some crappy unixes Jul 29 13:20:13 ah. well, gnuradio should stop doing that. heh. Jul 29 13:20:30 looks like it supports armv7 but no "arm" Jul 29 13:20:37 if they're config files, they should go in /etc. if they're random data, they should go in /usr/share/gnuradio. Jul 29 13:21:01 yeah, for now ${prefix}/etc? Jul 29 13:21:07 I will bitch at upstream Jul 29 13:21:17 that would probably work Jul 29 13:27:45 why are the TUNE_CCARGS using '-mtune=' instead of '-mcpu='? Jul 29 13:31:19 hello , please i wanna to start learning about embedded system(General), but i dont know yet how to start. should i kearning electronic ?? or just programming language?? if yes what kind ?? Jul 29 13:34:16 depends on you...about engineering the hw? about building it? about OS? about software? there are many fields of work needing different backgrounds Jul 29 13:35:03 ideally you would know it all :p Jul 29 13:36:39 hhh why not ? hehe Jul 29 13:37:23 ok valgrind 3.6.1 compiles for arm with a small stupid patch to configure.in Jul 29 13:37:30 I'm going to try it ;-) Jul 29 13:38:01 i think that i wanna to start embedded systems (linux) Jul 29 13:46:52 kakashi__ lot of people clai this Jul 29 13:46:53 claim Jul 29 13:47:09 mrAlmond hm oha Jul 29 13:48:23 so??? what do you advise me in this case??? i know programming on C and python and i use linux well. can you avise me something??? Jul 29 13:49:14 lol Jul 29 13:49:27 so you already learnded embedded linux Jul 29 13:50:21 kakashi__ start learn about cross compiling Jul 29 13:50:22 what should I advise Jul 29 13:50:33 got an embedded linux board Jul 29 13:50:42 like the beagle board Jul 29 13:50:43 and try to get it run Jul 29 13:50:51 mrAlmond he dont need Jul 29 13:50:56 he only need oe Jul 29 13:51:27 yes but knowing about cross compiling helps you in understanding how oe works Jul 29 13:51:42 and sometimes could save your a** ;-) Jul 29 13:54:26 morning kergoth Jul 29 13:55:40 ensc|w: presumably so that you can have -mtune= and -march= be different, which isn't a bad idea. -mcpu= is just a shorthand for the combination of those two flags so there is no advantage in using it, particularly. Jul 29 13:57:26 hey Jul 29 14:00:37 pb_: -mcpu select the most aggressive optimization by allowing instructions which are available for this cpu only Jul 29 14:00:58 but there can be different -march for a -mcpu Jul 29 14:01:25 e.g. -mcpu=cortex-m3 allows -march=arm7-m and armv7-r (?) Jul 29 14:01:35 ensc|w: I'm not quite sure I understand what you're saying. but, -mcpu=foo is precisely equivalent to -mtune=foo -march= Jul 29 14:01:51 pb_: no Jul 29 14:02:17 foo can have multiple archs Jul 29 14:03:03 not in gcc's model of the world. each cpu has exactly one arch, and for cortex-m3 it's 7M. Jul 29 14:03:20 see arm-cores.def Jul 29 14:05:21 oh, actually, it does look as though -mcpu= can have a few other side effects as well, for example -mcpu=cortexm3 enables -mfix-cortex-m3-ldrd but -mtune=cortex-m3 doesn't. Jul 29 14:08:45 but, apart from that, it doesn't seem as though there is any interesting difference. if you have an example of an optimisation that happens with -mcpu=cortex-m3 but not with -march=armv7-m -mtune=cortex-m3 then I'd be interested to see it. Jul 29 14:15:57 woglinde: I think I'm missing debuginfo in my rootfs : http://pastebin.com/Y84rUndX Jul 29 14:16:07 How can I install them? Jul 29 14:19:05 pb_: ah ok, I confused it with binutils where you can request special architecture extensions Jul 29 14:19:21 nevertheless, -mcpu is a stronger optimization than -mtune Jul 29 14:19:40 it is stronger than -mtune alone, but no stronger than -mtune+-march (which is what oe currently uses) Jul 29 14:20:08 swapping the -mtune+-march for -mcpu would not make anything better (as far as I can tell) and would force the two things to match which is not always desirable Jul 29 14:23:30 mrAlmond install the -dbg packages Jul 29 14:23:50 for example, back in familiar 0.8 days we used to build with -march=armv4 -mtune=pxa255, and that combination doesn't correspond to any -mcpu setting. Jul 29 14:25:18 woglinde : tnx Jul 29 14:37:49 Damn RP, who broke xscale on oe-core. Jul 29 14:38:27 JaMa: still there? Jul 29 14:38:47 lumag: pls pull again meta-zaurus Jul 29 14:38:59 lumag: collie is somehow WIP Jul 29 14:39:55 lumag: what's wrong with xscale? Jul 29 14:41:25 pb_: http://pastebin.de/18018 Jul 29 14:41:47 pb_: I'll submit a patch after finishing build. Jul 29 14:41:53 ant_work: wip branch? Jul 29 14:42:00 no, master Jul 29 14:42:16 lumag: oh, RP said he fixed that Jul 29 14:42:33 pb_: that's what I see in the master. Jul 29 14:43:18 oh, heh Jul 29 14:43:28 there were two wrong lines and he only fixed one of them Jul 29 14:43:39 originally both TUNE_FEATURES and PACKAGES_EXTRA_ARCHS were wrong Jul 29 14:43:50 he appears to have fixed the latter but not the former Jul 29 14:44:14 :) Jul 29 14:44:22 pb_: I fear your resumé will become a wiki Jul 29 14:46:10 ant_work: I'll test master later. Thanks for the work! Jul 29 14:48:35 pb_: after reading your summary, it seems to me that nothing works. Jul 29 14:48:44 lumag: for the moment collie includes the strongarm1100 file Jul 29 14:49:08 ant_work: that should work. There are no differencies between them AFAIR. Jul 29 14:49:30 great to hear Jul 29 14:49:46 I ain't sure about SA-110 -based machines, but I think they also have just SA-1 core. But who cares? Jul 29 14:49:53 having tune files in our layer will be a sure source of issues... Jul 29 14:50:18 ant_work: y Jul 29 14:50:22 s/will/would/ Jul 29 14:50:49 JaMa: I maybe discovered the license for encdec-updater Jul 29 14:51:02 meta-nslu2 lists it as GPL Jul 29 14:51:25 it is the last unknown iirc Jul 29 14:51:43 (no idea why that is in meta-nslu2 :) Jul 29 14:52:25 I don't think there's anybody using oe with sa-110. but yeah, from an ISA perspective SA-110 and SA-1100 run the same code, they are both just armv4. Jul 29 14:52:57 ant_work: I'll apply patch for that if you send one :) Jul 29 14:52:59 sa-1100 is effectively an sa-110 wrapped up with a bunch of peripherals. Jul 29 14:57:59 pb_: am I right, that eglibc is unbuildable on all armv5te arches? Or the problem only concerns qemuarm (926ejs)? Jul 29 14:59:31 lumag: I think it's unbuildable for any arch which sets "thumb" in TUNE_FEATURES Jul 29 15:00:04 lumag: in fact my build broke on eglibc overnight Jul 29 15:00:40 I'll see why later, had no time this morning Jul 29 15:00:50 ant_work: read oe-core list :) Jul 29 15:01:10 in short, problem is that ARM_INSTRUCTION_SET is no longer respected by new tune-* Jul 29 15:01:17 I did abstain from pulling for a couple of days while rebasing :) Jul 29 15:02:02 I'll swith to uclibc for further tests Jul 29 15:03:12 pb_: I just posted a patch which should not make it possible to build using thumb Jul 29 15:03:38 JaMa: ant_work pb_ please try it out and see if this works Jul 29 15:03:52 my testing is going on as we speak Jul 29 15:04:15 * JaMa launching armv4t build Jul 29 15:04:38 JaMa: with the patch I posted ? Jul 29 15:05:05 yes :) Jul 29 15:05:11 JaMa: cool Jul 29 15:05:16 the benchmark is eglibc Jul 29 15:05:31 if the compile goes through eglibc then it would mean it has succeeded Jul 29 15:05:32 I know.. Jul 29 15:06:29 gtg, will report later Jul 29 15:06:35 ok Jul 29 15:11:03 thanks mrlmond , for explain :) Jul 29 15:11:49 Hmm. Strange. Even with the current oe-core master I have the following for eglibc: Jul 29 15:11:57 -march=armv5te -mthumb -mthumb-interwork -mtune=xscale -mthumb-interwork -mno-thum Jul 29 15:12:01 *thumb Jul 29 15:12:14 What I'm doing wrong? Jul 29 15:12:18 last question :s . is it java usefull for embedded systems?? Jul 29 15:12:42 lumag: take the patch I posted few minutes ago Jul 29 15:12:56 khem: that's w/o the patch. Jul 29 15:13:10 Maybe it took something from old sstage though. Jul 29 15:13:40 lumag: whats your machine ? Jul 29 15:13:54 khem: tosa (xscale) Jul 29 15:14:12 http://patches.openembedded.org/patch/8861/ Jul 29 15:14:16 try with this patch Jul 29 15:14:25 currently master is broken for arm Jul 29 15:14:41 khem: I'll retry now. But the problem is that for me the build succeeded. Jul 29 15:14:59 BTW: your patch "warning: 3 lines add whitespace errors" Jul 29 15:15:13 lumag: ok I will fix those Jul 29 15:28:00 hi khem Jul 29 15:30:51 woglinde: hello Jul 29 15:30:59 pb_: I am testing your patches Jul 29 15:31:08 ok cool Jul 29 15:31:31 particularly 8809 8815 Jul 29 15:31:43 those numbers don't mean anything to me Jul 29 15:31:48 are those patchwork ids or something? Jul 29 15:31:53 pb_: aha patchwork Jul 29 15:32:08 http://patches.openembedded.org/patch/8815/ Jul 29 15:32:09 righto Jul 29 15:32:15 anything more ? Jul 29 15:32:38 yeah, those look like the ones you want Jul 29 15:32:48 plus the thing lumag mentioned for xscale, I don't know if he sent that patch yet Jul 29 15:34:08 Sent right now. Jul 29 15:34:14 rock Jul 29 15:37:44 lumag: what is the problem wrt. xscale Jul 29 15:38:52 http://article.gmane.org/gmane.comp.handhelds.openembedded.core/5181 Jul 29 15:39:10 pw #8863 Jul 29 15:40:15 pb_: I think in tune-arm926ejs.inc we have to set tune-arm926ejs.inc TUNE_FEATURES_tune-arm926ejs = "${TUNE_FEATURES_tune-armv5e} arm926ejs" instead of TUNE_FEATURES_tune-arm926ejs = "${TUNE_FEATURES_tune-armv5te} arm926ejs" Jul 29 15:40:20 to default to thumb Jul 29 15:40:32 err to *not* default to thumb Jul 29 15:41:23 khem: that seems a strange workaround. Jul 29 15:41:24 in the new tuning context armv5te has different semantics which is kind of confusing Jul 29 15:42:06 khem: what about other boxes which also support thumb? Jul 29 15:42:12 s/boxes/cores/ Jul 29 15:42:35 And how would you select thumb if that's requested by machine/etc.? Jul 29 15:42:42 lumag: as strange it may look its only conveying to enable thumb feature Jul 29 15:42:49 not conveying that thumb is available Jul 29 15:43:05 thats a bit confusing Jul 29 15:43:30 since usually people when see armv5te would think ok core has thumb available Jul 29 15:43:47 but in the new tune stuff this means use thumb instruction set Jul 29 15:44:39 Then probably we should drop all thumb setting in features and switch back to plain ARM_INSTRUCTION_SET handling. Jul 29 15:45:06 As this question is not only limited to 926, armv5 and (e.g.) xscale. Jul 29 15:45:40 lumag: well its not bad only trouble is it matches a familiar term which has different meanin Jul 29 15:46:30 so you have to differentiate between armv5te in general context and armv5te in TUNE_FEATURES context Jul 29 15:46:39 may be thumb was not denoted by t Jul 29 15:47:55 khem: that would be a workaround, but it is clearly not a good solution Jul 29 15:48:24 arm926ejs is, as a matter of fact, an armv5te core and I think it is (at the very best) confusing if you have to avoid mentioning the "t" to not get everything built as thumb Jul 29 15:49:09 I agree Jul 29 15:49:17 and that doesn't fix the armv4/t issue, so we still need a real fix for that which would have to be done differently Jul 29 15:49:17 but thats how it is set as of now Jul 29 15:49:31 sure, but I think the current situation is just broken. Jul 29 15:49:53 yes I think these patches should have been toasted a bit Jul 29 15:49:56 before applying Jul 29 15:50:38 armv4 does not have thumb so we should be ok there right Jul 29 15:51:24 right, it's armv4t that is fundamentally busted Jul 29 15:51:25 lumag: I am testing these patches on nslu2be Jul 29 15:51:45 and using thumb mode Jul 29 15:51:46 lets see Jul 29 15:52:15 khem: ok Jul 29 15:53:17 khem: I see you have a linux.inc in nslu2be (between other strange things). Should we fix it and have one in meta-oe? Jul 29 15:53:30 I'll send klibc for meta-oe later Jul 29 15:53:45 khem: regarding armv5te/armv5e/thumb. Maybe it's better to introduce special hook NO_THUMB ?= "no", which can be set to yes by several packages. And then filter out -mthumb if it's set? Jul 29 15:54:07 khem ofc I meant in meta-nslu2 Jul 29 15:54:35 ant_work: yes I this should be updated havent done that Jul 29 15:54:45 ant_work: I will take patches Jul 29 15:55:32 lumag: I think filtering out thumb from TUNE_FEATURES in recipes is satisfactory Jul 29 15:57:24 khem: I think it should be handled in some .conf/.bbclass, depending on variable sent in recipe. Is it what you mean? Jul 29 16:00:40 pb_: hmmm w.r.t. armv4t yeah I think in general how thumb is glued in is probably not right way Jul 29 16:01:04 pb_: thumb should not be tied to tune features here Jul 29 16:01:38 lumag: as I have done it in patch Jul 29 16:02:07 more I think about these arm tune files more broken they look Jul 29 16:03:59 maybe RP will pull a rabbit out of hat Jul 29 16:04:30 (don't see how) Jul 29 16:04:42 heh, seems like that whole rework should have sat on a branch a bit longer Jul 29 16:04:57 sat somewhere, yeah Jul 29 16:05:36 | *** Module name OUT: /local/kergoth/tmp-sb-eglibc/sysroots/x86_64-linux/usr/lib/perl-native/perl/5.12.3/File/Glob.pm Jul 29 16:05:37 | perl isn't executable! Jul 29 16:05:37 | make[1]: *** [install.perl] Error 255 Jul 29 16:05:40 anyone ever seen this one? Jul 29 16:05:52 the perl binary in the directory it was in is executable Jul 29 16:05:56 * kergoth scratches head Jul 29 16:06:00 pb_: TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "thumb", "-mthumb", "-mno-thumb", d)}" Jul 29 16:06:03 is the real problem Jul 29 16:06:43 well, yeah, maybe. I think that line is reasonable on its face, it's how thumb gets into ${TUNE_FEATURES} that is arguably bogus Jul 29 16:06:51 pb_: so we have to have another features called "usethumb" or something Jul 29 16:06:54 and check it as well Jul 29 16:07:13 to some extent it depends on what you define as "tuning". clearly bigendian and thumb are not "tune" flags in the conventional sense but the word seems to have been slightly repurposed here. Jul 29 16:07:17 then thumb would imply that core supports it and usethumb will imply we actually want to use it Jul 29 16:07:42 its configuration more than tuning imo Jul 29 16:08:13 right now we are not differentiating between having thumb and enabling it Jul 29 16:08:20 right Jul 29 16:08:34 we say if we have it just use t Jul 29 16:08:46 and, really, it's only armv4t where it matters. the rest is just configuration flipping. Jul 29 16:08:57 and I think usethumb should be a distro feature Jul 29 16:09:11 yes, it certainly needs to be under distro control Jul 29 16:09:20 pb_: well for armv5t we will still use armv5 for march Jul 29 16:09:27 right, but that doesn't matter Jul 29 16:09:36 not much yes Jul 29 16:09:36 -march=armv5 does allow bx and blx Jul 29 16:09:51 does it? Jul 29 16:09:53 and interworking Jul 29 16:09:59 and will it allow thumb code? Jul 29 16:10:03 lumag: no Jul 29 16:10:31 iirc, bx "works" but only for branching to arm code, it can't actually switch to thumb Jul 29 16:10:39 imo we should be able to use march=armv5te if we know core is armv5te Jul 29 16:10:42 but that's fine, it's enough to build interworking-capable binaruies Jul 29 16:10:46 s/uies/ies/ Jul 29 16:12:27 khem: yeah, though I don't think it makes any practical difference Jul 29 16:12:35 But what about building thumb-default binaries? Jul 29 16:13:01 I mean, I though if we have armv5te, we default to build thumb code by default, aren't we? Jul 29 16:13:10 Right now? Yes. Jul 29 16:15:32 And if we default to armv5 for all armv5te we will default to arm code, weren't we? Jul 29 16:16:05 Yes. I don't quite see what you're trying to say, though. Jul 29 16:18:31 pb_: Did I understood you correctly, that you proposed to make all armv5te cores to select -march=armv5? Jul 29 16:19:07 no, I don't think I was proposing that Jul 29 16:19:34 that would clearly be silly because it would make it impossible to use -mthumb even if you wanted to. Jul 29 16:20:04 I think I did say to khem that, if you weren't generating thumb code, there was no practical difference between -march=armv5 and -march=armv5t Jul 29 16:20:10 pb_: then I'm sorry, I misunderstood you. Jul 29 16:20:17 (but note that armv5 and armv5e are not quite the same thing either) Jul 29 16:20:24 * ant_work remebers the disappoint when taking first figures arm vs. thumb1 on limited devices Jul 29 16:20:42 at one point we moved to thumb Jul 29 16:21:03 what were you disappointed about? Jul 29 16:21:03 no real advantages on pxa25x Jul 29 16:21:18 oh, that's strange. on the openmoko units it was quite a win. Jul 29 16:21:19 slower benchmarks even Jul 29 16:21:27 on zaurus / opie bench Jul 29 16:21:47 same disappoint uclibc vs. eglibc vs. glibc Jul 29 16:21:57 not that big differences Jul 29 16:22:03 in size Jul 29 16:22:22 sure, if you build monster-images it matters Jul 29 16:22:31 strange, I think you must be in some parallel universe Jul 29 16:22:31 heh Jul 29 16:22:55 no, talking about console-images or even initramfs, initially uclibc Jul 29 16:23:12 it was really more buzz than other on Zaurus Jul 29 16:23:32 let me see if I can find my gta01 thumb benchmarks again Jul 29 16:24:43 pb_: maybe I did the size comparison during the unfortunate debug overhaul (-g) Jul 29 16:24:55 couple of years ago Jul 29 16:25:12 khem: with your patch eglibc cannot find ./x86_64-linux/usr/bin/armv4t-oe-linux-gnueabi.gcc-cross-initial/arm-oe-linux-gnueabi-gcc Jul 29 16:25:26 khem: I guess it's looking in ./x86_64-linux/usr/bin/armv4-oe-linux-gnueabi.gcc-cross-initial Jul 29 16:26:17 http://lists.linuxtogo.org/pipermail/openembedded-devel/2008-October/006698.html Jul 29 16:27:14 pb, heh, corgi plugin, really starting on the bad foot :) Jul 29 16:27:28 I'm not sure if I had any newer results than that, those were the only ones I could immediately find in the archives. Jul 29 16:27:46 but, I certainly didn't find it significantly slower Jul 29 16:28:05 and I think a 12% size reduction is something I would count as an advantage Jul 29 16:30:51 I can find only this discussion offhand http://ibot.rikers.org/%23oe/20081201.html.gz Jul 29 16:31:04 about this savings, I found approx 10% for thumb and 30% for uclibc images (console-image even 50%) Jul 29 16:31:52 against glibc/arm Jul 29 16:32:08 so we are there: 10-12% Jul 29 16:32:35 yeah, sounds about right Jul 29 16:37:04 pb_: http://www.mail-archive.com/angstrom-distro-devel@linuxtogo.org/msg02703.html Jul 29 16:47:57 that's why I was disappointed Jul 29 16:54:09 JaMa: yes that patch wont work Jul 29 16:54:49 JaMa: I am testing the patch you posted basically ARM_THUMB_M_OPT = "${@['-mthumb', '-mno-thumb'][bb.data.getVar('ARM_INSTRUCTION_SET', d, 1) != 'arm']}" Jul 29 16:55:18 so we dont have to worry about thumb1 or thumb2 Jul 29 16:57:39 khem: it looks like passing -mno-thumb everywhere :/ just checked expat/run.do_configure.. Jul 29 16:57:56 khem: arm-angstrom-linux-gnueabi-gcc: No such file or directory during eglibc configuration Jul 29 16:58:12 No. eglibc-initial Jul 29 16:58:27 lumag: that's what I reported on ML too Jul 29 16:58:50 lumag: yeah that patch wont work Jul 29 16:59:35 hrm I have those inverted Jul 29 16:59:37 does armv4t override still work? Jul 29 16:59:44 PREFERRED_ARM_INSTRUCTION_SET_armv4t = "thumb" Jul 29 17:00:23 I'm back BTW.. I'm trying to catch up with things now Jul 29 17:00:30 keep on Jul 29 17:00:32 bbl Jul 29 17:02:55 khem: btw in your patch you're appending twice to TUNE_CCARGS :) Jul 29 17:06:27 JaMa: that patch is bogus Jul 29 17:07:05 and _armv4t override no longer works :/ Jul 29 17:07:09 fray: arm tuning neds some attentions Jul 29 17:07:24 it had done multiple fractures for arm Jul 29 17:07:39 I am currently testing few patches which address some of the issues Jul 29 17:07:43 but may not be all Jul 29 17:08:13 fray: currently it has to differentiate between having thumb and using it Jul 29 17:09:12 yes.. Jul 29 17:09:31 It's ARM and no interworking (capable).. ARM and interworking capable and ARM & Thumb are the three combinations right? Jul 29 17:11:11 BTW: if I try to login to patchwork, it says that my account is inactive. How should I fix that? Jul 29 17:14:40 khem, JaMa : eglibc-initial still fails here even after your patch Jul 29 17:15:15 lumag: khem's or mine? Jul 29 17:15:58 It tried to build eglibc-initial in the work/armv5e-angstrom-linux-gnueabi dir (note the lack of t). Is that expected? Jul 29 17:16:14 JaMa, both :) You've sent identical patches IIUC. Jul 29 17:16:16 JaMa: your patch is ok I would have compared != arm Jul 29 17:16:26 lumag: mine is wrong Jul 29 17:16:26 lumag: hmm you still have old khem's old patch? Jul 29 17:16:46 lumag: pop out the old patch yet Jul 29 17:16:49 lumag: you need only 8867 Jul 29 17:17:19 So I should drop 8861? Jul 29 17:17:19 lumag: and be aware of my reply there.. Jul 29 17:17:42 lumag: yes, you have to drop 8861 Jul 29 17:18:38 JaMa, Ok, will try. Jul 29 17:40:01 er.. what the hell is the point of OECMAKE_BUILDPATH. it looks like a lame reimplementation of ${B} Jul 29 17:40:12 hmm Jul 29 17:40:18 I use that Jul 29 17:40:30 B already exists as the way to differentiate between build and source dirs Jul 29 17:40:47 not often used, but its there, and the cd will be done for you as it's listed in the dirs flag of the tasks Jul 29 17:40:58 iirc, anyway Jul 29 17:41:00 kergoth, naext time I play with a cmake recipe, I'll try setting OECMAKE_BUILDPATH to B Jul 29 17:41:10 cool Jul 29 17:41:34 at one point i was trying to default enabling use of separate B for autotools recipes.. i should poke at that again Jul 29 17:41:49 there's some hiccups with recipes that alter the sources with sed, etc and don't operate against ${S} directly.. Jul 29 17:42:00 one of these days Jul 29 17:42:27 does anybody know of an OpenEmbedded-based distribution that uses X.org, Qt and OpenGL on x86 machines? Jul 29 17:43:38 okay,this is weird. i have a perl do_install failure that occurs every time i run the task, but if i drop into a devshell and source the run script, it succeeds Jul 29 17:43:42 * kergoth wipes and tries again Jul 29 17:58:28 kobe_: look around in angstrom Jul 29 17:58:40 kobe_: all those bits can be put together in an image for sure Jul 29 17:58:56 qte4-x11-image or something Jul 29 18:04:03 kergoth: fwiw, I think some of the OECMAKE_BUILDPATH stuff being lame is because cmake is kinda lame :( Jul 29 18:04:21 Tartarus: perhaps, but afaict all it does is a cd in configure/compile, same thing B does Jul 29 18:04:23 * kergoth shrugs, will see Jul 29 18:04:28 hmm Jul 29 18:04:42 this perl thing is reliable. fails every time in do_install, works every time from devshell Jul 29 18:05:03 yeah, I just don't know if it's an always obeyed kind of thing Jul 29 18:05:06 the odd thing is re-running do_install from bitbake keeps failing, its not a race Jul 29 18:05:12 gtg now, bye! Jul 29 18:05:18 must be something different contextually between the two Jul 29 18:05:19 hmm Jul 29 18:06:44 khem: eglibc compiled on xscale (armv5te) Jul 29 18:06:48 can't be pseudo, its handled the same for all tasks.. Jul 29 18:06:49 hmm Jul 29 18:07:05 lumag_afk: cool Jul 29 18:36:27 Will doing a bitbake -c configure -f for a recipe also invalidate compile and install stages so that they're redone next time I bitbake? Jul 29 18:37:22 yes it would Jul 29 18:43:28 ok, thanks Jul 29 18:59:16 mickeyl, ping Jul 29 19:15:44 Crofton: pong Jul 29 19:15:52 Crofton: shall we make our ad-hoc meeting now?= Jul 29 19:16:33 Maybe should wait until next week, no sign of florian Jul 29 19:16:42 hmm, ok. Jul 29 19:16:42 I need to run out also Jul 29 19:16:47 k Jul 29 19:35:37 What's the easiest way for me to install the output (binaries) of a recipe to a root-fs without having to opkg install the many ipk packages it generates? Jul 29 19:36:17 well, that's pretty darn easy Jul 29 19:36:23 but, ipk can be extracted w/ ar -x Jul 29 19:36:23 Would rsync'ing the contents of work/../image be ok ? :) Jul 29 19:36:27 or whatever the dpkg unpack tool is Jul 29 19:36:38 ok for what? Jul 29 19:36:46 images are created w/ a 'fake root' method Jul 29 19:36:47 s/ok/correct Jul 29 19:36:53 so you can't use them on the target Jul 29 19:36:58 as perms will be all wrong Jul 29 19:37:05 recipe generates too many ipks Jul 29 19:37:23 why do you say that? Jul 29 19:37:28 many ipks are good Jul 29 19:37:34 it means fine grained control on the target Jul 29 19:38:00 I might be missing something here, but is it harder to opkg install alot of ipks individually Jul 29 19:38:10 *isnt Jul 29 19:39:48 Well, it's optional bits in the other packages Jul 29 19:40:05 Can you step back and describe the high level problem you're trying to solve, please? Jul 29 19:40:17 sure Jul 29 19:40:57 Let me take an example, there's a recipe for example 'gst-plugins-good_0.10.28.bb' Jul 29 19:41:12 and rebuilding it generates a lot of "gst-plugin-*" recipe Jul 29 19:41:12 joelagnel: why would you want to install all the ipks from a recipe? you really need development files, debugging, documentation.. it makes no sense Jul 29 19:41:24 does it not also emit a virtual package which depends on all of those? Jul 29 19:41:25 kergoth, for quick testing Jul 29 19:41:26 most such recipes do Jul 29 19:42:19 kergoth, what is it called typically Jul 29 19:42:33 that depends on the recipe Jul 29 19:43:18 I'm just not seeing the use case here. If you're testing things specifically, then you kn ow what you're testing. If you aren't, you don't need them all. Jul 29 19:44:26 kergoth, ok I describe my usecase Jul 29 19:44:56 I upgraded libv4l2 and rebuilt it, now I need to rebuild and install all dependent gstreamer plugins Jul 29 19:45:43 rebuilding is fine, but I was thinking of an easier way to install them all at once onto my root filesystem Jul 29 19:45:48 does that make sense? Jul 29 19:47:58 (hope it does) Jul 29 19:49:38 still not seeing why you need to install them all. wouldn't you just need to install the ones you already have installed? Jul 29 19:49:47 in which case a shell script + opkg list is your friend Jul 29 19:52:56 kergoth, sure that seems reasonable Jul 29 19:53:27 * kergoth shrugs Jul 29 20:00:41 re pb Jul 29 20:13:19 pb_: hmmm so now we have the image creation problemyou commented on that Jul 29 20:14:14 Unknown package 'opkg'. Jul 29 20:24:57 khem: oh, hm. I haven't heard of that exact failure. Jul 29 20:25:00 hi woglinde Jul 29 20:26:59 Hello Jul 29 20:27:25 hi lumag Jul 29 20:28:22 I got it to work now, thanks all for help Jul 29 20:31:08 joelangel what? Jul 29 20:31:26 Hmmm. Why eglibc builds packages for armv5te (in my case) but installs data in machine sysroot? Jul 29 20:33:00 If it's by design or it's again some misbehaviour? Jul 29 20:33:36 lumag: sysroot is denoted using machine-libc Jul 29 20:33:47 lumag: that should be fine Jul 29 20:35:44 I quite don't get it. I'm building a eglibc package which is not machine specific. It builds lots of arch packages. Then why populate machine sysroot? Won't it be logical to populate arch sysroot? Jul 29 20:36:13 lumag: actually there is one sysroot per machine Jul 29 20:36:28 and common packages will get populated from sstate Jul 29 20:36:48 so if you were to say have two machines which both have xscale Jul 29 20:37:08 then it would build the packages once and populate them into two sysroots Jul 29 20:37:22 machA and machB Jul 29 20:37:42 but they will be built only once Jul 29 20:38:11 Hmm. I remember that when I asked to build packages first for tosa and then for c7x0, eglibc (and some other packages) were rebuilt. Jul 29 20:38:18 I'll retry this now just to be sure. Jul 29 20:38:33 if they are common at arch level they should not be rebuilt Jul 29 20:38:41 but if they have machine specific stuff Jul 29 20:38:43 then they will be Jul 29 20:40:07 lumag: in oe-dev only collie was needing toolchain rebuild. this is expected behavior I'd say Jul 29 20:40:38 ant__: that's logical, as collie is armv4 Jul 29 20:40:59 yes, when I built for the pxa devices same toolchain was used Jul 29 20:41:50 ahem.. is there any floating patch for eglibc in the meantime? Jul 29 20:42:01 ant__: yes there are Jul 29 20:42:35 * ant__ reading ML Jul 29 20:55:14 That's strange. I asked OE to build eglibc for c7x0 and it actually recompiled something. At least I saw it rebuilding eglibc and gcc at least Jul 29 20:57:03 I had eglibc built for tosa. And now I asked bitbake to build eglibc for c7x0. And I actually see it rebuilding gcc-cross-initial now. Jul 29 20:59:13 eglibc indeed seems to be unpacked from sstate. Jul 29 21:14:37 but gcc was rebuilt Jul 29 21:21:44 lumag: c7x0 is xscale ? Jul 29 21:22:06 yes, pxa25x Jul 29 21:23:16 where is .conf file for machine Jul 29 21:23:21 in layers Jul 29 21:23:29 meta-zaurus Jul 29 21:23:45 in meta-smartphones Jul 29 21:25:57 lumag: so its xscale le ? Jul 29 21:27:28 khem: yes. Both are pxa25x xscale le Jul 29 21:27:41 khem: otherwise I won't use them for this testing. Jul 29 21:27:47 lumag: then they should be able to share the toolchain Jul 29 21:28:41 it does checksumming and if it sees differences it might rebuild but generally it should not Jul 29 21:29:11 lumag: btw. oe-core should be buildable for arm now Jul 29 21:29:40 *g* Jul 29 21:29:44 this is cobblework we have to fix the tune for arm once again Jul 29 21:30:25 I've launched a rebuild with the last patches Jul 29 21:39:35 khem: thanks. BTW: why does your patch for features-arm-thumb adjust TUNE_CCARGS twice? Jul 29 21:40:07 lumag: that patch was bogus Jul 29 21:40:28 khem. oops. interpreted diff in the wrong way. Jul 29 21:40:37 sorry Jul 29 21:41:30 btw: i still see no patch for the intltool for perl (command line too long in virtclass-native case). Jul 29 21:41:53 Ah. It wasn't submitted to oe-core ML. Jul 29 21:44:49 for the thumb stuff on arm.. please see the emails I an Phil Blundell sent today Jul 29 21:58:09 JaMa|Off: ping Jul 29 22:10:17 khem: util now build is fine. armv5te everywhere Jul 29 22:10:24 khem: something seem wrong here. I've built eglibc for tosa, then built eglibc for c7x0. Now I asked to build gcc for tosa and bitbake started rebuilding eglibc again! Jul 29 22:10:43 heh Jul 29 22:11:16 btw I've targeted poodle to mix up the dogs a bit :) Jul 29 22:11:29 lumag: hmm rm_work ? Jul 29 22:12:01 khem: yes. Angstrom setup-scripts. Does it mess things? Jul 29 22:12:38 lumag: it did in the past but I thought we fixed it Jul 29 22:13:16 fray: in your mail does 'interworking-capable chips' cover plain armv4 (no thumb) scripts Jul 29 22:13:22 ? Jul 29 22:13:45 khem: I can try checking things w/o rm_work, but later. Jul 29 22:14:21 I'll probably have to do a full rebuild, or just disabling rm_work will do the trick? Jul 29 22:14:53 the Phil's response covers that and I responded back about supporting non-thumb compatible armv4's.. Jul 29 22:14:58 are there any new ones being built? Jul 29 22:15:13 lumag: here arm-angstrom-linux-gnueabi-gcc -march=armv5te -mno-thumb -mthumb-interwork -mtune=xscale -mthumb-interwork -mno-thumb --sysroot= Jul 29 22:15:22 as you said Jul 29 22:15:36 ok Jul 29 22:15:54 twice Jul 29 22:16:03 if there are no new designs on armv4 (no thumb capable).. then does oe-core need to support them? (I lean toward no).. current oe does.. any a distro based on oe-core can add their own tunings that don't have thumb interworking and such for non-armv4 thumb cpus.. Jul 29 22:16:17 lumag, that was eglibc Jul 29 22:16:20 to me it all comes down to build/support expectations and costs of maintenance Jul 29 22:16:34 fray: there are lot of oe-users who use strongARM based systems Jul 29 22:17:04 fray and many of them are oe developers Jul 29 22:17:08 yes.. but do we need a strong arm tune in oe-core, or can it be external -- or will those users want to stay on the OE they're already using? Jul 29 22:17:32 even meta-oe can have a strong-arm tune.. its oe-core I'm concerned with Jul 29 22:17:36 I dont mind where it stays as long as oe-core facilitate it Jul 29 22:17:57 ideally its better suited in oe-core Jul 29 22:18:03 since its a core piece Jul 29 22:18:06 fray: I don't say that one should support _everything_, but supporting StrongARM seems logical to me. That's still one of the 'lowest common' platforms in use. Jul 29 22:18:09 I don't know why it can't be facilitated in oe-core -- but actually having non-thumb iterwork in oe-core is where I'm concerned Jul 29 22:18:42 lumag, in my world (mostly commerical products) we havn't seen strongarm in many years.. the "oldest" designs are 920t based Jul 29 22:19:04 the occasionaly 920t seems to still crop up.. but it's about 1 or 2 a year.. Jul 29 22:19:33 thats why I question the need (in oe-core, not in distributions based on oe-core) for strongarm and other non-interwork compatible chips Jul 29 22:19:36 khem: here eglibc did build Jul 29 22:19:38 fray: as I said Jul 29 22:21:16 there are people who have feeds build on oe for these devices Jul 29 22:21:17 fray: there are no real non-interwork compatible chips, I think. Jul 29 22:21:34 new products no Jul 29 22:21:40 but oe, as a distribution is oe-core + meta-oe Jul 29 22:21:45 lumag: you're working on a collie (strongarm) qemu emulation, isn't? Jul 29 22:21:52 oe-core is a "distribution-less" base (self contained though) Jul 29 22:22:46 ant__, kind of. I provided basic support for StrongARM cores (some coproc instructions not finished yet) and basic device set to get kernel to boot till "Can't mount root". Jul 29 22:22:50 fray the tune logic is ok largely Jul 29 22:22:58 we can tweak it for armv4 and armv4t Jul 29 22:23:01 a bit Jul 29 22:23:31 hm..khem... eglibc did build but failed do_install... lemme see Jul 29 22:23:35 so what I would expect at this point is something like armv4t and armv4t_thumb (tune names)..... Jul 29 22:23:46 the _thumb one would enable thumb instructions by default Jul 29 22:23:50 fray: yes Jul 29 22:24:00 they both would honor the arm_instruction_set as an override.. Jul 29 22:24:08 ant__, when I'll build the rootfs, I'll try to implement more devices/etc. Jul 29 22:24:09 although I am not totally conviced by identifying thumb Jul 29 22:24:13 in packages Jul 29 22:24:16 I prefer that the output pkgarch though be identifiable Jul 29 22:24:17 since they can be so mixed Jul 29 22:24:41 I just havn't seen the code mixed in packages.. hand optimized applications -- sure.. just not recipe/packages level Jul 29 22:24:43 fray there are static libs which are in ARM and they link into some binary which is thumb Jul 29 22:24:49 what would oyu call it ? Jul 29 22:25:04 eglibc is build arm Jul 29 22:25:08 khem, well recent changes to the system have made it that you'll be able to build w/o any static libs.. :P Jul 29 22:25:10 libgcc is built arm Jul 29 22:25:15 libgcc.a goes into everything Jul 29 22:25:29 you cant avoid libgcc.a Jul 29 22:25:33 yes.. but whats the default on the system? Jul 29 22:25:37 with latest gcc Jul 29 22:25:43 argh.. why do I get linux-3.0+3.1rc-h ?? Jul 29 22:25:51 so having thumb in package names is misnomer\ Jul 29 22:27:04 fray: people might think its completely thumb code which wont be true Jul 29 22:27:40 the -recipe- is thumb code.. Jul 29 22:27:47 the executables are mostly (if not all thumb).. Jul 29 22:27:54 packages arent recipes Jul 29 22:28:01 recipes -> packages Jul 29 22:28:19 khem: eglibc is sane, some other issue pulls now linux 3.0 iun my build... Jul 29 22:28:27 how so ? when they link a static lib which is arm Jul 29 22:28:41 ERROR: Task 612 (/oe/setup-scripts/sources/meta-texasinstruments/recipes-kernel/linux/linux_3.1.bb, do_fetch) failed with exit code '1' Jul 29 22:28:49 why are the static lib arm? Jul 29 22:29:04 (other then libgcc and libc.a) why are we linking static libs Jul 29 22:29:12 libgcc can not be built thumb e.g. Jul 29 22:29:19 it has catch 22 Jul 29 22:29:33 where gcc ask for a ligbcc function Jul 29 22:29:39 when building libgcc Jul 29 22:29:45 then there is no way to build a "different" armv4_thumb binary.. Jul 29 22:30:11 point is I want information in the arch to tell me what the thing is I'm looking at, so I can make smart decisions based on it Jul 29 22:30:27 I understand that Jul 29 22:30:28 so if libgcc can't ever be thumb.. then it won't matter,, Jul 29 22:30:55 libc_shared.a (I think thats the libc chunk) can be compiled thumb in some circumstances.. this is the only outlier that I know of Jul 29 22:31:04 other static libs become distro specific.. I'm not worried about those.. Jul 29 22:31:30 hmmm. klibc? Jul 29 22:32:14 each libc is different for this.. Jul 29 22:32:28 fray lets have armv4 armv4t_thumb armv4t armv5 armv5_thumb and so on Jul 29 22:33:02 so we're in general agreement at least on the names and interworking is enabled in all cases (except armv4) Jul 29 22:33:03 so 't' remains with the arm arch as it is and packageness is denoted with _thumb Jul 29 22:33:14 yeah Jul 29 22:34:28 or may be armv4t_t1 Jul 29 22:34:51 and armv7_t2 armv7_t1 armv7 Jul 29 22:35:13 AFAIK, nobody would every do an armv7_t1 Jul 29 22:35:24 althogh I would have preferred a single letter Jul 29 22:35:41 like t e h etc Jul 29 22:35:53 armv4tt Jul 29 22:36:09 doesnt sound bad just like a typo Jul 29 22:37:11 khem: somehow the TI kernel recipe spreads everywhere even with DEFAULT_PREFERENCE = "-99". Lacks COMPATIBLE_MACHINE = "(beagleboard)" Jul 29 22:37:32 linux_3.1.bb Jul 29 22:37:46 ant__: you have to lock kernel for your machine Jul 29 22:38:00 then it wont hit you Jul 29 22:39:10 I see, I guess the recipe was not intended to behave like that, anyway Jul 29 22:40:46 from the scroll: WARNING: For recipe libgcc, the following files were installed but not shipped in any package: Jul 29 22:40:46 WARNING: /usr/lib/arm-angstrom-linux-gnueabi/4.5.4/libgcov.a Jul 29 22:41:50 that should be rm -rf'ed Jul 29 22:42:14 mhm Jul 29 22:43:17 anyway, I'll work on a revised ARM set.. but I'm not yet sure when I'll get to it.. :( Jul 29 22:44:13 fray: I think what we have right now is workable so there is some respite Jul 29 22:44:37 ok Jul 29 22:47:17 ant__, did you understand, how to disable ti linux? Jul 29 22:48:45 yes, set compatible_machine Jul 29 22:48:55 like in linux_3.0.bb Jul 29 22:49:40 Thanks. However I can't understand, why it's selected despite DEFAULT_PREFERENCE being -99 Jul 29 22:50:03 he Jul 29 22:50:21 because its the highest version I guess Jul 29 22:50:48 for your virtual/kernel Jul 29 22:50:50 hm..should have happened with e.g. linux_git thgen Jul 29 22:51:16 So it will be supported for beagle no matter of DEF_PREF? That's strange. Jul 29 22:52:02 s/supported/selected/ Jul 29 22:59:34 DEFAULT_PREFERENCE in the recipe has lower priority than PREFERRED_VERSION Jul 29 22:59:57 at least, it was like that Jul 29 23:01:13 lumag: anyway, within a couple of weeks and we'll have the missing 3.1 defconfigs ;) Jul 29 23:02:06 after do_savedefconfig I don't expect many changes btw 2.6.39 and 3.1 Jul 29 23:03:48 ant__, that still doesn't tell me why that recipe was selected. Jul 29 23:04:26 the issue iare the layers Jul 29 23:04:43 you have to imagine it flattened Jul 29 23:05:05 but yes, default preference case is strange Jul 29 23:05:21 w/out setting pref. vers. Jul 29 23:06:29 in the past there was a note about the many virtual/kernel providers when we still had 2.4 cruft Jul 29 23:06:51 now it doesn't see any conflict, it's all 'linux' Jul 29 23:07:40 in the past I disliked having preferred_version for linux/u-boot, as chaging versions there would mean long reparsing of all recipes Jul 29 23:12:11 true Jul 29 23:12:54 well, I see lot of warnings unpackaged file scrolling... :/ Jul 29 23:13:20 this is console-image (Angstrom) Jul 29 23:14:32 0ur QA task-force will take care Jul 29 23:16:27 I remember from some university course, that QA errors either are fatal, or are ignored. Jul 29 23:16:45 ^_^ Jul 29 23:18:06 glib2, gtk+, ... Jul 29 23:23:01 avahi Jul 29 23:49:37 lumag: rebuilding now poodle->c7x0 Jul 29 23:49:45 ant__, :) Jul 29 23:49:56 I'm logging to see what rebuilds Jul 29 23:56:47 wow, anything is getting rebuilt for the moment Jul 29 23:59:20 only machine-specific Jul 30 00:01:23 khem said that this can be related to rm_work, but I don't want to test this now. Jul 30 00:01:48 Maybe I'll run this as a stress test on my new work box during weekeng. Jul 30 00:03:50 second image finished. that was fast Jul 30 00:04:31 we'll have to unbind klibc from kernel headers so will not be machine specific anymore Jul 30 00:05:22 did you get gcc* rebuilds? Jul 30 00:05:33 no Jul 30 00:06:02 strange Jul 30 00:06:16 check timestamps please Jul 30 00:08:01 do you have signatures enabled? Jul 30 00:09:10 I see only setscene activity Jul 30 00:09:39 strange. Jul 30 00:10:16 I see it compiled only once, one hour ago Jul 30 00:10:39 I have default machine in conf/auto.conf and I specify MACHINE on command line. And you? Jul 30 00:10:55 ah, I set in both files by hand Jul 30 00:11:10 both? Jul 30 00:11:12 in auto.conf and local.conf Jul 30 00:11:16 hmm. Jul 30 00:11:34 you use angstrom? Jul 30 00:12:12 yes Jul 30 00:13:12 let me make a tarball of the logs Jul 30 00:14:49 longest to rebuild were kernel and klibc Jul 30 00:19:17 http://www.filedropper.com/gcc-crosstar Jul 30 00:20:47 bah..seems mangled Jul 30 00:21:31 Forget it. I don't really have will to dig _that_ deep into sstage/rebuild internals for now. Jul 30 00:21:38 lumag: http://www.filedropper.com/gcc-cross Jul 30 00:22:02 I restarted from scratch Jul 30 00:22:36 maybe is an incremental build issue Jul 30 00:24:29 I've now tosa as target Jul 30 00:24:38 It's funny, you have MULTIMACH_TARGET_SYS variable there and I don't. Jul 30 00:25:07 pls ./oebb.sh update or git pull the sources Jul 30 00:25:13 That's just one of the differencies I've spotted Jul 30 00:26:20 Sorry, checked the wrong file. Jul 30 00:26:28 I'm using the latest sources. Jul 30 00:26:40 ok, after khem patches Jul 30 00:26:52 I built vanilla Jul 30 00:28:00 btw http://paste.debian.net/plain/124555 Jul 30 00:28:17 (for console-image) Jul 30 00:31:03 Yes, I've seen those messages. Don't know if they are important. Jul 30 00:32:17 ok, same for tosa Jul 30 00:32:20 gcc-cross-initial-4.5-r39.0+svnr175127.do_package_setscene.tosa Jul 30 00:32:28 gcc-cross-initial-4.5-r39.0+svnr175127.do_populate_sysroot_setscene.tosa Jul 30 00:32:42 just those Jul 30 00:32:53 Something is probably wrong with my setup. I see different settings for c7x0 and tosa in my siginfo files. Jul 30 00:35:57 Still building tosa image here Jul 30 00:38:14 ok, too late to test images now Jul 30 00:38:18 good night Jul 30 00:40:19 night! **** ENDING LOGGING AT Sat Jul 30 02:59:56 2011