**** BEGIN LOGGING AT Wed Apr 11 02:59:58 2012 Apr 11 05:52:19 <_tasslehoff_> a bit offtopic, but do any of you compile on a laptop and feel good about it? Apr 11 05:53:09 <_tasslehoff_> my dell laptop overheats and shuts down when I compile my rootfs, so I'm looking for a new pc. oe-core is the heaviest work it's likely to be doing Apr 11 09:09:06 morning all Apr 11 09:26:24 morning pb_, all Apr 11 09:32:59 hi bluelightning Apr 11 10:11:42 hi pb_ and bluelightning Apr 11 10:11:51 hi Noor Apr 11 10:12:04 bluelightning: hw ru doing? Apr 11 10:12:16 Noor: good thanks and you? Apr 11 10:12:29 bluelightning: perfectly fit Apr 11 10:13:17 bluelightning: just wrote a blog entry for how stuff is moved to buildfolder/deploy/image folder Apr 11 10:13:25 I'll share with u in few min Apr 11 10:24:47 bluelightning: http://noorahsankhawaja.blogspot.com/2012/04/ins-and-out-of-sstate-part-1.html Apr 11 10:30:03 bluelightning: dont know u need it now or not but just in case u still interested in how stuff is being moved to buildfolder/deploy/images folder Apr 11 10:35:15 Noor: great stuff, thanks! Apr 11 11:56:41 hi, if I wanted to include opkg-utils in a SDK would a .bbappend that does BBCLASSEXTEND += "nativesdk" and including opkg-utils-nativesdk in the task-sdk-host RDEPENDS be enough? Apr 11 14:44:01 when trying to us oe_filter_out on the variable RDEPENDS_${PN} I get: "SyntaxError: EOL while scanning string literal", anyone else seen that? Apr 11 14:44:45 The line is: RDEPENDS_${PN} := "${@oe_filter_out('qemu-nativesdk', ${RDEPENDS_${PN}}, d)}" Apr 11 15:11:18 jonasdn: I think ${RDEPENDS_${PN}} should be quotes too on RHS '${RDEPENDS_${PN}}' Apr 11 18:00:31 Hello Apr 11 18:03:02 in the process of compiling a package for the jlime distribution I patched opkg-utils' recipe Apr 11 18:05:51 can I send a patch to oe-devel, knowing that it's a patch for oe-classic ? Apr 11 18:05:51 s/can/should/ Apr 11 18:31:48 apelete_ look at the ml Apr 11 18:31:59 there are serval patches send for oe-classic Apr 11 18:34:40 woglinde: are the patches beginning with [oe] on the subject line in the ml are targeting oe-classic ? Apr 11 18:35:11 I see a lot of [oe] and [meta-oe] (oe-core I assume) patches Apr 11 18:36:08 (I am receiving the ml messages since the beiginning of this month) Apr 11 18:39:17 look at the archive Apr 11 18:39:41 [oe] should be okay Apr 11 18:40:33 ok, thanks Apr 11 18:42:13 actually I brought the opkg-utils recipe from oe-core to oe-classic since the recipe found in oe-classic was outdated (I started by patching the recipe myself, then I realised that there was a wroking one in oe-core) Apr 11 18:43:23 and I would like to submit the change. I am going to send the patch to the ml then. Apr 11 19:13:50 During do_rootfs, I have an error creating a symlink to volatile/run. How can I figure out which package is causing the error? Apr 11 19:14:09 Here's the last ~10 lines of the error log http://pastebin.com/sb6N6Rrs Apr 11 19:15:55 the system should have detected this and cleaned it up in some way during the build.. Apr 11 19:16:13 I dont now how to debug it with ipkg or deb packages.. w/ RPM it's fairly easy to figure out what happened.. Apr 11 19:16:27 you query all of the packages, checking for the file types and paths and see if you can figure out what generated the bad one.. Apr 11 19:16:36 if you can figure this out, we can fix the package generate helper to avoid this Apr 11 19:16:55 So I should grep for volatile, or something like that? Apr 11 19:17:06 meta/files/fs-perms.txt should be used to avoid this.. Apr 11 19:17:30 it looks like either volatile or volatile/run already exists as either a file or directory.. so it can't become a symlink Apr 11 19:17:43 Right. Apr 11 19:17:49 meta-files/fs-perms.txt ${localstatedir}/run link volatile/run Apr 11 19:18:12 that is what should, in the end, generate the link... code should also have verified that the link could be created, but maybe we missed something in the checking? Apr 11 19:18:23 if you can figure out the bad package(s), I'd love to know what exactly is triggering this Apr 11 19:18:50 My hunch is that it's dbus. Apr 11 19:19:08 dbus has done other stupid things before, so likely not a bad guess.. ;) Apr 11 19:19:22 See this discussion from a few weeks ago: http://comments.gmane.org/gmane.comp.handhelds.openembedded.core/15659 Apr 11 19:19:36 Has anyone seen the following, and know what it means? Apr 11 19:19:41 WARNING: Setscene task 65 (/home/usr2/oe-core/meta/recipes-devtools/qemu/qemu-helper-native_1.0.bb, do_populate_sysroot_setscene) failed with exit code '1' - real task will be run instead Apr 11 19:20:36 ya, the answer to that question -- it's a file conflict.. two packages (or more) are generating two files with different contents.. Apr 11 19:20:43 one is a symlink and one is a file or directory.. Apr 11 19:20:53 finding the mismatch is the first step to debug and figure out the underlying cause.. Apr 11 19:21:21 fs-perms.txt was put into place to avoid this behavior.. obviously you found either a bug in fs-perms handling.. or a package that is doing something that is causing hte issue Apr 11 19:22:28 fray: do I understand correctly that if fs-perms.txt is working right, recipes should never be creating their own symlinks? Apr 11 19:22:48 (at least in the /var/run volatile/run area) Apr 11 19:22:48 they can create a link, directory, etc.. fs-perms.txt should discover this, and then fix them Apr 11 19:23:08 Ah, fs-perms is just adjusting permissions? Apr 11 19:23:11 so if a package does mkdir /var/volative/run ; fs perms handling should fix that to be a symlink Apr 11 19:23:21 ya.. it adjusts and synchronises the distro files to avoid this type of error. Apr 11 19:23:35 thats why either we have an uncaught condition, a bug in fs-perms (or a recipe doing something it shouldn't) Apr 11 19:23:40 Adjusting permissions and enforcing symlinking. Apr 11 19:23:52 OK, that makes sense. Apr 11 19:23:59 yup Apr 11 19:24:31 I'll try knocking out some suspicious packages (I'm looking at you, dbus) and rebuilding. Apr 11 19:24:44 be sure to backup the old versions.. Apr 11 19:24:53 people have fixed it by selectively rebuilding, but I'd love to know what went wrong Apr 11 19:25:17 so far we've never gotten a chance to figure out where it went wrong.. I've seen maybe 5 reports of this since fs-perms was implemented Apr 11 19:25:37 Yeah, OK. I need to be able to build this more than once, so I'll see if I can dig out the root cause. Apr 11 19:25:49 Do you know where fs-perms.txt is parsed? Apr 11 19:26:23 package.bbclass? Apr 11 19:26:29 ya.. it's in meta/classes/sanity.bbclass -- I think.. might be pacakge.bbclass Apr 11 19:26:40 OK, that narrows it down. Apr 11 19:27:30 It's package.bbclass, just for the record. Apr 11 19:27:44 chunk of code to read the file, chunk of code that uses that and iterates over the filesystem fixing bits.. Apr 11 19:28:01 it is package.bbclass, just verified Apr 11 21:46:12 florian: ping Apr 11 21:46:30 JaMa: pong Apr 11 21:46:40 florian: do you still care about gpe's xserver-common? Apr 11 21:47:02 JaMa: yes a little bit Apr 11 21:47:21 can I send you pull request with patches we currently have in meta-oe? Apr 11 21:47:32 hmm; how can I slip an environment variable into a build? Apr 11 21:47:59 CMoH: add it to BB_EXTRA_WHITE or some var like that IIRC Apr 11 21:48:02 i mean in the do_configure task i run some stuff that should fetch an environment variable from outside bitbake Apr 11 21:48:33 well, BB_ENV_EXTRAWHITE makes it available in the .bb recipe Apr 11 21:48:43 but not within the commands being run by the tasks in the recipe Apr 11 21:48:57 this seems to be a change, since in OE classic it worked Apr 11 21:49:21 you can export it in that task, no? Apr 11 21:49:22 JaMa: hum... send patches, GPE upstream uses SVN :) Or do you mean the bb and friends we have in meta-oe? Apr 11 21:49:54 so I have a build number (one of the vars) Apr 11 21:50:04 i see the variable as ${BUILD_NUMBER} in the .bb Apr 11 21:50:20 but it's hidden from the cmake job run by bitbake Apr 11 21:50:27 florian: I've checkouted it with git svn now to rebase some patches we have in meta-oe.. so I can send pull-request like I do with oe-core/meta-oe patchsets so you will get standalone patches with it to (and can apply them to svn) Apr 11 21:50:34 (where I should read it from a .cmake script) Apr 11 21:51:06 JaMa: ah cool - yes please! Apr 11 22:01:57 +export BUILD_SYS Apr 11 22:01:57 +export HOST_SYS=${MULTIMACH_TARGET_SYS} Apr 11 22:02:05 anyone understand why I would have those in a recipe Apr 11 22:02:15 and why they seem to no longer parse in oe-core Apr 11 22:04:28 Crofton: does it parse with quotes like 'export HOST_SYS="${MULTIMACH_TARGET_SYS}"' ? Apr 11 22:04:48 ah Apr 11 22:04:51 better check Apr 11 22:05:01 the recipe is depends hades, so those are still busy Apr 11 22:05:04 building **** ENDING LOGGING AT Thu Apr 12 02:59:58 2012