**** BEGIN LOGGING AT Mon Mar 31 03:00:00 2014 Mar 31 07:19:09 good morning Mar 31 07:37:53 morning all Mar 31 07:59:04 morning Mar 31 08:07:59 morning Mar 31 11:39:39 Hi, I'm new to the Yocto and I have a question. What is the simplest way to bitbake core-image-minimal with a particular kernel version? I tried setting SRCREV_meta to the particular Linux version commit from the official linux-yocto-3.10.git, but which SRCREV_machine commit I should use? If I leave it with the default value, then I get the image built with a newer version of kernel than I need. Mar 31 13:22:02 What is the advantage with using do_configure[postfuncs] += "do_qa_configure " instead of addtask qa_configure after do_configure before do_compile (taken from insane.bbclass)? Mar 31 13:31:09 Saur: semantics: the latter is a new task that when a build occurs, happens between configure and compile. the former is a function that executes after confgure. Mar 31 13:31:10 the difference being, if you run bitbake foo -c configure, the former will run and the latter won't. Mar 31 13:31:50 rburton: Thanks. Mar 31 14:00:08 rburton: Maybe we could backport the x11-less support for piglit? Mar 31 14:00:14 rburton: and mesa-demos too Mar 31 14:00:43 rburton: those two would be /awesome/ to have around to benchmark the GPU Mar 31 14:00:51 otavio: for piglit it meant porting the glu code to waffle, not sure how easy that would be to backport Mar 31 14:01:17 mesa-demos should be buildable without x11, though i can't recall what it wanted it for. glxinfo, maybe, so that is a x11-only dep. Mar 31 14:01:33 rburton: glew depends on libx11 Mar 31 14:01:52 otavio: can you file a bug for piglit depending on x11 please? Mar 31 14:01:57 (and assign to me) Mar 31 14:14:01 rburton: I reported two; piglit and glew Mar 31 14:14:17 not sure you can avoid glew Mar 31 14:14:37 rburton: mesa-demos used to build and run fine in x11-less Mar 31 14:18:20 otavio: are you sure? We have quite big patch to disable all glew-dependant tests to build it x11-less (in dylan build) and I don't think it was resolved later Mar 31 14:29:32 JaMa: I think we had it working in past. But I may be wrong. Mar 31 14:44:49 JaMa: I am checking libinih build failure. Mar 31 14:45:29 great, thank you Mar 31 14:45:59 also please check that freerdp, it's already moved to nonworking on world builds.. Mar 31 14:53:24 JaMa: FreeRDP will take more time as I need to check build system changes. Mar 31 14:53:39 JaMa: I am building inih for testing already Mar 31 14:54:08 firefox concerns me; I need to find some time to update it :( Mar 31 14:58:52 I am unsure if I ask que question on the right channel, how to set timezone on the image created from yocto (danny) ? Mar 31 16:43:00 is it possible to build multiple MACHINE settings at the same time? Mar 31 16:43:39 hello i installed yocto in pandaboard es with lttng ( i added CORE_IMAGE_EXTRA_INSTALL = "lttng-ust lttng-modules lttng-tools " to local.conf) Mar 31 16:43:50 but i can't get kernel syscalls Mar 31 16:43:58 lttng enable-event -a -k --syscall i get "enable kernel events failed" Mar 31 16:44:06 please help Mar 31 16:48:25 any suggestion plz ? Mar 31 16:49:54 does yocto support kernel syscalls ? Mar 31 16:50:05 volker-: not within the same build, but you can change it between builds Mar 31 16:51:24 maroua_: yes it does; I don't know much about lttng but I suspect the kernel has to be properly configured, maybe the one in the pandaboard BSP isn't? Mar 31 16:54:39 but i properly configured the image Mar 31 16:54:54 it listed all kernel events Mar 31 16:55:06 but no syscalls Mar 31 16:57:03 there are the steps Mar 31 16:57:05 git clone git://git.yoctoproject.org/poky.git -b dora Mar 31 16:57:20 $ cd poky Mar 31 16:57:22 $ git clone http://git.yoctoproject.org/git/meta-ti Mar 31 16:57:31 $ git clone https://github.com/openembedded/meta-oe.git Mar 31 16:57:38 source oe-init-build-env pandaboard Mar 31 16:57:55 i added BB_NUMBER_THREADS ?= "4" PARALLEL_MAKE ?= "-j 4" MACHINE ?= "pandaboard" to local.conf Mar 31 16:58:05 also CORE_IMAGE_EXTRA_INSTALL = "lttng-ust lttng-modules lttng-tools " Mar 31 16:58:26 $ time bitbake core-image-sato Mar 31 16:58:34 $ wget http://jcrom.net/release/yocto/mksdcard_panda_yocto.sh Mar 31 16:58:44 $ LANG=C sudo ./mksdcard_panda_yocto.sh /dev/sdb Mar 31 16:58:52 so this is all Mar 31 17:01:36 any alternative solution?? Mar 31 17:02:00 i tested the inage with pandaboard ES REV B1 and REV B2 Mar 31 17:02:04 same problem Mar 31 17:03:45 plz help it's urgent Mar 31 17:08:42 ?? Mar 31 17:09:11 I await your reply Mar 31 17:25:28 maroua_: I can't really advise about lttng, I've never used it - sorry Mar 31 18:19:40 Is this build failure: http://privatepaste.com/f10507654e known? Mar 31 18:24:43 otavio: it appears you've left out the error... Mar 31 18:25:20 nmglobal.h:29:21: fatal error: pointer.h: No such file or directory Mar 31 18:32:22 bluelightning: this broke in today's build Mar 31 18:36:17 RP: opened bug 6081 for the sstate oddity I ran into. still digging, but would appreciate your giving a look to the delta between the working (from scratch) and broken (from sstate mirrors) sstate-caches, which is attached to the issue, in case it provides some insight Mar 31 18:36:18 Bug https://bugzilla.yoctoproject.org/show_bug.cgi?id=6081 normal, Undecided, ---, richard.purdie, NEW , SSTATE_DIR populated from SSTATE_MIRRORS is incomplete Mar 31 18:37:03 https://bugzilla.yoctoproject.org/attachment.cgi?id=1874 these archives came out of a from scratch core-image-minimal, but didn't get fetched into sstate_dir when building from it as an sstate mirror Mar 31 18:40:50 I'm not sure how much this has affected us, but at a minimum it raises a question, and beyond that it can be useful when testing sstate to be able to use a from-sstate-mirror build to populate a subset of the cache, and then see if that has everything necessary to build in various circumstances. that's how i ran into it, when attempting to test sstate reuse with different environmental differences between the builds Mar 31 18:41:50 though, when using a remote sstate mirror to populate a local one, this could bite me Mar 31 18:47:42 JaMa: inih patch sent. Mar 31 18:51:08 thans Mar 31 18:55:44 JaMa: the nbench-byte build error I had didn't happen in my local machine. Did you see it in your tests? Mar 31 19:20:06 JaMa: yes; nbench-byte built fine now in my build server Mar 31 19:20:24 JaMa: so it seems to be parallel building issue Mar 31 20:07:05 * kergoth double checks 6081 without external toolchain (though he tested with and without in the previous setup, want to cnfirm this exact reproducer in that case) Mar 31 20:30:45 I am unsure if I ask que question on the right channel, how to set timezone on the image created from yocto (danny) ? Mar 31 20:42:18 hmm.. in dora the systemd "alignment.service" (backed by the sysvinit script) is still not started for arm. :} Mar 31 20:43:21 really need to sit down and audit the delta between sysvinit and systemd images, because even in cases where a given service is tarted in both, they're not always started the same way, with the same prep and options, when they aren't backed by the same script Mar 31 20:43:26 * kergoth mutters Mar 31 20:44:23 :} Mar 31 20:45:01 for alsa, the script isn't even in the same binary package Mar 31 20:45:14 kergoth: e.g. in terms of busybox syslogd (the journald is just a hog for the TI Davinci we use for the GSM basestation). There are two different ways to configure busybox syslogd. :} Mar 31 20:45:15 alsa-utils-alsactl for systemd, alsa-state for sysvinit, iirc Mar 31 20:45:27 * kergoth nods Mar 31 20:45:44 :} Mar 31 20:46:00 systemd apparently doesn't look into rcS.d.. Mar 31 20:46:35 Can I make a bbappend for a specific PR? Mar 31 20:47:02 nope, appends are by recipe filename, not PN/PV/PR Mar 31 20:56:40 hmmm. I wonder how/if I can fix the update-rc.d of the alignment.sh without replicating the entire do_install. Probably use a prepend and hope the second call with fail in a non fatal way. :} Mar 31 21:06:05 zeddii: ping ? Mar 31 21:39:04 when using bin_package.class with an rpm package, it is just getting extracted to ${WORKDIR} is there a way to override where it gets extracted? Mar 31 21:43:01 kergoth: if you have those builds handy could you attach the cooker logs? Mar 31 21:45:27 nevermind, I apparently failed to read the bolded, highlighted, front and center note explaining I need to set the subdir= variable in the SRC_URI. Mar 31 22:19:40 RP: k, done Mar 31 22:23:06 halstead: ping Mar 31 22:23:15 halstead: see pm. Mar 31 22:23:29 pidge, okay. Mar 31 22:24:10 halstead: the backlog of build failures also works. Just a question of whether I've screwed something up in the metadata or the servers are upset... Mar 31 22:26:56 kergoth: thanks, those logs are helpful Mar 31 22:27:10 RP, nfs mount failure on ab05 should explain anything on that host. Mar 31 22:27:54 kergoth: from the last one, it looks like it doesn't like something about update-rc.d ... Mar 31 22:28:14 Fixed now. Mar 31 22:28:21 halstead: right, that one then gobbled up any tasks quickly failing them all :) Mar 31 22:28:32 halstead: pidge is restart things, thanks both :) Mar 31 22:28:47 Yay for fast failures. Mar 31 22:31:28 RP: it does? Hmm, I don't see what you're referring to, but I'll take your word for it you know the sstate stuff way better than I do :) Mar 31 22:33:27 kergoth: Its not doing a full build, it is rebuilding the toolchain and then "something" which it needed the toolchain to build Mar 31 22:33:41 kergoth: I'm not 100% clear on what "something" is mind :/ Mar 31 22:34:09 kergoth: since it skips to the rootfs after update-rc.d, it seems likely that was it though Mar 31 22:35:03 remember that build #3 was interrupted, it would have continued merrily rebuilding everything, i didn't see the point in letting it continue when it was past the setscenes and running real tasks Mar 31 22:35:12 afk Mar 31 22:35:34 kergoth: ah, right, yes :/ Mar 31 22:36:26 kergoth: yes, you're right. Been staring at the screen too long today Mar 31 22:37:00 kergoth: I did find a bug in the setscene code that robert reported earlier on today. This looks different though, much as my brain wants to make them the same issue :) Mar 31 22:44:26 RP: the thing I find most interesting is the sstate archives in the first build that weren't fetched in the second, e.g. ../build/sstate-cache/19/sstate:e2fsprogs:i586-poky-linux:1.42.9:r0:i586:3:199a149f349bfdabd97497009ccdead7_populate_sysroot.tgz Mar 31 22:44:39 e2fsprogs seemingly wasn't built in any form in build2, sstate or otherwise Mar 31 22:44:53 where'd it come from? build's sstate-cache was empty when i built it from scratch Mar 31 22:45:01 * kergoth gets more coffee Mar 31 22:48:05 kergoth: One thing I just noticed when trying your reproducer with just quilt-native - the distro part of the native packages get stripped out Mar 31 22:49:40 gah, ignore me :/ Mar 31 22:51:52 This isn't a critical issue, since it's only occurring when there's an indirection involved in your sstate setup, e.g. a local cache of a remote mirror, or using a local build to pare down a larger cache for testing purposes. Not blocking us or anything, just wanted to make sure it was on the radar Mar 31 22:52:01 and to see if it was something simple and obvious i was missing :) Mar 31 22:53:56 kergoth: it is puzzling why it wouldn't work, I'm intrigued more than anything Mar 31 22:54:01 * kergoth nods Mar 31 22:54:10 kergoth: and concerned this is a symptom of a more serious issue Mar 31 22:56:13 I'd have thought that if there was something wrong with one of the sstate archives, a setscene would hae failed, and if not, then it would have used them all and not rebuilt at all. It's interestin that both build2 and build3 run the same number of setscene tasks, it's what they do from there that differs Mar 31 22:57:09 kergoth: yes, I noted the number of setscene tasks was the same. Mar 31 22:57:41 kergoth: I think the printdiff gives that output since the intermediate task sigdata is are missing in build2 Mar 31 22:58:04 i.e it has nothing to compare against... Mar 31 22:59:49 ah, yes, i was thinking that was a possibility. does seem likely, so that's likely a red herring, not related to the reason it's choosing to rebuild in build3 and/or isn't populating build2's sstate-cache fully Mar 31 23:00:34 * kergoth heads home from the coffee shop Mar 31 23:43:15 kergoth: http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/t2&id=282b135674dc007e70a811918a456b8ece6b492b is the fix. I'll do a proper commit message and writeup tomorrow ;-) Mar 31 23:44:04 kergoth: debug consisted of "bitbake -p; bitbake eglibc -DDD" in build2 and build3, then diffing them :) **** ENDING LOGGING AT Tue Apr 01 02:59:59 2014