I’m the project leader of the rclone project. Rclone is a command line utility to sync files to and from cloud storage.
It is available in the snap store with a stable and a dev version:
However these versions are woefully out of date (from 2017) and I don’t have access to the snap store login.
As you can see from the repology entry rclone is packaged for just about every distribution and mostly quite up to date so the snap being so out of date sticks out.
So I’d like to fix the snap, either by removing it, which would still leave access to the deb package or by finding a new maintainer for it. Alas I don’t have the bandwidth for maintaining it but maybe someone could here?
We abandoned the snap because we couldn’t get the FUSE mount to work properly. Rclone needs access to all your files and a FUSE mount so maybe isn’t the best project for a snap, I don’t know.
I love rclone and I love making snaps, but suspect making a snap of rclone might be a bit beyond me. I’d like to explore this, though, and would be happy to help in any way I can. I suppose the biggest question is whether it should run in strict or classic confinement?
When I snapped Restic up, we went with classic as people’s data could be anywhere, and dotfiles would need to be accessed. I suspect this would be similar. Now since Rclone is a go program and a single binary, we could take the approach of taking the release file direct from GitHub and wrapping that in a snap. I took that approach (with Restic) as upstream wanted their builds used. I have a pretty quick template that I have used on multiple apps. Just a thought.
According to the docs the valid architectures are s390x , ppc64el , arm64 , armhf , amd64 and i386
So supporting arm64 , armhf , amd64 and i386 would probably be the sensible option and these map well to the binaries we produce at the moment. I’m not 100% sure what ARM level armhf implies - however rclone does require hardware floating point and we normally build for ARMv6 however we are planning to do an ARMv7 build very soon.
Debian/armhf works only on newer 32-bit ARM processors which implement at least the ARMv7 architecture with version 3 of the ARM vector floating point specification (VFPv3). It makes use of the extended features and performance enhancements available on these models.
So it looks like the ARMv7 build will be the right choice for armhf when it is available, in the mean time the ARMv6 build will work just fine.