**** BEGIN LOGGING AT Sun Oct 10 02:59:57 2010 Oct 10 04:17:25 03Chris Larson  07master * r7791fdfc5e 10openembedded.git/ (classes/package_dbg.bbclass lib/oe/package.py): Oct 10 04:17:26 oe.package: add 'files' function Oct 10 04:17:26 This function obtains a list of files to be included in a package, using the Oct 10 04:17:26 globs in FILES_ and the files installed in ${D}. Currently, the only Oct 10 04:17:26 user is package_dbg, but I can see this being useful in package.bbclass as Oct 10 04:17:26 well. Oct 10 04:17:27 Signed-off-by: Chris Larson Oct 10 04:17:38 03Chris Larson  07master * rb0edd6725d 10openembedded.git/ (classes/base.bbclass lib/oe/packagegroup.py): (log message trimmed) Oct 10 04:17:38 oe.packagegroup: add code for package groups Oct 10 04:17:38 This includes some utility functions for dealing with groups of packages Oct 10 04:17:38 defined in the metadata. Metadata syntax: Oct 10 04:17:38 PACKAGE_GROUP_ = "" Oct 10 04:17:39 If the packages in the group are optional: Oct 10 04:17:39 PACKAGE_GROUP_[optional] = "1" Oct 10 04:17:43 03Chris Larson  07master * r7e76f8041c 10openembedded.git/ (classes/package_dbg.bbclass lib/oe/path.py): Oct 10 04:17:44 oe.path: add 'find' convenience function Oct 10 04:18:30 find is simply an os.walk in generator form, yielding the absolute path to Oct 10 04:18:31 each file. Oct 10 04:18:31 Signed-off-by: Chris Larson Oct 10 04:31:11 03Chris Larson  07master * r28c3bcd49b 10openembedded.git/classes/image.bbclass: Oct 10 04:31:11 image.bbclass: apply package renaming to optional Oct 10 04:31:11 Runs runtime_mapping_rename against PACKAGE_INSTALL_ATTEMPTONLY, which has Oct 10 04:31:11 packages we'd like to install, but which are optional. Oct 10 04:31:11 Signed-off-by: Chris Larson Oct 10 04:31:23 03Chris Larson  07master * rea01e75217 10openembedded.git/classes/image.bbclass: Oct 10 04:31:23 image.bbclass: use PACKAGE_INSTALL in RDEPENDS Oct 10 04:31:23 Don't Repeat Yourself. Oct 10 04:31:24 Signed-off-by: Chris Larson Oct 10 04:31:25 03Chris Larson  07master * r24c7cb878c 10openembedded.git/classes/image.bbclass: Oct 10 04:31:26 image.bbclass: don't export PACKAGE_INSTALL Oct 10 04:31:27 It doesn't need to be exported, as the rootfs classes use the bitbake variable Oct 10 04:31:28 directly, not the shell variable created from it. Oct 10 04:31:29 Signed-off-by: Chris Larson Oct 10 04:31:30 03Chris Larson  07master * r4271024e26 10openembedded.git/classes/ (image.bbclass rootfs_ipk.bbclass): Oct 10 04:31:36 image.bbclass: add LINGUAS_INSTALL to PACKAGE_INSTALL. Oct 10 04:31:36 They aren't a special case, no reason to handle them that way, as we can Oct 10 04:31:36 leverage overrides. Oct 10 04:31:37 Signed-off-by: Chris Larson Oct 10 05:40:25 03Chris Larson  07master * rb680c0dd6b 10openembedded.git/ (5 files in 2 dirs): Oct 10 05:40:25 Move packagedata code into oe.packagedata Oct 10 05:40:25 Signed-off-by: Chris Larson Oct 10 05:40:31 03Chris Larson  07master * ra3fa60656f 10openembedded.git/ (3 files in 2 dirs): Oct 10 05:40:31 Implement 'dbg', 'dev', and 'doc' package groups Oct 10 05:40:31 These allow one to include debugging, development, and documentation files for Oct 10 05:40:31 all packages installed in the image, via IMAGE_FEATURES. Oct 10 05:40:31 Signed-off-by: Chris Larson Oct 10 05:40:34 03Chris Larson  07master * r7773452709 10openembedded.git/classes/image.bbclass: Oct 10 05:40:35 image.bbclass: implement IMAGE_FEATURES Oct 10 05:40:36 IMAGE_FEATURES, as with the other _FEATURES variables, is a space separated Oct 10 05:40:37 list of words which identify pieces of functionality to be included / Oct 10 05:40:38 supported. Currently, any defined package group may be included (see the Oct 10 05:40:39 oe.packagegroup python module). Oct 10 05:41:33 Signed-off-by: Chris Larson Oct 10 05:44:25 Crofton: there you are, went ahead and pushed the image features bits, but split it up into more sane chunks and renamed IMAGE_FEATURE_* to PACKAGE_GROUP_* Oct 10 06:54:44 03Martin Jansa  07master * r60336c58a3 10openembedded.git/recipes/xserver-nodm-init/ (xserver-nodm-init-2.0/xserver-nodm xserver-nodm-init_2.0.bb): Oct 10 06:54:44 xserver-nodm-init_2.0: move Xsession log from /tmp/x.log to /var/log/Xsession.log Oct 10 06:54:44 Signed-off-by: Martin Jansa Oct 10 07:09:36 03Khem Raj  07master * r77eaf6d5d3 10openembedded.git/conf/bitbake.conf: (log message trimmed) Oct 10 07:09:36 bitbake.conf: Define LIBTOOL_HAS_SYSROOT Oct 10 07:09:36 * Set default weak to "no" Oct 10 07:09:36 * Use in TARGET_LDFLAGS Oct 10 07:09:36 Signed-off-by: Khem Raj Oct 10 07:09:37 Acked-by: Martin Jansa Oct 10 07:09:37 Acked-by: Frans Meulenbroeks Oct 10 07:09:38 03Khem Raj  07master * r014bd3b534 10openembedded.git/classes/autotools.bbclass: (log message trimmed) Oct 10 07:09:39 autotools.bbclass: Conditionally use autotools_prepackage_lamangler Oct 10 07:09:39 * autotools_prepackage_lamangler is not needed with libtool 2.4+ Oct 10 07:09:40 * add --with-sysroot when using libtool 2.4+ Oct 10 07:09:40 Signed-off-by: Khem Raj Oct 10 07:09:41 Acked-by: Martin Jansa Oct 10 07:09:41 Acked-by: Frans Meulenbroeks Oct 10 07:09:44 03Khem Raj  07master * raa293507bf 10openembedded.git/recipes/binutils/ (binutils-2.20.1/libtool-2.4-update.patch binutils_2.20.1.bb): Oct 10 07:09:44 binutils_2.20.1.bb: Updates to use libtool 2.4 macros Oct 10 07:09:45 * Use this patch conditionally only if libtool 2.4 is selected Oct 10 07:09:45 Signed-off-by: Khem Raj Oct 10 07:09:45 Acked-by: Martin Jansa Oct 10 07:09:46 Acked-by: Frans Meulenbroeks Oct 10 09:03:36 03Khem Raj  07master * r88cb8237bc 10openembedded.git/recipes/libgee/ (libgee.inc libgee_0.5.2.bb libgee_0.6.0.bb): Oct 10 09:03:36 libgee_0.5.2.bb/libgee_0.6.0.bb: Fix native recipe build Oct 10 09:03:36 Signed-off-by: Khem Raj Oct 10 09:08:42 03Koen Kooi  07org.openembedded.dev * rc6c105e408 10openembedded.git/conf/distro/ (2 files in 2 dirs): angstrom next: switch to libtool 2.4, activate sysroot support, bump DISTRO_PR Oct 10 10:11:58 03Alexander Stohr  07master * r22b4c17b8e 10openembedded.git/recipes/freetype/ (6 files in 4 dirs): Oct 10 10:11:58 fix for building freetype-native on a symlinked build environment Oct 10 10:11:58 patchyfied for 2.2.1, 2.3.6 and 2.3.12 including recipes changes Oct 10 10:11:58 see attachment Oct 10 10:11:58 Signed-off-by: Khem Raj Oct 10 10:11:59 03Chase Maupin  07master * rbf10a3fdd6 10openembedded.git/recipes/desktop-file-utils/ (desktop-file-utils_0.3.bb desktop-file-utils_0.6.bb): Oct 10 10:12:00 desktop-file-utils: fix broken download links Oct 10 10:12:00 * fixed the SRC_URI download links Oct 10 10:12:00 * fixed md5 and sha256 sums for the downloads Oct 10 10:12:01 * Updated recipe license Oct 10 10:12:01 Signed-off-by: Chase Maupin Oct 10 10:12:02 Signed-off-by: Khem Raj Oct 10 10:12:11 03Kelvie Wong  07master * r56d868fe0b 10openembedded.git/recipes/images/initramfs-image.bb: Oct 10 10:12:12 initramfs-image: Make intiramfs images cpio.gz Oct 10 10:12:12 The kernel doesn't recognize anything else, anyways. Oct 10 10:12:12 Signed-off-by: Khem Raj Oct 10 10:40:00 gm Oct 10 11:50:16 03Frans Meulenbroeks  07org.openembedded.dev * r07c1cfc6f9 10openembedded.git/recipes/xserver-common/files/ (at-fix-slcxxxx.patch softkeys-slcxxxx-xmodmap.patch): Oct 10 11:50:16 xserver-common : moved unused files to obsolete dir Oct 10 11:50:16 Signed-off-by: Frans Meulenbroeks Oct 10 11:50:40 03Frans Meulenbroeks  07org.openembedded.dev * r65abd0ee86 10openembedded.git/recipes/xffm/xffm-4.2.0/link.patch: Oct 10 11:50:40 xffm : moved unused files to obsolete dir Oct 10 11:50:40 Signed-off-by: Frans Meulenbroeks Oct 10 11:50:40 03Frans Meulenbroeks  07org.openembedded.dev * r0473644330 10openembedded.git/recipes/gsoap/gsoap/rename_bogus_ldflags.patch: Oct 10 11:50:41 gsoap : moved unused files to obsolete dir Oct 10 11:50:41 Signed-off-by: Frans Meulenbroeks Oct 10 11:50:42 03Frans Meulenbroeks  07org.openembedded.dev * r783f3cdb23 10openembedded.git/recipes/gtk+/ (6 files in 3 dirs): Oct 10 11:50:42 gtk+ : moved unused files to obsolete dir Oct 10 11:50:43 Signed-off-by: Frans Meulenbroeks Oct 10 11:51:03 03Frans Meulenbroeks  07org.openembedded.dev * r067e6a9f69 10openembedded.git/recipes/xorg-driver/ (4 files in 2 dirs): Oct 10 11:51:03 xorg-driver : moved unused files to obsolete dir Oct 10 11:51:10 Signed-off-by: Frans Meulenbroeks Oct 10 11:51:10 03Frans Meulenbroeks  07org.openembedded.dev * r832d9fdd7c 10openembedded.git/recipes/xtscal/xtscal/xtscal-cxk.patch: Oct 10 11:51:10 xtscal : moved unused files to obsolete dir Oct 10 11:51:10 Signed-off-by: Frans Meulenbroeks Oct 10 11:51:10 03Frans Meulenbroeks  07org.openembedded.dev * r4c448d3016 10openembedded.git/recipes/gsm/files/ (11 files): Oct 10 11:51:11 gsm : moved unused files to obsolete dir Oct 10 11:51:11 Signed-off-by: Frans Meulenbroeks Oct 10 11:51:12 03Frans Meulenbroeks  07org.openembedded.dev * ra20337cda1 10openembedded.git/recipes/gtk-webcore/midori/ua-iphone-0.1.10.patch: Oct 10 11:51:12 gtk-webcore : moved unused files to obsolete dir Oct 10 11:51:13 Signed-off-by: Frans Meulenbroeks Oct 10 11:51:13 03Frans Meulenbroeks  07org.openembedded.dev * rcddb2d4f41 10openembedded.git/recipes/xfce-base/xfce4-settings-4.6.1/xfce4-settings-4.6.1-workspaces.c.patch: Oct 10 11:51:14 xfce-base : moved unused files to obsolete dir Oct 10 11:52:04 Signed-off-by: Frans Meulenbroeks Oct 10 13:41:21 A recipe I'm doing is trying to do "install -s binary" and of course, is failing Oct 10 13:41:46 I can override the install binary, but what is the correct variable? Oct 10 13:41:52 Something like ${INSTALL} Oct 10 13:43:52 hi , how can i enable backface culling on clutter ? someone know ? Oct 10 14:51:52 hi all , when i use pkg-config i got some wrong paths like as shown below, it almost working but i need to modify some 2 paths on below result Oct 10 14:51:52 like this: Oct 10 14:51:52 -L/home/kadirbasol/OE/sdk/usr/local/angstrom/arm/arm-angstrom-linux-gnueabi/home/kadirbasol/OE/sdk/usr/local/angstrom/arm/arm-angstrom-linux-gnueabi/lib Oct 10 14:51:52 But its repeating the path 2 times , i need to change it to : Oct 10 14:51:53 -L/home/kadirbasol/OE/sdk/usr/local/angstrom/arm/arm-angstrom-linux-gnueabi/lib Oct 10 14:51:55 where can i change this -L on pkg-config clutter-eglnative-1.0 , can someone give some way to edit paths ? Oct 10 14:51:57 Here is full result of page : http://pastebin.com/K5quk7G0 Oct 10 15:14:20 B_Lizzard: which package is it and whats exact error ? generally you need to install the directory before the file itself Oct 10 15:15:04 It was an issue with the upstream makefile, I just had the -s removed. Oct 10 15:15:14 ok Oct 10 15:15:19 It was in a recipe for snownews Oct 10 15:15:47 bitbake has the binaries stripped anyways Oct 10 15:29:48 hm, am I missing something here? http://pastebin.org/108580 Oct 10 15:30:35 I just don't get why it is looking for the patch in recipes/lua/files/makefile.patch and not at recipes/lua/lua-zeromq-git/makefile.patch Oct 10 15:31:27 Put it in lua-zeromq Oct 10 15:32:23 ah I see it now, looks like a cache problem Oct 10 15:33:12 I've renamed the recipe from lua-zeromq_0.1.0.bb to lua-zeromq_git.bb and it seems like the bitbake didn't noticed it Oct 10 15:36:07 Hi, I am building my root filesystem with buildroot and I am using OE to build some packages. I can almost install them fine, except for a problem with update-rc.d as busybox's init doesn't support runlevels. Does any of you have an idea on how to fix this? Oct 10 15:39:01 Is there a command line parameter I could define in distro.conf or something like that to instruct OE to build the packages with busybox's inittab format? Oct 10 15:39:11 nope. it's not supported by it today Oct 10 15:39:37 i'd suggest creating an empty, dummy update-rc.d script and manually add things Oct 10 15:42:45 03Chris Larson  07master * r31afd66b9a 10openembedded.git/lib/oe/packagegroup.py: Oct 10 15:42:45 oe.packagegroup: fix python version compat issue Oct 10 15:42:45 Signed-off-by: Chris Larson Oct 10 15:42:46 Thanks! The reason I am using buildroot is because of its support for external toolchains. I was able to build packages with OE using an external toolchain, but I couldn't build an image. Is there a sample config for building a minimal image with an external toolchain? Oct 10 15:44:54 The difficulty in doing that lies in the fact that some of the files from the toolchain need to go into root filesystems we create -- e.g. libgcc, the c library, etc Oct 10 15:45:06 so it needs to know about the layout of the particular external toolchain you're using Oct 10 15:45:12 (at least, to fully support it) Oct 10 15:45:29 I am using a toolchain built with Crosstool-NG Oct 10 15:45:45 there are recipes in oe for external toolchains, which expect certain layouts, iirc. one of them requires that it use an external toolchain generated by oe (meta-toolchain recipe) for example Oct 10 15:45:51 not sure if there's an existin recipe to handle that one Oct 10 15:46:13 making oe build things using that toolchain should be easy, its just the packaging of the toolchain bits i mentioned that adds any real complexity to it Oct 10 15:46:33 Exactly. I can build packages, but I cant build images Oct 10 15:46:53 take a look at recipes/meta/external-toolchain.bb (or something like that, i can't recall the exact path) for an example of the sort of thing you'd want to do to fully support your toolchain Oct 10 15:47:03 supporting crosstool-ng would be a worthy goal Oct 10 15:47:17 okay, right, recipes/meta/ has a few Oct 10 15:47:28 external-toolchain, external-toolchain-csl, external-toolchain-generic Oct 10 15:47:34 "generic" sounds rather promising Oct 10 15:47:57 Ok, but how would I go about using them? bitbake external-toolchain-generic? Oct 10 15:48:09 no, you set some preferred provider variables Oct 10 15:48:18 so bitbake knows you want that to provide your gcc, glibc, etc Oct 10 15:48:25 otherwise it'll run off and build those things Oct 10 15:48:48 ok, so I set that in local.conf? Oct 10 15:49:17 i don't recall them off the top of my head, a bit of googling for openembedded external-toolchain might find it, otherwise you can look in conf/distro/, where distros usually set their preferred versions/providers of things Oct 10 15:49:20 yeah Oct 10 15:50:08 http://www.mail-archive.com/openembedded-devel@lists.openembedded.org/msg05863.html Oct 10 15:50:27 Ok. I have already set some preferred providers building packages. My local.conf: http://pastebin.com/ZS7WKw6d Oct 10 15:51:29 that thread looks like it shows how to use the external toolchain recipes nicely, using a helper in conf/distro/include/ Oct 10 15:52:00 Thanks! I am looking at it right now Oct 10 15:52:02 again not sure if the generic one will work 100% with yours, just have to give it a shot, and if not, create external-toolchain-ctng :) Oct 10 15:55:14 Looks very promissing! I will test it right now and give you some feedback Oct 10 15:55:17 Thx! Oct 10 15:55:40 np Oct 10 16:13:47 kergoth, are you still there? I think the solution you pointed out could work, but my toolchain has the preffix -gnueabi. Do you know if I can specify that somehow? Oct 10 16:13:58 I meant suffix Oct 10 16:14:10 arm-unkown-linux-gnueabi-gcc Oct 10 16:14:22 Hi , when i use pkg-config i got some wrong paths like as shown below, it almost working but i need to modify some 2 paths on below result Oct 10 16:14:24 like this: Oct 10 16:14:24 -L/home/kadirbasol/OE/sdk/usr/local/angstrom/arm/arm-angstrom-linux-gnueabi/home/kadirbasol/OE/sdk/usr/local/angstrom/arm/arm-angstrom-linux-gnueabi/lib Oct 10 16:14:24 But its repeating the path 2 times , i need to change it to : Oct 10 16:14:24 -L/home/kadirbasol/OE/sdk/usr/local/angstrom/arm/arm-angstrom-linux-gnueabi/lib Oct 10 16:14:25 where can i change this -L on pkg-config clutter-eglnative-1.0 , can someone give some way to edit paths ? Oct 10 16:14:27 Here is full result of page : http://pastebin.com/K5quk7G0 Oct 10 16:25:08 kergoth, are you still there? I think the solution you pointed out could work, but my toolchain has the suffix -gnueabi. Do you know if I can specify that somehow? Oct 10 17:00:59 albert__: i assume you mean its --linux-gnueabi-gcc? Oct 10 17:02:22 right. Is the gnueabi added automatically? Oct 10 17:06:31 Now I am getting the following error: cp: cannot stat .../lib/libc/* Oct 10 17:07:54 within the external toolchain recipe? likely what i was talking about, differing layout, so fails to pull files from the toolchain for packaging Oct 10 17:09:26 Yes, it must be somwthing like that. But before this error I get: NOTE: multiple providers are available for virtual/arm-unknown-linux-gcc (external-toolchain-csl, external-toolchain-generic, gcc-cross, external-toolchain); Oct 10 17:09:48 in fact, I should have arm-unknown-linux-gnueabi-gcc, no? Oct 10 17:14:34 ~seen khem Oct 10 17:14:42 khem is currently on #oe (11d 12h 37m 47s) #edev (11d 12h 37m 47s) #uclibc (11d 12h 37m 47s). Has said a total of 987 messages. Is idling for 1h 59m 28s, last said: 'ok'. Oct 10 18:19:34 gm Oct 10 18:54:12 03Klaus Kurzmann  07master * r4bbd4afba6 10openembedded.git/recipes/images/shr-image.inc: Oct 10 18:54:13 shr-image.inc: override DEV_MANGER for nokia900 to get udev Oct 10 18:54:13 Signed-off-by: Klaus Kurzmann Oct 10 18:54:13 Signed-off-by: Martin Jansa Oct 10 18:54:16 03Martin Jansa  07master * r2221d6f564 10openembedded.git/recipes/dbus/ (4 files in 2 dirs): Oct 10 18:54:16 dbus: add recipe for 1.4.0 Oct 10 18:54:16 Signed-off-by: Martin Jansa Oct 10 18:54:16 03Martin Jansa  07master * r74a2f6d917 10openembedded.git/ (4 files in 2 dirs): Oct 10 18:54:16 xorg: add new versions for 20101010 Oct 10 18:54:16 Signed-off-by: Martin Jansa Oct 10 18:54:26 03Martin Jansa  07master * r1357f0894a 10openembedded.git/ (3 files in 3 dirs): Oct 10 18:54:26 EFL: bump SRCREV a bit more Oct 10 18:54:26 Signed-off-by: Martin Jansa Oct 10 18:54:47 03Martin Jansa  07master * radd3b99338 10openembedded.git/conf/distro/include/preferred-shr-versions.inc: Oct 10 18:54:47 SHR: prefer dbus 1.4.0 Oct 10 18:54:47 Signed-off-by: Martin Jansa Oct 10 19:01:16 khem: any hint on that samba build ICE? Oct 10 19:06:57 hi JaMa, florian, khem, all Oct 10 19:07:13 hi all Oct 10 20:07:54 hn Oct 10 20:07:56 hmmm Oct 10 20:08:05 | libudev/libudev-queue.c: In function 'udev_queue_skip_devpath': Oct 10 20:08:05 | libudev/libudev-queue.c:185:1: internal compiler error: in cond_exec_process_insns, at ifcvt.c:273 Oct 10 20:08:54 nice one Oct 10 20:12:42 I suspect there are compile options to resoove this Oct 10 20:12:49 need to double check with khem Oct 10 20:30:24 florian: ping Oct 10 20:31:57 ant_: pong Oct 10 20:32:11 hello Oct 10 20:32:43 I'm converting do_stage of libgpepimc and I have a question Oct 10 20:32:54 how many versions do we really need? Oct 10 20:33:46 see: ./distro/include/preferred-gpe-versions-2.8.inc:PREFERRED_VERSION_libgpepimc ?= "0.9" Oct 10 20:33:46 ./distro/include/preferred-gpe-versions-2.6.inc:PREFERRED_VERSION_libgpepimc ?= "0.4" Oct 10 20:33:46 ./distro/include/preferred-gpe-versions-2.7.inc:PREFERRED_VERSION_libgpepimc ?= "0.5" Oct 10 20:33:46 ./distro/include/preferred-gpe-versions.inc:#PREFERRED_VERSION_libgpepimc ?= "0.4" Oct 10 20:34:18 I already converted the svn and the recipes based on the .inc Oct 10 20:34:30 just wondering about older gpe-versions Oct 10 20:34:44 ant_: I guess the latest one is all we need. Oct 10 20:36:45 what about gpe-versions-2.6 and 2.7 ? Oct 10 20:36:59 (and recipes pinned therein) Oct 10 20:41:04 Crofton|work: yes its a known problem in gcc not solved yet though for now just add CFLAGS += "-Os" to udev recipe Oct 10 20:41:15 JaMa: did not look into it so far Oct 10 20:41:36 khem qemuarm is segfaulting when compiling libudev with gcc 4.5 Oct 10 20:42:00 hey khem, woglinde_ Oct 10 20:42:01 khem: ok, thanks Oct 10 20:42:10 woglinde_: you mean qemu is segfaulting ? or gcc Oct 10 20:42:15 hi JaMa Oct 10 20:42:16 gcc Oct 10 20:42:18 with ice Oct 10 20:42:25 ok Oct 10 20:42:27 woglinde_: yes thats known read my message above Oct 10 20:42:29 that is what I thought Oct 10 20:42:38 I thought you had fixed it though :) Oct 10 20:42:42 woglinde_: about segfaults, remember dietlibc when you can :/ Oct 10 20:42:50 JaMa: I just cleaned my tmp and rebuilding now Oct 10 20:42:52 ah crfoton hits the same Oct 10 20:43:13 ant *sigh* yes Oct 10 20:43:14 JaMa: then I will do bitbake samba and see if I hit it Oct 10 20:43:23 JaMa: btw which machine ? Oct 10 20:43:39 ah the +Os Oct 10 20:43:39 * khem things of adding a temp fix to udev Oct 10 20:46:09 khem: om-gta02 Oct 10 20:46:22 JaMa: is it armv5te Oct 10 20:46:29 IOW is it using thumb ? Oct 10 20:46:29 khem: but I had the same with armv7a Oct 10 20:46:35 JaMa: ok Oct 10 20:46:41 yes it's was with thumb enabled Oct 10 20:46:43 so not a thumb issue prolly Oct 10 20:46:57 with armv7a we have arm only Oct 10 20:47:00 compile options Oct 10 20:47:07 khem, hi is cairo obtimized for armv7? Oct 10 20:47:25 GNUtoo|laptop: in what sense ? Oct 10 20:47:35 I dont think we do anything special in OE for cairo Oct 10 20:47:36 such as uses neon assembly Oct 10 20:47:51 khem: armv5te (spitz) same ICE here Oct 10 20:48:26 GNUtoo|laptop: with latest gcc 4.5 you should not need to optimize apps for armv7 etc it does a darn good job itself Oct 10 20:48:43 khem, because we have an issue which appeared in cairo and I vaguely remember some obtimizations for cairo Oct 10 20:48:45 JaMa: can you create a preprocessed out of the file Oct 10 20:48:56 yup mmt Oct 10 20:49:37 GNUtoo|laptop: I remember someone doing it for pxa Oct 10 20:49:44 few years back Oct 10 20:49:45 ok Oct 10 20:50:20 http://lists.freedesktop.org/archives/cairo/2009-May/017056.html for instance Oct 10 20:50:28 so I wonder if the gcc patches triggered something Oct 10 20:50:36 GNUtoo|laptop: hmmm it seems cairo does care about neon bits Oct 10 20:50:38 or if we should look somewhere else Oct 10 20:51:24 on the same distro, different hardware we see no such issue Oct 10 20:51:31 the issue is that one: Oct 10 20:51:50 http://scap.linuxtogo.org/files/415fe73dfe85d622abf96dbbb850bb42.png Oct 10 20:51:57 http://scap.linuxtogo.org/files/ee43f0bf8a3b81d2df5e172b64c2ba5e.png Oct 10 20:51:58 etc... Oct 10 20:52:18 khem: rpc_client/cli_reg.E from samba-3.2.15-r1 http://paste.pocoo.org/show/273760/ Oct 10 20:53:04 GNUtoo|laptop: btw the date when this was first broken is somehow near when linaro gcc patches were merged to master, so it can be from that Oct 10 20:53:23 ok thanks a lot Oct 10 20:54:32 florian, only uses I see : ./conf/distro/sharprom-compatible.conf:require conf/distro/include/preferred-gpe-versions.inc Oct 10 20:54:33 ./conf/distro/amsdelta-oe.conf:require conf/distro/include/preferred-gpe-versions-2.8.inc Oct 10 20:56:57 so what should we do? Oct 10 20:57:16 change compile flags? Oct 10 20:57:34 ant_: i'm pretty sure both might be able to live with newer ones Oct 10 20:58:59 well ,angstrom and minimal do Oct 10 21:06:55 JaMa: hmmm Oct 10 21:07:16 JaMa: we have to debug the errors if something broken by gcc upgrade Oct 10 21:07:34 or find workaround Oct 10 21:11:50 khem: well I'm not really sure since which gcc version I had this, because I don't have samba in images/tasks I normally build Oct 10 21:13:16 JaMa: here is workaround for samba issue Oct 10 21:13:24 hm cusp still not at 1.4 Oct 10 21:13:26 use -O2 Oct 10 21:13:28 as default Oct 10 21:15:15 JaMa: but I think you should not see this error on armv7a Oct 10 21:18:25 bitbake -c listtasks doesn't seem to return the tasks in execution order? Is there any way to determine their order without actually doing a build? Oct 10 21:23:10 loadammo: you can use -g or can do a dry run Oct 10 21:23:20 good idea Oct 10 21:23:25 loadammo: bitbake doesn't build recipes, internally. it runs tasks. tasks don't only have an order inside a recipe, it's a dependency graph, and tasks can depend on tasks in other recipes (and do). so no, listtasks wouldn't be able to show very much Oct 10 21:25:08 yup. Just trying to figure out how I can get to where I need to be. I've even gone as far as writing a dependency tree utility that uses UbiGraph for understanding whats going on. :D Or trying to understand. :D Oct 10 21:25:25 bitbake -g is the best bet, the .dot files cover everything of importance Oct 10 21:25:49 JaMa, would you mind to give a look at xextproto-70-includes_7.0.5.bb (do_stage)? Oct 10 21:27:39 The thing I seem to run into with the dot graphs is finding the shortest path between 'package I care about' and 'first node', obviously cross-deps will get in the way but without trimming those down the pn-depends.dot looks like a Microsoft org-chart. Maybe I'm doing it wrong. *shrug* Oct 10 21:28:29 ant_: what about it? Oct 10 21:28:49 leagacy do_stage. I'm checking the last survivors... Oct 10 21:29:27 I'm not using xextproto that old.. but looks safe to just remove do_stage there Oct 10 21:29:45 loadammo: not sure what you mean by that. shortest path isn't of much use, given bitbake has to traverse all of them to satisfy all the dependencies and complete the tasks in the recipe -- but what i usually do when i need to make more sense out of it is write a python script to read in the .dot and traverse in particular ways, filtering out particular sets of tasks, etc Oct 10 21:30:37 khem`: ahh sorry, you're right (as always :)), armv7a built went just fine now Oct 10 21:31:20 loadammo: i have a script like that which attempts to just list the recipes that will be built, in a rough build order -- not perfect, since it excludes fetch, unpack, patch, etc, and primarily pays attention to standard relationships -- configure -> populate_sysroot, etc Oct 10 21:31:32 JaMa: cool. the add CFLAGS_thumb += "-O2" to the recipe Oct 10 21:31:39 but it helps give me a picture of what will go into what i'm building, without having to use bitbake's dry run option Oct 10 21:31:43 that should solve it for time being Oct 10 21:31:45 dry-run is, sadly, really really really slow at the moment Oct 10 21:31:57 kergoth: ahh, yeah, thats essentially what I'm shooting for Oct 10 21:31:58 it actually even forks off the child processes for each task, even though the task doesn't do anything Oct 10 21:33:24 i did the script for work, would have to get approval to put it up somewhere public, but its really straight forward. you can exclude the header lines from the .dot and only pay attention to the -> lines, read that into a dependency dictionary, then traverse it in the manner you choose Oct 10 21:33:40 just use regex or even a .split() after filtering out the header lines Oct 10 21:34:12 hm latest xine seems to compile fine now Oct 10 21:34:17 this is where i think it would be nice if bitbake had a proper plugin architecture, to inject python code of your choice at various points -- just hand me the graph bitbake uses and let me poke at it.. Oct 10 21:34:27 heh Oct 10 21:34:31 actually Oct 10 21:35:20 Now that I think of it, that info is all stored in the pickled cache Oct 10 21:35:35 So you don't even need to run bitbake 'again' if you're trying to understand what you've got. Oct 10 21:35:37 that's a good point, the cache is just a giant dictionary Oct 10 21:36:03 * kergoth has recently been thinking that too much of what we do is in the metadata, and that much would be nicer done as plugins into bitbake, let the metadata stay more declarative Oct 10 21:36:06 heh Oct 10 21:37:11 I agree with you whole heartedly. It'd be nice if the graph followed an observer model such that you add a recipe, based on it's dependencies it'd automatically notify them Oct 10 21:37:17 It'd be a kabillion times faster Oct 10 21:37:40 And you could store the graph in a database with indexes. :p pickles are for sandwiches. Oct 10 21:38:09 i tried that -- i'm an sql noob, but i tried using sqlite in multiple ways for the cache just a couple weeks ago Oct 10 21:38:15 horribly, horribly, horribly slow Oct 10 21:38:25 memory backed or disk backed? Oct 10 21:38:46 disk. haven't tried memory yet Oct 10 21:39:02 using faster structures is probably better rather than databases IMO Oct 10 21:39:15 khem`: doesn't seem enough (-O2) Oct 10 21:40:02 this isn't a case where a database is necessarily the best route -- to construct the runqueue, it needs *all* the data in the cache, not selective, so taking the upfront pain of pulling it into ram at once isn't necessarily the worst route Oct 10 21:40:03 JaMa: hmmm Oct 10 21:40:18 but, i know very little about databases and data architecture in general Oct 10 21:40:34 I assert that the bitbake cache should be in memory when you're working with it so that as a developer you wouldn't have to keep rescanning it. Oct 10 21:40:51 And that you would avoid rescanning by using inotify to detect modified recipes Oct 10 21:41:44 that's much ,much, much more difficult than it seems, just due to how the metadata is implemented :( Oct 10 21:42:12 i've wanted that for a long time, its part of why i did the code for metadata signatures and variable reference tracking, so we'd be able to propogate dirty state for the variables when a single file is reparsed Oct 10 21:42:26 Regardless, even with all the jumping through hoops -- you'd be doing it from memory instead of reading it off disk every time. Oct 10 21:42:39 JaMa: can you check if O2 was passed now on commandline atleast Oct 10 21:43:15 Well, I posit -- I don't know. Oct 10 21:43:32 today, a great deal of information is lost after the parse Oct 10 21:43:35 You've got more experience working under the hood, so don't take my wild guesses for dismissal of your experience. :D Oct 10 21:43:49 when, say, a += happens, the old value is gone, it has no idea that part came from here and part came from there, the origin is gone Oct 10 21:44:00 khem`: yes it was just after -Os, but even when I remove -Os it still ICE Oct 10 21:44:04 Really? Wow. Oct 10 21:44:08 khem`: the same for -O1, -O0 Oct 10 21:44:18 JaMa: show me complete commandline Oct 10 21:44:24 khem`: and without -fexpensive-optimizations -fomit-frame-pointer -frename-registers Oct 10 21:44:40 03Henning Heinold  07org.openembedded.dev * r5fb783bdaf 10openembedded.git/recipes/libgsm/ (8 files in 2 dirs): libgsm: update to version 1.0.13 and use .inc file Oct 10 21:44:42 03Henning Heinold  07org.openembedded.dev * r333a7f59dc 10openembedded.git/recipes/libcdio/libcdio.inc: Oct 10 21:44:42 libcdio: inherit pkgconfig, so the .pc files get fixed for libiconv, when uclibc is used Oct 10 21:44:42 * bump INC_PR Oct 10 21:44:42 03Henning Heinold  07org.openembedded.dev * re7632af7a4 10openembedded.git/recipes/libxine/ (6 files in 2 dirs): Oct 10 21:44:43 libxine: update to version 1.1.19 Oct 10 21:44:43 * remove older 1.1.16 version Oct 10 21:44:43 arm-oe-linux-gnueabi-gcc -march=armv4t -mtune=arm920t -mthumb-interwork -mthumb -I. -I/OE/tmpdir-shr/work/armv4t-oe-linux-gnueabi/samba-3.2.15-r1/samba-3.2.15/source -isystem/OE/tmpdir-shr/sysroots/armv4t-oe-linux-gnueabi/usr/include -fexpensive-optimizations -fomit-frame-pointer -frename-registers -Os -O2 -O -D_SAMBA_BUILD_=3 -I/OE/tmpdir-shr/work/armv4t-oe-linux-gnueabi/samba-3.2.15-r1/samba-3.2.15/source/iniparser/src -Iinclude -I./include -I. -I. Oct 10 21:45:20 who is adding that -O at the end Oct 10 21:45:29 zecke added a rudamentary AST to allow us to be able to re-execute the operations for files when one of their dependencies changes, which is a step in the right direction Oct 10 21:45:31 but there's a long way to go Oct 10 21:45:45 good nite Oct 10 21:46:03 Hmm. If you used a tree with visitor pattern you could save the journal of actions. Oct 10 21:46:07 I've often wanted to just ditch the current codebase and start from scratch, but most would prefer an incremental refactoring approach, so.. Oct 10 21:46:27 ahh yeah Oct 10 21:46:52 I'm sure lots of people have lots of opinions on how to solve this problem. XD Oct 10 21:46:59 http://github.com/kergoth/OE-Signatures/blob/transform/lib/bbvalue.py turns variables into a tree of nodes with visitors/transformers to "expand" variables and run the python snippets, etc Oct 10 21:47:12 JaMa: you need to get rid of the -O at the end Oct 10 21:47:12 khem`: ./configure.in: CFLAGS="${CFLAGS} -O" Oct 10 21:47:14 can re-evaluate the tree for a given variable easily, extract information about variable references Oct 10 21:47:20 ahh neat Oct 10 21:47:22 it also scans shell and python tasks to determine what variables they use Oct 10 21:47:31 not ${} style i mean Oct 10 21:47:34 JaMa: ok that needs to change Oct 10 21:47:37 but python bb.data.getVar() calls and the like Oct 10 21:47:46 you really should check out UbiGraph if you're spending a lot of time on the graphing stuff. :D Oct 10 21:47:57 JaMa: hang on Oct 10 21:47:58 khem`: still ICE Oct 10 21:48:04 * kergoth adds note to check it out Oct 10 21:50:12 JaMa: does not ICE for me Oct 10 21:50:25 my thought with this stuff was that a += operation would actually construct a new Compound value of the old and new components, so we'd never lose track of what we appended to -- but its not quite so simple, we'd need a registry to look into to get the previous version, rather than storing a direct reference tot he current previous node Oct 10 21:50:32 khem`: now I'm trying it on armv4t, can try on armv5te, mmt Oct 10 21:51:09 Hmm. I guess if you just treated it like an array it could get kinda long? Oct 10 21:51:44 JaMa: -march=armv4t -mtune=arm920t -fomit-frame-pointer -frename-registers -fexpensive-optimizations -Os -O2 -O -mthumb -mthumb-interwork Oct 10 21:51:47 yeah its just a list internally, but it's more a tree in the long run, very few of the lists contain many elements directly Oct 10 21:51:49 this is what I used Oct 10 21:52:01 as long as we cache intelligently, im not too worried about that Oct 10 21:52:37 * kergoth would really rather switch to a new less crappy file format first, but that'd be a long way out for compatibility reasons :\ Oct 10 21:52:43 yeah Oct 10 21:52:49 I hear you Oct 10 21:53:42 i like the design of some other tools for single recipes better than ours, but none of the other projects have the same massive pool of metadata that's collaboratively developed -- there's more wheel reinvention with tools like e2factory than there is with oe, even though i like the use of lua better than our stuff in many ways Oct 10 21:53:48 kergoth: changing bb file format ? Oct 10 21:53:52 we can only hope Oct 10 21:53:57 _append/_prepend need to die in a fire Oct 10 21:54:05 just to start with Oct 10 21:54:24 hmm. heh. If OE didn't use Python I wouldn't even be using it. No way I could figure it out. haha. Oct 10 21:54:35 would be nice if it could distinguish the format without using a different file extension, i really don't want .bb2 Oct 10 21:55:17 working on bitbake code makes me sad a lot Oct 10 21:55:29 aww Oct 10 21:55:34 modules aren't very orthogonal, no unit tests for anything.. Oct 10 21:55:39 its a twisty maze in there Oct 10 21:55:52 khem`: still the same http://paste.pocoo.org/show/273776/ Oct 10 21:57:02 ah well, we'll get there, bit by bit. currently there are only a few people that do any work on bitbake or the core oe classes, unfortunately. most just want to get their work done *with oe* and move on, and i can't blame them :) Oct 11 00:26:00 hello, my compiler is located under "/OE/build/tmp_angstrom_2008_1/sysroots/i686-linux/usr/armv4t/bin", now i would like to move the whole toolchain to another comp with exactly same specs and everything, which dirs do i have to move to get it work properlie? Oct 11 02:58:46 gah. I've been stuck on this for two hours. Trying to build python-cheetah, for some reason it keeps building it into /usr/lib/python2.6/site-packages/Cheetah-2.4.3-py2.6.egg/Cheetah/ Oct 11 02:59:04 So I'd have to add the 'egg' directory.. Oct 11 02:59:07 so stupid **** ENDING LOGGING AT Mon Oct 11 02:59:57 2010