Package Details: qbittorrent-git 3.3.10.r801.g33ada71e4-2

Git Clone URL: https://aur.archlinux.org/qbittorrent-git.git (read-only)
Package Base: qbittorrent-git
Description: A bittorrent client powered by C++, Qt5 and the good libtorrent library (development version)
Upstream URL: http://www.qbittorrent.org/
Keywords: qt torrent
Licenses: GPL, custom
Conflicts: qbittorrent
Provides: qbittorrent
Submitter: Sevenseven
Maintainer: carstene1ns (Eschwartz)
Last Packager: Eschwartz
Votes: 35
Popularity: 1.959173
First Submitted: 2011-06-28 01:40
Last Updated: 2017-01-12 22:19

Dependencies (6)

Required by (2)

Sources (1)

Latest Comments

TrakTrakTrugui commented on 2017-01-30 01:58

Not working for me, app don't start in anyway.

Getting:
QSystemTrayIcon::setVisible: No Icon set

tuxayo commented on 2017-01-18 14:50

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: https://github.com/qbittorrent/qBittorrent/issues/6239

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 :)

Eschwartz commented on 2017-01-15 02:01

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

@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.

desaparecido commented on 2016-12-26 07:54

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

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

If anyone is having issues, it seems that upstream support for libtorrent-rasterbar 1.1.x is not complete. See https://github.com/qbittorrent/qBittorrent/issues/6132

@carstene1ns Should it require libtorrent-rasterbar < 1.1.x for now?

uncle commented on 2016-06-24 00:00

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:
https://github.com/qbittorrent/qBittorrent/issues/5073
... caused by a bug in Qt5:
https://bugreports.qt.io/browse/QTBUG-52633
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

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

@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

@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

Please update, there's an 3.3.5.

Eschwartz commented on 2016-01-13 03:55

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.

carstene1ns commented on 2015-12-26 09:41

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

@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

@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

@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]: https://aur.archlinux.org/cgit/aur.git/plain/get_version.pri?h=qbittorrent-qt5-git
[2]: https://aur.archlinux.org/cgit/aur.git/plain/PKGBUILD?h=qbittorrent-qt5-git

carstene1ns commented on 2015-12-21 21:09

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

[1]: https://aur.archlinux.org/packages/qbittorrent-qt5-git/

uncle commented on 2015-12-20 05:25

qBittorrent now uses Qt5 by default: https://github.com/qbittorrent/qBittorrent/commit/6e090286823a2d222f8effd3cf1bd2176f811e99 The issue you mentioned earlier, which was caused by Qt5 has been closed: https://github.com/qbittorrent/qBittorrent/issues/2835 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

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

@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]: https://github.com/qbittorrent/qBittorrent/issues/2835
[2]: https://aur.archlinux.org/packages/qbittorrent-qt5-git/

Eschwartz commented on 2015-05-31 04:45

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

Eschwartz commented on 2015-05-31 04:43



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

Eschwartz commented on 2015-05-31 04:31

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......


Also, the package description now refers to Qt5, but you switched it to use qt4 again. The qBittorrent team just went with "Qt". ;)

carstene1ns commented on 2015-05-25 23:09

Package adopted and (hopefully) fixed.

yurikoles commented on 2015-05-06 23:38

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

Vaporeon commented on 2015-04-06 06:23

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

mrbit commented on 2012-08-30 08:31

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

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

hello
pls save PKGBUILD use UTF-8
now is dos

Sevenseven commented on 2012-08-16 18:12

Updated. Thank you, Blender.

Blender commented on 2012-08-11 05:37

Repo moved to https://github.com/qbittorrent/qBittorrent

Blender commented on 2012-07-22 22:52

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

moved to github