Backport open-vm-tools 12.3.5 for jammy, lunar and mantic

Noble has 12.3.5 now, would that be even better one (according to the patchlevel bump of .0 to .5) to backport? :)

The bug description says 'MRE' but the bump from 2:12.1.5-3ubuntu0.23.04.3 (lunar-updates) to 2:12.3.0-1~ubuntu0.23.04.1 (lunar UNAPPROVED) is not a micro-release and thus does not fall under the MRE policy. Please clarify here.

Prior art in LP: #1998558 does not mention MREs.

That is absolutely correct, it is not an MRE but under the https://wiki.ubuntu.com/StableReleaseUpdates#Other_safe_cases terms under the scope of an requirement to support new (virtual) hardware. Furthermore there is an agreement with Vmware to help testing those new releases as built in Ubuntu.

This process goes along not only the one you referred to, but is handled this way quite some time:
- https://bugs.launchpad.net/ubuntu/+source/open-vm-tools/+bug/1998558
- https://bugs.launchpad.net/ubuntu/+source/open-vm-tools/+bug/1975767
- https://bugs.launchpad.net/ubuntu/+source/open-vm-tools/+bug/1933143
- https://bugs.launchpad.net/ubuntu/+source/open-vm-tools/+bug/1741390
- https://bugs.launchpad.net/ubuntu/+source/open-vm-tools/+bug/1784638
- https://bugs.launchpad.net/ubuntu/+source/open-vm-tools/+bug/1813944
- https://bugs.launchpad.net/ubuntu/+source/open-vm-tools/+bug/1822204
- https://bugs.launchpad.net/ubuntu/+source/open-vm-tools/+bug/1844834
- https://bugs.launchpad.net/ubuntu/+source/open-vm-tools/+bug/1868012
- https://bugs.launchpad.net/ubuntu/+source/open-vm-tools/+bug/1877672
- https://bugs.launchpad.net/ubuntu/+source/open-vm-tools/+bug/1892266
- https://bugs.launchpad.net/ubuntu/+source/open-vm-tools/+bug/1911831

it might have been just a bad muscle memory to call it MRE, due to the team doing so many others.
The bug description is actually right, a bit simplified compared to my old probably too wordy cases, but refers to the right rules. Just the title is wrong - let me fix that and set it back to in Progress.

@Timo
We do roughly one of these backports per cycle, and yes it was delayed by many other things for so much time that it indeed would now be better to skip 12.3.0 and directly go to 12.3.5.

I've dropped the 12.3.0 uploads from the queues if there will be 12.3.5 uploaded later, thanks

> and therefore we agreed to regularly backport those to the latest LTS.

Who is this agreement between? Nothing is documented on https://wiki.ubuntu.com/StableReleaseUpdates, it doesn't appear to be an agreement involving the SRU Team.

Looking at the prior publishing history of open-vm-tools, we have jumped in jammy from 2:11.3.5-1ubuntu4 to 2:12.1.5-3~ubuntu0.22.04.4 so there is clearly precedent for significant version jumps in this package. However, the first such jump, LP: #1975767, refers to this as an "MRE" which stands for "micro-release exception" and this was clearly not a micro-release to move from 11.3.5 to 12.1.0 upstream.

You reference https://wiki.ubuntu.com/StableReleaseUpdates#Other_safe_cases in this current bug report, but I don't see how this fits as being a "safe" update for hardware enablement. I think a closer examination here is warranted, and a documented exception with clarity about what guardrails exist to ensure these updates are "safe".

Hi Steve,
I think our misunderstanding is deep enough that we really need to get it resolved - sorry for not providing you all we usually do and thereby causing confusion.

The core the misunderstanding seems to be a lot about how to call it.
It is in fact not an MRE and sometimes calling it that way was wrong - sorry for that in the name of the whole team. But that was it, a mistake, and not a try to slip through or anything else similarly sinister.

Now what is it then you might ask - This is actually a regular "platform enablement backport".
I think those do not have a common acronym to use.

