**** BEGIN LOGGING AT Thu Jun 30 23:59:57 2005 Jul 01 00:01:35 Looks like the nslu2-linux branch is back up to speed (all the previous changes merged.) Jul 01 00:03:07 koen: good morning Jul 01 00:03:28 strange name... Ångström Jul 01 00:03:52 it looks like I'm going to have to reconfigure my keyboard or X to be able to type it... :/ Jul 01 00:04:31 morning Jul 01 00:04:39 Arjan: 'angstrom' works too :) Jul 01 00:04:52 good morning hrw|work Jul 01 00:06:46 __law__ (and anyone else inconvenienced by having two heads) - simply supply the revision number of the head you want to the co command: Jul 01 00:07:01 mt --db=monotone.vanille.de.db --branch=org.openembedded.dev co 532d9ba2654dfb76ff4b9272867357a92726e966 org.openembedded.dev Jul 01 00:07:55 koen: just curious, who made the decision and why isn't it just Familiar? Jul 01 00:08:39 mickeyl and me, and we're going 'fedora' Jul 01 00:08:58 familiar = stable, angstrom = bleeding edge Jul 01 00:09:18 I see. that's a valid reason IMHO :) Jul 01 00:10:01 all clueless sharpcloner will read it as angstROM ;) Jul 01 00:10:56 <__law__> jbowler, how to you get the revision? Jul 01 00:10:56 heh :) Jul 01 00:11:05 mt heads Jul 01 00:11:06 has a nice swing to it for us Dutch people :P Jul 01 00:11:30 angst is also english Jul 01 00:11:33 ~dict angst Jul 01 00:11:40 slightly different meaning, though Jul 01 00:11:44 Morning Jul 01 00:11:53 ibot is still under his stone :P Jul 01 00:12:39 note to self: do not switch gps to sirf mode when you have an old gpsd Jul 01 00:12:49 __law__: the revision id above is mickeyl's, use viewmtn to find out what you are getting... Jul 01 00:13:27 ok, I merged the ewi heads Jul 01 00:13:36 koen: what is a difference between 'monotone pull' & 'monotone sync'? Jul 01 00:13:38 hey guys, how goes the monotone ? Jul 01 00:13:59 Humm, so, the transition to monotone is done? Jul 01 00:14:04 hrw|work: pull doesn't try to push too Jul 01 00:14:04 sync == push+pull (important! sync will push!) Jul 01 00:14:06 hrw|work: sync also pushes Jul 01 00:14:11 ok. thx Jul 01 00:14:37 apt-cache search monotone gives me nothing on my ubuntu. Jul 01 00:14:51 What version should I use? Jul 01 00:14:56 0.19 ? Jul 01 00:15:00 0.19 Jul 01 00:15:15 http://venge.net/monotone/downloads/monotone_0.19-1_i386.deb Jul 01 00:15:20 Perhaps that one will be fine. Jul 01 00:15:42 Sirfred: ubuntu/breezy has 0.19 Jul 01 00:16:09 just look at all the nice branching and merging: http://ewi546.ewi.utwente.nl/tmp/viewmtn/revision.psp?id=3da092c52a5277b328d6f10a4c9c35567d157855 Jul 01 00:16:26 hrw|work: Well, I'm on Hoary, but that's a reason to migrate. Jul 01 00:16:37 hrw|work: Are you on breeze? More or less stable? Jul 01 00:16:45 s/breeze/breezy Jul 01 00:16:54 breezy is stable every now and then Jul 01 00:17:23 Enough for me, I'm changing my sources.list Jul 01 00:17:55 Sirfred: I'm on Debian 'sid' Jul 01 00:17:59 just make backups :) Jul 01 00:18:10 you can stay hoary, move to breezy just to install monotone, then go back to hoary Jul 01 00:18:26 debian etch has 0.19 Jul 01 00:18:42 rwhitby: Well, it's simpler just downloading the package from venge.net. Jul 01 00:18:49 dyoung-zzzz did the breezy-only-for-monotone trick and is seemed to work Jul 01 00:18:52 rwhitby: But I'm curious about breezy. Jul 01 00:19:19 Sirfred: you will find the boost libraries are the wrong version for the .deb from venge.net - been there, tried that Jul 01 00:19:37 :-\ Jul 01 00:19:48 but yeah, if is just an excuse for an upgrade you were wanting to make, then go for it :-) Jul 01 00:20:02 koen: That comment of "Just make backups"... Jul 01 00:20:04 I'm missing info what is pulled ;( Jul 01 00:20:11 koen: I expect it to be more stable than that. Jul 01 00:20:49 hrw|work: yeah, me too. Jul 01 00:20:50 breezy messed up my X Jul 01 00:21:25 koen: Just a configuration problem or something deeper? Jul 01 00:21:45 Who need X, anyway? ;-) Jul 01 00:22:11 a missing fontdir Jul 01 00:22:52 <__law__> do update my repo i only have to mt pull && mt co ? Jul 01 00:23:15 719 packages to update. Jul 01 00:23:48 __law__: I think you want pull and update for an existing working dir Jul 01 00:26:04 rwhitby: installed montone on your slug yet? Jul 01 00:28:12 <__law__> monotone --db=oe.db --branch=org.openembedded.dev update 532d9ba2654dfb76ff4b9272867357a92726e966 org.openembedded.dev want work :-( Jul 01 00:28:28 koen: I don't think we have it compiled for the slug yet Jul 01 00:28:44 __law__: last bit should just be org.openembedded Jul 01 00:28:50 * koen searches for some food Jul 01 00:29:35 koen: monotone does autotools fines, unfortunately it needs libboost and that has it's own implementation of make... Jul 01 00:30:06 (autotools fines - should mean 'inherit autotools' works fine with monotone). Jul 01 00:31:19 <__law__> rwhitby, but i have named my dir org.openembedded.dev Jul 01 00:31:36 oh Jul 01 00:33:13 __law__ if you executed that command before just cd into the directory and do mt sync; mt update Jul 01 00:34:06 koen: where is the official viewmtn now? (I've lost the ewi URL...) Jul 01 00:34:51 hmm.. 'monotone update' looks similiar to 'bk pull' Jul 01 00:35:24 bk pull == mt pull; mt update Jul 01 00:35:42 <__law__> jbowler, cd into dir adn do mt pull; mt update did it thanks Jul 01 00:36:05 <__law__> how can i see what has changed? Jul 01 00:36:14 'pull' uses anonymous read, 'sync' only works if you have a write key. Jul 01 00:36:26 <__law__> oh updateing.... Jul 01 00:36:33 changes: watch the output of mt upate, Jul 01 00:39:10 ok. time to go to hh.org and look what pass I had in oe wiki Jul 01 00:39:17 hey raster you there? Jul 01 00:39:35 i'm over here actually Jul 01 00:39:44 raster, was just curious about the win32 stuff ... someone has efl working in windows? Jul 01 00:39:46 lol Jul 01 00:40:27 no Jul 01 00:40:30 :) Jul 01 00:40:35 lol Jul 01 00:41:37 *yawn* Jul 01 00:47:49 How can I checkout the monotone repository? Jul 01 00:48:08 I suppose there's no documentation about it yet. Jul 01 00:48:53 I just want the parallel command to 'bk clone bk://openembedded.bkbits.net/openembedded' Jul 01 00:49:06 Sirfred: http://article.gmane.org/gmane.comp.handhelds.openembedded/4949 Jul 01 00:49:12 koen: Thanks! Jul 01 00:49:17 and http://oe.handhelds.org/cgi-bin/moin.cgi/MonotonePhraseBook Jul 01 00:50:18 koen: Yes, I've reached that link. Jul 01 00:52:06 you guys might want to consider a master makefile like http://www.nslu2-linux.org/Makefile ... with a local.conf template and top-level targets for each distro ... Jul 01 00:53:06 that's an idea Jul 01 00:53:46 wget and make :-) Jul 01 00:54:14 morning all Jul 01 00:54:27 g'day RP Jul 01 00:54:36 hey RP Jul 01 00:54:42 RP: Good morning. Jul 01 00:59:13 pb_: classes/kernel.bbclass depmod change uses get_kernelmajorversion(PV), when KERNEL_MAJOR_VERSION is defined below and uses the actual linux header: Jul 01 00:59:34 pb_: is there a reason for that, it causes our unslung kernel builds to fail because we have a non-standard PV. Jul 01 00:59:58 (based on linksys version) Jul 01 01:00:32 jbowler: I think to ease 2.4/2.6 parallel installability Jul 01 01:01:21 Right, the problem is that unslung ends up asking for depmod-2.3, when if KERNEL_MAJOR_VERSION was used it would (correctly) look for depmod-2.4 Jul 01 01:02:52 morning Jul 01 01:06:05 moring XorA Jul 01 01:06:47 hey XorA & mallum Jul 01 01:06:47 Hum, it won't work with KERNEL_MAJOR_VERSION because it has to be evaluated correctly when the .bb file is parsed, and KERNEL_MAJOR_VERSION only evaluates correctly after do_configure Jul 01 01:06:58 hey Jul 01 01:07:05 jbowler: could you put that in bugzilla? Jul 01 01:07:22 * koen walks to the gate to board his plane Jul 01 01:07:23 later Jul 01 01:07:37 koen: I think we will have to do a fix to unslung. Jul 01 01:08:13 jbowler: can we change kernel.bb and test it? Jul 01 01:08:31 oh, I see why not ... Jul 01 01:08:48 I looked at it, I can make a change to allow an override in the unslung .bb files, but that's all Jul 01 01:09:12 * __law__ updates all his oe scripts to monotone :-) Jul 01 01:20:29 howdy folks Jul 01 01:21:49 <__law__> is there something similar like http://openembedded.bkbits.net:8080/openembedded? Jul 01 01:21:50 Do I need to do a pull and a checkout in monotone to update my local copy? Jul 01 01:22:03 <__law__> Sirfred, use pull and update Jul 01 01:22:55 __law__: How is update syntax? Jul 01 01:23:37 __law__: I've tried to use 'co' as I read in http://oe.handhelds.org/cgi-bin/moin.cgi/MonotonePhraseBook, but it says me: Jul 01 01:23:49 monotone: misuse: monotone book-keeping directory 'MT' already exists in '/export/home/oe/src/org.openembedded.dev' Jul 01 01:23:49 <__law__> change into your openembedded dir and run monotone pull; monotone update Jul 01 01:23:58 __law__: Thanks. Jul 01 01:30:00 <__law__> np Jul 01 01:33:51 moring Jul 01 01:33:53 morning, too Jul 01 01:33:56 morning mickeyl Jul 01 01:34:00 g'day mickeyl Jul 01 01:34:06 how's monotone treating you? Jul 01 01:36:08 mickeyl: Good morning. Jul 01 01:37:19 morning mickeyl Jul 01 01:39:33 rwhitby-away: so far so good Jul 01 01:39:47 same here Jul 01 01:39:49 my two major griefs are Jul 01 01:39:52 a) no CGI log yet Jul 01 01:40:12 b) I don't directly see which files have been changed/added during a sync Jul 01 01:40:22 s/CGI/CIA/ Jul 01 01:40:28 mickeyl: for b) you do see it on the update Jul 01 01:40:43 mickeyl: yeah I missed that thig morning, just a bytes counter :-( Jul 01 01:41:00 I wonder if we could do a lua hook to show what is transferred during a netsync Jul 01 01:41:17 mickeyl: have you got your slug yet? Jul 01 01:41:41 rwhitby-away: postman should deliver it today Jul 01 01:41:45 *crossing fingers* :) Jul 01 01:41:52 so i can play with it during the weekend Jul 01 01:42:14 mickeyl: first thing to do is remove R83 :-) Jul 01 01:42:35 sounds like a resistor Jul 01 01:42:38 then the CPU will run at it's rated 266MHz instead of the half-speed 133MHz that Linksys set it to. Jul 01 01:42:50 d'oh. why would they do that? Jul 01 01:42:58 are they 'Sharp' ? :) Jul 01 01:43:09 http://www.nslu2-linux.org/wiki/HowTo/OverClockTheSlug Jul 01 01:43:31 one guy removed his with nail clippers :-) Jul 01 01:44:00 we have no idea why Linksys crippled it Jul 01 01:44:27 it doesn't seem to be any hotter when running at full speed (we've measured it as 2 degrees C hotter - 27 to 29) Jul 01 01:44:36 hey, that's pretty cool Jul 01 01:45:15 15 done worldwide so far: http://groups.yahoo.com/group/nslu2-linux/database?method=reportRows&tbl=11 Jul 01 01:45:16 rwhitby-away: probably some EMC regulation Jul 01 01:45:32 mickeyl: Yesterday, before going back to Sharp ROM, I was a time on oz-3.5.2. Jul 01 01:45:51 XorA: wouldn't think so, as all external busses still run at the same speed - it's only the internal core speed which changes Jul 01 01:45:52 mickeyl: The thing is that sysinfo gfx benchmark is sensible better on 3.5.2 than on 3.5.3. Jul 01 01:46:04 mickeyl: Do you think what could cause it? Jul 01 01:46:09 s/thing/know Jul 01 01:46:33 s/think/know :-\ Jul 01 01:46:38 rwhitby-away: in that case to avoid "competing" with another linksys product (which may have been canned anyway) Jul 01 01:47:18 SirFred: no idea frankly. it would be interesting to find out which libqte or libqpe revision changes that Jul 01 01:47:30 we didn't touch the benchmark for sure Jul 01 01:47:39 XorA: yeah, or perhaps we are just pawns in an ingenious marketing plan which intentionally runs it at half speed with an easy fix to get the mid-life publicity of an overclocking hack ... Jul 01 01:47:48 mickeyl: Perhaps it's not a libqte issue. What about kernel? Jul 01 01:48:00 mickeyl: I didn't make the number tests, a pitty. Jul 01 01:48:35 Sirfred: we used kernel 2.4 with OZ 3.5.2 and it feels slower to me. Jul 01 01:48:46 mickeyl: Graphically slower? Jul 01 01:48:47 perhaps it's a matter of preempt Jul 01 01:49:00 Sirfred: yes. the kernel 2.4 framebuffer feels slower Jul 01 01:49:39 while preempt improves the feel of speed, it has some overhead that may shine through in a benchmark Jul 01 01:49:59 mickeyl: For example, dragging a window on the screen. On oz-3.5.2 is smoother, at least on my c760. Jul 01 01:51:10 Sirfred: you could flash 2.6.12 and have a look if it changes your impression Jul 01 01:51:16 1600x1200 looks nice... too bad that it is crt which I have to leave ;( Jul 01 01:51:16 leave the userland as it is Jul 01 01:53:02 mickeyl: Well, perhaps when I return from the dark sharp side. Jul 01 01:54:25 mickeyl: I expect to return more learned (if I return) Jul 01 01:55:30 mickeyl: Anyway, you mean flashing 2.6.12 with a rootfs from oz-3.5.2 ? Jul 01 01:56:16 Sirfred: yep Jul 01 01:56:46 mickeyl: Assuming that touchscreen support is compiled as a module and that modules are on the rootfs image, it would be hard to run the benchmark. Jul 01 02:00:54 Sirfred: touchscreen support is in kernel Jul 01 02:01:15 mickeyl: Bad assumption, so. Jul 01 02:01:24 mickeyl: I will give it a try. Jul 01 02:01:30 yeah. you just need to change tslib.sh Jul 01 02:01:36 or tslib.conf for that matter Jul 01 02:01:41 since we use /dev/sharp_ts on 2.4 Jul 01 02:01:46 and the input system Jul 01 02:01:47 on 2.6 Jul 01 02:02:18 mickeyl: I've sent you a new patch this morning. I found the bug for the hot-rotation. Jul 01 02:02:32 Sirfred: yep, got it. i'll apply it later today Jul 01 02:02:39 mickeyl: Thanks. Jul 01 02:20:10 my first commit... Jul 01 02:21:04 it should be org.openembedded.dev.hrw or org.openembedded.dev.hrw? I commited into first... Jul 01 02:21:37 org.openembedded.dev Jul 01 02:22:29 normally there's no need for a seperate branch unless you have some things that may not be appropriate for mainline Jul 01 02:23:01 ops. into second - org.openembedded.hrw - should I change it? Jul 01 02:23:35 * rwhitby-away wonders how you back out of a commit ... Jul 01 02:23:43 or if I will push change then nothing will broke? Jul 01 02:24:11 nothing will break, but org.openembedded.hrw will exist for evermore after that Jul 01 02:24:14 to be honest, i have no idea. the worst thing that could happen is that the org.openembedded.hrw branch appear Jul 01 02:24:33 it may be the appropriate time to find out how to remove a branch ;) Jul 01 02:24:40 ok I will then look how to remove it Jul 01 02:24:54 hrw|work: one way is to blow away your local db and start again :-) Jul 01 02:25:13 remember to export your keys first Jul 01 02:25:38 rwhitby-away: I have backup of empty db Jul 01 02:25:48 cool Jul 01 02:26:25 but signed gpg and dont have that secret key here Jul 01 02:29:23 uf. managed to get new base with keys Jul 01 02:31:16 pulling Jul 01 02:33:43 arent the committing instructions on wiki wrong? it misses keyword commit Jul 01 02:33:49 yep Jul 01 02:41:24 * RP blames koen Jul 01 02:41:48 how many weeks of blame koen have we got? Jul 01 02:42:57 Sirfred: I suspect 2.6.12 on 3.5.2 will not work very well. The keyboard will give issues for a start :-/ Jul 01 02:44:20 RP: Hmm, that's a problem. Because I will need to change the tslib configuration, as Mickey said. Jul 01 02:45:03 Sirfred: Thinking about it, the keyboard should basically work - just all the special keys won't Jul 01 02:45:12 You might get away with it... Jul 01 02:45:34 RP: Well, I will try. Thanks for the warning. Jul 01 02:46:01 certainly on the console. Without the newer opie keyboard code, I'm not sure what opie itself will do... Jul 01 02:46:45 RP: I expect to have a look today at those calls to TransBitblt. Jul 01 02:47:01 RP: I have setup my sharp rom and only need a decent gdb. Jul 01 02:47:02 Sirfred: I'm eagerly awaiting the results :) Jul 01 02:47:11 excellent :) Jul 01 02:47:22 qte-2.3.10: add improved version of w100 accelleration patch courtesy Manuel Teira Jul 01 02:47:27 RP: I will need your help, sure. Jul 01 02:47:42 RP: I suppose that a register dump on function entering will be useful. Jul 01 02:48:21 Given that TransBitBlt needs two pointers, what is pointing R0 and R1 will give us some information. Jul 01 02:48:29 Sirfred: Correct. And maybe a dump of some of the memory areas those registers point at Jul 01 02:48:36 RP: Yes. Jul 01 02:48:59 Hopefully we can then feed that data to atilib and it will do something... Jul 01 02:49:20 Failing that, we'll have to dump the shared memory segment and maybe the w100 registers Jul 01 02:49:27 RP: I expect that my old sharp toolchain is still lying in my hd. Jul 01 02:50:15 RP: The best way should be breakpoint at QW100Raster<16,0>:blt(), and them, break at the regexp AtiCore* Jul 01 02:50:31 RP: And crossfingers to catch a transparent bitblt. Jul 01 02:50:56 RP: So all the initialization to get a transparent bitblitting should be autocontained in those calls. Jul 01 02:51:10 RP: We will know this evening-night Jul 01 02:51:13 Sirfred: Sounds good. Or just break on transBitBlt itself... Jul 01 02:51:26 RP: Perhaps prior calls to AtiCore functions are needed too. Jul 01 02:51:41 Yes, that would be interesting to see Jul 01 02:52:11 Get a dump of the data to transBitBlt first - I can quickly test that Jul 01 02:52:14 RP: I remember that the bit disabling color comparing was enabled everytime we go into that. Jul 01 02:52:17 See if we have enogh... Jul 01 02:52:41 RP: I have not a driving license for gdb, it will be no painless. Jul 01 02:52:47 ;-) Jul 01 02:52:51 monotone: beginning commit on branch 'org.openembedded.dev.hrw' Jul 01 02:53:02 I'm no expert at it. I seem to have to relearn it each time :) Jul 01 02:53:20 Well, I have to go back to the work I got payed for. Jul 01 02:53:40 hrw|work: why a 'hrw' branch? I thought the convention was either use .dev directly, or use a branch named by distro or new feature if it couldn't go on the mainline? Jul 01 02:54:03 paid, I mena. Jul 01 02:54:17 and mena means mean Jul 01 02:54:20 Sirfred: Annoying, isn't it :) Jul 01 02:54:41 * RP hopes mallum isn't listening :) Jul 01 02:54:49 rwhitby-away: heh.. I always forget that.. sorry - had to much things to do lately so dont remember most of monotone talks Jul 01 02:54:52 RP: He's your boss? Jul 01 02:55:09 RP: Back to this bloody wsdl. Jul 01 02:55:19 Sirfred: yes. ssshhh ;-) Jul 01 02:55:24 RP: ;-) Jul 01 02:55:49 hrw|work: I'm no expert. What's your thoughts on username branches vs feature or distro branches? Jul 01 02:57:20 please let's stick to org.openembedded.dev and nslu for the branches that appear in the official repository. Jul 01 02:57:31 I recreate then Jul 01 02:57:32 feel free to use additional branches in your local monotone sandbox :) Jul 01 02:58:14 we may reconsider things when we have more experience with this thing, but for now i think it's the best way Jul 01 02:58:41 ko Jul 01 02:58:59 OT: viewmtn is nice, but I'd rather have it more like the old bk interface where you could see the last changes Jul 01 03:00:30 mickeyl: if someone has a different branch in their own sandbox, then either (a) it starts with org.openembedded.*, and will appear in the official repo as soon as they sync, or (b) it doesn't start with org,openembedded,* and can cause problems if it ever accidentally gets into the official repo. Jul 01 03:01:43 Has anyone tried to write .bb for the 2-95 toolchain to get rid of the binary toolchain dependency ? Jul 01 03:01:48 morning btw Jul 01 03:02:44 proti: morning Jul 01 03:06:26 I 'like' bugs like #126, #127... Jul 01 03:07:12 *nod* Jul 01 03:07:44 one more reason to differentiate AUTHOR and MAINTAINER Jul 01 03:08:08 and perhaps even s/MAINTAINER/PACKAGER/ Jul 01 03:08:13 to make it clear Jul 01 03:09:53 btw MAINTAINER/PACKAGER - how you see it? Jul 01 03:10:19 see AUTHOR/MAINTAINER/PACKAGER Jul 01 03:10:27 starting with most interest to least interest Jul 01 03:10:43 what's the difference between them? Jul 01 03:10:46 the packager just makes sure the package builds and gets into an ipkg Jul 01 03:10:58 ah Jul 01 03:11:01 the maintainer tries to ensure that the package is actually doing something meaningful Jul 01 03:11:11 the author is ... well... the one who abandonded the program :) Jul 01 03:11:22 that's my nomenclature Jul 01 03:11:49 Could the maintaner & packager not be merged? Jul 01 03:12:20 as the maintainer will need to ensure that it packages if they want it to do something meaningful Jul 01 03:12:32 at the moment, we only have MAINTAINER, but I'm starting to think we should split these. i.e. I'm committed to package many apps, but I rather not MAINTAIN them. I MAINTAIN all of my python packages though. Jul 01 03:13:12 also, users have a different idea of MAINTAINING a software Jul 01 03:13:19 they think that this regards bugs etc. Jul 01 03:13:35 which should really be an AUTHOR thing Jul 01 03:13:48 ok, that makes sense Jul 01 03:14:30 lardman: I packaged some stuff and pushed it without maintainer field Jul 01 03:17:41 We should make sure we explain this to the users then (considering that I was confused too) - to make sure they complain in the right direction ;) Jul 01 03:18:54 and which flags we will add into package? Jul 01 03:19:51 if(empty(MAINTAINER) AND !empty(PACKAGER)) MAINTAINER="noone - we dont want bugreports" Jul 01 03:22:29 what about assigning the first person who files a bug report against an unmaintained package as the maintainer ;) Jul 01 03:23:20 ;) Jul 01 03:23:26 sounds good. if someone reports a bug, he's interested in the package Jul 01 03:23:28 LAST_KNOWN_USER Jul 01 03:23:33 hehe, yeah Jul 01 03:23:44 good point Jul 01 03:24:25 might be better to tell him/her that it's unmaintained & that they should find a maintainer if they want it fixed Jul 01 03:24:50 they'll be motivated, plus it reduces work-load Jul 01 03:25:17 or will say "those OE/OZ guys does not want to fix it.. I dont like them" Jul 01 03:25:32 that'll happen anyway Jul 01 03:26:13 can someone check does 953b08a609919736baecab4a6de1df56164aab3a is commited and synced correctly? Jul 01 03:27:15 urhgs Jul 01 03:27:20 i hate those numbes Jul 01 03:27:24 what did you do? Jul 01 03:27:28 i'll check then Jul 01 03:28:13 monotone: branch 'org.openembedded.dev' is currently merged: Jul 01 03:28:14 953b08a609919736baecab4a6de1df56164aab3a hrw@openembedded.org 2005-07-01T10:24:33 Jul 01 03:28:17 looks good Jul 01 03:28:26 ya, i know i should setup viewmtn here Jul 01 03:28:48 at least i have a server log setup now :) Jul 01 03:28:50 http://monotone.vanille.de/log.spy Jul 01 03:28:58 mickeyl: lzma patch with CRLF now Jul 01 03:29:07 could you rebuild lzma-native now? Jul 01 03:29:17 sure, let me try Jul 01 03:31:53 | In file included from ../../../Common/CommandLineParser.cpp:5: Jul 01 03:31:54 | ../../../Common/CommandLineParser.h:6:27: Common/String.h: Datei oder Verzeichnis nicht gefunden Jul 01 03:31:58 (file not found) Jul 01 03:32:14 patch applied? Jul 01 03:32:21 yes Jul 01 03:32:24 ok Jul 01 03:32:39 lzma-native is tricky package.. it build for me Jul 01 03:33:11 Yes, it works. Updated correctly. Jul 01 03:33:21 ~lart bk once again Jul 01 03:37:42 i am trying to compile 2.6.12 omap osk. when i boot the kernel i get the message IP-Config: Incomplete network configuration information. and NFS mounting does not take place. has anyone faced this problem before. the kernel and the patch work fine when compiled with kegel's cross tools and am getting the problem when i compile using bitbake and openembedded ? Jul 01 03:40:43 I did update the MonotonePhraseBook with the command for updating. Jul 01 03:40:58 time to go back to LCD panel Jul 01 04:06:40 proti: shouldn't your update command say 'org.openembedded.dev'? at least that's the directory I get with the pull Jul 01 04:08:11 here's a tip: say "pull .... org.openembedded.dev openembedded" if you want the created directory to be called just "openembedded". Jul 01 04:08:50 rwhitby: thanks :) Jul 01 04:09:18 Arjan: check www.nslu2-linux.org/Makefile for other tips :-) Jul 01 04:10:17 re Jul 01 04:36:16 Arjan: pull is enough, Once the initial pull has been done. Jul 01 04:50:36 Since the "sudo" package does not have an AUTHOR or MAINTAINER listed, I'll ask here ... Jul 01 04:51:07 Does anyone have any objection to me adding --with-editor=/bin/vi to EXTRA_OECONF ? Jul 01 04:51:36 Currently, it defaults to the location of vi on the build machine, which doesn't make sense for cross-compilation. Busybox has vi as /bin/vi in OE. Jul 01 04:54:34 (you can always override it with an env var on the target device, but it's good to default to something sensible) Jul 01 04:54:43 go for it I think Jul 01 04:59:21 :-) that's better. Now visudo works :-) Jul 01 04:59:57 ok, now to test switching branches from org.openembedded.nslu2-linux to org.openembedded.dev, committing, pushing, then switching back :-) Jul 01 05:01:15 rwhitby: you guys do native builds on slugs - gcc etc built by OE? Jul 01 05:01:32 (cause we said that we would push changes to non nslu2-specific changes asap instead of waiting for an nslu2-linux full propagate). Jul 01 05:02:37 hrw|work: yes. For Unslung, we build a crosstool toolchain outside of OE, and have a native dev environment based around that with packages built from the Optware (formerly known as Unslung packages) build environment. For OpenSlug, we use all the stuff built with OE. Jul 01 05:03:18 rwhitby: could you create task packages which will allow to install build enviroment in easye way? Jul 01 05:03:27 The Unslung native environment is mature (and we have a native feed with things like Perl, Emacs, etc in it) Jul 01 05:03:30 such as task-gcc etc Jul 01 05:03:54 We are just in the middle of working out what is required for a development environment on an OpenSlug slug. Jul 01 05:04:12 and yes, the goal of that is to have a single task ipk which installs it all Jul 01 05:06:35 great Jul 01 05:06:44 ya, that'd be nice Jul 01 05:06:50 OZ users complain that there is no easy way to get native gcc Jul 01 05:07:19 [g2] and NAiL are working on that Jul 01 05:08:21 hi all Jul 01 05:08:34 g'day bluelightning Jul 01 05:08:45 hi rwhitby Jul 01 05:09:28 http://pastebin.com/305864 - my new script for OE Jul 01 05:09:32 lunch time.. Jul 01 05:19:18 my company is using OE for a product. right now, we have a bitkeeper repository with our changes available, but is it possible to do that in a branch on the official monotone server now? Jul 01 05:20:18 the reason that it probably can't be taken in the main branch is that it includes some hacks which aren't useful for other people, but required by our target Jul 01 05:21:01 (for example we aren't using full locales, but having some "dummy-locale" files so we can use translations, but don't require several megabytes per country/language for stuff we never need, like formatting of dates etc.) Jul 01 05:32:44 hi all Jul 01 05:32:58 g'day pb_ Jul 01 05:33:28 tmbinc: the nslu2-linux project is doing a similar thing on the org.openembedded.nslu2-linux branch Jul 01 05:33:48 re Jul 01 05:34:15 tmbinc: we have some nslu2-linux-specific packages, and use distro-specific modifications to common packages. Jul 01 05:42:19 ok, that was a bit more obtuse than expected. http://ewi546.ewi.utwente.nl/tmp/viewmtn/revision.psp?id=40ab23b1b8e8e478cc075a3795e981566f038498 Jul 01 05:42:37 mt heads -b org.openembedded.dev Jul 01 05:43:01 mt update 953b08a609919736baecab4a6de1df56164aab3a -b org.openembedded.dev Jul 01 05:43:12 mt commit -b org.openembedded.dev -m "sudo: Added '--with-vi=/bin/vi' to EXTRA_OECONF to mat\ Jul 01 05:43:13 ch the default location of vi in busybox." Jul 01 05:43:23 mt push monotone.vanille.de org.openembedded Jul 01 05:44:01 mt heads -b org.openembedded.nslu2-linux Jul 01 05:44:09 mt update bbe3a6dc7e44dab7715ed5caa3acbbbe308a7f69 -b org.openembedded.nslu2-linux Jul 01 05:44:35 mt propagate org.openembedded.dev org.openembedded.nslu2-linux Jul 01 05:44:58 hm that sounds good Jul 01 05:45:01 That's what you need to do to commit a change on a different branch, and then merge it back into your local branch. Jul 01 05:45:44 it would be nice if manifest would be disabled on viewmtn.. Jul 01 05:47:20 nslu2 is mips based? Jul 01 05:47:33 ixp420 Jul 01 05:47:48 www.nslu2-linux.org has all the info ... Jul 01 05:48:17 oh ok.. i remember, meshcube was mips, mixed them up Jul 01 05:55:15 pb_: glibc-2.3.5+cvs20050627 builds for arm? Jul 01 06:01:23 hi zecke Jul 01 06:02:56 hey Jul 01 06:14:29 hrw|work: I havent been able to Jul 01 06:14:36 TheCount: hey Jul 01 06:25:39 zecke: hey Jul 01 06:35:27 hmm Jul 01 06:35:28 hrw|work: yes Jul 01 06:35:32 thx Jul 01 06:35:35 viewmtn has not exactly many instructions for how to set it up Jul 01 06:35:39 NOTE: package glibc-2.3.5+cvs20050627-r0: task do_compile: completed Jul 01 06:35:46 its just compiled ;) Jul 01 06:35:59 very good Jul 01 06:36:59 but next OZ/Fam etc will use 2.3.2+20040726 one probably.. Jul 01 06:37:25 why? Jul 01 06:37:48 any special reason not to upgrade? :) Jul 01 06:38:05 mickeyl: you are RM - you decide ;) Jul 01 06:54:43 k, viewmtn now available @ monotone.vanille.de/viewmtn Jul 01 06:55:45