[00:01] <chrisccoulson> LimCore - I'm unfortunate enough to run the Nvidia drivers, and I don't experience any of your issues
[00:01] <LimCore> chrisccoulson: do you often switch VTs?
[00:01] <chrisccoulson> quite often
[00:02] <chrisccoulson> and i share the computer with fast-user-switching most of the time too
[00:02] <chrisccoulson> so, multiple X sessions are open aswell
[00:02]  * LimCore got an idea.  brb 1 month :)
[00:02] <chrisccoulson> lol
[00:03] <chrisccoulson> when a user logs in to their session, what component is responsible for restoring that users chosen screen resolution?
[00:03] <chrisccoulson> is it gnome-settings-daemon?
[00:07] <james_w> chrisccoulson: it is
[00:07] <james_w> chrisccoulson: if that resolution was set with the screen resolution capplet
[00:07] <Hobbsee> chrisccoulson: could be kde-specific, incidently
[00:07] <chrisccoulson> thanks james_w, i thought it might be the case
[00:09] <chrisccoulson> i was just looking at bug 305604, where the reporter says that opening a failsafe session should use the default resolution. i wasn't sure if that would be a gnome-session or a g-s-d request though (or both)
[00:10] <chrisccoulson> what happened to ubottu?
[00:10] <Pici> It'll be back in a moment.
[00:11] <chrisccoulson> thanks:)
[00:12] <chrisccoulson> james_w - i was thinking about the PK and LTSP issues earlier. Perhaps the real problem is that the default policy is too restrictive
[00:13] <chrisccoulson> for example, i can appreciate why its necessary to restrict actions such as shutting down the machine to users on the active console, but i'm not sure why it's necessary to restrict adminstrators from changing settings (ie, with users-admin) when they're logged in remotely (ie, with LTSP)
[00:15] <james_w> chrisccoulson: can that distinction be represented in PK?
[00:17] <chrisccoulson> i think so. for example, the policy for changing system settings could be set to "Admin Authentication" for active console, console and anyone. This would allow administrators to authenticate using PK whether they were on the local machine or logged in remotely.
[00:17] <chrisccoulson> that would be similar to pre-policykit days
[00:17] <chrisccoulson> but you could keep the policy for other actions (such as shutting down the machine) as they are now#
[00:18] <chrisccoulson> perhaps i should bring this up on one of the mailing lists for discussion?
[00:24] <james_w> chrisccoulson: I think sending a mail would be a good idea
[00:25] <chrisccoulson> thanks, i'll do that in the morning
[00:25] <chrisccoulson> when i'm slightly more awake!
[00:25] <james_w> :-)
[01:38] <pckchem> Whats the package that handles the login screen?
[01:42] <pckchem> nm, found it.
[01:44] <ziroday> Hi, what more information is needed to mark https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/116752 as triaged or confirmed?
[01:46] <pckchem> ziroday: Lemme look
[01:48] <ziroday> pckchem: any ideas?
[01:49] <pckchem> pckchem: Trying to figure out which part of the kernel is causing this...
[01:50] <pckchem> ziroday: Wow, never done that typo before.
[01:50] <ziroday> pckchem: any info it needs? About to upload everything needed listed in https://wiki.ubuntu.com/DebuggingKernelOops however this does not appear to be a kernel oops
[01:51] <pckchem> ziroday: Give me a second, and no it isn't really an OOPs.. You tend to notice those...
[01:55] <pckchem> ziroday: Yeah, from what I can tell, there isn't enough information to figure out whats causing the problem. It needs general kernel debugging first.
[01:55] <ziroday> pckchem: link?
[01:55] <pckchem> ziroday: The Minimal information section on https://wiki.ubuntu.com/KernelTeamBugPolicies should be enough
[01:55] <pckchem> to at least get started
[01:55] <ziroday> pckchem: shall read, thanks
[04:56] <maco> should this be considered a bug? if i go to users-admin and hit Unlock, then i ignore the gksu box for a few moments to do something else, an authentication error box comes up even though i haven't done anything. entering the correct password in the still-open gksu box just closes that window and does not authenticate at all.  i assume it's some sort of timeout?
[04:57] <maco> it says "Could not authenticate. An unexpected error has occurred." and that comes up on subsequent clicks of the Unlock button
[04:58] <pckchem> hmm, let me see if it happens to me
[04:59] <maco> im on intrepid
[04:59] <pckchem> Good, me too.
[04:59] <pckchem> Hmm, yep happens to me too
[05:00] <pckchem> This *might* be intentional behavior, but I don't know enough to confirm
[05:01] <maco> the fact that it keeps doing it on clicks of the Unlock button later til you exit and reopen the app is *annoying*
[05:02] <pckchem> Haha, yeah I could see that, but when you enter the right password it goes away.
[05:02] <pckchem> Arguably, nobody else but the sysadmin should be unlocking that interface, because it lets you reset the root password
[05:02] <maco> when i entered the right password, the password box went away, but it didnt unlock
[05:03] <maco> and then hitting unlock wouldnt bring the password box back at all
[05:05] <pckchem> Really? Mine unlocked....
[05:06] <maco> i can try again...maybe i messed the password...
[05:06] <pckchem> I only get that authentication error if I ignore the box, or I close it after I ignore it.
[05:06] <maco> nope tried again
[05:07] <maco> if i ignore the box, i get the authentication error
[05:07] <maco> then i close the error and the password box stays open
[05:07] <maco> i put the password in, and it doesn't unlock
[05:07] <maco> if i put the password in before the authentication error comes up, it unlocks fine
[05:07] <pckchem> Ok, wait thats not how I did it, let me try again
[05:09] <pckchem> Wow, OK yeah, If i do it that way i can reproduce
[05:09] <maco> ok...im gonna file this then
[05:09] <pckchem> If you want to write up a bug report I'll confirm it for you. Seems pretty easy to reproduce
[05:09] <maco> hm should check with another policykit app
[05:10] <maco> er, what else uses PK?
[05:10] <pckchem> services
[05:11] <pckchem> almost the whole admin menu actually...
[05:11] <maco> really? i just installed intrepid 2 days ago. so i only know what uses it in hardy :P
[05:11] <maco> login window does not use PK
[05:12]  * maco waits to see if Services times...oh there it is
[05:13] <maco> yah, same in Services
[05:13] <pckchem> Ok, by almost the whole thing, I mean services, users, time
[05:13] <maco> haha
[05:14] <pckchem> <- Sorry I'm trying to overclock my vista box at the same time.
[05:14] <pckchem> You DON'T want to mess up while inserting a FSB Freq...
[05:17] <pckchem> I swear there is more though...
[05:37] <maco> pckchem: ah, its already filed bug 201184
[05:37] <maco> it was filed a while ago...
[05:38] <maco> im gonna hit the Me Too
[05:48] <pckchem> me tood and escalated to medium importance since its a core util. Thanks for writing that up.
[05:48] <maco> pckchem: i didnt write it up. it was filed in march
[05:49] <pckchem> Whoa, didn't look at the date.
[05:50] <maco> hrm, i feel like using an OOo icon to represent a .glade file is a little um, odd
[06:00] <calc> maco: eh, why is it doing that?
[06:00] <maco> stupidity?
[06:00] <maco> i have a .glade on my desktop and it shows the OOo Document icon
[06:03] <pckchem> what is .glade supposed to be mapped to?
[06:03] <pckchem> <- get same thing
[06:04] <tcole> glade
[06:04] <tcole> it's a Gtk UI builder
[06:06] <pckchem> Hmm, maybe the xml is similar enough?
[06:06] <pckchem> Nope, just set that way. Ubuntu knows its a glade project.
[06:06] <pckchem> *shrug(
[06:07] <maco> :-/ Intrepid's OOo 2.4 displays files differently than Hardy's OOo 2.4
[06:08] <calc>   <generic-icon name="x-office-document"/>
[06:08] <calc> thats why apparently
[06:08] <calc> x-glade mimetype uses the x-office-document icon
[06:09] <calc> this is under /usr/share/mime/
[06:09] <maco> oh. i think itd make sense if it showed glade's logo
[06:09] <calc> well yea i think it probably shouldn't use that icon
[06:11] <calc> in any case its not OOo that is screwing it up, whatever created that association needs to be improved though
[06:11] <calc> it looks like it might be in shared-mime-info
[06:12] <maco> oh, i figured it wasnt OOo
[06:13] <maco> but i didnt know what decided which icon to use. i was guessing gnome and kde probably had different ways of doing it
[06:13]  * calc is in charge of OOo which was why he was checking it out to make sure it wasn't somehow at fault
[06:14] <maco> ah ok
[09:13] <PietVanraad> Let's say I've found a bug, how do I go about fixing it, how to get the source of a package, how do I edit (this I probably can), how do I recompile and rerun and how do I produce a patch?
[09:20] <maco> PietVanraad: apt-get source <package>
[09:20] <maco> then make your changes
[09:20] <maco> get the debhelper scripts installed
[09:21] <maco> and do "dch -i" in the source directory and itll take you to edit the changelog. then you can recreate the new source package with "debuild -S -sa" and use pbuilder to build a binary package. install the binary to test it. if it works, yay!
[09:22] <maco> then to make a debdiff, run, from the directory where the .orig.gz and all are: debdiff old-package.dsc new-package.dsc
[09:22] <maco> the debdiff is the patch you attach to the bug
[09:23] <PietVanraad> wow, thanks a lot, I'll copy past that! very helpfull
[09:24] <maco> ask someone else how to use pbuilder though. i had help setting mine up and now i forget how