Qt5 everywhere. Drop legacy Qt4 support.

[dragotin]

It would be very beneficial if we could build against Qt5 on all platforms that we support. That is no problem for MacOSX and Windows as we have to ship with the Qt. However on Linux, where we want to depend on the upstream packages, we need to double check. From which versions of the distros are Qt5 packages available in the main repositories?

Distro	first (supported) version that provides Qt5	has Webkit
openSUSE	openSUSE 13.1, before in other repo	yes
Fedora	?
Ubuntu	14.04 LTS provides Qt5-default, earlier?
Debian	?
CentOS 6/7	Qt 5.4 via EPEL	yes

Also, do the version provide Webkit?

https://github.com/owncloud/client/wiki/Qt-5-Dependency-on-Linux

[jriddell]

14.04 is indeed the first one in Ubuntu to have it
https://launchpad.net/ubuntu/+source/qtbase-opensource-src

Debian has it only in backports for their stable wheeze release (Debian 7)
It is in testing jesse which is expected to become stable in the next few months.
https://packages.debian.org/search?keywords=qtbase-opensource-src&searchon=sourcenames&suite=all&section=all

[hefee]

On debian I built occ since 1.6 with qt5, so everything is available to build and run occ on debian with qt5. Unfortuatelly there is a bug with the systray:

• https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=755350 or With certain Linux Desktops: Systray icon bug #2123 that make me shipping occ for testing with qt4 again.
  For this bug no solution is on the horizon ( only for plasma5) so gnome an lxde users won't be happy :)

[rullzer]

On Gentoo Qt5 is in the portage tree. However it is not marked stable yet.

[AdamWill]

Fedora seems to have had qt5 since at least F17, which is no longer supported (F19 is the oldest currently-supported release). It also seems to have been added to EPEL6 and EPEL7; that is, it's not a part of the core RH-supported RHEL repos (and hence CentOS), but the Fedora-maintained EPEL repositories. There are mirall packages in Fedora but not EPEL.

Note I'm not the maintainer of mirall, you can find the info on who maintains it at https://admin.fedoraproject.org/pkgdb/package/mirall/ .

[guruz]

I wonder what size a statically linked Mirall would have on Linux.

[dragotin]

@guruz which is not what we want, as it means we would have to maintain it. People are using Linux because they think that they have maintained libs by their distributor.

[ogoffart]

People are using Linux because they think that they have maintained libs by their distributor.

These people are using the binaries packaged by their distribution.

[guruz]

Yes, please get all those technology-scared Linux users to a newer Qt version.

Another nice reason for using Qt5: We can use the function pointer signal slot syntax..

http://woboq.com/blog/new-signals-slots-syntax-in-qt5.html

Would easily fix issues as
b0dbb49 12ac9f9 803cb5d

[dragotin]

For the upcoming 1.8.0 client: packages for openSUSE starting with 13.2 now build against Qt5. In 13.1 it uses Qt 5.3.x and thus neon is still required, but in Factory there (currently) is Qt 5.4.0 and we can build without neon.

Please help testing the packages from https://software.opensuse.org/download.html?project=isv%3AownCloud%3Acommunity%3Anightly&package=owncloud-client if possible.

If other distros have Qt5 packages in their default repositories available I am happy to integrate patches into our build service projects.

[dragotin]

Fedora 21 is also building against Qt5.

[danimo]

I have an experimental OBS build for CentOS 7 (soon 6) that depends on EPEL for Qt 5.4.

I'm looking for testers and input.

[danimo]

@moscicki Can you run this solution (Client on CentOS/SCL requiring EPEL) past your deployment guys? It would allow us to jump to Qt 5.

[moscicki]

@danimo: no problem, it would help us to get the CentOS 6 build to test first. Is that available already?

Also, please check with @dragotin and @jnweiger : our Linux team have prepared the "proper" (based on the mechanism of Software Collection) packaging scheme which will allow you to install the sync client in the completely standard and canonical way on Redhat-based systems. In particular the alternative versions of software which otherwise would collide with the baseline versions of software installed in the OS. They provided RPMs for 1.7 client. To be integrated with your OBS builds (I hope). Do you have feedback on this?

[jaroslawp]

