**** BEGIN LOGGING AT Fri May 03 02:59:58 2013
May 03 03:59:04 <Net147> how to fix "no generic license file exists" warning for custom license?
May 03 07:45:23 <mckoan> good morning
May 03 08:06:09 <mcfrisk> hi, just an update that my cmake problems from yesterday were resolved with a site-file.cmake, copied from the TryRun* file which failed, basic cmake cross compiling stuff it seems.
May 03 08:39:18 <rburton> mcfrisk:isn't that what cmake.bbclass does?
May 03 08:50:45 <mcfrisk> rburton: yes, exactly but one compile time run check needed a workaround through that file
May 03 08:52:00 <rburton> ah
May 03 08:52:20 * rburton hits his laptop with a big hammer
May 03 08:58:01 * mcfrisk wonders where these -dbg, -dev, -doc etc packages came from, all I did was 'inherit cmake' :)
May 03 09:00:31 <rburton> magic!
May 03 09:00:39 <rburton> its the base packaging rules
May 03 09:01:57 <mcfrisk> yes, magic!
May 03 09:02:07 <rburton> see bitbake.conf
May 03 09:02:20 <rburton> it defines a default PACKAGES and some FILES_blaa
May 03 10:15:23 <Net147> how would I fix "WARNING: mypackage: No generic license file exists for: mypackage in any provider"?
May 03 10:29:32 <william> willy am
May 03 10:31:43 <bluelightning> Net147: you can ignore it, or provide the license text in a file and place it in a directory in your layer, then add that directory to LICENSE_PATH in your layer's conf/layer.conf (using ${LAYERDIR} to make it a full path)
May 03 10:33:15 <bluelightning> Net147: that's assuming that LICENSE is correct and shouldn't just be some other value pointing to an existing file in meta/files/common-licenses
May 03 15:08:35 <kergoth> damnit, this makes no sense. bitbake is saying there's a preference conflict resolving runtime linux-libc-headers-dev between linux-libc-headers-imx and external-sourcery-toolchain even if the latter doesn't have that in its packages or rprovides
May 03 15:12:40 <bluelightning> kergoth: nothing to do with PACKAGES_DYNAMIC at all?
May 03 15:15:04 <kergoth> not that i can see
May 03 15:15:05 <kergoth> check out https://gist.github.com/kergoth/5509743
May 03 15:15:23 <kergoth> grepped bitbake -e of the external toolchain for every expanded reference to linux-libc-headers
May 03 15:15:26 <kergoth> thats all there is
May 03 15:15:31 * kergoth is quite confused
May 03 15:16:15 <kergoth> trying to make it work fine either in the separate linux-libc-headers recipe case or the external toolchain linux-libc-headers case
May 03 15:16:20 <kergoth> and this should be working, as far as i can see..
May 03 15:19:27 <bluelightning> kergoth: it's certainly not being helpful in explaining how it's got into that situation :/
May 03 15:19:39 <kergoth> indeed
May 03 15:19:59 <kergoth> I can't see anything that both recipes either provide or rprovide that could possibly cause a conflict
May 03 15:20:02 <kergoth> mind boggling
May 03 15:20:04 <kergoth> must be something obvious
May 03 15:20:51 <bluelightning> kergoth: what is in OVERRIDES?
May 03 15:21:25 <bluelightning> not mx3 by any chance?
May 03 15:21:47 <kergoth> nope, it's an mx6 build
May 03 15:21:52 <kergoth> weird eh?
May 03 15:22:52 <bluelightning> very
May 03 15:59:28 <Crofton|work> zeddii, do you know anything about the perf recipe?
May 03 15:59:40 <kergoth> wow this is screwed up
May 03 15:59:43 * kergoth kicks bitbake repeatedly
May 03 15:59:47 <Crofton|work> ?
May 03 15:59:54 <zeddii> some yep.
May 03 16:00:08 <Crofton|work> for my 3.5 recipe if fails to build
May 03 16:00:14 <zeddii> hmm.
May 03 16:00:16 <kergoth> bitbake thinks this recipe rprovides something that isn't mentioned anywhere in its bitbake -e output, and it's hurting my head
May 03 16:00:19 * kergoth mutters
May 03 16:00:30 <Crofton|work> this is with your kernel tool patch
May 03 16:00:39 <Crofton|work> I'm not sure how all this fits together
May 03 16:01:20 <zeddii> what's your failure, straight up compile error ?
May 03 16:02:42 <Crofton|work> |     CC /home/balister/src/oe-core/build/tmp-eglibc/work/ettus_e1xx-oe-linux-gnueabi/perf/1.0-r8/perf-1.0/util/evsel.o
May 03 16:02:42 <Crofton|work> | util/evsel.c:18:44: fatal error: ../../include/linux/perf_event.h: No such file or directory
May 03 16:02:42 <Crofton|work> | compilation terminated.
May 03 16:02:43 <Crofton|work> yep
May 03 16:03:52 <kergoth> aha
May 03 16:04:59 <kergoth> bluelightning: I'm using the external-sourcery-toolchain recipe from meta-sourcery, not the oe-core one, and the former layer is higher priority than the latter, so the former one *should* be irrelevent, yet bitbake is indicating a preference conflict because a non-preferred recipe which won't be built can emit a binary package that another recipe which *will* be built can emit
May 03 16:05:06 <kergoth> bluelightning: bitbake bug.
May 03 16:05:34 <bluelightning> kergoth: sigh...
May 03 16:06:07 <bluelightning> that is definitely a bug
May 03 16:06:11 <Crofton|work> omfg, there is a bug in bitbake!
May 03 16:06:15 <kergoth> haha
May 03 16:06:15 <Crofton|work> :)
May 03 16:06:39 <bluelightning> kergoth: however, what is the plan for the external-toolchain-sourcery recipe in OE-Core?
May 03 16:07:18 <kergoth> that's a good question. the sourcery toolchain requires that we pass certain sourcery g++ specific arguments to ensure it uses the right multilibs, meaning to support it fully, it has to override the tunings set in the tuning files
May 03 16:07:39 <kergoth> so either it needs its own layer, which was what we did to get past it for the time being, or it has to start doing ugly overrides in the tcmode itself
May 03 16:08:23 <kergoth> so either we add those hacks to it, remove it entirely, or treat it more as an example of how to create your own setup than as something fully functional
May 03 16:09:06 <kergoth> i'd lean toward its removal and pointing to the layer we maintain, since i can also go yell at the folks working on the toolchain internally, and perhaps add a different external toolchain recipe to the core for something a bit simpler to support
May 03 16:09:15 <bluelightning> hmm
May 03 16:09:30 <bluelightning> I guess the primary reason we have it is as a supported example
May 03 16:09:49 <kergoth> as a concrete example of this, passing the usually e500v2 arguments from the ppc tuning files is insufficient to select the correct multilib in the toolchain, it needs -te500v2 passed
May 03 16:09:52 <bluelightning> but if it doesn't really work properly and the canonical version is maintained elsewhere, it does seem sensible to drop the core one
May 03 16:10:59 * kergoth ponders
May 03 16:15:05 <kergoth> I can't help but wonder if we couldn't figure out the bits common to supporting any external toolchain and make some .incs to leverage, if we were smart about it. e.g. don't hardcode the sysroot path, ask the toolchain for it (current meta-sourcery does this)
May 03 16:21:18 <RP> kergoth: I think the hope was to have a simple example of an external toolchain in OE-Core
May 03 16:21:34 <RP> kergoth: the sorcery one does seem to be moving a bit beyond that :/
May 03 16:22:16 <RP> kergoth: btw, did you see my question about oe.types the other day?
May 03 16:22:53 <kergoth> about python3? yeah, but I haven't had time to look at it closely, been fighting fires at work
May 03 16:23:10 <kergoth> gotta love deadlines
May 03 16:23:51 <RP> kergoth: ok, haven't had a chance to go back and poke at it myself either. Seems in python3 they removed the bits of the types module we use :(
May 03 16:28:16 <kergoth> Hmm, interesting. okay
May 03 17:03:04 <zeddii> Crofton|work, I stepped out for sunshine and food. still working your issue ?
May 03 17:09:48 <Crofton|work> I removed profile tools for now
May 03 17:13:16 <zeddii> Crofton|work, that's the typical approach :) the thing is, a 3.5 kernel is plenty new and I would have built for it in the past. I know I've seen that error before. something is racing.
May 03 17:13:52 <Crofton|work> thats kind of why I thought I would get an image
May 03 17:14:06 <Crofton|work> jsut ran bitbake perf lets see what ahppens
May 03 17:14:30 <Crofton|work> still fails
May 03 17:14:55 <zeddii> hmm. I'm working on some kernel updates now. I'm going to try the same with 3.9/3.10 git.
May 03 18:33:42 <Crofton|work>          Please check the log '/home/balister/src/oe-core/build/tmp-eglibc/work/ettus_e200-oe-linux-gnueabi/perf/1.0-r8/temp/log.do_compile' for more information.
May 03 18:36:21 <seebs> There's a patch I submitted to the list a while back which might help if you're having the problem that sounds like to me.
May 03 18:36:39 <seebs> Which is that bitbake runs scripts with set -e, so any program returning a non-zero status causes the script to abort, and then you get that message.
May 03 18:37:04 <seebs> And if you don't see a likely-looking error message other than that, it means that something returned non-zero in a way you didn't expect, or without producing an error message.
May 03 18:37:23 <seebs> So I submitted a patch a while back which tries to indicate what went wrong in a little more detail.
May 03 18:37:40 <bluelightning> seebs: can you resend if it hasn't been merged? that sounds like it would be useful
May 03 18:49:19 <seebs> I think I've been planning to do that for quite a while, I just keep being interrupted by stuff.
May 03 19:33:17 <Circuitsoft> So, I'm having trouble with my python bbappend.
May 03 19:33:34 <Circuitsoft> https://gist.github.com/Circuitsoft/ba0e9301f7fec5790595 - I'm still missing netrc and importlib
May 03 21:24:05 <kergoth> what the hell, just had eglibc-locale fail on me trying to run split_and_strip_files in the objcopy command
May 03 21:25:13 <kergoth> "cannot create debug link section"
May 03 21:25:16 <kergoth> "Invalid operation"
May 03 21:25:17 <kergoth> hmm
May 03 22:02:33 <sgw1> Khem: around?
May 03 22:06:03 <feydrautha80> hello guys .. i made a recipe that just copies some configuration files . when I add to image install ..says it can't find that package. The recipe does produce a package ..but with names dev and debug
May 03 22:08:03 <sgw1> feydrautha80: the config files you are copying, do they go into the standard directories?
May 03 22:09:43 <feydrautha80> yup
May 03 22:10:12 <feydrautha80> more exactely i'm tring to create some directories lie : /usr/local/hummuhummu
May 03 22:10:25 <sgw1> Ah, /usr/local that's it
May 03 22:10:40 <sgw1> so you might need to set a FILES_${PN}/usr/local
May 03 22:10:50 <feydrautha80> i tried to create the packege again .. failed on do_install step
May 03 22:10:53 <sgw1> oops, forgot the =
May 03 22:11:17 <kergoth> probably better to just fix the recipe to not put files in /usr/local
May 03 22:11:21 <feydrautha80> FILES_${PN} += /usr/local
May 03 22:11:25 <kergoth> thats not intended to be under pckage management control, generally
May 03 22:11:25 <sgw1> FILES_${PN} = "/usr/local
May 03 22:11:54 <feydrautha80> wait
May 03 22:12:08 <feydrautha80> i think i might explain thing wrongly
May 03 22:12:28 <feydrautha80> i want to creata directory called /usr/local/blahblah
May 03 22:12:36 <feydrautha80> with some other directories in it
May 03 22:12:42 <kergoth> sgw is telling you how to package that, and i'm telling you "don't do that"
May 03 22:12:43 <kergoth> :)
May 03 22:12:51 <feydrautha80> yup
May 03 22:13:05 <feydrautha80> so ..
May 03 22:13:14 <feydrautha80> an alternative ?
May 03 22:13:17 <feydrautha80> or suggestion ?
May 03 22:13:26 <kergoth>  /usr/local/ is intended to be left under user control, not the package manager / distro. install to standard locations.
May 03 22:13:33 <kergoth> but it's your call
May 03 22:13:45 <kergoth> the FILES change will definitely get it packaged for you
May 03 22:14:04 <sgw1> feydrautha80: kergoth is right, should be put in standard locations not /usr/local if you are creating a distro.
May 03 22:14:21 <feydrautha80> so i should spread my binaries in /usr/bin
May 03 22:14:29 <feydrautha80> and libraries in /usr/lib
May 03 22:14:33 <kergoth> it's a best practices thing. recipes create packages, and packages hsouldn't touch certain dirs
May 03 22:14:37 <feydrautha80> and conf files in /etc right?
May 03 22:14:48 <kergoth> but of course there are exceptions, and at times deadlines limit your ability to do things the right way
May 03 22:15:09 <kergoth> e.g. i've seen cases where recipes install to /home/root/ and there just wasn't time to address it in a nicer way
May 03 22:15:25 <kergoth> feydrautha80: yes, there's variables for all those. /usr is ${prefix}, /usr/bin is ${bindir}, /usr/lib is ${libdir}
May 03 22:15:37 <kergoth> etc is ${sysconfdir}
May 03 22:16:06 <feydrautha80> i remember seeing that somewhere :)
May 03 22:16:09 <feydrautha80> thank you guys
May 03 22:16:21 <feydrautha80> is not the work ..
May 03 22:16:30 <feydrautha80> that i'm afraid
May 03 22:17:03 <feydrautha80> its the stubornes and stupidy of .. higher supervisors .... canadian west coast you know .. agile and feces
May 03 22:17:28 <feydrautha80> again thanks for the suggestion and the answer
May 03 22:17:31 <kergoth> ahh
May 03 22:17:34 <kergoth> good luck :)
May 03 22:17:43 <feydrautha80> eh no :)
May 03 22:17:46 <feydrautha80> that's bad luck :)
May 03 22:19:13 <feydrautha80>  btw
May 03 22:19:26 <feydrautha80> kergoth has any thing to do with a guy from Barbaria ?
May 03 22:20:14 <kergoth> no idea what you're referring to, so likely not
May 03 22:21:41 <feydrautha80> may a link an youtube link ?
May 03 22:22:30 <feydrautha80> or .. look for "Korgoth of Barbaria - Pilot HD " on youtube .. you'll have a laugh
**** ENDING LOGGING AT Sat May 04 02:59:58 2013