Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RPM packaging of Xpra for Fedora #4035

Closed
5 tasks
sagitter opened this issue Oct 15, 2023 · 28 comments
Closed
5 tasks

RPM packaging of Xpra for Fedora #4035

sagitter opened this issue Oct 15, 2023 · 28 comments
Labels
enhancement New feature or request

Comments

@sagitter
Copy link

sagitter commented Oct 15, 2023

@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.

@sagitter sagitter added the enhancement New feature or request label Oct 15, 2023
@totaam
Copy link
Collaborator

totaam commented Oct 15, 2023

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:

@sagitter
Copy link
Author

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:

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.

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

I try to package it

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

@totaam
Copy link
Collaborator

totaam commented Oct 16, 2023

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
Copy link
Collaborator

totaam commented Oct 16, 2023

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

@sagitter
Copy link
Author

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:

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
Copy link
Collaborator

totaam commented Oct 16, 2023

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
Copy link
Author

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
Copy link

sergiomb2 commented Oct 17, 2023

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
Copy link
Author

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
Copy link
Collaborator

totaam commented Oct 18, 2023

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
Copy link
Author

* 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
Copy link

where are the packages reviews ?

@sagitter
Copy link
Author

where are the packages reviews ?

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

@totaam
Copy link
Collaborator

totaam commented Dec 3, 2023

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
Copy link
Collaborator

totaam commented Jan 17, 2024

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
Copy link

sergiomb2 commented Jan 17, 2024

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
Copy link
Collaborator

totaam commented Jan 18, 2024

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
Copy link

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

@totaam
Copy link
Collaborator

totaam commented Jan 21, 2024

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
Copy link

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
Copy link
Collaborator

totaam commented May 10, 2024

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
Copy link
Collaborator

totaam commented May 10, 2024

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

@totaam
Copy link
Collaborator

totaam commented Aug 17, 2024

Almost a year on, I've just tried to install xpra from the default Fedora 41 repos and it wanted to pull in 800MB of dependencies that aren't needed.
No thanks.

@totaam
Copy link
Collaborator

totaam commented Oct 9, 2024

Not heard back.

@totaam totaam closed this as completed Oct 9, 2024
@sergiomb2
Copy link

ENOTIME

@totaam
Copy link
Collaborator

totaam commented Oct 10, 2024

ENOTIME

If simply removing the unnecessary python-opencv dependency takes years, we are doomed.

@sergiomb2
Copy link

ENOTIME

If simply removing the unnecessary python-opencv dependency takes years, we are doomed.

hum I'd like check python-opencv to see if just load what is need ...

I removed the line

https://bodhi.fedoraproject.org/updates/?packages=xpra
https://bodhi.fedoraproject.org/updates/FEDORA-2024-a3375cdaff
https://bodhi.fedoraproject.org/updates/FEDORA-2024-dcfab7f23c
https://bodhi.fedoraproject.org/updates/FEDORA-2024-ce88b6cabe

@totaam
Copy link
Collaborator

totaam commented Oct 12, 2024

Thanks.

check python-opencv to see if just load what is need

I am confident that almost no-one on Fedora has ever used the webcam, since you would need a kernel module which is not available from the Fedora repositories, or connect to another server distro that does (and they don't enable it by default either).
So this was costing everyone to download 800MB extra for an unusable feature..

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants