**** BEGIN LOGGING AT Mon Apr 20 02:59:58 2015 Apr 20 05:59:59 how can i get detailed info from a recipe using bitbake? or i need bitbake-layers? Apr 20 06:11:38 miandonmenmian, what are you looking for? Does `bitbkae -e `shou what you need? Apr 20 06:45:19 AndersD: wow, thanks. i suppose somewhere there has to be. I'm trying to locate the .bb file and location for the python stack. would like to add some more dependencies to python and want to see how the current ones are done Apr 20 07:25:46 Well, usually I end up being lazy and run find to locate the bb-file (or look at the history in git to find the path). Apr 20 07:31:57 good morning Apr 20 08:12:34 morning all Apr 20 08:59:27 hello Apr 20 09:00:19 how would I go about creating an SD card image that includes a UBI image? Apr 20 09:01:14 at the moment I'm flashing the SD card myself and then mounting the rootfs and copying in the UBI image + all the supporting scripts Apr 20 09:02:02 i have a dive through the python oe.image module but was a bit out of my depth Apr 20 09:02:06 *had Apr 20 09:05:06 jaz303: why would you use UBI on an SD? Apr 20 09:05:09 Hi everybody. Can anybody help me understand what variable FEED_DEPLOYDIR_BASE_URI is supposed to do? I'm using ipk package format and opkg package manager. I expected to find an additional conf file under /etc/opkg/ but no additional file has been placed there after bitbaking Apr 20 09:05:41 jaz303: is it to be flashed on nand/nor ? Apr 20 09:05:49 ant_work: i want my users to be able to boot from the SD and if they like it they can flash it, yes Apr 20 09:07:00 ah, ok, thne I se Apr 20 09:07:06 argh.. Apr 20 09:07:10 ah, ok, then I see Apr 20 09:12:41 iirc there are some layers handling complex SD images, if I'm not wrong meta-fsl-arm Apr 20 10:24:22 good morning Apr 20 10:24:41 when migrating to Daisy from Dylan, I can see this, but nothing in the migration guide: WARNING: Building libpam but 'pam' isn't in DISTRO_FEATURES, PAM won't work correctly Apr 20 10:24:56 this is the only entry in the migration guide: libpam: Deny all services for the OTHER entries. Apr 20 10:29:38 lpapp: somewhere a dependency on libpam exists that is not conditional on pam being in DISTRO_FEATURES; you should find it and eliminate it Apr 20 10:30:17 it is probably our software, but pam is not option for that. Apr 20 10:31:02 if by that you mean it's required, then you should add pam to your DISTRO_FEATURES value Apr 20 10:31:38 wk Apr 20 10:36:25 I've a couple of questions about 'dizzy' Apr 20 10:36:56 the command 'hystory' is no longer available on generated fs, what's missing? Apr 20 10:37:22 the 'opkg-target' command is no longer generated in minimal-image, what's missing? Apr 20 10:39:28 bluelightning: ok, thanks; interesting that this transition step is not documented. Apr 20 10:39:36 or I may be missing something. Apr 20 10:40:14 lpapp: it's not that we added a new requirement, we probably just added a check, the issue was probably always there Apr 20 10:41:33 still, it could have been put in there. Apr 20 10:42:32 so this will do it? DISTRO_FEATURES_append = " largefile --disable-zlib pam" Apr 20 10:44:29 sorry if I ask again, but maybe not everybody read. Can anybody help me understand what variable FEED_DEPLOYDIR_BASE_URI is supposed to do? I'm using ipk package format and opkg package manager. I expected to find an additional conf file under /etc/opkg/ but no additional file has been placed there after bitbaking my image Apr 20 10:45:44 I mean, are those removed features in 'dizzy' ? Apr 20 10:50:16 lpapp: er, --disable-zlib doesn't belong in there Apr 20 10:50:19 lpapp: otherwise, yes Apr 20 10:50:25 why? Apr 20 10:50:33 because nothing will check for that? Apr 20 10:50:41 so why is it in there? Apr 20 10:50:59 I'm not sure, it's your line that's adding it Apr 20 10:51:25 could be that somewhere a check was added for it in your custom metadata, but I wouldn't have thought so Apr 20 11:11:37 bluelightning: hmm, it was not used even at the denzil era? Apr 20 11:12:09 lpapp: no, we wouldn't use that syntax in DISTRO_FEATURES Apr 20 11:14:19 ok :) Apr 20 11:14:21 thanks. Apr 20 11:25:33 hullo Apr 20 11:28:07 is there a parser for bitbake recipes that allows me e.g. to get the dump as a dictionary in python? Apr 20 11:28:29 or the entire layer for that matter Apr 20 11:33:07 JYDawg: hm, the information you're looking for might already be contained in bitbake -e Apr 20 11:33:10 you can try 'bitbake -e ' Apr 20 11:33:22 can be spammy, though :) Apr 20 11:33:48 oke Apr 20 11:34:04 lessee Apr 20 11:34:15 but it depends on what you need Apr 20 11:37:37 we have several developers in the same layers and I'd like to be able to make sure they increase the package versions where needed. The other issue is that I'd like to be able to make package patches from builds but thats another item. Apr 20 11:39:34 * rink_ never increments package versions when adding patches and stuff... it's amazing how well the dependency tracking in bitbake works Apr 20 11:44:37 buildserver has a load of 55. This may take a while Apr 20 11:45:27 does bitbake have a python lib backend or sumsuch? Apr 20 12:03:28 JaMa: thanks for the reminder about the fontconfig patch. I want to talk to rburton about it and check his concern was addressed but will merge as soon as I can to do (or give feedback) Apr 20 12:04:02 * RP really needs to get a better process around this... Apr 20 12:07:58 JYDawg: there is "tinfoil" that allows accessing some of the internals e.g. parsing Apr 20 12:09:23 JYDawg: here's an example of using it: https://gist.github.com/bluelightning/6138980 Apr 20 12:17:59 i've got a layer working, where can i set distro params on my layer to override current default ones? Apr 20 12:20:23 miandonmenmian: add a conf/distro/yourdistroname.conf with the settings you want, and then set DISTRO = "yourdistroname" in conf/local.conf Apr 20 12:20:35 miandonmenmian: http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#creating-your-own-distribution Apr 20 12:21:59 bluelightning: thanks a bunch. i've also had some trouble setting maintainer on per package basis. isnt it suposed to be MAINTAINER= " " on the .bb ? Apr 20 12:23:28 miandonmenmian: where are you expecting the MAINTAINER value to show up? Apr 20 12:23:44 on opkg Apr 20 12:26:05 bluelightning: ELF binary '' has relocations in .text [textrel] from here: http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html -> What would be the solution suggested? -fPIC/-fpic or something else? Apr 20 12:26:47 miandonmenmian: well, near as I can tell, setting it in the recipe should affect any packages produced; it may be that just changing MAINTAINER doesn't trigger do_package to re-execute though, I'm not sure Apr 20 12:27:50 lpapp: I believe so yes Apr 20 12:28:31 bluelightning: could be put into the document as a hint, no? Apr 20 12:29:44 lpapp: http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#qa-issue-textrel could be extended yes Apr 20 12:32:46 ok, thanks Apr 20 12:34:25 RP: thanks Apr 20 12:35:31 lpapp: thanks for filing, i can remove that from my todo list now ;) Apr 20 12:35:42 RP: this one is only 1 week old, but also didn't get any feedback (nor is in master-next) http://lists.openembedded.org/pipermail/openembedded-core/2015-April/103684.html Apr 20 12:41:49 bluelightning: :D np. Apr 20 12:53:48 bluelightning: nice, starting to look a lot like what I need. Apr 20 12:55:16 bluelightning: I am getting some strange warnings, https://paste.kde.org/proplo3gj Apr 20 12:56:27 JaMa: didn't see that one for some reason. Have replied suggesting a minor tweak to the naming Apr 20 12:56:56 lpapp: there was a regression a while ago where we now expect everything added to ROOTFS_POSTPROCESS_COMMAND to be a function rather than a plain command Apr 20 12:57:52 bluelightning: followed the process, seems the layer is found alltogether with packages, that individually do well. however, image is not. set the distro as per the guide link you shared didnt work for me. do i need to refresh the cache for the distro to appear? Apr 20 12:57:59 lpapp: I suppose we should probably fix it, but then again using functions is generally a better way to structure things there Apr 20 12:59:05 miandonmenmian: what exactly is failing? I'm not quite following... Apr 20 12:59:37 bitbake mydistro does not exist Apr 20 13:00:02 miandonmenmian: that isn't generally expected to work Apr 20 13:00:08 bluelightning: should probably also be documented in the migration guide? Apr 20 13:00:34 not expected to work as in will have problems? or as in nothing will happen? Apr 20 13:00:35 miandonmenmian: a distro is a set of configuration values that you can select through DISTRO, it's not a target you can build Apr 20 13:01:03 miandonmenmian: what I suspect you want in addition is to define a custom image recipe containing the packages you want Apr 20 13:01:26 lpapp: well, not if it's a bug that we should fix, no Apr 20 13:02:46 bluelightning: BBFILE_COLLECTIONS ? Apr 20 13:03:45 does that refer to the set of configuration for the distro? or i need to look for this inside the distro.conf file? Apr 20 13:04:13 bluelightning: ok, i will take a look at your second suggestion, seems like that is exactly what i need Apr 20 13:04:51 miandonmenmian: if you haven't already seen it - http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#usingpoky-extend-customimage Apr 20 13:05:59 bluelightning: is it a bug or feature? ^_^ Apr 20 13:06:10 either way, report is neded for either? Is there one already to fix this regression? Apr 20 13:07:04 lpapp: it seems like a regression to me, if you could file a bug that would be great Apr 20 13:25:01 bluelightning: submitted, thanks. Apr 20 13:30:10 can the target Runtime Package Management install .deb or .rpm from existed distribution repository? Apr 20 13:31:24 if they have same CPU architecture. Apr 20 13:31:54 or we must build our own repository? Apr 20 13:36:30 the history command is still present but the list of commands is not persistent, how can I enable it? Apr 20 13:46:52 i'm building a package that installs a file, without do_compile. the file is located on the recipe/files and im calling it with SRC_URI = "file://myfile" Apr 20 13:47:17 install -m 644 ${WORKDIR}/myfile ${D}/usr/lib/myDestinationFolder Apr 20 13:47:28 is this wrong? my package is built empty Apr 20 13:47:33 bluelightning: it does not matter whether it is a python or bash function? Apr 20 14:00:45 lpapp: that is one of the things we gained in exchange for the regression, yes Apr 20 14:02:16 bluelightning: how can I assign a function to a variable? Apr 20 14:02:28 is there an example somewhere? Apr 20 14:02:47 just pass the function name along? Apr 20 14:02:47 miandonmenmian: you will need to add that path to FILES_${PN} i.e. FILES_${PN} += "${libdir}/myDestinationFolder" (and use ${libdir} rather than /usr/lib in your install command Apr 20 14:03:07 lpapp: ROOTFS_POSTPROCESS_COMMAND is still semicolon-separated, that hasn't changed Apr 20 14:03:45 so the function names separated by semicolon? Apr 20 14:04:15 yes Apr 20 14:04:21 thank you very much Apr 20 14:10:32 bluelightning: add the file to path for the do_install function ? Apr 20 14:10:53 miandonmenmian: no, outside of it Apr 20 14:12:22 miandonmenmian: assuming you were asking where to put this FILES_${PN} line Apr 20 14:13:06 yes, that is right, sorry. However, i am not sure I understand it: Apr 20 14:13:41 the source SRC_URI += "file://myfile" assumes the recipe folder? Apr 20 14:14:23 i was worried the file was lost on {WORKDIR} since there are no other sources. perhaps the line should be SRC_URI = Apr 20 14:14:24 miandonmenmian: myfile should be placed in a directory next to the recipe, named either the same as the recipe, or "files" Apr 20 14:14:56 bluelightning: ok, well, at least got that right :S Apr 20 14:17:49 somehow, on verbose, bitbake is still looking for sstate folder sources Apr 20 14:18:02 package is built empty Apr 20 14:19:04 miandonmenmian: something is still wrong with your FILES line then, it's not matching up Apr 20 14:20:13 miandonmenmian: just checking, are you using Toaster or oe-init-build-env-memres? Apr 20 14:20:35 oe-init-build-env Apr 20 14:21:28 miandonmenmian: would you be prepared to pastebin your recipe? Apr 20 14:21:47 should've done that before. sorry. give me a sec Apr 20 14:25:53 bluelightning: http://apaste.info/4mh Apr 20 14:31:01 miandonmenmian: you need an install -d command to create the ${D}${libdir}/python-2.7 directory Apr 20 14:31:32 miandonmenmian: also you should be doing FILES_${PN} += not = (although that won't make much difference in this case, but it's good practice) Apr 20 14:31:37 bluelightning: tried that as well. however, another package should be bcreating this directory Apr 20 14:32:07 miandonmenmian: doesn't matter, this recipe builds in isolation as far as the install step is concerned Apr 20 14:32:39 i'm reading another doc that adds the asterisk at the end for the FILES line. ${libdir}/lib*.so.* \ does the myfile have to be included here? or just the path ? Apr 20 14:32:49 miandonmenmian: the path is sufficient Apr 20 14:33:29 miandonmenmian: you shouldn't be inheriting autotools or gettext for this recipe either Apr 20 14:33:41 ah, that is a very good point Apr 20 14:34:02 you do have a closing } at the end of do_install as well right? Apr 20 14:35:02 oh, brother... Apr 20 14:36:09 thanks a bunch bluelightning, that was probably it Apr 20 14:36:30 it's curious that that didn't trigger an error Apr 20 14:37:10 i was wondering as well. but i'm pretty certain i have not seen any with regards to the do install or brackets Apr 20 14:52:30 after reproducing the lack of error I filed a bug: https://bugzilla.yoctoproject.org/show_bug.cgi?id=7633 Apr 20 14:52:31 Bug 7633: normal, Undecided, ---, richard.purdie, NEW , Parser does not error out on unclosed function Apr 20 14:55:43 hey guys, i'm trying to build yocto for rpi with qt5. so i'm using poky master, meta-qt5 master, meta-raspberrypi master and meta-openembedded master. Apr 20 14:55:43 my bblayers.conf goes like http://apaste.info/pI0 , while my local.conf goes like http://apaste.info/qcU . Apr 20 14:55:43 qtbase fails to compile - the error log goes here http://apaste.info/DIT . Apr 20 14:55:43 did anyone of you succeed in building this configuration? any opinions? Apr 20 14:57:28 and i forgot to mention that i've edited qtbase.inc to use gles2 instead of desktop gl Apr 20 15:26:27 bluelightning: I am getting this, WARNING: libstdc++-4.8.2 was registered as shlib provider for libstdc++.so.6, changing it to foo-0.1 because it was built later Apr 20 15:26:32 I wonder hwy Apr 20 15:26:33 why* Apr 20 15:26:59 lpapp: is foo-0.1 is installing its own libstdc++.so.6? Apr 20 15:27:16 not as far as I am aware of. Apr 20 15:27:27 the warning would suggest that it is Apr 20 15:27:45 oh, wow, it does Apr 20 15:27:51 how nasty Apr 20 15:28:01 this is not what I agreed with my colleague :P Apr 20 15:48:20 hi. i simply want to build my linux kernel. i use an external toolchain. i only do: bitbake virtual/kernel -- and that works. but why there are 457 tasks installing i.e binutils-native, so *-native* packages? is this really needed to just compile my kernel? how to remove unused stuff? can i blacklist this? Apr 20 16:39:22 hmm, renaming yocto based repositories with ain't fun. Apr 20 16:39:52 sadly, git will not do renaming of a directory with more than 4K files without further trouble and it seems the poky repository has far more than that file amount. Apr 20 16:51:16 bluelightning: so is it ok to use PRIVATE_LIBS then? Apr 20 16:51:26 it would be less work for me now than refactoring the system with testing. Apr 20 16:52:08 you probably should yes Apr 20 16:52:59 though it probably won't change the behaviour since it appears to have acknowledged your "custom" version of the lib Apr 20 16:53:48 yes, that is fine, I just want to get rid of the warning. Apr 20 16:54:01 ericbutters: i'd say use bitbake -g, possibly with depexp, to explore the dependency graph to determine that. e.g. bitbake -g -u depexp virtual/kernel Apr 20 17:26:01 bluelightning: if you had not seen it, https://bugzilla.yoctoproject.org/show_bug.cgi?id=7632 Apr 20 17:26:02 Bug 7632: normal, Undecided, ---, scott.m.rifenbark, NEW , ROOTFS_POSTPROCESS_COMMAND no longer accepts raw commands, just functions Apr 20 17:27:24 bluelightning: which file shall I put into PRIVATE_LIBS, the library with the symlinks, too? Apr 20 17:27:34 there are two symlinks created by the recipe to the library. Apr 20 17:27:43 just the library I believe Apr 20 17:27:58 so libstdc++.so -> libstdc++.so.6 -> libstdc++.so.6.0.10 Apr 20 17:29:59 bluelightning: so in my case libstdc++.so.6.0.10 or libstdc++.so? Apr 20 17:30:19 http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#var-PRIVATE_LIBS -> this seems to use the .so files. Apr 20 17:30:22 not the versioned ones. Apr 20 17:30:32 I wonder if that is intentional or just coincidence. Apr 20 17:30:57 not sure, sorry Apr 20 17:31:10 ok, I will keep trying until the warning is gone. Apr 20 18:23:08 what is the status of fido? Is it too late to pull in the latest bluez (5.30)? Apr 20 18:31:27 does the Yocto build bail out with failure if a patch cannot be applied? Apr 20 18:32:43 if a patch can't be applied, the do_patch task will fail. bitbake will then cleanly shut down, letting the other currently running tasks finish, and then exit non-zero, unless you run with bitbake -k, in which case it will continue running as many tasks as it's possible to run given the task that failed, and will then exit non-zero Apr 20 18:33:18 the -k argument came from gnu make, which has similar behavior Apr 20 18:38:50 ok, thanks. Apr 20 18:39:13 I updated from dylan to daisy and the build succeeds, but my kernel will no longer boot Apr 20 18:39:31 it hungs up at the state of "Uncompressing Linux... done, booting the kernel." Apr 20 18:39:43 we have our own kernel recipe, not sharing it with Yocto Apr 20 18:39:57 and after the upgrade, we did not change that, so I am surprised that it is broken. Apr 20 18:40:11 possibly a toolchain version problem, assuming the kenrel hasn't changed Apr 20 18:40:15 perhaps the kernel was created properly, but the image not? Apr 20 18:40:21 there have definitely been issues with certain gcc versions and the kernel Apr 20 18:40:23 I guess I would need to look into the the log.*? Apr 20 18:40:46 that's a possibility too, but if it stops that early, i doubt it got far enough to run init in the rootfs Apr 20 18:40:50 hmm, I would not know how to proceed from there as I am not the kernel developer in here. Apr 20 18:40:53 unless you're passing quiet in the cmdline Apr 20 18:41:01 in which case you should remove that so you can see more of what's going on Apr 20 18:41:18 oh, kernelopts=rw rootwait quiet Apr 20 18:41:22 uboot has that, indeed Apr 20 18:41:28 good idea :) Apr 20 18:41:31 (to check it) Apr 20 18:41:55 :) Apr 20 18:42:30 the bootlog seems to be the same without that, too :( https://paste.kde.org/pktk6fov5 Apr 20 18:43:06 I wonder how to proceed from here. I wish I had more low-level Linux kernel experience. Apr 20 18:43:21 there must be some command line option to turn more logging on Apr 20 18:43:25 my *guess* would be a possibly miscompiled kernel, assuming you're using an internal toolchain Apr 20 18:43:37 yeah, should be able to crank up console printk log level Apr 20 18:43:42 i don't recall the exact syntax offhand, though Apr 20 18:44:21 I am using the toolchain that Yocto generates. Apr 20 18:44:30 but I can double check the log.do_compile file for the kernel Apr 20 18:45:36 hmm, sadly not built with VERBOSE=1 Apr 20 18:45:55 NOTE: make -j 8 uImage CC=arm-foo-linux-gnueabi-gcc -mno-thumb-interwork -marm LD=arm-foo-linux-gnueabi-ld.bfd Apr 20 18:46:00 this is the best I can get out of it. Apr 20 18:46:32 not sure if that'll change anything, usually such bugs will just be a bad interaction between gcc and the kernel resulting in something ending up miscompiled, but no indication of such in the gcc output. i don't know of any specific bugs like that offhand, but i've seen them before. usually the kernel will end up with a fix to adjust for it later on. could check the kernel log for after your version, i suppose Apr 20 18:46:46 there is this in the compilation log, but I am not sure if it can be ignored: WARNING: modpost: Found 1 section mismatch(es). Apr 20 18:46:48 also don't know what version of gcc was used in your previous poky version vs current Apr 20 18:47:46 me neither, I would need to look it up, but it was a dylan to daisy change Apr 20 18:47:47 no idea, unfortunately. been long enough since i've done any kernel development that those skills are all atrophied and out of date :) Apr 20 18:47:47 might be something else, this was all that came to mind as a possibility Apr 20 18:47:47 * kergoth shrugs Apr 20 18:48:38 ok, thank you Apr 20 18:48:46 I will probably ask this in #kernelnewbies, too Apr 20 18:48:54 they might be less rusty than us :P Apr 20 19:40:09 Hmm, I should propose adding 'd' to event handlers, the way it's available elsewhere and via e.data, just as a convenience Apr 20 19:46:44 should also propose including the cooker's expanded_data in the ConfigParsed event Apr 20 19:47:00 both would simplify some event handlers somewhat Apr 20 19:47:05 * kergoth adds todo Apr 20 20:29:03 * kergoth moves the meta-sourcery sanity checks from BuildStarted to TreeDataPreparationStarted Apr 20 21:29:30 Can we generate a rootfs tar with symbols and debug info and then strip it for final image ? Apr 20 21:30:10 current tarball is as much stripped as any other image fs type Apr 20 21:40:11 not that i know of, but work has been done on generating a separate filesystem with just the -dbg packages installed, so you can point gdb at that. not sure if that was ever merged, however Apr 20 21:40:39 do you have links Apr 20 21:40:57 checking for it now Apr 20 21:40:59 it should be like Apr 20 21:41:06 IMAGE_FSTYPES Apr 20 21:41:26 fs types just control archival of the fs, that's too late to change their content Apr 20 21:42:04 I meant from usability POV Apr 20 21:42:12 underneath I agree Apr 20 21:42:59 you can alwyas add dbg-pkgs to IMAGE_FEATURES< but of course that affects every output of the image Apr 20 21:43:17 th enice thing about a separate debug fs is you can e.g. put it on a usb stick, or just extrac tit to point gdb at when you connect to gdbserver Apr 20 21:43:34 looking for the patch/branch now Apr 20 21:43:56 exactly Apr 20 21:44:21 I want the images to be stripped but corresponding debug rootfs image in tarball Apr 20 21:44:44 so folks can use it to debug the crash by booting from USB and so on Apr 20 21:45:05 we rolled our own version of it in meta-mentor a while ago, but the pending one sent to the list is cleaner, if i can track the damn thing down Apr 20 21:45:22 i need to start jotting down pending branches / patch series that interest me so i can monitor their status Apr 20 21:45:23 heh Apr 20 21:46:51 khem`: see poky-contrib, mhatle/debugfs Apr 20 21:47:18 also went to oe-core, "image.bbclass: Add a method for creating a companion debug filesystem" Apr 20 21:48:32 ok Apr 20 21:48:48 hope it will work with 1.6 too Apr 20 21:49:07 depends on whether 1.6 was before image construction got converted to python, i don't remember when that happened :) Apr 20 21:51:02 ls ../lib/oe/package.py Apr 20 21:51:03 ../lib/oe/package.py Apr 20 21:51:08 so yes it was :) Apr 20 21:51:11 nice Apr 20 21:51:21 let me try it Apr 20 21:55:32 I dont see it in OE-core Apr 20 21:55:39 do you have a SHA Apr 20 21:55:48 it went to the oe-core *list*, but wasn't merged Apr 20 21:55:52 still pending, no one merged it Apr 20 21:56:02 should be in patchwork, i'd expect Apr 20 21:56:28 should reply with a reminder in case it fell off the radar Apr 20 21:56:49 i'm sick of having overridden image.bbclass in meta-mentor-staging :) Apr 20 21:57:32 ah I see Apr 20 21:58:08 http://patchwork.openembedded.org/patch/83519/ Apr 20 21:58:25 you acked it Apr 20 21:58:35 thats good but no heed Apr 20 21:59:20 yeah, i'm guessing it probably fell off richard/saul's radar and mhatle and i never followed up Apr 20 21:59:26 it happens Apr 20 21:59:48 right Apr 20 21:59:55 so resurrect it Apr 20 22:00:06 thats why pw is so useful Apr 20 22:00:22 we dont use it as effectively for oe-core as we do for other layer s Apr 20 22:01:09 replied Apr 20 22:01:11 agreed Apr 20 22:07:37 kergoth: its intended for master FWIW, just never see the patch at the right time :/ Apr 20 22:12:24 RP: its has become a bit stale Apr 20 22:13:03 khem`: I think fray said he'd repost it Apr 20 22:13:32 cool Apr 20 22:14:02 its worth for 1.8 too Apr 20 22:18:12 cool Apr 20 22:18:13 looks like the rejects are pretty straightforward to resolve, it seems, just did it here when applying it to meta-mentor-staging as a temporary measure. Apr 20 22:49:35 kergoth: can you post the updated patch somewhere ? Apr 20 22:53:32 khem`: https://gist.github.com/5412df1791f596630696 Apr 20 22:53:58 curl https://gist.githubusercontent.com/kergoth/5412df1791f596630696/raw/81780886483d195d3f84aae091646987347534a3/- | git am Apr 20 22:54:35 only limited testing done Apr 20 22:54:38 but should be fine Apr 20 22:54:52 stuck waiting on a rebuild mostly from scratch after updating our upstream layers Apr 20 22:54:54 * kergoth taps foot Apr 20 22:55:09 heh Apr 20 22:56:37 sstate is nice and all, but still feels awfully brittle, doesn't take much to end up rebuilding the world from scratch Apr 20 22:57:18 need to think about how to implement task output checksumming.. would likely be non-trivial, though, would require adjusting the runqueue more on the fly Apr 20 23:18:33 kergoth: Yeah i am getting lot of fire for it Apr 20 23:19:42 even output checksumming wouldn't be perfect, given we'd have to figure out how to limit the scope by path potentially, or capture the api of the output, or fix builds to be more reproducible, less encoding of timestamps and whatnot.. probably a combination of all of them Apr 20 23:20:44 there's also the possibility of having file-level task-dependencies coupled with the output checksumming, e.g. we only depend on these files, only if they change should we rebuild, but others might depend on something else Apr 20 23:23:49 hmm, bitbake chokes if TMPDIR is g+s.. we should improve it so it just does a chmod g-s when TMPDIR is created in the first place, if possible Apr 20 23:24:01 if we know what's wrong, and what's wrong is in our output, we should just fix it Apr 20 23:24:22 it's quite reasonable for COREBASE & friends to be g+s for sharing will colleagues Apr 20 23:24:37 so if you create build dirs in ${COREBASE}/.., bitbake gets unhappy Apr 21 01:34:43 hello..my bitbake process shows warning rdepends on libgl-mesa. I then added libgl-mesa to DEPENDS variable in my recipe but now it says nothing provides libgl-mesa...any idea? Apr 21 01:41:15 add it to RDEPENDS_${PN} = "libgl-mesa" Apr 21 01:41:22 never mind..I added them to RDEPENDS_${PN} instead and all is well Apr 21 01:41:43 I wonder why can't I add it to DEPENDS variable? Apr 21 01:42:03 DEPENDS is for recipes, not binary packages Apr 21 01:42:09 RDEPENDS is runtime, binary packages Apr 21 01:42:11 DEPENDS is build time Apr 21 01:42:17 RDEPENDS is for runtime Apr 21 01:42:41 so DEPENDS = "recipe-name" and RDEPENDS = "ipk name" Apr 21 01:43:01 kergoth: I build sstate using externalsrc and then try to use it elsewhere Apr 21 01:43:14 and it invalidates it because ${S} changed Apr 21 01:43:22 any remedies Apr 21 01:43:43 externalsrc explicitly disables use of sstate. see the bb.build.deltask() Apr 21 01:44:03 hmm Apr 21 01:44:13 but yes, you could use vardepsexclude on all the tasks using it, or globally add to BB_HASHBASE_WHITELIST, but that's across everything, not per recipe, so would invalidate all current checksums Apr 21 01:44:41 probably don't want to do the latter Apr 21 01:44:55 but yeah, unless you kill the bits disabling sstate, it won't do much anyway Apr 21 01:45:23 so big issue for folks who has the flat tree dev Apr 21 01:45:26 like android Apr 21 01:45:41 all tooling is around that kind of development Apr 21 01:45:44 for platform work Apr 21 01:46:09 yeah. i've often thought it'd be fun to try a complete oe-core build with everything using local git sources and versions extracted from the git repos Apr 21 01:47:58 kergoth: yes Apr 21 01:48:08 kergoth: khem`: So what I understand now is DEPENDS is recipe dependency, and RDEPENDS is runtime dependency. Is that right? Apr 21 01:48:46 chankit: yes Apr 21 01:49:14 kergoth: http://bazel.io/ Apr 21 01:49:19 have you seen it Apr 21 01:49:22 nope Apr 21 01:49:36 oh i remember seeing it linked on hacker news or something Apr 21 01:49:40 didn't look very closely yet Apr 21 01:49:50 it looks promising Apr 21 01:50:03 build from source Apr 21 01:50:15 the kind of thing we are talking Apr 21 01:50:27 khem`: So is it true that there are binary packages that are not provided by any recipe? Apr 21 01:51:24 chankit: that doesn't really make sense. Apr 21 01:51:35 chankit: yes e.g. if they are empty then packager will optimize them out Apr 21 01:51:56 kergoth: I'm afraid I'm just confused here. Apr 21 01:51:59 so you might have to add ALLOW_EMPTY_ Apr 21 01:52:07 every recipe emits multiple binary packages Apr 21 01:52:23 the main package might not be emitted if the recipe doesn't install any files, as khem points out Apr 21 01:52:50 kergoth: I have been looking at gradle too Apr 21 01:52:55 and cmake Apr 21 01:53:00 as alternatives Apr 21 01:53:42 I'd like to play with something whose primary output is the binary package(s). local sources -> packages, deal with both fetching and feed/image construction as separate steps Apr 21 01:54:03 construct sysroots from the packages Apr 21 01:54:18 no separate task level scheduling and task acceleration via sstate Apr 21 01:54:24 just as an experiment to see how it goes Apr 21 01:55:07 kergoth: BUILD_IMAGES_FROM_FEEDS Apr 21 01:55:16 you can stay in bb world Apr 21 01:55:29 kergoth: khem`: I think I'm starting to get some sense here....so suppose that a recipe foo spawns binary packages spam and egg, and another recipe bar has a runtime dependency on spam, then I should do RDEPENDS_{"bar"}=spam ? Apr 21 01:56:02 RDEPENDS_${PN} += "spam", yes Apr 21 01:56:35 but 90% of the time the runtime dependency is due to shared library linking, and those you don't have to do manually. if A links against a library in B, A will automatically rdepend on B Apr 21 01:59:00 so rdepends variable can have libraries, binaries and what else? Apr 21 01:59:02 kergoth: BUILD_IMAGES_FROM_FEEDS is something we can use ? Apr 21 01:59:11 also should accelarate Apr 21 01:59:11 right ? Apr 21 01:59:13 chankit: again, doens't really make sense. rdepends lists binary packages. Apr 21 01:59:23 chankit: what gets put in those packages is up to the recipe Apr 21 01:59:32 the recipe that created them, that is Apr 21 01:59:50 khem`: i think so, never actually tried it myself. would be interesting to play with Apr 21 02:00:17 meh, meta-sourcery has problems with multilibs again, no preferences are specified for the multilib variants.. maybe i need some ${MLPREFIX}'s Apr 21 02:01:09 either that or i need to stop handling the preferences this way Apr 21 02:01:11 multilib should die Apr 21 02:01:19 kergoth: let me try again...erm...so rdepends can only contain packages? Apr 21 02:01:49 as we said earlier, DPEENDS contains build time dependencies, which are recipes, and RDEPENDS contains runtime dependencies, which are packages Apr 21 02:03:04 kergoth: ok...got it..thanks Apr 21 02:14:48 kergoth: I wonder how will BUILD_IMAGES_FROM_FEEDS interact with sstate Apr 21 02:14:59 is it a addition **** ENDING LOGGING AT Tue Apr 21 02:59:58 2015