KDE CI: Frameworks » solid » kf5-qt5 FreeBSDQt5.15 - Build # 32 - Failure!

[CI System]

BUILD FAILURE
 Build URL
https://build.kde.org/job/Frameworks/job/solid/job/kf5-qt5%20FreeBSDQt5.15/32/
 Project:
kf5-qt5 FreeBSDQt5.15
 Date of build:
Wed, 02 Dec 2020 06:18:27 +
 Build duration:
25 sec and counting
   CONSOLE OUTPUT
  [...truncated 562 lines...][2020-12-02T06:18:51.805Z] [ 70%] Building CXX object src/solid/CMakeFiles/KF5Solid.dir/fstab_debug.cpp.o[2020-12-02T06:18:52.068Z] [ 70%] Building CXX object src/solid/CMakeFiles/KF5Solid.dir/devices/backends/udisks2/udisksmanager.cpp.o[2020-12-02T06:18:52.334Z] [ 71%] Building CXX object src/solid/CMakeFiles/KF5Solid.dir/devices/backends/udisks2/udisksdevice.cpp.o[2020-12-02T06:18:52.334Z] [ 71%] Building CXX object src/solid/CMakeFiles/KF5Solid.dir/devices/backends/udisks2/udisksdevicebackend.cpp.o[2020-12-02T06:18:52.334Z] [ 72%] Building CXX object src/solid/CMakeFiles/KF5Solid.dir/devices/backends/udisks2/udisksblock.cpp.o[2020-12-02T06:18:52.334Z] [ 72%] Building CXX object src/solid/CMakeFiles/KF5Solid.dir/devices/backends/udisks2/udisksstoragevolume.cpp.o[2020-12-02T06:18:52.334Z] /usr/home/jenkins/workspace/Frameworks/solid/kf5-qt5 FreeBSDQt5.15/src/solid/devices/backends/fstab/fstabstorageaccess.cpp:104:43: error: use of undeclared identifier 'EBUSY'[2020-12-02T06:18:52.334Z] } else if (process->exitCode() == EBUSY) {[2020-12-02T06:18:52.334Z]   ^[2020-12-02T06:18:52.334Z] /usr/home/jenkins/workspace/Frameworks/solid/kf5-qt5 FreeBSDQt5.15/src/solid/devices/backends/fstab/fstabstorageaccess.cpp:106:43: error: use of undeclared identifier 'EPERM'[2020-12-02T06:18:52.334Z] } else if (process->exitCode() == EPERM) {[2020-12-02T06:18:52.334Z]   ^[2020-12-02T06:18:52.597Z] [ 73%] Building CXX object src/solid/CMakeFiles/KF5Solid.dir/devices/backends/udisks2/udisksdeviceinterface.cpp.o[2020-12-02T06:18:52.597Z] [ 73%] Building CXX object src/solid/CMakeFiles/KF5Solid.dir/devices/backends/udisks2/udisksopticaldisc.cpp.o[2020-12-02T06:18:52.597Z] 2 errors generated.[2020-12-02T06:18:52.597Z] gmake[2]: *** [src/solid/CMakeFiles/KF5Solid.dir/build.make:913: src/solid/CMakeFiles/KF5Solid.dir/devices/backends/fstab/fstabstorageaccess.cpp.o] Error 1[2020-12-02T06:18:52.597Z] gmake[2]: *** Waiting for unfinished jobs[2020-12-02T06:18:53.159Z] /usr/home/jenkins/workspace/Frameworks/solid/kf5-qt5 FreeBSDQt5.15/src/solid/devices/backends/udisks2/udisksdevice.cpp:302:26: warning: 'trUtf8' is deprecated [-Wdeprecated-declarations][2020-12-02T06:18:53.159Z] second = trUtf8("/DVD��R DL", "Second item of %1%2 Drive sentence");[2020-12-02T06:18:53.159Z]  ^[2020-12-02T06:18:53.159Z] /usr/home/jenkins/workspace/Frameworks/solid/kf5-qt5 FreeBSDQt5.15/src/solid/devices/backends/udisks2/udisksdevice.h:31:5: note: 'trUtf8' has been explicitly marked deprecated here[2020-12-02T06:18:53.159Z] Q_OBJECT[2020-12-02T06:18:53.159Z] ^[2020-12-02T06:18:53.159Z] /usr/local/include/qt5/QtCore/qobjectdefs.h:178:5: note: expanded from macro 'Q_OBJECT'[2020-12-02T06:18:53.159Z] QT_TR_FUNCTIONS \[2020-12-02T06:18:53.159Z] ^[2020-12-02T06:18:53.159Z] /usr/local/include/qt5/QtCore/qobjectdefs.h:134:5: note: expanded from macro 'QT_TR_FUNCTIONS'[2020-12-02T06:18:53.159Z] QT_DEPRECATED static inline QString trUtf8(const char *s, const char *c = nullptr, int n = -1) \[2020-12-02T06:18:53.159Z] ^[2020-12-02T06:18:53.159Z] /usr/local/include/qt5/QtCore/qglobal.h:292:25: note: expanded from macro 'QT_DEPRECATED'[2020-12-02T06:18:53.159Z] #  define QT_DEPRECATED Q_DECL_DEPRECATED[2020-12-02T06:18:53.159Z] ^[2020-12-02T06:18:53.159Z] /usr/local/include/qt5/QtCore/qcompilerdetection.h:227:45: note: expanded from macro 'Q_DECL_DEPRECATED'[2020-12-02T06:18:53.159Z] #  define Q_DECL_DEPRECATED __attribute__ ((__deprecated__))[2020-12-02T06:18:53.159Z] ^[2020-12-02T06:18:53.159Z] /usr/home/jenkins/workspace/Frameworks/solid/kf5-qt5 FreeBSDQt5.15/src/solid/devices/backends/udisks2/udisksdevice.cpp:304:26: warning: 'trUtf8' is deprecated [-Wdeprecated-declarations][2020-12-02T06:18:53.159Z] second = trUtf8("/DVD��R", "Second item of %1%2 Drive sentence");[2020-12-02T06:18:53.159Z]  ^[2020-12-02T06:18:53.159Z] /usr/home/jenkins/workspace/Frameworks/solid/kf5-qt5 FreeBSDQt5.15/src/solid/devices/backends/udisks2/udisksdevice.h:31:5: note: 'trUtf8' has been explicitly marked deprecated here[2020-12-02T06:18:53.159Z] Q_OBJECT[2020-12-02T06:18:53.159Z] ^[2020-12-02T06:18:53.159Z] /usr/local/include/qt5/QtCore/qobjectdefs.h:178:5: note: expanded from macro 'Q_OBJECT'[2020-12-02T06:18:53.159Z] QT_TR_FUNCTIONS \[2020-12-02T06:18:53.159Z] ^[2020-12-02T06:18:53.159Z] /usr/local/include/qt5/QtCore/qobjectdefs.h:134:5: note: expanded from macro 

Re: Would distributions have an issue if KF 5.77+ would require Qt >= 5.14 (instead of >= 5.13 as of now)?

[Bernhard Rosenkraenzer]

On Tuesday, December 01, 2020 13:13 CET, "Friedrich W. H. Kossebau" 
 wrote:

> QUESTION:
> Would any of the distributions have an issue with requiring Qt 5.14 instead of
> Qt 5.13?

For OpenMandriva, no problem, we're on 5.15.2 on all branches that will get 
5.77.

ttyl
bero

KDE CI: Frameworks » kio » kf5-qt5 FreeBSDQt5.15 - Build # 357 - Still Unstable!

[CI System]

BUILD UNSTABLE
 Build URL
https://build.kde.org/job/Frameworks/job/kio/job/kf5-qt5%20FreeBSDQt5.15/357/
 Project:
kf5-qt5 FreeBSDQt5.15
 Date of build:
Tue, 01 Dec 2020 20:13:32 +
 Build duration:
9 min 21 sec and counting
   JUnit Tests
  Name: projectroot Failed: 2 test(s), Passed: 56 test(s), Skipped: 0 test(s), Total: 58 test(s)Failed: projectroot.autotests.applicationlauncherjob_scopetestFailed: projectroot.autotests.kiocore_jobtestName: projectroot.autotests Failed: 0 test(s), Passed: 6 test(s), Skipped: 0 test(s), Total: 6 test(s)Name: projectroot.src.ioslaves.trash Failed: 0 test(s), Passed: 1 test(s), Skipped: 0 test(s), Total: 1 test(s)Name: projectroot.src.kpasswdserver Failed: 0 test(s), Passed: 1 test(s), Skipped: 0 test(s), Total: 1 test(s)

Re: Would distributions have an issue if KF 5.77+ would require Qt >= 5.14 (instead of >= 5.13 as of now)?

[Nicolas Fella]

Hi,

with my KDE Android hat on this would be fine, we use Qt 5.15. For KDE's
own Windows/Mac builds I'd expect it to be similar.

What most/all not-traditional-Linux-distro users have in common is that
they are not bound to the specific Qt version decided and shipped by a
vendor and instead either build themselves or download official binaries.

The two major "distributions" that are potential frameworks users but
can't because of Qt versions (SailfishOS and Ubuntu Touch) don't ship
5.13 either, so it doesn't make the problem worse.

Cheers

Nico


On 12/1/20 1:29 PM, Jonathan Riddell wrote:

Not from KDE neon of course, we're on 5.15.  And not from the KDE
snaps build either.  But I suppose there's more than just Linux
distros to consider as we ship apps using KDE frameworks on Flatpak,
Android, Windows, even Mac to ponder too.

Jonathan


On Tue, 1 Dec 2020 at 12:14, Friedrich W. H. Kossebau
mailto:kosse...@kde.org>> wrote:

Hi,

last week KDE Frameworks master saw a bump in the
required/expected minimal Qt
version to Qt 5.13, following rules once agreed and noted here:
https://community.kde.org/Frameworks/Policies#Frameworks_Qt_requirements


I would like to challenge that former decision though and propose
to instead
go straight to Qt 5.14 as minimum requirement now.


QUESTION:
Would any of the distributions have an issue with requiring Qt
5.14 instead of
Qt 5.13?


From some quick checks using https://repology.org/
 it seems that any
distribution versions which currently use Qt 5.13 have also
settled on some
older KF version, so will not update to just KF 5.77 and thus be
screwed.

Motivation:
* KDE CI not setup ATM to cover builds with Qt 5.13 (no build, no
unit tests)
* Qt 5.14 added some new API, chance to miss out when using that
in new code
* C++: no need to write #if QT_VERSION < QT_VERSION_CHECK(5, 14,
0) variants
* QML: no need to do hard-to-read generation tricks to support <
Qt 5.14
* Qt 5.13 went out-of-support in June
* App bundle builders would rather use some recent Qt 5.14/5.15

