https://fedoraproject.org/wiki/Changes/ReplaceBazaarWithBreezy
Note that this was originally discussed on the devel mailing list:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org…
== Summary ==
This change is about replacing the {{package|bzr}} package with
{{package|breezy}}.
[https://bazaar.canonical.com/en/ Bzr (Bazaar)] is a version control
system, [https://www.breezy-vcs.org/ Breezy (brz)] is a fork of
Bazaar. Breezy will obsolete and replace Bazaar in Fedora 32.
== Owner ==
* Name: [[User:churchyard| Miro Hrončok]]
* Email: <mhroncok(a)redhat.com>
* Name: [[User:dormouse| Marcel Plch]]
* Email: <mplch(a)redhat.com>
== Detailed Description ==
The {{package|breezy}} package will be introduced. It provides and
obsoletes <code>bzr</code> and <code>git-remote-bzr</code>, it
contains <code>/usr/bin/bzr</code> (link to <code>/usr/bin/brz</code>)
and <code>/usr/bin/git-remote-bzr</code>.
Packages {{package|bzr}} and {{package|git-remote-bzr}} will be retired.
The reasons for this include:
* bzr is Python 2 only and [[Changes/RetirePython2|Python 2 is retired]]
* bzr [https://bugzilla.redhat.com/show_bug.cgi?id=1734995 fails to
build from source]
* bzr [https://bugzilla.redhat.com/show_bug.cgi?id=1758870 fails to install]
* bzr [https://pagure.io/fesco/issue/2227 has no maintainer]
== Benefit to Fedora ==
Users of Fedora will be able to use bazaar repositories via breezy. If
we don't do this, bzr would be simply removed without a replacement.
== Scope ==
* '''Proposal owners:''' package {{package|breezy}} and it's
dependencies (see [https://bugzilla.redhat.com/show_bug.cgi?id=1754964
the package review])
* '''Other developers:''' Test that your packages work with breezy
({{package|trac-bazaar-plugin}}, {{package|etckeeper}},
{{package|ikiwiki}}, {{package|python-vcstools}},
{{package|python-wstool}}, {{package|golang-github-masterminds-vcs}},
{{package|python-pip}} are impacted). Adapt, drop the dependency or
retire the packages.
* Release engineering: no impact with Release Engineering is anticipated
* Policies and guidelines: N/A
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
Eventually removed depndent packages need to be obsoleted.
Breezy aims to be compatible with bazaar, but there might be some differences.
== How To Test ==
Test that installing bzr installs breezy, test that you can use it successfully.
Test that bzr gets replaced by breezy when upgrading to Fedora 32.
== User Experience ==
Users installing bzr will get breezy instead. The <code>bzr</code>
command will be provided as a symbolic link to the <code>brz</code>
(breezy) command. The basic API of that command should be the same.
== Contingency Plan ==
* Contingency mechanism: (What to do? Who will do it?) Proposal
owners will orphan both breezy and bzr (sorry, but not sorry).
* Contingency deadline: final freeze
* Blocks release? No
* Blocks product? No
== Documentation ==
<!-- Is there upstream documentation on this change, or notes you have
written yourself? Link to that material here so other interested
developers can get involved. -->
# https://breezy-vcs.org/doc/en/
== Release Notes ==
TBD
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
Hello fellow Python packagers. This is an announcement about a new set of RPM
macros you can use to build PEP 517/518 enabled packages, that is Python
packages that have the pyproject.toml file.
https://www.python.org/dev/peps/pep-0517/https://www.python.org/dev/peps/pep-0518/https://snarky.ca/clarifying-pep-518/
The set of macros is designed for modern packaging with dynamic buildrequires in
mind.
The macros are in the pyproject-rpm-macros package and you can use them like this:
BuildRequires: pyproject-rpm-macros
%prep
...
%generate_buildrequires
%pyproject_buildrequires -t
%build
%pyproject_wheel
%install
%pyproject_install
%check
%tox
See the full documentation of the macros:
https://src.fedoraproject.org/rpms/pyproject-rpm-macros/blob/master/f/READM…
See example spec files:
https://src.fedoraproject.org/rpms/pyproject-rpm-macros/blob/master/f/tests
(These use setuptools (setup.py), flit and poetry for build backends, but you
cannot tell that from the specfiles - BuildRequires are generated dynamically
from upstream metadata.)
The macros are **provisional**, i.e. their API may be changed upon feedback
received from you.
We are not (yet) interested in a general "update all the Python packages" hunt,
but rather in early adopters.
If you have questions, ask here. We'll gladly extend the docs if something is
not clear.
If you find bugs, report them in bugzilla or here. Likewise for RFEs.
Happy hacking,
Python Maintenance
https://fedoraproject.org/wiki/Changes/BINUTILS233
== Summary ==
Rebase the binutils package from version 2.32 to version 2.33.
== Owner ==
* Name: Nick Clifton [https://fedoraproject.org/wiki/User:Nickc]
* Email: nickc(a)redhat.com
== Detailed Description ==
Switch the binutils package from being based on the 2.32 release of
the GNU binutils to
being based on the 2.33 release. This release will bring in numerous
bug fixes, as well
as support for the CTF debug format.
== Benefit to Fedora ==
The main benefit will be the bug fixes and the improvement to the linker.
In addition the new support for the CTF debug format will help
consumers of CTF, most notably the kernel.
== Scope ==
* Proposal owners:
Change the source parameter in the binutils.spec rpm and adjust the
local patches to take account of the bugs that are now already fixed.
This is a significant change to the underlying tools used to build
Fedora and so there should be a mass rebuild in order for the changes
to be noticed across the system.
* Other developers: No other work should be necessary. Once the
rebase is in place and the buildroot contains the new binutils its use
should be automatic.
* Release engineering: [https://pagure.io/releng/issue/8837] A mass
rebuild will be required.
* Policies and guidelines: No update needed.
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
The binutils are backwards compatible with previous releases, so no
changes should be necessary.
== How To Test ==
The binutils package does include its own set of testsuites which
check basic functionality.
The real test however is by rebuilding other packages which depend
upon the binutils, or
more likely, upon gcc. If these packages continue to work then the
binutils update has not
broken anything.
== User Experience ==
The change should not be noticeable to the user.
== Dependencies ==
This update has no hard dependencies on any other package.
There are other packages that do depend upon the binutils however.
Most notably gcc and redhat-rpm-config.
== Contingency Plan ==
* Contingency mechanism: Revert to the 2.32 binutils as currently used
in rawhide. This work can be done by me, should it prove necessary.
* Contingency deadline: Beta Freeze.
== Documentation ==
Documentation is not currently available, due to the fact that the
2.33 release has not yet been created.
(It is hoped that the release will happen before the Fedora 32 mass rebuild).
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
There will be an outage starting at 2019-10-2 21:00 UTC, which will last
approximately 1 hour.
To convert UTC to your local time, take a look at
https://fedoraproject.org/wiki/UTCHowto
or run:
date -d '2019-10-02 21:00 UTC'
Reason for outage:
During this outage window we plan to upgrade koji to the current 1.18.0 release,
and additionally add memory to the koji database server to help improve performance.
During the outage window new builds may fail to initiate,
but in progress builds should complete as expected.
Affected Services:
koji - https://koji.fedoraproject.org/koji
Ticket Link: https://pagure.io/fedora-infrastructure/issue/8265
Contact Information:
Please join #fedora-admin in irc.freenode.net or add comments to the ticket for this outage above.