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
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
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
8 months, 1 week
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.
8 months, 1 week
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
8 months, 3 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
8 months, 3 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
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
9 months
RFC authselect: mdns or mdns-minimal
by Pavel Březina
Hi Fedora,
I have this ticket opened against authselect:
https://github.com/authselect/authselect/issues/334
I am not user of mdns myself, so I wonder if non-minimal version of mdns
is something used and if it should be included in the authselect
profiles (or even replace the minimal version).
mdns support is already complicated since there are mdns, mdns4 and
mdns6 full and minimal versions of the module. Is it really required
nowadays? In might opinion, it might be good to move the logic out of
nsswitch into a configuration file.
Thank you for your feedback,
Pavel.
9 months