[02:44] <jamesh> robert_ancell: do you think there is much chance of convincing niemeyer to consider polkit?
[02:44] <robert_ancell> jamesh, I gave up
[02:45] <robert_ancell> jamesh, I think the current solution is workable. Unfortunately Polkit doesn't fit well into the snap architecture - it's very much designed from the ground up.
[02:45] <robert_ancell> When I patched it the first time there weren't good D-Bus libraries available
[02:46] <jamesh> robert_ancell: in the desktop sprint thread on the forum, I suggested adding this as something the client would have to opt in to
[02:46] <robert_ancell> jamesh, the snapd client?
[02:46] <jamesh> so it wouldn't conflict with any existing use cases
[02:47] <robert_ancell> or snapd itself?
[02:47] <jamesh> yeah.  so the client would send something like "Authorization: polkit" in the request headers
[02:47] <robert_ancell> oh, I see
[02:47] <jamesh> and snapd would only make the polkit CheckAuthorization request in that case.
[02:47] <jamesh> otherwise, the existing logic would run its course.
[02:48] <jamesh> something like this could also be used to determine whether to do interactive polkit auth or not
[02:48] <jamesh> "Authorization: polkit; interactive=1" maybe
[02:48] <robert_ancell> I remember thinking at the time it was first proposed that there would be some ambiguity in snapd if Polkit was available or not. But now I think about it if snap detects that Polkit is there (i.e. checks D-Bus) then it should use it (or any other mechanism) to after it checks for roto
[02:48] <robert_ancell> root
[02:49] <robert_ancell> jamesh, I think that will get shot down because you need both the Macaroon (store credentials) and Polkit.
[02:50] <robert_ancell> I don't agree with the use of the Macaroon for both store credentials and local access, but niemeyer seems to like that idea
[02:50] <jamesh> I think it is crazy that we're relying on access tokens that can be passed between security principals without snapd even noticing
[02:53] <robert_ancell> jamesh, yes
[02:54] <jamesh> and that the command line tool is effectively storing root access credentials in the user's home directory
[02:54] <robert_ancell> jamesh, I think it's worth you continuing to raise these issues. You might have better terminology to describe them
[02:54] <robert_ancell> It's perhaps best to focus on that particular issue and leave the minor issues for now.
[02:55] <robert_ancell> The solution there might be to tie the Macaroon to a user account, but I don't know enough to say if that's sufficient
[05:11] <jamesh> robert_ancell: thinking about it some more, if we ever upgrade to a current version of polkit, it wouldn't be too difficult to write a policy that grants access without a password if the user presents a valid store macaroon
[05:12] <jamesh> since the policies are arbitrary JavaScript functions
[05:53] <oSoMoN> good morning desktoppers!
[06:11] <didrocks> good morning
[07:03] <duflu> TheMuso, hello. May I join ~ubuntu-audio-dev ?
[07:03] <jibel> morning
[07:04] <duflu> Morning oSoMoN, didrocks, jibel
[07:05] <didrocks> hey duflu, morning jibel
[07:06] <didrocks> jibel: any thoughts on checkbox-converged? is it even used nowdays? (by you or certification team?)
[07:06] <didrocks> it's bringing up the whole Qt/QML stack on the iso for it
[07:06] <duflu> and morning seb128
[07:07] <duflu> and other random Europeans
[07:07] <seb128> good morning desktopers
[07:07] <seb128> hey duflu
[07:11] <jibel> didrocks, no idea if it's still used for anything. I'll ask jerry or chris
[07:13] <didrocks> jibel: thanks! Keep me posted :)
[07:29] <duflu> jibel, unless you want to upset him; "Gerry" :)
[07:34] <pitti> mvo: good morning! thanks for insisting on https://github.com/cockpit-project/cockpit/pull/7131, updated now; mind having another look?
[07:35] <pitti> err
[07:35] <pitti> mvo: sorry, I meant our mvo (we have one too!)
[07:35] <pitti> mvo: so... Good morning! wie gehts? :-)
[07:36] <didrocks> sounds like he has more characters in his nickname, has he got promoted? :)
[07:36]  * pitti dit bonjour aux amis français
[07:36]  * didrocks dit bonjour également à pitti
[07:37] <pitti> didrocks: no, Michael Vogt and Marius Vollmer are both "mvo"; I thought I was in the cockpit channel
[07:38] <didrocks> pitti: oh, someone using a different nickname between IRC and github? (his nickname there is mvollmer apparently), scandalous! :)
[07:39] <pitti> didrocks: heh yes, he's mvollmer on freenode, but mvo on internal IRC
[07:40] <didrocks> sounds like a trap just targeted at you! :)
[07:41] <andyrock> good morning
[07:41] <didrocks> hey andyrock
[07:43] <duflu> koza, Debian has caught up as of 2 days ago, and is apparently using their preferred DEP-14 layout. Maybe we should switch to that... https://anonscm.debian.org/git/pkg-bluetooth/bluez.git/
[07:44] <didrocks> +1
[07:45] <seb128> hey andyrock
[07:45] <seb128> salut pitti, comment ça va ?
[07:46] <pitti> seb128: ça va bien, merci ! la dernière semaine à Karlsruhe avec mon équipe était grande
[07:46] <jibel> duflu, I don't understand, why would I upset him?
[07:47] <seb128> pitti, ah c'est bien pour toi alors !
[07:47] <jibel> bonjour pitti
[07:47] <pitti> seb128: we got a lot of stuff done, and finished the week with an electrical go-kart race
[07:47] <duflu> jibel, it's Gerry as in Gerrard :)
[07:47] <pitti> bonjour jibel, ça va ?
[07:47] <duflu> I think mainly Americans assume "Jerry"
[07:48] <jibel> duflu, no it's Jerry from CE. We are not talking about the same person
[07:48] <duflu> jibel, Oh... OK. You mentioned Qt :)
[07:48] <jibel> yeah np :)
[07:48] <seb128> didrocks, do you think we should go through seed changes and refresh the packages once, or just tweak&rebuild?
[07:49] <jibel> pitti, ça va bien, happy to work on desktop again :)
[07:49] <seb128> didrocks, also I was checking with will for a11y-profile-manager yesterday, you think as well that it's fine to nuke it? (you removed unity-accessibility-profiles but there is a gnome variant which we could swap for if we wanted to keep it)
[07:50] <didrocks> seb128: I was thinking something a little bit more incremental, in case we notice huge regression on an ISO (we have time until FF), wdyt?
[07:51] <seb128> didrocks, wfm, I had changes I wanted to do and that would have done if I knew you were going to do an upload
[07:51] <pitti> jibel: nice! so you're becoming a gnome guy at last? :)
[07:51] <seb128> anyway no big deal, I should probably just have stacked in the vcs
[07:51] <seb128> didrocks, let me know before your do another upload, just in case I want to sneak those in ;-)
[07:51] <didrocks> seb128: sorry, yeah, I bzr update first to see if anyone stacked anything, but I would really be in favor of small increments in case something goes wrong
[07:51] <didrocks> sure :)
[07:51] <didrocks> seb128: next one is checkbox-converged for the Qt5 stack IMHO
[07:52] <seb128> didrocks, and for a11y-profile-manager you think it's useless?
[07:52] <didrocks> once we know from jibel is good for removal
[07:52] <seb128> I don't know enough about it to be sure
[07:52] <seb128> it's not unity specific
[07:52] <seb128> and there is a gnome profile/binary
[07:52] <seb128> but we don't have a maintainer for it and I'm not sure what it brings
[07:53] <didrocks> I did remove the binary packages, one was an indicator, the other for unity. and yeah, for the remaining profile, without maintainer… I would think it's better to take what upstream brings us on that front and retweak
[07:53] <seb128> k, let's call it a decision, makes things easier, I was investigating on that yesterday
[07:53] <seb128> if somebody ask I tell them you tool the decision :p
[07:53] <didrocks> heh, sure :)
[07:54] <didrocks> just went the pragmatic approach
[07:54] <didrocks> I didn't remove the rest as I was less sure
[07:54] <seb128> right, we can iterate
[07:54] <seb128> we are not going to see the status until gdm is in anyway
[07:54] <didrocks> eactly
[07:54] <seb128> or rather unity-greeter out
[07:54] <didrocks> exactly*
[07:54] <didrocks> yeah, quite equivalent :)
[07:55] <seb128> I wonder if it's about time where we nag the security team for a pre-emptive ack to unblock us
[07:55] <didrocks> I would be in favor of that
[07:55] <seb128> like ack with the understanding that we are going to address their review issues when they get the review done
[07:55] <didrocks> as we did for big part of the stack
[07:56] <seb128> k, let's talk to them about that once they are up
[07:56] <didrocks> good plan
[07:57] <seb128> didrocks, do you have any idea how alsa-base get on the iso?
[07:57] <seb128> I think I'm missing something obvious
[07:57] <didrocks> seb128: I'm surprise, it's not from the manifest
[07:57] <didrocks> let me start yesterday's iso
[07:58] <didrocks> (manifest of germinate-outputs)
[08:01] <willcooke> morning
[08:02] <seb128> hey willcooke, how are you today?
[08:02] <jamesh> hi willcooke
[08:02] <seb128> hey jamesh
[08:05] <jamesh> I'm hopeful that we'll be able to convince the snappy folks to add polkit support to snapd: https://forum.snapcraft.io/t/should-we-use-polkit-for-local-auth/1206
[08:05] <jamesh> If we manage that, the user experience for gnome-software should improve
[08:06] <seb128> Gustavo doesn't seem close from convinced yet
[08:06] <seb128> let's see if the new round of arguments from robert and you is enough
[08:06] <jamesh> yep, but I'm hopeful I can change his mind
[08:06] <didrocks> hey willcooke
[08:09] <seb128> jamesh, great, I hope it works out :-)
[08:10] <jamesh> seb128: one thing I don't like about the current system is that it is the equivalent of storing the root password in a file in the user's home directory
[08:13] <seb128> yeah
[08:18] <didrocks> seb128: found it at lp:~ubuntu-core-dev/ubuntu-seeds/platform.artful
[08:18] <didrocks> desktop-common: * alsa-base # needed for proper hardware detection (hotplug/blacklist.d, modprobe.d)
[08:27] <seb128> didrocks, oh, platform seed, thanks
[08:28] <didrocks> seb128: sounds like we shouldn't remove it though? But I don't know enough about alsa
[08:29] <seb128> didrocks, not sure, jbicha asked on some trello card about it, Debian removed that package as "ROM; No longer needed, obsolete"
[08:30] <seb128> not sure who would have a better clue though
[08:30] <seb128> pitti, do you have any idea if alsa-base is something that might still have some use for some users/configs?
[08:32] <pitti> seb128: I don't know for sure; but the modprobe.d scripts might still be relevant
[08:32] <pitti> and the apport hook of course
[08:37] <koza> duflu, interesiting, reading
[08:38] <duflu> koza, also http://dep.debian.net/deps/dep14/
[08:38] <didrocks> seb128: sounds weird to me to have ubuntu-image on the iso, wdyt?
[08:38] <duflu> (seems Ubuntu's pulseaudio code is already kept in debian git)
[08:40] <didrocks> (dep of livecd-rootfs)
[08:43] <koza> duflu, thanks, good stuff
[08:48] <seb128> pitti, thanks
[08:52] <jibel> didrocks, I don't see ubuntu-image on the iso. On which image do you see it?
[08:53] <seb128> didrocks, weird indeed, do you have the commit/reason why it was added?
[08:54] <didrocks> jibel: I guess it's only in the live
[08:54] <didrocks> ah, it's not on the live
[08:55] <didrocks> interesting, it's in the all germinate output though
[08:55] <didrocks> I don't know which log file we should base on thus
[08:55] <didrocks> http://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu.artful/desktop only contains the desktop seed (and not desktop-common and such)
[08:56] <didrocks> http://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu.artful/all has more than what we ship
[08:56] <didrocks> unsure there is a file corresponding to the manifest or we need to look at the manifest, and then dig into those file to find what's pulling something in
[08:56] <didrocks> (all is then clearly "all seeds"
[08:56] <didrocks> )
[09:11] <didrocks> talking about spring/summer cleaning: "Source only movements to main": unity
[09:11] <didrocks> seb128: any idea why? ^
[09:12]  * didrocks wonders if we have one binary package from unity in main
[09:12]  * didrocks checks
[09:14] <didrocks> libunity-core-6.0-9
[09:14] <didrocks> oh unity-schemas as well is still in main
[09:14] <didrocks> even unity-services
[09:14] <didrocks> hum
[09:14] <didrocks> let's see why
[09:16] <didrocks> none are on the iso, let's try to demote them and see what's trying to pull them in (I guess something in supported)?
[09:25] <seb128> didrocks, no idea, yeah, let's see
[09:25] <didrocks> I just checked all rdepends, nothing in main (for libunity-core, schemas, services…)
[09:25] <didrocks> no build-rdepends either for the -dev
[09:25] <didrocks> so yeah, let's go empiric
[09:26] <didrocks> (done, let's look at next publisher cycle)
[09:27] <didrocks> oh nice, we got the +1 for removing checkbox-converged from the iso
[09:27] <seb128> where?
[09:27] <didrocks> email from the cert team (jibel sent one)
[09:27] <didrocks> should we kick off a build first with the current changes first?
[09:27] <didrocks> to have a checkpoint, wdyt?
[09:27] <seb128> k, I guess I was not Cced
[09:27]  * didrocks looks
[09:28] <seb128> I would remove checkbox while we are at it
[09:28] <didrocks> nope
[09:28] <seb128> I think that's likely going to be the biggest impact
[09:28] <didrocks> yeah
[09:28] <didrocks> so, no iso first?
[09:28] <didrocks> we do that in the some round?
[09:28] <seb128> as you prefer
[09:28] <didrocks> (I'm fine with it)
[09:28] <seb128> I would drop checkbox
[09:28] <didrocks> ok
[09:28] <seb128> and trigger an iso build later
[09:28] <seb128> or even wait tomorrow
[09:29] <seb128> depending how eager you are to see the result
[09:29] <didrocks> anything else you want to change in the seed?
[09:29] <seb128> let me have a look
[09:29] <didrocks> as you told you had waiting changes :)
[09:29] <didrocks> yep
[09:30] <seb128> I was unsure about adium-theme-ubuntu
[09:30] <seb128> well, it's not coming from the seed anyway
[09:30] <seb128> so let's ignore that
[09:30]  * seb128 reads his tomboy note
[09:31] <didrocks> I have no opinion on the empathy <-> adium, but I think it's not quite right to install things preemtively for a small part of our audience
[09:32] <didrocks> (at worst, we should tweak the empathy deps/recommends)
[09:32] <seb128> yeah
[09:32] <seb128> let's keep those for the next round
[09:32] <seb128> in fact most of mines are depends from other packages and not seed
[09:32] <seb128> the seed ones are alsa-base which I'm unsure about
[09:32] <seb128> and app-install-data-partner which I'm also unsure about
[09:32] <jibel> didrocks, so we have a GO to remove checkbox-converged
[09:32] <didrocks> jibel: yeah, we are discussing it here ^ it's nice! :)
[09:33] <jibel> well, what you said higher :)
[09:33] <didrocks> :)
[09:33] <didrocks> seb128: yeah unsure if alsa-base is a safe one…
[09:33] <seb128> didrocks, the other ones I had on my lsit you handled in your previous upload
[09:33] <seb128> so it's good
[09:33] <seb128> thanks for checking :-)
[09:34] <didrocks> seb128: hum, /usr/share/app-install/channels/xenial-partner.eula is empty, let me check artful
[09:34] <seb128> also I'm unsure where that's being used
[09:34] <seb128> was it a software-center thing?
[09:35] <seb128> but better to check with L_aney, he knows better those stack I think
[09:35] <didrocks> it was a way to type/search for a package, get it even if you didn't add the partner repo yet IIRC
[09:35] <didrocks> seb128: mind adding it to the trello card so that we check with Lane_y?
[09:36] <seb128> didrocks, done
[09:36] <didrocks> thx!
[09:37] <didrocks> uploading the seed with checkbox-converged remove
[09:37] <seb128> thanks
[09:37] <didrocks> I guess that should remove a lot of qml*
[09:37] <didrocks> not Qt5 though
[09:37] <didrocks> (hud/greeter)
[09:37] <seb128> right
[09:40] <didrocks> ah, we start to see some movement thanks to the seed changes: http://people.canonical.com/~ubuntu-archive/component-mismatches.html
[09:41] <didrocks> (we'll need to discuss whoopsie at some point)
[09:42] <didrocks> can't wait to see the greeter off, pulling indicators (and thus, the hud), then ubuntu-app-launch, then up to some zeitgeist libs…
[09:43] <didrocks> (that's the reason why I don't demote binary only changes, so that we remember about those source/bin packages which are still in main and shouldn't)
[09:48] <seb128> well demoting binaries is often done in case where the source is to stay in main
[09:49] <seb128> is whoopsie having a standalone config dialog?
[09:52] <didrocks> no, it was part of activity-log-manager
[09:52] <didrocks> whoopsie-preferences is only a dbus service
[09:54] <seb128> right
[10:21] <oSoMoN> oh, new battery icons, nice!
[10:21] <oSoMoN> thanks Daniel
[10:31]  * willcooke upgrades
[10:31] <willcooke> woo!
[10:31] <willcooke> humm, looks ok at the login screen, but still squished in the session
[10:32] <willcooke> oSoMoN, do you see the same? ^
[10:32] <oSoMoN> willcooke, I didn’t pay attention to it until now, so dunno at the login screen, but it looks good in my session
[10:34] <oSoMoN> willcooke, this is how it looks here: http://people.canonical.com/~osomon/battery.png
[10:34] <willcooke> kk, same here
[10:34] <willcooke> but different on the login screen
[10:35] <willcooke> I'll see what's going on and log a bug
[10:35] <oSoMoN> dunno if it’s supposed to look different, but it’s a net improvement over what there was before
[10:35] <willcooke> that icon looks a bit horizontally squashed to me
[10:35] <willcooke> :)
[10:35] <willcooke> humm, another bug perhaps...
[10:35] <willcooke> Plug in the power, get the charging battery icon, unplug the power - still have the charging icon
[10:36] <didrocks> willcooke: login screen, as in using gdm ofc?
[10:37] <willcooke> ahh, yes, I'm still on lightdm here
[10:37] <willcooke> didrocks, ^
[10:39] <didrocks> makes sense IMHO, may not be a symbolic icon
[11:16]  * didrocks demotes ubuntu-defaults-builder (sorry pitti) and removes it from supported seed, as it's what pulling unity source (due to a dep on unity-common which is now a virtual package)
[11:17] <didrocks> interesting side-effect about Provides:. I bet the package can't be built anyway (it was using unity-common for the schema)
[11:17] <didrocks> with that, I think unity source package won't be willing again to be pulled to main
[11:38] <pitti> didrocks: oh, yes please -- this hasn't really been supported for ages
[12:02] <didrocks> waow, effect of removing unity demotion + latest changes: http://people.canonical.com/~ubuntu-archive/component-mismatches.html
[12:02]  * didrocks demotes more and more
[12:02] <didrocks> this is demotion day
[12:03] <didrocks> and ubuntu-ui-toolkit is on the list \o/
[12:21] <muktupavels> Trevinho: https://code.launchpad.net/~muktupavels/compiz/motif-wm-hints/+merge/326777
[12:32] <Trevinho> muktupavels, flexiondotorg: is that somethiong we want in xenial too?
[12:33] <Trevinho> muktupavels: so bad I did a landing yesterday :-(
[12:33] <muktupavels> trevinho: https://askubuntu.com/questions/928226/xprop-fails-to-undecorate-window
[12:34] <Trevinho> muktupavels: what is the standard by the way?
[12:34] <muktupavels> ?
[12:36] <Trevinho> muktupavels: also why not using XA_CARDINAL instead of anytype?
[12:36] <muktupavels> Trevinho: I used it because it is used in metacity
[12:37] <Trevinho> mh, I see... ok fine
[12:37] <Trevinho> muktupavels: can you please open a bug?
[12:38] <muktupavels> Trevinho: ok
[12:38] <Trevinho> ta
[12:50] <jbicha> didrocks: Independence Day ;)
[12:51] <mitya57> didrocks, thanks for checkbox-converged and ui-toolkit demotion! :)
[12:51] <didrocks> jbicha: ahah, good matching :)
[12:51] <didrocks> mitya57: yw!
[12:58]  * willcooke offers jbicha a cup of tea
[12:58] <muktupavels> Trevinho: https://bugs.launchpad.net/compiz/+bug/1702297
[12:58] <Trevinho> muktupavels: thanks
[12:58] <Trevinho> muktupavels: sru compliant, awesome
[12:59] <didrocks> willcooke: would you dare offering milk/cream with it though? :p
[12:59] <jbicha> willcooke: uh, thanks I guess ;)
[12:59] <willcooke> :D
[13:06] <GunnarHj> Hi willcooke, I asked about an ISO size matter the other day:
[13:06] <GunnarHj> https://lists.ubuntu.com/archives/ubuntu-desktop/2017-June/005028.html
[13:06] <GunnarHj> jbicha, who has reviewed, deferred it to the team. Would be great if a decision could be made on today's meeting ( off meeting is fine for me too ;) ).
[13:10] <seb128> lol
[13:11] <seb128> hey GunnarHj
[13:11] <GunnarHj> seb128: Hi Seb!
[13:11] <didrocks> I think no decision should be made before we finish the transition
[13:12] <didrocks> (meaning gdm on the iso, no more big cleanup possible)
[13:12] <didrocks> so that we know where we stand with
[13:12] <seb128> didrocks, it's a bit orthogonal discussions though?
[13:12] <seb128> I mean it's going to be "is it ok to take a 90M hit to get those packages"
[13:13] <didrocks> well, depends if we want to go back to a reasonable iso size
[13:13] <didrocks> yeah, that as well
[13:13] <didrocks> I guess we can talk about it right now anyway, I doubt other than the ones present are interested in it, wdyt?
[13:13] <willcooke> +1 talk now works for me
[13:13] <seb128> we are not going to fix on a 700M cd, so being 1.5 instead or 1.6 or 1.7 instead of 1.8 isn't changing the outcome much I think
[13:14] <didrocks> (a little bit ironic we just, we just removed 60+ packages of the iso)
[13:14] <seb128> now seems fine to me
[13:14] <seb128> 60Mb or packages?
[13:14] <seb128> or 60 binaries?
[13:14] <willcooke> so, taking the amd64 iso as an example:  we're at 1.5GB
[13:15] <didrocks> seb128: binaries
[13:15] <seb128> k
[13:15] <willcooke> Trusty was 1GB
[13:15] <seb128> warty was under 600M :p
[13:16] <willcooke> So we've already grown 500MB in the last 3 years, right?
[13:16] <jbicha> seb128: you really should upgrade soon ;)
[13:16] <jbicha> (lol)
[13:16] <seb128> haha
[13:16] <didrocks> jbicha: shhh, he has still 2 menu entries in gnome-panel, don't shock him with the 3rd one upgrading to hoary :p
[13:17] <willcooke> didrocks, any guesses as to where we'll be when the transition is done?
[13:17] <willcooke> is this a net zero increase (i.e. we dropped the same as we'd add)
[13:17] <didrocks> willcooke: back to our discussion, depends on the security team and kenvandine to be done with lightdm -> gdm
[13:17] <didrocks> then, add a week for the final cleaning
[13:18] <jbicha> I don't think demoting lightdm will save us much iso space, but it will make the manifest make more sense without indicator packages
[13:18] <seb128> willcooke, I would guess we win some space but not so much, still over 1.3G
[13:18] <didrocks> jbicha: it will
[13:18] <didrocks> jbicha: pulling indicator, hence qt5, hence ubuntu-app-launch, hence zeitgeist
[13:18] <jbicha> oh ok
[13:18] <seb128> the biggest win is probably when we get qt out the iso
[13:19] <didrocks> not enormous, but will still count :)
[13:19] <jbicha> nautilus and totem-plugins still depend on zg
[13:19] <didrocks> yeah, I guess we can drop them or handling them smartly
[13:20] <seb128> discussion is drifting
[13:20] <didrocks> but that's why we need some time to do a second round of cleaning, once the manifest will be easier to read :)
[13:20] <didrocks> anyway
[13:20] <GunnarHj> One problem with keeping things like this pending is that it makes progress of related work harder.
[13:20] <willcooke> either way, I think an extra 60MB is ok
[13:20] <didrocks> back to language, yeah
[13:20] <didrocks> did anyone test the additional size?
[13:20] <jbicha> I just have to figure out how to get tracker in without seb noticing ;)
[13:20] <willcooke> :D
[13:20] <didrocks> that's round 0 when making this kind of proposal
[13:20] <didrocks> jbicha: ahah :p
[13:21] <seb128> didrocks, GunnarHj has numbers in his emails
[13:21] <didrocks> ah, not the MP, numbers
[13:21]  * didrocks reopen the email
[13:21] <seb128> but it's installed sizes
[13:21] <seb128> so not iso
[13:21] <didrocks> GunnarHj: do you have the deb size?
[13:22] <didrocks> as we approximate deb size with iso size
[13:22] <jbicha> didrocks: I asked jibel about that last week and he said installed-size was a better estimate?
[13:22] <didrocks> but yeah, I think we should stick to the principle I raised in that email a year and half ago, meaning: offline installation possible, without any further question
[13:23] <seb128> those debs at 10M each for well translated languages
[13:23] <seb128> for 7 languages = 70M
[13:23] <didrocks> jbicha: hum? I'm surprised, we always used deb size as it's squashfs compression, so similar to ar
[13:23] <seb128> gnome-getting-started-docs*
[13:23] <seb128> it's the same order anyway
[13:23] <seb128> 70M deb vs 80M installed
[13:24] <didrocks> sounds ok to me
[13:24] <jbicha> I guess those videos are already compressed and those are the biggest part of updating the proposal?
[13:24] <didrocks> the video is only present once, correct?
[13:24] <didrocks> then + subtitle
[13:25]  * didrocks wget
[13:26] <jbicha> the video itself can be translated https://help.gnome.org/users/gnome-help/stable/figures/gnome-task-switching.webm.fr
[13:27] <didrocks> indeed, some are even
[13:28] <didrocks> that's different from what I saw on latest fedora's on bochecha's latptop
[13:28] <didrocks> but ok, so the size is coming from the videos
[13:28] <seb128> which is why I guess those locales are taking 10M deb
[13:28] <seb128> where others are hundred of kbs
[13:28] <GunnarHj> seb128: So it is.
[13:28] <didrocks> 11M on the video directory
[13:29] <didrocks> (french)
[13:29] <seb128> is that video that useful?
[13:29] <didrocks> anyway, I think it makes sense to add them for the languages we claim complete default support.
[13:29] <didrocks> seb128: fedora starts the page presenting them by default
[13:29] <seb128> what page?
[13:29] <didrocks> like showing how to reach for the dash
[13:29] <didrocks> gnome-help with the introduction to G-S
[13:29] <seb128> ah
[13:30] <jbicha> seb128: when GNOME Initial Setup completes, it opens the Getting Started page with the videos right there
[13:30] <seb128> do they auto open yelp on first loggin?
[13:30] <didrocks> however, *if* we tweak the default experience via extensions (which isn't discussed yet), we may have some discrepancies there
[13:30] <didrocks> seb128: yeah, first user login after install
[13:30] <seb128> I see
[13:30] <didrocks> only 3 videos are shown though
[13:30] <seb128> good point about extensions
[13:30] <didrocks> then, you have to go to subpages to see others
[13:30] <jbicha> I'm hoping jackpot_51 will send his email to the list this week about adding Initial Setup (I pinged him a couple days ago but it's holiday today)
[13:36] <seb128> anyway, going back to the topic, I'm a bit torned
[13:36] <seb128> 100M is not a trivial hit for the iso
[13:36] <seb128> it's easy to dismiss medium-sized addition like that
[13:36] <seb128> but you do that a few time and your iso is 1.7G instead of 1.1G and I think it has an impact
[13:37] <willcooke> 1.5GB seems like a good max. size to me
[13:37] <seb128> slows down downloads, installs, has cost on mirrors, etc
[13:37] <willcooke> so if it's net cost zero - +1
[13:37] <seb128> +1 for me as well if we win enough to make for the cost of the suggestion addition
[13:37] <seb128> -0.3 otherwise
[13:37] <willcooke> :D
[13:37] <didrocks> (mod(2))
[13:38] <seb128> I'm in favor of having the languages install work offline and without post install nagging though
[13:39] <seb128> so if we are over I might suggest we do something about the video
[13:39] <seb128> maybe re-encode at lower definition
[13:39] <willcooke> what codec does it use?  x264?
[13:39] <seb128> I wonder if we could have a look at re-encoding and how much we would trade off on size vs quality
[13:39] <didrocks> webm
[13:39] <willcooke> kk
[13:39] <GunnarHj> seb128: That aspect is even more important now, when we no longer will have language-selector-gnome to get the rest....
[13:39] <didrocks> would be hard to get better compression/size rate
[13:40] <seb128> well, we could lower quality or resolution
[13:40] <seb128> maybe
[13:40] <didrocks> 854 x 480, it's not much already :/
[13:40] <seb128> I didn't look at it
[13:40] <didrocks> and using the On2 extension
[13:40] <willcooke> didrocks, webm vp8 or 9? Do you know?
[13:40] <didrocks> worth a try, but unsure how much smaller they can be
[13:40] <didrocks> vp8
[13:41] <didrocks> could try with 9
[13:41] <seb128> 10M is not that big for a video I guess
[13:41]  * willcooke fires up handbrake
[13:41] <didrocks> it's 10M for ~5:30min
[13:41] <seb128> GunnarHj, hold on, why don't we have language-selector-gnome?
[13:42] <GunnarHj> seb128: That was my assumption. Since g-c-c includes language handling.
[13:42] <jbicha> we just need to fix LP: #1631750 first
[13:42] <seb128> that's a topic we didn't really look at yet
[13:42] <didrocks> willcooke: compress the french ones please, it's the deciding factor as you know :p
[13:42] <seb128> we could decide to disable that panel
[13:42] <seb128> or improve it
[13:42] <seb128> or have both
[13:43] <willcooke> didrocks, mais oui
[13:43] <GunnarHj> seb128, jbicha: Indeed there are issues that must be resolved. Maybe I jumped at conclusion.
[13:44] <seb128> GunnarHj, having main languages complete on the iso isn't good enough/a justification for not having support for other locales
[13:44] <seb128> so we need to fix the langpack installation situation in any case
[13:45] <GunnarHj> seb128: Very true. So a possible dropping of language-selector-gnome will need to be carefully considered anyway.
[13:45] <seb128> right
[13:45] <seb128> jbicha, btw did you see my comment yesterday about -faces?
[13:46] <seb128> oSoMoN, I played a bit with libreoffice 5.3.4 snap, works nicely, well done!
[13:46] <didrocks> I don't feel we came to the bottom on this TBH, should we separate the -frami discussion?
[13:46] <seb128> didrocks, -frami?
[13:47] <seb128> video size?
[13:47] <didrocks> seb128: top part of the email
[13:47] <didrocks> there are 2 things:
[13:47] <didrocks> - dictionary for -de
[13:47] <didrocks> - videos/welcoming thing
[13:47] <didrocks> description of the -frami ones are:
[13:47] <seb128> ah, -frami are the de dicts
[13:47] <didrocks>  This package contains a enhanced version by Franz Michael Baumann with
[13:47] <didrocks>  some words missing in the base dictionary or not (yet) belonging to the
[13:47] <didrocks>  "core" German words.
[13:48] <seb128> GunnarHj, do you know why those dicts are so much bigger?
[13:48] <jbicha> seb128: I guess we should so we can drop unity-control-center source from main
[13:49] <seb128> jbicha, k, I was mostly asking you in case you had objections to add a binary to g-c-c
[13:49] <didrocks> +1 (that's the last thing keeping u-c-c in main AFAIK)
[13:49] <seb128> like it's extra divergence from Debian
[13:49] <GunnarHj> language-selector has pulled -frami for several cycles, since it's my understanding that German users prefer it. No, I can't tell offhand why it's so much bigger.
[13:50] <didrocks> GunnarHj: a *lot* of new words :p Ok, maybe that was my bad when seeding the dicts for -de and I didn't notice the difference
[13:50] <jbicha> seb128: we already diverge there because we can't have both -control-centers install the same files so it's ok with me
[13:50] <seb128> jbicha, ok, I'm going to do those  changes then
[13:50] <seb128> so we can demote u-c-c
[13:50] <jbicha> thanks
[13:50] <seb128> didrocks, ^ fyi
[13:50] <didrocks> seb128: yeah, looks good, want me to deal with this?
[13:51] <seb128> didrocks, no, it's fine, I started yesterday with the packaging changes
[13:51] <didrocks> good :)
[13:51] <seb128> but thanks for asking :-)
[13:51] <seb128> so going back to the iso topic
[13:51] <didrocks> seb128: I didn't demote the other binaries as a reminder for this
[13:51] <didrocks> (from u-c-c)
[13:51] <seb128> good
[13:51] <seb128> thanks
[13:52] <didrocks> so, shipping the -frami ones? I don't have any opinion, just that we should fix the seed or language-selector
[13:52] <seb128> I don't feel like arguing against what german teams though was best for their locale
[13:52] <seb128> so +1 for that even if it's a small size hit
[13:53] <didrocks> agreed
[13:53] <seb128> good, seems we have one decision
[13:53] <didrocks> and now… videos! :)
[13:53] <seb128> then for the gnome documentation
[13:53] <seb128> I think the offline install/popup-less experience is worth it
[13:53] <seb128> so we should include what is needed
[13:54] <seb128> but then we should maybe look at what we can do to spare some size
[13:54] <seb128> like I don't know how much we need those videos on the iso
[13:55] <seb128> especially if we end up having a dock which is different from what the video describes
[13:55] <jbicha> without language-selector-gnome, I don't think we'd have a popup
[13:55] <didrocks> the video doesn't invalide the dash to dock, but yeah, the workflow would be different from what we may want to promote
[13:56] <jbicha> GNOME Software can do langpack stuff but it'll need a bunch of work there LP: #1678670
[13:56] <seb128> jbicha, it feels like "nothing is going to prompt you to install support for your locale" which is a regression we need to fix
[13:56] <seb128> it's not acceptable for not-installed-by-default locales to not prompt the users
[13:57] <jbicha> seb128: I believe it will install the support when you choose the locale in gnome-control-center
[13:57] <seb128> it's just resulting to non translated desktops for those users
[13:57] <jbicha> it should work in Ubuntu GNOME 16.04 (packagekit 1.0 regressed that)
[13:57] <seb128> jbicha, then you expect users to open g-c-c and navigate it in a language they don't understand
[13:57] <seb128> which has some issues
[13:57] <jbicha> hmm?
[13:57] <seb128> - they are not going to know they can do that
[13:58] <GunnarHj> jbicha: Only newly installed languages. Languages which were incompletely installed by the installer won't be prompted for additions, if I understand it correctly.
[13:58] <seb128> - they might not find it
[13:58] <seb128> - they might not understand the language of the UI to get where they need
[13:58] <jbicha> how are they going to set their computer to a different locale?
[13:58] <seb128> "different"?
[13:58] <seb128> you select your language in ubiquity
[13:58] <seb128> if you do an offline greek install
[13:58] <seb128> then reboot
[13:59] <seb128> and connect to wifi
[13:59] <jbicha> ok, yes I don't think GNOME handles that very well
[13:59] <seb128> with language-selector your get prompted to install the support for your locale
[14:00] <jbicha> we could fix GNOME Software to do that, or we could keep that part of language-selector-gnome
[14:00] <seb128> right
[14:00] <seb128> I'm going to create a card about that
[14:00] <jbicha> but ideally we wouldn't have its control-center panel since the GNOME ones works fine
[14:00] <seb128> indeed
[14:01] <didrocks> dialog + opening g-c-c panel otherwise? (but it's work)
[14:01] <seb128> g-c-c panel doesn't know about langpacks though
[14:01] <seb128> it has no UI to communicate that a language is configured but misses debs to work
[14:01] <seb128> afaik
[14:02] <jbicha> seb128: it might in 16.04?
[14:02] <seb128> we are probably going to need work on that panel anyway
[14:02] <jbicha> I don't know
[14:02] <seb128> needs testing
[14:02] <seb128> I'm going to create a card to investigate the topic
[14:02] <jbicha> the panel is broken right now :(
[14:02] <seb128> right
[14:03] <GunnarHj> seb128: Please let me know where that card is. I'm a bit interested. :)
[14:03] <seb128> we already have a card in the trello board about that
[14:03] <seb128> GunnarHj, the url of the trello board is in the topic
[14:03] <didrocks> GunnarHj: on your MP, you should do something like that rather than duplicating the package names: http://paste.ubuntu.com/25018466/
[14:03] <didrocks> GunnarHj: I did spent quite some time to get those loops working correctly to avoid all those duplication, per language, so feel free to continue on that path please ;)
[14:04] <didrocks> (I can add that as a reminder on the MP)
[14:05] <GunnarHj> seb128: Thanks, I'll take a look at the trello board later.
[14:06] <seb128> we covered quite some topics now
[14:06] <seb128> didrocks, what's your conclusion on the iso size/languages support suggested changes?
[14:06] <oSoMoN> seb128, ack, glad to know that you didn’t find any obvious issue with it :) let’s see if my call for testing gets us some useful feedback
[14:06] <seb128> willcooke, ^ yours?
[14:06] <GunnarHj> didrocks: Thanks for the tip. I did use that technique for some of the packages, but not all.. Will take another look.
[14:06] <didrocks> GunnarHj: just wrote a reminder :)
[14:07] <didrocks> seb128: well, -frami is a no brainer. I'm with you on the video, concerned about size AND consistency if we add extensions
[14:07] <didrocks> sounds like Will is trying to reencode with vp9
[14:07] <willcooke> nearly done
[14:07] <didrocks> let's see what that gives
[14:07] <willcooke> it's smaller
[14:07] <willcooke> one sec
[14:08] <didrocks> as long as it's not bigger on the inside… :)
[14:08] <seb128> didrocks, I see what you did there
[14:08] <seb128> :p
[14:08] <didrocks> ;)
[14:12] <seb128> jbicha, btw do you plan to push forward on some of those suggested additions to the default install? the discussions seem to have stalled
[14:13] <seb128> oSoMoN, btw did you get any reply for kernel team about the issue that hits the libreoffice i386 builds?
[14:15] <jbicha> seb128: yes, it's in my backlog so it may take some time before it's done
[14:17] <didrocks> so, the iso jibel kicked after the removal of quite some packages still boot \o/
[14:17] <seb128> jbicha, no worry, I just wanted to check and to make sure you know that the questions on the list were not pushing against having some in, we just need to make sure we look at them properly before integrating them
[14:17] <didrocks> (not that much of a surprise TBH ;))
[14:18] <willcooke> didrocks, seb128 - vp9 is approx 1/2 the size
[14:19] <willcooke> looks the same quality to me
[14:19] <seb128> that's a good win
[14:19] <willcooke> on a very quick inspection
[14:19] <didrocks> waow
[14:19] <didrocks> totem opens them without any additional codec install?
[14:20] <willcooke> http://paste.ubuntu.com/25018555/
[14:20] <didrocks> looks promising!
[14:20] <willcooke> didrocks, works here, but I need to test in a virgin machine
[14:20] <didrocks> willcooke: you may have your contribution to upstream :)
[14:20] <jbicha> willcooke: https://git.gnome.org/browse/gnome-getting-started-docs/tree/animation (specifically line 39 of gnomerender.py)
[14:21] <jbicha> that directory is not shipped in the tarball but I'm thinking that maybe it should be (as "real" source)
[14:22] <seb128> didrocks, iso went down by 22M today, a good start
[14:23] <didrocks> yep! :)
[14:23] <seb128> and hud is out
[14:23] <didrocks> seb128: I know, I demoted quite some packages while you were away (the component-mismatch list was long)
[14:23] <didrocks> and unity source isn't in main anymore as well, which was the "main" motivation
[14:23] <seb128> good work!
[14:24] <didrocks> thx
[14:24] <didrocks> jbicha: I guess having blender in main just for rendering the videos would be overkill for most distros :p
[14:25] <jbicha> didrocks: build-dependencies don't have to be in main :)
[14:25] <jbicha> I think Ubuntu's "main" is pretty unique among distros
[14:26] <didrocks> should we build thus from source?
[14:26] <jbicha> I don't know if other distros would want to rebuild the videos from source, but I think Debian would
[14:27] <jbicha> the package isn't updated very often
[14:27] <didrocks> I guess there is a headless mode for blender, so compatible with buildds?
[14:28] <didrocks> ah, the main build-deps thing was when I was away from distro, that makes sense now (thanks seb for the pointer)
[14:28] <willcooke> didrocks, seb128  - confirmed they play on a virgin Artful desktop
[14:29] <willcooke> via totem
[14:29] <seb128> \o/
[14:29] <didrocks> excellent!
[14:29] <willcooke> I'd want to do some tweaking of the bitrates still really
[14:29] <willcooke> that was the deafults
[14:29] <willcooke> defaults
[14:29] <didrocks> willcooke: once you are done, are you ok proposing it to GNOME yourself or need us?
[14:29] <willcooke> didrocks, let's see how I get on
[14:29] <didrocks> oki :)
[14:29] <willcooke> I'll create a card
[14:30] <seb128> thanks didrocks, willcooke
[14:30] <didrocks> I guess it's hard to debate if we win half the size against those vids, wdyt?
[14:30] <seb128> so I guess we are +1 on the changes suggested by GunnarHj then?
[14:30] <didrocks> yep :)
[14:30] <didrocks> at least, to me
[14:30] <seb128> me too
[14:30] <didrocks> and if we add dash to dock-like experience, I think we can create one based on the main one
[14:30] <seb128> didrocks, do you want to reply on the list for the record or should I?
[14:30] <didrocks> or tweak it
[14:30] <didrocks> seb128: feel free
[14:31] <seb128> k
[14:31] <seb128> yeah, let's see what we need to do after we decide on extensions
[14:31] <GunnarHj> Thanks guys; I'll go back and complete the MP accordingly.
[14:31] <didrocks> excellent
[14:32] <seb128> yw, thanks everyone for the discussion
[14:32] <didrocks> thanks guys
[14:32] <seb128> GunnarHj, and thanks for nagging us about giving a reply :-)
[14:33] <GunnarHj> seb128: Always at your service. :)
[14:33] <seb128> GunnarHj, oh, while you are around, we got an artful translations export on launchpad yesterday, I'm going to have a look to do a langpacks build tomorrow
[14:34] <seb128> just as a fyi
[14:34] <seb128> jbicha, ^
[14:34] <seb128> you might be interested as well
[14:34] <seb128> the exports includes gnome-shell, I checked
[14:34] <seb128> (I approved the template a few days ago, we got translations imported correctly)
[14:35] <GunnarHj> seb128: Sounds good. Btw, is ubuntu-help gone now?
[14:36] <seb128> I didn't look
[14:36] <seb128> tarball is big and I'm on limited bandwith atm, I can check later
[14:37] <Trevinho> flexiondotorg: you also want http://bazaar.launchpad.net/~compiz-team/compiz/0.9.13/revision/4119 for xenial?
[14:38] <GunnarHj> seb128: Ok. We'd better make sure it didn't include something from an older build of ubuntu-docs, since we handle the docs outside of the language packs now.
[14:38] <seb128> GunnarHj, it wouldn't hurt much, just waste some space right?
[14:38] <seb128> but I'm going to keep an eye open for that, thanks for the comment
[14:38] <GunnarHj> seb128: Only spece waste, yes.
[14:39] <GunnarHj> s/spece/space/
[14:43] <jbicha> it looks like Qt was added to Ubuntu's default install for 11.10, 6 years ago
[14:44] <ogra_> yeah, just shortly before we planned to switch to unity8 and mir by default :P
[14:45] <jbicha> I think it was added for the Ubuntu One client
[14:45] <jbicha> Fedora actually includes Qt in their default GNOME install (for adwaita-qt)
[14:45] <willcooke> desktoppers - seb128 is going to run the meeting today, it's my lad's birthday so I'm cooking.  (thanks seb128)
[14:46] <seb128> yw!
[14:46] <xclaesse> jbicha, Ubuntu Online Account uses qt too IIRC
[14:46]  * Trevinho worried for will's lad :-D
[14:46] <willcooke> :DD
[14:46] <didrocks> :)
[14:47] <seb128> you might that some pints is not a proper dinner?
[14:47] <Trevinho> aahhaha
[14:48] <seb128> :-)
[14:48] <seb128> (might->mean)
[14:55]  * Trevinho remembers desktoppers the unmeeting ;-)
[14:56] <seb128> Trevinho, sorry I'm working for a coffee place atm, I should try to organize better for those :-/
[14:57]  * Trevinho is in a coworking too
[14:58] <Trevinho> but well... I did it in the road, so who cares :-D
[15:00] <seb128> haha
[15:00] <andyrock> I'm watching the last 10km of tdf
[15:00] <andyrock> so 10 minutes
[15:30] <seb128> k, meeting time
[15:30] <seb128> going to be a short list today
[15:30] <seb128> #startmeeting
[15:30] <meetingology> Meeting started Tue Jul  4 15:30:33 2017 UTC.  The chair is seb128. Information about MeetBot at http://wiki.ubuntu.com/meetingology.
[15:30] <meetingology> Available commands: action commands idea info link nick
[15:30] <oSoMoN> o/
[15:31] <jbicha> o/
[15:31] <seb128> Roll call: andyrock, dgadomski, didrocks (out), duflu (out), jbicha, jamesh, jibel/heber, kenvandine (out), laney (out), oSoMoN, seb128, tkamppeter, trevinho, robert_ancell (out)
[15:31] <andyrock> o/
[15:31] <seb128> k, let's get started
[15:31] <seb128> #topic andyrock
[15:31] <seb128> andyrock, hey
[15:31] <andyrock> # Review https://code.launchpad.net/~3v1n0/compiz/grid-lowgfx-fixes/+merge/326487
[15:31] <andyrock> # Review https://code.launchpad.net/~3v1n0/compiz/move-lowgfx-fixes/+merge/326451/+index?ss=1
[15:31] <andyrock> # Review https://code.launchpad.net/~3v1n0/compiz/resize-lowgfx-fixes/+merge/326491
[15:31] <andyrock> # Review https://code.launchpad.net/~3v1n0/compiz/support-desktop-average-colors/+merge/326573
[15:31] <andyrock> # Review https://code.launchpad.net/~3v1n0/unity/compiz-average-color/+merge/326571
[15:31] <andyrock> # Update software-properties-gtk design for livepatch following mtp's design
[15:31] <andyrock> # Studying and veryifing proposal for Livepatch Auth API (understanding macaroons, if all we need is there, etc.)
[15:31] <andyrock> # Looking at dash-to-dock code/issues/etc.
[15:31] <andyrock> # Blocked on update-manager waiting for design
[15:31] <andyrock> # EOW
[15:32] <seb128> good busy week andyrock :-)
[15:32] <seb128> thanks
[15:33] <seb128> #topic dgadomski
[15:33] <seb128> dgadomski, hey
[15:33] <dgadomski> hey
[15:33] <dgadomski> * still working on finding a way to disable WiFi Direct on intel 8260 (iwlwifi)
[15:33] <dgadomski> * working on bug #1701073
[15:33] <dgadomski> * working on bug #1700827
[15:33] <dgadomski> eof
[15:33] <seb128> thanks dgadomski
[15:33] <seb128> #topic didrocks
[15:33] <seb128> * Went back from Bosch's workshop after half a day of snap/snapcraft presentation & tutorials
[15:33] <seb128> * Review & merge desktop helper PR
[15:33] <seb128> * Ensure we don't have any migration scripts for unity running anymore (removed the nautilus one we don't need)
[15:33] <seb128> * Transition launcher icons from unity to gnome-shell (one time, only if default) and renamed amazon icon. Trying to keep into consideration people staying in unity session which shouldn't be impacted by that script
[15:33] <seb128> * Fixed some transition followup on dist-upgrade (amazon icon and u-c-c to g-c-c)
[15:33] <seb128> * Some AA work (NEWed some mate packages, demotions based on component-mismatches for cleaning up unity stack and ensure most of the components are in universe)
[15:33] <seb128> * Worked on an incoming set of 3 posts on classic snaps (using ubuntu-make as an example)
[15:33] <seb128> * Various discussions on snap themes, mimetype & desktop renames…
[15:34] <seb128> #topic duflu
[15:34] <seb128> * Video acceleration:
[15:34] <seb128>   - I've been diving deep into the VA-API failures in Wayland sessions: https://bugs.launchpad.net/bugs/1698287
[15:34] <seb128>   - Prototyped some upstream fixes this week for the Wayland-specific VAAPI issues:
[15:34] <seb128>     . mpv - https://github.com/mpv-player/mpv/pull/4556
[15:34] <seb128>     . totem/gstreamer-vaapi - https://bugzilla.gnome.org/show_bug.cgi?id=783169
[15:34] <seb128>   - Though still experiencing corruption and high CPU in gstreamer-clutter (totem): https://bugs.launchpad.net/bugs/1701463
[15:34] <seb128> * PulseAudio:
[15:34] <seb128>   - Finally completed SRU release to xenial (pulseaudio 1:8.0-0ubuntu3.3), although it did get stuck loosely on a regression that already existed in zesty and artful: https://bugs.launchpad.net/bugs/1690028
[15:34] <seb128>   - Started planning an update for artful (more news next week).
[15:34] <seb128> * Gnome Shell graphical bugs:
[15:34] <seb128>   - Completed and released new battery icons (with design's blessing), to support Gnome Shell's strictly square proportions: https://launchpad.net/bugs/1693155
[15:34] <seb128>   - You will notice a visual change at low DPI, but it's the best we can do without hacking upstream gnome-shell to support rectangular icons (which is probably possible but hasn't yet been attempted by anyone).
[15:34] <seb128> * Daily bug maintenance across gnome-shell, bluez, pulseaudio and mir.
[15:34] <seb128>   - Piles of automatic bug expiries from the May efforts started this week (in bluez)!
[15:34] <seb128> #topic jbicha
[15:35] <seb128> jbicha, hey
[15:35] <jbicha> • Fixed serious GDM bug for Ubuntu 17.10 and Debian (LP: #1701243)
[15:35] <jbicha> • Verified the gnome-software SRUs
[15:35] <jbicha> • Backported commits to fix gnome-contacts FTBFS with vala 0.36
[15:35] <jbicha> • Gave a push to removing the old webkitgtk from Debian by filing bugs and raising severity of existing bugs.
[15:35] <jbicha> The removal will take several weeks but it's doable by 18.04 LTS, maybe even 17.10. Arch Linux already did it. Fedora 27 (~November) is doing it too.
[15:35] <jbicha> https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=pkg-webkit-maintainers@lists.alioth.debian.org;tag=webkit1
[15:35] <jbicha> • Tried the preview of Pop!_OS, surprised to see a re-themed Ubuntu GNOME 17.04
[15:35] <jbicha> eow
[15:36] <seb128> thanks jbicha
[15:36] <seb128> #topic jamesh
[15:36] <seb128> gnome-software:
[15:36] <seb128> * rebased patches on new ubuntu-master branch, which is now based on
[15:36] <seb128> gnome-software 3.25.x.
[15:36] <seb128> * (re)started discussion about snapd directly using polkit.  This
[15:36] <seb128> would give a better experience for installing/removing snaps on the
[15:36] <seb128> desktop, and would likely improve security overall.  Main blocker is
[15:36] <seb128> convincing niemeyer :-)
[15:36] <seb128>  Up next is looking at captive portal handling in network-manager.
[15:37] <seb128> #topic jibel/heber
[15:37] <seb128> jibel, heber, hey
[15:37] <heber> Hey guys! QA updates:
[15:37] <heber> * Tested upgrades to artful and migration script.
[15:37] <heber> * Writing automated upgrade tests for the migration to gnome-shell
[15:37] <heber> * Update utah to be able to setup autopkg test before running tests.
[15:37] <heber> * Update CI to include Run tests after Smoke jobs.
[15:37] <heber> EOF
[15:38] <seb128> heber, are those tests run daily on on package updates somewhere?
[15:38] <seb128> or on*
[15:38] <seb128> if so is there a page we can look at to see the results of the day?
[15:39] <heber> seb128, the idea is to start with jobs after a new image is available on pending
[15:39] <seb128> sounds good, I guess that's not done yet?
[15:39] <heber> the results will be available in grafana dashboard. But that work is not ready yet
[15:39] <seb128> k
[15:39] <seb128> thanks heber
[15:40] <seb128> #topic oSoMoN
[15:40] <seb128> oSoMoN, hey
[15:40] <oSoMoN> hey there
[15:40] <oSoMoN> • discussed possible xenial SRU for bug #1585863, concluded that we need more evidence that the bug isn't fixed by 1.2.6
[15:40] <oSoMoN> • contributed a minor patch to snapcraft-desktop-helpers
[15:40] <oSoMoN> • filed bug #1700953, this is blocking packaging of libreoffice 5.4 (unless we revert a couple of upstream commits to relax the dependency on cppunit), need to follow up
[15:40] <oSoMoN> • chromium 59.0.3071.109 was published to all supported releases (thanks chris_ccoulson!)
[15:40] <oSoMoN> • updated chromium beta to 60.0.3112.50
[15:40] <oSoMoN> • published libreoffice <IP_ADDRESS> to the snap store (beta channel), amd64 and armhf, and blogged about it: https://forum.snapcraft.io/t/call-for-testing-libreoffice-5-3-4-snap/1205 , https://plus.google.com/100486649727917304321/posts/g2zWPFx75DW
[15:40] <oSoMoN> • continued investigating libreoffice i386 FTBFS (bug #1700692)
[15:40] <oSoMoN> ^D
[15:41] <seb128> thanks oSoMoN
[15:41] <seb128> #topic seb128
[15:41] <seb128> • reviewed u-c-c/lowgfx changes from Marco
[15:41] <seb128> • tested the libreoffice snap update, good work Olivier!
[15:41] <seb128> • hacked some local snap examples to demo the issues we are having with the content interface and wrote corresponding forum posts
[15:41] <seb128> • artful daily iso/install testing
[15:41] <seb128> • discussions about desktop topics (artful iso, language packages, snaps themes, pulseaudio SRU regression, desktop files renames, ...)
[15:42] <seb128> • tested the gnome-software xenial SRU candidate
[15:42] <seb128> #topic tkamppeter
[15:42] <seb128> tkamppeter, hey
[15:43] <seb128> no tkamppeter?
[15:43] <seb128> k, let's move on
[15:43] <seb128> #topic Trevinho
[15:43] <seb128> Trevinho, hey Marco!
[15:44] <Trevinho> 17/27
[15:44] <Trevinho> · Finished some missing fixes in UCC for lowgfx support
[15:44] <Trevinho> · Landed the fixes above, duflu's theme fixes, and other compiz fixes
[15:44] <Trevinho> · Fixed lowgfx issues in compiz (move, grid and resize plugins)
[15:44] <Trevinho> · Prepared backports to xenial for Unity, UCC, Nux, Compiz
[15:44] <Trevinho> · Attended the Ubuntu On Air meeting for the Testing days about GNOME
[15:44] <Trevinho>   https://www.youtube.com/watch?v=XMOwozLBdXI
[15:44] <Trevinho> · Moved back to Torino
[15:44] <Trevinho> · Did something else I don't remember
[15:44] <Trevinho> · Attended the unmeeting ALONE (I hate you guys -_- :-D)!
[15:44] <Trevinho> 🍉
[15:44] <seb128> 17 what?
[15:44] <Trevinho> it's the year/week... I forgot to trim :-)
[15:45] <tkamppeter> Hi
[15:45] <seb128> ah
[15:45] <seb128> thanks for doing that Ubuntu On Air and sorry we didn't have more people joining
[15:45] <seb128> we do better next time
[15:45] <seb128> and sorry for the unmeeting
[15:45] <seb128> on that one also we do better next time :p
[15:45] <seb128> thanks Trevinho
[15:45] <Trevinho> :)
[15:45] <seb128> hey tkamppeter
[15:45] <seb128> #topic tkamppeter
[15:45] <tkamppeter> - cups-filters: Released 1.14.1 with all the crash and stability fixes on cups-browsed (got uploaded into Debian today), worked on configurable naming of local queues created by cups-browsed, got some patches for cups-browsed to improve on handling of description and location info of remote printers.
[15:45] <tkamppeter> - Google Summer of Code 2017: Student project coordination and mentoring. Especially discussed implementation of flattening filled PDF forms in the pdftopdf filter. All students show very good progress.
[15:45] <tkamppeter> - Bugs.
[15:46] <seb128> thanks tkamppeter
[15:46] <seb128> #topic robert_ancell
[15:46] <seb128> - At Snappy sprint
[15:46] <seb128> - Swap day
[15:46] <seb128> - Following up with Snappy tasks back home
[15:46] <seb128> #topic aob
[15:47] <seb128> did I forget anyone? any other topic?
[15:49] <seb128> seems not I guess, let's wrap then
[15:49] <seb128> good efficient meeting, thanks everyone
[15:49] <seb128> #endmeeting
[15:49] <meetingology> Meeting ended Tue Jul  4 15:49:10 2017 UTC.
[15:49] <meetingology> Minutes:        http://ubottu.com/meetingology/logs/ubuntu-desktop/2017/ubuntu-desktop.2017-07-04-15.30.moin.txt
[15:49] <oSoMoN> thanks seb128
[15:50] <seb128> yw!
[15:51] <seb128> oSoMoN, sorry I dropped offline for a bit and I didn't see if you saw my question/replied earlier, did you manage to get anyone replying to you about the kernel/builder issue that makes libreoffice i386 not build?
[15:57] <oSoMoN> seb128, I talked to the kernel team and smb said «  That kernel version replaced the fix with the current upstream approach. That should fix the currently known real use-cases but showed some failures with some test cases. However upstream decided that they want to see real use-cases. So behavior is probably not back to how it was before but might need convincing arguments for upstream that something breaking is a le
[15:57] <oSoMoN> git use. »
[15:58] <oSoMoN> so I need to make a case for the LO build upstream
[15:59] <seb128> k :-/
[16:00] <oSoMoN> seb128, I’ll talk to the kernel folks again to devise the best approach to make that case
[16:05] <seb128> oSoMoN, sounds good, let me know how it goes, I'm trying to lurk on their channel and follow discussions (if you talk to them on IRC)
[16:05] <oSoMoN> seb128, yes, I talked to them on #ubuntu-kernel yesterday
[16:05] <seb128> good
[16:27] <oSoMoN> seb128, discussing the issue further on #ubuntu-kernel, in case you hadn’t seen
[16:29] <seb128> oSoMoN, thanks
[17:37]  * oSoMoN EOD
[17:37] <oSoMoN> have a good evening everyone
[18:58] <willcooke> night all


