**** BEGIN LOGGING AT Tue Jan 24 03:00:00 2006 Jan 24 03:25:53 morning all Jan 24 03:26:56 hi Liam Jan 24 03:27:52 hi Marcin Jan 24 03:28:42 hows going tosa work? Jan 24 03:29:24 hrw|work: not really started yet. :( I've had a lot of support worki come in recently and it's really boged me down Jan 24 03:30:01 hrw|work: I should with any luck get something started next week. Jan 24 03:30:42 just asking ;) Jan 24 03:31:00 hrw|work: how your work going ? Jan 24 03:31:38 hi Liam Jan 24 03:31:48 hey Richard Jan 24 03:32:02 RP I'm booked into Novotel now Jan 24 03:32:20 lrg|home: quite well Jan 24 03:32:21 hi lrg Jan 24 03:32:29 hey pb_ Jan 24 03:32:54 lrg|home: Excellent. I'm quite looking forward to fosdem :) Jan 24 03:33:30 RP: same here, I'm arriving Thursday evening and meeting up with Dirk on the Friday Jan 24 03:33:53 lrg|home: I arrive midday on the Friday Jan 24 03:34:18 RP: excellent, we can all go out drinking on Friday night :) Jan 24 03:36:04 lrg|home: Sounds like a plan :) Jan 24 03:37:32 dont get too drunk Jan 24 03:38:43 heh, not me. Jan 24 03:39:30 hrw|work: My boss is likely to be around ;-) Jan 24 04:06:51 morning Jan 24 04:09:24 hey XorA Jan 24 04:15:15 The monotone update yesterday ended with 529 missing files. I can either use monotone drop or monotone revert --missing. Which one should I rather use? Jan 24 04:17:03 use revert Jan 24 04:17:12 morning, dyoung Jan 24 04:18:51 NAiL: Thank you. I will do that. Jan 24 04:19:45 morning Jan 24 04:20:10 hi CoreDump|home Jan 24 04:20:19 morning and l8er Jan 24 04:23:33 hi CoreDump|home, XorA Jan 24 04:25:00 ~curse libpcre for shitty utf-8 support Jan 24 04:25:03 May you be reincarnated as a Windows XP administrator, libpcre for shitty utf-8 support ! Jan 24 04:30:15 I want to try gtk on the framebuffer directly -- is there a gtk package available for this, or should I configure manually? Jan 24 04:33:14 koobla: I dont think there is a bb for this Jan 24 04:35:36 ok, then I will go ahead and hack what I got :) Jan 24 04:42:17 03coredump 07org.oe.dev * reffe6a45... 10/packages/altboot/ (altboot.bb files/altboot.func files/init.altboot): Jan 24 04:42:18 altboot: Jan 24 04:42:18 - Reworked moving old mountpoints into the new rootfs Jan 24 04:42:18 - Optimized pivot_root'ing Jan 24 04:43:14 CoreDump|home: does whole altboot should go into branch? Jan 24 04:43:41 hmm, it wouldn't hurt Jan 24 04:52:10 Once we have arm kexec functionality under 2.6, a lot of the altboot code might become unneccessary... Jan 24 04:53:13 RP: only on 2.6 machines.. Jan 24 04:54:38 hrw|work: Yes, collie would still need it Jan 24 04:54:46 RP: poodle, tosa too Jan 24 04:55:14 RP: kexec? what does it do? Jan 24 04:56:06 CoreDump|home: It loads a new kernel Jan 24 04:56:15 sweet Jan 24 04:56:40 CoreDump|home: I have a kexec patch a user provided to test... Jan 24 04:56:40 I don't see how that makes booting from other devices easier tho Jan 24 04:56:55 RP: still compiling .dev here Jan 24 04:56:57 CoreDump|home: kexec /media/card/zImage.bin Jan 24 04:57:12 huh Jan 24 04:57:27 CoreDump|home: Change the kernel commandline to say root=/dev/mmcblk0p1 Jan 24 04:57:29 probably silly question -> is anyone planning to be at fosdem ? Jan 24 04:57:29 you can change the kernel in a _running_ system? Jan 24 04:57:46 CoreDump|home: It launches a new kernel Jan 24 04:57:50 CoreDump|home: yes Jan 24 04:57:59 holy cow Jan 24 04:58:01 The new kernel replaced the old one in memory and runs... Jan 24 04:58:18 with the system beeing in which state? Jan 24 04:58:31 "newly booted" I assume? Jan 24 04:58:53 Ifaistos: yeah, I think numerous members of Team OE will be there Jan 24 04:59:04 ie: trash all running processes and run INIT again? Jan 24 04:59:19 CoreDump|home: Yes, it will do a complete init from scratch Jan 24 04:59:27 hmmm i was thinking of going also Jan 24 05:00:07 very nice but kinda overkill =) altboot could play lilo in that case. Select kernel on boot-up, set kernel CMDLINE for kexec etc Jan 24 05:00:38 * CoreDump|home shrugs we will see =) Jan 24 05:00:53 CoreDump|home: Yes. In some ways its overkill, in others its quite useful. Both types of operation have their uses :) Jan 24 05:01:01 indeed Jan 24 05:01:16 CoreDump|home: I just wanted you to be aware of it as it might make 2.6 support easier :) Jan 24 05:01:29 Ifaistos: überhackers mickeyl and zecke will be there, at least, as will I Jan 24 05:01:48 easier? lol It means users can dual-boot between 2.4, 2.6 and Sharp. That's brilliant Jan 24 05:02:22 * mithro_ is trying to find a cheap way to get from Rome to Brussels :P Jan 24 05:02:39 mithro: hey Jan 24 05:03:07 hey zecke Jan 24 05:03:14 Ifaistos: also others such as lrg|home, do13, most of openedhand and myself Jan 24 05:03:22 * mithro was violently ill last night :/ Jan 24 05:03:29 mithro: well the tunnel is up buit had it has no ip address associated Jan 24 05:03:43 I think i need to "squiz" fosdem in.... Jan 24 05:03:46 :) Jan 24 05:04:14 CoreDump|home: Its possible 2.6 is good enough on collie to let you boot an initial kernel to kexec something else. I know poodle 2.6 and tosa 2.6 are certainly capable of that Jan 24 05:04:15 zecke: the tunnel device on the host shouldn't have an address associated with it Jan 24 05:04:26 anyone giving presentation ? Jan 24 05:04:41 mithro: well /sbin/ifconfig eth0 up fails in the uml Jan 24 05:04:58 hrm, what does it say? Jan 24 05:05:01 Ifaistos: lrg|home on ASoC last I heard Jan 24 05:05:19 RP: that's where altboot fits in nicely. You can script up anything for a "normal" boot. Jan 24 05:06:00 CoreDump|home: I've never actually tried altboot :) Jan 24 05:06:11 TUNSETIFF failed, errno = 16 Jan 24 05:06:58 It replaces /sbin/INIT and offers you various boot-time options. Each option launches a script that can do basically anything you want. Jan 24 05:07:07 you tried restarting the linux? Jan 24 05:07:33 mithro: more than once Jan 24 05:08:17 hrm.... Jan 24 05:08:43 can you stop it for a sec? Jan 24 05:11:08 CoreDump|home: I'll have to experiment when I resurect the work I did on the ipaq hx2750 as it sounds useful there :) Jan 24 05:11:53 heh won't work on iPAQ, sorry. You sort-of need a keyboard to navigate the menu. It doesn't support arrow-keys Jan 24 05:13:00 CoreDump|home: Ah :) Jan 24 05:13:01 hrm, i'm looking at 173 EUR :/ Jan 24 05:17:33 why could a package be compiled, but not added to an image (if included in the image DEPENDS and RDEPENDS) Jan 24 05:19:29 katossi_uni: you need it in IPKG_INSTALL Jan 24 05:21:07 it is Jan 24 05:21:23 that's why I don't understand nothing Jan 24 05:21:24 welp, train is hela expensive Jan 24 05:23:53 * mithro ponders what to do... Jan 24 05:24:24 mithro: re Jan 24 05:24:24 does FOSDEM cost anything? I couldn't find any prices anywhere Jan 24 05:24:38 zecke: give it a go now Jan 24 05:24:56 looks better again Jan 24 05:25:15 don't resize your windows :P Jan 24 05:26:22 mithro: well... it runs in a screen and it didn't work among restarts Jan 24 05:27:07 ? Jan 24 05:27:19 so if you restart it now it won't work? Jan 24 05:27:54 mithro: it didn't work Jan 24 05:29:54 hrm... that sucks Jan 24 05:39:51 mithro: look for eurolines if you can stand to be in the bus for so long Jan 24 05:40:09 mithro: or search for budget flights Jan 24 05:40:43 currently searching for budget files Jan 24 05:40:52 mithro: maybe Ryan Air or a lookalike has something for you Jan 24 05:41:52 ryan air will cost me 160 Eur :/ Jan 24 05:42:18 virgin-express 176.35 EUR Jan 24 05:43:09 if i fly in on the 23rd it's a bit cheaper Jan 24 05:43:17 mithro: Eurolines is 127 EUR one way Jan 24 05:43:31 ouch Jan 24 05:43:37 mithro: but their price depend on time of stay, departure etc Jan 24 05:43:46 http://www.eurolines.com Jan 24 05:44:09 mithro: when I was still in school and didn't have any money, then I hitchhiked the autobahn. Absolutely cheap :-) Jan 24 05:44:31 It took me 4 DM from Frankfurt to Berlin. The 4 DM (2 EUR) was for eat+drink :-) Jan 24 05:44:49 schurig: did you walk? Jan 24 05:44:50 but it could take from 5 to 12 hours Jan 24 05:45:07 zecke: hitchhike ("trampen" auf deutsch) Jan 24 05:45:28 schurig: I know people that even earned some money on their way Jan 24 05:45:38 ("pih ficken" auf deutsch) Jan 24 05:45:41 poh even Jan 24 05:45:56 lol zecke Jan 24 05:46:12 If I fly in on the 23rd it'll cost me 107 EUR Jan 24 05:46:22 mithro: http://www.viavai.it/ Jan 24 05:46:27 (with ryan air) Jan 24 05:46:47 schurig: what is that? Jan 24 05:47:28 136.35 with virgin-express Jan 24 05:47:43 mithro: an organized car hitchhiking. Drivers register there that they go from A to B. And if you want to ride with one, you ask if they have something and pay a fee to them, then they get you the address/phone # of the driver Jan 24 05:48:39 i think my best bet is to try and fly in on the 23rd Jan 24 05:48:53 anyway I've got to run! Jan 24 05:48:54 see ya Jan 24 05:52:53 gm Jan 24 05:55:12 mehhh ERROR: dependency ${BOOTSTRAP_EXTRA_DEPENDS} (for task-hentges-bootstrap) not satisfied. Guess I _do_ have to rework that after all Jan 24 05:56:12 CoreDump|home: Just set BOOTSTRAP_EXTRA_DEPENDS="" Jan 24 05:56:17 or remove it Jan 24 05:57:53 yeah, BOOTSTRAP_EXTRA_DEPENDS ?= "" should do the trick if the VAR is emty beforehand right? Jan 24 05:58:05 CoreDump|home: yes Jan 24 05:58:08 ty Jan 24 05:58:56 CoreDump|home: but nothing sets it anymore (unless you have some local machine.conf files) and its honestly not needed if you inherit the image bbclass Jan 24 05:59:56 my problem is that my .bb's are in a CVS and they have to be usable on branch =) And I'd rather _not_ make a branch in my own CVS heh Jan 24 06:00:22 NOTE: package task-hentges-bootstrap-1.0: completed Jan 24 06:00:26 =) Jan 24 06:00:28 CoreDump|home: Fair enough :) Jan 24 06:01:31 I'm going to flash a .dev opie-image now. Let's see how 2.6 holds up Jan 24 06:01:49 * RP hides Jan 24 06:02:16 heh nahh Jan 24 06:02:45 anything I should know about? Any noteworthy bugs / problems? Jan 24 06:03:22 CoreDump|home: This is akita? There shouldn't be anything major missing. Perhaps just some polish Jan 24 06:03:42 I'm not sure of the status of akita's fstab... Jan 24 06:03:43 great =) Jan 24 06:04:26 * CoreDump|home is great at polishing bootstrap stuff Jan 24 06:05:53 flashing away Jan 24 06:06:16 CoreDump|home: did you noticed something more to polish recently? Jan 24 06:07:17 hrw|work: umm maybe turn off the logmessages from /etc/init.d/opie. Don't remember anything beside that ATM Jan 24 06:07:27 and well, Jan 24 06:07:50 GPE's bootsplash looks sweet, but INIT5 make a mess of it. Looks terrible Jan 24 06:08:04 gpe bootsplash + elpp == argh Jan 24 06:08:07 maybe one could do a "clear" in S00_blahh in rc5.d Jan 24 06:08:16 ~lart qpdf2 Jan 24 06:08:17 * ibot stuffs qpdf2 into a shiny new tin can and vacuum seals it Jan 24 06:08:35 17M archive with all .o etc files Jan 24 06:08:50 * CoreDump|home is getting _tons_ of "Empty flash at blahhh ends at blahh" messages Jan 24 06:09:10 CoreDump|home: They're "normal" for akita. Jan 24 06:09:24 I hope they do not indicate a problem? Jan 24 06:09:25 CoreDump|home: you need DISTRO_TYPE="release" then Jan 24 06:10:09 hrw|work: nahh, I want to see kmesg right now =) It's a .dev image after all Jan 24 06:10:10 CoreDump|home: No problem I'm aware of Jan 24 06:10:40 RP: ok. It would suck to have the flash killed due to some annyoing bug lol Jan 24 06:11:18 hmm Opie apears to run faster w/ 2.6 Jan 24 06:12:55 CoreDump|home: The flash in akita is different to any previously in Zaurus models. I borrowed my boss' device to write the driver and those warning can be safely ignored as far as I can see. Its mostly a standard mtd nand driver so if there is a bug, its in the mainline mtd code ;-) Jan 24 06:13:09 CoreDump|home: That'll be PREEMPT Jan 24 06:13:13 RP: =) Jan 24 06:15:18 the delay for "key-repeat" should be raised Jan 24 06:16:10 CoreDump|home: find best value with kbd_rate so it will be raised Jan 24 06:16:19 ok Jan 24 06:16:38 CoreDump|home: known issue. You can use console-tools to change it but a kernel patch would be the best solution Jan 24 06:16:50 right Jan 24 06:16:59 looking very good Jan 24 06:17:02 (a kernel patch to allow keyboard drivers to set their own keyboard repeat rates) Jan 24 06:17:05 CF auto-mounts Jan 24 06:17:21 SD doesn't auto-mount but can be mounted menually Jan 24 06:17:32 CoreDump|home: SD should automount too Jan 24 06:17:48 CoreDump|home: Probably the akita fstab Jan 24 06:18:13 right Jan 24 06:18:23 its still using mmcda* Jan 24 06:18:58 CoreDump|home: See the spitz one for a suitable 2.6 entry Jan 24 06:18:59 udev can generate symlinks for mmcda anyway... Jan 24 06:19:02 no its not lol Jan 24 06:19:41 hrw|work: I'd like to think long and hard before we made it do that though... Jan 24 06:20:36 I would prefer no not doing it Jan 24 06:21:00 hrw|work: me too. Especially if we split the machine types into 2.4 and 2.6 versions... Jan 24 06:22:05 RP: fstab is fine. The partitioning of my card was at fault. 2.6 doesn't ship with the small script that auto-detects the partition Jan 24 06:22:56 CoreDump|home: 2.6 uses a udev automount script which could probably get adjusted to work. I was also looking into pmount Jan 24 06:23:42 CoreDump|home: My todo list includes this, unless someone beats me too it :) Jan 24 06:23:54 =) Jan 24 06:24:16 is http://bugs.openembedded.org/ down? Jan 24 06:24:40 it is Jan 24 06:24:48 CoreDump|home: There's a bit of rewriting to be done for the move to pcmciautils (network devce handling) which will be done from scripts via udev as well Jan 24 06:26:32 RP: what exactly needs adjusting? My CF WLAN card just went online w/p problems Jan 24 06:26:43 CoreDump|home: At the moment it uses pcmcia-cs Jan 24 06:27:08 and that will be replaced with pcmcia-utils? Jan 24 06:27:18 CoreDump|home: yes Jan 24 06:27:25 I'll have a look Jan 24 06:27:56 * RP -> lunch Jan 24 06:28:24 tries to set up USB networking Jan 24 06:33:13 CoreDump|home: http://hrw.one.pl/tmp/usb-gadget.sh - use opie-sh Jan 24 06:38:32 CoreDump|home: if you can test it under opie/2.6 then it would be great Jan 24 06:38:51 I'm looking at it now Jan 24 06:39:18 opie-sh still needs to compile here tho Jan 24 06:40:32 it does not do any error checking Jan 24 06:41:19 zecke, you about? Jan 24 06:41:38 yes Jan 24 06:41:53 I assume holger should have r/w access to subverion repo? Jan 24 06:42:02 schurig? Jan 24 06:42:05 yeah Jan 24 06:42:11 yes Jan 24 06:42:16 he created an account Jan 24 06:42:17 ok Jan 24 06:42:18 zecke: yes? Jan 24 06:42:26 schurig: you want to have write access? Jan 24 06:42:37 zecke: I haven't send the mail yet, but yes. Jan 24 06:42:38 schurig: I'm still svk smerging the repository Jan 24 06:43:07 Crofton: your repository is not setup in the usual SVN way, with trunk/ and branches/. Doing branches the SVN way is therefore not possible. Jan 24 06:43:15 hmmm Jan 24 06:43:22 that is zecke issue :) Jan 24 06:43:32 zecke: your repository is not setup in the usual SVN way, with trunk/ and branches/. Doing branches the SVN way is therefore not possible. Jan 24 06:43:33 :-) Jan 24 06:43:38 he should be able to move things around when he is done building it Jan 24 06:44:00 schurig: heh? Jan 24 06:44:15 schurig: trunk/ branches/ tags/ are just directories Jan 24 06:44:24 svn mkdir /branches Jan 24 06:44:36 svn cp org.oe.dev /branches/schurig-branch Jan 24 06:44:45 zecke: right. But all the source is in the root. So mkdir trunk/ and move all into it Jan 24 06:45:11 zecke: otherwise, when you have 10 branches and you do the intial checkout as descripted, you get all 10 branches as well. That's not common. Jan 24 06:45:33 schurig: well I could stop the merging Jan 24 06:45:46 schurig: wait Jan 24 06:45:47 just move things about later Jan 24 06:45:50 zecke: http://svnbook.red-bean.com/nightly/en/svn.branchmerge.using.html Jan 24 06:45:53 schurig: we have /org.openembedded.dev Jan 24 06:46:10 schurig: I know svn cp, not even the svn main server uses trunk/ tags/... Jan 24 06:46:43 zecke: we should have org.openembedded.dev/trunk/conf/bitbake.conf (for example). And then later org.openembedded.dev/branches/dev.slug/conf/bitbake.conf if one makes this branch. Jan 24 06:47:00 schurig: whatever (besser wisser)... Jan 24 06:47:04 and in org.openembedded.dev/ there should not be any other file/directory besides the branch/ and trunk/ directory Jan 24 06:47:06 schurig: you know that svn cp is O(1)? Jan 24 06:47:19 schurig: we could even create your 'schurig' view Jan 24 06:47:28 schurig: so the dirs get ordered the way you want... Jan 24 06:47:56 schurig, you should have write access now Jan 24 06:48:03 schurig: I do not want trunk/ branch/ tags/ under org.oe.dev Jan 24 06:48:11 schurig: this wouldn't match what we do now... Jan 24 06:48:21 schurig: .dev is the development branch... Jan 24 06:48:36 schurig: what you could call trunk if you like to HEAD, or foo, or even org.oe.dev ;) Jan 24 06:48:39 zecke: this has nothing to do with besserwisser or O(1). When you have "normal" (HEAD) files and directories in org.openembedded.dev/ AND you have the org.openembedded.dev/branches/ directories, then you can't just do an initial checkout of HEAD, you'll get all branches/ and all tags/. That's highly inconvenient. Jan 24 06:48:55 zecke: if you evaluate an SCM tool, then you should stick to it's customary use. Jan 24 06:49:07 zecke: look at the pictures in http://svnbook.red-bean.com/nightly/en/svn.branchmerge.using.html Jan 24 06:49:09 schurig: well svn co http://foo/org.openembedded.dev . Jan 24 06:49:23 schurig: I may place dirs where I want to... Jan 24 06:49:29 zecke: and where do you put tags in? Jan 24 06:49:30 schurig: org.openembedded.dev is trunk Jan 24 06:49:58 schurig: OE's development doesn't fit too well into your branch/ tags/ trunk kind of thinking Jan 24 06:50:01 zecke: in https://ossie-dev.mprg.org/repos/oe/tags? Jan 24 06:50:29 zecke: *IF* we ever switch (assuming people vote for it), then it might be nice to have tags, wouldn't it? Jan 24 06:50:44 and branches in https://ossie-dev.mprg.org/repos/oe/? Jan 24 06:50:47 schurig: wtf... I just smerging all 4000 revs Jan 24 06:50:55 schurig: look at the current rev number... Jan 24 06:51:04 that would work, but it's quite unusual. Most SVN repositories are laid out different. Jan 24 06:51:04 schurig: don't annoy me now, please don't do it Jan 24 06:51:21 schurig: the trunk/ branch/ tags/ thinking does not manch OE style of development Jan 24 06:51:25 zecke: don't get so easily annoyed Jan 24 06:51:37 I would recommend patience Jan 24 06:51:46 schurig: is nslu, dreambox just a OE branch? Jan 24 06:51:54 most of the svn organization is social, not required Jan 24 06:52:01 schurig: and is the main OE development in /trunk? I think not Jan 24 06:52:31 schurig: we would have official/org.oe.dev official/org.nslu-linux official/de.mn... Jan 24 06:52:43 schurig: as these are all official HEADs for their development Jan 24 06:52:58 schurig: well you could place these dir under /trunk Jan 24 06:53:05 CoreDump|home: One thing to note - usb client doesn't work with windows on the pxa270 (yet) Jan 24 06:53:31 schurig: one point of the trial is to experiment, coming with the bible and saying that a svn tree needs to be /trunk /tags /branches... Jan 24 06:53:34 RP: thank good I don't do windows heh heh Jan 24 06:53:41 *shakes head* Jan 24 06:54:08 you have 1200 revs to go before you have to solve this :) Jan 24 06:54:18 zecke: everything in branch/ is also a head. Yes, you're right, it boils down to the view if they are all equal brothers or if one is master of the universe and the other siblings. Jan 24 06:54:21 CoreDump|home: I have patches and some clues on how to make it work, next time I have some time to spend on it... Jan 24 06:54:34 CoreDump|home: My todo list is unmanagable atm :-/ Jan 24 06:54:41 =) Jan 24 06:55:08 zecke: however, even in monotone I thought that org.openembedded.dev is the master, the head where everything culminates. Forgive if I was wrong :-) Jan 24 06:55:09 schurig: at first I synced all org.oe.dev dirs to / which was bad Jan 24 06:55:20 schurig: with /org.oe.dev we have all freedom to organize... Jan 24 06:55:36 schurig: with distributed scm's you don't have a master Jan 24 06:55:56 schurig: it is social agreement as well. The main OE folks push to org.oe.dev Jan 24 06:56:05 schurig: the nslu people to org.nslu... Jan 24 06:56:11 zecke: wrong. Even with Bitbake we had a master. The master is the thing that is documented in our Wiki where people make their initial checkout. Jan 24 06:56:12 schurig: and once in a while we synchronized Jan 24 06:56:27 schurig: Bitbake? Jan 24 06:56:29 zecke: if I commit something and it doesn't and in this master, then it is not "world-wide" published. Jan 24 06:56:41 the key thing here is how good svn/svk is at synching across different branches Jan 24 06:57:02 which is a little different from how I think most people use svn Jan 24 06:57:04 zecke: so even our way of a distributed repository has a master, by way of the documentation (and also by the way we make snapshots and publish them on the website) Jan 24 06:57:25 schurig: well switch to the nslu perspective Jan 24 06:57:54 schurig: occasionally they get the bugs from OE Jan 24 06:57:59 schurig: and in their wiki... Jan 24 06:58:29 schurig: we have three subprojects with active development Jan 24 06:58:39 schurig: they are all official, they would be all in 'trunk' Jan 24 06:58:53 schurig: now each of them can go into a stablisation phase Jan 24 06:58:54 zecke: and, if nslu2 people modify, say, samba, do the merge that back in org.openembedded.dev ? Jan 24 06:59:07 schurig: this wehre one could use the branches Jan 24 06:59:14 schurig: now people can create personal branches as well Jan 24 06:59:51 zecke: you can use branch/nslu2 for stabilization, too. This is what happens in KDE's SVN repository, e.g. with branches/KDE/3.x/ Jan 24 07:01:16 schurig: I think we agree on that Jan 24 07:01:34 org.oe.dev/{trunk,tags,branches} looks wrong to me Jan 24 07:01:53 /trunk/org.oe as well Jan 24 07:02:05 this is why I decided to postpone discussion about the structure to later Jan 24 07:02:36 zecke: we just disagree on the point if we have a "Prima inter pares" or not. Once this is settled (if ever) the resulting directory structure is logical Jan 24 07:03:01 is a logical result of the decision Jan 24 07:03:12 schurig: wait another two days after I have replayed all revs... Jan 24 07:03:26 schurig: then we can do tree copying Jan 24 07:03:32 horse cart :) Jan 24 07:04:32 Crofton: I don't get that :) Jan 24 07:04:47 Crofton: me neither Jan 24 07:04:51 putting the cart before the horse Jan 24 07:05:16 my way of saying things have to be done in order :) Jan 24 07:05:19 Crofton: Is that the meaning of "the tail wiggles with the dog" ??? Jan 24 07:05:26 something like that Jan 24 07:05:36 the horse pulls thcart, it can't push the cart Jan 24 07:05:53 Crofton: I'm still not sure how I can apply this to the current situation Jan 24 07:06:14 well, you have to complete the repo, before you can try different strcutures Jan 24 07:06:42 and since cp's and mv's are lightweight in svn, plenty of arrangements may be tried Jan 24 07:07:04 zecke: I came acros this branch issue because I wanted to convert http://oe.handhelds.org/cgi-bin/moin.cgi/SvnScmTrial in a way so that we have two parts in it, an "SVN Phrasebook" and an "SVK Phrasebook". Now I won't do this, until I see what you have in petto. Jan 24 07:08:41 schurig: what stops you? Jan 24 07:08:54 schurig: you can just create tags/ and branches and trunk/ now if you want to Jan 24 07:09:10 schurig: and after the smerge you can svn mv it... Jan 24 07:09:19 zecke: WHERE should I create them? Jan 24 07:09:37 schurig: oe/trunk oe/tags/ Jan 24 07:09:45 schurig: we now have oe/org.openembedded.dev Jan 24 07:09:50 schurig: so with svn mkdir... Jan 24 07:10:25 zecke: ok, then I have to svn mv all things around. But if I got you right, then you want to make changes in this SVN repository during the next two days? Or maybe I didn't get you right? Jan 24 07:10:57 zecke: also, you just said to me that https://ossie-dev.mprg.org/repos/oe/org.openembedded.dev/trunk/ and https://ossie-dev.mprg.org/repos/oe/org.openembedded.dev/branches/ doesn't sound right to you. If other agree, then maybe my idea is nonsense after all. Jan 24 07:11:12 schurig: one dir? Jan 24 07:11:18 in this case maybe a https://ossie-dev.mprg.org/repos/oe/nslu2.dev/ dir should be made Jan 24 07:11:19 all things == one dir Jan 24 07:11:40 schurig: then we can move around once more Jan 24 07:11:44 and as long as this isn't really known, there's no point in documenting this and writing a phrasebook Jan 24 07:11:46 schurig: this is the idea of the trial Jan 24 07:11:56 schurig: we will throw it away afterwards.. Jan 24 07:13:27 ~seen RP Jan 24 07:13:32 rp is currently on #openzaurus #gpe #handhelds.org #oe. Has said a total of 1231 messages. Is idling for 18m 58s, last said: 'CoreDump|home: My todo list is unmanagable atm :-/'. Jan 24 07:13:49 hi schurig Jan 24 07:14:05 busybox's route is beginning to piss me off Jan 24 07:14:12 RP: I'm using the pxa-cpufreq patch from your repository and found a fix for it Jan 24 07:14:46 RP: in drivers/pcmcia/pxa2xx_base.c line 144 you have a warning, wondering if this is right Jan 24 07:15:27 schurig: That warning has always been there - I honestly don't know if it applies or not Jan 24 07:15:31 RP: if you have the powersave governor (with the 4 PXA frequencies), then the memory clock is always 99532, in this case you woudn't need this Jan 24 07:15:32 schurig: Fixes are welcome Jan 24 07:15:57 RP: bit if you use performance, you'll have 6 frequencies, and the memory clock varies. Jan 24 07:16:17 03rwhitby 07org.oe.dev * r2e1b97f9... 10/ (4 files in 2 dirs): ftpd-topfield: Updated to 0.6.3 Jan 24 07:16:30 RP: so the #warning can go away. However, the fix now is pxa2xx_pcmcia_set_mcxx(skt, freqs->new) is wrong, it needs to be pxa2xx_pcmcia_set_mcxx(skt, freqs->new /10) Jan 24 07:16:49 If I want to set EXTRA_OECONF for all arm-arches, is there a simple way to do it? (both be and le) Jan 24 07:16:50 otherwise MCIOx get's programmed so slow that you get DMA starvation, visible on the PXA framebuffer Jan 24 07:17:20 the same some lines below, it must be pxa2xx_pcmcia_set_mcxx(skt, freqs->new / 10) Jan 24 07:17:39 schurig: That looks like a good find, thanks. I'll add that to the patch Jan 24 07:18:17 schurig: I didn't write the patch and haven't looked too closely at it yet but hopefully once I do. I'll probably try for mainline with it... Jan 24 07:18:40 RP: I'm using this patch since some weeks, with a userspace app that changes frequency Jan 24 07:19:06 RP: to gether with core voltage modification via a callback I can save a substantial amount of mW :-) Jan 24 07:19:08 morning Jan 24 07:19:54 schurig: Is your core voltage changing patch suitable for other machines? I might be interested in that... Jan 24 07:20:19 schurig: I assume you didn't find any other problems with the cpufreq patch? Jan 24 07:20:34 RP: of course not. You need a GPIO somewhere (e.g. PXA, CPLD, AC97 codec) and this is highly machine specific. Jan 24 07:20:56 one of our hardware can only select between two voltages, the other between 4 voltages ... Jan 24 07:21:13 schurig: I mean is it clean enough to be easily altered for other hardware :) Jan 24 07:21:35 RP: moment, I post this to pastebin.ca ... Jan 24 07:22:05 http://pastebin.ca/38353 Jan 24 07:22:32 03nail 07org.oe.dev * r8de532d6... 10/conf/distro/ (debianslug.conf openslug.conf): debianslug/openslug.conf: Fix breakage caused by _EXTRA_RDEPENDS. Jan 24 07:22:35 RP: so, it's quite simple Jan 24 07:22:36 03nail 07org.oe.dev * r50d95cd7... 10/packages/meta/slugos-packages.bb: slugos-packages: Remove memtester from uclibc packages Jan 24 07:23:27 RP: oh, and you need a "cpufreq_register_notifier(&rt3000_cpufreq_notifier_block, CPUFREQ_TRANSITION_NOTIFIER);" somewhere Jan 24 07:23:45 hey schurig, been a while Jan 24 07:24:03 anyone kick openembedded.org yet? Jan 24 07:24:16 schurig: It is a little simpler than I was expecting :). The zaurii have an i2c voltage controller which I was thinking this might be similar to Jan 24 07:24:49 ooo, i2c my friend Jan 24 07:24:55 emte: yes. I'm seldom in IRC nowadays. Jan 24 07:25:24 emte: and days after the monotone switched I stopped contributing to OE (it was soooo slow) Jan 24 07:25:42 yeah :( Jan 24 07:25:46 emte: now if OE switches away from OE I have a bunch of things to contribute Jan 24 07:26:04 schurig: please watch the scm issue and vote :) Jan 24 07:26:05 switches away from MT, i meant Jan 24 07:26:06 schurig, you didnt try using kergoth's svk version? Jan 24 07:26:51 emte: I just saw that there is a vote today, when I opened akregator (where I saw the RSS feed of the OE wiki). I haven't made much besides discussing with zecke about the SVN directory layout. Jan 24 07:27:04 hg has alomost finished most of the issues that were missing before :) Jan 24 07:27:06 emte: I actually want to test pure SVN, SVN+SVK and GIT. Jan 24 07:27:35 i only read all the bad things about GIT in #mercurial Jan 24 07:27:36 emte: months ago I tested "hg" and liked it, but at that time there was no good support for branches Jan 24 07:27:46 emte: hehe :-) Jan 24 07:28:16