Re: [cfe-dev] Release 13.0.1-rc1 has been tagged
by Tom Stellard
On 1/1/22 12:54, Sean McBride wrote:
> On 30 Nov 2021, at 1:07, Tom Stellard via cfe-dev wrote:
>
>> Testers can begin testing and uploading binaries.
>
> It's been over a month since 13.0.1-rc1, and, as has been the case for many previous releases, there are no macOS binaries. And chance we'll see some?
>
This has been uploaded now.
-Tom
> Thanks,
>
> Sean
>
2 years, 4 months
Re: F36 Change proposal: No ifcfg by default (Self-Contained Change)
by Xose Vazquez Perez
Neal Gompa wrote:
>> On Wed, Jan 5, 2022 at 9:43 AM Sérgio Basto <sergio(a)serjux.com> wrote:
>> ...
>>
>> a big BTW when /etc/init.d/network will be removed or migrate to
>> systemd scripts ?
>>
>> rpm -qf /etc/init.d/network --qf "packge = %{sourcerpm}\nsub-package =
>> %{name}\n"
>>
>> packge = initscripts-10.09-1.fc34.src.rpm
>> sub-package = network-scripts
> It's deprecated and expected to be retired eventually. I doubt a
> "port" would ever happen.
initscripts is needed by audit: https://bugzilla.redhat.com/2029105
2 years, 4 months
How do we announce new packages?
by Eduard Lucena
Hello people.
First of all, I'm not a developer or a packager, I just try to help with
the little things I know to do. One thing I try to do is to check news,
forums, ML and places where people talk about Fedora.
A thing I noted is that a lot of people in magazines and news sites like
phoronix, hacker news and other sites follow this list to get news about
the project and it started to worry me that a big part of the traffic
follow orphaned and retired packages, but nothing is never
revealed/published when a new package enter the repositories or nothing
similar, maybe a review swap but it's not enough.
Trying to market the number of packages, the amount of free and open source
software that we offer, how this could be measured and published? Is that
something that require to much work?
Br,
--
Eduard Lucena
Móvil: +56962318010
GNU/Linux User #589060
Ubuntu User #8749
Fedora Marketing Representative
2 years, 4 months
F36 Change: PostgreSQL 14 (Self-Contained Change proposal)
by Ben Cotton
https://fedoraproject.org/wiki/Changes/PostgreSQL_14
== Summary ==
Update of PostgreSQL (`postgresql` and `libpq` components) in Fedora
from version 13 to version 14 in the non-modular (main) builds.
== Owner ==
* Name: [[User:fjanus| Filip Januš]]
* Email: fjanus(a)redhat.com
== Detailed Description ==
Update of PostgreSQL (`postgresql` and `libpq` components) in Fedora
from version 13 to version 14 in the non-modular (main) builds.
This also involves updating and rebuilding the PostgreSQL plugins that
depend on postgresql server.
=== Plan ===
* Prepare PostgreSQL 14 in Copr (By 2022-01-15)
* Rebuild important dependencies in Copr (By 2022-01-15)
* Debug and fix compatibility issues found in dependencies (a
reasonable amount of non-critical in FTBFS state might be tolerable)
* Prepare Pull requests in Rawhide
* Merge and build PR into Rawhide
== Feedback ==
<!-- Summarize the feedback from the community and address why you
chose not to accept proposed alternatives. This section is optional
for all change proposals but is strongly suggested. Incorporating
feedback here as it is raised gives FESCo a clearer view of your
proposal and leaves a good record for the future. If you get no
feedback, that is useful to note in this section as well. For
innovative or possibly controversial ideas, consider collecting
feedback before you file the change proposal. -->
== Benefit to Fedora ==
The latest stable software is used by Fedora users.
== Scope ==
* Proposal owners:
<!-- What work do the feature owners have to accomplish to complete
the feature in time for release? Is it a large change affecting many
parts of the distribution or is it a very isolated change? What are
those changes?-->
**Prepare PostgreSQL 14
**Prepare PostgreSQL 13 as a module for Rawhide
**Check software that requires or depends on `postgresql-server` or
`libpq` packages for incompatibilities
**Build PostgreSQL 14 (postgresql and libpq) to Rawhide
**Rebuild depended on packages against PostgreSQL 14
**Gather user input on the changes between PostgreSQL 13 and PostgreSQL 14
* Other developers: N/A (not a System Wide Change)
* Release engineering: [https://pagure.io/releng/issues #Releng issue number]
* Policies and guidelines: N/A (not a System Wide Change)
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
The PostgreSQL client library (libpq component) is compatible. So,
there shouldn't be any issues with compatibility, but rebuild of the
depended components is recommanded.
Server plugins might require a newer version update, because they
sometimes have explicit server requirements. PostgreSQL maintainer
will help fixing/rebuilding any issues in the plugins.
== How To Test ==
Usual testing as when upgrading between major PostgreSQL versions,
running `postgresql-setup --upgrade` is necessary between major
versions.
Test that all other software runs well with PostgreSQL 14.
== User Experience ==
The users will have to upgrade their databases the same way as between
major PostgreSQL versions, aka `postgresql-setup --upgrade` after
installing PostgreSQL 14 server packages.
If users want to stick with PostgreSQL 13 for a little longer, there
will be PostgreSQL 13 module
== Dependencies ==
There are some packages (mostly server plugins), that build on top of
PostgreSQL. Since the separation of PostgreSQL client library (libpq
component), only packages that build server plugins should use
postgresql package in BuildRequires, others should use libpq. In case
of Postgresql-server, rebuild should be done to make sure all
potential binary incompatibilities are handled.
* PostgreSQL server dependecies
** perl-DBD-Pg
** pgaudit
** qt
** qt3
** qt5-qtbase
** postgres-decoderbufs
** gambas3
** kdb
** kea
** libpqxx
** openvas-manager
** orafce
** pg-semver
** pgRouting
** pgadmin3
** pgsphere
** postgis
** postgresql-ip4r
** postgresql-pgpool-II
** qt3
** rdkit
** rhdb-utils
** timescaledb
** pg_repack
== Contingency Plan ==
Revert changes in the non-modular packages and provide PostgreSQL 14
as a module stream only.
== Documentation ==
Upgrade strategy: https://www.postgresql.org/docs/14/upgrading.html
== Release Notes ==
Release notes for PostgreSQL 14 release:
https://www.postgresql.org/docs/14/index.html
Overall overview of the changes and improvements:
https://www.postgresql.org/docs/14/release-14.html
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
2 years, 4 months
F36 Change: New requirements for akmods binary kernel modules for
Silverblue / Kinoite support (Self-Contained Change proposal)
by Ben Cotton
https://fedoraproject.org/wiki/Changes/Binary_Kernel_Modules_rpm-ostree
== Summary ==
In order to improve the current support for akmods based binary kernel
modules in Silverblue/Kinoite, this change introduces a new dependency
in akmods to a meta package that strongly links the version of a
kernel package with its `-devel` sub-package.
== Owner ==
* Name: [[User:Siosm| Timothée Ravier]]
* Email: siosm(a)fedoraproject.org
* Name: [[User:Kwizart| Nicolas Chauvet]]
* Email: kwizart(a)fedoraproject.org
* Name: [[User:Tpopela| Tomáš Popela]]
* Email: tpopela(a)fedoraproject.org
== Detailed Description ==
Silverblue & Kinoite currently include the `kernel-devel` and
`glibc-devel` packages by default in the base image to work around
dependency issues when using akmods based binary kernel modules such
as the NVIDIA binary driver.
To be able to remove that dependency, a new meta-package has been
added as kernel sub-package to strongly link a given kernel with its
corresponding `-devel` sub-package that is needed for building those
kernel modules with akmods.
With this change, custom kernel builds outside of the fedora
repository will have to provide this new meta-package.
A longer explanation of how akmods based binary kernel modules are
supported in Silverblue / Kinoite is available in
https://src.fedoraproject.org/rpms/akmods/pull-request/3#comment-90939.
References:
* New `kernel{,-debug}-devel-matched` sub-packages:
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1195
* Dependency change in akmods:
https://src.fedoraproject.org/rpms/akmods/pull-request/3
* Dependency removal in Silverblue/Kinoite:
https://pagure.io/workstation-ostree-config/pull-request/214
== Feedback ==
See individual PRs for existing discussions.
== Benefit to Fedora ==
This change will noticeably reduce the size of the Silverblue /
Kinoite base image and updates for users that do not use any binary
kernel modules.
== Scope ==
* Proposal owners:
** Code changes are ready. Merging is in progress.
* Other developers:
** Custom kernel builds outside of the fedora repository will have to
provide this new meta-package.
* Release engineering: N/A (not needed for this Change)
* 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 ==
This should not impact existing systems on updates. Users already
using binary kernel modules will now have those dependencies
automatically installed. Other users will have them removed.
== How To Test ==
* Install an akmods based binary kernel module (NVIDIA driver from RPM
Fusion for example) on Silverblue/Kinoite once the changes mentioned
above are merged.
* This should work just like it does on F35.
== User Experience ==
There should be no change in user experience.
== Dependencies ==
N/A
== Contingency Plan ==
* Contingency mechanism: Revert to previous behavior
* Contingency deadline: Beta freeze
* Blocks release? No
== Documentation ==
N/A (not a System Wide Change)
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
2 years, 4 months
