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
https://fedoraproject.org/wiki/Changes/Java11
Short Story:
* 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
https://copr.fedorainfracloud.org/coprs/jvanek/java11/builds/)
* 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
Long Story:
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)
186 succeeded
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
https://fedoraproject.org/wiki/Changes/Java11#common_issues_packagers_can_f… .
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
build.log.gz.
* 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
fedpkg srpm
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.
Thank You!
On behalf of Fedora java group
J.
Good Morning Everyone,
A little while ago[1], we integrated anitya in dist-git itself, allowing to
stop using fedora-scm-request's[2] 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[3], thus allowing to get rid entirely of the git repository at
fedora-scm-request[2].
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
liking: https://src.stg.fedoraproject.org/
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:
https://src.stg.fedoraproject.org/rpms/0ad
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
EPEL.
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,
Pierre
[1] https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedorapr…
[2] https://pagure.io/releng/fedora-scm-requests
[3] https://pagure.io/pagure-dist-git/
Per the Fedora Release Lifecycle[1], 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.
[1]
https://fedoraproject.org/wiki/Fedora_Release_Life_Cycle#Maintenance_Schedu…
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
Hey folks,
I know everyone has been wondering about if Flock to Fedora will be
happening this year. The answer is yes, though we are going virtual with an
alternate version: Nest with Fedora!
How and what we do is open to community input. Check out this blog post on
the Community Blog, which includes some inspiration:
https://communityblog.fedoraproject.org/nest-with-fedora-call-for-ideas/
I welcome you to open issues here with ideas or add comments to others:
https://pagure.io/flock/issues
Cheers!
*Apologies if you receive this multiple times, I am sending to multiple
lists for coverage.*
--
Marie Nordin
Fedora Community Action and Impact Coordinator
Red Hat <https://www.redhat.com/> • Fedora Project <https://getfedora.org/>
She/Her/Hers
T: +1.973.800.4967
IRC: riecatnor
<https://red.ht/sig>
As previously announced [1], Taskotron [2] will be shut down today. See the
announcement and its discussion for more details and some background info.
As a result, certain tests (beginning with “dist.“) will no longer appear
for new updates in Bodhi (in Automated Tests tab). Some of those tests (and
even new ones) will hopefully come back in the future with the help of
Fedora CI [3].
Thank you to everyone who contributed to Taskotron in the past or found our
test reports helpful.
[1]
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org…
[2] project page: https://pagure.io/taskotron
[3] https://docs.fedoraproject.org/en-US/ci/
https://fedoraproject.org/wiki/Changes/F33Boost173
== 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" [
https://docs.pagure.org/releng/sop_adding_side_build_targets.html build
system tag] ([
http://lists.fedoraproject.org/pipermail/devel/2011-November/159908.html
discussion]): TODO
** Build boost into that tag (take a look at the [
http://koji.fedoraproject.org/koji/buildinfo?buildID=606493 build #606493]
for inspiration)
** 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
guidelines.
* 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>
All clients:
<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
December 2019)
* https://www.boost.org/users/history/version_1_71_0.html (released on 19
August 2019)
* https://www.boost.org/users/history/version_1_70_0.html (released on 12
April 2019)
* https://www.boost.org/development/index.html
== 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 [
https://www.boost.org/libs/static_string/ Boost.StaticString].
* The `bjam` tool in the `boost-jam` package has been replaced by `b2` in
the `boost-b2` package.
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
Dear all,
The Go/No-Go meeting for the Fedora 32 Final release will be held on
Thursday, 2020-04-16 at 17:00 UTC in #fedora-meeting-1. For more
information, see: https://fedoraproject.org/wiki/Go_No_Go_Meeting
View the meeting on Fedocal at:
https://apps.fedoraproject.org/calendar/meeting/9738/
As usual, we will have the Release Readiness meeting following at
19:00 UTC. This time, I'm asking teams to do their homework in
advance. Please update your team's status at:
https://fedoraproject.org/wiki/Release_Readiness
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis