**** BEGIN LOGGING AT Fri Aug 06 02:59:58 2010 Aug 06 03:33:20 * kergoth looks at koen's darwin-host-fixes Aug 06 03:41:02 kergoth, GNU likes extend and embrace more than microsoft :) Aug 06 03:41:45 supporting the posix versions of utilities and not using gnu extensions would gain wider portability Aug 06 03:42:24 http://www.opengroup.org/onlinepubs/009695399/utilities/cp.html Aug 06 04:36:18 yeah, would be nice. unfortunately it's not just us we have to deal with, we have to opatch all the crappy buildsystems too :)) Aug 06 04:58:40 gm Aug 06 05:34:49 eFfeM, hi Aug 06 05:34:53 good morning Aug 06 05:36:03 03Frans Meulenbroeks  07org.openembedded.dev * rd8592c44e4 10openembedded.git/recipes/u-boot/ (10 files in 3 dirs): (log message trimmed) Aug 06 05:36:03 u-boot: calamari: moved to 2010.06 version Aug 06 05:36:03 all changes are calamari specific Aug 06 05:36:03 moved to 2010.06 version Aug 06 05:36:03 made sure all u-boot variants are build and deployed (for nor/nand/sd/spi) Aug 06 05:36:03 removed the patches that have been merged upstream Aug 06 05:36:04 removed a stale file that was not used: buggy-gcc-really-no-spe.patch Aug 06 05:36:07 GNUtoo|laptop: how are you doing, you're early Aug 06 05:36:40 indeed Aug 06 05:36:49 I didn't sleep well,it happens Aug 06 05:37:39 ah Aug 06 05:38:09 I'm reading my mails(tons of oe mails) during the compilation of a console-image for bug(in order to make something like an AP repeater) Aug 06 05:39:27 btw did the python patch for your recipe, but can't seem to build midori which is the only user of it; it is stuck at 3% downloading the src Aug 06 05:40:28 ah? Aug 06 05:41:10 did you try redowloading it from scratch? Aug 06 05:41:36 thanks a lot btw Aug 06 05:41:52 yeah, tried yesterday as well Aug 06 05:42:03 ah ok Aug 06 05:42:06 hmmm Aug 06 05:42:09 btw about python Aug 06 05:42:16 it is an svn pull Aug 06 05:42:20 there is a lot of do_stage in python recipes Aug 06 05:42:21 ok Aug 06 05:42:29 maybe we could ask mickeyl about that Aug 06 05:43:42 there are 31 recipes in the python dir with a do_stage in it Aug 06 05:44:11 some of them are older versions and could be gone Aug 06 05:44:17 s/gone/removed/ **** ENDING LOGGING AT Fri Aug 06 05:44:27 2010 **** BEGIN LOGGING AT Fri Aug 06 08:30:14 2010 **** ENDING LOGGING AT Fri Aug 06 08:30:21 2010 **** BEGIN LOGGING AT Fri Aug 06 08:32:14 2010 Aug 06 08:45:35 03Martyn Welch  07org.openembedded.dev * rbb5d9dfe46 10openembedded.git/recipes/comedi/comedilib_0.8.1.bb: Aug 06 08:45:35 Comedilib: Add version 0.8.1 Aug 06 08:45:35 The Comedi project develops open-source drivers, tools, and libraries for Aug 06 08:45:35 data acquisition. Aug 06 08:45:35 Comedilib is a user-space library that provides a developer-friendly Aug 06 08:45:36 MWelchUK_work_: was something at my side, fixed that, pushed your change Aug 06 08:45:36 interface to Comedi devices. Aug 06 08:45:36 Signed-off-by: Martyn Welch Aug 06 08:45:40 there you are Aug 06 08:51:07 patchwork is updated too Aug 06 08:57:08 03Henri Bragge  07org.openembedded.dev * r73e60c7cc4 10openembedded.git/recipes/gsnmp/gsnmp_0.3.0.bb: Aug 06 08:57:08 recipe for gsnmp-0.3.0 Aug 06 08:57:08 Signed-off-by: Henri Bragge Aug 06 08:57:09 03Henri Bragge  07org.openembedded.dev * rc945be8078 10openembedded.git/recipes/scli/scli_0.4.0.bb: Aug 06 08:57:09 recipe for scli-0.4.0 Aug 06 08:57:09 Signed-off-by: Henri Bragge Aug 06 09:04:10 03Martin Jansa  07org.openembedded.dev * raa824bdac1 10openembedded.git/conf/distro/include/preferred-shr-versions.inc: Aug 06 09:04:10 shr: prefer ncurses 5.7 Aug 06 09:04:10 Signed-off-by: Martin Jansa Aug 06 09:05:14 khem, your download url for qemu-1.12.5 is wrong; http://paste.debian.net/82366/ Aug 06 09:05:55 khem, _non_gnu.org Aug 06 09:06:44 03Martin Jansa  07org.openembedded.dev * rfc158239be 10openembedded.git/conf/distro/include/preferred-shr-versions.inc: shr: prefer ncurses 5.7 also for native Aug 06 09:08:34 blindvt`: strange, downloaded here fine Aug 06 09:10:29 Hi. When I try to run bitbake I keep getting parse errors. why is that? Aug 06 09:11:36 It runs for sometime showing some numbers and after that it gives an error EOL while scanning string literal while parsing ... some bb file. Aug 06 09:16:51 anybody? Aug 06 09:18:46 JaMa, very odd. you're right. Probably a proxy hickup Aug 06 09:40:54 03Enrico Scholz  07org.openembedded.dev * rcc70c759f4 10openembedded.git/recipes/jpeg/jpeg_8b.bb: Aug 06 09:40:54 jpeg: updated to version 8b Aug 06 09:40:54 jpeg8b is now automake based and does not required the patches from the Aug 06 09:40:54 6b recipe anymore. Aug 06 09:40:54 Signed-off-by: Enrico Scholz Aug 06 10:15:27 jama do you have any affiliation wiht ./distro/include/preferred-om-2008-versions.inc ? lots of the pinnings in it are to very old versions; eg. alsalib is at 1.0.15 which still has legacy staging; as the main recipe is at 0.23. I don't feel like fixing such old recipes, but prefer to put them to rest Aug 06 10:17:53 eFfeM: om is AFAIK dead as OE distro... I guess if someone wants to restore it, he has to update a lot of stuff first.. so I don't see preferred-om-2008-versions.inc important much (I've updated some version there already) Aug 06 10:19:42 jama if it is dead i think it is better to remove it Aug 06 10:20:02 it's pretty embarrassing but i somehow managed to forget my patchwork password (and furthermore seem unable to find a password reset button). Can someone help? Aug 06 10:20:06 it is still in the git and for now in the stable branch so it can be recovered Aug 06 10:21:15 eFfeM: I never worked on/for OM.. so I'm not the right person to remove it (someone else should confirm that there are no secret plans to restore it and then remove it) Aug 06 10:21:36 ah ok brought it up to you as I saw you touched it Aug 06 10:21:57 blindvt no idea on that, sry, maybe reregister? Aug 06 10:22:22 eFfeM: but IMHO if you have some recipe you would like to remove older version (pinned here) then just remove it (and remove pinned version from this file) Aug 06 10:22:31 eFfeM, it doesn't let me do that. It rightfully states that my mail-addr is already taken :( Aug 06 10:22:59 eFfeM: better to use tested version than keeping some older version pinned for no particular reason anymore Aug 06 10:23:13 * mckoan is leaving for Holidays in the Italian Dolomites, have a nice summer :-) Aug 06 10:23:35 mckoan: enjoy Holidays! Aug 06 10:23:40 blindvt no idea who is our admin for that, mickeyl do you by any chance know Aug 06 10:23:47 JaMa: thx ;-) Aug 06 10:33:17 table padding Aug 06 10:33:42 Agh! Aug 06 10:34:08 eFfeM, Cheers, much apprieciated Aug 06 10:34:58 yw :P Aug 06 10:36:25 if there are other recipes waiting to be checked in, and gotten no comments in a week or so feel free to let me know. if they build for me and do not have effect on the build system (e.g. because they are new recipes), I'll happily add them Aug 06 10:36:53 only non-controversial and non-intrusive stuff ofc Aug 06 10:37:59 and ofc they should adhere to the commit policy http://wiki.openembedded.net/index.php/Commit_Policy Aug 06 10:38:08 mckoan|holidays: have a nice vacation Aug 06 10:38:30 eFfeM: if a package is using the file that he copied to STAGING_BINDIR_NATIVE and if we change STAGING_BINDIE_NATIVE to $[D]${bindir_native} then do_install does not find that path coz this path is not added in bitbake.conf file. ALL paths in PATH variable are STAGING variables Aug 06 10:38:58 does do_configure() {oe_runconf} also qualify as is_legacy_staging() ? Aug 06 10:39:26 shouldn't ${D}{bindir_native} and other paths be in that file, in PATH variable? Aug 06 10:39:32 Noor: not really an idea on that, try to peek at another recipe Aug 06 10:39:41 i thought these were defined Aug 06 10:40:04 blindvt` not as legacy staging as it is not staging ;-) Aug 06 10:40:12 these are defined but not exported in PATH variable Aug 06 10:40:17 but i think it can be removed safely Aug 06 10:42:52 eFfeM, yea, i probably ment recipe_sanity Aug 06 10:47:11 blindvt` thinking of it i'm not that sure any more (calling upon higher wizards here :-) ) if is is an autotools recipe it could go, but if not I'm not sure whether configure is still run Aug 06 10:48:01 03Enrico Scholz  07org.openembedded.dev * r4e6aef33e2 10openembedded.git/recipes/readline/ (3 files in 2 dirs): Aug 06 10:48:01 readline: added 6.1 recipe Aug 06 10:48:01 It has a negative default preference for now due to the GPLv2 -> GPLv3 Aug 06 10:48:01 switch. Aug 06 10:48:01 Signed-off-by: Enrico Scholz Aug 06 10:48:05 trying zsh as a test Aug 06 10:48:45 eFfeM, if it inherits autotools then it's superfluous i'd think Aug 06 10:50:54 yes, but I'd rather prefer to test Aug 06 10:51:27 i find it really inconvenient that classextend native packages don't use S = "${WORKDIR}/${nonclassextended_PN}-${PV}" per default Aug 06 10:51:46 03Enrico Scholz  07org.openembedded.dev * r75933adb9a 10openembedded.git/recipes/readline/readline_6.1.bb: Aug 06 10:51:46 readline: apply the patches... Aug 06 10:51:46 Signed-off-by: Enrico Scholz Aug 06 10:52:09 hm zsh w/o the oe_runconf does not build Aug 06 10:52:17 trying with it again Aug 06 10:52:32 lunch break first :-) Aug 06 10:52:41 if i bake qt4-embedded, where will the sdk of qt go in? Aug 06 10:52:55 eFfeM, i was seeing it in e2fsprogs, fyi Aug 06 12:02:20 blindvt` for me without it it does not build Aug 06 12:51:04 03Graham Gower  07org.openembedded.dev * ref6ef8a68a 10openembedded.git/classes/package_ipk.bbclass: (log message trimmed) Aug 06 12:51:04 package_ipk.bbclass: add lists_dir to sysroots' /etc/opkg.conf Aug 06 12:51:04 This makes the sysroots' /etc/opkg.conf agree with opkg-collateral on where Aug 06 12:51:04 the package lists database should be found. Fixes a problem whereby opkg Aug 06 12:51:04 cannot find the package lists after opkg-collateral is installed. Aug 06 12:51:04 This fixes the same problem as acc720fa80227d08fd15764117e0c34e2387e804. Aug 06 12:51:05 But since that doesn't take into account other dependencies bringing Aug 06 12:51:08 03Martin Jansa  07org.openembedded.dev * ra7cc4bc9a7 10openembedded.git/classes/rootfs_ipk.bbclass: (log message trimmed) Aug 06 12:51:08 Revert "rootfs_ipk.bbclass: install the package manager in a separate pass from the other packages" Aug 06 12:51:08 * This reverts commit acc720fa80227d08fd15764117e0c34e2387e804. Aug 06 12:51:08 * Graham already has a proper fix for this. Aug 06 12:51:08 * This breaks rootfs with ${ONLINE_PACKAGE_MANAGEMENT}" == "none" Aug 06 12:51:09 Conflicts: Aug 06 12:51:09 classes/rootfs_ipk.bbclass Aug 06 12:52:16 03Graham Gower  07org.openembedded.dev * r746a5a99da 10openembedded.git/recipes/ (5 files in 2 dirs): Aug 06 12:52:16 Remove redundant dependencies upon opkg and opkg-collateral. Aug 06 12:52:17 rootfs_ipk.bbclass already pulls these in, so avoid some confusion. Aug 06 12:52:17 This is totally untested. Aug 06 12:52:17 Signed-off-by: Graham Gower Aug 06 12:52:17 Acked-by: Chris Larson Aug 06 12:52:17 Acked-by: Martin Jansa Aug 06 13:22:24 Hm, even with 2 acks I do not like this commit message: (14:52:17) CIA-1: This is totally untested. Aug 06 13:46:23 while hacking in base.bbclass to extend 'subdir=' functionality I see that it's easy to break SRC_URI handling. Are there already some regression tests? Aug 06 13:46:35 For subdir= stuff, I wrote https://www.cvg.de/people/ensc/0001-oe-tests-initial-checkin-of-oe-test-src-uri0.bb.patch Aug 06 13:47:03 is this a good idea? Aug 06 13:50:58 blindvt`: why wrong ? arent you able to download from http://download.savannah.gnu.org/releases/qemu/qemu-${PV}.tar.gz Aug 06 13:51:53 khem, sorry it was only a proxy error, all is well Aug 06 13:52:42 ensc|w: generally a good idea Aug 06 13:53:01 is gentoo really snappier Aug 06 13:59:02 blindvt: hello Aug 06 13:59:19 khem, hi Aug 06 14:00:48 heh we won the lawsuit Aug 06 14:07:59 03Koen Kooi  07org.openembedded.dev * r530a3b7e01 10openembedded.git/recipes/libgsm/libgsm_1.0.12.bb: libgsm: kill legacy staging Aug 06 14:07:59 03Koen Kooi  07org.openembedded.dev * r98e581dcc9 10openembedded.git/recipes/mpeg2dec/mpeg2dec_0.4.0b.bb: mpeg2dec: kill legacy staging Aug 06 14:10:21 blindvt: busybox one ? Aug 06 14:10:45 khem, yes Aug 06 14:12:06 hmmm nice ... any links ? Aug 06 14:12:43 hm tinderbox search not working Aug 06 14:13:03 can someone by any chance bake libftdi for me and see if it works, I get an error in configure Aug 06 14:19:03 blindvt: what is the final settlement Aug 06 14:30:55 anyone an idea on this: Aug 06 14:30:57 ERROR: QA Issue with staging: libexslt.pc failed sanity test (tmpdir) in path /home/frans/oe/tmp_angstrom/sysroots/armv7a-angstrom-linux-gnueabi/usr/lib/pkgconfig Aug 06 14:30:57 ERROR: QA Issue with staging: libxslt.pc failed sanity test (tmpdir) in path /home/frans/oe/tmp_angstrom/sysroots/armv7a-angstrom-linux-gnueabi/usr/lib/pkgconfig Aug 06 14:30:57 ERROR: QA staging was broken by the package built above Aug 06 14:31:12 jama maybe? saw you created the latest version Aug 06 14:31:20 03Jason Kridner  07org.openembedded.dev * rcb87bba3dd 10openembedded.git/ (3 files in 3 dirs): Aug 06 14:31:20 linux-omap-psp: Add camera bootarg Aug 06 14:31:20 Signed-off-by: Jason Kridner Aug 06 14:31:20 Signed-off-by: Koen Kooi Aug 06 14:31:26 03Frans Meulenbroeks  07org.openembedded.dev * r6ef56adad3 10openembedded.git/recipes/libxslt/libxslt_1.1.17.bb: Aug 06 14:31:26 xslt: deletel 1.1.17: very old, not pinned Aug 06 14:31:26 Signed-off-by: Frans Meulenbroeks Aug 06 14:31:57 eFfeM: haven't seen this error on my and shr buildhost Aug 06 14:32:28 JaMa: have you used any other system then gentoo and compared the performance experience Aug 06 14:32:28 came out of my build when baking midori Aug 06 14:33:15 khem: yes.. long ago and no big difference I would say Aug 06 14:34:35 may be on 32bit Aug 06 14:34:50 because I dont think all distros tune for core2+ Aug 06 14:34:57 and with gentoo you could Aug 06 14:35:11 I have 64 PhenomII Aug 06 14:35:21 64bit not 64x :) Aug 06 14:35:42 right Aug 06 14:36:20 that was main reason why choose gentoo, because when I first bought 64bit cpu, all other distros had only partial 64bit support (lots of packages available only 32b etc) Aug 06 14:36:40 hmm yes Aug 06 14:36:48 but it takes long time to install it Aug 06 14:36:54 morning Aug 06 14:37:06 with live CD others I get going in 1/2 hrs Aug 06 14:37:15 kergoth_: hi Aug 06 14:37:33 khem: if you can start building it from existing distribution inside prepared chroot, then it's not worse than average OE build :) Aug 06 14:38:24 JaMa: heh true Aug 06 14:38:37 sometimes I think installing OE on a desktop Aug 06 14:42:44 ensc|w: do you know which libs are linked agains jpeg_8b? you should PR bump them as ie staged edje-native now fails because jpeg-6.so is gone.. Aug 06 14:43:25 ensc|w: and from what I remember about same jpeg upgrade in gentoo *lots* of libs are linked against it Aug 06 14:44:16 btw is there a better way to set autoreconf params than this: Aug 06 14:44:18 do_configure_prepend() { Aug 06 14:44:18 autoreconf -i -s -v -f Aug 06 14:44:18 } Aug 06 14:44:55 eFfeM: autoreconf is automatically run Aug 06 14:45:10 with autotools Aug 06 14:45:30 khem I know but apparenty there is an arguments issue, this is with autotools but it generates config.rpath in the wrong dir Aug 06 14:45:42 and with the line above it does work Aug 06 14:46:05 thougth maybe there is a var in which I can set the flags Aug 06 14:46:28 eFfeM: I think this might work but it will run autoconf twice Aug 06 14:46:38 better override whole do_configure Aug 06 14:46:53 will try that Aug 06 14:47:40 EXTRA_AUTORECONF Aug 06 14:48:08 eFfeM: try to add extra options you want to pass there Aug 06 14:51:03 khem checked autotools and that one seems to have the optiosn I need Aug 06 14:59:28 JaMa: oooh... I should have set a negative default preference there :( bumping dependent packages would require touch half of OE :( Aug 06 15:02:17 ensc|w: better to bump it now then keeping it with negative D_P Aug 06 15:02:42 ensc|w: otherwise distro maintainers willing to test it, have to bump PR multiple time one-by-one Aug 06 15:04:42 khem: can we have --as-needed in OE? Angstrom has it prepared partially, but not using it now Aug 06 15:05:20 JaMa: yes Aug 06 15:05:37 JaMa: it needs careful thought a bit Aug 06 15:06:25 I'm using it on gentoo for long and now it's enabled by default.. so there is lots of patches for stuff failing with it Aug 06 15:06:34 as-needed won't help very much because it is ignored for most libraries (libtool does not add it for libraries) Aug 06 15:07:25 we provide our own libtool and can stick it in Aug 06 15:10:59 hmm, sanity checked an integration of all my pending bitbake branches with a console-image build, no problems, that's good to see.. maybe i should think about merging these Aug 06 15:12:20 03Koen Kooi  07org.openembedded.dev * r6b099fc311 10openembedded.git/conf/distro/include/angstrom-2008-preferred-versions.inc: angstrom: jpeg 8b doesn't build, prefer 6b for the time being Aug 06 15:12:29 khem played wiht EXTRA_AUTORECONF, adding -s made it working no idea why installing symlinks instead of copies would help Aug 06 15:12:34 maybe a parallel make issue Aug 06 15:13:19 kergoth: cool Aug 06 15:13:30 kergoth: I can help testing them Aug 06 15:14:03 may be bitbake should be released along with OE in bundle Aug 06 15:14:44 http://github.com/kergoth/bitbake/compare/master...logging - could use review of this as well as testing Aug 06 15:15:26 http://github.com/kergoth/bitbake/compare/master...vercmp is trivial, but doesn't seem to break anything, at least for me -- bitbake -s still shows the same versions Aug 06 15:16:17 course that one we can always subclass the distutils version class(es) ourself to customize comparison behavior, rather than the old way Aug 06 15:16:47 I'm not sure if http://github.com/kergoth/bitbake/compare/master...data is useful or not, I kind of like the idea, but I'm uncertain Aug 06 15:17:22 I think http://github.com/kergoth/bitbake/compare/master...sched is definitely going to be useful at some point Aug 06 15:18:14 http://github.com/kergoth/bitbake/compare/master...cache I'm also not sure about -- the performance benefit isn't huge, and it bumps the ram usage during the build slightly (though not extremely so), it caches the parsed data for a given recipe until that recipe's tasks are all completed Aug 06 15:18:35 03Koen Kooi  07org.openembedded.dev * r25b7d02b89 10openembedded.git/recipes/linux/linux-omap-psp_2.6.32.bb: linux-omap-psp 2.6.32: fix SRC_URI indentation Aug 06 15:20:08 http://github.com/kergoth/bitbake/commit/d2bc6da861424724694ba84d9e7dae2d7391c79e was just experimentation / prototyping - experimenting with variable typing, storing non-string objects in the metadata -- the idea here is our space separated list variables could actually *be* lists, no more (getvar(foo) or "").split() crap, but it would have a __str__ such that it auto-concatenates when emitted to shell / expanded Aug 06 15:22:06 course the problem trying something like that is dealing with -- when does the conversion happen.. at finalize causes problems, since you might want to use it before that.. but to do it before that, you'd have to ensure the types all know how to append/prepend, etc so the parsing can modify them Aug 06 15:23:11 http://github.com/kergoth/bitbake/commit/ab671da2dd4a6c37a721b92523528461851b0b12 was fun to play with, but I *know* it breaks things :) Aug 06 15:24:03 I think that covers most of the pending bits, other than the variable reference tracking integration, which isn't yet ready Aug 06 16:09:21 what is the correct way to depend on a specific task of a package via DEPENDS? I have a recipe that uses artifacts from DEPLOY_DIR_IMAGE thus I need it to depend on things like the deploy task of u-boot. I find that simply DEPENDS += "u-boot" implies some task prior to deploy (what would that be?) Aug 06 16:10:29 you don't use DEPENDS for that Aug 06 16:10:31 you use flags Aug 06 16:10:46 i.e. do_mytask[depends] += "someotherrecipe:do_some_other_task" Aug 06 16:11:29 ah... ok. Out of curiousity what task does DEPENDS= base off of? Aug 06 16:18:47 DEPENDS makes your do_configure/do_compile depend upon the do_populate_staging of all the things you depend on Aug 06 16:19:28 technically, it could probably be fully implemented in the metadata, by taking that and setting deptask/rdeptask flags from it, but.. :) Aug 06 16:19:54 that's afaik, of course. Aug 06 16:26:33 kergoth, thanks! Aug 06 16:27:05 np Aug 06 17:22:35 kergoth_: I am reading thru srctree.bbclass Aug 06 17:23:05 kergoth_: do_populate_sysroot is overridden and runs do_install and do_stage Aug 06 17:23:11 do we need to run do_stage Aug 06 17:23:16 it hasn't been updated for the new staging stuff Aug 06 17:23:23 hasn't been touched since I wrote it, really Aug 06 17:23:24 I see Aug 06 17:23:28 so likely not :) Aug 06 17:23:28 heh Aug 06 17:25:02 kergoth_: basically I can just remove that from running right Aug 06 17:25:36 * khem is still trying to understand the underlying logic in merge_tasks Aug 06 17:27:39 conceptually, it wants to merge all the tasks that modify the source tree, or copy files from the source tree, so that means everything after patch up to install, stage, deploy Aug 06 17:28:46 merge into what Aug 06 17:28:55 single task ? Aug 06 17:29:25 yeah Aug 06 17:29:42 that will be one task per recipe then right Aug 06 17:29:48 for this case Aug 06 17:31:06 merge_tasks simply adjusts deps so anything depending on the tasks we're going to run manually depends on the new task instead Aug 06 17:31:08 basically Aug 06 17:31:13 for all the sorts of dependencies Aug 06 17:31:32 then the other task just explicitly runs the tasks it took over responsibility for Aug 06 17:32:11 ah Aug 06 17:32:37 that's the idea, anyway Aug 06 17:32:46 deltasks = gather_taskdeps("do_patch") Aug 06 17:33:06 this will delete do_patch and its deps Aug 06 17:33:09 yeah, while we're there we just drop fetch/unpack/patch entirely, since we know they aren't necessary. it'd be harmless to remove that though Aug 06 17:33:15 since they'll just be no-ops with empty SRC_URI Aug 06 17:34:11 all the tasks they merge into one big task do_populate_sysroot Aug 06 17:34:14 right ? Aug 06 17:34:18 'deps' are internal task dependencies Aug 06 17:34:21 i.e. addtask this before that Aug 06 17:34:44 internal means local to recipe ? Aug 06 17:35:39 yep. it gathers up everything that do_populate_sysroot depends upon, recursively, into the mergetasks variable, adjusts everything that depends on that to point at the new task, (this is the first loop), then it makes sure the deltasks are removed from that tree Aug 06 17:35:56 then the third loop gathers up antyhing the mergetasks depended on in other recipes ("depends" flag) into the new task too Aug 06 17:36:15 now, i don't see any reason the do_populate_sysroot there couldn't just use the same thing the merge tasks did Aug 06 17:36:24 the gather_taskdeps of the new task Aug 06 17:36:37 though.. no, i guess now Aug 06 17:36:39 not Aug 06 17:36:51 but maybe merge_tasks should save the mergetasks somewhere, i dunno Aug 06 17:36:58 it just seems silly to hardcode in do_opulate_sysroot what we're running Aug 06 17:37:04 when merge_tasks goes by what it depends on Aug 06 17:37:24 we'd might as well save mergedtasks - deltasks into a variable, and have do_populate_sysroot manually exec those tasks Aug 06 17:37:37 I think. :) Aug 06 17:37:48 is that clearer, or did I make it more confusing? :) Aug 06 17:38:37 that class could probably use some more comments Aug 06 17:38:46 yeah Aug 06 17:39:11 conceptually its pretty simple, just there's lots of deps to adjust Aug 06 17:39:13 may be unlink the deps create meta task and relink the deps Aug 06 17:39:52 can't use bitbake deps to run the tasks or we're back in the same boat we're in today. the meta task has to run the tasks with exec_task/exec_func, can't let bitbake do it, if that's what you mean by relink the deps Aug 06 17:40:06 oh, i think i see what you mean Aug 06 17:40:12 leave the inter-mergetasks deps in tact Aug 06 17:40:17 just break the direct deps Aug 06 17:40:23 and exec those recursively Aug 06 17:40:24 yes Aug 06 17:41:05 in fact, thats probably what it does now, just it hardcodes the do_install/do_stage, when we should instead save the direct deps of do_populate_sysroot somewhere for safe keeping Aug 06 17:41:06 and use taht Aug 06 17:41:10 because it will serialize the access to ${S} Aug 06 17:41:54 oh, i see Aug 06 17:42:16 we should just exec the existing do_populate_sysroot from the new task. save it and run it recursively Aug 06 17:42:30 still need the deps adjustments, of course Aug 06 17:42:42 but that'd reduce the knowledge of how install/staging works Aug 06 17:42:47 right Aug 06 17:42:51 it shouldn't care, other than to know the task it needs to replace Aug 06 17:43:59 can likely leave merge_tasks the way it already is, just make it also rename do_populate_staging to do_populate_staging_old or something, copying its deps over too, and rename our wrapper to do_populate_staging with empty deps Aug 06 17:44:12 and make the wrapper only run do_populate_staging_old Aug 06 17:44:13 right? Aug 06 17:44:42 * kergoth_ thinks these sorts of details likely scare off most OE users :) Aug 06 17:45:02 it's okay people, feel free to talk.. :) Aug 06 17:45:05 heh but they will just use it :) Aug 06 17:45:09 :) Aug 06 17:45:23 eat the sausage dont see it being made Aug 06 17:46:12 looking at rec_exec_task Aug 06 17:46:40 does bb remove the dep once its executed Aug 06 17:46:58 not sure what you mean Aug 06 17:47:09 exec_task doesn't obey deps, and doesn't write stamps either iirc Aug 06 17:47:23 oh i see Aug 06 17:47:26 deps are a tree Aug 06 17:48:09 each task deps on something else, which deps on something else, down the line. 'deps' is just a list of the tasks it runs 'after' in addtask parlance Aug 06 17:48:51 I am trying to understand the loop in that function Aug 06 17:49:00 for dep in d.getVarFlag(task, "deps"): Aug 06 17:49:00 if not dep in seen: Aug 06 17:49:00 rec_exec_task(dep, seen) Aug 06 17:49:00 seen.add(task) Aug 06 17:49:35 seen holds the task/deps it has executed Aug 06 17:49:37 right Aug 06 17:49:38 just avoids running the same task more than once Aug 06 17:49:53 i.e. do_foo deps on do_bar and do_baz, and do_bar also deps on do_baz Aug 06 17:49:56 we don't want to run do_baz twice Aug 06 17:50:46 right Aug 06 17:50:53 it's just a depth first traversal that doesn't hit the same node more than once Aug 06 17:51:00 deps are prolly a list of strings Aug 06 17:51:06 yeah Aug 06 17:51:08 which are iterated in that for loop Aug 06 17:51:13 and recursed Aug 06 17:51:15 yup Aug 06 17:52:00 and then do_install and do_stage are run after all task and deps are done Aug 06 17:52:16 no, do_install is the start of the traversal Aug 06 17:52:30 do_stage is run manually afterward Aug 06 17:52:52 I see so newtask = "do_populate_sysroot" mergedtasks = gather_taskdeps(newtask) Aug 06 17:53:01 calculated all deps of do_populate_sysroot Aug 06 17:53:10 mergedtasks.pop() Aug 06 17:53:16 pops the last task out Aug 06 17:53:20 which is do_populate_sysroot Aug 06 17:53:29 and then we redefine that task Aug 06 17:53:38 as superset of all Aug 06 17:53:49 exactly. and we ensure that anything that deps on anything in that list now deps on populate_ssysroot directly Aug 06 17:54:07 yeah Aug 06 17:54:18 ok ok Aug 06 17:54:56 hmmm Aug 06 17:55:01 * kergoth_ reads code again Aug 06 17:55:21 what are recrdeptask recdeptask and deptask Aug 06 17:56:06 those are how you make one task depend on a task of your DEPENDS or RDEPENDS, recursively or not Aug 06 17:56:12 deps = d.getVarFlag(task, "deps") does it return true or false or a list of strings Aug 06 17:56:20 that returns a list of strings Aug 06 17:56:43 i don't remember why it's handling the deptask things that way Aug 06 17:57:17 note: it doesn't explicitly empty the do_populate_sysroot 'deps', it just happens that it's one of the tasks in the 'for task in' iteration Aug 06 17:57:19 as far as i can tell Aug 06 17:57:40 but the end result is the same, the new task drops the deps it used to have Aug 06 17:58:19 I'm thinking we do s.setVar() the d.getVarFlag(newtask, "deps"), and use that instead of do_install in the new task Aug 06 17:58:26 hmm for task in (key for key in d.keys() Aug 06 17:58:29 before the task iteration in merge_tasks Aug 06 17:58:40 it gets all tasks that exist, other than the ones in the mergetasks Aug 06 18:00:35 right Aug 06 18:00:53 are tasks prefixed with recipe names Aug 06 18:00:57 i think it should probably modify the deptask flags too, i wonder why it doesnt Aug 06 18:01:19 only the 'depends' flag explicitly deps on another recipe's task Aug 06 18:01:24 it's format is recipe:task Aug 06 18:01:39 the others are just lists of tasks, 'deps' an actual list, the others are space separated strings Aug 06 18:03:07 ok local tasks to recipes are names as it is ? Aug 06 18:03:13 e.g. do_compiler etc. Aug 06 18:03:30 but if I have DEPENDS="foo" Aug 06 18:03:45 then it will also show foo.bb:do_compile in deplist Aug 06 18:04:04 pretty sure 'deps' is only local tasks Aug 06 18:04:10 foo.bb:do_compile is done internally by bitbake Aug 06 18:04:16 i think.. Aug 06 18:04:43 DEPENDS = "foo" essentially is the same as do_configure[depends] += "foo:do_populate_staging" Aug 06 18:04:46 same for do_compijle Aug 06 18:04:51 of course its more complex than that due to PROVIDES Aug 06 18:05:02 right Aug 06 18:05:19 ah, right, there it is Aug 06 18:05:30 base.bbclass, do_configure[deptask] = "do_populate_staging" Aug 06 18:05:49 its bitbake that handles the provides and figures out exactly which recipes configure will need do_populate_staging run on Aug 06 18:06:04 i see Aug 06 18:06:29 for task in (key for key in d.keys() Aug 06 18:06:43 itrates over all global tasks right ? Aug 06 18:06:59 d.keys lists all variables Aug 06 18:07:12 the getVarFlag on that of 'task' ensures its a task Aug 06 18:08:08 got it Aug 06 18:11:04 hmm so recrdeptask recdeptask deptask are spared Aug 06 18:11:42 others are removed from depchain Aug 06 18:12:08 I'm thinking it should change those too, I'm not sure why it doesn't Aug 06 18:12:19 hmm Aug 06 18:12:24 * kergoth_ doesn't remember Aug 06 18:12:29 and added to the mega task list ok Aug 06 18:12:43 i woudl think that if something has, say, configure as a deptask, we'd want it to now deptask on populate_sysroot instead Aug 06 18:12:49 * kergoth_ shrugs Aug 06 18:12:51 yeah it should have broken them down Aug 06 18:12:52 too Aug 06 18:12:54 maybe there was a recursion issue Aug 06 18:14:08 if we dont plug them to the mega task then that depchain will be broken isnt it Aug 06 18:14:36 i would think so, yeah, it could end up running the merged tasks outside of do_populate_sysroot, if another recipe wanted it Aug 06 18:14:47 which sounds like a problem to me Aug 06 18:14:54 * khem nods Aug 06 18:15:21 actually every task in mergedtask should lose its outside connection Aug 06 18:15:47 and those links should be redirected to mega task Aug 06 18:15:58 oh, shit Aug 06 18:16:00 I see the problem Aug 06 18:16:05 you said recursion Aug 06 18:16:07 khem, only the one recipe inherits srctree Aug 06 18:16:14 not the recipes that depend on its tasks Aug 06 18:16:18 so it can't fix those others Aug 06 18:16:31 and the deptasks set in this recipe are upon other recipes, which aren't a factor unless those other recipes inherit srctree Aug 06 18:16:33 see the problem? Aug 06 18:16:42 I expect I never got around to trying to do anything about it Aug 06 18:16:44 yes Aug 06 18:17:08 you'd have to like store in persist_data which recipes use srctree and have base.bbclass or something adjust the other recipes based on it Aug 06 18:17:11 * kergoth_ rolls eyes Aug 06 18:17:15 that's ugly :) Aug 06 18:17:31 I hate state machines Aug 06 18:17:32 of course, most cross recipe deps aren't going to ever dep on the merged tasks Aug 06 18:17:34 if you think about it Aug 06 18:17:38 because they can't touch those things anyway Aug 06 18:17:47 they want the output from that recipe, which would be staging or packaging Aug 06 18:18:00 so maybe its a nonissue Aug 06 18:18:17 yeah conceptually this mega tasking should be done on global scope Aug 06 18:19:00 part of it, anyway. you'd need to globally set which recipes opt into it, so it can adjust all *other* recipes that dep or rdep on those Aug 06 18:19:10 but again i doubt its an issue Aug 06 18:19:15 no recipe is going to deptask on do_configure Aug 06 18:19:17 but they may depend on some Aug 06 18:19:19 it can't touch that other recipe's WORKDIR Aug 06 18:19:22 like someone was asking this morning Aug 06 18:19:31 about adding dependencies on a task Aug 06 18:21:59 yeah usually they should deptaks on populate_sysroot I guess Aug 06 18:22:03 or further than that Aug 06 18:22:22 right, something that involves deployment outside of the workdir Aug 06 18:22:29 true Aug 06 18:23:18 and if its not on a mergetask, this isn't an issue. course, we could add a check for it somehow.. error out if you try to exec one of those tasks outside of the context of the rec_exec_task.. set a var or flag and check in an event handler or something Aug 06 18:23:31 but that could have a performance impact Aug 06 18:24:21 deptask lists the tasks a given task depends on right Aug 06 18:24:37 in the recipes in your DEPENDS, yeah Aug 06 18:24:40 at build time Aug 06 18:24:51 rdeptask is RDEPENDS, iirc, and recrdeptask is both DEPENDS+RDEPENDS, recursively Aug 06 18:25:03 something like that, anyway.. Aug 06 18:26:14 gm Aug 06 18:26:32 kergoth: DEPENDS + REDEPENDS have to explicitly mentioned Aug 06 18:26:38 or is there a unified way Aug 06 18:26:46 not sure what you mean Aug 06 18:26:58 oh, for them both not recursively? Aug 06 18:27:03 i don't remember, check the bitbake code :) Aug 06 18:27:11 I want to know what ends up in recrdeptask Aug 06 18:27:27 recrdeptask tends to be used for things like do_fetchall Aug 06 18:27:37 ok Aug 06 18:27:38 to ensure we fetch all the way down the line, for everything Aug 06 18:27:51 now, a non-recr would work too, because that's inherited by all recipes Aug 06 18:28:05 but with recr you could inherit a class in one recipe, and recursively dep on something all the way down the line Aug 06 18:28:13 for that task from that recipe alone Aug 06 18:28:22 hi likewise Aug 06 18:28:50 ah recr = recursive Aug 06 18:29:07 Just moved to Ubuntu 10.04, and I have a regression where gconf configure stage says it misses polkit-dbus. What recipes provides that? policykit-gnome depends on gconf (->circular dependency) Aug 06 18:29:21 i'm n ot sure if its rec .. rdeptask, or recr .. deptask :) Aug 06 18:29:38 kergoth: some reports I see says tha problem with DEPENDS and srctree Aug 06 18:29:55 my guess is rdeptask is both DEPENDS and RDEPENDS, and recrdeptask is 'rec' for recursive, deptask Aug 06 18:29:59 it started the megatask before the dependecies were sysrooted Aug 06 18:30:00 but i'd have to double check the code Aug 06 18:30:27 hmm Aug 06 18:30:29 kergoth: usually DEPENDS should also mean RDEPEND Aug 06 18:30:46 it needs to pick up the deptask/rdeptask/recrdeptask of the mergetasks and pull them over into do_populate_sysroot Aug 06 18:30:56 to ensure it gets the do_populate_staging deptask from do_configure Aug 06 18:31:20 so that check should go Aug 06 18:31:23 if its not doing that now, it needs to Aug 06 18:31:31 if mergetask in (d.getVarFlag(task, "recrdeptask"), Aug 06 18:31:32 d.getVarFlag(task, "recdeptask"), Aug 06 18:31:32 d.getVarFlag(task, "deptask")): Aug 06 18:31:32 continue Aug 06 18:31:37 oops Aug 06 18:31:46 no, that's for things that deptask *on* the mergetasks Aug 06 18:31:56 we need the deptasks *from* the mergetasks on *other* tasks Aug 06 18:31:59 which aren't in the mergetasks Aug 06 18:32:14 those need to be copied over to the new task Aug 06 18:32:15 right Aug 06 18:32:30 we should calls DEPENDERS and DEPENDEES Aug 06 18:32:32 eh Aug 06 18:32:59 we already iterate over mergetasks on line 78 of srctree Aug 06 18:33:21 just add some code there to check for the deptask flags and pull them over Aug 06 18:33:46 we try to pull cross recipe task deps over, but we only get depends, not *deptask Aug 06 18:33:47 heh Aug 06 18:33:57 hmm that loop should reconnect the deps right Aug 06 18:34:25 the loop on line 78 just kills the deltasks from the mergedtasks Aug 06 18:34:54 thats what I should have meant Aug 06 18:35:34 next loop does that Aug 06 18:38:27 kergoth_: can we just replicate the loop at line 86 Aug 06 18:44:34 kergoth_: something like this http://pastebin.com/r3AGhaXa Aug 06 18:44:39 ? Aug 06 18:49:03 03Frans Meulenbroeks  07org.openembedded.dev * r04cb7fb374 10openembedded.git/recipes/python/ (python-docutils-native_0.5.bb python-docutils_0.5.bb): Aug 06 18:49:03 python-docutils: removed legacy staging, converted to BBCLASSEXTEND Aug 06 18:49:03 Signed-off-by: Frans Meulenbroeks Aug 06 18:52:44 khem, s/depends/deptask/ on the last line added, but yeah, that'd do it. I'd suggest consolidating it into a single loop rather than using multiple generators though :) Aug 06 18:56:55 I already did :) Aug 06 18:57:00 oh Aug 06 18:57:30 normally when running configure, should ../../../../sysroots/i686-linux/usr/bin/armv7a-angstrom-linux-gnueabi that be in my search path Aug 06 18:58:23 libxslt breaks for me, in QA, not sure how it could work for anyone, but it picks up the wrong xml2-config Aug 06 19:00:12 kergoth_: Aug 06 19:00:18 http://pastebin.com/DzfcHUVK Aug 06 19:00:56 wait Aug 06 19:01:09 why are people adding NATIVE_INSTALL_WORKS = "1" when they remove the legacy do_stage() function? afais, NATIVE_INSTALL_WORKS is used only to check wether legacy staging is in use Aug 06 19:01:38 khem, that's a generator that returns a bunch of tuples, deptask will be None. You'd have to gather up the items from the tuples first :) Aug 06 19:02:50 khem, I'm wondering if I am picking up some spillover from the dir structure changes for cross Aug 06 19:03:00 my path within configure starts with Aug 06 19:03:00 /home/frans/oe/tmp_angstrom/sysroots/i686-linux/usr/armv7a/bin:/home/frans/oe/tmp_angstrom/sysroots/i686-linux/usr/sbin:/home/frans/oe/tmp_angstrom/sysroots/i686-linux/usr/bin Aug 06 19:03:21 I want to run xml2-config Aug 06 19:03:25 that one lives in ../../../../sysroots/i686-linux/usr/bin/xml2-config Aug 06 19:03:26 ../../../../sysroots/i686-linux/usr/bin/armv7a-angstrom-linux-gnueabi/xml2-config Aug 06 19:03:45 and I am picking up the 1st one, but would have expected to pick up the 2nd one Aug 06 19:03:55 frist one gives native results Aug 06 19:05:04 should sysroots/i686-linux/usr/armv7a/bin be sysroots/i686-linux/usr/bin/armv7a-angstrom-linux-gnueabi ?? Aug 06 19:05:55 or is xml2-config installed in the wrong place ?? Aug 06 19:06:17 kergoth_: how does this look like http://pastebin.com/kFeaXPaD Aug 06 19:07:30 khem, you'll only get the last of the mergedtasks doing that Aug 06 19:07:54 will need to create depends and deptask lists before the loop and append the strings of each mergedtask to it Aug 06 19:07:57 then join that Aug 06 19:08:44 ah, think it is indeed due th the dir changes, the dir with arm7a in it has files dated aug1, the one with *abi has files from aug5 Aug 06 19:08:52 seems it is time tor rm -rf tmp again Aug 06 19:11:05 kergoth: I tried a,b = (c,d) Aug 06 19:11:07 did not work Aug 06 19:12:37 btw should bitbake -cclean remove files in sysroots/armv7a-angstrom-linux-gnueabi/usr/lib/pkgconfig ? Aug 06 19:12:46 apparently that does not happen Aug 06 19:12:54 not sure if this is an error or desire Aug 06 19:12:56 d Aug 06 19:16:51 kergoth_: how about this http://pastebin.com/dj9nKMiq Aug 06 19:17:42 eFfeM: I think it cleans up the the stuff whcih is in FILES Aug 06 19:17:44 eFfeM: depends on pstaging and/or not legacy staging, iirc Aug 06 19:20:35 it is a .pc file, I expected somewhat pstaging to remove it, not sure if pstaging is limited to FILES only Aug 06 19:21:05 if that is I would propose that RPs new version allows a meta package or so that also contains that stuff Aug 06 19:22:38 kergoth: I just sent another patch from Cliff thats needed in bitbake to get srctree working in OE Aug 06 19:22:40 pstaging isn't limited to anything Aug 06 19:23:02 But if you don't have pstaging, no, -c clean might not clean out sysroot stuff Aug 06 19:25:50 Tartarus: i am fairly sure I have pstaging Aug 06 19:26:38 checked, yes Aug 06 19:28:20 hm, it is listed Aug 06 19:28:25 need to sort this out later Aug 06 19:31:31 is this ok: Aug 06 19:31:33 NOTE: the following files were installed but not shipped in any package: Aug 06 19:31:33 NOTE: /usr/lib/libexslt.a Aug 06 19:31:33 NOTE: /usr/lib/xsltConf.sh Aug 06 19:31:33 NOTE: /usr/lib/libxslt.a Aug 06 19:31:33 NOTE: Multiple libraries (libexslt.so.0, libxslt.so.1) found and LEAD_SONAME not defined Aug 06 19:31:41 ? Aug 06 19:42:58 03Frans Meulenbroeks  07org.openembedded.dev * r063cff0e71 10openembedded.git/recipes/yasm/ (yasm-native_0.7.2.bb yasm.inc yasm_0.7.2.bb): Aug 06 19:42:58 yasm, migrate to BBCLASSEXTEND = "native" Aug 06 19:42:58 Signed-off-by: Frans Meulenbroeks Aug 06 20:08:08 how can I trace an m4 call invoked by autotools ? or add a debug stmt? I'm an m4 n00b Aug 06 20:10:51 eFfeM: they are shell scripts Aug 06 20:26:59 khem they indeed looked like shell scripts to me, but an echo statement in it did not reveal any results Aug 06 20:27:18 btw and apologies for the slow reply, missed your msg Aug 06 20:28:59 actually this test was in patch, and it builds nicely without the patch, but I end up iwth some RPATH QA issues like Aug 06 20:29:00 ERROR: QA Issue with libftdi: package libftdi contains bad RPATH /home/frans/oe/tmp_angstrom/work/armv7a-angstrom-linux-gnueabi/libftdi-0.18-r0/libftdi-0.18/src/.libs:/home/frans/oe/tmp_angstrom/sysroots/armv7a-angstrom-linux-gnueabi/usr/lib in file /home/frans/oe/tmp_angstrom/work/armv7a-angstrom-linux-gnueabi/libftdi-0.18-r0/packages-split/libftdi/usr/bin/bitbang Aug 06 20:29:06 any hint how to fix this? Aug 06 20:33:36 bad libtool files Aug 06 20:33:49 is this a new recipe Aug 06 20:33:53 yeah was seeing of OE_LT_RPATH_ALLOW would help Aug 06 20:34:44 khem, yeah had problems with autoconf for libftdi 0.13, upstream is already at 0.;18 so decided to see if I could move the recipe fwd Aug 06 20:34:58 seems not, feel kinda stuck Aug 06 20:35:15 lemme see what .13 looks like Aug 06 20:35:59 --disable-rpath Aug 06 20:36:03 interesting Aug 06 20:36:21 can you try to build .13? for me it fails in the AC_LIB_LINKFLAGS_FROM_LIBS check which is added to it in autotools.patch Aug 06 20:36:35 and 0.18 configure does not seem to have a --disable-rpath Aug 06 20:36:53 I think you need to port the autotools patch to 2.65 Aug 06 20:36:54 that would be too easy ;-) Aug 06 20:36:55 macros Aug 06 20:38:10 I have a build in progress Aug 06 20:38:16 so cant try right away Aug 06 20:38:21 cool! thanks! Aug 06 20:38:21 but will do once its done Aug 06 20:38:30 great Aug 06 20:38:40 * khem reinstalled his box last night Aug 06 20:38:47 will probably be gone in half an hour (bedtime here ) Aug 06 20:38:56 yeah sure Aug 06 20:39:07 if you are lucky I might fix it for you Aug 06 20:39:13 :-) Aug 06 20:39:17 but I have to find time Aug 06 20:39:19 * eFfeM crosses figners Aug 06 20:39:50 btw the only reason there is a libftdi native recipe is because there is an openocd native recipe Aug 06 20:40:07 on which no-one depends Aug 06 20:40:19 then delete both Aug 06 20:40:27 yeah thought so Aug 06 20:40:39 we can reintroduce stuff if needed Aug 06 20:40:45 but was not sure if there was a good reason to have openocd-native Aug 06 20:40:50 but as in this state its very hard to do any change Aug 06 20:40:50 for debugging or so Aug 06 20:41:42 We need to get rid of as much as we can from native recipes Aug 06 20:41:45 and do_stage Aug 06 20:42:18 KDE ate more resources on this build box Aug 06 20:42:30 so thought og putting no gui Aug 06 20:42:34 and just console Aug 06 20:42:37 and ssh Aug 06 20:42:42 khem this might help for my problem Aug 06 20:42:44 http://tinderbox.openembedded.net/builds/81504/ Aug 06 20:42:48 my log Aug 06 20:43:21 and yeah, I've been removing some old stuff, expected some flames for it, they didn't come Aug 06 20:43:29 but i also feel there is too much old stuff Aug 06 20:43:29 eFfeM: someone was tellng me about that mobile beer bar in amsterdam Aug 06 20:43:41 where you have to keep pedalling Aug 06 20:43:52 One day I want to sit in that :) Aug 06 20:44:26 and referred-om-2008-versions.inc pins lots of old versions Aug 06 20:44:38 khem, I've heard of it but never saw it Aug 06 20:44:46 would like to join you to try it out Aug 06 20:44:50 heh Aug 06 20:45:05 oe beer cycling party :-) Aug 06 20:47:19 nice Aug 06 20:47:42 likewise: I have gconf in my assume provided so never hit that issue Aug 06 20:47:48 let;s retire some abiword recipes Aug 06 20:47:52 03Frans Meulenbroeks  07org.openembedded.dev * r52ad126ffb 10openembedded.git/recipes/abiword/ (11 files): Aug 06 20:47:52 abiword: deleted some old versions Aug 06 20:47:52 Signed-off-by: Frans Meulenbroeks Aug 06 20:52:25 03Frans Meulenbroeks  07org.openembedded.dev * rde000ab0b0 10openembedded.git/recipes/m4/ (4 files): Aug 06 20:52:25 m4: removed 1.4.4 and 1.4.11 (old, unused) Aug 06 20:52:25 Signed-off-by: Frans Meulenbroeks Aug 06 20:57:07 03Frans Meulenbroeks  07org.openembedded.dev * r9c006b4773 10openembedded.git/recipes/apt/ (9 files in 4 dirs): Aug 06 20:57:07 apt: removed some very old versions Aug 06 20:57:07 Signed-off-by: Frans Meulenbroeks Aug 06 20:59:05 03Frans Meulenbroeks  07org.openembedded.dev * r62e62a4ac3 10openembedded.git/recipes/openssl/ (24 files in 4 dirs): Aug 06 20:59:05 openssl: removed old 0.9.7 versions Aug 06 20:59:06 Signed-off-by: Frans Meulenbroeks Aug 06 21:01:49 03Frans Meulenbroeks  07org.openembedded.dev * r4b85c8ee27 10openembedded.git/recipes/python/ (python-pygobject-native_2.14.2.bb python-pygobject_2.14.2.bb): Aug 06 21:01:49 python-pygobject[-native]: removed old 2.14.2 version Aug 06 21:01:49 Signed-off-by: Frans Meulenbroeks Aug 06 21:02:31 03Frans Meulenbroeks  07org.openembedded.dev * rb719101051 10openembedded.git/recipes/python/ (python-cython-native_0.10.3.bb python-cython_0.10.3.bb): Aug 06 21:02:32 python-cython[-native] removed 0.10.3 Aug 06 21:02:32 Signed-off-by: Frans Meulenbroeks Aug 06 21:07:43 03Frans Meulenbroeks  07org.openembedded.dev * r388edab9cd 10openembedded.git/recipes/sip/ (sip-native_4.7.3.bb sip-native_4.7.7.bb): Aug 06 21:07:43 sip-native: removed a few old versions Aug 06 21:07:43 Signed-off-by: Frans Meulenbroeks Aug 06 21:09:35 03Frans Meulenbroeks  07org.openembedded.dev * rfaa3aebaee 10openembedded.git/recipes/apt/ (4 files in 2 dirs): Aug 06 21:09:35 apt: removed 0.7.2 Aug 06 21:09:35 Signed-off-by: Frans Meulenbroeks Aug 06 21:12:48 ok, calling it a day for now Aug 06 21:13:00 good night eFfeM Aug 06 21:13:02 khem, will stay in the channel, feel free to leave a msg if you make progress Aug 06 21:13:24 khem, ty & have a nice day Aug 06 21:27:39 Hi. For an omapevm machine, I get STAGING_LIBDIR=$home/oe/arago-tmp/sysroots/armv7a-none-linux-gnueabi/usr/lib , but HOST_SYS=arm-none-linux-gnueabi. Where does the "arm7a" come from? Aug 06 21:42:47 I'm using ${PKG_CONFIG_SYSROOT_DIR} so I can add .../lib to link flags in addition to the STAGING_LIBDIR .../usr/lib, but using PKG_CONFIG seems not quite right Aug 06 21:43:13 jo Aug 06 21:44:53 woglinde: hello Aug 06 21:45:04 woglinde: whats the latest with maemo (meego?) in OE ? Aug 06 21:45:34 rkirti nothing you didnt merge Aug 06 21:45:42 we had no time Aug 06 21:46:17 woglinde: ok Aug 06 21:56:07 for the current arago project - is there a site that has any pointers to move the kernel to a different location in memory? Aug 06 22:08:16 03Henning Heinold  07org.openembedded.dev * r1c65f9b607 10openembedded.git/recipes/openjdk/openjdk-6-6b18-1.8/icedtea-jdk-remove-unused-backtrace.patch: openjdk: update the unused-backtrace-patch for uclibc Aug 06 23:12:07 ah ha! Aug 06 23:12:09 gotcha Aug 06 23:12:26 * kergoth_ finally nails down an annoying bug that he should have figured out sooner Aug 06 23:15:14 kergoth what is it? Aug 06 23:15:36 if you do something like.. do_patch[depends] += "quilt-native:do_foo" Aug 06 23:15:45 and do_foo doesn't exist, bitbake dies with an IndexError Aug 06 23:16:13 hm yes Aug 06 23:16:18 * kergoth_ fixes Aug 06 23:16:28 there was soemthing Aug 06 23:17:37 *sigh* Aug 06 23:17:39 NOTE: multiple providers are available for runtime ncurses (ncurses, ncurses-sdk) Aug 06 23:17:39 NOTE: consider defining a PREFERRED_PROVIDER entry to match ncurses Aug 06 23:55:13 khem: thanks (about mentioning gconf in your assume provided). Is that for native? My issue is with target, and I wonder why you set it assume provided? Aug 07 02:22:13 hi Aug 07 02:22:24 I am running OE build Aug 07 02:22:29 using oe.org Aug 07 02:22:31 err Aug 07 02:22:33 oe.dev.org Aug 07 02:22:38 or oe.dev.org Aug 07 02:22:43 damnit, I cant type Aug 07 02:23:03 anyway, it says stuff like "Angstrom DOES NOT support bluez-libs" etc Aug 07 02:23:06 is that ok? **** ENDING LOGGING AT Sat Aug 07 02:59:57 2010