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, 9 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, 9 months
Offering strongswan for (co)maintaining
by Petr Menšík
Hello,
strongswan and NetworkManager-strongswan packages were passed to me from
previous maintainer. I admit I have little experience with them and do
not run any service based on them. Because IPSsec is quite complex
technology, I am looking for help with its maintenance. I was always
using OpenVPN based solutions myself, so I guess I am not the best
person as main admin. I would like to transfer main admin to anyone
doing a good job, not not immediately. That is why I haven't orphaned it
already.
I would like to keep commit access for a while, but I would share at
least commit access with anyone willing to improve those packages.
Especially someone using they (almost) everyday would be ideal maintainer.
Regards,
Petr
--
Petr Menšík
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
2 years, 10 months
Heads Up: openexr 3.0 coming to Rawhide
by Richard Shaw
I'm currently in the process of testing all deps in my COPR. Assuming no
major issues are found I'll setup a side tag to perform all the builds. I
expect to be done by this coming weekend.
Affected packages are:
alembic
aqsis
bcd
blender
calligra
CTL
darktable
Field3D
freeimage
gegl04
gimp
gmic
gstreamer1-plugins-bad-free
hugin
ImageMagick
kdebase3
kdelibs
kde-runtime
kf5-kimageformats
kio-extras
krita
luminance-hdr
luxcorerender
opencv
OpenImageIO
OpenSceneGraph
openshadinglanguage
openvdb
pfstools
povray
prusa-slicer
synfig
synfigstudio
vigra
vips
YafaRay
Thanks,
Richard
2 years, 10 months
F35 Change: Debuginfod By Default (Self-Contained Change proposal)
by Ben Cotton
https://fedoraproject.org/wiki/Changes/DebuginfodByDefault
== Summary ==
Fedora users / developers who need to debug/trace distro binaries can
make use of the recently activated elfutils-debuginfod servers to
automatically fetch debugging data and source code, instead of having
to use `# sudo dnf` commands.
== Owner ==
* Name: [[User:fche| Frank Ch. Eigler]]
* Email: fche(a)redhat.com
== Detailed Description ==
Numerous fedora debugging-type tools have built-in capabilities to use
the [https://sourceware.org/elfutils/Debuginfod.html debuginfod]
protocol to fetch debuginfo/source code automatically. We would like
to activate a setting so that Fedora's debuginfod servers are
automatically used, rather than requiring hand-editing individual
users' dot files.
== Feedback ==
There has existed
[https://www.spinics.net/lists/fedora-devel/msg279002.html broad
interest] in a Fedora debuginfod server since the project was proposed
/ announced in 2020, and several distros already operate public
servers of this nature. Some of the distros configure their
installations by default to talk to those servers, some do not.
Turning on this by default has some limited privacy implications.
Some Debian users have
[https://lists.debian.org/debian-devel/2021/02/msg00262.html expressed
concerns] that this facility "calls home" during debugging, so it may
expose a limited amount of information about what a user is debugging.
The information is limited to the build-id and source code file names
of programs being debugged, and is only sent to the servers if their
machine lacks locally installed debuginfo. Whether this should be
opt-in or opt-out and how has been resolved there via an install-time
query to the sysadmin. In contrast, on OpenSUSE Tumbleweed, it is
[https://build.opensuse.org/request/show/879926 simply defaulted-on],
and we have heard of no controversy.
We anticipate discussing this topic on the mailing list, and noting it
in the release notes either way.
== Benefit to Fedora ==
This will improve developers' experience.
It may reduce download server burden, as only individual
ELF/DWARF/source files are downloaded rather than entire `-debuginfo`
and `-debugsource` RPMs.
It would help Fedora catch up to other distros who put up `debuginfod`
servers already. :-)
== Scope ==
* Proposal owners:
The work could consist one extra parameter in the `elfutils.spec`
`%configure`. Its effect is to arrange for the
`elfutils-debuginfod-client` RPM
to install an `/etc/profile.d` file that sets the `DEBUGINFOD_URLS`
environment variable automatically to
`https://debuginfod.fedoraproject.org/`. (At the time of this
writing, the _staging_ server is getting ready for testing:
`https://debuginfod.stg.fedoraproject.org/`.)
* Other developers: None - relevant code has been previously upstreamed!
* Release engineering: None - our team is operating the
`debuginfod[.stg].fedoraproject.org` VMs.
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives: N/A
== Upgrade/compatibility impact ==
None.
Note that these servers index all active Fedora releases (32-), all
architectures, so users of those versions can already set
`DEBUGINFOD_URLS` manually to take advantage.
== How To Test ==
* Install `elfutils-debuginfod-client`
* Open arbitrary fedora binary via gdb.
** Admire the immediate downloading of debuginfo and source code.
* Run `eu-stack -v -p $pid` for an arbitrary process.
** Admire the immediate downloading of debuginfo to give precise file:line data.
== User Experience ==
Primarily: users running debuggers, profilers, tracing tools on
internet-capable machines can work immediately, without switching to
privileged users and fragile manual `dnf` commands to install this
data.
== Dependencies ==
The `debuginfod` servers at `fedora-infra` need to be up.
== Contingency Plan ==
* Contingency mechanism: change the elfutils-debuginfod-client subrpm
to not set the default `DEBUGINFOD_URLS` environment variable for all
users. In the case of a server outage, the debugger tools revert to
debuginfo-less operation, prior to this feature.
* Contingency deadline: shortly before freeze
* Blocks release? No
== Documentation ==
There is upstream documentation in the debugging tools as well as
associated with the client code / cli tooling. What our Release Notes
would focus on however is the _automatic activation_ of this facility
via the environment variable.
== Release Notes ==
TBD.
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
2 years, 10 months
F35 Change proposal: Smaller Container Base Image (remove
sssd-client, util-linux, shadow-utils) (Self-Contained Change)
by Ben Cotton
https://fedoraproject.org/wiki/Changes/SmallerContainerBase
== Summary ==
This change proposes to remove 3 packages (sssd-client, util-linux,
shadow-utils) from the Container Base Image (including the minimal
image). The Fedora Base Image is still quite large compared to other
distributions and the tools offered by these packages are not
essential in base image.
== Owner ==
* Name: [[User:cverna| Clément Verna]]
* Email: <cverna-at-fedoraproject.org>
== Detailed Description ==
This is a proposal to make the Fedora Container Base image smaller by
remove the following 3 packages:
* sssd-client
* util-linux
* shadow-utils
Current size of the base image and minimal base image :
{| class="wikitable"
|-
! REPOSITORY !! TAG !! IMAGE ID !! CREATED !! SIZE
|-
| registry.fedoraproject.org/fedora || 34 || eede0db319cc || 2 days
ago || 187 MB
|-
| registry.fedoraproject.org/fedora-minimal || 34 || 4ff120184ee4 ||
2 days ago || 122 MB
|}
The installed size of each package is :
{| class="wikitable"
|-
! Package !! Installed Size
|-
| util-linux || 13018140
|-
| shadow-utils || 3876259
|-
| sssd-client || 317948
|}
Removing these packages would allow to gain around 17MB in both images.
Each of these packages provides useful tools but the main goal of the
base image is for building layered images. Each of these packages can
easily be added in a layered image if needed.
More info and discussion happened for each package in the Container SIG tracker
sssd-client : https://pagure.io/ContainerSIG/container-sig/issue/44
util-linux : https://pagure.io/ContainerSIG/container-sig/issue/45
shadow-utils : https://pagure.io/ContainerSIG/container-sig/issue/46
== Benefit to Fedora ==
Reducing the size of the base image makes it a more interesting choice
for users to build layered images using Fedora. The base image is also
heavily used by CI systems so reducing the size makes it faster to be
pulled.
Removing packages from the base image also reduces the number of CVEs
our users have to care about.
== Scope ==
* Proposal owners:
Explicitly remove the 3 packages from the base image kickstart :
https://pagure.io/fedora-kickstarts/blob/main/f/fedora-container-base.ks
* Release engineering:
Approve and Merge the kickstart change.
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives: N/A
== Upgrade/compatibility impact ==
Some layered images that relied on these packages being provided by
the base image will fail to build. These images will now have to make
sure to install the required package in their Container/Dockerfile.
In most cases that will results in adding the following :
RUN dnf -y install sssd-client shadow-utils util-linux && dnf clean all
== How To Test ==
Once implemented, one can test this change by pulling the rawhide
image and verify that none of the above packages are present in the
image.
== User Experience ==
See Upgrade/compatibility impact
== Dependencies ==
== Contingency Plan ==
Kickstart changes can simply be reverted and packages added back in
the base image.
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
2 years, 11 months
RPM name collisions
by przemek klosowski
Few weeks ago we had an announcement of a Python supply chain hack where
people supplied libraries with names matching some private library
names, which took precedence and overrode those private libraries,
giving the hackers control.
Now, the name collisions are built-in into RPM, because that's how
updates work: the original package is in 'fedora' and the updates are
in, well, 'updates'. This is fine as long as we control all
repositories, but the recent trend is to loosen up and increase the
repository set: rpmfusion, ROCm, packages-microsoft-com-prod are likely
to be used because they contain useful software. I am all for including
them, but since we have no control over them, necessarily, maybe we
should rethink the consequences for the end users.
Specifically, for example, Microsoft likes to keep multiple versions
online: for instance aadlogin has nearly 30 versions from
1.0.00485001-1 to 1.0.015280001-1. As long as this is their exclusive
package, this is fine---but sometimes it gets more complicated than
that. For instance, there's aspnetcore-runtime, which is in Fedora, but
also has nearly 70 versions in MS repo (they cover aspnetcore-runtime
versions from 2.1 to 5.0; just the 3.1 variants amount just to 18 or so
packages, that intersect with Fedora ones:
...
aspnetcore-runtime-3.1.x86_64 3.1.12-1 packages-microsoft-com-prod
aspnetcore-runtime-3.1.x86_64 3.1.13-1 packages-microsoft-com-prod
aspnetcore-runtime-3.1.x86_64 3.1.13-2.fc34 fedora
aspnetcore-runtime-3.1.x86_64 3.1.14-1 packages-microsoft-com-prod
aspnetcore-runtime-3.1.x86_64 3.1.14-1.fc34 updates
...
These packages are actually coming from Microsoft, and the versioning
seems consistent, so I guess there's nothing wrong with this setup
besides a possibility for confusion as to which one is actually
installed. But sometimes the versions are much more divergent:
netstandard-targeting-pack-2.1.x86_64 2.1.0-1 packages-microsoft-com-prod
netstandard-targeting-pack-2.1.x86_64 5.0.104-1.fc34 fedora
netstandard-targeting-pack-2.1.x86_64 5.0.202-1.fc34 updates
and here's a really weird one:
hello.x86_64 2.8-1 packages-microsoft-com-prod
hello.x86_64 2.10-5.fc34 fedora
Why would they put it in their repo? I don't expect any harm here, but
just looking at this this made me think of the Python debacle I
mentioned earlier.
Is that something we need to worry about? I couldn't think of any new
rules to impose on repositories, but maybe dnf should have more explicit
warnings when it sees multiple versions of the same package, or at least
a way to show such versions.
As it is now, I think it just handles the most current version, but this
is fragile across separately managed repositories, and doesn't easily
show all the available versions---in order to collect the data I wrote a
script that iterates over 'yum repolist' and disables */enables one repo
at a time.
For completness, here are the remaining strange cases:
openhantek.x86_64 2.06-1.fc31 rpmfusion-nonfree
openhantek.x86_64 3.2-1.fc34 fedora
procdump.x86_64 1.1-207 packages-microsoft-com-prod
procdump.x86_64 1.1.1-3.fc34 fedora
procdump.x86_64 1.1.1-218 packages-microsoft-com-prod
procdump.x86_64 1.1.1-220 packages-microsoft-com-prod
2 years, 11 months
