Arch Linux User Repository

Right, I've reverted it. Thanks for the info

The latest change that adds a dependency on rust 1.95 or newer breaks builds on systems that use rustup due to rustup providing rust but having a different versioning system.

-> pacman -Qi rustup
| Name            : rustup
| Version         : 1.29.0-2
| Description     : The Rust toolchain installer
| ...
| Provides        : rust  cargo  rust-nightly  cargo-nightly  rustfmt  rust-src
|                   lib32-rust-libs  rust-musl  rust-wasm  rust-analyzer
| ...

-> cargo --version
| cargo 1.95.0 (f2d3ce0bd 2026-03-21)

-> rustup --version
| rustup 1.29.0 (2026-03-23)
| info: This is the version for the rustup toolchain manager, not the rustc compiler.
| info: the currently active `rustc` version is `rustc 1.95.0 (59807616e 2026-04-14)`

Yes, it should never happen in practice anyway, if the user wants to disable the translations, he/she can and I will not stop him/her. The app will still compile and run with the english language as default. If you think implementing the change is more in line with some guideline let me know. Feel free to join the maintainers if you're interested too

Oh, I didn't know that about globs, thanks for the explanation.

Though, wouldn't you want the build to fail if there are no translation files for some reason, since the expected state is having them?

Otherwise you're just having that part silently fail without knowing about it.

you're right. regarding the loop the guard is not guaranteed true. In bash with nullglob off (the default, and makepkg doesn't enable it), a glob that matches nothing is left literal. So if locale//LC_MESSAGES/samrewritten.mo matches no files, the loop still runs once with $mo set to that literal unexpanded string. [ -e "$mo" ] is then false, so continue skips it. Without the guard, install would try to install a file literally named locale//... and fail the build.

gettext is both in base and base-devel, there's no need to depend on it explicitly.

There's three maintainers but none of them are in the PKGBUILD header.

I don't get the point of this check, [ -e "$mo" ], isn't that already guaranteed to be true since $mo comes from a loop?

You can now simply use cargo fetch --locked --target host-tuple in prepare()

You should not be version bumping -git packages if you have no other changes - https://wiki.archlinux.org/title/Arch_User_Repository#Flagging_packages_out-of-date

https://aur.archlinux.org/cgit/aur.git/commit/?h=samrewritten-git&id=b206e1e7ac772e059cd8978b770e28e4cbc7e211

Please add git as a makedep, otherwise this won't build in a chroot.

Apologies. I've updated it to the new upstream provided PKGBUILD.

With the new repo, the version has reset, so you'll likely need a clean install to get it installed. This will also have the side effect of not automatically installing the new version for folks who upgrade.

The new version should work with non-snap installs now as described on its wiki.