added to the agenda also:
added from recent discussionss about features we might well need soon:
1 Like
I won’t be at the sprint, but there are a few open issues that seem to have fallen through the cracks:
-
Add support for per-user mount namespaces: this is needed to support xdg-desktop-portal, which in turn is needed to properly confine non-tirival desktop applications.
Complicating matters is that I also need to bind mount a location within a FUSE file system, which can not be done as root. Supporting this would require
snap-confineto switch back to the regular user account but retain certain capabilities prior to configuring the mount namespace. -
Allow building in-place, and incremental builds while developing a snap: this one would greatly improve the user experience for the gnome-builder IDE integration I am working on. If a developer is concurrently working on packaging an application and making changes to the application code, it would be nice if rebuilding the snap didn’t involve a full recompilation of the entire project.
1 Like
Thanks James. Added to the agenda.
added these two topic as well:
The sprint is on!
We’ll use this topic to write down notes about agreements made here. Feel free to use this to propose further topics or exchange information between people in and out of the sprint as well.
Hi all,
Here’s the laundry list for GUI / Desktop tasks that we want to reach agreement on this week. This post will be updated as we go.
- Getting licence info from the store to the UI
- Human friendly “titles” to show in UI
- Add/Remove without U1 log in
- Discuss ODRS app reviews and Snaps
- A UI system for connecting plugs/slots
- Installing classic snaps via the UI
- Sideloading snaps via the UI
- Purchasing software within the UI
- Talk with everyone about snapd-glib & qt bindings
- A “power tool” for Snaps
- Support for channels in UI
- AppStream
- .desktop file matching in GNOME Software
- Verified publishers
We’re tracking our tasks in Trello:
Notes are available here: https://docs.google.com/document/d/1JFmYwzwoRqjhZPhRF2ZnjMs-sYaIDyjSZhlc-duYmYY/edit
Cheers, Will
2 Likes
snapd-glib docs for reference:
snapd REST API:
snapd-glib API (a little out of date, but has probably all the functions you need):
also click/snap-review-tools need updating to support base snaps
might need a bootable flag in the base snap.yaml to indicate whether a base snap can be used as boot base snap for a device (from the model)
Agreement about AppStream from after lunch on Monday:
- Snapcraft will have a means of populating the snap.yaml with data from the AppStream yaml, setup.py, etc
- Snapcraft will write appstream.yaml next to snap.yaml
- Appstream.yaml has a small set of fields not in snap.yaml
- Fields going in to appstream.yaml are agreed on by desktop/snapd teams
- Snapcraft uploads screenshots via new endpoint going into the same place
- Store keeps appstream.yaml in database as blob or JSON/fields (TBD)
- Snapd returns appstream.yaml as JSON or blob (tbd)
- GNOME Software will continue to work with snaps without appstream data
3 Likes
Agreements about the session on snap layouts just now (previously known as “overmounts”).
Updates from Tuesday:
- New syntax that reflects the idea of “layout” better
- New user, group, and mode fields
Preliminary ideas about user ID mappings.
Updates from Tuesday:
- snap.yaml must define what users and groups it depends upon
- We want snap devices to see “nobody” instead of “snap_nobody”
The following agreements were made about GUI-related needs this morning.
We also had a long discussion about representing interfaces in gnome-software, and have not yet managed to find a clear path towards making it acceptable for upstream.
1 Like
Updated some of the posts above with conversations from this morning. They also got updated whiteboard pictures.
Agreements about validation improvements from this afternoon:
And then about epochs (stepped updates):
2 Likes
Preliminary agreements about improved theme support below. More needs to be discussed for something to be implementable.
1 Like