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: 34
Popularity: 2.464383
First Submitted: 2011-06-28 01:40
Last Updated: 2017-01-12 22:19

Dependencies (6)

Required by (2)

Sources (1)

Latest Comments

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.

All comments