This update seems wrong. Looking to the specfile changes, this is wrong.





this is f40.. so it have to pull jdk17.. sorry

This still pulls in jdk17


The reason is for sure, that stack wsa built by jdk21, but the used runtime jre was 17 (the numbers are sure - 17 is 61 and 21 is 65).

The simple workaround is to built com/fasterxml/ t0ools with backward compatible bytecode . That measn setting source and target to 17. But that can bite later.

The fix is to ensure, that the FreeIPA server (or only its tests?) get launched by system JDK.. The most likely casue is that freeipa (or some of its dependencies) requires literally java-17-openjdk, instead of just versionless java. The dfree ip a 9test?)runner then pick 17 instead of 21.

It was fixed in the commit after the build. I'mnot sure the wrong changelog with obviously wrong year should block the release or enforce rebuild (

But thax a lot for reporting!

Yes. The debuginfo packages would bstill usfull - but not together. Onl one xor second. Thanx a lot for input!

In meantime I found, that I can rewrote build-id without actually any consequences - the will still be debuggable. I wil repalce the original bild-id hash by modified hash of library|full path.

I have the fix ready. I wil now push this to stbale, to allow update at least of standalone jdk17 to the security level, and crate new update, with fixed buildid of

Hello! It had happened that builds identically in jdk17 and jd20 That meanns that debuginfo's hash will be same: /usr/lib/.build-id/ae/5beb882acdb12641968ba3d13f5a7e1b00089a -> ../../../../usr/lib/jvm/java-20-openjdk- /usr/lib/.build-id/ae/5beb882acdb12641968ba3d13f5a7e1b00089a -> ../../../../usr/lib/jvm/java-17-openjdk-

Thhus, as they are symlinks pointing to diffferent file, will lead to:

Error: Transaction test error: file /usr/lib/.build-id/ae/5beb882acdb12641968ba3d13f5a7e1b00089a from install of java-17-openjdk-headless-1: conflicts with file from package java-latest-openjdk-headless-1:

I have double checked that I'm,not building jdk17 in jdk20 body or vice-versa. Also the rest of jdk is correctl different.

Unluckily, the .build-id/ are in both .debuginfo subpkg and in normal package. Headless subbpkg in our case. so This is prohibiting the java to install - if you wish both 20 and 17 isntalled, which I would like to.

I have two solutions around: %define _build_id_links alldebug Will cause the .build-id/ to be only in debuginfo subpkg, and I do not know all possible consequenqnces - the obvious one, that you will notbe abel to keep both 17 and 20's debuginfo I conisder as acceptable. slightly patch by adding some volatile field, but that is no go for reproducible build....


Adam, thsoe traces are from openqa. Do you think thaey have something to do with this articualr pkg update?

Tahx a lot for that debuginfo issue. Will look into that.

ha rerun of gating passed!


works. but this update loosk a bit stalled

oh. this si f39. But it is also in f38 and f37.

Damn. Wish you found it while it was in testing. If you remove debuginfo packages, will it help? I guess yes, because this newest packages do nto have debuginfo.