**** BEGIN LOGGING AT Wed Oct 27 02:59:57 2010 Oct 27 05:05:57 khem: libcairo.99369-99348-99353-99357-99363-99368-99369-99347-99349 as well as 99415+newerSRCREV still broken :/ Oct 27 05:10:31 khem: starting build without all 9936* Oct 27 05:28:29 khem: libcairo.99359-99347-99348-99349-99351-99353-99357 -> fails to start with "Floating point exception" Oct 27 06:06:41 I'm setting up a recipe for python bindings to libconfig, and I get a compile error saying "cannot find -lboost_python". I have dependended on boost in my recipe. Oct 27 06:19:26 JaMa|Zzz: hmm so which version do work Oct 27 06:23:32 khem: patches only before 99347 are still the only version known to be working + version without any linaro patch Oct 27 06:24:39 I think my Q is: how do I tell a distutils-inheriting recipe where to look for header files and libraries? Oct 27 06:25:11 khem: now I tried to disable also 99352 and 99352 Oct 27 06:25:18 err 99350 Oct 27 06:27:38 JaMa|Zzz: so once you apply 99347 it breaks ? Oct 27 06:27:52 which means 99347 is the one culprit Oct 27 06:28:04 no Oct 27 06:28:29 first I've built it with patches up to 99346 and that version worked Oct 27 06:28:54 then i've built it with all patches up to 99369 and that version didn't work Oct 27 06:29:20 so I started to remove suspicious patches (as you've marked them) one-by-one Oct 27 06:29:43 now I have only 5 patches enabled between 99346 and 99369 Oct 27 06:29:59 and with so it should be one of them Oct 27 06:30:10 hi khem Oct 27 06:30:26 i'm the guy you just replied to about the linker problem w/ libfreetype.so Oct 27 06:30:49 what did you mean by a libtool macro update for the recipe? sorry if i'm being dense Oct 27 06:38:27 khem: new running version :) 99359-99347-99348-99349-99350-99351-99352-99353-99357 (which means all up to 99359 except those listed with - sign) Oct 27 06:39:11 khem: and last change (after "Floating point exception") was -99350 and -99352 Oct 27 06:40:35 JaMa|Zzz: hmmm difficult to understand Oct 27 06:40:57 so you removed 99359-99347-99348-99349-99350-99351-99352-99353-99357 patches and applied all the rest Oct 27 06:41:01 and it worked ? Oct 27 06:41:34 so my guess one of this 2 is "creating" "Floating point exception" and the problem itself probably and one of 99360+ patches is fixing "Floating point exception" but the problem persist Oct 27 06:41:50 khem: no first number is highest patch applied Oct 27 06:42:12 khem: so all up to 99359 except those listed later .. (-99347-99348-99349-99350-99351-99352-99353-99357) Oct 27 06:43:03 ok can you see if you can apply all patches now Oct 27 06:43:14 excluding (-99347-99348-99349-99350-99351-99352-99353-99357) Oct 27 06:43:15 khem: mmt I'll push it to branch to be clear Oct 27 06:43:47 so we can see if the culprit is one of these Oct 27 06:44:55 mrj10: looking at clxclient it should not be inheriting autotools class Oct 27 06:46:20 khem: I'm building all -99350-99352 now expecting one of 9936* fail to apply Oct 27 06:46:35 khem: so i should change: Oct 27 06:47:04 khem: inherit autotools pkgconfig lib_package Oct 27 06:47:05 to Oct 27 06:47:05 inherit pkgconfig lib_package Oct 27 06:47:05 in clxclient_3.6.1.bb ? Oct 27 06:47:17 khem: btw I've noticed you've pushed supertux build fix.. so you don't have problem with sdl-mixer not detected in its do_configure, right? with libtool-2.4.. Oct 27 06:48:30 khem: and when you have time, please check "[oe] DEPENDS broken for native(sdk).bbclass Was: libgee introspection problem" thread, I think you're one of the autotools.bbclass masters :) Oct 27 07:04:12 I have the library I need in sysroots/armv7a-angstrom-linux-gnueabi/usr/lib/libboost_python-mt.so, but my recipe doesn't find it. Oct 27 07:09:01 03Khem Raj  07master * r0c958cb549 10openembedded.git/recipes/jaaa/clxclient_3.6.1.bb: Oct 27 07:09:01 clxclient_3.6.1.bb: Fix compilation, do not inherit autotools Oct 27 07:09:01 * This does not use autoconf or automake so no need to inherit it Oct 27 07:09:01 * Do not override CFLAGS and add freetype include path to compiler Oct 27 07:09:01 include search paths Oct 27 07:09:02 Signed-off-by: Khem Raj Oct 27 07:09:02 mrj10: I fixed it for you Oct 27 07:09:23 mrj10: update to latest master and try it out again Oct 27 07:10:36 thanks so much, i really appreciate it Oct 27 07:14:20 khem: cairo.all-99350-99352 works, which one should I try to enable first? Oct 27 07:15:21 99352 looks safe right? Oct 27 07:20:05 JaMa: yes Oct 27 07:20:05 khem: upgrading to OE hed -99350 Oct 27 07:20:08 head Oct 27 07:20:30 ok so now you have all patches applied except 99350 right Oct 27 07:21:24 last tested version (working) was without your 2 gcc commits from yesterday and without 99350 and 99352 Oct 27 07:21:47 and now I'll have new SRCREV + new linaro patches from yesterday but still without 99350 Oct 27 07:22:14 but upgrading all + image build will take much longer than gcc-cross rebuild.. Oct 27 07:22:28 so good night I guess :) Oct 27 07:23:03 heh Oct 27 07:23:07 well wait Oct 27 07:23:31 pin down the patch before you rebuild all Oct 27 07:24:00 I guess mostly its 99350 Oct 27 07:24:11 but test it and let me know Oct 27 07:24:16 now I will sleep Oct 27 07:24:23 but I will read back log Oct 27 07:24:51 yes as I said I'm building it WITHOUT 99350 Oct 27 07:25:51 if it still works I'll upload workdir (cairo+gcc) somewhere and then build broken version and upload it too Oct 27 08:11:29 My recipe compiles now, but on target I just end up with an egg in my site-packages. What do I inherit/do to make OE put the unpacked egg in the ipk instead? Oct 27 09:14:14 good morning Oct 27 09:14:20 mickey|zzZZzz: ping Oct 27 09:19:30 good morning Oct 27 09:19:36 hi mckoan Oct 27 09:20:05 florian: are you in UK? Oct 27 09:21:20 mckoan: no, I'll arrive there tomorrow Oct 27 09:22:45 * stefan_schmidt will arive at 8 pm Oct 27 09:22:56 Do we have a start time for friday? Oct 27 09:26:24 Could someone please take a look at http://pastebin.com/i1GLEJRg. It's my attempt at a recipe for pythonbindings for libconfig and have a few issues. Oct 27 09:28:35 It compiles, but gives me only an egg in dist-packages on target, and when I try to install it, I have a problem with a missing pyconfig.h. Oct 27 10:48:47 * tasslehoff drops a pin Oct 27 10:52:07 * tdebrouw picks up the pin and gives it back to tasslehoff Oct 27 10:53:39 khem: found it.. minimal needed change is http://gitorious.org/~jama/angstrom/jama-shr-experimental/commit/4c5ba23356753302d719cbee4a47984cc694b00c Oct 27 10:57:28 thanks tdebrouw :) Oct 27 10:58:11 np Oct 27 10:59:04 hrw: maybe you would be also interested ^^ gcc-4.5/linaro/gcc-4.5-linaro-r99350.patch is causing wrong rendering with libcairo (noticed on n900 in vala-terminal) Oct 27 11:09:47 JaMa: can any such problem be reported to linaro-toolchain@lists.linaro.org? this is easiest way to get us to notice Oct 27 11:10:40 JaMa: plus some description Oct 27 11:13:35 JaMa: report bug in launchpad against gcc-linaro. will give you a link Oct 27 11:15:53 JaMa: https://bugs.edge.launchpad.net/gcc-linaro Oct 27 11:16:15 * hrw just woke up and forgot that LP has bugtracker ;D Oct 27 11:17:16 I've found it already.. but waiting for khem to report it or even fix it :) Oct 27 11:17:36 ok Oct 27 11:18:01 ~hail Intel for making Yectoproject Oct 27 11:18:02 * ibot bows down to Intel for making Yectoproject and chants, "I'M NOT WORTHY!!" Oct 27 11:18:25 khem: here are workdirs (gcc+cairo) from both builds http://jama.homelinux.org/libcairo.working/ http://jama.homelinux.org/libcairo.broken/, only diff is that commit I've sent you Oct 27 11:19:07 what's Yectoproject? Oct 27 11:19:30 Poky based build system Oct 27 11:19:38 heh, I were typing the same question ;) Oct 27 11:19:46 with Intel, Windriver, Linux Foundation behind Oct 27 11:19:56 ~curse Google for not knowing Yectoproject Oct 27 11:19:57 hrw: link? Oct 27 11:19:57 May the fleas of a thousand camels infest your most sensitive regions, Google for not knowing Yectoproject ! Oct 27 11:20:07 yectoproject.org? Oct 27 11:20:21 moemnt Oct 27 11:20:47 yoctoproject.org sorry Oct 27 11:20:55 hrw: are you sure you are allowed to talk about it yet? ;) Oct 27 11:21:03 florian: its public Oct 27 11:21:34 florian: it got announced at elc-e iirc Oct 27 11:21:57 hrw: don't take me too serious Oct 27 11:22:43 florian: sorry, I am pernamently jeglagged this week Oct 27 11:22:57 today is first day when I slept more then 6h Oct 27 11:23:15 hrw: hey :) Oct 27 11:24:05 hrw: can you blog more about kexec session on UDS? :) Oct 27 11:24:34 Jay7: I skipped that session Oct 27 11:24:38 ah.. Oct 27 11:24:50 he.. I can ask this on right channel Oct 27 11:25:28 Jay7: use gobby-0.5 or kobby and connect to gobby.ubuntu.com and check were there any notes taken Oct 27 11:25:44 Jay7: or contact persons from kexec's blueprint Oct 27 11:25:57 ok, thank you Oct 27 11:26:57 np Oct 27 11:29:18 yocto has been seen on twitter Oct 27 11:29:38 Crofton: yes, thats how I got it Oct 27 11:29:50 following Dirk was good move Oct 27 11:29:56 vary curious Oct 27 11:30:06 very curious Oct 27 11:30:14 may battery is low Oct 27 11:32:32 https://lists.yoctoproject.org/pipermail/yocto/2010-October/000128.html Oct 27 11:36:20 Now I have something working for the recipe I've been talking to myself about all day. Python bindings for libconfig. Is this a recipe I should send to the mailing list, or should I just use it for my own entertainment? Oct 27 11:37:04 tasslehoff: share Oct 27 11:37:04 Google told me about a github-repo, and I created a recipe for it, No idea how "official" a software-source must be Oct 27 11:37:12 hrw: ok Oct 27 11:38:27 see my twitter exchange with Dirk H Oct 27 11:38:30 looks sane Oct 27 11:38:32 bye Oct 27 11:38:35 dead battery Oct 27 12:11:11 khem: both bziped workdirs also uploaded to http://build.shr-project.org/tests/jama/ for faster download and in case my desktop is offline when you wake up :) Oct 27 12:29:53 03Stefan Schmidt  07master * re26b2a58df 10openembedded.git/recipes/obsolete/e17/bubble-keyboard_svn.bb: Oct 27 12:29:53 bubble-keyboard: Move to obsolete Oct 27 12:29:53 * The domain is down and will not come back. Talked to the admin. Oct 27 12:29:53 * The software was not updated for all kind of EFL API changes. Oct 27 12:29:53 Signed-off-by: Stefan Schmidt Oct 27 12:30:04 03Stefan Schmidt  07master * r05baf32a73 10openembedded.git/recipes/obsolete/efl1/libefso_svn.bb: Oct 27 12:30:04 libefso: Move to obsolete Oct 27 12:30:04 * The domain is down and will not come back. Talked to the admin. Oct 27 12:30:04 * The software was not updated for all kind of EFL API changes. Oct 27 12:30:04 Signed-off-by: Stefan Schmidt Oct 27 12:30:04 03Stefan Schmidt  07master * r8711d05721 10openembedded.git/recipes/obsolete/e17/essential-dialer_svn.bb: Oct 27 12:30:05 essential-dialer: Move to obsolete Oct 27 12:30:06 * The domain is down and will not come back. Talked to the admin. Oct 27 12:30:06 * The software was not updated for all kind of EFL API changes. Oct 27 12:30:07 Signed-off-by: Stefan Schmidt Oct 27 12:30:07 03Stefan Schmidt  07master * r1987b1d48e 10openembedded.git/recipes/obsolete/e17/intuition_svn.bb: Oct 27 12:30:08 intuition: Move to obsolete Oct 27 12:30:08 * The domain is down and will not come back. Talked to the admin. Oct 27 12:30:09 * The software was not updated for all kind of EFL API changes. Oct 27 12:31:03 Signed-off-by: Stefan Schmidt Oct 27 12:33:21 03Stefan Schmidt  07master * rbb18d20f7e 10openembedded.git/recipes/ (5 files in 2 dirs): Oct 27 12:33:21 bubble-keyboard/essential-dialer/gridpad/intuition/libefso: Remove, moved to Oct 27 12:33:21 obsolete. Oct 27 12:33:21 My git-fu failed here for moving, sorry. Oct 27 12:33:21 Signed-off-by: Stefan Schmidt Oct 27 14:19:30 morning Oct 27 14:20:10 yes Oct 27 14:21:30 sadly Oct 27 14:22:10 yeah, yesterday it only was 24 hours and now it is today Oct 27 14:22:42 kergoth: just got back into OE, lots of changes, looks all to be to the good. Oct 27 14:26:44 T0mW: you might be interested in the Testing effort (see the wiki page) -- its helping to give people a more sane baseline to start work from, since there are machine/distro combinations which are known to be good with the testing branch Oct 27 14:27:32 * kergoth grumbles Oct 27 14:28:03 efforts like that one are starting to help improve the stability of it, though i still think we need to start doing actual twice a year releases Oct 27 14:28:07 heh Oct 27 14:28:30 03Klaus Kurzmann  07org.openembedded.dev * rab550dc105 10openembedded.git/recipes/freesmartphone/frameworkd_git.bb: Oct 27 14:28:30 frameworkd_git.bb: bump SRCREV for new opimd with New instead of MessageRead Oct 27 14:28:30 Signed-off-by: Klaus Kurzmann Oct 27 14:28:32 kergoth: Yeah, I'll look into that. What burned me before in using OE was the dev branch. Too much had been broken. Finally, I discovered that OE had branches and switched to stable. Oct 27 14:29:06 yeah, thats pretty common, sadly, there's a lot of churn and too many distros and machines for any one person, even the person making a given change, to fully test i Oct 27 14:29:10 t Oct 27 14:29:30 hopefully we get more automated builds going, that would help a loot Oct 27 14:29:32 lot Oct 27 14:29:36 * kergoth gets caffeine Oct 27 14:31:00 kergoth, gm Oct 27 14:34:54 hey Crofton Oct 27 14:35:02 hi Oct 27 14:35:46 hrm, wtf, FATAL: Task /home/kergoth/Code/oe/projects/parallel/openembedded/recipes/schroedinger/schroedinger_0.2.0.0.bb (do_package) has circular dependency on /home/kergoth/Code/oe/projects/parallel/openembedded/recipes/gstreamer/gst-plugins-base_0.10.23.bb (do_package) Oct 27 14:35:51 * kergoth pulls Oct 27 14:38:26 kergoth: IIRC, problems I had a few years ago were old / abandoned machines that were broken in the recipes. Oct 27 14:39:27 while learning OE, I had the devil's own time of it trying to get something to fully build. The release idea is good. Oct 27 14:39:51 well here's hoping it goes better for you this time around :) Oct 27 14:40:22 IOW, if you ain't maintaining your machine / distro, it gets dropped from the release. You would have to actively participate in the specific release to get your machine / distro "in there". Oct 27 14:41:15 yeah, that would be nice. ideally, i think we'd do the same for recipes -- responsibility and accountability for the metadata all around would be nice Oct 27 14:41:38 the problem is we would run out of people .... Oct 27 14:41:42 kergoth: heh, yes! I've a proposal to write, deadlines to specify and money to get paid me! Today, I'm doing the prelim work to ensure that I can still use OE for my new design. Oct 27 14:42:38 well, IMHO, one huge weakness is the local.conf Oct 27 14:43:58 i think the real underlying problem for local.conf usage is the lack of discoverability. there are all these variables, and there's no good way to say "okay, what exactly *can* I set?", short of looking at commented out entries in local.conf.sample, which is hardly definitive Oct 27 14:45:47 yes, target systems would need representative local.conf files. The local.conf should tell you, specifically, what board it is for. That way it is not only turnkey, but, it would allow someone like myself to go out on the net and find a board close to what I have, then select the local.conf close to it as a start. Oct 27 14:46:16 well, OE is structured by design to consist of particular orthogonal features Oct 27 14:46:31 if you can't pick a distro and pick a machine and go, its a bug in the distro or machine configuration files Oct 27 14:46:45 you shouldn't need a pre-set local.conf for a machine, thats what the machine.conf is for Oct 27 14:47:10 *somebody* wrote the machine.conf for a specific use. They selected / built a distro.conf, but, when the machine.conf gets submitted, the association with the distro.conf gets lost. Oct 27 14:47:31 that's exactly my point. that association shouldn't exist. Oct 27 14:47:45 well, not hard-coded, no. Oct 27 14:48:02 the only association is from a testing standpoint -- has it been tested Oct 27 14:48:52 Um, I'll look at the testing and look around the wiki. Probably this is now a non-issue and I'm just wasting time talking about past issues. Oct 27 14:49:06 hopefully :) Oct 27 14:49:42 odd, "NOTE: This package has no checksums, please add to recipe", that was linux-2.6.25 kernel source Oct 27 14:50:38 sounds like a machine that needs some love. the old checksums mechanism, where we had a checksums.ini file with everything, is gone, in favor of putting the checksums in the recipe as attributes of the SRC_URI Oct 27 14:50:54 you're living in the past man! 2.6.36 is where it's at! :P Oct 27 14:51:00 hehe Oct 27 14:51:38 ah Oct 27 14:51:45 makes sense Oct 27 14:52:00 kergoth: yeah, old bb files Oct 27 14:52:19 you can just copy/paste the snippet it gives you into the recipe to fix it Oct 27 14:52:41 yes Oct 27 14:53:15 checksum.ini must have been a nightmare to keep upto date Oct 27 14:53:46 oh yeah, and it was a point of merge conflict headaches due to being one place where every new recipe had to touch Oct 27 14:54:13 mrj10: soon Oct 27 14:55:49 there was a weird thing with tasks vs images, IIRC, sometimes you had to rebuild the task to get changes into the image (e.g. bitbake -c rebuilt task-base ; bitbake base-image) Oct 27 14:55:58 that still exist? Oct 27 14:57:29 I'm assuming that the tasks build out the image contents and then images are assembled as separate steps (two steps to build a target set of images) Oct 27 14:58:10 anyone know the bitbake command to totally purge all tarballs, temporary build files, etc. for a package (recipe)? Oct 27 14:58:48 isn't that 'bitbake -c clean ' ? Oct 27 14:58:50 a fix for a problem i was having got committed to OE master last night, but i think the build system isn't picking up all the changes, and it's not applying one of the makefile patches that was there before the change last night Oct 27 14:59:12 nm Oct 27 14:59:20 i've tried -c clean and the problem doesn't go away, it doesn't look like i'm redownloading any tarballs so might there be a deeper level of "clean"? Oct 27 14:59:29 clean doesn't remove the tarball Oct 27 15:00:16 i dont think i should *actually* need to refetch the tarball, but i do want it to totally get rid of the directory under build/tmp_/work/armv7a/clxclient Oct 27 15:02:41 AFAIK, clean should remove the source in /tmp, you would have to manually delete the tarball from sources Oct 27 15:03:10 let's try that, thanks Oct 27 15:03:23 mrj10: but I see what you mean, if the bb file specifies more than one tarball... Oct 27 15:04:28 you would get /tmp cleaned up, but cannot remove all the tarballs unless you look at the bb Oct 27 15:07:31 yeah, there is "clean" and "distclean" in /classes, maybe there should be an "allclean" ? heh Oct 27 15:16:01 could someone take a look at the clthreads recipe (recipes/jaaa/clthreads_2.4.0.bb) and fix the hardcoded paths to install and ldconfig and whatnot? Oct 27 15:16:16 it's hardcoded to use /usr/bin/install instead of the sysroot versions Oct 27 15:16:29 i'd do it if i knew the OE environment variables better Oct 27 15:17:42 oh Oct 27 15:18:11 maybe that's my problem too.. do you not have /usr/bin/install, or does it just do something different than the sysroot one? Oct 27 15:18:55 i have /bin/install instead of /usr/bin/install, but either way, it's breaking the encapsulation of OE Oct 27 15:19:16 that definitely shouldn't be hardcoded Oct 27 15:20:17 oh, its a problem for sure, i'm just wondering if that might also be causing any problems for me, i'm having issues with jaaa Oct 27 15:20:27 very well could be Oct 27 15:22:16 the OE recipe for clxclient has a patch for the makefile that changes some stuff with how "make install" works Oct 27 15:22:42 and now jaaa, which depends on clxclient, has trouble compiling because it can't find one of the headers clxclient was supposed to install in sysroots/bla/usr/include Oct 27 15:28:26 hmm Oct 27 15:28:43 gotta ask someone more knowledgeable, sorry :( Oct 27 15:29:26 vorporeal: should definitely fix that to use 'install' from the path, absolutely Oct 27 15:30:52 kergoth_: i'd do it if i knew the OE variables to use - i just changed the hardcoded path to point to the right install... :-/ Oct 27 15:31:06 you don't need to use an oe variable at all. Oct 27 15:31:11 just make it use the one in the path Oct 27 15:31:18 OE adjusts PATH to include the sysroots Oct 27 15:31:33 change /usr/bin/install to 'install' Oct 27 15:31:43 kergoth_: ah, really? good to know, thanks. Oct 27 15:32:09 also, it calls /sbin/ldconfig - should that be changed to just ldconfig or removed or what? Oct 27 15:34:29 we don't want ldconfig being run at all, its unnecessary for a non-native build Oct 27 15:38:43 I'm trying oe for the first time. I'm trying to do 'bitbake nano' and I'm getting a bunch of errors. http://georgem.pastebin.com/gghQRPjS Oct 27 15:39:31 so what's the opinion on yocto so far? Oct 27 15:39:47 georgem: odd, what bitbake version is that? Oct 27 15:40:03 kergoth_: bitbake-1.8.18 Oct 27 15:40:16 kergoth: looks quite interesting... mostly for the framework. Oct 27 15:41:26 kergoth: not sure if i like the relationship oe->poky->yocto but so far the oe+poky combination wasn't too bad Oct 27 15:41:40 well, for a long while there poky wasn't getting much love upstream Oct 27 15:41:49 i'm hoping that there'll be more oe<->poky syncs going forward Oct 27 15:41:53 so it might not be so bad Oct 27 15:42:21 there will Oct 27 15:43:18 i do worry about the syncing, as someone who's had to manage the syncing between oe and mvl6, i know what a gigantic pain in the ass it is Oct 27 15:43:20 georgem: I'm just getting started, again, with OE and I've no problems with bitbake-1.10.1 Oct 27 15:43:22 we need to do something to make it easier Oct 27 15:43:39 git sucks at managing cherry picks in long lived branches, so that's not the answer Oct 27 15:43:39 kergoth: it pretty much looks like there will be more soon :) Oct 27 15:44:56 at least yocto doesn't seem to be terribly wrapped up in governance, seems like some projects that involve steering committees and working gruops and crap never actually end up *working* Oct 27 15:45:00 heh Oct 27 15:45:12 doh Oct 27 15:45:41 * T0mW has had a few projects die due to "committee" Oct 27 15:45:56 but maybe i'm just biased, meego and the like haven't particularly impressed me Oct 27 15:47:08 I guess I'll try bitbake-1.10.1 Oct 27 15:48:04 there're also some subtle differences between the poky and oe classes these days which makes the merging less trivial Oct 27 15:48:07 georgem: let us know if that fixes it, if 1.8 is busted somehow, we need to fix it, clearly Oct 27 15:48:09 but we will work around this Oct 27 15:48:14 incandescant: yeah, thats worrisome to me Oct 27 15:48:29 ideally we'd be able to pick and choose recipes from any collection of oe based metadata anywhere :\ Oct 27 15:48:37 we need to start doing class versioning or something Oct 27 15:48:50 or teach the parser to use local classes, prefer whats in its own collection Oct 27 15:48:53 the differences should stop recipes working Oct 27 15:49:05 shouldn't, that is Oct 27 15:49:31 well, as soon as the final bits of checksums.ini support go away, that kills compatibility with some older third party collections Oct 27 15:49:36 just one example Oct 27 15:49:46 true Oct 27 15:49:57 morning kergoth Oct 27 15:50:31 hey pb_ Oct 27 15:51:42 incandescant: i don't know what the right answer is, but its something i think needs more thought and discussion as a general problem Oct 27 15:52:04 bitbake is done in Python, right? Which version are you supposed to have? Is 2.6.2 acceptable? Oct 27 15:52:22 georgem: python 2.5 is required for 1.10.x, 2.6 is required for the master branch Oct 27 15:52:30 kergoth_: agreed, I'll make a note of that here so I can push it form our side Oct 27 15:52:32 1.8 probably still works with 2.4, not sure offhand Oct 27 15:52:44 georgem: so yes, you're fine :) Oct 27 15:53:10 Still giving me those same errors. *shrug* Oct 27 15:53:22 try master? Oct 27 15:53:29 * kergoth_ can't reproduce that Oct 27 15:54:24 gah, i really need a whiteboard Oct 27 15:54:29 home office sucks without one Oct 27 15:54:46 * kergoth_ is failing at keeping all the crap he's working on in his head, things are falling out Oct 27 15:55:02 Ugh. I hate when that crap happens. Stresses me the F out Oct 27 15:56:25 * georgem suggests bulk purchase of Post-It notes. Oct 27 15:58:26 * incandescant suggests pens that write on the window Oct 27 15:58:53 Maybe my local.conf isn't valid? http://georgem.pastebin.com/UCmw9CK4 Oct 27 16:00:00 kergoth: just write the long-term items directly on the wall Oct 27 16:00:50 hmm... the wall is closer than any window :-) Oct 27 16:01:37 hrm, a lot of python recipes are failing due to trying to access host libraries Oct 27 16:04:24 Is there an oe tutorial for building oe to running on VirtualBox, or something like that? Oct 27 16:05:05 georgem: there are a couple qemu machines Oct 27 16:05:08 not sure about virtualbox or vmware Oct 27 16:06:14 virtualbox should be able to run 'qemux86' image Oct 27 16:39:36 damnit, something went crazy wrong when the cy8mrln-palmpre folks merged with current tslib master Oct 27 16:39:50 had to revert the branch to the old state to fix the github repo Oct 27 18:50:53 03Khem Raj  07master * re65b9b41ae 10openembedded.git/recipes/jaaa/clxclient_3.6.1.bb: Oct 27 18:50:53 clxclient_3.6.1.bb: Implement do_install Oct 27 18:50:53 Signed-off-by: Khem Raj Oct 27 18:51:22 hi all Oct 27 18:52:06 hey khem Oct 27 18:52:19 ah, just saw that, i was having trouble with do_install this morning Oct 27 19:03:47 03Chris Larson  07master * r9bae7ad287 10openembedded.git/recipes/ed/ed.inc: Oct 27 19:03:47 ed: fix build issue, fix install Oct 27 19:03:47 Signed-off-by: Chris Larson Oct 27 19:04:02 03Chris Larson  07master * rae8e07433d 10openembedded.git/recipes/lzip/lzip_1.11.bb: Oct 27 19:04:02 lzip: fix install Oct 27 19:04:02 Signed-off-by: Chris Larson Oct 27 19:04:02 khem: hi Oct 27 19:04:18 ugh, the 'dt' upstream is annoying Oct 27 19:04:29 just one tarball for the latest, no version in the filename, no old versions Oct 27 19:05:00 re Oct 27 19:05:01 hey kergoth Oct 27 19:05:19 JaMa: hi Oct 27 19:05:21 khem: i am now able to get clxclient to build successfully, but now when i try to build jaaa (which depends on clxclient and a couple others), it complains about not being able to find libpthread Oct 27 19:05:37 (i'm cross-compiling, target is beagleboard xm, host is x86_64) Oct 27 19:05:44 googling like crazy trying to find the old versions to try to construct a history, not having much luck Oct 27 19:05:53 hrmph Oct 27 19:06:04 hmm, curl-nativesdk is looking for a gcc binary that doesn't exist Oct 27 19:06:05 kergoth: do we really need dt :) Oct 27 19:06:17 it looks like the sysroots/armv7.../usr/lib is not getting added to the library search path Oct 27 19:06:23 vorporeal: yes this should be disabled for time being Oct 27 19:06:43 mrj10: which recipe exactly are you building Oct 27 19:06:45 khem: no idea, just annoyed on general principle Oct 27 19:06:46 khem: how would i do that? Oct 27 19:06:46 :) Oct 27 19:07:23 i assume it's not quite as simple as commenting it out of a recipe Oct 27 19:08:18 vorporeal: look in recipe and see BBCLASSEXTEND Oct 27 19:08:25 remove nativesdk from lis Oct 27 19:08:54 JaMa: did u conclude on the patch ? Oct 27 19:09:08 khem: on the way to building recipes/images/beagleboard-demo-image.bb . beagleboard-demo-image.bb depends on tasks/task-beagleboard-demo.bb which depends on jaaa which depends on clxclient Oct 27 19:09:14 khem: yes and wrote here all the info Oct 27 19:09:16 khem: http://pastebin.com/kp3rMStM Oct 27 19:09:38 khem: got it, thanks. also, i'm running into issues with a number of python packages (python-fuse, python-numeric) where they're looking for files in /usr/lib Oct 27 19:09:57 digged through a bunch of recipes and classes and found nothing useful Oct 27 19:09:59 khem: that was the relevant part of the output of "bitbake jaaa" Oct 27 19:10:23 vorporeal: are they inheriting distutils ? if not then try to inherit that Oct 27 19:11:20 khem: yeah, they are Oct 27 19:23:20 JaMa: so its 99350 thats the culprit Oct 27 19:23:40 JaMa: now is there a way to reduce the issue in cairo somehow Oct 27 19:29:15 khem: is this another recipe where it shouldn't be inheriting autotools? i'm not quite sure what that class does. i'm trying a couple hacks to the recipe to see if i can get it to work, but it's stabs in the dark for now Oct 27 19:30:20 khem: well all I can see different with broken cairo is all fonts rendered wrong.. but not sure if it's only in fonts as I don't know about other testcase for it then vala-terminal.. Oct 27 19:34:13 is it just me or is the u-boot git repository broken? Oct 27 19:34:44 JaMa: we using soft float ABI right for cairo and -O2 ? Oct 27 19:35:28 i'm trying u-boot_git.bb and getting "fatal: Not a valid object name 1" Oct 27 19:36:22 vorporeal: SRCREV is missing for you machine Oct 27 19:37:18 got it, thanks Oct 27 19:37:59 JaMa: dont delete the workspace yet Oct 27 19:38:07 JaMa: I might ask you to try few things Oct 27 19:38:13 jesus, the version string in the latest dt tarball from upstream is of 2007 Oct 27 19:38:21 its almost liek they resurrected an old version and replaced the current one Oct 27 19:38:30 ridiculous Oct 27 19:38:53 also, the web page claims 15.14 is the latest, while i just downloaded 16.19 from elsewhere Oct 27 19:41:50 mrj10: can you test a patch ? Oct 27 19:42:21 yeah Oct 27 19:42:57 mrj10: http://pastebin.com/ZqiC9jnF Oct 27 19:43:10 apply it then bitbake -c clean jaaa;bitbake jaaa Oct 27 19:43:54 kergoth: dt is funny, yeah.. Oct 27 19:44:05 I thought I had it building properly in oe.dev tho Oct 27 19:44:13 might have forgotten to fix S Oct 27 19:44:44 Tartarus: latest is busted again, current upstream tarball is WIP and shows a usage version string of 15.34. Oct 27 19:45:22 So they didn't listen to me, sigh Oct 27 19:45:58 and the website still claims latest is 15.14.. somebody needs to learn how to maintain software Oct 27 19:46:02 * kergoth rolls eyes Oct 27 19:46:41 khem: testing now; incidentally, that was the hack i mentioned before, i just copy-pasted what you had done to clxclient last night Oct 27 19:47:26 kergoth: I use xeyes Oct 27 19:47:31 to roll Oct 27 19:47:42 hehe Oct 27 19:51:21 JaMa: can you test a patch Oct 27 19:51:30 JaMa: w.r.t cairo issue Oct 27 19:51:51 sure Oct 27 19:52:17 ok lemme hack it up quickly Oct 27 19:52:23 gimme 2 mins Oct 27 19:52:51 who the hell staged ctl_macros.h Oct 27 19:53:09 * khem is hunting for the responsible recipe Oct 27 19:53:40 if i'm inheriting a do_configure_prepend() function from an .inc file and i want to append something onto there (without changing the .inc file), what's the syntax? Oct 27 19:53:49 can't be do_configure_prepend_append, right? Oct 27 19:55:33 you cant modify an _append Oct 27 19:55:35 at all, period Oct 27 19:55:39 _append isn't the name of the variable Oct 27 19:55:41 its an *operation* Oct 27 19:55:52 you can have any n umber of _append definitions, and they don't override one another Oct 27 19:55:54 they all get appended Oct 27 19:56:56 JaMa: replace 99350 patch with this one http://pastebin.com/9Lf3EH1n and repeat your experiment Oct 27 19:57:59 JaMa: its completely untested but lets see if it works Oct 27 19:58:52 kergoth: interesting. for education purposes, what is that a feature of? (trying to slowly figure out how this all works) Oct 27 19:59:22 Where is the source to the kernel for an image stored in OE? Oct 27 19:59:40 guys, where's the dir used to build my packages, with all patches applied? Oct 27 19:59:53 RobotGuy: $WORKDIR Oct 27 20:00:21 fidencio: see above its the workdir which is under ${TMPDIR}/work Oct 27 20:00:49 khem: patch worked :) Oct 27 20:00:49 and ${TMPDIR}/work// Oct 27 20:00:56 mrj10: ok thx Oct 27 20:00:59 khem, There is no $WORKDIR set on my system. Oct 27 20:01:11 khem: ok, thanks Oct 27 20:02:18 khem: so does the autotools bbclass set up a bunch of macros for native builds, which screws you up if you're trying to cross-compile a package? Oct 27 20:02:34 RobotGuy: read my answer to fidencio Oct 27 20:03:07 mrj10: well you dont use autotools for a recipe that does not use autotools that just braindead Oct 27 20:03:16 khem: isn't there the source file patched, just run.* and log.* files Oct 27 20:03:33 fidencio: you must have rm_work in your INHERITS Oct 27 20:03:51 fidencio: you can still do bitbake -b -c patch Oct 27 20:04:05 and it will create the patched src tree in the very same location Oct 27 20:04:27 me is perplexed with scim Oct 27 20:04:33 khem: ok Oct 27 20:05:58 kergoth: is this patch here http://patchwork.openembedded.org/patch/1023/ applied to bb master Oct 27 20:06:40 khem: dont think so Oct 27 20:06:44 haven't looked at that one Oct 27 20:07:19 kergoth: seems sane to me Oct 27 20:07:20 patching file gcc/testsuite/gcc.target/arm/neon-load-df0.c Oct 27 20:07:20 patch unexpectedly ends in middle of line Oct 27 20:07:20 patch: **** malformed patch at line 184: Oct 27 20:07:24 khem ^ Oct 27 20:07:40 JaMa: weird Oct 27 20:07:51 let me upload it to somplace Oct 27 20:08:41 03Chris Larson  07master * rd79f536f2b 10openembedded.git/recipes/dt/dt_15.14.bb: Oct 27 20:08:41 dt: rename to 17.07 Oct 27 20:08:41 The current version upstream, which matches our checksums, is version 17.07, Oct 27 20:08:41 not 15.14. Oct 27 20:08:41 Signed-off-by: Chris Larson Oct 27 20:09:15 JaMa: from this location http://uclibc.org/~kraj/gcc-4.5-linaro-r99350.patch Oct 27 20:09:53 khem, I know where the 'work' dir is, but knowing this does not help me find where the linux source for builds would be. Oct 27 20:10:09 bitbake -e virtual/kernel | grep \^S= Oct 27 20:10:12 there's your kernel source Oct 27 20:10:23 RobotGuy: do "bitbake -c patch" Oct 27 20:10:46 vorporeal, OK, will try that. Thanks. Oct 27 20:10:48 then dig through the //work folders for it Oct 27 20:10:59 khem: after redownload it's the same Oct 27 20:11:03 just do the -e i suggested to get the tree after doing the patch Oct 27 20:11:14 khem: but it did apply now :/ Oct 27 20:11:35 strange, looks like \n in the end of file was needed Oct 27 20:11:43 khem: fyi i now get the entire image to build with no errors, including jaaa. thanks so much for your help. now to collect up the source patches i had to come up with last night to get the TI kernel modules to build Oct 27 20:14:52 khem: I'm using as PREFERRED_PROVIDER_virtual_bootloader = "u-boot-imx" and I have set EXTRA_IMAGEDEPENDS += "u-boot" Oct 27 20:15:16 khem: When I build the image that should compile oe-imx, the recipe is never called Oct 27 20:15:33 s/oe-imx/u-boot-imx Oct 27 20:16:43 khem: isn't this the expected behavior, right? Oct 27 20:18:17 fidencio: EXTRA_IMAGEDEPENDS += "u-boot" is not needed if you want something else to be your bootloader Oct 27 20:19:14 and you should set PREFERRED_PROVIDER_virtual/bootloader = "u-boot-imx" Oct 27 20:20:00 is it, virtual_bootloader was a typo Oct 27 20:20:19 fidencio: ok then you might have to add _local override to it Oct 27 20:20:29 fidencio: which machine is it Oct 27 20:21:37 khem: babbage Oct 27 20:22:41 fidencio: ok this has PREFFERED_PROVIDER_virtual/bootloader defined Oct 27 20:23:04 so you might set PREFFERED_PROVIDER_virtual/bootloader_local = "u-boot-imx" Oct 27 20:23:24 in local.conf if you dont want to edit conf/machine/babbage.conf Oct 27 20:23:47 khem: ok. I'll try. thanks Oct 27 20:24:43 khem: ah, when you sayd: "something else to be your bootloader", this "something else" can be my u-boot-imx recipe, right? Oct 27 20:24:54 yes Oct 27 20:44:09 khem: with that patch, cairo is still broken, should I upload workdir from it? Oct 27 20:44:30 JaMa: no need Oct 27 20:58:37 03Chris Larson  07master * r8759bb71e5 10openembedded.git/ (4 files in 2 dirs): Oct 27 20:58:37 which: add recipe, versions 2.17 and 2.20 Oct 27 20:58:37 2.17 is the most recent version which was still GPLv2+, and 2.20 is the latest Oct 27 20:58:37 which is now GPLv3+. Oct 27 20:58:37 Signed-off-by: Chris Larson Oct 27 20:58:41 03Chris Larson  07master * rf6df8a4cc7 10openembedded.git/ (MAINTAINERS recipes/cwautomacros/cwautomacros_20090610.bb): Oct 27 20:58:41 cwautomacros: add recipe, version 20090610 Oct 27 20:58:42 Signed-off-by: Chris Larson Oct 27 20:59:16 JaMa: hmmm this patch does not seem to do what it is supposed to do Oct 27 20:59:19 even Oct 27 21:04:09 JaMa: around ? Oct 27 21:04:34 can you compile this small example and paste the .s file for me plz Oct 27 21:05:03 double x; void bar () Oct 27 21:05:16 { x = 0.0; ) Oct 27 21:06:20 compile with arm-oe-linux-gnueabi-gcc -mfpu=neon -mfloat-abi=softfp -march=armv7-a -S -O3 Oct 27 21:10:53 khem: was that close-paren correct or a typo? Oct 27 21:11:39 typo ofcourse when I am asking for asm Oct 27 21:13:04 sure mmt Oct 27 21:16:48 ...true. Oct 27 21:17:02 03Denis 'GNUtoo' Carikli  07master * r7d66ee089b 10openembedded.git/ (conf/machine/nokia900.conf recipes/tasks/task-boot.bb): Oct 27 21:17:02 nokia900: add keyboard to MACHINE_FEATURES, watchdog to MACHINE_EXTRA_RRECOMMENDS and autoload for g_ether Oct 27 21:17:02 Signed-off-by: Martin Jansa Oct 27 21:17:06 03Klaus Kurzmann  07master * rd838df9eac 10openembedded.git/recipes/keymaps/ (files/nokia900/keymap-2.6.map keymaps_1.0.bb): Oct 27 21:17:06 keymaps: add keymap for the nokia900 Oct 27 21:17:06 bump PR of task-base and task-boot to pickup keyboard for nokia900 Oct 27 21:17:06 Signed-off-by: Klaus Kurzmann Oct 27 21:17:07 Signed-off-by: Martin Jansa Oct 27 21:17:07 03Klaus Kurzmann  07master * ra8d15196e9 10openembedded.git/recipes/udev/ (5 files in 2 dirs): Oct 27 21:17:08 udev_151.bb: add rules for nokia900 Oct 27 21:17:08 Signed-off-by: Klaus Kurzmann Oct 27 21:17:09 Signed-off-by: Martin Jansa Oct 27 21:17:09 03Denis 'GNUtoo' Carikli  07master * ref13e630b1 10openembedded.git/recipes/netbase/ (netbase/nokia900/interfaces netbase_4.21.bb): Oct 27 21:17:10 netbase: add nokia900 support Oct 27 21:17:10 Signed-off-by: Martin Jansa Oct 27 21:17:20 03Martin Jansa  07master * r9b49b9b643 10openembedded.git/recipes/xorg-xserver/xorg-xserver-common.inc: Oct 27 21:17:24 xorg-xserver-common: use udev for SHR as DISTRO_XORG_CONFIG_MANAGER Oct 27 21:17:24 * libudev dependency doesn't hurt so much Oct 27 21:17:24 * usefull for other supported machines than gta0[12] Oct 27 21:17:24 Signed-off-by: Martin Jansa Oct 27 21:17:24 03Martin Jansa  07master * r3648dfb64d 10openembedded.git/recipes/images/shr-image.inc: Oct 27 21:17:24 shr-image: remove IMAGE_DEV_MANAGER only for om-gta0[12] Oct 27 21:17:25 Signed-off-by: Martin Jansa Oct 27 21:17:25 03Martin Jansa  07master * rcf31c66718 10openembedded.git/recipes/base-files/ (3 files in 3 dirs): (log message trimmed) Oct 27 21:17:26 base-files: add empty /etc/profile.d which can be filled by distro/machine profile scripts Oct 27 21:17:26 * used for gtk_im_module.sh in SHR Oct 27 21:17:27 * would be better to be able to fill it from more sources (maybe put profile.d.machine, profile.d.distro, profile.d directories Oct 27 21:17:31 and install all files to target profile.d), is it worth it? Oct 27 21:17:31 * /etc/profile.d/empty is used to prevent install call not failing because /profile.d/* not found Oct 27 21:17:31 Acked-by: Chris Larson Oct 27 21:17:31 03Martin Jansa  07master * rc5e497e23f 10openembedded.git/recipes/webkit/webkit-efl_svn.bb: Oct 27 21:17:31 webkit-efl: bump SRCREV a bit and add ${datadir}/ewebkit-0/theme/default.edj to package Oct 27 21:17:31 Signed-off-by: Martin Jansa Oct 27 21:17:46 gnutls: move to latest stable branch 2.10.1 -> 2.10.2 Oct 27 21:17:46 * needed by new ecore http://trac.enlightenment.org/e/changeset/53910 Oct 27 21:17:46 Signed-off-by: Martin Jansa Oct 27 21:17:46 03Martin Jansa  07master * rb438806310 10openembedded.git/recipes/efl1/edje_svn.bb: Oct 27 21:17:47 edje: add inkscape2edc to PN-utils Oct 27 21:17:48 Signed-off-by: Martin Jansa Oct 27 21:17:49 03Martin Jansa  07master * r95b93b09bb 10openembedded.git/recipes/efl1/edbus_svn.bb: Oct 27 21:18:20 edbus: improve packaging Oct 27 21:18:20 * add e-notify-send to PN-enotify Oct 27 21:18:20 * package each lib separate as used for hal/dbus Oct 27 21:18:20 Signed-off-by: Martin Jansa Oct 27 21:18:20 03Martin Jansa  07master * r6991b9ca54 10openembedded.git/ (2 files in 2 dirs): Oct 27 21:18:21 EFL: upgrade SRCREV Oct 27 21:18:21 * fixed python-elementary after elementary API changes Oct 27 21:18:22 Signed-off-by: Martin Jansa Oct 27 21:18:22 03Martin Jansa  07master * r2e2ec545f0 10openembedded.git/ (classes/efl.bbclass recipes/efl1/ethumb_svn.bb): Oct 27 21:18:23 efl.bbclass: improve packaging a bit Oct 27 21:18:23 * include dbus service config if available Oct 27 21:18:24 * include plugins from //plugins/ (ie from ethumb) Oct 27 21:18:24 * include edje modules (ie from emotion) Oct 27 21:18:25 Signed-off-by: Martin Jansa Oct 27 21:19:20 (6 lines omitted) Oct 27 21:22:30 03Martin Jansa  07master * r35a6b51bbd 10openembedded.git/recipes/webkit/webkit-efl_svn.bb: Oct 27 21:22:31 webkit-efl: fix typo in theme path Oct 27 21:22:31 Signed-off-by: Martin Jansa Oct 27 21:36:35 03Denis 'GNUtoo' Carikli  07master * r5d5987b3f8 10openembedded.git/ (6 files in 3 dirs): (log message trimmed) Oct 27 21:36:35 linux-2.6.28: make it bootable and usefull on nokia900 Oct 27 21:36:35 *crucial boot support(mmc,mmc block devices,and filesystems) are now builtin Oct 27 21:36:35 *a CMDLINE is now set in the recipe(there is a custom nokia bootloader on the nokia900), Oct 27 21:36:35 That is also necessary to boot on microsd Oct 27 21:36:36 *g_ether is now built, which is required for usbnet Oct 27 21:36:36 *ondemand cpufreq governor is now the default Oct 27 21:40:07 khem: sorry for delay.. I had to push those before loosing context :/ http://paste.pocoo.org/show/282430/ Oct 27 21:41:12 hmm, anyone know of a site/tool for monitoring a web page for changes which gives you an RSS feed? Oct 27 21:45:04 looks like the checks in base.bbclass for COMPATIBLE_MACHINE and COMPATIBLE_TARGET_SYS may not match appropriately. I find that COMPATIBLE_MACHINE = "overo" matches MACHINE= "overoevm" which is probably not what is desired? Oct 27 21:45:45 thinking that COMPATIBLE_MACHINE/COMPATIBLE_TARGET_SYS should not be treated as a regex but instead as a | separated list of items that much match exactly Oct 27 21:46:07 if you want it to match exactly, use $ Oct 27 21:46:08 03Martin Jansa  07master * r5a00fb6dd1 10openembedded.git/recipes/xorg-xserver/xserver-xorg_1.9.1.bb: xserver-xorg_1.9.1: bump PR to rebuild with udev support for SHR Oct 27 21:46:28 kergoth, can you explain more? Oct 27 21:46:40 i'm not holding a regex 101 class here. Oct 27 21:46:47 oh... COMPATIBLE_MACHINE = "overo?" ? Oct 27 21:46:53 no Oct 27 21:46:54 oh... COMPATIBLE_MACHINE = "overo$" I mean Oct 27 21:46:55 i said $, not ? Oct 27 21:46:57 yes Oct 27 21:47:00 $ matches the end of the string Oct 27 21:47:21 makes sense once you realize its a regex matching - so what I describe is expected behavior then? Oct 27 21:47:37 works as designed. thats what a regular expression is. Oct 27 21:47:59 if you want it to be something other than regex, i'm open to hearing reasons why, but this isn't one of them :) Oct 27 21:48:27 no thats fine, just asking what the goal was.... http://docs.openembedded.org/usermanual/usermanual.html has a 'to be completed' with regards to documenting COMPATIBLE_* heh Oct 27 21:50:17 kergoth: it seems gitver does not like git srctree's on (no branch) -- still testing ... Oct 27 21:50:35 kergoth: fatal: ref HEAD is not a symbolic ref Oct 27 21:50:48 JaMa: ok good so I see the same problem. could you apply all patches in series upto 99350 and rebuild gcc-cross then redo my testcase for me plz Oct 27 21:51:57 khem: so without nothing newer than 99350? because I have gcc sysroot with all patches except this one (wouldn't need rebuild) Oct 27 21:52:05 cbrake: its the code that marks what master points to as a depends file so the version changes when the branch you have checked out changes Oct 27 21:52:19 cbrake: will have to adjust it to account for a floating HEAD Oct 27 21:52:50 JaMa: yes all patches upto and including 99350 Oct 27 21:53:29 cbrake, are you working on your build template? I checked it out the other day and it seems to be broken Oct 27 21:53:42 tharvey: it should be fairly close Oct 27 21:54:05 meaning your working on it, or I'm expected to tweak it for use? Oct 27 21:54:12 JaMa: now I am 90% convinced that this 99350 patch is bogus in its current state Oct 27 21:54:24 was thinking it would be nice to see a target for testing-next and testing or something Oct 27 21:54:38 tharvey: I expect it to work -- let me test it here Oct 27 21:54:43 tharvey: yes, good point Oct 27 21:54:59 khem: I still don't understand (sorry), you want it with original 99350 included right? Oct 27 21:55:11 and nothing newer Oct 27 21:55:41 cbrake, here's what I get: http://pastie.org/1253961 Oct 27 21:56:18 cbrake: i have a patch that should take care of it, if you want to test it out, i don't have an srctree test setup handy Oct 27 21:56:35 kergoth: yes, I could test Oct 27 21:59:56 cbrake: top commit on master of github.com/kergoth/openembedded Oct 27 22:03:08 kergoth: it at least parses now :-) Oct 27 22:03:14 good sign Oct 27 22:03:24 kergoth: I'll do some more testing in the morning after the build completes Oct 27 22:03:36 cbrake: k Oct 27 22:07:33 tharvey: I need to go -- a clean checkout of the build template seems to work, so there is likely some issue with subsequent builds Oct 27 22:07:48 tharvey: will look into it more tomorrow Oct 27 22:10:26 03Khem Raj  07master * r9172ced11e 10openembedded.git/recipes/jaaa/jaaa_0.4.2.bb: Oct 27 22:10:26 jaaa_0.4.2.bb: Dont inherit autotools Oct 27 22:10:26 * Define own do_compile and do_install Oct 27 22:10:26 Signed-off-by: Khem Raj Oct 27 22:10:26 03Khem Raj  07master * r1994dbe613 10openembedded.git/recipes/gcc/ (gcc-4.5.inc gcc-4.5/linaro/gcc-4.5-linaro-r99368.patch): Oct 27 22:10:26 gcc-4.5.inc: Disable Optimize load 0.0 for NEON patch Oct 27 22:10:27 * fixes the cairo regression and has been reported to malfunction Oct 27 22:10:27 see https://bugs.launchpad.net/gcc-linaro/+bug/667490 Oct 27 22:10:28 Signed-off-by: Khem Raj Oct 27 22:12:44 03Chris Larson  07master * rddffbe483e 10openembedded.git/classes/gitver.bbclass: Oct 27 22:12:45 gitver: fix non-symbolic HEAD ref Oct 27 22:12:45 Signed-off-by: Chris Larson Oct 27 22:38:28 JaMa: yes thats right Oct 27 22:42:19 hmm Oct 27 22:48:45 I see that module-base.bbclass sets many KERNEL_ vars which depend on STAGING_KERNEL_DIR - perhaps 'DEPENDS += "virtual/kernel' in module.bbclass isn't enough? wondering if a 'do_fetch[depends] += "virtual/kernel:do_stage" should be added to make sure those vars are valid prior to a recipe using them? Oct 27 22:49:41 I ran into this with a recipe of mine that buidls an out-of-tree kernel module which has a patch that contains KERNEL_VERSION thus do_patch needs to depend on kernel being staged - what task is that? I don't think DEPENDS += "virtual/kernel:do_stage" is valid? Oct 27 22:53:31 tharvey: adding to DEPENDS should translate to depending on do_populate_sysroot which is do_stage Oct 27 22:54:00 tharvey: I wonder if kernel has that task at all Oct 27 22:54:01 hmmm doesn't seem to work that way in practice Oct 27 22:54:35 its because DEPENDS makes do_configure/do_compile depend on do_populate_staging Oct 27 22:54:47 and in my case with a patch that has KERNEL_VERSION in it I need do_patch to depend as well Oct 27 22:55:07 ah do_patch Oct 27 22:55:23 yes then we need to alter that Oct 27 22:55:33 looking at module-base.bbclass and all the vars it defines based on things that exist in KERNEL_STAGING_DIR seems like the class should add some more specific deps Oct 27 22:55:38 I think it would be ok to add that dep Oct 27 22:58:20 what is the proper way to add a dep for the 'first task' - is do_fetch first? Oct 27 23:02:03 do_patch[depends] += "virtual/kernel:do_populate_sysroot" Oct 27 23:03:05 ah... yes, do_stage = do_populate_sysroot - ok, testing Oct 27 23:03:54 is there any task prior to fetch? would think I would want to use do_fetch[depends] in case the vars defined are used in SRC_URI Oct 27 23:05:59 cbrake, thx - clean checkout of your openembedded template does work - I should have tried 'make clobber' to see if that fixed it but didn't Oct 27 23:07:43 tharvey: no Oct 27 23:08:46 do_fetch[depends] += "virtual/kernel:do_populate_sysroot" works as well - I'll post a patch - thx Oct 27 23:16:06 hrmmm Oct 27 23:16:27 cbrake: i'm experimenting with constructing a collection for all of task-boot which is entirely srctrees Oct 27 23:20:12 kergoth: juggling too many balls Oct 27 23:20:36 ah the sight of F-18s flying over my head Oct 27 23:21:15 i really need a whiteboard before i drop some of these Oct 27 23:21:17 nice Oct 27 23:21:39 I hope they are from USAF ;) Oct 27 23:22:28 hmm, i should install libtool 2.4 into a chroot to use for bootstraping for this srctree stuff Oct 27 23:22:50 huh, didn't realize all the fedora stuff is in git repositories now, nice Oct 27 23:25:49 kergoth: I want to stick in something into po/Makefile.in.in but do_configure seems to override it Oct 27 23:26:15 kergoth: before I bury my head any quick top Oct 27 23:26:17 tip Oct 27 23:26:31 someone is regenerating it Oct 27 23:27:10 might need --exclude=autopoint in your EXTRA_AUTORECONF Oct 27 23:33:16 kergoth: ok Oct 27 23:33:34 kergoth: we add -warning=cross to automake and it doesnt know about it Oct 27 23:34:10 hmm if recipe sources were in git, and we checked in generated files into a branch, we could make oe emit a chroot to use to bootstrap that with oe's macros, and thereby avoid the regenerate every build thing Oct 27 23:34:28 * kergoth ponders Oct 27 23:36:18 hmm, if we include an 'install' wrapper, we could drop coreutils-native.. and if we put stage-manager* into oe/bin/, we could drop stagemanager-native as a recipe Oct 27 23:36:27 and shasum-native is already dead for recnet python.. Oct 27 23:36:34 * kergoth is looking over the dependency graph Oct 27 23:38:40 kergoth: yes thats good if we could drop those 3 Oct 27 23:39:18 they don't take long, but the more deps we can remove the better i think Oct 27 23:39:20 heh Oct 27 23:40:30 hmm Oct 27 23:40:35 * kergoth tests an idea for an rm_work improvement Oct 27 23:43:58 i was just thinking -- why create rm_work/rm_work_all when we could just replace do_build with a task that actually *does something* Oct 27 23:44:03 rather than a no-op Oct 27 23:44:14 just make do_build clean the workdir Oct 27 23:45:34 kergoth, its nice to have a -c build target when you're using rm_work to build and leave the sources around Oct 27 23:46:05 hmm, i suppose. you can always -c patch to get the source if you need it Oct 27 23:46:10 when do you need to use -c build that way? Oct 27 23:46:30 i just want to check everything after build/install Oct 27 23:46:32 kergoth: build could do rm_work when asked for Oct 27 23:46:43 and no need to have rm_work Oct 27 23:46:51 khem: true. make it a variable? Oct 27 23:47:02 yeah Oct 27 23:47:08 i was thinking it would be nice to make workdir removal default, its the common case Oct 27 23:47:13 which could be set GLOBAL in local.conf Oct 27 23:47:16 * kergoth nods Oct 27 23:47:24 or per recipe with pn-${PN} override if you want that Oct 27 23:47:26 yes it should be default Oct 27 23:47:44 yes can be overridden using OVERRIDES Oct 27 23:47:58 i wrote a recipe to build the aufs2 kernel module, but it requires that a header file be copied to the kernel sources. how do i do that without hardcoding paths? Oct 27 23:48:08 khem: heh, theres another item for the todo list.. too much to do! Oct 27 23:48:11 :) Oct 27 23:49:26 kergoth: I guess you should do rm_work first of all Oct 27 23:49:36 and it can get in fairly easily Oct 27 23:49:46 and would reduce 2 tasks per recipe Oct 27 23:50:07 yeah, good point Oct 27 23:50:25 the more tasks, the harder bitbake has to work and more processes get forked, even if what they actually do is trivial Oct 27 23:50:40 correct Oct 27 23:51:06 I compared gcc bare build and with bitbake and time is almost twice Oct 27 23:51:28 I know its not apple to apple but you get the idea Oct 27 23:51:31 yikes Oct 27 23:51:55 so any reduction in tasks will help Oct 27 23:52:17 I wonder if itd be beneficial to change how bitbake spanws tasks -- make it hand off job objects into a queue, keep the pool of processes running and hand them work, rather than continually spawning new processes and letting them go away Oct 27 23:53:44 kergoth: I want to find first word in a line ignoring whitespaces what is the regexp Oct 27 23:54:12 i always forget which is which, iirc its \S for whitespace and \s for non, or vice-versa Oct 27 23:57:25 s/^\s+ .... Oct 27 23:57:32 something like that for sed Oct 28 00:10:03 http://github.com/kergoth/openembedded/commit/5e1afd2a81afd6a7ac564df41a0797013e199f2e Oct 28 00:13:53 kergoth, can you recall the failures you were seeing when you made the fix in oe commit a6a23f73 ? Oct 28 00:14:24 as a result of that change, do_fetch is called twice Oct 28 00:14:35 grg: if you use pstage, all tasks are bypassed, including fetch Oct 28 00:14:48 ah ok. Oct 28 00:14:54 so, on a completely fresh box, using prebuilt binaries, it'll fail to distribute sources, because they've never been fetched Oct 28 00:15:08 iirc, anyway Oct 28 00:15:08 could that do_fetch call be made conditional on whether pstage is being used? Oct 28 00:15:17 pstage is default Oct 28 00:15:20 but perhaps Oct 28 00:15:28 alternatively, have it check for the existance of the do_fetch stamp Oct 28 00:15:40 if do_fetch has *ever* been run, it should be okay to not run it Oct 28 00:16:05 yep Oct 28 00:16:28 kergoth: btw old rm_work.bbclass had nice "feature" that when it was enabled after building image, it "created new tasks" and running image build egain cleaned everything, I guess it won't be the case with new implementation, right? Oct 28 00:16:32 do_fetch and do_unpack are racing in src_distribute... i cant see any reason why its causing failures, but it is Oct 28 00:17:23 JaMa: hmm, yes, this is true. well, i expect in the new world it'll be left enabled and you just disable it for whatever recipe you're working on, so itd be a nonissue Oct 28 00:17:27 but it depends on your workflow, i guess Oct 28 00:18:33 it's not big issue I can still just delete whole workdir in this case usually Oct 28 00:19:51 what i mean is, I don't really see the use case for disabling RM_WORK globally. the only reason to keep it around is to diagnose problems or check sanity, that i can think of, anyway Oct 28 00:21:39 ok Oct 28 00:25:38 i could be wrong, maybe there is a need for it, i just can't think of one offhand :) Oct 28 00:26:06 doing a world-wide audit i suppose. but that's not going to be common Oct 28 00:26:11 * kergoth nods Oct 28 00:26:38 yes and in this case I'm OK with removing whole workdir after it (before reenabling rm_work) Oct 28 00:28:56 03Chris Larson  07master * r1a7c215aaf 10openembedded.git/classes/clean.bbclass: Oct 28 00:28:56 clean: rename clean_workdir to remove_workdir Oct 28 00:28:56 Signed-off-by: Chris Larson Oct 28 00:28:59 03Chris Larson  07master * r8264858d8c 10openembedded.git/classes/gitver.bbclass: Oct 28 00:28:59 gitver: add GITSHA variable Oct 28 00:28:59 There's a case where git describe produces output which is not pleasant, to Oct 28 00:28:59 put it mildly, and it's better to just set PV to "0.0+${GITSHA}" or similar, Oct 28 00:28:59 including the short form of the commit hash for HEAD. Oct 28 00:28:59 Signed-off-by: Chris Larson Oct 28 00:31:26 very occasionally, i get this error from bitbake: http://pastebin.com/JitxjRYy and rerunning the same bitbake command succeeds the next time around. Oct 28 00:31:37 here's another question: python-numeric and python-fuse are failing because they're adding -L/usr/bin to the linker flags. yes, they inherit distutils. any ideas on where to look? i've searched through the distutils classes and all of the files in the workdir. Oct 28 00:32:47 vorporeal: really /usr/bin/ not /usr/lib? Oct 28 00:32:53 err, /usr/lib Oct 28 00:34:37 last time we had those before 629ae87eadeec1068c3778e14488b549029adffb fix Oct 28 00:39:26 grg: strange, i just got bit by that too, very weird. whats more wierd is cranking up the debugging isn't informative, still a useless message :| Oct 28 00:39:26 :w Oct 28 00:40:08 if i knew anything about python and bitbake i might be able to delve deeper Oct 28 00:40:23 worse yet, just re-running bitbake isn't fixing it this time around Oct 28 00:40:23 hrm Oct 28 00:40:43 alas i can't even figure out how tasks are spawned into separate processes Oct 28 00:45:51 read runqueue.py Oct 28 00:46:26 ah, its something up with the logging stuff Oct 28 00:46:36 if you do bitbake -b on the offending recipe, you see the parse error Oct 28 01:06:49 ah, there's teh old build configuration display, resurrected Oct 28 01:19:43 03Chris Larson  07master * r107cb75421 10openembedded.git/classes/ (base.bbclass utility-tasks.bbclass): Oct 28 01:19:43 base: drop rebuild, fix eventhandler Oct 28 01:19:43 Signed-off-by: Chris Larson Oct 28 01:21:24 03Chris Larson  07master * r92637a355d 10bitbake.git/lib/bb/cache.py: Oct 28 01:21:24 Make 'cache is clean' message debug Oct 28 01:21:24 Signed-off-by: Chris Larson Oct 28 01:22:14 still can't find anything to fix those two python packages Oct 28 01:22:28 i'm running out of places to look :( Oct 28 01:44:08 well, i "fixed" it by changing "inherit distutils" to "inherit distutils-base". not sure what else that might have done, but everything compiled fine. (needed for python-numeric, python-fuse, and python-pygame) Oct 28 01:44:20 oops, nevermind Oct 28 01:44:23 broke things later Oct 28 01:44:24 of course Oct 28 01:50:38 kergoth: ok i should disable intltoolize to stop po/makefile.in.in from being regenerated Oct 28 01:50:55 kergoth: is there is a knob to disable it like autopoint Oct 28 01:52:19 well I dont see a knob in autotools.bbclass unlucky me Oct 28 02:03:24 khem: heh, time to add support for excluding the autotools.bbclass bits, i guess Oct 28 02:13:07 ok sed is the king Oct 28 02:13:14 the infinite loop in scim is fixed Oct 28 02:13:26 so my bitbake world can progress Oct 28 02:14:53 03Khem Raj  07master * r9ccba6c9c0 10openembedded.git/recipes/scim/scim_1.4.9.bb: Oct 28 02:14:53 scim_1.4.9.bb: Fix infinite loop when compiling po/ subdir Oct 28 02:14:53 Signed-off-by: Khem Raj Oct 28 02:15:19 kergoth: nice I like that summary view Oct 28 02:16:13 I wonder why it thinks I have TARGET_FPU=hard Oct 28 02:36:24 any suggestions on where i could look or who else i could ask about this libgcc_s.so issue? **** ENDING LOGGING AT Thu Oct 28 02:59:57 2010