Steps for version 3.4 release #5525

Author

Owner

@thalieht commented on GitHub (May 10, 2017):

Considering all the icons were changed for this version, #6484 should be in as well.

@thalieht commented on GitHub (May 10, 2017): Considering all the icons were changed for this version, #6484 should be in as well.

deekerman commented

Author

Owner

@sledgehammer999 commented on GitHub (May 10, 2017):

I'll comment in a couple of hours. But now something I don't want to forget:

Isn't v3.4.0 a great opportunity to dump the ".unwanted" folder functionality? Especially now that we support 1.1.x which puts unwanted blocks into a "parts" file? My intention is to make RC_1_1 the main series for 3.4.x.

If we agree to the above, doesn't anyone volunteer to make it happen? I assume we would need a migration function too, with a notice that users can't go back to earlier versions.

@sledgehammer999 commented on GitHub (May 10, 2017): I'll comment in a couple of hours. But now something I don't want to forget: Isn't v3.4.0 a great opportunity to dump the ".unwanted" folder functionality? Especially now that we support 1.1.x which puts unwanted blocks into a "parts" file? My intention is to make RC_1_1 the main series for 3.4.x. If we agree to the above, doesn't anyone volunteer to make it happen? I assume we would need a migration function too, with a notice that users can't go back to earlier versions.

deekerman commented

Author

Owner

@glassez commented on GitHub (May 10, 2017):

