I am not sure I understand the change on the version to 1.21.

While I agree we could use upstream gitlab snapshots instead of having a dedicated script (I've done that for Xwayland standalone), we do not plan on switching to 1.21 in any forseeable future considering that upstream has no plan to release 1.21, nor even make pre-releases for any Xserver but Xwayland.

Changing this means we would ship 1.21 instead of the stable branch, no?

Changing this means we would ship 1.21 instead of the stable branch, no?

Indeed, I've fixed by removing the version change and tested locally.

Also, I've switched to use the 1.20.99.0 version in my copr that enables the snapshot.

Changing this means we would ship 1.21 instead of the stable branch, no?

Indeed, I've fixed by removing the version change and tested locally.

Also, I've switched to use the 1.20.99.0 version in my copr that enables the snapshot.

But the point is, we don't want to switch to the unstable git master branch from upstream without any plan upstream to a release any time soon.

If you are missing some fixes from the git master branch, best is to backport it to the stable branch server-1.20-branch upstream and it will be picked up next time a a release is made upstream.

But switching to git master for the Xserver downstream is, well, way too risky I reckon, the API/ABI is not stable by definition.

Yes, I agree that for this PR and as far a fedora rawhide is concerned, git master is too risky.
But as gitdate isn't enabled, it's only keeping stable releases for this PR.

With that said, I might send a separate PR for the backport needs for tegra (mainly around drm modifiers support).

For my copr, using git master seems easier at this step as I want to test others patches related to xorg server and tegra and thoses patches are modeleted against xserver git master. So backporting to stable is annoying. But maybe I will revisit this at some point.

For my copr, using git master seems easier at this step as I want to test others patches related to xorg server and tegra and thoses patches are modeleted against xserver git master. So backporting to stable is annoying. But maybe I will revisit this at some point.

Granted, I am no expert in rpm snapshot versioning, but from my understanding of the review of bug 1912335 for Xwayland standalone, the snapshot versioning here is not correct based on:

• https://docs.fedoraproject.org/en-US/packaging-guidelines/Versioning/#_snapshots
• https://docs.fedoraproject.org/en-US/packaging-guidelines/Versioning/#_versioning_prereleases_with_tilde

If gitlab is set, the version should be 1.20.99.1 and a release 0.n plus a pre-release-snapshot versioning whereas, if not set, it should be 1.20.10 (as of today) with a release n.

Considering the API/ABI differ, a driver built against 1.20.99.1 won't load/run on xserver 1.20.x so keeping the version at 1.20.x with gitdate set seems broken.

Right, I don't want to complexity more than needed. and specially change the version field.

About the release field, you are indeed right, given we are before the 1.20.99.1 tag (which is usually how development versions are tagged), release field should be < 1.
I will fix in my copr to avoid any bad interaction with fedora package if even a later xorg is updated.

About gitdate , as it's unset in my current PR (fix by a previous forced push), the intend is also to keep using 1.20.x for fedora...

Yeah, agreed, it's a welcome cleanup and it doesn't change the stable use case.

Are you sure about dropping the dot in the release though?

Looks like you are right about the dot, I've over-think the issue.
I've kept the dot force pushed with the commit removed.

Thanks for the reviews.

@ofourdan thx for the comments. Anything missing from your POV ?

@ofourdan thx for the comments. Anything missing from your POV ?

Looks fine to me.

I've pinged my fellow colleagues to get their inputs as well.

are those three lines actually needed? the *tar* should catch anything we have, isn't it?

fun fact: commit0 doesn't seem to be needed, we can use shortcommit in the URL as well. (just tested using 5429791b)

LGTM minus the two comments above (sorry, not used to pagure and whoah, its UI is different to gh/gl)

@whot, thanks for the comments.

About commit0, it's part of the fedora guidelines for SourceURL:
https://fedoraproject.org/wiki/Packaging:SourceURL#Git_Hosting_Services

About .gitignore, I don't know which new compression format will arise. But the main idea is to avoid bothering merge conflicts on this file. and if xserver/xorg-server are the main expected archive, maybe a new archive name can be used at some point... So this case will be catched.
Ultimately, this file can has multiple match.

Hello,

A reminder of this PR, or any issue ?

Thanks in advances.

Build failed. More information on how to proceed and troubleshoot errors available at https://fedoraproject.org/wiki/Zuul-based-ci

• check-for-arches : SUCCESS in 1m 11s
• rpm-scratch-build : SUCCESS in 10m 39s
• rpm-scratch-build-s390x : SUCCESS in 17m 30s (non-voting)
• rpm-scratch-build-ppc64le : SUCCESS in 11m 21s (non-voting)
• rpm-scratch-build-i686 : SUCCESS in 10m 06s (non-voting)
• rpm-scratch-build-armv7hl : SUCCESS in 17m 25s (non-voting)
• rpm-scratch-build-aarch64 : SUCCESS in 12m 22s (non-voting)
• rpm-linter : FAILURE in 6m 03s
• rpm-rpminspect : FAILURE in 10m 00s (non-voting)
• check-for-tests : SUCCESS in 1m 08s
• rpm-install-test : SUCCESS in 1m 57s
• rpm-test : SKIPPED