**** BEGIN LOGGING AT Tue Sep 04 02:59:58 2012 Sep 04 05:59:05 hi, i have problem building OE regardless of whether i use oe, or oe-core, both try to rewrite system include /usr/include/limits.h. have i misconfigured something? Sep 04 05:59:19 don't build as root, ever. Sep 04 05:59:41 i dont build as root so build fails there Sep 04 06:04:12 it seems that i have far too new make Sep 04 06:10:39 * kergoth has never even heard of that behavior before, much less actually encountered it, and does builds every day for numerous machines. shrugs Sep 04 07:00:54 kergoth: there are many reports eglibc failing to cross-compile with make 3.82 Sep 04 07:01:45 maybe most of "sane" distros still use make 3.81 Sep 04 07:19:48 hi guys i'm having trouble crosscompiling glib here Sep 04 07:19:52 checking alignment of guint32... configure: error: in `/dream/glib232_oe/tmp/work/mips32el-oe-linux/glib-2.0/glib-2.0-1_2.32.3-r2/glib-2.32.3': Sep 04 07:19:52 configure: error: cannot compute alignment of guint32 Sep 04 07:50:13 good morning Sep 04 07:52:51 pb_: good morning, hey didn't you want to stop-by in Frankfurt some weeks ago? Sep 04 08:35:43 morning all Sep 04 08:35:51 bluelightning: hi Sep 04 08:36:23 is it just me or have a bunch of my emails to the OE-Core list been delayed? Sep 04 08:38:22 bluelightning: considering response.. my email are delayed or not delivered at all Sep 04 08:38:40 hmm, I guess there is some server load issue Sep 04 08:38:52 waiting >month for udev-extraconf patch to get meta-openmoko parsing again with oe-core HEAD Sep 04 08:39:44 florian: ping, any ideas? Sep 04 08:40:01 JaMa: Just seen your wrt request for the python-efl 1.7 tarballs. Gustavo is doing it for the final release. Hopefully today or tomorrow. Sep 04 08:40:38 stefan_schmidt_w: I've asked 3 times, good you're first one to reply :) Sep 04 08:40:56 stefan_schmidt_w: I gave up and sent pull-request without python bindings yesterday Sep 04 08:41:11 JaMa: yeah, sorry for that. Somehow fall though my cracks ;) Sep 04 08:41:22 JaMa: :( Sep 04 08:41:30 stefan_schmidt_w: seems like scrolling get broken between -beta and 1.7.0 :/ Sep 04 08:41:34 JaMa: But you can do another one once we have the tarballs Sep 04 08:41:45 JaMa: ugh Sep 04 08:41:55 stefan_schmidt_w: http://www.shr-project.org/trac/ticket/2056 Sep 04 08:41:57 JaMa: Scrolling in what? genlist? Sep 04 08:42:16 I don't know yet.. just seen this bug report and haven't looked myself yet Sep 04 08:42:40 JaMa: hmm, okay. Elfe is using elm IIRC Sep 04 08:42:53 So it might be in elm :( Sep 04 08:43:19 stefan_schmidt_w: and it's only in elfe... intone (also elm) too http://lists.shr-project.org/pipermail/shr-devel/2012-September/004146.html Sep 04 08:44:39 JaMa: hmm, let me check elementary_test here Sep 04 08:52:35 g morning all Sep 04 09:13:27 JaMa: Sorry, took some time as I completely screwed my e config by switching to mobile Sep 04 09:13:42 JaMa: tested with the mobile elm profile here and scrolling works fine Sep 04 09:14:23 JaMa: And it broke surely between beta and final? Sep 04 09:15:44 we were using beta and alpha before since they were released and the report arrived only after upgrade to 1.7.0 Sep 04 09:16:48 JaMa: hmm Sep 04 09:17:27 stefan_schmidt_w: can you join #openmoko-cdevel ? someone says he knows solution for this Sep 04 09:17:39 stefan_schmidt_w: and it's probably issue with our profile Sep 04 09:17:54 done Sep 04 09:40:45 morning all Sep 04 09:41:47 mickeyl: yeah, that plan never quite came to fruition in time. we have a new baby daughter now (Sophie, age 2.5 weeks) so probably not going to be practical to travel in the near future. Sep 04 09:42:07 hi pb_ Sep 04 09:42:13 hi silvio Sep 04 09:42:20 hi bluelightning Sep 04 09:42:37 hi bluelightning Sep 04 09:42:43 hi pb_ Sep 04 09:45:58 does anybody have an idea how to fix this? checking alignment of guint32... configure: error: in `/dream/glib232_oe/tmp/work/mips32el-oe-linux/glib-2.0/glib-2.0-1_2.32.3-r2/glib-2.32.3':configure: error: cannot compute alignment of guint32 Sep 04 09:46:59 missing site file entry, maybe? Sep 04 09:47:41 though, it seems to be in mips-common, so why you aren't getting that is a bit of a mystery. **** ENDING LOGGING AT Tue Sep 04 10:09:37 2012 **** BEGIN LOGGING AT Tue Sep 04 10:12:19 2012 Sep 04 10:52:43 hi guys Sep 04 10:53:00 I am trying to do do_prepare_release[depends] += "${MEL_RELEASE_IMAGE}:do_build" Sep 04 10:53:09 do_prepare_release[depends] += "${MEL_RELEASE_IMAGE}: do_build" Sep 04 10:53:59 but when I get the graph of the recipe I cant see my image recipe do_build task under do_prepare_release Sep 04 10:54:26 but when I change do_build to do_rootfs i can see that task in the graph Sep 04 10:54:36 is there something special with do_build? Sep 04 11:01:08 looks like we cant add do_build task in one's depends .... is that correct? Sep 04 11:01:22 if yes what is the reason behind it Sep 04 11:31:31 something is going over there with do_build in task depends Sep 04 12:45:44 bluelightning: ping Sep 04 12:45:54 hi Noor Sep 04 12:46:03 hello bluelightning lighting Sep 04 12:46:20 sorry to bother you directly Sep 04 12:46:40 do you have any comment on the problem I wrote earlier Sep 04 12:47:00 Noor: no problem, but unfortunately I don't know the answer I'm afraid Sep 04 12:47:02 right now I am digging in bitbake code :( Sep 04 12:47:27 that means I have to dig it myself :) Sep 04 12:47:28 the question is why do you want a dependency on do_build? Sep 04 12:47:41 do_build itself doesn't do anything Sep 04 12:47:58 basically we created a release recipe Sep 04 12:49:25 bluelightning: previously in image.bbcalss EXTRA_IMAGEDEPENDS was added in do_rootfs but recently it was changed and now EXTRA_IMAGEDEPENDS are added in do_build depends Sep 04 12:49:48 hmm, I'm not sure then... Sep 04 12:50:04 so not release recipe needs to depend on image do_build instead of do_rootfs Sep 04 12:50:22 hhhmmm thanks bluelightning Sep 04 13:08:55 someone could explain me difference between BSPLAYERS, BBLAYERS and BASELAYERS? Sep 04 15:01:07 in oe core there is some timeout for packet fetching? Sep 04 15:01:46 yes Sep 04 15:01:54 silvio_: check wget in bitbake.conf Sep 04 15:03:09 It seams no for me ... now check, but i m using git Sep 04 15:03:12 JaMa: can you test paule/packagegroup-fixes OE-Core contrib branch? Sep 04 15:03:20 JaMa: to check I haven't missed anything Sep 04 15:03:34 bluelightning: I'm using only 3 oe-core tasks on target, but yes Sep 04 15:03:56 JaMa: no worries, thanks Sep 04 15:08:09 bluelightning: there was also task-xserver in meta-oe before Sep 04 15:08:18 so it should R* also that Sep 04 15:08:33 previously, using oe classic, to interrupt bitbake I use only ctrl^C Sep 04 15:08:52 now with oe-core I need to removefile bitbake.lock? Sep 04 15:08:54 JaMa: oh, I got the name wrong Sep 04 15:08:58 bluelightning: and for met to test it would you mind adding also packagegroup-x11-* for meta-oe entries? Sep 04 15:08:58 silvio_: no Sep 04 15:09:00 I m rigth? Sep 04 15:09:05 bluelightning: no, both should be there Sep 04 15:09:15 silvio_: it is only paid attention to when it points to a running PID Sep 04 15:09:32 JaMa: really?! Sep 04 15:09:38 yes Sep 04 15:10:06 actually all 3 if todays patches to meta-oe (replace to packagegroup) get applied before this Sep 04 15:10:23 ok... but we really need to avoid adding anything like this mess in future... Sep 04 15:10:45 its present after i kill the job Sep 04 15:11:36 bluelightning, now ctrl^C doenst terminate bitbake Sep 04 15:11:51 silvio_: what do you mean? it does for me here... Sep 04 15:12:06 silvio_: sometimes it takes long Sep 04 15:12:16 silvio_: (e.g. when git is running on background) Sep 04 15:12:31 bluelightning: yes, package renames are messy Sep 04 15:12:43 bluelightning: maybe it wasn't worth renaming to packagegroup.. Sep 04 15:12:47 ah ok, because in the oe-classic, was almost istantaneous Sep 04 15:12:53 JaMa: what I mean is, with OE-Core we have the possibility to tidy things up Sep 04 15:13:01 ok thanks Sep 04 15:13:22 JaMa: we shouldn't just add things that aren't cleaned up to meta-oe on the assumption they will be cleaned up in future Sep 04 15:13:33 silvio_: ^C once means shut down cleanly, wait for runnning tasks to finish. ^C again after that will terminate the running tasks. it's always worke that way, even in classic Sep 04 15:14:26 bluelightning: those things were clean until it was changed in oe-core.. Sep 04 15:16:01 JaMa: I'm confused, how did you have task-x11-server and task-xserver? Sep 04 15:16:09 bluelightning: I mean task-x11 as well as task-xserver existed in meta-oe Sep 04 15:17:00 it was split to 2 recipes later to make only one MACHINE_ARCH and exclude it as ABISAVE from siggen Sep 04 15:17:21 so, there was no task-xserver package, just an RPROVIDES Sep 04 15:19:25 JaMa: ok I've pushed a new branch with the extra RPROVIDES Sep 04 15:19:52 bluelightning: http://git.openembedded.org/meta-openembedded/commit/?id=8f79297046d8bda340ebf00d004d44288dae93ee Sep 04 15:19:59 bluelightning: http://git.openembedded.org/meta-openembedded/commit/?id=bdf3f45012e218aac93b494136965ede6d32f212 Sep 04 15:20:28 so yes it was partially to provide upgrade path for meta-angstrom users Sep 04 15:21:06 right, but only a build-time upgrade path Sep 04 15:21:32 oh well, it's not really important Sep 04 15:21:50 and 28db5ce99e119171f788dfb3d810382be98e815b in meta-angstrom Sep 04 15:21:52 the important thing is that we provide the appropriate upgrade path for the current change Sep 04 15:23:56 I still see only task-x11-* in your updated branch Sep 04 15:25:47 Multiple replacers for task-x11-illume, using first one (packagegroup-x11-illume). Sep 04 15:26:06 hmm, intereging, there should be just one Sep 04 15:26:15 JaMa: sorry, I don't understand what I've missed... Sep 04 15:27:59 ok I soved, in chroot i forgot to add fingerprint of my RSA at the System, and i dind't receive message, so I though something was freezed Sep 04 15:30:10 bluelightning: packagegroup-x11-* Sep 04 15:30:26 bluelightning: if my patch gets applied to meta-oe, before yours in oe-core Sep 04 15:30:45 bluelightning: then some users can already upgrade to packagegroup-x11-server from meta-oe Sep 04 15:31:58 JaMa: where does packagegroup-x11-* come from? Sep 04 15:32:07 oh no you can't be serious Sep 04 15:32:08 no Sep 04 15:32:18 the answer is to fix these in lock-step or not at all Sep 04 15:33:09 yes I meant from meta-oe Sep 04 15:33:48 ok I'll ask koen to hold that patch Sep 04 15:34:15 that seems like the best approach Sep 04 15:34:19 IMHO Sep 04 15:35:38 well meta-oe does not even parse now.. so yes nobody will probably build it now Sep 04 15:35:51 right... Sep 04 15:36:06 but I cannot test upgrade path anymore Sep 04 15:36:10 to be honest I was expecting to have more time to produce a patch for meta-oe myself, but timescales haven't allowed for that Sep 04 15:36:21 all my installed targets are already upgraded to packagegroup-x11-* Sep 04 15:37:49 JaMa: ok, well I think this mechanism is fairly well understood now... I can send my series and if you change your patches to just remove task-x11* they will line up Sep 04 15:38:30 I should go for lunch first Sep 04 15:38:58 JaMa: ok, np... thanks for your patience on this one Sep 04 15:39:17 It is possible build a packet without a "COPYING" file? Sep 04 15:40:17 silvio_: you do need to set LIC_FILES_CHKSUM Sep 04 15:43:21 I did, it is empty now, but BB does not like it, it is possible forcing it empty? Sep 04 15:44:05 silvio_: is the recipe for something open source? Sep 04 15:47:07 nope Sep 04 15:47:47 but i still dont know the license Sep 04 15:50:04 silvio_: if it's closed source / proprietary you can set LICENSE = "CLOSED" Sep 04 15:50:09 but *only* if that Sep 04 15:50:31 in which case the LIC_FILES_CHKSUM check will not be performed Sep 04 15:51:02 otherwise you do need to point to a license file somewhere Sep 04 15:51:17 the idea is, if the upstream changes the license you want to detect that Sep 04 15:51:37 ok thanks, software is in development until now license is not done, but probably will be closed :( Sep 04 15:51:56 silvio_: ok, that's fine, in which case LICENSE = "CLOSED" is valid Sep 04 15:52:39 bluelightning, I try LICENSE = Commercial, now i try your way Sep 04 15:53:24 bluelightning: you should split x11-server from packagegroup-core-x11.bb like meta-oe did Sep 04 15:53:32 bluelightning: XSERVER variable depends on MACHINE Sep 04 15:53:49 while x11 and x11-utils can be allarch Sep 04 15:54:00 bluelightning, thanks u always right ;) Sep 04 15:54:12 JaMa: is there any major value in that? Sep 04 15:55:06 yes, it does not rebuild for each machine switch Sep 04 15:55:40 and it should be added to SIGGEN_EXCLUDERECIPES_ABISAFE Sep 04 15:55:40 we're talking about a package group though, it's almost negligible Sep 04 15:56:18 problem is that this recipe says MACHINE_ARCH which is right, but any other recipe which RDEPENDS on task-x11-server depends on sstate checksum Sep 04 15:56:57 so it makes e.g. task-efl-something also rebuilding after each machine switch even with "inherit allarch" Sep 04 15:57:01 and that's just wrong Sep 04 15:57:59 don't we have a mechanism to avoid that rebuilding? Sep 04 15:58:15 yes SIGGEN_EXCLUDERECIPES_ABISAFE Sep 04 15:58:27 that's what is used in meta-oe for task-x11-server Sep 04 15:58:44 right, so why can that not be used here without having to split the recipe? Sep 04 15:58:56 but better to exclude smallest part possible -> that's why it was split Sep 04 16:00:21 as I said, we're talking about a package group recipe which takes almost no time to rebuild; unless you're suggesting this rebuild affects packages that the package group depends upon? Sep 04 16:00:53 no but it causes rebuilds of recipes which rdepends on this package group Sep 04 16:04:31 JaMa: I'm clearly missing something here... what is the issue with adding packagegroup-core-x11 to SIGGEN_EXCLUDERECIPES_ABISAFE ? Sep 04 16:06:00 ah, no, that will not work Sep 04 16:07:14 it would have been good to have this feedback earlier... Sep 04 16:08:23 then don't merge such invasive changes 1 day after they were sent to ML.. Sep 04 16:08:30 JaMa: I didn't merge them... Sep 04 16:08:46 I know.. Sep 04 16:09:07 I do however need to make whatever clean ups are necessary Sep 04 16:09:45 so what you're saying is, we can't replace the meta-oe recipes without splitting packagegroup-core-x11 Sep 04 16:09:48 ? Sep 04 16:10:26 we can, but that split was intentional in meta-oe and I don't like the idea to revert it just because it doesn't take so much time to rebuild them Sep 04 16:11:33 and that split is quite easy now without any need to change RPROVIDES/RREPLACES/RCONFLICTS in oe-core Sep 04 16:12:09 and packagegroup-core-x11 can have default PACKAGE_ARCH then Sep 04 16:14:04 it makes more sense to me, than standalone packagegroup-core-x11-base.bb Sep 04 16:15:13 or task-core-x11-mini whatever it was Sep 04 16:29:25 JaMa: I'm afraid I can't rush the split in right now Sep 04 16:30:14 JaMa: could you propose this split for OE-Core on the mailing list? Sep 04 16:30:37 in the mean time I can submit my other changes, leaving out the 3/3 patch to do the replacement of the meta-oe recipes Sep 04 16:33:02 bluelightning: sorry not now, fixing other things Sep 04 16:33:15 JaMa: at this point it's not urgent Sep 04 16:34:20 should I send patch to split it? Sep 04 16:34:38 it's easier then describe it again (without copy pasting our discussion) Sep 04 16:35:37 JaMa: well the patch would need to have the case properly made in the commit message, so it makes little difference... Sep 04 16:37:21 bluelightning: so what's the point of split between packagegroup-core-x11-base.bb packagegroup-core-x11.bb ? Sep 04 16:38:09 JaMa: that's to not have to build the things that depends upon if you don't need those things at all Sep 04 16:39:06 i.e. things that need actual compilation... it's a small list to be sure, but not insignificant Sep 04 16:56:34 Is it possible to expand expressions with the @ syntax? For example, I want something like Sep 04 16:56:36 DEPENDS = "${$bb.data.getVar('PN',d,1).replace('foo','far') if bb.data.getVar('PN',d,1).endswith('baz')}" Sep 04 16:58:28 bluelightning: http://bpaste.net/show/43746/, I can add it to your branch if you like it Sep 04 17:00:17 JaMa: you need to be much more descriptive in the commit message than that; it needs to start with "split packagegroup-x11-server out into a separate recipe..." mentioning recipes that are affected, that this will help replace the recipes in meta-oe, etc. Sep 04 17:01:48 I still trouble with OE-core and qwt, someone have erros about this: Sep 04 17:01:58 /home/oe-core/build/out-eglibc/work/armv7a-vfp-angstrom-linux-gnueabi/qwt-6.0.1-r0/qwt-6.0.1/examples/../lib/libqwt.so: error: undefined reference to 'clock_gettime' Sep 04 17:01:58 | /home/oe-core/build/out-eglibc/work/armv7a-vfp-angstrom-linux-gnueabi/qwt-6.0.1-r0/qwt-6.0.1/examples/../lib/libqwt.so: error: undefined reference to 'clock_getres' Sep 04 17:02:03 mario-goulart: replace the second $ with @, that ought to work Sep 04 17:02:51 bluelightning: jesus christ. What have I done Sep 04 17:03:20 bluelightning: packagegroup-core-x11: split machine specific parts to separate recipe packagegroup-core-x11-server ? Sep 04 17:03:45 JaMa: s/machine specific/possibly machine specific/ Sep 04 17:04:54 JaMa: there may be some sstate issues with declaring machine-specific recipes as ABISAFE btw, I've not looked into it closely though Sep 04 17:06:26 mario-goulart: with recent bitbake versions that should be d.getVar rather than bb.data.getVar also Sep 04 17:07:57 bluelightning: ah, thanks. I'm using bitbake 1.15.1 here. Sep 04 17:08:33 mario-goulart: right, then d.getVar is the preferred method Sep 04 17:08:50 bluelightning: qemu machines defines XSERVER so it's always depending on MACHINE var Sep 04 17:08:58 bluelightning: Alright, thank you. Sep 04 17:10:23 JaMa: that doesn't mean XSERVER is intrinsically a machine variable Sep 04 17:11:30 for sstate it does AFAIK Sep 04 17:12:28 I get "ERROR: Failure expanding variable RDEPENDS, expression was ${@d.getVar('PN',d,1).replace('osca-','ossa-') if not d.getVar('PN',d,1).endswith('terminal')} which triggered exception SyntaxError: unexpected EOF while parsing (RDEPENDS, line 1)" Sep 04 17:12:50 I wonder what syntax rule I'm screwing. Sep 04 17:13:08 The exact line I've added is: Sep 04 17:13:09 RDEPENDS = "${@d.getVar('PN',d,1).replace('osca-','ossa-') if not d.getVar('PN',d,1).endswith('terminal')}" Sep 04 17:13:28 why are you passing 'd' Sep 04 17:13:47 looks like an incorrect conversion from bb.data.getVar Sep 04 17:14:00 d.getVar('PN' True) Sep 04 17:14:01 and you probably want RDEPENDS_${PN} Sep 04 17:14:03 should be enough Sep 04 17:14:43 JaMa: it's actually a .inc which performs several hacks Sep 04 17:15:14 khem: but would that cause a syntax error? Sep 04 17:16:09 mario-goulart: and? Sep 04 17:16:56 JaMa: usually I want RDEPENDS to contain 'ossa-foo' if PN is osca-foo, except when PN is osca-terminal (there is no ossa-terminal). Sep 04 17:18:02 mario-goulart: and you want that for PN or also PN-dev PN-dbg etc? Sep 04 17:18:09 JaMa: sorry, maybe I misunderstand you suggestion. You mean I should simply use RDEPENDS_${PN} instead of RDEPENDS? Sep 04 17:18:18 yes Sep 04 17:18:40 Ah, ok. Sep 04 17:19:13 What about the syntax error? It seems that I'm violating some syntax rule. Sep 04 17:20:03 well, first of all, that line has a logic flaw, it'll end up with rdepends set to 'None' if PN doesn't end with terminal Sep 04 17:20:09 you have no else for your conditioanl Sep 04 17:20:29 second, it really sounds like what you want is an anonymous python block, not iuinline python Sep 04 17:21:38 kergoth: good catch. Sep 04 17:23:23 but no, i don't see an obvious syntax failure there, that error doesn't make a great deal of sense Sep 04 17:27:21 kergoth: what would an anonymous python block be? If it is anonymous and not inline, how can I reference it? Sep 04 17:29:18 python () { Sep 04 17:29:19 } Sep 04 17:29:28 grep around, they're everywhere Sep 04 17:29:31 bb Sep 04 17:29:45 you don'jt need to reference it, because it gets automaitcally run at the end of teh recipe parsing, around the same time as the RecipeParsed event is fired Sep 04 17:30:33 kergoth: ah, ok. Thank you. Sep 04 17:33:27 bluelightning: RREPLACES/RCONFLICTS are missing in ./meta/recipes-core/packagegroups/packagegroup-base.bb Sep 04 17:33:39 or I don't see them Sep 04 17:42:46 JaMa: argh I missed those because they are added in code Sep 04 17:42:50 will fix up now Sep 04 18:06:44 JaMa: done Sep 04 18:06:50 bbl Sep 04 19:19:06 this recipe isn't working for me: https://github.com/openembedded/meta-oe/blob/master/meta-oe/recipes-devtools/nodejs/nodejs_0.6.20.bb Sep 04 19:19:25 I get this error: https://gist.github.com/3624889 Sep 04 19:19:36 is this the right place to ask? Sep 04 19:23:00 bewest: try to -c cleansstate it first Sep 04 19:23:07 seems like broken archive in sstate-cache Sep 04 19:23:37 -c cleanstate nodejs-native # or nodejs ? Sep 04 19:23:42 or both Sep 04 19:23:51 still wrapping my brain around all this Sep 04 19:24:19 cleansstate/cleanstate/? Sep 04 19:28:13 nodejs-native & cleansstate Sep 04 19:29:03 yeah, same Sep 04 19:29:32 ERROR: Error executing a python function in /home/bewest/src/beagle-board-setup-scripts/sources/meta-openembedded/meta-oe/recipes-devtools/nodejs/nodejs_0.6.20.bb: Sep 04 19:29:33 CalledProcessError: Command 'tar -cf - -C /home/bewest/src/beagle-board-setup-scripts/build/tmp-angstrom_v2012_05-eglibc/work/x86_64-linux/nodejs-native-0.6.20-r0/sysroot-destdir///home/bewest/src/beagle-board-setup-scripts/build/tmp-angstrom_v2012_05-eglibc/sysroots/x86_64-linux -ps . | tar -xf - -C /home/bewest/src/beagle-board-setup-scripts/build/tmp-angstrom_v2012_05-eglibc/sysroots/x86_64-linux' returned non-zero exit status 2 with output tar: /home/bewes Sep 04 19:30:53 with cleansstate Sep 04 19:31:40 cleansstate fails like this? Sep 04 19:31:54 or build after that? Sep 04 19:32:18 you can get that broken archive from some SSTATE_MIRROR if you're using it Sep 04 19:35:44 no Sep 04 19:35:48 cleansstate succeeds Sep 04 19:36:53 cleansttate nodejs-native success. nodejs-native then fails at the same point with the same error after recompiling Sep 04 19:37:09 and it looks like some important directories are empty Sep 04 19:37:14 /src/beagle-board-setup-scripts/build/tmp-angstrom_v2012_05-eglibc/work/x86_64-linux/nodejs-native-0.6.20-r0$ find sysroot-destdir/ Sep 04 19:37:24 sysroot-destdir/ and image/ are both empty Sep 04 19:41:21 remove SSTATE_MIRROR, cleansstate again and try again Sep 04 19:43:22 oh, sorry remove from where? the nodejs-.bb recipe? Sep 04 19:44:38 I don't have any, I believe Sep 04 19:45:06 bewest: it can be in distro config or local.conf or something like that Sep 04 19:45:22 yeah, I'm looking in my local.conf at setup-scripts level Sep 04 19:45:29 where else can I check Sep 04 19:45:43 you can also check if nodejs-native exists somewhere in sstate-cache dir Sep 04 19:45:54 meta-angstrom etc as I said Sep 04 19:46:26 if I find one in sstate-cache dir, I should try deleting? Sep 04 19:46:58 bewest: it's deleted by cleansstate but if you have SSTATE_MIRROR then it could be downloaded for you Sep 04 19:50:15 :~/src/beagle-board-setup-scripts/sources$ for x in ./* ; do test -d $x && (cd $x; git grep SSTATE_MIRROR); done Sep 04 19:50:21 pretty sure I don't have anything set Sep 04 19:53:33 pretty sure I've descended to all the itneresting places Sep 04 19:53:37 I can't find anything like that Sep 04 20:09:49 where does this tar command get produced Sep 04 20:12:12 hi Sep 04 20:12:53 is there a current summary of how meta-systemd should work? E.g. to make images use systemd? Right now it is difficult to build a sysvinit/udev and systemd image at the same time Sep 04 20:13:55 zecke: there is not IMAGE scope switch Sep 04 20:14:17 zecke: it's possible to set few DISTRO scope variables to select right tasks/providers Sep 04 20:14:33 that doesn't make sense. what was the pint of splitting out the -systemd packages for everything if they can't be easily installed? Sep 04 20:14:44 if it requires a rebuild, then there was no point to any of that Sep 04 20:15:03 agreed Sep 04 20:15:41 but at least now some people can use meta-oe without meta-systemd layer Sep 04 20:16:57 kergoth: moving /sbin/int with its u-a to separate recipe could help Sep 04 20:17:00 init Sep 04 20:19:24 JaMa: sorry, my point was that systemd now provides udev, which does not install the sysvinit script. Sep 04 20:20:19 JaMa: a) I set PREFERRED_PROVIDER_udev = "systemd" then sysvinit images will not have a sysvinit script for udev Sep 04 20:20:37 JaMa: b) I set PREFERRED_PROVIDER_udev = "udev" and then systemd is not buildable. :) Sep 04 20:21:20 so I wonder what I am missing. Sep 04 20:24:30 ah yes use systemd as PREFERRED_PROVIDER_udev only for systemd images where you don't need sysvinit script Sep 04 20:30:08 from inside the image? this feels a bit odd. Sep 04 20:31:31 no in distro config Sep 04 20:31:57 that means a distro can only build one kind of image? Sep 04 20:32:18 i have a recovery image that requires udev but has a tiny startscript Sep 04 20:32:19 yes Sep 04 20:32:56 JaMa: were the implications discussed? Sep 04 20:33:03 but fwiw you can use PREFERRED_PROVIDER_udev = "udev" with systemd image too Sep 04 20:33:13 zecke: yes, few times Sep 04 20:33:33 JaMa: see b). bitbake systemd will not work. :) Sep 04 20:33:48 (or didn't work) Sep 04 20:33:54 why? Sep 04 20:34:23 it worked fine (at least with slightly older systemd) Sep 04 20:34:50 but you have to cleansstate old provider from sysroot manually after switch Sep 04 20:35:09 also libudev .so name was changed so you have to clean stuff rdepending on that Sep 04 20:35:58 ERROR: Multiple .bb files are due to be built which each provide udev (/data/sysmocom/customer/generic/poky/meta-oe/meta-systemd/recipes-core/systemd/systemd_git.bb /data/sysmocom/customer/generic/poky/meta/recipes-core/udev/udev_164.bb). **** ENDING LOGGING AT Wed Sep 05 02:59:59 2012