Hi,
A fonts packaging policy rewrite proposal has been pushed to FPC today:
https://pagure.io/packaging-committee/pull-request/934
It should be clearer, more opinionated, and take into account:
– updates of The OpenType standard
– variable fonts
– web fonts
– upstream depreciation of non OpenType formats: final stages of the
Harfbuzz consolidation decided at the 2006 Text Layout summit
https://www.freedesktop.org/wiki/TextLayout/
– appstream & fonts
– weak dependencies
– and probably more I forget here
It is based on the new fonts-rpm-macros project for automation:
This project builds on tooling enhancements in redhat-rpm-config and rpm
itself, done during the past two years for the Forge and Go sets of
packaging macros. It started 2 years ago as a fork of fontpackages,
which is the core of our current fonts packaging guidelines.
It will require putting the fonts-srpm-macros package in the default
build root, like is done for other domain-specific packaging macro
sets.
Major additions:
– better documentation (clearer and more complete)
– better automation (less packager hassle for better and more complete
results)
Major removals:
– tools and scripts
– fixing metadata with ttname
Mostly because no one seems willing to maintain those scripts, or port
ttname to python 3.
https://copr.fedorainfracloud.org/coprs/nim/fonts-rpm-macros/builds/
showcases the new policy on 62 real-world source packages, generating
139 installation packages. Some of those are badly delayed updates to
Fedora packages, others are brand-new packages ready for Fedora
inclusion. They include major font packages such as Stix, DejaVu, Droid,
IBM Plex.
Existing Fedora packages will continue to build, the old fontpackages
macros are grandfathered in fonts-rpm-macros for now. They will be
removed in a few years to give packagers time to apply the new
guidelines.
Regards,
--
Nicolas Mailhot
Dear maintainers.
Based on the latest fail to build from source policy, the following packages
will be retired from Fedora 32 approximately one week before branching (2020-02-03).
Policy:
https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fails…
The packages in rawhide were not successfully built at least since Fedora 30.
This report is based on dist tags.
Packages collected via:
https://github.com/hroncok/fedora-report-ftbfs-retirements/blob/master/ftbf…
If you see a package that was built, please let me know.
If you see a package that should be exempted from the process, please let me
know and we can work together to get a FESCo approval for that.
There is an open exception request for shim-unsigned-aarch64 and
shim-unsigned-x64, but it has not yet been approved -- if it gains no negative
votes within 1 day, it will be:
https://pagure.io/fesco/issue/2331
If you see a package that can be rebuilt, please do so.
Package (co)maintainers Latest build
================================================================================
elasticsearch hubbitus, jvanek, lbazan, Fedora 24
zbyszek
expresso jamielinux, nodejs-sig, Fedora 28
patches
libocrdma ocrdma Fedora 27
nuvola-app-google-calendar martinkg Fedora 29
nuvola-app-groove martinkg Fedora 28
nuvola-app-logitech-media- martinkg Fedora 29
server
nuvola-app-plex martinkg Fedora 29
nuvola-app-soundcloud martinkg Fedora 29
nuvola-app-yandex-music martinkg Fedora 29
shim-unsigned-aarch64 pjones (exception request) Fedora 28
shim-unsigned-x64 pjones (exception request) Fedora 28
The following packages require above mentioned packages:
Depending on: expresso (1)
nodejs-chrono (maintained by: jamielinux, nodejs-sig, tomh)
nodejs-chrono-1.0.5-10.fc31.src requires npm(expresso) = 0.9.2
Affected (co)maintainers
hubbitus: elasticsearch
jamielinux: expresso
jvanek: elasticsearch
lbazan: elasticsearch
martinkg: nuvola-app-soundcloud, nuvola-app-logitech-media-server,
nuvola-app-yandex-music, nuvola-app-groove, nuvola-app-google-calendar,
nuvola-app-plex
nodejs-sig: expresso
ocrdma: libocrdma
patches: expresso
pjones: shim-unsigned-aarch64, shim-unsigned-x64
tomh: expresso
zbyszek: elasticsearch
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
---------- Forwarded message ---------
From: Kevin Fenzi <kevin(a)scrye.com>
Date: Fri, Jan 31, 2020, 03:40
Subject: Mass rebuild reminders
To: <devel(a)lists.fedoraproject.org>
Just a few reminders for folks:
* If your package failed to build in the mass rebuild
( https://kojipkgs.fedoraproject.org/mass-rebuild/f32-failures.html )
and you want to fix it, please do so. Just do a normal commit/build
cycle for rawhide as you normally would. It should disappear from the
above list and no FTBFS bug will be filed.
* If you want to fix something else or update a package or whatever,
just do it as normal. The script that tags the mass rebuild back in will
see a newer build and not tag in the one from the mass rebuild.
* There were some failures on s390x at the beginning of the mass
rebuild. We will try and resubmit these after the mass rebuild is
done. You're welcome to resubmit them (make sure you resubmit or do a
new build in the f32-rebuild tag, not the normal tag) also anytime. The
above link should update and they will have no FTBFS filed for them.
kevin
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
FYI...
NFS over UDP will be deprecated in the 5.6 kernel.
https://bugzilla.redhat.com/show_bug.cgi?id=1794117
Its not clear what or if any havoc this could cause
but the commit (f745bfdc) has been accepted upstream.
Just letting the community know...
If by chance a bz is opened, please feel free to send me a
private email with the link... As we all know Bugzilla
is just another word for... spam! ;-)
steved.
Good Morning Everyone,
We are pleased to announce that the work to gate rawhide packages has leveled
up!
Back in July we announced the first phase where bodhi got the support to gate
single-build updates. We can now officially announce that bodhi can gate
multi-builds updates. This is achieved through the use of side-tags, which can
be created on demand via ``fedpkg request-side-tag``. The package can then be
built using ``fedpkg build --target=<your side-tag>`` or via ``fepdkg
chain-build --target=<your side-tag>``. Once all your packages are built, you
can create a bodhi update from this side-tag using either the ``Use Side-Tag``
drop-down or in the CLI by using the ``--from-tag`` argument to the ``bodhi
updates new`` command.
Every build in the update will then be tested by the CI system which will report
the outcome. Bodhi will then query greenwave which will rely on the collection
of these individual results to make a decision about whether to gate the update
or not.
More detailed documentation is available at:
- https://fedoraproject.org/wiki/Package_update_HOWTO
- https://docs.fedoraproject.org/en-US/rawhide-gating/
Note: this is not the end of rawhide-gating. We still have some changes planned
to make it easier for greenwave to make a decision about an update containing
multiple builds, we want to improve the documentation for on-boarding new CI
systems and make them matter for rawhide as well as for stable releases.
We then have all the work ahead to improving our tests, including enabling some
of them distribution-wide, looking at the reverse dependencies or testing for
the impact of an update on our composes.
Looking forward for your feedback!
Pierre
For the rawhide gating team
https://fedoraproject.org/wiki/Changes/PostgreSQL_12
== Summary ==
Update of PostgreSQL (`postgresql` and `libpq` components) in Fedora
from 11 to 12 version in the non-modular (main) builds.
== Owner ==
* Name: [[User:panovotn| Patrik Novotny]]
* Email: panovotn(a)redhat.com
== Detailed Description ==
Update of PostgreSQL (`postgresql` and `libpq` components) in Fedora
from 11 to 12 version in the non-modular (main) builds.
This also involves updating and rebuilding the PostgreSQL plugins that
depend on postgresql server.
== Benefit to Fedora ==
Latest stable software is used by Fedora users.
Version v12 of PostgreSQL introduces several enahncements and
performance improvementes:
https://www.postgresql.org/about/news/1976/
== Scope ==
* Proposal owners:
**Prepare PostgreSQL 12 as a module for Rawhide and at least one
stable Fedora release (done)
**Prepare PostgreSQL 11 as a module for Rawhide, so there would be a
failover in case of problems
**Build PostgreSQL 12 to Rawhide
**Check software that requires or depends on `postgresql-server` or
`libpq` packages for incompatibilities
**Gather user input on the changes between PostgreSQL 11 and PostgreSQL 12
* Other developers: N/A (not a System Wide Change)
* Policies and guidelines: N/A
* 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, but rebuild of the depended components
is better to be sure.
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 12.
== User Experience ==
The users will have to upgrade their databases the same way as between
major PostgreSQL versions, aka `postgresql-setup --upgrade`.
If users want to stick with PostgreSQL 11 for a little longer, there
should be PostgreSQL 11 module.
If users want to test it before it reaches Fedora 32, there is
PostgreSQL 12 module already.
== 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 both
the cases, rebuild should be done to make sure all potential binary
incompatibilities are handled.
== Contingency Plan ==
Modules will provide the functional version of PostgreSQL 11,
available to all users.
* Contingency mechanism: Fedora Modules available
* Contingency deadline: beta freeze
* Blocks release? N/A (not a System Wide Change)
* Blocks product? N/A (not a System Wide Change)
== Documentation ==
Upgrade startegy: https://www.postgresql.org/docs/12/upgrading.html
== Release Notes ==
Release notes for PostgreSQL 12 release:
https://www.postgresql.org/docs/12/index.html
Overall overview of the changes and improvements:
https://www.postgresql.org/about/news/1976/
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
https://fedoraproject.org/wiki/Changes/Python3-rdiff-backup
== Summary ==
rdiff-backup is a python based backup tool. While development stopped
for many years, it's now resumed upstream and a python3 port has been
(almost) completed. Unfortunately, the python2 and python3 versions
will not interoperate, although backups made with either version are
compatible. Because of this we want to push the new python3 based
rdiff-backup to all supported releases when Fedora 32 is released.
== Owner ==
* Name: [[User:Kevin| Kevin Fenzi]] and [[User:FrankCrawford| Frank Crawford]]
== Detailed Description ==
We want to move to the upstream supported python3 version, but we want
to make sure people with mixed infrastructures are able to upgrade all
their hosts with the new version so they continue to interoperate, as
there are numerous incompatibilities between the python2 and python3
program implementation, such as default string types and pickle
definitions.
Like most backup programs, it is a long term commitment by the user
and the end of life of python2 has forced a migration to a python3 for
the code. This will allow rdiff-backup repositories to continue to be
used going forward.
== Benefit to Fedora ==
Old, no longer maintained python2 version will be replaced with new
2.0.0 python3 version.
This update will also allow a number of locally maintained patches to
be dropped as they have now been incorporated into the revitalised
upstream project.
This is also a major upgrade to this backup software and is the
primary Linux distribution of the current developer, and will put
Fedora in a good position to introduce new features going forward.
== Scope ==
* Proposal owners:
# Test beta releases via rawhide and COPR (completed for first beta
release, planned for upcoming beta releases).
# Gather feedback from this testing (in progress).
# Wait for final 2.0.0 release. This is planned for Feb 2020.
# Once f32 is out, push EPEL and older stable releases as well (due to
compatibility issues).
* Other developers: N/A (not a System Wide Change)
* Policies and guidelines: N/A
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
Previous Python2 versions are not interoperable with the new Python3
version, when used for remote operation, however, the actual backups
are compatible between the two. This does require that all hosts used
for remote operations are upgraded at the same time to continue to
perform remote operations.
== How To Test ==
N/A (not a System Wide Change)
== User Experience ==
rdiff-backup will stop working in Fedora with the retirement of
python2 and users will need to move to a new backup setup.
== Documentation ==
N/A (not a System Wide Change)
== Release Notes ==
Existing backups are compatible between older (v1.2.8/v1.3.x) and new
(v2.0.0) versions of rdiff-backup, however, remote operations are not
and require all hosts to use either the python2 (i.e. v1.2.8/v1.3.x)
or python3 (v2.0.0) version. However, as python2 is now end-of-life,
there is no further development on the older version and all future
patches will be performed on the python3 version.
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis