Hi Marius,





Sent with Proton Mail secure email.

------- Original Message -------
On Tuesday, November 22nd, 2022 at 11:56 AM, Marius Bakke <marius@gnu.org> wrote:


> > Is this issue somewhere described? I've lately used more tarballs to git download on other packages.
> > Is the issue connected with any Gitlab/Forge or just the KDE and the release scripts?
> 
> 
> We have this problem with all the forges. There have been many-a bug
> report about it, and the linter also warns about it (apparently for
> GitHub only, that could be improved).

Thanks for the explanation. I'll keep that in mind.
> 
> > > * dropped the !! commits
> > > * Minor tweaks to synopses and descriptions
> > 
> > My apologies as I noticed there were few packages with wrong license or missing description.
> 
> 
> Oh, I did not license audit these packages as I assumed all the KDE
> stuffs were using the same license. Can you submit patches to update
> the licenses?

I've tried to follow the licenses as submitted by the individual packages. I'm currently in process
of double checking.


I found out that the kinfocenter and systemsettings were not behaving correctly - no widgets were
rendered due to missing QML modules. The attached patch solves this.

I have some additional patches for kwin and plasma-workspace but they are not yet enough to launch
KDE desktop.

Also one "small" problem. As I switched to sway to test apps running under Wayland I noticed a pretty
important issue. None of the programs launched were running under Wayland - they ran in XWayland.

Is this known issue?

Do we need to modify the qt-build-system or cmake-build-system? Or shall we add wrap phase for each
package to add the correct path for qtwayland package in env variable QT_QPA_PLATFORM_PLUGIN_PATH?

```
$ echo $XDG_SESSION_TYPE
wayland
$ konsole
qt.qpa.plugin: Could not find the Qt platform plugin "wayland" in ""
```

----
Petr