openSUSE

[friki67]

Hello.
I'm using openSUSE Tumbleweed. The package version in official repositories is:

Information for package xpra:
-----------------------------
Repository     : Tumbleweed_OSS
Name           : xpra
Version        : 5.0+git20221127.3e61ef1c-2.8
Arch           : x86_64
Vendor         : openSUSE
Installed Size : 18,2 MiB
Installed      : Yes
Status         : up-to-date
Source package : xpra-5.0+git20221127.3e61ef1c-2.8.src
Upstream URL   : https://www.xpra.org/
Summary        : Remote display server for applications and desktops

I've read that I should not use the distro's official package, but the one xpra repositories provide.

I know that openSUSE is not supported. Anyway, is there an easy way to install latest official Xpra in openSUSE?

[sbradnick]

I'm the maintainer of xpra/xpra-html5 packages in openSUSE and I use xpra daily in TW. I took them over around April of 2022 and make a couple of adjustments to make them more agile going forward. Namely separating them out into 2 packages vs. 1 package that also included the html5 stuff.

I'll certainly agree (to the point no one has made yet :P) that the version numbers aren't what I'd assume Antoine would want/expect to see, but they're determined at build time and it doesn't feel worth the (even minimal) effort to add .diffs to adjust the versioning to official release numbers ... since these are basically point-in-time git snapshots (probably the wrong word) which I grab from time to time (and/or when a release happens) and test out for a week before pushing to the devel repo, which in turn is auto-ingested into Factory in about a week after that.

I'm happy to discuss things w/ Tumbleweed users if they're having issues w/ the packaging, but I'm not too keen on taking it to a more generic numbered release cycle (a la 4.4.6 and 8.1) type of output just for the sake of it.

Certainly, building from source is always an option for anyone (I use build.opensuse.org) and Antoine's take is very important here, but this method has been working well for me for over a year and I'm much more interested in continuing it vs. gutting it to do a github release cycle scenario.

[friki67]

Hello. Thank you for such a clear and complete answer. Knowing all that, I'm sure that I don't need a more "official" package. I'll keep using and testing it. Thank you again

[totaam]

Namely separating them out into 2 packages vs. 1 package that also included the html5 stuff.

The html5 client was split from the xpra code many many years ago. It just isn't possible to build xpra-html5 from the xpra source tree anymore.
The correct way to package xpra is to split it into multiple sub-packages, ie for v5:
https://github.com/Xpra-org/xpra/wiki/Download#sub-packages
Anything coarser will cause dependency issues.

that the version numbers aren't what I'd assume Antoine would want/expect to see

I see nothing wrong with that.

but I'm not too keen on taking it to a more generic numbered release cycle (a la 4.4.6 and 8.1) type of output just for the sake of it.

I don't understand what this means.
These are stable version numbers, which correspond to specific releases.
Adding any git information to these would be redundant, but whatever.

[sbradnick]

Namely separating them out into 2 packages vs. 1 package that also included the html5 stuff.

The html5 client was split from the xpra code many many years ago. It just isn't possible to build xpra-html5 from the xpra source tree anymore. The correct way to package xpra is to split it into multiple sub-packages, ie for v5: https://github.com/Xpra-org/xpra/wiki/Download#sub-packages Anything coarser will cause dependency issues.

Right, at the point I took it over there was 1 xpra package ~ but that's not the case anymore. I have:

• xpra
• xpra-html5

that the version numbers aren't what I'd assume Antoine would want/expect to see

I see nothing wrong with that.

Great :) I wasn't sure if it'd be annoying to have any openSUSE related questions referring a version that's basically 'the next one' - but obviously you'd be aware of/understand the +gitYYYYMMDD.<commit hash> part of it to determine more of an exact pseudo-next-version.

but I'm not too keen on taking it to a more generic numbered release cycle (a la 4.4.6 and 8.1) type of output just for the sake of it.

I don't understand what this means. These are stable version numbers, which correspond to specific releases. Adding any git information to these would be redundant, but whatever.

I probably didn't phrase that right. I have absolutely no issues whatsoever w/ your versioning scheme, but for the rolling openSUSE Tumbleweed especially, I prefer using the pseudo-next-version w/ the date and git commit hash partial as that plays very easily with pulling in the new source. Basically, there's intelligent scripting in OBS which will do the git pulldown and construct a versioned tarball as well as pull the changelog entries into a .changes file. Just makes frequent updates easier, especially since you squash bugs regularly 👍

[totaam]

Right, at the point I took it over there was 1 xpra package ~ but that's not the case anymore. I have:

As explained above, you really should be using sub-packages by now. Please see the link.

will do the git pulldown and construct a versioned tarball

That seems backwards. tarballs already exist and they are immutable and carefully crafted.
Do your scripts also update the src info?

[sbradnick]

Right, at the point I took it over there was 1 xpra package ~ but that's not the case anymore. I have:

As explained above, you really should be using sub-packages by now. Please see the link.

I see that now (as a part of xpra.spec). I'm not sure if our existing xpra.spec was ever a copy of what you provide (which is really cool it's there), but I'm sure there are some differences required on our end we have to put into our openSUSE:Factory/xpra/xpra.spec. I wasn't aware there were so many sub-packages, but I can't follow any project as closely as I'd like. I'll see what I can do to mimic the sub-packages you've setup.

will do the git pulldown and construct a versioned tarball

That seems backwards. tarballs already exist and they are immutable and carefully crafted. Do your scripts also update the src info?

They're not my scripts, it's all part of OBS service modules where I can give the osc binary a git https URL and it'll pull everything together and perform defined actions (such as changelog updates). A release tarball is very useful, but then I can't [as] easily incorporate recent commits into the package for bugfixes. You certainly have a much more regular release cycle than most, so that's great - but I prefer this approach (which is built into OBS, not something I've invented) to keep things current.

[totaam]

a git https URL and it'll pull everything together and perform defined actions

I wouldn't be surprised if the xpra --version information was either incomplete or incorrect since these tarballs are unlikely to be generated using the sdist build command.

I'm not sure if our existing xpra.spec was ever a copy...

Probably only "inspired".
I had a quick look and this file is out of date, the dependencies need fixing:

• python3-lz4 has not been used for a few versions
• requiring python3-opencv is extremely wasteful
• xpra does not use python3-setuptools at runtime at all
• python3-pynacl, python3-pycparser and many others are not used by xpra itself so I would assume they should be added as dependencies elsewhere (ie: paramiko)
  etc.

[sbradnick]

a git https URL and it'll pull everything together and perform defined actions

I wouldn't be surprised if the xpra --version information was either incomplete or incorrect since these tarballs are unlikely to be generated using the sdist build command.

Here's what I get:

$ xpra --version
xpra v5.0-r33693M (g2a908f54) beta

I'm not sure if our existing xpra.spec was ever a copy...

Probably only "inspired". I had a quick look and this file is out of date, the dependencies need fixing:

• python3-lz4 has not been used for a few versions
• requiring python3-opencv is extremely wasteful
• xpra does not use python3-setuptools at runtime at all
• python3-pynacl, python3-pycparser and many others are not used by xpra itself so I would assume they should be added as dependencies elsewhere (ie: paramiko)
  etc.

Very good :) I've cleaned it up according to what you've outlined above[1], no immediate openSUSE-specific issues seen so far - I'll keep using this iteration and if I don't happen upon a problem will push it forward.

[1]

-Requires:       python3-lz4
-Requires:       python3-opencv
-Recommends:     python3-pycparser
-Recommends:     python3-pynacl
-Recommends:     python3-pyparsing
-Recommends:     python3-setuptools

Thinking back on it, I added some[2] of those relatively recently after looking @ https://github.com/Xpra-org/xpra/blob/master/docs/Build/Dependencies.md

[2]

+Recommends:     python3-asn1crypto
+Recommends:     python3-cffi
+Recommends:     python3-cryptography
+Recommends:     python3-decorator
+Recommends:     python3-idna
+Recommends:     python3-ipaddress
+Recommends:     python3-packaging
+Recommends:     python3-pyasn1
+Recommends:     python3-pycparser
+Recommends:     python3-pynacl
+Recommends:     python3-pyparsing
+Recommends:     python3-setuptools
+Recommends:     python3-six

[totaam]

OTOH none of these should be needed as direct Recommends dependencies, only cryptography.
This dependency page lists full dependencies, including transitive dependencies which should be managed by the packages themselves.