Hi all.
I just orphaned python-adns. I don't need it and don't plan to maintain it. The last upstream release was in 2007 and it does not support Python3. Also it FTBFS in rawhide.
python-adns is required by transmission-remote-cli. Please consider removing the dependency, so that python-adns can be retired or please consider maintaining python-adns as well.
Regards,
Tomas
--
Tomas Hozza
Associate Manager, Software Engineering - EMEA ENG Core Services
PGP: 1D9F3C2D
UTC+1 (CET)
Red Hat Inc. http://cz.redhat.com
https://fedoraproject.org/wiki/Changes/F30Boost169
== Summary ==
This change brings Boost 1.69 to Fedora. This will mean Fedora ships
with a recent upstream Boost release.
== Owner ==
* Name: [[User:jwakely|Jonathan Wakely]]
* Email: jwakely at fedoraproject dot org
== Detailed Description ==
The aim is to synchronize Fedora with the most recent Boost release.
Because ABI stability is one of explicit Boost non-goals, this entails
rebuilding of all dependent packages. This has also always entailed
yours truly assisting maintainers of client packages in decoding
cryptic boost-ese seen in output from g++. Such care is to be expected
this time around as well.
== Benefit to Fedora ==
Fedora 29 includes Boost 1.67 but the latest upstream release, Boost
1.68, was released on August 9th, 2018 (the 1.69 release is scheduled
for mid-November 2018, so it should be in time for F30).
Fedora will stay relevant, as far as Boost clients are concerned.
Boost 1.68 brings two new libraries:
* [https://www.boost.org/doc/libs/1_68_0/doc/html/yap.html YAP], an
expression template library for C++14 and later, from Zach Laine.
== Scope ==
* Proposal owners:
** Build will be done with Boost.Build v2 (which is the
upstream-sanctioned way of building Boost)
** Request a "f30-boost" build system tag
([http://lists.fedoraproject.org/pipermail/devel/2011-November/159908.html
discussion]): https://pagure.io/releng/issue/7614
** Build boost into that tag (take a look at the
[http://koji.fedoraproject.org/koji/buildinfo?buildID=606493 build
#606493] for inspiration)
** Post a request for rebuilds to fedora-devel
** Work on rebuilding dependent packages in the tag.
** When most is done, re-tag all the packages to rawhide
** Watch fedora-devel and assist in rebuilding broken Boost clients
(by fixing the client, or Boost).
* Other developers:
** Those who depend on Boost DSOs will have to rebuild their packages.
Feature owners will alleviate some of this work as indicated above,
and will assist those whose packages fail to build in debugging them.
* Release engineering: [https://pagure.io/releng/issue/7595] (a check
of an impact with Release Engineering is needed)
** [[Fedora_Program_Management/ReleaseBlocking/Fedora{{FedoraVersionNumber|next}}|List
of deliverables]]: All deliverables will include updated Boost
packages.
* Policies and guidelines:
** Apart from scope, this is business as usual, so no policies, no guidelines.
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
* No impact on system upgrade.
* No manual configuration or data migration needed.
* Some impact on other packages. Historically this hasn't been too big
of a problem and could always be resolved before deadline.
== How To Test ==
* No special hardware is needed.
* Integration testing simply consists of installing Boost packages
(<code>dnf install boost</code>) on Fedora and checking that it does
not break other packages (see below for a way to obtain a list of
boost clients).
== User Experience ==
* Expected to remain largely the same.
* Developers building third-party software on Fedora may need to
rebuild against the new Boost packages, and may need to adjust their
code if the new Boost release is not source-compatible.
== Dependencies ==
Packages that must be rebuilt:
<code>$ repoquery -s --releasever=rawhide --whatrequires libboost\*
--disablerepo=* --enablerepo=fedora | sort -u</code>
All clients:
<code>$ repoquery --releasever=rawhide --archlist=src --whatrequires
boost-devel --disablerepo='*' --enablerepo=fedora-source</code>
== Contingency Plan ==
* Contingency mechanism: Worst case scenario is to abandon the update
and simply ship F30 with Boost 1.67, which is already in rawhide.
* Contingency deadline: We will know whether the change can be made
once the rebuilds in the side tag are done, which will be January
2019, ideally before the mass rebuild.
* Blocks release? No
* Blocks product? None
== Documentation ==
* https://www.boost.org/users/history/version_1_68_0.html
* https://www.boost.org/development/index.html
--
Ben Cotton
Fedora Program Manager
TZ=America/Indiana/Indianapolis
https://fedoraproject.org/wiki/Changes/Erlang_21
= Erlang 21 =
== Summary ==
Update Erlang/OTP to version 21.
== Owner ==
* Name: [[User:Peter|Peter Lemenkov]], [[SIGs/Erlang|Fedora Erlang
SIG]], [[User:bowlofeggs|Randy Barlow]], [[User:jcline|Jeremy Cline]]
* Email: lemenkov(a)gmail.com, erlang(a)lists.fedoraproject.org,
bowlofeggs(a)fedoraproject.org, jcline(a)fedoraproject.org
== User Experience ==
Users will get more robust, scalable, and fast Erlang applications.
== Dependencies ==
The following packages must be rebuilt:
see https://fedoraproject.org/wiki/Changes/Erlang_21#Dependencies
== Contingency Plan ==
* Contingency mechanism: None necessary. Instead of falling back to
the previous version we should fix existing packages in order to help
the Community. We should also monitor upstream development process for
potentially discovered issues and proactively apply patches (as we
already did with [[Features/Erlang_R14|Erlang R14]],
[[Features/Erlang_R15|Erlang R15]], [[Features/Erlang_R16|Erlang
R16]], [[Changes/BetterErlangSupport|Erlang 17]]),
[[Changes/Erlang_18|Erlang 18]], [[Changes/Erlang_19|Erlang 19]], and
[[Changes/Erlang_20|Erlang 20]]. It should be noted that this change
consists from an independent or loosely coupled smaller changes. If we
fail to deliver some changes in time, we should reschedule these exact
changes to the future Fedora release while keeping already implemented
ones.
* Contingency deadline: N/A
* Blocks release? N/A
* Blocks product? N/A
== Documentation ==
* [http://www.erlang.org/news/123 Erlang/OTP 21.0 release notes]
* [http://www.erlang.org/news/124 Erlang/OTP 21.1 release notes]
--
Ben Cotton
Fedora Program Manager
TZ=America/Indiana/Indianapolis
For reference, this is in reply to Paul's email about lifecycle
objectives, specifically focusing on problem statement #1[1].
<tl;dr>
Have rpm use zchunk as its compression format, removing the need for
deltarpms, and thus reducing compose time. This will require changes
to both the rpm format and new features in the zchunk format.
</tl;dr>
*deltarpm background*
As part of the compose process, deltarpms are generated between each
new rpm and both the GA version of the rpm and the previous version.
This process is very CPU and memory intensive, especially for large
rpms.
This also means that deltarpms are only useful for an end user if they
are either updating from GA or have been diligent about keeping their
system up-to-date. If a user is updating a package from N-2 to N,
there will be no deltarpm and the full rpm will be downloaded.
*zchunk background*
As some are aware, I've been working on zchunk[2], a compression format
that's designed for highly efficient deltas, and using it minimize
metadata downloads[3].
The core idea behind zchunk is that a file is split into independently
compressed chunks and the checksum of each compressed chunk is stored
in the zchunk header. When downloading a new version of the file, you
download the zchunk header first, check which chunks you already have,
and then download the rest.
*Proposal*
My proposal would be to make zchunk the rpm compression format for
Fedora. This would involve a few additions to the zchunk format[4]
(something the format has been designed to accommodate), and would
require some changes to the rpm file format.
*Benefit*
The benefit of zchunked rpms is that, when downloading an updated rpm,
you would only need to download the chunks that have changed from
what's on your system.
The uncompressed local chunks would be combined with the downloaded
compressed chunks to create a local rpm that will pass signature
verification without needing to recompress the uncompressed local
chunks, making this computationally much faster than rebuilding a
deltarpm, a win for users.
The savings wouldn't be as good as what deltarpm can achieve, but
deltarpms would be redundant and could be removed, completely
eliminating a large step from the compose process.
*Drawbacks*
1. Downloading a new release of a zchunked rpm would be larger than
downloading the equivalent deltarpm. This is offset by the fact
that the client is able to work out which chunks it needs no matter
what the original rpm is, rather than needing a specific original
rpm as deltarpm does.
2. The rebuilt rpm may not be byte-for-byte identical to the original,
but will be able to be validated without decompression, as explained
in the next section
*Changes*
The zchunk format would need to be extended to allow for a zchunked rpm
to contain both the uncompressed chunks that were already on the local
system and the newly downloaded compressed chunks while still passing
signature verification. This would also require moving signature
verification to zchunk.
The rpm file format has to be changed because the zchunk header needs
to be at the beginning of the file in order for the zchunk library
figure out which chunks it needs to download. My suggestions for
changes to the rpm file format are as follows:
1. Signing should be moved to the zchunk format as described at the
beginning of this section
2. The rpm header should be stored in one stream inside the zchunk
file. This allows it to be easily extracted separately from the
data
3. The rpm cpio should be stored in a second stream inside the zchunk
file.
4. At minimum, an optional zchunk element should be set to identify
zchunk rpms as rpms rather than regular zchunk files. If desired,
optional elements could also be set containing %{name}, %[version},
%{release}, %{arch} and %{epoch}. This would allow this information
to be read easily without needing to extract the rpm header stream.
*Final notes*
I realize this is a massive proposal, zchunk is still very young, and
we're still working on getting the dnf zchunk pull requests reviewed.
I do think it's feasible and provides an opportunity to eliminate a
pain point from our compose process while still reducing the download
size for our users.
[1]:
https://fedoraproject.org/wiki/Objectives/Lifecycle/Problem_statements#Chal…
[2]: https://github.com/zchunk/zchunk
[3]: https://fedoraproject.org/wiki/Changes/Zchunk_Metadata
[4]: https://github.com/zchunk/zchunk/blob/master/zchunk_format.txt
https://fedoraproject.org/wiki/Changes/GnuPG2_as_default_GPG_implementation
== Summary ==
The /usr/bin/gpg path representing the main GPG implementation will
now use GnuPG 2 instead of GnuPG 1.
== Owner ==
* Name: [[User:ignatenkobrain|Igor Gnatenko]], [[User:till|Till
Maas]], [[User:ngompa|Neal Gompa]]
* Email: ignatenkobrain(a)fedoraproject.org, opensource(a)till.name,
ngompa13(a)gmail.com
== Detailed Description ==
For long time, GnuPG 2 is de-facto standard and it is unfortunate to
have /usr/bin/gpg to point to GnuPG 1 given that all major
repositories already have it that way.
Some of them don't even have GnuPG 1 shipped (RHEL is one example).
== Benefit to Fedora ==
This change will bring Fedora in line with other major distributions,
users will get consistent experience between distributions and the
naive expectation that "gpg" binary is the latest and greatest
implementation of GnuPG.
== Scope ==
* Proposal owners:
** Rename gnupg package to gnupg1
** Rename gpg binary to gpg1
** Rename gpg2 binary to gpg
** Create gpg2 → gpg symlink
** Check and fix if needed existing packages which require /usr/bin/gpg
* Other developers: Everything can be handled by change owners.
* Release engineering: [https://pagure.io/releng/issue/7920 #7920]
* Policies and guidelines: No changes are needed.
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
Users will have to adapt to change that gpg is now called gpg1 if
their usage is not compatible with both 1.x and 2.x.
== How To Test ==
Before change is implemented, owners will prepare COPR repository. You
will need to enable it and update and ensure that your
applications/scripts still work.
== User Experience ==
* /usr/bin/gpg is pointing to latest release of GnuPG 2 which makes
consistent user experience between distributions
== Dependencies ==
What can't be adopted to this change will be patched to use gpg1
explicitly, no action is needed from any developers.
== Contingency Plan ==
* Contingency mechanism: Owners will revert changes and postpone
change to next release.
* Contingency deadline: Beta Freeze.
* Blocks release? No
* Blocks product? No
== Documentation ==
Both gpg1 and gpg2 have their own documentation shipped with them.
--
Ben Cotton
Fedora Program Manager
TZ=America/Indiana/Indianapolis
Recently I began to create a review request for netatalk, when I noticed there already was an open review request:
https://bugzilla.redhat.com/show_bug.cgi?id=1520024
May 7th was the last activity by anyone other than myself. On 11/28 I offered assistance to help move the review along, but I have not received an answer.
In the interested of getting this review completed, am I in my right to close this request and create a new one, or is there better course of action?
Hello,
it's been a long time when Mesa added meson buildsystem definitions,
but I never got time to switch Fedora's mesa build to use them.
Nowadays, mesa upstream is looking to drop autotools definitions in
19.0.0 release, so time came up.
I've prepared 18.0.0~rc5 builds with using meson buildsystem instead
of autotools: https://copr.fedorainfracloud.org/coprs/ignatenkobrain/meson-mesa/
Please test it and let me know if something doesn't work as expected.
P.S. Builds are available just for rawhide.