**** BEGIN LOGGING AT Thu May 21 02:59:57 2009 May 21 04:40:41 03Angus Ainslie  07fso/milestone5.5 * r604fa9fee9 10openembedded.git/recipes/netbase/netbase/ (om-gta01/interfaces om-gta02/interfaces): netbase interfaces : add usb rules with metric for gta01 and gta02 May 21 06:44:52 good morning May 21 06:45:33 morning May 21 06:59:32 morning all May 21 07:04:00 hi gremlin[it] May 21 07:04:27 hi mckoan ! May 21 07:11:02 hey .it dudes May 21 07:11:45 morning :) May 21 07:12:05 * * OE Bug 5116 has been created by erik.boto(AT)gmail.com May 21 07:12:07 * * Undefined reference to ppoll when building udev and jack May 21 07:12:09 * * http://bugs.openembedded.net/show_bug.cgi?id=5116 May 21 07:12:58 hey Jay7 I hear you scored a tosa :-) May 21 07:14:50 XorA: tosa is in my relative in USA May 21 07:15:37 it will be in Russia in May 27 May 21 07:15:37 Jay7: wish you had said, you could have had the one here and cleared out some desk space for me May 21 07:17:01 XorA: I hope there will be any other tosa lovers ;) May 21 07:17:14 * Jay7 it thinking about GTA.. May 21 07:17:22 * XorA has been trying to offload it for nearly 2 years :-) May 21 07:17:38 when someone have unused gta in usa tell me ;) May 21 07:18:51 Jay7: you mean open moko devices, I have spare May 21 07:20:15 XorA: you have said already.. but delivery from UK is expensive :) May 21 07:20:38 I have no 'couriers' in UK :) May 21 07:20:54 Jay7: do you have them in any .eu contries? May 21 07:21:09 Jay7: are you going to linuxtag? May 21 07:21:20 1) no 2) no :( May 21 07:21:25 arse May 21 07:21:30 yeah.. May 21 07:25:48 * XorA falls over looking at shipping prices May 21 07:33:09 crazy tariffs :) May 21 07:34:59 more than the devices are worth May 21 08:46:47 morning May 21 08:50:03 hi hrw May 21 08:50:44 mckoan: good news for you - I have nanopc running again May 21 08:51:11 as 'connected to net,screen,keyboard' so will look how things are May 21 08:51:12 hrw: why it wasn't running? May 21 08:51:58 mckoan: I lacked spare vga display May 21 08:54:14 hrw: you could use a KVM switch May 21 08:54:51 thats the option to consider May 21 08:55:01 morning May 21 08:55:17 hrw: I use it and I'm very satisfied, considering my tiny office May 21 08:57:20 hm..koen: udev-141-r4 is failing for me and Crofton (armv5te / armv7-a) May 21 08:57:39 undefined reference to `ppoll' May 21 08:59:57 ant_work: I don't think koen is in this channel :-} May 21 09:00:16 hey...wrong label... May 21 09:01:30 pb___: btw, why is there a difference? http://rafb.net/p/mlsRiw76.html May 21 09:01:54 udevd.c:(.text+0x16e4) vs udevd.c:978: May 21 09:02:51 and the paths May 21 09:06:34 anyway...The ppoll() system call was added to Linux in kernel 2.6.16. The ppoll() library call was added in glibc 2.4. May 21 09:06:47 possibly a missing include May 21 09:07:27 ant_work: i filed a bug on the ppoll issue May 21 09:07:43 thx May 21 09:07:54 I get it on udev and jack May 21 09:08:07 Just when I got my BB rev C2 :) May 21 09:08:52 somewhere #include "ppoll.h" May 21 09:09:49 great, tnx May 21 09:10:20 I'm googling and it seems bluez-utils is using it May 21 09:21:28 ant_work: it can't find ppoll.h.. And shouldn't the problem be that ppoll isn't in the libraries it tries to link against? otherwise it should complain when compiling and not when linking? May 21 09:24:00 hm.../udev/udevd.c:#include May 21 09:24:16 I can't check here May 21 09:25:17 I'll give it another shot May 21 09:26:41 oooh, I'm blind.. I included ppoll and not poll.. May 21 09:27:04 http://www.freebsd.org/cgi/man.cgi?query=ppoll&apropos=0&sektion=2&manpath=SuSE+Linux%2Fi386+ES+10+SP1&format=html May 21 09:27:19 morning Yuri ;) May 21 09:27:33 according to SYNOPSYS - #include is enough May 21 09:27:40 same problem though, but atleast it find sys/poll.h now :) May 21 09:27:46 ant_work: morning :) May 21 09:28:13 but this is man from OpenSUSE ES 10 :) May 21 09:28:47 hm.. this is linking error May 21 09:29:03 he May 21 09:29:05 but ppoll should be in stdlib imho May 21 09:30:09 The ppoll() system call was added to Linux in kernel 2.6.16. The ppoll() library call was added in glibc 2.4. May 21 09:32:06 ah..Jay7..syscall is your passion, isnt? :D May 21 09:32:52 he 50 May 21 09:32:59 s/50/:)/ May 21 09:32:59 good morning May 21 09:34:00 mckoan: 1680x1050 framebuffer looks nice May 21 09:37:21 hrw: good! I'll test it later too, could you please send me your xorg.conf ? May 21 09:38:30 hm.. May 21 09:38:43 * Jay7 is looking at moblin's screenshots May 21 09:39:07 seems there is second candidate to be useful on zauruses :) May 21 09:40:11 erbo: can you find command line which is used to link udev.o? May 21 09:40:22 make output should contain this May 21 09:40:52 better to use w/o parallel make. May 21 09:42:14 Jay7: moblin o zaurus? with what kind of GL implementation? May 21 09:42:30 GL.. sh*t :) May 21 09:42:41 is GL required for moblin? May 21 09:43:03 yeah, I think it is May 21 09:43:07 zecke: hail zecke May 21 09:43:15 well.. then maemo's hildon is the one :) May 21 09:44:02 ant_work: you mean why are the error messages different? either different binutils or different compiler flags at a guess. May 21 09:44:35 ant_work: the first form (".text+XXX") is what the linker says if it doesn't have any function name information, or (more likely in your case) what you get with older binutils May 21 09:44:49 s/function name/line number/ May 21 09:45:26 Jay7: moblin2 is using clutter... which s a scene graph library on top of OpenGL... :) May 21 09:45:28 the latter is what you get if you are linking with a new gld and it does have line number information (== debug info, I think) available. May 21 09:45:28 seems I should try to build new udev too :) May 21 09:45:37 zecke: bad luck :) May 21 09:48:26 mckoan: I use framebuffer now - need to get system updated first May 21 09:48:48 pb_: almost clear now, thx May 21 09:50:33 heh.. to install opkg-nogpg I need to remove opkg which I need to install opkg-nogpg ;D May 21 09:51:29 ~hail ar -x May 21 09:51:30 * ibot bows down to ar -x and chants, "I'M NOT WORTHY!!" May 21 09:52:38 Jay7: http://pastebin.com/mdf25005 May 21 09:53:05 heh, good to hear that opkg is keeping the tradition of ipkg brokenness alive. May 21 09:53:42 someone should totally write a decent package manager one day. May 21 09:53:50 pb_: dpkg+apt? May 21 09:54:04 very funny May 21 09:54:37 when I say "write", c++ doesn't count May 21 09:55:34 plus, apt seems to rival JRE for memory usage :-} May 21 09:56:13 I think the ipkg concept was a pretty sound one, it's just that the implementation sucks rather more than would be ideal May 21 09:56:20 indeed May 21 09:56:28 opkg fixes some bugs but added new ones May 21 09:56:32 * hrw -> off May 21 09:58:23 Hi all, I'm trying to use a prebuilt toolchain, I'm following a guide, but I dont know where should I put TARGET_CPPFLAGS_append = " -I${PRE_BUILT}/include " line? May 21 09:58:28 anybody can help me? May 21 10:02:04 leslie: probably in your local.conf, though I am a bit surprised that line is necessary May 21 10:03:41 leslie: which example do you attempt to follow? May 21 10:04:49 http://www.openembedded.info/usermanual.html#commonuse_prebuilt_toolchain, this link May 21 10:04:54 I'm following May 21 10:06:30 re May 21 10:07:45 does someone has fbdev driver working with x.org (not kdrive) x11 server? May 21 10:07:56 (EE) FBDEV(0): FBIOPUT_VSCREENINFO succeeded but modified mode May 21 10:07:56 (EE) FBDEV(0): mode initialization failed May 21 10:08:16 thats on one device. on second something brings and die in a moment after May 21 10:09:45 pb_: yes, I put it in the local.conf, and it seems work fine May 21 10:09:47 thanks May 21 10:14:07 did someone tried xserver 1.6x? May 21 10:14:11 with OE May 21 10:24:40 I failed build shasum-native-1.0, if I run run.do_compile.10039 for sharum, it report: gcc: No such file or directory, anybody knows this error? May 21 10:25:16 first heard May 21 10:25:28 leslie: sounds like you don't have a compiler installed on your build host May 21 10:25:30 OE require host compiler too May 21 10:25:48 leslie: 'aptitude install build-essential' on debian systems will help May 21 10:26:04 pb_: out of oe, in bash, I type "gcc", it reports: gcc: no input files May 21 10:26:22 ah, hm. in that case I guess your $PATH must be getting messed up in oe somehow. May 21 10:26:24 I do have gcc, g++ tools installed on my host May 21 10:26:35 if you do "which gcc", where does it say the compiler is installed? May 21 10:27:16 with which gcc, reports: /usr/bin/gcc May 21 10:27:42 that should be fine. very strange. May 21 10:28:01 my prebuilt toolchain has a ccache May 21 10:28:12 you might have to dig into the run.do_compile.10039 script (it's just a bash script, albeit a slightly convoluted one) and figure out why it isn't managing to find your gcc. May 21 10:28:19 and all tools, like arm-linux-gcc , is a link to ccache May 21 10:28:53 oe isn't even trying to use the cross-compiler at this point. xxx-native packages are built with your regular host compiler. May 21 10:29:10 so, don't worry about your cross toolchain, that can't be the problem here. May 21 10:29:30 export BUILD_CC="ccache gcc", this is a line in run.do_compile May 21 10:29:50 I think it use the cross toolchain's ccache May 21 10:30:03 does it work if you change that to just "gcc"? May 21 10:30:13 i'm trying :) May 21 10:30:37 bbl May 21 10:31:03 it works May 21 10:31:15 if I change it to "gcc" May 21 10:32:19 okay. well, if you're happy to not use ccache for host builds, you can just set CCACHE = "" in local.conf and it should be happy. May 21 10:32:26 leslie: fedora you use? May 21 10:32:35 opensuse May 21 10:32:38 if you do want ccache for the host bits then you might need to debug it a bit further to figure out why ccache is getting upset. May 21 10:33:07 en, thanks pb_ May 21 10:49:43 Note that ccache gets upset if HOME isn't set... May 21 10:49:49 morning all btw May 21 10:50:25 any thoughts on why edevd-141 is not building for some? May 21 10:52:22 Crofton|work: udevd ? May 21 10:52:55 right May 21 10:53:06 slowly adding coffee here .... May 21 10:53:24 Crofton|work: the ppoll stuff? looking into that (dropped back a version for now on the Pandora). It's odd, kernel and glibc all have ppoll in them. May 21 10:53:52 and seems kust libool/linking prob May 21 10:54:07 eh...and seems just libtool/linking prob May 21 10:57:10 lovely May 21 10:57:15 why only failing for some May 21 10:57:33 I dare to say for everybody building from scratch May 21 10:57:38 ok May 21 10:58:07 ant_work: yep, seems to come in with totally clean builds. May 21 10:58:47 so probably koen had some 'cruft' header around which we lack May 21 10:59:20 or he didn't do a clean build May 21 10:59:36 are you both using multi threaed bb May 21 10:59:53 yes here May 21 11:00:35 I just turned that off and will try again May 21 11:04:38 it doesn't look like a header issue as such, more of a library problem. does your libc.so actually contain a ppoll symbol? May 21 11:06:50 another more strange issue... when I build libtool-cross, if I do run.do_configure, it works fine, but if I do bitbake, it reports(in log): configure: error: C compiler cannot create executables May 21 11:07:15 pb_: seems is there since glibc-2.4 May 21 11:07:29 but indeed...Crofton, pls check May 21 11:07:38 ant_work: have you actually inspected your libc.so to see if it is really there? May 21 11:08:08 no...I always discover the failures in the morning when I'm heading to odffice :/ May 21 11:08:37 anybody knows what happening? May 21 11:08:42 and I can't ssh because during the day host is running Leopard OSX May 21 11:08:47 ../ May 21 11:09:00 leslie: check the config.log file to see what's up May 21 11:13:04 I pasted the error here: http://pastebin.com/d7ed0ad5d, but does it have difference between do bitbake and do run.do_configure mannually? May 21 11:14:04 shouldn't do, unless there is some environment variable dependency. May 21 11:14:18 bitbake does have a (sometimes slightly unhelpful) habit of zapping the environment before it runs anything. May 21 11:15:58 leslie: the fatal error: C compiler cannot create executables...have you cwiped your tmpdir? May 21 11:17:11 I always see /cross is wrongly recreated after rebuild from packaged-staging May 21 11:17:45 /cross instead of /cross/armv.../ May 21 11:18:22 it seems dont have /cross folder in tmp May 21 11:20:36 I think the problem is at the difference between do bitbake and do run.do_configure, but how to find it out... May 21 11:25:14 my glibc 2.6.1 build just failed in the binary locale generation because qemu-arm (qemu-native 0.9.1+svn) doesn't understand the -E option (called from glibc-package.bbclass since 6065fa...). qemu-native 0.10.3 is still DEFAULT_PREFERENCE=-1. May 21 11:25:37 pH5: apply Roman's patch May 21 11:25:57 [oe] [PATCH 1/2] qemu 0.10.3: port OE patches, make preferable version May 21 11:26:26 nm lib/libc.so.6 | grep ppoll May 21 11:26:27 hm.. May 21 11:26:33 doesn't show anything? May 21 11:26:43 bitbake udev is completed successfully May 21 11:27:06 Jay7, machine/distro? May 21 11:27:07 with udev-141-r4 May 21 11:27:10 from scratch? May 21 11:27:16 akita/angstrom May 21 11:27:19 yep May 21 11:27:31 pure fun May 21 11:27:33 I have build kexec-tools-static only before May 21 11:27:50 so it will build gcc May 21 11:28:50 ok, I have ppol in libc.so.6 on x86 :) May 21 11:29:14 gcc-cross-initial-4.3.3-r4.1, gcc-cross-intermediate-4.3.3-r4.1, gcc-cross-4.3.3-r4.1 and update-rc.d-0.7-r1 May 21 11:29:20 this was build before May 21 11:31:42 ant_work: thanks, checking May 21 11:33:38 pH5: I overlooked the patch too, thinking was already pushed May 21 11:33:54 seems just fine May 21 11:34:25 btw, should I vote for patches in .dev? :) May 21 11:34:28 fwiw, udev-141 does build fine for me May 21 11:34:38 what machine? May 21 11:34:41 or only coredev should do that? May 21 11:34:50 bye May 21 11:34:53 epia May 21 11:35:17 * Crofton|work has a bad feeling glibc for armv7 is missing ppoll for some reason May 21 11:35:18 and minimal distro, though I doubt that makes much difference May 21 11:35:44 minimal seems to be a copy of angstrom, with ugly section seperators .... May 21 11:36:11 afk for ~1.5h May 21 11:36:29 I really wish it would become trukly minimal, or people would work more on mciro May 21 11:36:34 er micro May 21 11:37:00 there probably is a niche for minimal, though I think mickey is right that it should be renamed (back) to generic. May 21 11:37:13 I can't figure out what it is May 21 11:37:14 I suspect micro is a bit too micro for a lot of folks. May 21 11:37:48 Crofton|work: FWIW I'm building angstrom-dev May 21 11:38:03 like Jay7... May 21 11:38:56 Crofton|work: armv5te May 21 11:39:00 I wonder if the newer udev added the ppoll call May 21 11:39:14 <__good_day_> Hello friends, How can I solve the following error http://pastebin.com/m5c130a0f after building toolchain using http://www.linux4sam.org/twiki/bin/view/Linux4SAM/OpenEmbeddedAngstromBuild#How_to_build_Angstrom_for_AT91. May 21 11:39:22 I see it in x86, but not libc for beagle May 21 11:39:43 Crofton|work: if it was broken on ARMv7 would it not have been broken for Koen from the get go? May 21 11:40:01 well, this is a mystery May 21 11:40:10 pb_: IMHO there are too many images and too many distros. Abundance is good...buth some lacks use/maintainance May 21 11:40:28 __good_day_: that error doesn't seem to be obviously related to oe. I think you need to take it up with your source vendor, whoever that is. May 21 11:40:54 pb_: creating a custom-image is trivial May 21 11:41:13 <__good_day_> pb_: okey I got your point Thank you. May 21 11:41:45 __good_day_, sometimes we get a little overwhelmed by questions from end users :) May 21 11:42:52 ant_work: yeah, there are indeed quite a lot of distros that seem to be maintained only patchily if at all. May 21 11:43:08 <__good_day_> pb_: little debugging found that the toolchain doesnt include REENTRANT_SYSCALLS_PROVIDED while compiling newlib. Can you please let me know how can I include that while building oe? May 21 11:43:57 <__good_day_> It has problem with "struct _reent r" May 21 11:43:57 pb_: I'm just scared by the matrix distro/image/machine ... is huge May 21 11:44:03 __good_day_: er, I didn't think that newlib was included in oe at all. I'm not quite sure I understand what you mean by "building oe" in this context. May 21 11:44:56 ant_work: true, though you wouldn't expect the entire cross-product matrix to be useful. most images are only intended to be valid for a limited subset of DISTROs, and most DISTROs are only intended for use with a limited subset of MACHINEs. May 21 11:45:43 pb_, in reality images should be orthogonal to distro May 21 11:45:50 micro-image builds fine in Angstrom May 21 11:45:51 pb_: how to minimize then? some images could have setting usually found in distro May 21 11:46:04 <__good_day_> I am sorry, I use building oe instead of building environment May 21 11:46:12 pb_: I'm thinking to router/nas May 21 11:46:19 that's not to say that the images are necessarily unbuildable against other DISTROs (e.g. I think Crofton|work mentioned he had had some success building micro-image for angstrom) but there is no particular guarantee about what the results will be. May 21 11:47:54 <__good_day_> pb_: Then is there any point if you can think of that can cause the problem ? Any suggestion? As I have tried to consult the vendor but invain. May 21 11:48:14 __good_day_, you are using a toolchain built with OE to compile something else? May 21 11:48:16 Crofton|work: it's difficult to see how they can be made truly orthogonal: there are too many policy decisions under the distro's control that can have an impact on the image. For some images and some distros it will probably work fine, but there's certainly no guarantee in the general case. May 21 11:48:23 The situation is miles better than it used to be :) May 21 11:48:27 can we think about $DISTRO_SUPPORTED_IMAGES? May 21 11:48:48 I would argue that distro specific images should not appear in the OE metadata May 21 11:48:55 not I said argue May 21 11:49:02 ant_work: that's not a bad idea, though it'd probably make more sense to do it the other way around; have a COMPATIBLE_DISTRO thing in the image.bb along the lines of COMPATIBLE_MACHINE. May 21 11:49:14 Crofton|work: Where should they go? May 21 11:49:16 yep..specular May 21 11:49:22 up to the distro :) May 21 11:49:30 Crofton|work: well, in that case it would be a natural next step to not ship any distro files at all in the OE metadata. May 21 11:49:36 * Crofton|work has been known to argue just for the sake of arguing May 21 11:49:48 there's no point having DISTRO.conf if you lack the image files that would allow you to build images. May 21 11:50:02 use the generic ones May 21 11:50:08 <__good_day_> crofton|work: yes, using OE to compile demo application supplied with the kit, which is made for gnu linux. May 21 11:50:24 Actually, I love the idea of creating multiple meta-* directories like poky May 21 11:50:49 __good_day_, I think the problem will lie in how you are compiling your app May 21 11:50:51 that said, moving all the distro-specific bits into separate repositories isn't a completely silly idea. May 21 11:50:51 Then the distro specific bits can all live together (conf and recipes) May 21 11:51:05 * Crofton|work is multi-tasking to failure May 21 11:51:07 pb_: No need for a separate repo, just a separate directory May 21 11:51:19 * Crofton|work segfaults May 21 11:51:25 pb_: I'd let distro-maintainers decide the images they 'support' and update frequently distro.conf May 21 11:51:38 listing the exact images May 21 11:51:44 they tested May 21 11:52:12 you would just need an oefatal May 21 11:52:22 to warn May 21 11:52:35 ok May 21 11:52:51 can someone with armv5 libs about grep libc for ppol? May 21 11:52:57 er May 21 11:52:59 ppoll May 21 11:53:09 Crofton|work: Jay7 will do for us in a while May 21 11:54:12 RP: yah, that'd work too. May 21 11:54:48 Crofton|work: my armv5te build (magician, hx4700) doesn't have ppoll either May 21 11:54:57 hmmm May 21 11:55:31 http://sourceware.org/ml/libc-ports/2007-09/msg00005.html May 21 11:57:05 Crofton|work: that shouldn't matter, you should still get the generic ppoll stub even then. May 21 11:57:29 plus I think the syscalls have actually been added for arm since drow posted that note May 21 11:58:10 well the question is why aren't they in the armv7 libc .... May 21 11:58:22 indeed, but I don't think that email is the answer. May 21 11:58:55 yeah, but google said it is :) May 21 11:59:04 heh May 21 11:59:10 what do you actually have in your ppoll.o? May 21 11:59:34 or ppoll.os rather May 21 11:59:47 bother May 21 11:59:57 can't find that file :) May 21 12:00:13 it should be in io/ May 21 12:00:24 [balister@localhost glibc-2.6.1]$ find . -name "ppoll*" May 21 12:00:25 ./sysdeps/unix/sysv/linux/ppoll.c May 21 12:00:25 ./sysdeps/mach/hurd/ppoll.c May 21 12:00:25 ./io/ppoll.c May 21 12:00:25 just after posix_fallocate.os, probably May 21 12:00:40 Crofton|work: you're looking in the source directory, not the build directory May 21 12:00:43 cd ../build-* May 21 12:01:13 I have ppoll.o May 21 12:01:21 is learning too much May 21 12:01:26 but no ppoll.os? May 21 12:01:30 that to May 21 12:01:34 I was being brief May 21 12:01:40 okay May 21 12:01:53 if you objdump -dr ppoll.os, what do you see? May 21 12:02:34 code May 21 12:02:38 jolly good May 21 12:02:55 does it start with a line that says something like "0000000 :"? May 21 12:03:03 been a while since I heard someone say that May 21 12:03:15 exactly May 21 12:03:35 okay, so the function is indeed being compiled May 21 12:03:54 hm. my ppoll.os only has the .comment and .ARM.attributes sections. objdump -d is completely empty. May 21 12:03:54 now look in ../libc_pic.os, see if you can find it defined there May 21 12:04:23 pH5: oh dear, sucks to be you. May 21 12:04:28 :) May 21 12:04:29 sounds like there might be two different bugs at work in that case May 21 12:04:55 pH5: the way to attack that one is to inspect log.do_compile and find out what command generated ppoll.os May 21 12:05:12 then inspect the input files and figure out why they are producing empty output. May 21 12:05:17 nm libc.so.6 | grep ppoll May 21 12:05:17 000b09e8 T ppoll May 21 12:05:29 I have add ASSUME_PROVIDED += " virtual/${TARGET_PREFIX}gcc " in local.conf, but bitbake still tried building gcc-cross-initial, is it correct?should I replace TRARGET_PREFIX to arm-linux- ? where is TRARGET_PREFIX defined? May 21 12:05:44 * ant_work sits on coutch looking 'PB's strikes back' Part1 May 21 12:05:59 hmmm [balister@localhost build-arm-angstrom-linux-gnueabi]$ nm libc_pic.os | grep ppoll May 21 12:05:59 0009c1d8 T ppoll May 21 12:06:09 leslie: it's correct, but not sufficient. you need to add virtual/${TARGET_PREFIX}gcc-initial as well. May 21 12:07:07 why doesn't this make it to staging May 21 12:07:24 pb_: should I replace TARGET_PREFIX to arm-linux- ? I havent set TARGET_PREFIX anywhere. May 21 12:07:32 bbiab May 21 12:07:43 leslie: no, that's okay, it's set by bitbake.conf May 21 12:08:35 pb_: thanks :) May 21 12:09:57 pb_: it still has lots of that configure errors, and I use run.do_configure, then touch a file in tmp/stamps to solve it, but I dont think it's a good solution May 21 12:14:12 leslie: that is rather strange. I think it must be an environment variable issue or something like that but I don't have any particular solutions for fixing it. May 21 12:17:57 pb_: just a crazy idea...I see there are headers staged only with kernels >2.6.27 May 21 12:18:14 in kernel.bbclass May 21 12:18:45 perhaps name mismatch? I'm building 2.6.26 May 21 12:24:51 ant_work: that still shouldn't cause ppoll to go missing in glibc. no matter what the kernel does or doesn't do, you still ought to get a ppoll symbol of some kind even if it's just a stub that always returns -ENOSYS. May 21 12:25:19 in fact, I don't think ppoll ever will degrade to just an -ENOSYS stub since glibc can emulate it with other syscalls if the kernel doesn't provide ppoll directly. May 21 12:25:46 I see...thxl May 21 12:27:14 this ppoll problem seems to be spreading May 21 12:30:30 03Otavio Salvador  07org.openembedded.dev * rff34921286 10openembedded.git/ (5 files in 3 dirs): May 21 12:30:30 acpid: add 1.0.8 (with netlink support) May 21 12:30:30 Signed-off-by: Otavio Salvador May 21 12:30:32 03Otavio Salvador  07org.openembedded.dev * r88e86fff96 10openembedded.git/conf/machine/ (4 files in 2 dirs): May 21 12:30:32 machine/geode[gl]x: use more optimization while compiling May 21 12:30:35 Since the code is now the same for Geode GX and Geode LX we also May 21 12:30:37 merged the tunning files in a single tune-geode.inc, making it easy to May 21 12:30:39 improve from now on. May 21 12:30:41 Signed-off-by: Otavio Salvador May 21 12:30:43 03Otavio Salvador  07org.openembedded.dev * r85a14b8765 10openembedded.git/conf/checksums.ini: May 21 12:30:46 checksums.ini: add flash-plugin May 21 12:30:48 Signed-off-by: Otavio Salvador May 21 12:30:50 03Otavio Salvador  07org.openembedded.dev * r1232133c9c 10openembedded.git/ (conf/checksums.ini recipes/gtk-engines/gtk-engines_2.18.1.bb): May 21 12:30:53 gtk-engines: add 2.18.1 May 21 12:30:55 Signed-off-by: Otavio Salvador May 21 12:30:57 03Otavio Salvador  07org.openembedded.dev * rf5c3b15422 10openembedded.git/conf/checksums.ini: May 21 12:31:00 checksums.ini: add sun-jdk May 21 12:31:10 Signed-off-by: Otavio Salvador May 21 12:31:12 03Otavio Salvador  07org.openembedded.dev * red4f8aa703 10openembedded.git/conf/checksums.ini: May 21 12:31:15 checksums.ini: firefox-l10n-pt-br May 21 12:31:17 Signed-off-by: Otavio Salvador May 21 12:31:19 03Otavio Salvador  07org.openembedded.dev * r0fbb2e057c 10openembedded.git/conf/licenses.conf: May 21 12:31:22 conf/licenses.conf: add CUPS license May 21 12:31:24 Signed-off-by: Otavio Salvador May 21 12:31:26 03Otavio Salvador  07org.openembedded.dev * r4df5a84ef9 10openembedded.git/ (conf/checksums.ini recipes/python/python-pycups_1.9.45.bb): May 21 12:31:29 python-pycups: add May 21 12:31:31 Signed-off-by: Otavio Salvador May 21 12:31:33 03Otavio Salvador  07org.openembedded.dev * rffb4e8d7ac 10openembedded.git/ (conf/checksums.ini recipes/hal/hal-cups-utils_0.6.19.bb): May 21 12:31:44 hal-cups-utils: add May 21 12:31:46 Signed-off-by: Otavio Salvador May 21 12:31:48 03Otavio Salvador  07org.openembedded.dev * r57c5f8879e 10openembedded.git/ (2 files in 2 dirs): May 21 12:31:51 system-config-printer: add to provide python-cupshelpers to hal-cups-utils May 21 12:31:53 Signed-off-by: Otavio Salvador May 21 12:31:57 03Otavio Salvador  07org.openembedded.dev * rf56580bbd4 10openembedded.git/ (4 files in 3 dirs): May 21 12:32:00 fixes wrong license value usage for GPLv2 May 21 12:32:02 Signed-off-by: Otavio Salvador May 21 12:32:04 03Otavio Salvador  07org.openembedded.dev * rd24c53100d 10openembedded.git/ (6 files in 3 dirs): May 21 12:32:07 mtools: update to 4.0.10 since 3.9.11 was not available anymore May 21 12:32:09 (70 lines omitted) May 21 12:34:39 koen suggested rebuilding glibc May 21 12:34:46 which won't rebuild for me May 21 12:35:04 on a really weird error May 21 12:35:18 Crofton|work: you need to rebuild glibc-initial first May 21 12:35:53 hrw|gone: please take a look and update your geode patches May 21 12:35:55 I find this stuff extremely mysterious .... May 21 12:36:52 Crofton|work: as I understand it glibc replaces some stuff glibc-initial put there, but glibc needs the versions from glibc-initial May 21 12:37:00 btw glibc-initial has a base_set_files_path warning May 21 12:37:18 no wonder we drink so much May 21 12:37:27 * XorA will drink tonight May 21 12:37:47 amen May 21 12:38:05 * * OE Bug 5086 has been RESOLVED (INVALID) by May 21 12:38:07 * * libpcap-1.0.0 failed to install May 21 12:38:09 * * http://bugs.openembedded.net/show_bug.cgi?id=5086 May 21 12:39:30 XorA, that worked May 21 12:39:35 thanks May 21 12:39:41 I was about to start drinking May 21 12:40:09 Crofton|work: we should work out a way to make OE always force that condition May 21 12:41:32 even better, we should just fix the glibc recipe to not require those bogus bits. May 21 12:42:32 03Elena Grandi  07org.openembedded.dev * reca20211da 10openembedded.git/conf/checksums.ini: May 21 12:42:32 checksums.ini: added entry for gtksourceview2_2.6.0 May 21 12:42:32 Signed-off-by: Elena Grandi May 21 12:42:32 Signed-off-by: Otavio Salvador May 21 12:42:34 03Elena Grandi  07org.openembedded.dev * r5888b8ce39 10openembedded.git/recipes/gtksourceview/gtksourceview2_2.6.0.bb: May 21 12:42:37 gtksourceview2 2.6.0: new recipe for the current stable version. May 21 12:42:39 GtkSourceView is a portable C library that extends the standard GTK+ May 21 12:42:40 that said, I'd have thought it would be a non-issue if you were using packaged staging. May 21 12:42:41 framework for multiline text editing. May 21 12:42:43 Signed-off-by: Elena Grandi May 21 12:42:45 Signed-off-by: Otavio Salvador May 21 12:43:32 well; let me back to work :-D May 21 13:04:00 03Koen Kooi  07org.openembedded.dev * r18c5ea8f84 10openembedded.git/recipes/udev/udev_141.bb: udev 141: fix staging May 21 13:04:00 03Koen Kooi  07org.openembedded.dev * rccab93e06e 10openembedded.git/: Merge branch 'org.openembedded.dev' of git@git.openembedded.org:openembedded into org.openembedded.dev May 21 13:04:01 03Koen Kooi  07org.openembedded.dev * rd543c80be6 10openembedded.git/ (5 files in 3 dirs): devicemapper: fix QA problems, add 1.02.28 May 21 13:07:19 Crofton|work: give alook at cgit (org/net) May 21 13:07:53 .org should work May 21 13:08:07 udev still not listed May 21 13:09:59 I want to say cgit does not update dynamically, but I do not know what i am talking about :) May 21 13:11:47 http://cgit.openembedded.org/cgit.cgi/openembedded/log/recipes/udev/udev_141.bb May 21 13:11:52 is there... May 21 13:15:15 03Roman I Khimov  07org.openembedded.dev * r247515aec9 10openembedded.git/recipes/qemu/ (15 files in 2 dirs): May 21 13:15:15 qemu 0.10.3: port OE patches, make preferable version May 21 13:15:15 Fixes binary locale generation broken by May 21 13:15:15 6065fa491c009118ae282ae933215649cccfcd24. May 21 13:15:15 Tested to work on ARM OABI (simpad), ARM EABI (qemuarm), PowerPC (efika) May 21 13:15:18 pH5: fwiw, I just ran an armv5te build of glibc and I do have the right bits in ppoll.os May 21 13:15:19 and i686 (x86-prescott). May 21 13:15:21 Acked-by: Philipp Zabel May 21 13:15:31 so whatever problem is afflicting you does seem to be some gypsy curse that's specific to your environment May 21 13:16:20 pb_: you were rebuilding from scratch? May 21 13:16:26 yeah May 21 13:16:36 bb_multithread ? May 21 13:16:43 no May 21 13:16:53 gotcha 1) May 21 13:17:08 make -jx ? May 21 13:17:19 not sure, let me have a look May 21 13:17:30 I usually use -j4 but I don't know if I remembered to configure that for this particular build May 21 13:17:41 no, it's not using -j May 21 13:17:48 ant_work: just trying to rebuild glibc and glic-initial to see if that helps. -j3 May 21 13:18:21 * pH5 tries a single threaded build May 21 13:18:22 pb_: diff # 2) May 21 13:18:53 pH5: this was for MACHINE=h3900 though I don't think it ought to make much difference May 21 13:19:13 hx4700. that's even a very similar board. May 21 13:19:14 I have 2 threads and make -j3 fwiw May 21 13:19:24 for c7x0 (armv5te) May 21 13:19:27 I used 4 threads and -j4 before. May 21 13:19:30 and failed 8 hours ago May 21 13:20:43 (from scratch, I repeat) May 21 13:21:06 * * OE Bug 5086 has been UNCONFIRMED by kevyn.alexandre.pare(AT)gmail.com May 21 13:21:08 * * libpcap-1.0.0 failed to install May 21 13:21:10 * * http://bugs.openembedded.net/show_bug.cgi?id=5086 May 21 13:21:57 I'd be surprised if either -jX or bb threads made a difference to this, though I guess you never know. May 21 13:22:31 some disable PARALLEL_MAKE May 21 13:23:20 not helping May 21 13:24:10 :/ May 21 13:25:46 if removing -j (and/or BB_NUMBER_THREADS) makes it go away then let me know and I'll investigate further. May 21 13:26:02 otherwise, I think this just needs debugging by somebody who can actually reproduce the problem. May 21 13:30:15 pb_: i'l just keep my /tmp for analysys May 21 13:34:28 righto May 21 13:35:30 pb_ from tinderbox I can see I built glibc-initial/glibc at 02.45 and udev at 03.20 May 21 13:35:47 so all should have been staged May 21 13:35:55 if it were glibc May 21 13:36:38 urgh... s/were/was/ :/ May 21 13:37:12 (wenn es ...wäre) May 21 13:37:23 short-circuit May 21 13:39:05 * * OE Bug 637 has been RESOLVED (WORKSFORME) by May 21 13:39:07 * * Different gcc cross output dependent on host ARCH ia32/amd64 May 21 13:39:09 * * http://bugs.openembedded.net/show_bug.cgi?id=637 May 21 13:43:31 ant_work: heh. fwiw, "if it were glibc" is perfectly valid english. May 21 13:45:05 * * OE Bug 1697 has been RESOLVED (WORKSFORME) by May 21 13:45:07 * * glibc-intermediate 2.4 fails to build on self-hosted Angstrom due to rpcgen change May 21 13:45:09 * * http://bugs.openembedded.net/show_bug.cgi?id=1697 May 21 13:45:42 pb_: if it would have been glibc... May 21 13:47:37 ok May 21 13:47:46 Crofton|work: with -j3 I cleaned out glibc-initial, glibc and udev then built them one after the other and the problem is still there so don't waste time trying that ;-) May 21 13:52:37 hmm May 21 13:52:59 I think I was on the wrong machine earlier when I said there was code in ppoll.o May 21 13:53:06 * * OE Bug 5086 has been RESOLVED (FIXED) by May 21 13:53:08 * * libpcap-1.0.0 failed to install May 21 13:53:10 * * http://bugs.openembedded.net/show_bug.cgi?id=5086 May 21 13:54:15 this makes loads more sense May 21 13:54:35 ant_work: I would have expected you to embrace the subjunctive :-) May 21 13:55:35 pb_: mid 80' I was in 'Edinborrow' and one year later in Oxford for a month... May 21 13:55:50 in college May 21 13:56:02 ah, very good May 21 13:56:07 my best remembering: the 'pocket lunch' May 21 13:56:21 translated to 'launch' -> trow May 21 13:57:09 iirc the Castle in Ed was damaged by fire May 21 13:57:16 there was the college May 21 13:57:26 upon that hill May 21 13:58:13 I bought there my first PSION *original* tapes May 21 13:58:20 pb_: you successfully compiled snes9x in 2008? May 21 13:58:39 !oebug 1196 May 21 13:58:40 ant_work: I don't remember the castle itself being on fire, though there was a big fire a few years ago just a little way down from the castle. May 21 13:58:41 * * Bug 1196, Status: CONFIRMED, Created: 2006-07-25 08:50 May 21 13:58:41 * * parkr31(AT)hotmail.com: "bitbake snes9x" complains about missing -lqte May 21 13:58:42 * * http://bugs.openembedded.net/show_bug.cgi?id=1196 May 21 13:58:48 maybe the castle was on fire before that though :-} May 21 13:59:05 Laibsch: not for qte, but I built it for x May 21 13:59:07 I was inclined to move it to nonworking May 21 13:59:14 pb_: I was there in '85 May 21 13:59:34 pb_: how would that matter? "bitbake snes9x" fails for me May 21 13:59:46 Laibsch: you've probably somehow gotten the SDL Library of Death selected. May 21 13:59:54 pb_, why wouldn't I see nay code in ppoll.o? May 21 13:59:57 http://tinderbox.openembedded.net/builds/153265/ May 21 14:00:14 pb_: lol May 21 14:00:29 Laibsch: this is what we were talking about yesterday: sdl, despite its cross-platform credentials, is sadly incompatible between qte and everything else. May 21 14:00:35 I remember May 21 14:00:43 But I'm not convinced it is the case here May 21 14:00:52 okay, I'll have a look May 21 14:00:54 I'm looking into it May 21 14:01:37 righto. let me know what you find out. May 21 14:01:56 it certainly used to work for me in a non-qte system May 21 14:02:38 funnily enough I was thinking about exhuming my mythtv installation yesterday so I might be wanting to build it again soon :-} May 21 14:02:45 I did "bitbake snes9x" and grepped the depends files for qpe and qte May 21 14:02:46 nothing May 21 14:02:55 http://tinderbox.openembedded.net/public/logs/5380240.txt May 21 14:02:57 same thing May 21 14:03:05 Looks unrelated to me May 21 14:03:30 yeah, that looks unrelated May 21 14:03:36 at a guess, your g++ is too new. what version do you have? May 21 14:04:31 should be fairly easy to patch though, it almost certainly just needs 'extern "C"...' adding in a few strategic places May 21 14:05:37 What BitBake option will cause a necessary OE tool rebuild when changing in a machine def your TARGET_CC_ARCH = "-march=armv4t" slightly to "-march=armv4" (my target is complaining about invalid instructions w/armv4t) May 21 14:06:47 03Koen Kooi  07org.openembedded.dev * rc303984523 10openembedded.git/recipes/devicekit/devicekit-disks_004.bb: devicekit-disks: add 004 May 21 14:06:48 03Koen Kooi  07org.openembedded.dev * rd18dc6fd33 10openembedded.git/: Merge branch 'org.openembedded.dev' of git@git.openembedded.org:openembedded into org.openembedded.dev May 21 14:06:49 03Koen Kooi  07org.openembedded.dev * r288eb56a5f 10openembedded.git/recipes/udev/udev_141.bb: udev 141: symlink /usr/lib/udev/rules.d to /etc/udev/rules.d May 21 14:06:49 03Koen Kooi  07org.openembedded.dev * rd5edeac207 10openembedded.git/recipes/devicekit/libatasmart_0.13.bb: libatasmart: add 0.13 May 21 14:07:36 Crofton|work: I could find this recent bits https://bugs.launchpad.net/ubuntu/+source/linux/+bug/319729 May 21 14:07:46 udev / ppoll May 21 14:08:30 Crofton: dunno, see what I said to ph5 earlier. you'd have to start with log.do_compile and debug it from there. May 21 14:08:32 about disabling fallback code...pb_ ? May 21 14:10:16 what is annoying is something changed because older builds have it May 21 14:11:56 ant_work: yeah, I think that complaint is probably correct. May 21 14:12:56 are those syscalls really still not implemented for arm? that's pretty lame. May 21 14:21:20 drat, gcc-cross-kernel-3.3.4 doesn't compile anymore May 21 14:21:21 * pb_ stabs it May 21 14:26:37 single threaded build doesn't help me either. May 21 14:28:10 I think the problem is that __NR_ppoll is not defined (which I guess is correct if the kernel doesn't provide it) but __ASSUME_PPOLL seems to be defined somewhere. May 21 14:28:32 which stops glibc from using its own __generic_ppoll instead. May 21 14:34:10 yeah, that sounds quite likely. May 21 14:34:32 based on the report in the url that ant posted a moment ago, udev won't work correctly with the generic ppoll emulation anyway. May 21 14:34:55 so, if that's the case, removing __ASSUME_PPOLL would just swap a compile time error for a runtime lockup, which probably isn't all that much of an improvement. May 21 14:35:32 it sounds as though the only real solution is to make the crazy kernel h4x0rs get their collective finger out and implement the missing syscalls. May 21 14:36:49 Laibsch: doh, now I get CROSS_COMPILE BADNESS in snes9x May 21 14:37:07 groan! May 21 14:37:14 Yes, that is bug 1196, I think May 21 14:37:59 oh, right. May 21 14:38:09 I put too much faith in the summary, I thought #1196 was something about -lqte May 21 14:39:05 ah well, the badness is usually quite easy to fix. it's conceivable that I wasn't using a zecke-ized compiler last time I built snes9x so these bogus flags might have been there forever. May 21 14:40:29 pb_: hehe, I wonder why no one renamed the patch... *damn* May 21 14:41:49 zecke: i guess we like to be reminded of you. same as the "mickey_is_cool" thing that we are all so fond of. May 21 14:42:21 lol May 21 14:42:25 :( May 21 14:43:03 Laibsch: yah, here's the culprit: May 21 14:43:09 dnl NOTE: PATH_X doesn't set up the include path if it's in the system path May 21 14:43:09 if test x$x_includes != x ; then May 21 14:43:09 XINCLUDES="-I$x_includes" May 21 14:43:09 fi May 21 14:43:42 can you fix it? May 21 14:43:56 yeah, it just needs those three lines deleting May 21 14:44:13 cool May 21 14:44:16 I'll make a patch May 21 14:47:26 oh, what? snes9x doesn't run autoconf?! May 21 14:47:28 * pb_ stabs it May 21 14:47:33 oh well, I'll just patch configure directly May 21 14:50:07 * * OE Bug 2311 has been RESOLVED (REMIND) by May 21 14:50:09 * * Openalchemy toolkit in Openembedded May 21 14:50:11 * * http://bugs.openembedded.net/show_bug.cgi?id=2311 May 21 14:51:10 pb_: Is there a newer snes9x anywhere? May 21 14:51:23 that's a good question, I have no idea May 21 14:58:09 03Phil Blundell  07org.openembedded.dev * rc16813c576 10openembedded.git/recipes/snes9x/ (3 files in 2 dirs): snes9x: fix sundry compilation problems May 21 14:58:18 03Phil Blundell  07org.openembedded.dev * rfc734ad620 10openembedded.git/: Merge branch 'org.openembedded.dev' of git@new.openembedded.org:openembedded into org.openembedded.dev May 21 14:58:34 Laibsch: et voila May 21 14:58:46 great May 21 14:59:06 * * OE Bug 1577 has been RESOLVED (LATER) by May 21 14:59:08 * * Minisip-video depend on ffmpeg in nonexisting version May 21 14:59:12 * * http://bugs.openembedded.net/show_bug.cgi?id=1577 May 21 14:59:55 pb_: looks like there is http://www.snes9x.com/downloads.php May 21 15:00:42 ah yes, seems 1.43 was released May 21 15:00:47 I guess we should update to that at some point May 21 15:01:47 still, 1.43-wip1 works well enough for me to play super mario kart, I am inclined to leave it alone :-) May 21 15:02:01 03Rolf Leggewie  07org.openembedded.dev * re687e226e1 10openembedded.git/recipes/minisip/minisip-video_svn.bb: minisip-video: move to nonworking. (Closes: #1577) May 21 15:02:47 Laibsch, be careful about moving stuff to nonworking, it will make the history harder to follow May 21 15:03:02 and potentially lead to it making it more difficult to fix stuff May 21 15:03:03 where else do you suggest to move it? May 21 15:03:08 leave it be May 21 15:03:19 I want to "bitbake world" May 21 15:03:45 well moving the recipes tht do not work for you is not they way to do that May 21 15:03:45 And I think there is value in getting stuff out of sight that has been nonworking for 3-4 years May 21 15:03:58 3-4 years May 21 15:03:59 I do not agree May 21 15:04:39 I do not see loads of people complain bitbake world does not work May 21 15:04:48 because nobody tries May 21 15:04:56 cause it immediately fails May 21 15:05:12 maybe we should remove the world option May 21 15:07:00 Hehe May 21 15:07:04 That is not really the problem May 21 15:07:18 I think that if we have a bb file, it should compile May 21 15:07:27 I know we'll never reach that state May 21 15:07:30 for all combinations May 21 15:07:38 sure, but moving stuff around will make it harder to see what changed May 21 15:07:48 that is a fine goal May 21 15:07:54 but I don't believe in the philosophy "once it's entered OE, never delete anything" May 21 15:08:04 I am absolutely with you May 21 15:08:12 I am an avid user of git log May 21 15:08:20 I also think we woll never get there May 21 15:08:22 And I hate it can't do directories better May 21 15:08:36 and do not want a work flow that will drive people nuts May 21 15:08:58 it is bad enough people deleting stuff just because THEY do not see a need for it May 21 15:09:11 now you will move things that do not work for you May 21 15:09:16 It drove nobody nuts that the package did not compile probably from the minute it entered OE May 21 15:09:33 I think that says enough about this particular case May 21 15:09:57 Well, if you object to moving stuff and prefer deletion, we can talk ;-) May 21 15:10:20 yeah, I would prefer not to have recipes hauled off to the nonworking ghetto as soon as they're discovered to be broken. not least because, personally, I seldom remember to look in nonworking/ when I'm trying to see if a particular package has already had a recipe written for it. May 21 15:10:30 :) May 21 15:10:31 agreed May 21 15:10:40 it's not what I am doing May 21 15:10:49 again, 3-4 years May 21 15:11:09 if it isn't in the main recipes/ directory, chances are I will just assume there isn't one and, depending on how much I cared about it, either write a new one (duplicating the effort of the old one) or just go away and have a small tantrum in the corner. May 21 15:11:48 yeah, 3/4 years is probably ok. I don't have a strong opinion about that; on the one hand I tend to agree that if nobody has noticed it's broken in that time then it might not be worth keeping. May 21 15:12:06 on the other hand, if nobody has been upset enough to fix or delete it already, it presumably isn't doing all that much harm either. May 21 15:12:10 imho some recipes have an excessive number of (unused) version in the repo May 21 15:12:13 my concern is there might be a combination that worked once upon a time May 21 15:12:24 and someone still maintains there own distro that uses it May 21 15:12:29 where it is anything May 21 15:12:32 * Laibsch agrees with ant_work May 21 15:12:39 ant_work, see my comment May 21 15:12:40 All this leads to complexity May 21 15:12:45 rubbish May 21 15:12:55 Nice May 21 15:12:58 yes, that's certainly true. one of my big frustrations with mythfront is that, almost every time I wanted to compile a new image (typically every 6-9 months or so) half the versions I was relying on would have been deleted as "unused" or "broken" or something. May 21 15:13:05 people need to support old stuff May 21 15:13:07 Crofton: if grep doesn't reveal any revdep...away May 21 15:13:11 at least people living in the real world May 21 15:13:28 now, they probably were indeed broken for angstrom on beagleboard or something, but they did happen to work for me on epia and I would rather have liked to keep them. May 21 15:13:30 Crofton: I see your point and agree May 21 15:13:32 I do not want to force people to fork OE becasue we delete stuff May 21 15:13:34 03Ihar Hrachyshka  07org.openembedded.dev * r340cb156e8 10openembedded.git/recipes/gstreamer/ (11 files): (log message trimmed) May 21 15:13:34 gst-plugins: fixed pattern for meta package dependencies. May 21 15:13:34 This fixes package name matching so that gst-plugins-*-meta May 21 15:13:34 packages include all the plugin ones. The current matching May 21 15:13:34 implementation doesn't make meta packages depend on gst-plugins May 21 15:13:35 with 'locale' and 'dev' in their names (f.e. gstfbdevsink). May 21 15:13:37 Also use INC_PR for gstremer-plugins as requested on ML. May 21 15:13:38 I don't discuss on that level May 21 15:13:39 Later May 21 15:13:44 03Koen Kooi  07org.openembedded.dev * rd04f5b461a 10openembedded.git/: Merge branch 'org.openembedded.dev' of git@git.openembedded.org:openembedded into org.openembedded.dev May 21 15:14:34 Crofton: *some* recipes have too many versions in OE, still May 21 15:14:48 (much of them GPE) May 21 15:14:54 yeah, but we need to be really thoguhtful about deletion May 21 15:15:20 ant_work: I think the problem there is just that, conceptually, the idea of having to have a separate .bb file for every single version is just a broken one. May 21 15:15:25 I do not pretend this is easy May 21 15:15:27 I would much prefer to fix that than to start deleting the old versions. May 21 15:15:49 pb_: sure May 21 15:16:03 then you have _git and SRCRES :) May 21 15:16:06 in the specific case of gpe you might well be right that nobody much cares about the old versions, since they're leaf packages and nothing depends on them. but I would hate for someone to generalise from that to more important packages. May 21 15:16:59 pb_: oneday an audacious should take the axe and start with /linux May 21 15:17:30 ant_work: linux/ is a good example of a package where people do definitely care about older versions. May 21 15:17:43 imho is out-of-control May 21 15:17:46 lots of platforms have their own favourite kernels that are very dear to their hearts and they would be very upset to have them taken away. May 21 15:18:19 platforms = distro ? machine ? May 21 15:18:29 machines, generally May 21 15:18:41 yeah May 21 15:18:56 I see redundancy... May 21 15:19:09 look at linux-rp ... May 21 15:19:10 I see gpl issues :) May 21 15:19:26 :) May 21 15:20:34 ok, this one would be a machine-maintainer task May 21 15:21:56 ant_work: why are these extraneous kernel versions upsetting you? May 21 15:22:12 too many cursor-down... May 21 15:22:16 :p May 21 15:22:29 seriously...>6700 recipes May 21 15:22:34 lunch May 21 15:23:16 pb_: I scratched the surface when I started patching the 'install -s' thing May 21 15:23:31 ant_work: yeah, as I say, in most cases I think this is a tool design problem and needs to be fixed in the tools. May 21 15:23:48 in the case of the kernel, there just genuinely are a lot of versions that need their own .bb files and I think we need to accept that. May 21 15:24:42 well, you could do it in one giant kernel file May 21 15:24:53 but it would be a nightmare to maintatin :) May 21 15:25:35 same for u-boot May 21 15:27:09 right, that's clearly not the answer either. kernels are, whether we like it or not, basically machine-specific things and the machine maintainers are going to want to hack them around. May 21 15:27:35 having one big file that all the crazy machine guys were hacking on would be a nightmare. May 21 15:27:59 yea, but old kernel_machine_version are just cruft after years May 21 15:28:00 we are doing ok with linux-omap May 21 15:28:08 So, what's the problem then? Magnetization is becoming too expensive? But people think my time to re-create deleted stuff is free??? :D May 21 15:28:14 ant_work, one mans cruft is another mans stable release May 21 15:28:18 NO DELETES! May 21 15:28:22 ant_work: not necessarily. I am still using plenty of kernels from many years ago. May 21 15:28:47 the fact that it's old doesn't mean it is broken. May 21 15:28:50 no extemists May 21 15:28:54 can make sense with collections May 21 15:28:57 Laibsch and I disagree vehemently on the delete issue, and if he wins the argument, then I shall force or leave OE. May 21 15:29:07 er, fork rather. May 21 15:29:20 mwester, you have plenty of support from me May 21 15:29:27 indeed, in the case of the kernel I would tend to think that being old probably means it's less broken, but I suspect I have an excessively jaundiced view of kernel development. May 21 15:30:00 I have no interest in spending hours of time sorting through build failures caused by over-eager deleters -- who do so only because of a sense of "asthetics". :( May 21 15:30:34 heh May 21 15:30:39 Old kernels are stable. There do exist many users who do not think that the purpose of a distro is to constantly upgrade itself. May 21 15:30:40 irrespective of old versus new, the point about the kernel is that folks often settle on a single version which works "well enough" for any given machine, and have no desire to go through the trauma of updating to a newer one for no particularly tangible benefit. May 21 15:30:41 I thought the main point with deletion was to help deal with the bitbake speed issues? May 21 15:30:53 These users often feel that the device has a useful purpose other than runing opkg update. May 21 15:31:06 (and more relevant for random userspace stuff than the kernels) May 21 15:31:21 broonie: some people seem to think that, but the right way to deal with the bitbake speed issues is to improve bitbake. May 21 15:31:29 pb_, +1 May 21 15:31:31 Well, quite. May 21 15:32:40 Or, for people who don't want to wait for that and need a solution today, to use BBMASK and/or collections so that bitbake sees fewer files. May 21 15:32:55 Yes! :) May 21 15:33:30 I would love to see a pre-packaged BBMASK that would be maintained by those who care only about the latest bleeding edge stuff. :) May 21 15:33:32 pb_: all nice and sound..still I'm overwhelmed by the numerosity of Zaurus (RIP 2008) kernels.. (2003-2009) May 21 15:34:40 ant_work: how many Z kernels are we actually talking about? At a first glance it looks like about ten to me. May 21 15:34:42 I would even use such a pre-canned BBMASK rather often., because there _are_ other distros I work on where I do try to use the newest stuff, including latest kernels. May 21 15:35:48 mwester: pb_ I could count 30 in the hurry May 21 15:36:15 Can we get a technical steering committee already? May 21 15:36:26 question: which *distros* are 'active' ? May 21 15:36:57 ant_work: even 30 doesn't strike me as a truly overwhelming number, given that there are several incompatible Z hardware platforms which each need their own. May 21 15:36:59 Tartarus: hear, hear May 21 15:37:43 pb_: there are 3 kinds of...embedix, linux-rp, linux (the future? May 21 15:42:00 right, and it certainly used to be the case that all three of them had their own adherents. May 21 15:43:59 Laibsch: if you feel masochist, try sharprom-compat-image nowaday ^_^ May 21 15:51:24 hi,why the variables such as the arch the distro,the machine etc... aren't displayed anymore after the parsing? May 21 15:51:55 is it because I upgraded to python 2.6? May 21 15:52:40 re May 21 15:53:24 hey May 21 15:53:51 Gnutoo: they god hidden recently May 21 15:54:16 otavio: I will rebase when you push May 21 15:54:16 ah ok it was the mail where it told that it was hiding things from the user? May 21 15:54:41 they were very usefull for debuging the abi and similar settings May 21 15:54:49 like glibc/uclibc also May 21 15:55:09 for instance when you struggle for having uclibc insterad of glibc May 21 15:55:17 you know it imediately May 21 15:55:36 (if you BBMASK or don't parse all recipes) May 21 15:56:12 g'day kergoth May 21 15:56:24 morning May 21 15:56:57 Gnutoo: bitbake -D May 21 15:57:09 ah ok thanks May 21 16:02:50 03Rolf Leggewie  07org.openembedded.dev * rbcc3623267 10openembedded.git/recipes/snes9x/snes9x_1.43-WIP1.bb: snes9x: bump PR May 21 16:12:36 http://darkwired.nl/~Industrial/img/lol/28aki86.jpg = awesome May 21 16:14:54 hmm I made my own kernel recipe based on linux_2.6.28.bb but it always fails in do_configure because there is no rule "make oldconfig"? how can this be? May 21 16:15:14 sounds like your S isn't set correctly May 21 16:15:22 * kergoth shrugs May 21 16:16:27 03Koen Kooi  07org.openembedded.dev * r8f389dd452 10openembedded.git/: Merge branch 'org.openembedded.dev' of git@git.openembedded.org:openembedded into org.openembedded.dev May 21 16:16:28 03Koen Kooi  07org.openembedded.dev * rce38ac7fce 10openembedded.git/recipes/gstreamer/gst-plugins.inc: gst-plugins: switch back to old way of excluding locales May 21 16:16:37 kergoth: do you have around the links to your cleaning-scripts (and results)? May 21 16:16:38 S? May 21 16:16:43 hmm, somewhere May 21 16:16:51 I'm not even sure which machine i wrote it on May 21 16:16:54 * kergoth has way too many trees May 21 16:17:03 * kergoth fires off a locate or 12 May 21 16:17:07 kergoth: Laibsch would be very interested... May 21 16:17:50 about $S, the kernel.bb seems needing its own May 21 16:18:11 ant_work: ? May 21 16:18:21 Laibsch: surprise :) May 21 16:19:23 basically many lines could be deleted from many recipes May 21 16:19:58 i'll make it not yell about PR, cause people dislike that one :P May 21 16:20:01 so one could just pick up a good exemple May 21 16:20:11 kergoth: eek May 21 16:20:24 I'm still not following you May 21 16:20:49 Laibsch: was just a prototype, proof of concept recipe metadata sanity script. would check, for example, if the unexpanded FILESPATH that a recipe defines is different from the original unexpanded FILESPATH, but the xpandedd versions are the same, then we know that the recipe doesn't need to set it May 21 16:21:04 Oh, that sounds nice May 21 16:23:15 this belongs to http://wiki.openembedded.net/index.php/Common_mistakes_in_a_recipe May 21 16:23:16 but of course, OE is not too complex. Anybody who says so is talking just "rubbish". May 21 16:24:52 ant_work: well, defining something that doesn't need defining isn't a mistake like the other two things listed on that page. But I guess "don't define default values" somehow fits May 21 16:25:01 * Laibsch likes PR = "r0", though May 21 16:25:13 as a reminder to bump it when necessary May 21 16:25:31 hmm I had set my work dir wrong, but now it's complaining that __LINUX_ARM_ARCH__ is not defined and #error unknown user model or something? this thing builds fine on its own >.< May 21 16:28:10 gotcha May 21 16:28:12 http://kergoth.pastey.net/111234 May 21 16:28:43 http://kergoth.pastey.net/111232 May 21 16:31:09 commit to contrib? May 21 16:31:23 and advocate on the list May 21 16:32:57 Laibsch: PR = "r0" was discussed a week or so ago. Most people who responded seemed in favor May 21 16:33:07 * * OE Bug 1196 has been RESOLVED (FIXED) by May 21 16:33:09 * * "bitbake snes9x" complains about missing -lqte May 21 16:33:11 * * http://bugs.openembedded.net/show_bug.cgi?id=1196 May 21 16:33:13 for me PR = "r0" can be in recipes May 21 16:33:17 also it is odd to remove the line when going to a new release May 21 16:40:26 Laibsch: contrib is fine with me, like i said, was just a proof of concept, but may be useful for someone looking to do some cleanup.. heh May 21 16:41:03 If cleanup remains possible, I may continue to do it May 21 16:41:34 Please commit the script to contrib May 21 16:42:07 k. i'll remove the autotools_base bits, thats specific to my autotools branch. autotools_base class is everything but autoreconf execution May 21 16:42:09 heh May 21 16:44:33 wtf May 21 16:44:34 fatal: cannot pread pack file: No such file or directory May 21 16:44:34 fatal: index-pack failed May 21 16:44:39 anyone seen that git error before? May 21 16:44:43 * kergoth tries a fresh clone instead May 21 16:47:22 bbl May 21 16:52:18 hello May 21 16:52:32 hey May 21 16:52:32 hrw: did it May 21 16:55:58 hi what are the advantages of minisip compared to others solutions? is it faster? May 21 17:11:31 otavio: so geodegx/lx will be i486 not i586? May 21 17:13:40 otavio: I will be back in ~1h - will you be then? May 21 17:19:59 http://www.linuxdevices.com/news/NS1980620246.html May 21 17:20:13 'kinda bug' smartphone :) May 21 17:22:16 Anybody know who Theodore Roth is? Did he get his RW recently? http://wiki.openembedded.net/index.php?title=OpenEmbedded_Developers&diff=prev&oldid=1390 May 21 17:22:32 hrw|gone: will be, np May 21 17:23:07 hrw|gone: we'd need to test it but I think i586 does work May 21 17:41:39 can someone explain why gnome.bbclass does a depends on gnome-common, and inherits gtk-icon-cache, which does an rdepends on hicolor-icon-theme? hicolor-icon-theme inherits gnome, as does gnome-common, so you get a circular dependency. May 21 17:46:27 kergoth: no, I find the gnome.bbclass dep on gtk-icon-cache strange May 21 17:46:45 s/dep/inherit May 21 17:47:35 mmm...does someone knows libosp2? which version provides osip_negotiation.h ? May 21 17:47:38 kergoth: I think it's the dependency of gtk-icon-cache on hicolor-icon-theme that's bogus. May 21 17:47:54 not least because it looks like it will apply to -dev and locale packages as well as the intended ones May 21 17:48:09 heh, good point, thats no good May 21 17:49:31 gnome packages do tend to need gtk-update-icon-cache run at install time, so the inherit of gtk-i-c from gnome.bbclass probably isn't unreasonable May 21 17:50:00 ah May 21 17:50:09 I can't think why using gtk-i-c means that you have a particular dependency on hicolor-icon-theme though. At a first guess I would have expected gtk+ itself to RRECOMMEND that pcakage. May 21 17:52:41 it also seems a bit weird that gtk-i-c.bbclass is adding "${datadir}/icons/hicolor" to FILES_${PN}. May 21 17:54:38 6c644a5c61dd3b814db20de7deefbe7485a7142a was the checkin where the dependency was added. May 21 17:54:56 found the correct version: https://dev.openwrt.org/ticket/1679 May 21 17:55:15 should we make libosip-2.2.2 the prefered version? May 21 17:56:15 hm, obviously this gnome stuff was all too much May 21 17:56:16 s/libosip-2.2.2/libosip2-2.2.2/ May 21 18:02:48 kergoth: according to the commit message, "gtk-icon-cache.bbclass: postinst scripts need hicolor-icon-theme (bunch of directories + 1 small textfile), so add it to RDEPENDS". May 21 18:03:06 I can't see anything in the postinsts that does genuinely depend on hicolor-icon-theme though; I suspect that justification is probably bogus. May 21 18:03:08 why would the postinsts need that? May 21 18:03:11 heh May 21 18:03:12 right then May 21 18:04:45 has anyone used a Qt app with a touchscreen device built with OE lately? May 21 18:04:55 the postinst/postrm scripts do also hardcode /usr/share rather than using ${datadir}; might be worth fixing that at the same time if you're going to edit the class. May 21 18:05:00 preferably an omap3 device? May 21 18:13:27 Laibsch: yes, Theodore Roth just go rw, per Mickey and my suggestion from some weeks ago May 21 18:13:56 Laibsch: was meaning to send email to oe-dev and got sidetracked ... May 21 18:33:02 03Koen Kooi  07org.openembedded.dev * rb2724ee710 10openembedded.git/recipes/glibc/ (glibc-initial_2.6.1.bb glibc_2.6.1.bb): glibc 2.6.1: bump PR for oldest-kernel change May 21 18:33:03 03Koen Kooi  07org.openembedded.dev * r794e8652f5 10openembedded.git/conf/distro/angstrom-2008.1.conf: Angstrom 2009.X: set OLDEST_KERNEL to 2.6.16 to avoid problems with ppoll() May 21 18:37:20 morning May 21 18:37:41 otavio: I used alix with settings which were before your changes May 21 18:37:57 otavio: when it used k6-2 march May 21 18:43:01 hrw: I have applied svn revision from bitbake svn, but I still get "__builtin__:74: DeprecationWarning: the sets module is deprecated" Do you have any idea about that? May 21 18:43:56 grep sets bitbake -r May 21 18:44:33 03Rolf Leggewie  07org.openembedded.dev * r977b935c7a 10openembedded.git/ (4 files in 2 dirs): May 21 18:44:33 pwlib: update SRC_URI, unify and clean-up. May 21 18:44:33 * build still fails, bug 1622 still open May 21 18:48:30 hrw: http://rafb.net/p/Id9vpZ77.html May 21 18:48:33 shell.py? May 21 18:52:23 yep May 21 18:54:30 sed s/sets/Sets/ bitbake/bb/shell.py May 21 18:54:31 ? May 21 18:55:23 I will prepare patch May 21 18:56:09 ~curse git-svn May 21 18:56:10 May the fleas of a thousand camels infest your most sensitive regions, git-svn ! May 21 18:58:39 Laibsch: how you get to this moment? -cdevshell? May 21 18:58:56 Just normal bitbake invocation May 21 18:59:24 bitbake $something May 21 18:59:41 The deb package I use is at https://launchpad.net/~r0lf/+archive/ppa May 21 19:00:38 but it's basically the deb from debian plus the revision 1178 from bitbake svn added to it May 21 19:03:26 I use trunk or top of bitbake-1.8 or stable/2009 May 21 19:07:57 Laibsch: .dev or stable/2009? May 21 19:10:00 .dev May 21 19:10:17 But I don't think that should have anything to do with it, no? May 21 19:10:19 no idea where from it comes May 21 19:10:31 mail about it to ML please May 21 19:10:37 OK May 21 19:11:17 But "/usr/share/python-support/bitbake/bb/shell.py: from sets import Set as set" is the culprit, we just don't know how it got there? May 21 19:11:19 sets is used only in shell.py but only if 'set' is not available (so python 2.3 rather) May 21 19:11:28 I removed that and still got it May 21 19:12:05 got it! May 21 19:12:07 task-base May 21 19:12:38 - if not hasattr(__builtins__, 'set'): May 21 19:12:38 - from sets import Set as set May 21 19:12:43 in task-base.bb May 21 19:12:49 but thats probably also not that May 21 19:13:08 http://docs.python.org/library/__builtin__.html May 21 19:13:16 I think that is getting warmer May 21 19:13:54 I think that whatever provides __builtin__ may be the culprit May 21 19:13:57 not bitbake May 21 19:14:13 hrw: right but I belive that i586 will do fine May 21 19:14:20 And from what I understand of that page, that $whatever may be python 2.6 itself May 21 19:14:33 hrw: I can't compile it from scratch today but I can manage to test it later this week May 21 19:14:42 otavio: would be nice May 21 19:14:57 otavio: I have to export my patches and send to ML May 21 19:15:01 hrw: do you have time to test it? May 21 19:15:11 hrw: it would be nice May 21 19:16:08 otavio: I will do a build and have a look does it boots and do 'openssl speed' on it May 21 19:16:41 hrw: nice May 21 19:17:19 my work branch has also some ep93xx work May 21 19:20:19 have a nice rest of day May 21 19:20:21 * hrw -> off May 21 19:29:28 Crofton: would you be OK with setting COMPATIBLE_MACHINE to an empty string for recipes that fail? Others can then add their machine if the recipe works for them. I think that would be a reasonable compromise. May 21 19:29:44 mwester: same question May 21 19:30:08 Laibsch, ask on the list May 21 19:30:18 I'm asking your opinion first May 21 19:30:20 does that work? May 21 19:30:30 Compable_machine? May 21 19:30:36 well in recipes May 21 19:30:38 Yes, the setting works and is used May 21 19:30:40 I suspect it will May 21 19:30:52 let's assume for now that it does May 21 19:30:56 well, it does not annoy me May 21 19:31:02 if it did, what's your opinion May 21 19:31:09 see above May 21 19:31:13 deleted and moved recipes annoy you May 21 19:31:17 highly May 21 19:31:35 not sure it can always be avoided May 21 19:31:47 basically, I think it is a question worth presenting to a larger audience May 21 19:31:53 yes May 21 19:31:58 starting with 1 May 21 19:32:36 so, what is your opinion? May 21 19:32:54 ask the list :) May 21 19:33:01 I think it is worth presenting May 21 19:33:10 OK, so your opinion is the same as the list? May 21 19:33:16 sheesh! May 21 19:33:18 my opinion on this is flexible May 21 19:33:41 It did not sound very flexible earlier May 21 19:33:48 But maybe that is my English May 21 19:33:59 heh May 21 19:34:09 it is inflexible about moves/delets May 21 19:34:23 yes, we are likely having communicaiont issues May 21 19:34:35 well, the question is about this May 21 19:34:45 basically, if you ask about moves/deletes on the list, I will reply promptly saying I do not liek the idea May 21 19:35:03 so I really don't understand why you can't give me "I think this may work" or "I'm not sure" or something like that May 21 19:35:07 but, COMPATIBLE_MACHINE I would like to hear other devs thoughts May 21 19:35:27 * Laibsch sending mail May 21 19:35:31 I like it enough to see what others think May 21 19:35:32 good May 21 19:36:04 the basic premise that bitbake world actually complete is not high on my list :) May 21 19:54:47 erk May 21 19:54:53 i just broke bitbake, and i have no idea how to fix this one May 21 19:55:03 File "/home/build/integration-platform-build/buildroot/opt/montavista/lib/python2.4/site-packages/bb/runqueue.py", line 248, in find_chains May 21 19:55:03 File "/home/build/integration-platform-build/buildroot/opt/montavista/lib/python2.4/site-packages/bb/runqueue.py", line 248, in find_chains May 21 19:55:03 File "/home/build/integration-platform-build/buildroot/opt/montavista/lib/python2.4/site-packages/bb/runqueue.py", line 249, in find_chains May 21 19:55:03 KeyError: 447 May 21 19:55:26 there were like 30 entries for line 248 in find_chains in the traceback May 21 21:07:14 http://www.industrial-embedded.com/news/Industry+News/17450 May 21 21:07:46 I'm having some difficulty with a package of mine thats failing the GNU_HASH sanity check - all that should be needed is to ensure that --hash-style=gnu is a param at link time correct? May 21 21:08:15 tharvey: look at the other recipes May 21 21:08:31 you need to ensure it links using our ldflags May 21 21:08:48 crofton, thanks for the link May 21 21:09:23 ya... its tending to be tricker than I had hoped - its a madwifi driver package. I look at the existing madwifi recipes but they seem broken right now if I'm not mistaken May 21 21:09:34 crofton, are you with embedded alley May 21 21:10:05 Crofton: sounds like an impressive featureset May 21 21:10:13 particularly the BoM / tracability May 21 21:11:20 tharvey: if it's a driver package in the sense of kernel drivers, it shouldn't be getting that check applied at all. May 21 21:16:30 pb_, madwifi includes some userland tools - its those that fail the GNU_HASH based on ldflags that I'm trying to fix May 21 21:17:10 tharvey, look in the git log for some similar fixes May 21 21:17:59 http://cgit.openembedded.org/cgit.cgi/openembedded/commit/?id=86999e943334858a687a51bbe2165ede26b00473 May 21 21:18:48 ok... I'll keep working on it thx May 21 21:20:13 tharvey: ah right, fair enough. anyway, yeah, like kergoth says, it's basically just a case of making sure that ${LDFLAGS} is included in the final link. May 21 21:21:06 hard-wiring --hash-style=gnu would remove the particular qa error but would (at least in part) defeat its purpose. May 21 21:22:20 agree'd but for some reason hard-wiring that still didnt' even produce the right thing in objdump so I wanted to make sure I understood GNU_HASH May 21 21:22:34 but your point is taken... the real purpose is to make sure OE's supplying ldflags May 21 21:27:40 madwifi seems tob e perhaps a special case though - http://cgit.openembedded.net/cgit.cgi?url=openembedded/commit/&id=75d4826c3c0f7012ccee3a7116d7350f41539fa3 May 21 21:36:04 It could be May 21 21:39:39 tharvey: that fix is wrong... LDFLAGS is needed for some tools May 21 21:39:54 tharvey: the real fix is to clear LDFLAGS in the correct Makefiles, not in the recipe May 21 21:40:16 tharvey: that commit undo's some of my (yes, agressive) fixes to make it work on powerpc again May 21 21:40:55 * Jay7 -> sleep May 21 21:41:00 tharvey: this was related to my fix: http://cgit.openembedded.net/cgit.cgi?url=openembedded/tree/recipes/madwifi/files/respect-ldflags.patch&id=eaea0ee411da83f7c5349920c701a55a17384f8e May 21 21:42:17 03Rolf Leggewie  07org.openembedded.dev * r268aed6297 10openembedded.git/ (conf/checksums.ini recipes/directfb/directfb_1.2.7.bb): directfb: 1.2.7 has been superseeded. Fix SRC_URI. May 21 21:42:56 mwester: ping May 21 21:45:12 tharvey: See openembedded ml: "[PATCH] madwifi-ng_r3837: Fix for LDFLAGS / GNU_HASH QA" May 21 21:54:43 likewise, pong. May 21 21:56:08 mwester: tharvey runs into the same GNU_HASH problem I fixed (aggressively) in madwifi, which you reverted (unset LDFLAGS) May 21 21:56:33 Is there a problem, or is it just a sanity check? May 21 21:56:36 mwester: I suggest to keep LDFLAGS set, and unset it only in the Makefiles where it needs to be unset. May 21 21:57:18 Is there a problem, or is it just a sanity check? May 21 21:57:20 mwester: it's a problem, it means the LDFLAGS (library link path etc) was incorrect. May 21 21:57:25 Is there a problem, or is it just a sanity check? May 21 21:58:10 It's a problem on some archs. May 21 21:58:29 I changed it in a bb recipe that is ONLY used by SlugOS. Beyond that, I think the LDFLAGS issue is just a warning, whereas the failure for ixp4xx arch devices is an outright failure. May 21 21:59:25 mwester: what if I use EXTRA_DEPENDS in my local.conf? May 21 22:00:00 mwester: It's a warning that something is wrong. I agree your revert is ok, I just want to find a proper fix. May 21 22:00:52 mwester: Do you still have the build log for madwifi when it failed in tmp/work/*/*/madwifi*/temp/log.do_compile* May 21 22:01:18 It's a warning that the dynamic linker will take a few nano-seconds longer to link in the libs, as I understand it. May 21 22:01:31 No, I have no logs for that any longer. May 21 22:02:31 MACHINE = "nslu2be" & DISTRO="slugos" May 21 22:02:38 mwester: Yes, that's the warning, However, the cause is that the linker flags for the target build during linking the tools is dead wrong. which brings out other problems May 21 22:02:47 mwester: thanks will reproduce May 21 22:03:33 Yes. And forcing the OE LDFLAGS into the makefiles to override the options provided by the madwifi folks breaks the linker args that permit the linking in of the binary blobs. May 21 22:06:15 You're welcome to spend cycles on that issue; it's of very little importance IMO because I understand the issue to be a very small amount of overhead to the linker, and nothing more. It's hardly worth the hours and hours of battling with the madwifi makefiles, which change constantly, requiring patches to be refreshed with each svn update... just not worth a few nanoseconds of CPU cycles for some infrequently-used admin applications. May 21 22:08:03 mwester: The build breaks for everyone who has the sanity checks enabled. They default to failure now I think, instead of warning. May 21 22:08:15 That sucks. May 21 22:08:28 Rather a foolish decision. May 21 22:09:23 * mwester shrugs -- too much other real-life stuff going on right now to deal with the silly OE "screw-the-existing-distros-the-only-one-that-matters-is-Angstrom" crap. May 21 22:10:02 And you KNOW that was a Koen decision, and nobody else could (or cared to) argue. May 21 22:11:11 anyway, must run - flat tire that I have to get fixed right now. May 21 22:12:00 I'm ignorant of that, really. I was just building madwifi for my powerpc. May 21 22:30:58 likewise, why not just build the version everyone else builds? May 21 22:31:26 r3878 had default preference of -1, so it should be used ONLY by SlugOS. May 21 22:34:23 mwester: I don't know, I think I have used that version since a year or so, when it was the latest. May 21 22:34:31 fine. May 21 22:34:57 then I'll make r3879 for slugos. May 21 22:36:44 * XorA goes to find sleep May 21 22:37:27 mwester: is this about claiming recipes for a single machine or distro? My goal is to make OE work for all machines I have here. Yes that breaks stuff sometimes, I'm sorry my fix was not complete. May 21 22:37:55 This is about making something work, and keeping it working. May 21 22:38:06 Apparently we need something different for SlugOS vs Angstrom. May 21 22:38:13 How do we do that? May 21 22:38:21 pistols at dawn May 21 22:38:35 I've tried EVERYTYHNG I KNOW to keep out of everybodies' freeweking way in OWE> May 21 22:38:58 Yet I spend 70+ percent of my OE time FIXING shit. May 21 22:39:04 instead of developing or supporting a distro. May 21 22:39:10 Yes, I'm frustrated. May 21 22:39:16 I don't care about elegant. May 21 22:39:38 It's impossible to keep .dev working at all times for everyone, while we globally try to improve it. May 21 22:39:46 My users don't care about elegant, or angstrom, or how many freeking recipes there are in a directory in OE. They want it to work and they wnat opkg upgrade to work. That's all. May 21 22:40:00 likewise, I fixed it, didn't I? May 21 22:40:09 Did I ping you even? May 21 22:40:12 No. May 21 22:40:17 I freeeking fixed it for slugos. May 21 22:40:30 do you branch your distro to stabilise it for your users or use dev? May 21 22:40:48 Now don't go getting all worked up becuase I changed one freeking thing in a recipe that is CLEARLY slugos-specific. May 21 22:41:03 timtimred, I'm not arguing with you, am I? May 21 22:41:20 I have both branches, and I have the next release to consider. May 21 22:41:20 im not arguing here im just vaguely interested :) May 21 22:41:23 Hence I need both. May 21 22:41:50 If I ignore OE until I'm ready for the next release, then how is that any better than trying to keep up as things change? May 21 22:42:04 We've tried that. It's worse. May 21 22:42:26 So I'm just about fed up with trying every possible thing I can do to stay out of everyone else's way. May 21 22:42:34 DEFAULT_PREFERENCE = -1 May 21 22:42:43 DEFAULT_PREFERENCE_slugos = 1 May 21 22:42:45 ? May 21 22:43:06 Should I name the version differently? packagname_SLUGOS_pv.bb? May 21 22:43:19 * kergoth still thinks we should separate things that are actively maintained by specific individuals or groups from the crap thats collectively maintained, and hence is less likely to work at any given moment May 21 22:43:34 kergoth misses the point. May 21 22:43:41 mwester: what if DEFAULT_PREFERENCE_somemach = 1 is added? May 21 22:44:16 This is not about system-specific packages, this is about cases where someone changes a common package, making it fail to build on ixp4xx or some other machine. May 21 22:44:30 likewise, yeah, what? May 21 22:44:49 likewise, then whomever did that has agreed that the recipe as it stands works for them. May 21 22:45:26 ok, and no ONE of the archs start to fail due to toolchain upgrade May 21 22:45:26 likewise, and you know what else? rather than argue, I would change the version and make aother bb file for slugos, so that it could, once again, have a bb file that works for ixp4xx systems without troubling anyone else in OE. May 21 22:45:42 s/no/now/ May 21 22:45:50 Don't even start me on toolchain issues. That nightmare continues. May 21 22:46:01 It's gotten a lot better in the past months, though. May 21 22:46:38 And helped a lot more when I finally was able to break compat for SlugOS users and switch to EABI, and pretty-much clone the Angstrom stuff. May 21 22:46:50 so you prefer claiming a recipe for one distro, instead of making it work across all machines? May 21 22:46:51 The closer you are to Angstrom, the better life is. May 21 22:47:18 ...+distros? May 21 22:47:27 likewise, when I have no access to other machines, and the recipe is CLEARLY highly (ie binary blobs) architecture-dependent,then the answer is a resounding YES!!!!!!! May 21 22:47:34 likewise: most people do only care about one distro. that's just life. May 21 22:47:57 I do not feel that any one person can adequately test out-of-kernel device drivers in the first place. May 21 22:47:59 making it work for other distros is fine, but breaking it for the person who created it in the first place is not really on. May 21 22:48:12 mwester: ok, I can see why, please don't shout. I'm trying to find a middle way to fix this without being in your way. May 21 22:48:23 mwester needs to get laid or something, instead of bitching left and right on irc May 21 22:48:36 kergoth, go to (*(*(* May 21 22:48:57 whine some more, please, thats just what we all need to hear May 21 22:50:05 heh. well, he does have some valid points. May 21 22:50:37 I have had that same frustrating experience of expending a lot of effort just to stay in the same place. it is something that we do need to figure out a solution for. May 21 22:50:45 he does, but i don't think being that argumentative and abrasive and yelling at people is going to help fix it, either May 21 22:50:49 I'm ok with ppl claiming a recipe, but that should be mentioned in the recipe then. May 21 22:50:54 not that i was much better in the past, but.. :) May 21 22:51:20 in the MAINTAINERS file ... May 21 22:51:38 or did that change, i know there was some discussion but i missed the end... May 21 22:51:41 yah, agreed, shouting and screaming is not really the right way to get things done. May 21 22:53:20 as for MAINTAINERS, dunno, I lost track of that too. May 21 22:53:24 btw, iirc there is a var like 'skip_QA' for the specific mwester case May 21 22:53:37 i think in addition to the reproducability problems thatve been discussed a lot, itd help to have better tools for doing a pile of local builds of various sets of recipes in various orders with various distros and machines, to make sure your changes didn't blow anything up May 21 22:53:38 heh May 21 22:53:57 yeah May 21 22:54:09 * pb__ adds that to the long list of better tools that would help May 21 22:54:10 ideally, a build machine that does auto-bisect on builds. May 21 22:54:39 we need to find a way to all get in one place for a bit May 21 22:54:55 despite all our attempts to change it, build order can still affect things. i was thinking the other day that you could create a sanity function thatd use autoconf tracing to dump a list of available --with/--enable arguments and warn if any are missing, since that tends to lead to automatic enabling/disabling of features based on the environment, which is bad May 21 22:55:01 takes many build cycles though... I have had this semi-automated once under monotone May 21 22:55:06 likewise: isn't that basically what tinderbox is? May 21 22:55:19 pb__: yes, minus auto-bisect May 21 22:55:19 obviously no auto-bisect as such, but if it builds often enough you should still get the same effect May 21 22:55:42 pb__: agreed, maybe tinderbox should report good and bad builds to a bisector May 21 22:55:53 yeah, that's not a bad idea May 21 22:56:12 machine X, distro Y, target Z for commit C: failed or succeeded May 21 22:56:20 machine X, distro Y, target Z for commit C2: failed or succeeded May 21 22:56:31 then auto bisect between C and C2 for that combo May 21 22:56:51 kergoth: right, it'd be nice to find a way to better isolate autoconf from the host environment. could even consider actively sandboxing it with some kind of LD_PRELOAD thing, for hosts that support it. May 21 22:57:16 03Koen Kooi  07org.openembedded.dev * r4c275b5c03 10openembedded.git/classes/gnome.bbclass: May 21 22:57:16 gnome bbclass: package scrollkeeper 'leftovers' in a seperate package. Like the fdo mime data it overlaps between packages. May 21 22:57:16 * better solution is needed for people wanting docs on device, but this makes packages at least installable May 21 22:57:24 03Koen Kooi  07org.openembedded.dev * r2a20dd7eef 10openembedded.git/ (4 files in 2 dirs): ekiga: update ekiga bits to 3.2.4 May 21 22:57:25 03Koen Kooi  07org.openembedded.dev * r23516c5a60 10openembedded.git/: Merge branch 'org.openembedded.dev' of git@git.openembedded.org:openembedded into org.openembedded.dev May 21 22:57:26 03Koen Kooi  07org.openembedded.dev * rdd68f2a6e6 10openembedded.git/: Merge branch 'org.openembedded.dev' of git@git.openembedded.org:openembedded into org.openembedded.dev May 21 22:57:27 that's true. you'd probably need a whitelist for the build machine's binaries/libs that we need to let still function, or at least depend on -natives for May 21 22:57:28 hmm May 21 22:57:35 that's not all hosts, of course, but I guess this is like vaccinating for measles: you just have to get a critical mass of developers doing it right, and then everybody else gets kind of carried along with the herd. May 21 22:57:49 heh, indeed May 21 22:58:07 right, but I think the set of host bits that oe can legitimately access is pretty small. nowadays. May 21 22:58:44 the list of -native packages has burgeoned somewhat of late, which is probably a good thing, and that replaces a pile of things that we used to expect from the host. May 21 23:00:38 likewise: for madwifi you could perhaps add INSANE_SKIP May 21 23:00:40 http://cgit.openembedded.net/cgit.cgi?url=openembedded/commit/&id=13e3e087e4d45555ee29caf09576961db9e5f30e May 21 23:00:53 if you're really sure May 21 23:01:01 it is sane May 21 23:01:36 ant__: ok tnx, I'll try to fix it first though May 21 23:02:41 i think this smooths the effect of having fatal QA May 21 23:03:02 * pb__ zzz now May 21 23:03:03 night all May 21 23:03:07 zz May 21 23:03:13 cya May 21 23:03:16 gn May 21 23:03:21 going too, bye May 21 23:03:23 -zz May 21 23:03:32 can't sleep yet May 21 23:06:17 heh May 21 23:06:19 why not? May 21 23:06:40 holiday here, so I went to bed 3 hours late yesterday evening May 21 23:06:57 i'll probably have +8 hours offset on monday :-) May 21 23:07:11 ah May 22 01:07:53 gn all **** ENDING LOGGING AT Fri May 22 02:59:57 2009