**** BEGIN LOGGING AT Wed Jul 15 02:59:58 2015
Jul 15 06:18:17 <miandonmenmian> is it possible to create meta packages for yocto? as in a package that just installs other packages? but is not a software/package it self?
Jul 15 06:18:49 <dvhart> miandonmenmian there are package groups
Jul 15 06:18:57 <dvhart> might be what you're looking for
Jul 15 06:19:36 <miandonmenmian> dvhart: sounds right, where do i look for more info about it? is it related to opkg? or just a recipe on yocto ?
Jul 15 06:19:58 <dvhart> should be information in the reference manual
Jul 15 06:20:40 <dvhart> http://www.yoctoproject.org/docs/1.8/dev-manual/dev-manual.html#usingpoky-extend-customimage-customtasks
Jul 15 06:20:44 <dvhart> try that
Jul 15 06:24:28 <miandonmenmian> dvhart: thanks! that's it
Jul 15 06:24:39 <dvhart> welcome :)
Jul 15 06:59:13 <mckoan> good morning
Jul 15 07:17:58 <Ox4> hello
Jul 15 07:18:17 <Ox4> it's me again
Jul 15 07:20:14 <Ox4> I have the following module bb file http://dpaste.com/3FN8ZDC, but when the image is built, I don't see my modules in the lib filders
Jul 15 07:20:19 <Ox4> what's wrong?
Jul 15 07:56:53 <Ox4> and the second question: WARNING: QA Issue: /usr/bin/locale_glibc-external-utils contained in package glibc-external-utils requires libgcc_s.so.1, but no providers found in its RDEPENDS [file-rdeps]
Jul 15 07:57:04 <Ox4> what does it mean? ^^^
Jul 15 08:02:00 <sm0ketst> morning all
Jul 15 08:18:28 <Ox4> bluelightning: hey, I waited for you :)
Jul 15 08:19:33 <Ox4> bluelightning: WARNING: QA Issue:
Jul 15 08:19:33 <Ox4>       /usr/bin/locale_glibc-external-utils contained in package
Jul 15 08:19:33 <Ox4>       glibc-external-utils requires libgcc_s.so.1, but no providers found in
Jul 15 08:19:33 <Ox4>       its RDEPENDS [file-rdeps]
Jul 15 08:19:38 <Ox4> oops
Jul 15 08:19:44 <bluelightning> morning all
Jul 15 08:20:34 <bluelightning> Ox4: http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#qa-issue-file-rdeps
Jul 15 08:22:10 <sm0ketst> morning bluelightning
Jul 15 08:22:26 <Ox4> bluelightning: ok, another quiestion
Jul 15 08:22:47 <Ox4> bluelightning: I have the following module bb file http://dpaste.com/3FN8ZDC
Jul 15 08:22:57 <Ox4> but I don't see my modules in the lib filder
Jul 15 08:43:05 <bboozzoo> is there a tool that I can use to quickly deploy contents of ${D} to a target host? something line devtool's deploy-target
Jul 15 08:49:34 <bluelightning> bboozzoo: devtool deploy-target is basically what we have for that
Jul 15 08:50:44 <bboozzoo> bluelightning: but that does not work with out-of-workspace recipes right?
Jul 15 08:58:02 <bluelightning> bboozzoo: no, but adding a recipe to the workspace is trivial, just do devtool modify recipename
Jul 15 08:58:24 <bluelightning> (which doesn't actually move or even touch the recipe itself, in case that's not clear)
Jul 15 09:07:31 <bboozzoo> seems like itl'll do :)
Jul 15 09:09:22 <Ox4> where the IMAGE_LINGUAS and GLIBC_GENERATE_LOCALES variable should be located?
Jul 15 09:09:23 <bboozzoo> bluelightning: btw. devtool is really nice, cograts on making the yocto experience much better
Jul 15 09:09:30 <Ox4> build/conf/local.conf?
Jul 15 09:15:06 <bluelightning> bboozzoo: thanks, if you think of any improvements, please let us know :)
Jul 15 09:15:35 <bluelightning> Ox4: you can set them from local.conf, but long term you should be thinking about creating your own custom distro config and setting it from there
Jul 15 09:15:44 <bluelightning> Ox4: there's a section of the manual on creating your own distro
Jul 15 09:16:03 <mansandersson> morning all. Is it possible to use psplash withot fbcon activated in kernel?
Jul 15 09:16:14 <mansandersson> mine stopped working when I disabled fbcon.
Jul 15 09:16:15 <mansandersson> thanks.
Jul 15 09:23:09 <bboozzoo> Ox4: for example meta-ivi sets it in ivi-image https://git.yoctoproject.org/cgit/cgit.cgi/meta-ivi/tree/meta-ivi/recipes-yocto-ivi/images/ivi-image.inc
Jul 15 09:24:19 <bluelightning> right, IMAGE_LINGUAS can (and probably should) be set from a custom image recipe
Jul 15 09:24:28 <bluelightning> GLIBC_GENERATE_LOCALES cannot be though
Jul 15 09:28:27 <Ox4> thank you guys
Jul 15 09:30:08 <Ox4> could somebody support me with meta-sourcery?
Jul 15 09:36:32 <Ox4> http://dpaste.com/1KCTSJW.txt omg :-(
Jul 15 09:37:03 <bluelightning> not me, I always use our built-from-source toolchain
Jul 15 09:38:43 <bluelightning> mansandersson: I don't believe so
Jul 15 09:38:59 <bluelightning> mansandersson: if you look at psplash's code it's pretty trivial, there's not much in the way of output options built in
Jul 15 09:42:29 <mansandersson> bluelightning: I'm looking at it right now and it seems to me that it wants a raw access to the fb device. If that's true it should work from my understanding (got a lot to read up on regarding fb though)
Jul 15 09:43:08 <bluelightning> mansandersson: you're at the limit of my knowledge as well I'm afraid
Jul 15 09:45:20 <mansandersson> bluelightning: I'll just continue my search then. Thanks anyway
Jul 15 09:55:49 <Ox4> hm, I don't see modules which should be built :-(
Jul 15 10:11:50 <ftonello> other toolchains should work in theory, but they are always a pain in the neck.
Jul 15 11:06:26 <JaMa> bitbake no longer prints content of log.* files for failed tasks by default? was that intentional change?
Jul 15 11:18:45 <bluelightning> JaMa: no, bugfix is on the list
Jul 15 11:18:49 <bluelightning> my fault :/
Jul 15 11:19:04 <bluelightning> I hope it should get merged soon
Jul 15 11:19:52 <bluelightning> I'll have a couple of follow-up fixes for bbfatal usage in meta-oe as well
Jul 15 11:21:16 <JaMa> ok, thanks for info
Jul 15 12:59:52 <HyP3r> Hey all, I'm building with the yocto poky (dizzy) project a small linux for my beagle bone black.
Jul 15 13:00:10 <HyP3r> Its working fine with dylan and the meta-beaglebone layer and also with dizzy without this layer.
Jul 15 13:00:42 <HyP3r> My simple question is how can I configure yocto that way it compiles me another kernel version?
Jul 15 13:02:39 <HyP3r> At the moment I get 3.8.13 with my dylan project and with fido I get 3.14.36.
Jul 15 13:07:18 <bluelightning> HyP3r: kernel is selected through PREFERRED_PROVIDER_virtual/kernel = "<recipename>" (and also PREFERRED_VERSION_<recipename> = "<version>" )
Jul 15 13:08:32 <bluelightning> you'd need to add a recipe providing the version of the kernel you want to be built, and set those to point to it (if there's only one version of that <recipename> then you don't need to set PREFERRED_VERSION_<recipename> though)
Jul 15 13:09:38 <HyP3r> bluelightning: ugh that sounds complicated
Jul 15 13:10:50 <bluelightning> it's not really ;)
Jul 15 13:12:31 <HyP3r> In first step I grepped: meta-yocto-bsp/conf/machine/beaglebone.conf:PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto"
Jul 15 13:12:52 <HyP3r> And now?
Jul 15 13:13:06 <mansandersson> HyP3r: many recipes has include files (.inc) that does all the hard work and you only have to provide the git repo and sha.
Jul 15 13:13:57 <HyP3r> In this file meta-yocto-bsp/conf/machine/beaglebone.conf  under this line is: PREFERRED_VERSION_linux-yocto ?= "3.14%"
Jul 15 13:14:03 <HyP3r> Would I work if I change that line?
Jul 15 13:14:50 <mansandersson> yes, as long as you have a recipe for that version (look in recipes-kernel/linux)
Jul 15 13:15:23 <HyP3r> I only have 3.14 and 3.19
Jul 15 13:15:58 <HyP3r> So in that way I have to create a new recipe?
Jul 15 13:17:19 <mansandersson> yes, if you'd like to build something else than 3.14 or 3.19
Jul 15 13:18:42 <mansandersson> if all you want is to make changes to the kernel configuration you can also try "bitbake -c menuconfig virtual/kernel"
Jul 15 13:19:14 <bluelightning> HyP3r: normally you wouldn't edit that file, you would set the value elsewhere in your configuration
Jul 15 13:21:06 <HyP3r> bluelightning: how can I find out which file is included? Where I can set the config?
Jul 15 13:22:05 <HyP3r> But I think to create a new kernel recipie is not a bad Idea beacause there is git-fork for the beaglebone black
Jul 15 13:22:18 <HyP3r> Which is Including the beagle bone black specific functions
Jul 15 13:22:29 <bluelightning> HyP3r: for testing you can set it in conf/local.conf under your build directory
Jul 15 13:22:40 <HyP3r> https://github.com/beagleboard/linux
Jul 15 13:22:50 <bluelightning> HyP3r: bitbake -e | less is a good way to explore how variables get set (and what config files are read)
Jul 15 13:26:07 <HyP3r> bluelightning: thank you
Jul 15 14:26:22 <joshuagl> dvhart: around? just wondering what's the right way to refresh my memory on the -tiny effort?
Jul 15 14:29:00 <ericbutters> hi.. is it possible to create a rpm/ipk containing packages that should not be included in image? i mean one ikp containing all packages to install manually?
Jul 15 14:30:10 <bluelightning> ericbutters: er, do you mean a packagegroup perhaps ?
Jul 15 14:31:24 <ericbutters> bluelightning: yes some kind of that.. i created a packagegroup, but this builds all packages and i can find them seperately in tmp/deploy/ipk .. but i want to have all of them in one ikp
Jul 15 14:31:30 <ericbutters> ipk i meant
Jul 15 14:31:50 <bluelightning> well, we have no mechanism to create a megapackage from individual packages, no
Jul 15 14:32:27 <rburton> ericbutters: you *could* have a recipe that depends on the deploy of your set of packages, and creates the megapackage and deploys that
Jul 15 14:33:04 <ericbutters> rburton: how to do this?
Jul 15 14:33:06 <ericbutters> sry
Jul 15 14:34:47 <rburton> i imagine something like do_unpack['depends'] += "some-package:do_deploy another-package:do_deploy" would work
Jul 15 14:35:16 <rburton> that means you'll only get past unpack once those packages have deployed themselves as binary packages
Jul 15 14:35:39 <ericbutters> ah
Jul 15 14:35:41 <kergoth> then you'd have to map the dependency to the exact binary package filename..
Jul 15 14:35:41 <ericbutters> okay i try
Jul 15 14:35:43 <kergoth> names, that is
Jul 15 14:35:45 <rburton> then write a do_install to unpack all of the packages to $D together, and re-package them
Jul 15 14:35:48 * kergoth yawns, morning all
Jul 15 14:35:54 <rburton> kergoth: yeah, and that
Jul 15 14:36:12 <rburton> (totally not saying this is a good idea)
Jul 15 14:36:23 <rburton> i dare not ask why :)
Jul 15 14:36:39 <kergoth> my guess would be he wants to install something with a lot of deps bu tdoesn't have a feed set up
Jul 15 14:37:17 <kergoth> the right answer to that is, set up a feed, even a temporary one, i think.. or write a standalone tool which copies a package and its deps from a feed to a target path (e.g. sd card or usb stick)
Jul 15 14:37:18 * kergoth shrugs
Jul 15 14:38:58 <ericbutters> kergoth: i never used feeds, can feeds be on a usb stick? how to create feeds?
Jul 15 14:39:40 <kergoth> yes, you could put a package feed on a usb stick. it depends on the package manager, they each have an appropriate tool for creating a feed / updating the feed metadata from the packages in it
Jul 15 14:40:57 <ericbutters> i find all packages in tmp/deploy/ipk .. so how to create a feed from that with packages i want to provide?
Jul 15 15:37:38 <JaMa> bluelightning: do I need some oe-core patch together with this one? http://patchwork.openembedded.org/patch/97489/
Jul 15 15:38:10 <JaMa> http://patchwork.openembedded.org/patch/97289/ maybe?
Jul 15 15:39:11 <JaMa> which doesn't apply, because it's already there :)
Jul 15 15:51:08 <bluelightning> JaMa: you should take all of http://patchwork.openembedded.org/patch/97507/ , though strictly only 2/4 and 3/4 are required to make things work properly again
Jul 15 15:53:02 <kergoth> should probably get those messaging fixes in relatively quickly
Jul 15 15:55:39 <kergoth> lovely, yesterday my unit tests were fine, today i'm getting random parse hangs again. gah. i don't know if it's something with these VMs, the machine they're running on, or something bitbake related
Jul 15 15:55:46 <kergoth> :|
Jul 15 15:56:08 <JaMa> bluelightning: trying that now..
Jul 15 15:57:19 <bluelightning> I haven't seen breakage due to the issue fixed by 1/4 but I'd expect there to be some
Jul 15 16:01:10 <kergoth> bluelightning: nice work on the messaging stuff, by the way, that's a feature we've wanted since early days of oe
Jul 15 16:01:43 <bluelightning> kergoth: thanks... I now appreciate why noone got around to implementing it until now ;)
Jul 15 16:01:51 <kergoth> hah :)
Jul 15 16:02:21 <kergoth> i didn't even think about the showing vs not showing the log aspect until i saw your fixes for it. didn't even cross my mind after reading the first patches..
Jul 15 16:03:13 <bluelightning> right, nor me (and I may have written the log suppressing code ...)
Jul 15 16:04:00 <bluelightning> one remaining annoying thing though is that if you Ctrl+C out of the build, the FIFOs get left behind - I guess the worker is being terminated before it has a chance to unlink it
Jul 15 16:05:19 <kergoth> guess the workers need to catch whatever signal the server is sending to shut them down and do some cleanup?
Jul 15 16:05:20 * kergoth shrugs
Jul 15 16:05:47 * kergoth grumbles
Jul 15 16:14:13 <JaMa> bluelightning: thanks worked, now I can see that intltool-native is broken
Jul 15 16:14:15 <JaMa> | checking for perl >= 5.8.1... 5.22.0
Jul 15 16:14:15 <JaMa> | checking for XML::Parser... configure: error: XML::Parser perl module is required for intltool
Jul 15 16:14:18 <JaMa> | Configure failed. The contents of all config.log files follows to aid debugging
Jul 15 16:37:48 <ftonello> How can I remove a REPDENDS package from one recipe but in another recipe, a image recipe for instance?
Jul 15 16:38:32 <ftonello> The  thing is that packagegroup-core-boot.bb installs init-ifupdown package, but I don't want it to install in one image, but it can install in another image.
Jul 15 16:38:51 <ftonello> Since it doesn't use any type of DISTRO_FEATURE or anything, it always install.
Jul 15 16:39:17 <kergoth> can't be done. packagegroup-core-boot emits a binary package, that package is installed in any image you build
Jul 15 16:39:27 <kergoth> one recipe can't alter another recipe's metadata
Jul 15 16:39:43 <kergoth> either do two builds with different cofniguration, or use multiple packagegroups
Jul 15 16:39:58 <ftonello> Ok, thats what I though.
Jul 15 16:40:24 <ftonello> Is there any reason why init-ifupdown package is installed in this packagegroup?
Jul 15 16:40:45 <ftonello> I mean, why not use some network DISTRO_FEATURE to select it?
Jul 15 16:40:59 <kergoth> i don't think networking has ever been optional
Jul 15 16:41:07 <kergoth> you could certainly create such a distro feature, yeah
Jul 15 16:47:30 <ftonello> ok
Jul 15 18:32:06 * kergoth swipes the logging bits from bb.tests.data for selftests
Jul 15 19:20:47 <kergoth> I clearly don't write unit tests often enough, this is taking me much longer than it should
Jul 15 19:20:52 <kergoth> course the random parse hangs don't help, but still
Jul 15 20:06:56 * kergoth finds a number of irritating issues with the bb.fetch.URI class
Jul 15 23:44:38 <rburton> more success!
**** ENDING LOGGING AT Thu Jul 16 02:59:59 2015