**** BEGIN LOGGING AT Wed May 14 02:59:57 2008 May 14 06:25:57 morning May 14 07:08:49 gm May 14 07:14:11 03koen 07org.oe.dev * r03ca49b1... 10/ (1 conf/distro/angstrom-2008.1.conf): angstrom 2008: prefer gcc csl 2008q1 for armv7a, gcc 4.3.0 just ICEs way too often May 14 07:41:11 03rwhitby 07org.oe.dev * re07d1d11... 10/ (7 files in 5 dirs): linux-ixp4xx: Updated to 2.6.24.7 as the default version May 14 07:45:49 hi May 14 09:03:45 good morning May 14 09:04:39 Did I mention that we will be next to T2 at LinuxTag? May 14 09:04:46 yup May 14 09:05:01 you said something about brining chainsaws I think May 14 09:05:24 * florian can't remember - too much of confusion here May 14 09:05:28 florian: who's T2? May 14 09:05:47 loud mouthed buildsystem rivals May 14 09:05:47 dcordes: oe-- ;) May 14 09:06:13 * XorA wont be at linuxtag to see the war May 14 09:06:15 XorA: rivals? lol May 14 09:07:09 they were a PITA on #openmoko May 14 09:07:22 Currently I would vote for a combination of suits, printed flyers and one press release at least :) May 14 09:07:34 florian: don't know any buildsystem rival to OE that has four letters and begins with oe May 14 09:07:41 :( May 14 09:08:02 XorA: Rene? May 14 09:09:42 XorA: Could you send me a new SSH public key for access to monotone on opensource, please? May 14 09:10:04 broonie: a new one? May 14 09:10:56 The OpenSSL vulnerability - the keys currently in there look to be generated with an affected OpenSSL. May 14 09:11:22 http://wiki.debian.org/SSLkeys May 14 09:11:39 shit that bug has been in longer than I thought then May 14 09:11:42 over 2 years May 14 09:11:49 Yeah, it's ancient May 14 09:11:53 Oh, hang on. May 14 09:12:02 gg-desktop is your old Wolfson desktop, isn't it. May 14 09:12:06 yes May 14 09:12:17 dp@cimmeria is my key May 14 09:12:29 yeah wolfson desktop was ubuntu so would suffer :-) May 14 09:12:39 Yup, and that reports as OK. May 14 09:13:59 Sorry about the false alarm. May 14 09:14:38 broonie: no hassles, better to be sure May 14 09:19:47 only 16 bits of entropy, ouch May 14 09:20:11 means every 8 keys will collide May 14 09:20:21 every 2^8 May 14 09:39:08 Yeah. Someone on #debian-de generated 1000 keys then another 50, finding rather a lot of collisions. May 14 09:40:56 heh heh all fun and games May 14 10:06:00 morning May 14 10:08:56 morning :) May 14 10:09:30 are there any guidlines on adding commits to the bugtracker? I have a diff with a new pack May 14 10:19:44 dcordes: I think we like the output of mtn diff . best. May 14 10:40:33 hi marex May 14 10:41:05 hi woglinde May 14 11:04:40 re May 14 11:05:02 likewise: I already have the according mtn diff just wonder if there is anything I have to take care of filing the bug May 14 11:05:40 dcordes: not that I know. if so, we'll let you know. May 14 11:39:02 morning May 14 11:51:05 * * OE Bug 4260 has been created by lukas.gorris(AT)gmx.de May 14 11:51:07 * * new package i2c-tools May 14 11:51:09 * * http://bugs.openembedded.net/show_bug.cgi?id=4260 May 14 12:11:15 Laibsch: thanks for the hint. diff added May 14 12:55:04 * * OE Bug 4261 has been created by jin(AT)mediatomb.cc May 14 12:55:07 * * meta-toolchain for uclibc does not add linux-libc-headers to the toolchain package May 14 12:55:09 * * http://bugs.openembedded.net/show_bug.cgi?id=4261 May 14 13:06:09 hmm, I wonder if it is actually worth submitting bugs vs. oe.stable, if I am required to send stuff to the stable-ml anyway? May 14 13:06:20 which then means that if my patch is accepted I can close the bug myself too :> May 14 13:14:21 Jin^eLD: we want the commits simply to be ack-ed by 2 someone elses to prevent simple mishaps - maybe the threshold is too high, but it's a start. May 14 13:15:45 likewise: but how is that (or - is that) related to the bugtracker? May 14 13:16:29 i.e. is there a point in opening a PR in bugzilla if I anyway send something to the ml? May 14 13:17:06 from what I understand the .stable guys do not look at bugzilla anyway, or am I wrong there? May 14 13:17:12 it all got somewhat confusing :) May 14 13:17:22 Jin^eLD: well, a bug in .stable is probably already a bug item (for .dev) or vice versa, a bug in stable might need a fix in .dev as well May 14 13:17:24 It might be helpful to others if they're likely to run into the same thing. May 14 13:17:50 fixes for stable go through the mailing list. (same as the linux stable tree, btw). May 14 13:17:58 as old time OpenZaurus branch maintainer I want to say one thing. May 14 13:18:03 morning May 14 13:18:04 ;) May 14 13:18:09 hey hrw :) May 14 13:18:14 likewise: but who is supposed to close the bug? May 14 13:18:23 whoever commits it May 14 13:18:23 hrw: That's your one thing? :) May 14 13:18:27 there are few types of changes for stable branch May 14 13:18:42 1. bugfix backported from .dev (most of them) May 14 13:18:59 2. bugfix for .stable not applicable to .dev (some) May 14 13:19:06 3. bugfix for .stable applicable to .dev (some) May 14 13:19:27 4. new stuff present in .dev wanted in .stable May 14 13:19:47 1 & 4 goes into one direction: .dev -> .stable May 14 13:19:58 3 goes .stable -> .dev May 14 13:20:04 2 stay in .stable only May 14 13:20:24 most of people think only about 1 & 4 types May 14 13:20:46 but type 3 is often forgotten when it should not be. type 2 is other thing May 14 13:21:24 well, 3. is probably forgotten because the one who wants a fix wants it for the branch he is working on, and then there is noone who will have a look if the same bug is present in the other branch May 14 13:24:50 such person should also send fix to .dev May 14 13:25:03 if device for which patch is exists in dev May 14 13:52:39 but Jin^eLD is raising a valid point. The one I tried to raise in the ml (unsuccessfully, I guess I am to blame, though) May 14 13:52:51 how does the bug tracker fit into that framework May 14 13:53:06 likewise: I understand the policy and respect it May 14 13:53:22 If you guys are comfortable with taking the decisions on the ml, perfect! May 14 13:54:01 I am *very* unconfortable with the way the bug tracker has been completely left aside for the past couple of months May 14 13:54:36 This raises the question for Jin^eLD and me (and everybody else) how they should see the bug tracker as it fits into .stable processes May 14 13:54:37 Laibsch: I am not confortable with everything as well. I wish it is enough to just say: be careful when committing to stable, don't break it for anyone else. May 14 13:54:55 Right now it is "if you report a bug in .stable in the BTS, it will rot to hell" May 14 13:54:58 Laibsch: basic rule: bugtracker can be used to report bugs, attaching patches etc. but final patch has to land on ML May 14 13:55:14 hrw: That is what I was proposing May 14 13:55:15 Laibsch: I liked the idea of the bugtracker flag (I only tried it yesterday), but I like a mailing list better. May 14 13:55:37 hrw: but it was rejected or only if somebody plays human gateway May 14 13:55:41 Laibsch: find someone to pay for .stable maintainer and then you will have what you want May 14 13:55:54 hrw: and if the .stable guys want a human gateway, it should be one of them, not me May 14 13:55:55 hrw: not even then. May 14 13:56:14 Laibsch: but in the end, there is always some human gateway; the one who decides to commit. May 14 13:56:26 Laibsch: I feel that you would like .stable to be like it was with .oz354x when I looked at bugtracker from time to time to check what is going on May 14 13:56:37 likewise: the flag automatically triggers a mail to the stablebranch ml (just like you guys want), but the mail is rejected May 14 13:56:38 Laibsch: and .stable developers decided that ML is the only place May 14 13:57:07 * hrw do not want to discuss that subject again and again and again May 14 13:57:11 ah - and again May 14 13:58:21 hrw: no, I don't even remember the oz354x processes, that was before my time May 14 13:58:26 Laibsch: ok, well, I don't even have a ml admin passwd or such, and I don't know sh*t about our infrastructure, so even if I wanted to help, I have no clue where to begin. As I said, yes, I think having a stable is good, and I will do my part when I start using it. I find it hard to make time now, unfortunately... May 14 13:59:26 likewise: Sorry, I was under the impression you already did some basic work in .stable May 14 13:59:41 if that is not the case, I guess I was barking up the wrong tree May 14 14:00:16 likewise: You have two human gateways now May 14 14:00:49 The second one is taken care of, the first one not, which is why stuff flows into the bts for .stable but _never_ flows out of it. May 14 14:01:03 Laibsch: I proposed to work on maintaining "it", without knowing what the stable branch would begin with. May 14 14:01:26 Laibsch: As it began with the angstrom-stable tree, it was too old for my own purposes (using it at work). May 14 14:01:48 Laibsch: if we started with something newer, things might be different from my perspective. May 14 14:02:03 you mean, you'd be more motivatd? May 14 14:02:38 I can understand that, but for good reasons, I don't think that is going to happen nor should it, as koen rightly pointed out May 14 14:03:23 Laibsch: I just hope we have enough .devs (in the LONG term) on some newer .stable so that maintainance is not endangered. I agree with koen on most points, also because he has the most experience with angstrom in this. May 14 14:04:15 Laibsch: yes, more motivated, as I then have to spend my time only once, not twice. May 14 14:04:16 I do too May 14 14:04:27 I have one single disagreement May 14 14:04:32 but an important one May 14 14:05:23 Laibsch: which one exactly, politics aside? May 14 14:05:24 there should be at least some stuff being flushed from the bts from time to time. instead, additional barriers are erected. May 14 14:05:49 Laibsch: agreed, maybe a stable fix-up weekend helps. Not that summer period helps, but we could try once. May 14 14:05:49 likewise: I don't appreciate people always attributing my initiatives to politics May 14 14:06:31 It should be clear that although I may be annoying, my points have merit. One can disagree, but I argue based on facts and factual problems May 14 14:07:19 Laibsch: Agreed and sorry for my preemptive remark. May 14 14:08:28 lol, cat pressed all the wrong keys then neatly deleted the garbage text May 14 14:09:01 good kitty! May 14 14:09:08 cleaning up after itself May 14 14:09:11 way to go May 14 14:09:13 :-D May 14 14:09:19 1``````iooooooooooi9 she now says May 14 14:09:31 which means: I'm irritating, need food! May 14 14:09:39 I thought it should be more like PURRRRR May 14 14:09:43 not? May 14 14:11:52 Laibsch: no purrr is after food May 14 14:12:43 oh, yes forgot that May 14 14:13:02 most cats know very well about how to motivate their owner May 14 14:13:09 Laibsch: http://www.esrac.ele.tue.nl/~leon/food.avi May 14 14:13:09 s/motivate/drill/ May 14 14:13:27 Laibsch: yup mine headbutt me around 6am May 14 14:14:07 likewise: beautiful little kitty May 14 14:14:25 * Laibsch likes her May 14 14:14:25 chouimat|away: well, we keep the door closed since recently, saves us 1 or 2 hours in the morning May 14 14:15:31 likewise: if I do this mine will kill another toilet paper roll May 14 14:15:42 she's one-eyed May 14 14:16:16 my mate's got a citler!! May 14 14:17:31 http://www.catsthatlooklikehitler.com/kitler/pics/kitler2129.jpg May 14 14:17:33 dcordes: I had to look that up. But ok, black mustache I presume? May 14 14:18:47 How does the Handhelds rebuild project relate to OE? They criticize us for not-enough-packages, then they take the native compile approach. http://www.celinux.org/elc08_presentations/ May 14 14:19:15 fsck all this I'd switch to t2!!! May 14 14:19:50 did someone take a good look at T2, btw? May 14 14:20:42 yes of course. I heard about them earlier in a post on the OM planet May 14 14:20:58 t2 spreads fud or something read their article, know them May 14 14:21:47 but atleast they have pr people ;) May 14 14:25:52 I'ld like to upgrade our PR as well. May 14 14:26:04 Starting with a more attractive web site. May 14 14:29:18 hh.org still has some life left? May 14 14:29:34 I thought absolutely everybody had dropped it May 14 14:38:57 hrw: we also do. I'm pr you just don't know it May 14 14:39:20 you can't count the people I molest with OE May 14 14:41:07 dcordes: "grep OpenEmbedded -i http://linuxdevices.com/ | wc -l" < "grep T2 -i http://linuxdevices.com/ | wc -l" May 14 14:41:20 example of PR actions May 14 14:44:03 that's a big quest to me May 14 14:44:33 the first part counts the lines containing OE in linuxdevices? May 14 14:46:33 dcordes: whole line says "there is more T2 then OE on linuxdevices" May 14 14:46:52 dcordes: s/T2/MontaVista or other embedded solution provider? May 14 14:47:59 I do not use linuxdevices May 14 14:48:06 no idea what's going on there May 14 14:50:00 who did the axfs tests under OE? http://www.celinux.org/elc08_presentations/ has this nice AXFS presentation. want in OE. May 14 14:53:39 What do you guys think about the approach handhelds mojo is taking? May 14 14:53:47 I thought it was interesting May 14 14:54:03 completely different approach May 14 14:54:08 * Laibsch wonders about the outcome May 14 14:55:02 Laibsch: did you recheck my commit with the .bb attached? May 14 14:55:30 no May 14 14:55:32 not yet May 14 14:55:34 maybe later May 14 14:56:05 i2c tools is quite a useful thing for OE I guess May 14 14:56:07 Laibsch: mojo is interesting, but for embedded work, I need a system where I can re-compile an easily customize a complete disto easily on any workstation. Setting up fragile native build environments probably won't cut it. May 14 14:57:16 Laibsch: even scratchbox fails in that regard. May 14 14:59:51 dcordes: I'll look at it May 14 15:00:02 but having the bb in OE is just the first step May 14 15:00:15 It needs to be maintained and distros need to pick it up May 14 15:00:15 Laibsch: what do you mean, just the first step? May 14 15:00:24 see two following lines May 14 15:00:30 one following line May 14 15:00:36 sorry May 14 15:00:40 with two more things that need to be done May 14 15:00:50 we sent the lines at the same time May 14 15:04:35 dcordes: bb file itself looks good May 14 15:04:41 I'll try a compilation May 14 15:05:10 cool thanks May 14 15:05:25 as I pointed out in the comment armv4t and armv5te build May 14 15:05:33 cbrake: from a distribution and user POV it looks like an interesting proposition, though May 14 15:06:07 dcordes: there is no reason that other arches won't build, are there? May 14 15:06:28 Laibsch: don't know that's why I just gave that info May 14 15:10:07 Laibsch: mojo is interesting *if you do not want to build* May 14 15:10:22 well, I want to start using again May 14 15:10:49 Just as an example, I ubuntu, not gentoo, for a reason May 14 15:11:03 Maybe we are the gentoo of the embedded world ;-) May 14 15:11:20 In that case, I think that mojo would suit me better May 14 15:11:43 But I'd be apalled having to visit *.hh.org May 14 15:12:05 Man, I need to learn to type May 14 15:12:19 "Just as an example, I use ubuntu on the desktop, not gentoo, for a reason" May 14 15:12:24 would be more like it May 14 15:13:03 mojo? May 14 15:13:26 mojo.handhelds.org - ubuntu 'native' compiled for arm with optimizations May 14 15:13:58 ah right the ubuntu arm port May 14 15:14:08 now I gotcha hrw May 14 15:14:15 ewww ubuntu May 14 15:16:42 it is not ubuntu arm port May 14 15:17:10 hi all May 14 15:17:12 /home/kraj/work/oe/build/eglibc/tmp-omap5912osk/work/armv5te-angstrom-linux-gnueabi/eglibc-intermediate-2.8+svnr6161-r6/temp/log.do_configure.9563 May 14 15:17:13 it is rather 'lets build packages from ubuntu with maybe some of our patches and with our flags for compilations' May 14 15:17:14 I just recall http://mojo.handhelds.org/ hrw ? May 14 15:17:39 why isn't it let's just use debian arm?! May 14 15:17:53 and add up an orange gtk theme May 14 15:17:57 debian armel is for armv4t May 14 15:17:58 for gnome May 14 15:18:08 it does not use vfp present in armv6 for example May 14 15:18:10 akita at least ist v5te May 14 15:18:15 ok May 14 15:18:32 I am seeing this error gcc version 4.2.2 May 14 15:18:32 Inconsistency detected by ld.so: dl-fini.c: 195: _dl_fini: Assertion `ns != 0 |! May 14 15:18:32 I don't see what an ubuntu install can give me what angstrom doesn't May 14 15:18:46 has someone seen something similar May 14 15:19:03 int main(void) { double a = 1.3, b = 1231.234; printf("%f\n", a * b); } is much smaller binary for amrv6-vfp May 14 15:19:09 dcordes: supportability May 14 15:19:30 aren't we complaining loudly how thinly stretched we are? May 14 15:20:03 I still have not fixed my Japanese environment on either spitz or collie (in this case it was opie) May 14 15:20:18 just some very simple examples May 14 15:20:30 Hi! I'm currently working on an mpc8313-rdb board, and I'm facing a little issue: May 14 15:20:35 It *can* be an interesting approach May 14 15:20:36 When generating an image (inheritance from image bbclass), the kernel image (uImage) is included in my jffs2 filesystem, while I want to avoid its presence (because the kernel will be on a separate MTD partition, so this uImage on the rootfs is useless). Watching other .bb files (namely org.openembedded.dev/packages/images/liveramdisk-image.bb) it seems a PACKAGE_REMOVE directive could remove my useless uImage. May 14 15:21:14 However, it does not work for me. When trying to understand by manually removing it (opkg remove kernel-image...), I see the process fails because kernel module packages depend on it, and I still want those modules to remain on the rootfs (they are not needed for booting, so no need for an initramfs). May 14 15:21:15 Laibsch: I don't want to bad talk about it. That's not my point I sure will give it a try on akita May 14 15:21:38 So my question is : how to properly use PACKAGE_REMOVE (or any other directive) to avoid this uImage to be present on the rootfs, but while still allowing the kernel modules to be present ? May 14 15:22:57 dcordes: Fully understood May 14 15:23:10 I am analysing myself May 14 15:23:18 I think the kernel and module deps should not be there May 14 15:23:21 is akita and spitz arm5vel? May 14 15:23:28 yes May 14 15:23:41 they are armv5te to be exact May 14 15:23:47 arm5vel is mojo naming May 14 15:24:17 so I think I've got the 'console-image' recipe built, but not clear where it put its objects - looking at packages/images/console-image.bb it bases itself off of 'image' yet I can't find an 'image.bb' ? May 14 15:25:04 tharvey, look in tmp/deploy ... May 14 15:27:50 guess it didn't build then... no tmp/deploy exists - I'll run it again and look for errors. In general do all the images dump objs in deploy? Where would I find this 'image' base that they are including May 14 15:30:12 thanks, hrw May 14 15:30:38 hrw: you still got one clamshell or sold them all out? May 14 15:32:49 dcordes: c760 somewhere May 14 15:33:25 hrw: isn't c760 a different pxa? May 14 15:35:15 likewise: But you *are* admin for the stablebranch ml May 14 15:35:30 http://lists.linuxtogo.org/cgi-bin/mailman/roster/openembedded-stablebranch May 14 15:35:52 Maybe you can do us all a favour and whitelist bugzilla mail? May 14 15:36:11 I am not asking for more May 14 15:36:19 but it already seems too much to ask May 14 15:36:22 Laibsch: presumably. I'm not aware of any passwd. I'll check my email for that. May 14 15:36:29 OK, thanks May 14 15:36:30 Laibsch: koen added me as admin, I guess May 14 15:37:04 The sender is bugzilla-daemon@amethysts.openembedded.net, I suppose May 14 15:37:27 amethyst May 14 15:37:30 dcordes: c7x0 are pxa25x - armv5te, cxx00 are pxa27x - armv5te (+ iwmmxt) May 14 15:37:53 Laibsch: have to ask koen for my passwd, I cannot find an email and I cannot have it sent... May 14 15:38:06 OK May 14 15:40:00 does console-image install fb_con? May 14 15:40:31 s/fb_con/ts_calibrate/ May 14 16:01:40 03koen 07org.oe.dev * rb79fc3b4... 10/ (1 conf/distro/include/angstrom-glibc.inc): angstrom: hack around gcc csl 2008q1 bug (http://www.codesourcery.com/archives/arm-gnu/msg01892.html) May 14 16:20:39 * rob_w ones again runs a fresh tree up -- May 14 16:29:23 hi, anybody used upstart on an embedded platform with success before? May 14 16:31:22 or insserv May 14 16:36:17 dcordes: compiles fine May 14 16:38:26 VoodooZ_: I've used upstart in a semi-embedded environment before. May 14 16:44:07 broonie: cool. what arch? May 14 16:44:12 i386 May 14 16:47:31 root May 14 16:51:22 hi Laibsch May 14 16:51:41 If I file / update a bug in a few min, can you go deal with it? :) It'll be easy and explained May 14 16:51:46 hey, Tom May 14 16:51:48 wb May 14 16:52:14 * Laibsch makes no promises May 14 16:52:33 heh, ok May 14 16:58:58 broonie: and what was your impressions/results like? May 14 16:59:30 No problems with it; I wouldn't particularly expect any. May 14 16:59:48 do you remember the boot time before/after? May 14 17:00:17 by problems, I meant compatibility with your existing startup scripts.. May 14 17:00:47 $ mtn --db=OE.mtn pull monotone.openembedded.org org.openembedded.{dev,stable} May 14 17:00:47 mtn: doing anonymous pull; use -kKEYNAME if you need authentication May 14 17:00:47 mtn: error: sqlite error: database is locked May 14 17:00:54 means someone is doing a push? May 14 17:05:26 VoodooZ_: it didn't make terribly much difference there - we were using it to provide monitoring/managment for long running processes. May 14 17:06:29 VoodooZ_: I just had it firing off our existing stuff as a startup job. It did also help us solve some startup ordering issues (the long running processes) May 14 17:10:00 a+ May 14 17:10:33 mtn diff -r 0e25c8665bca3c8d9e7c99e4432c9ce60811994c May 14 17:10:40 should show me all changes made in that rev, yes? May 14 17:12:28 Tartarus: no May 14 17:12:44 arg May 14 17:12:46 what will? May 14 17:12:55 take a look at my blog: http://blog.leggewie.org OE section May 14 17:13:14 k May 14 17:13:16 check out monotone-viz May 14 17:15:57 GUI stuff isn't good for me, my mtn stuff is in another office May 14 17:16:41 and, ah, ok, found the shortcut :) May 14 17:17:10 good May 14 17:17:23 I have that as an alias for "mtn-diff" May 14 17:17:36 hrw, ping May 14 17:17:39 So I only need to paste the rev once May 14 17:17:57 Tartarus: did you loose hope wrt to your patch? May 14 17:18:07 I don't see anything in the BTS, yet May 14 17:18:16 Laibsch, nope, still checking into everything May 14 17:18:25 OK May 14 17:18:27 that, btw, is the rev that did something wrong :) May 14 17:23:48 looking for help to diagnose the following build failure: http://source.mvista.com/~khilman/bitbake5.out May 14 17:24:07 this is happening after a 'bitbake -c clean git-native; bitbake git-native' May 14 17:24:32 the failure is because of a missing dir: temptaging (mysteriously similar to temp-staging) May 14 17:24:55 Tartarus: you need scsi? May 14 17:24:59 hey khilman May 14 17:25:07 Laibsch, customer does, actually May 14 17:25:11 Tartarus: hey May 14 17:25:13 OK May 14 17:25:20 Laibsch, but I went and poked the kernel folks, glibc is where those headers should come from May 14 17:28:05 * * OE Bug 4260 has been RESOLVED (FIXED) by May 14 17:28:07 * * new package i2c-tools May 14 17:28:09 * * http://bugs.openembedded.net/show_bug.cgi?id=4260 May 14 17:28:27 03Lukas 07org.oe.dev * r836a9d42... 10/ (1 packages/i2c-tools packages/i2c-tools/i2c-tools_3.0.1.bb): May 14 17:28:27 i2c-tools: add with version 3.0.1. Closes 4260. May 14 17:28:27 * commit from Laibsch May 14 17:28:32 03Laibsch 07org.oe.dev * r6aaaee53... 10/ (1 classes/seppuku.bbclass): seppuku: make the autobuilder report against the stable branch by default May 14 17:34:02 khilman, I'm going to try rebuilding git-native here against current meta-data May 14 17:35:07 angstrom is erroring out with 'GNU Fortran compiler is not working' - no idea what it would be including that requires fortran! what's the fortran compiler package that I need to install? May 14 17:36:53 BP flag is request to go into the stable branch too, yes? May 14 17:38:29 Crofton: thx, I will do a pull and try again too May 14 17:39:50 It's building for me here, after I clean git-native May 14 17:42:26 Tartarus: yes, bp was intended to be a backport request flag May 14 17:42:34 Don't count on it to work though May 14 17:42:56 k May 14 17:42:58 The people who currently maintain stable don't frequent the bug tracker May 14 17:43:02 i'll just file a same vs stable May 14 17:43:12 for whatever reason May 14 17:43:23 * Tartarus waits for 8 kernel tarballs to extract May 14 17:43:29 then I can finally hit commit on this bug, heh May 14 17:44:05 git-native built here :( May 14 17:44:22 Crofton: hmm, ok thx May 14 18:14:22 bye all May 14 18:18:48 aw May 14 18:18:51 * Tartarus missed hrw May 14 18:20:39 Laibsch, ok, filed May 14 18:20:43 * Tartarus waits for the bot May 14 18:20:56 1473 can also be closed once this is taken care of, btw :) May 14 18:21:30 morning May 14 18:28:04 * * OE Bug 4262 has been created by trini(AT)embeddedalley.com May 14 18:28:06 * * The /usr/include/scsi headers are missing in some cases May 14 18:28:08 * * http://bugs.openembedded.net/show_bug.cgi?id=4262 May 14 18:50:16 re May 14 18:54:58 hi flo May 14 19:13:05 * * OE Bug 1473 has been RESOLVED (FIXED) by May 14 19:13:07 * * libc6-dev/linux-libc-headers-dev conflict on scsi headers May 14 19:13:09 * * http://bugs.openembedded.net/show_bug.cgi?id=1473 May 14 19:30:40 !oebug 4242 May 14 19:30:41 * * Bug 4242, Status: UNCONFIRMED, Created: 2008-05-09 15:10 May 14 19:30:42 * * cliff.brake(AT)gmail.com: strace does not build with uclibc_svn May 14 19:30:43 * * http://bugs.openembedded.net/show_bug.cgi?id=4242 May 14 19:34:57 03koen 07org.oe.dev * rbd7627fc... 10/ (1 packages/openssl/openssl-native_0.9.8g.bb): openssl-native: stop leaking target compile flags (FULL_OPTIMIZATION) into native build, it kills kittens. May 14 19:40:03 anyone else having trouble build glibc-intermediate: http://pastebin.ca/1018276 May 14 19:40:11 (for PXA270 machine) May 14 19:41:34 glibc-intermediate-2.6.1-r4 build just fine a couple days ago ... May 14 19:44:36 03koen 07org.oe.dev * r1d173acb... 10/ (1 classes/seppuku.bbclass): disapproval of revision '6aaaee531ff6f260aade659a5a4b74f4ce3382bf' May 14 19:59:50 hey there.. trying to build an image for my asus wl500gp router. running the 'bitbake minimal-image' dies with the following: May 14 19:59:51 | The external toolchain could not be found in /usr/local/wrt54oe/mipsel! May 14 19:59:58 ... May 14 19:59:59 ERROR: '/mnt/stuff/oe/org.openembedded.dev/packages/meta/external-toolchain.bb' failed May 14 20:00:10 fairly new to the openembedded stuff.. any help is apreciated May 14 20:00:42 why does it depend on a toolchain.. isnt that the whole idea to build one? May 14 20:01:04 not for all distros May 14 20:01:23 same depends on external toolchain May 14 20:01:46 ok so that could be my case.. May 14 20:04:38 03koen 07org.oe.dev * r9acacf30... 10/ (3 files in 2 dirs): openssl-native: also fix 0.9.7m and def-pref -1 0.9.8 since it doesn't build May 14 20:08:21 I think the asus thing is just a mips32el, so I wonder why the external toolchain dependency? May 14 20:40:09 re May 14 20:40:19 hi hrw May 14 20:40:28 because the distro must set it to be provided by something else May 14 20:40:28 ho May 14 20:40:29 Do you use OE on your N810? May 14 20:40:33 Tartarus: no May 14 20:40:44 dang :( May 14 20:41:16 I did put too much work to get maemo working on it to remove it now May 14 20:41:24 maybe one day will try Poky May 14 20:41:27 heh May 14 20:41:45 I'm working on getting things to fully root off of external SD on mine right now May 14 20:41:56 I did give poky a try first, not too bad May 14 20:49:58 Laibsch: thanks for testing/commiting May 14 20:56:50 im still a bit confused.. so i assume it needs the external toolchain. should that one be compiled by oe? its checking for '/usr/local/wrt54oe/mipsel/pkgdata/' May 14 20:57:48 kwek: what are you trying to do? May 14 20:57:59 and why is your nickname kwek? May 14 20:58:15 trying to get oe running on my wl500gp May 14 20:58:23 why is your nick likewise May 14 20:58:51 because donald gave me that nickname May 14 20:59:00 :-) you .nl or .be? May 14 20:59:09 nl :) amsterdam May 14 20:59:15 but living in barcelona May 14 20:59:35 bye May 14 20:59:40 ok, nice. are you following some document on how to do this, or are you free riding? May 14 20:59:41 bye hrw May 14 21:00:05 just freeriding i guess.. the gettingstarted page is fecked May 14 21:00:09 kwek: living in spain permanently? May 14 21:00:20 important are MACHINE= and DISTRO= May 14 21:00:26 well as long as i like it.. and so far yeah May 14 21:00:29 yeah got those set May 14 21:00:35 to what if I may ask? May 14 21:00:58 martijn@meow /mnt/stuff/oe/build $ cat conf/local.conf | grep -E "(DISTRO|MACHINE)" May 14 21:00:58 MACHINE = "wl500g" May 14 21:00:58 DISTRO = "wrt54oe" May 14 21:01:45 checking conf files of those... hold on May 14 21:01:51 sure May 14 21:02:26 need to warm up my vmware fusion stuff, am typing on my mac now May 14 21:04:17 strange indeed, should be a normal mipsel toolchain May 14 21:04:48 and that shouldnt need an external one? May 14 21:07:19 kwek: well no, conf/distro/wrt54oe.conf specifies what toolchain to build May 14 21:07:29 kwek: reproducing (just for fun) here May 14 21:07:43 fun :) May 14 21:08:33 anyone have issues with a straight build of dropbear (ARM) causing clients to segfault? May 14 21:10:00 Fique: no, never seen that. What do you mean by a straight build? May 14 21:10:30 just did a console image for cm-x270 May 14 21:10:39 uclibc angstrom mode May 14 21:11:02 and I cant ssh into the thing... just figured id ask the people here before I went into further debugs May 14 21:11:24 no mods on my end, using latest sync of dev tree May 14 21:14:37 anyways... here we go with the traces :) May 14 21:26:54 kwek: ok, I found some output that explains the problem May 14 21:28:24 really May 14 21:28:35 kwek: http://www.pastebin.ca/1018389 May 14 21:29:26 yeah i got the same May 14 21:30:24 likewise hm why is the rang different for mipsel May 14 21:30:37 for simpad arm it first uses uclibc and the externaltoolchain May 14 21:31:57 wogline: rang? that's german for order, right? May 14 21:32:08 args yes May 14 21:32:11 order May 14 21:32:39 it was sliped out of my mind May 14 21:33:02 woglinde: I think the build is nondeterministic. In fact, I think we should fail whenever multiple providers are present and none is explicitly specified. May 14 21:33:35 yeah seems the best to me too May 14 21:33:48 with hint to put in local.conf May 14 21:34:23 hm seems gone May 14 21:34:30 for arm in actual dev May 14 21:36:44 hm? May 14 21:36:54 proposed this on the mailing list May 14 21:37:09 because I don't see the reason for the current behaviour. May 14 21:38:45 kwek: add this:PREFERRED_PROVIDER_virtual/libc = "uclibc" May 14 21:38:46 PREFERRED_PROVIDER_linux-libc-headers = "linux-libc-headers" May 14 21:38:46 PREFERRED_PROVIDER_virtual/mipsel-linux-uclibc-binutils = "binutils-cross" May 14 21:39:25 hey khem? May 14 21:40:12 hi Tartarus May 14 21:40:36 hi likewise May 14 21:42:54 likewise, yay.. its doing more now.. thanks! May 14 21:43:54 kwek: since we added the feature to also support external toolchains (opposed to self-built onces) most distro's do not define which one to use. May 14 21:44:10 kwek: you ran into that issue. I have to find the maintainer of wrt54oe... May 14 21:44:26 so should this go into the distro May 14 21:44:27 yeah exactly May 14 21:45:51 kwek yes May 14 21:45:58 bugreport *g* May 14 21:52:21 kwek: you probably run into the next problem as well: the revision for uclibc is not set, so it checks out revision 1.... May 14 21:52:36 woglinde: any clues on SRCREV? I hate this revision stuff. May 14 21:53:40 kwek: I think we need to do something like PREFERRED_VERSION_uclibc = "0.9.29" May 14 21:55:01 yeah it errors out now on unable to find repository May 14 21:55:06 yeah what you said May 14 21:57:43 that define atleast downloaded it.. seems to continue again May 14 22:01:29 kwek: it now builds tools for your host machine (-native) then starts with the cross-toolchain build (-cross) and after that the packages. May 14 22:02:07 kwek: One remaining problem *might* be that the binutils-cross package version number is not specified. Bitbake will choose the latest, but it may not work for your target processor. May 14 22:02:50 kwek: probably it will be ok though. MIPS architecture should be fine. May 14 22:03:37 ok ill remember that when trying to boot May 14 22:04:27 getting a new one now: May 14 22:04:29 | CROSS COMPILE Badness: /usr/include in INCLUDEPATH: /usr/include/ May 14 22:04:29 | cc1: internal compiler error: Aborted May 14 22:04:56 hm uh May 14 22:05:01 which package? May 14 22:05:05 y May 14 22:05:08 ill paste May 14 22:05:21 http://pastebin.com/d7a0a95c7 May 14 22:05:40 ah right May 14 22:05:55 there is no uClibc.config file for your setup May 14 22:06:03 so its using a generic May 14 22:06:21 hm hm May 14 22:06:54 could you pastbin the do_config file? May 14 22:07:16 yeah the uclib config is wrong May 14 22:07:21 where is the do_config? May 14 22:07:42 work/packagename/temp/do_config.processide May 14 22:07:47 kwek: yes I see too, this is the problem: find org.openembedded.dev/packages/uclibc/uclibc-0.9.2?/wrt* May 14 22:08:16 kwek: there is no configuration file for 0.9.29, only for 0.9.27 and 0.9.28 for your target. So we must select uclibc version 0.9.28. May 14 22:08:28 likewise nope May 14 22:08:29 kwek: Sorry, this is on-the-job debugging May 14 22:08:39 yeah im learning.. i like it May 14 22:08:41 woglinde: nope? May 14 22:08:46 better made config file for uclibc-0.9.29 May 14 22:08:57 isnt that hard May 14 22:09:00 copy it? May 14 22:09:05 woglinde: urhm, but we are not sure it will work for this target. May 14 22:09:22 better try it May 14 22:09:32 woglinde is right, but it might take some time to get the details right May 14 22:09:33 uclibc-0.9.28 can other glintches May 14 22:09:37 yes agreed May 14 22:09:56 0.9.29 is knowing to work for the most architecures May 14 22:10:16 and we have serval patches not backported to .28 May 14 22:10:38 woglinde: it's not that simple, since 0.9.29 we split up the single config file in a machine-specific file and distro-specific file May 14 22:10:52 but maybe we fall back to the single file, let me try May 14 22:11:50 kwek: by any means, it is smart to clean the uclibc build now, as it was already in compile stage: May 14 22:11:56 kwek: bitbake uclibc -c clean May 14 22:12:00 cool May 14 22:13:11 # For uClibc 0.9.29, OpenEmbedded splits the uClibc.config in two parts: May 14 22:13:11 # uClibc.machine and uClibc.distro. So, if they exist use them, otherwise May 14 22:13:12 # use a uClibc.config May 14 22:13:27 yes, we claim to have a fall-back, so I'll just try to shorcut here May 14 22:13:44 if it works, we need to split the config, if we want to fix this in our repository May 14 22:22:28 !log May 14 22:22:35 ~log May 14 22:22:37 log is probably as piece of wood, or a record, or the opposite of exponentiation May 14 22:24:15 trying to build 'console-image' with DISTRO=angstrom-2008.1 and its failing to download db-4.3.29 from downloads.sleepycat.com yet when I run 'bitbake -cfetch console-image' nothing fails? May 14 22:28:59 "Yes" May 14 22:29:08 you're telling it to fetch sources for the console-image recipe May 14 22:29:12 which presumably has none May 14 22:29:15 and doesn't fail May 14 22:29:20 if you want to grab db manually May 14 22:29:22 bitbake -c fetch db May 14 22:29:42 (possibly db4, for that particular failure, see what the recipe is named, do a bitbake console-image again) May 14 22:30:04 allrighty im gonna get some sleep here.. thanks for ya help likewise and woglinde.. ill check back tomorrow here if there is a solution.. oe seems like a nice project May 14 22:30:28 kwek: how did you find us? May 14 22:30:28 ok, so I still don't understand what defines what packages are in an image, such as console-image? May 14 22:30:46 tharvey: start with the console-image.bb file itself. May 14 22:31:06 tharvey: everything mentioned there will be in it, at least. Then all dependencies are also needed. May 14 22:31:16 likewise, tru trickie.. he's a collegue of mine at work and doing maemona (hows it called?) things May 14 22:31:38 tharvey: so if application "foo" needs library "bar", and foo is in image, bar will get in the image as well. May 14 22:32:03 kwek: where do you work? May 14 22:32:21 small software company in amsterdam May 14 22:32:22 kwek: or is it unrelated to OE? May 14 22:32:30 kwek: embedded stuff? May 14 22:32:38 yeah unrelated.. internet python stuff May 14 22:32:50 so this is to play around May 14 22:32:50 looks like I have to gain a better understanding of the recipe syntax - hopefully it will all make sense then May 14 22:32:56 kwek: ok just asking, because we need better PR :-) May 14 22:33:20 your doing good.. especially with openmoko coming May 14 22:33:31 tharvey: DEPENDS aaa means "this .bb needs package aaa to be built first". May 14 22:34:01 tharvey: RDEPENDS bbb means "the target will need package bbb in order for this package to run on the target" May 14 22:34:55 ahh... ok. and 'inherit image'? May 14 22:35:49 tharvey: we have a set of tasks (things bitbake must do) that are common. One of them is the "image class of tasks". May 14 22:36:44 tharvey: inherit image means that that .bb file re-uses the common tasks for a image. These common task classes are in /org.openembedded.dev/classes/*.bbclass May 14 22:37:13 tharvey: skim through the documentation / wiki / www.openembedded.org / www.openembedded.info while you explore stuff. May 14 22:37:30 tharvey: we have rather steep learning curve but it pays off after a while, I promise :-) May 14 22:42:05 yes... steep learning curve - thanks for all the insight here. I'm evaluating using OE for an internal BSP vs other's like OpenWRT, LTIB, buildroot May 14 22:49:13 http://oe.linuxtogo.org/user-manual rocks! May 14 22:51:05 tharvey: for what architecture? powerpc? May 14 22:52:19 various architectures (x86, PPC, ARM)... we have 3 or 4 embedded platforms, used in perhaps 6 to 7 products. There currently are a variety of different distros on them... I'm trying to unify everything. May 14 22:53:13 tharvey: ok, I'm in the same position, but I was there two or three years ago. I chose OE over buildroot. LTIB did not exist then, or only for powerpc/coldfire. I'ld still make the same choice today. May 14 22:53:47 tharvey: but please let us know if you have questions/doubts/suggestions May 14 22:53:58 I'm probably 98% certain OE is the way I'm heading... just doing a little research to backup my decision and at the same time trying to get my feet wet May 14 22:54:27 I've used OpenWRT quite a bit (buildroot based), and I've worked on my own buildroot based distro for the past couple of years at another job May 14 22:54:59 I only wish I would have noticed http://oe.linuxtogo.org/user-manual prior to http://oe.linuxtogo.org/wiki/GettingStarted May 14 22:55:38 GettingStarted doesn't work for me... missing file to download May 14 22:58:46 tharvey: what file? May 14 23:08:14 http://downloads.sleepycat.com/db-4.3.29.tar.gz May 14 23:10:53 so in the effort to find what's requiring db -> console-image depends on task-base-extended (still looking for that expect to see a packages/task-base-extended.bb). May 14 23:14:01 tharvey: ah, ok, the task based images build more than you need. don't ask me why, I never understood the task-based images, and never use them. May 14 23:14:14 tharvey: however, db will not end up in your image. May 14 23:14:21 gotta get some sleep now. May 14 23:14:22 cya May 15 01:05:03 Tartarus: what's up May 15 01:11:35 hey khem May 15 01:11:39 !oebug 4216 May 15 01:11:41 * * Bug 4216, Status: UNCONFIRMED, Created: 2008-05-06 03:23 May 15 01:11:42 * * trini(AT)embeddedalley.com: gdb-cross and gdb-cross-sdk 6.\[68\] differ May 15 01:11:43 * * http://bugs.openembedded.net/show_bug.cgi?id=4216 May 15 01:11:54 *pokes and run* May 15 01:11:59 s/run/runs/ May 15 01:14:36 Tartarus: I see the bug May 15 01:17:26 Tartarus: I think SDK is not intended at simulator so that patch might be skipped but early_debug_in_nptl probably makes sense May 15 01:29:30 khem, well, is there any reason _not_ to put all patches in both? May 15 01:30:04 IMHO, SDK might be used in more versatile places than the non-sdk cross version May 15 01:30:07 not apparent one except RP does the SDK ones often May 15 01:30:26 in the community May 15 01:30:40 I think a lot of people take the SDK recipes and fix 'em for their needs May 15 01:31:10 yes if you have tested these patches then we can put them upstream for sdk May 15 01:32:15 I haven't tested them any more fully than they have been already May 15 01:32:32 But I found the difference when tracking something else down May 15 01:32:38 and went "what? why?" May 15 01:34:14 So it sounds like there's not a good reason and it might expose those changes to more testing :) **** ENDING LOGGING AT Thu May 15 02:59:56 2008