Rclone snap - delete or update?

store-requests
1

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:

  • https://snapcraft.io/rclone
  • https://snapcraft.io/rclone-dev

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.

Any help much appreciated :slight_smile:

(Links quoted to avoid new user limit!)

2 Likes
2

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?

3

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.

4

If you would like to take it over, that would be fine with me :slight_smile:

I’m afraid I don’t know enough about snaps to answer that question.

Yes very similar I think.

Taking the upstream build would certainly work for me.

5

Classic makes a lot of sense.

6

How about we move it to snapcrafters and maintain it collaboratively?

2 Likes
7

I may have been going to suggest this to you :slight_smile:

1 Like
8

If you fine people would like to take it on, then that is absolutely fine with me :smiley:

I can pitch in if you need help with rclone itself.

9

Do you want me to build out one the same way I did restic just leveraging the pre-built binary?

10

Is that a normal way of doing it? Leveraging the pre-built binary would certainly help with bug reports.

11

Sounds like a plan!
We can do some testing based off that and then do the transfer to snapcrafters once you’re both happy.

12

I love it when a plan comes together :slight_smile: Sounds good to me!

1 Like
13

Ok, I’ll start putting one together.

@ncw which platforms do you officially support and would you like a build for? (Ie - 64bit, 32 bit, arm, etc)?

14

The full build support matrix is here

image

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.

According to the debian docs

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.

15

@popey Looking at the support matrix provided above, do you feel it makes sense to build for all based on the systems that actually support (snapd) snap packages? Any insight to this?

16

Oops missed your reply.

Releases in the table above are supported and should work.

If we could package the intersection of those and the platforms that support snapd that would be perfect.

17

Any progress on this?