**** BEGIN LOGGING AT Fri Apr 25 02:59:58 2014 Apr 25 06:17:38 If the webmaster is here, there's a copy/paste error on the Daisy-page where it says the release notes are for Dora. https://www.yoctoproject.org/download/yocto-project-16 Apr 25 06:58:53 So, anyone know what has changed in the way ROOTFS_POSTPROCESS_COMMAND works lately? Previously I could add regular shell commands like echo "foo" > ${IMAGE_ROOTFS}/bar , but now I just get a warning "WARNING: Function doesn't exist" Apr 25 07:21:45 sgw_: thanks, I have pushed a fix for cairo issue to the contrib branch. ppc ICE issue is still open, try out the new patchset and let me know how it goes Apr 25 08:09:04 erbo: they were changed to execute via exec_func so you may need to define a function with those commands in Apr 25 08:10:46 RP: I did a function foo() { my shell-code stuff} in the image recipe and then ROOTFS_POSTPROCESS_COMMAND += "foo()" , but then I got the same error about "Function foo doesn't exist" Apr 25 08:10:54 that's how I should to it, right? Apr 25 08:12:01 I did call it do_ but there's no special treatment of functions prefixed with do_ , or? Apr 25 08:14:10 hmm, maybe I shouldn't include the trailing () in ROOTFS_POSTPROCESS_COMMAND Apr 25 08:15:08 erbo: I suspect the trailing () was a problem Apr 25 08:15:38 RP: I'll try again in a sec Apr 25 08:34:21 RP: removing () did the trick, thanks Apr 25 09:22:39 morning all Apr 25 10:22:33 hai all, am building customized kernel (version - 3.6.9) for arm using yocto-toolchain. it is often showing do_compile error which is http://pastebin.com/psvXu1Fb . I couldn't get the solution ,can anyone help me to fix it. Apr 25 10:25:03 i think it basically means that there's something fishy with your kernel config Apr 25 10:25:35 and, why not 3.10 which is the current "officially" supported version by them atmel guys? Apr 25 10:41:28 jasmi: Double check that you have actually configured the kernel to support at least one board type. I think this was my problem when I encountered that error Apr 25 10:54:24 simonl: Yes i have configured the kernel to support for these boards http://pastebin.com/k0y5S7RB. Apr 25 12:27:08 When building an image with IMAGE_FEATURES += " dbg-pkgs " the image creation silently fails. Apr 25 12:28:16 The build completes, but no image is created and the symlink is deleted Apr 25 12:39:31 why would this happen, it's not obvious to me which log to look in Apr 25 12:54:57 morning every one, I got a little problem with lm_sensor, when I tried to build it, I have got the "lmsensors not found in the base feeds" error, I found some similar error on inet but that seem wrong to my problem Apr 25 12:56:07 I found the ALLOW_EMPTY_${PN} patch, but not allow the application to be install Apr 25 12:56:42 TuTizz: maybe the "lmsensors" package doesn't actually contain it itself? are there other lmsensors-* packages that you should be installing instead? Apr 25 12:57:18 there is lmsensors-config_1.0.bb and lmsensors_3.3.3.bb Apr 25 12:57:36 TuTizz: I mean packages, not recipes Apr 25 12:57:48 the lmsensors recipe will produce a number of packages Apr 25 12:58:02 you can see those by looking in packages-split under the workdir for the recipe Apr 25 12:58:30 (and often they will be defined in the recipe itself) Apr 25 12:58:42 yep saw them Apr 25 12:58:56 (sry for the disconnection, did I miss something?) Apr 25 12:59:07 no, don't think so Apr 25 12:59:13 ok ty Apr 25 13:14:37 bluelightning, :) I think I understand, I have to swap, in my image, lmsensor by lmsensors-sensord (if I want sensord), is that it? Apr 25 13:15:02 Yes, this is it :D, thanks you. Apr 25 13:15:39 TuTizz: right, that's what I was thinking Apr 25 13:18:18 Should adding dbg-pkgs to IMAGE_FEATURES disable .ubi images? Apr 25 13:19:07 simonl: definitely not Apr 25 13:19:20 simonl: anything in log.do_rootfs to indicate what might be going wrong? Apr 25 13:21:19 not really last I checked a couple of tries ago Apr 25 13:22:37 but I found something else: I think the extra packages might make the image to big to fit the ubi image Apr 25 13:22:44 *too Apr 25 13:24:07 I _always_ discover key things like this seconds after asking... :P Apr 25 13:24:31 simonl: it should error out if that were the case; if it's not doing that there must be a bug Apr 25 13:27:12 Yeah, getting no error isn't that nice... I'll look around a bit more and then I might submit a bug Apr 25 13:28:19 simonl: that would be great, thanks Apr 25 13:28:36 simonl: which branch / version of the build system is this with btw? Apr 25 13:31:34 not quite up-to-date 1.5.x Apr 25 13:33:05 I read something about 1.6 earlier, but I don't think I'll have the time to try that right now... Apr 25 13:33:22 ok, just wondering Apr 25 13:33:45 even if it was 1.5 we'd want the issue fixed there as well, if it's an issue in the core Apr 25 14:32:30 is it possible run stellarium on vivante drivers ? Apr 25 16:10:40 RP: I guess it was not intentional, but e45da211a7 made the PR for meta/recipes-core/initscripts/initscripts_1.0.bb go backwards... Apr 25 16:16:51 Saur: will fix, thanks Apr 25 16:28:06 moin Apr 25 17:18:46 RP: ping Apr 25 17:19:14 kergoth: pong Apr 25 17:19:30 RP: have you ever seen a rogue missing variable dependency? Apr 25 17:19:37 https://www.mail-archive.com/openembedded-devel@lists.openembedded.org/msg34511.html is someone in the community hitting one Apr 25 17:19:42 but we've seen it a few times at mentor elsewhere Apr 25 17:19:58 it emits a function and its deps to run it, but the function fails due to a dependent function not having been emitted Apr 25 17:20:09 but it's not reproducible, i've *never* hit one personally, only our jenkins builds Apr 25 17:20:20 kergoth: I've never seen that happen... Apr 25 17:20:33 we've occasionally had to throw up explicit vardeps additions because it tended to fail at particular spots, though not always Apr 25 17:21:03 kergoth: not good. I wouldn't know where to start with that either :/ Apr 25 17:21:07 I added debug messages to dump the variable dep info right before running the function, and sure enough, in the failing case it was missing a number of deps Apr 25 17:21:18 but i was never able to determine *why*, being unable to repro Apr 25 17:21:19 :\ Apr 25 17:21:22 quite strange Apr 25 17:21:23 kergoth: something cache related maybe? Apr 25 17:21:35 kergoth: specifically the codeparser cache? Apr 25 17:21:43 Yeah, I was thinking along those lines also, maybe some sort of contamination amongst vars? Apr 25 17:21:44 kergoth: what version was this? Apr 25 17:22:25 We just hit one a couple weeks ago with daisy, but we've seen it on and off for a very long time. It's never been enough of a blocker to force me to spend 100% of my time on it Apr 25 17:22:47 particularly when it tends to stick at a particular circumstance, and we can work around those cases with a vardeps addition Apr 25 17:22:51 kergoth: I wondered about http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=e955def4d3929f44d27d2958ab3ff4b48534f26f but that one was deterministic Apr 25 17:23:02 * kergoth nods Apr 25 17:23:54 kergoth: Parsing order and/or the state of the codeparser cache would be interesting if this happens on a build and you can save it off Apr 25 17:24:07 kergoth: compare the codeparser result with a fresh build Apr 25 17:24:33 RP: I have the musl support in my kraj/musl branch whats your opinion on approach to getting it in Apr 25 17:24:37 Okay, thanks for the tip, will look in that vicinity if we ever hit it again Apr 25 17:25:01 khem: Lets talk at ELC, I haven't thought much about that yet Apr 25 17:25:05 * RP needs to head afk Apr 25 17:25:10 RP: ok Apr 25 17:25:17 I kind of want something like http://rr-project.org/ for bugs like this. full process state replay Apr 25 17:25:24 I have now got x86/mips also building btw. Apr 25 17:25:43 too bad gdb with python is not pleasant :) Apr 25 17:26:28 kergoth: you want to use gdb to debug python Apr 25 17:26:45 I don't *want* to, no Apr 25 17:27:08 I just wish it didn't suck, since this bug isn't reproducible, so it'd be nice to capture and replay the state after the fact Apr 25 17:27:17 ah Apr 25 17:27:24 debugging tools always suc Apr 25 17:27:24 k Apr 25 17:28:21 indeed Apr 25 17:30:15 Hmmm.. Apr 25 17:31:05 many a times I want to debug an issue and I end up debugging/fixing the debugger first :) Apr 25 17:32:45 Hmm, if RP's theory is correct, maybe I should inject a line into bitbake to randomize the bbfiles parse order, and then run a from-scratch parse repeatedly, monitoring the codeparser cache for changes :) Apr 25 17:37:38 https://gist.github.com/kergoth/11297333 Apr 25 17:37:39 heh Apr 25 17:37:43 * kergoth plays around Apr 25 18:39:36 oh damn Apr 25 18:39:51 I'm definitely seeing differences in bb_codeparser.dat between two different parses with different file parse orders Apr 25 18:39:55 this is worrisome Apr 25 18:42:46 * kergoth digs Apr 25 18:50:29 sgw_: there ? Apr 25 18:51:39 sgw_: I have rebased gcc 4.9 branch on top of the libgcc-initial changes that rp did and made appropriate adjustments to gcc 4.9 as well Apr 25 18:51:53 so please retry with the latest whenever you try again Apr 25 19:26:53 RP: I think I found the cause. Not 100% certain, but I know I found at least one bug :) Apr 25 19:29:31 RP: ShellParser.parse_shell() stores execs from self.allexecs/self.funcdefs by hash of the value. But this isn't only called on the value of the entire shell value, it's also called on subshells. So context is leaking. execs from the calling function are leaking into the execs of the subshell component, and further, it's *resetting* self.execs to the execs of the hashed subshell value, not the overarching variable value when pulling from the Apr 25 19:29:32 cache. I expect if we split off _parse_shell which doesn't interact with the cache at all, and use that for subshells, our cached shell execs will become much more deterministic, if not entirely so Apr 25 19:30:20 e.g. if a shell task runs `find ${S} | grep -v aclocal-copy`, parse_shell('find ${S} | grep -v aclocal-copy') is run, but the object has state from the overall variable at that time Apr 25 19:31:54 * kergoth tests Apr 25 19:36:58 I'm guessing this mostly caused issues between two different functions which, while different, shared a common subshell. Apr 25 19:37:07 I'm not sure this will fix the issues we've seen, but it's a start Apr 25 19:37:21 not seeing any delta between codeparser.dat between parses with randomized bbfile parse order anymore, but still testing Apr 25 19:57:16 * kergoth does more local sanity test builds before submitting this to the bitbake list Apr 25 20:34:05 khem: I will locally, but probably will wait for the ICE patch before hitting the AB again Apr 25 20:36:59 1amh0me Apr 25 20:37:14 dang, there goes that one! Apr 25 20:37:57 * sgw_ sez ignore the man behind the screen ;-) Apr 25 21:27:48 ick, the prelink-cross repository is a single 'trunk' subdir? somebody sucked at the svn conversion :) Apr 25 21:41:20 sgw_: you can disable ppc Apr 25 21:41:24 for now Apr 25 21:41:31 atleast we will see other issues Apr 25 22:19:14 RP: when will you be travelling to ELC? Apr 25 22:27:20 darknighte: monday Apr 25 22:28:30 RP: ahh, same as me. Apr 26 02:43:45 Khem: FYI got a MUT build going with GCC 4.9 ^^^^ is a failure after that! **** ENDING LOGGING AT Sat Apr 26 02:59:58 2014