[00:13] <kdub> racarr, sorry, got embroiled in fighting the nexus10
[00:14] <kdub> racarr, i like the sound of the last idea, although, it might be better done as a deleter than a destructor?
[01:04] <racarr> kdub: Hmm y eah a deleter is probably better


[01:39] <Exilant> Hi, am I supposed to/allowed to file bugs against the version of kde 4.1 in the launchpad repositories, or not?
[01:53] <yuriy> Exilant: yes, please. preferably about the ones in Intrepid, but the hardy packages should be similar enough
[01:53] <Exilant> ok, will do, thank you
[01:53] <yuriy> Exilant: if hardy, do it against the -kde4 package (but it will likely need to be switched to the regular package if confirmed in intrepid)
[01:53] <yuriy> Exilant: i mean, the package ending in -kde4
[01:55] <Exilant> ok, will do
[01:57] <yuriy> Exilant: also please file at bugs.kde.org instead unless (or in addition) unless you think it's likely a bug introduced by kubuntu
[02:07] <persia> yuriy: Should KDE bugs really be filed in KDE *instead* rather than *also*?  I'd think that the bug link would be useful information, and having it already present in LP would reduce the effort of future triagers to track down the relevant upstream bug (plus it shows up in the list of duplicate candidates)
[02:11] <yuriy> persia: right, also with proper linkage is better
[02:11] <yuriy> and Exilant ^
[02:11] <Exilant> hm
[02:11] <Exilant> "kscreensaver-xsavers-extra-kde4" does not exist in Ubuntu. Please choose a different package. If you're unsure, please select "I don't know"
[02:12] <Exilant> i don't know, is that supposed to happen?
[02:13] <Exilant> maybe i'll leave out the kde4
[02:21] <Exilant> thanks for the help, and thanks for all that work in hunting and fixing bugs, have a good night
[02:34] <yuriy> damn, he left
[04:06] <mrooney> what is the proper way to handle a request for a backport?
[04:06] <mrooney> is there a guide for that?
[04:08] <persia> !backports
[05:10] <mrooney> persia: thanks :) I made it to that page before but for a different purpose and never noticed that section
[07:39] <mcas_away> good morning
[07:39] <mcas> i need help with bug 253279
[07:40] <mcas> it is an upstream problem and it is known there but must be fixed by nvidia
[07:40] <mcas> can someone tell me how to proceed?
[07:49] <RAOF> mcas: Is it an upstream _bug_?  If so, link to the upstream bug.
[07:51] <mcas> RAOF: i have to change the package to, because the nvidia driver are the probelm
[07:51] <mcas> s/probelm/problem
[07:51] <RAOF> mcas: If it's an nvidia bug, you can either mark it as Invalid, or if there's a really obvious bug (ie: not something like 'nvidia performs badly here', but doing x,y,z causes a catastrophy) then you want to move it to the nvidia source package.
[07:51] <RAOF> That's changed recently, I'm not sure what it is now.
[07:52] <mcas> RAOF: it's "only" about bad performance
[07:52] <RAOF> Then that's probably just invalid.
[07:53] <mcas> ok thank you
[07:53] <RAOF> Although 99% CPU utilisation is pretty bad :)
[07:53] <RAOF> It might be worth punting to the nvidia package, but it's likely to just sit there annoying people :(
[07:53] <mcas> yes but the hints from kde techbase did it for him
[07:54] <mcas> this problem is mentioned by the kde 4.1 release notes as known problem
[09:08]  * e-jat down down down
[10:49] <james_w> mrooney: hi, http://people.ubuntu.com/~jamesw/mrooney.py
[13:23] <mrooney> james_w: thanks, I'll check it out!
[13:24] <james_w> mrooney: give us a shout if it doesn't work :-)
[13:24] <james_w> I didn't test it, but it's based on code I use
[14:34] <mouz> In bug 248788 the reporter has attached .crash files directly. He did so, because apport-gtk had crashed too. Apart from the fact the wrong files were attached: is a crash file in itself usable for triaging?
[14:46] <pedro_> mouz: if apport-gtk crashed you can tell the reporter to use apport-cli instead, attaching .crash files to the reports is a bad idea... apport should handle those
[14:47] <james_w> hey mouz
[14:47] <james_w> hey pedro_
[14:47] <pedro_> hey james_w
[14:47] <james_w> mouz: apport-cli -c /var/crash/whatever will submit an apport bug report correctly
[14:48] <james_w> you can get the stuff out of .crash files if they are attached, but it's more trouble than it's worth really
[14:48] <james_w> mouz: and you can close that bug, as the apport-cli thing will open a new one
[14:50] <mouz> ok thanks both
[15:36] <mcas> i need help with bug 236173
[15:36] <mcas> the package is now in the intrepid repos
[15:37] <mcas> can i change the status now to "Fixed released"?
[15:37] <yuriy> mcas: yes
[15:37] <mcas> thank you yuriy
[15:38] <yuriy> er sorry was thinking of something else. hope not to step on people's toes, but that should be right
[15:39] <yuriy> ping xand3r in #kubuntu-devel if you want to make sure he's done with it
[15:39] <mcas> yuriy: he gave me the information ;-)
[15:40] <mcas> he told me to close the bug
[15:40] <mcas> and i wasn't sure about the new status
[15:46] <mcas> sorry but its me again
[15:46] <mcas> bug 253617
[15:47] <mcas> i would change the status to confirmed because this would be a great feature
[15:47] <mcas> can someone please change the importance to Wishlist?
[15:51] <james_w> mcas: I'm on it, I think it's actually wishlist for firefox, packages can install apport hooks
[15:52] <mcas> ok do you change everything or should i?
[15:53] <mcas> i didn't know that applications can do that
[15:53] <james_w> I've done it I think
[15:53] <mcas> ok thanks
[16:53] <nhandler> If a person reports a bug on Launchpad, and then determines that it is not really a bug, but something they did wrong, what should the status be set to? Invalid?
[16:53] <bdmurray> nhandler: yes, that is correct
[16:54] <bdmurray> as we didn't make a change to some software to fix it
[16:54] <nhandler> Ok, that is what I thought. I just wanted to make sure. Thanks bdmurray
[16:58] <bddebian> Boo
[22:07] <mrooney> would anyone mind confirming bug 253400?
[22:08] <bdmurray> mrooney: confirmed
[22:09] <chrisccoulson> this is only with the original home page is it? i can't confirm it with a custom home page
[22:10] <mrooney> chrisccoulson: oh right, it would only be with a chrome: or another page which redirects
[22:12] <mrooney> generically it is just a bug that you can't easily go back after visiting a page which redirects
[22:13] <bdmurray> I'd never thought of fixing it, just always worked around it
[22:14] <mrooney> bdmurray: do you think it is worthy of fixing?
[22:14] <bdmurray> mrooney: that's up to upstream but it sure would be neat as it it'd save 2 clicks
[22:15] <mrooney> bdmurray: shall I attempt to forward it? and any ideas on importance in Ubuntu?
[22:16] <bdmurray> mrooney: low I'd say
[22:16] <chrisccoulson> i can confirm it as well actualy. just tried it with a fresh user
[22:18] <mrooney> chrisccoulson: thanks!
[22:19] <mrooney> now can I just do also affects /firefox (Mozilla Firefox) and that handles the upstream logic for me?
[22:20] <bdmurray> mrooney: you'd need to manually report it in the upstream bug tracking system
[22:21] <mrooney> bdmurray: oh, what happens if I say it also affects project firefox?
[22:22] <bdmurray> mrooney: not much without an upstream bug to link to, it just indicates that it needs forwarding
[22:23] <mrooney> bdmurray: oh okay, I wouldn't have been surprised if Launchpad forwarded it for me
[22:23] <mrooney> lately it has been getting more and more automagical
[22:25] <afflux> mrooney: while this could be helpful sometimes, it would probably lead to some duplicate bugs at the upstream bug tracker, because when forwarding manually, you usually check whether the bug already is known
[22:27] <mcas> can i ask a question to a hugday bug?
[22:27] <mcas> bug 160809
[22:27] <james_w> hey mcas, sure
[22:28] <mcas> i ask for more information should i mark it on the hugday wiki page?
[22:28] <mrooney> afflux: I guess I assumed whoever did it would have already checked that, now they just don't have to file it
[22:28] <mrooney> bdmurray: now, should I make the upstream bug about going back after redirects in general?
[22:28] <mrooney> I obviously can't make it about ubufox
[22:28] <afflux> ah right, that makes sense
[22:29] <bdmurray> mrooney: yes, that sounds ideal to me
[22:29] <mrooney> bdmurray: also sounds like it won't get fixed any time soon that way :)
[22:30] <mrooney> I think all browsers every have this issue
[22:30] <mrooney> though I could be wrong
[22:31] <james_w> mcas: yeah, if you've asked for more information and set it to incomplete, then put your name next to it on the wiki
[22:31] <mcas> ok this is my first hugday bug :-)
[22:31]  * james_w hugs mcas
[22:31] <james_w> nice work! :-)
[22:32] <mcas> should i change to lightgreen?
[22:32] <james_w> yeah
[22:36] <mcas> done
[22:39] <mcas> thanks for your help james_w
[22:44] <greg-g> sorry, can't particpate today, but uh, should the topic be changed?
[22:44] <greg-g> bdmurray: ^
[22:46] <bdmurray> greg-g: oops, thanks!
[22:55] <mrooney> speaking of firefox, I guess bug 253641 needs to go upstream?
[22:58] <mrooney> man that was fun making the XML actually link to the XSL from launchpadlibrarian so you could just click it
[23:06] <afflux> note to myself: don't click on links in bugreports without reading what they are ("this link causes firefox to segfault *click*")
[23:06] <bdmurray> heh
[23:07] <bdmurray> So you can confirm it then? ;)
[23:07] <afflux> *confirmed*
[23:07] <afflux> yup :)