**** BEGIN LOGGING AT Fri Dec 23 02:59:56 2005 Dec 23 03:47:46 i ran a bad block count test on my z falsh yesturday, and found 3. Does anythign take these into account and avoid using them, or will i hve problems with corupted data from now on? Dec 23 04:03:40 03koen 07org.oe.oz354fam083 * r0091680b... 10/conf/machine/h2200.conf: h2200: RRECOMMEND kernel modules Dec 23 04:03:45 03koen 07org.oe.dev * r4580f887... 10/conf/machine/h2200.conf: h2200: RRECOMMEND kernel modules Dec 23 04:03:49 03koen 07org.oe.dev * r8a71e516... 10/conf/distro/preferred-gpe-versions-2.7.inc: gpe 2.7: prefer gpe-conf 0.1.27 Dec 23 04:03:55 good morning all Dec 23 04:07:47 morning koen Dec 23 04:16:13 morning folks Dec 23 04:16:35 morning mickeyl Dec 23 04:17:14 hey mickeyl Dec 23 04:28:53 dan2003: The nand driver should take care of it Dec 23 04:29:06 hi koen, lrg and mickeyl Dec 23 04:30:04 lrg: Did you see XorA's comment about the amp suspending on corgi? If all the codec is powered down, will the machine controls get powered down? Dec 23 04:30:18 If not, we can probably ask scoop to handle this Dec 23 04:30:38 it already does for cxx00 but not c7x0 iirc Dec 23 04:34:11 RP: it's designed to power up/down external components. i've probably left it out by ommision. Dec 23 04:34:27 RP: should it be in corgi ? Dec 23 04:35:12 lrg: Yes, the APM scoop control needs to be powered down when not in use Dec 23 04:35:24 ok, I'll have a look Dec 23 04:47:53 zecke: svn fetcher bug is #554 - patch attached to fix it Dec 23 04:51:10 morning Dec 23 04:51:15 hi reenoo_ Dec 23 04:51:43 hey RP Dec 23 05:07:44 any ideas what bvdd is as my .jp is nonexistent, it seems to be some kernel 2.4 and not 2.6 , any pointers? Dec 23 05:08:11 iirc it's an overlay interface for pxafb Dec 23 05:08:38 yes, accelerates video slighty by using overlays Dec 23 05:10:32 do we have source, or is it like aticore? Dec 23 05:22:27 koen: We have source. Its very simple though just supporting overlays Dec 23 05:22:37 aitcore is a compelte 2D acceleration engine Dec 23 05:40:36 * reenoo_ heads off for some soldering Dec 23 05:42:23 hmm found some stuff on overlays for 2.6 on intels site patches for 2.6.9 for loads of other bits too Dec 23 05:42:48 doesn't look like much has hit the mainline kernel though :( Dec 23 05:44:09 ade|desk: What kind of bits? Dec 23 05:44:31 ftp://ftp.arm.linux.org.uk/pub/armlinux/people/xscale/mainstone/01-27-2005/src/kernel/patch-2.6.9-intc1 Dec 23 05:44:33 and waht kind of code quality? Dec 23 05:45:34 ah, a cpufreq driver :) Dec 23 05:46:49 ftp://ftp.arm.linux.org.uk/pub/armlinux/people/xscale/mainstone/01-27-2005/README.txt Dec 23 05:47:10 its the 14th bit that interesting Dec 23 05:52:51 hey guys... Dec 23 05:52:57 hey Spyro Dec 23 05:53:07 I want to select a specific version of konq-embedded Dec 23 05:53:34 I set PREFERRED_VERSION_konqueror-embedded = "0.0cvs20050322" Dec 23 05:53:34 in local.conf Dec 23 05:55:14 hi Dec 23 05:55:20 its still building the older 2003 rev though Dec 23 05:55:23 hi mardy Dec 23 05:57:32 Spyro: You might need to set CVSDATE_konqueror-embedded Dec 23 05:57:57 Spyro: and check your bitbake it uptodate as there were issues when both of these were set in older bitbakes Dec 23 06:01:26 older meaning older than 2 days ? Dec 23 06:01:58 I dont need to specify PREFERRED_VERSION_konqueror-embedded-snapshot = "0.0cvs20050322" Dec 23 06:02:01 do i? Dec 23 06:03:05 Spyro: not newer than 2 days, no Dec 23 06:03:26 Spyro: that would depend on the PN of the package... Dec 23 06:04:21 PN ? Dec 23 06:04:54 Package Name - comes from the .bb filename but can be redefined Dec 23 06:05:15 bitbake knows it as $PN Dec 23 06:05:46 ok Dec 23 06:06:08 what becvame of the C verson of bb that was mooted ? Dec 23 06:06:56 nobody has had time to work on it Dec 23 06:07:01 shame Dec 23 08:32:20 RP: what does mmc0: unrecognized SCR structure version 1 mean ? Dec 23 08:34:18 ade|desk: It means we need 2.6.15-rc6 ;-) Dec 23 08:34:32 I also have a fix for the akita backlight resume bug Dec 23 08:34:34 heh Dec 23 08:36:15 RP: souds good Dec 23 08:37:36 RP: whats in rc6 thats so good then ? Dec 23 08:37:47 ade|desk: a fix for the SCR problem Dec 23 08:38:02 I believe - try looking at the changelog as I think its mentioned Dec 23 08:39:11 [MMC] Proper check of SCR error code Dec 23 08:39:40 how much of your code does rc6 break ? Dec 23 08:40:31 ade|desk: Its not a big diff - very little should break Dec 23 08:40:37 I'll do a release soon Dec 23 08:40:59 :) sounds damn good to me Dec 23 08:41:24 The bigger problem is the mmc driver is dead after a suspend/resume :-/ Dec 23 08:42:04 ok that sucks Dec 23 08:42:59 Do we have a c7x0 user seeing that problem? Dec 23 08:43:07 I wonder if its cxx00 specific... Dec 23 08:44:44 sorry can only test c100 Dec 23 08:44:46 +0 Dec 23 08:45:00 RP: is there a way to download patches from RMKs tracker? Dec 23 08:45:15 koen: no, cut and paste I'm afraid :-/ Dec 23 08:45:21 crapzilla Dec 23 08:45:27 AFAIK anyway Dec 23 08:45:36 ok Dec 23 08:45:43 time to c/p 13 patches Dec 23 08:47:14 Right - suspend/resume mmc lockup is cxx00 only Dec 23 08:47:31 which makes it highly likely my code it at fault :) Dec 23 08:47:47 bad Rp , naughty RP , slap Dec 23 08:48:34 can you tell its 2 hours away from christmas hols yet ? Dec 23 08:49:13 yes, same test on spitz locks it up :) Dec 23 08:49:26 ah well, that gives s good clue as to what the problem is :) Dec 23 08:49:47 * RP suspects the horrible cxx00 sd/cf combined power code Dec 23 08:49:55 you mean you let the elves in Dec 23 08:50:33 At least I can reproduce it... Dec 23 08:51:12 promising Dec 23 08:52:23 3208/1  Overlay 1 and 2 support for the Intel PXA27x (part 1 of 2) 2.6.15-rc5-git5  15 Dec 2005 18:53:47  Dec 23 08:52:45 was just look at that stuff from intels site, lol Dec 23 08:54:49 damn Dec 23 08:54:54 that wouldn't work on the hx Dec 23 08:55:00 stupid ati w3220 Dec 23 08:55:36 koen: but the ati i probably a better 2d accel no ? Dec 23 08:55:42 s/i/is Dec 23 08:55:44 probably Dec 23 08:56:14 let's hope the 2.6 aticore stuff will be finished soon Dec 23 08:56:21 indeed Dec 23 08:56:57 koen: aticore might not run with the w3220 Dec 23 08:57:07 we can only guess the differences between the w100 and w3220 Dec 23 08:57:08 hmm only patch 1 of 2 , wonder where 2 of 2 i s Dec 23 08:57:30 RP: too bad Dec 23 08:58:15 ~lart nvidia for removing mediaq docs Dec 23 08:58:15 * ibot executes killall -HUP nvidia for removing mediaq docs Dec 23 09:04:43 mickeyl: Merry & blessed Christmas ! Dec 23 09:07:39 RP: the eabi patches still apply to rc6 Dec 23 09:17:54 * koen hopes someone will get eabi working in the holidays Dec 23 09:18:47 koen: Is that a hint? :) Dec 23 09:19:26 if you want it to be ;) Dec 23 09:19:56 * koen waits for the kernel upload to complete Dec 23 09:25:47 koen: I'm tempted to apply those patches to the oz kernel :) Dec 23 09:26:22 that was my plan too *after* &*(&^(#%# glibc has been built Dec 23 09:26:52 you'd probably want 3108 - 3112 and 3204 too Dec 23 09:27:11 Can anyone else see the really neat simplification of OE's dependencies with what I'm proposing on oe@hh.org or am I just imagining things... Dec 23 09:27:59 you're proposing something what resembles how familiar handled it in the past Dec 23 09:28:47 I mean removing the DEPENDS >= RDEPENDS constraint and having bitbake's build list = DEPENDS+RDEPENDS+RRECOMENDS Dec 23 09:30:17 that won't work Dec 23 09:30:25 due to that ugly python mess Dec 23 09:30:52 I'm not saying its easy... Dec 23 09:30:56 but if we make a plan... Dec 23 09:30:58 R* stuff in only known at packaging time Dec 23 09:31:17 and with debian shlib renaming it will be even harder Dec 23 09:31:44 it actually is a non-problem Dec 23 09:31:57 since R* is *always* a subset of DEPENDS Dec 23 09:32:17 Its not Dec 23 09:32:32 it should be Dec 23 09:32:54 It OE as it stands it is but it doesn't have to be Dec 23 09:33:23 a hotplug script does not need virtual/hotplug to build but it is a runtime dependency Dec 23 09:33:57 <[lala_]> if a .bb file produces several packages - how can R* always be a subset? take glibc package as an example Dec 23 09:34:31 RP what about http://handhelds.org/hypermail/oe/51/5113.html ? Dec 23 09:35:25 koen: The duplicate information for DEPENDS and RDEPENDS just looks and feels wrong and worst still makes things break easily Dec 23 09:40:03 kergoth: As someone who was probably involved with this in the depths of time, was the overlap between DEPENDS and REDEPENDS intentional? Dec 23 09:48:46 RP: RDEPENDS was invented to cope with stuff shlibs doesn't pick up (among other stuff) Dec 23 09:49:13 it is for package managers, not for building Dec 23 09:49:47 koen: using it for building as well would make more sense than the current postion though... Dec 23 09:50:03 why should it? Dec 23 09:50:12 it should always be a subset of DEPENDS Dec 23 09:50:59 if OE was a 'build one package at a time' sort of thing you would be right with your hotplug example Dec 23 09:51:24 but OE is 'give me everything I need' kind of thing Dec 23 09:54:52 It applies even more when building multiple packages rather than the other way around... Dec 23 09:56:11 You want a seperate list of 'not needed for building, but needed on runtime'-stuff? Dec 23 09:56:48 koen: A mutli threaded bitbake would find that useful Dec 23 09:57:11 and I think the duplication of data is plain wrong Dec 23 09:57:21 that would be usefull, but that's not what RDEPENDS is about Dec 23 09:57:34 but can it be used for that? Dec 23 09:57:52 not cleanly Dec 23 09:57:57 why not? Dec 23 09:58:26 interpreted languages, xml files used for compilation and runtime, etc Dec 23 09:58:48 you've lost me... Dec 23 09:59:35 if something is used at both build and runtime it can go in both... Dec 23 09:59:50 correct Dec 23 10:00:31 but some things aren't and we have no way to handle that Dec 23 10:01:16 if the result worth the trouble of implementing that? (if it is even possible) Dec 23 10:02:11 s/if/is/ Dec 23 10:03:56 and will it confuse people even more? Dec 23 10:10:20 It means you no longer need to set both DEPENDS and RDEPENDS to match Dec 23 10:10:44 I think the simplification would be worth it Dec 23 10:12:41 although DEPENDS and RDEPENDS happen to sometimes contain the same elements, they can be entirely disjoint sets and there's no known correlation between the two Dec 23 10:14:30 reenoo_: Despite the fact DEPENDS >= RDEPENDS ? Dec 23 10:14:49 I know the names can be different for subpackages and that is a problem we'd need to solve Dec 23 10:18:22 we need to solve a hell lot of problems Dec 23 10:18:46 let's do one thing after another and get the task-bootstrap split done first Dec 23 10:19:22 it's not that difficult to grok how dependencies work in OE after all Dec 23 10:30:26 RP: eh? Imposing some foolish arbitrary limitation on subpackage naming because you don't want to have duplicate data is just plain wrong. Dec 23 10:35:01 kergoth: its not the duplicate data that bothers me in that case - its the inability to work out which packages provide a given subpackage Dec 23 10:35:31 what are you talking about? Dec 23 10:35:40 hiya kergoth Dec 23 10:36:00 it's surprisingly warm here :) Dec 23 10:36:43 kergoth: Can bitbake work out which PN's might provide kernel-modules-hostap ? Dec 23 10:37:04 why? Dec 23 10:37:40 You're now going to tell me I don't need to know about that :) Dec 23 10:37:48 My point is it can't Dec 23 10:37:51 i'm just trying to figure out what you're trying to do Dec 23 10:38:01 you're spouting nonsense about RDEPENDS and DEPENDS as though they dont need to be seperate, when they do Dec 23 10:38:09 so lets back up a step, what exactly are you trying to do adn why? Dec 23 10:38:18 There are several things here that bother me, all interconnected Dec 23 10:39:06 One conern is we have no way of specifying runtime dependencies without making them build dependencies as well Dec 23 10:39:21 uh? Dec 23 10:39:48 DEPENDS must contain everything in RDEPENDS Dec 23 10:39:52 so I'm told Dec 23 10:39:56 no, that is not the case. Dec 23 10:40:29 Well, all packages/subpackages in RDEPENDS must be listed in RDEPENDS Dec 23 10:40:35 what? Dec 23 10:40:48 Well, all packages/subpackages in RDEPENDS must be listed in DEPENDS Dec 23 10:40:57 according to what I keep getting told... Dec 23 10:41:31 RDEPENDS is _only_ used by packaging. DEPENDS is not. Dec 23 10:41:41 i can use oe and bitbake without packaging anything at all. Dec 23 10:41:47 right Dec 23 10:42:31 My point is that it might be better to have oe and bitbake using DEPENDS and RDEPENDS to work out the buildlist Dec 23 10:43:03 you're assuming that the packages you're building are going to be used in an oe built root filesystem. there's no guarantee of that. Dec 23 10:43:38 but i still dont see what you're proposing Dec 23 10:43:40 "buildlist"? Dec 23 10:44:07 it sounds like you're proposing imposing a limitation on the system. making bitbake add the packages that provide the elements in RDEPENDS to DEPENDS Dec 23 10:44:19 What I'm proposing doesn't change anything in the built packages so I don't understand you point either... Dec 23 10:44:48 bitbake produces a list of packages to build - correct? Dec 23 10:44:51 you're about to make it impossible for me to emit packages that RDEPEND on things that arent provided in the oe package metadata. Dec 23 10:45:23 That is a valid point Dec 23 10:45:58 and probably what ASSUME_PROVIDED though? Dec 23 10:46:13 ASSUME_PROVIDED is _build_ package names, not _runtime_ Dec 23 10:46:20 DEPENDS, not RDEPENDS Dec 23 10:46:55 At the moment, you can't have a package that has a RDEPEND that isn't in its DEPEND Dec 23 10:46:57 honestly i dont see the point. you're proposing imposing a limitation on the system, or adding variables to get around your imposed limitation, and gaining precisely nothing. Dec 23 10:47:01 or so I keep getting told Dec 23 10:47:26 I'm just not explaining it well :-( Dec 23 10:47:27 what makes you think that? of course you can, just the binary packages your emitted binary packages depend on, then wont be built by the time you build an image. Dec 23 10:47:34 but no one is forcing people to build images anyway Dec 23 10:47:44 and 99% of the time, RDEPENDS is populated automatically Dec 23 10:48:05 I've been asked to revert changes that have RDEPENDS that aren't in DEPENDS Dec 23 10:48:41 Having RDEPENDS that aren't in DEPENDS really messed up image generation Dec 23 10:48:48 because they want to ensure that those rdepends have been built by the time you're creating an image Dec 23 10:48:49 right Dec 23 10:48:53 stop assuming people have to build images. Dec 23 10:49:03 stop making assumptions about people's use of oe and bitbake in general Dec 23 10:49:22 I'm not - others are and are telling me to stick to their assumptions Dec 23 10:49:37 I don't want DEPENDS >= RDEPENDS Dec 23 10:49:50 so we're actually on the same side here :) Dec 23 10:50:21 The question becomes can be make bitbake resolve both DEPENDS and RDEPENDS for images? Dec 23 10:51:01 you mean.. look at the rdepends of all the packages we're about to install, go determine what packages provide them, then build them? Dec 23 10:51:15 yes Dec 23 10:51:20 thats a good idea, and would solve it. DEPENDS would then be what it was originally designed for, proper _BUILD_ dependencies Dec 23 10:51:25 only that which is needed to build the package Dec 23 10:51:33 This is what I want to achieve Dec 23 10:51:44 Everyone else is telling me I'm mad Dec 23 10:51:50 okay, i agree, guess we just had a communications breakdown there, i didnt understand your intent Dec 23 10:52:02 heh Dec 23 10:52:25 Every time someone says that I hear Led Zeppelin in my head Dec 23 10:53:56 DEPENDS should contain _that which your package needs to build_ only. it sounds like people are polluting it Dec 23 10:54:14 Its being badly abused Dec 23 10:54:34 and people are saying the pollution is the correct behaviour as it fixes image generation Dec 23 10:54:59 yeah, that's completely bogus. Dec 23 10:55:31 Could you post that to oe@hh.org please :) Dec 23 10:55:38 that has more to do with some packages having wrong/missing depends isnt it? Dec 23 10:55:39 they're not only fixing it wrong, they're ruining the integrity of the metadata based on an assumption Dec 23 10:55:50 can do Dec 23 10:55:55 kergoth: Yes, which is why I want to try and fix this Dec 23 10:56:31 Its been bugging me a lot but nobody will listen to me :) Dec 23 10:56:42 They might listen to your second opinion though.... Dec 23 10:56:59 is there an existing thread, or should i just start ranting? :) Dec 23 10:57:17 start a new one :) Dec 23 10:57:26 The existing ones are confused Dec 23 11:05:05 I'm being called away now :-( Dec 23 11:05:11 RP: whats your email addy? gonna cc you on the mail so you can read it sooner Dec 23 11:05:13 k Dec 23 11:05:27 kergoth: rpurdie@rpsys.net Dec 23 11:05:50 heh Dec 23 11:05:55 sent. Dec 23 11:06:04 reenoo_: You might want to read the above Dec 23 11:06:10 nobody ever said it would not be nice if DEPENDS could be just build dependencies. unfortunately that currently breaks image generation. if you have a fix for that people will be happy to use that I would think Dec 23 11:06:36 reenoo_: That doesn't make breaking the metadata right Dec 23 11:06:52 the problem is, you're ruining the integrity of the metadata. if at some point we do fix it correctly, now its going to take a huge amount of effort to recover the lost information. Dec 23 11:07:41 well. DEPENDS has been used this way ever since I joined the project Dec 23 11:07:58 2.5 years ago Dec 23 11:08:09 (IIRC) Dec 23 11:08:25 kergoth: I think you can see the scale of this problem :-( Dec 23 11:08:34 * kergoth sighs Dec 23 11:08:54 anyhow I really must go - the mail gives me something to try and move this forward with. kergoth: thanks Dec 23 11:09:09 no problem, sorry i misunderstood at first Dec 23 11:09:12 later RP Dec 23 11:10:10 i should pull down oe, havent played with it in ages Dec 23 11:14:10 so, how are you going to resolve RDEPENDS on automatically named packages? Dec 23 11:15:43 s/resolve/determine DEPENDS from/ Dec 23 11:16:22 i see a few possibilities. list the original package names in the image's variable, then let it scan PACKAGES for those, then finally run the name mangling on them itself to deteremine the names to actually install with ipkg Dec 23 11:16:51 or.. well i've been out of it too long to say the other off the top of my head Dec 23 11:17:14 but better to take the time to do it properly than to let this continue as is Dec 23 11:19:02 hmm. might work Dec 23 11:19:40 i.e. something like RDEPENDS = "gst-plugins:gst-plugin-mad" Dec 23 11:20:28 and now make it work with and without debian lib renaming Dec 23 11:20:35 .. Dec 23 11:20:39 thats what i was just talking about, actually. Dec 23 11:20:53 and python-crap to autogenerate subpackages Dec 23 11:21:17 koen: all that ends up in PACKAGES eventually, doesnt it? Dec 23 11:21:33 the image creator just scans the metadata for .bb's whose PACKAGES list the elements we want in the image. Dec 23 11:21:34 eventually, yes Dec 23 11:21:36 right Dec 23 11:21:48 that won't work Dec 23 11:22:13 how so? Dec 23 11:22:17 PACKAGES is generated *after* do_build() Dec 23 11:22:26 what? Dec 23 11:22:46 no, it isnt. do_package is a dependency of do_build Dec 23 11:23:01 unless you guys completely changed things while i was gone Dec 23 11:23:46 s/do_build/do_compile/ sorry Dec 23 11:24:34 the problem being that you have to compile the package first before you know how PACKAGES will look like Dec 23 11:24:43 and? Dec 23 11:24:47 hmm Dec 23 11:24:49 i see what you mean Dec 23 11:24:56 * kergoth ponders Dec 23 11:25:26 wait, give me an example of a package whose PACKAGES isnt determined until after compilation Dec 23 11:25:41 gst-plugins or gnumeric iirc Dec 23 11:25:55 and glibc localedata Dec 23 11:27:50 i'm not even sure where to start in describing the issues with that. sigh. Dec 23 11:27:50 kergoth: http://handhelds.org/hypermail/oe/51/5120.html Dec 23 11:28:37 DEPENDS is not a "lets shovel everything i need to install the packages" variable Dec 23 11:28:44 DEPENDS doesnt even assume you're emitting packages at all. Dec 23 11:31:29 koen: debian library renaming is taken care of by our shlibdeps code btw Dec 23 11:31:48 apart from -dev packages IIRC Dec 23 11:32:01 maybe itd be best to just rework our DEPENDS variables somewhat. currently we're destroying the build dependency information. Dec 23 11:36:21 well. the actual problem is that OE currently doesn't evaluate manually setRDEPENDS at all Dec 23 11:36:35 evaluate? Dec 23 11:37:02 it just copies that stuff into the package control file and has ipkg do the rest Dec 23 11:37:35 which is as it should be. RDEPENDS is runtime. when you build a package in .oe, you're building that package and what was necessary to build that package. not what was necessary to run that package. Dec 23 11:37:52 until you want to build an image Dec 23 11:40:06 anyways Dec 23 11:40:13 * reenoo_ heads off for more soldering Dec 23 11:40:17 again, the intent was for DEPENDS to hold build dependency information, not everything you need to run it. and hardcoding the name of one (of possibly many) packages that can emit the runtime ones you need Dec 23 11:40:19 seems wrong Dec 23 11:40:30 * kergoth shrugs Dec 23 11:41:23 of course the current (ab)use of DEPENDS is wrong Dec 23 11:42:51 but until someone teaches OE to build images with DEPENDS being build depends only you would break image generation Dec 23 11:43:14 which is what I've told RP before Dec 23 11:44:05 if you're aware of the problem, why do you continue to ruin the integrity of the metadata? this shouldve been dealt with a long time ago. Dec 23 11:45:16 even a hackish solution wouldve worked just to ensure that you arent losing information. DEPENDS = "foo $(BDEPENDS)" or something. seperate the real, actual build deps from the runtime crap. Dec 23 11:45:47 I rarely get to working on OE these days due to university and work stuff Dec 23 11:45:59 * kergoth nods Dec 23 11:46:53 whenever I do spend time on OE I try to keep things in a status quo way working Dec 23 11:47:06 I just can't fix any issues in the core these days Dec 23 11:51:32 I mean.. in a perfect world I would have fixed out-of-tree kernel module dependency handling, done the task-bootstrap split and rewritten ipkg ages ago >:) Dec 23 11:51:50 hehe Dec 23 11:52:33 i mean, i dont expect this to be fixed correctly right now, but at the very least we should fix it so we arent losing information. so that when we do fix it correctly, it isnt going to be impossible to recover the knowledge of what deps arent actual build deps, you know Dec 23 11:53:55 good plan. I like your DEPENDS = "foo $(BDEPENDS)" idea (where BDEPENDS is actual build dependencies I suppose) Dec 23 11:54:40 as an interim solution that is Dec 23 11:55:03 would you mind sending a followup on that to oe@ ? Dec 23 11:55:18 will do Dec 23 11:55:26 thanks Dec 23 11:55:32 * reenoo_ off for real now Dec 23 11:56:06 np, thanks for the info. didnt realize that you cant know what binary packages will be emitted until compile time in some cases. meh. Dec 23 13:50:44 hi Dec 23 13:51:00 * rob_w starts his first build for mips Dec 23 14:32:28 ok merry xmas to everybody see you all around the 27 or the 28 Dec 23 15:37:26 kergoth: Some of my other comments were about trying to solve the knowing what packages will be emitted before compile time problem Dec 23 16:08:59 * france is back (gone 16:28:35) Dec 24 01:01:39 good morning Dec 24 01:51:17 hi all Dec 24 02:06:13 hi all **** ENDING LOGGING AT Sat Dec 24 02:59:57 2005