**** BEGIN LOGGING AT Tue Jan 11 02:59:58 2011 Jan 11 05:47:30 03Khem Raj  07master * rf2253e23c7 10openembedded.git/recipes/mesa/ (mesa-7.9.1/uclibc.patch mesa-dri_7.9.1.bb mesa_7.9.1.bb): Jan 11 05:47:30 mesa-7.9.1: Fix build on uclibc Jan 11 05:47:30 Signed-off-by: Khem Raj Jan 11 08:24:06 good morning Jan 11 09:06:59 good morning Jan 11 09:16:10 ericben: hi Jan 11 09:17:39 hi mckoan Jan 11 09:22:02 03Eric BENARD  07org.openembedded.dev * rebd29e13f9 10openembedded.git/conf/distro/include/angstrom-2010-preferred-versions.inc: Jan 11 09:22:02 angstrom-2010: prefer busybox-1.18.1 Jan 11 09:22:02 this is the latest stable version Jan 11 09:22:02 Signed-off-by: Eric Bénard Jan 11 09:22:02 Acked-by: Koen Kooi Jan 11 09:22:05 03Eric BENARD  07org.openembedded.dev * rb4f54aa770 10openembedded.git/recipes/linux-libc-headers/linux-libc-headers_2.6.37.bb: Jan 11 09:22:05 linux-libc-headers_2.6.37: fix SRC_URI Jan 11 09:22:05 actual SRC_URI can't work because : Jan 11 09:22:05 - linux-libc-headers-2.6.37.tar.bz2 or linux-libc-headers-native-2.6.37.tar.bz2 Jan 11 09:22:06 don't exist on kernel.org's FTP Jan 11 09:22:07 - there is no file://defconfig Jan 11 09:22:07 Signed-off-by: Eric Bénard Jan 11 09:22:07 03Eric BENARD  07org.openembedded.dev * r0000d33694 10openembedded.git/recipes/busybox/ (8 files in 2 dirs): Jan 11 09:22:08 busybox: remove 1.17.4 Jan 11 09:22:08 now that angstrom-2010 is using 1.18.1 Jan 11 09:22:09 Signed-off-by: Eric Bénard Jan 11 09:22:10 Acked-by: Khem Raj Jan 11 09:22:10 03Eric BENARD  07org.openembedded.dev * ra11f29b4f4 10openembedded.git/recipes/tslib/tslib_git.bb: Jan 11 09:35:36 03Martin Jansa  07master * rf2a7e115ce 10openembedded.git/recipes/linux/linux_2.6.34.bb: Jan 11 09:35:36 linux-2.6.34: remove c7x0 patch from SRC_URI override as that file was removed in f000274e8bcae7c2d8cfebb2a7485689e7cab476 Jan 11 09:35:36 Signed-off-by: Martin Jansa Jan 11 09:55:25 03Koen Kooi  07org.openembedded.dev * ra92ab702f0 10openembedded.git/recipes/ntp/ (15 files in 4 dirs): (log message trimmed) Jan 11 09:55:25 ntp: cleanups Jan 11 09:55:25 * remove obsolete versions Jan 11 09:55:25 * move ntp-ssl forward Jan 11 09:55:25 * fix ifup script Jan 11 09:55:25 * fix crontab Jan 11 09:55:26 * moved files into files/ so it can be shared between ntp and ntp-ssl Jan 11 10:11:23 someone noticed this error while building boots-1.45.0 with gcc-4.5? *** buffer overflow detected ***: /OE/tmpdir-shr/sysroots/x86_64-linux/usr/armv4t/lib/gcc/arm-oe-linux-gnueabi/4.5.3/../../../../arm-oe-linux-gnueabi/bin/ld terminated Jan 11 10:11:28 boost.. Jan 11 10:12:07 http://paste.pocoo.org/show/318762/ Jan 11 10:13:23 on different host I get only [8775885.236872] ld[30461] trap stack segment ip:43596c sp:7fffc19e9170 error:0 in dmesg Jan 11 10:49:14 hej, anybody with knowledge of OEs bootstrapping process present? strict.pm (perl-module-strict) is missing when building flex-native and others... I don't think this is the right place to add the dep though... Jan 11 10:50:15 mlip: what is the error you get ? libperl.so not found or something like this ? Jan 11 10:50:49 ericben: automake fails: | Can't locate strict.pm in @INC (@INC contains: ... Jan 11 10:51:58 mlip: ok here I get "perl: error while loading shared libraries: libperl.so: cannot open shared object file: No such file or directory" when autoreconf runs on some native libs Jan 11 10:52:02 ericben: nvm, my includepaths are messed up somehow ... just didn't notice this until now Jan 11 10:54:20 just found out that packaged staging is not compatible with a new TMPDIR that is at some other place; had not though about this, but it seems reasonable (staged configs, etc.) Jan 11 10:57:25 03Martin Jansa  07master * r95827005a1 10openembedded.git/recipes/linux/ (4 files in 2 dirs): Jan 11 10:57:25 linux-2.6.34: upgrade to longterm 2.6.34.8 and update openmoko and shr patch a bit Jan 11 10:57:25 Signed-off-by: Martin Jansa Jan 11 11:00:37 03Michael 'Mickey' Lauer  07org.openembedded.dev * r90a94fb96f 10openembedded.git/recipes/freesmartphone/fsodeviced_git.bb: fsodeviced: i2c-tools no longer a dependency; everything necessary included in fsodeviced itself Jan 11 11:21:18 kergoth`: ping Jan 11 11:21:56 kergoth`: could you apply one little patch (fixing an include in cy8mrln-palmpre plugin) to tslib repository? Jan 11 11:22:12 kergoth`: if yes, I will send it to you by mail Jan 11 11:22:42 morphis: it is the middle of the night in kergoth-land, I expect he is asleep Jan 11 11:22:48 hm Jan 11 11:22:56 kergoth-land, where is it? Jan 11 11:22:57 US? Jan 11 11:22:59 yeah Jan 11 11:23:01 ok Jan 11 11:23:16 then I will send him the mail ... Jan 11 11:23:17 I think he is on UTC-7, something like that Jan 11 11:26:24 ok Jan 11 11:27:22 so he will up in some hours, great Jan 11 11:31:55 morphis: there is the tslib mailing list : tslib-general@lists.berlios.de Jan 11 11:36:13 ericben: I know, but in this case I prefer the fast, direct way :) Jan 11 12:52:33 Something went wrong with by build Jan 11 12:52:41 init.c:(.text+0x24): undefined reference to `__libc_start_main' Jan 11 12:52:41 init.c:(.text+0x28): undefined reference to `abort' Jan 11 12:52:52 Which recipe is responsible for libc? Jan 11 12:59:18 glibc Jan 11 12:59:48 or eglibc/uclibc depending on distro varients Jan 11 13:00:06 Thanks Jan 11 13:00:27 that is an unusual type error to cause Jan 11 13:01:30 03Víctor Manuel Jáquez Leal  07org.openembedded.dev * r1f90d78726 10openembedded.git/classes/scons.bbclass: (log message trimmed) Jan 11 13:01:31 scons: add EXTRA_OESCONS Jan 11 13:01:31 It's similar to EXTRA_OEMAKE, which appends arguments to the scons Jan 11 13:01:31 command Jan 11 13:01:31 v2: Jan 11 13:01:31 * initialise the EXTRA_OECONS if it is not defined Jan 11 13:01:31 Signed-off-by: Víctor Manuel Jáquez Leal Jan 11 13:04:51 I think yesterday I did cleanall (don't ask why) on one of the packages. Jan 11 13:05:33 probably bitbake did not rebuild those packages. Jan 11 13:05:41 So I messed things up a bit. Jan 11 13:29:56 if you clean *libc you normally need to clean *libc-initial as well Jan 11 13:30:15 then it all rebuilds fine Jan 11 14:14:16 Yeah, deleted temp and rebuilding everything. It looked a bit too messy now. Jan 11 14:28:22 So, is there anyone around currently that really really cares about uclibc failures? Jan 11 14:32:12 03Steffen Sledz  07org.openembedded.dev * re152587aa6 10openembedded.git/recipes/alsa/ (alsa-lib_1.0.20.bb alsa-lib_1.0.23.bb): Jan 11 14:32:12 alsa-lib: fix packaging error Jan 11 14:32:12 * symlink libasound.so -> libasound.so.2.0.0 in /usr/lib was missing in Jan 11 14:32:12 dev package Jan 11 14:32:12 Signed-off-by: Steffen Sledz Jan 11 14:32:12 Acked-by: Koen Kooi Jan 11 14:32:28 JaMa, ping Jan 11 14:33:08 pong Jan 11 14:34:08 ppc+mesa is failing Jan 11 14:34:09 sec Jan 11 14:34:34 http://pastebin.com/6dx1fMbv Jan 11 14:34:41 haven't googled or anything, triaging my logs atm Jan 11 14:34:56 but qemuppc/p2020ds/mpc8315e-rdb fail so it wouldn't be hard to reproduce if you can :) Jan 11 14:35:21 you relaize that all posible combinations of builds actually building in OE is a sign of the apocalypse? Jan 11 14:36:23 ericben, heh, I got that libperl.so problem overnight, on RHEL5 Jan 11 14:36:56 Tartarus: which libc it is? khem pushed fix for uclibc tonight Jan 11 14:37:20 JaMa, eglibc Jan 11 14:37:30 DISTRO=minimal Jan 11 14:37:33 Tartarus: cool ;-) I have some log if you want Jan 11 14:37:39 I just got it again Jan 11 14:37:45 ericben, it's def a race when we install perl-native :( Jan 11 14:37:55 in the present case : ibpthread-stubs_0.2.bb, do_configur fails Jan 11 14:38:01 but : 1: perl-native-5.10.1-r8 do_populate_sysroot (pid 7304) Jan 11 14:38:11 yeap, similar here Jan 11 14:38:17 so perl-native is not yet installed Jan 11 14:38:21 that task had just finished before i got the message Jan 11 14:38:57 * Tartarus tries to recall how/if we fixed a slightly similar race for coreutils-native Jan 11 14:40:35 also I have more and more : "Identifying dependency loops (this may take a short while)..." and only solution is to clean tmp and restart because it never ends Jan 11 14:41:20 seems to occur after having killed bitbake with several ctrl c Jan 11 14:42:37 JaMa, so are you going to be able to look into that? Jan 11 14:44:36 I'll try but not sure if I'll able to test it today Jan 11 14:44:52 builds and works fine on armv[457] Jan 11 14:45:10 yeah Jan 11 14:45:14 and too much daywork to start ppc build now Jan 11 14:45:21 :( k Jan 11 14:45:25 i'll see if i can google up anything Jan 11 14:45:50 but imho I've noticed similar error in some other package a while back Jan 11 14:45:51 it's also fine on qemux86/mips Jan 11 14:45:58 mipsel Jan 11 14:46:07 and mips64 Jan 11 14:47:14 can you try to add -ldl to that failing command? Jan 11 14:48:55 yeah, on the list. But the builds get blown away so I can move on to the next one Jan 11 15:41:45 Tartarus: adding perl-native-runtime to autoconf.inc seems to solve the problem for me Jan 11 15:42:00 Tartarus: to RDEPENDS_${PN}_virtclass-native in autoconf.inc Jan 11 15:42:00 but perl-native-runtime is nothing Jan 11 15:42:11 did you mean perl-native ? Jan 11 15:42:29 Tartarus: ok so doing nothing solves the problem :-D will wait the build finish to be sure Jan 11 15:45:10 Tartarus: or maybe this is because I'm doing other things on the build host, which modifies the timings ... will retry this evening. Jan 11 16:18:06 http://pastebin.com/pTE3ctEb look good to anyone? Jan 11 16:31:55 Tartarus: shouldn't do any harm imho Jan 11 16:36:22 should fix a build race I see, too Jan 11 16:41:16 re Jan 11 16:41:18 gm Jan 11 16:41:36 I joined in a race condition, missed the race condition fix Jan 11 17:00:02 03Tom Rini  07master * r343b75ebf0 10openembedded.git/recipes/autoconf/autoconf.inc: Jan 11 17:00:02 autoconf: Really only build in desired SUBDIRS Jan 11 17:00:02 In certain cases we would re-run configure as part of do_compile Jan 11 17:00:02 and thus wipe out our changes. So lets make the change before Jan 11 17:00:02 we run configure the first time so they are preserved. Jan 11 17:00:02 Signed-off-by: Tom Rini Jan 11 17:47:35 hi ericben Jan 11 17:48:12 hi GNUtoo|laptop Jan 11 17:48:28 quick question, under mainline what is the cmdline to get serial? Jan 11 17:48:42 under 2.6.27-freescale it was: Jan 11 17:49:02 mickey|zzZZzz, saw a post from you years back about pyqt support being dropped - did anyone pick that up? the recipe in OE is very dated Jan 11 17:49:04 console=ttymxc4 Jan 11 17:49:16 for you imx "console=ttymxcX,115200n8" Jan 11 17:49:30 ok still mxc then Jan 11 17:49:53 yes at least up to 2.6.37+ :) Jan 11 17:49:59 ok Jan 11 17:50:25 I don't think they change interface that easily Jan 11 17:50:32 as userspace interface are frozen Jan 11 17:50:35 but you can add some Jan 11 17:50:40 but not change the existing ones Jan 11 17:50:40 see you later, I have to go to get my childs from the nanny Jan 11 17:50:44 ok Jan 11 17:50:46 see you later Jan 11 17:50:48 and thanks a lot Jan 11 17:50:50 check omap : ttySx to tttyOx ! Jan 11 17:51:26 I've no omap with serial yet Jan 11 17:51:29 it will come tough Jan 11 18:21:11 khem, ping Jan 11 18:29:34 03Tom Rini  07master * r751ecb1dae 10openembedded.git/recipes/ltrace/ (files/ltrace-fix-sysdep_h-dependency.patch ltrace_0.5.3.bb): Jan 11 18:29:34 ltrace: Rework sysdeps dependencies Jan 11 18:29:34 The dependencies here were slightly lazy and in certain cases it was Jan 11 18:29:34 possible to be building objects that required generated headers before Jan 11 18:29:34 they were done. Jan 11 18:29:34 Signed-off-by: Tom Rini Jan 11 18:34:12 03Bernhard Reutner-Fischer  07master * rd3489b141c 10bitbake.git/lib/bb/ (5 files in 3 dirs): Jan 11 18:34:12 *: use utils.remove() some more Jan 11 18:34:12 Signed-off-by: Bernhard Reutner-Fischer Jan 11 18:34:15 03Bernhard Reutner-Fischer  07master * r86c6434f09 10bitbake.git/lib/bb/build.py: Jan 11 18:34:15 build: remove duplicate import of utils Jan 11 18:34:15 Signed-off-by: Bernhard Reutner-Fischer Jan 11 18:34:16 03Bernhard Reutner-Fischer  07master * r8c5555f5ed 10bitbake.git/lib/bb/codeparser.py: Jan 11 18:34:17 codeparser: fix spacing in diagnostic messages Jan 11 18:34:17 Signed-off-by: Bernhard Reutner-Fischer Jan 11 18:35:18 kergoth`, these 3 where only tested cursory.. Jan 11 18:37:59 kergoth`, RP, RP__, so what's that fetch2? I meant to generalize tarball creation to just specified a set of excludes and uniformly handle fullclone and scmdata=keep (the latter with a global knob so i don't have to touch every recipe in oe) and now fetch2 pops up? Should i hold back on touching fetchers for a while? Does anyone have a .plan ? Jan 11 18:43:06 the fetch module is essentially being rewritten. Jan 11 18:43:26 kergoth`, i've now thought about symlinking run.* to just one instance and while at it tend follow up with your (most obvious idea, now that i've seen what you mean :) to just emit both py as well as sh bodies if we got an exception or are debugging heavily. Do you plan on bringing the last part over anytime soon or should i look further? Jan 11 18:44:20 kergoth`, cool thing. It's way too elaborate as it is Jan 11 18:46:23 kergoth`, what do you think about the kconfig idea i sent? I think it was you who said that such a beast could eventually be received well, didn't you? Jan 11 19:06:43 the concept of kconfig is a good one, but i suspect it will be more useful as a frontend to configuration than for recipe selection. that said, i'm sure there's a need for both Jan 11 19:07:50 tharvey: i'm afraid noone picked up. it has always been quite an undertaking to update sip and pyqt, since they changed their buildsystem often. perhaps things are simpler nowadays? Jan 11 19:08:18 there is a pyqt fork also apparently Jan 11 19:09:39 you mean pyside? Jan 11 19:09:46 noticed that Jan 11 19:11:16 mickeyl, I'm reading that pyqt requires patches to work against qt-embedded - do you know anything about that? Jan 11 19:11:37 tharvey: sure, i did all those Jan 11 19:11:44 they're in OE Jan 11 19:12:01 ya, pyside is an utter piece of NIH Jan 11 19:12:06 i'm very angry wrt. Jan 11 19:13:23 from my reading pyside is LGPL vs pyqt GPL (unless you buy a commercial license) Jan 11 19:13:32 yeah, that is my understanding Jan 11 19:13:34 pyside has a goal of being API compatible Jan 11 19:14:03 so it seems to me that should simply replace pyqt if its up to snuff? Jan 11 19:15:35 feel free to add pyside next to pyqt, if you want Jan 11 19:15:41 updating pyqt would be appreciated as well Jan 11 19:16:53 yes, I'll look at both Jan 11 19:17:13 probably will start by attempting to update pyqt as I know that works for my need but will need to test pyside Jan 11 19:18:12 right Jan 11 19:22:25 mickeyl, I'm seeing that there's a recipe for sip-native as well as python-sip and they are not at the same version - seems like I'll need to bring both of those up to date as well? Jan 11 19:23:19 yes Jan 11 19:23:27 sip-native is the binding generator for pyqt Jan 11 19:23:31 python-sip is its runtime module Jan 11 19:26:02 I'm seeing some configure patches, and some arm patches, but not anything that looks specific to qtembedded Jan 11 19:26:13 (in current pyqt patches that is) Jan 11 19:27:15 mickeyl, ah I see a qtembedded patch in python/python-pyqt/cross-compile.patch Jan 11 19:28:42 yeah, it's tiny. over the years, more and more support got into pyqt mainline Jan 11 19:29:01 at one point of time, the pyqt creator was payed by Sharp to add Qt/E support Jan 11 19:29:15 i maintained that for a while when this contract ended Jan 11 19:29:33 but around 2007 i lost interest in (py)qt Jan 11 19:29:53 so it looks like the only diffs for QtEmbedded were to setup the various qt_* dir globals Jan 11 19:30:21 at least for this very version, yes Jan 11 19:30:29 things have changed massively since then Jan 11 19:30:38 a couple of product focus changes, renamings, etc. Jan 11 19:30:44 ok.... I'll get cracking - thanks for the info! Jan 11 19:30:50 np Jan 11 19:30:54 good spped Jan 11 19:30:57 speed Jan 11 19:48:29 hi mickeyl Jan 11 19:48:45 I sent some email about a week ago...did you get it? Jan 11 19:50:37 yes, i had a couple of busy days, i'll try to carry out the CNAME changes asap Jan 11 19:56:40 blindvt`: pong Jan 11 20:01:10 blindvt: I should be able to test you busybox patches tomorrow so ack will come after ;) Jan 11 20:01:50 passwd & shadow packages are a good idea Jan 11 20:02:02 khem, first, thanks for pushing the ACKed parts (as just recorded through ML). Second, see pings on ML. Third: unsurprisingly glib are braindead: https://bugzilla.gnome.org/show_bug.cgi?id=638593 so please consider ACKing and/or applying "[PATCH 11/12] glib-2.0: fix compilation for !IPv6" Jan 11 20:02:39 ericben, Roman rightfully noted that i forgot /etc/group Jan 11 20:02:55 ericben, so that should go into the passwd package, too. Jan 11 20:03:40 blindvt: ok will try it Jan 11 20:03:41 and i apparently didn't send in initramfs-qemu-image nor snippets against micro-image and related hunks :( Jan 11 20:06:45 blindvt: I update patchwork Jan 11 20:06:54 whenever a patch is acceptefd Jan 11 20:07:10 i should do that too. Jan 11 20:07:18 so should all of us Jan 11 20:07:23 its very handy Jan 11 20:08:12 it is, short of obfuscated password-reset facilities in the UI. Was that applied in our install, btw? Jan 11 20:08:22 blindvt: [PATCH 11/12] is applied already I think Jan 11 20:09:39 and i should poke Lars Hjemli to apply the cgit tweaks i sent Jan 11 20:11:27 blindvt: fetch2 is a rewrite of the fetcher code. Its being done that way so we can break the API Jan 11 20:11:40 khem, oh, sorry. 11/12 is. But some TI folk should fix their gstreamer-ti RRECOMMENDS aka "[PATCH 01/12] gstd: fix type in RRECOMENDS". None of my business though Jan 11 20:11:57 yeah Jan 11 20:12:15 RP__, so, can i unify tarball handling in fetch2 or should i wait for it to settle? Jan 11 20:12:40 blindvt: btw. yann's patches for uclibc are holding good Jan 11 20:12:53 speaking of uclibc Jan 11 20:12:59 khem, do you care about meta-toolchain for uclibc? Jan 11 20:13:01 or.. Jan 11 20:13:13 blindvt: I think we should push them after we cut .32 what do u think Jan 11 20:13:18 Tartarus: yes Jan 11 20:13:20 nas-server-image,native-sdk-imag or console-image Jan 11 20:13:20 RP__, if i touch any fetcher, whom should i? In the light of an scm, i find it a tad odd to do that fetch2 approach, but ok Jan 11 20:13:27 4.5 broke meta-toolchain for uclibc Jan 11 20:13:31 others have been broken for ages Jan 11 20:13:35 hrmm Jan 11 20:13:40 i forget why x11-image fials Jan 11 20:13:41 Tartarus: in what way Jan 11 20:13:50 which one? Jan 11 20:14:06 (sorry, got my daughter on my lap, little slow to type/dig out logs) Jan 11 20:14:07 Tartarus: meta-toolchain Jan 11 20:14:17 gcc-cross-sdk and libstdc++ precompiled headers Jan 11 20:14:27 ah pch stuff Jan 11 20:14:35 khem, they are good indeed. Thing is that arm is easy, x86 and x86_64 too as well as mips, ppc and sh. Tricky are alpha and especially sparc Jan 11 20:15:19 didn't i send a patch for the pch stuff, either to gcc or oe? Jan 11 20:15:43 we should poke Austin for sparc Jan 11 20:17:12 khem, we will for sure. It was a rather twisted logic with 4 degrees to get sparc right. I've discussed it with austin previously, ibot should have the details cached, but IIRC it was pretty quirky Jan 11 20:17:12 hrmm http://git.openembedded.org/cgit.cgi/openembedded/commit/?id=8d51dd82e8e26bf9c4bd780d1a63a23128f938b0 was not supposed to be pushed yet Jan 11 20:17:16 schade Jan 11 20:17:41 khem, oh that one. Jan 11 20:17:48 blindvt: I think everyone agrees the fetcher needs improving. Doing do so without breaking the API is going to be hard. We also need a transition path for projects like OE and poky. It is a little unusual but some of the more invasive code changed we're looking at should make the reasons clear soon Jan 11 20:18:15 blindvt: yeah somehow git push always takes all branches into account Jan 11 20:18:22 blindvt: As for which code to touch, I'm expecting fetch2 to be the long term code base but its not going to happen over night Jan 11 20:18:25 khem, i also wanted to talk with you about that one. Can we please, *pretty please* settle on one set of feature strings and _approach_? Jan 11 20:18:32 I have done this more than once Jan 11 20:18:54 blindvt: yes I liked the idea of explicit enabling rather than disabling Jan 11 20:18:55 ~lart khem Jan 11 20:18:55 * ibot squishes khem like a bug Jan 11 20:19:09 nm I will fix it Jan 11 20:19:15 poor khem Jan 11 20:19:18 as such the commit is harmless Jan 11 20:19:43 it does not change anything Jan 11 20:20:05 khem, it's way superiour. That no* crap is desktop attitude and definitely not the thing we should do #here, don't you think Jan 11 20:20:14 yes Jan 11 20:20:36 but I still want to go with all enabled by default Jan 11 20:20:41 as this has been the case so far Jan 11 20:21:11 so may be I have to patch all the distros Jan 11 20:21:15 khem, up to the distro to cast madness unto them, sure, sir. If they want to screw themselves, here's the rope Jan 11 20:23:26 So, anyone wanna try building those other images for uclibc? Jan 11 20:23:35 or just not going to work and I should stop Jan 11 20:23:39 Tartarus: x11-image builds fine Jan 11 20:23:44 I just tried this morning Jan 11 20:23:58 for uclibc? Jan 11 20:24:31 khem: did you notice any boost-1.45.0 issues (ld segfaulting with gcc-4.5 with binutils-2.20 and 2.21 too Jan 11 20:24:50 Tartarus: yes Jan 11 20:24:56 DISTRO=minimal-uclibc Jan 11 20:24:56 khem, I guess i'll report again once this build which has the mesa fix in is done Jan 11 20:25:01 but they've never built here Jan 11 20:25:03 JaMa|Off, I may be in a position to notice that sort of issue later this week Jan 11 20:25:07 ohw about nas/native-dsdk? Jan 11 20:25:12 ga Jan 11 20:25:14 native-sdk Jan 11 20:25:30 someone noticed this error while building boots-1.45.0 with gcc-4.5? *** buffer overflow detected ***: /OE/tmpdir-shr/sysroots/x86_64-linux/usr/armv4t/lib/gcc/arm-oe-linux-gnueabi/4.5.3/../../../../arm-oe-linux-gnueabi/bin/ld terminated Jan 11 20:25:34 Tartarus: native-sdk-image builds fine too Jan 11 20:25:42 I have not tried nas-server-image Jan 11 20:25:59 JaMa|Off: no I did not notice it Jan 11 20:26:29 let me fire off a boost build Jan 11 20:26:36 hmm, i think it built here Jan 11 20:26:44 khem, ok Jan 11 20:26:53 maybe once the fixes i pushed today hit my build it'll complete then Jan 11 20:27:03 here is log http://paste.pocoo.org/show/318762/ Jan 11 20:27:50 JaMa|Off: buffer overflow hmmmm Jan 11 20:28:04 JaMa|Off: I have seen ld/as having weird memalloc issues Jan 11 20:28:08 khem, do you do sh4? Jan 11 20:28:18 how long has your build server been running Jan 11 20:28:24 Tartarus: time to time Jan 11 20:28:28 khem, here's a big killer on minimal-uclibc for me Jan 11 20:28:30 I did recently fix it Jan 11 20:28:36 now it boots in qemu Jan 11 20:28:46 http://pastebin.com/38c7YcME Jan 11 20:29:24 native-sdk Jan 11 20:29:32 and 751ecb1daeaf08a3cb7bd5600731264a0753f4b3 Jan 11 20:29:32 Tartarus: ook Jan 11 20:29:42 Tartarus: you can do this Jan 11 20:29:54 khem: 101 days on one and here only few days since .37 release Jan 11 20:30:08 DISTRO_TYPE = "release" in local.conf Jan 11 20:30:18 Tartarus: then it wont pick all the fso crap Jan 11 20:30:36 JaMa|Off: both machine fail same way ? Jan 11 20:30:44 khem, i just run the testing script stuff, sec Jan 11 20:31:00 Tartarus: I have seen that error and its because that package assumes glibc Jan 11 20:31:31 on different host I get only [8775885.236872] ld[30461] trap stack segment ip:43596c sp:7fffc19e9170 error:0 Jan 11 20:31:44 JaMa|Off: ok Jan 11 20:31:54 JaMa|Off: here is one assignment for you then Jan 11 20:32:07 but it's on same command in boost build Jan 11 20:32:18 collect all .a .o .so that the linker uses Jan 11 20:32:22 into one dir Jan 11 20:32:26 03Andreas Oberritter  07org.openembedded.dev * ree85c41bb8 10openembedded.git/recipes/gcc/ (16 files): Jan 11 20:32:26 gcc: replace unconditional SRC_URI_append with SRC_URI += Jan 11 20:32:26 * Fixes missing leading whitespace character at some locations Jan 11 20:32:26 Signed-off-by: Andreas Oberritter Jan 11 20:32:26 CC: Khem Raj Jan 11 20:32:26 Acked-by: Khem Raj Jan 11 20:32:30 and see if you can reproduce it Jan 11 20:33:33 ok.. will try tomorrow, now I have to go, thanks Jan 11 20:35:54 * Tartarus rekicks builds with DISTRO_TYPE = "release" Jan 11 20:38:58 fwiw boost 1.45 builds ok on angstrom-2010 Jan 11 20:40:01 are obvious fixes ok to push without approval? Jan 11 20:41:45 03Bernhard Reutner-Fischer  07master * r0f2330dd7a 10openembedded.git/classes/patch.bbclass: Jan 11 20:41:46 patch.bbclass: conditional patch-tool dependency Jan 11 20:41:46 only depend do_patch on patch-tool if recipe references any patch Jan 11 20:41:46 The whole of do_patch should be gated through a facility to determine if Jan 11 20:41:46 there is any patch at all. TODO. Jan 11 20:41:46 Acked-by: Leon Woestenberg Jan 11 20:41:47 Signed-off-by: Bernhard Reutner-Fischer Jan 11 20:42:51 like the following one: Jan 11 20:42:54 03Bernhard Reutner-Fischer  07master * r71a9d34fe2 10openembedded.git/recipes/gcc/gcc-svn/gcc-flags-for-build.patch: Jan 11 20:42:54 gcc-svn: remove unrelated hunk from patch Jan 11 20:42:54 It provokes conflicts later on, so drop it since it serves no real use. Jan 11 20:42:54 Signed-off-by: Bernhard Reutner-Fischer Jan 11 20:44:26 I will really call them DISTRO_FEATURES_EGLIBC Jan 11 20:45:39 mickeyl, you say you were building (way back) pyqt against qt-embedded - do you know what qt version you were building against? I ask because I would like to get that working for comparison purposes. I find that most recent pyqt-4.4.3 recipe supports qt4.4.1 and I don't see any recipes for qt versions that old Jan 11 20:46:22 i have trouble logging into https://patches.openembedded.org/ Jan 11 20:46:37 what sort Jan 11 20:46:39 it says -ENOLISTEN ? Jan 11 20:46:49 its not https Jan 11 20:46:51 its http Jan 11 20:46:58 it only listens on :80 :( Jan 11 20:47:03 yes Jan 11 20:47:31 I think whole oe.org is like that Jan 11 20:47:57 oh. Who's hosting oe.org? Jan 11 20:48:04 osuosl Jan 11 20:49:56 khem, great. Let's bug Ramereth then, ok? Jan 11 20:50:21 blindvt: ka6sox is our infra guy Jan 11 20:50:23 he can help Jan 11 20:50:42 or should the SC do that as I'm just an innocent bystander Jan 11 20:51:56 ka6sox, ping. Can you please bug osuosl to get oe ssl certs for patches.oe.org and all the other virtual hosts? A wildcard cert should do for most users, i guess Jan 11 20:52:38 ka6sox, many TIA :) Jan 11 20:59:22 ericben, btw.. what do you think about just adding references to patches for busybox instead of the full versions. This would avoid cluttering up the history in the repo.. Jan 11 21:00:01 blindvt: no problem will do next time Jan 11 21:00:15 blindvt: only the hash you mean ? Jan 11 21:01:03 ericben, SRC_URI="http://git.busybox.net/whatever/?commit=0x0815;format=patch" or however it's spelled Jan 11 21:02:21 blindvt: but in that case we need checksum for each patch ? Jan 11 21:02:59 03Khem Raj  07master * rbb4736056d 10openembedded.git/recipes/linux/linux-ixp4xx.inc: Jan 11 21:02:59 linux-ixp4xx.inc: Add DEPENDS on zd1211-firmware Jan 11 21:02:59 Signed-off-by: Khem Raj Jan 11 21:03:01 ericben, could be, didn't try (i always use busybox_git) Jan 11 21:03:10 03Khem Raj  07master * r754fed9f4b 10openembedded.git/conf/distro/include/slugos.inc: Jan 11 21:03:10 slugos.inc: Use bluez4 as default provider for bluez-libs Jan 11 21:03:10 Signed-off-by: Khem Raj Jan 11 21:03:17 and the patches are moving each time (date change inside) so the checksums would need to be updated Jan 11 21:03:47 and now that bitbake master has changed the way it logs checksums, this is more complicated than before to simply copy/paste 2 lines Jan 11 21:05:35 ericben, btw.. B921600.patch was applied for anything >= 1.16.0. Let alone the bug that it's still in there, the patch-tool should really not silently re-apply patches the way it does today Jan 11 21:07:30 ericben, i have a patch to remove the B921600.patch lying around (ugh, what a mess), but perhaps you want to fix that and push it instead of /me factoring it out sometimes later on or never ;) Consider such a patch pre-approved Jan 11 21:08:12 blindvt: feel free to push you patch else I'll try to think to remove B921600.patch next time ;-) Jan 11 21:08:30 ericben, really? I'd guess the checksum should be stable per commit Jan 11 21:09:23 ericben, we're checksumming file-content, not file-metadata like local mtime for patches and tarballs Jan 11 21:09:55 blindvt: ah you're right, I was talking of the patches in http://busybox.net/downloads/fixes-1.18.1/ Jan 11 21:10:33 blindvt: I'll try what you suggest locally to see if that work fine Jan 11 21:10:40 ericben, these, too, don't ever change once created. Jan 11 21:11:17 blindvt: just check the date of the files ... one patches was pushed and 5 have a new date Jan 11 21:11:29 ericben, either using /downloads/fixes-x.y.z/ or a commit is fine with me as long as we don't journal the patches itself in oe's history Jan 11 21:12:45 ericben, even if upstream mtime changes, the hash doesn't change for the content iff the content is unchanged. If vda changes content we'll yell at him, but he won't do that Jan 11 21:13:01 blindvt: by "journal the patches", you mean having the patches in the files directory ? Jan 11 21:13:15 ericben, yes Jan 11 21:13:31 blindvt: look here : http://cgit.openembedded.net/cgit.cgi/openembedded/commit/?id=92e33f3a889d9bd91907869f151e5144f459bb25 Jan 11 21:13:48 blindvt: 1st patch was regenerated and the date changed Jan 11 21:14:07 blindvt: that what breaks checksums Jan 11 21:14:20 sorry, that's what breaks checksums Jan 11 21:14:32 ericben, ugh indeed. So don't use fixes/ but the commits Jan 11 21:15:07 blindvt, I'll look into that with Lance Jan 11 21:18:56 blindvt: yes will try this thanks for the feedback Jan 11 21:23:25 ericben, i've asked him to fix his habit: see bb ML "QA issue with downloads/fixes-x.y.z/*.patch" Jan 11 21:24:07 ka6sox, great! Jan 11 21:28:34 ericben, it would be much easier if he just committed or cherry-picked the fixes to the respective stable branches before the fact instead of doing it in reverse, but whatever Jan 11 21:28:51 blindvt: yes that would be simpler Jan 11 21:32:32 khem, Iff Carmelo really sends in protected symbols tomorrow then it would make sense to do another rc, even if it would delay the release for another 7-10 days or so. I won't be able to react until tuesday so if you happen to like it _and_ jocke agrees then please push it in the meantime Jan 11 21:35:09 blindvt: sure Jan 11 21:35:24 yeah rc would make sense Jan 11 21:35:47 khem: hi Jan 11 21:36:10 hrw: hi Jan 11 21:36:48 khem: I see that more and more our patches lands in OE - good job Jan 11 21:37:10 yeah but I am not happy with the quality of the patches Jan 11 21:37:50 there is a lot of work needed to get them working in OE Jan 11 21:37:58 more than anything its testing overhead Jan 11 21:38:54 non-arm archs breakage? Jan 11 21:39:01 even arm arch breakge Jan 11 21:39:16 I think you guys only bother about armv7 Jan 11 21:39:21 thats not enough for OE Jan 11 21:39:26 I know Jan 11 21:39:34 and yes, armv7 is target Jan 11 21:39:42 khem we do get the patches broader exposure Jan 11 21:39:59 I think it would be good if you guys did some minimal verification on armv5 as well Jan 11 21:40:00 we should encourage them to use OE to test their patches on more machines :) Jan 11 21:40:08 there are lot of devices using armv5t Jan 11 21:40:42 yes infact linaro should seriously consider using OE infra Jan 11 21:41:01 can you guys suggest that on linaro-toolchain ML? Jan 11 21:41:07 hrw: may be an idea for you in your next meeting :) Jan 11 21:41:35 yeah suggeting on ml can be done Jan 11 21:41:46 its not only for toolchain Jan 11 21:41:54 but also for other workgroups you have Jan 11 21:41:55 khem: we have a face to face meeting whole week now Jan 11 21:42:01 even better Jan 11 21:43:13 khem: btw - where do you live? Jan 11 21:43:13 so far people think linaro's focus is to improve OSS for arm in general Jan 11 21:43:17 and not only for armv7 Jan 11 21:43:25 hrw: I am in San Jose CA Jan 11 21:43:39 * hrw in Dallas, TX this week Jan 11 21:43:47 ah Jan 11 21:43:57 never been there Jan 11 21:44:16 for me so far it is the farest west I went Jan 11 21:44:53 heh ok Jan 11 21:46:28 khem: since the begining Linaro is clear in the fact that they concentrate on armv7 and not arm in general Jan 11 21:46:55 and this cycle mainly on A9 even Jan 11 21:47:41 well thats not what I got from Talk I attended at ARM Techcon from linaro CEP Jan 11 21:47:43 CEO Jan 11 21:48:03 khem: talk to technical peoples not to CEO with their powerpoints ;-) Jan 11 21:48:20 heh Linaro CEO is pretty techie Jan 11 21:48:58 in any case if they have to make patches that go upstream into gcc then they better work on whole spectrum Jan 11 21:49:22 at least make sure they do not introduce regressions Jan 11 21:49:30 agree Jan 11 21:50:01 khem: check the executive overview : http://www.linaro.org/assets/ExecsummaryQ410.pdf they clearly only mention a8 & a9 Jan 11 21:51:01 btw I was right, this doc it's produced with PowerPoint ;-) Jan 11 21:51:19 modern ARM SoCs Jan 11 21:51:20 hmmm Jan 11 21:51:52 but in picture it says arm9 arm11 too Jan 11 21:52:04 khem: and here : http://www.linaro.org/getting-started/ at get some hardware Jan 11 21:52:19 yeah they only have Tegras Jan 11 21:52:25 and beagles I think Jan 11 21:52:28 that I know Jan 11 21:52:57 that's fun : they recommend panda boaord, but TI doesn't sell OMAP4 for under several hunderd thousand of pieces ! Jan 11 21:53:22 right Jan 11 21:53:27 Panda is A9 based Jan 11 21:53:47 so may be they will have beagle2 as catalog version may be Jan 11 21:53:51 need to ask TI Jan 11 21:55:13 actuallyy ti seems focus on A8 for industrial markets : they announced 1.5 GHz with SATA & PCI Express : http://focus.ti.com/paramsearch/docs/parametricsearch.tsp?family=dsp§ionId=2&tabId=2687&familyId=1987¶mCriteria=no Jan 11 21:55:40 hmm interesting Jan 11 21:56:07 ericben: whats that story with LC_ALL = C Jan 11 21:56:49 I think if you use export LC_ALL = "C" Jan 11 21:57:04 then it will effect message reporting of different programs Jan 11 21:57:15 for non engish locales I think Jan 11 21:58:25 khem: the problem is with perl. To generate miniperl it's using outputs of sytems tools and hack them. If the tool works in english : no problme that works. If it talks french that fails and miniperl is not built. Jan 11 21:58:55 so u say its broken for non english langauages ? Jan 11 21:59:05 and does it work with C locale Jan 11 21:59:10 even for french lang Jan 11 21:59:19 khem: yes Jan 11 21:59:23 hmm Jan 11 21:59:27 this was set in bitbake but was recently removed Jan 11 22:00:31 onemoment, I find the exact place in the code Jan 11 22:01:23 why was it removed ? Jan 11 22:03:55 khem: http://www.nntp.perl.org/group/perl.perl5.porters/2008/02/msg133873.html Jan 11 22:04:10 this is the exact description of the problem and the way it's workaround in perl Jan 11 22:04:35 khem: I don''t know. kergoth` told me that this should go in .conf or base.bbclass Jan 11 22:05:04 I have export LANG=C in testbuilder Jan 11 22:05:13 very useful :) Jan 11 22:09:17 hi mickey| Jan 11 22:09:28 hi hrw Jan 11 22:09:40 blindvt: tried with http://git.busybox.net/busybox/patch/?id=8030a1484917d5b71d5ccd1a1d28a29da7a3d7f0;apply=yes;striplevel=0;name=bb181-01 but this doesn't work because of the name of the fetched file Jan 11 22:10:10 blindvt: no more idea now will see later Jan 11 22:10:16 bye Jan 11 22:23:37 Hi. When I build my image, libxml2 runs into trouble and I'd like to see which package needs it. "bitbake -v" shows some "selecting ... due to" messages, but no libxml2 before it starts do_compile. Is there a better way to show the reason a package is being built? Jan 11 22:26:12 hoj, see the -g option to bitbake. specifically, 'bitbake -g -u depexp your-image' will probably help Jan 11 22:27:54 Hm, I tried -g, and converted to .ps which displayed nothing. Looks like my old bitbake doesn't have -u. I think -D might be what I'm looking for... Jan 11 22:31:38 hoj, for older bitbake, try using the script at contrib/dependsgraph/dependsgraph.sh Jan 11 22:32:16 in the past, i've found it easiest to modify that script so that it just outputs the text file instead of making an image Jan 11 22:32:38 the text file will be more or less human readable and you can search for the package you are interested in Jan 11 22:33:35 the reduced .dot file is the one that should be helpful... Jan 11 22:38:04 grg: Thanks. I ran the script and it gave me an image of which packages libxml2 requires, but not which require libxml2. I'll play with it. Jan 11 22:39:08 hoj, you need to make sure you do bitbake -g your-image and not bitbake -g libxml2... Jan 11 22:40:14 grg: Yeah, looks like the script just picks up the last generated .dot, so that makes sense Jan 11 22:40:26 yes Jan 11 22:40:55 thanks Jan 11 22:54:19 hi guys. is there somewhere a documentation / hint for migrating oe for my distribution to a current one? Jan 11 22:55:02 paepke: can you extend question? Jan 11 22:57:08 grg: my image reduced.dot does not contain libxml2. Is it possible that libxml2 is half built and needs to be purged? BTW, I already tried -c clean Jan 11 22:58:25 hrw, i'm currently stuck with keeping my distribution up2date with current recipies. eg. i have currently x-org 1.5. Jan 11 22:58:29 hoj, i don't actually understand what problem you are trying to solve. Can you elaborate? Jan 11 22:59:27 hoj, Does the depends.dot contain libxml2 (in any form, e.g. a -dev) Jan 11 22:59:27 hrw, so my intention was to upgrade to a newer OE, but I didn't find a guideline how to manage it the best way. If there is none and its just catching the errors, i can live with it. Jan 11 22:59:44 grg: I want to not build libxml2 since it fails in do_compile. I think it must have gotten pulled into my build at some point, but I'd like to remove it, and what ever requires it. Jan 11 23:00:04 it should appear in the reduced.dot Jan 11 23:00:32 if not, i suppose something odd is happening. Maybe its in the depends.dot as a -dev or other variant? Jan 11 23:01:01 paepke: I would extract your configs/recipes from your branch, add them into current and do build Jan 11 23:01:17 paepke: then adapt your configs/recipes to build/work if there are problems Jan 11 23:01:35 grg: Ah, the depends.dot was it. It's in there. Thanks Jan 11 23:01:50 paepke: thats more or less what I did when I was switching buglabs from Poky to OE or Vernier from old Poky to newer one Jan 11 23:01:54 hrw, ok. that was my primary idea, too. Jan 11 23:02:15 hrw, thanks Jan 11 23:02:36 paepke: it requires some work but is doable Jan 11 23:03:36 hrw, yes. some work :-). i've never done it. so lets have a look. Jan 11 23:05:57 bye Jan 11 23:14:07 khem, ping Jan 11 23:14:47 khem, http://pastebin.com/PMwXKu8A Jan 11 23:19:14 Tartarus: is that bison recipe native-sdk-image pcc/uclibc Jan 11 23:19:25 Tartarus: I know that problem too Jan 11 23:19:32 it was there in glib Jan 11 23:19:34 as well Jan 11 23:19:43 again assumption is glibc Jan 11 23:19:58 my guess is it needs to be solved same way we did for glib Jan 11 23:20:05 err gnulib Jan 11 23:27:32 khem, k Jan 11 23:27:36 and yes Jan 11 23:33:15 hrw: how is your timezone difference this time? :) Jan 11 23:34:48 Jay7: 17:30 here now Jan 11 23:35:17 hrw: and how is your feeling this time? :) I remember last time you was tired :) Jan 11 23:35:33 Jay7: this time no jetlag Jan 11 23:35:46 at least not as bad as last time Jan 12 01:02:59 Hmmm Jan 12 01:03:07 I think ac_cv_func_dlopen in site/powerpc-common is wron Jan 12 01:03:08 g Jan 12 01:03:12 and why mesa is broken Jan 12 01:04:06 w/ it we of course get "checking for dlopen... yes (cached)" Jan 12 01:04:14 and without that's no and it learns it is in -ldl Jan 12 01:04:45 claims modphp needs it, testing that one next Jan 12 01:08:17 khem, I also see that bison thing on arm... so I guess it's a uclibc thing Jan 12 01:43:05 * Tartarus throws his hands up at apache2 Jan 12 01:50:29 Tartarus: i think that's a pretty common reaction Jan 12 02:02:41 heh Jan 12 02:50:14 hey all Jan 12 02:52:03 I'm trying to compile an SHR image for the iPhone 3G, but I'm running into some problems with bitbake. Anyone mind taking a look at my pastebin? http://pastebin.com/e6DJ5iSR Jan 12 02:52:50 Lopi, git.freesmartphone.org[0: 134.169.172.109]: errno=Connection timed out Jan 12 02:52:55 are you behind a firewall? Jan 12 02:53:35 grg: yeah, but I don't have access to make changes Jan 12 02:53:35 corporate firewall == unhappy developer Jan 12 02:54:25 this sort of thing crops up quite a lot. Check the mailing list archives or the wiki... Jan 12 02:54:30 it's surprising my apartment complex is behind smoothwall Jan 12 02:54:44 hm okay Jan 12 02:55:11 i think there were some patches for getting via http or something.... dunno, i've not been paying attention to the lists much these past 3 weeks Jan 12 02:55:19 question though, why don't I get the same errors when I issue bitbake shr-image the second time? Jan 12 02:58:13 Lopi, looks like you're hitting a bug in some error handling code Jan 12 02:58:31 Lopi, try updating bitbake, see what that does for you Jan 12 02:58:43 grg: okay will do thanks for the help **** ENDING LOGGING AT Wed Jan 12 02:59:58 2011