Nightly Release For Debian

[zero77]

qBittorrent version and Operating System

Debian Sid

If on linux, libtorrent-rasterbar and Qt version

What is the problem

There's only a stable release branch for debian, which means you have to rebuild for every change to keep up to date.

What is the expected behavior

Have an equivalent repository like ppa:qbittorrent-team/qbittorrent-unstable but for Debian.
Perhaps, using the current experimental repository debian has.

[GvY85]

I would like this very much, same for libtorrent.
Now you have to install ~1,5GB of building tools that I down use for anything else than building qBittorrent-nox and libtorrent each time a new release comes out.
Ele, you are still on 4.1.5 or someting like that.

[zywo]

If you are in Debian sid(unstable), they pushed libtorrent-1.2.5 and qbittorrent-4.2.4 versions yesterday.

[Kolcha]

I can create and maintain repo on OpenSUSE build server (it can provide packages for Debian) like I did it for stable releases and start the build each week for example (sure, process can be automated)

[zero77]

That would be great, thanks @Kolcha

[Kolcha]

so, I created new subproject in my home project on OpenSUSE build server.
I can maintain it and keep active and updated if qBittorrent team members have no objections or can help to setup such official project. in any case it will be available as any other 3rd-party repo.

it uses completely unmodified sources from latest commits at the moment of building. RC_1_2 branch is used for libtorrent, master branch is used for qBittorrent. exact commit hashes are part of corresponding package versions.

deb packages are available for few Debian versions (10 and above) and Raspbian 10 (arm + aarch64). both qbittorrent and qbittorrent-nox are available, updated libtorrent is installed as dependency, python3-libtorrent is also available.

to start using it, just follow this link to add repo and install/upgrade qBittorrent

all sources, list of supported OSes and current build status can be viewed here
there is full content of that repo for Debian Unstable (i.e. sid), just to show that everything required is in it, and nothing more.

I plan to start build weekly (very likely each Monday), but any suggestions are welcome. right now there is no any automation, new builds (but without source changes) will happen only in case of dependencies updates (e.g. OpenSSL update), in such case only the last number in package version will changed.

[zero77]

@Kolcha
This sounds really good, thanks.
Although, i think the ubuntu nightly repo builds every 24 hours provided there is a change to the git repo.

[Kolcha]

nightly repo builds every 24 hours provided there is a change to the git repo

done! just wait for updated packages. both libtorrent and qbittorrent repos changes are tracked.
please note, packages version format has changed (this must not cause an update issues)

[zero77]

@Kolcha
It seams to be all working well, thanks

[GvY85]

Great! One request: could you do -nox builds for Debian stable as well?
Also, perhaps we should make a wiki note so more ppl can find it?

[Kolcha]

@GvY85 , -nox versions are also available, just install qbittorrent-nox instead of qbittorrent
they are just not listed because they are build from the same sources, and server displays only packages with the same as source archive names (i.e. qbittorrent). this like python3-libtorrent package is not listed, but it also exists.
if not sure, just view the content of repository following one of the links with desired OS (e.g. Debian 10) from this build server page, there you can see everything available, and also can find link "go to download repository" - here you will find what is available for download right now (it can be NOT the same as that was build, some time is required to delivery build artifacts to the repo).

[Kolcha]

what about wiki page, I agree, it is better to have a wiki page with that info, but I'm not sure that any user can add anything to project wiki, moreover, I think this is unfair to project team members just to publish something in their wiki. only they should decide what where and when to publish.
as I wrote before, my repo is just like any other 3rd-party repo, nothing more. it like something created for personal usage, but shared in hope that it will be useful for someone else.
also I can help official maintainer to setup something similar if they will be interested.

[zero77]

@Kolcha
There seems to be a problem with the build.

[Kolcha]

I looked into the logs, build failure cased by yesterday libtorrent changes related to CMake (I used it in build), and it looks like there is no quick solution, I'll back to it later, right now I have no time to deal with it.
among all cmake changes, one looks very frighteningly - they set insanely new required CMake version - 3.17.0, even Ubuntu 20.04 doesn't have it. I'm almost sure that it will be compiled fine with any version starting from ~3.14 or even less, but... cmake scripts must be pathed in any case....

but be sure, I'll fix build in 2-3 days in any case. qBittorrent build is fine, it only will use previous (last successfully compiled) libtorrent build.

