Q Light Controller+

For a while I've followed the installation method where I add an apt source and install QLC+ on my Ubuntu 20.04 system using apt install qlcplus-qt5. However, at some point recently this has stopped working. The repository folder I had been using before (for 18.04 but worked fine on 20.04) doesn't seem to exist anymore. The instruction page doesn't have an option for Ubuntu anymore. I did find some other repositories for 20.04, 21.04, and 21.10, but none of them have the qlcplus-qt5 release package. Did this option go away? How should I be installing QLC+ on Ubuntu now?

https://build.opensuse.org/package/show ... lcplus-qt5

There are a couple of different build problems in Massimo's OBS repo. The stable package hasn't been touched since 4.12.4 release, but some dependencies or something else in the build process changed in the meantime.

Normally the latest successfully binary package is kept for publishing, but apparently these latest functioning packages got deleted.

It would need some maintainance love and time spent to fix the various issues for several distros and get current packages published again.

I know my basic ways around in OBS pretty well, and offered Massimo in the past to help out there, but got no reaction so far (to be fair, that was pretty long ago).

https://build.opensuse.org/package/show ... us-qt5-git

Build failures are mostly because of OLA, which I'm tempted to drop next. It always gave an infinite number of build issues.

I think that is because the ola package in your home repo is independent, not an automatically updating branch of the community package in multimedia:libs.

I see the necessity to add .dsc etc. to build for debian based distros, you could still do that if your package were branched from mm:libs like the one in my home:edogawa repo is, but would benefit from updates and fixes "upstream" packagers make...

e.g. your packages still tries and builds against python2.7 which isn't supported anymore, thus some rpm python macros don't work anymore.

I didn't investigate in detail the errors in your package, but I've submit-requested fixes to build problems that occurred in my home branch, and they just got accepted, see https://build.opensuse.org/request/show/965157, but with this setup this doesn't arrive in your home...

In my experience OBS is smooth to maintain in general , but occasionally needs some care to adapt to upstream evolvement. Cingulingu set up the OBS for you but doesn't seem to be actively maintaining it, and I don't know how willing you are to do that maintainance work. That's why I try to offer my help in that area.

Edgar, I can give you admin access to the OBS repo. OK?
Honestly it's difficult for me to follow each and every aspect of all the Linux builds

Sure, I'm glad to jump in and do my best to fix the builds and keep the repo in shape where I can!

So I used this unexpected free sunday and made quite an overhaul to the build server area.
https://software.opensuse.org//download ... lcplus-qt5
https://software.opensuse.org//download ... us-qt5-git
Most builds are working again for both stable and git qt5 versions, including the ola plugin on all currently targetted distros.

Only Ubuntu 20.04 doesn't want to build, and I haven't dealt with that issue so far - some deprecated use of QVariant error. Maybe Massimo has an idea for that?

Hi Edgar, thanks a lot!
I see the OLA package doesn't target ubuntu, so it makes sense QLC+ fails cause it requires OLA?

No , if I understand correctly, ubuntu flavours can supply their own ola package, therefore I disabled build/use for build/publish of the ola package in your home repo, for these.

See https://build.opensuse.org/build/home:m ... s-qt5/_log, search that log for ola and you'll see it's downloaded and used.

Arch also supplies ola by its own.

For openSUSE it's different as ola isn't part of the core distro, it exists in multimedia:libs and multimedia:proaudio only. So there are 2 possibilities, adding one of these as package source, which will make installation more difficult for end users, or serving our own branch/copy of that package.

Finally, for recent Fedoras no official ola rpms seem to exist, thus I tweaked the rpm spec until it started building for Fedora using python3 as it does on openSUSE.
So we could actually simplify our ola package even more and get rid of all the debian builds, effectively just branching the multimedia:proaudio package, and supply it for rpm distros in our repo.

Furthermore we can drop libmad completely, it's not an issue since the mp3 patent ended years ago and it's available in all distros we support.

Personally I'd also drop both Qt4 package versions, I disabled all failing builds and there's only qt4-git for openSUSE 15.3 that still builds, not something anyone will be interested in, I believe.

https://build.opensuse.org/project/moni ... allegari79 shows a summary of what is being built, and its state

The error in Ubuntu 20.04 comes from some Qt5 deprecation warning that's being handled as error, as far as I can see.

