[12:02] <sivang> mdz: any info on the lanchpad integration into the menu panel bounty? is there a wiki page for that or bugzilla entry?
[12:06] <mdz> lamont: looks like sizeof(unsigned int) != sizeof(unsigned long) problems
[12:07] <lamont> GAH!
[12:07] <lamont> simple, or systemic?
[12:08] <Kamion> meh, why does 'reboot' in d-i suddenly not work?
[12:10] <mdz> lamont: systemic
[12:11] <Kamion> or maybe I should be blaming busybox ... hmm
[12:11] <mdz> reboot is hard to screw up
[12:11] <robtaylor_> Kamion: umm, i was wondering before.. why deos d-i still use busybox-cvs?
[12:11] <mdz> kill -INT 1
[12:11] <mdz> robtaylor: yes
[12:12] <Kamion> robtaylor_: what else would make any sense?
[12:12] <robtaylor_> Kamion: umm, hasn;t busybox 1.0 been released for some time?
[12:12] <lamont> mdz: that's another mark for ia64, hten.
[12:12] <Kamion> robtaylor_: the busybox package in Debian is ancient
[12:12] <Kamion> robtaylor_: in Ubuntu, we need some stuff newer than 1.0
[12:13] <Kamion> so *shrug* it's not worth the size of the diff it would take to change
[12:13] <robtaylor_> Kamion: ah, righty :)
[12:13] <Nafallo> noone is working on #5256, right?
[12:13] <Nafallo> ((except me then ;-) ))
[12:13] <Kamion> robtaylor_: and the diff from busybox-cvs to 1.0 doesn't seem to be too important, AFAIK
[12:14] <mdz> lamont: I can fix it trivially if I disable a bunch of stupid shit
[12:14] <mdz> this thing is such crap
[12:14] <robtaylor_> Kamion: heh. i was just about to say, actually you're using cvs lower than the 1.00 release..
[12:14] <robtaylor_> s/lower/older
[12:14] <mdz> if you give it the --best option, it tries zlib compression levels 1-9 and chooses the one with the smallest size
[12:14] <mdz> which ends up being 9
[12:14] <mdz> always
[12:14] <Kamion> mdz: actually I suspect I screwed up by typing '/sbin/init' rather than 'exec /sbin/init'. whoops
[12:14] <lamont> mdz: go figure...
[12:17] <Kamion> mdz: is there any reason that we couldn't lose /sbin/hotplug.real entirely in d-i?
[12:17] <mdz> lamont: emailed you a patch which will get you going
[12:17] <mdz> Kamion: if you switch to udevsend, none
[12:18] <mdz> it breaks the stupid shit in favour of fixing the bit we actually use
[12:18] <mdz> I'll work up a more correct patch later
[12:18] <Kamion> goodie, though I'll need a small fix to debian-installer/build/Makefile before removing it
[12:18] <lamont> mdz: meaning I should upload the patch, or just install it in the chroot?
[12:19] <mdz> lamont: that patch should probably not go into the archive
[12:19] <Kamion> mdz: you were talking to lamont and not me there?
[12:19] <mdz> Kamion: correct (regarding the cloop-utils patch)
[12:19] <Kamion> ok
[12:20] <lamont> mdz: OK.  getting taken away for some family stuff now, if that's ok...
[12:23] <Nafallo> YES! Fixed my first Ubuntu-bug :-P
[12:23] <sivang> Nafallo: # ?
[12:24] <Nafallo> 5256
[12:26] <Nafallo> just have to make the changes look more nice, generate the patch and add it on bugzilla :-)
[12:36] <Nafallo> when to mark a bug fixed?
[12:36] <Kamion> when the fix is in the archive
[12:37] <Kamion> not just when a patch has been suggested, if that's what you're thinking
[12:37] <Nafallo> oki
[01:33] <mdz> jdub: which bit of that advogato diary did you mean for me to see?
[01:35] <jdub> mdz: the ssh-add on first ssh invocation bit
[01:35] <chrisa> ssh-add on ssh invocation sounds useful
[01:35] <Mithrandir> jdub: url?
[01:36] <jdub> http://www.advogato.org/person/mbrubeck/diary.html?start=90
[01:36] <jdub> just a shell script
[01:37] <Mithrandir> it's neat, though
[01:38] <mdz> I think we talked about that sometime last year
[01:39] <jdub> mmm, thus my interest ;0
[01:39] <jdub> ;)
[01:54] <mdz> trulux: ping?
[01:56] <mxpxpod> have the hotplug patches worked on in mataro been put into hotplug for powerpc?
[01:59] <Keybuk> mxpxpod: which ones?
[02:03] <Keybuk> if you mean the asynchronous stuff, no.  we've deferred that to hoary+1 as it involves fairly large changes and we'd rather have more time to work on them
[02:05] <Mithrandir> people who use implicit sizes and think that sizeof(long) == sizeof(int) should be shot.
[02:07] <mdz> Mithrandir: looking at cloop?
[02:07] <Mithrandir> yeah
[02:08] <mdz> Mithrandir: unless you enjoy it, there's no need; I asked Charles to look at it tomorrow
[02:08] <mdz> he doesn't seem to have a bugzilla account yet, but I mailed him
[02:09] <Mithrandir> ok; I'll see if this tiny little change fixes it, if so, I have a fix.  Not a real fix, since that means getting rid of loads of cruft, but a fix.
[02:10] <mdz> I already gave lamont the quick fix
[02:11] <mdz> (changing len to unsigned long and deleting the code which uses compress.cc)
[02:11] <mdz> that code is only used when --best is passed, which is a silly thing to do anyway
[02:11] <Mithrandir> ah, ok.
[02:15] <mdz> Kamion: is daily-live daily now, or still manual?
[02:31] <Safari_Al> jdub, yo?
[02:32] <Safari_Al> jdub, just wanting to check about those docs :)  Have to head off now but I'll be back later this arvo.
[02:32] <mdz> whee, just got powerpc live CD going
[02:33] <mxpxpod> Keybuk: ah, ok
[02:33] <mxpxpod> Keybuk: thanks for the update :)
[05:46] <stub> Weird - Can someone try and repeat this?
[05:46] <stub> Fire up the volume control, and play some music. Now switch back and forth between the OSS and Alsa mixers (File -> Change Device)
[05:47] <stub> I'm noticing quite distinct changes in sound
[05:47] <stub> Like some of the hidden controls are being randomly reset
[05:48] <jdub> stub: they're not synced
[05:48] <jdub> stub: so when you change them around, they're flipping back and so on
[05:49] <stub> Yeah - but if I switch to one, and switch back *it sounds different* to what I started with
[05:50] <stub> Hmm... seems to be only if I have the 3d controls turned up on the Alsa mixer.
[05:51] <stub> mmm... yes... jack up the 3d controls and every time you switch back to the Alsa mixer you get a different mix ;)
[05:56] <jdub> :-)
[05:57] <`anthony> stub: That's because ALSA mixer was designed by crackheads.
[05:57] <zenrox> and oss by potheads
[05:58] <zenrox> witch one works better
[05:58] <zenrox> lol
[05:58] <`anthony> zenrox: I'll take the OSS mixer over the 22 separate mixer controls that ALSA gives my onboard sound.
[05:59] <`anthony> (no, that's not a joke. _22_ controls.)
[06:00] <zenrox> `anthony,  ya same here but alsa imho is better casue of the 22 controles it gives me
[06:00] <zenrox> oss only has a few
[06:02] <`anthony> zenrox: riiiight. sure. tell me, quick: for correct behaviour of the microphone, what settings should Mic, Mic Select and Capture devices have (settings == mute/no mute, capture/no capture, volume/no volume) ?
[06:03] <`anthony> If you answered Mic: Muted, Capture, Capture: Not Muted, not Capture, Mix: no volume, no muted -- then you win a cookie.
[06:04] <jamesh> `anthony: in part, that is a problem with the user interface
[06:05] <`anthony> jamesh: Well, the UI is just reflecting the underlying settings of the "devices". 
[06:06] <`anthony> But in any case, there needs to be a higher-level UI - shtoom's growing one when running under ALSA. It will fix the settings up for you (after prompting).
[06:06] <jamesh> `anthony: yep, and most of them shouldn't be visible by default (many are only useful to audio geeks)
[06:07] <`anthony> jamesh: more importantly, the standard "audio mixer" program should check for sane settings each time it's run, and prompt "Your audio device settings are all fucked up. Should I fix them? Yes/No"
[06:07] <jamesh> `anthony: btw, some sound cards provide even more mixer settings in alsa: http://people.redhat.com/~alexl/files/why-alsa-sucks.png
[06:08] <jamesh> `anthony: yep.  ALSA's policy of setting all levels to zero by default is a problem
[06:08] <jamesh> it is basically a cop-out on picking sensible defaults
[06:08] <`anthony> I've seen people run alsamixer, not realize it's doing anything, and smack on keys and end up with muted master, or capturing on the mono output, or whatever.
[06:09] <jamesh> sure.
[06:09] <`anthony> hence the shtoom 'fix-the-audio-settings-for-you' mode.
[06:09] <`anthony> trying to debug this stuff remotely is more than a pain.
[06:09] <jamesh> the Windows mixer only shows a few standard channels by default
[06:09] <jamesh> and has a prefs dialog where you can show/hide all the weird ones.
[06:10] <bob2> you shtoom-hippy
[06:10] <`anthony> the one for linux should, too. in addition, the 'Capture' flag should be set intelligently, and the basic UI should _not_ let you change it.
[06:10] <pasc> `anthony: you broke me
[06:10] <jamesh> `anthony: have you looked at the gnome-2.8 volume control app?
[06:10] <pasc> `anthony: I bought a mouse exactly like yours when I went through HK
[06:11] <jamesh> it looks a lot better than the screenshot above ;)
[06:11] <bob2> also because everytime I see 'shtoom' I think 'shroom'
[06:12] <`anthony> jamesh: It says "Sorry, no mixer elements and/or devices found", and then exits. You're right, that looks much better than alsamixer ;)
[06:12] <fabbione> morning
[06:12] <`anthony> pasc: ziplinq.com
[06:13] <jamesh> `anthony: okay then.  Have you tried it on a working system? :)
[06:13] <`anthony> jamesh: I think it's expecting the OSS-compat devices, but I killed those.
[06:14] <jamesh> `anthony: it should do ALSA too.
[06:14] <`anthony> The only thing that was still using them was #&*($(#$& flash, and I wanted it to stop with the noise-making banner ads.
[06:14] <`anthony> jamesh: looks like it relies on esd or gstreamer.
[06:14] <jamesh> ah.  the volume control does let you turn off channels now
[06:15] <jamesh> although it has everything turned on by default.
[06:40] <mdz> fabbione: morning
[06:41] <sivang> mdz,fabbione : morning.
[06:42] <fabbione> mdz: hey.. i might be a bit late tomorrow for the CC meeting, but hopefully not.
[06:42] <fabbione> mdz: do you want me to prepare a draft for the kernel team?
[06:43] <fabbione> or do you want to lead it directly?
[06:47] <mdz> fabbione: just make sure that the kernel team item is low on the agenda, so that you're there when we start to discuss it
[06:47] <mdz> fabbione: a draft what?
[06:54] <Keybuk> I'm sure what I'm doing here is wrong
[06:54] <Keybuk> but it feels so right
[06:54] <Keybuk> I have two checkouts, one I've been fucking around with, and another that's clean
[06:54] <Keybuk> and I'm gradually committing my fucking about my copying stuff from the dirty to the clean one
[06:54] <Keybuk> and then sync-tree'ing the dirty one to catch up
[06:55] <Keybuk> THIS IS WHAT HAPPENS WHEN YOU CAN'T DO PARTIAL COMMITS
[06:55] <jdub> tla commit -s "blah" -- file file file <- ?
[06:55] <Keybuk> jdub: doesn't work if you add, remove, move, copy, etc.
[06:56] <fabbione> mdz: it is already the last one.. a draft on how to organize the kernel team...
[06:58] <jdub> Keybuk: mmm
[06:59] <fabbione> mdz: do you have any particular interest in getting all the UML stuff from 2.6.11 into hoary?
[06:59] <mdz> fabbione: no
[07:00] <jdub> My name is Nceba Botha working at Tshwane University of Technology in
[07:00] <jdub> Pretoria, South Africa.  We have just installed Ubuntu Linux as a print
[07:00] <jdub> server but we are struggling with the root password.  Is there a default
[07:00] <jdub> root password in Ubuntu?  If not how do we configure it?
[07:00] <jdub> 
[07:00] <jdub> ;-)
[07:02] <fabbione> hehe
[07:03] <sivang> heheh
[07:03] <sivang> jdub: we need to add this on the disk stored wlecome page.
[07:04] <sivang> jdub: (maybe, thinking out loud)
[07:04] <sivang> jdub: that is , instructions how to enable / use sudo
[07:04] <jdub> sivang: thing is, normal users don't care
[07:05] <Treenaks> jdub: hm.. when I started reading I thought it was some 419 spam you pasted...
[07:05] <Treenaks> jdub: it could at least link to the wiki more prominently
[07:05] <Treenaks> jdub: ("if you have more questions, look on the wiki")
[07:05] <jdub> yep
[07:06] <sivang> Treenaks: heheh, really sounded like this - I got a couple asking me to take their 40$G for them , until they can take it back...
[07:06] <sivang> jdub: I'll ad this to the wishlist.
[07:13] <mdz> sivang: that's more or less implicit in what's already there
[07:14] <mdz> I added an item requesting that there be more effective links to existing documentation
[07:16] <fabbione> mdz: there are some rumors that they might release a 2.6.10.1 or 2.6.11 pretty soon to include the security fixes....
[07:16] <sivang> mdz: I saw those, but maybe a specific link to that notion of sudo for people coming from other os's ? I mean, that's a central aspect of the system's managemtn
[07:16] <mdz> fabbione: will you be uploading the kernel today?
[07:16] <fabbione> mdz: yes for 2.6.10
[07:17] <mdz> sivang: my instinct is that there is very little overlap between the people who will read the "about ubuntu" page and people who wonder about things like root passwords
[07:17] <mdz> fabbione: ok, good.  I need that dm-snapshot/powerpc fix
[07:17] <bob2> it's in the FAQ and people still refuse to read it
[07:17] <fabbione> mdz: hmmm i still didn't see it in the bk changelog i am parsing.. 
[07:18] <fabbione> mdz: i will make it so :-)
[07:18] <mdz> fabbione: the one I filed a bug about in ubuntu bugzilla
[07:18] <mdz> it is not upstream
[07:18] <fabbione> ah ok
[07:18] <fabbione> i didn't check bugzilla yet
[07:18] <mdz> https://bugzilla.ubuntu.com/show_bug.cgi?id=5372
[07:18] <mdz> trivial
[07:18] <mdz> for some reason, powerpc has a separate md-modules list for the udeb
[07:19] <mdz> but it should be the same as the others
[07:19] <mdz> fabbione: with that fix, we can have powerpc live CDs today
[07:19] <fabbione> sure no problem
[07:19] <mdz> thanks
[07:20] <mdz> daniels: what's the status of the live cd X configuration issue?
[07:21] <sivang> mdz: right, not about root passwords, but how you use sudo for system managment tasks, which are not available from the gui yet, but maybe there are none anymore, however I may be wrong so this is a mere suggestion.
[07:25] <mdz> sivang: we can only lead the user to documentation; we cannot make them read it
[07:26] <zenrox> mdz tho we should
[07:26] <zenrox> lol
[07:27] <sivang> mdz: ok
[07:29] <fabbione> mdz: 5372 pending upload
[07:30] <trulux> mdz: pong, just near to go to school
[07:30] <trulux> mdz: howya?
[07:30] <mdz> trulux: ping me when you have time to discuss the requirements doc you wrote in the wiki
[07:30] <trulux> mdz: ok, now i must go to school
[07:30] <mdz> yes, I heard
[07:30] <trulux> mdz: have a nice day!
[07:31] <mdz> goodbye
[07:54] <doko> good morning all
[07:58] <sivang> doko: morning
[07:59] <doko> lamont: what are you doing with the buildds? gcc-3.4 did build some hours later on powerpc and ia64 ...
[08:00] <mdz> fabbione: how much smaller do the linux-image .debs get if you use bzip2 compression?
[08:00] <mdz> lamont is likely to be asleep
[08:02] <fabbione> mdz: dunno...
[08:02] <fabbione> let me check
[08:03] <fabbione> the source approx 10Mb
[08:03] <fabbione> i will need to run a test build to see the .deb
[08:04] <mdz> yes, the next time you run a build, please measure
[08:05] <mdz> I thought it might be useful to bzip2 the 686{,-smp} and k7{,-smp} kernels if they would be significantly smaller
[08:05] <mdz> because they are very frequently downloaded
[08:07] <mdz> ok, good night
[08:09] <fabbione> night :-)
[08:13] <doko> mdz: lrm: yes, each module increases to 4.5mb size
[08:14] <doko> fabbione: how to rename the lrm package, if I need to add new tarballs (binary files)
[08:16] <d3vic3> morning 
[08:16] <fabbione> doko: hmmmm i need to check... gimme a sec
[08:17] <d3vic3> fabbione, help 
[08:17] <fabbione> linux-restricted-modules-2.6.10 -> linux-restricted-modules-2.6.10.0 perhpas?
[08:17] <fabbione> d3vic3: ?
[08:17] <d3vic3> fabbione, how do I assing a bug to myself ?
[08:18] <fabbione> d3vic3: on bugzilla?
[08:18] <d3vic3> s/assing/assign/
[08:18] <d3vic3> yes
[08:18] <fabbione> open the bug
[08:18] <doko> fabbione: ok, will do.
[08:19] <fabbione> there is a thumb: Reassing to:
[08:19] <fabbione> put your email address in there and push on commit
[08:19] <fabbione> d3vic3: you need to use your bugzilla account email address
[08:19] <d3vic3> ok
[08:19] <fabbione> doko: that's just an idea..
[08:19] <fabbione> you will have to check that it doesn't break anything
[08:20] <fabbione> doko: also at packages that come out of it
[08:20] <fabbione> since ubuntu-meta uses them somehow
[08:20] <fabbione> doko: otherwise uuencode and add it as real binary in the next release
[08:25] <daniels> mdz: looking at it now, I think I know how to do it
[08:26] <Mithrandir> daniels: why did you wonder about whether I'm using an ATI card?
[08:28] <doko> fabbione: hmm, yes, uuencoding should be safer approach
[08:39] <fabbione> doko: remember to bump the nvidia and fglrx versions in debian/rules
[08:49] <fabbione> Keybuk: ping
[08:52] <Keybuk> fabbione: yo
[08:52] <fabbione> Keybuk: sorry that i need to bother you
[08:52] <fabbione> dpkg --build calls dpkg-deb right?
[08:53] <fabbione> so if i need to tell dpkg to use bzip...
[08:53] <fabbione> dpkg --build -Zbzip2 ?
[08:53] <fabbione> unfortunatly the kernel package is so complicated that i can't just swith to use dh_buildeb
[08:53] <fabbione> as in the example
[08:54] <Keybuk> I think that'll work
[08:54] <crimsun> is it -Z or -z?
[08:54] <Keybuk> dpkg --build ... => dpkg-deb --build ...
[08:54] <Keybuk> -Zbzip2
[08:54] <crimsun> k, thanks
[08:55] <fabbione> Keybuk: can i just export an ENV var to automatically switch to bzip instead of having to modify the scripts?
[08:56] <Keybuk> no, you have to modify the scripts as it's a per-package decision
[08:56] <Keybuk> otherwise you could accidentally build things the wrong way
[08:56] <fabbione> Keybuk: ok
[08:56] <Keybuk> I would be surprised if the kernel benefits
[08:56] <fabbione> ok
[08:56] <fabbione> it might...
[08:56] <fabbione> we need to give it a shot
[08:57] <Keybuk> bzip2 is generally better for mostly-text packages
[08:57] <fabbione> but to do that i need to modify kernel-package first
[08:57] <fabbione> that's why i was hoping for an ENV var that i can export in the main kernel package
[08:57] <fabbione> and propagates down to all the mess
[08:57] <fabbione> thanks mucho dude
[08:58] <Keybuk> no worries
[09:34] <Mithrandir> why is python-gtk2-doc in universe and not main?
[09:37] <crimsun> My guess is that no one has stepped up to maintain it. It doesn't seem to be a licensing issue regarding the documentation.
[09:39] <d3vic3> mdz, ping
[09:42] <fabbione> he is asleep
[09:42] <d3vic3> cloop won't build 
[09:43] <d3vic3> fabbione, help
[09:43] <d3vic3> ./debian/rules build <-- just gives me errors 
[09:44] <Mithrandir> d3vic3: use dpkg-buildpackage
[09:46] <fabbione> d3vic3: cloop kernel module or utils?
[09:46] <fabbione> there is no need to build the kernel module since we already have it
[09:46] <d3vic3> utils I think 
[09:46] <fabbione> in the main kernel
[09:46] <fabbione> hey pitti
[09:46] <d3vic3> I'm trying to fix a bug 
[09:46] <pitti> Hi guys
[09:46] <d3vic3> but i can't build it to begin with 
[09:47] <fabbione> pitti: you got mail
[09:47] <d3vic3> dpkg-buildpackage give same error 
[09:47] <fabbione> pitti: i have some other pending stuff from debian
[09:47] <fabbione> d3vic3: be more specific
[09:47] <fabbione> show us the error at least
[09:47] <Treenaks> d3vic3: did you install the build-depends?
[09:47] <pitti> fabbione: you mean the enhanced do_brk patch?
[09:47] <d3vic3> yes
[09:48] <fabbione> pitti: yes
[09:48] <d3vic3> /home/knopper/advancecomp-1.9_create_compressed_fs/missing: No such file or directory
[09:48] <fabbione> i have others security stuff from debian
[09:48] <pitti> fabbione: what about all the other occurrences of do_brk? They are not fixed by this patch AFAICS
[09:48] <fabbione> pitti: that one fix them all
[09:48] <fabbione> linus did that commit
[09:48] <fabbione> and there is nothing in bk
[09:48] <fabbione> other than that
[09:49] <pitti> hmm, ok
[09:49] <d3vic3> fabbione, gives the error above 
[09:50] <fabbione> d3vic3: apt-get source cloop-utils (or whatever they are called)
[09:50] <fabbione> apt-get build-dep cloop-utils
[09:50] <fabbione> go in the source
[09:50] <fabbione> do your changes
[09:50] <fabbione> dpkg-buildpackage
[09:51] <d3vic3> did all that 
[09:51] <d3vic3> still give me error when i try to build 
[09:51] <fabbione> d3vic3: bug number?
[09:51] <d3vic3> #5376
[09:54] <fabbione> d3vic3: works fine here
[09:54] <fabbione> you need to check your environment...
[09:56] <d3vic3> ok 
[09:56] <d3vic3> that is ? 
[09:57] <fabbione> it depends what you are doing....
[09:57] <d3vic3> jut trying to build the package 
[09:57] <fabbione> what modifications you did to the package
[09:57] <fabbione> and so on
[09:58] <d3vic3> so far 
[09:58] <d3vic3> nothing 
[09:58] <d3vic3> becouse i can't even build it 
[09:58] <fabbione> d3vic3: ayou you runnig hoary?
[09:59] <d3vic3> no
[09:59] <d3vic3> warty
[09:59] <Mithrandir> d3vic3: there's something funky on your system, check that you have enough free space.
[10:00] <fabbione> d3vic3: if you need to do development for hoary
[10:00] <fabbione> you need to either run hoary or have a hoary chroot
[10:00] <amu> moins 
[10:00] <d3vic3> hmm 
[10:00] <fabbione> you are probably trying to fix something on an old version of the package
[10:00] <fabbione> hey amu
[10:00] <d3vic3> oh right 
[10:01] <d3vic3> we don't have enough bandwidth for me to update to hoary here 
[10:01] <jdub> anyone got an nforce3-based amd64 machine?
[10:01] <d3vic3> I think
[10:02] <daniels> jdub: i'll have an nf4-based amd64 soon
[10:02] <fabbione> you all suck
[10:02] <fabbione> i want an amd64 too
[10:02] <jdub> daniels: nf4... yeek
[10:02] <jdub> fabbione: i don't have on e;)
[10:02] <jdub> fabbione: just checking if nf3 doesn't suck for my housemate
[10:02] <Mithrandir> jdub: seems I have one, why?
[10:02] <Kamion> mdz: still manual, will fully automate RSN
[10:02] <jdub> Mithrandir: how's the sata/lan/audio/etc hadware suport?
[10:03] <amu> fabbione: buon giorno ;) 
[10:03] <Mithrandir> jdub: working, I think.  We haven't checked th audio, but apart from that, it works.
[10:03] <Kamion> morning all
[10:03] <Mithrandir> hi Kamion
[10:05] <jdub> Mithrandir: cool, thanks
[10:05] <Mithrandir> jdub: it's running sarge just fine at least.
[10:06] <daniels> jdub: heh, should be fun
[10:07] <amu> daniels: matt told me, i should test your Xconfigurator :)   
[10:11] <daniels> amu: sure
[10:11] <daniels> amu: export XORGFORCEPROBE=yes && sudo dpkg-reconfigure -phigh xserver-xorg
[10:11] <daniels> amu: make sure you have dpkg-dev installed
[10:28] <Kamion> fabbione: oh, you haven't finalised this kernel upload yet have you?
[10:29] <Kamion> fabbione: I'd like the rtc module to be available in a udeb
[10:29] <fabbione> Kamion: not yet..
[10:29] <fabbione> just tell me what and where and it will be in :-)
[10:30] <Kamion> is there any other udeb where it would fit neatly? I couldn't think of one
[10:30] <fabbione> no idea...
[10:30] <fabbione> do we have a misc module udeb?
[10:30] <Kamion> if not, rtc-modules would be great; amd64 and i386 should have it, and on sparc you'll want to add rtc-modules to the kernel-image Provides in debian/d-i/sparc/package-list
[10:31] <Kamion> having it separate would probably work well for dependencies, since it's only the timezone question that needs it
[10:31] <Kamion> shall I add it to kernel-wedge?
[10:32] <fabbione> hmmm
[10:33] <Kamion> yeah, I should, I think
[10:33] <fabbione> only i386 and amd64 has it has module
[10:33] <Kamion> yep
[10:33] <fabbione> i think we should just inline it
[10:33] <fabbione> hppa/sparc/ia64 is compiled in
[10:33] <fabbione> and ppc too
[10:33] <fabbione> instead of adding another module...
[10:33] <Kamion> however you'll need to provide the package description etc. yourself if it's not in kernel-wedge
[10:33] <Treenaks> Kamion: I have some GPS-detecting python code (for yet another way to determine location/timezone/exact time).... but that'd make the installer depend on python-serial :P
[10:33] <fabbione> s/module/udeb
[10:34] <Kamion> ia64 and powerpc don't have it at all; CONFIG_RTC is not set
[10:34] <fabbione> Kamion: they have CONFIG_GEN_RTC
[10:35] <Kamion> hm, ok
[10:35] <Kamion> so you mean you think it should just be compiled into all kernels?
[10:35] <fabbione> i think so yes
[10:35] <fabbione> that would save us another udeb
[10:35] <Kamion> it's 21K
[10:36] <Kamion> udebs are relatively cheap, but it's up to you :)
[10:36] <fabbione> Kamion: ok.. let's make it a udeb
[10:36] <fabbione> i would suggest to create a misc-modules
[10:37] <fabbione> a bit more generic to fit all these "strange" categories
[10:37] <Kamion> seems a bit misleading since it isn't drivers/misc/
[10:37] <fabbione> hmmm ok
[10:37] <fabbione> just tell me what to add to debian/d-i/
[10:37] <fabbione> and i will do
[10:37] <Kamion> rtc-modules is more useful to me that misc-modules, because with the latter I have to depend on something weird and generic rather than on something specific that describes exactly what I want
[10:38] <Kamion> hm, is genrtc.ko useful on systems that have rtc.ko?
[10:38] <Kamion> s/that misc-modules/than misc-modules/
[10:39] <Kamion> config GEN_RTC
[10:39] <Kamion>         tristate "Generic /dev/rtc emulation"
[10:39] <Kamion>         depends on RTC!=y && !IA64 && !ARM
[10:39] <fabbione> genrtc conflitcs with rtc
[10:39] <fabbione> is either one or the other
[10:39] <fabbione> according to the arch
[10:39] <Kamion> I wonder why we have both as modules on amd64
[10:40] <fabbione> imho because it is possible
[10:40] <Kamion> heh
[10:43] <Kamion> fabbione: ok, build-dep on kernel-wedge (>= 1.25.1ubuntu3), 'echo common/rtc-modules > debian/d-i/i386/modules/i386/rtc-modules.lnk; echo common/rtc-modules > debian/d-i/amd64/modules/amd64/rtc-modules.lnk', and add ", rtc-modules" to the end of the two Provides_* lines in debian/d-i/sparc/package-list, please?
[10:45] <Kamion> hm, should probably do the Provides in ia64 and powerpc too, but only if you can be bothered :)
[10:45] <fabbione> of course i can
[10:45] <Kamion> ia64 is easy, for powerpc you'll need to add a Package: kernel-image block to the top
[10:46] <Kamion> dependency correctness there isn't vital, it'll just suppress a few whines in /var/log/debian-installer/syslog
[10:46] <fabbione> Provides_sparc64: ext2-modules rtc-modules
[10:46] <fabbione> something like this...
[10:47] <Kamion> Provides_sparc64: ext2-modules, rtc-modules
[10:47] <fabbione> right
[10:47] <Kamion> thanks dude, $beer{fabbione}++
[10:47] <fabbione> eheh no problem man
[10:48] <fabbione> Package: kernel-image
[10:48] <fabbione> Provides: rtc-modules
[10:48] <fabbione> this is for ppc
[10:48] <Kamion> at some point I may ask for a mouse-modules udeb, but that's in the future since I haven't got gpm working smoothly with fb yet ...
[10:48] <Kamion> fabbione: that's cool
[10:48] <daniels> noooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
[10:48] <fabbione> Kamion: well we are at it.. let's do it
[10:48] <fabbione> all this stuff needs to go via NEW
[10:49] <Kamion> fabbione: I'm not quite sure what needs to be added yet
[10:49] <Kamion> and it's all bluesky yet ...
[10:49] <fabbione> Kamion: ok
[10:49] <Kamion> besides I have the feeling that daniels wants to kill me
[10:50] <daniels> Kamion: whatever gave you that impression? :)
[10:50] <fabbione> the latter is irrelevant imho :-)
[10:50] <daniels> i just, er, dropped something very heavy on my toe
[10:50] <daniels> (or heard that the second of my dogs will get put down after having one put down three months ago)
[10:50] <daniels> s/one/the first/
[10:50] <daniels> but, in all seriousness, gpm is probably a very bad idea
[10:51] <fabbione> Kamion: we might have to update kernel-wedge later on for hppa support.. but don't bother now
[10:52] <fabbione> it has probably one extra rtc-module
[10:52] <Kamion> daniels: any other suggestions for mouse support on fb?
[10:52] <Kamion> fabbione: hm, ok
[10:52] <fabbione> Kamion: -4 has preliminary hppa support, but i need the new configs from lamony
[10:52] <fabbione> lamont
[10:52] <daniels> Kamion: why?
[10:53] <fabbione> i really don't know what to answer to some of the stuff over there
[10:53] <Kamion> daniels: sabdfl suggested the ability to point-and-click at buttons in the newt frontend
[10:53] <Kamion> daniels: which newt does support
[10:53] <daniels> Kamion: in d-i?
[10:53] <Kamion> yeah
[10:53] <Kamion> it's a graphical-installer stopgap :)
[10:53] <Kamion> I like the idea if it can be pretty
[10:54] <daniels> i honestly don't think we gain anything from the ability to click on buttons, but not the ability to do the proper layout we've been discussing
[10:54] <Kamion> because the "tab to get to buttons, in more or less random order" thing does suck
[10:54] <fabbione> Kamion: mind to give me the contents of rtc-modules?
[10:54] <daniels> i suppose it's not so bad, as long as it never, ever, ever propagates to the installed system
[10:54] <fabbione> otherwise i will need to wait up to 2 hours before i can testbuild
[10:54] <Kamion> -drivers/char/genrtc.o
[10:54] <Kamion> -drivers/char/rtc.o
[10:54] <fabbione> danke
[10:55] <Kamion> daniels: it won't; there's a worry of how to autodetect the mouse type though
[10:55] <Kamion> of course we have to solve that for the graphical installer anyway
[10:56] <Kamion> I have a feeling that gpm's framebuffer support is, um, lacking; it just scribbles black squares over the screen when you move the mouse around
[10:57] <daniels> Kamion: hm
[10:58] <Kamion> at least on powerpc
[10:59] <pitti> Kamion: this worked fine on kernel 2.6.9
[10:59] <pitti> Kamion: it's broken for me on 2.6.10 too
[10:59] <pitti> Kamion: so I don't think that this is a gpm problem
[11:00] <Kamion> I'm running 2.6.9 here
[11:00] <pitti> hmm, odd
[11:00] <pitti> worked fine for me on 2.6.9
[11:01] <Kamion> you don't get a pretty mouse pointer anyway though, you just get a block
[11:02] <Kamion> so it may not be a usability win anyway
[11:02] <pitti> but at least the block worked as it should and did not delete the contents of my screen...
[11:03] <Kamion> powerpc too, or something else?
[11:04] <pitti> yes, ppc I think
[11:05] <fabbione> you are all dreaming
[11:05] <fabbione> the kernel is NOT broken
[11:05] <fabbione> it's your crappy hardware
[11:05] <fabbione> Kamion: since you are at it
[11:05] <pitti> Kamion: works fine on i386 on standard Ubuntu kernel (2.6.10) and VESA driver
[11:05] <pitti> Kamion: maybe this is a problem with the radeon driver then?
[11:05] <fabbione> i need you to test the emu10k1 build on ppc
[11:06] <fabbione> pitti: it's enough you can get it to build
[11:06] <fabbione> i don't need you to test it.. because there is none at the moment
[11:06] <pitti> fabbione: you can test building on davis
[11:06] <pitti> it's very fast and nice to work on :-)
[11:06] <fabbione> pitti: ok.. short version of the story
[11:06] <fabbione> davis doesn't build it
[11:06] <fabbione> i have no root access on the chroot
[11:06] <fabbione> perhaps it builds with another gcc
[11:07] <pitti> fabbione: you need root to build it?
[11:07] <fabbione> or something that i have no way to test on davis
[11:07] <pitti> fabbione: I can try it here if you want
[11:07] <fabbione> i need root to install another gcc
[11:07] <pitti> ah
[11:07] <fabbione> like 3.4?
[11:07] <fabbione> the error is pretty much a weird gcc message
[11:07] <fabbione> that happens only on pcc
[11:08] <pitti> fabbione: give me the package, I compile it with gcc-3.4 and send you the log
[11:08] <pitti> fabbione: but uh, it's not a complete kernel image?
[11:08] <pitti> fabbione: this lasts about 5 hours on my iBook :-)
[11:08] <fabbione> pitti: just grab 2.6.0 from hoary, change the EMU10K in debian/config/powerpc to build as module
[11:08] <fabbione> and build...
[11:08] <fabbione> it's enough on one of them
[11:08] <fabbione> i don't need you to build the world
[11:09] <pitti> 2.6.10 that is? :-)
[11:09] <pitti> okay, I'll do that
[11:09] <fabbione> but i need you to figure out why it fails
[11:09] <fabbione> yes 2.6.10
[11:09] <pitti> does the linux Makefile respect CC=gcc-3.4?
[11:09] <fabbione> pitti: yes afaik
[11:09] <fabbione> otherwise it's one line change in the makefile
[11:09] <crimsun> yes, set HOSTCC and CC
[11:10] <fabbione> just search for gcc ;)
[11:10] <pitti> right, actually I should continue with my security updates...
[11:10] <Kamion> pitti: could be, not entirely sure I can follow where selection.c goes
[11:11] <pitti> ?
[11:11] <pitti> Kamion: what about selection.c?
[11:13] <doko> fabbione: hint ... unpack cpp-3.4 and gcc-3.4 into your home directory, add the <unpack dir>/usr/bin to your path, and compile.
[11:13] <Kamion> it's what TIOCLINUX(TIOCL_SETSEL) calls, which is basically what gpm does to set the mouse pointer position
[11:13] <fabbione> doko: no way i am going to do stuff like that .. KTHXBYW
[11:13] <fabbione> ;)
[11:14] <fabbione> doko: i don't like these kind of things when it goes to get stuff done properly
[11:14] <fabbione> i prefer to have the things tested properly
[11:15] <pitti> world: please stop finding holes in the kernel! We _just_ released an update yesterday and how I know about 5 to 10 new issues
[11:16] <fabbione> pitti: is there anything i need to push in hoary today?
[11:16] <doko> fabbione: ok, just an intermediate solutions until our admins wake up ...
[11:18] <fabbione> doko: point is that we are not supposed to build with gcc3.4
[11:18] <fabbione> so if this is something special it needs to be discussed
[11:18] <fabbione> specially because we are going to build an entire kernel set on gcc3.4
[11:18] <fabbione> that might introduce a bunch of regressions
[11:18] <cartman> are there any plans to do a gcc 3.3->3.4 migration in the future?
[11:19] <fabbione> since kernel tends to be affected by different gcc
[11:19] <Treenaks> cartman: well, when it's released etc, probably
[11:19] <cartman> Treenaks: released what?
[11:19] <daniels> pitti: christ
[11:20] <Treenaks> cartman: both gcc 3.4 and hoary probably
[11:20] <cartman> Treenaks: ah I see but when hoary is release gcc 4.0 will be out possibly
[11:20] <cartman> :)
[11:20] <cartman> released*
[11:23] <fabbione> daniels: the acx100 thingy will have to wait. the code is messy and fuckign stupid
[11:24] <fabbione> daniels: i need to rewrite most of it
[11:24] <pitti> fabbione: I sent you a mail with a disclosed patch
[11:24] <pitti> fabbione: all other issues are not yet public
[11:24] <fabbione> pitti: thanks
[11:25] <pitti> fabbione: are the Debian patches basically fixes for Brad Spengler's issues?
[11:25] <fabbione> pitti: yes afaict
[11:25] <pitti> cool
[11:25] <fabbione> but i have seen no info from other sources
[11:25] <fabbione> only these few patches
[11:25] <pitti> fabbione: I sort them to the advisories later today
[11:26] <pitti> fabbione: but all of them are public, so having them in Hoary is good
[11:26] <fabbione> pitti: ok...
[11:26] <fabbione> ah yeah
[11:26] <fabbione> i saw the thread this morning
[11:27] <pitti> Mithrandir: any news regarding mailman?
[11:27] <daniels> fabbione: not just sed -i foo -e "s/^ACX100ISSHITHOUSE^/$KVERS/;"?
[11:28] <fabbione> daniels: no. that will break other stuff
[11:29] <fabbione> pitti: gmm debian has only 3/4 patches
[11:29] <fabbione> i need to check the rlimit stuff
[11:30] <daniels> fabbione: ?
[11:30] <fabbione> daniels: because somebody might actually have the firmware with the proper name
[11:30] <fabbione> and we can't break it
[11:31] <fabbione> plus there is a cascade of checks that needs to be done to load the correct one
[11:31] <fabbione> and each one has it's own filename
[11:31] <fabbione> so it doubles the check all over to find what is available
[11:31] <fabbione> and which one is the correct one
[11:31] <trukulo> ogra: u there? new version of graveman avalaible
[11:31] <trukulo> hi fabbio :)
[11:31] <fabbione> hey trukulo 
[11:32] <trukulo> i'm here learning how to make _good_ debs
[11:32] <Treenaks> trukulo: read Debian Policy :) it explains how :P
[11:33] <azeem> and use dpatch
[11:33] <trukulo> Treenaks: i know, i'm doing
[11:33] <ogra> trukulo: lintian is your friend ;)
[11:33] <fabbione> trukulo: stay away from dpatch.
[11:33] <trukulo> ogra: and linda :)
[11:33] <fabbione> that's all you need
[11:34] <trukulo> fabbione: i'll show your way, my master
[11:34] <trukulo> ups
[11:34] <trukulo> s/follow/show
[11:34] <fabbione> pitti: the missing patch is just a ddos
[11:34] <fabbione> pitti: but there is no linus-blessing on it yet
[11:35] <pitti> fabbione: Herbert created this patch and sent it upstream
[11:35] <fabbione> pitti: http://seclists.org/lists/fulldisclosure/2005/Jan/0270.html
[11:35] <pitti> fabbione: you can defer it if you want
[11:35] <fabbione> pitti: just grab the rlimit.diff from the tgz included in that url
[11:36] <fabbione> pitti: yes i saw that..
[11:36] <fabbione> i am not sure if it is in bk tho
[11:36] <fabbione> i can just apply and rename later...
[11:36] <daniels> fabbione: yeah, fair enough; want me to make the patch for you?
[11:37] <fabbione> daniels: that would be nice.. 
[11:37] <fabbione> if you have time...
[11:37] <fabbione> basically what needs to be rewritten is all the crap that tries to load the different firmwares
[11:37] <fabbione> in such a way that will test for <firmwarename>-EXTRAVERSION before the firmwarename
[11:38] <fabbione> remeber that we define EXTRAVERSION
[11:38] <fabbione> and that's the same that is used to name the firmware
[11:38] <daniels> fabbione: yeah, when I've finished up with the xorg config stuff
[11:38] <fabbione> yeah
[11:50] <seb128> elmo: here ?
[12:06] <Mithrandir> nautilus should _so_ be able to resume transfers which have gotten stuck.
[12:16] <seb128> Mithrandir: any news of the gaim upload ?
[12:18] <Mithrandir> it passed NEW in Debian the same evening
[12:20] <pitti> Hi Mithrandir 
[12:20] <pitti> Mithrandir: any news about mailman?
[12:21] <Mithrandir> pitti: hiya; yes, I've decided on how to go about with the 55_thingy; we can't just remove it, since it fixes a real problem.  I need to actually test it though.  
[12:21] <Mithrandir> so, expect a patch today.
[12:21] <pitti> cool
[12:22] <pitti> Mithrandir: will you upload a new sid version?
[12:22] <Mithrandir> yes
[12:22] <pitti> Mithrandir: with the new password algorithm?
[12:22] <pitti> nice
[12:22] <trukulo> ogra: olivier? new graveman package dude
[12:22] <Mithrandir> that's my intention, yes, but I don't see the need for that to go into a USN if you want one for warty.
[12:23] <seb128> Mithrandir: I know for Debian, but about hoary ? :)
[12:23] <pitti> Mithrandir: I won't fix the password generation for Warty right now
[12:23] <seb128> Mithrandir: we don't sync from experimental automatically, and as you said you were going to handle the new version ...
[12:23] <pitti> Mithrandir: by now I only want to fix the XSS and the 55_thingy
[12:23] <Mithrandir> seb128: ah, it's experimental, I forgot. :/
[12:23] <Mithrandir> pitti: yup, I agree.
[12:23] <Mithrandir> seb128: I'll do it once I finish breakfast and get to uni, then. :)
[12:24] <seb128> ok, thanks!
[12:24] <pitti> Mithrandir: I agreed with mdz to leave the new password thingy in sid/hoary for a while before we update warty
[12:24] <Mithrandir> do you want a hoary upload instead of just syncing from Debian?
[12:25] <pitti> Mithrandir: we need a hoary upload since hoary diverted from Sid (python2.4)
[12:26] <pitti> Mithrandir: so we need a merge
[12:26] <Mithrandir> nope
[12:26] <pitti> (according to the changelog)
[12:26] <Mithrandir> mailman doesn't follow that (silly) part of Debian's policy.
[12:26] <Mithrandir> at least, it shouldn't.  If it does, it's a bug.
[12:27] <pitti> Mithrandir: you mean it depends on "python" instead of e. g. "python2.3"? So we don't need to divert?
[12:27] <Mithrandir> pitti: correct.
[12:28] <Mithrandir> pitti: it depends on python (>= 2.1), iirc
[12:28] <pitti> Mithrandir: nice, then we should indeed just sync it
[12:34] <fabbione> rsync warning: some files vanished before they could be transferred (code 24) at main.c(1146)
[12:34] <fabbione> DOH!
[12:34] <fabbione> that was trying to rsync the daily iso
[12:34] <fabbione> ..
[12:35] <Kamion> odd
[12:36] <Kamion> I haven't been messing about at that level very recently
[12:37] <fabbione> hmmmmm
[12:37] <fabbione> i think my server is a bit... hmmm unreliable
[12:37] <fabbione> it refused to delete files in ubuntu/spool due to an IO error
[12:37] <fabbione> but the fs is clean
[12:40] <fabbione> Package: rtc-modules-2.6.10-1-386-di
[12:40] <fabbione> Kamion: do you like it? ;)
[12:41] <fabbione> and a bit of After Burner
[12:41] <Kamion> fabbione: sounds good to me
[12:42] <fabbione> i am building on i386
[12:42] <fabbione> i can't test the others because of the chroot not being updated
[12:42] <fabbione> that should be good enough
[01:16] <Kamion> "Need to get 0B/397MB of archives. After unpacking 1218MB will be used." <- updated warty CD
[01:19] <mvo_> Kamion: uhh, that's a lot of updates
[01:21] <trukulo> only bug fixes?
[01:21] <Kamion> those aren't updates, that's the desktop installation step
[01:21] <Kamion> I'm pleased about the fact that it doesn't have to get anything from the network
[01:21] <Kamion> trukulo: warty+warty-security
[01:21] <mvo_> ahhh
[01:28] <trukulo> Kamion: ok
[01:31] <fabbione> elmo: can you update kernel-wedge on concordia hoary chroot please?
[01:31] <fabbione> to ubuntu3
[01:33] <trukulo> fabbione: we're preparing videos of badopi talkings :)
[01:33] <fabbione> trukulo: nice :-)
[01:33] <trukulo> when we have it, we'll tell you
[01:33] <fabbione> thanks
[01:33] <trukulo> we have technical problems with a f***ng ba***rd
[01:38] <jdub> sivang: it was a stream, not recorded
[01:46] <sivang> jdub: eh....
[01:53] <sid77> hi
[02:01] <sivang> hi ogra_ !
[02:02] <ogra_> hi sivang :)
[02:03] <Treenaks> hey you both :)
[02:05] <pitti> Did anybody try a recent daily Hoary cd?
[02:05] <pitti> I just do, and now my computer is painfully slow
[02:05] <ogra_> mdz wrote about it on the ML
[02:06] <pitti> it takes about 5 seconds to execute a trivial command
[02:06] <pitti> and switching VTs lasts about 3
[02:06] <ogra_> dma was off when he tested it
[02:06] <fabbione> is that the live cd?
[02:06] <ogra_> whoah
[02:06] <pitti> ogra_: I checked, DMA was on. I disabled it for testing, but no change
[02:06] <ogra_> hmm
[02:06] <pitti> ogra_: no, that's a hoary install cd
[02:07] <sivang> Treenaks: hi!
[02:08] <sivang> pitti: hi :)
[02:08] <pitti> Hi sivang 
[02:08] <fabbione> pitti: is it .9 or .10 based?
[02:08] <pitti> fabbione: .10
[02:08] <pitti> fabbione: standard i386 kernel
[02:08] <fabbione> yup
[02:08] <fabbione> my machine seems a bit slower on I/O with 2.6.10
[02:09] <pitti> this has got nothing to do with "a bit slower"
[02:09] <ogra_> 3 sec for switching VTs ?
[02:09] <pitti> I could not even install the desktop system, because it already took 5 minutes to linstall libdv4
[02:09] <pitti> now I canceled this 
[02:09] <pitti> brb
[02:09] <crimsun> it takes my machine approximately 3 seconds to switch vts as well
[02:09] <fabbione> pitti: are you sure you are not on your m68k in i386 emulation?
[02:10] <fabbione> here is immediate
[02:10] <ogra_> lol
[02:10] <sivang> crimsun: this is a laptop?
[02:10] <fabbione> are you all running frambuffer?
[02:10] <crimsun> (hoary, 2.6.10-1-686-smp _and_ 2.6.10-hardened-1-686-smp)
[02:10] <fabbione> is there any message in the log?
[02:10] <fabbione> like dmesg
[02:10] <crimsun> no fb, strictly "nv" X.Org driver and normal vga console
[02:11] <fabbione> same here
[02:11] <fabbione> except i use the nvidia drivers
[02:14] <crimsun> I have a despairing hunch that this has something to do with my reenabling ACPI :/
[02:14] <pitti> I rebooted my desktop, now it runs fast again
[02:14] <pitti> however, this is a weeeird problem
[02:14] <fabbione> pitti: hold on..
[02:14] <fabbione> you said you were installing right?
[02:14] <pitti> fabbione: I did
[02:14] <pitti> I did not supervise it
[02:15] <fabbione> so.. you installed = ok.. reboot = slow .. reboot = ok?
[02:15] <pitti> but I have the strong feeling that some postinst script triggered this
[02:15] <pitti> fabbione: right
[02:15] <pitti> fabbione: well, even more:
[02:15] <pitti> fabbione: install after reboot = ok
[02:15] <fabbione> where reboot = slow was the second stage installed?
[02:15] <fabbione> installer even
[02:15] <pitti> fabbione: then I left for a while, returned, then it was slow
[02:15] <pitti> fabbione: yes, reboot after 1st stage
[02:15] <fabbione> HMMMMM
[02:16] <pitti> fabbione: I had to manually install the desktop system since CD packages could not be authenticated
[02:16] <pitti> so I did apt-get install ubuntu-desktop
[02:16] <fabbione> pitti if you modprobe the fb modules...
[02:16] <fabbione> does it become slow again?
[02:16] <pitti> are they modprobed in the middle of pacakge installation?
[02:16] <fabbione> no.. during base-config
[02:17] <pitti> no, it worked fine after b-c
[02:17] <fabbione> or better.. at base-config init
[02:17] <fabbione> ok
[02:17] <fabbione> than i dunno...
[02:17] <pitti> pacakge installation already started
[02:17] <pitti> while it ran, I worked at another shell (some ssh)
[02:17] <pitti> then I left, and when I returned, it was slow
[02:17] <pitti> hmm, I have to try this again at some time
[02:18] <pitti> fabbione: btw, I tried the kernel emu10k1 problem in the meantime, I /msg you
[02:18] <fabbione> i didn't see the /msg
[02:18] <fabbione> yeah
[02:18] <fabbione> the same i saw on davis
[02:23] <trukulo> fabbione: news for you
[02:23] <trukulo> http://linuxbcn.homeip.net:6969/
[02:23] <fabbione> did i win 200 Million dollars?
[02:23] <trukulo> torrents of videos
[02:23] <trukulo> more less
[02:23] <fabbione> ah ok...
[02:23] <fabbione> thanks :-)
[02:23] <trukulo> you win a bride for february :)
[02:24] <fabbione> is she rich or something? ;)
[02:25] <fabbione> hell... people are already downloading it..
[02:25] <fabbione> my reputation is totally trashed now
[02:25] <fabbione> :)
[02:25] <trukulo> sure :)
[02:25] <trukulo> don't know
[02:25] <trukulo> perhaps she is virgin
[02:25] <trukulo> (think about it)
[02:26] <fabbione> ehehe
[02:26] <sivang> fabbione: I am also :)
[02:26] <fabbione> sivang: virgin? or getting a bride?
[02:26] <sivang> fabbione: oops, not a virgin, downloading that is :)
[02:26] <trukulo> lol
[02:26] <fabbione> ahhaha
[02:27] <sivang> fabbione: hmmm bride? scary....;-)
[02:27] <ogra_> hehe
[02:28] <trukulo> jeff video published too
[02:33] <fabbione> trukulo: why the fabio_big seeds is down to 0?
[02:34] <fabbione> it killed the download...
[02:35] <trukulo> don't know
[02:35] <trukulo> it's the same for me, wait a moment
[02:35] <fabbione> sure..
[02:36] <lamont> doko: I think I gave it back again, dunno
[02:36] <trukulo> back again now
[02:37] <lamont> Kamion: you have email re anna/ia64 - please correct my iso-steps as needed.
[02:38] <fabbione> hey lamont 
[02:38] <fabbione> lamont: -4 is up with hppa support
[02:39] <fabbione> you will have to do the configurations and send them back to me for -5 inclusion
[02:39] <pitti> amu: I release the KDE libs security update now if you don't have any objections
[02:39] <fabbione> it will fail on the buildd so it is better that you just take it manually before wanna-build
[02:40] <fabbione> trukulo: thanks :-)
[02:40] <amu> pitti: ok 
[02:40] <pitti> amu: thanks for preparing them
[02:40] <amu> pitti: np
[02:41] <trukulo> fabbione: wanna your ass
[02:41] <fabbione> ehehe
[02:41] <amu> pitti: it would be nice if i get a build.log of it .... 
[02:41] <pitti> amu: you have to ask lamont for that, I don't have them
[02:41] <Kamion> lamont: (yes, you have to fix the Release file)
[02:42] <amu> lamont: ? 
[02:42] <lamont> amu: build log of?
[02:42] <amu> lamont: kdelib+base from warty 
[02:42] <lamont> amu@canonical.com?
[02:42] <amu> yeah 
[02:43] <lamont> both succeeded, you know...
[02:44] <trukulo> fabbione: can you put the notice about the videos on ubuntu web?
[02:44] <amu> lamont: hehe, nethertheless, i'll check it ;) 
[02:44] <fabbione> trukulo: just slam them in the wiki
[02:44] <lamont> amu: kdelibs sent, kdebase is going to have to wait about an hour - must take kids to school
[02:44] <amu> lamont: .... in hoary there was a problem :)  
[02:44] <trukulo> fabbione: put it on planet
[02:45] <fabbione> i don't have that access level to do so
[02:45] <fabbione> otherwise i would
[02:45] <amu> lamont: no prob .... i#ll ask you again till i get them 
[02:45] <Mithrandir> fabbione: just blog about them?
[02:46] <seb128> lamont: new metacity with your patch in the archive
[02:46] <lamont> seb128: round 1 or round 2?
[02:46] <elmo> seb128: you were looking for me?
[02:46] <seb128> 2
[02:46] <elmo> fabbione: concordia's updating now
[02:46] <fabbione> Mithrandir: i didn't add my blog anywhere yet...
[02:46] <fabbione> elmo: thanks
[02:46] <seb128> elmo: yep, did you do the glib2.0 and easytag sync ?
[02:47] <seb128> elmo: they are in the archive
[02:47] <elmo> doko: ?
[02:47] <trukulo> fabbione: tell mako
[02:47] <fabbione> Mithrandir: you can blog it too :-)
[02:47] <seb128> lamont: BTW do you have a short description for it ? To add to the gconf schema 
[02:47] <Mithrandir> fabbione: yeah, I know
[02:48] <seb128> elmo: s/are/are not/
[02:49] <elmo> seb128: gar, sorry.  done now 
[02:49] <seb128> elmo: np, thanks
[02:49] <pitti> mvo_: right now installation from daily hoary seems to be utterly broken
[02:49] <pitti> mvo_: I suspect it fails to isntall ubuntu-desktop because it cannot authenticate the packages on CD-ROM
[02:49] <Kamion> dailies are for debugging :-)
[02:49] <pitti> mvo_: is this possible/known?
[02:49] <mvo_> yes
[02:49] <Kamion> um; base-config turns off authentication
[02:50] <Kamion> for precisely this reason
[02:50] <pitti> Kamion: that's why I'm doing :-)
[02:50] <pitti> Kamion: (testing for debugging)
[02:50] <mvo_> Kamion: will it help when you have the ubuntu-keyring udeb?
[02:50] <Kamion> unless somebody changed the configuration variable name
[02:50] <Kamion> mvo_: kinda waiting for gpgv-udeb first to make sure the name doesn't change
[02:50] <mvo_> all right
[02:51] <Kamion> mvo_: that won't make any difference to base-config, though; what I need for *that* is to have the keyring automatically registered with apt-key
[02:51] <Kamion> mvo_: at the moment apt's postinst registers a key in the apt package rather than from ubuntu-keyring
[02:51] <mvo_> Kamion: so what you need is apt-key update in postinst of ubuntu-keyring? 
[02:55] <Kamion> mvo_: right
[02:56] <Mithrandir> trukulo: your uplink seems a bit slow?
[02:56] <trukulo> Mithrandir: it's slow
[02:57] <trukulo> it doesn't seem, it is
[02:57] <trukulo> it's a home connection in spain
[02:57] <trukulo> it's what we can afford
[02:58] <Mithrandir> if you want me to run the tracker here, I can do that; it'll save you some traffic at least.
[02:58] <trukulo> of course
[02:58] <trukulo> just tell me what do you need
[03:00] <sivang> Mithrandir: wow that would be cool
[03:00] <trukulo> (if you need something)
[03:00] <Mithrandir> trukulo: I need some stuff, just wait a second while I set this up
[03:00] <trukulo> ok
[03:02] <Kamion> urgh. in python, how do I get a tuple containing all the elements of a given list?
[03:02] <Kamion> so I have foo = [a, b, c]  and want (a, b, c)
[03:03] <Kamion> oops, never mind, tuple() does what I need
[03:04] <sivang> tuples are cool
[03:06] <Mithrandir> trukulo: you need to make new metafiles using for f in *.avi; do ./btmakemetafile.py $f http://tracker.err.no:6969/announce; done and then put the torrents online somewhere (I can host them fine)
[03:07] <trukulo> wait a sec
[03:07] <trukulo> think ppl hosting torrents is eating now, shit
[03:08] <trukulo> umm, perhaps i can do it...
[03:09] <Mithrandir> I can't make the meta-files as I don't have the complete files. :)
[03:09] <trukulo> ok, ok
[03:09] <trukulo> wait a sec
[03:14] <thom> sladen: ping?
[03:21] <Mithrandir> trukulo: arghle, of course the wired network here _had_ to go down right now :/
[03:21] <trukulo> :( of course
[03:21] <trukulo> don't worry
[03:21] <trukulo> we'll do in two or three hours, ok?
[03:21] <Mithrandir> I guess it'll be back in a couple of minutes.
[03:22] <fabbione> trukulo: i have stopped my downloads so you can get a bit of bw back
[03:23] <trukulo> don't worry
[03:23] <trukulo> have to go home now
[03:23] <fabbione> i have done already
[03:23] <trukulo> i'll continue
[03:23] <fabbione> i will wait Mithrandir to set the stuff up
[03:23] <trukulo> so you can resume :)
[03:24] <trukulo> ok, hope this afernoon
[03:24] <Mithrandir> trukulo: ok, no worries, if this isn't up in a couple of minutes, I'll use the box I'm running IRC off.
[03:24] <trukulo> ok
[03:24] <trukulo> but now, i have to go home to lunch :)
[03:31] <mako> your presence is enough :)
[03:31] <Treenaks> lamont_r: just on-join triggers ;)
[03:31] <lamont_r> mako: feh!
[03:31] <lamont_r> :-)
[03:32] <Mithrandir> elmo: can you sync stuff from experimental, or would you then prefer that we upload an ubuntu version?
[03:33] <elmo> Mithrandir: I can sync stuff from anywhere with a Sources
[03:34] <Mithrandir> elmo: ok, please sync gaim from experimental, then.
[03:35] <elmo> Mithrandir: err, wouldn't that need an exception fromthe UpstreamVersionFreeze?
[03:35] <elmo> oh, no, we already have 1.1.1
[03:36] <Mithrandir> elmo: yeah, I thought we had, so that should be fine.
[03:36] <elmo> done
[03:36] <Mithrandir> thanks a lot.
[03:37] <pitti> elmo: can you please sync imlib+png2 and imlib2 from sid?
[03:38] <elmo> pitti: done
[03:38] <pitti> thanks
[03:40] <lamont_r> no mdz yet, is there..
[03:45] <lamont_r> amu: kdebase sent
[03:46] <Mithrandir> doko?
[03:46] <lamont_r> amu: sorry for the delay - that one had been archived.
[03:47] <gsuveg> thom: echo request
[04:01] <amu> lamont_r: thx again ... as i thought there's a problem with it :) 
[04:01] <lamont_r> amu: I see.
[04:01] <lamont_r> things with problems really should fail, you know...
[04:03] <amu> lamont_r: hehe
[04:28] <pitti> Kamion: do you know how to automatically map a language code (pt_BR or de_DE) to a language name (like "Brazilian Portugese" or "German")?
[04:29] <seb128> hum
[04:29] <lamont_r> pitti: /usr/share/misc/languages
[04:29] <lamont_r> .gz
[04:29] <seb128> Address   Kbytes     RSS    Anon  Locked Mode   Mapping
[04:29] <lamont_r> (in miscfiles)
[04:29] <seb128> b5c9f000    7592       -       -       - r----  kochi-gothic-subst.ttf
[04:29] <seb128> what's that ?
[04:30] <seb128> why a .ttf is listed in the memory table and eat that memory ?
[04:30] <lamont_r> pitti: and /usr/share/misc/countries.gz for the _BR _DE, etc
[04:30] <lamont_r> seb128: probably mmaped
[04:30] <smurfix> seb128: because it's mmap'd ?
[04:31] <smurfix> lamont: you win ;-)
[04:31] <pitti> lamont_r: cool, thanks
[04:31] <lamont_r> pitti: miscfiles is full of really cool stuff..
[04:31] <seb128> hum
[04:31] <lamont_r> and really useless stuff.
[04:31] <seb128> I'll just remove it, I don't care about this stuff :p
[04:31] <lamont_r> smurfix: less keystrokes..
[04:31] <seb128> lamont_r: BTW have you read my request for a small description of your focus mode ? :)
[04:32] <seb128> and thanks lamont_r and smurfix 
[04:32] <fabbione> lamont_r: mind to kick back the 2.6.10-4 on ia64?
[04:32] <lamont_r> seb128: yeah - although I'm still not 100% sure I'm happy with it....
[04:32] <lamont_r> fabbione: ok
[04:32] <fabbione> lamont_r: i doubt that's a package problem
[04:32] <lamont_r> will do, that is.
[04:32] <fabbione> make[1] : Entering directory `/build/buildd/linux-source-2.6.10-2.6.10/debian/build/linux-source-2.6.10'
[04:32] <fabbione>   HOSTCC  scripts/basic/fixdep
[04:32] <fabbione> Inconsistency detected by ld.so: dl-version.c: 230: _dl_check_map_versions: Assertion `needed != ((void *)0)' failed!
[04:32] <fabbione> make[2] : *** [scripts/basic/fixdep]  Error 127
[04:32] <thom> gsuveg: um, ack
[04:33] <seb128> lamont_r: out of you nobody use it atm so feel free to send a new patch to change the behaviour if you want :)
[04:33] <thom> focus_follows_lamont?
[04:33] <lamont_r> seb128: it's 'strict pointer mode' that is, new windows never take focus, although they may be mapped on top.  (issue is, if the new window maps on top and lands on the mouse, it still doesn't get focus - not sure which way I'd rather that went, and can argue both sides of that... must ponder.)
[04:34] <lamont_r> thom: upgrade metacity, and then use gconf-editor to change focus to 'strict'....
[04:34] <seb128> the key to change is in the changelog
[04:35] <lamont_r> seb128: the argument for why I want it (passwords, conversations, etc) kinda leads directly to the current behavior of the mode.  so I may just leave it that way...
[04:36] <seb128> the new metacity focus prevention should avoid to lost focus while typing a password or so
[04:36] <seb128> it works pretty fine here
[04:36] <lamont_r> thom: it behaves exactly like 'mouse', except that newly mapped windows _NEVER_ take focus.  ever.
[04:36] <lamont_r> seb128: right - that's only one corner case of the thing...
[04:36] <lamont_r> the other is popping up new windows, and wanting to do several before going to the new ones.
[04:37] <seb128> the focus in metacity now is: don't give the focus unless something ask for it
[04:37] <lamont_r> it's really a 'don't make retrain the muscle memory' thing...
[04:37] <seb128> it: you ask when you click on "save" icon in an app
[04:37] <seb128> that's stupid to not give the focus to the file selection which ask for the filename
[04:37] <lamont_r> or there's a shell prompt in an xterm/gnome-terminal
[04:38] <lamont_r> seb128: like I said - muscle memory.
[04:38] <lamont_r> the other side of the argument to calling it 'strict' would be that the focus would always be on the window where the mouse is sitting. current behavior violates that argument when the new window lands on the mouse...
[04:43] <seb128> http://mail.gnome.org/archives/desktop-devel-list/2004-December/msg00306.html
[04:43] <lamont_r> seb128: does that give you enough for the schema description, or do you want me to actually craft the entry?
[04:43] <seb128> the details of the current metacity behaviour
[04:44] <seb128> lamont_r: that's enough informations, but the "get the focus if pop under the mouse cursor" seems to be a bug for me :)
[04:45] <lamont_r> nice. note that (a) I sometimes interact with windows using only my eyes, and (b) there is still a brief window between the prompt in a window and when I start typing that could result in keystrokes going to the wrong window.  admittedly, it's a short window, but...
[04:45] <lamont_r> and sadly, neither of those can really be solved with the information available to the system./
[04:45] <gsuveg> thom: now works the apps, but in live i cant test now
[04:45] <seb128> yep
[04:46] <seb128> but opening a fileselector for example is really fast
[04:46] <seb128> you should be patient enough to wait for the dialog :)
[04:46] <lamont_r> seb128: so you think that my mode should give focus to the new window that maps on top of the cursor?
[04:46] <seb128> no
[04:46] <lamont_r> good - because it doesn't right now.
[04:46] <seb128> no if you don't move the mouse at least
[04:47] <lamont_r> right now, mouse must enter the new window (which could mean 'leaving' it first...)
[04:47] <seb128> no
[04:48] <lamont_r> ??
[04:48] <seb128> ie: I open gedit, type something in it, do alt-F2 with the cursor in the middle of the screen
[04:48] <thom> gsuveg: ..
[04:48] <seb128> the dialog takes the focus from gedit
[04:50] <gsuveg> thom: ?
[04:52] <lamont_r> seb128: with the current patch, mode==strict will never give the dialog focus until the mouse moves.
[04:52] <seb128> lamont_r: I've just tried again here before saying so on IRC
[04:52] <seb128> or the mouse move alone :)
[04:53] <lamont_r> for me - I have to either move the mouse out of the dialog box and back in, or click to take focus.
[04:53] <seb128> I don't touch the mouse
[04:53] <thom> gsuveg: i have no idea whether you're asking something, telling me something, or what
[04:53] <seb128> just open gedit in the middle of the screen, place the mouse cursor in the place where the alt-F2 dialog pop up
[04:54] <seb128> enter some text
[04:54] <seb128> alt-F2
[04:54] <seb128> and now input doesn't go in gedit
[04:55] <lamont_r> seb128: ah - it's not that the new window gets focus, it's that the old window loses focus.
[04:55] <lamont_r> got it.
[04:55] <lamont_r> that'd be a bug
[04:55] <seb128> yep :)
[04:55] <lamont_r> I'll investigate that today and send you a new patch
[04:55] <seb128> thanks
[04:56] <lamont_r> you want it relative to the current archive, I assume.
[04:56] <lamont_r> (duh)
[04:56] <seb128> if possible. Be careful, there is already a 000_raise-on-click.patch changing the code a bit
[04:57] <lamont_r> dpatch?
[04:57] <seb128> no, cdbs with diff files
[04:57] <seb128> but your patch apply ok on the current version and doesn't conflict with 000_raise-on-click.patch
[04:58] <seb128> hum, maybe there was 1 rej in fact due to some upstream changes
[04:58] <Mithrandir> seb128: gaim with -dev is now synced.
[04:58] <seb128> cool
[04:59] <seb128> perhaps the new version will fix some of the bugs open too :p
[04:59] <Mithrandir> at least, elmo has synced it, but it's not in the archive yet, it seems?
[05:00] <elmo>       gaim |  1:1.1.1-2 |         hoary | source
[05:00] <elmo> it's not built is all
[05:00] <seb128> nop, not in the archive yet
[05:00] <lamont_r> ok.  with cdbs (never used it), how do I get to the state where patch foo is not applied yet, but everything before it is?
[05:00] <azeem> lamont_r: man patch :P
[05:00] <Mithrandir> seb: blah, failed due to libebook-dev
[05:01] <azeem> is there a better way? (I'm seriously interested)
[05:01] <lamont_r> azeem: heh
[05:01] <lamont_r> azeem: with dpatch, I just say 'dpatch-edit-patch <patchname>' and get to that state
[05:01] <azeem> yeah
[05:01] <lamont_r> well, actually, <patchname> is applied, etc.
[05:01] <azeem> lamont_r: note that cdbs is patch-agnostic (you can use it with dpatch and quilt), it's just the simple-patchsys it also provides which sucks
[05:02] <azeem> simple-patchsys is not really suited for editing patches around and stuff I think (but I haven't poked at the code)
[05:02] <azeem> ask Jeff once he's around to fix cdbs :P
[05:02] <Mithrandir> seb128: I'm handling it
[05:04] <seb128> ok
[05:06] <seb128> azeem,lamont_r: simple-patchsys just apply all the diff files from debian/patches
[05:07] <seb128> that's nice when you get patch or diff from the CVS, you just have to drop them in debian/patches/
[05:07] <azeem> it adds stamp-files though
[05:07] <seb128> yes
[05:07] <seb128> but that's not optimal when you want to edit a patch
[05:07] <azeem> so could you do 'debian/rules debian/stamp-patch-foo'?
[05:07] <azeem> where 'foo' is the patch prior to the one you want to edit?
[05:08] <azeem> hmm, should try that out one time
[05:15] <lamont_r> doko??!!?
[05:16] <lamont_r> Inconsistency detected by ld.so: dl-version.c: 230: _dl_check_map_versions: Assertion `needed != ((void *)0)' failed!
[05:17] <lamont_r> fabbione: it'll be a while on that give-back
[05:18] <fabbione> lamont_r: it did it again?
[05:19] <fabbione> or gcc screw up?
[05:19] <lamont_r> it's systemic
[05:19] <fabbione> ok
[05:20] <fabbione> roger
[05:20] <fabbione> perhaps it's only one chroot that is b0rk3d
[05:20] <lamont_r> nope.  all 3, and all 3 are current wrt/archive
[05:21] <fabbione> ah
[05:21] <fabbione> ok
[05:21] <lamont_r> but we just finally got the toolchain in... hence the doko-summoning
[05:21] <fabbione> ehehhe
[05:21] <fabbione> ok i am off.. more sandpapering
[05:27] <Nafallo> I can see a new powernowd just entered, did bug #5256 get fixed within that one?
[05:30] <azeem> Nafallo: check the changelog
[05:30] <Nafallo> azeem: rsyncing and on my way to evening-course :-).
[05:31] <Nafallo> but it seemed only Sempron was added, a shame when there's a patch for Mobile AMD64 on bugzilla :-P.
[05:36] <thom> i thought we'd fixed 5256
[05:36] <thom> ho-hum
[05:36] <thom> uploads are cheap *shrug*
[05:37] <Nafallo> thom: hehe, uploading again? :-)
[05:38] <Nafallo> later all
[05:39] <lamont_r> Kamion: amd64 images available to you.
[05:39] <lamont_r> 541MB of cloop
[05:39] <lamont_r> well, 542.
[05:40] <lamont_r> mdz: hack fix worked, btw
[05:40] <trukulo> hi
[05:40] <trukulo> Mithrandir: i'm finishing torrents for yo
[05:40] <trukulo> you
[05:41] <Mithrandir> trukulo: just biking to my gf's now, but I'll be back online in 30 minutes or so.
[05:42] <trukulo> ok
[05:42] <Kamion> lamont_r: hooray
[05:42] <trukulo> i'll finish them
[05:42] <trukulo> i'll put it on http://mercurio.homeip.net/debian/
[05:51] <mdz> lamont_r: great
[05:51] <lamont_r> mdz: in other news, the new toolchain now in ia64 seems to be b0rked.
[05:52] <mdz> lamont_r: T Simonnet seems to have resurfaced
[05:52] <thom> mdz: i assume the reason you pinged was umask?
[05:52] <lamont_r> Kamion: does that mean you'll want me to rebuild rootfs's for all the architectures again later today?
[05:52] <mdz> lamont_r: can you communicate to him what needs to be fixed and ask him to coordinate?
[05:52] <mdz> thom: yeah, elmo fixed it for me
[05:52] <lamont_r> mdz: yeah - was going to ping doko about why it's what it is, since he can probably answer off the top of his head/trivial fix/etc.
[05:53] <lamont_r> mdz: already replied to T with how to debug the install cd
[05:53] <mdz> lamont_r: sure...we need for someone to start acting as go-to person for ia64, though
[05:53] <mdz> and T Simonnet said he would be that
[05:53] <lamont_r> well, how to produce a modified one, actually
[05:53] <lamont_r> right - specifically, not me. :-)
[05:53] <lamont_r> I'll send him mail in a short while.
[05:54] <Kamion> lamont_r: it's only the udebs that matter here; it was the dm-snapshot thing
[05:54] <lamont_r> Kamion: ah, ok
[05:54] <Kamion> since md-modules isn't in the initrd, it doesn't even need a daily-installer build
[05:54] <thom> mdz: yeah, i guessed
[05:54] <thom> sorry.
[05:54] <lamont_r> Kamion: i386/ppc are the daily build images from 06:15 your time, amd64 was a manual run just before I told you about it
[05:54] <Kamion> ok, thanks
[05:55] <mdz> thom: could you file a bug against baz if there isn't one already, to have it prevent us from shooting ourselves in the foot this way?
[05:55] <lamont_r> anything else before I run off for about an hour?
[05:55] <lamont_r> mdz: so mono is in main now?
[05:56] <Kamion> daniels: kickstart documents a (kickstart-specific) 'xconfig --noprobe' command, described as "do not probe the monitor". do you happen to know if I can translate that into some number of debconf answers that will have the same effect?
[05:58] <mdz> lamont_r: the source package iis, yes
[05:58] <mdz> I have to run to an appointment, back in a few hours
[05:59] <thom> we still need to fix mcs' FTBFS :/
[05:59] <lamont_r> mdz: ok.  that adjusts the priority for fixing it, if nothing else... ;_(
[05:59] <lamont_r> thom: see the bug
[05:59] <trukulo> Mithrandir: you have all the torrent files located on my website (http://mercurio.homeip.net/debian/)
[05:59] <lamont_r> 5052? maybe
[06:01] <mdz> Kamion: are there updated CD images for me to download?
[06:01] <mdz> if so, I'll start them before I leave
[06:01] <mdz> hmm, don't seem to be
[06:02] <mdz> Kamion: could you do a new set of live CDs based on lamont's latest images and Fabio's new kernel that he planned to upload today (haven't checked if it's up yet)
[06:02] <mdz> really going now
[06:03] <Kamion> mdz: I'm waiting for the new kernel images to arrive
[06:03] <Kamion> the source is up but powerpc isn't there yet
[06:04] <Kamion> daniels: xserver-xorg/autodetect_monitor appears to be what I want, but as far as I can tell the code that calls xresprobe doesn't honour it. Could you fix that?
[06:07] <elmo> powerpc just went in
[06:07] <elmo> next sync is 30 mins; can force earlier, if needed
[06:10] <Kamion> elmo: thanks, that's great; universe->main for rtc-modules would be good too, but not needed for the live CD
[06:12] <elmo> oh, actually, no, it should already be on archive.u.c
[06:12] <Kamion> yeah, it is
[06:15] <Mithrandir> trukulo: ok, if you now, with a client that already has the downloaded files, process the new .torrents, it'd be good
[06:16] <Kamion> mdz: it's up; amd64, i386, powerpc all built
[06:16] <trukulo> no one has downloaded the files yet
[06:16] <trukulo> i've made them with the original videos
[06:16] <trukulo> same as old torrents, in that machine
[06:16] <trukulo> (not mine)
[06:17] <trukulo> if you have instructions for it, send to my email
[06:17] <trukulo> now i have to go, to buy more ram to my laptop (am, am)
[06:17] <elmo> hmm, nice 2.6.10 is up to 3:25 to build on i386
[06:18] <Mithrandir> trukulo: yes, but you need to seed the new torrents.
[06:18] <trukulo> i know
[06:18] <trukulo> but now, i can't
[06:18] <Mithrandir> ok. :/
[06:18] <Mithrandir> please do when you can, then?
[06:18] <trukulo> perhaps tomorrow, don't know, now i've to go
[06:18] <trukulo> of course
[06:18] <trukulo> but i need full videos download isn't it?
[06:19] <trukulo> so perhaps tomorrow on my work
[06:19] <trukulo> today, with spanish connections, is impossible
[06:19] <Mithrandir> you need the files you used when running btmakemeta (or what the command is called)
[06:19] <Mithrandir> are they anywhere else on the web?
[06:19] <trukulo> i made them in the original machine where actual torrents are hosted
[06:19] <Mithrandir> ok
[06:20] <trukulo> well, see you later
[06:20] <Mithrandir> see you around
[06:27] <thom> hrm, can i do a query in bugzilla and negate the product - "I want to find all  bugs assigned to me that aren't on mozilla-firefox"
[06:28] <pitti> thom: got 'nuff of those ffox bugs? :-)
[06:28] <thom> a few too many
[06:29] <thom> :-)
[06:31] <pitti> thom: advanced search, summary "does not match regexp" comes close...
[06:31] <pitti> thom: or you select all components and manually deselect firefox et al
[06:33] <pitti> ^but this is going to be a biiiig HTTP request, I think :-)
[06:33] <thom> i was trying to avoid doing the latter ;-)
[06:33] <thom> the boolean stuff doesn't seem to work
[06:36] <elmo> if I want to test IMAP am I safe to use evolution?  it's not going to start mucking around with my local ~/mail/ is it?
[06:37] <thom> elmo: it shouldn't do, but i'd've thought mutt -f imaps://foo/bar was a safer bet
[06:38] <elmo> ok, I'll try that
[06:52] <HostingGeek> just some game ideas for ubuntu
[06:53] <HostingGeek> PPRacer
[06:53] <HostingGeek> it cont. from where tuxracer left off 
[06:53] <HostingGeek> And SupertuxKart
[06:53] <HostingGeek> as its way better than tuxkart
[06:54] <HostingGeek> PPRacer: http://projects.planetpenguin.de/racer/index.php
[06:54] <HostingGeek> SuperTuxKart: http://supertuxkart.berlios.de/index.html
[06:56] <cartman> PPRacer looks nice
[06:59] <HostingGeek> cartman: yes
[06:59] <HostingGeek> cartman: will it make hoary
[07:00] <cartman> <-- not an official dev.
[07:04] <thom> HostingGeek: no, we've already frozen our upstream selections, and it's unlikely we'll want to support games in the main distro
[07:04] <HostingGeek> no it doesn't have to come on the default install 
[07:05] <HostingGeek> but as long as its in the main rep
[07:05] <HostingGeek> as non of them are in universe to begin with
[07:05] <Mithrandir> mdz: do I have an implicit approval for new upstream version of mozilla-thunderbird?
[07:05] <elmo> Mithrandir: if you have to ask, then clearly not ;-P
[07:06] <Mithrandir> elmo: bah. ;P
[07:08] <HostingGeek> elmo: thunderbird 1
[07:08] <HostingGeek> OMG this is a brake through
[07:11] <HostingGeek> please click the ads on the PPRacer site
[07:11] <azeem> HostingGeek: are you taht ^_^ dude?
[07:11] <azeem> that, even
[07:11] <HostingGeek> i would like to see the team making enough money that he doesn't stop the project
[07:11] <HostingGeek> and if anything puts more time into it
[07:11] <HostingGeek> wait
[07:12] <HostingGeek> not all at the same time
[07:12] <HostingGeek> google will not pay them
[07:12] <HostingGeek> i clicked now
[07:12] <HostingGeek> we will do 1 per 30min
[07:12] <HostingGeek> azeem: LOL why?
[07:12] <azeem> just wondering. Are you?
[07:14] <HostingGeek> maybe yes or yes
[07:19] <cartman> hmm buildd is busy?
[07:19] <cartman> swig update still didn't make it to a.u.o
[07:22] <elmo> cartman: what version do you mean?
[07:22] <cartman> elmo swig1.3 1.3.22-5ubuntu2
[07:24] <elmo> it's in dep-wait on a package in universe
[07:24] <cartman> ah ok
[07:25] <elmo> doko: ?
[07:45] <pitti> carlos: here?
[07:45] <carlos> pitti: hi
[07:45] <pitti> carlos: is it possible to get the current (date-based) timestamp from Rosetta?
[07:46] <pitti> carlos: i. e. if I create a language pack with version 20050110, can I get this number from Rosetta?
[07:46] <pitti> carlos: this avoids time zone and wrong clock troubles when building the package
[07:46] <pitti> carlos: like http://rosetta.ubuntu.com/timestamp
[07:47] <pitti> carlos: ^ this would return an ASCII text just containing the time stamp
[07:47] <pitti> carlos: alternatively (or even better):
[07:47] <pitti> carlos: can the timestamp be delivered as a txt file within the ZIP file?
[07:48] <carlos> pitti: hmmm
[07:48] <rjek> Hello.
[07:48] <rjek> I think I have a bug to report with Hoary.
[07:49] <pitti> Hello rjek 
[07:49] <rjek> Good evening pitti.
[07:49] <carlos> pitti: so we use; http://launchpad.ubuntu.com/rosetta/language-pack
[07:49] <pitti> rjek: the bug is not yet filed in bugzilla.ubuntu.com?
[07:49] <carlos> and you get a file like: timestamp.zip?
[07:49] <carlos> pitti: will that work for you?
[07:49] <rjek> pitti: Who knows?  I routinely avoid it because of its awfulness.  Anyway, I thought I'd discuss it here first incase somebody could justify the behavior.
[07:49] <pitti> carlos: I meant something else
[07:50] <rjek> Ubuntu/Gnome/Whatever locks the CD-ROM drive's tray when an audio CD is inserted.
[07:50] <pitti> carlos: if I request http://rosetta/updates/20041231
[07:50] <pitti> carlos: I get a ZIP with all translations changed since 20041231
[07:50] <carlos> pitti: no
[07:50] <carlos> hmmm
[07:50] <carlos> yes
[07:50] <carlos> :-
[07:50] <rjek> Eject from the icon on the desktop for the audio disc doesn't work (it silently fails), and neither does "eject /cdrom" unless run with root privileges.
[07:50] <carlos> :-P
[07:50] <carlos> sorry
[07:50] <pitti> carlos: and within this ZIP is the translation data and also a file "timestamp" which contaisn 20051001
[07:50] <pitti> carlos: or, 20050110 even :-)
[07:51] <pitti> carlos: so that I can update my recorded timestamp and use that the next time I request an update
[07:51] <rjek> thom
[07:51] <rjek>     !
[07:51] <carlos> pitti: ok, I see your point
[07:51] <thom> hullo rjek
[07:52] <carlos> yes, it's doable
[07:52] <pitti> carlos: Of course Ican also take the time of the build host, but this might lead to errors
[07:52] <pitti> carlos: with my proposal we have a central global reference
[07:52] <carlos> pitti: I think I will use always 23:59 UTC from the day before the request
[07:53] <pitti> rjek: this works fine for me here
[07:53] <rjek> What aspect of the issue?
[07:53] <pitti> rjek: I insert an audio CD, it automatically starts playing, then I type "eject" and it comes out again
[07:53] <carlos> that way you will not get some translations from that day but will work always the same way and you don't need the time timestamp just the date
[07:54] <rjek> pitti: I close the CD player application when it pops up.
[07:54] <rjek> Pressing the hardware eject button then does nothing.
[07:54] <rjek> Only way I can get the tray to open again is "sudo eject /cdrom"
[07:54] <rjek> It's clearly locking the tray, I'm just interested in *why* it's locking the tray.
[07:55] <pitti> carlos: it basically boils down to date +%Y%m%d > timestamp
[07:55] <rjek> I can see it's advantagous to lock the tray when you've mounted a file system on it.
[07:55] <pitti> rjek: audio CDs are not mounted
[07:55] <rjek> I know this.
[07:55] <rjek> Which is why I'm complaining about it locking the tray. :)
[07:56] <carlos> pitti: right
[07:56] <pitti> rjek: after I stop the CD player, the tray gets unlocked again for me
[07:57] <rjek> "stop" ?
[07:57] <rjek> Do you mean pressing the stop button on the cd player application, or quiting the CD player?
[07:57] <rjek> Why is it getting locked in any case anyway?
[07:57] <pitti> rjek: can you please write a detailled explanation in a bug report and include /proc/sys/dev/cdrom/info?
[07:58] <pitti> rjek: that's a good question; proably the CD player should be adapted not to do this
[07:58] <rjek> pitti: If that involves touching Bugzilla, then no :)  Ubuntu's Bugzilla appears to hate me.
[07:59] <pitti> rjek: hmm, then please write it to ubuntu-devel@lists.ubuntu.com
[07:59] <rjek> It doesn't actually appear to want to let me sign up for an account with it, for example.
[07:59] <pitti> rjek: why bz hates you? it works fine for anybody else
[07:59] <elmo> rjek: if you used your pepperfish mail, that's because of your fascist policies; it should work now, we have stuff like reverse DNS
[07:59] <rjek> pitti: Perhaps for the same reason that this weekend I found 5 bugs in my new DVD player's firmware that are baffling the author of its firmware? :)
[08:00] <elmo> if it's not worked for you recently, I'd like to try and find out why...
[08:00] <rjek> elmo: I tried with and without.
[08:00] <rjek> AFAIK, ppf's mail is quite happy to accept mail from places without rDNS.
[08:00] <rjek> We don't run SAUCE. :)
[08:01] <elmo> rjek: kinni was whining at me about not having reverse, he said he had to special case our mail server, but maybe I'm misremembering
[08:01] <rjek> (Our home ADSL for some time didn't have rDNS.)
[08:01] <rjek> elmo: Perhaps.
[08:01] <rjek> I routinely deal with ppf customers who don't have rDNS, though.
[08:01] <rjek> Anyway, I've got to go.  I'll try sending a mail to ubuntu-dev, and I'll try to go near Bugzilla again.
[08:01] <rjek> ... later this evening.
[08:08] <mjt> i'm seeing the same behaviour with my cdrom drive and kernel 2.6.10 - it locks the door (mplayer (it's dvd really), xmms, ..)
[08:08] <mjt> 2.6.9 was ok with that - no door locking
[08:15] <pitti> carlos: so the timestamp file in the zip is doable?
[08:15] <carlos> pitti: yes
[08:15] <pitti> carlos: nice
[08:15] <carlos> pitti: could you open a bug at https://launchpad.ubuntu.com/malone to track all this things?
[08:16] <pitti> carlos: this URL loads forever...
[08:16] <sivang> carlos: what's with the rosetta mailing list? so quite...:) did you get my emails regarding the imported files versions?
[08:17] <carlos> sivang: too much pending mails. I was fixing important bugs today, will try to answer all mails tomorrow (sorry)
[08:17] <pitti> carlos: timeout
[08:17] <carlos> pitti: ok
[08:19] <sivang> carlos: ok, good to know :) thanks!
[08:20] <sivang> carlos: I also got someone to tell you about the plurar froms in arabic :) , he told me it's bit complex, although the rules are quite clear - I hope rosetta could support it.
[08:20] <carlos> sivang: if gettext support it, Rosetta will do it also
[08:20] <sivang> carlos: ok, cool
[08:25] <lamont_r> moof
[08:26] <Treenaks> lamont_r: you.. you.. APPLE person!
[08:26] <lamont_r> Treenaks: heh.  finally broke down and bought a G3 in november
[08:26] <lamont_r> it's installed, and looking for power and a home in the house somewhere.
[08:27] <Treenaks> *fires up vim*
[08:27] <lamont_r> mdz: is 2.6.8.1 supposed to drop from hoary/main?
[08:27] <lamont_r> Treenaks: heh
[08:28] <lamont_r> no-auto-check-trustdb
[08:29] <Treenaks> thanks
[08:30] <Treenaks> seems to work :)
[08:37] <Kamion> lamont_r: I think we agreed 2.6.8.1, yes
[08:40] <lamont_r> Kamion: fwiw, amd64 was built using cloop_...-1ubuntu1buildd1_amd64.deb
[08:41] <lamont_r> i386 should pick that up tonight, and ppc/ia64 if/when I get around to compiling it for them.
[08:42] <lamont_r> (hence the grumble about 2.6.8.1
[08:42] <lamont_r> (grabbing i386 live, merge stuff, and missing mirror-files)
[08:43] <lamont_r> dunno what everyone else here is doing, but I'm getting about 100KB/s agregate
[08:47] <lamont_r> here == coffeeshop, that is.
[08:49] <lamont_r> seb128: you probably care about evoultion-webcal_2.1.3-0ubuntu1
[08:50] <seb128> lamont_r: yes, ftbfs ?
[08:50] <lamont_r> yeag
[08:50] <seb128> ok, thanks
[08:51] <lamont_r> doko?  awake?
[08:51] <lamont_r> mdz/jdub about?
[08:51] <elmo> lamont: what's wrong?
[08:51] <elmo> I moved pike7.6 into main
[08:51] <lamont_r> ah, ok
[08:52] <lamont_r> that was my grumblage-source
[08:53] <thom> seb128: hey, nautilus sucks
[08:54] <seb128> thom: ... 
[08:54] <thom> seb128: this is what's happening: i have a webdav share. i cna mount it in cadaver, i can view it in firefox, gnomevfs-ls lists the dir
[08:55] <thom> nautilus says: "Couldn't find "http://10.9.8.12/mp3/"."
[08:55] <thom> gnomevfs-info http://10.9.8.12/mp3/|grep MIME
[08:55] <thom> MIME type         : x-directory/webdav
[08:56] <seb128> thom: how do you try to browser it ?
[08:56] <thom> Ctrl+L
[08:57] <seb128> thom: with the "connecteur server" stuff ?
[08:57] <seb128> na
[08:57] <thom> or connect to server
[08:57] <seb128> or user webdav://...
[08:57] <thom> both do the same
[08:57] <seb128> s/user/use/
[08:57] <seb128> hum
[08:57] <Kamion> aargh, kickstart files can %include files generated by preinstallation scripts in the kickstart file, which are run in the initrd
[08:57] <Kamion> that's painful
[08:57] <seb128> thom; is there any way to have an account to play with it ?
[08:58] <thom> seb128: wait one
[09:12] <Mithrandir> lamont_r: can you track down where my gaim upload went?
[09:12] <lamont_r> Mithrandir: ok
[09:13] <Mithrandir> lamont_r: I uploaded it some hours ago and no trace of the build logs
[09:14] <lamont_r> Mithrandir: anything to do with libebook-dev?
[09:15] <Mithrandir> lamont_r: that was what I fixed in the upload, yes
[09:15] <lamont_r> anytime you fix a missing build-dep by removing it, I have to kick the buildd's...
[09:15] <lamont_r> so once you see the source in the archive, you can poke me...
[09:16] <fabbione> hmmm
[09:16] <Mithrandir> ah, ok.  I didn't remove it, I just changed it, though.
[09:16] <Mithrandir> stuff get auto-depwaited?
[09:16] <fabbione> lamont_r: it looks like that only ia64 is screwed
[09:16] <lamont_r> kicked
[09:17] <lamont_r> fabbione: yeah - all 3 ia64 machines, only.
[09:17] <lamont_r> Mithrandir: stuff gets auto-depwaited, and clearing the depwait is manual
[09:17] <Mithrandir> lamont_r: ok, noted.  Thanks.
[09:18] <lamont_r> should save a little frustration the next time around.
[09:19] <fabbione> lamont_r: ok :-)
[09:20] <lamont_r> fabbione: that was what I meant earlier by 'all' - sorry about the miscommunication
[09:20] <fabbione> lamont_r: yeah gotcha.. don't worry...
[09:20] <fabbione> atleast it's not sparc ;)
[09:20] <fabbione> like we would say between real friends
[09:20] <fabbione> when shit happens
[09:20] <fabbione> better to you than me!
[09:20] <fabbione> :P
[09:21] <lamont_r> "there you sit all spic-n-span.  where were you when it hit the fan?"
[09:21] <fabbione> ehehe
[09:23] <lamont_r> fabbione: meanwhile hppa (which has more personal mindshare than ia64...) is at 734/5/17/20 of 777 inst/fail/d-w/build (==failed)
[09:23] <lamont_r> kernel threads seem to be a bit unhappy on hppa.
[09:23] <fabbione> nice
[09:23] <thom> lamont_r: are you looking at mcs? if not, i might play around tonight and see what i can find
[09:23] <fabbione> lamont_r: try to build the kernel.. and give it a spin
[09:23] <fabbione> it's up to this morning cvs
[09:23] <Mithrandir> lamont_r: that's not bad at all.
[09:23] <lamont_r> thom: not currently looking at it - the bug talks about known b0rkage that hasn't been uploaded yet - that'd be a starting point
[09:23] <fabbione> anyway
[09:23] <fabbione> i am off
[09:24] <thom> lamont_r: that's way out of date
[09:24] <lamont_r> Mithrandir: once one understands that the building==failed list includes gcc-3.[34] , db4.3, kenrel, synaptic, etc, it looks a bit uglier...
[09:25] <lamont_r> thom: glad I didn't head down that rat hole then.
[09:25] <lamont_r> thom: if you would please look at it, I'd be happier
[09:25] <thom> lamont_r: sure
[09:25] <lamont_r> feel free to hijack the bug too
[09:26] <thom> righto
[09:30] <thom> lamont_r: also, it doesn't appear to have built anywhere in debian, so i dunno wtf that's about
[09:30] <doko> lamont_r: the ia64 archive doesn't seem to be get updated
[09:30] <lamont_r> doko: with what?
[09:30] <doko> gcc-3.4
[09:31] <doko> the second time it did build sucessfully
[09:31] <thom> yeah, debian has the exact same error, so i think it's a case of the missing build deps
[09:33] <lamont_r> doko: libgcc1_3.4.3-7ubuntu1 is installed
[09:34] <lamont_r> doko: so I think the toolchain is completely current.  I'd love to be shown otherwise, because that makes the fix trivial.
[09:35] <doko> oops, wrong chroot. you are right. preparing the final libunwind upload.
[09:36] <lamont_r> doko: thanks.  pls tell me when to give everything back....
[09:36] <lamont_r> or even when the upload happens and I'll babysit it.
[09:47] <Mithrandir> doko: why did you upload a mailman to hoary with tightened build-deps?
[09:48] <elmo> doko: dude, can you fix python-nevow? it's been promoted from universe and needs transitioned
[09:48] <elmo> can file a bug if you want
[09:54] <doko> Mithrandir: don't remember. maybe the python-defaults package was delayed? don't know anymore.
[09:54] <doko> elmo: ok, please file a report. there are more packages...
[09:54] <Mithrandir> doko: ok; it doesn't need any, that's just why
[09:54] <elmo> doko: not in main, I hope?
[09:55] <doko> elmo: syncs from Debian only. and I have to look at abiword.
[09:55] <doko> elmo: please could you sync drdsl and graphviz from Debian?
[09:56] <doko> lamont_r: can you compile _anything_ on ia64 with the new libgcc1?
[09:56] <lamont_r> nope
[09:56] <elmo> doko: both would need an exception from the UpstreamVersionFreeze - please mail mdz/jdub, cc me, to get their approval
[09:57] <lamont_r> so do I just need to rollback libgcc1 on something to the prior rev to get libunwind to build?
[09:57] <doko> elmo: same with pike7.6. the last Debian upload was in November. just saw it when fixing swig
[09:59] <doko> lamont_r: I've put the libgcc1 from my testbuild on chinstrap. could you verify, if this works for you?
[09:59] <lamont_r> doko: in place of what's currently in the chroot, in order to build libunwind?
[09:59] <lamont_r> or just generally?
[10:00] <doko> just see, if you can compile things with it.
[10:00] <doko> (and the compiled binaries run ...)
[10:01] <elmo> doko: I promoted pike7.6 under the 'obvious' rule.. FWIW
[10:02] <robtaylor_> carlos: ping-a-ling?
 Generating locales...
   fr.ISO-8859-1...cannot open locale definition file `fr': No such file or directory
[10:03] <seb128> somebody has an idea on what could break the locales installation in this way on warty ?
[10:03] <mjt> isn't it fr_FR.... ?
[10:04] <seb128> yeah, it should
[10:04] <seb128> I'm wondering how he can get fr here
[10:04] <elmo> seb128: I suspect the user hand-edited /etc/locales.conf and got it wrong?
[10:04] <elmo> err locales.gen
[10:04] <doko> elmo: thanks
[10:04] <seb128> locales.gen was wrong yes
[10:04] <seb128> but removing it doesn't help according to him
[10:05] <seb128> is the value stored in debconf or something ?
[10:05] <mjt> removing what?  A file, or the line?
[10:06] <mjt> all debconf answers (or almost, anyway) are stored in debconf db
[10:06] <seb128> /etc/locales.gen
[10:06] <seb128> the fr line in it
[10:06] <seb128> locales is still broken (apt-get -f install)
[10:06] <mjt> still the same message about missing `fr' ?
[10:07] <seb128> yes
[10:07] <lamont_r> doko: Inconsistency detected by ld.so: dl-version.c: 230: _dl_check_map_versions: Assertion `needed != ((void *)0)' failed!
[10:08] <elmo> seb128: try dpkg-reconfigure locales first?
[10:08] <elmo> it shouldn't fix it, but..
[10:09] <seb128> already tried
 /usr/sbin/dpkg-reconfigure: locales is broken or not fully installed
[10:09] <seb128> the state is "iF"
[10:10] <mjt> the script is at /var/lib/dpkg/info/locales.postinst
[10:10] <seb128> I know that :)
[10:10] <mjt> dunno what's wrong, but as the last resort it's possible to add "|| :" at the end of locale-gen line
[10:11] <mjt> the script -- seems to be -- tries to restore values in locale.gen
[10:11] <seb128> I think so :/
[10:12] <mjt> (in which case i think it is wrong, btw)
[10:12] <mjt> hmm crap.
[10:12] <mjt>                 sed -e "s,#$locale *\$,$locale," $LG > $LG.tmp || true
[10:12] <mjt>                 mv -f $LG.tmp $LG
[10:13] <mjt> that '|| true' part is WRONG, imho.
[10:14] <lamont_r> mjt: actually, I bet it wants to be: sed ... && mv .. || true
[10:14] <lamont_r> or just tell perl to do it in place.
[10:14] <mjt> (or sed for that matter ;)
[10:14] <lamont_r> istr sed will exit 1 if it didn't do anything...
[10:15] <lamont_r> sed does things in place now?
[10:15] <mjt> yeah
[10:15] <Mithrandir> lamont_r: with -i, it does.
[10:15] <lamont_r> kewl
[10:15] <Mithrandir> it's a _really nice_ feature.
[10:15] <elmo> yeah but this is glibc
[10:15] <elmo> you don't want  to update _it's_ postinst in a hurry :P
[10:15] <lamont_r> elmo: I meant _my_ postinsts... :-)
[10:16] <mjt> sed exits with 0 even if it didn't do anything.  at least here
[10:16] <lamont_r> and yeah, it's a function of when was -i introduced, and was that effectively the dawn of time (and then you can change it..)
[10:16] <lamont_r> mjt: my bad
[10:17] <mjt> i think that "|| true" thing comes from days when grep was used at this place
[10:17] <mjt> still, what's a "common consensus" about debconf variables and actual configuration files?  Which takes precedence?
[10:17] <Mithrandir> mjt: config files.
[10:18] <Mithrandir> mjt: config files seed debconf which is then used for building the config files
[10:18] <Mithrandir> at least, that's the way I do it.
[10:18] <mjt> well ok... that's how i do it too ;)
[10:19] <lamont_r> ditto
[10:19] <Mithrandir> anything else is very much broken
[10:20] <lamont_r> with the added caveat that changing the configfile outside of things, and then running debconf and changing something else, needs to not overwrite the hand edits...
[10:20] <lamont_r> that bit gets a little more ugly
[10:21] <mjt> i asked to confirm.. a few months ago i filed a grave bugreport about mdadm as after i changed config in /etc and upgraded mdadm, my machine becomes unbootable
[10:21] <Mithrandir> you need to parse the config file somehow.
[10:21] <lamont_r> Mithrandir: actually, I just added a changed flag to debconf :-)
[10:22] <lamont_r> then again, sometimes early adoption can be painful...
[10:22] <amu> lamont_r: ppc is still not working  
[10:22] <lamont_r> amu: grumble.  not-working how?
[10:22] <amu> caspar runs amok ...  
[10:23] <amu> ... on a pb4 
[10:24] <doko> lamont_r: ld.so doesn't seem happy with libunwind changing between /lib and /usr/lib. I put the new libunwind on chinstrap. at least this makes things working again
[10:25] <amu> lamont_r: i'll continue now with i386 ... 
[10:26] <lamont_r> doko: will there be a new upload of libunwind that makes thigns happy?
[10:26] <doko> yes, if that works for you. this is my test build of the new upload.
[10:27] <lamont_r> doko: ah, ok. so test your .debs by building the source, eh?
[10:29] <lamont_r> doko: much happier.  if you upload, I'll help the binaries through, and we can make ia64 happy again
[10:30] <doko> lamont_r: ehh, they do build ...
[10:30] <doko> ok
[10:31] <doko> elmo: any chance to setup a chroot on davis for powerpc64 work?
[10:34] <doko> lamont_r: signed binaries on chinstrap:libunwind/
[10:34] <lamont_r> doko: yeah, I know
[10:34] <lamont_r> but policy says that the binaries have to be built in our buildd-chroots
[10:35] <lamont_r> but if you upload the source, then I can help the binaries along, since I have to diddle the chroot a bit to get it to work...
[10:37] <amu> lamont_r: i386 has the same problem 
[10:38] <doko> lamont_r: the source is included
[10:38] <lamont_r> amu: great.  consistancy is wonderful.
[10:38] <amu> lamont_r: i'll tryy to find it 
[10:38] <lamont_r> doko:  do you want me to do the dput of the source, or are you going to?
[10:39] <doko> lamont_r: will do.
[10:39] <lamont_r> please tell me when you get the accepted message
[10:40] <amu> lamont_r: got it, problem in cloop
[10:40] <doko> lamont_r: done
[10:41] <amu> cloop: disagrees about version of symbol struct_module
[10:44] <lamont_r> amu: that sounds pretty fatal
[10:48] <amu> lamont_r: should i try also amd64? 
[10:48] <amu> guess it's the same 
[10:48] <lamont_r> amu: I expect that you're right
[10:49] <lamont_r> it better not require that the system where we compress the filesystem match the kernel on the CD...
[10:49] <lamont_r> because that would be wrong in oh so many ways.
[10:49] <du2br> how should I contribute potfiles revision to ubuntu patched packages (eg. gnome-panel)? patch to bugzilla?
[10:50] <lamont_r> 95% of an iso that's borked.  sheesh
[10:51] <lamont_r> amu: I guess I can kill my download, eh?
[10:51] <amu> nope, try to rsync next time ;) 
[10:51] <lamont_r> hrm.... I wonder if we could run something over the fsimage that changed the timestamps on everything to something specific...  and if that would be a good idea or not...
[10:51] <lamont_r> I expect it would help with rsync-ability
[10:52] <lamont_r> how bad are the incremental rsync's?
[10:52] <mdz> lamont: here
[10:52] <mdz> lamont: yes, 2.6.8.1 is supposed to disappear entirely
[10:52] <amu> got the i386 in about 15sec. 
[10:52] <lamont_r> mdz: did I give you any context?
[10:52] <Mithrandir> mdz: mozilla-thunderbird 1.0 is already ok-ed, right?
[10:52] <lamont_r> amu: way cool
[10:52] <mdz> Mithrandir: the exception cases are listed in the wiki; does it meet one of them?
[10:52] <mdz> Kamion: thanks
[10:53] <doko> lamont_r: libunwind accepted
[10:53] <lamont_r> doko: thanks
[10:55] <doko> mdz: regarding the size of the l-r-m packages, should we build separate packages? these modules seem to be of interest for a relative local audience.
[10:56] <Mithrandir> mdz: it was discussed on the Hoary status meeting about a week ago, but no, it doesn't really fit apart from that. :/
[10:56] <mdz> doko: cf. the discussion on ubuntu-devel about why we have only one l-r-m
[10:56] <mdz> doko: it's better to only need to rebuild one package when updating the kernel
[10:57] <mdz> amu: which image has this cloop problem?
[10:57] <doko> mdz: sure, but that's not an argument to put them in a separate _binary_ package.
[10:57] <Mithrandir> mdz: you did actually say it needed a new upstream version. :P
[10:58] <amu> mdz: 20040110
[11:00] <amu> mdz: tested intel&ppc, i've also a amd64 here, guess it's the same, if you want me to test it also letme know, therefore i've reboot mail mail/webserver
[11:06] <lamont_r> ETIME
[11:08] <Kamion> lamont_r: sed -i was introduced relatively recently, in sed 3.95
[11:08] <Kamion> lamont_r: woody doesn't have it ...
[11:09] <lamont_r> back on somewhere around 16:45 -0700
[11:09] <Kamion> and it took a while before it worked properly, e.g. didn't chmod /dev/null when run as root with </dev/null :P
[11:09] <lamont_r> lol
[11:09] <lamont_r> anyway,
[11:12] <mdz> amu: all there are broken?
[11:12] <mdz> amu: all 3?
[11:12] <mdz> amu: did you talk to fabbione about it?
[11:13] <amu> mdz: yeah it looks like, i'm burning now amd64   
[11:13] <mdz> amu: what is the exact error?
[11:13] <amu> mdz: not now, looks like fabbione is away
[11:14] <amu> cloop: disagrees about version of symbol struct_module
[11:14] <smurfix> amu: kernel updated and not rebooted?
[11:14] <amu> smurfix: .. the dc live edition
[11:18] <Mithrandir> mvo_: mdz and I got an excellent, and/or crackful idea last night.
[11:19] <Mithrandir> mvo_: do you have a little time?
[11:19] <mdz> oh, yes, I meant to send a mail to mvo about that but haven' tyet
[11:19] <mvo_> Mithrandir: I'm pretty tired, but tell me
[11:19] <mvo_> I'm always curious for crazy stuff :)
[11:19] <Mithrandir> mvo_: have you looked at the UTFEightMigrationTool thingy?
[11:19] <Mithrandir> that's something which should really be run by all users after the system is hoarified.
[11:20] <mvo_> yes 
[11:20] <Mithrandir> and U8MT might not be the only tool which would want that, so if packages could ask, through upgrade-notifier or something to have a command run when the user asks for it, that'd be nice.
[11:21] <mvo_> Mithrandir: so what we need is some kind of "post-dist-upgrade-hook"?
[11:21] <Mithrandir> mvo_: post-dist-upgrade-per-user-hook, yes.
[11:22] <Mithrandir> and it should not just be some wizard which pops up when the user first logs in, it should probably be a notification icon of some sort.
[11:23] <mvo_> Mithrandir: sounds like a very interessting idea. let me sleep over it to think how it could be representated in the GUI
[11:23] <Mithrandir> mvo_: ok, sleep tight.
[11:23] <Mithrandir> mvo_: please prod me tomorrow or so.
[11:23] <mvo_> Mithrandir: will do, thanks :)
[11:26] <mdz> doko: if we make it a separate binary package, we would need to have an existing package depend on it anyway
[11:26] <mdz> doko: the idea is to have the drivers present that the user may need in order to get connected to the Internet
[11:27] <mdz> doko: as for the details of the packaging, I'll defer to fabbione; whatever the two of you agree on should be fine
[11:30] <doko> mdz: just, didn't want to penalize other users by the size of the package.
[11:37] <elmo> doko: sure
[11:43] <doko> elmo: powerpc64? thanks
[11:50] <amu> mdz: amd64 same problem  
[11:56] <mdz> amu: the module is just broken in the kernel package; it has nothing to do with the live CD
[11:59] <trukulo> hi ppl
[11:59] <trukulo> Mithrandir: u there?
[12:02] <Mithrandir> trukulo: yes
[12:03] <trukulo> Mithrandir: now, we need entire files to put torrents online, isn't it?