Fix: xmlrpc-c will not compile on newer systems

[zottelbeyer]

Description

XML-RPC-C fails to configure on my QNAP NAS and updating the config.guess / config.sub fixes it.

Fixes issues:

• Un-tracked issue...

Proposed Changes:

• download updated config.guess and config.sub before configuring xml-rpc-c

Change Categories

• Bug fix

Checklist

• Branch was made off the develop branch and the PR is targetting the develop branch
• Docs have been made OR are not necessary
• Changes to panel have been made OR are not necessary
• Code is formatted (See more)
• Code conforms to project structure (See more)
• Shellcheck isn't screaming (See more)
• Prints to terminal are handled (See more)
• I have commented my code, particularly in hard-to-understand areas
• Testing was done
  • Tests created or no new tests necessary
  • Tests executed

Test scenarios

Architectures

	amd64	armhf	arm64	Unspecified
Jammy
Focal
Bionic
Bullseye			✅
Buster
Stretch
Raspbian	⚫️		⚫️	⚫️

✅❎ Passed

🛠🛠 TODO

❌❌ Currently failing

[stickz]

Could you try retrieving xmlrpc-c from GitHub? And compiling from the stable folder? https://github.com/mirror/xmlrpc-c

This is not a good solution because it adds overhead. We should retrieve it from GitHub using git clone instead. It's faster and more reliable. Furthermore, if this link becomes invalid (which often happens on the GNU website) the install script will fail.

[stickz]

Alternatively, if the developer version of xmlrpc-c is broken, we could distribute these two files with the project as patches. Then copy them to the xmlrpc-c installation folder. It's more important to keep things working, then have the latest version.

[zottelbeyer]

Could you try retrieving xmlrpc-c from GitHub? And compiling from the stable folder? https://github.com/mirror/xmlrpc-c

This is not a good solution because it adds overhead. We should retrieve it from GitHub using git clone instead. It's faster and more reliable. Furthermore, if this link becomes invalid (which often happens on the GNU website) the install script will fail.

the stable version from git compiles fine for me.

Alternatively, if the developer version of xmlrpc-c is broken, we could distribute these two files with the project as patches.
Then copy them to the xmlrpc-c installation folder. It's more important to keep things working, then have the latest version.

Yes, I see the point in that. The affected hardware is a TS-832PXU which I believe was released in 2021.

It would probably be enough to just update the revision to a later version?
If you want me to try another revision let me know. Also let me know if we should move this to an issue rather than a PR.

[stickz]

Yes, I see the point in that. The affected hardware is a TS-832PXU which I believe was released in 2021.

It would probably be enough to just update the revision to a later version?

I would ask @liaralabs for thoughts on using the GitHub mirror. We can reset the version to pin the latest commit. svn co has performance issues. I was thinking about changing it last release cycle, but left it because there wasn't a good reason.

[stickz]

Even if git clone and git reset --hard takes a few hundred milliseconds longer, it uses a fraction of the CPU resources. This has a significant advantage when deploying to weaker systems like Raspberry PIs. Furthermore, I have plans to clone source files and download plus extract tar files asynchronously. It will save seconds and work everywhere with git.

[liaralabs]

The version of XMLRPC-C was carefully chosen because being a bit more careless with xmlrpc-c versioning has led to weird quirks and bugs which have manifested in the form of rtorrent crashes. I don't know if rtorrent or xmlrpc are to blame for the crashes; however, rakshasa hasn't released any stable versions of rTorrent since 2019 (our xmlrpc version is from 2017) so I'm still a bit skeptical that newer versions won't just regress and bring these quirks back into the fold.

The only way to find out though is to test.

I don't really have a preference for git vs svn -- svn is the official way of accessing the source code though and the authors certainly don't promote or encourage users to use the github mirror in their documentation.

I would only say that I'm generally against tracking the latest commit and would prefer if requests to change the version of XMLRPC-C are tested before blindly choosing a new version. Tracking head used to be the previous behavior before a version pin was put into place and I don't intend to revert this behavior.

Case and point: debian and ubuntu have both been using 1.33.14 since as far back as Bionic/Stretch and newer OSes don't utilize newer versions. I'm not really in a hurry to bump the version of this dependency, to be honest.

Edit: we already store patches for deluge and rtorrent in the sources/patches/appname directory, so just turning this fix into a diff and applying the patches during build time is likely the path of least resistance here.

[stickz]

Okay, no problem. We can distribute these with the project. I do think git is a better solution for this project though. It works much better when deploying to systems like Raspberry PIs. We need to reduce overhead in the installation process.

I found the commit you're referring to. We can reset the version to match what Ubuntu is distributing.
mirror/xmlrpc-c@095ac1b

[stickz]

I'm waiting on #975 merge to patch this problem. It's not compatible because the installation directory has changed.

[stickz]

Never mind actually. I'm going to apply the patch to the current directory. It can be changed afterwards for async tasks.