After much fighting with the crappy proprietary VisionFive2 driver (no open driver yet there) I had to switch to prepare a demo on a Raspberry-Pi5 board. Looks good already :) Will be based on Yocto master with a couple of unmerged patches for RPI5 support, as well as latest state of KDE Yocto layers and everything with a Plasma Mobile shell. I will also bring a very nice touch screen with me for the stall.

I did a small change of plans, instead of the RPi4, I am very optimistic that I manage to get the plasma-big-screen Yocto demo on top of a brand-new VisionFive-2 RISC-V board. That device alone will probably already catch some attention, I think.

If there is interest, I can bring a Yocto based RPI4 with 7inch touch screen for the booth as demo device. Either with a Plasma Mobile or a Plasma Bigscreen shell.

@alex please ignore the previous comment, I got mixed up with a task with an almost identical name (the tooling for autogenerating tests for license conformance)
I think it should be doable to get a hook that checks dep5 statements regarding REUSE tool output, mostly by reusing the referenced python tooling from ECM for generating the tests. But before doing that we have to check with sysadmins, if we can run the REUSE tool with every push...

@alex the .dep5 files with license statements should be fully respected, because the tooling internally calls reuse tool to generate a BOM file in SPDX format and parses that. Admittedly I never tested with a repository that contains .dep5 license statements. If it does not work, then it is most probably a problem in the reuse tool.

Task is replaced by https://invent.kde.org/teams/licensing/issues/-/issues/12

You know, you rock :D thanks for the PoC snippet. I already started some refactoring to get the translation part into a unit-testible self-contained async class. The idea is to create an adapter class to translatorshell with a decent to use API.

I like this :) Is it possible to access exactly this krunner plugin via dbus or would it rather be the way to load the plugin the same way krunner is doing it?

@alex I know, but then looked into the code and was shocked how much too complicated the implementation looks for this mostly simple feature.
But the the topic, I confirm that I also cannot make any of the translation APIs work, they all look dead. For google there seems to be the V2 API (https://cloud.google.com/translate/docs/reference/rest/v2/translate), yet that requires an API key. For Leo I could not find any recent API information. And probably it can simply replaced with DeepL, but there we also need an API key.
Yet, I think that the translation support is a really cool feature when integrated properly for creating vocabulary sets. So I think it's worth the time to see if it can be reenabled with more recent APIs.

Yeah, looking forward to remove all that lines of deprecated code :) If you are not already working on it, I can take over the rewrite of the translator scripts into a more user friendly and also Kross-less solution.

I checked with a distro package of Parley and must change my previous claim slightly, it seems that for me only the audio file download from Wiktionary is completely broken for me, the others seem to work there; I expect that I have something wrongly built with my Kross interpreters...
However, I think the question is, which of these scripts shall be ported to real C++ implementations? IMO the whole scripting engine of Parley never turned out to be a widely used feature and I suggest to keep complexity low by just rewriting the really useful bits in C++, which will then ultimately make the Kross dependency obsolete.
For the translation scripts I think it is easy to do, just by judging of the complexity of the scripts. For the audio download I just noticed that we actually have a C++ based implementation for accessing mediawiki api (https://invent.kde.org/libraries/libmediawiki). Yet, I did not check if this meets all needs. But it means, there could be a way also to replace the mwclient Python library.
Needless to say that I fully agree with your assessment of the technical debts in the code base :/ Just by testing the scripts I hit about 3 different crashes :( Will look if I can at least fix them in the release branch and also will try to spend some time in the most pressing codebase modernize issues. But no promises ;) Yet, that is probably outside if this issue.

@alex IIRC all those plugins have to be enabled by the user before doing any automatic downloading. But there are a few separate extensions:

• script for moving phrases from one lesson to another (trivial script, could easily be implemented in C++ IMO)
• script for downloading audio files for words from Wiktionary (uses mwclient python library and is probably hard to reimplement)
• script for translating words/phrases via Leo (looks like a simple to rewrite script)
• script for translating words/phrases via Google Translate (looks like a simple to rewrite script)

Yet, I have the same experience and did not yet succeed to make them work for me, which is quite sad, because is released code :/
However, I think that all of them are reasonable features but it will need somebody who fixes/rewrite them without Kross. At the moment, my suggestion would be to disable them at least in master because they do not work. If they then do not get ported to anything until the first KF6 based Parley release, we have to remove them.

https://invent.kde.org/frameworks/kunitconversion/-/merge_requests/7

For the bindings point, is it a decision worth mentioning in https://community.kde.org/Frameworks/Policies ?

(notes from KF6 sprint discussion)

I think the point is that a Tier 1 framework must not depend on another Tier 1 framework. So, the solutions are to either increase the Tier of Kirigami or to introduce another umbrella framework similar to KXmlGui, which does the GUI generation based on Kirigami and KConfig (I would prefer the latter personally).

Kross is practically unmaintained since before the port to Qt5, which is quite a lot of years right now.
Even for KF5 it was only marked to be a porting aid.

Remaining ones for now, still hunting original contributors:
src/file/fileindexerconfig.cpp:7: SPDX-License-Identifier: LGPL-2.0-only
src/file/fileindexerconfig.h:6: SPDX-License-Identifier: LGPL-2.0-only

Yeah, that will be interesting. Also it would be awesome if we find any way to connect to Qt's retranslate handing, but that still hardcodes the qsTr methods for evaluating if a binding should be reevaluted with retranslated...
However, this means that we can deprecate the old API in KDeclarative and move the few projects that use it to KI18n.

Remaining files after latest update (mails sent to remaining contributors for license changes):
file/metadatamover.cpp:6: SPDX-License-Identifier: LGPL-2.0-only
file/fileindexerconfig.cpp:7: SPDX-License-Identifier: LGPL-2.0-only
file/metadatamover.h:6: SPDX-License-Identifier: LGPL-2.0-only
file/fileindexerconfig.h:6: SPDX-License-Identifier: LGPL-2.0-only
file/powerstatemonitor.cpp:6: SPDX-License-Identifier: LGPL-2.0-only
file/filewatch.cpp:6: SPDX-License-Identifier: LGPL-2.0-only

@apol looks like you already added the bindings in 2015 :) Do you remember if anything was missing?
Right now I do not see anything missing than a few deprecation markers in KDeclarative for setupContext and translationDomain methods...

