**** BEGIN LOGGING AT Thu Aug 20 02:59:59 2015 Aug 20 08:48:10 odd. "SRCBRANCH ?= mybranch" is in my kernel recipe, but bitbake -e shows that SRCBRANCH is never set. this is with master. Aug 20 08:48:30 renaming SRCBRANCH to SRCBRANCHX shows that SRCBRANCHX is set. Aug 20 08:48:39 is something unsetting SRCBRANCH ? Aug 20 09:03:20 ah. debug output shows: "$SRCBRANCH [2 operations]" any way to trace these 2 operations? Aug 20 09:11:14 dv__: erm, they ought to be listed right underneath that Aug 20 09:11:22 morning all Aug 20 09:11:37 bluelightning: only one is listed Aug 20 09:11:59 ah, I think I know. deep inside an .inc file, I have a line: SRCBRANCH ?= "" Aug 20 09:12:39 so this line is first executed (and SRCBRANCH = "" is what shows up in the debug output), but the second line ( "SRCBRANCH ?= mybranch") isnt ran. Aug 20 09:12:52 the odd thing is, this worked in fido before, but not in master ... ? Aug 20 09:13:17 er, that sounds rather unlikely Aug 20 09:13:25 ?= means "set if not already set" Aug 20 09:13:58 so naturally if you have one that follows the other in the parse order, the second will not do anything (and won't show up in the history, because it had no effect) Aug 20 09:14:09 that behaviour has not changed Aug 20 09:14:10 yes, agreed. which makes me wonder why this worked in the first place. Aug 20 09:15:03 it would be worth going back to fido and checking, because there must be more to this Aug 20 09:15:56 riight, git blame shows that this .inc wasnt like that before. Aug 20 09:16:05 thats why it worked Aug 20 09:17:34 essentially this was a dormant bug in my recipe that got triggered by a change elsewhere Aug 20 09:18:24 I noticed this because git wouldnt fetch . turned out that since SRCBRANCH was empty, "branch=${SRCBRANCH}" evaluated to "branch=" Aug 20 09:18:51 is there any valid case for "branch=" ? because if not, I'd suggest a sanity check to warn that the branch is empty Aug 20 09:20:13 hmm, right, yes... we should have a check for that Aug 20 09:32:29 another question: I am preparing patches for gstreamer 1.6. the first release candidate is already out. but there is a problem with the -bad package. Aug 20 09:33:16 its configure.ac looks for an opencv path. it first asks pkg-config for the prefix variable, and then checks for $prefix/share/opencv . Aug 20 09:33:37 but since pkg-config --variable is not cross compilation friendly, this will evaluate to /usr/share/opencv Aug 20 09:33:54 I am not sure how to handle this. somehow I have to inject the sysroot into this. Aug 20 09:34:44 the problem is here: http://cgit.freedesktop.org/gstreamer/gst-plugins-bad/tree/configure.ac#n2484 Aug 20 09:35:19 (it also uses AC_CHECK_FILE , which too is cross compilation unfriendly, but this is a separate issue, and one that I can easily fix by using test -d instead) Aug 20 09:55:17 why on earth would they do that and not just use pkgconfig properly Aug 20 09:55:50 oh right, http://cgit.freedesktop.org/gstreamer/gst-plugins-bad/commit/configure.ac?id=07ee52db5dbddf35ab22199a1960e9f5cc8aae73 Aug 20 09:56:25 you might want to rip all that code out and hardcode the values we use? Aug 20 10:02:58 I'd prefer something I can push upstream Aug 20 10:03:19 I think the fault is actually in the opencv .pc , which should include a variable for this data directory Aug 20 10:04:11 but yeah, if it is not possible to upstream something, I can have an OE specific patch that is not upstreamed Aug 20 10:05:43 hmmm. what about patching the configure.ac to allow for a custom OPENCV_PATH_NAME Aug 20 10:06:17 something like: if test "x$OPENCV_PATH_NAME" = "x" ; then < the existing block > Aug 20 11:42:05 dv__: iirc there is a way you can make this work with pkgconfig Aug 20 11:42:21 dv__: you just prepend the return value with the pkgconfig sysroot Aug 20 11:43:29 dv__: so $PKG_CONFIG_SYSROOT_DIR`pkg-config --variable` Aug 20 11:43:44 and if no sysroot is set, it just works too Aug 20 11:45:07 dv__: See recipes-graphics/xorg-xserver/xserver-xorg/macro_tweak.patch or recipes-gnome/gnome/gnome-doc-utils/sysrooted-pkg-config.patch Aug 20 11:45:18 or recipes-graphics/xorg-lib/libxcb/xcbincludedir.patch Aug 20 11:45:23 looks like we have a few of these :/ Aug 20 12:01:04 "error: possibly undefined macro: PKG_CONFIG_SYSROOT_DIR" Aug 20 12:01:52 sigh .... autoconf is being lovely again Aug 20 12:03:35 ah look at that. x also has patches for that. m4_pattern_allow(PKG_CONFIG_SYSROOT_DIR) Aug 20 12:18:24 added gpg to my image, but when I try to use it I get: can't create directory '/home/root/.gnupg': Permission denied Aug 20 12:28:50 creating the directory manually works fine, but when gpg tries, it fails Aug 20 12:42:07 hm during the gstreamer recipe upgrades, several patches no longer apply. some of them are trivial to fix, some are more significantly broken. Aug 20 12:42:37 is there an OE policy for such situations? because I'd just delete these patches and request reworked ones from the original authors Aug 20 12:53:50 I currently have no .conf other than local.conf in my layer. Is that where I should/can put my PREFERRED_VERSION statements? Aug 20 13:02:52 gpg 1.4.7 decrypts my files just fine. 2.1.1 (which is default in 1.8) does not. Aug 20 13:06:45 security improved! Aug 20 13:07:16 :) Aug 20 13:24:29 RP: your idea was accepted https://bugzilla.gnome.org/show_bug.cgi?id=753651 Aug 20 13:27:54 dv__: cool :) Aug 20 13:31:25 any idea about the thing with the patches I mentioned? Aug 20 13:35:54 dv__: was this the recently added fairly large set? I'd contact the person who added them Aug 20 13:38:51 RP: yeah that Aug 20 13:39:41 half of the patches are backports and therefore can be deleted without problems. but the others, well.. I see no other way than to delete them in the upgrade commit and reintroduce them later after they got reworked Aug 20 13:40:05 dv__: right :/ Aug 20 13:40:13 dv__: Just give that person a heads up Aug 20 13:40:20 agreed Aug 20 16:06:43 WARNING: Failed to fetch URL hg://vim.googlecode.com/hg/;protocol=https;module=vim, attempting MIRRORS if available Aug 20 16:07:40 the move to github is in progress Aug 20 16:07:50 not sure what the status is, though Aug 20 16:08:11 the "NOT READY YET" at https://github.com/vim/vim is slightly concerning Aug 20 16:09:09 hmm Aug 20 16:09:11 annoying Aug 20 16:09:39 screwing up my post trip master build si i can get back to work Aug 20 16:49:05 Crofton: do you have bitbake with fix for hg repos? Aug 20 16:49:53 Crofton: if it's down because of move to github than it's a shame that we'll loose last real-world test case for hg fetcher in public layers (I know of) Aug 20 16:50:17 based on kergoth remarks they aer moving Aug 20 16:50:38 it's the top item on teh news on vim.org Aug 20 16:50:53 JaMa: googlecode... Aug 20 16:51:04 down eventually anyway Aug 20 16:54:34 ah, right Aug 20 17:14:44 How abominable would it be if we pushed an empty layer (no recipes, .conf file only containing comments) to github, solely so that we could store organization-wide site configuration bits like PACKAGE_FEED_URIs, PRSERV_HOST, etc. in a private branch that we don't push to github? Aug 20 17:15:27 (I mean a very hypothetical "we"; some of my coworkers find the idea abominable) Aug 20 17:18:01 there's nothing *wrong* with having a layer that has no recipes in it, necessarily. Aug 20 17:20:29 well, part of the controversy here is that the distro uses git submodule layers instead of combo layers, and .gitmodules in the top-level distro repo refers to a *single* ref for this layer, which is a *different* branch between our internal git server and github Aug 20 17:20:42 i.e. we rename the public branch on the push Aug 20 17:21:08 There is a degree of magic embedded in that which causes some justifiable nervousness Aug 20 17:21:40 but there's also a belief that pushing empty repos just makes us look bad Aug 20 17:22:21 couldn't you also just use a private repo, or an internal one? Aug 20 17:23:30 we are, but I would like a `git clone` of the distro on the internal server to automagically configure itself for an internal build, and for a `git clone` of the github repo to automagically configure itself for a "normal" build, without any manual configuration Aug 20 17:23:55 and most preferrably, for as many repos/layers as possible to have no changes whatsoever betwene private and public branches Aug 20 17:25:02 there is a separate discussion to add a private repo, but that is probably going to require manual bblayers edits as a matter of course; this doesn't Aug 20 17:25:39 i.e., local.conf.template would include a .conf from the layer which happens to be empty in the branch pulled from github, but non-empty in the branch pulled from the internal git server Aug 20 17:26:54 (the neologism "branch twist" was inadvertently invented to describe this) Aug 20 17:28:39 so, hinky? or not hinky? :F Aug 20 18:28:41 oe-classic, I'm trying to do an alsa-lib bbappend to add a patch, and I'm getting a "ERROR: Function 'Unable to locate local file for file://fix-tstamp-declaration.patch' failed" which is in the classic tree. i'm sure I just goofed up a path somehow. Is there any way to get it to tell me what path it is working with? "bitbake -v -v -v -v -v -v" didn't help me. Aug 20 19:45:46 sgw_: Has anyone yelled at you for breaking "dizzy" today yet? :) Missing '\' on that grub patch Aug 20 19:45:49 ... afk Aug 20 19:46:27 Tartarus: yes and I am being yelled at for other things also Aug 20 19:46:42 OK thanks ;) Aug 20 19:46:48 Have a better rest of the day Aug 20 19:48:59 * kergoth chuckles Aug 20 23:34:02 hmm, why does libjpeg-turbo not set COMPATIBLE_HOST? Aug 20 23:35:20 ah, i see **** ENDING LOGGING AT Fri Aug 21 02:59:58 2015