F39 Change Proposal: Allow Removal of tzdata (System-Wide)
by Aoife Moloney
https://fedoraproject.org/wiki/Changes/AllowRemovalOfTzdata
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 ==
Allow the removal of tzdata especially on containers in order to minimize size.
== Owner ==
* Name: Patsy Griffin (Franklin)
* Email: patsy(a)redhat.com
== Detailed Description ==
This change will allow the removal of tzdata. When tzdata is removed,
the system will default to UTC. In order to reduce overhead, many
container installations now remove the data associated with tzdata but
cannot fully remove the package due to dependencies by other packages.
This results in confusion regarding the expected timezone info.
In order for this to work, we need packages that use tzdata at run
time to switch from Require'ing tzdata to Recommend'ing tzdata. These
packages should also gracefully handle instances where tzdata has been
removed. For example, this would require recognizing that tzdata is
not present and providing an appropriate error, such as recommending
that the user install tzdata.
== Feedback ==
In June of 2021, we proposed creating a new tzdata sub-package that
would only provide the UTC timezone. As part of the discussion around
this proposal, it was recommended that we completely remove tzdata. We
appreciated this input and welcome additional feedback.
== Benefit to Fedora ==
This change will allow tzdata to be removed from containers without
leaving inconsistent package remnants.
== Scope ==
* Proposal owners: No changes are needed to tzdata.
* Other developers: Some packages need to change their spec files from
`Requires: tzdata` to `Recommends: tzdata`. It would be beneficial if
all packages switched in this way, but it is not required. Supporting
optional tzdata installation for as many workloads as possible allows
those workloads to minimize their container image size.
List of packages which need to be changed:
* glibc (glibc-common)
* gcc (libstdc++)
* python3.XX (3.9, 3.10, 3.11, 3.12)
List of packages which would be beneficial to be changed:
* python3-dateutil
* python3-pytz
* libical
Upon acceptance of the change request we will file bugs to fix each of
these packages for Fedora 39.
* Release engineering: No changes needed.
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Community Initiatives:
== Upgrade/compatibility impact ==
If tzdata is already installed, then it continues to be installed on the system.
Following the Fedora Weak Dependencies Policy dnf will treat the
Recommends on tzdata as if it were a Requires and tzdata will always
be installed in a default system
(https://docs.fedoraproject.org/en-US/packaging-guidelines/WeakDependencies/)
However, the recommends will allow tzdata to be correctly uninstalled
in a container build file rather than having to use ‘rm -rf’ to delete
the zone files to recover space.
== How To Test ==
Language runtimes were installed and A/B tests carried out with tzdata
present and tzdata removed. The intent of these tests was to ensure
that the system can use the language frameworks without tzdata present
and that when the data was required that meaningful errors were
presented to the user.
Packages tested were C (glibc), C++ (libstdc++), Python (Python 3.11),
using their time and date APIs. This testing led to the correction of
the libstdc++ implementation as noted here:
https://gcc.gnu.org/cgit/gcc/commit/?id=4abd5bc600193e821fbc41995a0b8d9ea...
Developers can test this by installing Rawhide and uninstalling tzdata
and verifying their package operates as expected.
If tzdata cannot be uninstalled then we recommend filling a bug
against the package that Requires: tzdata and having a discussion with
the maintainer to make tzdata optional e.g. Recommends: tzdata.
== User Experience ==
The user can remove tzdata to minimize the container size.
With tzdata removed the system is UTC only.
== Dependencies ==
Fixing glibc, gcc, and python3.xx at a minimum to make tzdata
Recommends instead of Requires.
== Contingency Plan ==
* Contingency mechanism: Back out the change. Don’t do it.
* Contingency deadline: Can be backed out at the last minute since we
are only dealing with conversions from Requires to Recommends.
* Blocks release? No
== Documentation ==
Document that the tzdata package may be removed if needed to reduce
space on containers. With tzdata removed, the system will default to
UTC.
== Release Notes ==
--
Aoife Moloney
Product Owner
Community Platform Engineering Team
Red Hat EMEA
Communications House
Cork Road
Waterford
3 hours, 28 minutes
Re: TSS maintainer volunteer
by Petr Pisar
V Thu, Feb 16, 2023 at 07:29:07PM +0000, Kenneth Goldman napsal(a):
> I think I followed all those steps - identifying the package, announcing that
> I want to be the packager, making an account, etc.
>
> What's next?
Submit an updated tss2 package for a package review. As far as I can see,
there is no review opened for tss2 now
<https://bugzilla.redhat.com/buglist.cgi?component=Package%20Review&produc...>.
How to do it is described at
<https://docs.fedoraproject.org/en-US/package-maintainers/Package_Review_P...>.
Especially pay attention to:
If you are not member of the packager group, you need a sponsor. Add
FE-NEEDSPONSOR to the bugs being blocked by your review request.
> Does someone approve me?
Based on the FE-NEEDSPONSOR blocker someone from sponsors should notice your
review request and start to communicate with you in the review request in
Bugzilla. (If that does not happen, approach you a sponsor of your choice as
recommended at
<https://docs.fedoraproject.org/en-US/package-maintainers/How_to_Get_Spons...>)
Once the sponsor finds your package looks good and you understand how to
maintain a package, he/she will sponsor you, i.e. adds you into a packagers
group. Then you will be able to continue from this item on the
Package_Review_Process document:
When your package passes the review you should use fedpkg to request a Git
repository for it.
> Move a git repo somewhere?
For the purpose of the package review, you need to publish the spec file and
the SRPM file somewhere on the Internet. (Once you become a packager, you can
also use <https://fedorapeople.org/> server for that purpose.)
Once the package review passes, the offical git repository (called dist-git in
Fedora) for the tss2 package will be reopened with completing this item:
Request a Git repository for the package
Then you will commit the new spec file into the reopen dist-git repository.
-- Petr
1 week, 6 days
Bootstrapping package with circular dependencies in koji
by Jaroslav Skarvada
Hi,
I need to bootstrap package which has bootstrap support written
according to the [1]. I am able to bootstrap it locally (rpmbuild,
mock, ...) with the "--with bootstrap" or "-D '_with_bootstrap 1'". Is
there support for it in koji? E.g. something like:
koji build SIDE-TAG PACKAGE --bootstrap? Or do I have to manually do:
1. patch:
- %bcond_with bootstrap
+ %bcond_without bootstrap
2. koji build SIDE-TAG SCM
3. update&build the circular dep
4. unpatch:
- %bcond_without bootstrap
+ %bcond_with bootstrap
5. release bump
6. koji build SIDE-TAG SCM
Or is there some better way?
thanks & regards
Jaroslav
[1] https://docs.fedoraproject.org/en-US/packaging-guidelines/#bootstrapping
2 weeks
CVE: Python-twisted a.o. needs update for F37 due to matrix-synapse
security issue
by Marius Schwarz
Hi,
due to an outdated(afaik) python-twisted version, it's not possible to
build matrix-synapse in version 1.8x .
Unlucky for all F37 users, matrix-synpase has 3 embargoed CVEs coming,
which need fixing asap.
As "releng" has shipped the last twisted update, I have no clue who
could help here on the python side and upgrade the packages.
Kai Hiller tries to cherry pick the required patches for synapse, but it
would of course be better to build the newest
synapse version for F37 too.
ATM we can only workaround this by using the f38 packages for synapse
and it's dependencies. AFAICT it's works without issues atm.
This brings me to the question: whats the main issue for twisted here?
best regards,
Marius Schwarz
3 weeks, 1 day
Intern Introduction & Goals (Open 3D Engine)
by Nicholas Frizzell
Hello,
My name is Nicholas and I'm working this summer as an intern with Red
Hat. My primary objective this summer is to improve support for the
O3DE project (https://www.o3de.org/) in Fedora and eventually have it
packaged and available for install through the official repositories.
If anyone is interested in this topic or has any advice/suggestions to
help this project along feel free to reach out.
3 weeks, 1 day
Thoughts welcome: interface between automated test gating and the
"critical path"
by Adam Williamson
Hi folks!
I have one of those definitional quandaries and I figured I'd throw it
at the lists for some input.
Right now, we kind of take advantage of the "critical path" concept for
automated update testing and gating via openQA.
openQA does not test all updates, only critical path updates plus
updates containing any package on a short allowlist.
Bodhi and Greenwave do not gate all updates on the openQA tests since
not all updates are tested; again we use the critpath definition. If an
update is critical path, it gets gated on the openQA tests. If it
isn't, it doesn't.
If you've been paying attention, that means there's a bit of a hole:
the packages on the 'allowlist'. These are tested, but not gated.
What's on the allowlist? Basically, FreeIPA-related packages. We have a
good set of FreeIPA tests in openQA, and both I and the FreeIPA team
wanted relevant updates to be tested with them. But those packages are
not on the critical path. So I set up this 'allowlist' mechanism.
However, the lack of gating kinda sucks. I would much prefer if we
could gate these updates as well as just testing them.
The obvious thing to do is add the FreeIPA-related packages to the
critical path, but that really is not supported by the critical path
definition:
https://fedoraproject.org/wiki/Critical_path_package
which defines it as packages required to "perform the most fundamental
actions on a system", with a list of specific areas, none of which is
"run a domain server".
So...what to do?
I can think of I guess four options:
1. Broaden the definition of the "critical path" somehow. We could just
write in that it includes FreeIPA functionality, I guess, though that
seems special purpose. We could broaden it to include any functionality
covered by the release criteria, which would be quite a big increase
but seems like a reasonable and concise definition. Or we could write
in that it includes any functionality that is exercised by the gating
openQA tests, though that seems a bit arbitrary - there's no
particularly great organizing principle to the openQA tests we choose
to run on updates, if I'm honest, it's a sort of grab bag I came up
with.
2. Keep the current "critical path" concept but define a broader group
of "gated packages" somewhere (could be comps or somewhere else). This
would require engineering work - we'd have to touch probably the openQA
scheduler, Bodhi, and greenwave configs. It's also another maintenance
burden.
3. Add gating config to each allowlisted package repo's gating.yml one
by one. I don't really like this option. It'd be a chunk of work to do
initially, and multiples the maintenance required when the list of
tests to gate on changes for some reason.
4. Do nothing, just keep only gating things that are "critical path" on
the current definition. In a utopian future, we'd manage to deploy
openQA in the cloud or get a giant pile of super fast servers so we
could test and gate *every* update, and this wouldn't be an issue any
more.
What do folks think? Any preferences? Thanks!
--
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net
1 month
Packaging a cross-compilation environment (wasi-libc)
by Jan Staněk
Hi list,
in order to be able to compile WASM natively on Fedora,
I'm trying to package wasi-libc[1] to provide the Web Assembly System
Interface.
[1]: https://github.com/WebAssembly/wasi-libc
My trouble is that this is in essence a cross-compilation environment,
and I have zero experience in trying to package these.
Also, I did not have much luck in trying to find any related
documentation.
Some issues I have run into so far:
- This is a libc implementation, which would probably conflict with the
glibc package by default. Looking at musl, the solution seems to be to
install into `/usr/{target}` prefix (i.e. `/usr/wasm32-wasi/include`).
Not really sure how this works, any pointers appreciated.
- Clang seems to have issue with `-fstack-clash-protection` flag for the
`wasm32-wasi` target. What's the proper way to adjust these?
Any additional tips on cross-compilation support in Fedora would also be
appreciated :)
Thanks in advance for any help!
--
Jan Staněk
Software Engineer, Red Hat
jstanek(a)redhat.com irc: jstanek
1 month, 1 week
F39 Change Proposal: Retire Modularity (Self Contained)
by Aoife Moloney
https://fedoraproject.org/wiki/Changes/RetireModularity
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 ==
Fedora will discontinue building
[https://docs.fedoraproject.org/en-US/modularity/ modules] for Fedora
Linux 39 and further in the Fedora infrastructure and shipping modular
content to users. The fedora-repos-modular and
fedora-repos-rawhide-modular packages will be retired and obsoleted.
The modular repositories will no longer be composed. Once Fedora Linux
38 reaches the end of life, Fedora's [https://mbs.fedoraproject.org/
Module Build Service] will be terminated. Whether or not dnf(5) would
still support modularity from 3rd party repository is out of the scope
of this proposal.
== Owner ==
* Name: [[User:Churchyard|Miro Hrončok]]
* Name: [[User:Mcurlej|Martin Čurlej]]
* Name: [[User:Ppisar|Petr Písař]]
* Email: mhroncok(a)redhat.com, mcurlej(a)redhat.com, ppisar(a)redhat.com
== Detailed Description ==
=== Motivation ===
There are very few modules left in Fedora, nobody is developing
modularity anymore and there is an everlasting infrastructure problem
with building modules. Similarly to retiring a package that has no
maintainers, we are retiring Modularity from Fedora, because it has no
maintainers. The latest noticeable activity in
[https://pagure.io/modularity pagure.io/modularity] was 3+ years ago.
=== What will happen ===
# After Fedora Linux 38 branches from Rawhide, we will disable
building modules for Rawhide and future Fedora Linux 39 and later.
# We will work with Release Engineering to disable composing of
modular repositories, F39 Modular updates in Bodhi etc.
# The fedora-repos-modular and fedora-repos-rawhide-modular
subpackages of fedora-repos will be removed and obsoleted by
fedora-repos and fedora-repos-rawhide.
# Once Fedora Linux 38 reaches end of life, we will retire the Fedora
instance of [https://mbs.fedoraproject.org/ Module Build Service].
=== What might or might not happen ===
Whether or not the package manager in Fedora Linux (dnf and/or dnf5)
will support modular repositories created by 3rd parties is not
decided in this change proposal. It is up to the dnf maintainers to
make this decision and we intentionally want to make the scope of this
proposal as limited as possible.
=== For maintainers of modules ===
Please retire your modules appropriately, so users are migrated to
suitable non-modular content. If you wish to continue shipping
multiple different versions or editions of your packages, please
follow [https://docs.fedoraproject.org/en-US/packaging-guidelines/Naming/#multiple
'''Multiple packages with the same base name'''], as was
[https://docs.fedoraproject.org/en-US/modularity/policies/#_requirements_f...
a recommendation of the policy for many years].
== Feedback ==
=== What will be offered as a replacement ===
We have been asked internally at Red Hat, what will be offered to
users of Fedora Linux if we retire modularity.
While we encourage anyone to share ideas they might have on the topic,
we intentionally offer no ''new'' alternative to modularity as part of
this change proposal. Replacing the retired modularity with something
else is intentionally out of scope of this proposal.
== Benefit to Fedora ==
Packager and Infra/Releng resources will not be wasted on Modularity.
Instead, we can focus on delivering quality content to our users
without it.
== Scope ==
* Proposal owners:
** Work with releng to disable modular builds in f39+
** Work with releng to disable composing and mirroring of modular repos for f39+
** Work with Bodhi admins to disable F39+ Modular updates
** Submit changes to fedora-repos package to remove and obsolete the
modular subpackages
** (once f38 is EOL) Work with infra to sunset MBS
* Other developers:
** Modular packagers:
*** Retire your modules
*** Ideally package the content as nonmodular
* Release engineering: [https://pagure.io/releng/issue/11480 #11480]
** Disable modular builds in f39+
** Disable composing and mirroring of modular repos for f39+
* Policies and guidelines: N/A (not needed for this Change) <!--
REQUIRED FOR SYSTEM WIDE CHANGES -->
* Trademark approval: N/A (not needed for this Change)
* Alignment with Community Initiatives:
== Upgrade/compatibility impact ==
An RPM scriptlet fedora-release might be necessary to deactivate all
Fedora-provided modular streams when upgrading to Fedora Linux 39 and
40. This will only happen if all other means of properly EOLing the
modules still block upgrades.
== How To Test ==
=== Has this landed? ===
# Check if fedora-repos-modular and fedora-repos-rawhide-modular are
missing from the repository and Obsoleted.
# Check if the modular repositories are missing from
download.fedoraproject.org and mirrormanager.
=== Does it work? ===
# Check if upgrading from Fedora Linux 37/38 to 39/40 with enabled
modular streams (from the Fedora repos) is still possible.
== User Experience ==
Users of Fedora Linux 39+ will no longer have access to the Fedora
modular repos. They can still install non-modular packages instead.
== Dependencies ==
* [[Changes/FlatpaksWithoutModules]]
* [[Changes/No_default_fedora-repos-modular]]
== Contingency Plan ==
* Contingency mechanism: Revert the changes
* Contingency deadline: Beta Freeze
* Blocks release? No
== Documentation ==
Ideally, all references to Fedora-provided modular streams should be
removed from docs.fedoraproject.org, except for
docs.fedoraproject.org/en-US/modularity which should be clearly marked
as obsolete/archived.
== Release Notes ==
Users of Fedora Linux 39+ will no longer have access to the Fedora
modular repos. They can still install non-modular packages instead.
--
Aoife Moloney
Product Owner
Community Platform Engineering Team
Red Hat EMEA
Communications House
Cork Road
Waterford
1 month, 1 week
F39 Change Proposal: LibuserDeprecation (System Wide)
by Aoife Moloney
https://fedoraproject.org/wiki/Changes/LibuserDeprecation
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 ==
Libuser is not actively developed. Most of the depending component
have build-time option to work without libuser.
== Owner ==
* Name: [[User:THalman| Tomas Halman]]
* Email: <thalman(a)redhat.com>
== Detailed Description ==
The libuser provides library and command line utilities to manipulate
user and group information. The purpose of the library
is/was to hide the differences between users in LDAP and files in etc
(passwd, groups...). The support for LDAP
is not complete and there is no plan to extend the functionality.
The LDAP integration in Fedora is nowadays done by SSSD.
In the past, the libuser was used by more component including Fedora
installer. Currently the list is short
* usermode (Requires development, it is not complicated but the
dependency is unconditional)
* util-linux (compile time option)
* passwd (I suggest to ship passwd utility from shadow-utils instead
of passwd and drop passwd package as well)
== Feedback ==
== Benefit to Fedora ==
The main benefit is to decrease the maintenance and packaging work on
library that does not bring much value while the functionality is
provided by another components.
== Scope ==
* Proposal owners: Dropping the package, move it to EPEL eventually
* Other developers:
** Update usermode code to make libuser dependency configurable.
** Update usermode packaging to compile it without libuser
** Change packaging of util-linux to compile without libuser dependency
** Change packaging of shadow-utils to provide passwd utility
* Release engineering: [https://pagure.io/releng/issue/11492]
Libuser is part of base image and must be removed. IMO mass rebuild is
not required.
* Policies and guidelines: Since this is about dropping packages
release notes must be updated.
* Trademark approval: N/A (not needed for this Change)
* Alignment with Community Initiatives: N/A
== Upgrade/compatibility impact ==
People who used libuser to manipulate users in LDAP will have to move to SSSD.
== How To Test ==
0. no special hardware needed
1. remove libuser, passwd, install new shadow-utils, usermod and util-linux
2. try to change password of some user
3. try to modify user using usermod
4. expected results: everything works normally
== User Experience ==
This change should not be visible for users.
== Dependencies ==
* usermod (code modification, packaging to drop libuser dependency)
* shadow-utils (packaging to provide passwd utility
* util-linux (packaging to drop libuser dependency)
* passwd (drop package)
== Contingency Plan ==
* Contingency mechanism: Revert the shipped configuration
* Contingency deadline: final development freeze
* Blocks release? No
== Documentation ==
There is no extra documentation for this change except release notes.
== Release Notes ==
--
Aoife Moloney
Product Owner
Community Platform Engineering Team
Red Hat EMEA
Communications House
Cork Road
Waterford
1 month, 2 weeks
