Description of problem: Can tigervnc be branched and built for EPEL10? Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
No matching package to install: 'fltk-devel >= 1.3.3' No matching package to install: 'pkgconfig(xkbcomp)' No matching package to install: 'xorg-x11-server-devel' No matching package to install: 'xorg-x11-server-source' I'm not sure this is going to fly. But also not sure what is going to replace it.
My current workflow is weston for EPEL10. It is a big shift, but works today.
Is it just the client you're looking for, or the server?
My ideal world would have both, but the server seems like a reach since I doubt anyone wants to own the xorg packages in EPEL. Client only would be sufficient.
Client only should be possible with a one-line patch to the spec file, but fltk will need to be added to EPEL 10 first (bug 2374179).
The client would be what I would use as well.
This now builds in epel10 with %bcond server 0: https://koji.fedoraproject.org/koji/taskinfo?taskID=136504895
We here upstream have ported our packaging to RHEL 10 if it helps: https://github.com/TigerVNC/tigervnc/blob/master/contrib/packages/rpm/el10/SPECS/tigervnc.spec We're also open to collaborating around the packaging. We don't give them as much love as they need.
I don't have any experience bringing a package to EPEL, yet, so maybe we can ask tdawson for some guidance? I don't see a reason why not to bring Tigervnc to EPEL now, when it supports Wayland. I have split the package to tigervnc-x11-server and tigervnc-wayland-server so we can at least for now bring only the wayland support there.
That pull request completely removes Xvnc and x0vncserver. Can't those be kept? All the dependencies are already available in RHEL/EPEL. It's just the Xorg server source that's been removed, and that can easily be added to the TigerVNC package. Have a look at our packaging above for how it can be done.
In whatever form it is handled, the xserver would still need to be *maintained*, and nobody has volunteered to do this for EPEL 10. Therefore, the xserver components need to be excluded so that the rest can be added.