mirror of
https://github.com/qbittorrent/qBittorrent.git
synced 2026-03-02 22:57:32 -05:00
Nightly Release For Debian #10252
Labels
No labels
Accessibility
AppImage
Bounty
Build system
CI
Can't reproduce
Code cleanup
Confirmed bug
Confirmed bug
Core
Crash
Data loss
Discussion
Docker
Documentation
Duplicate
Feature
Feature request
Feature request
Feature request
Filters
Flatpak
GUI
Has workaround
I2P
Invalid
Libtorrent
Look and feel
Meta
NSIS
Network
Not an issue
OS: *BSD
OS: Linux
OS: Windows
OS: macOS
PPA
Performance
Project management
Proxy/VPN
Qt bugs
Qt6 compat
RSS
Search engine
Security
Temp folder
Themes
Translations
Triggers
Waiting diagnosis
Waiting info
Waiting upstream
Waiting web implementation
Watched folders
WebAPI
WebUI
autoCloseOldIssue
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/qBittorrent#10252
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @zero77 on GitHub (Apr 24, 2020).
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-unstablebut for Debian.Perhaps, using the current experimental repository debian has.
@GvY85 commented on GitHub (Apr 24, 2020):
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 commented on GitHub (Apr 24, 2020):
If you are in Debian sid(unstable), they pushed libtorrent-1.2.5 and qbittorrent-4.2.4 versions yesterday.
@Kolcha commented on GitHub (Apr 24, 2020):
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 commented on GitHub (Apr 24, 2020):
That would be great, thanks @Kolcha
@Kolcha commented on GitHub (Apr 24, 2020):
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
qbittorrentandqbittorrent-noxare available, updated libtorrent is installed as dependency,python3-libtorrentis 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 commented on GitHub (Apr 25, 2020):
@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 commented on GitHub (Apr 25, 2020):
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 commented on GitHub (Apr 26, 2020):
@Kolcha
It seams to be all working well, thanks
@GvY85 commented on GitHub (Apr 28, 2020):
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 commented on GitHub (Apr 28, 2020):
@GvY85 , -nox versions are also available, just install
qbittorrent-noxinstead ofqbittorrentthey 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 likepython3-libtorrentpackage 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 commented on GitHub (Apr 28, 2020):
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 commented on GitHub (Oct 19, 2020):
@Kolcha
There seems to be a problem with the build.
@Kolcha commented on GitHub (Oct 19, 2020):
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 commented on GitHub (Oct 19, 2020):
@Kolcha
No, we set it to 3.16:
github.com/qbittorrent/qBittorrent@05c7796909/CMakeLists.txt (L1)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 commented on GitHub (Oct 19, 2020):
@FranciscoPombal , I'm talking about libtorrent:
github.com/arvidn/libtorrent@3d48e7d056/bindings/python/CMakeLists.txt (L1)this line is appeared in
github.com/arvidn/libtorrent@cfa5875d1athis is my main concern, I still use autotools build on linux for qBittorrent, only libtorrent is built using cmake
@FranciscoPombal commented on GitHub (Oct 19, 2020):
@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:
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 commented on GitHub (Oct 19, 2020):
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
it is planned, but I had not so much free time to rewrite qBittorrent Debian packaging scripts to cmake
@FranciscoPombal commented on GitHub (Oct 19, 2020):
@Kolcha
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 commented on GitHub (Oct 20, 2020):
@zero77 build is fixed now!
@zero77 commented on GitHub (Oct 20, 2020):
@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 commented on GitHub (Oct 20, 2020):
@zero77
This is an expected warning and the fix is self-explanatory. Be aware of https://github.com/qbittorrent/qBittorrent/issues/13519, though, you might also need to edit your config file to prevent the legacy directory location from being recreated at this time.
@zero77 commented on GitHub (Oct 20, 2020):
@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 commented on GitHub (Oct 20, 2020):
ugh... this is very strange... I'll check it later (today' evening)
@zero77 commented on GitHub (Oct 20, 2020):
No luck fixing it yet but, i have found:
https://github.com/qbittorrent/qBittorrent/wiki/Compilation:-Debian-and-Ubuntu#running-qbittorrent
@Kolcha commented on GitHub (Oct 20, 2020):
@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 commented on GitHub (Oct 20, 2020):
@Kolcha Thanks
@Kolcha commented on GitHub (Oct 21, 2020):
@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 commented on GitHub (Oct 22, 2020):
@Kolcha Thanks
@Kolcha commented on GitHub (Oct 26, 2020):
@zero77 finally, I reproduced exactly the same error message you reported on Ubuntu 20.04! and I found the reason… as I thought, the reason is libtorrent inconsistency, but the source of this is pretty strange - libtorrent from 'test' with latest stable version is considered newer than libtorrent from 'nightly' repo. so after adding 'nightly' repo without packages uninstall, only qbittorrent packages are updated (but not libtorrent!), and this leads to this error message.
just uninstalling
qbittorrent-noxandlibtorrent-rasterbar10packages (only libtorrent is enough, qbittorrent will be removed automatically) and installingqbittorrent-nox(orqbittorrent) again will fix that issue.apt policyalso shows this, see attached screenshot.I’ll fix this "version issue" somehow, but later. sorry for inconvenience, and thanks for reporting! now feel free to use 'nightly' builds.
@zero77 commented on GitHub (Oct 27, 2020):
@Kolcha Thank you for your help.
There is already a ubuntu nightly repository: https://launchpad.net/~qbittorrent-team/+archive/ubuntu/qbittorrent-unstable
Most of the distros listed here have out of date packages and no maintained repository available.
So supporting one of these would be help full.
https://repology.org/project/qbittorrent/versions
@guyarad commented on GitHub (Jan 9, 2021):
I'm very new to Raspberry PI. I have what seems to be Raspbian 10 installed, on Rasp-pi-4, which seems to be 32bit:
I followed these steps from here:
And it seemed to have worked just fine.
What am missing?
@Kolcha commented on GitHub (Jan 10, 2021):
I don't have any ARM-based devices, but it seems to be there is no stable Raspbian 10 64-bit yet... see
https://www.raspberrypi.org/forums/viewtopic.php?t=275370
and
https://www.raspberrypi.org/forums/viewtopic.php?t=292965
so, that's fine that you have 32-bit OS
@Kolcha commented on GitHub (Mar 18, 2021):
due to
github.com/qbittorrent/qBittorrent@f022458383builds for Debian 10 (and other distros based on it, like Raspbian) are not possible anymore. so, no more nightly builds will be provided for these systems.also, very likely I'll drop whole my repo at https://software.opensuse.org//download.html?project=home%3Anikoneko%3Aqbittorrent-nightly&package=qbittorrent
because I see no reasons to keep just for not stable Debian releases. but this slightly later, maybe in few months.
repo with stable releases https://software.opensuse.org//download.html?project=home%3Anikoneko%3Atest&package=qbittorrent for Debian will exist some longer time, but also I plan to drop it.
@Kolcha commented on GitHub (Apr 23, 2021):
since today qBittorrent nightly builds use libtorrent 2.0
https://software.opensuse.org//download.html?project=home%3Anikoneko%3Aqbittorrent-nightly&package=qbittorrent
no any migration process is required, everything works out of the box
moreover, everything is backward compatible with libtorrent 1.2, so even if you revert qBittorrent to lt-1.2-based, you will see all torrents as it was for lt-2.0-based qBittorrent
@Kolcha commented on GitHub (Jul 7, 2021):
@ted423 you are trying to add Ubuntu's ppa, what is not suitable for Debian, you should use links from my posts instead.
I provide these links below, to do not have you to search them in thread:
stable release: https://software.opensuse.org//download.html?project=home%3Anikoneko%3Atest&package=qbittorrent
nightly builds: https://software.opensuse.org//download.html?project=home%3Anikoneko%3Aqbittorrent-nightly&package=qbittorrent
to add any of this repos just follow instructions on that pages.
Note: regardless of only
qbittorrentpackage (aka GUI) is mentioned,qbittorrent-noxis also available (website just doesn't display it). you can find full list of available packages for Debian unstable (aka 'sid') hereupdate: now previous versions of qBittorrent are also available in the stable repo. so in case of any issues there is a possibility to revert to previous version. how to install a specific package version in case of few available versions, see this guide https://linoxide.com/install-specific-version-package-apt-get/
@ted423 commented on GitHub (Jul 7, 2021):
My mistake, I delete it
@Kolcha commented on GitHub (Aug 20, 2021):
Debian 11 was released.
corresponding qBittorrent packages in my repos will appear soon. the same links as were published previously in https://github.com/qbittorrent/qBittorrent/issues/12616#issuecomment-875368452 should be used.
from now stable (aka release) builds will be available for Debian 10 (buster), 11 (bullseye), testing and unstable,
while nightly will be available only for Debian 11 (bullseye), testing and unstable.
@GvY85 commented on GitHub (Sep 11, 2021):
Thank you for this. Have been using your stable repository for quite some time now on Debian 10 and now on Debian 11.
However, could you keep at least 1 previous version of the packages? There now is a problem witn 4.3.8 WebUI (see this post) and I would like to go back to 4.3.7 but I can only revert back to 4.2.5 from the official repositories or go wild and use beta 4.4.0 from the unstable repositories you provide.
@Kolcha commented on GitHub (Sep 11, 2021):
@GvY85 sorry, it looks like build server I use doesn't allow to keep several versions of the same package... it removes any previous version automatically... even file names are different (due to different versions, which are part of file name). I didn't found any options to control this behavior.
mentioned issue is very strange... don't have such issue since official 4.3.8 release... running it on my server since 2021-08-30, but using self-compiled slightly changed (just replaced some colors in WebUI) version of qbittorrent-nox running on Debian Unstable.
WebUI works fine when accessed from various devices/browsers, so working WebUI is not result of cached data:
qBittorrent was upgraded from 4.3.7 (again, slightly customized)
@GvY85 commented on GitHub (Sep 11, 2021):
Thanks for the reply. That is very wierd indeed. Any chance you still have a local (cache) copy of 4.3.7 somewhere or in the trash bin of the server?
I also did upgrade from 4.3.7 and since my torrentlist was empty I just started to notice it. Also more people seem to have the same proplem
@Kolcha commented on GitHub (Sep 11, 2021):
I don't build it locally, even don't have environment suitable for it. build server also doesn't have something like "trash bin", so there is no way to get previous package versions from it... service I use is free, so the absence of any packages archive may be the limitation just to keep much more projects.
@Kolcha commented on GitHub (Sep 11, 2021):
I found the way to keep few versions of the same package! I did some tricks and got it! but there is one drawback - old packages should be removed manually, but this is not a problem, I even update them manually when release happens.
@GvY85 now you can find qBittorrent 4.3.7 alongside with 4.3.8 in "stable" repo:
this will not affect any users which use 4.3.8. this just adds a possibility to revert to previous version.
any previous versions can be re-compiled on libtorrent (or any other dependency) change, so binary compatibility is guaranteed.
I will keep 2 previous versions.
@GvY85 commented on GitHub (Sep 11, 2021):
Thank you for this but now something wierd is happening:
I reverted to 4.3.7 (from your Debian 11 repository) but that did not solve it.
Then I restored a backup that was using 4.3.8 but from your Debian10 repository (http://download.opensuse.org/repositories/home:/nikoneko:/test/Debian_10 InRelease
) and that worked strangly enough.
I then updated APT sources to Debian 11 as they should be (http://download.opensuse.org/repositories/home:/nikoneko:/test/Debian_11 InRelease)
and it asked to update qbittorrent-nox for some reason (exact same version but still it asked for it) after an apt update so I updated to your Debian 11 version of 4.3.8 and now the WebUI is broken again.
Reverted back to my backup with 4.3.8 from Debian 10 repo and no problems.
Something wrong with the Debian 11 builds?
edit: it did not update anything else like libtorrent libraries when changing to Debian 11 repo.
It just wanted to update qbittorrent-nox:
qbittorrent-nox/unknown 4.3.8-0+1.1 amd64 [upgradable from: 4.3.8-0+1.1]@GvY85 commented on GitHub (Sep 13, 2021):
I wrote a bit more coherend bug report here: https://github.com/qbittorrent/qBittorrent/issues/15420#issuecomment-917982399
@GvY85 commented on GitHub (Oct 11, 2021):
Hi @Kolcha ,
I noticed the Debian 11 .deb's have been rebuild? Unfortinately the webui now does work but qbittorrent crashes when downloading: https://github.com/qbittorrent/qBittorrent/issues/15563
@Kolcha commented on GitHub (Oct 11, 2021):
Hi @GvY85 , nothing significant was changed, all sources are the same as they were... rebuild was caused by dependency change, I just dropped custom cmake what was used before, Debian 11 and above has new enough cmake in repos. such rebuilds also trigger automatically on any dependency update.
so, this is pretty strange, but I'll try to look into it.
also please install package with debug symbols (for example
qbittorrent-nox-dbgsym_4.3.8-0+1.1_amd64.deb), this may resolve addresses shown in logs into information useful for developers, or at least you can get such information by yourself usinggdb.but I almost sure that the issues you are experiencing are consequences of system upgrade and they will not appear on clean newly installed system... but I'll try (just for information, I'm using Debian unstable on 2 machines: my server and laptop)
@GvY85 commented on GitHub (Oct 12, 2021):
Hi, thanks for your reply.
I tried running it in gdb wih debug symbols and it does not crash. Perhaps something to do with the gdp version using default settings so they are not the same configuration.
I am a bit at a loss
@GvY85 commented on GitHub (Oct 12, 2021):
I have solved it by removing qbittorrent-nox and purging all dependencies and reinstalling them.
It was a environment issue after all. Thanks for the help
@Kolcha commented on GitHub (Nov 19, 2021):
Raspbian 11 builds were added for both cases (i.e. stable and nightly), packages will appear soon.
use the same links to add repos as published in https://github.com/qbittorrent/qBittorrent/issues/12616#issuecomment-875368452
current build status and list of available packages and distros can be viewed here:
for stable builds: https://build.opensuse.org/project/show/home:nikoneko:test
for nightly builds: https://build.opensuse.org/project/show/home:nikoneko:qbittorrent-nightly
@GvY85 commented on GitHub (Jan 7, 2022):
The links are still up to date right with 4.4.0. released?
@Kolcha commented on GitHub (Jan 7, 2022):
links will be the same, I'll update packages soon
apt-get updatewill notify you when packages become ready@GvY85 commented on GitHub (Jan 7, 2022):
Was monitoring the build process and I got them, working fine so far. Thanks for the work :)!
@Kolcha commented on GitHub (Jan 7, 2022):
4.4.0 packages are published and available for download, links are the same as in https://github.com/qbittorrent/qBittorrent/issues/12616#issuecomment-974482033, but there are some important notes are below.
packages for ARM architectures may appear with some significant delay, build servers used for them seems to be not so powerful as for x86 builds.
@Kolcha commented on GitHub (Jan 8, 2022):
small update: qBittorrent 4.4.0 was added into official Debian Unstable repository, so I disabled it in my repositories
@GvY85 commented on GitHub (Jan 16, 2022):
@Kolcha since yesterday the Testing repo (Stable build's) wants to update my current qBittorrent-nox4.4.0 but also removing libtorrent-rasterbar20 and replace it with libtorrent-rasterbar10 and thus breaking the installation.
Also, it seems at least once a day the packages get updated and the versions increases a minor digit, seemingly without reason?
edit: nvm, that is the official DEbian Testing that does not have rasterbar20 and wants to install rasterbar10...
Still, your packages seem to get updated often?
@Kolcha commented on GitHub (Jan 16, 2022):
seems that qBittorrent 4.4.0 was added to Debian Testing too... not only to Debian Unstable
and it is based on libtorrent 1.2.14, libtorrent 2.0.x is still unavailable even in Unstable (looks like only in experimental such package exists). moreover, looks like libtorrent package has no maintainer... so the future of it in Debian is a big question...
official packages took priority on upgrade due to slightly different version number '-2' at the end in official package version number, and '-0' (doesn't matter what goes after it) in my. unfortunately this '-0' can't be changed, build server just doesn't support this, and this '-0' is hardcoded into it's internal scripts, see
github.com/openSUSE/obs-service-set_version@b85ab00aab/set_version (L451)very likely that this build server restriction exists because server is OpenSUSE build server, and its primary task is build .rpm packages. and it lack of good support of .deb. but this is unique service I found that even can produce packages for Debian and provides repository out of the box.
for now I suggest to use official Debian qBittorrent 4.4.0 package, I'll disable my own for Debian Testing too (like I did for Debian Unstable). with next qBittorrent release I'll re-enable it.
as alternative solution, I can add something after version, like I added '+p' (full package version looks like '4.4.0+p-0+4.2') for my personal patched qBittorrent version used on my server. this will be greater than the version officially available.
from my point of view there is no reason to provide a custom repository if package in official one has the same version. but in case of qBittorrent libtorrent 2.0 may be a reason.
please let me know your thoughts.
@Kolcha commented on GitHub (Jan 16, 2022):
regarding version number changes, last digits after '+' in version number are "build number". first is incremented when I made some change in source files (only required for packaging) and thereby triggered a build. consider it as package improvement. the second one (after dot '.') is incremented by automatic build due to some dependency update (libc6, openssl, etc.) and this is not controlled by me. consider it like just a rebuilt to avoid potential compatibility issues.
@GvY85 commented on GitHub (Jan 22, 2022):
I would prefer the 4.4.0 based on Libtorrent2.x so if you could keep your version enabled for Testing that would be great.
@Kolcha commented on GitHub (Jan 22, 2022):
@GvY85 , my libtorrent 2.0 based qBittorrent builds were enabled for Debian Testing and Debian Unstable.
I just added '+0' to package version and this is sufficient to override system package. for example package version from my repository
4.4.0+0-0+3.4is considered newer than4.4.0-2provided from official Debian repositories.so, now you can just run
apt updateand you will get my packages, tested on Debian Unstable@GvY85 commented on GitHub (Feb 13, 2022):
Hi, it seems that (at least) in your (Stable) DebianTesting repo there is a problem with libtorrent:
followed by:
@Kolcha commented on GitHub (Feb 13, 2022):
@GvY85 , sorry for inconvenience, libtorrent package was renamed to follow official package name
libtorrent 2.0 was officially packaged for Debian unstable https://packages.debian.org/sid/libtorrent-rasterbar-dev , and now even was migrated even to testing https://tracker.debian.org/pkg/libtorrent-rasterbar . seems, someone maintains this package.
to get everything work again, just remove my
libtorrent-rasterbar20(qbittorrent-noxwill be removed too) and then installqbittorrent-noxagain.@GvY85 commented on GitHub (Feb 14, 2022):
Thanks.
Solved it while keeping qbittorrent-nox settings intact
@Kolcha commented on GitHub (Mar 5, 2022):
Qt6 is appeared in official Debian Testing and Unstable repos https://packages.debian.org/bookworm/qt6-base-dev
so, I decided to build qBittorrent packages based on it (separate packages, not replacing already existing Qt5-based)
for now I added Qt6-based build only for "stable" repo: https://software.opensuse.org//download.html?project=home%3Anikoneko%3Atest&package=qbittorrent-qt6
both GUI and "-nox" packages are available.
to start using Qt6-based qBittorrent, just install
qbittorrent-qt6orqbittorrent-nox-qt6package. Qt5-based package you may have already will be uninstalled automatically.Qt6-based packages are available only for Debian Testing and Unstable: https://build.opensuse.org/package/show/home:nikoneko:test/qbittorrent-qt6
"nightly" repo doesn't have Qt6-based builds yet.
@GvY85 commented on GitHub (Sep 2, 2022):
Hi @Kolcha, any progress on https://github.com/qbittorrent/qBittorrent/releases/tag/release-4.4.5?
edit: it works as always, thanks for the effort!
@Kolcha commented on GitHub (Sep 2, 2022):
sorry, now I'm not at home and have no computer with me. I'll back only this Sunday in the evening. so, please wait.
Sent from Mail.ru app for Android Friday, 02 September 2022, 00:03PM +02:00 from GvY85 @.*** :
@Kolcha commented on GitHub (Sep 5, 2022):
"stable" repo doesn't provide Qt5-based builds for Debian Testing and Unstable anymore, official repositories are updated quit quick and provide up-to-date
libtorrent-rasterbarandqbittorrentpackages."nightly" repo now also contains Qt6-based builds (for Debian Testing and Unstable only). "nightly" builds are not really "nightly" - they are updated in ~1 week.
@WolfganP commented on GitHub (Oct 1, 2022):
FOA thanks a lot for your nightly builds. Is there any chance you can create another recipe for builds based on libtorrent 1.2_RC as per the latest changes on official releases?
Thanks in advance.
@Kolcha commented on GitHub (Oct 2, 2022):
@WolfganP builds based on libtorrent 1.2 were added! can be installed from there (available for Debian Testing and Unstable), both Qt5 and Qt6 versions are available
@WolfganP commented on GitHub (Oct 2, 2022):
Excellent. Thanks a lot @Kolcha! Any chances the raspian11 / armhf versions can be added as in nightly / test? I also noticed that libtorrent is not included in the folder as in nightly & test, did you discard it on purpose or just relying on any specific version?
Thanks again!
@Kolcha commented on GitHub (Oct 2, 2022):
release builds (aka my "test" repository) are already available for Raspbian 11 (both armhf and aarch64), but they are based on libtorrent 2.0
this is my black magic :) if you even slightly familiar with C/C++ world, you may know about shared and static libraries. shared libraries are very common in Linux world (and libtorrent is one of them), static are mostly used as "internal" libraries for projects. for this particular case I built libtorrent as static library, packaged it with different package name and NOT published it (but used only for building qBittorrent package) just to overcome the "limit" that libtorrent package in default Linux repositories is newer and I didn't want to override something from standard repo. so, this is expected. also you may notice much bigger executable size comparing to release or current nightly builds, this is the consequence of static library usage (but libtorrent is not required at all in such case!)
I'll add Debian/Raasbian 11 builds this evening. please wait. it requires some work.
@Kolcha commented on GitHub (Oct 2, 2022):
@WolfganP repositories for Debian/Raspbian 11 were added. packages will be available in ~1 hour. unfortunately arm builds are too slow (especially armv7), very likely build server uses real hardware for it instead of emulation. the link is the same.
@WolfganP commented on GitHub (Oct 2, 2022):
Just to confirm, I installed the raspbian armhf -nox build with the static libtorrent and works like a charm. Thanks a lot for adding it!
@WolfganP commented on GitHub (Oct 3, 2022):
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 commented on GitHub (Oct 3, 2022):
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 commented on GitHub (Dec 22, 2022):
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 commented on GitHub (Dec 22, 2022):
@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 commented on GitHub (Dec 23, 2022):
@Kolcha working perfectly now. Thx a lot for the prompt fix!
@GvY85 commented on GitHub (Feb 6, 2023):
Hi, something seems wrong with your repo keys:
@Kolcha commented on GitHub (Feb 6, 2023):
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 @.*** :
@GvY85 commented on GitHub (Feb 6, 2023):
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/nullBut I get the same error after
apt update@Kolcha commented on GitHub (Feb 6, 2023):
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 commented on GitHub (Feb 6, 2023):
seems new keys are already available, and can be downloaded manually from here:
at least for "test" repo this key is different comparing to Release.key downloaded from repo.
@GvY85 commented on GitHub (Feb 6, 2023):
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/nullfor Stable works indeed@GvY85 commented on GitHub (Mar 24, 2023):
@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 commented on GitHub (Mar 25, 2023):
@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 commented on GitHub (Apr 18, 2023):
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 commented on GitHub (Apr 18, 2023):
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 commented on GitHub (Apr 18, 2023):
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 commented on GitHub (Jun 22, 2023):
Hi, the
Testingrepo withqbittorrent-nox-qt6does not work anymore now thatBookwormis out. Package is held back because it needslibtorrent-rasterbar2.0_2.0.9. That one is in theDebian_11repo but when you add that one it cannot install becauselibssl1.?is not available.@Kolcha commented on GitHub (Jun 22, 2023):
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 commented on GitHub (Jun 26, 2023):
Work a charm! Thanks
@Kolcha commented on GitHub (Aug 7, 2023):
qBittorrent devs raised minimum required Qt version to Qt 6.5, see
github.com/qbittorrent/qBittorrent@a0fa1709d5this 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 commented on GitHub (Aug 7, 2023):
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+).
masterhas 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 commented on GitHub (Sep 8, 2023):
good news everyone! based on ppa mentioned in this discussion https://github.com/qbittorrent/qBittorrent/discussions/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:
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 commented on GitHub (Sep 8, 2023):
Thanks a lot @Kolcha for keeping these builds alive
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 commented on GitHub (Sep 8, 2023):
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 commented on GitHub (Sep 8, 2023):
Much appreciated @Kolcha , thanks a lot.
@Kolcha commented on GitHub (Sep 8, 2023):
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 commented on GitHub (Sep 9, 2023):
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!
@clartek commented on GitHub (Nov 3, 2024):
Is Qbit version 5 coming any time soon?
@Kolcha commented on GitHub (Nov 4, 2024):
unfortunately, Debian 12 has unsuitable Qt 6 version and it is impossible to build qBittorrent with Qt 5 anymore. building static Qt version and building qBittorrent with it is possible, but better to do not do that. upgrading Qt from custom repository is even worse option.
so, the only option for now is building everything from sources - https://gist.github.com/Kolcha/642bceeb3724cc6d785a12dc0206b802
Debian testing has the latest qBittorrent version in the official repos, so no need for custom repos. so, upgrading to Debian testing may be an option too.
one more thing to consider: if I upgrade packages somehow, there will be no previous versions, and very likely Debian 11 will be dropped, what may be undesirable. so, repos in the current state with the latest 4.x version are more valuable, as Debian repos contain too old versions.
but will see, maybe I'll find some solution for everything, but it will happen not earlier than in two weeks, I'm too busy these days and not looking at any personal stuff at all.
Sent from Mail app for Android Monday, 04 November 2024, 02:27AM +01:00 from Josh @.*** :
@WolfganP commented on GitHub (Nov 4, 2024):
Thanks for the update!
@Kolcha commented on GitHub (Nov 27, 2024):
I pushed new qBittorrent (5.0.2) packages to my Debian 12 repo. expect upgrade when you run
apt update && apt upgradenext time. upgrade should happen doesn't regardless of installed version (Qt5 or Qt6, what was with "-qt6" suffix). qBittorent itself handles Qt version change at least good enough, you will need only to adjust some UI aspects if you are using GUI version.new packages are also available for ARM architectures (including Raspbian 12 distro), they may appear a bit later.
P.S> if something goes wrong, old package versions (4.6.7, both Qt5 and Qt6) are still there, and they will be there for a pretty long time (maybe while Debian 11 is "considered supported")
Debian 11 is unlikely will be supported, it is too old (it should still be possible to build binary, but it is too problematic).
for Debian testing or unstable just use the official repos, qBittorrent is up-to-date there.
P.P.S> I'm not using Debian (or any other Debian-based OS) for ~1 year now, so packages are untested, but they should work. let me know if something is wrong.
@Kolcha commented on GitHub (Nov 27, 2024):
one more note: nightly builds (updated approximately once per week) are available only for Debian Testing and Unstable and only for amd64 (x86_64) architecture
@clartek commented on GitHub (Dec 3, 2024):
Thanks for your work on this! I was having a lot of trouble with version 5.0.2 from the Debian Testing repo, so I'm gonna wait this one out and let it cook. 4.6.7 is working just fine for me.
@luzpaz commented on GitHub (Feb 4, 2025):
Does this ticket remain open to track Debian nightly/weekly builds ? Or can it be closed?
@zero77 commented on GitHub (Feb 19, 2025):
@luzpaz
It's probably best to leave this open as @Kolcha is the only one supporting Debian nightly builds and can use this to share or respond to comments.
Unless there is plans for official Debian nightly builds to be released
@xavier2k6 commented on GitHub (May 24, 2025):
ANNOUNCEMENT!
For anybody coming across this "Feature Request" & would like/love to see a potential implementation in the future!
Here are some options available to you:
Please select/click the 👍 &/or ❤
reactionsin the original/opening post of this ticket.Please feel free (If you have the "skillset") to create a "Pull Request" implementing what's being requested in this ticket.
(new/existing contributors/developers are always welcome)
DO:
DO NOT:
(These will be disregarded/hidden as "spam/abuse/off-topic" etc. as they don't provide anything constructive.)
@kambala-decapitator commented on GitHub (Oct 18, 2025):
on debian 13 I'm getting apt warning about the key used:
also, using the new
.sourcesformat is recommended:this is what
apt modernize-sourcesproduced:I've also added path to the key to
Signed-Bymanually (and moved the key to/etc/apt/keyringswhich seems the recommended place now).@Kolcha commented on GitHub (Oct 22, 2025):
all the stuff mentioned above is not under my control. keys expire after some time and automatically renewed, users need to re-download new keys manually.
sources list "modernization" is even more complex topic - this is only for new Debian (and few recent Ubuntu releases), it definitely will take time to apply and "propagate" the change. I don't think that scripts that generate these "add repo" instructions will be updated soon.