Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Always, when any part of java version changed from single digit to two digits, issues with priority rise.
It was fixed by comment like eg:
#TODO when major version will jump over 9, change 1700 to 170
%define priority 1700%{priority_major_version}%{priority_minor_version}
Anyway, this is not enough. during *every* (single to two numbers) release this is violated, and I think the jdks priority length slipped out of synchronization again across various jdks.
fix is, to enhance %prep by:
prioritylength=`expr length %{priority}`
if [ $prioritylength -ne 9 ] ... with some nice outputs and exits
eg:
--- a/java-1.8.0-openjdk.spec
+++ b/java-1.8.0-openjdk.spec
@@ -118,7 +118,6 @@
%global aarch64_updatever 40
%global aarch64_buildver b12
%global aarch64_changesetid aarch64-1263
-# priority must be 6 digits in total
%global priority 18000%{updatever}
%global javaver 1.8.0
@@ -951,6 +950,11 @@ if [ %{include_debug_build} -eq 0 -a %{include_normal_build} -eq 0 ] ; then
echo "you have disabled both include_debug_build and include_debug_build. no go."
exit 13
fi
+prioritylength=`expr length %{priority}`
+if [ $prioritylength -ne 9 ] ; then
+ echo "priority must be 9 digits in total, violated"
+ exit 14
+fi
%setup -q -c -n %{uniquesuffix ""} -T -a 0
%ifarch %{aarch64}
pushd jdk8
Which will successfully halt built if priority slips.
This bug should be tracking bug for:
rhel5
java-1.7.0-openjdk
java-1.7.0-oracle
java-1.7.0-ibm
java-1.6.0-openjdk
java-1.6.0-oracle
java-1.6.0-ibm
java-1.5.0-ibm
rhel6
java-1.8.0-openjdk
java-1.8.0-oracle
java-1.8.0-ibm
java-1.7.0-openjdk
java-1.7.0-oracle
java-1.7.1-ibm
java-1.6.0-openjdk
java-1.6.0-oracle
java-1.6.0-ibm
java-1.5.0-ibm
rhel7
java-1.8.0-openjdk
java-1.8.0-oracle
java-1.8.0-ibm
java-1.7.0-openjdk
java-1.7.0-oracle
java-1.7.1-ibm
java-1.6.0-openjdk
java-1.6.0-oracle
java-1.6.0-ibm
And fedoras 21,22
java-1.8.0-openjdk
And fedoras 20
java-1.7.0-openjdk
Few more errors like this, and we will run out of integer space...
The check test is now pushed to f21-f23 openjdk8, with test on *7*
As oracles', openjdks' and ibms' jdks each have priority based on different and differently growing numbers (SR+FP for ibm, icedtea foe openjdk<8, u for openjdk>7, u+b for Oracle) The idea of gruping them (so they will be moreover competitive only among themselves) :
ibm - length of 7
oracle - lenght of 8
openjdk - length of 9
Thoughts?
Current priorities table:
f20 f21 f22 rawhide rhel5 rhel6.5 rhel6.6 rhel7.0 rhel7.1
(openjdk 6)
na na na na 5 5 5 5 5
(openjdk 7)
6 na na na 6 6 6 6 6
(opendjk 8)
7 7 7 7 na 6 6 6 6
(oracle 6)
na na na na 6 6 6 6 6
(oracle 7)
na na na na 6 6 6 6 6
(oracle 8)
na na na na na N 6 N 6
(ibm 5)
na na na na 6 6 6 na na
(ibm 6)
na na na na 6 6 6 6 N
(ibm 7)
na na na na 6 6 6 6 na
(ibm 7.1)
na na na na N N 6 6 6
Legend: na - package is not live, N - no repositories, number = the current number of digits for priority.
Plan - synchronize priorities in all ibm javas to 6 digits, oracle javas to 7 digits, openjdk to 8 digits - alreday done by jvanek on fedora 20 21, 22, 23 for openjdk 8.
hi Jana,
I have pushed the check to jdk7:
f20 f21 f22 rawhide rhel5 rhel6.5 rhel6.6 rhel7.0 rhel7.1
(openjdk 7)
6 na na na 6 6 6 *7* *7*
And will do the same for 8
(opendjk 8)
7 7 7 7 na 6 6 *7* *7*
Please, add the checks to to proprietary jdks Well, and keep them all on 6...
Packages with proprietary Oracle jdk have all priority 6 digits long:
-jdk 8 on rhel 6.6,6.7,7.1,7.2
-jdk 7 on rhel 5.11,6.6,6.7,7.1,7.2
-jdk 6 on rhel 5.11,6.6,6.7,7.1,7.2
(In reply to jfabriko from comment #7)
> Packages with proprietary Oracle jdk have all priority 6 digits long:
> -jdk 8 on rhel 6.6,6.7,7.1,7.2
> -jdk 7 on rhel 5.11,6.6,6.7,7.1,7.2
> -jdk 6 on rhel 5.11,6.6,6.7,7.1,7.2
+the priority length check included
(In reply to jiri vanek from comment #6)
> also
>
>
> I have pushed the check to jdk7:
> rhel6.7 rhel7.2
> 6 *7*
>
> And will do the same for 8
> 6 *7*
And will do the same for 8
6.6 6.7 7.1 7.2
7 *7*
Always, when any part of java version changed from single digit to two digits, issues with priority rise. It was fixed by comment like eg: #TODO when major version will jump over 9, change 1700 to 170 %define priority 1700%{priority_major_version}%{priority_minor_version} Anyway, this is not enough. during *every* (single to two numbers) release this is violated, and I think the jdks priority length slipped out of synchronization again across various jdks. fix is, to enhance %prep by: prioritylength=`expr length %{priority}` if [ $prioritylength -ne 9 ] ... with some nice outputs and exits eg: --- a/java-1.8.0-openjdk.spec +++ b/java-1.8.0-openjdk.spec @@ -118,7 +118,6 @@ %global aarch64_updatever 40 %global aarch64_buildver b12 %global aarch64_changesetid aarch64-1263 -# priority must be 6 digits in total %global priority 18000%{updatever} %global javaver 1.8.0 @@ -951,6 +950,11 @@ if [ %{include_debug_build} -eq 0 -a %{include_normal_build} -eq 0 ] ; then echo "you have disabled both include_debug_build and include_debug_build. no go." exit 13 fi +prioritylength=`expr length %{priority}` +if [ $prioritylength -ne 9 ] ; then + echo "priority must be 9 digits in total, violated" + exit 14 +fi %setup -q -c -n %{uniquesuffix ""} -T -a 0 %ifarch %{aarch64} pushd jdk8 Which will successfully halt built if priority slips. This bug should be tracking bug for: rhel5 java-1.7.0-openjdk java-1.7.0-oracle java-1.7.0-ibm java-1.6.0-openjdk java-1.6.0-oracle java-1.6.0-ibm java-1.5.0-ibm rhel6 java-1.8.0-openjdk java-1.8.0-oracle java-1.8.0-ibm java-1.7.0-openjdk java-1.7.0-oracle java-1.7.1-ibm java-1.6.0-openjdk java-1.6.0-oracle java-1.6.0-ibm java-1.5.0-ibm rhel7 java-1.8.0-openjdk java-1.8.0-oracle java-1.8.0-ibm java-1.7.0-openjdk java-1.7.0-oracle java-1.7.1-ibm java-1.6.0-openjdk java-1.6.0-oracle java-1.6.0-ibm And fedoras 21,22 java-1.8.0-openjdk And fedoras 20 java-1.7.0-openjdk Few more errors like this, and we will run out of integer space...