**** BEGIN LOGGING AT Wed Nov 04 02:59:58 2015 Nov 04 08:05:05 good morning Nov 04 09:01:35 morning all Nov 04 09:03:58 morning bluelightning Nov 04 09:04:09 and others too :) Nov 04 09:16:31 hi yann|work Nov 04 10:46:17 hm, a PV of 2.0.3-r0 should not match ">= 2.0.3+2.0.4", right ? bitbake did not complain that I forgot my libsdl2 snapshot recipe, and happily built a 2.0.3 ... Nov 04 11:24:14 yann|work: what do you mean by match? Nov 04 11:24:18 match where? Nov 04 11:38:21 bluelightning: I have a recipe that has DEPENDS = "libsdl2 (>= 2.0.3+2.0.4)", and with only sdl2 2.0.3 recipe in the tree (forgot to copy my 2.04 snapshot one, another of those silly mistakes noone else makes) - and instead of bombing out, it builds 2.0.3, and as expected fails to build my final software which does require 2.0.4 Nov 04 11:40:18 hm, can I easliy see from tmp/work which recipe was used to build my linux kernel ? Can't find that :) Nov 04 12:46:46 yann|work: we don't support that kind of version restriction in DEPENDS Nov 04 12:47:24 yann|work: one way is bitbake -e virtual/kernel | grep ^FILE= Nov 04 13:09:59 bluelightning: should bitbake warn against it then ? Nov 04 13:13:02 bluelightning: thx, perfect solution :) Nov 04 13:19:03 there is no explicit provision wrt sharing work-shared between different build trees/developpers, right ? Ought to be possible to symlink to a shared area without problems ? Nov 04 13:25:23 yann|work: sharing build artifacts is what sstate is for Nov 04 13:30:16 rburton: I rather meant avoiding to unpack gcc and the kernel for each work tree Nov 04 13:31:19 but yes, I'm trying to use sstate as well, but for now everything still gets rebuilt even when using sstate - I surely did something wrong, still did not notice what yet Nov 04 13:31:30 it will only unpack if it needs to build, so if its rebuilding then sstate isn't working Nov 04 13:33:16 yann|work: possibly it should yes, maybe at the moment it's re-using logic from RDEPENDS that does support that syntax Nov 04 13:33:26 rburton: or maybe it's that the builds are too different Nov 04 13:33:53 yann|work: note that if the host distro is different, the native parts will be rebuilt Nov 04 13:34:20 rburton: my 3 builds are for yocto 1.6.1, 1.8.0 from tarball, and fido head Nov 04 13:34:26 on the same host Nov 04 13:34:59 looks like gcc got rebuilt between 1.8.0 and fido head, not sure if it's normal Nov 04 13:37:12 oh, my bad, I had not used the shared sstate for initial 1.8.0 build, nothing to worry yet :) Nov 04 13:39:31 quite possible that it needs to rebuild if you move around the release branch though Nov 04 13:55:56 is it expected that a recipe fetch my software from git (and otherwise identical to the tarball-based one) complains that I did not inherit gettext because of tmp/work/armv7a-vfp-neon-poky-linux-gnueabi//0.0.999+gitAUTOINC+3f5c606284-r0/git/ImageMagick-6.9.1/librsvg/gdk-pixbuf/configure.ac ? :) Nov 04 13:57:07 yann|work: don't know why that would make a difference Nov 04 13:59:01 oh, forget it, I had forgotten that this repository also contains unwanted cruft, it is confusing bitbake Nov 04 13:59:16 there *is* really an ImageMagick copy in there :( Nov 04 15:02:07 say recipe A depends on recipe B. is there some way to get the version (PV) of B from A? i need it because it appears in the path of a file i need to reference in this case. Nov 04 15:03:15 Ulfalizer: I'm afraid not Nov 04 15:04:27 Ulfalizer: can you be more specific about the file / path? Nov 04 15:06:25 bluelightning: i'm trying to cross-compile a ruby gem. part of the process involves specifying the path of the rbconfig.rb that belongs to the ruby you're cross-compiling for (i.e., the ruby that runs on the target). Nov 04 15:06:34 that ruby lives in a path that includes its version number Nov 04 15:06:52 however... Nov 04 15:07:40 hmm, so there must be some other means of finding that out; otherwise I can't see how this would work outside of our build system Nov 04 15:07:55 there's already a yocto patch that disables versioned paths for ruby. it has a bug though, so i tried disabling it. Nov 04 15:08:13 the other approach would be to patch the patch :P Nov 04 15:08:33 it misses some spots, which causes other problems when cross-compiling gems Nov 04 15:09:02 I'd suggest fixing it; but I'm still convinced there must be a way to find out what that path is Nov 04 15:09:17 this is for ruby 1.9 btw, from the meta-openembedded layer. it's pretty ancient, but it's what people want in this case. :/ Nov 04 15:09:29 bluelightning: might be if you could run the ruby on the target to find out Nov 04 15:09:35 but that's difficult when cross-compiling Nov 04 15:09:47 don't we have ruby-native for the host as well? Nov 04 15:10:10 ah, yeah, i guess you could figure out the path from that somehow Nov 04 15:10:27 assuming it's able to tell you the correct path for the target if that's what you want Nov 04 15:10:58 the path also includes the architecture, so that's another messy thing... :) Nov 04 15:13:42 another way to handle this sort of thing is to tell ruby the path you want it to use, then you know what it's going to be (I guess that's what the patch is doing effectively) Nov 04 15:15:32 is there a recipe index or search engine, at least for the layers hosted at yoctoproject.org ? Nov 04 15:16:36 hm, found http://layers.openembedded.org/layerindex Nov 04 15:17:01 yep, that is definitely the place to find recipes Nov 04 16:26:17 i have a ruby_1.9.%.bbappend file in a separate layer from the original recipe. in it, i add another patch to be applied to SRC_URI, which i put in the files/ subdirectory of the directory where the bbappend file is. it seems bitbake can't find it. are there some paths i need to extend? Nov 04 16:27:42 you need to set FILESEXTRAPATHS_prepend := "${THISDIR}/files:" Nov 04 16:27:50 see also every bbappend in every layer that adds to SRC_URI Nov 04 16:27:53 they all set it Nov 04 16:29:19 thanks! is it a horrible idea to have a patch that assumes another patch has already been applied by the way? it "repairs" that other patch. Nov 04 16:29:44 it's obviously pretty messy, but it makes it clear what the fix is at least :/ Nov 04 16:30:04 though i could add that in the commit message i guess, if i duplicated the original patch before fixing it Nov 04 16:30:35 the alternative would be to effectively replace the patch with a fixed version Nov 04 16:30:52 yeah, that's what i meant by duplicate Nov 04 16:38:05 I think either is an okay approach, depends Nov 04 20:10:04 Hmm, it'd be nice to have a sanity check for entries in PACKAGES which don't reference PN or BPN and which also don't include MLPREFIX Nov 04 20:10:17 just got bit by one of those in meta-sourcery Nov 04 20:25:01 hi all Nov 04 20:38:47 is there any way to increase the rootfs size of an sd card? (for a raspi) Nov 04 20:39:16 actually i can change de IMAGE_ROOTFS_SIZE, but it will generated a 32Gb sd-img file. Nov 04 20:41:58 generate* Nov 04 20:42:11 see IMAGE_ROOTFS_EXTRA_SPACE Nov 04 20:43:10 thanks, i'll take a look Nov 04 20:51:41 same, it created a 32Gb sd-img. to avoid generating 32Gb files at each build, full of nothing, i think i'll have to create a partition with the available space Nov 04 20:53:09 likely depends on how the sd card is being constructed. Nov 04 20:53:20 wic, various sdcard scripts, multiple image fstypes in various bsp layers, .. Nov 04 20:58:41 tbh i don't really know, i'm starting to use yocto... it seems that the sdcard_image-rpi.bbclass is doing the job Nov 04 21:12:07 * armpit needs more Guinness Nov 04 21:13:07 * JaMa needs more Kozel Nov 04 21:16:21 * armpit looks like that one is hard to find in states. Nov 04 21:30:10 armpit: it's easier to get Pilsner Urquell or Staropramen (tl-beer-garden-sunnyvale) Nov 04 21:31:05 will have to try next time I am out that way Nov 04 23:11:15 hello. Hopegully quick question. I'm trying to use pr_info(), I get a not defined error. So I #include ... no such file error. Is the problem in my configuration or am i trying to use it incorrectly? Nov 04 23:11:44 I'm specifically modifiying hardware/imx/lights/fsl_lights.c ... so this is a FSL specicic tree. Nov 04 23:12:13 I'm guessing I just need an include directive in the compile line for that file?? Nov 05 00:04:01 Question how do I change the standard login shell in yocto build? Nov 05 00:04:15 Currently it is sh but I want to have bash. Nov 05 00:04:33 Is that possible somewhere? Nov 05 00:13:33 install bash, then configure your user to use it (i.e. usermod), either on target, or via a ROOTFS_POSTPROCESS_COMMAND. I don't have an example of the latter handy, though. Nov 05 00:13:54 hmm, not actually sure how useradd picks the default login shell Nov 05 00:14:01 when not otherwise specified Nov 05 00:14:05 * kergoth ponders Nov 05 00:20:32 well, when bash is installed, /bin/sh will be bash by way of alternatives, so I think that ought to be enough Nov 05 00:20:50 * bluelightning goes to get sleep Nov 05 00:21:28 kergoth there is a useradd config file that sets the defaults.. should be in etc somewhere