aurupdater

android-file-transfer

Build times (auto-updated)

New package, added 2026-09-19 under maintained/. Stable-release Qt GUI build of https://github.com/whoozle/android-file-transfer-linux.

Why this package exists

Two related AUR packages already existed for the same upstream repo, but neither covers a stable-release Qt GUI build:

This package fills that gap: a stable-release (not -git) full build with the Qt GUI, CLI, and FUSE mount helper.

AUR repo history note (important)

git submodule add ssh://aur@aur.archlinux.org/android-file-transfer.git did not clone an empty repo – it pulled real history from an unrelated, long-abandoned package by a different maintainer (yaroslav, last at pkgver 2.4, ancient qt5-base/fuse (v2) deps). That package no longer shows up in AUR’s database/search (rpc/v5/info returns 0 results for the name) – deleted from the listing at some point, but the git backend kept the repo/history. Our new PKGBUILD/.SRCINFO were added as a fresh commit on top of that existing history, not a history rewrite/force-push – this is the normal way to revive a dead AUR package name.

Build (cmake options)

Upstream CMakeLists.txt options, all default ON except BUILD_SHARED_LIB/USB_BACKEND_LIBUSB (default OFF): BUILD_FUSE, BUILD_MTPZ, BUILD_PYTHON, BUILD_TAGLIB, BUILD_QT_UI, BUILD_SHARED_LIB, USB_BACKEND_LIBUSB.

Chosen for this package:

Generator/build: plain cmake -B build -S . + cmake --build build (no ninja needed, makedepends=(cmake qt6-tools) only – qt6-tools supplies Qt6’s linguist tools used for building translations).

Dependencies

depends=(qt6-base fuse3 taglib openssl hicolor-icon-theme readline file android-udev). readline/file (for libmagic) were added after the first test build – namcap flagged both as implicitly linked-but-undeclared. android-udev is not a real AUR package name – only android-udev-git exists and provides=(android-udev); this matches android-file-transfer-cli’s own PKGBUILD, which depends on the same virtual name for the udev rules needed to access MTP devices as a non-root user. namcap flags it “may not be needed” since it can’t detect a udev-rule dependency by linkage – expected false positive, same as on -cli.

conflicts=(android-file-transfer-git android-file-transfer-cli) – real file overlap (both ship aft-mtp-cli/binaries under the same paths).

Re-checked 2026-09-24 (FEEDBACK.txt sweep): check_aur_feedback.sh still flags this MISSING on every run – expected, per the “AUR repo history note” above (never pushed under this name, nothing to find).

Build status

Test-built clean for x86_64 via repo_build_staged.sh (REPO_BUILD_ONLY_ARCH=x86_64), pkgver 4.5-1, first try after adding the two missing namcap-flagged deps. Not yet committed/pushed/published – staged only, pending user review (per project policy, all git commits/pushes are done by the user, not automated).

2026-09-27: superseded by official extra – migrated to adapted/

Official Arch’s own extra repo started shipping android-file-transfer 4.5-2 directly (x86_64 only) at some point after this package was created – the user noticed and flagged it. The gap this package originally filled (no stable-release Qt GUI build existed anywhere) no longer exists for x86_64, but our own build still uniquely covers aarch64 (official extra doesn’t publish that arch for this package at all), so not fully redundant.

Per the user’s own call: this is now “just an arch adaptation” of an otherwise-official package, not a real AUR submission (it was never actually pushed to AUR anyway – the maintained/ submodule sat staged-only this whole time, see the entry above) – moved to adapted/android-file-transfer as a plain fork of official Arch’s own current PKGBUILD (matches it exactly except arch=() gains aarch64). pkgrel 1 -> 2.1 (matching upstream’s own 2, plus the local arch addition). Built + published clean for x86_64; aarch64 pending – eurobuild14 (and the whole ARM cluster) was down at the time.

The old maintained/android-file-transfer git submodule (fully committed in the superproject, clean working tree, never actually pushed to its AUR remote) still needs manual removal by the user – not done here, since submodule deinit/removal is a git operation.

2026-09-28: aarch64 published, first attempt hit eurobuild14 swap-thrashing

First real aarch64 build attempt once the ARM cluster came back up. This package’s qt6-base/qt6-tools deps are heavy enough that eurobuild14 started thrashing under the existing per-host MAKEFLAGS=-j1 cap alone – ping kept succeeding but new ssh connections timed out mid-banner while the build’s own already-established session stayed alive (see memory/TOOLING_NOTES.md’s “Remote ARM build machines” entry for the general symptom). User killed/power-cycled the board partway through rather than wait it out.

After the reboot: mounted /data fresh, and per the user’s tip swapon’d the board’s existing /data/swap (2G file, wasn’t active by default) before retrying – also had to clear a stale /data/INSTALL/.building.lock left behind by the killed attempt (board being power-cycled meant repo_build.sh never got to release it itself; confirmed no real build process was still running before clearing it). With swap active, the retry built and published cleanly in ~4 minutes, no thrashing. android-file-transfer-4.5-2.1-aarch64 live; the stale 4.5-1-aarch64 build the old x86_64-era pkgrel had left behind was auto-archived by repo_publish.sh.