RPM packaging of Xpra for Fedora

[sagitter]

@totaam
@sergiomb2

Problem:

RPM packaging of Xpra for Fedora: conflicts between official packages and upstream packages.
A recap of this issue is here.

Proposed solution:

In view of new next major release (the number 6), these are my suggests:

• Transferring the structure of Xpra sub-packages considered here in the Fedora RPM packaging tree of Xpra.
• Since we cannot include proprietary code in Fedora (pycuda?), we need to leave the RPMs of proprietary codecs available from Upstream only.
• All deep modifications of the RPMs in Fedora must be discussed here with @totaam (or with his collaborators) before to be committed in the Fedora repositories.

As a consequence:

• The RPMs of Xpra from Upstream become redundant.
• Upstream may consider to provide RPMs of Xpra for alpha or beta testing outside Fedora repositores but respecting the Fedora Project Packaging Guidelines.

Additional context

Xpra is also actually provided for CentOS 8-9 by EPEL repositories.

[totaam]

This sounds good, though I suspect that there are going to be a lot of thorny issues.

Let's start with the most obvious ones:

• build packages for multiple python targets #3945 ie: we now provide python3.12-xpra (and sub-packages) for Fedora 37, and xpra is actually python3.11-xpra for RHEL 8 / 9 since those have a python3 which is too old to run xpra v6 - see the (long) package list for Fedora: https://github.com/Xpra-org/xpra/blob/master/packaging/rpm/distros/fedora.list
• extra packages in the xpra repo:
  • python3-Cython versions older than v3 are not supported and may cause breakage that is just impossible to debug - we only tolerate older versions for now because the github Ubuntu CI has an older version (and maybe it should be upgraded before running any checks instead)
  • xorg-x11-drv-dummy patched, probably usable without the patches - but untested
  • python3-aioquic - not available in Fedora
  • minor (not essential): python3-uinput: the Fedora package was broken and unusable for years (was still broken in Fedora 37: xpra doesn't start: uinput error #3690) - IIRC same for python3-pyu2f but maybe older

[sagitter]

This sounds good, though I suspect that there are going to be a lot of thorny issues.

Let's start with the most obvious ones:

• build packages for multiple python targets #3945 ie: we now provide
  python3.12-xpra (and sub-packages) for Fedora 37, and xpra is actually python3.11-xpra for RHEL 8 / 9 since those have a > python3 which is too old to run xpra v6 - see the (long) package list for Fedora: https://github.com/Xpra-org/xpra/blob/master
  /packaging/rpm/distros/fedora.list

Fedora 37 provides python-3.12 since one week.

python3.11-xpra for RHEL 8 / 9: Xpra will be upgraded in EPEL when Python.3.12 will be available

• extra packages in the xpra repo:

• python3-Cython versions older than v3
  are not supported and may cause breakage that is just impossible to debug - we only tolerate older versions for now because
  the github Ubuntu CI has an older version (and maybe it should be upgraded before running any checks instead)

Same for python-Cython 3: Xpra will not be upgraded in Fedora < 39 because of older Cython.

• xorg-x11-drv-dummy patched, probably usable without the patches - but untested

We can include the patch in Fedora if the package owner agrees.

• python3-aioquic - not available in Fedora

I try to package it

• minor (not essential): python3-uinput: the Fedora package was broken and unusable for years (was still broken in Fedora 37: xpra doesn't start: uinput error #3690) - IIRC same for python3-pyu2f but maybe older

If a packaging error exists, it needs to be reported to Red Hat Bugzilla. Why is/was broken?

[totaam]

Why is/was broken?

python-uinput: Remove (sub)packages from Fedora 30+: python2-uinput - looks like this was left unresolved after years of breakage, but probably eventually fixed without updating the ticket
Input proxy tests use python-uinput which doesn't work on Fedora 37 anymore - looks like a patch exists but upstream is dead?
xpra doesn't start - not clear if the package has been pushed to Fedora 37 as the ticket only mentions 38.

[totaam]

There's another important piece missing from the Fedora repos: https://github.com/Xpra-org/xpra-html5

[sagitter]

This sounds good, though I suspect that there are going to be a lot of thorny issues.
Let's start with the most obvious ones:

• python3-aioquic - not available in Fedora

I try to package it

python3-aioquic needs python3-pylsqpack
python3-pylsqpack needs ls-qpack library
Latest releases of pylsqpack and ls-qpack looks like incompatible
Are they essential?

Why is/was broken?

python-uinput: Remove (sub)packages from Fedora 30+: python2-uinput - looks like this was left unresolved after years of breakage, but probably eventually fixed without updating the ticket Input proxy tests use python-uinput which doesn't work on Fedora 37 anymore - looks like a patch exists but upstream is dead? xpra doesn't start - not clear if the package has been pushed to Fedora 37 as the ticket only mentions 38.

Forget Fedora 37, it will become unsupported in one month.
We can patch python-uinput anyway.

[totaam]

python3-aioquic needs python3-pylsqpack

Yes: https://github.com/Xpra-org/xpra/blob/master/packaging/rpm/python3-pylsqpack.spec
Been building packages for all distros for about a year.

Forget Fedora 37, it will become unsupported in one month.

I understand, but the xpra repository exists because of problems such as this one.

[sagitter]

python3-aioquic needs python3-pylsqpack

Yes: https://github.com/Xpra-org/xpra/blob/master/packaging/rpm/python3-pylsqpack.spec Been building packages for all distros for about a year.

Okay, pylsqpack code archive from Pypi provides a bundled ls-qpack code and it is compiled; instead, pylsqpack code archive from Github repository have not ls-qpack code.

[sergiomb2]

Hello, TLDR .
as side note https://xpra.org/dists/Fedora/39/SRPMS/ I think you have simplified a lot since last time (no asm package for example) , thank you
I already did an scratch for xpra-html5 https://sergiomb.fedorapeople.org/xpra-html5.spec (based on xpra-html5-7.0-1.r1.fc37.src.rpm)

[sagitter]

Why is/was broken?

python-uinput: Remove (sub)packages from Fedora 30+: python2-uinput - looks like this was left unresolved after years of breakage, but probably eventually fixed without updating the ticket Input proxy tests use python-uinput which doesn't work on Fedora 37 anymore - looks like a patch exists but upstream is dead? xpra doesn't start - not clear if the package has been pushed to Fedora 37 as the ticket only mentions 38.

Forget Fedora 37, it will become unsupported in one month. We can patch python-uinput anyway.

That patch was included by me some months ago

Of which patches xorg-x11-drv-dummy currently needs?
These?

0002-Constant-DPI.patch
0006-Dummy-Disconnect.patch

[totaam]

0002-Constant-DPI.patch

This one is for backwards compatibility with older xpra versions. (ie: 3.1.x)
Not strictly needed.

0006-Dummy-Disconnect.patch

Things may work without - not entirely clear.
It may be redundant or impacted by: https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/981

[sagitter]

* extra packages in the xpra repo:

  * [python3-aioquic](https://github.com/Xpra-org/xpra/blob/master/packaging/rpm/python3-aioquic.spec) - not available in Fedora

@sergiomb2

python-aioquic and python-lsqpack are ready for Fedora, can you do the reviews?

[sergiomb2]

where are the packages reviews ?

[sagitter]

where are the packages reviews ?

https://bugzilla.redhat.com/show_bug.cgi?id=2245468
https://bugzilla.redhat.com/show_bug.cgi?id=2245469

[totaam]

FYI:

• Openh264 2.4.0 : de6e6eb
• pylsqpack 0.3.18 : 48670c4
• aioquic 0.9.22 : 7d9756d
• Cython also got updated and we require Cython 3 to build xpra >= 6

[totaam]

I've just installed the Fedora xpra package, and it pulled close to 800GB because of opencv!
Wow. That should never be a Recommends dependency, ever.

[sergiomb2]

it requires python3-opencv and python3-opencv requires a lot , but 800MB ? maybe

rpm -q xpra --requires | grep opencv
python3-opencv

rpm -q python3-opencv --requires | grep opencv
libopencv_alphamat.so.407()(64bit)
libopencv_aruco.so.407()(64bit)
libopencv_barcode.so.407()(64bit)
libopencv_bgsegm.so.407()(64bit)
libopencv_bioinspired.so.407()(64bit)
libopencv_calib3d.so.407()(64bit)
libopencv_ccalib.so.407()(64bit)
libopencv_core.so.407()(64bit)
libopencv_dnn.so.407()(64bit)
libopencv_dnn_superres.so.407()(64bit)
libopencv_face.so.407()(64bit)
libopencv_features2d.so.407()(64bit)
libopencv_flann.so.407()(64bit)
libopencv_freetype.so.407()(64bit)
libopencv_fuzzy.so.407()(64bit)
libopencv_gapi.so.407()(64bit)
libopencv_hdf.so.407()(64bit)
libopencv_hfs.so.407()(64bit)
libopencv_highgui.so.407()(64bit)
libopencv_img_hash.so.407()(64bit)
libopencv_imgcodecs.so.407()(64bit)
libopencv_imgproc.so.407()(64bit)
libopencv_intensity_transform.so.407()(64bit)
libopencv_line_descriptor.so.407()(64bit)
libopencv_mcc.so.407()(64bit)
libopencv_ml.so.407()(64bit)
libopencv_objdetect.so.407()(64bit)
libopencv_optflow.so.407()(64bit)
libopencv_phase_unwrapping.so.407()(64bit)
libopencv_photo.so.407()(64bit)
libopencv_plot.so.407()(64bit)
libopencv_quality.so.407()(64bit)
libopencv_rapid.so.407()(64bit)
libopencv_reg.so.407()(64bit)
libopencv_rgbd.so.407()(64bit)
libopencv_saliency.so.407()(64bit)
libopencv_shape.so.407()(64bit)
libopencv_stereo.so.407()(64bit)
libopencv_stitching.so.407()(64bit)
libopencv_structured_light.so.407()(64bit)
libopencv_surface_matching.so.407()(64bit)
libopencv_text.so.407()(64bit)
libopencv_tracking.so.407()(64bit)
libopencv_video.so.407()(64bit)
libopencv_videoio.so.407()(64bit)
libopencv_viz.so.407()(64bit)
libopencv_wechat_qrcode.so.407()(64bit)
libopencv_ximgproc.so.407()(64bit)
libopencv_xphoto.so.407()(64bit)

[totaam]

but 800MB ? maybe

You're forgetting the transitive dependencies from opencv.
Also, I did include the regular dependencies in the 800MB - but the rest is small in comparison.

[sergiomb2]

IIRC pyhton-opencv is needed for webcam support .. we may put that part in a sub-package ...

[totaam]

python-opencv is needed for webcam support

Only for the client, and noone actually uses it.

we may put that part in a sub-package

Don't do that.

Please do take a moment to look at our RPM packaging to see how things are split instead of guessing how things should be split.

[sergiomb2]

Please do take a moment to look at our RPM packaging to see how things are split instead of guessing how things should be split.

I'm thinking is improve xpra.spec with this new version of xpra , have you any suggest fro Fedora package? , do you want participate in packaging of Fedora ?
In Fedora we can't have Patented Software, we can't have CUDA , but we can have it on RPMFusion ... for example .

ah any pointer ? or suggestions ?

[totaam]

have you any suggest fro Fedora package?

Yes, almost a year's worth of work has gone into the packaging split done here:
https://github.com/Xpra-org/xpra/blob/master/packaging/rpm/xpra.spec
Every change usually has a good reason behind it.

So please ask questions about why things are done this way, rather than going in a different direction.

[totaam]

And most important of all, see:
https://github.com/Xpra-org/xpra/wiki/Download#sub-packages