Personally, I would also like to see [#6698], [#4029], [#3810], and [#3235], updated and merged, sooner rather than later.

I'm not sure that #4029 and #3810 can be completed in a reasonable time.

If we agree to the above, doesn't anyone volunteer to make it happen? I assume we would need a migration function too, with a notice that users can't go back to earlier versions.

Is migration required in this case? IMO, we can just stop doing it and leave existing files as is (and notice users about new behavior in release announcement).

@glassez commented on GitHub (May 10, 2017): >Personally, I would also like to see [#6698], [#4029], [#3810], and [#3235], updated and merged, sooner rather than later. I'm not sure that #4029 and #3810 can be completed in a reasonable time. >If we agree to the above, doesn't anyone volunteer to make it happen? I assume we would need a migration function too, with a notice that users can't go back to earlier versions. Is migration required in this case? IMO, we can just stop doing it and leave existing files as is (and notice users about new behavior in release announcement).

deekerman commented

Author

Owner

@zeule commented on GitHub (May 10, 2017):

Regarding libtorrent 1.1: take a look at https://github.com/arvidn/libtorrent/issues/1967. Such replacement to .unwanted files might enrage users even more.

@zeule commented on GitHub (May 10, 2017): Regarding libtorrent 1.1: take a look at https://github.com/arvidn/libtorrent/issues/1967. Such replacement to .unwanted files might enrage users even more.

deekerman commented

Author

Owner

@WolfganP commented on GitHub (May 10, 2017):

I'm just happy https://github.com/qbittorrent/qBittorrent/pull/5465 was merged already, so I assume it will hit v3.4.0
Due all the changes included, I support the release of a beta version (Win10 in my case) for interested users to shake up the RC a bit beforehand.

@WolfganP commented on GitHub (May 10, 2017): I'm just happy https://github.com/qbittorrent/qBittorrent/pull/5465 was merged already, so I assume it will hit v3.4.0 Due all the changes included, I support the release of a beta version (Win10 in my case) for interested users to shake up the RC a bit beforehand.

deekerman commented

Author

Owner

@zeule commented on GitHub (May 10, 2017):

I actually would like to see #4994 in 3.4.0 too.

@zeule commented on GitHub (May 10, 2017): I actually would like to see #4994 in 3.4.0 too.

deekerman commented

Author

Owner

@zeule commented on GitHub (May 10, 2017):

If we agree to the above, doesn't anyone volunteer to make it happen? I assume we would need a migration function too, with a notice that users can't go back to earlier versions.

Is migration required in this case? IMO, we can just stop doing it and leave existing files as is (and notice users about new behavior in release announcement).

From my experience it is worth to force rechecking all half-downloaded torrents after upgrading to libtorrent 1.1 in order to create and fill proper .parts files. Otherwise I/O errors pop-up when these torrent are seeded.

@zeule commented on GitHub (May 10, 2017): >> If we agree to the above, doesn't anyone volunteer to make it happen? I assume we would need a migration function too, with a notice that users can't go back to earlier versions. > Is migration required in this case? IMO, we can just stop doing it and leave existing files as is (and notice users about new behavior in release announcement). From my experience it is worth to force rechecking all half-downloaded torrents after upgrading to libtorrent 1.1 in order to create and fill proper .parts files. Otherwise I/O errors pop-up when these torrent are seeded.

deekerman commented

Author

Owner

@zeule commented on GitHub (May 10, 2017):

#3810 is important for Linux users only in its current state (but I wanted to add configurable notifications, i.e. user can select which event they want to see in notifications and which to ignore). As such, I don't think it has anything but minor priority, don't you agree?

@zeule commented on GitHub (May 10, 2017): #3810 is important for Linux users only in its current state (but I wanted to add configurable notifications, i.e. user can select which event they want to see in notifications and which to ignore). As such, I don't think it has anything but minor priority, don't you agree?

deekerman commented

Author

Owner

@zeule commented on GitHub (May 10, 2017):

At the same time I'd like to point you at #6156, which clearly adds benefits and needs just updating the libs for distribution/appveyour.

@zeule commented on GitHub (May 10, 2017): At the same time I'd like to point you at #6156, which clearly adds benefits and needs just updating the libs for distribution/appveyour.

deekerman commented

Author

Owner

@Chocobo1 commented on GitHub (May 10, 2017):

To keep things manageable, maybe we can use this: https://github.com/qbittorrent/qBittorrent/projects
I've already put in my notes and devs can put in theirs too (in a new column).

@Chocobo1 commented on GitHub (May 10, 2017): To keep things manageable, maybe we can use this: https://github.com/qbittorrent/qBittorrent/projects I've already put in my notes and devs can put in theirs too (in a new column).

deekerman commented

Author

Owner

@FranciscoPombal commented on GitHub (May 12, 2017):

@glassez, @evsh, @Chocobo1, @sledgehammer999
I would also like to see https://github.com/qbittorrent/qBittorrent/issues/6726 addressed as well, I think it is a serious security issue.

@FranciscoPombal commented on GitHub (May 12, 2017): @glassez, @evsh, @Chocobo1, @sledgehammer999 I would also like to see https://github.com/qbittorrent/qBittorrent/issues/6726 addressed as well, I think it is a serious security issue.

deekerman commented

Author

Owner

@Seeker2 commented on GitHub (May 12, 2017):

I know there's no hope for "Alternate connections per torrent while seeding": https://github.com/qbittorrent/qBittorrent/issues/2193 ...making it into v3.4. I want qBT v3.4 to be released soon too.
But please consider it for a future version of qBT.

@Seeker2 commented on GitHub (May 12, 2017): I know there's no hope for "Alternate connections per torrent while seeding": https://github.com/qbittorrent/qBittorrent/issues/2193 ...making it into v3.4. I want qBT v3.4 to be released soon too. But please consider it for a future version of qBT.

deekerman commented

Author

Owner

@sledgehammer999 commented on GitHub (May 18, 2017):

General comment for the rest of the devs: Guys, I'm on a tight schedule till Wednesday. Please give me time until 29th May. My top priority is to put a v3.3.13 version out containing important webui fixes. In the meantime I'll try to resume commenting on pending PRs.

@sledgehammer999 commented on GitHub (May 18, 2017): General comment for the rest of the devs: Guys, I'm on a tight schedule till Wednesday. Please give me time until 29th May. My top priority is to put a v3.3.13 version out containing important webui fixes. In the meantime I'll try to resume commenting on pending PRs.

deekerman commented

Author

Owner

@naikel commented on GitHub (May 21, 2017):

I'm loving 3.4.0 so far. I'm really testing it now and using it daily. I found a couple of bugs in WebUI and created PRs #6818 and #6827.

@naikel commented on GitHub (May 21, 2017): I'm loving 3.4.0 so far. I'm really testing it now and using it daily. I found a couple of bugs in WebUI and created PRs #6818 and #6827.

deekerman commented

Author

Owner

@Matth7878 commented on GitHub (Jul 1, 2017):

Does an updated list to what is expected to be considered ready for 3.4.0 exists ?
Project "v3.4.0 release expectations" has no update since may 24th but almost all expected PR from developers have been committed. Since development has geared up it is hard not to be impatient ! :-D

@Matth7878 commented on GitHub (Jul 1, 2017): Does an updated list to what is expected to be considered ready for 3.4.0 exists ? Project "v3.4.0 release expectations" has no update since may 24th but almost all expected PR from developers have been committed. Since development has geared up it is hard not to be impatient ! :-D

deekerman commented

Author

Owner

@sledgehammer999 commented on GitHub (Jul 1, 2017):

The list should be in the release's README. But it will be a pain to make it because I have cherry-picked a lot for the v3.3.x and it will be hard to distinguish the non-cherry-picked commits from the master branch.
Probably a txt-diff comparison of the 2 commit lists will do the trick.

@sledgehammer999 commented on GitHub (Jul 1, 2017): The list should be in the release's README. But it will be a pain to make it because I have cherry-picked a lot for the v3.3.x and it will be hard to distinguish the non-cherry-picked commits from the master branch. Probably a txt-diff comparison of the 2 commit lists will do the trick.

deekerman commented

Author

Owner

@bertyhell commented on GitHub (Jul 29, 2017):

Are there any 3.4 build available for download anywhere? i'd like to help test the release (and see my icons in action :p)

@bertyhell commented on GitHub (Jul 29, 2017): Are there any 3.4 build available for download anywhere? i'd like to help test the release (and see my icons in action :p)

deekerman commented

Author

Owner

@sledgehammer999 commented on GitHub (Aug 5, 2017):

Tomorrow, I'll post a beta build on the site.

@sledgehammer999 commented on GitHub (Aug 5, 2017): Tomorrow, I'll post a beta build on the site.

deekerman commented

Author

Owner

@glassez commented on GitHub (Aug 7, 2017):

@sledgehammer999, I'm not sure you receive alerts about inline comments in merged commits so I repost it here:

've been wanting to tell you this...
You shouldn't mention intermediate bugfixes in changelog! I.e. if some bug was introduced and then fixed between two adjacent releases it shouldn't be mentioned in changelog.

@glassez commented on GitHub (Aug 7, 2017): @sledgehammer999, I'm not sure you receive alerts about inline comments in merged commits so I repost it here: >'ve been wanting to tell you this... You shouldn't mention intermediate bugfixes in changelog! I.e. if some bug was introduced and then fixed between two adjacent releases it shouldn't be mentioned in changelog.

deekerman commented

Author

Owner

@sledgehammer999 commented on GitHub (Aug 7, 2017):

You shouldn't mention intermediate bugfixes in changelog! I.e. if some bug was introduced and then fixed between two adjacent releases it shouldn't be mentioned in changelog.

That's my intention. Did I miss something?

@sledgehammer999 commented on GitHub (Aug 7, 2017): >You shouldn't mention intermediate bugfixes in changelog! I.e. if some bug was introduced and then fixed between two adjacent releases it shouldn't be mentioned in changelog. That's my intention. Did I miss something?

deekerman commented

Author

Owner

@pasha-zzz commented on GitHub (Aug 8, 2017):

Maybe #6569 and #6059 too?

@pasha-zzz commented on GitHub (Aug 8, 2017): Maybe #6569 and #6059 too?

deekerman commented

Author

Owner

@sledgehammer999 commented on GitHub (Aug 10, 2017):

Refactor and improve statusBar is also a fixup commit, FYI.

I think it contains extra stuff.

@sledgehammer999 commented on GitHub (Aug 10, 2017): >`Refactor and improve statusBar` is also a fixup commit, FYI. I think it contains extra stuff.

deekerman commented

Author

Owner

@sledgehammer999 commented on GitHub (Aug 20, 2017):

@qbittorrent/demigods I am planning to do stable release of master the next weekend. Also I am thinking of bumping the version to 4.0.0 instead of 3.4.0. Is that ok?
(of course the v3_4_x branch will be renamed too)

@sledgehammer999 commented on GitHub (Aug 20, 2017): @qbittorrent/demigods I am planning to do stable release of master the next weekend. Also I am thinking of bumping the version to `4.0.0` instead of `3.4.0`. Is that ok? (of course the v3_4_x branch will be renamed too)

deekerman commented

Author

Owner

@glassez commented on GitHub (Aug 20, 2017):

Also I am thinking of bumping the version to 4.0.0 instead of 3.4.0. Is that ok?

If you have reason to do it... Of course, it would be better to do it starting with beta release (it looks strange v4.0 after v3.4beta).

I am planning to do stable release of master the next weekend.

New RSS subsystem has one reported bug. I can't fix it without affected feed urls but Issue author still don't provide me necessary info.

@glassez commented on GitHub (Aug 20, 2017): >Also I am thinking of bumping the version to 4.0.0 instead of 3.4.0. Is that ok? If you have reason to do it... Of course, it would be better to do it starting with beta release (it looks strange v4.0 after v3.4beta). >I am planning to do stable release of master the next weekend. New RSS subsystem has one reported bug. I can't fix it without affected feed urls but Issue author still don't provide me necessary info.

deekerman commented

Author

Owner

@Chocobo1 commented on GitHub (Aug 20, 2017):

I am planning to do stable release of master the next weekend.

I'll try to make #3235 ready in time.

Of course, it would be better to do it starting with beta release

+1

@Chocobo1 commented on GitHub (Aug 20, 2017): >I am planning to do stable release of master the next weekend. I'll try to make #3235 ready in time. >Of course, it would be better to do it starting with beta release +1

deekerman commented

Author

Owner

@sledgehammer999 commented on GitHub (Aug 20, 2017):

If you have reason to do it...

ΙΜΟ, the jump from 3.3.x to 3.4.x seems small for the amount of differences between. Also early v3.3.x releases(eg 3.3.3) are quite different in features/capabilities from current code. So I just wanted to signal the evolution via version number too.

I'll try to make #3235 ready in time.

Sure, but it can safely go into v4.0.1 too.

New RSS subsystem has one reported bug. I can't fix it without affected feed urls but Issue author still don't provide me necessary info.

Do you think it important enough to wait more?
In case of a stable release there might be new reporters with better info.

@sledgehammer999 commented on GitHub (Aug 20, 2017): >If you have reason to do it... ΙΜΟ, the jump from 3.3.x to 3.4.x seems small for the amount of differences between. Also early v3.3.x releases(eg 3.3.3) are quite different in features/capabilities from current code. So I just wanted to signal the evolution via version number too. >I'll try to make #3235 ready in time. Sure, but it can safely go into v4.0.1 too. >New RSS subsystem has one reported bug. I can't fix it without affected feed urls but Issue author still don't provide me necessary info. Do you think it important enough to wait more? In case of a stable release there might be new reporters with better info.

deekerman commented

Author

Owner

@naikel commented on GitHub (Aug 20, 2017):

What's the one reported bug for the RSS subsystem? I can only found two issues: one already fixed that only magnet links work and direct http links don't, and another one where the user has a Mac and can't try 3.4.0 beta.

@naikel commented on GitHub (Aug 20, 2017): What's the one reported bug for the RSS subsystem? I can only found two issues: one already fixed that only magnet links work and direct http links don't, and another one where the user has a Mac and can't try 3.4.0 beta.

deekerman commented

Author

Owner

@glassez commented on GitHub (Aug 20, 2017):

What's the one reported bug for the RSS subsystem?

Well, there's no separate Issue for thos problem. See last comments of #3898.

Do you think it important enough to wait more?

No, I don't.

@glassez commented on GitHub (Aug 20, 2017): >What's the one reported bug for the RSS subsystem? Well, there's no separate Issue for thos problem. See last comments of #3898. >Do you think it important enough to wait more? No, I don't.

deekerman commented

Author

Owner

@glassez commented on GitHub (Aug 23, 2017):

ΙΜΟ, the jump from 3.3.x to 3.4.x seems small for the amount of differences between.

Actually, I agree with major version update now. I just wish the release cycle were a little bit more formalized in the future.

@glassez commented on GitHub (Aug 23, 2017): >ΙΜΟ, the jump from 3.3.x to 3.4.x seems small for the amount of differences between. Actually, I agree with major version update now. I just wish the release cycle were a little bit more formalized in the future.

deekerman commented

Author

Owner

@WolfganP commented on GitHub (Aug 25, 2017):

Question about the 3.4.0 beta version. Was it compiled against libtorrent RC_1_0 or RC_1_1?

I wonder what's the target for 3.4.0 as there was a lot of discussion and development effort on v1.1 lately, with adoption of new lib features and the infamous mem leak... could anyone confirm?
Thx.

@WolfganP commented on GitHub (Aug 25, 2017): Question about the 3.4.0 beta version. Was it compiled against libtorrent RC_1_0 or RC_1_1? I wonder what's the target for 3.4.0 as there was a lot of discussion and development effort on v1.1 lately, with adoption of new lib features and the infamous mem leak... could anyone confirm? Thx.

deekerman commented

Author

Owner

@thalieht commented on GitHub (Aug 25, 2017):

RC_1_1

@thalieht commented on GitHub (Aug 25, 2017): RC_1_1

deekerman commented

Author

Owner

@WolfganP commented on GitHub (Aug 25, 2017):

I need to recompile everything then, cause when building qb from scratch with libtorrent RC_1_1 in my raspberry 2, qbittorrent-nox now stops with:

qbittorrent-nox: symbol lookup error: qbittorrent-nox: undefined symbol: _ZN10libtorrent20generate_fingerprintENSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEiiii

Any idea what could it be? TIA

@WolfganP commented on GitHub (Aug 25, 2017): I need to recompile everything then, cause when building qb from scratch with libtorrent RC_1_1 in my raspberry 2, qbittorrent-nox now stops with: ``` qbittorrent-nox: symbol lookup error: qbittorrent-nox: undefined symbol: _ZN10libtorrent20generate_fingerprintENSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEiiii ``` Any idea what could it be? TIA

deekerman commented

Author

Owner

@sledgehammer999 commented on GitHub (Aug 27, 2017):

An update: The final release is pushed back till next weekend unfortunately. I was planning to review/merge the PR for the logo this past week. But unforeseen events rendered me inactive in the project. I should be able to merge that PR during this week. Otherwise, I'll post a 2nd beta next weekend instead of a final version.

Of course, pending small PRs and hotfixes will be merged too.

I wonder what's the target for 3.4.0 as there was a lot of discussion and development effort on v1.1 lately, with adoption of new lib features and the infamous mem leak... could anyone confirm?

That's why all those issues were discovered, reported and fixed. Because RC_1_1 is in the qbt spotlight now.

I need to recompile everything then, cause when building qb from scratch with libtorrent RC_1_1 in my raspberry 2, qbittorrent-nox now stops with:

You must make sure that it compiles/links against >= 1.1.2. Earlier versions don't contain libtorrent::generate_fingerprint().
(and yes, it is deliberate that we don't use a patch for earlier versions)

@sledgehammer999 commented on GitHub (Aug 27, 2017): **An update:** The final release is pushed back till next weekend unfortunately. I was planning to review/merge the PR for the logo this past week. But unforeseen events rendered me inactive in the project. I should be able to merge that PR during this week. Otherwise, I'll post a 2nd beta next weekend instead of a final version. Of course, pending small PRs and hotfixes will be merged too. >I wonder what's the target for 3.4.0 as there was a lot of discussion and development effort on v1.1 lately, with adoption of new lib features and the infamous mem leak... could anyone confirm? That's why all those issues were discovered, reported and fixed. Because RC_1_1 is in the qbt spotlight now. >I need to recompile everything then, cause when building qb from scratch with libtorrent RC_1_1 in my raspberry 2, qbittorrent-nox now stops with: You must make sure that it compiles/links against >= 1.1.2. Earlier versions don't contain `libtorrent::generate_fingerprint()`. (and yes, it is deliberate that we don't use a patch for earlier versions)

deekerman commented

Author

Owner

@sledgehammer999 commented on GitHub (Aug 27, 2017):

You must make sure that it compiles/links against >= 1.1.2.

Of course, it still can compile/link against RC_1_0 too. But RC_1_1 is the main focus now.

@sledgehammer999 commented on GitHub (Aug 27, 2017): >You must make sure that it compiles/links against >= 1.1.2. Of course, it still can compile/link against RC_1_0 too. But RC_1_1 is the main focus now.

deekerman commented

Author

Owner

@sledgehammer999 commented on GitHub (Aug 27, 2017):

QFileIconProvider isn't essential IMO.

EDIT: The affected libs from 1.65 aren't used by us and libtorrent. So no issue there either.

@sledgehammer999 commented on GitHub (Aug 27, 2017): `QFileIconProvider` isn't essential IMO. EDIT: The affected libs from 1.65 aren't used by us and libtorrent. So no issue there either.

deekerman commented

Author

Owner

@sledgehammer999 commented on GitHub (Aug 27, 2017):

It will depend if I have enough time to recompile said libs and their dependants.

@sledgehammer999 commented on GitHub (Aug 27, 2017): It will depend if I have enough time to recompile said libs and their dependants.

deekerman commented

Author

Owner

@RabidWolf commented on GitHub (Aug 28, 2017):

Also, I have been wondering if you might offer builds based on Libtorrent 1.0.x in addition to ones based on Libtorrent 1.1.x, for Windows users?

What's the difference between the 2?

@RabidWolf commented on GitHub (Aug 28, 2017): > Also, I have been wondering if you might offer builds based on Libtorrent 1.0.x in addition to ones based on Libtorrent 1.1.x, for Windows users? What's the difference between the 2?

deekerman commented

Author

Owner

@sledgehammer999 commented on GitHub (Aug 28, 2017):

What's the difference between the 2?

libtorrent 1.1.0 changelog. Partly fixes and partly features. Fixes might be backported to the RC_1_0 branch but not the features.

Also, I have been wondering if you might offer builds based on Libtorrent 1.0.x in addition to ones based on Libtorrent 1.1.x, for Windows users?

No.

@sledgehammer999 commented on GitHub (Aug 28, 2017): >What's the difference between the 2? [libtorrent 1.1.0 changelog](https://github.com/arvidn/libtorrent/releases/tag/libtorrent-1_1). Partly fixes and partly features. Fixes might be backported to the RC_1_0 branch but not the features. >Also, I have been wondering if you might offer builds based on Libtorrent 1.0.x in addition to ones based on Libtorrent 1.1.x, for Windows users? No.

deekerman commented

Author

Owner

@WolfganP commented on GitHub (Sep 1, 2017):

I know this maybe too naive, but couldn't find it in the makefiles' set. Which flag do I need to pass ./configure to choose debug / release build version?

And I assume that even opting for a debug build, the -nox compilation will be a quiet one while running and just log to /var/log/qbittorrent-nox.log?
Thanks!

@WolfganP commented on GitHub (Sep 1, 2017): I know this maybe too naive, but couldn't find it in the makefiles' set. Which flag do I need to pass ./configure to choose debug / release build version? And I assume that even opting for a debug build, the -nox compilation will be a quiet one while running and just log to /var/log/qbittorrent-nox.log? Thanks!

deekerman commented

Author

Owner

@Chocobo1 commented on GitHub (Sep 2, 2017):

I know this maybe too naive, but couldn't find it in the makefiles' set. Which flag do I need to pass ./configure to choose debug / release build version?

have you tried?
./configure --help

it says:

--enable-debug          Enable debug build

@Chocobo1 commented on GitHub (Sep 2, 2017): >I know this maybe too naive, but couldn't find it in the makefiles' set. Which flag do I need to pass ./configure to choose debug / release build version? have you tried? `./configure --help` it says: ``` --enable-debug Enable debug build ```

deekerman commented

Author

Owner

@WolfganP commented on GitHub (Sep 3, 2017):

@sledgehammer999

You must make sure that it compiles/links against >= 1.1.2. Earlier versions don't contain libtorrent::generate_fingerprint().
(and yes, it is deliberate that we don't use a patch for earlier versions)

I did recompile libtorrent RC_1_1 (v1.1.4 at this time) and qB master head as previously suggested from scratch, and still suffering the dreaded fingerprint error. As per gdb:

Starting program: /usr/bin/qbittorrent-nox --webui-port=8099
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/arm-linux-gnueabihf/libthread_db.so.1".
[New Thread 0x74046a70 (LWP 10038)]
[New Thread 0x7343aa70 (LWP 10039)]
/usr/bin/qbittorrent-nox: symbol lookup error: /usr/bin/qbittorrent-nox: undefined symbol: _ZN10libtorrent20generate_fingerprintENSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEiiii
[Thread 0x7343aa70 (LWP 10039) exited]
[Thread 0x76fef000 (LWP 10032) exited]
[Inferior 1 (process 10032) exited with code 0177]

I didn't observe any linking or compilation error during the process, and checked any fingerprint piece of code is actually compiled when building libtorrent. Any idea what it may be?
Thanks.

@WolfganP commented on GitHub (Sep 3, 2017): @sledgehammer999 ``` You must make sure that it compiles/links against >= 1.1.2. Earlier versions don't contain libtorrent::generate_fingerprint(). (and yes, it is deliberate that we don't use a patch for earlier versions) ``` I did recompile libtorrent RC_1_1 (v1.1.4 at this time) and qB master head as previously suggested from scratch, and still suffering the dreaded fingerprint error. As per gdb: ``` Starting program: /usr/bin/qbittorrent-nox --webui-port=8099 [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/arm-linux-gnueabihf/libthread_db.so.1". [New Thread 0x74046a70 (LWP 10038)] [New Thread 0x7343aa70 (LWP 10039)] /usr/bin/qbittorrent-nox: symbol lookup error: /usr/bin/qbittorrent-nox: undefined symbol: _ZN10libtorrent20generate_fingerprintENSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEiiii [Thread 0x7343aa70 (LWP 10039) exited] [Thread 0x76fef000 (LWP 10032) exited] [Inferior 1 (process 10032) exited with code 0177] ``` I didn't observe any linking or compilation error during the process, and checked any fingerprint piece of code is actually compiled when building libtorrent. Any idea what it may be? Thanks.

deekerman commented

Author

Owner

@zeule commented on GitHub (Sep 3, 2017):

If it compiles but does not run, this might indicate that your binary is stripped and LD_PATH contains another copy of libtorrent-rasterbar.so

@zeule commented on GitHub (Sep 3, 2017): If it compiles but does not run, this might indicate that your binary is stripped and `LD_PATH` contains another copy of `libtorrent-rasterbar.so`

deekerman commented

Author

Owner

@WolfganP commented on GitHub (Sep 3, 2017):

If it compiles but does not run, this might indicate that your binary is stripped and LD_PATH contains another copy of libtorrent-rasterbar.so

Success! The /var/lib path had a copy of libtorrent-rasterbar8 that surely was generated a while ago and that interfered with qB building process. Now v3.4.0alpha working with libtorrent v1.1 !!!

Thanks a lot for all your help!

My only remaining wish is just that https://github.com/qbittorrent/qBittorrent/pull/5465 "Root folder strip" is exposed to the webUI add torrent window and that will complete my happy transition to qB! Thanks again!

@WolfganP commented on GitHub (Sep 3, 2017): > If it compiles but does not run, this might indicate that your binary is stripped and LD_PATH contains another copy of libtorrent-rasterbar.so Success! The /var/lib path had a copy of libtorrent-rasterbar8 that surely was generated a while ago and that interfered with qB building process. Now v3.4.0alpha working with libtorrent v1.1 !!! Thanks a lot for all your help! My only remaining wish is just that https://github.com/qbittorrent/qBittorrent/pull/5465 "Root folder strip" is exposed to the webUI add torrent window and that will complete my happy transition to qB! Thanks again!

deekerman commented

Author

Owner

@sledgehammer999 commented on GitHub (Sep 5, 2017):

Yet another tiny update: I realize that it is a bit long since last stable release. So now I am cherry-picking critical commits(eg the one that chooses wrong listen interface) and will do a v3.3.16 release along with a v3.4.0beta2 release. Stay tuned. I should be done in 3-4 hours.

@sledgehammer999 commented on GitHub (Sep 5, 2017): **Yet another tiny update:** I realize that it is a bit long since last stable release. So now I am cherry-picking critical commits(eg the one that chooses wrong listen interface) and will do a v3.3.16 release along with a v3.4.0beta2 release. Stay tuned. I should be done in 3-4 hours.

deekerman commented

Author

Owner

@glassez commented on GitHub (Sep 5, 2017):

bda5be8e4c is very important for v3.3.16 .

@glassez commented on GitHub (Sep 5, 2017): bda5be8e4ce3dd998805427af862e134bdc7daa1 is very important for v3.3.16 .

deekerman commented

Author

Owner

@glassez commented on GitHub (Sep 5, 2017):

...will do a v3.3.16 release along with a v3.4.0beta2 release. Stay tuned. I should be done in 3-4 hours.

BTW, this is good point to rename v3.4 to v4.0 if you still want to do it (and release v4.0.0beta or beta2).

@glassez commented on GitHub (Sep 5, 2017): >...will do a v3.3.16 release along with a v3.4.0beta2 release. Stay tuned. I should be done in 3-4 hours. BTW, this is good point to rename v3.4 to v4.0 if you still want to do it (and release v4.0.0beta or beta2).

deekerman commented

Author

Owner

@sledgehammer999 commented on GitHub (Sep 5, 2017):

bda5be8 is very important for v3.3.16 .

I agree.
Also what should I do with 5f47d3b021 and f067b8b37c? They seem related to stripFolder which isn't backported. Do they fix something that should be fixed in v3.3.16 too?

BTW, this is good point to rename v3.4 to v4.0 if you still want to do it (and release v4.0.0beta or beta2).

Normally, yes. But I have discovered a possible side-effect of the current "beta" situation. Trackers that rely only at the peer-id will not be able to differentiate between v4.0.0beta and v4.0.0 stable. So since the "v3.4.0" is burned already, I intend to continue the betas like that, and instead mention the future transition to v4.0.0 in the news entry.

@sledgehammer999 commented on GitHub (Sep 5, 2017): >bda5be8 is very important for v3.3.16 . I agree. Also what should I do with 5f47d3b02184389e86e4c3177ac7ea94bc542b24 and f067b8b37cbb0aaf96e064554b660d6f17aaffcd? They seem related to stripFolder which isn't backported. Do they fix something that should be fixed in v3.3.16 too? >BTW, this is good point to rename v3.4 to v4.0 if you still want to do it (and release v4.0.0beta or beta2). Normally, yes. But I have discovered a possible side-effect of the current "beta" situation. Trackers that rely only at the peer-id will not be able to differentiate between v4.0.0beta and v4.0.0 stable. So since the "v3.4.0" is burned already, I intend to continue the betas like that, and instead mention the future transition to v4.0.0 in the news entry.

deekerman commented

Author

Owner

@glassez commented on GitHub (Sep 5, 2017):

Do they fix something that should be fixed in v3.3.16 too?

Don't think. Leave it for 3.4.

@glassez commented on GitHub (Sep 5, 2017): >Do they fix something that should be fixed in v3.3.16 too? Don't think. Leave it for 3.4.

deekerman commented

Author

Owner

@WolfganP commented on GitHub (Sep 24, 2017):

Any way that a quick prototype of https://github.com/qbittorrent/qBittorrent/issues/7217 WebUI off-program extensions can be implemented so actual alt WebUI mods like @naikel (https://github.com/qbittorrent/qBittorrent/issues/6882#issuecomment-318144215) can be start to be worked on with core and maybe be included in official 3.4.0 if the feature matures enough? (I always think that visual features like UI / WebUI changes always get big attention from users due it's "materiality" :-)
Thanks!

@WolfganP commented on GitHub (Sep 24, 2017): Any way that a quick prototype of https://github.com/qbittorrent/qBittorrent/issues/7217 **WebUI off-program extensions** can be implemented so actual alt WebUI mods like @naikel (https://github.com/qbittorrent/qBittorrent/issues/6882#issuecomment-318144215) can be start to be worked on with core and maybe be included in official 3.4.0 if the feature matures enough? (I always think that visual features like UI / WebUI changes always get big attention from users due it's "materiality" :-) Thanks!

deekerman commented

Author

Owner

@Amaunator commented on GitHub (Oct 4, 2017):

hi all! On Arch with boost 1.65 neither version works: from repos nor compiled from the source. libboost_system.so.1.64.0: cannot open shared object file: No such file or directory

compile errors:
compiling base/net/portforwarder.cpp compiling base/net/proxyconfigurationmanager.cpp compiling base/net/reverseresolution.cpp In file included from /usr/include/libtorrent/version.hpp:36:0, from app/upgrade.h:32, from app/main.cpp:79: /usr/include/libtorrent/export.hpp:37:12: fatal error: boost/config/select_compiler_config.hpp: No such file or directory include <boost/config/select_compiler_config.hpp> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ compilation terminated. make[1]: *** [Makefile:2935: main.o] Error 1

@Amaunator commented on GitHub (Oct 4, 2017): hi all! On Arch with boost 1.65 neither version works: from repos nor compiled from the source. `libboost_system.so.1.64.0: cannot open shared object file: No such file or directory` compile errors: ` compiling base/net/portforwarder.cpp compiling base/net/proxyconfigurationmanager.cpp compiling base/net/reverseresolution.cpp In file included from /usr/include/libtorrent/version.hpp:36:0, from app/upgrade.h:32, from app/main.cpp:79: /usr/include/libtorrent/export.hpp:37:12: fatal error: boost/config/select_compiler_config.hpp: No such file or directory include <boost/config/select_compiler_config.hpp> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ compilation terminated. make[1]: *** [Makefile:2935: main.o] Error 1 `

deekerman commented

Author

Owner

@Chocobo1 commented on GitHub (Oct 5, 2017):

hi all! On Arch with boost 1.65 neither version works: from repos nor compiled from the source. libboost_system.so.1.64.0: cannot open shared object file: No such file or directory

you need to rebuild libtorrent-rasterbar with boost 1.65.

@Chocobo1 commented on GitHub (Oct 5, 2017): >hi all! On Arch with boost 1.65 neither version works: from repos nor compiled from the source. libboost_system.so.1.64.0: cannot open shared object file: No such file or directory you need to rebuild libtorrent-rasterbar with boost 1.65.

deekerman commented

Author

Owner

@sledgehammer999 commented on GitHub (Oct 12, 2017):

Some news: The logo PR (#6484) is almost ready for merging. I am also going to update the .ts files for the translators to work again on them. Because of that, to give them time, I think I shouldn't release sooner than the coming Wednesday.
Is #7445 still being considered for v4.0.0? Is there any other issue that should stall the final release?

@sledgehammer999 commented on GitHub (Oct 12, 2017): Some news: The logo PR (#6484) is almost ready for merging. I am also going to update the .ts files for the translators to work again on them. Because of that, to give them time, I think I shouldn't release sooner than the coming Wednesday. Is #7445 still being considered for v4.0.0? Is there any other issue that should stall the final release?

deekerman commented

Author

Owner

@Chocobo1 commented on GitHub (Oct 13, 2017):

Is #7445 still being considered for v4.0.0?

Yes, it's been stalled because we couldn't make an agreement, yet I think its worth a try.

@Chocobo1 commented on GitHub (Oct 13, 2017): >Is #7445 still being considered for v4.0.0? Yes, it's been stalled because we couldn't make an agreement, yet I think its worth a try.

deekerman commented

Author

Owner

@Seeker2 commented on GitHub (Oct 13, 2017):

There's some serious functionality problems that need to be addressed eventually, but they may have to wait till after this is released.

UPnP, tracker issues, ip bans, high cpu and memory usage, possible crashes.

@Seeker2 commented on GitHub (Oct 13, 2017): There's some serious functionality problems that need to be addressed eventually, but they may have to wait till after this is released. UPnP, tracker issues, ip bans, high cpu and memory usage, possible crashes.

deekerman commented

Author

Owner

@sledgehammer999 commented on GitHub (Nov 2, 2017):

If I find time tomorrow I am going to release v4.0.0. Should I wait for some specific PR first?
PS: #6484 will be merged just before releasing.

@sledgehammer999 commented on GitHub (Nov 2, 2017): If I find time tomorrow I am going to release v4.0.0. Should I wait for some specific PR first? PS: #6484 will be merged just before releasing.

deekerman commented

Author

Owner

@ghost commented on GitHub (Nov 2, 2017):

@sledgehammer999 What about #6484?

@ghost commented on GitHub (Nov 2, 2017): @sledgehammer999 What about #6484?

deekerman commented

Author

Owner

@Chocobo1 commented on GitHub (Nov 3, 2017):

Should I wait for some specific PR first?

#7636, the feature (noted in change log) isn't really complete without the fix.
Can you make a little time fixing it?

@Chocobo1 commented on GitHub (Nov 3, 2017): >Should I wait for some specific PR first? #7636, the feature (noted in change log) isn't really complete without the fix. Can you make a little time fixing it?

deekerman commented

Author

Owner

@sledgehammer999 commented on GitHub (Nov 3, 2017):

PS: #6661 will be merged just before releasing.

@DrunkenSasquatch I messed up the numbers. I meant #6484.

@sledgehammer999 commented on GitHub (Nov 3, 2017): >PS: #6661 will be merged just before releasing. @DrunkenSasquatch I messed up the numbers. I meant #6484.

deekerman commented