Arch Linux User Repository

sftpman has been rewritten in Rust.

The sftpman AUR package (which used to provide the Python) version now provides the new Rust version. The old (Python) version can still be found in the sftpman-python package.

As for the GUI, the old sftpman-gtk software (Python) has also been superseded by sftpman-iced (Rust).

You may also be interested in reading:

• Is sftpman v2 compatible with sftpman v1?

• Is sftpman-iced compatible with sftpman-gtk?

• The sftpman FAQ

• The sftpman-iced FAQ

@szmaszmo, your issue is with sftpman-iced, not this package (sftpman).

That said, what's your mesa version?

I've had similar trouble with mesa when it's lower or equal to version 25.0.1 due to this: https://gitlab.freedesktop.org/mesa/mesa/-/issues/12799

You may run vulkaninfo --summary | grep conformanceVersion and see if the reported version is 0.0.0.0 or something else.

Once I've upgraded to mesa 25.0.2, the problem disappeared for me.

This new version does not work for me with Nvidia-Hybrid Model: "nVidia GF108M [GeForce GT 620M/630M/635M/640M LE]". Actually I am unsure why should I need graphics acceleration for such a simple software. The old python gtk variant is the only one works. Here is the issue: $ sftpman-iced Xlib: extension "NV-GLX" missing on display ":0". MESA-INTEL: warning: Ivy Bridge Vulkan support is incomplete [2025-03-23T13:20:14Z WARN wgpu_hal::vulkan::adapter] Adapter is not Vulkan compliant, hiding adapter: Intel(R) HD Graphics 4000 (IVB GT2) [2025-03-23T13:20:14Z WARN wgpu_hal::vulkan::adapter] Adapter is not Vulkan compliant, hiding adapter: Intel(R) HD Graphics 4000 (IVB GT2) Error: GraphicsCreationFailed(GraphicsAdapterNotFound { backend: "wgpu", reason: RequestFailed("no adapter was found for the options requested: \"RequestAdapterOptions { power_preference: LowPower, force_fallback_adapter: false, compatible_surface: Some(Surface { context: ContextWgpuCore { type: \\\"Native\\\" }, _surface: \\\"Some\\\", id: ObjectId { id: Some(4294967296), global_id: Some(4294967296) }, data: Any { .. }, config: Mutex { data: None } }) }\"") }) I have tried to set environment with different variables like DISPLAY, RUST_BACKTRACE and so on, but nothing worked for me so far.

Thank you for suggesting these improvements!

I have removed replaces and only left conflicts where it makes sense (in sftpman and sftpman-python which do conflict with one another). sftpman-gtk and sftpman-iced do not conflict.

You're right about arch. I was thinking that any means "should work on all architectures" as long as you recompile, but the PKGBUILD#arch documentation actually says:

arch=(any) indicates the package can be built on any architecture, and once built, is architecture-independent in its compiled state (usually shell scripts, fonts, themes, many types of extensions, Java programs, etc.).

So, any was the wrong choice. The compiled result for us is architecture-specific and recompilation is necessary to make it work on other architectures.

Listing architectures in arch one by one (or a new * option which doesn't exist yet) may be OK, but… given that we haven't really tested and don't really know which architecture works, I've only left x86_64 in the arch list for now.

Some small remarks after looking at both PKGBUILDs :)
arch isn't any anymore. It needs to be at least replaced with x86_64 as it contains architecture specific code.
And in case of the new graphical: replaces isn't really a thing for the AUR (doesn't work on sync and -U, only sysupgrade). Although the intention is to replace the deprecated program it should make use of conflicts instead.
namcap also has the following remark for both:

sftpman W: ELF file ('usr/bin/sftpman') lacks GNU_PROPERTY_X86_FEATURE_1_SHSTK.

sftpman-iced W: ELF file ('usr/bin/sftpman-iced') lacks GNU_PROPERTY_X86_FEATURE_1_SHSTK.

Missing some flags, or not respecting the flags from Arch? Or false positive because rust?

Edit: It seems this has some details

Hello again,
thank your for your explanation. All in all reasonable and comprehensible :) Especially in the light of the temporary nature for the python version.

Hello!

Thank you for your feedback!

I didn't like the "opt-in" solution, because as far as I am concerned the Python-based sftpman project is dead. The sooner everyone moves away from it onto the new software, the better.

That said, I have intentionally kept the old projects around for now, so that people that hit problems with the new software (if any) would have something to fall back on, until the problems get addressed.

About the naming of the Python program, I see your point about using a python- prefix, but find it inconsistent with how all other packages are named (sftpman*).

For the new package, sftpman-rs would have been a more consistent name and would have provided a more gradual opt-in switch as well as making all packages being consistently named sftpman-*, but it doesn't align with the ultimate goal: people migrating to it quickly & only sftpman and sftpman-iced remaining in the future.

The existing AUR package names for the new software (sftpman and sftpman-iced) match the names of the software and binaries that they package, which is nice.

As it stands, only sftpman-python has a name that doesn't match the name of the binary being packaged, but it's a temporary package that I hope no one would need to use anymore.

Hello :)
Regarding the naming. Wouldn't it have been better to upload sftpman-rs as a new PKGBUILD and let this stay as the python package and just write a notice to point to the new package? More like opt-in instead of opt-out (need to look at your provided information regarding the rewrite and such and would need to replace a package to remain at the working status quo).
And the names of the PKGBUILDs would have stayed in sync with the names from your upstream repos? Now it is a little bit more confusing, as sftpman is sftpman-rs and sftpman-python would be sftpman.
(And although it isn't strictly a library, the name of the python package should propably have been python-sftpman?)[0]

[0] https://wiki.archlinux.org/title/Python_package_guidelines#Package_naming

sftpman has been rewritten in Rust.

The sftpman AUR package (which used to provide the Python) version now provides the new Rust version. The old (Python) version can still be found in the sftpman-python package.

As for the GUI, the old sftpman-gtk software (Python) has also been superseded by sftpman-iced (Rust).

You may also be interested in reading:

• Is sftpman v2 compatible with sftpman v1?

• Is sftpman-iced compatible with sftpman-gtk?

• The sftpman FAQ

• The sftpman-iced FAQ

Thank you @s.pantaleev

paru --rebuild sftpman

fixed the issue :-)

You likely just need to rebuild this package, now that your Python version had been upgraded.