[00:01] <cjwatson> slangasek: wpa_supplicant tries to log to /var/log, and is going to need to log to syslog instead
[00:02] <slangasek> ah yes
[00:29] <calc> http://marc.info/?l=linux-kernel&m=123819275025401&w=2
[00:30] <calc> that post implies our firefox might have issues? since we don't have that option linus mentioned
[00:30] <calc> or at least i don't see it in my about:config
[00:51] <Pollywog> I am getting crashes from Konqueror in Hardy but there are no debugging symbols and no konqueror-dbg  or -dbgsym packages.  Is there something I can do to enable debugging?
[00:56] <Laney> bah, why leave so quickly
[01:42] <TheMuso> calc: BTW you said the other day that you couldn't find the CONFIG_LBD kernel config option. I am guessing you are running amd64, and 64-bit systems don't need that option so far as I understand it, since they are able to handle large block devices natively. 32-bit systems need that option, I'm guessing again because particular code is needed to allow for that support.
[02:19] <calc> TheMuso: ah ok
[03:02] <lamont> I wonder.  how do I get do-release-upgrade -d to _not_ download all the -dbg packages?
[03:08] <ScottK> Uninstall them first?
[03:12] <lamont> they're not installed
[03:12] <lamont> nor are they in the local mirror...
[03:12] <lamont> nor do they show up in /var/log/dist-upgrade/*, they just show up when it bitches that it failed to download them
[03:13]  * lamont smacks it with strace -ff
[03:17] <lamont> is apt actually installing Suggests now? or am I just missing where it's stronger?
[03:21] <lamont> APT::Install-{Suggests,Recommends} "false";  <-- FTMFW
[03:23] <GuyFromHell> so it appears NotifyOSD's wiki page lies, can someone tell me if this is a feature or a bug? if a bug i'll fix the wiki. It appears that replaced_id has to be set as well (in addition to title and coming from same program) for concatenation to work, which is not what "https://wiki.ubuntu.com/NotifyOSD#Concatenating existing bubbles" says
[03:23] <GuyFromHell> pretend i spelled the important parts of that correctly >_>
[03:24] <ScottK> GuyFromHell: #dx or #ayatana are probably better channels to ask as that's where the developers of notify-osd hang out.
[03:24] <GuyFromHell> ScottK, dx and ayatana? random enough names but i'll head on over there...
[03:25] <ScottK> dx is short fo 'desktop experience'.  No idea about the provenence of the other one.
[03:25] <ScottK> fo/for
[03:27] <GuyFromHell> ScottK, I see, lets see if they know anything. In the meantime I'll patch pidgin-libnotify for the hell of it :P
[03:28]  * ScottK declines to give an opinion on that.
[03:29] <calc> anyone around that wants to a few syncs? :) 350070 350071 350072
[03:29] <calc> er want to do a few syncs
[03:29]  * calc needs to proofread his irc messages
[03:32] <calc> robbiew: good evening
[03:32] <robbiew> calc: hi
[03:33] <calc> robbiew: hey i meant to ask you before did you know a guy named Seth Burgess when you went to TAMS?
[03:33] <robbiew> calc: heh...yeah
[03:33] <robbiew> can't match the face right now...but remember the name for sure
[03:34] <DaemonFC> hmm, I did some benchmarking in Jaunty and found that XFS is still beating everything else
[03:34] <DaemonFC> including Ext4 :)
[03:34] <calc> robbiew: he lived in my neighborhood and i went to school with his younger brother at our local Math/Sci magnet school, heh
[03:35] <robbiew> calc: :)
[03:35] <GuyFromHell> DaemonFC, you try btr or r4 in there by any chance? i'm curious :P
[03:35] <robbiew> calc: small world
[03:35] <calc> robbiew: yea, i noticed you went there when looking at your facebook profile a while back
[03:35] <DaemonFC> Ext3/4, ReiserFS, JFS, and XFS in boot time and disk I/O
[03:36] <DaemonFC> XFS ate everything else for breakfast
[03:36] <robbiew> calc: yep...proud class of `94! :P
[03:36]  * calc 's wife is watching mama mia, and is astounded she has never heard ABBA before
[03:36] <calc> robbiew: i graduated in 95 :)
[03:36] <DaemonFC> strangely Ext3 beat Ext4 in disk throughput
[03:36] <DaemonFC> 51 MB/sec for Ext3, and 41 for Ext4
[03:36] <DaemonFC> compared with 57 for XFS
[03:37] <calc> robbiew: so was that equivalent to graduating from HS in 92 or did they have a HS graduation and then the next 2 years for college (i never looked into how that worked)
[03:37] <DaemonFC> Ext4 seems to be a regression in some cases
[03:37] <calc> DaemonFC: it looks like the kernel guys (upstream) are working on getting things working better, see the lkml 2.6.29 several hundred post thread, very funny in places
[03:38] <DaemonFC> GuyFromHell: ReiserFS tied with Ext3 for disk throughput, but took almost twice the time to boot
[03:38] <DaemonFC> due to reiserfsck
[03:38] <robbiew> calc: well..we had a graduation ceremony, but left with around 60 college credits
[03:38] <calc> DaemonFC: last time i used XFS it also ate itself for breakfast :\
[03:38] <GuyFromHell> DaemonFC, and i believe reiser mount time is utter carp in general but i'm sure if you tested only small files it would be the other way ;)
[03:38] <calc> robbiew: ah ok
[03:38] <DaemonFC> calc, that bug was fixed in 2007
[03:38] <DaemonFC> according to eric Sandeen
[03:38] <robbiew> calc: so pretty much like leaving in '92, but we had to take certain courses to meet Texas Education Agency requirements
[03:38] <calc> DaemonFC: yea, still kept me from wanting to try it again :\
[03:38] <calc> robbiew: i see
[03:39] <robbiew> calc: so I ended up with a lot of wasted credits...for a CS degree :P
[03:39] <DaemonFC> http://izanbardprince.wordpress.com/2009/03/28/comparing-boot-performance-of-ext3-ext4-and-xfs-on-ubuntu-jaunty/
[03:39] <robbiew> calc: like pre-med biology....world history...etc
[03:39] <calc> robbiew: wasted credits just makes you more well rounded :)
[03:39] <robbiew> calc: ;)
[03:39] <DaemonFC> http://img135.imageshack.us/img135/5469/reiserboot.png
[03:39] <DaemonFC> notice how Reiser flatlines
[03:39] <DaemonFC> when it gets to reiserfsck
[03:39] <GuyFromHell> DaemonFC, so i'm a bit curious, i thought there was an outstanding bug on XFS not being able to be used for the grub partition
[03:39] <DaemonFC> and then gets going agin after about 10 seconds
[03:39] <DaemonFC> lol
[03:40] <DaemonFC> GuyFromHell: In Ubuntu's setup, yes
[03:40] <DaemonFC> Debian has supported that since Etch
[03:40] <GuyFromHell> DaemonFC, huh, you mean i was using ext2 there for no reason >_>
[03:40] <DaemonFC> I filed a bug on that and it was fixed the same day oddly enough
[03:40] <DaemonFC> in Ubuntu
[03:41] <DaemonFC> right before Jaunty Alpha 5
[03:41] <DaemonFC> about 5-6 days before
[03:41] <DaemonFC> yeah, Debian supports booting on XFS, so does Mandriva, Ubuntu does now
[03:41] <DaemonFC> Suse will complain about it and tell you you need to make a boot disk
[03:42] <DaemonFC> but using xkill on that prompt it goes and isntalls GRUB on the hard disk anyway
[03:42] <GuyFromHell> >_>
[03:42] <DaemonFC> heh
[03:43] <DaemonFC> I like XFS, and I trust that Eric Sandeen knows what he's talking about
[03:43] <GuyFromHell> DaemonFC, you should cover btrfs and reiser4 too if you're still bored :P
[03:43] <DaemonFC> he's the lead file system engineer at Red Hat and before that he worked at SGI on XFS
[03:44] <calc> i'll stick to ext3 until i see progress from the current flame war, it looks like something positive might result from the discussion
[03:44] <DaemonFC> Ubuntu doesn't support either
[03:44] <DaemonFC> or I would have
[03:45] <GuyFromHell> DaemonFC, lol, i don't think anything "supports" either :P
[03:46] <DaemonFC> Fedora does
[03:46] <DaemonFC> BtrFS anyway
[03:46] <DaemonFC> in 11 Alpha
[03:46] <DaemonFC> type icantbelieveitsnotbtr on the installer line
[03:47] <DaemonFC> I tried it and I didn't really like it
[03:47] <GuyFromHell> btr?
[03:47] <DaemonFC> it's really really slow at this point
[03:47] <DaemonFC> yes
[03:47] <GuyFromHell> DaemonFC, it is still like alpha
[03:47] <GuyFromHell> so i mean
[03:47] <GuyFromHell> it's to be slightly expected
[03:48] <DaemonFC> yeah
[03:48] <DaemonFC> that's why I'm not benchmarking it til it's reasonably "there"
[03:48] <DaemonFC> I don't want to drag its name through the mud while it's still pre-alpha
[03:50] <DaemonFC> XFS reads at platter speed on all my stuff
[03:50] <DaemonFC> so I don't think BtrFS is going to improve on it in speed
[03:51] <DaemonFC> That was such a nuisance when Ubuntu was setting up GRUB to be stupid though
[03:52] <ScottK> This really doesn't have a lot to do with actual development of Ubuntu.
[03:52] <DaemonFC> one big reason GRUB didn't used to support XFS is because XFS puts the Superblock at the first sector of the root partition
[03:52] <DaemonFC> and GRUB couldn't deal with that
[03:53] <ScottK> There is #ubuntu-offtopic for general chitchat.
[03:59] <calc> ScottK: is there anything special i need to do for sync requests at this time in the cycle? i pointed to the bug that the three requests help to resolve in their bug reports, wasn't sure if anything else would be needed
[04:00] <ScottK>  calc: Is it a bugfix only change?
[04:01] <calc> ScottK: yea only new debian revisions no new upstream changes
[04:01] <ScottK> calc: Then no, just subscribe the archive as usual.
[04:01] <calc> hmm actually one of the packages is newer than what we have, they are dictionaries though so can't really explode
[04:02] <calc> newer upstream i mean
[04:02] <calc> ScottK: ok
[04:20] <ArneGoetje> nixternal: thanks. approved.
[04:20] <nixternal> ArneGoetje: no, thank you :) very much appreciated!
[04:41] <lamont> \o/  slapd failed to upgrade.  yay slapd
[04:46] <slangasek> lies, slapd never fails to upgrade
[04:46] <lamont> gah.  WTF turned on color in vim?
[04:46] <lamont> slangasek: well, to be fair, there is no slapd.conf.
[04:46] <lamont> OTOH, it would help if the upgrade noticed that it WASN'T RUNNING BEFORE
[04:48] <slangasek> hmm :)
[04:48]  * lamont goes looking to find the magic option to make vim shut up
[04:50] <lamont> there.  "syntax off"
[04:50] <lamont> love.
[04:50] <lamont> I guess one of these days, I should start using vim as vim, instead of as an overly weighted not-quite-the-same nvi
[04:52] <lamont> slangasek: truthfully, one could consider it a bug that if slapd was not running before the dist-upgrade, it shouldn't be started after the dist-upgrade
[04:52]  * lamont can hardly wait to see if  his laptop boots into jaunty
[04:54] <slangasek> lamont: if you don't want the service started, that's what policy-rc.d is for
[04:54] <lamont> meh.  bind and postfix both notice and DTRT
[04:54] <lamont> as the result of bugs filed against tehm
[04:54] <lamont> then again, that was before policy-rc.d
[04:55] <slangasek> no, bind and postfix both notice and do what you want, not TRT :)
[04:55] <slangasek> (well, or what you agreed to do in response to bugs :-)
[04:55] <lamont> well, what the submitter wanted
[04:56] <lamont> so is the login screen _supposed_ to look like 5 vertical blue lines?
[05:04] <lamont> sigh.  inspiron 1520 doesn't like what jaunty is doing to it.
[05:06] <lamont> dear squid.  when I say init.d/squid STOP, I mean really stop, not sit around for 30 seconds before stopping.  kthx
[05:08] <DaemonFC> I got rid of Apparmor out of init, I compiled my own kernel but it was still trying to load the stupid Apparmor module :P
[05:10] <lamont> slangasek: is it known that jaunty doesn't like 00:02.0 VGA compatible controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 0c)
[05:11] <IntuitiveNipple> lamont: That migh be bug #312677
[05:11] <lamont> /usr/bin/X11/X: symbol lookup error: /usr/lib/xorg/modules/extensions//libdri.so: undefined symbol: atiddxAbiDixLookupPrivate
[05:11] <lamont> giving up.
[05:11] <lamont> xinit:  Connection refused (errno 111):  unable to connect to X server
[05:11] <lamont> xinit:  No such process (errno 3):  Server error.
[05:11] <lamont> X optional is what it is
[05:12] <lamont> and then it doesn't want to switch to a VT after that's all done
[05:12] <slangasek> uhm... symbol errors don't sound like a known error
[05:12] <IntuitiveNipple> That's bug #345669
[05:13] <lamont> slangasek: it's current as of beta release (I thought), but has 229MB of dist-upgrade it want's to fetch...
[05:13] <lamont> which, without a working screen, is gonna be more painful
[05:15] <slangasek> lamont: i386 or amd64?
[05:15] <lamont> amd64
[05:15] <slangasek> checking
[05:15] <lamont> wtf
[05:15] <lamont> i386
[05:15] <lamont> well, i686
[05:15] <slangasek> heh, checking that instead then :)
[05:16] <slangasek> lamont: that symbol isn't referenced by the beta version of xserver-xorg-core on i386
[05:16] <slangasek> lamont: so what owns that lib on your system?
[05:16] <lamont> yeah, now that I think about it, the laptop was pretty much the last i386 install I did... haven't gotten up the effort to reinstall it yet
[05:17] <lamont> diversion by xorg-driver-fglrx to: /usr/lib/fglrx/libdri.so.xlibmesa
[05:17]  * lamont fires fglrx
[05:18] <slangasek> that seems like something you don't want on an i386 system, no :)
[05:18] <slangasek> er, s/i386/intel/
[05:18] <slangasek> (i965! that thing!)
[05:20] <lamont> what a cute gdm screen...
[05:20] <lamont> \o/
[05:23] <lamont> and total love, I get my 1680x1050 screen back
[05:26] <lamont> not sure how/why fglrx got dragged in at intrepid, but glad to kill _that_ minor annoyance
[05:27] <lamont> anyway, bed for me.  thanks again slangasek for nudging me in the right direction
[05:28] <slangasek> n/p
[05:28] <slangasek> night :)
[10:27] <mcas> hi is a ubiquity developer here?
[10:57] <cjwatson> mcas: what's the problem? (I'm sort of here.)
[10:57] <mcas> hi cjwatson
[10:57] <mcas> i have ab problem with a bug in ubiquity
[10:58] <mcas> in ubuntu-bugs no one could help me
[10:58] <mcas> so it is about bug https://bugs.launchpad.net/bugs/349173
[11:00] <mcas> i am not quite sure if the buttons are wrong only in german or in english too
[11:01] <mcas> and because the "main" ubiquity bug was fixed yesterday i want to tell you about this problem because i cannot say if the wrong button label is the same problem
[11:04] <cjwatson> mcas: that should be covered by the fix for English buttons
[11:04] <cjwatson> certainly the partition mounting one; the password dialog is a separate bug
[11:05] <mcas> ok
[11:05] <cjwatson> well, if it's a bug at all
[11:06] <cjwatson> the corresponding question in d-i is a boolean question so I agree that that should be Yes/No in ubiquity
[11:07] <mcas> ok
[11:08] <mcas> i ask some guys before filling this bug if they think the buttons are correct ;-)
[11:10] <cjwatson> mcas: I've updated your bug to describe the part not already covered by other bug reports
[11:11] <mcas> thank you cjwatson
[11:12] <cjwatson> ... and fixed, since it's trivial
[11:13] <mcas> thank you :-D
[12:18] <hunger> Is there any known trouble with /tmp getting filled up in jaunty at this time?
[12:19] <hunger> df and du disagree on how full /tmp is here: df says it's 9.9GB and 100%, du says it is 24MB.
[12:44] <stooj> !jaunty
[12:46] <soren> hunger: You probably have files open in there that have been deleted. They still take up space (as reported by df), but are visible on the filesystem (so du can't count them).
[12:46] <soren> Oh, he left.
[12:46] <soren> Bah
[12:46]  * soren does the same
[16:25] <kees> Keybuk: uhm, your bluez-utils preinst is wrong.  :P  preinst isn't run with "configure".  Also -- shouldn't you be checking that the conffile is unmodified?
[16:32] <diverse_izzue> Does somebody with packaging experience have a few minutes to give me a hand - i'd like to build an xserver-xorg-core package with a set of patches applied (bug #283128) and cannot figure out how to do it.
[16:46] <ScottK> diverse_izzue: I'm on my way out the door, so not me.  Generally your odds are better if you ask specific questions, "I tried foo, bar bad thing happened, I'd appreciate a suggestion about what to do next?"
[18:43] <LaserJock> hmm, is Conflicts really appropriate for brasero/nautilus-cd-burner?
[18:50] <savvas> LaserJock: I was wondering about the same thing
[18:51] <LaserJock> I mean, sure you end up with 2 burn-to-disc items in the context menu, but in order to get nautilus-cd-burner back I have to get rid of all of brasero
[18:52] <savvas> LaserJock: I think it's because of bug 317756
[18:53] <ScottK> If it's just both showing up in the menu, that's not what conflicts is for.
[18:53] <savvas> I'm not sure though, it wasn't linked with the bug
[18:54] <pochu> bug 317756
[18:56] <LaserJock> I'm just a bummed as I liked nautilus-cd-burner better for burning .isos, but brasero does a lot more so I don't want to remove it either
[18:59] <crdlb> eh? the only difference I see is that the dialog is slightly different
[19:00] <LaserJock> I've not had very good success with brasero's version
[19:00] <crdlb> ah, you mean the implementation, not the UI?
[19:00] <LaserJock> mostly yes
[19:00] <LaserJock> I can't remember if the nautilus-cd-burner dialog had more options or not
[19:00] <savvas> http://lwn.net/Articles/316015/
[19:01] <LaserJock> I don't have it in front of me for obvious reasons :-)
[19:01] <savvas> "New module decisions for GNOME 2.26"
[19:01] <LaserJock> right
[19:02] <LaserJock> but nautilus-cd-burner is in the archives and in Main even
[19:03] <savvas> "directly conflicts with nautilus-cd-burner feature-wise" < heh
[19:03] <savvas> so I guess there isn't anything that deprecates it, other than the fact that they both serve the same thing :P
[19:04] <savvas> should I file a bug to lift the conflict? or does this mean that nautilus-cd-burner will not be maintained anymore?
[19:05] <LaserJock> well, I see the point of the conflict, it'd just be nice if we had a more elegant solution
[19:05] <LaserJock> it's not exactly the proper use for Conflicts but it does the job I guess
[19:16] <ScottK> LaserJock: I'd suggest if there's no file level conflict it's a policy violation.  If brasero needs to swapped in upgrade, mvo should add logic for that in update-manager.
[19:18] <LaserJock> ScottK: yeah, that seems like a much better way of handling it
[19:19] <ScottK> We did it that was for multiple packages for kubuntu-desktop.
[19:19] <ScottK> was/way
[19:22] <savvas> ScottK: but will nautilus-cd-burner be supported upstream? if not, wouldn't it be better to ask for a package removal? Or is it too early for such action? :\
[19:22] <ScottK> savvas: Generally we let it drop to Universe and stay until it's not supportable.
[19:23] <ScottK> savvas: The idea in Ubuntu is to have one supported way, but let options stay in Universe.
[19:23] <savvas> aaah, ok, I'll file a bug against brasero then :)
[19:23] <ScottK> savvas: Also file a bug against update-manager asking to have them swapped out.
[19:25] <savvas> ScottK: will do!
[19:28] <kees> Keybuk: you around by any chance?  I'm trying to debug a dbus permissions issue with network-manager-pptp
[19:48] <savvas> ScottK: separate bugs or just link it? bug 350523
[22:34] <directhex> hmph. which bit of code would i go digging in if i felt that gnome's mouse sensitivity settings were dim?
[22:36] <directhex> i can only make my mouse controllable if i pull down the DPI setting
[22:36] <directhex> which sorta defeats the idea