deluge 2 upgrade to python 3.10 fix for DSM 7

[Strangelovian]

Motivation: Have the deluge 2.0 upgrade functional with python 3.7
Linked issues: #4134, #4158, closes #4701, hopefully closes #5177

Update as deluge 2.0.5 was officially released in Dec 2021

• Update Deluge to v 2.0.5
• Update to Python 3.10
• Update for DSM 7
• No need for prerelease by @Strangelovian (tanks for investigation anyway).
• Finally libtorrent was updated to v1.12.10 (further updates, or updates to libtorrent v2 are out of scope here, and probably not compatible with the synology toolchains).

Notes:

• Cross compilation works for at least: x64, aarch64, denverton
• x64 and denverton packages are confirmed working on DS1819+: install OK, download torrent OK, uninstall OK
• the core.conf was changed to have initially a single port configured, else deluge 2 will not managed to bind any port. Deluge 2 manages only one listen port. The core.conf still accepts a list of listen ports in the core.conf for compatibility reasons with deluge 1.x.
• I updated the package icon to new deluge 2 icon
• boost upgrade is needed from v1.63 to v1.67, else Python3.Boost fails to compile
• cross compilation fails with boost v1.74 for aarch64. Fortunately v1.67 works with all architectures

CAVEAT PLEASE READ:
deluge daemon v2.0.3 won't start because of this issue: https://dev.deluge-torrent.org/ticket/3278
The fix is already done here deluge-torrent/deluge@1b4ac88
But no release was made since 2.0.3 so I forked it to have the last update: https://github.com/Strangelovian/deluge/tree/2.0.4-str0
Now, I will ask the deluge team to build an official 2.0.4 to avoid using my fork. https://forum.deluge-torrent.org/viewtopic.php?f=8&t=55767
Normally this should be quick to do, even though the deluge developments have really slowed down recently.

Checklist

• Build rule all-supported completed successfully
• Package upgrade completed successfully
• New installation of package completed successfully

upgrade to boost 1.67

upgrade to libtorrent 1.2.9

build from deluge bleeding edge 2.0.4

update deluge icon

adjust core.config with a single port, as required by deluge version 2.x

[ymartin59]

@hgy59 I request your opinion about Boost upgrade. If I remember well, version is stuck because of others applications, right?

[ymartin59]

Deluge wizard provides instruction I wonder if it is still relevant for version 2: To allow clients to remotely connect to the daemon, see <a target=\"blank\" href=\"https://dev.deluge-torrent.org/wiki/UserGuide/ThinClient\">the ThinClient guide of Deluge</a>
May you please check to confirm if this should be discarded or not from wizard.
By the way, I would prefer to have details in a dedicated wiki page at https://github.com/SynoCommunity/spksrc/wiki/Package-Documentation-Index

[Strangelovian]

Deluge wizard provides instruction I wonder if it is still relevant for version 2: To allow clients to remotely connect to the daemon, see <a target=\"blank\" href=\"https://dev.deluge-torrent.org/wiki/UserGuide/ThinClient\">the ThinClient guide of Deluge</a>
May you please check to confirm if this should be discarded or not from wizard.
By the way, I would prefer to have details in a dedicated wiki page at https://github.com/SynoCommunity/spksrc/wiki/Package-Documentation-Index

Deluge v2.x is still based on daemon + client. Of course, daemon + delugeweb client still works. Most people will use this with synology nases, as the syno spksrc packages both.
I didn't try to start daemon + gtk thin UI. First of all, the gtk UI is no longer shipped on windows since deluge v2.x, because of a problem with the gtk library and windows.
@ymartin59 If you ask me, I would rather remove the thin client link from the wizard.

[Strangelovian]

check fails details as of 10/25/2020:

• qoriq-6.1 / evansport-6.1: missing linux header if_link.h IFLA_CARRIER IFLA_PROMISCUITY in toolkit, libtorrent v1.2.9 cannot be built
• ppc853x-5.2 / 88f6281-6.1: saltminion python 3.7 build fails (Building wheel for pyzmq)

@ymartin59 @hgy59 may I have your opinion about this?

[hgy59]

* ppc853x-5.2 / 88f6281-6.1: saltminion python 3.7 build fails (Building wheel for pyzmq)

Don't worry about salt-minion. These archs failed since the package was added with #4119. I don't know why this PR was merged without defining older ppc and ARM5 archs as unsupported.

[ymartin59]

@hgy59 My fault.... we should create a common "review checklist" in wiki so that no point is missed.

[Strangelovian]

@hgy59 My fault.... we should create a common "review checklist" in wiki so that no point is missed.

@ymartin59 @hgy59 ok about that salt-minion. About qoriq and evansport, is it OK to drop support because of libtorrent? Maybe it's going to improve with DSM7 for those 2 archs, if they get a more recent cross compilation toolkit. What do you think?

[Strangelovian]

@ymartin59 @hgy59 after clean-up of unsupported arches, clean-up of wizard text, all seems pretty much OK. Ready for review?

[zyrill]

@hgy59 anything that still needs doing here that I can help with?

[hgy59]

@hgy59 anything that still needs doing here that I can help with?

