[02:28] <brlin> Can anyone help review this one: https://github.com/ubuntu/snapcraft-desktop-helpers/pull/184
[02:28] <gitbot> ubuntu issue (Pull request) 184 in snapcraft-desktop-helpers "bindtextdomain: Support locale files under share/locale" [Open]
[05:54] <didrocks> good morning
[05:59] <duflu> Morning didrocks
[06:00] <didrocks> hey duflu
[06:03] <didrocks> duflu: hum, I'm running mutter 3.32.0+git20190410-1ubuntu1 which has supposively your timestamp fix, but when I click on the dock, I still have my apps not focused when they start
[06:03] <seb128> good morning desktopers, happy friday!
[06:04] <seb128> hey duflu didrocks
[06:04] <didrocks> hey seb128
[06:04] <duflu> Hmm
[06:04] <duflu> Hi seb128
[06:04] <duflu> Happy Friday
[06:04] <didrocks> some people on the french forum says that it fixes it for them, so there is maybe many causes ?
[06:05]  * didrocks just tried if intellihide mode could have an impact, but not the case
[06:05] <seb128> GNOME has been having issue giving the focus in some cases since we switched to it (or at least ti's also an issue in bionic)
[06:05] <seb128> unsure if your issue is different
[06:05] <didrocks> well, it's quite a 100% hit here
[06:05] <didrocks> which was never the case before 2.31
[06:05] <didrocks> 3.31*
[06:05] <seb128> on any app?
[06:05] <didrocks> yep
[06:05] <didrocks> terminal
[06:05] <didrocks> nautilus
[06:05] <duflu> didrocks, the bug seems to be fixed here. Remember it was Xorg sessions only
[06:05] <didrocks> firefox
[06:05] <didrocks> duflu: I'm on Xorg
[06:06] <didrocks> ah wait
[06:06] <didrocks> maybe it was slightely updated this morning by unattended-upgrade
[06:06] <duflu> Update not fully installed?
[06:07] <didrocks> (I wonder why unatteded-upgrade is installed, it's not a security fix…)
[06:07] <didrocks> and so apt policy showed me I was on the latest
[06:07] <seb128> we apply dev updates with unattended-upgrade now?
[06:07] <didrocks> looks like it from my history.log :/
[06:07] <seb128> weird
[06:07] <didrocks> http://paste.ubuntu.com/p/BXpj2M2gRP/
[06:08] <didrocks> as I wasn't expecting that, I thought apt policy -> latest meant "updated yesterday evening and running latest"
[06:08] <didrocks> so, let me alt+F2
[06:08] <duflu> Yeah
[06:08] <duflu> Or log out...
[06:08] <didrocks> duflu: all working now!
[06:08] <duflu> Though not if you want to keep your windows
[06:08] <duflu> \o/
[06:08] <didrocks> at least, confirming the fix :)
[06:08] <didrocks> but really, unattended-upgrade, why?
[06:09] <duflu> Foundations?
[06:09] <didrocks> yep, unsure if this change was desired
[06:09] <didrocks> I definitively didn't tweak any config
[06:09] <didrocks> and especially on the dev cycle, I want to have control of my ugprade
[06:09] <duflu> I knew I had the fix because my test wallpaper became sharper today
[06:10] <didrocks> seb128: duflu: do you have the same unattended-upgrade experience?
[06:10] <duflu> didrocks, not sure. My dev system gets turned off every night
[06:10] <didrocks> duflu: well, same for me, it's on reboot that it updates
[06:10] <duflu> Weird
[06:10] <didrocks> duflu: you can look at your apt logs and see if you have unattended-upgrade lines
[06:11]  * didrocks disables the service for now
[06:11] <duflu> didrocks, yes. It seems I am now getting unattended-upgrade
[06:12] <didrocks> let me file a bug
[06:13] <seb128> didrocks, yeah, I killed it a few time recently because it was blocking me to using apt in the morning and taking too long and I couldn't be bothered waiting to do $work
[06:13] <didrocks> seb128: do you think that should be -tracking? I have no opinion, but we may have other side-effects I guess…
[06:13] <didrocks> ok, let me open the bug first
[06:13] <duflu> "Software & Updates" tells me it is set to only auto-install security updates
[06:14] <didrocks> yeah, it's supposed to only mess with those
[06:14] <duflu> How do we know mutter wasn't a "security update"?
[06:14] <didrocks> we don't have security updates in the dev version
[06:15] <didrocks> so, it's not in the "security" pocket
[06:15] <duflu> Yeah, the pocket
[06:15] <didrocks> just the regular release one
[06:15] <didrocks> yep
[06:15] <didrocks> and as you can see in my pastebin those are all regular packages in the release pocket ^
[06:15] <seb128> I asked rbalint on #ubuntu-devel
[06:17] <didrocks> thx!
[06:48] <seb128> didrocks, k, so sidestepping over, the situation is that we got confused by u-u but the focus fix works for you after all?
[06:48] <didrocks> seb128: indeed. I still think that changing the behavior of u-u in a drastic way without warning users is weird
[06:49] <didrocks> but at least, the main point, "focus mutter issue" is fixed
[06:59] <seb128> he failed at communicating properly yeah
[06:59] <seb128> but I think on principle it's fine to have that behaviour, it gives us testing before landing changes to stable which would be difficult to get otherwise
[07:00] <seb128> and unstable series are probably mostly used by distro dev or users who like to test edge things and can deal with the behaviour (if it's documented)
[07:01] <didrocks> yeah, we need a reminder that upgrades start applying automatically
[07:49] <duflu> RAOF are you around?
[07:49] <duflu> Hmm, no. Not even in the channel
[08:00] <willcooke> morning
[08:00] <seb128> hey willcooke, how are you?
[08:00] <willcooke> hi seb128, ok, how about you?
[08:00] <didrocks> hey willcooke
[08:01] <willcooke> morning didrocks
[08:02] <seb128> willcooke, good, it's friday!
[08:02] <Laney> hello
[08:02] <seb128> hey Laney
[08:02] <seb128> how are you?
[08:02] <didrocks> hey Laney
[08:04] <Laney> yeah not bad
[08:05] <duflu> Morning willcooke and Laney
[08:42] <willcooke> Laney, are you all Ubiquiti'd up at home?
[08:43] <Laney> oh sorry
[08:43] <Laney> hey didrocks duflu ;-)
[08:43] <Laney> and willcooke
[08:43] <Laney> willcooke: yes
[08:43] <willcooke> ahoy!
[08:43] <Laney> I want to get another access point actually, it doesn't quite cover the whole house properly atm
[08:44] <willcooke> Laney, cool.  I think I asked you about it before, and you were a big +1.  I think the time has come for me to admit that my cobbled together collection of cheap no-name Wifi APs has had its time
[08:44] <willcooke> Let's see what May brings
[08:44] <willcooke> the month, not the witch
[08:44] <Laney> never rely on M... yes indeed
[08:44] <willcooke> :D
[08:45] <Laney> They have two different product lines which don't particularly integrate with each other, which is a bit sad
[08:45] <Laney> so I have https://www.ui.com/edgemax/edgerouter-poe/ and https://www.ui.com/unifi/unifi-ap-ac-pro/
[08:45] <Laney> but they have separate software stacks
[08:46] <willcooke> edgemax is what I was looking at for the router
[08:47] <willcooke> Laney, did you choose the pro over the lite for a specific reason?
[08:49] <Laney> I think it could achieve faster speeds or something? More channels maybe?
[08:50] <willcooke> oki, I'll do some more reading
[08:50] <Laney> was a few years ago already
[09:21] <seb128> Laney, with the freeze nothing is autoaccepted now right? like I don't need to worry about packages being in a set or not for gstreamer right?
[09:21] <seb128> (I don't want to e.G have some universe plugin autoaccepted while the base is not)
[09:23] <Laney> seb128: the script is off
[09:23] <seb128> thx
[09:28] <seb128> Laney, k, gstreamer stack uploaded to disco and desktop ppa (https://launchpad.net/~ubuntu-desktop/+archive/ubuntu/ppa)
[09:28] <seb128> needs to build now (seems like ppa doesn't do depwait?)
[09:28] <seb128> let's give it some testing from the team in the ppa once it will be built
[09:29] <Laney> sure they do, you just get the × icon
[09:29] <seb128> ah, indeed
[09:29] <seb128> good
[09:35] <tseliot> seb128, Laney: do you know how to detect that a udev rules is running on the live installer. I would like to make it quit in this specific case, so that LP: #1824177 can be fixed
[09:35] <ubot5`> Launchpad bug 1824177 in nvidia-graphics-drivers-410 (Ubuntu) "dmesg spammed with nvidia-nvlink messages during install" [Undecided,Confirmed] https://launchpad.net/bugs/1824177
[09:35] <tseliot> willcooke: ^
[09:38] <willcooke> sorry, I dont know
[09:39] <seb128> tseliot, sorry but I don't know either
[09:44] <Laney> tseliot: isn't vorlon saying that you shouldn't be doing anything until reboot at all?
[09:44] <Laney> but no, sorry, I'm not aware of an official way to detect a live environment
[09:44] <Laney> you might want to ship something in casper
[09:45] <Laney> AFAIK udev rules in /run shadow ones in /lib
[09:46] <tseliot> Laney: I don't think udev rules have that kind of logic in place. What I was thinking is to make the udev rule quit when on the live installer. So far, I've found out that update-initramfs is diverted on the live installer. Maybe I can use that
[09:47] <Laney> right, that's a casper script
[09:48] <tseliot> so, I want to test a condition in the udev rule, and avoid doing any big changes before the release
[09:50] <Laney> I think you probably want to make casper ship a udev rule in /run/udev/rules.d/ that overrides the packaged one
[09:50] <Laney> "files in /run take precedence over files with the same name in /lib. This can be used to override a system-supplied rules file with a local file if needed"
[09:50] <tseliot> Laney: do you mean a rule with the same name?
[09:50] <Laney> yep
[09:51] <tseliot> that's even easier. I can try it here now
[09:51] <Laney> slightly hard bit will be testing the casper change
[09:57] <tseliot> Laney: just an empty udev rules with the same seems to do the trick, and I don't get spammed any more
[09:57] <tseliot> thanks
[09:57] <willcooke> woot thanks tseliot Laney
[09:58] <Laney> np
[09:58] <Laney> tseliot: so that's a casper-bottom script fwiw
[09:58] <Laney> like the one to disable snap refresh
[09:58] <tseliot> Laney: ok, then I'll have a look at the sources, and come up with a patch
[09:59] <Laney> ok
[09:59] <Laney> to test it you can do break=top from an iso boot and then hack it into place in /scripts
[09:59] <Laney> but it's very bare bones, be warned
[10:03] <tseliot> Laney: ok, I'll try that. Thanks
[10:04] <Laney> (well, you could probably re-pack the ISO or something too...)
[10:15] <brlin> Can anyone review this PR?: https://github.com/ubuntu/snapcraft-desktop-helpers/pull/185
[10:15] <gitbot> ubuntu issue (Pull request) 185 in snapcraft-desktop-helpers "gnome-platform: Drop unnecessary build-packages" [Open]
[11:04] <tseliot> Laney: I wrote the script manually (using tee), and made the file executable (chmod a+x), after booting with break=top, and then I run the "exit" command. /run/udev/rules.d/ wasn't created. Is there any way to check what happened? Maybe a log from casper?
[11:05] <tseliot> I don't see anything useful in casper.log
[11:05] <tseliot> the script was in scripts/casper-bottom/
[11:07] <seb128> brlin, try asking kenvandine when he gets online
[11:18] <willcooke> new ups battery arrived, going off line for a few mins while I change it over.  I can't remember exactly what's connected and what's not, but I assume my modem is.
[11:22] <Laney> tseliot: weird, I just tried the same and it worked for me -- did you add it to ORDER and copy all of the boilerplate stuff that the other scripts have at the top?
[11:23] <Laney> casper.log isn't very helpful tho, agreet
[11:28] <brlin> seb128: Sure, thanks!
[11:29] <Laney> (not sure what ORDER does tbh)
[11:35] <willcooke> well, that went better than I expected.
[11:35] <willcooke> Hardly anything caught on fire
[11:54] <willcooke> so it seems upowerd is holding on to one of my upses, and I want nut to manage it.  Any ideas how I can stop upower doing that, or just stop upowerd altogether?
[11:55] <willcooke> heh, I just killed it and started nut before it could restart. Problem solved
[11:56] <willcooke> also, nut is *the* hardest thing to work with in the world.
[11:57] <seb128> :/
[11:57] <seb128> gstreamer stack update in https://launchpad.net/~ubuntu-desktop/+archive/ubuntu/ppa if others want to test it
[11:57] <seb128> (seems to work fine here)
[11:57] <seb128> disco update
[11:57]  * willcooke updates
[11:58] <seb128> thx
[11:59] <seb128> (tested totem/rb/cheese here)
[11:59] <seb128> brb, changing location
[12:13] <seb128> (back)
[12:15] <andyrock> seb128: is there a but about the g-i-s/snap thing?
[12:16] <seb128> andyrock, hey, good timing I was about to ping you :)
[12:16] <seb128> bug #1824188
[12:16] <ubot5`> bug 1824188 in gnome-initial-setup (Ubuntu) "Software tab is empty on clean 19.04 install" [High,Confirmed] https://launchpad.net/bugs/1824188
[12:16] <seb128> andyrock, ^
[12:16] <andyrock> I took a look at the code, it's going to take a while to fix it
[12:17] <andyrock> also because reproducing the bug it's not easy
[12:18] <willcooke> could you kill snapd, and run g-i-s without it running, then start once g-i-s is running?
[12:20] <seb128> andyrock, attach gdb to the snapd service to block it from responding? ;)
[12:21] <willcooke> (side note:  a problem I was having with a specific bluetooth mouse not reconnecting automatically is seemingly fixed :) )
[12:21] <seb128> clobrano, hey, is that gnome-initial-setup bug about using the incorrect icon still valid? the description pointed out to the welcome-app yaru icon but that has been removed
[12:22] <seb128> willcooke, good! was that the gnome-bluetooth update?
[12:22] <seb128> willcooke, also did you test the gstreamer updates? I dropped from IRC for a bit so might have missed that
[12:23] <clobrano> hey seb128! Was the bug opened on launchpad? I can't find it on github
[12:24] <willcooke> seb128, just testing now.  Cheese works, downloading b.b.bunny now...
[12:24] <willcooke> rb radio works
[12:24] <seb128> clobrano, yes, bug 1803521
[12:24] <ubot5`> bug 1803521 in gnome-initial-setup (Ubuntu) "gnome-initial-setup uses wrong icon" [Undecided,New] https://launchpad.net/bugs/1803521
[12:24] <clobrano> let me check
[12:25] <seb128> clobrano, thx
[12:26] <willcooke> seb128, @ bluetooth - I think so.  I found an upstream bug which said it was fixed, so sounds right
[12:26] <seb128> willcooke, good :)
[12:27] <willcooke> Saviq, do you still have your Logitech M557 mouse?  If so, I think that disco has the fix now for reconnecting problems
[12:27] <Saviq> willcooke: yeah I've been working with duflu to verify the fix
[12:29] <tseliot> Laney: unless I missed something obvious: http://paste.ubuntu.com/p/vMRpJdRccV/
[12:29] <willcooke> Saviq, woot
[12:29] <seb128> Saviq, what fix is it?
[12:29] <tseliot> Laney: and no, I didn't add it to ORDER. I'll check that
[12:29] <seb128> Saviq, I mean are you refering to a specific commit we can SRU?
[12:29] <seb128> (bug number?)
[12:29] <willcooke> I think its adding the device ids to a file so that it auto tries with pin 0000
[12:30] <willcooke> I'll find it
[12:30] <Saviq> I'll get you guys the big number when I'm back in Ubuntu
[12:30] <willcooke> seb128, looks like this one: https://bugs.launchpad.net/ubuntu/+source/bluez/+bug/1246981
[12:30] <seb128> willcooke, Saviq, https://salsa.debian.org/gnome-team/gnome-bluetooth/commit/ba99a3ce then?
[12:30] <ubot5`> Ubuntu bug 1246981 in bluez (Ubuntu) "Bluetooth mouse fails to re-connect after sleep." [Medium,Confirmed]
[12:31] <Saviq> The latest gnome-bluetooth update I believe
[12:31] <willcooke> seb128, yeah that looks like it
[12:31] <seb128> well the diff doesn't make sense to me though
[12:32] <willcooke> hm, nothing about this mouse in there
[12:32] <willcooke> one sec
[12:32] <seb128> ah
[12:34] <seb128> willcooke, no, it's fine, I misread it
[12:34] <seb128> it's the
[12:34] <seb128>  	
[12:34] <seb128> 		<!-- Mice don't usually need pincodes -->
[12:34] <seb128> 	
[12:34] <seb128> 		<device type="mouse" pin="NULL"/>
[12:34] <seb128> bit from the diff
[12:35] <willcooke> ah, I see
[12:35] <seb128> I'm going to SRU that now
[12:35] <willcooke> woo, thanks seb128
[12:35] <seb128> np
[12:37] <andyrock> seb128: using gdb it's not going to work because gnome-initial-setup will just block
[12:37] <andyrock> because it's using sync operation
[12:37] <seb128> andyrock, ah, it's a sync call without timeout?
[12:38] <andyrock> I'll try to make it async
[12:38] <seb128> andyrock, or maybe ask #snappy if they can help you putting snapd in the state which makes it not respond
[12:38] <Saviq> seb128, willcooke: my bug is https://bugs.launchpad.net/ubuntu/+source/bluez/+bug/1777062
[12:38] <ubot5`> Ubuntu bug 1777062 in gnome-bluetooth (Ubuntu Cosmic) "Logitech M535 mouse only pairs successfully after 4-5 tries" [Undecided,New]
[12:39] <clobrano> seb128: yes, since the Yaru icon is not there anymore, that specific behavior is invalid. However the "problem" should still be there
[12:39] <seb128> clobrano, what's the icon you expect to be used between the two?
[12:40] <willcooke> Saviq, thx
[12:40] <seb128> Saviq, willcooke, that bug description doesn't make sense to me. gnome-bluetooth only handle the pairing from the settings, not happens later
[12:40] <seb128> I mean if it pairs it in a way that is not persistent/trusted in bluez that explain it has to be paired again
[12:40] <willcooke> seb128, Totem working with an h264 working.  Promoted me to install the codec, did that from the ppa, restart totem, loaded the video, moar rabbits
[12:40] <seb128> but if you pair using bluetoothctl then gnome-bluetooth is out o fthe picture
[12:41] <seb128> willcooke, great, thx for testing!
[12:41] <willcooke> seb128, is the pin-code-database shared between bluetoothctl and gnome-bluetooth perhaps?
[12:42] <seb128> willcooke, gnome-bluetooth used to have overrides, the change is basically to drop that to use the bluez one
[12:42] <seb128> bluez doesn't use anything from gnome-bluetooth no
[12:43] <seb128> it's a lower level component, doesn't require GNOME nor event a graphical session
[12:43] <seb128> willcooke, the gnome-bluetooth change should fix the case of "pairing done through GNOME doesn't persist"
[12:43] <seb128> which is probably most reports
[12:44] <seb128> the "pairing with bluetoothctl has problem" from Saviq sounds like it's different though
[12:44] <seb128> maybe that was a kernel issue or such also fixed in disco
[12:45] <willcooke> I bet duflu will know
[12:46] <seb128> I will SRU the gnome-bluetooth fixes since they make sense
[12:46] <seb128> that's a good first step
[12:46] <clobrano> seb128: yes, the bug was opened because the unexpected icon was used, and this issue is gone
[12:46] <clobrano> seb128: but I thought that the problem is due to a difference in how the .desktop files where written
[12:47] <seb128> clobrano, right, if we standardize we need to pick one icon or the other, I just don't know which one makes more sense ... do you have an opinion on that?
[12:48] <clobrano> seb128: I have no strong opinion, I can only say that "preferences-system" doesn't seem specific enough if the real target is the ubuntu-logo
[12:48] <seb128> k
[12:48] <seb128> clobrano, thx
[12:48] <clobrano> seb128: np :)
[12:49] <clobrano> omg, just noticed... s/where/were ^
[13:11] <kenvandine> brlin: i'm on it
[13:14] <brlin> kenvandine: <3
[13:20] <willcooke> morning kenvandine
[13:23] <kenvandine> hey willcooke
[13:26] <andyrock> seb128: if we want to get rid of most of the gedit crashes it would be nice to have this in disco: https://gitlab.gnome.org/GNOME/gedit/merge_requests/32
[13:26] <gitbot> GNOME issue (Merge request) 32 in gedit "build: Reintroduce enable-gvfs-metadata option" [Merged]
[13:26] <seb128> Laney, ^ do you have slots to help reviewing the few pending fixes from andyrock for gedit today?
[13:27] <andyrock> seb128, Laney: the other fixes are not strictly necessary if we get this in debian/disco
[13:27] <seb128> andyrock, why not? they don't fix other problems?
[13:28] <seb128> well you mean they are less important?
[13:28] <andyrock> they do, but if we enable gvfs metadata the crash is not going to happen
[13:29] <andyrock> they're necessary if and only if gvfs metadata is disabled
[13:31] <andyrock> to summarize:
[13:32] <andyrock> 1. https://gitlab.gnome.org/GNOME/gedit/merge_requests/34 is necessary both if gvfs is enabled and if it is disabled (but we already distro patched it)
[13:32] <gitbot> GNOME issue (Merge request) 34 in gedit "open-document-selector: Properly remove idle" [Opened]
[13:33] <andyrock> 2.  https://gitlab.gnome.org/GNOME/gedit/merge_requests/35 it is necessary only if gvfs is disabled
[13:33] <gitbot> GNOME issue (Merge request) 35 in gedit "metadata-manager: Remove singleton" [Opened]
[13:33] <seb128> andyrock, oh ok
[13:33] <andyrock> 3. tab: Cancel loading operation when tab is disposed this does not fix a crash but I saw it while debugging so I fixed it
[13:33] <andyrock> now the commit that just got merged re-enabled gvfs by default
[13:34] <seb128> jbicha, ^ or maye you can review since you have been sort of gedit maintainer in recent cycles :-)
[13:34] <andyrock> seb128: jbicha said that I can merge them if I want but I can't because I'm not a GNOME developer
[13:35] <seb128> andyrock, I try to get it later today if Laney can't but I'm currently on a packed todolist for the day :/
[13:35] <andyrock> and now it's too late for me to ask 💔
[13:35] <andyrock> my suggestion for Laney is to review/merge https://gitlab.gnome.org/GNOME/gedit/merge_requests/34
[13:35] <gitbot> GNOME issue (Merge request) 34 in gedit "open-document-selector: Properly remove idle" [Opened]
[13:35] <andyrock> it should be safe enough
[13:36] <seb128> willcooke, Saviq, https://launchpadlibrarian.net/418989286/gnome-bluetooth_3.28.0-2ubuntu0.2_source.changes (used another bug for the SRU which looked like the issue and was less old/busy, those reports which collect problems over years often lead to difficult SRU validation because some of the people subscribed have another problem and will claim your SRU doesn't work)
[13:36] <seb128> andyrock, that's the wrong one right?
[13:36] <seb128> that one we already backported/SRUed
[13:36] <seb128> you mean !32
[13:36] <andyrock> nope
[13:37] <seb128> ah, you mean upstream
[13:37] <andyrock> I know that it has been backported but it still nice to have it upstream
[13:37] <seb128> right
[13:37] <seb128> gotcha
[13:37] <seb128> you are correct :)
[13:37] <willcooke> seb128, @ bluetooth: will confirm on this machine
[13:37] <andyrock> seb128:  also I can distro-patch the commit to enable gvfs by default after I take care of g-i-s
[13:38] <seb128> andyrock, k, let's see what L_aney says when he's back from lunch
[13:38] <seb128> andyrock, thx
[13:38] <andyrock> kk
[13:40] <willcooke> yay:
[13:40] <willcooke> W: An error occurred during the signature verification. The repository is not updated and the previous index files will be used. GPG error: http://dl.google.com/linux/chrome/deb stable Release: The following signatures were invalid: EXPKEYSIG 1397BC53640DB551 Google Inc. (Linux Packages Signing Authority) <linux-packages-keymaster@google.com>
[13:40] <willcooke> W: Failed to fetch http://dl.google.com/linux/chrome/deb/dists/stable/Release.gpg  The following signatures were invalid: EXPKEYSIG 1397BC53640DB551 Google Inc. (Linux Packages Signing Authority) <linux-packages-keymaster@google.com>
[13:40] <willcooke> W: Some index files failed to download. They have been ignored, or old ones used instead.
[13:41] <seb128> EXPKEYSIG
[13:41] <seb128> well done google :p
[13:42] <willcooke> \m/
[14:00] <kenvandine> brlin: thanks, that's a nice improvement.  Merged!
[14:01] <brlin> kenvandine: Thanks!  Here's another one: https://github.com/ubuntu/snapcraft-desktop-helpers/pull/184
[14:01] <gitbot> ubuntu issue (Pull request) 184 in snapcraft-desktop-helpers "bindtextdomain: Support locale files under share/locale" [Open]
[14:06] <kenvandine> brlin: saw it, that only helps snaps with --prefix=/
[14:06] <kenvandine> can't imagine there are a ton of those
[14:06] <brlin> kenvandine: Snapcraft autotools plugin by default built with empty prefix
[14:07] <brlin> s/built/build/
[14:07] <kenvandine> although it time cost should be negligible
[14:07] <kenvandine> empty usually defaults to usr or usr/local
[14:08] <brlin> kenvandine: That's not what I encountered though :-/
[14:08] <kenvandine> ok
[14:09] <brlin> It does specify `--prefix` while configuring , just set it as null: https://github.com/snapcore/snapcraft/blob/77c17b26573e474783e9535bf66ce3fe358b71f1/snapcraft/plugins/autotools.py#L121
[14:10] <kenvandine> brlin: indeed
[14:11] <kenvandine> brlin: merged
[14:11] <brlin> kenvandine: Thanks a bunch!
[14:11] <kenvandine> brlin: thank you!
[14:18] <Laney> seb128: yeah I saw the ping about gedit somewhere else
[14:19] <seb128> Laney, it was trello :)
[14:19] <Laney> so I had the tab open already, but thx for the re-ping
[14:19] <Laney> seems SRUable to me
[14:19] <seb128> Laney, but that other bug andyrock was pinging about seems worth trying to get into disco proper so maybe one for today if we can squeeze
[14:44] <seb128> Laney, thx for catching that tracker buggy upload, trying too much this week and not taking time to do some of them properly :/
[14:45] <seb128> Laney, I was going to upload to Debian but didn't want to wait to wait for launchpad to pick the uploads/sync and miss friday to get it reviewed
[14:45] <Laney> np, good when reviews work
[14:45] <seb128> Laney, but feel free to take over that :)
[14:45] <Laney> well you can do a ~fakesync upload
[14:45] <Laney> like for gstreamer
[14:45] <Laney> but also things can be SRUed at this point, maybe that makes for fewer mistakes with less rushing
[14:45] <seb128> right, it's just that jbicha commited 2.2.1 things to the vcs
[14:46] <seb128> and I didn't want spend time sorting out what to do there at the time
[14:46] <Laney> yep, I'm making a branch from the 2.1.8-1 tag
[14:46] <seb128> k
[14:46] <Laney> git checkout -b debian/buster debian/2.1.8-1 and update debian/gbp.conf
[14:46] <seb128> thx for the tip :)
[14:46] <seb128> yeah, I know for SRU, I've difficulties to be in peace with that though :(
[14:47] <seb128> we always end up getting reports in the error tracker and launchpad until end of times from users who don't apply updates for some reasons
[14:47] <Laney> yeah like we get people who insist on running devel-proposed
[14:47] <seb128> but that's probably my issue, I should accept that such are software users
[14:47]  * Laney has made peace with these things
[14:47] <seb128> one day you need to teach me how :)
[14:48] <seb128> anyway, I do try to land some of the crashers fix in the release for those reasons
[14:48] <seb128> but I'm not pushing so fine if they sit in the queue or in proposed until SRU time
[14:48] <Laney> okey, maybe make sure they have a bug report attached then
[14:48] <Laney> not saying they don't, haven't checked for that
[14:49] <seb128> yeah, that one had
[14:49] <seb128> g-c-c doesn't for the translation fix I added
[14:49] <seb128> worth thing it get rejected and it's a bit more work
[14:49] <seb128> I try to that for the next ones
[14:49] <Laney> nod
[14:49] <seb128> should I reupload the gstreamer stack for a SRU reference?
[14:49] <seb128> probably for -release
[14:49] <Laney> probably going to accept those ones in a minute
[14:50] <Trevinho> morning!
[14:51] <seb128> Laney, thx
[14:52] <seb128> hey Trevinho, how are you?
[14:53] <Trevinho> seb128: hey, all good!
[14:53] <Trevinho> you?
[14:53] <seb128> good!
[14:53] <seb128> happy friday btw :)
[14:54] <seb128> the work day only starts for you, but any fancy plan for the w.e ;)
[14:55] <andyrock> seb128: do you want me to add an error message in g-i-s in case it fails to get the featured snaps ?
[14:55] <andyrock> I've added a retry behaviour
[14:55] <andyrock> it's going to try to every 250 ms for a maximum of 5s
[14:56] <andyrock> but what if it fails? showing an error will required a UIFe
[14:59] <seb128> andyrock, I think new string is fine in that case
[15:00] <seb128> willcooke, Laney, ^ opinion? (about bug #1824188)
[15:00] <ubot5`> bug 1824188 in gnome-initial-setup (Ubuntu) "Software tab is empty on clean 19.04 install" [High,Confirmed] https://launchpad.net/bugs/1824188
[15:01] <willcooke> For the string, how about... "Unable to retrieve applications at this time.  Please open Ubuntu Software to see what's available."
[15:01] <seb128> willcooke, we do want a string/UI change right? even if it's untranslated at this point?
[15:02] <willcooke> thinking....
[15:02] <seb128> andyrock, also chipaca was saying yesterday that it takes 90s for snapd to be ready in his kvm
[15:02] <seb128> willcooke, did you do any timing testing at the end?
[15:02] <Trevinho> seb128: happy Friday you too :-), well... some more sightseeing I expect
[15:02] <willcooke> I did, and it was no where near 90 seconds.  Let me fire up the vm
[15:02] <seb128> andyrock, so maybe 1s for 30s or something would be better
[15:02] <willcooke> oh, except I will need to reinstall
[15:03] <seb128> willcooke, no hurry, but I think we still want to push a bit further than 5s retry total
[15:03] <kenvandine> i noticed the same problem in hyperv yesterday
[15:03] <willcooke> Yeah
[15:03] <kenvandine> empty page
[15:03] <willcooke> It certainly feels like something has got worse there on the snapd side
[15:04] <andyrock> who's going to wait 90s for that page? XD
[15:04] <Laney> is that a spinner while waiting for the list of snaps?
[15:05] <willcooke> Laney, correct
[15:05] <seb128> andyrock, well, I think that's total from boot that it takes 90s
[15:06] <andyrock> Laney: I'm going to add a spinner too
[15:06] <willcooke> andyrock, seb128 - if we don't have apps to show, we should remove the "You can use software to install apps like these" too
[15:06] <seb128> andyrock, so time your session start, the wizard load, you go through previous steps
[15:06] <andyrock> seb128: kk
[15:06] <seb128> and 90s is on slow vm
[15:06] <seb128> hopefully it's not that slow for everyone :p
[15:06] <kenvandine> even 30 seconds is way to long
[15:07] <seb128> right
[15:07] <kenvandine> and
[15:07] <seb128> I think the snapd team should care/own those sort of issues
[15:07] <kenvandine> imo it should be able to return results without it needing to seed
[15:07] <seb128> instead of bouncing back to us as our problem every time
[15:07] <seb128> that's a bit irritating
[15:07] <kenvandine> i can see not being able to install
[15:07] <kenvandine> it would queue
[15:07] <Laney> done is insensitive while the spinner is showing or what?
[15:07] <kenvandine> but get the list from the store shouldn't be blocked by seeding
[15:07] <seb128> right
[15:07] <Laney> I don't really like showing a weird error
[15:07] <kenvandine> mvo: ^^ thoughts?
[15:08] <Laney> just let them quit it
[15:08] <willcooke> The other option imo, is to not launch g-i-s until snapd is ready.  But that could be a long wait and pop up seemingly randomly
[15:08] <Laney> keep trying forever as long as the page is open
[15:08] <kenvandine> hack
[15:08] <Laney> but let people get out of it whenever they want
[15:08] <seb128> +1 for that
[15:09] <willcooke> ah, that sounds good Laney
[15:09] <kenvandine> +1
[15:09] <willcooke> seb128, what are you +1 ing?
[15:09] <seb128> andyrock, ^
[15:09] <kenvandine> and we should bug the snapd team about making it handle queries while it's seeding
[15:09] <seb128> willcooke, spin while the page is on screen, let user close anyway if they don't want to wait
[15:09] <willcooke> ta
[15:09] <seb128> also it's no new string and less UI change
[15:09] <Laney> otoh an eternal spinner could be confusing
[15:09] <Laney> but probably less bad than an error?
[15:09] <seb128> hopefully it's never eternel
[15:10] <willcooke> I think then, we should hide the "you can use software like...." as well, until its ready
[15:10] <willcooke> seb128, it could be for ever if the machine is off line
[15:10] <seb128> it should take a 1 minute or so max
[15:10] <willcooke> so 90 seconds max seems sensible
[15:10] <seb128> what do we do today for those?
[15:10] <willcooke> well, 95
[15:10] <kenvandine> if we're offline we shouldn't show the page at all
[15:10] <seb128> right
[15:10] <willcooke> ah, kk
[15:11] <kenvandine> and i think snapd can tell you if it's offline
[15:11] <mvo> kenvandine: we looked at this (pawel to be precise) and its the fc-cache generation that takes the time - if we could generate caches for v6/v7 as part of the install we cut a significant amount of time (>20s in our tests)
[15:11] <kenvandine> hopefully it doesn't report as offline when it's seeding
[15:11] <andyrock> wait so should we show an error or not?
[15:11] <andyrock> iirc I can hide a page in g-i-s if there is no connection
[15:11] <andyrock> let me check
[15:11] <kenvandine> mvo: my real question was can we let snapd respond to queries while it's seeding?
[15:12] <Laney> the other option is don't show it at all if it's not ready
[15:12] <kenvandine> so let s get the list of snaps in ubuntu-firstrun category
[15:12] <kenvandine> s/let s/let us/
[15:12] <pstolowski> hey
[15:12] <mvo> kenvandine: queries like store searches?
[15:12] <Laney> andyrock: we're saying just keep trying forever as long as they are sitting on the page I think
[15:12] <kenvandine> yeah
[15:12] <Laney> but make "Done" sensitive if you're doing that
[15:12] <seb128> Laney, we did fear that in the current state of things it would mean not showing it for most users because snapd got slow in disco
[15:12] <kenvandine> mvo: we just need a list of snaps from a category
[15:12] <Laney> ok
[15:12] <andyrock> Laney: kk
[15:12] <mvo> kenvandine: let me quickly check with the team
[15:12] <kenvandine> even if we can't install them yet
[15:13] <kenvandine> right now we can't get that list until seeding is done
[15:13] <kenvandine> it blocks
[15:13] <willcooke> hm, if we get the list, and someone clicks on it they get taken to Software.  What happens then?  Will Software error, or will it just wait?
[15:13] <seb128> brb, changing location
[15:13] <kenvandine> willcooke: it should queue
[15:14] <willcooke> kk
[15:14] <willcooke> I'd like to test that
[15:14] <willcooke> I think you're right, but ya know
[15:14] <Chipaca> holaa
[15:14] <willcooke> ahoy Chipaca
[15:14] <mvo> kenvandine: Chipaca says "yes we can"
[15:14] <mvo> kenvandine: it seems the problem is that the connect is too early? sorry I was not following all the details but Chipaca  I think was
[15:14] <Chipaca> the problem isn't querying while seeding (although "list of installed snaps" when it's in the middle of installing will be racy)
[15:14] <mvo> kenvandine: and for fc-cache we have pstolowski  who knows the details
[15:15] <Chipaca> the problem is not retrying on connect/read error
[15:15] <Chipaca> because snapd will go away in the middle of seeding, that's normal and expected
[15:16] <Chipaca> it takes less than a second to come back (~200ms on a loaded machine)
[15:16] <willcooke> so a few retries might just be enough then
[15:17] <Chipaca> yes
[15:17] <Chipaca> note that there's a difference between a low-level error like 'the socket went away' or sth, and an error response -- but i don't know how snapd-glib exposes that
[15:17] <Chipaca> what you're wanting to retry is the former
[15:18] <andyrock> actually snapd-glib has code to retry on connect but no on read
[15:19] <willcooke> Ah
[15:19] <willcooke> yeah we're getting  Connection reset by peer on read
[15:19] <Chipaca> also, snapd won't go away in the _middle_ of a request
[15:19] <Chipaca> (or it shouldn't! :-) bugs might exist)
[15:19] <Chipaca> we go away gracefully
[15:20] <kenvandine> ok, so maybe this is something we can improve in snapd-glib?
[15:20] <Chipaca> i need to repeat that getting the list of installed snaps is dubious when snapd is still seeding, so maybe that logic needs tweaking
[15:21] <Chipaca> but sections, featured snaps, etc, as long as the network is up should just work
[15:21] <kenvandine> Chipaca: we don't need the list of installed for this use case
[15:21] <kenvandine> just the list for a single category
[15:22] <Chipaca> kenvandine: i mean, you're getting it
[15:22] <Chipaca> it's the first thing you do
[15:23] <andyrock> kenvandine: snapd-glib can be smarter but it's easier to fix it in g-i-s
[15:23] <andyrock> at least at this point of the ccle
[15:23] <andyrock> *cycle
[15:23] <kenvandine> andyrock: great :)
[15:24] <Chipaca> kenvandine: line 826 of debian/patches/0001-Add-Ubuntu-mode-with-special-pages.patch
[15:24] <Chipaca> installed_snaps = snapd_client_list_sync (client, NULL, &error);
[15:24] <kenvandine> i wonder why
[15:24] <kenvandine> andyrock: ^^
[15:24] <Chipaca> that's why i say that logic needs tweaking :-)
[15:24] <kenvandine> that seems pointless
[15:25] <Chipaca> kenvandine: /* Skip if already installed */
[15:25] <kenvandine> unless it's to filter out
[15:25] <kenvandine> yeah
[15:25] <Chipaca> kenvandine: also /* Ignore common snaps that have default .debs */
[15:25] <Chipaca> ¯\_(ツ)_/¯
[15:26] <kenvandine> we should just trust that section is properly currated
[15:26] <kenvandine> andyrock: what do you think?
[15:26] <Chipaca> you _could_ look at what's going to get seeded and skip those
[15:27] <kenvandine> ubuntu-firstrun should only container what we want displayed in g-i-s
[15:27] <Chipaca> because otherwise in 2 years, are you going to remember that the snap you seeded in 19.10 is now featured
[15:27] <Laney> please leave bigger refactorings for after final freeze
[15:27] <seb128> (back online)
[15:27] <seb128> willcooke, on my inspiron on a fresh install from today it took like a minute for the wizard to open
[15:27] <Chipaca> Laney: it's C, the binary is tiny, so that's small right?
[15:27]  * Chipaca hides
[15:27] <kenvandine> lol
[15:28] <seb128> willcooke, still the software page was empty :/
[15:28] <Laney> 0:D
[15:28] <Laney> and we all know C developers are the smartest, so actually the smallest chance of any bugs appearing :>
[15:28] <Chipaca> kenvandine: because the code carries on even if that snapd_client_list_sync call fails, it should be fine to just comment out that line
[15:29] <Chipaca> kenvandine: (although I have no idea if the code actually _works_ if that call fails, as opposed to freaking out over it being nil)
[15:29] <Chipaca> also it's starting to feel like i'm teaching my grandmother something about eggs
[15:29] <Chipaca> so i'm going to step away from this now
[15:30] <kenvandine> Chipaca: thanks!
[15:30] <Chipaca> kenvandine: you know where to find me
[15:31] <GunnarHj> Hi seb128, Laney! Me again with another g-c-c MP. Not perfect, but a step in the right direction.
[15:31] <GunnarHj> https://code.launchpad.net/~gunnarhj/ubuntu/+source/gnome-control-center/+git/gnome-control-center/+merge/365920
[15:31] <GunnarHj> To late?
[15:31] <willcooke> seb128, I've seen it be slow to open on a few installs, but could never work out why
[15:31] <pstolowski> willcooke: have you discussed anything re fc-cache issue?
[15:32] <willcooke> pstolowski, erm, dont /think/ so
[15:32] <Laney> GunnarHj: might be better to keep working on it and SRU this?
[15:33] <pstolowski> willcooke: ah, i see, i was told it was brought up here already
[15:33] <pstolowski> willcooke: ok, let me explain
[15:33] <kenvandine> pstolowski: i don't think the fc-cache bit is really our issue
[15:33] <kenvandine> so you can disregard
[15:34] <GunnarHj> Laney: May be. I'd say that if you do yet another upload for some other reason, it would be good to include it. Otherwise wait.
[15:34] <seb128> GunnarHj, what does it fix compared to the previous change?
[15:35] <pstolowski> kenvandine, willcooke: it's about the installer and populating fontconfig cache on install, before reboot
[15:35] <GunnarHj> seb128: I displays correct labels, for instance "Serbian" and "Serbian - latin" instead of "Serbian" and "Serbian".
[15:35] <seb128> GunnarHj, ah, we can probably do that in a SRU, I'm sure we are going to do some for g-c-c
[15:36] <Laney> but they don't work properly right, so it's still going to be a bit weird/confusing
[15:36] <GunnarHj> Laney: True.
[15:40] <seb128> k, so SRU sounds better, sort it out properly and then upload
[15:41] <willcooke> pstolowski, on install of the snap?
[15:41] <seb128> willcooke, btw on that install on the inspiron the world map was really streched horizontally and the dots such misplaced (like Paris was in the north sea), did you see that problem?
[15:41] <willcooke> seb128, negative.  Let me download todays ISO
[15:42] <seb128> could have a one off, I'm going to try again
[15:43] <andyrock> kenvandine: the installed snaps is to filter them out
[15:43] <andyrock> not sure about the firefox thing
[15:43] <andyrock> I didn't write that page :D
[15:44] <pstolowski> willcooke: snapd generates fc-cache if it doesn't exist, this currently happens after seeding on the first run after installation and takes around 20s. we could probably save a lot of that if the installer simply populated font cache of the installed system
[15:44] <pstolowski> willcooke: i mean simply copied /var/cache/fontconfig from live session
[15:45] <seb128> pstolowski, would that be enough? shaving 20s of 90s is still making likely that snapd is not ready on time for the UI
[15:46] <willcooke> andyrock, kenvandine  - I sort of remember something about that.  It was when people upgraded that we wouldnt pimp stuff they already had, so that other stuff had a chance to fill the gaps
[15:46] <seb128> willcooke, andyrock, kenvandine, well, not only upgrade, no point recommending things we pre-install as deb/they already have installed out of the box
[15:47] <willcooke> seb128, @fc-cache I guess this is orthogonal to the g-i-s issue
[15:47] <seb128> right
[15:47] <willcooke> seb128, @ preinstall - +1
[15:47] <seb128> the fc-cache thing would be an optimization
[15:47] <pstolowski> seb128: what is the 90s you're talking about?
[15:47] <seb128> but I don't think it's rls topic at this point
[15:47] <willcooke> so it seems like a nice time saver anyway, but too late now for 19.04 of course :)
[15:48] <willcooke> pstolowski, Chipaca saw 90s from booting his disco vm to snapd being "done"
[15:48] <willcooke> desktop started at around 30s from what I remember
[15:48] <seb128> pstolowski, https://irclogs.ubuntu.com/2019/04/11/%23snappy.html#t12:46
[15:49] <willcooke> pstolowski, Given that it's too late for this cycle, could you log a bug with the suggestion?
[15:50] <pstolowski> willcooke: will do, thanks
[15:50] <willcooke> cheers!
[15:50] <pstolowski> thanks seb128, i'll check this out
[15:51] <andyrock> seb128: kenvandine we should just remove firefox from the ubuntu-firstrun section
[15:56] <kenvandine> i'd be ok with that
[15:56] <willcooke> I dont understand why it's even there
[15:56] <willcooke> it shouldnt be in the curated list
[16:05] <andyrock> seb128: willcooke https://usercontent.irccloud-cdn.com/file/oyoTc3Dn/image.png
[16:05] <andyrock> not showing "You can use...." will make the spinner weird
[16:06] <willcooke> how weird?  Just that you don't know what it's doing?
[16:06] <andyrock> yup
[16:06] <willcooke> got ya
[16:06] <willcooke> hrm
[16:06] <willcooke> yeah
[16:06] <andyrock> in theory the spinner will never be visible
[16:07] <andyrock> because what's going to happen is the following:
[16:07] <andyrock> 1. g-i-s ask snaps the list of snaps to show
[16:07] <andyrock> 2. snapd restarts in the middle of the request
[16:08] <andyrock> 3. g-i-s receives a failure
[16:08] <andyrock> 4. g-i-s try to connect to snapd again
[16:08] <andyrock> 5. not it works
[16:08] <willcooke> s/not/now ?
[16:09] <andyrock> yeah now :D
[16:09] <willcooke> :))
[16:09] <andyrock> 1-5 should be pretty fast
[16:09] <andyrock> but a spinner still makes sense in case it's not fast
[16:10] <willcooke> Should we add "Loading..." or something as well, for cases where its not fast?
[16:12] <Laney> we're trying to avoid a new string
[16:12] <willcooke> fair enough
[16:12] <andyrock> the problem really needs to be fixed in snapd-glib because (I guess) snapd dies after he wrote/send a request to snapd
[16:13] <andyrock> there is some logic to re-send the request if write fails because snapd died but there is no logic to retry if snapd died before/while reading
[16:13] <Laney> sounds worthy of a bug report / trello card
[16:13] <willcooke> andyrock, would you mind opening a bug against snapd-glib so we can get Robert to take a look
[16:13] <willcooke> what L_aney  said
[16:13] <andyrock> yeah I'll do that later
[16:13] <andyrock> let me try to finish the branch asap
[16:14] <willcooke> thanks andyrock, nice work
[16:14] <seb128> indeed
[16:17] <seb128> Trevinho, https://bileto.ubuntu.com/#/ticket/3698 ... the scope upload revert a change which was probably missing from the vcs but is in the ubuntu archive
[16:17] <seb128> -  * Add "X-Ubuntu-Use-Langpack: yes" to debian/control now that this package is
[16:17] <seb128> -    in Universe (LP: #1760435).
[16:17] <ubot5`> Launchpad bug 1760435 in unity-scope-manpages (Ubuntu) "Use Ubuntu language packs for various Unity packages" [Undecided,Fix released] https://launchpad.net/bugs/1760435
[16:17] <seb128> -X-Ubuntu-Use-Langpack: yes
[16:20] <seb128> GunnarHj, did you see bug #1823722 btw?
[16:20] <ubot5`> bug 1823722 in mutter (Ubuntu) "keyboard shortcuts are displayed not translated" [Low,Confirmed] https://launchpad.net/bugs/1823722
[16:24] <seb128> bug #1824497
[16:24] <ubot5`> bug 1824497 in nautilus (Ubuntu) "unable to copy small files with nautilus on cifs mount" [Low,New] https://launchpad.net/bugs/1824497
[16:24] <seb128> ups, sorry, wrong tab
[16:33] <willcooke> seb128, did you see the big map in UEFI or legacy mode?
[16:33] <willcooke> were you in the live session when you saw it
[16:40] <willcooke> seb128, tried both options - it looks "ok" to me I think.  Doesn't look wrong at least, but maybe a little stretched out, nothing that would cause me to think "oooh, that's broken"
[16:42] <GunnarHj> seb128: I can take a look at bug #1823722 this weekend.
[16:42] <ubot5`> bug 1823722 in mutter (Ubuntu) "keyboard shortcuts are displayed not translated" [Low,Confirmed] https://launchpad.net/bugs/1823722
[16:51]  * willcooke -> dinner. bbiab
[16:52] <Trevinho> seb128: ah... sorry I missed the mention. Mh, yeah... wasn't in the vcs. I need to add that and should we do another upload I suppose?
[17:11] <Laney> didn't get to gedit, sorry, might get some time later tho
[17:19] <willcooke> Looks like we're suspending by default now.  I have a feeling we turned that off by default before.  Anyone remember?
[17:19] <willcooke> by which I mean, if you leave the machine alone it's suspending
[17:19] <willcooke> rather than just turning off the screen
[17:20] <willcooke> Maybe I just turned that off before
[17:20] <willcooke> ah, this is when on battery only
[17:24] <andyrock> seb128: https://code.launchpad.net/~azzar1/ubuntu/+source/gnome-initial-setup/+git/gnome-initial-setup/+merge/365966
[17:24] <andyrock> hopefully it's enough
[17:54] <seb128> willcooke, it was on "install only", uefi
[17:54] <seb128> willcooke, I will try again on monday, no worry
[17:54] <seb128> Trevinho, I guess yes...
[17:55] <seb128> willcooke, right, I wonder if that's a requirement from the new energy standards also to do that (suspend on idle on battery)
[17:55] <seb128> well it does make sense on battery imho
[17:55] <seb128> andyrock, great, thx
[17:55] <Trevinho> seb128: ok, there are not many translated strings, but indeed better
[17:55] <Trevinho> i'll prepare it
[17:56] <seb128> Trevinho, well, better and also I don't think the r-t is going to let you revert a change without a solid reason at this point and "it was not commited to the vcs" isn't one
[17:58] <Trevinho> sure
[17:58] <willcooke> seb128, @ battery - yeah, I think it makes sense, once I realised it was only on battery.  Easy to change anyway
[17:58] <Trevinho> seb128: better to use a .1 or jut bumb the ubuntu number?
[17:59] <willcooke> seb128, secure boot on or off?
[18:00] <willcooke> ah ha!  Also "safe graphics mode" appears :)
[18:10] <seb128> indeed
[18:10] <seb128> willcooke, secure boot on
[18:10] <seb128> Trevinho, either is fine
[18:10] <willcooke> seb128, oki, thx.  Does it look ok to you from the photo?
[18:11] <seb128> yes
[18:11] <seb128> I'm doing another install to see if it was a one time thing
[18:11] <willcooke> oki.  Probably the weekend now though? :)
[18:12] <willcooke> (I'm hiding from the kids atm)
[18:12] <seb128> yeah, that and upload gis and then done
[18:12] <seb128> :)
[18:12] <seb128> we already had dinner
[18:12] <seb128> he's going to bed now so I can be back a bit at the computer :)
[18:13] <willcooke> I'm trying to pair an Amazon Fire TV stick with an Echo dot
[18:13] <willcooke> and doing some install testing at the same time
[18:22] <GunnarHj> seb128: Think I fixed the mutter translation issue. (MP)
[18:26] <seb128> GunnarHj, looking, oh nice, it's easier that I though :)
[18:26] <seb128> Trevinho, Laney, https://code.launchpad.net/~gunnarhj/ubuntu/+source/mutter/+git/mutter/+merge/365971 looks like, we should probably have it in for the next upload/SRU
[18:28] <GunnarHj> seb128: I noticed that a full language pack update has just been accomplished. But maybe another delta update can be made before release?
[18:28] <Trevinho> seb128: ok
[18:28] <seb128> GunnarHj, I doubt it's important enough to be worth doing that before release
[18:28] <seb128> it's only keybinding in settings
[18:28] <GunnarHj> seb128: Ok.
[18:28] <seb128> it's not a LTS cycle, we accept a little less polish
[18:28] <seb128> but thanks for carring :)
[18:28] <Trevinho> hopefully 3.32.1 is also coming soon
[18:29] <seb128> right
[18:29] <seb128> g-s upstream is like you Marco
[18:29] <seb128> liking to do things when it suits them :)
[18:29] <Trevinho> late? xD
[18:29] <seb128> schedule? what? who care, enjoy life
[18:29] <seb128> :)
[18:30] <Trevinho> ah, well... You know it's maintained by someone living in Spain for some time now, so....
[18:30] <seb128> worth than the italians right? ;)
[18:30] <Trevinho> quite likely
[18:32] <Trevinho> can't complain this cycle though, so far I was in the defined times :P
[18:33] <seb128> :)
[18:33] <seb128> on the edge but in indeed!
[18:34] <Laney> seb128: If you want to add mutter delta, I'm not the person to talk to. Don't see why that should be delta, but whatever.
[18:35]  * Laney goes away again
[18:35] <seb128> Laney, I don't think it should be a delta?
[18:35] <seb128> never said that?
[18:36] <seb128> oh, you mean it should go on salsa/debian, yeah I'm not arguing against that ... GunnarHj, do you think you can mp to debian too?
[18:36] <seb128> Laney, I meant that the delta seemed to make sense, I didn't even think about whether it was targetting debian or Ubuntu, just thinking about the diff by itself
[18:37] <seb128> sorry if that looked like me being careless or something
[18:38] <seb128> anyway, g-i-s uploaded, time to call it a day (might still look at backlog before going to bed in case there is a problem with that upload or something else)
[18:38] <seb128> andyrock, ^
[18:38] <seb128> enjoy the w.e desktopers!
[18:39] <GunnarHj> seb128: Sure, I can MP to Debian if you like. They probably don't need it since they don't run dh_translations, but OTOH it doesn't hurt them.
[18:40] <seb128> GunnarHj, right, and L_aney is right that we shouldn't add Delta to Ubuntu if we don't need to (I didn't plan to for the record, I was mostly thinking about Disco/SRU at this point which is probably not going to be a sync, but going forward it should go to Debian and be synced)
[18:41] <GunnarHj> seb128: Got it.
[18:41] <seb128> thx again GunnarHj
[18:41] <seb128> have a good w.e :)
[18:41] <GunnarHj> seb128: Same to you.
[18:41] <seb128> thx
[18:57] <andyrock> seb_128 thanks!
[19:00] <willcooke> see you seb128
[19:01] <willcooke> switching off now too.  In London on Monday, might be late online
[19:01] <willcooke> Will be on email etcs
[19:01] <willcooke> night all