**** BEGIN LOGGING AT Wed Jul 28 02:59:56 2010 Jul 28 03:39:40 03Tom Rini 07org.openembedded.dev * r400e9a3334 10openembedded.git/classes/packaged-staging.bbclass: Jul 28 03:39:40 Revert "packaged-staging: Make setting PSTAGING_ACTIVE be a named python func" Jul 28 03:39:40 This has some unintended consequences, revert for now. Jul 28 03:39:40 This reverts commit 9a0e95f37639d9856ad41b8fc301f9b00369a797. Jul 28 04:30:49 03Khem Raj 07org.openembedded.dev * r2c35d6ebd9 10openembedded.git/recipes/proxy-libintl/proxy-libintl_20080418.bb: Jul 28 04:30:50 proxy-libintl_20080418.bb: pass -fPIC in CFLAGS always. Jul 28 04:30:50 Signed-off-by: Khem Raj Jul 28 04:41:19 hi all Jul 28 04:41:35 I got an error in nitnake fso-illume-umage Jul 28 04:41:45 check_data_file_clashes: Package openmoko-alsa-scenarios wants to install file /home/ranjith/test/build/tmp/rootfs/fso-illume-image/etc/asound.state Jul 28 04:41:45 But that file is already provided by package * alsa-states Jul 28 04:41:49 opkg_install_cmd: Cannot install package gst-plugin-modplug. Jul 28 04:41:58 check_data_file_clashes: Package openmoko-alsa-scenarios wants to install file /home/ranjith/test/build/tmp/rootfs/fso-illume-image/etc/asound.state Jul 28 04:41:58 But that file is already provided by package * alsa-states Jul 28 04:42:39 can any one tell me what to do to get the error cleared.? Jul 28 04:42:49 hello anyone here..?? Jul 28 04:43:04 khem: hi Jul 28 06:16:25 khem: build was ok Jul 28 06:17:08 I have in sysroot: arm-v5te_angstrom-linux-gnuabi Jul 28 06:17:35 and c7x0-v5te_angstrom-linux-gnueabi Jul 28 06:17:38 bbl Jul 28 06:55:33 we have an OE git server emergency, and need to contact the core team ASAP Jul 28 06:56:06 omg.. again? Jul 28 06:56:14 :-( Jul 28 06:57:12 *one* person sync whatever needs syncing right now, it could go away at any time. make sure it is *one* person - a high load will kill it. Jul 28 06:57:18 who will it be? Jul 28 06:57:46 I'm deadly serious about not putting a load on it. Jul 28 06:58:57 cbrake: zecke: RP: pb_: mickeyl: Crofton|work: hrw|gone: kergoth: ping Jul 28 07:02:42 :( Jul 28 07:05:13 mickeyl will be it Jul 28 07:05:56 I'm rsyning it now. Jul 28 07:06:05 I'll have it all Jul 28 07:07:06 the changesets are coming in and I'm limiting the transfer rate. Jul 28 07:13:26 * Jay7 afk for some hours Jul 28 07:16:53 rwhitby: pong Jul 28 07:16:59 morgen Jul 28 07:17:31 hrw: please liase with mickeyl and ka6sox and make sure you have everything you need in case your servers at OSUOSL was to be offline for some time Jul 28 07:18:00 rwhitby: I never was a part of OE servers team Jul 28 07:19:41 hrw: I'll worke with mickeyl and others as I have the data and will put it on antother server. Jul 28 07:19:52 ok Jul 28 07:19:56 thx ka6sox Jul 28 07:41:00 good morning Jul 28 07:49:07 hm.. woglinde is not yet here Jul 28 07:51:57 cbrake, Are you subscribed to the gzip bug on Launchpad, or is it a different C. Brake? Jul 28 07:53:09 in which recipe can I find the jffs2 image creation command (I suppose should be mkfs.jffs2)? Jul 28 07:54:34 is it in conf/bitbake.conf, then inherited by others? Jul 28 07:55:30 mckoan: if you mean recipe it is mtd-utils Jul 28 07:55:46 if you mean how images are created, it is one of the image.bbclass files Jul 28 07:56:05 and in conf files you can influence some env vars that control the process Jul 28 07:57:32 eFfeM_work: thx, I mean I'm looking for the place where are defined the mkfs.jffs2 command options Jul 28 07:58:37 mckoan: i have my own image recipe and in it I say: Jul 28 07:58:38 EXTRA_IMAGECMD_jffs2 = "--pad --big-endian --eraseblock=0x20000 --faketime -n" Jul 28 07:58:38 mkfs.jffs2 command options for each specific machine Jul 28 07:58:54 eFfeM_work: great hint, thx Jul 28 07:59:02 yw :-) Jul 28 07:59:38 mickeyl when you wake up could you ping either rwhitby or me? Jul 28 07:59:51 mckoan: guess you can also set these in local.conf Jul 28 08:00:49 ka6sox did something happen again? Jul 28 08:00:54 moin mickeyl Jul 28 08:01:02 < ka6sox> mickeyl when you wake up could you ping either rwhitby or me? Jul 28 08:01:20 woglinde, fascinating thing.... Jul 28 08:01:53 but I haven't the time now...bbiab Jul 28 08:02:02 okay Jul 28 08:03:24 morgen woglinde Jul 28 08:03:29 hi ant Jul 28 08:06:47 woglinde: I had NOTE: package eggdbus-native-0.6-r0: task do_compile: Failed - | /usr/bin/ld: cannot find -ldbus-glib-1 Jul 28 08:07:24 I've seen Pokyi's dbus-glib is a bit different Jul 28 08:07:39 ant hm? Jul 28 08:07:43 here it worked Jul 28 08:07:47 with uclibc setup Jul 28 08:07:49 I had to revert your commit :/ Jul 28 08:07:59 with glibc Jul 28 08:08:01 which version of dbus-glib is choosen? Jul 28 08:08:27 sorry can't check from here Jul 28 08:08:50 plain angstrom/glibc Jul 28 08:09:08 did you build from scratch? Jul 28 08:09:11 yes Jul 28 08:09:18 hm Jul 28 08:09:22 build failed on that Jul 28 08:09:32 after revert build finished Jul 28 08:09:55 *sigh* Jul 28 08:10:14 see http://git.pokylinux.org/cgit.cgi/poky/tree/meta/packages/dbus/dbus-glib.inc Jul 28 08:10:15 oh its eggdbus-native Jul 28 08:10:33 yes Jul 28 08:19:55 hm, anyone any idea where attr/xattr.h must come from? Jul 28 08:20:05 udev Jul 28 08:20:10 when building squashfs-tools on mksquashfs I get: xattr.c:37:24: error: attr/xattr.h: No such file or directory Jul 28 08:20:33 woglinde: thanks Jul 28 08:20:37 udev/attr_2.4.44.bb Jul 28 08:22:31 yeah, already build that one, but that did not help, guess I need a native variant as mksquashfs is also build to make a squashfs on my build system Jul 28 08:22:56 but there is no attr-native and no BBCLASSEXTEND in the attr recipe Jul 28 08:23:03 * eFfeM_work scratches head Jul 28 08:23:25 hm Jul 28 08:23:29 fix it Jul 28 08:23:57 there 2 recipes in the past Jul 28 08:24:06 one in udev one in xfs Jul 28 08:24:13 I killed the on in xfs Jul 28 08:24:24 maybee there was some native stuff in Jul 28 08:24:26 well I have the file ./sysroots/ppce500v2-angstrom-linux-gnuspe/usr/include/attr/xattr.h so I should be ok Jul 28 08:24:33 yes Jul 28 08:24:54 or shoud that be in an i386 or x86-64 dir or so for a host recipe ? Jul 28 08:25:19 aeh Jul 28 08:25:24 yes Jul 28 08:25:27 sorry Jul 28 08:25:33 ok, clear, np Jul 28 08:25:50 if you build squashfs tools to generate to squafs image Jul 28 08:25:54 its need to be native Jul 28 08:26:43 yup Jul 28 08:29:28 strange, the xfsprogs attr recipe does not seem to have a native coutnerpart either and also does not contain host specifics: Jul 28 08:29:29 http://cgit.openembedded.org/cgit.cgi/openembedded/commit/?id=fad5af9a1c119e34b718c40f7a4c6452341d5beb Jul 28 08:29:48 let's see if a quick BBCLASSEXTEND will fix things Jul 28 08:30:22 hi zecke Jul 28 08:35:38 woglinde: BBCLASSEXTEND seems to fix things Jul 28 08:38:11 cool Jul 28 08:40:05 will prepare patch Jul 28 08:40:30 good morning Jul 28 08:43:05 good morning either ;] Jul 28 08:57:03 looks like we have another broken recipe recipes/mpfr/mpfr_3.0.0.bb Jul 28 08:57:14 NOTE: fetch http://www.mpfr.org/mpfr-3.0.0/mpfr-3.0.0.tar.xz Jul 28 08:57:15 --2010-07-28 09:27:53-- http://www.mpfr.org/mpfr-3.0.0/mpfr-3.0.0.tar.xz Jul 28 08:57:23 tar.xz ??? Jul 28 08:57:39 /bin/sh: xz: command not found Jul 28 08:57:39 tar: This does not look like a tar archive Jul 28 08:57:40 tar: Error exit delayed from previous errors Jul 28 08:58:20 what file mpfr-3.0.0.tar.xz says ? Jul 28 08:58:43 yes xz is the new compression Jul 28 08:59:06 :) Jul 28 08:59:18 mckoan: I have the same and it works for me.. Jul 28 08:59:36 soltys you have host xz installed Jul 28 08:59:42 mckoan not Jul 28 08:59:48 what is xz ? Jul 28 09:00:02 rwhitby: hi Jul 28 09:00:49 hi pb_ Jul 28 09:00:55 as I said a new compression algo Jul 28 09:01:00 or better combined Jul 28 09:01:02 hm it fails to build.. Jul 28 09:01:24 dome assembler crap.. Jul 28 09:02:14 where is ${D} assuming to point to? I have (for a native recipe): install -m 0755 mksquashfs ${D}${sbindir}/ and the log says cp mksquashfs /usr/local/bin Jul 28 09:02:29 here is error log http://wklej.org/id/369625 Jul 28 09:02:30 that gives an error (and is not where I wnat it to to) Jul 28 09:02:33 to go Jul 28 09:09:36 anybody has an idea wich package provides xz? Jul 28 09:09:55 xz Jul 28 09:09:58 :-) Jul 28 09:10:50 hm ffmpeg also fails.. http://wklej.org/id/369629/ Jul 28 09:21:00 if a makefile contains a line like INSTALL_DIR = /a/b can I override that in the make invocation (and if so how), or does this need a patch ? Jul 28 09:21:34 if you use "make -e", environment variables will override the vars in the makefile. Jul 28 09:22:05 pb_: and with oerunmake install ? can I also add -e ? Jul 28 09:22:56 you can put -e in EXTRA_OEMAKE, or I think "oe_runmake -e install" will also work Jul 28 09:24:00 pb_ yeah just found another example, my do_install now looks like: oe_runmake -e INSTALL_DIR="${D}" install Jul 28 09:24:09 if there is a better way to do so, please let me know Jul 28 09:26:08 eFfeM_work: maybe lzma Jul 28 09:27:13 ant dbus-glib is fixed now Jul 28 09:27:15 mckoan: no, xz Jul 28 09:27:16 $ ls recipes/xz Jul 28 09:27:16 xz_4.999.9beta.bb xz_git.bb xz.inc Jul 28 09:27:20 03Henning Heinold 07org.openembedded.dev * r3add3f57be 10openembedded.git/recipes/dbus/dbus-glib.inc: dbus-glib: fix do_install and bump INC_PR Jul 28 09:28:21 eFfeM_work: I expected it from the distro on my host side (debian) Jul 28 09:28:41 ah ok Jul 28 09:30:51 woglinde: thx, will try this evening Jul 28 09:30:53 mckoan, either bake xz-native or apt-get install xz-utils. Jul 28 09:33:17 blindvt`: apt-cache search xz-utils not exist Jul 28 09:33:56 mckoan: itseems bitbake.conf is not yet xz aware Jul 28 09:34:32 we should perhaps automagically depend on all required native unpackers and remove assume_provided entry for bzip2-native too. The current logic of ASSUME_PROVIDED vs. required_utilities handling is a bit of a split-brain situation Jul 28 09:35:02 mckoan: while base.bbclass seems lzma-unaware Jul 28 09:35:17 I think the two need some sync Jul 28 09:35:21 ant_work: since when has been introduced this recipe using xz? Jul 28 09:35:56 I found Jul 28 09:36:00 Bernhard Reutner-Fischer Jul 28 09:36:02 2010-02-01 base.bbclass: in base_contains, check for var existance before using it Jul 28 09:36:21 uups wrong paste.. Jul 28 09:36:31 2010-02-11 base.bbclass: handle xz compressed files and tarballs Jul 28 09:36:54 very strange behaviour Jul 28 09:37:21 as usual I have to delete tmp and retry to check Jul 28 09:37:36 one is for unpack the other is for image generation Jul 28 09:42:47 yesterday i have mentioned problems on failing gettext (compilation error), when building angstrom (x11-image) for igep0020 (beagleboard clone) Jul 28 09:42:54 i was asked to bisect through git revisions, and check wehre the error comes from, but it seems that on the other machines problem is in ncurses Jul 28 09:43:04 see the error log here http://wklej.org/id/369641/ Jul 28 09:44:55 nazgee: I saw the same, looks like git pull, del tmp, rebuild is working Jul 28 09:45:23 btw - the only difference that matters between beagle and igep0020 machines is in PREFERRED_PROVIDER_virtual/kernel. given that- how is it possible, that some recipes fail on igep, and do not on beagle (or at least that is what somebody told me) Jul 28 09:46:46 nazgee: is possible, consider that beagle and all TI stuff have the best support in OE Jul 28 09:46:58 mckoan: i did git pull before complaining ;] havent tried deleteing, though. do i have to delete whole tmp? or ncurses-related would be enough? and what is the reason for this time-consuming behavior? Jul 28 09:47:35 nazgee: when I have weird behaviour in OE I delete the whole tmp Jul 28 09:47:35 mckoan: but the only difference is in kernel (or at least that is what i can see), and oe fails on e.g. gettext, or ncurses Jul 28 09:49:03 what i do not understrand is other, not kernel-related recipes fail (e.g. gettext) when the only difference is in PREFERRED_PROVIDER_virtual/kernel Jul 28 09:50:25 ant_work, mckoan, http://paste.debian.net/81607/ you get the idea.. Jul 28 09:52:09 ant_work: woglinde : this is the xz problem http://pastebin.com/wM1RGXay Jul 28 09:52:18 this is obviously untested and would need further cleanup and auditing to avoid potential loops Jul 28 09:52:30 see stanislav's notes on the ML :/ Jul 28 09:52:44 [oe] bitbake: staging of binary over symlink breaks sysroot (lzma x xz) Jul 28 09:54:06 ant_work: yep Jul 28 09:54:51 are you using bitbake 1.18 too? Jul 28 09:55:11 s/1.18/1.8.18/ Jul 28 10:07:36 bitbake 1.8.18 Jul 28 10:28:08 blindvt`: actually there is already something for zx Jul 28 10:28:19 def oe_unpack_file(file, data, url = None): Jul 28 10:28:24 anyone interestes in this? nothing bas happened, but looks strange to me: NOTE: Running task 20 of 6888 (ID: 155, .../recipes/coreutils/coreutils-native_8.5.bb, do_configure) *** %n in writable segment detected *** Jul 28 10:28:36 bas = bad Jul 28 10:31:18 that's relatively harmless, it just indicates a potential vulnerability in coreutils. Jul 28 10:31:26 I guess your distro must be building with FORTIFY_SOURCE or some such. Jul 28 10:31:46 is this gentoo or something? Jul 28 10:33:34 pb_, I think I've the same warning on an ubuntu derived distro Jul 28 10:33:44 mckoan, oe_unpack_file *unpacks* a given file with the corresponding unpacker. Now you don't have an appropriate unpacker (xz in your case) so we have 2 options: 1) put xz into required_utilities 2) build xz-native behind your back Jul 28 10:33:54 I vaguely remember tough Jul 28 10:34:09 I think it was %s something tough Jul 28 10:34:11 and I don't remember the package at all Jul 28 10:35:46 pb_: angstrom (x11-image) on beagleboard clone (igep0020) Jul 28 10:36:01 blindvt`: I wonder why this problem raised only today, who introduced the recipes/mpfr/mpfr_3.0.0.bb should be responsible for that Jul 28 10:36:06 nazgee: build host distro, not DISTRO Jul 28 10:36:17 ups, ubuntu ;] Jul 28 10:36:45 ah right, I guess they have switched fortify on as well now Jul 28 10:36:52 anyway, you can ignore it, it won't do you any real harm Jul 28 10:37:08 mckoan, 2) is a little bit tricky for you're likely to end up with dependency loops (i'm currently looking into those) Jul 28 10:37:16 that is what i've noticed. just included it fo reference to you guys Jul 28 10:37:57 mckoan, yea, well that was /me who caused that, apparently (i have xz installed, so didn't see this, unfortunately) :-/ Jul 28 10:40:52 mckoan, as said, a quick workaround is to either install xz on your buildhost or bake xz-native manually, before baking anything else Jul 28 10:43:21 blindvt`: ok thx, install xz on debian lenny is impossible Jul 28 10:43:40 isn't ready yet Jul 28 10:43:54 I'm trying bitbake xz-native Jul 28 10:45:16 khem, please revert the gmp,mpfr,mpc bumps until we can fix unpackers for good and please accept my apologies for the breakage :( Jul 28 10:53:28 blindvt`: NOTE: Unpacking ../../sources/mpfr-3.0.0.tar.xz to tmp/work/x86_64-linux/mpfr-native-3.0.0-r0/ successful Jul 28 10:53:40 blindvt`: thx Jul 28 10:54:06 * mckoan -> bbl Jul 28 11:08:37 pb_, good idea to define distro versus DISTRO :) Jul 28 12:01:38 MWelchUK_work: yes, I'm the one subscribed to the gzip bug in Launchpad Jul 28 12:01:49 MWelchUK_work: just ran into it again yesterday :-\ Jul 28 12:02:57 cbrake, It's a bit of a bugger - I was hopping to move to 10.04 this week, but it seems I can't until this is resolved. Jul 28 12:03:18 hmz. how would i handle INHIBITS in BBCLASSEXTEND="native" packages? looking.. Jul 28 12:03:59 hello Jul 28 12:04:16 * mckoan re Jul 28 12:06:08 cbrake, annoyingly this bug was only added to Fedora's bugzilla in May and was fixed by the end of June. It was added as a bug in Launchpad in February by the looks of it - and it's still not fixed. Jul 28 12:06:50 MWelchUK_work: do you have a link to the fedora bugzilla? Jul 28 12:07:16 MWelchUK_work: do the Ubuntu folks know how fedora fixed it? Maybe that would be some incentive Jul 28 12:07:22 It's in Lanchpad, https://bugzilla.redhat.com/show_bug.cgi?id=588644 Jul 28 12:09:12 cbrake, There's even a patch in the Launchpad and a review was requested over a month ago! Jul 28 12:09:50 It's a one line fix, backported from a newer version of gzip AFAICT Jul 28 12:12:05 cbrake, According to their own wiki [1] there should have been some one in #ubuntu-reviews to discuss issues with this morning at 8 UTC - I got no answer. [1] https://wiki.ubuntu.com/UbuntuDevelopment/CodeReviews#Sponsoring Jul 28 12:25:27 can i drop 3 lines here, or should i use pastebin? Jul 28 12:27:28 i just got "Missing inherit gettext?" few lines more here: http://pastebin.ca/1910071 Jul 28 12:30:52 i do not give a ... about this message, but confronted with my gettext compilation problems, it gained some of my attention. I am building in parallel on two different machines (one is about 8 times fastern than the other) Jul 28 12:31:14 and i'll see if after removing tmp/ i will get past gettext error Jul 28 12:31:38 nazgee: which host distro are you using? Jul 28 12:31:50 if no - i will try bisecting (if there won't be any fire outburst in the company) Jul 28 12:31:55 ubuntu Jul 28 12:32:00 on both machines Jul 28 12:34:50 nazgee: sorry for the silly question, did you do git pull? Jul 28 12:35:15 nazgee: you should'nt face to such problem today Jul 28 12:42:20 git pull is the first thing i do in the morning ;] Jul 28 12:43:06 mckoan: well..l to be honest, coffe is first, but after that i always pull your changes ;] Jul 28 12:44:48 nazgee: I changed nothing, I'm simply saying that I don't come across this error Jul 28 12:45:09 for which machine are you bitbaking? Jul 28 12:45:42 mckoan: maybe these issues are machine-dependent? Jul 28 12:47:55 nazgee: may be, I'm using AT91SAM9263 derived Jul 28 12:52:37 antoher question: can i run two bitbakes in parallel? e.g. launch x11-image, and in the meanwhile start baking meta-toolchain? Jul 28 12:56:59 03Prabindh Sundareson 07org.openembedded.dev * r05208f6751 10openembedded.git/recipes/ti/ (3 files): Xgxperf: add svn version Jul 28 13:12:42 i think that INHIBIT_DEFAULT_DEPS_virtclass-native should automatically prevent DEPENDS_virtclass-native from being set. What do you think? Jul 28 13:23:31 nazgee: two bitbakes in parallel: this is tricky, I wouldn't run two bitbakes for the same architecture, but I sometimes run two in parallel for different architectures Jul 28 13:24:11 make sure that your native recipes (and toolchain etc) are ok, otherwise you'll end up in both bitbakes trying to bake the same recipe Jul 28 13:32:28 eFfeM_work: than i'll have to wait, that is not a problem Jul 28 13:32:51 nazgee if it is for the same arch you can just say Jul 28 13:32:55 bitbake a b c Jul 28 13:33:24 yup Jul 28 13:33:24 i know it Jul 28 13:33:28 and you can increase parallellism, but default is probably -j4 which already runs things in parallel Jul 28 13:33:44 the machine i am baking on has some power left Jul 28 13:33:50 ah ok Jul 28 13:33:57 so i was wondering if i can use it Jul 28 13:34:01 increase the parallellisation flags Jul 28 13:34:07 i am already using -j4 Jul 28 13:34:11 you can, but with care. Jul 28 13:34:17 you can go to j6 if needed Jul 28 13:34:20 for compiling and bitbaking Jul 28 13:34:44 and you can bake two things in parallel if you are sure they do not interfere (e.g.try to build teh same recipe) Jul 28 13:34:52 (i mean make, and bitbake, as there are two different flags for these) Jul 28 13:35:00 i know Jul 28 13:35:17 and about bot interfering bibtakes - these is something i am not sure of Jul 28 13:35:24 so i will stay with jus tone ;] Jul 28 13:35:32 tone = one Jul 28 13:35:53 that is best Jul 28 13:36:16 ok, i was baking on two different machines, and the slower one, using only one thread just failed on ncurses Jul 28 13:36:19 configure: error: C compiler cannot create executables Jul 28 13:36:41 that is what happened for few times to me, as i recall Jul 28 13:38:29 nazgee: there used to be an issue with ncurses but it should be fixed, i suggest to do a new pull Jul 28 13:38:35 see mailing list for more info Jul 28 13:41:45 did a pull, but it seems to be not enough Jul 28 13:42:00 now i delete tmp - maybe this is the way to go Jul 28 13:42:42 (the faster machine started with fres git pull, and with empty tmp, we will see where will it manage to go) Jul 28 13:42:47 nazgee, you probably could have got away with just cleaning the affect package. Jul 28 13:43:20 crap. that i what i thought, but somebody adviced me to go with cleaning whole tmp... Jul 28 13:43:51 (i will have to invest in typing lessons, as i keep missing and loosing letters) Jul 28 13:44:12 nazgee, probably safer, but will take considerably longer. Jul 28 13:44:59 and the "slower" machine is not only slower... it is run under virtualbox, so it is gonna take ages ;] Jul 28 13:45:15 hope that faster one is going to finish it with np Jul 28 13:50:55 MWelchUK_work: haven't seen the fix, but would expect it to bump PR so it should rebuild even without cleaning Jul 28 13:51:55 eFfeM_work, good point. Jul 28 13:52:46 btw is there an easy way to find out which partition is mounted as rootfs ? Jul 28 13:54:23 eFfeM_work, "mount"? Jul 28 13:55:15 MWelchUK_work: system runs busybox, mount says: Jul 28 13:55:15 rootfs on / type rootfs (rw) Jul 28 13:55:39 although mount on my ubuntu yss indeed gives the info I need Jul 28 13:55:40 /dev/sdd1 on / type ext4 (rw,errors=remount-ro) Jul 28 13:56:32 guess I have to go for a real mount Jul 28 14:04:02 MWelchUK_work: got an answer at #uclibc; wanted to share that here too, just in case others are interested. it is "rdev" Jul 28 14:04:12 eFfeM_work, dmesg, grep for boot params Jul 28 14:05:28 eFfeM_work, huh - that's good to know Jul 28 14:05:38 MWelchUK_work: actually it might be possible to get it from /proc/cmdline, but I doubt if that works if you have a system with initramfs or so Jul 28 14:05:49 got this link as a bonus: http://free-electrons.com/blog/find-root-device/ Jul 28 14:07:55 Think that rates up there with "lsb_release -a" (thoug not sure that works on OE) Jul 28 14:12:04 does anyone know an easy way to modify /etc/inittab in the rootfs image, without overriding or modifying the sysvinit recipe? Jul 28 14:21:43 03Koen Kooi 07org.openembedded.dev * r09a3ed0a85 10openembedded.git/recipes/qt4/ (15 files in 4 dirs): qt4: add WIP 4.6.3 recipes (only tested upto do_patch) Jul 28 14:30:46 03Chase Maupin 07org.openembedded.dev * r07c1f7bb11 10openembedded.git/classes/sourceipk.bbclass: Jul 28 14:30:46 sourceipk: use ar to package ipk instead of tar Jul 28 14:30:46 * Changed the command that packages the contents of the Jul 28 14:30:46 source ipk to ar instead of tar to match how other ipks Jul 28 14:30:46 are built. Jul 28 14:30:47 Signed-off-by: Chase Maupin Jul 28 14:30:47 Signed-off-by: Koen Kooi Jul 28 14:30:56 03Chase Maupin 07org.openembedded.dev * r1150363c16 10openembedded.git/classes/sourceipk.bbclass: Jul 28 14:30:56 sourceipk: add license to control file Jul 28 14:30:56 * Added License field to the control file. Jul 28 14:30:56 Signed-off-by: Chase Maupin Jul 28 14:30:57 Signed-off-by: Koen Kooi Jul 28 14:34:27 mckoan, you could give this one a try if you wipe your workdir next time, fyi: http://uclibc.org/~aldot/oe/fwd-xz-native2 Jul 28 14:40:33 just a quick thanks for all you guys here - current dev version works perfectly smooth for me. thank you for maintaining this build system Jul 28 14:58:03 03Koen Kooi 07org.openembedded.dev * rb4c5ef7e0e 10openembedded.git/recipes/x-load/ (x-load-git/beagleboard/xm-mem.patch x-load_git.bb): x-load git: update xm memory patch Jul 28 14:58:14 03Roger Monk 07org.openembedded.dev * rb738634ead 10openembedded.git/ (2 files in 2 dirs): Jul 28 14:58:14 linux-omap-psp: Update omap3evm defconfig Jul 28 14:58:14 * Re-base against latest psp defconfig Jul 28 14:58:14 * Sync-up config with beagleboard Jul 28 14:58:15 Signed-off-by: Roger Monk Jul 28 14:59:20 anyone else having trouble building gettext? Jul 28 15:02:50 03Koen Kooi 07org.openembedded.dev * re2b9225af3 10openembedded.git/conf/machine/include/omap3.inc: omap3 machines: build matching x-loader as well on each image build Jul 28 15:25:37 I'm having trouble building the recode recipie, but I'm not sure what has happened. It looks like configure has a bad gcc line but the recode recipie doesn't do anything special that I can see Jul 28 15:30:12 hi khem Jul 28 15:30:17 what patches should I test Jul 28 15:30:20 the glibc ones? Jul 28 15:30:28 I bet that requires rebuilding from scratch again Jul 28 15:38:59 GNUtoo|laptop: hello Jul 28 15:39:15 hi Jul 28 15:42:48 whats problem with .xz Jul 28 15:43:25 .xz? Jul 28 15:43:27 we don't auto-depend .tar.xz SRC_URIs on xz-native nor have xz in required_utilities Jul 28 15:44:14 Didn't we at one point? Jul 28 15:44:15 khem, i'm currently thinking in this direction, fwiw: http://uclibc.org/~aldot/oe/fwd-xz-native2 Jul 28 15:44:17 I'd have sworn we did Jul 28 15:44:41 bzips can handle xz Jul 28 15:44:57 and its in default ASSUME_PROVIDED list in bitbake.conf Jul 28 15:45:23 Tartarus, i think we never did, no. But i could be wrong, of course Jul 28 15:46:27 khem: since when? Jul 28 15:47:03 khem, that fwd-xz-native2 fails on zlib-native though (probably because i was turning off to much of autoreconf) Jul 28 15:47:15 Tartarus: hmm no confused Jul 28 15:47:52 so probably we should require xz-native on build host moving forward Jul 28 15:48:27 khem, yesterday you told me that you had v3 patches, I want to try them Jul 28 15:49:08 khem, exactly. See the hunks against base.bbclass in abovementioned non-patch Jul 28 15:49:50 blindvt: your stuff worked here because I have xz installed Jul 28 15:49:52 hmm Jul 28 15:50:06 khem, me too, yea. My bad :( Jul 28 15:50:11 is there a function such as: do_firstboot Jul 28 15:50:53 khem, ping me when you'ready for talking to me,I'm not in a hurry so I can wait Jul 28 15:50:59 warflyr: update_alternatives I guess Jul 28 15:51:19 khem thanks, ill look into that Jul 28 15:51:19 GNUtoo|laptop: go ahead Jul 28 15:51:49 khem, do you remember yesterdays's conversation? Jul 28 15:51:51 blindvt`: do we have bzip alternative for the SRC_URI Jul 28 15:51:56 basically I told: Jul 28 15:52:09 khem, if we're careful we can just build all required unpackers (except gzip-native which is needed to unpack bzip2-native which, in turn, is needed to unpack xz-native) Jul 28 15:52:18 armv6-novfp feed dir got transformed in armv6 which got no Packages.gz Jul 28 15:52:20 GNUtoo|laptop: I also ran into that eggdbus-native issue Jul 28 15:52:29 so 2 issues: Jul 28 15:52:29 *no Packages.gz Jul 28 15:52:37 *armv6 and armv6-novfp shouldn't mix Jul 28 15:52:45 ah Jul 28 15:52:46 khem, i don't understand your question? Jul 28 15:52:56 so you told me to try your version 3 toolchain patches Jul 28 15:52:57 GNUtoo|laptop: yeah I remember it is not fixed now ? Jul 28 15:53:10 ouch I'm nearly out of battery Jul 28 15:53:28 blindvt`: for now we could use .bz2 alternative if available Jul 28 15:53:30 khem, to unpack bzip2 compressed stuff you need bzip2-native or bzip2 on your buildhost. No way around that Jul 28 15:53:57 I'll find a power source Jul 28 15:54:41 khem, we could, as a quick hack, theoretically. But that's ugly and a pretty poor thing to do overall Jul 28 15:55:06 done Jul 28 15:55:43 blindvt`: currently why cant be depend on xz-native because it ends up in catch 22 Jul 28 15:55:43 khem, I didn't try the patches yet Jul 28 15:55:43 khem, where are the patches? are they in that thread: Jul 28 15:55:48 Re: [oe] [PATCH 1/3] glibc 2.9: cleaned up; patches only in local dir Jul 28 15:55:58 GNUtoo|laptop: they are on patchwork Jul 28 15:56:18 * GNUtoo|laptop would love to have patchwork magic numbers Jul 28 15:56:50 hmm, the update-alt class doesnt seem like itll do what im looking for basically i want to add a user and change permissions/owners of some files; if a user with the same ID is on both the host and target machine; if i chown in the post install; ill these ownerships be preserved in the rootfs? Jul 28 15:56:58 ok Jul 28 15:57:38