On 06/12/2025 09:34, Johannes Schauer Marin Rodrigues wrote:
what do you think about the idea of also letting the openrgb package
build and ship the OpenRGBEffectsPlugin shared library?
Good idea. I had already started trying to package the 7 plugins into
the main source, similar to your patch. The ones I managed to build so
far are Skins and E131.
If you're interested, happy to push my working branch on Salsa if you're
interested in helping with the Effects plugin or any of the other ones.
I think it would make sense to add this plugin to the openrgb source
package instead of creating a new source package because the version of
[...]
Agree, they build it that way, source dirs pointing at each other and
don't really export headers, so they all should be built together in the
same source if possible.
I have cooked up the patch at the end of this email which assumes that
both the OpenRGBEffectsplugin as well as QCodeEditor are included as a
Debian source package component. In d/rules then symlinks are created to
make OpenRGB itself as well as QCodeEditor appear to be at the expected
location relative to OpenRGBEffectsplugin.
Thanks a lot for that. MUT seems the right tool here, but I took the
approach of patching the QMake project file paths instead of symlinks. A
bit more work, but it has to be patched anyway with other bits (version,
etc.)
Vendoring the 2-file library seems reasonable here, we can try it.
Not sure about QCodeEditor. It's not objectively "tiny" so tough to make
a case for it. Just out of curiosity, have you tried to build it as a
shared lib?
Unfortunately, all of this is not immediately actionable even if you
agree that this is a good idea because the OpenRGBEffectsplugin expects
a specific version of OpenRGB, in this case the OpenRGB tag
release_candidate_1.0rc1. Attempting to build OpenRGBEffectsplugin with
OpenRGB, in Debian unstable would require some patching which is why
instead of patching OpenRGBEffectsplugin I packaged OpenRGB
release_candidate_1.0rc1 locally to make this a proof-of-concept.
Well, to package the plugin, a new version of OpenRGB would be expected
anyway. It's still actionable, but perhaps not as a patch.
As they don't really tag releases frequently (and uscan's MUT support
lacks any commit-based pinning), this just needs capturing the matching
HEAD commits from all repositories at the same point in time. And also
pristine-tar = True, which I hadn't been using so far.
My working copy is from an October commit, so a fresh one is due anyway.
--
Regards,
Ahmad
