[00:23] <pitti> mdke: eww, right, we must strip gnome help files, otherwise we'll install the files in both places; sorry, I'm afraid we need to fix the symlinking instead
[00:23] <pitti> slangasek: ^
[00:23] <PovAddict> does anyone know what other distros use apport, if any?
[00:24] <pitti> PovAddict: OpenSUSE does
[00:25] <slangasek> pitti: does that mean the solution is known and in progress?
[00:26] <pitti> slangasek: not yet, I'm afraid, it basically turned up yesterday
[00:28] <pitti> slangasek: that's the cdbs task on that bug
[00:32] <chrisccoulson> kees - are you interested in working on bug 446395?
[00:32] <chrisccoulson> i'll work on that tomorrow if nobody else has fixed it in the meantime
[00:34] <Notch-1> news about the loop module? still =y?
[00:35] <pitti> mdke: yes, it will need a langpack rebuild to pick up the new gnome help files
[00:35] <pitti> slangasek, mdke: got a DSL reconnect (I really ought to sleep at this time..), did you answer?
[00:35] <pitti> slangasek: hm, the .deb is 450 kB; what do you mean exactly with "baloon"?
[00:36] <slangasek> pitti: apt says upgrading ubuntu-docs here will take up 64MB more space
[00:36] <pitti> mdke: ignore the "we must fix symlinking" bit, I was confused; fdupes is unrelated to translations
[00:36] <pitti> ?!?
[00:37] <PovAddict> wow, 446395 looks serious
[00:37] <slangasek> pitti: installed-size: 169084 vs. 231408
[00:38]  * pitti looks at debdiff ubuntu-docs_9.10.9_all.deb ubuntu-docs_9.10.10_all.deb
[00:38] <slangasek> pitti: hah - something is calculating installed-size *before* pruning files from the tree (!)
[00:38] <slangasek> (AFAICT)
[00:38] <slangasek> hmm, no
[00:39] <pitti> slangasek: it seems the new version replaced all the relative symlinks with absolute ones
[00:39] <slangasek> pitti: which shouldn't change the package size at all, really
[00:39] <pitti> well, slightly
[00:39] <pitti> but certainly not in the MB range
[00:39] <PovAddict> not much after compression
[00:40] <PovAddict> how many symlinks are we talking about?
[00:40] <Notch-1> PovAddict: only if you count on your screensaver for your security, luckly
[00:41] <slangasek> pitti: right, in both cases the installed-size is way overestimated - the actual unpacked size is 17-19MB, the installed-size figures are > 160MB.  I think it's being calculated before the tree is trimmed
[00:41] <pitti> PovAddict: 5270
[00:41] <slangasek> pitti: relative and absolute symlinks should still take up exactly one block on disk, surely?
[00:41] <PovAddict> oh true, blocks... yes, it should take the same space
[00:41] <pitti> slangasek: right; I just purged and reinstalled ubuntu-docs, and df says before/after is a difference of 20.9 MB
[00:41] <PovAddict> unless you have a crazy-long path somewhere
[00:42] <pitti> slangasek: uncompressed yes, just the .deb gets a tad bigger (not much presumably)
[00:42] <slangasek> pitti: right - apt is reporting the installed size
[00:42] <pitti> ok, so I think this is a red herring
[00:42] <slangasek> which shouldn't differ for absolute vs. relative symlinks
[00:42] <slangasek> pitti: yeah; it's a bug in its own right though
[00:42] <slangasek> I'll report it
[00:43]  * pitti -> bed, really this time
[00:43] <slangasek> 'night!
[00:44] <directhex> night pitti!
[01:01] <jdong> directhex: gasp do I see banshee tagged?
[01:05] <slangasek> ArneGoetje, pitti: was language-support-extra-eu meant to be removed from the archive?  (No rdeps, depends on NBS myspell-eu-es)
[01:06] <directhex> jdong, 1.5.1? yes
[01:06] <jdong> directhex: indeed
[01:07] <jdong> directhex: heh a friend and I are now whining over how banshee psychically stole our smart playlist shuffler XD
[01:07] <jdong> directhex: we chose to build a student's t-distribution modeling each song's preference score though ;-)
[01:11] <directhex> jdong, the code in libmono-system-corlib2.0-cil which steals the user's brainwaves also serves to send all user-made extensions upstream silently
[01:12] <jdong> directhex: I KNEW IT! THEYVE BEEN WARNING US FOR YEARS ABOUT THIS!
[01:12]  * jdong registers boycott(2n+1)novell.com
[01:14] <directhex> jdong, you want to boycott boycott-boycottnovell?
[01:15] <jdong> :)
[01:15] <jdong> well the site for n <=2 has been taken, hasn't it? ;-)
[01:17] <directhex> dunno dude, i'm just a packager
[01:49] <ArneGoetje> slangasek: all language-support-extra-* packages got removed from the archive. Instead of myspell-eu-es, hunspell-eu-es gets installed with the language-support-writing-eu package.
[01:49] <slangasek> ArneGoetje: well, language-support-extra-eu didn't get removed :)
[01:50] <slangasek> ArneGoetje: is there a bug # I can reference for a removal request?
[01:50] <spotter> anyone having trouble upgrading gdm?  failing in configure scripts
[01:51] <slangasek> ArneGoetje: in fact, I see 11 language-support-extra-* in karmic presently
[01:51] <ArneGoetje> slangasek: eh? I thought pitti removed them already...
[01:53] <slangasek> ArneGoetje: apparently not - could I ask you to file a quick bug report requesting their removal and explaining (briefly) why they should go away, and I can knock them out of the archive?
[01:53] <ArneGoetje> slangasek: ok
[01:53] <ArneGoetje> slangasek: against "ubuntu"?
[01:54] <slangasek> ArneGoetje: against one of the source packages
[01:54] <ArneGoetje> slangasek: ok
[01:55] <spotter> nm, figured it out.  gdm doesn't like being upgraded as root
[01:55] <spotter> needs to be done as sudo'd user
[01:57] <slangasek> spotter: um
[01:58] <slangasek> spotter: that's not something gdm is entitled to have an opinion on; could you please file a bug report (with error messages)?
[01:59] <chrisccoulson> the GDM upgrade issue is already reported isn't it? (the failures due to the su calls in the postinst script)
[01:59] <slangasek> ah, ok
[01:59] <spotter> slangasek, bugs already filed
[01:59] <slangasek> (is the bug targeted to karmic?)
[01:59] <spotter> not by me
[01:59] <spotter> by many others
[01:59] <spotter> I just commented on one
[01:59] <chrisccoulson> slangasek - yeah, that's the one
[02:00] <spotter> its been this way for a few weeks
[02:00] <spotter> been ignoring it as had other things, and laptop still worked
[02:00] <slangasek> what bug?
[02:00] <spotter> here's the bug I commented on https://bugs.launchpad.net/bugs/438789
[02:00] <spotter> might be a duplicate of others
[02:01] <chrisccoulson> that's a slightly different issue but it's the same root cause
[02:01] <slangasek> ah; looks like that should be marked as a duplicate of 438561?
[02:01] <chrisccoulson> the stuff in the postinst script causes a gvfs daemon to be spawned in the GDM session
[02:02] <chrisccoulson> slangasek - yeah, you're right
[02:02] <slangasek> ok
[02:02] <slangasek> thanks for confirming :)
[02:02] <chrisccoulson> i need to speak to seb128 tomorrow and see what he wants to do with this one
[02:03] <chrisccoulson> i've got an idea for fixing it but it involves a non-trivial patch to g-s-d
[02:04] <spotter> btw, I didn' (and don't currently) have a .gvfs file in my /var/lib/gdm directory
[02:04] <spotter> nto before it refused to configure and not after I got it configured w/ sudo
[02:05] <chrisccoulson> spotter - it's still most likely a related issue. the su calls seem to cause multiple problems at the moment
[02:07] <spotter> ok
[02:10] <ArneGoetje> slangasek: https://bugs.edge.launchpad.net/ubuntu/+source/language-support-extra-de/+bug/451802
[02:22] <slangasek> ArneGoetje: thanks!
[02:42] <zul> slangasek: i think m2crypto is ok without the testsuite enabled
[04:09] <ArneGoetje> cjwatson: seems the installer still doesn't know about the Chinese package split... it still installs the -zh metapackages, instead of only -zh-hans or -zh-hant for Simplified and Traditional Chinese respectively. Against which package should I file the bug? pkgsel?
[04:26] <ArneGoetje> cjwatson: ah, ok. the latest daily Live CD doesn't have the latest ubiquity and language-selector yet... updating and retry...
[04:26]  * hyperair notes the wonderful clicking sounds his soundcard makes when resuming from powersave
[04:29] <slangasek> zul: well, that's for the MIR team to say
[04:31]  * hyperair pokes dtchen 
[05:05] <LaserJock> cjwatson: good news! The Edubuntu DVD seems to be working again! Thanks so much, you rock
[05:22] <hyperair> does root-on-dmcrypt result in the root partition not being unmounted properly?
[05:24] <hyperair> oh great, now my /etc/init/gdm.conf went missing. wtf?
[05:25] <hyperair> lolwut now encoding problems
[05:25] <hyperair> win
[05:35] <TheMuso> hyperair: gdm.conf is no longer used
[05:35] <hyperair> i meant /etc/init/gdm.conf
[05:40] <TheMuso> oh
[05:40] <hyperair> ext4's driving me up the wall
[05:40] <hyperair> even after a clean reboot, fsck complained endlessly about all kinds of things, and whacked up /var/lib/dpkg
[05:41] <hyperair> ugh
[05:43] <jdong> gasp ext4 loses tons and tons of data in the writeback cache? :)
[05:46] <hyperair> jdong: why, is it a known issue?
[05:46] <hyperair> well i could probably blame myself for running an rc kernel, but i didn't think things would get *this* bad with a filesystem that's supposedly stable
[05:51] <slangasek> TheMuso: ubuntustudio-desktop depends on gstreamer0.10-schroedinger, but that package is NBS (and I'm removing it) - can you update ubuntustudio-meta?
[05:56] <ScottK> slangasek: IIRC it moved to a different gstreamer package and we didn't sync the one it moved to.
[05:57]  * ScottK recalls no details though.
[05:57] <TheMuso> slangasek: RIghto thanks
[05:57] <slangasek> ScottK: hmm, looking
[05:58] <ScottK> It's also 1AM here and I'm very tired.  I could be totally full of crap.
[05:58] <ScottK> Just so you're warned.
[05:59]  * TheMuso waits to see if further updates are necessary
[06:00] <slangasek> ScottK: right, confirmed; the changelog said it moved to -bad, and I took it at face value
[06:01] <slangasek> TheMuso: ^^ so please hold off wrt uploading, at least
[06:02] <TheMuso> slangasek: Right, I agree, since I have bad installed and /usr/lib/gstreamer-0.10/libgstschro.so is not in bad
[06:02]  * slangasek nods
[06:02] <hyperair> where does upstart's umount code go?
[06:02] <hyperair> or does it not unmount filesystems at all?
[06:03] <slangasek> hyperair: scripts are still in /etc/rc[06].d/
[06:03] <hyperair> ah i see
[06:05] <slangasek> ScottK: has anyone taken a position wrt the right way to fix this for karmic, that you're aware of?
[06:06] <slangasek> I see bug #436350
[06:06] <ScottK> slangasek: Not that I know of.
[06:06] <slangasek> and I don't see slomo on IRC :/
[06:24] <TheMuso> slangasek: ok meta is ready fr upload, waiting for your call in the event something needs changing
[06:26] <slangasek> TheMuso: ok; everything I see here currently tells me we should drop the dep from the meta packages and pull in a new upstream version of plugins-bad, because the current upstream version of schroedinger doesn't even have the plugin in the source anymore
[06:26] <slangasek> TheMuso: I would advise you to go ahead with uploading
[06:27] <TheMuso> slangasek: ok
[06:34] <hyperair> slangasek: you're wanted.
[06:34] <hyperair> er whoops
[06:34] <hyperair> slomo:
[06:34] <slangasek> works well enough, though ;)
[06:34] <hyperair> haha
[06:35] <slangasek> slomo: hi, you seem to have synced the new upstream version of schroedinger which drops the gst plugin, but there doesn't seem to be any work done on getting the new upstream version of gst-plugins-bad in that takes it over?
[06:39] <hyperair> hmm it seems that banshee hasn't been seeing karma support for quite some time
[06:42] <slomo> slangasek: blame seb128, i asked him to sync gst-plugins-bad0.10 0.10.14 more than a month ago :) unfortunately i didn't notice that he forgot to do it
[06:42] <slomo> slangasek: sorry
[06:45] <hyperair> what was the tool used to do reverse build dep?
[06:46] <maco> hyperair: apt-cache rdepends?
[06:46] <hyperair> that's r *binary* dep
[06:46] <slomo> hyperair: grep-dctrl on apt's Sources files
[06:46] <hyperair> i'd like reverse build-dep
[06:46] <maco> ah ok
[06:46] <hyperair> slomo: ah right thanks
[06:47] <slomo> hyperair: good work on updating banshee btw :) does it already use the external hyena?
[06:47] <hyperair> hmm so it seems libkarma-cil only has one reverse build-dep
[06:47] <hyperair> slomo: no it doesn't. that's still stuck in binary new
[06:48] <hyperair> slomo: also, i don't see anything in the build system that looks for hyena
[06:48] <hyperair> so i guess not
[06:49] <ScottK> hyperair: reverse-build-depends script in ubuntu-dev-tools wraps grep-dctrl and makes it easy.
[06:50] <hyperair> ah cool
[06:50] <hyperair> thanks
[07:00] <mdke> slangasek: sorry, I don't know what has caused that, the deb is the same size
[07:02] <hyperair> whose brilliant idea was it to make https://launchpad.net/ubuntu/+source/<pkg>/+filebug point to a wiki page instead?
[07:02] <hyperair> >=(
[07:02] <hyperair> i know what information i want to include and don't need apport damnit
[07:02]  * hyperair grumbles
[07:06] <ScottK> hyperair: #ubuntu-bugs is the best place to provide feedback on that decision.
[07:07] <hyperair> alright, i'll do that when i figure which channel to leave
[07:19] <cjwatson> ArneGoetje: probably a bug with tasks on pkgsel and ubiquity, yes; although I'm afraid we may not have time to get that dealt with this cycle
[07:48] <spaetz_> shite, my firefox-3.5 crashes 100% on start now, even when removing the profile directory....
[07:48] <spaetz_> amd64
[07:49] <spaetz_> asac: you signed of the latest release a couple of hours ago. Can that be related?
[07:54] <spaetz_> reboot helped with the firefox crash issue, sorry for bothering
[07:57] <dholbach> good morning
[08:20] <slangasek> slomo: ah - ok, I'm following up on bug #436350, then
[08:20] <slangasek> mdke: bug #451764 filed, with analysis
[08:52] <simon-o> Hobbsee: What do you think about bug 359934? Is this ok with you and can we get this into karmic?
[08:57] <seb128> doh
[08:57] <seb128> slangasek already froze the archive
[08:57] <seb128> I was expecting an extra day to get work done ;-)
[08:57] <slangasek> seb128: I work European hours on Thursdays now ;)
[08:58] <seb128> slangasek, still I was expecting freeze at the end of the day
[08:58] <dholbach> seb128: I'll mail the press letting them know that we'll delay by a day, so we can get more new gnome crack!
[08:58] <slangasek> heh
[08:59]  * dholbach hugs seb128
[08:59] <seb128> dholbach, we plan to get GNOME 2.28.1 anyway as every cycle ;-)
[08:59]  * seb128 hugs dholbach
[08:59] <seb128> which is on monday next week
[08:59] <dholbach> seb128: if you need help with sponsoring, let me know
[08:59] <seb128> dholbach, would be nice thanks!
[08:59] <dholbach> can't let my old desktop buddy down :)
[09:03] <seb128> ;-)
[09:03] <Hobbsee> simon-o: ie, reverting version 29?  This seems to be a policy decision that keeps switching, which is why i've been trying to ignore it.  mvo:  your thoughts?
[09:04] <slangasek> mvo: 451428> hrm, that's not a bug in grub, that's a bug in whatever called grub to be installed...
[09:06] <mvo> slangasek: so you think he is installing kernels from some location that is not ubuntu?
[09:06] <simon-o> Hobbsee, mvo: Yes it is. Right now the java plugin is installed on amd64 but not on i386 which is inconsistent. I would like to keep the plugin in u-r-e until the open source plugin is stable.
[09:06] <slangasek> mvo: no, I think something removed grub-pc from his system and replaced it with grub on upgrade
[09:07] <mvo> simon-o: it seems like pitt did this change in 29
[09:09] <mvo> slangasek: aha, I misread the bug then, that makes sense. I will ask for more info
[09:09] <slangasek> mvo: already done, just wanted to get a heads-up since you see these bugs before I do
[09:09] <simon-o> mvo, pitti: yes he did. But it seems like icedtea6-plugin isn't stable enough yet, what do you think pitti?
[09:09] <slangasek> s/get a/give you a/
[09:09] <mvo> slangasek: I had one report about a jaunty grub2 being removed on upgrade, but was not able to reproduce yet as my VM did not boot with grub2 in jaunty
[09:09] <mvo> slangasek: thanks
[09:10] <slangasek> right; there've been a few reports from people saying grub-pc went away in favor of grub, I /think/ these are all actually fallout from old (fixed) bugs but am chasing them up to be sure
[09:21] <cjwatson> slangasek: of course there are still some cases where we need to use grub rather than grub2, e.g. dmraid
[09:21] <slangasek> cjwatson: sure - those aren't the people that have been filing bugs, though :)
[09:34] <pitti> Good morning
[09:35] <\sh> moins pitti
[09:35] <pitti> ArneGoetje, slangasek: hm, I wasn't aware of -extra; I just removed language-support-translations*
[09:35] <chrisccoulson> good morning pitti
[09:35] <slangasek> pitti: ah - well, they're knocked out now
[09:36] <pitti> good, thanks
[09:36] <pitti> simon-o: icedea-plugin? what?
[09:40] <simon-o> pitti: sorry, I didn't provide any context. We were talking about bug 359934 and if u-r-e should contain sun-java6-plugin or not (currently this is the case on amd64 but not on i386). icedea-plugin is maybe not stable enough to replace the sun plugin
[09:45] <pitti> simon-o: hm, I'm afraid I have no idea how stable it is; but given that we're about to remove sun-java6, I'd rather point people to openjdk TBH
[09:45] <pitti> doko might have a better opinion
[09:49] <simon-o> pitti: I think the wish to include the sun plugin came because of bug 344705
[09:50] <mvo> Keybuk: could you please give me a hand with bug #451556 ?
[09:50] <mvo> Keybuk: it seems to be upstart releated
[10:01] <ArneGoetje> cjwatson: ok...
[10:02] <ArneGoetje> cjwatson: BTW: Evan's libwebkit-1.0-2 fixes the crash issue for me.
[10:03] <evand> ArneGoetje: can you post a comment to that effect on 451980?
[10:04] <ArneGoetje> evand: ah, you are online... :) yes, I will post a comment
[10:05] <evand> ArneGoetje: thanks!
[10:08] <evand> pitti: is the fact that bug 401381 didn't pick up the core dumps for grub a bug in apport, or more fundamental to how apport works?  If it's the latter, do you see any use for rules that say something like, "if ubiquity crashed, and the following processes also have crash dumps, include them in ubiquity's crash report"?
[10:09] <evand> (the grub crash appears near the bottom of the syslog)
[10:24] <pitti> evand: that bug is against ubiquity with a python traceback; I don't quite understand why it should have a core dump?
[10:24] <evand> Jul 19 13:00:50 ubuntu grub-installer: Floating point exception (core dumped)
[10:24] <evand> Jul 19 13:00:56 ubuntu last message repeated 4 times
[10:25] <evand> (from UbiquitySyslog)
[10:25] <pitti> evand: well, of course the package hook could do some magic to pick up the related .crash reports, but if you just attach them you wouldn't get auto-duplication and retracing
[10:26] <pitti> evand: the .grub crash ideally gets submitted to LP separately, and gets retracing/duplication love
[10:30] <evand> Perhaps it could offer to file both at once (so there's a greater chance the user will actually do it), and link the two together with a comment?
[10:30] <pitti> evand: FYI, just updated bug 451263; unblocked now
[10:30] <evand> hooray
[10:30] <pitti> evand: would be nice indeed; unfortunately right now we have no control about the actual filing process in the browser;
[10:31] <evand> pitti: ah, unfortunate. Do you want a wishlist bug for this anyway?
[10:32] <pitti> evand: sure; don't hold your breath for it, though, it requires large changes, also in LP (be able to file bugs through launchpadlib, replicate the bug filing interface in GTK/KDE, etc.)
[10:32] <pitti> and looking for duplicates, etc.
[10:34] <evand> understood
[10:44] <slangasek> bryce_: something strange in the diff of your latest -evdev upload; a patch to configure.ac to make it think it's 2.2.2 instead of 2.2.5? (+ some undocumented source changes)
[10:45] <slangasek> bryce_: I'm looking at this to fix the FTBFS, but the other stuff looks notable
[10:45] <bryce_> slangasek, hrm, I'll doublecheck
[10:46] <bryce_> hmm, didn't show up in my debdiff
[10:49] <slangasek> bryce_: well, somehow you also skipped -1ubuntu3 (or rather, seem to have renumbered -1ubuntu2 to be -1ubuntu3 (!)), the previous upload was -1ubuntu2 - all very confusing
[10:49] <slangasek> uploading -1ubuntu4 in the meantime for the build fix
[10:50] <bryce_> oh crap, I know what I did
[10:51] <bryce_> slangasek, let me do the -1ubuntu4 if you've not done it already
[10:51] <slangasek> bryce_: ok, go ahead
[10:54] <tseliot> slangasek: can I upload a fix for nvidia-common (bug #292606)? It should fix a rather nasty problem with dist-upgrades
[10:54] <slangasek> tseliot: yes, no need to ask before uploading :)
[10:55] <tseliot> slangasek: ok, thanks
[10:56] <bryce_> slangasek, can I re-upload fixed -1ubuntu4 or does it need to be -1ubuntu5?
[10:56] <slangasek> bryce_: I haven't uploaded a -1ubuntu4 yet, just use that number
[11:00] <lool> slangasek: I just pushed a new partman-uboot to fix the initial implementation of the mkfs.ext2 call in there; Marvell had told me in the past that -I 128 should be used (not -b 4096), and they just confirmed in https://bugs.launchpad.net/bugs/450906
[11:01] <bryce_> slangasek, fixed package uploaded
[11:04] <slangasek> bryce_: cheers
[11:04] <slangasek> lool: will see it as I process the queue, I'm sure :)
[11:06] <lool> slangasek: Oh yeah sorry; I guess you should poke if you have any question rather than me poking you whenever I upload, sorry
[11:07] <slangasek> lool: no worries, and if you have anything that's you need pushed through the queue urgently, just shout
[11:08] <lool> Ok I dont
[11:08] <lool> Thanks
[11:08] <bryce_> slangasek, I got an error trying to upload -1ubuntu4
[11:09] <slangasek> oh?
[11:09] <slangasek> er, wait
[11:09] <dholbach> lool: where is mutter-moblin? is it still sitting in some queue?
[11:09] <dholbach> lool: the other sync requests build-depend on libmoblin-applet-dev or whatever it's called
[11:09] <slangasek> bryce_: sorry, -1ubuntu4 was the one you already uploaded?  Sorry, I was talking nonsense when I told you to reuse that number
[11:09] <bryce_> ahh ok
[11:10] <slangasek> bryce_: -1ubuntu4 was already in the archive, so you have to increment; was getting my wires crossed
[11:10] <bryce_> slangasek, ok -1ubuntu5 uploaded
[11:13] <slangasek> bryce_: thanks
[11:30] <lool> dholbach: mutter-moblin is in Debian; I thought paulliu would request a sync for it
[11:31] <lool> paulliu: Hey ^
[11:31] <dholbach> oh, I thought it was sitting in some queue already
[11:39] <dholbach> paulliu: usr/share/mutter-moblin/theme/moblin-panel-myzone is empty (not sure if that's empty) and src/mnb-scale-group.* are LGPL-2 (not sure if that's an upstream oversight)
[11:39] <dholbach> other than that the package looks good to go
[11:39] <lool> I need some help with brainstorm
[11:39] <dholbach> lool: ^
[11:39] <lool> dholbach: thanks for the review
[11:40] <dholbach> no worries
[11:40] <lool> I updated http://brainstorm.ubuntu.com/idea/21684/ but would like to subscribe to it
[11:40] <lool> Also, I'm not sure of the good way to link a brainstorm idea with a bug report
[11:40] <lool> I just put a link in the solution description which is not ideal
[11:40] <dholbach> lool: jcastro will know, but he's not awake yet, I guess
[11:41] <lool> dholbach: thanks
[11:41] <dholbach> and ndeschildre does not seem to be around either
[11:45] <ogra> Keybuk, moo ...
[11:47] <ogra> Keybuk, why did you move the framebuffer hack in usplash into the C code ? i would like to change the script to use fb1 instead of fb0 (my external monitor with way higher resolution) moving the code into C means i need to recompile the whole thing
[12:07] <lool> ogra: i dont think the language of the implementation should matter; the issue is rather with usplash not handling multiple screens which is well known
[12:08] <sladen> lool: urm.  you're supporting the hardcoding of configuration options?  (!)
[12:09] <sladen> lool: hardcoding a setting that might need changing is different from simply ensuring it has a good default
[12:10] <lool> sladen: fb0 was not configurable either
[12:10] <ogra> it was just easier to change in the shellscript ... it wasnt meant to be configurable at all though
[12:11] <lool> sladen: ogra's critic was that he couldn't update the /usr/share/initramfs-tools script to set fb1 easily as a hack to workaround usplash picking the wrong res
[12:11] <lool> The real bug is usplash handling of multiple screen
[12:11] <ogra> indeed
[12:11] <ogra> well, deeper even i guess
[12:11] <lool> In fact we shouldn't be reading the size from /sys but just let bogl figure out the best size
[12:11] <ogra> the kernel seems to pick the res for my laptop LCD in kms
[12:11] <lool> But that's orthogonal to fb0 versus fb1
[12:12] <ogra> instead of using the external one
[12:14] <cjwatson> putting it in C code let us simplify the upstart job quite a bit
[12:14] <cjwatson> if it needs to be configurable for now, have the C code read it from usplash.conf
[12:16]  * sladen blantently assumed the script in question was under /etc already
[12:18] <ogra> cjwatson, it doesnt need to
[12:18] <slangasek> tseliot: I don't understand why in nvidia-common you aren't just making sure the stdin/stdout of the nvidia-detector call are on clean fds?
[12:25] <slangasek> mvo: should bug #432819 be un-targeted as well as un-milestoned, or do you consider this a candidate for SRU?
[12:27] <slangasek> mvo: could you also comment on bug #434173?
[12:56] <tseliot> slangasek: cleans fds such as?
[12:56] <tseliot> s/cleans/clean/
[12:58] <slangasek> tseliot: use shell redirection to control what goes in and out of the process?
[12:59] <ttx> kirkland: around ?
[12:59] <paulliu> dholbach: hmm. I'll upload a new package for those changes.
[13:00] <ttx> kirkland: committed a euca -0ubuntu3 with a hotfix for the wrong IP issue and the web UI changes from Gustavo. I waited for the CD spin to go with the euca_rootwrap change so that it can be tested independantly
[13:01] <pitti> ogra: do you get pulsating ubuntu logo on livefs boot now? it works for me now
[13:01] <ttx> but the wrong IP issue was a pita that needed to be avoided asap and the ui changes had to go in urgently
[13:02] <ogra> pitti, i havent tested live images since a while
[13:02] <tseliot> slangasek: patches are welcome ;)
[13:02] <mvo> slangasek: 432819> the alwaysOnTop should be removed for karmic. I don't think it can be done in a way suitable for a sru
[13:02] <mvo> slangasek: I have a look at the language-selector one now (I have to add that l-s is no longer officially my baby)
[13:02] <pitti> ogra: would be nice to confirm
[13:03] <slangasek> tseliot: shall I reject the upload in the queue, and put together a patch?
[13:03] <ogra> pitti, will do once the board is available (it's busy atm)
[13:03] <tseliot> slangasek: with my solution I made sure that things don't crash in any case
[13:04] <tseliot> slangasek: so, please accept it and if you have the time to work on a patch, I'll be glad to review it
[13:04] <slangasek> mvo: the language-selector bug has a task open on update-manager, and cjwatson commented in the report that ArneGoetje should talk to you
[13:05] <ttx> kirkland: note that the wrong IP hotfix doesn't address the question of "adding a linklocal address confuses ifconfig" which needs to be discussed more.
[13:07] <Riddell> mvo: do you have any observations on bug 452090 ?  davmor2 failed to upgrade from hardy
[13:09] <mvo> Riddell: I just commented on it
[13:10] <Riddell> mvo: hum, anything that can be done about it?
[13:12] <mvo> Riddell: not sure, was this a stock kubuntu hardy setup?
[13:12] <Riddell> mvo: I expect so, davmor2?
[13:12]  * mvo tests in a VM
[13:14] <pitti> tkamppeter: ah, the buildd hostname fix is being worked on
[13:26] <tkamppeter> pitti, I got this mail from slangasek, too.
[13:26] <tkamppeter> So probably we can upload 1.4.1-8 today and it will get built.
[13:27] <tkamppeter> pitti: It is unusual for a package investigating the build server (reading IP, searching for printers and available PPDs, ...) during build.
[13:29] <slangasek> tseliot: I'm looking at this nvidia-common bug report and the changes, and I don't see how this could ever work... the script you're calling this from is invoking debconf, which means stdout of this script is *always* attached to the debconf frontend - flushing output doesn't help anything?
[13:32] <tseliot> slangasek: I can't reproduce the problem here. The script won't crash though, which is a big win.
[13:33] <tseliot> slangasek: if the script gets garbage instead of the proper output it won't give it to debconf as a reply
[13:38] <davmor2> mvo: yup
[13:39] <slangasek> tseliot: I really can't figure out why you've gone with this solution, or which fd it is you think has the garbage on it (which is generally confusing enough when debconf is involved...)
[13:39] <davmor2> mvo: stock + proposed for the adept update
[13:39] <slangasek> tseliot: why should nvidia-detector ever need to be run in a loop?
[13:40] <davmor2> mvo: sorry forgot + updates
[13:40] <slangasek> tseliot: nvidia-detector doesn't appear to read from stdin; if it did, you could work around this with LATEST=$(nvidia-detector < /dev/null); and the stdout of nvidia-detector is already being captured
[13:42] <tseliot> slangasek: if all goes well, it is called once, otherwise try again and, if this goes wrong, just give up
[13:42] <slangasek> yes, why do you think it should *ever* need to be called more than once?
[13:42] <tseliot> slangasek: no, it doesn't read from stdin
[13:42] <slangasek> this doesn't seem to have anything to do with the bug=
[13:43] <slangasek> I'm not going to accept something I don't understand during final freeze...
[13:45] <tseliot> slangasek: as you can see in the bug report, it can happen that my script doesn't get the output of nvidia-detector because dkms leaves something like " * Running DKMS auto installation service for kernel 2.6.27.2" on stdout
[13:46] <tseliot> and LATEST will be assigned that value
[13:46] <slangasek> tseliot: eh, I don't see that at all from the bug report, or from the code
[13:46] <tseliot> slangasek: https://bugs.launchpad.net/ubuntu/+source/nvidia-common/+bug/292606/comments/4
[13:47] <tseliot> slangasek: what I know for sure is that nvidia-detector can give print "nvidia-glx-$VER" or "none"
[13:47] <slangasek> tseliot: that shows the bufferred stdin being sent *to debconf*, not preventing reading the correct output from nivdia-detector
[13:49] <tseliot> slangasek: how?
[13:50] <tseliot> that's the point
[13:52] <slangasek> tseliot: the parent process has already started the debconf frontend before calling this script; it looks like the garbage has already been sent to the debconf frontend before the nvidia-common script has ever been called, and nvidia-common is just the first process to read back the resulting error code from the pipe
[13:52] <slangasek> (i.e., I agree with Mike Stroyan's analysis in the bug)
[13:52] <cjwatson> oh, yes, this is like malloc debugging
[13:52] <cjwatson> it's often the next thing along that gets to encounter the problem
[13:54] <tseliot> slangasek: ok, so are you suggesting that I simply prevent the script from failing without trying again?
[13:55] <tseliot> or do you have a different solution in mind?
[13:55] <slangasek> tseliot: yes - and that the way to do this is by fixing dkms, not nvidia-common
[13:56] <slangasek> what's starting debconf, though?
[13:56] <tseliot> slangasek: ouch, again. superm1 has a few objections though (to fixing that in dkms) and this is why I tried to deal with the problem in nvidia-common
[13:56] <cjwatson> kernel postinst?
[13:56] <slangasek> cjwatson: not that I see
[13:56] <tseliot> yep ^^
[13:57] <cjwatson> hmm, it used to I think, obviously no longer
[13:57] <tseliot> /etc/kernel/postinst.d/
[13:57] <cjwatson> 2.6.27.7-k8 though, that's kind of old
[13:57] <cjwatson> and looks custom
[13:57] <tseliot> nvidia-common installs the script there
[13:58] <tseliot> this is meant to help users who dist-upgrade with apt from the command line
[13:58] <tseliot> as Update Manager already uses nvidia-common to get rid of obsolete drivers
[13:59] <cjwatson> kernel image packages generated using make-kpkg still load the debconf confmodule in the postinst
[13:59] <slangasek> right
[14:00] <slangasek> so kernel postinst starts the frontend, dkms inherits the fd and throws garbage at it, nvidia-common catches it
[14:00] <tseliot> yes, it could be
[14:01] <cjwatson> and while Ubuntu images of that same vintage apparently didn't, /etc/kernel/postinst.d/ in general probably has to assume that stdout might be debconf
[14:01] <slangasek> so this is a dkms bug, and superm1 will just have to accept that :)
[14:03] <davmor2> mvo: I've commented on the bug as to what I had done.
[14:03] <tseliot> slangasek: ok, so in the mean time I'll modify nvidia-common so that it's capable of detecting garbage but doesn't call nvidia-detector more than once. Right?
[14:04] <slangasek> tseliot: that sounds better to me, yes - how are you going to detect the garbage?
[14:04] <tseliot> i.e. I'll get rid of the while loop
[14:05] <mvo> davmor2: thanks, I have a look
[14:05] <slangasek> cjwatson: won't this garbage cause all subsequent debconf transactions to be out-of-step, unless you know exactly how many lines to read back from the confmodule?
[14:05] <mvo> davmor2: I had it running in my auto-upgrade testing setup and it seems to be doing fine there, but it might have a slightly different setup
[14:06] <davmor2> mvo: I'll start it back up from fresh.  I'm wondering if it pulled in something else from proposed that it should of so I'll double check
[14:07] <cjwatson> slangasek: yes
[14:07] <cjwatson> the solution to garbage on debconf's input is *not to send it there in the first place*
[14:07] <cjwatson> there's no reliable way to recover
[14:07] <slangasek> tseliot: ^^ so basically, once dkms has broken things, you cannot reliably recover and ensure you get correct behavior out of the debconf commands
[14:07] <slangasek> so I wouldn't even try - this should get fixed in dkms
[14:08] <tseliot> slangasek: I know that nvidia-detector can print either "nvidia-glx-$VER" or "none". So if VER=${1#nvidia-glx-*} isn't either only made up of digits or "none" then I know that something went wrong. Furthermore I DKMS print strings which begin with "*" hence this shoul help a bit too: VER=${VER%\**}.
[14:08] <slangasek> tseliot: no, because *that's not where you'll be seeing the error*
[14:08] <cjwatson> dkms is sending those strings to debconf, not to you
[14:09] <cjwatson> as I understand it
[14:09] <mvo> Riddell: I'm just looking at a apturl kde issue and get "from PyKDE4.kdeui import *" -> "ImportError: No module named PyKDE4.kdeui" ? I assume this works fine for you? any idea what python package or lib is missing that makes it fail?
[14:09] <slangasek> tseliot: nvidia-common will abort before you ever get around to calling nvidia-detector
[14:09] <tseliot> cjwatson: I think we all agree on what "the solution" is :-)
[14:09] <cjwatson> debconf is entitled to respond to out-of-spec input basically any way it pleases
[14:09] <slangasek> tseliot: it will abort with the first db_set call
[14:09] <tseliot> cjwatson: I give debconf the reply with this, no? db_subst nvidia-common/obsolete-driver latest $LATEST
[14:10] <tseliot> well, it's not entirely correct
[14:10] <cjwatson> tseliot: once debconf's input is out of step with its output, all bets are off
[14:10] <slangasek> tseliot: your debconf input and output streams are already out of sync by that point because of the extra output dkms has helpfully inserted
[14:10] <cjwatson> you'll be getting the return from some previous thing each time you call db_*
[14:10] <tseliot> :-/
[14:10] <cjwatson> at best
[14:11] <lool> ENODOKO
[14:11] <slangasek> tseliot: so I'm going ahead and rejecting this nvidia-common upload, since it doesn't actually fix the real problem
[14:11] <tseliot> cjwatson, slangasek: ok, so you're basically saying that there may be nothing I can do about it
[14:11] <slangasek> (in fact, users who are running custom kernels would still get the abort)
[14:12] <cjwatson> tseliot: as the problem has been described to me, I don't think there is, no
[14:12] <tseliot> if so, then ok, reject the upload
[14:13] <cjwatson> BTW I think the reason this breaks is partly due to an infelicity in the way that the perl and shell confmodules differ
[14:13] <tseliot> cjwatson, slangasek: some users reported that this works: http://launchpadlibrarian.net/27310838/dkms.patch
[14:13] <cjwatson> I don't think they were ever designed to be nested in this way
[14:14] <tseliot> oh
[14:15] <slangasek> cjwatson: right, the perl client only redirects fds if the shell client is called first, heh
[14:15] <cjwatson> tseliot: if updated to a current version, I think that ought to work
[14:15] <mterry_> Keybuk, have you been getting bugs that look like a bunch of postinst failures with "Failed to connect to socket /com/ubuntu/upstart: Connection refused" messages?  I just got a couple for rsyslog, but I note from their apt logs that lots of packages were generating them.  I didn't see a likely master bug against upstart just now.
[14:15] <slangasek> mterry_: in a chroot?
[14:15] <cjwatson> though counterintuitively, sourcing the shell confmodule in /etc/kernel/postinst.d/dkms might also do it :-)
[14:15] <mvo> mterry_: I see something similar in #451556
[14:15] <cjwatson> but I haven't tested that, and it's possible it won't - the fd redirections are kind of twisty here
[14:15] <mvo> my theory is that the telinit -u removal causes it
[14:15] <mterry_> slangasek, dunno.  reporters didn't say
[14:15] <mvo> but I need Keybuk to confirm
[14:16] <slangasek> mterry_: there was a master bug about that, Keybuk closed it as invalid: bug #430224
[14:16] <mvo> I'm pretty sure it happens on real systems too
[14:16] <slangasek> ok
[14:16] <mvo> (I get it in my auto-upgrade test VM and I'm sure it was not there some days ago)
[14:16] <slangasek> cjwatson: yeah, sourcing the confmodule would do it.. :)
[14:17] <mterry_> slangasek, interesting
[14:18] <cjwatson> of course sourcing the confmodule, if it does anything, merely does 1>&2, so you might as well just do that directly
[14:19] <tseliot> ah
[14:20] <mterry_> mvo, so you're seeing it recently in a VM (not chroot) that used to work fine, is what you're saying?  I guess I'll ask the reporters if they were in a chroot
[14:20] <tseliot> cjwatson, slangasek: https://bugs.launchpad.net/ubuntu/+source/nvidia-common/+bug/292606/comments/18
[14:22] <mvo> mterry_: yes
[14:22] <mvo> mterry_: used to work fine in kvm, now it does no longer
[14:23] <tseliot> slangasek: oh, I didn't notice that you had added a comment to that report. Thanks
[14:23] <slangasek> cjwatson: <cough> no, if you source the confmodule, it does ( 1>&3 ) 3>&1 ;)
[14:25] <cjwatson> slangasek: surely 3>&1 1>&2
[14:25] <tseliot> heh
[14:25] <cjwatson> or am I missing something?
[14:27] <slangasek> let's assume I am
[14:27] <slangasek> and find more productive pursuits :-)
[14:27] <bdrung> james_w: i want to talk about bug #446856 with you.
[14:27] <cjwatson> yes, I had enough of debconf file descriptor mapping to last me a lifetime when implementing debconf-apt-progress and predecessors
[14:29] <bdrung> james_w: do you agree that those outdated packages should be removed?
[14:33] <slangasek> bdrung: all NBS (not built from source) binary packages are always removed before release
[14:34] <slangasek> (I removed 4 of those packages yesterday, the others will also go as we have a chance to work through what will break when we do it)
[14:34] <bdrung> slangasek: https://bugs.launchpad.net/ubuntu/+source/eclipse/+bug/446856/comments/7
[14:35] <slangasek> bdrung: ah
[14:35] <slangasek> bdrung: please add tasks to that bug for the source packages you want removed
[14:37] <bdrung> slangasek: k, done
[14:49] <pitti> Riddell: I'm confused by the arora upload; it has an inline patch to src/arora.desktop which changes translations, but then debian/patches/kubuntu_06_fix_desktop_translations.diff
[14:49] <pitti> Riddell: which changes the same thing back again
[14:49] <pitti> Riddell: ah, sorry, other way round: the patch is shippe,d but additionally applied inline
[14:49] <pitti> won't that fail?
[14:51] <pitti> apw: your linux meta upload> I don't think that this syntax actually works: Depends: foo [i386]; AFAIR, architecture specific stuff only works for build-depends
[14:52] <pitti> apw: I could be wrong, of course, but was this tested?
[14:52] <slangasek> pitti: it works when the package is architecture-dependent; dpkg-gencontrol parses it out
[14:52] <slangasek> (I've just accepted that upload, fwiw)
[14:52] <pitti> ah, great; that was the missing bit
[14:53] <slangasek> (dpkg-gencontrol parses it out when it's Arch: all, too, that's just not what you want :-)
[14:53]  * pitti closes the bug, it has a missing # in changelog
[14:54] <pitti> slangasek: thanks, learned something again; but at this time I better ask twice
[14:54] <apw> pitti, yeah i built it in PPA and it seemed to do what i wanted
[14:54] <apw> slangasek, thanks for the explanation :)
[14:56] <slangasek> n/p :)
[14:57]  * slangasek glares at the seasons.  When I'm still up at 7am, I should be rewarded with *light*, dammit
[15:01] <pitti> slangasek: here it snowed for the first time .. *shudder*
[15:01] <bdrung> slangasek: thanks
[15:02] <mvo> ArneGoetje: is bug #452065 caused by language packs not having apturl translations? does that need manual hinting?
[15:02] <evand> it will never properly snow here :-/
[15:02] <ArneGoetje> mvo: looking
[15:03] <torkel> pitti: lucky you. We still haven't got any snow...
[15:04] <ion> I wish it were summer already. :-(
[15:05] <torkel> ion: we are still on summer time, so per definition it is summer? :-)
[15:06] <ArneGoetje> mvo: we have one apturl template in Rosetta with 33 msgids... is this correct?
[15:07] <kirkland> ttx: back from running now
[15:08] <dpm> mvo, ArneGoetje, I've also noticed that. It seems that translations from the apturl.ui file are not extracted and merged into the POT template, if I'm not mistaken
[15:09] <ArneGoetje> dpm: that was my guess
[15:09] <dpm> python-distutils-extra bug?
[15:12] <seb128> when will the karmic language pack be rolled?
[15:12] <seb128> ie is it still worth doing changes on launchpad for karmic today?
[15:12] <ArneGoetje> seb128: full-export from Rosetta tomorrow
[15:13] <davmor2> mvo: right running again now
[15:13] <ArneGoetje> seb128: today is translation deadline for non-language-pack translations. Langpack translation deadline is on 22nd.
[15:14] <seb128> 22nd doesn't seem realistic
[15:14] <seb128> that's the candidate image day
[15:14] <seb128> and it takes a while to roll the language packs no?
[15:15] <cjwatson> we've always landed the final langpacks post-RC
[15:15] <ArneGoetje> seb128: these dates have been decided with the release team. :) The ones which get exported from rosetta tomorrow will go onto the RC images.
[15:15] <cjwatson> even though in principle that's suboptimal
[15:15] <cjwatson> but it's been that way since language packs were implemented ...
[15:16] <Riddell> pitti: my fail on arora, I'll reject
[15:16] <seb128> oh ok
[15:16] <superm1> slangasek, tseliot my understanding is that nvidia-common is starting the debconf frontend, not the kernel postinst.  i see no references in a linux-image postinst to debconf.
[15:16] <slangasek> superm1: incorrect
[15:16] <pitti> Riddell: ok
[15:17] <slangasek> superm1: if nvidia-common were starting it, dkms wouldn't have an fd to it and wouldn't be able to pollute it; this is a bug that only affects users who have custom kernel packages built with make-kpkg
[15:17] <superm1> slangasek, so custom kernel's postinst are what's spawning debconf?
[15:17] <slangasek> yes
[15:18] <superm1> well that's just plain silly.  why don't custom kernels use the same postinst as regular ones
[15:18] <slangasek> because the regular ones use a hand-hacked debian/ tree that can't be applied at will, people use make-kpkg instead when they want to generate custom kernel packages
[15:20] <superm1> hm.  then that means that an artificial requirement needs to be added to stay away from certain fd's for anything in kernel postinst
[15:20] <slangasek> just the one fd :)
[15:20] <superm1> is there any way to to query if debconf *has* been loaded and polluted fds?
[15:21] <slangasek> yes, you can check for $DEBIAN_HAS_FRONTEND; but see my comment in the bug, you shouldn't be making noise on stdout anyway
[15:23] <superm1> well i'll be willing to check for that environment variable and only redirect in that situation, but I'd rather not change general behavior
[15:24] <slangasek> the general behavior is inconsistent with the expectations of Ubuntu Policy, and not just in the case that debconf is running
[15:27] <seb128> jdstrand, hi, could you look at bug #452057?
[15:27] <seb128> it's due to the apparmor profile, it's probably easy to fix but I'm still busy with other karmic things
[15:28] <jdstrand> seb128: I'll fix it
[15:28] <seb128> jdstrand, thanks!
[15:28] <jdstrand> seb128: sure, np
[15:30] <tordne> hi I had some problems with AppArmor, it doesn't want to load, i found out while installing mysql
[15:31] <jdstrand> tordne: apparmor doesn't want to load?
[15:31] <LaserJock> anybody know off-hand what a "normal" size for including a language on the CD is? ~10MB?
[15:32] <tordne> yes, I tried to load it again /etc/init.d/apparmor start
[15:32] <tordne> but it gives me the same answer
[15:32] <tordne> loading failed
[15:32] <jdstrand> tordne: can you paste the output somewhere?
[15:33] <dholbach> Keybuk: I don't know much about vserver internals (vserver-linux.org), but I have upstart-vserver problems with the upgrade to karmic: reboot won't work anymore, start/stop/restart <service> won't work, etc.
[15:33] <dholbach> "Failed to connect to socket /com/ubuntu/upstart: Connection refused"
[15:33] <tordne> root@Cynara:/etc/init.d# ./apparmor start * Starting AppArmor                                                                                                                                                   * Loading AppArmor module...                                                                                                                                  [fail]
[15:34] <tordne> it doesn't say much
[15:34] <tordne> if looked in all the logfiles but i didn't find anything that talked about apparmor
[15:34] <jdstrand> tordne: what kernel?
[15:35] <jdstrand> tordne: cat /proc/version_signature
[15:35] <tordne> 2.6.29-1-netbook
[15:35] <tordne> i'm using eeebuntu
[15:35] <jdstrand> tordne: is that a custom kernel?
[15:35] <tordne> that's why the netbook
[15:35] <ttx> kirkland: ok
[15:35] <dholbach> Keybuk: some services already removed old style init scripts (rsyslog, cron, probably others too)
[15:37] <jdstrand> tordne: it seems apparmor is not enabled in the kernel.
[15:37] <kirkland> ttx: new iso's ready?
[15:37] <jdstrand> tordne: you can try adding to the kernel command line 'security=apparmor', or apparmor.enabled=1. I don't remember when the kernel command line changed
[15:38] <ttx> kirkland: the current ISO only contains the euca_rootwrap
[15:38] <ttx> kirkland: the idea was to have a spin which just contains that fix, for regression testing
[15:38] <jdstrand> tordne: you might check your /boot/config-2.6.29-1-netbook and make sure apparmor is built at all
[15:38] <ttx> kirkland: but I uploaded a newer eucalyptus that you should test
[15:39] <kirkland> ttx: okay
[15:39] <ttx> kirkland: so don't hesitate to ask for a respin if you want to test it from installer
[15:39] <ttx> kirkland: note that I only fixed the "wrong IP for cloud" issue, not really the "adding a linklocal address breaks things" part of it
[15:40] <ttx> kirkland: since I don't really understand what gets broken
[15:40] <kirkland> ttx: yeah, i don't totally understand it either
[15:40] <kirkland> ttx: but i have a feeling that ip address is going to cause us months and months and months of hurt
[15:40] <ttx> kirkland: but hey, I don't really understand the need for that address anyway :)
[15:41] <ttx> kirkland: doing it link local is the right way to do it though, since it's a non-routable address
[15:41] <mathiaz> kirkland: I thought about that
[15:41] <ttx> kirkland: so basically it boils down to "why do you need that extra address for"
[15:42] <mathiaz> the way to fix it is to add a virtual interface
[15:42] <mathiaz> the same way as avahi does
[15:42] <kirkland> mathiaz: yeah, that's what I was thinking
[15:42] <kirkland> mathiaz: there should be a separate interface for this address
[15:42] <mathiaz> IIRC you always have a eth0.avahi network interface
[15:42] <kirkland> mathiaz: right
[15:42] <kirkland> mathiaz: have you attempted this yet?
[15:42] <mathiaz> kirkland: the same for the private network
[15:42] <mathiaz> kirkland: nope - I got that idea overnight
[15:43] <ttx> kirkland, mathiaz: in all cases that doesn't invalidate the fix I committed, the conffile should only look at scope global addresses anyway.
[15:43] <mathiaz> kirkland: upstream does an ip add addr or something
[15:43] <mathiaz> ttx: right
[15:43] <tordne> jdstrand : I look in the boot file and didn't find anything about apparmor
[15:43] <mathiaz> ttx: but you may run into issue if you have multiple global addresses
[15:43] <mathiaz> ttx: which is what I've noticed on one of my cluster
[15:44] <ttx> mathiaz: you don't really run into issues. You just pick the first one arbitrarily
[15:44] <mathiaz> ttx: I wasn't using public IP - only private addressing
[15:44] <jdstrand> tordne: you'll need to file a bug with eeebuntu then
[15:44] <Riddell> mvo: sorry missed your message about apturl, pykde is currently broken, I'm looking into it
[15:44] <jdstrand> tordne: or run a custom kernel
[15:44] <tordne> jdstrand : how can i add security=apparmor', or apparmor.enabled=1. to the kernel command line
[15:44] <kirkland> mathiaz: ack, i saw multiple global addresses too
[15:45] <apw> pitti, we seem to have a bug in suspend/resume handling (one which i think has been around for a while) if you suspend with AC in and remove AC and resume we always suspend one more time ... i've checked that when it occurs pm-utils is called 2x so it and the kernel are in the clear ... whats the next layer devicekit-power ?
[15:45] <ttx> kirkland: for euca_rootwrap and the changes I uploaded, my basic testing works. Didn't install it from ISO though (since there is no ISO yet)
[15:45] <pitti> apw: I think I have a fix for that in unapproved
[15:45] <kirkland> ttx: mathiaz: i was going to rework that hack to pick the address that's in the same subnet as y our default route
[15:45] <jdstrand> tordne: if you don't have these lines in your /boot/config... file, then it doesn't matter:
[15:45] <pitti> apw: are you on amd64?
[15:45] <jdstrand> CONFIG_SECURITY_APPARMOR=y
[15:45] <jdstrand> CONFIG_SECURITY_APPARMOR_NETWORK=y
[15:45] <jdstrand> CONFIG_SECURITY_APPARMOR_BOOTPARAM_VALUE=1
[15:45] <kirkland> ttx: mathiaz: that requires some ip math, though
[15:45] <apw> pitti, i am seeing it on i386
[15:46] <pitti> apw: I meant, I have amd64 .debs here, ready to try
[15:46] <jdstrand> tordne: the last one could be '0'
[15:46] <mathiaz> kirkland: well - if upstream would use virtual interface it would be easier
[15:46] <apw> pitti, ahh ... right
[15:46] <kirkland> ttx: good to hear that euca_rootwrap didn't break our back
[15:46] <pitti> apw: I was debugging that yesterday, and used those for verifying
[15:46] <mathiaz> kirkland: one eth0.avahi for 169.X
[15:46] <kirkland> mathiaz: absolutely, agree
[15:46] <pitti> apw: otherwise I can just push it to my PPA
[15:46] <ttx> kirkland: maybe it's late to change that logic more. I think its acceptable to ask the user to edit that /etc file anyway
[15:46] <kirkland> mathiaz: this needs to be fixed at the address configuration level
[15:46] <mathiaz> kirkland: and one eth0.eucapriv for the private address
[15:46] <kirkland> mathiaz: grepping and awking it is purely a hack
[15:46] <apw> pitti, if me testing would help then do ... else i can just wait :)
[15:46] <pitti> apw: pushed to desktop PPA now, I'll ping you when they were built
[15:46] <ttx> kirkland: if they use a complex network config, they should
[15:47] <pitti> apw: I tested it under slightly different conditions, but it sounds related
[15:47] <kirkland> ttx: acceptable, yes; not ideal, IMHO
[15:47] <pitti> apw: testing would be heavily appreciated, yes
[15:47] <apw> can do ...
[15:47] <pitti> apw: bug 425411 FYI
[15:47] <ttx> kirkland: well, if that's the only issue left, why not :) I fixed it so that I could actually use my setup. That 169. address showing up as CLOUP_IP was breaking everything here :)
[15:48] <pitti> apw: I tested the inverse, though
[15:48] <apw> i didn't find the inverse affected it ... only the one reported in that bug :)
[15:48] <ttx> kirkland: now we get some time to design an alternative proposal :)
[16:01] <pitti> seb128: nice, no "High" any more on https://edge.launchpad.net/~desktop-bugs/+bugs?field.milestone%3Alist=12698
[16:02] <pitti> dpm: do you still get bug 408474 ? It works just fine everywhere else
[16:03] <seb128> pitti, ;-)
[16:03] <seb128> pitti, I can add some new ones if you want though ... ;-)
[16:04] <pitti> seb128: I think we should raise bug 451613
[16:04] <pitti> apw: PPA built, I updated the bug; testing appreciated!
[16:04] <apw> pitti, i installed devicekit-power_01-1ubuntu1 and libdevkit-power-gobject1_011-1ubuntu1 ... still seems to occur
[16:05] <seb128> pitti, is that a new issue? weird that nobody noticed until now
[16:05] <pitti> seb128: doesn't happen in kvm for me
[16:05] <pitti> apw: hm; I need better debugging then, hang on
[16:05] <dpm> pitti, I could still reproduce it last week when I last tried it, let me check again...
[16:06] <apw> pitti, no problem ...
[16:06] <pitti> dpm: variants in the keyboard selector should have worked for months..
[16:06] <seb128> pitti, btw could you review the pending gvfs and rhythmbox changes from robert_ancell when you have some slot?
[16:06] <seb128> pitti, I guess they are after karmic material now but want confirmation
[16:06] <seb128> pitti, they are in bzr waiting for upload
[16:07] <pitti> apw: https://bugs.edge.launchpad.net/devicekit-power/+bug/425411/comments/13
[16:08] <davmor2> mvo: crash and burn again I'm afraid
[16:08] <dpm> pitti, the bug is not about them not working (actually selecting any language didn't seem to work from gdm either, but that's a separate issue). It's about them being displayed in the list as exactly the same as the non-variant options, with the result that you don't actually know what you are selecting (see screenshot in the bug)
[16:10] <pitti> dpm: oh, it's the language selector, not the keyboard one, sorry
[16:10] <dpm> np :)
[16:11] <bddebian> Heya gang
[16:12] <bddebian> whoops ECHAN
[16:12] <LaserJock> bddebian: and hello to you too
[16:12] <apw> pitti, i cannot get gnome-power-manager to emit anything in --debug mode
[16:12] <pitti> apw: ah, that's because I suck and meant to say "--verbose"; sorry
[16:13] <mvo_> ArneGoetje: I disconnected, sorry. is there anything that need to be done to add apturl to the langpacks (if it is not already)
[16:13] <bddebian> Heh heya LaserJock
[16:13] <tordne> jdstrand: I was reading the apparmor docs and found this
[16:13] <tordne> jdstrand:                                                                 AppArmor
[16:13] <tordne> cannot be used together with other Linux Security Modules, so if CONFIG
[16:13] <tordne> SECURITY CAPABILITIES or CONFIG SECURITY SELINUX
[16:13] <tordne> is set to y or m
[16:14] <mvo_> dpm: https://bugs.edge.launchpad.net/ubuntu/+source/apturl/+bug/452065 is a open bug about it, but when I build it with the rosetta translations locally its all there
[16:14] <jdstrand> tordne: they can both be compiled into the kernel, only one can be loaded at a time
[16:15] <tordne> jdstrand : and i got CONFIG_SECURITY_SELINUX=y
[16:15] <pitti> seb128: ugh, quite intrusive
[16:15] <ArneGoetje> mvo_: can you check if the apturl.ui strings get added to the .pot file? The template in Rosetta has 33 msgids. Is that correct?
[16:15] <seb128> pitti, ok, what I though and that's why I didn't upload
[16:15] <tordne> jdstarnd: but how can i change this?
[16:15] <jdstrand> tordne: you don't want to change it
[16:16] <seb128> pitti, btw please don't use triaged for bugs not upstreamed yet
[16:16] <pitti> seb128: oh? I usually use this for "bug is understood/reproducible  and can be looked at by dev"
[16:16] <seb128> pitti, we use it as "is sent upstream" for GNOME bugs
[16:16] <pitti> hmkay
[16:17] <mvo_> ArneGoetje: that sounds about right
[16:17] <tordne> jdstrand : i just got a problem with mysql, it doesn't want to start unless apparmor is loaded
[16:17] <jdstrand> tordne: eg, the Ubuntu kernel has: http://paste.ubuntu.com/294042/
[16:18] <jdstrand> tordne: you'll need to adjust your kernel config to have apparmor support
[16:18] <dpm> mvo, mvo_, ArneGoetje, I built the package locally with pkgstriptranslations from pkgbinarymangler enabled, and the apturl.ui translations are not extracted and merged into the POT file
[16:18] <simon-o> Hi, I fixed a FTBFS for a package in universe. What do I do next? Just subscribe the sponsors as usual or the release team?
[16:18] <jdstrand> tordne: as for mysql requiring apparmor-- that doesn't sound right. I would file a bug on mysql giving as much detail as possible
[16:18] <jdstrand> tordne: mysql doesn't depend on apparmor afaik
[16:19] <\sh> jdstrand, I would complain if it does ;)
[16:19] <jdstrand> tordne: it supplies a profile, but if apparmor isn't available it shouldn't matter
[16:19] <sebner> Simira: still the sponsors
[16:19] <sebner> argh
[16:19] <sebner> simon-o:  still the sponsors
[16:19] <mvo_> dpm: its still using apturl.glade for some reason afaics
[16:19] <jdstrand> \sh: heh
[16:19] <simon-o> sebner: ok, thanks
[16:19] <mvo_> dpm: oh, you mean the kde .ui file?
[16:20] <apw> pitti, debug is attached to the bug
[16:20] <mvo_> dpm: sorry, I confused that with the gtk gtkbuilder .ui file
[16:20] <dpm> mvo_ no, you were right, I meant the gtkbuilder file, I thought apturl was already using gtkbuilder
[16:20] <tordne> jdstrand: apparnor is automatically installed, and when i wanted to install msql it gave the message that apparmor wasn't loaded.
[16:20] <mvo_> dpm: its the kdebuilder .ui file, I got confused by this as well
[16:20] <\sh> btw...is anyone working on a working jboss integration in ubuntu? if so, how can I help :)
[16:21] <jdstrand> tordne: please file a bug
[16:21] <dpm> mvo_, for the kde part, it might be bug 427358, for the glade part, I'm not sure
[16:23] <mvo_> dpm: right
[16:24] <dpm> mvo_, the glade file translations (there are only two of them) seem to be extracted ok and put into the POT template
[16:24] <tordne> ok i will
[16:25] <tordne> jdstrand: ok i will file a bug report
[16:25] <mvo_> dpm: is apturl part of the langpacks? I wonder why its not showing up translated?
[16:25] <dpm> let me check...
[16:26] <dpm> mvo_, it seems to be, in my system -> /usr/share/locale-langpack/ca/LC_MESSAGES/apturl.mo
[16:26] <ArneGoetje> mvo_: according to rosetta, the translations will be exported into langpacks.
[16:26] <mvo_> dpm: thanks, odd. I look a bit more to figure out what is going wrong then
[16:26] <mvo_> thanks ArneGoetje too
[16:32] <dpm> mvo_, actually... can you reproduce the bug in your system? I can't. Apturl appears translated in Catalan, at least
[16:33] <jdstrand> tordne: thanks!
[16:33] <mvo_> dpm: I have a local build (without striptranslations) now, let me downgrade
[16:38] <mvo_> dpm: I see it here, the problem is apparently that the mo file is in language-pack-kde-de-base:
[16:39] <mvo_> dpm: but it should be in a base language pack or something
[16:39] <dpm> mvo_, oh I see... yes, that's why I can't reproduce it, I've got the kde langpack also installed
[16:40] <mvo_> yeah
[16:40] <dpm> ArneGoetje, ^ should that be filed against langpack-o-matic?
[16:41] <ArneGoetje> dpm: I think so
[16:42] <mvo_> ArneGoetje: I added a bugtask to #452065
[16:45] <lool> Keybuk: poke
[16:45] <lool> Keybuk: Do you have any issue with adding this check during boot http://bazaar.launchpad.net/~bratsche/gdm/xsplash-check-cmdline/revision/146 ?
[16:45] <Keybuk> makes sense to me
[16:45] <Keybuk> though why would you want to disable xsplash?
[16:46] <Keybuk> you disable usplash because you want to see things going on under it
[16:46] <Keybuk> all that goes on under xsplash is the pinwheel
[16:46] <lool> Keybuk: Just in case something goes wrong or you simply don't want it
[16:46] <ion> That would match anything with a ‘splash’ substring.
[16:46] <lool> Keybuk: we had the case where it broke and we had no facility to document a workaround, and some people don't like it
[16:46] <lool> ion: I suggested adding -w
[16:46] <Keybuk> though strictly speaking, that grep is wrong
[16:47] <Keybuk> since that will match root=/dev/mapper/ubuntu-splash-top
[16:47] <Keybuk> -w won't help, since - is a word boundary
[16:47] <lool> Hmm true, I think gdm was using that though
[16:48] <Keybuk> the gdm upstart job reads /proc/cmdline using for
[16:48] <Keybuk> random thought
[16:48] <Keybuk> if you check for splash in that list and set an ENVVAR, does that end up in the gdm session scripts
[16:48] <Keybuk> ie. could you modify /etc/init/gdm.conf, set SPLASH=true at the top
[16:48] <lool> we dont need to send an envvar I guess
[16:48] <Keybuk> then when it reads the command-line, set SPLASH=false
[16:48] <Keybuk> (or however that should work)
[16:49] <Keybuk> then just check that var in the scripts
[16:49] <Keybuk> that'd save you a lot of processor time of re-reading /proc/cmdline a dozen times
[16:49] <lool> just for ... splash) start xsplash;
[16:49] <Keybuk> (well, not that it's much, but each one adds up)
[16:54] <ArneGoetje> mvo_, dpm: fixed in langpack-o-matic, should go into the main langpack now, not kde anymore.
[16:54] <dpm> ArneGoetje, cool, thanks
[16:55] <mvo_> ArneGoetje: great, thanks
[17:04] <ccheney> bug 451772  seems to claim openoffice.org-l10n-fr isn't being installed even though they have the rest of the localizations, is that supposed to be happening?
[17:04] <ccheney> and which package should that bug be reassigned to?
[17:05] <ccheney> or is it some sort of strange user error?
[17:06] <LaserJock> cjwatson: for some reason Ubiquity is not being removed from Edubuntu livefs installs, am I not supposed to have ubiquity packages in the dvd-live seed?
[17:07] <ccheney> pitti: ping
[17:07] <pitti> ccheney: hi
[17:08] <ccheney> pitti: any ideas about the above? i saw you have been working on fixing OOo getting pulled in by mistake and didn't know if it was related
[17:08] <pitti> ccheney: I think that should now get pulled in by the language-selector
[17:09] <pitti> ccheney: we don't have explicit l-support packages for that any more, I think
[17:09] <pitti> ccheney: ArneGoetje knows the details
[17:09] <ccheney> ok
[17:09] <ccheney> i'll ask the user if they used language-selector
[17:10] <ccheney> looks like that user is also missing the gnome/kde stuff assuming they are running one of those two
[17:15] <cjwatson> LaserJock: the manifests look right, so I'll need to see logs
[17:17] <LaserJock> cjwatson: is that /var/log/installer/syslog?
[17:17] <cjwatson> yes
[17:23] <didrocks> jdstrand: hi, I thought you merged my ufw branch a while ago, why rejecting it now?
[17:23] <jdstrand> didrocks: hi!
[17:23] <LaserJock> cjwatson: http://pastebin.com/f44d0c38d
[17:24] <cjwatson> LaserJock: anything in /var/log/installer/debug? (Perhaps we could do this in a bug report instead?)
[17:24] <jdstrand> didrocks: I was just doing some housekeeping. I rewrote your patch and included it in 0.24 (with a 'Based on work by Didier Roche' in the changelog)
[17:25] <jdstrand> didrocks: since I didn't explicitly take the merge as it was written, I used Rejected
[17:25] <didrocks> jdstrand: ok, it was just for an explanation :)
[17:27] <LaserJock> cjwatson: http://pastebin.com/f2c4467c7 and yeah, if you would like me to file a bug I can, is there an easy way to do it that will get you the logs via apport?
[17:28] <cjwatson> 'ubuntu-bug ubiquity'
[17:29] <cjwatson> your logs so far don't seem to explain it at all though
[17:29] <cjwatson> it's not removing any packages, but it doesn't say why
[17:29] <slangasek> ScottK: fwiw, I'm just about done with libkrb53 now; there are still some revdeps that are going to be uninstallable, but one of them is root-system, which I gave up trying to fix
[17:29] <slangasek> (s/one of them is/most of them are/)
[17:36] <LaserJock> cjwatson: is ubuntu-bug meant to be run with sudo? I get some long traceback that says that it doesn't have permission to the .crash
[17:36] <cjwatson> no
[17:36] <cjwatson> that's a bug somewhere else; ISTR update-notifier?
[17:36] <cjwatson> something was shipping /var/crash with bogus perm
[17:36] <cjwatson> s
[17:38] <mvo_> LaserJock: the update of update-notifier from some minutes ago should fix that
[18:00] <kees> mvo_: hi! did you see the apt cron bug from yesterday?
[18:01] <mvo_> kees: bug #449535 ?
[18:01] <kees> mvo_: I committed a fix for bug 449535 to the apt bzr tree, but since there were other things pending, I didn't upload it.
[18:01] <ion> keybuk: So, any hope of getting better sreadahead performance with laptop HDDs, or will readahead be put back?
[18:01] <kees> mvo_: yeah
[18:01] <Keybuk> ion: I'm still working on that
[18:01] <Keybuk> ion: it's a non-trivial problem ;)
[18:02] <mvo_> kees: I upload in a bit, thanks a lot for the commit
[18:02] <ion> I wonder if i could do anything...
[18:03] <mvo_> kees: there is a karmic branch for apt already that I will port to and upload from
[18:04] <kees> mvo_: oh! ok, sorry, I went from the Vcs in the karmic source package.
[18:04] <mvo_> kees: my mistake, thanks again
[18:05] <mvo_> kees: the vcs-bzr header fix is commited but not uploaded (ironically)
[18:05] <kees> hehe
[18:07] <Amaranth> ion: a clean install will fix it ;)
[18:09] <ion> amaranth: Why is that?
[18:09] <Amaranth> ion: afaik the main problem is that sreadahead ignores the location on disk and just loads the files in the order they are used in the boot
[18:09] <Amaranth> so you seek like mad
[18:09] <ion> Ah
[18:11] <PovAddict> package 'lcov' includes a 'genpng' tool that when run, says "ERROR: required module GD.pm not found on this system (see www.cpan.org)."
[18:12] <PovAddict> shouldn't libgd-gd2-perl be in the "recommends" line at least?
[18:13] <PovAddict> er, nvm... I'm filing a bug *right now*... lcov doesn't depend on/recommend/suggest *anything*!
[18:21] <LaserJock> cjwatson/mvo: I just can't get ubuntu-bug to work to save my life. I fully dist-upgraded. what logs should I attach? everything in /var/log/installer/?
[18:26] <andersk> Keybuk: Can you take a look at bug 452196?
[18:29] <Keybuk> andersk: it was only reported 3 hours ago
[18:29] <Keybuk> I'm not that far through my bugs folder yet
[18:30] <PovAddict> heh
[18:31] <andersk> Fair enough.  I think this one’s important, though, since it can exacerbate filesystem corruption.
[18:32] <Keybuk> everyone thinks that bugs they care about are important
[18:32] <Keybuk> that's how it works :p
[18:33] <andersk> Yeah, yeah.  I’ll let you get back to work.  :-)
[19:01] <jdstrand> cjwatson: hi! so, I just rebooted and got the '... has been mounted... check forced.' message (fine). I have a large disk, and it is spinning away, but other than the check forced message, I have no visual cue as to what is happening
[19:02] <jdstrand> cjwatson: I come to you cause I know you have worked on the boot quieting stuff
[19:03] <jdstrand> cjwatson: I assume it is still fscking, but even I am beginning to wonder at this point. I'd imagine a user might be inclined to power off the machine
[19:03] <jdstrand> cjwatson: is this a known bug?
[19:03] <jdstrand> s/a user/another user/
[19:04] <jdstrand> cjwatson: should I bother someone else? :)
[19:05] <jdstrand> \o/ it's done
[19:09] <sroecker> pitti, hi, can jockey handle debconf guis? I wrote a handler that installs isight-firmware-tools but it doesnt show the debconf menu
[19:20] <superm1> pitti, sroecker perhaps switching jockey to using aptdaemon would solve that type of problem
[19:20] <superm1> too bad it's too late for that kind of thing
[19:21] <sroecker> superm1, so it just can't handle debconf stuff?
[19:24] <superm1> sroecker, not currently, it can't handle any interactive debconf right now
[19:25] <sroecker> superm1, thanks, I thought I didn't use the right command/handler
[19:38] <jdstrand> slangasek: hi! is subscribing ubuntu-release to a milestoned bug with a debdiff attached enough to get your attention? I realize I am contacting you on irc now, but in the future, is this enough
[19:38] <jdstrand> ?
[19:48] <pipegeek> is the version of empathy im in karmic going to support im formatting?
[19:50] <cjwatson> LaserJock: yes, that should do
[19:51] <sladen> Keybuk: is usplash (since today) supposed to prevent you from using Alt-F1 (this isn't any worse than it was a week ago, but...)
[19:51] <cjwatson> jdstrand: that's bug 446596
[19:52] <Keybuk> sladen: no, what happens when you do?
[19:52] <sladen> Keybuk: nothing
[19:52] <Kage_Jittai> hello, I am with the project called "The mana world" our project is in the ubuntu repos
[19:52] <sladen> Keybuk: the same (static) usplash screen displays for ~30seconds, then ~30seconds of blank, then ~15 seconds of xsplash, then gdm
[19:53] <Kage_Jittai> the ubuntu repos are very outdated some as many as 4 versions old
[19:53] <Kage_Jittai> We have requested backports
[19:53] <sladen> Keybuk: I think the throbbingness is quite important for the whole haven't-crashed-yet reassurance, as it responding to keypresses when they're hit
[19:53] <ion> I “only” have 15–20 seconds of blank screen between usplash and xsplash. :-P
[19:53] <Kage_Jittai> but they have gone unanswered
[19:54] <ion> sladen: They are working on the gdm slowness, i hear.
[19:54] <Kage_Jittai> we are now considering dropping support for versions in the repo
[19:54] <sladen> ion: yeah, boot went from <1:30 seconds in jaunty to ~2:30 in karmic
[19:54] <Kage_Jittai> and only maintaining one active version
[19:54] <Kage_Jittai> this will break the projects in the repo
[19:55] <sladen> ion: but the GDM slowness doesn't really matter if the user is reassuring entertained by livid pulsations in the meantime
[19:56] <ion> sladen: Yeah, it would be nice if X could just start while usplash is still running and usplash would handle that properly. Dunnno whether it’s feasible.
[19:57] <sladen> ion: we had ideas about this in a conference room in Oxford ~5 years ago.  I'm sure it'll happen one day ;-)
[19:57] <cjwatson> it is, we're working on it
[19:57] <pitti> sroecker: right, it doesn't right now
[19:57] <pitti> sroecker: you'd need to write a handler which pokes the answers into debconf db first
[19:59] <PovAddict> I'd like async logout... so my mom can logout, and I can get back to my locked session while her apps and X are still in the process of shutting down
[20:31] <jono> slangasek, can you reply to Joe Casad email re. interview, he needs to know fairly soon
[20:37] <robbiew> jono: slangasek worked UK hours today...FYI
[20:40] <jono> robbiew, ahhh cool
[20:54] <mvo_> mathiaz: could you add a example config file to bug #450837 so that I can test against that?
[20:54] <mathiaz> mvo_: sure - let me dig one
[20:55] <mvo_> thanks mathiaz!
[20:58] <mvo_> mathiaz: is it ok if the mysql-client stuff for 5.1 is installed (i assume it is) when the 5.1 server is not ?
[20:58] <mathiaz> mvo_: yes
[20:58] <mathiaz> mvo_: but mysql-server 5.0 requires mysql-client 5.0
[20:59] <mathiaz> mvo_: so I guess you'd also wanna remove mysql-client
[20:59] <mathiaz> mvo_: in addition to mysql-server
[20:59] <ccheney> lamont: your city is on the news :)
[20:59] <mathiaz> mvo_: I'll update the bug description
[20:59] <mvo_> mathiaz: ok, thank
[20:59] <mvo_> s
[21:03] <mathiaz> mvo_: bug updated
[21:03] <mathiaz> mvo_: the second configuration file has been mangled (text wrapped)
[21:04] <mathiaz> mvo_: I've added a link to the location where I've got the examples configuration
[21:04] <mathiaz> mvo_: let me know if you have any more questions
[21:07] <ion> Woot http://www.ouaza.com/wp/2009/10/08/3-way-merge-of-debian-changelog-files/
[21:59] <Keybuk> wow
[21:59] <Keybuk> X doesn't like "modprobe nouveau" much
[22:00] <bryce_> get any fun colors?
[22:00] <Keybuk> no, just a crash
[22:00] <bryce_> aw
[22:01] <Keybuk> (X was running with the ordinary nv driver :p)
[22:01] <jdong> aww disappointing
[22:02] <ion> Does nouveau use KMS? I’d almost expect something to go wrong with a driver initializing the framebuffer for KMS while some random stupid userspace program is poking the hardware directly. :-P
[22:03] <Keybuk> nouveau is KMS yes
[22:03] <Keybuk> that's interesting
[22:03] <Keybuk> usplash sometimes fails to start with the bogl backend too
[22:45] <akgraner> rickspencer3, I upgraded to Karmic on the machine I use everyday..  It is my understanding that the old notifier (the one with the orange burst and the red arrow) won't work anymore is that true?
[22:45] <rickspencer3> akgraner, can you switch to #ubuntu-desktop?
[22:45] <akgraner> yeppers
[22:45] <akgraner> :-)