RPM packaging of Xpra for Fedora

sagitter commented 9 months ago

@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 commented 9 months ago

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:

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: #3690) - IIRC same for python3-pyu2f but maybe older

sagitter commented 9 months ago

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 commented 9 months ago

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 commented 9 months ago

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

sagitter commented 9 months ago

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 commented 9 months ago

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 commented 9 months ago

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 commented 9 months ago

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 commented 9 months ago

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 commented 9 months ago

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 commented 9 months ago

* 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 commented 9 months ago

where are the packages reviews ?

sagitter commented 9 months ago

where are the packages reviews ?

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

totaam commented 8 months ago

FYI:

Openh264 2.4.0 : de6e6eb23b347f1d3b08746936eb1705469ff3ee
pylsqpack 0.3.18 : 48670c46137681efc6a1efb558d0d46edb966c94
aioquic 0.9.22 : 7d9756dbc634022f9ef4739a01428e74519a7db1
Cython also got updated and we require Cython 3 to build xpra >= 6

totaam commented 6 months ago

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 commented 6 months ago

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 commented 6 months ago

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 commented 6 months ago

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

totaam commented 6 months ago

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 commented 2 months ago

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 commented 2 months ago

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 commented 2 months ago

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

Xpra-org / xpra

RPM packaging of Xpra for Fedora #4035