**** BEGIN LOGGING AT Wed Oct 13 02:59:57 2010 Oct 13 03:14:55 Anyone seeing a break in openjdk-6 and libprelude? Oct 13 05:58:38 Morning. I get "RDEPENDS/RRECOMMENDS or otherwise requires the runtime entity 'libusb-1.0-0' but it wasn't found in any PACKAGE or RPROVIDES variables" when I try to compile my image. Yesterday I removed my TMPDIR and rebuilt everything. That worked, but on the next build the error showed up again. Oct 13 06:49:49 03Khem Raj  07master * raffcbbc1f7 10openembedded.git/recipes/gnuradio/ (3 files in 2 dirs): Oct 13 06:49:49 gnuradio: Fix build with libtool 2.4 Oct 13 06:49:49 * Update libtool macros for embedded libusb Oct 13 06:49:49 * We still need to fix libstdc++.la issue Oct 13 06:49:49 Signed-off-by: Khem Raj Oct 13 06:54:22 khem: before you fall asleep, any hint why I see errors like this (double path) in a few recipes? Oct 13 06:54:25 | /bin/grep: /OE/tmpdir-shr/sysroots/armv4t-oe-linux-gnueabi/OE/tmpdir-shr/sysroots/x86_64-linux/usr/armv4t/arm-oe-linux-gnueabi/lib/libstdc++.la: No such file or directory Oct 13 06:54:28 | /bin/sed: can't read /OE/tmpdir-shr/sysroots/armv4t-oe-linux-gnueabi/OE/tmpdir-shr/sysroots/x86_64-linux/usr/armv4t/arm-oe-linux-gnueabi/lib/libstdc++.la: No such file or directory Oct 13 06:54:32 | arm-oe-linux-gnueabi-libtool: link: `/OE/tmpdir-shr/sysroots/armv4t-oe-linux-gnueabi/OE/tmpdir-shr/sysroots/x86_64-linux/usr/armv4t/arm-oe-linux-gnueabi/lib/libstdc++.la' is not a valid libtool archive Oct 13 06:55:07 and usually lot's of "moved .la" like arm-oe-linux-gnueabi-libtool: link: warning: `/OE/tmpdir-shr/sysroots/armv4t-oe-linux-gnueabi/usr/lib/libglib-2.0.la' seems to be moved Oct 13 07:27:25 Good morning. Oct 13 07:28:07 good morning Oct 13 07:29:38 I have 2 machine target2. Can I create 2 local.conf like "mach1.conf" and "mach2.conf" and ask bitbake to use them instead of local.conf? Oct 13 07:30:24 Something like bitbake --conf-file mach2.conf Oct 13 07:31:54 Now, I have to replace local.conf every time I switch target machine. not convenient. Oct 13 07:32:26 you can set the MACHINE as the shell variable Oct 13 07:32:57 ynezz: Actually, I've not been able to do that Oct 13 07:33:26 ynezz: The only way I could get it to take MACHINE as a shell environment, weirdly, was to do alias bitbake='MACHINE=${MACHINE} bitbake' Oct 13 07:34:20 xobs: do you have export BB_ENV_EXTRAWHITE="MACHINE DISTRO" ? Oct 13 07:34:26 ok. then you can create conf/auto.conf Oct 13 07:34:38 I really want to tell bitbake to use another .conf file instead of build/conf/local.conf . Oct 13 07:34:51 echo "MACHINE = \"one\"" > conf/auto.conf Oct 13 07:35:53 basically what I do is set machine/distro (and one or two other things) in a shell script that I source; works like a charm; as JaMa|Wrk says you do need to exprot BB_ENV_EXTRAWHITE Oct 13 07:36:01 * JaMa|Wrk is using setup-env which exports right MACHINE and DISTO and also puts it to PS1 Oct 13 07:36:02 JaMa|Wrk: No, and adding that doesn't seem to make a difference. Oct 13 07:36:09 moin Oct 13 07:36:20 hi hrw Oct 13 07:36:45 mfhk: as I said, you can use conf/auto.conf, bitbake will include it Oct 13 07:37:01 xobs: did you remove MACHINE = from your conf/local.conf or conf/auto.conf? Oct 13 07:37:13 mfhk: bitbake includes 3 files: conf/{local,auto,site}.conf Oct 13 07:37:20 xobs: otherwise it can overwrite the settings from environment Oct 13 07:37:35 xobs: use MACHINE ?= "name" in auto.conf so shell will overwrite it Oct 13 07:37:48 JaMa|Wrk: Yes. Without my alias hack, trying to build anything yields a ton of "EOL while scanning string literal (MACHINE_ARCH, line 1) while parsing" errors. Oct 13 07:37:54 JaMa|Wrk: good observation Oct 13 07:38:37 But this is still inconvient compared to just "bitbake --conf mach2.conf ...", agree? Oct 13 07:38:49 xobs: mfhk, here is what I use on our autobuilder: http://www.pastebin.ca/1960706 Oct 13 07:38:50 * JaMa|Wrk disagree :) Oct 13 07:39:11 it is a shell script that creates the local.conf but it has the BB_ENV* thing etc Oct 13 07:39:29 mfhk: if that is what you want do: Oct 13 07:39:36 MACHINE=xyz bitbake helloworld Oct 13 07:39:52 and you can make a nice alias for it Oct 13 07:40:15 ofc if you want to have two machines you can also use two trees Oct 13 07:40:35 and symlink part of it or use overlays to store your local.conf Oct 13 07:41:10 whatever is better then bitbake --conf :) Oct 13 07:41:32 effem, "MACHINE=xyz bitbake helloworld" looks better :) Oct 13 07:42:10 then make a shell alias for it or a shell script to save typing Oct 13 07:42:24 but still not easy as "bitbake --conf x86.conf helloworld" :) Oct 13 07:43:22 personal taste. Oct 13 07:43:35 it is, --conf x86.conf is 15 letters, MACHINE=x86 is only 11 :-) Oct 13 07:43:42 you can change it, if you wish, no problem, you've sources Oct 13 07:43:48 effem: That script looks really useful. I'll probably steal parts of it for my own autobuilder! Here's the basic setup script I have going right now: http://www.pastebin.ca/1960708 Oct 13 07:44:47 mfhk: feel free to add it to the code and mail it to the list, guess the bb maintainers will be happy to add it if it is a sound & proper implementation Oct 13 07:45:18 sure Oct 13 07:45:32 and thanks! Oct 13 07:45:35 xobs: be my guest, I use hudson as autobuilder, on the outside there is a small form to select MACHINE/DISTRO/TARGET_RECIPE from an enumerated list Oct 13 07:45:37 mfhk: yw Oct 13 07:46:55 xobs: I just set MACHINE in an env var but you *do* need the BB_ENV_EXTRAWHITE thingie Oct 13 07:47:16 I have no MACHINE set up. My only local.conf is in an overlay pointed to by BBPATH. Oct 13 07:47:28 echo -n $BB_ENV_EXTRAWHITE; echo -n " - "; echo $MACHINE -- produces: MACHINE DISTRO - chumby-falconwing Oct 13 07:48:37 looks ok to me Oct 13 07:49:43 03Koen Kooi  07org.openembedded.dev * r96988dec22 10openembedded.git/recipes/dosbox/dosbox_0.74.bb: dosbox: add 0.74 Oct 13 07:51:15 effem: bitbake still freaks out. "bitbake -e | grep MACHINE=" gives me "# MACHINE=None". Even though "bitbake -e | grep BB_ENV_EXTRAWHITE=" shows extrawhite is set. Oct 13 07:52:16 xobs, what host os? and could you try export BB_ENV_EXTRAWHITE MACHINE Oct 13 07:52:29 export seems to help on some systems Oct 13 07:52:40 taht script I gave works smoothly under ubuntu 10.04 Oct 13 07:53:43 xobs: BB_ENV_EXTRAWHITE is shell variable do you have it exported from shell? Oct 13 07:53:59 effem: That was the magic incantation. "export BB_ENV_EXTRAWHITE MACHINE". Having the "=" doesn't work for some reason. Oct 13 07:54:57 eFfeM_work: what types of errors do catch from Hudson? Are you also looking for QA ERRORS or just fatal? Oct 13 07:55:08 effem: I believe this an Ubuntu 2010 machine. It's an EC2 instance, so I'm not entirely sure. Oct 13 07:55:19 s/do catch/do you catch/ Oct 13 07:57:30 JaMa|Wrk: for now I am just looking at fatal (for the testing branch). I build then first check if it says all tasks build, then I glance over the log to see if there is something odd, peeking at QA errors is the next step (actually that is why I would like to make the non-packaged files generate an error, so we can make a list, fix them, then set it to error so we can catch regressions Oct 13 07:58:16 eFfeM_work: one SHR user is running test builds with Hudson and always reports failed builds because of even just QA ERROR: so if you have your Hudson setup documented somewhere I'll point him there Oct 13 07:59:05 JaMa|Wrk: I didn't really set it up, don't have too much info on it, I just added my project Oct 13 07:59:14 eFfeM_work: so you're later checking the log yourself and only fatal errors are shown as failed build? Oct 13 07:59:28 yes Oct 13 07:59:46 ok, thanks Oct 13 08:00:07 actually hudson sometimes tells things are failed because things like multiple providers etc seem also to trigger bitbake to return error Oct 13 08:00:22 so maybe I should have said no Oct 13 08:00:41 sometimes the build shows up as failed, I always check the console output Oct 13 08:00:47 still needs to work a little bit on this Oct 13 08:00:56 but last testing branch gave me some blue dots :-) Oct 13 08:01:00 eFfeM_work: something like this ticket (just QA NOTE:) makes me crazy http://trac.shr-project.org/trac/ticket/1213 Oct 13 08:01:42 I get these too, but they do not break my build and do not trigger errors in hudson Oct 13 08:02:22 no idea how to fix these, I see them on a few other places too; i even think I saw it on a place that has inherit gettext in the recipe Oct 13 08:02:49 JaMa|Wrk: Priority: trivial Oct 13 08:04:07 :-) Oct 13 08:06:40 eFfeM_work: right, but if he fills one ticket for every QA log entry we would need new bug tracker :) Oct 13 08:06:48 true Oct 13 08:07:47 actually don't know exactly how to fix these, seems something that that could be fixed fairly easily Oct 13 08:11:05 eFfeM_work: it checks configure.in|ac and if 'grep \"^[[:space:]]*AM_GNU_GETTEXT\" %s >/dev/null" % config' is not empty it want's gettext(-cross|-native) in DEPENDS Oct 13 08:12:42 JaMa|Wrk: my last successful build (nslu2be/slugos/slugos-image) did not have any QA errors (also not in gcc related recipes) Oct 13 08:13:10 not sure what changed, I used to get warnings on running strip on kernel files, but that one is gone too Oct 13 08:13:30 testing-next branch, bitbake 1.10.0 Oct 13 08:13:34 eFfeM_work: and for this gcc.. I guess it's because ie gcc-4.5.inc sets DEPENDS after inheriting gettext in gcc-common.inc Oct 13 08:14:09 could well be, actually slugos uses gcc 4.4.4 Oct 13 08:15:40 but my console-image builds did not pass due to libgee and it is too nasty to change things on the autobuilder (messed up things once causing things not to be updated); might set up a new project for dev head later Oct 13 08:27:20 03Koen Kooi  07org.openembedded.dev * r6c96c81016 10openembedded.git/recipes/pulseaudio/padevchooser_0.9.3.bb: padevchooser: bump PR for pulseaudio change Oct 13 08:27:23 03Koen Kooi  07org.openembedded.dev * ra8d06a2bb1 10openembedded.git/recipes/pulseaudio/paprefs_0.9.9.bb: paprefs: bump PR for pulseaudio change Oct 13 08:27:24 03Koen Kooi  07org.openembedded.dev * r9936414a48 10openembedded.git/recipes/pulseaudio/pavucontrol_0.9.10.bb: pavucontrol: add 0.9.10 Oct 13 08:27:32 03Koen Kooi  07org.openembedded.dev * rdc53510692 10openembedded.git/conf/distro/include/angstrom-2010-preferred-versions.inc: angstrom-next: switch to a newer pulseaudio Oct 13 08:32:05 is apr-util broken? could someone give it a bake? Oct 13 08:37:58 03Brijesh Singh  07org.openembedded.dev * r3a16dfae68 10openembedded.git/recipes/ti/ (13 files in 4 dirs): (log message trimmed) Oct 13 08:37:59 gstreamer-ti_svn: various updates Oct 13 08:37:59 * apply patch from tracker 1208 to get zero copy support on DM365 platform. Oct 13 08:37:59 * enable c6accel based element on omap3 platforms. Oct 13 08:37:59 * update dm365 loadmodules to reserve ARM TCM need by platinum codecs. Oct 13 08:37:59 * add loadmodule for omapl138. Oct 13 08:38:00 Signed-off-by: Brijesh Singh Oct 13 08:38:07 03Brijesh Singh  07org.openembedded.dev * r59a179c90a 10openembedded.git/recipes/ti/ti-dm365mm-module.inc: Oct 13 08:38:07 ti-dm365mm-module: use external URL to fetch the component Oct 13 08:38:07 Signed-off-by: Brijesh Singh Oct 13 08:38:07 Signed-off-by: Koen Kooi Oct 13 08:42:25 I get "error executing python function" in the apr-util recipe. Any debug I can turn on to see where the error occurs? Oct 13 08:51:48 m4t: I see you discussed the same issue in http://ibot.rikers.org/%23oe/20090828.html.gz. Got any ideas for a fix? Oct 13 08:53:00 03Koen Kooi  07org.openembedded.dev * re1430daabf 10openembedded.git/recipes/bluez/obexd_0.34.bb: obexd: add 0.34 Oct 13 08:53:08 03Koen Kooi  07org.openembedded.dev * r5a2c5d959c 10openembedded.git/recipes/bluez/ (bluez4.inc bluez4_4.66.bb bluez4_4.75.bb): bluez4: add 4.75, fix alsa packaging Oct 13 08:53:59 hm. seems it's pg_config that causes it to look at /usr/include Oct 13 08:56:31 good morning Oct 13 08:56:46 hi florian Oct 13 08:57:54 anyone ever tried things like dietlib or newlib with the minimal distro? Oct 13 09:00:47 If a recipe looks at host includes, is there something wrong with the recipe for sure, or could my system be to blame? Oct 13 09:04:08 tasslehoff: usually recipe Oct 13 09:04:57 or, more general: how does footprint of glibc/uclibc/newlib/dietlib compare ? Oct 13 09:15:43 Hi Florian, it Michael who talked to you about your mini6410 blog post. Oct 13 09:16:15 mfhk: hi! Oct 13 09:16:21 You must be busy. Oct 13 09:16:36 No feed back from you. Oct 13 09:16:40 oh sorry... yeah, there are still two mails I didn't answer yet Oct 13 09:17:00 Forget them, I figured out. Oct 13 09:17:40 BTW, is your mini6410 using 256MB NAND? Oct 13 09:18:07 mfhk: what was the reason? Oct 13 09:18:34 Mine is 1GB NAND. But the vendor supplied kernel driver seems broken. Oct 13 09:19:24 mfhk: i think so yes Oct 13 09:19:31 mfhk: an nasty Oct 13 09:19:50 the kernel sucks quite a lot (but i have seen worse) Oct 13 09:20:25 The vendor driver look for bad block at first page, but samsung put it at last page! Oct 13 09:20:54 Any plans to try 2.6.35 on it? Oct 13 09:24:56 fyi, if yours' 256MB SLC nand then the driver is ok. Oct 13 09:38:29 03Koen Kooi  07org.openembedded.dev * r3fffdec1c3 10openembedded.git/recipes/linux/ (12 files in 11 dirs): Oct 13 09:38:29 linux-davinci: add 2.6.31+2.6.32-rc2-psp03.01.00.37 Oct 13 09:38:29 imported from arago with some changes Oct 13 09:38:29 Signed-off-by: Koen Kooi Oct 13 09:56:52 hm www.openembedded.org currently only gives me an "It works" page Oct 13 09:57:13 eFfeM_work, same here Oct 13 10:05:56 use http://wiki.openembedded.org/index.php/Main_Page Oct 13 10:10:57 don't need it just wnated to report it Oct 13 10:11:47 03Koen Kooi  07org.openembedded.dev * rd8735ed621 10openembedded.git/recipes/pulseaudio/libcanberra_0.26.bb: libcanberra: update to 0.26 Oct 13 10:18:02 I have an issue with libusb1 that I don't understand. I get "RDEPENDS/RRECOMMENDS or otherwise requires the runtime entity 'libusb-1.0-0' but it wasn't found in any PACKAGE or RPROVIDES variables" when compiling. My image.bb hasn't changed, and libusb hasn't received any commits since the last time it worked either. Oct 13 10:46:46 03Koen Kooi  07org.openembedded.dev * rd0366603f0 10openembedded.git/recipes/ti/ti-dmai_svn.bb: Oct 13 10:46:46 ti-dmai svn: bump SRCREV for omap3 and dm365 Oct 13 10:46:46 Signed-off-by: Koen Kooi Oct 13 11:13:24 hi guys Oct 13 11:31:53 could a kind soul try "bitbake apr-util"? Oct 13 11:44:42 tasslehoff: it will take a while. Regarding the meta-toolchain... khem was linking the libs statically... so it is mostly fine right now Oct 13 11:45:33 tasslehoff: ah, i see your email on apr-util Oct 13 11:47:20 zecke: the toolchain works well for me know. thanks for that previus support :) Oct 13 11:51:46 03Khem Raj  07org.openembedded.dev * r629ae87ead 10openembedded.git/classes/distutils-common-base.bbclass: (log message trimmed) Oct 13 11:51:47 distutils-common-base.bbclass: Prepend STAGING_LIBDIR to linker library search path. Oct 13 11:51:47 * This was done generically in bitbake.conf this should be done on Oct 13 11:51:47 demand and distutils based recipes seem to need it. So we define it Oct 13 11:51:47 here. Oct 13 11:51:47 Signed-off-by: Khem Raj Oct 13 11:51:48 Acked-by: Martin Jansa Oct 13 11:51:48 03Koen Kooi  07org.openembedded.dev * r06bfcb80d8 10openembedded.git/recipes/ti/ti-dmai_svn.bb: Oct 13 11:51:49 ti-dmai svn: bump dm365 SRCREV after kernel change Oct 13 11:51:49 Signed-off-by: Koen Kooi Oct 13 11:51:50 03Koen Kooi  07org.openembedded.dev * r6c0e4791a4 10openembedded.git/conf/distro/include/angstrom-2010-preferred-versions.inc: angstrom-next: switch to udev 154 Oct 13 11:51:51 03Koen Kooi  07org.openembedded.dev * r1d07aed62a 10openembedded.git/recipes/linux/ (13 files in 2 dirs): Oct 13 11:51:52 linux-davinci 2.6.32rc2: fix typo in name and switch dm365 to use this recipe Oct 13 11:51:52 Signed-off-by: Koen Kooi Oct 13 11:56:38 03Koen Kooi  07org.openembedded.dev * r13c8cf23e3 10openembedded.git/recipes/linux/linux-omap_2.6.36rc.bb: linux-omap 2.6.36rc: move SRCREV forward Oct 13 12:02:54 khem: here is debug output from libtool http://paste.pocoo.org/show/274906/, my guess is that only last occurence is replaced like 's#=/usr/lib/libgthread-2.0.la#/OE/tmpdir-shr/sysroots/armv4t-oe-linux-gnueabi/usr/lib/libgthread-2.0.la#' and then it tries to open =/usr/lib/libgthread-2.0.la file Oct 13 12:08:01 03Thomas Zimmermann  07org.openembedded.dev * rac50fe200e 10openembedded.git/recipes/bluez/obexd_0.34.bb: Oct 13 12:08:01 obexd_0.34.bb: remove fso patch Oct 13 12:08:01 * this won't apply to this version Oct 13 12:08:01 * remove as it needs complete rewrite Oct 13 12:10:09 line 3092 already looks wrong: dependency_libs=' =/usr/lib/libgthread-2.0.la -lpthread -lrt =/usr/lib/libglib-2.0.la' Oct 13 12:12:51 tasslehoff: you want to either add postgres to the depens of apr-util... or find a flag to disable postgres Oct 13 12:14:09 zecke: postgresql? I'll try depending on it. Oct 13 12:14:49 playya: why? I think that =/ is just sysroot, resolved later.. cat tmpdir-shr/sysroots/armv4t-oe-linux-gnueabi/usr/lib/*.la | grep -c '=/usr/lib' -> 244 Oct 13 12:15:14 tasslehoff: i think it is preferable to disable it somehow. Oct 13 12:15:15 hmm. ok Oct 13 12:15:31 tasslehoff: but pg_config from your mail indicates that it is picking up postgres from your system Oct 13 12:18:07 playya: func_resolve_sysroot_result is replacing it with real sysroot Oct 13 12:18:40 playya: probably still missing somewhere like http://git.savannah.gnu.org/cgit/libtool.git/commit/?id=2ed5700993f997817ad5c164a4bbe4559e5bf66a was (this patch is already in OE's libtool) Oct 13 12:18:49 hmm. ok Oct 13 12:25:41 zecke: --without-pgsql in EXTRA_OECONF did the trick Oct 13 12:27:35 tasslehoff: care to post a patch? Oct 13 12:29:43 zecke: sure. just git format-patch, inline it in a mail and write "signed-off by"? Oct 13 12:31:48 tasslehoff: you can ask git format-patch to add the line. :) Oct 13 12:33:30 ah Oct 13 12:44:02 khem: with this patch http://paste.pocoo.org/show/274934/ I'm able to build libgee fine (all sysroots are removed ok before installing, but those duplicities (like gthread and glib are still ther) so probably func_resolve_sysroot wasn't called soon enough :/ Oct 13 12:45:06 zecke: patch submitted, thanks for helping. Oct 13 12:45:38 tasslehoff: the nitpick. You should have used spaces, and bumped the PR. I will do it this time Oct 13 12:46:14 zecke: useful nitpick. thanks. I'll try to remember the next time. Oct 13 12:47:14 tasslehoff: and your mailer wrapped the line Oct 13 12:50:27 zecke: hm. I need to learn this. I created the patch with "git format-patch HEAD~1 -s", and copy pasted it into a mail (in thunderbird). What should I have done instead to spare you the troubles? Oct 13 12:50:56 tasslehoff: yeah, thunderbirds sucks. man git-format-patch Oct 13 12:53:10 zecke: format-patch I used correctly, no? Oct 13 12:53:28 * broonie suspects zecke means git send-email Oct 13 12:53:43 * tasslehoff too Oct 13 12:55:09 03Koen Kooi  07org.openembedded.dev * r8e7866b551 10openembedded.git/recipes/ti/ti-codecs-omap3530_4.00.00.00.bb: ti-codecs-omap3530: add version 4 with c6accel support Oct 13 12:55:18 03Koen Kooi  07org.openembedded.dev * r901c315947 10openembedded.git/recipes/ti/gstreamer-ti.inc: gstreamer-ti: bump PR for omap3 codec changes Oct 13 12:55:29 03Koen Kooi  07org.openembedded.dev * r07176a3929 10openembedded.git/conf/distro/include/angstrom-codec-engine-latest-preferred-versions.inc: angstrom-codec-engine-latest-preferred-versions: use version 4 of omap3530 codecs Oct 13 12:55:40 tasslehoff: I do. So thunderbird will most likely wrap your lines Oct 13 12:56:39 03Tasslehoff Kjappfot  07master * reba2dd09df 10openembedded.git/recipes/apr/apr-util_1.3.4.bb: Oct 13 12:56:39 apr-util_1.3.4: Build without Postgres support Oct 13 12:56:39 apr-util attempts to execute pg_config, which could Oct 13 12:56:40 be the host pg_config binary. Ask it to build without Oct 13 12:56:40 Postgres support. Oct 13 12:57:42 You can bludgeon thunderbird into not wrapping lines, but you need to install a plugin to make it behave. Sad, really. Oct 13 12:58:01 mwester: or toggle an option in the manual settings... each time Oct 13 12:58:05 * zecke uses thunderbird too Oct 13 13:02:18 hum. but we still use it, since there are no good alternatives? Oct 13 13:05:53 tasslehoff: I had enough of kmail this year Oct 13 13:07:37 install the thunderbird thing that shows you what people are using to send their mail with Oct 13 13:07:44 * cbrake is hoping the kmail in Ubuntu 10.10 is improved some ... Oct 13 13:08:17 https://addons.mozilla.org/en-US/thunderbird/addon/562/ Oct 13 13:08:25 then see what the cool people are using Oct 13 13:08:35 * Crofton|work sees a surprising amount of mutt Oct 13 13:09:14 cbrake, can you fix www.openembedded.org? Oct 13 13:10:23 hm. does git send-email "just work" without any setup? it asked me a bunch of stuff, but never about any servers/passwords Oct 13 13:11:13 Crofton|work: yes, looking now ... Oct 13 13:11:52 thanks Oct 13 13:11:57 hopefully, it is easy :) Oct 13 13:12:33 Crofton|work: why? "It works!" :-) Oct 13 13:12:38 rofl Oct 13 13:12:43 yes, it does Oct 13 13:13:40 Crofton|work: ok, added a simple html re-direct Oct 13 13:14:15 ok great Oct 13 13:16:32 03Martin Jansa  07master * r85faa2d9ab 10openembedded.git/recipes/libsdl/ (libsdl-ttf-2.0.10/libtool-update.patch libsdl-ttf_2.0.10.bb): Oct 13 13:16:32 libsdl-ttf: add newer version 2.0.10 Oct 13 13:16:32 * conditionaly update libtool macros Oct 13 13:16:32 Signed-off-by: Martin Jansa Oct 13 13:16:32 03Martin Jansa  07master * rd198152868 10openembedded.git/recipes/openmoko-3rdparty/iliwi_git.bb: Oct 13 13:16:32 iliwi: add missing libgee DEPENDS Oct 13 13:16:33 Signed-off-by: Martin Jansa Oct 13 13:16:33 03Martin Jansa  07master * r6620f48c61 10openembedded.git/recipes/python/python-numeric_24.2.bb: Oct 13 13:16:34 python-numeric: add newer version 24.2 Oct 13 13:16:34 Signed-off-by: Martin Jansa Oct 13 13:16:35 03Martin Jansa  07master * r917c5db519 10openembedded.git/recipes/python/python-setuptools_0.6c11.bb: Oct 13 13:16:36 python-setuptools: add newer version 06c11 Oct 13 13:16:36 Signed-off-by: Martin Jansa Oct 13 14:24:23 hi, anyone any opinion on this patch: http://article.gmane.org/gmane.comp.handhelds.openembedded/37920 Oct 13 14:27:32 looked, no opinion :) Oct 13 14:27:36 grr Oct 13 14:27:47 cross built program cores, but native version does not Oct 13 14:27:55 Crofton|work: ty :-) Oct 13 14:28:54 Crofton|work: btw you just expressed an opinion; it's like with choices, if you have to choose something and you don't you still make a choice :-) Oct 13 14:31:07 I know the song Oct 13 14:32:02 morning Oct 13 14:32:40 hi kergoth Oct 13 14:32:42 gm Oct 13 14:39:17 03Koen Kooi  07org.openembedded.dev * r252263269e 10openembedded.git/recipes/gnome/libwnck_2.30.5.bb: libwnck: add 2.30.5 Oct 13 14:49:49 03Koen Kooi  07org.openembedded.dev * r7bda87f8ed 10openembedded.git/recipes/gnome/libwnck_2.30.5.bb: libwnck 2.30.5: add missing dep on gobject-introspection-native Oct 13 14:58:53 morning Oct 13 15:03:59 later ... Oct 13 15:15:18 03Koen Kooi  07org.openembedded.dev * r859ea36cfc 10openembedded.git/recipes/imagemagick/imagemagick_6.4.4-1.bb: Oct 13 15:15:19 imagemagick: enable libtoolize Oct 13 15:15:19 This is needed for libtool 2.4 and has no ill effects on libtool 2.x builds Oct 13 15:36:28 03Tom Rini  07org.openembedded.dev * rcaff621a72 10openembedded.git/recipes/gdb/gdb-cross-sdk.inc: Oct 13 15:36:28 gdb-cros-sdk.inc: Update our DEPENDS list Oct 13 15:36:28 Since we statically link, we don't want to depend on the Oct 13 15:36:28 -sdk version of things but do want to depend on the -native Oct 13 15:36:28 version. We also need to depend on expat-native. Oct 13 15:36:29 Signed-off-by: Tom Rini Oct 13 16:16:08 jo Oct 13 16:17:02 woglinde: hey! Oct 13 16:17:34 zecke, you are back in .de now? Oct 13 16:17:40 anybody has problems with the gobject-introspection recipe? Oct 13 16:17:53 Crofton|work: yes Oct 13 16:18:39 hopefully this is a good thing Oct 13 16:19:02 Crofton|work: so so... I know why I am doing it. so i am happy Oct 13 16:19:09 good Oct 13 16:19:30 03Koen Kooi  07org.openembedded.dev * rc2fa8f142e 10openembedded.git/recipes/mikmod/mikmod_3.2.2-beta1.bb: Oct 13 16:19:30 mikmod: remove hack to work around powerpc toolchain bugs from 3 years ago Oct 13 16:19:30 Also run oe-stylize on it Oct 13 16:21:13 khem: ping Oct 13 16:22:01 crofton yeah I have zecke back Oct 13 16:26:13 morphis: whats up Oct 13 16:27:09 jo khem Oct 13 16:27:14 khem: I have some question about one of your oe commits Oct 13 16:27:21 khem: it is this one: http://git.openembedded.net/cgit.cgi/openembedded/commit/?id=88cb8237bcad77fc2a64a1e84b6be63c94ce8b58 Oct 13 16:27:28 woglinde, take care fo him :) Oct 13 16:27:43 khem: I don't get libgee compiling with the dependency on gobject-introspection Oct 13 16:28:03 khem: and before you changed it it depended on gobject-introspection-native and not on gobject-introspection Oct 13 16:28:15 jo stefan Oct 13 16:28:22 hi all Oct 13 16:28:24 hi woglinde Oct 13 16:28:30 hey stefan_schmidt ! Oct 13 16:28:34 hi morphis Oct 13 16:30:03 khem: so you just misses the depency on *-native or is this right and I understand something wrong? Oct 13 16:31:11 morphis: hmm Oct 13 16:31:35 In one of my responses I noted that this DEP can be removed safely Oct 13 16:31:43 ah ok Oct 13 16:31:44 Paul was testing it Oct 13 16:32:03 can you remove this line and do a build of libgee and libgee-native Oct 13 16:32:12 jepp Oct 13 16:32:27 ok plz do I will wait Oct 13 16:32:30 the depend on glib-2.0 too? Oct 13 16:32:33 * khem can use some more hands Oct 13 16:32:37 no Oct 13 16:32:47 only introspection Oct 13 16:32:59 ok Oct 13 16:33:06 is running Oct 13 16:33:18 03Koen Kooi  07org.openembedded.dev * r8f7bd5f92f 10openembedded.git/recipes/mikmod/mikmod_3.2.2-beta1.bb: mikmod: libtool 2.4 fix 2/2: sed out -L/usr/lib from gcc cmdline Oct 13 16:33:55 is libtool 2.4 in master ? Oct 13 16:34:02 hmm koen the real fix is to update libtool macros not sed Oct 13 16:34:10 but he is not in this room Oct 13 16:34:17 dj-death: yes Oct 13 16:34:35 if you want to use angstrom-2010 uses it as default Oct 13 16:34:42 khem koen only finds the poorman solution Oct 13 16:34:54 heh Oct 13 16:35:12 Crofton|work: why does gnuradio need a given version of libusb Oct 13 16:35:32 khem the damn libusb0 libusb1 stuff Oct 13 16:35:34 Crofton|work: gnuradio recipe is more complex than gcc Oct 13 16:35:52 khem: I just want the patches to push them in buildroot ;) Oct 13 16:35:59 oh gnuradio still wants libusb0 Oct 13 16:36:19 dj-death: good, give credit to OE if you will Oct 13 16:37:53 yeah Oct 13 16:38:17 crofton than gnuradio suckz *g* Oct 13 16:38:26 I need to push a new recipe at some point that should solve all these issues Oct 13 16:38:46 by adding uhd support, I can get rid of the libusb issues Oct 13 16:38:58 khem: I haven't had a lot of success with the OE patches Oct 13 16:39:16 khem: I was more lucky with the patch from stlinux Oct 13 16:39:26 dj-death: ok. Oct 13 16:39:42 I dont know how you are using it and how buildroot sets us staging Oct 13 16:39:50 khem: I guess I'll have to rebase it on top of libtool 2.4 Oct 13 16:40:14 Crofton: please do so Oct 13 16:40:26 now? Oct 13 16:40:30 Crofton: and delete the old mess at same time Oct 13 16:40:34 yeah Oct 13 16:40:38 I will delete the old mess Oct 13 16:40:43 Crofton|work: any time you feel sooner the better Oct 13 16:40:47 since I am aware of the user base :) Oct 13 16:41:05 well, I need to check on the state of public uhd releases :) Oct 13 16:41:50 khem: have you noticed that libtool now adds a --with-sysroot option to the configure scripts Oct 13 16:42:23 khem: I can't see where you're using it in OE Oct 13 16:42:34 maybe you don't Oct 13 16:42:44 dj-death: it does not add. It uses it Oct 13 16:42:50 and you have to add it to configure Oct 13 16:42:59 its done in the autotools class Oct 13 16:43:09 ok Oct 13 16:43:13 why dont you use OE Oct 13 16:43:21 I didn't notice it before Oct 13 16:43:36 OE or the option o.0 Oct 13 16:44:47 khem: because I tried, and I wasn't happy with the 20Go of packages to compile to generate a 9Mb filesystem with only dbus/busybox/udev Oct 13 16:47:35 dj-death the root if evil ist bluetooth Oct 13 16:47:38 *g* Oct 13 16:47:43 which include all sound stuff Oct 13 16:48:01 woglinde: dbus too Oct 13 16:48:03 which includes half of gnome Oct 13 16:48:11 woglinde: it brings all the x11 stuff Oct 13 16:48:18 hm yes Oct 13 16:48:34 woglinde: last time I spent 2 days fixing the dependencies Oct 13 16:48:38 you could write your own none dbus-x11 recipe Oct 13 16:48:46 I got all the gnome stuff removed Oct 13 16:48:48 shouldnt be that hard Oct 13 16:48:58 but still the x11 stack remained compiled Oct 13 16:49:30 yep Oct 13 16:49:30 2 days? Oct 13 16:49:37 we really need to fix that Oct 13 16:49:44 make it dependent upon DISTRO_FEATURES Oct 13 16:49:46 lol Oct 13 16:50:07 kergoth first solve the bluethooth stuff Oct 13 16:50:13 woglinde: looking at the dependency graph Oct 13 16:50:25 woglinde: then recompiling Oct 13 16:50:35 woglinde: then looking again Oct 13 16:50:47 o.o? Oct 13 16:51:02 why you didnt remove the uppermost root Oct 13 16:51:14 instead going down the whole tree Oct 13 16:51:18 or up Oct 13 16:51:34 because the root it probably the libc or something like that ;) Oct 13 16:51:38 and I need it ;) Oct 13 16:52:00 no, it isn't. Oct 13 16:52:04 very few things pull in x11 Oct 13 16:52:09 khem: libgee builds fine with this, libgee-native too Oct 13 16:52:12 I'm agree, spending some times on OE would definitely help Oct 13 16:52:26 we'd love to see these things improve, you're not the first one to have issues in this regard Oct 13 16:52:30 jsut make sure it does not break otehr peoples stuff Oct 13 16:52:34 bluetooth is why we need better / more use flags Oct 13 16:52:36 and lead to insane builds Oct 13 16:52:37 but buildroot has a nice external toolchain support Oct 13 16:52:37 i mean DISTRO_FEATURES Oct 13 16:52:53 with OE it's much more complicated Oct 13 16:53:40 gm Oct 13 16:54:14 changing BT to only pull in the gui bits based on distro features is probably an afternoon's work Oct 13 16:54:18 just nobody's sat down to do it Oct 13 16:54:38 agree Oct 13 16:54:44 would be nice to have Oct 13 16:56:07 maybee we can peek effem into it Oct 13 16:56:09 *g* Oct 13 16:57:00 Any of the kalieos folks here? Oct 13 16:57:31 woglinde: any idea to speed up the recipes parsing ? :) Oct 13 16:57:44 dj-death haha ask kergoth Oct 13 16:58:24 well you can use BBMASK to mask of stuff you dont want to parse Oct 13 16:58:55 is there page that list all the usable variables ? Oct 13 16:59:13 such a page wouldn't be very useful Oct 13 16:59:33 for parse time, work is being done about it, multiple people have looked into doing the parsing in parallel when you have multiple cores Oct 13 17:01:14 03Tom Rini  07org.openembedded.dev * ra92b388ff7 10openembedded.git/ (6 files in 3 dirs): Oct 13 17:01:15 tiff: Update to 4.0.0beta6 Oct 13 17:01:15 This includes a number of security fixes. In addition, side-port Oct 13 17:01:15 the fix for CVE-2010-2482. Since we updated for security reasons Oct 13 17:01:15 and there was only one version before this (the previous beta), Oct 13 17:01:15 git mv and update the distros that had pinned down. Oct 13 17:01:15 Signed-off-by: Tom Rini Oct 13 17:02:25 kergoth: BTW: do you know if my script is of any use for tim rini? Oct 13 17:02:38 zecke ask himself Oct 13 17:02:44 dj-death: nuke all recipes that you do not need, I once did this for my project, with 5 lines of rm statements I managed to get rid of 3000 recipes or so Oct 13 17:02:51 * woglinde points to tartarus Oct 13 17:03:02 (no need for opie/openmoko/gpe/x11 etc on that system) Oct 13 17:03:04 morphis: thx Oct 13 17:03:13 woglinde: nick name? Oct 13 17:03:29 19:00 * woglinde points to tartarus Oct 13 17:03:40 dj-death: you can be one of the good users for low end use of OE Oct 13 17:03:42 and uclibc Oct 13 17:03:52 uclibc rockz Oct 13 17:03:54 *g* Oct 13 17:03:59 I have always tried to maintain uclibc port healthy Oct 13 17:04:09 and woglinde Oct 13 17:04:18 yes Oct 13 17:04:32 but we have do something about the config stuff Oct 13 17:04:53 should be generic target for each arch Oct 13 17:05:08 because we are setting compiler flags our self Oct 13 17:05:20 args should be using Oct 13 17:05:22 zecke: which script? Oct 13 17:05:22 hi gnutoo Oct 13 17:05:29 hi woglinde Oct 13 17:05:39 do you guys have any idea of the footprint of uclibc versus dietlibc and newlib ? Oct 13 17:05:41 how's things going? Oct 13 17:05:42 hey zecke, what script? Oct 13 17:05:57 eFfeM, there were some comparison done by free electron Oct 13 17:06:15 but dietlibc and newlib aren't very compatible Oct 13 17:06:31 ah ok Oct 13 17:06:45 Tartarus: hi, do you manually look for CVEs? Four months back I was writing a script to go through the FreeBSD port database and compare vulnerabilities with our versions Oct 13 17:07:08 Ah, yes, I had forgotten that Oct 13 17:07:22 saw we had a dietlibc recipe, but minimal didn't like it somewhere it does an include of distro/include/${LIBC}.inc and dietlibc.inc does not exist Oct 13 17:07:35 So what I've got is the CVE database (partial) in google docs + some javascript to hide a bunch of stuff Oct 13 17:07:47 Then it's just manual read/hide Oct 13 17:07:58 The triage isn't nearly so hard as the backporting when required Oct 13 17:08:26 Tartarus: contrib/oeaudit contains my script Oct 13 17:09:24 args Oct 13 17:09:26 khem: do you prepare a patch and commit it? Oct 13 17:09:27 re Oct 13 17:09:31 damn connection Oct 13 17:10:06 khem did my rant over our uclibc config occur? Oct 13 17:10:12 morphis, hi Oct 13 17:10:14 morphis: you are most welcome to post it to ml as you have done the testing Oct 13 17:11:04 eFfeM: dietlibc and klibc are not full C libraries Oct 13 17:11:25 dietlibc can compile a lot of tools Oct 13 17:11:39 arguably they can be used as C library alternatives but havent done so Oct 13 17:11:58 woglinde: thats true but you need compiler tools to configure to use them Oct 13 17:12:12 and thats not that easy as we have done it for uclibc eglibc or glibc Oct 13 17:12:14 khem: ok, will do that Oct 13 17:12:16 GNUtoo|laptop: hey Oct 13 17:12:40 o.O? Oct 13 17:12:49 khem, ah ok Oct 13 17:12:56 diet only needs some teaching about ccache and stuff Oct 13 17:13:04 but my last attempt segfaults now Oct 13 17:13:20 was looking for ways to see how to reduce my image (which only has a few small utitlities) Oct 13 17:13:29 khem I already put dietlibc stuff in Oct 13 17:13:34 actually also interested on how to do a static build Oct 13 17:13:38 and diet.bbclass Oct 13 17:14:10 khem, btw did a bitbake -cclean curl-native; and restarted the build, now it did proceed; no idea what was wrong yesterday Oct 13 17:14:42 look for toolchains in free electron Oct 13 17:14:44 let me find the link Oct 13 17:15:15 http://free-electrons.com/doc/toolchains.pdf Oct 13 17:15:23 they do some rough comparaisons Oct 13 17:15:35 is there a way to force static linking in oe (for all recipes), e.g. adding -Bstatic in LDFLAGS in my conf file ? Oct 13 17:15:48 GNUtoo|laptop: thanks for the link Oct 13 17:16:50 eFfeM: TARGET_CC_ARCH += "-static" Oct 13 17:16:56 in your local.conf Oct 13 17:16:59 eFfeM: -Bstatic is an ld option, you probably just want -static or -Wl,-Bstatic or something, but you'd also want to make sure you have --enable-static in your EXTRA_OECONF Oct 13 17:17:18 yw Oct 13 17:17:20 I'll eat Oct 13 17:17:36 better enable-static disable-shared Oct 13 17:17:46 eFfeM: But also, what're you hoping for? :) Oct 13 17:17:56 khem, kergoth thanks Oct 13 17:18:03 ie making all the -cross-sdk stuff use only static libs can be hard Oct 13 17:18:13 need a rather empty host Oct 13 17:18:18 static linking is does not have coolness factor Oct 13 17:18:35 hehe Oct 13 17:18:38 Tartarus: this is not for cross-sdk, let me explain Oct 13 17:18:56 I am thinking what happens if we punt out .la Oct 13 17:18:59 completely Oct 13 17:19:06 dont install them at all Oct 13 17:19:27 and we take care of dependencies via bitbake DEPENDS Oct 13 17:19:57 I guess it will work Oct 13 17:20:07 eFfeM: k. Just sayin', depending on what you're trying to do there's other stuff that needs twiddling Oct 13 17:20:09 I have a kernel that boots from SD, this is fairly slow, but it is used in factory to flash the nor of my board; idea is to minimize the kernel and rootfs; basically it has few busybox applets, a few mtdtools utilities, i2c-tools and probably urjtag to program a CPLD Oct 13 17:20:23 yeah Oct 13 17:20:30 look into mklibs, perhaps Oct 13 17:20:35 03Koen Kooi  07org.openembedded.dev * rb2d4cb84a1 10openembedded.git/recipes/totem/totem-pl-parser_2.30.0.bb: Oct 13 17:20:35 totem-pl-parser 2.30.0: fix build with libtool 2.4 sysroot Oct 13 17:20:35 * also disable introspection Oct 13 17:20:53 See if you really can't get by w/ just busybox + your custom tool Oct 13 17:20:54 and the image to flash is a rescue kernel and rfs, also with limited functionality Oct 13 17:21:01 newer BBs have a lot of applets written Oct 13 17:21:04 and that links statically fine Oct 13 17:21:20 Tartarus: anyway, maybe you have time to look at the script, it turned up many issues Oct 13 17:21:22 exit Oct 13 17:21:29 no not you Oct 13 17:21:30 Tartarus: and then freebsd is also a good place to search for patches Oct 13 17:21:31 me Oct 13 17:21:44 zecke, thanks, i'll keep it in mind Oct 13 17:21:45 yeah did not try busybox-static yet; rest then shoudl also be static, we did tweak the applets that are build Oct 13 17:22:12 Oh that's right, there's a busybox-static recipe too :) Oct 13 17:22:19 But you'll probably want a custom BB config Oct 13 17:22:20 yup Oct 13 17:22:25 yes, I already have Oct 13 17:22:27 (ie turn on all the mtd stuff in BB) Oct 13 17:22:27 k Oct 13 17:22:37 it is in files/ in my overlay Oct 13 17:23:22 btw I seem to recall we also had problems with cairo or so and eglibc, not sure about details (and the guy who works on that is on vacation, lucky B.) Oct 13 17:26:47 GNUtoo|laptop: read the free-electrons doc; it only gives data for uclibc and glibc, not for the others Oct 13 17:34:43 jo mickeyl Oct 13 17:34:48 eFfeM, ok but it says that for the others: Oct 13 17:35:04 good evening woglinde Oct 13 17:35:24 They need specially written programs and applications Oct 13 17:35:42 because: Oct 13 17:35:51 "but none of them have the goal of allowing the compilation of large existing applications" Oct 13 17:35:55 so it depends on your apps Oct 13 17:37:31 GNUtoo|laptop: agree Oct 13 17:37:46 khem: hi, did you have time to look at that libtool patch I've posted here? Oct 13 17:37:59 hi jama Oct 13 17:38:04 where is the time that libc only did ansi C functions and for other things you would use other libs Oct 13 17:38:16 effem haha Oct 13 17:38:27 woglinde: hi Oct 13 17:39:18 * eFfeM learned C from K&R 1st edition, before function prototypes existed, let alone ansi c Oct 13 17:39:55 uh Oct 13 17:40:01 ice is driving to lonodon Oct 13 17:40:34 effem so you are god of pointers? Oct 13 17:40:38 JaMa: the patch intention is ok but patch is a bit off Oct 13 17:40:43 I have fixed it locally Oct 13 17:40:53 JaMa: let me post the new patch for you Oct 13 17:40:57 can you try that out Oct 13 17:42:11 woglinde: yeah, actually I invented the ultimate API, suitable for everything: char **doit(p) char **p; { } Oct 13 17:42:12 khem: this was patch for already generated libtool script so just wanted your opinion if it's right way .. Oct 13 17:42:17 no void at that time Oct 13 17:43:10 JaMa: http://pastebin.com/sfpHfryd Oct 13 17:43:12 for me C++ is just a struct with function pointers (just kidding :-) ) Oct 13 17:43:13 try that one Oct 13 17:43:37 eFfeM: heh there is much more to that Oct 13 17:45:35 hi khem Oct 13 17:46:36 the only C++ I could consume is the one used in Qt :) Oct 13 17:46:36 bbs Oct 13 17:46:46 hi ynezz Oct 13 17:46:47 GNUtoo|laptop: hello Oct 13 17:47:19 hi woglinde, ICE to London = you're heading to CELF? :) Oct 13 17:47:19 JaMa: hmm still I think that patch was wrong Oct 13 17:47:47 khem, I know Oct 13 17:48:25 ynezz no Oct 13 17:48:43 ICE to london is sheduled to 2013 Oct 13 17:48:50 ah, bummer Oct 13 17:48:54 now they only testing Oct 13 17:48:54 khem: it fixed the issue with sed call on non-existent file.. but as I said before, the root cause is probably even before that Oct 13 17:49:10 JaMa: ok Oct 13 17:49:12 ynezz I have no time this year Oct 13 17:49:23 and would fly rayn air from berlin Oct 13 17:49:37 ryan air is cheap and nice Oct 13 17:49:52 I flew once with them Oct 13 17:50:27 khem: what is your opinion on the best GCC version to use with ARM right now? Oct 13 17:50:52 khem: am I right that Angsrom is still using 4.3.3? Oct 13 17:50:52 it depends on the ARM version I think :) Oct 13 17:50:58 ynezz yes Oct 13 17:51:06 * woglinde thinks that too Oct 13 17:51:14 cbrake: 4.5 Oct 13 17:51:14 yep, angstrom 2008.1 uses 4.3.3 Oct 13 17:51:15 for cortex a8 the one in oe Oct 13 17:51:30 cbrake: but thumb1 is a bit ignored Oct 13 17:51:39 in 4.5 which is sad but true Oct 13 17:51:50 cbrake: for armv7 no second thought Oct 13 17:51:52 khem: what about for PXA270? Oct 13 17:52:12 cbrake: I think it is better Oct 13 17:52:31 although it does not improve the usage of iwmmxt Oct 13 17:52:43 khem: nod -- tradeoffs :-\ Oct 13 17:52:51 which is the thing that separates PXA Oct 13 17:53:01 from rest of armv5te Oct 13 17:53:31 khem: we are interested in using iwmmxt, but have not succesfully to date Oct 13 17:54:06 khem: the app guys want to use some tr1 functional stuff that works in 4.4.3 Oct 13 17:54:41 cbrake: yeah, wmmxt used a different ABI Oct 13 17:54:48 it was a stupidity Oct 13 17:54:52 khem: your version of that patch should be applied as last patch? after resolve-sysroot.patch right? Hunk #1 FAILED at 8479 the other 2 with small offset Oct 13 17:54:54 #include Oct 13 17:55:03 cbrake: I think you could try 4.5 Oct 13 17:55:18 khem: does minimal default to that? Oct 13 17:55:20 and see if vectorizer kicks in wmmx code which I doubt Oct 13 17:55:25 cbrake: yes Oct 13 17:55:34 khem: ok, I'll give it a try ... Oct 13 17:55:59 crbake hm are you going to make some benchmarks? Oct 13 17:56:19 hrms we need and easy benchmark tool in oe Oct 13 17:56:23 an Oct 13 17:56:39 woglinde: it would be pretty easy to run if I succeed as I'll have older 4.3.3 systems laying around Oct 13 17:56:59 crbake would be nice to see if uclibc is faster in some niches Oct 13 17:57:07 woglinde: JaMa and I did some benchmarking few months back Oct 13 17:57:18 sakrah.dontexist.org Oct 13 17:57:23 khem hm yes Oct 13 17:57:36 few months is few months Oct 13 17:57:52 those were from spitz :) Oct 13 17:58:01 hm cannt we automate it for testing-branch with qemu somehow? Oct 13 17:58:22 hm maybee a nice gsoc project for next year Oct 13 17:58:40 and then I've added also recipe for that version I was using recipes/unixbench/unixbench_5.1.2.bb Oct 13 17:59:39 I thought I remembered seeing a TI project in OE that contained dhrystone, whetstone, and a few others Oct 13 18:00:22 hm sure but nead would be some automatic submition to a website Oct 13 18:00:25 like tinderbox Oct 13 18:00:29 that would be cool Oct 13 18:00:43 and benchmark + qemu sounds funny :) Oct 13 18:00:53 or 2 convos going on at once? Oct 13 18:00:59 back Oct 13 18:00:59 tartarus sure Oct 13 18:01:12 thre is lmbench Oct 13 18:01:13 khem, JaMa any news on the pango+cairo issue? Oct 13 18:01:27 cbrake: qemu wont do much good on benchmarks its not cycle accurate Oct 13 18:01:32 tartarus but when we see regressions in qemu its a high indicator we will see regrations on real hw Oct 13 18:01:39 khem: also libtool-(native|cross|sdk|nativesdk)_2.4.bb are missing PR = "${INC_PR}.0" so PR==0 there, I'll add it ok? Oct 13 18:01:43 GNUtoo|laptop: we need more information Oct 13 18:01:58 JaMa: thats fixed in my to be pushed patch Oct 13 18:02:05 besides vectorazation stuff Oct 13 18:02:13 khem, what infos do you need? Oct 13 18:02:15 so lunch now Oct 13 18:02:16 GNUtoo|laptop: if you mean with gir, than talk with playya .. he has patch disabling gir in those.. Oct 13 18:02:20 args supper Oct 13 18:02:33 JaMa, no I mean the garbage in vala-terminal Oct 13 18:02:43 which is also problematic on palm-pre Oct 13 18:02:53 GNUtoo|laptop: ah.. didn't have time to look at it at all.. Oct 13 18:03:00 ok Oct 13 18:03:01 GNUtoo|laptop: pin the issue a bit more Oct 13 18:03:04 GNUtoo|laptop: still too far from successfull image build Oct 13 18:03:17 JaMa, ok Oct 13 18:03:18 GNUtoo|laptop: if possible in the source Oct 13 18:03:34 GNUtoo|laptop: I dont have devices where I could reproduce the issue myself Oct 13 18:03:38 khem, I'll try to re-find the commands Oct 13 18:03:50 but with x backend with pango it was a clean image Oct 13 18:03:58 but with cairo backend we had garbage Oct 13 18:04:12 GNUtoo|laptop: ok cairo it is Oct 13 18:04:22 khem, I bet it's armv7 specific not device specific Oct 13 18:04:30 GNUtoo|laptop: I am afraid we might have to debug it Oct 13 18:04:33 yes it seem to be cairo Oct 13 18:04:34 ok Oct 13 18:05:34 GNUtoo|laptop: install the cairo version from old ipks Oct 13 18:05:42 may be replace library by library Oct 13 18:05:45 I don't have them anymore Oct 13 18:05:47 and see which library is causing it Oct 13 18:05:54 but I can try with shr feeds Oct 13 18:06:00 GNUtoo|laptop: search on angstrom mirror Oct 13 18:06:27 ok Oct 13 18:06:42 or I install a non-armv7 version? Oct 13 18:07:23 if there is a feed for your device Oct 13 18:07:28 otherwise rebuild it Oct 13 18:08:36 eFfeM: did you send last oe-devel e-mail 4 times or my mutt is just going crazy? Oct 13 18:11:16 wget http://www.angstrom-distribution.org/feeds/unstable/ipk/glibc/armv7a/base/libcairo2_1.10.0-r0.6_armv7a.ipk Oct 13 18:11:21 and installing it Oct 13 18:11:27 makes vala-terminal work Oct 13 18:11:46 nice Oct 13 18:15:12 JaMa, with a patch I'm able to build (from scratch) fso2-demo-image Oct 13 18:15:55 for om-gta02 Oct 13 18:18:44 GNUtoo|laptop: but my current build is using libtool-2.4... Oct 13 18:18:48 GNUtoo|laptop: ok now if you can change library by library Oct 13 18:19:00 and see which one is really causing trouble Oct 13 18:19:16 khem, I changed only one library and it solved my issue Oct 13 18:19:21 which is libcairo2 Oct 13 18:19:42 JaMa, ah ok so gir/introspection issues are fixed? Oct 13 18:19:59 GNUtoo|laptop: hmm ok Oct 13 18:19:59 because I did that for libgee: Oct 13 18:20:01 cool Oct 13 18:20:09 GNUtoo|laptop: no.. Oct 13 18:20:29 http://pastebin.com/VKdEwTYU Oct 13 18:20:57 and I was able to build fso2-demo-image Oct 13 18:23:20 GNUtoo|laptop: you dont need DEPENDS_virtclass-native = "glib-2.0-native" Oct 13 18:23:29 ok Oct 13 18:23:33 that should be constructed by BBCLASSEXNTEND Oct 13 18:23:36 ok Oct 13 18:23:37 GNUtoo|laptop: that's the same as I'm using locally and on SHR buildhost.. but after rebuild from scratch many recipes will turn gir on (from autodetection) after you build gir once Oct 13 18:23:48 ok Oct 13 18:24:04 GNUtoo|laptop: and you can keep gir-native dependency as mickey did in his workaround Oct 13 18:24:13 ok Oct 13 18:26:11 khem: even with this patch I get sysroot resolved twice ie from gst-plugins-ugly: | /bin/sed: can't read /OE/tmpdir-shr/sysroots/armv4t-oe-linux-gnueabi/OE/tmpdir-shr/sysroots/x86_64-linux/usr/armv4t/arm-oe-linux-gnueabi/lib/libstdc++.la: No such file or directory Oct 13 18:26:58 JaMa: thats a different problem Oct 13 18:27:06 we need to fix libstdc++ for that Oct 13 18:33:32 khem: are you sure it's libstdc++ problem? see http://paste.pocoo.org/show/275084/ I guess that libtool should strip sysroot prefix properly before putting = there, no? Oct 13 18:37:41 Minor question: I need to link against curl, so I tried to add "DEPENDS_${PN} = "curl"". In devshell, pkg-config libcurl --cflags shows a valid path, but the directory it gives is empty. I'm not using rm_work. How can I use libcurl's include files? Oct 13 18:37:56 khem: ah, nvm I see it's not armv4t sysroot, so it cannot replace it Oct 13 18:41:40 still looking for feedback on http://article.gmane.org/gmane.comp.handhelds.openembedded/37920 Oct 13 18:41:43 anyone ? Oct 13 18:42:31 jama, i think it is mutt Oct 13 18:43:28 JaMa: see http://thread.gmane.org/gmane.comp.handhelds.openembedded Oct 13 18:43:33 Ah, I think I wanted curl-config --cflags, not pkg-config curl --cflags. Oct 13 18:45:31 ...no, that's not it. That gives -native, which is different, as things like "int" have different sizes. Oct 13 18:47:17 here's a good one, I ahve an app that when cross built with OE segfaults, but runs when built native Oct 13 18:55:25 xobs: DEPENDS_${PN} is meaningless. Oct 13 18:55:45 xobs: you want DEPENDS, or RDEPENDS_${PN}, but more likely DEPENDS, as the runtime will automatically be generated based on what you link against. Oct 13 18:59:50 kergoth_: Good catch. I tried that because DEPENDS wasn't doing anything. Oct 13 19:00:18 if that was the case, you had something else going on, DEPENDS_${PN} won't be used by bitbake at all Oct 13 19:00:36 kergoth_: It looks like the problem was I was using devshell, which apparently doesn't re-evaluate DEPENDS. Oct 13 19:00:48 devshell runs after patch Oct 13 19:00:56 the recipe's deps aren't built at that time Oct 13 19:01:04 you'd want to bitbake -c configure it first, then fire up the devshell Oct 13 19:01:31 it may help to remember that bitbake internally operates at a task level, including dependencies Oct 13 19:01:35 so RDEPENDS needs a package name Oct 13 19:01:42 and DEPENDS just needs a recipe Oct 13 19:01:47 deps in DEPENDS translate to a dependency from configure/compile onto populate_sysroot in the depended items Oct 13 19:02:40 since you are disucssing RDEPENDS_${PN}: what about this: http://article.gmane.org/gmane.comp.handhelds.openembedded/37920 Oct 13 19:03:29 eFfeM: that looks reasonable, though ideally it'd be smarter than that -- you'd really want those deps for any packages emitted that include kernel modules Oct 13 19:04:19 kergoth, it was the best I could come up with, with my knowledge of python and the build system, if you have an improvement: greatly appreciated Oct 13 19:04:42 btw where does libfontconfig1 come from? since today or maybe yesterday I get: Oct 13 19:04:43 NOTE: Runtime target 'libfontconfig1' is unbuildable, removing... Oct 13 19:04:44 Missing or unbuildable dependency chain was: ['libfontconfig1'] Oct 13 19:05:26 but grep -r libfontconfig1 recipes does not reveal anything, and there is also no recipe named libfontconfig1 Oct 13 19:06:01 eFfeM: using debian.bbclass for debian lib names? Oct 13 19:07:30 could be Oct 13 19:07:41 it is something I got, not something I made Oct 13 19:08:28 think it is Oct 13 19:08:38 eFfeM: ie recipes/preboot/initramfs-preboot-image.bb has fontconfig in IMAGE_INSTALL which is renamed to libfontconfig1 in debian.bbclass Oct 13 19:09:30 ending with ERROR: '['/OE/dev/recipes/preboot/initramfs-preboot-image.bb']' RDEPENDS/RRECOMMENDS or otherwise requires the runtime entity 'libfontconfig1' but it wasn't found in any PACKAGE or RPROVIDES variables Oct 13 19:10:16 ah ok Oct 13 19:10:25 lets see if uclibc 0.9.31 builds Oct 13 19:10:42 JaMa: how did you find this Oct 13 19:11:34 what? Oct 13 19:12:18 JaMa: the initramfs-preboot-image.bb usage and the error Oct 13 19:12:31 * eFfeM does not understand why he didn't get this before Oct 13 19:16:08 * JaMa guess it's because those RDEPENDS patches, and I've just noticed in my builds (not using initramfs-preboot-image at all) Oct 13 19:17:34 ah ok Oct 13 19:22:58 btw also seem to getthing this for a few weeks or so: Oct 13 19:22:59 NOTE: multiple providers are available for runtime module-init-tools-depmod (module-init-tools, module-init-tools-cross) Oct 13 19:23:18 any thoughts on that (apart from defining a preferred provider) Oct 13 19:32:31 03Frans Meulenbroeks  07org.openembedded.dev * r7e8f12e3c6 10openembedded.git/recipes/u-boot/ (u-boot-git/dont-inline-weak-symbols.patch u-boot_git.bb): Oct 13 19:32:31 u-boot_git: added dont-inline-weak-symbols patch for hawkboard Oct 13 19:32:31 u-boot did not build for hawkboard due weak symbols and inlining. Oct 13 19:32:31 this is a known issue with u-boot 2009.8 and git versions shortly after that Oct 13 19:32:31 added the already existing patch to SRC_URI_hawkboard Oct 13 19:32:31 Signed-off-by: Frans Meulenbroeks Oct 13 19:41:17 03Martin Jansa  07master * r9ac50f2494 10openembedded.git/recipes/ffalarms/ (ffalarms/ical.timezone.patch ffalarms_git.bb): Oct 13 19:41:17 ffalarms: fix build with newer vala Oct 13 19:41:17 * ffalarms.vala:142.9-142.16: error: TimeZone is an ambiguous reference between GLib.TimeZone and ICal.TimeZone Oct 13 19:41:17 Signed-off-by: Martin Jansa Oct 13 19:42:48 hm, moved to libtool 2.4, but when building it, iI get Oct 13 19:42:49 help2man: can't get `--help-all' info from i686-linux-libtool Oct 13 19:43:41 what did I do to deserve this? Oct 13 19:45:29 http://tinderbox.openembedded.net/builds/95736/ Oct 13 19:46:29 eFfeM: shouldn't you build libtool-native and -cross first? Oct 13 19:47:54 where i can send my reciept ? Oct 13 19:48:06 eh, i hoped it would do itself, actually what I did is set 2.4 as preferred version in my local.conf then started building my image Oct 13 19:48:23 eFfeM: then you should set preferred versions for all libtool recipes Oct 13 19:48:32 eFfeM: see koen's commit Oct 13 19:48:32 aaah ofc Oct 13 19:51:06 yeah, got it, rebuilding Oct 13 19:51:07 re Oct 13 20:01:17 Can someone please try building c-ares? I'm running Angstrom, and I was having problems with its configure.ac. I have a patch, and want to make sure I need to post it. Oct 13 20:02:59 xobs: in a few min's I can, at task 5549 of 5550 so my build is almost done Oct 13 20:02:59 xobs didnt try it Oct 13 20:05:19 one library need libuuid, what should I use for RDEPENDS += ? Oct 13 20:05:27 can't find any provider in OE Oct 13 20:06:24 ynezz: need as in linking to it? or as in dlopen? Oct 13 20:06:58 <_chase_> In OE should the "local" override take precedence over all the other overrides? Or for example should order of precedence be local->MACHINE->DISTRO.... or do I have this backwards? Oct 13 20:07:12 hm Oct 13 20:07:24 <_chase_> right now it seems like my overrides are least specific takes precedence over most specific. Oct 13 20:07:25 new openjdk release for security stuff Oct 13 20:07:36 zecke: probably link Oct 13 20:07:54 libuuid is coming from linux-utils Oct 13 20:08:06 tells me, that I need install uuid-dev Oct 13 20:08:08 -ng Oct 13 20:08:09 linux-utils? or util-linux-ng ? Oct 13 20:08:16 or both Oct 13 20:08:42 sorry, where can I send my reciept? Oct 13 20:09:01 xobs, c-ares fails here: Oct 13 20:09:02 | config.h:5:8: error: no macro name given in #undef directive Oct 13 20:09:09 in do_compile Oct 13 20:09:13 hm or e2fsprogs Oct 13 20:09:15 hm Oct 13 20:09:22 hm, libtool 2.4 looks like a pain :) http://pastebin.org/166681 Oct 13 20:09:43 util-linux 2.17 Oct 13 20:09:49 debian says Oct 13 20:09:52 ynezz why? Oct 13 20:09:59 dv not sure what receipt you want to send, but you can sned to hte openembedded mailing list Oct 13 20:10:14 ynezz remove the old libtool.m4 macros Oct 13 20:10:27 there are serval recipes showing this Oct 13 20:10:38 maybee we should build it in autotools.bbclass Oct 13 20:10:39 hm, it's a new one Oct 13 20:10:49 no Oct 13 20:10:50 ok, will do that, thanks Oct 13 20:11:03 we hit this with other libtool upgrades too Oct 13 20:11:10 new recipe, for zeromq Oct 13 20:12:20 do_configure_prepend() { rm ./libtool.m4; ./autogen.sh } ? Oct 13 20:12:45 no Oct 13 20:12:51 only the rm Oct 13 20:13:03 we are calling autogen.sh ourself Oct 13 20:13:04 eFfeM, simple reciept "iw" for iw tool to use nl80211 Oct 13 20:13:10 in autotools.bbclass Oct 13 20:13:20 dv ???? Oct 13 20:13:34 dv sent to mailinglist, preferably as git commit using git format-patch Oct 13 20:13:39 dont we already have iw in? Oct 13 20:14:01 dv http://wiki.openembedded.net/index.php/How_to_submit_a_patch_for_dummies Oct 13 20:14:09 woglinde_, i don't see it in my branch origin/stable/2009 Oct 13 20:14:16 uh Oct 13 20:14:25 stable isnt update really more Oct 13 20:14:30 only bugfixing Oct 13 20:14:35 dv, head has iw_0.9.20.bb Oct 13 20:14:58 eFfeM, it seems, 0.9.21 is fresh Oct 13 20:23:22 hmmm Oct 13 20:23:45 * kergoth_ thinks about reworking oe.unpack to connect a series of subprocess pipes together to fully extract something, rather than constructing shell pipelines Oct 13 20:24:03 subprocesses? Oct 13 20:24:17 python subprocess module, yes Oct 13 20:25:07  Oct 13 20:25:12 i'm thinking something like http://gist.github.com/624817 Oct 13 20:25:37 then just keep extracting and passing the stdout of previous to the next, until you run out of handlers Oct 13 20:25:48 hm I rather thought there some python modules Oct 13 20:26:00 i've already tried modifying unpack to use the python modules Oct 13 20:26:05 it slows down extraction by *50%* Oct 13 20:26:11 damn Oct 13 20:26:13 why this Oct 13 20:26:18 dunno, they're just slow, i guess Oct 13 20:26:34 no wrapper around the libs? Oct 13 20:26:45 what do you mean? Oct 13 20:26:57 oh, a libz wrapper ors omething? Oct 13 20:27:02 yes Oct 13 20:27:03 i think the current python extraction modules are pure python Oct 13 20:27:08 so it's no surprise its slow Oct 13 20:27:12 yes Oct 13 20:29:10 hm, http://pastebin.org/166717 Oct 13 20:29:14 I did distclean Oct 13 20:29:34 shouldn't it configure it before do_compile? Oct 13 20:30:55 libiconv Oct 13 20:31:16 oh fuck, I'm that blind Oct 13 20:31:18 :D Oct 13 20:38:45 03Tom Rini  07org.openembedded.dev * r278fe3bc04 10openembedded.git/recipes/udev/ (udev_141.bb udev_151.bb udev_154.bb): (log message trimmed) Oct 13 20:38:45 udev 141/151/154: Fix update-rc.d logic for udev-cache Oct 13 20:38:45 The way that functions are evaluated means that while Oct 13 20:38:45 we say append our update-rc.d addition for udev-cache Oct 13 20:38:45 ends up at the top of the postinst script meaning that Oct 13 20:38:45 $OPT is not set and this error will cause no udev rcN.d Oct 13 20:38:46 symlinks to be created until during the first boot which Oct 13 20:56:13 wtf Oct 13 20:56:50 llvm changed the 2.7 tar ball Oct 13 21:02:09 tartarus still there? Oct 13 21:04:23 eeks! Oct 13 21:04:29 pong Oct 13 21:04:45 hm Oct 13 21:04:51 celf registration is closed Oct 13 21:05:01 tartarus hm never minde Oct 13 21:05:30 seems the spoardic network problems here miss downloaded the newer freetype Oct 13 21:05:34 oh crap Oct 13 21:05:43 I didn't register Oct 13 21:06:20 Crofton|work: same here :-( Oct 13 21:06:58 from what i know this never was a problem before Oct 13 21:08:12 it never was Oct 13 21:08:28 * eFfeM is surprized too, but fortunately I did already register Oct 13 21:08:31 calling it a day now Oct 13 21:08:33 cya Oct 13 21:08:49 nite effem Oct 13 21:12:32 hrm.. nasty Oct 13 21:13:01 yeah Oct 13 21:13:05 I sent begging email Oct 13 21:14:37 why? Oct 13 21:14:55 closing registration is normal Oct 13 21:15:02 isnt there a on spot registration ? Oct 13 21:15:15 usually you can get to the place and register Oct 13 21:15:28 khem if its full Oct 13 21:15:34 you close the reg Oct 13 21:15:34 I have done it many times for other confs as I never make it in time Oct 13 21:15:39 woglinde_: ? Oct 13 21:15:48 florian? Oct 13 21:16:21 florian how will you stuff 200 people in a room for 100 people? Oct 13 21:17:11 well, they charged my card .... Oct 13 21:21:11 hi, all Oct 13 21:21:34 I successfully built an x11-gpe-image and dropped it on the device Oct 13 21:22:17 igork fine Oct 13 21:22:52 is there any way to start the gui remotely? for some reason, it didn't start and I am stuck at the console... Oct 13 21:23:38 I successfully calibrate my stylus and thats about it Oct 13 21:23:45 look at Xorg.log Oct 13 21:24:30 khem: after replacing those *.la with wrong libstdc++.la path I was able to build my image again, I was trying to fix also openldap but that one seems quite hard (using own version of libtool-1.5.22-OpenLDAP :/) Oct 13 21:24:53 ok, thx. Oct 13 21:25:19 jama what are you doing? Oct 13 21:25:23 JaMa: ok the problem is that we stage libstdc++ from gcc-cross and thats where it gets it wrong Oct 13 21:25:40 woglinde_: trying libtool-2.4 Oct 13 21:25:51 *g* Oct 13 21:25:56 wtf, this question about overrides precedence.. it couldn't have been broken this whole time, could it? Oct 13 21:26:01 we used to have metadata unit tests.. Oct 13 21:26:05 i must be reading this wrong Oct 13 21:26:10 khem: can't we just set different sysroot to libtool in gcc-cross? Oct 13 21:26:18 I think I should try to now get gcc divided to build libs separately Oct 13 21:26:32 * khem turns pages on poky Oct 13 21:26:49 khem unpack gcc source a forth time? Oct 13 21:26:53 JaMa: I have to look Oct 13 21:27:05 woglinde_: yes :) Oct 13 21:27:46 oh son of a bitch. Oct 13 21:27:49 i cannot believe this Oct 13 21:27:59 kergoth? Oct 13 21:28:01 hmm Oct 13 21:28:11 OVERRIDES precedence is backwards. Oct 13 21:28:11 possible kergoth is having a worse day than me Oct 13 21:28:18 {~oe} % bitbake -e | grep \^FOO Oct 13 21:28:18 1683:FOO="bar" Oct 13 21:28:18 3824:FOO_qemux86="bar" Oct 13 21:28:18 3958:FOO_local="baz" Oct 13 21:28:26 local is supposed to override everything else, not the other way around.. Oct 13 21:28:38 how did we not catch this? Oct 13 21:28:40 why not? Oct 13 21:28:53 the intent of overrides is to provide layering Oct 13 21:29:00 to allow more specific information to override less specific information Oct 13 21:29:15 kergoth_: yes local should be top prio Oct 13 21:29:38 {~oe} % bitbake -e | grep \^FOO Oct 13 21:29:38 1169:FOO_i686="fooo" Oct 13 21:29:38 1686:FOO="fooo" Oct 13 21:29:38 3827:FOO_qemux86="bar" Oct 13 21:29:44 worse yet, TARGET_ARCH is overriding MACHINE Oct 13 21:29:50 this is just plain broken. Oct 13 21:30:12 local->distro->machine->arch->libc Oct 13 21:30:28 that order sounds ok to me Oct 13 21:30:50 yeah, its backwards right now. lowest priority can override highest if both are defined Oct 13 21:31:06 kergoth: does it matter how the sequence is specified in OVERRIDES Oct 13 21:31:13 yes Oct 13 21:31:16 its highest to lowest Oct 13 21:31:22 but in the implementation, its lowest to highest Oct 13 21:31:24 kergoth_: it works as described in bitbake.conf Oct 13 21:31:26 hihi Oct 13 21:31:37 woglinde: http://pastebin.com/EFCviRLK. "No screen found." Any suggestion? Oct 13 21:31:48 IgorK1: buy a screen Oct 13 21:31:57 lol Oct 13 21:32:15 IgorK1 forgot some modules? Oct 13 21:32:31 igork1 which machine? Oct 13 21:32:39 nope, basic x11-gpe-image Oct 13 21:32:44 mini2440 Oct 13 21:33:07 JaMa: the comments match reality, but the variable's contents don't. note the comment says it should be defined in least to most specific, yet MACHINE is before TARGET_ARCH Oct 13 21:33:12 ieehls mini2440 again Oct 13 21:33:26 IgorK1 sorry no idea which xorg modul works on it Oct 13 21:33:41 kergoth_: and that _ramses doesn't override _arm if not used as _arm_ramses Oct 13 21:33:55 thats the priority Oct 13 21:33:55 that should not be necessary. Oct 13 21:34:02 and was not designed that way when i wrote the code Oct 13 21:34:15 igork1 hm ah Oct 13 21:34:21 the xorg.conf is wrong Oct 13 21:34:30 jama we have xorg 1.9 in oe? Oct 13 21:34:52 And finally '_local' overrides anything, but with lowest priority. Oct 13 21:35:26 i disagree with the placement of local here, local should be able to override everything else, left to the user's discretion Oct 13 21:35:32 and with the order of target_arch vs machine Oct 13 21:35:46 so bitbake is fine, we just need to tweak our OVERRIDES definition Oct 13 21:35:47 imo Oct 13 21:35:49 oder is low to high Oct 13 21:35:53 order Oct 13 21:36:32 kergoth_: we can just reverse it isnt it Oct 13 21:36:48 woglinde_: 1.9.1-rc1 Oct 13 21:37:41 khem: yeah, i think you're right. my only quesiton was pn-${PN}, but i think that being lowest priority is okay Oct 13 21:37:43 _arm_ramses will override when ARCH = arm AND MACHINE=ramses Oct 13 21:37:58 you should never have to use a double override when you really want *one* conditional Oct 13 21:38:02 yeah Oct 13 21:38:08 khem: kergoth_: see 70af4a882915cb51302734ca0de3b810f05df072 Oct 13 21:39:10 yes, that changes it to more closely match the definition, but the definition is wrong, in my opinion. Oct 13 21:39:12 around that day I've asked on ML (or here) if it's really right to be working this way.. Oct 13 21:39:24 kergoth_: yes I agree Oct 13 21:39:29 and i think those comments just make things *more* confusing Oct 13 21:39:30 not less Oct 13 21:39:32 because I've also expected it to work vice-versa Oct 13 21:39:34 I want local to override everything Oct 13 21:40:10 JaMa: '_arm_ramses' is confusingly decscrived Oct 13 21:41:11 i vote we kill the second paragraph of comments entirely when we reverse the overrides Oct 13 21:41:29 kergoth_: yes seems ok Oct 13 21:41:41 here is pb's explanation http://www.mail-archive.com/openembedded-devel@lists.openembedded.org/msg01497.html Oct 13 21:43:12 du we have a recommended hotel for oedem already? Oct 13 21:43:50 apart from the university arms :) Oct 13 21:44:05 rofl Oct 13 21:44:25 JaMa: "In your particular case, where you had MACHINE before TARGET_ARCH in overrides, it so happens that stacking up overrides in that fashion is the easiest way to work around the (arguably wrong) ordering of your overrides" Oct 13 21:44:45 he agrees its wrong Oct 13 21:44:46 heh Oct 13 21:45:06 meh Oct 13 21:45:39 if you reverse order in bitbake code, are we going to bump bitbake version requirement? to make it behave the same on every host? Oct 13 21:46:08 no point changing bitbake, thats a compatibility nightmare Oct 13 21:46:16 kergoth_: so foo_arm_ramses depends on the override order as I get it Oct 13 21:46:18 just reverse the overrides definition in bitbake.conf Oct 13 21:46:42 khem: yeah, its hacking it by ensuring that for that variable, the evaluation collapses it in the right order Oct 13 21:46:51 ah that was Maupin's patch now on ML Oct 13 21:46:52 kergoth_: yeah changing order in bitbake.conf and also in the distros who do not obey bitbake.conf Oct 13 21:46:57 like minimal.conf Oct 13 21:47:01 that too, i would've forgotten about that Oct 13 21:48:09 its minimal micro and shr I think Oct 13 21:48:12 thats it Oct 13 21:48:41 ugh Oct 13 21:48:49 4 *machines* redefine OVERRIDES Oct 13 21:48:56 bad developers, bad, no cookie for you Oct 13 21:49:03 which ones? Oct 13 21:49:06 git grep -E "OVERRIDES ?=" conf Oct 13 21:49:11 nslu Oct 13 21:49:32 http://pastebin.com/P3GWJ9GX Oct 13 21:50:04 why not puth MACHINE_CLASS to default OVERRIDES? Oct 13 21:50:09 and drop it from distro configs? Oct 13 21:50:13 if there's a need to *insert* items at a particular point, there should be a variable to do it Oct 13 21:50:30 yeah, exactly, redefining it is crap Oct 13 21:50:45 kergoth yeah make_space_between ( a, b) Oct 13 21:50:47 same issue with FILESPATHPKG, though -- the common case is injecting into the middle Oct 13 21:51:31 ideally, bitbake would have type support Oct 13 21:51:44 so you could just FOO[1:1] = "bar" or something Oct 13 21:51:47 it'd know its a list Oct 13 21:51:49 heh Oct 13 21:51:57 but at that point, might as well just use lua :P Oct 13 21:53:23 i keep reading shr-t as either shirt or shit Oct 13 21:53:45 t-shirt :) Oct 13 21:54:01 lol Oct 13 21:55:37 kergoth_: so, what do you mean by changing the definition of OVERRIDES? just the comment in bitbake.conf? Oct 13 21:56:00 hehe Oct 13 21:56:01 denix: the definition needs to be reversed. the order of elements in the variable Oct 13 21:56:11 then the crap discussed in the comments becomes irrelevent Oct 13 21:56:26 :) Oct 13 21:57:29 so, do you mean everywhere we append to OVERRIDES, we need to prepend now? :) Oct 13 21:57:42 no Oct 13 21:57:46 its likely that everyone changing it was doing so without giving any thought whatsoever to the order Oct 13 21:57:47 order is still same Oct 13 21:57:48 so.. Oct 13 21:58:12 if you append you get higher prio Oct 13 21:58:17 khem: yeah, order is the same, but I want "local" to be at the end Oct 13 21:58:19 your ass is bigger Oct 13 21:58:31 khem: thanks! Oct 13 21:58:51 denix: that was in conjunction with override not for you :) Oct 13 21:59:16 denix: you want local to be least prio you mean ? Oct 13 21:59:33 usually, local needs to be highest priority Oct 13 21:59:34 thats arguably what kergoth_ and I thought it wrong Oct 13 21:59:46 denix: right, the way its defined now, its the lowest Oct 13 21:59:49 yeah local should be highest prio Oct 13 21:59:50 but then again, MACHINE is now lower than ARCH Oct 13 21:59:57 right Oct 13 22:00:02 its all out of whack, just reverse it Oct 13 22:00:08 with change that kergoth is thinking about it will do as we intend Oct 13 22:00:50 local > distro > machine > arch seems ok order to me Oct 13 22:01:24 though, i could see an argument to flip distro/machine Oct 13 22:01:27 that's what I'm asking - if not reversing in bitbake's code, then we need to reverse everywhere we assign/append OVERRIDE, right? Oct 13 22:01:32 distro could be considered less specific than the machine Oct 13 22:02:08 denix: right, but again, i doubt anyone paid any attention whatsoever to the order anyway -- its not a common case, having multiple overrides on a single variable Oct 13 22:02:09 denix: unknowingly we have been doing right thing Oct 13 22:02:17 clearly its not a common case, since we haven't noticed.. Oct 13 22:02:17 but default order is wrong Oct 13 22:02:51 kergoth: distro and machine are similar to me but yes machine could be consoidered special Oct 13 22:03:14 well, if the distro's override isn't applied, a policy is changed Oct 13 22:03:20 if a machine override isn't applied, shit probably wont work Oct 13 22:03:21 :P Oct 13 22:03:28 heh true Oct 13 22:03:51 kergoth_: I did notice a year ago when I had to use PREFERRED_PROVIDER_virtual/kernel_shr_local in local.conf to override settings from machine config Oct 13 22:04:20 denix: if we have been appending and wanting the appended override to have higher prio over the existing list then it was right Oct 13 22:04:25 btw, SOC_FAMILY isn't very popular, but we have it inbetween MACHINE and ARCH in the OVERRIDES - that's how it was caught Oct 13 22:04:44 ah SOC_FAMILY Oct 13 22:05:06 khem: if you are correct, then bitbake's code need to reverse the order before processing Oct 13 22:05:46 right now we have a default order from bitbake.conf where local is least preferred Oct 13 22:05:54 i.e. machine > soc > arch Oct 13 22:05:59 JaMa|Zzzz: ah Oct 13 22:06:13 we're not changing bitbake Oct 13 22:06:16 it'd be a compatibility nightmare Oct 13 22:06:27 I dont think there is a need to change bitbake Oct 13 22:07:02 machine > soc > arch is still valid if its said like machine:soc:arch Oct 13 22:07:37 we prolly wont change that order others around it will change Oct 13 22:08:57 ~lart airlines Oct 13 22:09:00 * ibot pulls out his louisville slugger and uses airlines's head to break the homerun record Oct 13 22:09:08 * florian is not going to fly from Hahn! Oct 13 22:09:48 florian why not? Oct 13 22:10:18 args classpath sill has legacy staging mode Oct 13 22:10:52 woglinde_: way off in the middle of nowhere... the only useful way to go there is by car if the weather is fine... Oct 13 22:11:09 will change that tomorrow Oct 13 22:11:41 woglinde_: and only ryanair has flights to uk from there it seems Oct 13 22:11:51 sure Oct 13 22:11:54 its cheap Oct 13 22:12:51 that too cheap ;) Oct 13 22:15:38 isn't ryanair the airline that offers "standing" seats? :) Oct 13 22:16:57 hehe Oct 13 22:17:24 some are really no-go... Oct 13 22:17:51 easyjet because it is almost impossible to get a bill Oct 13 22:18:32 wizair because its incredible how the prices raise if you have luggage Oct 13 22:21:53 florian: take the train? Oct 13 22:22:20 zecke 2013 the ice will go to london Oct 13 22:22:24 zecke: might be an option... i was just about to check Oct 13 22:22:39 florian to brussel and then to lodon Oct 13 22:22:43 args london Oct 13 22:24:10 takes quite some time - 8 hours from here Oct 13 22:25:36 hrm great... you can book a train ticket but they are not able to tell how much it is?! Oct 13 22:26:12 yes Oct 13 22:26:20 because its outside germany Oct 13 22:27:29 this doesn't count Oct 13 22:27:52 just booked a train at a customer's site in italy... Oct 13 22:28:38 same for the other direction in germany - in both cases i got a price Oct 13 22:31:01 something must be broken there Oct 13 22:33:06 Can anyone think why zlib.inc mandates libtool-cross Oct 13 22:33:41 that seems reasonable for the target one, but not for the native Oct 13 22:33:52 Well, autotools.bbclass gets libtool deps Oct 13 22:33:59 khem, hate to bug you about this again but I still have issues building meta-toolchain b/c of failed gdb-cross-sdk - configure.ac:32: error: Please use exactly Autoconf 2.64 instead of 2.65. Oct 13 22:34:24 Tartarus: indeed, seems unnecessary Oct 13 22:34:33 don't see any patch equiv to what I posted in git: http://patchwork.openembedded.org/patch/3194/ Oct 13 22:35:07 Tartarus: the CFLAGS_EXTRA overrides for hte virtclasses look entirely unnecessary too. in native, arm won't be in overrides, unless the build machine is arm Oct 13 22:36:57 tharvey change the ac entry in configure.ac Oct 13 22:37:33 kergoth_: I have to believe that was done for a reason.. Oct 13 22:37:35 * Tartarus git logs Oct 13 22:38:01 you have more faith in people than i do, apparently Oct 13 22:38:30 heh Oct 13 22:38:31 kergoth_: :) Oct 13 22:38:40 woglinde, can you explain more? configure.ac from where? Oct 13 22:38:48 kergoth: YOu did it :) Oct 13 22:38:55 da26c362b6b32d52f755ca55bfc6cc0f9ddb42f6 Oct 13 22:39:46 oh, a gcc version incompatibility, that'd explain it Oct 13 22:39:54 i should have noted that in a comment Oct 13 22:42:16 its pretty ugly doing it that way though, just assuming that we ccan't use it on the build machine's compiler -- those sorts of options should really *check* the gcc version and respond to it in the general case Oct 13 22:42:23 but we don't have any infrastructure for that yet Oct 13 22:42:26 heh Oct 13 22:46:53 libevent-1.1a.bb has begun failing - looks like the package got reved at src w/o changing name :( Oct 13 22:47:02 checksum mismatch Oct 13 22:49:46 tharvey: I will apply that patch let me test it Oct 13 22:49:56 khem, thx Oct 13 22:52:55 oh man... its my IT department jacking me.... libevent source site is blocked by OpenDNS - thats why it fails checksum when I fetch it Oct 13 22:53:13 freaking conflicker virus... when will people stop using IE and making the rest of us pay? Oct 13 23:03:47 03Tim Harvey  07master * r90cdd0e381 10openembedded.git/recipes/gdb/gdb-cross-sdk.inc: (log message trimmed) Oct 13 23:03:47 gdb-cross-sdk.inc: Do not run autoreconf Oct 13 23:03:47 * GDB autoconfigury mandates uses of a given autconf e.g. 2.64 for gdb Oct 13 23:03:47 7.1, but OE's default autoconf native is 2.65 and it does not go so Oct 13 23:03:47 well with gdb. We do not really need to recreate configure if it its not Oct 13 23:03:48 needed Oct 13 23:03:49 Signed-off-by: Tim Harvey Oct 13 23:06:43 aw Oct 13 23:06:58 almost got 3 in a row Oct 13 23:07:08 * Tartarus git pull --rebase's Oct 13 23:09:21 tharvey, why did you not touch gdb-cross? Oct 13 23:09:35 Er, nm Oct 13 23:09:38 I see it already doesn't Oct 13 23:10:57 03Tom Rini  07org.openembedded.dev * r8b2cac31be 10openembedded.git/recipes/gdb/ (gdb-cross-sdk.inc gdb-cross.inc): (log message trimmed) Oct 13 23:10:57 gdb-cross/cross-sdk: Fixup DEPENDS further Oct 13 23:10:57 Since we are statically linking, as noted before, we now share Oct 13 23:10:57 the same DEPENDS set on cross and cross-sdk. And gdb cannot Oct 13 23:10:57 build without grabbing some stuff from the real compiler. Oct 13 23:10:57 gdb-cross was fine but gdb-cross-sdk was relying previously on Oct 13 23:10:58 an oddity of zlib. To be clear, add in virtual/${TARGET_PREFIX}gcc Oct 13 23:10:59 03Tom Rini  07org.openembedded.dev * r3731d923bb 10openembedded.git/recipes/zlib/zlib.inc: Oct 13 23:10:59 zlib.inc: autotools.bbclass handles libtool depends Oct 13 23:10:59 Signed-off-by: Tom Rini Oct 13 23:11:12 khem, thanks - for the more appropriate comment as well Oct 13 23:18:07 my head just exploded Oct 13 23:18:15 looking at some c++ Oct 13 23:26:42 yeah.. c++ will do that Oct 13 23:51:13 heh C++ bomb Oct 13 23:51:27 I always thought C++ is nice language I still do Oct 13 23:51:50 I wrote 1 assembler from scratch and ELF/DWARF reader library Oct 13 23:51:53 in C++ Oct 13 23:52:08 c++ has too much. A good language is a simple language Oct 13 23:52:09 it was very elegant and fast Oct 13 23:52:55 C++ is simple enough but no simpler Oct 13 23:53:16 Its just that C programmers are using it Oct 13 23:53:16 a good language is easy to implement Oct 13 23:53:37 grg: in compiler ? Oct 13 23:53:43 its not that bad Oct 13 23:54:08 if you look at C++ front end its easier than C front end in gcc IMP Oct 13 23:54:10 IMO Oct 13 23:54:24 forget fortran Oct 13 23:54:29 with nested function Oct 13 23:54:31 crap Oct 13 23:56:36 grg: has bitbake world improved a bit for you Oct 14 00:01:40 khem, haven't done a bitbake world for a week... will try tomorrow Oct 14 00:02:39 grg: ok Oct 14 00:03:02 grg: its something we should keep always on Oct 14 00:03:15 it will take time to get thru Oct 14 00:04:12 yes Oct 14 00:05:45 there was a problem with libx11 i saw, missing building in some of the XIM functions. Subsequently there were lots of undefined reference errors in other apps. but i rebuilt libx11 and it was fine.... grrr... Not sure if i muddled something, or if its a parallel build problem. Oct 14 00:06:36 anyway, i've been working through some other "undefined reference" build failures Oct 14 00:06:57 seems a good way to attack the bitbake world errors are to fix classes of problems Oct 14 00:09:54 grg: right Oct 14 00:24:38 03Chris Larson  07master * r14b7ca062d 10openembedded.git/ (3 files in 2 dirs): Oct 14 00:24:38 oe.process: pull some common bits over Oct 14 00:24:38 Also update gitver to use the subprocess wrappers Oct 14 00:24:38 Signed-off-by: Chris Larson Oct 14 00:24:47 03Chris Larson  07master * r9db9799010 10openembedded.git/lib/oe/unpack.py: Oct 14 00:24:47 oe.unpack: use oe.process Oct 14 00:24:47 Signed-off-by: Chris Larson Oct 14 00:24:48 03Chris Larson  07master * rc04b2d70a1 10openembedded.git/conf/bitbake.conf: (log message trimmed) Oct 14 00:24:48 bitbake.conf: fix pkg-config relocation issue Oct 14 00:24:49 By default, pkg-config falls back to checking the default search path for .pc Oct 14 00:24:49 files, which is the native location. If you relocate it, it will be unable to Oct 14 00:24:50 hit that location, which can cause problems in certain cases. In particular, Oct 14 00:24:51 gnome-bluetooth requires gtk-doc-native to run its tools, and uses pkg-config Oct 14 00:24:52 to determine its availability. Oct 14 00:24:55 03Chris Larson  07master * r2d25a816f0 10openembedded.git/classes/gitver.bbclass: Oct 14 00:24:55 gitver: allow tag adjustment via GIT_TAGADJUST Oct 14 00:24:55 Example usage: Oct 14 00:24:56 GIT_TAGADJUST = "version[1:]" Oct 14 00:24:57 Signed-off-by: Chris Larson Oct 14 00:25:00 03Chris Larson  07master * ra016eb41a3 10openembedded.git/lib/oe/process.py: Oct 14 00:25:00 oe.process: subclass Popen Oct 14 00:25:01 Rather than providing a wrapper function, we can subclass Popen and provide Oct 14 00:25:02 our slightly different defaults that way. Oct 14 00:25:03 Signed-off-by: Chris Larson Oct 14 00:27:48 (re: pkg-config, i gave up on waiting for a second ack, so sue me :P) Oct 14 00:28:22 cbrake: GIT_TAGADJUST should make it much more convenient to adjust it, don't have to use ${@} crap Oct 14 00:33:05 03Chris Larson  07master * r2a0ffe7663 10openembedded.git/classes/gitver.bbclass: Oct 14 00:33:05 gitver: drop 'v' tag prefix where appropriate Oct 14 00:33:05 If the tag starts with 'v' followed by a number, drop the 'v' prefix. This Oct 14 00:33:05 will not be done for you if you customize GIT_TAGADJUST. Oct 14 00:33:05 Signed-off-by: Chris Larson Oct 14 00:34:02 thats better, more sane default Oct 14 00:34:31 tharvey? Oct 14 00:34:59 hell, i forgot about the clean.bbclass stuff Oct 14 00:35:11 need to make it easier to do the pstage clean from a custom clean task Oct 14 00:36:56 Tartarus, yes? Oct 14 00:37:47 03Chris Larson  07master * rbe68ca616a 10openembedded.git/classes/gitver.bbclass: Oct 14 00:37:47 gitver: add missing import Oct 14 00:37:47 Signed-off-by: Chris Larson Oct 14 00:38:15 tharvey, how does 90cdd0e3813a274a19a2625f664542ef7f93e8f7 work? Oct 14 00:38:23 We went from do_configure_append to do_configure Oct 14 00:38:30 And we do oe_runconf at the end Oct 14 00:38:33 after we've tried to run make Oct 14 00:39:02 works pretty well for me heh Oct 14 00:39:16 But how can it? :) Oct 14 00:39:16 prior to that patch do_configure failed complaining about versions of autotools Oct 14 00:40:10 khem suggested the fix, so I tested, and submitted the patch. If I understand correctly were simply telling oe to run configure again to fix up autotools Oct 14 00:40:31 Did you change it from do_configure_append to do_configure after testing? Oct 14 00:40:42 If it was still do_configure_append, yes, I could see what you're saying happening Oct 14 00:40:46 yes... I've already pulled and built with it Oct 14 00:41:11 Can you test it again real quick? Oct 14 00:41:25 I can't see how starting out by saying make something before we've run configure can work Oct 14 00:41:38 esp since we use a separate build dir Oct 14 00:41:43 damnit Oct 14 00:41:55 I ask since i"m seeing build failures now ;) Oct 14 00:42:41 03Chris Larson  07master * rd021e2b933 10openembedded.git/classes/utils.bbclass: Oct 14 00:42:41 utils.bbclass: add missing import of oe.process Oct 14 00:42:41 Signed-off-by: Chris Larson Oct 14 00:42:57 honestly I don't understand why khem had me change do_configure_append to do_configure either - he didn't explain it to me just said 'try it' - he did test it before he committed my patch and he also took a stab at explaining it where I failed to Oct 14 00:43:10 OK, so it's khem's fault Oct 14 00:43:11 Thanks :) Oct 14 00:43:16 * Tartarus fixes Oct 14 00:44:10 I've got a 'clean build' going now to test it as well, but I made that exact patch to my tree that failed prior and it successfully built gdb-cross-sdk afterward Oct 14 00:44:34 Did you do a -c clean in there? Oct 14 00:44:41 Otherwise I could see it working :) Oct 14 00:44:51 given the very funny nature of what you want done Oct 14 00:44:53 I wish I understood autotools better myself Oct 14 00:45:29 no I did not clean the package... but I assume khem tested appropriately? Oct 14 00:46:22 honestly I can't believe I'm the first to run into this issue, from what I can tell its been keeping meta-toolchain from building for weeks... Oct 14 00:46:39 On what host? Oct 14 00:46:44 It's been building for weeks for me Oct 14 00:46:47 x86 as well as overo Oct 14 00:47:02 what host distro? Oct 14 00:47:09 angstrom Oct 14 00:47:19 ... your host distro :) Oct 14 00:47:21 I wish I knew what the magic was... I've been stuck for weeks trying to get a stable snapshot :( Oct 14 00:47:26 ubuntu 10.04 Oct 14 00:47:32 Well there ya go :) Oct 14 00:47:36 * Tartarus does older hosts Oct 14 00:47:55 In fact, hell Oct 14 00:47:59 Something is crazy up in here Oct 14 00:48:04 well if it makes you feel better the first failure was on an Ubuntu 7.10 host last week... I assumed the issue was there, but then found it on my ubuntu 10.04 as well Oct 14 00:48:06 gdb-cross.inc has a comment, we don't want to run autoconf Oct 14 00:48:13 And then what you're saying is no, we really do Oct 14 00:48:27 what khem said :) Oct 14 00:48:53 clean and rebuild gdb-cross-sdk fails as you say :( Oct 14 00:49:19 pull! Oct 14 00:49:21 ;) Oct 14 00:49:26 03Tom Rini  07org.openembedded.dev * rd823e74189 10openembedded.git/recipes/gdb/gdb-cross-sdk.inc: (log message trimmed) Oct 14 00:49:26 gdb-cross-sdk.inc: We must use do_configure_append Oct 14 00:49:26 The goal is to have oe_runconf happen twice. So we want Oct 14 00:49:26 the normal gdb-cross.inc do_configure to happen so we get Oct 14 00:49:26 an initial configure. Then gdb-cross-sdk does its thing and Oct 14 00:49:26 then we run oe_runconf again. Oct 14 00:49:27 All of this shows that we really need to sit down and think and Oct 14 00:49:37 can you honestly tell me I'm the only one on an Ubuntu 10.04 host building angstrom meta-toolchain for x86? heck I figure its one of the most common test cases Oct 14 00:50:20 Yes. Oct 14 00:50:25 meta-toolchain doesn't get much love. Oct 14 00:50:38 is there something more appropriate for an sdk? Oct 14 00:50:42 I'm doing u8.04 since I want it to run on both Oct 14 00:50:45 Nope, it's the right thing Oct 14 00:50:51 It's just that sdk is funny in some ways Oct 14 00:51:25 this is why try to limit syncing with OE upstream to once a year... it takes weeks of utter thrashing to land on something stable Oct 14 00:51:36 Why again do we have a complex build system that tries so hard to make things happen right easily that also makes a "dumb" build system Oct 14 00:51:58 The more often you re-sync the less breakage you have to deal with Oct 14 00:52:33 yes... I thought so too... in fact I argued that same statement. But now I'm weeks into trying to get a stable snapshot Oct 14 00:52:34 (Don't get me wrong, my finger prints are all over the meta toolchain stuff) Oct 14 00:52:43 heh... I noticed, and I do appreciate the work! Oct 14 00:53:15 It's just a little bit of bad luck in there too Oct 14 00:53:39 We haven't done any big builds on u10.04 since doing it on u8.04 gives us that and 10.04 and 9.10 and I'm pretty sure but need to find the time to fire up a VM, 10.10 Oct 14 00:53:54 your commit makes sense to me... about having oe_runconf occur twice Oct 14 00:54:12 And 7.10 is just old ;) Oct 14 00:54:16 why are you sitting on u8.04? Oct 14 00:55:18 I have no desire to test several distros and versions... I just want to make sure I'm supporting an sdk for something 'recent' that desktop users will be using Oct 14 00:55:59 Since that's what gives us something that works on everything ubuntu still supports, except I guess the oldest lts Oct 14 00:56:19 and we expect to run into folks that planned on u804's 5 years of support for servers Oct 14 00:58:46 you mean your worried an sdk built on say 10.04 won't work on 8.04? doesn't that mean the toolchain is borked and not including its dependencies correctly? Oct 14 01:00:53 no, it means it's a normally build binary Oct 14 01:01:09 u10.04 has one glibc, u8.04 a much older one Oct 14 01:01:27 And we don't try and build (and it's really difficult to get) such that it should work on the older one Oct 14 01:02:16 I'm still confused - normally build binary? Oct 14 01:02:30 er, s/build/built/ Oct 14 01:02:44 binary compatibility is a pain :) Oct 14 01:03:07 I see, so with the newer glibc of ubuntu 10.x you could run into a glibc compatibility issue with your toolchain on 8.04 - but likely not the other way around? Oct 14 01:03:27 would think you would have the issues both ways Oct 14 01:05:50 Nope Oct 14 01:05:56 glibc tries hard to do backwards compat Oct 14 01:06:04 So long as the program didn't break the rules and use private symbols Oct 14 01:06:11 which hasn't been a problem in a long while Oct 14 01:06:23 So binary compat really was a pain like 10 years ago :) Oct 14 01:06:28 But life has happily moved on Oct 14 01:06:43 That's not to say there can't be problems Oct 14 01:06:53 hence the static linking we do in gdb of ncurses/expat/zlib Oct 14 01:07:06 sometimes we get libexpat.so.1 sometimes .so.0 Oct 14 01:07:24 And w/o doing further games, you won't be using ours, if we provide it, out of the box Oct 14 01:07:28 afk a while Oct 14 01:10:52 Tartarus, gotta head home to the kids, I'll chat some more tomorrow on this as I'm still not completely clear - I thought the whole point was to static link libs in the toolchain as well as provide binary libs in the SDK so there wouldn't be any compat issues - all self contained (unremittingly I'm no compiler expert) Oct 14 02:00:05 I move my open embedded environment to a x64 host .... everything still works .. but all the new stuff it is trying to build under tmp/work/x86_64-linux rather than i686-linux .... how can I force the host build env to 32-bit Oct 14 02:00:38 You probably don't want to :) Oct 14 02:01:04 If you have a 32bit chroot available Oct 14 02:01:07 i am in a 32-bit chroot env Oct 14 02:01:09 you can probably linux32 + chroot into it Oct 14 02:01:18 But only probably Oct 14 02:01:54 yep, thats likely it Oct 14 02:03:16 so it there like a native chost variable i can override Oct 14 02:04:03 no Oct 14 02:04:17 If you've linux32 chroot'd into it and it's still saying no you're on 64bit Oct 14 02:04:26 You're gonna need to get more drastic (say, kvm) Oct 14 02:04:40 Since that means that no, at some level the world still sees your box as 64bit Oct 14 02:04:55 the problem is prob uname Oct 14 02:05:00 it could be cargoudel doesn't realize that linux32 is a command, not a generic statement :) Oct 14 02:05:14 Well, i have this vauge recolltion of trying to do that Oct 14 02:05:21 and giving up since it still saw stuff as 64bit Oct 14 02:05:26 and I do know how to use linux32 ;) Oct 14 02:05:38 just override BUILD_ARCH. Oct 14 02:05:51 very few things will use uname directly, BUILD_ARCH extracts it from a uname call, overriding it will do Oct 14 02:06:04 kergoth: thanks i didn't release linux32 was a command Oct 14 02:06:07 let me try it Oct 14 02:06:20 if that doesn't work, try the BUILD_ARCH thing (e.g. setting to i686) Oct 14 02:06:32 * kergoth_ hasn't tried that in a while either, its ugly Oct 14 02:06:38 (the whole thing, i mean) Oct 14 02:07:07 hmm Oct 14 02:07:07 | make: *** No rule to make target `libltdl/config/ltmain.sh'. Stop. Oct 14 02:07:08 | ERROR: Function do_compile failed Oct 14 02:07:08 NOTE: package libtool-native-1.5.10-r26.0: task do_compile: Failed Oct 14 02:07:11 heh Oct 14 02:08:30 {master openembedded} % linux32 uname -a Oct 14 02:08:30 Linux auron 2.6.32-25-server #44-Ubuntu SMP Fri Sep 17 21:13:39 UTC 2010 i686 GNU/Linux Oct 14 02:08:30 {master openembedded} % uname -a Oct 14 02:08:30 Linux auron 2.6.32-25-server #44-Ubuntu SMP Fri Sep 17 21:13:39 UTC 2010 x86_64 GNU/Linux Oct 14 02:08:39 (for cargoudel's reference) Oct 14 02:09:10 {~oe} % linux32 bitbake -e |grep \^BUILD_ARCH Oct 14 02:09:10 337:BUILD_ARCH="i686" Oct 14 02:09:13 good sign Oct 14 02:10:10 looks like it is working... thanks Oct 14 02:10:44 the fucking set up a debian vm for me to do work on .... and want to be able to move this build env around Oct 14 02:10:57 admin set up a * Oct 14 02:11:18 and its a vm with 1.5 gig or RAM ... that is 64bit debian Oct 14 02:12:07 i know there is more registers in 64-bit mode ... but really for a system with less the 4 gigs of ram ... i would rather avoid rebuilding everything Oct 14 02:12:41 thanks for the help Oct 14 02:13:39 np Oct 14 02:29:53 cargoudel: fyi, the schroot tool in debian is quite handy for managing chroots. automatically bind mounts /proc, etc when entering and unmounts when leaving, can just mark a chroot as linux32 personality and using it will use linux32 always, etc Oct 14 02:30:23 * kergoth_ just created a quick lucid 32 bit debootstrap rootfs and added it to schroot that way and dropped in to run bitbake Oct 14 02:31:00 man schroot Oct 14 02:32:38 libboost as a dep... Oct 14 02:33:51 wonder how well fakechroot works Oct 14 02:33:56 haven't messed with that yet Oct 14 02:58:15 dangit, cargoudel got me screwing around with chroots instead of doing something useful **** ENDING LOGGING AT Thu Oct 14 02:59:57 2010