**** BEGIN LOGGING AT Mon Jun 17 02:59:58 2013
Jun 17 08:24:42 <bluelightning> morning all
Jun 17 11:57:21 <jonatan> Can I make bitbake produce an ext3 image rather than a compressed root filesystem when building a core-image-minimal?
Jun 17 12:00:54 <bluelightning> jonatan: output image type(s) are controlled by the IMAGE_FSTYPES variable
Jun 17 12:01:11 <bluelightning> jonatan: if you do IMAGE_FSTYPES += "ext3" you'll get an ext3 image
Jun 17 12:02:59 <jonatan> bluelightning, Thanks!
Jun 17 14:37:14 <panda84kde> bluelightning: Hi. Should I post this patch to openembedded-core instead of poky? https://lists.yoctoproject.org/pipermail/yocto/2013-June/016683.html
Jun 17 14:38:42 <bluelightning> panda84kde: yes, patches against the core metadata should be sent to the oe-core mailing list (see README for clarification)
Jun 17 14:38:53 <Crofton|work>  panda84kde it doess look like it shoudl go to oe-core
Jun 17 14:40:42 <panda84kde> bluelightning: Crofton|work: thanks. I was a bit confused at first
Jun 17 15:42:27 <bluelightning> seebs: hi... do you think we can drop the pseudo 1.4.5 recipe from OE-Core?
Jun 17 15:42:44 <seebs> Fine by me. I think the "in case we suddenly have to revert" window is probably over.
Jun 17 15:43:31 <bluelightning> indeed :) upgrade was pretty smooth
Jun 17 15:43:39 <bluelightning> I'll send a patch
Jun 17 17:50:15 <sorvato> hello all.
Jun 17 17:50:38 <sorvato> I've been playing around trying to add a couple dev packages to meta-toolchain-qte, to no avail so far
Jun 17 17:50:46 <sorvato> how should that be done?
Jun 17 17:53:04 <mr_science> in the older oe-classic world i had to add the dev packages to the task-toolchain bb file rather than the meta-toolchain bb file
Jun 17 17:54:22 <mr_science> i inherited it that way so i'm not sure what the rationale was...
Jun 17 17:55:33 <mr_science> the previous guy made custom recipes files for both meta-toolchain-foo.bb and task-foo-toolchain-target.bb
Jun 17 17:56:18 <mr_science> our custom dev package files are listed in the latter recipe
Jun 17 17:59:42 <sorvato> ah, good.
Jun 17 17:59:45 <sorvato> thanks
Jun 17 17:59:59 <sorvato> that gave me a better google search :)
Jun 17 18:00:27 <sorvato> add it to TOOLCHAIN_TARGET_TASK :)
Jun 17 18:31:57 <Garibaldi|work> so I have a recipe A that depends on an artifact written by recipe B.  If I put within A DEPENDS += "B", it looks like it tries to build A and B at the same time.  Is there a way to say "B must be finished before A starts?"
Jun 17 18:33:44 <Garibaldi|work> I get a failure within A that the artifact written by B isn't there yet
Jun 17 18:33:55 <Garibaldi|work> later B finishes
Jun 17 18:34:33 <Garibaldi|work> and if I rerun the 'bitbake A' it works
Jun 17 18:47:25 <Garibaldi|work> any pointers?
Jun 17 18:51:33 <Garibaldi|work> err, I should say "if I rerun bitbake -k A" it works
Jun 17 18:51:47 <Garibaldi|work> since the original 'bitbake -k A' finished building/installing B
Jun 17 18:54:01 <Garibaldi|work> is it possible to make the execution of a function dependent upon another recipe?
Jun 17 19:00:57 <evanp> Garibaldi|work: look at meta.bbclass and/or image.bbclass, both of which depend on similar ordering constraints
Jun 17 19:01:17 <Garibaldi|work> evanp: thanks, I'll take a look
Jun 17 19:03:18 <evanp> Garibaldi|work: also, don't forget about the case when B is "built" via sstate cache hit, and whether that drops your artifact in the right place too
Jun 17 19:03:46 <Garibaldi|work> err, yeah, I didn't consider that case
Jun 17 19:04:17 <Garibaldi|work> I'm fishing a file out of ${STAGING_DATADIR}
Jun 17 19:04:46 <Garibaldi|work> I'm guessing that wouldn't be there in the sstate cache hit case
Jun 17 19:05:45 <Garibaldi|work> maybe there's a better way to go about what I'm trying to do
Jun 17 19:06:37 <evanp> Garibaldi|work: I'd expect that to work, actually
Jun 17 19:07:28 <Garibaldi|work> I have a source repository with a Makefile that has a target that builds a directory full of python code suitable for distutils.  I had one recipe runs thought and and builds the directory and creates a tarball of it, then another that inherits distutils that takes that tarball and processes it.
Jun 17 19:07:31 <evanp> Garibaldi|work: looking for files in deploy/images is the kind of thing that probably won't
Jun 17 19:07:48 <Garibaldi|work> ah, yeah, this ought not be on the rootfs
Jun 17 19:09:04 <Garibaldi|work> if A DEPENDS on B, s that only A's do_compile() that is blocked on B?  I have A's do_fetch() pulling the file out of ${STAGING_DATADIR}
Jun 17 19:09:17 <evanp> Garibaldi|work: why the indirection? why go through a tarball, I mean?
Jun 17 19:09:38 <evanp> Garibaldi|work: do_configure too. but not do_fetch.
Jun 17 19:09:57 <Garibaldi|work> evanp: I don't own the content of the repository
Jun 17 19:10:50 <Garibaldi|work> and the logic for pulling all of the content together is in the 'release' target of the Makefile, which in turns builds the tarball
Jun 17 19:11:19 <evanp> Garibaldi|work: no, I mean, once you have the directory suitable for distutils, why don't you just operate on it directly? why tar it up, stage it, and then have a different recipe grab it? why not all in one recipe?
Jun 17 19:12:20 <Garibaldi|work> well the Makefile from the repo generates the tarball.  I guess I could inspect the Makefile and reimplement the logic, but I'm afraid the logic would change
Jun 17 19:13:12 <evanp> Garibaldi|work: you could also extract the tarball immediately after the make command that generates it, all within do_compile or whatever
Jun 17 19:14:03 <Garibaldi|work> yeah, I thought of that too, but then I'd have to re-implement what the 'distutils' bbclass is doing, no?
Jun 17 19:14:16 <Garibaldi|work> I guess if it's fairly simple, that'd work
Jun 17 19:14:29 <evanp> Garibaldi|work: hmm. true.
Jun 17 19:15:21 <Garibaldi|work> this way seemed to let me keep the abstraction of the Makefile from the repo and the distutils bbclass, but alas I have the dep problem with my do_fetch
Jun 17 19:15:46 <Garibaldi|work> either I need a way to makde do_fetch block until dependencies are done, or I can move my do_fetch logic to a later stage
Jun 17 19:15:56 <evanp> Garibaldi|work: you don't depend on distutils for your do_fetch stuff though...maybe just addtask some steps in between do_patch and do_configure?
Jun 17 19:16:12 <Garibaldi|work> yeah, I agree
Jun 17 19:16:15 <evanp> Garibaldi|work: to run the tarball-generating makefile rules and extract it?
Jun 17 19:16:24 <Garibaldi|work> I'll take a look at that
Jun 17 19:16:32 <Garibaldi|work> seems like a better way to do it
Jun 17 19:22:05 * mr_science votes for the addtask approach
Jun 17 19:27:50 <Garibaldi|work> so I've never actually done an addtask
Jun 17 19:28:45 <Garibaldi|work> would it be something like 'addtask distutils_do_install after do_install'
Jun 17 19:28:58 <mr_science> define your custom function
Jun 17 19:29:24 <mr_science> then addtask foo after do_install before do_package
Jun 17 19:29:36 <mr_science> or whatever your ordering is
Jun 17 19:30:04 <Garibaldi|work> so I need to re-implement the functions from distutils.bbclass?
Jun 17 19:30:59 <mr_science> if you inherit in your recipe, you can just call them
Jun 17 19:31:55 <Garibaldi|work> yeah, but if I inherit them, won't they provide implementations of the various functions?
Jun 17 19:31:58 <evanp> Garibaldi|work: no, the way I'd do it you'd need to reimplement the function that currently calls your tarball-creating make target
Jun 17 19:32:11 <mr_science> haven't actually tried that, but it sounded good...
Jun 17 19:32:32 <Garibaldi|work> evanp: right now I do that in 'do_compile()'
Jun 17 19:32:56 <Garibaldi|work> so add a task after do_configure and before do_compile to build the tarball, then extrac it
Jun 17 19:33:14 <Garibaldi|work> then let do_compile pick up from there
Jun 17 19:33:15 <mr_science> yup, sounds like a plan...
Jun 17 19:33:31 <Garibaldi|work> ok, that makes sense, I'll give it a shot
Jun 17 19:33:33 <evanp> Garibaldi|work: yep, in your second recipe. also copy over the SRC_URI and stuff from your first recipe.
Jun 17 19:40:57 <mr_science> is this more or less the "correct" way to enable hf/vfp from a generic armv6 config?
Jun 17 19:41:04 <mr_science> https://github.com/sarnold/meta-raspberrypi/commit/d796222d99fb43b37c296555994ba7c1159ddd64
Jun 17 19:41:30 <mr_science> first two files only; i already found the proper fix for empcd
Jun 17 19:58:48 <Garibaldi|work> evanp, mr_science: thanks!  I do believe this approach is working (and is a much nicer way to do it).  I appreciate your suggesitons!
Jun 17 20:16:01 <mr_science> Garibaldi|work: good deal, just don't take any wooden centuari nickels
Jun 17 20:16:19 <bluelightning> :)
Jun 17 20:24:16 <Garibaldi|work> :-)
**** ENDING LOGGING AT Tue Jun 18 02:59:59 2013