Package Details: qbittorrent-nox-git 1:4.5.0alpha1.r320.gde8377ab5-1

Git Clone URL: (read-only, click to copy)
Package Base: qbittorrent-git
Description: An advanced BitTorrent client programmed in C++, based on Qt toolkit and libtorrent-rasterbar (git version)
Upstream URL:
Keywords: bittorrent qt torrent
Licenses: GPL, custom
Conflicts: qbittorrent-nox
Provides: qbittorrent-nox
Submitter: Sevenseven
Maintainer: yurikoles
Last Packager: yurikoles
Votes: 50
Popularity: 0.45
First Submitted: 2011-06-28 01:40 (UTC)
Last Updated: 2022-04-27 01:56 (UTC)

Required by (7)

Sources (1)

Latest Comments

yurikoles commented on 2022-04-27 01:56 (UTC)

Thanks MarsSeed, I applied your suggestion.

MarsSeed commented on 2022-03-25 22:34 (UTC) (edited on 2022-04-23 12:19 (UTC) by MarsSeed)

The version string is wrong.

For Pacman, 4.5.0alpha1 < 4.5.0 < 4.5.0.alpha1 < 1:4.5.0alpha1.

Please kindly fix the version string creation (change 4.5.0.alpha1 to 4.5.0alpha1), and add an epoch=1 variable to the beginning section of the PKGBUILD to "reset" the version ordering.

This fix is needed so that whenever v4.5.0 stable gets released, Pacman will see pkgver=4.5.0[...] as newer version than pkgver=4.5.0.alpha1[...].

Otherwise Pacman won't update the alpha package to the stable version once that is out.

milkii commented on 2021-01-07 12:35 (UTC)

Getting this at the mo;

configure: error: Package requirements (libtorrent-rasterbar >= 1.2.11) were not met:

Package dependency requirement 'libtorrent-rasterbar >= 1.2.11' could not be satisfied.
Package 'libtorrent-rasterbar' has version '1.2.10', required version is '>= 1.2.11'

katt commented on 2020-08-23 10:31 (UTC)

If anyone is struggling to run this with qt5-base-headless, you need shared-mime-info, posting this partly in case I encounter this ever again.

eschwartz commented on 2017-09-24 17:59 (UTC)

This is true... I generally publish updated pkgver/pkgrel for soname rebuilds (although this time around I was offline over the weekend), but this is hardly required as an AUR standard. The user is expected to know enough to rebuild their AUR packages after events like this.

tuxayo commented on 2017-09-23 20:04 (UTC)

I also had to rebuild libtorrent-rasterbar-1_0-git before rebuilding qbittorrent-git

tuxayo commented on 2017-09-23 19:09 (UTC)

After the update of boost (1.64.0-4 -> 1.65.1-1) the package must be rebuilt.

eschwartz commented on 2017-09-07 22:35 (UTC)

No, you install base-devel as all users are required to do before using makepkg. I am not responsible for working around the fact that you didn't read the basic instructions for using the AUR.

fshp commented on 2017-09-07 20:56 (UTC)

Add pkg-config to make deps.

servimo commented on 2017-07-17 21:42 (UTC)

O.K., now after the update, it worked. Sorry. Thanks for the patience!

eschwartz commented on 2017-07-17 16:44 (UTC)

I already told you, fix your mirrors. How many times do I have to tell you, Arch Linux moved libtorrent-rasterbar v1.1.4 to [extra] on Friday, 3 days ago? If your mirror is still telling you that libtorrent-rasterbar is at 1.1.3-4, then it hasn't synced in 3 days and you should probably stop using it. Also, unless you forgot to include the epoch something weird is going on. If you still don't believe that I am telling the truth, see the link above for the libtorrent-rasterbar dependency on this page. Heck, I'll even give you an extra copy of the link: Notice the "Version: 1:1.1.4-1" part, where it clearly says that v1.1.4 is the current version. This strongly implies that v1.1.4 is in fact in the repositories.

servimo commented on 2017-07-17 15:44 (UTC) (edited on 2017-07-17 15:56 (UTC) by servimo)

I have installed libtorrent-rasterbar 1.1.3-4 and is still not working the compile, same results libtorrent-rasterbar 1.1.4 is not in the repositories

eschwartz commented on 2017-07-16 14:02 (UTC)

servimo, I just updated this package last night to remove the patch that would work around that error... because libtorrent-rasterbar 1.1.4 is now in [extra] and renders it unnecessary. Did you try doing a `pacman -Syu` before just assuming there was something wrong with this package? If so, your mirrorlist contains outdated mirrors, and you should consider updating your mirrorlist, then updating your system.

