**** BEGIN LOGGING AT Thu Nov 10 02:59:58 2011 **** BEGIN LOGGING AT Thu Nov 10 05:56:30 2011 Nov 10 06:08:43 good morning Nov 10 07:21:39 Why recipes doesnot contain libjpeg? o__O Nov 10 07:28:18 reisei: why do you say that? Nov 10 07:29:28 'cause I need libjpeg and suddenly didn't find it... Nov 10 07:32:42 reisei: find /path/to/oe -name "*jpeg*.bb" turns up nothing? Nov 10 07:36:38 ok, seems, its name is just "jpeg". thanks, zecke Nov 10 07:44:46 Is there a way to list all packets included in an image alongside with their license types (GPL, BSD...)? Nov 10 07:57:22 trying to compile an sdk here, and it ends up being only 376kB. it's basically meta-toolchain-qte with a few packages added. Nov 10 08:01:28 Is there a way to list all packets included in an image alongside with their license types (GPL, BSD...)? Nov 10 08:08:21 good morning Nov 10 08:08:31 florian: morning Nov 10 08:09:28 morning Nov 10 08:12:47 good morning Nov 10 08:27:14 anyone else compiling sdk from oe-core these days? I'm cleaning all I can think of, and still the SDK is only 375 kB. Nov 10 08:27:55 tasslehoff: no, last time I tried was broken Nov 10 08:27:56 tasslehoff: did you take a look at the logs? Nov 10 08:29:29 mckoan: the brokenness is gone. it claims to compile fine now :) Nov 10 08:29:55 zecke: will do now. Nov 10 08:30:05 mornin Nov 10 08:34:02 * mckoan is bitbaking Nov 10 08:36:53 I've set PR="r2" in my meta-toolchain-bd.bb, but in the workdir the folder is named r6, likely from meta-toolchain.bb which it requires. don't know if that's right, but the logs seems kinda sparse Nov 10 08:37:27 * tasslehoff is trying to improve his bitbake-log-reading-skills Nov 10 10:26:11 hi woglinde Nov 10 10:54:24 hi ant Nov 10 11:25:51 NOTE: The checksums for '/home/koan/devel/sources/binutils-2.20.1.tar.bz2' did not match. Nov 10 11:26:07 could I change the SRC_URI ? Nov 10 11:26:43 mckoan: Did the download corrupt? Nov 10 11:27:05 RP__: hmmm let me check Nov 10 11:27:18 2.20.1 was replaced with a symlink to 2.20.1a on some servers, I think Nov 10 11:33:38 patrickg: ah, yes. An idea which I never quite understood :( Nov 10 11:33:52 RP__: it was because of GPL violation Nov 10 11:34:21 RP__: deleted old sources, re-bitbaked same error, wrong checkums Nov 10 11:34:23 http://nickclifton.livejournal.com/9067.html Nov 10 11:35:40 mckoan: there are better fixes than what you just pushed.. but it's your branch so I don't care Nov 10 11:36:05 JaMa|Off: what for example? Nov 10 11:36:44 every patch which was changing binutils/gdb checksums lately in oe Nov 10 11:37:04 master or maintenance branch Nov 10 11:38:17 JaMa|Off: I don't understand Nov 10 11:38:30 JaMa|Off: they could have dropped 2.20.1 entirely (no symlink) Nov 10 11:38:52 mckoan: 262f9eb0f046cd77d041a9dcb055700c5ab6601b Nov 10 11:40:40 03Richard Purdie  07master * r6004cbf36c 10bitbake.git/lib/bb/cooker.py: (log message trimmed) Nov 10 11:40:41 cooker.py: Ensure only one copy of bitbake executes at once Nov 10 11:40:41 The bitbake codebase makes assumptions that only one copy is active Nov 10 11:40:41 against a given build directory at a given time. This patch adds a Nov 10 11:40:41 lockfile in TOPDIR to ensure that is the case. Nov 10 11:40:41 Note that no unlock is needed, that is automatically dropped when Nov 10 11:40:42 execution terminates. Nov 10 11:40:50 03Richard Purdie  07master * rf421ef819f 10bitbake.git/lib/bb/utils.py: Nov 10 11:40:50 utils.py: Fix lockfile retry handling Nov 10 11:40:50 The lockfile retry parameter is expected to return immediately after Nov 10 11:40:50 attempting to take the lock. There was a bug in the logic which this Nov 10 11:40:50 patch fixed to ensure it does that. Nov 10 11:40:50 Signed-off-by: Richard Purdie Nov 10 11:40:52 03Richard Purdie  07master * r05c29ab0b2 10bitbake.git/lib/bb/ (cache.py runqueue.py): (log message trimmed) Nov 10 11:40:52 Add FAKEROOTNOENV variable Nov 10 11:40:52 Add a FAKEROOTNOENV which does the opposite of the FAKEROOTENV variable Nov 10 11:40:52 and is data loaded into the environment for tasks without the fakeroot Nov 10 11:40:53 flag. Nov 10 11:40:53 The intent here is to provide a way to control the environment when we Nov 10 11:40:54 aren't needing fakeroot context which allows us to unload the preload Nov 10 11:40:54 03Richard Purdie  07master * r4a4046268f 10bitbake.git/lib/bb/data_smart.py: (log message trimmed) Nov 10 11:41:15 It also adds corresponding variants for flags. Nov 10 11:41:15 Currently there is no spacing added by these functions. That could be Nov 10 11:42:01 JaMa|Off: uh, ok thanks I was living in my branch and I miss it Nov 10 11:48:40 rp in Allow use of dash as /bin/sh some patches sneaked in Nov 10 11:49:06 /meta/recipes-devtools/libtool/libtool/prefix.patch Nov 10 11:49:30 meta/recipes-devtools/openjade/openjade-native_1.3.2.bb b/meta/recipes-devtools/openjade/openjade-native_1.3.2.bb Nov 10 11:52:46 woglinde: they are mentioned in the commit log Nov 10 11:53:39 only libtool Nov 10 11:53:45 not jade Nov 10 11:54:01 ups okay Nov 10 11:59:38 woglinde: I probably should have split it out but it was intentional to fix those things Nov 10 11:59:48 woglinde: good news is that dash works with those fixes :) Nov 10 12:10:10 that is good news. is it noticeably faster to build with dash than bash? Nov 10 12:12:00 pb_: I've not actually benchmarked it Nov 10 12:12:09 pb_: libtool is still using bash fwiw Nov 10 13:34:16 bluelightning ping, what was the fix for LIC_FILES_CHKSUM when one recipe as no real code Nov 10 13:34:47 woglinde: check any task-* recipe for example Nov 10 13:35:00 woglinde: usually reuse MIT license from COREBASE Nov 10 13:35:02 core or meta? Nov 10 13:35:05 both Nov 10 13:37:04 uhm Nov 10 13:37:08 the all have it Nov 10 13:39:11 okay base was pokay Nov 10 14:02:34 woglinde: LIC_FILES_CHKSUM = "file://${COMMON_LICENSE_DIR}/GPL-2.0;md5=801f80980d171dd6425610833a22dbe6" Nov 10 14:02:56 yes yes found it Nov 10 14:02:59 don't forget to switch to whatever license is appropriate Nov 10 14:47:37 who can create new meta repositories? do they need to be discussed? Nov 10 14:47:45 I would like to create meta-telephony Nov 10 14:48:08 discuss it on the list Nov 10 14:48:43 * florian wants a meta-classic repo :) Nov 10 14:52:59 florian: we want people to tidy up the recipes and group them appropriate layers, that would discourage people from doing so Nov 10 14:55:35 bluelightning: I see the idea but this generates a chicken and egg situation: People stay with oe-classic because oe-core doesn't offer all the software and devices known from oe-classic... which results in less users and therefore less recipes in oe-core. Nov 10 14:56:20 and looking at the current situation this is not just theory - its a fact that exactly this happens. Nov 10 14:57:02 there has to be someone who cares enough about particular software / machines to step forward and maintain them Nov 10 14:57:12 Still I am wondering why not more people contribute to OE-classic? Nov 10 14:57:15 clearly there were such people when everything was in one repo... Nov 10 14:57:34 … and send patches. Nov 10 14:57:59 florian: actually, I read that OE-classic becomes deprecated, this was the only reason why I decided to migrate our product to OE core Nov 10 14:58:00 PaulePanter: ... because they get the impression that oe-classic was abandoned Nov 10 14:58:47 if I knew OE-classic stays maintained, I would not have switched to OE-core Nov 10 14:58:55 Jin^eLD: that's the point... for most of our users oe-classic simply does what they need it for. Nov 10 14:59:09 Did they get the impression by lurking on the list? Nov 10 14:59:10 yep, I do like classic more (maybe just used to it) Nov 10 14:59:18 but for me classic has a little more overview Nov 10 14:59:55 and its way easier just to try something with some random new piece of hardware Nov 10 15:00:02 florian: it also contains mountains of cruft Nov 10 15:00:39 bluelightning: it does... but noone cares because it does what these people need it for Nov 10 15:00:56 bluelightning: + some pieces of those mountains are indeed needed by various people Nov 10 15:00:59 I think it would be more helpful if people could articulate the specific things they are missing, then we can start to improve things Nov 10 15:01:08 I realise that list might be quite long Nov 10 15:01:14 I am now inmind the migration of my stuff to core, and I constnatly have to dig out recipes from classic and migrate them over Nov 10 15:01:33 in oe-core it iss distributed among piles of layers from multiple locations and it is much harder to get somethign adapted Nov 10 15:01:44 florian: +1 Nov 10 15:02:26 and then you run into another problem: you want to contribute and have no idea where to add things to Nov 10 15:02:43 florian: That is a good point. spreading things out makes them harder to find. just the recipes- separation within oe-core causes me headaches on a daily basis -- i never remember what's where, so i have to use a glob or find nearly every time Nov 10 15:02:47 heh Nov 10 15:03:39 just the situation i have some random piece of hardware with omap3 -> i adapt some bits, add anew machine and kernel patch - and now? Nov 10 15:04:00 wtf? another layer for this hardware Nov 10 15:04:14 this is the point most contributors *will* give up Nov 10 15:04:51 florian: what you describe sounds like a BSP for your random piece of hardware... Nov 10 15:04:55 kergoth: yeah.. i have to use find more often. Nov 10 15:05:04 florian: well, create a meta-junk/ Nov 10 15:05:13 I'm not sure what a better approach would be, but clearly this isn't ideal either Nov 10 15:05:15 :\ Nov 10 15:06:12 In my opinion one of the reasons for this is, that oe-core was discussed on a separate list in the beginning. Nov 10 15:06:27 so guys.. IS classic deprecated or not? or was I too fast jumping on the new boat? :) Nov 10 15:06:40 I think it's more fundamental than that. some people have issues with the whole concept of breaking things up into individual layers like this Nov 10 15:06:42 from a technical point of view oe-core+layers is a good concept. but from a usability perspective its a major pain... Nov 10 15:06:51 Jin^eLD: classic is deprecated from the perspective of most, yes Nov 10 15:07:11 Jin^eLD: from the commit log I'd guess it is Nov 10 15:07:17 we've discussed having some form of index for recipes, would be great if someone had time to implement it Nov 10 15:07:28 I think it'd be sweet to have apt-get for oe metadata Nov 10 15:07:34 just go out, get the shit i need, and go Nov 10 15:08:31 bluelightning: not really - I could deal with these things here easily. its more a matter for people who want to get some single piece of hardware supported Nov 10 15:08:56 heh, maybe we need a random-bsps-go-here-layer Nov 10 15:09:38 Well the question is still what to do? Nov 10 15:09:46 maybe something like a generic "contrib" layer. distribution repositories are organised in a similar way Nov 10 15:09:47 kergoth: that could work... meta-handheld is s/random/old handheld/ for the same thing Nov 10 15:10:11 There was not a lot of discussion on the list? Nov 10 15:10:19 kergoth: what is your opinion on git submodule? i kinda hate them. :( Nov 10 15:10:27 florian: that could become quite messy though Nov 10 15:10:46 Some people complained but only a few. Nov 10 15:10:54 PaulePanter: by all means let's restart the discussion Nov 10 15:10:56 florian: well, meta-oe sort of is the random contributions layer, but its less about bsps and more about random recipes from oe Nov 10 15:11:00 bluelightning: but providing lots of additional functionality and software. that's why people use OE Nov 10 15:11:02 zecke: meh Nov 10 15:11:39 zecke: right now I'm playing around with 'repo' for my oe based setups, giving it a try anyway. I like the reduction in overhead commits 'update layers' etc that you get with submodule, since it can track branches Nov 10 15:11:45 bluelightning: There is the next problem. ;-) On OE-core or oe-devel? Nov 10 15:11:56 bluelightning: the good thing with oe is that you can totally ignore all the mess you choose not to need. Nov 10 15:12:10 PaulePanter: oe-devel Nov 10 15:12:24 yeah, thats the best part. its this pool of content you can snatch bits out of Nov 10 15:12:27 I think most people are not subscribed to oe-core yet and people on oe-core are probably not reading oe-devel that much (you excluded). Nov 10 15:12:34 PaulePanter: since the discussion is about stuff that's outside of oe-core, that's our current policy Nov 10 15:12:43 * kergoth 's been on both lists from the beginning and won't be changing that, ever Nov 10 15:12:56 florian: that suggest that someone has to really know what hs/he needs or not; I could figure out by examining the layers, but a new user will have troubles for sure Nov 10 15:13:00 *suggests Nov 10 15:13:43 florian: if you've been around for a long time like us, sure, that works... newcomers look at it and say "I don't need about 90% of this" Nov 10 15:14:40 thats why i think itd be cool to have the pool underlying a mechanism to 'install' what you require from it, similar to yum/apt. the fact that i *can* install a ton of crap i dont' need isn't really an issue if it's out of my sight Nov 10 15:15:33 kergoth: the problem then might then be what do you do when you want to send a patch for something? Nov 10 15:16:44 yeah, you'd have to have some sort of apt-get source analogue, or something set up specifically for that. if it actually pulled the metadata locally, perhaps it could use git under the hood to track the changes Nov 10 15:16:48 * kergoth shrugs Nov 10 15:16:57 you're right, it's nontrivial, but I still like the concept. should try doing a prototype Nov 10 15:17:00 see how it goes Nov 10 15:17:13 morning kergoth Nov 10 15:18:21 zecke: I guess I can set up a new repo for you. you want meta-telephony as a layer on git.oe.org, right? Nov 10 15:19:14 kergoth: this might be interesting... even if it might be non trivial for people used to other contribution mechanisms Nov 10 15:35:06 pb_: thanks, but now I asked on the ML.. we should at least allow some discussion. :} Nov 10 15:37:44 florian: of course, this is part of the problem with a lot of the desktop distros. they have mechanisms like this, but they tend to suck at the 'rebuild the whole universe' thing that we do well Nov 10 15:38:02 anyway Nov 10 15:41:03 hmm, is eglibc svn down? cross-localedef-native is not fetching :P Nov 10 15:41:54 wrt oe-core & meta-oe integration what's really disturbing are the duplicate recipes between the two layers Nov 10 15:42:13 koen is doing his best but there is still lot of work to do Nov 10 15:42:42 and apart otavio and JaMa not much help came :/ Nov 10 15:42:48 agreed Nov 10 15:43:31 I'm wondering if we should aim at merging or removing meta-oe alltogether Nov 10 15:43:55 i don't think that'd make much sense, personally. you'd lose the ease of contribution that classic oe provided Nov 10 15:43:56 ant_work: Merging meta-oe to what? Nov 10 15:44:26 Jin^eLD: seems like i can check out from eglibc svn manually. *shrugs* Nov 10 15:44:33 PaulePanter: merge down to oe-core or survive as separate layer (bitrot)? Nov 10 15:45:06 hmm, the fetch das is hanging here, let me try it manually... Nov 10 15:45:08 thanks for checking Nov 10 15:45:19 as far I see the meta-oe layer isn't the bleeding-edge it was Nov 10 15:45:35 and we (I for one) don't want it becomes that Nov 10 15:45:42 The other thing I'd really like to see, generally speaking, is a 100% srctree-ish oe build Nov 10 15:45:55 ant_work: bleeding edge or no, it still holds recipes that dont' belong in oe-core Nov 10 15:46:09 zecke: righto Nov 10 15:47:42 kergoth: I'm actually busted by the xserver discrepancies. Do we consider x core? Nov 10 15:48:39 I mean, RP insists to keep the core-image-sato in oe-core, thus... Nov 10 15:49:37 JaMa|Off: ping? Nov 10 15:49:56 ant_work: I would not object to a merge, but if I am not mistaken that was the whole reason for restructuring the repository. Nov 10 15:50:06 pong Nov 10 15:50:42 I think X probably is "core" in most reasonable definitions of the word. evidently you can build a system without it, but I think it meets the test of relevance to a large set of developers. Nov 10 15:51:05 and there probably is no single recipe in oe-core that is absolutely mandatory in all configurations. Nov 10 15:51:08 Where are these requirements written down? Nov 10 15:51:23 pb_: I agree. Nov 10 15:51:32 The thing about sato-image is (imho) largely unrelated to the question of whether X goes in oe-core or not. Nov 10 15:51:52 source code in the latest low end kindles: http://pastebin.com/bsXC5Ysz Nov 10 15:52:00 interesting they use GTK and DirectFB Nov 10 15:52:12 A lot of people use DirectFB Nov 10 15:52:14 gtk? crumbs Nov 10 15:52:14 Koen last time said there is too much stuff in OE-core already. But the way it looks like everything seems to transition to OE-core eventually and only causes support burden to update meta-oe to keep up with changes in OE-core. Nov 10 15:52:44 pb_: core-image-sato is supposed to be a test for X. So I targeted it. Then I discovered we have xf86-video-fbdev in meta-oe only :/ Nov 10 15:52:44 crbrake stoneage powertop Nov 10 15:52:47 CosmicPenguin: any idea if GTK+DirectFB is generally faster than GTK+tinyX? Nov 10 15:53:05 and stoneage directfb Nov 10 15:53:05 seems like there would be less context switches, which may help Nov 10 15:53:18 it depends on what you mean by faster, I suppose Nov 10 15:53:19 cbrake: humm... interesting indeed. Nov 10 15:54:06 CosmicPenguin: use less CPU cycles is what I need Nov 10 15:54:12 cbrake: Do they just provide the tarballs? Nov 10 15:54:22 and stoneage .31 kernel Nov 10 15:54:23 cbrake: if hardware acceleration is used, then probably the same Nov 10 15:54:25 muaahahaha Nov 10 15:54:32 PaulePanter: http://www.amazon.com/gp/help/customer/display.html?nodeId=200203720 Nov 10 15:54:59 CosmicPenguin: no hw accel -- this is old PXA270 system -- just raw FB Nov 10 15:55:20 I dunno - frame to frame probably the same Nov 10 15:55:32 X has a larger resource load and thats probably the difference. Of course, X does more things too Nov 10 15:55:59 cbrake: or an i.MX - iirc 2.6.31 was the freescale default for quite a while Nov 10 15:56:30 florian: I'm using a PXA270 in a design, I'm not sure what kindle uses Nov 10 15:57:15 ant_work: well, core-image-sato is meant to be a test for the desktop bits. afaik, all the qemu systems in oe-core use xserver-kdrive to run the tests. Nov 10 15:57:40 it possibly is true that xserver-xorg in oe-core is not very useful on its own if it doesn't have any drivers. Nov 10 15:58:48 pb_: yes, imagine I'd like to calibrate my ts ;) So add xinput and xinput-calibrator Nov 10 15:59:44 maybe meta-xserver would indeed make sense Nov 10 16:00:03 cbrake: I checked http://kindle.s3.amazonaws.com/Kindle_src_4.0_1308590058.tar.gz and indeed only the tarballs are included. Nov 10 16:02:04 JaMa|Off: have you still pending patches wrt X ? Nov 10 16:03:36 Are not they required by the GPL to provide means to build the resulting image? So there should be some build scripts too? Nov 10 16:03:54 yes and patches Nov 10 16:04:53 I guess there are people already working on getting Amazon in compliance. Nov 10 16:05:08 PaulePanter: Only if it is GPL-3. Nov 10 16:05:20 pb_: Really? Nov 10 16:05:47 I guess I have to reread GPLv2 then. Nov 10 16:05:49 Yes, really. GPL-2 says you must be able to get the source, it doesn't say that you need to be given any help to do anything with it. Nov 10 16:09:41 pb_: http://gpl-violations.org/faq/sourcecode-faq.html Nov 10 16:09:48 pb_: is that strictly true? I thought even with gplv2 you need to be able to build it Nov 10 16:10:06 i.e. you can't just ship the source without makefiles, for example Nov 10 16:10:32 The question if they comply. The Makefiles/scripts are probably included in the tarballs. Nov 10 16:10:37 * CosmicPenguin thinks is it a really good bet to assume pb_ knows what he is talking about Nov 10 16:10:55 CosmicPenguin: that's why I'm asking and not disagreeing ;) Nov 10 16:11:06 bluelightning: that's true, you need to ship all the original build machinery (so you couldn't just repackage the code with all the configure scripts and makefiles taken out). Nov 10 16:11:20 But they are standard tarballs so they probably do not generate the ipk-package or provide the used compile/build options. Nov 10 16:11:23 But if they're providing something analogous to the original distribution tarballs then that's probably good enough. Nov 10 16:11:29 hi, using oe-core, I meet again a compilation problem when I increase BB_NUMBER_THREADS : http://pastebin.com/Jm1fKZru any idea which dependency could be missing in mysql & directfb ? Nov 10 16:12:46 ericben: which mysql recipe are you using? Nov 10 16:13:31 ericben hm can you paste the lines? Nov 10 16:13:50 ericben but I think to remember its a problem inside mysql self which is not parallel_make safe Nov 10 16:13:53 bluelightning: I assume the one in oe-core + meta-oe : bmeta-openembedded/meta-oe/recipes-support/mysql/mysql5_5.1.40.b Nov 10 16:14:05 woglinde: mysql has PARALLEL_MAKE = "" Nov 10 16:14:09 hm Nov 10 16:14:21 than the lines please Nov 10 16:14:28 woglinde: which lines ? Nov 10 16:14:29 which are reported faulty Nov 10 16:14:34 oops ok Nov 10 16:17:27 woglinde: http://pastebin.com/seSv7FqM seems it doesn't find some c++ headers ? Nov 10 16:18:36 right Nov 10 16:19:17 was gcc rebuild? Nov 10 16:19:24 or is this a run from scratch? Nov 10 16:19:31 woglinde: it's a run from scratch Nov 10 16:20:00 hm than check if the headers are there Nov 10 16:20:06 I know I can make it work by reducing PARALELL_TASK but I'm trying to find the root cause of the problem as I need to warm my office thus I need to use as much CPU core as possible ;-) Nov 10 16:20:18 *g* Nov 10 16:23:04 ericben: next race will probably be during do_install of kernel firmwares Nov 10 16:24:10 ant_work: you alread met this problem ? Nov 10 16:24:41 yes but no time to debug Nov 10 16:25:01 ant_work: But not with the MySQL packages? Nov 10 16:25:10 what is strange is that if I launch bitbake virtual/arm-angstrom-linux-gnueabi-gcc it builds some things which seems to mean the cross compiler is not yet finished to build Nov 10 16:25:10 never built it Nov 10 16:25:49 ericben: Did you check the headers as woglinde suggested? Nov 10 16:26:10 PaulePanter: http://pastebin.com/seSv7FqM yes they are not installed Nov 10 16:26:33 ericben than look at the dependcy chain Nov 10 16:26:38 bitbake -g Nov 10 16:26:41 woglinde: the header are not here Nov 10 16:26:44 woglinde: already done ;-) Nov 10 16:26:55 that's why I tried to build virtual/arm-angstrom-linux-gnueabi-gcc Nov 10 16:27:35 hm gcc for c++? Nov 10 16:27:36 | patch: invalid option -- 'U' Nov 10 16:27:38 hmmm Nov 10 16:27:42 anyone seen this one? Nov 10 16:27:43 ericben: Open a ticket at the Yocto bug tracker? Nov 10 16:27:49 kergoth no Nov 10 16:31:54 hmm, http://lists.debian.org/debian-printing/2011/02/msg00251.html Nov 10 16:38:46 oh, haha, its one of those cases where the stuff oe calls really shouldn't obey dotfile Nov 10 16:38:49 s Nov 10 16:39:00 my quiltrc had the patch -U option (unified format reject files) Nov 10 16:39:01 oops Nov 10 16:40:19 Is someone having trouble building today's tip? http://paste.debian.net/144500/ Nov 10 16:41:59 otavio: I'll let you know, I'm at task 1099 of 1573 currently Nov 10 16:42:08 (core-image-minimal) Nov 10 16:42:11 bluelightning: good Nov 10 16:42:33 bluelightning: but it seems to be shared-mime native Nov 10 16:43:02 otavio hm you screwed ncurses somehow? Nov 10 16:43:19 otavio: I haven't got up to building that (assuming it's needed for core-image-minimal...) Nov 10 16:43:24 woglinde: this is an autobuilder and it runned fine up to an hour ago Nov 10 16:43:41 woglinde: I just synced it against current oe-core and seems to fail somehow Nov 10 16:43:41 libtinfo is ncurses Nov 10 16:43:52 woglinde: or it lacks a depends on it Nov 10 16:43:55 so either it uses host ncurese Nov 10 16:44:16 try it out Nov 10 16:44:37 I think we still have some unseen host deps Nov 10 16:54:29 woglinde: and worse, it seem to be a parallelism issue as I built same source in my default account and it worked Nov 10 16:54:38 woglinde: so most probably a missing dep Nov 10 16:54:54 hm, is there an example I can follow where a recipe has separate packages for binaries and config files? Nov 10 16:55:42 woglinde: in fact it seems include/c++ is not in the include search path Nov 10 16:55:59 tzanger: I did it for dhcp in oe-core Nov 10 16:56:08 otavio: ok, I will take a look there Nov 10 16:56:13 I'm trying to do it for Asterisk Nov 10 16:56:39 it looks liek the recipe DOES call out the config files separately, I can comment that out for a binary package, but I'm not sure how to take the built sample configs and create a separate package for them Nov 10 16:57:50 otavio: which dhcp package did you write Nov 10 16:58:07 tzanger: oe-core, look at recipes-core/dhcp/dhcp.inc Nov 10 16:58:54 hmm, I don't see recipes-core, I see recipes only Nov 10 16:59:15 (this is angstrom, I might be in the wrong spot) Nov 10 17:01:57 I see dhcp/dhcp4.inc which seems to do something with config files that I haven't quite figured out yet Nov 10 17:16:37 * woglinde curses stupid libffi Nov 10 17:19:02 does "PACKAGES += foo bar baz" followed by FILES_foo, FILES_bar, FILES_baz and CONFFILES_foo, CONFFILES_bar, CONFFILES_baz create the three packages? Nov 10 17:19:30 and FILES_ vs CONFFILES_ tells the packager what to remove with an ipkg remove vs ipkg purge? Nov 10 17:20:56 conffiles are optional, but yes Nov 10 17:29:58 kergoth: wow that's *trivial*, very impressive Nov 10 17:37:23 tzanger: that was the idea. PACKAGES lists what packages to emit, FILES_ is a glob of the files to include. there are plenty of other vars you *can* choose to set, but they also inherit the defaults. e.g. description will pick up the main recipe's if per package isn't set Nov 10 17:37:41 I understand Nov 10 17:38:13 it looks like FILES_${PN} gets a bunch of files by default too (likely everything that is built for /bindir /sbindir etc?) Nov 10 17:38:19 * kergoth nods Nov 10 17:38:26 very slick. Nov 10 17:38:27 see bitbake.conf for the default values Nov 10 17:58:29 kergoth: when I use PACKAGES += "foo bar" and the recipe name is "foo", do the defaults for FILES_${PN} still apply? Nov 10 17:58:35 i.e. the /bindir etc Nov 10 17:58:44 will they still make it in to the foo package? Nov 10 18:00:34 it won't have any effect, foo is in packages either way Nov 10 18:00:53 do note, however, that FILES_${PN} and FILES_foo can be different. the former overwrites the latter at the end of the parse process Nov 10 18:02:33 hmm, I have a kernel recipe for a 2.6 kernel which now fails to build after migration into OE core, I assume because I updated the distro and have newer kernel headers now; is it possible to tell one partcular recipe to use older headers? I am not sure if I should try to force a downgrade of the headers, something else might need the newer ones.. Nov 10 18:03:47 actually, not kernel recipe, but a recipe for some kernel modules that are not in mailine Nov 10 18:03:52 that'd be the correct description Nov 10 18:07:06 damn, gotta leave... will reade the backlog later :P I hope someone has a hint.. Nov 10 18:18:38 hmm, ok Nov 10 18:34:41 hm Nov 10 18:35:22 I have PACKAGES += "foo-default-config" and CONFFILES_foo-default_config += a bunch of stuff, but the default_config package doesn't appear to be created Nov 10 18:35:51 bitbake -c clean foo is enough to clean out the build so I can rebuild, isn't it? Nov 10 18:43:46 it looks like foo-dbg, foo-doc, and foo-dev are automatically generated packages too Nov 10 19:10:34 tzanger: are your files getting picked up by another package? Nov 10 19:11:01 I don't think so, if I look at the foo.ipk i see the conf files there Nov 10 19:11:23 I set FILES_${PN} explicitly (copied from bitbake.conf, but removed ${sysconfdir}) and am trying that now Nov 10 19:12:10 i.e. FILES_${PN} = all the stuff from bitbake.conf, except ${sysconfdir} Nov 10 19:12:19 instead of FILES_${PN} += extra stuff Nov 10 19:16:08 I do Nov 10 19:16:18 PACKAGES =+ "${PN}-foo" Nov 10 19:16:30 FILES_${PN}-foo = "/etc/files/*" Nov 10 19:16:49 which PREPENDS PN-foo to the package list Nov 10 19:16:55 so it looks for those files first Nov 10 19:16:55 hm, I did PACKAGES += "foo-configs" (${PN} Is foo) Nov 10 19:17:07 note the prepend Nov 10 19:17:10 yes I just saw that Nov 10 19:17:31 but why does += "${PN}-configs" prepend when "foo-configs" does not? Nov 10 19:17:35 (foo is the recipe name) Nov 10 19:20:15 re Nov 10 19:28:28 anyone tried compiling meta-toolchain-qte today? I did a fresh build of everything, and end up with an SDK of ~380kB. Nov 10 19:33:27 neat ;-) Nov 10 19:33:51 probably just the busybox rm tool , as it ought tobe ;-) Nov 10 19:58:24 :) Nov 10 20:02:43 03Florian Boor  07master * r77edf34b70 10openembedded.git/recipes/libgee/libgee.inc: Nov 10 20:02:43 libgee.inc: Increment PR in order to fix decrement from previous revert. Nov 10 20:02:43 Signed-off-by: Florian Boor Nov 10 20:31:46 hm Nov 10 20:34:01 what does it mean exactly when it's saying "CONTROL/conffiles mentions conffile /etc/logrotate.d/asterisk which does not exist" ? All I did was override FILES_${PN} to *not* include ${sysconfdir} Nov 10 20:34:30 CONFFILES_${PN} *does* += the file it's erroring out over, but if I do not override FILES_${PN} It works fine Nov 10 20:35:11 and if I comment out the CONFFILES_${PN} that includes the file, it *still* errors out with the same error Nov 10 20:35:22 I finally manage to read the OE list/logs again and it takes less than two minutes for Koen to annoy me :-/ Nov 10 20:50:00 Do someone knows the Paul Menzel's nick? Nov 10 20:50:35 paulepanther Nov 10 20:50:45 PaulePanter: Hi :) Nov 10 20:51:35 PaulePanter: I got hit by your change in xinit; it added 10 packages in my image :-) Nov 10 20:52:15 PaulePanter: looking at the change, it seems it would be better to split util-linux' mcookie into a package and rdepends on that, instead of whole util-linux. Nov 10 20:56:02 otavio yes Nov 10 20:59:55 woglinde: doing that locally Nov 10 21:00:02 woglinde: will test and send a patch Nov 10 21:07:55 http://pastebin.com/u6S96BQv Nov 10 21:08:06 That's the recipe I'm trying to create a "-default-config" package for Nov 10 21:08:13 is pkg_postinst supposed to run every boot? Nov 10 21:08:31 however all the CONFFILE_${PN}-default-config files are getting included in the base package Nov 10 21:09:12 I'm assuming it's because FILES_${PN} includes ${sysconfdir}, so I tried to redefine FILES_${PN} based on the bitbake.conf default, but left out ${sysconfdir} Nov 10 21:09:51 when I do this, though, it then complains that the logrotate script is in CONTROL/conffiles mentions /etc/logrotate.d/asterisk but it doesn't exist. I'm not what it is I'm doing wrong Nov 10 21:15:01 msm: no Nov 10 21:15:16 just on first boot, and only then if it didn't run during rootfs construction Nov 10 21:15:32 right Nov 10 21:15:35 msm: wait, you said you use PACKAGES =+ (not PACKAGES +=) ?? Nov 10 21:15:35 so if its a ramdisk Nov 10 21:15:38 then every boot Nov 10 21:15:46 tzanger: one is prepend one is append Nov 10 21:15:50 god damn Nov 10 21:16:04 ah, yes, if your rootfs is non-persistent then it will run on every boot Nov 10 21:16:06 pb_: ramdisk should run everytime… something is going on Nov 10 21:16:58 the only thing I can think of is this message Nov 10 21:17:01 … /etc/udhcpc.d/50default: line 63: /etc/resolv.conf: No space left on device Nov 10 21:17:11 which is preventing alll the init stuff from running Nov 10 21:17:24 well, that's certainly not too good. if your disk is full then I guess all sorts of things will lose. Nov 10 21:17:36 sounds like you don't have any spare space allocated in your ramdisk image Nov 10 21:18:17 pb_: yes im looking for this spare space Nov 10 21:18:22 otavio: I am sorry. As written I did not test it and just noticed it when trying `startx` on the demo image. Nov 10 21:19:01 otavio: Your proposal is a good idea though, since that seems also to be done for other packages. Nov 10 21:19:26 … binaries in util-linux. Nov 10 21:19:45 IMAGE_ROOTFS_SIZE it seems Nov 10 21:20:16 probably IMAGE_ROOTFS_EXTRA_SPACE is the one you want Nov 10 21:20:39 IMAGE_ROOTFS_SIZE is the absolute size, you could set that but then you will have to keep tweaking it up and down as the amount of space taken by your binaries changes. Nov 10 21:21:50 florian: heh, yes, koen does still seem to have his unique talent for being annoying Nov 10 21:23:38 pb_: really amazing Nov 10 21:23:46 though, in this particular case, it's hard to tell whether he is being irritating in a personal capacity or whether the tsc is being institutionally annoying. I suspect probably the former but who knows. Nov 10 21:25:13 I might ave missed something but I can't imagine we have a policy that TSC needs to decide about any community layers. Nov 10 21:25:23 hms why RDEPENDS_${PN}_native = "" Nov 10 21:25:27 dont works? Nov 10 21:26:23 I remember there was a discussion about commercial ones but even for these I can't remember of a decision involving the TSC. Nov 10 21:26:35 msm: I did not see the subtle += vs =+ (and indeed, I didn't know BASH did such things) Nov 10 21:26:50 tzanger: its actually bitbake syntax Nov 10 21:27:12 florian: yeah, that's what I thought too Nov 10 21:27:26 and, practically speaking, the TSC hasn't objected the last few times we created community layers Nov 10 21:27:29 msm: ah, it's VERY similar to bash :-) Nov 10 21:27:35 right Nov 10 21:27:43 msm: sorry for not picking up on that sutble difference earlier. I bet thta will clean things up significantly Nov 10 21:28:03 e.g. meta-handheld, meta-opie, etc, and I don't think we asked their permission for those. Nov 10 21:28:21 ok so… what spawns the rpm-postinsts? i can't even find any references in /etc Nov 10 21:28:29 does the minimal image run these scripts at all by default? Nov 10 21:28:30 args virtclass Nov 10 21:29:38 oh, you're using rpm? hm, dunno, maybe nothing. Nov 10 21:29:53 I guess you'd have to check package_rpm.bbclass, see what it does. Nov 10 21:30:39 for deb/ipk there's a thing called "run-postinsts". Nov 10 21:31:25 NOTE: Not creating empty archive for asterisk-default-config-1.4.23.1-r0.6 Nov 10 21:31:34 that's much better than the error, thanks msm, I can work away at this. Nov 10 21:31:54 is bitbake smart enough to create a non-architecture-dependent archive if it doesn't contain executables? Nov 10 21:32:43 tzanger: maybe Nov 10 21:32:48 tzanger: you can specificy this also Nov 10 21:33:08 im not sure if it will work for one package in a recipe though Nov 10 21:33:10 no, it doesn't do that automatically. even for non-executables it doesn't have any way of telling whether they might have arch-dependent bits in. Nov 10 21:33:11 maybe just the whole recipe Nov 10 21:33:25 e.g. data files might be endianess-specific Nov 10 21:38:26 PaulePanter: just sent the patches Nov 10 21:39:16 hm, interesting Nov 10 21:40:05 otavio: Thanks. I will take a look. Nov 10 21:40:34 PaulePanter: nice; if possible ack them Nov 10 21:42:09 otavio: I assume you tested them? Especially tried to run `startx`? Nov 10 21:42:42 PaulePanter: I don't use startx but your fix explicitly talks about mcookie so it ought to work Nov 10 21:42:52 True. Nov 10 21:43:14 PaulePanter: if you can, test it. I am more concerned about reducing the number of packages in my image. Nov 10 21:45:58 ok - so all my rpm-postinst scripts already have ".done" appended Nov 10 21:46:06 how do I say, this postinst is not done? Nov 10 21:46:11 exit 0/1? Nov 10 21:50:39 is it possible to dump the various variables with bitbake? Nov 10 21:52:38 to answer my own question - you need an exit 0 for it to ever run on the target Nov 10 21:55:14 dammit Nov 10 21:55:31 prepend or append, it still ends up thinking it'll create an empty package Nov 10 21:56:02 msm: is my idea of redefining FILES_${PN} to not include ${sysconfdir} flawed in some way? Nov 10 21:57:41 does another package use sysconfdir in FILES_ Nov 10 21:57:42 ? Nov 10 21:58:09 msm: the bitbake default FILES_${PN} includes ${sysconfdir} Nov 10 21:58:21 as it should. there are plenty of recipes that'd be useless without it Nov 10 21:58:25 I agree Nov 10 21:58:39 tzanger: did you install your files properly in the do_install step Nov 10 21:58:39 ? Nov 10 21:58:44 I'm trying to figure out how to pull the /etc/asterisk/* directory OUT of the default asterisk package Nov 10 21:59:04 it's worth noting that order of packages in PACKAGES is important. the first package to match a file will get it. so if you want to steal something from the main package, prepend it to PACKAGES, rather than appending it Nov 10 21:59:08 iirc anyway Nov 10 21:59:13 kergoth: that's what i told him Nov 10 21:59:23 kergoth: about using PACKAGE =+ instead of PACKAGE += Nov 10 21:59:27 * kergoth nods Nov 10 21:59:30 kergoth: I tried both with PACKAGE += and PACKAGE =+ Nov 10 21:59:34 * kergoth just jumped in, haven't read the full scrollback Nov 10 21:59:40 they both generate an empty package where the configs should be Nov 10 21:59:59 tzanger: well, if you prepend then its not the FILES_${PN} that's the problem, as msm says, make sure other things are happening as they should Nov 10 22:00:05 verify the files exist in the image/ dir in workdir Nov 10 22:00:33 kergoth: http://pastebin.com/u6S96BQv is the recipe in question Nov 10 22:00:42 ok, I'll check Nov 10 22:00:47 I appreciate the assitance, thank you both Nov 10 22:00:58 tzanger: you did FILES_${PN}-configs += /etc/* Nov 10 22:01:11 PACKAGES =+ "${PN}-configs" Nov 10 22:02:16 moment Nov 10 22:02:44 msm: line 95 was both += and =+ with the same results Nov 10 22:03:35 tzanger: im not sure Nov 10 22:03:58 is foo-package-with-lots-of-dashes a problem? Nov 10 22:04:26 nope Nov 10 22:10:09 hm okay Nov 10 22:10:42 rebuilding so I can check the build (I -c clean'd before you wrote that) Nov 10 22:13:29 the base package has the /etc/asterisk directory I am trying to pull in to the config package Nov 10 22:14:09 there's an image/etc/asterisk Nov 10 22:14:52 re Nov 10 22:18:26 is there any way to dump the variable states? Nov 10 22:18:29 er values Nov 10 22:20:04 bitbake -e.. Nov 10 22:20:25 i use it every single day to check things, verify sanity, etc Nov 10 22:20:50 so bitbake mypackage -e ? Nov 10 22:21:33 bitbake -e alone will dump the global config metadata Nov 10 22:21:38 bitbake -e will dump its metadata Nov 10 22:21:44 pretty sure this is in --help Nov 10 22:22:14 whoa, that's a lot of data Nov 10 22:23:00 good nite Nov 10 22:24:55 there's a lot of metadata to dump, yes Nov 10 22:29:46 # CONFFILES_${PN}-defconfig=None Nov 10 22:29:52 interesting, that doesn't seem right Nov 10 22:30:40 CONFFILES_asterisk-defconfig="/etc/*" Nov 10 22:30:45 that looks right Nov 10 22:31:00 I'd prefer /etc/asterisk/* but I set /etc/* for now to test Nov 10 22:31:25 the packages order looks good Nov 10 22:35:59 hm Nov 10 22:38:40 FILES_asterisk shows /etc. CONFFILES_asterisk-defconfig shows /etc/*... Nov 10 22:38:53 in that case, who wins? the first package? Nov 10 22:38:57 conffiles is not files. Nov 10 22:39:01 conffiles doesn't maek things go into the package Nov 10 22:39:08 conffiles marks files that already go into the package as configuration files Nov 10 22:39:16 you still need to include them in the files var Nov 10 22:40:12 AHA Nov 10 22:40:20 I didn't realize that Nov 10 22:40:33 so FILES_${PN}-defconfig must ALSO show the files Nov 10 22:40:57 CONFFILES_${PN}-defconfig marks files that are ALREADY in FILES_${PN}-defconfig as conf files Nov 10 22:41:20 yep Nov 10 22:41:49 conffiles doesn't affect oe's packaging process at all, actually, it just gets emitted as one of the variables in the ipk file it produces, so opkg or whatever else uses that info, not oe itself Nov 10 22:42:07 I understand now Nov 10 22:42:09 thank you so much Nov 10 22:42:32 np Nov 10 22:44:01 if I was a smarter person, where may I have found this in the documentation? oftentimes I can't find things through google because I don't have the magic search terms Nov 10 22:45:09 OE's a HUGE system and little things like this I find are learned through experience most times Nov 10 22:46:53 I think one of its biggest problems is the lack of discoverability Nov 10 22:47:09 you mean like discovering this thing you just showed me? :-) Nov 10 22:47:11 i can't sit down and ask it, what can i build, what vars are useful to set, what recipes will give me this package, what depends on this, what ... Nov 10 22:47:21 understood Nov 10 22:47:38 which is unfortunate, as a lot of people would rather be able to do that than dig through docs Nov 10 22:47:54 documentation is a double-edged sword Nov 10 22:48:05 if you write it, people try to understand it, and that often results in bigger problems Nov 10 22:52:53 after I used ${sysconfdir}/asterisk/* instead of ${sysconfdir}/asterisk, things are working. I have a default config package now Nov 10 22:53:11 very much appreciated, you and msm both, thank you Nov 10 23:05:33 hm, what is a virtual package I can reference for my own? Nov 10 23:05:51 there's lots of mention of virtual/kernel but I don't see a kernel.bb nor a virtual directory in the recipes directory Nov 10 23:06:40 virtuals aren't magic. Nov 10 23:06:46 its just a recipe that has virtual/kernel in its PROVIDES Nov 10 23:06:47 that's it Nov 10 23:07:04 by default recipes provides their ${PN}, but you can add any number of things, then something else can depend on those things Nov 10 23:07:07 nothing to it Nov 10 23:08:16 I know they're not magic, just trying to figure out how to do it. I was looking for a file instead of the contents of a file. that was it it seems Nov 10 23:09:16 it would look like I need to rename the asterisk package to asterisk-binaries and set the recipe to say it provides virtual/asterisk Nov 10 23:09:38 then figure out how to tell the system that virtual/asterisk depends on asterisk-binaries and asterisk-default-config Nov 10 23:09:57 slowly it's starting to make sense Nov 10 23:10:00 also note that you can add to provides, or rprovides_, the runtime analogue to this, so the choice/preference would need to be expressed at install time rather than build time Nov 10 23:10:38 hmm Nov 10 23:11:22 sounds like I would want virtual/asterisk to rdepend on virtual/asterisk-config. then asterisk-default-config provides virtual/asterisk-config and my custom asterisk config file package would also provide the same Nov 10 23:12:00 the virtual/ prefix is specific to build time / oe bits. if you're going to mess with runtime, drop the prefix, just have a unique name Nov 10 23:12:02 I think... does that sound like a correct way to have a default set of configs installed by default but then allow a different config pacage to supersede the default? Nov 10 23:12:21 that sort of thing seems reasonable to me, yes Nov 10 23:12:32 ok Nov 10 23:12:41 then I need to contact the maintainer with my patches. :-) Nov 10 23:13:25 we have maintainers? what? ;) Nov 10 23:13:29 hahahaha Nov 10 23:13:30 crazy talk Nov 10 23:13:42 no, no, I see what you're trying to do there Nov 10 23:13:48 you're not going to make me the maintainer Nov 10 23:14:08 * kergoth is really rather irritated that we don't have enough recipe maintainers and individual responsibility for particular recipes quality Nov 10 23:14:12 someday.. Nov 10 23:14:41 all in good time. I am planning on creating asterisk-1.8 recipes which I will likely have to mantain Nov 10 23:14:44 maintain Nov 10 23:14:51 * kergoth tries building a crosstool-ng toolchain to see about making an external toolchain recipe for it Nov 10 23:16:54 that sounds like waaaaaay more pain than what I just learned Nov 10 23:31:48 I'm having a great deal of difficult with this virtual thing, I looked at linux and gcc, I don't see a PROVIDES or DEPENDS/RDEPENDS that seems to do what does make sense Nov 10 23:32:01 actually only a very few kernel recipes use it Nov 10 23:33:02 tzanger: you'd make a great maintainer, I vote yes for tzanger! Nov 10 23:33:45 oh shit who let him in here Nov 10 23:34:33 i lurk here eternally Nov 10 23:34:44 tzanger: line 3 of kernel.bbclass. Nov 10 23:34:51 whoa a bbclass? Nov 10 23:35:13 yes, it handles the majority of the work in building the kernel Nov 10 23:35:30 see also module.bbclass for external modules Nov 10 23:35:38 looking, thanks Nov 10 23:39:39 tzanger: time for a waterloo oe users group ;) Nov 10 23:39:50 you chairing it? I'm still a newb. Nov 10 23:40:35 although aircell's using it for their device, which is why I'm learning it Nov 10 23:40:40 only if the chair gets free beer Nov 10 23:42:05 I thought the chair had to provide it Nov 10 23:43:44 then I'm out Nov 10 23:44:06 heh Nov 10 23:44:34 god, we build way too much crap. even just to build busybox the amount of tasks it has to run is disgusting. we need to do something about this Nov 10 23:44:40 * kergoth mutters Nov 10 23:51:52 kergoth: due to dependencies? Nov 10 23:51:57 aye Nov 10 23:52:11 there's good reason for them, to ensure we're using known sane things, but it's still irritating Nov 10 23:52:29 no doubt Nov 10 23:53:07 sanity is good for users though, for others, there's always -b Nov 10 23:55:59 I still like the idea of providing a chroot/VM that's a sane env we can rely on Nov 11 00:01:30 that doesn't sound unreasonable Nov 11 00:05:50 -b? Nov 11 00:07:16 hm, sounds like -b would not be a good thing Nov 11 00:07:53 actually, wmat, you're documenter extraordinaire Nov 11 00:08:06 lies, damn lies Nov 11 00:08:06 Y U NO DOCUMENT CONFFILES VS FILES ALREADY?! Nov 11 00:08:35 actually, oe and bitbabe documentation is on my todo list Nov 11 00:08:43 heh, bitbabe, oops Nov 11 00:08:46 19:07 < wmat> lies, damn lies Nov 11 00:08:52 that's what I say to that comment Nov 11 00:09:07 tzanger: as part of dayjob Nov 11 00:10:08 ASSUME_PROVIDED can be useful too, of course its not always safe, you have to know what you're doing Nov 11 00:10:47 https://gist.github.com/869616 Nov 11 00:11:20 well I definitely don't Nov 11 00:11:26 not related, but I use that and https://gist.github.com/776390 as well in my ~/.oe, loaded by my ~/.oe/conf/site.conf Nov 11 00:50:16 how do classes work, I'm having trouble finding docu on them as well Nov 11 00:50:35 does a recipe with the same name automatically get the class applied to it? Nov 11 00:51:19 the only class that's automatically loaded, ever, is base. Nov 11 00:51:28 canadian class? hhaha Nov 11 00:51:31 grep -rw inherit oe-core Nov 11 00:51:47 yes, canadian cross is the terminology used to refer to a particular type of crosscompiler Nov 11 00:51:58 e.g. building an arm->i686 crosscompiler from your x86_64 box Nov 11 00:51:59 I remember reading about it somewhere Nov 11 00:52:01 http://en.wikipedia.org/wiki/Cross_compiler#Canadian_Cross Nov 11 00:52:11 built not only *for* something else, but to run *on* something else as well Nov 11 00:52:21 ah yes, didn't realize it was on wikipedia, good call Nov 11 00:52:44 right, understood Nov 11 00:53:29 classes only loaded via two mechanisms. a recipe or class can do 'inherit' followed by a space separated list of classes, or they can be added to the INHERIT variable for bits that you want to be globally available Nov 11 00:53:38 things like rm_work go in INHERIT, whereas things like autotools are pulled in via inherit Nov 11 00:53:43 two different use cases Nov 11 00:54:21 hm, so how does the linux-kernel-base.bbclass get used, for example... I don't see anything in any recipe that references it Nov 11 00:54:40 hm, maybe it's up higher than recipes Nov 11 00:54:55 kernel.bbclass inherits from it Nov 11 00:55:04 hm, only conf/machine/netbook-pro references it Nov 11 00:55:17 oh classes inherit other classes too Nov 11 00:55:20 lots of grepping Nov 11 00:56:15 I remember trying to generate a dependency graph and it quickly became unwieldy Nov 11 01:01:11 you really should read hte metadata more closely. classes are the exact same file format as recipes, no difference at all. inherit/require/include can be used anywhere **** ENDING LOGGING AT Fri Nov 11 02:59:57 2011