[05:50] good morning [06:12] good morning desktoppers! [06:14] duflu, should we mention the test chromium packages (https://launchpad.net/~osomon/+archive/ubuntu/cr-vaapi-test/+packages) on http://wiki.ubuntu.com/IntelQuickSyncVideo ? === JanC_ is now known as JanC [06:19] hey oSoMoN [06:19] salut didrocks [06:49] good morning desktopers [06:49] good morning seb128 [06:50] lut oSoMoN, comment ça va ? [06:50] bien, et toi? [06:50] la nuit a été plus longue qu’hier? [06:50] bien, pas encore réveillé par contre [06:50] un peu ouais, mais elle aurait pu être plus longue :p [06:51] elles pourraient toujours être plus longues :) [06:51] :-) [06:56] re seb128 [06:57] oSoMoN, sorry you log on usually when I'm at lunch... Yes I would mention it on the wiki after confirming it works [06:58] Also... good morning didrock, oSoMoN, seb128 [06:58] hey duflu! [06:58] re didrocks [06:58] hey duflu, how are you? [06:59] seb128, today is a better day :) You? [06:59] duflu, I successfully tested that it works on my machine yesterday (you’ll need to turn on the #enable-accelerated-video flag in chrome://flags, it's off by default) [07:00] oSoMoN, Thanks, I will look [07:02] duflu, I'm not fully awake and I've a bit too many things on my todolist but I'm fine otherwise [07:02] reading about meson build system [07:02] jbicha, those GNOME updates switched to meson are not translators friendly :-/ [07:04] Oh I forgot I'll need to refresh the Kaby Lake machine. That's the only one that does VP9, and VP9 seems to be the only codec YouTube likes to use these days [07:13] oSoMoN, does that include intel's proposed patch? [07:14] Ah yes I see [07:14] duflu, yes [07:15] duflu, I haven't tested VP9, but http://distribution.bbb3d.renderfarming.net/video/mp4/bbb_sunflower_1080p_60fps_normal.mp4 was decoded and rendered fine at ~12% CPU on my X230 [07:15] oSoMoN, yeah cool. That's the perfect test for Ivy Bridge [07:23] oSoMoN, tried a Wayland session? I'm seeing the usual libva fails to init in a Wayland session. This causes a long delay on startup, and probably means VAAPI won't work there (because Chrome is an X app and libva requires DRI2, not DRI3 in Xwayland) [07:24] (you can see the error if you run chromium-browser from a terminal) [07:34] oSoMoN, Yes it's only working in Xorg sessions. We'll need to get a Chromium fix in as part of bug 1698287. Sadly there is no workaround to make it work in a Wayland session because it's an X11-only app [07:34] bug 1698287 in mpv (Ubuntu) "VA-API fails to initialize in a Gnome Shell Wayland session" [Medium,In progress] https://launchpad.net/bugs/1698287 [07:34] The fix is to just tell the app to try the wayland platform before trying x11 [07:38] It's also a bit unstable but that's not surprising for Chromium 62 [07:39] duflu, yeah [07:40] oSoMoN, still looking good considering it's early days. That same initialization bug needs fixing in multiple locations [07:47] oSoMoN, actually a proper fix for Wayland sessions might not come till Chromium moves from X11 to Wayland. Do you know if people are working on that still? [07:47] no idea, I'll need to check again [07:48] It could also be fixed if someone enhanced libva to support DRI2, but that feels like investing in old technology [07:49] I mean to support DRI3. It already supports DRI2 [07:49] Maybe not so old [07:49] yeah, I’ve seen in the bug report that you consider this unlikely to happen [07:50] oSoMoN, don't know. Seems there are multiple Intel engineers working on the various related projects [07:50] Anything could happen [07:51] it'd be good to have a POC at intel to inform us about their plans [07:56] oSoMoN, anyway if you want to play local MP4 files I will soon have totem and mpv fixed for out-of-the-box support in both Xorg and Wayland [07:56] I mean I have the fixes. Just distro patches to do [07:56] nice [07:57] morning willcooke [07:57] willcooke, https://forum.snapcraft.io/t/sharing-files-via-tmp/1613 to follow up on our conversation yesterday [08:01] o/ [08:05] https://blogs.igalia.com/tonikitoo/2017/05/17/chromium-musozone-update-h12017-wayland-x11/ [08:05] afternoon duflu. I'm getting this error: http://paste.ubuntu.com/25270562/ [08:06] wait, hold on - I think I was in a Wayland session as well, even though I told it not to [08:07] willcooke, good morning. You just missed me discussing that error with oSoMoN. It is https://bugs.launchpad.net/ubuntu/+source/intel-vaapi-driver/+bug/1698287 [08:07] Ubuntu bug 1698287 in mpv (Ubuntu) "VA-API fails to initialize in a Gnome Shell Wayland session" [Medium,In progress] [08:07] But there is no simple workaround for Chromium :/ [08:07] Other than "Log in to X" [08:08] hey willcooke [08:11] CPU usage goes from ~ 100% to ~ 50% [08:12] so that's a win [08:12] willcooke, oh good news in that area: https://www.igalia.com/nc/igalia-247/news/item/three-new-people-join-igalia/ [08:12] Eleni was working on Chromium with Andy for a while [08:17] seb128, is it better if my future sponsorships are not assigned? Do people get confused if they are assigned? [08:19] duflu, from that igalia reported dated from the 17th of May, there's active development and progress, but it doesn't look like it's been upstreamed yet [08:19] http://imgur.com/a/dG08X [08:19] before on the left, after on the right [08:21] oSoMoN, It is a hard problem. Chromium basically needs to become a display server, and each tab is a client [08:21] willcooke, I was hoping for a bit lower. What CPU is that? [08:25] Ah, never mind. I get about the same (adjusted for the fact I'm looking at a desktop server CPU) [08:29] duflu, no, I think assigned is fine, did anyone comment saying it's confusing? [08:29] duflu, sponsors tend to assume that if it's assigned to somebody who has upload right then that person is going to deal with the upload, but since you don't have upload rights there should be no confusion [08:30] seb128, I just recall seeing something on that topic in related wiki pages (syncs and SRUs). [08:30] Although these are not syncs or SRUs [08:30] right [08:30] well usual rule is to not assign to the people you need [08:31] e.g don't assign the bug to sponsors or sru team [08:31] just subscribe [08:31] but keeping it assigned to yourself is fine [08:44] morning [08:44] something odd happenened just now [08:45] did you guys see my messages from 09:05 and 09:19? [08:45] it's now 09:45 [08:46] willcooke, I saw [08:46] CPU usage goes from ~ 100% to ~ 50% [08:46] so that's a win [08:46] http://imgur.com/a/dG08X [08:46] before on the left, after on the right [08:48] hum, python packaging question [08:49] if a package is shipping python files to a private dir, is it useful to byte compile those and if so is that something the tools can do for you or that you need a postinst/rm for? [08:50] e.g https://github.com/fossfreedom/alternative-toolbar/blob/debian/debian/postinst [08:50] (cyphermox raised that one as a weird thing to do in his MIR review) [08:51] wb willcooke [08:51] :) [08:51] still better than slack [08:51] ;D [08:56] willcooke, Yes we saw and replied. That's bug 1698287 [08:56] bug 1698287 in mpv (Ubuntu) "VA-API fails to initialize in a Gnome Shell Wayland session" [Medium,In progress] https://launchpad.net/bugs/1698287 [08:57] duflu, cool! (Didnt see replies cos netsplit) [08:58] duflu, I've got to jump on another call now, will be late for bluetooth meeting (or might not make it, sorry) (cc seb128) [08:58] willcooke, Not cool though. It requires a native port of the browser to Wayland really (if in a Wayland session) [08:58] OK, late is cool [08:58] @ browser - Ah, I see [08:59] Or someone to greatly enhance libva [08:59] or Xwayland [08:59] heh [09:04] duflu, chromium refuses to start for me so I'm going to be a bit late for the bluetooth meeting as well [09:04] No one there but me [09:06] is Konrad not around this week? [09:10] seb128, well he's not in IRC or the hangout. But is writing emails [09:10] seb128, that's OK. Let me give you another debdiff :) [09:10] duflu, if neither Konrad or Will are around and I'm fighting with chromium (and firefox doesn't do hangout) let's skip [09:10] haha [09:11] You think I'm kidding [09:11] * seb128 hides [09:14] Crap. I closed the hangout by mistake [09:16] seb128, no hurry. After the meetings I'm at EOD... https://bugs.launchpad.net/ubuntu/+source/mpv/+bug/1708102 [09:16] Ubuntu bug 1708102 in mpv (Ubuntu) "Enable hardware video decoding by default in mpv" [High,In progress] [09:16] duflu, let's skip the hangout as said, unless willcooke finishes his other meeting and want to chat a bit there [09:17] That's fine. I'm still there in case Will has time [09:18] duflu, debdiff looks fine, it's usually better to list the files you change in the debian/changelog though [09:18] like instead of "* Enable hardware acceleration by default" [09:18] you would have [09:18] * debian/mpv.conf.ubuntu, debian/rules: [09:18] - Enable hardware acceleration by default [09:18] seb128, I was aiming to make readable changelogs. I thought that style was low value but I can do both in future [09:19] Too many people write unreadable changelogs [09:19] fair [09:19] the details on what files are impacted by a change make merges on debian a bit easier though [09:19] Yeah [09:19] especially when there is no packaging vcs to dig the commits [09:20] seb128, I can make another one if we're not meeting [09:20] duflu, don't bother redoing that one [09:20] it's for next time [09:36] unping about my python packaging question from earlier if anyone read that [09:38] I'm sure that's not a verb [09:38] Neither is ping though [09:39] it so is a verb amongst IRC people :) [09:39] hey pitti! wie gets? [09:39] it's even a (made-up) strong one :) ("he pung", as some people like to say ☺ ) [09:39] seb128: ça va seb128 ! merci, je vais bien ! [09:40] ça va bien ici aussi merci ! [09:40] seb128: j'attends avec impatience nos vacances, ils commencent ce vendredi pour trois semaines [09:44] Hi pitti [09:44] duflu: hello! *wave* [10:19] pitti, où est-ce que vous allez en vacances ? [10:21] seb128: on va à la côte de Ouest des État-Unis [10:21] seb128: for the total eclipse, pour des parcs nationals, pour visiter l'usine de Boeing, etc. [10:22] ah, nice [10:22] pitti, enjoy! [10:23] seb128: merci ! je suppose que vous reste chez vous, avec votre petit enfant ? [10:24] pitti, oui, ici et visiter nos familles en France [11:13] popey, hey, change the dbus monitor command from yesterday by "dbus-monitor interface='org.freedesktop.Notifications'" [11:20] seb128: is it meson or is it LP: #1688994 ? [11:20] Launchpad bug 1688994 in pkgbinarymangler (Ubuntu) "dh-translations: cannot build POT without intltool" [High,New] https://launchpad.net/bugs/1688994 [11:20] good morning [11:22] jbicha, that's the same thing [11:22] is that there seems there is no equivalent to "intltool-update -p" in the new build systems [11:23] I can't find how to update it manually with one command equivalent to ^ either [11:23] then if there is one we need to update the tools [11:23] intltool was already being dropped by GNOME before the meson switch :( [11:24] but I think meson requires dropping intltool? so it's getting worse :( [11:25] right, well under autotools&gettext we had standard make targets still [11:26] that seems to not even be the case anymore with meson [11:26] I asked about it on the gnome #i18n channel, let's see [11:26] otherwise I guess we are going to need to overwrite the dh_translations call in debian/rules for a bunch of packages until there is a proper solution [11:26] that wouldn't be the end of the world, that set of package is limited [11:27] still it's more work and annoying [11:28] let me know when you have the debian/rules override and I can start adding it to packages [11:29] will do, thanks [11:29] I'd like to cherry-pick https://github.com/hughsie/appstream-glib/commit/9df56f26f [11:29] one for Laney [11:30] it might cause a few packages to ftbfs because the dh_install rules assume the old directory but I'd rather fix that now than in a few weeks [11:30] right [11:31] popey, do you use "solaar"? [11:32] i don't know what that is [11:32] so no [11:32] "Solaar is a Linux device manager for Logitech's Unifying Receiver peripherals" [11:32] upstream guessed it might lead to issue like your power notification [11:32] no then, i have no logitech devices [11:32] popey, anyway, did you see my updated command? please get the log and then we hopefully know what the issue is :-) [11:33] ah, you updated it? let me see [11:33] i have been draining the laptop battery for a bit so I can plug it in and capture any output, will update the command to make sure I get the right stuffs [11:34] thanks [11:34] seb128: should I stop doing 3.26 updates until the translation problem is fixed/worked around? [11:34] jbicha, no, keep going, we still have the current template so worth cases we miss a few strings and I'm going to sort that out in the coming week [11:35] ok [11:35] tkamppeter: seeing bug 1709572 on Xubuntu since your change last Friday [11:35] bug 1709572 in system-config-printer (Ubuntu) "system-config-printer.py crashed with ValueError in require_version(): Namespace Secret not available" [Medium,Confirmed] https://launchpad.net/bugs/1709572 [11:36] jibel: could you consider adding installing Chrome to the gnome-software test plan? see LP: #1708936 or LP: #1672424 [11:36] Launchpad bug 1708936 in gnome-software (Ubuntu) "GNOME Software 3.20.5 doesn't install 3rd party deb's, doesn't prompt for authentication" [Critical,Confirmed] https://launchpad.net/bugs/1708936 [11:36] Launchpad bug 1672424 in gnome-software (Ubuntu Zesty) "Cannot install Debian files outside of the repositories" [Critical,Fix released] https://launchpad.net/bugs/1672424 [11:37] flocculant, it should have a depends added on gir1.2-secret-1 [11:37] tkamppeter, ^ [11:37] on that note it's lunch time, bbl [11:38] seb128: thanks - adding that package and all is well with the world :) [12:01] seb128: success! :D [12:01] (updated bug 1709194) [12:01] bug 1709194 in gnome-power-manager (Ubuntu) "Power notification appears with no detail" [High,Incomplete] https://launchpad.net/bugs/1709194 [12:15] willcooke: that issue I mentioned about apps taking 10+ seconds to start. found an AU post which has a solution. kill all apps, kill gnome-keyring-daemon, re-launch and then launch apps, everything launches instantly! [12:15] https://askubuntu.com/questions/788075/ubuntu-16-04-some-applications-take-too-long-to-start-up [12:15] worth remembering! [12:18] popey: do you have a bug # for that? [12:19] not yet, but it only happened today and I'm on 16.04 [12:19] will file it in moment [12:20] does that issue happen with 16.04 too? [12:21] I am on 16.04, and it happened here. willcooke said he'd seen it on 17.xx at some point too. I have only seen it on 16.04 [12:21] because I am a heavy 16.04 user, and only lightly use 17.xx [12:27] bug 1689825 looks to cover it [12:27] bug 1689825 in lightdm (Ubuntu) "gnome-keyring not unlocked on boot" [Undecided,Confirmed] https://launchpad.net/bugs/1689825 [12:27] people suggesting removing/purging dbus-user-session as a workaround/solution [12:29] popey: dbus-user-session will totally break 16.04 [12:29] we only started work on that for 16.10 [12:29] popey: the trigger for that bug is the flatpak ppa, I emailed Alexander Larsson about it a few weeks ago and got no response yet [12:30] oof [12:30] i do have that ppa on my system, good catch! [12:31] do we need an upstream bug? [12:33] upstream is talk to the PPA dev, maybe you'll have better luck than I did ;) [12:34] heh, okay [12:35] challenge accepted [12:37] popey: do you have a Facebook account? would you be interested in verifying this bug https://bugzilla.gnome.org/show_bug.cgi?id=785726 and its SRUs? [12:37] Gnome bug 785726 in general "facebook: Cannot add a new account with Graph API > 2.3" [Normal,Resolved: fixed] [12:38] using GNOME Online Accounts [12:38] jbicha: will take a look [12:39] I didn't prepare the SRUs yet [12:39] jbicha: lemme know when you have a deb I can try? [12:39] could you verify the bug first? ;) [12:39] I don't have a FB account [12:41] oh, hah, on 16.04 or 17.10? [12:42] either one, I haven't fixed it on 17.10 yet because I wanted to verify the bug before fixing it [12:43] ok, will try both [12:49] jbicha: success. https://twitter.com/gnomealex/status/895263690982928384 [12:54] jbicha: that facebook bug isn't exactly clear from a user perspective what the effect is. I connected my 17.10 system to facebook. Not sure how to confim whether it did or not. [12:56] if you can still connect your account, then it might not be an important enough bug to SRU [12:58] it certainly seems a bit broken. Now I added an account I can't view it or add another [13:01] popey: could you file a LP bug for the FB issue that I can use for SRU tracking? [13:04] flocculant, seb128, bug 1709572 fixed. [13:04] bug 1709572 in system-config-printer (Ubuntu) "system-config-printer.py crashed with ValueError in require_version(): Namespace Secret not available" [High,Fix committed] https://launchpad.net/bugs/1709572 [13:05] kenvandine (cc willcooke and jamesh): fyi, https://github.com/ubuntu/snapcraft-desktop-helpers/pull/68. I'm not sure who is tasked with getting snaps to run under wayland, but that PR gives some clues [13:06] kenvandine (cc willcooke and jamesh): you might want to see https://forum.snapcraft.io/t/wayland-dconf-and-xdg-runtime-dir/186/10 [13:06] jdstrand, thx! [13:06] not sure who is working on that, but i'll make sure this gets looked at [13:07] kenvandine (cc willcooke and jamesh): note that PR shouldn't be committed as is (see comment I added today), but it highlights the things to be considered. the env vars and the symlink (we may not always need the symlink, see later responses to the forum post) [13:08] kenvandine (cc willcooke and jamesh): I didn't look very hard, but it seems that gdk-pixbuf-query-loaders may be sensitive to the wayland env vars [13:08] jbicha: bug 1709621 [13:08] bug 1709621 in gnome-online-accounts (Ubuntu) "Facebook login appears broken" [Undecided,New] https://launchpad.net/bugs/1709621 [13:09] kenvandine (cc willcooke and jamesh): not saying anything to be done there-- just keep an eye out for it [13:10] didrocks, ^^ [13:10] didrocks, is that desktop helpers PR for wayland support something you can look at? [13:11] thanks for helping coordinate that work [13:11] jdstrand, thanks for pointing it out [13:12] kenvandine: not nowdays, I'm on default experience for our desktop [13:12] kenvandine: I think you are way closer than I am now due to handling the platform snap, are you happy to look at this? [13:12] sure [13:16] kenvandine: since you are looking at it, note that jamesh and I have been discussing how this might fit into his portals work which would remove the need to setup the symlink, but that is farther out [13:17] kenvandine: that's all in the forum [13:17] jdstrand, thx [13:17] jdstrand, yeah doesn't help for 17.10 [13:17] kenvandine: I submitted https://github.com/snapcore/snapd/pull/3690 yesterday (for wayland interface). I expect that to land quickly [13:18] kenvandine: well, afaik his portals work is 17.10 material, but its snapd, so it can float in at any time [13:19] kenvandine: when pr 3690 lands, it'll need something along the lines of the snapcraft-desktop-helpers pr for people to use it [13:20] kenvandine: lastly, I am creating preliminary new interfaces for gnome-shell that uses only modern apis (tentatively called 'desktop') [13:20] jdstrand, so wayland as a new interface means app developers will need to specify that interface in their snap. I fear some apps that should work will just fail [13:20] kenvandine: eg, no dbusmenu, etc, etc [13:20] wouldn't it be better for the desktop interface to support both wayland and x11? [13:21] ie app developers not care if it's wayland or x11, it's just a desktop [13:21] kenvandine: this is a complicated topic but is following the existing paradigm [13:21] kenvandine: that is true, but we want to be able to have people disconnect them [13:22] ie, if I'm using wayland, I should be able to disconnect the x11 interface [13:22] yeah, maybe super-interfaces? that bundle them [13:22] but i bet this has been discussed :) [13:22] that is sorta what unity7 is now, and I think tht is a mistake [13:23] unity7 includes access for x11 [13:23] in that case, it made some sense-- it couldn't run without it [13:23] but with the new 'desktop' interfacec, it could run with either wayland or x11 [13:24] from a desktop users perspective, they usually aren't going to understand the difference in x11 or wayland or even know which they are running [13:24] kenvandine: my plan is to get the policy together, submit the PR and then ping you and jamesh to participate in the discussion [13:24] kenvandine: that's fine-- the developer will likely do [plugs: wayland, x11, desktop] [13:24] jdstrand, sounds good, thanks [13:25] kenvandine: they'll all autoconnect, but then a security conscious person can 'snap disconnect foo:x11' [13:25] ok [13:25] that's reasonable [13:26] I think it is reasonable for a developer to specify where it is expected to work [13:26] chrisccoulson, when opening an attachment in thunderbird or a file in firefox, the file is written to /tmp and handed over to xdg-open (I assume). Do you know whether we can easily change the default location so that it would be somewhere under $HOME ? [13:26] since they have to test in all those places anyway [13:28] in the case of gnome-shell, it probably makes sense to plugs x11 by default in this transition period because mutter depends on Xwayland for a few things and wayland snaps sometimes connect to Xwayland for things [13:29] tkamppeter, thanks for fixing the s-c-p missing depends [13:29] trying to force not using x11 would be a poor user experience. but, to support moving forward, we should be able to let people disconnect x11 so people can try it out [13:29] kenvandine: ^ [13:29] jdstrand, you might want to leave appindicator access [13:29] yeah [13:29] jdstrand, you were working on snaps under wayland so we stayed out of it ... should we pick it up? [13:29] kenvandine, ^ [13:29] seb128, jdstrand did the interface [13:29] i need to tweak some stuff for desktop helpers [13:30] seb128, i'm going to pick up that part [13:30] tkamppeter: thanks :) [13:30] but i guess i need the interface to land [13:30] or learn how to run my own snapd again :) [13:30] i had a script for that at one point :) [13:30] seb128: I've only been working on a part of it. willcooke and I sync'd at the product sprint. I'm tasked with the wayland interface and a base set of policy for the new 'desktop' interface. getting the snapcraft-desktop-helpers to work, the gnome platform snap, etc, etc is for the desktop team [13:31] seb128, and jdstrand had some good pointers for what needs tweaking [13:31] I really needed to get something going though, so I did that snapcraft-desktop-helpers PR to help you [13:31] kenvandine, ok [13:31] (I was blocked) [13:31] jdstrand, we appreciate it :) [13:32] jdstrand, right, fair enough, I though the wayland interface didn't land yet and was a pre-requirement to test the other bits [13:32] jdstrand, i'm having a terrible time with classic snaps... i had 2 classic snaps yesterday that ran one time [13:32] but won't start again :/ [13:32] seb128: it hasn't landed, but is in a PR as of yesterday. it willland soon [13:32] seb128, it's in a PR [13:33] it is currently a single rule, so it is easy to test. snap install foo; snap connect foo:gnome-3-24-platform ... ; edit /var/lib/snapd/apparmor/profiles/snap.foo.foo to have the wayland rule ; apparmor_parser -r ... ; launch the app [13:34] I'm happy to help with advising how to test stuff [13:34] jdstrand, ok [13:34] kenvandine: oh, one other thing [13:35] kenvandine: running gnome-sudoku under wayland on xenial results in: (gnome-sudoku:3064): Gdk-WARNING **: Wayland compositor does not support xdg_shell interface, not using Wayland display [13:35] jdstrand, but that's after i'm running your snapd branch right? [13:36] kenvandine: if you use my snapd branch you don't have to do anything special (it adds the rule) [13:36] oh, i can add the rule without rebuilding snapd? [13:36] kenvandine: oh, well, you need to plugs wayland :) [13:36] ah, just apparmor :) [13:36] kenvandine: yes. if you don't want to rebuild snapd, just tack the rule on the profile [13:36] ah, cool! [13:37] kenvandine: snapd will refresh the profile though on reboot, reinstall, connect/disconnect, etc, so be aware of that [13:37] cheating ! [13:37] :) [13:37] that's a great cheat though [13:37] it's convenient [13:38] I use it when developing interfaces to quickly iterate [13:38] when I'm happy, I copy it all over to the interface and then build a new snapd, retest [13:39] kenvandine: you saw the gnome-sudoku comment with wayland on xenial comment above? ^ [13:39] yeah, i'll need to look into that [13:39] i guess it fell back to xwayland? [13:40] seb128, kenvandine: this actually worries me since I think it gets into the conversation with niemeyer re the gnome-3-24 snap. using gnome-3-24 with wayland doesn't work with xenial's wayland [13:40] kenvandine: well, no, cause I removed rules allowing to talk to X :) [13:40] :) [13:40] jdstrand, well we won't be running wayland on xenial [13:41] kenvandine: in *my* testing, I didn't plug unity7 or x11 [13:41] kenvandine: then the desktop helper will likely need to be even smarter [13:42] kenvandine: because there are only series 16 snaps today [13:42] indeed [13:42] but 17.10 will be wayland and 16.04 will be x11 [13:42] for Ubuntu default install [13:42] snaps go way beyond that [13:42] yes [13:43] but for the average desktop user, 16.04 users will be running unity7 [13:43] popey: shotwell doesn't support GOA yet [13:43] I agree it is unlikely to have many users on 16.04 using wayland in Ubuntu. but, derivatives or other distros that have an incompatible wayland with what is in the gnome-3-24 platform snap-- these are considerations [13:44] I wonder if there is a way to query the wayland socket for capabilities or version or something [13:45] I don't know if mutter supports that [13:46] but it is a little concerning that we already see an incompatibility between what is in 16.04 and what is in gnome-3-24 [13:46] jdstrand, so you were running gnome-shell on 16.04 with wayland right? [13:46] kenvandine: yes [13:47] kenvandine: I abandoned the gnome-sudoku snap for testing that. I grabbed the gnome-logs-udt snap from the store (3.18 libs embedded) and hacked its wrapper to force wayland to test [13:48] the env var setup and symlink from the pr I pointed you at all worked fine for that [13:48] btw, there is a gnome-3-18 content snap in the store, but I don't know of anything that uses it [13:49] jdstrand, yeah [13:49] kenvandine: so, I think that's my full brain dump [13:49] jdstrand, appreciated! [13:50] i'll try to dig into that more [13:50] kenvandine: thanks! [14:02] kenvandine: oh, one more thing-- I wasn't able to locally snapcraft cleanbuild gedit or gnome-sudoku. probably because I was using xenial apt sources [14:03] jdstrand, yeah... you have to include the backport PPA [14:03] which i don't think you can do in cleanbuild [14:03] LP lets you build with the PPA though [14:10] shrug [14:10] jdstrand, those problems you listed on the forum are not specific to the platform are they? [14:11] jdstrand, we would have the same wayland on xenial issue with gtk bundled with the app [14:11] jdstrand, same for using dbus services [14:12] seb128, i think you are right [14:13] seb128: they are not specific to the platform in that any content snap might have related issues. why I believe it is relevant is that it doesn't work on the same series the base snap is even built from (ie, 16.04 with series 16 snapd). it then may be 'specialized' and something the publisher needs to make sure consumers use correctly [14:14] jdstrand, I don't understand how that has to do with "content" [14:14] jdstrand, the alternative for an app developer would be to build gtk and all the depends into their snap, which would run into the same issue [14:14] jdstrand, if you built gedit with that ppa bundling the libs you would have the exact same issues no?. [14:14] put another way-- you want the world to auto-connect to this content interface, but the world won't work properly [14:14] how so? [14:15] it would work as properly as if they bundled the same content [14:15] it's the base issue that any flatpak or snap have, backward compatibility and services [14:15] this conversation should be done in the forum. niemeyer needs to be present [14:15] jdstrand, the topic you commented on is that conversation [14:15] to me, a content snap that anything is allowed to connect to should reasonably work on the series it targets [14:16] but I don't understand what he tries to say [14:16] seb128: yes, but we are now talking here :) [14:16] and it's going in loop [14:16] niemeyer isn't here [14:16] it would work in the desktop environment provided in the LTS, gnome-shell is universe in 16.04 [14:16] kenvandine: but snapd != Ubuntu [14:16] jdstrand, right, I though you might be able to make me understand what he means because the discussion is going nowhere on the forum [14:16] I guess I just going to give up [14:16] seb128: I am not representing niemeyer. I mentioned a concern I have about socket protocols and services [14:17] jdstrand, right, and I was asking why you think your concern about socket protocols and services wouldn't impact apps that bundle the same content [14:17] which is what I don't understand [14:17] because I don't think that the content interface design is handling well [14:17]