**** BEGIN LOGGING AT Wed Mar 20 02:59:58 2013 Mar 20 08:49:40 hi Mar 20 08:57:14 good morning Mar 20 09:03:04 is there a howto, wehre and how I configure u-boot with yocto? I did't found something about that.. (Sorry I am new to yocto and embedded Linux) Mar 20 09:05:16 matt___: actually I prefer to play with u-boot out of yocto until it is not completely running Mar 20 09:20:49 morning all Mar 20 09:31:04 hello there Mar 20 10:17:51 hi bluelightning, all Mar 20 10:27:57 hi mckoan Mar 20 14:05:12 hi. is there a way to trigger a rebuild of the deploy sources? i changed some archiver options in local.conf and cleaned the directory by hand, but now it does not get rebuilt when building an image. Mar 20 14:06:33 i think you are searching for "bitbake -c compile -f; bitbake Mar 20 14:07:20 i'll try, thanks Mar 20 14:07:26 matt@debian:~/yocto/build_fs$ bitbake virtual/kernel -c compile -f; bitbake virtual/kernel Mar 20 14:07:30 for example Mar 20 14:07:48 this works vor kernel reompilation Mar 20 14:12:22 here is the workaround for it: https://lists.yoctoproject.org/pipermail/yocto/2012-May/008861.html Mar 20 14:12:31 if this discribes your problem Mar 20 14:15:27 not really unfortunately - i better don't try this now. i don't want a (complete) recompile of the whole image, i just need the sources already being present in the work dirs being repackaged to the deploy/sources dir by the archiver. this was done automatically during a clean rebuild, but it does not work after manually cleaning the deploay/sources dir Mar 20 15:23:02 matt___: bug #3449 seems to be the answer: it can only be done via complete rebuild by now :/ Mar 20 15:23:03 Bug https://bugzilla.yoctoproject.org/show_bug.cgi?id=3449 normal, Medium, 1.4, kergoth, IN PROGRESS DESIGN , archiver doesn't interact well with sstate Mar 20 15:23:57 schramae: bitbake -cclean ; bitbake Mar 20 15:25:23 mckoan: will try, thx Mar 20 15:27:16 that bug was fixed, actually, shakeel took care of it Mar 20 15:27:22 * kergoth pokes him to resolve the bug Mar 20 15:27:29 mshakeel: https://bugzilla.yoctoproject.org/show_bug.cgi?id=3449 Mar 20 15:27:30 Bug 3449: normal, Medium, 1.4, kergoth, IN PROGRESS DESIGN , archiver doesn't interact well with sstate Mar 20 15:53:55 kergoth: nice. but i'm stuck to the release tarball of 1.3, so i'll go for the workaround for now Mar 20 15:57:26 * kergoth nods Mar 20 16:06:47 i just defined PREFERRED_VERSION_linux, and bitbake is tryiong to aply that version preference to stuff like m4-native Mar 20 16:06:51 what? Mar 20 16:06:52 * kergoth boggles Mar 20 16:08:08 is _linux being treated as an override? Mar 20 16:08:13 exactly Mar 20 16:08:24 ugh Mar 20 16:08:29 pn-linux will work Mar 20 16:08:33 the alternatives being _darwin etc i presume Mar 20 16:08:45 fray: that seems unlikely, given bitbake gets preferences from the config metadata. Mar 20 16:08:58 afaik, anyway Mar 20 16:11:38 * kergoth also thinks its stupid that bitbake is falling back to the un-suffixed PREFERRED_VERSION at all Mar 20 16:11:50 it's meaningless Mar 20 16:12:28 kergoth: agreed Mar 20 16:12:50 about as silly as letting you set a un-suffixed SRC_URI in local.conf Mar 20 16:39:05 Any bitbake expert? Mar 20 16:39:27 It seems fray has helped me to uncover a bug and I found a way to get it working Mar 20 16:39:41 but I need someone to look at the patch and help me to finish it Mar 20 16:40:12 I can look and give an opinion, but I'm not exactly an expert.. ;) Mar 20 16:45:03 i am no expert but i do enjoy reading through the bitbake code and i am fairly experienced with python Mar 20 16:45:27 waynr: you *enjoy* reading bitbake code? I think you need help. :) Mar 20 16:46:29 rburton: not saying I undertand it very well, but reading through it occasionally over the past year has been interesting and helped me learn python :P Mar 20 16:46:41 otavio: I'd suggest emailing the bitbake-devel list Mar 20 17:13:20 Ok Mar 20 17:13:35 http://pastebin.com/RpQd3dyP Mar 20 17:13:42 this is current patch Mar 20 17:15:06 interesting.. Mar 20 17:15:06 so _append/_prepend are flags? Mar 20 17:15:19 The only other thing is this block: Mar 20 17:15:19 - dest = self.getVarFlag(newkey, i) or [] Mar 20 17:15:19 - dest.extend(src) Mar 20 17:15:19 + dest = self.getVarFlag(newkey, i) or '' Mar 20 17:15:19 + dest += src Mar 20 17:15:40 I suspect the value of the flags are typed in some way... Mar 20 17:15:45 so this might be a problem for other things Mar 20 17:15:50 i'm guessing you want flags to traverse override boundaries? not all flags are lists, so blindly concatenating them isn't going to make things happy, and will just break for the flags that *are* lists (apepnd/prepend), due to how += works for lists Mar 20 17:16:05 a = []; a += "foo"; a == ["f", "o", "o"] Mar 20 17:17:00 ya.. that's my worry.. Mar 20 17:17:58 kergoth: yes; this broke my update-alternatives patch Mar 20 17:18:18 there's a reason we haven't fixed this behavior yet :) it's non-trivial Mar 20 17:18:33 kergoth: great Mar 20 17:18:40 it really needs to get fixed.. :( Mar 20 17:18:50 kergoth: but update-alternatives is broken without this fix Mar 20 17:18:54 I can live with the flag values themselves not being expanded (but I'd -love- to see that fixed!) Mar 20 17:19:15 but having problems w/ variable key's not working right is a bug we need fixed Mar 20 17:22:50 http://pastebin.com/Wipn3gzW Mar 20 17:22:52 nd this Mar 20 17:22:58 and this? Mar 20 17:27:21 Nicer version: http://pastebin.com/eefGbwj7 Mar 20 17:27:28 fray: kergoth Mar 20 17:28:23 again, that's likely to break some flags. not all flags are lists, so concatenation isn't always appropriate Mar 20 17:28:27 * kergoth shrugs Mar 20 17:28:35 again, i think the bitbake list is the best place for this Mar 20 17:32:42 kergoth: I am not in bitbake ml Mar 20 17:34:46 otavio definitely better.. I think the mailing list is open so you can send to it, might have to be accepted by the list maintainer.. Mar 20 17:34:58 yes, it's moderated for non-members Mar 20 17:35:04 or, join but turn off delivery Mar 20 17:35:13 ETOOMANYLISTS! Mar 20 17:35:25 it's luckily a -very- low volume list.. Mar 20 17:38:59 subing but turning off delivery solves the moderation issue without mail overload Mar 20 17:51:03 what is bb ml? Mar 20 17:52:52 why am i seeing sstate fetch failures.. failing ot fetch sstate from a mirror isn't supposed to be fatal.. hmm Mar 20 18:02:23 kergoth: something like https://bugzilla.yoctoproject.org/show_bug.cgi?id=3250 ? Mar 20 18:02:24 Bug 3250: normal, Medium, 1.4, richard.purdie, RESOLVED WORKSFORME, Fetcher errors when looking for sstate package in do_package_write_ipk_setscene Mar 20 18:02:25 otavio: bitbake mailing list Mar 20 18:03:00 otavio: http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/bitbake-devel Mar 20 18:03:31 hmm, the only fetch failures i see are siginfos, maybe it handles regular sstate fetch failure quietly but not the siginfo Mar 20 18:04:11 bluelightning: did it Mar 20 18:11:41 Another thing Mar 20 18:12:09 I am trying to get rootfs done with pseudo so I can have proper user/perms Mar 20 18:15:02 But it turns that rootfs dir is built with wrong parms/perf Mar 20 18:16:24 is cleanall=(clean+cleansstate)? Mar 20 18:16:43 somehow my cleanall removed the source I downloaded too Mar 20 18:16:55 no, thats what cleanall *is* Mar 20 18:17:00 cleanall is clean + remove sources Mar 20 18:17:03 :) Mar 20 18:17:16 http://www.openembedded.org/wiki/List_of_Executable_tasks Mar 20 18:17:29 cleanall clean $WORKDIR and sstate-cache Mar 20 18:18:56 clean(WORKDIR), cleansstate(sstate-cache), cleanall(clean+sources) Mar 20 18:19:06 the unpacked sources are in a subdir of $WORKDIR Mar 20 18:20:17 source I mean pkgs in DL_DIR here Mar 20 18:20:20 clean+sources, it says right there what it does Mar 20 18:20:32 yes, cleanall wipes downloaded sources for the recipe from DL_DIR, and empties workdir (clean) Mar 20 18:20:39 that's its entire purpose Mar 20 18:21:05 i would expect cleanall removes sstate-cache, but not the downloaded tarballs... Mar 20 18:21:10 anyway need remember that, thanks Mar 20 18:21:25 cleanall = (clean+cleansstate) makes more sense to me :) Mar 20 18:23:03 I actually thought it did all three, but I don't seem to use it ever so I'm not surprised I remember wrong Mar 20 18:23:54 i normally use clean and/or cleansstate, i did a cleanall today and found I had to reinstall as the DL_DIR contains the package that is from an internal git Mar 20 18:25:05 otherwise bitbake can't fetch, cleanall is dangerous for self-contained releases where all package sources are pre-cloned from some internal git Mar 20 18:30:58 ausxxh: We have some internal git repos, but our recipe SRC_URIs point at "git archive" tarballs. So we don't depend on DL_DIR being pre-populated with anything in particular. Mar 20 18:41:36 hmm "QA Issue: Architecture did not match (20 to 3) " that is a new one Mar 20 18:42:30 mranostay: this can happen from time to time depending on the package and tooling, what recipe? Mar 20 18:42:38 valgrind Mar 20 18:43:13 mranostay: it might have built a native host binary along with the target, what's your target? Mar 20 18:43:21 powerpc Mar 20 18:44:28 mranostay: do you have a x86 or x86_64 host? It looks like it built a x86 binary Mar 20 18:44:50 x86 host.. checking Mar 20 18:53:13 gah "ELF 32-bit LSB shared object, Intel 80386" Mar 20 18:53:40 mranostay: which file? Mar 20 19:10:28 ask again, why isn't meta-oe included in yocto release Mar 20 19:13:16 meta-oe is an entirely different beast than the yocto content. oe-core is tightly controlled to ensure high quality Mar 20 19:13:24 (though we don't always succeed, that's the goal) Mar 20 19:13:42 in some ways meta-oe tends to be the pile where recipes tha thave no other home go Mar 20 19:15:12 thought meta-oe is something non-core, but essential, anyway, thanks Mar 20 19:17:00 it completely depends on what you're trying to do. if what you're doing requires some recipe from meta-networking or meta-multimedia under meta-openembedded, then it would be essential for you :) Mar 20 19:17:11 but no, if you just want to build an image or something, it's not needed Mar 20 19:18:28 crazy as it sounds, i'm asked to run openstack on yocto, meta-virtualization is good, but i need so many more python modules Mar 20 19:20:01 http://wiki.openembedded.net/index.php/LayerIndex is your friend :) Mar 20 19:20:55 ausxxh, a lot more of openstack is coming meta-virtualization. Mar 20 19:21:14 ausxxh, so if you have development going on, feel free to contribute them there. Mar 20 19:22:12 zeddii: sure, it's now more of a python issue, thinking about building all the python modules I need natively instead Mar 20 19:22:31 instead of recipe-cross-compiling them one by one Mar 20 19:23:06 ausxxh: agreed .. the need for the missing modules is known. I'd think that within a month or two they'll be available, so check back, and if you do have anything to add .. you know where to find the layer :) Mar 20 19:25:46 not sure if this makes sense, yocto builds up a framework with a full blown sdk for the target(qemu/hardware), then let the rest be built by qemu / hardware, instead of writing all packages as a recipe? Mar 20 19:26:08 by sdk I mean the sdk running natively, on qemu or target hardware Mar 20 19:27:15 not sure how capable is the existing native sdk yet Mar 20 19:27:50 you can definitely do something like that with enough effort. recipes are the end game for reproducible, multi arch builds of course. you'll end up adding to the target side build with packages being built and installed, etc. Mar 20 19:38:50 so, anyone know why package_deb installs glibc-localedata-i18n explicitly in addition to the image linguas bits, but the other package formats dont? (re: do_rootfs package installs) Mar 20 19:41:54 whew, goodbye BB_DANGLINGAPPENDS_WARNONLY, meta-mentor doesn't need it anymore Mar 20 19:42:42 package_deb is broken? Mar 20 19:43:45 haven't actually tried it in years, just noticed the package_linguas steps were different between the different package classes Mar 20 19:44:32 i was going to submit a patch to drop this logic that disables linguas install when TARGET_OS has specific non-uclibc values, since tclibc-uclibc empties IMAGE_LINGUAS anyway, it seemed pointless, but then spotted this difference in behavior i didn't understand Mar 20 19:45:45 I'd say deb hasn't had enough love to be fixed Mar 20 19:46:53 heh, fair enough Mar 20 19:47:06 neglected stepchild Mar 20 19:49:48 kergoth: i think you're now the new maintainer of package_deb, congratulations Mar 20 19:50:35 i was the one that wrote it in the first place when i was at ohand :) Mar 20 19:50:41 it wasn't fun then, i doubt it'd be fun now :) Mar 20 19:50:53 well, made it work, that is Mar 20 19:51:05 * kergoth wanders off to find some coffee Mar 20 19:51:17 kergoth: yes, i remember. neglected *child*. :) Mar 20 19:51:39 * kergoth chuckles Mar 20 19:52:30 I really was not operating at 100% productivity during that contract, antidepressent dose was off Mar 20 19:52:38 * kergoth mutters and actually wanders off this time Mar 20 20:51:43 i added a patch to kernel(yocto 1.3), bumped PR, launched bitbake image-core, why the hack it recompiles pretty everything including eglibc-2.13? they're all in sstate! Mar 20 20:52:36 does bitbake -c clean virtual/kernel removes those sstate other than kernel itself? Mar 20 21:08:04 otavio: meta-fsl-arm is failing: see http://autobuilder.yoctoproject.org:8011/builders/nightly-fsl-arm/builds/16/steps/Building%20Images/logs/stdio Mar 20 21:18:38 pidge: known; I am on it Mar 20 21:19:42 otavio: ty Mar 20 21:21:59 pidge: yw Mar 20 21:38:59 pidge: fixed mx53 one Mar 20 21:39:15 pidge: Gary is preparing a new version of patch for vivante driver Mar 20 21:48:36 otavio: ok. I want to run M5.rc1 soon from master. I'll let you know when I need to Mr branch Mar 20 21:48:46 s/Mr/M5/ Mar 20 21:48:58 pidge: I hope to have it fine for tomorrow Mar 20 21:49:07 pidge: works for you? Mar 20 21:49:09 ok. it'll miss my M5 then. Mar 20 21:49:14 rc1 at least Mar 20 21:49:39 we can rebuild for later in the week then. Mar 20 22:02:44 ausxxh: bitbake automatically rebuilds based on dependencies. if A depends on B and B's metadata checksums change, A will get rebuilt, unless they're in the whitelist which marks specific exclusions. one would think the kernel would be one of those exclusions, but I don't really know offhand Mar 20 22:07:19 Hmm, I'm thinking we could probably drop the build-time update-alternatives dependency. we already add to the rdepends, we could just move that to parse time and drop the build dep entirely -- we don't need upd-alt to compile, after all Mar 20 22:19:17 kergoth: did the e-mail got bb ml? Mar 20 22:20:58 looks like it, yes Mar 20 22:23:03 thx Mar 20 23:20:07 otavio: meas-dri is failing in current fsl-arm builds: http://autobuilder.yoctoproject.org:8011/builders/nightly-fsl-arm/builds/16/steps/Building%20Images/logs/stdio Mar 20 23:20:25 otavio: not sure why but its looking at the native sysroot for expat Mar 20 23:21:04 otavio: ah, you already know., sorry. Scroll was stuck for some reason :/ Mar 20 23:22:07 kergoth: we'd need to ensure the sstate "acceleration" code knows that postinsts might use it Mar 20 23:23:26 not sure what you mean by that. anonymous python would add the runtime bits to the rdepends for the packages which use it Mar 20 23:25:15 hmm, wonder why this qemu-native build fails with a relocation failure only for this one machine. /me sanity checks its layer Mar 20 23:47:11 kergoth: there is acceleration code which for example doesn't bother populating the target sysroot if you're building an image Mar 20 23:47:53 kergoth: http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=b1a7b15941c1abf2219084a5d685735756541fb5 - need u-a in that list too Mar 20 23:48:16 kergoth: the interface is suboptimal I know... Mar 20 23:57:17 yikes Mar 21 01:01:24 1.4_M5.rc1 is kicked and running. Mar 21 01:06:22 pidge: nice Mar 21 01:24:55 kergoth: yeah, and on the new ab code. which should, at least in theory, be much faster. **** ENDING LOGGING AT Thu Mar 21 02:59:58 2013