wlroots 0.14.0 is coming to rawhide
by Aleksei Bavshin
Greetings,
wlroots 0.14.0 was released this week with a lot of bugfixes, new pixman
software renderer for not-so-recent hardware and continuation of
renderer refactoring. As usual, the update is API and ABI breaking and
all dependent packages must be rebuilt.
I'll be taking care of all rebuilds except `cage`, `labwc` and
`wayfire`. I'll notify maintainers of those packages additionally (and
send a PR with compatibility patches for `labwc`) once the side-tag is
ready.
`phoc` will continue using wlroots0.12 compat package; no actions
required here.
Rawhide update ETA is in a week from this message or when all the
required builds are complete.
--
Best regards,
Aleksei Bavshin
2 years, 9 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, 9 months
userspace-rcu 0.13.0 soname bump
by Michael Jeanson
I have started the process to update userspace-rcu to 0.13 in rawhide
which implies a soname bump to 8.
From what I understand, the following packages will need to be rebuilt:
device-mapper-multipath
glusterfs
knot
libntirpc
lttng-tools
lttng-ust
netsniff-ng
nfs-ganesha
I have created a side tag 'f35-build-side-42347' and built
userspace-rcu, lttng-ust and lttng-tools. At this point I'm unsure what
the rest of the procedure is to get the other packages built in this tag
and then get them pushed to rawhide once it's done.
Michael
2 years, 9 months
Re: [Fedocal] Reminder meeting : Prioritized bugs and issues
by Ben Cotton
On Tue, Jun 29, 2021 at 7:00 AM <bcotton(a)redhat.com> wrote:
>
> You are kindly invited to the meeting:
> Prioritized bugs and issues on 2021-06-30 from 11:00:00 to 12:00:00 America/Indiana/Indianapolis
> At fedora-meeting-1(a)libera.chat
>
There are no nominated bugs and the two open bugs are being actively
nudged by yours truly. I'll cancel this meeting and we'll meet again
on 14 July.
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
2 years, 9 months
F35 Change: Disable SHA1 In OpenDNSSec (Self-Contained Change proposal)
by Ben Cotton
https://fedoraproject.org/wiki/Change/DisableSHA1InOpenDNSSec
== Summary ==
OpenDNSSec' enforcer has a (deprecated) -sha1 CLI option that brings
back the old behavior, e.g. include the SHA1 version of the DS. As
SHA1 use is deprecated in favour of SHA256, disable the -sha1 CLI knob
so that it only displays a warning.
== Owner ==
* Name: [[User:fcami| François Cami]]
* Email: fcami(a)redhat.com
== Detailed Description ==
OpenDNSSec changed the default behavior to not include SHA1 DS by
default, and added the -sha1 knob as an immediately-deprecated
compatibility knob in version 2.1.0 (2017-2): "OPENDNSSEC-552: By
default ‘ods-enforcer key export –ds’ included the SHA1 version of the
DS. SHA1 use is discouraged in favour of SHA256. To get the SHA1 DS
use the –sha1 flag. This flag is immediately deprecated and will be
removed from future versions of OpenDNSSEC." (see ChangeLog:
https://www.opendnssec.org/archive/releases/ ).
The proposal is to disable the -sha1 knob in Fedora. I will also open
an issue upstream to remove all the sha1-related code.
Supporting statement
[https://www.icann.org/en/blogs/details/its-time-to-move-away-from-using-s...
[from ICANN] (2020-1-24): "Now is the time for administrators of zones
at all levels of the DNS to stop using SHA-1 and change to algorithms
using stronger hashes."
== Benefit to Fedora ==
* This change makes sure OpenDNSSec in Fedora follows ICANN's
guidelines and does not propose SHA1 DS. This is is needed given the
[https://sha-mbles.github.io/ latest attacks against SHA-1]. More
in-depth articles are available
[https://www.dns.cam.ac.uk/news/2020-01-09-sha-mbles.html there] and
[https://mailarchive.ietf.org/arch/msg/dnsop/hA4Ur9qxRJIUo13Pjpmrm_va7cs/
there].
* This change is aligned with previous features:
** [[Features/StrongerHashes]]
** [[Changes/StrongCryptoSettings]]
** [[Changes/StrongCryptoSettings2]]
== Scope ==
* Proposal owners:
Patch the enforcer so that bsha1 is not honored anymore:
./enforcer/src/keystate/keystate_export_cmd.c-271- break;
./enforcer/src/keystate/keystate_export_cmd.c-272- case 's':
./enforcer/src/keystate/keystate_export_cmd.c:273: bsha1 = 1;
./enforcer/src/keystate/keystate_export_cmd.c-274- break;
./enforcer/src/keystate/keystate_export_cmd.c-275- default:
* Other developers:
* Release engineering:
* 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 ==
Zones with SHA-1 signatures can be migrated to SHA-256 by re-signing the zone.
This change might break (very old) clients that only recognize SHA-1
but these should already be broken (on the Internet at least) because
the root zone is signed with SHA-256 only.
== How To Test ==
== User Experience ==
OpenDNSSec in Fedora can currently be used to sign zones with SHA1.
With this change, this will no longer be possible. The migration from
SHA1 is underway anyway.
== Dependencies ==
FreeIPA (freeipa-server-dns) depends on OpenDNSSec.
== Contingency Plan ==
* Contingency mechanism: Keep the current -sha1 knob's behavior
(remove the patch).
* Contingency deadline: Beta freeze
* Blocks release? No, unless the change breaks IPA.
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
2 years, 9 months
F35 Change: GNU Toolchain update (gcc 11, glibc 2.34, binutils 2.37,
gdb 10.2) (System-Wide Change proposal)
by Ben Cotton
https://fedoraproject.org/wiki/Changes/GNUToolchainF35
== Summary ==
Switch the Fedora 35 GNU Toolchain to gcc 11 (lastest point release),
binutils 2.37, and glibc 2.34.
The gcc 11 is already included in Fedora 34, but the release will be
updated to the latest point release. The glibc 2.34 change will be
tracked in this top-level GNU Toolchain system-wide update. Likewise
the binutils 2.37 release will be tracked in this top-level GNU
Toolchain system-wide update.
The gdb 10.2 is already in Fedora 34, but the release will be updated
to the latest point release.
== Owner ==
* Name: [[User:codonell|Carlos O'Donell]]
* Email: carlos(a)redhat.com
== Detailed Description ==
<!-- Expand on the summary, if appropriate. A couple sentences
suffices to explain the goal, but the more details you can provide the
better. -->
The GNU Compiler Collection, GNU C Library, and GNU Binary Utilities
make up the core part of the GNU Toolchain and it is useful to
transition these components as a complete implementation when making a
new release of Fedora.
The GNU Compiler Collection has already released version 11 containing
many new features documented here:
https://gcc.gnu.org/gcc-11/changes.html. The latest point release for
gcc 11 will be included in Fedora 35, this will be either 11.1
(already released in April) or 11.2 (released later).
The GNU C Library version 2.34 will be released at the beginning of
August 2021; we have started closely tracking the glibc 2.34
development code in Fedora Rawhide and are addressing any issues as
they arise. Given the present schedule Fedora 35 will branch after the
glibc 2.34 upstream release. However, the mass rebuild schedule means
Fedora 35 will mass rebuild (if required) after glibc 2.34 upstream
freezes ABI for release, but before the actual release, so careful
attention must be paid to any last minute ABI changes.
The GNU Binutils version 2.37 will be released near the end of July 2021;
The GNU Debugger verion 10.2 is already released.
== Benefit to Fedora ==
Stays up to date with latest features, improvements security and bug
fixes from gcc, binutils and glibc upstream.
The goal is to track and transition to the latest components of the
GNU Toolchain.
== Scope ==
* Proposal owners: Fedora Toolchain Team (gcc, glibc, binutils, ...)
The gcc and glibc teams will need to move their respective upstream
projects to a releasable state. For GCC this includes correctly
building Fedora rawhide.
* Other developers: Developers need to ensure that gcc, binutils, and
glibc in rawhide are stable and ready for the Fedora 35 branch. Given
that glibc is backwards compatible and we have been testing the new
glibc in rawhide it should make very little impact when updated,
except for the occasional deprecation warnings and removal of legacy
interfaces from public header files. An update to GCC 11.2 would be a
minimal change with bug fixes. The binutils 2.37 update has the
broadest scope for change and generated object files should be
reviewed and failures to build analyzed.
<!-- See Toolchain example: https://pagure.io/releng/issue/9491 -->
A mass rebuild is strongly encouraged. The glibc 2.34 release merges
libpthread.so into libc.so and it would be important to remove
DT_NEEDED on libpthread.so from all distribution binaries.
* Policies and guidelines: The policies and guidelines do not need to
be updated.
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
The compiler, the static linker and the the library are backwards
compatible with the previous version of Fedora.
Some packaging changes may be required for the glibc 2.34 rebase:
https://sourceware.org/glibc/wiki/Release/2.33#Packaging_Changes
Some source changes may be required for gcc 11 rebase:
https://gcc.gnu.org/gcc-11/changes.html
All changes for gcc 11 will have been included in Fedora 34 alraedy.
There should be no need for any changes to accommodate the new GNU
Binutils release.
We fully expect to fix all packaging changes in Fedora Rawhide without
impact to the release.
== How To Test ==
The GNU C compiler collection has its own testsuite which is run
during the package build and examined by the gcc developers before
being uploaded.
The GNU Binary Utilities has its own testsuite which is run during the
package build and examined by the binutils developers before being
uploaded.
The GNU C Library has its own testsuite, which is run during the
package build and examined by the glibc developers before being
uploaded. This test suite has over 6200 tests that run to verify the
correct operation of the library. In the future may also run the
microbenchmark to look for performance regressions.
== User Experience ==
Users will see improved performance, many bugfixes and improvements to
POSIX compliance, additional locales, etc.
== Dependencies ==
All packages do not need to be rebuilt due to backwards compatibility.
However, it is advantageous if a mass rebuild is performed during the
Fedora 35 cycle. In particular the glibc merge of libpthread into libc
will remove the dependency in ELF binaries on libpthread, and that
cleanup is valuable for consistency.
== Contingency Plan ==
* Contingency mechanism: If glibc 2.34 provides too disruptive to
compiling the distribution we could revert to 2.33, but given that
Rawhide has started tracking glibc 2.34, no show-stopper problems are
expected. At this point, we can still revert to upstream version 2.33
if insurmountable problems appear, but to do so may require a mass
rebuild to remove new symbols from the ABI/API.
* Contingency deadline: Upstream glibc ABI freeze deadline of 2021-07-01.
* Blocks release? Yes, upgrading to the gcc point release blocks the
release. Yes, upgrading to binutils 2.37 blocks the release. Yes,
upgrading glibc does block the release. We should not ship without a
newer binutils and glibc, there will be gcc and language features that
depend on glibc being upgraded. Thus without the upgrade some features
will be disabled or fall back to less optimal implementations.
== Documentation ==
The gcc manual contains the documentation for the release and doesn't
need any more additional work.
The binutils manual contains the documentation for the release and
doesn't need any more additional work.
The glibc manual contains the documentation for the release and
doesn't need any more additional work.
== Release Notes ==
The GNU Compiler Collection version 11 is already released. See
https://gcc.gnu.org/gcc-11/changes.html.
The GNU Binutils version 2.37 will be released in the middle of July
and release notes will be updated at that point.
The GNU C Library version 2.34 will be released at the beginning of
August 2021. The current NEWS notes can be seen here as they are
added: https://sourceware.org/git/?p=glibc.git;a=blob;f=NEWS;hb=HEAD
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
2 years, 9 months
[HEADS UP] Moving to sip 5 in Rawhide
by Scott Talbert
Hi,
Just a heads-up, I've been working on converting packages from sip 4 to
sip 5 in Rawhide. (sip is the Python bindings generation system used by
PyQt and wxPython.)
I'm planning on opening pull requests against the affected packages soon.
Please DO NOT merge these PRs yet - they need to be merged and built in a
side tag in order to build them in the correct order. Please DO review
and comment on the PRs though. Kevin and Rex will be helping merge and
build once the changes are reviewed.
The sip 5 changes are planned for F35+ only. Please let me know in the PR
if you prefer the changes to be fast-forwardable to older releases and
I'll %if guard them.
The affected packages are:
python-pyqt5-sip -> NEW package
calibre
krita
plplot
pyqtwebengine
python-pyqtchart
python-qt5
python3-poppler-qt5
qgis
qhexedit2
qscintilla
scidavis
sip
veusz
Thanks,
Scott
2 years, 9 months
Auto-generated dependencies for builds against rawhide glibc snapshots
by Florian Weimer
I've pushed a new glibc build to rawhide (glibc-2.33.9000-29.fc35) that
auto-generates versioned dependencies on glibc if symbols within the
under-development symbol version are used, where the ELF-derived RPM
dependencies are inaccurate. Given the change to the startup code, this
affects all programs in this release cycle, and the libdl and libpthread
changes mean that most shared objects trigger the versioned dependency
as well.
The dependencies are conservative in the sense that you might a
dependency on a more recent glibc version than that is actually
required by the symbols used.
For the technical background, here's what I put into a comment within
the dependency generator itself:
# A glibc development snapshot (say version 2.33.9000) may define
# symbols in its under-development symbol version (GLIBC_2.34). RPM
# automatically derives RPM dependencies such as
# libc.so.6(GLIBC_2.34)(64bit) from that. While the GLIBC_2.34
# version is under development, these dependencies may be inaccurate
# and could be satisfied by glibc RPM package versions that lack the
# symbols because they were created from an earlier development
# snapshot that had some other GLIBC_2.34 symbols. Therefore, if the
# latest, under-development ELF symbol version is detected, this
# dependency generator adds an explicit RPM dependencies on the glibc
# packaging version against which an RPM package is built.
I've tested this to the best of my abilities, and it seems to work as
expected, but given that this new territory for me, there could be some
issues (like the race condition in the dependency generator discussed in
that other thread).
Thanks,
Florian
2 years, 9 months
Fedora Source-git SIG report #1 (June 2021)
by Tomas Tomecek
Greetings from the Fedora source-git SIG! We are planning to start
publishing reports of what we are working on so everyone can easily
pay attention and get involved if interested. If you have any ideas,
comments or requests, don’t be shy and let us know :)
Here’s a short list of things which we are working on.
## Choosing git forge to host source-git repositories
We need to find a home for all the source-git repositories. This is
actually a really hard task because we have many options (github.com,
gitlab.com, pagure.io, src.fedoraproject.org, something custom or
on-premise) and different expectations: some projects already have
repos set up on different platforms while Pagure is the primary forge
now. Since the CPE team is investigating GitLab as a forge, it's even
harder for us to figure out the primary forge. We may end up
supporting both actually: pagure.io and gitlab.com. What are your
thoughts on this topic? Would you prefer pagure.io or gitlab.com
More info:
* https://pagure.io/fedora-source-git/sig/issue/1
* https://pagure.io/fedora-source-git/sig/issue/7
## High-level workflow proposal up for review
Hunor proposed a high-level workflow linked below and I strongly
recommend reading it. We have also started discussing many details in
the process, such as getting archives: should we generate one from the
source-git repo or use the official release archive from upstream?
Another big topic in terms of workflows are rebases (= updates to the
latest upstream release, which are very common in Rawhide). Rebases
are straightforward in dist-git, but when your source-git repo has
complete upstream git history, they are no longer trivial, especially
if one wants to get a review of a rebase.
More info:
* https://pagure.io/fedora-source-git/sig/issue/2
* Workflow proposal: https://pagure.io/fedora-source-git/docs/pull-request/2
* https://pagure.io/fedora-source-git/docs/blob/main/f/resources/CommitRule...
* https://pagure.io/fedora-source-git/sig/issue/8
## Tooling
Packit is the tooling which will be used to work with source-git
repos. No surprise there I assume :D
* https://packit.dev/
We've done a lot of work here lately, mainly to polish the process of
creating source-git repos and doing updates of dist-git repositories
based on the source-git content.
* https://packit.dev/docs/source-git/work-with-source-git/
* https://github.com/packit/packit/releases
## Interested?
We meet biweekly on Wednesdays via gmeet, 2:30 - 3:30 UTC, next one is
scheduled for July 7th.
* https://calendar.fedoraproject.org/SIGs/2021/7/5/#m9982
Everyone is welcome to join the SIG or provide any feedback on the
issues and PRs above.
You can always find the latest information over here:
* https://fedoraproject.org/wiki/SIGs/Source-git
* https://pagure.io/fedora-source-git/sig/issues
I'd like to thank all the SIG members for being so active, so happy to
work with all of you!
Cheers,
Tomas
2 years, 9 months
