Another point raised in a SF case: lots of snap CLI arguments do not work when acting on more than one snap at a time. For example, --ignore-validation, but also I think arguments like --stable, --candidate, --beta, --edge, --dangerous, --unaliased would also make sense to apply to all snaps listed. Currently these all throw an error if used with multiple snaps, like snap install --ignore-validation foo bar.
2 Likes
A post was split to a new topic: Helping out with hidden snap folder support
I sometimes work with a bad internet connection, syncing a container to my local machine.
I get extremely irritated if I make a typo specifying the target container on resync. With zfs i get the full container instead of the diff then. It is especially annoying as there is no way to stop the full transfer.
Following features would help:
- lxc copy: have
--refreshabort the copy if the given target does not exist (maybe a flag to override--force, or for backwards CLI compatibility the other way round, a--check-target-exists) - lxc copy: Add a
--abortparameter - cancel a running operation, keeping the old config and reverting to the old state - lxc completion bash: generate a completion which is able to handle the
local:~remote - lxc completion bash: generate a completion which is able to complete the target instance for lxc copy; at least if
--refreshis given. But I think that makes sense in the general case. It currently completes remotes correctly, but no instances. And also `local: is not offered
(Side-note: it I think it should also possible to implement a --continue to continue without full resend if the stream got interrupted with zfs)
I would guess that bash completion could be papercut territory(?)
Thought: how about an autoremove-like feature to cleanup any no longer needed “automatic snapshots the system has taken when you uninstalled any snap without --purge” (just learned this was a thing thanks to @ogra)?
1 Like
This is now done. The architecture is included since 2.72, but I also landed information on the source of snapd and snap binaries.
Architecture:
$ snap version
snap 2.72+g269.14869287a0-dirty
snapd 2.72+g269.14869287a0-dirty
series 16
arch -
kernel 6.17.9-arch1-1
architecture amd64
More info:
$ snap version --verbose
snap 2.72+g269.14869287a0-dirty
snapd 2.72+g269.14869287a0-dirty
series 16
arch -
kernel 6.17.9-arch1-1
architecture amd64
snapd-bin-from native-package # or 'snap' when using reexec
snap-bin-from native-package
Unfortunately, as I mentioned before, folks are likely parsing the output, and given you could do something silly like snap version | awk '/snapd/ { print $2}' (in which case both snapd and snapd-bin-from will match) I felt it’s safest to hide the new fileds behind a --verbose flag.
1 Like
It’s probably best if you open an issue about this in the LXD issue tracker.
There’s one more thing coming for 2.74. We’re adding a new snap report-issue command which will hopefully help with reporting problems about individual snaps. It combines some information from snap info and snap info --verbose. That’s how it looks in action:
$ snap report-issue ohmygiraffe
Contact information provided by "ohmygiraffe" snap publisher:
Issue reporting:
https://github.com/kz6fittycent/ohmygiraffe
Website:
http://www.ohmygiraffe.com
Source code:
https://github.com/kz6fittycent/ohmygiraffe
Use one of the links listed above to report an issue with the snap.
Would you like to open https://github.com/kz6fittycent/ohmygiraffe in browser? [Y/n] ^C
$ snap report-issue firefox
Contact information provided by "firefox" snap publisher:
General:
https://support.mozilla.org/kb/file-bug-report-or-feature-request-mozilla
Website:
https://www.mozilla.org/firefox/
Use one of the links listed above to report an issue with the snap.
Would you like to open https://support.mozilla.org/kb/file-bug-report-or-feature-request-mozilla in browser? [Y/n] ^
The snap details page available to publishers allows to add a dedicated issue tracker link, but in case the publisher has not provided one, the code tries to guess which of the existing URLs looks most likely to point at some support page (see the output for firefox above).
Maybe I could hook this up somehow to ubuntu-bug, reportbug (for Debian) or others.
3 Likes
Maybe this is too big for this initiative, but I’d like to see more snapd changes history.
I was asking about it here already.
I find the retention extremely limiting, especially when debugging an issue. Even for Canonical support staff it’s very limiting as when we/customers try and create an issue about something any related change information is quite likely to be missing.
What do you think ?
Cheers, Just
4 Likes
snap refresh is not fully functional if you use validation-sets and are ignoring a validation-set assertion for one or more installed snaps.
Something that’s a non helpful UX IMO.
In this example, we have a validation-set controller snapd revision, it’s been ignored to test a newer revision, but we can’t properly make use of snap refresh generally on the system now.
System wide snap refresh not usable
# snap refresh
error: cannot refresh: cannot update snap "snapd" to revision 25577 without
--ignore-validation, revision 23771 is required by validation sets:
~~~8<~~~
Can’t even list pending updates
# snap refresh --list
error: cannot list updates: cannot update snap "snapd" to revision 25577 without
--ignore-validation, revision 23771 is required by validation sets:
~~~8<~~~
For system wide refresh, there’s an argument to be made that the above behaviour is correct, but I think it’s a point of view. snapd could just exclude any snaps with an ignored validation-set set from the system wide refresh, even if via a new option.
Single snap refresh still works, but you have to know which ones have pending updates, which is a bit cumbersome.
For refresh list, I think there’s less of a compelling argument for the current status, why not simply tell me about he pending updates anyway, perhaps highlighting the snaps that are ignoring validation-sets and blocking refresh ?
Cheers, Just
1 Like
I think this is very much needed. I have a daily cronjob dumping the info in a logfile so it does not get lost.