Description of problem: The most recent build of the java-latest-openjdk RPM for EPEL7 is for version 17.0.1 which does not contain the security fixes released in Jan 2022. Version-Release number of selected component (if applicable): 17.0.2 Actual results: Most recent build on March 16 was for version 17.0.1 https://koji.fedoraproject.org/koji/buildinfo?buildID=1934602 Expected results: Hoping to get the most recent Java 17 (17.0.2) with all security fixes. Additional info: https://bodhi.fedoraproject.org/updates/FEDORA-2022-7d8b535724 https://jdk.java.net/17/ https://src.fedoraproject.org/rpms/java-latest-openjdk
Hi, I have been swamped this quarter, so I agree the release is quite late, I am sorry for that. Unfortunately with epel7 being a very old system, the updates come last there and usually are not going smooth. I just finsihed epel8 updates last week, and now I am working on epel7. However the backports are not really trivial and since I do this in my spare time, it can take more time than usual. Sorry for any inconvenience,
I've created a PR for the security update: https://src.fedoraproject.org/rpms/java-latest-openjdk/pull-request/106 Hope that helps. The cosmetic/build changes can wait until after the security update is out (and we have another coming in under < 1 month) It also restores the FIPS patches which seem to be missing. I'm not sure why. There's nothing in the ChangeLog about their removal as far as I can see. It would be good to prioritise EPEL 7 over EPEL 8 as RHEL 8 users have the option of using java-17-openjdk, while RHEL 7 users only have up to java-11-openjdk. I guess this will change when EPEL 8 gets java-latest-openjdk bumped to OpenJDK 18, but at present, the RHEL java-17-openjdk should be preferred to java-latest-openjdk on RHEL 8.
There appears to be something wrong with the RPM build for java-latest-openjdk-headless-17.0.2.0.8-2.rolling.el7.x86_64.rpm. I used the following link to download and test the build https://kojipkgs.fedoraproject.org//packages/java-latest-openjdk/17.0.2.0.8/2.rolling.el7/x86_64/java-latest-openjdk-headless-17.0.2.0.8-2.rolling.el7.x86_64.rpm An rpm -qlp on the rpm file lists all the files as expected, however on install a large portion of the expected contents is missing - namely the /usr/lib/jvm/java-17-openjdk-17.0.2.0.8-2.rolling.el7.x86_64/ directory. rpm2cpio java-latest-openjdk-headless-17.0.2.0.8-2.rolling.el7.x86_64.rpm | cpio -pvd shows the following # rpm2cpio java-latest-openjdk-headless-17.0.2.0.8-2.rolling.el7.x86_64.rpm | cpio -ivd ./etc/.java ./etc/.java/.systemPrefs ./usr/lib/jvm/jre-17-openjdk-17.0.2.0.8-2.rolling.el7.x86_64 ./usr/share/doc/java-17-openjdk-17.0.2.0.8-2.rolling.el7.x86_64/NEWS ./usr/share/man/man1/alt-java-java-17-openjdk-17.0.2.0.8-2.rolling.el7.x86_64.1.gz ./usr/share/man/man1/java-java-17-openjdk-17.0.2.0.8-2.rolling.el7.x86_64.1.gz ./usr/share/man/man1/keytool-java-17-openjdk-17.0.2.0.8-2.rolling.el7.x86_64.1.gz ./usr/share/man/man1/rmiregistry-java-17-openjdk-17.0.2.0.8-2.rolling.el7.x86_64.1.gz 355 blocks The rpm is also only 282K. -rw-r--r--. 1 root root 288404 Mar 29 00:36 java-latest-openjdk-headless-17.0.2.0.8-2.rolling.el7.x86_64.rpm
Hello! Yes we noticed it, but I can not found a clue. If it would be just one build, I woudl say koji went wil, but they are ntow two in row. Long story short, the headless package is mepty and do not have content - jsut dirs and broken symlink. But if you look to the package details (eg https://koji.fedoraproject.org/koji/rpminfo?rpmID=29818745, info of headless) - it claims it is full Smilarly the logs and debuginfo seesm to be correct and pretending the headless is full as it shold be. Even the size of the headless pkg is neraly zero. The devel package (with javac and friends) are already ok. Even "java-latest-openjdk" is ok - but that is jsut three libraries and icons. First broken is java-latest-openjdk-17.0.1.0.12-3.rolling.el7. Following java-latest-openjdk-17.0.2.0.8-1.rolling.el7 shares the same issue. Both architectures, in release variants share the issue. The debug/fastdebug are again ok... The build log also looks good - the headless package is processed, and its files listed (twice but still)
Thanks Jiri. I appreciate the feedback. I diffed the build.log files for both the 17.0.1.0.12-1 and 17.0.1.0.12-3 builds of java-latest-openjdk https://kojipkgs.fedoraproject.org//packages/java-latest-openjdk/17.0.1.0.12/1.rolling.el7/data/logs/x86_64/build.log https://kojipkgs.fedoraproject.org//packages/java-latest-openjdk/17.0.1.0.12/3.rolling.el7/data/logs/x86_64/build.log The first thing I noticed was a few errors related to macro expansion at the top of the -3 file that are not in the -1 file. From the 17.0.1.0.12/3.rolling.el7/data/logs/x86_64/build.log: === Mock Version: 2.16 Mock Version: 2.16 Mock Version: 2.16 ENTER ['do_with_status'](['bash', '--login', '-c', '/usr/bin/rpmbuild -bs --target x86_64 --nodeps /builddir/build/SPECS/java-latest-openjdk.spec'], chrootPath='/var/lib/mock/epel7-build-33850788-4530148/root'env={'TERM': 'vt100', 'SHELL': '/bin/bash', 'HOME': '/builddir', 'HOSTNAME': 'mock', 'PATH': '/usr/bin:/bin:/usr/sbin:/sbin', 'PROMPT_COMMAND': 'printf "\\033]0;<mock-chroot>\\007"', 'PS1': '<mock-chroot> \\s-\\v\\$ ', 'LANG': 'C.UTF-8'}shell=Falselogger=<mockbuild.trace_decorator.getLog object at 0x7fbdfe8161a0>timeout=201600uid=1000gid=425user='mockbuild'nspawn_args=[]unshare_net=TrueprintOutput=False) Executing command: ['bash', '--login', '-c', '/usr/bin/rpmbuild -bs --target x86_64 --nodeps /builddir/build/SPECS/java-latest-openjdk.spec'] with env {'TERM': 'vt100', 'SHELL': '/bin/bash', 'HOME': '/builddir', 'HOSTNAME': 'mock', 'PATH': '/usr/bin:/bin:/usr/sbin:/sbin', 'PROMPT_COMMAND': 'printf "\\033]0;<mock-chroot>\\007"', 'PS1': '<mock-chroot> \\s-\\v\\$ ', 'LANG': 'C.UTF-8'} and shell False error: Too many levels of recursion in macro expansion. It is likely caused by recursive macro declaration. error: Too many levels of recursion in macro expansion. It is likely caused by recursive macro declaration. error: Too many levels of recursion in macro expansion. It is likely caused by recursive macro declaration. Building target platforms: x86_64 Building for target x86_64 Wrote: /builddir/build/SRPMS/java-latest-openjdk-17.0.1.0.12-3.rolling.el7.src.rpm Child return code was: 0 ENTER ['do_with_status'](['bash', '--login', '-c', '/usr/bin/rpmbuild -bb --target x86_64 --nodeps /builddir/build/SPECS/java-latest-openjdk.spec'], chrootPath='/var/lib/mock/epel7-build-33850788-4530148/root'env={'TERM': 'vt100', 'SHELL': '/bin/bash', 'HOME': '/builddir', 'HOSTNAME': 'mock', 'PATH': '/usr/bin:/bin:/usr/sbin:/sbin', 'PROMPT_COMMAND': 'printf "\\033]0;<mock-chroot>\\007"', 'PS1': '<mock-chroot> \\s-\\v\\$ ', 'LANG': 'C.UTF-8'}shell=Falselogger=<mockbuild.trace_decorator.getLog object at 0x7fbdfe8161a0>timeout=201600uid=1000gid=425user='mockbuild'nspawn_args=[]unshare_net=TrueprintOutput=False) Executing command: ['bash', '--login', '-c', '/usr/bin/rpmbuild -bb --target x86_64 --nodeps /builddir/build/SPECS/java-latest-openjdk.spec'] with env {'TERM': 'vt100', 'SHELL': '/bin/bash', 'HOME': '/builddir', 'HOSTNAME': 'mock', 'PATH': '/usr/bin:/bin:/usr/sbin:/sbin', 'PROMPT_COMMAND': 'printf "\\033]0;<mock-chroot>\\007"', 'PS1': '<mock-chroot> \\s-\\v\\$ ', 'LANG': 'C.UTF-8'} and shell False error: Too many levels of recursion in macro expansion. It is likely caused by recursive macro declaration. error: Too many levels of recursion in macro expansion. It is likely caused by recursive macro declaration. error: Too many levels of recursion in macro expansion. It is likely caused by recursive macro declaration. Building target platforms: x86_64 Building for target x86_64 Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.i4w4Sh + umask 022 + cd /builddir/build/BUILD include_normal_build is 1 ... ... Also noticed that the 17.0.1.0.12-3 headless build file list here https://koji.fedoraproject.org/koji/rpminfo?rpmID=29818721 contains a number of files which would normally belong to the jdk such as bin/javac, bin/javadoc and bin/jar which the 17.0.1.0.12-1 headless does not have: https://koji.fedoraproject.org/koji/rpminfo?rpmID=28159032
Hi! Thanx a lot for looking onto other places, and for adding a motivation to this to get it fixed. I had saw the `error: Too many level..` but I skipped it as I'm moreover used to them. However looking to the impact with javac you found, it may be the root cause, Actually long time ago, rpmbuild had increased hard-coded recursion detection form 16 to 64 or similarly, jsut because of the java*.spec files. It may be that update o rpmbuild lost this patch.. checked.. not activity in rpm in rhel7 or centos7 in last year... Looking to the twopatches between 12.3 and 12.1 again: https://src.fedoraproject.org/rpms/java-latest-openjdk/c/57ee960afb92c39a227a463f3c52b1813a080ef8?branch=epel7 + https://src.fedoraproject.org/rpms/java-latest-openjdk/c/9748606d6fb1e8a910539262d9e444e431d04b04?branch=epel7 from those two the second had introduced `error: Too many..` And there are indeed macros, which were removed,but are still in spec. Will try to fix it.
Ok. Found it: + %ghost %{_jvmdir}/%{sdkdir -- %{?1}}/conf.rpmmoved + %ghost %{_jvmdir}/%{sdkdir -- %{?1}}/lib/security.rpmmoved is nogo in epel7. It must be +%ghost %{_jvmdir}/%{sdkdir %%1}/conf.rpmmoved +%ghost %{_jvmdir}/%{sdkdir %%1}/lib/security.rpmmoved mymockbuild no longer compains about the `to many...` Will commit and try main build, seeing if it goes correct in koji
And they were headless... I explain that fastdebug/slowdebug headless built correctly, as the -- %{?1}} in epel7 is fragile only when nilis going in. Here we go: https://koji.fedoraproject.org/koji/taskinfo?taskID=85197852 larscson, really thanx a lot for your findings and for the encouragement which was really needed to kick me on.
Jiri - thanks! The builds are looking much better now. The headless rpm is back to around 40MB. I grabbed the headless RPM from the build and initial signs are good. dnf upgraded the existing 17.0.1 version to the new version and the java processes started up as expected. [root@test7 ~]# java -version openjdk version "17.0.2" 2022-01-18 OpenJDK Runtime Environment 21.9 (build 17.0.2+8) OpenJDK 64-Bit Server VM 21.9 (build 17.0.2+8, mixed mode, sharing) So far so good!
yy. Has jsut checked it. Indded it is fixed. Am firing up update.
FEDORA-EPEL-2022-f985878abb has been submitted as an update to Fedora EPEL 7. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-f985878abb
FEDORA-EPEL-2022-f985878abb has been pushed to the Fedora EPEL 7 testing repository. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-f985878abb See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-EPEL-2022-f985878abb has been pushed to the Fedora EPEL 7 stable repository. If problem still persists, please make note of it in this bug report.