MR for first set of simple conversions (all authors already in relicensingscript.pl): https://invent.kde.org/frameworks/baloo/-/merge_requests/8
src/file/fileexcludefilters.h
src/file/priority.cpp
src/file/priority.h

Reaming files in src:/
kioslaves/timeline/timelinetools.h:5: SPDX-License-Identifier: LGPL-2.0-only
file/fileexcludefilters.h:5: SPDX-License-Identifier: LGPL-2.0-only
file/priority.cpp:8: SPDX-License-Identifier: LGPL-2.0-only
file/metadatamover.cpp:6: SPDX-License-Identifier: LGPL-2.0-only
file/fileindexerconfig.cpp:7: SPDX-License-Identifier: LGPL-2.0-only
file/filewatch.h:5: SPDX-License-Identifier: LGPL-2.0-only
file/fileexcludefilters.cpp:5: SPDX-License-Identifier: LGPL-2.0-only
file/metadatamover.h:6: SPDX-License-Identifier: LGPL-2.0-only
file/fileindexerconfig.h:6: SPDX-License-Identifier: LGPL-2.0-only
file/powerstatemonitor.cpp:6: SPDX-License-Identifier: LGPL-2.0-only
file/priority.h:5: SPDX-License-Identifier: LGPL-2.0-only
file/filewatch.cpp:6: SPDX-License-Identifier: LGPL-2.0-only
file/powerstatemonitor.h:6: SPDX-License-Identifier: LGPL-2.0-only

