[00:04] <slomo> slangasek: ok, mono should now build again (not my fault, was broken before :P ) on x86 and friends... could you care for give-backs of gnome-desktop-sharp2 and everything else that failed because of broken mono dependencies after things are working again? :)
[00:05] <slangasek> slomo: you need a buildd admin for that
[00:07] <slomo> doko: ^--- :)
[00:08] <doko> slomo: what is "everything else"?
[00:08] <doko> will do that tomorrow, if you could give some list
[00:10] <slomo> doko: nothing else it seems... well, if i find something else i'll tell you. i thought f-spot or mono-tools could've failed too but they're fortunately still on dep-wait
[00:10] <slomo> doko: so that's only gnome-desktop-sharp2
[00:12] <cody-somerville> There might be a possible regression occurring with Hardy.
[00:12] <cody-somerville> A few people have said that network-manage has quit working after the latest updates
[00:13] <slangasek> nope, it quit working after the previousupdates
[00:13] <slangasek> it works again with the latest updates
[00:13] <cody-somerville> Okay
[00:13] <cody-somerville> So Bug #204897 is Fix released?
[00:13] <ubotu> Launchpad bug 204897 in network-manager "[hardy] Network manager causes CPU load to go to 100%" [Undecided,New] https://launchpad.net/bugs/204897
[00:15] <slangasek> yes
[00:17] <pwnguin> good to know
[00:26] <sectech> My network manager just crashed and came back with a dup from bug #85113
[00:26] <ubotu> Launchpad bug 85113 in network-manager "[apport] NetworkManager crashed with signal 5 in main()" [High,Fix released] https://launchpad.net/bugs/85113
[00:32] <ScottK> sectech: That's correct.  The problem is in hal.  There's a new package that's been built and should show up on a mirror near you soon.
[00:32] <sectech> There was a second update released for it
[00:32] <sectech> ok
[00:34] <sectech> Was your fix  0.5.11~rc2-1ubuntu2
[00:34] <sectech> ?
[00:34] <sectech> whoops... hal  0.5.11~rc2-1ubuntu2
[00:35] <sectech> because that was the one that caused the report.... The version before was the one with the original regression
[00:58] <slangasek> sectech: how have you determined that it's a duplicate of bug #85113?  I don't see that any new bugs have been marked as duplicates of that
[00:58] <ubotu> Launchpad bug 85113 in network-manager "[apport] NetworkManager crashed with signal 5 in main()" [High,Fix released] https://launchpad.net/bugs/85113
[01:00] <slangasek> and if it's not a duplicate, we probably need more information (such as a current backtrace) to track it down
[01:13] <posingaspopular> hey all, im trying to open the source for _gobject.so, under/var/lib/python-support/python2.5/gtk-2.0/gobject, and when i run 'sudo gcc _gobject.so' i get a bunch of compiler errors
[01:13] <posingaspopular> how can i open it to actually read/edit the file though
[01:16] <slangasek> sorry, you're trying to do what?  the source is in the source package, not in /var/lib/python-support
[01:16] <posingaspopular> hmm okay, where do i get the actual source then?
[01:16] <posingaspopular> sorry im new to this
[01:16] <slangasek> apt-get source python-gobject
[01:17] <slangasek> but what do you plan to do with the source?
[01:17] <posingaspopular> unable to find source package
[01:17] <posingaspopular> im looking at a bug right now
[01:17] <slangasek> then you need to add the right deb-src lines to your /etc/apt/sources.list
[01:19] <posingaspopular> which ones?
[01:20] <slangasek> you need a deb-src line for "main", corresponding to the deb lines for your mirror
[01:20] <cody-somerville> posingaspopular, Applications > System > Software Sources
[01:21] <cody-somerville> posingaspopular, Check off the source repositories
[01:21] <posingaspopular> thanks cody
[01:21] <slangasek> ITYM  System -> Administration -> Software Sources
[01:23] <posingaspopular> either way, im running kde :P
[01:30] <posingaspopular> http://paste.ubuntu-nl.org/60485/
[01:30] <posingaspopular> it's not working
[01:31] <slangasek> sudo apt-get update; sudo apt-get source python-gobject
[01:31] <slangasek> is this about the "PySignal_SetWakeupFd" error in your blog?
[01:31] <posingaspopular> yea
[01:31] <posingaspopular> here are my sources list: http://paste.ubuntu-nl.org/60486/
[01:32] <slangasek> which version of python-gobject do you have installed?  The current version doesn't appear to reference that symbol.
[01:32] <keescook> mjg59: solved the libx86 issues.
[01:32] <posingaspopular> hmm how do i check
[01:33] <slangasek> apt-cache policy python-gobject
[01:34] <mjg59> keescook: Really?
[01:34] <keescook> mjg59: yup.
[01:34] <mjg59> keescook: Please don't tell me it was just an updated x86emu :)
[01:34] <keescook> yup
[01:34] <mjg59> Gah. Misery.
[01:34] <posingaspopular> version 2.1.4-2
[01:34] <keescook> I extracted your patches (that took most of the time) and applied the updated x86emu
[01:34] <mjg59> keescook: Well, update it and win :)
[01:34] <mjg59> s/update/upload/
[01:35] <keescook> mjg59: yup, doing final packaging now.
[01:35] <mjg59> Ah well
[01:35] <keescook> mjg59: I basically have 3 patches I extracted: 1 appears to be an ancient version of the inline asm calls, which I have left unapplied.
[01:35] <mjg59> I blame cpuid
[01:35] <keescook> cpuid or rdtsc
[01:36] <keescook> 1 is the process memory patch
[01:36] <mjg59> Hm. Yeah.
[01:36] <keescook> and the other (the real nasty one that took me so long to find) was the "exit when CS==0 IP==0"
[01:36] <slangasek> keescook: is "solved the libx86 issues" as momentous as it sounds? :)
[01:36] <keescook> why is that in our x86emu but not upstream?
[01:36] <keescook> slangasek: yeah, bug 147623
[01:37] <slangasek> w00t
[01:37] <slangasek> posingaspopular: 2.1.4-2 is not the current version; can you upgrade to 2.1.4-2ubuntu1 and see if that fixes it?
[01:38] <slangasek> (I believe that it does)
[01:44] <mjg59> keescook: Thanks for dealing with that!
[01:45] <keescook> mjg59: you bet, it was kind of fun.  ironically, my friend's EDID-lacking BIOS still eludes me.
[01:45] <keescook> mjg59: any thoughts on the extracted patches?  I'd like to understand the CS==0 IP==0 one at least
[01:47] <mjg59> keescook: Oh! I think that's just to make sure that when we return, we immediately bail
[01:48] <keescook> mjg59: without that, upslash freaks out pretty badly.  I'm curious why the lack of that difference isn't an issue for xorg
[01:48] <mjg59> keescook: Yeah, not sure off-hand.
[01:48] <posingaspopular> it works!
[01:49] <posingaspopular> thanks slangasek
[01:49] <mjg59> keescook: But the aim is certainly to ensure that there's a halt instruction when it exits
[01:49] <keescook> slangasek: the debdiff for libx86 is rather sizeable -- should I just shove it in anyway?
[01:49] <slangasek> keescook: is it all bugfixes? :)
[01:50] <keescook> slangasek: in theory :)
[01:50] <slangasek> heh
[01:50] <slangasek> keescook: let's run it through an FFe so we know what we're getting
[01:50] <keescook> I think people will scream loudly if there is a regression in it.  but at the very least, it should fix nvidia and possibly other cards.
[01:51] <slangasek> right, but the people hitting the regression might not scream at just the right time
[01:51] <keescook> slangasek: okay.  worst-case I can extract just the cpuid/rdtsc instruction additions.
[01:52] <slangasek> posingaspopular: no problem
[01:52] <sistpoty> keescook: the 8000er problem? \o/ feel free to abuse me as guinea pig ;)
[01:53] <keescook> sistpoty: sweet.  I'll throw it in a PPA
[01:53] <sistpoty> keescook: source is fine for me as well ;)
[01:53] <mjg59> slangasek: It's basically entirely addition of emulated opcodes
[01:53] <mjg59> slangasek: I can't see any issue with it
[01:53] <keescook> sistpoty: I'll have a debdiff up shortly
[01:53] <sistpoty> :)
[01:54] <keescook> mjg59: well, I could extract _just_ those bits -- but since xorg was so different, this is actually a full refresh
[01:54] <slangasek> mjg59: what does it currently do with opcodes it doesn't know how to emulate?
[01:54] <keescook> aborts.  :P
[01:54] <slangasek> ok, push it :)
[01:55] <keescook> slangasek: err, no FFe?
[01:56]  * keescook is hovering over "submit bug report" button
[01:57] <slangasek> keescook: if the new code is just adding emulated opcodes, and unemulated opcodes cause an abort, I don't see how this can be a regression
[01:57] <slangasek> so I'm fine with that being uploaded without an FFe
[01:57] <keescook> slangasek: I would agree, if that's what I've got packaged presently.  what I have at the moment is a full refresh, which includes other fixes, re-arranged headers, etc.
[01:58] <slangasek> ok, then go ahead and click submit and we'll look at it in more detail :)
[02:01] <flipstar> hi, are there plans to integrate dmraid into the installer?
[02:04] <keescook> slangasek, sistpoty: FFe for libx86 is 204936
[02:05] <slangasek> cody-somerville: is there any sort of timeline for getting the xubuntu alternate CDs tested for release as a beta/
[02:08] <cody-somerville> well
[02:09] <cody-somerville> Sorry, the big bus that brings the testers is late.
[02:09]  * cody-somerville shrugs.
[02:10] <cody-somerville> slangasek, Unfortunately, I can't give any sort of timeline since I can't predict who is willing to volunteer to test and when.
[02:10]  * sistpoty tests, brb
[02:10] <cody-somerville> I'll send an e-mail off to xubuntu-devel to see if I can round up some people who aren't on IRC
[02:11] <slangasek> ok
[02:12] <slangasek> shall I just hold off on xubuntu daily rebuilds in the meantime?  (since turning them on means that these images may be aged out)
[02:12] <slangasek> oh, these images have the broken hal, does that affect anything on xubuntu?
[02:13] <sectech> slangasek,  The crash reporter stated it was a duplicate bug... I'm going to reboot to see if I can reproduce the problem, I'll try and provide more information if it happens again
[02:13] <sectech> one minute
[02:13] <cody-somerville> We use network-manager
[02:13] <jono> has anyone had any network manager breakage when upgrading to the beta?
[02:14] <slangasek> jono: it was a post-beta breakage, should be fixed now in hal -1ubuntu2
[02:14] <slangasek> jono: if not, we need more info, because it's fixed for some people
[02:15] <jono> slangasek: ok, dist-upgrading now
[02:15] <slangasek> cody-somerville: ok, then let me reroll the images /again/, so you get a working n-m :)
[02:16] <slangasek> sectech: quick reboot, how's it look?
[02:16] <sectech> I just rebooted but was unable to reproduce the error from network-manager.   It looks like everything is okay
[02:16] <slangasek> sectech: ok, thanks :)
[02:16] <sectech> thank you for the quick fix :)
[02:17] <slangasek> if it does show up again, please file a bug report; even if it gets marked as a duplicate, it may still give us new information (such as version numbers, etc)
[02:17] <sectech> okay sounds good
[02:18] <keescook> oh, whoops -- I had two checkouts of xorg...
[02:20] <mjg59> slangasek: In principle, it gives a failure. However, I suspect that cpuid was giving it something that gave /an/ answer, just not one that made sense to the BIOS
[02:25] <jono> slangasek: have some pretty significant b0rkage here
[02:25] <sistpoty> keescook: works for me \o/... however there's quite some flickering in usplash and tty1 contains lots of assembly now
[02:25] <jono> slangasek: firstly, I have two kernels -12 and -14 - I need -14 to even see my wireless interfaces, and NetworkManager allows me to manually set the wireless interface but can't enable it
[02:26] <jono> also, the -12 kernel is booting as the default instead of the -14 which seems odd
[02:26] <sistpoty> keescook: also unrelated (since my update of today), my monitor says no signal, when having usplash not installed
[02:26] <sistpoty> s/update/upgrade/
[02:27] <keescook> sistpoty: can you capture the output?  I was missing an options in the previous debdiff.  Can you try the new one?
[02:28] <keescook> s/an options/an instruction/
[02:28] <sistpoty> keescook: sure
[02:28] <sistpoty> (give me a sec)
[02:31] <jono> are these network manager issues known with the beta?
[02:32] <sistpoty> keescook: is there any log where the output might be stored? (if not, I've just taken a photo *g*)
[02:32] <keescook> photo works -- you can also just run "usplash -c -v" manually as root and capture stdout/stderr
[02:34] <keescook> slangasek: I've extracted just the new instructions from upstream, not the whole mess of everything.  this fixes it too -- however, an interesting side effect (that sistpoty has already seen) is that switching to a console vt ... doesn't work.  it needs to do a POST, it seems.
[02:35] <keescook> slangasek: (at least on gutsy)
[02:35] <jono> ok I have to get to bed
[02:35] <jono> night all
[02:36] <sistpoty> gn8 jono
[02:36] <keescook> mjg59: possible regression is putting the video card in a _worse_ state.  :P
[02:40] <sistpoty> keescook: http://www.potyra.de/vt1.photo.jpg
[02:41] <keescook> hrm, fun.
[02:41]  * keescook goes looking for where he missed the debug output
[02:41] <keescook> sistpoty: I've got yet-another-patch to try (same bug).  This one is a minimal debdiff with only the new opcodes.
[02:42] <sistpoty> keescook: ok, rebuilding
[02:44] <sistpoty> keescook, slangasek: should I add my findings to the bug report for documentation, or should I rather not clutter it?
[02:45] <sistpoty> (as /me dislikes cluttered FFe's for universe *g*)
[02:45] <keescook> sistpoty: if the 3rd one behaves the same, then document it.  I'll invalid the FFe if the third one fixes it sanely for you.
[02:45] <sistpoty> ok
[02:46] <sistpoty> brb ;)
[02:48] <keescook> aaaah, upstream changes made debug sane, and thunk.c still had it enabled.
[02:49]  * keescook holds his breath
[02:49] <sistpoty> keescook: 3rd one still works, but tty1 is cluttered with assembly as well
[02:50] <keescook> sistpoty: okay, I think I tracked down the cause of the clutter, but I'm curious why I don't see it on my system.  :P
[02:50] <sistpoty> keescook: should usplash display some text? (the first one did, but I was bitten by a fsck then)
[02:50] <sistpoty> heh
[02:51] <keescook> sistpoty: not unless you have "quiet" removed from your boot arguments
[02:51] <sistpoty> ah, k
[02:53] <sistpoty> keescook: if it helps, I've got a "VGA compatible controller: nVidia Corporation GeForce 8500 GT (rev a1) (prog-if 00 [VGA controller])" (amd64x2, not too sure what's interesting from cpuinfo ;)
[02:54] <keescook> mostly I'm just scratching my head over why I don't get debug output on my system.
[02:55] <keescook> oh!
[02:55] <sistpoty> keescook: hm.. I've installed the kubuntu usplash thingy, and am running kdm
[02:55] <sistpoty> (and I'm usually one day behind with updates, since I use a german mirror)
[02:56] <keescook> yeah, it's all self-contained in libx86 -- it's just weird.
[02:57] <keescook> sistpoty: what were you saying earlier about "no video signal" ?
[02:57] <sistpoty> keescook: if I don't have usplash installed, I don't get a video signal until kdm starts (since an earlier upgrade from this afternoon already, so I guess it's unrelated to libx86)
[02:58] <sistpoty> might be just, that my monitor doesn't support a specific mode though
[03:00] <keescook> sistpoty: hm, i'm seeing an identical situation in my test system -- once x starts, I can't switch to a vt
[03:00] <keescook> or, I can, it's just "no video signal"
[03:00] <keescook> hmpf
[03:02] <sistpoty> keescook: no, once X starts, I *can* switch to a VT when not having usplash installed, but not before that
[03:02] <keescook> sistpoty: and if you have usplash installed, you can switch to/from X okay?
[03:03] <keescook> (this may be simple an issue with the gutsy nvidia driver -- my test machine isn't hardy)
[03:03] <sistpoty> keescook: yes, seems like it doesn't matter if I have usplash installed for that behaviour
[03:03] <keescook> okay, then I don't think there's a regression.  now, the spewing of asm instructions to your console -- is it actually visible?
[03:04] <keescook> (during boot?)
[03:04] <sistpoty> keescook: not during boot, only when switching to it afterwards
[03:04] <keescook> okay, that sounds something we can fix later.  ;)
[03:05] <sistpoty> yes, right now it's still a big improvement.. (and interestingly, when usplash starts, I can see text on my monitor, so I guess switching to tty's would work then, in contrast to not having usplash installed ;)
[03:06] <keescook> hahah true
[03:06] <superm1> what's this big regression that you've been working on exactly keescook ?
[03:06] <keescook> slangasek: okay, sounds like the minimal "only new instructions plus fixes for busted ones" patch is sane.
[03:07] <keescook> superm1: bug 147623 (not a regression, but missing usplash on 64bit nvidia)
[03:07] <superm1> ah
[03:07] <keescook> slangasek: okay to upload it?
[03:11] <keescook> slangasek: based on your earlier "I'm okay with only new opcodes", I'll upload it (and mark the FFe invalid -- I'll upload that bundle for intrepid)
[04:15] <j1mc> slangasek: do you have an ETA on when cody somerville's re-rolled xubuntu-alternate ISO may be ready?
[04:22] <YokoZar> Could someone please retag this bug to much higher priority than low?  It resulted in data loss for me: https://bugs.edge.launchpad.net/ubuntu/+source/gnome-utils/+bug/194127
[04:22] <ubotu> Launchpad bug 194127 in gnome-utils "gnome-screenshot closes when chosing not to overwrite an existing file" [Unknown,Confirmed]
[04:23]  * ScottK2 looks
[04:24] <ScottK2> YokoZar: Please comment to that effect in the bug.
[04:24] <YokoZar> I lost my screenshot as a result, since the window had changed
[04:24] <YokoZar> Sure.  It's sort of in the first comment though
[04:25] <YokoZar> ScottK2: how do I get triage permissions, btw?
[04:26] <ScottK2> I think you have to be a member of one of the bug triage teams.  MOTU will get it for you or you can talk to bdmurray in #ubuntu-bugs if you don't have to wait.
[04:27] <YokoZar> I'll wait a bit then to see if this MOTU thing happens :)  I guess being an Ubuntu member doesn't give it by default.
[04:38] <ScottK2> No.  IIRC it's ubuntu-qa you have to be in.
[04:39] <ScottK2> YokoZar: Is this a regression do you think?
[04:50] <mjg59> keescook: Yeah, make sure the debug enabling code doesn't end up in the distro :)
[04:50] <mjg59> keescook: Any text output should be fatal in the non-debug build...
[04:57] <YokoZar> ScottK2: no I think this bug has been that way since gutsy at least...probably earlier
[04:58] <ScottK2> OK.  I made it medium.  If it'd been a regression I'd have gone for high.
[05:09] <mneptok> may the next month not require a more empty ban list. amen.
[05:10] <pwnguin> what?
[05:10] <pwnguin> that very closely skirts "double negative" territory
[05:12] <mneptok> as all good religion does.
[05:18] <sudobash> yeah i didnt follow that but its cool that you are removing bans
[05:18] <sudobash> remove mine from Ubuntu and Ubuntu-ops
[05:20] <sudobash> please
[05:26] <mneptok> he leaves after i try to find the op that banned him.
[05:27] <mneptok> hrmf. children. ALL OF YOU OFF MY LAWN!
[05:27]  * LaserJock streaks across mneptok's yard
[05:28]  * mneptok waves his fist impotently, in bermuda shorts and black dress socks
[05:29] <slangasek> they have pills now to help with fist impotence, you know
[05:30] <slangasek> or "fistile dysfunction", as they say in the biz
[05:30] <mneptok> AND STAY OFF!
[05:30] <slangasek> heh
[05:30]  * mneptok goes back to his stories and gin
[05:31] <mneptok> ok, no i don't
[05:45] <keescook> mjg59: that's the part I don't understand -- the diff between what I uploaded and what was already uploaded contains no changes to debugging.  (perhaps sistpoty was already using a debug-enabled one?)
[05:45] <keescook> mjg59: I haven't seen the output in my tests.
[05:49] <keescook> mjg59: btw, doesn't an update of libx86 require a update-initramfs run?
[05:49] <keescook> (I could just version-bump usplash....)
[08:14]  * pwnguin has a question about deb tarballs versus the .diff
[08:15] <pwnguin> if you upgrade a package to a new svn revision from upstream, does that go in as a new tarball or a large .diff?
[08:16] <cq> where is the transition from the debian to ubuntu archives controlled, i.e. which debian packages make it over and which don't?
[08:18] <pwnguin> cq: partly, its a matter of the schedule. new packages can come in up until the appropriate freeze, after which there's only exceptional circumstances allowed. but i imagine you're curious about the automated part
[08:18] <cq> no, actually the process... do you take stable or testing, and then freeze it for a release, and rinse, lather, repeat?
[08:19] <pwnguin> you're close
[08:19] <pwnguin> the process is branch unstable where appropriate
[08:19] <pwnguin> then try to stablize that code with various freezes
[08:21] <pwnguin> during that time bugs are filed, patches are applied, etc
[08:22] <cq> ok. so the changes between 7.10 and 8.04 are a whole bunch, depending on what got taken and frozen
[08:22] <pwnguin> can be
[08:22] <pwnguin> and in whole, absolutely different
[08:23] <pwnguin> if no changes come in in six months, that's either  a pretty stable program or a pretty stagnant one
[08:25] <cq> and how do kubuntu and ubunto differ, kubuntu sits on ubuntu with a different installer and KDE, or is there more?
[08:25] <pwnguin> at this junction, kubuntu is a set of packages and an installer within ubuntu repos, no different than say ubuntu-server
[08:26] <pwnguin> originally, it was a small community formed in protest to the decision to select gnome formally ;)
[08:29] <cq> lol ... the usual free software discussions :)
[08:29] <pwnguin> right, and the usual free software response: more software :)
[08:30] <cq> isn't it possible to make ubuntu a subset of debian the way kubuntu is a set of packages?
[08:31] <cq> or is the process to get stuff into debian too long, or is ubunto too different in installation?
[08:32] <pwnguin> ubuntu orginated as a fork of debian for many reasons, and this is starting to veer away from -devel related topics
[08:32] <cq> I'm just interested in teh technical ones, not the political ones...
[08:32] <cq> politics takes too much time :)
[08:32] <pwnguin> well
[08:32] <pwnguin> heh, precisely
[08:33] <cq> i mean, ubuntu feeds stuff back upstream to debian as far as I know
[08:34] <pwnguin> the basic problem with debian that I, having no formal relationship or status within Ubuntu, is that debian is slow and adversarial
[08:35] <pwnguin> rather than attempt to change from within, i think ubuntu has set forth a few good examples of how to do things better socially
[08:36] <cq> man what a lot of distributions... just looking at what distributions are around.
[08:36] <pwnguin> theres a lot of different kinds of people out there
[08:38] <pwnguin> cq: as an example of the difficulties with merging ubuntu back, imagine a scenario where you'l like a patch included as an ubuntu developer, but the debian developer who owns the package disagrees
[08:38] <pwnguin> you can go further upstream
[08:39] <cq> just leaves me wondering where linux would be with 50% less distributions...
[08:40] <pwnguin> it'd be without a flagship USB drive distro, and a ps3 distro, and a build from scratch distro, and a handicap accessible distro, and a forensics distro
[08:40] <pwnguin> and a live cd distro
[08:41] <cq> ...but probably a lot closer to the desktop
[08:41] <cq> i guess the splinter experiments are necessary to show the big ones what to integrate
[08:41] <pwnguin> thats a pretty huge sacrifice
[08:42] <cq> yeah
[08:42] <pwnguin> if you look at the millions apple's spent in the name of marketshare, i'd say throwing all that away in the name of unity is silly.
[08:42] <slomo_> doko: when you're back you could give-back gnome-desktop-sharp2 where it failed, i.e. sparc and powerpc and ia64
[08:42] <superm1> the splinter experiments are appropriate for some corner cases though.  it's the ones that try to re-invent the window and have a better "desktop" OS that hurt
[08:43] <pwnguin> heh, there should be some disclosure here
[08:43] <pwnguin> superm1 works on mythbuntu ;)
[08:43] <superm1> hehe :)
[08:43] <pwnguin> speaking of which, i demand joystick support!
[08:43] <superm1> well but i mean all our development happens in ubuntu though, so we don't do too much harm
[08:43] <superm1> its in
[08:44] <persia> superm1: If you get joystick support, could you also do remote control support for games?
[08:44] <cq> that's what I  mean though, if you get a good base that's configurable, then you need less splinters and the whole thingmoves faster
[08:44] <superm1> well joystick support works, remote control support in games is a challenge to be honest though
[08:45] <superm1> depends on how you have your remote configured if it would be even considered to be possible at this point
[08:45] <persia> How did you do joystick support?  Separate driver support, or merge of Lirc and /dev/input ?
[08:45] <cq> if all you do is change package groups etc. and feed everything back, great.
[08:45] <pwnguin> honestly, i havent tested joystick support since the backport
[08:45] <superm1> persia, the joystick support works off a normal X input device
[08:45] <superm1> well not even X
[08:45] <superm1> just /dev/jsX
[08:46] <superm1> should have said
[08:46] <pwnguin> cq: ubuntu distinguishes itself from debian by embracing, rather than hiding, from users, and predictable release cycles
[08:46] <persia> Ah, but lirc is still separate?  That's what I thought, and was wildly excited for a brief period.
[08:46] <superm1> yeah lirc is still separate.  quite the little bastard kid too
[08:47] <pwnguin> personally, i'd just as soon use a wiimote
[08:47] <superm1> i'm hopefully going to try to triage a bunch of its offspring bugs tomorrow
[08:47] <superm1> not enough buttons on it to be useful
[08:47] <persia> Always good to prune the orchard :)
[08:47] <cq> does ubuntu run on all the systems debian runs on? or is it more focused on the core PC systems
[08:47] <pwnguin> cq: oh, debian still has more arch ports
[08:48] <pwnguin> persia: how many buttons would you need to be useful?
[08:48] <persia> pwnguin: I have four input devices with over 100, and I'm still not happy :p (but I think you didn't mean to ask me)
[08:49] <superm1> pwnguin, you mean to direct that at me ?
[08:49] <pwnguin> ah, yes
[08:49] <superm1> pwnguin, 2x vol, 2x chan, play/pause, stop,ff,rr,skip+,skip-, esc
[08:49] <pwnguin> 2x volume?
[08:49] <superm1> vol+/vol-
[08:50] <superm1> stop and esc can be combined
[08:50] <superm1> so that's 10 buttons to be useful for me
[08:50] <superm1> well and up/down/left/right of course
[08:50] <superm1> 14 :)
[08:50] <persia> 10?  I count 11 (or 15)
[08:50] <pwnguin> the wiimote itself has 11 plus extensions
[08:50] <superm1> play/pause is one
[08:51] <superm1> pwnguin, but they're hardly intuitive however you spin it
[08:51] <pwnguin> home = esc seems reasonable
[08:51] <persia> Ah.  Right.
[08:52] <superm1> okay so arrows = arrows, +/- = either vol +/-, 1/2 is chan+/-, but then you still have all the skips
[08:52] <superm1> and the play pause
[08:52] <cq> http://distrowatch.com/dwres.php?resource=major seems like a good distro comparison
[08:52] <pwnguin> what are the arrows for?
[08:52] <superm1> menus
[08:52] <pwnguin> shouldnt that be seperate?
[08:53] <superm1> you mean external controller?
[08:53] <pwnguin> no, i mean, menu controls seperate from mplayer controls ;)
[08:53] <superm1> oh i'm saying mythtv controls, not mplayer controls
[08:54] <pwnguin> well, im still using mplayer for playback
[08:54] <pwnguin> no tvtuner
[08:54] <superm1> with 0.21, the internal player is fairly nice.  don't necessarily need to call an external player for stuff
[08:55] <pwnguin> what do the arrows do with the internal player?
[08:55] <superm1> large skips
[08:55] <superm1> and if you hit menu to choose menu stuff
[08:56] <pwnguin> i think you could define a set of contexts wherein 10 or 11 buttons would work
[08:56] <pwnguin> but right now, wminput needs work first
[08:57] <superm1> i see.  well if you come up with a good layout, i'll pair one of my wiimotes and give it a shot some day
[08:57] <superm1> :)
[08:57] <pwnguin> no need to pair
[08:57] <pwnguin> just turn off the wii and hit 1+2
[08:57] <superm1> its a standard BT device?
[08:57] <pwnguin> yea
[08:57] <superm1> it doesnt need to pair?
[08:58] <pwnguin> you can tell it to be promiscous
[08:58] <superm1> oh neat
[08:58] <superm1> well that's far more useful then
[08:58] <superm1> i didn't like the idea of having to pair back and forth between the two
[08:59] <pwnguin> lemme have a look at my current binding
[08:59] <pwnguin> it's not the greatest
[08:59] <pwnguin> but it passes for navigation so far
[09:00] <superm1> well i can't test until at least early next week anyhow.  my little usb/bt adapter for pc is in the office
[09:00] <pwnguin> the thing to watch out for is that wminput doesn't set lights
[09:00] <pwnguin> or disconnect on long idle sessions
[09:01] <pwnguin> or handle multiple wiimotes readily yet. and it seems to crash on daemon mode for me on the mythbox
[09:01] <pwnguin> but not on my desktop
[09:01] <pwnguin> i guess what im saying is patches welcome ;)
[09:02] <superm1> hehe
[09:33] <cq> cannot remove /var/lib/apt/lists/lock: read only filesystem  huh??
[09:34] <cq> I have one huge partition, and it's mounted RO for some reason... any ideas?
[09:34] <slangasek> check dmesg for signs of a kernel problem
[09:35] <slangasek> (kernel/disk)
[09:35] <cq> argh.
[09:35] <cq> had that yesterday. "attempt to access beyond end of device".  just did a clean reintsall, still there
[09:36] <cq> memory check was OK... ran that yesterday too
[09:37] <cq> would a fsck solve that problem, or is that a disk or other hardware problem?
[09:40] <TomaszD> pitti, langpack update? Please?
[09:41] <slangasek> cq: I don't know; "attempt to access beyond end of device" could mean that the filesystem and the partition table don't agree about the size of the disk
[09:42] <slangasek> it could mean your hardware has problems accessing very large disks, if this is a new disk?
[09:42] <slangasek> (in an old system)
[09:52] <cq> hm. system is a few years old, not sure how old, disk is 30GB and newer.
[09:52] <cq> fujitsu siemens amilo k 7600
[09:56] <cq> would reinstalling to a smaller partition, say 8gb help?
[09:57] <cq> and use the other one as a user partition?
[09:57] <pwnguin> fg
[09:58] <YokoZar> Do packages pushed to ppa have to have source in tar.gz format, or can I have orig.tar.bz2?
[09:59] <cq> or how can I test if the HD works with the machine?
[09:59] <persia> YokoZar: You may get a better answer to that in #launchpad
[10:00] <YokoZar> persia: do you know of any source restrictions for officially uploaded packages?
[10:00] <persia> I know almost nothing about launchpad internals
[10:04] <pitti> TomaszD: tonight we'll get the latest Rosetta export, and tomorrow early morning the cronjob will build and upload them
[10:04] <TomaszD> pitti, ok
[10:04] <pitti> mjg59: ah, that sounds easy enough; thanks
[10:35] <Festor> Hi all
[10:35] <Festor> Does anyone know why the command update-mozilla-firefox-chrome is not available in beta 4 of firefox 3?
[10:35] <Festor> I am in the beta of Hardy now
[10:35] <pitti> slangasek: thanks for cleaning up after me (hal)
[10:47] <doko> gnome-desktop-sharp2 given back
[10:47] <doko> slomo_: ^^^
[10:47] <slomo_> thanks :)
[10:57] <slomo_> slangasek: if you're awake, can you get the gnome-desktop-sharp2 binary packages accepted from binary NEW? they're finally built on all archs and two packages from main are waiting for it (or more specific libgtkhtml3.16-cil)
[10:58] <Festor> Is there anyone ...?
[10:58] <slomo_> pitti: or you? :)
[10:59] <pitti> slomo_: me?
[10:59] <pitti> ah
[10:59] <pitti> looking
[10:59] <slomo_> you can move gtkhtml3.8 out of main afterwards iirc
[11:00] <pitti> yay
[11:01] <pitti> slomo_: hm, why didn't it build on i386?
[11:01] <pitti> NEW only has sparc, ia64, and powerpc
[11:01] <slomo_> pitti:  	 buildlog_ubuntu-hardy-i386.gnome-desktop-sharp2_2.20.1-2ubuntu2_FULLYBUILT.txt.gz
[11:01] <slomo_> it has :)
[11:01] <slomo_> but that was last night
[11:03] <pitti> ah, they are already NEWed
[11:04] <slomo_> pitti: oh, since when? because f-spot, mono-tools and gnome-rdp are still on dep-wait (hm, MANUALDEPWAIT it says, does this need manual intervention?)
[11:04] <pitti> hm, pretty weird actually
[11:05] <pitti> https://edge.launchpad.net/ubuntu/+source/gnome-desktop-sharp2/2.20.1-2ubuntu2 shows them as DONE
[11:05] <pitti> but they are not in the archive
[11:07] <pitti> slomo_: accepted the ports arches from NEW
[11:08] <pitti> slomo_: I see the .deb on drescher, though; maybe it was just NEWed some 30 minutes ago, and currently being published
[11:08] <slomo_> ok
[11:39] <lool> Cool, gold released
[11:39] <lool> http://sourceware.org/ml/binutils/2008-03/msg00162.html
[12:42]  * Hobbsee looks for when uds starts
[12:43] <Hobbsee> oh, may, 2 months away
[12:52] <zul> hey Hobbsee
[12:53] <Hobbsee> hi zul
[12:55] <Festor> jdong, are you here?
[12:55] <delfick> hello. I just tried compiling this here https://bugs.launchpad.net/ubuntu/hardy/+source/sane-backends-extras/1.0.18.12 (released an hour ago) and got these errors http://paste.ubuntu-nl.org/60522/
[13:12] <_MMA_> Hmm....On the SANE subject, I cannot open any of the devices seen buy it. Tells me they're all busy. Grr...
[13:18] <stgraber> my network scanner worked fine last I tried, but the server which it's attached to isn't running hardy only clients are
[13:20] <_MMA_> stgraber: Yeah. I bought a 8 year old flatbed because I knew it fully worked. Worked under Hardy 2 days ago. Not today. :( Everything that I can pick through the SANE dialog wont. Webcam either.
[13:33] <mjg59> keescook: Hm. Yeah, I guess so.
[15:10] <slomo_> doko: about libffi... what's the -dev package exactly called? pygobject b-d on libffi-dev, is that fine? if so you can request binNMUs for pygobject, totem and rhythmbox at least (the last two dep-wait on the binNMU of pygobject)
[15:11] <doko> slomo_: hmm, well, yes, hope somebody does ...
[15:12] <slomo_> doko: so... libffi-dev 3.0.4-1 is the new thing?
[15:13] <doko> slomo_: yes
[15:15] <slomo_> doko: ok, so that essentially means: pygobject binNMU and binNMU of all rdepends of pygobject that depend on libffi4... good
[15:19] <doko> slomo_: how is this ubuntu related? ;-p
[15:19] <slomo_> doko: not at all, but you're here ;)
[15:26] <ion_> seb128: Oh dear. The archive backend in gvfs would have been sooo awesome. I take it there's absolutely no way to get libarchive to main?
[15:28] <seb128> ion_: what are you speaking about?
[15:29] <seb128> ion_: did you read the "for now" in the changelog entry?
[15:30] <seb128> ion_: there is no such hurry that I should start annoying people during a weekend and holidays to get libarchive promoted right now, that will wait for next week
[15:36] <ion_> seb128: Alright
[15:38] <seb128> ion_: you are welcome to write the mir bug if you want to get it quickly though ;-)
[15:39] <ion_> No hurry, just something that would be really nice to have, perhaps even as a default unpacker.
[15:42] <seb128> ion_: the code is really new and not tested, I doubt than making it the default for anything now would be a good idea
[15:42] <ion_> Ok
[15:42] <seb128> ion_: we will likely use it to allow to browse iso for examples which is is not possible right now but that's about it
[16:01] <ScottK2> doko: Is the python component of gnome-menus really significant enough to warrant it being in Pythoneers?  I seem to get a lot of non-Python bugmail on that package (being a KDE user, I really don't know anything about that package).
[16:02] <doko> ScottK: maybe not, but I've still a report about it pending in python-central
[16:02] <ScottK2> OK.  Just thought I'd mention it.
[16:03]  * ScottK2 finds it somewhat distracting, but I ignore enough bugmail as it is, I little more isn't a major burden.
[16:03] <slomo_> doko: the mono-CPPFLAGS issue is fixed in svn now btw :)
[16:03] <doko> \o/
[17:02] <slomo_> slangasek: present for you, mono-tools builds now too :)
[17:07] <jono> hey
[17:07] <jono> has anyone had any network manager problems with the beta?
[17:17] <stgraber> jono: like eating all your CPU ?
[17:18] <jono> stgraber: networking brokewn
[17:18] <jono> my wirless interface doesnt seem to work anymore
[17:19] <stgraber> there was a problem with NM entering an infinite loop when starting wireless but that was yesterday and was fixed by the new hal
[17:19] <stgraber> so your issue is probably another bug
[17:20] <jono> also - there seems to be two kernels on my system and the older one is booting
[17:20] <jono> any idea about that?
[17:20] <superm1> jono, somehow a -386 and a -generic?
[17:21] <jono> superm1: I have versins -12 and -14
[17:21] <superm1> oh
[17:22] <stgraber> AFAIK only -12 isn't complete yet (miss the module packages)
[17:22] <jono> so I should use -12?
[17:22] <jono> werm
[17:22] <jono> -14?
[17:22] <stgraber> erk, I meant -14
[17:22] <stgraber> so you should use -12
[17:23] <superm1> i dont see a -14 in apt.  is it 2.6.24-14-generic?
[17:23] <jono> so I should use -12?
[17:23] <stgraber> superm1: I don't see it either on amd64 but saw linux-source uploaded last week
[17:23] <superm1> ah
[17:25] <jono> ok, let me test -12 again
[17:26] <jono> its odd - I see three Wired network interfaces
[17:26] <jono> no wireless interfaces
[17:27] <jono> I have this thing called wlan0_rename
[17:27] <jono> any idea what that is?
[17:28] <seb128> that's the one you should be using
[17:28] <jono> seb128: it says eth0 ad eth1 have no wireless extensions
[17:28] <seb128> use the wlan0_rename
[17:29] <seb128> it's udev doing the renaming or something
[17:29] <jono> but in the NM manual config - it lists Wired connecton, Wired connecton, wired connection and Point to point connection
[17:31] <jono> seb128: any idea what it could be?
[17:31] <seb128> no
[17:31] <jono> ok, will file a bug
[17:31] <mbt> Heya... does anyone know if there is a reason that the "bitchx" package is missing from Hardy?
[17:31] <johanbr> jono: Sounds like an old udev bug (that I thought was fixed?).
[17:32] <jono> johanbr: any way I can check?
[17:33] <johanbr> jono: You can try moving /etc/udev/rules.d/70-persistent-net.rules out of the way. It should be regenerated, and if you're lucky that'll fix your bug.
[17:33] <johanbr> Do you have a Broadcom card, by any chance?
[17:34] <jono> nopew
[17:38] <jono> johanbr: so I need to reboot after moiving that udev rule?
[17:38] <johanbr> yes
[17:38] <jono> ok doing so
[17:38] <jono> lets see if this works
[17:40]  * _MMA_ is having a issue with SANE between Alhpa6 and Beta where SANE tells me all my devices are busy. I don't know if it's a SANE or underlying system issue. :-/
[17:40] <jono> johanbr: no change
[17:42] <johanbr> jono: Okay, then it may be a bug slightly different from the one I was thinking of, but one that manifests itself in the same way.
[17:42] <johanbr> Can you connect with the wlan0_rename interface?
[17:44] <jono> johanbr: let me try
[17:45] <jono> nope, and I now have no option to Enable Wirless since I renamed that udev rule
[17:51] <johanbr> jono: But it did regenerate the file? Maybe you should move the old one back in any case. And file a bug, I guess.
[17:51] <jono> johanbr: it did re-generate it
[17:51] <jono> will move it back
[17:52] <jono> hmm in gutsy I needed a restricted driver for this card
[17:52] <jono> but it is not listed in restricted manager here
[17:52] <johanbr> What kind of card is it?
[17:52] <jono> not sure - its the intel card in the Dell XPS1330
[17:53] <jono> sorry, the M1330
[17:53] <johanbr> That's normal, I think it uses the iwl driver now.
[17:53] <jono> right
[17:55] <jono> johanbr: see https://bugs.edge.launchpad.net/ubuntu/+bug/205215
[17:55] <ubotu> Launchpad bug 205215 in ubuntu "Wireless networking broken in Network Manager" [Undecided,New]
[17:56] <jono> ahh :)
[17:56] <johanbr> jono: Discovered something?
[17:56] <jono> no
[17:56] <jono> just ubutu showing my bug description :)
[17:59] <johanbr> jono: Can you attach the output of "ifconfig -a" and "iwconfig" to the bug?
[18:00] <jono> ok - one sec, will need to put it on a usb keyring
[18:05] <jono> johanbr: ok, bug updated - https://bugs.edge.launchpad.net/ubuntu/+bug/205215
[18:05] <ubotu> Launchpad bug 205215 in ubuntu "Wireless networking broken in Network Manager" [Undecided,New]
[18:07] <johanbr> jono: Alright. Looks like wlan0_rename is your real wlan interface and eth1 is the master interface that goes along with it. This is probably caused by a bug in the udev scripts.
[18:07] <jono> johanbr: right
[18:08] <jono> johanbr: is there anything else I can do to help fix this?
[18:09] <johanbr> jono: Maybe also attach the contents of 70-persistent-net.rules. I'm not sure why you can't connect, though. This bug should just be cosmetic.
[18:10] <jono> johanbr: will do, what do you mean by cosmetic?
[18:10] <johanbr> That apart from your interfaces having weird names, it shouldn't hurt anything.
[18:11] <johanbr> Your connection problem may be a separate issue.
[18:11] <jono> right
[18:17] <jono> johanbr: see https://bugs.edge.launchpad.net/ubuntu/+bug/205215 no
[18:17] <jono> now
[18:17] <ubotu> Launchpad bug 205215 in ubuntu "Wireless networking broken in Network Manager" [Undecided,New]
[18:18] <jono> added the udev bits
[18:18] <jono> and some details of the network card
[18:35] <xhaker> jono: bug 205215 i've just commented
[18:35] <ubotu> Launchpad bug 205215 in ubuntu "Wireless networking broken in Network Manager" [Undecided,New] https://launchpad.net/bugs/205215
[18:37] <xhaker> jono: you also do not need a restricted driver since the driver for 3945 no longer needs the binary only daemon from the previous driver ipw3945
[18:41] <jono> xhaker: will try editing the file now
[18:43] <xhaker> jono: it should work after that, but someone needs to do some migration script
[18:58] <nosrednaekim> hey, is there someone here who is familiar with the system-config-printer code?
[19:03] <slangasek> pitti: no problem :)
[19:03] <slangasek> slomo_: mono-tools> nice, thanks :)
[19:06] <slangasek> jono: there is no 2.6.24-14 kernel in the archive, what exactly are the kernel versions you're seeing on your machine?
[19:10] <ion_> Wow, sabdfl has apparently been funding GEGL development. Awesome.
[19:17] <sebbar> hi, is there a reason why xv isn't in the repositories?
[19:21] <sistpoty> sebbar: imo it was removed from unstable ages ago, so we followed debian there
[19:23] <sebbar> sistpoty: hm that's a pity, I think it still has quite a user base (at least it's the standard tool at my university...)
[19:24] <mjg59> There were distribution issues
[19:42] <sistpoty> doko: can you give back hslogger on sparc? Thanks!
[19:44] <doko> sistpoty: done
[19:44] <sistpoty> thanks!
[20:19] <laga> slangasek: can you enlighten me how to tell d-i (or whatever is responsible on the alternate disks) to install a udeb?
[20:29] <slangasek> laga: is this a udeb that you're including on a CD?
[20:29] <laga> slangasek: yes.
[20:29] <slangasek> laga: do you want it installed unconditionally?
[20:31] <laga> slangasek: no.. only when the users chooses it in gfxboot. we've already got the part in place (copied from LTSP). that's our current preseed: http://www.pastebin.ca/953113
[20:31] <laga> (although i have noticed that mythbuntu-client-builder/run is the wrong template name, maybe it'll work automagically once it's fixed? i have *no clue* how d-i works)
[20:35] <slangasek> laga: hmm, that's more complicated than I was thinking
[20:36] <laga> slangasek: i think LTSP is doing the same with ltsp-client-builder. i just dont know how they do it
[20:36] <slangasek> I don't either
[20:37] <laga> i'll have to bug ogra then..
[20:37] <superm1> well maybe at least get the template fixed right now
[20:37] <superm1> and see if that resolves it
[20:37] <slangasek> I would be inclined to just make the udeb a priority: standard udeb, and give it a postinst that only triggers based on the preseeded values
[21:40] <laga> slangasek: okay. and how do you make it so it gets installed?
[21:53] <slangasek> laga: if it's to be installed unconditionally, you can do that just by setting the udeb package priority right
[21:53] <slangasek> i.e., Priority: standard
[21:59] <bigon> does somebody know who is in charge for calling external thumbnailers on gnome? nautilus?
[22:02] <sistpoty> doko: I guess you don't have a quick fix to the build failure of atlas on i386 as well (https://launchpad.net/ubuntu/+source/atlas/3.6.0-21.1ubuntu2/+build/510163)... If not, I'll upload a version, which simply doesn't bail out on failed tests, though I know that's not fixing the real bug :(
[22:04] <sistpoty> (of course any good advice would be highly appreciated as well ;)
[22:05] <doko> sistpoty: I don't care that much, of course if you could get a working 3.8 into hardy, that would be even better
[22:06] <doko> but kmap already tried, it's non-trivial
[22:06] <sistpoty> doko: I doubt I have the skills to do so... atlas is a beast for me
[22:07] <doko> not just for you
[22:08] <lamont> do we still support 486 machines, or is pentium the new bottom-class machine?
[22:08] <sistpoty> heh
[22:12] <doko> lamont: yeah, we should drop that for hardy+1
[22:12] <lamont> doko: meh.
[22:12] <lamont> they're still nice machines...
[22:12] <lamont> and fast with no fans :-)
[22:13] <doko> lamont: and please fix gcj for hppa ;-p
[22:14]  * lamont tries to remember which of the languages he doesn't know is implemented by gcj
[22:14] <sistpoty> lamont: do 486 machines exist with enough mem to actually install hardy? I know that p5 exist with large mem, but 486?
[22:15] <slangasek> I was going to joke that it was the "GNU compiler for Japanese", but then I remembered
[22:15] <Nafallo> slangasek: not that big difference or what? ;-)
[22:16] <slangasek> Nafallo: that fails the "that lamont doesn't know" criterion
[22:16] <lamont> slangasek: heh
[22:16] <Nafallo> :-)
[22:16] <lamont> sistpoty: nfc.  I think I have one out in the shed - maybe I'll give it a go
[22:17] <lamont> minimal install, of course.
[22:17] <ion_> What's a typical amount of memory for a "high-end" 486 box? 32 MiB? I think that should be enough for hardy (that is, ubuntu-{minimal,standard} installed)
[22:17] <doko> no, we should just have 686 as the default for hardy+1
[22:17] <Nafallo> doko: agreed
[22:17] <doko> anything else should be built as an embedded target
[22:17] <lamont> it's also possible that gcj is one of the packages blocked on waiting for debian to switch over to nptl so that enough people care that the (alleged) bugs in hppa's nptl impl get sorted.
[22:17] <ion_> At least 64 MiB is far more than enough. :-) (Running on a laptop with 64 MiB of RAM right now)
[22:18] <sistpoty> ion_: I tried imo dapper once with an 8mb laptop. I stopped, after locales generation wasn't finished after a night ;)
[22:18] <ion_> Hehe
[22:20] <lamont> doko: what I need is a small and simple test program that reliably fails.  gcj doesn't fit the "small and simple" criteria.
[22:21] <doko> lamont: a HelloWorld.java does fail
[22:23] <lamont> also not exactly "small and simple" once it drags in the jre.
[22:28] <doko> lamont: yeah, but apparently *this* is the problem. the testsuite itself looks ok
[22:29] <lamont> doko: there should be a porter machine for hppa sometime soonish
[22:30] <doko> lamont: that would be cool, although I do offer my A500 to everyone who wants to have access
[22:30] <lamont> cool
[22:30] <ion_> My brain has been hardwired to expand "A500" as "Amiga 500".
[22:31] <doko> your brain is likely to fail ...
[22:32] <lamont> ion_: doko has that m68k hppa emulator running there
[22:33] <ion_> lamont: :-)
[22:33]  * lamont undertakes to understand why gnome-screensaver needs to have read access to /var/lib/misc/shadow.db when 'db' is present in nsswitch.conf
[22:33] <doko> I refuse to setup this beast on amd64 as well ,-p
[22:33] <lamont> because, well, that's stupid
[22:39] <lamont> and making gnome-screensaver run sgid shadow doesn't help, since it politely throws away all its privs, or some such
[22:46] <jdong> ah, beautiful bug
[22:47] <jdong> networkmanager CPU-spins connecting to a WPA2 network
[23:12]  * lamont ultimately just files bug 205345
[23:12] <ubotu> Launchpad bug 205345 in gnome-screensaver "if passwords are in nss 'db', gnome-screensaver requires world read access to shadow.db" [Undecided,New] https://launchpad.net/bugs/205345