Arch Linux User Repository

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.

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.

Recently, I've been getting an error when using “sftpman”.

the output returns:

Traceback (most recent call last):
  File "/usr/lib/python3.12/importlib/metadata/__init__.py", line 397, in from_name
    return next(cls.discover(name=name))
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
StopIteration

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/bin/sftpman", line 33, in <module>
    sys.exit(load_entry_point('sftpman==1.2.2', 'console_scripts', 'sftpman')())
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/bin/sftpman", line 22, in importlib_load_entry_point
    for entry_point in distribution(dist_name).entry_points
                       ^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.12/importlib/metadata/__init__.py", line 862, in distribution
    return Distribution.from_name(distribution_name)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.12/importlib/metadata/__init__.py", line 399, in from_name
    raise PackageNotFoundError(name)
importlib.metadata.PackageNotFoundError: No package metadata was found for sftpman

this is failing to build in a chroot (via aurto) because of missing libcrypto.so.1.1