**** BEGIN LOGGING AT Thu Jul 11 02:59:58 2013 Jul 11 05:18:21 after finished the build by "bitbake core-image-basic", how can I get package list that have installed into the target image? Jul 11 05:33:26 fce84x0dev: cat tmp/work/mybigboard-poky-linux/core-image-minimal/1.0-r0/installed_pkgs.txt Jul 11 05:33:46 or something of the sort Jul 11 06:00:03 Hi Jul 11 06:00:22 What is correct way to include kernel headers in user space to build recipe Jul 11 06:01:13 In the documentation, it says that kernel headers for user space are copied to $KERNEL_STAGING... Jul 11 06:01:21 but they are no Jul 11 06:01:22 t Jul 11 06:02:51 What I done was create a compile_append and manually copy the headers to staging directory and it works but is it necessary? Jul 11 06:24:03 Mic, i believe headers used to build packages against are in buildtmp/sysroots/machine/usr/include/linux/ Jul 11 06:24:39 I'm not sure what combination of variables that is. Jul 11 06:56:38 0, Jul 11 06:57:37 hi, do you plan to use gerrit for contribution? Jul 11 06:58:33 lpapp: no Jul 11 06:59:47 the debate over patch review systems is a long and well trodden one, so please lets not repeat it again. let's just say that for now, gerrit has been rejected as an option. Jul 11 07:00:35 that is unfortunate. Jul 11 07:01:14 to a submitter it doesn't make a huge difference - you mail a patch and get feedback on it in your inbox. Jul 11 07:01:54 but as i said, let's not debate gerrit here - it's been done several times and unless you're offering to work on the gerrit source itself to add the features it's missing, there isn't any point. Jul 11 07:01:56 trust me, it makes a huge difference for me Jul 11 07:02:02 and for many other people. Jul 11 07:02:05 we have used both ways ... Jul 11 07:02:15 for years now. Jul 11 07:02:25 lpapp: oh well. you'll manage. i do plan to attempt to fix up the patchwork system (http://patches.openembedded.org/) Jul 11 07:03:11 why another from scratch? :'/ Jul 11 07:03:58 because it solves the problem differently. Jul 11 07:04:34 also, patchwork has been around since 2008, about when gerrit appeared Jul 11 07:05:31 it is sad that we get more tools, and non is complete'ish. Jul 11 07:05:53 IMO, especially since gerrit is open source, it would be better to improve it if needed. Jul 11 07:06:22 as i've said, it's been evaluated and rejected based on it's design and features. Jul 11 07:06:47 halstead: ping Jul 11 07:09:36 I do not see the point of waiting for a perfect system and others to do the job. Jul 11 07:09:49 gerrit is also an open source project, and downstram can add features. Jul 11 07:09:53 lpapp: who said anything about waiting? Jul 11 07:10:08 lpapp: i'll continue talking if you're offering to do the work Jul 11 07:10:09 AlexG: what's up? Jul 11 07:10:22 lpapp: otherwise i've got breakfast to clean away Jul 11 07:12:06 halstead: on private pls :) Jul 11 07:13:07 rburton_: what work? Jul 11 07:16:01 lpapp: the work on talking the the yocto community, getting agreement with relevant stakeholders, working on gerrit to satisfy the requirements, and then finally proposing it. Jul 11 07:17:39 rburton_: I do not even know what is wrong with gerrit for you ... Jul 11 07:18:22 but I would say, getting a code review tool right is probably not a hard sell to any stakeholder. :) Jul 11 07:18:48 lpapp: getting the right cold review tool is. review by email is a perfectly usable tool. Jul 11 07:19:30 many would disagree with "perfectly". Jul 11 07:19:38 * rburton_ shrugs Jul 11 07:19:42 many, that is, having used both ways. Jul 11 07:19:47 many would disagree gerrit is perfect. Jul 11 07:19:55 it's almost like there isn't a perfect tool! Jul 11 07:19:57 no one has ever said gerrit is perfect. Jul 11 07:20:16 no one ever said review by mail was perfect. or review by bugzilla. both of which are popular alternatives. Jul 11 07:20:21 myopiate: what is staging_kernel_dir mentioned in documentation then for .. if it not used. Its confusing Jul 11 07:20:24 anyway time to get the kids dressed. Jul 11 07:21:16 popular does not mean it is better. Jul 11 07:21:36 svn is still popular, too. :) Jul 11 07:22:05 anyway, it is really hard to speak about it without knowing the details of the rejection. Jul 11 07:24:57 good morning Jul 11 07:31:52 When packages are created to tmp/deploy/... What is the naming convention? Jul 11 07:32:15 Do anybody have any idea? Jul 11 09:09:58 Hi for some reason X11 is always added in my image build (building a directfb image), and I'd would like to know from where it's coming, are there any tools for this? Jul 11 09:11:28 becuase you didn't remove x11 from DISTRO_FEATURES? Jul 11 09:11:42 try "bitbake [imagename] -g -u depexp" Jul 11 09:11:55 that will (eventually, for a big image) give you a list of packages Jul 11 09:12:47 okay thx will try Jul 11 09:14:58 rburton_: i get a progressbar loading the cache and then I get a window with nothin in it (with exception for the layout) Jul 11 09:15:27 give it a minute :) Jul 11 09:15:37 (todo: make loading faster) Jul 11 09:15:51 rburton_: aaah okay sorry for complaining ;) Jul 11 09:16:24 no it's quite confusing - the progress bar finishes and then it hangs for a few seconds Jul 11 09:16:58 rburton_: It's longer then a few seconds here, still don't see anything but I'll wait a few minutes :) Jul 11 09:17:22 fenrig: oh, maybe it's actually hung. check the cpu load. Jul 11 09:17:29 there's a race in the startup somewhere Jul 11 09:17:48 this tool was something i hacked up about 6 years ago and nobody's got around to fixing it since :) Jul 11 09:19:48 you will get a big delay on the first boot when packages are configured, iirc Jul 11 09:20:12 rburton_: It doesn't use any cpu cycles :/ Jul 11 09:20:20 rburton: 0% in top Jul 11 09:20:35 fenrig: control-c and try again :(. but if you haven't removed the x11 distro feature, you'll get x11 deps sneaking in through stuff like dbus. Jul 11 09:21:00 and if you change distro feature, you should wipe out tmp and start again Jul 11 09:21:02 http://cgit.openembedded.org/cgit.cgi/openembedded-core/tree/meta/recipes-graphics/images/core-image-directfb.bb?h=master Jul 11 09:21:08 I copied this recipe in my layer Jul 11 09:21:09 yes definitely what tf said Jul 11 09:23:01 morning all Jul 11 09:29:25 packagegroup-core-directfb doesn't exist anymore? Jul 11 09:30:07 meta/recipes-graphics/packagegroups/packagegroup-core-directfb.bb Jul 11 09:30:39 hm, tslib. Jul 11 09:30:40 " Nothing RPROVIDES 'packagegroup-core-directfb' " Jul 11 09:30:48 comes from bitbake :/ Jul 11 09:31:25 try bitbake packagegroup-core-directfb Jul 11 09:31:46 see if that gives a more useful error Jul 11 09:32:14 ERROR: Nothing PROVIDES 'packagegroup-core-directfb' Jul 11 09:32:43 what version of oe-core/yocto/poky are you using? Jul 11 09:32:52 I'm using the angstrom build :/ http://www.angstrom-distribution.org/building-angstrom Jul 11 09:33:13 have a look in your meta/recipes-graphics/ Jul 11 09:33:45 there is a directfb package Jul 11 09:33:51 but not a directfb packagegroup Jul 11 09:34:30 is there a tasks/ directory instead? Jul 11 09:34:53 in meta/recipes-graphics? Jul 11 09:35:02 yes Jul 11 09:35:22 no Jul 11 09:35:34 well it's in oe-core Jul 11 09:36:34 I don't have oe-core Jul 11 09:36:40 I have meta-openembedded Jul 11 09:37:04 I mean openembedded-core Jul 11 09:37:19 openembedded-core = oe-core ;) Jul 11 09:37:24 openembedded-core == oe-core, i was abbreviating Jul 11 09:37:36 https://lists.yoctoproject.org/pipermail/poky/2013-January/008695.html Jul 11 09:37:38 ^^ Jul 11 09:37:48 Angstrom is still 2012.12 Jul 11 09:38:18 thanks ant_work Jul 11 09:39:01 core-image-gtk-directfb <-- use this instead? Jul 11 09:39:08 or how do I go about fixing it ? Jul 11 09:40:35 I'd say yes, in danny is https://github.com/Angstrom-distribution/oe-core/tree/danny/meta/recipes-graphics/packagegroups Jul 11 09:41:12 I could however opt to download the renamed directfb package group :o Jul 11 09:41:13 (I've seen around some Angstrom based on Yocto 1.4 but seems not official yet) Jul 11 09:41:21 so I don't have to add the gtk+ dependency Jul 11 10:05:55 rburton_: fixed it, now about your dependency explorer, every compiled package is visible in the "package" column Jul 11 10:07:54 rburton: I mean every package that has to go in the image Jul 11 10:08:51 fenrig: yes Jul 11 10:09:00 click on the one you don't want and you'll see what is pulling it in Jul 11 10:09:20 i'll admit that tool needs rewriting to be more useful Jul 11 10:09:59 rburton_: strange but I can't find X11 Jul 11 10:10:30 libx11 is a good start Jul 11 10:10:40 rburton_: + the tool just crashed and I can't open because "only one copy of bitbake should be run ..." Jul 11 10:10:51 ps axu |grep bitbake Jul 11 10:11:12 one glorious day i'll rewrite that from scratchl Jul 11 10:12:30 rburton_: (y) got it working again, had to kill python Jul 11 10:14:25 rburton_: No X11 to be seen :o strange Jul 11 10:14:41 so how did you determine that your image has x11 in? Jul 11 10:18:05 well core_image_directfb has a python __anonymous() function Jul 11 10:18:27 and that complains about x11 Jul 11 10:18:37 the function that aborts the build if you didn't remove the x11 distro feature Jul 11 10:18:49 yes indeed Jul 11 10:19:07 so as i said originally, you need to remove x11 from your DISTRO_FEATURES Jul 11 10:22:30 rburton_: in " conf/distro/" of the meta-angstrom dir? Jul 11 10:23:22 never used angstrom, but i presume so. there'll be something setting DISTRO_FEATURES, remove x11 from it and replace with directfb. Jul 11 10:23:50 you may need to set the distro features field entirely, as angstrom may inherit x11 from oe-core. Jul 11 10:24:28 DISTRO_FEATURES += "${LDISGOLD}" Jul 11 10:24:33 -.- yay Jul 11 10:25:52 okay found it in angstrom.inc :) Jul 11 10:32:45 rburton_: I think you fixed it, thx for your help Jul 11 10:33:41 np Jul 11 12:04:22 where can I find the differences between image_install and image_features Jul 11 12:07:42 image_features adds dependencies and image install install the packages? Jul 11 12:08:32 fenrig: IMAGE_FEATURES variable is more generic Jul 11 12:09:22 with IMAGE_INSTALL, you specify which additional packages you want to be installed on the image. So, produced image contains that package Jul 11 12:09:28 fenrig: https://www.yoctoproject.org/docs/1.0/poky-ref-manual/poky-ref-manual.html#var-IMAGE_FEATURES Jul 11 12:11:16 eren: the documentation suggest otherwise: "IMAGE_INSTALL List of packages used to build image" Jul 11 12:11:27 eren: too it's quite confusing Jul 11 12:12:05 eren: though* Jul 11 12:12:39 fenrig: well, I use "IMAGE_INSTALL" variable to specify which packages I want to put into image, hence 'list of packages used to build image' Jul 11 12:12:43 fenrig: it's a bit confusing, yeah Jul 11 12:13:38 eren: okay then I have problems getting qtbase compiled, the only thing I did was switch to directfb (with X11 it did build) Jul 11 12:17:19 fenrig: I haven't been into graphics stuff yet, sorry :/ Jul 11 12:17:32 eren: no problem :D Jul 11 12:21:38 I think I'm missing opengl es, somebody got some pointers on how to include it in my build? Jul 11 12:38:27 Hey guys, having a problem. Anyone here have any idea how to deal with an actual '+' sign in an S assignment? The file I download is Text-Tabs+Wrap-${PV}, and both "Text-Tabs+Wrap-${PV}" and "Text-Tabs\+Wrap" fail beacuse the makefile can't be found (Presumably it can't look into the dir). Any advice? Jul 11 12:39:14 Is there a way to concatentate strings, maybe, and does singlequotes keep interpolation from taking place? Jul 11 12:40:19 I see on eissue with Wrap- Jul 11 12:40:33 should be _ before ${PV} Jul 11 12:41:20 hm.. I'm talking about recipes name, though Jul 11 12:41:30 ant_work, Ah, right. Yes, it is named like that. Jul 11 12:41:42 ant_work, I am talking about setting S, so I can actually do_install and do_compile Jul 11 12:41:48 ant_work, This is the file: http://cpan.metacpan.org/authors/id/M/MU/MUIR/modules/Text-Tabs+Wrap-2013.0523.tar.gz Jul 11 12:41:58 ant_work, It's folder is Text-Tabs+Wrap-${PV} Jul 11 12:42:05 ant_work, Which, apparently, breaks the string interpretation. Jul 11 12:43:00 well, may be. In the past I had issues with kernels called i.e. linux_2.6.37+2.6.38 but was long ago. it was vercmp() Jul 11 12:43:19 ant_work, vercmp()? Jul 11 12:44:40 yes, from bitbake. IT was failing trying to evaluate if the version was grater than x Jul 11 12:45:12 ..this at least 2-3 years ago...then linux-yocto came ;) Jul 11 12:45:46 it's harldy related to your case, though Jul 11 12:46:00 Hmm nope. Jul 11 12:46:08 Do you know how to run a simple action before do_unpack? Jul 11 12:46:11 do_unpack_prepend? Jul 11 12:46:16 sure Jul 11 12:46:30 or add your task Jul 11 12:46:40 Stygia: if you run devshell, you should be able to at least tell what directory it is changing to; that might give you a clue to what the problem is Jul 11 12:48:22 tf, HMm, I get 'No valid terminal found'. But I have not used the devshell before. Jul 11 12:49:03 Stygia: I'd say that actually linux-yocto does indeed use '+git' Jul 11 12:49:16 there is a variable in the local.conf, you can choose the terminal Jul 11 12:49:24 ant_work, In an ${S} context? Jul 11 12:49:29 tf, Awesome, will have a look. Jul 11 12:51:27 Stygia: you'd show us the recipe name and the SRC_URI at least Jul 11 12:51:32 Stygia: + should not be a problem, you get packages like gtk with + in name Jul 11 12:53:47 ant_work, Yup, sorry, was trying a workaround without luck. This is it: http://pastebin.com/r3TaJUw9 Jul 11 12:53:51 tf, Hmm. Strange. Jul 11 12:53:51 Stygia: you are not forgetting the workdir, right, like S = "${WORKDIR}/Text-Tabs+Wrap-${PN}" Jul 11 12:54:30 tf, No, it is actually exactly S ="${WORKDIR]/Text-Tabs+Wrap-${PN}" Jul 11 12:55:00 PN is probably not right Jul 11 12:55:23 tf, PV, sorry. Jul 11 12:55:24 but you have PV Jul 11 12:55:27 tf, Yup. Jul 11 12:55:28 huh, I am having tmux issues with poky 1.4 :) Jul 11 12:57:10 tf, Can I use wildcards? Like Text-Tabs.*-${PN}? Jul 11 12:57:11 Stygia: what's the recipe name? Jul 11 12:57:28 Stygia: no, it's an argument for cd Jul 11 12:57:31 tf, cpan-text-wrap_2013.0532.bb Jul 11 12:57:42 tf, Pity. Jul 11 12:57:49 tf, And well... cpan-text-wrap really. Jul 11 12:57:53 tf, But the bb file is that. Jul 11 12:58:07 tf, And yes that is Text::Wrap in case you're wondering. Jul 11 12:58:48 Stygia: can you run devshell? Jul 11 12:59:04 tf, Not immediately, haven't found the configuration option to enable it yet. :/ Jul 11 13:00:33 well, if you examine tmp/work//cpan-text-wrap, there will the directory with your unpacked source, and likely another one, with a similar name but mostly empty that will be the S dir it;s trying to use Jul 11 13:00:53 Stygia: anyway default is S = "${WORKDIR}/${BP}" Jul 11 13:01:40 and BP = "${BPN}-${PV}" Jul 11 13:02:36 ant_work, BNP? Jul 11 13:03:12 base package name defiend in conf/bitbake.conf Jul 11 13:03:41 ant_work, Dear fuck... Jul 11 13:03:46 tf, And you too. Jul 11 13:03:49 Sorry, I wasted everybody's time. Jul 11 13:04:03 The recipe name is 2013.05__32__ Jul 11 13:04:11 the file name is 2013.05.__23__ Jul 11 13:04:42 Obviously this is whats wrong... Jul 11 13:04:49 Thank you for your assistance. Sorry for wasting your time. Jul 11 13:05:10 np Jul 11 13:05:49 Stygia: just so you know, PN is the full package name, i.e. foo, foo-native, or lib32-foo. BPN is the "base" without any suffixes or prefixes, so just foo. Jul 11 13:06:09 rburton_, Thank you, duly noted. Jul 11 13:06:24 suddenly becomes important with multilib and automatic-native where you don't want to do anything with the full package name Jul 11 13:06:34 Stygia: remember this pitfall once you write a recipe wich extends to -native ;) Jul 11 13:06:38 rburton_, And heh, FYI, it's more like 85-ish CPAN recipes I'll be releasing once I finished than the 30-ish of last time we spoke. Jul 11 13:06:50 nice :) Jul 11 13:07:12 sounds like a substantial amount of meta-cpan is done then! Jul 11 13:07:15 rburton_, Yea for the community maybe. :P I've spend waay too long getting this one, simple script to run. I'm going crazy. Jul 11 13:07:20 rburton_, Yes... yes it does. ^_^ Jul 11 13:07:50 rburton_, I just like to complain, it's okay, at least nobody will have to do this again. Jul 11 13:07:57 rburton_, Pity so many of these are under GPL though. Jul 11 13:08:03 afaik the biggest users of perl/cpan modules are spam filters Jul 11 13:09:29 ant_work, Seems likely. We're using it for, hmm, well updating of our embedded system. Jul 11 13:09:38 ant_work, And all the movies/music/etc shipped with it. Jul 11 13:09:56 ant_work, I only wanted like 10 modules... but the dependency three just kept growing. :P Jul 11 13:10:46 Stygia: btw, our convention for perl stuff is perl-* rather than cpan-*... this matches what distributions do as well Jul 11 13:10:58 bluelightning, I... I did notice when I was a good way into it. Jul 11 13:11:07 Stygia: really appreciate your perseverence on this set though, great work Jul 11 13:11:12 bluelightning, I'm gonna worry about that once I have a workable ship, then I'll actually rename them and push it in. Jul 11 13:11:20 great :) Jul 11 13:11:25 bluelightning, Hehe, thanks, but it's not like I have a choice. :P Am getting paid to make these modules. Jul 11 13:11:36 bluelightning, Fortunately I have permission to open-source them so I feel less defeated doing this. Jul 11 13:11:59 Stygia: much appreciated Jul 11 13:14:27 rburton_, Eh no problem, the work has to be done, may as well save others from repeating it. Jul 11 13:14:49 Stygia: check out the Gentoo's ebuilds - generator Jul 11 13:18:50 we should probably try to extend create-recipe Jul 11 13:19:00 not a lot of work has been done on it since it was introduced Jul 11 13:19:06 rburton_: I'm digging into terminal.py Jul 11 13:19:16 there seems to be problem with command parsing and feeding it into Popen Jul 11 13:19:42 does anyone have a time to assist me? :) Jul 11 13:25:47 bluelightning, Actually, are you a maintainer on OE/perl-related things? I need to file some serious bugs for the perl recipe Jul 11 13:26:38 Stygia: I do do work on some of the core classes/recipes but haven't touched perl itself much Jul 11 13:26:53 Stygia: bug reports are welcome though if you have found issues Jul 11 13:26:57 pretty sure nobody will admit touching the perl recipe ;) Jul 11 13:26:57 bluelightning, Hmm alright. A number of crucial, perl core files, such as build-in PM's and SO's are missing. Jul 11 13:27:21 bluelightning, Hmm I'll file one, I made a .bbappend just to get perl to actually run. I'm surprised this perl was capable of anything. Jul 11 13:28:05 Stygia: hmm, not good if it's that broken; I have certainly used it on the target in conjunction with webmin FWIW Jul 11 13:28:16 perhaps that doesn't exercise the same things, not sure Jul 11 13:28:25 bluelightning, Well yes I would expect it works with your existing packages. But it was strange - Some of the more core files were missing. Jul 11 13:28:53 Stygia, strict.pm, warnings.pm, base.pm... even ut8.pm, vars.pm and POSIX.pm Jul 11 13:31:12 hmm, webmin does depend on perl-module-strict Jul 11 13:31:14 brb Jul 11 13:31:43 afternoon all Jul 11 13:31:51 And hmm, now that I have you guys here, another issue. I get the "Files/directories were installed but not shipped" error, with the files I am doing this to: http://pastebin.com/8xb11AvF And yet I get complains about /usr/share/perl/MovisLog.pm - Shouldn't adding it under ${D} do the trick? Jul 11 13:32:34 The weird part is movisdaemon.pl and movis.conf and installed, in this block, and no complaints are generated. Jul 11 13:34:06 Am I supposed to "install" the directory itself? (/usr/share/perl) Or do anything other than create it under D? Jul 11 13:35:33 Stygia: typically you would create it in do_install using install -d yes Jul 11 13:35:46 I've got a bbappend where I've added some things via "IMAGE_INSTALL +=" - however I'd like to remove something the original .bb had in IMAGE_INSTALL - is there an easy way to do that? Jul 11 13:36:02 pev: you can use oe_filter_out() Jul 11 13:36:06 bluelightning, Hmm, so with install -d instead of mkdir. I'll try. Jul 11 13:36:40 pev: however for image recipes to be honest I think the easiest thing is not to append them, just copy them Jul 11 13:40:12 bluelightning_ : Thanks I'll give copying a go again - tried yesterday and failed so prob worth having another bash! Jul 11 13:42:24 is there a doc / guide on how to handle recipes for packages that need to build and run build-time helpers on the host? Jul 11 13:44:33 thaytan: I don't know if we have any specific docs on that Jul 11 13:44:48 thaytan: typically we try to build the native parts in a separate recipe Jul 11 13:45:05 thaytan: e.g. we have qt4-native to build qmake and co for building qt Jul 11 13:45:18 thaytan, bluelightning_: apart from recipes that just need a small tool internally built Jul 11 13:45:22 ie mesa Jul 11 13:45:29 where you can build just that using the native compiler Jul 11 13:46:16 thaytan: have a look at mesa, they upstreamed their "i'm cross compiling but have tools to build" support Jul 11 13:46:26 or you can try to use the extend mechanism, if the package is not outright evil Jul 11 13:46:57 bluelightning_: rburton_: ta Jul 11 13:53:56 I want to set up a cross development system using bitbake, and as we are using Qt we need Qt to work under cross compilation. I thought bitbake could generate such a thing, or am I completely wrong? Jul 11 13:54:15 Hm, randmom question again - If you list all recipes in use via bitbake -s, is there an easy way to get the licence for each as well? Jul 11 13:55:25 thaytan: i've made various packages work that need native tools so feel free to ping me Jul 11 13:55:26 fenrig: certainly, that is something we provide out of the box Jul 11 13:56:08 bluelightning_: http://www.yoctoproject.org/docs/current/adt-manual/adt-manual.html#adt-intro-section I'm nog reading this document, but it doesn't seem to do what I want (cross compile Qt programs) Jul 11 13:56:21 but maybe ADT is something else? Jul 11 13:56:43 the ADT gives you a cross compiler and libraries you want Jul 11 13:56:48 so that's what you want Jul 11 13:57:48 oh okay :o I just tried generating a ADT, and it's 700 kb big :o enough for a cross compiler but I don't think it's enough :o Jul 11 13:58:12 now I did only do " MACHINE="beaglebone" bitbake adt-installer " Jul 11 13:58:22 yeah you probably want more than that Jul 11 13:58:28 do you have an image? Jul 11 13:58:38 because you can do bitbake [myimage] -c populate_sdk Jul 11 13:58:54 and it will make you a SDK that contains all the libs etc from your image Jul 11 13:59:32 rburton_: that's what I'm looking, yes I did produce my own image Jul 11 14:02:26 rburton_: should I carry on reading the adt_manual? or is the sdk generation documentation to be found somewhere else? Jul 11 14:03:11 fenrig: rapidly reaching the edge of my knowledge here, but i think the adt and the "sdk" are mostly the same. Jul 11 14:03:50 rburton_: Oh okay, it doesn't seem so clear :o as the populate_sdk is only to be found in a "note" in the document Jul 11 14:04:34 fenrig: hmpf. i'll prod our docs guy :) Jul 11 14:05:38 rburton_: hahaha :D still thx for the help :) Jul 11 14:05:45 rburton_: I appreciate it ;) Jul 11 14:06:03 bluelightning_: thx for your help ;) Jul 11 14:07:12 fenrig: for what it's worth, any mention of meta-toolchain should be considered as deprecated. populate_sdk is the way to get a fully-featured sdk. Jul 11 14:07:47 rburton_: will keep that in mind, but I don't think I have read anything about meta-toolchain. Jul 11 14:08:07 meta-toolchain is deprecated? =o Jul 11 14:08:08 fenrig: good :) Jul 11 14:08:37 RagBal: sort of. maybe meta-toolchain itself will stay, but e.g. meta-toolchain-gmae is going away Jul 11 14:09:15 RagBal: meta-toolchain is fine, it's just people often want to extend it to include libraries to match what goes into their images, and that is a bit hard Jul 11 14:09:46 Hmm Jul 11 14:09:46 RagBal: the much better alternative is bitbake -c populate_sdk imagename, which will give you an SDK that exactly matches the image Jul 11 14:09:57 * RagBal makes a mental note about populate_sdk task Jul 11 14:10:33 we do need to document it a bit better although I think the current docs do at least mention it in passing Jul 11 14:10:33 oh yeah on another note: I tried including directfb in the BBB Jul 11 14:10:59 and when bitbake did a do_configure on Qt it failed, something about missing opengl :) Jul 11 14:11:46 now I think opengl (es) support is machine dependent and so is implemented in the machine layer? Jul 11 14:12:13 correct me if I'm wrong :D cause I can be terribly wrong sometimes XD Jul 11 14:12:20 qt should be respecting the opengl distro feature and disabling it Jul 11 14:12:59 rburton_: It did not :/ now when using X11 I don't get these issues Jul 11 14:14:51 QT_GLFLAGS gets set based upon whether opengl is in DISTRO_FEATURES except for qemux86 and qemuppc which force it on Jul 11 14:15:22 (to be honest I don't know why we do the latter, I wonder if it is a holdover from the days when we had passthrough GL support hacked into qemu) Jul 11 14:15:47 hm, yeah, we should remove that Jul 11 14:16:08 i found tizen's qemu GL code... it's a fork of qemu 1.2. Jul 11 14:16:19 yeah I saw your link Jul 11 14:17:06 so this is a yocto issue or has it to do with directfb? Jul 11 14:17:41 fenrig: possibly the gl support actually means glx, so it needs X? Jul 11 14:17:46 what was the actual error? Jul 11 14:18:20 “ fatal error: GLES2/gl2.h: No such file or directory " Jul 11 14:18:41 I'll post the log via gist Jul 11 14:18:54 fenrig: so does your DISTRO_FEATURES contain opengl ? Jul 11 14:19:23 bluelightning_: No I don't think so Jul 11 14:19:38 let me check Jul 11 14:20:47 fenrig: you're building qt4-embedded right? Jul 11 14:21:14 https://gist.github.com/fenrig/5975871 Jul 11 14:21:19 no i'm building qt5 Jul 11 14:21:22 meta-qt5 Jul 11 14:21:27 using qtbase in image_install Jul 11 14:21:39 oh, qt5 Jul 11 14:21:50 I've not done much with that yet Jul 11 14:22:06 fenrig: speak to JaMa Jul 11 14:23:06 I've commentend in the gist https://gist.github.com/fenrig/5975871 Jul 11 14:23:10 about the distro features Jul 11 14:23:14 fenrig: default is to build against mesa, did you change that default? Jul 11 14:23:16 I understand that it is not enabled :) Jul 11 14:23:26 I did not change anything default :o Jul 11 14:23:49 I only changed in angstrom.inc the distro_features from x11 to directfb :) Jul 11 14:26:03 fenrig: it builds fine here with defaults, can you pastebin config.log from that build? Jul 11 14:27:19 JaMa: where can I find this ? Jul 11 14:32:37 JaMa: I probably have to rerun the build, cause I've changed to X11 again after that :/ Jul 11 14:33:57 and at this moment I'm running the populate_sdk thing for the first time :/ Jul 11 14:34:14 fenrig: it should be in ${S}/build directory Jul 11 14:35:22 JaMa: nothing in my build dir, but I'm using the angstrom spinoff of yocto :/ maybe that's a part of the problem? Jul 11 14:36:05 try to search whole $S maybe I don't remember the name correctly Jul 11 14:36:46 Okay I get multiple results :o Jul 11 14:37:53 is one of them in config.tests/unix/opengles2? :) Jul 11 14:38:23 or better config.tests/unix/opengldesktop Jul 11 14:39:24 maybe start with "bitbake -e | grep ^PREFERRED_PROVIDER_virtual/libgl Jul 11 14:39:59 JaMa: Okay, but I'm building something at the moment, it'll take some min but I'm almost there :p Jul 11 14:46:03 JaMa: find | grep config.log | grep opengl didn't return anything :/ Jul 11 14:46:34 JaMa: I'll try the bitbake method when my populate_sdk is done (70 tasks remaining on my i7) Jul 11 14:49:56 JaMa: do I have to configure my settings back to when I tried directfb? Jul 11 14:50:16 JaMa: it probably would, wouldn't it? Jul 11 14:50:59 otavio: you around? Jul 11 14:52:01 sgw_: sure Jul 11 14:52:02 :) Jul 11 14:52:36 otavio: any progress on bug #4510 Jul 11 14:52:38 Bug https://bugzilla.yoctoproject.org/show_bug.cgi?id=4510 critical, High, 1.5 M2, otavio, NEW , GLX load vivante_dri.so failed Jul 11 14:52:45 sgw_: yes Jul 11 14:52:53 sgw_: but I cannot disclose it yet Jul 11 14:53:26 Can you at least update the bug and mark it in progress? Jul 11 14:53:36 sgw_: not yet, sorry Jul 11 14:53:47 sgw_: but will be soon ;) Jul 11 14:54:34 otavio: just changing the status to in progress instead of new would be good :) Jul 11 14:55:07 rburton_: I should have said 'no progress' but I'd be lieing Jul 11 14:55:16 ha Jul 11 14:55:21 we're friends, you can tell us :) Jul 11 14:55:26 otavio: ok, change it to accepted :) Jul 11 14:55:38 rburton_: NDA is not friendly ;) Jul 11 14:58:49 fenrig: yes Jul 11 14:59:34 JaMa: the last 20 packages, sorry that I have to make you wait :) Jul 11 15:11:59 JaMa: I'm having some problems with the SDK, can I contact you tomorrow? Jul 11 16:20:00 Is there any documented information about how to create crash kernel implementation in yocto project? Jul 11 16:20:28 Has anybody done this Jul 11 16:20:29 ? Jul 11 16:27:39 ok different question Jul 11 16:28:10 Can somebody explain how to replace pr / pn ... in recipes with AUTOREV Jul 11 16:29:24 grep for SRCPV Jul 11 16:31:08 ok Jul 11 16:33:41 Where does value for SRCREV come from? Jul 11 16:35:17 fin_: if fetching from a git/svn/etc. repository it needs to be set by the recipe Jul 11 16:35:39 (to either a fixed revision/tag/etc. or ${AUTOREV}) Jul 11 16:36:36 Where do I obtain the value..if its from a git Jul 11 16:36:47 repo Jul 11 16:36:58 the value is the git commit hash. if you dont know how to get that from a git repo, read Pro Git :) Jul 11 16:37:29 ok so if I use AUTOREV then it will just take the latest version? Jul 11 16:37:51 fin_: yes, if you do SRCREV = "${AUTOREV}" Jul 11 16:41:11 What if I dont set that atall? What is the point in setting this? Jul 11 16:41:55 it's not going to read your mind to figure out what branch/tag/commit to check out Jul 11 16:42:13 fin_: I think you get an error if it's not set at all Jul 11 16:42:14 if you want it to track the tip of a branch, that's what setting it to AUTOREV does Jul 11 16:42:39 In the src_uri I have the git link and branch. and that works Jul 11 16:43:07 fin_: you may find it does not rebuild automatically when the tip moves without AUTOREV Jul 11 16:45:31 Should I still set this SRCREV = "${AUTOREV}" Jul 11 16:45:50 even if I specify git repo and branch in SRC_URI¨ Jul 11 16:46:25 The git repo is constantly been updated so I just need the latest version from the branch Jul 11 16:46:32 again, thats what autorev is *for* Jul 11 16:46:43 if you want to it to track the tip of a branch reliably, then set SRCREV to AUTOREV Jul 11 16:47:13 ok, understand Jul 11 16:47:49 Correct me if I'm wrong, but Yocto is supposed to be a replacement firmwar, right? Jul 11 16:48:03 firmware Jul 11 16:48:48 Umeaboy: not really, we provide the means to build custom "firmware" if "firmware" = the os that runs on a device Jul 11 16:50:18 bluelightning: OK, how can I add support for my TV then? I have bootloader-access. Jul 11 16:50:37 It's Titania-based. Jul 11 16:50:49 mstar# Jul 11 16:50:59 Umeaboy: you'd need to create a BSP layer containing a kernel and any other things required to boot/run on the device Jul 11 16:51:29 bluelightning: I'm already running LGMOD on it. Jul 11 16:51:36 It's a wrapper. Jul 11 16:54:02 hi, I guess it is possible to replace the old u-boot version in Yocto with the version we want to have? Jul 11 16:54:06 like writing a new recipe? Jul 11 16:54:56 lpapp: absolutely Jul 11 16:55:01 lpapp: Sure. "Anything is possible"....... said by a known skier here in Sweden. Jul 11 16:55:04 lpapp: in fact a lot of BSPs do that Jul 11 16:55:31 I have to go. I'll be back in 4 to 5 hrs. Jul 11 16:56:40 lpapp: if you make it a git recipe you can have it pull from your own u-boot repo Jul 11 16:57:04 k, ty. Jul 11 16:57:15 I was wondering if there is any difficulty about it to pay attention to. Jul 11 16:57:45 also, is there anyone working on the libdir issue? Jul 11 16:57:58 nothing in particular, but you might check some of the existing recipes Jul 11 16:59:24 we have a couple of different (local) u-boot git recipes, one for core u-boot, one for tools, and one for the SD bootloader files Jul 11 16:59:50 /home/lpapp/Projects/poky/meta/files/common-licenses/* could not be copied for some reason. It may not exist. WARN for now. Jul 11 17:00:00 is this due to the libdir issue? Jul 11 17:00:16 no idea, haven't seen that one... Jul 11 17:00:49 not sure what you mean by "the libdir issue" Jul 11 17:01:03 lpapp: does the error actually say "*"? Jul 11 17:03:41 rburton_: no, it actually says all the license files. Jul 11 17:03:47 did not wanna paste them all Jul 11 17:03:58 lpapp: do they exist? Jul 11 17:04:18 rburton_: yes Jul 11 17:04:29 how interesting. file a bug? never seen that. Jul 11 17:09:07 justed added the slides from a talk at ELC entitled 'Yocto Meta-Virtualization Project' if anyone is interested: http://elinux.org/images/9/9b/Elc2013_Christofferson.pdf Jul 11 17:12:29 looks interesting Jul 11 17:31:54 rburton_: 'accepted' the bug ;-) Jul 11 18:39:17 Hmm, I don't think PKG is always being properly considered to satisfy RDEPENDS for runqueue generation Jul 11 18:45:36 There is some weird stuff in there. Jul 11 18:45:52 does any one know why debug-tweaks IMAGE_FEATURE is not working? Jul 11 18:46:17 i saw and the actual function to replace the sshd_conf is been called, but for some reason the file is empty so sed doesn't replace anything Jul 11 18:46:28 I'm using openssh recipes from dylan Jul 11 18:46:45 There is some extra-special magic with RDEPENDS and multlibs, as I recall. I think I once came up with a test case where I would get either 32-bit or 64-bit of some package, but which one was dependent on ordering of other things in a way that made it effectively non-deterministic. Jul 11 18:46:54 the only difference from before(which was working) is that I added pulseaudio DISTRO_FEATURE Jul 11 18:47:16 ftonello: not sure, but I could do a local check, this is with dylan? Jul 11 18:47:28 sgw_: yes Jul 11 18:48:43 is that possible to create an SDK from yocto? Jul 11 18:52:06 tinti_: yes, you can get a sdk for the image you build by using the populate_sdk task (bitbake -c populate_sdk core-image-sato) or by building the meta-toolchain target which will give you a toolchain Jul 11 18:53:01 sgw_: but for example can I make it build libboost too? I a cortex-a8? Jul 11 18:53:06 In a* Jul 11 18:53:11 ftonello: unfortunately my dylna build was stale and more stuff is building Jul 11 18:54:43 tinti_: eitehr you can create an iamge recipe that includes it and use populate_sdk, or you can add to the variables used to control what packages go into the sdk Jul 11 18:54:54 tinti_: if you have an image in your distro's layer (if you are not using the core poky images) the populate_sdk task will match exactly that image, I think you might be able to do it with CORE_IMAGE_EXTRA_INSTALL_appends = " boost" Jul 11 18:55:04 kergoth`: timing Jul 11 18:56:05 got it, I will try to read a bit more about it Jul 11 18:58:18 Hi I am trying to understand the sstate stuff. I read the documentaton and it give deploy.bbclass as a example Jul 11 18:58:55 Can somebody explain the lines in that file? Jul 11 19:00:33 is it just copying files from deploydir to deploydirimage Jul 11 19:06:44 sgw_: ok.. thanks anyway Jul 11 19:19:45 * sgw_ thinks he tracked down the boost issue to eglibc updated!! Jul 11 19:19:57 boost uses the __GLIBC_HAVE_LONG_LONG and Jul 11 19:19:59 ../../../eglibc/2.18-r0/eglibc-2.18/libc/ChangeLog: * include/features.h (__GLIBC_HAVE_LONG_LONG): Remove. Jul 11 19:59:07 ftonello: still around, a local build completed and I do have a "correct" sshd_config with root allowed. Jul 11 20:00:10 sgw1: do you have pulseaudio DISTRO_FEATURE? Jul 11 20:06:57 ftonello: just verified with bitbake -e, yes and I added it to my image to be sure Jul 11 20:14:40 sgw1: any ideas how to debug this? Jul 11 20:15:02 because as I told, the function is been called, is just that the conf file in the openssh installation is empty Jul 11 20:15:05 :/ Jul 11 20:15:31 I will try to cleanall the openssh recipe.. it was working before.. its really weird Jul 11 20:22:34 ftonello: yeah, mine is not empty. Jul 11 21:34:07 wmat: thanks for that link... Jul 11 21:57:12 Any dev around to assist me with adding support for my TV in Yocto? Jul 11 21:57:25 I'll do the job if someone guides me. Jul 11 21:57:43 It is modified with a wrapper called LGMOD. Jul 11 21:58:08 The board is Titania-based with mstar as bootloader. Jul 11 21:58:14 MIPSEL. **** ENDING LOGGING AT Fri Jul 12 02:59:58 2013