Hello,

KDE packages used to build fine on the Hurd port.

Since recently, we have started seeing this build error:

“
Your current platform 'GNU' is not supported. The list of supported
platorms is 'Linux;FreeBSD;Windows;macOS;Android'.If you think this is a
mistake or you are working on enabling the platform please build with the
KF_IGNORE_PLATFORM_CHECK variable set to true
”

We have tried to make kde add the Hurd in the list of supported
platforms, but they'd only do it if there is active support with CI
setup etc., see:

https://invent.kde.org/frameworks/extra-cmake-modules/-/merge_requests/294

I wonder what debian KDE maintainers' position is: would it be fine
to just make debian/rules with KF_IGNORE_PLATFORM_CHECK set for some
platforms? Or add the platform in extra-cmake-modules and add the
supported platform as a patch in the packages?

Samuel

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi Samuel!

Explicitly CCing Aurélien who is the c-e-m maintainer.

On Sun, 4 Sept 2022 at 17:18, Samuel Thibault
<[email protected]> wrote:

Hello,

KDE packages used to build fine on the Hurd port.

Since recently, we have started seeing this build error:

“
Your current platform 'GNU' is not supported. The list of supported
platorms is 'Linux;FreeBSD;Windows;macOS;Android'.If you think this is a
mistake or you are working on enabling the platform please build with the
KF_IGNORE_PLATFORM_CHECK variable set to true
”

We have tried to make kde add the Hurd in the list of supported
platforms, but they'd only do it if there is active support with CI
setup etc., see:

https://invent.kde.org/frameworks/extra-cmake-modules/-/merge_requests/294

I wonder what debian KDE maintainers' position is: would it be fine
to just make debian/rules with KF_IGNORE_PLATFORM_CHECK set for some platforms? Or add the platform in extra-cmake-modules and add the
supported platform as a patch in the packages?

Well, Hurd is a non-official arch, so I guess a patch in
extra-cmake-modules could be added and you will have to deal with
FTBFSs, etc. Is that suitable for you?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Le 9 septembre 2022 18:41:34 GMT+02:00, "Lisandro Damián Nicanor Pérez Meyer" <[email protected]> a écrit :

Hi Samuel!

Explicitly CCing Aurélien who is the c-e-m maintainer.

On Sun, 4 Sept 2022 at 17:18, Samuel Thibault
<[email protected]> wrote:

Hello,

KDE packages used to build fine on the Hurd port.

Since recently, we have started seeing this build error:

[…]

I wonder what debian KDE maintainers' position is: would it be fine
to just make debian/rules with KF_IGNORE_PLATFORM_CHECK set for some
platforms? Or add the platform in extra-cmake-modules and add the
supported platform as a patch in the packages?

Well, Hurd is a non-official arch, so I guess a patch in
extra-cmake-modules could be added and you will have to deal with
FTBFSs, etc. Is that suitable for you?

Yes, we quickly discussed this with Samuel over IRC and I said I was supportive of the idea.
I still wanted to have some more input from the team so here I have at least one bit. :-)

Besides FTBFS in Debian I insisted with Samuel that the porters have a minimal interest in following up Hurd related bug reports that may end-up in the upstream bugtracker as a consequence of our patch.

The main reason stated upstream for not accepting the patch is that they don't want to have to deal with bug reports for platforms for which they don't do CI and don't have porter knowledge. The last thing we want is to load them with the consequences of
our own choices that they explicitly declined to follow. That could easily be perceived as a hostile move from us.


Happy hacking !
--
Aurélien

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hello,

Lisandro Damián Nicanor Pérez Meyer, le ven. 09 sept. 2022 13:41:34 -0300, a ecrit:

Well, Hurd is a non-official arch, so I guess a patch in
extra-cmake-modules could be added and you will have to deal with
FTBFSs, etc. Is that suitable for you?

Aurélien COUDERC, le ven. 09 sept. 2022 21:42:57 +0200, a ecrit:

Yes, we quickly discussed this with Samuel over IRC and I said I was supportive of the idea.
I still wanted to have some more input from the team so here I have at least one bit. :-)

Besides FTBFS in Debian I insisted with Samuel that the porters have a minimal interest in following up Hurd related bug reports that may end-up in the upstream bugtracker as a consequence of our patch.

The main reason stated upstream for not accepting the patch is that they don't want to have to deal with bug reports for platforms for which they don't do CI and don't have porter knowledge. The last thing we want is to load them with the consequences

of our own choices that they explicitly declined to follow. That could easily be perceived as a hostile move from us.


Err, well, yes for sure, just like we've been doing it in the past
years?

I mean, before the "supported list" feature got introduced in kde,
packages were building fine or not, and we'd submit patches to fix them
when not. There is no reason for us to change this habit, and there is
no reason for bugreports to appear upstream without a proposed patch, at
least not more than what happened in the past years. Perhaps upstream
doesn't realize that kde has been building fine on the Hurd for years
before this, and thus there is no actual "move" here?

Samuel

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Aurélien COUDERC, le dim. 11 sept. 2022 21:59:17 +0200, a ecrit:

But I for one wasn't aware of your work getting fixes upstream so that's really good to know !

We didn't have to add many of them, since KDE is mostly very portable,
and GNU/Hurd is very close to GNU/Linux (same toolchain).

As I understand it if someone stepped up to add a CI pipeline upstream for Hurd there are good chances that the patch would get accepted.

Mmm. That'd mean a hurd-based CI. I don't know if invent.kde.org would
be happy to use an external runner that we'd host? (we can surely sets
this up, just like we do for exim for instance).

If all goes well the change will land in Frameworks 5.98 which should reach in Debian in a not too distant future. :-)

Great :-)

Samuel

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Dear Samuel,

Le 11 septembre 2022 18:46:48 GMT+02:00, Samuel Thibault <[email protected]> a écrit :

Hello,

The main reason stated upstream for not accepting the patch is that they don't want to have to deal with bug reports for platforms for which they don't do CI and don't have porter knowledge. The last thing we want is to load them with the consequences

of our own choices that they explicitly declined to follow. That could easily be perceived as a hostile move from us.

Err, well, yes for sure, just like we've been doing it in the past
years?

I mean, before the "supported list" feature got introduced in kde,
packages were building fine or not, and we'd submit patches to fix them
when not. There is no reason for us to change this habit, and there is
no reason for bugreports to appear upstream without a proposed patch, at >least not more than what happened in the past years. Perhaps upstream
doesn't realize that kde has been building fine on the Hurd for years
before this, and thus there is no actual "move" here?

I won't agree with your conclusion.
Upstream decided to add a feature to split OSes between supported and unsupported, and we're about to revert that in Debian for one of the unsupported OSes.

But I for one wasn't aware of your work getting fixes upstream so that's really good to know ! As I understand it if someone stepped up to add a CI pipeline upstream for Hurd there are good chances that the patch would get accepted.

And I'm still supportive of the change in Debian anyway as I already wrote.

If all goes well the change will land in Frameworks 5.98 which should reach in Debian in a not too distant future. :-)


Happy hacking !
--
Aurélien

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi Samuel & Hurd porters,

Le 11 septembre 2022 22:40:59 GMT+02:00, Samuel Thibault <[email protected]> a écrit :

Aurélien COUDERC, le dim. 11 sept. 2022 21:59:17 +0200, a ecrit:

If all goes well the change will land in Frameworks 5.98 which should reach in Debian in a not too distant future. :-)

Great :-)

I've integrated the patch from the MR on invent.kde.org [0] into our package [1].

But it doesn't work : [2].

Inputs welcome.

[0] https://invent.kde.org/frameworks/extra-cmake-modules/-/merge_requests/294 [1] https://salsa.debian.org/qt-kde-team/kde/extra-cmake-modules/-/commit/8f09959402c6c732c677c9ff59fb678a6402b3ef
[2] https://buildd.debian.org/status/package.php?p=karchive


Happy hacking !
--
Aurélien

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hello,

Aurélien COUDERC, le mar. 20 sept. 2022 13:03:58 +0200, a ecrit:

Le 11 septembre 2022 22:40:59 GMT+02:00, Samuel Thibault <[email protected]> a écrit :

Aurélien COUDERC, le dim. 11 sept. 2022 21:59:17 +0200, a ecrit:

If all goes well the change will land in Frameworks 5.98 which should reach in Debian in a not too distant future. :-)

Great :-)

I've integrated the patch from the MR on invent.kde.org [0] into our package [1].

Thanks!

But it doesn't work : [2].

Each package now has to explicitly add Hurd to the list of supported OS
in metainfo.yaml:

--- a/metainfo.yaml
+++ b/metainfo.yaml
@@ -5,6 +5,7 @@ type: functional
platforms:
- name: Linux
- name: FreeBSD
+ - name: Hurd
- name: Windows
- name: macOS
- name: Android

Samuel

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi,

Le 20 septembre 2022 15:09:08 GMT+02:00, Samuel Thibault <[email protected]> a écrit :

Hello,

Aurélien COUDERC, le mar. 20 sept. 2022 13:03:58 +0200, a ecrit:

Le 11 septembre 2022 22:40:59 GMT+02:00, Samuel Thibault <[email protected]> a écrit :

Aurélien COUDERC, le dim. 11 sept. 2022 21:59:17 +0200, a ecrit:

If all goes well the change will land in Frameworks 5.98 which should reach in Debian in a not too distant future. :-)

Great :-)

I've integrated the patch from the MR on invent.kde.org [0] into our package [1].

Thanks!

But it doesn't work : [2].

Each package now has to explicitly add Hurd to the list of supported OS
in metainfo.yaml:

Ouch !
That's 83 Frameworks source packages, 51 Plasma, however many Gears…

I didn't have that in mind and I'm not doing it.

MRs welcome.


Happy hacking !
--
Aurélien

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Aurélien COUDERC, le mar. 20 sept. 2022 15:23:04 +0200, a ecrit:

Le 20 septembre 2022 15:09:08 GMT+02:00, Samuel Thibault <[email protected]> a écrit :

Each package now has to explicitly add Hurd to the list of supported OS
in metainfo.yaml:

Ouch !
That's 83 Frameworks source packages, 51 Plasma, however many Gears…

I didn't have that in mind and I'm not doing it.

I can understand that indeed...

I'm thinking: perhaps we can patch extra-cmake-modules to take KF_IGNORE_PLATFORM_CHECK as an environment variable, as attached, and I
can easily make the hurd buildd define it to ON?

Samuel

--- KDEMetaInfoPlatformCheck.cmake.orig 2022-09-20 20:10:41.000000000 +0000
+++ KDEMetaInfoPlatformCheck.cmake 2022-09-20 20:11:21.000000000 +0000
@@ -19,6 +19,9 @@
#]=======================================================================]

option(KF_IGNORE_PLATFORM_CHECK "Ignore the supported platform check against metainfo.yaml" OFF)
+if ($ENV{KF_IGNORE_PLATFORM_CHECK} STREQUAL "ON")
+ set(KF_IGNORE_PLATFORM_CHECK ON)
+endif()

if (NOT "${KF_IGNORE_PLATFORM_CHECK}")
file(STRINGS metainfo.yaml MetaInfoContents)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hello,

Samuel Thibault, le mar. 20 sept. 2022 22:12:46 +0200, a ecrit:

Aurélien COUDERC, le mar. 20 sept. 2022 15:23:04 +0200, a ecrit:

Le 20 septembre 2022 15:09:08 GMT+02:00, Samuel Thibault <[email protected]> a écrit :

Each package now has to explicitly add Hurd to the list of supported OS >in metainfo.yaml:

Ouch !
That's 83 Frameworks source packages, 51 Plasma, however many Gears…

I didn't have that in mind and I'm not doing it.

I can understand that indeed...

I'm thinking: perhaps we can patch extra-cmake-modules to take KF_IGNORE_PLATFORM_CHECK as an environment variable, as attached, and I
can easily make the hurd buildd define it to ON?

So how does it look like as a solution? That only requires a very simple
patch in extra-cmake-modules, and setting the environment variable on
the buildds will enable building all kde packages.

Samuel

--- KDEMetaInfoPlatformCheck.cmake.orig 2022-09-20 20:10:41.000000000 +0000
+++ KDEMetaInfoPlatformCheck.cmake 2022-09-20 20:11:21.000000000 +0000
@@ -19,6 +19,9 @@
#]=======================================================================]

option(KF_IGNORE_PLATFORM_CHECK "Ignore the supported platform check against metainfo.yaml" OFF)
+if ($ENV{KF_IGNORE_PLATFORM_CHECK} STREQUAL "ON")
+ set(KF_IGNORE_PLATFORM_CHECK ON)
+endif()

if (NOT "${KF_IGNORE_PLATFORM_CHECK}")
file(STRINGS metainfo.yaml MetaInfoContents)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Le 4 octobre 2022 00:41:04 GMT+02:00, Samuel Thibault <[email protected]> a écrit :

Hello,

Dear Samuel,

Samuel Thibault, le mar. 20 sept. 2022 22:12:46 +0200, a ecrit:

Aurélien COUDERC, le mar. 20 sept. 2022 15:23:04 +0200, a ecrit:

