[12:17] <zyga> whiprush: stars source: changelog-should-mention-nmu
[12:17] <zyga> whiprush: stars source: source-nmu-has-incorrect-version-number 0.12+1-2
[12:17] <zyga> hmm, how should I fix this?
[12:17] <zyga> whiprush, sorry W: got expanded to your username
[12:20] <Amaranth> i believe you can ignore those
[12:20] <Amaranth> but lintian -v might tell more
[12:20] <LaserJock> zyga: nmu warnings don't apply to Ubuntu, they are for Debian
[12:21] <zyga> okay
[12:21] <StevenK> It's Lintian being brain-dead.
[12:21] <StevenK> As per usual.
[12:21] <zyga> https://launchpad.net/distros/ubuntu/+source/stars/+bug/36451
[12:21] <Ubugtu> Malone bug 36451 in stars "stars - No .desktop file installed" [Minor,Confirmed] 
[12:21] <zyga> I hope I did this right
[12:21] <LaserJock> somebody (I can't remember who at the moment) was going to perhaps hack up an Ubuntuized lintian to get rid of that stuff and add some checks for ubuntu specific things
[12:23] <LaserJock> zyga: I'm not sure about bumping the Standards-Version even though I know lintian complains about it
[12:23] <minghua> StevenK: hey, linda in dapper still complains about "no suitable .mo file" for everything ;-)
[12:24] <LaserJock> I haven't seen linda complain about much of anything other that that :(
[12:24] <minghua> zyga: don't user version number 0.12+1-2, use 0.12+1-1ubuntu1 instead
[12:25] <LaserJock> doh, I didn't catch that
[12:25] <ToadZzZztool> LaserJock:  i've got a debdiff that disables lintian nmu checks if y'ou don't specify -D or --debian on the commandline
[12:25] <StevenK> minghua: Paul Sladen did that upload.
[12:25] <minghua> zyga: and you should set the distribution to dapper instead of unstable (use dch -D dapper)
[12:25] <StevenK> minghua: If I had any hope, I'd ask for Linda 0.3.20 to be thrown into dapper.
[12:26] <zyga> thanks
[12:26] <minghua> StevenK: yes, he tried to fix that, 0.3.17 complains the same thing
[12:26] <minghua> StevenK: but I know you are busy
[12:26] <LaserJock> I don't really know what linda does that lintian doesn't?
[12:27] <zyga> how come debuild cannot find my private key?
[12:27] <StevenK>     - Install .mo files under linda.root instead of under locales. This
[12:27] <StevenK>       mainly fixes Linda breaking when localepurge is run. (Closes: #354764)
[12:28] <minghua> zyga: and if you bump standard version, mention it in the changelog (I personally won't touch standard version)
[12:28] <zyga> okay
[12:33] <zyga> http://librarian.launchpad.net/1834977/my.debdiff
[12:33] <zyga> better patch
[12:34] <ToadZzZztool> LaserJock: bug 36505 with a debdiff to get rid of nmu checks
[12:34] <Ubugtu> Malone bug 36505 in lintian "Ubuntu Lintian shouldn't do the nmu checks" [Wishlist,Unconfirmed]  http://launchpad.net/bugs/36505
[12:34] <Toadstool> well i can't sleep :)
[12:36] <LaserJock> Toadstool: cool
[12:36] <LaserJock> well, not the "can't sleep" part
[12:36] <Toadstool> ;)
[12:37] <Toadstool> what kind "ubuntu specific things" are there for lintian ?
[12:37] <zyga> could somebody please look if my patch is fine? I'd like to take a look at another package
[12:37] <Toadstool> wow I can't sleep but I can't write english too tonight...
[12:37] <LaserJock> checking for "dapper" for instance or maybe ubuntu versioning
[12:38] <Toadstool> well, I think I can give it a try
[12:47] <Toadstool> that'll take a little more time than disabling nmu check :)
[12:48] <zyga> okay I'm looking after another package - no point to wait
[12:50] <LaserJock> zyga: do you know how validate .desktop files?
[12:51] <zyga> LaserJock: no but I know their syntax pretty well, I patched/rewrote pyxdg with regards to .desktop files
[12:51] <zyga> I probably should have included version marker, right?
[12:52] <LaserJock> I'm not very knowledgable so I use "desktop-file-validate"
[12:53] <zyga> I'll check it out
[12:53] <zyga> no bugs thus far
[12:53] <zyga> nice, I didn't know of this tool
[12:54] <Amaranth> it's handy
[12:54] <Amaranth> i once ran it over every .desktop on my HD to report bugs
[12:54] <Amaranth> but when i realized i'd have to figured out what package provides what and file seperate bugs for each one i gave up
[12:55] <zyga> hm
[12:55] <LaserJock> Amaranth: wouldn't dpkg -S do that?
[12:55] <Amaranth> i suppose with dpkg -S and launchpad's mail interface you could automate it
[12:55] <minghua> dpkg -S and apt-cache showsrc should give you the source package name you need
[12:57] <zyga> oh a package uses dpach
[01:01] <crimsun> the great and wond'rous bddebian.
[01:02] <zyga> guys, what is an .applications file?
[01:02] <bddebian> Hi crimsun.  Do you like making me feel bad? :-)
[01:02] <yves> hi all!
[01:02] <bddebian> zyga: Some type of gnome application definition?
[01:02] <zyga> hmm
[01:06] <bddebian> ANyone know if there would be any issues with me building a package for Debian on Ubuntu?
[01:07] <zyga> hmm, might be
[01:07] <zyga> c++ abi?
[01:07] <bddebian> Ah yes..Hmm
[01:08] <minghua> unstable and dapper have the same C++ ABI AFAIK
[01:09] <yves> would you guys please review http://revu.tauware.de/details.py?upid=2182 ? :-)
[01:09] <minghua> python version and X file layout seem to be the most wide spread issue now
[01:09] <bddebian> Well fudge.. My Debian box is dead :-(
[01:09] <zyga> minghua: python 2.3 in debian!?
[01:11] <yves> what's sid default python version? 2.4?
[01:11] <crimsun> bddebian: you know I'm just joshin'
[01:11] <crimsun> yves: still 2.3 afaik
[01:11] <yves> strange
[01:11] <zyga> argh
[01:11] <zyga> 2.4 has lovely features
[01:12] <bddebian> crimsun: No, you hate me :-)
[01:12] <yves> some people say ubuntu developers are not being very "quick" when sending improvements back to debian
[01:12] <crimsun> bddebian: I build packages from sid in my dapper pbuilder constantly. I mostly have to adjust python and debhelper versioned build-deps
[01:18] <ajmitch> hi
[01:18] <bddebian> Heya ajmitch
[01:18] <LaserJock> hi ajmitch bddebian crimsun and nictuku
[01:18] <ajmitch> bddebian: use a sid chroot
[01:18] <bddebian> Hi LaserJock
[01:18] <nictuku> hello LaserJock
[01:18] <zyga> two packages down lots more to go :-)
[01:19] <crimsun> 'lo LaserJock
[01:22] <Toadstool> LaserJock: about the lintian-checking-for-"dapper" thing dholbach already implemented it
[01:24] <LaserJock> Toadstool: cool
[01:27] <LaserJock> and another bug bites the dust ;-)
[01:28] <Toadstool> :)
[01:29] <LaserJock> It is much faster when you get to reject bugs :-)
[01:29] <bddebian> Go LaserJock, go! :-)
[01:31] <LaserJock> well, MOTU Science still has a little under 100 bugs assigned or subscribed :(
[01:32] <LaserJock> although about half of them are .desktop bugs ;-)
[01:35] <LaserJock> umm, do we have a m68k arch?
[01:35] <crimsun> (no)
[01:35] <ajmitch> no, thankfully
[01:35] <ajmitch> and don't tempt infinity to start one
[01:36] <crimsun> I love when people describe themselves as "unix gurus"
[01:36] <ajmitch> heh
[01:37] <LaserJock> ok, so malone 25232
[01:37] <Ubugtu> Malone bug 25232 in mpfr "mpfr_2.2.0.dfsg.1-2_m68k: FTBFS: 2 of 117 tests failed" [Major,Unconfirmed]  http://launchpad.net/bugs/25232
[01:38] <ajmitch> imported from debian?
[01:38] <LaserJock> the Debian bug has been closed and the present Ubuntu package builds on all our archs
[01:38] <ajmitch> get rid of it
[01:38] <LaserJock> should I close both tasks?
[01:38] <ajmitch> yes
[01:38] <LaserJock> and another one bites the dust ;-)
[01:38] <ajmitch> reject the ubuntu one, since we don't have m68k
[01:39] <Amaranth> LaserJock: pfft
[01:39] <Amaranth> i'm down to 0 pyxdg bugs and (at most) 1 alacarte bug that i'm worrying about for dapper
[01:39] <Amaranth> :)
[01:39] <ajmitch> Amaranth: good, start fixing other bugs
[01:39] <Amaranth> ajmitch: I moved on to working on alacarte 0.9
[01:40] <truz24> Do most of you guys fix these bugs after you get off work?
[01:40] <Amaranth> it's hopefully going to use gmenu instead of pyxdg, so far it shows all the same stuff (but doesn't do anything)
[01:40] <zyga> truz24: I'm after work ;] 
[01:40] <Amaranth> and it starts up in less than a second
[01:40] <Amaranth> which is a huge win
[01:40] <crimsun> well, work never really lets up here
[01:40] <zyga> but I don't fix many bugs... hardly ever actually
[01:42] <Amaranth> i go to school and work on websites for the school's intranet, i do all this stuff after that
[01:44] <truz24> so are most of the bugs configuration or coding bugs that we are fixing here?
[01:45] <crimsun> some of both
[01:48] <truz24> has anyone noticed the flash plugin for firefox doesn't show some text.  Has anyone been able to determine if its a macromedia bug, or a font issue in ubuntu?
[01:50] <softwarecommie> I read somewhere that that could be fixed by installing some win fonts
[01:50] <softwarecommie> but I have never actually found a fix for it
[01:50] <crimsun> which gsfonts\* are installed?
[01:51] <truz24> stock fonts are installed
[01:51] <truz24> from the drapper install
[01:51] <ajmitch> bddebian: instead of complaining about not fixing anything, just do it :)
[01:51] <crimsun> so...just don't fix anything? ;)
[01:52] <softwarecommie> haha
[01:52] <bddebian> ajmitch: I can't fix anything :-)
[01:52] <ajmitch> crimsun: I believe you misinterpreted
[01:52] <ajmitch> bddebian: oh shut up :P
[01:52] <crimsun> ajmitch: oh I did purposely =)
[01:53] <softwarecommie> one thing many people have trouble with is figuring out where to start on fixing things
[01:53] <crimsun> mmm bug triaging == good start
[01:53] <softwarecommie> myself being one such person
[01:53] <ajmitch> I rebuilt all those unmet deps packages last night, now I just have to sort out which were fixed by a simple rebuild
[01:54] <zyga> https://launchpad.net/distros/ubuntu/+source/pymol/+bug/36435
[01:54] <minghua> switching MTA around is not fun :-(
[01:54] <Ubugtu> Malone bug 36435 in pymol "pymol - No .desktop file installed" [Minor,Unconfirmed] 
[01:54] <zyga> another one down? :)
[01:55] <bddebian> ajmitch: :-)
[01:55] <crimsun> bug #5343
[01:55] <Ubugtu> Malone bug 5343 in lirc "can`t build lirc-modules-source with kernel 2.6.15" [Major,Needs info]  http://launchpad.net/bugs/5343
[01:55] <minghua> truz24, softwarecommie: yes, I've heard the same thing.  the MS core fonts has a (installer) package
[01:56] <truz24> So I assume this fonts package cannot be installed by default legally?
[01:56] <minghua> you can install it legally, you just can't package it legally
[01:57] <truz24> k
[01:57] <bddebian> fsck, an OOo upgrade, I hate those :-(
[01:58] <zyga> bddebian: I remember posting a request for oo-less ubuntu-desktop metapackage ;] 
[01:58] <softwarecommie> OOo upgrades are not as painful as unsuccessful fsck's though
[02:00] <softwarecommie> perhaps the Win fonts should be included in default setup
[02:00] <softwarecommie> because inability to see text in Flash is pretty common
[02:00] <softwarecommie> and awefully annoying
[02:00] <zyga> inability to install flash is even more annoying
[02:01] <softwarecommie> aye
[02:04] <zyga> guys
[02:04] <zyga> 0.5.1-2 -> ubuntunized -> 0.5.1.2ubuntu1 right?
[02:05] <crimsun> 0.5.1-2ubuntu1
[02:05] <crimsun> is this a sync or a Ubuntu modification?
[02:05] <zyga> ubuntu modification to improve desktop file
[02:06] <crimsun> right, 0.5.1-2ubuntu1 then
[04:27] <nictuku> hi
[04:28] <Hobbsee> StevenK: want to jump on someone for me?  :P
[04:28] <nictuku> I'll apply to be a ubuntu member in the next CC and I need a good "peer review"
[04:29] <nictuku> if any of you guys know me enough, and know my work for nwu, could you please write a very small testimonial about what you think, in my wiki profile?
[04:31] <crimsun> actually it's preferable to link to your work on revu
[04:31] <crimsun> that really will be more effective than static testimonials
[04:31] <nictuku> nice
[04:46] <dolson> hmm, very strange. I just had that same extreme slowdown behaviour, but this time it didn't last nearly as long... I was receiving new mail in Evolution at the time. I tried logging into a virtual console, no go. I switched back to X after a bit, and waited a bit, and the usage is back down to 0%.
[04:46] <dolson> and now, I see spamd listed as a Zombie process in gnome system monitor...
[04:49] <dolson> and my memory + swap usage is still at 100%, with Evolution leading the pack
[04:54] <crimsun> crap, I still need to look at that defaults.{pcm,ctl}.card issue
[04:55] <dolson> I wonder if this is a bug in evolution, evolution-data-server, or spamassain or something else.. it points to one of those three though.. 1GB of RAM and 500MB of swap should not be in use entirely by those 3 apps
[04:57] <crimsun> sheesh, this machine only has 512 MB of RAM, and it hits swap pretty consistently with my workload
[04:58] <dolson> three times that in use by evolution is just insanity though
[05:07] <nictuku> how can I send a patch to #26601?
[05:07] <nictuku> it's a oneliner
[05:07] <nictuku> Ubugtu, bug #26601 ?
[05:07] <Ubugtu> Malone bug 26601 in bittornado bittornado-gui "btdownloadgui crashes on startup" [Normal,Unconfirmed]  http://launchpad.net/bugs/26601
[05:08] <dolson> https://launchpad.net/distros/ubuntu/+source/bittornado/+bug/26601/+addattachment
[05:08] <Ubugtu> Malone bug 26601 in bittornado bittornado-gui "btdownloadgui crashes on startup" [Normal,Unconfirmed] 
[05:09] <nictuku> thanks
[05:09] <ajmitch> crimsun: I disabled swap on here, currently got about 50% RAM in use by apps, the rest buffer+cache
[05:11] <nictuku> I wrote a comment to the bug but it didn't appear, is that expected?
[05:11] <ajmitch> no
[05:12] <nictuku> worked now
[05:14] <nictuku> 0.3.13-1ubuntu1 +1 = 0.3.13-1ubuntu2 or 0.3.13-2ubuntu1 ?
[05:16] <dolson> the former
[05:16] <Hobbsee> nictuku: the former
[05:17] <nictuku> any wiki page with ubuntu way's for a changelog? I've seen there's a new changelog proposal being discussed, but how should the changelog look right now?
[05:19] <minghua> nictuku: dch -i is your friend (although it makes mistake sometimes) :-)
[05:20] <nictuku> ok, but should I use "(Closes: #1)" or just say "bittornado-gui depending on old version of bittornado" ?
[05:22] <Hobbsee> closes malone #12345
[05:22] <Ubugtu> Malone bug 12345 in isdnutils "isdn does not work, fritz avm (pnp?)" [Normal,Fix released]  http://launchpad.net/bugs/12345
[05:22] <Hobbsee> i think
[05:23] <nictuku> seems so
[05:23] <nictuku> http://no-name-yet.com/changelogs/pool/main/x/xorg/xorg_7.0.0-0ubuntu17/changelog
[05:24] <nictuku> actually "Closes: malone #number"
[05:25] <Hobbsee> ah
[05:25] <Hobbsee> that's right
[05:28] <minghua> I think the close-bug format in changelog is still not decided yet
[05:29] <minghua> and before it's decided I suppose any one is as good as another
[05:29] <nictuku> I thought soo, too
[05:43] <nictuku> fix done. Now I dput it?
[05:44] <nictuku> or attach a patch to the bug?
[05:50] <nictuku> I'll send it to revu. I hope I'm not commiting a crime =] 
[05:57] <minghua> a problem with ubuntu package version numbers is that they are usually too long for you to see in the aptitude ncurses UI :-(
[05:58] <nictuku> http://revu.tauware.de/details.py?upid=2184
[05:59] <nictuku> oops
[05:59] <nictuku> bittornado is nnow main
[05:59] <Se7h> nictuku erase CVS dirs
[06:00] <nictuku> it was in the package already.. I didn't want to mess with it too much
[06:00] <Se7h> http://sauerbraten.org/ <- this would be a nice game to have :)
[06:00] <Se7h> nictuku remove it anyway
[06:01] <nictuku> ok
[06:01] <Se7h> lets try the game...
[06:02] <minghua> I wouldn't remove the CVS dirs if it's in .orig.tar.gz
[06:02] <nictuku> hmm good point
[06:02] <Se7h> why not?
[06:03] <nictuku> the package already "removes" them
[06:03] <nictuku> dpkg -c bittornado-gui_0.3.13-1ubuntu2_all.deb ... shows no CVS
[06:04] <Se7h> good
[06:04] <minghua> Se7h: because it changes the .orig.tar.gz, which means you need to pick up new upstream version number
[06:05] <minghua> Se7h: and not to mention unnecessary diverge from Debian (I assume bittornado is in Debian)
[06:05] <monzie> hi hard-working motu's
[06:06] <nictuku> hi monzie !
[06:06] <nictuku> minghua, it is
[06:06] <monzie> hi nictuku
[06:13] <LaserJock> hi monzie
[06:13] <bddebian> Gnight folks
[06:14] <LaserJock> cya bddebian
[06:14] <minghua> night bddebian
[06:14] <minghua> and hi LarstiQ
[06:14] <minghua> oops, hi LaserJock
[06:16] <LaserJock> lol, hi minghua
[06:18] <Gloubiboulga> morning
[06:18] <Erlang> g'evenin'
[06:21] <LaserJock> minghua: I noticed 2 people unsubscribed from ubuntu-science after the .desktop blitz
[06:21] <minghua> LaserJock: good for them, perhaps :-)
[06:22] <LaserJock> lol
[06:25] <monzie> hi LaserJock
[06:34] <Hobbsee> crimsun: i'm getting sick of damn morons in #ubuntu and #kubuntu using the exploit, cos one guy got banned by accident for it
[06:34] <crimsun> yeah, it's a bit more...automated in #ubuntu ;)
[06:34] <Hobbsee> yes, even for legitimate cases
[06:34] <Hobbsee> unfortunately
[06:36] <Se7h> btw
[06:36] <Erlang> exploit?
[06:36] <Se7h> will xgl be a default for some future version ?
[06:36] <monzie> how good is xgl? anyone here who uses it?
[06:37] <Se7h> i havent tested it myself, but i know loads of people using it
[06:38] <LaserJock> Hobbsee: what exploit?
[06:38] <ajmitch> Hobbsee: the dcc one?
[06:38] <Hobbsee> LaserJock: *rolls eyes* - were you not here a few weeks ago?
[06:38] <Hobbsee> yes
[06:43] <nictuku> welcome back
[06:44] <LaserJock> wb minghua
[07:08] <minghua> nice crash...
[07:12] <LaserJock> minghua: bummer
[07:13] <minghua> LaserJock: yeah, morale of story:  don't use a KDE input method daemon in GNOME :-)
[07:15] <LaserJock> minghua: lol, I don't have to worry about that
[07:23] <Se7h> omg
[07:23] <Se7h> this is just a beauty
[07:23] <Se7h> (xgl)
[07:24] <Unfrgiven> LaserJock: ping
[07:25] <LaserJock> Unfrgiven: pong!
[07:25] <LaserJock> Unfrgiven: hi!
[07:25] <Unfrgiven> LaserJock: how r u?
[07:25] <Se7h> not that good to play tho
[07:25] <LaserJock> Unfrgiven: good, pretty busy
[07:26] <Unfrgiven> LaserJock: ive just done a bigish change to the Getting Started section of the packaging guide
[07:26] <Unfrgiven> LaserJock: wanted to get you to have a look....
[07:26] <Unfrgiven> LaserJock: just doing an svn update now... will need to resolve merges first
[08:25] <minghua> crimsun: are you always in #ubuntu and #ubuntu+1 answering questions?
[08:25] <crimsun> minghua: essentially.
[08:27] <LaserJock> me too. I try but it just gives me a headache. I can't track conversations in there very well :(
[08:27] <LaserJock> plust I'm not nearly as helpful as crimsun
[08:28] <crimsun> don't worry, it's not a feat, more like a crutch ;)
[08:30] <na7e-> seems like crimsun just pops out of nowhere with an end-all answer all the time
[08:31] <na7e-> i likey
[08:40] <Kyral> Night all
[08:40] <crimsun> 'night, Kyral
[08:40] <Kyral> mmm...back to GNOME goodness
[08:40] <LaserJock> yeah, I gotta get to bed too
[08:40] <LaserJock> cya all
[08:41] <Kyral> Though tomorrow I compile Gaim 2.0 lol
[08:41] <crimsun> 'night, LaserJock
[10:06] <siretart> morning
[10:06] <siretart> crimsun: around?
[10:06] <ajmitch> morning siretart
[10:07] <siretart> hey ajmitch
[10:07] <siretart> how are you?
[10:08] <ajmitch> good, how are you?
[10:09] <siretart> finally passed my last exam, now I can finally catch up my ubuntu and other work :)
[10:09] <ajmitch> great!
[10:09] <siretart> :)
[10:09] <ajmitch> just fixing up another python2.3 -> 2.4 that we got from debian
[10:10] <Toadstool> 'morning here
[10:11] <ajmitch> and I should really get working on main as well
[10:15] <ajmitch> wow, my karma crashed back down :)
[10:30] <ajmitch> hi raphink
[10:30] <raphink> hi ajmitch :)
[10:34] <raphink> how are you today ajmitch?
[10:37] <ajmitch> good :)
[10:37] <raphink> hehe
[10:37] <raphink> ;)
[10:37] <ajmitch> laptops are very useful
[10:38] <raphink> indeeed
[10:38] <raphink> till  you put some tomato sauce on them and they're not useful anymore ;)
[10:39] <ajmitch> haha
[10:41] <ajmitch> unmet deps list is thankfully quite short compared to what I've seen in the past :)
[10:42] <ajmitch> only ~120 or so source packages
[10:46] <raphink> hehe
[10:52] <StevenK> ajmitch: Wanna hand?
[10:52] <ajmitch> StevenK: go ahead ;)
[10:53] <StevenK> Where be the list?
[10:53] <ajmitch> apt-cache -i unmet
[10:53] <ajmitch> I need a faster box
[10:54] <ajmitch> wb raphink
[10:54] <ajmitch> StevenK: either that or work through the 10K open bugs on malone
[10:54] <raphink> thanks :)
[10:54] <raphink> suspend works again on my ppc :D
[10:55] <ajmitch> StevenK: I just wanted to go for the really low-hanging fruit - those packages where a simple rebuild will fix them
[10:55] <ajmitch> so I rebuilt the list of unmet deps on my box last night
[10:56] <StevenK> ajmitch: The ones where you can do five to seven in an hour, and feel good about helping.
[10:56] <ajmitch> yeah
[10:56] <ajmitch> I've done 4 now :)
[10:56] <ajmitch> it's an easy way for me to get back into MOTU work
[10:56] <ajmitch> before I start on the depressing bugs ;)
[10:57] <StevenK> Heh
[10:58] <ajmitch> sure
[10:58] <ajmitch> just pay dholbach, siretart & slomo_ enough cash
[10:58] <StevenK> All three?
[10:58] <ajmitch> yeah
[10:58] <Tonio_> morning all :)
[10:59] <ajmitch> so just send 1 cheque to germany & get someone to split it 3 ways :)
[10:59] <StevenK> Hah
[10:59] <ajmitch> hi Tonio_
[10:59] <Gloubiboulga> hi Tonio_
[10:59] <Tonio_> hi ajmitch, Gloubiboulga
[10:59] <siretart> StevenK: ajmitch: linda is in main, so you need to bug mdz/Kamion
[10:59] <Tonio_> need to get knetworkmanager in main ;) I'm working on the package
[10:59] <ajmitch> siretart: ah, I didn't realise
[11:00] <ajmitch> StevenK: see, nothing to send to germany now :)
[11:01] <Tonio_> siretart: any idea what is the process to get a NEW package submitted for main directly ?
[11:01] <Tonio_> siretart: does it need to go in revu first ?
[11:01] <StevenK> ajmitch: Just the UK and US. :-)
[11:01] <siretart> Tonio_: first, get it into universe, and make sure it gets tested and reasonably bug free and supportable for main
[11:02] <siretart> Tonio_: then write an MainInclusionReport and bug pitti to review it
[11:02] <siretart> Tonio_: but since we are that late in the release cycle, don't get disappointed if it doesn't make it for dapper
[11:03] <Tonio_> siretart: I know chances are little, but as networkmanager 0.6.1 is now in main, and since knetworkmanager can be considered as part of the global work we've done on that....
[11:03] <Tonio_> chances are a bit better maybe ;)
[11:04] <ajmitch> siretart: what's the process for getting into universe? mdz hasn't been spotted online so I haven't clarified feature freeze & universe with him
[11:04] <siretart> Tonio_: in kubuntu, I heard that things are a bit different. convince riddel about that package, and he will talk to Kamion and pitti
[11:04] <siretart> ajmitch: he said somewhere that he has no objections to new packages in universe. but new packages requiring new dependencies are a nogo
[11:04] <Tonio_> siretart: yes, we have a little issue because networkmanager brings some gtk deps
[11:05] <Tonio_> siretart: and it is not the purpose of kubuntu to be by default linked to gtk in some way
[11:05] <ajmitch> siretart: and that's what we have to clarify, since it's different to what was agreed on
[11:05] <Tonio_> siretart: but lots of people have reported knetworkmanager is working great :)
[11:05] <siretart> Tonio_: you'll need to talk to riddel. but the first step is to bring it to universe anyway :)
[11:06] <ajmitch> sigh, *yet more* f-spot bugs
[11:06] <Tonio_> siretart: will do, thanks for those infos ;)
[11:09] <StevenK> ajmitch: Duh.
[11:09] <StevenK> Mono seems to attract them.
[11:12] <ajmitch> :P
[11:13] <ajmitch> sigh
[11:13] <ajmitch> quantlib is taking its sweet time to build..
[11:13] <StevenK> Yes. Sigh.
[11:14] <StevenK> The usbhid bug I thought was easily reproducible, isn't so.
[11:14] <ajmitch> how annoying
[11:15] <StevenK> Building on this machine is at little painful until it gets more RAM.
[11:15] <StevenK> At least it doesn't ICE gcc.
[11:16] <ajmitch> how much RAM?
[11:16] <ajmitch> ouch, f-spot bugs have doubled in the last couple of days
[11:16] <ajmitch> time to clear out duplicates again
[11:17] <StevenK> 512, at the moment.
[11:17] <StevenK> Which is too little for an amd64
[11:17] <StevenK> (As I've discovered)
[11:18] <ajmitch> yeah
[11:19] <ajmitch> I put 4GB in mine
[11:19] <ajmitch> even the P-M laptop has 1GB
[11:21] <kelmo> hi siretart, hows it going
[11:23] <siretart> huhu kelmo
[11:23] <siretart> kelmo: thanks, fine
[11:24] <kelmo> i trust your exam went well
[11:24] <siretart> kelmo: I just wanted to mail pkg-wpa-devel, but if you are right here, thats even better :)
[11:24] <siretart> yes, the exam was way better than expected. :)
[11:24] <kelmo> i am also thinking of wpa development right now ; )
[11:24] <StevenK> When I get some money I'll be getting a dual core CPU
[11:24] <siretart> kelmo: great :)
[11:24] <ajmitch> StevenK: the results of a month working in .au ;)
[11:25] <siretart> kelmo: we perhaps have a (small) problem
[11:25] <siretart> kelmo: keybuk uploaded yesterday (or the day before) a new wpasupplicant to ubuntu/dapper
[11:25] <kelmo> hmm
[11:25] <siretart> kelmo: he merged some parts of our experimental packaging into 0.4.8
[11:25] <ajmitch> siretart: just some?
[11:25] <kelmo> shit
[11:26] <siretart> ajmitch: he dropped the init script at all
[11:26] <ajmitch> right
[11:26] <ajmitch> because he only wants it for desktop systems?
[11:26] <siretart> kelmo: he needed the new wpasupplicant for being able to support nm 0.6 with wpa support
[11:26] <kelmo> i'd really like to have a communication pipe with this guy, we need co-ordination co-operation if this is to work out
[11:26] <siretart> ajmitch: right. he thinks that without init scripts, this is easier to integrate
[11:27] <kelmo> i do
[11:27] <kelmo> but in due time
[11:27] <kelmo> i am heavily developpng the ifupdown integration
[11:27] <kelmo> developing*
[11:27] <siretart> and this integration is really great stuff
[11:27] <kelmo> but require time, and co-operation
[11:28] <kelmo> i'd be more than happy to spend time so that our distro's can both be happy
[11:28] <kelmo> with the same source package
[11:28] <siretart> ajmitch: the only reason for using an init script is to use wpasupplicant as roaming daemon
[11:28] <ajmitch> right
[11:28] <kelmo> but i need to know exactly what is happening, or else there is no point in my involvement, and vice versa, i need to communicate more too
[11:28] <ajmitch> all I really want is for things to Just Work ;)
[11:29] <siretart> ajmitch: but this is fundamentally against the concept of ifupdown. so in order to not interefere too much with ifupdown, on which nearly all of the rest of ubuntu relies, dropping the init script completly is a good option
[11:29] <ajmitch> siretart: right
[11:29] <ajmitch> siretart: sounds reasonable from that perspective then
[11:29] <siretart> ajmitch: you won't get a 'just work' solution with any init script. sorry
[11:29] <kelmo> i have not heard a good enough arguement FOR the init script yet
[11:29] <siretart> kelmo: only in the use case as roaming daemon
[11:30] <kelmo> no, not even that imho
[11:30] <siretart> but thats a completly different mode of operation
[11:30] <kelmo> i have an alternative to that "mode"
[11:30] <kelmo> using onlu ifupdown
[11:30] <kelmo> only*
[11:30] <siretart> ifupdown plus roaming? tell me more
[11:31] <kelmo> well, i need time tonight
[11:31] <kelmo> then i must really begin documenting
[11:31] <kelmo> but in a nutshell:
[11:31] <ajmitch> hey Yagisan
[11:31] <kelmo> wpa_cli daemon CONNECTED and DISCONNECTED events can drive the roaming aspect
[11:32] <kelmo> and execute a maintainer provided, or user provided (handcrafted) script with those events
[11:32] <kelmo> currently i only have a proof of concept working demo for this
[11:32] <siretart> this is called an 'action script', right?
[11:33] <Yagisan> G'day ajmitch
[11:33] <kelmo> when a network is detected, and association is completed, dhclient is called
[11:33] <siretart> sounds sane
[11:33] <kelmo> when you disconnect ( for any reason) dhclient releases the device
[11:33] <kelmo> this can be extrended to detailed network profiles
[11:33] <ajmitch> kelmo: when a network changes, or always on those events?
[11:33] <kelmo> extended*
[11:33] <ajmitch> eg if you get disconnected & reconnect to the same network in a few seconds, what would happen?
[11:34] <kelmo> ajmitch: those events are frequent, and the construct of the script is vital
[11:34] <siretart> this does happen from time to time, right
[11:34] <Yagisan> ajmitch: I managed to patch a 2.6.16 kernel with pax and the ck patchsets, but then looked at the ubuntu kernel source to integrate l-r-m and have gone - wtf. how does this work.
[11:34] <kelmo> but there is nothing you can do if your device is dropping of the netwrok all the time, that is different problem all together
[11:34] <kelmo> imho
[11:35] <ajmitch> Yagisan: yeah, the ubuntu kernel has a couple of changes
[11:35] <kelmo> ajmitch: but when the network changes, the actions are triggered yes
[11:35] <ajmitch> kelmo: I agree
[11:35] <kelmo> you can even simulate it with wpa_gui
[11:35] <Yagisan> ajmitch: yes - like no .diff in dapper
[11:35] <kelmo> you can disable networks on the fly, what the wpa_cli daemon manipulate the interface via the action script
[11:35] <ajmitch> Yagisan: just a git tree, saner for kernel development
[11:36] <kelmo> s/what/watch
[11:36] <siretart> kelmo: this sounds promising, indeed. the automatic release of a dhcp release on a DISCONNECT event sounds rather invasive to me
[11:36] <Yagisan> ajmitch: I don't know how to use git. yet anyway.
[11:36] <kelmo> why?
[11:37] <kelmo> youneed to release the network setting once you disconnect from a network, in order to configure the next network that you "roam" into
[11:37] <siretart> kelmo: well, if your link is poor, I fear that there could be a storm of dhcp messages on the air because of that
[11:37] <siretart> but I might be too careful at this point
[11:37] <kelmo> of course, that is "expected behaviour"
[11:37] <siretart> ok
[11:37] <kelmo> we can daemonize the dhclient
[11:37] <kelmo> that will "fix" what you describe
[11:37] <kelmo> -nw
[11:38] <kelmo> options
[11:38] <siretart> I see
[11:38] <siretart> but this means that we don't let ifupdown handle dhclient, no?
[11:38] <kelmo> ok, please letme gather my thoughts
[11:38] <kelmo> yo guys tyype much faster than I ; )
[11:38] <kelmo> you* type*
[11:38] <siretart> ok :)
[11:39] <kelmo> siretart: correct:
[11:39] <kelmo> the manual interfaces $MODE must be set
[11:39] <kelmo> for wpa_cli deamon to take control
[11:39] <kelmo> this is well documented in debian policy
[11:40] <kelmo> just as if you give control to guessnet et al.
[11:40] <kelmo> but what intend to provide is flexibility
[11:40] <kelmo> +I
[11:41] <kelmo> had a direct good chat to aj this evening, he helped me sort out some suitable debugging code
[11:41] <siretart> nice :)
[11:42] <kelmo> so the BIG task with be documenting this, because the more time i spend talking about its usage in irc, the less time i am writing it in a file for *all* interested parties ; )
[11:42] <kelmo> s/with/will
[11:42] <kelmo> siretart: so, will you be around at a later stage this evening/day/timezone?
[11:43] <kelmo> and where can i find the debian difference of the recently uploaded ubuntu package for wpasupplicant?
[11:43] <siretart> kelmo: I'm from germany, I intend to be online this afternoon (its 11:43AM here currently)
[11:43] <kelmo> or the diff.gz would be fine i guess
[11:43] <siretart> kelmo: I'd suggest to download the ubuntu source package for now, the changes are documented in the changelog
[11:44] <ajmitch> kelmo: recruit willing slaves to document
[11:44] <siretart> http://archive.ubuntu.com/ubuntu/pool/universe/w/wpasupplicant/wpasupplicant_0.4.8-0ubuntu1.diff.gz
[11:44] <kelmo> ajmitch: yes, i have some guys at kanotix who are more than willing to help translate too
[11:45] <ajmitch> ok, 6 f-spot bugs out of 13 that are marked 'in progress' now & solved with the next upload
[11:45] <siretart> kelmo: let me explain what I currently have. I have prepared a new upload of 0.4.8-1
[11:45] <siretart> I hesitate with uploading, because I changed the init.d script and the /etc/default/wpasupplicant
[11:45] <siretart> the user has to choose for now if he wants to run wpasupplicant in daemon mode (depreacted) or in 'link' mode
[11:45] <siretart> link mode activates wpasupplicant in /etc/network/if-preup.d/wpasupplicant
[11:45] <siretart> this link mode thingy is tested by at least 3 users
[11:45] <siretart> and seems to work so far
[11:45] <kelmo> hmm
[11:45] <kelmo> it definately does not get me excited
[11:46] <siretart> we need to decide how to go on from here
[11:46] <siretart> right, i developed it in oder to fix some bugs we have in the bts
[11:46] <kelmo> i really don't want to throw away my work, if there is a different directive that will override my influence now, i must know soon
[11:46] <siretart> kelmo: I want to get your work into unstable ASAP
[11:47] <kelmo> cool, but we need patience ; )
[11:47] <siretart> kelmo: what I have done was an interim solution to make the current bug reporters happy
[11:47] <kelmo> ok, thas good, but you started to scare me ; )
[11:47] <siretart> kelmo: but now that keybuk uploaded the new world order of things have changed a bit
[11:48] <siretart> I'm tempted to integrate your work in the experimantal package to the next 0.4.8-1 upload
[11:48] <StevenK> Hrm. There's an awful lot of python2.3 unmet deps.
[11:48] <ajmitch> StevenK: yep :)
[11:48] <kelmo> well, can i just please ask this:
[11:48] <siretart> perhaps without the action script, if that needs more time
[11:48] <siretart> but we already have a non-roaming wpasupplicant integration with ifupdown
[11:48] <kelmo> please please please let me announce that my work is final before we go gun ho
[11:48] <siretart> which WORKS (at least for me)
[11:48] <ajmitch> StevenK: mostly due to the gutting of python2.3 from main - so any main python lib had its python2.3 package removed
[11:49] <siretart> kelmo: of course. no problem
[11:49] <kelmo> siretart: buggy non-roaming wpasupplicant integration
[11:49] <kelmo> there are holes in it
[11:49] <siretart> kelmo: buggy in what way?
[11:49] <ajmitch> StevenK: it broke zope2.8 horrendously - I have 'forked' python-xml for universe
[11:49] <kelmo> well, i have made many changes
[11:49] <ajmitch> as well as python-imaging, and a dummy package for python-docutils so I can install plone again
[11:49] <kelmo> i don't want to support backwards compat fixes to code i never announced for release
[11:49] <siretart> ok
[11:49] <kelmo> this would be, frustrating
[11:50] <siretart> completly understandable
[11:50] <siretart> your work is great. I'd love to see that in unstable
[11:50] <kelmo> definately
[11:50] <kelmo> but its not good enough *right now*
[11:50] <kelmo> in *any form*
[11:50] <siretart> and thats why I was working on this link mode thingy
[11:51] <kelmo> cool
[11:51] <kelmo> ok, let me get to work
[11:51] <siretart> as interim solution
[11:51] <kelmo> midnight approaches quickly
[11:51] <ajmitch> kelmo: where are you?
[11:51] <siretart> kelmo: how do you think about this?
[11:51] <kelmo> brisbane
[11:51] <siretart> kelmo: shall I ask my sponsor to upload this?
[11:51] <kelmo> au
[11:51] <ajmitch> kelmo: ah right, a pity I didn't know - I was just there for a month :)
[11:52] <kelmo> siretart: what is "this", the link stuff?
[11:52] <siretart> kelmo: it causes another round of conffile changes to our users. which will happen again when we switch to new world order
[11:52] <siretart> kelmo: I introduced a new variable in the old packages, called 'TYPE'
[11:52] <siretart> kelmo: if the user sets this to 'DAEMON', wpasupplicant gets started at boot time, as ever
[11:52] <siretart> (deprecated)
[11:53] <siretart> if the user sets this to 'link', it gets started in /etc/network/if-preup.d/wpasupplicant
[11:53] <Tonio_> any wolunteer to revu this ? http://revu.tauware.de/details.py?upid=2167
[11:53] <Tonio_> it is actually discussed as a replacement for kwifimanager on kubuntu by default :)
[11:54] <siretart> I'd like to get many of the bugs we have in the bts open fixed. which the new upload does
[11:54] <kelmo> my main concern is this: be careful of forcing users to switch "methods" too many times in a short period, it may become a reason to stop the work i currently do from being introduced
[11:54] <siretart> thats right
[11:54] <kelmo> and:
[11:54] <kelmo> i am confident i can work out minor points of operation this evening
[11:55] <kelmo> and we can discuss this in a few hours time
[11:55] <kelmo> is that ok?
[11:55] <siretart> kelmo: how quick do you think we can get your work suitable for unstable?
[11:55] <kelmo> siretart: raw code: maybe this weekend
[11:55] <siretart> I finally have a wpa secured network at home, so I can test better
[11:55] <kelmo> siretart: good documentation, a week, two or more
[11:55] <siretart> kelmo: ok, I'll help you with documenting
[11:56] <kelmo> and that is only if i can "walk the talk"
[11:56] <kelmo> at the moment i am simply talking the talk
[11:56] <siretart> then lets work on that and target an upload for monday or tuesday, pointing to some wiki page for documentation
[11:56] <siretart> so that we can work on documentation there. :)
[11:57] <kelmo> okay, i have a slightly off topic question that also requires my urgent attention this evening
[11:57] <kelmo> conffiles
[11:57] <siretart> this is perfectly on topic for #ubuntu-motu :)
[11:57] <kelmo> i have seen a package that overwrote a key kde conffile (kdebase-data) even
[11:58] <kelmo> the package is restricted to kanotix however, that is the off-topicness
[11:58] <kelmo> but the concept is interesting
[11:58] <kelmo> now a new package owns a key conffile
[11:58] <kelmo> and threatens the upgrade path of kdebase-data
[11:59] <kelmo> we need to employ a hack to put that conffile back in the hands of kdebase-data
[11:59] <kelmo> with minimal (if at all) manual intervention
[11:59] <kelmo> any quick ideas?
[12:00] <siretart> I'm a bit confused
[12:00] <kelmo> i have noticed udev has some postinst code to remove warn about leftover hotplug stuff
[12:00] <siretart> if kdebase-data has a conffile, which is also in another package, dpkg should prevent installation of that other package due to file conflicts
[12:01] <kelmo> yes, reason that did not happen:
[12:01] <siretart> are you sure you don't mix conffiles vs. configuration file?
[12:01] <kelmo> our "ftp-master" trusted the uploader so much, that he failed to interigate the package
[12:01] <kelmo> and the package had Replaces: kdebase-data!
[12:01] <kelmo> massive blunder
[12:02] <kelmo> and not something we can live with
[12:02] <ajmitch> ouch
[12:02] <kelmo> exactly
[12:02] <Tm_T> haha
[12:02] <kelmo> there is alot of embarrasment about this in our camp
[12:02] <siretart> and now users have upgraded to the new broken package, right?
[12:02] <kelmo> siretart: some have, correct
[12:03] <kelmo> this really spells bad news => new kde soon
[12:03] <kelmo> i am simply wondering if anybody would have a quick idea about this problem
[12:03] <siretart> hm. you will perhaps need a new upload of kdebase-data, which conflicts against this malicous package. remove/fix that package asap
[12:04] <kelmo> yes, but hesitation:
[12:04] <siretart> but thats obvious, now you have the problem with conffiles
[12:04] <kelmo> a binNMU of kdebase may introduce subtle ABI changes
[12:04] <kelmo> as well
[12:04] <kelmo> compounding an allready outrageous problem
[12:04] <siretart> *sigh*
[12:05] <kelmo> ok, enough chatter from me ; )
[12:05] <kelmo> i have flooded this channel with it
[12:05] <ajmitch> that's crackful, to say the least :)
[12:05] <kelmo> indeed
[12:05] <kelmo> but its like this now:
[12:05] <ajmitch> kelmo: no problem, we don't mind development discussion :)
[12:05] <kelmo> finders keepers
[12:05] <siretart> kelmo: you are battling several fronts. and now several things bite you at once
[12:05] <kelmo> i found the damn bug, now its mine to fix!
[12:06] <kelmo> siretart: to say the least
[12:06] <ajmitch> kelmo: ah, TILS :)
[12:06] <ajmitch> touched-it-last syndrome :)
[12:06] <kelmo> yep!
[12:07] <siretart> kelmo: if you change the ABI, you'll won't get away without building large portions of the archive
[12:07] <siretart> which is painfull as hell, yes
[12:07] <kelmo> siretart: we have done that before
[12:07] <kelmo> but we before the reasons were sane
[12:07] <kelmo> -we
[12:07] <kelmo> the reason now is *insane*
[12:07] <kelmo> moral of story:
[12:08] <kelmo> conffiles are very very precious files
[12:08] <siretart> kelmo: if only some users have upgraded to that malicous package, give them instructions how to manully revert
[12:08] <siretart> and remove that package
[12:08] <kelmo> yes, its looking like a debconf WARNING screen is the only way
[12:08] <Tonio_> siretart: any idea on that lintian error ? network-manager-kde: no-shlibs-control-file usr/lib/libkdeinit_knetworkmanager.so
[12:08] <Tonio_> siretart: I assume this is because I don't split the lib
[12:09] <siretart> Tonio_: you are providing an shared library, but no soname. isn't this file intended for use in other packages?
[12:09] <Tonio_> siretart: but should I ? as it is for knetworkmanager usage only
[12:09] <zakame> Tonio_: you don't have a shlibs.local?
[12:09] <siretart> if it is, then provide a shlibs file
[12:09] <Tonio_> it is not intended for use with another package, no....
[12:09] <zakame> hi all anyway :)
[12:09] <Tonio_> should I override lintian then ?
[12:10] <Tonio_> siretart: or let the error ?
[12:10] <siretart> kelmo: you could do some heuristics, check the dpkg database if that specific version is installed, and do then countermeasures
[12:10] <siretart> (like debconf WARNING screen)
[12:10] <siretart> Tonio_: I've seen packages ignoring this issues, but I'm not happy with that either
[12:11] <siretart> I'd need to look up what to do with internal only use shared libs
[12:11] <kelmo> siretart: yep, just like udev
[12:11] <zakame> Tonio_: is that so a plugin or something
[12:11] <Tonio_> siretart: so you would suggest to split anyway, even if the lib is intended for internal usage only ?
[12:11] <zakame> (I'm so ignorant of kde, sorry)
[12:11] <Tonio_> zakame: nope, it is just a lib used in that package only, nothing more
[12:11] <siretart> Tonio_: no, if only one package needs that libs, thats overkill
[12:12] <Tonio_> siretart: so I can let the error and upload like that
[12:12] <zakame> Tonio_: hm, can you just statically link it then and save a file?
[12:12] <zakame> Tonio_: but then again that might be not a good idea
[12:12] <Tonio_> zakame: hum..... what would it change ?
[12:12] <siretart> Tonio_: I'd like to do some more research on that topic before giving advice
[12:13] <Tonio_> zakame: the package works actually, it is just to make lintian happy with it :) but I generally don't like to override lintian messages :)
[12:13] <zakame> siretart++
[12:13] <Tonio_> siretart: okay, thanks ;)
[12:14] <zakame> Tonio_: from what it looks, that may be one option
[12:14] <Tonio_> zakame: I can simply let the error, and let motu give their opinion
[12:14] <Tonio_> ;)
[12:14] <siretart> ok, I'm afk for a few hours, see you later all!
[12:14] <Tonio_> siretart: ++
[12:14] <zakame> cya siretart :)
[12:35] <ajmitch> hey Hobbsee
[12:35] <Hobbsee> hey ajmitch :)
[12:39] <ajmitch> Hobbsee: that's always a bonus ;)
[12:40] <Hobbsee> hehe
[12:40] <ajmitch> StevenK hasn't jumped on you or anything tonight
[12:41] <Hobbsee> no, oddly enough
[12:41] <Hobbsee> i went to work
[12:44] <zakame> heya Hobbsee
[12:44] <Hobbsee> hey zakame
[12:45] <ajmitch> Hobbsee: I know that feeling
[12:45] <Hobbsee> it's only adept, and a build-dep of adept, but even so...
[12:46] <ajmitch> Hobbsee: ah, c++ code?
[12:46] <zakame> Hobbsee: awww *patpat*
[12:46] <zakame> Hobbsee: I myself have a monster compile to do, with eclipse
[12:46] <ajmitch> zakame: ouch
[12:47] <zakame> ajmitch: motujava work :( all for just a s/mozilla/firefox/ b-d adjustment
[12:47] <ajmitch> except when a testcase for something decides to just do an infinite loop
[12:47] <ajmitch> zakame: oh?
[12:49] <ajmitch> Hobbsee: no, but c++ takes an age to build
[12:50] <Hobbsee> true
[12:55] <ajmitch> ok, 12 non-duplicate f-spot bugs
[12:55] <ajmitch> 6 fixed in next upload
[12:55] <ajmitch> only 2 unconfirmed now
[12:58] <zakame> rock
[12:58] <zakame> brb
[01:23] <Yagisan> ajmitch: I just noticed that the pt_pax_flags patch, patches nicely onto breezys binutils. :)
[01:24] <ajmitch> useful
[01:24] <Yagisan> ajmitch: yes. I'm building it, and gcc 4.1 for a little experiment :) really need to wrap my head around the kernel and l-r-m packages though
[01:25] <tseng> pt_pax_flags eh
[01:25] <tseng> is upstream still alive?
[01:25] <tseng> or is spengler maintaining that
[01:25] <Yagisan> tseng: I think so. I took it from the pax page
[01:26] <Yagisan> tseng: not the grsec ones
[01:26] <tseng> Yagisan: well the author of pax quit over a year ago
[01:30] <Yagisan> tseng: no he didn't
[01:30] <Yagisan> tseng: but he did make a public seen
[01:30] <Yagisan> s/seen/scene
[01:30] <tseng> there is nothing on the website dated past then
[01:31] <Yagisan> tseng: he released test patches of pax against 2.6.16
[01:31] <tseng> ok.
[01:31] <Yagisan> tseng: they seem ok at the moment. I thought it would be good to do an experiment, and see how well ubuntu builds and runs with it
[01:32] <Yagisan> tseng: compared to the competition
[01:32] <tseng> that would be pretty cool.
[01:32] <tseng> 'the competition' being adamantix and gentoo?
[01:33] <Yagisan> tseng: I was thinking gentoo (and exec shield solutions)
[01:33] <tseng> i used to work on hardened gentoo a long long time ago
[01:33] <Yagisan> that being all I have to compare at home
[01:34] <Yagisan> tseng: I know )I used to cherry pick your patches from http://dev.gentoo.org/~tseng/kernel/ )
[01:34] <tseng> haha nice.
[01:34] <Yagisan> tseng: you had some good stuff there :)
[01:34] <Yagisan> hmm, thats a 403 now
[01:35] <tseng> i stole it from -mm, dilinger -as, -ac
[01:35] <tseng> smarter people than me.
[01:35] <tseng> yeah they finally got around to deleting my account on that box
[01:35] <Yagisan> tseng: and I did they same. ie you, and much other the others you mentioned
[01:36] <Yagisan> tseng: the new pax stuff hides in here http://www.grsecurity.net/~paxguy1/
[01:36] <Tonio_> any revu-admin out there ?
[01:36] <tseng> yeah i was aware of secret hidden patches from back then
[01:36] <Tonio_> need a upload to be nuked :)
[01:37] <tseng> Yagisan: if you could get the full grsecurity suite running nicely on my ubuntu server, you would be my hero
[01:38] <Yagisan> tseng: I'd be my hero too - but spender hasn't yet ported to 2.6.16, but if pax is now there, ther should be a patch soonish
[01:38] <tseng> yeah, thats the hard part.
[01:39] <Yagisan> tseng: I diffed the .14 grsec against .16 and went - nope, I'll just take the pax bit then. Easier for me
[01:40] <Yagisan> tseng: I don't know why they can't break it up into little bits and send it mainline. A lot of those features would be useful.
[01:45] <tseng> oh yeah
[01:45] <tseng> one time we tried to send the randomized pid's and stuff
[01:45] <tseng> and we found out the kernel was already doing that :)
[01:46] <Yagisan> heh. That's rather funny
[01:46] <tseng> alot of the other stuff linus considers to be useless
[01:46] <tseng> or you just end up in a flamewar with arjvan
[01:48] <Yagisan> very talented people, but security is not their forte, so they probally are hard to convince
[01:48] <tseng> yeah
[01:51] <Yagisan> tseng: do you think I could use lp to store patches for a sort of "security enhanced ubuntu" ?
[01:51] <tseng> you can definately attache patches to bugs
[01:51] <tseng> and then link them up on a wiki page
[01:53] <Yagisan> tseng: I was thinking more a meta distribution, so I could merge patches automatically when a new release of a package hits dapper. Currently I do it manually.
[01:53] <tseng> oh
[01:54] <tseng> that sounds like HCT
[01:54] <tseng> which will be part of launchpad someday, we hope
[01:54] <Yagisan> tseng: ? usually my changes are CFLAGS related, but sometimes I have a new patch I pinched from somewhere.
[01:54] <tseng> its not entirely automated, but it makes handling patches easier
[01:55] <tseng> what are you doing to CFLAGS?
[01:57] <Yagisan> tseng: new gcc 4.1 features :) -f-stack-protector stuff usually.
[01:57] <tseng> i think pitti is looking at that a little
[01:57] <slomo> Yagisan: can't you just use a patched gcc that enables this by default?
[01:57] <tseng> slomo: sortof
[01:57] <tseng> slomo: but some packages dont like it
[01:57] <Yagisan> slomo: my testing showed that doing it package by package was better
[01:58] <Yagisan> damm tseng beat me
[01:58] <slomo> hm... so there are more packages that don't like it than packages that like it?
[01:58] <tseng> no
[01:58] <tseng> but starting with a whitelist is nice
[01:58] <tseng> firefox hates ssp
[01:59] <slomo> what's the reason they don't like it? what are they doing to the stack? ;)
[01:59] <Yagisan> some packages do funky stuff, but most go well
[01:59] <tseng> actually
[01:59] <tseng> alot of C++ is bad news
[01:59] <tseng> kde too
[02:01] <slomo> but what's the exact reason why they fail? what are they doing? :)
[02:01] <tseng> it has been a really long time since i cared :)
[02:01] <tseng> i dont remember
[02:02] <Yagisan> slomo: I sometimes see them segfault on startup
[02:02] <tseng> slomo: ssp adds a stack guard in assembly
[02:02] <Yagisan> slomo: but as I build them with gcc 4.1 I'll make a list (assuming I use the app)
[02:02] <tseng> if someone is doing evil things with the stack
[02:02] <tseng> your app will either blow up or be wrongfully killed by ssp
[02:03] <tseng> most of the time its a bug in the app
[02:03] <tseng> not ssp
[02:03] <Yagisan> personally I think ssp is working correctly
[02:04] <Yagisan> on i386, it does take the speed advantage of -fomit-frame-pointer away. other arches have no penalty
[02:05] <Yagisan> but that is only for certain functions (unless -fstack-protector-all is used)
[02:05] <slomo> x86 is deprecated anyway ;)
[02:05] <spacey> Yagisan: maybe you can give ubuntu-hardened some extra life with that :)
[02:05] <ajmitch> slomo: of course, we should all have amd64 by now, right?
[02:06] <spacey> Yagisan: did you utilize the mirror yet?:)
[02:06] <slomo> Yagisan: is ssp without -fomit-frame-pointer slower than without both on x86?
[02:06] <Yagisan> spacey: not yet. my upstream is saturated atm, but I will soon
[02:07] <spacey> Yagisan: might save your upstream from future saturation? :)
[02:09] <Yagisan> brb - kids
[02:14] <Yagisan> slomo: yes. ssp needs a register, much like a frame pointer
[02:14] <Yagisan> spacey: self-inflicted saturation. Uploading to the jfiles mirror first
[02:14] <slomo> Yagisan: ok... too bad that x86 has so few registers :/
[02:15] <Yagisan> slomo: it isn't on all functions, so overall impact is very low
[02:15] <slomo> Yagisan: how are the functions chosen that get it?
[02:16] <siretart> x86 stinks anyway
[02:18] <Yagisan> slomo: http://gcc.gnu.org/onlinedocs/gcc-4.1.0/gcc/Optimize-Options.html#Optimize-Options
[02:18] <Yagisan> slomo: search for -fstack-protector
[02:19] <slomo> ok, thanks
[02:19] <Yagisan> :)
[02:27] <siretart> Yagisan: sbuild is nice
[02:28] <siretart> Yagisan: espc. with recent schroot.
[02:28] <ajmitch> night all
[02:28] <siretart> sleep well, ajmitch
[02:28] <Tonio_> good night
[02:29] <Yagisan> goodnight ajmitch
[02:29] <Hobbsee> night ajmitch
[02:29] <Yagisan> ajmitch let us know how your selinux stuff goes. I'd like to test it latter
[02:29] <slomo> gn8 ajmitch
[02:30] <Yagisan> siretart: can I automate it ? I have a "multibuild" script for pbuilder that builds all .dsc packages in the cwd
[02:33] <siretart> Yagisan: well, buildd uses sbuild. I think that sbuild is easier to automate than pbuilder, but YMMV
[03:53] (Yagisan/#ubuntu-motu) slomo: that package will never get into debian
[03:53] (siretart/#ubuntu-motu) slomo: ok. I will cherry pick and include that to the diff.gz (read: directly into the svn
[03:53] (siretart/#ubuntu-motu) slomo: because the TOOLS/ subdir is a mess anyway. but well
[03:53] (slomo/#ubuntu-motu) siretart: ok... is there something useful in TOOLS? i didn't look too closely
[03:54] (slomo/#ubuntu-motu) Yagisan: no, most probably not... although the debian package has nothing evil that ffmpeg doesn't have
[03:54] <siretart> some helper scripts like mencvcd, which calls mencode with correct parameters for vcd encoding and such
[03:54] <siretart> nothing critical, but nice to have
[03:56] <Yagisan> slomo: I know. The name seems cursed. If it had another name, it would might move quicker
[03:57] <slomo> Yagisan: exactly... and when beeing consequent many things would have to stay out of debian too the same way like mplayer ;)
[04:00] <Yagisan> slomo: I too find it odd that they can apply the same rules to the same type of application, and get two different outcomes
[04:00] <slomo> Yagisan: different people looking at it
[04:03] <Yagisan> slomo: I suppose. I'd look up the DFSG to see if patents are listed, but www.debian.org seems to be down.
[04:04] <slomo> Yagisan: patents make a package not freely redistributable... so it should be at least implicitly listed there
[04:05] <Yagisan> slomo: if you take that attitude, you can't distribute any software - somewhere some jerk has a patent on almost all software
[04:06] <Yagisan> slomo: eg apple patented software updates recently - now update-manager is infinging
[04:08] <Yagisan> slomo: it's absurd that *ideas* like that can be patented, copyright law already covers the expression of the idea, a patent is not required.
[04:08] <slomo> Yagisan: yes... unfortunately. the only difference here is, that multimedia related patents were enforced in the past while most other were not...
[04:08] <slomo> Yagisan: hehe, no need to tell me that :)
[04:09] <Yagisan> slomo: the funny thing is multimedia, is maths. Why are people patenting maths now ?
[04:10] <siretart> I had the chance to talk to one of the ftp-masters in debian at linuxtag
[04:10] <slomo> Yagisan: because they can... they would patent breathing when it would be possible ;)
[04:11] <siretart> about mplayer not beeing processed
[04:11] <Yagisan> slomo: they might have already done that. 20% of the human genome is now patented
[04:12] <slomo> siretart: and what did he say?
[04:12] <siretart> the thing is this: if he would reject mplayer, then many many other software would need to be removed from debian as well
[04:12] <siretart> like, say, xine, ffmpeg and so on
[04:12] <siretart> and this would cause a GIANT flamewar, which he wants to avoid
[04:12] <siretart> in order to check and approve mplayer, he would need about 5h in a row, he told me
[04:13] <siretart> the thing is, that he is too busy with other packages, which needs to be reviewed as well
[04:13] <siretart> and so he puts the package on 'hold'. for now
[04:16] <slomo> siretart: hm, we'll see what the future brings :) at least such patents will most probably become a big trouble in the next time...
[04:23] <kelmo> siretart: making great progress here, can i ask a quicky?
[04:23] <kelmo> siretart: any objections to switching to cdbs for wpasup?
[04:24] <tseng> whats the reason, and is it in debian?
[04:25] <kelmo> tseng: i am debian packager for this program
[04:25] <kelmo> at least for the experimental branch  i help out
[04:25] <tseng> oh, that settles that
[04:25] <kelmo> no ubuntu-motu ; )
[04:30] <slomo> kelmo: as long as cdbs makes your life easier and you don't need to hack around some of it's problems there's no reason not to switch :)
[04:53] <siretart> say, have there been any update to breezy-backports since the upgrade to soyuz?
[05:00] <slomo> siretart: no
[05:03] <siretart> :/
[05:06] <slomo> siretart: should be the same as for syncs "not implemented yet"
[05:21] <siretart> slomo: :(
[05:43] <bmonty> Erlang: fakesync for jde is uploaded
[06:02] <bmonty> slomo: ping
[06:02] <slomo> bmonty: pong
[06:02] <bmonty> slomo: Malone #33619 should never have been a UVF request, it is just a sync...can I mark it as reject?
[06:02] <Ubugtu> Malone bug 33619 in petsc "UVF exception request" [Normal,Needs info]  http://launchpad.net/bugs/33619
[06:04] <slomo> bmonty: a sync with no new upstream version involved? then reject it and upload the sync :)
[06:04] <bmonty> slomo: ok, sorry about that
[06:04] <slomo> bmonty: no need to worry :)
[06:10] <trappist> danpei depends on libpng10-0 which doesn't exist.  how can I tell if it was actually built against 10-0?
[06:11] <trappist> Depends: ${shlibs:Depends}
[06:11] <trappist> never seen that before
[06:11] <siretart> trappist: that mechanism is called shlibs, it calculates versioned dependencies at package build time
[06:12] <kelmo_lap> siretart, http://rafb.net/paste/results/PjIAHs50.html
[06:12] <kelmo_lap> siretart, its looking cool now ; )
[06:12] <trappist> if there's no libpng10-0 in dapper, how did that happen?  maybe it was built on a dist-upgraded box with old libs lying around?
[06:12] <siretart> trappist: libpng was renamed again, perhaps a rebuild is sufficent to fix this
[06:12] <trappist> I'm rebuilding now, seems to be going ok
[06:13] <siretart> kelmo_lap: sweet! :)
[06:13] <trappist> yeah the rebuilt package installs fine
[06:14] <kelmo_lap> now i need to merge into alioth svn from my own . . .
[06:14] <kelmo_lap> quite a few changes
[06:14] <kelmo_lap> then we can discuss the upgrade path
[06:14] <siretart> ok
[06:16] <bmonty> trappist: please take a look at https://wiki.ubuntu.com/MOTU/Transitions/UnmetDeps
[06:16] <bmonty> if you want to make the debdiff we can fix the package in the archive
[06:18] <bmonty> anyone know if the default debconf priority for ubuntu is set to "high".  It is on my system, but I can't remember if it is because I set it that way.
[06:18] <slomo> iirc it's high by default
[06:19] <siretart> trappist: I just uploaded danpei_2.9.7-1build1 to get it rebuilt
[06:19] <bmonty> slomo: does that differ from debian?
[06:21] <trappist> siretart: awesome, thanks
[06:22] <trappist> bmonty: thanks for the link
[06:23] <trappist> crap it builds but it segfaults on startup.
[06:24] <slomo> bmonty: no idea
[06:24] <siretart> wah, mplayer is da hate
[06:24] <siretart> takes ages to build
[06:24] <slomo> siretart: not my fault :)
[06:26] <siretart> slomo: :)
[06:27] <slomo> siretart: but it's funny that we had almost no bugreports on mplayer... seems to be almost perfect ;) (unless i'm not subscribed...)
[06:27] <netzmeister> hi MOTU's ;-)
[06:27] <bmonty> hey netzmeister
[06:28] <slomo> hi netzmeister
[06:28] <netzmeister> hi bmonty, slomo
[06:28] <siretart> slomo: there are some https://launchpad.net/distros/ubuntu/+source/mplayer/+bugs
[06:28] <siretart> I'm particularily worried about bug 27851
[06:28] <Ubugtu> Malone bug 27851 in mplayer "Mplayer crashes after screensaver is run" [Normal,Unconfirmed]  http://launchpad.net/bugs/27851
[06:29] <slomo> siretart: the bugs are forwared to the motumedia list?
[06:29] <siretart> slomo: yes, they are
[06:29] <slomo> siretart: weird... i never saw them :(
[06:30] <siretart> strange
[06:30] <Yagisan> slomo: they are the only mail I see on the list
[06:30] <siretart> slomo: mail@slomosnail.de is subscribed
[06:30] <slomo> i get bugmails on the media list... but i never saw a mplayer related one there... anyway, i'll work through them tomorrow :)
[06:30] <siretart> ok
[06:35] <bmonty> hi LaserJock
[06:36] <kelmo_lap> siretart, do you have time for some talk?
[06:37] <LaserJock> morning bmonty
[06:37] <siretart> kelmo_lap: sure
[06:38] <kelmo> take a peek in out experimental branch
[06:38] <kelmo> our*
[06:39] <siretart> ok.
[06:39] <siretart> what shall I look at first?
[06:40] <kelmo> well, maybe make a binary and unpack it
[06:40] <siretart> cdbs?
[06:40] <kelmo> i am just looking at your new packaegs diff.gz
[06:40] <kelmo> i like to build a deb, and unp -u *.deb to take a look inside ; )
[06:41] <siretart> mc is useful as well :)
[06:42] <kelmo> ok, so you guys uploaded on thursday
[06:42] <kelmo> +  * Unlike Debian the wpa-conf /etc/network/interfaces is only needed for
[06:42] <kelmo> +    explicitly giving a configuration file; simply include any setting
[06:42] <kelmo> +    for wpa to be used.
[06:42] <kelmo> i don't get that bit?
[06:43] <siretart> same here
[06:43] <kelmo> so i guess i need to:
[06:43] <crimsun> Scott only wants to support #1
[06:43] <kelmo> grab the ubuntu preinst
[06:43] <kelmo> hack it a bit
[06:43] <siretart> Keybuk didn't really discuss that part with me. he wanted something quick for being able to go on with further testing with nm_0.6
[06:44] <kelmo> why don't Scott get involved in some discussion then?
[06:44] <kelmo> Collaborative Maintenance
[06:44] <kelmo> we need collaberation ; )
[06:44] <siretart> :)
[06:45] <siretart> hmm, doesn't build for me in svn-buildpackage
[06:45] <siretart> there is some foo with the clean target
[06:45] <crimsun> no idea, but I think it has something to do with him being pushed so hard during this release cycle and thus lacking resources
[06:45] <kelmo> that is why he can handoff to enthusiastic volenteers, such as myself
[06:45] <kelmo> to save time
[06:46] <siretart> (/usr/bin/make && cd wpa_gui-qt4 && qmake-qt4 && /usr/bin/make) -k clean || true
[06:46] <siretart> wtf?
[06:46] <kelmo> what cdbs do you guys have?
[06:47] <crimsun> 0.4.32ubuntu13
[06:47] <kelmo_lap> aha
[06:47] <kelmo_lap> good spot
[06:47] <siretart> Version: 0.4.32ubuntu13
[06:47] <kelmo_lap> did not fail here however
[06:47] <kelmo_lap> ii  cdbs                               0.4.36
[06:48] <kelmo_lap> ok
[06:48] <kelmo_lap> should be an easy fix to that
[06:49] <siretart> DEB_MAKE_INVOKE := ($(MAKE) && cd wpa_gui-qt4 && $(QMAKE) && $(MAKE))
[06:49] <siretart> what does this? this seems to break for me?
[06:49] <kelmo_lap> yes
[06:49] <Yagisan> crap
[06:50] <kelmo_lap> its dodgy
[06:50] <Yagisan> I just got emailed a spam that crashes evolution constantly
[06:51] <slomo> Yagisan: tell malone about it :)
[06:51] <crimsun> siretart: (we probably need to demote the build-dep to libqt3-dev so that wpasupplicant can enter main)
[06:51] <crimsun> libqt3-mt-dev, that is
[06:51] <siretart> no qt4 in main. gnarf
[06:51] <siretart> perhaps we can do an alternative on that
[06:51] <siretart> I'd like it to be backportable to sarge as well
[06:52] <crimsun> yeah, sounds reasonable
[06:52] <siretart> nobse talked to me about that
[06:53] <kelmo> ok, cleaned up that garbage
[06:53] <kelmo> excuse me for the problem
[06:55] <siretart> oh, you already did? I was working on that as well :)
[06:55] <kelmo> well, that bit is the least of my interests, lets move on ; )
[06:56] <siretart> :)
[06:57] <Yagisan> slomo: I got the spam open in a text editor
[06:57] <slomo> Yagisan: something bad in there?
[06:57] <Yagisan> slomo: it appears to exploit the evolution crashes if many urls are in an email sec bug alan cox discovered
[06:58] <siretart> kelmo_lap: it ifupdown script looks very improved
[06:58] <slomo> Yagisan: oh... definitely needs to be fixed :/
[06:58] <siretart> package builds fine for me
[06:58] <kelmo> i have spent much time on it!
[06:58] <kelmo> the ifupdown script
[06:59] <kelmo> not much time in debian/rules evidently ; )
[06:59] <Yagisan> slomo: If I could read arabic, I could tell you what they are trying to sell me too
[06:59] <siretart> :)
[06:59] <siretart> but you are right, the old rules file was rather a mess
[06:59] <kelmo> well, this way they are short and sweet
[06:59] <siretart> ok, package built fine in 1:45 on my dapper laptop
[07:01] <kelmo> there are still some items in the TODO list
[07:01] <kelmo> a menu entry for wpagui would be nice
[07:01] <kelmo> little things like that
[07:02] <kelmo> long term plans: improve wpa_cli feedback engine, but i suppose you guys will favout NMW at all times
[07:03] <kelmo> so you guys will use QT3?
[07:03] <siretart> kelmo_lap: we also have qt4 in universe, but only qt3 in main
[07:03] <kelmo> maybe we can make the rules a bit nicer so you just change QMAKE and it selects the right target
[07:03] <siretart> kelmo_lap: so for getting wpasupplicant on the cd, qt3 would be a must
[07:03] <kelmo> then one line change in rules, change control file build-deps
[07:04] <siretart> but after all, in order to get it in sarge, we would need to use qt3 anyway
[07:04] <kelmo> sarge?
[07:04] <kelmo> bit late for that aint it?
[07:04] <siretart> kelmo_lap: I'll work on getting it backportable. I think about putting build depends alternatives, and make the rules file check what is actually available
[07:04] <crimsun> (backportability)
[07:04] <siretart> kelmo_lap: I mean backports.org
[07:05] <siretart> kelmo_lap: nobse builds updated packages in sarge chroots
[07:06] <siretart> kelmo_lap: anything special before I go into deep testing mode I should look at?
[07:06] <kelmo> its 4am, don't ask me to think . . .
[07:07] <siretart> uuh
[07:07] <kelmo> well, if i wake up and see that what we've done tonight is sane, maybe i should request Kyle get this in deb/experimental
[07:08] <kelmo> so i guess the init script is being totally dropped?
[07:08] <siretart> Kyle seems quite busy. have you talked to him lately?
[07:08] <kelmo> no
[07:08] <Yagisan> kelmo: 4am, so Aus, or Asia ?
[07:08] <siretart> kelmo_lap: keybuk dropped the init script completely. we still have it for supporting the traditional way (as system daemon)
[07:09] <kelmo> Yagisan: au
[07:09] <siretart> kelmo_lap: where is the action script run?
[07:10] <siretart> or better, run from
[07:10] <kelmo> you have to ask it to run, for now
[07:10] <kelmo> wpa-action /path/to/action/script
[07:10] <siretart> excellent!
[07:10] <kelmo> that should allow flexibility
[07:10] <Yagisan> kelmo: G'day from Sydney. NT or SA ?
[07:11] <kelmo> so when you wanna use NMW, no conflicts here
[07:11] <kelmo> Yagisan: brissie
[07:11] <siretart> NMW?
[07:11] <kelmo> NWM ; )
[07:11] <kelmo> netwrok-manager or so
[07:11] <siretart> aah, nm
[07:11] <kelmo> work*
[07:12] <kelmo> i've only heard it 20,00 times in the last week ; )
[07:12] <kelmo> +0
[07:12] <siretart> well, I will see. I was told that it still has issues on madwifi
[07:12] <siretart> or the other way rund
[07:12] <siretart> round
[07:12] <Yagisan> kelmo: crap, forgot daylight saving didn't end yesterday.
[07:12] <kelmo> i just commited one patch for NM compat the other day
[07:12] <kelmo> to madwifi-ng
[07:13] <kelmo> the one that Dan submitted
[07:13] <kelmo> to report IW_CAPA*
[07:13] <kelmo> just the scanning problem
[07:13] <kelmo> but wpa_sup 0.5.2 has a workaround for it
[07:13] <kelmo> or you might like to take a loong into my madwifi-ng experimental branch fopr a patch
[07:14] <kelmo> s/loong/look*
[07:14] <kelmo> to eliminate that annoying 30 second interval
[07:14] <kelmo> shoudl help with wifi-radar and so on
[07:14] <kelmo> i saw your diff.gz for that package
[07:14] <siretart> so you mean that wpa_sup 0.5.2 and madwifi-old should just do it?
[07:14] <kelmo> madwifi-old? no
[07:14] <kelmo> madwifi-ng
[07:15] <siretart> ok
[07:15] <kelmo> maybe with a patch
[07:15] <kelmo> or
[07:15] <kelmo> with bleeding edge wpa_sup
[07:15] <kelmo> patch is in pkg-madwifi notuploaded branch
[07:15] <kelmo> if you are interested
[07:15] <kelmo> i won't apply it upstream
[07:15] <siretart> will look at that
[07:16] <kelmo> but will carry it along until that guys finds the time to fix the outstanding issues
[07:16] <kelmo> s/guys/guy
[07:16] <siretart> kelmo_lap: what is the status about WE19 in madwifi-ng? Is it planned that madwifi-ng will work with -Dwext someday?
[07:16] <kelmo> some people have just started working on it
[07:16] <kelmo> *but*
[07:17] <kelmo> they must realise that madwifi still has to support older kernels
[07:17] <kelmo> so its ifdef city
[07:17] <siretart> sure
[07:17] <kelmo> ifdefferry
[07:17] <kelmo> but i am no developer, just a patch tester/manager/documents etc
[07:18] <siretart> ah, ok
[07:18] <kelmo> currently there is no one person spending lots of time on it, just contributed patches
[07:18] <kelmo> maybe ath-driver will get better ; )
[07:18] <siretart> lets hope the best
[07:19] <kelmo> we had one guy report madwifi-ng was working quite well with nm 0.6.1
[07:19] <kelmo> not sure about that version, just quoting him
[07:20] <siretart> I plan to test nm 0.6.1 tomorrow with madwifi-old. perhaps I can try madwifi-ng as well for comparison
[07:20] <kelmo> sure
[07:20] <kelmo> how do you guys handle madwifi?
[07:21] <kelmo> restricted-modules meta package or so?
[07:21] <siretart> it is in the 'linux-restricted-modules' source package
[07:21] <kelmo> so to update one, you also have to update fglrx and nvidia?
[07:21] <siretart> that package contains all restricted drivers we have: nvidia, fglrx, some restricted firmware and madwifi even
[07:22] <siretart> well, all drivers are in that package, so, yes
[07:22] <kelmo> hmm, ok
[07:22] <siretart> infinity considers uploading madwifi-ng, but he hesitates
[07:22] <kelmo> why?
[07:22] <siretart> I believe because it introduces additional dependencies
[07:22] <siretart> so these additional packages would have to go to universe first and then get promoted to main
[07:23] <kelmo> do you know what ones?
[07:23] <siretart> which wouldn't be that much of a problem if we weren't in feature freeze already
[07:23] <siretart> well, I think he was talking about these mandatory user space tools
[07:23] <siretart> in order to setup your VAPs and then your actual devices
[07:24] <kelmo> yah, does he base his work on that of pkg-madwifi?
[07:24] <kelmo> i see no real problems there . . . at first glance
[07:25] <siretart> I don't think so
[07:25] <siretart> because kernel is handled specially
[07:25] <siretart> kelmo_lap: see, pkg-madwifi is about packaging madwifi only
[07:26] <siretart> kelmo_lap: he has no interest in slitting madwifi into its own sourcepackage, because that additional burden for security and abi bump uploads
[07:26] <siretart> kelmo_lap: currently, new kernel uploads are quite easy, because they involve exactly 2 uploads
[07:27] <siretart> unlike debian, which needs over 2 dozens uploads for kernel related packages for a security upload
[07:27] <siretart> which is insane
[07:27] <kelmo> yes, but module upgrades are notpossible with that method . . .
[07:27] <kelmo> i get your point though
[07:27] <kelmo> i handle those two dozen external modules for Kanotix ; )
[07:28] <siretart> ;)
[07:28] <Yagisan> evolution bug now reported, and finally I reported that reportbug doesn't work with lp
[07:28] <kelmo> beginning to be a bitch lately
[07:28] <Yagisan> kelmo you poor thing
[07:28] <siretart> I have strong doubts thad madwifi-ng will make it into dapper, but at least mjg59 strongly suggests doing so
[07:29] <siretart> we'll see what happens
[07:29] <kelmo> well, for compatibility sake of wpa_sup, i hope not
[07:29] <kelmo> and hhostapd
[07:29] <kelmo> i don't plan to push madwifi-ng until a: its made a release or b) etch is released
[07:29] <kelmo> s/a:/a)
[07:30] <kelmo> in all honesty, it still has a host of issues
[07:30] <siretart> ah, I see
[07:31] <Yagisan> siretart: thanks for the credit in r77 :)
[07:32] <Yagisan> right, goodnight all. It's 5:30 and I need to get up soon.
[07:32] <Yagisan> bye
[07:32] <ogra> Yagisan, pfft
[07:32] <ogra> stay up then :)
[07:33] <Yagisan> ogra: no - I need to take advantage of the two sleeping children. If I don't sleep now - I won't sleep at all today
[07:33] <siretart> ogra: you did some work on gnome-screensaver integration into several applications, no?
[07:33] <Yagisan> ogra: 2 children under 2 makes it hard to sleep
[07:34] <siretart> ogra: could you please look at malone bug 27851 then, if you have some time leftover for mplayer ;)
[07:34] <Ubugtu> Malone bug 27851 in mplayer "Mplayer crashes after screensaver is run" [Normal,Unconfirmed]  http://launchpad.net/bugs/27851
[07:34] <ogra> siretart, yep
[07:34] <ogra> siretart, again ?
[07:34] <siretart> its not closed (yet)
[07:34] <ogra> i had that one on my desk already...
[07:34] <ogra> hmm
[07:34] <ogra> i'll look at it
[07:34] <siretart> grr
[07:35] <siretart> now this was weird
[07:35] <siretart> I could still type in my shell
[07:35] <siretart> but I couldn't click anywhere on my desktop
[07:35] <siretart> killing gnome-screensaver helped
[07:35] <siretart> wtf?!
[07:37] <kelmo> evil gtk stuff ; )
[07:37] <kelmo> later
[07:45] <ogra> siretart, hmm, th eonly idea i'd have would be to always disable the screensaver if mplayer starts ...
[07:45] <ogra> i guess their visuals clash ...
[07:46] <ogra> i patched only the --no-xscreenaver option to handle g-s-s as well ... nothing else ...
[07:47] <siretart> ogra: hm. intersting
[07:49] <ogra> oh, err
[07:49] <ogra> you are aware that this is a debian imported bug ?
[07:51] <siretart> debian has no mplayer
[07:52] <ogra> "...This is obviously a mplayer bug but mplayer wasn't availabale to select (why?)..."
[07:52] <siretart> interesting
[07:53] <ogra> it comes from ubuntu bugzilla but was imported there already from debian it seems
[07:53] <siretart> lets see if he answers. if he doesn't just close it in a week or so
[07:53] <ogra> yep
[09:30] <bddebian> Heya gang
[09:31] <bmonty> hi bddebian
[09:31] <crimsun> hey bddebian, bmonty
[09:31] <bddebian> Heya bmonty, crimsun
[09:34] <LaserJock> hiya bddebian bmonty and crimsun !
[09:35] <bddebian> Hi LaserJock :-)
[09:36] <crimsun> (the list grows)
[09:36] <crimsun> hi LaserJock
[09:37] <crimsun> mm I see some users are angry at the wpasupplicant update
[09:38] <bmonty> they shouldn't run dapper then
[09:38] <crimsun> well, that's kinda our fault
[09:38] <crimsun> we failed to provide an upgrade path
[09:39] <bmonty> where are they complaining?
[09:41] <crimsun> https://lists.ubuntu.com/archives/ubuntu-users/2006-March/071277.html
[09:54] <ajmitch> hi
[09:54] <crimsun> 'morning, ajmitch
[09:54] <LaserJock> hi ajmitch
[10:04] <bmonty> crimsun: I think that guy doesn't really have much of an argument
[10:04] <bmonty> you'd have to make some fairly invasive changes to the package to provide an upgrade path
[10:04] <bmonty> would that be worth it?
[10:07] <bddebian> Heya ajmitch
[10:32] <bmonty> interesting two versions of the same package just got announced on dapper-changes
[10:33] <bddebian> w00t
[10:33] <LaserJock> hmm, how does that work out?
[10:34] <bmonty> you'd think the second one would have been rejected
[11:07] <bmonty> anyone have a hoary chroot?
[11:44] <LaserJock> hi tritium_
[11:45] <tritium_> hi LaserJock
[11:48] <bddebian> tritium_:!!!
[11:49] <tritium_> hey bddebian :)