the configure script for the next
release?
Thanks,
--
Cristian Greco
GPG key ID: 0xCF4D32E4
--
Christophe DUMEZ
qBittorrent author
| 2012-03-12 02:11:39 +0200 (Mon, 12 Mar 2012) | 1 line
reverted a potential ABI breaking change in 0.15.10
---
Kr,
Chris.
On Mar 18, 2012, at 4:21 PM, Cristian Greco wrote:
On Sun, 18 Mar 2012 14:02:17 +0200
Christophe Dumez dch...@gmail.com wrote:
crego, this hardly seems like a solution
I've been getting a lot of similar reports from Debian users over the last 2
days, this cannot be a coincidence:
https://bugs.launchpad.net/bugs/958693
https://bugs.launchpad.net/bugs/958659
https://bugs.launchpad.net/bugs/958484
https://bugs.launchpad.net/bugs/958184
Kr,
--
To UNSUBSCRIBE,
Hi,
This is a typical issue when qBittorrent was compiled against a different
version of libtorrent-rasterbar than the one installed.
Either you installed qBittorrent from one repo and libtorrent-rasterbar from
another. Or, someone updated libtorrent-rasterbar
in the repository and forgot to
Please reassign to libtorrent-rasterbar, this is obviously not related to
qBittorrent itself.
It would also be useful to have more information regarding where the torrents
are stuck.
Are they stuck at 99.9% and just won't go to 100%? Or do they get stuck earlier?
Are you connected to full
qBittorrent v2.4.11 can be built against either libtorrent v0.14.x or
v0.15.x. Both should be fine but some new features are introduced in
libtorrent v0.15. Your high CPU problem is likely to be a libtorrent
bug though, I would suggest trying a more up-to-date version of
libtorrent v0.14 or maybe
Have you tried Deluge (also based on libtorrent)? As I said, I suspect
this is a libtorrent issue and not caused by a bug in qBittorrent.
I will install Wheezy in a VM and see if I can reproduce the issue
anyway but please test Deluge to see if you get the same behavior.
Kr,
Chris.
On Mon, Apr
).
Kr,
Chris.
On Mon, Apr 25, 2011 at 6:20 PM, Christophe Dumez ch...@qbittorrent.org wrote:
Have you tried Deluge (also based on libtorrent)? As I said, I suspect
this is a libtorrent issue and not caused by a bug in qBittorrent.
I will install Wheezy in a VM and see if I can reproduce the issue
Hi,
You have an old version of qBittorrent and a recent version of boost
(with new filesystem v3 API by default).
Either update qBittorrent or add a DEFINE to force the filesystem v2
API from boost (1).
(1) To do so, just add DEFINES += BOOST_FILESYSTEM_VERSION=2 to
qbittorrent/src/src.pro
This bug was fixed quite some time ago (v2.2.8), see:
https://bugs.launchpad.net/qbittorrent/+bug/583347
* Mon May 24 2010 - Christophe Dumez ch...@qbittorrent.org - v2.2.8
- BUGFIX: ETA for finished torrent is now 0 instead of Infinite
(closes #583704)
- BUGFIX: Fix sorting of ETA column
Hi,
Is this still an issue with recent qBittorrent versions? I have made
quite a few improvements since this bug report.
Of course, the ETA calculation can never be perfect and it is just an estimate.
Just so you know, qBittorrent ETA calculation algorithms should be
identical to KTorrent's.
The stylesheet message is not a bug, I simply no not use stylesheets for
qBittorrent right now.
Regarding the speed indicators, they were moved to status bar because a
lot of users did not like the old way of displaying it. qBittorrent
v1.2.0 interface is more simple and clear.
--
To
Package: libboost-regex1.34.1
Version: 1.34.1
libboost-regex1.34.1 is not instalable in unstable because it is
depending on a version of libicu that is no longer available.
# apt-get install libboost-regex1.34.1
returns the following output:
libboost-regex1.34.1: Depends: libicu36 ( 3.6-7) but
13 matches
Mail list logo