in any thanks for notification, I'm even surprised that you noticed build failure only after few hours after it happened (build starts each day at ~6.30am).

[FranciscoPombal]

@Kolcha

among all cmake changes, one looks very frighteningly - they set insanely new required CMake version - 3.17.0, even Ubuntu 20.04 doesn't have it. I'm almost sure that it will be compiled fine with any version starting from ~3.14 or even less, but... cmake scripts must be pathed in any case....

No, we set it to 3.16:

qBittorrent/CMakeLists.txt

Line 1 in 05c7796

cmake_minimum_required(VERSION 3.16 FATAL_ERROR) # Policies <= CMP0097 default to NEW

which Ubuntu 20.04 does have, and also comes bundled with the official Qt distribution on Windows (or it did at the time, perhaps they have updated in the meantime).

However, it will probably build fine with a version as old as 3.14, but this is not recommended, patch and use at your own risk.

[Kolcha]

@FranciscoPombal , I'm talking about libtorrent:
https://github.com/arvidn/libtorrent/blob/3d48e7d0562ea2f345077e6e791c5ff438c5a6bc/bindings/python/CMakeLists.txt#L1
this line is appeared in arvidn/libtorrent@cfa5875
this is my main concern, I still use autotools build on linux for qBittorrent, only libtorrent is built using cmake

[FranciscoPombal]

@Kolcha

Ah, I see, sorry for the misunderstanding.

CMake >= 3.17 is required for libtorrent's python bindings now because of the new features used from the FindPython3 module: https://cmake.org/cmake/help/latest/release/3.17.html?highlight=changes#modules.

But if you don't care too much about python bindings, you can:

• revert that patch in your custom build
• not build the python bindings

both alternatives seem easy enough (the patch itself is very self-contained, so it is easy to revert).
Also note that Python 2 bindings are no longer built with the new changes.

Furthermore, I strongly recommend building qBittorrent with CMake now as well.

[Kolcha]

But if you don't care too much about python bindings

I care... I used it in my scripts, so it is required for me. but previously I did very simple change to build bindings only for Python3: https://build.opensuse.org/package/view_file/home:nikoneko:qbittorrent-nightly/libtorrent-rasterbar/cmake-find-python3.patch?expand=1 . so, maybe I'll revert my build scripts to use autotools

Furthermore, I strongly recommend building qBittorrent with CMake now as well.

it is planned, but I had not so much free time to rewrite qBittorrent Debian packaging scripts to cmake

[FranciscoPombal]

@Kolcha

I care... I used it in my scripts, so it is required for me. but previously I did very simple change to build bindings only for Python3: https://build.opensuse.org/package/view_file/home:nikoneko:qbittorrent-nightly/libtorrent-rasterbar/cmake-find-python3.patch?expand=1 . so, maybe I'll revert my build scripts to use autotools

The change was not just about building them only for Python3, it was also about simplifying the build script and not using deprecated CMake modules/features and not having a dependency on setuptools. Anyway, you can easily revert the change and apply yours, so that it still builds with older versions of CMake. No need to go back to autotools.

[Kolcha]

@zero77 build is fixed now!

[zero77]

@Kolcha Thank you.

Although after updating to the following package 4.4.0~alpha1.20201019T093003.05c779690-0+89.1, qbittorrent fails to start and i get the following error.

The legacy data directory '~/.local/share/data/qBittorrent/' is used. It is recommended to move its content to '~/.local/share/qBittorrent/'
The legacy data directory '~/.local/share/data/qBittorrent/' is used. It is recommended to move its content to '~/.local/share/qBittorrent/'
The legacy data directory '~/.local/share/data/qBittorrent/' is used. It is recommended to move its content to '~/.local/share/qBittorrent/'

qbittorrent-nox: symbol lookup error: qbittorrent-nox: undefined symbol: _ZN10libtorrent7session5startENS_5flags13bitfield_flagIhNS_17session_flags_tagEvEEONS_14session_paramsEPN5boost4asio10io_contextE

[FranciscoPombal]

@zero77

The legacy data directory '~/.local/share/data/qBittorrent/' is used. It is recommended to move its content to '~/.local/share/qBittorrent/'

This is an expected warning and the fix is self-explanatory. Be aware of #13519, though, you might also need to edit your config file to prevent the legacy directory location from being recreated at this time.

[zero77]

@FranciscoPombal
Thanks, i will sort that out.
I am guessing that it's more the second error that prevents qbittorrent starting.

