Hi everyone, below you will find the updates from the Desktop team from the last week.
If you’re interested in discussing a topic please start a thread in the Desktop area of Discourse.
We also have our weekly meeting on IRC. We meet on Tuesday at 13:30 UTC in #ubuntu-desktop on Freenode. There will be an “Any Other Business” section at the end where you are welcome to raise topics. These topics might be discussed during the meeting, or afterwards depending on the time, depth of conversation, topic and so on.
Also new this week; Release affecting bugs are now listed here:
That post is a wiki and you should be able to provide any updates inline.
Last week’s notes are here: Monday 8th July
Next week’s notes are here: Desktop Team Update - Monday 22nd July 2019
Gnome Shell performance (stutter | latency | CPU):
Gnome Shell other things:
- Proposed an API cleanup related to recent optimizations.
- Lost about a day on a comedy of regressions, all occurring around the same time in different projects:
snapd user session agent:
- I addressed the last round of review comments on PR #6954, with it waiting on Samuele to sign off.
- As a side effect of this work, I submitted PR #7036 to make the main snapd rest service use the newer stdlib
http.Server.Shutdown method, as used in the session agent. That PR got merged this week.
snapd interfaces for snap store
- No change on PR #7042 (
- For PR #7054 (
packagekit-control interface), I received some review feedback from @jdstrand that I have responded to. I’ve tightened up the rules governing access to transactions, and set the base declaration to deny the ability to install a snap using the interface without a store assertion specifically allowing it (as is done for e.g.
snapd icon theme support
- I worked on PR #6959 (the
EnsureTreeState helper), adjusting the semantics as requested and adding a few more tests. I think this is fairly solid now, which should unblock the icon theme PR.
Other snapd interface work
PR #7073, extending the
opengl interface to allow access to drivers provided by the base has been marked blocked.
- There is some push back against adding ad-hoc AppArmor rules to the interface implementations to support one particular base snap, which I can understand.
- There is some discussion on the forum about how AppArmor file based restrictions should be handled for base snaps other than
core18. My personal preference would be to use a fairly open profile for non-bootable base snaps: there isn’t really any reason for them to include files that would be off limits to application snaps using them as a base, so why not make the entire base readable?