[00:28] <xnox> robert_ancell: bschaefer: all layout is done using vector sources, so it's easy to generate svg out of that i believe. It's just well - getting dimention sizes of how would we want it to be rendered.
[04:18] <bjf> xnox, trusty-desktop-amd64+mac.iso gives me ubi-usersetup failed with exit code 2. that's so unfriendly.
[04:20] <bjf> xnox, i'm also curious how that made it past CI testing
[05:31] <pitti> Good morning
[09:03] <Laney> morning!
[09:04] <hikiko> hello :)
[09:05] <Laney> hey hikiko & pitti
[09:05] <Laney> wie gehts?
[09:05] <pitti> hey Laney, guten Morgen
[09:05] <seb128> good morning desktopers!
[09:05] <pitti> Laney: gut, danke!
[09:05] <pitti> bonjour seb128 !
[09:05] <seb128> hey Laney hikiko pitti, how are you?
[09:05] <hikiko> hi seb128 Laney pitti :)
[09:05] <hikiko> good seb128 you?
[09:06] <seb128> hikiko, I'm good thanks
[09:06] <pitti> seb128: ma main est un peu malade (je doit aller au médecin maintenant), mais bon
[09:06] <Laney> hey seb128
[09:06] <seb128> Laney, so changing to build u-s-s on all archs was not the best idea, it's blocked on i-n which is blocked on unity8 now
[09:06] <Laney> prima, danke
[09:06] <seb128> pitti, oh, qu'est-ce que tu as fait ?
[09:06] <Laney> heh
[09:07] <pitti> seb128: not sure yet; probably ganglion burst open again when I was doing pushups improperly
[09:07] <Laney> I guess the goal is to unwind the stack
[09:07] <seb128> Laney, I force merged back to trunk even if it's in proposed
[09:07] <Laney> but there are hacks like faux packages that can be employed if necessary
[09:07] <seb128> right, Colin was on it
[09:07] <Laney> nod
[09:07] <seb128> he forced britney into thinking unity8 is available on archs where it's not
[09:09] <hikiko> seb128, we finally decided to add a checkbox quickly in u-c-c and try to implement this: https://wiki.ubuntu.com/BrightnessAndDisplays#Displays until friday (but since the second change is quite big and might not be in 14.04) could you get a look at my checkbox? (here: https://code.launchpad.net/~hikiko/unity-control-center/u-c-c.checkbox-for-app-scaling/+merge/211681)?
[09:11] <seb128> hikiko, I had on screen, how come it's so much code?
[09:11] <seb128> hikiko, like why do you need to use gnome_rr apis, isn't that supposed to just write gsettings keys?
[09:12] <hikiko> seb128, I needed to add a custom gsetting too
[09:12] <seb128> why?!
[09:12] <hikiko> https://code.launchpad.net/~hikiko/gsettings-ubuntu-touch-schemas/gsettings-ubuntu-touch-schemas.selected-monitor/+merge/211680
[09:12] <hikiko> because I needed to store the selected monitor
[09:12] <seb128> why?
[09:12] <seb128> those settings are not by monitor
[09:12] <hikiko> the checkbox does the following:
[09:12] <hikiko> when is checked
[09:13] <hikiko> it sets the scaling-factor and the text-scaling-factor to some values that when multiplied they give the ui-scale factor
[09:13] <hikiko> of the selected monitor
[09:14] <hikiko> so that the menus and launcher etc have the same size with the window contents
[09:14] <hikiko> in the selected monitor
[09:14] <seb128> so what happen when you select another monitor in the UI?
[09:15] <hikiko> the new monitor's check button is checked, the new monitor's name is saved and the scaling-factor and text-scaling-factor of the desktop are set according to the ui-scale
[09:16] <hikiko> next time you open u-c-c you will see the new monitor checked
[09:16] <hikiko> unless if
[09:16] <seb128> shrug, that seems really complicated logic, did design suggest that?
[09:16] <hikiko> the scaling/text-scaling have been changed from outside u-c-c
[09:17] <seb128> can you open a bug with explain the logic? that needs a ffe/uife anyway, and to me that's just too complex
[09:17] <hikiko> seb128, we discussed with mpt and we found this solution: https://wiki.ubuntu.com/BrightnessAndDisplays#Displays
[09:17] <hikiko> but since we practically have 2 days
[09:17] <hikiko> and in uds we were asked to add a checkbox just to have the feature there
[09:17] <seb128> right
[09:17] <hikiko> we decided to do the checkbox
[09:17] <seb128> I'm fine with the checkbox
[09:18] <hikiko> and then do the big change
[09:18] <Laney> that has a button for using the selected display
[09:18] <seb128> but not with that magic logic and new key and whatsoever
[09:18] <Laney> that seems more sensible to me
[09:18] <hikiko> I ve started the second design too
[09:18] <hikiko> seb128, if I only had the checkbutton
[09:18] <hikiko> and someone checked it for monitor N or changed it from the outside
[09:19] <seb128> there is no "for monitor N"
[09:19] <seb128> those settings are not by monitor
[09:19] <hikiko> I know what you mean
[09:19] <seb128> the checkbox is "scaling 2 on/off, for all monitors"
[09:19] <hikiko> I didnt explain it well
[09:20] <seb128> IRC might not be the best place
[09:20] <hikiko> no the checkbox should do the following:
[09:20] <seb128> please open a bug with the logic described
[09:20] <hikiko> ok :)
[09:20] <seb128> we need it for the ffe/uife anyway
[09:20] <seb128> thanks
[09:28] <seb128> shrug, why are unstable users not updating
[09:29] <seb128> the top report of e.u.c daily trusty issues is still that xfdesktop4 issue that was fixing 17 days ago
[09:30] <Tazmain> hi all, I am having some issue with my ubuntu-raring-minimal if I launch a vncserver and connect to it I keep getting failed to start session "gnome" logout. I have xubuntu installed though
[09:34] <mitya57> larsu, charles_: Can one of you please approve https://code.launchpad.net/~mitya57/indicator-applet/unparent-label/+merge/208174? Having a hacky fix is better than having that applet totally broken.
[09:35] <seb128> Laney, did you try https://code.launchpad.net/~binli/unity-control-center/1291862/+merge/211258 again?
[09:35] <seb128> I'm going to put a landing with some of my fixes, I'm pondering including that or not
[09:36] <seb128> Laney, also if you want to review/ack https://code.launchpad.net/~seb128/unity-control-center/users-prompt-when-needed/+merge/211596 ... it's the bug I was talking to desrt about yesterday
[09:36] <Laney> oh I forgot, let me do that in a minute
[09:36] <seb128> thanks
[09:39] <Laney> how come g-c-c upstream doesn't have that password bug?
[09:39] <Laney> it looks like it would from the code
[09:39] <cking> anyone able to explain why boot is slow slowe in trusty, the desktop seems to be consuming a load more boot time if one can believe this data: http://ci.ubuntu.com/bootspeed/machine/1/amd64/
[09:40] <larsu> mitya57: that's a gtk bug, no? I don't think any other container has this check
[09:40] <larsu> which wouldn't make sense, gtk_widget_set_parent() unsets the old parent anyway
[09:41] <larsu> ah it doesn't
[09:41] <larsu> interesting... then the other containers are doing it wrong?!
[09:44] <seb128> Laney, see the bugzilla I pointed in the description?
[09:44] <seb128> Laney, desrt's comment on it
[09:44] <seb128> Laney, I think they had it on 3.8, they refactored the code (in a buggy way in 3.10)
[09:44] <Laney> ah yes
[09:44] <seb128> the call I moved is before the case for them
[09:45] <seb128> so it's just ignored
[09:45] <mitya57> larsu: Yes, it doesn't, and fails with assertion error with the current code.
[09:45] <ochosi> hey larsu
[09:46] <larsu> mitya57: shouldn't entry->image have the same problem?
[09:46] <seb128> cking, hum, https://jenkins.qa.ubuntu.com/job/bootspeed-trusty-desktop-amd64-acer-veriton-01/98/artifact/11/bootchart.png has a long python process eating cpu and io for like 40 seconds
[09:46] <larsu> hi ochosi
[09:47] <seb128> cking, lot of "utah-done.py" running in sequence as well
[09:47] <seb128> cking, seems buggy CI infra to me
[09:47] <mitya57> larsu: I can do the same with entry->image, but I didn't see any problems with that.
[09:47] <cking> seb128, OK, I'll report that back to CI
[09:47] <cking> thanks
[09:47] <mitya57> I.e. all icon-only indicators are working.
[09:47] <seb128> cking, thanks
[09:47] <Tazmain> hi all, I am having some issue with my ubuntu-raring-minimal if I launch a vncserver and connect to it I keep getting failed to start session "gnome" logout. I have xubuntu installed though
[09:47] <ochosi> larsu: not sure you received my note from yesterday about your latest indicator-sound patch (if not, i can quickly re-summarize)
[09:48] <larsu> mitya57: this makes this bug even more mysterious. I hesitate to approve a fix I don't understand
[09:48] <seb128> Tazmain, hey, try #ubuntu for user questions
[09:49] <larsu> ochosi: please summarize again, there were a lot of pings for me last night
[09:49] <seb128> ochosi, hey, oh, did I reply to you with the spec link yesterday?
[09:49] <ochosi> seb128: yup, you did :) in case i didn't thank you for it, thanks now!
[09:49] <mitya57> larsu: Maybe it's indicator-appmenu's bug that the label has non-NULL parent, and for other indicators it's just not the case.
[09:50] <seb128> ochosi, lol, thanks ;-)
[09:51] <mitya57> larsu: In any case, there is zero harm from unparenting, as it doesn't change anything for indicators that already do it right.
[09:51] <ochosi> larsu: so, you basically re-added a functionality that was in indicator-sound before, if i recall correctly, i.e. showing another icon (red speaker) when sound is muted but there is playback. that's the context.
[09:52] <ochosi> larsu: the problem is, that the icon-name for "blocked" state is not part of the spec for soundmenu, and you went with "audio-volume-muted-blocked-panel"
[09:52] <ochosi> larsu: so while this is not a problem in itself, it breaks existing icon-themes (incl. ubuntu-mono),  because the icon used to be called "audio-volume-muted-blocking-panel"
[09:53] <ochosi> (not the small diff between "blocked" and "blocking")
[09:53] <seb128> ochosi, note that the spec has a name, it uses "audio-volume-muted-panel"
[09:53] <seb128> https://wiki.ubuntu.com/Sound#Title
[09:54] <ochosi> seb128: yeah, but that icon-name is there as a fallback in larsu's patch
[09:54] <ochosi> seb128: and it's actually a bit wrong, that's the normal "muted" state. the special "red icon" is for the blocked state
[09:55] <ochosi> i guess the idea in the spec was to make a difference between normal "muted" state and "muted-blocking"/"muted-blocked" state
[09:55] <larsu> mitya57: we can't say it doesn't change anything, as we don't fully understand where the bug is coming from. Also, there might be more side-effects. I'll have a look in a bit
[09:56] <seb128> ochosi, right, I was just commenting on your statement that the name is not part of the spec
[09:56] <seb128> ochosi, we should get the spec updated to have the right name if the one used is wrong
[09:56] <seb128> e.g talk to mpt about that ;-)
[09:57] <ochosi> ok :)
[09:57] <larsu> ochosi: I thought I just used the icon name from the old code...
[09:57] <ochosi> larsu: weird... check ubuntu-mono, it has only *-blocking-*
[09:57] <ochosi> and elementary-xfce (which i'm maintaining) also has always only had that icon name
[09:58] <ochosi> in conclusion: are you sure it wasn't "blocking" before? (it used to work here)
[09:58] <seb128> ochosi, the ubuntu-mono icon seems blue, not red?
[09:58] <mitya57> larsu: Thanks a lot. FWIW, there is a link to a code that creates that label in one of the comments.
[09:58] <seb128> the current icon works
[09:58] <seb128> but it comes from humanity
[09:58] <seb128> not ubuntu-mono
[09:58] <larsu> ochosi: ah! It only has blocking, but pulls in blocked from Humanity
[09:58] <larsu> and that's the one we want iirc
[09:59] <seb128> larsu, ochosi: the spec says "red speaker", the blocking one is blue
[09:59] <larsu> the one from ubuntu-mono is blue
[09:59] <larsu> seb128: I think I'd want the blue one in red
[09:59] <larsu> but we should probably ask mpt again
[09:59] <Laney> seb128: I approved that sound mp
[09:59] <larsu> ochosi: thanks for bringing this up. Man, our icons are a mess :-/
[09:59] <seb128> larsu, right
[10:00] <seb128> I was just going to say that
[10:00] <seb128> with icons -> themes
[10:00] <seb128> and +1 for using blocking if it's red
[10:00] <seb128> because the one we are using atm doesn't match the muted icon
[10:00] <seb128> which looks a bit weird
[10:00] <larsu> that's what I'm thinking
[10:00] <seb128> e.g x against ---
[10:00] <ochosi> larsu: yeah, i know... it has taken me *ages* to get elementary-xfce (which originated from the same source as humanity obviously) into shape
[10:01] <ochosi> i wouldn't mind helping you guys out with humanity, but then again it feels so useless as your new icon theme will come...
[10:01] <larsu> right, that's why I've been holding off as well
[10:01] <seb128> +1
[10:01] <larsu> but it's always such a pain to sort things out
[10:01] <seb128> we should fix obvious bugs where we spot them though
[10:02] <ochosi> well in this case it's a simple fix
[10:02] <seb128> somebody with icon drawing skills needs to blue->red
[10:02] <ochosi> you don't even have to go the long way and "sort things out" :)
[10:02] <larsu> (a) fix the icon (b) fix my patch
[10:02] <seb128> (e.g not me, I've no clue how to do that :p)
[10:02] <ochosi> seb128: i can do that if you want
[10:02] <seb128> ochosi, that would be nice
[10:02] <seb128> though why is this icon blue atm?
[10:02] <seb128> mpt, do you know?
[10:02] <ochosi> i guess someone designed it that way because they liked it :p
[10:03] <ochosi> (not specifically because it makes sense)
[10:03] <seb128> so yeah, if you want to make it red, please do
[10:03] <larsu> mpt: http://i.imgur.com/CRAcGg5.png
[10:03] <seb128> then we can update the indicator to use that one
[10:03] <ochosi> hah, the one from humanity has a really different style
[10:04] <ochosi> doesn't look very nice/consistent
[10:04] <seb128> right, it looks buggy
[10:04] <ochosi> ok, i'll quickly fix that for you...
[10:04] <larsu> mpt: we're using the red one right now, but assume the blue one would be more correct if it were red
[10:04] <larsu> mpt: do you agree?
[10:04] <seb128> ochosi, thanks
[10:04] <seb128> larsu, I like that program (the icon library) ;-)
[10:04] <larsu> seb128: me too :)
[10:04] <larsu> seb128: btw, is it packaged?
[10:05] <larsu> I'm still running it from some old source version
[10:05] <seb128> I don't think so (or in a ppa only), it should
[10:05] <seb128> same here
[10:05] <seb128> it runs fine from srcdir
[10:05] <larsu> it could be a bit faster in switching icon themes :)
[10:05] <ochosi> seb128: how/where do you want it?
[10:06] <seb128> ochosi, merge proposal against lp:ubuntu-themes would be best if you can do that
[10:06] <ochosi> and: you only need that icon once btw, it's the same in -dark and -light obviously
[10:06] <ochosi> ok
[10:06] <seb128> thanks!
[10:06] <ochosi> that'll take a while, my connection suuuucks :)
[10:06] <ochosi> (note: the icon is finished already, pulling and pushing will probably take 10x longer ;))
[10:08] <ochosi> any other icons that need fixing now that i'm at it?
[10:08] <seb128> not that I know
[10:08] <seb128> larsu, do you know of any?
[10:08] <ochosi> (you should really just merge ubuntu-mono and humanity...)
[10:08] <seb128> ochosi, just curious, what did you use to fix it? inkscape?
[10:08] <ochosi> seb128: yup
[10:09] <ochosi> this was extremely simple, as you only need to change the color
[10:09] <seb128> (yeah, we should ... but as you and larsu said, spending time on that feels pointless since we get a new theme)
[10:09] <ochosi> you could theoretically edit the xml directly as well
[10:09] <mitya57> ochosi: I think Humanity and ubuntu-mono have different license/copyright.
[10:09] <ochosi> true, it just pains me to see the mess :D
[10:10] <seb128> suru-icon-theme is the new theme for touch btw
[10:10] <seb128> I hope that comes to desktop as well
[10:11] <larsu> seb128: no I don't
[10:11] <larsu> ochosi: thanks
[10:13] <ochosi> seb128: yep, those are beautiful (kudos again, tiheum!)
[10:14] <ochosi> in fact it wouldn't be too hard to port those panel/indicator icons for the desktop...
[10:14] <ochosi> i mean of suru-icon-theme
[10:14] <seb128> ochosi, looking through ubuntu-mono in the icon library software, I don't see any other obvious candidate for fixing
[10:14] <seb128> right, it's a bit late now for this cycle though
[10:15] <hikiko> seb128, https://bugs.launchpad.net/unity-control-center/+bug/1294578 here it is
[10:15] <ubot2> Launchpad bug 1294578 in Unity Control Center ""Match the display settings" checkbox" [Undecided,New]
[10:15] <hikiko> I hope it helps...
[10:15] <seb128> hikiko, thanks
[10:16] <ochosi> seb128: ok
[10:16] <ochosi> yeah, i understand it's late for that
[10:18] <larsu> hikiko: why would I ever want to have this checkbox turned off?
[10:19] <larsu> (I hope I'm not starting a discussion you guys already had earlier)
[10:19] <hikiko> lol larsu
[10:19] <hikiko> because those are desktop settings
[10:20] <ochosi> larsu, seb128: ok, here you go: https://code.launchpad.net/~ochosi/ubuntu-themes/audio-volume-blocking/+merge/211694
[10:21] <seb128> ochosi, thanks!
[10:21] <ochosi> np
[10:21] <larsu> hikiko: what? If I understand correctly, I'll have mismatched scaling for titlebars and window contents when the checkbox is unchecked, right?
[10:21] <hikiko> the user might change them from any other program or from u-c-c when he selects larger fonts or when in multimonitor if he plugs a monitor let's say a projector and he needs to check the laptop's monitor while the projector is still plugged to see something or for any reason
[10:22] <hikiko> larsu, it depends...
[10:23] <hikiko> if it's unchecked because you checked something else or modified a scaling factor outside ucc yes
[10:23] <larsu> what is monitoring those settings to uncheck the checkbox?
[10:23] <ochosi> seb128: you have a few more broken symlinks in ubuntu-mono btw
[10:23] <larsu> or do you check whether the scaling factors are the same when I arrive in the settings panel?
[10:24] <hikiko> I use a gsetting for the selected-display
[10:24] <ochosi> seb128: specifically in ubuntu-mono-dark/status/22/
[10:24] <hikiko> when the selected-display is the current monitor
[10:24] <seb128> ochosi, if you want to fix those as well feel free ;-)
[10:24] <hikiko> I check if ui-scale == scaling-factor * text-scaling-factor +- error (very small rounding error)
[10:24] <hikiko> if this is not the case
[10:25] <hikiko> some factor was modified so I uncheck it
[10:25] <ochosi> seb128: yeah, there are a few more in -light...
[10:25] <hikiko> larsu, that's not the final widget
[10:25] <hikiko> mpt did a much better design
[10:25] <hikiko> we just decided to add something that works before 14.04 release
[10:26] <hikiko> and then improve it
[10:26] <hikiko> but it seems to work fine in multimonitor
[10:26] <ochosi> seb128: the main problem seems to be that whoever added the new indicator-keyboard icons must've also removed the old keyboard icon (input-keyboard) from the icon-theme, leaving behind broken symlinks...
[10:27] <seb128> Laney, did you mean to review/+1|-1 that 1 liner for the account panel, or did you just glance over it and prefer to let for robert_ancell?
[10:27] <hikiko> I mean you see no inconsistencies like: a button is checked when settings dont match the desktop or things like that
[10:27] <larsu> hikiko: I don't know. It seems overly complicated to me and I can't imagine ever wanting a different scaling factor for title bars and window contents
[10:27] <larsu> hikiko: thanks for clearing it up, though
[10:27] <Laney> seb128: I didn't look into it, seems fine to me but you may want to wait for desrt
[10:28] <seb128> Laney, ok, thanks for testing the sound one!
[10:29] <hikiko> larsu, if you have different ui-scale for each monitor since the scaling-factor and text-scaling-factor are for the whole desktop they won't always match your unity display settings
[10:29] <hikiko> so the user should choose in which monitor he wants the "perfect" match
[10:29] <hikiko> (same scaling)
[10:30] <hikiko> that's what the checkbox does
[10:30] <hikiko> if your monitors are a retina a laptop screen and a projector
[10:30] <hikiko> and they all use a different ui-scale factor
[10:31] <hikiko> you have to decide which monitor's ui-scale you want to have in gnome apps and set the scaling-factor and the text-scaling-factor of the whole desktop tou match that
[10:31] <hikiko> sorry :) I dont know if I make it more clear or more complicated now :p
[10:32] <larsu> hikiko: you totally did thanks. I understand the problem, but don't like the solution
[10:32] <hikiko> me neither :)
[10:32] <hikiko> we ll change it after release
[10:32] <larsu> and I'm a bit surprised that gnome's scaling-factor is per desktop and not per monitor
[10:32] <larsu> hikiko: I also don't like mpt's proposed solution...
[10:32] <hikiko> yes :/ all scaling factors :/
[10:33] <hikiko> larsu, then we can discuss it further before I submit a branch for it
[10:33] <hikiko> but we need to merge the checkbox
[10:33] <hikiko> to have the feature
[10:33] <hikiko> as we promised
[10:33] <hikiko> I mean after we test it ofc
[10:34] <seb128> ochosi, do you plan to send another merge request to fix some of the symlink issues? Just wondering if I should line up your other fix for landing yet or wait for another fix to come
[10:40] <Laney> hikiko: btw, it crashes when I run it http://paste.ubuntu.com/7119084/
[10:41] <ochosi> seb128: yes, pushing already
[10:41] <hikiko> Laney, did you install the gsetting?
[10:41] <Laney> yes, look at the bt
[10:41] <ochosi> seb128: is it a problem that it was done on top of the soundmenu-icon fix?
[10:41] <hikiko> sec
[10:42] <seb128> ochosi, no, not a problem
[10:42] <seb128> ochosi, thanks
[10:42] <Laney> I think that you should look into using glib functions rather than malloc/strcpy
[10:42] <hikiko> yes, will fix
[10:43] <hikiko> I'm replacing them right now, I forgot it :p
[10:43] <ochosi> seb128: MR done
[10:46] <seb128> ochosi, thanks
[10:50] <ochosi> seb128: well happy to be able to give something back for all the great support and helpin out this cycle! :)
[10:51] <ochosi> (guess now i have to stop looking at ubuntu-mono or i'll start fixing it...)
[10:52] <seb128> ochosi, ;-)
[11:05] <Laney> crap, the glib autopkgtest failed
[11:06] <seb128> :-(
[11:19] <jibel> Laney, fixed
[11:20] <Laney> jibel: oh, env problem?
[11:20] <jibel> Laney, the old rule: when it fails run it again until is passes
[11:20] <Laney> O_O
[11:20] <Laney> I was trying to reproduce it :P
[11:21] <Laney> but, good... I suppose
[11:22] <hikiko> seb128, I ll remove the code that sets the primary monitors settings from ucc
[11:22] <hikiko> you are right on that
[11:22] <hikiko> this should be done by unity
[11:22] <jibel> Laney, apparently gdbus-threading crashed on previous run
[11:23] <seb128> hikiko, unity-settings-daemon probably rather, that's what applies e.g the resolution
[11:23] <Laney> jibel: yep
[11:23] <hikiko> +1 seb128
[11:23] <hikiko> I am removing it
[11:23] <seb128> hikiko, btw I like Laney's suggestion of a button
[11:24] <hikiko> the only problem is that you have 0 feedback of what is selected/not
[11:24] <hikiko> not that the checkbox is the super widget
[11:24] <hikiko> :p
[11:24] <hikiko> the opposite
[11:24] <hikiko> but at least shows something
[11:24] <Laney> jibel: The ubuntu-sso-client one fixed itself too on another run
[11:24] <Laney> all good fun
[11:24] <jibel> Laney, yes, that's pitti-matic at work
[11:26] <Laney> we should just run all tests more than once and only consider a failure if they fail every time :P
[11:29] <Laney> hikiko: I guess it's not 'selected' if you have the buttons, but rather an operation which is performed
[11:29] <Laney> 'run this algorithm now'
[11:48] <hikiko> Laney, I ve fixed the branch, I think that if you try now it will be ok
[11:56] <Laney> hikiko: yeah, it doesn't crash
[11:56] <Laney> so it's totally unclear what that checkbox does
[11:57] <Laney> The design has a "Scale for window contents:" header that we probably want here
[11:57] <Laney> & I still prefer the button idea
[11:57] <Laney> thanks for working on this btw
[11:58] <hikiko> ok, it's easy to add the label, I'm not sure that the button does the same thing because the checkbox shows the selection, that's why i prefer the checkbox
[11:59] <hikiko> I'll add the Scale.. label as a first step :)
[11:59] <Laney> It doesn't, we're arguing that the current behaviour is complicated and confusing
[12:02] <hikiko> I don't disagree on that, I know that the checkbox is not the best widget, I just think that from button and checkbox the checkbox is slightly "better" because it makes clear that only one monitor is selected and which one is this
[12:02] <hikiko> bregma, Trevinho ^^ have you seen what Laney suggests? what do you think?
[12:03] <seb128> hikiko, I don't think the checkbox work, for the reason I pointed on the bug
[12:03] <seb128> hikiko, if I select another monitor it's going to show unchecked, but yet the scaling is still active, it's just based on computation from another screen
[12:03] <hikiko> no,
[12:04] <hikiko> if you select another monitor
[12:04] <hikiko> the last monitor selected
[12:04] <hikiko> will be used
[12:04] <seb128> that's buggy
[12:04] <seb128> what if I select another monitor to turn it off?
[12:04] <hikiko> no, that's what we want
[12:04] <seb128> or to change the resolution
[12:04] <seb128> but I don't want to use scaling from that one
[12:04] <hikiko> then you just wont check the button
[12:04] <hikiko> it wont be checked by default
[12:05] <seb128> right
[12:05] <seb128> if it's not checked, it makes me thing there is no scaling active
[12:05] <seb128> when there is
[12:06] <Trevinho> seb128, hikiko: ihmo we should just use one single monitor-idependent "use max scaling across monitors for everything"... That is imho the easiest way to achive sacalability withouth touching things too much
[12:06] <seb128> +1
[12:07] <hikiko> Trevinho, seb128 could you run it?
[12:07] <seb128> hikiko, let me build it
[12:07] <hikiko> i think the checkbutton is doing what it should
[12:07] <hikiko> you just select the monitor
[12:07] <hikiko> and when you move the ui slider
[12:07] <hikiko> you see the content scale too
[12:07] <hikiko> when unchecked
[12:08] <hikiko> you move the slider and the content doesnt scale
[12:08] <hikiko> it's very simple i think
[12:08] <seb128> expect that the GTK scaling is not by monitor
[12:09] <seb128> so having the checkbox changing according to the selected monitor is just weird
[12:09] <seb128> it also doesn't solve the conflicts with the accessibility text scaling setting
[12:10] <hikiko> seb128, all these are not solved by the button either and are not solved by the current design
[12:10] <hikiko> we have to plan a better approach
[12:10] <Trevinho> hikiko: the fact is... +app_checkbox_activation_deactivatio doesn't need to do anything but changing the setting. As I told you this change must be done in unity itself
[12:10] <hikiko> that button is just a partial solution
[12:10] <hikiko> Trevinho, the 1st time yes
[12:11] <Trevinho> hikiko: no, unity will do that
[12:11] <hikiko> but then if you plug a projector
[12:11] <seb128> hikiko, well, first thing I really dislike adding yet another gsettings key
[12:11] <hikiko> ok
[12:11] <Trevinho> hikiko: I mean, what UCC only have to do is to change a gsettings key, unity will handle the rest.
[12:11] <Laney> The button idea is meant to be a less confusing way of doing the same thing
[12:12] <hikiko> Trevinho, and next time you start ucc
[12:13] <hikiko> how would you know which monitor is selected
[12:13] <hikiko> to show the buttons checked or unchecked
[12:13] <seb128> the checkbox doesn't convey that info properly imho
[12:14] <Trevinho> hikiko: if we go for "use the max available scaling", we don't need to know anything
[12:14] <hikiko> yes but this doesnt help if you have a projector and a retina and need to swap between them
[12:14] <seb128> hikiko, it's not clear why changing monitor or checking the box for another monitor uncheck the one you had for the first one
[12:15] <seb128> nothing says "only one monitor can be checked at time"
[12:15] <seb128> or "checking that is going to uncheck oher non selected status"
[12:15] <hikiko> seb128, +1 I could add labels for that
[12:15] <Laney> A combo would convey it slightly better, but that's also not ideal
[12:15] <seb128> hikiko, if you want to say "the setting apply to <...>" you should have a combo that let you select the monitor
[12:15] <Trevinho> Why not just using a combo box for selecting wich monitor is the "target"?
[12:15] <Laney> ha
[12:15] <hikiko> cool
[12:15] <hikiko> that's a good idea :)
[12:15] <seb128> hikiko, same as the "launcher placement"
[12:16] <Trevinho> yeah
[12:16] <seb128> Trevinho, stop stealing my suggestions :p
[12:16] <hikiko> so I ll have a combo on the right with all monitors
[12:16] <Laney> I SAID IT FIRST!
[12:16] <hikiko> and choose 1?
[12:16] <hikiko> lol
[12:16] <Trevinho> seb128: ah, I didn't read it, but it just seemed the more natural thing to me :)
[12:16] <hikiko> Laney, thanks thanks :D
[12:16] <seb128> Trevinho, ;-)
[12:17] <hikiko> hahaha
[12:17] <hikiko> ok people just a sec
[12:17] <hikiko> to make sure
[12:17] <hikiko> I got it right
[12:17] <Trevinho> Anyway................ Going back to the thing, how it must done: we only need 2 gsettings key more, that should be in com.canonica.unity namespace (I don't want to put things that will be legacy in com.ubuntu.user-interface)
[12:17] <Trevinho> 1 target monitor
[12:17] <Laney> so unity does the scaling?
[12:17] <hikiko> so I have a combo with the plugged monitors
[12:17] <Laney> so it gets to own the key
[12:17] <Trevinho> 2 text-scaling-factor... (in case user has a different scaling factor)
[12:17] <hikiko> I put the key on unity
[12:17] <Trevinho> unity will handle the things
[12:17] <Trevinho> well, is handling them already here
[12:18] <Trevinho> UCC only has to set these vales, unity will guess the rest
[12:18] <hikiko> and what do i store Trevinho ?
[12:18] <hikiko> scaling-factor
[12:18] <hikiko> text-scaling-factor
[12:18] <hikiko> selected-monitor
[12:18] <hikiko> ?
[12:18] <Trevinho> hikiko: scaling-factor is already stored
[12:19] <Trevinho> hikiko: you (I) need to add two more keys inside com.canonical.unity gschema
[12:19] <hikiko> a custom text-scaling-factor
[12:19] <Trevinho> yes, that unity will then bind to the actual one... or ucc when unity is not running
[12:20] <hikiko> and the 2nd is the monitor i guess
[12:20] <Trevinho> but before we need to finish the unity part, the UCC Is just the last thing to do imho. hikiko i think you should get the UI ready for now, we'll change the gsetttings path once they're defined
[12:20] <Trevinho> yes
[12:20] <hikiko> ok Trevinho
[12:23] <Trevinho> I've to go to lunch and after that I've to take my girl friend to a visit, but I hope to come back in few hours...
[12:23] <hikiko> I ll leave in 30 minutes too, i have an apointment but i ll push the mp at night
[12:24] <Trevinho> hikiko: ok, that's fine... I'll work till late as well
[12:24] <seb128> hikiko, Trevinho: thanks for working on that ;-)
[12:29] <hikiko> np seb128 and Laney thanks for the reviews/feedback too :)
[12:29] <seb128> yw!
[12:46] <ochosi> larsu: just to know what's going to happen next, will you rename the icon in indicator-sound or is that still pending on something?
[12:48] <larsu> ochosi: yep, I'll rename it
[12:51] <ochosi> larsu: ok, thanks, just good to know i don't have to push another update to our icon-theme
[12:53] <Sweetshark> \o\ /o/ \o/
[12:54] <Sweetshark> ./run-adt-test finished successfully after 48min (guestimate: 42 minutes to provision, 6 minutes to run the tests)
[12:57] <mpt> larsu, what don’t you like about the design? :)
[13:00] <larsu> mpt: I don't understand why I would ever want titlebars with a different scaling than window controls
[13:00] <larsu> s/window controls/window contents/
[13:00] <mpt> larsu, oh, me neither. I grate my teeth whenever the window spread shows oversized title bars, for example.
[13:01] <mpt> larsu, but Compiz is drawing the title bars, so they get scaled along with the rest of Unity.
[13:01] <mpt> The whole thing is a snafu.
[13:02] <larsu> I don't know what a snafu is
[13:02] <larsu> but I'm glad you agree with me :)
[13:22] <nessita> hello everyone! I'm having an issue in a canonistack slave, running precise, where when installing librsvg2-common there is a seg fault in the output:
[13:22] <nessita> Processing triggers for libgdk-pixbuf2.0-0 ...
[13:22] <nessita> Segmentation fault (core dumped)
[13:23] <nessita> this is causing, I think, the svg library to missbehave
[13:23] <nessita> seems like bug https://bugs.launchpad.net/ubuntu/+source/gdk-pixbuf/+bug/1174253 describes the issue but there is no workaround
[13:23] <ubot2> Launchpad bug 1174253 in gdk-pixbuf (Ubuntu) "Segfault (core dumped) during upgrade 12.10 to 13.04" [Undecided,New]
[13:26] <nessita> pitti, heya! would you have any advice for what I just mentioned?
[13:27] <seb128> nessita, hey
[13:28] <seb128> nessita, not know, do you have a stacktrace?
[13:29] <seb128> nessita, you should probably upgrade to a support release btw, e.g 13.10
[13:30] <nessita> seb128, hola!
[13:30] <nessita> seb128, I'm running precise in this slave
[13:31] <nessita> seb128, this is the output http://pastebin.ubuntu.com/7119797/
[13:31] <seb128> nessita, oh, so likely not the same issue than the one you pointed out
[13:31] <nessita> no traceback, not sure how can I get onw
[13:31] <nessita> seb128, the apt output matches, that's why I linked the bug...
[13:33] <Laney> run /usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/gdk-pixbuf-query-loaders manually
[13:33] <nessita> Laney, trying
[13:33] <seb128> nessita, does it segfault if you run "sudo /usr/lib/#MULTIARCH#/gdk-pixbuf-2.0/gdk-pixbuf-query-loaders $(find /usr/lib/#MULTIARCH#/gdk-pixbuf-2.0/2.10.0/loaders-name *.so 2> /dev/null)" by hand?
[13:33] <seb128> where #MULTIARCH# is the triplet for your arch
[13:33] <nessita> Laney, got the segfault, trying with gdb
[13:33] <seb128> or what Laney said :p
[13:34] <nessita> :-P
[13:34] <Laney> install the gtk and glib debug package first
[13:34] <nessita> Laney, have the package name handy? or I can look them up
[13:35] <seb128> libgdk-pixbuf2.0-0-dbg
[13:35] <nessita> Laney, seb128: without the debug packages http://pastebin.ubuntu.com/7119821/
[13:35] <nessita> installing debug package
[13:35] <seb128> libc6-dbg as well
[13:35] <nessita>  E: Unable to locate package libgdk-pixbuf2.0-0-dbg
[13:35]  * nessita googles
[13:36] <seb128> install libc6-dbg and libglib2.0-0-dbg
[13:36] <seb128> that might be enough, seeing your bt
[13:37] <seb128> nessita, http://ddebs.ubuntu.com/pool/main/g/gdk-pixbuf/libgdk-pixbuf2.0-0-dbgsym_2.26.1-1_amd64.ddeb otherwise
[13:38] <nessita> traceback with debug symbols: http://pastebin.ubuntu.com/7119828/ (haven't installed libgdk-pixbuf2.0-0-dbg yet)
[13:40] <seb128> nessita, dpkg -l | grep libglib
[13:40] <nessita> ii  libglib2.0-0                                       2.37.5-1ubuntu2~precise1                      GLib library of C routines
[13:40] <nessita> ii  libglib2.0-0-dbg                                   2.37.5-1ubuntu2~precise1                      Debugging symbols for the GLib libraries
[13:41] <seb128> where is that coming from?
[13:41] <seb128> the precise version is 2.32
[13:41] <nessita> checking policy
[13:41] <nessita> ough
[13:41] <nessita>         500 https://private-ppa.launchpad.net/ubuntuone/scope-runner/ubuntu/ precise/main amd64 Packages
[13:41] <seb128> yeah
[13:41] <seb128> you got buggy stuff from the ppa...
[13:41] <nessita> seb128, thanks a lot for your help
[13:41] <nessita> will talk to the scope runner guys
[13:42] <nessita> :-)
[13:42] <seb128> nessita, yw, that's not a fix, but you are using an old unstable glib library that can't be good
[13:42] <desrt> my advice: never install glib
[13:42] <desrt> this software is trouble
[13:42] <seb128> desrt, you get coffee!
[13:42] <desrt> already got it :)
[13:42] <Laney> pre-coffee trolling
[13:42] <seb128> good morning then ;-)
[13:42] <Laney> oh!
[13:43] <nessita> seb128, what do you mean with old unstable glib?
[13:43] <nessita> if precise have 2.32, I would have thought 2.37.5 was newer
[13:45] <seb128> nessita, right, but odd number are unstable series
[13:45] <nessita> ah, right
[13:45] <seb128> nessita, look at https://launchpad.net/distros/ubuntu/+source/glib2.0
[13:45] <seb128> nessita, saucy has 2.38, trusty 2.39
[13:45] <seb128> 2.37 was the unstable leading to 2.38
[13:45] <seb128> if you want that serie you should at least take 2.38 proper
[13:45] <nessita> I see
[13:46] <nessita> will ping the scope runner guys
[13:46] <nessita> thanks!
[13:46] <Laney> well, try downgrading to precise's version of libglib2.0-0 and friends and see if it works
[13:46] <Laney> you can confirm it is indeed that
[13:49] <nessita> Laney, makes sense, any easy way of downgrading?
[13:50] <Laney> nessita: start with sudo apt-get install {libglib2.0-0/libglib2.0-common}/precise
[13:51] <Laney> maybe precise-updates
[13:51] <Laney> or just ppa-purge that PPA
[13:59] <nessita> Laney, it worked like a charm, thanks
[13:59] <Laney> nod
[13:59] <nessita> now we're defining how to move forward, turns out out jenkins slaves are building scope-runner which are now running server side but need libunity7 (???)
[14:00] <nessita> so we're having a lovely chat :-D
[14:09] <desrt> mterry: hey... how hard would it be to get rid of nopasswdlogin?
[14:10] <mterry> desrt, you mean, stop doing it on the phone?  we don't want to get ride of that I don't believe
[14:10] <mterry> *rid
[14:10] <desrt> mterry: here's the problem:
[14:10] <desrt> the user logs in with nopasswdlogin
[14:10] <desrt> then they run 'passwd'
[14:10] <desrt> they have no password, so they are able to change their password now
[14:10] <desrt> and now they have a password
[14:10] <desrt> but they're still in this group...
[14:11] <desrt> because the two ways that we've stored the idea that they have no password (as the null password hash in /etc/shadow and as the group-as-a-flag) are now out of sync
[14:11] <mterry> that's not inherently a problem
[14:11] <desrt> well -- they can't login anymore.  that's sort of a problem
[14:11] <mterry> desrt, nopasswdlogin doesn't mean they don't have a password.  It means they are allowed to be autologged in
[14:12] <desrt> doesn't it mean that the greeter doesn't prompt for the password field?
[14:12] <seb128> mterry, we should probably make a-s not call passwd -d and just add them to the group then?
[14:12] <mterry> desrt, eventually, once the phone's greeter is a real grown up greeter, the system settings will let them set a passwd and require a login
[14:12] <mterry> seb128, we shouldn't let user change password on phone yet I don't think
[14:12] <seb128> mterry, the issue is not phone specific, we are discussing it in the context of the desktop
[14:12] <mterry> seb128, ah
[14:12] <seb128> atm you can lock your only user out by doing what desrt said
[14:12] <mterry> seb128, yeah I think that's how g-c-c does it.  Just adds to group
[14:12] <seb128> use u-c-c to do "no password"
[14:12] <seb128> log back in
[14:13] <desrt> mterry: the control center just changes the user's password with the passwd command
[14:13] <desrt> so we should not have any workarounds in control center because the user could just bypass them by using passwd directly
[14:13] <seb128> mterry, it does both atm, passwd -d (upstream behaviour) + group
[14:13] <mterry> desrt, even for 'autologin' mode?  Are you sure, even with ubuntu patches and such?
[14:13] <seb128> desrt, mterry: we could update your a-s patch to delete the passwd -d call
[14:13] <desrt> mterry: the problem is when switching -away- from autologin
[14:14] <seb128> your->out
[14:14] <seb128> our
[14:14] <desrt> seb128: i'm not sure pam would allow the user to be logged in if they had a password...
[14:14] <seb128> desrt, they do
[14:14] <seb128> I set a password back through the gui
[14:14] <desrt> and just being in the group is enough?
[14:14] <seb128> lightdm keeps displaying me the "log in" button instead of a password entry
[14:14] <seb128> yes
[14:15] <desrt> huh
[14:15] <desrt> so make their password into some impossibly-long-random-string so they can never change it? :)
[14:15] <seb128> as you said, it doesn't even hit pam when you are in this group
[14:15] <mterry> desrt, yar that group is just about logging in, has nothing to do with existence of passwd
[14:15] <desrt> seb128: it always hits pam...
[14:15] <seb128> well, the point is that they want their password
[14:15] <seb128> otherwise you can't use polkit anymore
[14:15] <desrt> unless we want also to teach polkit about nopasswdlogin
[14:15] <seb128> if you have a passwd + group, you get auto login and the ability to use the admin tools
[14:16] <seb128> what's the issue with not calling passwd -d and just do the group thing?
[14:16] <desrt> seb128: this would not be at all clear in the current UI
[14:16]  * seb128 tries on his test box again, change the combo, use passwd to add a passwd and see what happens
[14:16] <seb128> how so?
[14:16] <desrt> since it looks like autologin is an alternative to having a password
[14:17] <desrt> ie: the idea of having a password _and_ having autologin is not well-presented in this UI
[14:17] <seb128> well, nopasswd != autologin
[14:17] <seb128> you are not automatically logged in with the "no password" option
[14:17] <seb128> it's just that the step to log in is a click and not a password
[14:17] <seb128> or hitting enter
[14:18] <seb128> to be fair the "no password" is well hidden
[14:18] <seb128> it's in a combo of the "change password" dialog that you get only if you unlocked the panel
[14:18] <desrt> erm...
[14:19] <seb128> ?
[14:19] <mterry> seb128, yeah sorry I thought we were talking about an autologin context before, I may have confused issue
[14:19] <seb128> mterry, https://bugs.launchpad.net/ubuntu/+source/accountsservice/+bug/815271
[14:19] <ubot2> Launchpad bug 815271 in accountsservice (Ubuntu Oneiric) "Cannot login if user account does not have a password" [High,Fix released]
[14:19] <seb128> mterry, is what we are talking about basically
[14:20] <desrt> seb128: this UI is megaconfusing
[14:20] <seb128> desrt, indeed
[14:20] <desrt> it freely mixes the concepts of no password and autologin
[14:20] <seb128> we should maybe just hide the "no password" in the combo :p
[14:20] <desrt> well
[14:20] <seb128> declare that we don't support that mode
[14:20] <desrt> "log in without a password" and "auto login" i guess
[14:21] <mterry> seb128, that bug is fixed, eh?  What's the proximate problem?
[14:21] <seb128> mterry, I was testing other changes in trusty and hit that scenario
[14:21] <seb128> - log in
[14:21] <seb128> - go to user panel
[14:21] <seb128> - unlock
[14:21] <desrt> does lightdm let the user login _after_ the first boot with no password even if they have a password, if nopasswdlogin is true?
[14:21] <desrt> i geuss the answer is yes, looking at the pam config
[14:21] <seb128> - click password -> no password
[14:22] <seb128> - log out
[14:22] <seb128> you can log back in by clicking a button
[14:22] <seb128> good so far
[14:22] <seb128> go to the user panel again
[14:22] <seb128> click passwd (without unlocking)
[14:22] <seb128> it asks you for a passwd
[14:22] <seb128> type it, validate
[14:22] <seb128> log out
[14:22] <seb128> you keep getting the button
[14:22] <seb128> no password entry
[14:22] <seb128> and you go "how the heck do I go back to a secure login"
[14:22] <seb128> mterry, ^^
[14:23] <seb128> that's the user visible issue
[14:23] <mterry> seb128, expected behavior from a backend point of view.  I think that's just a UI issue?
[14:23] <seb128> yeah
[14:23] <mterry> seb128, and I don't think anyone is thrilled with that UI as it is
[14:23] <seb128> desrt, yes, as long as you are in the group you can log out/in, reboot and log in, etc as many times as you want
[14:24] <desrt> seb128: what if you toggle the separate 'automatic login' switch in the UI?
[14:24] <seb128> mterry, yeah, could be
[14:24] <desrt> i mean... maybe this actually isn't a big issue?
[14:24] <desrt> i would expect that you get a polkit authentication dialog and then your autologin bit is removed
[14:24] <seb128> mterry, there is also the issue than picking "no password" calls "passwd -d" which makes polkit unhappy and let you without a way to do admin changes again
[14:25] <seb128> desrt, ^ that's an issue
[14:25] <seb128> you can't go back to change the mode
[14:25] <desrt> seb128: not if you reset your password again :)
[14:25] <seb128> since you can't unlock anymore
[14:25] <desrt> which you can do...
[14:25] <desrt> and for normal users, it would be asking the _admin_ password, not yours
[14:27] <seb128> right
[14:27] <desrt> i agree that it's a bit annoying that accountsservice happily sets no-password and polkit won't allow that
[14:27] <desrt> there is some sort of a mismatch there
[14:27] <desrt> but it actually has nothing to do with autologin
[14:27] <seb128> I'm still unsure why we need the passwd -d there?
[14:28] <seb128> what does it win us?
[14:28] <desrt> and nopasswdlogin is a hideously badly named group
[14:28] <seb128> out of locking you out of sudo/polkit
[14:28] <desrt> seb128: it makes it so that you have no password...
[14:28] <seb128> what's the benefit of that?
[14:28] <desrt> so you can change your passwd with passwd later, without knowing it
[14:29] <seb128> hum, good point
[14:29] <seb128> what happens in fedora when you do that?
[14:29] <seb128> are you locked out of polkit auths as well?
[14:29] <desrt> i guess it lets you set your password...
[14:29] <desrt> let me check
[14:30] <desrt> actually, on fedora they have removed the option :p
[14:30] <seb128> from where?
[14:30] <desrt> gnome-control-center
[14:30] <seb128> did you unlock?
[14:30] <desrt> yes
[14:30] <desrt> i'm trying to modify a different user
[14:30] <desrt> and i have only two choices:
[14:30] <desrt> 1) set a password now (possibly to a random value)
[14:31] <seb128> 2) password at next login?
[14:31] <desrt> 2) the user chooses their password at next login
[14:31] <seb128> hum
[14:31] <seb128> what if you add a new user?
[14:31] <desrt> the old dropdown is gone
[14:31] <desrt> ame
[14:31] <desrt> *same
[14:31] <rsalveti> Laney: pushed your hybris changes (libwayland) and decreased the default alternatives priority, it shouldn't break desktop anymore
[14:32] <seb128> desrt, right, part of https://git.gnome.org/browse/gnome-control-center/commit/panels/user-accounts/um-password-dialog.c?id=d134890b8b8785792eda1b30793915f435729333
[14:32] <desrt> maybe we should nuke the password-unset ability from accountsservice too
[14:32] <desrt> since it's obviously problematic
[14:33] <seb128> not sure, you might have users of the api/dbus method out there, you can't just change a public api like that
[14:33] <seb128> desrt, mterry: ok, I think I'm convinced it's a corner case and not an important issue
[14:33] <seb128> I suggest just moving on and not spending more time on it :p
[14:34]  * desrt takes a look at our as patches
[14:36] <desrt> there's still something here that's not right
[14:38] <desrt> okay... i'm back to thinking that nopasswdlogin should go away
[14:39] <desrt> because i just had myself autologged-in by gdm with a password set
[14:39] <desrt> and i'm not in the nopasswdlogin group
[14:39] <desrt> so this isn't working like we apparently think it is
[14:39] <seb128> lying!
[14:39] <seb128> "groups"?
[14:40] <seb128> oh, autologged
[14:40] <seb128> autologin != nopasswd
[14:40] <desrt> desrt adm sudo dip plugdev lpadmin sambashare
[14:40] <desrt> something is missing......
[14:40] <desrt> so nopasswdlogin really has nothing to do with autologin because... well... i'm logged in
[14:41] <seb128> " because i just had myself autologged-in by gdm with a password set
[14:41] <seb128>  and i'm not in the nopasswdlogin group"
[14:42] <seb128> I'm not sure I follow you
[14:42] <desrt> i went into the dialog, with a password set
[14:42] <desrt> and i did nothing other than flick the autologin toggle
[14:42] <desrt> then i reboot the machine
[14:42] <desrt> and i was automatically logged in
[14:43] <desrt> despite having a password and despite _not_ being in the nopasswdlogin group
[14:43] <desrt> which shows that nopasswdlogin has nothing to do with autologin
[14:43] <desrt> and it really is just a redundant bit of state
[14:44] <seb128> right
[14:44] <desrt> so i'm back to thinking we should remove it
[14:44] <seb128> but "nopasswdlogin" is different from autologin, if you read the gdm bug I pointed you at
[14:44] <seb128> those users want to be able to select in between different users
[14:44] <seb128> and entering the session without password
[14:44] <seb128> autologin allows only 1 user to be autologged
[14:45] <seb128> not 3 to be selectable, usable without password
[14:45] <seb128> so nopasswdlogin is more of "share a laptop in a family"
[14:45] <seb128> boot on the greeter, let you pick an user
[14:45] <seb128> don't bother you with auth
[14:46] <seb128> but yeah, I agree
[14:46] <seb128> those are confusing notions
[14:47] <desrt> seb128: forget autologin completely
[14:47] <desrt> since it really is a completely separate thing
[14:47] <seb128> right
[14:47] <desrt> this is controlled by a keyfile in /etc
[14:47] <seb128> you are the one who mentioned it
[14:47] <desrt> the question now is only about if a user has a password or not
[14:47] <desrt> seb128: mterry brought it into the discussion :)
 i went into the dialog, with a password set
