[02:18] jamesh: hey [02:18] i'm definately getting portals for file open and save as dialogs [02:20] okay [02:20] but not for launching URLs/files? [02:20] running the portals with --verbose I can see the output [02:20] nope [02:20] never hits the portal daemons [02:21] are you running the portal packages from the archive? [02:21] or maybe something newer that you've been hacking on? [02:21] fwiw, I don't think there is any verbose output for the OpenURI actions [02:21] oh [02:21] maybe that's why :) [02:21] but... [02:21] I was testing focal's xdg-desktop-portal [02:21] in firefox's stdout i see the attempts to exec /snap/bin/evince [02:22] ah. [02:22] it can see /var/lib/snapd/desktop/applications [02:22] and it should... right? [02:23] even with GTK_USE_PORTAL=1 set, it will prefer locally available handlers [02:23] portal-test does the right thing [02:23] browser-support grants access to /var/lib/snapd/desktop/applications, but probably shouldn't. I've mentioned it to jdstrand a few times [02:24] it can't do anything useful with that data, and it is an information leak [02:24] try opening a file with a mime type not covered by any of your snap applications [02:25] I didn't have the libreoffice snap installed, so it was the .deb libreoffice snap that was being launched when I tried to open .docx files [02:32] jamesh: if i remove all my pdf handling snaps it works [02:32] i had 7 snaps installed that claim to handle pdf :) [02:32] I guess removing that apparmor rule from browser-support is a priority now [02:32] if i open the drop down to select a different handler it now shows no apps [02:33] that UI should be provided by portals? [02:33] My guess is that it was added in a reactive "browsers seem to be trying to access this path, so lets allow it" way, rather than because they need it [02:33] can you raise that with jdstrand again? [02:33] yeah [02:33] Do you mean the Firefox UI that asks if you want to open or save, or the portal one after asking you which app to launch? [02:34] which app to launch [02:34] it defaults to "system handler" [02:34] We can't offer application choice in the Firefox UI, because the sandboxed application can't know what's available [02:34] portal-test gives me the portal's selector [02:34] the "System Handler" part is normal (although a bit ugly) [02:35] i guess that uses a different API? [02:35] that's coming from Firefox itself, special casing for portal support [02:35] https://dxr.mozilla.org/mozilla-central/source/toolkit/system/gnome/nsGIOService.cpp#58 [06:38] good morning all [06:46] morning jibel [06:48] hi jamesh, how are you? [06:48] Hi jibel [06:48] and jamesh [06:49] hi duflu [06:51] It's interesting times. They just announced a travel ban for all non citizens or residents entering the country from tomorrow here [06:54] confined at home with the kids is interesting too [06:55] My mother has brought forward her travel home by a week (she's been working in the UK for the last month or so) [07:28] gooood morning desktopers [07:29] Hi seb128. How goes? [07:29] duflu, doing fine with the current context! you? [07:29] Heh, yes, same. Though I miss the outside world. Will get back to it on Sunday [07:30] good morning [07:30] Hi didrocks [07:30] lut didrocks, comment ça va ? [07:31] hey duflu [07:31] salut seb128. ça va, et toi ? [07:31] ça va aussi [07:31] :-) [07:34] seb128, I haven't forgotten about your email. Just wanted to make sure everything else in progress isn't waiting on me before I try learning a new project/codebase [07:35] duflu, k, thanks, also it sounds like you are wanting to make some free cycle to poke at that so that's good news :) [07:36] same for most days really - finish what I started before starting anything new [07:37] duflu, btw, I've emailed Hans about my flicker, turned out to be an i915 bug, I reported upstream as https://gitlab.freedesktop.org/drm/intel/issues/1476 (mentioned as a follow up/in case you are curious still about the issue) [07:37] drm issue 1476 in intel "i915 fastset failing on XPS 13 7390" [Community, Feature: Display/Other, Platform: Kbl, Opened] [07:41] seb128, is that flicker or the corruption? [07:41] good morning desktoppers [07:41] which might also have flickered [07:41] Hi oSoMoN [07:41] hey duflu [07:41] lut duflu [07:42] salut seb128 [07:43] duflu, that's the plymouth flicker and the logo shifting is a side effect of the modeset according to Hans, I didn't report the session video corruption yet since I'm trying on 5.6-rc and didn't hit the bug there yet [07:43] On that note I had the idea of switching to radeon or nouveau briefly to try and prove my big flicker issue is i915 [07:43] ups [07:43] salut oSoMoN ! [07:43] lut oSoMoN I meant, comment ça va ? [07:44] salut didrocks [07:44] seb128, bien, et toi? :) [07:45] ça va :-) [08:22] oSoMoN: I had some ideas about how you could move forward with https://bugs.launchpad.net/snapd/+bug/1863625, but it turned into a (temporary) dead end [08:22] Ubuntu bug 1863625 in snapd "Need an xdg-email wrapper, similar to the xdg-open one" [Medium,Triaged] [08:24] duflu, we seem to disagree on using "fix commited" for GNOME bugs which have a fix commited upstream :-( [08:25] duflu, can I convince to not change those back to triaged? it makes bugs lists more difficult to browse then, since from the list you can't tell that the bug is being handled/doesn't need more than waiting for the next update to land in Ubuntu [08:26] oSoMoN: hi, would you be willing to consider linking libnssckbi.so in firefox/thunderbird to /usr/lib//pkcs11/p11-kit-trust.so in order to fix bug 1647285? [08:26] bug 1647285 in ca-certificates (Ubuntu) "SSL trust not system-wide" [Wishlist,Confirmed] https://launchpad.net/bugs/1647285 [08:26] duflu, your status is might be theoritically correct but at an efficiency cost on handling of bugs and I think it doesn't benefit anyone, neither us nor our users if we waste more time than needed on launchpad [08:28] seb128, my concern is that users don't understand "Fix committed" and then ask why the bug still isn't fixed. Also Marco and I have been using the 'fixed-upstream' tag for that for a while, so might you consider that? [08:28] duflu, tags are not visible from the bug lists so they don't solve my problem [08:29] when I review e.g gnome shell bugs I just have a stack of Triaged ones and I can't tell appart which ones need work and which ones don't [08:29] where "need work" means debugging/fixing work, e.g are not already in the process of being fixed by just updating [08:30] I feel it's something we shouldn't do, but I understand your concern. Also, most are not in the state you want: https://bugs.launchpad.net/ubuntu/+bugs?field.tag=fixed-upstream [08:32] seb128, advanced search has a tick box 'Show bugs that are resolved upstream'. I wonder if that works? [08:33] that somewhat works [08:33] it's not able to tell if it's fixed in the same component [08:34] Yeah but it's only 21 bugs to fix [08:34] so gets confused if it has several upstream watches and one closed and one open [08:34] up [08:34] That's a fair point [08:34] anyway, I made my point [08:35] there are other ways to find those bugs [08:35] it's just that fix commited is what messages the more clearly from bugs lists that an issue is handled, you can even don't list those [08:35] but yeah, it comes to the price of confusing a bit some users sometime [08:36] (though I usually do add a comment saying it has been fixed upstream and the fix will land with the next update when I change the status) [08:40] People are already confused. I forgot I wanted to give a lightning talk about all things in Launchpad that mislead people [08:40] Like they can't tell when a bug is closed and carry on with it [08:41] same in every bug tracking system, people keep commenting on closed bugs on github for instance [08:41] It was the same on Track [08:41] I don’t think we can aim at avoiding that [08:41] Sure you can, just better UI/web design [08:44] seb128, I think if there was a packaging branch with a fix committed early then we'd both agree on the status. I think the main issue really is that there hasn't been (like https://git.launchpad.net/~ubuntu-desktop/ubuntu/+source/gnome-shell). If we declare Fix Committed when something is just fixed upstream then there may be an indefinite lag and no guarantee of it reaching distro even within one cycle or ever [08:46] So Fix Committed creates false expectation even for those who know what it means [08:46] well, if it’s fixed upstream in a version like 3.36.0 and we have 3.35.91, we know we’ll switch to the released version [08:46] released as "stable" [08:46] That's a good case for an exception [08:46] and so, that it will reach the distro this cycle [08:46] jamesh, ack, thanks, that's useful even if not applicable right now [08:47] OK, I will update 3.35.9x bugs to Fix Committed, seb128 [08:51] oSoMoN: yeah. If we're not doing any "snap userd" specific work, it's not clear it's worth reimplementing a tool like that [08:52] Done, seb128 [08:54] tjaalton, looking into this [09:01] oSoMoN: great, thanks [09:03] moin [09:03] hey Laney [09:04] hey Laney [09:08] duflu, thanks! [09:09] duflu, and yeah, I don't suggest using "fix commited" for random projects on launchpad which might not see a new version for years, I use it as a special rule for GNOME mostly [09:10] hey tjaalton, Laney, how are you? [09:12] seb128, also beware we are in the territory of 3.36.1 fixes, which are committed upstream :) [09:13] duflu, that's fine, we do plan to get .1 in focal :) [09:13] seb128: howdy, doing great [09:14] moin oSoMoN didrocks seb128 [09:15] yeah not too bad I guess! [09:15] you? [09:18] doing good here! [09:19] doing fine [09:19] duflu, hi! Saw your comment on https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/1866194 [09:19] Ubuntu bug 1866194 in pulseaudio (Ubuntu) "[Zoom USB audio on Dell Inspiron 7370] shows up in the sound output options but the sound keeps being emitted from the internal laptop speaker" [High,New] [09:19] today is my "work day" :) [09:19] duflu, the thing is I can trigger this with two very different sound interfaces: a USB microphone and a BT headset [09:19] not my try-to-strech-to-get-work-done-while-watching-kid day [09:20] duflu, so in my case I'm not sure if this is specific to a sound peripheral... maybe more to the device itself (and its internal component) [09:20] pieq, yeah I think you're right. I periodically see similar issues on different devices, but not with every peripheral [09:20] So different bugs [09:21] argh.... I don't know how to tackle this [09:21] a colleague was saying that basically when the issue is fixed for one person, it brings a regression for someone else... [09:21] pieq, upstream is responsive and helpful: https://gitlab.freedesktop.org/groups/pulseaudio/-/issues [09:22] duflu, ha? I'll check it out then [09:22] In fact I should have directed you there already. I forgot [09:22] but maybe we should consider some test cases to make sure newer versions of PA don't break things on existing models [09:22] tjaalton, you wrote in comment #22 that nss should have everything in focal, yet /usr/lib/x86_64-linux-gnu/nss/libnssckbi.so is not a symlink to p11-kit-trust.so [09:23] duflu, no worries. I'm very bad at going upstream myself... I'll check this out later [09:23] oSoMoN: that's fine [09:23] tjaalton, (I know this is independent from the situation in firefox and tbird, because they ship their own copy of nss) [09:23] pieq, if you look hard enough this kind of bug never went away, but also never occurs on many machines [09:23] pieq, the bug you mentioned, is that new or did it exist for you in e.g bionic? [09:24] duflu, that's the problem... it's here enough to be annoying to a big enough fraction of the users, but it's not spread enough that it's easy to trigger/debug/fix [09:24] tjaalton, so how is this going to work for other apps using the system-wide copy of nss? [09:24] seb128, it's new. I had 19.04 and 19.10 previously on this laptop [09:24] pieq, anyway upstream knows the right questions and commands to try [09:24] oSoMoN: I'm referring to comment #6 which mentioned that at least 3.30 would be needed [09:24] seb128, worked well enough, and when I put 20.04 daily, this bug appeared [09:24] pieq, that's the sort of information that would be useful to include in the report [09:24] pieq, when did you start testing focal? [09:25] seb128, argh I thought I mentioned it, but I didn't. I'll update the bug description [09:25] This is why I keep a growing list of ISOs, so you can bisect when it's unclear what package is the issue [09:25] seb128, shortly before I open this bug [09:26] I think Debian is automating that kind of thing? [09:26] seb128, I was tricked by jibel who told me everything was fine [09:26] on 20.04 daily [09:26] ;) [09:26] tjaalton, but my understanding of comment #4 is that the symlink is needed nonetheless [09:26] k, so after we updated pulseaudio, which doesn't make easier to knowif that's pulseaudio or something else in focal [09:27] seb128, this laptop has been certified. I could check the OEM image (bionic) but I don't think it's very useful since it didn't happen on 19.04/19.10 [09:27] oSoMoN: ok, I'll leave that open then. but it doesn't concern ffox/tbird :) [09:28] on that note... why is "disco" still listed in launchpad? https://launchpad.net/ubuntu/+source/gnome-shell [09:28] It hit EOL in January [09:28] tjaalton, I know, I was just trying to understand the bigger picture. Doing that symlink in firefox and thunderbird sounds okay to me, but I'll ask the security team for their opinion, as I probably don't understand all the implications [09:29] oSoMoN: sure thing [09:29] oSoMoN: my understanding is that this doesn't *have* to be implemented everything in one go [09:29] the biggest impact would be gained from fixing these apps I think [09:32] duflu, because whoever is supposed to handle that didn't finish the work to decomission it properly [09:32] duflu, can you mention it/ask on #ubuntu-release ? [09:32] a reminder that it's not done might be useful [09:32] there's no need, it's known / in progress [09:32] ok [09:32] I saw Steve talking about it yesterday actually [09:32] thx Laney [09:33] there was some actual reason why it couldn't be done straight away [09:33] I've no idea about the process and what is involved [09:33] me neither beyond https://wiki.ubuntu.com/EndOfLifeProcess [09:33] I would have expected that to be a simple flag to switch [09:35] would be good to share that knowledge / work imho [09:36] indeed [09:39] tjaalton, an alternative would be building firefox/thunderbird against the system-wide libnss, but firefox currently requires 3.50, which isn't yet in focal, and I suspect they bump that requirement often, so that wouldn't really work with our distribution model [09:40] oSoMoN: yeah, I don't think that's worth it [09:48] duflu: Fancy updating the debian/changelog in https://salsa.debian.org/3v1n0-guest/mutter/-/tree/ubuntu/master and https://salsa.debian.org/3v1n0-guest/gnome-shell/-/tree/ubuntu/master to list the bugs that would be closed by these uploads? [09:57] Laney, do I have perms for that? [09:57] duflu: you can push it anywhere, or give me a 'git am'-able patch even, I don't mind :-) [09:58] Laney, OK I'll try to get that done before making dinner... [09:58] that's great, thanks [10:07] Ugh, don't mix remotes from the wrong project [10:09] Laney, I would be editing older changelog entries, you understand? [10:09] Not the top one [10:10] duflu: That won't cause the bugs to be closed [10:10] Hmm, they were closed in older entries [10:10] I suggest describing it in the latest entry, as 'this upload to Ubuntu contains the fixes from ... which will close ...' [10:11] Yes, caveat being that they are Ubuntu bugs and the first Ubuntu entry [10:23] Laney, 1/2: https://salsa.debian.org/3v1n0-guest/gnome-shell/-/merge_requests/1 [10:23] or https://salsa.debian.org/3v1n0-guest/gnome-shell/-/merge_requests/1.patch [10:26] Trevinho, Laney, duflu, bug #1867345 just as a FYI/consideration when updating the packaging now or later (we can also rls-ff-incoming and discuss in meeting if that makes more sense) [10:26] bug 1867345 in gnome-shell (Ubuntu) "Do not ship "Extensions" application with gnome-shell" [Wishlist,New] https://launchpad.net/bugs/1867345 [10:26] I have no opinion on that, any more [10:31] sounds worth doing [10:31] in Debian too probably though [10:31] Laney, 2/2: https://salsa.debian.org/3v1n0-guest/mutter/-/merge_requests/1 [10:32] which is https://salsa.debian.org/3v1n0-guest/mutter/-/merge_requests/1.patch [10:33] Laney, I'm done so good night(?) [10:33] thanks and see you! [10:34] Oh wait [10:34] Those were the fixes already upstreamed not including patches. I guess Marco already documented any patches [10:34] ? [10:35] yes but without LP references if there are any [10:35] Argh [10:35] OK try again... [10:36] In a minute [10:36] you can amend his lines to include those [10:36] I will [10:44] Laney, done [10:44] one line changed [10:44] great, thanks, I'll look in a bit [10:59] kenvandine any plan to add pop theme to gtk-common-themes? i see no issues for it [12:16] hey desktoppers :) [12:17] Good day! [12:31] jamesh, kenvandine: I may have misunderstood before that the access to /var/lib/snapd/desktop/applications was just noise. based on backscroll I understand that not to be the case [12:50] hey ricotz, how are you? [12:58] popey: no current plan. i'm not particularly opposed but i do want to limit the size [12:58] pretty soon we should have the automated theme installation [12:59] "soon"? [12:59] last i heard we might have something usable in may [12:59] right after 20.04 releases [13:00] 20.04 was the goal, but we couldn't get it in time for feature freeze [13:00] so decided right after 20.04 was ok [13:33] kenvandine: is there a bug for this firefox issue? [13:34] jdstrand: bug 1868051 [13:34] bug 1868051 in snapd "browser-support[allow-sandbox=true] should not grant access to /var/lib/snapd/desktop/applications" [Undecided,New] https://launchpad.net/bugs/1868051 [13:45] oSoMoN, hey, I am fine (still) ;), and you? [13:48] ricotz, yeah, I'm good, thanks [14:05] ogra: anything to chat about today? [14:05] not really, i played with the platform snap but have nothing working yet [14:05] ok [14:53] good morning desktopers [14:59] hellsworth: good morning [14:59] hi kenvandine ! how are you today? [15:00] my yard is turning yellow... hellsworth, do you know why? [15:01] umm because it's so warm there? [15:03] you know, i went for a 30 min walk yesterday and got a solid sunburn. and today it is going to snow! [15:03] maybe later i'll go get some snow to put on my sunburn :) [15:07] hey kenvandine so maybe we want to just forget about updating gtk in the build snap until gnome-3-36. i wasn't thinking of the test effort that would be needed and now that you pointed it out, i think it's not worth it. [15:11] hellsworth: pollen! [15:11] it's everywhere now [15:11] welcome to spring i guess! [15:15] ugh and the daycare will close at noon, not for coronavirus but for the blizzard warning [15:16] oSoMoN: heads up i'm going to ask you to upload a new LO to dev as soon as it builds and put the artifacts in a google drive for you. all autopkgtests have passed my build in the ppa. [15:16] ricotz: FYI ^^ [15:16] this is 6.4.2 [15:18] hellsworth, sure thing [15:18] hellsworth, hi, I noticed, so the autopkgtests passed? [15:19] yes all of them [15:19] hellsworth, great [15:19] https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-focal-hellsworth-libreoffice/?format=plain [15:19] (if you want to have a look) [15:19] I am fine if you say so :) [15:19] :D [15:20] hellsworth, I assume there is no difference from your ppa package apart from the final changelog version? [15:21] correct [15:21] hellsworth, could you push the git branch? [15:22] yep doing that now [15:23] thx [16:09] Trevinho, Laney, so what's the status of 3.36? [16:09] I'm uploading bits to a silo now [16:09] seb128: I'm fixing now a change we need for theming gdm [16:09] then we should be good [16:10] need to change something in yaru too though [16:10] k [16:10] Laney, Trevinho, thanks [16:11] Trevinho: what change to what project? [16:11] and need? [16:11] and what need* [16:12] Laney: shell and yaru [16:12] :/ [16:13] is this another distro patch? [16:13] Laney: no, need to change one actually, I hope to remove another so I'm trying to figure another approach [16:13] means 20.04.3 in the silo isn't 20.04.3 right? [16:14] Laney: no, I noticed late... [16:14] k, so I guess not today then [16:14] Laney: if you wait a second I rebuild the silo [16:14] and push without that yaru [16:14] I knew I had to use ~wip there too -_- [16:15] use 3983 [16:15] the silo was already dead because you burned the version for mutter [16:15] now that one is dead too because of yaru [16:16] Laney: ok, well in such cases I just abandon and rebuild and re-upload (or copy if in time) [16:16] right [16:17] I was fetching the things out and re-uploading them [16:17] Laney: I wa looking at the changelog changes you pushed to salsa, and it's weird... Since i was sure I had pushed last night a version with bugs fixed as well, while it seems I forgot, but I had done the same alredy :( [16:17] anyways... [16:18] I got Daniel to do that so we could know it was right ;-) [16:18] oh well [16:19] ah damn it.... I didn't push indeed https://gitlab.gnome.org/Teams/Design/os-mockups [16:19] ouch [16:19] https://paste.ubuntu.com/p/h3RyWk3GJS/ [16:19] so yeah, was right :D [16:21] Probably going to copy Fedora for Shell and do https://src.fedoraproject.org/rpms/gnome-shell/c/2563211c08a75a21842793a6e3879c93a335e6b0?branch=master [16:22] oSoMoN: I've shared a google drive folder with you that contains all of the LO 6.4.2 build artifacts for focal. when you get a chance, please upload the necessary pieces to proposed. [16:29] hellsworth, will do shortly [16:35] oSoMoN: thanks [17:19] RAOF: hey, I'm preparing a few changes for colord, is it that fine for you if I'm pushing them git and then uploading it to debian? [18:00] hellsworth, looking at the debdiff, in debian/rules, is this intentional? [18:00] -USE_GIT_TARBALLS=n [18:00] +USE_GIT_TARBALLS=y [18:00] no [18:02] i fixed that locally (changed it back to n) and am rebuilding with debuild -S -sd [18:02] sorry [18:02] hellsworth, also, it would be interesting to generate the *source.changes file using the -v switch to include all the changelog entries since the last version in focal [18:03] is that -v flag to debuild? [18:03] IIRC, yes [18:03] that's dpkg-genchanges -v, and I think debuild dispatches it correctly to dpkg-genchanges [18:04] ok thanks. i started a debuild -S -sd -v locally [18:05] cheers [18:30] Is there a way to make bug 1863239 an rls bug for focal? [18:30] bug 1863239 in libmtp (Ubuntu) "/dev/bus/usb/*/* device file of HP multi-function printer assigned to "audio" group" [Critical,Confirmed] https://launchpad.net/bugs/1863239 [18:33] It makes most HP printers not printing when on USB. [18:39] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=954013 << an idea for this? [18:39] Debian bug 954013 in evince "evince: Opening external URL failed: blocked by AppArmor: Failed to execute child process /bin/sh" [Normal,Open] [18:40] oSoMoN: seems that -v in debuild is for version and causes debuild -S -sd -v to fail [18:41] -v is version also to dpkg-genchanges [18:41] retrying with jsut debuild -S -sd === _thumper_ is now known as thumper [19:04] hellsworth, yeah, you need to explicitly specify a version [19:04] see the man page for dpkg-genchanges [19:05] hmm ok thanks [19:34] hellsworth, I noticed an issue :\ [19:34] tell me [19:35] it is an unwanted debian change [19:35] regarding boost and mdds [19:37] i didn't see any problem with building or running libreoffice... [19:38] hellsworth, I might lead to mdds being demoted to universe [19:38] oh perhaps this is bad because debian is now using an internal mdds and we need to use the mdds that's in main [19:38] right [19:38] ok [19:38] good catch [19:39] hellsworth, I can push the required change [19:39] sure ricotz please do [19:39] and thanks [19:41] hellsworth, done [19:41] thanks [19:43] i'm going to err on the side of caution and build this in my ppa and rerun autopkgtests before requesting it to be uploaded to proposed [19:44] unless ricotz you think that's unwarranted [19:46] I will at least build a ~ppa2 in hellsworth:libreoffice and install/test [19:46] hellsworth, yeah, do that [20:29] good night all [20:32] bigon: add this to the evince profile: /bin/{b,d}ash ixr, [20:33] bigon: actually, /bin/{,ba,da}sh ixr, [20:36] popey, https://forum.snapcraft.io/t/snap-interface-metadata-i-e-descriptions/16077 in case you didn't see it. [20:38] Do desktop snaps need both the pulseaudio and audio-playback interfaces connected? I noticed audacity has both, which looks confusing in settings. [20:40] robert_ancell: no, pulseaudio is deprecated [20:41] jdstrand, ah, good. [20:41] robert_ancell: it doesn't auto-connect any more (with new enough snapd) [20:41] robert_ancell: unless we grandfathered the snap [20:41] jdstrand, so it would probably make sense to add it to the blacklist in the UI? [20:42] robert_ancell: we grandfathered snaps that only plugged pulseaudio so as not to break them and force a flag day to move to audio-playback [20:43] robert_ancell: considering the number of grandfathered snaps, it probably makes sense to only show pulseaudio if audio-playback is not preset [20:43] present* [20:43] jdstrand, ok. [20:43] Thanks! [20:43] np [20:44] jdstrand, is there an easy way to work out which interfaces are deprecated? [20:44] robert_ancell: that won't fix the situation where a grandfathered snap decided to add audio-playback but not remove pulseaudio, in which case both show. if someone wanted to remove audio capabilities from the snap, they'd have to both be shown, but yes, to your point, it is a bit weird having both (but that is what the snap actually has) [20:45] jdstrand, oh, so if you disable audio-playback but have pulseaudio connected then you'll get sound? In that case we'll have to show both. [20:45] robert_ancell: I'm not sure if it is worth adding a 'deprecated' label in a strategic location or not. that might help the ui... [20:45] robert_ancell: yes [20:46] jdstrand, I was asking specifically so I know the list of interfaces that need labels, and not waste time on deprecated ones. But more metadata is always useful. [20:46] robert_ancell: but if a snap plugged both, you could, conceivably, only show audio-playback if pulseaudio is disconnected. the more we chat, the more the 'deprecated' label might make sense :) [20:47] but I'll leave that up to you :) [20:47] I think I'll propose a deprecated label PR, because that seems an easy add. [20:47] robert_ancell: for more context, pulseaudio actually grants playback and record on (iirc) < disco [20:48] not that you need to necessarily express that [20:50] robert_ancell: as for working out which interfaces are deprecated: no. this is the only one atm and we didn't add anything for querying what is deprecated [20:50] oh, I thought there were more. [20:50] There's been some that have been removed, right? [20:51] robert_ancell: well, now that you mention it, I might have used that term in a google doc, but this is the only one like pulseaudio where it moved from auto-connected to manual connected [20:51] robert_ancell: you might be thinking of a spreadsheet that talked about the interfaces? [20:52] jdstrand, yeah, that's what I've been looking at, but it's out of date and I was wondering if there was a better source of information. [20:52] robert_ancell: no interfaces have been removed. pulseaudio went from auto to manual connect, and network-status was totally rewritten. everything else has just been modified in normal maintenance-y ways [20:53] ok [20:53] jdstrand, Do you want to add some new labels to that spreadsheet? I asked for edit access from mpt but haven't got it yet. [20:53] robert_ancell: right, so in terms of that doc, sure, the unity8 interfaces could be considered deprecated for your ui (they are still alive in the store reviews and snapd though) [20:54] robert_ancell: I can review that spreadsheet again, sure [20:54]