| 00:00.10 | kergoth | likewise: it's definately used for the target perl, the same way python-native is usedf or the target python, because it has to be the same version, afaik |
| 00:00.17 | kergoth | but beyond that, /shrug |
| 00:00.25 | likewise | kergoth: what would you suggest? |
| 00:00.57 | kergoth | my first inclination would be to kill all perl-native deps other than for the perl crosscompilation, and see what explodes in a test build |
| 00:01.00 | kergoth | maybe i'll add that to my todo.. |
| 00:01.01 | likewise | kergoth: what "perl scripts <...> are still relying on the build machine's perl"? |
| 00:01.12 | kergoth | shrugs |
| 00:01.18 | kergoth | wonder who's maintaining the perl stuff |
| 00:01.36 | likewise | heh, this is open-source :-) |
| 00:02.18 | kergoth | heh :) |
| 00:02.30 | kergoth | still thinks we need more individual responsibility for recipes and classes, somehow |
| 00:16.27 | likewise | I think the best way is to have a few groups, like the toolchain group, which have a focus. Not necessarely one individual per recipe; that won't work. |
| 00:17.25 | likewise | So you want "Less Loosely Knit Hackers" :-) |
| 00:21.13 | kergoth | thatd work too, i just want actual responsibility |
| 00:21.26 | kergoth | so you dont just break something and move on to other things |
| 00:21.38 | kergoth | if I'm responsible for autotools, and it breaks, i want people to yell at me about it |
| 00:22.04 | kergoth | right now breakage is just fixed by whomever happens to feel like fixing it, but I'd be a lot more confident in fixes if they were done by those most familiar with those recipes or classes |
| 00:22.18 | kergoth | less likely to introduce unrelated issues |
| 00:33.45 | *** join/#oe hufnus_cicq (n=hufnus_c@69-12-177-67.dsl.static.sonic.net) |
| 00:36.11 | CIA-35 | 03Rolf Leggewie <oe-devel@rolf.leggewie.biz> 07org.openembedded.dev * r4e16e01337 10openembedded.git/conf/checksums.ini: checksums.ini: add entry for an AVR32 u-boot patch. (Closes: #4804) |
| 00:38.06 | cdbot2 | * * OE Bug 4804 has been RESOLVED (FIXED) by <Laibsch> |
| 00:38.08 | cdbot2 | * * Some more checksums missing |
| 00:38.10 | cdbot2 | * * http://bugs.openembedded.net/show_bug.cgi?id=4804 |
| 00:50.36 | *** join/#oe waite (n=bwaite@c-24-91-81-44.hsd1.ma.comcast.net) |
| 00:55.49 | likewise | good night all |
| 00:55.59 | kergoth | night |
| 00:56.51 | *** join/#oe HellDragon (i=jd@Wikipedia/HellDragon) |
| 01:12.05 | cdbot2 | * * OE Bug 5115 has been created by <Laibsch> |
| 01:12.07 | cdbot2 | * * include information about unshipped files in QA log |
| 01:12.09 | cdbot2 | * * http://bugs.openembedded.net/show_bug.cgi?id=5115 |
| 01:22.08 | *** join/#oe Flyser_ (n=Flyser@unaffiliated/flyser) |
| 01:25.11 | zerum | hm, for some reason, bibake don't recognize the 4.5 version of qtx11, although the recipe file is there. |
| 01:39.36 | *** join/#oe kergoth (n=kergoth@ip98-167-215-86.ph.ph.cox.net) |
| 01:42.20 | Neko | hmmm even though I set up a 2.6.28.10 recipe based on 2.6.28.bb and my patchset, it still is mentioning 2.6.28-r6 a lot in bitbake build messages |
| 01:59.18 | *** join/#oe zecke (n=ich@123-192-147-94.dynamic.kbronet.com.tw) |
| 02:06.33 | *** join/#oe fraxinas (n=quassel@p54AA7C79.dip.t-dialin.net) |
| 02:08.50 | *** join/#oe zerum (n=quassel@187.37.59.58) |
| 02:19.18 | *** join/#oe BenLauDC (n=benlau@221.125.8.105) |
| 02:19.49 | Crofton | did you set PV in the recipe ... |
| 02:37.18 | *** join/#oe waite (n=bwaite@c-24-91-81-44.hsd1.ma.comcast.net) |
| 03:09.26 | *** join/#oe mrmoku|away (n=mrmoku@ppp-93-104-109-14.dynamic.mnet-online.de) |
| 03:23.13 | *** join/#oe jayiz (n=Owner@202-89-173-144.static.dsl.amnet.net.au) |
| 04:19.48 | *** join/#oe mrc3 (n=ddiaz@189.157.113.43) |
| 04:22.21 | *** join/#oe zerum (n=quassel@187.37.59.58) |
| 04:40.41 | CIA-35 | 03Angus Ainslie <nytowl@openmoko.org> 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 |
| 05:35.56 | *** join/#oe Sup3rkiddo (n=sudharsh@unaffiliated/sudharsh) |
| 05:37.30 | *** join/#oe marex (n=marex@vasut.kolej.mff.cuni.cz) |
| 06:14.17 | *** join/#oe booxter (n=booxter@80.249.92.179) |
| 06:16.37 | *** join/#oe pigeon (n=pigeon@60-241-137-179.static.tpgi.com.au) |
| 06:16.57 | *** join/#oe Timelord (n=TL@16.8c.d12c.cidr.airmail.net) |
| 06:44.53 | mckoan | good morning |
| 06:45.33 | XorA | morning |
| 06:52.44 | *** join/#oe Jay7 (n=jay@93-81-140-165.broadband.corbina.ru) |
| 06:57.31 | *** join/#oe pvanhoof (n=pvanhoof@d54C0C0BA.access.telenet.be) |
| 06:58.08 | *** join/#oe gremlin[it] (n=gremlin@host209-103-static.32-85-b.business.telecomitalia.it) |
| 06:59.32 | gremlin[it] | morning all |
| 07:04.01 | mckoan | hi gremlin[it] |
| 07:04.27 | gremlin[it] | hi mckoan ! |
| 07:11.03 | XorA | hey .it dudes |
| 07:11.45 | Jay7 | morning :) |
| 07:12.05 | cdbot2 | * * OE Bug 5116 has been created by erik.boto(AT)gmail.com |
| 07:12.07 | cdbot2 | * * Undefined reference to ppoll when building udev and jack |
| 07:12.09 | cdbot2 | * * http://bugs.openembedded.net/show_bug.cgi?id=5116 |
| 07:12.58 | XorA | hey Jay7 I hear you scored a tosa :-) |
| 07:14.50 | Jay7 | XorA: tosa is in my relative in USA |
| 07:15.37 | Jay7 | it will be in Russia in May 27 |
| 07:15.37 | XorA | Jay7: wish you had said, you could have had the one here and cleared out some desk space for me |
| 07:17.01 | Jay7 | XorA: I hope there will be any other tosa lovers ;) |
| 07:17.14 | Jay7 | it thinking about GTA.. |
| 07:17.22 | XorA | has been trying to offload it for nearly 2 years :-) |
| 07:17.39 | Jay7 | when someone have unused gta in usa tell me ;) |
| 07:18.50 | *** join/#oe Spyro (n=ian@benden.mnementh.co.uk) |
| 07:18.51 | XorA | Jay7: you mean open moko devices, I have spare |
| 07:20.15 | Jay7 | XorA: you have said already.. but delivery from UK is expensive :) |
| 07:20.38 | Jay7 | I have no 'couriers' in UK :) |
| 07:20.54 | XorA | Jay7: do you have them in any .eu contries? |
| 07:21.09 | XorA | Jay7: are you going to linuxtag? |
| 07:21.20 | Jay7 | 1) no 2) no :( |
| 07:21.25 | XorA | arse |
| 07:21.30 | Jay7 | yeah.. |
| 07:23.35 | *** join/#oe mgwpub (n=mgwpub@193.170.134.119) |
| 07:25.49 | XorA | falls over looking at shipping prices |
| 07:33.09 | Jay7 | crazy tariffs :) |
| 07:35.00 | XorA | more than the devices are worth |
| 08:28.45 | *** join/#oe Sleep_Walker (n=Sleep@nat/suse/x-8bc593fbdad01dfe) |
| 08:46.47 | hrw | morning |
| 08:50.03 | mckoan | hi hrw |
| 08:50.44 | hrw | mckoan: good news for you - I have nanopc running again |
| 08:51.11 | hrw | as 'connected to net,screen,keyboard' so will look how things are |
| 08:51.12 | mckoan | hrw: why it wasn't running? |
| 08:51.58 | hrw | mckoan: I lacked spare vga display |
| 08:52.01 | *** join/#oe ant_work (n=andrea@host214-85-static.34-85-b.business.telecomitalia.it) |
| 08:52.31 | *** join/#oe booxter (n=booxter@cpmsq.epam.com) |
| 08:53.41 | *** join/#oe pH5 (n=ph5@e178211112.adsl.alicedsl.de) |
| 08:54.14 | mckoan | hrw: you could use a KVM switch |
| 08:54.51 | hrw | thats the option to consider |
| 08:55.01 | ant_work | morning |
| 08:55.17 | mckoan | hrw: I use it and I'm very satisfied, considering my tiny office |
| 08:57.20 | ant_work | hm..koen: udev-141-r4 is failing for me and Crofton (armv5te / armv7-a) |
| 08:57.39 | ant_work | undefined reference to `ppoll' |
| 08:59.57 | pb___ | ant_work: I don't think koen is in this channel :-} |
| 09:00.16 | ant_work | hey...wrong label... |
| 09:01.30 | ant_work | pb___: btw, why is there a difference? http://rafb.net/p/mlsRiw76.html |
| 09:01.55 | ant_work | udevd.c:(.text+0x16e4) vs udevd.c:978: |
| 09:02.51 | ant_work | and the paths |
| 09:06.27 | *** join/#oe zecke (n=ich@123-192-147-94.dynamic.kbronet.com.tw) |
| 09:06.34 | ant_work | anyway...The ppoll() system call was added to Linux in kernel 2.6.16. The ppoll() library call was added in glibc 2.4. |
| 09:06.46 | ant_work | possibly a missing include |
| 09:07.27 | erbo | ant_work: i filed a bug on the ppoll issue |
| 09:07.43 | ant_work | thx |
| 09:07.54 | erbo | I get it on udev and jack |
| 09:08.07 | erbo | Just when I got my BB rev C2 :) |
| 09:08.52 | ant_work | somewhere #include "ppoll.h" |
| 09:09.06 | *** join/#oe greentux (n=lemke@BAA1c0d.baa.pppool.de) |
| 09:09.16 | *** join/#oe rkirti (n=rkirti@117.254.20.142) |
| 09:09.49 | erbo | great, tnx |
| 09:10.20 | ant_work | I'm googling and it seems bluez-utils is using it |
| 09:21.28 | erbo | 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? |
| 09:24.00 | ant_work | hm.../udev/udevd.c:#include <sys/poll.h> |
| 09:24.16 | ant_work | I can't check here |
| 09:24.39 | *** join/#oe pOH9 (n=ph5@e178238207.adsl.alicedsl.de) |
| 09:25.17 | erbo | I'll give it another shot |
| 09:25.18 | *** join/#oe lrg (n=lrg@host81-136-218-57.in-addr.btopenworld.com) |
| 09:26.41 | erbo | oooh, I'm blind.. I included ppoll and not poll.. |
| 09:27.04 | Jay7 | http://www.freebsd.org/cgi/man.cgi?query=ppoll&apropos=0&sektion=2&manpath=SuSE+Linux%2Fi386+ES+10+SP1&format=html |
| 09:27.19 | ant_work | morning Yuri ;) |
| 09:27.34 | Jay7 | according to SYNOPSYS - #include <poll.h> is enough |
| 09:27.40 | erbo | same problem though, but atleast it find sys/poll.h now :) |
| 09:27.46 | Jay7 | ant_work: morning :) |
| 09:28.13 | Jay7 | but this is man from OpenSUSE ES 10 :) |
| 09:28.47 | Jay7 | hm.. this is linking error |
| 09:29.03 | ant_work | he |
| 09:29.05 | Jay7 | but ppoll should be in stdlib imho |
| 09:30.09 | Jay7 | <PROTECTED> |
| 09:32.06 | ant_work | ah..Jay7..syscall is your passion, isnt? :D |
| 09:32.52 | Jay7 | he 50 |
| 09:32.53 | *** join/#oe mpoullet|home (n=mpoullet@77-22-121-59-dynip.superkabel.de) |
| 09:32.59 | Jay7 | s/50/:)/ |
| 09:32.59 | mpoullet|home | good morning |
| 09:34.00 | hrw | mckoan: 1680x1050 framebuffer looks nice |
| 09:37.21 | mckoan | hrw: good! I'll test it later too, could you please send me your xorg.conf ? |
| 09:38.31 | Jay7 | hm.. |
| 09:38.43 | Jay7 | is looking at moblin's screenshots |
| 09:39.07 | Jay7 | seems there is second candidate to be useful on zauruses :) |
| 09:40.11 | Jay7 | erbo: can you find command line which is used to link udev.o? |
| 09:40.22 | Jay7 | make output should contain this |
| 09:40.52 | Jay7 | better to use w/o parallel make. |
| 09:42.14 | zecke | Jay7: moblin o zaurus? with what kind of GL implementation? |
| 09:42.30 | Jay7 | GL.. sh*t :) |
| 09:42.41 | Jay7 | is GL required for moblin? |
| 09:43.03 | pb_ | yeah, I think it is |
| 09:43.07 | pb_ | zecke: hail zecke |
| 09:43.15 | Jay7 | well.. then maemo's hildon is the one :) |
| 09:44.02 | pb_ | ant_work: you mean why are the error messages different? either different binutils or different compiler flags at a guess. |
| 09:44.35 | pb_ | 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 |
| 09:44.50 | pb_ | s/function name/line number/ |
| 09:45.25 | zecke | Jay7: moblin2 is using clutter... which s a scene graph library on top of OpenGL... :) |
| 09:45.28 | pb_ | 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. |
| 09:45.28 | Jay7 | seems I should try to build new udev too :) |
| 09:45.37 | Jay7 | zecke: bad luck :) |
| 09:48.25 | hrw | mckoan: I use framebuffer now - need to get system updated first |
| 09:48.48 | ant_work | pb_: almost clear now, thx |
| 09:50.32 | hrw | heh.. to install opkg-nogpg I need to remove opkg which I need to install opkg-nogpg ;D |
| 09:51.28 | hrw | ~hail ar -x |
| 09:51.29 | ibot | ACTION bows down to ar -x and chants, "I'M NOT WORTHY!!" |
| 09:52.38 | erbo | Jay7: http://pastebin.com/mdf25005 |
| 09:53.05 | pb_ | heh, good to hear that opkg is keeping the tradition of ipkg brokenness alive. |
| 09:53.42 | pb_ | someone should totally write a decent package manager one day. |
| 09:53.49 | hrw | pb_: dpkg+apt? |
| 09:54.05 | pb_ | very funny |
| 09:54.37 | pb_ | when I say "write", c++ doesn't count |
| 09:55.34 | *** join/#oe leslie (n=leslie@116.228.58.74) |
| 09:55.34 | pb_ | plus, apt seems to rival JRE for memory usage :-} |
| 09:56.13 | pb_ | I think the ipkg concept was a pretty sound one, it's just that the implementation sucks rather more than would be ideal |
| 09:56.20 | hrw | indeed |
| 09:56.28 | hrw | opkg fixes some bugs but added new ones |
| 09:56.31 | hrw | -> off |
| 09:57.45 | *** join/#oe marex (n=marex@eduroam81.ms.mff.cuni.cz) |
| 09:58.24 | leslie | 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? |
| 09:58.28 | leslie | anybody can help me? |
| 10:02.04 | pb_ | leslie: probably in your local.conf, though I am a bit surprised that line is necessary |
| 10:03.41 | zecke | leslie: which example do you attempt to follow? |
| 10:04.49 | leslie | http://www.openembedded.info/usermanual.html#commonuse_prebuilt_toolchain, this link |
| 10:04.54 | leslie | I'm following |
| 10:06.30 | hrw | re |
| 10:07.45 | hrw | does someone has fbdev driver working with x.org (not kdrive) x11 server? |
| 10:07.56 | hrw | (EE) FBDEV(0): FBIOPUT_VSCREENINFO succeeded but modified mode |
| 10:07.56 | hrw | (EE) FBDEV(0): mode initialization failed |
| 10:08.52 | hrw | thats on one device. on second something brings and die in a moment after |
| 10:08.52 | *** join/#oe ptitjes (n=didier@93.2.7.156) |
| 10:09.46 | leslie | pb_: yes, I put it in the local.conf, and it seems work fine |
| 10:09.48 | leslie | thanks |
| 10:14.07 | hrw | did someone tried xserver 1.6x? |
| 10:14.11 | hrw | with OE |
| 10:23.19 | *** join/#oe mnabil (n=mnabil@196.202.97.147) |
| 10:24.41 | leslie | 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? |
| 10:25.16 | hrw | first heard |
| 10:25.28 | pb_ | leslie: sounds like you don't have a compiler installed on your build host |
| 10:25.30 | hrw | OE require host compiler too |
| 10:25.48 | hrw | leslie: 'aptitude install build-essential' on debian systems will help |
| 10:26.05 | leslie | pb_: out of oe, in bash, I type "gcc", it reports: gcc: no input files |
| 10:26.22 | pb_ | ah, hm. in that case I guess your $PATH must be getting messed up in oe somehow. |
| 10:26.25 | leslie | I do have gcc, g++ tools installed on my host |
| 10:26.35 | pb_ | if you do "which gcc", where does it say the compiler is installed? |
| 10:27.17 | leslie | with which gcc, reports: /usr/bin/gcc |
| 10:27.43 | pb_ | that should be fine. very strange. |
| 10:28.01 | leslie | my prebuilt toolchain has a ccache |
| 10:28.12 | pb_ | 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. |
| 10:28.20 | leslie | and all tools, like arm-linux-gcc , is a link to ccache |
| 10:28.54 | pb_ | oe isn't even trying to use the cross-compiler at this point. xxx-native packages are built with your regular host compiler. |
| 10:29.10 | pb_ | so, don't worry about your cross toolchain, that can't be the problem here. |
| 10:29.30 | leslie | export BUILD_CC="ccache gcc", this is a line in run.do_compile |
| 10:29.50 | leslie | I think it use the cross toolchain's ccache |
| 10:30.03 | pb_ | does it work if you change that to just "gcc"? |
| 10:30.13 | leslie | i'm trying :) |
| 10:30.37 | mckoan | bbl |
| 10:31.03 | leslie | it works |
| 10:31.15 | leslie | if I change it to "gcc" |
| 10:32.19 | pb_ | 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. |
| 10:32.26 | hrw | leslie: fedora you use? |
| 10:32.36 | leslie | opensuse |
| 10:32.38 | pb_ | 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. |
| 10:33.07 | leslie | en, thanks pb_ |
| 10:43.34 | *** join/#oe bbradley (n=bbradley@87-194-119-230.bethere.co.uk) |
| 10:49.43 | RP | Note that ccache gets upset if HOME isn't set... |
| 10:49.49 | RP | morning all btw |
| 10:50.25 | Crofton|work | any thoughts on why edevd-141 is not building for some? |
| 10:52.22 | ant_work | Crofton|work: udevd ? |
| 10:52.55 | Crofton|work | right |
| 10:53.06 | Crofton|work | slowly adding coffee here .... |
| 10:53.24 | DJWillis | 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. |
| 10:53.52 | ant_work | and seems kust libool/linking prob |
| 10:54.06 | ant_work | eh...and seems just libtool/linking prob |
| 10:57.10 | Crofton|work | lovely |
| 10:57.15 | Crofton|work | why only failing for some |
| 10:57.33 | ant_work | I dare to say for everybody building from scratch |
| 10:57.38 | Crofton|work | ok |
| 10:58.07 | DJWillis | ant_work: yep, seems to come in with totally clean builds. |
| 10:58.47 | ant_work | so probably koen had some 'cruft' header around which we lack |
| 10:59.20 | Crofton|work | or he didn't do a clean build |
| 10:59.37 | Crofton|work | are you both using multi threaed bb |
| 10:59.52 | ant_work | yes here |
| 11:00.35 | Crofton|work | I just turned that off and will try again |
| 11:00.51 | *** join/#oe pirho (i=pirho@gateway/gpg-tor/key-0x2CEEC9CB) |
| 11:04.38 | pb_ | it doesn't look like a header issue as such, more of a library problem. does your libc.so actually contain a ppoll symbol? |
| 11:05.22 | *** join/#oe hillct_ (n=hillct@cpe-069-134-049-165.nc.res.rr.com) |
| 11:05.55 | *** part/#oe mpoullet|home (n=mpoullet@77-22-121-59-dynip.superkabel.de) |
| 11:06.50 | leslie | 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 |
| 11:07.15 | ant_work | pb_: seems is there since glibc-2.4 |
| 11:07.21 | *** join/#oe sepultina (n=quassel@zux221-173-049.adsl.green.ch) |
| 11:07.29 | ant_work | but indeed...Crofton, pls check |
| 11:07.38 | pb_ | ant_work: have you actually inspected your libc.so to see if it is really there? |
| 11:08.08 | ant_work | no...I always discover the failures in the morning when I'm heading to odffice :/ |
| 11:08.37 | leslie | anybody knows what happening? |
| 11:08.42 | ant_work | and I can't ssh because during the day host is running Leopard OSX |
| 11:08.47 | ant_work | ../ |
| 11:09.00 | pb_ | leslie: check the config.log file to see what's up |
| 11:13.04 | leslie | I pasted the error here: http://pastebin.com/d7ed0ad5d, but does it have difference between do bitbake and do run.do_configure mannually? |
| 11:14.05 | pb_ | shouldn't do, unless there is some environment variable dependency. |
| 11:14.18 | pb_ | bitbake does have a (sometimes slightly unhelpful) habit of zapping the environment before it runs anything. |
| 11:15.58 | ant_work | leslie: the fatal error: C compiler cannot create executables...have you cwiped your tmpdir? |
| 11:17.11 | ant_work | I always see /cross is wrongly recreated after rebuild from packaged-staging |
| 11:17.44 | ant_work | <PROTECTED> |
| 11:18.22 | leslie | it seems dont have /cross folder in tmp |
| 11:20.37 | leslie | I think the problem is at the difference between do bitbake and do run.do_configure, but how to find it out... |
| 11:25.14 | pH5 | 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. |
| 11:25.37 | ant_work | pH5: apply Roman's patch |
| 11:25.57 | ant_work | [oe] [PATCH 1/2] qemu 0.10.3: port OE patches, make preferable version |
| 11:26.26 | Crofton|work | nm lib/libc.so.6 | grep ppoll |
| 11:26.27 | Jay7 | hm.. |
| 11:26.33 | Crofton|work | doesn't show anything? |
| 11:26.43 | Jay7 | bitbake udev is completed successfully |
| 11:27.07 | Crofton|work | Jay7, machine/distro? |
| 11:27.07 | Jay7 | with udev-141-r4 |
| 11:27.10 | ant_work | from scratch? |
| 11:27.17 | Jay7 | akita/angstrom |
| 11:27.19 | Jay7 | yep |
| 11:27.31 | ant_work | pure fun |
| 11:27.34 | Jay7 | I have build kexec-tools-static only before |
| 11:27.50 | Jay7 | so it will build gcc |
| 11:28.50 | Crofton|work | ok, I have ppol in libc.so.6 on x86 :) |
| 11:29.14 | Jay7 | 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 |
| 11:29.20 | Jay7 | this was build before |
| 11:31.42 | pH5 | ant_work: thanks, checking |
| 11:33.38 | ant_work | pH5: I overlooked the patch too, thinking was already pushed |
| 11:33.54 | ant_work | seems just fine |
| 11:34.25 | Jay7 | btw, should I vote for patches in .dev? :) |
| 11:34.28 | pb_ | fwiw, udev-141 does build fine for me |
| 11:34.38 | Crofton|work | what machine? |
| 11:34.41 | Jay7 | or only coredev should do that? |
| 11:34.49 | hrw | bye |
| 11:34.53 | pb_ | epia |
| 11:35.17 | Crofton|work | has a bad feeling glibc for armv7 is missing ppoll for some reason |
| 11:35.19 | pb_ | and minimal distro, though I doubt that makes much difference |
| 11:35.38 | *** join/#oe Gnutoo (n=gnutoo@host51-130-dynamic.54-79-r.retail.telecomitalia.it) |
| 11:35.44 | Crofton|work | minimal seems to be a copy of angstrom, with ugly section seperators .... |
| 11:36.12 | Jay7 | afk for ~1.5h |
| 11:36.29 | Crofton|work | I really wish it would become trukly minimal, or people would work more on mciro |
| 11:36.35 | Crofton|work | er micro |
| 11:36.50 | *** join/#oe __good_day_ (n=chatzill@122.169.48.97) |
| 11:37.00 | pb_ | there probably is a niche for minimal, though I think mickey is right that it should be renamed (back) to generic. |
| 11:37.13 | Crofton|work | I can't figure out what it is |
| 11:37.14 | pb_ | I suspect micro is a bit too micro for a lot of folks. |
| 11:37.48 | ant_work | Crofton|work: FWIW I'm building angstrom-dev |
| 11:38.03 | ant_work | like Jay7... |
| 11:38.56 | ant_work | Crofton|work: armv5te |
| 11:39.00 | Crofton|work | I wonder if the newer udev added the ppoll call |
| 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. |
| 11:39.23 | Crofton|work | I see it in x86, but not libc for beagle |
| 11:39.43 | DJWillis | Crofton|work: if it was broken on ARMv7 would it not have been broken for Koen from the get go? |
| 11:40.01 | Crofton|work | well, this is a mystery |
| 11:40.10 | ant_work | pb_: IMHO there are too many images and too many distros. Abundance is good...buth some lacks use/maintainance |
| 11:40.28 | pb_ | __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. |
| 11:40.54 | ant_work | pb_: creating a custom-image is trivial |
| 11:41.13 | __good_day_ | pb_: okey I got your point Thank you. |
| 11:41.45 | Crofton|work | __good_day_, sometimes we get a little overwhelmed by questions from end users :) |
| 11:42.52 | pb_ | ant_work: yeah, there are indeed quite a lot of distros that seem to be maintained only patchily if at all. |
| 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? |
| 11:43.57 | ant_work | pb_: I'm just scared by the matrix distro/image/machine ... is huge |
| 11:43.57 | __good_day_ | It has problem with "struct _reent r" |
| 11:44.03 | pb_ | __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. |
| 11:44.56 | pb_ | 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. |
| 11:45.43 | Crofton|work | pb_, in reality images should be orthogonal to distro |
| 11:45.50 | Crofton|work | micro-image builds fine in Angstrom |
| 11:45.50 | ant_work | pb_: how to minimize then? some images could have setting usually found in distro |
| 11:46.05 | __good_day_ | I am sorry, I use building oe instead of building environment |
| 11:46.12 | ant_work | pb_: I'm thinking to router/nas |
| 11:46.19 | pb_ | 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. |
| 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. |
| 11:48.14 | Crofton|work | __good_day_, you are using a toolchain built with OE to compile something else? |
| 11:48.16 | pb_ | 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. |
| 11:48.22 | RP | The situation is miles better than it used to be :) |
| 11:48.27 | ant_work | can we think about $DISTRO_SUPPORTED_IMAGES? |
| 11:48.49 | Crofton|work | I would argue that distro specific images should not appear in the OE metadata |
| 11:48.55 | Crofton|work | not I said argue |
| 11:49.02 | pb_ | 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. |
| 11:49.14 | RP | Crofton|work: Where should they go? |
| 11:49.16 | ant_work | yep..specular |
| 11:49.22 | Crofton|work | up to the distro :) |
| 11:49.30 | pb_ | 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. |
| 11:49.37 | Crofton|work | has been known to argue just for the sake of arguing |
| 11:49.48 | pb_ | there's no point having DISTRO.conf if you lack the image files that would allow you to build images. |
| 11:50.02 | Crofton|work | use the generic ones |
| 11:50.09 | __good_day_ | crofton|work: yes, using OE to compile demo application supplied with the kit, which is made for gnu linux. |
| 11:50.24 | RP | Actually, I love the idea of creating multiple meta-* directories like poky |
| 11:50.49 | Crofton|work | __good_day_, I think the problem will lie in how you are compiling your app |
| 11:50.51 | pb_ | that said, moving all the distro-specific bits into separate repositories isn't a completely silly idea. |
| 11:50.51 | RP | Then the distro specific bits can all live together (conf and recipes) |
| 11:51.05 | Crofton|work | is multi-tasking to failure |
| 11:51.07 | RP | pb_: No need for a separate repo, just a separate directory |
| 11:51.20 | Crofton|work | segfaults |
| 11:51.24 | ant_work | pb_: I'd let distro-maintainers decide the images they 'support' and update frequently distro.conf |
| 11:51.38 | ant_work | listing the exact images |
| 11:51.44 | ant_work | they tested |
| 11:52.12 | ant_work | you would just need an oefatal |
| 11:52.22 | ant_work | to warn |
| 11:52.35 | Crofton|work | ok |
| 11:52.51 | Crofton|work | can someone with armv5 libs about grep libc for ppol? |
| 11:52.57 | Crofton|work | er |
| 11:52.59 | Crofton|work | ppoll |
| 11:53.09 | ant_work | Crofton|work: Jay7 will do for us in a while |
| 11:54.12 | pb_ | RP: yah, that'd work too. |
| 11:54.48 | pH5 | Crofton|work: my armv5te build (magician, hx4700) doesn't have ppoll either |
| 11:54.57 | Crofton|work | hmmm |
| 11:55.32 | Crofton|work | http://sourceware.org/ml/libc-ports/2007-09/msg00005.html |
| 11:56.25 | *** join/#oe __good_day__ (n=chatzill@122.169.48.97) |
| 11:57.05 | pb_ | Crofton|work: that shouldn't matter, you should still get the generic ppoll stub even then. |
| 11:57.29 | pb_ | plus I think the syscalls have actually been added for arm since drow posted that note |
| 11:58.10 | Crofton|work | well the question is why aren't they in the armv7 libc .... |
| 11:58.23 | pb_ | indeed, but I don't think that email is the answer. |
| 11:58.55 | Crofton|work | yeah, but google said it is :) |
| 11:59.04 | pb_ | heh |
| 11:59.11 | pb_ | what do you actually have in your ppoll.o? |
| 11:59.34 | pb_ | or ppoll.os rather |
| 11:59.47 | Crofton|work | bother |
| 11:59.57 | Crofton|work | can't find that file :) |
| 12:00.13 | pb_ | it should be in io/ |
| 12:00.25 | Crofton|work | [balister@localhost glibc-2.6.1]$ find . -name "ppoll*" |
| 12:00.25 | Crofton|work | ./sysdeps/unix/sysv/linux/ppoll.c |
| 12:00.25 | Crofton|work | ./sysdeps/mach/hurd/ppoll.c |
| 12:00.25 | Crofton|work | ./io/ppoll.c |
| 12:00.25 | pb_ | just after posix_fallocate.os, probably |
| 12:00.40 | pb_ | Crofton|work: you're looking in the source directory, not the build directory |
| 12:00.43 | pb_ | cd ../build-* |
| 12:01.13 | Crofton|work | I have ppoll.o |
| 12:01.21 | Crofton|work | is learning too much |
| 12:01.27 | pb_ | but no ppoll.os? |
| 12:01.30 | Crofton|work | that to |
| 12:01.35 | Crofton|work | I was being brief |
| 12:01.40 | pb_ | okay |
| 12:01.53 | pb_ | if you objdump -dr ppoll.os, what do you see? |
| 12:02.34 | Crofton|work | code |
| 12:02.38 | pb_ | jolly good |
| 12:02.55 | pb_ | does it start with a line that says something like "0000000 <ppoll>:"? |
| 12:03.03 | Crofton|work | been a while since I heard someone say that |
| 12:03.15 | Crofton|work | exactly |
| 12:03.35 | pb_ | okay, so the function is indeed being compiled |
| 12:03.54 | pH5 | hm. my ppoll.os only has the .comment and .ARM.attributes sections. objdump -d is completely empty. |
| 12:03.54 | pb_ | now look in ../libc_pic.os, see if you can find it defined there |
| 12:04.23 | pb_ | pH5: oh dear, sucks to be you. |
| 12:04.28 | pH5 | :) |
| 12:04.29 | pb_ | sounds like there might be two different bugs at work in that case |
| 12:04.55 | pb_ | pH5: the way to attack that one is to inspect log.do_compile and find out what command generated ppoll.os |
| 12:05.12 | pb_ | then inspect the input files and figure out why they are producing empty output. |
| 12:05.17 | Crofton|work | <PROTECTED> |
| 12:05.17 | Crofton|work | 000b09e8 T ppoll |
| 12:05.30 | leslie | 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? |
| 12:05.44 | ant_work | sits on coutch looking 'PB's strikes back' Part1 |
| 12:05.59 | Crofton|work | hmmm [balister@localhost build-arm-angstrom-linux-gnueabi]$ nm libc_pic.os | grep ppoll |
| 12:06.00 | Crofton|work | 0009c1d8 T ppoll |
| 12:06.09 | pb_ | leslie: it's correct, but not sufficient. you need to add virtual/${TARGET_PREFIX}gcc-initial as well. |
| 12:06.18 | *** join/#oe fraxinath (n=quassel@p54AA77D3.dip.t-dialin.net) |
| 12:06.23 | *** join/#oe Laibsch (n=Laibsch@p5B3B3E33.dip.t-dialin.net) |
| 12:07.07 | Crofton|work | why doesn't this make it to staging |
| 12:07.25 | leslie | pb_: should I replace TARGET_PREFIX to arm-linux- ? I havent set TARGET_PREFIX anywhere. |
| 12:07.33 | Crofton|work | bbiab |
| 12:07.43 | pb_ | leslie: no, that's okay, it's set by bitbake.conf |
| 12:08.35 | leslie | pb_: thanks :) |
| 12:09.57 | leslie | 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 |
| 12:12.52 | *** join/#oe pH5_ (n=ph5@e178192176.adsl.alicedsl.de) |
| 12:14.12 | pb_ | 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. |
| 12:17.57 | ant_work | pb_: just a crazy idea...I see there are headers staged only with kernels >2.6.27 |
| 12:18.14 | ant_work | in kernel.bbclass |
| 12:18.45 | ant_work | perhaps name mismatch? I'm building 2.6.26 |
| 12:20.47 | *** join/#oe waite (n=bwaite@206.83.81.178.ptr.us.xo.net) |
| 12:24.51 | pb_ | 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. |
| 12:25.19 | pb_ | 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. |
| 12:25.46 | ant_work | I see...thxl |
| 12:27.14 | XorA | this ppoll problem seems to be spreading |
| 12:27.21 | *** join/#oe __good_day_ (n=chatzill@122.169.48.97) |
| 12:30.30 | CIA-35 | 03Otavio Salvador <otavio@ossystems.com.br> 07org.openembedded.dev * rff34921286 10openembedded.git/ (5 files in 3 dirs): |
| 12:30.30 | CIA-35 | acpid: add 1.0.8 (with netlink support) |
| 12:30.30 | CIA-35 | Signed-off-by: Otavio Salvador <otavio@ossystems.com.br> |
| 12:30.31 | CIA-35 | 03Otavio Salvador <otavio@ossystems.com.br> 07org.openembedded.dev * r88e86fff96 10openembedded.git/conf/machine/ (4 files in 2 dirs): |
| 12:30.32 | CIA-35 | machine/geode[gl]x: use more optimization while compiling |
| 12:30.35 | CIA-35 | Since the code is now the same for Geode GX and Geode LX we also |
| 12:30.37 | CIA-35 | merged the tunning files in a single tune-geode.inc, making it easy to |
| 12:30.39 | CIA-35 | improve from now on. |
| 12:30.41 | CIA-35 | Signed-off-by: Otavio Salvador <otavio@ossystems.com.br> |
| 12:30.43 | CIA-35 | 03Otavio Salvador <otavio@ossystems.com.br> 07org.openembedded.dev * r85a14b8765 10openembedded.git/conf/checksums.ini: |
| 12:30.46 | CIA-35 | checksums.ini: add flash-plugin |
| 12:30.48 | CIA-35 | Signed-off-by: Otavio Salvador <otavio@ossystems.com.br> |
| 12:30.50 | CIA-35 | 03Otavio Salvador <otavio@ossystems.com.br> 07org.openembedded.dev * r1232133c9c 10openembedded.git/ (conf/checksums.ini recipes/gtk-engines/gtk-engines_2.18.1.bb): |
| 12:30.53 | CIA-35 | gtk-engines: add 2.18.1 |
| 12:30.55 | CIA-35 | Signed-off-by: Otavio Salvador <otavio@ossystems.com.br> |
| 12:30.57 | CIA-35 | 03Otavio Salvador <otavio@ossystems.com.br> 07org.openembedded.dev * rf5c3b15422 10openembedded.git/conf/checksums.ini: |
| 12:31.00 | CIA-35 | checksums.ini: add sun-jdk |
| 12:31.10 | CIA-35 | Signed-off-by: Otavio Salvador <otavio@ossystems.com.br> |
| 12:31.12 | CIA-35 | 03Otavio Salvador <otavio@ossystems.com.br> 07org.openembedded.dev * red4f8aa703 10openembedded.git/conf/checksums.ini: |
| 12:31.15 | CIA-35 | checksums.ini: firefox-l10n-pt-br |
| 12:31.17 | CIA-35 | Signed-off-by: Otavio Salvador <otavio@ossystems.com.br> |
| 12:31.19 | CIA-35 | 03Otavio Salvador <otavio@ossystems.com.br> 07org.openembedded.dev * r0fbb2e057c 10openembedded.git/conf/licenses.conf: |
| 12:31.22 | CIA-35 | conf/licenses.conf: add CUPS license |
| 12:31.24 | CIA-35 | Signed-off-by: Otavio Salvador <otavio@ossystems.com.br> |
| 12:31.26 | CIA-35 | 03Otavio Salvador <otavio@ossystems.com.br> 07org.openembedded.dev * r4df5a84ef9 10openembedded.git/ (conf/checksums.ini recipes/python/python-pycups_1.9.45.bb): |
| 12:31.29 | CIA-35 | python-pycups: add |
| 12:31.31 | CIA-35 | Signed-off-by: Otavio Salvador <otavio@ossystems.com.br> |
| 12:31.33 | CIA-35 | 03Otavio Salvador <otavio@ossystems.com.br> 07org.openembedded.dev * rffb4e8d7ac 10openembedded.git/ (conf/checksums.ini recipes/hal/hal-cups-utils_0.6.19.bb): |
| 12:31.44 | CIA-35 | hal-cups-utils: add |
| 12:31.46 | CIA-35 | Signed-off-by: Otavio Salvador <otavio@ossystems.com.br> |
| 12:31.48 | CIA-35 | 03Otavio Salvador <otavio@ossystems.com.br> 07org.openembedded.dev * r57c5f8879e 10openembedded.git/ (2 files in 2 dirs): |
| 12:31.51 | CIA-35 | system-config-printer: add to provide python-cupshelpers to hal-cups-utils |
| 12:31.53 | CIA-35 | Signed-off-by: Otavio Salvador <otavio@ossystems.com.br> |
| 12:31.57 | CIA-35 | 03Otavio Salvador <otavio@ossystems.com.br> 07org.openembedded.dev * rf56580bbd4 10openembedded.git/ (4 files in 3 dirs): |
| 12:32.00 | CIA-35 | fixes wrong license value usage for GPLv2 |
| 12:32.02 | CIA-35 | Signed-off-by: Otavio Salvador <otavio@ossystems.com.br> |
| 12:32.04 | CIA-35 | 03Otavio Salvador <otavio@ossystems.com.br> 07org.openembedded.dev * rd24c53100d 10openembedded.git/ (6 files in 3 dirs): |
| 12:32.07 | CIA-35 | mtools: update to 4.0.10 since 3.9.11 was not available anymore |
| 12:32.09 | CIA-35 | (70 lines omitted) |
| 12:34.39 | Crofton|work | koen suggested rebuilding glibc |
| 12:34.47 | Crofton|work | which won't rebuild for me |
| 12:35.02 | *** join/#oe vo5 (n=vo@189.121.183.147) |
| 12:35.04 | Crofton|work | on a really weird error |
| 12:35.18 | XorA | Crofton|work: you need to rebuild glibc-initial first |
| 12:35.53 | otavio | hrw|gone: please take a look and update your geode patches |
| 12:35.55 | Crofton|work | I find this stuff extremely mysterious .... |
| 12:36.53 | XorA | Crofton|work: as I understand it glibc replaces some stuff glibc-initial put there, but glibc needs the versions from glibc-initial |
| 12:37.00 | Crofton|work | btw glibc-initial has a base_set_files_path warning |
| 12:37.19 | Crofton|work | no wonder we drink so much |
| 12:37.27 | XorA | will drink tonight |
| 12:37.47 | Crofton|work | amen |
| 12:38.05 | cdbot2 | * * OE Bug 5086 has been RESOLVED (INVALID) by <Laibsch> |
| 12:38.07 | cdbot2 | * * libpcap-1.0.0 failed to install |
| 12:38.09 | cdbot2 | * * http://bugs.openembedded.net/show_bug.cgi?id=5086 |
| 12:39.30 | Crofton|work | XorA, that worked |
| 12:39.36 | Crofton|work | thanks |
| 12:39.41 | Crofton|work | I was about to start drinking |
| 12:40.09 | XorA | Crofton|work: we should work out a way to make OE always force that condition |
| 12:41.32 | pb_ | even better, we should just fix the glibc recipe to not require those bogus bits. |
| 12:41.32 | *** join/#oe __good_day__ (n=chatzill@122.169.48.97) |
| 12:42.32 | CIA-35 | 03Elena Grandi <elena.valhalla@gmail.com> 07org.openembedded.dev * reca20211da 10openembedded.git/conf/checksums.ini: |
| 12:42.32 | CIA-35 | checksums.ini: added entry for gtksourceview2_2.6.0 |
| 12:42.32 | CIA-35 | Signed-off-by: Elena Grandi <elena.valhalla@gmail.com> |
| 12:42.32 | CIA-35 | Signed-off-by: Otavio Salvador <otavio@ossystems.com.br> |
| 12:42.34 | CIA-35 | 03Elena Grandi <elena.valhalla@gmail.com> 07org.openembedded.dev * r5888b8ce39 10openembedded.git/recipes/gtksourceview/gtksourceview2_2.6.0.bb: |
| 12:42.37 | CIA-35 | gtksourceview2 2.6.0: new recipe for the current stable version. |
| 12:42.39 | CIA-35 | GtkSourceView is a portable C library that extends the standard GTK+ |
| 12:42.40 | pb_ | that said, I'd have thought it would be a non-issue if you were using packaged staging. |
| 12:42.41 | CIA-35 | framework for multiline text editing. |
| 12:42.43 | CIA-35 | Signed-off-by: Elena Grandi <elena.valhalla@gmail.com> |
| 12:42.45 | CIA-35 | Signed-off-by: Otavio Salvador <otavio@ossystems.com.br> |
| 12:43.32 | otavio | well; let me back to work :-D |
| 12:46.31 | *** join/#oe vivijim (n=vivijim@unaffiliated/vivijim) |
| 13:04.00 | CIA-35 | 03Koen Kooi <koen@openembedded.org> 07org.openembedded.dev * r18c5ea8f84 10openembedded.git/recipes/udev/udev_141.bb: udev 141: fix staging |
| 13:04.00 | CIA-35 | 03Koen Kooi <koen@openembedded.org> 07org.openembedded.dev * rccab93e06e 10openembedded.git/: Merge branch 'org.openembedded.dev' of git@git.openembedded.org:openembedded into org.openembedded.dev |
| 13:04.01 | CIA-35 | 03Koen Kooi <koen@openembedded.org> 07org.openembedded.dev * rd543c80be6 10openembedded.git/ (5 files in 3 dirs): devicemapper: fix QA problems, add 1.02.28 |
| 13:07.06 | *** join/#oe drw_ (n=drw@cpe-76-187-64-213.tx.res.rr.com) |
| 13:07.19 | ant_work | Crofton|work: give alook at cgit (org/net) |
| 13:07.53 | Crofton|work | .org should work |
| 13:08.07 | ant_work | udev still not listed |
| 13:09.59 | Crofton|work | I want to say cgit does not update dynamically, but I do not know what i am talking about :) |
| 13:11.47 | ant_work | http://cgit.openembedded.org/cgit.cgi/openembedded/log/recipes/udev/udev_141.bb |
| 13:11.52 | ant_work | is there... |
| 13:15.15 | CIA-35 | 03Roman I Khimov <khimov@altell.ru> 07org.openembedded.dev * r247515aec9 10openembedded.git/recipes/qemu/ (15 files in 2 dirs): |
| 13:15.15 | CIA-35 | qemu 0.10.3: port OE patches, make preferable version |
| 13:15.15 | CIA-35 | Fixes binary locale generation broken by |
| 13:15.15 | CIA-35 | 6065fa491c009118ae282ae933215649cccfcd24. |
| 13:15.15 | CIA-35 | Tested to work on ARM OABI (simpad), ARM EABI (qemuarm), PowerPC (efika) |
| 13:15.18 | pb_ | pH5: fwiw, I just ran an armv5te build of glibc and I do have the right bits in ppoll.os |
| 13:15.19 | CIA-35 | and i686 (x86-prescott). |
| 13:15.21 | CIA-35 | Acked-by: Philipp Zabel <philipp.zabel@gmail.com> |
| 13:15.31 | pb_ | so whatever problem is afflicting you does seem to be some gypsy curse that's specific to your environment |
| 13:16.20 | ant_work | pb_: you were rebuilding from scratch? |
| 13:16.26 | pb_ | yeah |
| 13:16.36 | ant_work | bb_multithread ? |
| 13:16.43 | pb_ | no |
| 13:16.53 | ant_work | gotcha 1) |
| 13:17.08 | ant_work | make -jx ? |
| 13:17.19 | pb_ | not sure, let me have a look |
| 13:17.30 | pb_ | I usually use -j4 but I don't know if I remembered to configure that for this particular build |
| 13:17.41 | pb_ | no, it's not using -j |
| 13:17.49 | DJWillis | ant_work: just trying to rebuild glibc and glic-initial to see if that helps. -j3 |
| 13:18.20 | pH5 | tries a single threaded build |
| 13:18.22 | ant_work | pb_: diff # 2) |
| 13:18.54 | pb_ | pH5: this was for MACHINE=h3900 though I don't think it ought to make much difference |
| 13:19.12 | pH5 | hx4700. that's even a very similar board. |
| 13:19.14 | ant_work | I have 2 threads and make -j3 fwiw |
| 13:19.23 | ant_work | for c7x0 (armv5te) |
| 13:19.27 | pH5 | I used 4 threads and -j4 before. |
| 13:19.30 | ant_work | and failed 8 hours ago |
| 13:20.42 | ant_work | (from scratch, I repeat) |
| 13:21.06 | cdbot2 | * * OE Bug 5086 has been UNCONFIRMED by kevyn.alexandre.pare(AT)gmail.com |
| 13:21.08 | cdbot2 | * * libpcap-1.0.0 failed to install |
| 13:21.10 | cdbot2 | * * http://bugs.openembedded.net/show_bug.cgi?id=5086 |
| 13:21.57 | pb_ | I'd be surprised if either -jX or bb threads made a difference to this, though I guess you never know. |
| 13:22.31 | ant_work | some disable PARALLEL_MAKE |
| 13:23.20 | Crofton|work | not helping |
| 13:24.10 | ant_work | :/ |
| 13:25.09 | *** join/#oe ArteK (n=Artur@81.15.241.96) |
| 13:25.46 | pb_ | if removing -j (and/or BB_NUMBER_THREADS) makes it go away then let me know and I'll investigate further. |
| 13:26.02 | pb_ | otherwise, I think this just needs debugging by somebody who can actually reproduce the problem. |
| 13:27.40 | *** join/#oe zerum (n=quassel@187.37.50.192) |
| 13:27.43 | *** join/#oe abner (n=birunko@189.70.76.86) |
| 13:28.15 | *** join/#oe jimsheldon (n=jim@c-98-216-198-0.hsd1.nh.comcast.net) |
| 13:28.18 | *** join/#oe waite (n=bwaite@206.83.81.178.ptr.us.xo.net) |
| 13:30.14 | ant_work | pb_: i'l just keep my /tmp for analysys |
| 13:30.26 | *** join/#oe zerum_ (n=quassel@187.37.59.58) |
| 13:31.27 | *** join/#oe aloisiojr (n=aloisio@200.184.118.130) |
| 13:34.28 | pb_ | righto |
| 13:35.30 | ant_work | pb_ from tinderbox I can see I built glibc-initial/glibc at 02.45 and udev at 03.20 |
| 13:35.47 | ant_work | so all should have been staged |
| 13:35.55 | ant_work | if it were glibc |
| 13:36.23 | *** join/#oe brolin (n=brolin@nat50.udea.edu.co) |
| 13:36.38 | ant_work | urgh... s/were/was/ :/ |
| 13:37.12 | ant_work | (wenn es ...wäre) |
| 13:37.23 | ant_work | short-circuit |
| 13:39.05 | cdbot2 | * * OE Bug 637 has been RESOLVED (WORKSFORME) by <Laibsch> |
| 13:39.07 | cdbot2 | * * Different gcc cross output dependent on host ARCH ia32/amd64 |
| 13:39.09 | cdbot2 | * * http://bugs.openembedded.net/show_bug.cgi?id=637 |
| 13:43.31 | pb_ | ant_work: heh. fwiw, "if it were glibc" is perfectly valid english. |
| 13:45.05 | cdbot2 | * * OE Bug 1697 has been RESOLVED (WORKSFORME) by <Laibsch> |
| 13:45.07 | cdbot2 | * * glibc-intermediate 2.4 fails to build on self-hosted Angstrom due to rpcgen change |
| 13:45.09 | cdbot2 | * * http://bugs.openembedded.net/show_bug.cgi?id=1697 |
| 13:45.42 | ant_work | pb_: if it would have been glibc... |
| 13:46.51 | *** join/#oe zerum (n=quassel@187.37.59.58) |
| 13:47.37 | Crofton | ok |
| 13:47.46 | DJWillis | 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 ;-) |
| 13:50.08 | *** join/#oe dth (n=dth@p4FDEC902.dip.t-dialin.net) |
| 13:52.37 | Crofton | hmm |
| 13:52.59 | Crofton | I think I was on the wrong machine earlier when I said there was code in ppoll.o |
| 13:53.06 | cdbot2 | * * OE Bug 5086 has been RESOLVED (FIXED) by <Laibsch> |
| 13:53.08 | cdbot2 | * * libpcap-1.0.0 failed to install |
| 13:53.10 | cdbot2 | * * http://bugs.openembedded.net/show_bug.cgi?id=5086 |
| 13:54.16 | Crofton | this makes loads more sense |
| 13:54.35 | pb_ | ant_work: I would have expected you to embrace the subjunctive :-) |
| 13:55.35 | ant_work | pb_: mid 80' I was in 'Edinborrow' and one year later in Oxford for a month... |
| 13:55.50 | ant_work | in college |
| 13:56.02 | pb_ | ah, very good |
| 13:56.07 | ant_work | my best remembering: the 'pocket lunch' |
| 13:56.21 | ant_work | translated to 'launch' -> trow |
| 13:57.08 | ant_work | iirc the Castle in Ed was damaged by fire |
| 13:57.16 | ant_work | there was the college |
| 13:57.25 | ant_work | upon that hill |
| 13:58.13 | ant_work | I bought there my first PSION *original* tapes |
| 13:58.21 | Laibsch | pb_: you successfully compiled snes9x in 2008? |
| 13:58.39 | Laibsch | !oebug 1196 |
| 13:58.41 | pb_ | 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. |
| 13:58.41 | cdbot2 | * * Bug 1196, Status: CONFIRMED, Created: 2006-07-25 08:50 |
| 13:58.41 | cdbot2 | * * parkr31(AT)hotmail.com: "bitbake snes9x" complains about missing -lqte |
| 13:58.42 | cdbot2 | * * http://bugs.openembedded.net/show_bug.cgi?id=1196 |
| 13:58.48 | pb_ | maybe the castle was on fire before that though :-} |
| 13:59.05 | pb_ | Laibsch: not for qte, but I built it for x |
| 13:59.07 | Laibsch | I was inclined to move it to nonworking |
| 13:59.14 | ant_work | pb_: I was there in '85 |
| 13:59.34 | Laibsch | pb_: how would that matter? "bitbake snes9x" fails for me |
| 13:59.46 | pb_ | Laibsch: you've probably somehow gotten the SDL Library of Death selected. |
| 13:59.54 | Crofton | pb_, why wouldn't I see nay code in ppoll.o? |
| 13:59.57 | Laibsch | http://tinderbox.openembedded.net/builds/153265/ |
| 14:00.14 | ant_work | pb_: lol |
| 14:00.30 | pb_ | Laibsch: this is what we were talking about yesterday: sdl, despite its cross-platform credentials, is sadly incompatible between qte and everything else. |
| 14:00.35 | Laibsch | I remember |
| 14:00.43 | Laibsch | But I'm not convinced it is the case here |
| 14:00.52 | pb_ | okay, I'll have a look |
| 14:00.54 | Laibsch | I'm looking into it |
| 14:01.26 | *** join/#oe xanalogica (n=xanalogi@adsl-68-95-128-31.dsl.rcsntx.swbell.net) |
| 14:01.37 | pb_ | righto. let me know what you find out. |
| 14:01.56 | pb_ | it certainly used to work for me in a non-qte system |
| 14:02.38 | pb_ | funnily enough I was thinking about exhuming my mythtv installation yesterday so I might be wanting to build it again soon :-} |
| 14:02.45 | Laibsch | I did "bitbake snes9x" and grepped the depends files for qpe and qte |
| 14:02.46 | Laibsch | nothing |
| 14:02.55 | Laibsch | http://tinderbox.openembedded.net/public/logs/5380240.txt |
| 14:02.58 | Laibsch | same thing |
| 14:03.05 | Laibsch | Looks unrelated to me |
| 14:03.30 | pb_ | yeah, that looks unrelated |
| 14:03.36 | pb_ | at a guess, your g++ is too new. what version do you have? |
| 14:04.31 | pb_ | should be fairly easy to patch though, it almost certainly just needs 'extern "C"...' adding in a few strategic places |
| 14:05.37 | xanalogica | 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) |
| 14:06.47 | CIA-35 | 03Koen Kooi <koen@openembedded.org> 07org.openembedded.dev * rc303984523 10openembedded.git/recipes/devicekit/devicekit-disks_004.bb: devicekit-disks: add 004 |
| 14:06.48 | CIA-35 | 03Koen Kooi <koen@openembedded.org> 07org.openembedded.dev * rd18dc6fd33 10openembedded.git/: Merge branch 'org.openembedded.dev' of git@git.openembedded.org:openembedded into org.openembedded.dev |
| 14:06.48 | CIA-35 | 03Koen Kooi <koen@openembedded.org> 07org.openembedded.dev * r288eb56a5f 10openembedded.git/recipes/udev/udev_141.bb: udev 141: symlink /usr/lib/udev/rules.d to /etc/udev/rules.d |
| 14:06.49 | CIA-35 | 03Koen Kooi <koen@openembedded.org> 07org.openembedded.dev * rd5edeac207 10openembedded.git/recipes/devicekit/libatasmart_0.13.bb: libatasmart: add 0.13 |
| 14:07.36 | ant_work | Crofton|work: I could find this recent bits https://bugs.launchpad.net/ubuntu/+source/linux/+bug/319729 |
| 14:07.46 | ant_work | udev / ppoll |
| 14:08.30 | pb_ | Crofton: dunno, see what I said to ph5 earlier. you'd have to start with log.do_compile and debug it from there. |
| 14:09.17 | ant_work | about disabling fallback code...pb_ ? |
| 14:10.16 | Crofton | what is annoying is something changed because older builds have it |
| 14:11.56 | pb_ | ant_work: yeah, I think that complaint is probably correct. |
| 14:12.03 | *** join/#oe aloisiojr1 (n=aloisio@200.184.118.130) |
| 14:12.21 | *** join/#oe Sup3rkiddo (n=sudharsh@unaffiliated/sudharsh) |
| 14:12.56 | pb_ | are those syscalls really still not implemented for arm? that's pretty lame. |
| 14:13.35 | *** join/#oe BenLauDC (n=benlau@221.125.8.105) |
| 14:15.54 | *** join/#oe marex (n=marex@vasut.kolej.mff.cuni.cz) |
| 14:19.44 | *** join/#oe aloisiojr (n=aloisio@200.184.118.130) |
| 14:20.16 | *** join/#oe aloisiojr (n=aloisio@200.184.118.130) |
| 14:21.20 | pb_ | drat, gcc-cross-kernel-3.3.4 doesn't compile anymore |
| 14:21.21 | pb_ | stabs it |
| 14:26.37 | pH5 | single threaded build doesn't help me either. |
| 14:28.10 | pH5 | 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. |
| 14:28.32 | *** join/#oe jconnoll1 (n=jconnoll@firebug.buglabs.net) |
| 14:28.32 | pH5 | which stops glibc from using its own __generic_ppoll instead. |
| 14:34.10 | pb_ | yeah, that sounds quite likely. |
| 14:34.32 | pb_ | based on the report in the url that ant posted a moment ago, udev won't work correctly with the generic ppoll emulation anyway. |
| 14:34.55 | pb_ | 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. |
| 14:35.32 | pb_ | 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. |
| 14:36.49 | pb_ | Laibsch: doh, now I get CROSS_COMPILE BADNESS in snes9x |
| 14:37.07 | pb_ | groan! |
| 14:37.14 | Laibsch | Yes, that is bug 1196, I think |
| 14:37.59 | pb_ | oh, right. |
| 14:38.09 | pb_ | I put too much faith in the summary, I thought #1196 was something about -lqte |
| 14:39.05 | pb_ | 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. |
| 14:40.29 | zecke | pb_: hehe, I wonder why no one renamed the patch... *damn* |
| 14:41.49 | pb_ | zecke: i guess we like to be reminded of you. same as the "mickey_is_cool" thing that we are all so fond of. |
| 14:42.20 | zecke | lol |
| 14:42.25 | zecke | :( |
| 14:43.03 | pb_ | Laibsch: yah, here's the culprit: |
| 14:43.09 | pb_ | dnl NOTE: PATH_X doesn't set up the include path if it's in the system path |
| 14:43.09 | pb_ | if test x$x_includes != x ; then |
| 14:43.09 | pb_ | <PROTECTED> |
| 14:43.09 | pb_ | fi |
| 14:43.42 | Laibsch | can you fix it? |
| 14:43.56 | pb_ | yeah, it just needs those three lines deleting |
| 14:44.13 | Laibsch | cool |
| 14:44.16 | pb_ | I'll make a patch |
| 14:47.27 | pb_ | oh, what? snes9x doesn't run autoconf?! |
| 14:47.28 | pb_ | stabs it |
| 14:47.33 | pb_ | oh well, I'll just patch configure directly |
| 14:50.07 | cdbot2 | * * OE Bug 2311 has been RESOLVED (REMIND) by <Laibsch> |
| 14:50.09 | cdbot2 | * * Openalchemy toolkit in Openembedded |
| 14:50.11 | cdbot2 | * * http://bugs.openembedded.net/show_bug.cgi?id=2311 |
| 14:51.10 | Laibsch | pb_: Is there a newer snes9x anywhere? |
| 14:51.23 | pb_ | that's a good question, I have no idea |
| 14:57.05 | *** join/#oe brolin (n=brolin@nat50.udea.edu.co) |
| 14:58.08 | CIA-35 | 03Phil Blundell <philb@gnu.org> 07org.openembedded.dev * rc16813c576 10openembedded.git/recipes/snes9x/ (3 files in 2 dirs): snes9x: fix sundry compilation problems |
| 14:58.18 | CIA-35 | 03Phil Blundell <philb@gnu.org> 07org.openembedded.dev * rfc734ad620 10openembedded.git/: Merge branch 'org.openembedded.dev' of git@new.openembedded.org:openembedded into org.openembedded.dev |
| 14:58.34 | pb_ | Laibsch: et voila |
| 14:58.47 | Laibsch | great |
| 14:59.06 | cdbot2 | * * OE Bug 1577 has been RESOLVED (LATER) by <Laibsch> |
| 14:59.08 | cdbot2 | * * Minisip-video depend on ffmpeg in nonexisting version |
| 14:59.11 | cdbot2 | * * http://bugs.openembedded.net/show_bug.cgi?id=1577 |
| 14:59.55 | Laibsch | pb_: looks like there is http://www.snes9x.com/downloads.php |
| 15:00.42 | pb_ | ah yes, seems 1.43 was released |
| 15:00.47 | pb_ | I guess we should update to that at some point |
| 15:01.47 | pb_ | still, 1.43-wip1 works well enough for me to play super mario kart, I am inclined to leave it alone :-) |
| 15:02.01 | CIA-35 | 03Rolf Leggewie <oe-devel@rolf.leggewie.biz> 07org.openembedded.dev * re687e226e1 10openembedded.git/recipes/minisip/minisip-video_svn.bb: minisip-video: move to nonworking. (Closes: #1577) |
| 15:02.47 | Crofton | Laibsch, be careful about moving stuff to nonworking, it will make the history harder to follow |
| 15:03.02 | Crofton | and potentially lead to it making it more difficult to fix stuff |
| 15:03.03 | Laibsch | where else do you suggest to move it? |
| 15:03.08 | Crofton | leave it be |
| 15:03.14 | *** join/#oe flo_lap (n=fuchs@f049038042.adsl.alicedsl.de) |
| 15:03.20 | Laibsch | I want to "bitbake world" |
| 15:03.45 | Crofton | well moving the recipes tht do not work for you is not they way to do that |
| 15:03.45 | Laibsch | And I think there is value in getting stuff out of sight that has been nonworking for 3-4 years |
| 15:03.58 | Laibsch | 3-4 years |
| 15:03.59 | Crofton | I do not agree |
| 15:04.39 | Crofton | I do not see loads of people complain bitbake world does not work |
| 15:04.48 | Laibsch | because nobody tries |
| 15:04.56 | Laibsch | cause it immediately fails |
| 15:05.12 | Crofton | maybe we should remove the world option |
| 15:05.58 | *** join/#oe dth (n=dth@p4FDEC902.dip.t-dialin.net) |
| 15:07.00 | Laibsch | Hehe |
| 15:07.04 | Laibsch | That is not really the problem |
| 15:07.18 | Laibsch | I think that if we have a bb file, it should compile |
| 15:07.27 | Laibsch | I know we'll never reach that state |
| 15:07.30 | Laibsch | for all combinations |
| 15:07.39 | Crofton | sure, but moving stuff around will make it harder to see what changed |
| 15:07.49 | Crofton | that is a fine goal |
| 15:07.54 | Laibsch | but I don't believe in the philosophy "once it's entered OE, never delete anything" |
| 15:08.04 | Laibsch | I am absolutely with you |
| 15:08.12 | Laibsch | I am an avid user of git log |
| 15:08.20 | Crofton | I also think we woll never get there |
| 15:08.22 | Laibsch | And I hate it can't do directories better |
| 15:08.24 | *** join/#oe eFfeM (n=Frans@195-241-226-180.ip.telfort.nl) |
| 15:08.36 | Crofton | and do not want a work flow that will drive people nuts |
| 15:08.58 | Crofton | it is bad enough people deleting stuff just because THEY do not see a need for it |
| 15:09.11 | Crofton | now you will move things that do not work for you |
| 15:09.16 | Laibsch | It drove nobody nuts that the package did not compile probably from the minute it entered OE |
| 15:09.33 | Laibsch | I think that says enough about this particular case |
| 15:09.57 | Laibsch | Well, if you object to moving stuff and prefer deletion, we can talk ;-) |
| 15:10.20 | pb_ | 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. |
| 15:10.31 | Crofton | :) |
| 15:10.32 | Laibsch | agreed |
| 15:10.40 | Laibsch | it's not what I am doing |
| 15:10.49 | Laibsch | again, 3-4 years |
| 15:10.58 | *** join/#oe valhalla (n=valhalla@81-174-24-165.dynamic.ngi.it) |
| 15:11.09 | pb_ | 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. |
| 15:11.49 | pb_ | 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. |
| 15:12.07 | pb_ | 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. |
| 15:12.10 | ant_work | imho some recipes have an excessive number of (unused) version in the repo |
| 15:12.13 | Crofton | my concern is there might be a combination that worked once upon a time |
| 15:12.24 | Crofton | and someone still maintains there own distro that uses it |
| 15:12.30 | Crofton | where it is anything |
| 15:12.32 | Laibsch | agrees with ant_work |
| 15:12.39 | Crofton | ant_work, see my comment |
| 15:12.40 | Laibsch | All this leads to complexity |
| 15:12.46 | Crofton | rubbish |
| 15:12.55 | Laibsch | Nice |
| 15:12.58 | pb_ | 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. |
| 15:13.05 | Crofton | people need to support old stuff |
| 15:13.07 | ant_work | Crofton: if grep doesn't reveal any revdep...away |
| 15:13.11 | Crofton | at least people living in the real world |
| 15:13.28 | pb_ | 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. |
| 15:13.30 | ant_work | Crofton: I see your point and agree |
| 15:13.32 | Crofton | I do not want to force people to fork OE becasue we delete stuff |
| 15:13.33 | CIA-35 | 03Ihar Hrachyshka <ihar.hrachyshka@gmail.com> 07org.openembedded.dev * r340cb156e8 10openembedded.git/recipes/gstreamer/ (11 files): (log message trimmed) |
| 15:13.33 | CIA-35 | gst-plugins: fixed pattern for meta package dependencies. |
| 15:13.33 | CIA-35 | This fixes package name matching so that gst-plugins-*-meta |
| 15:13.34 | CIA-35 | packages include all the plugin ones. The current matching |
| 15:13.34 | CIA-35 | implementation doesn't make meta packages depend on gst-plugins |
| 15:13.35 | CIA-35 | with 'locale' and 'dev' in their names (f.e. gstfbdevsink). |
| 15:13.37 | CIA-35 | Also use INC_PR for gstremer-plugins as requested on ML. |
| 15:13.38 | Laibsch | I don't discuss on that level |
| 15:13.40 | Laibsch | Later |
| 15:13.44 | CIA-35 | 03Koen Kooi <koen@openembedded.org> 07org.openembedded.dev * rd04f5b461a 10openembedded.git/: Merge branch 'org.openembedded.dev' of git@git.openembedded.org:openembedded into org.openembedded.dev |
| 15:14.33 | ant_work | Crofton: *some* recipes have too many versions in OE, still |
| 15:14.48 | ant_work | (much of them GPE) |
| 15:14.54 | Crofton | yeah, but we need to be really thoguhtful about deletion |
| 15:15.20 | pb_ | 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. |
| 15:15.25 | Crofton | I do not pretend this is easy |
| 15:15.27 | pb_ | I would much prefer to fix that than to start deleting the old versions. |
| 15:15.48 | ant_work | pb_: sure |
| 15:16.03 | ant_work | then you have _git and SRCRES :) |
| 15:16.06 | pb_ | 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. |
| 15:16.58 | ant_work | pb_: oneday an audacious should take the axe and start with /linux |
| 15:17.30 | pb_ | ant_work: linux/ is a good example of a package where people do definitely care about older versions. |
| 15:17.43 | ant_work | imho is out-of-control |
| 15:17.46 | pb_ | 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. |
| 15:18.18 | ant_work | platforms = distro ? machine ? |
| 15:18.29 | pb_ | machines, generally |
| 15:18.41 | Crofton | yeah |
| 15:18.56 | ant_work | I see redundancy... |
| 15:19.09 | ant_work | look at linux-rp ... |
| 15:19.10 | Crofton | I see gpl issues :) |
| 15:19.26 | ant_work | :) |
| 15:20.34 | ant_work | ok, this one would be a machine-maintainer task |
| 15:21.03 | *** join/#oe bin1010 (n=mia@rrcs-71-40-238-241.sw.biz.rr.com) |
| 15:21.56 | pb_ | ant_work: why are these extraneous kernel versions upsetting you? |
| 15:22.12 | ant_work | too many cursor-down... |
| 15:22.16 | ant_work | :p |
| 15:22.29 | ant_work | seriously...>6700 recipes |
| 15:22.34 | Crofton | lunch |
| 15:23.16 | ant_work | pb_: I scratched the surface when I started patching the 'install -s' thing |
| 15:23.31 | pb_ | 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. |
| 15:23.48 | pb_ | 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. |
| 15:23.51 | *** join/#oe CIA-73 (n=CIA@208.69.182.149) |
| 15:24.13 | *** join/#oe zerum (n=thiago@187.37.59.58) |
| 15:24.42 | Crofton | well, you could do it in one giant kernel file |
| 15:24.53 | Crofton | but it would be a nightmare to maintatin :) |
| 15:25.35 | ant_work | same for u-boot |
| 15:25.42 | *** join/#oe workrat (n=chatzill@adsl-76-234-137-73.dsl.sfldmi.sbcglobal.net) |
| 15:27.09 | pb_ | 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. |
| 15:27.35 | pb_ | having one big file that all the crazy machine guys were hacking on would be a nightmare. |
| 15:27.59 | ant_work | yea, but old kernel_machine_version are just cruft after years |
| 15:28.00 | Crofton | we are doing ok with linux-omap |
| 15:28.08 | mwester | So, what's the problem then? Magnetization is becoming too expensive? But people think my time to re-create deleted stuff is free??? :D |
| 15:28.14 | Crofton | ant_work, one mans cruft is another mans stable release |
| 15:28.17 | mwester | NO DELETES! |
| 15:28.22 | pb_ | ant_work: not necessarily. I am still using plenty of kernels from many years ago. |
| 15:28.47 | pb_ | the fact that it's old doesn't mean it is broken. |
| 15:28.50 | Crofton | no extemists |
| 15:28.54 | ant_work | can make sense with collections |
| 15:28.57 | mwester | Laibsch and I disagree vehemently on the delete issue, and if he wins the argument, then I shall force or leave OE. |
| 15:29.07 | mwester | er, fork rather. |
| 15:29.20 | Crofton | mwester, you have plenty of support from me |
| 15:29.27 | pb_ | 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. |
| 15:29.50 | *** join/#oe cminyard (n=cminyard@pool-173-57-164-199.dllstx.fios.verizon.net) |
| 15:30.00 | mwester | 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". :( |
| 15:30.34 | Crofton | heh |
| 15:30.38 | mwester | Old kernels are stable. There do exist many users who do not think that the purpose of a distro is to constantly upgrade itself. |
| 15:30.40 | pb_ | 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. |
| 15:30.41 | broonie | I thought the main point with deletion was to help deal with the bitbake speed issues? |
| 15:30.53 | mwester | These users often feel that the device has a useful purpose other than runing opkg update. |
| 15:31.06 | broonie | (and more relevant for random userspace stuff than the kernels) |
| 15:31.21 | pb_ | broonie: some people seem to think that, but the right way to deal with the bitbake speed issues is to improve bitbake. |
| 15:31.29 | Crofton | pb_, +1 |
| 15:31.31 | broonie | Well, quite. |
| 15:32.40 | pb_ | 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. |
| 15:32.54 | mwester | Yes! :) |
| 15:33.30 | mwester | I would love to see a pre-packaged BBMASK that would be maintained by those who care only about the latest bleeding edge stuff. :) |
| 15:33.32 | ant_work | pb_: all nice and sound..still I'm overwhelmed by the numerosity of Zaurus (RIP 2008) kernels.. (2003-2009) |
| 15:34.40 | pb_ | ant_work: how many Z kernels are we actually talking about? At a first glance it looks like about ten to me. |
| 15:34.42 | mwester | 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. |
| 15:35.47 | ant_work | mwester: pb_ I could count 30 in the hurry |
| 15:36.15 | Tartarus | Can we get a technical steering committee already? |
| 15:36.26 | ant_work | question: which *distros* are 'active' ? |
| 15:36.57 | pb_ | 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. |
| 15:36.59 | pb_ | Tartarus: hear, hear |
| 15:37.43 | ant_work | pb_: there are 3 kinds of...embedix, linux-rp, linux (the future? |
| 15:42.00 | pb_ | right, and it certainly used to be the case that all three of them had their own adherents. |
| 15:43.58 | ant_work | Laibsch: if you feel masochist, try sharprom-compat-image nowaday ^_^ |
| 15:51.17 | *** join/#oe kergoth (n=kergoth@ip98-167-215-86.ph.ph.cox.net) |
| 15:51.24 | Gnutoo | hi,why the variables such as the arch the distro,the machine etc... aren't displayed anymore after the parsing? |
| 15:51.55 | Gnutoo | is it because I upgraded to python 2.6? |
| 15:52.40 | hrw | re |
| 15:53.24 | kergoth | hey |
| 15:53.51 | hrw | Gnutoo: they god hidden recently |
| 15:54.16 | hrw | otavio: I will rebase when you push |
| 15:54.16 | Gnutoo | ah ok it was the mail where it told that it was hiding things from the user? |
| 15:54.41 | Gnutoo | they were very usefull for debuging the abi and similar settings |
| 15:54.49 | Gnutoo | like glibc/uclibc also |
| 15:55.09 | Gnutoo | for instance when you struggle for having uclibc insterad of glibc |
| 15:55.17 | Gnutoo | you know it imediately |
| 15:55.36 | Gnutoo | (if you BBMASK or don't parse all recipes) |
| 15:56.12 | pb_ | g'day kergoth |
| 15:56.24 | chouimat|work | morning |
| 15:56.57 | hrw | Gnutoo: bitbake -D |
| 15:57.09 | Gnutoo | ah ok thanks |
| 16:02.51 | CIA-73 | 03Rolf Leggewie <oe-devel@rolf.leggewie.biz> 07org.openembedded.dev * rbcc3623267 10openembedded.git/recipes/snes9x/snes9x_1.43-WIP1.bb: snes9x: bump PR |
| 16:10.39 | *** part/#oe CoreDump|cf-18 (n=mhentges@nslu2-linux/CoreDumpHome) |
| 16:10.58 | *** join/#oe CoreDump|cf-18 (n=mhentges@nslu2-linux/CoreDumpHome) |
| 16:12.36 | kergoth | http://darkwired.nl/~Industrial/img/lol/28aki86.jpg = awesome |
| 16:14.20 | *** join/#oe Neko (n=Neko@131.194.34.14) |
| 16:14.54 | Neko | 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? |
| 16:15.15 | kergoth | sounds like your S isn't set correctly |
| 16:15.22 | kergoth | shrugs |
| 16:16.22 | *** join/#oe brolin (n=brolin@iner.udea.edu.co) |
| 16:16.27 | CIA-73 | 03Koen Kooi <koen@openembedded.org> 07org.openembedded.dev * r8f389dd452 10openembedded.git/: Merge branch 'org.openembedded.dev' of git@git.openembedded.org:openembedded into org.openembedded.dev |
| 16:16.28 | CIA-73 | 03Koen Kooi <koen@openembedded.org> 07org.openembedded.dev * rce38ac7fce 10openembedded.git/recipes/gstreamer/gst-plugins.inc: gst-plugins: switch back to old way of excluding locales |
| 16:16.37 | ant_work | kergoth: do you have around the links to your cleaning-scripts (and results)? |
| 16:16.38 | Neko | S? |
| 16:16.44 | kergoth | hmm, somewhere |
| 16:16.51 | kergoth | I'm not even sure which machine i wrote it on |
| 16:16.54 | kergoth | has way too many trees |
| 16:17.03 | kergoth | fires off a locate or 12 |
| 16:17.07 | ant_work | kergoth: Laibsch would be very interested... |
| 16:17.50 | ant_work | about $S, the kernel.bb seems needing its own |
| 16:18.11 | Laibsch | ant_work: ? |
| 16:18.21 | ant_work | Laibsch: surprise :) |
| 16:19.23 | ant_work | basically many lines could be deleted from many recipes |
| 16:19.58 | kergoth | i'll make it not yell about PR, cause people dislike that one :P |
| 16:20.00 | ant_work | so one could just pick up a good exemple |
| 16:20.10 | ant_work | kergoth: eek |
| 16:20.23 | *** join/#oe Ojg (n=Ojg@90-229-198-184-no150.tbcn.telia.com) |
| 16:20.24 | Laibsch | I'm still not following you |
| 16:20.49 | kergoth | 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 |
| 16:21.04 | Laibsch | Oh, that sounds nice |
| 16:23.15 | ant_work | this belongs to http://wiki.openembedded.net/index.php/Common_mistakes_in_a_recipe |
| 16:23.16 | Laibsch | but of course, OE is not too complex. Anybody who says so is talking just "rubbish". |
| 16:24.52 | Laibsch | 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 |
| 16:25.01 | Laibsch | likes PR = "r0", though |
| 16:25.14 | Laibsch | as a reminder to bump it when necessary |
| 16:25.31 | Neko | 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 >.< |
| 16:28.10 | ant_work | gotcha |
| 16:28.12 | ant_work | http://kergoth.pastey.net/111234 |
| 16:28.43 | ant_work | http://kergoth.pastey.net/111232 |
| 16:31.10 | Laibsch | commit to contrib? |
| 16:31.23 | Laibsch | and advocate on the list |
| 16:32.57 | eFfeM | Laibsch: PR = "r0" was discussed a week or so ago. Most people who responded seemed in favor |
| 16:33.07 | cdbot2 | * * OE Bug 1196 has been RESOLVED (FIXED) by <Laibsch> |
| 16:33.09 | cdbot2 | * * "bitbake snes9x" complains about missing -lqte |
| 16:33.11 | cdbot2 | * * http://bugs.openembedded.net/show_bug.cgi?id=1196 |
| 16:33.13 | hrw | for me PR = "r0" can be in recipes |
| 16:33.17 | eFfeM | also it is odd to remove the line when going to a new release |
| 16:37.21 | *** join/#oe ptitjes (n=didier@93.2.7.156) |
| 16:37.29 | *** part/#oe ptitjes (n=didier@93.2.7.156) |
| 16:40.26 | kergoth | 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 |
| 16:41.03 | Laibsch | If cleanup remains possible, I may continue to do it |
| 16:41.31 | *** join/#oe ptitjes (n=didier@93.2.7.156) |
| 16:41.34 | Laibsch | Please commit the script to contrib |
| 16:42.08 | kergoth | k. i'll remove the autotools_base bits, thats specific to my autotools branch. autotools_base class is everything but autoreconf execution |
| 16:42.09 | kergoth | heh |
| 16:44.33 | kergoth | wtf |
| 16:44.34 | kergoth | fatal: cannot pread pack file: No such file or directory |
| 16:44.34 | kergoth | fatal: index-pack failed |
| 16:44.39 | kergoth | anyone seen that git error before? |
| 16:44.43 | kergoth | tries a fresh clone instead |
| 16:45.37 | *** part/#oe ptitjes (n=didier@93.2.7.156) |
| 16:47.22 | ant_work | bbl |
| 16:52.18 | otavio | hello |
| 16:52.32 | kergoth | hey |
| 16:52.32 | otavio | hrw: did it |
| 16:53.16 | *** join/#oe likewise (n=chatzill@82-171-51-231.ip.telfort.nl) |
| 16:55.58 | Gnutoo | hi what are the advantages of minisip compared to others solutions? is it faster? |
| 16:57.14 | *** join/#oe benlau2 (n=benlau@221.125.8.70) |
| 16:57.17 | *** join/#oe W_I (n=W_I@a88-112-207-217.elisa-laajakaista.fi) |
| 17:11.31 | hrw | otavio: so geodegx/lx will be i486 not i586? |
| 17:13.40 | hrw | otavio: I will be back in ~1h - will you be then? |
| 17:17.27 | *** join/#oe benlau21 (n=benlau@221.125.8.70) |
| 17:19.59 | Jay7 | http://www.linuxdevices.com/news/NS1980620246.html |
| 17:20.13 | Jay7 | 'kinda bug' smartphone :) |
| 17:22.16 | Laibsch | 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 |
| 17:22.32 | otavio | hrw|gone: will be, np |
| 17:23.07 | otavio | hrw|gone: we'd need to test it but I think i586 does work |
| 17:30.33 | *** part/#oe ArteK (n=Artur@81.15.241.96) |
| 17:31.12 | *** join/#oe digital-ex (n=Luccisa@nat/cisco/x-3c677dc2c6fda46c) |
| 17:32.49 | *** join/#oe Spyro1 (n=ian@benden.mnementh.co.uk) |
| 17:41.40 | kergoth | 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. |
| 17:46.27 | likewise | kergoth: no, I find the gnome.bbclass dep on gtk-icon-cache strange |
| 17:46.45 | likewise | s/dep/inherit |
| 17:47.35 | Gnutoo | mmm...does someone knows libosp2? which version provides osip_negotiation.h ? |
| 17:47.38 | pb___ | kergoth: I think it's the dependency of gtk-icon-cache on hicolor-icon-theme that's bogus. |
| 17:47.54 | pb___ | not least because it looks like it will apply to -dev and locale packages as well as the intended ones |
| 17:48.09 | kergoth | heh, good point, thats no good |
| 17:49.31 | pb___ | 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 |
| 17:50.00 | kergoth | ah |
| 17:50.09 | pb___ | 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. |
| 17:52.41 | pb___ | it also seems a bit weird that gtk-i-c.bbclass is adding "${datadir}/icons/hicolor" to FILES_${PN}. |
| 17:54.39 | pb___ | 6c644a5c61dd3b814db20de7deefbe7485a7142a was the checkin where the dependency was added. |
| 17:54.56 | Gnutoo | found the correct version: https://dev.openwrt.org/ticket/1679 |
| 17:55.15 | Gnutoo | should we make libosip-2.2.2 the prefered version? |
| 17:56.15 | pb___ | hm, obviously this gnome stuff was all too much |
| 17:56.16 | Gnutoo | s/libosip-2.2.2/libosip2-2.2.2/ |
| 17:57.28 | *** join/#oe rkirti (n=rkirti@117.254.21.242) |
| 17:57.30 | *** join/#oe guillaum1 (n=gl@90.95.1.236) |
| 18:00.16 | *** join/#oe kergoth (n=kergoth@ip98-167-215-86.ph.ph.cox.net) |
| 18:01.24 | *** join/#oe dth1 (n=dth@p4FDED00A.dip.t-dialin.net) |
| 18:02.48 | pb___ | 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". |
| 18:03.06 | pb___ | I can't see anything in the postinsts that does genuinely depend on hicolor-icon-theme though; I suspect that justification is probably bogus. |
| 18:03.08 | kergoth | why would the postinsts need that? |
| 18:03.11 | kergoth | heh |
| 18:03.12 | kergoth | right then |
| 18:04.44 | jimsheldon | has anyone used a Qt app with a touchscreen device built with OE lately? |
| 18:04.56 | pb___ | 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. |
| 18:05.00 | jimsheldon | preferably an omap3 device? |
| 18:13.27 | cbrake | Laibsch: yes, Theodore Roth just go rw, per Mickey and my suggestion from some weeks ago |
| 18:13.55 | cbrake | Laibsch: was meaning to send email to oe-dev and got sidetracked ... |
| 18:16.01 | *** join/#oe HellDragon (i=jd@Wikipedia/HellDragon) |
| 18:19.57 | *** join/#oe alecrim (n=alecrim@189.2.128.130) |
| 18:27.51 | *** join/#oe zerum (n=quassel@187.37.59.58) |
| 18:33.02 | CIA-73 | 03Koen Kooi <koen@openembedded.org> 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 |
| 18:33.03 | CIA-73 | 03Koen Kooi <koen@openembedded.org> 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() |
| 18:37.20 | hrw | morning |
| 18:37.41 | hrw | otavio: I used alix with settings which were before your changes |
| 18:37.57 | hrw | otavio: when it used k6-2 march |
| 18:43.02 | Laibsch | 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? |
| 18:43.56 | hrw | grep sets bitbake -r |
| 18:44.33 | CIA-73 | 03Rolf Leggewie <oe-devel@rolf.leggewie.biz> 07org.openembedded.dev * r977b935c7a 10openembedded.git/ (4 files in 2 dirs): |
| 18:44.33 | CIA-73 | pwlib: update SRC_URI, unify and clean-up. |
| 18:44.33 | CIA-73 | * build still fails, bug 1622 still open |
| 18:47.54 | *** join/#oe Sup3rkiddo (n=sudharsh@unaffiliated/sudharsh) |
| 18:48.30 | Laibsch | hrw: http://rafb.net/p/Id9vpZ77.html |
| 18:48.33 | Laibsch | shell.py? |
| 18:51.38 | *** join/#oe timtimred (n=meh@79-75-169-127.dynamic.dsl.as9105.com) |
| 18:52.23 | hrw | yep |
| 18:54.30 | Laibsch | sed s/sets/Sets/ bitbake/bb/shell.py |
| 18:54.31 | Laibsch | ? |
| 18:55.23 | hrw | I will prepare patch |
| 18:56.09 | hrw | ~curse git-svn |
| 18:56.09 | ibot | May the fleas of a thousand camels infest your most sensitive regions, git-svn ! |
| 18:58.39 | hrw | Laibsch: how you get to this moment? -cdevshell? |
| 18:58.56 | Laibsch | Just normal bitbake invocation |
| 18:59.25 | Laibsch | bitbake $something |
| 18:59.41 | Laibsch | The deb package I use is at https://launchpad.net/~r0lf/+archive/ppa |
| 19:00.38 | Laibsch | but it's basically the deb from debian plus the revision 1178 from bitbake svn added to it |
| 19:03.26 | hrw | I use trunk or top of bitbake-1.8 or stable/2009 |
| 19:07.57 | hrw | Laibsch: .dev or stable/2009? |
| 19:10.01 | Laibsch | .dev |
| 19:10.17 | Laibsch | But I don't think that should have anything to do with it, no? |
| 19:10.19 | hrw | no idea where from it comes |
| 19:10.31 | hrw | mail about it to ML please |
| 19:10.37 | Laibsch | OK |
| 19:11.17 | Laibsch | 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? |
| 19:11.18 | hrw | sets is used only in shell.py but only if 'set' is not available (so python 2.3 rather) |
| 19:11.28 | hrw | I removed that and still got it |
| 19:12.05 | hrw | got it! |
| 19:12.07 | hrw | task-base |
| 19:12.38 | hrw | - if not hasattr(__builtins__, 'set'): |
| 19:12.38 | hrw | - from sets import Set as set |
| 19:12.43 | hrw | in task-base.bb |
| 19:12.49 | hrw | but thats probably also not that |
| 19:13.09 | Laibsch | http://docs.python.org/library/__builtin__.html |
| 19:13.16 | Laibsch | I think that is getting warmer |
| 19:13.54 | Laibsch | I think that whatever provides __builtin__ may be the culprit |
| 19:13.55 | *** join/#oe ArteK (n=Artur@81.15.241.96) |
| 19:13.57 | Laibsch | not bitbake |
| 19:14.13 | otavio | hrw: right but I belive that i586 will do fine |
| 19:14.20 | Laibsch | And from what I understand of that page, that $whatever may be python 2.6 itself |
| 19:14.33 | otavio | hrw: I can't compile it from scratch today but I can manage to test it later this week |
| 19:14.42 | hrw | otavio: would be nice |
| 19:14.48 | *** join/#oe Eismann (n=foo@247.70.222.87.dynamic.jazztel.es) |
| 19:14.57 | hrw | otavio: I have to export my patches and send to ML |
| 19:15.01 | otavio | hrw: do you have time to test it? |
| 19:15.12 | otavio | hrw: it would be nice |
| 19:16.07 | hrw | otavio: I will do a build and have a look does it boots and do 'openssl speed' on it |
| 19:16.41 | otavio | hrw: nice |
| 19:17.19 | hrw | my work branch has also some ep93xx work |
| 19:20.18 | hrw | have a nice rest of day |
| 19:20.21 | hrw | -> off |
| 19:20.40 | *** join/#oe digital-ex (n=Luccisa@nat/cisco/x-9f5022c1c788b8e2) |
| 19:27.31 | *** join/#oe mekius (n=mekius@enlightenment/developer/mekius) |
| 19:29.29 | Laibsch | 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. |
| 19:29.45 | Laibsch | mwester: same question |
| 19:30.08 | Crofton | Laibsch, ask on the list |
| 19:30.18 | Laibsch | I'm asking your opinion first |
| 19:30.20 | Crofton | does that work? |
| 19:30.31 | Laibsch | Compable_machine? |
| 19:30.36 | Crofton | well in recipes |
| 19:30.39 | Laibsch | Yes, the setting works and is used |
| 19:30.40 | Crofton | I suspect it will |
| 19:30.52 | Laibsch | let's assume for now that it does |
| 19:30.56 | Crofton | well, it does not annoy me |
| 19:31.02 | Laibsch | if it did, what's your opinion |
| 19:31.10 | Crofton | see above |
| 19:31.14 | Laibsch | deleted and moved recipes annoy you |
| 19:31.18 | Crofton | highly |
| 19:31.36 | Laibsch | not sure it can always be avoided |
| 19:31.47 | Crofton | basically, I think it is a question worth presenting to a larger audience |
| 19:31.53 | Laibsch | yes |
| 19:31.59 | Laibsch | starting with 1 |
| 19:32.36 | Laibsch | so, what is your opinion? |
| 19:32.54 | Crofton|work | ask the list :) |
| 19:33.01 | Crofton|work | I think it is worth presenting |
| 19:33.10 | Laibsch | OK, so your opinion is the same as the list? |
| 19:33.16 | Laibsch | sheesh! |
| 19:33.18 | Crofton|work | my opinion on this is flexible |
| 19:33.41 | Laibsch | It did not sound very flexible earlier |
| 19:33.48 | Laibsch | But maybe that is my English |
| 19:33.59 | Crofton|work | heh |
| 19:34.09 | Crofton|work | it is inflexible about moves/delets |
| 19:34.24 | Crofton|work | yes, we are likely having communicaiont issues |
| 19:34.36 | Laibsch | well, the question is about this |
| 19:34.46 | Crofton|work | basically, if you ask about moves/deletes on the list, I will reply promptly saying I do not liek the idea |
| 19:34.54 | *** join/#oe HellDragon (i=jd@Wikipedia/HellDragon) |
| 19:35.04 | Laibsch | 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 |
| 19:35.07 | Crofton|work | but, COMPATIBLE_MACHINE I would like to hear other devs thoughts |
| 19:35.27 | Laibsch | sending mail |
| 19:35.31 | Crofton|work | I like it enough to see what others think |
| 19:35.33 | Crofton|work | good |
| 19:36.05 | Crofton|work | the basic premise that bitbake world actually complete is not high on my list :) |
| 19:44.48 | *** join/#oe digital-ex (n=Luccisa@nat/cisco/x-a9bb74d9a66e600b) |
| 19:47.25 | *** join/#oe grma (n=gruberm@chello212186029093.tirol.surfer.at) |
| 19:51.33 | *** join/#oe pb__ (n=pb@88-109-34-80.dynamic.dsl.as9105.com) |
| 19:54.30 | *** join/#oe brolin (n=brolin@200.24.16.55) |
| 19:54.48 | kergoth | erk |
| 19:54.53 | kergoth | i just broke bitbake, and i have no idea how to fix this one |
| 19:55.03 | kergoth | <PROTECTED> |
| 19:55.03 | kergoth | <PROTECTED> |
| 19:55.03 | kergoth | KeyError: 447 |
| 19:55.20 | *** join/#oe smartin (n=smartin@216.58.130.98) |
| 19:55.26 | kergoth | there were like 30 entries for line 248 in find_chains in the traceback |
| 20:09.42 | *** join/#oe flo_lap (n=fuchs@f049038042.adsl.alicedsl.de) |
| 20:16.10 | *** join/#oe bluelightning (n=blueligh@pdpc/supporter/active/bluelightning) |
| 20:33.30 | *** join/#oe guillaum1 (n=gl@AMontsouris-153-1-17-25.w86-212.abo.wanadoo.fr) |
| 20:37.28 | *** part/#oe ArteK (n=Artur@81.15.241.96) |
| 20:39.21 | *** join/#oe abner (n=birunko@189.70.76.86) |
| 20:41.55 | *** join/#oe digital-ex (n=Luccisa@nat/cisco/x-3e2561b355049ff9) |
| 20:55.07 | *** join/#oe hillct (n=hillct@cpe-069-134-049-165.nc.res.rr.com) |
| 21:02.15 | *** join/#oe brolin_ (n=brolin@200.24.16.55) |
| 21:02.35 | *** join/#oe bbradley_ (n=bbradley@87-194-119-230.bethere.co.uk) |
| 21:07.14 | Crofton | http://www.industrial-embedded.com/news/Industry+News/17450 |
| 21:07.46 | tharvey | 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? |
| 21:08.15 | eFfeM | tharvey: look at the other recipes |
| 21:08.31 | kergoth | you need to ensure it links using our ldflags |
| 21:08.48 | eFfeM | crofton, thanks for the link |
| 21:09.22 | tharvey | 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 |
| 21:09.35 | eFfeM | crofton, are you with embedded alley |
| 21:10.05 | kergoth | Crofton: sounds like an impressive featureset |
| 21:10.13 | kergoth | particularly the BoM / tracability |
| 21:11.20 | pb__ | tharvey: if it's a driver package in the sense of kernel drivers, it shouldn't be getting that check applied at all. |
| 21:15.01 | *** join/#oe bin10101 (n=mia@rrcs-71-40-238-241.sw.biz.rr.com) |
| 21:16.30 | tharvey | pb_, madwifi includes some userland tools - its those that fail the GNU_HASH based on ldflags that I'm trying to fix |
| 21:17.10 | Crofton | tharvey, look in the git log for some similar fixes |
| 21:18.00 | Crofton | http://cgit.openembedded.org/cgit.cgi/openembedded/commit/?id=86999e943334858a687a51bbe2165ede26b00473 |
| 21:18.48 | tharvey | ok... I'll keep working on it thx |
| 21:20.13 | pb__ | 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. |
| 21:21.06 | pb__ | hard-wiring --hash-style=gnu would remove the particular qa error but would (at least in part) defeat its purpose. |
| 21:21.33 | *** join/#oe jconnoll1 (n=jconnoll@firebug.buglabs.net) |
| 21:22.20 | tharvey | 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 |
| 21:22.34 | tharvey | but your point is taken... the real purpose is to make sure OE's supplying ldflags |
| 21:27.40 | tharvey | madwifi seems tob e perhaps a special case though - http://cgit.openembedded.net/cgit.cgi?url=openembedded/commit/&id=75d4826c3c0f7012ccee3a7116d7350f41539fa3 |
| 21:36.04 | Crofton | It could be |
| 21:39.39 | likewise | tharvey: that fix is wrong... LDFLAGS is needed for some tools |
| 21:39.54 | likewise | tharvey: the real fix is to clear LDFLAGS in the correct Makefiles, not in the recipe |
| 21:40.15 | likewise | tharvey: that commit undo's some of my (yes, agressive) fixes to make it work on powerpc again |
| 21:40.55 | Jay7 | -> sleep |
| 21:40.59 | likewise | tharvey: this was related to my fix: http://cgit.openembedded.net/cgit.cgi?url=openembedded/tree/recipes/madwifi/files/respect-ldflags.patch&id=eaea0ee411da83f7c5349920c701a55a17384f8e |
| 21:42.17 | CIA-73 | 03Rolf Leggewie <oe-devel@rolf.leggewie.biz> 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. |
| 21:42.56 | likewise | mwester: ping |
| 21:45.12 | likewise | tharvey: See openembedded ml: "[PATCH] madwifi-ng_r3837: Fix for LDFLAGS / GNU_HASH QA" |
| 21:54.43 | mwester | likewise, pong. |
| 21:56.08 | likewise | mwester: tharvey runs into the same GNU_HASH problem I fixed (aggressively) in madwifi, which you reverted (unset LDFLAGS) |
| 21:56.32 | mwester | Is there a problem, or is it just a sanity check? |
| 21:56.36 | likewise | mwester: I suggest to keep LDFLAGS set, and unset it only in the Makefiles where it needs to be unset. |
| 21:57.18 | mwester | Is there a problem, or is it just a sanity check? |
| 21:57.20 | likewise | mwester: it's a problem, it means the LDFLAGS (library link path etc) was incorrect. |
| 21:57.25 | mwester | Is there a problem, or is it just a sanity check? |
| 21:57.47 | *** join/#oe tharvey (n=tharvey@adsl-76-205-222-173.dsl.snlo01.sbcglobal.net) |
| 21:58.10 | likewise | It's a problem on some archs. |
| 21:58.29 | mwester | 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. |
| 21:59.24 | likewise | mwester: what if I use EXTRA_DEPENDS in my local.conf? |
| 22:00.00 | likewise | mwester: It's a warning that something is wrong. I agree your revert is ok, I just want to find a proper fix. |
| 22:00.52 | likewise | mwester: Do you still have the build log for madwifi when it failed in tmp/work/*/*/madwifi*/temp/log.do_compile* |
| 22:01.18 | mwester | It's a warning that the dynamic linker will take a few nano-seconds longer to link in the libs, as I understand it. |
| 22:01.31 | mwester | No, I have no logs for that any longer. |
| 22:02.31 | mwester | MACHINE = "nslu2be" & DISTRO="slugos" |
| 22:02.38 | likewise | 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 |
| 22:02.47 | likewise | mwester: thanks will reproduce |
| 22:03.33 | mwester | 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. |
| 22:06.15 | mwester | 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. |
| 22:08.03 | likewise | mwester: The build breaks for everyone who has the sanity checks enabled. They default to failure now I think, instead of warning. |
| 22:08.14 | mwester | That sucks. |
| 22:08.28 | mwester | Rather a foolish decision. |
| 22:09.47 | 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. |
| 22:10.02 | mwester | And you KNOW that was a Koen decision, and nobody else could (or cared to) argue. |
| 22:11.11 | mwester | anyway, must run - flat tire that I have to get fixed right now. |
| 22:12.00 | likewise | I'm ignorant of that, really. I was just building madwifi for my powerpc. |
| 22:30.57 | mwester | likewise, why not just build the version everyone else builds? |
| 22:31.26 | mwester | r3878 had default preference of -1, so it should be used ONLY by SlugOS. |
| 22:34.23 | likewise | mwester: I don't know, I think I have used that version since a year or so, when it was the latest. |
| 22:34.30 | mwester | fine. |
| 22:34.56 | mwester | then I'll make r3879 for slugos. |
| 22:36.44 | XorA | goes to find sleep |
| 22:37.27 | likewise | 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. |
| 22:37.54 | mwester | This is about making something work, and keeping it working. |
| 22:38.06 | mwester | Apparently we need something different for SlugOS vs Angstrom. |
| 22:38.12 | mwester | How do we do that? |
| 22:38.22 | timtimred | pistols at dawn |
| 22:38.34 | mwester | I've tried EVERYTYHNG I KNOW to keep out of everybodies' freeweking way in OWE> |
| 22:38.58 | mwester | Yet I spend 70+ percent of my OE time FIXING shit. |
| 22:39.04 | mwester | instead of developing or supporting a distro. |
| 22:39.10 | mwester | Yes, I'm frustrated. |
| 22:39.16 | mwester | I don't care about elegant. |
| 22:39.37 | likewise | It's impossible to keep .dev working at all times for everyone, while we globally try to improve it. |
| 22:39.46 | mwester | 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. |
| 22:40.00 | mwester | likewise, I fixed it, didn't I? |
| 22:40.08 | mwester | Did I ping you even? |
| 22:40.11 | mwester | No. |
| 22:40.17 | mwester | I freeeking fixed it for slugos. |
| 22:40.30 | timtimred | do you branch your distro to stabilise it for your users or use dev? |
| 22:40.48 | mwester | Now don't go getting all worked up becuase I changed one freeking thing in a recipe that is CLEARLY slugos-specific. |
| 22:41.03 | mwester | timtimred, I'm not arguing with you, am I? |
| 22:41.20 | mwester | I have both branches, and I have the next release to consider. |
| 22:41.21 | timtimred | im not arguing here im just vaguely interested :) |
| 22:41.23 | mwester | Hence I need both. |
| 22:41.50 | mwester | 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? |
| 22:42.04 | mwester | We've tried that. It's worse. |
| 22:42.26 | mwester | So I'm just about fed up with trying every possible thing I can do to stay out of everyone else's way. |
| 22:42.34 | mwester | DEFAULT_PREFERENCE = -1 |
| 22:42.43 | mwester | DEFAULT_PREFERENCE_slugos = 1 |
| 22:42.45 | mwester | ? |
| 22:43.06 | mwester | Should I name the version differently? packagname_SLUGOS_pv.bb? |
| 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 |
| 22:43.34 | mwester | kergoth misses the point. |
| 22:43.41 | likewise | mwester: what if DEFAULT_PREFERENCE_somemach = 1 is added? |
| 22:44.16 | mwester | 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. |
| 22:44.30 | mwester | likewise, yeah, what? |
| 22:44.48 | mwester | likewise, then whomever did that has agreed that the recipe as it stands works for them. |
| 22:45.25 | likewise | ok, and no ONE of the archs start to fail due to toolchain upgrade |
| 22:45.26 | mwester | 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. |
| 22:45.42 | likewise | s/no/now/ |
| 22:45.50 | mwester | Don't even start me on toolchain issues. That nightmare continues. |
| 22:46.01 | mwester | It's gotten a lot better in the past months, though. |
| 22:46.37 | mwester | 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. |
| 22:46.50 | likewise | so you prefer claiming a recipe for one distro, instead of making it work across all machines? |
| 22:46.50 | mwester | The closer you are to Angstrom, the better life is. |
| 22:47.17 | likewise | ...+distros? |
| 22:47.27 | mwester | 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!!!!!!! |
| 22:47.35 | pb__ | likewise: most people do only care about one distro. that's just life. |
| 22:47.57 | mwester | I do not feel that any one person can adequately test out-of-kernel device drivers in the first place. |
| 22:47.59 | pb__ | 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. |
| 22:48.12 | likewise | 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. |
| 22:48.24 | kergoth | mwester needs to get laid or something, instead of bitching left and right on irc |
| 22:48.36 | mwester | kergoth, go to (*(*(* |
| 22:48.56 | *** part/#oe mwester (n=mwester@nslu2-linux/mwester) |
| 22:48.58 | kergoth | whine some more, please, thats just what we all need to hear |
| 22:50.06 | pb__ | heh. well, he does have some valid points. |
| 22:50.37 | pb__ | 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. |
| 22:50.45 | kergoth | he does, but i don't think being that argumentative and abrasive and yelling at people is going to help fix it, either |
| 22:50.48 | likewise | I'm ok with ppl claiming a recipe, but that should be mentioned in the recipe then. |
| 22:50.55 | kergoth | not that i was much better in the past, but.. :) |
| 22:51.20 | timtimred | in the MAINTAINERS file ... |
| 22:51.38 | timtimred | or did that change, i know there was some discussion but i missed the end... |
| 22:51.41 | pb__ | yah, agreed, shouting and screaming is not really the right way to get things done. |
| 22:52.40 | *** join/#oe ant__ (n=andrea@host115-20-dynamic.0-87-r.retail.telecomitalia.it) |
| 22:53.20 | pb__ | as for MAINTAINERS, dunno, I lost track of that too. |
| 22:53.24 | ant__ | btw, iirc there is a var like 'skip_QA' for the specific mwester case |
| 22:53.37 | kergoth | 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 |
| 22:53.38 | kergoth | heh |
| 22:53.57 | pb__ | yeah |
| 22:54.09 | pb__ | adds that to the long list of better tools that would help |
| 22:54.10 | likewise | ideally, a build machine that does auto-bisect on builds. |
| 22:54.39 | Crofton|work | we need to find a way to all get in one place for a bit |
| 22:54.56 | kergoth | 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 |
| 22:55.01 | likewise | takes many build cycles though... I have had this semi-automated once under monotone |
| 22:55.06 | pb__ | likewise: isn't that basically what tinderbox is? |
| 22:55.18 | likewise | pb__: yes, minus auto-bisect |
| 22:55.19 | pb__ | obviously no auto-bisect as such, but if it builds often enough you should still get the same effect |
| 22:55.42 | likewise | pb__: agreed, maybe tinderbox should report good and bad builds to a bisector |
| 22:55.53 | pb__ | yeah, that's not a bad idea |
| 22:56.12 | likewise | machine X, distro Y, target Z for commit C: failed or succeeded |
| 22:56.20 | likewise | machine X, distro Y, target Z for commit C2: failed or succeeded |
| 22:56.31 | likewise | then auto bisect between C and C2 for that combo |
| 22:56.51 | pb__ | 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. |
| 22:57.17 | CIA-73 | 03Koen Kooi <koen@openembedded.org> 07org.openembedded.dev * r4c275b5c03 10openembedded.git/classes/gnome.bbclass: |
| 22:57.17 | CIA-73 | gnome bbclass: package scrollkeeper 'leftovers' in a seperate package. Like the fdo mime data it overlaps between packages. |
| 22:57.17 | CIA-73 | * better solution is needed for people wanting docs on device, but this makes packages at least installable |
| 22:57.25 | CIA-73 | 03Koen Kooi <koen@openembedded.org> 07org.openembedded.dev * r2a20dd7eef 10openembedded.git/ (4 files in 2 dirs): ekiga: update ekiga bits to 3.2.4 |
| 22:57.25 | CIA-73 | 03Koen Kooi <koen@openembedded.org> 07org.openembedded.dev * r23516c5a60 10openembedded.git/: Merge branch 'org.openembedded.dev' of git@git.openembedded.org:openembedded into org.openembedded.dev |
| 22:57.26 | CIA-73 | 03Koen Kooi <koen@openembedded.org> 07org.openembedded.dev * rdd68f2a6e6 10openembedded.git/: Merge branch 'org.openembedded.dev' of git@git.openembedded.org:openembedded into org.openembedded.dev |
| 22:57.28 | kergoth | 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 |
| 22:57.28 | kergoth | hmm |
| 22:57.36 | pb__ | 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. |
| 22:57.49 | kergoth | heh, indeed |
| 22:58.07 | pb__ | right, but I think the set of host bits that oe can legitimately access is pretty small. nowadays. |
| 22:58.44 | pb__ | 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. |
| 23:00.38 | ant__ | likewise: for madwifi you could perhaps add INSANE_SKIP |
| 23:00.40 | ant__ | http://cgit.openembedded.net/cgit.cgi?url=openembedded/commit/&id=13e3e087e4d45555ee29caf09576961db9e5f30e |
| 23:00.53 | ant__ | if you're really sure |
| 23:01.01 | ant__ | it is sane |
| 23:01.36 | likewise | ant__: ok tnx, I'll try to fix it first though |
| 23:02.34 | *** join/#oe jayix (n=Owner@202-89-173-144.static.dsl.amnet.net.au) |
| 23:02.41 | ant__ | i think this smooths the effect of having fatal QA |
| 23:03.02 | pb__ | zzz now |
| 23:03.03 | pb__ | night all |
| 23:03.06 | likewise | zz |
| 23:03.13 | likewise | cya |
| 23:03.16 | Crofton|work | gn |
| 23:03.21 | ant__ | going too, bye |
| 23:03.23 | likewise | -zz |
| 23:03.31 | likewise | can't sleep yet |
| 23:04.41 | *** join/#oe jayiz` (n=Owner@202-89-173-144.static.dsl.amnet.net.au) |
| 23:05.18 | *** join/#oe _Lucretia_ (n=Lucretia@5ac2a234.bb.sky.com) |
| 23:06.17 | Crofton|work | heh |
| 23:06.19 | Crofton|work | why not? |
| 23:06.39 | likewise | holiday here, so I went to bed 3 hours late yesterday evening |
| 23:06.57 | likewise | i'll probably have +8 hours offset on monday :-) |
| 23:07.11 | Crofton|work | ah |
| 23:20.45 | *** join/#oe digital-ex (n=Luccisa@nat/cisco/x-e864dd7fe1b3c573) |
