| 00:01.59 | *** join/#oe stephank (n=urk@2002:52c5:cfc7:1:2c0:9fff:feb7:e03f) |
| 01:34.00 | *** join/#oe BenLauDC (n=benlau@221.125.8.105) |
| 01:34.14 | *** join/#oe punk-ass (n=user@unaffiliated/punkass) |
| 01:38.56 | *** join/#oe bazbell (n=a0192809@nat/ti/x-876742087b7c5b3d) |
| 01:44.27 | *** part/#oe bazbell (n=a0192809@nat/ti/x-876742087b7c5b3d) |
| 01:53.30 | *** join/#oe punkass (n=user@unaffiliated/punkass) |
| 02:15.44 | *** join/#oe punk-ass (n=user@unaffiliated/punkass) |
| 02:18.32 | *** join/#oe jconnolly_ (n=jconnoll@cpe-24-90-254-170.nyc.res.rr.com) |
| 02:22.28 | *** join/#oe davygravy (n=davygrav@h69-128-156-59.mdtnwi.dsl.dynamic.tds.net) |
| 02:35.45 | *** join/#oe dijenerate (n=dijenera@72.51.71.55) |
| 02:44.38 | *** join/#oe chouimat (n=dieu@kde/developer/chouinard) |
| 03:11.42 | *** join/#oe chouimat (n=dieu@kde/developer/chouinard) |
| 03:14.59 | *** join/#oe radiochickenwax (n=user@m380e36d0.tmodns.net) |
| 03:16.09 | *** join/#oe FenX (n=darkstee@32.128.182.199) |
| 03:18.32 | *** part/#oe radiochickenwax (n=user@m380e36d0.tmodns.net) |
| 03:19.00 | *** join/#oe rsalveti (n=salveti@189.70.143.203) |
| 04:12.03 | *** join/#oe rsalveti_ (n=salveti@189.70.143.203) |
| 04:24.28 | *** join/#oe Sup3rkiddo (n=sudharsh@unaffiliated/sudharsh) |
| 04:42.16 | *** join/#oe dcordes_ (n=dcordes@unaffiliated/dcordes) |
| 05:02.22 | *** join/#oe mbuf (n=shakthim@59.92.40.3) |
| 05:23.51 | *** join/#oe mithro (n=tim@unaffiliated/mithro) |
| 07:11.57 | *** join/#oe pcgeil (n=steffen@p549E5DB3.dip.t-dialin.net) |
| 07:17.15 | *** join/#oe chouimat (n=dieu@r2351064.cidc.net) |
| 07:30.09 | CIA-24 | 03zecke123 07bitbake-1.8 * r1078 10/ (ChangeLog lib/bb/fetch/cvs.py): |
| 07:30.09 | CIA-24 | [cvs] Allow to checkout by date and time |
| 07:30.09 | CIA-24 | <PROTECTED> |
| 07:30.09 | CIA-24 | <PROTECTED> |
| 07:30.09 | CIA-24 | <PROTECTED> |
| 07:44.27 | CIA-24 | 03zecke123 * r1079 10bitbake/ (ChangeLog lib/bb/fetch/cvs.py): |
| 07:44.27 | CIA-24 | [cvs] Allow to checkout by date and time |
| 07:44.27 | CIA-24 | <PROTECTED> |
| 07:44.27 | CIA-24 | <PROTECTED> |
| 07:44.27 | CIA-24 | <PROTECTED> |
| 07:50.11 | *** join/#oe rschuster (n=rob@e178111218.adsl.alicedsl.de) |
| 07:51.27 | *** join/#oe shaz (i=shazkhan@116.58.110.18) |
| 07:57.07 | cdbot2 | * * OE Bug 4456 has been created by ka6sox(AT)nslu2-linux.org |
| 07:57.09 | cdbot2 | * * DNS Cache Poisoning Bug |
| 07:57.11 | cdbot2 | * * http://bugs.openembedded.net/show_bug.cgi?id=4456 |
| 08:18.13 | *** join/#oe JustinP (n=papercra@c-67-180-70-148.hsd1.ca.comcast.net) |
| 08:26.10 | *** join/#oe greentux (n=lemke@Z6c10.z.pppool.de) |
| 08:50.23 | *** join/#oe pb_ (n=pb@88-110-124-15.dynamic.dsl.as9105.com) |
| 08:51.57 | *** join/#oe trickie (n=trickie@a80-101-189-212.adsl.xs4all.nl) [NETSPLIT VICTIM] |
| 08:51.57 | *** join/#oe diego_ (n=diego@host-84-222-5-15.cust-adsl.tiscali.it) [NETSPLIT VICTIM] |
| 08:55.23 | *** join/#oe thesing (n=tkunze@BAA335d.baa.pppool.de) |
| 09:08.06 | thesing | morning all |
| 09:25.43 | CIA-24 | 03pb 07org.oe.dev * rede13d1b... 10/ (4 files in 3 dirs): |
| 09:25.43 | CIA-24 | font-misc-misc: re-add apparently deleted package with no obvious |
| 09:25.43 | CIA-24 | replacement |
| 09:25.56 | *** join/#oe kuzgun (n=deniz@unaffiliated/kuzgun) |
| 09:26.33 | kuzgun | hi |
| 09:26.36 | kuzgun | to make bitbake recipe for an application which uses WAF build system, which class should I inherit in my recipe? |
| 09:29.27 | thesing | 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) |
| 09:31.30 | kuzgun | this means no class exist to inherit? |
| 09:33.36 | *** join/#oe oxo_ (i=jorik@carbon.kippendief.biz) |
| 09:34.41 | *** join/#oe TheCan (n=thecan@dslb-088-067-139-075.pools.arcor-ip.net) |
| 09:40.40 | CIA-24 | 03pb 07org.oe.dev * r4d4881c0... 10/ (3 files in 2 dirs): snes9x: fix cross-compiling problem with 64 bit host |
| 09:46.20 | *** join/#oe thesing (n=tkunze@BAA335d.baa.pppool.de) |
| 09:57.45 | *** join/#oe Foolean (n=emil@foolean.ros.sgsnet.se) |
| 10:04.16 | CIA-24 | 03pb 07org.oe.dev * rddb3262e... 10/ (4 files in 2 dirs): openchrome: add 0.2.902 |
| 10:06.47 | *** join/#oe mbuf (n=shakthim@59.92.40.3) |
| 10:20.37 | *** join/#oe shaz (i=shazkhan@116.58.114.248) |
| 10:36.06 | CIA-24 | 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 |
| 10:36.12 | CIA-24 | 03mickeyl 07org.oe.dev * r27000390... 10/ (1 packages/images/fso-image.bb): fso-image: include dosfstools |
| 10:36.49 | *** join/#oe Laibsch (n=Laibsch@ip-62-143-12-162.hsi.ish.de) |
| 10:43.16 | pb_ | mickeyl: good morning |
| 10:45.03 | mickeyl | hi pb_ |
| 10:45.08 | mickeyl | good to see you commiting changes! |
| 10:45.17 | pb_ | heh :-) |
| 10:45.18 | mickeyl | unfortunately you will soon have to use another SCM |
| 10:45.23 | mickeyl | are you prepared for that? ;) |
| 10:45.28 | pb_ | doh! |
| 10:45.34 | pb_ | just when I had got used to monotone :-} |
| 10:45.37 | mickeyl | heh |
| 10:45.40 | pb_ | but sure, I am prepared :-) |
| 10:45.41 | mickeyl | i knew you were saying that |
| 10:45.42 | mickeyl | cool |
| 10:45.56 | mickeyl | we're right in the administrative struggle of moving to git |
| 10:46.18 | pb_ | right, very good |
| 10:46.25 | alphaone | yay! |
| 10:46.26 | pb_ | when do you plan to make the switch? |
| 10:46.53 | RP | as soon as we can get some agreement on a few issues. I think we're mostly there though |
| 10:47.02 | mickeyl | 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 |
| 10:47.09 | mickeyl | *nod* |
| 10:47.12 | pb_ | righto |
| 10:47.35 | thesing | I should hurry to commit some stuff just in case something doesn't work in the first weeks ;) |
| 10:47.51 | CIA-24 | 03pb 07org.oe.dev * rd31c1295... 10/ (4 files in 3 dirs): mesa-dri: fix 6.5.2 cross compilation error, add 7.0.3 |
| 10:47.56 | CIA-24 | 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 |
| 10:48.57 | pb_ | RP: just out of interest, what are the issues? |
| 10:50.15 | RP | pb_: Basically a question of how the OE project as a whole is managed, who gets to make decisions and how |
| 10:50.26 | *** join/#oe Zathras (n=zathras@92.243.163.7) |
| 10:50.30 | thesing | 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. |
| 10:50.39 | *** join/#oe Sleep_Walker (n=Sleep@gprs2.vodafone.cz) |
| 10:50.51 | RP | thesing: it does although it changed format in bitbake svn recently |
| 10:51.00 | RP | see the PARALLEL_MAKE stuff in bitbake.conf |
| 10:52.16 | RP | pb_: The plan is to make the existing core team more offical/public, at least until we come up with something better |
| 10:54.09 | pb_ | right, I see |
| 10:54.31 | thesing | 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. |
| 10:55.09 | RP | thesing: You can combine overrides |
| 10:55.57 | *** join/#oe BabelO (n=Fabrice@unaffiliated/babelo) |
| 10:56.21 | RP | thesing: and yes, you should be able to override a task |
| 10:56.57 | thesing | I'll try with a non_empty task. |
| 10:57.56 | pb_ | yeah, there should be loads of examples of task overrides in the existing .bb files |
| 11:00.21 | thesing | I only found the prepend and append stuff |
| 11:00.43 | RP | thesing: do_compile_someoverride () { should just work |
| 11:02.09 | thesing | so we can't have a distro/machine etc. called "prepend" or "append" ;) |
| 11:02.32 | pb_ | not without changing OVERRIDES, no. |
| 11:02.55 | *** join/#oe nslu2-log (n=nslu2-lo@limax.nslu2-linux.org) |
| 11:03.16 | RP | pb_: append and prepend are embedded in bitbake's core so I doubt even changing overrides would help |
| 11:03.54 | pb_ | RP: right, but he could re-jig overrides to mention, for example "distro-${DISTRO}" rather than just ${DISTRO} |
| 11:04.14 | pb_ | then, writing "do_install_prepend_distro-append" would do what you expected |
| 11:05.13 | thesing | lets hope that it doesn't come to that. |
| 11:05.15 | RP | pb_: ah, yes :). My favourite is the PN override which works like that |
| 11:05.51 | pb_ | right, yeah, that's for the same reason. |
| 11:06.15 | pb_ | 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 |
| 11:06.24 | thesing | another thing. is there a way to remove sth. from PROVIDES? -= doesn't seem to exist. |
| 11:07.02 | RP | pb_: There doesn't seem to be the need at present... |
| 11:07.37 | RP | 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 |
| 11:08.50 | pb_ | thesing: I thought there was a "_delete" thing, similar to _append, but it doesn't seem to exist so maybe I imagined it. |
| 11:09.03 | RP | There isn't a delete |
| 11:09.08 | pb_ | of course, you can munge PROVIDES any way you like using python |
| 11:09.29 | pb_ | RP: why would changing the override character make the parser faster? |
| 11:10.09 | RP | pb_: Because at the moment we note every variable name with a _ in as being potentially overrideable |
| 11:10.33 | RP | This made bitbake a lot faster since we could make override expansion faster |
| 11:10.51 | RP | but there are lots of false positives with _ in the name |
| 11:10.53 | pb_ | are there a large proportion of variable names with "_" that aren't actually overrides? |
| 11:10.59 | RP | yes :( |
| 11:11.12 | RP | SRC_URI. TARGET_OS TARGET_ARCH |
| 11:11.17 | RP | etc. |
| 11:11.37 | RP | I did once propose removing the _ and replacing with something else |
| 11:11.43 | pb_ | oh, right, yeah |
| 11:11.48 | RP | but swapping _ for . seems neater |
| 11:12.24 | pb_ | 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. |
| 11:13.03 | pb_ | 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. |
| 11:13.30 | RP | The one thing in its favour is that bitbake could override on both for a while, even maybe as a configurable option |
| 11:13.39 | RP | so we could transition to it without a flag day |
| 11:14.11 | pb_ | possibly, but of course you won't get any benefit from it until you can turn off processing of _. |
| 11:14.52 | RP | true |
| 11:15.02 | RP | I think it wouldn't be that hard to convert OE.dev though |
| 11:15.04 | *** join/#oe BenLauDC (n=benlau@221.125.8.105) |
| 11:15.35 | thesing | one could use bitbake to replace _ with . in for override |
| 11:15.55 | RP | thesing: no, since we never know all possible overrides |
| 11:16.19 | thesing | I only meant for converting oe.dev. |
| 11:16.31 | pb_ | 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. |
| 11:16.42 | pb_ | well, not impossible, but much harder |
| 11:17.48 | RP | You'd just have to enable "_" handling in bitbake, then it would work |
| 11:18.00 | RP | at a price of some speed which if that bothered you... |
| 11:19.45 | pb_ | 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 ".". |
| 11:20.21 | RP | I'm assuming you could update the bitbake on the older branch |
| 11:20.21 | pb_ | 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. |
| 11:21.09 | pb_ | i.e. the parser would need to treat those two names as being actually lexically identical, not just two syntaxes for overriding. |
| 11:21.45 | RP | yes, that would need careful handling |
| 11:22.06 | pb_ | 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. |
| 11:23.19 | RP | pb_: So you still loathe the idea? |
| 11:23.35 | pb_ | well, I'm still far from convinced that it is worth the pain at the moment. |
| 11:23.41 | *** join/#oe Sleep-Walker (n=Sleep@gprs8.vodafone.cz) |
| 11:23.46 | pb_ | do you know what the actual speedup will be in percentage terms? |
| 11:24.02 | RP | If we seriously think about it I'd run some tests and give some real numbers |
| 11:25.17 | RP | We have made real progress in making bitbake faster but its getting harder to find significant speedups |
| 11:25.21 | pb_ | 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. |
| 11:26.39 | RP | pb_: Agreed. This idea has been floating around for over a year and we've not done anything yet for that reason |
| 11:27.09 | thesing | 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. |
| 11:27.26 | RP | The random churn is a problem with OE.dev - its a melting pot of many people's improvements |
| 11:28.12 | RP | Most of the churn is actually desireable but it does introduce the potential for problems :( |
| 11:28.24 | thesing | Well thats the price of fast development I think. |
| 11:28.59 | RP | exactly. We don't do too badly all things considered and if you want stablity there are solutions out there (e.g. poky) |
| 11:29.03 | thesing | And we have the stable branch for a reason. |
| 11:30.32 | thesing | 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. |
| 11:33.13 | CIA-24 | 03mickeyl 07org.oe.dev * r0506e17d... 10/ (1 conf/distro/include/moko-autorev.inc): moko-autorev.inc: yank strange character from file |
| 11:33.17 | CIA-24 | 03mickeyl 07org.oe.dev * r6973c76c... 10/ (1 conf/distro/include/sane-srcdates.inc): sane-srcdates.inc: remove strange character. my merger is broken |
| 11:33.40 | pb_ | 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. |
| 11:34.31 | pb_ | 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. |
| 11:35.26 | thesing | Of course. Breaking stuff this badly shouldn't be sone for 0.1% speed increase. |
| 11:35.48 | thesing | pb_: nearly all tasks have '_' |
| 11:36.42 | pb_ | sure, but there are a finite number of common task names and they are all enumerated in bitbake.conf. |
| 11:37.44 | thesing | This sounds if it could be slower than the actual solution. Finite can be quite large. |
| 11:39.21 | thesing | s/actual/current/ |
| 11:43.42 | pb_ | mm, seems hard to imagine that it would be slower. |
| 11:44.26 | pb_ | If I understand RP's point correctly he is worried about update_data() being something like O(N(overrideable vars)*N(overrides)). |
| 11:45.03 | pb_ | 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. |
| 11:45.33 | pb_ | 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 |
| 11:48.41 | thesing | 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? |
| 11:53.36 | thesing | pb_: more O(N(possible overidable variables)) |
| 11:55.48 | pb_ | why? |
| 11:57.58 | thesing | 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) |
| 11:59.25 | thesing | So your are right. |
| 11:59.36 | *** join/#oe Sleep_Talker (n=Sleep@gprs6.vodafone.cz) |
| 12:01.39 | RP | thesing: do_rootfs has the "nostamp" flag |
| 12:02.07 | RP | pb_: As you say it all comes down to numbers which is what I'd establish if we were to seriously consider it |
| 12:02.15 | thesing | RP: so its run despite nobody depending on it? |
| 12:02.56 | RP | well, you said A depends on it |
| 12:03.11 | thesing | yes but A is already build. |
| 12:03.26 | RP | but B is "nostamp" and will therefor always run |
| 12:03.36 | RP | To build A, it would have to build B |
| 12:04.07 | RP | Standard bitbake dehaviour doesn't look at the timestamp differences between two different packages A and B |
| 12:04.43 | RP | There is now the new stamp policy options which let it look at that though |
| 12:05.14 | thesing | how do I enable it? |
| 12:05.20 | *** join/#oe denix1 (n=denix@82.116.198.135) |
| 12:05.35 | *** part/#oe denix1 (n=denix@82.116.198.135) |
| 12:06.41 | RP | thesing: BB_STAMP_POLICY = "whitelist" (or "full") |
| 12:06.59 | RP | but be warned, it will do this for all stamps |
| 12:07.21 | thesing | does "full" work or should I use "whitelist"? |
| 12:07.36 | RP | are you using packaged staging? |
| 12:07.41 | thesing | yes |
| 12:08.04 | RP | use whitelist then |
| 12:08.17 | RP | That class sets up a suitable whitelist for you |
| 12:08.26 | thesing | Well new features have to be tested otherwise I could use stable ;) |
| 12:08.52 | RP | thesing: Just don't be surprised when half your build rebuilds ;-) |
| 12:09.11 | thesing | and this feature will for example rebuild everything if I change glibc right? |
| 12:09.22 | RP | pretty much, yes |
| 12:09.36 | thesing | and images will only rebuild when some stuff they use changed? |
| 12:09.51 | RP | no, images are still nostamp |
| 12:10.03 | RP | but A and B will rebuild since A depends on B |
| 12:11.10 | *** join/#oe timtimred (n=meh@82-34-50-106.cable.ubr02.chel.blueyonder.co.uk) |
| 12:11.45 | thesing | why are images nostamp? with the STAMP_POLICY it makes no sense to rebuild an image if nothing changed. |
| 12:12.41 | RP | bitbake just honors the nostamp flag |
| 12:15.03 | thesing | But you agree that we should remove that flag for images once the stamp policy is default? |
| 12:17.41 | RP | thesing: There are no plans to make the stamp policy default |
| 12:17.52 | RP | It should come down to user preference |
| 12:19.33 | thesing | that wouldn't change. We would only change the default setting. |
| 12:20.28 | RP | The current stamp policy needs the nostamp setting for images |
| 12:20.35 | RP | we can't remove that |
| 12:20.38 | RP | -> back later |
| 12:23.11 | thesing | khem, RP; the latest toolchain change broke BB_STAMP_POLICY = "whitelist" see: http://www.pastebin.ca/1084249 |
| 12:33.51 | *** join/#oe pcgeil (n=steffen@p549E5DB3.dip.t-dialin.net) |
| 12:42.57 | *** join/#oe greentux (n=lemke@Z6c10.z.pppool.de) |
| 12:45.27 | *** join/#oe mm1 (n=michal@81-208-36-95.ip.fastwebnet.it) |
| 12:46.14 | *** join/#oe rschuster (n=rob@e178111218.adsl.alicedsl.de) |
| 12:48.08 | *** join/#oe Gnutoo (n=gnutoo@host191-204-dynamic.41-79-r.retail.telecomitalia.it) |
| 12:53.00 | *** join/#oe stephank (n=urk@2002:52c5:cfc7:1:2c0:9fff:feb7:e03f) |
| 13:17.33 | *** join/#oe SorenHK (n=sorenhk@0x50a13df3.abnxx6.dynamic.dsl.tele.dk) |
| 13:29.04 | CIA-24 | 03pb 07org.oe.dev * r7de203ac... 10/ (4 files in 2 dirs): openchrome: adjust PACKAGES_DYNAMIC |
| 13:29.08 | CIA-24 | 03pb 07org.oe.dev * rbb233fef... 10/ (1 packages/tasks/task-mythfront.bb): mythfront: adjust dependencies |
| 13:33.48 | *** part/#oe rschuster (n=rob@e178111218.adsl.alicedsl.de) |
| 13:33.55 | Laibsch | thesing you can delete stuff with some python magic. It is very similar to sed, it may even use it. |
| 13:38.00 | *** part/#oe SorenHK (n=sorenhk@0x50a13df3.abnxx6.dynamic.dsl.tele.dk) |
| 13:40.11 | stephank | 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 |
| 13:41.05 | stephank | 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: |
| 13:41.07 | stephank | <PROTECTED> |
| 13:41.07 | stephank | <PROTECTED> |
| 13:41.42 | stephank | That's about all I understand about the problem. Busybox appears to be working fine with uClibc. :/ |
| 13:41.47 | pb_ | That sounds like a dynamic linker bug. I guess you should take it up with the uclibc people. |
| 13:42.52 | stephank | Okay, I'll post to their mailinglist then. Thanks. |
| 13:51.27 | *** join/#oe greentux (n=lemke@Z6c10.z.pppool.de) |
| 13:58.21 | *** join/#oe shaz (i=shazkhan@116.58.110.150) |
| 14:00.25 | *** part/#oe shaz (i=shazkhan@116.58.110.150) |
| 14:01.20 | *** join/#oe Sup3rkiddo (n=sudharsh@unaffiliated/sudharsh) |
| 14:05.35 | *** join/#oe zecke (n=ich@118-166-68-99.dynamic.hinet.net) |
| 14:08.07 | *** join/#oe montamer (n=vijay@203.199.213.130) |
| 14:15.57 | pb_ | hi zecke |
| 14:16.27 | zecke | ho |
| 14:16.49 | zecke | pb_: do you know the linux ECC code? for me it looks like we only store column parity in the OOB? |
| 14:17.22 | pb_ | zecke: I know it a bit, but I don't remember the details offhand |
| 14:17.33 | pb_ | let me have a look |
| 14:18.20 | zecke | 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) |
| 14:18.54 | pb_ | I think the default linux ecc algorithm is different to the samsung one, certainly |
| 14:20.39 | pb_ | are you looking at the code in nand_ecc.c, or in s3c2410.c? |
| 14:21.08 | zecke | pb_: right, but I think we only store the column parity... I wonder how useful this is compared to the column+row |
| 14:21.16 | zecke | pb_: s3c2410.c and nand_base.c |
| 14:22.05 | montamer | hi has anyone tried OE for avr32?? (atngw100) |
| 14:22.05 | zecke | 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 |
| 14:23.27 | pb_ | right |
| 14:23.36 | pb_ | what makes you think that only the column parity is stored? |
| 14:23.37 | *** join/#oe gnutoo_ (n=gnutoo@host191-204-dynamic.41-79-r.retail.telecomitalia.it) |
| 14:24.05 | montamer | for some reason its trying to build glibc instead of uclibc |
| 14:24.17 | montamer | my conf contains |
| 14:24.29 | montamer | MACHINE = "atngw100" |
| 14:24.29 | montamer | TARGET_OS = "linux-uclibc" |
| 14:24.29 | montamer | DISTRO = "angstrom-2008.1" |
| 14:24.52 | zecke | pb_: maybe I expect too much from the hardware but we ignore one byte from ECC0 and ECC1 completely |
| 14:25.09 | pb_ | hm, really? |
| 14:25.20 | pb_ | I think all three bytes that the hardware returns should be getting stashed in the oob |
| 14:26.42 | pb_ | I can't see anything obvious in the code that would prevent that happening. |
| 14:26.59 | pb_ | nand_write_page_hwecc() seems to save everything that ecc.calculate() returns |
| 14:27.22 | zecke | pb_: let me check, I think ECC0 contain four bytes for s3c2442... |
| 14:27.24 | *** join/#oe osas (n=nnnnnnnn@nslu2-linux/osas) |
| 14:27.34 | pb_ | oh, right. that would be different to the older chips. |
| 14:27.45 | pb_ | I'm pretty sure s3c2410/12 only calculates a three byte ecc |
| 14:28.06 | pb_ | if 244x uses a different algorithm then yeah, s3c2410.c is probably broken |
| 14:30.09 | pb_ | yah, I just checked my software implementation of the s3c2410 ecc and that only uses a three byte code. |
| 14:30.21 | zecke | pb_: it has s3c2440 code. okay I think I understand better now. ECC0 and ECC1 generate two kind of parities |
| 14:30.55 | zecke | ECC0 would generate 28bit parity, we save 3*8, so skip 4 bits... |
| 14:31.19 | pb_ | I see |
| 14:31.51 | zecke | and then I'm confused again (by the next page of the user manaul) |
| 14:32.06 | pb_ | let me download the user manual and have a look at what it says |
| 14:32.08 | zecke | "ECC MODULE FEATURES" |
| 14:32.51 | pb_ | what nand page size do you use? |
| 14:32.55 | zecke | anyway. I have patched uboot to write and read the ECC from hardware, and the kernel agrees with the values read and written |
| 14:32.59 | zecke | 2k (so large page) |
| 14:33.22 | pb_ | ah right, I guess that would account for the difference |
| 14:33.49 | pb_ | 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 |
| 14:34.33 | zecke | ecc size gets reduced to 256 byte in the kernel |
| 14:35.25 | zecke | (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... :) |
| 14:35.37 | zecke | pb_: anyway thanks for listening |
| 14:36.27 | pb_ | I see |
| 14:36.35 | pb_ | sorry, I don't know much about the large page support |
| 14:36.51 | zecke | :) |
| 14:37.28 | zecke | pb_: 2K page means that our erase block is of that size right? |
| 14:37.45 | pb_ | zecke: no, the erase block is usually bigger |
| 14:37.55 | pb_ | on small page nand you have 512 byte pages, 16k erase blocks |
| 14:38.44 | pb_ | I think large page nand has something like 64k or 128k erase blocks |
| 14:39.17 | zecke | 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... |
| 14:39.53 | pb_ | zecke: doh |
| 14:40.01 | pb_ | are you in taipei at the moment? |
| 14:40.16 | zecke | pb_: yes, leaving tuesday... if mother nature allows that |
| 14:40.30 | pb_ | heh, right |
| 14:40.59 | pb_ | funnily enough I nearly had to go to taipei this week as well, but in the end one of my colleagues went instead |
| 14:41.32 | pb_ | he flew out to HK yesterday, just in time to avoid the typhoon |
| 14:41.33 | zecke | 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... |
| 14:42.18 | pb_ | zecke: where do you see that your nand controller allows byte access? |
| 14:42.44 | zecke | pb_: imagination? |
| 14:42.47 | zecke | let me check |
| 14:44.17 | zecke | 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) |
| 14:44.42 | zecke | pb_: okay, so I do addressing of 2K pages and then NFDATA would fill with the data... |
| 14:45.18 | pb_ | pretty much |
| 14:45.53 | zecke | thanks |
| 14:45.56 | pb_ | the procedure for reading is more or less: |
| 14:46.19 | pb_ | write "read page" command to NFCMD |
| 14:46.37 | pb_ | write the page address (i.e. byte address / 2048) to NFADDR, 8 bits at a time, least significant bit first |
| 14:46.46 | pb_ | wait for the flash to say it's ready |
| 14:46.57 | pb_ | read data out of NFADDR |
| 14:48.02 | pb_ | 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 |
| 14:53.05 | pb_ | er, read data out of NFDATA, obviously, not NFADDR |
| 14:53.57 | zecke | thanks |
| 14:55.47 | pb_ | bbiab |
| 14:55.49 | pb_ | -> |
| 14:57.08 | CIA-24 | 03woglinde2 07org.oe.dev * rc167fd3c... 10/ (1 packages/classpath/classpath-native.inc): classpath-initial: fix libtool2 error |
| 15:08.09 | *** join/#oe chouimat (n=dieu@kde/developer/chouinard) |
| 15:42.37 | CIA-24 | 03thebohemian2 07org.oe.dev * r428b4f34... 10/ (3 files in 3 dirs): jamvm-initial 1.4.5: New recipe. |
| 15:42.42 | CIA-24 | 03thebohemian2 07org.oe.dev * rff3cafe7... 10/ (3 files in 2 dirs): |
| 15:42.42 | CIA-24 | classpath-native.inc: Set JAVAC through environment variable. |
| 15:42.42 | CIA-24 | classpath.inc: Set JAVAC through environment variable. |
| 15:42.47 | CIA-24 | 03thebohemian2 07org.oe.dev * r7d59915b... 10/ (3 files in 2 dirs): disapproval of revision 'ff3cafe77c935d7b92703d6844722054ef7f9774' |
| 15:42.52 | CIA-24 | 03thebohemian2 07org.oe.dev * r6ca499af... 10/ (3 files in 2 dirs): |
| 15:42.52 | CIA-24 | ecj-initial 3.4: New recipe for version 3.4. |
| 15:42.52 | CIA-24 | ecj-bootstrap-native 3.4: New recipe for version 3.4. |
| 15:42.57 | CIA-24 | 03thebohemian2 07org.oe.dev * r77bc5067... 10/ (3 files in 2 dirs): disapproval of revision '6ca499af1613b08ef437cfa3285ae0b2ed3fbfcb' |
| 16:05.03 | *** join/#oe dcordes (n=dcordes@unaffiliated/dcordes) |
| 16:11.20 | *** join/#oe TheCan (n=thecan@dslb-088-067-139-075.pools.arcor-ip.net) |
| 16:15.31 | pb_ | mickeyl: wb |
| 16:20.03 | Laibsch | 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 |
| 16:20.13 | mickeyl | thanx |
| 16:24.07 | pb_ | mickeyl: I am very pleased with myself, today I managed to build a mythfront-image with no errors :-) |
| 16:24.37 | pb_ | 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. |
| 16:25.36 | mickeyl | nice, that's progress |
| 16:25.38 | mickeyl | hehe |
| 16:25.44 | mickeyl | keep us updated |
| 16:25.48 | pb_ | will do :-) |
| 16:30.31 | *** join/#oe zecke (n=ich@118-166-68-99.dynamic.hinet.net) |
| 16:45.35 | *** join/#oe Gnutoo (n=gnutoo@host191-204-dynamic.41-79-r.retail.telecomitalia.it) |
| 16:48.26 | CIA-24 | 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 |
| 16:49.34 | mickey|bbl | hmm |
| 16:49.37 | mickey|bbl | Gdk-WARNING (recursed) **: Error converting from UTF-8 to STRING: Could not |
| 16:49.37 | mickey|bbl | >open converter from 'UTF-8' to 'ISO-8859-1' |
| 16:49.40 | mickey|bbl | ? |
| 16:51.26 | mickey|bbl | where's the gtk experts? |
| 16:51.54 | zecke | iconv |
| 16:52.14 | zecke | or xlib lacking stuff |
| 16:52.23 | zecke | (just a guess) |
| 16:52.41 | zecke | mickey|bbl: the alternative to the above would be to cherry-pick raster's xdg menu.xml changes |
| 16:53.23 | mickey|bbl | i guess some lib is missing |
| 16:53.47 | mickey|bbl | how is gtk+ converting charsets? |
| 16:53.55 | mickey|bbl | dlopening stuff? |
| 16:54.08 | zecke | mickey|bbl: glibc iconv IIRC |
| 16:54.15 | *** join/#oe woglinde (i=woglinde@e178118193.adsl.alicedsl.de) |
| 16:54.16 | zecke | mickey|bbl: this will dlopen |
| 16:54.20 | mickey|bbl | ah |
| 16:54.27 | woglinde | hi |
| 16:54.30 | mickey|bbl | let me check whether i have libiconv |
| 16:54.35 | zecke | glibc-localedata-... could be your friend |
| 16:54.51 | mickey|bbl | oh, something like that |
| 16:55.10 | woglinde | hms |
| 16:55.11 | zecke | mickey|bbl: flag days are fun... do you volunteer to unbrick neo sold in europe? :) |
| 16:55.19 | woglinde | monotone server hangs |
| 16:55.36 | woglinde | flag days? |
| 16:55.52 | mickey|bbl | zecke: unbricking? => michael shiloh |
| 16:56.11 | mickey|bbl | ok, there's not a single localedata installed by default |
| 16:56.16 | mickey|bbl | now which of those do i need... |
| 16:57.14 | zecke | mickey|bbl: sorry maybe it is gconv |
| 16:57.23 | woglinde | *g* |
| 17:00.28 | pb_ | mickey|bbl: yah, that means you lack the right iconv modules |
| 17:00.45 | mickey|bbl | hmm |
| 17:00.48 | mickey|bbl | but which ones |
| 17:01.02 | zecke | mickey|bbl: utf8 would be good :) |
| 17:01.07 | pb_ | iso8859 |
| 17:01.17 | mickey|bbl | hmm, oh, they aren't even built |
| 17:01.22 | pb_ | doh |
| 17:01.46 | mickey|bbl | bitbake iconv |
| 17:01.48 | mickey|bbl | bbl, dinner |
| 17:02.00 | pb_ | glibc-gconv-iso8859-1 is probably what you want |
| 17:02.14 | pb_ | judging from task-openmoko-toolchain-target.bb :-} |
| 17:02.27 | mickey|bbl | hmm |
| 17:02.29 | mickey|bbl | installed |
| 17:02.32 | mickey|bbl | no changes |
| 17:02.35 | mickey|bbl | do i need to make it known? |
| 17:02.59 | pb_ | not that I can think of |
| 17:03.18 | pb_ | oh, wait, what's your locale? |
| 17:03.34 | zecke | LC_ALL=hesse |
| 17:04.05 | pb_ | zecke: not that locale |
| 17:04.28 | woglinde | LOCALE=c is the best |
| 17:04.28 | zecke | pb_: just wanted to amuse mickeyl :) |
| 17:04.41 | pb_ | woglinde: no, C is the worst |
| 17:04.43 | pb_ | you want a utf-8 locale |
| 17:04.48 | pb_ | zecke: heh |
| 17:05.44 | woglinde | pb hm right |
| 17:09.19 | woglinde | dinner |
| 17:09.24 | woglinde | right |
| 17:10.09 | pb_ | bon appetit |
| 17:23.02 | CIA-24 | 03thesing 07org.oe.dev * rae83b5e0... 10/ (1 classes/kernel.bbclass): |
| 17:23.02 | CIA-24 | kernel.bbclass: -change initramfs-logic |
| 17:23.02 | CIA-24 | <PROTECTED> |
| 17:23.06 | CIA-24 | 03thesing 07org.oe.dev * r7627b0bc... 10/ (4 files in 2 dirs): |
| 17:23.06 | CIA-24 | add linux-kexeboot: a kernel with initramfs-kernel-image as initramfs |
| 17:23.06 | CIA-24 | <PROTECTED> |
| 17:23.11 | CIA-24 | 03thesing 07org.oe.dev * r9cf027e9... 10/ (5 files in 3 dirs): |
| 17:23.11 | CIA-24 | linux-rp 2.6.26:-update collie patch |
| 17:23.11 | CIA-24 | <PROTECTED> |
| 17:23.12 | CIA-24 | <PROTECTED> |
| 17:23.16 | CIA-24 | 03thesing 07org.oe.dev * r0f1c2075... 10/ (1 packages/images/initramfs-kexec-image.bb): initramfs-kexec-image: automagicly build cpio images too |
| 17:23.21 | CIA-24 | 03thesing 07org.oe.dev * ra4b0b9af... 10/ (1 packages/linux/linux-rp.inc): |
| 17:23.21 | CIA-24 | linux-rp.inc: override do_deploy for collie with empty function. Kernel |
| 17:23.23 | CIA-24 | <PROTECTED> |
| 17:23.26 | CIA-24 | 03thesing 07org.oe.dev * r778f5060... 10/ (1 files/device_table_add-mmc.txt): |
| 17:23.27 | CIA-24 | add device table that will create mmcblk0p1 file. |
| 17:23.29 | CIA-24 | <PROTECTED> |
| 17:23.31 | CIA-24 | <PROTECTED> |
| 17:23.33 | CIA-24 | <PROTECTED> |
| 17:23.35 | CIA-24 | 03thesing 07org.oe.dev * r35d00516... 10/ (3 files in 3 dirs): |
| 17:23.39 | CIA-24 | collie.conf: -make collie also use device-table with mmc added |
| 17:23.41 | CIA-24 | <PROTECTED> |
| 17:23.43 | CIA-24 | <PROTECTED> |
| 17:23.45 | CIA-24 | zaurus-2.6.inc: -add kernel to rootfs for collie |
| 17:23.47 | CIA-24 | <PROTECTED> |
| 17:24.22 | *** join/#oe waite (n=bwaite@c-24-91-252-221.hsd1.ma.comcast.net) |
| 17:34.02 | thesing | 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. |
| 17:38.56 | Laibsch | OK, I'll try to give it a go |
| 17:39.10 | mickey|bbl | hmm |
| 17:39.13 | mickey|bbl | nothing set as locale |
| 17:39.16 | mickey|bbl | trying C |
| 17:39.23 | mickey|bbl | err |
| 17:39.25 | mickey|bbl | utf8, that is |
| 17:40.08 | mickey|bbl | hmm, no |
| 17:40.12 | mickey|bbl | still the same complaint |
| 17:40.33 | mickey|bbl | wtf is gpe-scap doing there |
| 17:40.38 | mickey|bbl | it should not need to convert anything |
| 17:40.46 | mickey|bbl | just leave everything and things will be fine |
| 17:40.47 | mickey|bbl | *sigh* |
| 17:41.12 | mickey|bbl | or rather |
| 17:41.12 | mickey|bbl | gdk |
| 17:41.23 | zecke | mickey|bbl: attach strings to the x window :) |
| 17:41.38 | zecke | not that we have a way to display captions |
| 17:43.26 | mickey|bbl | i don't think it's a window title |
| 17:43.29 | mickey|bbl | but anyways |
| 17:43.39 | mickey|bbl | LOCALE=utf-8 at least changes something |
| 17:43.41 | mickey|bbl | i now get |
| 17:43.52 | mickey|bbl | locale not supported... |
| 17:43.55 | mickey|bbl | falling back to C |
| 17:43.55 | mickey|bbl | :D |
| 17:44.33 | mickey|bbl | why isn't gtk+ dragging all in it needs... |
| 17:44.45 | mickey|bbl | obviously it doesn't work without this locale foo |
| 17:44.49 | mickey|bbl | so it should DEPEND on it |
| 17:44.52 | mickey|bbl | or at least RRECOMMEND |
| 17:44.59 | mickey|bbl | *sigh* |
| 17:45.38 | mickey|bbl | or gpe-scap in this case. i don't know who's to blame |
| 17:45.42 | mickey|bbl | my openmoko-terminal2 works fine |
| 17:45.45 | mickey|bbl | (also in gtk) |
| 17:45.52 | CIA-24 | 03thebohemian 07org.oe.dev * r953ae6dd... 10/ (1 packages/classpath/classpath-native.inc): classpath-native: Fix typo in depends. |
| 17:46.40 | zecke | :) |
| 17:47.05 | mickey|bbl | (gpe-scap:2261): Gdk-WARNING **: |
| 17:47.08 | mickey|bbl | what's the 2261? |
| 17:47.22 | mickey|bbl | any chance i see where exactly it is going wrong? |
| 17:48.14 | zecke | pid |
| 17:48.36 | mickey|bbl | oh |
| 17:48.40 | mickey|bbl | well |
| 17:49.01 | mickey|bbl | i don't think i'm in the mood to insert debug statements into gpe-scap to fix it |
| 17:49.10 | mickey|bbl | i'll just leave it there for someone else to fix |
| 17:49.11 | mickey|bbl | *shrug* |
| 17:49.42 | zecke | it works with ASU... |
| 17:50.08 | mickey|bbl | yeah, because you install everything but the kitchen sink |
| 17:50.23 | mickey|bbl | obviously our metadata is broken |
| 17:50.37 | mickey|bbl | otherwise this would work even by installing a gtk app afterwards on a non-gtk image |
| 17:50.56 | zecke | we are even forced to ship the gtk moko theme :) |
| 17:51.08 | zecke | "forced" in terms of no one actually depends on it but everyone assumes |
| 17:54.55 | mickey|bbl | aah |
| 17:55.06 | mickey|bbl | <PROTECTED> |
| 17:55.06 | mickey|bbl | <PROTECTED> |
| 17:55.06 | mickey|bbl | <PROTECTED> |
| 17:55.19 | mickey|bbl | ??? |
| 17:55.50 | zecke | looks sane... :) |
| 17:55.55 | mickey|bbl | dunno whether this leads to the real error (could not save temporary png file) |
| 17:56.03 | mickey|bbl | i would not care about the warning |
| 17:56.06 | mickey|bbl | but it actually doesn't work |
| 17:56.14 | mickey|bbl | the real error popping up in a dialog box |
| 17:56.17 | mickey|bbl | (as written) |
| 17:56.32 | mickey|bbl | might be something completely different |
| 17:56.44 | mickey|bbl | considers rewriting gpe-scap |
| 17:57.11 | zecke | mickey|bbl: reuse :) |
| 17:57.26 | mickey|bbl | i tried |
| 17:57.30 | mickey|bbl | as you've seen... it didn't work |
| 17:57.39 | mickey|bbl | and now i can spend some days to find out what's wrong |
| 17:57.46 | mickey|bbl | or spend a couple of hours rewriting it |
| 17:57.53 | mickey|bbl | i guess that's the problem foss has... |
| 17:57.56 | mickey|bbl | *shrug* |
| 17:58.13 | mickey|bbl | well, enough ranting. lets forget this issue and talk about something nice |
| 17:58.20 | mickey|bbl | how's qt doing in OE? |
| 17:58.29 | mickey|bbl | i've seen koen changing a lot |
| 17:58.31 | zecke | the error is more likely in OE... |
| 17:58.45 | zecke | mickey|bbl: Yes, but I think the stuff koen is not testing broke badly... qt/x11 that is |
| 17:59.10 | zecke | 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 |
| 17:59.45 | zecke | mickey|bbl: also I need to start creating a keyname -> name + mail address map for mtn2git and fix that one bug... |
| 17:59.57 | mickey|bbl | yeah |
| 18:00.20 | zecke | mickey|bbl: let us talk about something nice, pretty people (male seldomy qualify) but not here :) |
| 18:00.37 | zecke | mickey|bbl: have you seen the reasoning behind replacing SRCREV with SRCPV in the asu branch? |
| 18:00.57 | mickey|bbl | no, sorry |
| 18:01.01 | mickey|bbl | i did not follow asu at all |
| 18:01.31 | zecke | mickey|bbl: you should. e.g. you can cvs co with date and time now :) |
| 18:01.57 | zecke | mickey|bbl: sane-srcrev for git has the issue that you can not upgrade packages afterwards (or like 50/50...) |
| 18:02.06 | Laibsch | mickey|bbl: gpe-scap dead upstream? |
| 18:02.16 | zecke | Laibsch: unlikely dead |
| 18:02.18 | Laibsch | Isn't florian maintaining it? |
| 18:02.40 | mickey|bbl | he is and i bet it works on all images for him |
| 18:02.55 | mickey|bbl | but like i said, it doesn't work when you just install it afterwards to a non-gtk image |
| 18:03.09 | mickey|bbl | which might rather be a metadata problem |
| 18:03.22 | Laibsch | Oh, I see |
| 18:03.34 | Laibsch | I just thought you should take it up with upstream |
| 18:03.43 | Laibsch | I'd assume florian to fix it |
| 18:03.59 | zecke | mickey|bbl: so if you put SRCREV in the PV and have a sane-srcrev, you lose... |
| 18:04.07 | mickey|bbl | sounds good |
| 18:04.13 | zecke | mickey|bbl: so I invented SRCPV which can be put into PV and will create a version number that allows upgrading... |
| 18:04.24 | mickey|bbl | good. being able to upgrade is always nice |
| 18:05.06 | zecke | mickey|bbl: I have to redo/improve the bitbake implementation... this would also split up BITBAKE_PV and PACKAGE_PV... |
| 18:09.01 | *** join/#oe bbradley (n=bbradley@78-105-167-16.zone3.bethere.co.uk) |
| 18:10.01 | *** join/#oe mr_nice (n=nice@91-65-161-148-dynip.superkabel.de) |
| 18:11.31 | *** join/#oe Crofton (n=balister@66-207-66-26.black.dmt.ntelos.net) |
| 18:12.13 | RP | 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 |
| 18:12.14 | *** join/#oe pb___ (n=pb@88-110-124-15.dynamic.dsl.as9105.com) |
| 18:13.02 | zecke | RP: I know :( |
| 18:13.11 | pb___ | mickey|bbl: yah, that locale thing is annoying. I thought there was a fix for it in the gpe task packages but apparently not. |
| 18:13.20 | pb___ | iirc, you basically just need to install a utf8 locale and select it as your current one |
| 18:13.29 | pb___ | wow, big thunderstorm we're having here |
| 18:13.46 | mickey|bbl | hmm could be, i don't have gpe-task installed |
| 18:14.02 | mickey|bbl | which package is the utf8 locale in? |
| 18:14.05 | zecke | RP: I think I mailed oe-dev back then, but yeah I have to merge that... |
| 18:14.08 | mickey|bbl | the gconv is installed |
| 18:14.22 | pb___ | mickey|bbl: I think all the standard locales are utf8 |
| 18:14.38 | pb___ | try "ipkg install locale-base-de-de" or some such |
| 18:14.40 | mickey|bbl | ok, so i can just install anyone |
| 18:14.41 | mickey|bbl | righto |
| 18:14.43 | mickey|bbl | doing that |
| 18:15.40 | pb___ | 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. |
| 18:15.57 | mickey|bbl | ah, that could be it |
| 18:16.04 | mickey|bbl | hmm... another construction site: |
| 18:16.06 | mickey|bbl | root@om-gta02:/etc/gtk-2.0# opkg install glibc-locale-en |
| 18:16.06 | mickey|bbl | An error ocurred, return value: 2. |
| 18:16.13 | mickey|bbl | thanks for the verbose information, opkg |
| 18:16.15 | mickey|bbl | *sigh* |
| 18:16.17 | mickey|bbl | not my day |
| 18:16.21 | zecke | :) |
| 18:16.49 | mickey|bbl | ok, -de works better |
| 18:16.52 | mickey|bbl | urghs |
| 18:16.53 | RP | Each time that happens with opkg, Thomas gets an email from me :) |
| 18:16.56 | mickey|bbl | this is dragging in HEAPS of packages |
| 18:17.02 | mickey|bbl | RP: excellent :) |
| 18:17.09 | mickey|bbl | in this case it means "can't find package" |
| 18:17.18 | *** join/#oe CSMan (n=csman@bas1-montreal42-1177928111.dsl.bell.ca) |
| 18:18.46 | mickey|bbl | ok, the de locale is installed |
| 18:19.04 | mickey|bbl | neither setting LOCALE=de nor LOCALE=de_DE makes the error go away |
| 18:19.14 | mickey|bbl | (first error, can't find locale) |
| 18:21.46 | *** join/#oe davygravy_ (n=davygrav@h69-128-156-59.mdtnwi.dsl.dynamic.tds.net) |
| 18:23.26 | pb___ | try LC_ALL rather than LOCALE |
| 18:23.36 | pb___ | I'm not entirely sure that the latter controls ctype. |
| 18:24.15 | woglinde | re |
| 18:24.23 | mickey|bbl | just tried that. same locale not supported |
| 18:24.31 | mickey|bbl | how can i check which locales actually are supported? |
| 18:24.36 | mickey|bbl | so i could just pick one |
| 18:25.05 | pb___ | hm, good question. what do you have in /usr/share/i18n/locales/? |
| 18:25.30 | mickey|bbl | root@om-gta02:/etc/gtk-2.0# ls -l /usr/share/i18n/locales |
| 18:25.30 | mickey|bbl | -rw-r--r-- 1 root root 6448 Jul 27 12:06 de_DE |
| 18:25.30 | mickey|bbl | -rw-r--r-- 1 root root 4809 Jul 27 12:06 de_LU |
| 18:25.30 | mickey|bbl | -rw-r--r-- 1 root root 111251 Jul 27 12:06 i18n |
| 18:25.36 | mickey|bbl | and a lot of translit* |
| 18:25.37 | pb___ | right, those are the source files |
| 18:25.41 | pb___ | what's in /usr/lib/locale? |
| 18:25.57 | mickey|bbl | root@om-gta02:/etc/gtk-2.0# ls -l /usr/lib/locale/ |
| 18:25.57 | mickey|bbl | -rw-r--r-- 1 root root 1276896 Jul 27 17:57 locale-archive |
| 18:26.09 | pb___ | hm. well, plenty in there. |
| 18:26.14 | mickey|bbl | yeah pretty much |
| 18:26.23 | pb___ | that's the new-style "all in one" glibc locale archive |
| 18:26.24 | mickey|bbl | isn't some postinst supposed to generate those once you install a localeà |
| 18:26.32 | mickey|bbl | ah |
| 18:26.36 | mickey|bbl | so that's ok so far? |
| 18:26.41 | pb___ | well, I would kind have expected you to be using the pregenerated binary locales, actually |
| 18:26.48 | pb___ | but yes, that's ok, there's nothing obviously wrong there. |
| 18:27.06 | pb___ | try "localedef --list-archive" on that locale-archive |
| 18:27.24 | mickey|bbl | root@om-gta02:/usr/lib/locale# localedef --list-archive locale-archive |
| 18:27.24 | mickey|bbl | de_LU |
| 18:27.24 | mickey|bbl | de_LU.utf8 |
| 18:27.33 | mickey|bbl | eeks |
| 18:27.40 | mickey|bbl | luxemburg? |
| 18:27.45 | mickey|bbl | and nothing else? |
| 18:28.21 | pb___ | oh dear |
| 18:28.40 | pb___ | well, heh, see if you can set LC_ALL=de_LU |
| 18:28.44 | mickey|bbl | yeah |
| 18:28.49 | mickey|bbl | makes the 'locale not found' away |
| 18:28.55 | mickey|bbl | but not the can't convert from utf8 to iso-... |
| 18:29.01 | pb___ | try de_LU.utf8 |
| 18:29.04 | mickey|bbl | same |
| 18:29.08 | pb___ | doh |
| 18:29.11 | mickey|bbl | *nod* |
| 18:29.40 | pb___ | can you check the postinst for glibc-localedata-de-de, see why it didn't generate that one? |
| 18:30.02 | pb___ | I guess it's possible that de_LU* is scrunged somehow and doesn't actually have the right charset |
| 18:31.06 | mickey|bbl | hmm |
| 18:31.13 | mickey|bbl | can't find the postinst |
| 18:31.16 | pb___ | oh |
| 18:31.22 | pb___ | well, that would explain why it didn't get generated :-} |
| 18:31.31 | pb___ | what does the postinst for the LU one say? |
| 18:31.40 | *** join/#oe zecke_ (n=ich@118-166-68-99.dynamic.hinet.net) |
| 18:31.47 | mickey|bbl | not present as well |
| 18:31.50 | pb___ | hm |
| 18:31.57 | mickey|bbl | should be in /usr/lib/ipkg/info, right? |
| 18:32.00 | pb___ | maybe it's locale-base-* that has the postinst, not glibc-localedata |
| 18:32.01 | mickey|bbl | i can see other postinst there |
| 18:32.01 | pb___ | right |
| 18:32.13 | mickey|bbl | ah right |
| 18:32.16 | mickey|bbl | locale-base- |
| 18:32.21 | pb___ | ah |
| 18:32.32 | mickey|bbl | the locale-base for -lu is present |
| 18:32.35 | mickey|bbl | for -de it's not |
| 18:33.05 | pb___ | oh dear |
| 18:33.15 | mickey|bbl | the LU one basically calls localedef --inputfile=/usr/share/i18n/locales/de_LU --charmap=UTF-8 --prefix=/tmp/locale de_LU |
| 18:33.22 | mickey|bbl | and then shuffles a locale-archive around |
| 18:33.26 | pb___ | right, yeah, that's correct |
| 18:33.45 | pb___ | the shuffling is necessary due to jffs2 limitations, locale-def will blow up if its output is on flash |
| 18:33.51 | mickey|bbl | right |
| 18:34.03 | mickey|bbl | so basically we have two problems |
| 18:34.03 | pb___ | so, looks like de_LU should indeed be utf8 |
| 18:34.12 | pb___ | but, clearly gtk doesn't agree |
| 18:34.12 | mickey|bbl | yeah, de_LU looks like utf8 |
| 18:34.16 | mickey|bbl | *nod* |
| 18:34.40 | pb___ | is there a straightforward way I can build an image to look at this for myself? |
| 18:34.50 | pb___ | say, something gtk based that will run in qemu on my laptop |
| 18:35.39 | mickey|bbl | if you require conf/distro/moko-autorev.inc and conf/distro/fso-autorev.inc |
| 18:35.43 | mickey|bbl | then you should be able to build fso-image |
| 18:35.49 | mickey|bbl | which includes gpe-scap |
| 18:35.56 | mickey|bbl | which is what i'm struggeling with |
| 18:36.05 | mickey|bbl | it doesn't contain the locales (as we have seen) |
| 18:36.09 | mickey|bbl | so you need to install taht as well |
| 18:37.06 | mickey|bbl | apparantly it's not a problem in the openmoko gtk image, so that seems to install all the neccessities |
| 18:37.23 | pb___ | ok, very good |
| 18:37.26 | mickey|bbl | but it's tough for me to say which package actually fixes it |
| 18:37.53 | pb___ | yeah, it's all a bit complex |
| 18:38.09 | pb___ | unfortunately I seem to be too senile to remember how that stuff works |
| 18:38.21 | pb___ | but, if I can actually see it on my own machine, maybe I can figure it out again |
| 18:39.32 | mickey|bbl | right. thanks a lot! |
| 18:39.37 | woglinde | so |
| 18:39.40 | mickey|bbl | taking a break now |
| 18:39.44 | mickey|bbl | bblk |
| 18:39.45 | woglinde | nexttry on gettext 0.17 |
| 18:39.48 | woglinde | bye mickeyl |
| 18:55.08 | *** join/#oe davygravy (n=davygrav@h69-128-156-59.mdtnwi.dsl.dynamic.tds.net) |
| 18:58.43 | pb___ | okay, build running |
| 18:58.49 | pb___ | had a bit of a false start when I forgot to set XSERVER |
| 19:00.55 | *** join/#oe zecke (n=ich@118-166-68-99.dynamic.hinet.net) |
| 19:01.08 | *** join/#oe BabelO (n=Fabrice@lun34-2-82-238-28-28.fbx.proxad.net) |
| 19:05.26 | woglinde | re zecke |
| 19:05.40 | zecke | thanks |
| 19:09.18 | *** join/#oe punkass (n=user@unaffiliated/punkass) |
| 19:10.24 | *** join/#oe dcordes (n=dcordes@f048040081.adsl.alicedsl.de) |
| 19:27.03 | *** join/#oe greentux (n=lemke@Z6c10.z.pppool.de) |
| 19:45.52 | *** join/#oe bbradley_ (n=bbradley@78-105-167-16.zone3.bethere.co.uk) |
| 20:08.06 | *** join/#oe flo_lap (n=fuchs@g227112210.adsl.alicedsl.de) |
| 20:17.43 | woglinde | e flo |
| 20:18.24 | *** join/#oe bluelightning (n=blueligh@pdpc/supporter/active/bluelightning) |
| 20:19.42 | flo_lap | hi all |
| 21:10.09 | *** join/#oe bluebugs (n=cedric@mieuh.bluebugs.org) |
| 21:28.00 | *** join/#oe ant__ (n=ant@host46-250-dynamic.2-87-r.retail.telecomitalia.it) |
| 21:31.27 | *** join/#oe diego (n=diego@host-84-223-44-94.cust-adsl.tiscali.it) |
| 21:33.09 | ant__ | wonders if somebody tried TMPDIR = "/OE/${DISTRO}-tmp/" (http://www.angstrom-distribution.org/building-angstrom) |
| 21:33.37 | ant__ | ant__> http://www.pastebin.ca/1083734 |
| 21:33.37 | ant__ | <ant__> http://www.pastebin.ca/1083738 |
| 21:33.55 | ant__ | fails miserably... |
| 21:35.06 | ant__ | note the mistyped /oe/angstrom-tmp//staging/i686-linux/usr/lib |
| 21:35.55 | ant__ | one '/' too much in TMPDIR ? |
| 21:36.23 | ant__ | but then you look at the examples BBPATH and PKGDIR, both terminated by slash |
| 21:36.48 | ant__ | what is the correct policy to designate these BB paths? |
| 21:37.16 | ant__ | I know it's harmful, but then... |
| 21:38.08 | ant__ | one would expect sane examples! |
| 21:38.52 | ant__ | pls just one confirmation before opening a bug |
| 21:55.49 | NAiL | ant__: A double / doesn't do any harm at all |
| 21:57.10 | ant__ | hi NAiL |
| 21:57.43 | CIA-24 | 03mickeyl 07org.oe.dev * r5bb4bd3c... 10/ (1 packages/freesmartphone/freesmartphone-feed-configs.bb): add freesmartphone-feed-configs |
| 21:58.16 | ant__ | NAiL: I know, these slash are not the issue |
| 22:08.20 | ant__ | NAiL: TMPDIR = "/oe/build/tmp/${DISTRO}" (as it was) and the issue disappears |
| 22:08.45 | ant__ | under /build |
| 22:18.53 | *** join/#oe jtaji (n=jtaji@unaffiliated/astro76) |
| 22:20.05 | CIA-24 | 03Richard Purdie <rpurdie@rpsys.net> 07test1 * re8da60446a 10OE.dev/MAINTAINERS: |
| 22:20.05 | CIA-24 | Fix misplaced entry in MAINTAINERS |
| 22:20.05 | CIA-24 | Signed-off-by: Richard Purdie <rpurdie@rpsys.net> |
| 22:20.05 | CIA-24 | 03Richard Purdie <rpurdie@rpsys.net> 07test1 * r94d5595dda 10OE.dev/: Merge branch 'master' of ssh://gittrial@git.openembedded.net//org.openembedded.dev |
| 22:20.31 | RP | heh :) |
| 22:22.04 | woglinde | hi rp |
| 22:22.07 | woglinde | ~seen khem |
| 22:22.08 | ibot | 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'. |
| 22:22.10 | RP | hi woglinde |
| 22:23.41 | woglinde | hm I trigger cannot convert 'const __ctype_touplow_t*' to 'const int*' in assignment |
| 22:23.50 | woglinde | there is an gcc patch since 2006 |
| 22:23.54 | woglinde | but why I am trigger this now |
| 22:24.07 | woglinde | with latest uclibc and gcc-4.3.1 |
| 22:25.02 | woglinde | and in the uclibc tracker is only the link to the attachment not the bugreport |
| 22:41.48 | Laibsch | RP: ping |
| 22:41.51 | Laibsch | still there? |
| 22:42.00 | RP | Laibsch: yes |
| 22:42.26 | Laibsch | OK |
| 22:42.29 | Laibsch | Just got your mail |
| 22:42.43 | RP | Laibsch: everything ok with it? |
| 22:43.08 | Laibsch | Well, I guess so |
| 22:43.16 | Laibsch | I have not really read through it |
| 22:43.22 | Laibsch | I've got two questions |
| 22:43.30 | Laibsch | Should this be on a single page? |
| 22:43.39 | Laibsch | I'm not sure that is appropriate |
| 22:43.51 | RP | Possibly not, no |
| 22:44.02 | Laibsch | OK, I'll see about something |
| 22:44.16 | Laibsch | You want real pages or should we keep this in a discussion page for now |
| 22:44.17 | Laibsch | ? |
| 22:44.23 | Laibsch | The difference is rather cosmetic |
| 22:44.30 | RP | Real pages, it shouldn't be changing much |
| 22:44.41 | Laibsch | OK |
| 22:44.52 | Laibsch | When you say website, I assume you are talking about the wiki |
| 22:44.57 | Laibsch | I'll add things there |
| 22:45.07 | Laibsch | I don't even think we still have a normal website |
| 22:45.21 | RP | yes, I mean website as in "somewere accessible via http on oe.org" :) |
| 22:45.54 | RP | I don't know how its all setup which is why I'd much rather someone who knows what they're doing does this ;-) |
| 22:49.14 | Laibsch | I am having to think a bit how and where to add it |
| 22:49.26 | Laibsch | I guess your section titles lend themselves to split things up |
| 22:49.45 | Laibsch | But I wonder if having things spread out would be acceptable |
| 22:50.04 | RP | As long as we have somewhere that links to them all and its easily navigated... |
| 22:50.08 | Laibsch | But there is not really one common theme under which to subsume things |
| 22:50.20 | Laibsch | yes |
| 22:50.24 | RP | Yes, its all a bit disjointed like that... |
| 22:50.25 | Laibsch | but what do you call that? |
| 22:50.30 | Laibsch | We have the policy category |
| 22:50.39 | Laibsch | But not all those things are policy |
| 22:50.51 | Laibsch | Some talk about people and responsibilities |
| 22:50.57 | Laibsch | others about resources |
| 22:51.01 | RP | Policy and Procedure? |
| 22:51.07 | Laibsch | I am trying to find some common them to place this under |
| 22:51.27 | Laibsch | I'll find something |
| 22:51.34 | Laibsch | Things are mallable |
| 22:51.43 | Laibsch | We can rename the pages if the need arises |
| 22:51.48 | RP | I'm sure you'll work wokring out :) |
| 22:51.49 | RP | indeed :) |
| 22:52.00 | RP | It was bad enough writing it in the first place ;-) |
| 22:52.07 | Laibsch | I *bet*! |
| 22:52.12 | Laibsch | My part is easy |
| 22:52.32 | Laibsch | It's still a little task to come up with a theme |
| 22:52.35 | Laibsch | Let's see |
| 22:53.24 | Laibsch | How about http://wiki.openembedded.net/index.php/Openembedded_wiki:About |
| 22:53.26 | Laibsch | ? |
| 22:53.31 | Laibsch | That page is empty now |
| 22:53.45 | Laibsch | And the stuff you wrote is kind of "what is OE?" |
| 22:53.51 | Laibsch | what does it stand for |
| 22:54.07 | Laibsch | I'll link the individual pages from there and put them in categories where appropriate |
| 22:54.45 | RP | I think having it under Policies may be more appropriate than about but its hard to say |
| 22:54.49 | Laibsch | The About page is also accessible from every page on the wiki and if we want to we can add it to the navbar |
| 22:55.00 | Laibsch | RP: We can have both |
| 22:55.07 | RP | Laibsch: ok :) |
| 22:55.52 | RP | I'm about to fall asleep at my desk so I'm going to call it a day ;-) |
| 22:55.58 | RP | 'night all! |
| 22:56.06 | Laibsch | good night |
| 23:00.35 | thesing | Laibsch: I think it is possible to have a small grafic menu in the initramfs kernel to select the root device. |
| 23:00.50 | Laibsch | great |
| 23:00.59 | Laibsch | Have you been able to try it? |
| 23:01.33 | thesing | I only collected the source code examples for different components. |
| 23:02.54 | thesing | A textmenu should be simple, but I think we can even have something with framebuffer access (lines, rectangles text, bitmaps) |
| 23:03.46 | *** join/#oe dijenerate (n=dijenera@72.51.71.55) |
| 23:14.11 | *** join/#oe dcordes_ (n=dcordes@unaffiliated/dcordes) |
| 23:14.19 | *** join/#oe dijenerate (n=dijenera@72.51.71.55) |