**** BEGIN LOGGING AT Fri Sep 25 02:59:59 2015 Sep 25 07:59:32 <_4urele_> hello did someone ever tried to build gst-python 1.4.0? Sep 25 09:13:36 maxin: hello! Sep 25 09:14:04 joseppc: hello ! Sep 25 09:42:50 I am using "bitbake -e myrecipe" to produce a environment file which I post process. I have to do this for ~300 recipes which is Sep 25 09:42:51 very slow. Is there a way of generating the 300 environment files with one execution of bitbake which is much faster Sep 25 10:08:55 morning all Sep 25 10:17:50 hmm, maybe I'm missing something but why doesn't meta-qt5 provide a qmake package too? Sep 25 10:36:40 I am using "bitbake -e myrecipe" to produce a environment file which I post process. I have to do this for ~300 recipes which is very slow. Is there a way of generating the 300 environment files with one execution of bitbake which is much faster Sep 25 10:54:23 Hello, I have an odd question and sorry for this. My question is: For example I have an OS image created with Yocto. Will be this image compatible for installing it on all devices that supports Yocto? or there should be done some modification before creating the image? I don't have right now the time to learn about Yocto and that's why I am asking this here. Thanks! Sep 25 10:54:58 I mean.. is the same image compatible with all devices that supports Yocto OSs ? Sep 25 10:57:39 I'm trying to send a dev-manual patch to Scott Rifenbark, but I'm getting bounced with 550 Address rejected, anyone know what's up? is Scott no longer with Intel? Sep 25 10:59:38 can somebody help me please :-s ? Sep 25 11:16:24 dguthrie: you might consider writing a python script that uses tinfoil Sep 25 11:16:44 dguthrie: here's an example: https://gist.github.com/bluelightning/6138980 Sep 25 11:17:15 in the next release (2.1) hopefully we should be simplifying (and documenting) the API Sep 25 11:18:16 theriorslide: our build system is very flexible, so there's no guarantee two OSes produced by two different people would be compatible if they're heavily customised - but if they had mostly the same config, they would be Sep 25 11:19:29 bboozzoo: he's not, no... srifenbark at gmail.com is his current address Sep 25 11:19:38 (he is still doing docs work) Sep 25 11:19:50 bluelightning: thanks Sep 25 11:34:50 bluelightning: thanks Sep 25 11:37:21 Is it possible to use a MACHINE_FEATURE as an override Sep 25 12:06:09 bluelightning: Thanks! Sep 25 12:17:22 <_4urele_> hello again! Sep 25 12:18:33 <_4urele_> I am building pygobject and I would like to specify the python interpreter, it is possible with "--with-python=PATH" Sep 25 12:18:49 <_4urele_> but how to tell the correct path? Sep 25 12:21:52 <_4urele_> ok this is stupid ;) I just wrote python2.7 and bitbake and configure did the job ;p Sep 25 12:43:05 dguthrie: no, you'd need to use a construct like VAR = "${@bb.utils.contains("MACHINE_FEATURES", "featurename", "yesvalue", "novalue", d)}" Sep 25 12:49:43 Hello all. I am having a problem with xserver-xorg 1.17.1 compiling. We've enabled xinerama via PACKAGECONFIG and now, all builds end up failing with missing drm.h durin the build of video-modesetting . I've checked the sysroot, and there are quite a few. I'm still digging around, but if anyone has input, that would be much appreciated. I have the compile log, if anyone needs more specific details. Sep 25 13:02:38 meta-qt5 question: why can't my SDK depend on nativesdk-libqt5core-dev which seems to provide the qmake spec files? bitbake just says nothing provides it but after built the ipk is there and can be installed manually.. Sep 25 13:12:30 mcfrisk: where are you adding it? Sep 25 13:13:48 bluelightning: in a packagegroup RDEPENDS_${PN} Sep 25 13:14:28 don't use "nativesdk-libqt5core-dev", that's how it was renamed by debian.bbclass Sep 25 13:14:44 the correct value is something like nativesdk-qtbase-dev Sep 25 13:14:59 but that does not exists Sep 25 13:16:06 or do does nativesdk-qtbase-dev exists at 'bitbake' time but real ipk's have different names? Sep 25 13:16:59 that's what debian.bbclass does Sep 25 13:18:20 Nothing RPROVIDES 'nativesdk-qtbase-dev' Sep 25 13:19:47 PACKAGES = "${PN}-tools-dbg ${PN}-tools-dev ${PN}-tools-staticdev ${PN}-tools" Sep 25 13:20:01 check buildhistory which package got renamed to nativesdk-libqt5core-dev Sep 25 13:20:28 hmm, oe-pkgdata-util doesn't support looking into the SDK nativesdk namespace, I'll have to fix that Sep 25 13:20:55 otherwise it's exactly what I'd use in this instance Sep 25 13:21:02 OE @ ~/build/oe-core/buildhistory $ git grep nativesdk-libqt5core-dev Sep 25 13:21:02 packages/x86_64-nativesdk-oesdk-linux/nativesdk-qtbase/nativesdk-qtbase-tools-dev/latest:PKG = nativesdk-libqt5core-dev Sep 25 13:21:18 you can do what it does manually though by looking in pkgdata, if you don't have buildhistory enabled Sep 25 13:21:55 "pkgdata" being tmp/sysroots/ sigh, so I'm on dizzy plus quite new meta-qt, buildhistory doesn't show nativesdk-libqt5core-dev Sep 25 13:24:09 nativesdk-qtbase-tools-dev Sep 25 13:25:37 thanks JaMa, that seems to be it Sep 25 13:26:57 so debian.bbclass is mapping package names from bitbake to ipk, or did I get it wrong? Sep 25 13:27:39 it occurs during do_package, so it's before the ipk/rpm/deb creation Sep 25 13:29:58 ok, I got completely lost after recipes were not matching to ipk file names and opkg output Sep 25 13:50:38 qmake, moc and spec files are now in my target but using them fails since some of the config files have paths from build env there. I guess patching needed... Sep 25 13:50:47 /target/sdk/ Sep 25 14:59:42 Hi all.. I am still new to yocto, so this might be obvious.. I have several recipes that should be generating a uImage, an initramfs-uImage, and a ubifs. However, after adding a new recipe that should be getting added to the ubifs, I installed it to the board and it didn't appear to be there. It *does* appear to be in the rootfs it generates. Sep 25 15:00:54 So, even though the UBIFS timestamps were updated, I thought maybe it hadn't fully regenerated them? So I rm * the deploy/images/at91sam5ek/ directory, and now it's ONLY generating the ubifs, no uImages Sep 25 15:02:43 applepi: not sure what's going on with the ubifs, but the uimage is produced from the kernel, and because you've built it once it marks the task as completed - deleting the output file doesn't reset that Sep 25 15:03:10 (this is why there is a file in tmp/deploy/images with "do not delete files in this directory" in capitals) Sep 25 15:03:41 not that you can't delete files in there, you just have to understand that they won't necessarily be regenerated just by deleting them Sep 25 15:10:53 bluelightning, does running clean on a recipe that builds a uImage not tell it to rebuild the uImage? Sep 25 15:25:20 1) https://bugzilla.yoctoproject.org/show_bug.cgi?id=8398 Sep 25 15:25:21 Bug 8398: normal, Undecided, ---, ross.burton, NEW , Want to unbreak systemd <=> dbus circular DEPENDS but unable to for a DISTRO which includes ptest Sep 25 15:25:31 bah, copy/paste error - apologies Sep 25 15:31:34 applepi: if by recipe you mean the kernel recipe, yes Sep 25 15:32:30 applepi: if you mean the image recipe, it's not the image recipe that actually produces the uimage - it's just that the image recipe has a dependency on (or rather a dependency chain leading to) the kernel recipe Sep 25 15:34:10 meh Sep 25 15:38:50 bluelightning, so I would need to clean what it depends on.. or is there something I can give it that will clean it and all the way back up? Sep 25 15:39:35 bluelightning, I come from a buildroot background and this has sort of been thrust upon me.. I've tried going through the documentation but the volume of it is overwhelming.. Sep 25 15:46:24 applepi: just clean virtual/kernel and rebuild the image Sep 25 15:46:26 * kergoth yawns Sep 25 15:47:17 what the hell. this shouldn't even be possible Sep 25 15:47:19 ERROR: ParseError at /scratch/cedar/layer-updates/meta-oe/meta-oe/recipes-extended/liblognorm/liblognorm_1.0.1.bb:1: Could not include required file defaultpkgname.inc Sep 25 15:47:41 how the heck did PN not get set from that filename? Sep 25 15:47:48 * kergoth checks to see if he broke something horribly in his local changes Sep 25 15:49:16 Hmm, this isn't the first time I've had to re-parse every layer.conf to get at info we throw away from the initial bblayers setup. Would anyone else find it useful to retain LAYERDIR for each BBFILE_COLLECTIONS entry, so we can map between layer name and layer root path? Sep 25 15:49:28 * kergoth wonders if bitbake should store that Sep 25 15:51:53 generally i'm not a fan of adding crap 'just in case', or if someone might find it useful, but in this case it's info we already had, and just didn't retain Sep 25 15:53:08 * kergoth yawns Sep 25 15:59:14 wow, this makes no sense. if i define RECIPE_LAYERNAME = "${@bb.utils.get_file_layer('${FILE}', d)}" i get a *parse error* in a recipe due to PN not being set properly. what the hell? that makes no sense, but stashing my local change to use that function results in a successful parse Sep 25 15:59:17 * kergoth boggles Sep 25 15:59:56 * kergoth ponders Sep 25 16:04:57 So can anyone help me understand how recipes-kernel/linux/linux-yocto-custom_3.10.bb gets pulled in to this recipe I'm working on? I'm trying to understand this better as I go. It's definitely the image that it's building, but I have ZERO idea why and it's really frustrating me. I can't find anything pointing to that file.. Sep 25 16:06:13 bluelightning: when I use your script to execute bbhandler.cooker.showEnvironment(), the result isn't the same as if I use "bitbake -g ". I get a lot of "no history recorded" in the text output. Is there a way of storing the variable history Sep 25 16:07:12 I'm building ./recipes-core/images/fooboard-image-base.bb, which inherits core-image, but I can't find any hint of where the kernel is referenced anywhere Sep 25 16:08:38 applepi: bitbake -g -u depexp fooboard-image-base Sep 25 16:33:36 Hmm, I like the oe-local-files bits in devtool on mut, but it'd be nice in the long term for them to be git tracked, with update-recipe updating those files if they change in git (i.e. rebase -i / amend) Sep 25 16:33:38 * kergoth yawns Sep 25 16:34:05 still a good step as is though Sep 25 16:34:10 * kergoth gets more caffeine Sep 25 16:43:15 bluelightning: you should think about adding whitelist.bbclass to meta-oe, just to ensure nobody has to go digging through feature branches or mailing list patches if they need it Sep 25 16:43:24 just so there's somewhere to grab it *from* Sep 25 17:05:42 kergoth: I suspect people will have the same objections to merging it there Sep 25 17:05:53 bbl Sep 25 17:06:12 Hmm, I suppose. maybe we need another layer for random useful bits that live there lacking anywhere else to live Sep 25 17:06:19 though meta-oe has historically been just that :) Sep 25 17:06:22 * kergoth shrugs Sep 25 17:07:07 * kergoth browsing through the bugs on the yocto 1.9 features page :) Sep 25 17:43:01 hmm, was it jama that wrote a distro/bsp layer sanity testing script? I know there was one other than mine, but i can't for the life of me find the thing Sep 25 17:50:38 huh, first time building with oelint enabled, that's a lot of warnings Sep 25 17:50:39 :) Sep 25 20:40:11 rburton1: did you ever make any progress with eventually removing bitbake's knowledge of ${B}? did you manage to determine which functions are relying on the default behavior? Sep 25 20:40:21 (just curious) Sep 25 20:45:46 kergoth: i removed ${B} from bitbake's default mkdir and fixed whatever broke Sep 25 20:45:51 so that's a step in the right direction Sep 25 20:46:05 the question then is what is the desired behavior for the next release Sep 25 20:47:02 Have we done builds with and without that and checked for changes to the metadata or the output? e.g. buidhistory-diff? Sep 25 20:47:17 I'm assuming we won't be merging the removal of ${B} from exec_func until 2.1 to reduce risk, right? Sep 25 20:48:32 right Sep 25 20:49:29 I hate things like this, where any reliance on the current behavior is implicit, all we can do is hope the change in path results in breakage rather than changed behavior :) Sep 25 20:50:10 * kergoth would hope that this change would be in 2.1, bitbake really shouldn't be knowing about ${B}, and these races we keep hitting and you keep fixing are getting old :) Sep 25 20:50:58 yeah Sep 25 20:51:17 have a think about what the default behavior should be though Sep 25 20:51:25 if no dirs, just no chdir? Sep 25 20:52:18 i should run a test where if dirs isn't specified it chdirs to a directory it then deletes, that should make any use of cwd obvious Sep 25 20:54:39 hmm, that's a good question. we don't want overhead. Ideally we wouldn't rely on any other path variables either. I'd think either $TOPDIR or /tmp if we don't go with a generated temporary directory Sep 25 20:54:46 s/overhead/too much extra overhead/ Sep 25 20:54:54 guess would have to prototype and see how it affects performance Sep 25 20:55:53 or just not chdir at all - no overhead there! Sep 25 20:56:27 but yeah, $topdir is reasonable to have determinism Sep 25 20:56:36 instead of just "what the previous task left it as" Sep 25 21:05:12 yeah, my concern with doing nothing would be yet again someone will assume it always runs in a certain place, and then that assumption will break Sep 25 21:05:15 right Sep 25 21:05:25 hmm Sep 25 21:43:14 Hmm, just noticed bitbake checks sstate mirror object availability even when I'm just doing a bitbake -S printdiff. I wonder if that's really needed Sep 25 21:43:15 ah, perhaps Sep 26 01:52:28 zeddii: around ? **** ENDING LOGGING AT Sat Sep 26 02:59:59 2015