The Death of Java (packages)
by Fabio Valentini
Hi everybody,
Long story short, I can no longer in good conscience be the primary
maintainer of (most) Java packages in Fedora. I am not using any of
them, I don't like Java or any other languages targeting the JVM, and
don't get me started on the horrid Java ecosystem. Recently I've been
spending 40-60 hours per week at my desk, and I just don't have the
capacity to feel guilty for not taking care of those packages any
longer.
New versions and even security issues have been piling up for months
(just look at the SIG's taiga board). Other people tried to step up
for the "new" Java SIG (@java-maint-sig), but other than myself,
nobody has been triaging new bugs in Java packages. Java package
maintainers from Red Hat have been exceptionally unhelpful, and have
not substantially contributed to Java packages in Fedora in years.
Even the Modules that were heralded as "the solution" have stagnated.
On the other hand, Mat Booth and two members of the DogTag PKI team
have been really helpful, but Mat is busy fighting the Eclipse
dumpster fire most of the time, and the other two have since both left
Red Hat for greener pastures. And since I see no way for the situation
to improve, there's only one honest thing left that I can do:
I will orphan all Java packages I am the main admin of, later today.
Since this is the majority of remaining Java software in Fedora (~180
packages), I expect at a decent amount of dependent packages will be
affected. However, given the utter lack of Java package maintainers
and the pitiful state of the overall language ecosystem, I would
strongly urge affected maintainers to drop dependencies on Java, if at
all possible.
Maybe other members of the java-maint-sig will pick up the orphaned
packages, if they're still here. Or maybe it's finally time to let
Java packages die. Nobody seems to care either way.
Fabio
2 years, 9 months
Stepping down as Fedora Jam maintainer
by Erich Eickmeyer
Hello all,
A little over a year ago, I came to the Fedora project to revive and
modernize the Fedora Jam project. I have successfully done that. My
vision was that it would be a great way to help develop and test the
most recent advancements in Linux audio.
Unfortunately, or fortunately, life has a way of changing for the good
or the bad. Back in November, I was offered an opportunity that I could
not pass-up: becoming the User Experience Director for the Kubuntu
Focus brand of laptops made by MindShareManagement. Since then, I have
become an integral member of that team, directly reporting to the CTO,
CEO, and President, working directly with the PR and Sales and
Marketing directors. It has been a blast, and is a project that works
directly with Ubuntu and Debian to create, as we put it, the "Ultimate
Linux Laptop". As a MOTU for Ubuntu, this was a perfect fit.
I didn't come here to be a shill for Ubuntu or to advertise my work,
but rather, to illustrate the level of involvement. It has taken up a
majority of my time, and my work with Ubuntu Studio is directly
involved with the project as well as both Ubuntu Studio and the Kubuntu
Focus laptop have similar synergies.
Because of the amount of time involved in these projects, something has
to give. For that reason, I must step-down as Fedora Jam maintainer. My
plan is to continue to maintain certain packages within Fedora (which,
admittedly, I've been slacking on), but I am orphaning the vast
majority of my packages. Here's the list:
Add64
dssi
dssi-vst
fedora-jam-backgrounds*
fedora-jam-kde-theme*
fluidsynth
fluidsynth-dssi
freqtweak
gnome-guitar
harmony-seq
hexter-dssi
jackctlmmc
jmeters
libinstpatch
lv2-c++-tools
lv2-fabla
lv2-ll-plugins
lv2-mdaEPiano
lv2-newtonator
lv2-sorcer
lv2-swh-plugins
lv2-vocoder-plugins
meterbridge
non-daw
portmidi
radium-compressor
realTimeConfigQuickScan
whysynth-dssi
xsynth-dssi
*These packages have pagure repos which I'd be happy to hand over to
whoever takes these.
I do want to thank everyone for the opportunity, including Matthew
Miller, Ben Cotton, Neal Gompa, and many others that helped me revive
this project. I'm sad to let it go, and I'm not sure what's going to
happen to it, but I hope someone who has a passion for the latest
technologies in Linux Audio and music production can take it over.
Thanks,
Erich Eickmeyer
2 years, 9 months
Fedora 34 Change: LTO Build Improvements (System-Wide Change proposal)
by Ben Cotton
https://fedoraproject.org/wiki/Changes/LTOBuildImprovements
== Summary ==
Currently all packages that are not opted out of LTO include
-ffat-lto-objects in their build flags. This proposal would remove
-ffat-lto-objects from the default LTO flags and only use it for
packages that actually need it.
== Owner ==
* Name: [[User:law | Jeff Law]]
* Email: law(a)redhat.com
== Detailed Description ==
-ffat-lto-objects was added to the default LTO flags to ensure that
any installed .o/.a files included actual compiled code rather than
just LTO bytecodes (which are stripped after the install phase).
However, that is wasteful from a compile-time standpoint as few
packages actually install any .o/.a files.
This proposal would remove -ffat-lto-objects from the default LTO
flags and packages that actually need the option would have to opt-in
via an RPM macro in their .spec file. This should significantly
improve build times for most packages in Fedora.
To ensure that we can identify packages that need the opt-in now and
in the future, the plan is to pass to brp-strip-lto a flag indicating
whether or not the package has opted into -ffat-lto-objects. If
brp-strip-lto finds .o/.a files, but the package has not opted into
-ffat-lto-objects, then brp-strip-lto would signal an error.
== Benefit to Fedora ==
The key benefit to Fedora is improved package build times and lower
load on the builders.
== Scope ==
* Proposal owners: The feature owner (Jeff Law) will need to settle on
a suitable RPM macro to indicate an opt-in to -ffat-lto-objects,
implement the necessary tests in brp-strip-lto and opt-in the initial
set of packages. This will be accomplished by doing the prototype
implementation locally, building all the Fedora packages to generate
the opt-in set. Committing the necessary opt-ins, then committing the
necessary changes to the RPM macros.
* Other developers: There should be minimal work for other
developers. The most likely scenarios where other developers will
need to get involved would include:
# Packages which are excluded from x86_64 builds and which need the
opt-in will need the appropriate package owners to add the opt-in.
# Packages which are FTBFS when the builds are run to find the set of
packages that need to opt-in and which need to opt-in will need
packager attention.
# It is possible that the faster builds may trigger build failures in
packages that have missing dependencies in their Makefiles. We saw a
few of these during the initial LTO work and those packages were
either fixed or -j parallelism removed. This work may expose more of
these problems.
I expect these all to be relatively rare occurences, but with 9000+
packages in Fedora I wouldn't be surprised if we see a few of each of
these issues.
* Release engineering: [https://pagure.io/releng/issues #Releng issue
number] (a check of an impact with Release Engineering is needed) This
should have no release engineering impacts.
* Policies and guidelines: The packaging guidelines will need to be
updated to document the new macro.
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives: This proposal does not align with any
current Fedora Objectives.
== Upgrade/compatibility impact ==
This change should have zero impact on upgrade/compatibility. In
fact, the change should have no user visible impacts.
== How To Test ==
No special testing is needed. Any issues with this proposal will show
up as FTBFS issues.
== User Experience ==
Users should see no changes to the user experience.
== Dependencies ==
Packages which need to opt-in to -ffat-lto-objects will need their
.spec files updated to include the
new macro.
== Contingency Plan ==
If this can not be completed by final development freeze, then the RPM
macro changes would not be installed and the change could defer to
Fedora 35.
* Contingency mechanism: Proposal owner will only commit the RPM macro
changes once the opt-in package set has been identified and opt-ins
added to those package's spec files. So no special contingency
mechanism should be needed
* Contingency deadline: It is most beneficial to have this completed
before the mass rebuild; however, the drop dead date should be beta
freeze.
* Blocks release? No
* Blocks product? No
== Documentation ==
No upstream documentation. Packaging guidelines will need a minor update.
== Release Notes ==
I do not expect this change to require any release notes.
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
2 years, 9 months
Assimp soname bump
by Rich Mattes
Hi,
I plan to update assimp from 3.3.1 to the latest release (5.0.1) in
rawhide this week. The following packages will be affected:
fawkes-0:1.3.0-11.fc33.src
mrpt-0:1.4.0-17.fc33.src
pioneer-0:20200203-1.fc33.src
vkmark-0:2017.08-0.8.20180123git68b6f23.fc32.src
I will take care of the rebuilds and any fallout/updates that need to
happen.
Rich
2 years, 9 months
How to easily automate test builds in a COPR project
by Richard Shaw
I maintain a suite of ham radio related packages. The developer is very
active and often creates test versions adding and incrementing the "tweak"
part of the version which is removed for the full releases and the patch
level incremented.
Currently I'm just trying to keep up with them by hand using pagure forks
of the official repos so I don't accidentally pollute SCM with the changes
and build them in COPR.
Things I need to manage automagically:
1. Monitor the test URLs to look for new versions.
I could write a bash script for this and add a cron or systemd timer but I
was hoping for something that took less time as I don't have a lot of that
:)
Would it be permissible to create a <package>-testing entry in
release-monitoring.org?
2. Trigger a "fedpkg clone" and add a tweak version.
This could probably be managed with macros easy enough, %{?tweak}, or
something like that. And then use a script to substitute into "%global
tweak ..."
3. I need to download the files from a different location.
%if %{?tweak}
... use difference Source0?
4. Build the packages in COPR.
Easy enough using a bash script but is there a better way?
Thanks,
Richard
2 years, 10 months
The future of legacy BIOS support in Fedora.
by Jóhann B. Guðmundsson
Given Hans proposal [1] introduced systemd/grub2/Gnome upstream changes
it beg the question if now would not be the time to stop supporting
booting in legacy bios mode and move to uefi only supported boot which
has been available on any common intel based x86 platform since atleast
2005.
Now in 2017 Intel's technical marketing engineer Brian Richardson
revealed in a presentation that the company will require UEFI Class 3
and above as in it would remove legacy BIOS support from its client and
datacenter platforms by 2020 and one might expect AMD to follow Intel in
this regard.
So Intel platforms produced this year presumably will be unable to run
32-bit operating systems, unable to use related software (at least
natively), and unable to use older hardware, such as RAID HBAs (and
therefore older hard drives that are connected to those HBAs), network
cards, and even graphics cards that lack UEFI-compatible vBIOS (launched
before 2012 – 2013) etc.
This post is just to gather feed back why Fedora should still continue
to support legacy BIOS boot as opposed to stop supporting it and
potentially drop grub2 and use sd-boot instead.
Share your thoughts and comments on how such move might affect you so
feedback can be collected for the future on why such a change might be
bad, how it might affect the distribution and scope of such change can
be determined for potential system wide proposal.
Regards
Jóhann B.
1.
https://fedoraproject.org/wiki/Changes/CleanupGnomeHiddenBootMenuIntegration
2 years, 10 months
F35 Change: Node.js 16.x by default (System-Wide Change proposal)
by Ben Cotton
https://fedoraproject.org/wiki/Changes/Nodejs16
== Summary ==
The latest release of Node.js to carry a 30-month lifecycle is the
16.x series. As with 14.x, 12.x, 10.x and 8.x before it, Fedora 35
will carry 16.x as the default Node.js interpreter for the system. The
14.x and 12.x interpreters will remain available as non-default module
streams.
== Owner ==
* Name: [[User:zvetlik| Zuzana Svetlikova]]
* Email: zsvetlik(a)redhat.com
* Name: [[User:Sgallagh| Stephen Gallagher]]
* Email: sgallagh(a)fedoraproject.org
* Responsible SIG: Node.js SIG
== Detailed Description ==
Fedora 35 will ship with the latest LTS version of Node.js. '''dnf
install nodejs''' will give users nodejs-16.x and the matching npm
package.
== Benefit to Fedora ==
Node.js is a popular server-side JavaScript engine. Keeping Fedora on
the latest release allows us to continue tracking the state-of-the-art
in that space. For those whose applications do not yet work with the
16.x release, Fedora 35 will also have the 14.x and 12.x releases
available as selectable module streams.
== Scope ==
* Proposal owners: The packages are already built for Fedora 33, 34
and 35 in a non-default module stream. On June 14th, 2021, the
nodejs-16.x packages will be built in the non-modular repository and
thus become the default in Fedora 35.
* Other developers: Any developer with a package that depends on
Node.js at run-time or build-time should test with the 16.x module
stream enabled as soon as possible. Issues should be reported to
nodejs(a)lists.fedoraproject.org
* Release engineering: We will coordinate with the Node.js SIG to
create a side-tag to perform the rebuilds before making 16.x the
default.
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
As with previous releases, users running Fedora 33 or Fedora 34 with
the non-modular nodejs-14.x packages will be automatically upgraded to
the 16.x packages when they upgrade to Fedora 35, which may cause
issues. If users are running software known not to support Node.js
16.x yet, they can switch the system to use 14.x with '''dnf module'''
commands.
== How To Test ==
* Confirm that `dnf install nodejs` results in Node.js 16.x being installed.
* Confirm that upgrading from Fedora 33 or Fedora 34 with nodejs-14.x
installed (non-modular) results in an upgrade to nodejs-16.x
* Confirm that upgrading from Fedora 33 or Fedora 34 with the
`nodejs:14` module enabled does *not* result in an upgrade to 16.x and
still has `nodejs:14` enabled on Fedora 35.
* Confirm that upgrading from Fedora 33 or Fedora 34 with the
`nodejs:16` module enabled upgrades successfully and still has
`nodejs:16` enabled on Fedora 33.
== User Experience ==
Users will have the 16.x release of Node.js available by default. See
the "Upgrade/compatibility impact" section for specific details.
== Dependencies ==
All packages prefixed with `nodejs-` depend on this package. If they
do not work with Node.js 16.x, they will need to be updated, made
modular and dependent upon the `nodejs:14` stream or else removed from
Fedora 35.
Prior to the switchover date to Node.js 16.x as the default, packagers
are strongly encouraged to test their existing Node modules with 16.x
via the Modular version by running:
<pre>
dnf module reset nodejs
dnf module install nodejs:16/development
</pre>
Packagers can also test their builds using `mock` by creating the file
`/etc/mock/fedora-rawhide-x86_64-nodejs16.cfg` with the following
contents:
<pre>
config_opts['target_arch'] = 'x86_64'
config_opts['legal_host_arches'] = ('x86_64',)
config_opts['enable_disable_repos'] = ['--enablerepo', 'rawhide-modular']
config_opts['module_install'] = ['nodejs:16/development']
include('templates/fedora-rawhide.tpl')
</pre>
Then call
<pre>
mock -r fedora-rawhide-x86_64-nodejs16 --enablerepo=rawhide-modular nodejs-foo
</pre>
(Note that the `--enablerepo=rawhide-modular` portion looks redundant,
but this is because of
[https://github.com/rpm-software-management/mock/issues/591 a mock
bug])
== Contingency Plan ==
* Contingency mechanism:
Revert to Node.js 14.x as the default Node.js interpreter. This will
require bumping epoch.
* Contingency deadline: Beta Freeze
* Blocks release? No
* Blocks product? No
== Documentation ==
* https://nodejs.org/dist/latest-v16.x/docs/api/
* https://github.com/nodejs/node/blob/master/doc/changelogs/CHANGELOG_V16.md
== Release Notes ==
Fedora 35 now ships with Node.js 16.x as the default Node.js
JavaScript server-side engine. If your applications are not yet ready
for this newer version, you can revert to the 14.x series by running
the following commands
<pre>
dnf remove nodejs
dnf module reset nodejs
dnf module install nodejs:14
</pre>
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
2 years, 10 months
Bringing glibc 2.34 snapshots to Fedora 35 and CentOS Stream 9
by Florian Weimer
TL;DR: glibc 2.34 snapshots are coming. libpthread as a separate library
creates problems, so we are removing it. There may be some
hickups. Full updates with “dnf update” are recommended.
We expect that we will soon be able to import glibc upstream snapshots
regularly into Fedora 35 and CentOS Stream 9. We did such regular
imports for the past couple of Fedora rawhide releases, but the
situation will be slightly different, as explained below. The snapshots
will also land in CentOS Stream 9, after a delay as the result of a
different testing pipeline.
glibc 2.33 and earlier accidentally provided an very generic ROP gadget
in the statically linked startup code that is present in every program
(even dynamically linked ones). We have removed the ROP gadget and
moved that particular initialization code into the dynamically linked
part, but that means that the interface between the startup code and the
dynamically loaded glibc parts had to change. As a result, any program
linked against glibc 2.34 will not run with glibc 2.33 or any earlier
version. (Some of you may remember the memcpy(a)GLIBC_2.14 issue, it was
similar.) This version requirement will be properly reflected in RPM
dependencies.
glibc 2.34 removes libpthread as a separate library. This is based on
the observation that most processes load libpthread anyway. (On this
system, I count 141 out of 159 processes that load libpthread.) One
particularly thorny issue is that certain NSS modules depend on
libpthread, and if the main program is not linked (indirectly) against
libpthread, loading such NSS modules effectively loads libpthread via
dlopen, which is something that glibc has never supported well.
Furthermore, the availability of some pthread_* functions without
-lpthread has been a source of confusion to developers, resulting in
both overlinking and underlinking.
We started the libpthread transition in glibc 2.33 when we added the
__libc_single_threaded variable as a replacement for the weak symbol
hacks that some libraries use to detect single-threaded processes. (For
example, libstdc++ used to do this to avoid using atomic instructions in
std::shared_ptr.) Backwards compatibility for dynamically linked
binaries should be preserved (as usual), but we know of one issue on
ppc64le, where the weak symbol hacks resulted in slightly corrupt
binaries. Upstream glibc did not accept the proposed backwards
compatibility enhancement so far. Instead, we will rebuild affected
distribution binaries with a binutils version which handles weak symbols
slightly differently, avoiding the corruption. As we plan to perform
these rebuilds before the new glibc lands in the buildroot, the
requirement to upgrade to the new binaries before or at the same time of
the upgrade to the glibc upstream snapshot will NOT be reflected in RPM
dependencies. A full upgrade using “dnf update” will work, however.
In addition to the removal of libpthread, I also hope to remove libdl
and librt. This means that new GLIBC_2.34 symbols will be added to
libc.so.6 (e.g., timer_create(a)GLIBC_2.34). The librt removal in
particular will probably not land with the first imported snapshot.
This is unfortunate because RPM does not have a way to express this:
there's just a blanket Provides: libc.so.6(GLIBC_2.34), which will
already be included in the first snapshot that adds the symbol
__lib_start_main@(a)GLIBC_2.34 (whether or not the RPM package includes
timer_create(a)GLIBC_2.34 as well). Some tools in the fedpkg/centpkg/mock
sphere try to install builds from the Koji buildroot into installations
from composes, without upgrading everything to the current buildroot, so
it's possible that glibc won't be upgraded to match the requirements of
RPMs directly imported from the buildroot. Developers encountered
similar issues with glibc snapshot imports (e.g., around the symbol
pthread_getattr_np). Our RPM infrastructure does not have per-symbol
dependencies, so there isn't much we can do about it at the packaging
level. It's a transitory issue during rawhide/CentOS Stream 9
development; the finished release will add all GLIBC_2.34 symbols in one
upgrade, so end users won't see it in a Fedora 34 to Fedora 35 upgrade
or a CentOS Stream 8 to CentOS Stream 9 upgrade.
We think there is value in providing access to these snapshots early,
and will try to make the transitions as smooth as possible, within the
constraints outlined above.
Thanks,
Florian
2 years, 11 months
Let's retire original glib and gtk+
by Michael Catanzaro
Hi, I'd like to retire the original glib, GLib 1 from the GNOME 1 era.
This is would take out the gtk+ package (GTK 1) along with it. (I'm not
proposing to remove GTK 2.) GLib 1 has been obsolete for 19 years now,
since GLib 2 was released in March 2002. That's a real long time to
maintain a compatibility package, so I'm not sympathetic to anything
that still requires it.
GLib 2 has been API and ABI stable for 19 years now, so it's not moving
too fast for your package to depend on. :) The full list of packages
still depending on GLib 1 is below. If you own one of the below
packages, please consider upgrading to GLib 2. The only one that I
recognize is Sagemath.
$ sudo dnf repoquery --recursive --whatrequires glib
Last metadata expiration check: 0:28:04 ago on Fri 07 May 2021 09:06:03
AM CDT.
Singular-0:4.1.1p3-24.fc34.x86_64
Singular-doc-0:4.1.1p3-24.fc34.x86_64
Singular-emacs-0:4.1.1p3-24.fc34.x86_64
Singular-surfex-0:4.1.1p3-24.fc34.x86_64
bubblemon-0:1.46-29.fc34.x86_64
collectd-xmms-0:5.12.0-2.fc34.x86_64
gap-pkg-happrime-0:0.6-5.20190208.edfbd41.fc34.noarch
gap-pkg-happrime-doc-0:0.6-5.20190208.edfbd41.fc34.noarch
gap-pkg-singular-0:2020.12.18-2.fc34.noarch
gap-pkg-singular-doc-0:2020.12.18-2.fc34.noarch
glib-devel-1:1.2.10-62.fc34.i686
glib-devel-1:1.2.10-62.fc34.x86_64
golang-github-mattn-gtk-devel-0:0-0.7.20200729gitaf2e013.fc34.noarch
gtk+-1:1.2.10-96.fc34.i686
gtk+-1:1.2.10-96.fc34.x86_64
gtk+-devel-1:1.2.10-96.fc34.i686
gtk+-devel-1:1.2.10-96.fc34.x86_64
gxvattr-0:1.3-42.fc34.x86_64
librcc-devel-0:0.2.12-18.fc34.i686
librcc-devel-0:0.2.12-18.fc34.x86_64
librcc-gtk+-0:0.2.12-18.fc34.i686
librcc-gtk+-0:0.2.12-18.fc34.x86_64
logjam-xmms-1:4.6.2-25.fc34.x86_64
manedit-0:1.2.1-25.fc34.x86_64
qepcad-B-0:1.74-1.fc34.x86_64
sagemath-0:9.2-4.fc34.x86_64
sagemath-core-0:9.2-4.fc34.x86_64
sagemath-data-0:9.2-4.fc34.noarch
sagemath-data-combinatorial_designs-0:9.2-4.fc34.noarch
sagemath-data-conway_polynomials-0:9.2-4.fc34.noarch
sagemath-data-elliptic_curves-0:9.2-4.fc34.noarch
sagemath-data-elliptic_curves_large-0:9.2-4.fc34.noarch
sagemath-data-etc-0:9.2-4.fc34.noarch
sagemath-data-graphs-0:9.2-4.fc34.noarch
sagemath-data-polytopes_db-0:9.2-4.fc34.noarch
sagemath-jupyter-0:9.2-4.fc34.x86_64
sagemath-sagetex-0:9.2-4.fc34.x86_64
surf-geometry-0:1.0.6-29.fc34.x86_64
xarchon-0:0.50-35.fc34.x86_64
xconvers-0:0.8.3-27.fc34.x86_64
xdialog-0:2.3.1-28.fc34.x86_64
xmms-1:1.2.11-41.20071117cvs.fc34.x86_64
xmms-devel-1:1.2.11-41.20071117cvs.fc34.i686
xmms-devel-1:1.2.11-41.20071117cvs.fc34.x86_64
xmms-flac-0:1.3.3-7.fc34.x86_64
xmms-libs-1:1.2.11-41.20071117cvs.fc34.i686
xmms-libs-1:1.2.11-41.20071117cvs.fc34.x86_64
xmms-pulse-0:0.9.4-27.fc34.x86_64
Michael
2 years, 11 months