> Looking at the prior publishing history of open-vm-tools, we have jumped in
> jammy from 2:11.3.5-1ubuntu4 to 2:12.1.5-3~ubuntu0.22.04.4 so there is
> clearly precedent for significant version jumps in this package.
> However, the first such jump, LP: #1975767, refers to this as an "MRE"
> which stands for "micro-release exception" and this was clearly not a
> micro-release to move from 11.3.5 to 12.1.0 upstream.

The history on this goes much longer, back to 2018 and 10.7.0 -> 10.2.0 in Xenial.
There have been two occasions in the history of the 12 major version bump backports done so far calling it MRE, one was our mistake and one was externals filing it with that name and us not correcting the name. I have now fixed those two old bug titles, so one does not accidentally look back and says "here you see, it was an MRE then".

> You reference https://wiki.ubuntu.com/StableReleaseUpdates#Other_safe_cases in this
> current bug report, but I don't see how this fits as being a "safe" update for
> hardware enablement. I think a closer examination here is warranted, and a documented
> exception with clarity about what guardrails exist to ensure these updates are "safe".

I run into the same sometimes and I'm glad I'm not alone forgetting the past :-)
So after a smile I need to tell you that it was you suggesting it to me back in [1] in 2018.

"""
With my SRU team hat on, I will say that open-vm-tools clearly falls into
the class of packages that have a "platform enablement" (new "hardware
enablement") exception to the usual bugfix-only rule.

Care must of course still be taken to test the updates and avoid
regressions, but in cases where the package must be updated from upstream to
maintain compatibility with the moving target of the OS's substrate (whether
that's hardware, or a cloud platform, or a VM platform), the requirement to
selectively cherry-pick bugfixes is waived.
"""

> Nothing is documented on https://wiki.ubuntu.com/StableReleaseUpdates,
> it doesn't appear to be an agreement involving the SRU Team.

Correct - and that is what we really have to fix.
I have now created [2] and submitted for official approval.

This should provide all the background needed for future iterations on this to be much smoother.

[1]: https://bugs.launchpad.net/ubuntu/+source/open-vm-tools/+bug/1741390/comments/6
[2]: https://wiki.ubuntu.com/OpenVMToolsUpdates

The open-vm-tools SRU exception[1] has been accepted[2][3].

1. https://wiki.ubuntu.com/OpenVMToolsUpdates
2. https://wiki.ubuntu.com/StableReleaseUpdates#open-vm-tools
3. https://lists.ubuntu.com/archives/ubuntu-release/2024-January/005900.html

Ubuntu 23.04 (Lunar Lobster) has reached end of life, so this bug will not be fixed for that specific release.

Hello Bryce, or anyone else affected,

Accepted open-vm-tools into mantic-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/open-vm-tools/2:12.3.5-3~ubuntu0.23.10.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed-mantic to verification-done-mantic. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-mantic. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

Hello Bryce, or anyone else affected,

Accepted open-vm-tools into jammy-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/open-vm-tools/2:12.3.5-3~ubuntu0.22.04.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed-jammy to verification-done-jammy. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-jammy. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

I have requested our QE team to test the 12.35 OVT packages on both jammy and mantic.

Thanks John.

It looks like this also includes a fix for LP: #2043897 that was accepted into Debian. Thanks for forwarding it to them, I hadn't noticed it got in.

I have run the testing with the provided 12.3.5 OVT packages on both Jammy and Mantic.
The packages work well.
BTW, an unexpected warning "Unknown option: q" is reported while try to install open-vm-tools-containerinfo, open-vm-tools-sdmp and open-vm-tools-salt-minion.
The warning has been tracked by https://bugs.launchpad.net/ubuntu/+source/open-vm-tools/+bug/1999945.

The "q" warning is already present in the packages from the updates pocket, so it's not being introduced in this SRU:

(...)
Setting up open-vm-tools-containerinfo (2:12.1.5-3~ubuntu0.22.04.4) ...
Unknown option: q
inactive
Processing triggers for libc-bin (2.35-0ubuntu3.6) ...

ubuntu@j:~$ echo $?
0

Thanks for flagging it, though.

Because of the ongoing autopkgtest db rebuild, the excuses page and pending sru report might not be accurate at this time regarding autopkgtest results. I then checked the DEP8 results manually.

open-vm-tools itself has no autopkgtests.

Consulting the DB, I saw that there are no dependent tests trigger by it either:

$ sqlite3 autopkgtest.db "SELECT result.run_id, package FROM test, result WHERE test.id = result.test_id AND test.release = 'mantic' AND result.triggers LIKE '%open-vm-tools%';"
$

$ sqlite3 autopkgtest.db "SELECT result.run_id, package FROM test, result WHERE test.id = result.test_id AND test.release = 'jammy' AND result.triggers LIKE '%open-vm-tools%';"
$

The verification of the Stable Release Update for open-vm-tools has completed successfully and the package is now being released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.

This bug was fixed in the package open-vm-tools - 2:12.3.5-3~ubuntu0.22.04.1

---------------
open-vm-tools (2:12.3.5-3~ubuntu0.22.04.1) jammy; urgency=medium

  * Backport recent open-vm-tools release v12.3.5
    (LP: #2028420)

open-vm-tools (2:12.3.5-3) unstable; urgency=medium

  * [7699f7a] Fix typo in last upload

open-vm-tools (2:12.3.5-2) unstable; urgency=medium

  * [80ed173] Disable arm cross-build
  * [61a0f4d] (Temporarily) build with diffoscope
  * [d929c44] Fix containerinfo plugin directory.
    Thanks to John Wolfe (Closes: #1056205)

open-vm-tools (2:12.3.5-1) unstable; urgency=high

  * [1b07bee] Remove api doc build dir with dh_clean.
    Thanks to Lucas Nussbaum (Closes: #1046018)
  * [de2e0ba] New upstream version 12.3.5 (Closes: #1054662)
    - New upstream release fixes two CVEs:
      CVE-2023-34059 CVE-2023-34058
      Closes: #1054666

open-vm-tools (2:12.3.0-1) unstable; urgency=high

  * [4ed4be4] New upstream version 12.3.0
    (Closes: #1050972)
    CVE-2023-20900
    Adressing this CVE also Closes: #1050970
    There are no new features in the open-vm-tools 12.3.0 release. This is
    primarily a maintenance release, details can be found at
    https://github.com/vmware/open-vm-tools/blob/stable-12.3.0/ReleaseNotes.md
  * [779d338] drop d/p/debian/grpc_1.51: no more needed

open-vm-tools (2:12.2.5-1) unstable; urgency=medium

  * [8c0c33f] New upstream version 12.2.5
    (Closes: #1037546)
    CVE-2023-20867
  * [232810e] d/p/*: add DEP-3 patch headers

open-vm-tools (2:12.2.0-1) unstable; urgency=medium

  * [bebda7c] New upstream version 12.2.0
    (Closes: #1032607)
  * [d266aa7] Add libabsl-dev as explicit build-dependency.
    Not needed in Debian, but let's support the Deepin package maintainer.
    (Closes: #1032305)

 -- Bryce Harrington <email address hidden> Tue, 05 Dec 2023 13:18:04 -0800

This bug was fixed in the package open-vm-tools - 2:12.3.5-3~ubuntu0.23.10.1

---------------
open-vm-tools (2:12.3.5-3~ubuntu0.23.10.1) mantic; urgency=medium

  * Backport recent open-vm-tools release v12.3.5
    (LP: #2028420)

open-vm-tools (2:12.3.5-3) unstable; urgency=medium

  * [7699f7a] Fix typo in last upload

open-vm-tools (2:12.3.5-2) unstable; urgency=medium

  * [80ed173] Disable arm cross-build
  * [61a0f4d] (Temporarily) build with diffoscope
  * [d929c44] Fix containerinfo plugin directory.
    Thanks to John Wolfe (Closes: #1056205)

open-vm-tools (2:12.3.5-1) unstable; urgency=high

  * [1b07bee] Remove api doc build dir with dh_clean.
    Thanks to Lucas Nussbaum (Closes: #1046018)
  * [de2e0ba] New upstream version 12.3.5 (Closes: #1054662)
    - New upstream release fixes two CVEs:
      CVE-2023-34059 CVE-2023-34058
      Closes: #1054666

 -- Bryce Harrington <email address hidden> Tue, 05 Dec 2023 13:18:07 -0800