#11175 Unannounced soname bump of libunistring
Closed: Fixed a year ago by kevin. Opened a year ago by sgallagh.

  • Describe the issue
    libunistring-1.1-1.fc38 breaks the buildroot for Koji because the soname changed and it's in the dependency chain for mock. Please untag this package from F38.

  • When do you need this? (YYYY/MM/DD)
    Immediately

  • When is this no longer needed or useful? (YYYY/MM/DD)
    When the maintainer properly rebuilds dependent packages in a side-tag.

  • If we cannot complete your request, what is the impact?
    No Koji builds for Rawhide or ELN will work.


Untagging it now from f38 and eln.

the spec file also needs to be modified to not use .so.* in %files.

Untagged, buildroot working again now.

Metadata Update from @kevin:
- Issue close_status updated to: Fixed
- Issue status updated to: Closed (was: Open)

a year ago

I somebody following up on the side tag rebuild? It will most likely be needed to disable mock bootstrap in the side tag which requires releng.

I would expect the maintainer/whoever is doing the rebuilds to do that?

The bootstrap disable could be avoided by shipping the old so's in the new package once, rebuilding everything and then dropping them no?

Sorry for the trouble and thanks for looking after that. I'm currently confirming with the upstream whether this SONAME bump is intentional:
https://lists.gnu.org/archive/html/bug-libunistring/2022-12/msg00000.html

The bootstrap disable could be avoided by shipping the old so's in the new package once, rebuilding everything and then dropping them no?

Right, I forgot about this approach :)

Sorry for the trouble and thanks for looking after that. I'm currently confirming with the upstream whether this SONAME bump is intentional:
https://lists.gnu.org/archive/html/bug-libunistring/2022-12/msg00000.html

The answer was it's intentional; so I guess we'd expect more SONAME bumps in libunistring in the future.

I would expect the maintainer/whoever is doing the rebuilds to do that?

What would be the best way to handle this? I can create a side-tag but I don't think I have privilege to rebuild all the dependent packages.

Options might be:
- introduce a compat package with libunistring.so.2
- temporarily provide 2 versions of shlibs from the libunistring package (as we sometimes do for nettle)
- ask the maintainers of dependent packages to rebuild their own
- ask someone in the provenpackager group to deal with rebuilds or apply myself for it

This just broke rawhide again when the mass-rebuild was tagged in. This needs to be properly fixed.

Metadata Update from @churchyard:
- Issue status updated to: Open (was: Closed)

a year ago

@kevin seems to have untagged it again from rawhide (assuming from a thread at the devel list).

Could somebody please untag it from ELN as well?

@ueno The options you listed are all pretty much good.

Filed a review request for the libunistring1.0 compat package:
https://bugzilla.redhat.com/show_bug.cgi?id=2163708

Untagged from eln.

$ koji list-tagged eln libunistring
Build                                     Tag                   Built by
----------------------------------------  --------------------  ----------------
libunistring-1.0-2.eln120                 eln                   distrobuildsync-eln/jenkins-continuous-infra.apps.ci.centos.org
libunistring-1.0-2.fc37                   eln                   releng

libunistring1.0-1.0-1.fc38 is available in f38.

I have verified that it can be installed in mock to replace libunistring-1.0-2.fc37.

Release engineers, please tag it to eln as well and tag the libunistring-1.1-3.fc38 and libunistring-1.1-3.eln125 builds back to f38/eln.

Thanks.

I'm confused what you are asking for here.

➜  ~ koji latest-pkg eln libunistring
Build                                     Tag                   Built by
----------------------------------------  --------------------  ----------------
libunistring-1.0-2.eln120                 eln                   distrobuildsync-eln/jenkins-continuous-infra.apps.ci.centos.org
➜  ~ koji latest-pkg f38 libunistring
Build                                     Tag                   Built by
----------------------------------------  --------------------  ----------------
libunistring-1.0-2.fc37                   f38                   releng

1.1-3 was the one with the soname bump right? did everything get rebuilt?

1.1-3 was the one with the soname bump right?

Yes.

did everything get rebuilt?

Not at all. But a compact package exists now.

I'm confused what you are asking for here.

I'm asking for the previously untagged builds to be retagged back, so new builds can happen in rawhide against the new version. For this to work in ELN, the compact package needs to be tagged there as well.

ok, I missed that that was a compat package... must have read over it too fast.

Tagged them back in.

% koji latest-pkg f38 libunistring
Build                                     Tag                   Built by
----------------------------------------  --------------------  ----------------
libunistring-1.1-3.fc38                   f38                   releng

%  koji latest-pkg eln libunistring
Build                                     Tag                   Built by
----------------------------------------  --------------------  ----------------
libunistring-1.1-3.eln125                 eln                   distrobuildsync-eln/jenkins-continuous-infra.apps.ci.centos.org

Metadata Update from @kevin:
- Issue close_status updated to: Fixed
- Issue status updated to: Closed (was: Open)

a year ago

@ueno Now you can follow with:

  • ask the maintainers of dependent packages to rebuild their own
  • ask someone in the provenpackager group to deal with rebuilds or apply myself for it

The list is:

$ repoquery -q --repo=koji --whatrequires libunistring1.0 --source | pkgname | sort -u
bigloo
boxes
clisp
freeipa
gcal
gettext
gnutls
gssntlmssp
guile
guile22
guile30
libidn2
libpsl
libratbag
maxima
notcurses
rygel
sssd
the_foundation
wcd

Login to comment on this ticket.

Metadata