I've attempted to build an updated bodhi-server release for testing it
into staging, just a few more commits which fixes some glitches in the
web UI. However, running the tests in Koji fail both on F36 and F37:
E subprocess.CalledProcessError: Command '['dnf',
'--disablerepo=*', '--repofrompath=testrepo,/tmp/tmpu9wd3211bodhi/',
'--enablerepo=testrepo', '--setopt=skip_if_unavailable=0',
'--setopt=testrepo.skip_if_unavailable=0', '--refresh', '--nogpgcheck',
'list', 'available']' returned non-zero exit status 1.
/usr/lib64/python3.11/subprocess.py:571: CalledProcessError
----------------------------- Captured stderr call
-----------------------------
Failed to store expired repos cache: [Errno 13] Permission denied:
'/var/cache/yum/expired_repos.json'
Error: Cannot create repo destination directory
"/var/cache/yum/testrepo-c292118c2c2d1b32": Permission denied
There was no change in bodhi-server code that can justify the failure
(also running the tests upstream doesn't show any failure). Has
something been changed in Koji between 29/11 (time of the previous
successful build) and today?
These are the links to F36 and F37 failed builds:
https://koji.fedoraproject.org/koji/buildinfo?buildID=2107714https://koji.fedoraproject.org/koji/buildinfo?buildID=2107719
Mattia
https://fedoraproject.org/wiki/Changes/Ruby_3.2
This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora Engineering Steering Committee.
== Summary ==
Ruby 3.2 is the latest stable version of Ruby. Many new features and
improvements are included for the increasingly diverse and expanding
demands for Ruby. With this major update from Ruby 3.1 in Fedora 37 to
Ruby 3.2 in Fedora 38, Fedora becomes the superior Ruby development
platform.
== Owner ==
* Name: [[User:vondruch| Vít Ondruch]]
* Email: vondruch(a)redhat.com
== Detailed Description ==
Ruby 3.1 is upstream's new major release of Ruby. Many new features
and improvements are included.
=== WASI based WebAssembly support ===
This is an initial port of WASI based WebAssembly support. This
enables a CRuby binary to be available on Web browser, Serverless Edge
environment, and other WebAssembly/WASI embedders. Currently this port
passes basic and bootstrap test suites not using Thread API.
=== Regexp timeout ===
A timeout feature for Regexp matching is introduced.
It is known that Regexp matching may take unexpectedly long. If your
code attempts to match an possibly inefficient Regexp against an
untrusted input, an attacker may exploit it for efficient Denial of
Service (so-called Regular expression DoS, or ReDoS).
The risk of DoS can be prevented or significantly mitigated by
configuring `Regexp.timeout` according to the requirements of your
Ruby application. Please try it out in your application and welcome
your feedback.
=== Other Notable New Features ===
* Language
** Anonymous rest and keyword rest arguments can now be passed as
arguments, instead of just used in method parameters.
** A proc that accepts a single positional argument and keywords will
no longer autosplat.
** Constant assignment evaluation order for constants set on explicit
objects has been made consistent with single attribute assignment
evaluation order.
** Find pattern is no longer experimental.
** Methods taking a rest parameter and wishing to delegate keyword
arguments through `foo(*args)` must now be marked with
`ruby2_keywords`
* Performance improvements
** YJIT
*** Support arm64 / aarch64 on UNIX platforms.
*** Building YJIT requires Rust 1.58.1+.
=== Other notable changes since 3.1 ===
* Hash
** Hash#shift now always returns nil if the hash is empty, instead of
returning the default value or calling the default proc.
* MatchData
** MatchData#byteoffset has been added.
* Module
** Module.used_refinements has been added.
** Module#refinements has been added.
** Module#const_added has been added.
* Proc
** Proc#dup returns an instance of subclass.
** Proc#parameters now accepts lambda keyword.
* Refinement
** Refinement#refined_class has been added.
* Set
** Set is now available as a builtin class without the need for
`require "set"`. It is currently autoloaded via the `Set` constant or
a call to `Enumerable#to_set`.
* String
** String#byteindex and String#byterindex have been added.
** Update Unicode to Version 14.0.0 and Emoji Version 14.0. (also
applies to Regexp)
** String#bytesplice has been added.
* Struct
** A Struct class can also be initialized with keyword arguments
without `keyword_init: true` on `Struct.new`
=== Compatibility issues ===
* Removed constants
** `Fixnum` and `Bignum`
** `Random::DEFAULT`
** `Struct::Group`
** `Struct::Passwd`
* Removed methods
** `Dir.exists?`
** `File.exists?`
** `Kernel#=~`
** `Kernel#taint`, `Kernel#untaint`, `Kernel#tainted?`
** `Kernel#trust`, `Kernel#untrust`, `Kernel#untrusted?`
=== C API updates ===
* Removed C APIs
** `rb_cData` variable.
** "taintedness" and "trustedness" functions.
== Benefit to Fedora ==
With a latest release, Ruby language is supporting the newest language
features, which enables even faster and easier development of Ruby
applications.
== Scope ==
* Proposal owners:
** Finish packaging of Ruby 3.2. Current changes available in PR
https://src.fedoraproject.org/rpms/ruby/pull-request/134
** Rebuilding of Ruby packages providing native extensions (i.e.
packages which depends on libruby).
* Other developers:
** Rebuild of packages with binary extensions (i.e. packages which
depends on libruby) will be handled automatically, but some packages
might need fixes/updates to support Ruby 3.2 properly.
* Release engineering: [https://pagure.io/releng/issues/11115 #11115]
** The packages are going to be rebuild in side-tag, but that does not
need releng involvement nowadays.
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives:
== Upgrade/compatibility impact ==
* User specific Ruby binary extensions need to be rebuild.
* Ruby packages/application dependencies might need to be adjusted if
newly bundled gems are used.
== How To Test ==
* No special hardware is needed.
* To test, install Ruby 3.2. The test builds are published in PR or on
Ruby-SIG ML
* Try to locally rebuild your packages using Ruby 3.2.
* Use the packages with your applications previously written in Ruby.
* If something doesn't work as it should, let us know.
== User Experience ==
The Ruby programs/scripts should behave as they were used to.
== Dependencies ==
<!-- What other packages (RPMs) depend on this package? Are there
changes outside the developers' control on which completion of this
change depends? In other words, completion of another change owned by
someone else and might cause you to not be able to finish on time or
that you would need to coordinate? Other upstream projects like the
kernel (if this is not a kernel change)? -->
<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
<pre>
$ dnf repoquery --disablerepo=* --enablerepo=rawhide
--enablerepo=rawhide-source --arch=src --whatrequires 'ruby-devel' |
sort | uniq | wc -l
130
</pre>
== Contingency Plan ==
* Contingency mechanism: We would like to get a special buildroot tag
to be able to rebuild necessary the packages with Ruby 3.2. If
anything goes wrong, the tag could be easily dropped and previous
version of Ruby 3.1 and its dependencies stays intact. The tag would
be merged into F38 after everything is rebuild
* Contingency deadline: Mass Rebuild
* Blocks release? No
== Documentation ==
* [http://www.ruby-doc.org/ Help and documentation for the Ruby
programming language]
* [https://github.com/ruby/ruby/blob/master/NEWS.md Ruby 3.2.0 NEWS]
* [https://www.ruby-lang.org/en/news/2022/09/09/ruby-3-2-0-preview2-released/
Ruby 3.2 Preview 2 release announcement]
== Release Notes ==
* The Ruby 3.2 bumps soname, therefore Ruby packages, which use binary
extensions, should be rebuilt. Nevertheless, since upstream paid great
attention to source compatibility, no changes to your code are needed.
https://github.com/ruby/ruby/blob/master/NEWS.md
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
Hi everyone!
My name is Omar Sandoval. Davide Cavalca just sponsored me as a packager
and suggested that I introduce myself here.
I am a Software Engineer on the Linux Kernel team at Meta. These days I
spend most of my time on the debugger I created, drgn
(https://github.com/osandov/drgn) as well as debugging kernel issues in
our production fleet and kernel development work (mainly in Btrfs). I am
passionate about open source and love digging into arcane, low-level
details.
Fedora was the first Linux distro I ever tried back in high school, and
I've been using Linux exclusively ever since. I distro hopped a bit over
the years, but even when I wasn't using Fedora, I always admired how it
pushes Linux forward. I'm very excited to help out!
Thanks,
Omar
A fresh installation of Fedora 37 has by default the "--supervised"
option active in its gpg-agent systemd file
(/usr/lib/systemd/user/gpg-agent.service).
According to GnuPG Docs [1], this option is deprecated. Once gpg-agent
is invoked, the log of "systemctl --user status gpg-agent.service"
confirms that with: "gpg-agent[2022]: WARNING: "--supervised" is a
deprecated option"
Is this intended?
Off the cuff I do not see an immediate security issue, but I guess it
makes sense to get over deprecated options.
Regards,
Chris
[1] https://www.gnupg.org/documentation/manuals/gnupg/Agent-Commands.html
In one week (2023-01-12), or slightly later, I plan to build libfplll
5.4.4[1] in a side tag for Rawhide. This release is API-compatible with
5.4.2, but there is an ABI-breaking change[2], so the .so version
increases from 7 to 8.
I have verified compatibility with dependent packages in COPR[3].
Maintainers of affected packages should have received a copy of this
email directly:
- gap-pkg-float
- linbox
- Macaulay2
- python-fplll
- sagemath
When the side tag is ready, I will send another email to these packages’
maintainers so they can do the necessary rebuilds. If some maintainers
are unavailable and it looks like I won’t be able to close the side tag
before the F38 mass rebuild begins on 2023-01-18, I will ask a
provenpackager to finish the rebuilds.
[1] https://src.fedoraproject.org/rpms/libfplll/pull-request/2
[2] https://github.com/fplll/fplll/issues/502
[3] https://copr.fedorainfracloud.org/coprs/music/libfplll/packages/
https://fedoraproject.org/wiki/Changes/TeXLive2022
This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora Engineering Steering Committee.
== Summary ==
Update the TeXLive engines and components in Fedora to the 2022 version.
This will improve TeX document processing, conversion, and
internationalization, which is used by some Fedora packages (and
users).
== Owner ==
* Name: [[User:spot| Tom Callaway]]
* Email: spotrh(a)gmail.com
== Detailed Description ==
The goal is to update Fedora to the latest available version of
TeXLive (2022), including its large number of associated components.
This will resolve outstanding bugs in the existing TeXLive (2021)
packages, add new features, improve performance, and expand
internationalization support.
== Benefit to Fedora ==
Updating to TeXLive 2022 brings the latest versions of the TeX engines
and components into Fedora, which improves document rendering and
conversion. A number of Fedora packages include TeX support, which
depend on the TeXLive utilities.
In each TeXLive release, a large (hundreds) number of TeX components
are updated, a significant (~100) number of new TeX components are
added, and core functionality is enhanced and optimized.
Documents should render properly and export into various formats without issues.
== Scope ==
* Proposal owners:
The necessary changes are contained to the texlive and texlive-base
packages. These changes have already landed in rawhide.
* Other developers
No changes should be necessary for other packagers/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: It does not align with any current Objectives.
== Upgrade/compatibility impact ==
Users will need to delete old TexLive 2021 cache in order to properly
use TeXLive 2022 upon an upgrade. To do this, a user simply (and
carefully) needs to run:
rm -rf ~/.texlive2021
A new ~/.texlive2022 directory will be generated and used when the
user invokes TeXLive related functionality, but TeXLive will attempt
to use the older cache directory and it will not work properly.
== How To Test ==
Packagers who have packages that use TeX to generate documentation
should simply attempt to rebuild their package in rawhide with the
TeXLive 2022 packages. If it succeeds and the documents generated are
correct, nothing further is necessary. If it fails or the documents
generated are corrupted/damaged, please open a bug against the texlive
component.
== User Experience ==
The way that the user interacts with TeX/TeXLive does not change in
this release. A very small number of components (~10) in TeXLive have
been obsoleted and removed, but they have either been silently
replaced by other functionality or they were outdated documentation.
== Dependencies ==
While other packages in Fedora do depend on texlive component
packages, this is almost always for build-time generation of
documentation, and not in a traditional "linking to library" approach.
Packages with tex() or texlive dependencies should not need to make
any changes to use TeXLive 2022.
== Contingency Plan ==
* Contingency mechanism: Roll back to latest texlive/texlive-base 2021 packages.
* Contingency deadline: N/A (not a System Wide Change)
* Blocks release? N/A
== Documentation ==
https://tug.org/texlive/bugs.html
== Release Notes ==
Fedora 38 has updated its TeXLive support to 2022. Users who upgrade
from older versions of Fedora and who have used TeXLive previously may
need to delete the ~/.texlive2021 cache directory in order to have a
working TeXLive environment. A new ~/.texlive2022 cache directory will
be generated on first use of TeXLive 2022, but TeX will attempt to use
older cache directories if they exist.
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
https://fedoraproject.org/wiki/Changes/Unified_Kernel_Support_Phase_1
This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora Engineering Steering Committee.
== Summary ==
Add support for unified kernels images to Fedora.
== Owner ==
* Name: [[User:kraxel| Gerd Hoffmann]]
* Email: kraxel(a)redhat.com
== Detailed Description ==
The goal is to move away from initrd images being generated on the
installed machine. They are generated while building the kernel
package instead, then shipped as part of a unified kernel image.
A unified kernel image is an all-in-one efi binary containing kernel,
initrd, cmdline and signature. The secure boot signature covers
everything, specifically the initrd is included which is not the case
when the initrd gets loaded as separate file from /boot.
Main motivation for this move is to make the distro more robust and more secure.
Switching the whole distro over to unified kernels quickly is not
realistic though. Too many features are depending on the current
workflow with a host-specific initrd (and host-specific kernel command
line), which is fundamentally incompatible with unified kernels where
everybody will have the same initrd and command line. Thats why there
is 'Phase 1' in title, so we can have more Phases in future releases
😃
A host-specific initrd / command line is needed today for:
* features needing optional dracut modules (initrd rebuild needed to
enable them).
* configuration / secrets baked into the initrd (booting from iscsi
for example).
* configuration being specified on the kernel command line.
** root filesystem being the most important one.
[https://systemd.io/DISCOVERABLE_PARTITIONS/ Discoverable partitions]
allow to remove this.
Phase 1 goals (high priority):
* Ship a unified kernel image as (optional) kernel sub-rpm. Users can
opt-in to use that kernel by installing the sub-rpm. Initial focus is
on booting virtual machines where we have a relatively small and well
defined set of drivers / features needed. Supporting modern physical
machines with standard setup (i.e. boot from local sata/nvme storage)
too should be easy.
* Update kernel install scripts so unified kernels are installed and
updated properly.
* Add bootloader support for unified kernel images. Add
[https://systemd.io/BOOT_LOADER_SPECIFICATION/#type-2-efi-unified-kernel-ima…
unified kernel bls support] to grub2, or support using systemd-boot,
or both.
Phase 1 goals (lower priority, might move to Phase 2):
* Add proper discoverable partitions support to installers (anaconda,
image builder, ...).
** Temporary workaround possible: set types using sfdisk in %post script.
** When using btrfs: configure 'root' subvolume as default volume.
* Add proper systemd-boot support to installers.
** Temporary workaround possible: run 'bootctl install' in %post script.
* Better measurement and remote attestation support.
** store kernel + initrd hashes somewhere (kernel-hashes.rpm ?) to
allow pre-calculate TPM PCR values.
** avoid using grub2 (measures every config file line executed which
is next to impossible to pre-calculate).
* Switch cloud images to use unified kernels.
Phase 2/3 goals (longer-term stuff which is not realistic to complete for F38).
* Move away from using the kernel command line for configuration.
* Move away from storing secrets in the initrd.
* Handle dracut optional modules in a different way.
systemd has some building blocks which can be used, although none of
them are used by fedora today.
[https://www.freedesktop.org/software/systemd/man/systemd-creds.html
systemd credentials] can be used for secrets (also for configuration).
The [https://www.freedesktop.org/software/systemd/man/systemd-stub.html
unified kernel stub] can load credentials from the ESP.
The unified kernel stub can also load
[https://www.freedesktop.org/software/systemd/man/systemd-sysext.html
extensions] from the ESP, which can possibly be used to replace
optional dracut modules.
== Feedback ==
== Benefit to Fedora ==
* Better secure boot support (specifically the initrd is covered by
the signature).
* Better confidential computing support (measurements are much more
useful if we know what hashes to expect for the initrd).
* More robust boot process (generating the initrd on the installed
system is fragile, root cause for kernel bugs reported is simply a
broken initrd sometimes).
== Scope ==
* Proposal owners:
** Update kernel build to create unified kernel sub-package.
*** part one: [https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2179
PR#2179]
*** part two: (wip)
[https://gitlab.com/kraxel/kernel-ark/-/commits/unified/https://gitlab.com/kraxel/kernel-ark/-/commits/unified/]
* Other developers:
** grub2: add unified kernel support
*** wip code at [https://github.com/osteffenrh/grub2/https://github.com/osteffenrh/grub2/]
** installer(s): add support for discoverable partitions.
*** [https://bugzilla.redhat.com/show_bug.cgi?id=1075288 Bug#1075288]
* Release engineering: [https://pagure.io/releng/issues #Releng issue number]
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives:
== Upgrade/compatibility impact ==
None (using unified kernel is opt-in for Phase 1).
== How To Test ==
Try on a existing (uefi) system:
* make sure you are running fedora 37 or rawhide.
* make sure your root filesystem has type "Linux root (x86-64)" (use
`fdisk -l` to check).
** should that not be the case use the fdisk tag command ('t') to
change the partition type.
* when using btrfs: make sure the 'root' subvolume is set as default volume.
* `dnf copr enable kraxel/unified.kernel`
* `dnf update "grub2*"`
* `dnf install kernel-unified-virt`
* `reboot`
You should find two entries in the grub2 boot menu, one for classing
kernel with separate initrd and one for the unified kernel image.
Both should boot fine.
The https://gitlab.com/kraxel/fedora-uki project has kickstart files
and helper scripts for generating virtual machine images.
* image using grub2-efi:
https://gitlab.com/kraxel/fedora-uki/-/raw/master/kickstart/fedora-uki-grub…
* image using systemd-boot:
https://gitlab.com/kraxel/fedora-uki/-/raw/master/kickstart/fedora-uki-sdbo…
Prebuilt virtual machine images are available from
https://www.kraxel.org/fedora-uki/.
== User Experience ==
== Dependencies ==
== Contingency Plan ==
* Contingency mechanism:
** Probably none (unified kernel images are opt-in for Phase 1).
** In case we tried switching the cloud images to unified kernels:
revert the kickstart config changes.
* Contingency deadline:
* Blocks release? No
== Documentation ==
== Release Notes ==
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis