Community schedule:
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
2 Likes
Quick sketch about how the “double starred” epochs enable transition of data forward without preventing reverts to prior revision:
snapd must ensure that once a revision lacking a double starred epoch is installed, the double star behavior is disabled and going back an epoch is not possible anymore, even if a revert into the double starred revision happens. This is necessary because the double star is what tells the system that compatibility is still being preserved.
Agreements about the upcoming improvements for the kernel and gadget snaps that will enable image resources to be updated (top) and avoid the need of lockstep updates in the Raspberry Pi (bottom).
