On 31/05/2021 14:20, Harald Sitter wrote:
On Sat, May 29, 2021 at 10:20 PM Bart De Vries <b...@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
