**** BEGIN LOGGING AT Fri Apr 11 02:59:58 2014 Apr 11 07:25:29 i moved my build dir, and the OE sanity checker kicked in telling me I should either move it back or rebuild. how do I rebuild? and is there no legal way to move a build dir? Apr 11 08:27:33 mago_: you can't really move a build dir indeed. however if you properly use 'downloads' and 'sstate-cache' folder rebuilding in a new build dir should be quick Apr 11 08:28:04 the full build dir path is 'hard coded' in many generated scripts, that's what makes moving it not possible. Apr 11 08:29:51 okay. i forced a rebuild by simply removing TMPDIR and rebuilding (keeping my download and sstate dir), is this the recommended way of triggering a rebuild, or is there a bitbake command for it? Apr 11 08:30:43 no, that's correct. Apr 11 08:31:14 since bitbake needs to be run from the build dir, there is no command to delete from bitbake. Apr 11 08:39:09 Is there a way / bitbake command to get the list of packages available in a particular image ? Apr 11 08:43:58 good morning Apr 11 08:45:33 milan__, if you use the HOB ui, you can click Customize image once you've selected an image, that'll show you which packages are selected for the given image Apr 11 08:45:41 bitbake -u hob your-image-name Apr 11 08:46:57 milan__, you can also do this: bitbake -g your-image-name && cat pn-depends.dot | grep -v -e '-native' | grep -v digraph | grep -v -e '-image' | awk '{print $1}' | sort | uniq Apr 11 08:47:12 (from https://community.freescale.com/docs/DOC-94953) Apr 11 09:07:01 morning all Apr 11 09:07:59 hey bluelightning Apr 11 09:19:08 mago_ : Oh...wow!! The second option worked like a charm !! Thanks a lot :) Apr 11 09:38:13 mago_: how's going with the kernel? Apr 11 09:41:52 ant_work, it's progressing :) thanks for asking! i've created my own layer and attempting to create machine configs for my two boards atm. my current solution is to use different kernels (from the bsp layers) depending on machine, but will likely try to merge them later by forking the yocto kernel as the yocto manual suggests. i noticed one of my targets (ti) has been merged with mainline kernel, so i guess it will ripple down to the yocto kernel soon anyway Apr 11 09:44:49 I see, nice Apr 11 09:45:55 TI boards and using mainline... Apr 11 09:46:08 didn't know such naivity still existed in the world Apr 11 09:46:18 koen, i'm new :) Apr 11 09:46:29 if it's one of those TI SoCs with video stuff, you are screwed Apr 11 09:46:52 there is no video stuff on board Apr 11 09:46:56 am18xx, am335x, omap3 and omap4 are OK in mainline Apr 11 09:47:09 dm8xxx is a lost cause Apr 11 09:47:14 im on am335x Apr 11 09:47:43 that one boots with mainline Apr 11 09:48:17 so there's hope :) Apr 11 10:50:20 koen: JaMa: my memory is failing - in which release did we decide to stop bumping PRs as a matter of procedure, can you recall? Apr 11 10:51:38 iirc 1.5 Apr 11 10:52:44 I think dylan already Apr 11 10:53:33 I have to admit I thought it was dylan; at least nobody complained up to this point that I wasn't doing them... Apr 11 10:54:51 I know we did it during dylan, I am not sure when we decided it was procedure Apr 11 10:56:16 on reflection I might just do it for this openssl one just for people's peace of mind Apr 11 10:57:12 question is, bump it just 1, or higher than that as a bigger flag? Apr 11 10:59:36 actually since we use INC_PR just bumping that ought to be enough Apr 11 10:59:55 although hmm, then that'll catch people's own broken forked recipes Apr 11 11:02:29 bluelightning, some time ago you provided an url to an up-to-date bitbake manual. I seem to have misplaced it, do you still have it? Apr 11 11:04:17 lol lightning is fun Apr 11 11:06:05 mago_: this is the temporary one: http://www.yoctoproject.org/docs/temp/user-manual/user-manual.html Apr 11 11:07:53 thanks Apr 11 11:16:11 bluelightning, are BBFILE_COLLECTIONS just arbitrary subsets files of a layer which matches the collection pattern? if so, does Bitbake rely on BBFILE_PRIORITY when calculating variables which are set by multiple collections (possibly in multiple layers)? or is the variable priority controlled by some other bitbake variable? Apr 11 11:16:58 so for example, if i set VAR = "moo" in layer1 and VAR = "foo", will Bitbake rely on BBFILE_PRIORITY to compute the actual value of ${VAR}, and what will happen if no COLLECTIONS/PRIORITY exist? Apr 11 11:27:59 sorry, VAR = "foo" is set in layer2 Apr 11 12:05:29 mago_: are you talking about setting variables within bbappends, or in layer.conf in each layer, or somewhere else? Apr 11 12:09:37 in a layer config, specifically a conf/machine/something.conf file Apr 11 12:10:18 im just curious, because a lower layer sets KERNEL_IMAGETYPE, and I reset it in my layer. Bitbake seem to compute the variable to my layer value, im mostly curious how it came to that conclusion Apr 11 12:32:44 mago_: well only one conf/machine/something.conf will be parsed, and if there are multiple files across layers matching the value of MACHINE, since we use BBPATH to find conf files the first one found searching through BBPATH will be used Apr 11 12:33:45 so it depends on how each layer's layer.conf sets BBPATH; the prescribed method is to append to it, so if all layers are adhering to that the order would be the order used in bblayers.conf Apr 11 12:34:23 if your question is about the machine conf in relation to other configuration files, see the include lines in meta/conf/bitbake.conf to see the order in which those are processed Apr 11 12:34:25 okay, but if layer1/conf/some.conf sets VAR="foo" and then my layer, layer2/conf/machine/board.conf also sets VAR="bar", would not the first value be used then? (according to your logic) Apr 11 12:35:07 mago_: but there only one of those would be used, which one would depend on whether MACHINE is set to "some" or "board" Apr 11 15:00:22 hmmm Apr 11 15:00:32 this linux-yocto-custom thing is a recipe for disaster Apr 11 15:01:03 meta-intel changes make the c7x0 kernel go from 3.10.33 to 3.10.19 Apr 11 15:01:03 ERROR: QA Issue: Package version for package kernel-module-soundcore went backwards which would break package feeds from (0:3.10.33+git0+6ad20f049a_c03195ed6e-r0.1 to 0:3.10.19+git0+6ad20f049a_c03195ed6e-r0.1) Apr 11 15:01:08 fun fun fun Apr 11 15:01:30 * koen <3 linux.inc + linux-.bb Apr 11 15:02:30 koen: how did that happen? Apr 11 15:06:32 I updated all repos with 'dora' branches Apr 11 15:06:36 then did a new build Apr 11 15:06:40 *boom* Apr 11 15:07:35 I don't think anyone besides angstrom uses multipe BSP layers with linux-yocto-* recipes at the same time Apr 11 15:07:42 *and* tracks release branches Apr 11 15:08:50 koen: when you say "linux-yocto-custom" do you mean "linux-yocto" ? because there is no reference "linux-yocto-custom" at all in meta-intel or meta-handheld Apr 11 15:09:07 I'm going to do a 'daisy' setup this weekend and if I see if happening there I'll file a bug Apr 11 15:09:11 bluelightning: yes, linux-yocto Apr 11 15:09:24 I got confused because i"ve been working on meta-atmels linux-yocto-custom Apr 11 15:10:34 koen: which meta-intel BSP layers are you enabling atm? Apr 11 15:11:26 bluelightning: http://pastebin.com/pKPz0pBE Apr 11 15:14:34 koen: do you know what revision you were at before the update? Apr 11 15:14:40 (meta-intel revision that is) Apr 11 15:15:32 I think I updated it last weekend Apr 11 15:15:39 but looking at it, I think it's meta-minnow Apr 11 15:16:00 since that has a change from yesterday poking at linux-yocto srcrevs Apr 11 15:16:05 perhaps it's the unconditional setting of LINUX_VERSION? that seems to be an (anti-)pattern Apr 11 15:17:01 ah yes Apr 11 15:17:15 meta-minnow now sets it with _minnow whereas previously it did not Apr 11 15:17:30 so the change to do it properly actually made the version go backwards for others... Apr 11 15:17:59 looks like it Apr 11 15:18:12 bit of a bummer, but it was doing the wrong thing originally... Apr 11 15:18:14 so I can't complain too hard about it :) Apr 11 15:18:28 we should stamp out the other places it's being set unconditionally Apr 11 15:18:33 * bluelightning adds todo Apr 11 15:18:53 one could make an argument in favor of an epoch bump in a case like that, but meh :) Apr 11 15:19:35 kergoth: for kernels PE bumps are counterproductive in the long run Apr 11 15:19:41 * kergoth nods Apr 11 15:19:43 since most people forget to carry them Apr 11 15:20:34 I did PE bump a kernel a few years ago Apr 11 15:20:46 "never again" Apr 11 15:20:48 oh, they forget ot carry it to new recipes when they bump versions and the like? Apr 11 15:20:51 makes sense Apr 11 15:23:03 for 1.6 I'm going to try that new sstate lockdown thing Apr 11 15:23:28 this heartbleed thing triggered too many PRSERV bumps Apr 11 15:23:48 I'm fairly sure now of the recipes statically linked to openssl Apr 11 15:27:40 that sounds interesting. maybe add boundaries to the rippling out of changes through the entirety of the dependency digraph in certain known sane cases, presumably Apr 11 15:27:43 heh Apr 11 15:29:50 RP mentioned that it was intended to lock down sstate hashes for e.g. gcc and eglibc Apr 11 15:30:17 so you can make fixes to those recipes that don't impact the build without having have global rebuild triggered Apr 11 15:35:08 koen: I didn't get the locked sstate patches into 1.6, I just ran out of time but they'll go in for 1.7 Apr 11 15:38:51 ah well Apr 11 15:39:09 * koen will enter cryofreeze for 6 months Apr 11 15:42:18 to be honest, I would have thought you could already stop dependencies rebuilding using SIGGEN_EXCLUDERECIPES_ABISAFE, even though that is kind of a hack Apr 11 15:48:21 true. though thats kind of a blunt hammer, only for use when no changes from that recipe should *ever* affect anything else Apr 11 15:48:51 bluelightning: dependencies yes, but you cannot lock bbclass changes Apr 11 16:05:33 kergoth: completely yes Apr 11 16:06:03 JaMa: correct, that would be another limitation Apr 11 16:06:57 the workflow part that I think might be missing with the locked sstate patch is to be able to easily analyse where rebuilds haven't happened that you might want to happen Apr 11 16:07:36 e.g. if someone adds a patch to a recipe and that recipe's tasks are locked, that change simply won't take effect, which could be bad Apr 11 16:08:30 of course you can just disable the locking temporarily but I can't help feeling that's not the ideal solution Apr 11 16:09:30 yes, I have the same problem with SIGGEN_EXCLUDERECIPES_ABISAFE and SIGGEN_EXCLUDE_SAFE_RECIPE_DEPS :/ Apr 11 16:09:56 indeed, I guess there would be times when the ABI really does break Apr 11 16:24:42 when a recipe spits out additional packages, and when I want those packages to be "allarch", is there some way to solve it via inherit allarch, but only for the additional packages? or will I have to set PACKAGE_ARCH manually in that case? Apr 11 16:26:58 probably have to set it manually for just that package, but not sure Apr 11 16:28:22 I'll probably have a look at extending the allarch class because it seems setting just PACKAGE_ARCH to "all" is not enough, I then get warnings about "shared area" installs when building multimachine stuff Apr 11 16:28:40 this does not happen when allarch is inherited, I guess because it sets a bunch of other things too Apr 11 16:36:21 Jin^eLD: that's why you pretty much can't do split arch stuff in the same recipe like that Apr 11 16:36:42 since it'll be restaged and repackaged on architecture/machine changes Apr 11 16:36:50 hmm Apr 11 16:37:15 I have a tarball that produces the main application (binary) and some additional and optional scripts Apr 11 16:37:30 latter ones are just shell scripts Apr 11 16:37:39 so I thought it'd make sense to have them allarch Apr 11 16:37:56 but seems I have to drop that "optimization" if I read you correctly... Apr 11 16:39:28 yes, we don't usually do that kind of thing Apr 11 23:52:56 https://gist.github.com/kergoth/10510368 - getting there **** ENDING LOGGING AT Sat Apr 12 02:59:59 2014