reasoning: the desktop session needs to talk to systemd to orchestrate the startup
pipewire:
request-type: auto-connection
reasoning: the desktop session needs to talk to Pipewire for the screen sharing
shutdown:
request-type: auto-connection
reasoning: to be able to trigger shutdown from the application menu of the session
system-files (shell-config-files):
request-type: auto-connection
reasoning: this is not a new interface to add, but it has been adjusted to also include /etc/security in addition to /etc/pam.d (the latter was enough in core22, but core24 pushed us to add this extra directory)
Thanks! We need another vote at least beyond @cav I guess?
Sorry to bother but any chance to speed this up a bit? I’d like to be able to finally test the new iteration with all the blocks assembled straight from the store.
@jslarraz Thanks! I understand pipewire is under the same regime than systemd-user-control for now. Makes sense. Expect me to ask again on further revision of the package though.
Looks like the systemd-user-control auto-connection is missing? I’m getting this when I try to install the package from the store: installation not allowed by "systemd-user-control" plug rule of interface "systemd-user-control".
I just tried installing the snap and it seemed to be successful. Does this issue still occur on your end?
$ snap install plasma-desktop-session --edge
2025-04-01T10:17:53+10:00 INFO snap "plasma-desktop-session" has bad plugs or slots: pipewire (unknown interface "pipewire"); systemd-user-control (unknown interface
"systemd-user-control")
2025-04-01T10:18:04+10:00 INFO snap "plasma-desktop-session" has bad plugs or slots: pipewire (unknown interface "pipewire"); systemd-user-control (unknown interface
"systemd-user-control")
plasma-desktop-session (edge) 20250319+gitb1c8cc7 from KDEâś“ installed
WARNING: There is 1 new warning. See 'snap warnings'.
Actually I think it’s because you’re testing with a regular snapd but we have a fork on Core Desktop for now which knows the systemd-user-control and pipewire interfaces. In the case of systemd-user-control it’s by default not allowing installation, I think it needs to be overridden from the store assertion.
IIRC you did that in the past but it didn’t happen this time around.
The snapd used on core desktop provides the systemd-user-control interface, but is declared with allow-installation: false on the plug declaration side. It’s been like this for the past few months.
This has happened a few times with various snaps: a request is made for an addition to the snap declaration, and another part of the declaration is removed without discussion. It can be incredibly disruptive, since assertion updates propagate very quickly and affect all users of the snap.
Is there any process in place to make sure that only the requested changes are made to the snap declaration?
a request is made for an addition to the snap declaration, and another part of the declaration is removed without discussion.
Whilst you are right and that has happened few times, I don’t think it is the case this time. Looking at the declaration history and review-tools output for past revisions I think systemd-user-control has never been granted. That makes sense as this interface is not known to review-tools.
After discussion with @pedronis, it seems that this interface won’t ever be added to the “oficial” snapd project. Thus, I don’t think we should add support for it in review-tools.
Considering that you are using a fork of snapd, I think that a more appropriate solution (just for testing purposes until the long-term solution would be available in snapd) would be to update the base declaration for the systemd-user-control on your fork, so no assertion from the store would be needed.
Is there any process in place to make sure that only the requested changes are made to the snap declaration?
I’m not aware of any plan in that direction. However, I imagine that it should be implemented by the store team in the dashboard
Looking at the declaration history and review-tools output for past revisions I think systemd-user-control has never been granted.
I’m pretty sure it has been granted, @cav did it by hand a couple of times on previous iterations of the same package. It was also installed just fine, in the meantime the base declaration in the snapd fork didn’t change.
I just looked again to the declaration history and I could not find any evidence that it is was granted.
If for some reason an unexpected interface name is found the declaration (as it would be the case for systemd-user-control) automatic review immediately exits with the Unexpected output from snap-review. snap-review. I see it is not the case for any of the snap revisions.
Finally, according to @cavcomment in the original thread, it seems that the suggested solution was also to update the base declaration on your side. Commentaries in the original topic suggest that @cav only manually approved the revision (in the same way I did for the latest one) and I could not find any commentary that indicates that the declaration was granted in the store side at all
I might be missing something, but everything points out that it was never granted tbh.