Soname change and transition started without a ffe

Bug #1943288 reported by Sebastien Bacher
20
This bug affects 2 people
Affects Status Importance Assigned to Milestone
libffi (Ubuntu)
Fix Released
High
Matthias Klose

Bug Description

It seems the recent upload includes a soname change and is starting a transition, such changes at the point of the cycle would require a ffe

Changed in libffi (Ubuntu):
importance: Undecided → High
tags: added: impish rls-ii-incoming
Revision history for this message
Steve Langasek (vorlon) wrote :

I've reviewed the history here; libffi8 has been in impish-proposed since June 30. So this is not something that requires a freeze exception, just follow-through on the migration.

Changed in libffi (Ubuntu):
status: New → Fix Released
Revision history for this message
Sebastien Bacher (seb128) wrote :

Alright, unsure why the transition hadn't been started between june and now, the timing is a bit unfortunate since it's blocking stack of packages in proposed before beta now but let's take that discussion elsewhere if that's not a release concern

Revision history for this message
Steve Langasek (vorlon) wrote :

Ok so it turns out I misread this: the upload to Debian was in June, but this was only synced to impish on Sep 10. And while it's not an soname transition in the usual sense, it is a new upstream version, which we have reports of regressing the desktop. Yes this needs to be reviewed with respect to feature freeze.

It is also presently blocking a lot of packages in -proposed which are being rebuilt against libffi8 and can't migrate.

Changed in libffi (Ubuntu):
status: Fix Released → New
assignee: nobody → Matthias Klose (doko)
Revision history for this message
Sebastien Bacher (seb128) wrote :

There are several desktop packages which started having red autopkgtests due to the update

https://autopkgtest.ubuntu.com/packages/g/gtk+3.0
https://autopkgtest.ubuntu.com/packages/p/python-dbusmock
https://autopkgtest.ubuntu.com/packages/u/umockdev

The i386 tests also showed problems but it could be that they just need to be retried with the current revision since it seems the issues were mostly installability problems

Revision history for this message
Sebastien Bacher (seb128) wrote :

not directly related but we should try to ensure that libffi updates exercise the tests from some of its rdepends as gjs, it's not working today since those depends on libglib and not directly on libffi which means the update could have migrated despite the issue if we hadn't be lucky

Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in libffi (Ubuntu):
status: New → Confirmed
tags: removed: rls-ii-incoming
Revision history for this message
Steve Langasek (vorlon) wrote :

The glib-related regressions have been fixed in a subsequent upload and autopkgtests are now green. Closing this bug to unblock migration.

Changed in libffi (Ubuntu):
status: Confirmed → Fix Released
Changed in libffi (Ubuntu):
status: Fix Released → New
Revision history for this message
Sebastien Bacher (seb128) wrote :

Sorry but no, the reason this bug was opened is that the upload is a feature freeze break, Steve you wrote yourself in comment #3 that it needed to be reviewed in that regard. The question on whether this upload deserves an exception hasn't been answered by the release team. And if the outcome is 'yes because the uploaders pushed ahead meanwhile and it's easier to finish than revert now' that would be pretty disappointing from a project perspective since it just sends the message that 'if you want to break a freeze, just don't ask for permission but keep going with uploads', at which point we should probably just remove the freezes

Revision history for this message
Steve Langasek (vorlon) wrote :

Matthias has communicated out of band that the regressions were not due to new features in the upstream code, but due to a misconfiguration of the build. That has now been addressed, and with my release team hat I don't see any further cause for concern.

The feature freeze is meant to ensure review of new features, not just of all new upstream code. I don't see any evidence that there are new features here. (exec-static-tramp may be a new feature, but it has now been - correctly - disabled in the build.)

Changed in libffi (Ubuntu):
status: New → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.