v4.2.2 is going to be released #12214
Conversation
It should remain disabled by default. Anyone that needs to Queue torrents for seeding/downloading should go to settings and change it to their preference.
Closes qbittorrent#8772. This will fix issue that "Free space on disk:" label in Add New Torrent dialog not updated on Category change when Torrent Management Mode is on Auto mode.
Windows only. Closes qbittorrent#9592
Not all flags displayed strictly belong to countries.
- CheckingMemUsageSize (16 MiB -> 32 MiB): a 16 MiB increase in memory consumption seems worthwhile for a nice performance boost in most cases. - DiskCacheSize (64 MiB -> Auto): auto yields the best performance without committing to a huge fixed value. - UseRandomPort (false -> true): The initial port chosen by qBittorrent may clash with something else the user already has that is aways using that port (low probability, but still). Thus, qBittorrent will always fail listening on that port, causing unexpected problems for the user. Users who know they want a fixed port will go to the settings anyway.
Closes qbittorrent#11724. Option is enabled by default for users using qBittorrent's built-in HTTPS capabilities. This flag will never be set if qBittorrent is using plain HTTP. Users using HTTPS reverse proxies, like "qbt <-> (http) <-> proxy <-> (https) <-> user" should override the flag in the proxy in order to set it, if they wish to do so.
Fixup 8200ef6 Remove "Listen on IPv6 address" option.
Don't sync main data if a request to do so is already in progress. This prevents piling up of requests and bogging down slow/busy machines, since the current implementation of `/api/v2/sync/maindata` is very computationally intensive, especially with lots of torrents. Everything gets updated on the next scheduled request anyway (via the timeout mechanism).
Model returns string for DisplayRole. Text alignment is set by Model (using TextAlignmentRole). Delegate performs custom painting only where necessary (i.e. for Progress bar).
|
#11735 still has UDP/Proxy issues it seems even with libtorrent 1.2.5 |
Despite this I think we should still release 4.2.2 + libtorrent >=1.2.5 ASAP. Not all issues are fixed, but there are many others that are. It is better to just release and fix problems for most users, and then later release the fix for the remaining problems, than to keep everybody waiting. @sledgehammer999 After the release of 4.2.2 the existing Proxy/UDP issues thread should probably be closed, and the discussion continued on a new one. Maybe post a message like "4.2.2 should fix most of these issues. If you still have problems with this version, post in the new thread ". |
|
Minor update: The release is delayed for a half a day to one day. I had some trouble updating the libtorrent package for ubuntu and updating the macosx toolchain. I took sometime to work things out. |
In light of #12229 (comment), if I understand it correctly, we will really need to remove the usage of strict_superseeding until the next release. |
|
Yes if you build with deprecated functions off then the build would fail. |
@sledgehammer999 |
|
Support for the deprecated functions only serves to facilitate the transition from the previous libtorrent branch. Now that qBittorrent is fully compatible with the libtorrent-1.2 native API, we should never build it with |
|
@glassez However if one build & link statically (like our windows binary) or restrict the PPA libtorrent package for qbt-only usage, then perhaps we can have |
|
yes it would prevent users from downgrading to older versions with non deprecated functions. Like after 4.2.2 gets released you won’t be able to use previously released libtorrent packages for downgrade. |
Users will have to downgrade libtorrent package too. |
|
I mean you can’t have qbt 4.2.2 from ppa with libtorrent rasterbar9 for example. Qbt 4.2.2 would be dependent on latest libtorrent build provided by ppa/repo. |
👍
Well, maybe I'm just wrong... if qBittorrent still uses the native API, even if libtorrent is built with deprecated functions, then there is no problem. |
Why would this be desirable? IMO this just enables some user to accidentally do that and run into weird bugs. PPA is for basic end-user usage. |
I don't think there was ever a guarantee that the PPA's libtorrent package was a generic package for all cases. If someone needed that, they should use a PPA that has the sole purpose of providing libtorrent packages for general usage. The libtorrent version available in the PPA is almost never a stable version either, just the commit revision that's most convenient for usage in qBittorrent. In addition, historically it was even more specific to our use case (the I really don't think anyone installs the qBIttorrent PPA with the expectation they are getting an as-vanilla-as-possible libtorrent distribution for general use in development or other purpose. I agree with @glassez that we should turn it off, at least in the CI. |
|
A quick note before my eventual release: Yesterday I updated both PPAs with disabled deprecated functions. |
AFAIK that is exactly what you would expect by setting |
|
Turning off deprecated functions when building libtorrent may break the stable ABI-intention within minor versions. So, in order to stay maximally compatible, it's best to distribute libtorrent builds with deprecated functions enabled. (and I also think it makes sense to build qBT with deprecated functions disabled in CI, or at least periodically transition away from old APIs). For example, Given that the only function returning this type has been excluded from builds without deprecated functions, in practice this is most likely not a problem though. Most deprecation changes, preserve ABI (in practice). For example, strict super seeding mode will be deprecated in libtorrent-1.2.6. In a build where deprecated functions are still included, the |
I'm not familiar with debian/ubuntu packages so I could be wrong. AFAIK the libtorrent package from PPA overwrites the ones from debian/ubuntu official repo. As a result, this gets in the way of the user from using other torrent clients (the ones based on libtorrent). |
It is only desirable in CI situation. It isn't a desirable situation when you want make a release and can't because of that.
Exactly! Maybe the true solution to our conundrum is to make a 3rd PPA that will be for the CI and have disabled deprecated funtions. And maybe have it auto-import libtorrent-git-RC_1_2. ** Ideally we could also introduce a package with a different name on the same PPA that will have disabled deprecated functions. But I am not very familiar with debian packaging to make it happen that way. |
You're right...
We don't need a PPA for that (PPAs in general are a bit of a mess, I think it's best to avoid having more if possible). CI's can directly import from git and can have arbitrary configurations for building libtorrent on a standard ubuntu system. |
We don't want to build libtorrent everytime our CI wants to test a pr/commit. |
Fair point, perhaps we could use github actions for that then? |
Idk. Maybe they would do that for testing purposes. Like sometimes things break in new versions and they might wanna test out an older package. Btw @sledgehammer999 just to note, an0n666 and An0n is the same person. Idk why you use usernames in some place and nicks in another(in changelog). Makes it look like different persons. |
Don't know how sledge is the generating the changelogs, but probably some automated script that extracts git metadata such as commit message + |
|
Oh I get it now. Previously didn’t have a nick. So probably my username was taken from those commit metadata. |
|
FYI a first draft of the changelog is generated with this command: then I adjust it further by hand. |
|
There is a problem with Transifix in Japanese. I abandoned the editorial war. 4.2.2 was released without fixing the problem. More info: #11921 |
This is a pseudo-PR. It will not be merged. Read below.
Currently I have cherry-picked everything from master into v4_2_x.
If not, then v4.2.2 will be released until Monday.
I'll wait on #12213. Also the only other changes I plan to do is version bumps and translation syncs from Transifex.
As far as I can tell the WEBAPI version has been bumped already. It doesn't seem to need a major version bump. @Piccirello @FranciscoPombal can you confirm?
Also @Piccirello @FranciscoPombal @Kolcha when cherry-picking I noticed some "auto merging" messages from git concerning WebUI commits. Can you test this particular branch to see if things work correctly on the WebUI part? I want to minimize the chance that automerge screwed things up code wise.