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
Good Morning Everyone™,
we have recently spent some time refactoring, improving and fixing the script
that syncs the default assignee and CC list from dist-git to Bugzilla.
Since the script was broken for some time, we felt that it needs some validation
before we run it live (which will still require some work).
We have uploaded the results at:
https://pingou.fedorapeople.org/distgit_bugzilla_sync.log
(Note that this only shows what would be updated.)
We'd appreciate it if you could take some time and check the changes affecting
you and report any issues you might find.
An easy way to do this is downloading the file and grepping for your FAS
username.
Thanks in advance for your help,
Pierre
Apologies for the last minute nature of this outage, the details
behind the upgrade were under debate and we didn't want to announce a
time until we were sure about what was going to happen when.
Seeing as the machines are running F29, they need to be upgraded as
it's going EOL today.
Tim
------------------------------------------------------------
There will be an outage starting at 2019-11-26 21:00 UTC, which will
last approximately 3 hours.
To convert UTC to your local time, take a look at
https://fedoraproject.org/wiki/UTCHowto or run:
date -d '2019-11-26 19:00 UTC'
Reason for outage:
We will be upgrading the servers which host Taskotron and ResultsDB to
newer versions of Fedora.
Affected Services:
Taskotron, ResultsDB and anything which uses ResultsDB as a data source
(Bodhi, gating etc.)
Ticket Link:
https://pagure.io/fedora-infrastructure/issue/8420
Contact Information:
Please join #fedora-admin in irc.freenode.net or add comments to the
ticket for this outage above.
Hello all,
As of the 26th of November 2019, Fedora 29 has reached its end of life for
updates and support. No further updates, including security updates,
will be available for Fedora 29. Fedora 30 will continue to receive
updates until
approximately one month after the release of Fedora 32. The
maintenance schedule of Fedora releases is documented on the Fedora
Project wiki [0]. The Fedora Project wiki also contains instructions
[1] on how to upgrade from a previous release of Fedora to a version
receiving updates.
Mohan Boddu.
[0] https://fedoraproject.org/wiki/Fedora_Release_Life_Cycle#Maintenance_Schedu…
[2] https://docs.fedoraproject.org/en-US/quick-docs/dnf-system-upgrade/
Good Morning Everyone,
Tomorrow we are planning on deploying a new version of pagure and
pagure-dist-git on production.
These changes come with two changes to the packager workflow:
* Anitya integration in dist-git
Something we lost when loosing pkgdb was the easy integration to anitya
(https://release-monitoring.org) With the coming changes we are getting them
back.
On the left hand-side column, there will be a drop-down button allowing to
change the settings for anitya for the project.
Existing status will be migrated from the fedora-scm-requests repo on pagure to
use this drop-down.
Using the fedora-scm-requests repo for the anitya integration will no longer be
supported.
* Change in the de-orphaning process
Currently if a package is orphaned, one has to open a ticket against the releng
project to adopt it. With these changes, anyone will be able to adopt orphaned
projects (not retired on master) directly from dist-git's UI.
If the project is retired or has been orphaned for too long, a ticket on the
releng project will still be required though.
Both of these changes can already be reviewed in staging at:
https://src.stg.fedoraproject.org
Looking forward for your feedback!
Pierre
https://fedoraproject.org/wiki/Changes/PythonNoSemanticInterpositionSpeedup
Simplified version of another change proposal|This change was
originally proposed for [[Releases/32|Fedora 32]] as
[[Changes/PythonStaticSpeedup]], however based on
[https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org…
community feedback], it has been significantly reduced.
== Summary ==
We add the <code>-fno-semantic-interposition</code> compiler/linker
flag when building Python interpreters, as it provides significant
performance improvement, up to 27% depending on the workload. Users
will no longer be able to use LD_PRELOAD to override a symbol from
libpython, which we consider a good trade off for the speedup.
== Owner ==
* Name: [[User:Cstratak| Charalampos Stratakis]], [[User:Vstinner|
Victor Stinner]], [[User:Churchyard| Miro Hrončok]]
* Email: python-maint(a)redhat.com
* Shout-out: [[User:Jankratochvil|Jan Kratochvíl]] for first
suggesting this instead of the original proposal, followed by
[[User:Kkofler|Kevin Kofler]]. [[User:Fweimer|Florian Weimer]] for
providing answers to our questions. David Gray for originally
suggesting to link Python statically to gain performance.
== Detailed Description ==
When we build the Python interpreter with the
<code>-fno-semantic-interposition</code> compiler/linker flag, we can
achieve a performance gain of 5% to 27% depending on the workload.
Link time optimizations and profile guided optimizations also have a
greater impact when python3 is built this way.
As a negative side effect, it disables the LD_PRELOAD feature: it's no
longer possible to override symbols in libpython with LD_PRELOAD.
Interposition is enabled by default in compilers like GCC: function
calls to a library goes through a "Procedure Linkage Table" (PLT).
This indirection is required to allow a library loaded by LD_PRELOAD
environment variable to override a function. The indirection puts more
pressure on the CPU level 1 cache (instruction cache). In term of
performance, the main drawback is that function calls from a library
to the same library cannot be inlined, to respect the interposition
semantics. Inlining is usually a big win in term of performance.
Disabling interposition for libpython removes the overhead on function
calls by avoiding the PLT indirection, and allows to inline more
function calls. We're describing function calls from libpython to
libpython, something which is very common in Python: almost all
function calls are calls from libpython to libpython.
If Fedora users need to use LD_PRELOAD to override symbols in
libpython, the recommend way is to build a custom Python without
<code>-fno-semantic-interposition</code>.
It is still possible to use LD_PRELOAD to override symbols in other
libraries (for example in glibc).
=== Affected Pythons ===
Primarily, we will change the interpreter in the {{package|python3}}
package, that is Python 3.8 in Fedora 32 and any later version of
Python in future Fedora releases.
Impact on other Python packages (and generally software using Python)
is not anticipated (other than the possible speedup).
We will also change the
[https://developer.fedoraproject.org/tech/languages/python/multiple-pythons.…
alternate Python interpreters] where possible and useful, primarily
the upstream supported versions of CPython, such as
{{package|python39}} (if already packaged), {{package|python37}} and
{{package|python36}}.
=== Affected Fedora releases ===
This is a Fedora 32 change and it will be implemented in Rawhide
(Fedora 32) only. Any future versions of Fedora will inherit the
change until it is reverted for some reason.
If it turns out that there are absolutely no issues, we might consider
backporting the speedup to already released Fedora versions (for
example Fedora 31). Such action would be separately coordinated with
[https://docs.fedoraproject.org/en-US/fesco/ FESCo].
== Benefit to Fedora ==
Python's performance will increase significantly depending on the
workload. Since many core components of the OS also depend on Python
this could lead to an increase in their performance as well, however
individual benchmarks will need to be conducted to verify the
performance gain for those components.
[https://pyperformance.readthedocs.io/ pyperformance] results,
ignoring differences smaller than 5%:
(See change proposal)
== Scope ==
* Proposal owners:
** Review and merge the
[https://src.fedoraproject.org/rpms/python3/pull-request/151 pull
request with the implementation].
** Monitor Koschei for significant problems.
** Backport the change to alternate Python versions.
* Other developers are encouraged to check if their package works as expected
* Release engineering: N/A (not needed for this Change) -- this change
does not require a mass rebuild nor any other special releng work
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
Python package maintainers should verify that their packages work as
expected and the only impact the end users should see is a performance
increase for workloads relying on Python.
== How To Test ==
Test that everything Python related in Fedora works as usual.
=== Was the flag applied test ===
You can test whether the <code>-fno-semantic-interposition</code> flag
was applied for your Python build:
<pre>
>>> import sysconfig
>>> '-fno-semantic-interposition' in (sysconfig.get_config_var('PY_CFLAGS') + sysconfig.get_config_var('PY_CFLAGS_NODIST'))
True
>>> '-fno-semantic-interposition' in (sysconfig.get_config_var('PY_LDFLAGS') + sysconfig.get_config_var('PY_LDFLAGS_NODIST'))
True
</pre>
Before the change, you would see <code>False</code>, <code>False</code>.
=== Performance test ===
The performance speedup can be measured using the official Python
benchmark suite [https://pyperformance.readthedocs.io/ pyperformance]:
see [https://pyperformance.readthedocs.io/usage.html#run-benchmarks
Run benchmarks].
== User Experience ==
Python based workloads should see a performance gain of up to 27%.
== Dependencies ==
This change is not dependent on anything else.
== Contingency Plan ==
* Contingency mechanism: If issues appear that cannot be fixed in a
timely manner the change can be easily reverted and will be considered
again for the next fedora release.
* Contingency deadline: Before the beta freeze of Fedora 32 (2020-02-25)
* Blocks release? Yes
* Blocks product? None
== Documentation ==
This change proposal has all the documentation.
See the [[Changes/PythonStaticSpeedup|previous change proposal]] and
the [https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org…
thread about it on the devel mailing list] for more relevant
information about what we are not doing
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
https://fedoraproject.org/wiki/Changes/Move_apt_package_from_RPM_to_DPKG_ba…
== Summary ==
Currently the apt package in Fedora actually installs apt-rpm,
starting with Fedora 32 it will provide the regular apt software
backed by DPKG.
== Owner ==
* Name: [[User:dridi| Dridi Boukelmoune]], [[User:ngompa | Neal Gompa]]
* Email: dridi(a)fedoraproject.org, ngompa13(a)gmail.com
== Detailed Description ==
The apt package in Fedora does not ship the mainline apt software from
Debian, but rather the apt-rpm fork instead. This allows a user to
copy and paste apt or apt-get commands often found in "Linux"
tutorials. This will usually work, apt-rpm will resolve dependencies
from the Yum/DNF repositories and since our package naming guidelines
often lead to the same package names as apt-based distributions like
Debian and Ubuntu.
The apt-rpm software is dead upstream and doesn't support rich
dependencies or modules. It also has known vulnerabilities and
according to its author other bugs that are never going to be fixed.
== Benefit to Fedora ==
By switching the Fedora apt package from apt-rpm to regular apt we
move from a dead to a living upstream. We also close security holes
and introduce a critical dependency for more packages from the DPKG
ecosystem. It is already possible to build Deb packages in Fedora,
including with pbuilder, an equivalent for mock in the DPKG ecosystem,
however pbuilder uses debootstrap to provision a build environment.
While we may lose the ability to "apt-get install" Fedora packages
from the command line, we also open the gate for sbuild, another mock
equivalent to build Debs in a clean environment. This change offers
more options to target Debian and derivative systems without leaving
the Fedora comfort zone.
== Scope ==
* Proposal owners: re-review of the apt package with the proper
upstream ([https://bugzilla.redhat.com/show_bug.cgi?id=1764813
RH#1764813]), and optionally more dependent packages.
* Other developers: N/A (not a System Wide Change)
* Release engineering: N/A (not needed for this Change)
* Policies and guidelines: As apt would conflict with DNF for the host
system, we may want to ship it without pre-configured repositories.
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
Any user actively relying on apt-rpm will lose functionality that
cannot be replaced. Because apt-rpm's version is much lower than the
current apt version, this change will follow the natural upgrade path.
== How To Test ==
If sbuild is packaged in time for the beta, performing builds with
sbuild should be enough to confirm that apt was able to provision a
build root.
== User Experience ==
Anyone used to paste apt-get commands in a terminal will no longer be
able to install or remove Fedora packages this way.
On the other hand anyone needing regular apt tooling will be able to
work with it directly from Fedora.
== Dependencies ==
Apt shouldn't bring more dependencies, it will be the dependency for
more packages from the DPKG ecosystem.
== Contingency Plan ==
* Contingency mechanism: Simply retire apt (apt-rpm)
* Contingency deadline: N/A (not a System Wide Change)
* Blocks release? N/A (not a System Wide Change)
* Blocks product? N/A
== Documentation ==
Once installed, apt ships multiple manual pages available in several
languages. There will no longer be any references in the shipped apt
package documentation of handling RPMs.
== Release Notes ==
The apt package has been rebased from apt-rpm to Debian's apt. This
means that apt no longer supports handling RPMs or managing RPM-based
systems. Please use dnf for software management of RPM-based systems
and containers.
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
https://fedoraproject.org/wiki/Changes/DisallowEmptyPasswordsByDefault
== Summary ==
Remove ''nullok'' parameter from pam_unix module in default PAM
configuration in order to disallow authentication with empty password.
== Owner ==
* Name: [[User:pbrezina| Pavel Březina]]
* Email: <pbrezina(a)redhat.com>
== Detailed Description ==
Current default configuration allows users to login with an empty
password by setting nullok parameter to pam_unix module. This affects
only logins to local machine, it does not affect ssh logins as this
must be explicitly allowed in sshd_config. We want to disallow empty
password by default for local logins as well to improve system
hardening.
Note: It is possible to disallow empty passwords with authselect call
(authselect enable-feature without-nullok) or by removing nullok
manually, however it creates possible issues in other components that
must be addressed.
=== Affected Components ===
* '''passwd''' - calling passwd -d to remove users password must be
denied if empty passwords are disallowed otherwise the user will be
locked out of the system
* '''AccountService''' - D-Bus methods ''SetPassword'' and
''SetPasswordMode'' on ''org.freedesktop.Accounts.User'' interface can
remove user’s password and lock the user out of the system if empty
password is disallowed. These calls must be denied in this case.
Additionally, these methods can be run by normal users as opposed to
''passwd -d'' and ''chage -d 0'' which can be run only by root.
Therefore only root should be able to call these methods.
* '''Gnome’s Control Center''' - when creating new users, it provides
an option to “require password to be set on first login” which creates
user with expired empty password. This would again lock the user out
of the system.
* '''Other Desktop Environments''' - may have the same issue as Gnome
Control Center
=== Solution Step by Step ===
==== Step 1) Provide a unified way to read if nullok is enabled or not ====
We will create an authselect library call that would parse existing
PAM configuration (not necessarily generated by authselect) and return
list of enabled/disabled features. We will implement only ''nullok''
feature in the scope of this change but if needed it can be extended
in the future.
==== Step 2) Fix passwd -d ====
Calling ''passwd -d'' to remove user's password will fail if
''nullok'' is disabled.
==== Step 3) Fix AccountService ====
These methods on ''org.freedesktop.Accounts.User'' D-Bus interface
will be callable only by ''root'' and must return an error if
''nullok'' is disabled.
SetPasswordMode
SetPassword(“”, hint)
==== Step 4) Fix Desktop Environments ====
“Require password change on next login” must keep working. This
feature currently relies on setting an empty password. A new option
''nullresetok'' will be implemented for ''pam_unix'' module that will
allow user to authenticate with empty password only if a password
change for this user is enforced upon login. Authentication with empty
passwords which are not expired will be prohibited (unless ''nullok''
is set).
==== Step 5) Update PAM configuration to disable nullok by default ====
In authselect and pam components for new installations. Upgrading from
older systems will keep nullok present.
== Benefit to Fedora ==
Changes in described components (Step 1 - Step 4) are necessary to
implement in order to make sure that user accounts and tools works
correctly when authentication with empty password is disabled by
system administrator. Changing system default to disallow
authentication with empty passwords (Step 5) improves system
hardening.
== Scope ==
* Proposal owners: Coordinate the work. Make sure all required changes
are implemented.
* Other developers: All affected component must be fixed. Changes are
described in ''Detailed Description''
* Release engineering: [https://pagure.io/releng/issue/9038 #9038] (a
check of an impact with Release Engineering is needed) <!-- REQUIRED
FOR SYSTEM WIDE CHANGES -->
<!-- Does this feature require coordination with release engineering
(e.g. changes to installer image generation or update package
delivery)? Is a mass rebuild required? include a link to the releng
issue.
The issue is required to be filed prior to feature submission, to
ensure that someone is on board to do any process development work and
testing, and that all changes make it into the pipeline; a bullet
point in a change is not sufficient communication -->
* Policies and guidelines: No updates needed.
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
This does not affect system upgrades because only new installation
will have changed default.
== How To Test ==
* Calling ''passwd -d user'' as root must fail with default configuration.
* Calling ''org.freedesktop.Accounts.User.SetPassword("", hint)'' and
''org.freedesktop.Accounts.User.SetPasswordMode(x)'' must fail with
default configuration.
* "require password reset on first login" must keep working when
creating users from Desktop Environment's GUI tools
== User Experience ==
Users will no longer be able to use empty passwords by default.
== Dependencies ==
None.
== Contingency Plan ==
* Contingency mechanism: Default behavior will not be changed.
* Contingency deadline: Beta
* Blocks release? No
* Blocks product? No
== Documentation ==
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
https://fedoraproject.org/wiki/Changes/GLIBC231
== Summary ==
Switch glibc in Fedora 32 to glibc version 2.31.
== Owner ==
* Name: [[User:submachine|Arjun Shankar]]
* Email: arjun(a)redhat.com
== Detailed Description ==
The GNU C Library version 2.31 will be released at the beginning of
February 2020; we have started closely tracking the glibc 2.31
development code in Fedora Rawhide and are addressing any issues as
they arise. Given the present schedule Fedora 32 will branch after the
GLIBC 2.31 upstream release. However, the mass rebuild schedule means
Fedora 32 will mass rebuild (if required) after GLIBC 2.31 upstream
freezes ABI for release, but before the actual release, so careful
attention must be paid to any last minute ABI changes.
== Benefit to Fedora ==
Stays up to date with latest security and bug fixes from glibc upstream.
== Scope ==
* Proposal owners: Update glibc to 2.31.
* Other developers: Developers need to ensure that rawhide is stable
and ready for the Fedora 32 branch. Given that glibc is backwards
compatible and we have been testing the new glibc in rawhide it should
make very little impact when updated, except for the occasional
deprecation warnings and removal of legacy interfaces from public
header files.
* Release engineering: [https://pagure.io/releng/issue/9040 #9040]
* Policies and guidelines: The policies and guidelines do not need to
be updated.
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
The library is backwards compatible with the version of glibc that was
shipped in Fedora 31.
Some packaging changes required, see:
https://sourceware.org/glibc/wiki/Release/2.31#Packaging_Changes
We fully expect to fix all packaging changes in Fedora Rawhide given
that glibc in Rawhide is tracking what will become glibc 2.31.
== How To Test ==
The GNU C Library has its own testsuite, which is run during the
package build and examined by the glibc developers before being
uploaded. This test suite has over 6200 tests that run to verify the
correct operation of the library. In the future may also run the
microbenchmark to look for performance regressions.
== User Experience ==
Users will see improved performance, many bugfixes and improvements to
POSIX compliance, additional locales, etc. The glibc 2.31 NEWS update
will include more details.
== Dependencies ==
All packages do not need to be rebuilt.
== Contingency Plan ==
* Contingency mechanism: Given that Rawhide has started tracking glibc
2.31, no show-stopper problems are expected. At this point, we can
still revert to upstream version 2.30 if insurmountable problems
appear, but to do so may require a mass rebuild to remove new symbols
from the ABI/API.
* Contingency deadline: Upstream ABI freeze deadline of 2020-01-01.
* Blocks release? Yes, upgrading glibc does block the release. We
should not ship without a newer glibc, there will be gcc and language
features that depend on glibc being upgraded. Thus without the upgrade
some features will be disabled or fall back to less optimal
implementations.
== Documentation ==
The glibc manual contains the documentation for the release and
doesn't need any more additional work.
== Release Notes ==
The GNU C Library version 2.31 will be released at the beginning of
February 2020. The current NEWS notes can be seen here as they are
added: https://sourceware.org/git/?p=glibc.git;a=blob;f=NEWS;hb=HEAD
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis