From Fedora Project Wiki
m (Jvanek moved page Changes/Drop32bJDKs to Changes/Drop i686 JDKs: 32b was misleading. i686 is better)
 
(43 intermediate revisions by 2 users not shown)
Line 19: Line 19:
<!-- The actual name of your proposed change page should look something like: Changes/Your_Change_Proposal_Name.  This keeps all change proposals in the same namespace -->
<!-- The actual name of your proposed change page should look something like: Changes/Your_Change_Proposal_Name.  This keeps all change proposals in the same namespace -->


= Drop 32b builds of jdk8,11,17 and latest (18) rpms  <!-- The name of your change proposal --> =
= Drop i686 builds of jdk8,11,17 and latest (18) rpms from f37 onwards <!-- The name of your change proposal --> =


== Summary ==
== Summary ==
Line 40: Line 40:
* Product: java and java stack
* Product: java and java stack
* Responsible WG: java-sig (java and java-maint)(which no longer exists)
* Responsible WG: java-sig (java and java-maint)(which no longer exists)
* rcm ticket: todo
 


== Current status ==
== Current status ==
<!--[[Category:ChangeReadyForFesco]]-->
[[Category:ChangeAcceptedF37]]
[[Category:ChangePageIncomplete]]
<!--[[Category:ChangePageIncomplete]]-->
[[Category:SystemWideChange]]  
[[Category:SystemWideChange]]  


