Fedora 34 Change: Ignore Anaconda kernel boot parameters without
'inst.' prefix (System-Wide change)
by Ben Cotton
https://fedoraproject.org/wiki/Changes/Ignore_Anaconda_kernel_boot_parame...
== Summary ==
Right now Anaconda allows usage of boot options both with the 'inst' prefix
(inst.stage2=) and without (stage2=). We would like to ignore the use of
Anaconda kernel boot parameters which do not contain the 'inst.' prefix.
== Owner ==
* Name: [[User:jkonecny| Jiří Konečný]]
* Email: <jkonecny(a)redhat.com>
== Detailed Description ==
Anaconda allows you to use kernel boot parameters with and without the
'inst.' prefix right now (e.g. inst.repo= / repo=). However, specifying
boot parameters without the 'inst' prefix has not been recommended for
years and has been deprecated since Fedora 33. We (Anaconda team) would
like to make it an official requirement now that users must specify the
'inst.' prefix all the time.
The reason for this is frequent parameter conflicts with other projects. We
already had a few issues with conflicts in the past, such as if the user
ran an installation with `debug`. In that case the installation boot would
enable debug mode for the kernel and also for Anaconda which is probably
not what the user intended.
Another reason is to make it readable at first glance what belongs to
Dracut (rd.), kernel (no prefix) or Anaconda (inst.).
== Feedback ==
We have sent mail about doing the deprecation on Fedora 33. The only issue
there was why the prefix is 'inst.' and not 'anaconda.'.
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.o...
== Benefit to Fedora ==
This change should make crystal clear what kernel boot parameters are
processed by the Anaconda installer.
It will also avoid conflicts with other kernel boot parameters.
== Scope ==
* Proposal owners: Remove support to process arguments without the 'inst.'
prefix and require the 'inst.' prefix for kernel boot parameters consumed
by Anaconda.
* Other developers:
All configurations using the not-recommended solution without prefix will
have to change the invocation of the kernel boot options consumed by
Anaconda. These users are already warned since Fedora 33 after boot.
This should not be a problem for ISOs we ship because they already use the
recommended 'inst.' prefix everywhere. However, it will probably touch some
custom PXE configurations and other custom ISO configurations which are
prone to this, because users often want to save typing and not explicitly
write the 'inst.' prefix. Fortunately, most of these configuration changes
shouldn't be that hard to change.
* Release engineering: [https://pagure.io/releng/issue/9889 #9889]
* Policies and guidelines: This should not be required. All the
documentation should use the recommended 'inst.' prefix already.
* Trademark approval: No (not needed for this Change)
* Alignment with Objectives: No
== Upgrade/compatibility impact ==
If your custom infra configuration is not updated then new Fedora
installations could not install correctly. Most probably the ISO will not
boot (use of 'stage2=') or your repositories won't be used (use of 'repo=').
== How To Test ==
# You need a Virtual Machine and ISO for testing.
# Boot the installation using the ISO and try Anaconda specific kernel boot
parameters. See here to find out the list
https://anaconda-installer.readthedocs.io/en/latest/boot-options.html.
# Parameters without the prefix should be ignored and with the prefix
should be used.
== User Experience ==
Users of Fedora official ISOs should not be impacted because all the Fedora
official ISOs should already use the recommended prefix.
== Dependencies ==
Don't know about any packages impacted by this change.
== Contingency Plan ==
* Contingency mechanism: The Anaconda team will revert code changes and get
back support for boot parameters without the 'inst.' prefix.
* Contingency deadline: Final Freeze
* Blocks release? No
* Blocks product? This won't require changes for any specific product.
== Documentation ==
I don't think we need to document this change other than in Release Notes.
As mentioned before, the solution without 'inst.' prefix has not been
recommended for years and it should not be used anywhere in the official
documentation.
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
3 years, 2 months
What is the most time consuming task for you as packager?
by Miroslav Suchý
I am looking for challenges for upcoming year - what I and my team should enhance. I have some ideas, but I want to hear
yours.
What you - as Fedora packager - find most time consuming on packaging?
Where you will welcome more simplicity or automation?
--
Miroslav Suchy, RHCA
Red Hat, Associate Manager ABRT/Copr, #brno, #fedora-buildsys
3 years, 2 months
Chromium built in rawhide does not render most strings
by Tom Callaway
Okay, this one has me stumped. Any chromium package I build through rawhide
refuses to render most of the strings.
At first, I thought this was gcc 11, but then I noticed that the first
build with this problem was built before GCC 11 landed in rawhide (the
compiler was the same n-v-r as the one in Fedora 33). Next, I thought it
must be due to a newer system component that Chromium uses dynamically, but
I was able to disprove that by installing the Fedora 33 build (same
version-release) into a Rawhide VM, and it works fine. Google Chrome also
works fine in rawhide.
It seems that this must be something that is contained within chromium,
that when built in rawhide, builds broken.
Here's a screenshot of what it looks like:
https://twitter.com/spotfoss/status/1338918235719299072/photo/1
Note that some text strings are rendering (in the UI, in the "search box"),
but most of them are not (the "HTML5Test" text below the icon, all of the
strings in the developer console).
Chromium has a lot of bundled components, so it is usually fairly resistant
to system changes. There are no differences between how Chromium builds
(within the RPM spec) on Fedora 33 and Rawhide. It also doesn't use
%{optflags}, so the compiler flags are equivalent.
Could this be due to some quirk of binutils in the way chromium gets linked
in rawhide? Is there something else unique to how packages are built in
rawhide right now? Are any other rawhide packages having similar string
issues?
Here are some builds for comparison:
Fedora 34: Chromium 87.0.4280.88 (built against GCC 11):
https://koji.fedoraproject.org/koji/taskinfo?taskID=57595738
Fedora 34: Chromium 87.0.4280.88 (built against GCC 10, same as Fedora 33):
https://koji.fedoraproject.org/koji/buildinfo?buildID=1655036
Fedora 33: Chromium 87.0.4280.88 (build against GCC 10, but actually works
in rawhide):
https://koji.fedoraproject.org/koji/buildinfo?buildID=1655036
Fedora 34: Chromium 88.0.4324.27 (beta version of chromium, also broken)
https://koji.fedoraproject.org/koji/taskinfo?taskID=56977476
Thanks in advance,
~spot
3 years, 2 months
List of long term FTBFS packages to be retired in February
by Miro Hrončok
Dear maintainers.
Based on the current fail to build from source policy, the following packages
will be retired from Fedora 34 approximately one week before branching (February
2021).
Policy:
https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fai...
Note that some listed packages are orphaned and hence may be retired even sooner.
The packages in rawhide were not successfully built at least since Fedora 32.
This report is based on dist tags.
Packages collected via:
https://github.com/hroncok/fedora-report-ftbfs-retirements/blob/master/ft...
If you see a package that was built, please let me know.
If you see a package that should be exempted from the process, please let me
know and we can work together to get a FESCo approval for that.
If you see a package that can be rebuilt, please do so.
Package (co)maintainers Latest build
===============================================================================
VirtualGL gsgatlin Fedora 31
boo elsupergomez, orphan, tpokorra Fedora 31
gmpc orphan Fedora 31
jboss-servlet-2.5-api dmoluguw, orphan Fedora 31
js-html5shiv orphan Fedora 31
js-respond orphan Fedora 31
nodejs-info-symbol orphan Fedora 31
nodejs-interpret nodejs-sig, orphan Fedora 31
nodejs-net-browserify-alt orphan Fedora 31
nodejs-win-spawn nodejs-sig, orphan Fedora 31
rubygem-net-ssh-multi maxamillion, orphan, tdawson Fedora 31
sugar-flipsticks callkalpa, chimosky, pbrobinson, Fedora 31
tuxbrewr
sugar-getiabooks callkalpa, chimosky, pbrobinson, Fedora 31
tuxbrewr
sugar-infoslicer callkalpa, chimosky, pbrobinson, Fedora 31
tuxbrewr
sugar-labyrinth callkalpa, chimosky, pbrobinson Fedora 31
sugar-ruler callkalpa, chimosky Fedora 31
sugar-starchart callkalpa, chimosky, orphan Fedora 31
sugar-view-slides callkalpa, chimosky, pbrobinson, Fedora 31
tuxbrewr
sugar-visualmatch chimosky, orphan Fedora 31
sugar-yupana callkalpa, chimosky, orphan Fedora 31
The following packages require above mentioned packages:
Depending on: js-html5shiv (1)
copr-frontend (maintained by: clime, copr-sig, dturecek, frostyx, msuchy, praiskup)
copr-frontend-1.171-1.fc34.noarch requires js-html5shiv
Depending on: nodejs-info-symbol (2)
nodejs-log-utils (maintained by: orphan)
nodejs-log-utils-0.2.1-6.fc32.noarch requires npm(info-symbol)
nodejs-time-diff (maintained by: orphan)
nodejs-time-diff-0.3.1-7.fc32.src requires npm(info-symbol)
Depending on: nodejs-interpret (1)
nodejs-shelljs (maintained by: fab, nodejs-sig, patches)
nodejs-shelljs-0.8.4-2.fc33.noarch requires npm(interpret)
Affected (co)maintainers (directly and indirectly):
callkalpa: sugar-labyrinth, sugar-yupana, sugar-ruler, sugar-flipsticks,
sugar-view-slides, sugar-infoslicer, sugar-starchart, sugar-getiabooks
chimosky: sugar-labyrinth, sugar-yupana, sugar-ruler, sugar-flipsticks,
sugar-view-slides, sugar-visualmatch, sugar-infoslicer, sugar-starchart,
sugar-getiabooks
clime: js-html5shiv
copr-sig: js-html5shiv
dmoluguw: jboss-servlet-2.5-api
dturecek: js-html5shiv
elsupergomez: boo
fab: nodejs-interpret
frostyx: js-html5shiv
gsgatlin: VirtualGL
maxamillion: rubygem-net-ssh-multi
msuchy: js-html5shiv
nodejs-sig: nodejs-win-spawn, nodejs-interpret
patches: nodejs-interpret
pbrobinson: sugar-labyrinth, sugar-flipsticks, sugar-view-slides,
sugar-infoslicer, sugar-getiabooks
praiskup: js-html5shiv
tdawson: rubygem-net-ssh-multi
tpokorra: boo
tuxbrewr: sugar-view-slides, sugar-infoslicer, sugar-getiabooks, sugar-flipsticks
3 years, 2 months
Server Side Public License (SSPL) v1
by Tom Callaway
After review, Fedora has determined that the Server Side Public License
v1 (SSPL) is not a Free Software License.
It is the belief of Fedora that the SSPL is intentionally crafted to be
aggressively discriminatory towards a specific class of users.
Additionally, it seems clear that the intent of the license author is to
cause Fear, Uncertainty, and Doubt towards commercial users of software
under that license. To consider the SSPL to be "Free" or "Open Source"
causes that shadow to be cast across all other licenses in the FOSS
ecosystem, even though none of them carry that risk.
It is also worth nothing that while there is a draft for a "v2" of the SSPL:
A) It is not final.
B) It is not in use anywhere at this time (as far as we know).
C) The intent of the v2 draft text is not changed from the v1 license
currently in use.
We have updated our "Bad License" list to include SSPLv1. No software
under that license may be included in Fedora (including EPEL and COPRs).
Thanks,
Tom Callaway
Fedora Legal
3 years, 2 months
Fedora 34 Change: Enable spec file preprocessing (System-Wide Change proposal)
by Ben Cotton
https://fedoraproject.org/wiki/Changes/Enable_Spec_File_Preprocessing
== Summary ==
This change should enable an opt-in spec file preprocessor in Fedora
infrastructure for the benefit of packagers. The preprocessor allows
some very neat tricks that were impossible before, for example
generate changelog and release automatically from git metadata or pack
the entire dist-git repository into an rpm-source tarball (effectively
allowing unpacked repos to live in DistGit).
== Owner ==
* Name: [[User:clime| Michal Novotný]]
* Email: clime(a)fedoraproject.org
== Detailed Description ==
There is a recently added feature into mock:
[https://github.com/rpm-software-management/mock/wiki/Plugin-rpkg-preproce...
the rpkg preprocessor] which, if enabled, introduces an intermediate
step just before srpm building. This step consists of running the spec
file through a text preprocessing engine that includes an already
present library of macros designed specifically for rpm spec file
generation from git metadata. This library is called
[https://docs.pagure.org/rpkg-util/v3/macro_reference.html
rpkg-macros]. The macros there allow packagers to have their
`%changelog`, `Release`, `Version`, `VCS` tag, or even `Source` fields
automatically generated from dist-git repository data and metadata.
The library can be easily extended in future to support more packager
use-cases or even a completely new library can be developed that
doesn't look at git metadata at all and instead, for example, analyses
already present tarball content to render spec file based on upstream
information. This doesn't mean it will happen but the framework is
generic enough to support that. There is also support for user-defined
macros that are loaded on-demand from a file placed alongside the
package sources, maintained by packager. This feature wouldn't be
enabled by this change from start but it's an example of freedom that
the preprocessing framework is able to provide. Enabling this change
should be very easy, basically adding:
<pre>
config_opts['plugin_conf']['rpkg_preprocessor_enable'] = True
</pre>
into mock configuration of Koji builders and using at least mock 2.7.
Some very minor change may be also needed in Koji regarding the spec
file lookup.
Even if the change is enabled on the infrastructure level like this,
the packager will still need to opt-in to use the preprocessor. The
opting-in is done by placing `rpkg.conf` file into the package
top-level directory with the following content:
<pre>
[rpkg]
preprocess_spec = True
</pre>
When this is done by a packager, the preprocessor will be finally
enabled for the given package.
Alongside, there is an ongoing work to add the preprocessor support
into the `rpkg` python library so that a packager can easily work with
the spec files containing the preprocessor (rpkg) macros:
https://pagure.io/rpkg/pull-request/530
The macros are supported since epel6 until the most latest Fedora
(preproc, rpkg-macros, and rpm-git-tag-sort packages are needed). The
spec preprocessing step in mock happens in a target chroot just before
the srpm build.
== Benefit to Fedora ==
This change offers solution to some long-standing issues in Fedora
around packaging (i.e. automatic release and changelog generation)
while also offering some interesting future options (for example
unpacked dist-git repos). The big advantage of this approach is that
it is explicit. Spec file stays the source of truth and by looking
inside one, you will be able to determine how the text will expand for
a certain git repository state.
== Scope ==
* Proposal owners:
For the very basic support, probably a small patch in Koji is needed
to be able to lookup not only `.spec` files but also `.spec.rpkg`
files (the `.spec.rpkg` extension explicitly states that the spec file
is a template). Also the `rpmdevtools/rpmdev-bumpspec` script should
be tweaked to be compatible with spec files using the macros.
* Other developers:
Some optional help with `rpmdevtools/rpmdev-bumpspec` changes would be welcome.
* Release engineering: [https://pagure.io/releng/issue/9910 #9910] (a
check of an impact with Release Engineering is needed)
Enabling the rpkg_preprocessor plugin in mock config for Koji builders.
* Policies and guidelines:
The new macro support should be mentioned or even described in the
packaging guidelines. We should decide if the full power of the
rpkg-macros library should be allowed from start (i.e. even unpacked
repos).
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives: N/A
== Upgrade/compatibility impact ==
Because of the opt-in nature on packager side, there should be no
compatibility issues.
== How To Test ==
Once the feature is enabled, one can test it by providing the
`rpkg.conf` file with the required content in a package repository and
use some rpkg macro in the spec file: e.g.
<pre>
Name: {{{ git_dir_name }}}
</pre>
to generate the name of the package from the repository name (this
should actually produce the original text as package names should be
the same as the repository basenames).
To try it out first without committing to dist-git, one can use `rpkg`
command-line tool from
https://copr.fedorainfracloud.org/coprs/clime/rpkg-util/ or even
fedpkg's koji scratch build after
[https://pagure.io/rpkg/pull-request/530 the work in the pyrpkg]
library is finished.
One can also currently use Copr's SCM "rpkg" build method where the
macros are enabled but the rpkg-macros there are in version 2 whereas
this change is about introducing the
[https://docs.pagure.org/rpkg-util/v3/macro_reference.html version 3
rpkg-macros]. However, while there are some differences between v2 and
v3, the idea and most of the working is the same.
== User Experience ==
This change is intended for packagers. It should help to make a bit of
their work easier and offer them some new interesting options.
== Dependencies ==
N/A
== Contingency Plan ==
Packagers can opt-out on individual basis by removing the `rpkg.conf`
file or just setting the `preproces_spec` property to `False`. On
infrastructure level, the rpkg_preprocessor plugin could be disabled
again.
== Documentation ==
- [https://github.com/rpm-software-management/mock/wiki/Plugin-rpkg-preproce...
Mock's rpkg_preprocessor plugin]
- [https://docs.pagure.org/rpkg-util/v3/macro_reference.html
rpkg-macros reference (the library of macros ready to be used in spec
files)]
== Release Notes ==
Currently N/A
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
3 years, 2 months
Fedora 34 Change: Unify the GRUB configuration files location across
all supported architectures (System-Wide Change proposal)
by Ben Cotton
https://fedoraproject.org/wiki/Changes/UnifyGrubConfig
== Summary ==
This change makes the GRUB configuration files layout to be consistent
across all the supported architectures. Currently EFI is a special
case since the GRUB configuration file and environment variables block
are stored in the EFI System Partition (ESP) instead of the boot
partition (or `/boot` directory if no boot partition is used).
== Owner ==
* Name: [[User:Javierm|Javier Martinez Canillas]]
* Email: javierm(a)redhat.com
* Name: [[User:Gicmo|Christian Kellner]]
* Email: ckellner(a)redhat.com
== Detailed Description ==
The GRUB configuration files layout on EFI platforms is not consistent
with the other non-EFI platforms (e.g: x86 with legacy BIOS, ppc64le
with Open Firmware). On platforms using EFI the GRUB configuration
file (`grub.cfg`) and environment variables block (`grubenv`) are
stored in the EFI System Partition (ESP) while for non-EFI platforms
these are stored in the boot partition (or `/boot` directory if not
boot partition is used).
The reason for this is that the path where the GRUB bootloader
searches for its configuration file varies depending on the firmware
interface used. In most cases, GRUB searches for it in the path set in
the `$prefix` variable. The device is not specified in that case, GRUB
just searches for a configuration in this path for every detected
device. But on EFI, a special `$fw_path` variable is used instead.
This variable specifies both the device and path from where the GRUB
bootloader was loaded and these are used to search for the
configuration file. This is done for security reasons, to make sure
that the correct GRUB configuration file is used and not just the
first one found in one of the detected devices.
Since the GRUB binary is located in the ESP, it expects to find the
configuration file in that location as well. But this creates the
mentioned inconsistency, because the GRUB configuration file has to be
stored in `/boot/efi/EFI/fedora/grub.cfg` while for non-EFI platforms
it has to be stored in `/boot/grub2/grub.cfg`.
This leads to a GRUB configuration layout that is confusing for users
and error prone, since either the tools that are used to manage these
files have to be aware of the differences or symbolic links used to
hide the fact that the pats differ depending on the platform. Also, it
creates artificial constraints on the OS installation due the
differences in the configuration layout used. A system installed when
using EFI won't be bootable if the firmware configuration is changed
to boot using legacy BIOS instead, for example enabling the EFI
Compatibility Support Module or moving the disk to a BIOS machine.
The proposal is to always store the `grub.cfg` and `grubenv` files in
the `/boot/grub2/` directory, making `/boot/efi/EFI/fedora/grub.cfg`
to only be a small configuration file that sets a different `$prefix`
variable and loads the configuration file stored in
`/boot/grub2/grub.cfg`.
The `$prefix` variable will be set to the device partition where
`/boot/grub2/grub.cfg` is stored, using the partition filesystem's
Universally Unique IDentifier (UUID). That way the correct GRUB
configuration file will be loaded, making it as secure as the current
approach where the configuration file in the ESP is used.
A drawback of the new approach is that the GRUB configuration will now
depend on the boot partition (or `/boot` directory if no boot
partition is used). But since the kernel and initramfs images are
stored there too, the bootloader configuration already has this
dependency anyways.
Note that the proposed configuration files layout is already used by
the Fedora CoreOS Assembler (COSA) and OSBuild image builders. So this
will make the systems installed with Anaconda to be consistent with
the images generated by these.
== Benefit to Fedora ==
This change will not only simplify and make less confusing the GRUB
configuration but also allow the following improvements:
* To have a consistent configuration across all the architectures using GRUB.
* Allow the same installation to be booted with either EFI or legacy BIOS.
* Use the same documentation and commands for all architectures
instead of having EFI as a special case.
* Make GRUB configuration tools more robust by not relying on symbolic
links to be created and not having to handle platform specific cases.
* Align with images generated by COSA and OSBuild on how the GRUB
configuration files are used.
* Align with other Linux distributions on how the GRUB configuration
files are used.
== Scope ==
* Proposal owners:
** Modify Anaconda to generate the `grub.cfg` and `grubenv` files in
`/boot/grub2/` instead of `/boot/efi/EFI/fedora/` for EFI platforms.
** Make Anaconda to generate the minimal GRUB config file in the ESP
that sets the `$prefix` variable and loads the configuration file
located in `/boot/grub2/grub.cfg`.
** Modify the grub2 package scriptlets to not generate the
`/boot/grub2/grubenv` and `/etc/grub2-efi.cfg` symbolic links since
these will not be needed anymore.
** Make any changes needed in tools that use these configuration files
(`grubby`, `kernel-install` scripts, etc).
* Other developers:
** The Anaconda developers will need to review and merge the patches
to change where the GRUB configuration files are created.
** Test and watch for regressions.
* Release engineering:
** [[Fedora_Program_Management/ReleaseBlocking/Fedora{{FedoraVersionNumber|next}}|List
of deliverables]]: N/A
* Policies and guidelines: The policies and guidelines do not need to
be updated.
* Trademark approval: No changes needed.
== Upgrade/compatibility impact ==
The changes will only be for new installations, existing systems will
not be impacted and will continue using the grub.cfg and grubenv files
that are located in the ESP.
== How To Test ==
* Install Fedora 34 and verify that the GRUB configuration is correct.
* Check that the `/boot/efi/EFI/fedora/grub{.cfg,env}` files are not present.
* Check that the `/boot/grub2/grub{.cfg,env}` files are present.
* Enter the GRUB prompt by pressing 'c' from the GRUB boot menu and
execute the following command:
<pre>echo $prefix</pre>
and verify that the prefix is set to the partition that contains the
`/boot/grub2` directory.
* Re-generate the GRUB configuration file with:
<pre>grub2-mkconfig -o /boot/grub2/grub.cfg</pre>
and verify that the GRUB configuration is still correct.
== User Experience ==
No visible changes are expected other than the configuration files
being present in a different path. This should improve the overall
user experience.
== Dependencies ==
None
== Contingency Plan ==
* Contingency mechanism: Revert the Anaconda and grub2 package
scriptlets changes.
* Contingency deadline: Beta Freeze
* Blocks release? No
* Blocks product? None
== Documentation ==
* Fedora CoreOS assembler script that creates the GRUB config file for
EFI: https://github.com/coreos/coreos-assembler/blob/master/src/create_disk.sh
* OSBuild org.osbuild.grub2 stage that creates the GRUB config file
for EFI: https://github.com/osbuild/osbuild/blob/main/stages/org.osbuild.grub2
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
3 years, 3 months