**** BEGIN LOGGING AT Mon Jun 20 02:59:57 2011 Jun 20 06:25:36 good morning Jun 20 11:13:26 hi gnutoo and ericben Jun 20 11:16:37 hi woglinde Jun 20 11:16:45 finished uni? Jun 20 11:17:49 no Jun 20 11:44:53 hi Jun 20 11:45:00 I've still issues with oe-core Jun 20 11:45:07 I'm still unable to build an image Jun 20 11:45:29 o.O Jun 20 11:45:47 hi woglinde, ant, all Jun 20 11:45:54 armv4t-oe-linux-gnueabi.gcc-cross-intermediate/gcc/arm-oe-linux-gnueabi/4.5.3/cc1: error while loading shared libraries: libmpc.so.2: cannot open shared object file: No such file or directory Jun 20 11:46:07 I tried to add it Jun 20 11:46:08 hm oh armv4t Jun 20 11:46:17 result => dependency loop Jun 20 11:46:38 where does the dependency loop come from? Jun 20 11:46:54 let me look Jun 20 11:47:04 it comes from libmpc requiring eglibc Jun 20 11:47:17 but I don't remember the exact error Jun 20 11:47:19 libmpc, or libmpc-native? Jun 20 11:47:37 it's libmpc-native that you're missing there. Jun 20 11:47:40 good question Jun 20 11:47:41 ok Jun 20 11:47:46 then I did an error Jun 20 11:47:58 and libmpc-native certainly shouldn't be depending on eglibc or any other target packages. Jun 20 11:48:04 if it does then that is surely a bug Jun 20 11:48:10 I added libmpc not native Jun 20 11:48:14 ah Jun 20 11:48:24 because I had no clue on which one to add Jun 20 11:48:31 since it's eglib-intermediate Jun 20 11:56:03 thanks a lot for the idea Jun 20 11:56:17 s/idea/fix/ Jun 20 12:00:19 have you ever seen this message building a kernel with a meta-toolchain ? fixdep: mmap: Cannot allocate memory Jun 20 12:06:05 mckoan not enough ram? Jun 20 12:10:34 pb_: hello Jun 20 12:11:18 woglinde: it was working on thsi machine Jun 20 12:11:38 I tried cahanging machine Jun 20 12:12:03 pb_: may I bother you with that klibc static chimaera? Jun 20 12:12:58 sure Jun 20 12:13:09 pb_: ok, hen http://paste.debian.net/120430/ http://paste.debian.net/120431/ Jun 20 12:13:34 (I renamed one) Jun 20 12:14:28 ah, I see Jun 20 12:14:36 so, klibc is putting in the INTERP even for static links, it seems Jun 20 12:15:02 well, I assume that's what's happening. did you want the binary in 120430 to be static or dynamic? Jun 20 12:15:19 we have one recipe for each Jun 20 12:15:33 klibc -> klibc-utils and klibc-static-utils Jun 20 12:15:36 okay Jun 20 12:15:45 so 120431 is the static one, and 120430 is meant to be dynamic? Jun 20 12:16:04 yes Jun 20 12:16:36 alright. so, what has actually happened in 120430 is that it has linked statically but then added klibc as a DSO. Jun 20 12:16:45 so, something has gone wrong with the final link command line I would guess. Jun 20 12:17:53 what puzzles me is the comment about rdepending on the very same klibc-xy.so Jun 20 12:18:10 sorry, which comment was that? Jun 20 12:19:32 # Yes we want exactly the klibc that was compiled with the utils Jun 20 12:19:34 THIS_KLIBC = "libklibc (= ${PV}-${PR})" Jun 20 12:19:51 then RDEPENDS_klibc-utils-sh = "${THIS_KLIBC}" Jun 20 12:19:57 for each util Jun 20 12:20:13 yeah, per previous discussion, I think that is bogus Jun 20 12:20:19 isn't Requesting program interpreter: /lib/klibc-3--IAVBuDTfb4XSbZ_h2wvoAZsQ.so random? Jun 20 12:20:28 looks it, yeah Jun 20 12:20:33 lol Jun 20 12:20:40 it's probably some kind of hash of the binary Jun 20 12:20:52 nothing about PV Jun 20 12:21:30 indeed, we need exactly that hash, indipendent from PV Jun 20 12:21:38 right Jun 20 12:21:53 and, if you let the autonamer do its own thing, that shoul d be what you get. Jun 20 12:21:55 but you suggestthe whole INTERP stuff is not needed? Jun 20 12:22:10 not for static binaries Jun 20 12:22:14 but you do need it for dynamic ones Jun 20 12:22:58 so, ithas to do with the way klibc builds its binaries, not how klcc builds external Jun 20 12:23:10 it seems Jun 20 12:23:23 because klcc does http://cgit.openembedded.org/cgit.cgi/openembedded/tree/classes/klibc.bbclass?h=org.openembedded.dev Jun 20 12:23:39 but klibc should be built with OE flags Jun 20 12:25:34 ok, it's the first time I see that ;) Jun 20 12:25:44 pb_: many thx Jun 20 12:26:46 woglinde: about that, you added an isystem patch for klcc. I somehow saw isystem in the Makefile and was wondering if we still need it Jun 20 12:27:17 (sorry no sources here...) Jun 20 12:32:50 pb_: one last note about that troublesome klibc recipe. In oe-dev we use FILESPATHPKG. I thought oe-core forbids it favoring FILESPATH manipulation but a quick check at oe-core eglibc's exposes it naked...glibc uses FILESPATH instead. Jun 20 12:36:08 I'm not quite sure whether eglibc is really using FILESPATHPKG or not. Jun 20 12:36:22 It does define that var but I'm not sure it is having any useful effect, and the recipe does also set FILESPATH. Jun 20 12:36:35 I think the FILESPATHPKG thing is just some artifact and should be deleted. Jun 20 12:37:44 pb_: I think you're right... unless the path being added has subdirs with machine names I don't think it does anything in oe-core Jun 20 12:38:33 yeah Jun 20 12:38:39 eglibc_2.13 does FILESPATHPKG =. "eglibc-svn:" Jun 20 12:38:44 but eglibc-svn doesn't exist at all Jun 20 12:38:56 so it's hard to see how this can be contributing much to the outcome. Jun 20 12:39:02 ant proably not Jun 20 12:40:39 florian: ping Jun 20 12:41:23 mickey|office: pong Jun 20 12:44:58 pb_: I'll add it to my todo list to patch if nobody else does first Jun 20 12:47:57 good-o Jun 20 12:48:29 pb_: I'd like to converti the oe-dev recipe for future cherry-pick. grep revealed any recipe in oe-dev uses FILESPATH directly :/ Jun 20 12:48:46 is in the classes, though Jun 20 12:49:53 woglinde: looks like this http://thread.gmane.org/gmane.linux.kernel/1015620 Jun 20 13:25:18 florian: it's 18 UTC today, right? Jun 20 13:26:36 mickey|office: yes Jun 20 13:27:53 ok, thanks Jun 20 13:29:10 hi mickeyl Jun 20 13:32:17 hmmm now I've the same issue than before Jun 20 13:32:25 I was told to clean my tmpdir Jun 20 13:32:34 but that issue is still there: Jun 20 13:33:01 | .../sysroots/x86_64-linux/usr/libexec/armv4t-oe-linux-gnueabi/gcc/arm-oe-linux-gnueabi/4.5.4/ld: cannot find -lm Jun 20 13:33:28 told by whom? Jun 20 13:33:47 it's rather hard to know for sure what is going on without more details, but at a first guess I would say that your DISTRO_FEATURES is defective. Jun 20 13:34:13 kergoth, I thikn but I'm not sure Jun 20 13:34:34 gcc-runtime-4.5-r37.1+svnr175127 fails with that Jun 20 13:34:39 distro: shr Jun 20 13:34:47 oe type: oe-core Jun 20 13:34:53 machine: om-gta02 Jun 20 13:35:21 so what is your DISTRO_FEATURES, in fact? Jun 20 13:36:15 I'll bitbake -e to look Jun 20 13:37:08 DISTRO_FEATURES="largefile ipv4 ipv6 wifi ppp ext2 vfat bluetooth usbgadget usbhost eabi tk" Jun 20 13:46:17 does it help if you add libc-libm to that? Jun 20 13:46:24 you'll have to rebuild eglibc as well of course Jun 20 13:50:17 ok Jun 20 13:52:04 GNUtoo: i didn't say cleaning tmpdir would fix any problems, i just suggested it as an alternative means of cleaning out the toolchain, rather than trying to -c clean every component involved, since sstate makes wiping tmpdir less painful Jun 20 13:52:11 heh Jun 20 13:52:33 ok Jun 20 13:54:43 libc-libm libc-libm-big are in: Jun 20 13:54:47 DISTRO_FEATURES_LIBC Jun 20 13:57:12 no doubt Jun 20 13:57:51 morning kergoth, by the way Jun 20 13:58:39 so I add to DISTRO_FEATURES as well? Jun 20 14:03:43 yeah Jun 20 14:04:31 problem found Jun 20 14:04:48 in environment-setup there is export CPATH=$SDK_PATH/$TARGET_SYS/usr/include:$CPATH Jun 20 14:05:22 if $CPATH is unset it becomes CPATH=/usr/local/kaeilos/arm/arm-kaeilos-linux-gnueabi/usr/include: Jun 20 14:05:34 causing a pleny of fixdep: mmap: Cannot allocate memory Jun 20 14:05:44 s/pleny/plenty Jun 20 14:06:22 I wonder why nobody else faced to it Jun 20 14:35:17 ok Jun 20 14:42:04 Hi all Jun 20 14:47:01 I'm using oe-core, and when I set TCLIBC = "uclibc" in local.conf, I get: ERROR: Nothing PROVIDES 'glib-2.0-native' from bitbake Jun 20 14:47:09 Has anyone seen anything similar? Jun 20 15:06:49 Ah... to answer my own question: glib-2.0.inc forces the package to skip if USE_NLS is "no", and tclibc-uclibc.inc sets USE_NLS to "no"... Jun 20 15:07:19 So should I expect TCLIBC = "uclibc" to work at all in oe-core at the moment? Jun 20 16:13:19 ka6sox-work: something is hogging http://www.openembedded.org Jun 20 16:14:33 obi Jun 20 16:44:41 anyone understand what is needed to build external kernel modules in an OE generated SDK? I find that the kernel-headers package (created using kernel's headers_install) package just includes the kernel 'include' subdir, which is not enough. Wondering what ubuntu/debian use instead Jun 20 16:45:12 as they also include Makefile, scripts/... arch/$ARCH/... that are needed in their 'linux-headers' packages Jun 20 17:02:47 RP__ / kergoth: I'm wondering how/if we should deal with naming of layer-related variables Jun 20 17:03:33 some of the changes I'm preparing add new vars; should they continue to use the term COLLECTION as most of our other ones do, or do I use LAYER? Jun 20 17:03:47 if the latter should we be looking to change the others to LAYER as well? Jun 20 17:04:24 maybe it's way too late for that, I don't know Jun 20 17:04:45 pb_, you about/ Jun 20 17:04:46 ? Jun 20 17:10:47 bluelightning: I suspect we should standardise and layer is the preferred term now Jun 20 17:12:08 RP__: perhaps we can "rename" the old vars, and if an old var name is used, still read it but show a warning Jun 20 17:13:23 bluelightning: yes, we probably need to transition like that Jun 20 17:13:40 although most layers would throw a warning atm :/ Jun 20 17:13:51 well yes, I would imagine all would Jun 20 17:14:22 for now, I'll submit my patches using LAYER for all new vars and the old var renaming can be dealt with as a separate patch Jun 20 17:24:26 now it fails at ncurses(thanks a lot for the previous help) in do_configure Jun 20 17:24:32 is oe-core really ready? Jun 20 17:24:53 | ERROR: This autoconf log indicates errors, it looked at host include and/or library paths while determining system capabilities. Jun 20 17:25:26 | checking where we will install curses.h... /usr/include Jun 20 17:25:41 | include directory: /usr/include Jun 20 17:42:03 RP__: I am planning on adding sh3 and mips64 qemu machines I was wondering should they be hosted on separate meta-machine layer Jun 20 17:59:19 florian: Crofton denix in 5 minutes in ##oe-ev-board? Jun 20 18:00:46 ok Jun 20 18:39:29 otavio: you around? Jun 20 18:42:27 bluelightning: sure Jun 20 18:43:03 otavio: fray is looking at debug handling in the qt4 recipes Jun 20 18:44:08 he's wondering if it would be OK to have one single debug recipe (and using the default debug packaging) rather than using splitting it out as much as it is currently with custom code Jun 20 18:44:37 this falls back to an enahcnement made to oe-core a while back (prior to it being oe-core) that we now produce -dbg packages with "associated sources" Jun 20 18:44:40 bluelightning: i guess it would work fine Jun 20 18:44:50 so all of this custom -dbg processing is ignoring the associated sources.. Jun 20 18:44:51 bluelightning: this seems to be the way Debian does it Jun 20 18:45:24 either we need to add even more complexity to attached the associated sources to the already complex -dbg generation.. or move to a recipe-wide -dbg package.. Jun 20 18:45:32 (which is already the standard for 98% of the rest of oe-core) Jun 20 18:45:44 I've got local patches that fix everything except qt... Jun 20 18:47:22 RP__: ping Jun 20 18:49:14 do modern debian system contain -dbg package with associated sources? or just the .debug files? Jun 20 18:49:54 (with the oe-core enhancement, you should be able to debug a system local or cross without having access to anything but the package feeds) Jun 20 18:54:40 * fray thinks it's time for lunch.. only 2pm.. ;) Jun 20 18:54:42 (here) Jun 20 18:58:03 Anyone know how long http://tinderbox.openembedded.org has been down? Jun 20 19:00:26 I'm trying to find help with a problem when baking an image... Jun 20 19:00:34 One of the recipes does not seem to be placing the files into the image and can't figure out why. Jun 20 19:01:12 Wiki is sparse on info and google is not so helpful. Would appreciate any direction. Jun 20 19:02:40 placer14: its been down a long time Jun 20 19:02:51 What image? Jun 20 19:02:57 That was my worry. Jun 20 19:03:07 I'm building a custom image and trying to include the php recipe. Jun 20 19:03:19 However the files are not making it into the image. Jun 20 19:03:39 Well, look over log.do_rootfs Jun 20 19:03:44 and see what package files it installs Jun 20 19:03:44 Is there any information available on bitbake that would help me debug the recipe. Or maybe you have an idea why the files aren't making it. Jun 20 19:03:49 and you can use ar -x to unpack an ipk Jun 20 19:03:56 and see if what you're expecting is in whats installing Jun 20 19:04:07 Thank you. I'll take a look. Jun 20 19:04:12 The package is being created and installed Jun 20 19:04:34 Right, but does it contain what you expect is the question :) Jun 20 19:04:51 So i'll see if the contents are right. However I looked at one of the files generated called "files-in-image.txt" and don't see the files there. Jun 20 19:13:59 I'm still verifying all the created packages, but I'm definitely seeing files which are not making it into the image. Jun 20 19:14:16 Woudl the log.do_rootfs show if the packages are being copied appropriately? Jun 20 19:14:27 Tartarus: ^^^ (thx) Jun 20 19:14:50 yes, it will show what ipk files exactly are being used in the install Jun 20 19:21:23 * bluelightning -> home Jun 20 19:27:37 Tartarus: Alright, so there seem to be packages created which aren't being included as suspected. The packages seem to be fine. Jun 20 19:27:56 Looking at the recipe, it seems to point appropriately to the packages which are missing. Jun 20 19:28:12 I've pulled the lasted from git. Jun 20 19:28:56 Assuming the recipe is correct, is there another log which might indicate why certain packages were skipped? Jun 20 19:29:11 Well, here's the thing Jun 20 19:29:20 I still have to read up on the recipe syntax to verify that it's doing what it should. Jun 20 19:29:24 You've verified that the ipk you expect to be installed has what you want right? Jun 20 19:29:44 Yes, it has the files in it as data/control.tar.gz and a debian-binary Jun 20 19:29:54 And data.tar.gz contains what? Jun 20 19:30:00 What you expected? Jun 20 19:30:06 which the data epands to reflect the filesystem of the image as expected Jun 20 19:30:19 OK Jun 20 19:30:24 So, log.do_rootfs tells you what? Jun 20 19:30:35 that only the main package is being processed Jun 20 19:31:04 The add'l packages in the main recipe bb is being ignored Jun 20 19:31:11 Right Jun 20 19:31:18 So you need to tell your image to install those packages Jun 20 19:31:28 That's expected Jun 20 19:31:30 They need to be explicitly defined? Jun 20 19:31:33 Okay. Jun 20 19:31:34 Yes Jun 20 19:31:45 Bitbake doesn't resolve dependancies? Jun 20 19:31:46 Otherwise what's the point of having multiple packages? Jun 20 19:31:46 ;) Jun 20 19:31:50 It does Jun 20 19:32:01 That's why it didn't install the extra ones, nothing said it depended on the extra packages Jun 20 19:32:33 So there are lines in the recipe which indicate where files should be placed for each package. Jun 20 19:32:39 Right Jun 20 19:32:40 for each dependant package. Jun 20 19:32:55 That isn't a dependancy, just if they are defined to put them there? Jun 20 19:33:33 (If my engrish doesn't make sense, I'll reword it.) Jun 20 19:34:11 I have lines like FILES_${PN}-dbg or FILES_${PN}-doc which have matching packages generated Jun 20 19:34:20 Correct, those aren't dependencies Jun 20 19:34:33 They're just saying that a package will contain the following files, if found Jun 20 19:34:42 Oy Jun 20 19:34:51 If you had RDEPENDS_${PN} += "${PN}-dbg" for example Jun 20 19:35:00 that would make the main package depend on the -dbg package Jun 20 19:35:09 (at runtime, hence RDEPENDS) Jun 20 19:35:20 alright, I do see a few of those directives Jun 20 19:35:38 to do otherwise would be to sacrifice flexibility. emitting a package doesn't imply that that package will end up in any given image Jun 20 19:35:41 RDPENDS_${PN}-doc = "${PN}" Jun 20 19:35:47 for examble Jun 20 19:36:12 that means the -doc will depend on $PN Jun 20 19:36:25 or rather, "required by" Jun 20 19:38:44 It means the -doc will require the main Jun 20 19:47:26 Tartarus: Thanks for the clarification. I'll continue playing around. Jun 20 21:25:13 Tartarus: That helped immensely! Thank you again! Jun 21 00:04:41 guh, debian maintains their initscripts and update-rc.d script both within sysvinit's source tree? Jun 21 00:04:42 * kergoth sighs Jun 21 00:05:49 and the upstream sysvinit svn repo only goes back to 2.88, no further history than that Jun 21 00:51:39 i'm starting to regret taking this in scm thing on as a side project **** ENDING LOGGING AT Tue Jun 21 02:59:56 2011