New repo in kdereview: kasts

Bart De Vries bart at mogwai.be
Wed Jun 2 10:48:31 BST 2021


On 31/05/2021 14:20, Harald Sitter wrote:
> On Sat, May 29, 2021 at 10:20 PM Bart De Vries <bart at mogwai.be> wrote:
>>
>> On 27/05/2021 15:09, Harald Sitter wrote:
>>> - the source is almost reuse compliant but not quite. needs some extra
>>> data files equipped with CC-0 or the like [1][2]. You could then also
>>> add an include on
>>> https://invent.kde.org/sysadmin/ci-tooling/raw/master/invent/ci-reuse.yml
>>> to your gitlab-ci.yml to ensure it stays at complete coverage
>>
>> We've made all source files reuse compliant with one exception: the dbus
>> interface files.  We couldn't figure out which license to apply.
>> Any pointers are welcome.
> 
> org.freedesktop.PowerManagement.Inhibit.xml can be simply CC0 with no
> copyright holder. It's essentially auto-generated introspection data.
> example at [1]
> 
> org.gnome.SessionManager.xml is a bit more complicated because it
> contains exhaustive documentation that could possibly be considered
> copyrightable.
> I'm guessing it was excavated from gnome-session [2]? If so it's
> probably GPL-2+ with gnome as copyright holder, **but** it may make
> sense to send a mail to the maintainers to clarify the situation. You
> could also replace this file with a rewrite: You really only need a
> super trivial definition like
> org.freedesktop.PowerManagement.Inhibit.xml, modeling merely the
> Inhibit and Uninhibit methods. Neither the documentation nor the other
> methods actually serve any purpose here anyway.
> 
> [1] https://community.kde.org/Guidelines_and_HOWTOs/Licensing#License_Statements_in_Non-Source-Code_Files
> [2] https://gitlab.gnome.org/GNOME/gnome-session/-/blob/master/gnome-session/org.gnome.SessionManager.xml

Thanks, that makes sense.
I've reduced org.gnome.SessionManager.xml to its bare minimum, and then 
used CC0 for both dbus xml files.
The project is now fully reuse compliant, and the gitlab CI check has 
been put in place.

> I now noticed your hack in AudioManagerPrivate::prepareAudioStream
> though. I would strongly urge you to find another way of dealing with
> this. Nested event loops (QEventLoop::exec) have shown to be fairly
> crashy in the past, double so for QML application. If any event fires
> (e.g. through a timer) that deletes an object or otherwise mutates
> expected states out from under the current stack the application will
> crash. QEventLoop::exec is really an anti-pattern most of the time
> IMO.

Fair point.
I'll investigate other possibilities to get this hack implemented.
Actually, our hope is that the underlying problem will be solved in 
Qt6::Multimedia, and that the hack can be removed altogether.

Best regards,
Bart


More information about the kde-core-devel mailing list