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
8 months, 1 week
Potential changes to systemd RPM macros
by Andrea Bolognani
Hi,
this requires a bit of background, so please bear with me :)
Earlier this year, the libvirt project changed its RPM package to be
more granular[1] as a step towards a future where the legacy
monolithic daemon (libvirtd) is completely gone. This change has
happened upstream, but the Fedora package uses the same spec file so
it was quickly reflected in Rawhide.
As part of this change virtproxyd, a service which has historically
been part of the libvirt-daemon package, has been moved to the
newly-introduced libvirt-daemon-proxy package.
More recently we have realized that, despite our care in trying to
ensure smooth upgrades, splitting the package this way has
unfortunately caused unintended consequences[2][3]. Specifically,
since the libvirt-daemon-proxy package is a completely new one as far
as RPM is concerned, all its systemd units will get presets applied
during %post. In at least two completely valid deployment scenarios,
this results in some amount of brokenness due to local configuration
changes made by the admin getting discarded.
In order to avoid this problem, I have implemented a new set of RPM
macros[4][5] that base the decision of whether presets should be
applied for a systemd unit not on whether the package that contains
them is being newly installed, but rather on whether the unit itself
existed on the system before package installation. This should
address not only the scenario of services being split off to separate
packages, but also the one where an existing package starts shipping
additional services.
Now, since this is clearly not a libvirt-specific issue, I believe
this approach should be adopted across Fedora by way of these macros
(or comparable ones) being added to systemd. Packages would have to
migrate from the old macros over time, and at some point it should be
possible to get rid of them entirely.
Note that openSUSE already has its own distro-specific RPM macros for
dealing with systemd units, and in fact the approach that I have
implemented is partially inspired by theirs. Ideally, we'd be able to
collaborate with them to create a single set of macros that lives in
systemd and satisfies the needs of both Fedora and openSUSE.
The problem is that Fedora 39 and RHEL 9.3 are fast approaching and,
if we don't do anything about this issue before then, a subset of
libvirt users will see their deployments broken after upgrade. In the
interest of avoiding that, I would prefer to get the libvirt-specific
version of the macros merged as soon as possible, and focus on
upstreaming the work all the way to systemd as a follow-up.
Does this plan sound reasonable to the Fedora community? Are there
any serious concerns regarding the approach taken for the macros that
would cause them to be considered a complete no-go? Any scenarios
that I might have missed while implementing them?
Thanks for your patience in reading this far :) and looking forward
to your feedback!
[1] https://listman.redhat.com/archives/libvir-list/2023-January/237059.html
[2] https://bugzilla.redhat.com/show_bug.cgi?id=2210058
[3] https://listman.redhat.com/archives/libvir-list/2023-June/240226.html
[4] https://listman.redhat.com/archives/libvir-list/2023-July/240723.html
[5] https://listman.redhat.com/archives/libvir-list/2023-July/240729.html
--
Andrea Bolognani / Red Hat / Virtualization
8 months, 3 weeks
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
8 months, 3 weeks
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
8 months, 3 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
9 months
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.
9 months
RFC: Roadmap for DNF5 in Fedora 39 / invoking the Contingency Mechanism
by Fabio Valentini
Hi all,
I'm opening this thread to trigger discussion of the roadmap for DNF5
in Fedora 39 - whether the switch still looks doable for this release,
or whether it should be reverted for F39 and postponed to F40.
This is also being tracked in a FESCo ticket:
https://pagure.io/fesco/issue/3039
The DNF5 Change was approved with the condition that bits that are
important to the distribution *MUST* work, but this does not seem to
be the case yet, six months after this was initially approved -
there's at least a few things that are still using dnf-3 or have been
broken since the switch to dnf5:
- rawhide mock / koji builds still default to dnf-3 (DNF 4)
- Fedora CI has been partially broken since the switch to DNF5 (c.f.
[fedora-ci/general#416](https://pagure.io/fedora-ci/general/issue/416)),
making CI results for bodhi updates at least partially useless
- fedora-review has been broken since the switch to DNF5 (c.f.
[FedoraReview#482](FedoraReview/issue/482)), which is really hurting
the rate at which new packages are getting reviewed and added to
Fedora
- (not an exhaustive list, feel free to mention other things, I will
update the list to include them)
We are now mere days before the Fedora 39 mass rebuild is scheduled to
start, so I think it's time to start talking about the roadmap for
getting missing pieces into place for Fedora 39, or if that is not
possible within this timeframe, whether the contingency mechanism
should be enacted.
Fabio
9 months, 2 weeks
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
9 months, 2 weeks
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
9 months, 3 weeks
