Hi Ahmad, Quoting Ahmad Khalifa (2025-12-09 18:52:28) > 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 can help testing and I can review your code but I fear I am too short on time to make significant contributions. Too many other packages and upstream projects to maintain. XD > > 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.) Since you are the maintainer, it's up to you which engineering solution you choose for this problem. :) > 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? No, my focus was on having to do as little custom patching as possible because everything which I do different from how OpenRGBEffectsplugin does it will have to be maintained by me going forward. Keeping things the way upstream chose to engineer them means less time investment on my part. I am motivated to spend my time on the problem if it has a net benefit for Debian and since QCodeEditor is used by nobody else, I chose the easy vendoring solution. You might even say that *not* vendoring is a disadvantage for Debian because now QCodeEditor as a new package will have an impact on all parts of our infra as its own source package from tracker to transitions to the Packages file itself. And QCodeEditor seems to be dead upstream, no? > > 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. I can wait. There is no rush from me and if it makes things easier, I wait for the 1.0 release. :) Thanks! cheers, josch
signature.asc
Description: signature
