| 00:00.32 | jsun | more output from evtest after I touched the screen |
| 00:00.35 | jsun | http://channels.debian.net/paste/2359 |
| 00:01.10 | zecke|baking | looks good right? |
| 00:01.37 | zecke|baking | start ts_print_raw using strace and see what file gets opened |
| 00:01.45 | jsun | looks good to me - : |
| 00:03.08 | mreimer | jsun: try http://sermons.desiringGod.org/~mreimer/Xfbdev |
| 00:03.22 | jsun | hmm, I need to bitbake strace ... starting ... |
| 00:03.32 | jsun | mreimer, anything special in that? |
| 00:03.56 | mreimer | not really, just an Xfbdev built by OE that I know has evdev support |
| 00:04.01 | mreimer | maybe yours doesn't |
| 00:05.43 | jsun | mine is built by OE tho. |
| 00:06.18 | mreimer | should be good then |
| 00:06.27 | *** join/#oe marcan (n=marcanso@160.10.7.105) |
| 00:07.36 | jsun | zecke|baking, when I uncomment ucb1x00, I got output from ts_print. |
| 00:07.56 | jsun | when I uncomment module_raw input, I don't. |
| 00:08.03 | zecke|baking | jsun: that doesn't sound right |
| 00:08.13 | zecke|baking | jsun: and evtest works with the device as well |
| 00:08.16 | jsun | I am puzzled. |
| 00:08.33 | zecke|baking | jsun: ucb1x00 just reads 32 bit IIRC and prints the values |
| 00:08.51 | zecke|baking | jsun: module_raw input tries to open it as a special device and does a sanity check |
| 00:13.24 | polyonymous | zecke|baking, if I have .bb that has include and modify inc and then reparse it, why being smart and say file has not been updated instead of reparsing? :) |
| 00:14.03 | zecke|baking | polyonymous: it doesn't know about internal file dependencies |
| 00:14.12 | zecke|baking | polyonymous: can emerge do that? |
| 00:14.18 | polyonymous | yes, but if I say reparse why not just reparse? |
| 00:14.30 | zecke|baking | polyonymous: ah the shell, ask mickeyl ;) |
| 00:14.37 | polyonymous | I see :) |
| 00:14.39 | RP | 'night all |
| 00:14.50 | polyonymous | Well, that's no prob to touch, it's just that it's a bit weird. |
| 00:14.52 | zecke|baking | RP: cya |
| 00:15.36 | polyonymous | I think emerge doesn't need it, it parses needed ebuilds at each startup... |
| 00:16.36 | polyonymous | zecke|baking, another question... I'm trying to build pwmpi and I have gcrypt stuff in staging. pwmpi has its own copy, but it gets in the include list after the staged version. Can I prepend -I ? |
| 00:17.16 | zecke|baking | polyonymous: actually this is what should always happen... |
| 00:17.32 | zecke|baking | polyonymous: we slightly abuse C(XX)FLAGS and place -I${STAGING_INCDIR} there |
| 00:17.47 | zecke|baking | polyonymous: packages should always put their includes in front of that :} |
| 00:17.49 | polyonymous | Well, in the resulting build it has staging before local includes... |
| 00:18.04 | polyonymous | I'm worse with qmake than I am with autotools... |
| 00:18.23 | polyonymous | Not sure how it builds those makefiles... |
| 00:18.33 | zecke|baking | polyonymous: ah that is qmake |
| 00:18.38 | polyonymous | but it definitely goes after staging stuff. |
| 00:18.40 | polyonymous | yes, that is it. |
| 00:18.52 | zecke|baking | polyonymous: and it is from lutz (the pi guy)... |
| 00:18.59 | polyonymous | should be something like prepending to OE_QMAKE_CFLAGS ? |
| 00:19.11 | polyonymous | what is from the pi guy? |
| 00:19.22 | polyonymous | the .bb? |
| 00:19.24 | zecke|baking | polyonymous: what is wrong with the not forked version of libgcrypt? |
| 00:19.38 | polyonymous | it even has different prototypes |
| 00:19.41 | jsun | zecke|baking, with "module_raw input" uncommented, I see ts_print open /dev/input/event1 (which is correct), and also read data when I touch screen, however, it does not output anything. |
| 00:19.55 | jsun | make any sense? |
| 00:20.10 | *** join/#oe katossi_ (n=guillerm@dslb-084-062-164-025.pools.arcor-ip.net) |
| 00:20.11 | polyonymous | I'm not sure that porting it to the staged gcrypt is the way to go. |
| 00:20.12 | zecke|baking | polyonymous: ouch, pester lutz to use the official one |
| 00:20.27 | polyonymous | could it be that he's had a reason for using local copy? |
| 00:20.40 | zecke|baking | polyonymous: well why would you want to keep two copies of a security critical library? |
| 00:20.57 | zecke|baking | polyonymous: which version do you trust more? Lutz one? or the upstream source code? |
| 00:21.04 | zecke|baking | (from a distribution point of view) |
| 00:21.20 | polyonymous | zecke|baking, you're perfectly right, but I don't know his reasons. |
| 00:21.32 | zecke|baking | polyonymous: he is not a team player at all |
| 00:21.51 | polyonymous | well, neither I am ;-) |
| 00:21.58 | zecke|baking | polyonymous: he has forked most of Opie just to implement Button Order for tab focus (well that is not completely true) |
| 00:22.18 | polyonymous | :))) |
| 00:22.34 | zecke|baking | polyonymous: he has forked ~6 Opie applications for no good reason |
| 00:22.35 | polyonymous | well, then it doesn't make sense to fight over crypt issue, easier to just make it work. |
| 00:23.41 | polyonymous | or do you suggest that we fork kdepim to make it work with stock gcrypt? :) |
| 00:23.44 | zecke|baking | polyonymous: try QMAKE_VARSUBST_PRE += "INCLUDEPATH+=private-gcrypt/include" |
| 00:23.52 | polyonymous | Aha, thank yuo |
| 00:24.56 | polyonymous | and thank you too :) |
| 00:25.06 | zecke|baking | polyonymous: if that doesn't work, we need to play tricks to QMAKE_CC or QMAKE_CXX |
| 00:25.12 | polyonymous | didn't work though... |
| 00:25.14 | zecke|baking | using the VARSUBST_PRE thing |
| 00:25.16 | zecke|baking | okay |
| 00:26.08 | zecke|baking | OE_QMAKE_CC_append = "-I...." |
| 00:26.12 | zecke|baking | OE_QMAKE_CXX_append = "-I...." |
| 00:26.20 | zecke|baking | and see what is hapening |
| 00:26.27 | zecke|baking | skip the first two lines of my reply |
| 00:26.39 | polyonymous | maybe OE_QMAKE_CFLAGS_append? is there such thing? or is it too late? |
| 00:26.46 | zecke|baking | just in your .bb file (like any other variable) doe OE_QMAKE_CC_append = "-I" |
| 00:27.07 | zecke|baking | I'm currently looking at packages/qmake/files/linux-oe-qmake.conf |
| 00:27.24 | polyonymous | in fact, I'm already trying my version, I enetered it before you suggested yours |
| 00:27.28 | polyonymous | entered |
| 00:27.38 | zecke|baking | ah good, keep that then ;) |
| 00:27.57 | polyonymous | and well, I got different error, must be another fork :) |
| 00:28.15 | polyonymous | this seems to have worked: OE_QMAKE_CFLAGS_prepend="-I${S}/pwmanager/libcrypt/mpi/crypt" |
| 00:28.25 | zecke|baking | jsun: http://cvs.arm.linux.org.uk/cgi/viewcvs.cgi/tslib/plugins/input-raw.c?rev=HEAD&content-type=text/vnd.viewcvs-markup |
| 00:28.44 | zecke|baking | polyonymous: maybe add a ' ' |
| 00:28.49 | zecke|baking | to the end |
| 00:28.55 | polyonymous | makes sense. |
| 00:29.42 | polyonymous | Although I think there was a space, otherwise build would be shorter, not longer :)) |
| 00:29.50 | zecke|baking | hehe |
| 00:30.34 | polyonymous | weird.... after adding space it's back to the error #1... |
| 00:30.39 | polyonymous | but it's clearly impossible |
| 00:30.48 | polyonymous | and the -I is there. |
| 00:31.42 | polyonymous | nevermind, I put the wrong path :) |
| 00:39.12 | polyonymous | built it. |
| 00:47.32 | polyonymous | well, goodnight everybody |
| 00:58.18 | zecke|baking | gosh I hate svk |
| 01:31.51 | *** join/#oe W8TVI_ (n=me@166.165.155.93) |
| 01:46.30 | *** join/#oe wrobbie (n=rob@cm7.sigma181.maxonline.com.sg) |
| 02:03.06 | TheMasterMind1 | anyone alive still? |
| 02:03.20 | NAbyss | Yep |
| 02:06.19 | TheMasterMind1 | are the assumptions in the following patch correct http://sourceware.org/ml/newlib/2004/msg00046.html |
| 02:07.24 | NAbyss | No idea.. |
| 02:07.46 | NAbyss | Ask RP? |
| 02:08.53 | TheMasterMind1 | when's he around i guess |
| 02:18.39 | *** join/#oe Crofton (n=balister@66-207-66-26.black.dmt.ntelos.net) |
| 02:23.56 | *** join/#oe dijenerate_ (n=dijenera@69.73.206.63) |
| 02:30.28 | *** join/#oe cesar- (n=cesar@pool-71-104-222-113.lsanca.dsl-w.verizon.net) |
| 02:55.05 | *** join/#oe johnX (n=john@c-24-16-192-158.hsd1.wa.comcast.net) |
| 03:05.12 | jnc | bugger, debian sid (unstable) is currently with an broken Xorg transition period |
| 03:05.21 | jnc | heck of a time for me to try to upgrade :P |
| 03:05.31 | NAbyss | jnc: Yeah, I've been putting off my apt-get upgrades for a few days.. |
| 03:05.48 | jnc | good idea. neat stuff though, it's not executing or doing useful work yet |
| 03:06.12 | jnc | the split has happened. Xorg modularization is now in effect, and /usr/X11R6 is disappearing ;) |
| 03:07.19 | jnc | most of the parts are arranged as of tonight, except video and input modules |
| 03:07.35 | jnc | kind of makes it tough to run X11 without video or input modules, y'know =) |
| 03:07.43 | NAbyss | True =) |
| 03:07.57 | jnc | i see my nick highlighted while i was away |
| 03:08.02 | jnc | happen to know what i missed? |
| 03:08.29 | NAbyss | Nah, can't see it from flicking back |
| 03:08.44 | TheMasterMind1 | nothing in my history here |
| 03:08.55 | jnc | thanks |
| 03:09.02 | jnc | how y'all been? |
| 03:09.24 | NAbyss | Not too bad; and yourself? |
| 03:09.41 | jnc | depriving myself of sleep sometimes. okay though! |
| 03:10.04 | TheMasterMind1 | watching bitbake build its cache, as usual |
| 03:10.13 | jnc | heh |
| 03:10.17 | jnc | that annoys me |
| 03:10.35 | jnc | i wait all this time for bitbake to build a cache, and then it seems like the cache never speeds anything up |
| 03:11.38 | jnc | TheMasterMind1: which embedded hardware are you using? |
| 03:12.35 | TheMasterMind1 | gumstix |
| 03:12.42 | TheMasterMind1 | i also have a 5500 |
| 03:13.14 | TheMasterMind1 | if i have a-type1.bb and a-type2.bb and both have provides=a in them, how can i make one preferred |
| 03:14.40 | *** join/#oe tmbinc (i=XXX@e176171064.adsl.alicedsl.de) |
| 03:16.49 | jnc | ooh gumstix. don't know much about it |
| 03:17.05 | CoreDump|afk | PREFERRED_PROVIDER_a = "a-type2" should do |
| 03:17.10 | jnc | could you explain an example use of gumstix hardware in real world application? |
| 03:17.28 | *** join/#oe punk-ass (n=user@ptbynynas01pool0-a132.ptbyny.tds.net) |
| 03:19.40 | TheMasterMind1 | jnc: there's many projects out there, just look at gumstix.com or search google |
| 03:19.50 | jnc | oh |
| 03:20.01 | jnc | i meant, more specifically what /you/ use it for |
| 03:20.36 | TheMasterMind1 | robotics |
| 03:21.24 | TheMasterMind1 | with the robostix attachment we can write linux progs in c/java/python/whatever to control inputs and motors and use bluetooth to ssh in wirelessly or communicate amongst robots |
| 03:22.01 | jnc | holy laz0r beam. |
| 03:23.37 | TheMasterMind1 | they're being developed primarily for graduate research on swarm robotics |
| 03:24.29 | TheMasterMind1 | i.e. how swarms of fish and flock of birds move in groups without hitting each other, and how ants work collectively to gather food |
| 03:24.52 | jnc | i've often wondered that, watching the gulls gather outside a datacenter parking lot |
| 03:25.08 | jnc | why is it they poop on everyone's car except mine? |
| 03:25.17 | jnc | i feel so left out |
| 03:26.36 | TheMasterMind1 | <PROTECTED> |
| 03:26.37 | TheMasterMind1 | finally |
| 03:33.38 | *** join/#oe aquadran_ (i=pablo@scummvm/undead/aquadran) |
| 03:39.26 | *** join/#oe benlau (n=benlau@221.125.13.158) |
| 03:48.24 | cyrus__ | I am trying to compile glibc for an ARM processor. I am getting an error since an include file (link.h) has one line in it that says it needs to be defined for the target platform. My question is, how do I find out what definitions are suppose to be in link.h |
| 03:49.24 | JustinP | jnc: the cache makes it *much* faster |
| 03:49.39 | JustinP | jnc: the first run is very slow, then subsequent ones are much faster |
| 03:49.49 | JustinP | jnc: may not be if you didn't install psyco, though |
| 03:49.59 | jnc | JustinP: psyco is no-go on my platform |
| 03:50.05 | jnc | :/ |
| 03:50.21 | jnc | could cache be disabled if psyco is not there? |
| 03:51.21 | johnX | jnc: just try blowing away the cache and see if it slows down... |
| 03:51.46 | jnc | it's about the same, i've tried that out of curiosity |
| 03:52.01 | cyrus__ | anyone? |
| 03:52.16 | jnc | my CPU is not the limiting factor, disk IO seems to be the limiter |
| 03:52.16 | CIA-9 | 03justinp 07org.oe.dev * rb387bb17... 10/packages/e17/ (entrance/disable-autodetect.patch entrance_0.9.0.006.bb): entrance: remove useless autodetection script and fix packaging with e.bbclass |
| 03:52.21 | CIA-9 | 03justinp 07org.oe.dev * re879a0da... 10/packages/efl/ (6 files): evas: stage modules to arch-based directories |
| 03:52.43 | jnc | caching uses tons of disk IO w/o psyco |
| 03:52.47 | jnc | i'm not sure about that |
| 03:52.54 | jnc | it appears to be the case though |
| 03:56.34 | johnX | jnc: I copied cache to a tmpfs and got no performance boost on an Athlon 1900+ with 768MB RAM, but that machine is just for building |
| 03:56.46 | johnX | 5400 RPM disk, BTW |
| 03:56.58 | jnc | hmm |
| 03:57.09 | jnc | that's an 1900+ though |
| 03:57.40 | jnc | you'd have to try it on a rediculously fast box to do a fair test |
| 03:58.07 | johnX | never goes above 70% CPU usage |
| 03:58.24 | johnX | er...spiked to 80% for a second |
| 03:58.25 | JustinP | jnc: it's not the "cache" that's slowing things down. The cache speeds it up. It's the *parsing* that slows it down. |
| 03:58.36 | JustinP | jnc: with psyco the cache speeds things up considerably |
| 03:58.41 | jnc | oh |
| 03:58.52 | JustinP | jnc: and the newer versions of bitbake are supposed to be even faster |
| 03:58.56 | JustinP | jnc: although they have other issues |
| 03:58.59 | jnc | the requirement is on psyco? |
| 03:59.04 | JustinP | I believe so |
| 03:59.18 | jnc | bugger ;/ |
| 03:59.28 | JustinP | if your first parse and subsequent parses are the same speed it's because you have *no* cache |
| 03:59.39 | JustinP | I suggest using bitbake -i more often ;-) |
| 04:04.26 | TheMasterMind1 | meh. reiserfs failing already |
| 05:09.15 | *** join/#oe tchnk2|afk (n=hwtechni@tor/session/external/x-11db271ea33f5e7e) |
| 05:22.30 | *** join/#oe rm_you|sleep (n=Adam@resh0922.tigernet.trinity.edu) |
| 05:44.39 | *** join/#oe dijenerate_ (n=dijenera@69.73.206.63) |
| 05:59.08 | *** join/#oe leoncamel (n=leoncame@221.217.113.163) |
| 06:01.39 | CIA-9 | 03justinp 07org.oe.dev * r379d3632... 10/packages/e17/e-wm/fix-configure.patch: e-wm: remove unneeded fixes from patch |
| 06:15.12 | *** join/#oe rm_you|sleep (n=Adam@resh0922.tigernet.trinity.edu) |
| 06:16.04 | JustinP | woohoo! e-image-core builds again |
| 06:22.50 | *** join/#oe mithro (n=tim@ppp246-117.static.internode.on.net) |
| 06:32.46 | mithro | hey mickey|dinner you about? |
| 06:54.53 | RP | morning all |
| 07:07.01 | mithro | hey RP |
| 07:07.13 | mithro | did you see that there is another Summer of Code? |
| 07:07.49 | emte | will be interesting to see what happens regarding it |
| 07:08.01 | RP | hi mithro |
| 07:08.18 | RP | mithro: I did notice it being mentioned, yes |
| 07:08.32 | RP | I offered to mentor last year... |
| 07:13.47 | *** join/#oe TheMasterMind1 (n=aman@residents-liberty-potomac-129-174-185-149.residents.gmu.edu) |
| 07:14.56 | TheMasterMind1 | the kernel module ipks have too much overhead. each control file is 2K because it contains all the patches used in the sources line, and they have the exact same postinst scripts.. couldn't we set it up so they all shared a common post inst atleast |
| 07:16.20 | emte | file it as a bug and offer to fix it :) |
| 07:16.42 | RP | TheMasterMind1: In theory that's a nice idea. In practice, its rather tricky to do without rewriting ipkg |
| 07:17.04 | emte | it shouldnt contain all the patches tho |
| 07:17.50 | TheMasterMind1 | the names of all the patches that is, the entire SRC_URI |
| 07:18.03 | emte | ah |
| 07:18.13 | TheMasterMind1 | i can see why thats a good idea, but i only have a 3.8mb jffs2 root =\ |
| 07:18.52 | RP | TheMasterMind1: Add an option to disable the Sources: line in the packaging |
| 07:19.50 | TheMasterMind1 | yea planning on doing that. trying to think of a decent hack to get the kernel modules sharing scripts |
| 07:20.04 | TheMasterMind1 | i keep thinking symlinks but that just can't be pretty |
| 07:22.01 | TheMasterMind1 | RP: can you confirm the patch at http://sourceware.org/ml/newlib/2004/msg00046.html is incorrect |
| 07:23.39 | RP | TheMasterMind1: I'm not sure. Paul Brook usually knows what he's doing... |
| 07:25.12 | TheMasterMind1 | well its an old patch, but "__VFP_FP__ will be defined, even if soft-float" is certainly not true for me with 3.4.3 |
| 07:26.00 | CIA-9 | 03justinp 07org.oe.dev * rfb37f14b... 10/packages/meta/e-image-core.bb: e-image-core: fix DEPENDS |
| 07:26.58 | RP | TheMasterMind1: That suggests it isn't quite right then... |
| 07:27.48 | TheMasterMind1 | well the ieeefp.h in gnu classpath has the same code causing floats not to work with any jvm using classpath |
| 07:28.19 | TheMasterMind1 | i filed a report on the classpath bugzilla but i'm not really sure where upstream it needs to be reported |
| 07:29.50 | RP | It should be reported to the people providing that header I guess |
| 07:30.02 | TheMasterMind1 | yea, how do i find out who that is |
| 07:30.30 | RP | Where did the header come from? |
| 07:31.00 | TheMasterMind1 | its in the classpath source tree under the fdlibm directory. |
| 07:32.46 | *** join/#oe Wolverine (n=wolverin@222.44.91.39) |
| 07:32.54 | RP | TheMasterMind1: So classpath is one place it needs fixing I guess. If they get it from anyone, hopefully they'll pass the fixes on... |
| 07:33.26 | TheMasterMind1 | alright, sounds good. atleast its reported somewhere, hopefully google with crawl it |
| 07:36.06 | *** part/#oe Wolverine (n=wolverin@222.44.91.39) |
| 07:37.16 | *** join/#oe Wolverine (n=wolverin@222.44.91.39) |
| 07:38.38 | TheMasterMind1 | RP: how does that sound, a flag to go through kernel-module*.postinst and create symlinks to one file, and another flag to perhaps clean out all the sources lines |
| 07:39.44 | RP | TheMasterMind1: What happens when you remove the package they all symlink to? |
| 07:41.20 | TheMasterMind1 | well i was going to take the first one in the list and copy it to kernel-modules-common.postinst and symlink to that |
| 07:42.05 | RP | So how does kernel-modules-common.postinst get removed? |
| 07:42.19 | TheMasterMind1 | it doesn't |
| 07:42.28 | *** join/#oe cromain (n=cromain@AToulouse-157-1-51-183.w86-207.abo.wanadoo.fr) |
| 07:42.32 | RP | You just broke package management then :-/ |
| 07:43.04 | TheMasterMind1 | yea, its a hack and a tradeoff. |
| 07:43.15 | TheMasterMind1 | the sources thing will save me more space so i'll do that first |
| 07:43.37 | RP | I'm not sure we want hacks in OE itself... |
| 07:45.29 | TheMasterMind1 | well the other way would be to have them all depend on an empty package that contained only the scripts, but then you need to have broken symlinks into the ipks which is nastier |
| 07:46.10 | RP | The only correct solution is a more intelligent ipkg :-( |
| 07:46.45 | TheMasterMind1 | ok, fair enough |
| 07:46.50 | TheMasterMind1 | how would ipkg ideally handle it |
| 07:47.21 | RP | All its metadata was in a database and it would recognise the postinsts were identical and only store one copy |
| 07:48.05 | RP | I have given this thought in the past... |
| 07:48.20 | RP | It would also work for your Sources: problem |
| 07:48.42 | TheMasterMind1 | ok so something nicer than the files we have now |
| 07:49.11 | RP | yes |
| 07:49.27 | TheMasterMind1 | sqlite comes to mind |
| 07:49.41 | RP | It might be seen as too much of a change from traditional debian behaviour so you might have to fork ipkg :-/ |
| 07:49.55 | RP | sqlite is what I was thinking of using |
| 07:51.15 | TheMasterMind1 | well thats definitely not something that can be hacked on.. not easily anyway |
| 07:52.01 | TheMasterMind1 | and the idea of forking ipkg makes me shudder |
| 07:52.35 | RP | You can see why it might be needed though? |
| 07:52.51 | TheMasterMind1 | oh yea definitely |
| 07:53.08 | RP | I agree, its not ideal. Its also very heavy changes to ipkg |
| 07:53.37 | TheMasterMind1 | you could do something similar and rudimentary, perhaps compare md5sums to find identical files, but thats not nearly as beneficial as doing it on a field by field basis |
| 07:54.44 | TheMasterMind1 | well ideally i think its something that could be achieved in the ipkg backend without any changes to the ipk format |
| 07:54.54 | TheMasterMind1 | data comes in the same way, its just stored more efficiently |
| 07:55.20 | RP | Yes, the ipk format wouldn't change |
| 07:57.11 | *** join/#oe johnX (n=john@c-24-16-192-158.hsd1.wa.comcast.net) |
| 07:57.41 | TheMasterMind1 | well if neither the users nor the developers/packagers have to change anything they're doing it should be a lot easier to get accepted. reminds me of when ethernet bridges came out, replace your hub, do nothing else and all of a sudden you have dedicated bandwidth link to every computer on the network |
| 07:59.52 | RP | TheMasterMind1: The only issue might be that people are attached to the debian like file structure on the device |
| 08:00.16 | TheMasterMind1 | yes, it certainly has its advantages |
| 08:01.46 | JustinP | It's easy to sh script |
| 08:02.27 | TheMasterMind1 | what is? |
| 08:03.01 | TheMasterMind1 | i need a variable name for toggling the source: line.. IPK_DISABLE_SOURCE? IPK_CONTROL_NO_SOURCE? |
| 08:03.29 | JustinP | the file-based structure is easy to hack on based on its flat file structure |
| 08:03.37 | JustinP | I agree, however, that sqlite would be a better choice |
| 08:03.42 | TheMasterMind1 | yep |
| 08:04.10 | TheMasterMind1 | i'm trying to think if it'd be possible to have a separate utility that did it.. if only you could create a symlink to multiple files that were to be appended |
| 08:04.30 | Cockroach- | morning |
| 08:05.04 | Cockroach- | ~logs |
| 08:05.05 | ibot | apt/ibot/jbot/purl all log to http://ibot.rikers.org/<channelname>/ where channelname is html encoded ie: %23debian | lines that start with a space are not shown | some channels have stats at http://ibot.rikers.org/stats/<channelname>.html.gz, or updated "nightly" |
| 08:07.09 | *** join/#oe Bompo (n=Bompo@V32fd.v.pppool.de) |
| 08:07.40 | pb_ | TheMasterMind1: yeah, sharing the postinsts between kernel packages would be a neat idea. It probably ought to be as easy as putting the postinst in a dedicated package that all the others depend on, and inventing some new control field to set the path of that script. |
| 08:08.20 | *** join/#oe gremlin[it] (n=gremlin@88-149-150-155.f4.ngi.it) |
| 08:08.34 | *** join/#oe gints|wrk (n=gints@195.244.141.102) |
| 08:08.35 | TheMasterMind1 | heck a new control field with a path could just point to update-modules itself since thats all the script does |
| 08:08.53 | pb_ | TheMasterMind1: as for the verbose Source: lines, yeah, they're a bit of a nuisance. Including all the patch URIs has only dubious utility anyway; in the medium term it would be better to move to some kind of source package system for that stuff (even if the "source package" is just a tarball) |
| 08:08.54 | TheMasterMind1 | *** Error: CONTROL/control is missing field Source |
| 08:08.55 | Cockroach- | last xstroke |
| 08:08.59 | Cockroach- | oops :) |
| 08:10.28 | pb_ | TheMasterMind1: oh, heh. if that's really all it does then yeah, that would work. But, equally, if that's all it does then it's only going to occupy a few bytes of storage for each copy of the postinst, so maybe it isn't worth worrying about. |
| 08:12.11 | TheMasterMind1 | yea agreed, its not that big of a space hog. it has a conditional in there currently to see if its running on the OE build host, but still |
| 08:12.20 | TheMasterMind1 | the Source: lines are the ones taking 2K per module |
| 08:12.30 | pb_ | yeah |
| 08:12.46 | TheMasterMind1 | well i'm just going to include blank Source lines for now then |
| 08:12.57 | pb_ | we already strip the Source lines out of the Packages file for familiar for space reasons. |
| 08:13.12 | TheMasterMind1 | ah, its not just me then |
| 08:13.24 | TheMasterMind1 | well i just added a flag not to put them there in the first place |
| 08:13.26 | pb_ | (though we do leave them in the individual .ipks) |
| 08:13.52 | TheMasterMind1 | oh packages file, misread that |
| 08:14.19 | pb_ | I think the best thing might be to patch package_ipk.bbclass to only put the URI of the upstream tarball in Source:, not all the patch stuff. |
| 08:14.43 | *** join/#oe katossi (n=guillerm@dslb-084-062-164-025.pools.arcor-ip.net) |
| 08:14.45 | pb_ | in a sense that's a bit misleading, but all those file:// URIs are next to useless anyway for someone who just has a copy of the .ipk file. |
| 08:14.50 | TheMasterMind1 | yea |
| 08:15.13 | TheMasterMind1 | the name of the .bb file might make sense |
| 08:15.28 | koen | mithro: pong |
| 08:15.38 | gremlin[it] | hi pb_ , koen |
| 08:15.56 | pb_ | longer term, package.bbclass should be putting all the sources in a tarball that gets distributed along with the .ipk, and the Source field in the latter should refer to the name of that tarball |
| 08:15.58 | pb_ | hi gremlin[it] |
| 08:17.19 | pb_ | TheMasterMind1: or, yet another idea would be to invent some flag that says "this package has the same source as <some other package>", so that all the kernel-modules could refer to kernel-image. |
| 08:17.34 | pb_ | and then kernel-image would have a real Source: field with all the URIs in |
| 08:18.04 | TheMasterMind1 | hrm, yea but at that point it almost makes sense to go with RPs idea |
| 08:19.07 | pb_ | changing ipkg? yeah, I guess, but that isn't terribly appealing. |
| 08:20.05 | TheMasterMind1 | well i meant more doing that for all fields, but you're right that would require changing ipkg |
| 08:21.04 | pb_ | mm. there aren't very many other fields that are routinely shared, at least not big ones. |
| 08:21.18 | pb_ | obviously stuff like Architecture: is almost always the same, but that one isn't big enough to worry about |
| 08:21.50 | TheMasterMind1 | well even stuff like 'Maintainer: OpenEmbedded Team <oe@handhelds.org>' can add up |
| 08:22.47 | TheMasterMind1 | but again i agree, sources is the big one and another control field sounds like a good solution for the moment |
| 08:25.26 | mithro | hey koen |
| 08:28.38 | koen | mithro: you pinged me earlier? |
| 08:30.12 | mithro | ahh about the SoC stuff |
| 08:33.04 | mithro | can ibot give time in germany? |
| 08:33.35 | TheMasterMind1 | meh. everytime i go to use ipkg i end up writing a patch for it |
| 08:39.54 | koen | mithro: 10:33 |
| 08:40.15 | koen | 10:40 that is |
| 08:42.43 | *** join/#oe xep (i=misha@dsl027-176-045.sfo1.dsl.speakeasy.net) |
| 08:50.58 | koen | mithro: I think OE can benefit from the GSoC |
| 08:53.51 | *** join/#oe Bernardo (n=Bernardo@sourcemage/Bernardo) |
| 08:54.24 | Bernardo | good morning |
| 08:54.34 | koen | hey Bernardo |
| 08:54.49 | Bernardo | hi koen |
| 08:55.42 | Bernardo | I've been fighting to get my sandisk plus connect to work on my laptop in wifi mode, but no luck yet... |
| 08:57.44 | Bernardo | and the specs for it have disapeared... I was thinking on starting hacking it on the laptop then if I had any luck getting it to work in wifi+ide porting the patch to the z |
| 09:06.32 | TheMasterMind1 | smart little ipkg, detects if i leave Source: out or even if i have it blank! |
| 09:19.39 | *** join/#oe polyonymous_ (n=hacker@pD953944E.dip0.t-ipconnect.de) |
| 09:24.56 | pb_ | heh |
| 09:42.47 | TheMasterMind1 | well that seems to have works, i don't know how much it really helped. guess tomorrow is for unionfs and udev. gotta get rid of sysvinit and hotplug |
| 09:44.05 | pb_ | okay, very good |
| 09:44.46 | TheMasterMind1 | night |
| 09:44.51 | koen | 'night TheMasterMind1 |
| 09:44.56 | pb_ | night tmm1 |
| 09:49.16 | *** join/#oe hue_ (n=hue@218.20.51.109) |
| 09:49.36 | RP | ~oe |
| 09:49.37 | ibot | i heard oe is OpenEmbedded (see http://www.openembedded.org ), or "Opportunistic Encryption" (see http://www.wavesec.org ), or an email client which is not to be spoken of. |
| 10:04.15 | *** join/#oe incinerator (n=incinera@82-41-24-164.cable.ubr04.edin.blueyonder.co.uk) |
| 10:18.11 | *** join/#oe rwhitby (n=rwhitby@nslu2-linux/rwhitby) |
| 10:26.06 | mithro | damn, now I need zecke's help again |
| 10:28.30 | RP | mithro: Anything I can help with? |
| 10:30.17 | mithro | i need to know initalise the C parser |
| 10:30.50 | RP | You need zecke :-(. I never did manage that myself :-/ |
| 10:31.07 | mithro | whats the secondary cache do? |
| 10:31.57 | RP | What I mentioned the other day - create a small subset of cache data instead of caching the whole parsed data |
| 10:32.21 | RP | So it will only speed up reparsing where nothing has changed but that's a good improvement to have |
| 10:34.00 | mithro | RP: have you tried running the code through the python profiler? |
| 10:34.20 | RP | mithro: zecke did and was working from that |
| 10:34.49 | RP | mithro: I know currently bitbake spends 33% of its time doing disk IO writing out the cache on my machine |
| 10:35.24 | mithro | why is the cache so big btw? |
| 10:35.59 | *** join/#oe goxboxlive (n=goxboxli@ti500710a080-11245.bb.online.no) |
| 10:35.59 | RP | mithro: When all the classes combine, we have a large amount of variables |
| 10:38.23 | mithro | still seems a bit excessive |
| 10:38.55 | RP | If you can see any improvements, we'd take them... |
| 10:39.03 | koen | 400MB of cached metadata to fill 8MB of flash |
| 10:39.25 | RP | mithro: Each cache file is ~100kb which isn't so bad... |
| 10:39.56 | mithro | bitbake code makes my head hurt :P |
| 10:41.06 | RP | I didn't know where to start yesterday. I'm slowly getting somewhere now though. I can generate the list of variables I need to use a secondary cache for |
| 10:41.38 | *** join/#oe theturtle (n=theturtl@theturtle.net) |
| 10:46.19 | mithro | dunno how anyone wrote python code like this :P |
| 10:47.08 | RP | mithro: Its a nightmare although my python is limited to start with :-/ |
| 10:50.57 | *** join/#oe hue_ (n=hue@218.20.51.109) |
| 10:56.51 | CoreDump|home | morning |
| 11:00.55 | RP | hi CoreDump|home |
| 11:01.19 | RP | CoreDump|home: I found that dd bug btw - there's a fix on LKML |
| 11:01.27 | CoreDump|home | nice! |
| 11:01.41 | RP | Well, several fixes - I just need to confirm it works |
| 11:02.11 | CoreDump|home | if I can be of help let me know |
| 11:02.53 | RP | CoreDump|home: Will do. Hopefully I'll push a patch into OE soon. I want to get this bitbake work done first :) |
| 11:03.08 | CoreDump|home | no hurry =) |
| 11:07.28 | CoreDump|home | RP: c7x0 was moved to kernel 2.6 right? |
| 11:07.59 | RP | CoreDump|home: Correct - it was the first |
| 11:08.19 | CoreDump|home | excellent =) |
| 11:09.25 | CoreDump|home | ~sheperd |
| 11:09.45 | CoreDump|home | ~shepherd |
| 11:09.46 | ibot | [shepherd] a Sharp Zaurus SL-C750, or a dog. |
| 11:10.00 | CoreDump|home | ~husky |
| 11:10.01 | ibot | somebody said husky was Sharp Zaurus SL-C760 or a dog |
| 11:10.03 | CoreDump|home | ~corgi |
| 11:10.04 | ibot | corgi is, like, sharp sl-c700, or a dog |
| 11:12.25 | RP | It appears I just regressed bitbake's memory usage to the bad old days :-/ |
| 11:12.58 | CoreDump|home | RP: If you made it as fast as it was back then I could live with id =D |
| 11:13.07 | *** join/#oe zecke (n=ich@88.134.3.107) |
| 11:14.09 | RP | CoreDump|home: We had 10% of the .bb files we have now :-/ |
| 11:15.06 | CoreDump|home | we had like 1700 |
| 11:15.30 | CoreDump|home | http://hentges.net/tmp/screenshots/mhcln03/oe.jpg |
| 11:15.35 | CoreDump|home | 2137 =) |
| 11:15.38 | RP | CoreDump|home: And we're slower than we were then? |
| 11:16.08 | CoreDump|home | Yep, at least on my box the initial parsing takes way longer |
| 11:16.12 | CoreDump|home | (now) |
| 11:16.38 | RP | It'd be nice to know why as that's worrying |
| 11:16.40 | RP | hi zecke |
| 11:17.39 | zecke | moin |
| 11:17.47 | CoreDump|home | hey zecke |
| 11:19.38 | zecke | CoreDump|home: it can't take longer, use the kernel you used before |
| 11:20.01 | zecke | CoreDump|home: have you had some special attributes in your fstab? (no atime or such?) |
| 11:20.15 | CoreDump|home | zecke nope |
| 11:20.35 | CoreDump|home | I have sinced moved to a XFS RAID with noatime and friends |
| 11:21.00 | CoreDump|home | and I really do not want to use kernel 2.4.20-bk36 anymore ;) |
| 11:21.49 | zecke | CoreDump|home: I refuse to consider that bitbake got slower ;) |
| 11:22.00 | zecke | CoreDump|home: "Was nicht sein darf, kann nicht sein" |
| 11:22.01 | CoreDump|home | zecke: I know =) |
| 11:22.11 | CoreDump|home | you told me that shortly after the change heh |
| 11:22.39 | zecke | CoreDump|home: turn off the cache please (CACHE="") |
| 11:22.50 | zecke | CoreDump|home: we will see quite some memory consumption then but... |
| 11:23.04 | CoreDump|home | I got 2G in that box |
| 11:23.13 | CoreDump|home | in local.conf or shell env? |
| 11:24.02 | zecke | local.conf |
| 11:24.06 | RP | time bitbake foo |
| 11:24.06 | RP | NOTE: Using cache in '/usr/oe/build2/tmp/cache' |
| 11:24.07 | RP | NOTE: Parsing finished. 3206 cached, 0 parsed, 66 skipped, 0 masked. |
| 11:24.07 | RP | ERROR: Nothing provides dependency foo |
| 11:24.07 | RP | real 0m6.599s |
| 11:24.08 | RP | user 0m5.692s |
| 11:24.09 | RP | sys 0m0.196s |
| 11:24.25 | zecke | RP: ? |
| 11:24.35 | RP | zecke: secondary caching :) |
| 11:24.55 | zecke | CoreDump|home: please run time bitbake -p opie-image with the fast and slower version |
| 11:25.06 | zecke | CoreDump|home: I would like to know where the difference is spent |
| 11:25.15 | CoreDump|home | will do |
| 11:25.20 | zecke | RP: hehe, did you push that change yet? |
| 11:25.31 | RP | zecke: No, it only just started to work :) |
| 11:25.42 | RP | zecke: At the moment it will crash if it builds anything as well ;-) |
| 11:25.46 | zecke | It forgot from which depot it copied bitbake-tests |
| 11:25.51 | RP | zecke: But this is a minor issue ;-) |
| 11:26.03 | zecke | RP: oh well, you should have shipped it more early |
| 11:26.10 | goxboxlive | anyone here who can send me a modified hciattach binary? |
| 11:26.26 | polyonymous_ | modified? |
| 11:26.27 | zecke | RP: This diverts from the breakage I'm creating |
| 11:26.50 | zecke | goxboxlive: e.g. replacing the ELF header with MCOF? Sadly not |
| 11:26.51 | RP | zecke: I know and this worries me :-/ |
| 11:27.01 | polyonymous | ah |
| 11:27.20 | *** join/#oe leoncamel (n=leoncame@219.142.190.64) |
| 11:27.26 | RP | zecke: I had to back out the changes between r419 and r423 to get something I could work on as I can't get r423 to work properly |
| 11:27.43 | zecke | RP: hmm, that is weird |
| 11:28.16 | RP | zecke: It doesn't like the DEPENDS_prepend in package_ipk |
| 11:29.25 | RP | I was seeing -native packages depending on ipkg despite the fact native packages have PACKAGES="" and therefore don't pull in ipkg |
| 11:29.26 | goxboxlive | I want the one who is able to use caption s '-S' The one in the familiar-0.8.4.rc1 doesnt support caption s. |
| 11:29.44 | zecke | RP: okay, that is a hint ;) |
| 11:29.55 | zecke | RP: regardles I'm passing all the tests :} |
| 11:30.11 | RP | zecke: :-/ |
| 11:30.23 | zecke | That shows off the quality of them... |
| 11:30.42 | RP | zecke: It worked fine for a while, then broke. Nothing I could do (wiping tmp/cache etc.) would unbreak it... |
| 11:32.13 | CoreDump|home | real 5m27.019s |
| 11:32.13 | CoreDump|home | user 5m1.963s |
| 11:32.13 | CoreDump|home | sys 0m7.164s |
| 11:32.22 | CoreDump|home | that is with # CACHE |
| 11:33.20 | mithro | hey zecke! |
| 11:33.29 | mithro | how did you sneek in? |
| 11:33.54 | zecke | mithro: from this small terminal over here |
| 11:34.03 | mithro | i need your help again |
| 11:34.18 | mithro | i can't figureout how to setup and call the C side of the parser |
| 11:38.15 | zecke | RP: At least your statement correlates to the revisions you mentioned :) |
| 11:38.40 | RP | zecke: :) |
| 11:38.48 | zecke | mithro: see bitbakescanner.l |
| 11:38.52 | mithro | where? |
| 11:38.55 | zecke | mithro: the 'parse' method |
| 11:39.04 | zecke | mithro: lib/bb/parse/parse_c/bitbakescanner.l |
| 11:39.06 | CoreDump|home | real 6m16.146s |
| 11:39.07 | CoreDump|home | user 5m41.629s |
| 11:39.07 | CoreDump|home | sys 0m10.679s |
| 11:39.10 | CoreDump|home | this is with cache |
| 11:39.24 | mithro | ahh I see it |
| 11:39.45 | zecke | mithro: there are some bits missing though |
| 11:40.08 | zecke | mithro: e.g. YY_INPUT should not be defined, instead the 'FILE*' should be set as input |
| 11:40.19 | mithro | hrm? |
| 11:40.42 | koen | hey zecke |
| 11:40.47 | zecke | mithro: this scanner used to operate on 'mmaped' files, and needed a custom read buffer method |
| 11:41.55 | mithro | so um.... |
| 11:42.05 | mithro | i thought the C side worked? |
| 11:42.11 | zecke | mithro: sort of ;) |
| 11:42.21 | zecke | mithro: the grammar and scanner is correct |
| 11:42.28 | mithro | so what will happen when I call the parse function? |
| 11:44.05 | zecke | mithro: lex_t::input needs a implementation |
| 11:44.21 | zecke | mithro: alternatively we can make the scanner work directly on our FILE* |
| 11:45.12 | mithro | should I be implimenting "void parse (FILE* file, PyObject* data)" instead of you? |
| 11:45.50 | zecke | mithro: no parse is already implemented |
| 11:46.03 | zecke | mithro: it setups the scanner and grammar, and starts parsing |
| 11:46.13 | zecke | mithro: which will call into the e_* methods and it is reentrant |
| 11:47.03 | zecke | RP: could we look into the DEPENDS_prepend issue for a moment? |
| 11:47.57 | mithro | okay then |
| 11:48.04 | mithro | what does reentrant mean? |
| 11:48.56 | RP | zecke: I'll need 5 minutes to get a working bitbake |
| 11:58.23 | mithro | zecke: no ICQ? |
| 12:05.27 | *** join/#oe dan2003 (n=dan2003@cpc1-ware3-0-0-cust291.lutn.cable.ntl.com) |
| 12:09.57 | RP | zecke: ok, I have bitbake producing this error - what debug info can I provide? |
| 12:10.49 | zecke | RP: local conf, bb files etc. for a later test case ;) |
| 12:11.02 | zecke | RP: is it failing with bitbake -b as well? |
| 12:11.02 | CIA-9 | 03coredump 07org.oe.oz354x * ra6d6b0a4... 10/packages/xserver-common/ (3 files in 2 dirs): xserver-common: Remove xmodmap for kernel 2.4 on c7x0 and cxxxx |
| 12:11.10 | RP | zecke: No, -b works |
| 12:11.29 | zecke | RP: okay that is bad then ;) |
| 12:12.01 | *** join/#oe zecke (n=ich@88.134.3.107) |
| 12:12.10 | zecke | ~fishslap zecke |
| 12:12.11 | ibot | ACTION slaps zecke up side the head with a wet fish. |
| 12:12.42 | zecke | CoreDump|home: BTW: Use reiser for better bitbake performance not that crappy XFS ;) |
| 12:13.04 | RP | zecke: The error I see is: http://pastebin.com/661308 |
| 12:13.24 | CoreDump|home | zecke: over my dead body |
| 12:13.53 | zecke | CoreDump|home: then live with the bad performance ;) |
| 12:14.05 | zecke | CoreDump|home: using a fs that can not be shrinked is... |
| 12:14.46 | zecke | RP: do you have an idea what is going wrong? |
| 12:14.51 | CoreDump|home | zecke: I do not need to shrink / rezise my raid heh |
| 12:14.58 | koen | CoreDump|home: you're forgetting 'changes on disk format more that hans reiser changes socks' |
| 12:15.29 | CoreDump|home | koen: =) |
| 12:15.51 | CoreDump|home | I take the slow ext3 over reiser any day hehe |
| 12:15.53 | zecke | RP: wait a second please |
| 12:16.05 | CoreDump|home | But I am pleased so far w/ XFS |
| 12:16.58 | zecke | CoreDump|home: I'm using HFS+ (journaled) and UFS at the moment |
| 12:17.10 | zecke | CoreDump|home: UFS is not journaled but I have background filesystem checks |
| 12:17.20 | RP | CoreDump|home: Until it east your files. But ext3 does that for me too... |
| 12:17.29 | CoreDump|home | zecke: Can't comment on the fancy Mac stuff =) |
| 12:17.32 | RP | s/east/eats/ |
| 12:17.41 | zecke | CoreDump|home: UFS, Unix File System ;) |
| 12:17.44 | CoreDump|home | never had any problems w/ ext3 |
| 12:18.42 | koen | bleh |
| 12:18.45 | zecke | RP: well. update_data is likely to be the problem |
| 12:18.50 | koen | one step forward and one step back |
| 12:18.56 | zecke | RP: it used to fork the following way: |
| 12:19.12 | zecke | RP: for each key -> for each override -> apply_override |
| 12:19.28 | zecke | RP: now we do for each override -> find key -> apply_override |
| 12:19.38 | koen | CoreDump|home: I think I solved some crashes when using the clearlooks theme |
| 12:19.52 | CIA-9 | 03koen 07org.oe.dev * re7b98b54... 10/packages/gtk-engines/gtk-engines_2.7.4.bb: |
| 12:19.52 | CIA-9 | gtk-engines: add 2.7.4 |
| 12:19.52 | CIA-9 | * this fixes a lot of crashes with the clearlooks theme |
| 12:19.52 | CIA-9 | * it now uses cairo do draw lots of stuff, so it might be slower as 2.6.x on FPU less systems |
| 12:19.59 | CoreDump|home | yay! |
| 12:20.18 | zecke | slower yes, but it is written in C so it is faster again :} |
| 12:20.20 | koen | CoreDump|home: but it problably is a bit slower due to cairo |
| 12:20.52 | zecke | C the gurantee for small, maintainable and fast applications |
| 12:20.56 | koen | zecke: it uses git, so it can't be slow! |
| 12:21.02 | CoreDump|home | could you push that to .oz354x as well please? |
| 12:21.25 | koen | CoreDump|home: not without updating to gtk 2.8 |
| 12:21.48 | CoreDump|home | hmm ok, probably not a good idea =) |
| 12:22.30 | RP | zecke: http://pastebin.com/661321 |
| 12:22.40 | zecke | RP: OT: I have found an issue with FOO_${DOO} yesterday... |
| 12:22.48 | RP | zecke: The problem is when bitbake sees DEPENDS, its not = "" |
| 12:23.50 | RP | zecke: I think the evaluation of DEPENDS=${@autotools_dep_prepend(d)}${@["ipkg-utils-native ", ""][(bb.data.getVar('PACKAGES', d, 1) == '')]}${PACKAGE_DEPENDS} ${@base_dep_prepend(d)} is failing somewhere along the line |
| 12:27.25 | zecke | hmm |
| 12:27.49 | RP | zecke: Although it works with bitbake -b |
| 12:28.20 | zecke | RP: it ignore DEPENDS though ;) |
| 12:29.17 | *** join/#oe ahmedchk_ (i=messai@nic-nac-project.de) |
| 12:29.35 | RP | zecke: It might ignore it but it does find the right value... |
| 12:30.02 | *** part/#oe ahmedchk_ (i=messai@nic-nac-project.de) |
| 12:30.04 | RP | unlike when bitbake it calculating the dependencies which it finds ipkg-utils-native in there... |
| 12:31.01 | CoreDump|home | doh, why is "wlan0" back |
| 12:31.22 | mithro | anyone know how to list symbols in a file? |
| 12:31.30 | RP | CoreDump|home: You probably changed from hostap to orinoco and back |
| 12:31.35 | zecke | mithro: nm, objdump? |
| 12:31.39 | RP | mithro: objdump? |
| 12:31.41 | CoreDump|home | just an ipkg upgrade |
| 12:32.02 | RP | CoreDump|home: Perhaps hostap wasn't installed or something? |
| 12:32.10 | RP | I'm going to have to break bbshell's peek and poke commands to get the speed increase... |
| 12:32.26 | koen | RP: I've seen reports that kernel-module-ieee80211 change eth0 to wlan0 |
| 12:32.46 | CoreDump|home | no clue, worked fine with "eth0" when I flashed it. An upgrade brings back wlan0 which doesn't get setup |
| 12:32.50 | RP | koen: Ah, that would explain things... |
| 12:32.52 | zecke | RP: hmm could you send me your local.conf please? |
| 12:34.44 | CoreDump|home | mehh hostap depends on that module |
| 12:35.53 | RP | zecke: Did you get the PM? |
| 12:37.04 | zecke | RP: is it failing without collections as well? |
| 12:39.23 | RP | zecke: checking |
| 12:43.15 | RP | zecke: Same problem |
| 12:43.33 | zecke | RP: good |
| 12:43.51 | RP | The pdaxrom people (person) are (is) beginning to irritate me :-/ |
| 12:43.52 | *** join/#oe dijenerate (n=dijenera@69.73.206.63) |
| 12:44.12 | koen | RP: what have they done now? |
| 12:44.27 | RP | 2.6 sucks, it can't do X. Our users will hate it if it can't do Y |
| 12:44.35 | RP | Just generally annoying me... |
| 12:44.52 | koen | they still haven't figured out alsa? |
| 12:45.07 | RP | koen: They haven't got that far yet ;-) |
| 12:45.25 | CoreDump|home | that ieee thingy breaks WEP |
| 12:45.29 | koen | it's funny how there superior buildsystem can't handle 2.6 |
| 12:45.36 | koen | CoreDump|home: you need some extra modules for that |
| 12:45.46 | CoreDump|home | kernel-module-arc4-2.6? |
| 12:45.47 | RP | koen: The lack of cpufreq, QVGA, video overlay and probably other things I've forgotten are upsetting them |
| 12:46.04 | koen | RP: ah, you mean on cxxxx |
| 12:46.15 | RP | koen: yes |
| 12:46.30 | koen | RP: they don't have to use 2.6 |
| 12:46.39 | RP | koen: Apparently ewi is also "always down" |
| 12:46.45 | koen | heh |
| 12:46.56 | koen | koen@bitbake:~/OE/monotone/org.openembedded.dev/packages/xlibs$ uptime 14:49:51 up 87 days, 3:53, 11 users, load average: 1.15, 0.87, 1.38 |
| 12:47.13 | koen | not for the past 87 days |
| 12:47.30 | zecke | RP: and if you use the shell parse and peek DEPENDS |
| 12:47.33 | zecke | RP: what do you get? |
| 12:47.39 | RP | koen: Addmitedly it did have a blip in network access recently but I'd not call that "always down" |
| 12:47.57 | RP | zecke: I can't try that easily :-/ |
| 12:47.59 | koen | RP: ewi is serving feeds for the uni project as well |
| 12:48.12 | koen | RP: so a lot of people get upset when its down |
| 12:48.26 | RP | koen: I have no problem with it ;-) |
| 12:48.34 | koen | RP: but what do they need from ewi? |
| 12:48.37 | pb_ | hail zecke |
| 12:49.03 | RP | koen: I told them to grab a snapshot of OE to get the bits they want instead of pestering me |
| 12:49.38 | RP | zecke: Can you reproduce this problem I'm seeing? |
| 12:49.47 | CoreDump|home | grrr |
| 12:49.57 | zecke | RP: not yet :} |
| 12:51.19 | koen | RP: add them to your ignore list as move on |
| 12:51.29 | rwhitby | koen: monotone.nslu2-linux.org is not too far behind ewi :-) 12:42:01 up 72 days, 13:35, 1 user, load average: 0.11, 0.21, 0.33 |
| 12:52.27 | polyonymous | Has anybody ever considered flashing bootloader instead of kernel on C3x00? |
| 12:52.27 | koen | rwhitby: nice |
| 12:52.28 | rwhitby | koen: (it's72 days since that box was installed at OSUOSL :-) |
| 12:54.53 | RP | koen: If I totally ignore them, OZ/OE will no doubt get slated for lack of cooperation |
| 12:55.32 | koen | RP: if it keeps you saner, so be it |
| 12:55.51 | koen | que? |
| 12:55.52 | zecke | RP: I need to pull first... |
| 12:56.00 | koen | why does e0image wants to build gcc4? |
| 12:57.07 | RP | koen: I also have this totally mad idea they might generate some useful 2.6 patches. I think I'm probably dreaming though |
| 12:58.01 | RP | zecke: r423 also ouputs a number of parsing errors you should probably look into :-/ |
| 12:58.02 | koen | RP: I haven't seen any pdaX patch that wasn't horribly armv5te/zaurus specific |
| 12:58.32 | RP | koen: I can imagine :-/ |
| 12:58.32 | CoreDump|home | the arc4 modules works, but it is not a dependency and is not automatically loaded |
| 12:59.47 | RP | zecke: I'm going to have to go back to r419 to do any further work on the cache I was working on... |
| 12:59.57 | koen | CoreDump|home: hrw had a solution for that |
| 13:00.03 | zecke | RP: sure |
| 13:00.09 | koen | CoreDump|home: he proposed adding the depends by hand to kernel.bbclass |
| 13:00.36 | CoreDump|home | sounds "interesting" ;) |
| 13:07.43 | *** join/#oe Timelord (n=TL@4.78.4.43) |
| 13:10.19 | zecke | RP: you are using a pre alpha distribution ;) |
| 13:13.31 | zecke | RP: which parse errors are you talking about? |
| 13:13.40 | zecke | RP: the one I mailed yesterday? |
| 13:16.02 | zecke | okay |
| 13:16.27 | zecke | I'm studying now |
| 13:30.21 | Ecco | Hello guys |
| 13:31.02 | *** join/#oe benlau (n=benlau@221.125.13.158) |
| 13:53.27 | mithro | any C guys about? |
| 13:54.21 | RP | mithro: I'd ask the question... |
| 13:54.58 | mithro | I have a .o with a function and a .o which needs the function but they won't link together |
| 13:55.25 | RP | What does the linker say? |
| 13:55.50 | mithro | nothing |
| 13:55.57 | mithro | as I'm compiling to a shared library |
| 13:57.28 | RP | :-/. Does the function show up twice in the shared library? |
| 13:57.50 | RP | If so, its not linking properly or it thinks tkey don't match for some reason |
| 13:57.53 | mithro | how do I test that? |
| 13:58.07 | RP | objdump or nm should show the symbols |
| 14:00.10 | mithro | 00005e89 t e_postcat |
| 14:00.10 | mithro | <PROTECTED> |
| 14:01.12 | RP | What commandline are you using to link the files? |
| 14:01.31 | mithro | g++ -shared -fPIC bitbakeparser.o bitbakec.o -o bitbakec.so |
| 14:02.07 | RP | Its not a C/C++ difference is it? |
| 14:02.21 | mithro | could be |
| 14:02.34 | RP | They have different calling conventions |
| 14:02.57 | RP | You could try forcing the function to be a C function if its in C++ code |
| 14:03.00 | mithro | i have done 'extern "C" {' |
| 14:03.21 | mithro | around the apprioprate functions |
| 14:05.40 | zecke | and the callers knows this function as 'c' as well? |
| 14:05.48 | zecke | (look so though) |
| 14:05.52 | mithro | yes |
| 14:06.11 | zecke | mithro: what happens if you try to link bitbakec.o first? |
| 14:06.16 | mithro | same |
| 14:10.42 | mithro | is there way to check the calling thing? |
| 14:11.27 | koen | | |
| 14:13.00 | mithro | do these differ? |
| 14:13.08 | mithro | static void e_postcat(lex_t (*__pyx_v_c),char (*__pyx_v_key),char (*__pyx_v_what)) { |
| 14:13.19 | mithro | extern void e_postcat(lex_t*, const char*, const char*); |
| 14:13.25 | mithro | is it the const? |
| 14:13.52 | RP | mithro: static? |
| 14:14.10 | RP | mithro: If its declared static, nothing will see it |
| 14:14.18 | mithro | o... |
| 14:14.23 | mithro | why? |
| 14:14.36 | RP | static means its not referred to outside that file |
| 14:17.36 | mithro | oo... thats almost fixed it |
| 14:20.31 | mithro | okay, why don't these match then :P |
| 14:20.33 | mithro | void parse (FILE* file, PyObject* data) |
| 14:20.33 | mithro | void (parse(FILE (*),PyObject *)); /*proto*/ |
| 14:22.22 | RP | I'm not sure about the void() - what happens if you make them match a little more closely? |
| 14:22.40 | RP | ie void parse(FILE (*),PyObject *); |
| 14:24.23 | mithro | ahh thats fixed now |
| 14:26.56 | zecke | http://www.mi.fu-berlin.de/kvv/?veranstaltung=1133 <- I feel wasted at Uni... |
| 14:30.33 | mithro | lex_t::input(char*, int*, int) |
| 14:30.42 | mithro | was that what needed to be implimented? |
| 14:32.25 | zecke | mithro: it could be completely dropped if we make the scanner/lexer use our FILE* as YY_INPUT |
| 14:32.52 | mithro | mmap is most probably better? |
| 14:33.10 | zecke | mithro: my idea was to open the file in python |
| 14:33.22 | mithro | why? |
| 14:33.56 | zecke | mithro: I wanted to avoid string conversion issues, raising exceptions from within c... |
| 14:34.06 | mithro | string conversion issues? |
| 14:34.34 | zecke | mithro: getting the char* from the Py_Object* ;) |
| 14:34.44 | mithro | zecke: no problem there :P |
| 14:34.54 | zecke | mithro: also - I don't know if it applies - encoding comes to mind as well |
| 14:35.02 | zecke | forget that... |
| 14:35.11 | mithro | don't worry about string conversion issues atm |
| 14:35.18 | mithro | so do you actually have an implimentation? |
| 14:35.28 | zecke | mithro: marc singer had one |
| 14:35.51 | zecke | mithro: ftp.buici.com |
| 14:36.14 | zecke | pub/oe/bbp-1.0.3.tar.gz |
| 14:36.43 | RP | mithro: We've never had the C<->Python data interchange - there was a implementation in C and obviously the python verison... |
| 14:37.00 | mithro | RP: yeah i know i'm doing the C<->python data interchange :P |
| 14:37.24 | RP | mithro: :) |
| 14:37.39 | *** join/#oe Wolverine (n=wolverin@222.44.91.39) |
| 14:41.52 | mithro | zecke: so i just need to copy across mapped file? |
| 14:42.05 | zecke | yes |
| 14:44.41 | mithro | then how do i fix up input? |
| 14:45.24 | zecke | lex_t has a file* make that a filedescriptor |
| 14:45.32 | zecke | and copy the old code into input ;) |
| 14:46.11 | chouimat | morning |
| 14:48.44 | koen | hey chouimat |
| 14:48.58 | mithro | ahh fsck |
| 14:49.07 | mithro | now I have to call C++ code from C |
| 14:49.29 | zecke | mithro: wrap it ;) |
| 14:55.40 | *** join/#oe pb___ (n=pb@2002:5165:89b3:2:20e:9bff:fe56:eb5) |
| 15:05.05 | CIA-9 | 03koen 07org.oe.dev * r3276dff2... 10/packages/freeciv/freeciv_2.0.8.bb: freeciv: add freeciv 2.0.8 |
| 15:13.26 | mithro | actually |
| 15:13.29 | mithro | zecke: you alive? |
| 15:18.59 | mithro | hrm |
| 15:19.19 | zecke | kind of |
| 15:21.44 | mithro | do you know what a result from yylex of 1001 means? |
| 15:23.52 | mithro | it appears to be T_EOF |
| 15:28.36 | mithro | only none of the E functions are getting called |
| 15:30.36 | zecke | not out of my head |
| 15:31.08 | zecke | <<EOF>> { return T_EOF; } |
| 15:31.26 | zecke | this means it scanned to the EOF |
| 15:31.55 | mithro | how can i find out how it got to EOF without doing anything |
| 15:31.56 | zecke | <PROTECTED> |
| 15:31.56 | zecke | <PROTECTED> |
| 15:32.29 | zecke | using bbparseTrace |
| 15:33.00 | zecke | give it a FILE* |
| 15:39.37 | mithro | i have |
| 15:40.22 | *** join/#oe katossi (n=guillerm@p54AE5AF8.dip.t-dialin.net) |
| 15:41.33 | zecke | mithro: for the tracing |
| 15:41.59 | mithro | ahh |
| 15:44.14 | mithro | i've found the problem |
| 15:44.27 | mithro | e_parse_error |
| 15:44.27 | mithro | Exception exceptions.NameError: 'CParseError' in 'bitbakec.e_parse_error' ignored |
| 15:46.03 | mithro | know any way to get the parser error from yylex? |
| 15:46.49 | zecke | mithro: see #define ERROR(e) in bitbakescanner.l |
| 15:50.35 | RP | zecke: Guess what's slowing down my cache the most - SkipPackage :) |
| 15:51.07 | zecke | good |
| 15:51.29 | RP | good? |
| 15:53.59 | zecke | RP: well, that is the bottleneck on cached loading now? |
| 15:54.23 | RP | zecke: Yes - as it reparses the skipped files each time :-/ |
| 15:54.49 | mithro | do you have a very simple bitbake file with no inherits/etc |
| 15:55.11 | zecke | every file inherits base.bbclass |
| 15:55.45 | zecke | mithro: try a sample like bitbake.conf (and remove include... and name it .bb) |
| 15:55.57 | mithro | okay |
| 15:56.01 | *** join/#oe zh (n=cZCBH8A6@58.169.63.185) |
| 15:56.07 | mithro | is |
| 15:56.09 | RP | or a base.bbclass with lumps chopped out |
| 15:56.17 | mithro | "a := a" a valid bitbake file? |
| 15:56.47 | RP | That's self referencing which I'm not sure we allow |
| 15:57.38 | RP | actually, its not as I'm thinking of a := ${a} :) |
| 15:58.37 | koen | RP: r412 also suffers from the cached-failure problem |
| 15:59.23 | RP | koen: ok, the issues I see for 420 onwards are a different problem then :-/ |
| 15:59.59 | koen | in this case it went straight to do_rootfs, which obviously failed with missing ~30 packages |
| 16:00.48 | mithro | e_parse_error line: 2 parse: 1 |
| 16:01.50 | RP | koen: Its interesting my testing didn't show that up :-/ |
| 16:02.41 | mithro | that seems to be errorUnexpectedInput |
| 16:03.55 | mithro | so what is with "\na := a\n" |
| 16:06.31 | zh | anyone know if there has been any work done on the wgt634u router? |
| 16:10.08 | zecke | not here AFAIK |
| 16:20.06 | RP | SkipPackage is a can of worms. I'd still like it to return the data dict even when it raises an exception :-/ |
| 16:23.05 | RP | Although maybe I'm speaking too soon - I perhaps just need to rework this... |
| 16:25.23 | *** join/#oe joshua_ (i=joshua@cl-5.chi-01.us.sixxs.net) |
| 16:29.24 | mithro | SkipPackage? |
| 16:32.50 | TheMasterMind1 | morning |
| 16:34.06 | *** join/#oe wrobbie (n=rob@cm7.sigma181.maxonline.com.sg) |
| 16:34.17 | pb_ | morning tmm1 |
| 16:41.55 | pb_ | grr, I wonder why I'm getting this broken 2.6 kernel in my gpe-image build |
| 16:50.12 | mithro | zecke: so any idea why the parser is dieing on my test file? |
| 16:51.07 | koen | indigestion? |
| 16:51.41 | mithro | the C one seems to like it okay |
| 16:53.09 | RP | Reparsing with a clean cache down to 3.3s :) |
| 16:53.25 | koen | RP: that's only 60 times faster |
| 16:53.30 | *** join/#oe Timelord (n=TL@4.78.4.43) |
| 16:53.37 | koen | go for 100 times faster ;) |
| 16:54.28 | RP | koen: It probably is 100 times faster. I'd be curious to see what ewi makes of it :) |
| 16:54.55 | RP | Initial parsing seems slower now though so I need to work out why... |
| 17:00.14 | TheMasterMind1 | 3.3 seconds?! is that allowed? |
| 17:01.01 | mithro | RP: how does this effect the overall speed? |
| 17:01.42 | RP | mithro: In theory, it shouldn't change much at all. In practice, it might be slowing down the inital parse |
| 17:02.07 | RP | mithro: I'll finish off the code and run some proper before/after tests... |
| 17:02.08 | mithro | if it wouldn't change much, why are you doing it? |
| 17:02.24 | RP | mithro: Ah, define what you mean by overall speed |
| 17:02.40 | mithro | speed between bitbake xxx and it starting to bake it |
| 17:03.05 | RP | mithro: That's about 60+ times faster if nothing changed |
| 17:03.15 | RP | (i.e the cache is valid) |
| 17:03.16 | *** join/#oe andersee (n=andersee@codepoet.org) |
| 17:03.20 | mithro | but on the first run no change? |
| 17:03.35 | RP | mithro: no, I'm not working on that |
| 17:04.14 | RP | mithro: This should only reparse the files it needs to so if you change a single .bb and rerun, it will still have the speed gain. You only lose if you edit local.conf or similar |
| 17:05.16 | RP | I just touched the linux-openzaurus.inc file and I lost a whole extra 0.4 seconds in reparsing time :) |
| 17:05.26 | zecke | RP: hehe, I hate that game |
| 17:05.43 | mithro | i'm suck |
| 17:05.47 | mithro | s/suck/stuck |
| 17:05.52 | zecke | RP: HEAD started to build oz354fam083 without a issue |
| 17:06.15 | mithro | i believe the problem is in the parser code |
| 17:06.41 | RP | zecke: I'm using .dev |
| 17:07.23 | zecke | RP: I just wanted to test, as people report otherwise |
| 17:07.55 | RP | zecke: For reference, I use oz354x with revision 419 ok |
| 17:08.24 | zecke | okay... |
| 17:08.26 | RP | It might throw odd parsing errors, I can't remember. That might be r423 |
| 17:08.44 | zecke | RP: I throw one kind of error now |
| 17:08.54 | zecke | RP: when two different files specify a method with the same name... |
| 17:09.56 | mithro | Exception exceptions.AttributeError: "'list' object has no attribute 'setVar'" in 'bitbakec.e_immediate' ignored |
| 17:09.59 | mithro | :P |
| 17:10.40 | RP | zecke: This is with head? Have you committed anything recently? |
| 17:12.10 | *** join/#oe gremlin[it] (n=gremlin@88-149-150-155.f4.ngi.it) |
| 17:14.29 | RP | In case anyone fancies experimenting, this patch adds what I've done so far and reverts the changes between r419 and r423: http://www.rpsys.net/openzaurus/temp/bitbake_newcache-r0.patch |
| 17:14.42 | RP | Yes, I know writing to /tmp is bad and I will fix that ;-) |
| 17:14.57 | RP | I'm going to do something else for a bit... |
| 17:17.02 | zecke | mithro: you pass the wrong Pyobject? |
| 17:17.24 | mithro | zecke: yeah delebrately |
| 17:17.43 | Ecco | Hi again guys |
| 17:17.43 | zecke | *depressed* |
| 17:17.51 | koen | hey Ecco |
| 17:17.55 | Ecco | ;-) |
| 17:18.09 | koen | zecke: want some vla? |
| 17:18.30 | zecke | koen: want a Diploma... but not the ones from the SPAM mails |
| 17:18.47 | zecke | I have 11 exams to take... I'm collecting them... |
| 17:18.51 | koen | ouch |
| 17:19.19 | CIA-9 | 03koen 07org.oe.dev * rfbe3dd34... 10/ (3 files in 3 dirs): |
| 17:19.19 | CIA-9 | efika.conf, linux-efika: add files to get rudimentary support for the efika machine into OE. |
| 17:19.19 | CIA-9 | * see http://www.pegasosppc.com/efika.php for more details |
| 17:19.30 | zecke | koen: non is actually challenging... I take the written ones, 'oral' |
| 17:19.39 | zecke | koen: but I have to make the dates myself |
| 17:19.40 | Ecco | I was wondering something about xtscal : how does it work (from the user point of view) ? |
| 17:19.53 | zecke | Ecco: you click at five positions |
| 17:20.03 | zecke | Ecco: using something like a pseudo pencil |
| 17:20.19 | Ecco | ok |
| 17:20.30 | Ecco | because I'm having some troubles with my current distro |
| 17:20.53 | Ecco | may i do something like "Xfbdev & export DISPLAY=:0 ; xtscal" |
| 17:21.00 | Ecco | ? |
| 17:21.05 | Ecco | because that doesn't display anything |
| 17:21.17 | Ecco | (apart from the base Xfbdev of course) |
| 17:21.17 | zecke | Ecco: should work |
| 17:21.21 | Ecco | ok |
| 17:21.24 | koen | Xfbdev -ac & |
| 17:21.26 | zecke | Ecco: you can also delete the calibration file |
| 17:21.29 | Ecco | where am I supposed to press the screen ? |
| 17:22.10 | Ecco | koen, : what does ac do ? It says "disable access restriction", but what does that mean ? |
| 17:22.36 | koen | it means you can connect from outside an xauth session |
| 17:22.49 | Ecco | ha. Which means ? |
| 17:22.56 | Ecco | (sorry, not really an X guru) |
| 17:23.39 | *** join/#oe Harvy (n=norm@80-193-172-141.stb.ubr05.pres.blueyonder.co.uk) |
| 17:24.23 | koen | it means that if you have trouble connecting to the X server you might have better luck with the access controls turned off |
| 17:24.57 | Ecco | oh, ok, that's a neat explaination :-) |
| 17:26.39 | Ecco | ahem |
| 17:27.02 | Ecco | well, indeed Xfbdev -ac & export DISPLAY=:0 ; xtscal does not work |
| 17:27.24 | Ecco | it does nothing more than raw "Xfbdev" |
| 17:27.41 | koen | any errors on the console? |
| 17:28.01 | Ecco | nope :( |
| 17:28.07 | Ecco | and logread doesn't give anything either |
| 17:28.27 | Ecco | ah |
| 17:28.34 | Ecco | yeah, it says "Cannot open XFT font" |
| 17:28.39 | Ecco | May it be that ? |
| 17:28.55 | zecke | Ecco: that is totally Off topic here |
| 17:29.04 | Ecco | zecke, yeah, I know. Sorry :-$ |
| 17:29.16 | zecke | Ecco: try to find another channel |
| 17:29.22 | Ecco | ok |
| 17:29.24 | zecke | e.g. #gpe or #freedesktop.org |
| 17:29.30 | Ecco | thx :-) |
| 17:29.43 | zecke | or even #openzaurus-users (or whatever it is named) |
| 17:35.08 | *** join/#oe mreimer_ (n=mreimer_@wl-wa.vpop.net) |
| 17:35.37 | mreimer_ | has anyone seen this error trying to build tcl: checking system version (for dynamic loading)... /opt/oe/build/tmp/work/arm-linux/tcl-8.4.11-r2/tcl8.4.11/unix/configure: line 7624: syntax error near unexpected token `)' |
| 17:36.14 | zecke | mreimer_: not me, but I can't remember to have build tcl |
| 17:36.33 | mreimer_ | python is trying to build it for some reason |
| 17:37.50 | koen | mreimer_: you can safely remove tcl (and tk) from pythons depends |
| 17:38.33 | mreimer_ | thanks koen |
| 17:39.26 | mreimer_ | koen, finally got abiword-plugins built. thanks again. I hope to try out the OOo plugin soon |
| 17:39.54 | zecke | mreimer_: how does the line look like? |
| 17:39.54 | zecke | koen: why? |
| 17:40.38 | koen | zecke: it's optional for python and doesn't build in some configs |
| 17:40.55 | koen | I couldn't find a problem in the configure itself |
| 17:41.37 | mreimer_ | zecke: OSF*) |
| 17:41.51 | mreimer_ | I looked in the surrounding context, but didn't see any obvious syntax errors. |
| 17:42.11 | mreimer_ | I'll go blind if I spend too much time trying to debug a configure script |
| 17:42.22 | mreimer_ | maybe it's a shell problem |
| 17:43.39 | koen | or some badly written case statement |
| 17:43.53 | mreimer_ | looks fine to me |
| 17:43.56 | mreimer_ | thanks for the help guys. gotta run |
| 17:44.00 | *** part/#oe mreimer_ (n=mreimer_@wl-wa.vpop.net) |
| 17:50.12 | *** join/#oe pH5 (n=ph5@p5485EA07.dip.t-dialin.net) |
| 17:58.07 | koen | hey pH5 |
| 17:58.37 | mithro | yay its working! |
| 18:00.14 | koen | mithro: the c/c++ based parser? |
| 18:01.01 | mithro | yeah |
| 18:02.16 | koen | is it fast? |
| 18:02.31 | pH5 | hey koen, good evening everyone |
| 18:04.41 | mithro | dunno |
| 18:05.14 | mithro | in theory it should be |
| 18:05.17 | koen | pH5: do you think you can find some time to port the linux-oz eabi selectio ot hh-pxa? |
| 18:05.24 | mithro | but a lot of the speed is lost in other places |
| 18:11.08 | koen | pH5: I pushed a new gtk-engines which should fix the abiword crash with clearlooks |
| 18:12.04 | mithro | anyone know how to use svk? |
| 18:12.20 | koen | mithro: there's a short howto in the oe wiki |
| 18:12.45 | koen | mithro: http://oe.handhelds.org/cgi-bin/moin.cgi/SvnScmTrial |
| 18:17.09 | *** join/#oe darkschneider (n=gab@213.140.6.96) |
| 18:18.53 | mithro | SVK not svn? |
| 18:19.07 | polyonymous | mithro, read the whole page? |
| 18:19.12 | mithro | yeah |
| 18:19.15 | mithro | i just realised that |
| 18:19.35 | polyonymous | There's a bunch of svk commands |
| 18:19.41 | polyonymous | (not that I read them:)) |
| 18:26.32 | Bernardo | re |
| 18:27.35 | koen | Bernardo: wb |
| 18:28.41 | pH5 | koen: yay, freeciv :) |
| 18:28.50 | koen | :) |
| 18:28.56 | CIA-9 | 03mwester 07org.oe.dev * ref08aba7... 10/ (12 files in 6 dirs): Unslung: unslung-rootfs, unslung-kernel, unslung-image - rearranged NLS support, removed Linksys upgrade page |
| 18:29.17 | *** join/#oe goxboxlive (n=goxboxli@ti500710a080-11245.bb.online.no) |
| 18:29.43 | pH5 | koen: I'm dense. where do I find the linux-oz eabi selection? |
| 18:30.12 | koen | pH5: packages/linux/linux-openzaurus.inc |
| 18:30.28 | pH5 | koen: heh, .inc. thanks |
| 18:30.46 | TheMasterMind1 | phew |
| 18:30.53 | TheMasterMind1 | has anyone played with mDNS and zeroconf? |
| 18:31.37 | koen | I toyed briefly with avahi |
| 18:31.52 | koen | but pH5 is the avahi maestro in here |
| 18:33.37 | TheMasterMind1 | just reading up on it, pretty cool stuff. especially for usb gadget devices. i found an ARP broadcast kernel patch, a patch for udhcpc that reverts to zeroconf is no dhcp server is found, and a bunch of tiny userspace daemons |
| 18:36.40 | *** join/#oe Harvy (n=norm@80-193-172-141.stb.ubr05.pres.blueyonder.co.uk) |
| 18:36.50 | koen | dhcp is so ipv4 |
| 18:37.41 | jnc | heh |
| 18:37.57 | jnc | PXEboot isn't yet ipv6 though |
| 18:38.03 | jnc | is it? |
| 18:41.16 | koen | no idea |
| 18:41.22 | koen | I use nfs or tftp |
| 18:41.42 | koen | ~stab redboot |
| 18:41.43 | ibot | ACTION runs at redboot with an origami Swiss Army knife, and inflicts a nasty paper cut. |
| 18:42.31 | *** join/#oe Harvy (n=norm@80-193-172-141.stb.ubr05.pres.blueyonder.co.uk) |
| 18:45.49 | koen | pH5: great news about hx4700 wlan, isn't it? |
| 18:50.40 | pH5 | koen: yeah, especially as I don't even have a wlan cf card. |
| 18:54.52 | koen | is your microdrive still broken? |
| 18:58.00 | zecke | koen: isn't this hx device discontinued? |
| 18:58.22 | koen | zecke: iirc not, but I was talking about the MD |
| 19:01.22 | pH5 | koen: I sent it in, I hope the replacement will arrive next week. |
| 19:01.23 | pH5 | koen: http://en.pastebin.ca/49436 |
| 19:02.49 | *** join/#oe alizardo (n=lizardo@200-230-128-159-mns.cpe.vivax.com.br) |
| 19:02.57 | koen | pH5: looks ok to me |
| 19:05.16 | pH5 | hey zecke, RP |
| 19:05.33 | koen | RP: wb |
| 19:06.50 | *** join/#oe alizardo (n=lizardo@200-230-128-159-mns.cpe.vivax.com.br) |
| 19:07.37 | *** join/#oe evildevil (n=evildevi@p54A6ED26.dip.t-dialin.net) |
| 19:10.14 | koen | ooooooooh |
| 19:10.15 | koen | http://linuxdevices.com/news/NS6404482880.html |
| 19:10.22 | koen | 5x gbit |
| 19:14.33 | pH5 | hmh, nice. |
| 19:16.38 | evildevil | 6x gbit |
| 19:17.19 | koen | even better! |
| 19:17.53 | TheMasterMind1 | grr usb gadget ether |
| 19:18.08 | evildevil | hmmm... might turn out to be 4x gbit only (if the gbit port isn't somehow connected to the gigabit switch) |
| 19:18.09 | koen | ah, I see |
| 19:18.23 | koen | 6x phy + 5x switch + 1 "simpleport" |
| 19:18.55 | koen | it does seem to feature 6x rj45 |
| 19:19.25 | evildevil | koen, yep, 3x2 |
| 19:20.00 | koen | if you look at the large picture you can see 6x YCLPG243002 |
| 19:20.20 | koen | and one big and one small vitesse chip |
| 19:20.22 | evildevil | yup |
| 19:20.51 | koen | "along with a standards-based Linux software stack " |
| 19:21.59 | evildevil | 4x sata, 1x pata, 4x usb, 1x pci, 1x (168pin) sdram.. nice |
| 19:23.42 | koen | apple switching to intel really got freescale into action it seems |
| 19:25.19 | koen | if you want to have free powerpc hardware: http://projects.ppczone.org/projects.php |
| 19:25.55 | koen | evildevil: http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=MPC8349E&nodeId=018rH3bTdG8657 |
| 19:26.06 | koen | evildevil: it only has 2 gbit port on-chip |
| 19:26.17 | koen | ports* |
| 19:27.13 | evildevil | koen, do you know how much this board is going to cost? |
| 19:27.19 | koen | I have no idea |
| 19:27.29 | koen | I can't seem to find it on the freescale site |
| 19:27.40 | koen | but I suspect $300 - $400 |
| 19:27.53 | *** join/#oe reenoo (n=r@p5489E0FD.dip.t-dialin.net) |
| 19:31.25 | evildevil | yeah, this seems to be a reasonable price. |
| 19:32.49 | evildevil | this thing could replace my switch, my nslu2, my external usb-hdd (including 3 power supplies) |
| 19:33.20 | koen | that's what I was thinking as well |
| 19:33.27 | *** part/#oe treke|home (n=ggilbert@70-38-100-138.losaca.adelphia.net) |
| 19:35.14 | evildevil | it seems to be powered by a standard atx power supply (there must be some power connectors for the internal hdd's somewhere..) |
| 19:50.01 | koen | didn't sata have some funky powerconnectors? |
| 20:02.16 | RP | Current sata have both and old style and new style connector |
| 20:02.29 | RP | zecke: Are you busy? |
| 20:04.16 | zecke | RP: hehe |
| 20:04.29 | zecke | RP: I played with addpart and my backup disk is busted :} |
| 20:04.48 | RP | zecke: Oops :-/ |
| 20:05.03 | RP | zecke: I'm pondering what to do with the original bitbake cache |
| 20:05.11 | zecke | RP: I gave a wrong length on addpart and created a fs :} |
| 20:05.31 | zecke | RP: throw it away ;) |
| 20:05.43 | RP | zecke: I guess you'll not make that mistake again ;-) |
| 20:05.58 | zecke | RP: we could replace it with something a Cache with ~30 slots |
| 20:06.12 | RP | zecke: I'm just not sure how much of the data store I have to remove/fix... |
| 20:06.12 | zecke | RP: did you make that mistake as well (once) |
| 20:06.27 | RP | zecke: I've made similar mistakes ;-) |
| 20:06.53 | zecke | RP: I'm currently copying the other parts and playing somemore with delpart and addpart ;) |
| 20:07.13 | RP | zecke: You evidently like taking risks :) |
| 20:07.15 | zecke | RP: ah and GNU parted doesn't want to change my part table |
| 20:07.30 | RP | Use fdisk ;-) |
| 20:07.54 | zecke | RP: how can I change existing partitions? I would need to del and create one |
| 20:07.59 | zecke | okay back to the cache |
| 20:08.09 | zecke | RP: what is your plan? |
| 20:08.10 | RP | zecke: Ah, fdisk doesn't do that :) |
| 20:08.23 | *** join/#oe gerwinin (n=gerwinin@ip5457b30e.direct-adsl.nl) |
| 20:08.31 | RP | zecke: My current code basically removes the need for the current form of caching |
| 20:08.47 | RP | The current cache causes us 400MB of IO for no gain I can see now... |
| 20:08.58 | RP | I've proven my replacement can reparse in seconds |
| 20:09.07 | zecke | RP: do you cache enough data to do findBestProvider? |
| 20:09.17 | RP | zecke: Easily |
| 20:09.42 | RP | zecke: Its also dynamic - if findBestProvider uses a new variable, the cache adapts :) |
| 20:09.46 | koen|tv | hey gerwinin |
| 20:10.00 | RP | zecke: Did you look at the patch? |
| 20:10.12 | zecke | RP: have you posted that somewhere? |
| 20:10.31 | RP | zecke http://www.rpsys.net/openzaurus/temp/bitbake_newcache-r0.patch |
| 20:10.36 | RP | zecke: I mentioned it earlier |
| 20:11.15 | zecke | RP: oh |
| 20:11.15 | RP | (Ignore the bits that revert r423 to r419 - they're two isolated files atm |
| 20:11.20 | zecke | - if not var in self.dict: |
| 20:11.21 | zecke | - self._makeShadowCopy(var) |
| 20:11.26 | zecke | that was new as well |
| 20:11.49 | RP | zecke: This is a working copy diff that also reverts r423 to r419 |
| 20:12.15 | RP | I don't actually need to touch data.py, data_smart.py (yet) |
| 20:12.35 | RP | Ignore changes to those two files |
| 20:12.44 | zecke | RP: feel free to commit fetch/__init__.py |
| 20:12.55 | RP | zecke: I still need to commit it all |
| 20:13.17 | evildevil | koen|tv, the only sata disk i own does have a special sata power connector, but it came with an adapter |
| 20:13.27 | RP | zecke: If I remove the orginal cache, it gets much simpler though so no point in commenting until we decide which way to go |
| 20:13.34 | zecke | RP: rppickle, worse than the BSD advertising clause |
| 20:13.44 | RP | zecke: :) |
| 20:13.56 | RP | zecke: That will be fixed to use the cache directory ;-) |
| 20:14.32 | mithro | he he |
| 20:14.34 | mithro | Obvious Americans twice as likely to view Islam favorably than Scientology. Tom Cruise envious of Bin Laden's recruiting ability |
| 20:15.53 | zecke | RP: how do we stop the cache growing to hunderds of MB? |
| 20:16.13 | RP | zecke: By being careful about the number of variables you access via bb_cache |
| 20:17.23 | zecke | RP: let us play bitbake now |
| 20:17.28 | zecke | RP: bitbake opie-image |
| 20:18.00 | zecke | RP: we build the dependencies, will we reread the bbfile for quilt-native more than once? |
| 20:18.43 | zecke | RP: we will have all information cached to not load the file a second time and find out that we have it already build? |
| 20:18.46 | RP | When you build the dependencies, no, just once. It will be read once more when quilt-native builds |
| 20:19.11 | RP | But I'm arguing its faster to reparse the single .bb files as we build them |
| 20:19.26 | zecke | RP: I think we can remove the current caching |
| 20:19.30 | RP | (than spend 400MB of disk IO caching them all just in case) |
| 20:19.48 | RP | zecke: Can you see how this is working? |
| 20:21.37 | zecke | RP: I like the approach |
| 20:21.50 | zecke | RP: I still have to find out about getVar ;) |
| 20:22.37 | RP | zecke: getVar watches which variables are accessed through bb_cache. It only saves the ones that are accessed |
| 20:22.59 | RP | This means our total cache file is 8MB large |
| 20:23.21 | koen|tv | that doesn't fit on my 5000d, so it sucks |
| 20:23.25 | koen|tv | *cough* |
| 20:25.22 | zecke | RP: remove the old caching |
| 20:25.35 | zecke | RP: what about SkipPackage? |
| 20:25.54 | RP | zecke: I have that handled happily now |
| 20:26.20 | RP | We save a note it was skipped (and its __depends) |
| 20:26.22 | zecke | ah okay within the cache |
| 20:26.30 | RP | zecke: Does this have any implication for DataSmartPackage? |
| 20:27.19 | zecke | RP: we can remove some code |
| 20:27.34 | zecke | but I'm glad to remove it |
| 20:27.57 | RP | zecke: ok. I'm not 100% what it does but I'll have a look :) |
| 20:28.08 | RP | zecke: The only casualty is that after these changes is bb shell's poke doesn't work |
| 20:28.33 | RP | zecke: I think its a small price to pay and I suspect mickeyl can find a way around it :} |
| 20:28.58 | zecke | RP: well, we can move the 'dirty' handling to the Cache |
| 20:29.20 | zecke | RP: loadFullData would do this then?! |
| 20:29.22 | RP | zecke: The problem isn't dirty handling - pkgdata doesn't exist anymore |
| 20:30.38 | zecke | RP: the only thing I need to point out |
| 20:30.44 | zecke | RP: Document the Cache |
| 20:30.56 | RP | zecke: I promise to :) |
| 20:30.57 | zecke | RP: the idea under class Cache:\n"""Here is my plan...""" |
| 20:31.20 | RP | zecke: If we rip out the old cache it gets much simpler and easier to document |
| 20:31.31 | zecke | RP: rip it out |
| 20:31.40 | RP | zecke: ok :) |
| 20:31.41 | zecke | RP: we might have the C parser done soon as well thanks to mithro |
| 20:31.57 | zecke | RP: it gives so much issues... |
| 20:32.04 | zecke | RP: One more question |
| 20:32.06 | RP | zecke: As they'll speed up different things, this would be great :) |
| 20:32.20 | zecke | RP: do you cache the variables expanded or unexpanded? |
| 20:32.25 | RP | Which gives issues - the C parser or the cache? |
| 20:32.29 | RP | zecke: Expanded |
| 20:32.42 | zecke | RP: that needs to be changed |
| 20:32.49 | RP | zecke: Why? |
| 20:32.50 | zecke | RP: think of the moving SRCDATE |
| 20:34.22 | RP | zecke: If you want to do that, the whole idea is dead in the water |
| 20:34.47 | zecke | why? |
| 20:35.40 | RP | You can't use the unexpanded versions in the likes of findBestProvider and we don't cache enough to expand them |
| 20:36.20 | RP | expanding them also means potential calls to python methods and is way out of the scope of what the cache code currently does |
| 20:38.13 | RP | (Its also partially broken in the existing bitbake caching) |
| 20:38.32 | zecke | right |
| 20:38.45 | zecke | RP: okay this means we need to reparse once a day? |
| 20:39.11 | RP | zecke: For the change to DATE, yes |
| 20:39.48 | RP | For TIME, once per second :} |
| 20:40.16 | JustinP | {: |
| 20:43.35 | zecke | RP: hmm not too good then |
| 20:44.09 | zecke | ah delpart and addpart worked |
| 20:44.18 | zecke | I just had to redo my error ;) |
| 20:45.07 | RP | zecke: It will only use the cached data to make the decisions about which packages to build. It will reexpand the variables when it acutally builds a provider |
| 20:45.28 | RP | I realise this could get slightly confusing :-/ |
| 20:46.27 | koen|tv | RP: just call it 'MagicCache' |
| 20:47.11 | RP | To be honest, I think people would prefer the speed than 100% cache accuracy. If they want accuracy, they can reparse... |
| 20:47.31 | polyonymous | If only reparse reparsed! :) |
| 20:48.29 | zecke | RP: hmm I wanted to say I'm offline for an hour |
| 20:48.43 | zecke | RP: but I decided to be offline tomorrow and monday so I can hack now |
| 20:49.37 | RP | zecke: Don't let me put you off exam revision or whatever - this can wait |
| 20:50.00 | zecke | RP: it is Wednesay and Friday |
| 20:50.09 | zecke | RP: and I think I already know enough to pass it |
| 20:51.02 | RP | I used to get addicted to new TV series and spider solitaire before exams :-/. Anything but revision :) |
| 20:51.13 | koen | heh |
| 20:51.17 | koen | spider solitaire |
| 20:51.41 | koen | and watching stargate sg1's first 6 seasons in about 2 weeks |
| 20:51.58 | zecke | koen: invite me the next time |
| 20:52.54 | zecke | koen: does a 'diff' ipk script exist? |
| 20:53.38 | RP | zecke: How about I put it this way - Our current cache isn't scalable. My proposal is more scalable and the drawback you mention isn't a fundamental part of the design |
| 20:54.38 | koen | zecke: just unpack the ipkgs? |
| 20:54.38 | RP | There is nothing stopping us changing it to use unexpanded data, if we can work the depencencies out |
| 20:54.38 | zecke | right |
| 20:54.46 | RP | (Which may be possible which a cache dummy front to the data store to see which variables we look at) |
| 20:55.13 | RP | I'll adapt the patch to remove the existing cache and see where I end up |
| 21:03.30 | zecke | right |
| 21:04.20 | zecke | oh well, I watch that movie and then I'm going to read some more |
| 21:08.03 | *** join/#oe cromain (n=cromain@AToulouse-157-1-51-183.w86-207.abo.wanadoo.fr) |
| 21:13.40 | *** join/#oe katossi (n=guillerm@p54AE5AF8.dip.t-dialin.net) |
| 21:14.35 | JustinP | RP: Did you get that sound interrupt rewrite done that you mentioned to me before? |
| 21:14.51 | RP | JustinP: Sound interrupt? |
| 21:15.36 | JustinP | I shall quote from....months ago |
| 21:15.46 | JustinP | +12:13 < RP> JustinP: There is going to be an issue with it fighting the sound system for the headphone interrupt |
| 21:15.49 | JustinP | +12:14 < RP> JustinP: I'm about to rewrite the headphone interrupt handling anyway so the best soution might be to just comme\ |
| 21:15.52 | JustinP | nt it out in the sound code |
| 21:15.59 | JustinP | sorry, copied from my patch :-/ |
| 21:16.12 | RP | Yes, that's all handled by the input system now |
| 21:16.23 | RP | and even in mainline :) |
| 21:16.26 | JustinP | cool |
| 21:16.36 | JustinP | so I'm going to need to fix the remote then |
| 21:16.57 | JustinP | in fact, the patch probably doesn't fully apply anymore anyway....I'm about to try to get it to apply to 2.6.16 |
| 21:17.36 | RP | Instead of disabling it in the sound driver, you need to disable in the keyboard driver (or better, share it) |
| 21:17.45 | RP | drivers/input/keyboard/spitkbd.c |
| 21:17.46 | JustinP | once I know it applies could you take a look at the interrupt and let me know what needs to be changed? |
| 21:17.57 | RP | To disable it? |
| 21:18.06 | JustinP | disabling the keyboard interrupt doesn't sound like a good idea to me.... |
| 21:18.20 | RP | No, just the headphone interrupt |
| 21:18.33 | RP | There are lots of interrupts in the keyboard driver... |
| 21:18.46 | JustinP | ok |
| 21:18.57 | JustinP | well, sharing also sounds like a good idea.... |
| 21:19.31 | RP | It would be best for you to talk to someone who's shared interruts before - I haven't so I don't know what the pitfalls are |
| 21:19.44 | JustinP | hmmmm...fun.... |
| 21:20.09 | zecke | RP: oh |
| 21:20.13 | RP | To disable, basically find the line that says request_irq*AK_INT and comment it out in the file I mentioned |
| 21:20.17 | JustinP | so the headphone interrupt handles insert/eject of headphone jack, right? |
| 21:20.22 | RP | yes |
| 21:20.36 | JustinP | ok |
| 21:20.44 | RP | zecke: oh? |
| 21:20.45 | JustinP | well, I'll see if I can get this thing working again |
| 21:22.04 | *** join/#oe rwhitby (n=rwhitby@nslu2-linux/rwhitby) |
| 21:23.49 | mickeyl | RP: good stuff |
| 21:23.55 | zecke | mickeyl: hey |
| 21:24.02 | RP | hi mickeyl :) |
| 21:24.13 | mickeyl | I will shed a tear when you rip off the cache though :)) |
| 21:24.28 | zecke | RP: could you try r433 and see if that changed anything |
| 21:24.47 | RP | mickeyl: Its really the same code with a slightly different method ;-) |
| 21:24.51 | zecke | RP: if it did, I will explain the oh |
| 21:25.01 | zecke | mickeyl: another pattern is applied ;) |
| 21:25.03 | RP | mickeyl: I'm afraid I'll break the shell's poke command but I there are ways it can be fixed again |
| 21:25.16 | zecke | RP: I broke it as well ;) |
| 21:25.17 | mickeyl | RP: right. |
| 21:25.21 | zecke | RP: don't worry about that |
| 21:27.12 | mickeyl | times have changed. when i added the cache, we had less metadata and parsing was even more infefficient. |
| 21:27.16 | mickeyl | good to have a new scheme now |
| 21:27.25 | koen | hey mickeyl |
| 21:27.28 | Ecco | Guys |
| 21:27.40 | Ecco | Is it ok to report some Zaurus kernel bugs into OE's bugtracker ? |
| 21:27.45 | RP | mickeyl: The fast reparse is quite scary when you're used to the old bitbake :) |
| 21:27.57 | mickeyl | RP: indeed. looks like it's just doing nothing |
| 21:28.14 | mickeyl | Ecco: yeah, go ahead. use oz 3.5.4.x as product |
| 21:28.30 | Ecco | Ok |
| 21:28.34 | Ecco | I think that'll interest RP |
| 21:28.49 | Ecco | Remember that USB_gadget bug ? |
| 21:29.05 | RP | Ecco: yes |
| 21:29.06 | mickeyl | RP: I guess with that few data to cache it makes no sense to try to use marshall instead of pickle. we wouldn't gain much now |
| 21:29.20 | Ecco | It looks like it is happens because USB_host is hardcoded within OZ 3.5.4.1 Akitta's kernet |
| 21:29.22 | Ecco | kernel |
| 21:29.25 | Ecco | does that make sense ? |
| 21:29.53 | RP | Ecco: Kind of. Do you know where its hardcoded? |
| 21:30.06 | Ecco | What do you mean ? |
| 21:30.07 | RP | mickeyl: Its a single pickle/unpick operation now on an ~8MB file :) |
| 21:30.15 | Ecco | I mean that actually usbcore is not a module |
| 21:30.18 | TheMasterMind1 | what is the usb gadget bug? |
| 21:30.21 | Ecco | it's built straight into the kernel |
| 21:30.30 | RP | Ecco: And that makes the difference? |
| 21:30.32 | Ecco | TheMasterMind1, on my C-1000 usb gadget acts really weird |
| 21:30.39 | Ecco | RP : I don't know wether that's it |
| 21:30.44 | Ecco | I rolled out my own kernel |
| 21:30.49 | Ecco | without usbcore at all |
| 21:30.51 | TheMasterMind1 | i'm trying to get usb gadget ether recognized by osx |
| 21:30.56 | RP | Ecco: usbcore shouldn't make any difference at all if ohci_hcd isn't loaded |
| 21:31.14 | Ecco | TheMasterMind1 : g_ether works great with OSX out of the box |
| 21:31.14 | RP | ohci_hcd is what talks to the hardware, nothing else. |
| 21:31.19 | Ecco | hmmm |
| 21:31.24 | Ecco | Ok, so it might be not that |
| 21:31.30 | Ecco | But it's really "random" |
| 21:31.38 | Ecco | I thought it could be related to Power Managment |
| 21:31.52 | RP | If you can show that ohci_hcd leaves the machine in the wrong state to support UDC, that would be a bug |
| 21:31.52 | Ecco | but it looks like it works (and doesn't) both with AC or not |
| 21:32.06 | Ecco | hmm, indeed I never used ohci_hcd |
| 21:32.31 | RP | but ohci_hcd was autoloaded by your original OZ supplied kernel |
| 21:32.32 | TheMasterMind1 | Ecco: strangely enough it isn't for me. osx says initDevice failed |
| 21:32.45 | Ecco | TheMasterMind1, Does OSX enumerate your device ? |
| 21:32.54 | Ecco | In fact the problem is not with g_ether |
| 21:32.56 | mickeyl | RP: now that the command line is so fast, one of the reasons for the shell vanished. I need to improve it to drag people into using it :D |
| 21:33.13 | Ecco | it's with the pxa27x__udc |
| 21:33.29 | mickeyl | ! :) |
| 21:33.30 | cdbot | mickeyl: I have no frelling idea! |
| 21:33.33 | polyonymous | mickeyl, speaking of which. |
| 21:33.35 | koen | mickeyl: I take bribes in the form of Leffe Radieusse |
| 21:33.45 | mickeyl | koen: hehe. |
| 21:34.03 | polyonymous | mickeyl, when I say 'reparse' I want it to reparse even if it thinks the file is up to date, but I know included files aren't :) |
| 21:34.06 | TheMasterMind1 | Ecco: enumerate? |
| 21:34.10 | Ecco | Yeah |
| 21:34.20 | RP | mickeyl: I can't wait to see what these impovements will be :) |
| 21:34.23 | mickeyl | polyonymous: right. that timestamp check is bogus. I'll remove it asap |
| 21:34.32 | Ecco | Basically the host PC doesn't even see the device (the Zaurus) |
| 21:34.40 | mickeyl | I'm still dreaming about complete GUI frontend... |
| 21:34.46 | polyonymous | mickeyl, just wanted to make sure you know about it. |
| 21:34.50 | polyonymous | mickeyl, _G_UI? |
| 21:34.51 | koen | mickeyl: and 'addparse' for new files/versions |
| 21:34.53 | mickeyl | polyonymous: yeah |
| 21:34.59 | RP | mickeyl: Once I write this multithreaded bitbake, it'll need a UI and I'm hoping to talk to you about it when it gets to that point ;-) |
| 21:35.02 | polyonymous | Why would one want the 'G' part there?? |
| 21:35.03 | mickeyl | yes, GUI as in graphical :)) |
| 21:35.10 | koen | *G*ui, not a *Q*ui |
| 21:35.13 | koen | ;) |
| 21:35.16 | polyonymous | Oui :) |
| 21:35.17 | TheMasterMind1 | Ecco: well in this case i'm working with a pxa255 based gumstix |
| 21:35.17 | mickeyl | heh |
| 21:35.25 | mickeyl | RP: sounds good |
| 21:35.37 | polyonymous | Well, I can't imagine the special graphical effects you have to offer :) |
| 21:36.04 | RP | mickeyl: I think the timestamp check might get fixed in my current rearrangement of things |
| 21:36.05 | Ecco | TheMasterMind1, ok, so if you do "Apple -> About this Mac -> More Info -> USB", can you see the gumstick ? |
| 21:36.09 | XorA|gone | JustinP: ping |
| 21:36.16 | koen | hey XorA|gone |
| 21:36.17 | polyonymous | kind of browsing would be nice though, but I was thinking about making a web frontend for it. |
| 21:36.32 | mickeyl | polyonymous: it would be more than just a GUI for what bitbake can do now. I'm thinking more along the lines of a Bitbake IDE. like, adding a new distro wizard, adding a new .bb, debugging .bb's etc. |
| 21:36.37 | mickeyl | RP: ah, yeah |
| 21:36.38 | XorA | hey koen |
| 21:36.42 | XorA | morning |
| 21:36.42 | TheMasterMind1 | Ecco: ah didn't even know that was there. indeed i see a 'RNDIS/Ethernet Gadget' listed |
| 21:36.48 | polyonymous | mickeyl, I see. That's different. |
| 21:37.16 | koen | mickeyl: eclipse integration |
| 21:37.16 | Ecco | TheMasterMind1, so you're good with that |
| 21:37.23 | koen | did I really say that? |
| 21:37.25 | polyonymous | So far I'm happy with the shell -- saves time tremendously. |
| 21:37.27 | Ecco | Now it's easy : modprobe g_ether on the device |
| 21:37.34 | Ecco | bring usb0 up with an ip addres |
| 21:37.36 | mickeyl | java zealot :D |
| 21:37.40 | Ecco | get to "System preferences, Network" |
| 21:37.47 | Ecco | and it says "A new device appeared" |
| 21:37.49 | mickeyl | use a leffe, not soap |
| 21:37.51 | Ecco | and you' ready to go |
| 21:38.15 | JustinP | XorA: Pong? |
| 21:38.27 | XorA | JustinP: answered your email about gnome-vfs-dbus |
| 21:39.07 | TheMasterMind1 | Ecco: nope, no go. if i bring up system.log i can see a 'AppleUSBCDC: start - initDevice failed' |
| 21:39.15 | Ecco | Hmm |
| 21:39.17 | Ecco | that's weird |
| 21:39.23 | Ecco | Maybe you're using an old kernel ? |
| 21:39.30 | Ecco | I've been using it on OMAP and on PXA |
| 21:39.32 | JustinP | XorA: I don't see anything.... |
| 21:39.35 | RP | zecke: My parsing errors don't show under r433 |
| 21:39.40 | Ecco | as long as the udc worked, g_ether worked well :-) |
| 21:39.41 | TheMasterMind1 | i'm using 2.6.11 here |
| 21:39.50 | RP | (apart from the duplicate methods ones) |
| 21:40.05 | TheMasterMind1 | ok so problem is in udc, that helps |
| 21:40.18 | TheMasterMind1 | enable_irq(58) unbalanced from bf0514bc on module load |
| 21:40.21 | Ecco | TheMasterMind1, it may not be in udc |
| 21:40.30 | Ecco | I think it's not since your device is enumerated properly |
| 21:40.36 | XorA | JustinP: literally just answered, let the mail servers catch up :-) |
| 21:40.39 | Ecco | Try to switch to a recent version |
| 21:40.41 | zecke | RP: but the dependency issue is still present? |
| 21:40.43 | Ecco | like 2.6.16 or so |
| 21:41.01 | TheMasterMind1 | alright, will try |
| 21:41.07 | zecke | RP: I applied a hunk of your patch |
| 21:41.11 | RP | zecke: No, its not showing it |
| 21:41.25 | RP | zecke: Which hunk? |
| 21:41.32 | zecke | - if not var in self.dict: |
| 21:41.32 | zecke | - self._makeShadowCopy(var) |
| 21:41.53 | zecke | in the train I thought, we need to shadow it first |
| 21:42.04 | zecke | to not influence the other users |
| 21:42.10 | RP | zecke: So I was sort of right :) |
| 21:42.22 | zecke | RP: at least you forced me into a review |
| 21:43.14 | RP | zecke: My current bitbake is messed up and those test results are invalid, sorry :-( |
| 21:43.21 | RP | ~lart svn |
| 21:43.25 | zecke | oh |
| 21:43.43 | zecke | anyway, the lines were wrong, or simply not needed |
| 21:45.33 | mickeyl | hmm with 3 seconds we should probably tweak or remove the progress bar altogether |
| 21:46.00 | RP | mickeyl: We still need it for the inital parse |
| 21:46.09 | mickeyl | oh right |
| 21:46.36 | RP | mickeyl: and it is nice to watch spinning like crazy on the reparse :) (I tried removing it and it didn't seem to make much difference) |
| 21:46.55 | polyonymous | RP, try it over 2400 line :) |
| 21:47.01 | zecke | RP: yeah that was my finding as well |
| 21:47.36 | RP | polyonymous: pipe to a file ;-) |
| 21:47.53 | polyonymous | RP, piping progess meter to a file is the most brilliant idea ever! :) |
| 21:49.01 | RP | zecke: Having updated to your latest changes properly, the parser is flying :) |
| 21:49.23 | zecke | RP: hmm it still fails on matchbox |
| 21:51.17 | RP | zecke: A full parse was 7 minutes before, now without the cache files to write and with your changes, its 2.45 mins :) |
| 21:51.27 | RP | zecke: and the quilt dependency issue didn't show up |
| 21:51.41 | zecke | RP: oh well, I have the same issue I had before :} |
| 21:51.50 | zecke | RP: but that is due cached loading it seems |
| 21:51.53 | koen | just wait for mithro to say "20 seconds" :) |
| 21:52.16 | RP | koen: My cache will still be faster ;-) |
| 21:52.16 | zecke | RP: push it, push it, push it |
| 21:52.23 | zecke | says my evil mind |
| 21:52.56 | CIA-9 | 03koen 07org.oe.dev * r4ed4d06c... 10/packages/binutils/ (11 files): binutils_*.bb: apply patch from OE bug #812 to all binutils versions |
| 21:55.04 | RP | ok, latest patch: http://www.rpsys.net/openzaurus/temp/bitbake_newcache-r2.patch |
| 21:55.21 | RP | Applies to head, doesn't revert anything hopefully. |
| 21:55.38 | RP | I need to filter out the fetcher change that's lost in there but it won't hurt anyone |
| 21:55.50 | zecke | RP: do we want to sync on keyboard interrupt? |
| 21:55.57 | RP | zecke: yes |
| 21:56.09 | RP | zecke: It will then continue parsing where it left off |
| 21:56.10 | zecke | <PROTECTED> |
| 21:56.10 | zecke | + if not var in self.dict: |
| 21:56.11 | zecke | + self._makeShadowCopy(var) |
| 21:56.15 | zecke | it reverts that part |
| 21:56.17 | zecke | :( |
| 21:56.51 | zecke | RP: make sure to not commit fetch/__init__.py accidently |
| 21:56.58 | zecke | RP: feel free to commit it though |
| 21:57.33 | RP | zecke: What do you think about iterating over the src mirror like that? |
| 21:57.41 | zecke | RP: I'm fine with that |
| 21:57.55 | RP | I'll clean up and commit it separately |
| 21:59.04 | zecke | RP: We can remove DataSmartPackage completely |
| 21:59.09 | zecke | RP: wait a second |
| 21:59.25 | RP | zecke: I thought that might be possible but was going to ask you |
| 21:59.29 | zecke | ah no |
| 22:00.05 | zecke | oh welll ;) |
| 22:00.11 | zecke | we can only use createCopy |
| 22:00.28 | zecke | we won't have a 'detached' Dict |
| 22:02.36 | *** join/#oe katossi (n=guillerm@p54AE5AF8.dip.t-dialin.net) |
| 22:02.47 | zecke | RP: I'm getting tons of kernel-abiversion errors |
| 22:02.49 | zecke | weird |
| 22:03.10 | RP | zecke: I was seeing them earlier I think |
| 22:03.28 | zecke | RP: it is looking tim TMPDIR, so it can't find them... |
| 22:04.11 | koen | XorA: speeling cheecker ;) |
| 22:04.11 | zecke | now a way to 'diff' the results of a bitbake run would be nice |
| 22:05.03 | RP | zecke: Ah, those variables - they've caused me problems in the past as you can only evaluate them properly after the kernel is staged :-/ |
| 22:05.21 | zecke | RP: hmm, building quilt fails |
| 22:05.28 | zecke | RP: smells like an update_data issue |
| 22:05.38 | RP | zecke: With the error I had? |
| 22:06.11 | zecke | RP: okay with the cache it takes about 3-4 seconds |
| 22:06.28 | zecke | RP: But I'm getting tons of RDEPENDS failures here |
| 22:07.04 | RP | zecke: Can you pastebin it? |
| 22:07.43 | zecke | RP: ah... |
| 22:08.00 | zecke | Rhttp://oe.pastebin.com/662186 |
| 22:08.12 | zecke | every kernel module failed with RDEPENDS |
| 22:08.25 | zecke | because there were parse errors with them before |
| 22:09.13 | RP | zecke: Ah, if the parsing aborts, that might leave the cache in a bad state. We should really trap that and delete the cache entry upon any parse error |
| 22:09.55 | koen | I just had a disturbin realization about the bitbake C parser |
| 22:09.57 | zecke | "${@base_read_file('${STAGING_KERNEL_DIR}/kernel-abiversion')} |
| 22:10.05 | zecke | koen: yes? |
| 22:10.14 | RP | zecke: I've always thought this was evil... |
| 22:10.15 | koen | it will probably break with -OMG -gentoo cflags |
| 22:10.38 | zecke | mithro: can people pass CFLAGS with pyrex? |
| 22:11.01 | zecke | koen: we probably run unittests on loading the module |
| 22:11.04 | *** join/#oe tnb (n=tnb@19.sub-70-194-231.myvzw.com) |
| 22:11.11 | zecke | koen: and if it fails we fall back to python |
| 22:11.15 | koen | heh |
| 22:11.21 | koen | anyway |
| 22:11.24 | koen | 'night all |
| 22:11.28 | RP | zecke: Those RDEPENDS certainly look like the original parsing failed corrupting the cache |
| 22:11.33 | RP | 'night koen|sleep |
| 22:11.37 | zecke | koen: or we put #ifdef GNUC > 2 #error "Unsupported compiler" #endif |
| 22:11.51 | TheMasterMind1 | Ecco: now it won't enumerate =\ |
| 22:11.55 | RP | zecke: Parsing shouldn't fail ;-) |
| 22:12.06 | zecke | RP: right, it throw an Exception on evaluating the __anonfunc() {} |
| 22:12.23 | zecke | RP: which brings you into the generic Exception handler |
| 22:12.46 | zecke | RP: you were not able to expand 'RDEPENDS' |
| 22:12.51 | zecke | RP: and now I suffer ;) |
| 22:13.19 | RP | zecke: It should just remove any entry from the cache that throws an exception... |
| 22:13.37 | *** join/#oe cromain (n=cromain@AToulouse-157-1-51-183.w86-207.abo.wanadoo.fr) |
| 22:13.42 | zecke | RP: go ahead ;) |
| 22:14.18 | zecke | Can we name this release "'N' stands for sucky monpoly" |
| 22:16.01 | TheMasterMind1 | Ecco: ok shows up. does your pxa device show up with product id a4a2 or a4a1? |
| 22:16.19 | *** part/#oe evildevil (n=evildevi@p54A6ED26.dip.t-dialin.net) |
| 22:19.54 | *** join/#oe brons|away (n=bronson@c-24-61-215-44.hsd1.ma.comcast.net) |
| 22:20.01 | zecke | RP: found another bug |
| 22:22.21 | RP | zecke: go on :) |
| 22:23.11 | Ecco | TheMasterMind1, I don't know |
| 22:23.20 | Ecco | TheMasterMind1, in fact on pxa27x |
| 22:23.23 | zecke | RP: you do not link/copy the 'seen overrides cache' |
| 22:23.28 | Ecco | udc is very "buggy" |
| 22:23.30 | zecke | RP: how to proceed now |
| 22:23.34 | Ecco | in fact when it works it works great |
| 22:23.39 | zecke | RP: I would patch some files |
| 22:23.41 | Ecco | but sometimes it just isn't enumerated |
| 22:23.47 | zecke | RP: how to send you the patch of the patch? |
| 22:24.19 | RP | zecke: Will I see what you mean from a diff or not? |
| 22:24.28 | TheMasterMind1 | Ecco: ah. well looking at ether.c there's a define if using pxa2xx that only uses a subset of cdc, but doesn't look like its being set |
| 22:24.45 | Ecco | hmm |
| 22:24.48 | Ecco | weird |
| 22:24.49 | zecke | RP: I'm killing DataSmartPackage now |
| 22:24.49 | RP | zecke: Or should I commit this and we can take it from there? |
| 22:24.57 | zecke | RP: probably better |
| 22:25.42 | RP | zecke: I have that exception handling working much better |
| 22:25.47 | zecke | nice :) |
| 22:26.27 | RP | give me a few minutes to sanity check this diff, then I'll commit |
| 22:27.10 | zecke | I will fool myself and look into one of the 'scripts' and study |
| 22:32.37 | zecke | RP: with my fix we could see the breakage returning |
| 22:32.42 | zecke | wait a second before comitting |
| 22:34.54 | gerwinin | Zecke can you give me the link to the new oe website ? |
| 22:35.34 | zecke | gerwinin: new website? If we have one, I don't know it |
| 22:35.39 | gerwinin | okay |
| 22:36.23 | gerwinin | Zecke: Shall we make one ? |
| 22:36.37 | zecke | RP: please don't commit |
| 22:36.48 | zecke | RP: we are back to the 'parsing' errors |
| 22:37.20 | RP | zecke: Due to who's changes? |
| 22:37.26 | zecke | RP: mine |
| 22:38.03 | zecke | RP: if you commit, all overrides from conf/bitbake.conf |
| 22:38.05 | zecke | will be lost |
| 22:38.37 | zecke | this leads to the fetchers not working correctly |
| 22:39.06 | RP | zecke: This was caused by the last change you made? |
| 22:39.24 | zecke | RP: locally |
| 22:39.33 | zecke | currently self._seen_overrides = copy.deepcopy(parent._seen_overrides) self._special_values = copy.deepcopy(parent._special_values) |
| 22:39.41 | zecke | is missing in DataSmartPackage |
| 22:40.00 | zecke | (well I have them as copy.copy in HEAD) |
| 22:40.19 | zecke | okay these two dicts need COW as well |
| 22:40.29 | zecke | BTW: Is cow patented? |
| 22:40.40 | RP | Lets hope not |
| 22:41.34 | XorA | koen|sleep: how else do I test it :-) |
| 22:42.19 | zecke | RP: okay, we can commit something that works now |
| 22:42.34 | zecke | RP: but it will be way slower (on initial parse) |
| 22:42.49 | RP | zecke: :-( |
| 22:42.57 | zecke | RP: (for now) |
| 22:43.01 | RP | zecke: We can't keep the speed gain in any way? |
| 22:43.03 | zecke | cross your figers |
| 22:43.13 | RP | zecke: So I can commit? |
| 22:43.37 | zecke | hold your fingers crossed |
| 22:44.02 | zecke | ~900 files more to parse |
| 22:45.02 | zecke | commit please |
| 22:46.55 | RP | zecke: ok, doing that now |
| 22:46.59 | zecke | good |
| 22:47.13 | zecke | RP: I will tmp decrease parsing performance due a deepcopy |
| 22:47.25 | RP | zecke: ok |
| 22:49.00 | TheMasterMind1 | Ecco: strange, usbnet on linux doesn't claim the gadget as well |
| 22:49.32 | zecke | *can't wait* |
| 22:50.05 | RP | zecke: nearly there |
| 22:52.40 | RP | zecke: Committed revision 434. |
| 22:52.49 | zecke | congrats |
| 22:53.27 | RP | zecke: Isn't that the deepcopy? :) |
| 22:53.37 | zecke | right |
| 22:53.37 | polyonymous | s/jealous/an asshole/ ;-) |
| 22:54.14 | zecke | polyonymous: well I'm an asshole, cause I'm canadian... (southpark) actually because I'm jealous |
| 22:54.35 | polyonymous | I don't know much about southpark, but I couldn't resist it! |
| 22:56.38 | Ecco | TheMasterMind1, I don't know where that come from |
| 22:58.11 | zecke | RP: comitted my performance decreasing code |
| 22:58.32 | zecke | RP: it should still be faster than before |
| 22:58.56 | zecke | RP: could we add a version number to the cache this time? |
| 22:59.27 | TheMasterMind1 | Ecco: i found some docs.. this kernel is set to use RNDIS so it works with windows, and that requires some experimental module enabled on my linux kernel, and explains why it doesn't work in osx |
| 22:59.40 | Ecco | haaa |
| 22:59.43 | Ecco | Cool ! |
| 22:59.57 | TheMasterMind1 | i thought usbnet worked with windows though, i'm not sure why this rndis is required |
| 23:01.26 | zecke | RP: I'm killing the dead classes now |
| 23:01.56 | RP | zecke: Even after the performance decreasing code, it seems quite fast :) |
| 23:02.21 | RP | zecke: A version number would be good and we should add that before any release |
| 23:02.26 | zecke | RP: could be my vmware server instances slowing things down :} |
| 23:02.48 | zecke | RP: (Number,[Dict]) |
| 23:03.05 | zecke | RP: this way we can extend the format |
| 23:03.15 | zecke | RP: always unpickle it to load the data... |
| 23:03.33 | zecke | RP: I'm killing the various Dead Classes now |
| 23:04.14 | RP | zecke: I'll look at documenting the cache a bit. Only after that will I think about new code... |
| 23:04.33 | zecke | awesome |
| 23:05.06 | gerwinin | Zecke: did you place the survey already ? |
| 23:05.16 | zecke | gerwinin: not yet |
| 23:06.46 | gerwinin | Zecke: I will have a look tomorrow at making a plan for the website |
| 23:07.20 | gerwinin | Zecke: it should be easy to maintain and it should be an add-on to the wiki |
| 23:07.28 | TheMasterMind1 | meh, microsoft at it again, screwing compatibility left and right |
| 23:07.45 | zecke | gerwinin: we need a clean seperation |
| 23:07.57 | gerwinin | zecke: ok |
| 23:08.00 | zecke | gerwinin: what goes on the website, what into the wiki |
| 23:08.12 | gerwinin | Zecke: I will take care of that |
| 23:08.13 | zecke | gerwinin: and it should be easily editable... |
| 23:08.18 | zecke | nice |
| 23:08.35 | gerwinin | Zecke: furthermore I want to make a clear plan for liasons per country |
| 23:08.45 | zecke | gerwinin: good as well |
| 23:09.21 | gerwinin | Zecke: for coding issues I am working now on the autentec driver it seems I got some usb endpoint problem |
| 23:09.41 | zecke | gerwinin: I have never heard of that (autentec) |
| 23:10.02 | gerwinin | zecke: it are those fingerprint sensors |
| 23:12.41 | *** join/#oe drw (n=drw@c-67-172-219-167.hsd1.tx.comcast.net) |
| 23:12.47 | *** part/#oe gerwinin (n=gerwinin@ip5457b30e.direct-adsl.nl) |
| 23:12.57 | zecke | good nite gerwinin ;) |
| 23:18.02 | zecke | RP: I have killed the dead classes |
| 23:18.18 | RP | zecke: ok, thanks :) |
| 23:18.39 | zecke | hmm it is still transmitting |
| 23:19.09 | zecke | 436 |
| 23:19.15 | RP | zecke: That deep copy changed the initial parse from 2:45 to 4 mins :-/ |
| 23:19.19 | zecke | okay I think we are not too far away from a next release |
| 23:20.10 | zecke | I need to take an exam in "Design and Analysis of Algorithms" |
| 23:20.25 | zecke | I think I showed some basic understanding here already... |
| 23:20.42 | RP | Lets convince a few people to test current head and see what state its in... |
| 23:20.47 | zecke | I need to get done with uni faster... |
| 23:20.50 | RP | zecke: Just a bit :) |
| 23:21.00 | RP | zecke: This was why I did Physics... |
| 23:21.13 | zecke | RP: I'm starting with Physics this year :} |
| 23:21.21 | zecke | Physics for scientists |
| 23:21.49 | RP | I achieved what I set out to do - understood General Relativity :) |
| 23:22.18 | polyonymous | RP, so, you're the third one? |
| 23:22.29 | zecke | RP: I really get depressed about my big list of exams... |
| 23:22.42 | RP | polyonymous: Well, I got as close as anyone ever gets :) |
| 23:22.49 | polyonymous | :)) |
| 23:23.02 | zecke | hehe |
| 23:23.59 | polyonymous | Eddington should be proud of you. |
| 23:39.49 | zecke | RP: I'm currently thinking of having a generic COW dict... |
| 23:40.29 | RP | zecke: I'm still confused as to how the dictonary works and what all the bits do :) |
| 23:41.09 | zecke | RP: Don't ask ;) |
| 23:41.16 | RP | Well, I understand the idea of COW and the basic dictonary operations, just not what happens in all the classes :) |
| 23:41.42 | RP | zecke: If you tell me you can make it faster/neater, Im happy to go along with it :) |
| 23:41.46 | zecke | RP: for each var you can have the var itself (content) and other flags |
| 23:42.27 | zecke | RP: All I can say, I'm an asshole I can break it, without you being able to prove it (due lack of testcase) |
| 23:42.52 | RP | zecke: I guess I can claim the same thing with the Cache and the Rdepends handling :) |
| 23:43.14 | RP | zecke: One thing we can easily do now it make an unfulfilled rrecommend none fatal btw |
| 23:43.38 | zecke | I'm going to bed now |
| 23:43.49 | zecke | no COW for me, I will read some more in this texbook |
| 23:44.04 | RP | Probably wise. I'll not be long in following - maybe I'll finish documenting first |
| 23:44.21 | zecke | RP: we need to find a solution for this kernel-abi thing |
| 23:44.53 | RP | zecke: Yes. Its one evil variable which I suspect should be made illegal :-/ |
| 23:45.01 | RP | but what to replace with? :-/ |
| 23:45.15 | zecke | why does it end up in DEPENDS (for modutils?) |
| 23:45.33 | zecke | oh it is a RDEPENDS |
| 23:45.35 | RP | It should only end up in RDEPENDS |
| 23:45.59 | zecke | and it is legal to not have a valid RDEPENDS before your dependencies are build? |
| 23:46.20 | RP | So some would argue |
| 23:46.36 | RP | bitbake does ignore the versions in RDEPENDS anyway... |
| 23:47.33 | zecke | or have a default variable |
| 23:47.41 | RP | Perhaps we add an exception handler to that piece of code - have it return None if the file isn't present |
| 23:47.45 | zecke | UNKNOWN |
| 23:47.52 | RP | yes |
| 23:47.53 | zecke | so the package gets the right version... |
| 23:48.13 | RP | Yes. At the end of the day, bitbake won't care about it |
| 23:49.14 | zecke | okay cya |
| 23:49.36 | RP | zecke: ok, 'night! |
| 23:49.37 | *** join/#oe evildevil (n=evildevi@p54A6ED26.dip.t-dialin.net) |
