@ipedrosa sorry, I didn't see the ping (once https://github.com/fedora-infra/bodhi/pull/6066 is in production I will be a lot more likely to notice Bodhi pings...), but judging by the above, it was likely a blip that I restarted on one of my regular trawls through failed tests, so all is good. thanks!

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.

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...

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.

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.

Well, please sort it out with @mizdebsk. You can waive the failure, but you'd have to do that every time you build the package.

This fails gating because it has a -javadoc package. Apparently, "all -javadoc subpackages are expected to be dropped". On further investigation, it seems this test is intended to be applied to "Maven dependency set (AKA the "MBI" set)." - https://github.com/fedora-java/javapackages-validator/issues/209 . It does seem like @kni (re-)introduced the javadoc subpackage in this build: https://src.fedoraproject.org/rpms/jakarta-mail/c/9471f6493905c5b13c77b8946cc45ea02a5aeeb9?branch=rawhide .

@mizdebsk , I guess this all means you want to know about this? So, I'm pinging you.

Bug: https://bugzilla.redhat.com/show_bug.cgi?id=2420679

Still the vmmouse kernel panic in openQA. Hopefully we'll get this resolved soon!

Awesome, thanks for fixing this!

Interestingly, firefox-147.0-2.fc44 from the mass rebuild is also affected. So it's definitely something build chain-y, not a change in 147.0.1. I'll file a bug tomorrow.

Huh. I got some logs from the original server now, but don't immediately see what's causing the 500. You can download them at https://openqa.stg.fedoraproject.org/tests/5791971/file/role_deploy_domain_controller_check-var_log.tar.gz .

Wait, now I look at that, the 500 is coming from the original server, the one that's being replicated. So we need the logs from that.

wait, I'm being silly, the traceback it's catching is likely just the one in ipareplica-install.log. So the key question is why are we getting this 500 response?

DEBUG: https://ipa002.test.openqa.fedoraproject.org:443 "GET /ca/rest/securityDomain/domainInfo HTTP/1.1" 500 None

Huh, with the latest edit to the update, I no longer see the ipa-topology-plugin ERR messages, but we still crash in the same place:

Jan 19 15:08:39 ipa003.test.openqa.fedoraproject.org ns-slapd[8958]: [19/Jan/2026:15:08:39.726455080 -0500] - INFO - NSMMReplicationPlugin - replica_subentry_create - add dn: cn=repl keep alive 5,o=ipaca
Jan 19 15:08:39 ipa003.test.openqa.fedoraproject.org ns-slapd[8958]: objectclass: top
Jan 19 15:08:39 ipa003.test.openqa.fedoraproject.org ns-slapd[8958]: objectclass: ldapsubentry
Jan 19 15:08:39 ipa003.test.openqa.fedoraproject.org ns-slapd[8958]: objectclass: extensibleObject
Jan 19 15:08:39 ipa003.test.openqa.fedoraproject.org ns-slapd[8958]: keepalivetimestamp: 0
Jan 19 15:08:39 ipa003.test.openqa.fedoraproject.org ns-slapd[8958]: cn: repl keep alive 5
Jan 19 15:08:39 ipa003.test.openqa.fedoraproject.org ns-slapd[8958]: GSSAPI client step 1
Jan 19 15:08:39 ipa003.test.openqa.fedoraproject.org ns-slapd[8958]: GSSAPI client step 1
Jan 19 15:08:39 ipa003.test.openqa.fedoraproject.org ns-slapd[8958]: GSSAPI client step 1
Jan 19 15:08:39 ipa003.test.openqa.fedoraproject.org ns-slapd[8958]: GSSAPI client step 2
Jan 19 15:08:40 ipa003.test.openqa.fedoraproject.org /usr/sbin/ipa-replica-install[5808]: [IPA.API] host/ipa003.test.openqa.fedoraproject.org@TEST.OPENQA.FEDORAPROJECT.ORG: idrange_show: SUCCESS [ldap2_281472721529616] {"cn": "TEST.OPENQA.FEDORAPROJECT.ORG_id_range", "rights": false, "all": false, "raw": false, "version": "2.257"}
Jan 19 15:08:42 ipa003.test.openqa.fedoraproject.org python3.14[10107]: detected unhandled Python exception in '/usr/lib/python3.14/site-packages/pki/server/pkispawn.py'

I wonder if I can get abrt to ignore the package being unsigned and give us the Python trace or something...or maybe I can make openQA get a signed package in this case...

I can reproduce this manually, as well. Just install current Rawhide Workstation in a VM, update Firefox from this update, and try to run it; it crashes instantly. I still can't get a useful traceback, though :/