So by restraining to Qt 5.13 as minimum version IMHO we would
make/keep life
complicated for KF contributors without adding any value for anyone.

With most of KDE Frameworks in my local checkout:
    grep "QT_VERSION_CHECK(5, 14, 0)"  frameworks/*/src -r
2>/dev/null | \
        grep "QT_VERSION " | wc -l
gives me "92", so there are quite some code variants which need
support in
current code.

From the emails at least in
https://mail.kde.org/pipermail/kde-frameworks-devel/2020-July/112712.html

I could not see a discussion whether Qt 5.13 makes
sense at all now, seems mainly the algorithm was applied. I
propose to match
the result to known real world needs now. Or teach me what I have
missed here
:)

Cheers
Friedrich

Re: Would distributions have an issue if KF 5.77+ would require Qt >= 5.14 (instead of >= 5.13 as of now)?

[Jonathan Riddell]

Not from KDE neon of course, we're on 5.15.  And not from the KDE snaps
build either.  But I suppose there's more than just Linux distros to
consider as we ship apps using KDE frameworks on Flatpak, Android, Windows,
even Mac to ponder too.

Jonathan


On Tue, 1 Dec 2020 at 12:14, Friedrich W. H. Kossebau 
wrote:

> Hi,
>
> last week KDE Frameworks master saw a bump in the required/expected
> minimal Qt
> version to Qt 5.13, following rules once agreed and noted here:
> https://community.kde.org/Frameworks/Policies#Frameworks_Qt_requirements
>
> I would like to challenge that former decision though and propose to
> instead
> go straight to Qt 5.14 as minimum requirement now.
>
>
> QUESTION:
> Would any of the distributions have an issue with requiring Qt 5.14
> instead of
> Qt 5.13?
>
>
> From some quick checks using https://repology.org/ it seems that any
> distribution versions which currently use Qt 5.13 have also settled on
> some
> older KF version, so will not update to just KF 5.77 and thus be screwed.
>
> Motivation:
> * KDE CI not setup ATM to cover builds with Qt 5.13 (no build, no unit
> tests)
> * Qt 5.14 added some new API, chance to miss out when using that in new
> code
> * C++: no need to write #if QT_VERSION < QT_VERSION_CHECK(5, 14, 0)
> variants
> * QML: no need to do hard-to-read generation tricks to support < Qt 5.14
> * Qt 5.13 went out-of-support in June
> * App bundle builders would rather use some recent Qt 5.14/5.15
>
> So by restraining to Qt 5.13 as minimum version IMHO we would make/keep
> life
> complicated for KF contributors without adding any value for anyone.
>
> With most of KDE Frameworks in my local checkout:
> grep "QT_VERSION_CHECK(5, 14, 0)"  frameworks/*/src -r 2>/dev/null | \
> grep "QT_VERSION " | wc -l
> gives me "92", so there are quite some code variants which need support in
> current code.
>
> From the emails at least in
> https://mail.kde.org/pipermail/kde-frameworks-devel/2020-July/112712.html
> I could not see a discussion whether Qt 5.13 makes
> sense at all now, seems mainly the algorithm was applied. I propose to
> match
> the result to known real world needs now. Or teach me what I have missed
> here
> :)
>
> Cheers
> Friedrich
>
>
>