Le 20 septembre 2022 15:09:08 GMT+02:00, Samuel Thibault <[email protected]> a écrit :

Each package now has to explicitly add Hurd to the list of supported OS >> > >in metainfo.yaml:

Ouch !
That's 83 Frameworks source packages, 51 Plasma, however many Gears…

I didn't have that in mind and I'm not doing it.

I can understand that indeed...

I'm thinking: perhaps we can patch extra-cmake-modules to take
KF_IGNORE_PLATFORM_CHECK as an environment variable, as attached, and I
can easily make the hurd buildd define it to ON?

So how does it look like as a solution? That only requires a very simple >patch in extra-cmake-modules, and setting the environment variable on
the buildds will enable building all kde packages.

No objection from my side.

I'm working on the next Plasma for now so an MR is welcome if want it quick. Otherwise I would add that as part of Frameworks 5.99 that is also around the corner, but only once Plasma 5.26 is behind.


Hally hacking !
--
Aurélien

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Aurélien COUDERC, le mar. 04 oct. 2022 01:03:12 +0200, a ecrit:

Le 4 octobre 2022 00:41:04 GMT+02:00, Samuel Thibault <[email protected]> a écrit :

Samuel Thibault, le mar. 20 sept. 2022 22:12:46 +0200, a ecrit:

Aurélien COUDERC, le mar. 20 sept. 2022 15:23:04 +0200, a ecrit:

Le 20 septembre 2022 15:09:08 GMT+02:00, Samuel Thibault <[email protected]> a écrit :

Each package now has to explicitly add Hurd to the list of supported OS >> > >in metainfo.yaml:

Ouch !
That's 83 Frameworks source packages, 51 Plasma, however many Gears… >> >
I didn't have that in mind and I'm not doing it.

I can understand that indeed...

I'm thinking: perhaps we can patch extra-cmake-modules to take
KF_IGNORE_PLATFORM_CHECK as an environment variable, as attached, and I
can easily make the hurd buildd define it to ON?

So how does it look like as a solution? That only requires a very simple >patch in extra-cmake-modules, and setting the environment variable on
the buildds will enable building all kde packages.

No objection from my side.

I'm working on the next Plasma for now so an MR is welcome if want it quick.

Here it is:

https://salsa.debian.org/qt-kde-team/kde/extra-cmake-modules/-/merge_requests/11

Samuel

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hello,

Sune Stolborg Vuorela, le mar. 20 sept. 2022 20:37:20 +0200, a ecrit:

Consider applying the following instead:

diff --git a/kde-modules/KDEMetaInfoPlatformCheck.cmake b/kde-modules/ KDEMetaInfoPlatformCheck.cmake
index c02cfff0..49af1aab 100644
--- a/kde-modules/KDEMetaInfoPlatformCheck.cmake
+++ b/kde-modules/KDEMetaInfoPlatformCheck.cmake
@@ -70,6 +70,6 @@ if (NOT "${KF_IGNORE_PLATFORM_CHECK}")
endforeach()

if (NOT _MetainfoFoundSupportedPlatform)
- message(FATAL_ERROR "Your current platform '${CMAKE_SYSTEM_NAME}' is not supported. The list of supported platorms is '$ {_MetainfoSupportedPlatforms}'.If you think this is a mistake or you are working on enabling the platform please build with the KF_IGNORE_PLATFORM_CHECK variable set to true")
+ message(WARNING "Your current platform '${CMAKE_SYSTEM_NAME}' is not supported. The list of supported platorms is '$ {_MetainfoSupportedPlatforms}'.If you think this is a mistake or you are working on enabling the platform please build with the KF_IGNORE_PLATFORM_CHECK variable set to true")

That would be sort of simpler indeed :)

I wonder if upstream could accept this way of making the build only
produce that warning, and not fail the build completely?

Samuel

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Le mercredi 5 octobre 2022, 01:10:56 CEST Samuel Thibault a écrit :

Hello,

Sune Stolborg Vuorela, le mar. 20 sept. 2022 20:37:20 +0200, a ecrit:

Consider applying the following instead:
[…]

That would be sort of simpler indeed :)

I wonder if upstream could accept this way of making the build only
produce that warning, and not fail the build completely?

Could be worth a try.

My understanding was that it was intentional to make it obvious which platforms were supported or not, in a way that a warning doesn’t really give you.

Maybe the change in your MR to be able to feed KF_IGNORE_PLATFORM_CHECK from the environment would be more acceptable to them.


Happy hacking,
--
Aurélien

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)