[14:47] <seb128>  and i did nothing other than flick the autologin toggle
[14:47] <seb128>  then i reboot the machine
[14:47] <seb128> k
[14:47] <desrt> the unix way to have no password is to have a field :: in /etc/shadow
[14:47] <mterry> I did mention it  :)
[14:48] <seb128> let's refocus ;-)
[14:48] <desrt> and this is what i would expect to happen in your "family shares the laptop" case
[14:48] <desrt> and i see no reason why this cannot be the _only_ way
[14:48] <desrt> since having this separate group is massively increasing the complexity and introducing issues
[14:48] <seb128> read https://bugzilla.gnome.org/show_bug.cgi?id=414862 for the rational
[14:48] <ubot2> Gnome bug 414862 in general "Allowing passwordless connections" [Enhancement,Resolved: fixed]
[14:48]  * seb128 reads it again
[14:49] <qengho> Hi all. I'm looking at events coming from xinput2 for multitouch devices. The direct-mode touch screen in front of me reports RawTouch{Start,Update,End} events, Motion events, and others, but the APPL touch pad I have reports only Motion events. I expected more from the touchpad, since it says it has multitouch position "Valuators". What gives?
[14:49] <seb128> desrt, https://bugzilla.gnome.org/show_bug.cgi?id=414862#c12
[14:49] <seb128> desrt, suggest the intend from Milan was to not call passwd -d on those case
[14:49] <seb128> our "no password" option is a mix of concepts it seems
[14:49] <desrt> okay
[14:50] <desrt> so what we really want is a new toggle on the main page of the user's dialog
[14:50] <seb128> https://mail.gnome.org/archives/system-tools-list/2008-May/msg00000.html
[14:50] <desrt> "require password at login screen"
[14:50] <seb128> that would toggle the membership thing?
[14:50] <desrt> yes
[14:50] <desrt> and only that
[14:50] <seb128> and we orthogonal to the no password
[14:50] <seb128> right
[14:50] <seb128> we->be
[14:51] <Laney> rsalveti: I saw, thanks for that
[14:51] <Laney> didn't you need the higher priority for touch?
[14:51] <Laney> mesa was pulled there iirc
[14:51] <Laney> or did you add a hook into livecd-rootfs
[14:51] <desrt> maybe "require password to login locally" or something
[14:51] <seb128> desrt, I'm not convinced there is enough of a need/usecase to have it next to autologin, especially it's going to be difficult to explain the difference
[14:51] <desrt> since it also applies to screensaver
[14:51] <desrt> but presumably not to (eg) ssh connections
[14:51] <seb128> desrt, I'm starting to thing it's a power user config and shouldn't be in that tool :p
[14:52] <desrt> seb128: i'd be fine with nuking it entirely =) =)
[14:52] <desrt> either way, it should _definitely_ not be set from any option that is currently in accountsservice
[14:52] <desrt> since it is completely unrelated to anything currently there
[14:53] <desrt> maybe we want to add a new API for it though
[14:54] <seb128> desrt, the initial issue/reason why mterry adding the user to nopasswdlogin was that lightdm wouldn't let an user without passwd log in it seems (from the bug description linked to the patch), but I tried and that seems fixed in trusty
[14:55] <desrt> so there really is no need for that patch anymore
[14:55] <desrt> and meanwhile there is already the 'power user tweak tool'
[14:55] <desrt> sudo vi /etc/group :)
[14:56] <desrt> also meanwhile: we should probably remove the options from the UI for having no password (as did upstream gnome)
[14:56] <seb128> desrt, the main issue with dropping that patch is "what happens if users added themself to that group through the UI/by using the confusing combo"
[14:56] <seb128> then upgrade to trusty
[14:56] <seb128> then change their mind
[14:57] <rsalveti> Laney: changed livecd-rootfs to force a higher priority when building ubuntu-touch images
[14:57] <desrt> we could have a trusty upgrade script to knock everyone out of this group if they have a password set?
[14:57]  * desrt shrugs
[14:57] <Laney> rsalveti: rocking, that's basically both things I suggested
[14:57] <desrt> upstream gnome dropped the 'disable this account' option
[14:57] <seb128> desrt, some user might have put themself on purpose through vi and could be unhappy :p
[14:57] <rsalveti> Laney: yup
[14:58] <Laney> :)
[14:58] <desrt> seb128: if they did it with vi before, they can do it again :)
[14:58] <seb128> lol
[14:58] <seb128> desrt, oh, but I'm being stupid
[14:58] <seb128> desrt, the combo would still have "set password/set password at next login"
[14:58] <desrt> seb128: and perhaps 'disable'
[14:58] <seb128> I guess we could keep dropping them from the group when doing those
[14:58] <seb128> shouldn't hurt anyone
[14:59] <desrt> no.  we don't want to do that.
[14:59] <seb128> why not?
[14:59] <desrt> when the user's password is changed it doesn't mean that they want to be removed from the group
[14:59] <desrt> that would be annoying
[15:00] <desrt> imho we should forget that we ever did anything with this stuff and kick people out of the group on upgrade
[15:00] <desrt> if they did it via the dialog then they'll have no password and can login with a null password anyway
[15:00] <desrt> if they did it themselves, they can do it themselves again
[15:00] <seb128> yeah...
[15:01] <seb128> desrt, thanks for the chat, I think we have a plan, now I just need to make the different bits to happen ;-)
[15:01] <desrt> seb128: i'm mostly happy that i don't need to do anything anymore :)
[15:01] <seb128> haha
[15:01] <desrt> although maybe we want to chat with upstream gnome about adding this UI
[15:02] <desrt> i'll see what aday thinsk
[15:02] <seb128> yeah, I'm unsure, seems like too close from autologin/likely to confuse users
[15:02] <seb128> not sure there is enough of a demand/usecase
[15:04] <desrt> ya
[15:04] <desrt> the feature got dropped when moving from system tools to g-c-c...
[15:04] <desrt> maybe that was intentional
[15:05] <seb128> lot of things got dropped when moving
[15:05] <seb128> like the ability to selects your groups membership is one quite some users complain about
[15:05] <seb128> though that's less of an issue nowadays since less things rely on groups
[15:25] <xclaesse> seb128, any particular reason why empathy is still at 3.8 and the rest of GNOME at 3.10 in 14.04 ?
[15:30] <seb128> xclaesse, the rest of GNOME is not 3.10 (though we ended up updating quite some of the apps)
[15:33] <seb128> xclaesse, but no particular reason, out of the fact that nobody asked for it to be updated during the cycle
[15:33] <xclaesse> seb128, ok, I though everything was 3.10 already and empathy was the exception
[15:33] <xnox> seb128: what about gnome-terminal 3.10? does that have the auto-reflow thing or is that post 3.10?
[15:34] <seb128> xnox, I've no clue, ask Laney he's the closest of a maintainer we have for that one
[15:34] <seb128> I've no interest in command lines/didn't look at g-t for years
[15:34] <xclaesse> seb128, I perfectly understand to be conservative on LTS, if there are no strong reason to upgrade ;-)
[15:35] <seb128> xclaesse, well, we defaulted to stay on 3.8 and then picked up "safe 3.10 updates", which ended up including apps like eog/gedit/nautilus, I've to admit I didn't look much at empathy to see what changes were in 3.10
[15:36] <xclaesse> seb128, otoh, from an upstream POV, it means you're less likely to get fixes backported if needed. It is already unlikely that GNOME will backport fixes into 3.10 when 3.12 is released, and I think nobody will even care about 3.8 anymore.
[15:36] <seb128> I think I did look at the git log earlier in the cycle and there were quite some telepathy changes, which I was unsure how likely those were to create issues
[15:36] <Laney> We talked about gnome-terminal at the sprint
[15:36] <Laney> It's that bash / vte thing, remember?
[15:37] <seb128> xclaesse, right, that's going to be true even if we pick 3.10, in 1 year nobody is going to care about 3.10 anymore
[15:37] <xclaesse> seb128, not sure myself what 3.10 adds tbh ;-)
[15:37] <xclaesse> seb128, right, I personally think it is problem #1 of many OSS
[15:37] <xclaesse> and GNOME in particular
[15:38] <seb128> the issue that apps keep bumping their requirement to the latest GTK
[15:38] <seb128> which means it's impossible to backport new softwares to the distros users run
[15:38] <seb128> some upstream do try to stay compatible though
[15:38] <seb128> like the shotwell team makes sure they run on the current Ubuntu LTS
[15:38] <bjf> xnox, bug 1294721
[15:38] <ubot2> Launchpad bug 1294721 in ubiquity (Ubuntu) "trusty-desktop-amd64+mac.iso install fails with "ubi-usersetup failed with exit code 2"" [Critical,New] https://launchpad.net/bugs/1294721
[15:39] <seb128> it means using an 1.5 years old GTK atm
[15:39] <desrt> seb128: so imho we should drop the 'no password' option from this dialog for now
[15:39] <xclaesse> seb128, IMO we really should have a sync LTS cycle between major distros and upstream
[15:39] <xclaesse> until we get that, we'll never have proper QA
[15:39] <desrt> seb128_aync, that is
[15:39] <xclaesse> unless for RHEL where they invest a lot, maybe
[15:40] <seb128> xclaesse, we sort of have, RHEL7 ships with GNOME 3.8 :p
[15:40] <xnox> bjf: is that with "encrypt my home directory", "full disk encryption", or *both* options enabled?
[15:40] <bjf> xnox, just "encrypt my home directory"
[15:40] <seb128> desrt, right
[15:41] <seb128> desrt, btw can you +1 https://code.launchpad.net/~seb128/unity-control-center/users-prompt-when-needed/+merge/211596 ?
[15:41] <xclaesse> seb128, oh didn't know RHEL7 is 3.8, yep so that does speak in favor of keeping 3.8 where 3.10 is not needed for ubuntu LTS indeed
[15:42] <desrt> seb128: done
[15:43] <seb128> desrt, thanks
[15:45] <xnox> bjf: k, thanks.
[16:02] <damianatorrpm> Hi all :)
[16:03] <damianatorrpm> I compiled QMenuModel (https://code.launchpad.net/qmenumodel/)
[16:03] <damianatorrpm> but if I try to compile the examples
[16:03] <damianatorrpm> they fail that QMenuModel has no function QMenuModel::LinkSubMenu
[16:04] <damianatorrpm> and that's true QMenuModel doesn't have this member anymore since 30 branches ago
[16:04] <damianatorrpm> anyone working on a fix?
[16:12] <seb128> dednick, larsu: ^
[16:21] <dednick> seb128: hm. yeah. I dont think examples were updated in a long while
[16:21] <seb128> damianatorrpm, ^
[16:22] <dednick> damianatorrpm: I dont think qmenumodel is being supported anymore. We're using unitymenumodel nowadays.
[16:22] <dednick> larsu: ^ ?
[16:36] <seb128> om26er, hey
[16:36] <om26er> seb128, hello
[16:36] <seb128> om26er, could you help us with autopilot issues?
[16:37] <seb128> om26er, https://code.launchpad.net/~diegosarmentero/ubuntu-system-settings/click-updates/+merge/208567 fails on the CI/device but not on desktop
[16:37] <om26er> seb128, yes, sure.
[16:37] <seb128> File "/usr/lib/python2.7/dist-packages/autopilot/introspection/dbus.py", line 323, in select_single
[16:37] <seb128> raise StateNotFoundError(type_name, **kwargs)
[16:37] <seb128> StateNotFoundError: Object not found with name '*' and properties {'objectName': 'systemUpdatesPage'}.
[16:37] <seb128> om26er, I tried with the debs from jenkins, e.g http://jenkins.qa.ubuntu.com/job/generic-mediumtests-builder-trusty-armhf/3553/artifact/work/output/*zip*/output.zip
[16:37] <seb128> running
[16:37] <seb128> $ phablet-test-run ubuntu_system_settings.tests.test_system_updates.SystemUpdatesTestCases.test_show_updates
[16:38] <seb128> same tests work fine on desktop
[16:39] <mlankhorst> hm I upload mesa to the wrong place and I get a phoronix article ._.
[16:39] <om26er> seb128, did the issue happen on your phone ?
[16:39] <seb128> om26er, yes
[16:39] <seb128> om26er, with the command I gave you
[16:39] <seb128> running the same test on desktop works fine though
[16:39] <seb128> which puzzles me, either the objectName is valid or not
[16:39] <seb128> why is it behaving differently on the device?
[16:40] <seb128> (the icon correspond is also on screen so not a scrolling issue)
[16:54] <om26er> seb128, this fixes the issue http://paste.ubuntu.com/7120773/
[16:54] <seb128> gatox_lunch, ^
[16:54] <om26er> so yes, what you said
[16:54] <Laney> my favourite function ♥
[16:56] <damianatorrpm> ok thanks :)
[16:56] <seb128> om26er, I don't really understand, is the issue that the other function doesn't work with touch devices?
[16:56] <seb128> or is that a scrolling issue?
[16:56] <seb128> because the icon is on screen on the n4
[16:56] <om26er> seb128, I believe move_to_object is broken, if you had just click_object() that would work as well
[16:57] <om26er> click_object() is a combination of move_to_object() and click()
[16:57] <Laney> I didn't get separate move_to and click to work
[16:57] <Laney> someone told me to use click_object()
[16:58] <Laney> might as well always use scroll_to in case it goes off screen in the future - the function should handle the on-screen case fine
[16:58] <om26er> probably because on touch devices there is no such thing as "move to location"
[16:58] <om26er> you just tap ;)
[16:59] <seb128> om26er, confirmed it works, thanks!
[16:59] <seb128> gatox_lunch, ^ can you add that to your branch?
[16:59] <om26er> seb128, \o/
[17:00] <seb128> Laney, want to review/test https://code.launchpad.net/~diegosarmentero/ubuntu-system-settings/click-updates/+merge/208567 before I put it in a silo ?
[17:00] <Laney> it should move your 'finger' to that location
[17:00] <om26er> seb128, I though ChrisGagnon was already working on upgrade testing which would have covered this part with real update testing
[17:00] <Laney> seb128: ok
[17:00] <seb128> Laney, it's too much code for a proper review, but it has integration tests, looks fine in principle and works on the device
[17:00] <om26er> Laney, technically it will drag the screen :)
[17:00] <Laney> lemme finish this thing up then I'll look at it
[17:00] <seb128> om26er, I'm trying to get https://code.launchpad.net/~diegosarmentero/ubuntu-system-settings/click-updates/+merge/208567 merged in
[17:01] <seb128> Laney, thanks
[17:01] <om26er> btw these tests fail when there is an update available, they did for me for example
[17:02] <om26er> e.g. http://paste.ubuntu.com/7120829/
[17:03] <Laney> I've told gatox_lunch about that before
[17:03] <seb128> Laney, om26er: http://bazaar.launchpad.net/~diegosarmentero/ubuntu-system-settings/click-updates/revision/646
[17:03] <seb128> I told him today as well, he commited that
[17:03] <seb128> which fixes it for system updates
[17:04] <seb128> but there seems to still be an issue when click updates are available
[17:04] <seb128> I confirmed that the commit fixes the issue the system updates case
[17:04] <om26er> great!
[17:08] <seb128> Laney, "undefined reference to symbol '_Znwj@@GLIBCXX_3.4'", webkit doesn't like you today :-(
[17:10] <Laney> it's broken on armhf anyway
[17:10] <Laney> I asked berto about it
[17:10] <Laney> (see the debian buildlog)
[17:12] <seb128> right
[17:16] <larsu> damianatorrpm: what dednick said. qmenumodel is still in the repo, but it's not used anywhere. What do you need it for?
[17:17] <seb128> larsu, dednick: if that has no rdepends we should make clean it out?
[17:17] <damianatorrpm> larsu: thanks Lars. Is unitymenumodel a seperate package?
[17:17] <larsu> seb128: unitymenumodel is in the same repo... but I think that's only used by unity itself?
[17:17] <larsu> damianatorrpm: no, unfortunately not
[17:17] <seb128> larsu, oh, ok
[17:17] <larsu> maybe it should just be part of unity8 though
[17:18] <dednick> larsu: i think it's used in settings as well
[17:18] <larsu> ah
[17:18] <dednick> unitymenumodel i mean
[17:18] <larsu> I think you might be right
[17:18] <larsu> at least the action part
[17:19] <damianatorrpm> larsu: I want to tinker with it ;) a standalone app for gmenumodel
[17:19] <damianatorrpm> or similar
[17:19] <larsu> interesting
[17:19] <larsu> there's an example for unitymenumodel in there as well (iirc)
[17:19] <dednick> larsu: qdbusactiongroup still being used
[17:20] <damianatorrpm> larsu: and I have a live cd with my own panel now based on libqt5xdg, libkwindowsystem and gsettings-qt
[17:20] <damianatorrpm> larsu: a menu plugin would be nice too ^^
[17:21] <damianatorrpm> larsu: still very ugly stage
[17:21] <damianatorrpm> larsu: https://github.com/damianatorrpm
[17:21] <larsu> neat :)
[18:02] <seb128> mterry, hum
[18:02] <mterry> seb128, hello!
[18:02] <seb128> mterry, I don't understand https://code.launchpad.net/~mterry/ubuntu-system-settings/custom-pages/+merge/209562
[18:02] <seb128> mterry, didn't that land/got merged back yesterday, http://bazaar.launchpad.net/~system-settings-touch/ubuntu-system-settings/trunk/revision/657
[18:03] <seb128> mterry, why is the mp not closed? did launchpad not see the merge back for some reason? did you push on the same location a new branch?
[18:04] <mterry> Looks like I merged from trunk and pushed again (not realizing it had made trunk already) -- this was part of my effort to make pagination merge clean
[18:04] <seb128> mterry, lp:~mterry/ubuntu-system-settings/pagination still gives me a criss-cross ... can you just redo it on top of current trunk? seems like that's going be easier than trying to make bzr happy
[18:04] <mterry> seb128, sure
[18:04] <seb128> mterry, thank
[18:04] <seb128> s
[18:04] <seb128> mterry, I'm marking the custom-pages one merged
[18:04] <mterry> seb128, I just did
[18:05] <seb128> thanks
[18:06] <Laney> I've got to go, will look at the click MP first thing in the morning
[18:06] <Laney> have a good evening one and all
[18:06] <seb128> Laney, thanks, you too!
[18:06] <Laney> I noticed that webkit build failure was some terrible fat fingering on my part, trying again
[18:06] <Laney> hopefully even the armhf, but I'm not expecting to get that lucky
[18:06] <seb128> Laney, let's see
[18:15] <mterry> seb128, omg, I did that and now there is some weird conflict in debian/changelog
[18:15] <seb128> mterry, your vcs shouldn't even include debian/changelog? did you have a local dch or something?
[18:16] <mterry> seb128, no debian/changelog?  It's in trunk...
[18:16] <seb128> mterry, well I mean your branch should edit that file
[18:16] <seb128> bzr log debian/changelog?
[18:16] <mterry> seb128, right.  It has 0.1+14.04.20140318-0ubuntu1
[18:17] <mterry> seb128, if you look at https://code.launchpad.net/~mterry/ubuntu-system-settings/pagination/+merge/210790
[18:17] <seb128> wth
[18:17] <mterry> seb128, you'll see my branch is "deleting" some merge conflict crap
[18:18] <seb128> mterry, http://bazaar.launchpad.net/~system-settings-touch/ubuntu-system-settings/trunk/view/head:/debian/changelog doesn't include those
[18:18] <seb128> mterry, bzr blame debian/changelog | grep >>> ?
[18:18] <mterry> seb128, ¯\_(ツ)_/¯
[18:18] <seb128> lol
[18:18] <seb128> that's quite a nice smiley!
[18:18] <mterry> seb128, nothing
[18:19] <seb128> is '>' a special char?
[18:19] <mterry> seb128, I quoted it
[18:19] <seb128> let me bzr get your branch
[18:21] <seb128> mterry, I don't understand what's going on ...
[18:22] <seb128> mterry, I think it's your "merge from trunk" (639.4.8) which confuse it
[18:22] <mterry> seb128, shall I try for a third time?
[18:22] <seb128> mterry, just branch trunk, appli your diff manually, commit, push --overwrite
[18:22] <seb128> drop those merge from trunk
[18:22] <seb128> bzr is confused
[18:22] <mterry> seb128, I thought that's what I did...  except I uncommitted and pulled
[18:22]  * mterry starts fresh
[18:23] <seb128> mterry, uncommit; diff > diff; revert; patch -p0 < diff
[18:23] <mterry> basically
[18:23] <seb128> mterry, the issue when you uncommit is that bzr keeps track for what you merged
[18:23] <seb128> like you see it at the bottom of the commit log in "bzr commit"
[18:23] <seb128> so it's not a clean diff
[18:23] <seb128> bzr revert makes it forget
[18:23] <mterry> I did make a clean diff though...
[18:23] <mterry> Maybe I screwed up revert
[18:23] <mterry> Regardless
[18:23] <seb128> well, your branch has some knowledge of past merges
[18:26] <seb128> bzr log -n0 | less -> see 639.4.8
[18:26] <seb128> typically that happens if you "bzr merge; bzr uncommit" and then don't revert
[18:26] <seb128> but anyway, no point discussing it for hours, revert and reapply the diff and let's see ;-)
[18:26] <seb128> mterry, (sorry for the lag, wifi is acting up sometime, it doesn't disconnect me but stop transferring datas, I just notice when I try to hit the internet or notice the irc lag-o-meter)
[18:29] <GunnarHj> Hi seb128!
[18:29] <seb128> GunnarHj, howdy
[18:29] <GunnarHj> seb128: If you start Rhythmbox in 14.04, you don't see the controls in the sound menu as in this image:
[18:29] <GunnarHj> https://help.ubuntu.com/13.10/ubuntu-help/figures/unity-appmenu-intro.png
[18:29] <GunnarHj> Is it a bug, or has the feature been dropped?
[18:29] <seb128> GunnarHj, it's a bug, it works for me
[18:29] <seb128> GunnarHj, do you have the mpris plugin enabled?
[18:31] <GunnarHj> seb128: I tested with a full updated installation - hadn't installed mpris specifically, will have to check. Doug and Kevin in the docs team had the same problem.
[18:32] <seb128> GunnarHj, I can confirm on my test machine which has a recent install, let me debug
[18:32] <GunnarHj> seb128: Ok, thanks.
[18:34] <seb128> GunnarHj, try installing rhythmbox-plugins
[18:35] <mterry> seb128, I also resubmitted MP to kick it in pants.  Looks fine now
[18:36] <seb128> mterry, happier now, thanks!
[18:36] <GunnarHj> seb128: Will do that later. Is it a missing dependency?
[18:36] <seb128> GunnarHj, yes, I'm fixing it
[18:36] <seb128> it should be a recommends
[18:37] <GunnarHj> seb128: Ok, recommends should be sufficient, I suppose. Thanks!
[18:37] <seb128> yw!
[18:37] <seb128> mterry, lp:~mterry/ubuntu-system-settings/sim-pic has the same issue
[18:37] <seb128> mterry, criss-cross and conflicts :/
[18:37] <seb128> mterry, can you fix that one as well?
[18:37]  * mterry hulk stomps
[18:37] <seb128> ;-)
[18:41] <mterry> seb128, fixed
[18:42] <seb128> mterry, works!
[18:42]  * seb128 adds Cimi's change and test build
[18:42] <seb128> mterry, thanks
[18:52] <seb128> mterry, hum, are the dots off by one?
[18:52] <mterry> seb128, are they?
[18:52] <seb128> we get "hello (1) -> sim (not in the dots/skip) -> settings (2) ->  that's it (3)
[18:53] <seb128> mterry, ^
[18:53] <seb128> I would expect the "that's it" to have all the dots colored
[18:53] <mterry> seb128, that looks fine?
[18:53] <seb128> there is one missing, that suggest there is still a page coming?
[18:53] <mterry> seb128, it does?  there are 3 dots
[18:53] <mterry> seb128, you have 4 dots?
[18:54] <mterry> seb128, do ls wizard/qml/Pages/
[18:54] <seb128> mterry, http://people.canonical.com/~seb128/uss.png
[18:54] <seb128> $ ls wizard/qml/Pages/
[18:54] <seb128> 10-welcome.qml  20-wifi.qml.disabled  80-finished.qml  no-sim.qml
[18:54] <seb128> 20-wifi.qml     30-location.qml       data             spinner.qml
[18:54] <mterry> seb128, you should only have 3
[18:54] <mterry> seb128, that looks like 3
[18:55] <seb128> 10 20 30 80 ?
[18:55] <mterry> seb128, 20 is disabled
[18:55] <seb128> it's there twice
[18:55] <seb128> is the .disabled masking the entry?
[18:55] <mterry> seb128, once is the file that disables it
[18:55] <mterry> seb128, yeah
[18:55] <seb128> k
[18:55] <seb128> weird
[18:55] <seb128> ok, need to go for dinner but I'm going to try debugging it after that
[18:55] <seb128> ttyl!
[18:55] <mterry> seb128, to make it easier for customization to hide an existing page
[18:57] <mterry> seb128, maybe actually what needs to happen is ls debian/tmp/usr/share/ubuntu/settings/wizard/qml/Pages/
[18:57] <mterry> seb128, since that's where test.sh is loading from
[19:36] <seb128> mterry, ok, I get 3 dots after installing the debs, so I guess when running from src something is looking in the system location, my mistake for not installing those earlier
[19:36] <mterry> seb128, huh,
[19:36] <mterry> k
[20:04] <gtpr23789> Hi all!
[20:05] <gtpr23789> Does anyone have any experience using the Ubuntu Customization Kit?
[20:22] <robert_ancell> mterry, hey, can you remember the reasoning for checking the revert_to focus form http://bazaar.launchpad.net/~unity-greeter-team/unity-greeter/trunk/revision/604?start_revid=604 ? That's going to be racy right as the focus might have changed by the time you check it
[20:25] <mterry> robert_ancell, fair...  the reasoning is in the comment there though right?
[20:26] <robert_ancell> mterry, does it fail if revert_to is FocusParent?
[20:27] <mterry> robert_ancell, fail?
[20:27] <robert_ancell> Does the logic "focus on main window when any unmap occurs" not work?
[20:36] <seb128> robert_ancell, hey, if you switch user from a guest, is it supposed to close the guest session on you?
[20:36] <robert_ancell> seb128, no
[20:37] <seb128> ok, that seems to be buggy
[20:37] <robert_ancell> that does not sound like a useful feature
[20:37] <seb128> right, I though that switch to your user and pick guest session was bringing you back to the open one
[20:37] <seb128> but it seems to not be the case in trusty
[20:37] <seb128> we were wondering if that's by design or a bug
[20:38] <robert_ancell> log?
[20:38] <seb128> no log (yet)
[20:38] <seb128> but it doesn't close it
[20:38] <seb128> in fact I did
[20:38] <seb128> user -> guest (through indicator-session)
[20:39] <seb128> guest -> user (through indicator session)
[20:39] <seb128> that sends you to the greeter
[20:39] <seb128> change to "guest" on the greeter, enter
[20:39] <seb128> that seems to open a new guest
[20:39] <seb128> I close that, came back to my session
[20:39] <seb128> then picked guest in the indicator and it seems like that it sends me to my old guest
[20:39] <seb128> though it's locked, unity locking screen bug :/
[20:41] <seb128> https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1292154
[20:41] <ubot2> Launchpad bug 1292154 in unity (Ubuntu) "Unity ignores "disable-lock-screen" desktop key" [High,Confirmed]
[20:41] <seb128> andyrock, ^
[20:42] <robert_ancell> seb128, could you reproduce the greeter focus issue anymore?
[20:42] <seb128> robert_ancell, I was never able to reproduce it, not even once :/
[20:43] <seb128> neither on my laptop nor on the test touch laptop I've been using recently for testing
[20:45] <charles> rorbert_ancell, seb128, is the "greeter focus issue" the one where you can't type your password until you've done something like click on an indicator and then back to the pw field?
[20:45] <seb128> charles, yes
[20:45] <seb128> charles, do you get it by any chance?
[20:45] <charles> robert_ancell, seb128, I'm seeing that fairly regularly, a couple of times a week
[20:45] <robert_ancell> aha, a testing victim :)
[20:45] <seb128> nice!
[20:45] <charles> I don't have a recipe, but just judging from the numbers I could probably be a guinnea pig
[20:46] <robert_ancell> charles, do you think you could run lp:~robert-ancell/lightdm/wm-log and check /var/log/lightdm/x-*-greeter.log after it occurs?
[20:46] <robert_ancell> It just has a little extra debugging
[20:48] <seb128> robert_ancell, you should maybe add the call to xwininfo in there as well?
[20:49] <seb128> or are the debug statement you added enough to guess the stacking?
[20:49] <robert_ancell> seb128, there's not an obvious place to call it and it might affect the timing
[20:49] <seb128> k
[20:49] <robert_ancell> seb128, the debug statements indicate what u-g is triggering
[20:49] <charles> robert_ancell: will do
[20:49] <robert_ancell> I'm assuming it's being driven wrong by u-g.
[20:49] <robert_ancell> charles, ta
[20:50] <charles> robert_ancell: if it helps your guessing any, I've seen it very frequently right after boot.... I don't recall ever seeing it after just logging out to the greeter
[20:50] <robert_ancell> charles, that seems to be the only time anyone sees it
[20:50] <robert_ancell> I did around 20 boots here and no problems
[20:52] <charles> robert_ancell: I'll ping you if/whenI have some news.
[20:52] <robert_ancell> charles, ta
[20:52] <charles> robert_ancell: I'll try to reboot a little more often :)
[22:09] <charles> robert_ancell: ping
[22:10] <charles> robert_ancell: I'm experiencing that greeter focus issue right now on another box and can test live if there's anything you want me to try
[22:10] <charles> robert_ancell: also I have that log for you
[22:57] <robert_ancell> charles, I take it you're not experiencing it right now :)
[22:57] <ochosi> robert_ancell: hey! we've been seeing a weird lightdm-gtk-greeter bug recently and i was wondering whether you have a hint for me where to look
[22:58] <robert_ancell> charles, your log shows some random window has got focus
[22:58] <robert_ancell> charles, could you run https://bugs.launchpad.net/ubuntu/+source/unity-greeter/+bug/1255558/comments/70 after it occurs next time?
[22:58] <ubot2> Launchpad bug 1255558 in unity-greeter (Ubuntu) "Can't type my password after cold boot" [High,Triaged]
[22:59] <robert_ancell> ochosi, I heave to leave in a few minutes but go ahead
[22:59] <ochosi> robert_ancell: concretely, it seems that it doesn't exit gracefully and keeps running as a zombie in the session (i saw two lightdm-gtk-greeter windows in my taskbar), obviously that makes the session very wonky. problem is that we haven't found a way to consistently reproduce it. it happens almost never, but often enough that ppl notice
[22:59] <ochosi> (thanks)
[22:59] <robert_ancell> ochosi, I think I saw that report go past - is the greeter being launched by a script?
[23:00] <robert_ancell> Because lightdm should have sent a SIGTERM to the greeter process and not launch the session until it has quit
[23:00] <robert_ancell> if a script got in-between and it didn't exec the greeter then just the script would have terminated and the greeter might remain
[23:00] <ochosi> robert_ancell: the greeter is being launched by lightdm, as always, we've never touched that ever
[23:00] <ochosi> so it still dates back to you ;)
[23:00] <robert_ancell> ochosi, that's what I feared ;?
[23:00] <robert_ancell> ;)
[23:00] <robert_ancell> ochosi, do you have a lightdm.log file?
[23:01] <robert_ancell> ochosi, (we're not seeing this in unity-greeter)
[23:01] <ochosi> robert_ancell: hm, not really because it happens almost never. it only happened to me once, and at the time i thought it was just a fluke
[23:02] <ochosi> robert_ancell: and as it went away and i've never experienced it since, i felt confirmed. and then the bugreport flew in and got confirmed...
[23:02] <robert_ancell> ochosi, I've got to go now, but that was my only thought off hand
[23:02] <ochosi> robert_ancell: the only new thing is that we're using indicators
[23:02] <robert_ancell> ochosi, the logic from lightdm is send SIGTERM, wait for process to exit then continnue
[23:02] <ochosi> hence upstart
[23:02] <robert_ancell> so something has broken in between that
[23:02] <ochosi> ok
[23:03] <ochosi> will dig further...
[23:03] <ochosi> just annoying because i can't even get logs of this myself :/
[23:10] <ochosi> robert_ancell: anyway, thanks!