Fedora 34 Change: BIND 9.16 (Self-Contained Change)
by Ben Cotton
https://fedoraproject.org/wiki/Changes/BIND9.16
== Summary ==
BIND 9 would be updated to upcoming stable version BIND 9.16.
== Owner ==
* Name: [[User:pemensik| Petr Menšík]]
* Email: pemensik at redhat.com, dns-sig at fedoraproject dot org
== Detailed Description ==
ISC BIND 9 stayed longer time on 9.11 Extended Support Version,
because dhcp and freeipa depended on it. DHCP package no longer
requires bind-export-libs, which new BIND 9.16 does not support.
FreeIPA part bind-dyndb-ldap were also modified to support new
version.
BIND 9.16 includes more easy way to provide DNSSEC
([https://gitlab.isc.org/isc-projects/bind9/-/wikis/DNSSEC-Key-and-Signing-...
KASP]).
== Benefit to Fedora ==
Stable version under most the active development is packaged again.
Introduces [https://gitlab.isc.org/isc-projects/bind9/-/wikis/DNSSEC-Key-and-Signing-...
DNSSEC Key and Signing Policy] without external tools like opendnssec.
Also client tools from '''bind-utils''' now support yaml export format
(''dig, mdig, delv'').
== Scope ==
* Proposal owners:
* Other developers: N/A
* Release engineering: N/A
* Policies and guidelines: N/A
* Trademark approval: N/A
* Alignment with Objectives:
== Upgrade/compatibility impact ==
N/A (not a System Wide Change)
* [https://downloads.isc.org/isc/bind9/9.11.26/doc/arm/Bv9ARM.ch05.html#ligh...
lightweight resolver (lwres)] server and nss client plugin are no
longer provided.
* named version with database backends support (bind-sdb) is also no
longer provided as subpackage. Instead several bind-dlz-* plugins are
offered as runtime loadable plugins, which require modification to
named configuration. They offer the same functionality with just
'''bind''' package and selected plugin.
* ''dnssec-enabled'' option is not supported anymore, it is always set
to ''yes''. ''dnssec-validation'' can be still turned off.
== How To Test ==
System administrators would receive the most recent stable version of
BIND, with improved performance and features.
Prerelease is available on
[https://copr.fedorainfracloud.org/coprs/pemensik/bind-9.16/ COPR].
== User Experience ==
* named service supports ''dnssec-policy'' option, merging
''dnssec-keymgr'' into ''named''.
* DNSSEC trust anchors were merged into ''trust-anchors'' section,
replacing previous ''trusted-keys'' and ''managed-keys''.
* '''dig +yaml''' provides machine parseable output in YAML format
== Dependencies ==
* bind-dyndb-ldap (required by freeipa)
== Contingency Plan ==
* Contingency mechanism: (What to do? Who will do it?) N/A (not a
System Wide Change)
* Contingency deadline: N/A (not a System Wide Change)
* Blocks release? N/A (not a System Wide Change), Yes/No
* Blocks product? product
== Documentation ==
* Upstream [https://bind9.readthedocs.io/en/v9_16_10/notes.html BIND
9.16 Release Notes]
* [https://bind9.readthedocs.io/en/v9_16_10/notes.html#notes-for-bind-9-16-0
Added and removed features]
* Upstream [https://downloads.isc.org/isc/bind9/9.14.0/RELEASE-NOTES-bind-9.14.0.html
BIND 9.14 Release Notes]
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
3 years, 5 months
Orphaned perl-XML-SAX-ExpatXS, perl-Math-Libm, perl-Math-NumSeq,
perl-Math-PlanePath, perl-Math-Factor-XS
by Miro Hrončok
Hello,
I have orphaned:
perl-XML-SAX-ExpatXS
perl-Math-Libm
perl-Math-NumSeq
perl-Math-PlanePath
perl-Math-Factor-XS
Those used to be (transitive) build dependencies of prusa-slicer, but they are
no more.
Note that prusa-slicer seems to FTBFS for unrelated reason on rawhide, so they
will still be reported as needed by repoquery, but I've pushed:
https://src.fedoraproject.org/rpms/prusa-slicer/c/6188029a33611c686c24213...
Anecdata: perl-Math-Libm was one of my first packages ever, packaged as a
dependency of slic3r on/after a RPM packaging workshop in Brno in 2012.
Obviously, there was a license issue, but I've managed to solve it:
https://src.fedoraproject.org/rpms/perl-Math-Libm/blob/master/f/Math-Libm...
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
3 years, 5 months
proposal: move Data Corruption criterion from Final to Beta
by Kamil Paral
Hello, I already sent this proposal (quoted below) to the test list last
week. Please read the existing discussion at:
https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.or...
So far, I collected a thumbs up from Chris Murphy and Ben Cotton. I'm
forwarding it also here to the devel list, to collect more feedback, if
there is any.
Thanks,
Kamil
---------- Forwarded message ---------
From: Kamil Paral <kparal(a)redhat.com>
Date: Thu, Jan 7, 2021 at 1:44 PM
Subject: proposal: move Data Corruption criterion from Final to Beta
To: test <test(a)lists.fedoraproject.org>
I propose we move the existing Data Corruption criterion from Final to
Beta. The criterion sounds like this:
"All known bugs that can cause corruption of user data must be fixed or
documented at Common F34 bugs."
https://fedoraproject.org/wiki/Fedora_34_Final_Release_Criteria#Data_corr...
(see footnotes for some additional details)
The reason for this proposal is this bugzilla [1] and this blocker ticket
[2] where we discussed whether we should ship an older Firefox on F33 Beta
media, which was known to completely wipe the whole user profile on
upgraded systems. We didn't (and still don't) have any release criterion
which says that this situation should not occur. Fortunately, in the F33
Beta case, we managed to ship a fixed version of Firefox in time, and so we
didn't really need to make a decision back then.
I talked about this problem in general in [2], and I said:
"I support moving the Data Corruption criterion to Beta, with the rationale
that we also require system upgrades to be fully working at Beta, and that
puts testers into a tough place where they are recommended to upgrade but
might lose personal data. It seems to me that those two things should be
coupled together, for important cases (like this one, IMO). The corruption
criterion allows us to decide when we want to demand the fix and when it's
enough to have it documented. If e.g. all my history+bookmarks+passwords
get purged from Firefox or if e.g. my ~/Documents folder gets removed on
Beta upgrade, I believe we should have an option to block the Beta release.
At the same time, we don't need to apply it if you only lose e.g. your
color profiles in gnome-terminal. Currently your whole home can get purged
and we don't have a way to stop it in Beta, I find that a problem."
The criterion as currently written is flexible enough that it doesn't force
us to fix the issue, if we consider it low-risk or low-impact, but it
*enables us* to have that conversation and accept the high-risk or
high-impact issues as blockers. That's why I believe moving it to Beta
doesn't bring any downsides, just advantages.
Please comment, thank you.
Kamil
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1881495
[2] https://pagure.io/fedora-qa/blocker-review/issue/118
3 years, 5 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, 5 months
Re: libdnet in Fedora
by Richard W.M. Jones
[Adding Cathy who is the open-vm-tools maintainer in RHEL
and Ravindra who is the maintainer in Fedora]
On Thu, Jan 14, 2021 at 01:36:05PM +0100, Oliver Falk wrote:
> On Thu, Jan 14, 2021 at 12:49 PM Richard W.M. Jones <rjones(a)redhat.com> wrote:
>
> Hi Oliver and others,
>
> I'm trying to fix a few things in Fedora's libdnet and have some
> questions.
>
> (1) I'm unclear what the canonical upstream of libdnet should be.
> There seem to be a couple of candidates:
>
> https://github.com/boundary/libdnet - not updated since 2016
> https://github.com/ofalk/libdnet - recently updated
>
> The current spec file points to the "boundary" repo, but I think we
> should move to Oliver Falk's apparently more active fork.
>
> (2) If we move to the ofalk repo, then there is a new version (1.14).
>
> (3) I received a bug report about multilib conflicts with this
> package. I previously fixed this
> (https://bugzilla.redhat.com/342001), but my fix was reverted,
> apparently by a bad revert commit:
>
> https://src.fedoraproject.org/rpms/libdnet/c/
> 224a9645782f69ae05b0e7caeb2e52e12b5655cb?branch=master
>
> I would therefore like to include the multilib fix again.
>
> Please let me know your thoughts on all this.
>
> Hey Richard!
>
> Due to the inactivity of the previous maintainer, yes, I took over libdnet and
> tried to fix a few long standing issues. Given this also incorporated some ABI
> incompatibilities, the version (and soname) were raised. API compatibility,
> however, should be OK and if there is any issue, I'm sure we can sort that out
> as well.
> If there is anything that needs to be fixed, please open an issue on GitHub and
> /or provide a PR and I'll be happy to review and merge!
Thanks for confirmation. I will do the update shortly, but only in
Rawhide, and we'll see what the fall-out is.
Ravindra: I'll also rebuild open-vm-tools against the new package
(again, only in Rawhide).
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
libguestfs lets you edit virtual machines. Supports shell scripting,
bindings from many languages. http://libguestfs.org
3 years, 5 months
Schedule for Thursday's FPC Meeting (2021-01-14 17:00 UTC)
by James Antill
Following is the list of topics that will be discussed in the FPC
meeting Thursday at 2021-01-14 17:00 UTC in #fedora-meeting-1 on
irc.freenode.net.
Local time information (via. uitime):
================= Day: Thursday ==================
2021-01-14 09:00 PST US/Pacific
2021-01-14 12:00 EST --> US/Eastern <--
2021-01-14 17:00 GMT Europe/London
2021-01-14 17:00 UTC UTC
2021-01-14 18:00 CET Europe/Berlin
2021-01-14 18:00 CET Europe/Paris
2021-01-14 22:30 IST Asia/Calcutta
---------------- New Day: Friday -----------------
2021-01-15 01:00 HKT Asia/Hong_Kong
2021-01-15 01:00 +08 Asia/Singapore
2021-01-15 02:00 JST Asia/Tokyo
2021-01-15 03:00 AEST Australia/Brisbane
Links to all tickets below can be found at:
https://pagure.io/packaging-committee/issues?status=Open&tags=meeting
= Followup Actions =
#topic #pr-814
* mhroncok
talk to authors again, having a working example might help a lot
#topic Open Floor
* decathorpe
look through non-meeting tickets, see if any are stuck/need to be discussed
= Followup Issues =
#topic #907 Which %__foo macros for executables are acceptable?
.fpc 907
https://pagure.io/packaging-committee/issue/907
= Followup Pull Requests =
#topic #pr-814 Add SELinux Independent Policy Guidelines.
https://pagure.io/packaging-committee/pull-request/814
= Open Floor =
For more complete details, please visit each individual ticket. The
report of the agenda items can be found at:
https://pagure.io/packaging-committee/issues?status=Open&tags=meeting
If you would like to add something to this agenda, you can:
* Reply to this e-mail
* File a new ticket at: https://pagure.io/packaging-committee
* E-mail me directly
* Bring it up at the end of the meeting, during the open floor topic. Note
that added topics may be deferred until the following meeting.
3 years, 5 months