**** BEGIN LOGGING AT Thu Nov 08 03:00:02 2012 Nov 08 08:29:23 morning all Nov 08 08:33:32 good morning Nov 08 08:34:10 Yocto project dev day in Barcelona has started Nov 08 08:59:53 hi mckoan Nov 08 09:12:20 hi mckoan, all Nov 08 09:12:34 mckoan: you're at the dev day? Nov 08 10:01:25 I copy in my layer the recipe of qt4-x11-free and change the .bb as I need, but when I compile packages I obtain that NOTE/warning on many packages, what I need to tune ? Nov 08 10:01:50 NOTE: consider defining a PREFERRED_PROVIDER entry to match qt4-demos-doc Nov 08 10:01:50 NOTE: preferred version 4.8.0 of qt4-x11-free not available (for item qt4-x11-free) Nov 08 11:24:22 morning all Nov 08 11:32:27 eFfeM_work: yes I am (and many others from OE) Nov 08 11:33:05 how can i remove ipv6 support from busybox ? Nov 08 11:33:24 (using a .bbappend) Nov 08 11:33:38 or something better... Nov 08 15:15:49 Crofton|work: OE board is now only 3 members? Nov 08 15:21:11 Crofton|work: ah nae worries I figured it out! Nov 08 15:28:20 XorA|gone, heh Nov 08 15:28:49 Crofton: forgot the 4th member was elected in Prague Nov 08 15:29:09 yep Nov 08 15:29:28 ok, back to work! Nov 08 15:29:30 l8r Nov 08 15:29:35 cya Nov 08 15:51:44 Hello everybody. I wonder how can I install libudev package. It seems that there is no recipie for it. Am I wrong ? Nov 08 15:55:51 well.. I can find libudev.so but I wonder how can I force copying libraries to my rootfs Nov 08 15:57:54 the recipe is udev Nov 08 15:57:56 not libudev Nov 08 16:00:05 kergoth: yes.. but I can find /lib/udev in my rootfs but not libudev.so Nov 08 16:01:12 wait.. I will check if udev is really installed Nov 08 16:01:30 yes, you're confusing recipes and packages Nov 08 16:01:36 the udev recipe emits a number of different packages Nov 08 16:01:38 including a libudev package Nov 08 16:01:59 see line 38 of meta/recipes-core/udev/udev.inc Nov 08 16:09:20 emm.. do you mean that adding libudev to IMAGE_INSTALL will install libudev library ? Nov 08 16:12:24 yes Nov 08 16:17:22 kergoth: thanks you very much, it worked Nov 08 16:18:18 np Nov 08 16:27:23 can anyone explain what egblic-initial/uclibc-initial are for? the old intermediate gcc appears to have been dropped, so the initial libc gets built then immediately the regular libc gets built afterward. Is there something i'm not aware of that this is doing, or is it just left over from when gcc-cross-intermediate existed? Nov 08 16:27:47 (context: i'm trying to write a recipe to use newlib as virtual/libc) Nov 08 16:30:40 iirc the initial libc is used to build the initial gcc, which is then used to build the final eglibc, which is used to build the final gcc Nov 08 16:30:46 something along those lines, anyway, just track the dependencies Nov 08 16:30:54 it's been a while since i had to build a crosscompiler from scratch Nov 08 16:31:23 no, it builds gcc-cross-initial, then libc-initial, then libc, then gcc-cross Nov 08 16:32:02 gcc-cross-initial doesn't need any headers at all Nov 08 16:32:32 and the current eglibc and uclibc recipes are happy to build with just gcc-cross-initial :) Nov 08 16:33:03 basically i'm trying to work out if i need a newlib-initial or not, and if so, what it should actually do Nov 08 16:34:07 i'd just reproduce the manual steps in recipe form and go from there. do the minimum necessary to make progress, and go back and flesh it out further if it becomes necessary Nov 08 16:34:07 pb_: ping.. i'm curious to see your mingw32 stuff still, for an example of a non-linux-centric build :) Nov 08 16:34:08 * kergoth shrugs Nov 08 16:34:27 kergoth: sure, that's what i'm doing, was just wondering if someone knew and could maybe save me some time :P Nov 08 16:34:46 heh, well, apparently my info is out of date, pre-removal-of-intermediate Nov 08 16:34:54 hopefully someone else knows the current state of things better than i Nov 08 16:37:01 kergoth: having looked through oe-core a bunch, though, i am much more optimistic about being able to use it for my custom OS than when oe was monolithic, so good job everyone i guess :) Nov 08 16:37:47 yeah, things have improved a great deal. having a core set of metadata whose quality is kept fairly high has made things easier for everyone Nov 08 16:38:14 it also means i won't end up having to have my users pull hundreds of megabytes of irrelevant recipes Nov 08 16:38:18 :p Nov 08 16:38:59 heh, indeed Nov 08 16:39:38 though it wouldn't be terribly hard to extract just the content you're using from oe-core into your own more minimal subset layer, if you wanted to do that. of course, then you'd have the issue of how to sync down updates from oe-core.. Nov 08 16:39:49 I don't think it's really necessary Nov 08 16:40:04 just using oe-core and being a separate layer means i can get new toolchain versions super easily and stuff Nov 08 16:40:17 i had a class once which did that for oe classic, you'd do a build with a -c and it'd copy all the files out for all the config/classes and recipes that were built into a separate directory Nov 08 16:40:18 * kergoth nods Nov 08 16:40:32 the problem with the monolithic repo was less the actual size, and more just not knowing where to look to find good examples of how to do stuff Nov 08 16:40:51 nod. the quality was quite varied, much of it didn't build at all Nov 08 16:40:54 oe-core appears to have a couple of pretty reasonable examples for each thing i look for in it, which is much more manageable Nov 08 16:41:27 there's just a lot more recipes floating around than there are maintainers to keep them in good shape :) Nov 08 16:41:33 yeah. Nov 08 16:41:59 i'm still stuck pretty much having to start with writing probably the hardest recipe i'll need, though (building a libc) :) Nov 08 16:42:54 newlib is not very popular on linux, i guess Nov 08 16:43:04 only with weird embedded people :p Nov 08 16:43:26 well, newlib is more often used for bare metal than people using linux Nov 08 16:43:35 quite popular for bare metal work though Nov 08 16:43:40 yeah, that's what i'm using it for Nov 08 16:44:07 my OS kernel is, er, CPython. So it doesn't build without a reasonably complete C library :p Nov 08 16:44:19 though my syscalls are pretty much all stubs Nov 08 16:44:22 hah. cute Nov 08 16:44:31 sounds like a fun exercise Nov 08 16:44:38 hey, this is a serious project Nov 08 16:44:39 :p Nov 08 16:44:53 (it already works) Nov 08 16:45:01 (my current build system is just terrible) Nov 08 16:45:56 the downside to oe/yocto/bitbake is it's a bit heavy. slow if you need to do a rapid compile/test cycle, for example. works well for the rest, though. Nov 08 16:46:47 yeah. that's not a problem, really. my "userspace image" as it were is just python code, so it doesn't need much building and can probably be done on its own Nov 08 16:46:53 * kergoth nods Nov 08 16:47:16 the actual boot binary is the fiddly part, with multiple libraries and platform-specific crap Nov 08 16:48:01 once that layer is actually approaching finished people will probably not need to build it often Nov 08 16:48:07 and can just use binaries Nov 08 17:10:03 hm. my configure fails with "Please use exactly Autoconf 2.64 instead of 2.69." :/ Nov 08 17:10:25 probably trivial to update the configure.{in,ac} for 2.69, but who knows Nov 08 17:10:50 indeed.. Nov 08 17:10:50 with autoconf/automake, predicting what versions will break compatibility is a guessing game Nov 08 17:11:07 can i disable running autoreconf? i'm not patching the sources so it shouldn't be needed.. Nov 08 17:11:27 it's almost always needed, because we patch the m4 macros used to generate teh configure script Nov 08 17:11:31 e.g. for libtool Nov 08 17:11:33 oh. Nov 08 17:11:43 hrm. Nov 08 17:12:06 you could bypass it, by overriding the do_configure task (see autotools.bbclass) Nov 08 17:12:26 if there is a package for fedora for that, check it for autoconf patches, fedora likes to keep upto date and is a good source :-) Nov 08 17:12:46 even cvs head uses 2.64 :/ Nov 08 17:14:36 hrmm Nov 08 17:14:49 actually, different bits of newlib are specifying different autoconf versions Nov 08 17:14:51 even better! :) Nov 08 17:15:05 nice Nov 08 17:15:06 hah Nov 08 17:15:09 lovely Nov 08 17:15:24 newlib has gcc-like source layout,w ith nested projects with their own configure's Nov 08 17:16:33 Torne: http://blog.gmane.org/gmane.comp.handhelds.openembedded/month=20100101 - looks like newlib recipes have been attempted at least once before, though a long time ago Nov 08 17:16:36 from a quick google Nov 08 17:16:37 heh Nov 08 17:17:27 yeah, i found that one but that guy didn't seem to kjnow what he was doing, or get anywhere Nov 08 17:17:33 or say what he was doing it for/etc Nov 08 17:17:41 so, not much of a way to follow up other than emailing him Nov 08 17:18:26 hm, actually, i'm not sure i even want to run the top level configure Nov 08 17:29:08 hm. do_configure now appears to be taking infinite time Nov 08 17:34:22 i hate autotools :) Nov 08 17:42:18 most people do Nov 08 17:43:24 it doesn't immediately break if i patch it to just use 2.69 Nov 08 17:43:45 but now C compiler can't create executables. i need to steal more magic from the eglibc recipe :) Nov 08 19:06:47 re **** ENDING LOGGING AT Fri Nov 09 02:59:58 2012