**** BEGIN LOGGING AT Sun Jul 27 02:59:57 2008 Jul 27 07:30:09 03zecke123 07bitbake-1.8 * r1078 10/ (ChangeLog lib/bb/fetch/cvs.py): Jul 27 07:30:09 [cvs] Allow to checkout by date and time Jul 27 07:30:09 With putting YYYYYMMDDHHmm into the SRCDATE bitbake will checkout Jul 27 07:30:09 using "-D YYYYMMDD HH:mm UTC". Be careful when you switch from SRCDATE Jul 27 07:30:09 with time and without to always get updatable packages. Jul 27 07:44:28 03zecke123 * r1079 10bitbake/ (ChangeLog lib/bb/fetch/cvs.py): Jul 27 07:44:28 [cvs] Allow to checkout by date and time Jul 27 07:44:28 With putting YYYYYMMDDHHmm into the SRCDATE bitbake will checkout Jul 27 07:44:28 using "-D YYYYMMDD HH:mm UTC". Be careful when you switch from SRCDATE Jul 27 07:44:28 with time and without to always get updatable packages. Jul 27 07:57:07 * * OE Bug 4456 has been created by ka6sox(AT)nslu2-linux.org Jul 27 07:57:09 * * DNS Cache Poisoning Bug Jul 27 07:57:11 * * http://bugs.openembedded.net/show_bug.cgi?id=4456 Jul 27 09:08:05 morning all Jul 27 09:25:43 03pb 07org.oe.dev * rede13d1b... 10/ (4 files in 3 dirs): Jul 27 09:25:43 font-misc-misc: re-add apparently deleted package with no obvious Jul 27 09:25:43 replacement Jul 27 09:26:33 hi Jul 27 09:26:36 to make bitbake recipe for an application which uses WAF build system, which class should I inherit in my recipe? Jul 27 09:29:26 write a class for WAF system (if you will add more recipes that use it) or non. (just define do_configure & co in your recipe) Jul 27 09:31:30 this means no class exist to inherit? Jul 27 09:40:40 03pb 07org.oe.dev * r4d4881c0... 10/ (3 files in 2 dirs): snes9x: fix cross-compiling problem with 64 bit host Jul 27 10:04:16 03pb 07org.oe.dev * rddb3262e... 10/ (4 files in 2 dirs): openchrome: add 0.2.902 Jul 27 10:36:06 03mickeyl 07org.oe.dev * rc7b8aa93... 10/ (3 files in 3 dirs): openmoko.conf: remove P1, there are no longer any phases. allow feed config to be overriden locally Jul 27 10:36:12 03mickeyl 07org.oe.dev * r27000390... 10/ (1 packages/images/fso-image.bb): fso-image: include dosfstools Jul 27 10:43:16 mickeyl: good morning Jul 27 10:45:03 hi pb_ Jul 27 10:45:08 good to see you commiting changes! Jul 27 10:45:17 heh :-) Jul 27 10:45:18 unfortunately you will soon have to use another SCM Jul 27 10:45:22 are you prepared for that? ;) Jul 27 10:45:28 doh! Jul 27 10:45:34 just when I had got used to monotone :-} Jul 27 10:45:37 heh Jul 27 10:45:40 but sure, I am prepared :-) Jul 27 10:45:41 i knew you were saying that Jul 27 10:45:42 cool Jul 27 10:45:56 we're right in the administrative struggle of moving to git Jul 27 10:46:18 right, very good Jul 27 10:46:25 yay! Jul 27 10:46:25 when do you plan to make the switch? Jul 27 10:46:53 as soon as we can get some agreement on a few issues. I think we're mostly there though Jul 27 10:47:02 i hope we can do that within the next 2-4 weeks. there's going to be an announcement and a call for ssh-key long enough beforehand Jul 27 10:47:09 *nod* Jul 27 10:47:12 righto Jul 27 10:47:35 I should hurry to commit some stuff just in case something doesn't work in the first weeks ;) Jul 27 10:47:51 03pb 07org.oe.dev * rd31c1295... 10/ (4 files in 3 dirs): mesa-dri: fix 6.5.2 cross compilation error, add 7.0.3 Jul 27 10:47:56 03pb 07org.oe.dev * r1be001db... 10/ (1 packages/lirc/lirc-modules_0.8.3+cvs20080713.bb): lirc-modules: remove "-e" from makeflags, was causing build breakage Jul 27 10:48:57 RP: just out of interest, what are the issues? Jul 27 10:50:15 pb_: Basically a question of how the OE project as a whole is managed, who gets to make decisions and how Jul 27 10:50:30 RP: does bitbake support overrides on tasks? I want to have do_deploy_collie() { } (empty task) the build doesn't run do_deploy with this change but this may just be some bug. Jul 27 10:50:50 thesing: it does although it changed format in bitbake svn recently Jul 27 10:51:00 see the PARALLEL_MAKE stuff in bitbake.conf Jul 27 10:52:16 pb_: The plan is to make the existing core team more offical/public, at least until we come up with something better Jul 27 10:54:09 right, I see Jul 27 10:54:31 RP: the PARALLEL_MAKE stuff uses tasks as overrides, doesn't it? I want to use machine overrides on tasks i.e. redefine tasks for different machines. Jul 27 10:55:09 thesing: You can combine overrides Jul 27 10:56:21 thesing: and yes, you should be able to override a task Jul 27 10:56:57 I'll try with a non_empty task. Jul 27 10:57:56 yeah, there should be loads of examples of task overrides in the existing .bb files Jul 27 11:00:21 I only found the prepend and append stuff Jul 27 11:00:42 thesing: do_compile_someoverride () { should just work Jul 27 11:01:50 so we can't have a distro/machine etc. called "prepend" or "append" ;) **** ENDING LOGGING AT Sun Jul 27 11:02:27 2008 **** BEGIN LOGGING AT Sun Jul 27 11:02:55 2008 Jul 27 11:03:16 pb_: append and prepend are embedded in bitbake's core so I doubt even changing overrides would help Jul 27 11:03:54 RP: right, but he could re-jig overrides to mention, for example "distro-${DISTRO}" rather than just ${DISTRO} Jul 27 11:04:14 then, writing "do_install_prepend_distro-append" would do what you expected Jul 27 11:05:14 lets hope that it doesn't come to that. Jul 27 11:05:15 pb_: ah, yes :). My favourite is the PN override which works like that Jul 27 11:05:51 right, yeah, that's for the same reason. Jul 27 11:06:15 we did talk about explicitly namespacing all the OVERRIDES at one point but it never seems to have been a pressing enough issue to make the upheaval worth it Jul 27 11:06:24 another thing. is there a way to remove sth. from PROVIDES? -= doesn't seem to exist. Jul 27 11:07:03 pb_: There doesn't seem to be the need at present... Jul 27 11:07:38 pb_: On a related note, we did talk of changing the override character from _ to . so we could speed up the parser and make overrides more obvious Jul 27 11:08:50 thesing: I thought there was a "_delete" thing, similar to _append, but it doesn't seem to exist so maybe I imagined it. Jul 27 11:09:03 There isn't a delete Jul 27 11:09:09 of course, you can munge PROVIDES any way you like using python Jul 27 11:09:29 RP: why would changing the override character make the parser faster? Jul 27 11:10:09 pb_: Because at the moment we note every variable name with a _ in as being potentially overrideable Jul 27 11:10:33 This made bitbake a lot faster since we could make override expansion faster Jul 27 11:10:51 but there are lots of false positives with _ in the name Jul 27 11:10:53 are there a large proportion of variable names with "_" that aren't actually overrides? Jul 27 11:10:59 yes :( Jul 27 11:11:13 SRC_URI. TARGET_OS TARGET_ARCH Jul 27 11:11:17 etc. Jul 27 11:11:37 I did once propose removing the _ and replacing with something else Jul 27 11:11:43 oh, right, yeah Jul 27 11:11:48 but swapping _ for . seems neater Jul 27 11:12:25 well, to be honest I loathe the idea. or, more accurately, I like the idea in principle but I loathe the incompatibility it would introduce. Jul 27 11:13:03 I kind of feel that, although with hindsight one could have invented better syntax for these things, we're pretty much stuck with what we have got. Jul 27 11:13:31 The one thing in its favour is that bitbake could override on both for a while, even maybe as a configurable option Jul 27 11:13:40 so we could transition to it without a flag day Jul 27 11:14:12 possibly, but of course you won't get any benefit from it until you can turn off processing of _. Jul 27 11:14:52 true Jul 27 11:15:03 I think it wouldn't be that hard to convert OE.dev though Jul 27 11:15:36 one could use bitbake to replace _ with . in for override Jul 27 11:15:56 thesing: no, since we never know all possible overrides Jul 27 11:16:19 I only meant for converting oe.dev. Jul 27 11:16:31 no, I don't think it would be all that hard to convert OE.dev itself. but then, at a single stroke, you would make it impossible to backport or forward port packages (or, even worse, patches) between OE.dev and other branches. Jul 27 11:16:42 well, not impossible, but much harder Jul 27 11:17:48 You'd just have to enable "_" handling in bitbake, then it would work Jul 27 11:18:00 at a price of some speed which if that bothered you... Jul 27 11:19:45 well, if you backported something from .dev to an older branch, you'd probably have to manually replace all the characters since older bitbakes wouldn't understand ".". Jul 27 11:20:21 I'm assuming you could update the bitbake on the older branch Jul 27 11:20:22 if you forward port then yes, you could enable processing of underscores, but then bitbake would have to take special measures to make sure that the right thing happened if a recipe defines both somevar_override and somevar.override. Jul 27 11:21:09 i.e. the parser would need to treat those two names as being actually lexically identical, not just two syntaxes for overriding. Jul 27 11:21:45 yes, that would need careful handling Jul 27 11:22:06 and you wouldn't have any hope of cherry-picking patches for ports in either direction, since anything where the override character was different would give you a reject. Jul 27 11:23:19 pb_: So you still loathe the idea? Jul 27 11:23:35 well, I'm still far from convinced that it is worth the pain at the moment. Jul 27 11:23:46 do you know what the actual speedup will be in percentage terms? Jul 27 11:24:03 If we seriously think about it I'd run some tests and give some real numbers Jul 27 11:25:18 We have made real progress in making bitbake faster but its getting harder to find significant speedups Jul 27 11:25:22 it's long been my view that the single greatest weakness of OE isn't the parsing speed, or the memory consumption, it's more the level of seemingly-random churn that makes it very difficult to maintain an OE-based system if you aren't continuously plugged into the irc and/or mailing list circuits. Anything that makes this worse should, I think, only be done after very careful consideration. Jul 27 11:26:39 pb_: Agreed. This idea has been floating around for over a year and we've not done anything yet for that reason Jul 27 11:27:09 Perhaps we could make the change shortly before we make the new stable branch. And we could provide a tool to convert from old to new syntax. Jul 27 11:27:26 The random churn is a problem with OE.dev - its a melting pot of many people's improvements Jul 27 11:28:12 Most of the churn is actually desireable but it does introduce the potential for problems :( Jul 27 11:28:25 Well thats the price of fast development I think. Jul 27 11:28:59 exactly. We don't do too badly all things considered and if you want stablity there are solutions out there (e.g. poky) Jul 27 11:29:03 And we have the stable branch for a reason. Jul 27 11:30:32 We should provide means to backport stuff from dev to stable easily if we change the syntax but other than that I don't think we should change what we must to improve oe. Jul 27 11:33:13 03mickeyl 07org.oe.dev * r0506e17d... 10/ (1 conf/distro/include/moko-autorev.inc): moko-autorev.inc: yank strange character from file Jul 27 11:33:17 03mickeyl 07org.oe.dev * r6973c76c... 10/ (1 conf/distro/include/sane-srcdates.inc): sane-srcdates.inc: remove strange character. my merger is broken Jul 27 11:33:40 well, I guess we should see the numbers before we make a decision. If there's a really noticeable speedup to be had there then fine, this might be worth doing. But I would certainly not support this sort of disruptive change if the parsing speedup isn't going to be significant. Jul 27 11:34:31 I would have thought a less disruptive way to achieve the same ends would be just to have a moratorium on new variables with underscores in their names, and to have a blacklist of legacy variables (SRC_URI etc) that have non-override-signifying underscores. Jul 27 11:35:26 Of course. Breaking stuff this badly shouldn't be sone for 0.1% speed increase. Jul 27 11:35:48 pb_: nearly all tasks have '_' Jul 27 11:36:43 sure, but there are a finite number of common task names and they are all enumerated in bitbake.conf. Jul 27 11:37:45 This sounds if it could be slower than the actual solution. Finite can be quite large. Jul 27 11:39:21 s/actual/current/ Jul 27 11:43:42 mm, seems hard to imagine that it would be slower. Jul 27 11:44:26 If I understand RP's point correctly he is worried about update_data() being something like O(N(overrideable vars)*N(overrides)). Jul 27 11:45:03 assuming that it's true that only a minority of the vars are actually overrideable, there ought to be a significant win in removing the cost of examining all the other ones. Jul 27 11:45:33 marking a variable as non-overrideable is basically O(1) so it would take a very pathological case for that cost to outweigh the gain Jul 27 11:48:41 RP: Another thing. If I have two tasks A and B:do_rootfs with A depending on B:rootfs. If I bitbake A then B:rootfs is run and after that A, but if I bitbake A again only B:do_rootfs is run. A isn't run because it already build. But why is B:do_rootfs run again? Jul 27 11:53:36 pb_: more O(N(possible overidable variables)) Jul 27 11:55:48 why? Jul 27 11:57:58 because you have to check for each var which might be an overide if its in this list. Well the number of vars which might be an override is limited so one is back to O(1) Jul 27 11:59:25 So your are right. Jul 27 12:01:40 thesing: do_rootfs has the "nostamp" flag Jul 27 12:02:07 pb_: As you say it all comes down to numbers which is what I'd establish if we were to seriously consider it Jul 27 12:02:15 RP: so its run despite nobody depending on it? Jul 27 12:02:56 well, you said A depends on it Jul 27 12:03:12 yes but A is already build. Jul 27 12:03:26 but B is "nostamp" and will therefor always run Jul 27 12:03:36 To build A, it would have to build B Jul 27 12:04:07 Standard bitbake dehaviour doesn't look at the timestamp differences between two different packages A and B Jul 27 12:04:43 There is now the new stamp policy options which let it look at that though Jul 27 12:05:15 how do I enable it? Jul 27 12:06:42 thesing: BB_STAMP_POLICY = "whitelist" (or "full") Jul 27 12:06:59 but be warned, it will do this for all stamps Jul 27 12:07:21 does "full" work or should I use "whitelist"? Jul 27 12:07:36 are you using packaged staging? Jul 27 12:07:41 yes Jul 27 12:08:04 use whitelist then Jul 27 12:08:17 That class sets up a suitable whitelist for you Jul 27 12:08:26 Well new features have to be tested otherwise I could use stable ;) Jul 27 12:08:52 thesing: Just don't be surprised when half your build rebuilds ;-) Jul 27 12:09:11 and this feature will for example rebuild everything if I change glibc right? Jul 27 12:09:22 pretty much, yes Jul 27 12:09:37 and images will only rebuild when some stuff they use changed? Jul 27 12:09:51 no, images are still nostamp Jul 27 12:10:03 but A and B will rebuild since A depends on B Jul 27 12:11:45 why are images nostamp? with the STAMP_POLICY it makes no sense to rebuild an image if nothing changed. Jul 27 12:12:41 bitbake just honors the nostamp flag Jul 27 12:15:04 But you agree that we should remove that flag for images once the stamp policy is default? Jul 27 12:17:42 thesing: There are no plans to make the stamp policy default Jul 27 12:17:52 It should come down to user preference Jul 27 12:19:33 that wouldn't change. We would only change the default setting. Jul 27 12:20:28 The current stamp policy needs the nostamp setting for images Jul 27 12:20:35 we can't remove that Jul 27 12:20:39 * RP -> back later Jul 27 12:23:12 khem, RP; the latest toolchain change broke BB_STAMP_POLICY = "whitelist" see: http://www.pastebin.ca/1084249 Jul 27 13:29:04 03pb 07org.oe.dev * r7de203ac... 10/ (4 files in 2 dirs): openchrome: adjust PACKAGES_DYNAMIC Jul 27 13:29:08 03pb 07org.oe.dev * rbb233fef... 10/ (1 packages/tasks/task-mythfront.bb): mythfront: adjust dependencies Jul 27 13:33:55 thesing you can delete stuff with some python magic. It is very similar to sed, it may even use it. Jul 27 13:40:11 I have a problem that completely baffles me here. On powerpc with uclibc, I can't start dbus-daemon. I get the following error: "dbus-daemon: symbol '': can't resolve symbol in lib 'dbus-daemon'." Now I've obtained full output from uClibc with LD_DEBUG=all here: http://stephan.kochen.nl/proj/wii-oe/dbus-daemon_ld_debug.txt Jul 27 13:41:05 Now I have not idea what the garbage in libexpat is, readelf and objdump seem to be reading it fine. However, the nameless section it's talking about appears to be this in dbus-daemon's .dynsym: Jul 27 13:41:06 Num: Value Size Type Bind Vis Ndx Name Jul 27 13:41:06 1: 00000114 0 SECTION LOCAL DEFAULT 1 Jul 27 13:41:42 That's about all I understand about the problem. Busybox appears to be working fine with uClibc. :/ Jul 27 13:41:47 That sounds like a dynamic linker bug. I guess you should take it up with the uclibc people. Jul 27 13:42:52 Okay, I'll post to their mailinglist then. Thanks. Jul 27 14:15:57 hi zecke Jul 27 14:16:27 ho Jul 27 14:16:49 pb_: do you know the linux ECC code? for me it looks like we only store column parity in the OOB? Jul 27 14:17:23 zecke: I know it a bit, but I don't remember the details offhand Jul 27 14:17:33 let me have a look Jul 27 14:18:20 to me it looks like we don't do it like samsung proposes in its s3c2442 user manual (column and row parity for a NAND page) Jul 27 14:18:54 I think the default linux ecc algorithm is different to the samsung one, certainly Jul 27 14:20:39 are you looking at the code in nand_ecc.c, or in s3c2410.c? Jul 27 14:21:08 pb_: right, but I think we only store the column parity... I wonder how useful this is compared to the column+row Jul 27 14:21:17 pb_: s3c2410.c and nand_base.c Jul 27 14:22:05 hi has anyone tried OE for avr32?? (atngw100) Jul 27 14:22:06 pb_: so we write blocks, get the ECC0 data of the main memory, put that into the OOB data structure... and then after having written the whole page we write the OOB in linux Jul 27 14:23:28 right Jul 27 14:23:36 what makes you think that only the column parity is stored? Jul 27 14:24:05 for some reason its trying to build glibc instead of uclibc Jul 27 14:24:18 my conf contains Jul 27 14:24:29 MACHINE = "atngw100" Jul 27 14:24:29 TARGET_OS = "linux-uclibc" Jul 27 14:24:29 DISTRO = "angstrom-2008.1" Jul 27 14:24:52 pb_: maybe I expect too much from the hardware but we ignore one byte from ECC0 and ECC1 completely Jul 27 14:25:09 hm, really? Jul 27 14:25:20 I think all three bytes that the hardware returns should be getting stashed in the oob Jul 27 14:26:42 I can't see anything obvious in the code that would prevent that happening. Jul 27 14:27:00 nand_write_page_hwecc() seems to save everything that ecc.calculate() returns Jul 27 14:27:22 pb_: let me check, I think ECC0 contain four bytes for s3c2442... Jul 27 14:27:34 oh, right. that would be different to the older chips. Jul 27 14:27:46 I'm pretty sure s3c2410/12 only calculates a three byte ecc Jul 27 14:28:07 if 244x uses a different algorithm then yeah, s3c2410.c is probably broken Jul 27 14:30:09 yah, I just checked my software implementation of the s3c2410 ecc and that only uses a three byte code. Jul 27 14:30:22 pb_: it has s3c2440 code. okay I think I understand better now. ECC0 and ECC1 generate two kind of parities Jul 27 14:30:55 ECC0 would generate 28bit parity, we save 3*8, so skip 4 bits... Jul 27 14:31:19 I see Jul 27 14:31:51 and then I'm confused again (by the next page of the user manaul) Jul 27 14:32:06 let me download the user manual and have a look at what it says Jul 27 14:32:08 "ECC MODULE FEATURES" Jul 27 14:32:51 what nand page size do you use? Jul 27 14:32:55 anyway. I have patched uboot to write and read the ECC from hardware, and the kernel agrees with the values read and written Jul 27 14:32:59 2k (so large page) Jul 27 14:33:23 ah right, I guess that would account for the difference Jul 27 14:33:50 24 bits is enough to hold row/column parity for a 512 byte page, but I guess you need more bits for rows as the page size goes up Jul 27 14:34:33 ecc size gets reduced to 256 byte in the kernel Jul 27 14:35:26 (for large page), I try to find some kind of discussion on these parameters. How many errors we want to detect, be able to correct... :) Jul 27 14:35:38 pb_: anyway thanks for listening Jul 27 14:36:28 I see Jul 27 14:36:35 sorry, I don't know much about the large page support Jul 27 14:36:52 :) Jul 27 14:37:28 pb_: 2K page means that our erase block is of that size right? Jul 27 14:37:45 zecke: no, the erase block is usually bigger Jul 27 14:37:55 on small page nand you have 512 byte pages, 16k erase blocks Jul 27 14:38:44 I think large page nand has something like 64k or 128k erase blocks Jul 27 14:39:17 pb_: ah I see... and miss something... if we wouldn't have this typhoon warning I would go to the book shop to get a book about flash... Jul 27 14:39:53 zecke: doh Jul 27 14:40:01 are you in taipei at the moment? Jul 27 14:40:17 pb_: yes, leaving tuesday... if mother nature allows that Jul 27 14:40:31 heh, right Jul 27 14:40:59 funnily enough I nearly had to go to taipei this week as well, but in the end one of my colleagues went instead Jul 27 14:41:32 he flew out to HK yesterday, just in time to avoid the typhoon Jul 27 14:41:33 pb_: sorry to abuse you. I know NAND and erabse block... all bits in that block get put back to 1... 2K page then must have to do with addressing, but our nand controller even allows byte access... Jul 27 14:42:18 zecke: where do you see that your nand controller allows byte access? Jul 27 14:42:44 pb_: imagination? Jul 27 14:42:47 let me check Jul 27 14:44:18 ah more to learn... that datasheet is working. it talks about being able to load a byte from NFDATA... (well it is risc in the end, so I'm probably just throwing away the rest) Jul 27 14:44:42 pb_: okay, so I do addressing of 2K pages and then NFDATA would fill with the data... Jul 27 14:45:18 pretty much Jul 27 14:45:53 thanks Jul 27 14:45:56 the procedure for reading is more or less: Jul 27 14:46:19 write "read page" command to NFCMD Jul 27 14:46:37 write the page address (i.e. byte address / 2048) to NFADDR, 8 bits at a time, least significant bit first Jul 27 14:46:46 wait for the flash to say it's ready Jul 27 14:46:57 read data out of NFADDR Jul 27 14:48:02 iirc, most modern flashes will do automatic sequential reads, so after you've read 2048 bytes you just have to wait for another ready signal and then you can go on reading; no need to reissue the command or address Jul 27 14:53:06 er, read data out of NFDATA, obviously, not NFADDR Jul 27 14:53:57 thanks Jul 27 14:55:47 bbiab Jul 27 14:55:49 * pb_ -> Jul 27 14:57:08 03woglinde2 07org.oe.dev * rc167fd3c... 10/ (1 packages/classpath/classpath-native.inc): classpath-initial: fix libtool2 error Jul 27 15:42:37 03thebohemian2 07org.oe.dev * r428b4f34... 10/ (3 files in 3 dirs): jamvm-initial 1.4.5: New recipe. Jul 27 15:42:42 03thebohemian2 07org.oe.dev * rff3cafe7... 10/ (3 files in 2 dirs): Jul 27 15:42:42 classpath-native.inc: Set JAVAC through environment variable. Jul 27 15:42:42 classpath.inc: Set JAVAC through environment variable. Jul 27 15:42:47 03thebohemian2 07org.oe.dev * r7d59915b... 10/ (3 files in 2 dirs): disapproval of revision 'ff3cafe77c935d7b92703d6844722054ef7f9774' Jul 27 15:42:53 03thebohemian2 07org.oe.dev * r6ca499af... 10/ (3 files in 2 dirs): Jul 27 15:42:53 ecj-initial 3.4: New recipe for version 3.4. Jul 27 15:42:53 ecj-bootstrap-native 3.4: New recipe for version 3.4. Jul 27 15:42:57 03thebohemian2 07org.oe.dev * r77bc5067... 10/ (3 files in 2 dirs): disapproval of revision '6ca499af1613b08ef437cfa3285ae0b2ed3fbfcb' Jul 27 16:15:31 mickeyl: wb Jul 27 16:20:04 Does anybody understand why gmp-native builds fine in Angstrom, but fails to build in Sonkei which is an overlay on top of Angstrom? http://tinderbox.openembedded.net/public/logs/635554.txt Jul 27 16:20:13 thanx Jul 27 16:24:08 mickeyl: I am very pleased with myself, today I managed to build a mythfront-image with no errors :-) Jul 27 16:24:38 of course, I haven't actually tried to boot it yet. I think that will only end in disappointment so I will try it another day. Jul 27 16:25:37 nice, that's progress Jul 27 16:25:38 hehe Jul 27 16:25:44 keep us updated Jul 27 16:25:49 will do :-) Jul 27 16:48:26 03mickeyl 07org.oe.dev * r9dc7779d... 10/ (1 packages/images/fso-image.bb): fso-image: install some gtk programs and fix their .desktop files to appear in the illume launcher Jul 27 16:49:34 hmm Jul 27 16:49:37 Gdk-WARNING (recursed) **: Error converting from UTF-8 to STRING: Could not Jul 27 16:49:37 >open converter from 'UTF-8' to 'ISO-8859-1' Jul 27 16:49:40 ? Jul 27 16:51:26 where's the gtk experts? Jul 27 16:51:55 iconv Jul 27 16:52:14 or xlib lacking stuff Jul 27 16:52:23 (just a guess) Jul 27 16:52:41 mickey|bbl: the alternative to the above would be to cherry-pick raster's xdg menu.xml changes Jul 27 16:53:23 i guess some lib is missing Jul 27 16:53:47 how is gtk+ converting charsets? Jul 27 16:53:55 dlopening stuff? Jul 27 16:54:08 mickey|bbl: glibc iconv IIRC Jul 27 16:54:16 mickey|bbl: this will dlopen Jul 27 16:54:20 ah Jul 27 16:54:28 hi Jul 27 16:54:31 let me check whether i have libiconv Jul 27 16:54:35 glibc-localedata-... could be your friend Jul 27 16:54:52 oh, something like that Jul 27 16:55:11 hms Jul 27 16:55:11 mickey|bbl: flag days are fun... do you volunteer to unbrick neo sold in europe? :) Jul 27 16:55:19 monotone server hangs Jul 27 16:55:36 flag days? Jul 27 16:55:53 zecke: unbricking? => michael shiloh Jul 27 16:56:11 ok, there's not a single localedata installed by default Jul 27 16:56:16 now which of those do i need... Jul 27 16:57:15 mickey|bbl: sorry maybe it is gconv Jul 27 16:57:23 *g* Jul 27 17:00:28 mickey|bbl: yah, that means you lack the right iconv modules Jul 27 17:00:46 hmm Jul 27 17:00:48 but which ones Jul 27 17:01:03 mickey|bbl: utf8 would be good :) Jul 27 17:01:07 iso8859 Jul 27 17:01:17 hmm, oh, they aren't even built Jul 27 17:01:22 doh Jul 27 17:01:46 * mickey|bbl bitbake iconv Jul 27 17:01:49 bbl, dinner Jul 27 17:02:00 glibc-gconv-iso8859-1 is probably what you want Jul 27 17:02:14 judging from task-openmoko-toolchain-target.bb :-} Jul 27 17:02:28 hmm Jul 27 17:02:29 installed Jul 27 17:02:32 no changes Jul 27 17:02:35 do i need to make it known? Jul 27 17:02:59 not that I can think of Jul 27 17:03:18 oh, wait, what's your locale? Jul 27 17:03:34 LC_ALL=hesse Jul 27 17:04:05 zecke: not that locale Jul 27 17:04:28 LOCALE=c is the best Jul 27 17:04:28 pb_: just wanted to amuse mickeyl :) Jul 27 17:04:41 woglinde: no, C is the worst Jul 27 17:04:43 you want a utf-8 locale Jul 27 17:04:49 zecke: heh Jul 27 17:05:44 pb hm right Jul 27 17:09:20 dinner Jul 27 17:09:24 right Jul 27 17:10:09 bon appetit Jul 27 17:23:02 03thesing 07org.oe.dev * rae83b5e0... 10/ (1 classes/kernel.bbclass): Jul 27 17:23:02 kernel.bbclass: -change initramfs-logic Jul 27 17:23:02 -add parameter to do_sizecheck do make it optional Jul 27 17:23:06 03thesing 07org.oe.dev * r7627b0bc... 10/ (4 files in 2 dirs): Jul 27 17:23:06 add linux-kexeboot: a kernel with initramfs-kernel-image as initramfs Jul 27 17:23:06 will be used as 2nd stage bootloader for collie Jul 27 17:23:11 03thesing 07org.oe.dev * r9cf027e9... 10/ (5 files in 3 dirs): Jul 27 17:23:11 linux-rp 2.6.26:-update collie patch Jul 27 17:23:11 -change collie defconfig Jul 27 17:23:12 -remove initramfs-config-collie Jul 27 17:23:16 03thesing 07org.oe.dev * r0f1c2075... 10/ (1 packages/images/initramfs-kexec-image.bb): initramfs-kexec-image: automagicly build cpio images too Jul 27 17:23:21 03thesing 07org.oe.dev * ra4b0b9af... 10/ (1 packages/linux/linux-rp.inc): Jul 27 17:23:21 linux-rp.inc: override do_deploy for collie with empty function. Kernel Jul 27 17:23:23 for collie is now included in rootfs Jul 27 17:23:26 03thesing 07org.oe.dev * r778f5060... 10/ (1 files/device_table_add-mmc.txt): Jul 27 17:23:27 add device table that will create mmcblk0p1 file. Jul 27 17:23:29 Note: this node is from a dynamic pool. If you have other block Jul 27 17:23:31 devices that get their major numbers from this pool this node might Jul 27 17:23:33 be wrong. Jul 27 17:23:35 03thesing 07org.oe.dev * r35d00516... 10/ (3 files in 3 dirs): Jul 27 17:23:39 collie.conf: -make collie also use device-table with mmc added Jul 27 17:23:41 -collie kernels are not checked for size now Jul 27 17:23:43 -other minor stuff Jul 27 17:23:45 zaurus-2.6.inc: -add kernel to rootfs for collie Jul 27 17:23:47 -change do_installkit accordingly Jul 27 17:34:03 Laibsch: you should now be able to build stuff for collie without additional patches. bitbake linux-kexecboot and flash resulting kernel. Untar image to sd card and boot. Jul 27 17:38:56 OK, I'll try to give it a go Jul 27 17:39:10 hmm Jul 27 17:39:13 nothing set as locale Jul 27 17:39:16 trying C Jul 27 17:39:24 err Jul 27 17:39:26 utf8, that is Jul 27 17:40:09 hmm, no Jul 27 17:40:12 still the same complaint Jul 27 17:40:33 wtf is gpe-scap doing there Jul 27 17:40:39 it should not need to convert anything Jul 27 17:40:47 just leave everything and things will be fine Jul 27 17:40:48 *sigh* Jul 27 17:41:12 or rather Jul 27 17:41:12 gdk Jul 27 17:41:23 mickey|bbl: attach strings to the x window :) Jul 27 17:41:38 not that we have a way to display captions Jul 27 17:43:26 i don't think it's a window title Jul 27 17:43:30 but anyways Jul 27 17:43:39 LOCALE=utf-8 at least changes something Jul 27 17:43:41 i now get Jul 27 17:43:52 locale not supported... Jul 27 17:43:55 falling back to C Jul 27 17:43:55 :D Jul 27 17:44:34 why isn't gtk+ dragging all in it needs... Jul 27 17:44:46 obviously it doesn't work without this locale foo Jul 27 17:44:50 so it should DEPEND on it Jul 27 17:44:52 or at least RRECOMMEND Jul 27 17:45:00 *sigh* Jul 27 17:45:38 or gpe-scap in this case. i don't know who's to blame Jul 27 17:45:42 my openmoko-terminal2 works fine Jul 27 17:45:45 (also in gtk) Jul 27 17:45:52 03thebohemian 07org.oe.dev * r953ae6dd... 10/ (1 packages/classpath/classpath-native.inc): classpath-native: Fix typo in depends. Jul 27 17:46:40 :) Jul 27 17:47:05 (gpe-scap:2261): Gdk-WARNING **: Jul 27 17:47:09 what's the 2261? Jul 27 17:47:22 any chance i see where exactly it is going wrong? Jul 27 17:48:15 pid Jul 27 17:48:36 oh Jul 27 17:48:40 well Jul 27 17:49:02 i don't think i'm in the mood to insert debug statements into gpe-scap to fix it Jul 27 17:49:10 i'll just leave it there for someone else to fix Jul 27 17:49:11 *shrug* Jul 27 17:49:42 it works with ASU... Jul 27 17:50:08 yeah, because you install everything but the kitchen sink Jul 27 17:50:23 obviously our metadata is broken Jul 27 17:50:37 otherwise this would work even by installing a gtk app afterwards on a non-gtk image Jul 27 17:50:56 we are even forced to ship the gtk moko theme :) Jul 27 17:51:09 "forced" in terms of no one actually depends on it but everyone assumes Jul 27 17:54:55 aah Jul 27 17:55:07 bindtextdomain (GETTEXT_PACKAGE, GPESCAPLOCALEDIR); Jul 27 17:55:07 bind_textdomain_codeset (GETTEXT_PACKAGE, "UTF-8"); Jul 27 17:55:07 textdomain (GETTEXT_PACKAGE); Jul 27 17:55:19 ??? Jul 27 17:55:51 looks sane... :) Jul 27 17:55:56 dunno whether this leads to the real error (could not save temporary png file) Jul 27 17:56:03 i would not care about the warning Jul 27 17:56:06 but it actually doesn't work Jul 27 17:56:14 the real error popping up in a dialog box Jul 27 17:56:18 (as written) Jul 27 17:56:32 might be something completely different Jul 27 17:56:44 * mickey|bbl considers rewriting gpe-scap Jul 27 17:57:11 mickey|bbl: reuse :) Jul 27 17:57:26 i tried Jul 27 17:57:30 as you've seen... it didn't work Jul 27 17:57:39 and now i can spend some days to find out what's wrong Jul 27 17:57:46 or spend a couple of hours rewriting it Jul 27 17:57:53 i guess that's the problem foss has... Jul 27 17:57:56 *shrug* Jul 27 17:58:14 well, enough ranting. lets forget this issue and talk about something nice Jul 27 17:58:20 how's qt doing in OE? Jul 27 17:58:30 i've seen koen changing a lot Jul 27 17:58:31 the error is more likely in OE... Jul 27 17:58:45 mickey|bbl: Yes, but I think the stuff koen is not testing broke badly... qt/x11 that is Jul 27 17:59:10 i didn't get around taking a look... also I would like to get my SRCPV changes into OE, I think they make a lot sense Jul 27 17:59:45 mickey|bbl: also I need to start creating a keyname -> name + mail address map for mtn2git and fix that one bug... Jul 27 17:59:57 yeah Jul 27 18:00:20 mickey|bbl: let us talk about something nice, pretty people (male seldomy qualify) but not here :) Jul 27 18:00:38 mickey|bbl: have you seen the reasoning behind replacing SRCREV with SRCPV in the asu branch? Jul 27 18:00:58 no, sorry Jul 27 18:01:01 i did not follow asu at all Jul 27 18:01:31 mickey|bbl: you should. e.g. you can cvs co with date and time now :) Jul 27 18:01:57 mickey|bbl: sane-srcrev for git has the issue that you can not upgrade packages afterwards (or like 50/50...) Jul 27 18:02:06 mickey|bbl: gpe-scap dead upstream? Jul 27 18:02:17 Laibsch: unlikely dead Jul 27 18:02:19 Isn't florian maintaining it? Jul 27 18:02:40 he is and i bet it works on all images for him Jul 27 18:02:55 but like i said, it doesn't work when you just install it afterwards to a non-gtk image Jul 27 18:03:09 which might rather be a metadata problem Jul 27 18:03:22 Oh, I see Jul 27 18:03:34 I just thought you should take it up with upstream Jul 27 18:03:43 I'd assume florian to fix it Jul 27 18:03:59 mickey|bbl: so if you put SRCREV in the PV and have a sane-srcrev, you lose... Jul 27 18:04:07 sounds good Jul 27 18:04:13 mickey|bbl: so I invented SRCPV which can be put into PV and will create a version number that allows upgrading... Jul 27 18:04:25 good. being able to upgrade is always nice Jul 27 18:05:06 mickey|bbl: I have to redo/improve the bitbake implementation... this would also split up BITBAKE_PV and PACKAGE_PV... Jul 27 18:12:13 zecke: It would be good to have an email summary or a bug report with the exact problem in then we can lookat solving it Jul 27 18:13:03 RP: I know :( Jul 27 18:13:11 mickey|bbl: yah, that locale thing is annoying. I thought there was a fix for it in the gpe task packages but apparently not. Jul 27 18:13:21 iirc, you basically just need to install a utf8 locale and select it as your current one Jul 27 18:13:29 wow, big thunderstorm we're having here Jul 27 18:13:46 hmm could be, i don't have gpe-task installed Jul 27 18:14:02 which package is the utf8 locale in? Jul 27 18:14:05 RP: I think I mailed oe-dev back then, but yeah I have to merge that... Jul 27 18:14:08 the gconv is installed Jul 27 18:14:22 mickey|bbl: I think all the standard locales are utf8 Jul 27 18:14:38 try "ipkg install locale-base-de-de" or some such Jul 27 18:14:40 ok, so i can just install anyone Jul 27 18:14:41 righto Jul 27 18:14:43 doing that Jul 27 18:15:40 if you don't have any locale set then it defaults to C, in which case gtk will think everything is in iso8859-1 and try to recode it. Jul 27 18:15:58 ah, that could be it Jul 27 18:16:04 hmm... another construction site: Jul 27 18:16:07 root@om-gta02:/etc/gtk-2.0# opkg install glibc-locale-en Jul 27 18:16:07 An error ocurred, return value: 2. Jul 27 18:16:13 thanks for the verbose information, opkg Jul 27 18:16:15 *sigh* Jul 27 18:16:18 not my day Jul 27 18:16:22 :) Jul 27 18:16:49 ok, -de works better Jul 27 18:16:52 urghs Jul 27 18:16:54 Each time that happens with opkg, Thomas gets an email from me :) Jul 27 18:16:57 this is dragging in HEAPS of packages Jul 27 18:17:02 RP: excellent :) Jul 27 18:17:09 in this case it means "can't find package" Jul 27 18:18:46 ok, the de locale is installed Jul 27 18:19:04 neither setting LOCALE=de nor LOCALE=de_DE makes the error go away Jul 27 18:19:15 (first error, can't find locale) Jul 27 18:23:27 try LC_ALL rather than LOCALE Jul 27 18:23:36 I'm not entirely sure that the latter controls ctype. Jul 27 18:24:16 re Jul 27 18:24:23 just tried that. same locale not supported Jul 27 18:24:32 how can i check which locales actually are supported? Jul 27 18:24:36 so i could just pick one Jul 27 18:25:05 hm, good question. what do you have in /usr/share/i18n/locales/? Jul 27 18:25:30 root@om-gta02:/etc/gtk-2.0# ls -l /usr/share/i18n/locales Jul 27 18:25:30 -rw-r--r-- 1 root root 6448 Jul 27 12:06 de_DE Jul 27 18:25:30 -rw-r--r-- 1 root root 4809 Jul 27 12:06 de_LU Jul 27 18:25:30 -rw-r--r-- 1 root root 111251 Jul 27 12:06 i18n Jul 27 18:25:36 and a lot of translit* Jul 27 18:25:37 right, those are the source files Jul 27 18:25:41 what's in /usr/lib/locale? Jul 27 18:25:57 root@om-gta02:/etc/gtk-2.0# ls -l /usr/lib/locale/ Jul 27 18:25:57 -rw-r--r-- 1 root root 1276896 Jul 27 17:57 locale-archive Jul 27 18:26:10 hm. well, plenty in there. Jul 27 18:26:14 yeah pretty much Jul 27 18:26:23 that's the new-style "all in one" glibc locale archive Jul 27 18:26:25 isn't some postinst supposed to generate those once you install a localeß Jul 27 18:26:32 ah Jul 27 18:26:36 so that's ok so far? Jul 27 18:26:41 well, I would kind have expected you to be using the pregenerated binary locales, actually Jul 27 18:26:49 but yes, that's ok, there's nothing obviously wrong there. Jul 27 18:27:07 try "localedef --list-archive" on that locale-archive Jul 27 18:27:24 root@om-gta02:/usr/lib/locale# localedef --list-archive locale-archive Jul 27 18:27:24 de_LU Jul 27 18:27:24 de_LU.utf8 Jul 27 18:27:34 eeks Jul 27 18:27:40 luxemburg? Jul 27 18:27:45 and nothing else? Jul 27 18:28:21 oh dear Jul 27 18:28:40 well, heh, see if you can set LC_ALL=de_LU Jul 27 18:28:44 yeah Jul 27 18:28:49 makes the 'locale not found' away Jul 27 18:28:55 but not the can't convert from utf8 to iso-... Jul 27 18:29:01 try de_LU.utf8 Jul 27 18:29:04 same Jul 27 18:29:09 doh Jul 27 18:29:11 *nod* Jul 27 18:29:40 can you check the postinst for glibc-localedata-de-de, see why it didn't generate that one? Jul 27 18:30:03 I guess it's possible that de_LU* is scrunged somehow and doesn't actually have the right charset Jul 27 18:31:06 hmm Jul 27 18:31:13 can't find the postinst Jul 27 18:31:16 oh Jul 27 18:31:22 well, that would explain why it didn't get generated :-} Jul 27 18:31:31 what does the postinst for the LU one say? Jul 27 18:31:48 not present as well Jul 27 18:31:50 hm Jul 27 18:31:58 should be in /usr/lib/ipkg/info, right? Jul 27 18:32:00 maybe it's locale-base-* that has the postinst, not glibc-localedata Jul 27 18:32:01 i can see other postinst there Jul 27 18:32:02 right Jul 27 18:32:13 ah right Jul 27 18:32:16 locale-base- Jul 27 18:32:22 ah Jul 27 18:32:32 the locale-base for -lu is present Jul 27 18:32:36 for -de it's not Jul 27 18:33:05 oh dear Jul 27 18:33:15 the LU one basically calls localedef --inputfile=/usr/share/i18n/locales/de_LU --charmap=UTF-8 --prefix=/tmp/locale de_LU Jul 27 18:33:22 and then shuffles a locale-archive around Jul 27 18:33:26 right, yeah, that's correct Jul 27 18:33:46 the shuffling is necessary due to jffs2 limitations, locale-def will blow up if its output is on flash Jul 27 18:33:51 right Jul 27 18:34:03 so basically we have two problems Jul 27 18:34:03 so, looks like de_LU should indeed be utf8 Jul 27 18:34:12 but, clearly gtk doesn't agree Jul 27 18:34:13 yeah, de_LU looks like utf8 Jul 27 18:34:16 *nod* Jul 27 18:34:40 is there a straightforward way I can build an image to look at this for myself? Jul 27 18:34:50 say, something gtk based that will run in qemu on my laptop Jul 27 18:35:39 if you require conf/distro/moko-autorev.inc and conf/distro/fso-autorev.inc Jul 27 18:35:44 then you should be able to build fso-image Jul 27 18:35:50 which includes gpe-scap Jul 27 18:35:56 which is what i'm struggeling with Jul 27 18:36:05 it doesn't contain the locales (as we have seen) Jul 27 18:36:09 so you need to install taht as well Jul 27 18:37:06 apparantly it's not a problem in the openmoko gtk image, so that seems to install all the neccessities Jul 27 18:37:23 ok, very good Jul 27 18:37:26 but it's tough for me to say which package actually fixes it Jul 27 18:37:53 yeah, it's all a bit complex Jul 27 18:38:09 unfortunately I seem to be too senile to remember how that stuff works Jul 27 18:38:21 but, if I can actually see it on my own machine, maybe I can figure it out again Jul 27 18:39:32 right. thanks a lot! Jul 27 18:39:38 so Jul 27 18:39:41 * mickey|bbl taking a break now Jul 27 18:39:44 bblk Jul 27 18:39:45 nexttry on gettext 0.17 Jul 27 18:39:49 bye mickeyl Jul 27 18:58:43 okay, build running Jul 27 18:58:50 had a bit of a false start when I forgot to set XSERVER Jul 27 19:05:26 re zecke Jul 27 19:05:40 thanks Jul 27 20:17:43 e flo Jul 27 20:19:42 hi all Jul 27 21:33:09 * ant__ wonders if somebody tried TMPDIR = "/OE/${DISTRO}-tmp/" (http://www.angstrom-distribution.org/building-angstrom) Jul 27 21:33:37 ant__> http://www.pastebin.ca/1083734 Jul 27 21:33:37 http://www.pastebin.ca/1083738 Jul 27 21:33:55 fails miserably... Jul 27 21:35:07 note the mistyped /oe/angstrom-tmp//staging/i686-linux/usr/lib Jul 27 21:35:56 one '/' too much in TMPDIR ? Jul 27 21:36:24 but then you look at the examples BBPATH and PKGDIR, both terminated by slash Jul 27 21:36:48 what is the correct policy to designate these BB paths? Jul 27 21:37:16 I know it's harmful, but then... Jul 27 21:38:09 one would expect sane examples! Jul 27 21:38:53 pls just one confirmation before opening a bug Jul 27 21:55:50 ant__: A double / doesn't do any harm at all Jul 27 21:57:10 hi NAiL Jul 27 21:57:43 03mickeyl 07org.oe.dev * r5bb4bd3c... 10/ (1 packages/freesmartphone/freesmartphone-feed-configs.bb): add freesmartphone-feed-configs Jul 27 21:58:17 NAiL: I know, these slash are not the issue Jul 27 22:08:20 NAiL: TMPDIR = "/oe/build/tmp/${DISTRO}" (as it was) and the issue disappears Jul 27 22:08:45 under /build Jul 27 22:20:05 03Richard Purdie  07test1 * re8da60446a 10OE.dev/MAINTAINERS: Jul 27 22:20:05 Fix misplaced entry in MAINTAINERS Jul 27 22:20:05 Signed-off-by: Richard Purdie Jul 27 22:20:05 03Richard Purdie  07test1 * r94d5595dda 10OE.dev/: Merge branch 'master' of ssh://gittrial@git.openembedded.net//org.openembedded.dev Jul 27 22:20:31 heh :) Jul 27 22:22:04 hi rp Jul 27 22:22:07 ~seen khem Jul 27 22:22:09 khem is currently on #oe (6d 41m 59s) #uclibc (6d 41m 59s). Has said a total of 194 messages. Is idling for 1d 6h 1m 56s, last said: 'pb_: cool enjoy your gettogether'. Jul 27 22:22:10 hi woglinde Jul 27 22:23:41 hm I trigger cannot convert 'const __ctype_touplow_t*' to 'const int*' in assignment Jul 27 22:23:50 there is an gcc patch since 2006 Jul 27 22:23:55 but why I am trigger this now Jul 27 22:24:07 with latest uclibc and gcc-4.3.1 Jul 27 22:25:02 and in the uclibc tracker is only the link to the attachment not the bugreport Jul 27 22:41:48 RP: ping Jul 27 22:41:52 still there? Jul 27 22:42:00 Laibsch: yes Jul 27 22:42:26 OK Jul 27 22:42:29 Just got your mail Jul 27 22:42:43 Laibsch: everything ok with it? Jul 27 22:43:09 Well, I guess so Jul 27 22:43:16 I have not really read through it Jul 27 22:43:22 I've got two questions Jul 27 22:43:30 Should this be on a single page? Jul 27 22:43:39 I'm not sure that is appropriate Jul 27 22:43:52 Possibly not, no Jul 27 22:44:02 OK, I'll see about something Jul 27 22:44:16 You want real pages or should we keep this in a discussion page for now Jul 27 22:44:17 ? Jul 27 22:44:24 The difference is rather cosmetic Jul 27 22:44:30 Real pages, it shouldn't be changing much Jul 27 22:44:42 OK Jul 27 22:44:52 When you say website, I assume you are talking about the wiki Jul 27 22:44:57 I'll add things there Jul 27 22:45:08 I don't even think we still have a normal website Jul 27 22:45:21 yes, I mean website as in "somewere accessible via http on oe.org" :) Jul 27 22:45:54 I don't know how its all setup which is why I'd much rather someone who knows what they're doing does this ;-) Jul 27 22:49:14 I am having to think a bit how and where to add it Jul 27 22:49:26 I guess your section titles lend themselves to split things up Jul 27 22:49:45 But I wonder if having things spread out would be acceptable Jul 27 22:50:04 As long as we have somewhere that links to them all and its easily navigated... Jul 27 22:50:08 But there is not really one common theme under which to subsume things Jul 27 22:50:20 yes Jul 27 22:50:24 Yes, its all a bit disjointed like that... Jul 27 22:50:25 but what do you call that? Jul 27 22:50:30 We have the policy category Jul 27 22:50:40 But not all those things are policy Jul 27 22:50:51 Some talk about people and responsibilities Jul 27 22:50:57 others about resources Jul 27 22:51:01 Policy and Procedure? Jul 27 22:51:07 I am trying to find some common them to place this under Jul 27 22:51:28 I'll find something Jul 27 22:51:34 Things are mallable Jul 27 22:51:44 We can rename the pages if the need arises Jul 27 22:51:48 I'm sure you'll work wokring out :) Jul 27 22:51:49 indeed :) Jul 27 22:52:00 It was bad enough writing it in the first place ;-) Jul 27 22:52:08 I *bet*! Jul 27 22:52:12 My part is easy Jul 27 22:52:32 It's still a little task to come up with a theme Jul 27 22:52:36 Let's see Jul 27 22:53:24 How about http://wiki.openembedded.net/index.php/Openembedded_wiki:About Jul 27 22:53:26 ? Jul 27 22:53:31 That page is empty now Jul 27 22:53:45 And the stuff you wrote is kind of "what is OE?" Jul 27 22:53:51 what does it stand for Jul 27 22:54:08 I'll link the individual pages from there and put them in categories where appropriate Jul 27 22:54:45 I think having it under Policies may be more appropriate than about but its hard to say Jul 27 22:54:49 The About page is also accessible from every page on the wiki and if we want to we can add it to the navbar Jul 27 22:55:01 RP: We can have both Jul 27 22:55:07 Laibsch: ok :) Jul 27 22:55:52 I'm about to fall asleep at my desk so I'm going to call it a day ;-) Jul 27 22:55:58 'night all! Jul 27 22:56:06 good night Jul 27 23:00:35 Laibsch: I think it is possible to have a small grafic menu in the initramfs kernel to select the root device. Jul 27 23:00:50 great Jul 27 23:00:59 Have you been able to try it? Jul 27 23:01:33 I only collected the source code examples for different components. Jul 27 23:02:54 A textmenu should be simple, but I think we can even have something with framebuffer access (lines, rectangles text, bitmaps) **** ENDING LOGGING AT Mon Jul 28 02:59:56 2008