Fix rclone download on Linux and non-amd64 machines - #23
Merged
Conversation
Reported in #1. `gsg` could not install itself on Linux at all: RuntimeError: Could not find rclone asset for linux-amd64.tar.gz Two separate mistakes in _rclone_asset_name, either of which is fatal. The extension was wrong. rclone publishes .zip for every platform it supports, including Linux and macOS. There has never been a linux .tar.gz, so the lookup could not succeed on any Linux machine, ever. The architecture was hardcoded to amd64. Even with the extension corrected, an arm64 machine would have been handed an Intel binary. That covers Apple Silicon, Raspberry Pi, and the ARM handhelds the reporter mentioned. Both halves are now derived. platform.system() maps to rclone's OS token and platform.machine() to its arch token, which matters because the same 64-bit Intel chip reports "x86_64" on Linux and "AMD64" on Windows, and 64-bit ARM is "aarch64" or "arm64" depending on who is asked. An unsupported platform now says what to do instead of only what failed: install rclone yourself and gsg will use it, since get_rclone_path already checks PATH via shutil.which before downloading anything. Ten tests cover the selection, built from a real rclone release listing, and name the two original bugs directly so a regression says which one came back. Ludusavi was checked for the same class of bug and is correct: its assets really are linux.tar.gz, mac.tar.gz and win64.zip. Also imports Any in packaging/make_icon.py, which was annotated but never imported. Harmless under `from __future__ import annotations`, but wrong.
Closed
This was referenced Aug 4, 2026
Merged
Vasanthdev2004
added a commit
that referenced
this pull request
Aug 5, 2026
get_rclone_path has always checked PATH before downloading. get_ludusavi_path never did, so a Ludusavi from the AUR, from Homebrew, from Nix, or built by hand was passed over in favour of a download. That asymmetry is worst exactly where the download cannot work. Ludusavi's CI builds one Linux target, x86_64-unknown-linux-gnu, and one macOS target, aarch64-apple-darwin. ARM64 Linux and Intel macOS have no official binary at all, so the users who most needed to supply their own were the ones being overruled. Also stops caching a binary this machine cannot execute. Ludusavi's asset names carry no architecture - the real release is ludusavi-vX-linux.tar.gz and ludusavi-vX-mac.tar.gz, verified against the live API - so a wrong-arch download succeeds and fails only at exec. Worse, download_ludusavi writes it to the binary dir, and get_ludusavi_path returns any cached binary without re-checking, so every later run failed the same way with no path to recovery. Unsupported architectures now raise before fetching and name the workaround, matching the error text added for rclone in #23. Config still wins over PATH: pointing gsg at a specific build is deliberate. Eleven tests in a new tests/test_ludusavi.py. Deliberately not in tests/test_cloud_cas.py, which carries a module-level skipif for a missing rclone and is therefore skipped on every CI run - the same trap that left the CAS upload flags unguarded in #29. Verified they run without rclone present: 220 passed, 3 skipped. The changelog gains an Unreleased section covering this and #26, both of which landed after 0.6.1 was dated. Co-authored-by: Vasanthdev2004 <Vasanthdev2004@users.noreply.github.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #1.
gsgcould not install itself on Linux. At all. Every first run ended at:Two independent bugs in
_rclone_asset_name, either one fatal on its own.The extension was wrong. rclone publishes
.zipfor every platform itsupports, Linux and macOS included. There has never been a
linux-amd64.tar.gz.Verified against the live release listing: 23 platform variants, all
.zip(plus
.deb/.rpmfor Linux, which are packages, not binaries).The architecture was hardcoded to
amd64. Even with the extension fixed,an arm64 machine would have downloaded an Intel binary and failed at exec.
That is Apple Silicon, Raspberry Pi, and the ARM handhelds @EnduringGuerila
mentioned.
Both halves are derived now.
platform.system()maps to rclone's OS token andplatform.machine()to its arch token — that second map matters because thesame 64-bit Intel chip reports
x86_64on Linux andAMD64on Windows, and64-bit ARM answers
aarch64orarm64depending on who you ask.An unsupported platform now says what to do instead of only what broke:
That is not a consolation message, it is accurate.
get_rclone_path()callsshutil.which("rclone")before it ever considers downloading, so rclone from adistro package, Homebrew, or
pip install rclone-binis already picked up withno code change. That is the answer to the pip question in the issue too.
Tests
Ten cases in
tests/test_cloud.py, built from a real release listing, coveringlinux amd64/arm64/386, macOS Intel and Apple Silicon, Windows x64 and ARM, and
the unsupported-platform path. Three of them name the original bugs directly so
a regression reports which one came back rather than just "wrong asset".
Not changed
Ludusavi was checked for the same class of bug and is correct: its assets
really are
linux.tar.gz,mac.tar.gzandwin64.zip.Also imports
Anyinpackaging/make_icon.py, which was annotated but neverimported. Inert under
from __future__ import annotations, still wrong.