Individual snaps cannot be removed from a quota group
Also backed up by the docs:
To remove a snap from a quota group, the entire group must be removed with the remove-quota command and the quota group recreated without the snaps:
This is a bit convoluted, especially as the implementation seems to be just based around systemd slices, I don’t see why it should be required.
Perhaps a simple snap remove-quota my-quota my-snap could be implemented ?
Cheers,
Just
Extend snap info to show meta/assert data about a certain revision/channel.
E.g. one gets core version when doing `snap info mysnap`, but i guess that is the core for the default revision(?).
E.g. firefox latest/stableis on core22, but latest/core24/stableis on core24 (which seems obvious) but also latest/stable/26.04is (where it is not obvious). Also the tracks are gonna change soonish
core24 has been recently rolled out for Ubuntu 26.04 (which tracks the channel latest/stable/26.04). We’re giving it some time to catch issues; It will eventually follow suit for the latest/stable channel.
..also latest/edgeis currently on core24. How i found out? Downloaded the snap, unsquashed it and had a look at the snapcraft.yaml
I’m not entirely convinced about this one. AFAIU it should be irrelevant for the user which base the snap happens to use. At least in an ideal world, where all bases and associated runtimes are equal for instance in the hardware they support. We already from practice that e.g. core24 snap likely uses much more recent mesa drives and has a higher chance of working properly on new hardware.
In any case, should this information be presented, how is a random user expected to act on it without prior knowledge of what it means?
This is not for a random user, but a power user. For presentation, currently:
$ snap info --verbose firefox | grep base
base: core22
with the papercut
$ snap info --verbose --channel=latest/stable/ubuntu-26.04 firefox | grep base
base: core24
Also one can not currently check if a channel is available using snap info (one has to use snap download AFAIK). I know these are “test” branches which do time out, but the latest/*/ubuntu-XX.XX ones are effectively permanent
Probably too big for a papercut: At least warn/notice when a tracked channel gets closed (which implicitly means a different channel gets tracked). For me this often leads to an unwanted situation. For GUI apps i would actually like to get that info on first start of that app, but system notice would be better than what we have.
This also bit people tracking the firefox core24 for getting their hardware supported, when republish of that branch was forgotten by mistake.