[00:13] <jbicha> robert_ancell: so LP: #1707352 is still frustrating, people say they can now install third-party scanner libs but the libs don't always work now
[00:13] <jbicha> we added a versioned provides which fixed the installability issue
[00:46] <robert_ancell> jbicha: did they change the internals of sane much? It's a fairly simple API, I would have thought it would be fairly hard to break.
[00:49] <jbicha> I don't know what's going on
[01:20] <duflu> jbicha, I have no context other than that one message :)
[01:21] <jbicha> so 2 of us don't know what's going on :)
[01:21] <duflu> \o/\o/
[01:22] <jbicha> I don't know what's going on LP: #1707352, we added the versioned provides which fixed the installability problem but the 3rd party libs seem to still not work
[02:24] <jamesh> robert_ancell: what do you think of moving gnome-software's macaroon code to log in to snapd directly rather than using snapd-login-service?
[02:25] <robert_ancell> jamesh: as in making snapd responsible for storing it?
[02:25] <jamesh> I know that this code path won't be hit for most new users, but seems necessary to handle the password change bug
[02:25] <jamesh> robert_ancell: no.  Just have gnome-software call /v2/login rather than asking snapd-login-service to do so
[02:26] <robert_ancell> jamesh: oh, we should definitely kill snapd-login-service if snapd is capable of us talking to it directly (i.e. using Polkit)
[02:26] <robert_ancell> s-l-s only exists as a workaround
[02:27] <jamesh> robert_ancell: at the moment, if you provided U1 credentials to gnome-software and then change your U1 password, things will break some time later when snapd tries to refresh the store macaroon
[02:28] <robert_ancell> jamesh: shouldn't snapd just return an appropriate error code for g-s to trigger re-entering the credentials?
[02:29] <jamesh> I've fixed up things snapd side so it sends a proper Unauthorized response when this happens, but I think on the gnome-software side the correct action is to call /v2/login with the existing snapd macaroon
[02:30] <jamesh> which I don't think we can do through snapd-login-service
[02:30] <robert_ancell> oh, I see. Yeah, that would be a pain to try and get through D-Bus.
[02:30] <robert_ancell> jamesh: if we just put a Polkit action on /v2/login we can call it directly, right?
[02:31] <jamesh> if we call login without a macaroon, we end up collecting dead logins inside snapd
[02:31] <robert_ancell> jamesh: oh interesting. I think snapd-glib explicitly doesn't send the old macaroon when you do another login anyway
[02:31] <robert_ancell> I had assumed it wasn't useful anymore...
[02:31] <jamesh> robert_ancell: there's already a polkit action on that endpoint: it was the first one I added
[02:31]  * robert_ancell thinks Macaroons have sure made life easier :)
[02:32] <robert_ancell> jamesh: done then - let's just change g-s to stop using s-l-s
[02:32] <robert_ancell> I'll deprecate those functions in snapd-glib
[02:33] <jamesh> robert_ancell: to be honest I don't know if it is important or not.  If you look in /var/lib/snapd/state.json you can see where it stores info about each login
[02:33] <robert_ancell> jamesh: what is the state of polkit support in snapd now? Did we resolve the Polkit config issue? Which Ubuntu releases (if any) does it work on now?
[02:34] <jamesh> robert_ancell: one thing I'm concerned about is what happens when snapd does its automatic refresh: if I've got 10 non-functional uids registered, does it try to use them to talk to the store?
[02:34] <robert_ancell> ¯\_(ツ)_/¯
[02:35] <jamesh> robert_ancell: looking at https://launchpad.net/ubuntu/+source/snapd, 2.28.5 is everywhere
[02:35] <jamesh> well, proposed for xenial and trusty
[02:35] <robert_ancell> and that ships the polkit config?
[02:35] <jamesh> but effectively everywhere
[02:35] <jamesh> yes
[02:36] <jamesh> it was only necessary to copy the polkit action file when using snapd from the core snap while the deb packaged version was older
[02:37] <robert_ancell> jamesh: right. I just wasn't sure if the core snap version was considered "done" and when the .deb version would exist
[02:38] <robert_ancell> jamesh: there must be a bug in snapd if it accumulates broken macaroons / uids - even if we make g-s a well behaved client it should handle broken clients
[02:38] <jamesh> robert_ancell: using "Depends: snapd (>= 2.28)" should be sufficient
[02:38] <robert_ancell> yeah
[02:39] <jamesh> robert_ancell: if you run "snap login", snapd has no way to know if you throw away the macaroon.
[02:39] <robert_ancell> jamesh: doesn't it use the macaroon stored in the home dir?
[02:42] <jamesh> robert_ancell: the "snap" client reads the macaroon from your home directory.  "snapd" doesn't know about it
[02:42] <jamesh> so if I delete ~/.snap/auth.json and log in again, snapd has no way to know that the previous login uid is inaccessible
[02:43] <jamesh> there is no sensible way to garbage collect it
[02:44] <robert_ancell> jamesh: by "snap login" you mean the command line client right? Doesn't it read ~/.snap/auth.json?
[02:45] <jamesh> robert_ancell: well, it can be pretty much any snapd client
[02:46] <jamesh> robert_ancell: if I log in via gnome-software and again via the command line client, there is no linkage between the two issued macaroons
[02:46] <robert_ancell> yes
[02:46] <jamesh> and any login which hasn't been matched with an equivalent call to logout is potentially in use
[02:48] <jbicha> by the way, I'm working on getting snapd-glib into Debian https://ftp-master.debian.org/new/snapd-glib_1.24-1.html
[02:49] <jamesh> jbicha: awesome!
[02:50] <robert_ancell> yay!
[02:51] <robert_ancell> "Ayatana Packagers" - does that still exist?
[02:51] <jbicha> sunweaver has repurposed it for packaging his indicator stuff
[02:52] <jamesh> so it's basically "stuff from ubuntu" now?
[02:52] <jbicha> if not for that, the team would have been pretty much gone by now
[02:52] <jbicha> https://qa.debian.org/developer.php?email=pkg-ayatana-devel%40lists.alioth.debian.org
[02:53] <jbicha> jamesh: I guess, I couldn't think of a better team for the pkg and I really prefer team maintenance
[02:54] <jamesh> jbicha: fair enough
[02:54] <jbicha> also with alioth being decomissioned soon, it's difficult to start a new team now (hard to get a Debian mailing list)
[02:55] <robert_ancell> jbicha: alioth is going to be decomissioned! That's great! :)
[02:55] <jamesh> if https://tracker.debian.org/pkg/snapd had a team as maintainer, it probably would have fit better there
[02:55] <jamesh> jbicha: are they going to set up their own instance of Launchpad?
[02:55] <jbicha> jamesh: no, something like gitlab.gnome.org
[02:55] <jamesh> :)
[02:56] <robert_ancell> jamesh: https://git.gnome.org/browse/gnome-software/commit/?id=db1eceb912572fe2fe832372148e437632d7973d
[02:57] <robert_ancell> jamesh: let me know if that works well and we can backport it
[02:57] <robert_ancell> It will still hit the weirdness if you had 2.28 from core but <2.28 in the .deb, but we really can't detect that :/
[02:59] <jamesh> robert_ancell: it should be fine.  For Ubuntu releases, I doubt gnome-software will get out of proposed before snapd (and we could ensure that with a versioned dependency in the control file)
[03:11] <RAOF> robert_ancell: Hey, are you still vaguely interested in backing GTK4 onto Mir?
[03:12] <RAOF> robert_ancell: Because Gerry, Alan, and I will be discussing that sort of thing tomorrow evening, and you're welcome to attend (at the friendly time of 22:30 UTC+13) or I can proxy stuff for you.
[03:14] <robert_ancell> RAOF: it would be in the category of vaguely interested but too far down my priority list, so I'm interested to hear what's happening.
[03:14] <robert_ancell> Won't be at that meeting though :)
[03:14] <RAOF> Have you had any further thoughts on what would be involved?
[03:15] <RAOF> One of us would probably be able to do it, but it'd be nice to be mentored by someone with actual experience :)
[03:15] <robert_ancell> RAOF: I think the backend stuff has changed a lot with GTK4, so not sure if I'd be much help there. It was fairly hard to do in GTK3, probably a lot easier now
[03:16] <jbicha> by the way, the latest gtk4 is in Debian svn, I didn't upload to Debian's NEW queue yet because the soname numbering is odd
[03:16] <jbicha> they are still dropping symbols from gtk4 and I'm unaware of any apps using gtk4
[03:17] <jbicha> I'm thinking we might remove gtk4 from Ubuntu for the 18.04 LTS release because it will be more confusing than helpful, given how gtk4 development is going
[03:18] <robert_ancell> RAOF: looks like the Mir backend has been getting some changes due to the refactoring. Don't know if it still works though.
[03:19] <robert_ancell> RAOF: oh hang on, are you referring to making a GTK+/Mir compositor?
[03:19] <RAOF> robert_ancell: Hopefully we won't have to care 😅
[03:19] <RAOF> robert_ancell: Yes!
[03:20] <RAOF> That bit. Not Mir clients; writing Mir shells with GTK+
[03:20] <robert_ancell> Ah, right! I still have no idea at all, but it sounds like a cool idea.
[03:20] <robert_ancell> Totally happy to hack around with you on it.
[03:22] <robert_ancell> RAOF: how did the Qt compositor work, did it open a Mir connection to itself and otherwise act like a client?
[03:23] <RAOF> No; it plumbed stuff right into the Qt event loop and stuff.
[03:23] <RAOF> And the Qt scene graph.
[03:24] <robert_ancell> So that must essentially be a special backend for Qt. I guess for GTK+ we'd have to write a special mir-compositor backend
[03:24] <RAOF> QtMir implemented the various policy interfaces exposed by libmirserver.
[03:24] <jamesh> there was QtMir and QtUbuntu
[03:25] <RAOF> QtMir was the compositor-side one; QtUbuntu was the Qt-as-a-Mir-client one.
[03:25] <robert_ancell> yeah
[03:25] <RAOF> Yeah, you'd need a special compositor backend. Because (for example) you'd want to have the client windows in your scenegraph, and those are only available in-process.
[03:26] <robert_ancell> The backends seem to be hidden from the GTK+ client. So we might need to lobby for some API gtk_get_backend() that would allow us to get the backend object.
[03:26] <RAOF> And you might want a way to send GTK events to the clients and such.
[03:26] <RAOF> Hm.
[03:26] <robert_ancell> I guess we need a MVP and then work out what does and doesn't work and then work out what needs to be done to make it work.
[03:27] <RAOF> Yeah. Maybe you'd actually want a gtk_init_with_backend(), because your shell can only sensibly use that backend anyway...
[03:27] <RAOF> But something of that kidney.
[03:28]  * RAOF will need to investigate the GTK4 scenegraph API, and see whether it makes sense for things to appear in it without the application specifically putting them there.
[03:28] <robert_ancell> RAOF: There just seems to be a backend filter API. It would be a lot cleaner with what you suggested.
[03:29] <robert_ancell> I suspect the short answer is going to be "this is not really do-able", but we could work on some APIs to make it possible.
[03:29] <robert_ancell> And having them in GTK+4 earlier rather than later is going to be useful.
[03:29] <RAOF> And now would be the time to do them, while GTK4 is in flux.
[03:29] <RAOF> Ding!
[03:30] <robert_ancell> Working on some of those APIs and working with upstream sounds right up my alley. I've been keen to find something to work on in GTK+.
[03:34] <RAOF> Yay!
[03:35] <RAOF> So, I'll tell Alan and Gerry that you're going to come back with a GTK4 compositor backend in a couple of months :)
[03:35] <robert_ancell> ah......
[03:36] <RAOF> Or, at least, that you're going to look into the GTK4 API and see how such a backend would look?
[03:37] <robert_ancell> I'm interested, but I wouldn't rely on me to do it unless it was a business priority...
[03:45] <RAOF> gdk_display_beep() 🙄
[03:45] <robert_ancell> That still exists? ;)
[03:47] <RAOF> Not even deprecated :)
[03:50] <RAOF> So, from a cursory look...
[03:50] <RAOF> ...we'd need to implement a GdkDisplay and a GskRenderer backed onto the Mir server API.
[05:28] <jbicha> duflu: so, I was looking at http://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.svg
[05:29] <jbicha> and intel-vaapi-driver used to be in main, I guess briefly though
[05:29] <jbicha> https://launchpad.net/ubuntu/+source/intel-vaapi-driver/+publishinghistory
[05:30] <duflu> jbicha, interesting but no biggy. We were being cautious rather than acting on specific legal advice (AFAIK)
[05:33] <jbicha> oh ok, I don't know anything about all that
[07:32] <oSoMoN> good morning desktoppers
[08:31] <fdfghhjfgfzsdffg> Hello, When will the dailybuild of Bionic be published ??
[08:53] <willcooke> morning all
[08:57] <oSoMoN> good morning willcooke
[08:59] <willcooke> Hi oSoMoN, good weekend?
[09:00] <seb128> hey willcooke oSoMoN
[09:00] <seb128> good morning desktopers
[09:00] <willcooke> howdy seb128
[09:02] <duflu> Morning oSoMoN, willcooke, seb128
[09:02] <willcooke> afternoon duflu
[09:02] <seb128> hey duflu
[09:03] <oSoMoN> willcooke, yeah, a good one, stayed at home and did some gardening, diy and played lego with my daughter
[09:03] <willcooke> \o/
[09:03] <oSoMoN> you?
[09:03] <oSoMoN> salut seb128, hey duflu
[09:04] <willcooke> Played in a golf competition on Saturday (my team won!) and then emptied the garage so that the builders can start converting it in to a new office for me
[09:04] <willcooke> Scaffolding is going up today
[09:04] <oSoMoN> nice
[09:12] <duflu> Gah, 5:12pm and still getting through email
[09:12] <seb128> duflu, launchpad incoming bugreports triaging?
[09:13] <duflu> seb128, yeah
[09:13] <duflu> also gnome bugzilla
[09:14] <seb128> duflu, I would recommend you skip on some/do less, I've been there, on busy time you could spend you full week triaging but that doesn't help much since then you don't have any slot to work on issues
[09:15] <duflu> seb128, it's fine. Used to be worse with Compiz (this happened all year round, not just release months). And I have a sufficiently fair scheduling algorithm
[09:15] <seb128> ok :)
[09:16] <duflu> seb128, one of the tricks is to *close* email around this time of day :)
[09:19] <seb128> sounds like a good idea
[09:20] <seb128> I don't think how you do it, I got bored of going through reports after half a day usually
[09:22] <duflu> Never said it was fun :)
[09:25] <fdfghhjfgfzsdffg> Hello
[09:25] <fdfghhjfgfzsdffg> When will I publish Bionic dailybuild iso?
[09:26] <duflu> fdfghhjfgfzsdffg, great question. I would like to know myself
[09:27] <fdfghhjfgfzsdffg> http://cdimage.ubuntu.com/daily-live/
[09:27] <duflu> Yeah we know. It's still artful
[09:27] <fdfghhjfgfzsdffg> the most recent is from October 19th
[10:03] <oSoMoN> seb128, are you planning on pushing my libreoffice 5.4.2 packages to the artful queue today?
[10:04] <seb128> oSoMoN, oh yeah, sorry that I didn't manage to get to it on friday
[10:05] <oSoMoN> seb128, no worries, I don't think it would have moved much during the week-end anyway
[10:45] <ricotz> chrisccoulson, hi, a simple retry should worked for me -- https://launchpad.net/~ubuntu-mozilla-security/+archive/ubuntu/rust-updates/+build/13624981
[12:36] <oSoMoN> chrisccoulson, chromium-browser 62.0.3202.75 is ready for publication in https://launchpad.net/~canonical-chromium-builds/+archive/ubuntu/stage/+packages
[13:00] <jbicha> I got into an edit war over https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/1721315/+activity
[13:07] <jbicha> seb128: could you hint remmina-plugin-spice to universe to see if that's enough for new remmina to migrate to bionic?
[13:14] <jbicha> oh I guess duflu gave in and let the other duplicate bug win, probably a good idea
[13:27] <kenvandine> The "welcome 17.10 users" banner is now up on gnome.org
[13:41] <willcooke> kenvandine, nice one!
[13:42] <willcooke> kenvandine, would you share that on the socials?
[13:42] <kenvandine> sure
[13:47] <jbicha> seb128: or anyone: you triaged LP: #1700319 as high, are you able to fill in the test case so the bug number can be mentioned in the gtk 3.22.25 SRU I'm working on?
[13:50] <seb128> jbicha, k
[13:50] <seb128> jbicha, unsure what's the issue with remmina? did somebody new a binary to main wrongly?
[13:52] <jbicha> there's a new version of remmina and it adds a new binary: remmina-plugin-spice which depends on the universe spice-gtk libraries
[13:52] <jbicha> I guess new binaries for main packages go to main by default?
[13:53] <seb128> not in the web ui iirc, but maybe some archive admin just send them in main because that's where they most likely need to be
[13:54] <jbicha> it shows up on the bionic update_excuses page
[13:54] <kenvandine> willcooke, done
[13:56] <willcooke> thx kenvandine
[13:57] <jbicha> also, I guess the desktop-bugs team should be subscribed to freerdp2 (someone promoted it to main already)
[14:31] <a1fa> i got an issue with 17.10 - laptop waking up from suspend w/o prompting for password
[14:31] <a1fa> it's a rando thing.. most of the time it requires password
[14:31] <a1fa> i think it has to do something with chrome, and one of the tabs
[14:31] <a1fa> with audio
[14:32] <seb128> a1fa, what makes you believe that's the case?
[14:34] <a1fa> i think that's the only time i've seen this issue, if chrome was left running and lid was closed
[14:35] <a1fa> suspend action should lock first, then suspend
[14:36] <a1fa> to prevent this from happening
[14:37] <seb128> you should open a bug against gnome-shell with your syslog from just after getting the issue
[15:51] <andyrock> seb128, willcooke the fix for that OEM bug has been committed in master too
[15:51] <andyrock> seb128: let me know if I need to do something more for the SRU
[15:58] <seb128> andyrock, \o/
[15:58] <seb128> andyrock, no, it's all good, thanks again for the work on that
[16:11] <jbicha> jackpot51: good morning, GNOME 3.26.2 updates are this week so I think I'm going to ask that the unapproved mutter SRU for artful be rejeted so we'll just upload mutter 3.26.2 in a few days
[16:16] <jbicha> andyrock: similarly, is it ok if I can for our gtk3 unapproved sru to be rejected and we'll do LP: #1728421 instead soon?
[16:16] <jbicha> *can ask
[16:17] <andyrock> jbicha: ok for me
[16:35] <oSoMoN> kenvandine, hey, in a clean artful VM I'm still seeing the theme issue with the LO candidate snap, but on my desktop I'm not, any idea what could make a difference?
[16:35] <oSoMoN> in both setups the gsettings interface is connected
[16:36] <kenvandine> oSoMoN, no... that's very weird
[16:36] <kenvandine> oSoMoN, both on wayland?
[16:36] <kenvandine> shouldn't matter
[16:38] <oSoMoN> yes, both on wayland
[16:38] <oSoMoN> not seeing any relevant apparmor denials either
[16:39] <kenvandine> oSoMoN, how about UID?  are they both UID 1000?
[16:39] <kenvandine> as in first user created?
[16:42] <oSoMoN> let me check
[16:42] <kenvandine> oSoMoN, i recall seeing a problem like that and i think it was with the second user created on the system
[16:42] <kenvandine> multiple logins
[16:43] <kenvandine> but at the time i thought the problem was unrelated... and i trashed the VM
[16:44] <oSoMoN> yes, single user machines anyway, and both have UID 1000
[16:44] <kenvandine> ok
[16:44] <kenvandine> good
[16:51] <kenvandine> oSoMoN, i'm installing it on both of my artful systems
[16:52] <oSoMoN> reinstalling on my desktop as I realized it was not the version from the candidate channel (although supposedly the same snap)
[16:54] <oSoMoN> still getting the ambiance theming on my desktop with the snap from candidate
[16:56] <kenvandine> oSoMoN, failed to install from the candidate channel on my desktop
[16:56] <kenvandine> invalid exec command
[16:56] <kenvandine> still downloading on my laptop
[16:58] <kenvandine> oSoMoN, same on my laptop
[16:58] <kenvandine> revision 37
[16:58] <kenvandine> oSoMoN, i'm running core from beta
[16:58] <oSoMoN> kenvandine, I'm on stable
[16:58] <kenvandine> and edge on the other
[17:00]  * kenvandine tries again with stable
[17:00] <oSoMoN> aha, if I move ~/.config/dconf/user on my desktop, then the libreoffice snap gets the wrong theme
[17:00] <kenvandine> ugh
[17:01] <kenvandine> that's not good!
[17:01] <oSoMoN> and sure enough if I restore it the theme is good again
[17:01] <kenvandine> oSoMoN, what about the other gnome snaps?
[17:01] <kenvandine> like gnome-calculator
[17:02] <oSoMoN> same
[17:02] <oSoMoN> i.e. without my old version of ~/.config/dconf/user, they get the adwaita theme
[17:02] <kenvandine> LO installed fine with core from stable
[17:03] <jbicha> oSoMoN: do you have an explicit theme set in your gsettings, try:
[17:03] <jbicha> dconf dump / | grep theme
[17:03] <oSoMoN> kenvandine, can you try the gnome-calculator snap in a clean artful VM and let me know if you see the same?
[17:04] <oSoMoN> jbicha, http://paste.ubuntu.com/25852862/
[17:05] <jbicha> yeah, the last three lines say to me that you've customized your theme at some point
[17:06] <oSoMoN> looks like it indeed, not sure how/when I did that
[17:06] <jbicha> gsettings reset org.gnome.desktop.interface gtk-theme (same for icon-theme and cursor-theme) to get back to defaults
[17:06] <jbicha> maybe you tried a different theme in Tweaks and then changed it back?
[17:06] <oSoMoN> could very well be
[17:07] <jbicha> I think it would be nice if dconf wouldn't bother storing configs if they match the default
[17:07] <oSoMoN> yup
[17:08] <oSoMoN> kenvandine, so with a default config I'm getting adwaita for both LO and gnome-calculator
[17:08] <kenvandine> oSoMoN, yeah, i'm guessing the gsettings interface isn't allowing access?
[17:09] <kenvandine> although you'd think it would get a denial
[17:09] <kenvandine> oh, it's the other way
[17:09] <kenvandine> it only works if we've altered?
[17:09] <oSoMoN> yes
[17:13] <oSoMoN> if I disconnect the gsettings interface I'm seeing a denial on ~/.config/dconf/user
[17:13] <oSoMoN> so the snap tries to get the theme config from there
[17:14] <oSoMoN> and it doesn't know how to fall back to the system default
[17:14] <kenvandine> yeah
[17:14] <jbicha> we have per-desktop overrides for theme settings in Ubuntu 17.10
[17:14] <kenvandine> i don't think this affects 16.04
[17:16] <jbicha> (the per-desktop overrides are new to 17.10)
[17:16] <kenvandine> right
[17:16] <oSoMoN> checking in a xenial VM
[17:16] <kenvandine> ~/.config/dconf/user gets created at login on 16.04
[17:16] <kenvandine> i removed it from the console before logging in
[17:16] <kenvandine> and it  was recreated
[17:16] <kenvandine> so i'm thinking jbicha is right
[17:17] <kenvandine> or... something with unity7 that created it
[17:29] <oSoMoN> I confirm that xenial and zesty are not affected, only artful
[17:30] <kenvandine> yeah, and on those that file is created at login
[17:30] <kenvandine> so it only works when that file is created
[17:30] <kenvandine> i guess the question is why does that file not get created anymore
[17:31] <a1fa> seb128: ok i will
[17:31] <kenvandine> i'd guess settings daemon is what triggers creating that
[17:36] <amano> didrocks, the proper gnome-shell fix regressed my boot experience again 😤
[17:37] <amano> now upgrading to libmutter  3.26.1-2ubuntu2
[17:37] <amano> to see if that fixes it
[17:37] <kenvandine> oSoMoN, also of interest... i created a new user on my 17.10 desktop
[17:37] <kenvandine> completely fresh account with a new homedir
[17:38] <kenvandine> logged with the Ubuntu session
[17:38] <kenvandine> it gets the Adwaita theme!
[17:38] <kenvandine> jbicha, ^^
[17:38] <amano> (I was the nouveau user experiencing the amd symptoms)
[17:39] <kenvandine> oh... and it doesn't get the Ubuntu session actually
[17:41] <jbicha> uh, I would have thought that wouldn't happen after the gnome-session/artful SRU 😕
[17:42] <jbicha> ugh
[17:42] <kenvandine> i logged out and back in and now i got the right session
[17:42] <kenvandine> wtf
[17:43] <kenvandine> this isn't a pristine install though :)
[17:43] <kenvandine> but still, very odd
[17:43] <jbicha> right, pristine wouldn't have gnome-session installed
[17:47] <amano> didrocks, 3.26.1-2ubuntu2 is fine again
[17:47] <amano> so 3.26.1-2ubuntu1 regressed?
[17:47] <amano> a shaky experience ;)
[17:51] <amano> * Cherry-pick gdm crasher from gnome-3-26 branch: (LP: #1725153)
[17:51] <amano>     - git_12381d57d1c9256bb1f5206a403c1272bf2af34e.patch
[17:51] <amano>     - git_4ad8c4b86bab938e20e37f47781025911d5ff419.patch
[17:52] <amano> so one of those two gdm crashes was mine
[17:54] <amano> (both were fixed with libmutter 3.26.1-2ubuntu2)
[17:55] <jbicha> amano: didrocks isn't here today
[18:16] <amano> oh, tnx, didn't read the logs today (October is a busy month for me). but it is fine now anyways :)
[18:22]  * oSoMoN calls it a day, good night all
[18:23] <jbicha> I don't know his schedule, but he's not in the userlist in this channel so he's "not here" for that at least
[18:23] <andyrock> jbicha: should we stop answering this tom? :D
[18:23] <andyrock> it's kind of trolling us
[18:31] <willcooke> night all
[19:42] <seb128> jbicha, I would be in favor of not superseeding selected bugfixes SRUs by new versions ones, at least not when the fix is something we want to see landing like the g-c-c segfault one from and_yrock. The new version is more likely to be more difficult to test/have a regression/sit for longer in proposed and it delays the important fix then
[19:50] <jackpot51> jbicha: sounds good
[19:50] <jackpot51> (mutter 3.26.2, that is)
[19:51] <jbicha> seb128: did you see my ping re: Are you able to add a test case for LP: #1700319 ?
[19:51] <seb128> jbicha, I did add one, see the description update from this afternoon?
[19:52] <jbicha> ok, will you be able to verify that bug fix in an SRU? I don't have cygwin and such set up
[19:54] <seb128> I don't have a setup to reproduce no, it works fine between Ubuntu machines
[19:55] <jbicha> my trick in these cases is not to mention a bug # if it's going to be difficult to verify the bug fix ;)
[19:55] <jbicha> I can upload gtk 3.22.25 now and you can poke an SRU team member to expedite its acceptance
[19:56] <jbicha> I think the list of bug fixes in LP: #1728421 is long enough that it would be nice to get all of them in instead of trying to cherry-pick in this case
[19:58] <jbicha> the gtk3/artful SRU I uploaded last week for andyrock was still stuck in unapproved until today
[20:00] <seb128> jbicha, do as you want, I think it's wrong for the reason stated before but it's not a LTS so I don't care enough to argue
[20:02] <seb128> jbicha, there is more than 100 commits in that update
[20:02] <seb128> I wouldn't bet that there isn't a regression or a new issue that is going to block the SRU
[20:03] <seb128> but we can play the odds and see how it goes :)
[20:04] <jbicha> I'm going to wait on LP: #1728617 at least since that will take some more time to test
[20:04] <seb128> right, I'm not sure I would do that change in artful
[20:04] <seb128> it's a behaviour change in the toolkit and can impact apps
[20:05] <seb128> it's fine in a new cycle, less so as a SRU
[20:05] <seb128> but again it's not a LTS so I don't think it's that important so I'm not going to make a fuss about it
[20:08] <jbicha> on the other hand, it's good practice to see how willing the sru team is to accept new gtk3 releases (or other large GNOME updates) under our microrelease exception
[20:13] <seb128> why would they discuss that MRE?
[20:13] <seb128> I think it's fine
[20:13] <seb128> it's just more likely that it fails verification or hit a regression which is going to delay the g-c-c/online account segfaultfix
[20:14] <dobey> hmm, would have been nice to have relevant unity/indicator settings migrated over to gnome on upgrade to 17.10. maybe that can be done for 18.04?
[20:15] <jbicha> GNOME offers a way to convert settings from gconf to gsettings but not from one gsettings to another (that's part of why the Super+L/Ctrl+L bug is unfixed)
[20:15] <jbicha> but what settings were you thinking of?
[20:16] <dobey> clock format and some other things.
[20:16] <dobey> i've just seen some questions popping up like this on askubuntu; not sure what all would translate
[20:17] <dobey> i thought we had something so that a script could be run at login to migrate stuff
[20:18] <jbicha> I think the top bar clock isn't designed to let users make many changes to it
[20:19] <dobey> well you can certainly move it via extension
[20:19] <jbicha> well I mean the time format
[20:19] <dobey> yeah, i don't recall if there's a setting for it or not. but i think there is
[20:20] <jbicha> there are toggles for date and seconds in Tweaks > Top Bar (and coming in 3.28: "day of week")
[20:20] <dobey> ah, there's an extension you have to install to change the format
[20:20] <jbicha> there's AM/PM or 24-hour in Settings > Details > Date & Time
[20:20] <dobey> https://askubuntu.com/a/968955
[20:22] <dobey> so i guess migrating stuff is not so easy :-/