**** BEGIN LOGGING AT Sun Dec 04 02:59:58 2011 Dec 04 03:50:51 * pidge does the license manifest happy dance even if the RFC email choked. dvhart: send-pull-request doesn't like certain line lengths in the patches (was deleting a very long line). Any BKMs on working around that? Dec 04 18:44:20 hi all Dec 04 18:44:41 is there anyone here that wants to talk about a quick yocto question? Dec 04 19:09:34 how do I find a list of all valid options for MACHINE? I see atom-pc is valid. but when experamenting with the downloadable images online I can only get the n450 images to boot my netbook. does that mean I can use n450 as a valid MACHINE? what happens if I want to use a Core2Duo cpu? what on earth do I enter then? I've been looking through the documentation and it's not clear. The docs always Dec 04 19:09:34 talk about the qemu emulator but that's not always helpfull. I wish there were more examples other than just the few BSPs... maybe some YouTube videos? I'm so stuck! Dec 04 19:10:50 It makes me feel like I'm missing something obvious. any sugestions? Dec 04 19:27:04 Andy44: You can use n450 as MACHINE with the meta-intel BSP then if that is what is working for you. Dec 04 19:27:54 You'll need to grab the layer git://git.yoctoproject.org/meta-intel and modify bblayers.conf so it can use it. Then set your MACHINE to n450. Dec 04 19:29:32 MACHINE within meta-yocto are qemu* and the 4 core BSPs (atom/routerstation/beagleboard/mpc). Dec 04 20:43:06 wow ok thanks pidge Dec 04 20:43:25 i totally didn't know about the meta-intel BSP - thanks! Dec 04 20:45:09 Andy44: you're welcome. Dec 04 20:45:12 do you know what I might use for MACHINE if I'm using an Intel Core2Duo? Is there a listing of possible values for MACHINE? Dec 04 20:50:01 Andy44: well, you could try actually using the qemux86* images IIRC. As for MACHINE listings, for yocto check out the local.conf. For meta-intel, each machine is listed in the root of the layer (ie meta-*). I'm trying to remember where you can pull that from but it's not coming to me. Dec 04 20:51:08 again, Dec 04 20:51:12 ah, now I remember. conf/machine/*.conf Dec 04 20:51:19 thank you - I'll look into it Dec 04 20:52:44 this will keep me busy for a while. Dec 05 01:20:31 https://github.com/kergoth/oe-core/compare/copyleft-compliance Dec 05 01:20:57 This is my attempt to replace src_distribute_local with something more targeted to the particular need Dec 05 01:25:23 I think the emission of patch series files is quite helpful, from a user side. Getting a tarball + patches isn't of much use without knowing what order to apply them in Dec 05 01:25:23 heh Dec 05 01:29:24 hmm, forgot to add the unit tests for the license parsing Dec 05 01:42:15 kergoth`: looking at your patch. One of the things I'm working on for the LicenseVisitor class is a way to handle bitor LICENSE and "or later" LICENSE, specifically around setting license priority. Dec 05 01:44:20 So: given FOOv2(+) FOOv3 and BARv1; if I've set FOOv2 as having a higher priority than FOOv3 and BARv1; given LICENSE = "FOOv2+ | BARv1" valid LICENSES could be FOOv2 FOOv3 BARv1 but prioritized would spit out FOOv2. Dec 05 01:44:48 make sense of have I been staring at my monitor for too long? Dec 05 01:46:24 /of/or/ Dec 05 01:48:49 Yeah, I was thinking about that too. It'd have to have a definitive list of available licenses to access to determine that list Dec 05 01:49:32 Hmm, wonder if I should rework this to be image-based. This image + its corresponding sources for compliance. course, the user might be building feeds, so maybe that wouldn't be ideal Dec 05 01:51:21 doing what you're talking about using the FlattenVisitor wouldn't be terribly difficult via the choose function. iterate over a side's licenses, expand out any +'s, then apply preference/priority logic as you describe Dec 05 01:54:32 * kergoth` goes back to watching house **** ENDING LOGGING AT Mon Dec 05 02:59:58 2011