[12:35] <kmon> good night!
[02:01] <hendry> mornfall: ping?
[03:04] <hendry> is it possible to use rsync with the Kubuntu daily ISOs?
[03:05] <hendry> instead of having to download an entire ISO each day
[06:43] <seaLne> hendry: supposedly but it always timed out on me
[07:52] <Hobbsee> well knetworkmanager still doesnt like my uni connection, but it works from the command line...
[08:26] <freeflying> http://www.kdedevelopers.org/node/1868
[08:31] <Tm_T> ugh
[08:32] <Hobbsee> Tm_T: yay!
[08:35] <Mez> beta packages? is that wise?
[08:35] <Mez> when's the next kubuntu meeting?
[08:35] <Hobbsee> Mez: it wasnt decided.
[08:36] <Mez> Hmm :'(
[08:36] <Mez> because I have an idea
[08:36] <Hobbsee> and for a separate repo, probably
[08:36] <Hobbsee> what's your idea?
[08:36] <Mez> well we have all these things that we make for ubuntu - upgraded versions of apps and stuff - and they all just go into the respective people's personal repositorys etc etc (like knm and stuff)
[08:37] <freeflying> Hobbsee: hope can be held at 12:00 UTC
[08:37] <Mez> I'd love to see one central "Kubuntu Developers" Repository
[08:37] <Mez> so that all this stuff we do is available in one place
[08:37] <freeflying> Mez: nice
[08:37] <Hobbsee> Mez: that'd be useful.  i think that that's more or less being done with tonio_'s repo
[08:37] <Mez> rather than having to go and add uber amounts of repositories#
[08:37] <Hobbsee> as in, knm and kpowersave are both there
[08:37] <Mez> yeah but Tonio's the only one who has access to that
[08:37] <Hobbsee> true
[08:37] <Mez> hmm
[08:38] <Mez> ok, it may not be possible now
[08:38] <Mez> but
[08:38] <Hobbsee> i guess the powers that be might be able to create such a thing
[08:38] <Mez> I think I may be able to sort something out
[08:38] <Mez> Hobbsee, I was thinking about PPA's actually
[08:38] <Mez> and wondering whether we'd be able to have a Shared PPA#
[08:38] <Hobbsee> PPA?
[08:38] <Mez> or similar
[08:38] <Mez> Personal Package Archives
[08:38] <Mez> (planned feature of LP + hct)
[08:39] <Mez> (was something we discussed at UBZ - and I talked to Daniel Quite a bit about)
[08:39] <Mez> do you know the concept behind it and hct etc?
[08:40] <Hobbsee> ah right
[08:40] <Hobbsee> oh...i tihnk i'd heard slightly about it - but not really
[08:41] <Mez> well - whenever we develop something - we push it out and it goes to our PPA ... then when say, we want to put something into main - we say "publish this from my PPA into ubuntu main"
[08:41] <Mez> pretty simple concecpt really
[08:41] <seaLne> probably not simple to implement tho
[08:41] <seaLne> sounds interesting
[08:41] <Hobbsee> yep
[08:42] <seaLne> especially if it was integrated with buildd
[08:43] <Mez> seaLne, that's the plan for PPA
[08:45] <seaLne> cool
[08:45] <seaLne> i tried playing about with setting up a buildd but strugled to find enough info
[09:02] <Tm_T> hmm hmm hmm
[09:32] <Hobbsee> hi Lure.  i've concluded that my laptop plain doesnt like the uni network
[09:40] <Lure> Hobbsee: what kind of security they have...
[10:27] <seaLne> anyone know what he means by enabling the highpass filetr? https://launchpad.net/distros/ubuntu/+source/kdemultimedia/+bug/36045
[10:27] <Ubugtu> Malone bug 36045 in kdemultimedia kdemultimedia-kio-plugins "Creating MP3 with IOslave using highpass filter fails" [Normal,Unconfirmed]
[10:27] <seaLne> i presume this is about if you have an audio cd and look at it in konq?
[11:07] <seaLne> hoary -> dapper fails on kaffeine-xine
[11:37] <Riddell> seaLne: what's the error?
[11:38] <Riddell> updates through multiple releases aren't really supported, but if it's easily enough to solve it we should
[11:52] <seaLne> Riddell: https://launchpad.net/malone/bugs/36124
[11:52] <Ubugtu> Malone bug 36124 in kaffeine kaffeine-xine "hoary -> dapper dist-upgrade fails" [Normal,Unconfirmed]
[11:52] <seaLne> kdevelop3 happens hoary -> dapper aswell as to breezy
[11:52] <Mez> Riddell: w00t
[11:53] <Mez> Riddell, the longest standing fixable bug for katapult is now closeable
[11:53] <Mez> (from sources anyways)
[11:53] <seaLne> appart from those hoary -> dapper is fine :)
[11:54] <Mez> WOAH
[11:54] <Mez> my karma is insane
[11:55] <seaLne> hmm actually after dist-upgrade i have no X
[11:56] <seaLne> and /etc/issue wasn't updated
[12:20] <seaLne> Riddell: interestingly my KURLRequestor ruby bug is fine in dapper 3.5.2, i wonder what it was about dapper 3.5.1 and no other 3.5.1 that caused the crash
[12:27] <Riddell> phew :)
[12:36] <seaLne> not as strange as my pc using my pci card as primary graphics until i kick the machine and it uses the agp card (agp isn't even detected without a good kick) :-)
[01:09] <mvo> Riddell: I may have found the problem with the missing kde icons, I'll upload a new app-install-data package later today
[01:09] <Riddell> mvo: what was the problem?
[01:10] <mvo> Riddell: a bug in the handling of packages with epoch seems to have caused it
[01:10] <mvo> do new stuff wasn't properly updated
[02:34] <danimo> hi
[02:34] <Riddell> danimo!
[02:34] <danimo> does anyone else expirience problems with alsa since the latest kernel update on dapper (-19)?
[02:34] <danimo> heya Riddell
[02:35] <danimo> the changelog says it should improve things, but now I have no sound output at all
[02:35] <danimo> (Intel HDA sound device)
[02:36] <Riddell> I'm still on linux -18
[02:36] <danimo> Riddell: hmm, where to file this bug best?
[02:37] <danimo> Riddell: I gotta talk to the guy in charge anyway. HDA support is less than satisfying (in that e.g. skype doesn't work at all, neither does jack autosensing, although latest vanilla should have it)
[02:46] <Riddell> danimo: launchpad.net
[02:46] <Riddell> for bug reporting
[02:46] <danimo> Riddell: ok
[03:55] <hunger> Is audiocd:/ broken in dapper?
[04:01] <freeflying> Riddell: ping
[04:01] <freeflying> Riddell: is cmake ok now ?
[04:02] <Riddell> freeflying: sorry, never had time, will look at it today.  or maybe raphink can do it sooner
[04:03] <raphink> what has to be done?
[04:03] <freeflying> Riddell: ok
[04:03] <freeflying> raphink: http://revu.tauware.de/details.py?upid=2171
[04:03] <raphink> ah
[04:03] <raphink> reviewing ;)
[04:03] <raphink> what is it?
[04:03] <raphink> a bug fix?
[04:04] <freeflying> raphink: http://revu.tauware.de/details.py?upid=2129
[04:04] <raphink> well this one is a NEW package no?
[04:04] <freeflying> raphink: new upstream release , Riddell need it :)
[04:04] <raphink> ah
[04:04] <raphink> for both packages?
[04:05] <freeflying> raphink: the later is for bug fix
[04:05] <raphink> ok
[04:05] <raphink> let me see
[04:05] <Lure> Riddell: 3.5.2 looks good for now
[04:05] <freeflying> raphink: I don't know who upload the later, not the one ion REVU
[04:07] <raphink> freeflying: was the UVFer approved for quarry?
[04:07] <Riddell> Lure: i386 dapper?
[04:07] <Lure> yes
[04:07] <raphink> and if it was, could you put the bug number related to it in the changelog ?
[04:07] <raphink> like : New upstream release (Closes: Malone ... blah)
[04:08] <freeflying> raphink: it's very strange , this one has been uploaded to REVU about 2 weeks , but I found the old release was upload to universe about 3 days ago
[04:08] <raphink> ...
[04:09] <seaLne> raphink: any chance of looking at http://revu.tauware.de/details.py?upid=2160 if you get a chance, its a bug fix
[04:09] <freeflying> raphink: also this package may not in universe ,maybe in restricted , due to some license issue
[04:09] <raphink> seaLne: will do
[04:09] <raphink> it's in universe freeflying
[04:09] <raphink> now there's a weird thing freeflying
[04:10] <raphink> here is what I'd like
[04:10] <raphink> 1) base your new packgae on the current one
[04:10] <raphink> 2) if you got an OK for UVFe, put the bug number inthe changelog
[04:10] <raphink> please
[04:11] <freeflying> raphink: https://launchpad.net/distros/ubuntu/+source/quarry/+bug/35772
[04:11] <Ubugtu> Malone bug 35772 in quarry "installs to /usr/games/bin/" [Normal,Unconfirmed]
[04:11] <raphink> seaLne: could you please quote the patch name in the changelog ?
[04:12] <seaLne> sure
[04:12] <freeflying> raphink: also needd UVFe for cmake ?
[04:12] <raphink> this is a new upstream version so yes
[04:14] <raphink> I don't get the quarry one though
[04:14] <raphink> it's a new upstream based on 0.16-1
[04:14] <raphink> or so it says in the changelog
[04:14] <raphink> the current version in Ubuntu is 0.16-0ubuntu3 though
[04:14] <raphink> it seems we didn't use the Debian version so far
[04:14] <raphink> so why would a new version be based on the Debian package?
[04:14] <seaLne> raphink: anything else for autopsy?
[04:14] <raphink> seaLne: let me see
[04:15] <raphink> malone #35188
[04:15] <Ubugtu> Malone bug 35188 in autopsy "DATA_DIR is incorrectly used instead of DATADIR" [Normal,In progress]  http://launchpad.net/bugs/35188
[04:16] <raphink> did you test the fix seaLne?
[04:16] <seaLne> yep
[04:16] <seaLne> been using it all week
[04:17] <raphink> ok good
[04:17] <seaLne>   * Added 03.caseman_datadir.dpatch to fix DATA_DIR incorrectly used instead of DATADIR in caseman.pm (closes malone #35188) ?
[04:17] <Ubugtu> Malone bug 35188 in autopsy "DATA_DIR is incorrectly used instead of DATADIR" [Normal,In progress]  http://launchpad.net/bugs/35188
[04:18] <seaLne> that better changelog?
[04:18] <raphink> taht's better
[04:19] <raphink> also instead of "udpated standards" you could say "bumped debhelper compat to 5" since this is what you did ;)
[04:19] <raphink> it's clearer
[04:19] <seaLne> was it worth mentioning?
[04:20] <raphink> I think so :)
[04:20] <seaLne> "Updated debhelper compat to 5"
[04:20] <raphink> mhm
[04:21] <freeflying> Riddell: seems no good reson fot cmake UVFe
[04:21] <freeflying> s/fot/for
[04:22] <Riddell> reason is that it's needed by KDE 4
[04:22] <Riddell> does anything else use cmake
[04:22] <raphink> ah KDE4 needs a new version of cmake?
[04:22] <raphink> but then we're not to put KDE4 in Dapper right?
[04:22] <freeflying> Riddell: seems only kde4 need cmake now
[04:23] <raphink> so if we package KDE4 separately, we can put a new version of cmake together
[04:23] <Riddell> freeflying: in that case we do needs an UVF exception since KDE 4 needs that new version o
[04:23] <Riddell> of cmake
[04:24] <freeflying> Riddell: when we package kde4, cmake2.4 may be out
[04:24] <Riddell> amu: ping, do you want CDs for linuxtag or shall I sent them to tackat?
[04:24] <Riddell> freeflying: but in the mean time people will be wanting to compile kde 4 themselves and will expect kubuntu to have a suitable version of cmake for it
[04:25] <freeflying> Riddell: ok
[04:25] <Riddell> actually I didn't realise cmake was already in the archive
[04:28] <amu> to tackat is fine :)
[04:28] <seaLne> raphink: http://revu.tauware.de/details.py?upid=2173
[04:28] <freeflying> Riddell: raphink  done UVFe for cmake and quarry
[04:28] <raphink> approved?
[04:28] <freeflying> raphink: just sent them  :)
[04:29] <raphink> now you have to wait then
[04:29] <raphink> when/if they are approved, please put the bug number in your changelog
[04:30] <raphink> seaLne: let me test build
[04:30] <freeflying> raphink: I'd file bug to motu-uvf
[04:30] <seaLne> thanks
[04:30] <raphink> yes freeflying, assign it to motu-uvf
[04:32] <raphink> ok seems good to me seaLne
[04:32] <raphink> I'll upload
[04:33] <seaLne> ta
[04:38] <raphink> seaLne: uploaded
[04:38] <seaLne> great
[04:39] <freeflying> raphink: shall ping dholbach for UVFe
[04:39] <raphink> can you close the bug please?
[04:39] <raphink> freeflying: no you don't need to
[04:40] <raphink> just assign your bug to motu-uvf
[04:40] <raphink> and wait
[04:40] <freeflying> hmh jut wait
[06:35] <mornfall> Riddell: btw, there is one huge thing with kde on laptops
[06:35] <mornfall> Riddell: after mounting .kde/share/config, .kde/share/konqueror and /var/tmp/kdecache-mornfall my drive actually spins down and stays that way
[06:36] <mornfall> Riddell: by default, typing in url in konqueror causes spurious spinup
[06:36] <mornfall> Riddell: (mounting the abovementioned directories as tmpfs)
[06:36] <mornfall> Riddell: a good hour of difference on batteries, i'd say
[06:38] <hunger> mornfall: /var/tmp/kdecache-* tends to get *very* big here... I would not want that on a tmpfs.
[06:39] <mornfall> hunger: 14M
[06:39] <hunger> mornfall: very big as in bigger than RAM+swap.
[06:39] <mornfall> hunger: probably depends on konqueror cache settings :)
[06:40] <hunger> mornfall: I ran out of space in /var once...
[06:40] <mornfall> but /var/tmp/kdecache-* would probably not cause much problems
[06:40] <mornfall> even if on drive
[06:40] <hunger> mornfall: I link /var/tmp to /tmp now:-)
[06:40] <mornfall> config and konqueror cause the problem
[06:40] <mornfall> hunger: i have /tmp on tmpfs :))
[06:40] <hunger> mornfall: Outch.... /tmp is about 10G here:-)
[06:41] <mornfall> hunger: /tmp is volatile by FHS
[06:41] <hunger> mornfall: /var has oven 2G free now... and those were taken by kdecache.
[06:41] <mornfall> hunger: some distros even rm -rf /tmp/* on boot IIRC
[06:41] <hunger> mornfall: It is... /tmp gets formated on each reboot!
[06:41] <mornfall> hunger: *blink*
[06:41] <mornfall> hunger: what you do with /tmp pretty please?
[06:42] <hunger> mornfall: I encrypt it with a random key, so I have to format it.
[06:42] <mornfall> you run squid for 1000 users? :)
[06:42] <mornfall> oh my
[06:42] <mornfall> anyhow
[06:42] <mornfall> gotta run -- theatre
[06:42] <mornfall> laters
[06:42] <hunger> mornfall: Nope... just store DVD images there till I get round to burn them, that kind of stuff.
[06:42] <mornfall> Riddell: i'll talk to you about the laptop thing later :)
[06:43] <hunger> Is audiocd:/ broken in dapper?
[06:43] <hunger> I have to use that crappy kaudiocreator:-(
[06:45] <Riddell> mornfall: ok
[07:12] <Tonio_> hi all
[07:13] <jjesse> hello Tonio_
[07:28] <jjesse> quite channel, everyone must be either asleep or eating :)
[07:29] <apachelogger> hm
[07:29] <apachelogger> eating is a good idea
[07:29] <apachelogger> AFK
[07:47] <Pygi> Tonio_: ping
[07:47] <Pygi> Lure: around?
[07:48] <Tonio_> Pygi: pong ?
[07:49] <Pygi> Tonio_: I hope you haven't listened to Luka, and remove L-R-M from our repo?
[07:49] <Tonio_> didn't yet ;)
[07:49] <Tonio_> why ?
[07:49] <Pygi> read the mail...
[07:50] <Tonio_> I have 200 mails to read
[07:50] <Tonio_> can you resume quicly plz ?
[07:51] <Pygi> hm, ok ^_^
[07:51] <Pygi> L-R-M patched ones in official repo DON'T WORK
[07:54] <Tonio_> oki ;)
[08:02] <Pygi> Tonio_: and joy...200 mails :-P
[08:08] <Pygi> Lure: read mail...
[08:08] <Lure> Pygi: does it fail in general or just madwifi?
[08:09] <Pygi> well, the patch is for madwifi
[08:10] <Pygi> so madwifi fails ^_^
[08:11] <Pygi> Tonio_: We have patch that should make n-m behave properly about the scanning bug
[08:13] <Tonio_> hum sounds good ;)
[08:13] <Tonio_> is _ion working on it ?
[08:13] <Tonio_> he has ftp access to the repo now
[08:14] <Pygi> ah, ok ^_^
[08:14] <Pygi> we don't have the patch :-S I was wrong ;)
[08:14] <Tonio_> Lure: just read allee's mail
[08:14] <Tonio_> he wonders why we removed vpn from knetworkmanager
[08:14] <Pygi> huh, I answered then for 10 times
[08:14] <Tonio_> why has it been removed from networkmanager first ?
[08:14] <Lure> because there is no VPN in nm
[08:15] <Tonio_> it is a special feature in nm-applet and knetworkmanager then ?
[08:15] <Lure> because core developers said that we should not add features beside wpa
[08:15] <Tonio_> is it calling yast in the first place ? or does it work directly with openvpn/vpnc ?
[08:15] <Lure> no, VPN is part of n-m, GNOME/KDE front-end just provide configuration interface
[08:15] <Tonio_> Lure: okay ;)
[08:16] <Tonio_> we should explain that to allee then
[08:16] <Pygi> Tonio_: gimme his mail, I'll talk to him
[08:16] <Lure> it is hard to explain - we are in FF and adding VPN would just reduce possibility to get n-m in
[08:16] <Pygi> Lure: just gimme his mail
[08:16] <Tonio_> lure do you have the mail ?
[08:17] <Tonio_> still 140 mails.....
[08:18] <Lure> Tonio_: I have replied to that e-mail already and have provided new patches for latest kNM
[08:18] <Lure> I will explain him when/if he gets online
[08:19] <Tonio_> Lure: did you send me the patches ?
[08:19] <Tonio_> I will repackage then
[08:19] <Lure> Yes (around 13:00 CET today)
[08:19] <Lure> I am already using it, and got one crash on connect which I would like to reproduce now with debugs
[08:20] <Pygi> I'll try to contact Robert about the scanning
[08:20] <Lure> Just to be sure that I did not break something with my patches (which I doubt since I do not change anything on connect code)
[08:20] <Lure> Pygi: what is the fix for scanning?
[08:21] <Lure> allee: hi
[08:21] <Tonio_> Lure: so many mails to read......... can you provide me the extracted tarball plz ?
[08:22] <allee> Lure: hi
[08:22] <allee> Lure: nice, did a reboot just before I wanted to leave and ati driver went cracy :(
[08:22] <Tonio_> allee: hello ;) just reading your email
[08:22] <allee> Lure: switching to console back to x fixed it.  Puuuhhhh!
[08:22] <Lure> allee: got my e-mail about kNM and VPN - we had to remove it as Ubuntu NM does not have VPN
[08:22] <allee> Lure: heah, I thought about pkging them  (but lack the time currently)
[08:22] <Lure> allee: I get full hang on logout (100% with fglrx, 20% with ati
[08:22] <Pygi> Lure: no fix for now...I was overreacting...
[08:23] <Lure> Pygi: I would be very happy - but... :-(
[08:23] <Pygi> Lure: heh :-/
[08:23] <allee> Pygi: hi.  I say l-r-modules has a madwifi patch.  It this was you were looking for?
[08:23] <Tonio_> any url for new knetworkmanager tarball plz ?
[08:23] <Lure> Tonio_: where should I put the tarbal?
[08:23] <Tonio_> I'm going to package toonight
[08:24] <Tonio_> Lure<EMAIL_ADDRESS>:) let's do simple
[08:24] <Pygi> allee: L-R-M modules in official repo have madwifi patch, but it doesn't work...we'll look into it later...read the forum
[08:24] <allee> Tonio_: I've none. I stopped last night when the compile failure happened
[08:24] <allee> Pygi: uhm, forum are too much for me :(
[08:25] <Pygi> allee: ah ;-)
[08:25] <Tonio_> Lure: isn't that better to wait for the suse guy to send us up-to-date tarball as he promissed ?
[08:25] <Lure> Tonio_: on it's way...
[08:25] <allee> Anyway.  The highway is waiting for me.  See you later or tomorrow. Bye
[08:25] <Pygi> Tonio_: of n-m or knetworkmanager?
[08:25] <Lure> Tonio_: we can - I do not feel much pressure, but they are now dicussing SVN on freedesktop.org a
[08:25] <Lure> I am concerned that this may take some time...
[08:26] <Tonio_> Pygi: knetworkmanager
[08:26] <Tonio_> Lure: he talked about this WE no ?
[08:26] <Tonio_> we should wait and focussed on that version then, lmaybe
[08:26] <Tonio_> instead of working toonight, and restart everything in three days......
[08:26] <Tonio_> that's my opinion
[08:27] <Tonio_> the most important is n-m
[08:27] <Lure> Tonio_: fine with me - not much new anyway
[08:27] <Tonio_> if it is approved for main, knetworkmanager will follow easilly
[08:27] <Lure> I will test it on my system and see how it goes...
[08:27] <Tonio_> Lure: okay ;)
[08:28] <Lure> allee: bye and safe trip
[08:29] <allee> Lure: thx
[08:55] <Parkotron> kwwii: Are you around?
[09:03] <LeeJunFan> I hate when I spend hours trying to figure something out thinking it's just my setup only to find an actual bug has been documented. hehe
[09:29] <superstoned> riddell: a "kde 3.5.2 works fine for me" from here ;-)
[09:29] <hunger> There are new kde debs?
[09:29] <Riddell> superstoned: version?  arch?
[09:29] <hunger> Why are they not in dapper yet? ;-)
[09:30] <Riddell> hunger: because 3.5.2 hasn't been released
[09:30] <superstoned> riddell: i386, latest from kubuntu.org
[09:30] <Riddell> and because I havn't asked or got an upstream version freeze exception
[09:30] <hunger> Riddell: Ah, that explains it;-)
[09:30] <Riddell> superstoned: dapper?
[09:30] <superstoned> riddell: yes
[09:30] <Riddell> superstoned: excellent, thanks
[09:31] <superstoned> riddell: if such a thing is usefull (hearing a 'works for me(TM)') i can tell you also latest amarok and koffice from beta on kubuntu.org work great ;-)
[09:31] <superstoned> not perfect, sure, had the 'icons disappear' bug a few days ago - once. and kword can crash now and then, but just rarely - its generally very stable.
[09:31] <Riddell> superstoned: thanks, test reports are always useful
[09:31] <hunger> Riddell: koffice-beta and amarok installed fine here, too.
[09:32] <Riddell> hunger: groovy
[09:32] <hunger> Riddell: both seem to work fine, but I have not tested them too thouroughly.
[09:32] <superstoned> i just use them. no probs...
[09:32] <Riddell> installing daily CDs and testing daily-live CDs from cdimage.ubuntu.com is also welcome any time
[09:32] <hunger> Riddell: Maybe koffice could depend on kplato as well?
[09:33] <superstoned> but i can stand a little instabillity, been using beta's, alpha's and even SVN for most apps i run since i started to use linux... didnt switch for stabillity, but for fun :D
[09:33] <hunger> Riddell: It is part of the suite but not installed by default (and pretty nice, too).
[09:35] <Riddell> Tonio_: see that in #ubuntu-meeting?  keybuk expects n-m 0.6 in by next monday
[09:36] <Riddell> hunger: good point, although kplato is only a "technology preview" I believe
[09:36] <Pygi> Riddell: that's not going to be good :-/
[09:38] <Riddell> Pygi: why?
[09:38] <Pygi> Riddell: because the greatest problem of all, disconnects due to constant n-m scanning is still present
[09:41] <Pygi> Riddell: we need to solve that...
[09:42] <Riddell> Pygi: does keybuk know about it?
[09:42] <Pygi> Riddell: probably not...
[09:42] <Pygi> want me to poke him?
[09:42] <Lure> Pygi: it will be no worse than current n-m - why concerned?
[09:42] <Pygi> Lure: yes, but we need to get it right...
[09:42] <Lure> Just more testing and effor tin getting it fixed
[09:42] <Pygi> because USERS do count
[09:43] <Pygi> Lure: no, it has to be fixed
[09:43] <Pygi> Riddell: Do I need to poke keybuk for that?
[09:43] <Riddell> Pygi: he's the n-m maintainer, so yes :)
[09:43] <Pygi> Riddell: kk, will do now ^_^
[09:44] <Lure> Tonio_: we should probably prepare new kNM package (rename + update), just in case
[09:45] <Tonio_> Lure: I will ;)
[09:46] <Tonio_> Riddell: thanks for the info, I'm preparing the new knm package actually
[09:46] <Tonio_> will be on my repo toonight
[09:47] <Pygi> Lure: network-manager-kde should be probably
[09:47] <Lure> yes
[09:47] <Pygi> but I would prefer if we could just call it kde-network-manager & gnome-network-manager
[09:48] <Lure> Pygi: I told you - persuade debian maintainer - it is not our call ;-)
[09:48] <Lure> for package names it make sense to have same prefix, for binary names having gnome/kde first makes more sense (IMHO)
[09:48] <mornfall> re
[09:51] <mornfall> Riddell: the thing is, on my laptop, using konqueror makes drive spinup all the time completely needlessly because of fsyncs of config files
[09:51] <mornfall> Riddell: so i guess that's something very well worth considering
[09:52] <mornfall> Riddell: for dapper+1
[09:52] <Tonio_> _Sime_: ping ?
[09:52] <sebas> mornfall: You could use laptop_mode as a workaround.
[09:53] <mornfall> Riddell: something that puts .kde on a ramdisk and backs it up regularly would be almost perfect i think
[09:53] <mornfall> sebas: how so?
[09:53] <mornfall> sebas: i have laptop-mode-tools
[09:53] <Riddell> mornfall: that sounds quite non-trivial to do
[09:53] <mornfall> sebas: but whatever you do, hardly anything will save you from fsync()
[09:53] <sebas> /proc/sys/vm/laptop_mode
[09:54] <mornfall> Riddell: that's why i say dapper+1
[09:54] <sebas> That keeps dirty data in cache and writes it to disk when reads are done.
[09:54] <sebas> Can save quite some battery power
[09:54] <mornfall> sebas: let me repeat once again
[09:54] <mornfall> sebas: fsync
[09:54] <mornfall> which part you don't understand? :)
[09:55] <mornfall> i of course have laptop mode
[09:55] <sebas> I thought the *exact* point of laptop was to queue those.
[09:55] <mornfall> but laptop mode is sane enough to not turn fsync into noop
[09:55] <mornfall> *sigh*
[09:55] <mornfall> see, normal write operations are obviously postponed
[09:55] <mornfall> sebas:        fsync, fdatasync - synchronize a files complete in-core state with that on disk
[09:56] <sebas> mornfall: I obviously should read my manuals better. :)
[09:56] <mornfall> laptop-mode is useless in presence of regular fsyncs
[09:56] <mornfall> (like syslogd tends to do :)
[09:56] <sebas> Sorry for the ignorance, though
[09:56] <mornfall> but syslogd is easy to resolve
[09:57] <mornfall> konqueror less so -- typing in url triggers fsync here :'(
[09:57] <sebas> Hmm
[09:57] <mornfall> because kconfig fsyncs after write
[09:57] <mornfall> well, at least i think that
[09:57] <Pygi> _ion: k, now the naming thingy ;)
[09:58] <Pygi> why can't we just call it gnome-network-manager & kde-network-manager instead of that...
[09:58] <Pygi> network-manager-gnome & network-manager-kde
[09:58] <_ion> Well, network-manager-gnome was chosen because that's what Debian is going to have AFAIK.
[09:58] <Lure> _ion: exactly
[09:58] <Pygi> o joy
[09:59] <mornfall> sebas: with advancedpowersave (which apparently works nicely for me) turning off wlan, usb, souund and with this tmpfs mod to kde, laptop-mode and some other settings, i can squeeze some 6 hours out of the thing
[09:59] <mornfall> sebas: 4:30 was best i got with default powersave mode
[09:59] <Pygi> Tonio_: pokes....
[09:59] <Pygi> _ion: lemme talk a sec with Tonio_ about ur update...
[09:59] <_ion> pygi: Ok. :-)
[09:59] <sebas> mornfall: What hardware is it?
[09:59] <mornfall> sebas: dell latitude d410
[10:00] <_ion> pygi: I can revert the evil change, if you think so. There are also other changes i listed in the message.
[10:00] <mornfall> ipw2200 for wireless (even the led thingy works now! :-)
[10:00] <sebas> 6 hours is really nice, but that's probably without working on it?
[10:00] <Pygi> _ion: yup, I saw ^_^
[10:00] <Pygi> _ion: nothing is that evil...I think we can get it in...
[10:00] <Pygi> sec pls
[10:00] <mornfall> sebas: well, depends on definition of working -- reading/writing text, irc, web
[10:00] <mornfall> sebas: for development i guess 4 hours will have to do :)
[10:01] <sebas> Still quite OK.
[10:01] <Lure> mornfall: with just one (main) battery?
[10:01] <Tonio_> Pygi:  ?
[10:01] <mornfall> Lure: single (extended) battery
[10:01] <Pygi> Tonio_: are we comfortable with "evil changes" _ion made?
[10:01] <Tonio_> Pygi: didn't saw what he changed
[10:01] <Tonio_> is that on the repo ?
[10:02] <Pygi> Tonio_: no, sec pls
[10:02] <Lure> mornfall: interesting - I have to play a bit too (battery life started to bother me...)
[10:02] <mornfall> it's also very quiet and cool with these settings :)
[10:02] <Lure> mornfall: can you document somewhere what you did?
[10:02] <Tonio_> _Sime_: ping me when you're available plz ^^
[10:03] <mornfall> Lure: hmm :)
[10:03] <mornfall> that would be ... useful
[10:03] <Lure> ;-)
[10:03] <_ion> tonio: I sent an email.
[10:04] <Lure> _ion: did you sent also to Keybuk - he is supposed to push nm 0.6 to main tommorow
[10:04] <Tonio_> _ion: okay
[10:04] <Pygi> _ion: I sent him all...
[10:04] <Pygi> _ion: As far as I am concerned, we can include that...
[10:04] <Pygi> Tonio_: I sent you a pm
[10:04] <_ion> pygi: Ok. I hadn't sent him email.
[10:04] <Tonio_> _ion: according to what I saw, that means that debuild -s -sa && debuild will generate a big diff....
[10:04] <Tonio_> which isn't very convenient
[10:05] <Pygi> _ion: hm, you did ;)
[10:05] <mornfall> Lure: gigabyte of ram really helps keeping the drive in standby, too
[10:05] <mornfall> Lure: but it should be workable with 512
[10:05] <Tonio_> _ion: can go like that but in an ideal world, it is nice when no files get modifyed except with patches
[10:05] <Lure> mornfall: true - have noticed that (I am on 1GB now for 4 months)
[10:06] <_ion> tonio: Hmm  with the change, the diff should be _smaller_ because debian/patches/* don't need to modify the autogenerated files.
[10:07] <_ion> tonio: Or did i misunderstand?
[10:07] <Tonio_> _ion: ok, not sure to really understand what you did in fact
[10:08] <Pygi> _ion: care to explain him?
[10:08] <Tonio_> _ion: in fact you don't change files generated by automake and autoconf
[10:09] <Tonio_> and run auto* via rules
[10:09] <Tonio_> not sure to really understand what does it change
[10:09] <Tonio_> you're cleaning the sources and automate the automake/autoconf usage ?
[10:09] <Tonio_> the problem with this technique is that it can make the package very complicated to maintain
[10:09] <_ion> tonio: In 0.5.1 the patches modify the original files (configure.in, **/Makefile.am) as well as files generated based on them (configure, **/Makefile.in). What i want to do is only modify the originals and let autoconf+automake generate the other files, thus overwriting the generated files that came with the original source. That makes the patches smaller and easier to maintain. But that causes one problem: autoconf and automake overwrite stuff ...
[10:10] <_ion> ... that came in the orig source, so debian/rules clean is unable to really clean the directory to its original state.
[10:10] <Tonio_> _ion: hum.......
[10:10] <Tonio_> doesn't cause real issue technically, and that happens very often with packages in universe
[10:10] <Tonio_> don't know what do the guys expect for main on that point
[10:10] <Tonio_> I would say that's quite okay
[10:11] <_ion> So i thought that maybe put the to-be-overwritten stuff to a tarball before the 'build' phase and put them back during the 'clean' phase.
[10:11] <Tonio_> _ion: nope, we have to keep the tarball untouched
[10:11] <Pygi> Tonio_, _ion: as I already said, it looks fine ... no reason why not to include it...
[10:11] <Tonio_> I would personnaly say that's okay
[10:12] <Tonio_> need asking coredevs on ubuntu-devel to get their opinion
[10:12] <_ion> tonio: network-manager-0.6.1.orig.tar.gz isn't modified.
[10:12] <Tonio_> _ion: I know ;) but you were talking about including modifications to the tarball ;)
[10:13] <Tonio_> _ion: once again, I would say it is okay, but I'm not the bible ;) and maybe the "main" inclusion requires some kind of policy I don't know :)
[10:13] <Pygi> _ion: so build package, and upload it to the repo...ok?
[10:13] <Pygi> Tonio_: for now, it's our repo, no main ;)
[10:13] <Tonio_> _ion: if it was me for example, I would cdbs the package, but well, you were told it was better to only use debhelper....
[10:13] <Tonio_> Pygi: then to me it is nice
[10:14] <_ion> Ok, i'll build and post it.
[10:14] <_ion> backup.tar:
[10:15] <_ion>         tar cf $@ --files-from debian/backup.filelist --remove-files
[10:15] <_ion> This is what happens before the 'build' phase.
[10:15] <_ion> debian/backup.filelist contains lines like "configure", "Makefile.in", "src/dhcp-manager/Makefile.in" etc.
[10:15] <_ion> Those will be overwritten during 'build' by autoconf+automake
[10:15] <_ion> restore:
[10:16] <_ion>                 tar xf backup.tar && \
[10:16] <_ion>                 rm -f backup.tar; \
[10:16] <_ion> That happens during 'clean'.
[10:16] <_ion> So after building the package one can 'debuild -S' and get the _same_ diff.gz
[10:16] <_ion> Not one with all the generated files different from .orig.tar.gz
[10:24] <mornfall> wonderful... even edit-compile-testsuite cycle keeps disk in standby
[10:25] <_ion> pygi, tonio: Ok, i uploaded it.
[10:26] <Pygi> _ion: great ^_^
[10:26] <Tonio_> cool ;)
[10:26] <_ion> http://johan.kiviniemi.name/ubuntu/nm-bugs
[10:27] <_ion> Is the patch listed in the first paragraph helpful?
[10:27] <kmon> does anyone know when the networkmanager community package will enter dapper repo?
[10:27] <Tonio_> _ion: I tried it but as I explained to you, build fails with it
[10:28] <Pygi> Tonio_: we need to fix the patch
[10:28] <Pygi> kmon: well, we'll see ;)
[10:28] <Lure> kmon: maybe tommorow (but may not include everything from test packages)
[10:28] <Tonio_> Pygi: I'm not a C coder...
[10:28] <_ion> Uh, this: http://svn.debian.org/wsvn/pkg-utopia/packages/unstable/networkmanager/debian/patches/timeout.patch?op=file&rev=0&sc=0
[10:28] <Pygi> kmon: we are currently doing it, so wait ;)
[10:28] <Tonio_> I can't fix this
[10:28] <Pygi> Tonio_: I am, but ...
[10:28] <kmon> Pygi: Ok, thanks :)
[10:28] <_ion> tonio: I've been so tired i haven't been able to try to fix it, but i'm going to.
[10:28] <Pygi> kmon: yw ;)
[10:28] <_ion> (The madwifi patch)
[10:28] <Tonio_> _ion: great ;)
[10:29] <Tonio_> sorry for not beeing able to do it myself....
[10:29] <_ion> No problem.
[10:29] <kmon> and are there any news on progress with the kpowersave package?
[10:29] <Tonio_> I can help on several points, but I'm limited concerning this
[10:29] <Pygi> _ion: the l-r-m fail, infinity promised to look into it later...
[10:29] <Pygi> kmon: can't help on that...
[10:29] <Lure> kmon: I plan to look on kpowersave more when we get n-m stabalized a bit
[10:30] <kmon> Lure: Thanxs.
[10:30] <Lure> kmon: but there is still quite some work to play nicer with Ubuntu acpi-support...
[10:30] <Lure> kmon: there was also new kpowersave rc released today - we may want to include soon
[10:31] <kmon> you are doing a great job with kubuntu. (everyone here ;)
[10:31] <mornfall> Lure: working on dapper+1?
[10:31] <Lure> kmon: are you testing kpowersave - is hibernate/suspend working for you?
[10:32] <_ion> pygi, tonio: Have you looked at this patch Lure mentioned? http://madwifi.org/attachment/ticket/462/wext19_060322.patch
[10:32] <kmon> Lure: I've just bought a new laptop. It's the acer ferrari 4005.
[10:32] <Lure> mornfall: no, I would just like to get latest powersave to universe (where it is, but old)
[10:32] <kmon> Unfortunately, it has crappy hw
[10:32] <kmon> and I can't use correct resolution in X without fglrx
[10:32] <Pygi> _ion: please gimme a sec to check it out all,ok?
[10:32] <mornfall> 0.5.10 here
[10:32] <_ion> Sure.
[10:33] <kmon> and AFAIK, fglrx == No hibernate or suspend....
[10:33] <Pygi> _ion: what is it supposed to do anyway?
[10:33] <Tonio_> _ion: very big patch...... will not be easy to maintain ;) but if it works, could be nice to try
[10:33] <kmon> :(
[10:33] <Lure> kmon: ati - see my laptop page for hints (you need to help "ati" driver a bit)
[10:33] <_ion> pygi: Apparently that's supposed to fix the timeout problem with madwifi.
[10:33] <Pygi> Tonio_: yes, I'll look into the code now...
[10:33] <Tonio_> Pygi: I assume that corrects the madwifi signalstrengh issue
[10:33] <Lure> fglrx hibernate/suspend worrks
[10:33] <Lure> better than ati for me
[10:33] <kmon> Lure: Ok, I'll try this weekend
[10:34] <kmon> Lure: I also need to see how can I get apt-get to compile source packages.... never done before
[10:34] <Tonio_> _ion: is it the patch I believe ?
[10:34] <Lure> kmon: see https://wiki.ubuntu.com/LaptopTestingTeam/HPNW8240/Kubuntu
[10:34] <Pygi> _ion: the patch seems not to be finished, but ...
[10:34] <Lure> you do not need to compile anything - Dapper has latest fglrx driver from ATI
[10:35] <Pygi> _ion, Tonio_: I would say go for it...
[10:35] <kmon> Lure: added to bookmarks...
[10:36] <Lure> _ion: I have just noticed it in NM mailing list
[10:36] <Lure> problem is that if I would have madwifi HW, I would test it, but otherwise it is hard to say what impact may have
[10:37] <_ion> Yep.
[10:37] <Pygi> _ion: just go for it...apply the patch
[10:38] <_ion> Could someone else build the l-r-m package? It would take something like a year with my computer. ;-)
[10:39] <Tonio_> _ion: sources ?
[10:39] <Tonio_> hum, sorry, I wasn't in ;) I'm trying to build it
[10:41] <Pygi> Tonio_: on new kernel build, I hope?
[10:41] <Pygi> and btw. we need to make it have bigger version then the one in the official repo if we want people to get updates..
[10:42] <Tonio_> Pygi: okay
[10:42] <Tonio_> Pygi: was just thinking, is it our job to build l-r-m ?
[10:42] <Tonio_> could that be done by the ubuntu maintainer instead ?
[10:42] <Pygi> Tonio_: yes, but not today :-/
[10:42] <Tonio_> Pygi: okay
[10:43] <Pygi> thanks
[10:47] <Pygi> Tonio_, _ion: Ok, this is really, really weird...
[10:47] <Tonio_> Pygi: the patch ?
[10:48] <Pygi> no, not the patch...We've just been reported that the new L-R-M work :-/
[10:48] <_ion> :-D
[10:48] <_ion> Maybe it's magic.
[10:48] <Pygi> _ion: but it's practicly not  possible :-/
[10:48] <_ion> You mean no timeout problem anymore with madwifi?
[10:48] <Tonio_> do I need to build something then ?
[10:48] <Pygi> Tonio_: just you build...
[10:48] <Pygi> _ion: no, the problem where Madwifi fails to recognize WPA abilites of card..
[10:49] <Tonio_> Pygi: plz be clear ;) I'm half drink, alf tired :)
[10:49] <Pygi> Tonio_: k, sorry ^_^
[10:49] <Tonio_> I need clear english actually ^^
[10:49] <_ion> pygi: Oh, that. The patch was included in the package.
[10:49] <Tonio_> half drunk/half tired
[10:49] <Tonio_> sorry ;)
[10:49] <Pygi> _ion: yes, I know...but for some reason it doesn't work for Seveas, and a lot of other people
[10:50] <Tonio_> Pygi: what do I do then ?
[10:50] <Tonio_> if it works, I would suggest nothing but.....
[10:50] <Pygi> Tonio_: just build the package with the patch please ^_^
[10:50] <Pygi> Tonio_: no, it doesn't have anything to do with this patch ;)
[10:50] <Tonio_> Pygi: okay
[10:50] <Lure> Tonio_: there are two issues with madwifi: WPA support and disconnects
[10:51] <Lure> WPA support should be in offical repo, but there was report(s) that it does not work yet
[10:51] <Lure> but there are reports that it works also
[10:51] <Lure> The new patch is supposed to help with disconnect issue
[10:51] <Lure> we want to get it in our test repository for wider testing
[10:52] <Lure> if it helps, great - we will ask infinity for inclusion, otherwise bad luch for madwifi users
[10:52] <Tonio_> Lure: thanks for that clear explanation ;)
[10:52] <Tonio_> building
[10:53] <Pygi> bah, I am not good in explaining..thoughts Tonio_? ;)
[10:53] <Tonio_> I'm just back from the restaurant, and the wine was a bit too good :)
[10:53] <Pygi> Tonio_: please make sure you don't forget to increase version number above from the one in official repos?
[10:53] <Tonio_> Pygi: exactly ;) ^^
[10:53] <Lure> we know that you are french... ;-)
[10:53] <Tonio_> Pygi: no need to increase the version
[10:53] <Lure> (wine and stuff)
[10:53] <Lure> ;-)
[10:53] <Tonio_> when md5sum changes, upgrades are provided anyway
[10:53] <Pygi> Tonio_: ah,kk
[10:54] <Pygi> Lure: so this patch should help with disconnect issues?
[10:54] <Tonio_> Lure: unfortunately yes, I'm french, and loving red wine when going to the restaurant :)
[10:54] <Lure> Tonio_: but offical repo is before ours (in most cases), therefore ours will not be considered
[10:54] <Tonio_> Lure: that doesn't change anything :)
[10:54] <Lure> Pygi: I am not sure - the thread it was discussed was about disconnect issue, and some comments claim that it sould improve
[10:55] <Tonio_> if apt detects an md5sum somewhere in the repos, the update is going on
[10:55] <Lure> Tonio_: I do not get this - if two repos have same package (incl version) - which one will be installed?
[10:56] <Lure> I suspect the first listed in /e/a/sources.list
[10:56] <mornfall> good night
[10:56] <Tonio_> Lure: supposedly the latest modified
[10:56] <Tonio_> but not sure of that :)
[10:56] <Pygi> bah, we'll just have to check ;)
[10:56] <Pygi> if not, you'll be the one increasing version ;)
[11:11] <Pygi> Tonio_: done?
[11:12] <Tonio_> Pygi: nope
[11:12] <Pygi> ah, yes, it takes ages ^_^
[11:12] <Tonio_> the actual source code is COMPLETLY different from the one given by that patch.........
[11:12] <Tonio_> there are things to replace that don't exist in the actual code
[11:12] <Tonio_> I can't merge this patch
[11:12] <Pygi> lol, patch for version 0.6.0 :-/
[11:13] <Pygi> _ion: around?
[11:13] <_ion> pygi: Yep.
[11:13] <Pygi> _ion: we need to port this patch to 0.6.1
[11:13] <_ion> pygi: Ok.
[11:14] <Tonio_> Pygi: the patch supposes a 4200 ieee80211_wireless.c
[11:14] <_ion> Hmm. Which of them? :-)
[11:14] <Pygi> http://madwifi.org/attachment/ticket/462/wext19_060322.patch
[11:14] <Pygi> this one...
[11:14] <Tonio_> our version is 2400 only
[11:14] <Tonio_> I need to replace lines that simply don't exist in our version
[11:14] <Pygi> but I am not sure that this is good...perhaps 0.6.1 already has this?
[11:14] <Tonio_> that means the patch needs LOTS of changes that I can't do myself
[11:15] <Pygi> Tonio_: yes, yes ;)
[11:15] <_ion> That's for madwifi, not n-m.
[11:15] <Tonio_> _ion: yes, I'm in l-r-m actually
[11:15] <Pygi> _ion: ah, yes, sorry ;)
[11:15] <Tonio_> but look by yourself ;)
[11:15] <Pygi> Tonio_: perhaps by joined forces of you, _ion's and me, we could do it?
[11:16] <_ion> I'll look at it later, but i'm not feeling very good now, i need to rest.
[11:16] <Tonio_> Pygi: unless you know kernel code very well ;)
[11:16] <Tonio_> Pygi: example, line 3929
[11:16] <Pygi> _ion: k, rest ^_^
[11:16] <Tonio_> (iw_handler) in the line to be replaced
[11:17] <Tonio_> Pygi: this complete portion of code misses in our version.......
[11:17] <Tonio_> not only one line, but the complete section......
[11:17] <Pygi> 3929 in the patch?
[11:17] <Tonio_> 3929
[11:17] <Tonio_>
[11:17] <Tonio_>         (iw_handler) NULL,                             /* -- hole -- */
[11:17] <Tonio_> this
[11:17] <Pygi> ah
[11:18] <Pygi> 3929	                return -error;
[11:18] <Tonio_> that simply doesn't exist in our source code
[11:18] <Pygi> this is what I saw in a patch, so :-P
[11:18] <Pygi> hm, you sure you got the right patch? ^_ ^
[11:18] <Tonio_> not in the text version of the patch ;)
[11:18] <Tonio_> on the webpage
[11:18] <Pygi> to me line 3929 is 3929                 return -error;
[11:18] <Pygi> and yes, on the webpage
[11:19] <Tonio_> hu ????????
[11:19] <Pygi> http://madwifi.org/attachment/ticket/462/wext19_060322.patch
[11:19] <Pygi> are you lookin' at this or?
[11:19] <Tonio_> yes
[11:19] <Tonio_> look at the first line :)
[11:19] <Tonio_> first column, "old", not the second "new"
[11:19] <Pygi> }  ???
[11:20] <Tonio_> there are two columns for the line numbers
[11:20] <Pygi> yes, I see that ;)
[11:20] <Tonio_> then search for old "3929"
[11:20] <Pygi> o, joy ;)
[11:20] <Pygi> found it, sorry :-P
[11:21] <Tonio_> yes ;)
[11:21] <Pygi> hm, so l-r-m aren't correct :-/
[11:21] <Tonio_> that portion of code doesn't exist in our actuall source code.... so patching this will be a weired job
[11:21] <Tonio_> we miss about 1200 lines compared to the file the patch refers
[11:21] <Tonio_> means about 30% of code missing
[11:22] <Pygi> yes :-/ the question is why do we miss that code?
[11:22] <Pygi> that's a hell of a diff :-/
[11:22] <Tonio_> yes
[11:22] <Pygi> hm, what about making diff, applying to our version, and then patching with this patch? :-/
[11:22] <Tonio_> and when I'm drunk, that horribly hard to adapt that kind of patch ^^
[11:23] <Tonio_> Pygi: means we don't have only one file to diff, but I think the complete madwifi section
[11:23] <Pygi> yes, I know...
[11:23] <Tonio_> if that file is outdated, about all files of the driver source will be........
[11:23] <Pygi> and the question really is, why do we miss so much code...
[11:24] <Tonio_> Pygi: outdated madwifi ?
[11:24] <Pygi> yes, we probably have outdated madwifi :-
[11:24] <Pygi> :-/
[11:27] <Pygi> Tonio_: this is BIG :-/
[11:27] <Tonio_> yup...
[11:27] <Pygi> hm, come to #ubuntu-devel pls
[11:34] <Pygi> Tonio_: as keybuk suggested, maybe it's patch for -ng?
[11:35] <Tonio_> Pygi: for what ?
[11:35] <Pygi> Tonio: for madwifi -ng
[11:35] <Tonio_> and where the package is ?
[11:36] <Tonio_> do we have it ?
[11:36] <Pygi> we cannot use madwifi -ng
[11:36] <Pygi> it's unstable
[11:36] <Tonio_> k
[11:36] <Tonio_> so there is no solution
[11:37] <Pygi> seems like it :-/
[11:39] <Pygi> Tonio_: any suggestions? :-/
[11:40] <Tonio_> unfortunately no........
[11:42] <Pygi> hm :-/
[11:44] <Pygi> Tonio_: we have to think more :-/
[11:45] <Tonio_> Pygi: as I don't code, I can't help on that point....
[11:45] <Tonio_> I can help on the packaging part, but that's all
[11:45] <Pygi> I can code, but I don't see what I can do here :-/
[11:46] <Tonio_> :/
[11:46] <Lure> Tonio_: I can code, but I have coding if I cannot test (no madwifi HW)
[11:47] <Lure> s/have/hate/
[11:47] <Pygi> Lure: no point in coding here... what would you code actually? ;-/
[11:47] <Lure> there is part of the patch that I consider of interest (at the end)
[11:47] <Pygi> Lure: that patch is for madwifi -ng
[11:47] <Pygi> we are missing a lot of code
[11:47] <Pygi> and we cannot apply a diff, as diff is from the -ng
[11:52] <Lure> Pygi: why do you think is for -ng
[11:52] <Pygi> cause it says "trunk"
[11:52] <Pygi> it's -ng
[11:52] <Lure> did you check the bug report: http://madwifi.org/ticket/462
[11:52] <Pygi> btw. you posted this
[11:52] <Pygi> I am glad you confirmed that WPA works with latest L-R-M and madwifi - there was some concern that patch was not taking the effect.
[11:52] <Pygi> and he was the only one that reported it works...
[11:52] <Pygi> for none else it worked...
[11:52] <Lure> NeoChaosX also confirmed
[11:53] <Lure> no other report in forums of not working
[11:53] <Pygi> yes, but that is due to older l-r-m already there
[11:53] <Pygi> not in forums, but mails and irc
[11:53] <Lure> it was camelreef reporting failure and then success
[11:54] <Pygi> ah
[11:54] <Lure> who reported on mail and irc (have not seen those)?
[11:54] <Pygi> Seveas for example
[11:55] <Lure> Pygi: I do not think older l-r-m can be an issue - the version changed therefore it cannot be picked up from old directory
[11:55] <Pygi> yes, but local changes remain
[11:55] <Pygi> nah, I am telling that older l-r-m help
[11:55] <Lure> I though Seveas is testing NM from cvs (WPA enterprise)
[11:56] <Lure> Pygi: it cannot help, because /lib/modules/<version> is different (-18 vs. -19)
[11:56] <Lure> it could help only if -xx would not change (like 2.6.15-19.29)
[11:56] <Pygi> ah
[11:57] <Lure> Can you check with Seveas again (not sure if he is online) just to be sure
[11:57] <Lure> I have seen his posts to NM mailing list today and I thought that he is testing bleeding edge currently
[11:58] <Pygi> Lure: please address the new post in forum if you have time?
[11:58] <Lure> will check - actually Seveas is just discussing the topis in #u-devel
[12:00] <Pygi> Tonio_, Lure: please keep me updated on the matter throught mail
[12:00] <Pygi> I have to go now
[12:01] <Lure> Pygi: ok - bye
[12:01] <Pygi> Lure: the conclusion of #u-devel or somethin...please send it to me