**** BEGIN LOGGING AT Thu Dec 29 02:59:57 2011 Dec 29 09:16:48 morning all Dec 29 14:22:46 morning Dec 29 14:23:46 hi kergoth Dec 29 14:25:37 kergoth: do you think "import bb.fetch2" would be acceptable now in bitbake-layers for bitbake master? or do we need to resort to a wrapper script in OE-Core for that? Dec 29 14:25:41 http://bugzilla.pokylinux.org/show_bug.cgi?id=1855 for reference Dec 29 14:25:51 bluelightning, that doesn't seem unreasonable Dec 29 14:26:32 ok, that keeps things simple... thx Dec 29 14:26:34 Hm, we should look into some sort of gathering up of error messages for knotty and summarize of them at the end. whenever you do a build with parallel, the errors are buried way up in the output, not ideal usability. I end up doing all my builds with -k, so a subsequent build will show the problem near the bottom :) Dec 29 14:26:35 np Dec 29 14:27:06 kergoth: IIRC that is on our todo list to implement Dec 29 14:28:04 hmm, might be this is all we have atm: http://bugzilla.pokylinux.org/show_bug.cgi?id=1540 Dec 29 14:29:25 Hmm, of course the hard part would be context. we can easily store up ERRORs and dump them, but they might need more context to understand, perhaps. *thinks* Dec 29 14:30:25 speaking of which, i've been thinking it'd be nice to inject things like recipe name, task name into the log messages automatically, so we aren't always having to do it manually in the metadata. that'd attach a certain amount of context automatically Dec 29 14:30:39 * kergoth adds to todo to evaluate the amount of work involved to prototype that Dec 29 14:32:53 hmm, thats an idea, could attach the contextual logger to the datastore. d.info(). *thinks* Dec 29 16:30:30 how can we access the a layer's root dir? what's the variable? Dec 29 16:37:14 don't think there is such a thing. there's a variable for oe-core specifically.. Dec 29 16:43:22 kergoth: dam, so for a custom layer, there's no way to point to it's license from a bb file? Dec 29 16:43:36 meta-foo/LICENSE Dec 29 16:43:56 not that I know of. you could find the layer programmatically easy enough relative to FILE, or use a relative path from the recipe. I could be wrong, but that's my understanding Dec 29 16:44:12 k, trying relative Dec 29 16:51:44 kergoth: LICENSE_FILE := "${@os.path.abspath(os.path.join(os.path.dirname(bb.data.getVar('FILE', d)), '..', '..', 'LICENSE'))}" Dec 29 16:58:37 LICENSE_FILE := "${@os.path.abspath(os.path.join(THISDIR, '..', '..', 'LICENSE'))}" would also work Dec 29 16:58:50 (thisdir is just a dirname of FILE, for convenience) Dec 29 17:45:23 oe-core/scripts/bitbake: line 95: 7703 Segmentation fault PSEUDO_BINDIR=$PSEUDOBINDIR PSEUDO_LIBDIR=$PSEUDOBINDIR/../lib/pseudo/lib PSEUDO_PREFIX=$PSEUDOBINDIR/../../ PSEUDO_DISABLED=1 $PSEUDOBINDIR/pseudo $BITBAKE $@ Dec 29 17:45:24 yow Dec 29 17:45:35 * kergoth scratches head Dec 29 17:47:43 oh weird, i get a segfault running the hob script, but not the bitbake script Dec 29 17:49:22 yep, every time Dec 29 17:49:38 hrm Dec 29 17:56:47 yeah, i definitely can't run hob. segfaults every time. ubuntu 10.04 64 bit, latest updates applied, stock python Dec 29 17:56:48 hmm Dec 29 18:03:32 * kergoth rebuilds pseudo and checks again Dec 29 18:06:33 how do I know if my .bbappend is being included? Dec 29 18:09:01 set FOO=1 Dec 29 18:09:06 then bitbake -e recipe | grep FOO= Dec 29 18:09:26 thats the quickest way. you could crank up debugging or something and try to see the parse messages, but there'll be so much output it'd be a giant pain to deal with Dec 29 18:09:27 this is easier Dec 29 18:10:26 k, doin that Dec 29 18:11:19 kergoth: hmm, I got FOO on the output Dec 29 18:11:32 but it seems that my files are not beeing picked up first Dec 29 18:11:43 PRINC = "1" Dec 29 18:11:46 make sure your layer priority is higher than the other layers Dec 29 18:11:48 FILESEXTRAPATHS_prepend := "${THISDIR}/files:" Dec 29 18:11:57 SRC_URI_append = " file://psplash-lw-bgcolor.patch " Dec 29 18:12:06 kergoth: mine is at 20 Dec 29 18:12:35 I think default is 5 Dec 29 18:22:54 s0undt3ch: bitbake -e recipe | grep FILESPATH should show you the search path being used to find the files Dec 29 18:22:55 kergoth: got it to work, Thanks! Dec 29 18:23:05 bluelightning: Thanks Dec 29 18:23:06 s0undt3ch: what was the problem? Dec 29 18:23:33 bluelightning: i needed to clean the package, editing the bbappend did not trigger a rebuild of that package Dec 29 18:24:46 s0undt3ch, editing fiels never causes an automatic rebuild, unless you're using a non-standard bb signature handler Dec 29 18:24:49 have to bump PR or clean Dec 29 18:25:15 kergoth: yeah, never remembered to bump PR Dec 29 18:25:22 :) been there Dec 29 18:28:42 should recipes with the same PV be ignored in layers with a lower priority? Dec 29 18:29:55 or does one need to only have one recipe with the same PN/PV/PR ? Dec 29 18:30:04 need = required to have Dec 29 18:35:48 I don't understand the question Dec 29 18:36:48 if you have a recipe in two layers, it'll use the higher priority one and ignore the other, whether they have the same PV or not Dec 29 18:36:50 so its not really a factor Dec 29 18:50:25 kergoth: i think it spits out a warning though Dec 29 18:50:50 kergoth: ERROR: Multiple .bb files are due to be built which each provide virtual/libgl (/home/jenkins/poky/meta/recipes-graphics/mesa/http://mesa-xlib_7.10.2.bb/ /home/jenkins/poky/meta-oe/meta-oe/recipes-graphics/mesa/http://mesa-dri_7.10.2.bb/). Dec 29 18:51:03 thats entirely different Dec 29 18:51:06 completely different problem Dec 29 18:51:11 thats two different recipes that provdie the same functionality Dec 29 18:51:25 and are both being pulled in via dependencies Dec 29 18:51:46 the version is irrelevent Dec 29 18:51:53 they both share en entry in their PROVIDES Dec 29 18:51:58 s/en/an/ Dec 29 18:52:01 ahh Dec 29 18:52:14 kergoth: is there a good way to handle this? or just remove one of the recipes? Dec 29 18:52:33 yes, fix the broken dependencies Dec 29 18:52:44 something is explicitly depending on one of those, not via the item in PROVIDES Dec 29 18:52:48 forcing bitbake to build both Dec 29 18:53:07 if a PROVIDES c and b PROVIDES c, and d DEPENDS on a and e DEPENDS on c, it will have to build both a and b, as both got pulled into the runqueue Dec 29 18:53:17 if you were to modify d to DEPENDS on c instead, it would only build the preferred provider of c Dec 29 18:53:42 kergoth: got it, makes sense Dec 29 18:54:12 that probably wasnt the best description, but thats the simplest case of this i can come up with :) Dec 29 19:02:26 erm, the above description would only hold true if b was the PREFERRED_PROVIDER, but you get the idea Dec 29 19:02:32 heh Dec 29 19:46:09 Who was it that did buildhistory, again? Dec 29 21:46:38 hmm, meta-ti's u-boot.inc is broken wrt do_deploy. doesn't install to DEPLOYDIR Dec 29 22:07:31 kergoth: me Dec 29 22:07:41 kergoth: some issues? Dec 29 22:08:10 ah, right. minor issue: if you enable committing, and you ^C a build, then let it die without forcing it further, it thinks the build succeeded, and chokes when there are no files to commit Dec 29 22:08:25 should probably check status or something first Dec 29 22:08:26 * kergoth shrugs Dec 29 22:14:22 * sgw sez Happy New Year all, out for now, but back later to check on builds Dec 29 22:14:39 kergoth: is there an easy way to figure out the final status of the build in the BuildCompleted event? Dec 29 22:15:34 afaik its hould be firing a failure event if hte build actually failed, but that isn't whats happening here, the build was interrupted.. I don't think we have an event for that :) Dec 29 22:15:46 * kergoth checks the code Dec 29 22:16:19 the thing is, we definitely want to commit the results of any packages that were built Dec 29 22:16:36 even if the user breaks out afterwards Dec 29 22:16:43 i know, its just the case where there's *nothing* to commit that it needs to handle Dec 29 22:16:53 okay, BuildCompleted gets passe dthe build name, targets, and failures Dec 29 22:17:22 but even then that isn't ideal. just because what i wanted to run completed doesn't mean there's anything for buildhistory to capture, no? Dec 29 22:17:34 maybe I should just check if there's nothing to commit first and then skip Dec 29 22:17:37 yep Dec 29 22:17:43 thats what i suggested before, just use git status or similar Dec 29 22:17:55 ok, that's trivial... will do that tomorrow Dec 29 22:18:06 its a minor thing, just wanted to throw it out there Dec 29 22:18:08 thanks Dec 29 22:18:34 yeah, I'm keen to prevent pain when it's used because it will encourage more people to use it and hopefully catch more issues Dec 29 22:18:39 :) Dec 29 22:18:41 * kergoth nods Dec 29 22:18:43 good point Dec 29 22:19:09 we still have an annoying issue with git PVs going backwards that buildhistory flags up Dec 29 22:19:13 the other thing, i didn't realize when first using it that i'd have to git init myself. it does make sense, but it dies unpleasantly in that case rather than telling me Dec 29 22:19:30 hmm ok, I'll try to address that as well Dec 29 22:19:46 i know enough git to easily realize what i needed to do, but probably best to print a nice message if we can Dec 29 22:19:48 :) Dec 29 22:20:05 can probably just do a git rev-parse --git-dir or similar to verify that you're inside a git repository Dec 29 22:21:46 would it be OK to just init if necessary? Dec 29 22:22:07 that works too. it maintaining its own repository was my initial expectation Dec 29 22:22:13 ok Dec 29 22:22:14 guess it depends on the sorts of usages we expect Dec 29 22:22:20 but that seems like a fine idea to me Dec 29 22:22:41 if you rm -rf tmpdir a lot and leave buildhistory at the default it would probably help to auto-init Dec 29 22:22:48 * kergoth had a class somewhere one time that captured WORKDIR in a git repository and tagged the stamps :) Dec 29 22:22:52 er, i mean leave the buildhistory dir at the default Dec 29 22:22:59 ah, yes, good point Dec 29 22:28:50 * bluelightning -> bed Dec 29 22:58:38 Hmm, it'd be cute to make a summary display at the end of the build with info from the buildhistory Dec 29 22:59:28 hmm Dec 29 23:33:24 gah Dec 29 23:33:25 | flex.real: fatal internal error, exec failed Dec 29 23:33:31 what the hell is that? :| Dec 29 23:52:10 Well, that probably means that some binary named flex.real tried to call exec, and failed. Dec 29 23:52:14 <-- really helpful Dec 29 23:58:34 :) **** ENDING LOGGING AT Fri Dec 30 02:59:57 2011