**** BEGIN LOGGING AT Thu Jan 05 02:59:59 2006 Jan 05 03:00:16 morning all Jan 05 03:00:18 It'd be more of an SD-gadget Jan 05 03:00:18 lol Jan 05 03:00:21 I don't have a USB port Jan 05 03:00:26 morning Liam Jan 05 03:00:54 do13: any joy with suspend/resume ? Jan 05 03:01:12 df00z: usb gadget is 'any linux device which can be connected as usb client - for example PDA' Jan 05 03:01:46 lrg: Sorry actually I can't test, because my resume is broken Jan 05 03:01:53 Right Jan 05 03:01:56 this is for my PDA, though Jan 05 03:02:01 it doesnt have a USB host Jan 05 03:02:16 what i meant was, use the SD storage driver transparently Jan 05 03:02:34 do13: np, I'll look at the warm reset today. Jan 05 03:02:43 with a hardware device that converts the signals to something a CF storage or USB storage device would understand Jan 05 03:03:01 lrg: I switched to RP's charging stuff and now I have to reorganize suspend / resume Jan 05 03:03:10 I doubt theres such a device though Jan 05 03:04:01 do13: np Jan 05 03:04:09 df00z: your pda has usbclient port so it is usb gadget Jan 05 03:05:45 hm Jan 05 03:05:57 df00z: but you need linux 2.6 for it Jan 05 03:06:02 so with g_file_storage, my PDA's client can connect to another client device and it'd function as a USB mass storage> Jan 05 03:06:07 Oh. i have 2.4 Jan 05 03:06:10 :( Jan 05 03:06:40 df00z: with g_file_storage your PDA (client) can connect to host (desktop) and it'd function as a USB mass storage Jan 05 03:06:57 oh Jan 05 03:06:59 i dont care about that Jan 05 03:07:11 df00z: under 2.4 there is storage_fd which do similar things but its sharp crap thing which I ignore Jan 05 03:07:15 Ah Jan 05 03:07:23 I've used that, I thinlk Jan 05 03:07:36 I was looking for a way to add a hard drive to my zaurus Jan 05 03:07:40 using the SD port Jan 05 03:07:45 my CF slot is taken Jan 05 03:08:13 ah.. so no way Jan 05 03:08:33 Right. Unless I made a device that used the SD port, and emulated an SD card Jan 05 03:08:48 while translating the signals to something a CF storage device can use Jan 05 03:08:51 then I'd use a microdrive Jan 05 03:08:55 that I think is feasable Jan 05 03:09:47 I'd just have to look up how SD cards work, how they're addressed...serial..parallel..and then how CF storage cards work Jan 05 03:09:55 fsck.. last time when I build kernel I removed something and now usb gadget does not work.. no cardreader too ;( Jan 05 03:11:29 yeah, an sd-to-cf (or indeed sd-to-usb) storage adapter should certainly be possible. That'd be an interesting project. Jan 05 03:11:44 Yeah :) Jan 05 03:12:07 I might know enough to do it, but i'm not sure where I could buy the headers and stuff Jan 05 03:12:36 maybe I could use an old broken SD card and solder wires to it and then use a breadboard, haha Jan 05 03:12:51 heh Jan 05 03:15:48 hrw: thanks for ipkg.conf Jan 05 03:17:06 alan|home: I think on windows you might be able to use syslinux to boot it from a DOS floppy or eltorito cdrom Jan 05 03:17:34 Actually..i wonder if you could market something like that Jan 05 03:17:59 Say, a package...SD card and a tool that a CF card goes in and fits into your pocket Jan 05 03:18:07 the SD card and device could communicate wirelessly Jan 05 03:18:18 and the other device could be powered by a couple double As or something Jan 05 03:18:34 market it like ADD STORAGE TO YOUR DIGITICAL CAMERA EASILY with a 4GB microdrive Jan 05 03:19:15 is there a problem with microperl Jan 05 03:19:27 with envirments variables? Jan 05 03:29:43 hrw|work: morning Jan 05 03:30:25 anyone use miniperl? microperl? Jan 05 03:35:35 greentux_alt: query Jan 05 03:40:59 <[lala]> it seems to me, that not all changes for do_stage have been reverted - glib-2.0-native_2.6.5.bb still has the autotools_stage_all statement present Jan 05 03:41:29 <[lala]> that still causing atk to fail in configure Jan 05 03:42:35 <[lala]> can someone please fix that? Jan 05 03:43:12 <[lala]> see bug #570 Jan 05 03:43:42 re Jan 05 03:46:37 <[lala]> have added an additional comment there Jan 05 03:49:32 Ugh Jan 05 03:49:33 I give up Jan 05 03:49:35 SHFS sucks too Jan 05 03:50:07 For some reason it disconnects when the PDA's CPU/bandwidth is under heavy use Jan 05 03:50:25 i wonder if the SHFS portion of lufs would compile, maybe it's fixed Jan 05 03:50:26 [lala]: Ah, I thought that had been reverted - I'll fix that... Jan 05 03:51:20 lrg: hey... micro recording and headphone playing ist nice now Jan 05 03:51:33 <[lala]> RP: thx Jan 05 03:51:35 lrg: but using headset is not usable :) Jan 05 03:52:25 lrg: headset works now too... diif mux to line 1... :) Jan 05 03:52:46 lrg: but there is a long delay Jan 05 03:53:26 greentux_alt: are you doing a arecord | aplay ? Jan 05 03:54:28 lrg: after setting "headset" you have te reswitch the diff mux to line2 and back... some kind of reinit i think Jan 05 03:54:34 lrg: yes record -> play Jan 05 03:54:46 lrg: arecord | aplayl Jan 05 03:55:22 greentux_alt: the record -> play has a delay because the audio is being piped from 1 process to another Jan 05 03:56:03 greentux_alt: I'll check the re-init today. I'm getting my headset soon Jan 05 03:57:46 [lala]: correction pushed Jan 05 03:58:10 <[lala]> RP: cool, i'll try to sync then :) Jan 05 04:00:11 ok mail sent to RMK - will look what he reply Jan 05 04:01:47 <[lala]> RP: hmm, atk has no direct dependency on glib-2.0-native, so it doesn't rebuild the pkg automatically Jan 05 04:01:55 <[lala]> RP: is that behaviour intended? Jan 05 04:02:26 atk needs glib-2.0-native? Jan 05 04:02:52 <[lala]> yes, it wants to call some gettext configure binary Jan 05 04:03:10 <[lala]> thats the reason atk was broken Jan 05 04:03:37 brb Jan 05 04:03:44 <[lala]> the gettext stuff the configure calls is taken from staging/i686 Jan 05 04:05:26 <[lala]> dunno if that's what atk is supposed to do though ;-) Jan 05 04:05:29 [lala]: Hmm. I don't know much about gettext. This has worked in the past so why would it stop now? Or was it working in the past just good luck? Jan 05 04:06:06 <[lala]> well, i think that while building gpe-image there must be an earlier pkg which has the glib-2.0-native dependency then Jan 05 04:06:34 <[lala]> hmm Jan 05 04:07:33 <[lala]> ah, i see Jan 05 04:07:43 <[lala]> RP: glib-2.0 has the dependency Jan 05 04:07:48 <[lala]> its all right Jan 05 04:08:04 Ah, that makes sense Jan 05 04:08:32 <[lala]> it's a problem of transient dependendy ;-) Jan 05 04:09:23 RP: so audio is working fine.. so i think the job is done Jan 05 04:09:36 hey all .. Jan 05 04:09:38 <[lala]> i mean a depends on b, b depends on c ... that stuff Jan 05 04:09:45 greentux_alt: excellent :) Jan 05 04:10:00 i am first time working on mips .. now the glibc breaks against mtx-1 Jan 05 04:10:07 greentux_alt: just a few little things still todo. :) Jan 05 04:10:28 any guru around on mips Jan 05 04:10:50 i found mails talking about that issue .. my today`s goal would get a working bootstrap Jan 05 04:19:55 lrg: great, i will try a voip call as soon as lala has build the gpe image... Jan 05 04:20:14 greentux_alt: cool. Jan 05 04:26:51 france: hey george Jan 05 04:27:28 RP: can git do SASL? Jan 05 04:27:31 zecke: hi Jan 05 04:27:50 france: from what I heard svn should cope with any number of groups Jan 05 04:27:59 france: SASL support is missing completely Jan 05 04:28:06 zecke: very nice than the fix it. I hope. Jan 05 04:28:51 zecke: Not that I'm aware of... Jan 05 04:30:10 zecke: I can install svn on h7 later today. we will see. there are only a handfull of us that are in a lot of groups. Jan 05 04:30:27 zecke: me, jamey, andy, brian, etc... (maybe nelson) Jan 05 04:30:40 zecke: we can try to break it Jan 05 04:31:17 france: svn uses a Apache library to abstract from the Operating System Jan 05 04:31:30 france: and all group handling code is inside this lib Jan 05 04:32:36 zecke: so it depends on our version of apache and what autoconf picked for us. Jan 05 04:33:13 france: I will have to check it. They have an apr copy in the subversion tree as well Jan 05 04:33:39 zecke: I will also need a list of ports for the firewall Jan 05 04:33:50 zecke: while you are digging about. Jan 05 04:34:11 france: for now: ssh like -d:ext with cvs Jan 05 04:34:25 france: for later I will send you a list of possible ports Jan 05 04:34:42 nods Jan 05 04:35:08 france: but we have plenty of choiches. There is a module for apache (HTTP/HTTPS) Jan 05 04:35:25 france: and a subversion protocol (we would need this for SASL) Jan 05 04:35:28 i have problem with microperl and env variables... could anyone help me please Jan 05 04:35:56 RP: You able to help with a few usbnet issues? Jan 05 04:36:00 zecke: yes, that is a way we could work around the sasl issue Jan 05 04:37:22 france: HTTPS would do as well? Jan 05 04:37:31 but lets work on the group issue first, I did a quick check and I belong to 97 groups on h7 Jan 05 04:37:39 NAbyss: #openzaurus Jan 05 04:38:16 zecke: it would Jan 05 04:39:48 zecke: git is ssh only for the kind of access we want so I'd suspect most of the group handling is done by glibc Jan 05 04:40:28 ~lart samba Jan 05 04:40:28 * ibot shoves a crumpet down samba's throat, happy now?! Huh? Want some JAM with that? Jan 05 04:43:54 hrw|work: You'll note rmk's reply to the mmc post on lakml? :) Jan 05 04:44:35 yes Jan 05 04:45:04 RP: and that patch was for <2.6.15 Jan 05 04:45:26 I did wonder what that magic number meant :) Jan 05 04:46:17 * zecke is trying to convert the monotone OE.db to svn Jan 05 04:47:26 morning all Jan 05 04:47:29 zecke: you are kde user.. does kate can show list of functions in loaded file so I could navigate or do I need kdevelop for it? Jan 05 04:48:29 hrw|work: I have not seen it Jan 05 04:48:37 hrw|work: kate can do code completion and code folding Jan 05 04:49:25 I normally use gvim but today samba decided to not like me so I have to use fish:// and kde has it done better Jan 05 04:49:49 hrw|work: I use either xemacs or (g)vim Jan 05 04:54:02 I once tried xemacs Jan 05 05:01:16 RP: I can send you a OE git tree this evening or a short note on how to use tailor Jan 05 05:01:52 france: there is svnsync but I do not know how well/secure it performs Jan 05 05:02:03 zecke: both might be useful if possible please? :) Jan 05 05:02:26 zecke: I have a VM running reading to setup a git repository into... Jan 05 05:09:12 RP: can one pull using http? Jan 05 05:09:34 with git that is Jan 05 05:17:25 zecke: it can always be put in a stunnel, etc... Jan 05 05:19:04 when i use: microperl -wle 'print `echo \$USER`' ->>>>>>>a blank line is printed Jan 05 05:19:32 but when i use: perl -wle 'print `echo \$USER`' ->>>>>>>the user name is printed! Jan 05 05:20:13 the strange thing when use microperl -wle 'print `pwd`'.. the output is the correct working directory Jan 05 05:29:52 how to cross compile perl to armv5b-softfloat.. i have the toolchain Jan 05 05:32:59 linnuxxy: create machine with target_arch=armeb-linux and build Jan 05 05:37:09 i had downloaded the source of perl from the cpan.org... how to create a target_arch Jan 05 05:37:45 linnuxxy: you are using OE to do builds or just sit here because of something? Jan 05 05:37:55 :D Jan 05 05:38:46 im building from the source using crosstool Jan 05 05:39:11 linnuxxy: so I cannot help - never used crosstool. Jan 05 05:39:52 linnuxxy: in OE its a matter of correct machine config (for armeb look at *slug/nslu* one) and 'bitbake perl' Jan 05 05:39:53 ok..ok ... where to find oe... ur http://oe.handhelds.org/downloads.php is empty! Jan 05 05:40:19 linnuxxy: OE -> Wiki -> GettingStarted Jan 05 05:40:29 ok thank u Jan 05 05:48:49 heya folks, whoever it was: thank you for pointing me to duplicate bugs ?31 and ?345. Jan 05 05:50:17 lkcl: np Jan 05 05:50:40 only thing... the pcre one doesn't appear to want to work... hmmm *thinks*... Jan 05 05:51:04 let me think about this - of course it's got autotools_stage_all beforehand... Jan 05 05:51:49 let's see if putting the sed before the autotools_stage_all does the trick.. YEP Jan 05 05:52:16 i'll do an updated patch... Jan 05 05:53:14 zecke: There is a git-daemon which supports pull only Jan 05 05:55:04 zecke: I think you can also use http and rsync as well Jan 05 05:57:46 yaay! me amd64 sys is building konqueror-embedded. _that_'s something i like to see. Jan 05 06:11:13 re Jan 05 06:12:40 rehi zecke Jan 05 06:13:06 is there a way to download oe other that monotone? Jan 05 06:13:37 RP: a question about SDIO... is the support of SDIO a question of the SDIO controller in the Z or is it a NDA/license problem of the card-manufactor? Jan 05 06:14:22 greentux_alt: Its a documentation issue - we don't have specs for any of the SDIO devices Jan 05 06:14:49 I'm not sure if the SDIO standard is open spec of not either. I think bits might be public but perhaps not all? Jan 05 06:14:53 RP: ok, if i have a well documented device, is the hostpart a problem? Jan 05 06:15:40 RP: assumed we produce the device, so we can document it very well... is it possible to use it with linux... ? :) Jan 05 06:15:53 greentux_alt: The PXA manual should give details of the hardware itself Jan 05 06:16:25 greentux_alt: SDIO support would need to be added to the kernel but that should be possible if there were a device with documentation available, yes Jan 05 06:16:27 RP: ^with device i mean a "card" Jan 05 06:17:45 greentux_alt: The only thing I'd worry about is whether the SD association would like you making the device documentation available? Jan 05 06:18:01 but I don't know what your people's agreements with them say :) Jan 05 06:18:31 RP: that should be possible. NP...ok. good to know. Jan 05 06:18:57 greentux_alt: For what its worth, I'd really like to see SDIO support in Linux Jan 05 06:19:38 RP: i think its not possible to have gpl suppport for sdio in the near future... Jan 05 06:20:44 greentux_alt: If documentation is available, surely a gpl driver is perfectly possible? Jan 05 06:21:20 the SD card on the HTC himalaya and blueangel devices work. Jan 05 06:21:35 RP: for the card, but i think the host part is only possible with documentation you can get after signing a NDA. Jan 05 06:21:44 lkcl: only storage... not sdio Jan 05 06:22:01 there was an article on linuxdevices.com about the issues involved with SDIO - they're being pretty stupid. Jan 05 06:22:03 and the sd storage driver based on a nda... :) Jan 05 06:22:08 ah, yes. Jan 05 06:22:09 read that yes. Jan 05 06:22:18 well, that's what reverse-engineering is for :) Jan 05 06:22:34 greentux_alt: Documentation of the SDIO controller on the PXA is available. The tricky bit of it might be the SDIO protocol itself as that will be the part that needs a licence Jan 05 06:23:39 RP: :) fine. perhaps you will get a sdio job in the future Jan 05 06:24:06 greentux_alt: but no-one with an SDIO job can implement it in kernel :-( Jan 05 06:24:27 XorA: This would be done in such a way as I wasn't signing any NDAs Jan 05 06:24:30 XorA: no only as patch... Jan 05 06:25:18 RP: the problem comes when working that you are also covered by the companies NDA's Jan 05 06:25:47 so i siad the code cant be gpl... Jan 05 06:26:23 This depends whether greentux_alt was giving me information about how to use his companies devices or information on the actualy SDIO specs... Jan 05 06:26:56 XorA: Surely the interface can be documented by someone who hasn't signed the NDA, yet has seen the docs.. Jan 05 06:27:06 yes, if i have a nda and the specs and a well documented sdio device, RP can write me the code... Jan 05 06:27:18 greentux_alt: its the seeing the specs without an NDA thats the problem Jan 05 06:27:53 erm sorry that was meant for NAbyss Jan 05 06:28:17 greentux_alt: If we can find a way to get me enough information without seeing the specs, no NDA is needed and the driver can be gpl which would be the preferred solution Jan 05 06:28:49 If I'm under NDA and can't release the code, you end up with a binary only driver which are a massive pain Jan 05 06:28:51 someone persuade c-guys to release their driver accidently adding all debug symbols :-) Jan 05 06:28:59 XorA: All you have to do is find someone who isn't 18 (or of legal age to sign a contract in the relevant jurisdiction) to 'sign' the NDA.. easier said than done though. And, as usual.. IANAL etc etc. Jan 05 06:29:42 NAbyss: but then greentux_alt's company gets sued by the SD assocation for breaching their NDA... Jan 05 06:30:29 lunch Jan 05 06:30:52 RP: I didn't mean through a company.. as an individual... Jan 05 06:30:58 That's about the only loophole I can think o Jan 05 06:30:58 f Jan 05 06:31:19 NAbyss: The company would end up in court for failing to protect the IP though Jan 05 06:31:20 and is further complicated by the fact a GPL driver will get jumped on by DMCA and ESCD in court :-( Jan 05 06:31:58 As I see it, greentux_alt can release docmentation of their hardware without NDA? If so, then the question is whether there's enough information out there to put together a working driver based on that Jan 05 06:32:45 RP: if he can release his docs, then packet sniffing the SD bus will work wonders as you'll know what is SD protocol and what is his hardwares stuff Jan 05 06:33:02 XorA: Ah, yeah, you've got those laws over there.. Jan 05 06:33:06 RP: did this before for cd-headunit -> multichanger traffic Jan 05 06:33:17 NAbyss: where are you? Jan 05 06:33:21 XorA: Australia Jan 05 06:33:34 XorA: Assuming there's a driver for some other system you mean? Jan 05 06:33:41 RP: yes Jan 05 06:34:17 RP: anyway for that special project it is not very important to have a gpl driver (but it would be the best way i agree). Jan 05 06:34:58 RP: in the moment i have the question: is it possible to support a sdio card or not. i learned: it is possible with NDA and perhaps possible without NDA. Jan 05 06:35:17 greentux_alt: correct Jan 05 06:35:21 greentux_alt: My only concern is if I have to sign NDAs I'll never be able to touch gpl SDIO code Jan 05 06:36:45 RP: understand that. and if we have to to a decisision i have to ask my boss for details :) I think we will find the right solution. Jan 05 06:40:07 greentux_alt: ok. Asking my boss about this, he's "concerned" about the legal side of it all so we need to think carefully about this Jan 05 06:41:10 RP: yes we should prefer the legal way with the best solution for the community. :) Jan 05 06:50:34 hmm darcs seems faster than svn Jan 05 06:51:52 http://www.sandisk.com/Assets/File/OEM/Manuals/SD_SDIO_specsv1.pdf seems to be the open source SDIO spec Jan 05 06:52:20 and we have the hardware documentation from the pxa to know how to physically control the bus.... Jan 05 06:55:15 RP: looks good. ok will discuss that wirh our hardware develeopers. Jan 05 06:56:59 greentux_alt: Is lacks info on what the SDIO protocol commands and i/o space actually look like. Info is missing but I'm not sure how much... Jan 05 07:08:39 hi mickeyl Jan 05 07:08:57 hh mickeyl Jan 05 07:09:46 mickeyl: hey Jan 05 07:10:19 koen|away: I do not think we have decided on any SCM beside monotone for OE yet Jan 05 07:11:10 zecke: darcs isn't working out then? Jan 05 07:11:35 RP: well it can add files faster than svn ;) Jan 05 07:11:42 RP: I'm watching the output of tailor Jan 05 07:11:55 ah, right Jan 05 07:12:02 you're converting monotone -> darcs? Jan 05 07:12:18 RP: mt -> svn, mt -> darcs and once cogito compiled mt -> git Jan 05 07:12:46 RP: the good thing with tailor is. it looks like it could convert incrementally Jan 05 07:12:48 anyone having ideas on why my cvs-kernel fails to compile with builtin ASIC3 MMC : http://pastebin.com/491714 ? Jan 05 07:13:12 03rpurdie 07org.oe.dev * r731be5b7... 10/packages/glib-2.0/glib-2.0-native_2.6.5.bb: glib-native-2.6.5: Revert autotools_stage_all change. Jan 05 07:14:28 zecke: That would be handy as we could in theory share any scm we choose in other forms as well (one way) Jan 05 07:14:50 theturtle: that "In function `$a':" looks not good - toolchain problem? Jan 05 07:15:45 RP: right. Or if we use darcs we could use git as backend as well Jan 05 07:15:50 The $a is an arm mapping symbol - corrupts output but can be ignored. Jan 05 07:15:51 (at least pull from git) Jan 05 07:16:03 It looks like your kernel isn't building in all the symbols it needs Jan 05 07:17:14 zecke: true, but we are in this mess because no one could reinstate the cvs mirror Jan 05 07:17:25 hi Jan 05 07:18:17 zecke: I've been trying for *months* to get kergoth and mickeyl to say "yes, koen can work on the cvs module" Jan 05 07:19:04 koen: Do we have a list on hh.org where project leaders can be identified? I'm not sure if I am the one to obey Jan 05 07:19:14 s/obey/pester/ Jan 05 07:19:14 http://bugs.openembedded.org/show_bug.cgi?id=33 Jan 05 07:19:14 heh Jan 05 07:19:21 updated patch to put the sed hack in before the autotools_blah_blah Jan 05 07:19:22 stuff in do_stage(). Jan 05 07:19:22 mickeyl: admin.handhelds.org which is down ;) Jan 05 07:19:31 yes, he's absolutely right: it does need to go in do_stage(). i Jan 05 07:19:31 haven't tried at the end of do_compile(). Jan 05 07:19:34 mickeyl: well neth Jan 05 07:19:34 hrw|work & RP : thanks, i'll check my toolchain :/ Jan 05 07:19:36 ehm, Jan 05 07:19:49 neither you or kergoth gave any reaction at all Jan 05 07:20:25 koen: yeah, because i'm pretty sure I'm not one of the project leaders in the terms of the hh.org administrative :D Jan 05 07:20:41 koen: reinstantating the cvs mirror would be a good thing for sure. Jan 05 07:20:46 i think i always said that Jan 05 07:21:04 hell, i'm not even an opie project leader Jan 05 07:21:05 heh Jan 05 07:21:06 :D Jan 05 07:21:22 We'll see what zecke's experiments turn up Jan 05 07:21:29 yep Jan 05 07:22:06 * zecke is not near a project leader as well ;) Jan 05 07:22:09 mickeyl: anyway your voice was enough for france to add me to proj_oe group on hh.org Jan 05 07:22:13 I'm still not convinced that changing to another scm (how bad monotone may seem) is a magic bullet Jan 05 07:22:37 grass is always greener on the other side of the fence Jan 05 07:22:41 koen: definately not. but if we can win pb_ back we should try it Jan 05 07:22:52 zecke: that's for sure Jan 05 07:22:59 koen: if the result is: hey monotone is better than anything else Jan 05 07:23:06 koen: he simply has to cope with that fact Jan 05 07:23:26 http://www.theinquirer.net/?article=28709 Jan 05 07:24:59 I think svn+svk could do the job for most OE use cases Jan 05 07:25:05 zecke: heh Jan 05 07:25:16 pb__: hi Jan 05 07:25:25 hi zecke Jan 05 07:25:29 zecke: I'm a bit hesitant for stuff that requires ssh logins Jan 05 07:26:29 you guys familiar with trac web interface for svn? (It doesn't help the current problem, but is cool anyway) Jan 05 07:26:33 koen: well it is a proven authentication framework ;) Jan 05 07:26:42 Crofton: yes it is nice. We use it at opensync.org Jan 05 07:26:52 zecke: without admin.hh.org it's close to useless Jan 05 07:29:14 i would like to wait until 0.26 is ready and then do a roundup with svk,mercurial, and darcs again. Jan 05 07:29:23 (monotone 0.26, that is) Jan 05 07:29:29 no git? Jan 05 07:29:39 RP: go away you stink ;) Jan 05 07:29:45 zecke: monotone proved that people don't read docs (see the recent dissaprove fiasco), so it doesn't matter to what we switch, people will mess it up anyway Jan 05 07:29:45 oh yes, git as well. Jan 05 07:30:18 ideally we'd use something that trac can understand Jan 05 07:30:19 koen: that is for sure. Again I like monotone Jan 05 07:30:30 koen: darcs or svn Jan 05 07:30:34 I wish the whiners would just pay for bk licenses for all :) Jan 05 07:30:57 heh Jan 05 07:31:22 I have a monotone db with a private branch that is a few weeks old Jan 05 07:31:40 will I be able to rebuild oe than copy my private bracnh into new db? Jan 05 07:31:49 once things settle down Jan 05 07:31:54 heh.. bitkeeper.. citool/revtool was nice Jan 05 07:31:59 as for 'isv branches', we could import those, migrate and send the result back Jan 05 07:32:19 RP: my list of things I'd like to clear up is a) *.conf issue + subgroup for machine maybe, b) bootstrapping strategy (like reenoo proposed in a response to my proposal months ago), c) staging, d) SCM. Jan 05 07:32:24 ordered by priority Jan 05 07:32:42 from high to low :) Jan 05 07:32:59 mickeyl: machine+submachine in a) and task-(sth1|sth2) in b)? Jan 05 07:33:04 mickeyl: let us use parallelism. SCM does not depend on a to c Jan 05 07:33:08 hrw|work: yes Jan 05 07:33:11 mickeyl: so I can prepare test drives Jan 05 07:33:17 mickeyl: We really need to decide if the zaurus machines should be split into 2.4 and 2.6 versions. My conclusion after the last set of discussions was yes but I need to talk to you about that Jan 05 07:33:19 zecke: sure, scm is orthogonal Jan 05 07:33:53 mickeyl: e) sort out bogus MAINTAINER fields Jan 05 07:33:58 koen: thats right Jan 05 07:33:59 RP, mickeyl: will we drop 2.4 c7x0/cxx00? Jan 05 07:34:00 tailor is now at importing osso stuff Jan 05 07:34:28 hrw|work: c7x0, yes, cxx00 not for now by 2.6 becomes default IMO Jan 05 07:34:29 RP: initially i had hoped that this was nothing to decide because 2.4 wouldn't be interesting at all anymore. Alas, it didn't work out fast enough ;) Jan 05 07:34:56 mickeyl: I'm tempted to do a 'oe-new' branch and import every single file after running oe-lint or something Jan 05 07:35:10 mickeyl: Its moving at a better pace than it ever has though :) Jan 05 07:35:24 RP: cxx00/2.4 will live in .oz354fam083 branch - we can drop it from .dev as noone maintain 2.4-crapix Jan 05 07:35:26 koen: sounds like a deal, but we would need to add a lot of criterias Jan 05 07:35:31 RP: for sure Jan 05 07:35:33 There are several nasty search and replaces I've like to do. CVSDATE -> SCMDATE for example Jan 05 07:35:46 RP: SRCDATE Jan 05 07:36:01 and I'm $^*&#$#&# annoyed by broken hand-crafted staging which I can't touch because reenoo will start FUDing again Jan 05 07:36:15 koen: and clean SECTION situation... Jan 05 07:36:25 net/network/networking for example.... Jan 05 07:36:58 RP: hrw has a point here. We can remove 2.4 support for C7x0 and cxx00 in .dev asap. We have it in .branch. Jan 05 07:37:05 mickeyl: will we split opie/applications to opie/(applications|network|something)? Jan 05 07:37:12 koen: If current staging is broken, please fix them and state its a fix. rene can't argue with that. Jan 05 07:37:27 RP: he can and will Jan 05 07:37:34 mickeyl: I'd like the kernels to stay if possible but the actual machines can die Jan 05 07:37:39 mickeyl: its simple - if we dont want to maintain it then better drop it if there is better way Jan 05 07:37:48 after calling his bluff on familiar-dev about branches he moved to annoying OE Jan 05 07:37:49 hrw|work: i don't think it would buy us anything except a little clarity. honestly, I don't think Opie is going anywhere substantial beyond its current state Jan 05 07:37:56 koen: You have my support on that Jan 05 07:38:04 RP: fair enough Jan 05 07:38:13 koen: for what that's worth ;-) Jan 05 07:38:16 mickeyl: thats true too Jan 05 07:38:33 RP: I'm staying back from touching .dev for a few days/weeks Jan 05 07:39:25 btw - there is one annoying thing - each time when we release oz/fam we change something with OE repo... Jan 05 07:39:42 Given we all have ideas for cleanup here, perhaps we should have a cleanup session on .dev and accept that we might break a few things in the interests of a better future... Jan 05 07:40:13 RP: that's my opinion as well Jan 05 07:41:01 RP: full ACK. we will try to do a smooth transition of course, but in my opinion we just can't afford branching a third branch off. we don't have the manpower to do that. in the end the branches would diverge too much and then we have a situation worse than now. Jan 05 07:41:38 we can do a tag and warn people that temporary slight breakage my be ahead Jan 05 07:41:56 mickeyl: My thoughts exactly. The two branches we have are more than our manpower. A tag sounds good Jan 05 07:42:10 Lets have a discussion on oe@ and list the things we're going to do Jan 05 07:42:19 OE-january-2006-not-so-broken ;) Jan 05 07:42:22 heh Jan 05 07:42:52 The SRCDATE/SCMDATE change will need a new bitbake version :-/ Jan 05 07:42:54 RP: agreed. I promise to participate while I'm here (leaving on sunday for 10 days on Lanzarote *yay!*) Jan 05 07:43:08 mickeyl: bastard ;) Jan 05 07:43:11 hehe Jan 05 07:43:37 RP: right Jan 05 07:43:48 mickeyl: Even just some acks/naks to suggestions is probably all we need to proceed as it shows we have a concensus on how to proceed with changes Jan 05 07:43:58 * koen gets reminded to make a bitbake snapshot as well Jan 05 07:44:22 *nod* Jan 05 07:46:11 * mickeyl looks at his TODO and sighs Jan 05 07:46:33 STAGING_BINDIR is something I want to fix as well. Its being totally abused, particularly by native packages Jan 05 07:46:41 * hrw|work dont even want to create todo list... Jan 05 07:46:58 * RP created one recently and was scared by it Jan 05 07:47:14 hrw: is there a chance i could talk you into taking the wheel for 3.5.4 ? it looks i'm not able to focus on it as much as I'd like to Jan 05 07:47:20 * koen continues to ignore his TODO list Jan 05 07:47:29 zecke: Sometime, I'd like to talk to you about adding something to bitbake that can work out a depends from a rdepends Jan 05 07:48:07 zecke: Only when we have something that can do this can we properly solve the depends/rdepends mess that exists at the moment Jan 05 07:48:13 RP: hehe I have been thinking of that as well Jan 05 07:48:37 I wrote something to start doing this but it performance was truely dreadful Jan 05 07:49:01 RP: on the 'bloat' issue: we should be able to rm $WORKDIR after populating staging with packages Jan 05 07:49:25 mickeyl: can you atleast build/release it? my homebuildmachine would upload it for eons.. Jan 05 07:49:28 koen: as long as that can be disabled, I agree Jan 05 07:49:39 that means fixing a couple of packages which rely on paths into $WORKDIR but it would be a change for the good. Jan 05 07:49:51 koen: after the comments about qemu, I'm not so concerned about the bloat as I was Jan 05 07:49:54 koen: now we can too - as long we do not build glib2 related stuff Jan 05 07:50:58 hrw|work: that should be fixed after that libtool change Jan 05 07:51:05 zecke: The problem I found in doing this is you have lots of interations over the data store for the information in PACKAGES Jan 05 07:51:08 koen: nice Jan 05 07:51:43 koen: We should also address the issues multimachine bbclass highlights... Jan 05 07:51:59 RP: and make it default IMO Jan 05 07:52:05 hrw|work: I can get you a build machine if you need Jan 05 07:52:24 koen: Default for the distros is fine with me Jan 05 07:52:29 hrw|work: ok, lets do it like that. I build images + world and copy them to ewi in a secret directory. You handle the testing - pester people to test it for the machines you don't have - and write the announcement. Jan 05 07:53:42 mickeyl: ok. then 3.5.4.1 for 2.6.15 kernel machines (if RP update kernel in .oz354fam083 branch) after some time probably Jan 05 07:53:56 hrw|work: righto Jan 05 07:54:13 mickeyl: I think that 3.5.4.x subreleases (feed from 3.5.4) would be good way for image fixes Jan 05 07:54:16 mickeyl: you now have a login on ewi, same passwd as the merlin monotone account Jan 05 07:54:31 koen: ah cool. thanks Jan 05 07:54:39 koen: user is mickeyl? Jan 05 07:54:51 mickeyl: yes Jan 05 07:55:47 who will be the brave soul to announce the breakage? Jan 05 07:56:26 koen: go ahead with it ;P Jan 05 07:56:33 so the plan is to allow me to upgrade the branch after release to support the 2.6 kernel? (this is fine with me) Jan 05 07:56:52 sounds like a plan Jan 05 07:56:57 RP: yes this would be best Jan 05 07:57:05 RP: when we tag .oz354fam083 with openzaurus-3.5.4 Jan 05 07:57:37 * koen composes mail to oe@ Jan 05 07:57:41 RP: .dev builds are .dev builds. if users have to get something officially then it has to be from .oz354fam083 branch Jan 05 07:58:16 if XYZ does not exist in .oz354fam083 then it does not exist for OZ/FAM users Jan 05 07:58:27 thats my point of view Jan 05 07:59:23 hrw|work: I understand that. I'm just asking if I get permission to write to the branch and make those changes? :) Jan 05 08:00:33 RP: if it's just kernel-related (kernel, udev, modutils) you have my blessing Jan 05 08:00:34 RP: if we wont release cxx00/2.6 to users then we do not get it tested in many strange ways. Jan 05 08:01:16 RP: and to get it we need you to update it in branch - 2.6/Z is your baby:) Jan 05 08:03:41 hrw|work, RP, mickeyl: don't forget to ACK the parts of my mail you agree with Jan 05 08:04:08 sure Jan 05 08:04:15 RP: but I fear we need a complete new data model for bitbake Jan 05 08:04:19 koen: zaurus-clamshell-2.6, wifi module splitup (can't remember if this is in) and fstab might have to be touched to make current 2.6 work in the branch Jan 05 08:04:40 RP: that counts as kernel-related to me :) Jan 05 08:05:43 zecke: I was thinking of caching the PACKAGES data to fix the DEPENDS issue for now but yes, the data model is screwed :-/ Jan 05 08:06:14 zecke: In future, I think bitbake might be bettter off just calculating dependencies globally and dropping the rest of the data Jan 05 08:06:23 if we can do that somehow Jan 05 08:06:38 RP: to some degree we do that already Jan 05 08:06:44 koen: ok, I think we can work something out here :) Jan 05 08:06:47 RP: we just remember where we can find the file again Jan 05 08:07:09 zecke: Perhaps that was why this was as slow... Jan 05 08:08:03 RP: generate cache with 2 files per recipe: 1 contain all which contain now, 2 contain only DEPENDS - so next attempt read only 2 and selected 1s Jan 05 08:08:20 morning kergoth Jan 05 08:08:25 kergoth: congrats on the new job Jan 05 08:08:28 hey Jan 05 08:08:29 thanks Jan 05 08:08:43 hi kergoth, pb__ Jan 05 08:09:01 I don't understand, if i compile mmc & mmc_asic3 as a module, my kernel compiles fine but if i build them into the kernel, i get the following errors : http://pastebin.com/491714 Jan 05 08:09:06 kergoth: congrats and I hope you will not get annoyed by it Jan 05 08:09:44 theturtle: Some module with those symbols in isn't being compiled into the kernel Jan 05 08:10:28 kergoth: what/where you work now? Jan 05 08:10:33 zecke: hehe, you and me both Jan 05 08:10:50 hrw|work: c++ development on land warrior (google it) Jan 05 08:10:51 mail sent Jan 05 08:12:22 kergoth: sounds good Jan 05 08:13:31 RP : any idea on how i can find the missing modules to include ? Jan 05 08:14:47 <[lala]> RP: i cannot fetch matchbox-wm-0.9.5+cvs via svn from svn.o-hand.com - any idea why? Jan 05 08:15:13 you can start ACKing now Jan 05 08:15:21 [lala]: Will try it here... Jan 05 08:16:38 [lala]: It works here... Jan 05 08:17:37 ooooh Jan 05 08:17:48 new lego mindstorms with bluetooth Jan 05 08:19:09 * theturtle imagines himself controling mindstorms with his ipaq... 8-) Jan 05 08:19:28 theturtle: the uni here has been doing it for the past few years Jan 05 08:21:19 mindstorms bluetooth where? Jan 05 08:21:20 nice :) Jan 05 08:21:27 here we are playing with gameboys Jan 05 08:21:28 I could hook that to me trainsets Jan 05 08:21:33 XorA: http://www.lego.com/eng/info/default.asp?page=pressdetail&contentid=17278&countrycode=2057&yearcode=&archive=false Jan 05 08:27:41 koen: replied and acked (listed a few more proposals as well) Jan 05 08:28:03 RP: thanks Jan 05 08:28:49 03tmbinc 07org.oe.dreambox * re7a2aacd... 10/packages/glibc/glibc_2.3.5+cvs20050627.bb: glibc_2.4.5+cvs20050627: remove bits/ directory created by cvs breakage Jan 05 08:28:53 03tmbinc 07org.oe.dreambox * r1df8d2eb... 10/packages/ipkg/ (4 files in 4 dirs): ipkg: move tar gnu extension patch to ipkg.inc Jan 05 08:28:57 03tmbinc 07org.oe.dreambox * r6e9ab8ed... 10/packages/python/python_2.4.2.bb: python-2.4.2: remove tcl/tk support until we support x Jan 05 08:30:23 replying Jan 05 08:30:41 koen: We just need to decide on a version format for cvs/svn files... Jan 05 08:30:54 and get it right so it works :) Jan 05 08:32:14 RP: what was the discussion on how to ha Jan 05 08:32:20 handle staging? Jan 05 08:32:54 koen: It was on oe@ Jan 05 08:33:00 not on #oe? Jan 05 08:33:04 koen: no Jan 05 08:33:10 ok Jan 05 08:37:36 sent Jan 05 08:40:16 koen: could you cut quotes when reply? Jan 05 08:40:25 hrw|work: I'll try to Jan 05 08:40:32 sometimes I'm just too lazy Jan 05 08:41:58 heh those lazy boys... Jan 05 08:42:00 ;) Jan 05 08:42:08 'PS signature quote is random - really!' Jan 05 08:42:17 zecke: Can we release a new bitbake version quite soon please? hrw makes a good point that if we're changing CVSDATE, subsequent versions will break fo the branch Jan 05 08:42:44 koen: it is random - but fits too good Jan 05 08:42:49 Sadly, a neccessary evil :-/ Jan 05 08:43:31 RP: should we add SCMDATE to the fetchers already? Jan 05 08:43:50 zecke: We need to release, then make the change Jan 05 08:44:13 and are we going to use SRCDATE or SCMDATE? Jan 05 08:44:27 SRCDATE might be the most generic? Jan 05 08:44:38 RP: we can add getDat'SCMDATE' or getVar'CVSDATE' now already Jan 05 08:45:13 Have SRC* semi reserved for fetcher variables? Jan 05 08:45:28 zecke: true, that might help us keep compatibility Jan 05 08:54:34 RP: btw - did you saw bug #573? Jan 05 08:55:36 hrw|work: Some idiot has added the CONFIG_CMDLINE back into the defconfig-cxx00, haven't they? :-/ Jan 05 08:55:40 ~lart me Jan 05 08:55:40 * ibot teaches rp that M$ Access is a database. No, really, a database. A real live multi-user... well, ok, not multi-user, but a database. Yeah, that sounds right. Jan 05 08:55:50 ;) Jan 05 08:57:50 Its a good way to check akita users are testing the kernel though :) Jan 05 08:57:59 ;) Jan 05 08:58:50 heh.. I'm too used to UP - started monotone pull on ewi and waiting until it end.. Jan 05 09:02:25 hrw|work: fixed pushed. will close the bug Jan 05 09:03:18 thx Jan 05 09:04:18 heh Jan 05 09:04:20 http://pastebin.com/491862 Jan 05 09:04:28 thank god for for-loops Jan 05 09:05:42 Thats a lot of locales Jan 05 09:05:47 hi ;) Jan 05 09:06:07 111 according to wc Jan 05 09:06:09 hey AvengerMoJo Jan 05 09:06:45 koen: I update directfb window manager a little ... with gtk :) and it seem to be usable ish :) Jan 05 09:07:19 AvengerMoJo: I saw some chatter about gtk+ on directfb on gtk-devel Jan 05 09:07:22 looks nice Jan 05 09:07:35 especially that debian is using it for the installer Jan 05 09:07:42 http://www.flickr.com/photos/69735356@N00/82461698/ Jan 05 09:08:05 I think debian is using the 2.0 port Jan 05 09:08:07 http://mail.gnome.org/archives/gtk-devel-list/2006-January/msg00048.html Jan 05 09:09:52 mickeyl: can you provide a summary of the "correct" metadata order please? (I'm not sure I know this :) Jan 05 09:09:53 03rpurdie 07org.oe.dev * rf219739e... 10/packages/linux/ (2 files in 2 dirs): linux-oz-2.6: Remove the line causing kernel failures on akita from the defconfig. Remove rndis patch as it break cdc_subset on c7x0. Jan 05 09:12:34 hi koen, RP, CosmicPenguin, hrw|work Jan 05 09:12:52 I've summarised the tasks. feel free to reply with any further items or details on proposed tasks Jan 05 09:12:54 hi gremlin[it] Jan 05 09:12:59 gremlin[it]: ciao.. :) Jan 05 09:13:18 hi gremlin[it] Jan 05 09:13:21 hey gremlin[it] Jan 05 09:14:05 RP: yeah, i'll send that lateron Jan 05 09:14:19 mickeyl: wiki might be good for that Jan 05 09:14:34 yeah, iirc we had a page that deals with that already Jan 05 09:14:34 we need to work on this documentation thing :) Jan 05 09:14:37 i try to dig it Jan 05 09:14:40 *nod* Jan 05 09:20:40 afternoon Jan 05 09:20:49 hi reenoo Jan 05 09:20:54 hi reenoo_ Jan 05 09:21:28 hi reenoo_ Jan 05 09:21:37 hey hrw|work, RP, koen Jan 05 09:22:40 17:18:15 [W] [Status 3] Jan 05 09:22:41 17:18:15 [C] Couldn't apply changeset Jan 05 09:22:41 17:18:20 [I] 2789 pending changesets in state file Jan 05 09:22:41 17:18:20 [C] Upstream change application failed Jan 05 09:22:41 Failure applying upstream changes: 'mtn update' returned status 3 Jan 05 09:22:44 :( Jan 05 09:23:15 http://www.bash.org/?107294 Jan 05 09:23:16 heh Jan 05 09:23:22 cherokee is still installed Jan 05 09:23:41 I'm fairly sure I don't need a webserver on a pda :) Jan 05 09:24:28 anyone happen to have logs of today's discussion in #oe? ibot's logging seems to be broken... Jan 05 09:24:50 ibot's logging is updated every 24 hours... if its less than 24 hours ago, you wont see it yet Jan 05 09:25:22 reenoo_: I can provide them Jan 05 09:25:22 I know. but the logs for the past week or so are corrupt/incomplete Jan 05 09:25:44 always end a few hours past midnight Jan 05 09:25:52 RP: thanks Jan 05 09:26:40 reenoo_: http://www.rpsys.net/openzaurus/temp/oe-log-050106.txt Jan 05 09:26:53 ah, odd Jan 05 09:29:03 one more thing about coming breakage.. DEPENDS != 'Build depends' question. Jan 05 09:29:57 hrw|work: We need to fix bitbake before we can fix that... Jan 05 09:30:05 ok Jan 05 09:33:07 [lala_]: please read the doc till tomorrow. TP visits us tom. Jan 05 09:36:45 mickeyl: is there a strong reason for python-2.4.2 depending on tcl/tk? i've a X-less system here, and something (sorry, i haven't checked ;) of that depends on X. Jan 05 09:38:55 the reason is to make it possible to build the tkinter extension module Jan 05 09:40:09 which is a module, so this dependency shouldn't hurt, just increase build time a bit Jan 05 09:40:56 the individual python packages don't depend on X btw., i override rdepends for every subpackage Jan 05 09:41:08 (see manifest) Jan 05 09:41:10 well, some of the dependencies fails to build here Jan 05 09:41:32 so it's a build-time issue Jan 05 09:41:35 yep Jan 05 09:42:06 feel free to remove that requirement in your tree - the tk interface module won't be build then but it shouldn't hurt the python build Jan 05 09:42:22 bbl, dishwashing and then sqash Jan 05 09:42:27 ok Jan 05 09:42:36 mickey|bbl: don't hurt yourself Jan 05 09:47:53 heh. I guess dishwashing can be dangerous if you don't get much practice. Jan 05 09:48:43 i think the only danger is dishpan hands Jan 05 09:48:48 oh noes, wrinkley Jan 05 09:51:52 http://www.askmen.com/jokes/2005_dec/dec31.html Jan 05 09:52:41 cu Jan 05 09:58:44 ~bon appetit Jan 05 09:58:45 from memory, bon appetit is smacznego. Guten Appetit. Eet Smakelijk. God Appetitt. Buon Appetito. Buen apetito Bom Apetite. buen apetito Jan 05 10:10:12 zecke: I think we can go ahead and convert bitbake to use SRCDATE Jan 05 10:11:18 RP: I will create a patch tonight Jan 05 10:11:28 RP: it would be nice if you can review it Jan 05 10:11:36 (the tailor converts are still running) Jan 05 10:11:39 zecke: I'd be happy to Jan 05 10:12:18 I'm about to move home now Jan 05 10:18:59 hi all Jan 05 10:19:11 kudos to all OE hackers Jan 05 10:20:05 built a toolchain and some stuff with OE for the gp2x (http://gp32x.com/) although my embedded development knowledge is seriously limited :) Jan 05 10:21:14 gp2x is arm? Jan 05 10:21:37 I am planning to do more development for the gp2x and want to install some important libraries to /lib and all minor important ones to /usr/lib (which will live outside the devices internal NAND memory) Jan 05 10:21:41 tmbinc: yes its ARM Jan 05 10:22:07 how can I achieve such an override? (eg. install libsdl in /lib) Jan 05 10:29:18 03tmbinc 07org.oe.dreambox * rb11c7ff0... 10/packages/python/python-2.4.2/ (autohell.patch bindir-libdir.patch crosscompile.patch): python-2.4.2: add files which were lost in propagate Jan 05 10:29:22 03tmbinc 07org.oe.dreambox * r197fcb6b... 10/packages/zope/ (zope-interface-native_3.1.0c1.bb zope-interface_3.1.0c1.bb): zope-interfaces: add 3.1.0c1 (and -native) Jan 05 10:29:27 03tmbinc 07org.oe.dreambox * r984321e2... 10/packages/twisted/twisted_2.1.0.bb: twisted: add twisted-2.1.0 Jan 05 10:31:10 blop Jan 05 10:31:14 * Luke-Jr stabs libsvg Jan 05 10:41:24 koen - btw, i split up ?540 on bugs.oe.org. Jan 05 10:57:33 is setting up apache2 for crosscompile hopeless? I see three places where it generates programs that generate code, presumably to take care of system differences. Jan 05 10:58:10 abrewer: Not hopeless but perhaps tricky. Can it read a cached value for the test reult? Jan 05 10:59:12 well sure, you could put some #ifdefs as a substitute to the generated code, which would be okay if you were just dealing with a few devices... just wondering how far somebody else might have gone down this path before i get my ass kicked (-; Jan 05 11:00:40 Good evening Jan 05 11:01:31 Just read the ML. RP statet, that people will have to update bitbake in the near future. Jan 05 11:01:42 I would have another feature request. Jan 05 11:01:56 uv1: What's that? Jan 05 11:02:07 Lets do all the breakage in one go :) Jan 05 11:02:46 If CVS co does not deliver the data in a module dir (cvs/abc-xyz/abc/*), but without (cvs/avc-a.x.z/*), fetch.py will give up. Jan 05 11:02:55 Just patched that file ... Jan 05 11:03:54 If no "MODULEDIR" is set in bb file, fetch.py will copy all stuff found in MODULEDIR into a prepared cvs/abc.xyz/abc dir and goes on like normal. Jan 05 11:04:47 uv1: You have a patch to fix this? Jan 05 11:05:18 Its still a quick hack patch using "cp -a " system command, as I could not find out, how to do this in pure python. Jan 05 11:05:37 I would like to do so, if anyone gives me the correct info ... Jan 05 11:06:18 RP: git add is pretty fast :) Jan 05 11:06:34 uv1: zecke would be the person to ask about python Jan 05 11:06:46 uv1: Let me pastebin your comments for his benefit Jan 05 11:06:50 * zecke deroutes to mickeyl Jan 05 11:06:56 zecke: How to copy a dir in python ? Jan 05 11:07:13 uv1: let me look it up ;) Jan 05 11:07:30 zecke: http://pastebin.com/492053 Jan 05 11:07:40 uv1: wrong would be os.system("cp -a %(src)s %(dst)") % vars() Jan 05 11:07:54 zecke: a potential cvs fetcher issue Jan 05 11:08:07 zecke: I think git is designed to be *fast*... Jan 05 11:08:14 which would make a nice change :) Jan 05 11:08:34 zecke: Guess, does not work on your BSD ? Jan 05 11:09:00 uv1: possible insecure, -a is a GNUism Jan 05 11:09:38 I do not fully understand the problem but I will answer your question first Jan 05 11:10:11 I also don't fully understand the problem with the fetcher fully... Jan 05 11:10:39 I know I can do cvs -d.../foo co . Jan 05 11:10:52 but that is not resulting in a problem i guess Jan 05 11:11:50 E.g. cvs co with module=abc does potentially (especially in my case) not end in sources/cvs/abc/abc, but in sources/cvs/abc only... Jan 05 11:12:41 uv1: -a replace it with -pPR Jan 05 11:15:06 uv1: I would say go with os.system for now Jan 05 11:15:12 This is stopping fetch.py, as that script uses "os.chdir(moddir)" with moddir "moddir=os.path.join(pkgdir,localdir)" and "localdir = module" ... Jan 05 11:15:57 OR "localdir = parm["localdir"]" !! Potentially, that's it! Jan 05 11:16:26 Where is parm["localdir"] gets its data from ? Jan 05 11:17:07 uv1: I guess Fetch base class Jan 05 11:17:30 does anybody have a recipe for keeping my own set of diffs/additions to OE in a local monotone db??? Jan 05 11:17:42 uv1: Its set in the SRC_URI ;localdir=xxx Jan 05 11:17:53 er, hang one Jan 05 11:18:16 abrewer: branches Jan 05 11:18:40 RP: That'll help. I implemented a similar thing. So forget thet patch until I can try the original tomorrow. Jan 05 11:18:46 yes, it looks like some cvs fetcher parameter Jan 05 11:18:48 i read the (really good) monotone manual... so i just do a 'db init' and then make my own branch? Jan 05 11:19:03 uv1: use os.system for now Jan 05 11:19:26 * RP loves our documentation of features like this... Jan 05 11:20:27 abrewer: you can use the same database Jan 05 11:20:29 zecke: You do not mean to want that patch, if original fetch.py potentially supports this feature already ? Jan 05 11:20:54 abrewer: and do monotone commit -b org.openembedded. on a modifief file Jan 05 11:20:58 uv1: I'm interested in a patch Jan 05 11:21:18 but that gets stored locally somewhere, right? Jan 05 11:21:24 abrewer: yes Jan 05 11:21:38 thanks! I'll try some experiments. appreciate it. Jan 05 11:22:20 RP: SRCDATE or SCMDATE Jan 05 11:24:18 SRCDATE or even SRC_DATE will probably be easiest to understand Jan 05 11:28:56 zecke: patch at http://pastebin.com/492095 Jan 05 11:29:08 03koen 07org.oe.dev * r34267e55... 10/packages/gpe-timesheet/gpe-timesheet_0.20.bb: gpe-timesheet: add 0.20 Jan 05 11:30:02 zecke: BitBake Build Tool Core version 1.3.2.1, bitbake version 1.3.2 Jan 05 11:31:42 uv1: I still do not get the issue. I will get some food and get back to you! Jan 05 11:32:26 zecke: Wait, I have to leave. Jan 05 11:32:26 zecke: I think SRCDATE, then we match SRC_URI. Jan 05 11:32:41 RP: SRC_DATE then? Jan 05 11:33:10 zecke: Will come back tomorrow! Thanks so far, Bye Jan 05 11:33:22 * koen should buy some more underscores Jan 05 11:33:24 SRC_DATE is perhap going to look a bit odd when used in all the CVSDATE style variables in the version preference files Jan 05 11:34:11 The _ character does special things in variable names and is perhaps best avoided? Jan 05 11:34:18 I know we don't have to... Jan 05 11:34:47 OE seems to be fond of the _ Jan 05 11:34:55 SRC_URI, STAGING_SOMETHINGDIR Jan 05 11:35:29 if you put DATE into your overrides you will lose Jan 05 11:35:34 For instance think what would happen if DATE ever got set in an OVERRIDE... Jan 05 11:35:39 zecke: snap :) Jan 05 11:47:06 * RP -> food Jan 05 12:04:52 RP: #576 Jan 05 12:05:38 woglinde: happy birthday to you... happy ;) Jan 05 12:05:47 zecke yes yes Jan 05 12:06:18 schoenen geburtstag woglinde Jan 05 12:06:27 jo danke koen Jan 05 12:07:45 weird Jan 05 12:07:47 * koen monotone --db=/data/build/oe/OE-commit.db db kill_branch_certs_locally org.openembedded.zecke Jan 05 12:11:06 heh. the zecke branch lives on? Jan 05 12:11:58 wasn't me Jan 05 12:12:29 ah, must be some other zecke Jan 05 12:12:47 pb_: some muesli eating teenage jerk... Jan 05 12:20:34 wow tailor just comitted revision 28 to the svnrepo :} Jan 05 12:21:55 crumbs Jan 05 12:22:01 how long does it take for each revision? Jan 05 12:23:37 pb_: countless amount of clock cycles Jan 05 12:24:34 pb_: I do not know how it counts though Jan 05 12:25:48 svn revision 28? one revision per commit then. Jan 05 12:26:12 plus initial import/creating dirs, etc. Jan 05 12:26:27 reenoo_: I do not know if tailor converts one monotone revision into a svn revision Jan 05 12:26:35 reenoo_: or puts them together somehow Jan 05 12:26:56 would be rather bad if it did Jan 05 12:27:33 if the goal is to preserve revision history Jan 05 12:27:37 right Jan 05 12:29:38 hey, does anyone know of a solution to the "ordering" of modules being loaded in /etc/modprobe.d? Jan 05 12:29:57 if the touchscreen module gets loaded before the keyboard module, we're hosed. Jan 05 12:30:54 lkcl: why? Jan 05 12:31:13 detect-stylus autodetects with event interface the touchscreen is on :) Jan 05 12:31:35 s/with/which/ Jan 05 12:32:19 yes, detect stylus works - but keyboard won't. Jan 05 12:32:33 ... or will it? Jan 05 12:32:38 it should work fine. Jan 05 12:32:54 assuming you're using legacy keyboard, which virtually everyone is, nothing ought to care what event device it's on. Jan 05 12:33:24 hmmm.... detect-stylus command not found (on the opie-image i just built - how odd) Jan 05 12:33:25 if for some reason you are not using the legacy muxing, I guess you should write a "detect-keyboard" program to find it :-) Jan 05 12:33:33 *sigh* :) Jan 05 12:33:44 first opie boot on a blueangelllll Jan 05 12:34:00 heh Jan 05 12:34:03 aaaand, drat - detect stylus wasn't there. first hard-reset, too, it looks like.... Jan 05 12:34:16 now the quest to reclaim your soul and innocense from Troltech Jan 05 12:34:17 ah, that would be a problem Jan 05 12:34:40 muhahaha Jan 05 12:35:13 what's that ~ thing, the one where you can get the irc bot to pour forth insults at someone/something... Jan 05 12:35:22 ~insult lkcl Jan 05 12:35:24 lkcl is nothing but an it-fowling stack of droning urine samples Jan 05 12:35:48 ~insult Trolltech Jan 05 12:35:50 Trolltech is nothing but a contemptible quart of headless red dye number-9 Jan 05 12:36:02 come on ;) Jan 05 12:36:04 i _fart_ in the general directionnn of trolltech Jan 05 12:36:41 teehee. eat your dinner, zecke: what i say might put you off food for life Jan 05 12:37:54 ahh, i love qt really. and kde. _stacks_ more... refreshing, shall we say, than gtk. Jan 05 12:38:21 if only qt/e would use X... Jan 05 12:38:23 can't program qt applications for toffee, mind... Jan 05 12:38:52 refreshing? Jan 05 12:38:52 oh - ah. yes, i did notice some uicmoc code that was directly accessing framebuffers and stuff - what's _that_ all about?? Jan 05 12:38:58 * pb_ gives lkcl a funny look Jan 05 12:39:06 gimme one sec, pb... Jan 05 12:40:24 http://advogato.org/person/lkcl/diary.html?start=235 says it best - warning, warning warning, opinionated xxxxer alert! do not read if you are easily upset by opinionated little toads like me! Jan 05 12:41:29 how odd. detect-stylus isn't anywhere on the opie-image. Jan 05 12:41:51 lkcl: opie is empowering people to hardcode assumptions ;) Jan 05 12:41:57 opie doens't have detect-stylus Jan 05 12:42:01 gpe has :) Jan 05 12:42:31 koen: well like ifrename I want similiar functionality for the input layer ;) Jan 05 12:42:44 tslib does OH DRAT, now you tell me, just after i provided myself with a huuuge beartrap to walk into. Jan 05 12:43:08 ... looks like it is, koen - no x server??? Jan 05 12:43:29 zecke|food: yeah, udev is rumoured to provide that Jan 05 12:44:36 hm so lkcl is a htc hacker Jan 05 12:44:37 RP, reenoo_, mickey|bbl: I just sent a task reorganization example to the list, I hope I got it right Jan 05 12:44:41 detect-stylus - dependencies are..... xrdb, x11... DRAT! Jan 05 12:44:57 koen: do you remember the include vs. require discussion Jan 05 12:45:07 yeah, but removing the last ~20 lines of detect-stylus would solve that Jan 05 12:45:08 zecke|food: yes Jan 05 12:45:17 that's greeeeaaat... *sigh*... hm... *thinks*... Jan 05 12:45:18 koen: how did it end? Jan 05 12:45:24 workaround.... hmmm.... Jan 05 12:45:36 zecke|food: require would error out, nobody had time to implement it Jan 05 12:45:52 koen: well I have written three lines Jan 05 12:45:58 koen: how should the keyword be named Jan 05 12:46:22 lkcl: http://handhelds.org/cgi-bin/cvsweb.cgi/gpe/base/detect-stylus/detect-stylus.c?rev=1.13&content-type=text/x-cvsweb-markup Jan 05 12:46:48 zecke|food: 'require' or 'mandate' or something Jan 05 12:47:14 * koen suspects zecke now implements something(foo.inc) Jan 05 12:53:57 koen: we now have a require keyword Jan 05 12:54:02 zecke|food: cool Jan 05 12:54:05 well after the next release of bitbake Jan 05 12:54:11 * koen hands zecke some vla Jan 05 12:54:28 koen: I have it my fridge already... but it is a good idea Jan 05 12:54:35 * zecke|food gets a cup of vla now Jan 05 12:59:47 heya folks. Jan 05 13:00:00 *g* Jan 05 13:00:03 anyone know if there's an equivalent to GPE_EXTRA_DEPENDS for opie? Jan 05 13:00:45 i see SLUGOS_EXTRA_DEPENDS, MAEMO_EXTRA_DEPENDS, UNSLUNG_EXTRA_DEPENDS, BOOTSTRAP_EXTRA_DEPENDS.... Jan 05 13:01:49 or is it a capitalisation thing: if you have DISTRO="thingy", then you get THINGY_EXTRA_DEPENDS and you can add to that? Jan 05 13:01:52 clues? Jan 05 13:02:15 i need to add detect-stylus (a gpe program) to the opie build. Jan 05 13:02:20 no, there's nothing special about *_EXTRA_DEPENDS Jan 05 13:02:37 lkcl: see packages/meta/*opie*.bb Jan 05 13:02:50 lkcl: you can use BOOTSTRAP_EXTRA_DEPENDS Jan 05 13:02:52 ack. thanks zecke. Jan 05 13:02:53 ah _ha_ Jan 05 13:03:10 zecke I guess lkcl runs opie on the mda III Jan 05 13:03:27 if i add it to "everything", the fact that it's already in gpe isn't going to mess up a bitbake gpe-image, is it? Jan 05 13:04:28 lkcl: shouldn't happen. A proper fix would be to reimplement detect-stylus without any glib/X code and use that for all images Jan 05 13:06:32 *sigh*. yehh. there are more pressing things right now. i fried my brain by staying up till 5:30am today so getting opie-image to work is about the "safest" thing i can pick right now. when i'm not fried, i'll have kernel-hacking to do... Jan 05 13:07:56 lkcl I guess there is work needed in opie to run it on the htc devices Jan 05 13:10:06 woglinde: a open-source gsm app would be a nice start Jan 05 13:10:09 well it's running: i'm getting to the "press touchscreen" stage Jan 05 13:10:18 there's always gomunicator, koen. Jan 05 13:10:26 however it's a hacked-up gpe application. Jan 05 13:10:32 lkcl: doesn't run opie Jan 05 13:10:34 no X Jan 05 13:10:36 lkcl oh hm Jan 05 13:10:38 * koen gloats Jan 05 13:10:44 we've been talking on #htc-blueangel about porting it to qt. Jan 05 13:11:07 with proper front and backend seperation? Jan 05 13:11:09 that would be nice Jan 05 13:11:15 koen - yes. Jan 05 13:11:33 although cr2's take on that would be to trash gomunicator and start from gnokiii and libgsm. Jan 05 13:11:34 and multiplexer separation? Jan 05 13:11:59 yehh, that got talked about, too - my idea was to do like gpsdrive and gpsd. Jan 05 13:12:08 heh Jan 05 13:12:11 cp15 recommended dbus Jan 05 13:12:21 incorporate a fork of gpsd? Jan 05 13:12:21 because gomunicator and gpe already use dbus. Jan 05 13:12:38 gpsd - for GPS satellite receivers. Jan 05 13:12:39 and wait till it blows up, so you have to start to use the external gpsd? Jan 05 13:12:46 I know Jan 05 13:12:50 oh, right :) Jan 05 13:13:02 gpsdrive a a great example on how NOT to run an open source app Jan 05 13:13:15 v cool side-note: i managed to get gpsd to run on the skyminder devices, dial up over GPRS and then use gpsdrive on a PC to connect to it. Jan 05 13:13:30 the skyminder is a failed project to put GSM and GPS on a "security" device. Jan 05 13:13:39 with VoIP and data logging and stuff Jan 05 13:13:54 with dgps as well? Jan 05 13:14:08 although gprs lag might prevent it from being usefull Jan 05 13:14:12 koen: just buy a license of this award winning Qtopia Phone Edition Jan 05 13:14:23 heh Jan 05 13:14:24 ... but they used a Cirrus Logic "Maverick" processor only 90mhz and two other ARMs - one in the radio rom and one in the gps module. Jan 05 13:14:27 zecke *g* Jan 05 13:14:29 I pay enough tax right now Jan 05 13:14:35 zecke best choice in china or so Jan 05 13:14:44 the CLPS wasn's fast enough to run libspeex at 8kHz!!!! Jan 05 13:14:57 ~guinness koen Jan 05 13:15:04 * ibot pours a creamy pint of dark bitter guinness stout and hands it to koen Jan 05 13:15:28 http://www.glomationinc.com/products_9312-sx.html <- with FPU Jan 05 13:15:36 * koen -> beer now Jan 05 13:15:58 lkcl: are the skyminder devices available? Jan 05 13:15:59 okay, adding detect-stylus seems to have been a successful build, now to try it... Jan 05 13:16:23 he tmbinc how was it in berlin? Jan 05 13:16:59 zecke|food: fwiw, '16,+2d;21,+1d;47,+2d;53,+5d;116,+23d;140s+0+1+' is the sed patch you need to remove the glib and x11 code from detect-stylus. Jan 05 13:17:12 maybe you could incorporate that into a .bb and make an opie version Jan 05 13:17:51 heh Jan 05 13:17:55 pb_: hehe. so gpe-detectstylus is copyright header + opening /dev/inpute/eventX? ;) Jan 05 13:18:14 zecke|food: drat, you uncovered my secret Jan 05 13:18:24 hi renoo Jan 05 13:18:30 hey woglinde Jan 05 13:18:46 re koen Jan 05 13:19:02 if it's _that_ easy, even i can do it with my fried brain. Jan 05 13:19:50 actually, it's not quite that easy. I missed one line. Jan 05 13:20:09 still, you should be able to figure it out. when you get an error about an undeclared variable, delete the line with the error. Jan 05 13:20:29 who knows how to make libsvg compile? :) Jan 05 13:20:53 pb_: I bet you could only create this code because you took it out of UNIX System V Jan 05 13:21:07 Luke-Jr: voodoo Jan 05 13:22:09 ack, pb. Jan 05 13:22:14 zecke|food: on the contrary, I made it by reverse engineering the rights management support in a pirated copy of longhorn Jan 05 13:22:21 woglinde: quite nice Jan 05 13:22:39 Luke-Jr: hit it with a hammer? Jan 05 13:22:54 pb_: that rocks a true heroe in our rows Jan 05 13:23:05 tmbinc dindt have time, because I have to work on my flat Jan 05 13:23:35 http://pastebin.ca/35898 Jan 05 13:23:39 :/ Jan 05 13:26:15 RP: if you say you can still fetch source code with trunk of bitbake we can release a new version Jan 05 13:29:40 ahh, drat. yep - patching it is. Jan 05 13:29:53 of course - it says "cannot detect xserver..." Jan 05 13:31:40 ah - it works. detect-stylus --device Jan 05 13:39:42 well i have an ssh in - the touchscreen is giving out events, but opie doesn't want to pick them up, Jan 05 13:40:01 even though TSLIB_TSDEVICE=/dev/input/event0 is set correctly. Jan 05 13:40:05 odd. Jan 05 13:40:07 QWS_MOUSEPROTO? Jan 05 13:40:23 set QWS_MOUSEPROTO to TPanel Jan 05 13:40:29 or some other empowering variable? Jan 05 13:40:45 koen|tv: no this was a good call Jan 05 13:41:55 03rw 07org.oe.dev * r614971e9... 10/packages/libmad/libmad_0.15.0b.bb: libmad: revert deletion of do_stage() applied in b5e7f8ff699745865fbaf5837f61cdc510d33bdb Jan 05 13:42:00 03rw 07org.oe.dev * r2f85a760... 10/packages/libvorbis/libvorbis_1.0.1.bb: libvorbis: revert deletion of do_stage() applied in 615eba3bfa04f4ca312f9d49ca5bd804c48864f7 Jan 05 13:42:04 03rw 07org.oe.dev * r79bab1c4... 10/packages/libid3tag/libid3tag_0.15.0b.bb: libid3tag: revert deletion of do_stage() applied in 10d8222c82822cf7dc06049b59d4149169551aa1 Jan 05 13:42:08 03rw 07org.oe.dev * ra995632e... 10/packages/libao/libao_0.8.6.bb: libao: revert deletion of do_stage() applied in 3db52ecf315fce5662f670b01ec6148168debcd2 Jan 05 13:42:12 03rw 07org.oe.dev * r99071b2f... 10/packages/lzo/lzo_1.08.bb: lzo: revert deletion of do_stage() applied in 71628c7543be0569aeb80a525ad951d4006b1cbd Jan 05 13:42:16 03rw 07org.oe.dev * r3de3adf7... 10/packages/openobex/openobex_1.0.1.bb: openobex: revert deletion of do_stage() applied in cc48e899d4b736ce34af0a73fe85463c86d71fd7 Jan 05 13:42:20 03rw 07org.oe.dev * r16facdab... 10/packages/popt/popt_1.7.bb: popt: revert deletion of do_stage() applied in 068f4de8987266220879a628c352cfae84f1b288 Jan 05 13:42:22 ta zecke|food Jan 05 13:42:24 03rw 07org.oe.dev * rd5cffcb1... 10/packages/cyrus-sasl/cyrus-sasl_2.1.19.bb: cyrus-sasl: revert deletion of do_stage() applied in cc38fee3e6ce218e7c6a178c82b40f9a3a3ed885 Jan 05 13:42:28 03rw 07org.oe.dev * rab67a511... 10/packages/bluez/bluez-libs_2.21.bb: bluez-libs: revert deletion of do_stage() applied in 2f06f49d807367c54e4ea7e65e8a801c28ac178f Jan 05 13:42:32 03rw 07org.oe.dev * re5c55302... 10/packages/jpeg/ (jpeg-native_6b.bb jpeg_6b.bb): jpeg: revert deletion of do_stage() applied in 7170376c9b53df050cf818ffca4ea499b8aea5b9 Jan 05 13:42:37 03rw 07org.oe.dev * r3ab46de0... 10/packages/glib-2.0/glib-2.0_2.8.2.bb: glib-2.0: fully revert deletion of do_stage() initially applied in b10c7a501f6606abe1b6a425dbb75912e858ae9f Jan 05 13:42:41 03rw 07org.oe.dev * r16b0ab18... 10/packages/db/db_4.3.29.bb: db: revert deletion of do_stage() applied in cb4bdb355a7ab7751886b88c8857c5f64fcfd84f Jan 05 13:42:46 03rw 07org.oe.dev * r171b6baa... 10/packages/libogg/libogg_1.1.bb: libogg: revert deletion of do_stage() applied in c6358e3932bd89f868ce958c308bc34cc870e25c Jan 05 13:42:50 03rw 07org.oe.dev * r41ee231e... 10/packages/audiofile/audiofile_0.2.6.bb: audiofile: revert deletion of do_stage() applied in 5c22e08daabf70f10120e7226d3995a5b5777de5 Jan 05 13:42:54 03rw 07org.oe.dev * r3b425991... 10/packages/flac/flac_1.1.0.bb: flac: revert deletion of do_stage() applied in 1afdc843b65bacc2cfc4f7a91dea88affeaf5bd5 Jan 05 13:42:58 03rw 07org.oe.dev * r0abdf959... 10/packages/gdbm/ (gdbm-native_1.8.3.bb gdbm_1.8.3.bb): gdbm: revert deletion of do_stage() applied in d5cad88ce1e757a9ebbac7f47c3c0e728e5a3482 Jan 05 13:43:02 03rw 07org.oe.dev * r2c1b80cf... 10/packages/libexif/libexif_0.6.9.bb: libexif: revert deletion of do_stage() applied in 9c3da63504cf03581d04ad46a9797e04293b62e8 Jan 05 13:43:06 03rw 07org.oe.dev * re8a054f7... 10/packages/expat/expat_1.95.6.bb: expat: revert deletion of do_stage() applied in 133f3abf4845cbe01834a4e1476b5a5ad776ce02 Jan 05 13:43:10 03rw 07org.oe.dev * r813a62dc... 10/packages/pcre/pcre_4.4.bb: pcre: revert deletion of do_stage() applied in b50ac951745a042a4a00f8e7b81e7e785ca22851. fixes Bug #575. Jan 05 13:43:51 nope - that didn't work (QWS_MOUSEPROTO=TPANEL) Jan 05 13:44:11 lkcl: TPanel I said ;) Jan 05 13:44:20 probably case sensitive Jan 05 13:44:27 trying TPanel instead... nope. Jan 05 13:44:47 lkcl: then look what QtE is opening (using the procfs) Jan 05 13:46:09 and sacrifice the correct number of goats Jan 05 13:46:22 koen|tv: why not Gnu's? Jan 05 13:46:35 :) Jan 05 13:48:50 * reenoo_ finishes reading logs Jan 05 13:48:50 koen|770: I'd welcome it if you stopped misrepresenting me and accusing me of spreading FUD behind my back. Jan 05 13:48:56 koen|770: as far as the release branch is concerned, soon after it was created I suggested automating the cherrypicking task with a script, I believe I even wrote a few lines of pseudo-bash on IRC that could have been extended to a working version with a standardized format for commit messages especially naming source revisions. that would have made things so easy if you hadn't turned that approach down. instead there's now no automated way to identify Jan 05 13:48:56 koen|770: that does indeed qualify as unknown/undocumented to me and even worse: in SCM terms it effectively creates a fork, not a branch, since there's no way to determine ancestry. Jan 05 13:48:58 koen|770: as far as the do_stage() deletions are concerned, like I said in a message to oe@, I was referring to the recently introduced mass changes only. e.g. your change to tslib_cvs.bb is perfectly legal since it fixes a bug and has been tested. John himself however said his changes hadn't received enough testing (by diffing staging trees before vs. after as Richard suggested). raising concerns about that hardly qualifies as FUD either. Jan 05 14:16:31 03tmbinc 07org.oe.dreambox * rc866ce0b... 10/packages/enigma2/enigma2.bb: enigma2: move SRC_URI to public cvs Jan 05 14:20:21 * RP returns Jan 05 14:20:39 RP: wb Jan 05 14:22:10 zecke: current bitbake svn works for me for fetching (unless there've been any changes recently) Jan 05 14:22:50 and fwiw, detect-stylus should be depreciated in favour of a few lines in a udev script Jan 05 14:23:10 RP: from one hour ago? Jan 05 14:23:10 Its what it was written for afterall Jan 05 14:24:39 zecke: I think my version is slightly out of sync - I'm testing now Jan 05 14:24:57 RP: I've comitted the SRCDATE change already Jan 05 14:24:58 RP: do your ALSA drivers for Cxx0 handle the mic at all? Jan 05 14:25:31 RP: does udev know how to handle usbnet yet? Jan 05 14:26:15 mithro: hi Jan 05 14:26:33 zecke: right, that's what's confusing me. Testing once I get some disk space back :-/ Jan 05 14:26:55 mreimer: Not yet but I do want to teach it about that Jan 05 14:27:07 Luke-Jr: They handle the mic totally Jan 05 14:27:26 RP: concurrent w/ audio out? Jan 05 14:27:41 Luke-Jr: mono audio out, yes Jan 05 14:27:57 detect-stylus, even if depreciated (or even deprecated), is still needed for 2.4 kernels. I don't think it can go away any time soon. Jan 05 14:28:08 RP: what if audio out is opened first? Jan 05 14:28:18 pb_: legacy stuff... Jan 05 14:28:33 zecke: yeah, we're all about the legacy Jan 05 14:28:48 RP: and is it possible to use speaker-out concurrent w/ mic? Jan 05 14:28:56 or is that a hardware limitation? Jan 05 14:30:46 pb_: Not go away but it can be depreciated Jan 05 14:30:46 hey zecke Jan 05 14:30:52 buy zecke Jan 05 14:30:57 s/buy/bye Jan 05 14:30:59 zecke: cvs is confirmed as working Jan 05 14:31:03 I'm not quite sure I agree with the "its what it was written for" statement about udev either, though I'm sure it could indeed be used for this purpose. Jan 05 14:31:36 RP: sure, nothing prevents you from depreciating it at any time. Jan 05 14:31:41 Luke-Jr: Its possible to use them concurently. I'm not sure what happens if you try to use both as audio out then open the device as input as well Jan 05 14:31:46 mithro: I'm converting monotone to darcs, git and svn using tailor Jan 05 14:32:11 Is udev to the point where we can get rid of hotplug scripts entirely? (hoping so) Jan 05 14:32:21 mreimer: I don't think that's a goal... Jan 05 14:33:03 * Luke-Jr ponders playing stereo via speakers while concurrently doing VoIP via headphone/mic jack ;) Jan 05 14:34:02 pb_: It was udev was written to mean you can have arbitrary naming of /dev entries. It means we can setup a consistent /dev/touchscreen device, regardless of what kernel devices are available or their number in any other system... Jan 05 14:34:29 heya zecke: oh - right, okay, i understand. the manual equivalent of lsof Jan 05 14:34:38 lkcl: hehe Jan 05 14:34:47 pb_: I realise udev has other uses but this was one of its objectives Jan 05 14:36:05 mreimer: Yes, hotplug is already actually dead in OE under udev (no I didn't commit that but I didn't undo it either as it didn't break much) Jan 05 14:36:26 hotplug is dead _completely_ with the latest versions of udev Jan 05 14:36:34 Yay! Jan 05 14:36:38 yay Jan 05 14:36:47 on dappery my udev conflicts with hotplug Jan 05 14:37:03 zecke: yay Jan 05 14:37:10 hotplug go squish now Jan 05 14:37:28 under debian/testing, with a 2.6.12 or greater kernel, hotplug simply ... goes bye-bye Jan 05 14:37:44 actually, that sucks a bit, since I guess it means gpe hot-plugging support will stop working. Jan 05 14:37:45 oh well Jan 05 14:37:53 but we can't get rid of it due to 2.4 as pb_ will point out in a minute :-/ Jan 05 14:38:15 what hot-plugging does GPE do? Jan 05 14:38:17 zecke: nope - nothing open. /dev/null a few times, /dev/fb0, /dev/vc/0 and a socket - that's it. Jan 05 14:38:21 pb_: This is where my view of 2.4 and 2.6 being separate machines comes from. There's just so many differences emerging Jan 05 14:39:10 why would you _want_ to run a kernel that hasn't been actively maintained by the mainline linux developers for over two years, dude? *quizzical* Jan 05 14:39:33 mreimer: not a great deal, in fact, which is why I'm not too upset about it Jan 05 14:39:40 i know it's 25% smaller (600k instead of 900k, typically), i know it's usually faster... _but_... Jan 05 14:39:49 lkcl: no other choice? Jan 05 14:40:09 lkcl: Some hardware doesn't have a 2.6 kernel Jan 05 14:41:04 He said "_want_ to"... Jan 05 14:42:45 RP: I'm still converting to git... Jan 05 14:43:04 RP: yeah, there certainly are differences between 2.4 and 2.6, and making them separate machines is very probably the appropriate answer for openzaurus. Jan 05 14:43:24 I certainly don't oppose you doing that. Jan 05 14:43:57 pb_: You'll note I've abstained on how familar handles the ipaqs Jan 05 14:44:39 pb_: but I would add that angstrom may well be 2.6 only depending on how easily 2.4 kernels are going to support the new EABI... Jan 05 14:45:04 Something that needs thought :-/ Jan 05 14:45:20 Transmitting file data .... Jan 05 14:45:21 Committed revision 32. Jan 05 14:45:52 Sure. Angstrom is welcome to adopt whatever policy it likes, just like openzaurus and familiar do. Jan 05 14:47:19 pb_: I'd like to see OE handle the 2.6 vs. 2.4 kernel issue better. Sadly the time I and openzaurus need that is nearly passed, at least for 2/3rds of the zaurus models... Jan 05 14:49:55 ah HA. Jan 05 14:50:04 QWS_MOUSE_PROTO=... Jan 05 14:50:22 I don't actually think the 2.4 vs 2.6 thing is particularly intractable in itself. It was probably worse on the Zaurus because so much of the kernel was rewritten to behave differently at the same time. Jan 05 14:51:00 let's see if it works... Jan 05 14:51:20 lkcl: hah Jan 05 14:52:52 zecke: I've also sanity checked you patch and it looks good to me Jan 05 14:53:15 okay - it now has /dev/input/event0 open... Jan 05 14:53:20 rock Jan 05 14:53:59 and seems to have "bought" the ... damn. it accepted a "press" but is going no further... Jan 05 14:54:11 not so rock Jan 05 14:54:19 suck, in fact Jan 05 14:54:46 let's kill it again, try thingy. reading /dev/input/event0 manually... Jan 05 14:54:53 i couldn't read from event0 earlier... Jan 05 14:55:05 with evtest or something? Jan 05 14:55:14 or you mean you couldn't read from it at all? Jan 05 14:55:38 If I have a local.conf from probably a year ago, is it likely to still work? Jan 05 14:55:48 (and some replacement meta-.bbs) Jan 05 14:56:10 Luke-Jr: I'd doubt the local .conf will just work. The meta-'s might be ok Jan 05 14:56:37 hexdump /dev/input/event0 Jan 05 14:56:48 RP: I was expecting otherwise for an answer O.o Jan 05 14:56:51 RP: why not the local.conf? Jan 05 14:56:54 earlier i had to remove the battery module and reload the ts module Jan 05 14:57:03 funky Jan 05 14:58:07 okay, hexdump shows data spewing forth... Jan 05 14:59:14 root@blueangel:/opt# ls -altr /proc/5280/fd/ Jan 05 14:59:20 lr-x------ 1 root root 64 Jan 5 21:46 5 -> /dev/input/event0 Jan 05 14:59:23 so that's there... Jan 05 14:59:35 tap anywher on screen to continue.... annnd..... Jan 05 14:59:41 nothing. Jan 05 14:59:42 dang! Jan 05 15:00:18 earlier it was happy to have the "english" thing going. is it supposed to run a config program or anything? Jan 05 15:00:25 calibration? Jan 05 15:02:53 hmmm... Jan 05 15:05:00 do i _have_ to have a keyboard module? Jan 05 15:06:07 ahhh... for some reason, ts.conf doesn't exist. BURBLE. Jan 05 15:07:18 does it need to? Jan 05 15:07:45 yes, according to... http://66.102.9.104/search?q=cache:6YBWgHsaDJsJ:www.handhelds.org/hypermail/h2200-port/current/3367.html+opie+touchscreen+event0&hl=en Jan 05 15:07:51 koen|770: how do you prevent write access to ewi? I.e. how are you enabling it on a per-ID basis? Jan 05 15:08:10 We need to do the same on nslu2-linux.org Jan 05 15:08:25 .monotonerc hooks Jan 05 15:08:34 no more regexp Jan 05 15:09:35 jbowler: http://pastebin.com/492455 Jan 05 15:09:44 Ah, thanks. Jan 05 15:11:00 Ok, we're fixing the nslu2-linux DB, it would be good if we could sync that back to the OE dbs before the horrible changes start ;-) Jan 05 15:11:26 indeed Jan 05 15:16:00 koen|770: if I fix the nslu2-linux db today, and put in the netsync write restrictions so that only people who have fixed the database can play, will that be ok? Jan 05 15:16:30 rwhitby: that would be close to perfect Jan 05 15:17:17 Does anyone have an easy way of extracting diffs from monotone so that they can be reapplied to a fixed db ? Jan 05 15:17:30 viewmtn? Jan 05 15:17:50 The instructions on the message I posted to the OE mailing list a couple of days ago Jan 05 15:17:51 koen|770: something scripted I can run on a local database would be preferred ... Jan 05 15:18:00 jbowler: URL? Jan 05 15:18:09 or the voodoo mickeyl uses for the commits Jan 05 15:18:38 where's the calibrate application gone???!?!?! Jan 05 15:18:42 koen|770: I will take down the nslu2-linux server now, then replace it with jbowler's fixed DB (with no nslu2-linux changes past the bad day) and institute per-id write restrictions. Jan 05 15:19:05 then I will extract the diffs from my local DB, and textually apply them to the fixed DB. Jan 05 15:19:20 rwhitby: cool Jan 05 15:19:46 The problem is that there's nothing to automate things like 'rename', the url is:http://www.handhelds.org/hypermail/oe/current/5309.html Jan 05 15:19:56 in a worst case, I will just apply all nslu2-linux changes since that date as a single file commit by copying files between working dirs and loose all the history. Jan 05 15:20:12 yeah, the renames I will have to do by hand. Jan 05 15:20:27 the number of nslu2-linux files involved is manageable Jan 05 15:20:37 the opie-taskbar ipkg shows a calibrate.desktop in it, ~/sources/cvs/opie-taskbar/opie/core/apps/calibrate exists - but no calibrate application. utterly weird. Jan 05 15:20:48 (i.e. we haven't touched many (if any) common OE files, so the locality of changes is good) Jan 05 15:22:48 the increase in people actual write access would be nice Jan 05 15:23:34 * koen|770 spots a misding 'with' in that sentence Jan 05 15:23:52 ~lart maemo vkb Jan 05 15:23:52 * ibot throws maemo vkb's poor little doggy off a cliff Jan 05 15:39:36 koen|770: copied you on the email announcing the nslu2-linux migration. we have turned off database access as from now. Jan 05 15:50:30 good nite Jan 05 15:51:41 RP: I will give you access to the git stuff once the conversion is done Jan 05 16:30:40 night all Jan 05 16:32:16 hehe - I love it people post messages to other mailing lists, and its obvious they are using OE as the backend Jan 05 16:32:24 s/backend/build system/ Jan 05 16:33:23 such as? Jan 05 16:34:48 Some guy on the linux-mips list has a problem compiling diet-x11 Jan 05 16:59:37 * RP sighs at the state of oe's dependency data Jan 05 17:00:02 * RP but smiles as it proves my RDEPENDS -> DEPENDS code is semi working :) Jan 05 17:00:46 RP: but aren't RDEPENDS large time automatically generated? or will that simply stop? Jan 05 17:01:47 tmbinc: No, the issue is that DEPENDS sometimes contain things that are really RDEPENDS for image generation Jan 05 17:02:34 like? (i've never understood that problem - DEPEND stuff doesn't show up in images, or does it my some mysterious mechanism?) Jan 05 17:02:41 by Jan 05 17:04:34 tmbinc: DEPENDS should be things a package needs to build only Jan 05 17:04:55 Sometimes we have things in DEPENDS because we need them at runtime and this is wrong Jan 05 17:06:01 but how does putting something into DEPENDS help at all? it won't show up in the image. (not that it's a good idea, either, of course.) Jan 05 17:06:35 No, but if something is in an RDEPENDS only, bitbake won't have built it and the image generation will fail Jan 05 17:07:06 To solve this, people have put things in DEPENDS as well as RDEPENDS Jan 05 17:09:25 oh i see Jan 05 17:52:49 eck Jan 05 17:52:56 fontconfig-native is trying to write outside of tmp Jan 05 18:15:12 * RP goes to bed Jan 05 18:23:44 hmm Jan 05 18:23:55 wassup reenoo? Jan 05 18:24:27 just pondering going off to bed ;) Jan 05 18:24:36 sounds like a plan actually Jan 05 18:24:39 'night all Jan 05 18:24:39 v sensible. Jan 05 18:24:42 night reenoo_ Jan 05 18:28:01 * france is away: Away Jan 05 19:01:44 okay: http://bugs.openembedded.org/show_bug.cgi?id=577 Jan 05 19:02:27 the source directory for the calibrate program wasn't being specified: it was therefore hit-and-miss as to whether the calibrate binary got copied to the ipkg! Jan 05 19:07:38 monotone: connecting to monotone.vanille.de Jan 05 19:07:38 monotone: network error: failed to connect: Connection refused Jan 05 19:19:26 Luke-Jr: use one of the spare ones. Jan 05 19:19:48 monotone.nslu2-linux.org Jan 05 19:19:58 ewi54.wei.utwente.nl Jan 05 19:20:04 s/54/546 Jan 05 19:27:07 lkcl: spare? Jan 05 19:27:36 nice monotone pull monotone.nslu2-linux.org "org.openembedded.{dev,dreambox}" ? Jan 05 19:27:46 is dev,dreambox still currently correct? Jan 05 19:28:49 monotone: connecting to monotone.nslu2-linux.org Jan 05 19:28:49 monotone: network error: failed to connect: Connection refused Jan 05 19:34:00 yeh, it's correct. Jan 05 19:34:28 make sure you have monotone v 0.24. Jan 05 19:34:49 update your oe.db ---- ah - _don't_ do that, Luke-Jr :) Jan 05 19:34:54 it will take quite literally _days_. Jan 05 19:35:04 follow the instructions on the getting started wiki. Jan 05 19:36:02 talk to pof, in #htc-blueangel he's just trying to do the same as you . Jan 05 19:37:59 he'll point you at the instructions i've just given him. Jan 05 19:38:18 or look on ibot.rikers.org for #htc-blueangel irc logs, tomorrow (after midnight). Jan 05 19:50:32 lkcl: note I have an oe.db already Jan 05 19:50:40 it's only a few days old, I think Jan 05 19:51:13 I have monotone 0.20 Jan 05 19:53:10 why 0.24 instead of 0.25? Jan 05 19:53:33 monotone: warning: discarding revision cert packet ea728072febab8471c31add474a18b864de00bfe with unmet dependencies Jan 05 19:53:38 seems to discard everything new Jan 05 20:58:30 koen|770: nslu2-linux db fixing is going smoothly - we should be up and running with a fixed database in about 6 hours from now. Jan 05 21:53:02 Do somone have an helloworld source for GPE ? Jan 05 22:31:25 does gpe need a helloworld example? Jan 05 22:32:36 http://gpe.handhelds.org/documentation.phtml Jan 05 22:45:55 lol Jan 05 22:46:36 Do somone have an goodbyeunfairworld source for Opie ? Jan 05 22:46:38 =p Jan 06 00:45:04 koen|sleep: ping when you wake up Jan 06 00:47:15 koen|sleep: nslu2-linux database has been rebuilt and is clean and ready for automatic syncing back to OE Jan 06 00:50:11 rwhitby, koen|sleep: it looks good to me Jan 06 00:50:29 rwhitby: what happened to org.nslu2-linux.dev? I've still got all the history. Jan 06 00:50:53 (It should have been in the marsco.db which I scp'ed). Jan 06 01:02:24 jbowler: I started it from scratch Jan 06 01:03:03 (didn't realise you had it in marsco.db, cause it was part of the corruption, so I assumed it had to be rebuilt) Jan 06 01:03:14 there's not much history anyway, so no matter Jan 06 01:04:21 Most of it is in org.openembedded.dev now anyway - that's how the original problem got fixed (the org.nslu2-linux.dev revisions were made part of the OE databases). Jan 06 01:05:25 The thing about them is that they have no branch cert in the OE databases, which is why a 'pull' from a db init produces something broken - the revisions don't get transmitted. Jan 06 01:10:12 OE shouldn't be pulling org.nslu2-linux.dev anyway Jan 06 01:10:21 (it's just the top-level master makefile stuff) Jan 06 01:10:41 so none of org.nslu2-linux.dev should be in org.openembedded.dev Jan 06 01:10:59 (or are we talking about different things?) Jan 06 01:11:25 org.nslu2-linux should be totally orthogonal and non-overlapping with org.openembedded Jan 06 01:11:28 The original problem was that all of it got linked into org.openembedded.dev - as though org.nslu2-linux.dev had been monotone propagated into org.openembedded.dev (though that's not what happened). Jan 06 01:12:08 right, but koen fixed that by getting a version before that happened, right? Jan 06 01:12:39 so there should be none of org.nslu2-linux anywhere in org.openembedded now, correct? Jan 06 01:12:53 (that's why I didn't chance keeping the history of org.nslu2-linux) Jan 06 01:13:00 No, he fixed it by getting everyone to pull a new snapshot. Jan 06 01:13:26 ok, so is our current database on nudi o.k. or not? Jan 06 01:13:34 * rwhitby is now very confused Jan 06 01:13:56 Yes, the nudi database is correct. Jan 06 01:14:19 (That is, it exactly corresponds to the result of following Koen's original instructions). Jan 06 01:14:43 excellent. that's one thing I achieved today then ... Jan 06 01:15:46 I only have five month ahead of converting history... Jan 06 01:50:33 morning Jan 06 02:01:11 good morning Jan 06 02:13:19 morning all Jan 06 02:17:08 good morning RP Jan 06 02:29:46 hey guys, what monotone version is currently used ? Jan 06 02:32:23 0.24 i suppose Jan 06 02:33:05 oki. thanks gremlin[it] Jan 06 02:33:50 at least i'm using 0.24 as client and till yestarday it worked :) Jan 06 02:38:05 gremlin[it]: mmm... any idea of the minimal required version ? Jan 06 02:39:05 0.24 ... i had 0.23 but i had to upgrade to me able to sync Jan 06 02:40:54 strange... i think i used an older version two days ago... i'm doing a fresh install on another mandriva computer and i'm using urpmi as much as i can... Jan 06 02:43:27 alan|laptop: I think you can use older version to sync, but if you use koen's snapshots thats 0.24 and above only **** ENDING LOGGING AT Fri Jan 06 02:59:57 2006