[01:27] <cjwatson> slangasek: fyi, removing uncompressed Packages files is blocked on bug 255545
[01:27] <slangasek> ok
[01:27] <cjwatson> I knew I'd run into *something* like that before, but had been hoping it was fixed ...
[01:51] <infinity> cjwatson: That's got to be a pretty quick fix, really...
[01:52] <cjwatson> I wasn't sure which of the several alternative approaches was best
[01:52] <slangasek> yes, there's a design decision to be made there
[01:53] <infinity> cjwatson: Removing from Releases is clearly wrong.  Since apt-cdrom wants to do verification on the fly, I see no reason why it couldn't unzip to /var/lib/apt, just like apt-get does, and verify from there.
[01:53] <infinity> Pretty much reuse the same code path.
[01:54] <RAOF> Intrepid seems to take parallel booting a little too far - it appears that the fsck of / or /home gets run in parallel with the rest of the boot sequence, which means I can get to a login prompt with an entirely read-only filesystem which then doesn't work.  This'd be a bug to file against upstart, right?
[01:55] <james_w> RAOF: I had that, but I didn't realise/think there was an fsck going on
[01:55] <cjwatson> infinity: you're probably brighter than I am at this time of day, so I'll take your word for it. :-)
[01:55] <RAOF> james_w: It's easier to notice when it's just /home.  Then you _can_ login, and work out what's happening.
[01:56] <infinity> cjwatson: Well, I think the fundamental problem here isn't that apt doesn't know how to do this, it's that apt-cdrom and apt don't share enough code. :)
[01:56] <james_w> as for a bug I'm not sure if it would be upstart or the initscripts
[01:56] <infinity> cjwatson: s/apt /apt-get /
[01:57] <infinity> james_w: upstart provides those init scripts.
[01:57] <infinity> james_w: Oh, I lie.  sysvinit still does.
[01:57] <james_w> oh, ok, I thought they were in a different package
[01:58] <cjwatson> infinity: I certainly won't argue with that
[01:58] <infinity> RAOF: It's likely an initscripts/upstart misinteraction.  In that the latter should probably be using a mechanism to delcare the fsck scripts as blocking, and it's not.  *hand wavy*
[01:58] <RAOF> infinity: Sounds about handwavey right.
[01:59] <kirkland> cjwatson: hiya, i have a grub patch, if have any time to look at it
[01:59] <infinity> RAOF: I'd start with the bug report at initscripts/sysvinit and see where it goes from there.
[01:59] <RAOF> infinity: Ta.  Will do.
 actually, in London last month, Keybuk argued that we totally should parallelize the fsck with the rest of the startup, to get everyone to the login screen sooner
[01:59] <slangasek> and force a delay at gdm if necessary
[01:59] <kirkland> understanding that it is of course probably the middle of the night for you, it can certainly wait ;-)
[02:00] <slangasek> hmm, it was Keybuk, was it?  or Ted
[02:00] <TheMuso> slangasek: Keybuk IIRC.
[02:00] <infinity> slangasek: That works for /home (delaying at GDM), but it so obviously doesn't work for any other mountpoint.
[02:00] <RAOF> slangasek: Wouldn't that require /tmp to be some sort of ramfs?
[02:00] <infinity> RAOF: A lot more than /tmp ... /var, for instance.
[02:00] <slangasek> well, yes, presumably we block on /var :)
[02:01] <RAOF> Oh, right.  Yes.
[02:01] <slangasek> I don't know
[02:01] <cjwatson> kirkland: not really awake any more ...
[02:01] <kirkland> cjwatson: ;-)  no prob.  ping me at some point tomorrow perhaps and we can discuss
[02:01] <infinity> slangasek: I suppose the mechanism used for blocking on /home would need to be pretty user-friendly here... Failing to log in is kinda unintuitive and scary.
[02:01] <slangasek> yes, that was the plan
[02:02] <slangasek> the user-friendly part, not the scary and unintuitive part
[02:02] <infinity> *giggle*
[02:02] <infinity> RAOF: So... This may be a half-implemented "feature", rather than a bug. :)
[02:02] <infinity> RAOF: OTOH, if you can prove that it's not blocking on /var, you may still have a bug.
[02:02] <slangasek> still warrants a bug report, though, so we all know what's going on. :)
[02:03] <infinity> RAOF: If it's only /home, then it might be the above.
[02:03] <slangasek> (even if it's a half-implemented feature, given the current state of implementation it should be tracked as a release-blocking bug...)
[02:03] <infinity> RAOF: And, yes, either way, vorlon's right.  A bug report to the effect of "eek, unintuitive and scary, must be user-friendly by release" would be nice.
[02:03] <RAOF> infinity: I've seen both - unable to GDM login because /home is in the middle of fsck, and unable to login *at all* because / was in the middle of fsck.
[02:04] <infinity> RAOF: The former is usability, perhaps.  The latter is pretty clearly a big, fat WTF.
[02:04] <RAOF> Right.
[02:05] <infinity> My god, could CDBS be any more inefficient.
[02:05] <infinity> I swear this build has called dh_buildded ON THE SAME BINARY PACKAGE, like 5 times now.
[02:05] <slangasek> yes, here let me show you
[02:05] <RAOF> infinity: It could be worse.  It could build twice.
[02:05] <slangasek> <clickety click>
[02:05] <infinity> s/buildded/builddeb/
[02:07] <infinity> slangasek: I still argue that CDBS was Colin's way of sabotaging Debian on his way out.
[02:07] <calc> anyone else having weird problems with firefox in hardy?
[02:07] <calc> with it locking up on websites, etc
[02:07] <infinity> calc: Working great for me.  Perhaps you're surfing the wrong porn?
[02:08] <slangasek> calc: don't follow any links infinity offers as "test cases"
[02:08] <calc> infinity: well one of the cases where it isn't working for me is on facebook top friends app (but doesn't crash), and sparkpeople.com doesn't let me add pictures and hangs the browser
[02:09]  * calc isn't sure if either of them use flash
[02:09] <infinity> Removing flash is a pretty good way to find out.
[02:12] <cjwatson> or flashblock
[02:38] <RAOF> Pair of bugs filed against sysvinit.
[02:39]  * TheMuso manages to shave 1.1MB off the size of the ubuntu-sounds package by downsampling all files by half.
[02:42] <ion_> themuso: I’d prefer encoding them as vorbis instead.
[02:42] <TheMuso> ion_: The GNOME stuff doesn't yet support that.
[02:42] <TheMuso> ion_: Only wavs work at this point.
[02:42] <ion_> themuso: No problem, just decode them in postinst.
[02:42] <TheMuso> ion_: But ogg is the plan for the future.
[02:42] <ion_> Shouldn’t take too long.
[02:42] <TheMuso> eeeew
[02:42] <TheMuso> No thanks.
[02:42] <TheMuso> That brings in one more dependency on the disk that is really not needed.
[02:43] <TheMuso> And negates the shrinking in the first place. This is a CD size operation only.
[02:43] <slangasek> "only"?
[02:44] <TheMuso> slangasek: Well maybe not only, but it does help, and the quality difference is really not noticable unless you listen carefully.
[02:44] <slangasek> ok
[02:44]  * TheMuso hasn't uploaded it yet, just experimenting with sizes of the package depending on what files are shrunk.
[02:45]  * slangasek nods
[02:45] <slangasek> did you find that the .wav files were stereo as well?  Was there room for improvement there?
[02:45] <slangasek> (i.e., drop to mono except in any rare cases where it matters)
[02:47] <TheMuso> Haven't checked that yet, but I think they are all stereo yes.
[02:48] <TheMuso> Ok it appears that the startup/logout sounds are stereo, but the others, while stored as stereo, are only mono in actual sound.
[02:51] <nxvl> if a package need bash for some reason during build time, i need to a) remove the dependency of bash or b) add bash as build-dependency
[02:51] <nxvl> ?
[02:52] <StevenK> I thought bash was still Essential: yes?
[02:52] <StevenK> nxvl: c) Fix it to use SHELL=/bin/bash
[02:53] <StevenK> nxvl: /bin/sh != /bin/bash doesn't mean it isn't there, just that it isn't the default/
[02:53] <StevenK> s^/$^.^
[02:53] <ScottK> nxvl: Better to teach it not to need bash if you can.
[02:53] <nxvl> StevenK: the problem here is that bash isn't there
[02:54] <nxvl> StevenK: configure: error: cannot run /bin/bash ../config.sub
[02:54] <StevenK> nxvl: Then your chroot is broken. The bash package is Essential: yes.
[02:54] <nxvl> ScottK: yes, but i'm just about to quit on that
[02:54] <nxvl> ScottK: heh, then the build daemons are broken :D
[02:55] <nxvl> http://launchpadlibrarian.net/16512924/buildlog_ubuntu-intrepid-i386.php5_5.2.6-2ubuntu1_FAILEDTOBUILD.txt.gz
[02:55] <StevenK> nxvl: But adding bash as a Build-Depends is pointless.
[02:56] <nxvl> that's what i thought
[02:56] <nxvl> :S
[02:56] <ion_> themuso: A statically linked oggdec would 215 KiB, btw.
[02:56] <ion_> take
[02:56] <nxvl> i will keep looking
[02:56] <nxvl> StevenK: thank you!
[02:56] <TheMuso> ion_: Its still more work than its worth.
[03:03] <nxvl> nevermind i found the problem
[03:03] <nxvl> <- dumbass
[03:10] <YokoZar> vmware is not working at all for running Intrepid (freezes on login, even with the earlier workaround of modprobe -r snd_pcsp)...what can I use to test/develop on Intrepid?
[03:11] <ion_> virtualbox
[03:38] <TheMuso> 5~/c
[03:46] <warren> Can anybody running Ubuntu help me compare something to Fedora?
[03:46] <warren> in your "man su" do you have this option:
[03:46] <warren>        -m, --preserve-environment
[03:46] <warren>               do not reset environment variables
[03:46] <StevenK>        -m, -p, --preserve-environment
[03:46] <StevenK>            Preserve the current environment.
[03:48] <warren> hmm
[03:48] <warren> thanks
[04:25] <macho> will any help me
[04:25] <macho> any 1
[04:25] <RAOF> macho: Probably not in here; is your problem related to the development _of_ Ubuntu?
[04:26] <macho> no where can i get help to add ubuntu ps3
[04:26] <RAOF> #ubuntu would be the right channel.
[04:26] <macho> maybe you guy can help ps3 ower
[04:26] <RAOF> Ubuntuforums would also likely be a good spot.
[04:26] <macho> thank raof
[04:27] <macho> btw what you guys work on
[05:48] <pwnguin> "I am the tech lead for Goobuntu, Google's in-house derivative of Ubuntu, used as an Engineering desktop amongst other things."
[05:48] <pwnguin> https://wiki.ubuntu.com/AndrewPollock2
[05:48] <pwnguin> i thought goobuntu didnt exist
[05:54] <lifeless> pwnguin: it exists
[06:11] <pitti> Good morning
[06:11] <pitti> lamont: oh, enjoy!
[06:11] <StevenK> Morning pitti
[06:11] <nxvl> morning pitti
[06:13] <dholbach> good morning
[06:26]  * dholbach has to get used to the new wiki syntax
[06:26] <nxvl> dholbach: it has changed?
[06:27] <dholbach> moin was updated on wiki.u.c yesterday
[06:28]  * nxvl checks
[06:28] <nxvl> oh! that's why i've been having some issues with the wiki today
[06:29] <persia> The new interface is confusing, the new syntax a bit odd, the need to refresh cookies annoying, and the installed code likely significantly more flexible and secure.
[06:30] <nxvl> i don't feel the difference :S
[06:32] <persia> nxvl: Edit a page.  Click the buttons at the bottom of the editing frame.
[06:32]  * nxvl clicks
[06:34] <nxvl> moin is slow
[06:34]  * nxvl loves doku
[06:34] <nxvl> wait
[06:34] <nxvl> save wasn't down?
[06:34] <nxvl> as in at the bottom
[06:34] <persia> It was, it's up now.  Still works, just an example of the difference :p
[06:35] <nxvl> that's definitely uncomfortable
[06:36] <persia> The only part I find odd is that the comment is not near the preview/save buttons.
[06:37] <slangasek> hmm, "libcanberra"?
[06:37] <RAOF> Australia's where it's at.
[06:38] <persia> An entirely new view of desktop events, neatly constructed between the primary existing places, and intended to supercede them, yet without the natural resources to do so without external assistance.
[06:39] <persia> (at least if XDG can be said to be between KDE and GNOME, rather than a bit south)
[06:39] <RAOF> persia: Is that a quote on the libcanberra naming?
[06:39] <persia> RAOF: Only if it gets repeated
[06:40] <RAOF> 'cause it's a pretty good description of the city :)
[06:40] <TheMuso> RAOF: lol you are so right!
[06:41] <TheMuso> slangasek: But its supposed to be the new library for sound events in GNOME/Desktop applications.
[06:41] <slangasek> why did we need a new one? :)
[06:41] <RAOF> With a passing nod to KDE, too.
[06:42] <RAOF> slangasek: We had an old one? :)
[06:42] <persia> http://0pointer.de/blog/projects/sixfold-announcement.html
[06:43] <TheMuso> The current sound events system in GNOME is kinda sucky.
[06:43] <persia> s/kinda/rather/
[06:44] <RAOF> The KDE default sound theme isn't crash-hot, either.  I'm not a big fan of having a "bing!" every time I press a button.
[06:44] <slangasek> persia: ah, ok then :)
[06:45] <slangasek> RAOF: computers that "bing!" are an attempt at operant conditioning to see if I'll murder someone, I think
[06:45] <RAOF> slangasek: Someone's going to broadcast a "bing!" in a public place to trigger your programming?
[06:46] <slangasek> I'll have the perfect alibi
[06:46] <slangasek> s/alibi/defense/, perhaps :)
[06:59] <pitti> zul: did you see the php5 FTBFS?
[07:00] <StevenK> pitti: Did you see that it was due to bash? :-)
[07:00] <StevenK> Or autotools
[07:00] <pitti> yeah, looked quite weird
[07:00] <StevenK> pitti: If the hppa and ia64 buildds could actually keep up, I'd have a few packages for you to NBS out.
[07:01] <pitti> StevenK: ia64 is down to 24 builds
[07:01] <pitti> should manage until I attack NBS tomorrow
[07:01] <pitti> for now I just had a quick look at http://people.ubuntu.com/~ubuntu-archive/testing/intrepid_outdate.txt
[07:03] <pitti> StevenK: hppa-only rdeps don't stop me from NBSing packages
[07:03] <Hobbsee> hey pitti
[07:03] <StevenK> pitti: Ah. There's a few :-)
[07:03] <pitti> StevenK: you can still check for unsatisfieable dependencies with apt, so if someone is actually willing to fix hppa, he can still do so
[07:04] <pitti> "apt-cache unmet" ftw :)
[07:04] <pitti> hey Hobbsee
[07:04] <StevenK> pitti: Well, usually the fix is uploaded, but hppa hasn't built it yet
[07:05] <StevenK> And that is true for the 13 or so uploads I did last night
[07:06] <slangasek> StevenK: the php5 ftbfs is linked to the new libtool...
[07:06] <StevenK> slangasek: Fun.
[07:06]  * pitti looks at the time FTBFS and wonders...
[07:06] <StevenK> Where's Keybuk, so we can belt him ...
[07:06] <pitti> Package automaken is a virtual package provided by:
[07:06] <pitti>   automake1.9 1.9.6+nogfdl-3ubuntu1
[07:06] <pitti>   automake1.7 1.7.9-9
[07:06] <pitti>   automake 1:1.10.1-3
[07:06] <pitti> Using automake1.8 (selected in sbuildrc)
[07:07] <pitti> infinity, cprov: ^ any idea why it picks the very alternative which does not even exist?
[07:07] <StevenK> Woo!
[07:07] <pitti> infinity: is the "selected in sbuildrc" actually true, and this file needs an update to just point to "automake"?
[07:09] <YokoZar> pitti: was there a kernel recently (namey -20) that was in proposed but didn't go into -updates?  It seems like virtualbox-ose-modules-generic depends on a -20 version but there is no -20 kernel (thus making the -20 virtualbox-ose-modules uninstallable)
[07:10] <pitti> YokoZar: right, that -updates move was an accident
[07:10] <pitti> we need to reupload -19 into hardy-updates
[07:10] <YokoZar> Fair enough
[07:11] <YokoZar> Now I just need to figure out how to actually get Intrepid to boot in virtualbox (still freezes in vmware for me at login, even after removing the snd_pcsp module)
[07:13] <YokoZar> slangasek: not to pester, but is there anyway these critical bugs in the virtualization programs could be given some sort of higher priority?  Not having Intrepid work in vmware or virtualbox has been preventing me from doing substantial amounts of work on my package.  There are other things I can do in the meantime, but it does seem like it's a blocker of sorts.
[07:14] <slangasek> YokoZar: I'm not on the kernel team, there's not a whole lot that I can do personally to move them along; they've already been flagged as high-priority issues to the kernel team.
[07:15] <TheMuso> YokoZar: What about a chroot?
[07:15] <YokoZar> slangasek: Well thank you, in any case :)  That seems to be the best thing to do.
[07:16] <YokoZar> TheMuso: That and pbuilder, basically.
[07:55] <lifeless> mvo: hi
[08:00] <mvo> hey lifeless
[08:02] <pitti> hi sabdfl
[08:03]  * pitti waves to mvo
[08:03] <pitti> mvo: compiz-fusion-plugins-main wants to pull in compiz-bcop; do we want that in main, or was that an error?
[08:03] <pitti> (it's in dep-wait)
[08:04] <mvo> pitti: let me check
[08:08] <mvo> pitti: isn't that in main since gutsy? compiz-bcop. there is also a compiz-fusion-bcop that we got from debian (they decided to package it with a different name). might be a good time now to actually use the debian one and get rid of ours
[08:08] <pitti> mvo: oh, hang on, compiz-bcop doesn't even exist in hardy any more
[08:08] <pitti> mvo: right, so that needs a fixed build dependency
[08:09] <pitti> mvo: I'll promote compiz-fusion-bcop
[08:09] <pitti> done
[08:09] <pitti> s/exist in hardy/exist in intrepid/
[08:11] <mvo> pitti: aha, good. now I just need to fix the compiz packages
[08:11]  * mvo goes and does it
[08:11] <pitti> mvo: thanks
[08:20] <lifeless> mvo: what was the findconflicts outcome ?
[08:21] <mvo> lifeless: its a bit strange, it hasn't spamed^Wmailed me anymore, either its fixed now or so broken that its not even crying anymore
[08:23] <lifeless> mvo: the code is out btw
[08:23] <mvo> lifeless: excellent, congrats!
[08:24] <mvo> I saw the mail this morning
[08:24] <lifeless> mvo: future changes please shove up a branch and use the lp merge request stuff
[08:24] <lifeless> so that I can pull them into trunk
[08:24] <mvo> lifeless: ok, will do
[08:24] <lifeless> [this is separate from getting it onto macaroni - keep doing that as you ar]
[08:24] <lifeless> *are*
[08:26] <lifeless> mvo: should I create a conflictchecker team ?
[08:27] <mvo> lifeless: sounds like a good idea to me (or conflictchecker-hackers or so)
[08:27] <lifeless> k will do
[08:39] <RAOF> seb128: Re bug #255621 - xdg-open was detecting a gnome environment by GNOME_DESKTOP_SESSION_ID, which seems to be no longer set by gnome-session.  For me, it seems DESKTOP_SESSION=gnome is being set; is this a safe thing to check for?
[08:40] <seb128> RAOF: http://bugzilla.gnome.org/show_bug.cgi?id=542880
[08:41] <RAOF> Aha.  You're obviously on top of that, then.
[09:09] <seb128> is there any known issue with the new nvidia binary drivers?
[09:10] <seb128> bug #255461 states that gnome-panel crashes when using "177"
[09:13] <seb128> pitti: https://bugs.edge.launchpad.net/ubuntu/+source/gnome-applets/+bug/255573, is there any reason apport doesn't remove the coredump when marking duplicates?
[09:14] <RAOF> seb128: 255461 isn't a general crash; I'm using nvidia-glx-177, and gnome panel works just fine.
[09:17] <pitti> seb128: that sounds like a bug
[09:17] <seb128> pitti: same on https://bugs.edge.launchpad.net/ubuntu/+source/gnome-applets/+bug/255572
[09:17] <soren> Has MoM been switched off or is she malfunctioning?
[09:17] <mvo> seb128: same for me
[09:17] <mvo> soren: might be malfunctioning, I can have a look
[09:17] <seb128> mvo: works or doesn't work for you?
[09:17] <mvo> seb128: sorry, work for me with -177
[09:18] <soren> mvo: Cool. Last update seems to have been on August 1st.
[09:18] <seb128> mvo: ok, thanks
[09:19] <pitti> seb128: hm, it's also supposed to remove the private tag
[09:19] <mvo> soren: yep, mom is unhappy, I will see what I can do about it
[09:19] <seb128> mvo, pitti: http://bugzilla.gnome.org/show_bug.cgi?id=545828, if you could comment to say what you think about the feature, if it does what we need and if you think we would use that rather than update-notifier
[09:19] <pitti> seb128: the code is there
[09:19] <pitti> seb128: sure, will do
[09:19] <seb128> pitti: ok, should I open a bug about the duplicate issue?
[09:20] <pitti> seb128: if you want, but I'm investigating it right now
[09:20] <pitti> thekorn: I am using this:
[09:20] <pitti>         bug.attachments.remove(
[09:20] <pitti>             func=lambda a: re.match('^(CoreDump.gz$|Stacktrace.txt|ThreadStacktrace.txt|\
[09:20] <pitti> Dependencies.txt$|ProcMaps.txt$|ProcStatus.txt$|Registers.txt$|\
[09:20] <pitti> Disassembly.txt$)', a.lp_filename))
[09:20] <seb128> pitti: upstream closed the bug as NOTGNOME first, but it looks like opensuse are working on using apport so they reopened the bug, they would like to know what the fedora plans are too, if you are in touch with somebody from fedora who could comment about that
[09:20] <pitti> thekorn: has the API changed in that regard?
[09:25] <thekorn> pitti, hmm, I'm sure the API did not change there,
[09:25] <thekorn> this shuold work this way,
[09:25] <thekorn> will have a look at it in a bit
[09:26] <thekorn> what exactly is not working, are no attachments removed?
[09:27] <seb128> thekorn: https://bugs.edge.launchpad.net/ubuntu/+source/gnome-applets/+bug/255572 for example
[09:31] <pitti> seb128: commented and CC'ed
[09:31] <seb128> pitti: thank you
[09:32] <pitti> thekorn: apparently not; I play with it locally here
[09:33] <seb128> I let the coredump on those bugs so you guys can use that for testing
[09:33] <pitti> thanks
[09:33] <thekorn> ok, I will have a look at this in a few
[09:34] <pitti> thekorn: let me finish my local test and write a reproducer
[09:34] <mdz> both of my Intrepid systems have an empty /var/log/kern.log since the upgrade
[09:34] <thekorn> ok
[09:34] <pitti> thekorn: I'm pretty sure that the code is run, since the same function first deletes attachments and then marks the bug as a dup (and the latter works)
[09:35] <pitti> mdz: confirming; /var/log/dmesg is there, but kern.log doesn't work
[09:35] <mdz> pitti: something wrong with klogd perhaps?
[09:35] <pitti> seb128: sorry for the bug noise, I have to undup the bug to play with it; will re-dup afterwards
[09:35] <seb128> pitti: that's alright
[09:36] <mvo> soren: should be running again (but will take a bit to complete, it needs to do some catchup). you don't happen to know about network speed slowdowns in the intrepid kvm? for me kvm in intrepid gives me only ~30k download speed (compared to ~700k with qemu)
[09:36] <dholbach> james_w: congratulations! :)
[09:36] <pitti> mdz: hm, "sudo tail -f /proc/kmsg" doesn't report anything either (tried with some modprobe)
[09:37] <pitti> itz kernel bug?
[09:37] <mvo> james_w: congrats!
[09:37] <mdz> pitti: filed as bug 255635
[09:38] <Mithrandir> why do we have /etc/.java, at least in hardy?
[09:38] <soren> mvo: Which nic are you emulating?
[09:38] <mdz> pitti: kmsg was working earlier in the cycle, I used it for debugging bug 251223
[09:38] <soren> mvo: Thanks for fixing MoM by the way.
[09:39] <mvo> soren: the default one (not sure which one that is)
[09:39] <mdz> pitti: is kernel.printk set correctly? I can never remember which way the numbers work
[09:39] <soren> mvo: That would be the realtek one.
[09:39] <pitti> mdz: neither can I :(
[09:39] <mvo> soren: should I just try a different one?
[09:39] <pitti> mdz: but 4 4 1 7 sounds familiar
[09:40] <mdz> pitti: I noticed recently that sysrq+[1-9] didn't seem to work, I wonder if it's related
[09:40] <soren> mvo: It couldn't hurt. Either pass "model=virtio" to the first "-nic" on the command line, or set "<model type='virtio'/>" in the interface definition in the domain definition.
[09:40] <soren> (depending on whether you're using libvirt or not)
[09:41] <mdz> pitti: did you remember to stop klogd before your tail -f /proc/kmsg test?
[09:41] <lool> Mithrandir: Urgh
[09:41] <lool> Mithrandir: Looking at my dpkg.log, it seems to come from java-common
[09:41] <pitti> mdz: yes, I did
[09:42] <mdz> pitti: confirmed here, nothing in /proc/kmsg
[09:42]  * pitti follows up to the bug
[09:42] <mdz> pitti: already updated
[09:42] <pitti> argh, LP ate my comment
[09:43] <mdz> pitti: was it because I moved it to a new package (which bizarrely changes the URL)?
[09:43] <pitti> yes, I got an error message
[09:44] <mdz> pitti: going back in the firefox history retrieves lost input fields surprisingly often
[09:44] <pitti> and alt+left then didn't remember the text contents
[09:45] <lool> Mithrandir: I also have sun-java6* upgraded in the same minute, so they could also be at fault (I checked the creation time of /etc/.java)
[09:46] <tjaalton> mdz: please attach /var/log/Xorg.0.log to 255008, thanks
[09:46] <Mithrandir> lool: that's where it's come from; I'm wondering why somebody thought dotfiles in /etc was a good idea.
[09:46] <tjaalton> mdz: upstream wants that
[09:47] <tjaalton> mdz: also, you do have -1ubuntu3 of the xserver installed?
[09:47] <lool> Mithrandir: Well and the package failed to cleanup after itself too
[09:48] <lool> (as I have this empty /etc/.java now, but no sun-java6* installed)
[09:48] <Mithrandir> lool: ugh.
[09:49] <mvo> soren: ohhhh - that looks *much* better, in fact, I'm getting 11mb peek to my local proxy now *sweet*
[09:49] <mvo> soren: is this available in hardy too? can we make it default please :)
[09:50] <soren> mvo: It is. :)
[09:50] <soren> mvo: Both available and the default :)
[09:50] <soren> mvo: If you choose Ubuntu Hardy as the OS you're installing in virt-manager, it chooses virtio_net automatically.
[09:51] <mdz> bug 255008
[09:51] <mvo> soren: hm,  for the -nice user too? I have the latest kvm here and before I added "model=virtio" I got really bad throughput (basicly I just ran "kvm image.qcow2")
[09:52] <soren> mvo: Oh, no, not if you run kvm like that.
[09:52] <mvo> soren: ok, so its default in libvirt but not on the commandline kvm?
[09:52] <soren> mvo: The only operating system that supported it at Hardy's release was Hardy.
[09:53] <mdz> tjaalton: sorry it's almost 8M, due to bug 247195
[09:53] <mdz> tjaalton: but I have attached it now
[09:53] <mvo> soren: for virtio? I see. that is a problem :) will the hardy kvm with virtio work with a intrepid guest? or is that not possible?
[09:53] <soren> mvo: I think perhaps a few others are starting to catch up, but it'll never be as ubiquitisly(sp?) supported as the realtek adapter.
[09:53] <soren> mvo: That should work fine.
[09:54] <tjaalton> mdz: heh
[09:54] <mvo> soren: thanks for your explaination! that is fine then, I'm only concerned with ubuntu systems for my current project, so I will just add it to my standard kvm option, thanks again for your help
[09:54] <soren> mvo: The interface has an ABI check, so it doesn't work, it will just come up without a NIC. It won't just break spectacularly.
[09:55] <soren> mvo: No problem :)
[09:55] <seb128> tjaalton: is there any know video bustage on intel in intrepid? the evolution composer has refresh issues and artefact since I upgraded today (I didn't upgrade for a few days before that)
[09:55] <tjaalton> mdz: I've filtered the ACPI errors and will attach that too
[09:55] <tjaalton> seb128: not that I know of, my i965 works mostly ok
[09:56] <seb128> hum, ok, using compiz?
[09:56] <tjaalton> but then again I don't use evolution
[09:56] <seb128> is there any change this week that could have created issues?
[09:56] <mdz> I'm seeing a lot of corruption with nvidia on intrepid on my desktop
[09:56] <mdz> e.g. switching tabs in firefox doesn't redraw half the window
[09:56] <thekorn> pitti, I think I found the issue
[09:57] <pitti> thekorn: fun; originally it had 4 attachments; the first run removed 2, the second removed 1
[09:57] <pitti> thekorn: now just CoreDump.gz is left
[09:57]  * pitti runs it a third time
[09:57] <thekorn> pitti, and whe you run it again, Coredump will be removed
[09:57] <pitti> thekorn: maybe the $ doesn't match reliably any more or so?
[09:57] <pitti> thekorn: right, worked now
[09:57] <tjaalton> funny, I don't have evolution installed
[09:58] <thekorn> no, attachment.remove is not working correctly for many matches
[09:58] <pitti> thekorn: do you need my reproducer script? (we have some more bugs to try this with)
[09:58] <thekorn> so it only removes the first match
[09:58] <tjaalton> seb128: no updates to the intel driver. do you use compiz? does metacity have the same problem?
[09:58] <thekorn> pitti, no, I'm fixing it right now
[09:58] <pitti> thekorn: awesome, thanks!
[09:58] <pitti> seb128: I'll ask bdmurray to generate a list of all bugs with Coredumps, then I'll run a script for mass-cleanup
[09:58] <seb128> tjaalton: I do use compiz but this one didn't change in the update
[09:58] <seb128> pitti: thanks
[10:03] <pitti> seb128: btw, I'm really impressed with the current fakechroot; intrepid chroots have updated without a hitch for weeks...
[10:03] <seb128> that's good indeed ;-)
[10:04] <pitti> by now that should have compensated for the 6 hours I spent on debugging and fixing  fakechroot, I guess :)
[10:07] <tjaalton> mdz: would you attach xorg.conf as well, thanks
[10:09] <mdz> tjaalton: it's already in a comment in the bug
[10:09] <tjaalton> mdz: only a part of it
[10:10] <mdz> tjaalton: https://bugs.edge.launchpad.net/ubuntu/+source/xorg-server/+bug/255008/comments/8
[10:10] <mdz> tjaalton: there is nothing else but Driver "nvidia".  I will attach it though
[10:10] <tjaalton> mdz: yes, thanks.
[10:10] <mdz> tjaalton: done
[10:11] <tjaalton> seb128: I can see the corruption too, with metacity
[10:12] <seb128> tjaalton: good ;-)
[10:12] <thekorn> pitti, fix pushed to the .main branch
[10:12] <pitti> thekorn: rock, thanks!
[10:12] <seb128> brb
[10:13] <tjaalton> seb128: but the driver has not been updated in a while, and I doubt it's a problem in the server, so.. :)
[10:13] <pitti> thekorn: curious fix
[10:13] <seb128> tjaalton: you are blaming it on GNOME aren't you ;-)
[10:13] <tjaalton> seb128: well, you said it :)
[10:14] <pitti> seb128, thekorn: retracers restarted with the fixed p-lp-bugs
[10:14] <pitti> oh, seb is offline
[10:14] <thekorn> pitti, right, but it makes sense, because LPAttachments.filter() returns a generator
[10:15] <pitti> thekorn: ah, the problem isn't the set, but that it returns an iterator instead of a static set?
[10:15] <pitti> so that you can't use things like "in"?
[10:18] <thekorn> pitti, the problem was that that the length of the attachment list was changed durring a run of a loop, which was/is not working correctly
[10:19] <pitti> aah
[10:22] <thekorn> pitti, I just went through apports launchpad.py, defining the download location for attachments changed a bit, http://paste.ubuntu.com/35044/
[10:23] <pitti> thekorn: hm, so that still works, but is deprecated?
[10:23] <pitti> thekorn: since apparently it can download attachments with the current version
[10:24] <seb128> tjaalton: alright, the composer issue is due to the gtk update
[10:24] <tjaalton> seb128: heh :)
[10:25] <thekorn> pitti, yes it is working, but it does not download the files to your tmpdir, but to a default location
[10:26] <pitti> thekorn: ah, where is that?
[10:27] <thekorn> let me check
[10:27] <thekorn> ~/.bughelper/attachments-cache
[10:30] <pitti> thekorn: I added the missing ), testing now; it doesn't seem to have downloaded any, /me peeks
[10:31] <pitti> ah, PEBCAK
[10:56]  * hunger is waiting for debian to update its git-core debs for the security update that was released so that he can bug people in #ubuntu-devel to sync the debs.
[11:01] <persia> hunger: Why do you need to bug people?  Just file a bug and subscribe the appropriate parties.
[11:02] <hunger> persia: Mostly to find out who the appropriate party is. I don't want to just assign everything to pitti;-)
[11:02] <hunger> And of course bugging people gets results faster.
[11:03] <persia> hunger: Except where bugging people annoys them and they have reduced motivation.
[11:03] <persia> Anyway, for a security update, I'd recommend subscribing the security team.  For a sync of a package in main (such as git-core), I'd recommend subscribing the ubuntu-main-sponsors.
[11:04] <hunger> persia: Well, using LP annoys me;-)
[11:04] <persia> hunger: Well, someone needs to put it in LP.  Note that this can be just sending email.
[11:12] <pitti> hunger: just use requestsync, that will DTRT and subscribe ubuntu-archive
[11:12] <pitti> and you don't need to get in direct contact with LP :)
[11:41] <cjwatson> kirkland: so what was that grub patch?
[11:44] <asac> NM 0.7 uploaded :/
[11:44] <lool> Why ":/"?  It should be \o/
[11:44] <asac> yeah.
[11:45] <asac> \:/ ;)
[11:45] <ogra> ion_, do you happen to be around ?
[11:45] <seb128> asac: good job ;-)
[11:45]  * ogra pats asac on the back
[11:45] <asac> tell that to me when you still have network ;)
[11:48] <cjwatson> asac: woo
[11:52] <Riddell> mvo: did you get a chance to look at my compiz patch?
[11:52] <mvo> Riddell: still not :( but I will do it today, I plan a compiz update as well
[11:53] <asac> Riddell: so knetworkmanager probably should be uploaded too
[11:54] <Riddell> asac: mm, ok
[11:58]  * ogra scratches his head about the overcomplicated compcache implementation 
[12:06] <Keybuk> this whole "no X server" bug ceased to be funny long ago
[12:06] <ogra> Keybuk, ECONTXT ?
[12:07] <Keybuk> ogra: no X server on boot for Dell Latitude D420/430
[12:07] <ogra> ah
[12:13] <tjaalton> Keybuk: does it have intel gfx?
[12:15] <Keybuk> tjaalton: yes
[12:15] <tjaalton> Keybuk: ok, try without usplash
[12:15] <Keybuk> tjaalton: I *know* that works, I was the one that discovered the "no splash" trick
[12:15] <tjaalton> there is a patch upstream which might help
[12:15] <Keybuk> that's not a fix though ;)
[12:15] <tjaalton> heh
[12:17] <tjaalton> I'll merge 2.4.0 and add that patch (and others from the stable branch) and see if I can reproduce the problem anymore
[12:20] <YokoZar> slangasek: what should I name a file I put into the new /etc/sysctl.d ?  I assume the format is just the same as an entry in sysctl.conf, but I haven't found a naming standard yet.
[12:33] <ogra> persia, any idea about that java issue ?
[12:34] <ogra> its definately not LTSP
[12:34] <ogra> so the duplication is the wrong way round
[12:35] <persia> Erm.  Oops
[12:35] <ogra> (since his mp3's and the login/logout sounds work fine)
[12:36] <persia> Right.  Seems to be a not uncommon issue with some JAVA releases.  On the other hand, it ought be using ALSA post-Java 1.5
[12:37] <persia> Anyway, it's clearly an issue with either MALTED or Java, and not LTSP as such.
[12:37] <persia> Sorry for the reverse duplication.
[12:52] <zul> pitti: yes I saw it, trying to fix it but not sure how kirkland is also looking at it
[13:34] <Mez> argh, we've taken the dash stuff havent we? we dont install bash as part of essential anymore?
[13:36] <cjwatson> bash is still essential, although /bin/sh points to dash
[13:36] <cjwatson> there is no plan to remove bash from essential
[13:36] <cjwatson> it is still the default user shell
[13:36] <persia> That has been true for quite a while now.
[13:38] <pitti> zul: thanks (and good morning!)
[13:38] <zul> pitti: np
[13:38] <cjwatson> Mez: https://wiki.ubuntu.com/DashAsBinSh
[13:38] <Mez> configure: error: cannot run /bin/bash ../config.sub
[13:39] <Mez> I guess it was the error with config.sub ;) not bash
[13:46] <TheMuso> Keybuk: Question for you re udev, symlinks and link priority. I'm trying to get a /dev/disk/by-uuid symlink for a device mapper filesystem to have a higher link priority than the same filesystem UUID which originally points to a /dev/sd device. I notice through udeadm info that the UUID symlink for the sd device has no link priority. I've tried various values, but the symlink doesn't appear to be replaced.
[13:46] <TheMuso> Keybuk: My rule is after persistant-storage in terms of numbering, i.e in the 6x range.
[13:46] <Keybuk> it'll have a zero link priority by default
[13:47] <TheMuso> Keybuk: So, am I to assume that a positive plink priority should overwrite it?
[13:47] <Keybuk> you need to change the 65-dmsetup.rules file
[13:47] <Keybuk> OPTIONS="link_priority=-100"
[13:47] <Keybuk> becomes something > 0
[13:47] <Keybuk> and you need to fight in a tub of jello with kees who says that DM devices need to be *lower* priority
[13:47] <TheMuso> My rule runs after dmsetup, and is to do with dmraid and readjusting UUID symlinks for filesystems on RAID1 devices.
[13:47] <Keybuk> I bet you're having DM-RAID vs. LVM issues
[13:47] <Keybuk> where one needs to be higher, the other lower
[13:48] <TheMuso> Keybuk: More like dmraid vs real hard disk partition/filesystem issues.
[13:48] <TheMuso> For RAID1 setups.
[13:48] <Keybuk> right
[13:48] <Keybuk> real partition looks like the dm-raid partition
[13:48] <Keybuk> and you want dm-raid to win
[13:48] <TheMuso> Yep.
[13:48] <TheMuso> Exactly./
[13:48] <Keybuk> whereas in other devmapper situations, you want the real partition to win
[13:48] <TheMuso> Yep.
[13:49] <Keybuk> do you have something that matches dm-raid only?
[13:49] <Keybuk> ENV{DM_TARGET_TYPES}=="*dm-raid*", OPTIONS="link_priority=100"
[13:49] <Keybuk> something like that maybe?
[13:49] <Keybuk> *(note no - on the 100)*
[13:49] <TheMuso> I have the UUID base, which is DMRAID-*. I also have KERNEL=="dm-*
[13:49] <TheMuso> As oposed to md-*
[13:50] <Keybuk> dm-* is all devmapper devices
[13:50] <Keybuk> so that'll break LVM
[13:50] <Keybuk> and cryptsetup
[13:50] <TheMuso> Keybuk: Hrm you sure? Checking a real devmapper device on another system here, it shows as md- for the kernel value.
[13:51] <Keybuk> md is definitely mdadm :)
[13:51] <Keybuk> dm is devmapper
[13:51] <Keybuk> LVM devices show up as dm-999
[13:51] <TheMuso> Keybuk: sorry  you are correct
[13:51] <TheMuso> So there is the UUID then.
[13:51] <TheMuso> DM_UUID=DMRAID-blah
[13:52] <Keybuk> yeah
[13:52] <Keybuk> is there nothing in the target types we could match?
[13:52] <Keybuk> that's how we do it for LVM
[13:53] <TheMuso> DM_TARGET_TYPES=linear
[13:54] <TheMuso> thats for a dmraid device, which also is used for LVM it seems.
[13:58] <Keybuk> ah right
[13:58] <Keybuk> DM_UUID seems reasonable then
[13:58] <Keybuk> the bottom of debian/dmsetup.udev could look like
[13:58] <Keybuk> IMPORT{program}="vol_id --export $tempnode"
[13:58] <Keybuk> OPTIONS="link_priority=-100"
[13:58] <Keybuk> ENV{DM_TARGET_TYPES}=="*snapshot-origin*", OPTIONS="link_priority=-90"
[13:58] <Keybuk> ENV{DM_UUID}=="DMRAID-*", OPTIONS="link_priority=100"
[13:58] <Keybuk> then the bits to make the symlinks
[13:59] <TheMuso> Keybuk: Ok thanks, I'll give that a shot.
[13:59] <TheMuso> Keybuk: Also, any idea why Debian never packaged/enabled dmeventd in devmapper?
[14:00] <ion_> ogra: I am now. I’m going to eat, but i’ll read the scrollback afterwards.
[14:02] <tjaalton> Keybuk: would you test the new intel driver? seems to work for me
[14:02] <tjaalton> Keybuk: I've got i386 deb ready
[14:02] <ogra> ion_, i'm a bit confused how the compcache script as we have it now is supposed to work ... we only have three usecases from the distro side which all include the initramfs being build on a different system than the target system ...
[14:03] <Keybuk> tjaalton: url?
[14:04] <ogra> ion_, your code seems to use /proc/meminfo at build time thats not going to work at all
[14:04] <tjaalton> Keybuk: http://users.tkk.fi/~tjaalton/dpkg/xserver-xorg-video-intel_2.4.0-1ubuntu1_i386.deb
[14:04] <TheMuso> Keybuk: That change to 65-dmsetup.rules works, however is that likely to be a clash/problem with LVM?
[14:04] <Keybuk> TheMuso: shouldn't be since you only match dmraid
[14:05] <TheMuso> Keybuk: Right.
[14:05] <TheMuso> I'll test it tomorrow anyway.
[14:09] <TheMuso> Now to write a udev rule to bring up dmraid arrays automatically, with the help of a wrapper script to prevent degraded arrays being brought up unless the user specifically asks for them to be.
[14:18] <Keybuk> tjaalton: still black screen
[14:20] <seb128> jdstrand: hey, so I pinged evolution's upstream about your calendar issue, they are interest in some details
[14:20] <seb128> - do you get an error on the command line when you create a new meeting in the calendar
[14:21] <seb128> - is the red line which indicates the current time in the day view correct?
[14:21] <jdstrand> seb128: let me see
[14:21] <jdstrand> seb128: red line is correct
[14:22] <tjaalton> Keybuk: bah
[14:22] <jdstrand> seb128: you are not going to believe this-- it is working now
[14:22] <seb128> jdstrand: bah :-(
[14:23] <jdstrand> totally bah :(
[14:23] <jdstrand> seb128: I did logout and back in since we talked
[14:24] <jdstrand> seb128: I wonder if there was an update where I needed to restart my session (perhaps from -updates?)
[14:24] <seb128> jdstrand: ok, if you get the issue again note if there is some error in .xsession-errors when creating something on the calendar and if the line is correctly placed
[14:24] <jdstrand> seb128: I shall. this bug is odd...
[14:24] <seb128> jdstrand: you tried on a stock user no?
[14:24] <seb128> that was a new session?
[14:24] <jdstrand> seb128: just now? no-- but when we filed-- yes
[14:25] <seb128> right, and you had the issue
[14:25] <jdstrand> seb128: looks like I may have rebooted in the meantime too
[14:25] <seb128> so that's not likely an upgrade and session restart
[14:25] <jdstrand> seb128: good point
[14:25] <jdstrand> odd
[14:25] <seb128> well, if the other user you try was a fresh login that's not likely an upgrade issue
[14:25] <seb128> indeed
[14:26] <tjaalton> Keybuk: right, I got a blank screen after booting .26 the second time
[14:27] <ion_> ogra: Nope, it writes a piece of sh code that uses /proc/meminfo to a file in initramfs, which is then evaluated when the initramfs is running.
[14:27] <ogra> no, thats sitting in the hook
[14:28] <ogra> nozt in init-top
[14:28] <ion_> ogra: Huh. I’ll take a new look at the code, a moment...
[14:29]  * ogra really whished we didnt have such complicated code in tehre 
[14:29] <ogra> four lines and a udev rule would have sufficed
[14:30] <ion_> ogra: The code seems allright to me. The hook writes '$(blahblah /proc/meminfo)' to $DESTDIR/scripts/init-top/compcache
[14:31] <ogra> no it doesnt
[14:31] <ogra> all the /proc/meminfor code sits in the hook
[14:31] <ion_> ogra: Note the $( being escaped: mem_total="\$(sed ...
[14:31] <ogra> but before the cat >"$DESTDIR"/scripts/init-top/compcache <<EOF
[14:32] <ion_> Also the kbytes calculation is escaped: kbytes="\$((...
[14:32] <ogra> yes, i see that
[14:32] <ogra> but its still only read at buildtime
[14:32] <ogra> which will give you only the inof of the buildd
[14:32] <ogra> *info
[14:34] <ion_> ogra: % zcat /boot/initrd.img-$(uname -r) | strings | grep compcache_size_kbytes
[14:34] <ion_> modprobe -Q --ignore-install compcache compcache_size_kbytes="$(($(sed -nre 's/^MemTotal:\s*([0-9]+) kB$/\1/p' /proc/meminfo) * 50 / 100))"
[14:35] <ogra> hmm
[14:35] <ogra> right, thanks for clearifying ... understood now ... but i still dont like the complexity :/
[14:36] <tjaalton> Keybuk: it always works with the hardy kernel though..
[14:37] <ion_> ogra: It’s not really *that* complex IMO. And i really want the possibility to set a percentage. That allows me to use the same configuration on all my boxes, even though the low-end one has 64 MiB of RAM and the high-end one has a gigabyte.
[14:37] <Keybuk> tjaalton: the old version always worked with the hardy kernel too
[14:37] <tjaalton> Keybuk: yep
[14:38] <ogra> ion_, its more complex than just go with upstream and not wrap a scrpt around it ...
[14:38] <ogra> since with upstream it wuld be (as i said above) a four line init-top sctipt and a hook installing the udev rule
[14:40] <vargadanis> hi
[14:41] <vargadanis> bye ^_^
[14:41]  * vargadanis just read the topic
[14:41] <Keybuk> tjaalton: I just noticed an interesting difference between kernels
[14:41] <Keybuk> let me try something
[14:42] <ion_> Do others think /usr/share/initramfs-tools/hooks/compcache is too complex? There are a lot of places one could simplify/shorten code while reducing user-friendliness, and i sincerely don’t think it should be done with that one.
[14:46] <Keybuk> ooh
[14:46]  * ogra would like to point out to "the others" that the alternative would be a one liner: modprobe -Q --ignore-install compcache compcache_size_kbytes=$COMPCACHE_SIZE 
[14:46] <Keybuk> I just fixed my own bug
[14:46] <Keybuk> pitti: are you still having the X issue on your 430 when running the 26 kernel?
[14:46] <ogra> and a hoook putting up the udev rule
[14:46] <ogra> Keybuk, i do
[14:46] <pitti> Keybuk: what is the X issue?
[14:47] <Keybuk> pitti: booting with splash, no X
[14:47] <BenC> pitti: Do you think, even without the package-groups, that we could remove apt's exception for linux-image-* now that we have a legitimate fallback for kernels?
[14:47] <pitti> Keybuk: usplash is broken, and computer becomes slow without pci=nomsi, otherwise current kernel works very well
[14:47] <Keybuk> add uvesafb to /etc/modprobe.d/blacklist-framebuffer
[14:47] <Keybuk> and update-initramfs -u
[14:47] <Keybuk> seems someone renamed the framebuffer module ;)
[14:47] <BenC> Keybuk: no, it's a different module :P
[14:48] <pitti> Keybuk: ah, so that's why adding it to /etc/modprobe.d/blacklist only worked for starting usplash in the running system?
[14:48] <BenC> Keybuk: but it is a bug that not having v86d installed makes uvesafb break the console, and I'm looking into it
[14:48] <pitti> Keybuk: I had assumed that /etc/modprobe.d/ blacklists would automatically apply to the initramfs, too
[14:48] <Keybuk> pitti: not unless you update the initramfs ;)
[14:48] <pitti> Keybuk: oh, hang on, bl-framebuffer or bl shouldn't make a difference
[14:49] <pitti> Keybuk: hm, I think I did try that
[14:49] <pitti> Keybuk: I'll try again
[14:49] <BenC> blacklist might not work
[14:49] <pitti> but I think it didn't work last time
[14:49] <BenC> I think usplash force loads it anyway
[14:49] <BenC> but it should only do that if you have a vga= or video= line in your cmdline
[14:52]  * ogra tries Keybuk's suggestion
[14:56] <ogra> nope
[14:57] <ogra> grrr, why does compiz not maximize as it should
[14:59] <ogra> oh, bceause my system decides that compiz isnt good for me after a reboot :( so it auto switches me to metacity
[15:01] <ogra> Keybuk, since you assumed the module was renamed, does that mean you dont have vesafb in your blacklist ?
[15:02] <Keybuk> ogra: vesafb is in the blacklist by defualt
[15:02] <ogra> i know
[15:02] <pitti> seb128: hm, so it doesn't look as pretty as pidgin, but by and large it feels the same
[15:02] <ogra> but you assumed it was renamed above ... so i was wondering if you just added a u in front :)
[15:02] <pitti> seb128: ICQ and jabber work
[15:03] <seb128> pitti: right, and it'll follow GNOME schedule and has responsive upstream which will be happy to help use if we ship their software
[15:03] <pitti> seb128: it just cannot figure out the realname of one of my ICQ contacts (user info doesn't help either), otherwise it works well enough
[15:03] <tedg> I've found IRC to be lacking in Empathy.  It's usually the thing that frustrates me and pushes me back to Pidgin.
[15:04] <tedg> Apparently there's an SoC project for it though.
[15:04] <pitti> tedg: heh, I found IRC frustrating in pidgin, and it's the thing that brings me back to xchat or weechat :)
[15:04] <seb128> tedg: you really do IRC in an IM client?
[15:04] <Keybuk> tedg: xchat-gnome FTW!
[15:04] <ogra> xchat ftw !
[15:04] <seb128> xchat-gnome is way better
[15:04] <pitti> weechat FTW!
[15:04] <mdz> BenC: it gets loaded unconditionally
[15:04] <Keybuk> ogra: I added an extra line
[15:04] <tedg> Yes, I do do IRC in Pidgin/Empathy.
[15:04] <Keybuk> mdz: the vesa fb module?  no it doesn't
[15:04] <ogra> Keybuk, yes, understood now ... well, didnt work here
[15:04] <seb128> tedg: IRC is different enough to have specialized softwares
[15:04] <pitti> BenC: I have it loaded, too (uvesafb), and no video/vga kopt
[15:04] <mdz> Keybuk: uvesafb does
[15:05] <Keybuk> mdz: LoC?
[15:05] <tedg> I've not had any feature that I think is missing.
[15:05] <pitti> tedg: pidgin's usage of screen real estate is too wasteful for my IRC needs
[15:05]  * ogra would also like to know why usplash jumps between bounce and progress mode 
[15:05] <pedro_> tedg: for IRC try installing telepathy-idle
[15:05] <tedg> I find the XChat GUI to be too cluttered.
[15:05] <pitti> it's ok for personal private conversations, where you close the windows again, but having them open all the time, as for IRC, is a pain IMHO
[15:06] <mdz> Keybuk: LoC?
[15:06] <Keybuk> mdz: line of code where it gets loaded
[15:06] <tedg> pedro_: Yeah, I was using telepathy-idle, even patched it some.  But it still seems broken.  Drops off, doesn't name the rooms right (guessing by subject is fun).
[15:06] <sladen> ogra: unknown; boot; fsck unknown, fsck progress, unknown; boot progress?
[15:06] <mdz> Keybuk: /usr/share/initramfs-tools/hooks/kernelextras:36
[15:06] <Robot101> tedg: what's broken? where are the bugs? :(
[15:06] <Keybuk> mdz: err, that's a function?  doesn't mention uvesafb
[15:07] <Keybuk> oh
[15:07] <Keybuk> sorry
[15:07] <mdz> Keybuk: read the function, then look in /lib/modules/`uname -r`/initrd
[15:07] <Keybuk> it iterates /initrd
[15:07] <ogra> sladen, hmm, it looks quite weird but that could be it
[15:07] <Keybuk> it looks very like another function I'm used to reading
[15:07] <Keybuk> force_load() adds the module name to conf/modules
[15:07] <tedg> pitti: I already have the screen real estate used for Jabber chats, etc.
[15:07] <Keybuk> which is iterated by load_modules() in the initramfs
[15:08] <Keybuk> which calls modprobe on it
[15:08] <Keybuk> which means the blacklist applies
[15:08] <tedg> Robot101: I've filled the new ones in the telepathy repository.  Most are known and have been on the telepathy devel list.
[15:08] <pitti> tedg: in particular, there doesn't seem to be a way to make the font size smaller, and not waste so much space at the window bottom
[15:08] <BenC> pitti: did you see my question about apt linux-image-* exceptions to autoremove?
[15:08] <mdz> Keybuk: that's good news
[15:08] <BenC> mdz, Keybuk: Ok, I'll take a look at that
[15:08] <mdz> but it isn't in the blacklist
[15:08] <pitti> BenC: right, sorry, was in the meeting until now
[15:08] <Keybuk> mdz: no, that's what I was saying
[15:08] <Keybuk> the framebuffer blacklist is manually maintained
[15:08] <Keybuk> and seems to be lacking some of the newer framebuffer modules
[15:09] <Keybuk> notably uvesafb
[15:09] <mdz> BenC: why is uvesafb treated differently than all the other framebuffer modules?
[15:09] <Keybuk> obviously it shouldn't be attempted to be loaded in the first place, since we blacklist them :p
[15:09] <pitti> BenC: I wouldn't kill all non-default kernels automatically, but since we don't do autoremoval by default, I think it's fine to drop the exception
[15:09] <BenC> mdz: because vesafb was, and uvesafb is supposed to supercede vesafb
[15:09] <pitti> BenC: e. g. I needed to run the hardy kernel for quite some time
[15:09] <mdz> Keybuk: it wouldn't matter if it were blacklisted or not, if we didn't load it unconditionally
[15:09] <ogra> for me it doesnt fix an issue even with only fbcon loaded
[15:09] <tedg> pitti: So you're saying that you're not waiting for the Webkit integration to have animated messages from individual speakers in a chat ;)
[15:09] <Keybuk> BenC: but vesafb was also blacklisted by default
[15:09] <Keybuk> mdz: agree
[15:09] <BenC> Keybuk: really?
[15:09] <pitti> tedg: lol
[15:10] <mdz> so rather than force_loading it and blacklisting it, how about just not loading it?
[15:10] <Keybuk> grep vesafb /etc/modprobe.d/blacklist-framebuffer
[15:10] <ogra> BenC, t s here
[15:10] <ogra> *it
[15:10] <BenC> vesafb was force loaded before as well
[15:10] <BenC> If someone can boot into hardy and see if it is loaded or not, that would help
[15:10] <Keybuk> BenC: yes, it's in that directory
[15:10] <Keybuk> but since it's also in the blacklist
[15:11] <Keybuk> being in that directory was kinda pointless ;)
[15:11]  * ogra de-blacklists it and tests
[15:11] <BenC> Keybuk: no, blacklist is ignored when usplash loads fb modules
[15:11] <Keybuk> quest scott% ls /lib/modules/2.6.24-20-generic/initrd
[15:11] <Keybuk> vesafb.ko
[15:11] <Keybuk> quest scott% lsmod | grep vesa
[15:11] <Keybuk> zsh: done       lsmod |
[15:11] <Keybuk> zsh: exit 1     grep vesa
[15:11] <pitti> Keybuk: so still want me to try and blacklist uvesafb?
[15:11] <Keybuk> BenC: usplash doesn't load fb modules
[15:11] <Keybuk> the framebuffer initramfs script does deliberately force load it *if* you have vga=... on the command-line
[15:11] <BenC> Keybuk: I beg to differ...let me get the snippet
[15:11] <BenC> That's the script I'm thinking of
[15:12] <cjwatson> ion_: I think it'd be easier to read if you had the init-top script as a separate file that sources a configuration file, rather than substituting stuff into it at run-time
[15:12] <BenC> I for some reason though that was a usplash hook, but I could be wrong
[15:12] <Keybuk> the fact it has -Q there means it *won't* obey the blacklist
[15:12] <Keybuk> if it just did modprobe $FB it *would* obey the blacklist
[15:12] <Keybuk> don't look at me like that
[15:13] <BenC> Keybuk: uh, -Q is quiet
[15:13]  * Keybuk can't hear you
[15:13] <Keybuk> la la la la
[15:13] <Keybuk> actually, it's that MODPROBE_OPTIONS="-Qb" in init
[15:13] <BenC> Keybuk: -b means to honor the blacklist...so if it doesn't have that, it will load no matter what
[15:13] <Keybuk> (quiet and obey blacklist)
[15:13] <Keybuk> and specifying any option means modprobe ignores the default env var
[15:14] <Keybuk> so modprobe foo will use $MODPROBE_OPTIONS, which means it's the same as modprobe -Qb foo
[15:14] <cjwatson> things I have learned today: modprobe is crazy
[15:14] <ogra> yay
[15:14] <ogra> removing vesafb from the blacklist and adding uvesafb helps here
[15:14] <Keybuk> cjwatson: it's maintained by jon masters
[15:14] <Keybuk> he drives a miata, wears silly hats, and can't get over his ex
[15:14] <ogra> cjwatson, heh, you werent in the mobile bootspeed session in prague
[15:15] <ogra> you could have seen *intresting* things happening with modprobe
[15:15] <Keybuk> funnily enough, at least 2/3 of those items match different members of Canonical staff
[15:15] <Keybuk> but we don't have the full set in any one person
[15:15] <BenC> Keybuk: sounds like a job for HR
[15:15] <cjwatson> Keybuk: you're in good form today
[15:16] <ogra> holiday pending ?
[15:16] <Keybuk> heh, no
[15:17] <mdz> pitti: the guest session worked for me, but the mixer applet crashed on logout
[15:17]  * ogra wonders whats that that switches him back to metacity on each boot ...
[15:17] <jtisme> anyone know what 8.04  repository  kickstart is in
[15:18] <mdz> ogra: novell spies
[15:18] <ogra> haha
[15:18] <seb128> mdz: probably nothing specific to the guest session, bug #255554 maybe?
[15:18] <BenC> While we're on the topic of bugs...I really want my power button back on the top toolbar instead of that little green jogger guy
[15:18] <BenC> I hate him
[15:18] <ogra> BenC, ++
[15:18] <ogra> BenC, being worked out upstream
[15:18] <seb128> ogra: the new gnome-session does that, there is a gconf key you can set to compiz though
[15:18] <mdz> seb128: hard to tell, because it failed to write a crash report (it was 0 bytes).  it doesn't crash in my normal sessions though
[15:19] <Keybuk> seb128: that so doesn't work
[15:19] <ogra> seb128, hmm, so no auto love for users anymore ?
[15:19] <ogra> i would expect such a key to be set from the appearace applet btw
[15:19] <BenC> And for reboot/shutdown while logged in to actually DTRT
[15:19] <seb128> Keybuk: you set the wrong key
[15:19] <pitti> Keybuk, BenC: so, for the record, blacklisting uvesafb doesn't change a thing, still red-white stripes (yes, I updated initramfs)
[15:19] <Keybuk> seb128: I sat the one you told me to
[15:19] <seb128> Keybuk: edit the /desktop/gnome/session/default-session list
[15:19] <seb128> Keybuk: and I was wrong, it's in the same place but the next key in fact ;-)
[15:20] <BenC> pitti: try installing v86d and tell me if that fixes things
[15:20] <BenC> pitti: Just so I know the root cause
[15:20] <Keybuk> ahh
[15:20] <pitti> mdz: indeed, having a clean profile exposes quite a bunch of current gnome desktop bugs, such as the theme, and various other crashes
[15:20] <BenC> pitti: output from dmesg would help too, if you can blind capture it
[15:20] <pitti> BenC: I think I already tries all four combinations
[15:20] <seb128> pitti: what crashes?
[15:21] <pitti> seb128: random crashes with a fresh user profile (such as in the guest session)
[15:21] <pitti> seb128: haven't worried about them too much yet, somethign for post feature freeze
[15:21] <seb128> pitti: please report those using apport so we can get them fixed
[15:21] <mdz> pitti: I only had the red/write stripes if uvesafb was actually working (i.e. v86d installed)
[15:21] <cjwatson> jtisme: which bit of kickstart? the UI or the installer implementation?
[15:21] <seb128> pitti: the sooner reported the better
[15:21] <BenC> pitti: Should I upload apt without linux-image-* exceptions, or is there someone better to do that?
[15:21] <mdz> pitti: do you have a guess why the crash report wasn't written?
[15:21] <seb128> pitti: or it'll be late for next GNOME
[15:21] <pitti> BenC: I think I can boot blindly with ctrl+alt+f1 and typing my luks passphrase, and get dmesg, yes
[15:21] <jtisme> cjwatson, both please
[15:22] <pitti> BenC: mvo might want to keep it all in bzr, I don't know
[15:22] <cjwatson> jtisme: the former is the system-config-kickstart package, the latter is kickseed
[15:22] <ogra> pitti, try adding a u to vesafb in the blacklist-framebuffer file .... that works here
[15:22] <BenC> mvo: ^^
[15:22] <pitti> mdz: I reinstalled my box from alpha 3 and forgot to reenable apport manually
[15:22] <pitti> ogra: i did blacklist uvesafb
[15:22] <ogra> i.e. enabling vesafb, disabling uvesafb
[15:23] <pitti> sommer: so, unblacklist uvesafb and install v86d, then dmesg?
[15:23] <pitti> ogra: oh, ok
[15:23] <mvo> BenC: if you could point me to a patch, that would be nice, I like to upload stuff that is in sync with my bzr tree
[15:23] <BenC> pitti: No, dmesg without v86d installed
[15:23] <BenC> pitti: and with
[15:23] <stgraber> heh, what's happening to evolution ?? The new message window is extremely buggy here ...
[15:23] <jtisme> cjwatson, ok thanks cna find kickstart but not kickseed
[15:23] <mvo> BenC: this is just about removing the kernel from the autoremove blacklist?
[15:23] <cjwatson> jtisme: there's no "kickstart" package in the archive
[15:23] <pitti> BenC: and with uvesafb loaded? or not?
[15:23] <ogra> stgraber, for me its only slow
[15:24] <cjwatson> jtisme: you'll need 'apt-get source kickseed'. It's an installer component and you can't install those on normal systems
[15:24] <jtisme> cjwatson, ok thanks will look it over
[15:24] <BenC> mvo: just remove the whole NeverAutoRemove stanza in /etc/apt/apt.conf.d/01autoremove
[15:24] <ion_> cjwatson: ogra preferred the script that actually ends up in initramfs to be as simple as possible, so that there exists no percentage computation if the user isn’t using a percentage.
[15:24] <cjwatson> jtisme: anything particular you're interested in?
[15:25] <BenC> pitti: yeah, with it loading
[15:25] <BenC> pitti: (not blacklisted)
[15:25] <stgraber> ogra: http://www.stgraber.org/download/evo.png and each other character I type make it worse :)
[15:25] <jtisme> cjwatson, yes network installs
[15:25] <ogra> stgraber, looks more liek a font issue though
[15:25] <jtisme> cjwatson, on multiple machines etc.
[15:25] <mvo> BenC: ok, consider it done
[15:25] <BenC> mvo: thanks
[15:27] <mvo> BenC: should I upload just for this or is it ok to wait until some more changes come up? so the new fallback kernel stuff is there and working? that is excellent news \o/
[15:27] <kirkland> cjwatson: howdy, see https://bugs.launchpad.net/ubuntu/+source/grub-installer/+bug/33649
[15:27] <BenC> mvo: it's not urgent at all
[15:28] <BenC> mvo: but yes, the fallback kernel stuff is there
[15:28] <kirkland> cjwatson: kees gave it a once-over, and he thought it looked good--almost too good, surprisingly simple
[15:28] <kirkland> cjwatson: that one is to grub-installer, i think another with similar logic will be needed in grub-install
[15:29] <mdz> pitti: I definitely have apport enabled, but it wrote a 0-byte .crash file
[15:29] <kirkland> zul: you and pitti were talking about something and mentioned me....  what was that?
[15:29] <mdz> pitti: i figured it had something to do with the guest session
[15:29] <mvo> BenC: thanks, commited
[15:29] <cjwatson> kirkland: ok, will look after the phone call I have shortly
[15:29] <mdz> pitti: ---------- 1  113  128       0 2008-08-07 15:16 _usr_lib_gnome-applets_mixer_applet2.113.crash
[15:29] <zul> kirkland: php
[15:29] <mdz> pitti: odd uid/gid as well
[15:30] <pitti> kirkland: that was the php5 FTBFS
[15:30] <pitti> mdz: yeah, it's a system user
[15:30] <mdz> pitti: it's the pulseaudio user on my system
[15:31] <kirkland> cjwatson: cool
[15:31] <kirkland> pitti: ah, yeah, i reproduced a FTBFS, but didn't get much further than that
[15:32] <pitti> mdz: there is no apparmor rule to allow writing to /var/crash for the guest session, but I wouldn't have thought it applied to apport (since it is launched by the kernel, not the guest session)
[15:32] <pitti> mdz: please feel free to write a bug against gdm-guest-session, at least for the devel release apport crashes in guest session are useful
[15:33] <pitti> mdz: pulseaudio> really? that would be weird
[15:33] <pitti> on my system, pulse is uid 104, gid 113
[15:33] <pitti> mdz: and since we all install from the live CD, I suppose on your's, too?
[15:34]  * ogra has 107/116 for pulse 
[15:34] <pitti> BenC: anyway, doing these boots/dmesgs now; any bug report I shuold attach the results to?
[15:34] <BenC> pitti: there's probably one around, but may be best to just send them to me
[15:43] <tkamppeter> pitti, I have done a new SVN commit for CUPS now.
[15:44] <tkamppeter> pitti, now the package builds correctly with the new filters (under pbuilder) and PDF workflow actually works (print PDF file into Gutenprint queue).
[15:51] <pitti> tkamppeter: nice
[15:52] <pitti> BenC: ok, got them both now
[15:53] <pitti> BenC: without v86d, red-white stripes; with v86d, no usplash at all, and it says "Can't get mode info (vm86 failure)"; usplash: no usable theme found for 320x200
[15:53] <pitti> BenC: I'll mail the dmesg to you, ok?
[15:54] <pitti> seb128: just got two apport crashes again; already reported, though
[15:55] <seb128> pitti: ok, btw apport doesn't respect my prefered browser choice
[15:55] <seb128> I got one crash already reported this morning and it opened firefox
[15:55] <emgent> hello
[15:58] <pitti> BenC: mailed
[15:59] <pitti> seb128: gconftool --get /desktop/gnome/url-handlers/http/command
[16:00] <seb128> pitti: $ gconftool --get /desktop/gnome/url-handlers/http/command
[16:00] <seb128> epiphany %s
[16:01] <pitti> seb128: does "gnome-open http://www.ubuntu.com" open ffox or epy?
[16:01] <seb128> pitti: epiphany
[16:01] <pitti> hmm; that's what apport does ATM
[16:01] <seb128> are you sure?
[16:02] <BenC> pitti: thanks
[16:02] <pitti> if any of those fails, it falls back to using webbrowser.open() which probably calls ffox
[16:02] <seb128> pitti: where is the code?
[16:02] <pitti> seb128: oh, hang on
[16:02] <seb128> pitti: it uses the sudo settings?
[16:02] <pitti> pgrep -x -u 1000 gnome-session
[16:02] <pitti> that fails
[16:03] <pitti> up until hardy, a running gnome-session was a good indicator that you are running GNOME
[16:03] <pitti> I need to update that apparently
[16:03] <seb128> ah
[16:03] <pitti> weird, what's the "mother process" nowadays?
[16:04] <seb128> pitti: x-session-manager, debian thing
[16:04] <pitti> argh
[16:04] <pitti> oh, WTH, I have four zombies running
[16:05] <pitti> Z    16:45   0:00 [gnome-login-sou] <defunct>
[16:05] <pitti> Z    16:45   0:00 [gnome-volume-ma] <defunct>
[16:05] <pitti> Z    16:45   0:00 [gnome-power-man] <defunct>
[16:05] <pitti> Z    16:45   0:00 [gnome-at-visual] <defunct>
[16:05] <pitti> yay new gnome-session not properly detaching children?
[16:06] <pitti> seb128: so, I could use gnome-panel or nautilus as indicators for GNOME
[16:07] <seb128> pitti: bug #252702
[16:07] <seb128> pitti: and http://bugzilla.gnome.org/show_bug.cgi?id=542880
[16:07] <pitti> seb128: thanks
[16:07] <seb128> pitti: usually looking for GNOME_DESKTOP_SESSION_ID is a good way
[16:07] <seb128> when gnome-session is not broken
[16:08] <pitti> $ env|grep GNOME
[16:08] <pitti> GNOME_KEYRING_PID=5839
[16:08] <pitti> hm
[16:08] <pitti> seb128: heck, I just use the panel for now
[16:10] <pitti> seb128: fixed apport uploaded, thanks for pointing out
[16:10] <seb128> pitti: the zombie issue seems to be fixed in 2.23.6 which I didn't upload yet
[16:10] <seb128> pitti: thank you
[16:11] <davmor2> Yay alternative cd's work again :)
[16:12] <seb128> pitti: btw I wanted to discuss that with you, gnome-session relies on dbus to be started now, do you think a depends on dbus-x11 (>= current-version) will be enough for that? or is that likely that some people deleted the conffile or something?
[16:13] <pitti> seb128: we didn't install the conffile, so it'll come back when you install that version
[16:13] <pitti> seb128: so a depends is ok
[16:13] <seb128> ok, will do that then and upload the new gnome-session
[16:14] <seb128> bigon: around?
[16:15] <cjwatson> davmor2: oh good
[16:15] <davmor2> cjwatson: no network issues, no partitioning issues and no missing modules :) Yay
[16:15] <cjwatson> I imagine the first two were due to the last
[16:16] <cjwatson> hard to do anything much with just the initrd
[16:16] <davmor2> cjwatson: the first 2 showed up before the last one but as you say they could easily be interlinked :)
[16:17] <cjwatson> davmor2: that's rather odd, the missing modules error is linearly before those in the installer flow
[16:17] <cjwatson> anyway, never mind, shouldn't happen again
[16:17] <davmor2> cjwatson: I admire the optimism :)
[16:18] <tkamppeter> pitti, I have also asked for getting the new filters into upstream CUPS: CUPS bug 2897
[16:19] <tkamppeter> pitti, but I do not have any answer from Mike yet.
[16:20] <cjwatson> davmor2: I mean because I took steps to stop it happening again
[16:20] <cjwatson> at least in the same form
[16:20] <davmor2> :D
[16:21] <ogra> ion_, cjwatson http://paste.ubuntu.com/35103/ that would me my proposal for compcache vs what we have now (including some casper stuff so we dont need any additional scripts), ion_ i dont think its a prob if you add your percentage stuff to that
[16:25] <ogra> hmm, probably another check if COMPCACHE_SIZE is actually set at all ... but you should get the idea
[16:26] <seb128> pitti: for information http://mail.gnome.org/archives/desktop-devel-list/2008-August/msg00043.html
[16:26] <pitti> seb128: hah
[16:26] <pitti> seb128: so, time for an update of dbus, I guess
[16:27] <pitti> seb128: can do, please nag me about it in case I forget
[16:27] <seb128> yes ;-) well no hurry but we need the new version before intrepid
[16:27] <seb128> pitti: ok will do
[16:27] <seb128> thanks
[16:27]  * seb128 hugs pitti
[16:27] <pitti> oh, I just keep the tab open
[16:27]  * pitti hugs seb128
[16:28] <ogra> http://paste.ubuntu.com/35108/ is better now
[16:30] <pitti> asac: how is nspr/nss now in hardy-proposed?
[16:31] <pitti> ooh, new n-m coming through apt-get!
[16:31] <pitti> so if I fall off the net, please send asac my ♥ :)
[16:32] <sladen> pitti: let me guess, this is _the version_ of N-M that actually works and is going to save humanity ;0
[16:32] <pitti> slangasek: it will certainly be 100% pure love
[16:32] <pitti> and the other 90% are bugs
[16:35] <pitti> asac: hm, nm-applet doesn't start here
[16:35] <pitti> ** (nm-applet:28476): WARNING **: nm_object_get_property: Error getting 'WirelessHardwareEnabled' for /org/freedesktop/NetworkManager: Method "Get" with signature "ss" on interface "org.freedesktop.DBus.Properties" doesn't exist
[16:35] <pitti> asac: but it didn't kill my eth connection during upgrade, bravo!
[16:38] <davmor2> cjwatson: no usplash still :(
[16:42] <pitti> tkamppeter: something is wrong there, if I run "debclean" it runs a whole lot of configure stuff...
[17:01] <kees> mmm jello
[17:03] <mvo> Riddell: I merged your compiz-wrapper patch, will be part of the next upload
[17:03] <Riddell> mvo: great
[17:03] <Riddell> I'll make kwin recommend compiz-wrapper then
[17:04] <mvo> Riddell: excellent, thanks
[17:04] <kees> Keybuk, TheMuso: from scrollback, it sounds like the link priority stuff got sorted out?  I could have used some jello; dang!
[17:06] <asac> pitti: did you restart applet manually?
[17:06] <pitti> asac: yes
[17:06] <pitti> asac: and reloaded dbus as well
[17:07] <pitti> asac: I haven't restarted my entire session yet, though
[17:07] <asac> pitti: yeah ... problem is that NetworkManager has not been restarted. we need a reboot now
[17:07] <asac> thats a _new_ feature
[17:07] <pitti> asac: but I did that, too
[17:07] <asac> reboot?
[17:07] <seb128> re
[17:07] <pitti> no, sudo /etc/init.d/NetworkManager stop/start
[17:08] <seb128> pitti: ok, /usr/lib/ConsoleKit/scripts/ck-system-restart doesn't want to work, installing the policy doesn't make a difference there
[17:08] <asac> pitti: hmm.. which nm-applet version?
[17:09] <pitti> Version: 0.7~~svn20080721t051503-0ubuntu1
[17:09] <asac> sounds good
[17:10] <asac> pitti: maybe you have two NetworkManager running now?
[17:10] <asac> wierd thing is that nothing changed dbus wise since the latest PPA version
[17:10] <asac> which you already had iirc
[17:10] <jarson> pitti, its possible for us to talk in private?
[17:10] <slangasek> YokoZar: naming under /etc/sysctl.d - using the package name would be fairly typical, or else something descriptive about its function
[17:11] <pitti> asac: no, I upgraded from intrepid (0.6) straight to the new intrepid
[17:11] <Mirv> fwiw, I don't have any networks working in intrepid's new NM 0.7 at the moment, upgraded from 0.6. I've even rebooted.
[17:11] <asac> pitti: ok. I'd say that you have still 0.6 running
[17:12] <Mirv> (tries to connect, but ultimately fails, even to wired network)
[17:12] <asac> Mirv: syslog ?
[17:16] <asac> Mirv: there?
[17:17]  * asac upgraded to archive version through apt-get
[17:18]  * asac hits "system restart" ;)
[17:23] <asac> works fine here
[17:23] <asac> :/
[17:24] <Mirv> asac: hmm, works now that I cleaned the cruft I first added into interfaces after having problems. looks like reboot actually did solve the problems, while I still had some after dbus/nm restart, before reboot
[17:27] <Mirv> I do get link timed out quite often, though only with the FON station which is at times problematic itself too
[17:27] <Mirv> well, I guess there'll be anyway bug reports if any big regressions are there
[17:27] <DktrKranz> pitti, re vim-latexsuite SRU in hardy-proposed, I guess you rejected it due to wrong bug number (22541 instead of 225411), isn't it?
[17:27] <pitti> DktrKranz: yes, I mailed the uploader
[17:28] <pitti> DktrKranz: ah, you sponsored it?
[17:28] <MacSlow> seb128, I assume you've not packaged the new gdm yet in a PPA or so, right? Just asking before I do duplicate work.
[17:28] <DktrKranz> pitti, yes. I imagined when noticing bug #
[17:29] <asac> Mirv: ok thanks
[17:29] <seb128> MacSlow: you should really start read mails...
[17:30] <seb128> MacSlow: you were Cced on the reply I did on monday
[17:35] <DktrKranz> pitti, reuploaded with correct LP number, sorry.
[17:35] <pitti> DktrKranz: thanks
[17:36] <metavoid> pitti: hi, did you receive my email?
[17:36] <pitti> metavoid: hi Nikolay! yes, I got it, just didn't repond yet
[17:36] <pitti> metavoid: glad to 'meet' you!
[17:38] <metavoid> pitti: ok, me too
[17:38] <infinity> pitti: "selected in sbuildrc" is, indeed, true... I have an update for all the buildds queued (though I might just twiddle that by hand for now, and wait on bigger fixes to push new packages)
[17:38] <pitti> infinity: ah, ok; good that it's known
[17:39] <MacSlow> seb128, ups... sorry... forgot about that thread... never mind.
[17:40] <pitti> metavoid: how does it run in general on suse? could you make any use of the existing fedora rpm bits?
[17:41] <infinity> pitti: Honestly, though, if the New World Order is to have the most recent "automake" called "automake", maybe build-deps on "automaken" should be phased out in favor of just "automake" (and versioned package names when a package requires an older one)
[17:41] <pitti> infinity: I agree; it would mean to introduce a delta, but I can do that
[17:42] <pitti> infinity: or, if it applies to several packages, maybe just set automaken == automake in sbuildrc and keep it that way?
[17:42] <infinity> pitti: Well, yes, that was the plan anyway.
[17:42]  * pitti -> reboot, brb
[17:43] <infinity> pitti: It just personally annoys me that, while sbuildrc used to house dozens of virtual->real mappings, the automaken one is about the only one left that matters. :)
[17:43] <metavoid> pitti: yes, I inherited opensuse packaging class from rpm one, just like in Fedora
[17:43] <metavoid> pitti: now it works pretty fine, you can see screenshots of apport-gtk on http://en.opensuse.org/Interactive_Crash_Analysis
[17:47] <pitti> infinity: understandable
[17:48] <pitti> infinity: 2 rdepends in main, 11 in universe
[17:48] <pitti> no ttoo bad any more
[17:49] <pitti> metavoid: the bits that I didn't abstract yet (because it's inherently hard) is apport-chroot and parts of apport-retrace
[17:49] <pitti> metavoid: I guess they more or less have to be rewritten from scratch for every distro :(
[17:50] <pitti> metavoid: spec> nice! I'm happy to see other people adopt it
[17:50] <persia> infinity: It was suggested that you might be the right person to ask about the ardour FTBFS: it seems to choke in scons in different places for different build attempts on the buildds, and always compiles fine under sbuild or pbuilder on hardy or intrepid.
[17:50] <pitti> metavoid: I guess it's worth reviewing how much of the logic in apport-chroot and -retrace is generic, and put the rest into the packaging backends
[17:52] <pitti> seb128: new d-bus 1.2.3 works fine for me, uploaded
[17:52]  * slangasek rolls new CDs to see what libgweather has managed to do for us
[17:52] <metavoid> pitti: good idea, in these modules I noticed a bulk of ubuntu-specific calls
[17:53] <NCommander> seb128, it seems every time we update a package, we break hppa more -_-
[17:53] <seb128> pitti: you rock
[17:53] <pitti> metavoid: they have to set up a complete chroot, install debug symbol packages, etc. that stuff needs to move to the package backends wholesale
[17:53] <seb128> slangasek: hey, did you try the new clock applet locations dialog? ;-)
[17:53] <pitti> metavoid: but of course those tools are what makes it really rock
[17:53] <seb128> NCommander: hppa is just broken and doesn't build anything apparently
[17:53] <metavoid> pitti: by the way one my ideas is ti implement automatic downloading of debuginfo packages, does ubuntu have something similar?
[17:53] <pitti> metavoid: i. e. we get automated "retraces" (stack traces with symbols, based on debug symbol packages and core dumps)
[17:54] <NCommander> seb128, its probably on account of glibc 2.8
[17:54] <pitti> metavoid: I have a long-term wishlist bug about adding a "developer" mode
[17:54]  * NCommander wonders how the glibc maintainers manage to break it for every release it seems
[17:54] <pitti> metavoid: it would be nice if the notification window would have a button "Debug locally" if apport-retrace is installed (which we don't do by default)
[17:54] <slangasek> seb128: not yet... haven't switched my primary desktop env to intrepid yet, that may have to wait until I'm back from DebConf to see :)
[17:54] <pitti> metavoid: and then it would install all the dbgsym packages
[17:54] <pitti> metavoid: just haven't found the time yet
[17:55] <pitti> metavoid: something like bug 75901 ?
[17:55] <seb128> slangasek: bug you should add bug #250506 to your list of intrepid issues, turns out reboot and halt don't work because the debian maintainers decided they don't like the consolekit restart and halt actions and don't allow those, pitti agree with them that upstream is on crack, so it's a distro specific issue and we are not going to get any help from GNOME on solving it now
[17:56] <davmor2> slangasek: I got wolverhampton listed and working so I don't care :)
[17:56] <infinity> persia: Without even looking, I'd start with "Does debian/rules understand DEB_BUILD_OPTIONS=parallel=N", followed up by "Are you using it on your test system (because the buildds are)", possibly followed up once more with "scons sucks and I hate debugging it when it breaks".
[17:56] <metavoid> pitti: yes, downloading debuginfos will be a killer feature, we just need to make a cross-distro class first, i'm going to start that very soon
[17:56] <seb128> slangasek: I don't know about consolekit and I've too much to do already so I doubt I'll be looking at the issue
[17:57] <pitti> slangasek: if it's fine for you to fix that ^ post FF, I'm happy to have a look in september
[17:57] <slangasek> pitti: that's a bug rather than a feature, so yes
[17:57] <slangasek> currently milestoned for alpha-5
[17:58] <metavoid> pitti: yes that bug has the same idea I want to implement
[17:58] <infinity> persia: Although, looking at the actual failure, it looks slightly more insidiously annoying than a threading/ordering issue.  Meh.
[17:58] <pitti> metavoid: I think the hardest part so far is to implement a apport/crashdb.py subclass for bugzilla
[17:58] <pitti> metavoid: so far I just have one for launchpad and a testing one (in-memory sqlite)
[18:00] <pitti> metavoid: Will woods added a fedora entry to /etc/apport/crashdb.conf back then, and called it "rhbugzilla"
[18:00] <pitti> metavoid: but there's no such class in the apport code; maybe he developed it separately
[18:00] <seb128> pitti: I'm not sure I understand the rational though, the .policy allow only active users do to restart and halt and only auth_admin to do those in case somebody else is logged
[18:00] <persia> infinity: Yes, No (and I'll try that), and indeed (but you are so good at it).  Thanks for the pointer.
[18:00] <slangasek> 692M    daily/current/intrepid-alternate-i386.iso
[18:00] <slangasek> win \o/
[18:00] <seb128> pitti: so it should not be an issue, and not different of the suspend and hibernates actions we already have
[18:01] <pitti> seb128: the rationale was that it's a design and dependency loop: CK asks PolKit for authorization, and PolKit then in turn asks ConsoleKit for infos about this authorization again
[18:01] <pitti> slangasek: rocking
[18:01] <metavoid> pitti: today I received an email from wwoods and he told me he will be happy to cooperate in adapting apport to bugilla
[18:01] <pitti> metavoid: ah, you are in contact with him? great
[18:02] <metavoid> pitti: there is a patch in fedora RPM package
[18:02] <metavoid> pitti: btw, he is on #fedora-devel ;)
[18:02] <seb128> pitti: is that really bad, both are installed anyway
[18:03] <pitti> metavoid: hm, at least the non-RH-specific bits could certainly go upstream
[18:04] <pitti> seb128: I'm not saying that it can't work, but it's really bad design (layer violation and circular dependencies)
[18:04] <pitti> and it doesn't really belong into CK either
[18:04] <android6011> is there a bug report for boot hanging at ACPI: EC: GPE Storm Detected, Disabling EC GPE until the power button is pressed?
[18:04] <pitti> CK should track sessions, not have random other functionality plumbed on it
[18:05] <alex-weej> seb128: you just closed https://bugs.launchpad.net/ubuntu/+source/gnome-panel/+bug/162068 today saying it was "already reported" but didn't set a dup bug ID... not the first time either! am i missing something or are you just being lazy? :P
[18:05] <alex-weej> android6011: that shows even on my working system
[18:06] <android6011> alex-weej: but my system hangs at it unless i press the power button, then it will continue to boot
[18:06] <android6011> i have the same problem with backtrack3
[18:06] <seb128> alex-weej: I'm being overworked, I can't look for duplicate number for the zillions duplicates open or I would spend half my days doing that and I don't think it would benefit anybody
[18:06] <slangasek> ScottK, pitti: libmail-dkim-perl is still uninstallable on the server CD; is a MIR pending for libopenssl-rsa-thingy-perl?
[18:06] <alex-weej> seb128: take a break
[18:07] <seb128> alex-weej: I don't need to take a break, but I don't think looking for exact numbers benefit anybody as said, it's not a good ressource usage ;-)
[18:07] <alex-weej> it benefits me
[18:07] <alex-weej> i subscribed THAT report
[18:07] <alex-weej> because that was a bug I was going to file
[18:07] <seb128> well, you opened a bug about a known issue
[18:08] <alex-weej> oh wait i am confused now
[18:09] <seb128> alex-weej: I agree it's not optimal but choises are
[18:10] <seb128> - let ton of known duplicates open because we are too busy to look for exact numbers, which make our work harder
[18:10] <seb128> - close and let the duplicate filer search for the open bug
[18:10] <seb128> - spend lot of time looking a duplicate which could be used to fix issues
[18:11] <persia> seb128: Yes, but it's an exceedingly unpleasant experience for the user to be told their bug is invalid without any information about how to get more information beyond "search LP".
[18:11] <seb128> I've decided to let users look for number when I don't find those quickly
[18:11] <alex-weej> seb128: and i can't find it either.
[18:12] <seb128> persia: well, having bugs not fixed because I spend my time looking at number rather than working on bugs would not be pleasant for them either
[18:12] <persia> seb128: Agreed.  I'm just not sure it's not worth leaving the bugs there for others to find the duplicates (and no, the interface isn't ideal for this)
[18:12] <seb128> alex-weej: that's a known issue, not sure about the bug number
[18:13] <cjwatson> "subject: [needs-dup] foo" maybe?
[18:13] <seb128> persia: I've no way to get those out of my way out of closing them, and if I do let the hundred duplicates we get every week on desktop bugs I can as well stop using launchpad
[18:13] <persia> cjwatson: That sounds like a good idea.
[18:13] <seb128> cjwatson: we tried tagging those, that goes quickly out of control
[18:13] <persia> seb128: I understand the feeling.
[18:14] <alex-weej> seb128: has the bug reporting gotten out of hand lately then?
[18:14] <cjwatson> with ordinary tags or in the subject?
[18:14] <seb128> nobody close them and we can't work on the bug lists due to the noise
[18:14] <seb128> cjwatson: tags
[18:14] <seb128> alex-weej: yes
[18:14] <cjwatson> the reason I suggested a subject tag was that it is more visible in bug lists and thus it's easier to ignore those bugs
[18:14] <cjwatson> I don't find tags very useful for things I need to see in bug lists
[18:14] <seb128> well, still I don't fancy having lists 3 time longer just because we don't want to close duplicates without looking for exact numbers
[18:15] <alex-weej> i've been thinking about something that may make it less painful. basically make it so that "users" file problem reports and "developers" can file actual, in-the-code bug reports
[18:15] <persia> It really waits on LP having a negation feature in searches (one of the features being examined for the next set of milestones)
[18:15] <cjwatson> another approach that seems to have been successful elsewhere is putting [MASTER] in the subject of bugs that attract lots of dups
[18:15] <alex-weej> and a problem like "my sound isn't working" is VALID, but is worked out and linked to a set of 5 bug reports
[18:15] <alex-weej> and you can work on the actual bug reports
[18:16] <seb128> alex-weej: I usually send those users to the support tracker
[18:16] <alex-weej> and also, for each in-the-code Bug can see what kind of problems it is causing
[18:16] <cjwatson> although ISTR from recent mailing list conversation that there's a way to search for bugs by most-duplicated
[18:16] <alex-weej> seb128: "Answers"?
[18:16] <seb128> yes
[18:16] <alex-weej> i agree it is the closest thing
[18:16] <cjwatson> alex-weej: answers.launchpad.net has that feature set - you can easily promote an answers ticket to a bug
[18:16] <cjwatson> or demote a bug to a ticket
[18:16] <persia> (or demote a bug to a question)
[18:17] <alex-weej> i guess it's just the terminology then
[18:17] <seb128> we need an extra state: duplicate, somebody needs to look at the number which acts as a closed status ;-)
[18:17] <alex-weej> see, "my sound isn't working" is something that needs to be fixed, "how do i install skype?" is something that doesn't. yet they both go under "answers" right now.
[18:17] <seb128> so we don't have those getting in the way of people looking at their bug list
[18:18] <persia> alex-weej: That lets those more familiar with the system help sort the support requests from the bugs.
[18:18] <alex-weej> persia: but most of the time a user will know whether it is a support request or a problem report
[18:18] <cjwatson> alex-weej: many users do not have a reliable ability to distinguish the two, though
[18:18] <alex-weej> heh
[18:18] <cjwatson> alex-weej: that's not my experience
[18:18] <alex-weej> ok
[18:18] <alex-weej> well you're probably right, my sample size of 1 includes myself
[18:19] <alex-weej> in that case i suggest a policy of demoting crap bug reports much more often
[18:19] <cjwatson> it's hard to judge - in many cases it's clear that *something* is wrong with the code, but it's just not clear what
[18:20] <alex-weej> cjwatson: then it should be a "Problem Report"
[18:20] <alex-weej> like i said, bug reports should be actually in the code
[18:20] <persia> alex-weej: It very much depends on the user.  Also "my sound isn't working" isn't a useful report.  "OpenAL isn't working with pulseaudio" or "No sound with Al4827 codec in ALSA" are good bug reports, one of which might be extracted from "my sound doesn't work", but it might also just be "Did you unmute the master volume?"
[18:20] <alex-weej> persia: even the last case is a bug. why is master volume muted?
[18:21] <cjwatson> perhaps because the user muted it and forgot :)
[18:21] <alex-weej> and i don't expect anyone who isn't a geek to know what an Al4827 codec is
[18:21] <persia> alex-weej: Some BIOSes do that, also sometimes it was muted before, and the settings were preserved.
[18:21] <cjwatson> I mean, a good percentage of the times I complain about broken wireless at the start of a UDS, it turns out to be that I'd forgotten to turn my RF-kill switch back off after the plane trip
[18:21] <persia> There's a page on the wiki that talks about collecting information on sound bugs that would specify that (it's in /proc/asound/cards)
[18:21] <alex-weej> i will give you a personal experience. i know my way around linux, ubuntu and gnome fairly well, but sometimes i will report a bug, have it marked as a duplicate of some other bug report that is the same bug but another manifestation
[18:21] <alex-weej> and the problem is that the ifnormation i provided is then lost
[18:22] <alex-weej> and i suddenly have no idea what this other report is about
[18:22] <alex-weej> a real-world user just wants to know when their problem gets fixed
[18:22] <cjwatson> FWIW information in duplicate bugs is not lost
[18:22] <cjwatson> I've very often gone through all the dups when fixing a much-duplicated bug looking for information
[18:22] <persia> It may be that someone needs to review the duplicates and ensure the master bug contains the most useful information.
[18:22] <cjwatson> so it's neither lost in theory nor in practice
[18:23] <cjwatson> although it's true that it's basically lost if you don't link the bugs
[18:23] <alex-weej> right, but i'm saying if you can have one person with knowledge of the systems file a proper bug report that says "the al4827 codec is broken" and then link all of the user-generated problem reports
[18:23] <alex-weej> it might be easier to manage for the users who generated those reports and the people who have to actually fix the code
[18:23] <persia> alex-weej: Which is precisely the relationship between answers.launchpad.net and bugs.launchpad.net
[18:23] <alex-weej> persia: answers should be renamed then
[18:24] <persia> (or if it isn't then that is itself a bug)
[18:24] <alex-weej> when something is broken, i don't want an answer, i want it to be fixed
[18:24] <alex-weej> also crash reports
[18:24] <alex-weej> they should not be bug reports
[18:24] <alex-weej> they should be problem reports
[18:24] <cjwatson> alex-weej: I believe the preferred way to do that (as demonstrated by the way the system's designers use it) is to edit the description of whichever bug you use as a master, to describe the problem in a more developer-friendly way
[18:24] <cjwatson> rather than just leaving the description in place and adding a comment
[18:24] <alex-weej> i have been doing that in some cases
[18:25] <alex-weej> but then the comment trail makes no sense
[18:25] <cjwatson> it works for me
[18:25] <alex-weej> because people think it is just a forum thread
[18:26] <alex-weej> yeah it's not too bad
[18:26] <alex-weej> but i still think there are too many people using bugs. too often (myself included)
[18:26] <alex-weej> if i get a crasher, i just want to log it somewhere
[18:26] <alex-weej> i don't want to have to explain what i was doing or search for duplicates en-route
[18:27] <seb128> alex-weej: why should I bother looking for the duplicate number of the submitter doesn't bother doing that before opening the bug ;-)
[18:27] <alex-weej> i mean it has gotten so bad we turn OFF apport now for final release
[18:27] <alex-weej> cause the volume is so insane
[18:28] <cjwatson> you say that as if it's new :)
[18:28] <seb128> right, there is over 3000 apport crash bugs not triaged in launchpad
[18:28] <pitti> cjwatson: it was quite alright in, say, october 2004 :)
[18:28] <alex-weej> seb128: because you can't expect the user to know what a SIGSEGV is, and it would help people trying to fix the original bug
[18:28] <cjwatson> we always knew that crash bugs ought to be handled by a separate crash database, but needed to work with what we had
[18:28] <alex-weej> cjwatson: what's wrong with answers?
[18:29] <cjwatson> I doubt that the set of people doing most of the work with answers at the moment would have a clue what to do with crash reports
[18:29] <alex-weej> right
[18:29] <seb128> alex-weej: the bug tracker main use is to allow people who do the work to know the issues and to work on those
[18:29] <pitti> also, a crash is a real bug, not a support request
[18:29] <cjwatson> they're often much better handled by developers, although the volume is ... unfortunate
[18:29] <alex-weej> pitti: negative, a crash is a manifestation of a bug
[18:29] <pitti> it wouldn't fix the problem, just move it
[18:29] <alex-weej> there should only be one bug
[18:29] <seb128> alex-weej: as the maintainer if I say that I know about the issue and that I don't need an another bug why should I let the bug open?
[18:29] <alex-weej> and all of the crashes should be linked to it
[18:29] <pitti> alex-weej: well, most reports are "manifestations"
[18:30] <alex-weej> pitti: exactly what i'm trying to move away from
[18:30] <alex-weej> because it's making seb's life a misery
[18:30] <pitti> alex-weej: that's why we aim for good auto-duplication
[18:30] <pitti> alex-weej: but yes, I see what you mean, but there's no real difference to what users report
[18:30] <pitti> if they report the same problem n times
[18:30] <alex-weej> i don't see why the first report is the best, i see all the (problem|crash) reports as being individually useful for fixing actual bugs
[18:31] <pitti> we don't have a policy of always using the first bug as master, to the contrary
[18:31] <alex-weej> also we sometimes use the number of duplicates as a metric for how important a problem is to fix
[18:31] <alex-weej> yet we actively discourage people from filing duplicates at the reporting stage
[18:31] <pitti> we usually use the best-described bug as the master
[18:31] <alex-weej> if we let people report their own set of problems we could have a useful measure
[18:32] <pitti> alex-weej: no, we wouldn't
[18:32] <alex-weej> pitti: right, but that's something which can only be judged by a human, not an "auto-dup" robot
[18:32] <cjwatson> no we wouldn't, we'd just have a bajillion problem reports that nobody would ever be able to triage
[18:32] <cjwatson> there has to be some kind of input filtering, otherwise you're just rearranging the deckchairs
[18:32] <pitti> alex-weej: since we can't even keep up with precisely duplicating the current number of bugs
[18:32] <alex-weej> but it doesn't take bug fixers to triage them
[18:32] <alex-weej> it just takes monkeys or robots
[18:33] <alex-weej> and the user gets to keep track of his own issue
[18:33] <pitti> alex-weej: no, it reuqires a fair amount of developer experience in many cases
[18:33] <cjwatson> if you have monkeys or robots dealing with problem reports, you'll get a corresponding quality of problem report handling
[18:33] <pitti> if a monkey could do it, LP could do it itself
[18:33] <cjwatson> there will be a very substantial degree of inaccuracy, and our ability to assess the actual bugginess of Ubuntu would get significantly worse
[18:33] <pitti> so we should make it much easier to find duplicates right from the start
[18:33] <cjwatson> and users will be angry because their report is being dealt with by an idiot
[18:33] <pitti> less bugs -> more developer time per bug to spend on
[18:33] <cjwatson> that does nobody any good
[18:35] <alex-weej> pitti: i don't think it will EVER be possible for my mum to file a crash report properly
[18:35] <alex-weej> and i don't think it should be
[18:35] <alex-weej> that includes checking for duplicates
[18:36] <pitti> alex-weej: crash reports are actually the easier ones
[18:36] <pitti> they are highly structured, and we *can* (and have) a monkey dup'ing them
[18:36] <cjwatson> actually, I've got lots of crash reports filed by people who have no idea what they're doing that are the easiest bugs to address
[18:36] <alex-weej> i suppose now we have your stack trace resolver thing
[18:36] <pitti> alex-weej: and we don't need a real description for them
[18:36] <cjwatson> backtrace, it's clear what's going on (sometimes), bingo, fixed
[18:36] <cjwatson> two minutes
[18:36] <pitti> alex-weej: the non-crash bugs are a much more difficult problem
[18:37] <pitti> alex-weej: I'm inclined to say that we have perfect crash handling for Python crashes; sigsegv crashes suck a bit, due to dbgsym/local version/current version skew, but at least we have some automatic support there
[18:37] <alex-weej> i've never actually dealt with a python crash
[18:37] <cjwatson> the best thing I ever did for ubiquity was turning on automatic crash reporting for it
[18:37] <alex-weej> does it just catch exceptions that bubble all the way up?
[18:37] <cjwatson> we hoovered up so many bugs as a result
[18:38] <pitti> alex-weej: right
[18:38]  * alex-weej had better fix his application
[18:38] <alex-weej> :P
[18:38] <pitti> nice thing is that I get a lot of apport crashes filed through apport as well :)
[18:38] <cjwatson> you can still log the crash separately or whatever if you want with a top-level exception handler; just re-raise the exception when you're done
[18:39] <cjwatson> ubiquity spits it to syslog, invokes pdb if requested and sane, raises the exception if apport is present, otherwise displays a dialog box with the exception and then exits
[18:40] <alex-weej> i just have these utopian visions
[18:40] <alex-weej> an email from launchpad
[18:40] <alex-weej> "you know that pommed crasher you got last week? the bug causing it was fixed today."
[18:40] <cjwatson> even if the crash is hard to understand, it's a million times better than "uh, the installer vanished on me and I don't know what to do" which is what I got before
[18:40] <alex-weej> yeah i don't think there's any dispute there cjwatson :)
[18:40] <cjwatson> and users *do* get "you know that installer crasher you got last week? the bug causing it was fixed today" e-mails
[18:41] <cjwatson> although since it's the installer it may not be practical for them to make use of the fix for a while, but still
[18:41] <pitti> it does work pretty well for desktop apps
[18:41] <pitti> reporter gets mail, dist-upgrades, is happy
[18:41] <pitti> and can immediately file the next crasher which gets uncovered then :)
[18:42] <alex-weej> right
[18:44] <alex-weej> but say there were 5 different crash conditions caused by a single unchecked buffer or whatever
[18:44] <pitti> that's actually pretty rare, although possible, of course
[18:44] <alex-weej> oh is it
[18:44] <pitti> alex-weej: well, it's definitively a problem
[18:45] <alex-weej> well anyway, i just see a massive difference between "Pommed crashes with SIGSEGV in ...." and "buffer overflow in yadda yadda"
[18:45] <pitti> alex-weej: but we can't expect users and most developers who file a bug to know that :)
[18:45] <alex-weej> perhaps not
[18:45] <alex-weej> i am just a bit angry that seb128 is "overworked"
[18:46] <seb128> I don't see the issue with being agressive in bugs closing
[18:46] <seb128> we have way more issues than we will fix anyway and they come faster than we fix those
[18:46] <seb128> so closing bugs we judge not useful should not be an issue
[18:46] <alex-weej> look man you said yourself you can't find the report so you gave up
[18:46] <seb128> there is no need to accumulate bugs we know we will not likely do anything about
[18:46] <alex-weej> and you're the one who has seen it before
[18:46] <alex-weej> i've never seen it before
[18:46] <alex-weej> and i've looked, and i can't find it
[18:47] <alex-weej> if i go to the effort of filing a bug it's because i want to see Ubuntu improved for everyone
[18:47] <seb128> alex-weej: we have currently almost 6000 desktop bugs open, I expect we close more than that and I read all the bug mails I get usually
[18:47] <alex-weej> and for me to lose track of that is very demotivating
[18:47] <alex-weej> and I'm not even on Canonical's payroll!
[18:47] <seb128> alex-weej: which means I read like 35 000 desktop bugs
[18:47] <seb128> finding something there is not always easy ;-)
[18:48] <seb128> alex-weej: to be honest I'm not sure there is a specific bug about your issue, there is for sure about having GNOME, evolution and the clock applet sharing clock settings, which I consider the same issue
[18:48] <alex-weej> and GDM
[18:48] <cjwatson> alex-weej: all I'm saying is that there are some things which appear tempting as solutions, but that in fact would make things more difficult for developers
[18:49] <cjwatson> alex-weej: nevertheless, various other attempts to address the bug problem are right at the top of Ubuntu's priorities for Launchpad development
[18:49] <seb128> alex-weej: gdm is a trickier question because that's not an user setting, what if 2 users on the same box user different options?
[18:49] <cjwatson> I haven't been intimately involved in that so can't tell you the details
[18:49] <alex-weej> seb128: systemwide settings are not that hard to conceive
[18:50] <alex-weej> well, they are in GNOME because we just happily reinvent everything within a desktop session
[18:50] <seb128> alex-weej: right, 12-or-24 should be a gconf key with a schemas default, a way for sysadmin to change the default and then user settings
[18:50] <seb128> alex-weej: the new gdm will make easier to solve that since it uses gconf
[18:50] <pitti> I think gdm uses the format defined in the locale
[18:50] <seb128> pitti: as does the clock applet
[18:50] <seb128> but some locales allow 12 or 24h
[18:50] <alex-weej> the clock applet has a 12-24h choice in its preferences
[18:50] <pitti> there are some 12 hour bugs against langpack-locales, but none for en_GB
[18:51] <alex-weej> now if the option was "Default, 12hr, 24hr" then that would make sense
[18:51] <alex-weej> but somehow it's just 12hr, 24hr
[18:51] <alex-weej> so i'm nto sure how it uses the locale
[18:51] <alex-weej> seeing as gconf defaults are static
[18:51] <slangasek> pitti: which "format defined in the locale"?
[18:51] <seb128> pitti: the bugs are for locales which don't allow to choose between 12h and 24h
[18:52] <slangasek> there are some really insane default time formats in locales :)
[18:52] <seb128> slangasek: am,pm or 24
[18:52] <slangasek> ah, is that discretely queriable?
[18:52] <pitti> slangasek: the locale defines the strings for "AM" and "PM"
[18:53] <slangasek> pitti: my question was really about what format string one would use to strftime(), and apparently it's %X
[18:54] <slangasek> IME, %c gives crazy results though
[18:54] <cjwatson> kirkland: the only problem I see with your grub-installer patch is that you call the write_grub function before it's defined ...
[18:54] <slangasek> I tried to make freetds use %c for the default datetime format once; this was a source of Bugs
[18:54] <cjwatson> kirkland: I'll just fix that in the obvious way
[18:55] <slangasek> because %c in en_US was mapped to a format that NO ONE uses
[18:57] <alex-weej> also we still have monospace legacy crap in those date formatting functions :/
[18:57] <alex-weej> check out the date now
[18:57] <alex-weej> "Thu··7·Aug"
[18:57] <alex-weej> on Sunday it will be "Sun·10·Aug"
[18:57] <pitti> the German one doesn't look very good as well
[18:57] <seb128> slangasek: date +%p
[18:58] <alex-weej> we need steve jobs to rule over us and not let us release until everything looks spot on :P
[18:58] <seb128> slangasek: that's doing something or not, depending of the locale
[18:58] <slangasek> seb128: but I don't think that's what you want, because there's no format string for "give me the hour in 24 or 12 hour time, according to the locale preference"
[18:58] <slangasek> seb128: except for %X, which gives you the whole time string
[18:59] <cjwatson> kirkland: I'm concerned that re-running grub-install after installation will break, though
[18:59] <cjwatson> kirkland: so I don't think this is a viable long-term solution, but it may do for the short term
[19:00] <pitti> slangasek: closest I found is +%r
[19:00] <pitti> $ LANG=en_US.UTF-8 date +%r
[19:00] <pitti> 08:00:06 PM
[19:00] <pitti> $ LANG=de_DE.UTF-8 date +%r
[19:00] <pitti> 08:00:15
[19:00] <slangasek> ah
[19:00] <pitti> the latter is wrong, of course, becaue de doesn't have am/pm
[19:00] <seb128> slangasek: that's what the gnome-panel do:
[19:00] <pitti> but for a test it might suffice
[19:00] <seb128>         am = nl_langinfo (AM_STR);
[19:00] <seb128>         return (am[0] == '\0') ? CLOCK_FORMAT_24 : CLOCK_FORMAT_12;
[19:01] <slangasek> seb128: right, that seems kludgy to me :)
[19:02] <slangasek> the app shouldn't assume that empty AM_STR implies 24-hour time; maybe my locale uses a 12-hour clock and revels in ambiguity :-)
[19:02] <pitti> slangasek: but that's pretty much what locales does
[19:02] <infinity> slangasek: A locale with a 12 hour clock and no am/pm indicator is broken anyway.
[19:02] <pitti> if you define t_fmt_ampm, then it uses AM/PM, otherwise 24 hours
[19:03] <pitti> unfortunately locales definitions don't have a concept of "alternative nonpreferred 12 hour format"
[19:03] <pitti> infinity: like every wall clock? :-)
[19:03] <infinity> pitti: Wall clocks don't tend to be driven by locales. :)
[19:04] <pitti> infinity: well, they are just kind of hardcoded :)
[19:04] <pitti> (especially the ones with a calendar)
[19:06] <infinity> Anyhow, I figure we're stuck working with what we have, unless someone feels like upending the locale world by always specifying an am/pm format string, and introducing a new 24_hour_preferred boolean.
[19:06] <pitti> I got interesting bugs about that already
[19:06] <slangasek> lifeless: do you have an LC_TIME for your Latin locale yet, that numbers the hours from sunrise instead of from midnight? ;)
[19:06] <slangasek> infinity: don't you repress me!
[19:07] <pitti> I added some locale patches because some es_MX people said they want it that way, and the next week some others told me it was wrong :)
[19:07] <slangasek> pitti: oh, well, I still think gnome-panel shouldn't have to duplicate the logic then
[19:07] <infinity> slangasek: Calling locales ugly is about as useful as calling Roseanne fat, unless you have some magic plan to fix either. :P
[19:07] <slangasek> (but yes, not a high priority to fix)
[19:08] <pitti> slangasek: LC_CTIME=la.UTF-8 date -> XIV:LIX ?
[19:08] <slangasek> pitti: hahaha
[19:08] <pitti> slangasek: ack for not duplicating, yes
[19:09] <pitti> slangasek: but I pretty much gave up on applying those now, it's utterly hard to get them past Ulrich
[19:10] <pitti> seb128: yay gnome bug 544554
[19:11]  * pitti checks out svn head and tests
[19:14] <ScottK> slangasek: Urgh.  I'll look into it.
[19:17] <slangasek> ScottK: cheers :)
[19:17] <cjwatson> davidm,lool: I've just uploaded a debian-installer package with support for lpia. Once it builds, you should at least be able to attempt netboot installations if you can get the thing to boot over the network, or boot the netboot mini.iso somehow
[19:19] <slangasek> 691M    daily-live/current/intrepid-desktop-amd64.iso
[19:19] <slangasek> man, libgweather-common is just awful :)
[19:20] <pitti> slangasek: s/ful/some/ in the current state :)
[19:20] <slangasek> well, I still need to graft in gettext to make it truly awesome... :)
[19:21]  * pitti does sudo dpkg -P gnome-volume-manager and whistles happily
[19:21] <slangasek> the changes to the C code are ridiculously simple, just replace two calls to ..._get_localized_value() with _(..._get_value())
[19:21] <pitti> slangasek: nice
[19:21] <pitti> slangasek: does it even define a gettext domain already, or do we need to invent one?
[19:21] <slangasek> but now I have to pull in the correct gettext glue :)
[19:22] <slangasek> probably have to invent one
[19:22] <pitti> slangasek: you probably have to use dgettext() instead of _(), though
[19:22] <slangasek> ah, probably
[19:22] <pitti> slangasek: since the general application gettext domain will differ from the one for the cities
[19:23] <slangasek> yep
[19:26] <pitti> rocking! that patch fixed gnome-keyring for ssh
[19:26]  * pitti uploads
[19:27] <alex-weej> if i leave any VM's running, my machine fails to suspend
[19:27] <alex-weej> and i have to hard reboot
[19:27] <alex-weej> anyone know anything about this? bug has been open for a few weeks now without any comment
[19:28] <alex-weej> this is with the "supported" KVM/virt-manager stuff
[19:29]  * slangasek frowns.  Ok, I know I saw an existing textdomain name for the location strings /somewhere/, why can I not find it now?
[19:30] <slangasek> ah, I was looking for 'gnome', and the header just says 'weather-locations'.
[19:33] <slangasek> pitti: do you think 'weather-locations' is ok for a textdomain, or should I change it to 'gnome-weather-locations'?
[19:33] <pitti> slangasek: I'd use an appendix to libgweather's already existing one
[19:34] <pitti> slangasek: like "libgweather-locations"
[19:34] <lool> cjwatson: Oh rocks, I had a local tree with the beginning of lpia support, but I was waiting for the kernel udebs which were blocked by a lpia kernel tree in intrepid -- I'm glad you already implemented all this, I guess you have a similar config as for amd64?
[19:34] <pitti> slangasek: but yeah, it's bikeshedding
[19:35] <slangasek> pitti: hmm, I'm not finding where *that* is defined either :)
[19:36] <pitti> slangasek: usually it's defined in configure.in as GETTEXT_PACKAGE=
[19:36] <slangasek> ah
[19:36] <pitti> if not, it should be in po/Makefile.in.in
[19:37] <pitti> but usually that just has
[19:37] <pitti> GETTEXT_PACKAGE = @GETTEXT_PACKAGE@
[19:37]  * slangasek nods
[19:37] <pitti> slangasek: so you could do dgettext(GETTEXT_PACKAGE "-locations", str) perhaps?
[19:38] <slangasek> yeah, it's in configure.in; I think best practices may have drifted slightly since the last time I gettextized something :)
[19:38] <seb128> pitti: he, you start fixed GNOME faster than me now? ;-)
[19:38]  * seb128 hugs pitti
[19:38] <pitti> seb128: leave me the victory of being faster than you ONCE :)
[19:38]  * pitti hugs seb128
[19:38] <seb128> good to get this one fixed
[19:39] <seb128> now I just have to fix seahorse to get the gpg-agent working again
[19:39] <pitti> actually the gpg one is more annoying, but that one was nasty as well
[19:39] <pitti> seb128: please appreciate my nice patch header :)
[19:39] <seb128> well the gpg one is trivial to fix
[19:40] <seb128> pitti: nice ;-)
[19:41] <ScottK> slangasek: libcrypt-openssl-bignum-perl has an approved MIR (Bug #243266) and all it's depends are in Main, yet it got demoted to Universe on July 11.  Any idea why?
[19:41] <ScottK> That also took out libcrypt-openssl-rsa-perl at the same time.
[19:41] <slangasek> ScottK: no idea, no
[19:42] <pitti> ScottK: probably it appeared in component-mismatches back then and wanted to go back
[19:42] <pitti> so it can just be promoted back now
[19:42] <ScottK> pitti: Please do (both)
[19:42] <slangasek> right, probably a race condition between someone approving an MIR and someone else processing component mismatches
[19:42] <pitti> rather, we promoted them, but nothing was depending on them even several days/weeks later, so they just fell through the cleanup cracks
[19:43] <pitti> promoted both
[19:43] <ScottK> Because that was before recommends got pulled into seeds.
[19:43] <pitti> yep
[19:43] <pitti> sorry for the confusion
[19:43] <ScottK> libmail-dkim-perl  is a recommends for amavisd-new.
[19:43] <ScottK> That's what I get for working ahead.
[20:42] <ffm|sh> How can I find out what patches were applied to http://packages.ubuntu.com/intrepid/sugar ?
[20:55] <geser> ffm|sh: look into the .diff.gz
[20:59] <ffm|sh> geser: thx.
[21:24] <jcastro> Hi, I've posted 2 mails to ubuntu-devel today that are in the moderator queue if someone could look at them please.
[22:13] <warren> Hey, which Ubuntu release was the first to contain glibc-2.4 or higher?
[22:14] <jpds> warren: "rmadison glic" reports: glibc | 2.5-0ubuntu14 |        feisty | sourc
[22:15] <warren> thanks
[22:20] <Mez> glic ?
[22:28] <warren> btw, is Ubuntu using execshield?
[22:28] <warren> does Ubuntu build all binaries with -fstack-protector?
[22:29] <pwnguin> warren: i dont think Ubuntu builds "all binaries" with anything
[22:29] <warren> really, no standard build options?
[22:29] <pwnguin> there's common build options
[22:29] <warren> what are the common flags currentyl?
[22:30] <elmo> warren: exeshield> no
[22:30] <elmo> warren: -fstack-protector> yes, since 6.10
[22:30] <elmo> stack-protector's enabled in the gcc spec file
[22:30] <elmo> so it's global both for ubuntu packages, and source built on ubuntu systems
[22:31] <warren> ok good.
[23:01] <kirkland> what does "set -- " do in shell?
[23:01] <slangasek> sets the contents of your $@ argv array to the empty set
[23:02] <kirkland> slangasek: and "set -- `foo `" sets your $@ to the stdout of foo?
[23:02] <soren> Yes.
[23:02] <kirkland> soren: slangasek: cool, thanks.
[23:05] <hwilde_> how do you tell if you are running 64b or 32b
[23:05] <kirkland> hwilde: uname -a
[23:06] <hwilde> kirkland, I don't see where that tells me tho
[23:06] <hwilde> Linux Tug-91-1 2.6.24-16-generic #1 SMP Thu Apr 10 13:23:42 UTC 2008 i586 GNU/Linux
[23:06] <kirkland> i586
[23:06] <kirkland> that's 32 bit
[23:06] <hwilde> ok now how do you tell if it's 32b desktop or 32b server version
[23:07] <kirkland> 2.6.24-16-generic = desktop
[23:07] <slangasek> you check whether you're running gnome? :)
[23:07] <hwilde> wrong that is server version.
[23:07] <bardyr> lsb_release -a
[23:07] <soren> hwilde: Err.. No.
[23:07] <kirkland> Linux ubuntu 2.6.26-4-server #1 SMP Mon Jul 14 19:19:23 UTC 2008 x86_64 GNU/Linux
[23:07] <hwilde> that is server version.  I just installed it myself from the server cd
[23:07] <hwilde> it has no gui
[23:07] <kirkland> hwilde: ^^^ mine is 64 bit server
[23:07] <hwilde> it has no ubuntu-desktop
[23:08] <hwilde> lsb_release -a has no indication it is server version either
[23:08] <soren> It won't.
[23:08] <kirkland> hwilde: you can mix and match Ubuntu quite a bit
[23:08] <slangasek> yes, because the difference between "server version" and "desktop version" is what packages you have installed
[23:08] <kirkland> hwilde: server kernel, on a desktop machine, vice versa
[23:08] <soren> Server and Desktop editions are the same except the desktop has more packages installed and uses the -generic kernel.
[23:08] <hwilde> interesting
[23:08] <kirkland> hwilde: it's like going to a Chinese buffet with sushi :-)
[23:08] <hwilde> soren, this is server version but it still says generic
[23:09] <soren> hwilde: Then you've installed that somewhere down the line.
[23:09] <hwilde> lol
[23:09] <soren> hwilde: The server install cd will install the server kernel.
[23:09] <soren> hwilde: Either you've manually installed the generic flavour after installing ubuntu or perhaps you used the cli install option on the alternate CD.
[23:10] <soren> The latter will give you the same packages as a server install, but with the generic kernel.
[23:10] <hwilde> so... dpkg -l | grep desktop   ?
[23:10] <soren> What about it?
[23:10] <hwilde> that is how to tell if you have desktop or server version ?
[23:10] <soren> 22:08:42 < soren> Server and Desktop editions are the same except the desktop has more packages installed and uses the -generic kernel.
[23:11] <soren> You can't tell the difference, because there is none.
[23:11] <soren> You can start with the desktop edition, remove all the desktoppy bits, or you can start with the server edition and install gnome.
[23:11] <slangasek> hwilde: what's the problem you're trying to solve?
[23:11] <kirkland> (chinese buffet with sushi!)
[23:11] <slangasek> kirkland: sick, sick man
[23:11] <hwilde> slangasek, noob complaining their gui is broken.   did they install from server cd
[23:11] <soren> hwilde: In those cases, what would be the answer to your question?
[23:12] <hwilde> in those cases the answer would be, you either have not installed or you have removed the desktop packages so there is no gui.
[23:12] <slangasek> hwilde: if you want to answer the question "did they install from server cd", look in /var/log/installer
[23:13] <hwilde> ah hah!
[23:13] <hwilde> syslog:Apr 23 12:18:10 base-installer: info: kernel linux-image-2.6.24-16-server not usable on k6
[23:13] <hwilde> /var/log/installer/syslog
[23:13] <hwilde> syslog:Apr 23 12:18:10 base-installer: info: Using kernel 'linux-generic'
[23:14] <soren> hwilde: If that's your use case, it's a nonsense question. Whether they installed from one CD or the other doesn't matter. What might matter is the presence of the desktop packages.
[23:14]  * slangasek rewrites that line to say: "k6 not usable as a server" ;)
[23:14] <lifeless> slangasek: :)
[23:14] <slangasek> soren: one might legitimately want to know how they got to a particular broken state; e.g., for tracing an installer bug :)
[23:14] <hwilde> how come anytime people ask something the inevitable answer is you should not be asking that
[23:14] <hwilde> if you don't want to answer that's fine but there is no need to be like that
[23:15] <lifeless> slangasek: actually, I have to track down an X complaintt
[23:15] <soren> slangasek: That's a fair point. :)
[23:15] <Laney> Can someone unsubscribe ubuntu-archive from bug #252287? AFAICS the request needs an ACK first
[23:15] <lifeless> slangasek: $ xterm
[23:15] <lifeless> Warning: locale not supported by Xlib, locale set to C
[23:15] <slangasek> hwilde: well, your first question was the wrong question in that there's no hard line between a "desktop" and a "server" install; but we seem to have gotten to the right question and answer now :)
[23:15] <hwilde> I never knew /var/log/installer existed, so thank you, that explained it
[23:16] <hwilde> they did install from the server cd
[23:16] <hwilde> but it installed generic kernel because k6 unusable
[23:16] <slangasek> lifeless: Xlib SMASH
[23:17] <lifeless> slangasek: is that humourous or an actual thing I'm unaware of ?
[23:17] <slangasek> lifeless: :(  maybe it's neither :(
[23:17] <slangasek> but I think it was trying to be humorous
[23:17] <lifeless> :)
[23:18] <slangasek> Laney: unsubscribed
[23:20]  * slangasek mutters at intltool being uncooperative.  'default' is not a very useful string to search for in aclocal.m4. :P
[23:24] <Laney> slangasek: Thanks
[23:24] <hwilde> so... what is k6 ?
[23:24] <slangasek> an older AMD processor
[23:25] <LaserJock> are the Athlon XP's k6?
[23:25] <slangasek> no, the k6 was a 32bit-only proc
[23:26] <slangasek> oh, there was a 32bit athlon; but still, no :)
[23:26] <LaserJock> http://en.wikipedia.org/wiki/List_of_AMD_microprocessors has the answer
[23:27] <hwilde> model name      : Geode(TM) Integrated Processor by AMD PCS
[23:27] <hwilde> cpu MHz         : 499.918;   cache size      : 128 KB;  bogomips        : 1006.15
[23:27] <hwilde> :(((
[23:27] <hwilde> too slow to run the server kernel
[23:27] <hwilde> this make me want to cry
[23:27] <slangasek> not speed, instruction set
[23:28] <LaserJock> hwilde: is the server kernel needed on that machine? I can't imagine it would be
[23:28] <hwilde> I think my phone is faster
[23:28] <hwilde> 128K cache cmon
[23:28] <hwilde> this isn't even worth it.   thanks for all your help /var/log/installer is gold
[23:30] <hwilde> LaserJock, I just had five different people tell me there is no difference except the packages
[23:31] <LaserJock> hwilde: well, the server and generic kernels are different packages :-)
[23:31] <hwilde> yeah, I want the server kernel... why would I download the server cd and go through the whole install just to have it downgrade to generic :/
[23:31] <LaserJock> it's *not* a downgrade
[23:31] <hwilde> ok
[23:31] <LaserJock> well, I guess it is if you have a lot of memory
[23:32] <elmo> it's not a downgrade because the -server kernel _doesn't work on this hardware_
[23:32] <hwilde> failover
[23:32] <hwilde> fallback
[23:32] <hwilde> default
[23:32] <hwilde> whatever
[23:32] <LaserJock> the generic kernel should be fine though
[23:32] <hwilde> it's not the kernel I intended to install is the point.
[23:33] <LaserJock> well, that's too bad for sure, but shouldn't make any difference on that machine
[23:35] <hwilde> slangasek, what is it about the instruction set that is incompatible
[23:36] <slangasek> hwilde: er, "it's too old"?
[23:36] <slangasek> the k6 is an earlier generation of chip
[23:37] <slangasek> the server kernel is targetted to a newer instruction set
[23:38] <hwilde> man this sucks.  I can't quite get ubuntu running perfectly.   it is obviously the hardware.   but the hw ppl counterargument is that xp embedded runs fine :/
[23:38] <slangasek> dude, if Ubuntu isn't running, that has nothing to do with whether it's using the server or generic kernel
[23:38] <hwilde> its runs fine but has a few bugs.  i just tried the server version to see if it would be a little better
[23:39] <hwilde> * attempted to try
[23:39] <wgrant> The server version is just a different set of default packages...
[23:40] <hwilde> wow you're not kidding about old... First Introduction, Apr 2, 1997 (K6 166, 200 and 233 MHz)
[23:42] <hwilde> there are really only three issues, but they are all traced back to the amd chipset
[23:42] <hwilde> 1)  random power button presses.   fixed with acpi=off
[23:42] <hwilde> 2)  sounds stutter   https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.22/+bug/131439
[23:42] <hwilde> 3)  usbs randomly disconnect and reconnect   (no clue)