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.
There will be an outage starting at 2009-07-01 01:00 UTC, which will last
approximately 2 hours.
To convert UTC to your local time, take a look at
http://fedoraproject.org/wiki/Infrastructure/UTCHowto
or run:
date -d '2009-07-01 01:00 UTC'
Affected Services:
Buildsystem
CVS / Source Control
Unaffected Services:
Database
DNS
Fedora Hosted
Fedora People
Fedora Talk
Mail
Mirror System
Torrent
Translation Services
Websites
Ticket Link:
https://fedorahosted.org/fedora-infrastructure/ticket/1496
Reason for Outage:
Final migration step for new cvs server. It will hopefully be offline for
only 30-45 minutes. The additional time is for some further tuning if
needed and some verification steps.
Contact Information:
Please join #fedora-admin in irc.freenode.net or respond to this email to
track the status of this outage.
_______________________________________________
Fedora-devel-announce mailing list
Fedora-devel-announce(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-announce
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
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
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_for…
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
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
(I realized I hadn't subscribed to f-devel with this email ID, and this
message didn't make it to devel. Resending.)
On Thu, 2023-06-15 at 13:59 +0200, Amit Shah wrote:
> Hey Nick,
>
> I submitted
>
> https://src.fedoraproject.org/rpms/binutils/pull-request/47
>
> yesterday to not build gold by default.
>
> Creating this thread here to ensure you see this, and also a chance to
> discuss the change via email rather than on the PR.
>
> Cheers,
>
> Amit
https://fedoraproject.org/wiki/Changes/perl5.38
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 ==
A new ''perl 5.38'' version brings a lot of changes done over a year
of development. Perl 5.38 will be released in May 20th 2023. See
[https://metacpan.org/release/SHAY/perl-5.37.11/view/pod/perldelta.pod
perldelta for 5.37.11] for more details about new release.
== Owner ==
* Name: [[User:Jplesnik| Jitka Plesníková]], [[User:Mspacek| Michal
Josef Špaček]]
* Email: <jplesnik(a)redhat.com>, <mspacek(a)redhat.com>
== Current status ==
=== Completed Items ===
=== Items in Progress ===
=== Items to Be Done ===
* Get dedicated build-root from rel-engs (''f39-perl'')
* Upstream to release Perl 5.38
* Define perl_bootstrap in perl-srpm-macros
* Rebase perl to 5.38.0
* Rebuild all dual-lived packages (83) - otherwise dnf recommends
--skip-broken and fails
* Rebuild packages needed for minimal build-root
* Rebuild packages needed for building source packages from git repository
* Rebuild packages requiring ''libperl.so'' or versioned
''perl(MODULE_COMPAT)'': Use Fedora::Rebuild dependency solver
* Undefine perl_bootstrap
* Rebuild packages having perl_bootstrap condition in spec file (XX packages)
* Rebuild all updated packages
* [https://jplesnik.fedorapeople.org/5.38/ Final lists of results]
* Merge dedicated build-root to rawhide and remove the dedicated one by rel-engs
* Synchronize packages upgraded in ''f39'' build root
* Rebuild Perl packages: 0 of 600 done (0 %)
* Failed packages (0):
* Rebuild Fedora modules: 0 of 0 (0 %)
* Create module perl:5.38 and rebuild dependencies
== Detailed Description ==
New perl is released every year and updates containing mainly bug
fixes follow during the year. The 5.38.0 version is stable release
this year.
== Benefit to Fedora ==
Up-to-date and latest perl release will be delivered to Fedora users.
== Scope ==
Every Perl package will be rebuilt in a dedicated ''f39-perl''
build-root against perl 5.38.0 and then if no major problem emerges
the packages will be merged back to ''f39'' build-root.
* Proposal owners: New perl and all packages requiring ''libperl.so''
or versioned ''perl(MODULE_COMPAT)'' will be rebuilt into ''f39-perl''
build-root.
* Other developers: Owners of packages that fail to rebuild, mainly
perl-sig users, will be asked using Bugzilla to fix or remove their
packages from the distribution.
* Release engineering: [https://pagure.io/releng/issues #Releng issue
number] <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
Release engineers will be asked for new ''f39-perl'' build-root
inheriting from ''f39'' build-root. After successful finishing the
rebuild, they will be asked to merge ''f39-perl'' packages back to
''f39'' build-root.
* 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 ==
Vast majority of functionality will be preserved. Only the packages
that failed to build against perl 5.38 will be removed from the
distribution. That will require to remove those packages from the
existing systems otherwise a package manager will encounter
unsatisfied dependencies. The developers in Perl language are advised
to install ''perl-doc'' and ''perl-debugger'' packages.
== How To Test ==
Try upgrading from Fedora 38 to 39. Try some Perl application to
verify they work as expected. Try embedded perl in
[https://src.fedoraproject.org/rpms/openldap slapd] or
[https://src.fedoraproject.org/rpms/net-snmp snmpd].
== User Experience ==
There should not be any remarkable change in user experience. With the
exception that previously locally installed modules with a CPAN
clients will need a reinstallation.
== Dependencies ==
There is more than 3500 packages depending on perl. It is the first
rebuild where we will rebuild only all dual-lived packages and
packages which require ''libperl.so'' or versioned
''perl(MODULE_COMPAT)''. It means only about 600 packages needs to
rebuild. Most of them are expected not to break. Finishing this change
can be endangered only by critical changes in a toolchain.
''noarch'' packages don't need to be rebuilt now.
== Contingency Plan ==
* Contingency mechanism: If we find perl 5.38 is not suitable for
Fedora 39, we will revert back to perl 5.36 and we drop the temporary
build-root with already rebuilt packages.
* Contingency deadline: branching Fedora 39 from Rawhide.
* Blocks release? No.
== Documentation ==
* 5.38.0 perldelta
* An announcement on perl-devel mailing list
* An announcement on fedora-devel mailing list
== Release Notes ==
TBD
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
Hi,
Apache Arrow 10.0.0 has been released.
At present nobody is using libarrow except Ceph. (Which I am the maintainer
of.)
I will be rebasing libarrow to 10.0.0 within the next couple of days.
--
Kaleb