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.
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):
Preliminary agreements about improved theme support below. More needs to be discussed for something to be implementable.
Agreements about the continuation of the repair feature:
Agreements about the warnings feature:
Agreements about the devmode refresh behavior:
Agreements about lazy snapd registrations in the store:
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).
Agreements related to the changes coming to the grade setting:
Agreements about how the management of textual information (summary, description, translations, etc) will take place between snapcraft and store:
Regarding the metadata/textual info, I think we also need a snapcraft command to sync from the store to the local snapcraft.yaml. So if you are a developer of a snap where the text is always edited in the store UI (possible a different person in your team), you can do something like
snapcraft update-text --from-store && snapcraft && snapcraft push in your CI to ensure that builds always have the latest info inside the snap.
You would also want to periodically update the snapcraft.yaml and commit to your repo, but that could be just part of your local dev workflow.
There seems to be a contradiction between:
“If grade is unspecified in snapcraft.yaml, leave out of snap.yaml”
“Store should reject if grade unspecified”
Can you clarify? Is
grade is now specified via some other means?
Great, wasn’t the only one to notice. I basically read this as new snaps will be rejected by default.
Adding a bit more questions:
- Are translations going to be contemplated in
- Is the meta data going to not be part of snap.yaml?
Out of interest, was there any discussion about using polkit here? If it is acceptable for snapd to (optionally) talk to D-Bus, then I think this would be possible and not interfere with the existing authentication system.
Here’s a quick sketch of how it could work:
- when incoming connections are made to the REST port, record the peer’s pid in the same way their uid is currently recorded.
- When processing a request, check the request headers for
- If the request requires superuser privileges and polkit authorization has been requested, call polkitd’s
CheckAuthorizationD-Bus method with the peer’s pid and an action ID derived from the REST API request. If polkitd grants permission, allow the request to complete.
Connecting to the system bus could be delayed until this mode is requested, and it shouldn’t be too difficult to reconnect to the bus if it has been restarted since the last polkit request.