I'm not 100% sure what's going on with the failure here, honestly, but it seems reproducible - it's failed three times the same way. Weirdly, it didn't fail the same way on the staging openQA instance.
It's failing the openQA FreeIPA test that enrols into the domain via Cockpit. Other FreeIPA enrolment tests pass. It fails when trying to login as a domain user - the login fails with "System error". Server journal doesn't show anything much. Client journal has this:
Erro: Erro no teste de transação:
o arquivo /usr/lib/.build-id/ae/5beb882acdb12641968ba3d13f5a7e1b00089a conflita entre a tentativa de instalação de java-17-openjdk-headless-1:17.0.7.0.7-1.fc37.x86_64 e java-latest-openjdk-headless-1:20.0.1.0.9-4.rolling.fc37.x86_64
Bodhi is disabling automatic push to stable due to negative karma. The maintainer may push manually if they determine that the issue is not severe.
Running transaction check
Transaction check succeeded.
Running transaction test
The downloaded packages were saved in cache until the next successful transaction.
You can remove cached packages by executing 'dnf clean packages'.
Error: Transaction test error:
file /usr/lib/.build-id/ae/5beb882acdb12641968ba3d13f5a7e1b00089a conflicts between attempted installs of java-latest-openjdk-headless-1:20.0.1.0.9-4.rolling.fc37.x86_64 and java-17-openjdk-headless-1:17.0.7.0.7-1.fc37.x86_64
and these are the packages that would be updated:
java-17-openjdk x86_64 1:17.0.7.0.7-1.fc37 updates-testing 426 k
java-17-openjdk-devel x86_64 1:17.0.7.0.7-1.fc37 updates-testing 4.7 M
java-17-openjdk-headless x86_64 1:17.0.7.0.7-1.fc37 updates-testing 42 M
java-latest-openjdk-headless x86_64 1:20.0.1.0.9-4.rolling.fc37 updates-testing 44 M
This update's test gating status has been changed to 'passed'.
same error while installing via dnf (it also occurs with Fedora 38)
Error: Transaction test error:
file /usr/lib/.build-id/ae/5beb882acdb12641968ba3d13f5a7e1b00089a conflicts between attempted installs of java-17-openjdk-headless-1:17.0.7.0.7-1.fc37.x86_64 and java-latest-openjdk-headless-1:20.0.1.0.9-4.rolling.fc37.x86_64
Hello!
It had happened that libjsvml.so 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-20.0.1.0.9-4.rolling.fc37.x86_64/lib/libjsvml.so
/usr/lib/.build-id/ae/5beb882acdb12641968ba3d13f5a7e1b00089a -> ../../../../usr/lib/jvm/java-17-openjdk-17.0.7.0.7-1.fc37.x86_64/lib/libjsvml.so
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:17.0.7.0.7-1.fc37.x86_64 conflicts with file from package java-latest-openjdk-headless-1:20.0.1.0.9-4.rolling.fc37.x86_64
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 libjsvml.so by adding some volatile field, but that is no go for reproducible build....
I think option #1 is the most reasonable one and perhaps the least troublesome for you. Should the need occur, would a user be able to use the one or the other set of debug packages in a relatively straightforward manner?
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 libjsvml.so 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 libjvlm.so
This update has been submitted for testing by jvanek.
This update's test gating status has been changed to 'waiting'.
This update's test gating status has been changed to 'failed'.
I'm not 100% sure what's going on with the failure here, honestly, but it seems reproducible - it's failed three times the same way. Weirdly, it didn't fail the same way on the staging openQA instance.
It's failing the openQA FreeIPA test that enrols into the domain via Cockpit. Other FreeIPA enrolment tests pass. It fails when trying to login as a domain user - the login fails with "System error". Server journal doesn't show anything much. Client journal has this:
and
var/log/sssd/selinux_child.loghas this:I can try and look into it more on Monday...
This update has been pushed to testing.
Here I have this error, and FAIL TO INSTALL:
Bodhi is disabling automatic push to stable due to negative karma. The maintainer may push manually if they determine that the issue is not severe.
no regressions noted
Tahx a lot for that debuginfo issue. Will look into that.
Adam, thsoe traces are from openqa. Do you think thaey have something to do with this articualr pkg update?
Same error as Geraldo above:
and these are the packages that would be updated:
This update's test gating status has been changed to 'passed'.
same error while installing via dnf (it also occurs with Fedora 38)
Hello! It had happened that libjsvml.so 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-20.0.1.0.9-4.rolling.fc37.x86_64/lib/libjsvml.so /usr/lib/.build-id/ae/5beb882acdb12641968ba3d13f5a7e1b00089a -> ../../../../usr/lib/jvm/java-17-openjdk-17.0.7.0.7-1.fc37.x86_64/lib/libjsvml.so
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:17.0.7.0.7-1.fc37.x86_64 conflicts with file from package java-latest-openjdk-headless-1:20.0.1.0.9-4.rolling.fc37.x86_64
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 libjsvml.so by adding some volatile field, but that is no go for reproducible build....
Thougts?
I think option #1 is the most reasonable one and perhaps the least troublesome for you. Should the need occur, would a user be able to use the one or the other set of debug packages in a relatively straightforward manner?
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 libjsvml.so 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 libjvlm.so
jvanek edited this update.
This update's test gating status has been changed to 'waiting'.
jvanek edited this update.
This update's test gating status has been changed to 'passed'.
same issue for f38: https://bugzilla.redhat.com/show_bug.cgi?id=2192073
This update has been obsoleted by java-17-openjdk-17.0.7.0.7-5.fc37.