Would distributions have an issue if KF 5.77+ would require Qt >= 5.14 (instead of >= 5.13 as of now)?

[Friedrich W. H. Kossebau]

Hi,

last week KDE Frameworks master saw a bump in the required/expected minimal Qt 
version to Qt 5.13, following rules once agreed and noted here:
https://community.kde.org/Frameworks/Policies#Frameworks_Qt_requirements

I would like to challenge that former decision though and propose to instead 
go straight to Qt 5.14 as minimum requirement now.


QUESTION:
Would any of the distributions have an issue with requiring Qt 5.14 instead of 
Qt 5.13?


>From some quick checks using https://repology.org/ it seems that any 
distribution versions which currently use Qt 5.13 have also settled on some 
older KF version, so will not update to just KF 5.77 and thus be screwed.

Motivation:
* KDE CI not setup ATM to cover builds with Qt 5.13 (no build, no unit tests)
* Qt 5.14 added some new API, chance to miss out when using that in new code
* C++: no need to write #if QT_VERSION < QT_VERSION_CHECK(5, 14, 0) variants
* QML: no need to do hard-to-read generation tricks to support < Qt 5.14
* Qt 5.13 went out-of-support in June
* App bundle builders would rather use some recent Qt 5.14/5.15

So by restraining to Qt 5.13 as minimum version IMHO we would make/keep life 
complicated for KF contributors without adding any value for anyone.