servimo commented on 2017-07-16 13:46 (UTC)

In file included from /usr/include/libtorrent/torrent_info.hpp:47:0, from base/bittorrent/torrentinfo.h:34, from base/bittorrent/session.h:58, from base/bittorrent/session.cpp:30: /usr/include/libtorrent/bdecode.hpp:294:14: note: in call to ‘std::__cxx11::string libtorrent::bdecode_node::list_string_value_at(int, const char*)’ std::string list_string_value_at(int i ^~~~~~~~~~~~~~~~~~~~ make[1]: *** [Makefile:3267: session.o] Error 1 make[1]: Leaving directory '/tmp/yaourt-tmp-sergio/aur-qbittorrent-git/src/qbittorrent/src' make: *** [Makefile:45: sub-src-make_first] Error 2 ==> ERRO: Uma falha ocorreu em build(). Abortando... ==> ERRO: Makepkg não conseguiu compilar qbittorrent-git. ==> Reiniciar a compilação de qbittorrent-git ? [s/N]

Sevenseven commented on 2017-05-12 15:06 (UTC)

@jdawg updated.

jdawg commented on 2017-05-11 23:49 (UTC)

I am unable to build this package: patching file src/base/bittorrent/session.cpp Hunk #1 succeeded at 43 (offset -2 lines). Hunk #2 succeeded at 187 (offset -10 lines). Hunk #3 FAILED at 367. 1 out of 3 hunks FAILED -- saving rejects to file src/base/bittorrent/session.cpp.rej

eschwartz commented on 2017-03-12 07:40 (UTC)

@Saren, The reverted commit in prepare() no longer reverted cleanly, this is now fixed. :)

Saren commented on 2017-03-11 14:57 (UTC)

For anyone who cannot build this, source=("${pkgname%-*}::git+")

TrakTrakTrugui commented on 2017-01-30 01:58 (UTC)

Not working for me, app don't start in anyway. Getting: QSystemTrayIcon::setVisible: No Icon set

tuxayo commented on 2017-01-18 14:50 (UTC)

Eschwartz, The quantity of issues and criticity (data corruptions) is high enough so at least one upstream dev is considering forbidding(← I'm not satisfied with this word, I'm not a native speaker and can't find better for now) to build against libtorrent 1.1.x for now. I've asked clarification and a broader discussion about that possibility: Anyway, while I don't think that your strategy is the best, it's still good because it creates more incentive to fix the issues and most of all, lead to more data about the underlying causes which will helped fixing them. Thanks for your work as a package maintainer :)

Sevenseven commented on 2017-01-15 09:18 (UTC)


eschwartz commented on 2017-01-15 02:01 (UTC)

tuxayo, I understood that as one of your meanings in the first place. ;) "Anyway, nothing is stopping users from replacing libtorrent-rasterbar on their systems, with the alternative branches packaged in the AUR." I still do not see why this package should *mandate* the 1.0.x branch, when that should be a user choice (to opt for the stable libtorrent-rasterbar with bleeding-edge qbittorrent). So I am not going to change it.

tuxayo commented on 2017-01-14 20:08 (UTC)

@Eschwartz @desaparecido > Arch Linux doesn't support partial updates, so it makes no sense to tell people to downgrade, and requiring an old version just to make updates abort is kind of silly too. That's not what I proposed. Sorry for being vague. The proposal is to use the "libtorrent-rasterbar-1_0-git" AUR package.

diggit commented on 2017-01-10 22:49 (UTC)

Does not build with libtorrent 1.1. Arch is using patch to build it for community repo, which seems to work.

desaparecido commented on 2016-12-26 07:54 (UTC)

I'm agree with @Eschwartz, it's better to play with libtorrent-rasterbar-git package, all builds fine with it, and if we (like arch users) are choice a git version, usually we take the bleeding-edge package sure, but bleeding-edge bugs and upstream's issues;

eschwartz commented on 2016-12-25 22:13 (UTC) (edited on 2016-12-25 22:19 (UTC) by eschwartz)

Arch Linux doesn't support partial updates, so it makes no sense to tell people to downgrade, and requiring an old version just to make updates abort is kind of silly too. Do those specific issues occur on the released versions of qbittorrent (they had better, since the current git HEAD is identical to their release tag except for the changelog/version codes)? Maybe you should suggest to the Arch maintainers that they should revert to a previous libtorrent-rasterbar release because qbittorrent doesn't wish to fix bugs against liborrent-rasterbar 1.1.x ... Anyway, nothing is stopping users from replacing libtorrent-rasterbar on their systems, with the alternative branches packaged in the AUR. ... For the one issue where qbittorrent upstream refused to provide appropriate ifdefs when grabbing a new feature in 1.0.x (and in the git HEAD for 1.1.x), I have reverted the commit in the PKGBUILD. As always, report bugs upstream, they should want to fix the bugs regardless since they will *eventually* hit them once they officially support libtorrent-rasterbar 1.1.x Or from the sound of it, maybe report it to libtorrent-rasterbar as a regression instead.

tuxayo commented on 2016-12-25 21:43 (UTC) (edited on 2016-12-25 21:44 (UTC) by tuxayo)

If anyone is having issues, it seems that upstream support for libtorrent-rasterbar 1.1.x is not complete. See @carstene1ns Should it require libtorrent-rasterbar < 1.1.x for now?

uncle commented on 2016-06-24 00:00 (UTC)

A solution to a Qbittorrent bug I was having problems with: If your log is flooded with "Network configuration has changed" messages, this is a known bug in qBittorrent: ... caused by a bug in Qt5: This problem can be remedied by building with Qt4. First make sure you have Qt4 installed ;-) then edit the PKGBUILD before building, and change line 34 (omitting quotation marks) from: " ./configure --prefix=/usr" to " ./configure --prefix=/usr --with-qt4"

uncle commented on 2016-06-23 23:55 (UTC)

Advice for beginners: To automatically update the git packages on your system, run yaourt with the "--devel" flag. If you want to skip all the prompts asking you to manually approve each step, you can also add the "--noconfirm" flag, for example: yaourt -Syua --devel --noconfirm

eschwartz commented on 2016-06-22 13:09 (UTC)

@ilyamodder, For future notice the comments are the wrong place to leave out-of-date notifications. That is why a dedicated out-of-date flag exists. As desaparecido said, this is a git package, so merely being out of date is not an excuse to flag it. Note that some maintainers will bump the pkgver as a courtesy notification that a new upstream release is available... however this is at the maintainer's discretion.

desaparecido commented on 2016-06-22 06:44 (UTC)

@ilyamodder when you have a git package, to update, you only need to rebuilt it (except if changes in upstream force to change PKGBUILD). I successfully build with this commit: qbittorrent-git-3.3.5.r602.gdbd079d-1 so 3.3.5 like you say.

ilyamodder commented on 2016-06-22 00:17 (UTC)

Please update, there's an 3.3.5.

eschwartz commented on 2016-01-13 03:55 (UTC)

Well, I *thought* the v3_3_x branch was "stable" development vs. alpha, but just looking at the history (there is none, it is stuck at the tag) I am no longer sure that is what it is for.

Sevenseven commented on 2016-01-10 16:07 (UTC)

Ty, updated.

3psus commented on 2016-01-10 04:30 (UTC) (edited on 2016-01-10 06:20 (UTC) by 3psus)

I am getting this error during build: "sh: lrelease-qt5: command not found" ls /usr/bin gives me lrelease and lrelease-qt4. Should lrelease-qt5 also be there? I'm a little confused... Edit: Builds well with qt4. Also, I have successfully built after installing qt5-tools. Maybe add it to the dependencies list so that we have lrelease-qt5? Edit2: Also, --with-qt5 should be removed from PKGBUILD as qt5 is now the default option. --with-qt5 results in a warning message "unrecognised option". Ref:

carstene1ns commented on 2015-12-26 09:41 (UTC)

What about having this package updated to QT5, but otherwise keep on using the "stable" branch approach and renaming 'qbittorrent-qt5-git' to 'qbittorrent-unstable-git' keeping updates from the master branch?

AlfredoRamos commented on 2015-12-22 00:31 (UTC)

@uncle Yes, currently it gives the alpha version, but not just alphas, betas and RCs as well. So I don't think naming it *-alpha would be the best way as it won't be consistent. I think I answered to myself: It uses other branches than master to get the latest "stable" version. I don't know how I feel about that, I like to have the latest versions of my apps even if they're a little unstable (with no critical issues), I mean, that's one of the reasons why I switched to Arch :P I can still build my own version, so no worries.

uncle commented on 2015-12-21 23:36 (UTC)

@AlfredoRamos building from master branch gives you the alpha version (for example: 3.4.0), whereas using branch v3_3_x will give you the development version (for example: 3.3.1) of the most recent release, which is more stable than an alpha release. An idea that occurs to me would be for you to change the name of your package to something like "qbittorrent-alpha-git".

AlfredoRamos commented on 2015-12-21 22:23 (UTC)

@carstene1ns Sure, but I have a question: why you're using other branch than master? I've been using the master branch in the qbittorrent-qt5-git package since I adopted (back in AUR3) and I haven't had any critical issue. In any case, can you keep using the get_version.pri[1] file and (at least something similar) in the pkgver()[2] function? I like to know which version I'm using, the version we get with git describe and the one in the qBittorrent/version.pri are different, that small file I made gets the actual version. [1]: [2]:

carstene1ns commented on 2015-12-21 21:09 (UTC)

Considering my comment from 2015-05-31 I think we should merge qbittorrent-qt5-git[1] into this package now. [1]:

uncle commented on 2015-12-20 05:25 (UTC)

qBittorrent now uses Qt5 by default: The issue you mentioned earlier, which was caused by Qt5 has been closed: Also, the most recent branch is "v3_3_x", this package is still on "v3_2_x".

eschwartz commented on 2015-06-02 02:01 (UTC)

Thanks for the fix. :) BTW -- I didn't know either, until I googled and read the manpages obsessively trying to fix this nagging cosmetic issue. :D As for the protocol used -- maybe there should be some sort of guideline (hah!)... anyway, it was just a little funny. Personally I wouldn't care, except that it cost me almost a whole 60 seconds of my life never to be recovered to change to my yaourt $develsrcdir and update the remote url before I could build it.

carstene1ns commented on 2015-05-31 09:08 (UTC)

@Eschwartz: Yes, I had updated this PKGBUILD to use qt5, but noticed then that there is a bug[1], that made the qbittorrent team revert to use qt4 by default. We also have a qbittorrent-qt5-git[2] package in the AUR, so I changed it to use qt4 again, but forgot to update the description... :) I wanted to contain the used version in the description so users can easily find it (also regarding [2]). If the team decides to switch to qt5 again, this package should use it and [2] should be removed (and a new package qbittorent-qt4-git could be added, if needed). I agree that the revision count is better with your change, I did not know that one could specify a tag to get only commits since then. The downside you mention is valid, however it will be gone once the next release is made. Considering I only introduced this change 5 days ago and the (lack of) popularity of this package, I think it does not really matter to change it now. It is true that cloning with git:// url works, but it uses a port (9418) that may be blocked by company firewalls, proxies or whatever. Using the https:// protocol has the advantage to get through them. [1]: [2]:

eschwartz commented on 2015-05-31 04:45 (UTC)

The current workaround for git describe counts every commit since forever, but of course to properly emulate describe, it would be nice to only list #commits since the version tag. If I change the line: _rev=$(git rev-list --count HEAD) to: _rev=$(git rev-list --count release-${_tag}..HEAD) then I get version 3.2.0.r17.2c1d76c-1 instead of version 3.2.0.r5793.2c1d76c-1, which I much prefer. The downside would be that the package goes _down_ 5776 versions for anyone else who has already installed it...... P.S. the package description now refers to Qt5, but you switched it to use qt4 again. The qBittorrent team just went with "Qt". ;) P.P.S. cloning works with git:// as well. :p

carstene1ns commented on 2015-05-25 23:09 (UTC)

Package adopted and (hopefully) fixed.

yurikoles commented on 2015-05-06 23:38 (UTC)

please specify that now qBittorrent requires libtorrent-rasterbar >= 1.0

Vaporeon commented on 2015-04-06 06:23 (UTC)

Building with QT5 is now default so the dependencies should be changed.

jnbek commented on 2013-03-31 04:36 (UTC)

why is qt4 a dep, if this is a nogui pkg? ;-)

mrbit commented on 2012-08-30 08:31 (UTC)

torrentcontentmodel.cpp:35:39: fatal error: torrentcontentmodelFolder.h: File o directory non esistente compilation terminated. make[1]: *** [torrentcontentmodel.o] Errore 1

mutoso commented on 2012-08-23 01:58 (UTC)

For those of you using yaourt to install qbittorrent-git, until the PKGBUILD is converted from DOS format, you can run "yaourt" as "EDITOR=dos2unix yaourt", then say yes to editing the PKGBUILD and it should work.

hepha commented on 2012-08-20 15:23 (UTC)

hello pls save PKGBUILD use UTF-8 now is dos

Sevenseven commented on 2012-08-16 18:12 (UTC)

Updated. Thank you, Blender.

commented on 2012-08-11 05:37 (UTC)

Repo moved to

commented on 2012-07-22 22:52 (UTC)

Can you change the "git clone" to "git clone --depth=1" and change the second "git clone" to "cp -r"? You don't need to clone the *entire* repository because you're only using the latest revision of the code. Doing this speeds up downloading the source code by quite a lot.

amirs commented on 2012-02-20 04:55 (UTC)

moved to github