[06:38] <didrocks> good morning!
[06:50] <k_alam> Please look into following issues....
[06:51] <k_alam> https://bugs.launchpad.net/ubuntu/+source/libgdata/+bug/1698437
[06:51] <k_alam> https://bugs.launchpad.net/ubuntu/+source/policykit-desktop-privileges/+bug/1670269
[06:51] <k_alam> https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/1690407
[06:53] <k_alam> Nautilus issue is really complicated and probably xorg specific...but mate/cinnamon fixed it by patching caja/nemo
[06:53] <k_alam> Thanks
[07:23] <oSoMoN> good morning desktoppers
[07:23] <duflu> Hello oSoMoN
[07:24] <oSoMoN> hey duflu
[07:26] <duflu> Curiously there's a big reduction in lag using GNOME on Wayland compared to Xorg. Bigger than I expected. Although I'm only assuming both are using hardware cursors
[07:26] <duflu> ^ RAOF did you ever notice that?
[07:28] <RAOF> duflu: As always, “lag” is an unhelpful term :)
[07:28] <duflu> RAOF: Visible disparity between the cursor and titlebar when dragging a window
[07:28] <RAOF> Xorg cursor will be more responsive to mouse movements, wayland cursor will be better synchonised to window movements.
[07:29] <duflu> Is it software rendered or did mutter use the delayed rendering trick (I think Weston already has)?
[07:29] <RAOF> No?
[07:29] <RAOF> Xorg cursor is entirely divorced from frame updates (to the extent that frame updates exist at all in X, which is not very much)
[07:29] <RAOF> Wayland cursor is updated once a frame.
[07:30] <duflu> RAOF: Oh, right, OK.
[07:30] <duflu> Good trick, apparently
[07:30] <RAOF> I think that the SIGIOectomy of Xorg has been done, so cursor updates are performed in a regular thread rather than a signal handler.
[07:31] <duflu> Nevermind. I have a card in the backlog to port mirvanity to Wayland. That would provide better answers
[07:33] <seb128> good morning desktopers
[07:33] <oSoMoN> good morning seb128
[07:33] <duflu> Hi seb128
[07:33] <seb128> hey oSoMoN, duflu, RAOF
[07:34] <didrocks> hey oSoMoN, duflu, RAOF, re seb128
[07:34] <seb128> lut didrocks :-)
[07:35] <seb128> had an ok trip out of the waiting and the suboptimal wifi?
[07:35] <oSoMoN> salut didrocks
[07:35] <Mirv> once duflu is done with that and hopefully someone ports mirvfb somewhere too, I might finally stop getting Mir related highlights :)
[07:35] <oSoMoN> :)
[07:35] <oSoMoN> hey Mirv, how are you doing?
[07:35] <didrocks> seb128: yeah, the trip was uneventful, everything on time as expected and waited a lot with flaky wifi as you saw…
[07:35] <didrocks> but that was ok, back home finally :)
[07:35] <RAOF> Hey yo everybody!
[07:35] <duflu> Mirv: Long time no see. Sorry about that but yeah the name would change...
[07:36] <seb128> didrocks, :-)
[07:36] <didrocks> seb128: also, network, didn't get any (they even didn't gave us the "guest" password) during our workshop…
[07:36] <Mirv> oSoMoN: hey oSoMoN, fine thanks, I've just had a few weeks of work but planning to spend holiday for July as originally planned (before April)
[07:36] <didrocks> hey Mirv!
[07:36] <seb128> :-/
[07:36] <Mirv> duflu: no problem, it always brings smile to me when I get those funny highlights ;)
[07:36] <Mirv> hey didrocks
[07:36] <Mirv> oSoMoN: how are you?
[07:37] <oSoMoN> Mirv, I’m good, thanks! Holidays sound good, I’ll be afk a couple of weeks at the end of July too, looking forward to it :)
[07:38]  * didrocks is eager to see the lightm -> gdm transition so that we can do the iso cleanswap
[07:39] <didrocks> that will remove the indicators, and so, ubiquity after installation and such and such¿
[07:41] <duflu> didrocks: I'm hoping gdm will also work around bug 1700485
[08:01] <Laney> morning!
[08:03] <didrocks> hey Laney
[08:04] <Laney> hey didrocks, wb
[08:04] <Laney> how are you and how was it?
[08:07] <didrocks> I'm good but a little bit tired due to travelling and arriving late yesterday
[08:07] <didrocks> the demo and workshop were well received from what I heard from
[08:09] <seb128> hey Laney, back from London already?
[08:09] <seb128> didrocks, ubiquity is kept because of the indicators?
[08:10] <seb128> didrocks, on the iso cleanswap I put a bunch of items in the trello card, I think there are some things we can get out but I don't think it's going to be big on space or maintaince saving
[08:10] <seb128> well out of what is going to automatically fall out once gdm replaces lightdm
[08:12] <Laney> yes, back last night
[08:12] <Laney> how are you seb128?
[08:12] <seb128> was the day in London good? useful?
[08:13] <seb128> I'm good, I had some 7 hours sleep this night, also it's raining today and fresh which is nice for a change
[08:14] <didrocks> seb128: yep, see the bug report I referenced in the trello card with cyphermox_'s investigation
[08:15] <didrocks> seb128: yeah, I saw your items on the card!
[08:15] <didrocks> we can maybe removed Qt, so it will be quite some size :)
[08:15] <seb128> right, that's probably just a matter of removing checkbox
[08:16] <seb128> or going back to the old gtk version
[08:16] <seb128> somebody pinged jibel about that some time ago but I think he said it was not somebody from qa and to ask $somebodyelse
[08:17] <Laney> seb128: being there for some desktop related discussions was helpful ...
[08:17] <Laney> and meeting up with people
[08:18] <Laney> got to abuse ximion about some bugs
[08:18] <seb128> haha
[08:25] <duflu> koza, willcooke, Are there any bluetooth topics to discuss today? I have none that I can recall
[08:28] <duflu> + seb128
[08:28] <seb128> duflu, I don't have any topic and willcooke is at a snappy sprint so not going to join
[08:29] <seb128> duflu, maybe we should just skip this one if there is nothing to discuss?
[08:29] <duflu> seb128, Depends on koza. Also I'm out for next week's
[08:32] <jibel> I'm stuck. anyone see anything obvious in this list of updates https://launchpadlibrarian.net/325600829/livecd.ubuntu.manifest.diff that could cause bug 1700557 ?
[08:33] <jibel> i'm updating all the packages 1 by 1 but it's tedious
[08:34] <jibel> it looks like a kernel bug the the kernel is the same between the 2 images
[08:34] <koza> duflu, we can skip the meeting
[08:34] <duflu> koza, so long as you don't get surprised by my absence next week too :)
[08:35] <koza> duflu, I promise I will not :)
[08:35] <seb128> jibel, I see nothing suspicious in that list
[08:35] <seb128> is the manifest listing kernels and such?
[08:35] <seb128> duflu, koza, let's skip then?
[08:36] <koza> seb128, duflu, yes let's skip
[08:36] <seb128> k
[08:37] <jibel> seb128, yes, it lists the content of the squashfs
[08:37] <seb128> didrocks, Laney, I wonder if we should start removing the compat_desktop hacks from e.g nautilus as well
[08:37] <jibel> the kernel was 4.10.0.22.24
[08:37] <Laney> seb128: we can do, but those benefit other desktops too
[08:37] <jibel> it ididn't change
[08:38] <Laney> I think if we do then at least the migration from unity favourites to gnome shell favourites should fix that up
[08:38] <Laney> or wait, isn't there a translation table in gnome shell itself?
[08:38] <seb128> Laney, we did change the unity launcher config already afaik
[08:39] <seb128> but the rename was an issue for e.g default mimetype handlers
[08:39] <Laney> how?
[08:39] <seb128> or other desktops
[08:39] <seb128> well, your mimeapps (or whatever the name of that file is called) listed the old name
[08:39] <seb128> and nothing is rewritting it with the new name
[08:39] <seb128> well, if you have an user edited one
[08:39] <seb128> where you changed for example your default image viewer to gimp and then back to eog.desktop
[08:40] <Laney> yeah
[08:40] <Laney> I meant "how?" for the unity launcher thing
[08:40] <seb128> Laney, http://launchpadlibrarian.net/325869839/nautilus_1%3A3.24.1-0ubuntu3_1%3A3.24.1-0ubuntu4.diff.gz
[08:41] <seb128> sorry I'm too lazy to find another url
[08:41] <seb128> but that has the script in the diff :p
[08:41] <Laney> people did that for everything?
[08:42] <seb128> no, I expect some we didn't do
[08:42] <seb128> we did it at least for those in the launcher default config
[08:43] <seb128> anyway that script covers launcher only
[08:43] <seb128> you say that gnome-shell has a mapping table?
[08:43] <seb128> how does it work?
[08:43] <Laney> if it sees one name, that is translated to another
[08:43] <andyrock> good morning
[08:43] <seb128> that covers launcher?
[08:44] <seb128> hey andyrock, how are you?
[08:44] <andyrock> mpt is it possible to have a full design with all the cases?
[08:44] <mpt> andyrock, yes, I’m planning to work on that today
[08:44] <Laney> https://git.gnome.org/browse/gnome-shell/tree/js/ui/appFavorites.js#n10
[08:45] <andyrock> otherwise it's likely I waste one more week
[08:45] <andyrock> hey seb128 good you?
[08:46] <seb128> andyrock, I'm good thanks!
[08:46] <seb128> Laney, shrug, that's a long list, for sure we didn't migrate most of those
[08:46] <Laney> yep
[08:47] <Laney> https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1662296
[08:47] <didrocks> let me scrollback (working on the migration script as we skip)
[08:47] <seb128> Laney, imho we should just stop trying to handle the rename and drop the hacks, it might lead to some config issues for upgraders but oh well, those are easy to fix and the hacks have a cost in maintainance and leads to some buggy UIs where items are listed twice
[08:48] <Laney> ok, well I try to propose ways to mitigate the impact, but if you want to say that we accept the issues then just do it
[08:48] <didrocks> yeah, it was only once for nautilus AFAIK
[08:48] <didrocks> I don't think anybody wrote anything for others
[08:49] <seb128> Laney, I can put a card in the backlog and see how it goes/if we have cycles to work on a better solution
[08:49] <seb128> I'm just getting annoyed by the dup items in some UIs
[08:50] <Laney> what's the chance of that?
[08:50] <Laney> I think nobody will, so that is the same as saying that we won't do it, in which case just don't do it
[08:51] <seb128> hum
[08:51] <Laney> it's fair to say that the workaround creates its own issues
[08:51] <Laney> and was never that complete anyway
[08:51] <seb128> my gut feeling is that the impact on users is small annoyances when they have to re-add a launcher icon or reselect a default app
[08:51] <seb128> which is annoying but easy to workaround
[08:52] <Laney> as you wish then
[08:52] <Laney> I don't think it's that hard to migrate stuff over
[08:52] <Laney> but it is work and if nobody's going to do it
[08:52] <seb128> well that's only my opinion, I would welcome some other people stating what they think
[08:52] <Laney> then decide what is more important
[08:53] <seb128> it's not hard but that table from g-s has some 30 items
[08:53] <didrocks> hum, I can't log into the wayland session anymore
[08:53] <seb128> and some of the packages are direct syncs
[08:53] <Laney> doesn't have to be in the individual packages
[08:53] <Laney> it can be in gnome-shell
[08:53] <Laney> or anywhere in fact
[08:53] <seb128> right
[08:54] <Laney> I don't feel that strongly about it any more
[08:54] <Laney> just made a proposal but you're free to go a different way
[08:54] <seb128> didrocks, wdyt?
[08:54] <seb128> Laney, I'm not deciding more than you here :p
[08:55] <didrocks> you know I'm always in favor of smooth user transitions, especially if it's not a lot of work for us
[08:55] <didrocks> the question though is that most of the transitions have already been done, right?
[08:56] <didrocks> how many are missing since the LTS?
[08:56] <didrocks> (as we missed all the others pre-LTS, and it's too late)
[08:56] <seb128> I don't even remember if those renames happened mostly before xenial or after
[08:56] <seb128> let me check
[08:56] <Laney> it's not too late, since we renamed the desktop files
[08:56] <Laney> that was papering over the problem
[08:56] <seb128> right
[08:57] <seb128> we didn't drop the old name
[08:57] <Laney> although that only happened for a few applications
[08:57] <seb128> so non migrated configs still work
[08:57] <Laney> so it was at best quite incomplete :-)
[08:57] <didrocks> ah, we didn't drop old names
[08:57] <Laney> it makes a copy with the old name
[08:57] <didrocks> so, basically, the issue is for non G-S desktop, if we drop them, correct?
[08:57] <didrocks> (as G-S has that map)
[08:57] <Laney> and gnome-shell for mimeapps associations as far as I can tell
[08:57] <didrocks> oh right
[08:58] <didrocks> I would still do it, doesn't sound to be that much work
[08:59] <Laney> I proposed an idea ages ago https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1662296/comments/2
[08:59] <Laney> but actually I would probably just copy the list instead of making each package do it
[09:00] <seb128> right, each package sounds complex
[09:00] <Laney> and maybe we can tell flavours 'you might want to do this' instead of providing some hook mechanism
[09:00] <seb128> let me put a card in the backlog about doing that migration in gnome-shell's package
[09:00] <didrocks> hum, interesting
[09:00] <Laney> that is probably too difficult
[09:00] <didrocks> a little bit of work on session-migrations though, but sounds like a better and more scalable idea
[09:01] <didrocks> copy the list and having new hooks for all is easier, indeed
[09:01] <seb128> didrocks, you mean on session-migrations itself? or just a migration python script to ship in g-s?
[09:01] <didrocks> seb128: well, with the initial proposal from Laney, it involved some work on session-migrations itself
[09:01] <seb128> right
[09:01] <seb128> well, if somebody wants to do that it would be nice
[09:01] <didrocks> but, if we have a list, we can have a package shipping utility functions somewhere in python for instance
[09:01] <didrocks> and having multiple scripts using it
[09:01] <Laney> yeah
[09:02] <didrocks> which is easier IMHO
[09:02] <Laney> just sharing the list is probably good enough
[09:02] <Laney> and have something common do the mimeapps.list bit as that is shared across environments
[09:02] <didrocks> yep
[09:02] <didrocks> where should this python package live in your opinion?
[09:03] <Laney> https://github.com/hughsie/appstream-glib/blob/master/libappstream-glib/as-store.c#L721 there's a bigger one BTW
[09:03] <Laney> hmm, don't know
[09:05] <seb128> didrocks, Laney, I created https://trello.com/c/M3Vc1BDm/172-handle-better-gnome-desktop-renames
[09:06] <didrocks> perfect, thanks seb128!
[09:06] <seb128> yw
[09:06] <Laney> thx!
[09:06] <Laney> good discussion
[09:06] <didrocks> so, basically, we have those utilities "somewhere"
[09:06] <didrocks> if you ship a list with a simple hook, importing that package
[09:06] <didrocks> it will run the migration for mimeapps and G-S launcher
[09:06] <didrocks> (if needed)
[09:07] <didrocks> and we can add as well other desktop in it
[09:07] <seb128> yeah
[09:07] <didrocks> (everytime checking if the schema is there ofc)
[09:07] <Laney> or the desktops can ship it themselves
[09:07] <Laney> and just read this file in in their hooks
[09:07] <seb128> or have our migration script in gnome-shell or ubuntu-session
[09:07] <Laney> or import the same python module
[09:07] <seb128> and other desktops handle their configs/users
[09:07] <didrocks> could do, I'll explore options
[09:07] <seb128> what Laney said basically
[09:07] <seb128> didrocks, thanks
[09:08] <Laney> ♥
[09:13] <popey> didrocks: hello! do you know of any clutter apps which we have successfully snapped?
[09:15] <popey> I'm getting libgl errors, even when using desktop-gtk3, and the opengl plug (among others).
[09:15] <popey> didrocks: http://paste.ubuntu.com/24970892/ is the super simple clutter app we're testing with
[09:17] <popey> didrocks: http://paste.ubuntu.com/24970908/ is what you get when you run that
[10:07] <Laney> http://people.canonical.com/~laney/weird-things/weather.png
[10:07] <Laney> depressing weather ⓒ GNOME MMXVII
[10:09] <tseliot> seb128, Laney, jbicha: I have a patch for gdm (LP: #1697882), how do I proceed? What branch shall I use for the MP?
[10:10] <oSoMoN> didrocks, https://github.com/ubuntu/snapcraft-desktop-helpers/pull/66
[10:28] <mpt> Laney, it’s not just light rain, it’s Light rain
[10:38] <oSoMoN> seb128 (or anyone else who can sponsor): I'm gonna need cppunit 1.14 in artful, filed sync request as bug #1700953
[10:38] <oSoMoN> (needed to build LO 5.4.0 RC1)
[11:23] <Laney> tseliot: I don't know of a branch for gdm3, so a debdiff on the bug is probably OK - and if it's suitable for upstream, please submit it there too & then write the URL into the patch you submit & link the bug. :)
[11:25] <Laney> oSoMoN: looks like it breaks other stuff, what should we do there?
[11:41] <jbicha> tseliot: lp:~ubuntu-desktop/gdm/ubuntu (for artful)
[11:42] <jbicha> good morning
[11:45] <Laney> Vcs-Bzr should say that
[11:45] <Laney> hi
[11:52] <oSoMoN> Laney, not sure, I’ll see if the LO dependency can be relaxed back to 1.13
[11:58] <GunnarHj> jbicha: Good morning! Time to sort out the seed MP?
[11:59] <seb128> oSoMoN, Laney, is that a transition? maybe we just need to deal with it?
[12:00] <jbicha> GunnarHj: I believe we don't want extra gnome-getting-started-docs- pkgs in the live image
[12:01] <GunnarHj> jbicha: Too big? I suspected you'd say that. But gnome-user-docs?
[12:01] <jbicha> jibel: you've done work before on iso image size; do you know if Installed-Size or Download-Size is a reasonable estimate of how much space a pkg will take on the iso?
[12:05] <GunnarHj> jbicha: Isn't it the Download-Size, i.e. the size of the .deb files, which adds to the ISO size?
[12:06] <Laney> seb128: sort of, it requires code changes to packages that aren't all uploaded in debian yet
[12:08] <jibel> jbicha, installed-size is a good approximation
[12:13] <jibel> jbicha, and download size is the exact size of the package
[12:13] <jibel> of the deb
[12:13] <jbicha> GunnarHj: ok, so g-u-docs-de is 3.2 MB and -fr is 1.8 MB, etc.
[12:15] <jbicha> I'm thinking those numbers are kind of high, what do you think?
[12:15] <GunnarHj> jbicha: Right. And if we had let the builders strip it, precisely that size would have been added to language-pack-gnome-XX-base for those languages.
[12:18] <GunnarHj> jbicha: I have no own idea of what's reasonable in this case. But if you read that bug report, the overall idea seems to be that nothing further should be pulled by language-selector for those languages.
[12:21] <jbicha> I get 12 MB by adding up those extra languages for user docs: https://paste.debian.net/973701/
[12:22] <jbicha> which bug report?
[12:23] <GunnarHj> jbicha: Bug #1520278
[12:25] <GunnarHj> jbicha: To give you some perspective of things affecting ISO size: The archive size of fonts-noto-cjk is currently 170 MiB in the daily builds. It was recently increased by 100 MiB, but will soon be reduced by 120 MiB by splitting the package.
[12:36] <jbicha> changing the German dictionaries adds 10 MB https://paste.debian.net/973707/
[12:39] <GunnarHj> jbicha: More than I'd have guessed. But -frami is what's preferred by the German users and what has been pulled by pkg_depends for a few cycles. I really think we should get rid of such inconsistencies.
[12:39] <jbicha> GunnarHj: maybe, but I don't think I can make that decision by myself
[12:40] <jbicha> didrocks: since 1520278 was your bug, do you want to weigh in?
[12:40] <GunnarHj> jbicha: Understood. Who can?
[12:40] <jbicha> GunnarHj: the Desktop Team collectively
[12:43] <GunnarHj> jbicha: I think that the reason for the current delta between the seed and pkg_depends is that things have gradually changed over time. I have adapted pkg_depends, but have been unaware of the implication of the seeds.
[12:44] <jbicha> and the extra getting-started-docs pkgs proposed add 83 MB https://paste.debian.net/973708/
[12:45] <GunnarHj> jbicha: The latter is much. :(
[12:46] <jbicha> but if you're measuring by "able to do offline install with no missing language support" for those languages…
[12:47] <GunnarHj> jbicha: Yeah, in that case we can stop talking about sizes. ;)
[12:48] <seb128> oSoMoN, good job figuring out the libreoffice menu issue
[12:51] <jbicha> Ubuntu GNOME followed Ubuntu's example and installed the extra language suppport in 16.10 (the iso went from ~1.2 GB to ~1.4 GB)
[12:53] <jbicha> but g-getting-started-docs wasn't split out yet (the Ubuntu GNOME daily now says ~1.5 GB)
[12:54] <oSoMoN> seb128, thanks for spotting it!
[12:54] <seb128> yw :-)
[12:57] <GunnarHj> jbicha: Compared with Ubuntu GNOME 16.10/17.04, the ISO size ought to be reduced a bit when packages are moved to main stripped.
[12:58] <GunnarHj> s/main stripped/main and stripped/
[12:59] <jbicha> GunnarHj: if we don't get additional comments here, feel free to ask on the desktop mailing list or at a Tuesday meeting
[13:01] <seb128> cyphermox_, hey, did you see my ping yesterday? what's the status of n-mp/nplan/autopkgtest?
[13:02] <GunnarHj> jbicha: Since it's Wednesday, I think I'll post to the list then.
[13:07] <GunnarHj> seb128: Hi Sebastien, can you please look at bug #1684097? I think that they messed up the POT creation somehow - please see my latest comment. Do you have an idea offhand how to fix it?
[13:07] <seb128> hey GunnarHj
[13:10] <tseliot> Laney, jbicha: ok, thanks
[13:10] <jbicha> seb128: are you ok with the patches at LP: #1696418 and LP: #1575222 ?
[13:11] <seb128> jbicha, the first one no opinion, I think it's wrong to not debug the issue and fix it properly but I don't care enough about trusty to spend time debugging it and I'm not going to block others if they want to workaorund that way
[13:12] <seb128> the other one looks good
[13:16] <mpt> andyrock, if a livepatch fails, the fallback is for it to install as a normal update (requiring restart), right?
[13:16] <andyrock> yeah, so you should update/upgrade restart with the new kernel
[13:17] <andyrock> I don't think there are fixes that are distributed with livepatch but not with normal repo
[13:17] <mpt> andyrock, do you you have any data on how often it happens that a livepatch update doesn’t work?
[13:17] <andyrock> nope
[13:32] <jbicha> k_alam: if you attach a patch to an Ubuntu bug, please remember to subscribe ~ubuntu-sponsors https://wiki.ubuntu.com/SponsorshipProcess
[13:34] <didrocks> jbicha: unsure I want to dive into such a discussion before we get a good idea of our iso size with the transitions done
[13:48] <didrocks> popey: I don't know about any of them, sorry
[13:54] <GunnarHj> jbicha: One thing just struck me: As regards gnome-user-docs-<lang> for the big languages, they would basically replace localized ubuntu-docs pages in the language-pack-gnome-XX-base packages, so the net effect on the ISO size ought to be negligible. Given that, the remaining concern is the German hunspell packages and gnome-getting-started-docs-<lang>. Do you agree?
[13:59] <tseliot> jbicha: ok, merge proposal sent
[14:14] <flexiondotorg> muktupavels Hi
[14:14] <muktupavels> flexiondotorg: hi
[14:15] <flexiondotorg> muktupavels I thought it might be a good idea to introduce you to greyback
[14:15] <Trevinho> Laney: hey, I've noticed there's an u-c-c in proposed for xenial, with a bug that has verification-failed
[14:15] <greyback> muktupavels: hi
[14:15] <muktupavels> ?
[14:15] <muktupavels> greyback: hi
[14:15] <flexiondotorg> muktupavels greyback is the Mir lead. He spoke to me on Monday about how Mir could be used as a Wayland compositor.
[14:16] <Laney> hi Trevinho
[14:16] <Laney> Trevinho: ok?
[14:16] <flexiondotorg> muktupavels Thought you might be interested in hearing about these developments.
[14:16] <Trevinho> Laney: so.. I've to release a change too in xenial, so I'm wondering how long I should wait or... if I can just add the PR to your silo waiting
[14:16] <Trevinho> Laney: yes, ok. You're still in london?
[14:16] <greyback> muktupavels: I'm wanting to chat with shell/window manager devs, to learn what their plans are for Wayland adoption in future
[14:17] <greyback> muktupavels: we've this big chunk of code called Mir, which (once we've Wayland support enabled) might be of use to shell authors, but there's likely features we're missing that you'd need
[14:18] <greyback> muktupavels: if you can spare me a few mins, I'd like to pick your brain on this topic
[14:18] <Laney> Trevinho: I think that verification-failed could be verification-done-xenial. The change works, it just happens to not fix the bug.
[14:19] <muktupavels> greyback: I dont know anything about wayland...
[14:19] <Laney> do you want to push on changing that / getting it released?
[14:20] <muktupavels> flexiondotorg: what are your plans about Metacity in MATE?
[14:21] <Trevinho> Laney: ok, so I'll change that
[14:22] <greyback> muktupavels: budgie uses metacity, right?
[14:22] <Laney> meh, my desktop just crashed in the middle of an upgrade
[14:23] <greyback> muktupavels: talking with flexiondotorg we were just discussing the things that their metacity fork would need, should it move away from X11
[14:23] <muktupavels> greyback, no
[14:23] <muktupavels> they use mutter
[14:23] <didrocks> do you know if G-S can pin devices in the dash?
[14:23] <didrocks> (knowing if it's something I need to transition as well)
[14:23] <greyback> muktupavels: durrr, think I'm getting my wires crossed, sorry
[14:24] <muktupavels> greyback: my opinion is that Metacity has been and will be x11 only
[14:25] <greyback> muktupavels: ok. Metacity does everything you need from a compositor? Any features you wish it had?
[14:27] <greyback> muktupavels: and for budgie-wm, is mutter easy to work with?
[14:27] <muktupavels> greyback: what features? example?
[14:28] <muktupavels> greyback: I dont know
[14:29] <greyback> muktupavels: features I think of are "is it flexible enough for what you want", is the window management good? Does it save/restore your window positions if you plug/unplug external monitors? Is it using your GPU, or software only
[14:30] <greyback> high-dpi support is nice to have. touch screen support too
[14:32] <muktupavels> dont know about window positions when plugin / unplugin monitors. probably not.
[14:33] <muktupavels> Metacity has high-dpi support.
[14:36] <greyback> muktupavels: ok, well it sounds like you're pretty happy with metacity at the moment
[14:37] <greyback> muktupavels: but if you ever fancy looking into moving away from X, look me up, I'll have info you might find useful
[14:38] <muktupavels> greyback: yes, I am happy. there are things that I want, but moving away from x is not one of them.
[14:38] <greyback> muktupavels: ok, well thanks for chatting with me
[14:38] <muktupavels> :)
[14:41] <flexiondotorg> muktupavels The plans for Metacity in MATE are unchanged from what we discussed a few weeks back.
[14:41] <didrocks> Trevinho: do you have the scaling configuration key I need to migrate between unity and G-S?
[14:42] <flexiondotorg> muktupavels We'd like to update mate-settings-daemon so Metacity is fully supported and allow distro maintainers to ship either Metacity or Marco.
[14:42] <Trevinho> didrocks: well, so far we can't migrate anything, just reset the defaults
[14:42] <Trevinho> didrocks: so they're font-scaling-factor and ui-scaling in org.gnome.desktop.interface
[14:42] <Trevinho> didrocks: ah. and the cursor-size one
[14:42] <didrocks> Trevinho: hum, why reset? if we keep the same values, it's going to break?
[14:42] <flexiondotorg> muktupavels The MATE dev who is going to work on the m-s-d changes is taking exams right now, so I expect that work to start in a few weeks.
[14:43] <didrocks> (and so, what to migrate later on as they are in org.gnome.*)
[14:43] <muktupavels> flexiondotorg: OK
[14:43] <Trevinho> didrocks: we can't reuse those with great results in gnome...
[14:43] <Trevinho> didrocks: also that would break the gnome automatic-scaling algo
[14:43] <didrocks> Trevinho: did you change the scale, or is it the float vs integer thing?
[14:44] <Trevinho> didrocks: so, we can migrate the settings later once the new mutter configuration is theree with per-monitor-scaling
[14:44] <Trevinho> but right now it's just not worth it
[14:44] <didrocks> Trevinho: but basically, you are changing the scale/definition of those keys?
[14:44] <didrocks> this is why they are not compatible with the previous values?
[14:44] <Trevinho> didrocks: the new settings will be inside mutter config ~/.config/monitors.xml
[14:44] <Trevinho> but that file has not any room for scaling right now
[14:45] <didrocks> Trevinho: sorry, but I would like to understand why the previous values aren't compatible (probably stupid question, but I didn't dive into your work) :)
[14:45] <Trevinho> didrocks: so, if you just keep thje values we have they'll break things in some cases
[14:46] <didrocks> so, you changed the semantic of the values?
[14:47] <Trevinho> didrocks: currently they are not... But you'll just end up with global values which might be wrong. Like if the user had a 1.5 scaling he'll get a shel and everyhthing scaled at 2 and the text at 0.75
[14:47] <Trevinho> didrocks: this *migtht* be ok for now...
[14:47] <Trevinho> But... the thing is when the new mutter configuration will be used, we'd have to reset these values anyway to rely on user configuration or automatic-scaling.
[14:47] <didrocks> ah, because you are more fine-grained and can scale multiple things
[14:47] <didrocks> ok
[14:47] <didrocks> so
[14:47] <Trevinho> So, up to you, or we do reset them now, or later
[14:48] <didrocks> but we'll need to reset them in any case
[14:48] <didrocks> and not basing on them
[14:48] <didrocks> correct?
[14:48] <Trevinho> yeah, otherwise all the scaling we're doing now, is just bypassed
[14:48] <didrocks> ok
[14:49] <Trevinho> we *migth* reuse the com.ubuntu.user-interface settings in future to figure out user preferences on fractional scaling
[14:49] <mpt> andyrock, design completed. <https://wiki.ubuntu.com/SoftwareUpdates?action=diff&rev2=214&rev1=211> The part I haven’t done is the error cases, because I don’t know what they are.
[14:49] <Trevinho> so we won't loose that information, but right now, I'm not sure what's the best approach
[14:49] <didrocks> Trevinho: I don't find font-scaling-factor
[14:49] <Trevinho> I had to do this, in order to get things working in the new mutter
[14:49] <didrocks> nor ui-scaling
[14:50] <didrocks> only cursor-size
[14:50] <Trevinho> didrocks: names are actually scaling-factor for UI
[14:50] <Trevinho> and text-scaling-factor
[14:51] <didrocks> Trevinho: better with the correct name! Ok, going to reset the 3 at the same time :)
[14:51] <didrocks> thanks!
[14:51] <andyrock> mpt: error cases for what? to enable livepatch  or in the status of livepatch?
[14:51] <didrocks> only if they had Unity, ok?
[14:51] <didrocks> Trevinho: or for everyone upgrading?
[14:51] <mpt> andyrock, both
[14:51] <andyrock> mmm for enabling it can be:
[14:52] <andyrock> 1. we don't get the livepatch token from the service for an user (e.g. the user is not allowed to use the service)
[14:53] <andyrock> 2. we get a token but the user is already using livepatch on more that 3 machines
[14:53] <andyrock> so enable will fail
[14:54] <andyrock> 3. We get a corrupted token and everything will just fail (it should not happen but maybe better to add a generic error case?)
[14:54] <jbicha> Trevinho: it might be better to use a more generic schema name than "com.ubuntu" but I believe GNOME at least doesn't really have code yet to do gsettings>gsettings migration
[14:54] <Trevinho> didrocks: i'd do it only for people with unity
[14:54] <andyrock> mpt: regardint the livepatch status:
[14:54] <Trevinho> jbicha: no wait, it's already there
[14:55] <andyrock> https://www.irccloud.com/pastebin/NZfgrDff/
[14:55] <Trevinho> jbicha: gsettings get com.ubuntu.user-interface scale-factor
[14:55] <andyrock> mpt: let me know if you need something more
[14:56] <jbicha> Trevinho: you're thinking of pushing com.ubuntu.user-interface into GNOME, right?
[14:56] <Trevinho> jbicha: nope... Once we'll have the new mutter configuration working, we *might* use these settings to define the user-defined scaling
[14:57] <didrocks> Trevinho: ok, doing so
[14:57] <jbicha> I don't understand but ok
[14:57] <Trevinho> jbicha: however... Since we'll have sane defaults anyway, i guess we'll just ignore them and user might re-adapt in g-c-c
[14:57] <Trevinho> jbicha: what is not clear?
[14:58] <jbicha> what was not clear was: "will you push the schema into GNOME Shell"? "nope, but we might use it"
[15:02] <jbicha> I think it's fine to reset things (so use different schemas?) and let the user decide if the new way works fine out-of-the-box after upgrade
[15:05] <jbicha> tseliot: is NVIDIA working to get KMS working correctly? do you know when that will be ready?
[15:21] <Trevinho> jbicha: oh, well... the situation is a bit tricky in fact... We should probably have in the past untiy not to set gtk-default settings by default but using a different profile or something like that. But now we've done it.
[15:22] <Trevinho> So... If the user logs in gnome we should reset these values. It might be also worth to split the settings in order to have unity *and* gnome working with different parameters, but thsi is not supported. And I've not looked how we can do it. Maybe just unity-settings-daemon could do by chanigng the xsettings instead of touching the gsettings ones
[15:25] <jbicha> why can't you just use different schema names?
[15:28] <Trevinho> jbicha: we might have done it, but we didn't as we needed a quick solution at the time, and something that applied to gtk settings without doing much
[15:29] <Trevinho> jbicha: so now, we can move to different gsettings schemas, I just need to figure out how to make unity-settings-daemon to feed gtk with the unity scaling settings
[15:31] <jbicha> Trevinho: your hidpi work hasn't been merged into GNOME yet, right?
[15:33] <Trevinho> jbicha: nope
[15:33] <Trevinho> jbicha: but anyways these things are still  relevant now
[15:34] <seb128> hum, what are you trying to resolve there?
[15:34] <seb128> I missed the start of the discussion and the backlog is quite long
[15:34] <seb128> is that what to do about the scaling settings on upgrade?
[15:37] <Trevinho> seb128: yes... and then about having both desktops available, with different options
[15:38] <Trevinho> as unity would break gnome by changing the gtk values
[15:38] <seb128> right
[15:38] <seb128> well it's probably not often that the same user alternate between desktops
[15:39] <Trevinho> seb128: but even if an user tries gnome, then he goes back to unity again for a while... Then say we release the fractional and he wants to go to gnome in the LTS or whatever... at that point there won't be a migration (it has already ran)
[15:39] <Trevinho> so... if you go back and forth you break things
[15:39] <seb128> right
[15:39] <seb128> it's not ideally
[15:39] <seb128> ideal
[15:39] <seb128> but most users don't do back and forth
[15:40] <didrocks> yeah, so, I conditioned the reset to:
[15:40] <Trevinho> yeah, well who does it, generally know how to fix too
[15:40] <didrocks> - you have unity installed
[15:40] <Trevinho> but still
[15:40] <didrocks> - first time you start ubuntu or ubuntu-wayland session
[15:40] <Trevinho> seb128: I've to check this, but I guess maybe using u-s-d to handle the values isn't bad
[15:41] <seb128> didrocks, that seems about right to me
[15:46] <didrocks> hum, no more bzr rewrite/rebase
[15:46] <didrocks> and ken pushed things on gnome-session :p
[15:46]  * didrocks will merge then
[15:46] <Trevinho> didrocks: oh, about that,....
[15:46] <Trevinho> didrocks: I can't get the bzr rewrite plugin to work here
[15:47] <Trevinho> didrocks: how to install that?
[15:47] <didrocks> Trevinho: it's been remove
[15:47] <didrocks> removed*
[15:47] <didrocks> from what I see
[15:47]  * didrocks would really like to have new repo org
[15:47] <Trevinho> eh, in fact I installed from src, but I didn't get it as an avvailable command
[15:47] <kenvandine> didrocks, sorry... i updated the branch to reflect what was in artful :)
[15:48] <didrocks> kenvandine: not your fault! :)
[16:25] <seb128> have a good evening desktopers
[16:25] <oSoMoN> have a good one seb128
[16:26] <didrocks> same to you seb128
[16:28] <kenvandine> good night
[16:29] <tseliot> jbicha: they are going to need the Unix Device Memory Allocator API to land in the kernel before they can fix the problem. This might take a while
[16:35] <tseliot> Laney: I replied. Thanks for reviewing the MP
[17:11] <Laney> tseliot: np!
[17:11] <Laney> goodnight!
[17:40] <immu> can someone tell me of why i cannot log into gnome session?
[17:40] <immu> gnome-wayland session?
[17:41] <gQuigs> immu: Ubuntu version?  LiveCD or install?
[17:41] <gQuigs> oh, and graphics card?
[17:41] <immu> i am on 17.10 builds
[17:42] <immu> i think i am running on intel gpu on built
[17:43] <gQuigs> immu: Live or installed?
[17:46] <immu> installed
[17:46] <immu> i am on hybrid graphics
[17:46] <immu> Intel+Nvidia750
[17:48] <gQuigs> immu: I'd guess it's related to that.. can you try full disabling the nvidia card in the BIOS and see if it works then?
[17:49] <immu> sure
[17:49] <immu> since i am on Alpha build i think i cannot switch to Nvidia GPU yet
[17:51] <immu> i am on Nouveau driver. so its using that
[17:59] <immu> also why is firefox stuck at 50.1.x
[18:06] <gQuigs> yea definitely try switching to intel
[18:07] <gQuigs> dev doesn't get security updates, and firefox is usually released that way,  likely worth making that work.. but that's how it is today
[18:10] <immu> when are things expected to be normal at what stage of the release cycle
[18:12] <kenvandine> immu, firefox 54 is in artful-proposed
[18:13] <kenvandine> not sure why it hasn't migrated to release yet
[18:15] <jbicha> because it doesn't build on architectures we care about but don't care about ;)
[18:16] <kenvandine> jbicha, lol
[18:16] <kenvandine> indeed
[18:18] <gQuigs> right, we've discussed that before :)
[18:20] <immu> but i am currently running on 50.1.0 firefox?
[18:20] <kenvandine> immu, that's what's in artful release yes
[18:20] <kenvandine> 54 is in artful-proposed, you'll get it after someone gets it building for all architectures
[18:20] <immu> okie :)
[18:21] <immu> tomm is alpha1 release date
[18:26] <immu> so what shall we see on release alpha1 date
[18:27] <immu> brb rebooting to kernel 4.11.x
[19:00] <immu> back
[19:02] <jbicha> immu: the development release does not get guaranteed security updates, some security updates get delayed a while
[19:03] <jbicha> but for Firefox, one workaround is to use the firefox-next PPA from the mozillateam; that will get you Firefox Beta instead of the latest stable release
[19:04] <immu> jbicha, i shall wait then will use google chrome for a while