**** BEGIN LOGGING AT Wed Feb 23 02:59:56 2011 Feb 23 04:46:07 otavio, libcap2-2.16-r3 builds for me with angstrom armv7a - maybe a week old OE? Feb 23 09:00:39 morning all Feb 23 09:02:27 * ka6sox checks to see if hh.org is still saying next week. Feb 23 09:02:50 yup...but who knows. Feb 23 09:09:29 03Koen Kooi  07org.openembedded.dev * r09e23d0946 10openembedded.git/recipes/ (2 files in 2 dirs): Feb 23 09:09:29 beagleboard NAND image: new image and matching task Feb 23 09:09:29 Signed-off-by: Koen Kooi Feb 23 09:09:39 03Koen Kooi  07org.openembedded.dev * rd6729be1fd 10openembedded.git/recipes/efl1/evas.inc: Feb 23 09:09:40 evas: disable NEON forcefully, it is still causing misrendering when enabled Feb 23 09:09:40 Upstream changed the default for NEON from disabled to enabled, so the recipe has to catch up Feb 23 09:09:40 Tested with angstrom 2008.1 on a beagleboard C4 Feb 23 09:09:40 Signed-off-by: Koen Kooi Feb 23 09:14:21 ka6sox: I'm not holding my breath personally :) Feb 23 09:26:09 bluelightning, me neither. Feb 23 09:56:32 morning Feb 23 10:04:19 good morning Feb 23 10:06:14 hi marco Feb 23 10:07:07 moin woglinde Feb 23 11:44:44 hm found another bugger Feb 23 11:44:52 fakeroot-native depends on util-linux Feb 23 12:17:18 GNUtoo|laptop: hello Feb 23 12:18:02 hi Feb 23 12:29:49 03Simon Busch  07org.openembedded.dev * r39899b7df9 10openembedded.git/recipes/e17/elfe_svn.bb: Feb 23 12:29:49 elfe: add initial recipe for new embedded e17 launcher Feb 23 12:29:49 Signed-off-by: Simon Busch Feb 23 12:29:57 GNUtoo|laptop: have you got libcap2 building? Feb 23 12:30:04 03Simon Busch  07org.openembedded.dev * r5f669e0ca5 10openembedded.git/recipes/e17/ (13 files): Feb 23 12:30:04 e-module: introduce INC_PR and use it in all depending recipes Feb 23 12:30:04 We set INC_PR initially to r5 as some of the dependencies already defined a PR which max Feb 23 12:30:04 was r4. Feb 23 12:30:04 Signed-off-by: Simon Busch Feb 23 12:30:04 Acked-by: Martin.Jansa Feb 23 12:30:23 otavio, no, I skipped that Feb 23 12:30:31 GNUtoo|laptop: how you did? Feb 23 12:30:56 nothing, just bitbake -k Feb 23 12:31:00 and bitbake package-index Feb 23 12:31:06 and opkg update;opkg upgrade Feb 23 12:31:14 so it still doesn't build Feb 23 12:31:29 I must look at the irc logs Feb 23 12:31:40 GNUtoo|laptop: right; I will check about updating it to 2.20 Feb 23 12:32:10 ok Feb 23 12:32:13 thanks a lot Feb 23 12:33:07 GNUtoo|laptop: I will do that and post a new patchset. Feb 23 12:33:27 GNUtoo|laptop: then can you pick the ones you think are OK and push? Feb 23 12:33:42 you do not have commit access? Feb 23 12:33:44 or is it core? Feb 23 12:34:58 GNUtoo|laptop: I have but I don't have my regular machine up yet; it had hw issues Feb 23 12:35:06 GNUtoo|laptop: and some are core too Feb 23 12:35:11 ok Feb 23 12:35:38 I'll look if I've the time Feb 23 12:36:12 GNUtoo|laptop: nice and thx Feb 23 12:36:56 if I've no time maybe someone else would pick up the patches Feb 23 12:59:12 GNUtoo|laptop: OK; I got it done. I will send the patches to mailing list Feb 23 12:59:30 ok Feb 23 12:59:47 does it build with the libcap2 patch? Feb 23 13:06:01 GNUtoo|laptop: it requires few changes on it but most the same Feb 23 13:06:29 ok Feb 23 13:08:43 GNUtoo|laptop: sending them all right now... done. Feb 23 13:08:54 ok Feb 23 13:09:02 I'll look for the libcap2 Feb 23 13:14:00 GNUtoo|laptop: in case you have time/motivation, please push others that you think are OK :-) Feb 23 13:16:07 I've some important stuff to send to oe Feb 23 13:16:14 oe is un-debugable Feb 23 13:16:22 on target Feb 23 13:16:25 GNUtoo|laptop: yes, indeed. Feb 23 13:16:28 or trough gdbserver Feb 23 13:16:34 because we don't use -g Feb 23 13:16:40 GNUtoo|laptop: serious indeed. Feb 23 13:16:45 but....we use -g for host stuff Feb 23 13:16:49 which is non-sense Feb 23 13:16:52 heh Feb 23 13:18:58 GNUtoo|laptop: you can select debuggable packages if you want, see local.conf.sample Feb 23 13:19:16 pb_, yes but why not set it by default? Feb 23 13:19:18 -g is enabled by default on the host because it doesn't really cost anything to do so Feb 23 13:19:26 ah ok Feb 23 13:19:46 GNUtoo|laptop: that's a DISTRO choice. you are welcome to enable it by default for your own distro if you want. Feb 23 13:20:18 you can install debug packages on the target Feb 23 13:20:28 enabling -g by default would be fairly harmless, but for best debuggability you also need to build with low optimization (e.g. -O0 or -O1 rather than -O2/-Os) Feb 23 13:20:32 Crofton|work, which don't work without -g Feb 23 13:20:38 the is an image feature to include all of them, but make sure you have a lot of flash :) Feb 23 13:20:54 GNUtoo|laptop, what distro are yuo using? Feb 23 13:21:28 SHR and Angstrom Feb 23 13:21:39 03Koen Kooi  07org.openembedded.dev * r9aa487897f 10openembedded.git/recipes/e17/elfe_svn.bb: (log message trimmed) Feb 23 13:21:39 elfe: add elementary to DEPENDS Feb 23 13:21:39 | checking for E... configure: error: Package requirements (enlightenment Feb 23 13:21:39 | elementary Feb 23 13:21:39 | efreet >= 1.0.0 Feb 23 13:21:39 | ) were not met: Feb 23 13:21:40 | Feb 23 13:21:40 I need debugging mostly for SHR Feb 23 13:22:05 basically I debug like that Feb 23 13:22:09 opkg install foo-dbg Feb 23 13:22:22 gdbserver ip:port foo Feb 23 13:22:34 cross-oe-gdb Feb 23 13:22:49 set sysroot /path/to/sshfs/mounted/root Feb 23 13:23:03 file /path/to/sshfs/mounted/root/usr/bin/foo Feb 23 13:23:06 target remote ... Feb 23 13:23:11 etc... Feb 23 13:23:18 so that doesn't work when -g is not passed Feb 23 13:23:24 but I'll add debugging in local.conf Feb 23 13:23:32 DEBUG_BUILD = "1" Feb 23 13:24:15 hm right angstorem builds per default with -ggdb3 Feb 23 13:24:25 ok Feb 23 13:24:39 JaMa, what do you think ^^^ Feb 23 13:25:15 do we include DEBUG_BUILD in local.conf or do we add -g by default Feb 23 13:25:28 woglinde: I think they gave that up in the end Feb 23 13:25:54 iirc, angstrom has a slightly more sensible debug level now, plain -ggdb or something Feb 23 13:26:19 it'd probably be a fine idea for SHR to do the same thing Feb 23 13:37:09 kenny, welches cando muß man nehmen? ICh hab 1.0.0-rc6 aus dem master branch Feb 23 13:37:38 oups... Feb 23 13:37:55 *g* Feb 23 13:38:01 day of wrong windows Feb 23 13:41:15 woglinde: the few people who still have a job, work too much :-D Feb 23 13:41:39 mckoan o,O? Feb 23 13:41:41 year of wrong Windows Feb 23 13:42:02 woglinde: so become tired and do mistakes Feb 23 13:42:12 mckoan on our univeristy job mailinglist I see nearly 5 job offers every week Feb 23 13:45:25 Jay7: if you have Windows your entire life is wrong, LOL Feb 23 13:47:49 s/Windows/Microsoft Windows/? Feb 23 13:53:24 GNUtoo|laptop: sure :) Feb 23 13:53:52 because, if you're crazy enough you could understand it differently Feb 23 13:54:03 su as: use the shell Feb 23 13:54:39 I still use gnome, because of notifications Feb 23 13:54:49 xchat notifications etc... Feb 23 13:55:34 and the fact that titled manager didn't integrate well with network manager and such stuff Feb 23 14:26:25 03Koen Kooi  07org.openembedded.dev * re7adc925c1 10openembedded.git/recipes/linux-firmware/linux-firmware_git.bb: Feb 23 14:26:25 linux-firmware: update to current git and split out the wl12xx stuff that was added in between Feb 23 14:26:25 Signed-off-by: Koen Kooi Feb 23 14:33:12 hey, how can i use bitbake to build for mutliple archs? do i just make another directory? Feb 23 14:33:16 and build in there? Feb 23 14:33:16 GNUtoo|laptop: I have DEBUG_BUILD in local.conf, but -g should be passed in sane-toolchain.inc (as discussed last time) Feb 23 14:33:47 JaMa, ok Feb 23 14:34:08 JaMa, could you take care of writing a mail for that? Feb 23 14:37:37 or is there away to tell bitbake to use a different "local.conf" fil Feb 23 14:38:29 GNUtoo|laptop: not today, but yes Feb 23 14:39:04 ok thanks a lot Feb 23 14:41:04 gandhijee: just change your MACHINE and build again Feb 23 14:41:12 03Martin Jansa  07master * r17f3253e28 10openembedded.git/recipes/linux/ (3 files in 3 dirs): Feb 23 14:41:12 linux-2.6.37: upgrade to 2.6.37.1 Feb 23 14:41:12 * update om-gta0* defconfigs like Feb 23 14:41:12 8e4bd2fd4cbf1c75acd30adbd3aaa074c3175a3e and Feb 23 14:41:12 1516588acd3c4b4dd4add71d06ab8ce0d1bafa02 Feb 23 14:41:12 Signed-off-by: Martin Jansa Feb 23 14:41:14 bb is careful about multiple arches Feb 23 14:41:53 or you may look to oebb.sh script used by Angstrom developers Feb 23 14:42:51 Jay7: where can i find this oebb.sh script? Feb 23 14:43:28 check angstrom-distribution.org for links or manual Feb 23 14:47:43 k, thanks Feb 23 15:01:59 is anybody having trouble building freetype? Feb 23 15:02:16 I am getting a file not recognized: File format not recognized error Feb 23 15:02:21 during oe_runmake Feb 23 15:06:06 has anyone built the intel IEGD against any of the angstrom kernels? Feb 23 15:17:30 here is the freetype build output Feb 23 15:17:31 http://pastebin.com/ssK3yQte Feb 23 15:38:29 hm Feb 23 15:38:54 So, for some reason it's trying to use host libz not target Feb 23 15:41:30 yeah Feb 23 15:41:38 i don't quite understand what it is doing Feb 23 15:42:54 it built find monday - I have been looking through the changelog and don't see anything obvious Feb 23 15:43:33 (2008.1, btw) Feb 23 15:47:12 03Koen Kooi  07org.openembedded.dev * r8e91c85042 10openembedded.git/recipes/qcanobserver/ (4 files in 2 dirs): Feb 23 15:47:12 qcanobserver: add svnr41 + socketcan driver Feb 23 15:47:12 Signed-off-by: Koen Kooi Feb 23 16:25:04 I'm having trouble compiling xproto. Compile log here: http://oe.pastebin.com/KLDgbfZv Feb 23 16:26:08 I have tried some internet advices like manually running xmlto and setting LANG="C" Feb 23 16:26:52 Manually running xmlto produces another error (can't recall exactly what) and LANG="C" did not seem to make a difference Feb 23 16:34:52 It seems like you can use fop instead of xmlto, but fop has a lot of other dependencies that I don't really want Feb 23 16:48:59 Do I need xproto specs? Feb 23 16:53:35 anyone looked at switching OE dependency from chrpath to patchelf? Feb 23 17:08:38 jkridner: yes I have Feb 23 17:09:25 khem: great! Feb 23 17:09:43 I've found that patchelf builds just fine on a Mac Pro, whereas chrpath does not.... Feb 23 17:09:51 jkridner: yes Feb 23 17:09:57 I was considering just making a shell script for chrpath that simply calls patchelf.... Feb 23 17:09:59 ooh, patchelf can handle growing the path? Feb 23 17:10:00 slick Feb 23 17:10:13 jkridner: btw. are you able to use mac buildhost at all for oe Feb 23 17:10:26 but, if you have an OE patch, that would be cool. Feb 23 17:10:50 I remember having added recipe for patchelf Feb 23 17:10:50 khem: I used to get a fair amount of stuff to build, but I decided to start again from scratch and document my steps. Feb 23 17:11:02 that would be nice Feb 23 17:11:10 I use Gentoo Prefix to get me a baseline. Feb 23 17:11:35 My old Gentoo Prefix was getting a bit stale, so I started a new one. Feb 23 17:11:53 i see Feb 23 17:11:58 bitbake minimal-image is failing on a lack of chrpath right now.... Feb 23 17:12:08 I think ports should be enough to jump start Feb 23 17:12:10 so, I built patchelf and am wondering how to replace the dependency. Feb 23 17:12:19 ok Feb 23 17:13:02 khem: sure, but I guess it is personal taste that I prefer Gentoo Prefix than ports (can't remember the full name of the ports project) Feb 23 17:14:01 jkridner: replace CHRPATH_BIN in bitbake.conf and classes/relocatable.bbclass Feb 23 17:14:04 khem: so, what are your thoughts on moving to patchelf? is there a good approach? Feb 23 17:14:13 k Feb 23 17:14:21 to point to patchelf Feb 23 17:14:52 CHRPATH_BIN isn't set in my bitbake.conf Feb 23 17:14:52 and add it to required_utilities in classes/sanity.bbclass Feb 23 17:15:09 ok then dont do it in bitbake.conf :) Feb 23 17:15:29 I'm using 1.12 Feb 23 17:16:21 jkridner: then changes to classes/sanity.bbclass and classes/relocatable.bbclass should be enough Feb 23 17:16:41 and also get rid of depenendency on chrpath in classes/sanity.bbclass Feb 23 17:17:06 * khem can test a patch Feb 23 17:17:52 what is that command-line utility to use pastebin? Feb 23 17:18:04 pastebinit Feb 23 17:19:58 new verb Feb 23 17:21:23 heh Feb 23 17:21:35 kergoth: where can I add a required dep Feb 23 17:21:49 that depends on what you mean by required dep :) Feb 23 17:21:59 kergoth: yes Feb 23 17:22:04 but -native Feb 23 17:22:14 dont depend on buildhost Feb 23 17:22:57 well, the issue is, of course, that adding any dep to "everything" is in danger of circular for itself and anything it depends on Feb 23 17:23:06 which is why base and autotools are careful about how they add things Feb 23 17:23:30 right Feb 23 17:23:43 patchelf is not provided by all distros Feb 23 17:23:47 thats the problem Feb 23 17:24:21 right, so we should add it as a required dep to base.bbclass most likely, let the user use ASSUME_PROVIDED to say its already there, and make sure insane doesn't freak out in either case Feb 23 17:24:27 * kergoth shrugs Feb 23 17:25:00 ideally we'd have a cleaner mechanism, but its tough since you can't just inspect what this other recipe depends on to exclude a section of the dependency graph from it Feb 23 17:25:44 Well, isn't the problem with patchelf or chrpath being able to build it before we need it? Feb 23 17:25:52 Or does patchelf have small enough deps? Feb 23 17:26:19 it needs libc nothin more Feb 23 17:26:21 i expect it likely has few enough Feb 23 17:26:44 in this case its a simple add, just saying we can't just DEPENDS_prepend = " foo-native" to blindly add it everywhere or anything that quick and easy.. Feb 23 17:26:56 erm, bad space usage there, but you get the point Feb 23 17:27:01 heh Feb 23 17:28:26 for deps see http://hydra.nixos.org/build/114534/contents/1 Feb 23 17:31:27 kergoth: in bitbake.conf ? Feb 23 17:40:19 khem, you'll need to see base.bbclass for how we fiddle around with this today Feb 23 17:40:41 And since kergoth eliminated the other examples, that function is a bit smaller than it used to be, heh Feb 23 17:40:57 we explicitly code in the knowledge of the dependencies of the thing we're building, ensuring it doesn't get added for itself and things it depends on Feb 23 17:41:29 it's too bad we can't tell bitbake about this in some way, but i really don't know how that would work :) Feb 23 17:43:01 khem, when you get a chance, may I ask you to build groff and see if it still works for you? (Fails for me, but you committed the recipe so I know it worked at one time) Feb 23 17:43:51 I get a failure in do_install -- can't find img/pic* (because we don't actually run groff to populate those files during the cross build) Feb 23 17:45:21 I solved my xmlto problem earlier. It turns out that I didn't have what is called "xml catalogues" set up correctly Feb 23 18:03:17 * Tartarus kicks lzma recipe Feb 23 18:32:18 ah the optspace bug is fixed upstream Feb 23 18:32:21 for ppc Feb 23 18:32:34 oh even better its ported into 4.5 Feb 23 18:32:39 branch Feb 23 18:32:42 perfect Feb 23 18:32:44 fun Feb 23 18:33:02 I will put it under fire lets see Feb 23 18:37:35 something radical change in bitbake-1.8.12 with regards to env vars? its giving me grief that looks like I didn't define MACHINE correctly, which is in BB_ENV_EXTRAWHITE and exported Feb 23 18:38:01 1.12.0? no Feb 23 18:38:11 but what do you have, exacvtly? Feb 23 18:38:13 sorry 1.12.0 Feb 23 18:38:28 export BB_ENV_EXTRAWHITE="MACHINE ANGSTROM_GCC_VERSION DISTRO LIBC BBPKGS" Feb 23 18:38:31 ERROR: Unable to determine endianness for architecture 'INVALID' | ETA: --:--:-- Feb 23 18:38:31 ERROR: Please add your architecture to siteinfo.bbclass Feb 23 18:38:31 ... Feb 23 18:38:33 works for me Feb 23 18:38:41 hmm Feb 23 18:38:53 sure you passed the right machine? Feb 23 18:39:17 ah... must be something about BBPATH that changed then as my machine is custom in an overlay Feb 23 18:39:44 whats BBPATH look like? :) Feb 23 18:41:16 /mnt/sda1/oe/build:/mnt/sda1/oe/local:/mnt/sda1/oe/overlay:/mnt/sda1/oe/org.openembedded.dev Feb 23 18:41:49 so no vars, ok Feb 23 18:41:57 where my machine conf is in /mnt/sda1/oe/overlay/conf/mymachine.conf Feb 23 18:42:54 tharvey: why not use bblayes Feb 23 18:43:00 if you are using 1.12 Feb 23 18:43:38 anyone tried booting qt4-x11-demo-image ? Feb 23 18:43:40 ya, will likely move to that, but figured it should work with the BBPATH overlays I have now - I've been using a rather recent bitbake-git, just threw in 1.12 and ran into issues Feb 23 18:43:53 ok Feb 23 18:44:03 bitbake -DDDD Feb 23 18:44:10 is your friend here Feb 23 18:44:18 see where and what files are being read in Feb 23 18:44:32 good point Feb 23 18:44:40 btw is bblayers documented well now in bitbake manual? Feb 23 18:44:48 dont think so Feb 23 18:44:59 doubtful Feb 23 18:45:07 Tartarus: is patchwork clean Feb 23 18:45:14 Tartarus: it seems some patches got applied Feb 23 18:45:24 and not updated the status in pw Feb 23 18:45:29 khem, I've been trying to keep up with what I apply, but no, I haven't checked in the last day or two Feb 23 18:45:37 ok Feb 23 18:45:46 Digging at the problem I reported that wasn't libpcap right now Feb 23 18:45:52 khem, have any pointers for good documentation on using bblayers then? Feb 23 18:45:57 gm Feb 23 18:45:58 khem, are you about to go at it? Feb 23 18:46:06 Or should I try and hit that up in the next hour or so Feb 23 18:46:07 Tartarus: less likely Feb 23 18:46:16 I am struggling with my demo Feb 23 18:46:21 ok Feb 23 18:46:27 i'll get at it soon then, thanks for the reminder Feb 23 18:46:33 ok Feb 23 18:47:09 I would think if we want ppl to move to bblayers we should get it documented properly Feb 23 18:48:47 Well, we hopefully will once it makes more sense still, heh Feb 23 18:49:06 (ie once we have oe-core and meta-oe and $distro-collection and $bsp-collection Feb 23 18:53:21 tharvey: my blog http://sakrah.homelinux.org/blog/2010/11/bblayers-bbappend/ Feb 23 18:55:15 thx, I'll look over that Feb 23 18:55:30 Tartarus: re our conversation this morning - I rewound the repository to 8e4bd2f (end of Sunday) and freetype is OK again. Feb 23 18:55:43 so bblayers itself currently works well but there is still work ongoing to split the metadata into various layers right? Feb 23 18:56:39 martinmeba, can you run a git bisect? Feb 23 18:56:51 yeah - that was what I was going to start into Feb 23 18:57:01 I am just going to rebuild my whole image and make sure it is happy before I start that Feb 23 19:00:21 stupid user error regarding my bitbake-1.12 issue Feb 23 19:02:18 what was it, if you don't mind Feb 23 19:05:32 I have a wrapper that checkes oe snapshot rev and bitbake rev and updates if needed, which also whacked a local change in a user.conf to append a collection that is 'not' in BBPATH Feb 23 19:05:44 or I should say that gets dynamically added to BBPATH Feb 23 19:06:08 victim of my own cleverness, or lack there-of Feb 23 19:06:20 tharvey: yeah autoconf was born due to all this sort of conveniences Feb 23 19:06:34 unless it overtook human brain Feb 23 19:06:41 heh Feb 23 19:06:59 * tharvey reminds himself to test on oe-trunk before testing his custom build with local overlays Feb 23 19:09:12 I do find it odd however that if you do end up with MACHINE set to something invalid that bitbake just 'hangs' after complaining about invalid architecture etc Feb 23 19:09:32 it shouldn't do that Feb 23 19:09:35 that would be a bug Feb 23 19:09:39 cntl-c won't even kill it - have to kill it with job control Feb 23 19:09:47 oh, i know what that one is Feb 23 19:09:51 richard just fixed it in poky's bitbake Feb 23 19:09:56 not in master or 1.12 yet Feb 23 19:10:18 good to know Feb 23 19:10:23 tharvey: http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=56a92105fe6b779c69bccd44c2cff8f21cafdfbd Feb 23 19:10:56 * kergoth doesn't particularly like that approach, implementation wise, but it does resolve the issue Feb 23 19:11:41 * Tartarus hits python-numpy Feb 23 19:13:33 khem: http://pastebin.com/cM6KxiEb Feb 23 19:13:49 * jkridner assumes there is going to be more than that involved. :) Feb 23 19:14:22 jkridner, yeah, patchelf recipes :) Feb 23 19:14:26 * kergoth pokes at src_distribute*.bbclass Feb 23 19:15:17 yeah, but I think that'll probably be easier than chrpath recipes. maybe not? Feb 23 19:15:54 jkridner: that wont work fully Feb 23 19:16:05 as you need to add dep on patchelf-native somehwere Feb 23 19:16:14 not all distros ship patchelf Feb 23 19:16:20 :( Feb 23 19:16:31 so asking it to be present on distro would be a big ask Feb 23 19:17:15 what about what actually calls chrpath? since the arguments are different, don't the calls need to be changed as well? Feb 23 19:17:36 I doubt dostros ships chrpath either though Feb 23 19:17:50 Crofton|work, they have it available Feb 23 19:17:56 * jkridner definitely prefers one less distro dependency rather than swapping one for another. Feb 23 19:18:02 RHEL5/Ubuntu 8.04, even Feb 23 19:18:15 Tartarus: not all do. Feb 23 19:18:31 jkridner, which one doesn't? Feb 23 19:18:47 If you can get it on rather stale rhel5, it's gotta be available elsewhere, in general :) Feb 23 19:18:48 It is masked on most architectures in Gentoo Prefix. Feb 23 19:18:51 what is wrong with using a patchelf-native deopensency? Feb 23 19:19:06 Crofton|work, long term, nothing Feb 23 19:19:12 jkridner, any idea why? Feb 23 19:19:17 * Crofton|work knows he is only have paying attention, but this is easier than dma_sync_single_for_device Feb 23 19:19:44 I think the ebuild just wasn't complete... Feb 23 19:20:00 I saw some issues with compiler arguments on some architectures. Feb 23 19:20:09 Sounds odd, heh Feb 23 19:20:21 But, regardless, yeah, I'm down with replacing a host distro dep with something we build Feb 23 19:20:29 Just need to be careful for these very eary things Feb 23 19:21:36 * jkridner is happy to see khem already added a patchelf-native recipe. :) Feb 23 19:22:28 * Tartarus adds endian overrides to his OVERRIDES wishlist and moves on Feb 23 19:22:35 03Andreas Müller  07master * rcf1849501b 10openembedded.git/classes/cross.bbclass: (log message trimmed) Feb 23 19:22:36 cross.bbclass: Fix many QA RPATH errors for distros preferring libtool-2.2 Feb 23 19:22:36 * This patch removes the absolute path in sysroots//usr/lib/libstdc++.la Feb 23 19:22:36 * Feb 23 19:22:36 * It was build tested wih clean tmp for xfce46-image. Additional known Feb 23 19:22:36 * QA-RPATH-error-candidates were checked for successful build: Feb 23 19:22:37 * Feb 23 19:28:24 guh, src_distribute is crap, how best to do this.. Feb 23 19:28:29 since there is a 'chrpath-native' recipe, is the dependency on 'chrpath' for the purpose of bootstrapping? would the same be true of 'patchelf'? Feb 23 19:28:46 Well, we don't do chrpath the way we want to do patchelf Feb 23 19:29:05 We force chrpath to exist on the host distro as getting the deps right wasn't possible, or not desirable anyhow Feb 23 19:29:12 But patchelf is much smaller, yes? Feb 23 19:29:31 Tartarus: as pb suggested once, we may want to start playing with a namespaced overrides var at some point.. endian/32, buildarch/foo, whatever.. Feb 23 19:29:41 heh Feb 23 19:36:01 * Tartarus kicks loudmouth, more Feb 23 19:36:10 it's moved to gnome.org and all the checksums changed Feb 23 19:37:33 any reason why do_package_update_index_ipk[recrdeptask] += "do_package_write_ipk" line is duplicated in package_ipk.bbclass? Feb 23 19:38:00 lines 71 and 72 Feb 23 19:42:20 how do I force removal of a file from sysroots (especially libsupc++) Feb 23 19:43:57 (apart from removing TMPDIR :-) ) Feb 23 19:44:12 -c clean the recipe that put it there Feb 23 19:44:15 heh Feb 23 19:46:07 kergoth, this comes from gcc, I already did bitbake -cclean gcc-cross gcc gcc-cross-initial gcc-cross-intermediate Feb 23 19:46:17 I'm not *that* n00bish ;-) Feb 23 19:46:34 * eFfeM leans towards "rm" Feb 23 19:46:35 03Tom Rini  07master * r3116d890c4 10openembedded.git/recipes/loudmouth/ (5 files): Feb 23 19:46:35 loudmouth: Part of GNOME Feb 23 19:46:35 The previous upstream URI is gone and what's on ftp.gnome.org Feb 23 19:46:35 implies it's long been part of GNOME. Sources for 1.1.1 and 1.3.2 are Feb 23 19:46:35 non-fetchable so move to nonworking. Update 1.0.1, 1.2.2 and 1.4.3 Feb 23 19:46:36 to fetch from GNOME_MIRROR and bump PR (as DEPENDS changed). Feb 23 19:46:37 Signed-off-by: Tom Rini Feb 23 19:46:53 Did you also get gcc? Feb 23 19:47:02 yes Feb 23 19:47:06 and while at it, glibc glibc-initial, in order to build again later Feb 23 19:47:29 * Tartarus tests a probably unrelated to the usual lzma race lzma race fix Feb 23 19:47:51 Tartarus: actually I know why neek gets the libsupc++ QA error, there is a patch in 4.2.*.inc for it, but not in 4.1.2, wanted to try that Feb 23 19:48:21 ah good Feb 23 19:48:32 a bit more than 24h until I update the branch again :) Feb 23 19:49:08 ok, will try to test it, then submit a patch Feb 23 20:16:02 khem, patchwork up to dateish again Feb 23 20:16:08 need to review otavio's stuff, heh Feb 23 20:19:58 khem, Tartarus patch for libstdc++ libsupc++ QA issue for gcc 4.1.2 submitted, please review, this will help to get more neek stuff compiled (neek is currently only supported in 4.1.2) Feb 23 20:20:46 ok Feb 23 20:22:24 what's the proper way to find out the chosen packaging solution (ipk/deb/rpm")? Feb 23 20:22:43 filip, what're you driving at? :) Feb 23 20:22:59 Aside from meta-toolchain* (which is broken, imho), stuff should be packaging agnostic Feb 23 20:23:20 Tartarus: recipes/meta/package-index.bb Feb 23 20:23:29 evening Feb 23 20:23:31 Tartarus: it's only for ipks Feb 23 20:23:33 Jay7: hi Feb 23 20:24:18 filip, also broken I guess :( Feb 23 20:24:41 * Tartarus wonders how lzma passes package_qa as he's pretty sure this breakage he sees isn't local... Feb 23 20:25:29 Tartarus: any hints how to make it automagically call package_update_index_ipk/package_update_index_deb/package_update_index_rpm ? Feb 23 20:25:48 filip, lets ask fray if poky has fixed this :) Feb 23 20:25:55 since poky does ipk and rpm Feb 23 20:26:02 filip: how are your patches? :) Feb 23 20:26:21 Tartarus: lzma again? Feb 23 20:26:43 Jay7, yeah, I hit a different race Feb 23 20:26:51 And I have a fix, but it made me look at building this thing Feb 23 20:26:54 And, um, owch Feb 23 20:27:06 Jay7: well koen has sticket his between HEAD and mine Feb 23 20:27:09 sticked* Feb 23 20:27:20 Jay7: rest is New without replies, so I really dunno :) Feb 23 20:28:26 well.. better to have it all in this release-testing branch Feb 23 20:28:53 Jay7: what do you mean? Feb 23 20:29:24 filip: I mean testing-release-2011.03 Feb 23 20:29:54 Tartarus: how about specifying a generic package_update_index task, with addtask package_update_index_ipk before package_update_index ? Feb 23 20:30:12 filip, I'd really go and see how poky solved this, assuming they have Feb 23 20:30:17 Jay7: but the stuff I am doing doesn't really fit well in 'testing' Feb 23 20:30:17 since we're going to base oe-core on poky Feb 23 20:30:24 Jay7: I am messing up quite a bit Feb 23 20:30:37 Tartarus: ok, I'll have a look Feb 23 20:30:42 (And, ah-ha, we either don't ship liblzma.a or since it's an ar archive we just can't check it :( ) Feb 23 20:30:48 * Tartarus waits for that task to fire already Feb 23 20:32:01 khem, you going to push the groff fix or want me to? Feb 23 20:34:42 Tartarus: naah, they're doing the same dirty thing: http://git.pokylinux.org/cgit/cgit.cgi/poky/tree/meta/recipes-core/meta/package-index.bb Feb 23 20:35:47 Does package_update_index_ipk have a dummy for when package_ipk isn't in? Feb 23 20:35:51 or fail, heh Feb 23 20:39:12 Tartarus: no idea, I've added do_package_update_index_deb to package_deb.bbclass Feb 23 20:39:21 Tartarus: but I don't know how to call it from package_index.bb Feb 23 20:40:48 Tartarus: do you think the idea above is a good one? Feb 23 20:41:56 Yes, I think so for now Feb 23 20:42:11 ok, let me proceed with that :) Feb 23 20:45:25 Tartarus: how should I note that a patch depends on another (previous) patch? Feb 23 20:46:43 That's been accepted or not? Feb 23 20:46:49 Which one, maybe I can just approve it real quick :) Feb 23 20:47:07 Tartarus: it's new (http://patches.openembedded.org/patch/755/) Feb 23 20:47:47 I'll apply that shortly Feb 23 20:47:57 I really wanna finish kicking lzma into shape, heh Feb 23 20:49:20 Tartarus: thanks :) Feb 23 20:56:05 eFfeM, ping Feb 23 21:00:06 I have trying to compile a console-image, but have failed the download of cramfs Feb 23 21:00:43 I have used the command bitbake recipe -f -c fetch to try to fetch again the package but don't work Feb 23 21:01:01 any idea how I can force to make the download ? Feb 23 21:02:56 Tartarus: pong Feb 23 21:02:59 how does the download fail? Feb 23 21:03:06 eFfeM, patch looks fine, just push it Feb 23 21:03:17 can I post the output of the command here ? Feb 23 21:03:45 Tartarus: can I add your ack (as it is a toolchain related patch officially I need two acks, so let's at least add one :-) ) Feb 23 21:04:03 sure Feb 23 21:04:07 NOTE: Preparing runqueue NOTE: Executing runqueue NOTE: Running task 2 of 2 (ID: 0, /home/anibal/OMAP/oe/arago-oe-dev/recipes/cramfs/cramfs_cvs.bb, do_fetch) NOTE: package cramfs-1.1+cvs20110110-r0: task do_fetch: Started NOTE: package cramfs-1.1+cvs20110110-r0: task do_fetch: Succeeded NOTE: Tasks Summary: Attempted 2 tasks of which 1 didn't need to be rerun and 0 failed. Feb 23 21:04:12 Acked-by: Tom Rini Feb 23 21:04:15 ok, thanks Feb 23 21:05:50 Tartarus: there it is: Feb 23 21:05:59 03Frans Meulenbroeks  07org.openembedded.dev * rbc56218e9e 10openembedded.git/recipes/gcc/gcc-4.1.2.inc: Feb 23 21:05:59 gcc 4.1.2: fix dependency_libs for libstdc++ and libsupc++ Feb 23 21:05:59 This fixes a QA issue in gcc 4.1.2. Feb 23 21:05:59 The patch is identical to what is done in gcc 4.2.2 and 4.2.4 Feb 23 21:05:59 The issues caused neek compilations to fail Feb 23 21:05:59 Signed-off-by: Frans Meulenbroeks Feb 23 21:06:01 Acked-by: Tom Rini (on irc) Feb 23 21:06:31 Tartarus: might be interesting to see if now more of neek builds, will try to kick off a build for console-iamge Feb 23 21:07:18 ok Feb 23 21:07:27 I didn't take too much out of the matrix for neek for next go-around Feb 23 21:07:34 just uclibc, and micro Feb 23 21:08:24 03Filip Zyzniewski  07master * rc596318ffc 10openembedded.git/recipes/linux/ (31 files in 7 dirs): Feb 23 21:08:24 linux/jlime: removed obsolete kernel recipes, added a new one. Feb 23 21:08:24 We need to focus on developing a new set of kernels and userspace, Feb 23 21:08:24 hence the cleanup. Feb 23 21:08:24 Signed-off-by: Filip Zyzniewski Feb 23 21:08:25 Signed-off-by: Tom Rini Feb 23 21:08:35 03Tom Rini  07master * r6bb7f0a606 10openembedded.git/recipes/lzma/ (lzma-4.65/makefile-cleanup.patch lzma.inc): (log message trimmed) Feb 23 21:08:35 lzma: Various cleanups and a bugfix Feb 23 21:08:35 We use the subdir parameter to SRC_URI so that we will unpack into Feb 23 21:08:35 the normal S directory rather than WORKDIR (which avoids a race with Feb 23 21:08:35 the append to unpack and removal of empty log files). Next, we replace Feb 23 21:08:35 the regex to override the compiler with a patch that really does it Feb 23 21:08:36 where it's needed (C/LzmaUtil) and now we have a target liblzma.a Feb 23 21:08:38 03Filip Zyzniewski  07master * rd179809da0 10openembedded.git/classes/package_deb.bbclass: (log message trimmed) Feb 23 21:08:38 package_deb.bbclass: make version acceptable for dpkg-deb. Feb 23 21:08:38 dpkg-deb does not like version numbers without digits: Feb 23 21:08:38 NOTE: Running task 428 of 604 (ID: 14, Feb 23 21:08:40 [...]/openembedded/recipes/linux-firmware/linux-firmware_git.bb, Feb 23 21:08:40 do_package_write_deb) Feb 23 21:08:40 dpkg-deb - error: (upstream) version (`git') doesn't contain any digits Feb 23 21:09:48 Tartarus: uclibc and eglibc on neek do not work, actually I am surprised that you have issues with micro, someone at work did build a neek minimal-image for micro distro the other day Feb 23 21:09:53 03Otavio Salvador  07master * r459110a17e 10openembedded.git/classes/qmake_base.bbclass: (log message trimmed) Feb 23 21:09:53 qmake_base.bbclass: add generate_qt_config_file task Feb 23 21:09:53 This writes a qt.conf inside WORKDIR to properly configure projects Feb 23 21:09:53 based on CMake. This is required since qmake variables (returned by Feb 23 21:09:53 -query command) are fixed into the binary and can only be changed Feb 23 21:09:53 using a qt.conf file. Feb 23 21:09:54 Signed-off-by: Otavio Salvador Feb 23 21:09:55 03Otavio Salvador  07master * rac24dca288 10openembedded.git/classes/cmake.bbclass: Feb 23 21:09:56 cmake.bbclass: use 2.8 modules Feb 23 21:09:56 Signed-off-by: Otavio Salvador Feb 23 21:09:56 Signed-off-by: Tom Rini Feb 23 21:10:02 03Otavio Salvador  07master * r36a46e9db8 10openembedded.git/recipes/cmake/ (3 files in 2 dirs): Feb 23 21:10:03 cmake: drop 2.6.4 as it is not used by any distro Feb 23 21:10:03 Signed-off-by: Otavio Salvador Feb 23 21:10:03 Acked-by: Frans Meulenbroeks Feb 23 21:10:03 Signed-off-by: Tom Rini Feb 23 21:10:08 03Otavio Salvador  07master * r5bba90caad 10openembedded.git/classes/cmake.bbclass: Feb 23 21:10:08 cmake.bbclass: use QT_CONF_PATH to support Qt4 projects Feb 23 21:10:08 Signed-off-by: Otavio Salvador Feb 23 21:10:08 Signed-off-by: Tom Rini Feb 23 21:10:10 but if I recall correctly he had an issue with getting rid of opkg Feb 23 21:10:11 03Otavio Salvador  07master * r07fdc0e4e9 10openembedded.git/recipes/cmake/ (4 files in 2 dirs): Feb 23 21:10:12 cmake: update from 2.8.2 to 2.8.3 Feb 23 21:10:12 Signed-off-by: Otavio Salvador Feb 23 21:10:12 Signed-off-by: Tom Rini Feb 23 21:10:14 03Otavio Salvador  07master * r6ed0541653 10openembedded.git/recipes/cmake/ (5 files in 2 dirs): Feb 23 21:10:14 cmake: add OE qt4-tools-{native,sdk} support Feb 23 21:10:14 * make it find qmake2, moc4 and others Feb 23 21:10:14 * convert to INC_PR Feb 23 21:10:14 Signed-off-by: Otavio Salvador Feb 23 21:10:15 Signed-off-by: Tom Rini Feb 23 21:10:28 03Otavio Salvador  07master * r65fa94664f 10openembedded.git/recipes/syslinux/syslinux_3.82.bb: Feb 23 21:10:28 syslinux: add isolinux and chain packages Feb 23 21:10:28 This syncs the package recipe with the O.S. Systems tree adding more Feb 23 21:10:28 packages and fixing GNU_HASH issues. Feb 23 21:10:28 Signed-off-by: Otavio Salvador Feb 23 21:10:29 Signed-off-by: Tom Rini Feb 23 21:10:36 03Otavio Salvador  07master * r4f76c0e2e4 10openembedded.git/recipes/ntfsprogs/ (ntfsprogs/skip-erange-errors.patch ntfsprogs_2.0.0.bb): Feb 23 21:10:36 ntfsprogs: add 2.0.0 Feb 23 21:10:36 This recipe has been imported from O.S. Systems tree and hence starts Feb 23 21:10:36 at revision r2. Feb 23 21:10:36 Signed-off-by: Otavio Salvador Feb 23 21:10:36 Signed-off-by: Tom Rini Feb 23 21:10:40 03Otavio Salvador  07master * r4a37a644b9 10openembedded.git/contrib/distro-packages/debian/openembedded-essential-1.4/ (6 files in 2 dirs): Feb 23 21:10:41 contrib/openembedded-essential (debian): rename to be version agnostic Feb 23 21:10:41 Signed-off-by: Otavio Salvador Feb 23 21:10:41 Signed-off-by: Tom Rini Feb 23 21:10:47 dont understand why bitbake say "Attempted 2 tasks of which 1 didn't need to be rerun" when I say for force a fetch Feb 23 21:10:53 03Otavio Salvador  07master * r33d0e6d0ae 10openembedded.git/contrib/distro-packages/debian/openembedded-essential/debian/ (changelog control): Feb 23 21:10:53 contrib/openembedded-essential (debian): depends on chrpath Feb 23 21:10:53 Signed-off-by: Otavio Salvador Feb 23 21:10:53 Signed-off-by: Tom Rini Feb 23 21:10:54 03Otavio Salvador  07master * rd25f6c9a8c 10openembedded.git/recipes/parted/ (files/fix-MiB-handling.patch parted_2.3.bb): Feb 23 21:10:54 parted: fix MiB handling Feb 23 21:10:55 Signed-off-by: Otavio Salvador Feb 23 21:10:55 Signed-off-by: Tom Rini Feb 23 21:10:56 03Otavio Salvador  07master * rb7eb89b012 10openembedded.git/recipes/libinih/libinih_git.bb: Feb 23 21:10:57 libinih: readd without AUTOREV Feb 23 21:10:57 This provides a C and C++ INI library that can be statically linked Feb 23 21:10:57 into projects. Feb 23 21:10:58 Signed-off-by: Otavio Salvador Feb 23 21:10:58 Signed-off-by: Tom Rini Feb 23 21:11:13 shouldn't run all the tasks ... Feb 23 21:11:27 AnibalNine, it's not, it's saying what it didn't need to run Feb 23 21:11:31 03Otavio Salvador  07master * r813a686a45 10openembedded.git/recipes/libcap/ (libcap2-2.16/make.patch libcap2_2.16.bb): (log message trimmed) Feb 23 21:11:31 libcap2: 2.16 -> 2.20 Feb 23 21:11:31 Fix compilation with newer kernel headers: Feb 23 21:11:31 | .../tmp/sysroots/.../usr/include/asm/sigcontext.h:28:2: error: Feb 23 21:11:31 | expected specifier-qualifier-list before '__u64' Feb 23 21:11:32 | .../tmp/sysroots/.../usr/include/asm/sigcontext.h:191:2: error: Feb 23 21:11:33 | expected specifier-qualifier-list before '__u64' Feb 23 21:12:07 Tartarus : but I wan't to download again ... first time downloaded the message of the proxy saying error Feb 23 21:12:18 I need to download it again ... Feb 23 21:13:04 AnibalNine, do a -c clea Feb 23 21:13:05 n Feb 23 21:13:58 result : Tasks Summary: Attempted 1 tasks of which 0 didn't need to be rerun and 0 failed Feb 23 21:14:09 Now try and fetch it again Feb 23 21:14:30 Tasks Summary: Attempted 2 tasks of which 0 didn't need to be rerun and 0 failed Feb 23 21:14:50 but don't appeared any message of download ... Feb 23 21:15:39 OK, do a -c clean again, and rm *cramfs* from your download directory Feb 23 21:16:23 ok Feb 23 21:17:08 and now, a fetch again ? Feb 23 21:17:36 yes Feb 23 21:18:14 now worked Feb 23 21:18:33 I only cleaned the package, forgett the md5 Feb 23 21:18:39 thanks Feb 23 21:19:15 AnibalNine: as it is a cvs repo you might also check your Downloads/cvs dir Feb 23 21:19:52 the problem is in the work we have a proxy that sometimes fail the packages Feb 23 21:19:53 and remove cramfs if it is in there Feb 23 21:20:08 sometimes I download them by hand Feb 23 21:20:28 but cvs only at home without a proxy Feb 23 21:20:53 03Mike Westerhof  07master * r70bf94cd86 10openembedded.git/recipes/groff/groff_1.20.1.bb: (log message trimmed) Feb 23 21:20:54 groff: Fix do_install in certain cases, along with DEPENDS Feb 23 21:20:54 Sometimes groff fails in the do_install step, complaining that img/pic* does Feb 23 21:20:54 not exist. Normally, these files would be created by groff itself during the Feb 23 21:20:54 build process, but since we are cross-compiling, the old recipe replaces the Feb 23 21:20:54 invocation of groff and troff with echo commands. However, echo does not Feb 23 21:20:55 create the output files, which eventually results in the do_install failure. Feb 23 21:21:47 otavio, I'll test your libcap2 patch now Feb 23 21:21:56 GNUtoo|laptop, it's in, btw Feb 23 21:22:06 ah? Feb 23 21:22:11 I'll look Feb 23 21:22:27 I didn't see it Feb 23 21:22:32 it applied correctly Feb 23 21:22:33 All of 5 minutes ago Feb 23 21:22:38 ah ok Feb 23 21:22:47 OK, 11, now that I scroll up :) Feb 23 21:22:48 03Alex Bennee  07master * r2977a53f5e 10openembedded.git/recipes/lm_sensors/lmsensors-apps_2.10.8.bb: (log message trimmed) Feb 23 21:22:48 libsensors: Remove clashing header definition from package Feb 23 21:22:48 libsensors attempts to install: Feb 23 21:22:48 /usr/include/linux/i2c-dev.h Feb 23 21:22:48 Which clashes with the libc definition. This patch removes it Feb 23 21:22:49 from the build (as suggested by _pb on #oe). Feb 23 21:22:50 Signed-off-by: Alex Bennee Feb 23 21:23:44 GNUtoo|laptop: NICE Feb 23 21:24:09 otavio, note that I arrived too late to do something Feb 23 21:25:10 GNUtoo|laptop: heh no problem Feb 23 21:27:45 03Filip Zyzniewski  07master * r90c3b8c9fe 10openembedded.git/classes/ (package_deb.bbclass rootfs_deb.bbclass): Feb 23 21:27:45 package_deb.bbclass: create a proper package_update_index_deb task. Feb 23 21:27:45 Until now the Packages.gz generation was hardcoded in rootfs_deb_do_rootfs. Feb 23 21:27:45 (Tom Rini: While in here, trailing whitespace cleanup) Feb 23 21:27:45 Signed-off-by: Filip Zyzniewski Feb 23 21:27:46 Signed-off-by: Tom Rini Feb 23 21:28:17 03Tom Rini  07master * rc9400e9457 10openembedded.git/conf/distro/include/angstrom-2008-preferred-versions.inc: Feb 23 21:28:17 angstrom-2008: Pin gvfs at 1.6.6 Feb 23 21:28:17 We're doing this since glib-2.0 is pinned. Feb 23 21:28:17 Signed-off-by: Tom Rini Feb 23 21:28:17 Acked-by: Koen Kooi Feb 23 21:28:23 Tartarus: thanks by pushing them Feb 23 21:28:33 03Tom Rini  07master * r6cf1be4feb 10openembedded.git/conf/distro/include/preferred-slugos-versions.inc: Feb 23 21:28:34 slugos: Pin gvfs to 1.6.6 Feb 23 21:28:34 We're doing this since glib-2.0 is pinned. Feb 23 21:28:34 Signed-off-by: Tom Rini Feb 23 21:28:34 Acked-by: Mike Westerhof Feb 23 21:30:01 03Andreas Oberritter  07master * r03663c9538 10openembedded.git/classes/kernel.bbclass: Feb 23 21:30:01 kernel.bbclass: provide virtual/kernel-${PV} Feb 23 21:30:01 * Allow precompiled modules to depend on a specific kernel version. Feb 23 21:30:01 Signed-off-by: Andreas Oberritter Feb 23 21:30:01 Signed-off-by: Tom Rini Feb 23 21:31:38 oh shit... Feb 23 21:31:40 03Tom Rini  07master * re3b50a48f1 10openembedded.git/conf/distro/include/kaeilos-2009-preferred-versions.inc: Feb 23 21:31:40 kaeilos 2009: Pin gvfs to 1.6.6 Feb 23 21:31:40 We're doing this since glib-2.0 is pinned. Feb 23 21:31:40 Signed-off-by: Tom Rini Feb 23 21:31:44 03Tom Rini  07master * r1357ff14aa 10openembedded.git/recipes/gnome/gvfs_1.7.2.bb: Feb 23 21:31:44 gvfs 1.7.2: Drop DEFAULT_PREFERENCE Feb 23 21:31:44 This is the version required for glib-2.28.0 which is default unless Feb 23 21:31:44 pinned. Feb 23 21:31:45 Signed-off-by: Tom Rini Feb 23 21:31:57 I am about to unleash a massive commit Feb 23 21:33:08 fear me Feb 23 21:34:53 has anyone compiled rlwrap using openembedded Feb 23 21:35:10 it's configure compiles some stuff when detecting getopt Feb 23 21:37:21 which of course doesn't work when cross-compiling Feb 23 21:37:48 or not... Feb 23 21:37:53 DAMN Feb 23 21:42:15 creationix: compiling isn't a problem, but running is. depending on the configure script, you can usually either set some cache variables (grep for ac_cv_.*) or replace AC_TRY_RUN with AC_TRY_LINK or similar Feb 23 21:45:40 obi: so if I know that my target platform needs, I just need to hard-code the value Feb 23 21:48:11 yes. that's what the cache variables are good for. if they are specific to a cpu arch, then the variables should go to openembedded/site/mipsel-linux etc. Feb 23 21:48:16 khem: I'm not sure of the steps to follow to put the patchelf dependencies in, so I figured I'd start debug by starting to build and seeing where things failed. Right now, I'm dying in building quilt-native. http://pastebin.com/2xGAF0L4 http://pastebin.com/GknsB75h Feb 23 21:50:30 yeah quilt has some darwin specific patches Feb 23 21:50:46 look at the darwin-fixes branch Feb 23 21:50:51 there might be something there Feb 23 21:50:57 which is not upstream yet Feb 23 21:58:22 ah, I thought the patches I'd submitted previously had been already accepted. :( Feb 23 21:58:22 I see several of my own patches on that fork. Feb 23 21:58:24 er, branch Feb 23 21:58:26 Tartarus: as we discussed earlier today, I bisected the build failure for freetype. Feb 23 21:58:26 here is the result: Feb 23 21:58:26 git bisect start Feb 23 21:58:26 # good: [8e4bd2fd4cbf1c75acd30adbd3aaa074c3175a3e] linux-2.6.34: add unwinding to om-gta01's defconfig Feb 23 21:58:26 git bisect good 8e4bd2fd4cbf1c75acd30adbd3aaa074c3175a3e Feb 23 21:58:26 # bad: [1357ff14aaa3c8078354661d8e6c4fdfa755416d] gvfs 1.7.2: Drop DEFAULT_PREFERENCE Feb 23 21:58:26 git bisect bad 1357ff14aaa3c8078354661d8e6c4fdfa755416d Feb 23 21:58:27 # bad: [6bb7f0a60617f50da54eaa03f25a14bfb19aad64] lzma: Various cleanups and a bugfix Feb 23 21:58:27 git bisect bad 6bb7f0a60617f50da54eaa03f25a14bfb19aad64 Feb 23 21:58:27 # bad: [d6729be1fd7f2e82e7535a854e2aae006aaec5ee] evas: disable NEON forcefully, it is still causing misrendering when enabled Feb 23 21:58:27 git bisect bad d6729be1fd7f2e82e7535a854e2aae006aaec5ee Feb 23 21:58:27 # bad: [52d750320e5ec2d6ff8cefbacc0f7d8d9a9f8728] strongswan: Add version 4.5.1 Feb 23 21:58:27 git bisect bad 52d750320e5ec2d6ff8cefbacc0f7d8d9a9f8728 Feb 23 21:58:27 # good: [b162231b359bd218cbe0c1000e4fb33f4d942751] This patch changes hard-coded references to /usr and /opt in the various squid config.test scripts to point to the correct sysroot paths. This version accommodates the unusual staging dir layout used by micro. Signed-off-by: Mike Westerhof Acked-by: Khem Raj Feb 23 21:58:27 git bisect good b162231b359bd218cbe0c1000e4fb33f4d942751 Feb 23 21:58:27 sorry about that Feb 23 21:58:27 bad paste Feb 23 21:58:27 I meant this: http://pastebin.com/fzWwC87h Feb 23 22:03:44 jkridner: yes that branch should merge one day Feb 23 22:03:50 into master Feb 23 22:03:59 but we dont have force user of macosx here Feb 23 22:04:15 one of us starts and deflates after a while Feb 23 22:08:34 * mwester looks at the blast of commits, and scratches his head Feb 23 22:10:17 :) But it looks like building SlugOS from tomorrow's release will result in man pages in the package feeds! (for the first time in a long time, 'cause I just never found time to fix groff up to now) Feb 23 22:11:27 I quite like the concept of a release -- it turns out that I need a deadline to organize my efforts around. :) **** BEGIN LOGGING AT Wed Feb 23 22:23:30 2011 Feb 23 22:41:25 khem: I'm not quite finding the right patch, but I'll keep looking later. Feb 23 23:10:12 filip, what sort of hardware are you planning on using your oe/apt system on? Feb 23 23:10:53 And can you give an indication of the footprint (memory and disk) that dpkg/apt use compared with opkg? Feb 23 23:49:37 03Tom Rini  07master * rf2bda313c9 10openembedded.git/recipes/binutils/binutils-avr32.inc: (log message trimmed) Feb 23 23:49:37 binutils-avr32.inc: Switch to do_configure_{prepend,append} Feb 23 23:49:37 While adding autoconf/automake to DEPENDS helps, that only Feb 23 23:49:37 means they must have completed do_populate_sysroot before Feb 23 23:49:37 we can run do_configure, and since do_avr32_reconf was before Feb 23 23:49:38 do_configure it will be run before autoconf is there, with enough Feb 23 23:49:39 BB_NUM_THREADS. Feb 24 00:17:29 03Tom Rini  07master * r2cb2509de3 10openembedded.git/conf/machine/at91sam9m10ekes.conf: Feb 24 00:17:29 Revert "make sd-boot default for sam9m10ekes" Feb 24 00:17:29 This was another out-of-order push from me that depends on other changes. Feb 24 00:17:29 Take this out for now so that u-boot builds again. Feb 24 00:17:29 This reverts commit ccb60316650162a417e519a123d9fd09eae9911e. Feb 24 00:47:01 03Tom Rini  07master * r558eb989e1 10openembedded.git/recipes/libnl/ (3 files in 2 dirs): Feb 24 00:47:01 libnl2: Finish fixing the build race on lib/route/pktloc.c Feb 24 00:47:01 Signed-off-by: Tom Rini Feb 24 02:30:51 03Enrico Scholz  07master * rc81990aeca 10openembedded.git/recipes/opkg-utils/ (opkg-utils/mtime-int.patch opkg-utils_svn.bb): (log message trimmed) Feb 24 02:30:51 opkg-utils: convert mtime to int before comparing it Feb 24 02:30:51 The st_mtime attribute (which is a float) is compared against a value Feb 24 02:30:51 from the timestamp database, which was stored as an integer there. Feb 24 02:30:51 When working on a filesystem with precise timestamps the comparision Feb 24 02:30:52 will fail nearly everytime hence. Feb 24 02:30:53 Although it might be possible to enhance the database to store the Feb 24 02:42:10 03Andreas Oberritter  07master * rb01a76952f 10openembedded.git/recipes/netkit-base/netkit-base_0.17.bb: Feb 24 02:42:10 netkit-base-0.17: use update-alternatives Feb 24 02:42:11 * Give netkit-inetd a priority of 70. Feb 24 02:42:11 * Add inetd.conf to CONFFILES_${PN}. Feb 24 02:42:11 * RPROVIDE inetd. Feb 24 02:42:11 Signed-off-by: Andreas Oberritter Feb 24 02:42:11 Signed-off-by: Khem Raj Feb 24 02:42:13 03Martin Jansa  07master * r4986641894 10openembedded.git/recipes/webkit/ (5 files in 2 dirs): Feb 24 02:42:13 webkit-efl: upgrade to 1.3.11, upstream has Source subdirectory now, which makes SRC_URI a lot shorter Feb 24 02:42:13 Signed-off-by: Martin Jansa Feb 24 02:42:13 Signed-off-by: Khem Raj Feb 24 02:45:00 03Andreas Oberritter  07master * r84f27c7901 10openembedded.git/ (3 files in 2 dirs): (log message trimmed) Feb 24 02:45:00 python-2.6: python-xml depends on python-elementtree Feb 24 02:45:00 * Fixes the following error: Feb 24 02:45:00 import xml.etree.cElementTree Feb 24 02:45:00 File "/usr/lib/python2.6/xml/etree/cElementTree.py", line 3, in Feb 24 02:45:01 from _elementtree import * Feb 24 02:45:01 ImportError: No module named _elementtree **** ENDING LOGGING AT Thu Feb 24 02:59:57 2011