FS#64937 - [deluge] packaged version is not released

Attached to Project: Arch Linux
Opened by Rafael (raffomania) - Sunday, 22 December 2019, 21:08 GMT
Last edited by Jan Alexander Steffens (heftig) - Sunday, 19 July 2020, 09:11 GMT
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To Jan Alexander Steffens (heftig)
Architecture All
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 1
Private No

Details

Description:
The package for deluge contains an unreleased version. Usually, I would not care about this, but deluge reports its version to torrent trackers as the following:
"2.0.4.dev20".
Some of my trackers have now started blocking my deluge installation because the version string contains the word "dev", and they won't unblock me until I switch to a stable deluge version.
Also, it's confusing that the package metadata states the version as "2.0.3+23+g5f1eada3e-1", but that might be intentional, I'm not sure if you want to mirror upstream versions closely or not.

Thanks for packaging one of the best torrent clients there is :)
This task depends upon

Closed by  Jan Alexander Steffens (heftig)
Sunday, 19 July 2020, 09:11 GMT
Reason for closing:  Fixed
Additional comments about closing:  deluge 2.0.4.dev38+g23a48dd01-2
Comment by loqs (loqs) - Sunday, 22 December 2019, 21:52 GMT
The PKGBUILD generates its version from `git describe`
deluge during build uses `git describe --tags --match deluge-[0-9]*`
The most recent tag for 5f1eada3eae215f0fd489000e97792c892fb7b17 is deluge-2.0.4.dev0.
The tag deluge-2.0.4.dev0 is not an annotated tag so is ignored by `git describe` without the --tags option.
The next most recent tag is tag deluge-2.0.3 which is an annotated tag hence the mismatch.
Comment by Eli Schwartz (eschwartz) - Sunday, 22 December 2019, 21:54 GMT
Well, yes, the version number is plainly intentional since the intention when packaging it was to package an unstable development version. https://git.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/deluge&id=3e89f5bfd579cb5f9914922940335884f676f7d5

This is common in the gnome/gtk ecosystem, for better or for worse. It seems reasonable to not do so in this case though...
Comment by Jan Alexander Steffens (heftig) - Sunday, 22 December 2019, 23:52 GMT
We use a non-released version because it contains important fixes.
Comment by Jan Alexander Steffens (heftig) - Monday, 23 December 2019, 00:08 GMT
Anyway, you can easily lie about Deluge's version by changing the user_agent in /usr/lib/python3.8/site-packages/deluge/core/core.py.

It's just as unreliable as a browser's user agent. I'm pretty baffled some trackers think whitelists are a good idea.
Comment by Eli Schwartz (eschwartz) - Monday, 23 December 2019, 01:24 GMT
If it doesn't work out of the box, then maybe the PKGBUILD should change the user agent at least?
Comment by Sven-Hendrik Haase (Svenstaro) - Wednesday, 25 December 2019, 03:26 GMT
As a user of deluge also on private trackers, I think it'd make the most sense to change the user agent to what the package version "is meant to be" in the package.
Comment by Drew (Drew) - Saturday, 18 July 2020, 20:03 GMT
If these fixes are so important, then why hasn't deluge released them? Could you please explain what these fixes are?
Comment by Eli Schwartz (eschwartz) - Sunday, 19 July 2020, 04:06 GMT
According to the commit message, the fixes in question are: "2.0.3+23+g5f1eada3e-1"

I notice that half a year later, we're still packaging known bad software. Can we do something about that?

Loading...