Line 56: Line 56:
CLOSED as NEXTRELEASE -> change is completed and verified and will be delivered in next release under development
CLOSED as NEXTRELEASE -> change is completed and verified and will be delivered in next release under development
-->
-->
* FESCo issue: todo
* [https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/VRZRCT23OT64JWZNVLHOAU2YNIXU2BBO/ devel thread]
* Tracker bug: todo
* FESCo issue: [https://pagure.io/fesco/issue/2772 #2772]
* Release notes todo
* Tracker bug: [https://bugzilla.redhat.com/show_bug.cgi?id=2083750 #2083750]
* Release notes [https://pagure.io/fedora-docs/release-notes/issue/835 #835]


=== Expected schedule ===
=== Expected schedule ===
Line 71: Line 72:


All those builds on all architectures except jdk8, where arm32 with jit is built by different package.
All those builds on all architectures except jdk8, where arm32 with jit is built by different package.
Unluckily, the  32 bit builds of jdk are rotten in upstream. The recent breakage of i686 jit just before branching nearly killed jdk17 as system jdk feature.
Unluckily, the  i686 bit builds of jdk are rotten in upstream. The recent breakage of i686 JIT just before branching nearly killed jdk17 as system jdk feature.
The rotting have main visibility with newer GCC. If gcc bump, and it does, it always tirggers new issues in i686 jit, and there is less and less people to fix somehow workaround them. Unluckily, there is probably no longer anyone willing to really fix them
The rotting have main visibility with newer GCCs. If GCC bump, and it does, it always triggers new issues in i686 JIT, and there is less and less people to somehow workaround them. Unluckily, there is probably no longer anyone willing to really fix them
 
Although there is https://fedoraproject.org/wiki/Changes/EncourageI686LeafRemoval ,  this proposal have nothign to do with it, not even inspiration. People about OpenJDK learned about after this jdk one was announced.


== Benefit to Fedora ==
== Benefit to Fedora ==
Line 107: Line 110:
== Scope ==
== Scope ==
==== Change owners ====
==== Change owners ====
* we will simiply stop building i686 pkg in rawhide
* After recursive dependency scan was done, i was discovered that the change affects moreover whole system
** initial recursive scan pkg requiring or build requiring java and friends (https://github.com/judovana/FedoraSystemJdkBump/blob/1f126a2d7a4235593b1575467f420b185e5ecb13/scritps/listPkgs/recursiveGlue.sh#L54)  pulled in automake and few others, which n second recursive round pulled in moreover whole system
*** I do no have record of this search as it was useless
**  Second run was run without automake. Still second round took in automake and thus third and fourth recursion run into morevoer whole system.
*** those results are already parse able. I even generated the chart, but that was pretty flat pointng to automake and autoconf
*** Reuslts: https://jvanek.fedorapeople.org/i686Deps/withAutconf.tar.gz
** third run was run again with autoconf and automake, however all '''build time requires''' for '''noarch''' results were omitted, as those have no real impact in real usage
*** unluckily during recursion, automake and autoconf  were hit again on level 3 and four, so later whole system got pulled in
*** results: https://jvanek.fedorapeople.org/i686Deps/withNoarcBrOff.tar.gz
** final sane scan was done with all '''build time requires''' for '''noarch'''  packages ommited, together with big blacklist of already known trouble makers:  https://github.com/judovana/FedoraSystemJdkBump/blob/1f126a2d7a4235593b1575467f420b185e5ecb13/scritps/listPkgs/recursiveGlue.sh#L142
** results https://jvanek.fedorapeople.org/i686Deps/withNoarcBrOffWithBlacklist.tar.gz
** those results are already sane (70 000 edges in unreadable chart)
 
==== Workflow ====
=====  new macro =====
* new macro `%{java_arches}` which will be of value : aarch64 ppc64le s390x x86_64
** will be declared
* Once done:
=====  crucial system pckages =====
** All most crucial affected pkg - [https://github.com/judovana/FedoraSystemJdkBump/blob/1f126a2d7a4235593b1575467f420b185e5ecb13/scritps/listPkgs/recursiveGlue.sh#L142 the blacklist] + few others, eg R,graphviz (suggestions welcomed, bottom of sorted by dependent children [https://jvanek.fedorapeople.org/i686Deps/sortedFilteredRequires list]) will get filled bugzilla -[https://fedoraproject.org/wiki/Changes/Drop_i686_JDKs#crucial_dependences_transitively_depndnding_on_java(s) listing] - eg:
<pre>
adapt [cairo] to removal of java on i686
 
Dear maintainer, we are going to drop i686 java-openjdk packages in f37 - https://fedoraproject.org/wiki/Changes/Drop_i686_JDKs
Your package (maybe jsut some subpakcage) is transitively affected by this change:
 
[cairo<-libxcb<-doxygen<-git<-subversion<-java-11-openjdk-devel
cairo<-libxcb<-graphviz<-ruby<-git<-subversion<-java-11-openjdk-devel
cairo<-libxcb<-graphviz<-R-devel<-R-java-devel<-java-17-openjdk-devel
...
cairo<-gtk-doc<-docbook-utils<-gawk<-git<-gawk<-git<-subversion<-java-11-openjdk-devel
Shown 50 from 568]
 
This package was selected as one of the most crucial, which when missing, will burn distro down.
Please take care, and adapt  your package to exclude java on i686. For  your convenience, there was added macro %{java_arches}, including all arches java is available on,  which you can use to ifarch-out java specific features out in i686 (on non-java arches). Although for plain java package, the change is as simple as https://src.fedoraproject.org/rpms/maven/c/520942645bfd1e4721dacd536a6ccbf80495a8ae?branch=rawhide, you can not use it. The ExclusiveArch: %{java_arches} is not going to work for you, because your package is not simple java application, and also non-java world depends on it (even if you are one of dozen noarchs in this set)
See exemplar PR: https://src.fedoraproject.org/rpms/graphviz/pull-request/9#request_diff
See more details eg in:: https://bugzilla.redhat.com/show_bug.cgi?id=2102298
See why in : https://pagure.io/fesco/issue/2772
Please read carefully proposal: https://fedoraproject.org/wiki/Changes/Drop_i686_JDKs
Please see tracking bug for most up to date informations: https://bugzilla.redhat.com/show_bug.cgi?id=2083750
(note, that direct dependencies are already work in progress - native reported and worked on, noarch ones autoadjusted)
 
I'm terribly sorry to report this bug so late in f37 lifecycle. If you can, please handle this with priority.
</pre>
=====  directly depnding not-noarch (archfull) pkgs =====
** all '''native''' (not noarch) direct dependencies of javas', maven ant (as in [https://github.com/judovana/FedoraSystemJdkBump/blob/main/scritps/listPkgs/recursiveGlue.sh#L54 here] and [https://github.com/judovana/FedoraSystemJdkBump/blob/1f126a2d7a4235593b1575467f420b185e5ecb13/scritps/listPkgs/listJavaDependentPkgs.sh#L19 here] (to be generated)  will get filled bugzilla -[https://fedoraproject.org/wiki/Changes/Drop_i686_JDKs#direct_arch-full_java_dependencies listing] - eg:
<pre>
native [libreoffice] depends on to be removed i686 java-openjdk packages
 
Dear maintainer, we are going to drop i686 java packages in f37 - https://fedoraproject.org/wiki/Changes/Drop_i686_JDKs
your package (or maybe jsut some subpackage)  is directly depending on java and is native.
 
Please take care, and adapt  your package to exclude java on i686. For  your convenience, there was added macro %{java_arches}, including all arches java is available on,  which you can use to ifarch-out java specific features out in i686 (on non-java arches). Although for plain java package, the change is as simple as https://src.fedoraproject.org/rpms/maven/c/520942645bfd1e4721dacd536a6ccbf80495a8ae?branch=rawhide, you can not use it. The ExclusiveArch: %{java_arches} is not going to work for you, because your package is not simple java application, and also non-java world depends on it.
 
See exemplar PR: https://src.fedoraproject.org/rpms/graphviz/pull-request/9#request_diff
See more details eg in:: https://bugzilla.redhat.com/show_bug.cgi?id=2102298
See why in : https://pagure.io/fesco/issue/2772
Please read carefully proposal: https://fedoraproject.org/wiki/Changes/Drop_i686_JDKs
Please see tracking bug for most up to date informations: https://bugzilla.redhat.com/show_bug.cgi?id=2083750
 
I'm terribly sorry to report this bug so late in f37 lifecycle. If you can, please handle this with priority.
</pre>
=====  directly depnding noarch pkgs =====
** all '''noarch''' direct java, amven ant... dependencies will -[https://fedoraproject.org/wiki/Changes/Drop_i686_JDKs#direct_noarch_java_dependencies listing] -  get auto injected `ExclusiveArch: %{java_arches} noarch` if not present, or appended by `%{java_arches}` if ExclusiveArch already  there
** all bugs will block this feature main bug
* if all goes ok, we will simply stop building i686 java pacakges in rawhide
* I'm not sure if there is any sense in creating copr for this, as there is no proper i686 there...
 
=====  deprecated i686 java packages =====
As shcedule did not went as expected, instead of direct removal, which would cause to much packages to FTBFS during mass rebuild, i686 jdk will be derecated in i686, by having bianries repalced by warning, not working shell script: https://src.fedoraproject.org/rpms/java-17-openjdk/c/73fbfeeb34244ac9e1b105d6dea094c1f4d7f1cb?branch=rawhide


==== Other developers ====
==== Other developers ====
* may notice the multilib i686 java missing.  
* may notice the multilib i686 java missing.  
* it is up to them to drop i686 builds or to povide workaround (if possible)
* it is up to them to drop i686/use %{java_arches} in specfiles or to provide reasonable workaround
 
* '''have to adapt theirs packages according to filled bugs'''


==== Other ====
==== Other ====
Line 120: Line 192:
<!-- What work do other developers have to accomplish to complete the feature in time for release?  Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?-->
<!-- What work do other developers have to accomplish to complete the feature in time for release?  Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?-->


* Release engineering: todo <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
* Release engineering: [https://pagure.io/releng/issue/10686 #10686]
** mass rebuild will be required for this change
** mass rebuild will NOT be required for this change
<!-- Does this feature require coordination with release engineering (e.g. changes to installer image generation or update package delivery)?  Is a mass rebuild required?  include a link to the releng issue.  
<!-- Does this feature require coordination with release engineering (e.g. changes to installer image generation or update package delivery)?  Is a mass rebuild required?  include a link to the releng issue.  
The issue is required to be filed prior to feature submission, to ensure that someone is on board to do any process development work and testing, and that all changes make it into the pipeline; a bullet point in a change is not sufficient communication -->
The issue is required to be filed prior to feature submission, to ensure that someone is on board to do any process development work and testing, and that all changes make it into the pipeline; a bullet point in a change is not sufficient communication -->
Line 129: Line 201:
* Trademark approval: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
<!-- If your Change may require trademark approval (for example, if it is a new Spin), file a ticket ( https://fedorahosted.org/council/ ) requesting trademark approval from the Fedora Council. This approval will be done via the Council's consensus-based process. -->
<!-- If your Change may require trademark approval (for example, if it is a new Spin), file a ticket ( https://fedorahosted.org/council/ ) requesting trademark approval from the Fedora Council. This approval will be done via the Council's consensus-based process. -->
* Bug assignees will need to verify the impact of i686


== Upgrade/compatibility impact ==
== Upgrade/compatibility impact ==
* The upgrade on multilib systems will lead to autoremoval of i686 javastack  
* The upgrade on multilib systems will lead to autoremoval of i686 javastack  
* which should be minimum - 99% of javastack is noarch
* which should be minimum if above bugzillas are properly handled
<!-- What happens to systems that have had a previous versions of Fedora installed and are updated to the version containing this change? Will anything require manual configuration or data migration? Will any existing functionality be no longer supported? -->
<!-- What happens to systems that have had a previous versions of Fedora installed and are updated to the version containing this change? Will anything require manual configuration or data migration? Will any existing functionality be no longer supported? -->
<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
Line 164: Line 237:
  - Green has been scientifically proven to be the most relaxing color. The move to a default background color of green with green text will result in Fedora users being the most relaxed users of any operating system.
  - Green has been scientifically proven to be the most relaxing color. The move to a default background color of green with green text will result in Fedora users being the most relaxed users of any operating system.
-->
-->
User experience on multilib systems will be bad.
User experience on multilib systems will be bad. Bad reasonable.
 
== Dependencies ==
== Dependencies ==
There are unknown multilib java consumers. This will need to evolve dynamically
There are is unknown number of multilib java consumers. I expect some of them may rise voice, but that will have to handled one by one.
 
<!-- What other packages (RPMs) depend on this package?  Are there changes outside the developers' control on which completion of this change depends?  In other words, completion of another change owned by someone else and might cause you to not be able to finish on time or that you would need to coordinate?  Other upstream projects like the kernel (if this is not a kernel change)? -->
<!-- What other packages (RPMs) depend on this package?  Are there changes outside the developers' control on which completion of this change depends?  In other words, completion of another change owned by someone else and might cause you to not be able to finish on time or that you would need to coordinate?  Other upstream projects like the kernel (if this is not a kernel change)? -->


== Contingency Plan ==
== Contingency Plan ==
<!-- If you cannot complete your feature by the final development freeze, what is the backup plan?  This might be as simple as "Revert the shipped configuration".  Or it might not (e.g. rebuilding a number of dependent packages).  If you feature is not completed in time we want to assure others that other parts of Fedora will not be in jeopardy.  -->
<!-- If you cannot complete your feature by the final development freeze, what is the backup plan?  This might be as simple as "Revert the shipped configuration".  Or it might not (e.g. rebuilding a number of dependent packages).  If you feature is not completed in time we want to assure others that other parts of Fedora will not be in jeopardy.  -->
* Contingency mechanism:  return i686 packages  <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
* Contingency mechanism:  return i686 java packages  <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
<!-- When is the last time the contingency mechanism can be put in place?  This will typically be the beta freeze. -->
* Contingency date: (not provided)
<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
<!-- Does finishing this feature block the release, or can we ship with the feature in incomplete state? -->


== Documentation ==
== Documentation ==
Will be neded...
Will be needed...


== Release Notes ==
== Release Notes ==
Line 188: Line 257:
-->
-->
None yet...
None yet...
== final listings ==
All those packages vere identified as live, valid rpm top level components - non subpackages, not dead.pcakcage.
=== crucial dependences transitively depndnding on java(s)  ===
manually selected packages which, when in troubles, would cause system to case
<pre>
alsa-lib
atk
bash
boost
cairo
cmake
coreutils
doxygen
findutils
fontconfig
freetype
gawk
gcc
gettext
ghc
git
glib2
glibc
gmp
gnupg2
graphviz
gtk2
gtk3
harfbuzz
kf5
kf5-kio
libglvnd
libtool
libX11
libXext
make
mesa
ocaml
openssl
pango
perl
php
pkgconf
qt5-qtbase
qt
R
rust
rust-web-sys
sed
systemd
tesseract
vala
zlib
</pre>
from those  <pre>autoconf automake meson qt5 rubygems rubypick texlive</pre> are noarch, but am not going to handle it separately.
Automake, and autoconf are  handled individually: https://bugzilla.redhat.com/show_bug.cgi?id=2102298 ,  https://bugzilla.redhat.com/show_bug.cgi?id=2103921
note, that more packages can be added to this basic set, but the number of dependent pkgs was goind down with exponential speed.
==== Second wave ====
Check all top level depndencies of pkg :
for all pkgs, from the
`
p<p1<p2<someJava
p<p3<p4<someJava
`
Select all p2,p4...
No need to spam other secondary transitive deps, maintainers of first wave were not interested
=== direct noarch java dependencies  ===
<pre>
ant-antunit
antlr32
antlr-maven-plugin
antlrworks
ant
aopalliance
apache-commons-beanutils
apache-commons-cli
apache-commons-codec
apache-commons-collections4
apache-commons-collections
apache-commons-compress
apache-commons-digester
apache-commons-exec
apache-commons-fileupload
apache-commons-io
apache-commons-jxpath
apache-commons-lang3
apache-commons-logging
apache-commons-math
apache-commons-modeler
apache-commons-net
apache-commons-parent
apache-commons-pool
apache-ivy
apache-parent
apache-resource-bundles
apache-sshd
apiguardian
aqute-bnd
args4j
assertj-core
atinject
automake
auto
BareBonesBrowserLaunch
batik
bcel
beansbinding
beust-jcommander
bouncycastle
brazil
bsf
bsh
buildnumber-maven-plugin
byte-buddy
byteman
cambozola
canl-java
CardManager
cdi-api
CFR
cglib
classloader-leak-test-framework
classpathless-compiler
clojure-core-specs-alpha
clojure-maven-plugin
clojure
clojure-spec-alpha
codehaus-parent
colossus
console-image-viewer
cortado
crypto-policies
decentxml
directory-maven-plugin
dirgra
disruptor
ditaa
dom4j
easymock
ecj
ed25519-java
enjarify
exec-maven-plugin
fasterxml-oss-parent
felix-parent
felix-utils
fernflower
filedrop
fishbowl
flute
fop
forge-parent
freecol
freemarker
freerouting
fusesource-pom
google-gson
google-guice
guava
hamcrest
hawtjni
hibernate-jpa-2.0-api
hibernate-jpa-2.1-api
hid4java
httpcomponents-client
httpcomponents-core
httpcomponents-project
icu4j
imagej
IPAddress
jackson-annotations
jackson-bom
jackson-core
jackson-databind
jackson-dataformats-binary
jackson-dataformats-text
jackson-jaxrs-providers
jackson-modules-base
jackson-parent
jacoco
jacop
jakarta-activation
jakarta-annotations
jakarta-el
jakarta-interceptors
jakarta-json
jakarta-mail
jakarta-oro
jakarta-saaj
jakarta-server-pages
jakarta-servlet
jakarta-xml-ws
janino
jansi1
jargs
javacc-maven-plugin
javacc
java_cup
java-diff-utils
java-dirq
javaewah
java-jd-decompiler
java-mersenne-twister
javapackages-bootstrap
javapackages-tools
javaparser
javapoet
java-runtime-decompiler
java-scrypt
javassist
jaxb-api
jaxb-dtd-parser
jaxb-fi
jaxb-istack-commons
jaxb
jaxb-stax-ex
jaxen
jboss-jaxrs-2.0-api
jboss-logging
jboss-logging-tools
jboss-parent
jchardet
jcip-annotations
jcodings
jcommon
jcommon-serializer
jctools
jcuber
jdeparser
jdependency
jdepend
jdom2
jdom
jericho-html
jetty
jflex
jFormatString
jfreechart
jgit
jglobus
jgoodies-common
jgoodies-forms
jgoodies-looks
jgrapht
jline2
jline
jmock
jmol
jneuroml-core
jnr-constants
jnr-ffi
jnr-netdb
jnr-posix
jnr-x86asm
jol
jolokia-jvm-agent
joni
jopt-simple
jorbis
jpanoramamaker
jsch-agent-proxy
jsch
json_simple
jsr-305
jtidy
junit5
junit
juniversalchardet
jzlib
laf-plugin
lancer
ldapjdk
libbase
libfonts
libformula
liblayout
libloader
librepository
libserializer
libvirt-java
log4j
mariadb-java-client
Mars
maven2
maven-antrun-plugin
maven-archetype
maven-archiver
maven-artifact-transfer
maven-assembly-plugin
maven-clean-plugin
maven-common-artifact-filters
maven-compiler-plugin
maven-dependency-analyzer
maven-dependency-plugin
maven-dependency-tree
maven-doxia
maven-doxia-sitetools
maven-enforcer
maven-file-management
maven-filtering
maven-invoker
maven-invoker-plugin
maven-jar-plugin
maven-mapping
maven-native
maven
maven-parent
maven-patch-plugin
maven-plugin-build-helper
maven-plugin-bundle
maven-plugin-testing
maven-plugin-tools
maven-remote-resources-plugin
maven-reporting-api
maven-reporting-impl
maven-resolver
maven-resources-plugin
maven-scm
maven-script-interpreter
maven-shade-plugin
maven-shared-incremental
maven-shared-io
maven-shared-utils
maven-source-plugin
maven-surefire
maven-verifier
maven-verifier-plugin
maven-wagon
miglayout
mockito
modello
mojo-executor
mojo-parent
munge-maven-plugin
mxparser
mysql-connector-java
naga
nekohtml
nom-tam-fits
objectweb-asm
objenesis
ongres-scram
ongres-stringprep
openas2
openjdk-asmtools
openstack-java-sdk
OpenStego
opentest4j
options
osgi-annotation
osgi-compendium
osgi-core
pcfi
pdfbox
pdftk-java
pentaho-libxml
pentaho-reporting-flow-engine
picocli
plantuml
plexus-active-collections
plexus-archiver
plexus-build-api
plexus-cipher
plexus-classworlds
plexus-compiler
plexus-component-api
plexus-components-pom
plexus-containers
plexus-i18n
plexus-interpolation
plexus-io
plexus-languages
plexus-pom
plexus-resources
plexus-sec-dispatcher
plexus-utils
plexus-velocity
pomchecker
portlet-2.0-api
postgresql-jdbc
procyon
proguard
prometheus-jmx-exporter
prometheus-simpleclient-java
py4j
python-javaobj
qdox
rachota
reflections
regexp
replacer
resteasy
rhino
rsyntaxtextarea
rundoc
sac
sat4j
sblim-cim-client2
sblim-cim-client
scalacheck
scala
scannotation
sequence-library
serp
shaman
sisu-mojos
sisu
slf4j
snakeyaml
snip
spec-version-maven-plugin
spice-parent
sqljet
stringtemplate4
string-template-maven-plugin
stringtemplate
svnkit
swing-layout
system-rules
taggle
tagsoup
t-digest
test-interface
testng
texlive
tomcatjss
tomcat
tomcat-taglibs-parent
treelayout
trilead-ssh2
truth
univocity-parsers
uom-parent
vecmath1.2
velocity
vim-syntastic
voms-api-java
voms-clients-java
weld-parent
ws-commons-util
wsdl4j
xalan-j2
xbean
xerces-j2
xjparse
xml-commons-apis
xml-commons-resolver
xmlgraphics-commons
xml-maven-plugin
xmlpull
xmlstreambuffer
xmltool
xmlunit
xmpcore
xmvn-connector-ivy
xmvn
xstream
xz-java
yuicompressor
</pre>
=== direct arch-full java dependencies  ===
<pre>
abrt-java-connector
antlr3
antlr4-project
antlr
apron
arduino-listSerialPortsC
astyle
AusweisApp2
bigloo
bolzplatz2006
brltty
capstone
ceph
chromium
cocoalib
collectd
cryptlib
csound
cvc4
DecodeIR
diffoscope
dl_poly
dogtag-pki
eclipse-swt
erlang
erlang-corba
freewrl
frysk
gdal
gdl
genders
gnulib
graphviz
hdf5
hdf
healpix
hyperestraier
icecat
jansi
jansi-native
java-11-openjdk
java-17-openjdk
java-1.8.0-openjdk
java-gnome
jblas
jffi
jigawatts
jna
jni-inchi
jpcap
jpype
jss
jssc
kawa
kernel-tools
libbluray
libgda
libidn
libphidget
libreoffice
libsvm
libwebp
link-grammar
mapserver
mecab-java
mp
nailgun
ocaml-atd
octave
opencv
openjfx8
openjfx
openmpi
openni
pcl
pl
plplot
portmidi
ppl
protobuf
python-javabridge
python-jep
python-jnius
qdbm
R
rstudio
scalpel
sdljava
seqan2
seqan
Singular
sphinx
subversion
systemtap
tomcat-native
tuxguitar
tzdata
vtk
will-crash
writer2latex
z3
zbar
</pre>
From those, subversion is handled separately: https://bugzilla.redhat.com/show_bug.cgi?id=2103909

Latest revision as of 10:04, 17 July 2022


Drop i686 builds of jdk8,11,17 and latest (18) rpms from f37 onwards

Summary

java-1.8.0-openjdk, java-11-openjdk, java-17-openjdk and java-latest-openjdk packages will no longer build i686 subpackages

Owner

  • Name: Jiri Vanek
  • Email: <jvanek@redhat.com>
  • Product: java and java stack
  • Responsible WG: java-sig (java and java-maint)(which no longer exists)


Current status

Expected schedule

  • during march, drop i686 builds from all jdks in fedora rawhide

Detailed Description

Fedora currently ships:

  • java-1.8.0-openjdk (LTS)
  • java-11-openjdk (LTS)
  • java-17-openjdk (LTS)
  • java-latest-openjdk (STS, jdk18).

All those builds on all architectures except jdk8, where arm32 with jit is built by different package. Unluckily, the i686 bit builds of jdk are rotten in upstream. The recent breakage of i686 JIT just before branching nearly killed jdk17 as system jdk feature. The rotting have main visibility with newer GCCs. If GCC bump, and it does, it always triggers new issues in i686 JIT, and there is less and less people to somehow workaround them. Unluckily, there is probably no longer anyone willing to really fix them

Although there is https://fedoraproject.org/wiki/Changes/EncourageI686LeafRemoval , this proposal have nothign to do with it, not even inspiration. People about OpenJDK learned about after this jdk one was announced.

Benefit to Fedora

The i686 builds are rotten in usptream, and to patch them localy had become pain. We may be introducing very bugy i686 jdk. Better then to do so, we would rather not ship that at all. This will untie hands of both JDK and GCC developers, who will no longer need to dive into nasty legacy code.

Scope

Change owners

Workflow

new macro
  • new macro %{java_arches} which will be of value : aarch64 ppc64le s390x x86_64
    • will be declared
  • Once done:
crucial system pckages
    • All most crucial affected pkg - the blacklist + few others, eg R,graphviz (suggestions welcomed, bottom of sorted by dependent children list) will get filled bugzilla -listing - eg:
adapt [cairo] to removal of java on i686

Dear maintainer, we are going to drop i686 java-openjdk packages in f37 - https://fedoraproject.org/wiki/Changes/Drop_i686_JDKs
Your package (maybe jsut some subpakcage) is transitively affected by this change:

[cairo<-libxcb<-doxygen<-git<-subversion<-java-11-openjdk-devel
cairo<-libxcb<-graphviz<-ruby<-git<-subversion<-java-11-openjdk-devel
cairo<-libxcb<-graphviz<-R-devel<-R-java-devel<-java-17-openjdk-devel
...
cairo<-gtk-doc<-docbook-utils<-gawk<-git<-gawk<-git<-subversion<-java-11-openjdk-devel
Shown 50 from 568]

This package was selected as one of the most crucial, which when missing, will burn distro down.
Please take care, and adapt  your package to exclude java on i686. For  your convenience, there was added macro %{java_arches}, including all arches java is available on,  which you can use to ifarch-out java specific features out in i686 (on non-java arches). Although for plain java package, the change is as simple as https://src.fedoraproject.org/rpms/maven/c/520942645bfd1e4721dacd536a6ccbf80495a8ae?branch=rawhide, you can not use it. The ExclusiveArch: %{java_arches} is not going to work for you, because your package is not simple java application, and also non-java world depends on it (even if you are one of dozen noarchs in this set)
See exemplar PR: https://src.fedoraproject.org/rpms/graphviz/pull-request/9#request_diff
See more details eg in:: https://bugzilla.redhat.com/show_bug.cgi?id=2102298
See why in : https://pagure.io/fesco/issue/2772
Please read carefully proposal: https://fedoraproject.org/wiki/Changes/Drop_i686_JDKs
Please see tracking bug for most up to date informations: https://bugzilla.redhat.com/show_bug.cgi?id=2083750
(note, that direct dependencies are already work in progress - native reported and worked on, noarch ones autoadjusted)

I'm terribly sorry to report this bug so late in f37 lifecycle. If you can, please handle this with priority.
directly depnding not-noarch (archfull) pkgs
    • all native (not noarch) direct dependencies of javas', maven ant (as in here and here (to be generated) will get filled bugzilla -listing - eg:
native [libreoffice] depends on to be removed i686 java-openjdk packages

Dear maintainer, we are going to drop i686 java packages in f37 - https://fedoraproject.org/wiki/Changes/Drop_i686_JDKs
your package (or maybe jsut some subpackage)  is directly depending on java and is native.

Please take care, and adapt  your package to exclude java on i686. For  your convenience, there was added macro %{java_arches}, including all arches java is available on,  which you can use to ifarch-out java specific features out in i686 (on non-java arches). Although for plain java package, the change is as simple as https://src.fedoraproject.org/rpms/maven/c/520942645bfd1e4721dacd536a6ccbf80495a8ae?branch=rawhide, you can not use it. The ExclusiveArch: %{java_arches} is not going to work for you, because your package is not simple java application, and also non-java world depends on it.

See exemplar PR: https://src.fedoraproject.org/rpms/graphviz/pull-request/9#request_diff
See more details eg in:: https://bugzilla.redhat.com/show_bug.cgi?id=2102298
See why in : https://pagure.io/fesco/issue/2772
Please read carefully proposal: https://fedoraproject.org/wiki/Changes/Drop_i686_JDKs
Please see tracking bug for most up to date informations: https://bugzilla.redhat.com/show_bug.cgi?id=2083750

I'm terribly sorry to report this bug so late in f37 lifecycle. If you can, please handle this with priority.
directly depnding noarch pkgs
    • all noarch direct java, amven ant... dependencies will -listing - get auto injected ExclusiveArch: %{java_arches} noarch if not present, or appended by %{java_arches} if ExclusiveArch already there
    • all bugs will block this feature main bug
  • if all goes ok, we will simply stop building i686 java pacakges in rawhide
  • I'm not sure if there is any sense in creating copr for this, as there is no proper i686 there...
deprecated i686 java packages

As shcedule did not went as expected, instead of direct removal, which would cause to much packages to FTBFS during mass rebuild, i686 jdk will be derecated in i686, by having bianries repalced by warning, not working shell script: https://src.fedoraproject.org/rpms/java-17-openjdk/c/73fbfeeb34244ac9e1b105d6dea094c1f4d7f1cb?branch=rawhide

Other developers

  • may notice the multilib i686 java missing.
  • it is up to them to drop i686/use %{java_arches} in specfiles or to provide reasonable workaround
  • have to adapt theirs packages according to filled bugs

Other

  • Release engineering: #10686
    • mass rebuild will NOT be required for this change


  • Trademark approval: N/A (not needed for this Change)
  • Bug assignees will need to verify the impact of i686

Upgrade/compatibility impact

  • The upgrade on multilib systems will lead to autoremoval of i686 javastack
  • which should be minimum if above bugzillas are properly handled

How To Test

install i686 java will result to not packages found

User Experience

User experience on multilib systems will be bad. Bad reasonable.

Dependencies

There are is unknown number of multilib java consumers. I expect some of them may rise voice, but that will have to handled one by one.

Contingency Plan

  • Contingency mechanism: return i686 java packages
  • Contingency date: (not provided)

Documentation

Will be needed...

Release Notes

None yet...

final listings

All those packages vere identified as live, valid rpm top level components - non subpackages, not dead.pcakcage.

crucial dependences transitively depndnding on java(s)

manually selected packages which, when in troubles, would cause system to case 

alsa-lib
atk
bash
boost
cairo
cmake
coreutils
doxygen
findutils
fontconfig
freetype
gawk
gcc
gettext
ghc
git
glib2
glibc
gmp
gnupg2
graphviz
gtk2
gtk3
harfbuzz
kf5
kf5-kio
libglvnd
libtool
libX11
libXext
make
mesa
ocaml
openssl
pango
perl
php
pkgconf
qt5-qtbase
qt
R
rust
rust-web-sys
sed
systemd
tesseract
vala
zlib

from those 

autoconf automake meson qt5 rubygems rubypick texlive

are noarch, but am not going to handle it separately.

Automake, and autoconf are handled individually: https://bugzilla.redhat.com/show_bug.cgi?id=2102298 , https://bugzilla.redhat.com/show_bug.cgi?id=2103921 note, that more packages can be added to this basic set, but the number of dependent pkgs was goind down with exponential speed.

Second wave

Check all top level depndencies of pkg : for all pkgs, from the p<p1<p2<someJava p<p3<p4<someJava Select all p2,p4...

No need to spam other secondary transitive deps, maintainers of first wave were not interested

direct noarch java dependencies

ant-antunit
antlr32
antlr-maven-plugin
antlrworks
ant
aopalliance
apache-commons-beanutils
apache-commons-cli
apache-commons-codec
apache-commons-collections4
apache-commons-collections
apache-commons-compress
apache-commons-digester
apache-commons-exec
apache-commons-fileupload
apache-commons-io
apache-commons-jxpath
apache-commons-lang3
apache-commons-logging
apache-commons-math
apache-commons-modeler
apache-commons-net
apache-commons-parent
apache-commons-pool
apache-ivy
apache-parent
apache-resource-bundles
apache-sshd
apiguardian
aqute-bnd
args4j
assertj-core
atinject
automake
auto
BareBonesBrowserLaunch
batik
bcel
beansbinding
beust-jcommander
bouncycastle
brazil
bsf
bsh
buildnumber-maven-plugin
byte-buddy
byteman
cambozola
canl-java
CardManager
cdi-api
CFR
cglib
classloader-leak-test-framework
classpathless-compiler
clojure-core-specs-alpha
clojure-maven-plugin
clojure
clojure-spec-alpha
codehaus-parent
colossus
console-image-viewer
cortado
crypto-policies
decentxml
directory-maven-plugin
dirgra
disruptor
ditaa
dom4j
easymock
ecj
ed25519-java
enjarify
exec-maven-plugin
fasterxml-oss-parent
felix-parent
felix-utils
fernflower
filedrop
fishbowl
flute
fop
forge-parent
freecol
freemarker
freerouting
fusesource-pom
google-gson
google-guice
guava
hamcrest
hawtjni
hibernate-jpa-2.0-api
hibernate-jpa-2.1-api
hid4java
httpcomponents-client
httpcomponents-core
httpcomponents-project
icu4j
imagej
IPAddress
jackson-annotations
jackson-bom
jackson-core
jackson-databind
jackson-dataformats-binary
jackson-dataformats-text
jackson-jaxrs-providers
jackson-modules-base
jackson-parent
jacoco
jacop
jakarta-activation
jakarta-annotations
jakarta-el
jakarta-interceptors
jakarta-json
jakarta-mail
jakarta-oro
jakarta-saaj
jakarta-server-pages
jakarta-servlet
jakarta-xml-ws
janino
jansi1
jargs
javacc-maven-plugin
javacc
java_cup
java-diff-utils
java-dirq
javaewah
java-jd-decompiler
java-mersenne-twister
javapackages-bootstrap
javapackages-tools
javaparser
javapoet
java-runtime-decompiler
java-scrypt
javassist
jaxb-api
jaxb-dtd-parser
jaxb-fi
jaxb-istack-commons
jaxb
jaxb-stax-ex
jaxen
jboss-jaxrs-2.0-api
jboss-logging
jboss-logging-tools
jboss-parent
jchardet
jcip-annotations
jcodings
jcommon
jcommon-serializer
jctools
jcuber
jdeparser
jdependency
jdepend
jdom2
jdom
jericho-html
jetty
jflex
jFormatString
jfreechart
jgit
jglobus
jgoodies-common
jgoodies-forms
jgoodies-looks
jgrapht
jline2
jline
jmock
jmol
jneuroml-core
jnr-constants
jnr-ffi
jnr-netdb
jnr-posix
jnr-x86asm
jol
jolokia-jvm-agent
joni
jopt-simple
jorbis
jpanoramamaker
jsch-agent-proxy
jsch
json_simple
jsr-305
jtidy
junit5
junit
juniversalchardet
jzlib
laf-plugin
lancer
ldapjdk
libbase
libfonts
libformula
liblayout
libloader
librepository
libserializer
libvirt-java
log4j
mariadb-java-client
Mars
maven2
maven-antrun-plugin
maven-archetype
maven-archiver
maven-artifact-transfer
maven-assembly-plugin
maven-clean-plugin
maven-common-artifact-filters
maven-compiler-plugin
maven-dependency-analyzer
maven-dependency-plugin
maven-dependency-tree
maven-doxia
maven-doxia-sitetools
maven-enforcer
maven-file-management
maven-filtering
maven-invoker
maven-invoker-plugin
maven-jar-plugin
maven-mapping
maven-native
maven
maven-parent
maven-patch-plugin
maven-plugin-build-helper
maven-plugin-bundle
maven-plugin-testing
maven-plugin-tools
maven-remote-resources-plugin
maven-reporting-api
maven-reporting-impl
maven-resolver
maven-resources-plugin
maven-scm
maven-script-interpreter
maven-shade-plugin
maven-shared-incremental
maven-shared-io
maven-shared-utils
maven-source-plugin
maven-surefire
maven-verifier
maven-verifier-plugin
maven-wagon
miglayout
mockito
modello
mojo-executor
mojo-parent
munge-maven-plugin
mxparser
mysql-connector-java
naga
nekohtml
nom-tam-fits
objectweb-asm
objenesis
ongres-scram
ongres-stringprep
openas2
openjdk-asmtools
openstack-java-sdk
OpenStego
opentest4j
options
osgi-annotation
osgi-compendium
osgi-core
pcfi
pdfbox
pdftk-java
pentaho-libxml
pentaho-reporting-flow-engine
picocli
plantuml
plexus-active-collections
plexus-archiver
plexus-build-api
plexus-cipher
plexus-classworlds
plexus-compiler
plexus-component-api
plexus-components-pom
plexus-containers
plexus-i18n
plexus-interpolation
plexus-io
plexus-languages
plexus-pom
plexus-resources
plexus-sec-dispatcher
plexus-utils
plexus-velocity
pomchecker
portlet-2.0-api
postgresql-jdbc
procyon
proguard
prometheus-jmx-exporter
prometheus-simpleclient-java
py4j
python-javaobj
qdox
rachota
reflections
regexp
replacer
resteasy
rhino
rsyntaxtextarea
rundoc
sac
sat4j
sblim-cim-client2
sblim-cim-client
scalacheck
scala
scannotation
sequence-library
serp
shaman
sisu-mojos
sisu
slf4j
snakeyaml
snip
spec-version-maven-plugin
spice-parent
sqljet
stringtemplate4
string-template-maven-plugin
stringtemplate
svnkit
swing-layout
system-rules
taggle
tagsoup
t-digest
test-interface
testng
texlive
tomcatjss
tomcat
tomcat-taglibs-parent
treelayout
trilead-ssh2
truth
univocity-parsers
uom-parent
vecmath1.2
velocity
vim-syntastic
voms-api-java
voms-clients-java
weld-parent
ws-commons-util
wsdl4j
xalan-j2
xbean
xerces-j2
xjparse
xml-commons-apis
xml-commons-resolver
xmlgraphics-commons
xml-maven-plugin
xmlpull
xmlstreambuffer
xmltool
xmlunit
xmpcore
xmvn-connector-ivy
xmvn
xstream
xz-java
yuicompressor

direct arch-full java dependencies

abrt-java-connector
antlr3
antlr4-project
antlr
apron
arduino-listSerialPortsC
astyle
AusweisApp2
bigloo
bolzplatz2006
brltty
capstone
ceph
chromium
cocoalib
collectd
cryptlib
csound
cvc4
DecodeIR
diffoscope
dl_poly
dogtag-pki
eclipse-swt
erlang
erlang-corba
freewrl
frysk
gdal
gdl
genders
gnulib
graphviz
hdf5
hdf
healpix
hyperestraier
icecat
jansi
jansi-native
java-11-openjdk
java-17-openjdk
java-1.8.0-openjdk
java-gnome
jblas
jffi
jigawatts
jna
jni-inchi
jpcap
jpype
jss
jssc
kawa
kernel-tools
libbluray
libgda
libidn
libphidget
libreoffice
libsvm
libwebp
link-grammar
mapserver
mecab-java
mp
nailgun
ocaml-atd
octave
opencv
openjfx8
openjfx
openmpi
openni
pcl
pl
plplot
portmidi
ppl
protobuf
python-javabridge
python-jep
python-jnius
qdbm
R
rstudio
scalpel
sdljava
seqan2
seqan
Singular
sphinx
subversion
systemtap
tomcat-native
tuxguitar
tzdata
vtk
will-crash
writer2latex
z3
zbar

From those, subversion is handled separately: https://bugzilla.redhat.com/show_bug.cgi?id=2103909

Retrieved from "https://fedoraproject.org/w/index.php?title=Changes/Drop_i686_JDKs&oldid=649921"