qbittorrent-nox: symbol lookup error: qbittorrent-nox: undefined symbol: _ZN10libtorrent7session5startENS_5flags13bitfield_flagIhNS_17session_flags_tagEvEEONS_14session_paramsEPN5boost4asio10io_contextE

[Kolcha]

ugh... this is very strange... I'll check it later (today' evening)

[zero77]

No luck fixing it yet but, i have found:
https://github.com/qbittorrent/qBittorrent/wiki/Compilation:-Debian-and-Ubuntu#running-qbittorrent

[Kolcha]

@zero77 what you found affects only manually compiled libtorrent + qBittorrent, not packaged version
one exception, only if CMake files where broken somehow, and my package contains libtorrent at wrong path (I didn't checked it yet). please wait, I'll resolve these issues, but not right now, only in few hours

[zero77]

@Kolcha Thanks

[Kolcha]

@zero77 I checked my nightly builds for Debian 10/testing/unstable using qbittorrent-nox package in Docker containers (Kubuntu 20.04 as host), qbittorrent GUI on Debian 10 VM, and qbittorrent-nox on my server, no issues were found. so I assume bug is gone.
if you still observe it, just make sure that you don't have any other libtorrent rather than mine.

[zero77]

@Kolcha Thanks

[WolfganP]

BTW, I couldn't find out on the site, but is there any way to get an RSS notification when a new build is released? (just found browser notifications which aren't too useful)

[Kolcha]

I don't think that such feature exists... and this is pretty useless, it is supposed just to add repository, and packages will be updated as any other system packages. but autoupdate will NOT update packages from custom repositories by default, some configuration is required.
what about "update period", there is no any schedule, I trigger builds manually (running some script) approximately every Saturday.

[WolfganP]

Hi @Kolcha It seems that an error cropped up during the past days as the libtorrent 1.2 version didn't build up properly (https://build.opensuse.org/package/live_build_log/home:nikoneko:qbittorrent-nightly-lt12/qbittorrent/Raspbian_11/armv7l)
Any chance you can check it?

[Kolcha]

@WolfganP issue is fixed, wait for new qbittorernt package. what happened: for some unknown reason, libtorrent static library in package was corrupted. more correctly, library itself is correct (this is just an archive), but one specific object file (which should contain missing symbols linker complained about) inside it was corrupted. I see no reasonable explanation how it happened (there is no any suspicious output during corresponding file compilation) rather than just some disk I/O error on build agent during that file compilation, because even at the final stage of library creation archiver complained about "unknown format" for that particular object file, but succeeded regardless of it... so, library was created (and later packaged) with corrupted object file inside, and as result some symbols were missing in it.

as far as I know, this build server uses some real hardware for arm builds (at least for some agents), so maybe that "lucky" build was run on hardware with dying flash chip... who knows...

in any case, everything should be fine for now, just wait some time until new qbittorrent package appear. thanks for reporting, I rarely looking into build failures, because they very often happen due to out of memory (especially in case of arm builds) or other reasons completely unrelated to any source code.

[WolfganP]

@WolfganP issue is fixed, wait for new qbittorernt package. what happened: for some unknown reason, libtorrent static library in package was corrupted. more correctly, library itself is correct (this is just an archive), but one specific object file (which should contain missing symbols linker complained about) inside it was corrupted. I see no reasonable explanation how it happened (there is no any suspicious output during corresponding file compilation) rather than just some disk I/O error on build agent during that file compilation, because even at the final stage of library creation archiver complained about "unknown format" for that particular object file, but succeeded regardless of it... so, library was created (and later packaged) with corrupted object file inside, and as result some symbols were missing in it.

as far as I know, this build server uses some real hardware for arm builds (at least for some agents), so maybe that "lucky" build was run on hardware with dying flash chip... who knows...

in any case, everything should be fine for now, just wait some time until new qbittorrent package appear. thanks for reporting, I rarely looking into build failures, because they very often happen due to out of memory (especially in case of arm builds) or other reasons completely unrelated to any source code.

@Kolcha working perfectly now. Thx a lot for the prompt fix!

[GvY85]

Hi, something seems wrong with your repo keys:

apt update
Hit:1 https://deb.debian.org/debian bullseye InRelease
Hit:2 https://deb.debian.org/debian bullseye-updates InRelease
Hit:3 https://deb.debian.org/debian-security bullseye-security InRelease
Hit:4 https://deb.debian.org/debian bullseye-backports InRelease
Get:5 http://download.opensuse.org/repositories/home:/nikoneko:/test/Debian_11  InRelease [1,540 B]
Hit:6 https://www.deb-multimedia.org bullseye InRelease
Hit:7 https://www.deb-multimedia.org bullseye-backports InRelease
Ign:8 https://mkvtoolnix.download/debian bullseye InRelease
Hit:9 https://mkvtoolnix.download/debian bullseye Release
Err:5 http://download.opensuse.org/repositories/home:/nikoneko:/test/Debian_11  InRelease
  The following signatures were invalid: EXPKEYSIG 93368839B2B9A655 home:nikoneko OBS Project <home:nikoneko@build.opensuse.org>
Reading package lists... Done
W: GPG error: http://download.opensuse.org/repositories/home:/nikoneko:/test/Debian_11  InRelease: The following signatures were invalid: EXPKEYSIG 93368839B2B9A655 home:nikoneko OBS Project <home:nikoneko@build.opensuse.org>
E: The repository 'http://download.opensuse.org/repositories/home:/nikoneko:/test/Debian_11  InRelease' is not signed.
N: Updating from such a repository can't be done securely, and is therefore disabled by default.
N: See apt-secure(8) manpage for repository creation and user configuration details.
root@PiServer:~# echo 'deb http://download.opensuse.org/repositories/home:/nikoneko:/test/Debian_11/ /' | sudo tee /etc/apt/sources.list.d/home:nikoneko:test.list
deb http://download.opensuse.org/repositories/home:/nikoneko:/test/Debian_11/ /
root@PiServer:~# curl -fsSL https://download.opensuse.org/repositories/home:nikoneko:test/Debian_11/Release.key | gpg --dearmor | sudo tee /etc/apt/trusted.gpg.d/home_nikoneko_test.gpg > /dev/null
root@PiServer:~# sudo apt update
Hit:1 https://deb.debian.org/debian bullseye InRelease
Hit:2 https://deb.debian.org/debian bullseye-updates InRelease
Hit:3 https://deb.debian.org/debian-security bullseye-security InRelease
Hit:4 https://deb.debian.org/debian bullseye-backports InRelease
Get:5 http://download.opensuse.org/repositories/home:/nikoneko:/test/Debian_11  InRelease [1,540 B]
Ign:6 https://mkvtoolnix.download/debian bullseye InRelease
Hit:7 https://www.deb-multimedia.org bullseye InRelease
Hit:8 https://www.deb-multimedia.org bullseye-backports InRelease
Hit:9 https://mkvtoolnix.download/debian bullseye Release
Err:5 http://download.opensuse.org/repositories/home:/nikoneko:/test/Debian_11  InRelease
  The following signatures were invalid: EXPKEYSIG 93368839B2B9A655 home:nikoneko OBS Project <home:nikoneko@build.opensuse.org>
Reading package lists... Done
W: GPG error: http://download.opensuse.org/repositories/home:/nikoneko:/test/Debian_11  InRelease: The following signatures were invalid: EXPKEYSIG 93368839B2B9A655 home:nikoneko OBS Project <home:nikoneko@build.opensuse.org>
E: The repository 'http://download.opensuse.org/repositories/home:/nikoneko:/test/Debian_11  InRelease' is not signed.
N: Updating from such a repository can't be done securely, and is therefore disabled by default.
N: See apt-secure(8) manpage for repository creation and user configuration details.

[Kolcha]

this is not controlled by me... generated gpg keys used for repo signing expire after some time. and this time is now... all you need to do is just to redownload new generated key. follow the instructions for repo addition (you need to run only one line starting with `curl`) -- Sent from Mail.ru app for Android Monday, 06 February 2023, 09:34AM +01:00 from GvY85 ***@***.*** :

…

Hi, something seems wrong with your repo keys: http://download.opensuse.org/repositories/home:/nikoneko:/test/Debian_11 InRelease The following signatures were invalid: EXPKEYSIG 93368839B2B9A655 home:nikoneko OBS Project ***@***.***> Reading package lists... Done W: GPG error: http://download.opensuse.org/repositories/home:/nikoneko:/test/Debian_11 InRelease: The following signatures were invalid: EXPKEYSIG 93368839B2B9A655 home:nikoneko OBS Project ***@***.***> E: The repository 'http://download.opensuse.org/repositories/home:/nikoneko:/test/Debian_11 InRelease' is not signed. N: Updating from such a repository can't be done securely, and is therefore disabled by default. N: See apt-secure(8) manpage for repository creation and user configuration details. — Reply to this email directly, view it on GitHub , or unsubscribe . You are receiving this because you were mentioned. Message ID: @ github . com>

