KDE in core-updates

KDE in core-updates

[Andreas Enge]

KDE fails on core-updates due to a test error in kwayland:

FAIL!  : PlasmaWindowModelTest::testChangeWindowAfterModelDestroy(icon) 'changedSpy.wait()' returned FALSE. ()
   Loc: [/tmp/guix-build-kwayland-5.98.0.drv-0/kwayland-5.98.0/autotests/client/test_plasma_window_model.cpp(916)]
The following tests FAILED:
         26 - kwayland-testPlasmaWindowModel (Failed)
Errors while running CTest
make: *** [Makefile:74: test] Error 8

Test suite failed, dumping logs.
error: in phase 'check': uncaught exception:
%exception #<&invoke-error program: "make" arguments: ("test") exit-status: 2 term-signal: #f stop-signal: #f>
phase `check' failed after 109.0 seconds
command "make" "test" failed with status 2
builder for `/gnu/store/crbmfw5w5s2h7y5k9zvvfn5crk5rs9lw-kwayland-5.98.0.drv' failed with exit code 1
build of /gnu/store/crbmfw5w5s2h7y5k9zvvfn5crk5rs9lw-kwayland-5.98.0.drv failed
View build log at '/var/log/guix/drvs/cr/bmfw5w5s2h7y5k9zvvfn5crk5rs9lw-kwayland-5.98.0.drv.gz'.

Difficult to analyse...

Andreas

Re: KDE in core-updates

[Andreas Enge]

And another undebuggable (?) failure, this time for qtbase:

Total Test time (real) = 544.95 sec

The following tests FAILED:
	354 - tst_qsslkey (Failed)
Errors while running CTest
error: in phase 'check': uncaught exception:
%exception #<&invoke-error program: "xvfb-run" arguments: ("ctest" "--output-on-failure" "-j" "4" "-E" "(tst_moc|tst_rcc|tst_qtemporarydir|tst_qtemporaryfile|tst_qdir|tst_qresourceengine|tst_qfilesystemwatcher|mockplugins|test_plugin_flavor.*|test_import_plugins|tst_qtimezone|tst_qdatetime|tst_qsettings|tst_qaddpreroutine|test_generating_cpp_exports|test_static_resources|tst_qfile|tst_qglyphrun|tst_qx11info|tst_qgraphicswidget|tst_qdnslookup|tst_qcompleter|tst_qfiledialog)") exit-status: 8 term-signal: #f stop-signal: #f>
phase `check' failed after 545.4 seconds
command "xvfb-run" "ctest" "--output-on-failure" "-j" "4" "-E" "(tst_moc|tst_rcc|tst_qtemporarydir|tst_qtemporaryfile|tst_qdir|tst_qresourceengine|tst_qfilesystemwatcher|mockplugins|test_plugin_flavor.*|test_import_plugins|tst_qtimezone|tst_qdatetime|tst_qsettings|tst_qaddpreroutine|test_generating_cpp_exports|test_static_resources|tst_qfile|tst_qglyphrun|tst_qx11info|tst_qgraphicswidget|tst_qdnslookup|tst_qcompleter|tst_qfiledialog)" failed with status 8
builder for `/gnu/store/qbxz60vhhbshl823ajir2zjgz0lp8wcm-qtbase-6.3.1.drv' failed with exit code 1
build of /gnu/store/qbxz60vhhbshl823ajir2zjgz0lp8wcm-qtbase-6.3.1.drv failed
View build log at '/var/log/guix/drvs/qb/xz60vhhbshl823ajir2zjgz0lp8wcm-qtbase-6.3.1.drv.gz'.

Andreas

Re: KDE in core-updates

[Ludovic Courtès]

Hi,

Andreas Enge <andreas@enge.fr> skribis:

> And another undebuggable (?) failure, this time for qtbase:
>
> Total Test time (real) = 544.95 sec
>
> The following tests FAILED:
> 	354 - tst_qsslkey (Failed)
> Errors while running CTest

CTest produces log files for test suites.  I forgot the exact file name
but it should be findable in the build tree with a ‘--keep-failed’
build.

That doesn’t mean it’ll be easy of course.  :-)

Given the test name, one would hope that it’s the usual time bomb of an
expired X.509 certificate.

Ludo’.

Re: Qt in core-updates (was: KDE in core-updates)

[Andreas Enge]

Am Sat, Feb 25, 2023 at 07:19:15PM +0100 schrieb Ludovic Courtès:
> Given the test name, one would hope that it’s the usual time bomb of an
> expired X.509 certificate.

Apparently not, just some strange handling of openssl@3; if I understand
correctly, these tests are expected to fail and should be skipped.
I may have found a solution that entails switching from Qt 6.3.1 to 6.3.2
and applying a patch. Does anyone know whether it is possible to just
increase the version of qtbase, while keeping all others at 6.3.1?
Or do we need to keep in lockstep even with patch level versions?

In any case, I realised that we are still compiling most packages (including
KDE) with Qt 5, which is seriously outdated (not maintained any more in the
free version since May 2021). Qt 6.3 support will end in April 2023,
that of the current version Qt 6.4 in September 2023. So we have the work
carved out for a (yet to be created) Qt/KDE team.

Andreas

Re: Qt in core-updates (was: KDE in core-updates)

[Philip McGrath]

[-- Attachment #1: Type: text/plain, Size: 1737 bytes --]

Hi,

On Sunday, February 26, 2023 7:44:20 AM EST Andreas Enge wrote:
> 
> In any case, I realised that we are still compiling most packages (including
> KDE) with Qt 5, which is seriously outdated (not maintained any more in the
> free version since May 2021). Qt 6.3 support will end in April 2023, that
> of the current version Qt 6.4 in September 2023. So we have the work carved
> out for a (yet to be created) Qt/KDE team.
> 

Note that KDE maintains a patch collection for Qt 5.15:
https://community.kde.org/Qt5PatchCollection

There was an announcement here:
https://dot.kde.org/2021/04/06/announcing-kdes-qt-5-patch-collection

Patches are exclusively backports of bugfixes that have already been committed 
to upstream Qt 6, except that patches for Qt 5.15 components removed in Qt 6 
are also accepted. The patches are curated by a small group of KDE developers 
who also have commit privileges in the upstream Qt Project (as distinct from 
the Qt Company).

I think out Qt 5 packages should be based on the KDE patch collection.

The patches are maintained in Git repositories with the same structure as 
upstream Qt. They could be extracted with `git format-patch v5.15.3-lts-
lgpl..origin/kde/5.15` and added to "gnu/packages/patches/", or we could just 
change the origins for Qt 5 to point to KDE's repositories, e.g. this one for 
qt-base: https://invent.kde.org/qt/qt/qtbase/-/tree/kde/5.15

Most KDE stuff can build against Qt 6, but it will continue targeting Qt 5.15 
until KDE Frameworks 6 and Plasma 6 are released (maybe as soon as the end of 
this year?).

I'm not a Qt or C++ developer, but I'm a long-time KDE user, and I'm really 
excited that people have been working to get KDE into Guix: thank you!

-Philip

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Qt in core-updates (was: KDE in core-updates)

[kiasoc5]

On 2/26/23 18:43, Philip McGrath wrote:
> Hi,
> 
> On Sunday, February 26, 2023 7:44:20 AM EST Andreas Enge wrote:
>>
>> In any case, I realised that we are still compiling most packages (including
>> KDE) with Qt 5, which is seriously outdated (not maintained any more in the
>> free version since May 2021). Qt 6.3 support will end in April 2023, that
>> of the current version Qt 6.4 in September 2023. So we have the work carved
>> out for a (yet to be created) Qt/KDE team.
>>
> 
> Note that KDE maintains a patch collection for Qt 5.15:
> https://community.kde.org/Qt5PatchCollection
> 
> There was an announcement here:
> https://dot.kde.org/2021/04/06/announcing-kdes-qt-5-patch-collection
> 
> Patches are exclusively backports of bugfixes that have already been committed
> to upstream Qt 6, except that patches for Qt 5.15 components removed in Qt 6
> are also accepted. The patches are curated by a small group of KDE developers
> who also have commit privileges in the upstream Qt Project (as distinct from
> the Qt Company).
> 
> I think out Qt 5 packages should be based on the KDE patch collection.
> 
> The patches are maintained in Git repositories with the same structure as
> upstream Qt. They could be extracted with `git format-patch v5.15.3-lts-
> lgpl..origin/kde/5.15` and added to "gnu/packages/patches/", or we could just
> change the origins for Qt 5 to point to KDE's repositories, e.g. this one for
> qt-base: https://invent.kde.org/qt/qt/qtbase/-/tree/kde/5.15

The KDE patchset moves quickly and does not have tagged releases. If 
that proves difficult we could also just bump the QT5 version to 5.15.8, 
which is freely available.

Re: Qt in core-updates (was: KDE in core-updates)

[Efraim Flashner]

[-- Attachment #1: Type: text/plain, Size: 2198 bytes --]

On Sun, Feb 26, 2023 at 09:38:43PM -0500, kiasoc5 wrote:
> On 2/26/23 18:43, Philip McGrath wrote:
> > Hi,
> > 
> > On Sunday, February 26, 2023 7:44:20 AM EST Andreas Enge wrote:
> > > 
> > > In any case, I realised that we are still compiling most packages (including
> > > KDE) with Qt 5, which is seriously outdated (not maintained any more in the
> > > free version since May 2021). Qt 6.3 support will end in April 2023, that
> > > of the current version Qt 6.4 in September 2023. So we have the work carved
> > > out for a (yet to be created) Qt/KDE team.
> > > 
> > 
> > Note that KDE maintains a patch collection for Qt 5.15:
> > https://community.kde.org/Qt5PatchCollection
> > 
> > There was an announcement here:
> > https://dot.kde.org/2021/04/06/announcing-kdes-qt-5-patch-collection
> > 
> > Patches are exclusively backports of bugfixes that have already been committed
> > to upstream Qt 6, except that patches for Qt 5.15 components removed in Qt 6
> > are also accepted. The patches are curated by a small group of KDE developers
> > who also have commit privileges in the upstream Qt Project (as distinct from
> > the Qt Company).
> > 
> > I think out Qt 5 packages should be based on the KDE patch collection.
> > 
> > The patches are maintained in Git repositories with the same structure as
> > upstream Qt. They could be extracted with `git format-patch v5.15.3-lts-
> > lgpl..origin/kde/5.15` and added to "gnu/packages/patches/", or we could just
> > change the origins for Qt 5 to point to KDE's repositories, e.g. this one for
> > qt-base: https://invent.kde.org/qt/qt/qtbase/-/tree/kde/5.15
> 
> The KDE patchset moves quickly and does not have tagged releases. If that
> proves difficult we could also just bump the QT5 version to 5.15.8, which is
> freely available.

This is something we should probably do anyway.

We should also try to keep qtwebengine patched as much as possible,
since it is a web engine :)

-- 
Efraim Flashner   <efraim@flashner.co.il>   אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Qt in core-updates (was: KDE in core-updates)

[Andreas Enge]

Hello Philip, Kiasoc5, Efraim,

thanks a lot for your input!

Indeed I got my information that Qt 5 was phased out from Wikipedia,
which mentioned May 2021 as the end of support. I did not expect there
to be more versions! But then discovered the 5.15.8 version, probably
related to the commercial support available until May this year?

Anyway, I updated in my own branch wip-andreas-core-updates (since I wanted
to avoid rebuilding core-updates with its recent world-rebuilding changes);
just qtwebengine takes 6 hours on my laptop... (And it required the update,
since it would not build at version 5.15.5.) Now I am trying to build all
the Qt packages before applying the patch to core-updates; it looks good
so far.

Andreas

Re: Qt in core-updates

[Andreas Enge]

In the context of security problems and package removal, I just noticed
(by "./pre-inst-env guix package -A ^qt") that we still have a qtwebkit
package. The latest release dates from 2020, and this also the last
release, if I understand correctly that the project has been abandoned.

However:
Building the following 31 packages would ensure 43 dependent packages are rebuilt: kdewebkit@5.98.0 psi@1.5 lmms@1.2.2 python-pymol@2.5.0 hplip@3.22.4 toutenclic@7.00 cura@4.13.1 electron-cash@4.2.12 trezor-agent@0.14.4 electrum@4.3.2 frescobaldi@3.1.3 flyer-composer@1.0rc2 rapid-photo-downloader@0.9.18 asymptote@2.84 python-woob@3.0 orange@3.32.0 pyzo@4.12.4 offlate@0.6.1 qgis@3.26.2 openmolar@1.0.15-gd81f9e5 autokey@0.95.10 nanovna-saver@0.5.3 qspectrumanalyzer@2.1.0 gnss-sdr@0.0.17 gqrx@2.15.9 urh@2.9.3 python-setools@4.4.0 plover@4.0.0.dev12 manuskript@0.14.0 dream@2.2 aseba@1.6.0-0.3b35de8

So it looks like there is some work ahead to update or remove these packages.

Andreas

Re: Qt in core-updates

[Andreas Enge]

Am Tue, Feb 28, 2023 at 04:13:52PM +0100 schrieb Andreas Enge:
> Now I am trying to build all
> the Qt packages before applying the patch to core-updates; it looks good
> so far.

It went well with all the qt* packages.

Then python-pyqt-without-qtwebkit fails already in its configure phase,
hopefully an easily solved problem.

Andreas

Re: Qt in core-updates

[Leo Famulari]

Qtwebkit has been removed from the master branch.

On Tue, Feb 28, 2023, at 13:09, Andreas Enge wrote:
> Am Tue, Feb 28, 2023 at 04:13:52PM +0100 schrieb Andreas Enge:
>> Now I am trying to build all
>> the Qt packages before applying the patch to core-updates; it looks good
>> so far.
>
> It went well with all the qt* packages.
>
> Then python-pyqt-without-qtwebkit fails already in its configure phase,
> hopefully an easily solved problem.
>
> Andreas

Re: Qt in core-updates

[Andreas Enge]

Am Tue, Feb 28, 2023 at 01:20:08PM -0500 schrieb Leo Famulari:
> Qtwebkit has been removed from the master branch.

Oh right, I even remember now that you sent messages about it.
Maybe it is time to merge master back into core-updates?

(Although the problem here seems to be unrelated to webkit, it already
occurs for compiling the flavour of python-pyqt *without* webkit.)

Andreas

Re: Qt in core-updates

[Andreas Enge]

Am Tue, Feb 28, 2023 at 09:51:49PM +0100 schrieb Andreas Enge:
> Maybe it is time to merge master back into core-updates?

Where the vague "it is time to" could be read as "could you please?".
It is something I have never done, so it makes me nervous. Well, I suppose
I could just merge and try to fix the merge conflicts?

Andreas

Re: Qt in core-updates

[Andreas Enge]

Am Tue, Feb 28, 2023 at 09:55:28PM +0100 schrieb Andreas Enge:
> Am Tue, Feb 28, 2023 at 09:51:49PM +0100 schrieb Andreas Enge:
> > Maybe it is time to merge master back into core-updates?
> Where the vague "it is time to" could be read as "could you please?".
> It is something I have never done, so it makes me nervous. Well, I suppose
> I could just merge and try to fix the merge conflicts?

Well, I gave it a try, and it seems to be okay. So far I pushed it as a
separate branch, wip-andreas-merge. It does compile. If you agree, I
could also push it to core-updates (assuming that merge commits can be
pushed just like every other commit; I am a bit doubtful what happens if
someone else pushes other commits in the meantime; probably then I will
have to merge a second time, to core-updates, instead of just pushing
there?).

Andreas

Re: Qt in core-updates

[Andreas Enge]

Am Wed, Mar 01, 2023 at 12:54:04AM +0100 schrieb Andreas Enge:
> Well, I gave it a try, and it seems to be okay.

I spake too fast. Somehow I took samba/fixed from core-updates instead
of samba/pinned from master, and since I do not quite follow which is what,
I will give up and let someone else figure it out... I am too afraid of
making security relevant wrong choices here or incidentally downgrading
packages by choosing the wrong version.

Anyway, I still think it would be good to merge master into core-updates,
to get rid of (qt)webkit, and thus to advance on pyqt and consorts.
Thanks!

Andreas

Re: KDE in core-updates

[Andreas Enge]

A quick update on KDE in core-updates:

kcodecs also fails

I tried to update extra-cmake-files and kwayland to the next version 5.99,
which also forced me to update plasma-wayland-protocols to 1.9.0.
But then kwayland shows three test failures instead of one...

The latest KDE version is 5.104, so we could try to update further,
but I did not have time to pursue the tests for the time being.
If someone would like to have a look, that would be most welcome.

Andreas