**** BEGIN LOGGING AT Thu Feb 28 02:59:58 2013 Feb 28 10:56:39 hello Feb 28 10:59:31 morning all **** BEGIN LOGGING AT Thu Feb 28 12:27:15 2013 Feb 28 12:49:10 RP_: do you have a minute? I'm trying to wrap my head around your remarks about RDEPENDS_${PN}-ptest += "make". I can't make that cause "make" to be built without defining the "ptest" distro feature. what am I missing? Feb 28 15:04:46 hey guys... Feb 28 15:05:35 i am totally new to openembedded and i am trying to figure out which version of u-boot and which patches my openembedded beaglebone config uses Feb 28 15:05:48 i found this: ./sources/meta-ti/conf/machine/beaglebone.conf Feb 28 15:06:02 but it doesnt really tell me much Feb 28 15:07:20 it just says: UBOOT_MACHINE = "am335x_evm_config Feb 28 15:07:27 and EXTRA_IMAGEDEPENDS = "u-boot" Feb 28 15:15:20 bitbake -s may well be what you're looking for Feb 28 15:22:44 morning Feb 28 15:42:16 kergoth: i dont understand what that does? Feb 28 15:43:00 u-boot :2011.09+git-r30 Feb 28 15:43:38 i take it that means it will build that version of u-boot... but it is obviously referring to some git repo... which one? what are the -r30 patches all about? where can i find them Feb 28 15:57:27 tuxx_: you have to look at the corresponding recipe Feb 28 15:58:01 tuxx_: one way to find that is to do bitbake-layers show-recipes u-boot Feb 28 15:58:40 tuxx_: er bitbake-layers show-recipes -f u-boot Feb 28 15:58:59 bluelightning: hmm.. Feb 28 15:59:18 bluelightning: recipes are like build-scripts? Feb 28 15:59:22 tuxx_: or alternatively, bitbake -e u-boot | grep ^FILE= Feb 28 15:59:26 bluelightning: with the configure flags and whatnot Feb 28 15:59:56 tuxx_: right, more or less Feb 28 16:00:03 bluelightning: i http://pastebin.com/MzdCULHR Feb 28 16:00:31 can zou just briefly explain how that is to be interpreted? :) Feb 28 16:00:43 that's showing all the recipes whose name matches u-boot Feb 28 16:00:50 quite a few in your current configuration Feb 28 16:01:12 i have to add MACHINE=beaglebone Feb 28 16:01:26 bluelightning: yea i'm not sure which one it is actually using Feb 28 16:01:29 let me grep them for beaglebone Feb 28 16:01:53 (skipped) means there's some directive in the recipe that is telling bitbake to skip it... usually this is something like it is set to be compatible with only a set number of machines/architectures and your current configuration doesn't match Feb 28 16:02:07 tuxx_: use the alternative method: bitbake -e u-boot | grep ^FILE= Feb 28 16:02:17 /home/tuxx/tmp/setup-scripts/sources/meta-ti/recipes-bsp/u-boot/u-boot_2011.10rc.bb: file://2011.09git/0005-am335x-evm-enable-i2c2-pinmux-for-beaglebone.patch \ Feb 28 16:02:31 most like it uses that since theres a beaglebone patch in it Feb 28 16:02:34 let me try the other method Feb 28 16:03:43 FILE="/home/tuxx/tmp/setup-scripts/sources/meta-ti/recipes-bsp/u-boot/u-boot_2011.10rc.bb" Feb 28 16:03:46 FYI, that command says print me the environment for the recipe currently selected to provide "u-boot" and then filter it to show me the value of the FILE variable, which points to the recipe file Feb 28 16:03:56 bluelightning: right. thanks Feb 28 16:04:03 right, so your guess was correct Feb 28 16:04:16 ok now that file Feb 28 16:04:31 contains a bunch of patches.. let me pastebin it Feb 28 16:04:55 http://pastebin.com/Qk7iFcpb Feb 28 16:05:09 i reckon it is based on the git:// repo and then it applies the list of patches below that Feb 28 16:06:14 tuxx_: yep Feb 28 16:06:23 thanks bluelightning! Feb 28 16:06:27 np Feb 28 16:06:40 bluelightning: one last thing.. it would kind of be nice to see the actual buildscript, if possible Feb 28 16:07:00 tuxx_: the actual buildscript? you mean what commands get executed? Feb 28 16:07:02 like the "make CROSS_COMPILE=... am335x_evm_config" etc Feb 28 16:07:05 right Feb 28 16:07:59 you can do bitbake -v, that might show what you're looking for; another way is to look at the run.do_* scripts written out to the TMPDIR/work/*/recipename/version/temp/ directory Feb 28 16:08:06 bluelightning: i probably can build it on my own from here.. but it would be interesting to know Feb 28 16:08:31 bluelightning: -v will probably show me the output of the compile and i'll have to filter the commands manually rihgt? Feb 28 16:08:40 yeah Feb 28 16:08:56 bluelightning: okay i saw the log dir .. i will check that in a bit. thanks for the tips! Feb 28 16:33:19 bluelightning: it works.. thanks again Feb 28 16:33:28 tuxx_: no worries Feb 28 17:43:38 bluelightning_, please please add populate_sdk support to buildhistory :) Feb 28 17:43:52 I need to debug a sdk and am going nuts Feb 28 17:44:06 btw, anyone know who knows the most about populate_sdk? Feb 28 17:44:15 Crofton: can you file a bug and I'll try to look at it; unfortunately I'm away from this evening until next tues Feb 28 17:44:26 like, if I change the image file (leave PR alone) what do I need to do to rebuild the sdk Feb 28 17:44:33 ok, will do Feb 28 17:44:57 basically, I am running into some issues, and having it tell me what it did would be really helpful Feb 28 17:45:04 I am certain others will run into this Feb 28 17:45:13 Crofton: probably fray would be the best person to advise about populate_sdk since he wrote it :) Feb 28 17:45:20 ok thanks Feb 28 17:46:35 I was going to git log and figure that out Feb 28 17:51:44 bluelightning_, also, you should look at using meetbot for TSC meetings Feb 28 17:52:15 maybe I will have the OE board direct you too :) Feb 28 17:52:28 Crofton: ok, sure, I can ask about it Feb 28 17:56:07 I can point my bot at the channel you use Feb 28 17:57:08 the only headache is I need to manually mail the output to you after the meeting, but that is fine with me Feb 28 17:58:17 Crofton: probably best person to ping is jefro since he very kindly takes care of the minutes Feb 28 17:58:21 ok Feb 28 17:58:23 will do Feb 28 17:58:39 I jsut thought of it this morning Feb 28 17:58:43 ok Feb 28 17:58:48 thanks Feb 28 17:59:44 also, if anyone knows anything about pci drivers, can you msg me privately. I have an "opportunity" Feb 28 19:36:50 fray, when you get a chance, can we talk about populate_sdk? Feb 28 19:41:57 I'm here for a little bit.. Feb 28 19:42:00 what do you want ot know? Feb 28 19:44:47 I need to insert some python stuff into the host bits Feb 28 19:45:04 packages or? Feb 28 19:45:04 the program I am building need python-cheetah Feb 28 19:46:02 if you have a nativesdk-python-cheetah... you can do: TOOLCHAIN_HOST_TASK_append = " nativesdk-python-cheetah" Feb 28 19:46:06 and it'll be added to the SDK.. Feb 28 19:46:16 (that'll work with the meta-toolchain as well) Feb 28 19:46:25 yeah, that sort of worked, but cheetah needs python-netserver Feb 28 19:46:41 if the deps are right, they should be brought in automagically Feb 28 19:46:56 (if you don't care to get the deps right) you'll have to just keep adding to that _append Feb 28 19:47:02 also, if I make a change, how to best orce update when I re-rnu populate_sdk? Feb 28 19:47:20 the cheetah deps are dodgy Feb 28 19:47:55 * Crofton will add abug for buildhistory not reporting on populate_sdk also :) Feb 28 19:47:55 just running the -c populate_sdk -should- reevaluate all of the dependencies, including the ones you've added.. Feb 28 19:48:15 yes.. I've been meaning to file that as well Feb 28 19:48:16 do I need to bump PR's? Feb 28 19:48:28 I'll try and add you to the cc for it Feb 28 19:48:36 whatever you would normally have to do to get a rebuild, you'll have to do.. with the master stuff.. I'm not sure anything is necessary Feb 28 19:48:45 I am trying to avoid running the PR up while I debug Feb 28 19:48:47 yeah Feb 28 19:48:52 (populate_sdk is like rootfs task, it never writes a stamp.. so it'll always re-run) Feb 28 19:48:57 ok Feb 28 19:49:20 can I bb -c cleansstate someting-nativesdk? Feb 28 19:49:59 yup Feb 28 19:50:17 populate_sdk is seriously useful Feb 28 19:52:48 Crofton -- yup.. ;) Feb 28 19:53:11 That is out primary "application developer" use-case for our commercial customers.. Feb 28 19:53:36 the meta-toolchain style is useful, but significantly more limited appeal.. (it's great for when you want to share an SDK outside of your org though, and limit what people can link against) Feb 28 19:55:16 the python stuff getting used in thebuild is annoying :) Feb 28 19:55:53 This line from bugzilla should include a poky reference: Meta‑yocto: All defects related to the meta-yocto layer's metadata. Feb 28 19:59:28 fray, https://bugzilla.yoctoproject.org/show_bug.cgi?id=3964 Feb 28 20:35:04 Is there a bitbake command to remove the sources for a recipe so a fetch will have to happen the next time? Feb 28 20:35:21 sr105: bitbake -c cleanall Feb 28 20:35:58 that nukes everything including dependencies, right? Does it limit itself to only the recipe if I use -b? Feb 28 20:36:13 sr105: bitbake -c cleanall foo Feb 28 20:36:18 limits it to foo recipe Feb 28 20:36:54 I think the last time I tried that, it wiped out all of my foo dependencies, too. But then I was running an old bitbake (like 2+ years old) Feb 28 20:37:10 thank you Feb 28 20:37:14 cleanall has never wiped all sources. distclean or mrproper or whatever did, though Feb 28 20:37:15 afaik Feb 28 20:37:28 (by all, i mean more than just the specified recipe) Feb 28 20:37:37 cleanall just cleans hte specified recipe, as jama said :) Feb 28 20:37:45 * kergoth can't seem to articulate his words well today Feb 28 20:37:46 ok, thanks Feb 28 20:38:26 I'm trying to add support to hg.py to be able to tell if it needs to update based on a bookmark/branch name. Feb 28 20:38:35 yes, please don't wipe them out from github :) Feb 28 20:38:48 I'm not seeing how git.py does this (if it does). Feb 28 20:40:02 :) Feb 28 20:42:25 it uses git ls-remote to get the current mapping from ref to commit, generally at parse time, so it can be used in SRCPV Feb 28 20:42:47 if SRCREV is a ref, rather than a commit, taht is Feb 28 20:46:40 Ok, I also seem to have misplaced my copy of git.py where I fixed the broken file:// access where it tried to run ls-remote on a local path. Too many things going on. Feb 28 20:49:14 BTW bitbake 1.10.2 with OE classic does a clean on all dependencies when you run cleanall on a recipe Feb 28 20:49:17 heh, i'm always doing that. losing code i wrote, branches buried in repositories on who knows what machine Feb 28 20:49:19 just tried it Feb 28 20:49:50 that's what made me tentative to try it on the new OE with a newer bitbake Feb 28 20:52:20 ah, guess the task is entirely different than it was in classic Feb 28 20:52:27 bitbake is irrelevent in this context, it's the task in the metadata Feb 28 20:52:35 oe core is quite a bit different from classic :) Feb 28 20:53:03 yes Feb 28 20:53:12 but you can see why I'd be nervous Feb 28 20:53:47 I see how git is doing the rev updates. I'm going to add that to hg.py Feb 28 20:54:12 I really should download the latest bitbake, so I can submit patches. Feb 28 20:54:28 * kergoth nods Feb 28 20:55:11 I was thinking it might be nice to try and make the functionality of git and hg match. Then, we might have a middle class between fetch and git/hg with common code Feb 28 20:55:37 I've already added a bit. I also made it so bitbake can recognize hg meta layers Feb 28 20:56:00 that would be nice, it's obvious mercurial is a bit of a second class citizen at the moment Feb 28 20:56:00 will do Feb 28 20:56:39 yeah, it was obvious. :) I had to open the source just to figure out what a mercurial "module" means. Feb 28 20:56:49 ugh, yes Feb 28 20:56:57 that'd be a remnant of our cvs/svn fetchers, clearly Feb 28 20:57:11 doesn't have much meaning for git either, other than the last component of the url Feb 28 20:57:17 I have a TODO to remove the dependency on module and have it auto-populate by stripping off the last element of the URL path Feb 28 20:57:20 * kergoth gets back to work Feb 28 20:57:28 ok, me too. thanks. Feb 28 21:10:23 Guys, please help. Feb 28 21:10:30 I've created bbappend to linux receipe. Feb 28 21:10:43 I've attached patch (SRC_URI += blabla.path) Feb 28 21:11:01 I've put blabla.path in „files” directory Feb 28 21:11:25 But bitbake still can not find my patch. Feb 28 21:11:31 Unable to download from any source Feb 28 21:12:34 first, it's file://blablah.patch, not blabla.patch Feb 28 21:12:44 second, make surey ou're setting FILESEXTRAPATHS, see other bbappends for examples Feb 28 21:12:56 without that, it won't know to look in the path where the bbappend is for file:// files Feb 28 21:13:26 file://, of course it is. Feb 28 21:13:31 Second, thanks Feb 28 21:14:29 np Feb 28 21:21:51 And failed. Feb 28 21:22:04 fetch was successful, but unpack failed. Feb 28 21:22:11 | cp: cannot stat `/home/dreambox/oe-core-dev/sources/pcm_oss.c.patch': No such file or directory Feb 28 21:24:48 dreambox@linworker:~/oe-core-dev$ find sources/ -iname "pcm_oss.c.patch" Feb 28 21:24:49 dreambox@linworker:~/oe-core-dev$ Feb 28 21:24:54 what is going on? :( Feb 28 21:26:25 otwieracz: is sources in your FILESEXTRAPATHS or why are you looking for that there? Feb 28 21:26:43 first you said something about files directory Feb 28 21:27:00 dreambox@linworker:~/oe-core-dev$ grep FILESEXTRAPATH meta-vts/recipes-vts/linux/linux-dreambox_3.2.bbappend Feb 28 21:27:03 FILESEXTRAPATHS := "${THISDIR}/files" Feb 28 21:27:48 and the patch is in meta-vts/recipes-vts/linux/files? Feb 28 21:27:53 But, wait. Feb 28 21:27:56 What the heck. Feb 28 21:28:04 It isn't. Feb 28 21:28:09 But it is in repository. Feb 28 21:28:16 And the repository is updated… Feb 28 21:29:16 otwieracz: file:// paths do not get fetched into DL_DIR, as they're by definition local. they're pulled into workdir directly Feb 28 21:29:40 But there is no patch in recipe dir. Feb 28 21:29:42 Some git failure. Feb 28 21:29:44 (my failure) Feb 28 21:51:40 I didn't realize that you should always specify branches with name= and not rev= in SRC_URI Feb 28 21:52:16 you should technically use SRCREV, not a parameter at all :) Feb 28 21:52:21 * kergoth dislikes this Feb 28 21:52:26 If you use rev=, it won't look up the actual rev hash and see if it needs to fetch. Feb 28 21:52:51 it's really confusing because there's at least 3 different ways to specify what you want Feb 28 21:53:05 all with subtle implementation differences Feb 28 21:54:00 that's oe/yocto in a nutshell, really ;) Feb 28 21:54:06 flexible, but also many ways to do anything Feb 28 21:54:15 more perl than python in philosophy, which can be problematic at times Feb 28 21:57:36 Well, at least with hg, SRCREV acts like rev= and will not check for an upstream change. Feb 28 21:58:58 definitely sounds broken Feb 28 21:59:18 it's definitely missing some code I see in git.py. Feb 28 21:59:52 but it seems like git might also suffer from the rev=branch_name issue as well. Feb 28 22:37:29 to build the latest meta-oe + openembedded-core -- should the systemd layer in meta-oe be used? Feb 28 22:41:37 removing the meta-oe systemd layer at least gets me parsing ... Feb 28 22:42:16 * cbrake takes a look at the angstrom setup scripts ... Feb 28 22:45:30 cbrake: it's known to be broken with meta-systemd layer included Feb 28 22:46:11 cbrake: there are some patches on oe-devel ML to fix that, but some people including me would prefer oe-core version to be changed instead Feb 28 22:46:12 JaMa: is the a valid way to build systemd images with the latest bits? Feb 28 22:46:51 JaMa: is removing meta-systemd valid? Feb 28 22:50:47 cbrake: if you don't need systemd in image.. Feb 28 22:51:07 JaMa: its hard to give up systemd once you're used to it :-) Feb 28 22:53:05 true, you can apply khem's patch (better use version currently in contrib/jansa/in-test branch) and that will allow you to parse with meta-systemd Feb 28 22:53:11 but upgrade path is still broken **** ENDING LOGGING AT Fri Mar 01 02:59:58 2013