[GvY85]

That is what I though as well so I followed the instructions at https://software.opensuse.org//download.html?project=home%3Anikoneko%3Atest&package=qbittorrent

specially curl -fsSL https://download.opensuse.org/repositories/home:nikoneko:test/Debian_11/Release.key | gpg --dearmor | sudo tee /etc/apt/trusted.gpg.d/home_nikoneko_test.gpg > /dev/null

But I get the same error after apt update

[Kolcha]

it seems key was deprecated, but new one was not generated/uploaded for that repo yet

for example, for nightly repo key was added at 1 AM (who knows which time zone, very likely server time)

so, please wait some time. there is nothing depending on me...

[Kolcha]

seems new keys are already available, and can be downloaded manually from here:

• for stable (aka "test") repo
• for nightly repo
• for LT1.2-based nightly

at least for "test" repo this key is different comparing to Release.key downloaded from repo.

[GvY85]

curl -fsSL https://build.opensuse.org/projects/home:nikoneko:test/public_key | gpg --dearmor | sudo tee /etc/apt/trusted.gpg.d/home_nikoneko_test.gpg > /dev/null for Stable works indeed

[GvY85]

@Kolcha again thanks for the good work!

Now with Bookworm being in hard freeze, are you planning on making a Bookworm repo? I am using Testing currently but a separate Bookworm repo somewhere in the coming months will be appreciated.

[Kolcha]

@GvY85 , sorry, this is doesn't depend on me. I'm using what this "openSUSE build service" provides, this is the only all-in-one solution which can build packages for Debian I found...
also I don't think that testing repo will be somehow different to upcoming Bookworm release repo, at least it was so with current Bullseye release -- at the moment of release all repositories were the same (i.e. stable = testing = sid). so, I don't think that some thing can cause any compatibility problems, maybe only python.
even more, it seems that build service I'm using updates build environments not so often.

[WolfganP]

Hi @Kolcha . As always, thx for keeping this builds working.

I was surprised I didn't noticed any update since days ago, so I went to your opensuse's project logs and found that it seems the builds weren't triggered since March 25th (not only for the raspbian static libtorrent 1.2 version but for others as well).
Any chance to check it?
Thanks in advance.

[Kolcha]

Hi @WolfganP . sorry for this. builds are triggered only manually from my personal laptop, but past 3 weeks (since March 26) I was not a home and without my personal laptop. I returned only today, so new builds will appear very soon.

[WolfganP]

Hi @WolfganP . sorry for this. builds are triggered only manually from my personal laptop, but past 3 weeks (since March 26) I was not a home and without my personal laptop. I returned only today, so new builds will appear very soon.

Perfect, thanks @Kolcha. No problem at all with the delay, I just assumed the builds were triggered by commits at github or similar, and something changed at opensuse's side that was worthy to bring to your attention. Thx again!

[GvY85]

Hi, the Testing repo with qbittorrent-nox-qt6 does not work anymore now that Bookworm is out. Package is held back because it needs libtorrent-rasterbar2.0_2.0.9. That one is in the Debian_11 repo but when you add that one it cannot install because libssl1.? is not available.

[Kolcha]

thanks for notifying, I'm not using Debian anymore, so don't know what happens around it.
now I added Debian 12 repos, and disabled Debian Unstable as so as official package is built against Qt6!
regarding Debian Testing, it is unclear for now what to do, some time need to pass until Debian updates own repositories, and more important build service updates Debian images used for builds (testing and unstable seems to be updated more rarely rather than stable). similar situation was observed when Debian 11 released in the summer 2021. process should become "smooth" again in about a month.

Debian 12 builds will appear in the repos very soon (in ~1 hour), so you can add and use Debian 12 packages instead of incompatible Debian Testing.

[GvY85]

Work a charm! Thanks

[Kolcha]

qBittorrent devs raised minimum required Qt version to Qt 6.5, see a0fa170
this makes impossible to build qBittorrent with system-provided Qt even on Debian Unstable (only Qt 6.4.x is available in Debian repos), so builds available right now are the last available for a long time until Debian update Qt 6 in its repos.

