**** BEGIN LOGGING AT Tue Oct 11 02:59:58 2016 Oct 11 12:34:35 how do I go about triggering only the image generation step? Oct 11 12:37:36 ecksun: bitbake myimage, if the packages are all ready then they won't be rebuilt Oct 11 12:38:00 well, I would to run the building of packages separetly from the generation of the image Oct 11 12:38:05 because I would like to do something in between Oct 11 12:38:45 so bitbake myimage works fine for the image generation step then Oct 11 12:39:11 well, I don't want it to do the building of packages, as I probably wont have the required sstate cache files for that Oct 11 12:39:31 how do you expect to build an image without packages? Oct 11 12:39:39 I will have the packages Oct 11 12:39:49 basically only the package feed Oct 11 12:40:02 thats what I will consider the output of the previous step Oct 11 12:40:10 as discussed yesterday you need more than just the deploy/ directory Oct 11 12:40:18 well, Im not so sure actually Oct 11 12:40:22 the code does not seem to depend on much more Oct 11 12:40:26 and the documentation hints at it being possible Oct 11 12:40:34 see the note here for example: http://www.yoctoproject.org/docs/latest/ref-manual/ref-manual.html#package-splitting-dev-environment Oct 11 12:41:30 that discusses making a package feed minimal / upgrade only / publishable Oct 11 12:41:42 for which there is more work than just making deploy/deb public Oct 11 12:42:01 yes, sure, my plan is to make a package feed Oct 11 12:42:10 but I dont follow what you mean by "minimal / upgrade only / publishable"? Oct 11 12:44:01 where is the entrypoint to the different steps in the bitbake build, more specifically, what triggers the do_rootfs function? Oct 11 12:50:36 image.bbclass defines the do_rootfs task that has to run before do_build Oct 11 12:50:56 before? Oct 11 12:50:58 hmm, interesting Oct 11 12:53:16 I see Oct 11 13:00:28 do_build is essential a no-op task that is just the default task Oct 11 13:00:48 all the other tasks involved in any recipe are dependents of that Oct 11 13:01:39 ie a normal package do_build depends on writing to the sysroot, generating packaging, writing the license manifest, and a few other pieces. Oct 11 13:02:20 yeah, I understood as much Oct 11 13:02:58 so what I hope I can do is just run do_build and ignore the output image, then configure my package feed and then run do_rootfs after that Oct 11 13:04:23 you understand that won't work out of the box right Oct 11 13:04:58 well, yes, but I dont know what else to do Oct 11 13:05:17 stop considering the sstate as something transient and untrustworthy? Oct 11 13:05:23 its *better* than a package feed Oct 11 13:05:39 but it is? its a cache? Oct 11 13:05:51 as i said repeatedly yesterday, only in the technical sense Oct 11 13:06:09 what's to ensure that libfoo-1-2.deb is always identical Oct 11 13:06:14 you could rebuild it without a version change Oct 11 13:06:25 -> package feeds are not immutable Oct 11 13:06:40 thats exactly what I'm worried about, bitbake rebuilding things without a version change Oct 11 13:07:08 and then also packages that into the image, but since there is no new version it wont be deployed to the running systems Oct 11 13:07:27 and that is what the PR service is for - every rebuild causes the version to bump Oct 11 13:08:01 *but* if you want to know *exactly* what goes into an image, then just used locked signatures so you mandate the sstate hash of every part of your release. if the hash changes then the build will abort. Oct 11 13:08:32 if you're just worried about a rebuild not propogating to an existing image using package management, turn on the PR service Oct 11 13:09:08 could you provide some documentation about locked signatures? Oct 11 13:10:17 looks like the docs haven't really expanded to cover those yet, bitbake -S will write a locked signature file for the current metadata. Oct 11 13:10:33 i'm still convinced you're over-thinking here, just use PR service. Oct 11 13:10:49 yeah, I understand that Oct 11 13:10:55 but Im not at all convinced about the sstate cache Oct 11 13:11:12 well then we're all screwed Oct 11 13:11:14 that would mean that I cant do clean builds, wouldn't it? Oct 11 13:11:17 which is another thing I want to do Oct 11 13:11:18 not at all Oct 11 13:11:23 no? Oct 11 13:11:24 delete the cache! Oct 11 13:11:30 or, change sstate_dir to another location Oct 11 13:11:57 i'm often changing sstate_dir to sstate2 just to get a totally clean build for testing Oct 11 13:12:34 Im building in a docker container in order to get a clean build every time Oct 11 13:14:24 so what happens if that when say m4 is built, the entirety of the inputs (src_uri, dependencies, machine, basically every variable and export) are all hashed and used to identify the result Oct 11 13:14:25 you are basically saying that I should persist the entire sstate-cache folder and hope that it will always work? Oct 11 13:14:40 which is why everything in sstate has a checksum on it - thats the identifier Oct 11 13:15:21 on rebuild from clean with sstate, when bitbake decides it wants m4 it can repeat the hash and if there's a corresponding entry in the sstate cache it can just extract the final packages+metadata from there instead of building Oct 11 13:15:40 yes, persisting sstate between builds is usual, and not doing so would be unusual Oct 11 13:15:50 having to bootstrap gcc for every build would get very boring Oct 11 13:16:13 sure, but better to rebuild packages from scratch than to use some partial result from previous builds Oct 11 13:16:24 it's the *final* result of the build Oct 11 13:16:30 nothing in sstate is partial Oct 11 13:16:34 hmm, okay Oct 11 13:17:03 morever, I have already had a case where bitbake essentially told me to delete the tmp directory because something went wrong Oct 11 13:17:08 set SSTATE_DIR to shared-state-archive if you want Oct 11 13:17:11 which is another reason I dont trust it Oct 11 13:17:15 that's unrelated to sstate Oct 11 13:17:25 that's you doing two builds with recipes that conflict Oct 11 13:17:30 well, the sstate is useless if I have to remove it Oct 11 13:17:37 sstate isn't in tmp/ Oct 11 13:18:05 we used to let recipes silently overwrite files from other recipes, but that does lead to non-deterministic builds, so now its a fatal error Oct 11 13:18:32 my sstate is in /data/poky-master/sstate, my build dirs are in /data/poky-master/tmp-glibc/ Oct 11 13:18:40 i can delete tmp-glibc and rebuild an image in seconds Oct 11 13:19:16 so, using the pr service, if it tells me that a package have changed, I just need to redeploy it with a new version Oct 11 13:19:44 otherwise bitbake will do nothing and there is nothing new for me to deploy? Oct 11 13:20:40 when using the pr service on every build the PR field (r0, r1, etc) will increase. this means a package manager on the target can actually see upgrades due to rebuilds. Oct 11 13:21:30 the PR field will increase for packages with changed recipes, dependencies etc? Oct 11 13:22:14 it bumps for every build, so whatever causes a rebuild will cause a bump Oct 11 13:22:31 I think I'm missunderstanding what you mean by build Oct 11 13:22:39 every time a recipe is built Oct 11 13:22:39 when you say build you dont mean just running bitbake Oct 11 13:22:52 the PR is per recipe Oct 11 13:22:52 but bitbake actually rebuilding a recipe after it has changed? Oct 11 13:23:49 if you build an image, then say edit a class that adds users, then rebuild the image, all the recipes that use that class will get rebuilt and their versions will increase slightly Oct 11 13:24:01 yes Oct 11 13:24:33 what happens if I do a clean build of the same package twice, with the pr service? Oct 11 13:24:59 s/package/recipe/ Oct 11 13:26:42 it increases Oct 11 13:26:48 *every* build increases the version Oct 11 13:26:59 but then the checksum would match? Oct 11 13:27:01 unless you delete the little database that maps packages to versions Oct 11 13:27:42 oh if there's something in sstate that matches then it will pull that Oct 11 13:27:52 if you explicitly say "do a build from scratch" then the version bumps Oct 11 13:28:00 hi Crofton Oct 11 13:28:13 what is the purpose of the pr service in that case? Oct 11 13:28:18 Crofton: i'd like to say all your photos of ELC-E food is making me hungry. Oct 11 13:28:21 Crofton: that would be a lie though Oct 11 13:28:33 ecksun: not sure what you mean Oct 11 13:28:48 rburton, if it will just bump the version even if I build the same package twice Oct 11 13:29:10 then its just always bumping it, is it not? Oct 11 13:29:31 its bumping for every build, yes. what's the alternative? Oct 11 13:29:40 bumping only when changes happen Oct 11 13:29:57 i.e. the checksum is different Oct 11 13:30:11 but if its rebuilding then the checksum is different Oct 11 13:30:15 otherwise it wouldn't be rebuilding Oct 11 13:30:56 well, if I do a clean build with the same definition? Oct 11 13:31:42 then would not the checksum be the same but a rebuild unnescesary (since that version is known since before) Oct 11 13:36:38 ecksun: I think you should use the exact bitbake command you mean with "clean build" -- I think you may be talking about different things Oct 11 13:37:45 well, rm -rf . && git clone $REPO Oct 11 13:37:46 :) Oct 11 13:38:12 your answers seems to suggest there is some interaction between the sstate and the pr service I dont understand Oct 11 14:15:49 anyone know if Saul Wold is anywhere on IRC? Oct 11 14:48:22 marka: he is sgw_ Oct 11 14:49:07 ah, I should have been able to figure that out. thanks Oct 11 14:49:47 rburton, the food is accceptable, although mainly eating Doner for lunch Oct 11 14:49:52 sent sgw_ a patch in the meantime, hopefully it can get applied and meta-security parsing successfully again. Oct 11 14:53:01 marka: saw it a few minutes ago, Armin (armpit) has been doing most of the maintenance and merging Oct 11 14:54:59 I tossed up putting him and you on the --to and ended up hitting enter with only you on it Oct 11 14:55:14 live and learn I guess Oct 11 14:55:46 anyways, he should pick it I would assume Oct 11 15:02:39 marka: I assume so, I will wait till tomorrow and pull it if he does not, I am not sure if he is at ELC and might be busy with that. Oct 11 15:03:03 yep, lots of folks travelling today Oct 11 15:04:35 too bad the patch submitter tossed in a "Fix typo" part to his commit, most likely as an afterthought to the extent he never even followed up with an attempt to build Oct 11 15:05:32 no need to 'save' a commit by not doing this sort of thing on its own Oct 11 15:06:26 anyways, we all make mistakes, hopefully something is learned in the process Oct 11 15:19:31 http://www.oreilly.com/programming/free/, https://github.com/ZhaoLion/O-Reilly-Offering-Programming-eBooks-for-Free Oct 11 15:19:42 oooh Oct 11 15:20:40 dunno if any are any *good*, but free is free Oct 11 15:58:35 fray: well put in #8596, adding that to the docs would be nice, i'm sick of repeating it when someone asks about it on a semi-regular basis :) Oct 11 17:26:19 Hey folks, I'd like to use PACKAGE_DEBUG_SPLIT_STYLE='debug-file-directory', but I'm also using meta-qt, which splits out it's qt4 recipie into multiple packages, each with their own dbg package (with paths for these manually specified). What's the right way to handle this? Is having one all-encompassing -dbg package the typical way to handle it? Or should I use manual FILES_${PN}-foo-dbg = "..." Oct 11 17:26:21 specifications that allow multiple debug split styles? Or is the automatic -dbg package generation smart enough to handle things if I get out of it's way? Oct 11 17:26:52 [clarification: issue with meta-qt4 is it's manual paths for FILES_${PN}-foo-dbg presume '.debug' usage] Oct 11 17:43:53 fishey1: i expect the best bet would be to drop the per-package dbg-packages to align with the core and let the automatic bits do their job, if you're on a recent enough version Oct 11 17:44:49 kergoth: would that result in one large ${PN}-dbg package, or would I still get the split-out ${PN}-foo-dbg where a ${PN}-foo exists? Oct 11 17:45:22 one large one. but one could presumably add per-package dbg-package support to the automatic bits and thereby do it at a policy level for all recipes Oct 11 17:50:43 ok. for extending the automatic bits, would that likely amount to adjusting meta/classes/package.bbclass populate_packages() to generate a -dbg package for each normal package, and then populate the -dbg package based on the paths included in the plain package it corresponds to? Oct 11 17:56:06 yeah, exactly. Oct 11 17:56:24 somewhere around here i have a class that does exactly that, but it was before the current automatic bits got merged Oct 11 19:59:17 Can a bitbake recipe refer to an include file in a different layer? Oct 11 20:07:41 Circuitsoft: it can, include resolution tries each of the included layers from each layer's root. Oct 11 20:08:26 Include or bbclass? Oct 11 20:08:31 I end up doing things like 'require recipes-foo/bar/bar.inc' occasionally, where recipes-foo/bar is in a different layer Oct 11 20:08:39 Ah. I see. Oct 11 20:08:42 Okay. Oct 11 20:08:44 I'm not sure what the resolution order is though Oct 11 20:09:09 That's okay. I'm just trying to upgrade a recipe by putting a new one in my own layer, referring to the original recipe's include file. Oct 11 20:09:56 Circuitsoft: in that case, you may also want this fancy thing: Oct 11 20:10:16 FILESEXTRAPATHS_append = ":${@os.path.join(os.path.dirname(bb.parse.resolve_file('recipes-connectivity/bluez5/bluez5.inc', d)), 'bluez5')}" Oct 11 20:10:19 :) Oct 11 20:11:48 If you're re-using patches or files from the original package, you'll need to add the path to them in FILESEXTRAPATHS as the default file resolution is based on the location of the recipe (.bb file) Oct 11 21:32:59 what is this configure.sstate that sometimes appears in work dirs, with unpacked content not being available causing do_install to fail ? Oct 11 21:33:41 second time tonight on a different package: "install: cannot stat '.../tmp/work/amdfalconx86-poky-linux/initramfs-live-boot/1.0-r12/init-live.sh': No such file or directory Oct 11 21:34:16 could it be a side-effect of forced interruption of a build ? Oct 11 22:07:51 yann|work: configure.sstate doesn't have anything to do with whether things are unpacked; it's just a file to track whether a 'make clean' is needed, IIRC **** ENDING LOGGING AT Wed Oct 12 02:59:58 2016