qlcplus
qlcplus copied to clipboard
mcallegari
Debian packaging
Tracked here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=694077 By @jeromelebleu
By the way, when do you plan to release 4.12.2 please? Is this patch going to be included?
4.12.2 binaries are already ready. I haven't tagged yet, so HIDAPI license will be included in the 4.12.2 sources.
Also, as you are free to choose, are you okay to license those files under the terms of the GNU General Public License v3?
The problem is always the same: Apache 2.0 is compatible with GPL3, while GPL3 is not compatible with Apache 2.0. So I guess the answer is no at the moment. By the way, what are "those files" ? hidapi.* ?
By the way, when do you plan to release 4.12.2 please? Is this patch going to be included?
4.12.2 binaries are already ready. I haven't tagged yet, so HIDAPI license will be included in the 4.12.2 sources.
Great! :)
Also, as you are free to choose, are you okay to license those files under the terms of the GNU General Public License v3?
The problem is always the same: Apache 2.0 is compatible with GPL3, while GPL3 is not compatible with Apache 2.0. So I guess the answer is no at the moment. By the way, what are "those files" ?
The HIDAPI files which have been modified with #1190. The authors say that HIDAPI may be used by one of three licenses as outlined in LICENSE.txt.
The architecture issue I mentioned before is this: https://github.com/mcallegari/qlcplus/blob/master/variables.pri#L95
Unfortunately I had to hardcode x86_64 to have libraries in the proper place on Ubuntu-like distros.
This means though i686 and armhf are not supported out of the box.
This is ok as long as I am the one producing (manually) the official x64 package, but it's not in a more generic build server targeting multiple architectures.
I might replace that with QT_INSTALL_LIBS (check it with qmake -query) but I'm not sure if it is always consistent with the architecture and distro.
The architecture issue I mentioned before is this: https://github.com/mcallegari/qlcplus/blob/master/variables.pri#L95
Good to know, I didn't realize that, thanks. I could at least patch it in the Debian package to use QT_INSTALL_LIBS meanwhile you find a solution which is working fine on all distro.
Also this, which is even more difficult to solve :sob: https://github.com/mcallegari/qlcplus/blob/master/debian/qlcplus-ola.install#L1
Also this, which is even more difficult to solve sob https://github.com/mcallegari/qlcplus/blob/master/debian/qlcplus-ola.install#L1
I chose the easy way for now: do not install it... but I know that at some time...
Then I think BSD is the one. I will double check though.
I remembered correctly. HIDAPI can be released with BSD: https://apache.org/legal/resolved.html
Then I think BSD is the one. I will double check though.
I remembered correctly. HIDAPI can be released with BSD: https://apache.org/legal/resolved.html
Thanks! I have set this one so.
The architecture issue I mentioned before is this: https://github.com/mcallegari/qlcplus/blob/master/variables.pri#L95
Good to know, I didn't realize that, thanks. I could at least patch it in the Debian package to use QT_INSTALL_LIBS meanwhile you find a solution which is working fine on all distro.
Here is what I have done for now: https://salsa.debian.org/jlebleu-guest/qlcplus/blob/master/debian/patches/0002-fix-library-directory.patch. It is working fine for now at least on amd64 and on Debian. I cannot test on other distributions and OS, but it seems that this variable is quite reliable regarding other Qt applications. Tell me when you might have tested it! Do you want I open an issue for that?
Your patch is wrong. LIBSDIR is used almost everywhere with INSTALLROOT as well. Example: https://github.com/mcallegari/qlcplus/blob/master/engine/src/src.pro#L227 Your patch install things in /usr/usr/lib/etc.. If it was that easy I would have done it a long time ago :)
Thanks for your review. I didn't expect this use of LIBSDIR, I should grep it to have more context. However - as I have tested at least that this patch is working before pushing it - libraries are installed at the right place. I didn't succeed to find an explanation of why, if you have an idea as you know Qt more than me...
Here are some parts of the build output, tell me if you need more:
[...]
debian/rules override_dh_auto_install
make[1]: Entering directory '/<<PKGBUILDDIR>>'
dh_auto_install
make -j2 install DESTDIR=/<<PKGBUILDDIR>>/debian/tmp AM_UPDATE_INFO_DIR=no INSTALL_ROOT=/<<PKGBUILDDIR>>/debian/tmp
[...]
make[4]: Entering directory '/<<PKGBUILDDIR>>/webaccess/src'
/usr/lib/qt5/bin/qmake -install qinstall -exe libqlcpluswebaccess.so.1.0.0 /<<PKGBUILDDIR>>/debian/tmp/usr/lib/i386-linux-gnu/libqlcpluswebaccess.so.1.0.0
/usr/lib/qt5/bin/qmake -install qinstall /<<PKGBUILDDIR>>/webaccess/res/virtualconsole.css /<<PKGBUILDDIR>>/debian/tmp/usr/share/qlcplus/web/virtualconsole.css
: --strip-unneeded /<<PKGBUILDDIR>>/debian/tmp/usr/lib/i386-linux-gnu/libqlcpluswebaccess.so.1.0.0
ln -f -s libqlcpluswebaccess.so.1.0.0 /<<PKGBUILDDIR>>/debian/tmp/usr/lib/i386-linux-gnu/libqlcpluswebaccess.so
/usr/lib/qt5/bin/qmake -install qinstall /<<PKGBUILDDIR>>/webaccess/res/virtualconsole.js /<<PKGBUILDDIR>>/debian/tmp/usr/share/qlcplus/web/virtualconsole.js
ln -f -s libqlcpluswebaccess.so.1.0.0 /<<PKGBUILDDIR>>/debian/tmp/usr/lib/i386-linux-gnu/libqlcpluswebaccess.so.1
ln -f -s libqlcpluswebaccess.so.1.0.0 /<<PKGBUILDDIR>>/debian/tmp/usr/lib/i386-linux-gnu/libqlcpluswebaccess.so.1.0
make[4]: Leaving directory '/<<PKGBUILDDIR>>/webaccess/src'
[...]
Also, if you have any ideas of how to debug that - e.g. to know the variable values - I can try them.
Finally, here is my output of qmake -query - note that it is not the one of the build context:
QT_SYSROOT:
QT_INSTALL_PREFIX:/usr
QT_INSTALL_ARCHDATA:/usr/lib/x86_64-linux-gnu/qt5
QT_INSTALL_DATA:/usr/share/qt5
QT_INSTALL_DOCS:/usr/share/qt5/doc
QT_INSTALL_HEADERS:/usr/include/x86_64-linux-gnu/qt5
QT_INSTALL_LIBS:/usr/lib/x86_64-linux-gnu
QT_INSTALL_LIBEXECS:/usr/lib/x86_64-linux-gnu/qt5/libexec
QT_INSTALL_BINS:/usr/lib/qt5/bin
QT_INSTALL_TESTS:/usr/tests
QT_INSTALL_PLUGINS:/usr/lib/x86_64-linux-gnu/qt5/plugins
QT_INSTALL_IMPORTS:/usr/lib/x86_64-linux-gnu/qt5/imports
QT_INSTALL_QML:/usr/lib/x86_64-linux-gnu/qt5/qml
QT_INSTALL_TRANSLATIONS:/usr/share/qt5/translations
QT_INSTALL_CONFIGURATION:/etc/xdg
QT_INSTALL_EXAMPLES:/usr/lib/x86_64-linux-gnu/qt5/examples
QT_INSTALL_DEMOS:/usr/lib/x86_64-linux-gnu/qt5/examples
QT_HOST_PREFIX:/usr
QT_HOST_DATA:/usr/lib/x86_64-linux-gnu/qt5
QT_HOST_BINS:/usr/lib/qt5/bin
QT_HOST_LIBS:/usr/lib/x86_64-linux-gnu
QMAKE_SPEC:linux-g++
QMAKE_XSPEC:linux-g++
QMAKE_VERSION:3.1
QT_VERSION:5.11.3
Here's the explanation, I totally forgot about this: https://github.com/mcallegari/qlcplus/blob/master/variables.pri#L265 So basically you don't even need a patch as long as you build with Qt installed in /usr
The hardcoded paths are used when building with a "non-system" Qt version (I normally do that at home) to avoid QLC+ libraries/plugins to be installed in the Qt paths.
For instance
/home/massimo/projects/Qt5.12.3/5.12.3/gcc_64/bin/qmake -query
QT_SYSROOT:
QT_INSTALL_PREFIX:/home/massimo/projects/Qt5.12.3/5.12.3/gcc_64
QT_INSTALL_ARCHDATA:/home/massimo/projects/Qt5.12.3/5.12.3/gcc_64
QT_INSTALL_DATA:/home/massimo/projects/Qt5.12.3/5.12.3/gcc_64
QT_INSTALL_DOCS:/home/massimo/projects/Qt5.12.3/Docs/Qt-5.12.3
QT_INSTALL_HEADERS:/home/massimo/projects/Qt5.12.3/5.12.3/gcc_64/include
QT_INSTALL_LIBS:/home/massimo/projects/Qt5.12.3/5.12.3/gcc_64/lib
QT_INSTALL_LIBEXECS:/home/massimo/projects/Qt5.12.3/5.12.3/gcc_64/libexec
QT_INSTALL_BINS:/home/massimo/projects/Qt5.12.3/5.12.3/gcc_64/bin
QT_INSTALL_TESTS:/home/massimo/projects/Qt5.12.3/5.12.3/gcc_64/tests
QT_INSTALL_PLUGINS:/home/massimo/projects/Qt5.12.3/5.12.3/gcc_64/plugins
QT_INSTALL_IMPORTS:/home/massimo/projects/Qt5.12.3/5.12.3/gcc_64/imports
QT_INSTALL_QML:/home/massimo/projects/Qt5.12.3/5.12.3/gcc_64/qml
QT_INSTALL_TRANSLATIONS:/home/massimo/projects/Qt5.12.3/5.12.3/gcc_64/translations
QT_INSTALL_CONFIGURATION:/home/massimo/projects/Qt5.12.3/5.12.3/gcc_64
QT_INSTALL_EXAMPLES:/home/massimo/projects/Qt5.12.3/Examples/Qt-5.12.3
QT_INSTALL_DEMOS:/home/massimo/projects/Qt5.12.3/Examples/Qt-5.12.3
QT_HOST_PREFIX:/home/massimo/projects/Qt5.12.3/5.12.3/gcc_64
QT_HOST_DATA:/home/massimo/projects/Qt5.12.3/5.12.3/gcc_64
QT_HOST_BINS:/home/massimo/projects/Qt5.12.3/5.12.3/gcc_64/bin
QT_HOST_LIBS:/home/massimo/projects/Qt5.12.3/5.12.3/gcc_64/lib
QMAKE_SPEC:linux-g++
QMAKE_XSPEC:linux-g++
QMAKE_VERSION:3.1
QT_VERSION:5.12.3
[snip]
I might replace that with
QT_INSTALL_LIBS(check it withqmake -query) but I'm not sure if it is always consistent with the architecture and distro.
It will work, as the returned value will depend on how the distro setted up Qt / qmake.
Also this, which is even more difficult to solve sob https://github.com/mcallegari/qlcplus/blob/master/debian/qlcplus-ola.install#L1
I chose the easy way for now: do not install it... but I know that at some time...
Also this, which is even more difficult to solve sob https://github.com/mcallegari/qlcplus/blob/master/debian/qlcplus-ola.install#L1
Replace x86_64-linux-gnu with *
usr/lib/*/qt5/plugins/qlcplus/libolaio.so
[snip]
Finally, here is my output of
qmake -query- note that it is not the one of the build context:
As long as you are using the distro-supplied qmake version it will have the same values, so nothing to worry here.
Here's the explanation, I totally forgot about this: https://github.com/mcallegari/qlcplus/blob/master/variables.pri#L265 So basically you don't even need a patch as long as you build with Qt installed in /usr
The hardcoded paths are used when building with a "non-system" Qt version (I normally do that at home) to avoid QLC+ libraries/plugins to be installed in the Qt paths. For instance
/home/massimo/projects/Qt5.12.3/5.12.3/gcc_64/bin/qmake -queryQT_SYSROOT: QT_INSTALL_PREFIX:/home/massimo/projects/Qt5.12.3/5.12.3/gcc_64 QT_INSTALL_ARCHDATA:/home/massimo/projects/Qt5.12.3/5.12.3/gcc_64 QT_INSTALL_DATA:/home/massimo/projects/Qt5.12.3/5.12.3/gcc_64 QT_INSTALL_DOCS:/home/massimo/projects/Qt5.12.3/Docs/Qt-5.12.3 QT_INSTALL_HEADERS:/home/massimo/projects/Qt5.12.3/5.12.3/gcc_64/include QT_INSTALL_LIBS:/home/massimo/projects/Qt5.12.3/5.12.3/gcc_64/lib QT_INSTALL_LIBEXECS:/home/massimo/projects/Qt5.12.3/5.12.3/gcc_64/libexec QT_INSTALL_BINS:/home/massimo/projects/Qt5.12.3/5.12.3/gcc_64/bin QT_INSTALL_TESTS:/home/massimo/projects/Qt5.12.3/5.12.3/gcc_64/tests QT_INSTALL_PLUGINS:/home/massimo/projects/Qt5.12.3/5.12.3/gcc_64/plugins QT_INSTALL_IMPORTS:/home/massimo/projects/Qt5.12.3/5.12.3/gcc_64/imports QT_INSTALL_QML:/home/massimo/projects/Qt5.12.3/5.12.3/gcc_64/qml QT_INSTALL_TRANSLATIONS:/home/massimo/projects/Qt5.12.3/5.12.3/gcc_64/translations QT_INSTALL_CONFIGURATION:/home/massimo/projects/Qt5.12.3/5.12.3/gcc_64 QT_INSTALL_EXAMPLES:/home/massimo/projects/Qt5.12.3/Examples/Qt-5.12.3 QT_INSTALL_DEMOS:/home/massimo/projects/Qt5.12.3/Examples/Qt-5.12.3 QT_HOST_PREFIX:/home/massimo/projects/Qt5.12.3/5.12.3/gcc_64 QT_HOST_DATA:/home/massimo/projects/Qt5.12.3/5.12.3/gcc_64 QT_HOST_BINS:/home/massimo/projects/Qt5.12.3/5.12.3/gcc_64/bin QT_HOST_LIBS:/home/massimo/projects/Qt5.12.3/5.12.3/gcc_64/lib QMAKE_SPEC:linux-g++ QMAKE_XSPEC:linux-g++ QMAKE_VERSION:3.1 QT_VERSION:5.12.3
You can also do this just for your application by setting the install root of your app. By the way CMake makes this all much simpler, you should consider trying it.
QLC+ is now in Debian unstable since 11/11! :) See: https://packages.debian.org/sid/qlcplus
nice @jeromelebleu ! I've made a PR on salsa in the hope that those changes are helping. Please review it.
@mcallegari In order to integrate the OLA plugin in Debian too, could you explain your motivations of doing a separate package for it please?
@jeromelebleu there's no reason really. When I originally forked QLC, it was already like that. Anyway, libolaio.so is included in (my) official Debian package. OLA is not a hard dependency though. Perhaps qlcplus-ola.install is no longer needed?
What does changes if the OLA plugin is added? I mean, if it is a plugin then it surely can be [de]activated at user's will. If it is not possible to do that, does it change some specific behaviour?
The OLA plugin normally requires the OLA package to be installed. A few years ago I made this dependency optional, so the plugin is always there even if OLA is not installed. In that case, the plugin will fail to load, cause needed shared library (libola.so) will not be found. Nothing fancy in my opinion.
El mié., 27 nov. 2019 16:25, Massimo Callegari [email protected] escribió:
The OLA plugin normally requires the OLA package to be installed. A few years ago I made this dependency optional, so the plugin is always there even if OLA is not installed. In that case, the plugin will fail to load, cause needed shared library (libola.so) will not be found. Nothing fancy in my opinion.
Then there is nothing to add, this should be added right away to the current package, no need to create a special package for this. Debian users will simply have libola installed.
Thanks!