**** BEGIN LOGGING AT Thu Dec 03 04:00:14 2009 Dec 03 06:48:26 03Martin Jansa  07org.openembedded.dev * r8874a6fd4c 10openembedded.git/recipes/librsvg/librsvg-native_2.26.0.bb: librsvg-native: add native package for navit-icons Dec 03 07:11:56 any ideas why I would get this error: gcov-iov.o: file not recognized: File format not recognized Dec 03 07:12:46 When compiling gcc-cross-intermediate_4.3.3.bb ? Dec 03 07:19:42 hvontres|home: is this file zero byte long? Dec 03 07:24:37 zecke: nope.. : -rw-r--r-- 1 henry henry 3226 2009-12-02 00:05 ./build.x86_64-linux.arm-angstrom-linux-gnueabi/gcc/build/gcov-iov.o Dec 03 07:25:45 hvontres|home: what does file say about this file? Dec 03 07:26:29 zecke: gcov-iov.o: ASCII English text, with very long lines Dec 03 07:26:49 hvontres|home: oh...can you open it? Dec 03 07:28:26 zecke: hmm... looks like it's a Makefile.in that somehow got copied to the wrong spot. Dec 03 07:30:54 ~pastbin Dec 03 07:31:00 ~pastebin Dec 03 07:31:02 [~pastebin] A "pastebin" is a web-based service where you can paste anything over 3 lines without flooding the channel. Here are links to a few : http://www.pastebin.com , http://pastebin.ca , http://channels.debian.net/paste , http://paste.lisp.org , http://www.rafb.net/paste Dec 03 07:35:13 zecke: log.do_compile: http://pastebin.com/m3b66026a Dec 03 07:45:21 zecke: hmm, looks like m4-native and some other tools didn't build before. I am going to try a clean and rebuild. Dec 03 08:01:52 night all Dec 03 08:10:09 good morning Dec 03 08:12:09 gm Dec 03 08:38:49 morning Dec 03 08:39:21 hrw: hey Dec 03 08:46:54 03Marcin Juszkiewicz  07org.openembedded.dev * rf94c8a89fc 10openembedded.git/recipes/linux/linux_2.6.32.bb: linux: added 2.6.32 Dec 03 08:51:13 03Koen Kooi  07org.openembedded.dev * r0bb8648bf4 10openembedded.git/recipes/xorg-util/util-macros_1.3.0.bb: util-macros: add 1.3.0 (from Martin's branch) Dec 03 08:51:14 03Koen Kooi  07org.openembedded.dev * r2e2d343526 10openembedded.git/: Merge branch 'org.openembedded.dev' of git@git.openembedded.org:openembedded into org.openembedded.dev Dec 03 08:58:52 03Kristoffer Ericson  07org.openembedded.dev * r33497aded7 10openembedded.git/conf/distro/jlime-2009.1.conf: Dec 03 08:58:52 Add more preferred providers/version to jlime-2009 Dec 03 08:58:52 Signed-off-by: Kristoffer Ericson Dec 03 08:58:54 03Kristoffer Ericson  07org.openembedded.dev * rc3cd564320 10openembedded.git/recipes/cdparanoia/ (cdparanoia/configure.in.patch cdparanoia_10.2.bb): Dec 03 08:58:55 Fix configure error (no 16bit type!) Dec 03 08:58:57 Signed-off-by: Kristoffer Ericson Dec 03 08:58:59 03Kristoffer Ericson  07org.openembedded.dev * r34d47c70a2 10openembedded.git/conf/distro/jlime-2009.1.conf: Dec 03 08:59:02 Add e2fsprogs-libs-native version to jlime-2009.1 Dec 03 08:59:04 Signed-off-by: Kristoffer Ericson Dec 03 08:59:06 03Kristoffer Ericson  07org.openembedded.dev * rbfdc490812 10openembedded.git/conf/distro/jlime-2009.1.conf: Dec 03 08:59:09 Add gettext version to jlime distro file. Dec 03 08:59:11 Signed-off-by : Kristoffer Ericson Dec 03 09:02:06 DJWillis, hi! Dec 03 09:02:30 Hi Dec 03 09:03:13 I've hit the same problem sakoman__ described here earlier (http://pastebin.com/m2b4aa878) Dec 03 09:03:59 I'm not OE expert and didn't quite understood why is this happening, can you please explain? Dec 03 09:09:21 mike^: for the same packages? You need the fixes for the recipes, that is the long and short of it. Dec 03 09:09:53 DJWillis, I get problems with networkmanager and then task-beagleboard-demo Dec 03 09:10:53 mike^: I don't know if sakoman__ has pushed his fixes. The udev fix is in mainline. Ok, I have not looked at networkmanager to fix, just some of the others, your going to have to wait for sakoman__ to push the fixes or knock up a patch yourself. Dec 03 09:11:34 mike^: if you grep your log for 'opkg: ' you will see the exact error (i.e. what really failed) so you can then have a stab at fixing. Dec 03 09:11:49 DJWillis: I wish I knew what fix should be done :) anyway, I'm going to try now with mainline, thanks a lot Dec 03 09:12:27 mike^: I have not see the networkman patch go in so I expect it will fail again ;) Dec 03 09:26:24 bloody autoconf, why is it failing in wierd and wonderful ways omn avr32 Dec 03 09:33:10 shit I think the coreutils-native do_install is totally wrong Dec 03 09:36:25 XorA: well that would cause quite a bit of breakage Dec 03 09:36:29 ;-) Dec 03 09:36:54 all the commands are blah.coreutils-native Dec 03 09:37:06 we dont do u-a on tmp/staging Dec 03 09:38:07 how can i remove the source files during bitbake run? AFAIK rm_work remove that after a complete build Dec 03 09:45:04 03Graeme Gregory  07org.openembedded.dev * r6a8c9d9393 10openembedded.git/recipes/coreutils/coreutils-native.inc: Dec 03 09:45:04 coreutils-native.inc : fix staging of coreutils-native Dec 03 09:45:04 Was inheriting the u-a renaming from non native version and we dont Dec 03 09:45:04 do u-a on staging so all utils had a silly name Dec 03 09:59:54 good morning Dec 03 10:00:02 yo florian Dec 03 10:08:15 DJWillis: mainlile build worked just fine :) Dec 03 10:14:08 paroli_git.bb have edbus-ehal in RDEPENDS, but efl1/edbus_svn.bb won't be built and do_rootfs will fail later.. should I add edbus to DEPENDS there? or is there better fix for that? Dec 03 10:15:27 * XorA suddenly wishes ipkg-make-index wasnt written in python Dec 03 10:15:31 ~curse python Dec 03 10:15:39 May you be reincarnated as a Windows XP administrator, python ! Dec 03 10:18:23 mike^: oh, great :), glad it's working Dec 03 10:32:28 XorA: well.. they could have used Perl ;) Dec 03 10:34:07 florian: at least perl is compatible between minor versions Dec 03 10:44:04 good morning Dec 03 10:45:52 how can i rebuilt all *-native packages? Dec 03 10:52:41 rm tmp/stamps/*/*-native* Dec 03 10:52:56 this will kill stamps so bitbake will think that they were not built Dec 03 10:55:46 hrw: thanks, i'll try Dec 03 11:09:17 Hi guys :) I'm really getting frustrated with the "mesa" stuff! - http://pastebin.ca/1699968 - I've tried to set virtual/libgl:mesa in my local.conf, but it doesn't work ..??! Dec 03 11:10:06 Btw. which way is the right one - PREFERRED_PROVIDERS += " virtual/libgl:mesa" or PREFERRED_PROVIDER_virtual/libgl = "mesa"? Dec 03 11:12:55 why does my python-native have no md5 module?? Dec 03 11:16:28 Hrww: thx for committing 2.6.32...(you were faster than me:_) Dec 03 11:16:33 ant_work: ;D Dec 03 11:16:48 now th edefconfigs... Dec 03 11:16:55 ant_work: for you I left easiest part - running 2.6.32 on zauruses Dec 03 11:16:56 Looks like I have a candidate for this soon :) Dec 03 11:17:09 florian: ? Dec 03 11:17:15 * florian just updated his Topas kernel tree to 2.6.32. Dec 03 11:17:26 ah Dec 03 11:17:38 I have ep93xx built but not tested yet Dec 03 11:18:05 the problem can be with those boards on ram init Dec 03 11:18:50 and I need to build zImage and uImage in one run Dec 03 11:21:53 btw, anyone willing to fix (busybox) procps to make 'Unknown Hz' disappear? Dec 03 11:22:11 Does anybody have good or bad experiences with MESA? Dec 03 11:23:11 ant_work: in other way then 'opkg install procps'? Dec 03 11:24:26 recent procps shouldn't have the issue anymore Dec 03 11:24:42 but we are using busybox one? aren't we? Dec 03 11:25:13 depends Dec 03 11:25:14 florian: good morning Dec 03 11:25:21 hey pb_ Dec 03 11:25:26 on BUG I have task-proper-tools by default Dec 03 11:25:34 I see Dec 03 11:26:00 mickey|office: good morning Dec 03 11:26:12 pb_: hello there Dec 03 11:26:17 hi ant_work Dec 03 11:41:15 morning pb_ Dec 03 11:43:20 mickey|office: in your python guru clothes, what would stop python-native having md5 module so ipkg-make-index cant run Dec 03 11:47:52 md5 module is only used if hashlib is not found Dec 03 11:48:08 hashlib in turn needs _hashlib, which is a compiled module Dec 03 11:48:14 perhaps this was not built / can not be loaded Dec 03 11:48:18 then it falls back on md5 Dec 03 11:51:50 mickey|office: anything that would cause hashlib to not build? Dec 03 11:52:20 not offhand Dec 03 11:52:40 arse Dec 03 11:52:41 would need to inspect the build log Dec 03 11:52:46 this is annoying Dec 03 11:52:52 Zecke: I'm sorry, but it looks like django-oestats cannot be updated on melo. The software now requires a newer python-support package. I recompiled that, but that in turn depends on a newer dpkg which depends on a newer libc6. I'm afraid that's not going to happen. Dec 03 11:52:59 zecke: The best option is probably to ask Jeremy to relax the python-support dependency by rewriting some of the code. Dec 03 11:53:03 Laibsch: oh, what happens when we just reduce the dependency? Dec 03 11:53:15 I haven't tried, but I think that is just asking for trouble Dec 03 11:53:23 They are listed explicitly with that version. Dec 03 11:53:55 Ask Jeremy if django-oestats can run with an older python-support package Dec 03 11:54:24 I guess we could also move oestats to ltg if it isn't practical to upgrade it on melo. Dec 03 11:54:35 * Laibsch is worried about stability on ltg Dec 03 11:55:06 ltg doesn't have a good track record Dec 03 11:55:20 well, oestats isn't exactly mission-critical infrastructure Dec 03 11:55:34 Laibsch: Since the upgrade its pretty nice. Dec 03 11:55:34 and therefore what is the reason we absolutely need to update it? Dec 03 11:55:36 and I haven't actually noticed any stability problems on ltg for the past several months. Dec 03 11:55:36 define nice Dec 03 11:55:36 And its easy to jump in and help since its meant to be maintained by community people, Dec 03 11:55:44 Laibsch: because the new version has some features that we would like to use. Dec 03 11:56:03 feel free to move it if you insist Dec 03 11:56:15 I'm not sure if it's a good idea Dec 03 11:56:28 And I certainly won't spend time on it Dec 03 11:56:41 Hum well... even the fact that we have an update justifies using it. If not even OE uses it... Dec 03 11:57:10 florian: I spelt out the reasons it can't be done Dec 03 11:57:21 not on melo Dec 03 11:57:40 mickey|office: ahah, selinux issue, openssl has executable stack Dec 03 11:57:47 Are there any backports.org packages which would help? Dec 03 11:57:55 broonie: I can backport stuff Dec 03 11:57:57 Laibsch: let's look at the changelog and see why he bumped it? Dec 03 11:58:01 XorA: righto, that would be a problem Dec 03 11:58:02 And I do Dec 03 11:58:30 Laibsch: Sure, it's just that there's no need for you to bother if it's already been done. Dec 03 11:58:30 broonie: I stopped when I would have had to backport dpkg (and thus libc6) Dec 03 11:58:30 mickey|office: I was looking for md5 errors why I didnt notice it Dec 03 11:59:05 and other folks would've avoided those things too Dec 03 11:59:38 broonie: ? "those things"? Dec 03 11:59:49 libc and dpkg dependencies Dec 03 11:59:50 Laibsch: where is the new dependency coming from debian/control? What version is it? Dec 03 12:00:38 Laibsch: the only noticable change in debian/control was... python-oestats -> django-oestats Dec 03 12:00:58 Laibsch: and bumping Standards-Version and the debhelper requirement Dec 03 12:01:15 zecke: again, django-oestats now explicitly depends on a newer python-support package (as I said, the easiest is to ask Jeremy if the code can easily be rewritten to work with the old package, that is my recommendation). Backporting python-support means backporting dpkg which means backporting libc6 and thus is not happening. Dec 03 12:11:32 morning all Dec 03 12:12:42 hi rp Dec 03 12:13:51 hi RP Dec 03 12:17:04 RP: sorry if I repeat myself...it seems all log.packagedstaging_fastpath are broken. Any idea? Dec 03 12:18:50 Laibsch: Sorry, I'm not following. So you say in your debian/control is a python-suport (>= Some.thing)? Dec 03 12:20:57 oddly, the copy of django-oestats that I just checked out doesn't seem to depend on any particular version of python-support. Dec 03 12:21:08 maybe I am looking at the wrong branch, though it does claim to include your waterfall bits. Dec 03 12:21:25 zecke pasted "my debian/control" at http://paste.lisp.org/display/91507 Dec 03 12:22:03 pb_: so yours looks like this too? Jeremy has changed the Standard-Version this year... I'm not sure if it has influence beyond sanity checking Dec 03 12:23:38 I doubt the Standards-Version would cause a major problem although I guess it is possible. Dec 03 12:23:56 what version of debian is melo actually running, lenny? Dec 03 12:25:38 pb_: Ubuntu Hardy Dec 03 12:26:07 ah right, let me look at what versions are in hardy Dec 03 12:30:22 standards-version has no practical effect at all Dec 03 12:31:28 but there may have been other changes at the same time if policy required them Dec 03 12:31:39 hardy seems to have python-support "0.7.5ubuntu1", which is admittedly quite a bit older than the current debian version. Dec 03 12:32:36 florian: could you see what version of python-support is on ltg? I don't seem to have any ssh key on this machine that will let me log in. Dec 03 12:33:00 Laibsch: thanks for giving it a try (btw) Dec 03 12:35:53 pb_: We have 0.8.4lenny1 installed right now. Dec 03 12:36:22 okay, thanks. I wonder if that would be new enough. Dec 03 12:36:36 I still can't see exactly where this dependency is coming from so I am not quite sure what version is required. Dec 03 12:42:01 There have been some changes in the way Python modules are packaged. Dec 03 12:43:03 IIRC it may not actually require any changes in the package itself, it may just be the case that the dependency is used to make the upgrade go smoothly Dec 03 12:43:09 However, don't quote me on that. Dec 03 12:43:36 it was a while ago Dec 03 12:43:58 See the changelog for python-support 0.90.0 Dec 03 12:44:33 Is it possible to have multiple OE build configurations? Dec 03 12:44:38 Concurrently Dec 03 12:45:11 I currently have the normal build, openembedded, sources and tmp dirs for ARM Dec 03 12:45:20 But I also want to make SH3 builds. Dec 03 12:45:48 So I made build-j6xx, openembedded-j6xx (updated differently) and tmp-j6xx Dec 03 12:46:08 And I point to them in build-j6xx/conf/local.conf Dec 03 12:46:34 But running bitbake nano in the build-j6xx directory tries to build the ARM thing Dec 03 12:46:47 And doesn't use the -j6xx directories Dec 03 12:47:56 B_Lizzard: sounds like a wrong environment setting Dec 03 12:48:32 Oh shit right, BBPATH Dec 03 12:49:24 I'd have to source another file everytime I build for SH3, right? Dec 03 12:50:15 yes... or pass it as a parameter Dec 03 12:50:57 I'll see what's more confortable... Dec 03 12:51:01 Thanks, florian Dec 03 12:51:02 ;) Dec 03 12:51:15 B_Lizzard: yw Dec 03 12:53:33 Great, it works just fine Dec 03 12:53:38 Thanks again Dec 03 13:02:49 zecke: We may be in luck. You are right, there is no particular version required in debian/control itself. I was looking at the wrong directory (had been backporting bitbake as well). But the binary package required python-support > 0.9 nonetheless. That may be due to the package being compiled for karmic. I will rerun a compilation for hardy now. Dec 03 13:29:35 03Koen Kooi  07org.openembedded.dev * r217fedb3d9 10openembedded.git/recipes/linux/ (linux-omap-2.6.32/beagleboard/defconfig linux-omap_2.6.32.bb): linux-omap 2.6.32: start recipe for it Dec 03 13:30:57 03Graeme Gregory  07org.openembedded.dev * r1ac69df768 10openembedded.git/conf/distro/angstrom-2008.1.conf: Dec 03 13:30:57 angstrom-2008.1.conf : update uclibc to latest bugfix release Dec 03 13:30:57 This was needed to clear some linking errors occuring on avr32 Dec 03 13:30:57 03Graeme Gregory  07org.openembedded.dev * r549b1eca05 10openembedded.git/recipes/cdparanoia/cdparanoia_svn.bb: Dec 03 13:30:59 cdparanoia_svn.bb : also add configure.in.patch to svn version Dec 03 13:31:01 This fixes the "No 16bit type found" error messages. Dec 03 13:40:03 zecke: We're not in luck. The package can be recompiled for hardy without having the requirement for a newer python-support package. But the web page crashes with the new package. There is no way around getting some support from Jeremy. Dec 03 13:52:04 03Koen Kooi  07org.openembedded.dev * r1f0439b0d7 10openembedded.git/conf/distro/include/sane-srcrevs.inc: opkg: bump SRCREV to get some more fixes Dec 03 13:55:02 Laibsch: do you think you could get a backtrace for jeremy and me? Dec 03 13:55:17 Laibsch: but thanks again for looking into it Dec 03 14:00:51 03Graeme Gregory  07org.openembedded.dev * r7159f335cf 10openembedded.git/recipes/openssl/openssl-native_0.9.8j.bb: Dec 03 14:00:51 openssl-native_0.9.8j.bb : set the noexec bit for stacks Dec 03 14:00:51 This is needed to stop tripping up security protections on Fedora 12 and Dec 03 14:00:51 probably other selinux using distros Dec 03 14:15:38 gm Dec 03 14:15:58 Do we have an arch in OE that is both MMU-less or MMU-full? If so, do we define different archs for the two combo'? Dec 03 14:16:37 DJWillis: no fix is required for networkmanager, network-manager-applet, or devkit-power. all three failures were related to the udev issue and were fixed by koen's udev fix Dec 03 14:17:53 XorA: see debian bug reports about 'udevsettle in /etc/rcS.d/S03udev always hangs and times out' Dec 03 14:17:59 Google Dec 03 14:18:10 DJWillis: for xorg-minimal-fonts I just moved the ln -sf that was in intall to a pkg_postinst_${PN}_append Dec 03 14:18:28 likewise: I can't think of one. If the binaries are different, but you want to support them in a single DISTRO, then it would make sense to define two separate arches. Dec 03 14:18:29 ( I didn't yet find the time to inspect a.m. file) Dec 03 14:19:37 ant_work: WHAT??? Dec 03 14:20:02 Angstrom ML posts Dec 03 14:20:19 whats that got to do with /tmp being not writeable Dec 03 14:20:47 pb_: the difference without a different arch name would be the target tripple: nios2-linux-gnu and nios2-linux-uclibc. I wonder if that is enough. Dec 03 14:21:09 pb_: I guess not, as the arch defines the binary ABI's. Dec 03 14:21:21 ant_work: the /tmp thing is because the udev caching code doesnt wait until volatiles is mounted Dec 03 14:21:38 likewise: if the ABI is different then yeah, clearly gcc and binutils need a way to know which you are requesting. Dec 03 14:21:51 XorA: so it's audev problem, isn't? Dec 03 14:22:01 tell K Dec 03 14:22:12 ant_work: no, its a badly written script in OE Dec 03 14:22:20 that would not generally be done with a different cpu name, though, you'd have something like 'nios2-linux-gnunommu' and 'nios2-linux-gnu' Dec 03 14:22:22 pb_: gcc and binutils use the full tripplet Dec 03 14:22:23 ant_work: assume / is always writeable Dec 03 14:22:43 ant_work: it shouldnt actually kill boot though Dec 03 14:23:09 03Koen Kooi  07org.openembedded.dev * r78c8ab4e06 10openembedded.git/recipes/linux/ (3 files in 3 dirs): linux-omap 2.6.32: add patch to fix EHCI Dec 03 14:23:44 florian: are all eV members defineately on mailing list now? Dec 03 14:24:08 XorA: I haven't checked... one sec Dec 03 14:24:32 florian: cool, I want to send a final TSC reminder tonight Dec 03 14:25:19 the checksum says: no Dec 03 14:26:15 morning Dec 03 14:26:25 hi hrw Dec 03 14:26:32 XorA: now :) Dec 03 14:28:10 florian: thanks Dec 03 14:29:48 03Kristoffer Ericson  07org.openembedded.dev * r1f16e2c5f9 10openembedded.git/recipes/gnome/ (gnome-keyring/fix_ta.po.patch gnome-keyring_2.28.0.bb): Dec 03 14:29:48 gnome-keyring 2.28 has a language file ta.po that fails to build. Dec 03 14:29:48 Looks like the file in question is in the progress of being Dec 03 14:29:48 translated. To fix this we remove the insulting lines. Dec 03 14:29:48 Signed-off-by: Kristoffer Ericson Dec 03 14:30:56 XorA: which 'badly written' script are you referring too? Self-built images boot just fine... Dec 03 14:31:26 ant_work: the one that caches /dev instead of using udev to generate it Dec 03 14:31:43 heh, the "insulting lines"? the mind boggles Dec 03 14:31:48 ant_work: if self built images work then compare the difference Dec 03 14:32:01 yep..just didn't yet find the time :) Dec 03 14:32:21 ...I was almost insluted after posting the two logs... Dec 03 14:32:32 (btw) Dec 03 14:33:10 * XorA hasnt had time to boot an OE build for weeks Dec 03 14:33:32 XorA, OMG! Dec 03 14:33:35 :Å Dec 03 14:35:17 * XorA just learns too much about autoconf Dec 03 14:39:56 I'm having a problem building gcc-cross-initial for SH3... Dec 03 14:40:03 fixproto: populating `include' Dec 03 14:40:10 CROSS COMPILE Badness: /usr/include in INCLUDEPATH: /usr/include Dec 03 14:40:24 Usually, it's some stray /usr/include in some makefile Dec 03 14:40:56 But I thought that this CROSS COMPILE Badness functionality is patched into gcc-cross... Dec 03 14:41:01 :/ Dec 03 14:41:16 it's patched into gcc-cross-initial as well, I think. Dec 03 14:41:21 look for patches with "zecke" in the name Dec 03 14:41:53 :( Dec 03 14:42:05 :-} Dec 03 14:42:16 But I'm *trying* to build gcc-cross-initial Dec 03 14:42:21 zecke: would you like me to rename those patches? Dec 03 14:42:36 B_Lizzard: indeed Dec 03 14:42:46 pb_: yeah, and maybe redo (to get the dirs to blacklist as param) Dec 03 14:42:51 Hehe Dec 03 14:43:27 zecke: good idea Dec 03 14:44:05 $ find . -name "*zecke*" | wc -l Dec 03 14:44:05 45 Dec 03 14:44:06 heh Dec 03 14:44:30 B_Lizzard, check those versions you use, so that they got zecke'ish patches applied in their .bb files Dec 03 14:44:45 patches/zecke-no-host-includes.patch Dec 03 14:44:47 :) Dec 03 14:44:50 yeah, that's the one Dec 03 14:45:02 Yeah, it's applied all right Dec 03 14:45:03 there's also a zecke-xgcc-cpp.patch, I don't quite know what that one does Dec 03 14:45:04 In gcc/c-incpath.c Dec 03 14:45:29 This is with gcc-cross-initial-4.2.2 Dec 03 14:45:42 So how does this work? Dec 03 14:45:55 It tries to build something with -I/usr/include? Dec 03 14:46:31 fix-header: Internal error: abort in add_path, at c-incpath.c:371 Dec 03 14:47:12 yeah, apparently its own header paths are somehow getting set wrong. Dec 03 14:47:21 what target triplet is this? maybe one of your tm-* files needs patching. Dec 03 14:47:32 pb_: xgcc patch I think makes sure we use cross cpp now host one Dec 03 14:47:43 target triplet? Dec 03 14:49:20 One of my tm-* files? Dec 03 14:49:24 *explode* Dec 03 14:50:17 B_Lizzard, what versions do you got? gcc, glibc, binutils? Dec 03 14:50:37 binutils 2.18, gcc 4.2.2, glibc 2.6.1 Dec 03 14:50:44 In OE, that is. Dec 03 14:51:25 Should I move gcc and glibc up a notch? Dec 03 14:57:46 B_Lizzard, worth a try Dec 03 14:58:04 * XorA wishes generating locales was faster Dec 03 14:58:30 XorA: you could try out the eleet cross-localegen from eglibc Dec 03 14:59:11 pb_: ah, didnt know about that, shall try it when I return to UK Dec 03 14:59:14 or unbundle the locales from glibc and build them separately, which would allow that to happen in parallel with other builds Dec 03 14:59:19 or generating just 2 or 3... Dec 03 14:59:33 ant_work: cant do that Dec 03 14:59:50 ant_work: well yeah, or that, but I assume xora is smart enough to have thought of that one already Dec 03 15:00:12 this is one of the offical angstrom builders running Dec 03 15:01:01 XorA: do big builds (with 8-10K tasks) so binlocales will be done before build finish Dec 03 15:01:10 sakoman__: nice, the whole XOrg fonts thing is also fragile, I managed to get every individual font to fail with permissions coming down to bugs in the way font-utils and encodings did the building of the font packages. Bumping them (and a lot of the font's) to the latest versions has made all those problems go away but I need to check there is no fallout with the XOrg version we use (docs suggest it's fine but we all know t Dec 03 15:01:10 hat does not always workout ;-)) Dec 03 15:01:14 XorA: bug-image-production is ~8900 tasks Dec 03 15:02:52 it would finish in 1/4 the speed if it didnt fall back to single core while doing it :-( Dec 03 15:03:14 * broonie gets his oe-members list subscription through finally Dec 03 15:03:22 XorA: so add code to run few instances of localedef at once? Dec 03 15:03:40 8455 tasks to go... Dec 03 15:08:29 hrw: Pandora Xfce image is 8363 tasks at the moment and getting very boring to maintain when my 'testers' like to report bugs 5 mins after I kick off a build - I guess all deadlines are flexable ;-) Dec 03 15:09:45 sakoman__: I pushed my XOrg font-* fudge-work to http://git.openpandora.org/cgi-bin/gitweb.cgi?p=openembedded.git;a=shortlog;h=op.openembedded.dev but I have a feeling it will just lead to me getting abuse for fixing it wrong ;-) Dec 03 15:09:54 DJWillis: use incremental builds? Dec 03 15:13:45 hrw: yep, but of late rebuilding from scratch has been called for a good few times. Dec 03 15:14:18 DJWillis: I use buildbot which do full and incemental builds Dec 03 15:14:22 DJWillis: why couldnt you just increment INC_PR? Dec 03 15:15:59 XorA: for the fonts stuff? Dec 03 15:18:16 XorA: there was no INC_PR, I added that to the include this morning to make it somewhat easier to do. Esp. as fonts can no go in lib/X11 or user/share/fonts/X11 in the specs. Dec 03 15:18:42 XorA: Of course I may have missed something obvious and wasted my time again, quite common that ;-) Dec 03 15:19:07 DJWillis: but if your new INC_PR is higher than the highest PR from old fonts, you dont need to PE bump Dec 03 15:19:16 DJWillis: of course both are cheap operations Dec 03 15:21:17 WTF Dec 03 15:21:48 OK, I deleted my tmp dir and changed glibc and gcc versions in the distro file Dec 03 15:22:07 I go into the build directory and type "bitbake nano" once again Dec 03 15:22:25 NOTE: Unpacking ../tmp-j6xx/deploy/sources/LGPL/shasum-native/main.c to ../tmp-j6xx/work/i686-linux/shasum-native-1.0-r1/ Dec 03 15:22:30 cp: cannot stat `/home/havoc/.oe/tmp-j6xx/deploy/sources/LGPL/shasum-native/main.c': No such file or directory Dec 03 15:23:20 Wait, what Dec 03 15:24:56 In the recipes/shasum/files dir I have three broken links pointing to /home/havoc/.oe/tmp-j6xx/deploy/sources/LGPL/shasum-native/main.c Dec 03 15:25:08 Ugh, you get the point Dec 03 15:49:21 XorA: Hmm, yep, I had to work out the practical diffs with PR/PV/PE today, I guess if I have pushed to high it's copy/paste errors with the new recipes. Still, not sure if the work is of use to anyone else but it's got my images building again so I am happy just to have that going for now ;-) Dec 03 15:50:41 morning Dec 03 15:51:11 DJWillis: I wonder why I'm not getting all the font package errors that you are Dec 03 15:51:25 I only had the issue with xorg-minimal-fonts Dec 03 15:51:34 and that was easy to fix Dec 03 15:52:34 03Koen Kooi  07org.openembedded.dev * r4ad8614261 10openembedded.git/recipes/gnome/ (gnome-keyring/fix_ta.po.patch gnome-keyring_2.28.0.bb): Dec 03 15:52:34 Revert "gnome-keyring 2.28 has a language file ta.po that fails to build." Dec 03 15:52:34 * The 'patch' is not a patch and breaks the build Dec 03 15:52:34 * The error this commit tries to fix can be remedied by using a more recent gettext-native Dec 03 15:52:36 This reverts commit 1f16e2c5f999a795b1dc77b2f2011f17a077f16e. Dec 03 15:54:21 DJWillis: what image recipe are you building? Dec 03 15:54:58 03Mike Rapoport  07org.openembedded.dev * r708eff3b14 10openembedded.git/recipes/tasks/task-beagleboard-demo.bb: Dec 03 15:54:58 task-beagleboard-demo: add e-wm-menu Dec 03 15:54:58 Signed-off-by: Mike Rapoport Dec 03 16:16:03 ant_work: Can you define "all broken" a little more clearly? Dec 03 16:19:40 RP: the log file starts with: cp: cannot .... and the path is very very strange... Dec 03 16:20:02 let me see if I pasted it somewhere Dec 03 16:22:27 yep Dec 03 16:22:28 cp: cannot stat `/oe/build/tmp/work/c7x0-angstrom-linux-gnueabi/base-files-3.0.14-r89/sysroot-destdir///oe/build/tmp/cross/armv5te/*': No such file or directory Dec 03 16:38:41 RP: seems to be Dec 03 16:38:42 cp -fpPR ${SYSROOT_DESTDIR}/${CROSS_DIR}/* ${PSTAGE_TMPDIR_STAGE}/cross/ || /bin/true Dec 03 16:48:22 sakoman__: my image is in the Pandora overlay, I expect that is why, it was pulling in XOrg fonts not the minimal working set that is usually pulled in. Dec 03 16:52:30 DJWillis: these are the fonts I include: http://pastebin.com/m5041820d Dec 03 16:53:45 hi ,what is libdb? I did a "find ./ | grep libdb" and I only found patches or perl things... Dec 03 16:53:56 ah ok maybe it comes from mysql Dec 03 16:54:16 isn't Berkeley db? Dec 03 16:54:18 sound like db 4.2 Dec 03 16:54:23 ah ok thanks Dec 03 16:54:47 better because mysql is a huge dep for libpam Dec 03 16:54:53 hehe Dec 03 16:56:11 sakoman__: http://pastebin.com/d6ace9b85 same for me now but it was the adobe one that failed so I added all the others, they also failed so I sorted out the lot in one go. Dec 03 16:56:13 is there a way to specify that all modules produced by the kernel should be included in the image? Dec 03 16:57:33 there's a bunch of stuff in kernel.bbclass which parses package names like 'kernel-module-foo123xyz' and adds just foo123xyz, but I want everything that the kernel is configured to build as a module Dec 03 16:59:14 Zygo: kernel-modules metapackage Dec 03 16:59:44 hmmm...if I just list 'kernel-modules' I get no modules at all Dec 03 17:03:17 Zygo: # Make sure we install all kernel modules with the Pandora images Dec 03 17:03:17 RRECOMMENDS_${PN} += "kernel-modules" << Works for me ;-), that's in one of my core task files that the image picks. Dec 03 17:04:18 DJWillis: MACHINE_RRECOMMENDS += "kernel-modules" in openpandora.conf is better maybe? Dec 03 17:04:28 I have IMAGE_INSTALL = " ... kernel-modules ... " Dec 03 17:05:19 hrw: pondered that but then if you get a really tiny image you don't want modules for (such as some of the validation images I build) that's not all that handy ;-) Dec 03 17:05:34 sure Dec 03 17:05:39 hrw: but, yep, that will work great, Zygo do that ;-) Dec 03 17:09:56 hmmm there was MACHINE_EXTRA_RRECOMMENDS += "kernel-modules"...trying MACHINE_RRECOMMENDS += "kernel-modules" now Dec 03 17:12:00 hm... this is to add *some* modules...see MACHINE_EXTRA_RRECOMMENDS_c7x0 = "kernel-module-snd-soc-corgi kernel-module-pxa2xx-cs kernel-module-pcmcia" Dec 03 17:13:15 hrw: btw the two latter are now compiled in kernel (for c7x0) . I would clean the .RRECOMMENDS but someone said don't do it. Can't remember why :=) Dec 03 17:14:21 because user can build kernel with those as modules Dec 03 17:14:38 it does not hurt to not have packages for RECOMMENDS Dec 03 17:19:50 ok, time for me Dec 03 17:21:22 mmm,hi Dec 03 17:22:19 I've that error and "failed to find a libdb or equivalent" and I've already bitbaken db-4.3.29-r10 Dec 03 17:22:21 mmm Dec 03 17:22:28 I'll look in staging Dec 03 17:26:43 ok...if I update the machine .conf so that it says MACHINE_RRECOMMENDS += "kernel-modules", and remove kernel-modules from the IMAGE_INSTALL variable, I get a /lib/modules/ directory...but it's empty Dec 03 17:27:51 mmm no libdb in staging Dec 03 17:29:01 CoreDump|home: ping Dec 03 17:39:16 03Marcin Juszkiewicz  07org.openembedded.dev * r52d27db8e0 10openembedded.git/conf/machine/simone.conf: (log message trimmed) Dec 03 17:39:16 simone: added machine config for SimpleMachines Sim.One developer board Dec 03 17:39:16 Text from vendor page: Dec 03 17:39:16 Sim.One means Simplemachines One, The first Project from Simplemachines Dec 03 17:39:16 team. It's a single board computer based on the low cost Cirrus System Dec 03 17:39:19 On Chip EP9307. It deliver a set of flexible PC-Like interfaces and Dec 03 17:39:21 add-on expansion connector to connect daughter boards. Dec 03 17:39:26 03Marcin Juszkiewicz  07org.openembedded.dev * rdd2e82a881 10openembedded.git/recipes/linux/ (13 files in 3 dirs): linux 2.6.32: added Sim.One support Dec 03 18:05:24 cleaned db and libpam and now it's building Dec 03 18:23:34 03Leon Woestenberg  07org.openembedded.dev * rebb9899f55 10openembedded.git/recipes/helloworld/helloworld_1.0.0.bb: Dec 03 18:23:34 helloworld: Use {C,LD}FLAGS during build. Duh. Dec 03 18:23:34 Signed-off-by: Leon Woestenberg Dec 03 18:27:15 wow again a build failure Dec 03 18:29:11 GNUtoo|erc: no kidding Dec 03 18:29:13 a build failure? In OE? Dec 03 18:29:31 yes I know but every 5 min it's too much Dec 03 18:36:17 ah, in the same build, multiple errors? Dec 03 18:38:16 no from time to time I've to clean a package and the failed one and to continue building Dec 03 18:38:21 I use shr/merge Dec 03 18:38:34 and I bet it's a bit old Dec 03 18:38:44 (not from today) Dec 03 18:39:13 nov 30 Dec 03 18:39:14 re Dec 03 18:42:45 for instance new problem now Dec 03 18:43:00 sounds like a dependency race condition (or make -jN, N>1 problem) Dec 03 18:43:13 I've only 1 core/cpu Dec 03 18:43:44 but the deps are there...I bet they were not staged correctly Dec 03 19:56:01 likewise: should I recompile everything from scratch for the third time Dec 03 19:56:09 because again it faile Dec 03 19:56:11 d Dec 03 19:57:00 GNUtoo|erc: what are you building for? Dec 03 19:57:06 shr/merge Dec 03 19:57:12 ah the machine Dec 03 19:57:24 htcdream Dec 03 19:57:32 and om-gta02 Dec 03 19:57:35 I tried both Dec 03 19:57:41 same issues Dec 03 20:02:13 Ah, I have seen a lot of commits lately on that arch/machine. Dec 03 20:02:33 Maybe look into who made the commits and try to reach them for status? Dec 03 20:02:43 ok Dec 03 20:02:46 Maybe the .dev tree is more stable then the shr/merge tree? Dec 03 20:02:59 It could be work in progress against an old revision. Dec 03 20:03:03 ok Dec 03 20:03:07 I just don't know, sorry. Dec 03 20:03:17 np Dec 03 21:25:36 jo Dec 03 21:39:59 03Klaus Kurzmann  07org.openembedded.dev * r7303994323 10openembedded.git/recipes/freesmartphone/ (fsodeviced/fsodeviced fsodeviced_git.bb): Dec 03 21:39:59 fsodeviced_git.bb: remove niceness as it does not use libcanberra anymore Dec 03 21:39:59 Signed-off-by: Klaus Kurzmann Dec 03 21:44:54 jo raster Dec 03 21:45:10 boo Dec 03 21:45:12 :) Dec 03 21:49:03 ;) Dec 03 22:10:06 ~seen zecke Dec 03 22:10:09 zecke was last seen on IRC in channel #oe, 7h 27m 22s ago, saying: 'pb_: yeah, and maybe redo (to get the dirs to blacklist as param)'. Dec 03 22:16:28 hm its quit today Dec 03 22:16:32 qrgs quiet Dec 03 22:16:48 hehe crofton Dec 03 22:17:08 jo bluelightning Dec 03 22:17:25 hi woglinde Dec 03 22:18:08 bluelightning something new about the git transition? Dec 03 22:18:25 woglinde: I've thought about it Dec 03 22:18:45 I think the only real solution is some kind of custom fetcher that does its own caching Dec 03 22:18:56 hm ah Dec 03 22:20:18 hehe khem Dec 03 22:20:28 khem new telco provider? Dec 03 22:20:36 hi there Dec 03 22:20:56 no the same Dec 03 22:21:04 hm Dec 03 22:21:11 something new about libstdc++? Dec 03 22:22:31 not much, Dec 03 22:22:44 I did not work much yesterday or today Dec 03 22:22:52 okay Dec 03 22:24:37 not yet fully recovered Dec 03 22:24:44 I am drained :) Dec 03 22:24:52 pity :( Dec 03 22:25:08 when will we have devtmpfs in oe supported Dec 03 22:25:16 and drained with kids means double drained Dec 03 22:25:21 yeah Dec 03 22:26:03 may be after 2.6.32 Dec 03 22:26:13 koen started 2.6.32 Dec 03 22:26:16 already Dec 03 22:26:41 jo ant Dec 03 22:26:58 ciao woglinde Dec 03 22:27:04 but it will be handy I believe Dec 03 22:27:11 should simplify boot process Dec 03 22:27:17 and fasten Dec 03 22:27:26 thats why I want it Dec 03 22:27:39 maybee a task for ant Dec 03 22:28:20 do I miss smthg? Dec 03 22:28:22 :) Dec 03 22:28:35 devtmpfs Dec 03 22:28:44 support in oe Dec 03 22:28:49 to fasten boot process Dec 03 22:29:19 ah..yes devfs strikes back :) Dec 03 22:29:24 heh, devfs rides again. Dec 03 22:29:28 very good Dec 03 22:29:29 pb yes Dec 03 22:29:34 for booting its okay Dec 03 22:29:40 than udev can take over Dec 03 22:30:09 actually I'm almost fed up by udev races...I'm thinking to pack my dev tarball... Dec 03 22:30:36 ant__ than devtmpfs saves you Dec 03 22:30:59 make localmodconfig rocks too Dec 03 22:38:49 2.6.32 was released yesterday hmm Dec 03 22:39:24 he..lot of patches pending for next arm git-pull.. Dec 03 22:43:09 woglinde: devtmpfs, upstart and an overhaul of the boot process is just what the Dr. ordered ;) - Maybe even look at quick-init again. Dec 03 22:45:53 quick-init new package? Dec 03 22:46:02 hi djwillis btw. Dec 03 22:47:04 woglinde: hi Dec 03 22:47:50 woglinde: quickinit is something I have seen in Arch Linux, I keep meaning to revisit it before investing more time in upstart to make sure we make the right choice. Dec 03 22:50:39 DJWillis: How do they compare in term of codesize Dec 03 22:50:52 I mean quickinit and upstart Dec 03 22:52:12 khem: don't forget openRC (scripts in C) Dec 03 22:52:43 would need a bit of work for debian-like layouts, though Dec 03 22:52:53 khem: not looked in that level of detail. I think they deal with the issues in very different ways anyway so code size would be secondary ;) Dec 03 22:53:40 hmm some video I am seeing 9 seconds to console Dec 03 22:54:12 and 32 seconds to kde thats on arch Dec 03 22:54:20 32 is much Dec 03 22:56:03 upstart is 40 seconds Dec 03 22:56:44 hm Dec 03 22:56:49 moblin starts faster Dec 03 22:57:30 what does openelec.tv use Dec 03 22:57:47 woglinde: but you have to go like for like, saying another distro starts faster is not a good way of looking at it ;) Dec 03 22:58:16 thats right Dec 03 22:58:54 ?????? Dec 03 22:59:00 faster is faster Dec 03 22:59:41 if another distribution is slower than there is some wrong or not optimized Dec 03 23:00:03 xfce on arch boots in 20secs Dec 03 23:00:38 woglinde: there might be more services started by one than another Dec 03 23:00:58 eh..right.. you are comparing apples with pears.... Dec 03 23:01:34 nah Dec 03 23:01:49 khem: Xfce in 20 secs would be nice on the Pandora let alone Arch ;-), I think it's more like 80 at the moment. Dec 03 23:01:50 not really Dec 03 23:01:56 I think smaller code size will be a consideration for oe Dec 03 23:02:16 we should define when x can start Dec 03 23:02:28 for most embedded Dec 03 23:02:31 I was just seeing it on youtube someone booting arch on a virtual box Dec 03 23:02:35 we dont even need net for x starting Dec 03 23:03:24 I think when user is able to move the pointer or type is when I consider it booted Dec 03 23:04:49 woglinde: starting X as early as poss in some async way has to be the way to go, maybe have a 'check state' before you run up the WM to say do I have enough services. Dec 03 23:19:31 omg..opkg-native looks for libldap.la..wtf? Dec 03 23:19:41 lol Dec 03 23:19:56 I removed openldap from my buildhost one hour ago... Dec 03 23:20:33 power of useflags: USE="${USE} -ldap" Dec 03 23:20:58 ant__, correction: libcurl looks for libldap Dec 03 23:21:18 | /bin/grep: /usr/lib/libldap.la: No such file or directory Dec 03 23:21:18 | /bin/sed: can't read /usr/lib/libldap.la: No such file or directory Dec 03 23:21:33 reading from host is evil Dec 03 23:22:07 woglinde: the best part is it took half hours for rebuilding evolution (which I never use..) Dec 03 23:22:15 not my day.. Dec 03 23:22:20 ieeh Dec 03 23:22:22 evolution Dec 03 23:22:29 longer than libc Dec 03 23:22:56 iirc pb appreciates evo Dec 03 23:27:08 ant cannt believe this Dec 03 23:29:21 ;) Dec 04 00:07:48 ant__: pong Dec 04 00:08:07 hi!! Dec 04 00:08:30 hi there Dec 04 00:08:59 just to say sometimes the logs of irc are not respecting the table Dec 04 00:09:07 today happened again Dec 04 00:09:22 with 2 different browsers Dec 04 00:09:30 hmm Dec 04 00:09:44 well..yesterday in EU Dec 04 00:10:26 see [20091203 14:02:50] Dec 04 00:10:31 #oe Dec 04 00:10:45 ugh Dec 04 00:12:37 ah..the Nokia browser (E51) doesn't display anything...opera does Dec 04 00:13:24 CoreDump|home: great service btw, thx again Dec 04 00:13:44 you're welcome =) Dec 04 00:14:45 hm..perhaps the '<' and '>' ? Dec 04 00:15:47 see [20091203 18:26:43] too Dec 04 00:21:20 'nite all **** ENDING LOGGING AT Fri Dec 04 02:59:57 2009