remaining files in src/:
sycoca/ksycocaentry.cpp:5: SPDX-License-Identifier: LGPL-2.0-only
sycoca/ksycocautils_p.h:6: SPDX-License-Identifier: LGPL-2.0-only
sycoca/kbuildsycoca_p.h:5: SPDX-License-Identifier: LGPL-2.0-only
sycoca/kbuildsycoca.cpp:6: SPDX-License-Identifier: LGPL-2.0-only
sycoca/ksycoca.h:6: SPDX-License-Identifier: LGPL-2.0-only
sycoca/kctimefactory.cpp:5: SPDX-License-Identifier: LGPL-2.0-only
sycoca/ksycocafactory_p.h:5: SPDX-License-Identifier: LGPL-2.0-only
sycoca/ksycocadict_p.h:5: SPDX-License-Identifier: LGPL-2.0-only
sycoca/ksycocafactory.cpp:5: SPDX-License-Identifier: LGPL-2.0-only
sycoca/ksycocaentry.h:5: SPDX-License-Identifier: LGPL-2.0-only
sycoca/kctimefactory_p.h:5: SPDX-License-Identifier: LGPL-2.0-only
sycoca/ksycocaentry_p.h:5: SPDX-License-Identifier: LGPL-2.0-only
sycoca/vfolder_menu.cpp:5: SPDX-License-Identifier: LGPL-2.0-only
sycoca/ksycoca_p.h:7: SPDX-License-Identifier: LGPL-2.0-only
sycoca/kbuildservicegroupfactory_p.h:5: SPDX-License-Identifier: LGPL-2.0-only
sycoca/ksycocaresourcelist_p.h:5: SPDX-License-Identifier: LGPL-2.0-only
sycoca/kbuildservicetypefactory.cpp:5: SPDX-License-Identifier: LGPL-2.0-only
sycoca/vfolder_menu_p.h:5: SPDX-License-Identifier: LGPL-2.0-only
sycoca/kbuildservicegroupfactory.cpp:5: SPDX-License-Identifier: LGPL-2.0-only
sycoca/kbuildservicefactory.cpp:6: SPDX-License-Identifier: LGPL-2.0-only
sycoca/ksycocadict.cpp:5: SPDX-License-Identifier: LGPL-2.0-only
sycoca/ksycoca.cpp:7: SPDX-License-Identifier: LGPL-2.0-only
kbuildsycoca/kbuildsycoca_main.cpp:6: SPDX-License-Identifier: LGPL-2.0-only
plugin/kdbusservicestarter.h:5: SPDX-License-Identifier: LGPL-2.0-only
plugin/kplugintrader.h:7: SPDX-License-Identifier: LGPL-2.0-only
plugin/kdbusservicestarter.cpp:5: SPDX-License-Identifier: LGPL-2.0-only
plugin/kplugintrader.cpp:7: SPDX-License-Identifier: LGPL-2.0-only
kdeinit/ktoolinvocation_win.cpp:6: SPDX-License-Identifier: LGPL-2.0-only
services/kservicetypefactory.cpp:5: SPDX-License-Identifier: LGPL-2.0-only
services/kplugininfo.h:5: SPDX-License-Identifier: LGPL-2.0-only
services/kservice.cpp:6: SPDX-License-Identifier: LGPL-2.0-only
services/kplugininfo.cpp:6: SPDX-License-Identifier: LGPL-2.0-only
services/kservicegroup_p.h:5: SPDX-License-Identifier: LGPL-2.0-only
services/kmimetypetrader.h:6: SPDX-License-Identifier: LGPL-2.0-only
services/kservicetypeprofile.cpp:6: SPDX-License-Identifier: LGPL-2.0-only
services/kservicetype.cpp:6: SPDX-License-Identifier: LGPL-2.0-only
services/kservicetypetrader.h:6: SPDX-License-Identifier: LGPL-2.0-only
services/kservicegroup.cpp:5: SPDX-License-Identifier: LGPL-2.0-only
services/kservicegroup.h:5: SPDX-License-Identifier: LGPL-2.0-only

Because of the feedback, merge requests are created for all SPDX based framework repositories. Moreover, I added this info to a new FAQ section in: the https://community.kde.org/Guidelines_and_HOWTOs/Licensing

Well, if there is no opposition, then we do not have to stall this discussion :)
Just a gentle ping for the usual licensing suspects (@riddel @adridg @kossebau ) if anybody wants to raise their voice, otherwise I will start cleaning the COPYING files up in frameworks next week

Traditionally, our repositories have license text files in their main folder. For GPL licenses this originates from the GNU FAQ (https://www.gnu.org/licenses/gpl-howto.html). So, today often are files called COPYING, COPYING.BSD, COPYING.LGPL...
With changing the copyright statements to following the reuse.software specification, additionally a new folder LICENSES/ was created in every repository. That folder contains a file <SPDX-License-Identifier>.txt per used license in the repository.
Thirdly, Gitlab suggests to add a file called LICENSE at the main root (which we can fully ignore, if we want).

I think the goal must be to have some machine readable license information. Ideally, this would be in the repository yaml files and then can be used both for documentation as well as for automatic checking that the source code in the repository is really compatible with that license.
The main problem IMO is though that we have several repository with a historically weird mix of licenses, even when only looking at the contained libraries, plugins and executables. So, probably we will get to a list of possible binary artifacts of that repository and for each a possible outbound license that artifact can be used under (e.g. when something is both usable as LGPL 2.1 or LGPL 3.0).

I was thinking the same.