[02:44] robert_ancell: do you think there is much chance of convincing niemeyer to consider polkit? [02:44] jamesh, I gave up [02:45] 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] When I patched it the first time there weren't good D-Bus libraries available [02:46] 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] jamesh, the snapd client? [02:46] so it wouldn't conflict with any existing use cases [02:47] or snapd itself? [02:47] yeah. so the client would send something like "Authorization: polkit" in the request headers [02:47] oh, I see [02:47] and snapd would only make the polkit CheckAuthorization request in that case. [02:47] otherwise, the existing logic would run its course. [02:48] something like this could also be used to determine whether to do interactive polkit auth or not [02:48] "Authorization: polkit; interactive=1" maybe [02:48] 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] root [02:49] jamesh, I think that will get shot down because you need both the Macaroon (store credentials) and Polkit. [02:50] 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] 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] jamesh, yes [02:54] and that the command line tool is effectively storing root access credentials in the user's home directory [02:54] jamesh, I think it's worth you continuing to raise these issues. You might have better terminology to describe them [02:54] It's perhaps best to focus on that particular issue and leave the minor issues for now. [02:55] 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] 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] since the policies are arbitrary JavaScript functions [05:53] good morning desktoppers! [06:11] good morning === Guest44144 is now known as fredp === fredp is now known as Guest15020 === carlolo is now known as clobrano__ [07:03] TheMuso, hello. May I join ~ubuntu-audio-dev ? [07:03] morning [07:04] Morning oSoMoN, didrocks, jibel [07:05] hey duflu, morning jibel [07:06] jibel: any thoughts on checkbox-converged? is it even used nowdays? (by you or certification team?) [07:06] it's bringing up the whole Qt/QML stack on the iso for it [07:06] and morning seb128 [07:07] and other random Europeans [07:07] good morning desktopers [07:07] hey duflu [07:11] didrocks, no idea if it's still used for anything. I'll ask jerry or chris [07:13] jibel: thanks! Keep me posted :) [07:29] jibel, unless you want to upset him; "Gerry" :) [07:34] mvo: good morning! thanks for insisting on https://github.com/cockpit-project/cockpit/pull/7131, updated now; mind having another look? [07:35] err [07:35] mvo: sorry, I meant our mvo (we have one too!) [07:35] mvo: so... Good morning! wie gehts? :-) [07:36] 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] didrocks: no, Michael Vogt and Marius Vollmer are both "mvo"; I thought I was in the cockpit channel [07:38] pitti: oh, someone using a different nickname between IRC and github? (his nickname there is mvollmer apparently), scandalous! :) [07:39] didrocks: heh yes, he's mvollmer on freenode, but mvo on internal IRC [07:40] sounds like a trap just targeted at you! :) [07:41] good morning [07:41] hey andyrock [07:43] 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] +1 [07:45] hey andyrock [07:45] salut pitti, comment ça va ? [07:46] seb128: ça va bien, merci ! la dernière semaine à Karlsruhe avec mon équipe était grande [07:46] duflu, I don't understand, why would I upset him? [07:47] pitti, ah c'est bien pour toi alors ! [07:47] bonjour pitti [07:47] seb128: we got a lot of stuff done, and finished the week with an electrical go-kart race [07:47] jibel, it's Gerry as in Gerrard :) [07:47] bonjour jibel, ça va ? [07:47] I think mainly Americans assume "Jerry" [07:48] duflu, no it's Jerry from CE. We are not talking about the same person [07:48] jibel, Oh... OK. You mentioned Qt :) [07:48] yeah np :) [07:48] didrocks, do you think we should go through seed changes and refresh the packages once, or just tweak&rebuild? [07:49] pitti, ça va bien, happy to work on desktop again :) [07:49] 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] 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] 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] jibel: nice! so you're becoming a gnome guy at last? :) [07:51] anyway no big deal, I should probably just have stacked in the vcs [07:51] didrocks, let me know before your do another upload, just in case I want to sneak those in ;-) [07:51] 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] sure :) [07:51] seb128: next one is checkbox-converged for the Qt5 stack IMHO [07:52] didrocks, and for a11y-profile-manager you think it's useless? [07:52] once we know from jibel is good for removal [07:52] I don't know enough about it to be sure [07:52] it's not unity specific [07:52] and there is a gnome profile/binary [07:52] but we don't have a maintainer for it and I'm not sure what it brings [07:53] 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] k, let's call it a decision, makes things easier, I was investigating on that yesterday [07:53] if somebody ask I tell them you tool the decision :p [07:53] heh, sure :) [07:54] just went the pragmatic approach [07:54] I didn't remove the rest as I was less sure [07:54] right, we can iterate [07:54] we are not going to see the status until gdm is in anyway [07:54] eactly [07:54] or rather unity-greeter out [07:54] exactly* [07:54] yeah, quite equivalent :) [07:55] I wonder if it's about time where we nag the security team for a pre-emptive ack to unblock us [07:55] I would be in favor of that [07:55] like ack with the understanding that we are going to address their review issues when they get the review done [07:55] as we did for big part of the stack [07:56] k, let's talk to them about that once they are up [07:56] good plan [07:57] didrocks, do you have any idea how alsa-base get on the iso? [07:57] I think I'm missing something obvious [07:57] seb128: I'm surprise, it's not from the manifest [07:57] let me start yesterday's iso [07:58] (manifest of germinate-outputs) [08:01] morning [08:02] hey willcooke, how are you today? [08:02] hi willcooke [08:02] hey jamesh [08:05] 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] If we manage that, the user experience for gnome-software should improve [08:06] Gustavo doesn't seem close from convinced yet [08:06] let's see if the new round of arguments from robert and you is enough [08:06] yep, but I'm hopeful I can change his mind [08:06] hey willcooke [08:09] jamesh, great, I hope it works out :-) [08:10] 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] yeah [08:18] seb128: found it at lp:~ubuntu-core-dev/ubuntu-seeds/platform.artful [08:18] desktop-common: * alsa-base # needed for proper hardware detection (hotplug/blacklist.d, modprobe.d) [08:27] didrocks, oh, platform seed, thanks [08:28] seb128: sounds like we shouldn't remove it though? But I don't know enough about alsa [08:29] didrocks, not sure, jbicha asked on some trello card about it, Debian removed that package as "ROM; No longer needed, obsolete" [08:30] not sure who would have a better clue though [08:30] pitti, do you have any idea if alsa-base is something that might still have some use for some users/configs? [08:32] seb128: I don't know for sure; but the modprobe.d scripts might still be relevant [08:32] and the apport hook of course [08:37] duflu, interesiting, reading [08:38] koza, also http://dep.debian.net/deps/dep14/ [08:38] seb128: sounds weird to me to have ubuntu-image on the iso, wdyt? [08:38] (seems Ubuntu's pulseaudio code is already kept in debian git) [08:40] (dep of livecd-rootfs) [08:43] duflu, thanks, good stuff [08:48] pitti, thanks [08:52] didrocks, I don't see ubuntu-image on the iso. On which image do you see it? [08:53] didrocks, weird indeed, do you have the commit/reason why it was added? [08:54] jibel: I guess it's only in the live [08:54] ah, it's not on the live [08:55] interesting, it's in the all germinate output though [08:55] I don't know which log file we should base on thus [08:55] http://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu.artful/desktop only contains the desktop seed (and not desktop-common and such) [08:56] http://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu.artful/all has more than what we ship [08:56] 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] (all is then clearly "all seeds" [08:56] ) [09:11] talking about spring/summer cleaning: "Source only movements to main": unity [09:11] seb128: any idea why? ^ [09:12] * didrocks wonders if we have one binary package from unity in main [09:12] * didrocks checks [09:14] libunity-core-6.0-9 [09:14] oh unity-schemas as well is still in main [09:14] even unity-services [09:14] hum [09:14] let's see why [09:16] 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] didrocks, no idea, yeah, let's see [09:25] I just checked all rdepends, nothing in main (for libunity-core, schemas, services…) [09:25] no build-rdepends either for the -dev [09:25] so yeah, let's go empiric [09:26] (done, let's look at next publisher cycle) [09:27] oh nice, we got the +1 for removing checkbox-converged from the iso [09:27] where? [09:27] email from the cert team (jibel sent one) [09:27] should we kick off a build first with the current changes first? [09:27] to have a checkpoint, wdyt? [09:27] k, I guess I was not Cced [09:27] * didrocks looks [09:28] I would remove checkbox while we are at it [09:28] nope [09:28] I think that's likely going to be the biggest impact [09:28] yeah [09:28] so, no iso first? [09:28] we do that in the some round? [09:28] as you prefer [09:28] (I'm fine with it) [09:28] I would drop checkbox [09:28] ok [09:28] and trigger an iso build later [09:28] or even wait tomorrow [09:29] depending how eager you are to see the result [09:29] anything else you want to change in the seed? [09:29] let me have a look [09:29] as you told you had waiting changes :) [09:29] yep [09:30] I was unsure about adium-theme-ubuntu [09:30] well, it's not coming from the seed anyway [09:30] so let's ignore that [09:30] * seb128 reads his tomboy note [09:31] 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] (at worst, we should tweak the empathy deps/recommends) [09:32] yeah [09:32] let's keep those for the next round [09:32] in fact most of mines are depends from other packages and not seed [09:32] the seed ones are alsa-base which I'm unsure about [09:32] and app-install-data-partner which I'm also unsure about [09:32] didrocks, so we have a GO to remove checkbox-converged [09:32] jibel: yeah, we are discussing it here ^ it's nice! :) [09:33] well, what you said higher :) [09:33] :) [09:33] seb128: yeah unsure if alsa-base is a safe one… [09:33] didrocks, the other ones I had on my lsit you handled in your previous upload [09:33] so it's good [09:33] thanks for checking :-) [09:34] seb128: hum, /usr/share/app-install/channels/xenial-partner.eula is empty, let me check artful [09:34] also I'm unsure where that's being used [09:34] was it a software-center thing? [09:35] but better to check with L_aney, he knows better those stack I think [09:35] 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] seb128: mind adding it to the trello card so that we check with Lane_y? [09:36] didrocks, done [09:36] thx! [09:37] uploading the seed with checkbox-converged remove [09:37] thanks [09:37] I guess that should remove a lot of qml* [09:37] not Qt5 though [09:37] (hud/greeter) [09:37] right [09:40] ah, we start to see some movement thanks to the seed changes: http://people.canonical.com/~ubuntu-archive/component-mismatches.html [09:41] (we'll need to discuss whoopsie at some point) [09:42] 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] (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] well demoting binaries is often done in case where the source is to stay in main [09:49] is whoopsie having a standalone config dialog? [09:52] no, it was part of activity-log-manager [09:52] whoopsie-preferences is only a dbus service [09:54] right [10:21] oh, new battery icons, nice! [10:21] thanks Daniel [10:31] * willcooke upgrades [10:31] woo! [10:31] humm, looks ok at the login screen, but still squished in the session [10:32] oSoMoN, do you see the same? ^ [10:32] 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] willcooke, this is how it looks here: http://people.canonical.com/~osomon/battery.png [10:34] kk, same here [10:34] but different on the login screen [10:35] I'll see what's going on and log a bug [10:35] dunno if it’s supposed to look different, but it’s a net improvement over what there was before [10:35] that icon looks a bit horizontally squashed to me [10:35] :) [10:35] humm, another bug perhaps... [10:35] Plug in the power, get the charging battery icon, unplug the power - still have the charging icon [10:36] willcooke: login screen, as in using gdm ofc? [10:37] ahh, yes, I'm still on lightdm here [10:37] didrocks, ^ [10:39] 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] interesting side-effect about Provides:. I bet the package can't be built anyway (it was using unity-common for the schema) [11:17] with that, I think unity source package won't be willing again to be pulled to main [11:38] didrocks: oh, yes please -- this hasn't really been supported for ages [12:02] 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] this is demotion day [12:03] and ubuntu-ui-toolkit is on the list \o/ [12:21] Trevinho: https://code.launchpad.net/~muktupavels/compiz/motif-wm-hints/+merge/326777 [12:32] muktupavels, flexiondotorg: is that somethiong we want in xenial too? [12:33] muktupavels: so bad I did a landing yesterday :-( [12:33] trevinho: https://askubuntu.com/questions/928226/xprop-fails-to-undecorate-window [12:34] muktupavels: what is the standard by the way? [12:34] ? [12:36] muktupavels: also why not using XA_CARDINAL instead of anytype? [12:36] Trevinho: I used it because it is used in metacity [12:37] mh, I see... ok fine [12:37] muktupavels: can you please open a bug? [12:38] Trevinho: ok [12:38] ta [12:50] didrocks: Independence Day ;) [12:51] didrocks, thanks for checkbox-converged and ui-toolkit demotion! :) [12:51] jbicha: ahah, good matching :) [12:51] mitya57: yw! [12:58] * willcooke offers jbicha a cup of tea [12:58] Trevinho: https://bugs.launchpad.net/compiz/+bug/1702297 [12:58] Ubuntu bug 1702297 in Compiz "Compiz ignores _MOTIF_WM_HINTS set from xprop" [Undecided,New] [12:58] muktupavels: thanks [12:58] muktupavels: sru compliant, awesome [12:59] willcooke: would you dare offering milk/cream with it though? :p [12:59] willcooke: uh, thanks I guess ;) [12:59] :D [13:06] Hi willcooke, I asked about an ISO size matter the other day: [13:06] https://lists.ubuntu.com/archives/ubuntu-desktop/2017-June/005028.html [13:06] 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] lol [13:11] hey GunnarHj [13:11] seb128: Hi Seb! [13:11] I think no decision should be made before we finish the transition [13:12] (meaning gdm on the iso, no more big cleanup possible) [13:12] so that we know where we stand with [13:12] didrocks, it's a bit orthogonal discussions though? [13:12] I mean it's going to be "is it ok to take a 90M hit to get those packages" [13:13] well, depends if we want to go back to a reasonable iso size [13:13] yeah, that as well [13:13] I guess we can talk about it right now anyway, I doubt other than the ones present are interested in it, wdyt? [13:13] +1 talk now works for me [13:13] 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] (a little bit ironic we just, we just removed 60+ packages of the iso) [13:14] now seems fine to me [13:14] 60Mb or packages? [13:14] or 60 binaries? [13:14] so, taking the amd64 iso as an example: we're at 1.5GB [13:15] seb128: binaries [13:15] k [13:15] Trusty was 1GB [13:15] warty was under 600M :p [13:16] So we've already grown 500MB in the last 3 years, right? [13:16] seb128: you really should upgrade soon ;) [13:16] (lol) [13:16] haha [13:16] 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] didrocks, any guesses as to where we'll be when the transition is done? [13:17] is this a net zero increase (i.e. we dropped the same as we'd add) [13:17] willcooke: back to our discussion, depends on the security team and kenvandine to be done with lightdm -> gdm [13:17] then, add a week for the final cleaning [13:18] 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] willcooke, I would guess we win some space but not so much, still over 1.3G [13:18] jbicha: it will [13:18] jbicha: pulling indicator, hence qt5, hence ubuntu-app-launch, hence zeitgeist [13:18] oh ok [13:18] the biggest win is probably when we get qt out the iso [13:19] not enormous, but will still count :) [13:19] nautilus and totem-plugins still depend on zg [13:19] yeah, I guess we can drop them or handling them smartly [13:20] discussion is drifting [13:20] 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] anyway [13:20] One problem with keeping things like this pending is that it makes progress of related work harder. [13:20] either way, I think an extra 60MB is ok [13:20] back to language, yeah [13:20] did anyone test the additional size? [13:20] I just have to figure out how to get tracker in without seb noticing ;) [13:20] :D [13:20] that's round 0 when making this kind of proposal [13:20] jbicha: ahah :p [13:21] didrocks, GunnarHj has numbers in his emails [13:21] ah, not the MP, numbers [13:21] * didrocks reopen the email [13:21] but it's installed sizes [13:21] so not iso [13:21] GunnarHj: do you have the deb size? [13:22] as we approximate deb size with iso size [13:22] didrocks: I asked jibel about that last week and he said installed-size was a better estimate? [13:22] 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] those debs at 10M each for well translated languages [13:23] for 7 languages = 70M [13:23] jbicha: hum? I'm surprised, we always used deb size as it's squashfs compression, so similar to ar [13:23] gnome-getting-started-docs* [13:23] it's the same order anyway [13:23] 70M deb vs 80M installed [13:24] sounds ok to me [13:24] I guess those videos are already compressed and those are the biggest part of updating the proposal? [13:24] the video is only present once, correct? [13:24] then + subtitle [13:25] * didrocks wget [13:26] the video itself can be translated https://help.gnome.org/users/gnome-help/stable/figures/gnome-task-switching.webm.fr [13:27] indeed, some are even [13:28] that's different from what I saw on latest fedora's on bochecha's latptop [13:28] but ok, so the size is coming from the videos [13:28] which is why I guess those locales are taking 10M deb [13:28] where others are hundred of kbs [13:28] seb128: So it is. [13:28] 11M on the video directory [13:29] (french) [13:29] is that video that useful? [13:29] anyway, I think it makes sense to add them for the languages we claim complete default support. [13:29] seb128: fedora starts the page presenting them by default [13:29] what page? [13:29] like showing how to reach for the dash [13:29] gnome-help with the introduction to G-S [13:29] ah [13:30] seb128: when GNOME Initial Setup completes, it opens the Getting Started page with the videos right there [13:30] do they auto open yelp on first loggin? [13:30] however, *if* we tweak the default experience via extensions (which isn't discussed yet), we may have some discrepancies there [13:30] seb128: yeah, first user login after install [13:30] I see [13:30] only 3 videos are shown though [13:30] good point about extensions [13:30] then, you have to go to subpages to see others [13:30] 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] anyway, going back to the topic, I'm a bit torned [13:36] 100M is not a trivial hit for the iso [13:36] it's easy to dismiss medium-sized addition like that [13:36] 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] 1.5GB seems like a good max. size to me [13:37] slows down downloads, installs, has cost on mirrors, etc [13:37] so if it's net cost zero - +1 [13:37] +1 for me as well if we win enough to make for the cost of the suggestion addition [13:37] -0.3 otherwise [13:37] :D [13:37] (mod(2)) [13:38] I'm in favor of having the languages install work offline and without post install nagging though [13:39] so if we are over I might suggest we do something about the video [13:39] maybe re-encode at lower definition [13:39] what codec does it use? x264? [13:39] I wonder if we could have a look at re-encoding and how much we would trade off on size vs quality [13:39] webm [13:39] kk [13:39] seb128: That aspect is even more important now, when we no longer will have language-selector-gnome to get the rest.... [13:39] would be hard to get better compression/size rate [13:40] well, we could lower quality or resolution [13:40] maybe [13:40] 854 x 480, it's not much already :/ [13:40] I didn't look at it [13:40] and using the On2 extension [13:40] didrocks, webm vp8 or 9? Do you know? [13:40] worth a try, but unsure how much smaller they can be [13:40] vp8 [13:41] could try with 9 [13:41] 10M is not that big for a video I guess [13:41] * willcooke fires up handbrake [13:41] it's 10M for ~5:30min [13:41]