Possibility of backporting Qt bug fixes

Platform Development
#1

One of my applications (Sailfin) is freezing due a deadlock within Qt caused by QTBUG-76157. This has been fixed with a patch in several Qt versions above 5.12.5. I’ve modified and applied this patch to the Jolla branch of Qt myself. This solves the freezing for my application and somehow I managed to do apply this patch to a core system component without soft bricking my phone :slight_smile:

Anyhow, are there any chances that such bug fixes from the upstream Qt repository could be backported to the Jolla branch? I’ve heard rumours about it not being possible due to licensing issues with the newer Qt versions and the fact that OpenSSL 1.1 on the Jolla branch has been implemented in a different way than in the upstream Qt versions supports this rumour.

A Qt upgrade to a Qt version that fixes this and other bugs, such as 5.12.5, would be even better, but I’ve seen people asking about it since I started using Sailfish OS. I expect the answer to that request to be the same as the answer given to all the people who’ve requested it before me.

2 Likes
#2

Indeed, patches are protected by the same licenses as the code itself and newer Qt licensing seems to be an issue with Jolla.

Depending on the size of the patch and your willingness to rewrite it, you can submit a PR to sailfishos/qtbase. I’ve done it already, for instance : [qtbase] Fix QDateTime::toString() timezone info. Contributes to JB#5… · sailfishos/qtbase@74afde0 · GitHub

That’s a boring situation :-/

2 Likes
#3

I’d be willing to rewrite it. I had to rewrite it for the patch anyway, since quite a bit has changed between Qt 5.6 and Qt 5.12 in qtnetwork. However, the patch is not trivial and I have seen the actual changes that Qt made. The patch that I would write would be influenced by that code, even if I would not look at Qt’s newer code from now on. I’m not sure if that’s allowed by the licence and copyright law. Neither do I know what Jolla’s policies are on this matter.

Alternatively, I could wait 70 years or so for the copyright on the source code to expire :wink:

3 Likes
#4

Well, as far as I understand the full topic, ideas cannot be copyrighted (at least in Europe). It’s their implementations that are (there is no software patents but there are copyrights on written productions). I don’t see any issue in reading a copyrighted code, understanding it’s intent and reimplementing it, as long as there will be no copy-pasting in the process. Well, that’s my personal interpretation. I guess layers may diverge on the matter.

As far as I know, Jolla sailors may not complain on your PR as long as there is no copy-pasting (copying by hand can be considered as a bad implementation of copy-pasting in that regard).

2 Likes
#5

As a small status update on the patch: I don’t expect being able to get working on the patch any time before July. I’m still interested in working on it, although I just haven’t got the time at the moment.

1 Like
#6

I’ve been wanting to look at the network stack. since 4.x (I believe it was 4.1) some apps have suffered from intermittent issues with network. A c++ app like SailHN has issues, the python app for hacker news has less issues. Too mee it looks like a substantial regression from 3.4. The proof is still lacking.

1 Like
#7

ditto. Summer means camping with kids… racing at me …

1 Like
Effective use of menus in Qt applications on Sailfish OS
#8

A post was split to a new topic: Effective use of menus in Qt applications on Sailfish OS

#9

Update: I finished my patch and have sent it to GitHub for code review: https://github.com/sailfishos/qtbase/pull/11

6 Likes
#10

Did you rework your patch? From what I see the upstream solution differs quite much.
For instance in some areas like adding Qt → SSL Wrappers there’s no other way than adding the same code as upstream since the wrappers work the same in all Qt versions so far.

#11

The pull request I made is the reworked patch. I had a copy-paste patch that worked, but I threw it away when I heard of the licensing issues.

As I mentioned in today’s IRC-meeting as Chris[m]123—apparently, the IRC bridge didn’t follow my Matrix room specific nickname—, I looked up which OpenSSL functions are used in the upstream patch to set the extra data and I noted that down. Afterwards, I wrote the reworked patch from scratch with the notes.

Of course it is inevitable in some areas that the code might look similar to the Qt upstream patch, such as in the Qt →SSL wrappers as you mentioned. I also used the same approach as the upstream patch in Qt: instead of using locks to guard a list of SSL errors, attach the errors to the X509_STORE or SSL struct as user data.

1 Like
#12

That sounds good, I’ll forward this internally.
I’m not exactly sure which way is better without looking into this deeper, I’m thinking one or the other way maybe work better (e.g. in booster).

How far are you making this work with apps running with the boosters?

1 Like
#13

Update: please read the post below. The information below is no longer relevant.
I haven´t looked into checking what is the exact cause yet, I only know that it somehow doesn’t work with the booster.

I tested it with a small test application that I wrote: https://github.com/HenkKalkwater/harbour-badssl. It connects to a few subdomains of badssl.com and lists the errors that occurred. Then it either shows the domain in green, if the list of occurred errors matches the list of expected errors, or red, if it doesn’t match.

When launching the application from the terminal using harbour-badssl all tests pass as expected.

When launching the application from the launcher or by running invoker --type=qt5 --desktop-file=/usr/share/applications/harbour-badssl.desktop harbour-badssl from the terminal, the tests which expect at least 1 SSL error fail.

There are no crashes or whatsoever, it just doesn’t work.

EDIT: I see that I forgot to add the internet permission to the harbour-badssl sailjail configuration. That might be the cause of the issue.

1 Like
#14

It was indeed a problem of not adding the internet permission to the harbour-badssl.desktop file. Silly me blaming everything on the booster.

This means that it works just fine as far as I know and others may have a look at it.

2 Likes
#15

Forwarded your update.

2 Likes
#16

Please also update Github.

1 Like
#17

I have updated the code of the sample application on GitHub already and the pull request is done as well. Or did I perhaps forget something?

1 Like