As a part of that Linux team: I would be interested in the feedback too (client packaged as @moscicki desribed is there: http://linuxsoft.cern.ch/tmp/owncloud-client/)

[jnweiger]

@jaroslawp Thanks for your detailled description!
The URL is down today. I have saved a copy here:
https://s3.owncloud.com/owncloud/public.php?service=files&t=dcd3c210435abcfda90b08aa45a84f92&download

[jaroslawp]

that URL is back again, sorry. (scheduled intervention ..)

[danimo]

@jaroslawp That's very cool actually. Going the SC route is the next logical step. Also our own SC would allow putting patching Qt to adopt it to our needs without bothering the system. This is something we already do for Windows and Mac OS on several occasions, even though we try to avoid it as much as possible. So thanks for doing that!

At the same time, I wonder how much work it would be to have an SC including Qt5 (which is a bit more complex to package). Have you looked into that?The good part is that it's already in EPEL, so an SC would "only" have to fork those packages and keep them in sync with upstream. On the upside, when adopting Qt from EPEL in the SC, we could lose neon and its dependencies. I think that's quite a benefit.

[jaroslawp]

@danimo: I should have some time to look at this (Qt5) next week, will keep you updated !

[guruz]

Also relevant for HiDPI #2558

[jnweiger]

When you say 1315 that made me curious. It should be 133x or so.
Here is what they did: Not exactly nice:

OS	%{suse_version}	%{is_opensuse}
openSUSE_13.1	suse_version = 1310	is_opensuse = '%{is_opensuse}'
openSUSE_13.2	suse_version = 1320	is_opensuse = '%{is_opensuse}'
openSUSE_Factory	suse_version = 1330	is_opensuse = 1
openSUSE_Leap_42.1	suse_version = 1315	is_opensuse = 1
SLE_12	suse_version = 1315	is_opensuse = '%{is_opensuse}'

The upgade from 13.2 to leap 42 has a non-monotonic change in suse_version.

[jnweiger]

Building 2.2.4 owncloud-client for Ubuntu 14.04 with Qt-5.2.1 here:

• https://build.opensuse.org/package/show/isv:ownCloud:desktop:qt5deb/owncloud-client

Is this vulnerable to file corruptions?

[michaelstingl]

A user reported about their oC client for Ubuntu 14.04:

Qt4 network libraries don't work with our F5 load balancer

@guruz @crrodriguez What could be the solution there?

[ogoffart]

Is [Qt-5.2.1] vulnerable to file corruptions?

Yes it is, but Qt 4.8 is even worse, so no regressions there.

Qt4 network libraries don't work with our F5 load balancer, What could be the solution there?

The package built with Qt5.

[ShalokShalom]

I guess this can be closed?

[guruz]

@ShalokShalom No, we're still supporting Qt 4 currently. We'll probably drop that next year. On Linux we use the system packages which sometimes are still based on Qt4.

[ShalokShalom]

Qt4 itself gets no maintenance anymore?

[moscicki]

Is this vulnerable to file corruptions?

This sounds very worrying. Could someone please elaborate what it means?

[ogoffart]

@moscicki: the corruption bug you investigated was fixed in Qt 5.4.2 only. However we are working around it in the client by forcing connection reset with older version of Qt, so file corruption should not happen normally.

[guruz]

Qt4 itself gets no maintenance anymore?

Qt4 is EOL by The Qt Company as far as I know.

so file corruption should not happen normally.

...plus we send checksums to CernBox.

[ShalokShalom]

Qt4 is EOL by The Qt Company as far as I know.

Thats what i mean. Is it safe, since that?

[jaroslawp]

@ShalokShalom : guess depends where from you take it (on RHEL7/CentOS7 we get qt 4.8.5 from Red Hat / CentOS: and according to their policies that version will be supported - including security fixes - still for quite long time - more than a few years until support for 7 will be over)

[ShalokShalom]

I see.

[guruz]

Superseded by #5470

[jnweiger]

See also https://bugreports.qt.io/browse/QTBUG-31762

[vladimiroff]

Now that Qt4 is no longer supported it might be worth removing those checks if QT_VERSION is 4.x.

--> grep -r "QT_VERSION [<=>]* QT_VERSION_CHECK(4" ./client 
5

[michaelstingl]

@vladimiroff ==> 2.3.1 (see #5470)