With most of KDE Frameworks in my local checkout:
grep "QT_VERSION_CHECK(5, 14, 0)"  frameworks/*/src -r 2>/dev/null | \
grep "QT_VERSION " | wc -l
gives me "92", so there are quite some code variants which need support in 
current code.

>From the emails at least in 
>https://mail.kde.org/pipermail/kde-frameworks-devel/2020-July/112712.html I 
>could not see a discussion whether Qt 5.13 makes 
sense at all now, seems mainly the algorithm was applied. I propose to match 
the result to known real world needs now. Or teach me what I have missed here 
:)

Cheers
Friedrich

KDE CI: Frameworks » kio » kf5-qt5 FreeBSDQt5.15 - Build # 356 - Still Unstable!

[CI System]

BUILD UNSTABLE
 Build URL
https://build.kde.org/job/Frameworks/job/kio/job/kf5-qt5%20FreeBSDQt5.15/356/
 Project:
kf5-qt5 FreeBSDQt5.15
 Date of build:
Tue, 01 Dec 2020 09:27:40 +
 Build duration:
5 min 0 sec and counting
   JUnit Tests
  Name: projectroot Failed: 1 test(s), Passed: 57 test(s), Skipped: 0 test(s), Total: 58 test(s)Failed: projectroot.autotests.kiocore_jobtestName: projectroot.autotests Failed: 0 test(s), Passed: 6 test(s), Skipped: 0 test(s), Total: 6 test(s)Name: projectroot.src.ioslaves.trash Failed: 0 test(s), Passed: 1 test(s), Skipped: 0 test(s), Total: 1 test(s)Name: projectroot.src.kpasswdserver Failed: 0 test(s), Passed: 1 test(s), Skipped: 0 test(s), Total: 1 test(s)