Oh you were of course right about the missing ola in 20.04, I'll fix that in a minute, then the build error I talked about will show, I suppose...

EDIT: yep confirmed, apparently only newer than 20.04 Ubuntu ship ola, now that I've enabled it, the build starts and the error I was mumbling about shows ... sorry for the confusion, I was rather tired yesterday after all that and didn't even recognize the difference between "unresolvable" and "failed" anymore. And when writing that post today in the morning I didn't even look anymore, oh well...

I've read up on that warning/error. I've not found a fix in C++ code anywhere - from what I've read it seems to be the result of an unlucky combination of g++-9 and Qt5 5.12.x in Ubuntu 20.04, and got fixed in Qt 5.13 .

I made a simple patch and include it only for the debian builds, to ignore that deprecated-copy warning, and the 20.04 package builds with this now.

Just https://build.opensuse.org/package/show ... us-qt5-git includes this so far.

If Massimo is OK with this, I'll add the same to the 4.12.4 release package, and we can mark this thread as solved.

Hi Edgar, you've done a great job with those packages! Thanks
Please proceed with 4.12.4 qt5, considering that pretty soon I will release a 4.12.5 (shouldn't make any difference though)

It would be nice if OBS packages builds can be triggered by commits on Github (qt5-git of course).
I think I investigated a bit some years ago but then decided not to do it. Maybe now it's easier than then

I've just updated 4.12.4 qt5, it's building now. I'll also look into the automated triggering on Github commits, I too remember that this is possible.

Thanks you both so much! I can't express how helpful it is to see this resolved so efficiently.

I keep writing to this thread as the topic came up here, even if a new thread in Development subforum were a better place, excuse me...

It would be nice if OBS packages builds can be triggered by commits on Github (qt5-git of course).
I think I investigated a bit some years ago but then decided not to do it. Maybe now it's easier than then

I've looked into this and it seems in fact quite easy to set up.

I found and followed this guide.

I tried on a (unpublished) qlcplus package branch in my home:edogawa repo, pointing to my GH branch so I'm able to test committing/triggering via the webhook, and got it to work easily.

There has been more work on CI with Github and Gitlab, and it's currently in beta testing phase, not yet public... here's a detailed description:
https://openbuildservice.org/help/manua ... ation.html

TLDR:
1. If not exists already, Massimo has to generate a personal access token on Github, containing at least scope "repo"
2. In OBS, we create a token (being maintainer now, also I can do that) for package qlcplus-qt5-git
3. Back in GH, Massimo has to add a webhook with the ID and secret/key obtained from the OBS token, for "push" action only (pull requests shouldn't trigger OBS).

That's all, once this is set up, a push to QLC+ master branch on GH will trigger a package update in OBS

As you suggested, I moved this thread to sw development.

EDIT: I'm creating the necessary tokens/hooks now
EDIT2: almost done, but apparently tokens don't match. This doesn't work: while this works (old syntax)

did you replace "long_ascii_salad" with the actual long string of your osc token? type "osc token" to get it displayed.

I didn't even follow the procedure from suse docs, I used the linuxkamerada guide method which seems a bit simpler, for you that would look like:
This would print the string you need for long_ascii_salad (used for Secret: in the webhook) and the ID to fill in when creating the webhook.

I didn't even have to create the GH personal access token in the first place as in the suse docs, I believe it used the one I already had created for a different task (login from dolphin without authenticating).

EDIT:
I just created that osc token and if I understand correctly it should be displayed for you too via "osc token" ? ID=6088...

did you replace "long_ascii_salad" with the actual long string of your osc token? type "osc token" to get it displayed.

Of course I did

The guide says to create a "workflow" token. Your command creates a "service" token.
I'm confused. Everything seems to be done like the guide says, but OBS returns error 400 to GitHub.

Sorry for that question, I was just surprised that you did cite from the suse page while I had following the easier method in mind.

Maybe this helps: https://openbuildservice.org/2022/04/20 ... -messages/

I'll throw my existing setup and try the beta program method myself to see.

EDIT:
I deleted my previous setup, followed the same procedure/guide as you and got it working quickly. I altered .obs/workflows.yml to match my fork URL and OBS package name, after merging from upstream master to my dmxkeypad branch, and that triggered the new webhook right away. as did the merge/rebase just before that.

Apparently Github was giving me an error from a previous token.
Retriggering the delivery (on GH) seems to work now, but OBS doesn't actually start to build