[00:23] <smspillaz> RAOF: hi
[00:23] <smspillaz> RAOF: so turns out we don't need screen crtc pixmaps to do what I want
[00:23] <RAOF> Funkysauce.
[00:23] <smspillaz> RAOF: I did it using a trick in xcomposite
[00:24] <smspillaz> RAOF: so now all we need is for lightdm to implement a simple compositor and have that carry through into the session until compiz tries to replace it, if at all possible
[00:25] <RAOF> Probably fairly simple.
[00:25] <smspillaz> and then in the logout case, if it's possible to allow lightdm to "take over" a currently running x server, then have it's compositor replace the gnome-session one which will replace the compiz one
[00:25] <smspillaz> and ta-da, no flicker! :)
[00:26] <smspillaz> RAOF: actually, even for the restart case, it looks really cool
[00:26] <RAOF> What's the XComposite trick?
[00:27] <smspillaz> instead of going CLUNCK, flashflashflashflashflash, VANISH, BOOM (shift)
[00:27] <smspillaz> it's just *stop* *start
[00:27] <smspillaz> RAOF: oh, the new compositor doesn't take the selection until it's painted at least one frame
[00:27] <smspillaz> so the old compositor stays around until the new compositor has done this
[00:28] <RAOF> Nifty
[00:29] <smspillaz> (basically, there's a property that the outgoing and incoming compositors set on the window used for the composite selection which says they support the handoff protocol
[00:30] <smspillaz> so when the new compositor comes in, it checks for the existence of the protocol, and doesn't try to do CompositeRedirectManual, but instead does CompositeRedirectAutomatic and *doesn't* touch the composite overlay window
[00:30] <smspillaz> and then it paints one full frame
[00:30] <smspillaz> and then it takes the selection
[00:31] <smspillaz> upon losing the selection, the old compositor checks the new selection owner for the property, and if that's present, it doesn't unmap the composite overlay window or touch it in any way (but it does redirect using CompositeRedirectManual)
[00:31] <smspillaz> err, *unredirect
[00:31] <smspillaz> then the new compositor waits for the old one to finally go away, and does a redirect using CompositeRedirectManual, but the output window is still visible
[00:32] <smspillaz> (because both have a reference on it)
[00:32] <smspillaz> however, the only caveat so far is that it makes the giant assumption that you will lose the composite selection, which is a problem if you went from compositor to no compositor
[00:33] <RAOF> Heh.
[00:33] <smspillaz> so if you replace compiz with an unpatched metacity your screen hangs
[00:33] <smspillaz> (mostly because of the loose marriage between 'compositor' and 'window manager')
[00:34] <smspillaz> I suppose I could make a new selection, but then I'd have to resort to checking incoming properties on the root window and I've found that to be racy
[00:34] <smspillaz> or it could just time out
[00:38] <smspillaz> RAOF: what I *really* want to do though is enforce compositing, like maybe we can do something in gnome-session to always try and composite the screen if it stops being composited or whatever, but that's really hard to do because of the way selections work
[00:39] <RAOF> I wouldn't mind, personally, if the answer to "what happens if you run an unpatched metacity" was "it breaks".
[00:39] <smspillaz> RAOF: s/metacity/xmonad/
[00:40] <smspillaz> think of the people who will ditch ubuntu for arch :p
[00:40] <RAOF> s/metacity/*/
[00:40] <RAOF> unity-greeter could quite happily only do this when running an "Ubuntu" session, which we know will start Unity.
[00:40] <smspillaz> yeah I suppose
[00:41] <smspillaz> and then we could just ignore --replace except when allowing it inside of unity
[00:41] <RAOF> And could start compiz with "--compositor-handoff"
[00:41] <smspillaz> but *gosh* that's a hack :p
[00:41] <jbicha> similar idea to what GDM is doing with it being part GNOME Shell now if the hardware supports it
[00:41] <smspillaz> yeah
[00:41] <smspillaz> I'm not really keen on running compiz on lightdm
[00:42] <smspillaz> *thinks of the security implications*
[00:42] <RAOF> And it's slow on startup.
[00:42] <smspillaz> compiz by itself is really fast to start
[00:42] <smspillaz> it could be faster
[00:42] <RAOF> Oh, right.  I was thinking a full session compiz. :)
[00:42] <smspillaz> but if you did composite --replace composite opengl its pretty much instance :)
[00:42] <smspillaz> err
[00:42] <smspillaz> *compiz
[00:43] <smspillaz> RAOF: I'm more thinking of
[00:43] <smspillaz> "hey, install this BLING BLING plugin"
[00:43] <smspillaz> "GLScreen::glPaintOutput () { execl ("/bin/bash"); }
[00:44] <jbicha> my software center is busted, are y'all having any problems with it?
[00:44] <RAOF> Nope.  Well, apart from my self-inflicted PolicyKit wound.
[00:45] <smspillaz> I wonder if its possible to use PolicyKit for things other than granting root permissions
[00:45] <RAOF> Yes, absolutely.
[00:45] <smspillaz> oh, cool
[00:46] <jbicha> I get a blank white window and this is the only output on the terminal: http://paste.ubuntu.com/705203/
[00:46] <smspillaz> I was thinking of something like being able to have a "blessed" screensaver window
[00:46] <RAOF> It'll become more possible once https://bugs.freedesktop.org/show_bug.cgi?id=41025 gets accepted, too :)
[00:46] <ubot2> Freedesktop bug 41025 in daemon "Add an ‘owner’ user to actions." [Enhancement,New]
[00:46] <RAOF> smspillaz: PolicyKit doesn't actually grant root permissions anyway; it's just a way for $DAEMON to check whether $CLIENT should be able to perform $ACTION.
[00:46] <smspillaz> I figured
[00:47] <smspillaz> RAOF: and I suppose it gives keys or somesuch to applications so you don't have to authorize it all the time ?
[00:48] <RAOF> Depends; you can define that in the action description: http://hal.freedesktop.org/docs/PolicyKit/polkit-conf.html#conf-declaring-actions
[00:51] <RAOF> Although until that patch gets applied your $DAEMON needs to run as root for PolicyKit to be useful.
[00:52] <jbicha> pitti: python plugins are broke in Totem (libpeas again) bug 855100
[00:52] <ubot2> Launchpad bug 855100 in totem "python plugins not working" [Undecided,Confirmed] https://launchpad.net/bugs/855100
[01:10] <smspillaz> RAOF: neat
[05:19] <RAOF> Baurgh.  What part of gdk_x11_display_grab are you not understanding, damnit?
[06:01] <RAOF> Bah!  Of course, my old nemesis, XSync.
[06:14] <smspillaz> RAOF: :)
[06:15] <smspillaz> RAOF: or XNextEvent
[06:16] <RAOF> For my future self, in the hope that writing it down again will make it stick: If you call XGrabServer, it's a good really idea to XSync afterward if you expect it to take effect properly.
[06:16] <smspillaz> yeah
[06:16] <smspillaz> uhh actually
[06:16] <smspillaz> XGrabServer is synchronous iirc
[06:16] <smspillaz> it's XUngrabServer that isn't
[06:16] <smspillaz> or is it not synchronous?
[06:17] <RAOF> smspillaz: So, turns out that if you fork quickly enough you can get in before XGrabServer takes effect.
[06:17] <smspillaz> since if that's the case there's lots of code in compiz that depends on sever grabs (because we send synthetic events)
[06:17] <RAOF> XGrabServer was not sufficiently synchronous for my testing.
[06:17] <smspillaz> RAOF: hmm ok, I think I'll need to do XSync directly befor and after XGrabServer then
[06:17] <smspillaz> *before
[06:18] <smspillaz> well really, when you do XGrabServer, you should first do XSync, then XSynchronize, then XGrabServer, then do your stuff, then XUngrabServer
[06:18] <RAOF> In my case, I was trying to check that I correctly handled the case where XGrabServer causes check_gl_texture_size to hang waiting for XOpenDisplay.
[06:18] <smspillaz> then XSynchronize (false)
[06:18] <smspillaz> RAOF: ah, yikes
[06:19] <RAOF> I, too, thought that XGrabServer was synchronous, so I just called it at the top of the function that forks off check_gl_texture_size... which proceeded to *work* and happily return the correct GL_MAX_TEXTURE_SIZE.
[06:19] <smspillaz> huh
[06:19] <RAOF> Obviously not the effect I was hoping for :)
[06:20] <RAOF> So, in short: ?XGrabServer: your paranoia is justified.?
[06:21] <smspillaz> well, XGrabServer without synchronous behaviour kind of defeats the purpose of XGrabServer if you ask me
[06:22] <smspillaz> because what ends up happening is this:
[06:22] <smspillaz> listen only to me, stop listening only to me, do stuff
[06:23] <smspillaz> since if you're using server grabs, its likely that you're doing stuff with whats directly on the server at that time, which means you have to flush your output buffer
[06:23] <RAOF> In this case, gnome-desktop only wants to batch up some X state fiddling into a single notify.
[06:24] <RAOF> Oh, hai check_gl_texture_size.  *You're* what's consuming 100% cpu?
[06:38] <didrocks> good morning
[06:41] <RAOF> Morning didrocks!
[06:41] <didrocks> hey RAOF, how are you?
[06:41] <RAOF> Chagrined.
[06:42] <RAOF> For being insufficiently paranoid with check_gl_texture_size :)
[06:42] <RAOF> Also, still slightly sick, but that's easier to ignore ?
[06:44] <didrocks> oh really?
[06:44] <pitti> Good morning
[06:44] <RAOF> Morning pitti
[06:44] <RAOF> Oh, whoops.
[06:45]  * RAOF has noticed a *tiny* problem with the most recent gnome-desktop3 upload.
[06:45] <didrocks> guten morgen pitti, feeling better?
[06:45] <RAOF> We really should set --abort-on-upstream-changes by default, shouldn't we :)
[06:46] <pitti> didrocks: a bit, yes
[06:46] <pitti> hey RAOF
[06:46] <pitti> RAOF: I think dpkg 1.16.1 will help
[06:47] <pitti> RAOF: you got a debian-changes* stuff that reverted your patch?
[06:47] <RAOF> That basically flips that option to default-on, doesn't it?
[06:47] <pitti> seems so, yes
[06:49] <RAOF> oneiric-proposed is open, right?
[06:53] <pitti> RAOF: yes
[07:10] <tkamppeter> pitti, hi
[07:10] <tkamppeter> pitti, first thank you for approving my 0-day SRUs during the weekend.
[07:11] <pitti> tkamppeter: guten Morgen
[07:12] <tkamppeter> pitti, I have a little problem with my eeePC. I got a flooding of WLAN password requests due to bug 868293 and then turned off WLAN in the indicator applet menu. This also removed the menu entry to turn on WLAN again, and now I am totally locked out, the machine looks like having no WLAN by hardware now.
[07:12] <ubot2> Launchpad bug 868293 in unity "compiz assert failure: *** glibc detected *** compiz: free(): corrupted unsorted chunks: 0xa05166e0 *** (drm_intel_gem_bo_unreference)" [High,Fix committed] https://launchpad.net/bugs/868293
[07:12] <tkamppeter> pitti, as usual, scrambling bug numbers, I meant bug 854833.
[07:13] <ubot2> Launchpad bug 854833 in gnome-keyring "(oneiric) wireless passwords not remembered" [Undecided,Confirmed] https://launchpad.net/bugs/854833
[07:13] <pitti> tkamppeter: that's something for cyphermox
[07:15] <tkamppeter> cyphermox, hi
[07:16] <pitti> tkamppeter: he's in the US, so he'll answer this afternoon
[07:16] <tkamppeter> pitti, as you have seen the CUPS SRU is verified. I have joined the two bugs as duplicates as they are fixed by the same patch.
[07:19] <tkamppeter> pitti, do you know which package is the culprit for the disappeared WLAN?
[07:22] <pitti> tkamppeter: I don't, no; works here
[07:23] <chrisccoulson> good morning everyone
[07:23] <didrocks> hey chrisccoulson
[07:24] <didrocks> welcome back! (well, if we consider you didn't connect during your vacations ;))
[07:24] <chrisccoulson> hi didrocks :)
[07:24] <tkamppeter> pitti, have found out what happend: Turning of wireless has put the machine into inflight mode (did not see that directly as a plugged USB Bluetooth adapter carried on working, I pressed Fn + F2 to leave inflight mode, then the wireless entry reappeared in the menu and I could turn on wireless again by the menu.
[07:24] <chrisccoulson> thanks ;0
[07:24] <chrisccoulson> how are you?
[07:24] <pitti> tkamppeter: aah, kill switch?
[07:25] <didrocks> chrisccoulson: I'm fine thanks, and you?
[07:25] <chrisccoulson> didrocks, yeah, good thanks
[07:25] <pitti> hey chrisccoulson -- don't you need some holiday now? :-)
[07:25] <chrisccoulson> hi pitti. yeah, i'll need some more holiday again soon ;)
[07:27] <tkamppeter> pitti, what do you mean with "kill switch"?
[07:27] <pitti> tkamppeter: the key/slider which disables/enables wifi is usually called "kill switch"
[07:28] <tkamppeter> pitti, some boxes have a physical slider which cannot be set by software, this netbook not.
[07:32] <tkamppeter> pitti, in this case the software can set the kill switch which this action should not do.
[07:33] <RAOF> chrisccoulson: How would you like to test gnome-desktop later?
[07:34] <chrisccoulson> RAOF, sure, can do
[07:34] <RAOF> I can either PPA it up or point you at a packaging branch.
[07:43] <RAOF> chrisccoulson: First cut is in ppa:raof/aubergine, pending building.  That should ensure your desktop is never blocked by check_gl_texture_size, no matter how crazy gnome-desktop/g-s-d want to be.
[07:47] <rodrigo_> morning
[07:59] <pitti> hey rodrigo_
[08:02] <Sweetshark> Morning all!
[08:04] <rodrigo_> hi pitti, Sweetshark
[08:05] <pitti> hey Sweetshark, how are you?
[08:05] <seb128> hey
[08:05] <didrocks> good morning Sweetshark, rodrigo_
[08:05] <rodrigo_> hi didrocks, seb128 :)
[08:06] <seb128> hey didrocks pitti rodrigo_
[08:06] <seb128> how is everybody,
[08:06] <pitti> bonjour seb128, ca va?
[08:06] <seb128> ?
[08:06] <seb128> pitti, ca va bien, merci ;-)
[08:06] <pitti> still a bit oneiric :)
[08:06] <seb128> hehe
[08:06] <seb128> pitti, how is your cold?
[08:06] <seb128> did you manage to get over it?
[08:06] <pitti> release candidates are built and on the tracker, if you guys feel so inclined
[08:06] <pitti> seb128: seems to be a very slow one; it's not very bad, but already lasting a week :/
[08:07] <seb128> pitti, I will do some iso testing for sure today
[08:07] <seb128> let me start syncs while I catch up on emails etc
[08:12] <Sweetshark> pitti: a cold takes 14 days to heal off, with medicine it takes two weeks ...
[08:13] <pitti> Sweetshark: that used to be 7 days -- the germs keep getting better!
[08:13] <Sweetshark> pitti: we are training them with antibiotics
[08:13] <pitti> I don't
[08:13] <pitti> but they might have gotten resistant against chicken soup and apple pie as well
[08:14] <Sweetshark> pitti: ow, now thats bad
[08:20] <seb128> pitti, do you know about udisk2 and davidz plans for it?
[08:21] <pitti> seb128: he wants to try and push it into gnome 3.4
[08:21] <seb128> ok, what I was feating
[08:21] <pitti> but I haven't played around with it much yet
[08:21] <seb128> I'm pondering staying on GNOME 3.2 for the lts
[08:21] <pitti> it's somewhere on my list of things to do
[08:21] <seb128> do you see that as a risky move in a lts cycle?
[08:21] <pitti> it's installable in parallel with old udisks
[08:21] <pitti> moderate, I think
[08:21] <seb128> well, he's porting gnome-disk-utility and gvfs
[08:21] <pitti> it's completely rewritten
[08:21] <seb128> not sure he will keep both backends
[08:22] <pitti> seb128: no, I mean for other desktops like KDE
[08:22] <pitti> seb128: but anyway, it turns some concepts upside down
[08:22] <pitti> like the distinction between "internal" and "external"
[08:22] <pitti> I'd feel better if this landed in Q TBH
[08:23] <pitti> but then again, I need to actually look at it before I make up my mind
[08:23] <pitti> something to play with next week
[08:23] <seb128> ok, me as well
[08:23] <seb128> pitti, can you look before UDS? thanks ;-)
[08:23] <pitti> one thing I want to do is writing an integration test, similar to what udisks 1 has
[08:23] <seb128> pitti, it's going to be one of the parameters in the "what GNOME version to go for" discussion
[08:23] <pitti> seb128: ok, will make sure I'm prepared for this part
[08:23] <seb128> the glib changes desrt is doing makes me nervous for a lts as well
[08:24] <seb128> and since GNOME sucks at being able to ship a new version on a non current platform I doubt we will be able to take 3.4 without udisks2; glib 2.32 gtk 3.4 etc
[08:26] <pitti> udisks2 and glib/gdu/gvfs certainly go together, yes
[08:28] <seb128> yeah, as usually with GNOME you can't easily cherrypick components
[08:28] <seb128> it's the lot or nothing
[08:29] <pitti> well, that's fairly understandable, though
[08:29] <pitti> keeping both udisks 1 and 2 code in gdu/gvfs would be quite some effort, and nobody would extensively test that upstream anyway
[08:29] <seb128> pitti, well I still wish that "applications" like gedit, eog etc would be handled as standalone applications and a bit lax on their depends ;-)
[08:30] <pitti> I don't think the API changes at the gvfs level, though
[08:30] <pitti> so it still ought to be possible to update udisks/gdu/gvfs/glib, but keep the apps, for example
[08:31] <seb128> that's already something
[08:31] <seb128> well anyway something for UDS
[08:31] <seb128> I just wanted to make sure somebody has a clue about that transition at UDS for the discussion ;-)
[08:32] <Sweetshark> pitti: does anyone know how to setup a software-raid after the install? Mine sorta kinda works -- it sometimes boots through, it is complaining about degradedraids on boot sometimes and just doesnt boot at all at other times (just hangs with a blank screen). I assume I would need to get my raid setup into the initramfs somehow maybe?
[08:32] <pitti> Sweetshark: did you try the latest udev from Friday/Saturday?
[08:33] <pitti> Sweetshark: you mean moving your root fs to raid after install?
[08:33] <pitti> I've done that on my server just through ssh years ago, with repartitioning two times (that was fun)
[08:33] <pitti> but I kept /boot/ on non-RAID; not sure if that works now
[08:40] <Sweetshark> pitti: no, no fancy stuff like root or /boot on raid. Just /home and a custom partition.
[08:40] <pitti> Sweetshark: that should "just work" (tm); i. e. do the mdadm stuff, add /dev/mapper/whatever to /etc/fstab for /home
[08:41] <pitti> mdadm udev rules sohuld assemble the array on boot, and trigger the mounting
[08:51] <didrocks> re
[08:56] <glatzor> morning mvo, debugging aptdaemon I just realized that the session indicator performs a UpgradeSystem Simulate after every change of the transaction queue
[08:56] <glatzor> mvo, that seems to be a little bit too much
[08:56] <glatzor> mvo, the simulate is also processed in the main loop (we don't use threading in oneiric) so the system gets a short block after each transaction
[08:57] <mvo> glatzor: urgh
[08:57] <mvo> glatzor: that is very much not ideal
[08:58] <mvo> glatzor: hm, what can we do, what is the best way to fix session indicator? or should we simply do some clever caching?
[08:59] <glatzor> mvo, for P indicator should use the PackageKit interface. The GetUpdates will be cached in aptdaemon.
[09:00] <glatzor> mvo, it could listen to the org.debian.apt.CacheChanged transaction
[09:00] <glatzor> transaction != signal
[09:01] <glatzor> mvo, I am away
[09:01] <mvo> glatzor: thanks for the notify!
[09:07] <czajkowski> Aloha
[09:16] <glatzor> mvo, the signal won't be enough.
[09:17] <glatzor> mvo, it seems to be difficult to this right with the current infrastructure. we have to accept some inaccuranceness
[09:17] <mvo> ok
[09:17] <glatzor> oh that word seems to be odd :)
[09:17] <mvo> I know what you mean
[09:17] <mvo> its just a bit inaccurate ;)
[09:17] <glatzor> mvo, right :)
[09:18] <Sweetshark> pitti: well, it doesnt "just work" here. and the sometimes works, sometimes doesnt stuff scares me a bit.
[09:18]  * mvo is still proud member of blatant errors and awkward grammar
[09:18]  * glatzor too
[09:18] <glatzor> see you, mvo
[09:19]  * mvo waves
[09:22] <pitti> Sweetshark: when it doesn't work, does the /dev/mapper/* device exist? or not even that?
[09:27] <Sweetshark> pitti: I am not used dmapper or lvm, just md.
[09:28] <pitti> Sweetshark: yes, but that should still end up in /dev/mapper/
[09:28] <chrisccoulson> hmmm, so, since i went on vacation, something seems to have broken the panel menus in unity on my second monitor :(
[09:28] <chrisccoulson> they no longer stay open anymore, but instead, they appear briefly and close immediately again
[09:28] <chrisccoulson> that never used to happen
[09:29] <chrisccoulson> didrocks, have you seen that?
[09:30] <didrocks> chrisccoulson: I'm not with my second monitor right now
[09:30] <didrocks> njpatel: you still have your second monitor, isn't it, do you have this? ^
[09:30] <pitti> Sweetshark: hm, or maybe not -- what do you get there, /dev/mdsomething?
[09:30] <chrisccoulson> hmmm, it's pretty broken. i tried logging out and back in again, just to make sure it wasn't transient
[09:31] <chrisccoulson> and it's consistently broken on my second monitor
[09:31] <chrisccoulson> all the menus are unusable
[09:32] <Sweetshark> pitti: I have /dev/md/1 and /dev/md/2 in /etc/mdadm/mdadm.conf and am using the UUIDs of those arrays in fstab. However, even when booting trough I get /dev/md127 and /dev/md126 instead of 1 and 2
[09:32] <njpatel> chrisccoulson, didrocks, erm, no, but let me try
[09:33] <seb128> hey chrisccoulson
[09:33]  * njpatel upgrades first, though
[09:33] <pitti> Sweetshark: oh, mdadm.conf? that shouldn't have been necessary for some ten years or longer..
[09:33] <chrisccoulson> hi seb128
[09:33] <seb128> njpatel, chrisccoulson: kenvandine (I think) mentioned the same second monitor issue
[09:33] <chrisccoulson> ah, so it might not just be me then :)
[09:33] <seb128> chrisccoulson, how are you? had nice holidays? happy to be back?
[09:33] <njpatel> okay
[09:33] <pitti> Sweetshark: perhaps try to move that away, and see what it does then?
[09:33] <njpatel> damn
[09:33] <njpatel> chrisccoulson, bug please, sir :)
[09:33] <pitti> Sweetshark: (just to rule out the possibility of some mis-configuration ther)
[09:33] <chrisccoulson> seb128, yeah, the holiday was great thanks
[09:34] <chrisccoulson> it felt like i never left really ;)
[09:34] <chrisccoulson> njpatel, did you manage to confirm it?
[09:34] <njpatel> chrisccoulson, no, but I have a feeling you might be right
[09:34] <seb128> njpatel, chrisccoulson: bug #869196
[09:34] <ubot2> Launchpad bug 869196 in unity "unity panel menus don't stay open when clicked on second monitor" [Undecided,New] https://launchpad.net/bugs/869196
[09:34] <njpatel> not yet*
[09:34] <njpatel> seb128, swheet
[09:34] <njpatel> shweet*
[09:34] <chrisccoulson> excellent, thanks :)
[09:35] <chrisccoulson> it seems all the bugs come out of the woodwork when i finish my vacation ;)
[09:35] <seb128> no, they have been sitting there
[09:35] <chrisccoulson> heh
[09:35] <pitti> seb128: my concerns about clutter weren't so much about performance, but about not working at all on some hardware; or can that be ruled out?
[09:35] <seb128> the issue is that dx didn't fix bugs previous week because njpatel was not around
[09:35] <chrisccoulson> ah, ok
[09:35] <chrisccoulson> i found a nice bug for RAOF at the weekend too
[09:35] <njpatel> seb128, come on, they were fixing bugs
[09:36] <seb128> pitti, well, if it's for games or side features it's easy enough to not care or turn the features off at beta time?
[09:36] <njpatel> it's just the bugs are harder at this point the cycle, so sometimes they take days instead of hours
[09:36] <pitti> seb128: right; but I'm concerned about it for the video player
[09:37] <seb128> njpatel, yeah, sorry, it was a bit of exageration
[09:37] <pitti> seb128: TBH I'd rather stay with totem 3.0 than moving to banshee or clutter-totem for LTS
[09:37] <seb128> njpatel, I'm a bit annoyed that things like the launcher not showing, the dash not getting the focus, the right menu list not working on for use, etc didn't get fixed
[09:37] <seb128> njpatel, sorry for turning that in wrong accusation ;-)
[09:38] <seb128> pitti, right, which is the topic of my email, I just responded to the "let clutter out of the CD" bit, I totally agree with you otherwiwse
[09:38] <njpatel> seb128, funnily enough, I just asked for a patch of the first one you mentioned, which fingers-crossed fixes it (will be in compiz release today), and the second two are the same bug with jason has been working on. I'll help him out today too
[09:39] <pitti> seb128: ah, ok; we violently agree then :)
[09:40] <seb128> njpatel, \o/ thanks
[09:40] <chrisccoulson> dear xchat, thanks for crashing
[09:40] <Sweetshark> pitti: you mean completely removing mdadm.conf?
[09:42] <pitti> Sweetshark: well, renaming for now
[09:43] <chrisccoulson> so, now oneiric is nearly released, who wants to carry on running the firefox beta before they upgrade to precise (and help test the next security update)?
[09:43] <chrisccoulson> https://launchpad.net/~mozillateam/+archive/firefox-next
[09:43] <chrisccoulson> ;)
[09:45]  * pitti updates
[09:46] <pitti> chrisccoulson: oh, 8.0 already?
[09:47] <rodrigo_> yeah, firefox version numbers increase every day now :)
[09:47] <chrisccoulson> pitti - yeah, that's the next release
[09:47] <pitti> chrisccoulson: this disables ubufox, known/intended?
[09:47] <chrisccoulson> pitti - yeah, that's known, but unintended
[09:47] <chrisccoulson> i've got a fix for that
[09:47] <njpatel> chrisccoulson, your screens have different geometries?
[09:47] <chrisccoulson> njpatel, yeah, my secondary screen is slightly bigger
[09:48] <njpatel> thanks
[09:48] <pitti> chrisccoulson: I now get an annoying "Extension-Update" dialog about test pilot
[09:48] <pitti> chrisccoulson: clicking "Update..." button doesn't do anything, and it keeps staying on all desktops
[09:48] <Laney> does it use gsettings for proxies yet? :-)
[09:48] <chrisccoulson> pitti - oh, i've not seen that
[09:48] <chrisccoulson> you could try disabling test pilot
[09:48] <chrisccoulson> i think people do that anyway ;)
[09:48] <pitti> chrisccoulson: the red "X" button on the top right works
[09:49] <chrisccoulson> pitti - yeah, the issue with it appearing on all desktops has been mentioned before
[09:49] <chrisccoulson> note that test pilot is only switched on in the beta and aurora builds
[09:49] <chrisccoulson> feel free to switch it off ;)
[09:59] <pitti> mvo: would you miss attach_gconf() much from source_update-manager.py?
[09:59] <pitti> mvo: u-m and gnome-power-manager seem to be the only two package hooks using it, and I just removed the g-p-m one in bzr
[10:00] <pitti> mvo: it uses the static "gconf" python module which will certainly mess up apport-gtk, and it's gsettings these days anyway
[10:03] <mvo> pitti: no, this needs updating to gconf anyway its outdated
[10:03] <mvo> pitti: no in the sense that I will not miss it
[10:03] <pitti> mvo: ok, thanks; I'll remove it and replace it with a no-op function, so that it doesn't immediately break hooks
[10:06] <seb128> pitti, we need an _gsettings() variant ;-)
[10:06] <pitti> seb128: bug 836489, working on it :)
[10:06] <ubot2> Launchpad bug 836489 in apport "apport should have built-in support for gsettings hooks" [Medium,In progress] https://launchpad.net/bugs/836489
[10:07] <seb128> pitti, \o/ ;-)
[10:08] <seb128> ok, I'm going to make friends :p
[10:08] <mvo> pitti: thanks
[10:08] <seb128> I'm suggesting on ubuntu-devel list that we stop getting stuff in universe and lock them to our freeze cycle but that we push packagers and upstreams to extra.ubuntu.com
[10:08] <seb128> let's see how much people will hate me :p
[10:11] <pitti> hm, is there any way to find out the system default of a gsettings key?
[10:12] <seb128> pitti, not that I know, but better to ask desrt
[10:13] <pitti> maybe there's a way to parse .config/dconf/user
[10:15] <pitti> oh, perhaps with g_settings_new_with_backend ()
[10:15] <seb128> pitti, look to the dconf-editor source?
[10:15] <seb128> pitti, the non default value keys are bold in there
[10:15] <pitti> seb128: ah, right, that does get the default
[10:15] <seb128> pitti, so robert_ancell probably does it in some way
[10:18] <pitti> wendar: are you on very latest oneiric? several bugs of that sort got fixed last week
[10:19] <wendar> very latest, just updated
[10:19] <pitti> wendar: so, for the record, your screen gets completely turned off right after logging in, but only for your user account?
[10:19] <pitti> rodrigo_: ^ I just asked her to reset org.gnome.settings-daemon.plugins.power *, but that didn't help
[10:20] <wendar> yes, backlight turned off completely
[10:20] <wendar> has to be manually turned back on
[10:20] <pitti> how do you do this? with the brightness keys?
[10:20] <wendar> (through the keyboard brigtness key)
[10:20] <wendar> yes
[10:20] <seb128> what is the bug?
[10:20] <chrisccoulson> seb128, i agree with you btw (about extras.ubuntu.com)
[10:20] <seb128> ELACKCONTEXT
[10:20] <seb128> chrisccoulson, great ;-)
[10:21] <chrisccoulson> i have an upstream currently asking me to package their software in ubuntu, and i was going to direct them there instead ;)
[10:21] <seb128> well I wish the appreviewboard was functional
[10:21] <wendar> seb128: pitti and I just switched an ongoing conversation to the channel for more perspective
[10:21] <pitti> wendar: for bisecting, you could start with chmod 0'ing /usr/lib/gnome-settings-daemon-3.0/*power* and *xrandr*, and checking if that "fixes" it
[10:21] <seb128> let's see if they fix it if they get new people on board
[10:21] <seb128> wendar, pitti: could you describe the issue?
[10:21] <wendar> seb128: so, when I log in, my backlight turns off, and doesn't turn back on again
[10:22] <wendar> seb128: it used to do the same when I resumed from sleep, but resuming is fine now
[10:22] <wendar> seb128: so it's just login, and only on my installed user account, not on a guest account on a LiveCD
[10:22] <seb128> hum
[10:24] <chrisccoulson> why do we have shutdown actions listed under "Applications" in the dash?
[10:24] <chrisccoulson> http://www.omgubuntu.co.uk/2011/10/how-to-log-out-from-unity-dash/
[10:24] <chrisccoulson> mpt? ^^
[10:24] <wendar> pitti: do you want both the lib*.so and the *.gnome-settings-plugin versions of both?
[10:24] <pitti> wendar: can't hurt to just chmod both
[10:24] <mpt> chrisccoulson, lol, I have no idea
[10:25] <chrisccoulson> heh
[10:25] <seb128> chrisccoulson, mpt: ted figured people might want to search for shutdown and find it
[10:25] <wendar> pitti: brb
[10:25] <chrisccoulson> seb128, yeah, having actions in the dash might make sense. but it doesn't make sense that they are grouped with "Applications"
[10:25] <chrisccoulson> that's weird ;)
[10:25] <mpt> +1
[10:27] <seb128> is there any way to get them listed but not in applications?
[10:27] <seb128> do we have any other category?
[10:27] <seb128> he added "System" to the category in http://bazaar.launchpad.net/~indicator-applet-developers/indicator-session/trunk/revision/217
[10:27] <pitti> seb128: bah -- dconf-editor parses the schemas
[10:28] <seb128> pitti, there is probably no other way...
[10:28] <wendar> pitti: that does it
[10:28] <wendar> pitti: both on relogin and reboot
[10:28] <pitti> wendar: can you now chmod 644 one, and see whether it's xrandr or power?
[10:28] <wendar> yup
[10:30] <mpt> Hmm ... Random question: Would it be theoretically practical for code in g-c-c to warn you that the language pack you're about to uninstall is being used by N user accounts?
[10:31] <rodrigo_> wendar, pitti: sorry, just reading the backlog now...
[10:32] <seb128> mpt, yes, trivial
[10:33] <pitti> mpt: not very precisely, but should usually be correct
[10:33] <seb128> mpt, the "language" info is in the accountsservice dbus service, so it's easy to iterate through users looking for their language and match with the one you remove
[10:33] <rodrigo_> wendar, hmm, chmod'ing those lib* files fixed the problem for you?
[10:33] <pitti> seb128: not all derivatives use accountsservice, though
[10:33] <seb128> pitti, those who don't use it don't use gnome-control-center
[10:33] <pitti> rodrigo_: just trying to bisect which plugin it was; I already had her reset the power gsettings
[10:33] <seb128> pitti, the question from mpt was about g-c-c ;-)
[10:33] <pitti> seb128: you could have some KDE and some GNOEM users
[10:34] <seb128> oh, right, I know what you mean
[10:34] <pitti> that's what I meant with "not precisely"
[10:34] <seb128> we should talk to other derivatives about using accountsservice, it's a fdo tech
[10:34] <seb128> I think robert_ancell planned to do that
[10:34] <seb128> he wanted to standardize on it for lightdm as well
[10:35] <wendar> pitti: so, it's libxrandr that causes the problem
[10:35] <seb128> wendar, interesting
[10:35] <wendar> pitti: but with libpower disabled, I can't manually turn the backlight back on
[10:35] <wendar> pitti: which made it interesting to test :)
[10:35] <pitti> wendar: can you do the list-recursively/reset-recursively/compare dance again for .xrandr?
[10:35] <seb128> xrandr has no settings
[10:36] <seb128> only enable and the default behaviour
[10:36] <pitti> not many, indeed
[10:36] <seb128> (which is "let xorg does it work)
[10:36] <pitti> but somehow that user account must be different
[10:36] <seb128> it might have a .config/monitors.xml
[10:36] <pitti> wendar migh thave a bad ~/config/monitors.xml, which would xrandr off the screen
[10:36] <wendar> it has 4 settings
[10:36] <pitti> but then the brightness settings wouldn't work
[10:36] <pitti> wendar: anyway, might be worth trying to move ~/.config/monitors.xml away
[10:37] <seb128> could be that xrandr trigger an xorg bug?
[10:37] <seb128> i.e xrandr use might screw xorg
[10:37] <seb128> which would be an xorg,driver bug
[10:37] <seb128> it would be interesting to see if with another session using the capplet or xrandr leads to similar issues
[10:38] <wendar> I have no file /etc/gnome-settings-daemon/xrandr/monitors.xml
[10:39] <wendar> The directory /etc/gnome-settings-daemon/xrandr/ is completely empty
[10:39] <seb128> wendar, ~/.config/monitors.xml
[10:39] <seb128> wendar, the etc directory is for system defaults
[10:39] <wendar> seb128: yes, but the value of default-configuration-file is '/etc/gnome-settings-daemon/xrandr/monitors.xml'
[10:40] <seb128> wendar, right, that's the default system one
[10:40] <seb128> but if you have an user one it will be used
[10:40] <seb128> the key name is misleading
[10:40] <seb128> it's actual system-default-configuration-file
[10:41] <seb128> the user location is not configurable but used anyway ;-)
[10:41] <wendar> ok, removed ~/.config/monitors.xml, trying again
[10:41] <pitti> wendar: did you chmod 644 back both plugins?
[10:42] <wendar> pitti: yes
[10:43] <wendar> pitti: and, bug is gone with nuked monitors.xml, but xrandr and power on
[10:43] <seb128> wendar, does using xrandr manually to apply a resolution trigger the bug?
[10:44] <wendar> seb128: example command line to try?
[10:44] <seb128> not sure ... xrandr --auto? ;-)
[10:44] <seb128> do you use a laptop screen, an external one?
[10:44] <wendar> no external screen
[10:45] <wendar> (except for presentations)
[10:45] <rodrigo_> hmm, so removing ~/.config/monitors.xml fixed the problem?
[10:45] <wendar> seb128: xrandr --auto doesn't trigger the problem
[10:45] <wendar> rodrigo_: yes
[10:45] <seb128> wendar, xrandr --output LVDS --mode 1024x768
[10:45] <seb128> or whatever resolution is yours?
[10:45] <rodrigo_> I guess it's a driver problem indeed, maybe it's not detecting correctly a specific monitor
[10:46] <rodrigo_> wendar, did you keep a copy of that monitors.xml file?
[10:46] <wendar> rodrigo_: of course, I just moved it to another directory
[10:46] <wendar> rodrigo_: would you like a copy?
[10:46] <rodrigo_> wendar, yes please
[10:47] <seb128> wendar, you can probably just try to use the session menu, display panel to apply a resolution and see if that triggers the bug
[10:48] <rodrigo_> yes
[10:49] <wendar> seb128: oooh, using the display panel does trigger it
[10:49] <seb128> wendar, what about "xrandr --output LVDS --mode 1024x768"
[10:49] <wendar> seb128: (still, even with no monitors.xml)
[10:49] <seb128> or whatever resolution your tried in the graphical ui
[10:49] <seb128> wendar, well, you probably have a monitors.xml now
[10:49] <seb128> wendar, that panel is what writes this config
[10:50] <seb128> looks like a driver bug
[10:50] <wendar> seb128: that gives me "warning: output LVDS not found; ignoring"
[10:50] <seb128> xrandr screws things
[10:50] <seb128> wendar, it might be LVDS1 if you are on intel dkms
[10:50] <seb128> wendar, look in the "xrand" log how the active output is called
[10:50] <pitti> just run "xrandr" to see the available outputs
[10:50] <wendar> seb128: yes, it's been recreated, but it's not the same old corrupt one (whatever was wrong with it)
[10:51] <seb128> wendar, I don't think it was wrong or corrupted
[10:51] <seb128> it just seems something in xorg doesn't like xrandr calls
[10:51] <seb128> i.e that you hit a bug when the resolution is changed with xrandr
[10:51] <wendar> pitti: ah, it gives me LVDS1
[10:52] <wendar> seb128: so I do trigger the same bug with
[10:52] <wendar> xrandr --output LVDS1 --mode 1024x768
[10:52] <seb128> ok
[10:52] <seb128> so what I said
[10:52] <seb128> xorg or driver issue
[10:52] <seb128> it just happens that GNOME applies stored config using xrandr at login time
[10:53] <rodrigo_> yes, seems so
[10:54] <rodrigo_> wendar, do you have anything under ~/.xrandr ?
[10:54] <wendar> rodrigo_: nope, no such directory
[10:55] <wendar> I guess bryceh will be up in 5-6 hours
[10:55] <rodrigo_> sorry, ~/gsd-debug-randr.log
[10:56] <seb128> rodrigo_, you need to create a file to get that log IIRC
[10:56] <wendar> rodrigo_: don't have that file either
[10:56] <seb128> rodrigo_, but "xrandr" triggers the same bug
[10:56] <didrocks> pitti: hey, I will need your help for a SRU question after a discussion with njpatel for bug #841750
[10:56] <ubot2> Launchpad bug 841750 in unity "Dash - horizental divider line in between categories incorrectly drawn" [Medium,In progress] https://launchpad.net/bugs/841750
[10:56] <didrocks> pitti: see the merge req: https://code.launchpad.net/~macslow/unity/unity.fix-841750-2/+merge/78809.
[10:56] <rodrigo_> seb128, that's where the xrandr g-s-d plugin writes, as I can see in the code
[10:57] <njpatel> pitti, basically it makes it always draw instead of sometimes (it was being drawn outside of clip, hence x/y change), but also dims it by 0.05
[10:57] <didrocks> pitti: I agree that in some case, the line isn't shown, so maybe moving it tiny. I utterly disagree with the color change, even if told "not noticeable", if it's "not noticeable", so "don't push it"
[10:57] <njpatel> it = separator, sorry
[10:57] <njpatel> didrocks, it's noticeable from a design sense, I meant that it doesn't effect docs
[10:58] <wendar> pitti, seb128, rodrigo_: this is non-critical for release?
[10:58] <didrocks> for a SRU? If we start pushing design change in SRU, it's road to crazyness
[10:58] <seb128> wendar, no it's not, it's specific to your hardware
[10:58] <seb128> wendar, it's a bit unfortunate and annoying but not a blocker
[10:58] <pitti> wendar, seb128: it might also be related to the SRU that RAOF is about to upload (libgnome-desktop3)
[10:58] <wendar> seb128: yup, so I won't worry about it, but will check in with bryce when he's up
[10:59] <pitti> http://launchpadlibrarian.net/81934986/gnome-desktop3_3.2.0-0ubuntu3_3.2.0-0ubuntu4.diff.gz might be related to it
[10:59] <seb128> wendar, thanks
[10:59] <wendar> pitti: will try that and see if it resolves the issue
[10:59] <pitti> unfortunately the patch which got uploaded there got reverted by that silly debian-changes* patch
[10:59] <wendar> pitti, seb128, rodrigo_: thanks!
[11:00] <pitti> wendar: so you could reinstall that broken config, apt-get source gnome-desktop3, quilt pop -a, drop teh debian-changes patch, rebuild, and check if that makes a difference
[11:00] <pitti> (and meh @ UDD)
[11:00] <seb128> rodrigo_, I'm pretty sure g-s-d only writes that log file if the file is on disk (or another file is on disk), I've debugged xrandr bugs with federico before where he asked me to create a file to have the debug output
[11:01] <seb128> pitti, UDD :-(
[11:01] <rodrigo_> seb128, ah ok, didn't know
[11:01] <pitti> didrocks: so on https://launchpadlibrarian.net/81808065/dash_divider%20lines%20wrong1.png it's the slightly thicker ends of the lines?
[11:01] <pitti> didrocks: no need to spend time on color changes indeed, IMHO
[11:01] <didrocks> pitti: that's my guess, MacSlow|lunch can confirm
[11:02] <didrocks> pitti: what do you mean, should we let the color change in?
[11:02] <pitti> didrocks: but if it's that subtle, I don't think ubuntu-sru would violently veto it
[11:02] <seb128> rodrigo_, you need to create a file "gsd-debug-randr" to get the log apparently from the old bug comments I read
[11:02]  * didrocks thinks we really open the pandora box, but oh well
[11:02] <pitti> didrocks: if it only slightly changes colors, I think "whatever is easier for you"
[11:02] <pitti> didrocks: (not in general, though; SRUs are not for that kidn of fixing)
[11:02] <seb128> lunch, bbiab
[11:03] <pitti> didrocks: if you fell better about dropping that change, pleaes do
[11:03] <didrocks> pitti: I'm afraid it open the gate to it, but again, I'm just a puppet there
[11:03] <rodrigo_> seb128, right, it checks for that file indeed, didn't see it when looking at the code
[11:03] <didrocks> njpatel: ok, you can push to 4.0 branch then ^
[11:04] <pitti> didrocks: oh, I thought it was already
[11:04] <njpatel> pitti, no, it's still proposed
[11:04] <pitti> didrocks: fixing the line ends sounds good and desirable to me, so +1 from me on that part
[11:04] <pitti> but SRUs are not the place for design changes
[11:05] <njpatel> this is the only UI tweak on SRU list, it's just dimming it by 0.05 so it looks nicer on some backgrounds (/me found out why :)
[11:05] <pitti> ack
[11:05] <Wellark> mvo: I've got little something for you :)
[11:05] <Wellark> https://launchpad.net/bugs/871691
[11:05] <ubot2> Launchpad bug 871691 in update-notifier "update notifier message too long on display" [Undecided,Confirmed]
[11:06] <mvo> Wellark: woah
[11:09] <Wellark> mvo: indeed :)
[11:15] <rodrigo_> brb
[11:19] <wendar> other random question: is it a "feature" that the drop-down menu for recent files in gedit no longer lists any files?
[11:25] <seb128> wendar, it does for me
[11:26] <seb128> wendar, well, define "drop down", the file menu you mean?
[11:26] <wendar> seb128: shows a list of recent files?
[11:26] <seb128> yes
[11:26] <wendar> seb128: the down arrow next to the "Open" button on the top of the window
[11:26] <wendar> for me it always says "No files found"
[11:27] <seb128> wendar, http://ubuntuone.com/76bELPEUH0hfzKzbNolX7x
[11:27] <wendar> seb128: yup, that's the one
[11:28] <seb128> wendar, do you have a .local/share/recently-used.xbel?
[11:29] <wendar> seb128: yup
[11:29] <seb128> wendar, does it have entries with "<bookmark:group>gedit</bookmark:group>"
[11:30] <mvo> Wellark: I can reproduce will look at it in a sec
[11:30] <wendar> seb128: several
[11:30] <seb128> wendar, ok, weird that gedit doesn't list those then... how do you start it?
[11:30] <wendar> seb128: tried both from the Launcher and from the command-line, same effect
[11:30] <ogra_> works here too btw
[11:31] <Wellark> mvo: cool! have your time :)
[11:31] <seb128> wendar,
[11:31] <seb128> $ strace gedit 2>&1 | grep recently
[11:31] <seb128> wendar, can you try this and see what files it lists?
[11:33] <wendar> seb128: for some reason, that opens gedit, but piping through less doesn't
[11:33] <seb128> wendar, it doesn't print anything?
[11:33] <seb128> $ strace gedit 2>&1 | grep recentlyopen("/home/seb128/.local/share/recently-used.xbel", O_RDONLY|O_LARGEFILE) = 12
[11:33] <wendar> seb128: it prints "chmod("/home/allison/.local/share/recently-used.xbel", 0600) = 0"
[11:33] <seb128> wendar, that's what I get there
[11:34] <seb128> wendar, hum
[11:34] <seb128> wendar, ls -ld /home/allison/.local/share
[11:34] <seb128> wendar, ls -l /home/allison/.local/share/recently-used.xbel
[11:34] <seb128> wendar, it seems you have wrong permissions on the dir or files
[11:34] <wendar> -rw-------
[11:34] <seb128> the dir or the file?
[11:35] <wendar> -rw------- 1 allison allison
[11:35] <seb128> i.e the first or second command?
[11:35] <wendar> the file
[11:35] <wendar> drwxr-xr-x 15 allison allison
[11:35] <seb128> that seems correct
[11:36] <seb128> wendar, I'm surprised you don't get an "open" line first in strace
[11:38] <seb128> wendar, did you have any gedit open when you run the command?
[11:38] <seb128> can you close all instances
[11:38] <seb128> run "strace gedit 2>log"
[11:38] <seb128> close it after opening it
[11:38] <seb128> less log
[11:38] <seb128> use "/recently"
[11:39] <seb128> and see what it matches and if there are any error before
[11:39] <seb128> wendar, other option is that /home/allison/.local/share/recently-used.xbel somewhat is corrupted, you can maybe try to move it away, open a file and see if the menu gets updated
[11:46] <wendar> seb128: well, opening the file in vim doesn't show any results for "recently"
[11:47] <wendar> will try removing the file
[11:47] <seb128> wendar, the strace log you mean?
[11:48] <seb128> wendar, do you have any "inotify_add_watch(9, "/home/allison/.local/share""
[11:48] <seb128> I wonder if it hits an issue putting the monitor on .local/share for you
[11:50] <wendar> seb128: I'm running backwards through the tips...
[11:50] <wendar> so strace gedit log shows:
[11:50] <wendar> open("/home/allison/.local/share/recently-used.xbel", O_RDONLY) = 12
[11:51] <seb128> ok, so it does open it, great, that's a good start
[11:51] <wendar> and also has the inotify_add_watch for the directory
[11:52] <seb128> wendar, ok, so that's normal, I was getting confused by the lack of open call you had before
[11:53] <wendar> seb128: on the other trial, moving .local/share/recently-used.xbel away has no effect on gedit
[11:54] <wendar> seb128: but, it does empty out the "Recently Used" option in the file picker dialog
[11:54] <seb128> wendar, so you run gedit, ctrl-O, open a file, and the menu is still empty?
[11:55] <wendar> seb128: it was when I removed recently-used.xbel, but it's generally fine
[11:55] <wendar> the only problem is the little "shortcut" button
[11:55] <seb128> wendar, right, that one stays empty after you open a file still?
[11:55] <wendar> seb128: yup
[11:55] <seb128> :-(
[11:56] <seb128> does recently-used.xbel gets written with the file you opened?
[11:57] <wendar> seb128: yes, the file is added to a freshly created recently-used.xbel
[11:57] <seb128> wendar, ok, I'm sorry but I'm not sure what's going on, the fileselector correctly use recently-used.xbel from what you said so the file can be read and parsed, not sure why the small toolbar menu doesn't work
[11:58] <seb128> wendar, the small menu next to the "open" toolbar icon works fine there for me with my user or in a guest session
[11:58] <seb128> wendar, do you get a "no entry found" label in the menu or just no menu at atll?
[11:59] <wendar> seb128: it drops down with "No items found"
[11:59] <seb128> wendar, ok, well you can restore your old recently-used.xbel
[11:59] <pitti> seb128: attach_gsettings_{package,schema} added to apport trunk FYI -- XDG_CONFIG_HOME=/nonexisting gsettings list-recursively... did the trick
[11:59] <seb128> wendar, I'm out of idea for now on why it's buggy for you but I will ping you later if I get a new one
[12:00] <seb128> pitti, \o/
[12:00] <wendar> seb128: okay, thanks
[12:00] <seb128> pitti, well done
[12:00] <seb128> wendar, but if that's of any consolation it's a bug and it doesn't seem to happen to others
[12:00] <seb128> i.e not something broken for everybody
[12:02] <mpt> Am I imagining this, or is the "Keyboard" gnome-control-center panel, accessed from the keyboard indicator, a panel that you can't actually access from the g-c-c home screen?
[12:03] <mpt> oh, no, g-c-c has separate "Keyboard" and "Keyboard Layout"
[12:03] <mpt> how silly
[12:04] <seb128> mpt, it's silly but the "keyboard layout" upstream is in the "region" capplet which we hides because we use language-selector
[12:05] <seb128> mpt, it's on the precise list of polish we want to do
[12:05] <mpt> seb128, right, that's what I'm working on, and stumbled across this :-)
[12:05] <seb128> though "keyboard layout" should probably be under "keyboard" rather than region?
[12:05] <mpt> you'd think
[12:06] <seb128> mpt, btw not sure if you are the right one but I would welcome design input on "screen locking: when and for what users", we will have a session on that at UDS and I dropped an email about it on the desktop list
[12:07] <seb128> mpt, i.e define for what user we do locking by default (i.e do we do it for autologged users), how do you allow users to tweak the behaviour
[12:08] <seb128> etc
[12:09] <mpt> seb128, I agree it would make a lot of sense to have the keyboard settings together. But in Windows keyboard layout is under "Region and Language" and in OS X it's under "Language & Text", both far away from other keyboard options. In OS X it makes *slightly* more sense because one of the text input options is entering Chinese characters by drawing on the touchpad (i.e. not using keyboard at all) ... but still.
[12:10] <seb128> mpt, well maybe "keyboard" should have a least a link to the region tab for the keyboard layout then ;-)
[12:10] <mpt> yeah, cross-references FTW
[12:10] <mpt> It's another example of how settings don't have clear categories (e.g. where do you draw the line between desktop background <-> screensaver <-> screen blanking <-> screen dimming <-> power settings)
[12:11] <seb128> right...
[12:13] <mpt> seb128, I saw the message about screen locking, I think we need a spec for "sessions" in general, e.g. whether an admin should be able to unlock someone else's session, what happens if you shut down while other people are logged in, what the session inhibit dialog should look like, etc
[12:14] <chrisccoulson> an admin can already unlock someone elses session
[12:14] <mpt> What should happen if you go to log out after saving something in a guest session
[12:14] <chrisccoulson> sudo killall gnome-screensaver :P
[12:15] <seb128> mpt, do you want to suggest the topic on the list? ;-)
[12:15] <seb128> I'm trying to get other people than me suggesting topic :p
[12:15] <mpt> seb128, no, I'm not interested in discussing it at UDS, it's not the sort of thing that benefits from a 55-minute fishbowl
[12:16] <seb128> mpt, ok, fair enough, well as said I want design input rather than an UDS session
[12:16] <mpt> well, maybe there could be a brainstorming session, but it's a bit of an esoteric topic :-)
[12:16] <mpt> ok
[12:18] <MacSlow> didrocks, pitti: how that's suppose to happen I don't know... I've never seen this... the lines are certainly drawn being only 1 pixel wide.
[12:25]  * rodrigo_ lunch
[13:40] <chrisccoulson> it's wrong to have an "Arch: all" package installing stuff in to /usr/lib isn't it?
[13:40] <seb128> chrisccoulson, usually yes
[13:41] <chrisccoulson> seb128, thanks. i guess i need to make ubufox "Arch: any" now then, even though it really isn't
[13:41] <chrisccoulson> i need to move it to the firefox $libdir to stop it from being disabled by default
[13:42] <chrisccoulson> which sucks ;)
[13:42] <pitti> chrisccoulson: more to the point, it's considered bad to install architecture neutral files into /usr/lib/
[13:43] <pitti> chrisccoulson: does lintian actually complain if an all package installs stuff into /usr/lib? all python packages place symlinks there
[13:43] <chrisccoulson> pitti - i do that already for firefox. but in any case, i need to install extensions in to /usr/lib/firefox/extensions
[13:43] <chrisccoulson> and this folder can contain binary extensions as well as arch-independent ones
[13:46] <pitti> chrisccoulson: I don't think an arch:all package would be terribly wrong there
[13:48] <chrisccoulson> pitti - so you think i should keep ubufox as arch:all for now (although i still need to move it to /usr/lib/firefox-addons/extensions)?
[13:48] <pitti> chrisccoulson: yes
[13:48] <chrisccoulson> i guess if we want a multi-arch aware firefox at some point, i'd need to make it arch:any
[13:50] <chrisccoulson> pitti - i get lintian warnings for firefox btw (for the icons)
[13:51] <chrisccoulson> if we make firefox multi-arch in the future, then i would move those to a firefox-common package and put them in the right place
[13:52] <chrisccoulson> but i'm not sure of any benefits of doing those now (other than to make the warnings go away)
[15:06]  * kenvandine waves
[15:06] <seb128> hey kenvandine
[15:06] <seb128> isn't topic a national holiday for you?
[15:06] <kenvandine> yes
[15:07] <kenvandine> :)
[15:07] <seb128> ;-)
[15:07] <seb128> how are you?
[15:07] <kenvandine> just replying to a few emails before i get started working on our cars :-D
[15:07] <kenvandine> great, and you?
[15:08] <seb128> I'm fine thanks
[15:08] <seb128> kenvandine, btw I assigned you some telepathy-indicator bugs the other days, not sure if you watch the product or not
[15:08] <seb128> it has a bunch of segfault bugs
[15:10] <kenvandine> yeah, i have a branch fixing at least one of them waiting for review
[15:11] <kenvandine> i haven't looked at the others yet
[15:29] <seb128> ok, first install of the CD worked great
[15:29] <pitti> bbl
[15:29] <seb128> (i386 in install mode using a specific partition without internet)
[15:29] <seb128> seems a good start ;-)
[16:51] <seb128> mvo, stupid question but is it normal that the partner archive is not enabled by default?
[16:55] <pitti> seb128: s-c enables it on demand, doesn't it?
[16:56] <seb128> pitti, well "on demand" means you need to know that what you want to use is in there?
[16:56] <seb128> I was just wondering if there is any reason it's not enabled by default
[16:57] <pitti> app-install-data-ubuntu doesn't have it?
[16:57] <pitti> oh, apparently not
[16:57] <seb128> I should start using graphical uis :p
[16:58] <seb128> in fact I just try to sudo apt-get install adobe<tab><tab> on my new install
[16:58] <seb128> which didn't work until I enabled partner in software-properties
[16:58] <pitti> right; but ISTR that it magically worked in s-c
[16:59] <seb128> ok, ignore me then, will teach me to want to be efficient and use the command line :p
[17:03] <pitti> still a valid question, of course
[17:15] <didrocks> ok, enough unity testing written for today, time for some exercice :)
[17:16] <pitti> didrocks: thanks, bye didrocks
[17:16] <didrocks> see you tomorrow!
[17:43] <jbicha> seb128: I have a simple fix for bug 840858 ready, really just removing the patch we applied earlier this release cycle
[17:43] <ubot2> Launchpad bug 840858 in gnome-control-center "No obvious way to disable Ubuntu startup sound" [Low,Confirmed] https://launchpad.net/bugs/840858
[17:45] <seb128> jbicha, i.e make that list have one entry "startup sound" by default?
[17:45] <seb128> it's pretty confusing on the message it gives to users on what the list is about and why other entries got dropped
[17:46] <jbicha> yelp help:ubuntu-help/session-loginsound
[17:47] <jbicha> ^ out of date for Oneiric but that's how it worked in Natty
[17:47] <jbicha> I think the theory at UDS-O was that we would hide the Startup Apps that it didn't make sense for typical users to disable
[17:50] <jbicha> hmm, Startup Applications has another broken help button
[17:53] <seb128> jbicha, well the theory was that we would hide "services" and let it be what the title claim, i.e startup *applications* ;-)
[17:54] <seb128> jbicha, the login sound is not really an application
[17:54] <seb128> i.e that dialog should be how you autostart your email client at login if you want to do that
[17:56] <seb128> dinner time, bbl
[18:17] <jbicha> seb128: ok, simple fix for bug 871484 should that get uploaded in oneiric-proposed or what?
[18:17] <ubot2> Launchpad bug 871484 in gnome-utils "gnome-screenshot help missing" [Low,Confirmed] https://launchpad.net/bugs/871484
[18:18] <seb128> jbicha, let's try to get it upstream for 3.2.1
[18:18] <seb128> or in the vcs for the next upload
[18:18] <seb128> i.e no need to do an upload now but when 3.2.1 is out we can sru the new version with the fix
[18:23] <jbicha> seb128: sounds good
[18:23] <pitti> seb128: oh, seems you kicked off quite some discussion :)
[18:24] <seb128> pitti, yeah, I'm in the mood for that this week :p
[18:47] <jbicha> pitti: what do you think about python plugins being broken in Totem? bug 855100
[18:47] <ubot2> Launchpad bug 855100 in totem "python plugins not working" [Undecided,Confirmed] https://launchpad.net/bugs/855100
[18:48] <pitti> jbicha: well, obviously I think it's bad :)
[18:48] <pitti> worth an SRU
[18:48] <pitti> jbicha: a reproduction recipe might be handy, though, as normally totem doesn't spit out these errors
[18:49] <pitti> I just tried a youtube search which worked (probalby isn't python)
[18:50] <jbicha> pitti: Totem>Edit>Plugins and just start checking boxes (it's related to libpeas)
[18:51] <jbicha> you had done a bit of work with libpeas recently so I thought you might have an idea about what's wrong
[18:52] <jbicha> maybe it was fixed in Totem 3.2
[18:52] <pitti> jbicha: no time to look at it yet
[18:52] <pitti> jbicha: yes, libpeas works fine now with gedit, I suppose the python plugins in totem itself don't get along with new pygobject
[18:53] <pitti> pretty sure that 3.2 will fix it, so we can do some backporting there
[18:53] <jbicha> pitti: no problem, other things are more important
[19:58]  * pitti sets up new image builds and waves good night
[21:17] <bjsnider> jbicha, just refreshed patches and built totem 3.2, installed it, and i can check the python console button without issue
[21:19] <jbicha> bjsnider: right, Totem 3.0 used the old pygobject which I don't believe works any more
[21:23] <jbicha> but it's probably not too difficult to port to the new style