update.rmdepcheck:

Dependencies of other packages that would be BROKEN by the tested packages:
package: asterisk-snmp-18.12.1-1.fc44.17.x86_64 from https://kojipkgs.fedoraproject.org/repos/f44-build/latest/x86_64
  libnetsnmp.so.40()(64bit)
  libnetsnmpagent.so.40()(64bit)
  libnetsnmpmibs.so.40()(64bit)
package: eth-tools-fastfabric-1:12.1.0.0-151.fc43.x86_64 from https://kojipkgs.fedoraproject.org/repos/f44-build/latest/x86_64
  libnetsnmp.so.40()(64bit)
package: lldpd-1.0.18-5.fc44.x86_64 from https://kojipkgs.fedoraproject.org/repos/f44-build/latest/x86_64
  libnetsnmp.so.40()(64bit)
  libnetsnmpagent.so.40()(64bit)
  libnetsnmpmibs.so.40()(64bit)
package: opensips-snmpstats-3.6.3-2.fc44.x86_64 from https://kojipkgs.fedoraproject.org/repos/f44-build/latest/x86_64
  libnetsnmp.so.40()(64bit)
  libnetsnmpagent.so.40()(64bit)

These are due to build failures that are known and were announced to the devel list and to the packages’s maintainers. The asterisk failure is because TeX Live is broken, and the others are incompatibilities with this net-snmp version. All four are leaf packages, so the consequences should not be too great.

Something is wrong with fedora-ci.koji-build./plans/tier1-public.functional in frr-10.5.0-6.fc44: it is “ABSENT,” and the same thing happened in the previous update FEDORA-2026-1f2e214f0f, so it’s not due to the net-snmp update. For that reason, I think that particular test could be waived.

note rmdepcheck is informational, not blocking. I'm not sure what's going on with frr - it seems to be set up the same way as hplip, where the tests ran. But I agree it could be waived.

Oh, hah, I see the problem: the tests repo got re-arranged so the location the plan points to is no longer there. I'll send a PR to fix it.

This is still waiting on update.base_selinux for 64-bit server, but when I click on it, https://openqa.fedoraproject.org/tests/4187710 says it passed two hours ago. Not sure what to make of that.

Fixed, but it's a bit concerning that happened...it implies there was a missing message, or message handling went wrong somehow (but I don't have any error emails)...I'll look into it if I get a minute.

I sent a PR for frr, but then realized it was a dupe, there's already three PRs for the branches. I guess I'll merge those instead...

I'm doing a new build of frr with the fixed (hopefully) test definitions, on this side tag. I'll re-gen the update when it's done. Then the tests should all re-run and we should get the frr result this time.

@adamwill Thank you. Your investigation is really helpful, especially considering I will be turning around and rebuilding frr again for abseil-cpp as soon as this update reaches stable.

@mruprich, now that we’re getting failed frr tests rather than missing test results, do you have any insights? I know that frr tests have been rather brittle in the past, and I don’t see anything that looks obviously related to this update, but I can’t really tell what’s going wrong.

Huh, weird that the gating status got to 'passed' there...oh, well. It's probably fine.

Huh, weird that the gating status got to 'passed' there...oh, well. It's probably fine.

Yeah, I only waived the frr test.

It looks like update.install_default_update_live and update.realmd_join_sssd_ad ended up failing this time around. I still find the output of these tests inscrutable, though.

Yeah, I only waived the frr test.

Yeah, that's why it's odd. Must have been a very precise timing issue of some kind.

It looks like update.install_default_update_live and update.realmd_join_sssd_ad ended up failing this time around. I still find the output of these tests inscrutable, though.

The deal is that we (Quality team) look at failures and translate them for you, unless you want to be really keen. ;) In this case install_default_update_live was just a test flake. I think realmd_join_sssd_ad was also a flake - I've restarted it - though it failed the same odd way twice in a row, which is concerning. What happened is the test did ctrl-alt-f3 to get a fresh terminal, and it got a blank screen instead.

Ugh, there's definitely some kind of weird intermittent issue with tty3 not spawning in AD/FreeIPA enrolment tests, but I don't think it has anything to do with this update. Sigh.