[05:11] <pitti> Good morning
[05:14] <pitti> larsu: oh, doing systemd pull requests now :)
[05:42] <didrocks> good morning
[05:42] <pitti> bonjour didrocks
[05:43] <didrocks> hey pitti, how are you?
[05:43] <pitti> didrocks: quite fine, thanks! went to play badminton with some friends yesterday
[05:44] <pitti> didrocks: et toi ?
[05:44] <didrocks> pitti: starting to get a little bit sick, let's see how it evolves today
[05:44] <pitti> didrocks: erk :/
[05:45]  * TheMuso waves hello.
[05:45] <TheMuso> Getting sick sucks.
[05:45] <didrocks> hey TheMuso!
[05:46] <TheMuso> Hey didrocks, get better soon. :)
[05:46] <didrocks> thanks ;)
[06:16] <larsu> good morning!
[06:16] <larsu> pitti: indeed -  I want to drop in to the conference after all ;)
[06:17] <seb128> good morning desktopers
[06:17] <seb128> hey larsu
[06:17] <seb128> what conference?
[06:18] <larsu> seb128: systemd has a conference in Berlin in November
[06:18] <pitti> hey seb128
[06:18] <pitti> larsu: it might actually be that I can't come :/
[06:19] <larsu> and I made a tiniest commit :)
[06:19] <larsu> pitti: oh?!
[06:19] <pitti> larsu: we originally planned to have the sprint in London, and so I could have flewn over from London to Berlin on Thursday evening
[06:19] <seb128> oh, ok
[06:19] <pitti> larsu: but now Steve says the office is already booked so we'll have the core sprint in the US instead
[06:20] <pitti> larsu: I can still try to fly on Thu evening and arrive in Berlin Friday noon, but I'll be an utter wreck
[06:21] <didrocks> good morning larsu! re seb128
[06:21] <seb128> re didrocks :-)
[06:23] <seb128> hum
[06:23] <seb128> what's going on with armhf autopkgtests?
[06:24] <seb128> gtk has been uploaded yesterday afternoon and all those are still inprogress
[06:24] <larsu> pitti: ah ... complicated :)
[06:24] <larsu> didrocks: morning!
[06:24] <seb128> same for pulseaudio
[06:24] <seb128> pitti, ^ is that just backlog?
[06:24] <pitti> Listing queues ...
[06:25] <pitti> debci-wily-armhf 312
[06:25] <pitti> sorry .. KDE tests take an aching amount of time
[06:25] <seb128> oh, right, KDE spam uploads
[06:25] <seb128> pitti, danke
[06:25] <pitti> I started a second worker on all 8 ARM boxes
[06:25] <pitti> this sohuld increase throughput
[06:25] <pitti> but still a lot of backlog, sorry
[06:26] <seb128> no worry
[06:26] <pitti> if it can't catch up fast enough, we could temporarily disable testing on ARM
[06:26] <seb128> well, I don't think any of those is urgent, though they want to build beta images today
[06:26] <seb128> so unsure how much that can become an issue for that
[06:26] <seb128> Saviq, ^
[06:27] <Saviq> seb128, tx
[06:27] <seb128> yw
[06:27] <pitti> I also pinged infinity in #u-devel
[06:27] <seb128> pitti, thanks
[06:27] <pitti> so one KDE test takes roughly 30 to 60 mins
[06:28] <pitti> we can run 16 in parallel
[06:28] <pitti> so we are looking at roughly a day's worth of backlog
[06:28] <pitti> (some take much longer as they hang forever)
[06:43] <seb128> bah
[06:43] <seb128> so using the indicator-session to pick another user and login back to my user doesn't unlock the session since a few days here :-/
[06:44]  * pitti tries
[06:44] <seb128> and since yesterday unity displays the old compiz alt-tab switcher over the unity one
[06:44] <pitti> seb128: same here -- I type my pwd into lightdm, and then again into the screensaver
[06:44] <seb128> hikiko, andyrock, Trevinho, ^ known?
[06:44] <seb128> pitti, thanks for confirming :-)
[06:45] <seb128> pitti, could it be a logind issue? Trevinho said they were listening to the logind signal and that unity did change that code
[06:51] <pitti> seb128: it certainly could be, but if they changed that code they should know better about the details?
[06:51] <seb128> pitti, sorry, that was meant as "didn't"
[06:52] <seb128> it started before yesterday's unity update for me
[06:52] <seb128> was there any systemd change that might create issue? is that worth trying to downgrade that one?
[06:53] <pitti> seb128: last relevant change (225-1ubuntu1) was on Sept 5
[06:53] <seb128> hum, that's too old
[06:53] <seb128> though I didn't test switcher users much recently, especially when I was on holidays
[06:53] <seb128> so could be some weeks old
[06:54] <seb128> can I just downgrade logind without systemd?
[06:54] <pitti> seb128: no, it's the same binary package
[06:54] <seb128> k, no worry, let me try that
[06:56] <seb128> pitti, reported https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1498775
[06:57] <seb128> I'm going to try downgrade some of the components, but first eating something
[06:57] <pitti> seb128: oh, that breakfast thing -- high time indeed :)
[07:07] <hikiko> seb128, I have no idea why I am dist-upgrading
[07:07] <hikiko> and reinstall
[07:07] <hikiko> to see what you mean
[07:08] <hikiko> or you just compiled the new unity trunk?
[07:23] <larsu> oh wow no app menu on eog?
[07:26] <seb128> hikiko, no, I'm just using wily
[07:26] <seb128> larsu, right, that's the bug I mentioned the other day, we have a patch on Unity that disable it
[07:26] <seb128> Laney said it was to avoid the double "Eog Eog" in the unity panel
[07:26] <seb128> e.g title and menu having the same name
[07:26] <seb128> which was ok when we had the menubar
[07:26] <seb128> but we don't have it now...
[07:27] <seb128> hikiko, looks like I had the static application switcher plugin enabled in compiz, unsure why
[07:27] <larsu> seb128: I know I wrote this, but back then there was still a menu bar
[07:27] <larsu> now we have nothing
[07:27] <larsu> ah well I'm 50% into a fix anyway
[07:28] <seb128> great
[07:28] <seb128> larsu, yeah, which is why I pointed it, current situation means no way to access preferences
[07:28] <seb128> thanks for working on it
[07:28] <larsu> got it
[07:28] <larsu> yw!
[07:28] <hikiko> seb128, so, when you disable it it's ok?
[07:28]  * seb128 is offline for some minutes, playing downgrade game with systemd/lightdm/unity to found when that double lock screen started
[07:28] <seb128> hikiko, yes
[07:29] <hikiko> cool :)
[07:39] <pitti> qengho: FTR, chromium-browser's tests are still broken: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#chromium-browser
[07:41] <didrocks> pitti: I guess he was expecting that from yesterday's meeting: http://irclogs.ubuntu.com/2015/09/22/%23ubuntu-desktop.html#t15:51
[07:49] <pitti> didrocks: ah, thanks
[08:02] <Laney> yo
[08:05] <seb128> hey Laney, how are you?
[08:06] <larsu> morning Laney!
[08:06]  * larsu shaves yaks
[08:07] <didrocks> morning Laney
[08:09] <Laney> hi yak busters
[08:10] <Laney> we came last in the picture round but won the main pub quiz last night!
[08:10] <Laney> feelin' gooood
[08:10] <Laney> how are you all?
[08:10] <larsu> nice!
[08:10] <pitti> hey Laney!
[08:10] <larsu> congrats
[08:10] <pitti> Laney: congrats!
[08:11] <Laney> prize is 8 pints ;-)
[08:11] <Laney> hey pitti
[08:11] <pitti> Laney: I hope you didn't drink that all by yourself :)
[08:12] <Laney> saving it for next week
[08:12] <pitti> ah, you don't need to spend it right away?
[08:13] <Laney> its physical form is a voucher :)
[08:15] <seb128> Laney, pitti, didrocks, could anyone just have a glance to http://paste.ubuntu.com/12529579/ to see if it looks ok to them?
[08:16] <seb128> the configuration should have "[Seat:*]"
[08:16] <seb128> seems to work from a local test, just want a +1 before uploading
[08:16] <pitti> seb128: ah, it's literally ... that
[08:17] <pitti> seb128: LGTM
[08:17] <seb128> pitti, danke
[08:17]  * seb128 uploads
[08:19] <Laney> nice
[08:19] <Laney> I saw a bug yesterday about autologin not working, does it fix that?
[08:19] <Laney> what changed?
[08:19] <seb128> Laney, well it fixes the new install one
[08:20] <seb128> what changed you mean?
[08:20] <seb128> lightdm syntax changes in the wily cycle
[08:20] <seb128> it used to be [SeatDefaults]
[08:20] <seb128> and is [Seat:*] now
[08:20] <seb128> robert_ancell did http://launchpadlibrarian.net/214773980/user-setup_1.48ubuntu5_1.48ubuntu6.diff.gz
[08:20] <seb128> but he didn't escape correctly
[08:20] <seb128> so the grep and sed were failing
[08:20] <Laney> oh right
[08:20] <Laney> I just wondered by it became broken
[08:21] <seb128> k
[08:21] <seb128> that fixes installs
[08:21] <seb128> somebody mentioned upgraded systems to have issues
[08:21] <seb128> but I'm unsure if we have code doing config migration, to me it looks like lightdm has compat code for the old format
[08:21] <seb128> I emailed robert about that
[08:21] <Laney> cool
[08:22] <Laney> funny
[08:22] <Laney> I misread update_output as tellling me that glib wasn't installable
[08:22] <Laney> was going mad trying to reproduce it
[08:23] <Laney> "accepted: glib2.0"
[08:23]  * Laney fail
[08:23] <seb128> haha
[08:23] <pitti> lol
[08:23] <seb128> can we get the stable update for beta?!
[08:23] <pitti> Laney: yeah, I hinted it as chromium's tests are known broken
[08:23] <Laney> for tomorrow... doubt it
[08:24] <seb128> :-(
[08:24] <Laney> uploading that to sid this morning though
[08:24] <seb128> I can do the update now if you want
[08:24] <seb128> oh, ok
[08:24] <Laney> unless you want to do it there :-)
[08:24] <Laney> you can do _source uploads to debian now
[08:24] <seb128> well I can fake sync
[08:25] <seb128> right, but I'm not going to upload glib without runtime test it on a debian system
[08:25] <seb128> and I don't have one handy
[08:25] <Laney> pfft, testing, you old people
[08:25] <Laney> you're lucky that my changelogs parse correctly
[08:26] <seb128> :-)
[08:26] <seb128> that unity lock screen issue is getting annoying
[08:26] <pitti> I have an LXDE install
[08:26] <seb128> doesn't happen if I downgrade unity+systemd+lightdm
[08:27] <seb128> but downgraded only one of those is not enough to fix it
[08:27] <pitti> seb128: can you eliminate one of those by upgrading only one and it's still working?
[08:28] <seb128> trying that now
[08:32] <seb128> pitti, ok, upgraded back systemd bits and it's still working, you are off the hook ;-)
[08:33] <pitti> seb128: phew :)
[08:39] <seb128> k, seems the issue is due to lightdm...
[08:52] <seb128> seems like that update is what creates the unity lockscreen/greeter issue
[08:52] <seb128> http://launchpadlibrarian.net/218120238/lightdm_1.16.0-0ubuntu1_1.16.1-0ubuntu1.diff.gz
[08:52] <seb128> that change the pam config, unsure if unity doesn't like it
[08:52] <seb128> andyrock, ^
[08:56] <seb128> no andyrock today?
[08:57] <seb128> nor Trevinho?
[09:05] <willcooke> seb128, andyrock is probably at classes and Trevinho starts later/works later
[09:05] <willcooke> oh, also
[09:05] <willcooke> good morning
[09:05] <willcooke> I forgot today
[09:06] <seb128> hey willcooke :-)
[09:06] <seb128> k
[09:06] <seb128> sometime it's difficult to know when they are supposed to be online
[10:03] <Laney> andyrock: can you at least add a comment when you make a bug Opinion please?
[10:04] <Laney> talking about https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1158010
[10:05] <Laney> https://youtu.be/pWdd6_ZxX8c
[10:16] <larsu> perfect :D
[10:17] <larsu> (also good catch on that - I've never actually noticed that text)
[10:20] <Laney> 2013 Laney was observant
[10:21] <larsu> ya
[10:21] <larsu> I remember fighting hard against the introduction of that dialog
[10:34] <Laney> :(
[10:34] <Laney> the tide is powerful
[10:43] <Azufre> hi
[10:44] <Azufre> why i can not find the alternatives desktop of ubuntu in the official site?
[10:44] <Azufre> i just can download a Ubuntu with Unity but i don't find the Xubuntu or Lubuntu options
[10:47] <Laney> What do you want to do?
[10:47] <Laney> If you want to download a particular flavour then why not go via their website?
[10:48] <Azufre> but is not an official options from canonical the other dekstops?
[10:49] <Azufre> i need to install some ubuntu  for my grandpa laptop but he have a very old portable pc
[10:51] <Laney> Sure they are built by Canonical, but supported by the flavours themselves
[10:52] <Laney> so if you want try xubuntu: http://xubuntu.org/getxubuntu/
[10:52] <Azufre> ok thanks
[10:52] <Azufre> i don't understand why the are not listed on the 'mainpage' of ubuntu
[12:40]  * desrt yawns
[12:40] <desrt> acquired L7 last night at around midnight
[12:42]  * desrt can now self-deploy L5 portals
[12:42] <seb128> hey desrt
[12:42] <desrt> good morning :)
[12:42]  * didrocks wouldn't have bet desrt to play that long… congrats man!
[12:43] <seb128> you are addicted to this game ;-)
[12:43] <desrt> it's didrocks' fault
[12:43] <didrocks> what? I deny any responsability
[12:43] <didrocks> just showing up the basics :p
[12:43] <didrocks> to help a friend
[12:43] <desrt> didrocks: we're totally gonna play in london, right? :)
[12:43] <didrocks> desrt: it's been a year and half I didn't play it :p
[12:44] <desrt> best part of being L7 (and even more with L8): not constantly running out of R4 :)
[12:46] <didrocks> waow, there are so many portals now near my home
[12:46] <didrocks> insane, there is not at all the sense of "ownership"
[12:48] <desrt> didrocks: it's a different world these days
[12:49] <desrt> didrocks: we could use a good agent like you
[12:49] <didrocks> ahah :)
[14:06] <larsu> desrt: remember how we talked about window-specific gmenu sections once? I think we need this now.
[14:06] <larsu> desrt: gmenu ist just not very useful without (especially with the automatic resource stuf)
[14:07] <larsu> *stuff
[14:08]  * larsu proposes <section from="win.identifier" /> and gtk_application_window_add_menu_section (window, id, menu)
[14:28] <Laney> https://buildd.debian.org/status/fetch.php?pkg=glib2.0&arch=amd64&ver=2.46.0-1&stamp=1443009041 https://buildd.debian.org/status/fetch.php?pkg=glib2.0&arch=i386&ver=2.46.0-1&stamp=1443009390
[14:28] <Laney> what happened to break this test?
[14:29] <larsu> good question :/
[14:30] <Laney> it passes on other architectures
[14:34]  * Laney is running it in a loop
[14:39] <Laney> ._.
[14:41] <desrt> larsu: i agree with this.  someone needs to write a patch :)
[14:42] <desrt> larsu: also: figure out how the heck this works on dbus......
[14:42] <desrt>  /org/gnome/gedit/windows/1/identifier i guess
[14:42] <larsu> ya...
[14:42] <desrt> or maybe /org/gnome/gedit/windows/1/menus/identifier
[14:42] <larsu> I have no better idea either :/
[14:42] <desrt> i like that more
[14:42] <larsu> indeed, with "menus"
[14:43] <desrt> beyond that, the logic is _fairly_ simple
[14:43] <desrt> until you start thinking about how you'd make this work with the tracker
[14:43] <desrt> ie: how do you 'feed' it the correct external context?
[14:45] <desrt> we either need another GActionGroup-like abstraction (GMenuGroup anyone?) or some callback-based mechanism
[14:45] <desrt> or abuse the muxer
[14:45] <larsu> I was thinking callbacks
[14:45] <desrt> the muxer already deals in accels, so why not also menus?
[14:46] <larsu> the muxer already does too much
[14:46] <larsu> hm, indeed
[14:46] <desrt> it's sort of the logical place for it
[14:46] <desrt> since we expect menus to traverse the same hierarchy as actions
[14:46] <larsu> so the muxer would have set_menu_section() and get_menu_section() ?
[14:46] <desrt> just menu
[14:47] <larsu> yeah
[14:47] <desrt> it's sort of complicated, though
[14:47] <desrt> the namespacing is out of whack
[14:47] <desrt> the action group for the window is associated via "win"
[14:47] <desrt> but we would want this associated via "win.history" or whatever
[14:47] <desrt> which points to using GActionGroup itself as the mediator
[14:48] <larsu> how is this out of whack?
[14:48] <larsu> seems reasonable to me
[14:48] <desrt> muxer_set_menu_section() wouldn't work properly, i'm saying
[14:48] <seb128> hum
[14:48] <larsu> why not?
[14:48] <seb128> https://bugs.launchpad.net/bugs/1498945 claims that glib 2.45.7->8 makes evo ews not work
[14:48] <desrt> because the identifier would have to be "win.history"
[14:49] <desrt> which means that the things that attach "win" actions wouldn't necessarily have to be associated with "win"
[14:49] <desrt> which is very very odd
[14:49] <desrt> i think what we want to do is add a new interface on GActionGroup for get_menu()
[14:49] <larsu> no
[14:49] <desrt> for dbus action groups that would be implemented by appending "/menus/<identifier>" to the dbus path and requesting a dbusmenumodel
[14:50] <larsu> I still don't understand the problem. The muxer would be identified by "win" and hold a menu named "history"
[14:50] <desrt> muxers don't have prefixes
[14:50] <desrt> groups do
[14:50] <desrt> muxers are the repository for the root namespace...
[14:50] <desrt> this really really needs to be done as an extension to GActionGroup
[14:50] <larsu> ah indeed, they mux things
[14:50]  * larsu messed this up
[14:50] <desrt> which is _weird_ by the name
[14:51] <desrt> but really works sort of nicely when you think about it
[14:51] <larsu> I thought we had one for app and win, but we have *one*
[14:51] <desrt> well, we chain, right... ? :)
[14:51] <desrt> we actually _do_ have one for the app and win
[14:51] <larsu> yeah but at the top level we have one
[14:51] <desrt> but they are not named like that
[14:51] <desrt> so ya.. it's all very simple
[14:52] <desrt> GActionGroup grows new _get_menu() method
[14:52] <larsu> the benifit of having it in gactiongroup is that we wouldn't have to touch so many things
[14:52] <desrt> GSimpleActionGroup implements it with a hashtable and setters
[14:52] <larsu> but actions and menus were nicely separated before :/
[14:52] <desrt> we expose that in the GtkWidget tree in the usual way, plus on GtkApplication and GtkApplicationWindow
[14:52] <desrt> GDBusActionGroup implements it by getting a GDBusMenuModel at the appropriate subpath
[14:52] <desrt> and for exporting we ... do something
[14:52] <desrt> but think about the reason for the separation
[14:53] <desrt> note also that we have gtk_application_get_menu_by_id()
[14:54] <larsu> what's with that?
[14:54] <larsu> that's separate, no?
[14:54] <desrt> it's the resources thing
[14:54] <larsu> I know
[14:54] <desrt> useful for forming gear menus and the like
[14:54] <larsu> ish
[14:54] <larsu> for example: eog pulls out the resources itself when constructing a window
[14:54] <desrt> well, in the beautiful future we can just have a menu-name property on GtkMenuButton and have it mine it out of the muxer
[14:54] <larsu> so they have a new copy of the menu model
[14:54] <larsu> so they can just not care about the window-specific menus
[14:54] <desrt> ya.  gedit used to do it this way too
[14:55] <larsu> and simply insert them
[14:55] <desrt> then they fixed their code ;)
[14:55] <larsu> well
[14:55] <larsu> you can't really have window-specific dynamic menus with this
[14:55] <desrt> (i know it doesn't work for eog this way now, but this is what we are discussing)
[14:55] <larsu> I know, I'm fixing it
[14:55] <larsu> but I can't fix it properly until we have this
[14:55] <desrt> the only tricky bit is making sure the app and the window export the menus properly
[14:56] <desrt> and here's the fun part:
[14:56] <larsu> and when do you switch the dynamic sections?
[14:56] <desrt> do we add _list_menus() on GActionGroup interface
[14:56] <desrt> ?
[14:56] <larsu> we don't export a menu per window
[14:56] <desrt> if we do that, then we could make the action group exporter take care of the menu exporting automatically
[14:56] <desrt> which has a nice symmetry with the automatic handling on the other side
[14:57] <desrt> but it means that we need changed signals and _probably_ also need, then, to export this list on dbus as well
[14:57] <desrt> (with change signals there, too)
[14:58] <larsu> yeah we should do that
[14:58] <desrt> so this is worrying now
[14:58] <larsu> everything else would feel hacky I presume
[14:58] <desrt> because either we're going to spam the bus with menus nobody cares about or we need to adjust the GActionGroup dbus protocol (which is something i've wanted to do for a while anyway)
[14:59] <larsu> to be like the menu one? subscribing and all?
[14:59] <desrt> yes
[14:59] <desrt> this model is very nice
[14:59] <larsu> this is turning out to be a very big yak
[14:59] <desrt> at least until our magical explicit-subscription beautiful kdbus future
[14:59] <desrt> it is!
[14:59] <desrt> this is why it wasn't done yet :)
[14:59] <larsu> desrt: tell me how to implement this now
[14:59] <desrt> do you want to shave the whole yak?
[14:59] <larsu> yes
[14:59] <desrt> because you kinda need to...
[14:59] <desrt> can it wait until london?
[15:00] <desrt> we could take a day or two on this together
[15:00] <larsu> it's impossible to even do now
[15:00] <larsu> eog has a open with menu per window
[15:00] <larsu> which is in a popover (so might stay open)
[15:00] <larsu> so I can't just switch the application_get_menu_by_id() section around
[15:00]  * larsu hates this
[15:01]  * desrt shrugs
[15:01] <larsu> desrt: yes, it can. We need this for 15.10, but not with all the changes (I'm already preparing a much smaller patch)
[15:01] <desrt> okay
[15:01] <desrt> let's allocate a day or two in london to this
[15:01] <larsu> desrt: don't shrug. This is the biggest shortcoming of gmenumodel, because *every* app needs this
[15:01] <desrt> i think we covered all of the important bits in this discussion
[15:01] <larsu> ya, could do
[15:01] <desrt> i'll start thinking about the new dbus protocol
[15:01] <larsu> I think I'll start hacking on it before to see how it feels
[15:02] <larsu> yeah I might not get into that yet
[15:02] <desrt> something else i want to scratch off at the same time is the 'in transition' thing mclasen was asking about
[15:02] <desrt> maybe also per-target enabled states
[15:02] <larsu> ui elements?
[15:02] <desrt> like prelighting in switches
[15:02] <desrt> for turning on bluetooth or whatever
[15:03] <larsu> yes we should fix that
[15:03] <larsu> it's a pain
[15:03] <larsu> especially with switches
[15:03] <larsu> because they have such a weird quasi-model api
[15:03] <larsu> if you mix that with actions, you almost always get it wrong
[15:04] <desrt> and the other todo: the per-target enable/disable business
[15:04] <larsu> what do we need that for?
[15:04] <desrt> for simple enum/flags-type actions this makes sense, even if we can't possibly hope to do it in the general sense
[15:05] <desrt> like if we have a radiobutton group for connect using: bluetooth/wired/wifi/magic
[15:05] <larsu> ah, indeed
[15:05] <desrt> with detailed actions connectwith::bluetooth, etc.
[15:05] <larsu> desrt: gotta run real quick to pick up a ... package
[15:05] <desrt> and we want to disable only "magic" because there is no magic, but leave the others enabled
[15:05] <larsu> let's do this in London
[15:05] <desrt> good luck :)
[15:05] <desrt> yup
[15:05] <larsu> thanks :)
[15:06]  * larsu liked the magic example
[15:12] <pitti> infinity, jdstrand: FYI, re-enabling armhf in britney; queue is down to 8
[15:12] <pitti> err, that was supposed to go into #u-devel
[15:21] <flexiondotorg> seb128, I've respun the Ubuntu MATE isos so they now include user-setup 1.48ubuntu7
[15:22] <flexiondotorg> But this issue is still present - https://bugs.launchpad.net/ubuntu/+source/user-setup/+bug/1498544
[15:22] <seb128> flexiondotorg, patches are welcome
[15:24] <seb128> flexiondotorg, said differently, I've no idea why the fix is not working, I fixed an issue I saw with the shell code and it worked copied in a local script, I'm unsure how to test user-setup
[15:24] <seb128> so somebody who understands that better is going to need to do it
[15:37] <flexiondotorg> seb128, OK, I'll take a look.
[15:37] <seb128> flexiondotorg, thanks
[15:38] <seb128> flexiondotorg, it might be that somebody needs to import the updated user-setup in ubiquity
[15:38] <seb128> unsure how that works but I saw ubiquity changelog mentioning such imports
[15:38] <seb128> cyphermox probably knows if that's needed
[15:39] <cyphermox> yes, that's exactly it
[15:39] <cyphermox> I can update ubiquity now
[15:39] <seb128> cyphermox, thanks
[15:39] <seb128> flexiondotorg, ^
[15:40] <flexiondotorg> seb128, cyphermox Thanks.
[15:40] <flexiondotorg> cyphermox, Anything I can do to help?
[15:43] <seb128> still no Trevinho or andyrock?
[15:43] <larsu> seb128: haven't seen them all day
[15:43] <Trevinho> seb128: I'm here, did I miss any ping?
[15:43] <seb128> yeah, same here
[15:43] <larsu> oh hi Trevinho :)
[15:43] <seb128> Trevinho, yes, you did, several this morning
[15:43] <Trevinho> seb128: I was in the call :)
[15:43] <seb128> Trevinho, should watch this channel :-/
[15:43] <Trevinho> Ouch... /me reads backlog
[15:44] <larsu> Trevinho: did you file that bug we talked about yesterday (argb windows for csd)? I'd like to subscribe myself
[15:44] <seb128> Trevinho, I tracked down bug #1498775 to the lightdm change to support "audit"
[15:44] <seb128> Trevinho, unsure why, do you know if unity would need to catch up with pam config changes from lightdm or something?
[15:44] <seb128> Trevinho, I guess it's more one for andyrock though?
[15:45] <Trevinho> seb128: yeah, he's more on that...
[15:45] <Trevinho> seb128: did lightdm changed anything on PAM?
[15:45] <seb128> yes
[15:45] <seb128> Trevinho, http://launchpadlibrarian.net/218120238/lightdm_1.16.0-0ubuntu1_1.16.1-0ubuntu1.diff.gz
[15:45] <seb128> is the diff of that update
[15:45] <seb128> +session required        pam_loginuid.so
[15:46] <seb128> though you said you were listening to logind
[15:46] <Trevinho> seb128: adding that to the unity.pam file fixes the issue?
[15:46] <Trevinho> pam_loginuid.so
[15:46] <seb128> so unsure why that has an impact
[15:46] <Trevinho> seb128:  it might, but not sure what that module does
[15:47] <seb128> maybe we should ask tyhicks
[15:47] <seb128> he did the lightdm change
[15:49] <tyhicks> seb128: I don't see how the modified pam config would cause that bug
[15:50] <seb128> tyhicks, I don't know what cause it, but that lightdm change is what creates the double unlock issue
[15:50] <seb128> I downgraded/upgraded lightdm several times and confirmed
[15:50] <tyhicks> hrm
[15:51] <Trevinho> seb128: have you tried to hack your unity.pam also?
[15:51] <seb128> Trevinho, no, I don't understand pam enough to do that
[15:53] <Trevinho> seb128: mh ok, I also don't think unity needs it...
[15:55] <tyhicks> I'm trying some ideas
[15:55] <seb128> tyhicks, thanks
[16:00] <tyhicks> seb128: if you enter your password a second time, does it log you in?
[16:00] <tyhicks> (it does here... just wanting to verify that's the case with you too)
[16:01] <seb128> tyhicks, yes
[16:01] <seb128> it's just that it's supposed to unblock directly and not ask again
[16:02] <tyhicks> seb128: there should be no password prompt at all?
[16:04] <seb128> tyhicks, the greeter should unlock the session
[16:04] <seb128> Trevinho mentioned that unity listens to some logind signal for that
[16:04] <Trevinho> Yeah, let me be more precise
[16:05] <tyhicks> seb128: but should you have to enter the password to return back to the original session?
[16:05] <seb128> tyhicks, yes, on the unity-greeter
[16:05] <tyhicks> ok
[16:06] <Trevinho> So, we connect to org.freedesktop.login1.Session.Lock/Unlock signals
[16:06] <Trevinho> seb128: can you verify wether the unlocked signal is emitted for you?
[16:07] <seb128> Trevinho, sorry in an hangout then I need to go for sport, but can try tomorrow morning
[16:07] <Trevinho> seb128: ok, that's fine... I can check that as well
[16:08] <Trevinho> seb128: as for the switcher, was just a configuration mess I guess
[16:08] <seb128> seems so
[16:08] <seb128> it might be due to me
[16:08] <seb128> I played with cairo-dock yesterday trying to see if the unity-control-center icon changed when changing panels
[16:11] <Trevinho> ah, i see
[16:11] <Trevinho> larsu: as back to your thing... I didn't open any bug yet
[16:12] <Trevinho> I mean for the argb
[16:13] <Trevinho> larsu: so there were two things discussing, and they mixed up, so the other thing was related to the double eog/eog panel/deco entry, right?
[16:30] <tyhicks> Trevinho: looks like it has to do with the pam changes :/
[16:30] <tyhicks> Trevinho: I'll have to find some time to dig into it some more later today
[16:30] <Trevinho> hm, tyhicks what that model does?
[16:32] <seb128> tyhicks, can you comment on the bug? just to avoid that robert_ancell or others dup work not knowing somebody started looking
[16:38] <larsu> Trevinho: that's different and I'm fixing that (by putting a traditional menu on eog)
[16:39] <Trevinho> larsu: I see, although maybe that could be fixed for every app.. By checking whether the win name matches the menu, and update accordingly for example...
[16:40] <Trevinho> larsu: for the ARGB thing, instead, I've checked, but unity doesn't do anything special for those windows (a part from not adding decorations), so I guess that gtk should react differently in our scenario
[16:44] <larsu> Trevinho: hm? Last time I checked unity didn't draw shadows
[16:44] <larsu> and you said this is hard, because the windows are not rectangular
[16:45] <Trevinho> larsu: ah, yeah... right... I had saved a change, let me retry it
[16:45] <larsu> thanks :)
[16:45] <Trevinho> larsu: I was thinking you were speaking of the corners not being transparent
[16:45] <larsu> I am
[16:45] <larsu> they're not because it's disabled in gtk
[16:45] <larsu> and I'm going to enable it as soon as unity can deal with it
[16:46] <larsu> the check is in gtkwindow.c pretty obvious if you want to try
[16:46] <Trevinho> what would be the change in gtk? Enabling argb or what?
[16:46] <Trevinho> yeah, ok
[16:46] <larsu> yes
[16:46] <larsu> it's just an if
[16:48] <Trevinho> k... adding to my list
[17:04] <Laney> bye!
[17:04] <larsu> Laney: good night!
[18:00] <willcooke> g'night
[18:02] <andyrock> hey
[18:02] <andyrock> Trevinho: no putting +session required        pam_loginuid.so
[18:02] <andyrock> in unity.pam
[18:02] <andyrock> does not make sense
[18:02] <Trevinho> andyrock: yeah, in fact it was my guess
[18:03] <andyrock> seb128: does reverting lightdm fix the issue?
[18:04] <andyrock> also we had some changes in unity that could cause this issue
[19:32] <Trevinho> andyrock: it seems so
[19:32] <Trevinho> andyrock: check with tyhicks also
[19:36] <tyhicks> Trevinho: reverting the lightdm pam changes, even while keeping the lightdm code changes, results in the expected behavior
[19:43] <andyrock> tyhicks: any idea how why this is happening?
[19:43] <andyrock> have you tried to check if the logind signal is emitted?
[19:44] <tyhicks> andyrock: I haven't had a chance to look into it yet
[19:44] <tyhicks> andyrock: I haven't investigated whether logind is emitting a signal
[19:45] <tyhicks> andyrock: the pam_loginuid module simply writes the uid to /proc/self/loginuid
[19:46] <tyhicks> andyrock: I'm guessing that affects logind in some way
[19:48] <andyrock> well let me know if you need help investigating the issue
[19:49] <andyrock> tyhicks: at least for the unity side
[19:51] <tyhicks> andyrock: thanks! I hope to get to it soon
[20:19] <qengho> good night!
[20:26] <ochosi> Sweet5hark: still enjoying libocon i presume? :)
[20:27] <Sweet5hark> ochosi: umm, yes. fratically generating slideware ...
[20:27] <ochosi> :>
[20:28] <ochosi> good luck then!
[20:41] <desrt> so uh... gonna go out and meet with a couple of friends
[20:41] <desrt> goodnight everybody!
[20:42]  * desrt will probably be around later in the evening a bit
[21:05] <robert_ancell> hi all
[21:29] <attente> bye, bbl
[22:39] <TheMuso> Morning folks.
[23:48] <TheMuso> Back in a bit, gotta run some errands.