Hello fellow java package maintainers!
We are planning to bump the JDK from java-1.8.0-openjdk to java-11-openjdk for F33. Please see
* if you have some java package, be aware that we are bumping JDK in rawhide
* Ensure your package builds and runs fine with JDK11 (see the
* there is special tooling ready for this, before mass rebuild is launched
** See https://fedoraproject.org/wiki/Changes/Java11#copr_preliminary_rebuild
* If you do not want Fedora rotten with JDK8 for ever, continue reading
We ran a preliminary mass rebuild of javastack in copr repo
https://copr.fedorainfracloud.org/coprs/jvanek/java11/builds/ (select "all" instead of "25" at the
bottom), on packages requiring java,javac, java-devel, maven-local, ant, ivy & comp for build. You
can see, the result was quite dramatic:
1225 total; attempted to rebuild
483 failed; from those 191 are trivial failures (but if you fix it, there is no guarantee real
troubles are not hidden behind that)
556 orphans or dead or otherwise tragic so the build did not even start
I would kindly ask you to search yourself in this list: https://jvanek.fedorapeople.org/java11/people
If you are here, please check status of your package in https://jvanek.fedorapeople.org/java11/init
(pain text of https://copr.fedorainfracloud.org/coprs/jvanek/java11/builds).
* If your package is "succeeded", congratulations nothing to do, and just keep en eye on JDK bump
* If there is "failed" but contains "- -" then it is probably orphan. If you wish to resurrect it,
please ensure it runs against JDK11 (see lower)
* If there is "failed" but failed in "seconds", then those packages failed so quickly, that the
build was in initial phases. That usually mean that you build with source/target lower then 1.6
JDK11 supports 1.6 and up. We recommend to bump the source/target to 1.8, to allow existence of
compact 1.8 packages alongside main javastack. See
https://fedoraproject.org/wiki/Changes/Java11#Wrong_source.2Ftarget_version. Don't forget to
upstream the patch, or maybe it is enough to update to more fresh upstream release which supports
JDK11? it may happen, that after the fix, your build will fail in more terrible way (see below)
* If there is "failed", and its none of above, then your package simply failed. Very often the
scary error may be fixed by bump to latest upstream version. JDK 11 is out for several years.
Please, try to fix the package. Don't hesitate to ask on devel(a)fedoraproject.org or
java-devel(a)fedoraproject.org or directly to me jvanek(a)redhat.com. If you fix the fail, feel free to
share your fix, it may help others.
We are trying to gather the most common issues at
Feel free to enhance the page, or write us your case (possibly both with solution and without) so
we can add it here.
Debugging Your failures.
The copr repo we maintain, contains builds of java-11-openjdk as system JDK, javapackages-tools
honoring that, and java-1.8.0-openjdk as non system JDK. Also it contains successfully rebuilt
packages. You can directly use this copr repo in several ways.
* first glance on error. On https://copr.fedorainfracloud.org/coprs/jvanek/java11/builds/ find your
build (select "all" instead of "25" at the bottom),
** Click its number, select chroot (currently fedora-32-x86_64 ) and check the logs. Main log is
* anything you push to rawhide, will automatically rebuild here in f32 chroot (we have a JDK in
rawhide broken a bit currently)
** It is the best approach. If you can fix your package in rawhide directly, without breaking the
rawhide too much, go for it
** If yo need to experiment, I have a mock config for you (generated from copr-cli mock-config
jvanek/java11 fedora-32-x86_64) which you can copy to your /etc/mock and use -
https://jvanek.fedorapeople.org/java11/jvanek-java11-fedora-32-x86_64.cfg . Eg:
sudo cp downloaded-fedora-32-x86_64.cfg /etc/mock/jvanek-java11-fedora-32-x86_64.cfg
# change spec, bump sources, apply patches
mock -r jvanek-java11-fedora-32-x86_64 *.src.rpm
Or any other packaging workflow you use, and you can use against the copr repo.
Thank you very much for your help, there are 500 failures, and 1000 java packagers, but only 2
active members of java sig. Without your help, the JDK bump will be very hard.
On behalf of Fedora java group
Good Morning Everyone,
A little while ago, we integrated anitya in dist-git itself, allowing to
stop using fedora-scm-request's git repository to store this information.
However, this git repository is still being used to store bugzilla overrides
(i.e.: default assignee on bugzilla ticket when they differ from the point of
contact (main admin) of the package in dist-git).
Together with Karsten Hopp we worked on integrating this functionality on
pagure-dist-git, thus allowing to get rid entirely of the git repository at
This work has been deployed in staging today. We would very much appreciate if
you could take a few minute of your time and see if it works to your
The overrides information from production has been migrated yesterday to the
staging dist-git, so what you see in the UI reflects the current state of the
overrides in production as of yesterday.
Here is an example with an override:
One note: in the rpms namespace, the UI will always show you the default
assignee for Fedora and Fedora EPEL, regardless of whether the package is in
This is a shortcoming we are aware of and will be looking at fixing in the near
future but potentially after it has reached production.
Thank you for your understanding and help testing this,
Per the Fedora Release Lifecycle, Fedora 30 will reach end-of-life four
weeks after the release of Fedora 32. This is Tuesday 26 May 2020. After
this date, no more updates will be available for Fedora 30.
It is Fedora's policy to close all bug reports from releases that are no
longer maintained. On 26 May, all open Fedora 30 bugs will be closed as EOL.
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
== Summary ==
This change brings Boost 1.73 to Fedora. This will mean Fedora ships with a
recent upstream Boost release.
== Owner ==
* Name: [[User:jwakely| Jonathan Wakely]]
* Email: jwakely(a)redhat.com
== Detailed Description ==
The aim is to synchronize Fedora with the most recent Boost release.
Because ABI stability is one of explicit Boost non-goals, this entails
rebuilding of all dependent packages. This has also always entailed yours
truly assisting maintainers of client packages in decoding cryptic
boost-ese seen in output from g++. Such care is to be expected this time
around as well.
The equivalent changes for previous releases were
[[Changes/F30Boost169|Fedora 30 Change]], [[Changes/F29Boost167|Fedora 29
Change]], [[Changes/F28Boost166|Fedora 28 Change]],
[[Changes/F27Boost164|Fedora 27 Change]], [[Changes/F26Boost163|Fedora 26
Change]], [[Changes/F25Boost161|Fedora 25 Change]],
[[Changes/F24Boost160|Fedora 24 Change]], [[Changes/F23Boost159|Fedora 23
Change]] and [[Changes/F22Boost158|Fedora 22 Change]].
== Benefit to Fedora ==
Fedora 32 includes Boost 1.69 which is the same version as F31 and F30, and
is several releases behind the latest upstream release (Boost 1.73 is due
for release late April 2020).
Fedora will stay relevant, as far as Boost clients are concerned. Boost
1.73 brings four new components:
* [https://www.boost.org/libs/outcome/ Boost.Outcome], A set of tools for
reporting and handling function failures in contexts where <i>directly</i>
using C++ exception handling is unsuitable, from Niall Douglas.
* [https://www.boost.org/libs/histogram/ Boost.Histogram], Fast and
extensible multi-dimensional histograms with convenient interface for
C++14, from Hans Dembinski.
* [https://www.boost.org/libs/variant2/ Boost.Variant2], A never-valueless,
strong guarantee implementation of std::variant, from Peter Dimov.
* [https://www.boost.org/libs/nowide/ Boost.Nowide], Standard library
functions with UTF-8 API on Windows, from Artyom Beilis.
* [https://www.boost.org/libs/static_string/ Boost.StaticString], A
dynamically resizable string of characters with compile-time fixed capacity
and contiguous embedded storage, from Vinnie Falco and Krystian Stasiowski.
== Scope ==
* Proposal owners:
** Build will be done with Boost.Build v2 (which is the upstream-sanctioned
way of building Boost)
** Request a "f33-boost" [
system tag] ([
** Build boost into that tag (take a look at the [
http://koji.fedoraproject.org/koji/buildinfo?buildID=606493 build #606493]
** Post a request for rebuilds to fedora-devel
** Work on rebuilding dependent packages in the tag.
** When most is done, re-tag all the packages to rawhide
** Watch fedora-devel and assist in rebuilding broken Boost clients (by
fixing the client, or Boost).
* Other developers:
** Those who depend on Boost DSOs will have to rebuild their packages.
Feature owners will alleviate some of this work as indicated above, and
will assist those whose packages fail to build in debugging them.
** The existing `boost-nowide` package will need to be retired, as it is
now included in the upstream Boost release.
* Release engineering: [https://pagure.io/releng/issue/9421 #9421] (a check
of an impact with Release Engineering is needed)
* Policies and guidelines:
** Apart from scope, this is business as usual, so no new policies, no new
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
* The `boost-jam` package has been replaced by `boost-b2`. The separate
`boost-nowide` package will be replace by a subpackage of `boost`.
* No manual configuration or data migration needed.
* Some impact on other packages needing code changes to rebuild.
Historically this hasn't been too much of a problem and could always be
resolved before deadline.
== How To Test ==
* No special hardware is needed.
* Integration testing simply consists of installing Boost packages (`dnf
install boost`) on Fedora and checking that it does not break other
packages (see below for a way to obtain a list of boost clients).
== User Experience ==
* Expected to remain largely the same.
* Developers building third-party software on Fedora may need to rebuild
against the new Boost packages, and may need to adjust their code if the
new Boost release is not source-compatible.
* Developers using `bjam` to build their own software will need to switch
to using the new name for the tool, `b2`
== Dependencies ==
Packages that must be rebuilt:
<code>$ dnf repoquery -s --releasever=rawhide --whatrequires libboost\*
--disablerepo=* --enablerepo=fedora | sort -u</code>
<code>$ dnf repoquery --releasever=rawhide --archlist=src --whatrequires
boost-devel --disablerepo='*' --enablerepo=fedora-source</code>
== Contingency Plan ==
* Contingency mechanism: Worst case scenario is to abandon the update and
simply ship F33 with Boost 1.69, which is already in rawhide. It would also
be possible to ship an older release (1.70.0, 1.71.0 or 1.72.0) which would
still be newer than in current Fedora releases.
* Contingency deadline: We will know whether the change can be made once
the rebuilds in the side tag are done, which will be July 2020, ideally
before the mass rebuild.
* Blocks release? No
* Blocks product? None
== Documentation ==
* https://www.boost.org/users/history/version_1_73_0.html (Beta1 released
on 12 April 2020, final release expected soon)
* https://www.boost.org/users/history/version_1_72_0.html (released on 11
* https://www.boost.org/users/history/version_1_71_0.html (released on 19
* https://www.boost.org/users/history/version_1_70_0.html (released on 12
== Release Notes ==
Boost has been upgraded to version 1.73. Apart from a number of bug fixes
and improvements to existing libraries. Compared to Fedora 32, this brings:
* New header-only components: [https://www.boost.org/libs/outcome/
Boost.Outcome], [https://www.boost.org/libs/histogram/ Boost.Histogram], [
https://www.boost.org/libs/variant2/ Boost.Variant2], [
https://www.boost.org/libs/nowide/ Boost.Nowide] and [
* The `bjam` tool in the `boost-jam` package has been replaced by `b2` in
the `boost-b2` package.
He / Him / His
Senior Program Manager, Fedora & CentOS Stream