There is no official v2.0.4 yet.
I propose to leave this PR untouched for experimantal builds by interested users, until a new release is created in the official repo (if ever ?).

for me the deluge projects seems dead, as since 2019-06-12 there is no aticivity under https://git.deluge-torrent.org/deluge

[zyrill]

@hgy59 you're right about the project being abandoned - so wouldn't it then make sense to also close this ticket? Interested parties could still search for it but maybe nobody should be encouraged to actually use it. Plus this would clean up one more item on the open PR list.

[ymartin59]

Thanks for contribution. I have minor improvements proposals.

[hgy59]

as #4539 is now on the master branch, this PR needs some rework.
all >> ${INST_LOG} in service-setup.sh have to be removed for service_postinst to work.
and service_preinst must be renamed to validate_preinst to get the same output for echo in this function.

[hgy59]

On another note, are you able to rebase against master so the code is using the latest changes?

It was already rebased to b07fbcc two days a go.
now I have rebased to fed9f03.

[hgy59]

but I still have pending patches for this PR

@th0ma7 I could not find any branch in your repo related to delugepy.
Can you tell me on which of your banches / which commit are for delugepy? I will try to cherry pick those into this PR.

[Safihre]

@hgy59 You seem to be getting the same problem as me with SABnzbd, cryptography suddenly fails to build..

[th0ma7]

@hgy59 seems I was able to push changes in... Seems I had first to use gh to get things up.

EDIT: I've now pushed in what was pending on my drive, I'll have to revisit later on over the week-end to confirm it's all working as intended.

[th0ma7]

@Safihre using your changes from #5316 fixed building on my local tree :)
@hgy59 feel free to rebase once @Safihre PR is merged!

[th0ma7]

@hgy59 what's now left is getting rid of dsm-control.sh. At first glance two options comes to mind:

1. Modify start-stop-status to allow managing multiple daemon startups. This could be done using a default delimiter such as : or using \n and parsing each lines as separate daemons. This also leads to adapting the PID_FILE creation in order to concatenate pid's.
2. Use something similar to rutorrent: default start-stop-status script refers to usual SERVICE_COMMAND but it calls another script to do the work. That other script could be of a similar nature and would start-up both daemons and adjust pid file as well.

I think option 1) would bring more benefit as it can be reused on any package aftewards. On the other hand we must be careful as depending how it's done it may impact spechial caracters (e.g. \something) although I haven't noticed any of that. On the other hand option 2) could be easier/faster to implement.

I'll give it a shot at option 1) and see how it turns out. Worst case we can simply undo it afterwards.

[th0ma7]

A follow-up, the good:

• Option 1. looks relatively simple to implement. Got some code I'm currently playing with pending further testing/debug.

The bad:

• libboost_python310.so.1.70.0 is not being packaged... actually not even being copied over to the target/lib at the end of boost build/installation. So there is that to fix either by further changing boost 1.70 or switching to a newer boost version.

The ugly:

• After manually copying it over and restarting deluge, it currently segfault core-dump on deluged. Perhaps due to incompatible boost library?

[th0ma7]

A subsequent follow-up:

The good:

• got a deluge 2.0.5 + python310 + boost 1.78 + libtorrent 2.0.6 working (e.g. loads to memory properly)
  This is only good for DSM7 as c++14 is needed (and fails with c++1y equivalent on gcc-4.9)
  Code is on my local drive, nothing pushed up yet as I have more testing to do
  I still have to test building boost 1.70 while enforcing c++1y using gcc-4.9 then try to build libtorrent 2.x ...
• got a deluge 2.0.5 + python310 + boost 1.70 + libtorrent 1.2.16 building OK (but segfault, at least on DSM6)

The bad:

• Latest version of boost officially supporting c++11 from gcc<5.1 is boost 1.70 (1.71 might work, haven't tried but fails starting with 1.72). This mean DSM6 = boost 1.70ish
• boost 1.70 doesn't support python310. While we do have a patch there is more needed to get it working (e.g. getting libboost_python310.so.1.70.0 installed for a start). Note that official py310 support only started with boost 1.76

The ugly :
Our options are:

1. only use libtorrent 1.2 + boost 1.70 - but segfault needs fixing
2. use different versions for DSM6 vs DSM7
3. only support DSM7

[Ber-Flo]

@th0ma7 as a DSM7 user, Deluge is really missing me since the upgrade, wouldn't it be better to have a version supporting the latest version of DSM only rather than a version less and less used and outdated ?

[th0ma7]

@Strangelovian can you please allow edit from maintainers to simplify the process of updating this PR? Thnx in advance.

[Strangelovian]

@Strangelovian can you please allow edit from maintainers to simplify the process of updating this PR? Thnx in advance.

it's already allowed, please check

[th0ma7]

Thnx @Strangelovian but I was having too many issues trying to update from your PR. As such I've started a nwe one and imported all changes as co-authored commit and resumed work from there using a clean and rebased branch (PR #5398). It is now much closer from a release as latest version of binaries do compile and run properly (while still missing proper startup mechanism).

Feel free to chim-in if you have spare cycles and thnx again for your efforts on this.