[02:52] <tseng> jdub: daniels any of you dudes have an interest in hardening?
[02:53] <tseng> ssp, pie
[06:30] <fabbione> morning guys
[08:34] <fabbione> mdz: ping
[08:44] <pitti> Morning
[08:53] <doko> morning
[09:17] <mdz> morning
[09:18] <Mithrandir> mdz: uhm, you're not supposed to say "morning" when it's morning here. :)
[09:18] <fabbione> mdz: hey
[09:18] <mdz> "morning" is the time when one appears on IRC
[09:19] <Mithrandir> well, true
[09:23] <mdz> fabbione: so, we seem to have inherited many of these file conflict bugs :-/
[09:28] <fabbione> mdz: yes i saw them. I need to prepare X for upload with some fixes and i am on them.
[09:28] <mdz> fabbione: I think that almost all of them are NOTWARTY (universe packages)
[09:29] <mdz> they are assigned to both packages, but generally it is the universe one which is buggy :-)
[09:29] <fabbione> mdz: ok
[09:30] <fabbione> mdz: i need a decision on 1878 now
[09:30] <mdz> fabbione: confirm a couple of things for me please
[09:30] <mdz> fabbione: 1. current via driver is buggy and hangs systems
[09:31] <mdz> fabbione: 2. new via driver from x.org is not significantly better
[09:31] <mdz> ?
[09:31] <fabbione> mdz: the driver from x.org = the one we have. The driver from unichrome is not that better. It still has a lot of glitches here and there
[09:34] <daniels> does it introduce new ones?
[09:34] <fabbione> I try it seems to be impossible to make TV-out output be "nice": it has
[09:34] <fabbione> _lots_ of flicker and overscan, and everything is offset to the right
[09:34] <fabbione> (so when you're watching DVDs, you miss the right half of the movie).
[09:34] <fabbione> daniels: yes
[09:34] <daniels> i.e. are we talking about buggy (vs non-existant) support for chipsets we don't support now?
[09:34] <daniels> or screwing up chipsets that were previously OK
[09:34] <daniels> if so, it's not worth reverting
[09:35] <daniels> (imo)
[09:35] <fabbione> daniels: that was ok before
[09:35] <fabbione> TReenaks: can you confirm?
[09:35] <daniels> argh!
[09:35] <fabbione> + the VT switching. i guess that was working before too
[09:35] <daniels> no, previously it just hung from Kamion
[09:35] <daniels> s/from/for/
[09:36] <daniels> that's progress ;)
[09:36] <fabbione> daniels: well he wrote something different in the bug report
[09:36] <mdz> there will be hardware and features that Warty does not support, this is unavoidable and not an RC issue.  However, Warty should not hang the system even if it doesn't properly support the hardware
[09:36] <fabbione> X starts up fine with the new driver (I suspect it might have started up with
[09:36] <fabbione> the old driver too if I'd had my font packages configured correctly);
[09:40] <daniels> mdz: right
[09:40] <daniels> mdz: hence my suggestion of just having all of via use vesa
[09:40] <daniels> mdz: afaict that's the least-bad case
[09:41] <daniels> may not support everything, but it doesn't hang
[09:41] <daniels> via seems to be a total basketcase in general
[09:42] <daniels> (the via-supplied driver doesn't even work, there are two external projects -- one of which is dead -- to fix it, but neither of them have great access to hardware)
[09:42] <mdz> I've never encountered a via graphics card
[09:42] <mdz> are there some which work correctly?
[09:42] <daniels> mdz: mercifully, they seem to be rare
[09:43] <daniels> mdz: i don't know. i assume so, but I've not seen any success reports (not that we tend to, obviously; just the bug reports)
[09:43] <daniels> i have no access to via, and it's not something I'm terribly upset about
[09:49] <fabbione> i still suggest that if we enounter a via card, we ask for the driver and we don't probe
[09:49] <fabbione> i am really not happy to default to vesa
[09:51] <pitti> mdz: can you please approve #2051? It's trivial (the gimp-print force-reload fix)
[09:51] <pitti> Hi carlos_!
[09:52] <mdz> yes
[09:53] <doko> mdz, mithrandir: what do we want to do about the amd64 gcc-3.3 biarch?
[09:57] <carlos_> hi
[09:57] <mdz> doko: well, we only use it for grub and oo.o, right?  as long as the changes are obviously correct and cannot introduce regressions, I think we can do it
[09:57] <mdz> we should only need to verify grub and oo.o if it is simple enough
[10:01] <mdz> doko: but when I look at the bug report, it sounds like too big a change for 9 days from release
[10:02] <mdz> it must touch 3 or 4 packages, replacing things which have been tested and work with new code...
[10:02] <mdz> jdub: do you have an opinion on #1996?
[10:05] <doko> yes, it touches many things. however they all look straight forward. for gcc-3.3 I outlined a less invasive approach (and not touching grub). For the gcc-3.4 change, ia32-libs-ooo is affected too.
[10:08] <mdz> elmo_: you were looking for me earlier?
[10:13] <elmo_> wondering if ndiswrapper should be going to main?
[10:13] <elmo_> (cf. jabber)
[10:17] <doko> elmo_: do we have a ubuntu-admin@, or is this just thom@ ? ;)
[10:17] <mdz> elmo_: tricky question
[10:18] <elmo_> doko: admins@admins atm
[10:18] <elmo_> err, admins@admins.warthogs.hbd.com I mean
[10:18] <mdz> elmo_: what does Mark say?
[10:18] <elmo_> the RFC-required addresses at @ubuntu.com etc. will work, but we don't have a proper admins one setup yet
[10:18] <elmo_> mdz: dunno, he's busy deciding out fate for the day(tm) with Steve - I'll ask him afterwards
[10:19] <mdz> elmo_: I think it probably belongs in SupportedSeed, but please confirm
[10:22] <fabbione> mdz, daniels: #ubuntu-meeting please
[10:27] <seb128> morning
[10:27] <elmo_> mdz: mark confirmed main - any more detail someone else will have to ask him if needed
[10:28] <pitti> Morning seb128!
[10:28] <seb128> hello pitti 
[10:28] <carlos> seb128: hey
[10:28] <mdz> elmo_: I'll add to SupportedSeed
[10:36] <mdz> elmo_: please move pnm2ppa into main; I added it to a seed already
[10:36] <plovs> are there any ops for the #ubuntu channel? 
[10:36] <mdz> plovs: why, is there a problem?
[10:38] <plovs> mdz, some people needs some kicking :)
[10:38] <plovs> ubuntu has been on slashdot you know
[10:40] <elmo_> mdz: as long as wvdial is in the seed list it's almost impossible for me to detect any other changes
[10:41] <mdz> elmo_: yes, that is overdue for fixing
[10:41] <mdz> apparently, the only other package which uses libwvstreams is "retchmail"
[10:42] <mdz> which doesn't sound like it uses all the crazy stuff in that library either
[10:42] <mdz> so I'm thinking we should just have a minimal build of libwvstreams
[10:49] <Kamion> morning
[10:52] <mdz> Kamion: morning
[10:52] <mdz> Kamion: the natives are anxious for the new live CD :-)
[10:54] <Mithrandir> do we have a bug# for the "splash screen stays around after logging in"?
[10:54] <mdz> elmo_: minimal wvstreams uploaded, should not require any other packages from universe
[10:54] <mdz> Mithrandir: with or without causing the entire login process to fail?
[10:54] <mdz> with = 1943
[10:55] <mdz> without = an old bug which was closed
[10:55] <Mithrandir> without
[10:55] <Mithrandir> mdz: on the mysterious system hangs bug -- it seems like it only happens with some packages, not all..
[10:55] <mdz> Mithrandir: 1725
[10:56] <mdz> seb128: ping?
[10:57] <seb128> pong
[10:58] <Mithrandir> I love how gnome-terminal is able to use 50% cpu on a 2.4GHz P4 when running tar cvzf
[10:58] <mdz> seb128: so about #1943...:-)
[10:59] <seb128> turn sound events off by default ? :)
[10:59] <mdz> seb128: I confirmed that disabling gnome-settings-sound.c:apply_settings works around the bug
[10:59] <mdz> so it is definitely related to the sound init
[10:59] <mdz> though I have not been able to find the exact problem
[11:00] <mdz> seb128: I would prefer to fix the bug, to be honest :-)
[11:00] <daniels> mdz: ping?
[11:00] <mdz> seb128: is there someone who is familiar with that reaper.c code?
[11:00] <seb128> this part of code is not really maintained upstream, so dunno where to get help. I've not knowledge of this part of code either and I'm not able to reproduce it here ...
[11:00] <seb128> I would like to fix it too
[11:01] <seb128> but I've no real idea on where to start
[11:02] <mdz> it is so strange that you cannot reproduce it
[11:02] <mdz> seb128: I can give you a shell on my machine if it would help
[11:02] <mdz> seb128: it is easy to reproudce at the command line
[11:02] <mdz> by running gnome-settings-daemno
[11:04] <seb128> ok, I'll have a serious look on this now. I'll start by making some extra tests on my test box and read the code
[11:04] <seb128> and then I'll ping you back if I need a shell. But I would like to reproduce it here, more easy to debug in local
[11:05] <mdz> seb128: thanks, this is high priority because many users are encountering it, and it completely breaks their system
[11:05] <seb128> on my box, if I "lsmod | grep '^snd' | awk '{ print $1 }' | xargs -n1 sudo rmmod" and login again, I don't even have a line about /dev/dsp
[11:05] <mdz> seb128: if you cannot isolate the problem today, we will need to disable sound events
[11:06] <mdz> seb128: that's strange; you have sound server startup enabled?
[11:06] <seb128> yes
[11:06] <seb128> sound events are working
[11:06] <seb128> I log out, remove the sound modules and log in again
[11:06] <seb128> no problem, no error in the log
[11:07] <seb128> I just get the volume applet to 0
[11:07] <Kamion> mdz: yeah, I know, will put it up this morning
[11:08] <Kamion> mdz: I'm just going to shove it in /releases/warty/preview/ for now (the location in the full tree is orthogonal to Mark's request for a simplified tree)
[11:08] <azeem> seb128: didn't hadess blog about sound being muted on startup recently?
[11:08] <azeem> might have been a different issue though
[11:11] <Kamion> wow, #ubuntu is a cesspit now
[11:13] <azeem> are the forums up yet?
[11:13] <Kamion> fabbione: defaulting to vesa seriously seems to be much more sane for the two via machines I have here; if you must ask, then at least please default to vesa not to via, I don't want to have to deal with the broken installations that will result otherwise
[11:16] <seb128> azeem: dunno, apparently you read a lot more blogs than me
[11:16] <seb128> azeem: any idea of the date of this blog entry ?
[11:17] <mdz> azeem: I think in this case it is set to 0 because there is no mixer device
[11:17] <azeem> seb128: heh, it might have been somewhere else again ;)
[11:18] <seb128> mdz: do you have esd running when to problem happens ?
[11:18] <mdz> seb128: no, esd cannot start because there is no /dev/dsp
[11:18] <mdz> it could be some kind of race condition, but my laptop loses 100% of the time
[11:18] <azeem> http://www.hadess.net/?start=453
[11:19] <azeem> "The next piece of work for system-config-soundcard is to fix the fact that ALSA starts up muted, and that the UI is starting to suck a bit"
[11:24] <seb128> ok, on this box I've a lot of "/dev/dsp: No such file or directory" in the log
[11:24] <seb128> but no problem to login
[11:25] <mdz> #2  0x0805de6f in vte_reaper_signal_handler (signum=-512) at reaper.c:64
[11:25] <mdz> I have no idea where signum=-512 comes from
[11:26] <seb128> vte is a terminal emulator
[11:27] <seb128> what is that doing here ?
[11:28] <mdz> that code is in reaper.c in gnome-settings-daemon
[11:28] <mdz> perhaps the code was copied from another place
[11:28] <mdz> anyway that handler is only called for SIGCHLD
[11:28] <mdz> and there is a test in the handler for that
[11:28] <mdz> so i think gdb is just lying
[11:29] <elmo_> gnome-nettool is pulling in tcptraceroute which is pulling in libnet0 and rman
[11:29] <elmo_> ok?
[11:30] <mdz> gah
[11:30] <mdz> how about we remove the dependency on tcptraceroute?
[11:31] <daniels> that thing is bloody *obscure*.
[11:31] <daniels> mdz: permission to upload http://people.ubuntu.com/~daniels/pppconfig/pppconfig-2.3.2ubuntu2-to-ubuntu3.diff ?
[11:33] <mdz> daniels: yes, thanks
[11:33] <mdz> I love it when gdb suspends itself and goes into the background
[11:33] <mdz> that's just the best
[11:34] <mdz> Detaching after fork from child process 10714.
[11:34] <mdz> /dev/dsp: No such file or directory
[11:34] <mdz> Detaching after fork from child process 10716.
[11:34] <mdz> /dev/dsp: No such file or directory
[11:34] <mdz> zsh: suspended (tty output)  gdb .libs/gnome-settings-daemon
[11:34] <mdz> after it does that it seems impossible to get it back; even if I continue it, it doesn't respond to any signals so i can't get back to the debugger
[11:34] <Mithrandir> run gdb on it?
[11:35] <seb128> ok, I've tried with the esd maintainer and some other GNOME guys, no clue
[11:35] <seb128> only advice "run away of this part of code if youy can" :(
[11:35] <mdz> great
[11:38] <Mithrandir> mdz: do you have a p4 with HT around?
[11:39] <mdz> Mithrandir: no, I do not
[11:40] <mdz> there might be someone I could ask, but they are asleep
[11:40] <Mithrandir> I can reproduce 1854 with debootstrap here.
[11:40] <Mithrandir> I haven't tried with a full fresh install, since I forgot to bring an extra hard drive today.
[11:41] <seb128> mdz: if you try to run esd from the command line, what happens ? 
[11:41] <seb128> any output, error, log ?
[11:41] <mdz> potpal:[...2.8.0/gnome-settings-daemon]  esd
[11:41] <mdz> /dev/dsp: No such file or directory
[11:41] <mdz> exactly what I see in xsession-errors
[11:41] <seb128> $ esd
[11:41] <seb128> $
[11:41] <mdz> fascinating
[11:41] <seb128> no log, no error
[11:42] <mdz> potpal:[...2.8.0/gnome-settings-daemon]  md5sum =esd
[11:42] <mdz> 59ad6b41a3c86f4e2e8be91a8b10c1ba  /usr/bin/esd
[11:43] <mdz> your esd != my esd?
[11:43] <seb128> on this box yes
[11:44] <seb128> but I've built the package, so that's not the autobuilded one
[11:44] <Mithrandir> mdz: linux-image-2.6.8.1-3-686-smp version 2.6.8.1-9; debootstrap warty /somewhere ; chroot /somewhere ; <edit sources.list>; apt-get update; aptitude install '~tdesktop'
[11:44] <mdz> seb128: ok, I have a workaround
[11:44] <seb128> mdz: could you try to rebuild esound ?
[11:44] <mdz> or perhaps a fix
[11:44] <seb128> oh ?
[11:44] <mdz> I disabled all of the pipe crap in the reaper
[11:44] <Kamion> Mithrandir: ~tubuntu-desktop
[11:44] <Kamion> surely?
[11:44] <mdz> as far as I could tell, its only purpose was for a debug/error message
[11:44] <mdz> and it looked buggy
[11:45] <Mithrandir> Kamion: yes, sorry, I was reading off an xscreenlocked screen. :)
[11:45] <seb128> ok, nice
[11:46] <mdz> seb128: I attached the patch to the bug
[11:46] <seb128> ok
[11:47] <seb128> mdz: dpkg -l | grep esd ?
[11:47] <mdz> seb128: I still get WAY too many error messages
[11:47] <mdz> but at least it lets me login
[11:47] <mdz> "/dev/dsp: No such file or directory" is repeated hundreds of times
[11:47] <mdz> and it tries to fork esd hundreds of times, which is a bit slow
[11:47] <mdz> ii  gstreamer0.8-esd    0.8.4-1ubuntu3      Enlightened Sound Daemon plugin for GStreamer
[11:47] <mdz> ii  libesd0             0.2.35-0ubuntu1     Enlightened Sound Daemon - Shared libraries
[11:47] <mdz> ii  libesd0-dev         0.2.35-0ubuntu1     Enlightened Sound Daemon - Development files
[11:47] <seb128> could you try with libesd-alsa0 ?
[11:47] <seb128> I've this one on this box in fact
[11:48] <seb128> instead of libesd0
[11:48] <mdz> libesd-alsa0 is crashy
[11:48] <seb128> hum
[11:48] <mdz> try it with libesd0 :-)
[11:48] <seb128> I'm installing it
[11:48] <mdz> perhaps then you can reproduce it
[11:48] <mdz> and then you could verify my patch
[11:48] <seb128> but on my test box which is a non-modified warty install, no problem
[11:48] <seb128> $ esd
[11:48] <seb128> /dev/dsp: No such file or directory
[11:48] <seb128> ok
[11:48] <seb128> the non-alsa version sucks
[11:49] <seb128> are you sure that the alsa version is crashy ?
[11:49] <seb128> 0.2.29 was crap
[11:49] <Mithrandir> Kamion: ~tdesktop seems to work fine as well
[11:49] <mdz> that is why we removed it from desktop
[11:49] <mdz> even after I fixed the bugs that I saw, it was crashy
[11:49] <seb128> but 0.2.35 should fixe most of the issues
[11:50] <mdz> it may be that 0.2.35 is better
[11:50] <mdz> but this is not an esd bug
[11:50] <seb128> that an esd/settings-daemon interaction
[11:50] <Kamion> Mithrandir: strange, there's no Task: desktop any more; maybe aptitude is too clever for its own good
[11:51] <Mithrandir> Kamion: it probably does substring match -- either works
[11:52] <mdz> seb128: right
[11:52] <seb128> mdz: ok, the non-alsa version flood the .xsession-errors, but doesn't hold the session here
[11:52] <Mithrandir> Kamion: ~tdesk seems to work as well
[11:52] <Kamion> Mithrandir: seems like bad behaviour, it means the result of the command can radically change if an extra task is introduced
[11:52] <mdz> seb128: I have no idea why it doesn't break for you, but the patch fixes it for me
[11:52] <seb128> ok
[11:52] <Mithrandir> Kamion: true
[11:52] <seb128> mdz: let's upload a package with the patch and see how it goes ?
[11:53] <mdz> seb128: ok
[11:53] <seb128> mdz: could you try without the patch with the alsa version of the lib ?
[11:53] <seb128> to know if that holds the session too
[11:53] <mdz> seb128: the stuff that I disabled only existed to emit a signal "child-exited" when the child exited
[11:53] <mdz> but there was nothing listening for it
[11:53] <seb128> ok
[11:53] <mdz> I think this code was cut-and-waste from elsewhere
[11:53] <seb128> probably
[11:54] <mdz> ok, I will revert to unmodified g-s-d and install libesd-alsa0
[11:56] <seb128> thanks
[11:57] <mdz> seb128: it does not seem to hang with libesd-alsa0
[11:57] <seb128> ok
[11:58] <mdz> switched back to libesd0, hangs
[11:59] <mdz> killall gnome-settings-daemon, install patched gnome-settings-daemon, works
[11:59] <seb128> ok
[12:00] <seb128> let's use the patch for now, but we should consider switching to the alsa version after warty
[12:00] <mdz> after warty hopefully we will get rid of esd :-)
[12:01] <seb128> true :)
[12:01] <mdz> yes, let's go with the patch
[12:02] <daniels> mdz: ok, so for #1897 we just clobber the file if either exists?
[12:02] <daniels> mdz: about to take care of that now
[12:03] <carlos> seb128: after warty, esound should die :-P
[12:03] <mdz> daniels: I'm fine with something similar to the supplied patch, but using grep instead of sed :-)
[12:03] <aj> elmo_: ?
[12:03] <mdz> I would probably have merged the stupid thing a year ago, except that I saw that sed and wanted to fix that first
[12:03] <elmo_> aj: ?
[12:04] <aj> elmo_: you "?"ed earlier?
[12:04] <elmo_> oh, one sec
[12:05] <daniels> mdz: yeah, as I said :)
[12:05] <daniels> mdz: heh, fair cop
[12:16] <daniels> mdz: permission to upload http://people.ubuntu.com/~daniels/dhcp3/dhcp3-3.0+3.0.1rc14-1-to-ubuntu1.diff ?
[12:16] <mdz> daniels: tested the hell out of it?
[12:16] <daniels> as much as I can, but I suppose more testing is always welcome
[12:17] <mdz> I don't have one of those broken dhcp servers handy which doesn't hand out nameservers
[12:17] <daniels> especially with something like the DHCP client
[12:17] <daniels> mdz: ... me neither
[12:17] <mdz> the code for the reasonable case is obviously well-tested and unchanged
[12:17] <mdz> daniels: go ahead and upload
[12:17] <daniels> mdz: (I just yanked that portion out and played around with calling with different variables)
[12:17] <daniels> mdz: thanks
[12:17] <mdz> as long as there are no regressions in the non-broken-dhcp-server case
[12:18] <daniels> not that I can see
[12:32] <elmo_> mdz: wvdial's in - I'll hold off on gnome-nettool's deps for now - lemme know if you decide to not fix the package
[12:33] <pitti> mdz: do you want to have all these universe file conflicts resolved for warty? I can do some of them
[12:37] <Kamion> I should look at debconf-doc/cdebconf, I guess
[12:40] <Kamion> um
[12:40] <Kamion> why does show_bug.cgi return 403?
[12:40] <Kamion> ah, fixed apparently
[12:41] <pitti> @all: http://www.piware.de/hal/ contains a new hal package which (among other things) should fix the "sometimes the first plugged in device is not recognized" bug (#1954); can somebody verify that?
[12:42] <pitti> @all: for me it works perfectly, but since upstream did not confirm the fix yet, it should get more than one person for testing it
[12:42] <sjoerd_> pitti: could you let me know the results of people testing that :)
[12:43] <pitti> sjoerd_: of course; I will send my latest three patches to David and you anyway
[12:43] <sjoerd_> pitti: nice, thanks
[12:43] <pitti> sjoerd_: BTW, does the patch work for you? Then I had already a second person :-)
[12:43] <pitti> sjoerd: (I assume it, because you have written it) :-)
[12:44] <sjoerd> pitti: yes ofcourse it does ;)
[12:53] <daniels> mdz: oh, yay! cpad is ... um ... interesting.
[12:54] <daniels> mdz: needs a separate driver, but it appears to register as a usb input device and also lcd
[12:54] <daniels> mdz: so you can draw shit on your touchpad (!)
[12:54] <Mithrandir> run xterm on your touchpad today!
[12:54] <daniels> if you wanted to, yeah
[12:54] <daniels> someone made an X server with a cpad output device
[12:57] <fabbione> daniels: i really think 1089 will be fixed with Denis and my changes
[12:57] <fabbione> daniels: he completely forgot to install the pc/us_intl layout :P
[12:57] <fabbione> if you want to reassing to me go ahead
[12:57] <daniels> haha yeah, I saw that :)
[12:57] <daniels> ok, another bug off my hands is good
[12:57] <fabbione> i am almost done with 1964 too
[12:58] <daniels> thanks
[12:58] <daniels> sounds cool :)
[12:59] <daniels> fabbione: http://www.dietmar-kuehl.de/Xcpad/
[12:59] <fabbione>     db_get debian-installer/keymap || true
[12:59] <fabbione>     if [ "$RET" = "br-abnt2" ] ; then
[12:59] <fabbione>       LAYOUT="br"
[12:59] <fabbione>     else
[12:59] <fabbione>       LAYOUT="us_intl"
[12:59] <fabbione>     fi
[01:00] <fabbione>     XKBOPTIONS=""
[01:00] <fabbione>     ;;
[01:00] <fabbione> the other exception for br -> abnt2 was already there
[01:00] <fabbione> so already defining the proper LAYOUT will do the trick
[01:01] <fabbione> but we must have the ub3r keyboard setting tool for hoary
[01:01] <fabbione> going or LANG isn't enough
[01:02] <Kamion> we'll have localization-config from Debian for hoary ...
[01:02] <Kamion> (Konstantinos' thing)
[01:04] <fabbione> Kamion: yes. the cose i am using has been stolen from it
[01:04] <mdz> pitti: don't bother with the file conflicts if the universe package is the buggy one
[01:05] <mdz> pitti: downgrade the bug if it is universe's fault
[01:05] <fabbione> 2 problems: 1) he didn't coordinate with X at all. He preseeds templates that might not even be there (last time i checked at least)
[01:05] <pitti> mdz: okay
[01:06] <fabbione> 2) the templates needs to go in something/shared and we need to sync translations & co. that hasn't been done
[01:06] <mdz> pitti: I can't reproduce the "first plugged in" bug, at least not reliably
[01:06] <Kamion> mdz: we forgot to make lsb-release's Ubuntu version number consistent with everything else (i.e. "4.10" rather than "4-10"); OK to upload?
[01:06] <mdz> Kamion: yes
[01:06] <pitti> mdz: its not reliable anyway (it's a race condition)
[01:07] <fabbione> mdz: you marked 2007 as duplicate of 1964 but they aren't really the same
[01:07] <pitti> mdz: I thought you were already asleep, but you can test my package before approval
[01:08] <fabbione> mdz: one option to catch all the possibility is to confirm the layout when LAYOUT=unknown or LAYOUT=us, that seems to be most common problem.
[01:08] <pitti> mdz: http://www.piware.de/hal/hal_0.2.98-1ubuntu5_i386.deb
[01:10] <mdz> fabbione: I mentioned that on Saturday, but you said it was the same
[01:10] <daniels> mdz: comments on 2026 and 2057?
[01:10] <mdz> already commented on 2026, keep up
[01:11] <daniels> yeah, just got the mail
[01:11] <daniels> it's not my fault every bug takes like 3 minutes to load
[01:11] <daniels> :P
[01:14] <daniels> Kamion: how I learnt to stop worrying and love dhb_register
[01:15] <mdz> pitti: I have never seen the warning emitted by that code block
[01:16] <fabbione> mdz: well i read it again and i noticed that it is not exactly the same
[01:16] <daniels> mdz: basically, we don't have any support for those touchpads whatsoever (for the cPads, we cannot make a working configuration out of the box; I believe we cannot get any working ALPS configuration) and doing both of 2026 and 2057 would fix this
[01:16] <mdz> fabbione: ok, feel free to fix up the bug
[01:17] <fabbione> mdz: asking the question if LAYOUT=unknown or LAYOUT=us ?
[01:17] <mdz> daniels: ok, that's just missing hardware support, and we'll have that.  not RC, then
[01:17] <daniels> mdz: -> hoary?
[01:17] <mdz> fabbione: why LAYOUT=us?
[01:17] <mdz> daniels: yes
[01:17] <daniels> mdz	fair cop
[01:18] <fabbione> mdz: 2007 got a US layout when it should have been es
[01:18] <fabbione> mdz: probably due to a lang setting
[01:18] <mdz> fabbione: so probably he chose English install but with Swedish keymap?
[01:20] <fabbione> mdz: could be...
[01:20] <fabbione> we don't have console -> X mappings
[01:20] <fabbione>   *"SE"* ) LAYOUT="se" XKBOPTIONS="" ;;
[01:20] <mdz> seb128: is it possible to remove the tcptraceroute dep from gnome-nettool?
[01:21] <fabbione> mdz: he must have got a strange LANG or something that we don't handle directly
[01:21] <fabbione> mdz: that would explain the "bug"
[01:21] <fabbione> but there is no winner here until we don't have console -> X keyboard maps
[01:26] <seb128_> mdz: if we remove a part of the UI yes
[01:31] <fabbione> daniels:
[01:31] <fabbione> # Specific via workaround:
[01:31] <fabbione> if [ "$DEFAULT_DRIVER" = "via" ]  || [ "$DEFAULT_DRIVER" = "vesa" ] ; then
[01:31] <fabbione>   PRIORITY="high"
[01:31] <fabbione> fi
[01:31] <fabbione> db_subst xserver-xfree86/config/device/driver choices "$DRIVER_LIST"
[01:31] <fabbione> auto_answer db_input "$PRIORITY" \
[01:31] <fabbione>   xserver-xfree86/config/device/driver "$DEFAULT_DRIVER"
[01:31] <fabbione> this will ask for the driver if we detect via or the driver is vesa (that is never returned by discover1)
[01:31] <fabbione> that means=unknown
[01:32] <daniels> ok
[01:32] <daniels> that saves me s/via/vesa/ in discover1-data
[01:32] <daniels> fabbione: fine by me
[01:32] <daniels> fabbione: you might want to mention that the via driver is buggy as shizzle in that comment
[01:34] <fabbione> # Specific via workaround:
[01:34] <fabbione> # the via driver sucks nuts and we can't rely on it. The user will
[01:34] <fabbione> # have to decide which cracks he prefers and he has 3 options:
[01:34] <fabbione> # - via
[01:34] <fabbione> # - vesa
[01:34] <fabbione> # - visa (or mastercard) to buy a serious video card
[01:34] <azeem> heh
[01:34] <pitti> mdz: (sorry, lunch) the new warning is only written in the case where the previous hal segfaulted (as you wrote in the bug)
[01:35] <daniels> fabbione: heh :)
[01:35] <fabbione> ok agreed :-)
[01:35] <mdz> pitti: no, I meant the other patch
[01:35] <fabbione> time to ban the probe now
[01:35] <mdz> pitti: the one which removes the sequence number check
[01:35] <pitti> mdz: ah; I have seen it several times
[01:35] <pitti> mdz: the last_sequence_number (or so) had a random number and the comparison result was more or less random
[01:36] <pitti> mdz: BTW, you do not follow your own advice in your energy mail...
[01:36] <mdz> pitti: today is monday :-P
[01:37] <pitti> mdz: ask your body :-)
[01:37] <daniels> mdz: do I get to take Tuesday off in compensation for having worked half of Sunday? ;)
[01:38] <mdz> pitti: I needed to wake up at 0500 today anyway to take monika to the airport
[01:38] <mdz> and finish getting ready for the fumigation
[01:38] <fabbione>       # we know the driver from config.in
[01:38] <fabbione>       db_get xserver-xfree86/config/device/driver
[01:38] <fabbione>       DEVICE_DRIVER="$RET"
[01:38] <fabbione>       case "$DEVICE_DRIVER" in
[01:38] <fabbione>         via)
[01:38] <fabbione>           PROBE_DUMP="" 
[01:38] <fabbione>         ;;
[01:38] <fabbione>         *)
[01:38] <fabbione>           set +e
[01:38] <fabbione>           PROBE_DUMP=$(xresprobe "$DEVICE_DRIVER")
[01:38] <fabbione>           set -e
[01:38] <fabbione>         ;;
[01:38] <fabbione>       esac
[01:38] <fabbione> daniels: ^^^ banning via from probing
[01:39] <daniels> fabbione: hm
[01:39] <pitti> mdz: so far the hal package works for you? Then we are already three; I will still wait a bit, maybe thom returns in the next hours
[01:39] <mdz> pitti: I have not tested it
[01:39] <daniels> fabbione: why not do if [ "$RET" = "via" ] ; DEVICE_DRIVER="vesa"; fi
[01:40] <daniels> fabbione: that still allows for DDC probes, which are harmles
[01:40] <fabbione> daniels: hmmmmmmmmmmm
[01:40] <fabbione> daniels: what if the card looks up the machine?
[01:41] <daniels> fabbione: on a DDC probe? then shit dude, it has bigger problems
[01:41] <daniels> fabbione: and will be unusable with the vesa driver also
[01:41] <daniels> think of it as an early warning if a VESA VBE DDC probe kills the machine :)
[01:41] <fabbione> daniels: didn't you say that via doesn't return DDC stuff because it doesn't store it in the NVRAM?
[01:41] <fabbione> or BIOS or whatever
[01:41] <daniels> fabbione: only for laptop panels, and we were trying with read-edid, not ddcprobe
[01:42] <daniels> read-edid actually misses a massive chunk of the DDC data
[01:42] <daniels> if we try it with ddcprobe, the best case is we get a working resolution, the realistic worst case is that the resolution is wrong
[01:42] <fabbione> daniels: i see your point, but i am really not too happy to force that on cards that already sucks
[01:43] <fabbione> daniels: i much rather prefer to ask the resolution
[01:43] <fabbione> without hanging the machine
[01:43] <fabbione> since we can't test it, i would much rather prefer to skip it
[01:43] <fabbione> 100% to be safe
[01:43] <daniels> fabbione: um
[01:44] <daniels> seriously, as I said, if it hangs on a DDC probe, then it won't be able to use either the VESA or Via driver
[01:44] <daniels> it will also die on Windows installs
[01:44] <fabbione> ok
[01:45] <fabbione>       db_get xserver-xfree86/config/device/driver
[01:45] <fabbione>       DEVICE_DRIVER="$RET"
[01:45] <fabbione>       if [ "$DEVICE_DRIVER" = "via" ] ; then
[01:45] <fabbione>         DEVICE_DRIVER="vesa"
[01:45] <fabbione>       fi
[01:45] <fabbione>       set +e
[01:45] <fabbione>       PROBE_DUMP=$(xresprobe "$DEVICE_DRIVER")
[01:45] <fabbione>       set -e
[01:45] <fabbione> there
[01:46] <daniels> cool
[01:47] <fabbione> daniels: 1999
[01:47] <fabbione> any idea?
[01:47] <fabbione> we didn't touch that code at all
[01:47] <fabbione> and he seems to be the only one with that problem
[01:47] <daniels> ?!?
[01:47] <fabbione> otherwise we would have received a few tons of bugs
[01:48] <daniels> the title looks bizzare, but the body will take like a minute to come down still
[01:48] <fabbione> no problem
[01:49] <daniels> wtf
[01:49] <daniels> i suggest local problem
[01:49] <daniels> probably hanging on IO?
[01:55] <fabbione> daniels: i have really no idea
[01:55] <fabbione> i am pretty sure it's not a problem in the script
[01:55] <fabbione> we would have noticed in debian too
[01:56] <daniels> yeah
[01:56] <daniels> it's bong
[01:57] <fabbione> mind to ask or comment?
[01:58] <daniels> you want me to?
[02:00] <mdz> seb128: there is a part of the UI which uses tcptraceroute? for what?
[02:00] <mdz> seb128: can we change it to use tracepath instead?
[02:01] <seb128> mdz: run gnome-nettool :) The UI has differents tab: traceroute, port scan, finger, whois ...
[02:01] <seb128> no idea, but I can have a look if you want
[02:01] <mdz> seb128: at first glance it seems to just provide a way to run the program and view its output
[02:01] <mdz> so I think tracepath would work fine
[02:02] <seb128> I think so
[02:02] <mdz> seb128: do you want a bug as a reminder?
[02:02] <seb128> yes please
[02:04] <fabbione> daniels: yes please.
[02:05] <fabbione> mdz: 2054. there are several differences between the 2 logs
[02:05] <fabbione> mdz: but 2 of them are quite relevant
[02:05] <fabbione> -(++) using VT number 8
[02:05] <fabbione> +(++) using VT number 7
[02:05] <fabbione> -(II) PCI: stages = 0x03, oldVal1 = 0x00000000, mode1Res1 = 0x80000000
[02:05] <fabbione> +(II) PCI: stages = 0x03, oldVal1 = 0x8000003c, mode1Res1 = 0x80000000
[02:05] <fabbione> -       BytesPerScanline: 528
[02:05] <fabbione> +       BytesPerScanline: 594
[02:05] <fabbione> + = working config
[02:05] <fabbione> - = bad config
[02:06] <fabbione> how come it starts on vt8 in the first place...
[02:06] <fabbione> the driver hasn't changed 
[02:23] <Kamion> pitti: what approach are you taking to the debconf-doc/cdebconf bug? I was just about to fix that in Debian.
[02:23] <pitti> Kamion: none actually
[02:24] <pitti> Kamion: I just saw that cdebconf is not installable in Warty anyway
[02:24] <Kamion> (by adding a conflicts)
[02:24] <pitti> Kamion: it will remove 1GB of packages
[02:24] <pitti> Kamion: I can reassign it to you if you want
[02:24] <Kamion> it is perfectly installable, just not simultaneously with debconf :-)
[02:24] <pitti> Kamion: but half a thousand packages depend only on debconf
[02:25] <Kamion> yes, I know
[02:25] <Kamion> it's not really a bug, cdebconf will probably eventually replace debconf
[02:25] <Kamion> I'm not sure why it's in warty though
[02:25] <pitti> Kamion: it is a bug in those many packages; they should depend on debconf|cdebconf, not?
[02:25] <pitti> Kamion: cdebconf is not in warty
[02:26] <Kamion> pitti: oh, indeed it isn't, madison output confused me, only the source is there
[02:26] <thom> pitti: hi. what's up?
[02:26] <Kamion> pitti: noooooo
[02:26] <Kamion> pitti: cdebconf is *not ready* to replace debconf yet :)
[02:26] <Kamion> pitti: just NOTWARTY it then, I'd say
[02:26] <pitti> Kamion: agreed
[02:27] <pitti> thom: I wanted to ask you if you could review the hal package in http://www.piware.de/hal/ to check bug #1954
[02:27] <mdz> need to move stuff out for the fumigation, back later
[02:28] <pitti> Kamion: I write a bug comment and downgrade
[02:28] <daniels> fabbione: weird. i dunno about that bug.
[02:29] <Kamion> RESOLVED/NOTWARTY is not so much a downgrade :)
[02:29] <Kamion> pitti: fixed upstream, anyway
[02:29] <pitti> Kamion: okay.
[02:30] <fabbione> daniels: 1989 -> LATER
[02:30] <fabbione> daniels: 2054 looks to me a user fucks up
[02:30] <fabbione> we didn't touch the intel driver at all
[02:30] <fabbione> we didn't change build kernel on buildd
[02:30] <fabbione> we didn't change anything that touches dri/drm
[02:31] <thom> pitti: ok, building now
[02:31] <pitti> thom: i386 packages are already available, btw
[02:32] <thom> pitti: yup
[02:32] <thom> uname -m
[02:32] <thom> x86_64
[02:32] <thom> :-)
[02:33] <pitti> thom: I repeatedly restarted dbus, watched whether the first and second hotplug produced a Volume node in device manager, goto 1
[02:33] <pitti> thom: dbus restarts will kill gnome-volume-manager, but that's not the point here; device manager is good for verification
[02:33] <daniels> fabbione: bong
[02:34] <Kamion> pitti: (actually, the eventual solution will more likely be for packages to depend on a virtual package like debconf-2.0)
[02:34] <daniels> fabbione: I suspect we need XF86Config-4
[02:34] <pitti> Kamion: right, I actually meant that
[02:35] <occy> Will the pcmcia issues get worked out before a final release is produced?
[02:36] <fabbione> wtf is wrong with wmdial that asks me if i want to configure the modem in text mode and at install time?
[02:36] <Kamion> occy: which pcmcia issues?
[02:36] <occy> I tried to post a bug detailing my problems on my laptop with the Sept 28, Sept 29, and Oct 1 Nightlies...   But bugzilla ate it. :(
[02:37] <occy> Kamion: I have a Dell Inspiron 7500  (quite a common older laptop)  and all distros work peachy with pcmcia on it.   Ubuntu hangs during install at loading pcmcia
[02:37] <thom> pitti: yup, looks good to me
[02:37] <pitti> thom: fine; plovs also tests it right now, if it works for him, I will upload the beast
[02:37] <pitti> thom: thanks for testing!
[02:38] <Kamion> occy: related to bug #581?
[02:38] <occy> Kamion: let me take a look at that one.
[02:38] <Kamion> although I think that's a Dell desktop, hm
[02:39] <occy> by "blocking" does that mean prevent installation?
[02:39] <Kamion> occy: I'm afraid the way to make sure somebody looks at it *is* to file a bug; if Bugzilla keeps eating it, you might want to mail justdave@canonical.com for help
[02:39] <Kamion> block means waiting for I/O
[02:39] <occy> ahh
[02:40] <occy> Kamion: who is this person?   justdave@canonical.com?  Is he a developer?
[02:41] <Kamion> he runs our Bugzilla installation
[02:41] <daniels> occy: david miller, our bugzilla dude
[02:41] <occy> daniels: ahhh... "The Bugzilla Dude"&copy;
[02:42] <occy> tx guys
[02:48] <occy> https://bugzilla.ubuntu.com/show_bug.cgi?id=2059
[02:48] <occy> :)
[02:49] <occy> Is there any other information I could attach to that bug that might be helpful?
[02:50] <Kamion> occy: there should be some relevant log messages on tty3 or tty4 (use alt-f3 and alt-f4 to get to them)
[02:50] <occy> ahh ok, let me go do that so I can add it to the bug.  tx.    /me reboots to get the bug again.
[02:50] <occy> :)
[02:51] <occy> tx gang
[03:25] <occy> Kamion:  Warning: **: bad d-i Packages file   grep:  /cdrom/dists/stable/Release     : Not a directory.      This repeats in a loop.
[03:26] <occy> Kamion: that same CD installed on my desktop just peachy.
[03:26] <Kamion> occy: you probably have DMA problems then, we recently disabled DMA by default for CD drives to avoid this problem
[03:26] <occy> ahh
[03:26] <occy> ok, I'll go grab a new nightly bud.  tx :)
[03:26] <occy> sorry to bug the devel channel
[03:27] <occy> oh, one last thing.  If that fixes it, should I delete that bug?
[03:29] <Kamion> certainly tell the bug about it
[03:36] <occy> k
[03:42] <fabbione> daniels: are you still around?
[03:50] <daniels> fabbione: sup?
[03:51] <fabbione> daniels: ubuntu23 is up
[03:52] <daniels> yeah, saw it on -changes just then
[03:52] <fabbione> ok good
[03:52] <fabbione> i am off
[03:52] <daniels> looks good -- i have a few things to do around the house (moving back out on thursday) so I'll eb around for a while
[03:52] <fabbione> i start to dream about X.org at night
[03:52] <daniels> i'll keep an eye on the logs/bz/etc and fix it if anything goes badly wrong
[03:52] <daniels> dude!! stop working on x for a while.
[03:52] <fabbione> ok good
[03:52] <daniels> i had a dream about introducing a rgb vs bgr bug in the x server once and in my dream, I debugged it with a lot of ErrorF()s and gdb
[03:53] <daniels> and fixed the bug
[03:53] <daniels> that was pretty bad
[03:53] <fabbione> daniels: that crack for X.org is good you have no idea
[03:53] <daniels> heh heh :)
[03:53] <fabbione> even Branded liked that crack so much that he is all high up for it
[03:53] <daniels> well, I've gotta pop off for a few minutes, so have a good lunch or whatever, and take care :)
[03:53] <daniels> hahaha
[03:53] <fabbione> yeah later
[03:54] <daniels> nah dude, I'm still here
[03:55] <fabbione> daniels: you are supposed to be my upstream bitch :P
[03:55] <daniels> i can be both :)
[03:55] <fabbione> ahhah you love to suck, don't you ???
[03:56] <fabbione> later bitch^Wdaniels
[05:33] <elmo_> is it just me or is "build a kernel image with the warty source" far more complex than it ought to be?
[05:35] <Kamion> is it not just dpkg-buildpackage from the source package?
[05:40] <elmo_> err, that'll build all the madness ?
[05:40] <elmo_> I mean build a custom kernel image
[05:40] <elmo_> 'export PATCH_THE_KERNEL=yes' isn't exactly intuitive, IMO
[05:41] <elmo_> CONFIG_BROKEN=y
[05:41] <elmo_> mmk
[05:46] <Keybuk> make-kpkg, especially all the patch gubbins, has always been a little Manoj for my tastes
[06:45] <Kamion> can someone peer-review my patch in #1332 for me, please?
[06:45] <Kamion> I've tested it in all three mentioned cases
[06:54] <elmo_> I guess the /tmp use is safe (?), but it's security-team bait :)
[07:00] <Kamion> the /tmp use in question is run inside d-i, where there are no other users
[07:00] <elmo_> right.. anyway, nm
[07:00] <elmo_> it looks fine to me, FWIW, but I can't test it
[07:01] <Kamion> yeah, not really expecting anyone else to be able to yet :/
[07:01] <Kamion> thanks
[07:27] <thom> elmo_: can you apply the patch in #1960 to /usr/bin/mozilla-firefox and confirm it fixes the problem for you?
[07:29] <elmo_> thom: yes, works for me
[07:31] <thom> goodo
[07:32] <thom> mdz: can i upload php with either mine or adam's patches? I don't think going with a new upstream is a good move
[07:33] <mdz> thom, which is better, yours or his?
[07:33] <thom> mine fixes a printf, other than that they're identical
[07:34] <mdz> your call then
[07:34] <mdz> one of them is OK by me
[07:34] <thom> k
[07:34] <mdz> but not both :-)
[07:34] <fabbione> thom: upload adam's one.. you can have someone else to blaim ;)
[07:34] <mdz> latest ipw2200 is working nicely
[07:34] <thom> fabbione: i'm planning to blame you either way :-)
[07:35] <fabbione> i know NOTTING about php ;)
[07:35] <thom> mdz: and new firefox with the fix for #1960 also?
[07:35] <thom> fabbione: that's why you're perfect to blame ;-)
[07:36] <mdz> thom: 1960 looks good to me
[07:42] <mdz> Kamion: did I ask you already about using the linux-* metapackages in base-installer?
[07:42] <mdz> I'm a bit out of it and can't recall
[07:43] <thom> Mozilla/5.0 (X11; U; Linux x86_64; rv:1.7.3) Gecko/20041004 Firefox/0.10.1 (Ubuntu)
[07:43] <Kamion> you did, about to look at that now
[07:44] <Kamion> just uploading that prebaseconfig/base-config thing for UTC handling first
[07:44] <mdz> argh, silly xchat
[07:44] <mdz> Kamion: I fixed them up so that they're actually installable on all architectures
[07:44] <Kamion> mdz: although it's a little awkward due to the lack of easily greppable naming pattern, hmm
[07:44] <mdz> I think we should probably clean them up so that they don't require 3 levels of metapackages, but that can come later
[07:45] <mdz> I think linux-foo should depend directly on linux-x.y.z-n-foo
[07:45] <mdz> rather than via linux-image-2.6-foo
[07:45] <Kamion> kernel_update_list () {
[07:45] <Kamion>         # Using 'uniq' to avoid listing the same kernel more then once.
[07:45] <Kamion>         (set +e;
[07:45] <Kamion>          chroot /target apt-cache search kernel-image | grep ^kernel-image;
[07:45] <Kamion>          chroot /target apt-cache search linux-image | grep ^linux-image) | \
[07:45] <Kamion>         cut -d" " -f1 | uniq > $KERNEL_LIST
[07:45] <Kamion> }
[07:45] <Kamion> I'm trying to figure out what to do with that bit ...
[07:45] <mdz> hmm, that's inconvenient
[07:46] <mdz> if not for amd64, linux-[^-] * would work
[07:46] <mdz> I'm a bit crippled on my laptop right now, it having recently been reinstalled and hurriedly prepped to be my primary workstation for a couple of days
[07:46] <mdz> could someone kindly clean up my mess and squash #2063?
[07:47] <Kamion> also linux-686-smp etc., which would work on netboot installs
[07:48] <Kamion> does apt-cache search look at the source package name?
[07:48] <mdz> don't think so
[07:48] <mdz> that command-line really should use apt-cache search -n
[07:49] <mdz> that grep seems to be working around the lack of -n
[07:49] <Kamion> -n?
[07:49] <mdz> --names-only
[07:49] <mdz> matches the package name only, not description
[07:49] <Kamion> it also works around lack of ^ in the apt-cache search
[07:49] <mdz> yes...
[07:49] <Kamion> does apt-cache search --names-only ^kernel-image work?
[07:50] <mdz> in fact what that really wants to be is "apt-cache pkgnames linux-image"
[07:50] <mdz> Kamion: absolutely
[07:50] <mdz> but apt-cache pkgnames would avoid the cut and uniq as well
[07:51] <Kamion> apt-cache pkgnames returns packages that are not actually available
[07:51] <mdz> not that we should be tweaking for elegance reasons at this point, really...:-)
[07:51] <Kamion> <cjwatson@cairhien ~>$ apt-cache search --names-only ^kernel-image | grep 2.2.20<cjwatson@cairhien ~>$ apt-cache pkgnames kernel-image | grep 2.2.20            kernel-image-2.2.20-pmac
[07:51] <Kamion> kernel-image-2.2.20-prep
[07:51] <Kamion> kernel-image-2.2.20-chrp
[07:51] <Kamion> oopsie, but you get the idea
[07:52] <mdz> true, it'll likely match anything mentioned in a dependency relationship
[07:52] <Kamion> anyway, still leaves the problem of how to find the metapackages
[07:53] <Kamion> shame I didn't think of this before, I'd have suggested linux-meta-*
[07:53] <mdz> we only have 3 architectures; we could hardcode it
[07:53] <mdz> *duck*
[07:53] <Kamion> ewwwwwwwww
[07:54] <Kamion> we could put grep-dctrl in base and then I could use that :)
[07:54] <thom> mdz: i'll take 2063
[07:54] <mdz> thom: thanks
[07:55] <mdz> apt-cache -n search '^linux-(.86|k7|power|amd64)'
[07:55] <Kamion> there might be a better way, testing now
[07:55] <thom> oh. for powernow on amd64 it seems like the only module is powernow-k8; i could just hardcode that based on uname -m :/
[07:56] <mdz> thom: WFM
[07:58] <Kamion> hm, no, apt-cache search doesn't look at descriptions
[07:58] <Kamion> s/descriptions/dependencies/
[07:59] <Kamion> mdz: you know, "apt-cache search 'Complete Linux kernel on'" is actually slightly less gross :)
[07:59] <mdz> Kamion: ewwww
[08:00] <mdz> apt-cache search -n '^linux-' | grep -v '^linux-image'
[08:00] <Kamion> returns linux-headers
[08:01] <mdz> wow, #ubuntu really is a cesspool now
[08:01] <mdz> but a cesspool of 220 persons(!)
[08:01] <thom> yeah
[08:01] <mdz> when did we gain another 40?
[08:01] <mdz> did the live cd announcement go out? :-)
[08:02] <Kamion> # apt-cache -n search ^linux- | head -n 1
[08:02] <Kamion> klogd - Kernel Logging Daemon
[08:02] <Kamion> WTF?
[08:02] <thom> and 550 mails on the bugs list over the weekend *sob*
[08:02] <Kamion> so the grep really is needed
[08:02] <Kamion> mdz: apt-cache search -n ^linux- | grep ^linux- | grep -v 'linux-\(doc\|.*headers\|.*modules\|patch\|source\|tree\)'
[08:03] <Kamion> returns the right set ...
[08:04] <Kamion> I'm rather tempted to suggest renaming the packages while we still can, though
[08:04] <mdz> I am very partial to the simple linux-foo naming
[08:05] <Kamion> it really sucks for greppability, though
[08:05] <mdz> one day you will be able to "apt-get install linux" and have it DTRT :-)
[08:06] <thom> dpkg-buildpackage -rfakeroot -S -sa  21.50s user 52.98s system 20% cpu 5:57.91 total 
[08:06] <thom> gosh, i wonder what package that could be
[08:06] <mdz> hehe
[08:07] <thom> mdz: oh, hey. everytime i reboot, my evms partition doesn't work till i rerun evmsn - i don't get /dev/evms entries till then
[08:08] <thom> have i missed something obvious?
[08:08] <mdz> really? that's odd
[08:08] <mdz> what if you run evms_activate?
[08:08] <mdz> oh, I know what it is
[08:08] <mdz> thom: your evms volumes are on a device that is created when hotplug runs
[08:08] <mdz> and evms runs ahead of hotplug
[08:08] <thom> ah, yep.
[08:09] <mdz> it should probably re-run after hotplug
[08:09] <thom> or get kicked by udev for certain types of things getting loaded?
[08:11] <mdz> hmm
[08:12] <mdz> currently there's no way to tell it only to discover volumes on a certain device
[08:12] <mdz> but that'd be handy
[08:13] <thom> that seems to be the way things are heading
[08:14] <thom> but yeah, i have /dev/evms/home        143G  5.9G  137G   5% /home and it seems to be working nicely - xfs over software raid1 on serial ata
[08:16] <mdz> thom: configured from the ground up with evms?
[08:17] <thom> yep
[08:18] <mdz> nice
[08:18] <thom> the manual is pretty decent
[08:18] <mdz> so nice to be able to build a volume like that without prodding 3 or 4 different subsystems with their own config files
[08:18] <thom> definitely
[08:19] <thom> especially since evmsgui is just nicely clicky-clicky :-)
[08:19] <mdz> one of these days someone will write a decent CLI for it
[08:19] <thom> (you should include a .desktop file for it and include it in System Config)
[08:19] <mdz> with zsh tab completion *swoon*
[08:19] <thom> heh, that'd be nice
[08:19] <mdz> thom: I *so* don't want that support headache :-)
[08:20] <mdz> the GUI, while very nice, is not exactly desktop-user-friendly
[08:20] <thom> not quite, no
[08:21] <thom> it'd be cool tho
[08:21] <thom> firefox is crawling up my adsl
[08:46] <mdz> anyone have a 30-second tutorial to set up outbound smtp auth in postfix?
[08:55] <tseng> http://www.postfix.org/SASL_README.html
[08:55] <tseng> doesnt look to hook into pam there
[09:02] <mdz> tseng: it uses sasl for outbound?
[09:02] <tseng> oh im sorry i misunderstood
[09:03] <tseng> you want your mta to send smtp auth to another mta?
[09:03] <mdz> right
[09:04] <tseng> hm its in the bok
[09:04] <tseng> *book.
[09:09] <tseng> smtpd_sasl_auth_enable = yes
[09:09] <tseng> er, -d
[09:09] <hazmat> there's some docs for it on gentoo.org
[09:09] <tseng> smtp_sasl_password_maps = hash:/etc/postfix/sasl_password
[09:09] <tseng> hazmat: that doc is ridiculous
[09:09] <elmo_> 62 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
[09:10] <elmo_> since 6am this morning! (i.e. like, 14 hours ago).. you guys are KraZY
[09:10] <tseng> ora.com        kdent:Password
[09:10] <tseng> is the example sasl_passwd file
[09:10] <hazmat> tseng, why is that?
[09:11] <tseng> hazmat: um
[09:11] <tseng> for one thing it uses pam_mysql to read mysql user info when sasl can do it directly
[09:12] <tseng> also it uses $variable to denote variables to be filled in my the user
[09:13] <tseng> and also literally a variable, like $mydomain
[09:13] <tseng> that confused the hell out of people.
[09:13] <hazmat> its been updated in the last week
[09:14] <tseng> hm, by whom?
[09:15] <tseng> it still sucks
[09:15] <tseng> for the same reasons
[09:15] <tseng> virtual_minimum_uid = 1000
[09:15] <tseng> virtual_gid_maps = static:$vmail-gid
[09:16] <tseng> if you werent paying close attention, you wouldnt replace $vmail-gid with say, 1001
[09:16] <tseng> because postfix uses $variable as well
[09:18] <tseng> oh well.
[09:18] <hazmat> dunno, but its also one of the few good howto docs on how to set it up on the net.. 
[09:18] <hazmat> mdz, http://gentoo-wiki.com/HOWTO_Email_System_for_the_Home_Network
[09:18] <tseng> good being relative
[09:19] <tseng> oh, you are talking about that ^ ?
[09:19] <daniels> hazmat: cairo
[09:19] <tseng> http://www.gentoo.org/doc/en/virt-mail-howto.xml is how i mean
[09:19] <daniels> er
[09:19] <hazmat> tseng, i know, there were two different topics
[09:19] <hazmat> the link above answers mdz's question though
[09:20] <tseng> good deal then
[09:20] <hazmat> but i was curious about your condemenation of the virt mail howto, as i've used it before
[09:20] <tseng> ive helped a bunch of people with it
[09:21] <tseng> it was a painful experience every time
[09:23] <tseng> hm who is martin pitt on irc?
[09:28] <ggi> tseng: pitti
[09:29] <pitti> ggi: yes, what's up?
[09:30] <ggi> pitti: Nothing, tseng asked who Martin Pitt was on irc.
[09:30] <pitti> ggi: ah; I just rejoined (just did a Warty installation)
[09:30] <hazmat> are there seperate team mailing lists?
[09:34] <mdz> hazmat: not yet, currently everything is on ubuntu-devel
[09:39] <pitti> Argh, why does bugzilla erase any field when an input is wrong? It just ate my bug report... In addition, I _did_ specify a component (although I was told that I didn't)
[09:42] <mdz> seb128: here?
[09:42] <seb128> yes
[09:42] <seb128> and wanted to ping you about the patches for the control-center
[09:43] <tseng> pitti: im brandon on "hald segfaults"
[09:43] <seb128> what do you think about Vincent's patch ?
[09:43] <tseng> pitti: tracking it down further atm
[09:43] <pitti> tseng: ah, it still does not work now?
[09:43] <tseng> no
[09:43] <tseng> but i found the probable cause
[09:43] <mdz> seb128: I wanted to ping you about #1943
[09:44] <tseng> the last device it looks at before crashing is my ipw2200 on irq11
[09:44] <mdz> seb128: I think we should upload the quick fix that I used now, and then see about cleaning it up right
[09:44] <tseng> im using pci=noacpi because of bug 1254
[09:44] <mdz> seb128: we need to do something for the users whose systems are broken right now
[09:44] <seb128> mdz: ok fine, I've the package ready and tested it the whole day
[09:45] <tseng> when i boot w/o noacpi, hald does not segfault
[09:45] <seb128> just wanted to check with you
[09:45] <mdz> seb128: ok, great, please go ahead and upload
[09:45] <pitti> tseng: thanks for exploring this.
[09:45] <tseng> not sure if it doesnt see the ipw2200 at all, or if it doesnt like being on the other irq
[09:45] <seb128> I've tried to ping you some hours ago, but was just after you left
[09:45] <pitti> tseng: nevertheless hal should not segfault
[09:45] <seb128> mdz: ok
[09:45] <tseng> i should try verbose w/o noacpi
[09:45] <tseng> see if it looks at the ipw
[09:46] <tseng> this seemed to work all fine with 2.6.8.1-2
[09:46] <tseng> iirc
[09:46] <pitti> tseng: do you have the time and skills to debug hal? Or can you let me onto a noncritical machine?
[09:47] <tseng> you can do it on here, nothing very critical
[09:47] <tseng> just dont rm my homework
[09:47] <tseng> lemme grab that key
[09:48] <pitti> tseng: actually I do not want do modify anything (not even install a new package), but I need root to debug hal
[09:48] <tseng> yes thats fine
[09:48] <tseng> im setup in the broken environment now
[09:49] <pitti> tseng: broken env?
[09:49] <tseng> yes, conditions set for a segfault
[09:49] <pitti> tseng: you plugin this card=
[09:49] <pitti> tseng: s/=/?/
[09:50] <tseng> no, if i boot without pci=noacpi, the card does not work (irq conflict) but hald dose
[09:50] <tseng> if i boot with, the card works, hal does not
[09:51] <tseng> let me make a port forward here right quick
[09:51] <pitti> tseng: I have to reboot as well (new kernel), see you in some minutes
[09:52] <tseng> ok
[09:52] <pitti> tseng: brb
[10:20] <mdz> pitti: eek, #2069
[10:20] <mdz> pitti: will you take care of it?
[10:20] <pitti> mdz: I can do
[10:21] <pitti> mdz: BTW, I just got yet another hal segfault
[10:21] <pitti> mdz: sometimes I wish hal was written in python
[10:21] <mdz> yes
[10:27] <pitti> tseng: can you please download http://www.piware.de/hal_0.2.98-1ubuntu6_i386.deb, install it with dpkg -i and check whether hal works now?
[10:27] <tseng> yes
[10:28] <tseng> pitti: the pkg restarted dbus
[10:28] <pitti> tseng: please be aware that hal upgrade will kill gnome-volume-manager (bug #1551), so you need to logout and in if you actually want your devices mounted
[10:28] <tseng> pitti: and hald is running now
[10:28] <pitti> YEEEAAHH!
[10:28] <tseng> hal       6337  4.3  0.7  5480 4096 ?        Ss   16:28   0:00 /usr/sbin/hald --drop-privileges
[10:28] <pitti> tseng: thanks!
[10:28] <tseng> you rock, etc
[10:29] <pitti> tseng: thanks for letting me onto your machine. You should remove my ssh key
[10:29] <tseng> yeah im on it
[10:29] <pitti> tseng: I removed my files (up to the backdoors, of course :-), so you should not need to clean up anything other
[10:29] <tseng> yep.
[10:43] <mdz> heh, mounting with noatime severely confuses mutt
[11:20] <tseng> could someone get rid of that pyramid dude?
[11:20] <tseng> he's ridiculous.
[11:25] <mdz> no sleep last night...a nap is called for