**** BEGIN LOGGING AT Tue Nov 19 03:00:00 2013 Nov 19 08:44:58 good morning Nov 19 09:06:37 morning Nov 19 10:31:32 morning all Nov 19 11:08:36 hi bluelightning Nov 19 11:08:48 wearing yocto-project t-shirts Nov 19 11:08:59 I was given in Edinburgh :) Nov 19 11:09:27 free ad for you guys Nov 19 11:14:05 Krz-: nice :) Nov 19 11:23:32 yeah, ELC-E is an important part of the annual shirt supplies. Nov 19 12:23:35 Krz-: cool :) Nov 19 12:24:00 I wish I'd picked up an extra at the booth... I gave away lots of them but only got one for myself Nov 19 12:27:08 How do I get rid of the LIC_FILES_CHKSUM requirement in the recipe? Nov 19 12:27:37 (temporarily) Nov 19 12:28:22 set LICENSE to CLOSED Nov 19 12:29:20 ah. thanks, JaMa Nov 19 12:54:00 hmm, the git fetcher change needs git > 1.8.0 Nov 19 12:54:14 can we require that version of git? Nov 19 12:57:38 can we build it if required? Nov 19 13:06:17 rburton: that is ahrder than it first appears Nov 19 13:06:29 yeah i can imagine, thus the question Nov 19 13:07:38 I've got a feeling ubuntu 12.04 stil uses 1.7.x Nov 19 13:07:54 jackmitchell: it will Nov 19 13:25:39 RP, Fedora 19(?) has 1.8.3.1 Nov 19 13:25:49 but I would expect fedora to be up to date Nov 19 13:44:55 http://pkgs.org/search/?keyword=git&search_on=name&exact=1 Nov 19 13:46:53 I've merged a patch using older more ugly syntax Nov 19 14:30:41 HI all, how to tell in SRC_URI that I want latest git revision, i.e. HEAD Nov 19 14:30:41 ? Nov 19 14:33:44 drasko: set SRCREV = "${AUTOREV}" Nov 19 14:51:43 hi, why is a core-image-minimal boot for more than half a minute? Nov 19 14:51:47 it is really strange... Nov 19 14:51:54 or at least 10-20 sec Nov 19 14:51:58 shouldn't it be under 2-3 seconds? Nov 19 14:52:19 i recommend you profile it and find ut Nov 19 14:52:23 we have bootchart Nov 19 14:52:39 a good bet is udev taking too long on your HW Nov 19 14:53:43 oh, and simply passing "quiet" to the kernel can make a significant difference Nov 19 15:05:34 How to instruct do_compile that make command has to be done from another dir? Nov 19 15:05:54 (switch to th dir before excuting the make and some other stuff, then switch back) Nov 19 15:06:22 drasko: you mean that make should be executed more than once? Nov 19 15:06:50 bluelightning, no, I mean make and some other stuff... like cp, sed... Nov 19 15:07:00 otherwise we can do make -C... Nov 19 15:07:16 kind of looks like you need to define your own do_compile Nov 19 15:07:24 s/looks/sounds/ Nov 19 15:07:56 S controls where the source should be found; if you want the build to be done in a separate directory you can set B to point to a different subdir of ${WORKDIR} Nov 19 15:24:54 hmm, I won't have time to attend the YPTM today :-( Nov 19 15:25:10 not that I usually contribute much.. :) Nov 19 15:28:53 hi Nov 19 15:33:41 Zagor: any progress on the ptest wiki page? Nov 19 15:34:41 rburton: udev taking long? Nov 19 15:34:46 rburton: you mean systemd stuff? Nov 19 15:36:09 sgw_: I'm afraid not. we've had a release crunch here, stealing all my time. Nov 19 15:36:38 lpapp: i mean the udev device probe Nov 19 15:37:23 rburton: means? Nov 19 15:38:27 Zagor: Understood, as mentioned last week there are some other folks that want to contribute updates to ptest and we just don't want to duplicate work. Nov 19 15:39:17 yes, I understand. I think the old mail still gives a pretty good picture actually. Nov 19 15:39:42 lpapp: when udev starts it probes your hardware. that can take a while. Nov 19 15:40:08 lpapp: if you're concerned about boot time, use bootchart and get a detailed breakdown of where the time is going Nov 19 15:40:12 rburton: well, why would that happen before getting a prompt? Nov 19 15:41:15 lpapp: because the udev probe happens very early Nov 19 15:41:25 as i said, that was a guess. use bootchart. **** BEGIN LOGGING AT Tue Nov 19 15:44:20 2013 Nov 19 15:44:21 bluelightning: yeah., that :) Nov 19 15:45:59 bluelightning: http://layers.openembedded.org/layerindex/recipe/930/ Nov 19 15:46:36 lpapp: http://layers.openembedded.org/layerindex/recipe/292/ Nov 19 15:47:14 rburton: I am just showing that to bluelightning there are recipes for both. Nov 19 15:47:41 right, in meta-oe Nov 19 15:48:08 yes Nov 19 15:48:11 oh that recipe is ancient Nov 19 15:48:21 bootchart2 has existed for several years Nov 19 15:48:32 well, 0.0+rX Nov 19 15:48:36 what version number is that? :D :D Nov 19 15:48:43 (for ubootchart) Nov 19 15:49:08 Zagor: thanks, I will put that on to a wiki page, and mark the ones we already have done. Nov 19 15:49:17 lpapp: maybe its never actually been released Nov 19 15:49:22 sgw_: thank you Nov 19 15:49:43 hmm ubootchart seems unmaintained Nov 19 15:49:56 it hasn't moved beyond what we're building Nov 19 15:49:56 lpapp: no tags, no releases, no versions. v0 is about the best you're going to get :) Nov 19 15:50:00 since 2007 Nov 19 15:50:08 bluelightning: probably worth ditching both of those and using bootchart2 Nov 19 15:50:12 apparently busybox provides a tiny bootchart daemon as well... Nov 19 15:50:15 think we should replace ubootchart with bootchart in core...... Nov 19 15:50:18 oh yeah, it does Nov 19 15:50:18 rburton: could be Nov 19 15:50:38 bootchart2 is less python and more C, which should mitigate why ubootchart exists Nov 19 15:50:47 "kinda" Nov 19 15:50:53 leaving the busybox bootchart for the tiny people Nov 19 15:51:13 sounds like a reasonable approach Nov 19 15:51:33 systemd has an integrated bootchart too Nov 19 15:52:08 is that also as bad as udev? :D Nov 19 15:53:18 https://github.com/mmeeks/bootchart/, fwiw Nov 19 15:53:55 The Yocto Project Tech Meeting Con-Call will be starting at the top of the hour Nov 19 15:53:55 Dial-in number: 1.972.995.7777 / Participant passcode: 42001078 Nov 19 15:53:55 This call is open to all and the channel remains open to discuss any topic Nov 19 15:54:30 I propose as a topic a debate on the conclusion of series 3 of The Killing Nov 19 15:55:33 hmm bootchart2 has its own copy of pybootchartgui like we do... Nov 19 15:55:47 so, has anyone used the busybox chart stuff? Nov 19 15:55:50 or the systemd? Nov 19 15:55:52 bluelightning: we both forked pybootchartui Nov 19 15:56:15 bluelightning: meeks is open to merging support for reading our data in that version, fwiw. :) Nov 19 15:57:42 rburton: that's good :) Nov 19 16:01:58 cristiana on the call Nov 19 16:02:04 YPTM: Paul Eggleton is on the call Nov 19 16:02:13 YPTM: Beth Flanagan is on the call Nov 19 16:02:38 YPTM: Corneliu joined Nov 19 16:02:40 YPTM: Scott Rifenbark is on the call Nov 19 16:02:41 * nitink joined the YPTM bridge Nov 19 16:02:49 YPTM: Richard is here Nov 19 16:02:50 YPTM: Polk is on Nov 19 16:02:52 YPTM: AlexG joined. will be here for only 15 minutes Nov 19 16:02:55 YPTM: LaurentiuP joined Nov 19 16:02:58 YPTM: Tom Z on the bridge Nov 19 16:03:11 YPTM: Saul is here Nov 19 16:03:21 IonutC is here Nov 19 16:03:24 YPTM: Cristiana is here Nov 19 16:03:56 YPTM: welcome to the technical team meeting. Any opens? Nov 19 16:04:19 YPTM: source mirror issues Nov 19 16:04:23 YPTM: ross is in Nov 19 16:05:06 YPTM: jzhang on the call Nov 19 16:07:40 YPTM: Darren is on Nov 19 16:12:16 hold on phone issue Nov 19 16:17:49 YPTM: Michael Halstead has joined. Nov 19 16:47:49 Question for whomever: re BB_GENEATE_MIRROR_TARBALLS -- the docs not "performance reasons" .. what reasons Nov 19 16:49:02 presumably the performance overhead of creating the tarballs Nov 19 17:16:25 hmm, does someone want to explain http://autobuilder.yoctoproject.org:8011/builders/nightly-mips/builds/3/steps/Building%20Images_1/logs/stdio to me? :/ Nov 19 17:17:03 recipe linux-yocto-3.10.17+gitAUTOINC+6ad20f049a_2d91e20101-r0: task do_populate_sysroot_setscene: Succeeded Nov 19 17:17:03 NOTE: recipe linux-yocto-3.10.17+gitAUTOINC+6ad20f049a_2d91e20101-r0: task do_populate_sysroot: Started Nov 19 17:17:16 NOTE: recipe linux-yocto-3.10.17+gitAUTOINC+6ad20f049a_2d91e20101-r0: task do_populate_sysroot: Failed Nov 19 17:47:22 Good morning! Does anyone know if Debian SCM is down? ca_certificate is getting fetch fail Nov 19 17:50:24 b1gtuna: yes, there has been a problem since last week, we know about it and there was also a bug found in the fetcher, we have it in the mirror Nov 19 17:51:37 sgw_: hmm the premirror didn't work for me. I should check up on that Nov 19 17:52:31 b1gtuna: are you using master? Nov 19 17:53:07 I'm on Dora Nov 19 17:54:07 I am not modifying the premirror related configurations. Do you think perhaps the bug fix did not get backported? Nov 19 17:56:17 b1gtuna: it was just fixed today, so probably not backported yet, but will be Nov 19 17:56:47 b1gtuna: you could possibly take the top commit from master and cherry-pick it into dora to test. Nov 19 17:58:33 sgw_: good stuff, I can definitely try it out. Do you have a link to it? I searched in the OE mailing list, it's not coming up Nov 19 18:00:05 sgw_: thanks Nov 19 18:00:41 possibly on the bitbake mailing list, http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=215dab864e7cf74394840621ad0754db593708f1 Nov 19 18:00:58 actually you might need the top two patches from poky/master Nov 19 18:03:01 sgw_: great! One last question - will this eventually get backported to Dora? Or have you guys already moved on? Nov 19 18:04:34 b1gtuna: dora is in stable mode, we are working on a 1.5.1 so these will be back-ported soon. Nov 19 18:06:12 sgw_: gotcha. thank you very much Nov 19 20:32:08 otavio_: around, have you seen bug 5551? Nov 19 20:32:09 Bug https://bugzilla.yoctoproject.org/show_bug.cgi?id=5551 major, Undecided, ---, otavio, NEW , 3.10.9 Kernel hanging on fsl-image-gui Nov 19 23:23:22 sgw_: Nov 19 23:23:23 hi Nov 19 23:23:25 was out Nov 19 23:24:29 sgw_: #5551 is forwarded to someone but no reply yet :-( Nov 19 23:28:22 otavio: no worries, what's the priority for it? Med/Med+? Nov 19 23:32:21 sgw_: Med+ Nov 19 23:32:31 sgw_: I am looking at it but not in public Nov 19 23:32:41 sgw_: you know how it works :( Nov 19 23:32:55 So, I got curious about a thing, which is that a badly-broken config may be so broken that bitbake can't even get close to the point of dumping variables, which makes them hard to debug. Nov 19 23:32:58 sgw_: in fact I requested for it to be reported Nov 19 23:33:07 sgw_: ;) Nov 19 23:33:16 And I started messing with this to see if I can find a way to make it so that bitbake will survive long enough to give useful diagnostics. Nov 19 23:33:57 otavio: 1.5.1 issue or is that only 1.6 Nov 19 23:34:06 And I found a fascinating thing, which is that if part of the name that it wants to use for a run.do_some_task file is a variable which is not defined, the file may actually get created with a name containing a literal ${variable_with_no_value}, but the attempts to interact with that file later replace the name with "". Nov 19 23:36:22 hah Nov 19 23:37:11 Our system has a really early gen_sysroot_properties. My test case was just to break a qemuarma9 tuning (our armv7a thing) by setting DEFAULTTUNE to "". Nov 19 23:37:38 So now I am looking to try to figure out what generated the actual literal filename "./tmp/work/${ARMPKGARCH_tune-}-wrs-linux-gnueabi/bblayers/..." Nov 19 23:38:07 My ideal goal would be for bitbake -e to work even if you have something severely broken, so you can at least get some idea of what is or isn't wrong. Nov 19 23:38:35 sgw_: 1.5.1 Nov 19 23:39:38 otavio: done Nov 19 23:42:09 Anyone familiar with data_smart happen to know what determines whether an expansion leaves unmatched variables in as text, or replaces them with ""? Nov 19 23:44:15 seebs: it always leaves an undefined variable as is Nov 19 23:44:20 it only replaces with "" if the value is "" Nov 19 23:44:32 * kergoth hates that we did that Nov 19 23:44:38 Wait, always? Nov 19 23:44:40 * kergoth wishes it errored when expanding undefined vars Nov 19 23:44:50 well, it's not going to flip a coin Nov 19 23:44:51 Because I have stuff like ${OPTIONAL_EXTRA} in FILES_foo sometimes. Nov 19 23:44:54 yes, that's the behavior Nov 19 23:45:08 And if I never define ${OPTIONAL_EXTRA}, the resulting value shown in the output is empty. Nov 19 23:45:14 that wont hurt, since that exact value won't be found Nov 19 23:45:34 ... Hmm. I might have an OPTIONAL_EXTRA_append_override. Does that make OPTIONAL_EXTRA have an empty value even if that particular override doesn't apply? Nov 19 23:45:46 don't know what you tell you, bitbake never substitutes the empty string if a var is unset Nov 19 23:45:51 Huh. Nov 19 23:45:52 hmm, seems unlikely, but possible? Nov 19 23:46:01 if so i'd argue it's a bug Nov 19 23:46:20 The errors I'm getting come from when bitbake, having created a file named ${ARMPKGARCH_tune-}-foo, then can't find the directory -foo to cd to. Nov 19 23:46:29 Whereas if it looked for ${ARMPKGARCH_tune-}, it... Nov 19 23:46:30 oh, hey. Nov 19 23:46:36 Becuase that's made it on to the shell. Nov 19 23:46:38 D'oh. Nov 19 23:46:50 Because, even. Nov 19 23:46:53 *thinks* Ugh. Nov 19 23:47:56 * kergoth hopes we can change this behavior in the long term, it just adds to confusion due to bitbake and shell using the same variable expansion syntax Nov 19 23:48:18 Yes, yes it does. Especially because I sometimes want to use shell substitutions which really do require me to use ${foo:-bar} type stuff. Nov 19 23:48:28 yeah, me too Nov 19 23:48:44 And I found what's biting me. The run.* script contains "cd /path/to/workdir" with no quotes. Nov 19 23:49:00 It should probably single-quote that path since it knows that the *intent* is that there are no variables to expand. Nov 19 23:50:06 Oh, wow, that helps immensely. Nov 19 23:50:30 Okay, that's a one-line patch that got me from 300+ lines of incomprehensible gibberish to 10 lines of output that actually told me what was wrong. Nov 19 23:50:58 nice Nov 19 23:51:45 Still can't use bitbake -e on it, though. Hmm. Nov 19 23:52:06 I really want -e to work even if sanity checks fail. Nov 19 23:54:48 agreed Nov 19 23:55:02 ... Well, okay, there's an easy solution, which is: If you add -e, just manually set DISABLE_SANITY_CHECKS = "1" Nov 19 23:55:26 Although I don't really like that, because I want them to run, I just don't want them to kill execution. Nov 19 23:58:13 i'd thought most were running at BuildStarted time rather than ConfigParsed time, but maybe not Nov 19 23:58:35 Sanity checks run at ConfigParsed, probably to keep from re-running the expensive ones. Nov 19 23:59:18 And it looks like the sanity check handler is explicitly exiting, causing the caller to get a SystemExit exception. And I think I'd rather have it raise an exception which the caller can decide how to handle based on other context, like "whether we think we are doing tracking". Nov 19 23:59:24 BuildStarted only runs once too, after the config files are parsed, but before the build runs Nov 19 23:59:27 * kergoth shrugs Nov 19 23:59:50 I *thought*, possibly incorrectly, that if you ran multiple builds (because something was failing), later builds might not need a new ConfigParsed unless config changed. Nov 20 00:00:42 i thought the event was always fired, but that it checked the sanity stamp in ${TOPDIR}/conf/ to see if it needed to run Nov 20 00:00:45 but could be wrong Nov 20 00:00:54 actualy, half the build would fail if configparsed didn't fire Nov 20 00:01:01 it's often used to do programmatic modification of the config metadata Nov 20 00:01:11 Compelling point. Nov 20 00:01:20 Huh. I can't figure out what's *causing* the SystemExit exception. Nov 20 00:11:21 Got it. Woo! Nov 20 00:31:00 I sent patches. Two tiny patches (one and three lines, respectively) to bitbake, and then a fairly small oe-core patch. Nov 20 00:31:18 With them, "bitbake -e" works if you unset DEFAULTTUNE, despite all the horrific ways in which this breaks the setting of various variables. Nov 20 00:33:09 Not that I break my tuning or machine definitions in ways that break TUNE_PKGARCH once or twice a week or anything. That would be ridiculous. Nov 20 00:34:29 that wouldn't faze some people i know... Nov 20 00:45:11 ... and of course there were tabs in one patch. fixed. **** ENDING LOGGING AT Wed Nov 20 02:59:58 2013