**** BEGIN LOGGING AT Thu Nov 10 03:00:00 2016 Nov 10 17:53:21 hmm, meta-fsl-arm layer does not have a morty branch? what's the revision that matches poky's 2.2 release? Nov 10 17:53:50 oh, they moved to another git url Nov 10 18:00:50 mhm ok, meta-fsl-arm-extra became meta-freescale, but meta-fsl-arm is still as it is, but has no morty branch? Nov 10 18:02:22 or were they both merged into one meta-freescale? Nov 10 18:03:16 if it is the case, then its still wrong here http://layers.openembedded.org/layerindex/branch/master/layers/ Nov 10 18:45:53 berton: Hi Jin^eLD meta-fsl-arm was renamed to meta-freescale and morty branch will be only available in meta-freescale layer. Also, meta-fsl-arm-extra renamed to meta-freescale-3rdparty and meta-fsl-demo to meta-freescale-distro Nov 10 18:47:43 oooh ok, thank you, so I am missing the meta-freescale-3rdparty checkout then Nov 10 18:49:23 Jin^eLD: And yes, we need to update layeri index. Thanks to reporting this. Nov 10 18:49:55 :) Nov 10 18:54:02 berton: and meta-freescale is on the yocto's git server while meta-freescale-3rdparty is only on github? Nov 10 18:56:47 Jin^eLD: Yes, 3rdparty it's available on Github Nov 10 18:57:15 ok thx, just making sure I use the correct repos and not some mirror Nov 10 18:59:28 Jin^eLD: You can use fsl-community-bsp-platform that will download all sources for you Nov 10 19:01:30 not really familiar with that... we have a fixed git setup with submodules that track different poky releases and different package feeds for alpha/beta testing and so on until it propagates into the field Nov 10 19:07:57 berton: just a warning, if you don't have a master branch currently the layer won't show up under the default view (master) in the layer index Nov 10 19:09:01 we can internally set the branch name for master for meta-freescale and pretend that they are the same thing, but that of course will have to be updated every release Nov 10 19:17:15 bluelightning: meta-freescale currently has morty, master and master-next branches Nov 10 19:17:44 berton: ah ok, no worries then - I was just going by your comment above which said it would only have morty Nov 10 19:18:17 there are certainly layers out there that don't have a master branch Nov 10 19:24:10 mhm, I am migrationg from poky 2.0.2 to poky 2.2, it's now searching for bblayers.conf in another location than before, although I did not modify my overall setup (i.e. local.conf, environment is the same) Nov 10 19:24:24 which variable defines the config search path? Nov 10 19:26:12 I thought it would look under $BBPATH first? Nov 10 19:27:26 instead it seems to try $TOPDIR/conf/bblayers.conf Nov 10 19:27:38 any hints? Nov 10 19:34:38 was BB_ENV_EXTRAWHITE dropped in 2.2? Nov 10 19:37:03 Jin^eLD: BBPATH is *set* by bblayers.conf, how would it search BBPATH to find it? Nov 10 19:37:10 no, BB_ENV_EXTRAWHITE still works fine Nov 10 19:38:05 kergoth: since when is bbpath set by bblayers.conf? are you sure you are not confusing it with BBLAYERS? Nov 10 19:38:22 http://www.yoctoproject.org/docs/2.2/ref-manual/ref-manual.html#var-BBPATH Nov 10 19:38:43 the point is, until bblayers.conf and all layer.confs are parsed, bbpath isn't worth crap Nov 10 19:38:46 from what I read its exactly what I use it for... export it in the shell to tell bitbake where to look for all the configs? Nov 10 19:38:47 using it to find bblayers.conf would be pointless Nov 10 19:39:01 is this new? Nov 10 19:39:01 no. BBPATH on its own is only useful if you're not using bblayers at all Nov 10 19:39:12 bummer... Nov 10 19:39:21 BBPATH predates bblayers. it was used to manually construct your setup Nov 10 19:39:38 and bblayers.conf was always found by searching upward from $PWD for conf/bblayers.conf, or checking TOPDIR specifically if set Nov 10 19:39:47 well that's what I had, a constructed setup... which now fails with the move to 2.2 :) so I am trying to figure out how to reconstruct it ;) Nov 10 19:39:59 the entire purpose of bblayers.conf, layer.conf, and bblayers was to set BBPATH and BBFILES based on your layer selection Nov 10 19:40:01 ok wait.. so pwd/conf should be fine? Nov 10 19:40:15 because thats my setup Nov 10 19:40:32 I have $pwd/conf/bblayers.conf and $pwd/conf/local.conf Nov 10 19:40:38 not sure what the behavior is when $PWD and $TOPDIR aren't the same Nov 10 19:40:56 it worked well earlier so not sure if something has changed now.. Nov 10 19:40:56 well, if $PWD is relative to $TOPDIR< then it'll work by searching upward from $PWD to / Nov 10 19:41:06 layer processing logic hasn't changed in a long time Nov 10 19:41:17 afaik anyway, i doubt richard snuck it in Nov 10 19:42:14 then I wonder why it fails if it worked on 2.0.2 in the same setup... Nov 10 19:42:15 https://pastebin.mozilla.org/8926972 Nov 10 19:42:19 I get a python error actually Nov 10 19:43:07 which from what I can see boils down to not finding bblayers.conf in $TOPDIR/conf Nov 10 19:43:16 that error doesn't have anything to do with bitbake at all, it's the sanity checker. guessing maybe there's an assumption about how it's laid out in the sanity checking code in oe-core Nov 10 19:43:41 oh Nov 10 19:44:01 mhm I guess I should diff the changes in the sanity checker then Nov 10 19:45:00 i'm guessing this must be a configuration that isn't covered by the unit tests, otherwise it'd have been caught before now. one that bitbake supports, but folks forgot about when writing the code to check and update bblayers Nov 10 19:46:08 so whats this "layer update"? Nov 10 19:46:25 auto bump of LCONF_VERSION? Nov 10 19:46:28 or what exactly does it do? Nov 10 19:46:46 hmmm Nov 10 19:47:06 yeah, deals with bblayers version bumps. increments the version and adjusts the version change Nov 10 19:47:25 hm, ok so let me try to bump it manually to get around this Nov 10 19:47:43 because from what I can see in the trace, its the autoupdate function thats failing Nov 10 19:48:39 ah, yeah, that should work then Nov 10 19:49:30 ok thats odd, my version with 2.0.2 was 6, and if I grep poky now its back to 2? Nov 10 19:49:40 we definitely broke running bitbake from any directory at some point in the last few releases... but that's not quite the same thing Nov 10 19:50:14 Jin^eLD: are you sure you're looking at the same thing? we wouldn't have gone backwards Nov 10 19:51:08 ok you are right, it grepped me the .sample Nov 10 19:51:15 but where is the actual version set or stored? Nov 10 19:51:48 https://pastebin.mozilla.org/8926976 Nov 10 19:52:52 oh well, just increasing it by one to "7" seems to have done the trick Nov 10 19:53:26 at least it now started to fail in my own .bbclass'es :) so its a step forward Nov 10 19:55:33 Jin^eLD: you are referring to the migration guide right? not that I recall it covering this stuff specifically, but it's good to be looking at when doing an upgrade Nov 10 19:56:01 bluelightning: uhm, which migration guide? I was just looking at the 2.2 manual... Nov 10 19:56:45 Jin^eLD: yeah it's in the 2.2 manual: http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#moving-to-the-yocto-project-2.2-release Nov 10 19:56:54 which btw brought me to the next question, what exactly does the expansion parameter do in d.getVar? I did not understand that from the manual, what is the effective difference between d.getVar('FOO', True) and d.getVar('FOO', False) ? Nov 10 19:57:47 Jin^eLD: when you set variables B = "1", A = "${B}" for example, the expansion of ${B} doesn't happen immediately on that second assignment Nov 10 19:57:51 bluelightning: oh thanks, that's an important read Nov 10 19:58:26 Jin^eLD: if you do d.getVar('A', True) you get "1" but with d.getVar('A', False) you'll get "${B}" Nov 10 19:58:29 bluelightning: ah, I think I got it, so I use True wherever I need the actual value and false for contructing stuff, thats what the manual meant Nov 10 19:58:34 got it, thanks Nov 10 19:58:35 right Nov 10 19:59:00 how can I prevent removal of old images? I see it will remove old images from deploy by default now? Nov 10 19:59:07 yep Nov 10 19:59:09 says: the RM_OLD_IMAGE variable is now redundant Nov 10 19:59:15 does it mean I can not use this var to prevent removal? Nov 10 19:59:21 or is there some other setting? Nov 10 19:59:31 no, it doesn't work in the same way, it's sstate doing the removal Nov 10 19:59:41 unfortunately I don't think there is an easy means of turning it off Nov 10 19:59:42 so is there a way to keep the old images? Nov 10 19:59:45 ooh Nov 10 19:59:57 other than copying them out yourself Nov 10 19:59:58 that's really unfortunate :( Nov 10 20:00:19 why was this hard change made? having it configurable would have been really nice... :P Nov 10 20:00:46 I think it was a mostly unintended side-effect of putting that directory under sstate control - the way sstate works is that it clears out previous state before installing the new one Nov 10 20:00:59 mhh :( Nov 10 20:01:23 a straw poll was conducted on the mailing list and nobody really objected, but I appreciate you probably didn't see that Nov 10 20:02:18 I guess I missed that, yes Nov 10 20:07:53 Jin^eLD: if it causes you serious problems it's not too late to speak up though Nov 10 20:08:13 I'm not sure how we'd disable the removal, but it is worth discussing if it's problematic Nov 10 20:09:07 bluelightning: well "serious" is a too strong expression in the sense that there is a workaround with copying, but its surely not nice for me Nov 10 20:09:26 we are basically putting the whole deploy directory online and this includes a list of releases, i.e. an image per release Nov 10 20:09:49 so each release build was adding another image to the images directory Nov 10 20:10:06 now I'd have to think of moving and copying stuff around Nov 10 20:10:09 ah, I see Nov 10 20:10:16 it was just really practical Nov 10 20:11:27 I mean, sure I'd like the old behaviour back :) but not so sure if the term "serious" qualifies here... Nov 10 20:12:32 although it would mean that we'd have to change the links for the firmware updates also, the devices know where to download the latest image Nov 10 20:12:51 but then again the latest image is there anyway, so.. oh well Nov 10 20:12:53 we'll manage Nov 10 20:13:33 unless you say it's easy to make it configurable ;) **** ENDING LOGGING AT Fri Nov 11 03:00:00 2016