Re: [Development] Any supported platforms not tested in CI?
On Fri, Oct 20, 2017 at 08:14:12AM -0700, Thiago Macieira wrote: > For every architecture where the processor can run in either endianness, the > system chooses one and sticks to it, so all software is specifically compiled > for that choice. It's also encoded in the Qt sysinfo name: > > $ $QTLIBDIR/libQt5Core.t.so | head -1 > This is the QtCore library version Qt 5.10.0 (x86_64-little_endian-lp64 shared > (dynamic) debug build; by GCC 7.2.1 20171005 [gcc-7-branch revision 253439]) > > See > https://www.debian.org/releases/stable/i386/ch02s01.html.en > armel - l for little endian > mipsel - l for little endian > mips64el- l for little endian > ppc64el - l for little endian > > I'd recommend trying the mips build, though it doesn't have the "e" which I > believe stands for either "embedded" or "EABI" (where the E stands for > "embedded"). No, in Debian architecture names “el” means little endian. If you can consider running native big endian hardware for CI, then Debian’s mips architecture would work, but other good choices are s390x and ppc64. See https://wiki.debian.org/ArchitectureSpecificsMemo#Summary for the full list of Debian architectures with their endianness. -- Dmitry Shachnev signature.asc Description: PGP signature ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Any supported platforms not tested in CI?
On Wed, Oct 11, 2017 at 01:23:58PM +0200, Thiago Macieira wrote: > Are there any supported platforms that we do not test in the CI? Probably > INTEGRITY? > > [...] > > So the question is: are there any platforms that could break even after > passing the CI check? It would help us (Debian) a lot if Qt had something big endian on the CI. Currently big endian support breaks with almost every major Qt release. -- Dmitry Shachnev signature.asc Description: PGP signature ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Decrease amounth of delivered src packages
On Wed, Feb 15, 2017 at 12:28:11PM +0100, Kevin Kofler wrote: > I would kindly request you to at least use tar.xz (rather than tar.gz) for > the tarballs. (What you use as the Windows format is something you need to > sort out with the Windows people.) The fact that tar.gz is still the most > downloaded is probably mostly out of habit, or maybe your download site is > directing to them by default (which ought to be fixed anyway, even if you > were to keep both). tar.gz has no advantage over tar.xz, it is just a lot > larger. Switching to the tar.gz tarballs (from the tar.xz tarballs that are > currently used) would increase the size of distributions' source packages > (source RPM etc.) significantly. > > It is sad that the legacy gzip compression is living a renaissance due to > automatic tarball exports from GitHub and the like producing only that > format. It should finally be retired now that there are algorithms that are > just as open and that compress significantly better. At least for projects > like Qt that produce their own tarballs and are already able to produce xz- > compressed ones, I see no reason whatsoever to switch back to the obsolete > gzip. +1, please leave tar.xz instead of tar.gz. Users of all modern UNIX-like systems are able to decompress tar.xz, so .gz has really no advantage over .xz. -- Dmitry Shachnev signature.asc Description: PGP signature ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Tagging private symbols as such
Hi Thiago, On Tue, Dec 06, 2016 at 04:26:41PM -0800, Thiago Macieira wrote: > So I think it's not a good idea to apply the SUSE patch as-is. The QPA part > makes sense, though. I also dislike this change. As Lisandro says, we do not want it in Debian (because we keep track of versions ourselves in the symbols file, and when the versions are in the symbols themselves they are just useless noise for us). And as you say, you do not want distributions Qt builds to be ABI incompatible with upstream (we also would like to avoid that), so if this patch gets applied upstream, we will be in a bad situation. I wonder what was the reason for OpenSUSE to have this change — I could not find a relevant changelog entry. Why cannot they just rebuild all packages using private headers for every Qt release, like we do? > I wonder: do we want a different ELF version for the QPA bits, other than > Qt_5_PRIVATE_API? I think Qt_5_PRIVATE_API is enough. (But I won't mind if something different is used, provided that it does not change from release to release.) -- Dmitry Shachnev signature.asc Description: PGP signature ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] New library in qtbase
On Sat, Dec 03, 2016 at 12:36:48AM +0100, Kevin Kofler wrote: > I did not suggest you use the Galago software, just this specification: > https://people.gnome.org/~mccann/docs/notification-spec/notification-spec-latest.html > older versions of which were hosted on: > http://www.galago-project.org/specs/notification/ > (which is how it came to be known as the "Galago (notification) spec"). > > If you want to use an existing library, libnotify is what you are looking > for: > https://developer.gnome.org/libnotify/ It is better to re-use the existing code in qtbase, rather than relying on a 3rdparty library: https://code.qt.io/cgit/qt/qtbase.git/tree/src/platformsupport/themes/genericunix/dbustray/qxdgnotificationproxy_p.h -- Dmitry Shachnev signature.asc Description: PGP signature ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Doing a new release of qtstyleplugins?
Hi all, I sent the below mail to releasing mailing list a week ago, and got no reply. I wanted a new qtstyleplugins release so that I could package it for Debian. Is there anyone here who can make it, or would it be better for me to just package the latest Git snapshot? - My message to releasing mailing list below - Dear release team, In Qt 5.7, the GTK+ style has been moved from qtbase to qtstyleplugins [1]. However, the last released tarball of qtstyleplugins [2] is from 2014, and does not include that style yet. Can someone please generate a new tarball for the latest qtstyleplugin code and update the page linked above? For me any version number would work, and I can wait a bit in case you want that release to be synchronized with Qt 5.7.1. [1]: https://code.qt.io/cgit/qt/qtstyleplugins.git [2]: http://download.qt.io/community_releases/additional_qt_src_pkgs/ -- Dmitry Shachnev signature.asc Description: PGP signature ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Searching for a better place for dbusmenu/dbustray code
Hi all, In QTBUG-55310 [1], we have been discussing the ways on how to make it possible to use our dbusmenu/dbustray implementations on platforms which have their own platform themes (such as Plasma and LXQt). Ideally QSystemTrayIcon (and QMenuBar) should try to use these implementations if the platform themes do not provide their own ones. The first thing that comes to mind is putting this code into QtWidgets library. A side effect of this will be the QtWidgets -> QtDBus dependency, which I think is not acceptable. Currently (since [2]) this code is built as part of static QtThemeSupport library, which is then linked into the Qt5XcbQpa library and into the gtk3 theme plugin. (Another reason why this is bad is duplication of the same code between different libraries.) I propose to make it a separate plugin, linked against QtDBus, which then will be loaded by QtWidgets. In this case I have some questions (copied to here from QTBUG-55310): 1) Where will it make sense to put the plugin? Should I create a separate directory for it in plugins/? Or maybe I can put it in plugins/generic/? 2) So far the only way to load plugins I found is using QFactoryLoader. Should I use it, or is there a more simple way, provided that the plugin will be the only one of its type? If anyone can suggest an alternative to splitting that code into its own plugin, that would be welcome too. [1]: https://bugreports.qt.io/browse/QTBUG-55310 [2]: https://codereview.qt-project.org/172484 Cheers, -- Dmitry Shachnev signature.asc Description: PGP signature ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QtSingleApplication in Qt proper?
Hi all, On Thu, Jun 16, 2016 at 10:06:45AM +0200, Kevin Funk wrote: > I did not realize there are ready packages on some distributions out there. > There isn't on Ubuntu at least (which is fixable of course). > > I also just now realize that qt-solutions.git has a maintained version of > qtsingleapplication: > https://code.qt.io/cgit/qt-solutions/qt-solutions.git/log/ > qtsingleapplication > > I'd like to hear more opinions about whether there's still interest in having > it in Qt proper. There are obviously advantages to it: CI coverage (qt- > solutions.git isn't covered by CI, right?), and QtSA getting a bit of > exposure > so it does not feel like a, well, 3rdparty Qt solution. I would very much appreciate having it promoted as a proper part of Qt, either in qtbase or as a separate module. Another advantage of that will be its inclusion in bindings packages, such as PyQt. > qt-solutions.git seems a place where deprecated components are kept alive, > but > not experiencing feature development in my book. One potential problem with that code is that QtLockedFile from QtSolutions duplicates the functionality of QLockFile in qtcore (introduced in Qt 5.1). The QtSingleApplication will probably need to be ported to QLockFile instead. -- Dmitry Shachnev signature.asc Description: PGP signature ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5.7.0 beta snapshot available - gtk 3 and packaging on RHEL 6
Hi Frederik, and sorry for the late response, On Mon, Apr 11, 2016 at 04:50:18PM +0200, Frederik Gladhorn wrote: > Hello all, > > for Linux packaging we currently use a Red Hat 6 which seemed like a good > compromise at the time. > > I have been pondering https://bugreports.qt.io/browse/QTBUG-52259 for a while > and don't seem to reach a conclusion. > We had a contribution porting our gtk 2 theme to gtk 3 (thanks Dmitry!). > The question is how to proceed, from what I can tell, it's not trivial to get > gtk3 built on rhel6. > For Linux distributions this is of course not a problem, but the Qt installer > is currently built without any gtk plugin compiled. > In the future (Qt 5.8), I'd like to switch to rhel 7 as packaging platform, > so > this problem should go away. > > For Qt 5.7, the options seem to be: > 1.) ignore the problem and ship Qt packages in the installer without gtk theme > 2.) revert the patch to have the gtk2 theme for one release longer and only > have gtk3 with Qt 5.8 > 3.) package on rhel 7, but I'm told, we're already too late in the cycle > > Any ideas appreciated. In general I have a hard time seeing how to cleanly > create packages on Linux, unless we basically ship an entire distro (similar > to Chrome and others)... I'd love to learn about good approaches, since > packaging on something "old enough to run everywhere" and "new enough to > allow > all dependencies to be built" seems hard to achieve. The GTK+ platform theme is actually a plugin (the libqgtk2.so file). Maybe it can be built and/or distributed separately? The biggest issue with missing GTK+ theme one needs to be aware of is that Qt won't be able to detect the system icon theme on some environments (as that part is currently provided by the GTK+ theme). -- Dmitry Shachnev signature.asc Description: PGP signature ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Problems with QtWebKit 5.6
On Sun, 06 Mar 2016 21:45:49 +0300, Konstantin Tokarev wrote: >> 2. There is a linking error when building libQt5WebKit.so on some >> architectures >>(arm, mipsel and s390x): it reports undefined reference to pthread_*, even >>though -lpthread is present in the command line. > > This patch should help: > > https://codereview.qt-project.org/#/c/150601 Thanks a lot! How could I not notice it… -- Dmitry Shachnev signature.asc Description: OpenPGP digital signature ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Problems with QtWebKit 5.6
Hi all, I am currently packaging Qt 5.6 release candidate for Debian and I have encountered some problems with QtWebKit. 1. Looks like the tarballs were build without calling syncqt. That issue was easy to work-around and we are now calling syncqt before the build. However it would be nice to have the final tarballs built properly. 2. There is a linking error when building libQt5WebKit.so on some architectures (arm, mipsel and s390x): it reports undefined reference to pthread_*, even though -lpthread is present in the command line. I compared it with QtWebKit 5.5.1 build log and noticed that in 5.5.0 log there are 10 occurences of -lpthread in link command, however in 5.6.0 there is only one — though it's early enough (before -lWebKit1 and -lWTF). Was there some optimization in qmake that removes duplicate link flags? Can it be the reason for this issue? If yes, is there any known workaround? The build logs are available at: https://buildd.debian.org/status/package.php?p=qtwebkit-opensource-src=experimental -- Dmitry Shachnev signature.asc Description: PGP signature ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] DST breakage in qtbase
Hi, On Mon, 26 Oct 2015 12:43:48 +0100, Marc Mutz wrote: > It failed all of yesterday. Now works. Cf. e.g. > https://codereview.qt-project.org/138771 Exactly, it works now for me too. -- Dmitry Shachnev signature.asc Description: OpenPGP digital signature ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] DST breakage in qtbase
Hi all, This failure in qtbase seems to be related to today's end of DST period: * Start testing of tst_QLocale * Config: Using QtTest library 5.5.1, Qt 5.5.1 (x86_64-little_endian-lp64 shared (dynamic) release build; by Clang 6.0 (clang-600.0.54) (Apple)) FAIL! : tst_QLocale::macDefaultLocale() 'timeString.contains(expectedGMTSpecifier) || timeString.contains(expectedGMTSpecifierZeroExtended)' returned FALSE. (timeString `01:02:03 GMT+3', expectedGMTSpecifier `GMT+2' or `GMT+02') Loc: [../tst_qlocale.cpp(1474)] http://testresults.qt.io/ci/QtBase_5.5_Integration/build_02131/macx-clang_developer-build_OSX_10.9/log.txt.gz Can someone please look at that? -- Dmitry Shachnev signature.asc Description: OpenPGP digital signature ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Question about GTK+ support status
Hi J-P, On Tue, 16 Jun 2015 17:44:06 +, Nurmi J-P wrote: Given that QGtkStyle is no longer part of the public API in Qt 5, how about making it a QStylePlugin and moving it out of QtWidgets? If someone implements a style plugin for GTK+ 3, then it also becomes feasible to have platform theme plugins for both GTK+ 2 and 3. As you mentioned, a platform theme is the easy part. Implementing a QStyle for GTK+ 3.x is a lot more work. I proposed removing QGtkStyle altogether, but moving it to qtstyleplugins is also a good idea. We just need to make sure we don't load it when the platform theme is gtk3 (as one can't load gtk2 and gtk3 libraries at the same time). configure: add support for GTK+ 3.x - https://codereview.qt-project.org/#/c/75599/ QGtk3ThemePlugin - https://codereview.qt-project.org/#/c/75757/ Do we really need to keep gtk2 support in qtbase? I.e., do we really need to keep gtk2 theme if we have gtk3 theme? Also the latter patch will need some rebasing for new version and new copyrights. -- Dmitry Shachnev signature.asc Description: OpenPGP digital signature ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Question about GTK+ support status
Hi all, In Debian, we have recently removed the gtk2 platform theme from default Qt 5 installation [1], and now I start getting reports about missing icons in my Qt 5 application on Debian (currently Qt 5 supports themed icons only on KDE and when using the gtk2 platform theme). From the discussion it seemed that we can keep the platform theme around, but only if it is ported from GTK+ 2 to GTK+ 3. That task itself is not hard, but then this theme will become incompatible with QGtkStyle, which is using theming engine specific to GTK+ 2, and GTK+ 3 port does not seem possible. Looking at QGtkStyle, it not only relies on a deprecated library, but doesn't play well with default GNOME theme (Adwaita). Also, the theme authors usually do not care about GTK+ 2 anymore, and focus their efforts on a CSS theme for GTK+ 3. Also, Adwaita theme is now available in a native Qt 5 variant [2], i.e. Fedora ships it. So my question is: can we drop the QGtkStyle completely and port the gtk platform theme to GTK+ 3? I will contribute to that effort if it gets the consensus. [1]: https://bugs.debian.org/781148 [2]: https://github.com/MartinBriza/adwaita-qt -- Dmitry Shachnev signature.asc Description: OpenPGP digital signature ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Status of qtconfig
On Tue, 23 Dec 2014 16:06:51 -0200, Thiago Macieira wrote: On Tuesday 23 December 2014 16:52:51 Dmitry Shachnev wrote: Hi all, Back in 2011, there was a qttools commit (a22e38aee14419428bd5) that commented out building of qtconfig on unix systems “to make tools compile”. Almost 4 years passed since then, but we still have it disabled. My understanding is that it is easy to get it built, but it won’t work because Qt no longer reads theme settings from configuration files. Is that correct? If yes, maybe it makes sense to drop qtconfig completely from the repository? Correct and we should do it. In case someone else is interested, https://codereview.qt-project.org/102626 -- Dmitry Shachnev signature.asc Description: OpenPGP digital signature ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Status of qtconfig
Hi all, Back in 2011, there was a qttools commit (a22e38aee14419428bd5) that commented out building of qtconfig on unix systems “to make tools compile”. Almost 4 years passed since then, but we still have it disabled. My understanding is that it is easy to get it built, but it won’t work because Qt no longer reads theme settings from configuration files. Is that correct? If yes, maybe it makes sense to drop qtconfig completely from the repository? -- Dmitry Shachnev signature.asc Description: OpenPGP digital signature ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Problems pushing changes to Gerrit
Hi, On Mon, 17 Mar 2014 07:54:31 +, Andy Shaw wrote: You seem to be missing the port, if you add: :29418 After the address so it is: git push ssh://mandri...@codereview.qt-project.org:29418/qt/qt HEAD:refs/for/4.8 then does this solve the problem? No, that does not work. Actually, when it works, it works without the port number. -- Dmitry Shachnev signature.asc Description: OpenPGP digital signature ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Problems pushing changes to Gerrit
Hi, Gerrit seems to reject some of my changes with this error: $ git push ssh://mandri...@codereview.qt-project.org/qt/qt HEAD:refs/for/4.8 error: error: invalid protocol: wanted 'old new ref' fatal: internal server error fatal: The remote end hung up unexpectedly Counting objects: 30, done. Compressing objects: 100% (6/6), done. error: pack-objects died of signal 13 error: failed to push some refs to 'ssh://mandri...@codereview.qt-project.org/qt/qt' For example, today I successfully pushed a change to qtmultimedia, but failed to push a change to qt4. Some weeks ago I got a similar problem with qtwebkit, but resolved this by pushing from a different machine. Now I get this error from two different machines (with different SSH keys), one running Ubuntu and one running Debian GNU/Linux. Retrying from a fresh Git tree, adding different port numbers or URI schemes does not help. Does anybody know what may cause this behavior? Kind regards, -- Dmitry Shachnev signature.asc Description: OpenPGP digital signature ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt patches to support AArch64 architecture
Hi, On Fri, 14 Mar 2014 14:27:27 -0700, Thiago Macieira wrote: Ah, this is Qt 4, where we got the arch from uname. What is reported on Qt 5? I think this is the relevant part: |Configure summary | | Build type:linux-g++ (unknown, CPU features:) ... which means that some detection code is still missing. The full build log is here (for Qt 5.2.1): https://launchpadlibrarian.net/168953728/buildlog_ubuntu-trusty-arm64.qtbase-opensource-src_5.2.1%2Bdfsg-1ubuntu7_UPLOADING.txt.gz -- Dmitry Shachnev signature.asc Description: OpenPGP digital signature ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Qt patches to support AArch64 architecture
Lars: this mail needs your attention. Hi, AArch64 is a new 64-bit ARM architecture, that will be used in a big range of devices, from servers to iPhones. See this Wikipedia article for details: https://en.wikipedia.org/wiki/ARM_architecture#64.2F32-bit_architecture In Debian/Ubuntu, we have been working to enable AArch64 (aka ARM64) support for Qt packages. We would like to forward those patches upstream. Please see https://bugs.debian.org/735488 for the full discussion and https://bugs.debian.org/cgi-bin/bugreport.cgi?msg=200;bug=735488 for the patches. We understand that these patches might be seen as a new feature for Qt4, but the reality is that they will get applied on all distributions wanting to support arm64, so it's better to have them upstreamed. Let me describe the current situation and patches briefly: **Patches already applied in Git**: [qtbase] https://qt.gitorious.org/qt/qtbase/commit/410e9cd5b1a6eb87 (basic detection) [qtscript] https://qt.gitorious.org/qt/qtscript/commit/2e049836ee16f4ae (JavaScriptCore support) **Cherry-pick waiting for approval**: [qt4] https://codereview.qt-project.org/79602 (JavaScriptCore support) **Marcin Juszkiewicz’s patches (licensed under either Public Domain or BSD)**: [qt4] basic-aarch64-detection.patch [done differently to what was done in qtbase] [qt4] mkspecs.patch (mkspecs for qt4) [qtbase and qt4] syscalls.patch (inotify syscalls numbers) **Mark Salter’s patch (licensed under BSD)**: [qt4] qatomic.patch (atomics for qt4) The first issue comes with Marcin’s and Mark’s patches. They are RedHat employees, and they cannot sign the CLA. So we asked them to put the patches under a license which could enable us to merge the patches upstream. Marcin agreed to license his patches under CC0 (aka Public Domain) or simply BSD licensed [0], and Mark under the BSD license [1]. [0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=735488#179 [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=735488#195 The second issue is that Qt may require, only for arm64, -fpermissive to build. This could mean that something is not really finished, but it will get certainly ironed out with some time. Finally we Debian maintainers are not able to verify the patches ourselves *yet*, as we don’t have access to porterboxes. So far only Debian arm64 porters have access. Non the less, patches are already applied in Ubuntu (and most probably Red Hat too, as the patches come from them), and the current Qt 4 packages built fine there. If you want testers for the patches, try asking Marcin or Wookey (CCed), they should be able to help you. I am going to submit the missing patches to Gerrit if you have nothing against that. Kind regards, -- Dmitry Shachnev (on behalf on Debian Qt maintainers) signature.asc Description: OpenPGP digital signature ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Extra link flags in QMAKE_PRL_LIBS
Hi,
In Debian/Ubuntu, we received some bug reports ([1], [2], [3]) stating
that compiling QtWebKit apps fails with ld errors like this one:
/usr/bin/ld: cannot find -lgstapp-0.10
/usr/bin/ld: cannot find -lgstinterfaces-0.10
...
After digging the problem, we found out that the reason is .prl files,
especially libQt5WebKitWidgets.prl which has this line (see [4]):
QMAKE_PRL_LIBS = -lX11 -lxslt -lgio-2.0 -lgstapp-0.10 -lgstinterfaces-0.10
[...]
I think it is wrong because none of QtWebKit public headers refers to
xslt or gstreamer.
Is it a bug in qmake, and if yes, can it be fixed or should we change our .prl
files downstream?
A similar issue is in libQt5Multimedia{,Widgets}.prl files, which have -lpulse
flag.
Also, some files have multiple occurences of the same flag, i.e.
libQt5WebKit.prl has -lpthread flag 6 times.
[1]: http://bugs.debian.org/711307
[2]: https://bugs.launchpad.net/bugs/1134745
[3]: https://bugs.launchpad.net/bugs/1165250
[4]: http://paste.debian.net/27129/
signature.asc
Description: OpenPGP digital signature
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
