**** BEGIN LOGGING AT Mon Apr 01 02:59:57 2013
Apr 01 10:11:16 <tavish> hi, I do not want to fetch/build kernel using poky, and I have set linux-dummy as preferred provider of virtual/kernel. Yet it starts fetching from git repository. What should I do to not let that happen?
Apr 01 10:22:21 <bluelightning> tavish: you may find PREFERRED_PROVIDER_virtual/kernel is set at a level that overrides what you have set
Apr 01 10:23:35 <bluelightning> tavish: either set it in your own custom distro config, or temporarily you can set it using forcevariable i.e. PREFERRED_PROVIDER_virtual/kernel_forcevariable = "linux-dummy"
Apr 01 10:33:01 <tavish> bluelightning: thank you, i will try that
Apr 01 10:35:19 * RP1 finally figures out I have one broken component, one resistor value is wrong and the terminals are marked backwards on another component...
Apr 01 10:37:12 <bluelightning> RP1: great... hope you didn't let out too much of the magic smoke in finding that out...
Apr 01 10:37:36 <RP1> bluelightning: only yesterdays little fireworks display :)
Apr 01 10:38:09 <RP1> bluelightning: Its just frustrating that its taken this long to make the circuit work, Now I can move onto the next piece of it, its not even complete yet :/
Apr 01 10:40:30 <JaMa> lists.linuxtogo.org down? web pipermail?
Apr 01 10:40:41 <JaMa> timeouts from here
Apr 01 10:40:53 <Crofton|work> hmm, florian not online
Apr 01 10:41:50 * Crofton|work adds a note to his todo list to get halstead and florian talking
Apr 01 10:49:23 <tavish> bluelightning: :( now something needs kernel-base kernel-vmlinux, which starts fetching kernel again. i set PREFERRED_PROVIDER_kernel-base_forcevariable etc
Apr 01 10:50:26 <RP1> Its been a while since linux-dummy has been used, its possible its missing from PROVIDES/RPROVIDES :/
Apr 01 10:52:34 <tavish> RP1: would setting these in the linux-dummy recipe work?
Apr 01 10:55:12 <RP1> tavish: it would likely let your build get further
Apr 01 10:55:53 <RP1> tavish: recipes-kernel/oprofile/oprofile.inc:RRECOMMENDS_${PN} = "kernel-vmlinux"
Apr 01 10:56:28 <RP1> so its only a recommendation and so it should be ok in that case
Apr 01 10:58:30 <RP1> tavish: Try a RPROVIDES_${PN} += "kernel-vmlinux". If that works, please do send a patch :)
Apr 01 10:59:43 <tavish> sure thing, thanks
Apr 01 11:04:36 <tavish> RP1: it worked!
Apr 01 16:05:42 <RP2> The lack of burnt components was too good to be true. A capacitor couldn't take the strain, shorted out, set fire to a resistor and the transients took out half the other pieces of the circuit :/
Apr 01 18:34:08 <kergoth> Hmm, thoughts on deprecating SkipPackage in favor of a variable (e.g. BB_SKIPPED or SKIPPED)? Would make it possible to e.g. do a bitbake -e -b <recipe> for a skipped recipe, for example. The exception was an overly clever way of implementing it to begin with.
Apr 01 18:34:26 * kergoth is looking over his ooold todo lists
Apr 01 18:51:57 <mranostay> kergoth: that get populated on a bitbake run?
Apr 01 21:09:10 <evanp> I have a build-time tool--just a Python script--which I want to use in some recipes. This tool has its own recipe with BBCLASSEXTENDS = "native" and "inherit distutils"; the others say DEPENDS += "the-tool-native".
Apr 01 21:10:23 <evanp> I then try to build a top-level recipe which eventually pulls in this stuff
Apr 01 21:12:33 <evanp> and the build bombs because the do_compile step for my tool fails with ".../run.do_compile.XXXX: line 86: /home/YYYY/sysroots/x86_64-linux/usr/bin/python: No such file or directory"
Apr 01 21:13:05 <evanp> but when I look, a python interpreter is indeed at that location
Apr 01 21:13:38 <evanp> anybody have any thoughts?
Apr 01 21:13:53 <evanp> my tool recipe is modeled after the scons recipe
Apr 01 21:14:03 <evanp> and I'm on Yocto 1.2 currently
Apr 01 21:28:52 <bluelightning> evanp: that is odd... not sure what to suggest
Apr 01 21:33:02 <evanp> at first I was thinking it was as simple as needing to add DEPENDS += "python" to my tool recipe...and _some_ of the things which inherit distutils do in fact do that--but not all of them. The scons recipe doesn't, for example.
Apr 01 21:40:53 <evanp> oh. nevermind. that's exactly what I need to do..or, DEPENDS = python-native, rather: the scons recipe doesn't use BBCLASSEXTENDS = native, it has a separate native recipe, which _does_ set DEPENDS
Apr 01 21:41:14 <evanp> at least that sure sounds plausible
Apr 01 21:44:58 <bluelightning> evanp: well, if your recipe has python in its DEPENDS already, then when creating the -native variant that will be changed to python-native
Apr 01 21:45:23 <bluelightning> you can verify that by doing bitbake -e the-tool-native | grep ^DEPENDS=
Apr 01 21:45:24 <evanp> bluelightning: It didn't though, because the scons recipe I modeled after didn't
Apr 01 21:47:25 <evanp> apparently if I do nothing, my-tool has DEPENDS="blah blah python-native python" while my-tool-native has DEPENDS=""
Apr 01 21:47:57 <evanp> unless I add DEPENDS_virtclass-native += "python-native", which I just did, and which the python-scons-native recipe also does
Apr 01 21:52:00 <evanp> actually maybe it would make more sense to add the virtclass-native override to distutils-base.bbclass rather that recipes individually based on whether they inherit native....
Apr 01 22:43:14 <RP2> kergoth: The trouble is that some recipes are actually unparsable and raise SkipPackage in those cases so we'd have to decide all recipes should always be parsable
Apr 01 22:56:33 <kergoth> Hmmmm, good point
**** ENDING LOGGING AT Tue Apr 02 02:59:58 2013