[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#1089792: marked as done (transition: openxr-sdk-source)

Your message dated Tue, 17 Dec 2024 18:06:49 +0100
with message-id <15d2bb86-2f13-40d6-8ee5-30e678ad2838@debian.org>
and subject line Re: Bug#1089792: Packages needing update
has caused the Debian Bug report #1089792,
regarding transition: openxr-sdk-source
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
1089792: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1089792
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message --- 
Package: release.debian.org
Severity: normal
User: release.debian.org@packages.debian.org
Usertags: transition
X-Debbugs-Cc: openxr-sdk-source@packages.debian.org
Control: affects -1 + src:openxr-sdk-source

OpenXR 1.1 is a compatible minor release. However, convention had
developers using the XR_CURRENT_API_VERSION define to specify the
version they wanted to use. When this changed to a 1.1.x version, it
meant that the app would no longer run against 1.0 runtimes, which is
not desired behavior.

The OpenXR WG noticed this problem, unfortunately after initial 1.1.x
release, and added defines that lock the major and minor version, in
the 1.1.37 release (second 1.1.x release). [1] So, in practice, while
the API and ABI is compatible, applications that used the established
convention need to replace usage of XR_CURRENT_API_VERSION with
XR_API_VERSION_1_0 to retain desired behavior when they first rebuild
against a 1.1.x release.

Again: the ABI is compatible (one new export), and so is the API,
**except that** the value of XR_CURRENT_API_VERSION changed in a way
that probably does not reflect the desires of applications when
rebuilt. I am not 100% sure this requires a package transition but I
thought it was better to be safe than sorry. (Hence why I shipped the
1.0.34 package recently despite it being outdated by the time I could
get to that package again.)

Unfortunately there is no 1.0.x release that defines the new
XR_API_VERSION_1_0 macro, but I'm not opposed to patching that in to
the 1.0.34 (last 1.0-only release) currently in unstable/testing. It
would be equal to XR_CURRENT_API_VERSION in that version.


Full disclosure: I am the OpenXR WG Spec Editor, which means I
effectively serve as the upstream contact for openxr-sdk-source, as
well as the packager. I've maintained Debian packages for some years,
but this is my first time with a Debian package transition.


[1]
https://github.com/KhronosGroup/OpenXR-Docs/blob/main/CHANGELOG.Docs.md#openxr-specification-1137-2024-05-23

Ben file:

title = "openxr-sdk-source";
is_affected = .build-depends ~ /libopenxr-dev/;

Attachment: signature.asc
Description: This is a digitally signed message part


--- End Message ---
--- Begin Message --- 
On 12/12/2024 18:41, Rylie Pavlik wrote:

FWIW, in case this didn't work from my original report, I believe the
only packages needing update besides openxr-sdk-source are:

- gxr
- xr-desktop (possibly, might just get the fix via gxr)

Going to get upstream patches sent soon, I'm in touch with upstream
there too.

https://gitlab.freedesktop.org/xrdesktop/gxr/-/blob/main/src/gxr-context.c#L315


Apps built against the new SDK will be able to run fine against the old
SDK, back to 1.0.6 for sure and 1.0.3 if they only use extensions
defined back then.
I don't think we need a transition here as there will be nothing to rebuild IIUC. So go ahead and file bugs / send patches as needed. 

Cheers,
Emilio

--- End Message ---
Reply to: