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, 2 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, 2 months
Orphaning luit
by Peter Hutterer
I've orphaned luit. The only user of it was xterm and it recently dropped
support for luit so there are no users left. Whether there are *any* users
left is unclear too :)
The luit package we shipped is still the freedesktop.org one which has been
unmaintained for about a decade now. Upstream now points to
Thomas Dickey's fork at http://invisible-island.net/luit/ so if anyone
wants to take this, I advise switching to that version as part of the first
steps.
Cheers,
Peter
2 years, 2 months
About how Go is updated in Fedora
by Alejandro Saez Morollon
I've been thinking a little about how Go is updated in Fedora. I would like
to hear other opinions about the current state of the releases and improve
it.
This is not related to the Fedora proposal that I'm planning to submit
today regarding the update of Go. I do not pretend to change anything for
the next Fedora release, but at least have an idea of if what we are doing
right now can be improved.
The current state:
Each Fedora release has a major release of Go available.
For example, Fedora 33 had 1.15, and Fedora 34 had 1.16.
The problem:
I see two main issues with this approach.
1. Both Go and Fedora have release cycles of 6 months, so the schedule
is a little tight. Go releases can be delayed and have issues in the mass
rebuild phase.
2. A user needs to wait for the next Fedora release to get a new major
version of Go. So consequentially, they will tend to download from
upstream, making the Go package just necessary for dependencies but with
little use on its own. Also, backport bugs to Fedora releases might be a
problem. Releasing packages that depend on new features are an issue too
[0].
What I think is an improvement:
Suppose a new Go major version is released in the middle of a Fedora life
cycle. In that case, I think it is an improvement for the user to be able
to update to the following Go release.
A hypothetical new release cycle would look like this:
- Fedora N release follows Go upstream as close as we can.
- Fedora N-1 sticks with the latest major version of Go that was
available on it until the release of Fedora N.
Another hypothetical approach could be using modules with each upstream
supported release in a stream.
To help in the decision, I made a report tool/web page [1] that shows the
current state of the packages that depend on Go (Thanks to the COPR API).
It compares the builds of every single Go dependent package in Fedora 35
using the current available Go package with the same list of Go packages
but using the Go package is available on Fedora Rawhide. To rephrase it, it
compares Fedora 35 packages built with Go 1.16 with Fedora 35 packages
built with Go 1.17.
As you can see, right now, from the 1901 packages that depend on Go, 196
have some sort of change and 1705 built exactly the same. You can search
for "Same results" or "Something has changed" to see this. Or by the name
of the package.
The report is not smart enough to say what happened right now so some
"issues" are in fact improvements like golang-github-cactus-statsd-client,
others like golang-github-briandowns-spinner are real issues.
My idea is to improve this report with your suggestions. Hence, if a new Go
major release is available, we can confidently say that the package can be
updated in the middle of a Fedora release.
[0] https://github.com/containers/podman/pull/12544
[1] https://alexsaezm.fedorapeople.org/report.html -> let it load, it has a
JS that allows you to search
2 years, 2 months
F36 Change: Hunspell Dictionary dir change (System-Wide Change proposal)
by Ben Cotton
https://fedoraproject.org/wiki/Changes/Hunspell_dictionary_dir_change
== Summary ==
Update Hunspell Dictionary system directory from /usr/share/myspell/
to /usr/share/hunspell/
== Owner ==
* Name: [[User:vishalvvr| Vishal Vijayraghavan]]
* Email: <vishalvvr(a)fedoraproject.org>
== Detailed Description ==
In most of Linux distributions the standard Hunspell dictionary path
is `/usr/share/hunspell/` but in Fedora still has
`/usr/share/myspell/`. This effort is to follow default standard to
install all Hunspell dictionary into `/usr/share/hunspell/` instead of
`/usr/share/myspell/`.
== Benefit to Fedora ==
This will future proof Fedora to use the correct current location for
hunspell spelling dictionaries.
== Scope ==
* Proposal owners:
In total there are `135` packages which is to be updated. libreoffice
& Firefox are the two main applications and rest are mostly language
dictionary packages.
* Other developers:
* 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 ==
== How To Test ==
1. Check if default installed dictionary path is
`/usr/share/hunspell/` instead of `/usr/share/myspell/`
`$ hunspell -D` or `$ ls /usr/share/hunspell/`
2. Install any language dictionary and check if it getting installed
into '/usr/share/hunspell/'
`$ dnf install hunspell-hi`
`$ hunspell -D`
== User Experience ==
User should not notice any difference: their applications should
continue to work as expected after this directory migration.
== Dependencies ==
== Contingency Plan ==
* Contingency mechanism: revert release back to /usr/share/myspell
* Contingency deadline: Beta
* Blocks release? No
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
2 years, 2 months
F36 Change: %set_build_flags for %build and %check (System-Wide
Change proposal)
by Ben Cotton
https://fedoraproject.org/wiki/Changes/SetBuildFlagsBuildCheck
== Summary ==
Call %set_build_flags macro automatically at the beginning of the
%build and %check phases of RPM builds in Fedora Linux. This will
ensure that the compiler flag environment variables are set for every
RPM build.
== Owner ==
* Name: [[User:tstellar| Tom Stellard]]
* Email: <tstellar(a)redhat.com>
== Detailed Description ==
The %set_build_flags macro exports common environment variables used
for building packages:
* CFLAGS
* CXXFLAGS
* FFLAGS
* FCFLAGS
* LDFLAGS
* LT_SYS_LIBRARY_PATH
* CC
* CXX
These environment variables are set to the compiler flags defined in
the system RPM configuration. This macro is currently implicitly
called when packages use some of the build system helper macros, like
%configure, %cmake, and %meson. However, not all packages use these
macros and so some packages do not use the correct compiler flags as
required by the Fedora packaging guidelines[1].
This change will be implemented by updating the %__spec_build_pre and
%__speck_check_pre macros in redhat-rpm-config to include
%set_build_flags. This will set these environment variables
automatically before the %build and %check sections. See the proposed
[https://src.fedoraproject.org/fork/tstellar/rpms/redhat-rpm-config/c/a397...
implementation] for more details.
The purpose for making this change in both the %build and %check
sections is because sometimes test code gets built in the %check
sections for unit tests and this will ensure that the application code
and its tests are built with the same set of flags.
This change should have no impact on packages that already use
%set_build_flags either directly or indirectly through another macro.
It also won't impact any package that currently sets these environment
variables or modifies any of the %{build*_flags} macros in their
%build or %check sections.
[1] https://docs.fedoraproject.org/en-US/packaging-guidelines/#_compiler_flags
== Benefit to Fedora ==
This change will ensure that more packages are built using the correct
compiler flags, and bring them in compliance with the Fedora packaging
guidelines. It will also help improve the security of the
distribution as many of the compiler flags help defend against common
security attacks.
== Scope ==
* Proposal owners:
** Make the necessary changes to redhat-rpm-config.
** Help debug any issues uncovered by this change during the mass rebuild.
* Other developers:
** Report bugs to the proposal owner.
* Release engineering: [https://pagure.io/releng/issue/10482 #10482]
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives:
== How To Test ==
This change will be tested by rebuilding packages as part of the mass rebuild.
== User Experience ==
This change will make some packages less susceptible to security exploits.
== Contingency Plan ==
* Contingency mechanism: The proposal owner will revert the change in
redhat-rpm-config
* Contingency deadline: Beta Freeze
* Blocks release? No
== Documentation ==
None needed.
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
2 years, 2 months
Heads-up: lxqt libraries soname bump
by Zamir SUN
Hi,
I'm updating the whole LXQt desktop to 1.0.0 in rawhide, and I've built
the packages in the side tag f36-build-side-49104. The following package
contains library with a soname bump
liblxqt (liblxqt.so.1)
liblxqt-globalkeys (liblxqt-globalkeys.so.1,liblxqt-globalkeys-ui.so.1)
I hope I did not miss anything. IIRC there are no packages outside of
the LXQt SIG depends on those, but I'd like to still make people aware
of the change and possible other packages I missed.
I'll merge the side tag by the last day of the year.
HTH.
--
Zamir SUN
GPG : 1D86 6D4A 49CE 4BBD 72CF FCF5 D856 6E11 F2A0 525E
Want to know more about Fedora?
Visit https://fedoraproject.org/wiki/
Ready to contribute? See https://whatcanidoforfedora.org/
想了解更多中文资讯,访问 https://zh.fedoracommunity.org/
2 years, 2 months