F38 proposal: GNU Make version 4.4 (System-Wide Change proposal)
by Ben Cotton
https://fedoraproject.org/wiki/Changes/MAKE44
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 ==
Rebase GNU make in Fedora 38 from make version 4.3 to make version 4.4.
== Owner ==
* Name: [[User:djdelorie| DJ Delorie]]
* Email: dj(a)redhat.com
== Detailed Description ==
Make 4.4 was released on Oct 31, 2022. It includes many bug fixes and
new features. Fedora has been carrying some patches to the 4.3
release which are included in 4.4, reducing the workload for Fedora
builders.
== Benefit to Fedora ==
Stay up to date with upstream GNU make, make sure we have the latest
bug fixes et al, be compatible with stock GNU make.
== Scope ==
* Proposal owners: Update to GNU make 4.4
* Other developers: Package owners relying on makefile features
specific to older versions of GNU make may FTBFS and need to tweak
their Makefiles. A
[https://gitlab.com/fedora/packager-tools/mass-prebuild mass prebuild]
run has identified at least two (apron due to
https://savannah.gnu.org/bugs/?57778 and pcmciautils due to
https://savannah.gnu.org/bugs/?60435)
* Release engineering: [https://pagure.io/releng/issues/11161]
* 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 ==
Users who have local projects using GNU make, which rely on features
only available in older versions of GNU make, may need to tweak their
Makefiles before rebuilding. Packages which were built previous to
this upgrade will not be affected.
Specific backwards incompatibilities as called out in the NEWS file
for make 4.4:
<pre>
* WARNING: Future backward-incompatibility!
In the NEXT release of GNU Make, pattern rules will implement the same
behavior change for multiple targets as explicit grouped targets, below: if
any target of the rule is needed by the build, the recipe will be invoked if
any target of the rule is missing or out of date. During testing some
makefiles were found to contain pattern rules that do not build all targets;
this can cause issues so we are delaying this change for one release cycle
to allow these makefiles to be updated. GNU Make shows a warning if it
detects this situation: "pattern recipe did not update peer target".
* WARNING: Backward-incompatibility!
GNU Make now uses temporary files in more situations than previous releases.
If your build system sets TMPDIR (or TMP or TEMP on Windows) and deletes the
contents during the build, or uses restrictive permissions, this may cause
problems. You can choose an alternative temporary directory only for use by
GNU Make by setting the new MAKE_TMPDIR environment variable before invoking
make. Note that this value CANNOT be set inside the makefile, since make
needs to find its temporary directory before the makefiles are parsed.
* WARNING: Backward-incompatibility!
Previously each target in a explicit grouped target rule was considered
individually: if the targets needed by the build were not out of date the
recipe was not run even if other targets in the group were out of date. Now
if any of the grouped targets are needed by the build, then if any of the
grouped targets are out of date the recipe is run and all targets in the
group are considered updated.
* WARNING: Backward-incompatibility!
Previously if --no-print-directory was seen anywhere in the environment or
command line it would take precedence over any --print-directory. Now, the
last setting of directory printing options seen will be used, so a command
line such as "--no-print-directory -w" _will_ show directory entry/exits.
* WARNING: Backward-incompatibility!
Previously the order in which makefiles were remade was not explicitly
stated, but it was (roughly) the inverse of the order in which they were
processed by make. In this release, the order in which makefiles are
rebuilt is the same order in which make processed them, and this is defined
to be true in the GNU Make manual.
* WARNING: Backward-incompatibility!
Previously only simple (one-letter) options were added to the MAKEFLAGS
variable that was visible while parsing makefiles. Now, all options are
available in MAKEFLAGS. If you want to check MAKEFLAGS for a one-letter
option, expanding "$(firstword -$(MAKEFLAGS))" is a reliable way to return
the set of one-letter options which can be examined via findstring, etc.
* WARNING: Backward-incompatibility!
Previously makefile variables marked as export were not exported to commands
started by the $(shell ...) function. Now, all exported variables are
exported to $(shell ...). If this leads to recursion during expansion, then
for backward-compatibility the value from the original environment is used.
To detect this change search for 'shell-export' in the .FEATURES variable.
</pre>
== How To Test ==
GNU make has its own testsuite and does not require specific hardware
or testing outside of building the RPM.
== User Experience ==
Users will get all bugfixes included in make 4.4 as well as any new
features therein. The make 4.4 NEWS update will include more details.
== Dependencies ==
Updating GNU make does not require any other change requests to complete first.
There are 9115 packages which explicitly BuildRequires "make". None
of those packages will require a rebuild because of this update.
== Contingency Plan ==
* Contingency mechanism: Revert to make 4.3
* Contingency deadline: Beta freeze. If there is a mass rebuild,
preferably before then.
* Blocks release? No
== Documentation ==
GNU Make includes its own documentation. No additional documentation
work is required.
https://www.gnu.org/software/make/manual/
== Release Notes ==
Full release notes can be found in make's NEWS file:
http://git.savannah.gnu.org/cgit/make.git/tree/NEWS
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
1 year, 6 months
Red Hat Bugzilla fonts
by Vitaly Zaitsev
Hello.
RHBZ began to demand Microsoft font "Segoe UI" since yesterday:
font-family: SFMono-Medium, SF Mono, Segoe UI Mono, "Roboto Mono",
"Ubuntu Mono", Menlo, Courier, monospace
> SFMono-Medium, SF Mono
Not packaged and not installed by default on Fedora, so the Segoe UI
Mono is used.
Is this okay? I think only open-source and packaged fonts should be used.
--
Sincerely,
Vitaly Zaitsev (vitaly(a)easycoding.org)
1 year, 6 months
New zlib-1.2.13
by Lukas Javorsky
Hi,
I've been working on a zlib rebase for some time now.
I would like to introduce it to you via COPR repo [1] first before I push
it to Fedora rawhide.
If you could test installing your package or even test the zlib
functionality, the feedback would be much appreciated.
The plan is to push the new zlib-1.2.13 to Fedora Rawhide in the next week
(Thursday or Friday).
Feel free to provide any feedback you can until then.
[1] https://copr.fedorainfracloud.org/coprs/ljavorsk/zlib-1.2.13/
Thank you so much. Regards
Lukas
--
S pozdravom/ Best regards
Lukáš Javorský
Software Engineer, Core service - Databases
Red Hat <https://www.redhat.com>
Purkyňova 115 (TPB-C)
612 00 Brno - Královo Pole
ljavorsk(a)redhat.com
<https://www.redhat.com>
1 year, 6 months
Need help with disappeared update from repository
by yanqiyu＠fedoraproject.org
Hi all,
It seems update fcitx5-qt-5.0.16-2.fc37 from [1] somehow did not make
it to stable repository while other package in same update did. This
caused broken dependences during update [2].
Seems that bodhi is doing something weird. I might have an idea how
this happened.]: I decided to update fcitx5-qt to 5.0.16 and created a
update [3] containing fcitx5-qt-5.0.16-1.fc37, during [3] waiting to
make it to stable, qt6 rebuild happens and created another update with
fcitx5-qt-5.0.16-2.fc37 [1]. [1] gets a lot karma and pushed to stable
soon. And when [3] gets pushed afterwards, somehow fcitx5-qt-5.0.16-
1.fc37 overrides fcitx5-qt-5.0.16-2.fc37.
I don't know if this behavior should be considered as a bug, but
anyway, it seems that manual override from releng is needed to fix the
broken dependencies.
Cheers,
Qiyu Yan
[1]: https://bodhi.fedoraproject.org/updates/FEDORA-2022-9821716191
[2]: https://github.com/fcitx/fcitx5/issues/678
[3]: https://bodhi.fedoraproject.org/updates/FEDORA-2022-729ae0f3ae
1 year, 6 months
Self Introduction: Gary Mann
by Gary Mann
Hello All,
This post will serve as my introduction into the devel community.
I've been around in the linux/redhat world for some time. My
professional experience includes well over 15 years in the telecom and
enterprise industries, with each year becoming more and more involved
in the open source community. When I have time I contribute to bug
reports, and also have my own redhat-esque software repository that I
use for lab testing that I have hosted on copr (currently out of date,
because life). My goal here is to contribute to Fedora/Redhat by
becoming a package maintainer. I've noticed that the 'mylvmbackup'
package is a simple package that currently has been retired in EL8
that could serve as a starting point for me if anyone is interested in
mentoring me. I'm not really sure what the next steps would be in that
regard though.
This however concludes my introduction, thanks for taking the time to
read it and let me know if you have any questions for me!
Gary
1 year, 6 months
moby-engine (also known as Docker) maintenance in Fedora
by Timothée Ravier
Hi everyone,
The moby-engine package [1] (also known as Docker) has been orphaned in Fedora and is looking for a new maintainer. The waiting period will soon be over and the package will be retired if nobody steps in.
This means that the package will be unavailable starting with the next release of Fedora (Fedora 38) that should happen in approximately 5 to 6 months.
If you are using this package and are interested in helping maintaining it, now is the time to come forward!
This notably impacts Fedora CoreOS as we are including the moby-engine package by default to let users pick their container engine of choice whithout deciding for them in advance. We offer both major container engines by default in the image (podman and moby-engine).
If the moby-engine package ends up being retired for Fedora 38, then we will have to recommend to its users on Fedora CoreOS that they either switch to the official Docker packages [2] or move to containerd or podman when the rebase to Fedora 38 happens alongside the Fedora 38 release [3].
Note that we will likely not remove the containerd package from Fedora CoreOS as it is still maintained in Fedora and is currently used by Kubernetes distributions based on Fedora CoreOS (such as Typhoon for example).
See also the Fedora CoreOS tracker issue [4] for more details.
[1] https://src.fedoraproject.org/rpms/moby-engine
[2] https://docs.docker.com/engine/install/fedora/
[3] https://fedorapeople.org/groups/schedule/f-38/f-38-key-tasks.html
[4] https://github.com/coreos/fedora-coreos-tracker/issues/1291
Thanks,
Timothée Ravier for the Fedora CoreOS team
1 year, 6 months
F38 proposal: Ostree Native Container (Phase 2, stable) (System-Wide
Change proposal)
by Ben Cotton
https://fedoraproject.org/wiki/Changes/OstreeNativeContainerStable
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 ==
Continue the work done in
https://fedoraproject.org/wiki/Changes/OstreeNativeContainer but in an
officially stable format, and expanded to cover more OSTree-based
editions. This goes "all in" on being container-native and
significantly changes the technology and user emphasis.
== Owner ==
* Name: [[User:walters| Colin Walters]], [[User:jmarrero| Joseph
Marrero]], [[User:baude| Brent Baude]]
* Email: walters(a)verbum.org, jmarrero(a)fedoraproject.org, baude(a)fedoraproject.org
== Detailed Description ==
* rpm-ostree's functionality to
[https://coreos.github.io/rpm-ostree/container/ boot and upgrade from
Docker/OCI container images] is declared stable
* Rework Fedora editions and spins (CoreOS, IoT, Silverblue, Kinoite,
etc) that use ostree to instead deliver via Docker/OCI container
images
* `rpm-ostree` is reworked to gain strong CLI compatibility with
`yum/dnf` commands (cliwrap)
* The new container native functionality is exposed via `dnf image`
* (TBD: Rebranding of rpm-ostree itself to `dnf-image` or something else)
* Support and documentation for generating derived images
* Support in Anaconda and other tools
* Support for generating bootable images
A top level goal is that users should not need to know or understand
ostree (or rpm-ostree); they only need to know containers and most key
functionality is exposed via the `yum/dnf` frontend with a few
extensions.
=== Backwards compatibility ===
If you're a user of ostree today: no need to worry. Everything that
works today in ostree and rpm-ostree will continue to work for years
to come (it's shipped in RHEL9). However, it's expected that most
users will find the new model sufficiently compelling to switch fairly
quickly.
=== Stable Bootable OCI ===
More information about this is available in
[https://coreos.github.io/rpm-ostree/container/ the rpm-ostree
documentation]. This Change highlights that this functionality is
planned to be officially stable.
=== Changing to OCI over the wire ===
Today Fedora has an OSTree repository that contains updates for
editions such as Fedora CoreOS and Fedora Silverblue.
These editions instead will become [https://github.com/opencontainers
OCI base images], available at e.g.
* `quay.io/fedora/fedora-coreos:stable`
([https://quay.io/repository/fedora/fedora-coreos this exists today]!)
* `quay.io/fedora/fedora-silverblue:38` (does not exist, but can soon)
An update will be shipped that will cause existing systems tracking
the production ostree branches to be switched to the corresponding
container image. Concretely for example, a system running
`fedora:fedora/36/x86_64/silverblue` will execute `rpm-ostree rebase
ostree-remote-registry:fedora:quay.io/fedora/fedora-silverblue:36`.
Note that at the current time, Fedora does not sign container images.
This should change (likely to something based on
[cosign](https://github.com/containers/skopeo/pull/1701)), but in the
mean time, the ostree-container flow supports verifying the embedded
ostree-baesd GPG signatures and this will continue to be used.
The Fedora OSTree repository will become read-only and stop receiving updates.
Note that for Fedora CoreOS specifically, there is some outstanding
design discussion around the intersection with Cincinnati:
https://github.com/coreos/fedora-coreos-tracker/issues/1263
==== Wire efficiency ====
Today the container images generated by rpm-ostree are "chunked" in a
reproducible fashion; for more information on this, see
* https://github.com/ostreedev/ostree-rs-ext/issues/69
* https://coreos.github.io/rpm-ostree/container/
However, longer term (as that first issue notes) we do want to add
[https://github.com/containers/image/pull/902 container deltas].
Doing so will benefit non-host containers too.
=== dnf/yum CLI compatibility ===
rpm-ostree has a feature called
[cliwrap](https://coreos.github.io/rpm-ostree/cliwrap/) today. A key
motivation here is that in the switch to using containers as the
frontend, the project name "rpm-ostree" (which is very literal) no
longer makes sense. A further emphasis on "container native" will
strongly encourage writing e.g. a `Dockerfile` like this:
<pre>
FROM quay.io/fedora/fedora-silverblue:stable
RUN dnf -y install sway && ostree container commit
</pre>
*Today*, one can spell this as `RUN rpm-ostree install -y sway &&
ostree container commit` - but a toplevel goal here is to allow host
system customization using the same patterns and tools one uses to
build application containers, and to de-emphasize the "ostree backend"
aspect.
To complete this story on the client side, what is today called
"ostree native containers" will be exposed via a new `dnf image`
subcommand on the client system.
For example:
<pre>
$ dnf image rebase quay.io/examplecorp/customos:latest
</pre>
As well as other offline/"image based" functionality such as `dnf
image rollback` and `dnf image apply-live`.
However, as many people know, rpm-ostree does today support
"per-machine" package layering/overrides - and *that will continue to
work*. So users are not *required* to do builds on a remote server
even in "image mode".
Concretely, it will also work to `sudo dnf -y install sway` inside a
root terminal on a Fedora Workstation for example. This will still be
a transactional operation.
More: https://github.com/coreos/rpm-ostree/issues/2883
=== Rebranding of rpm-ostree ===
This is a fundamental change in technology *and* positioning for
rpm-ostree (and for the projects that use it). The terminology of
"immutable" gets even fuzzier now (see also [this
blog](https://blog.verbum.org/2020/08/22/immutable-%E2%86%92-reprovisiona...).
It would make sense to rebrand the project due to this. No decision
has been made on this, but the choices are:
- Keep as is
- Rebrand to dnf-image (or, reviving a past name, yum-image)
- Rebrand to something else
More: https://github.com/coreos/rpm-ostree/issues/405
=== Support for building derivative containers ===
Until now, the model for systems like Fedora CoreOS and Silverblue
etc. has included an emphasis on containerization, but avoiding
extensive customization of the host system. This will be weakened
somewhat - it will be fully supported to build derivative operating
system images that in turn contain software which itself should run
directly on the host system, and not in a container.
A key aspect of this is that by generating a custom build, one binds
together the code and configuration as a transactionally updatable
unit.
The role of things like Kickstart, cloud-init, and Ignition and other
system config management shrinks significantly.
=== Example 1: Kubernetes and kubelet ===
It is not supported upstream to run the kubelet in a container image
itself. Today, for OpenShift 4 we embed the kubelet as part of the
CoreOS builds. The [https://www.okd.io/ OKD] project
[https://github.com/openshift/okd-machine-os/blob/fa2248d332abc9926e68428d...
already installs kubelet during a container build] deriving from the
base `fedora-coreos` image. It is possible that RHEL CoreOS will make
[https://github.com/openshift/os/issues/799 a similar split].
=== Example 2: Agent software ===
Many organizations require agents (cloud agents, security scanners,
antivirus) which are not ready to be containerized. Often too, these
tools come in e.g. RPM form, and also expect to be configured (remote
logging server, etc.). This tooling allows to `dnf install` these
*and* embed the configuration, generating a standard container image
which can then be booted as an atomic unit.
(Note that in the OpenShift context, we expect this to chain with the
first example - users instead derive from a `okd-node-base` image
which itself derives from `fedora-coreos`).
=== Example 3: Podman machine ===
The `[http://podman.io Podman]` project has a function called
`[https://github.com/containers/podman/blob/main/docs/source/markdown/podman-machine.1.md
machine]` where it creates a virtual machine and boots standard CoreOS
builds. Podman developers and users has long desired a custom FCOS
image that is focused on container deployment using Podman, including
certain QEMU packages that allow for cross-architecture development.
This approach will solve a series of problems including but not
limited to getting more timely release alignment between Podman and
FCOS.
We also have a user base that wants to customize the VM image based on
restrictive environments ... bring your own virtual machine image.
=== Support in Anaconda and other tools ===
Anaconda support for custom images is tracked in this bug:
https://bugzilla.redhat.com/show_bug.cgi?id=2125655
But, as part of this Change, it should also work to generate an
Anaconda ISO which allows *user choice* for whether to install in
"image mode" or "traditional".
=== Support for generating bootable images ===
Instead of using an existing disk image/ISO (Anaconda, AWS AMI, etc.)
and then doing an in-place update to a generated container image, in
many cases will want to generate disk images using their container
image as input.
For example, generating an ISO that embeds that container image as
input and will install it.
In this proposal, we plan to ship a container image as part of Fedora
CoreOS that will do this:
https://github.com/coreos/fedora-coreos-tracker/issues/1151
But, it also makes sense to have a tool that e.g. does this and
generates an Anaconda ISO (we will inherently be doing this as part of
generating ostree-based Anaconda ISOs already!) - this would just be
supporting that in a clear external way too. One likely target for
this is [https://github.com/osbuild osbuild] and
[https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/...
RHEL Image Builder].
== Feedback ==
== Benefit to Fedora ==
The need to understand ostree goes away for most users; they
understand RPMs and containers. While retaining all the current
(rpm-)ostree features.
== Scope ==
* Proposal owners:
* Other developers: May affect e.g. gnome-software and similar tools
that talk to rpm-ostree.
* Release engineering: [https://pagure.io/releng/issue/11047]
* Policies and guidelines: None.
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives: None
== Upgrade/compatibility impact ==
We will ship a systemd unit that transitions systems currently using
OSTree on the wire over to tracking the corresponding container
images. Note again, all features of rpm-ostree continue to work! For
example, if you have layered packages, that will continue to be
applied.
== How To Test ==
Build container images, boot them.
== User Experience ==
Users will not need to understand ostree (at least at a superficial
level), only container images.
== Dependencies ==
Needs improvements in Anaconda in some cases, also would like to
increase alignment with dnf. Fetching container images uses `skopeo`,
maintained by containers team.
== Contingency Plan ==
* Contingency mechanism: Continue to ship things the way we ship them today
* Contingency deadline: Dunno
* Blocks release? No
== Documentation ==
https://coreos.github.io/rpm-ostree/container/ and
https://github.com/coreos/coreos-layering-examples etc.
== Release Notes ==
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
1 year, 6 months
F38 proposal: libpinyin 2.8 (Self-Contained Change proposal)
by Ben Cotton
https://fedoraproject.org/wiki/Changes/libpinyin_2.8
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 ==
The libpinyin 2.8 will provide phrase suggestion candidate and longer
pinyin candidate features.
== Owner ==
* Name: [[User:pwu| Peng Wu]]
* Email: pwu(a)redhat.com
== Detailed Description ==
The phrase suggestion candidate feature will provide some candidates
which will following the previous input.
The longer pinyin candidate feature will provide one phrase candidate
which is longer than the pinyin input.
== Feedback ==
== Benefit to Fedora ==
By speeding up the Chinese characters input, the features will improve
the user experience for Chinese users when using Pinyin input method.
== Scope ==
* Proposal owners:
** Release libpinyin 2.8 and ibus-libpinyin 1.15
** Update the Fedora libpinyin package to version 2.8.0
** Update the Fedora ibus-libpinyin package to version 1.15.0
* 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:
== Upgrade/compatibility impact ==
== How To Test ==
For longer pinyin candidate feature, when user input "baiyun", one
candidate longer than the pinyin input like "白云岩" will appear in the
candidate list.
For phrase suggestion candidate feature, when user input "baiyun", and
choose the "白云" candidate, the input method will switch to suggestion
mode, and several suggestion candidates will appear, like "机场", "孤飞",
"亲舍", etc.
== User Experience ==
The longer pinyin candidate and phrase suggestion candidate features
will speed up the pinyin input when using the "Intelligent Pinyin"
input method.
== Dependencies ==
== Contingency Plan ==
* Contingency mechanism: Revert the libpinyin and ibus-libpinyin
package to the last stable version.
* Contingency deadline: N/A (not a System Wide Change)
* Blocks release? No
== Documentation ==
N/A (not a System Wide Change)
== Release Notes ==
The libpinyin 2.8 package will make the pinyin input faster in the
"Intelligent Pinyin" input method.
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
1 year, 6 months
