Arch Linux User Repository

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

Does not build with libtorrent 1.1. Arch is using patch to build it for community repo, which seems to work. https://git.archlinux.org/svntogit/community.git/tree/trunk/qbittorrent-libtorrent-1.1.1.patch?h=packages/qbittorrent

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;

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.

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?

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"

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

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

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

Please update, there's an 3.3.5.