Comments

1260 Comments

This bumps the soname of libreport.so from libreport.so.0 to libreport.so.1, so it cannot go stable without at minimum rebuilds of everything in Fedora that depends on libreport.so.0, which looks to be at least:

  • abrt
  • abrt-java-connector
  • reportd

However, also note that soname bumps are generally supposed to be avoided entirely as much as possible in stable updates, and especially for critpath packages. Is this one really necessary? See the update policy: "ABI changes in general are very strongly discouraged, they force larger update sets on users and they make life difficult for third-party packagers..."

note, if we go ahead with this bump, the rebuilds of dependent packages need to be added to this update, not submitted separately.

note, if we go ahead with this bump, the rebuilds of dependent packages need to be added to this update, not submitted separately.

This bumps the soname of libreport.so from libreport.so.0 to libreport.so.1, so it cannot go stable without at minimum rebuilds of everything in Fedora that depends on libreport.so.0, which looks to be at least:

  • abrt
  • abrt-java-connector
  • reportd

However, also note that soname bumps are generally supposed to be avoided entirely as much as possible in stable updates, and especially for critpath packages. Is this one really necessary? See the update policy: "ABI changes in general are very strongly discouraged, they force larger update sets on users and they make life difficult for third-party packagers...Package maintainers SHOULD: Push only major bug fixes and security fixes to the previous stable releases [this refers to Fedora 31 at present]..."

This update actually seems to have broken FreeIPA replica deployment in openQA. Unfortunately for some reason the openQA tests didn't run on this update, so we didn't notice :( See https://bugzilla.redhat.com/show_bug.cgi?id=1868482

I explained and fixed the issue @robatino described above here and here. Not sure if we need to do anything for the change to gating.yaml to take effect, though.

the openQA failures here can be ignored, they're due to the update not containing any x86_64 or noarch packages. Telling openQA not to run if there are no packages for it to test is actually kind of awkward and it happens fairly rarely so I just let it be.

karma

As the openQA results show, this breaks FreeIPA server deployment. See https://bugzilla.redhat.com/show_bug.cgi?id=1857043 (same bug in Rawhide) for more details.

karma

As the openQA results show, this breaks FreeIPA server deployment. See https://bugzilla.redhat.com/show_bug.cgi?id=1857043 (same bug in Rawhide) for more details.

per openQA results, FreeIPA server deployment is broken with this update.

per openQA results, FreeIPA server deployment is broken with this update.

As discussed on IRC, that's because I adjusted how the tests work recently, and if you schedule the current test code with an older scheduler you'll have issues because variables the current test code expects to be set (specifically UP1REL, in this case) won't be set by the older scheduler code. Please update your fedora_openqa checkout :)

I've re-scheduled the affected flavors with the current scheduler code, the tests should pass now.

karma

welp, this'll do it

OK, this looks like it has another unfulfilled dep too :/. It needs bind-dyndb-ldap >= 11.3-1 , and that update was only just pushed to testing a day ago. This can't go stable before that does; we should disable autopush (for both karma and time).

openQA tests failed (you can't see this ATM because of the data centre switch, but I can!) because the selinux-policy this depends on is not pushed stable yet. I'll re-run them when it is.

the openQA failure here is just because the update is so large it causes the test VM to run out of disk space. it's not a bug in the update really. I could hack it up and re-run it but it doesn't seem worth bothering because there's no reason this update would actually break FreeIPA.

karma

+1ing this as we need to push it stable because the Firefox update already went stable :(

karma

indeed openQA tests are passing now, looking good.

karma

the bug affects upgrades from F31. working on update within F32 doesn't mean the bug isn't a problem. Since I'm fairly clear on what's going on now and it does seem like a reason not to push this update stable as-is, gonna give it -1 now.

I did a scratch build with the proposed change and tested it. It passed.