jammy: 4.21.0-7 dropped mstlink binary
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
mstflint (Ubuntu) |
New
|
Undecided
|
Unassigned | ||
Jammy |
Fix Committed
|
Critical
|
dann frazier |
Bug Description
[Impact]
The mstlink and mstreg binaries have regressed in the last jammy update. This is because a new upstream landed in jammy as an SRU outside of the SRU process, and is based on upstream's debian/ packaging, not Debian's. One of the differences between these version is the use of different configure flags.
[Test Case]
/usr/bin/mstlink and /usr/bin/mstreg have returned.
[What Could Go Wrong]
While this update does restore files that were dropped in the last "SRU", it does drop some files that the Debian packaging does not ship. This includes some header files, some .a files, and 2 manpages for binaries that neither version of the package ships.
It is possible that somebody has started using these files, and by taking them away we break someone. That seems unlikely - these appear to be for internal-use only.
Here's a complete diff:
--- mstflint.jammy.orig 2024-04-12 21:40:42.700199967 +0000
+++ mstflint.jammy.ppa 2024-04-12 21:58:59.495997299 +0000
@@ -6,37 +6,20 @@
/usr/bin/mstflint
/usr/bin/
/usr/bin/
+/usr/bin/mstlink
/usr/bin/mstmcra
/usr/bin/mstmread
/usr/bin/
/usr/bin/mstmwrite
/usr/bin/
+/usr/bin/mstreg
/usr/bin/
/usr/bin/
/usr/bin/
/usr/bin/mstvpd
-/usr/include
-/usr/include/
-/usr/include/
-/usr/include/
-/usr/include/
-/usr/include/
-/usr/include/
-/usr/include/
-/usr/include/
-/usr/include/
-/usr/include/
-/usr/include/
-/usr/include/
-/usr/include/
/usr/lib
/usr/lib/
-/usr/lib/
-/usr/lib/
-/usr/lib/
-/usr/lib/
/usr/lib/
-/usr/lib/
/usr/lib/
/usr/lib/
/usr/lib/
@@ -150,13 +133,14 @@
/usr/share/
/usr/share/
/usr/share/
+/usr/share/lintian
+/usr/share/
+/usr/share/
/usr/share/man
/usr/share/
-/usr/share/
/usr/share/
/usr/share/
/usr/share/
-/usr/share/
/usr/share/
/usr/share/
/usr/share/
@@ -196,6 +180,10 @@
/usr/share/
/usr/share/
/usr/share/
-/usr/include/
-/usr/include/
-/usr/lib/
+/usr/share/
+/usr/share/
+/usr/share/
+/usr/share/
+/usr/share/
+/usr/share/
+/usr/share/
Changed in mstflint (Ubuntu): | |
assignee: | nobody → Brad Figg (brad-figg) |
Changed in mstflint (Ubuntu Jammy): | |
status: | New → In Progress |
assignee: | nobody → dann frazier (dannf) |
description: | updated |
description: | updated |
description: | updated |
The specific problem here is that the newer problem dropped the --enable- db-generic- tools configure flag.
But there seems to be a *much* bigger problem here. I see that an entirely new mstflint upstream release landed in both the updates and security pockets with no reference to either a bug or a CVE in the changelog. The packaging looks completely different to what was there before, with no common entries in the changelog. It bears little resemblance even to the same upstream version that landed in mantic;
$ debdiff mstflint_ 4.21.0+ 1-1.dsc mstflint_ 4.21.0- 7.dsc
[...]
126 files changed, 8106 insertions(+), 62755 deletions(-)
I do understand the need for new mstflint packages in stable releases - in fact, I've done one before: /launchpad. net/bugs/ 1864475
https:/
.. but this seems to have sidestepped the SRU procedure altogether.
Note that I had proposed a special case policy for doing these updates, which specifically requires testing that no binaries were removed: /wiki.ubuntu. com/mstflint- Updates
https:/
The SRU team elected to hold off on approving that because it wasn't clear if that time was a one-off.