The java-latest-openjdk-portable SRPMs in the EPEL 9 and 8 repos have not been updated since 12/2023 and do not match the currently published java-latest-openjdk SRPMs. This makes it impossible to rebuild java-latest-openjdk from SRPMs (since the two-stage build requires both the corresponding "-portable" and non "-portable" SRPMs). https://dl.fedoraproject.org/pub/epel/9/Everything/source/tree/Packages/j/ java-latest-openjdk-22.0.1.0.8-1.rolling.el9.src.rpm java-latest-openjdk-portable-21.0.1.0.12-2.rolling.el9.src.rpm https://dl.fedoraproject.org/pub/epel/8/Everything/source/tree/Packages/j/ java-latest-openjdk-22.0.1.0.8-1.rolling.el8.src.rpm java-latest-openjdk-portable-21.0.1.0.12-2.rolling.el8.src.rpm Please update the java-latest-openjdk-portable SRPMs in the repo and fix whatever issue was preventing them from being automatically updated. Thanks!
I'll look into it, thanks
hi, the https://fedoraproject.org/wiki/Changes/BuildJdkOncePackEverywhere#theoretical_tagging_solution implemented as https://fedoraproject.org/wiki/Changes/BuildJdkOncePackEverywhere#Packagers_and_comaintainers_tutorial is guilty. For fedora, I can keep the portable srpm at least updated in rawhide (but still it will suffer the issue you described). As epel do not have naything as rawhide, I currently do not know how to persists that build. As bodhi is currently unable (and will remain unable for long time) to do one NVR update to several systems, I do not know how to do this correctly. In lates updates, I had added: $ cat /usr/lib/jvm/java-22-openjdk-22.0.1.0.8-1.rolling.fc39.x86_64/repack.info Those RPMs are just repacking portable tarballs extracted from portable RPMs Usually this exact portable RPM can not be obtained via dnf install, but you can download it. The exact info is at bottom. .... Which repacked java-latest-openjdk-portable-22.0.1.0.8-1.rolling.fc38 You can download the repacked portables from: https://koji.fedoraproject.org/koji/search?match=glob&type=build&terms=java-latest-openjdk-portable-22.0.1.0.8-1.rolling.fc38 Wed May 1 17:31:49 UTC 2024 The link should give you all you need to do the rebuild . I know this is clumsy. for rhel we solved this by adding portable srpm as part of rpms release. I still do not know what is worse. Do you have any idea how to make this better? I'm able to do a portable rebuild with all above, if you are not, can you share more of your usecase? MAybe there sould be possible some small enhancement to make it more smooth.
My use case: There is a bug in Java's HttpURLConnection that keeps biting me in production (repeatedly in various applications over the course of the last decade or so). Long ago I reported it upstream, but never got a response. A few years later, I developed a fix and submitted it upstream: https://github.com/PaulSD/jdk/commit/280342ca257823adb8a5c550f129c1a81929afa2 However, they didn't respond to my fix for a few years, then they ignored my patch and implemented a different and incomplete "fix" for the bug which only solves part of the problem, and their bugzilla won't let me comment on my own bug report (to explain why their "fix" is incomplete and suggest further fixes), so my only option is to open another upstream bug report and wait a few more years for them to look at it again... (Any chance you have upstream OpenJDK contacts who can give me a better way to report and comment on bugs like this in Java?) Regardless ... Until it gets fixed (if it ever gets fixed) upstream, I have an automated process that rebuilds all of the Java RPMs that I use, to include my fix. It does this by downloading and extracting the relevant SRPMs (using `dnf download`), injecting my patch file into the SOURCES directory and SPEC file, running rpmbuild, then pushing the built RPMs into my RedHat Satellite server for distribution to my systems. Note that my patch requires rebuilding both the portable and non-portable RPMs (since the patch is compiled into the portable RPMs then re-packaged into the non-portable RPMs). I'm currently doing this for Java 1.8, 11, 17, 21 (from RHEL), and -latest (from EPEL) on both RHEL 8 and RHEL 9 hosts (to support a variety of apps / use cases in my environment). Due to the number and frequency of builds that are needed, this process is designed to run fully unattended - Any time a new SRPM is released, it automatically detects it and builds a new RPM, and a human is only involved if the process fails (eg. due to a merge conflict when applying my patch). Thoughts: I don't think I know enough about koji/bodhi (and their workflows and tagging behavior) to fully understand the underlying issues and work-arounds here. However, if I am following you correctly, it sounds like the problem is that bodhi can't publish the portable SRPM/RPMs to both the el8 and el9 Yum repos, so you are using it in a way that causes it not to publish the -portable SRPM/RPMs anywhere (other than in koji itself)? Would it be possible to create a special one-off el-openjdk repo (just to hold the -portable SPRMs) that does get published alongside the el8/el9 repos? That way I could simply add another /etc/yum.repos.d/el-openjdk.repo file for the new one-off repo in order to make `dnf download` work again? Alternatively, it sounds like I might be able to handle this new situation by replacing my `dnf download java-latest-openjdk-portable` call with something like `koji latest-build --quiet el8-openjdk java-latest-openjdk-portable`, followed some code to parse the output, followed by `wget https://kojipkgs.fedoraproject.org/packages/<name>/<version>/<release>/src/<SRPM>`? That is clumsy, but it might be workable... Thanks!