even such change is reasonable (at least as for me), as so as drops compatibility stuff from the code base, but imho it a bit early. I'm not sure that Qt 6.5 is available in latest Ubuntu. it will be a breaking change if this will be included into upcoming release...

so, no nightly builds for now. build Qt and qBittorrent by yourself if you want nightly build.

[glassez]

it will be a breaking change if this will be included into upcoming release...

v4_6_x is already branched off and it will be used for v4.6.x releases and it supports Qt 6.2+ (as well as Qt 5.15.2+).
master has now set a course for a future major update, which is unlikely to be released earlier than in half a year.
Unfortunately, someone will now be disappointed by the lack of these nightly builds. But this is not a critical problem due to the fact that we provide test builds on GitHub.

[Kolcha]

good news everyone! based on ppa mentioned in this discussion #19457 , I built static version of Qt 6.5 for Debian

qBittorrent nightly builds for Debian 12+ will be available soon, but there are some difficulties with Debian 11. finding a solution may require some time, but I'm thinking it doesn't worth. so would like to ask some questions:

• is Debian 11 (including Raspbian 11) still needed? supporting it will require to use backported packages + some hacks/fixes
• is armv7 arch still needed? build time for it is extremely long...
• should I provide builds for arm arch (arm64/aarch64) at all?

please leave your comments on it. this is really important, as so as building for different archs and distros is very time- (and resource-) consuming process, and I do not want to just spend build server resources for no value, and also solve any build issues raising from time to time.

also please let me know about any run-time issues, as so as static Qt is very bad idea (at least it was so with Qt 4 and 5, know nothing about Qt 6). I just "smoke" tested GUI build for Debian Unstable, the rest are completely untested, but should be fine.

[WolfganP]

Thanks a lot @Kolcha for keeping these builds alive

* is Debian 11 (including Raspbian 11) still needed? supporting it will require to use backported packages + some hacks/fixes

* is armv7 arch still needed? build time for it is extremely long...

* should I provide builds for arm arch (arm64/aarch64) at all?

I'm using a Raspberry2 (armv7l platform) as a torrent/file/media server, so the builds for qbittorrent-nox for arm7hf with static libtorrent 1.2 are my way to go (I don't really know if full QT is even needed in the build as it's a headless server)

But saying that, I also don't think a nightly/daily build is needed for my use (in case you need to maintain build resources low).

Again, thanks a lot for these builds.

[Kolcha]

Debian 11 (and Raspbian 11) for nightly builds (from master branch) will not be supported anymore - qBittorrent uses some C++20 features which seems unavailable in GCC 10 (Debian 11 default). so, it's time to say goodbye to Debian 11., nightly builds will be available only for Debian 12+

@WolfganP , I'll create new qbittorrent release package based on libtorrent 1.2 in "test" repo where lt2.0 based builds are available. release builds are available for Debian 11+ and for arm and x86, both 32 and 64 bit. and this will be supported for a long time, as so as qBittorrent 4.6.x branch still compatible with older Qt6 and even 5.15

existing lt1.2 based nightly builds repo will be dropped very soon.

[WolfganP]

@WolfganP , I'll create new qbittorrent release package based on libtorrent 1.2 in "test" repo where lt2.0 based builds are available. release builds are available for Debian 11+ and for arm and x86, both 32 and 64 bit. and this will be supported for a long time, as so as qBittorrent 4.6.x branch still compatible with older Qt6 and even 5.15

Much appreciated @Kolcha , thanks a lot.

[Kolcha]

now latest release based on libtorrent 1.2 (static version) is also available in "test" repo (where stable release is available), package name is qbittorrent-lt12, both GUI and "nox" versions are available (append "-lt12" suffix to known package names)

[WolfganP]

now latest release based on libtorrent 1.2 (static version) is also available in "test" repo (where stable release is available), package name is qbittorrent-lt12, both GUI and "nox" versions are available (append "-lt12" suffix to known package names)

Qbt v4.5.5-nox-lt12 working perfectly from the new repository. Thanks a lot!

Updt: it just installed perfectly but doesn't actually work. Can't connect to trackers, saying "Permission denied". I'll troubleshoot and report back.

Updt2: seems like the new libraries and previous instance made a mess. A server restart solved all the issues. Thanks again!