== 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,
== 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.
Fedora Program Manager
Seems like Apple converted their phones over to using a new file format
to store pictures. I was copying some pictures from a phone and noticed
my linux box couldn't read them and they had an interesting extension .heic.
Looks like there is a new image format in town and we need the libheif and
libde265 libraries in order to read it according to the gimp plugin . The
plugin docs say it should be included by default now in gimp but the gimp on
my f29 system says it can't read the file. This is probably because we don't
have the underlying libraries in Fedora.
Anybody been down this road? Is it as simple as getting the libraries in or
is there much more pain involved that I haven't discovered yet?
A lot of discussion about improving the compose process seem to end up
with a "reality check" - that ideas have already been tried but don't
work because of requirements a) b) c) d). You can't have the pony, but
maybe if a lot of effort is put into it, you can have a faster rocking
If want to fundamentally improve the Fedora workflow we need compose
ponies, we can't just have rocking horses!
Perhaps it would make sense to leave the current 8-10 hour compose in
place for the forseeable future, and work on a new system in parallel
where the primary constraint is to be as fast as possible. Hopefully
most problems with the slow compose will get sorted out in the fast
composes, and the slow compose will become more reliable. Perhaps in a
distant future, we can make the new system do everything
I don't know what the system would look like exactly, but you could
imagine things like:
* Composed of several micro-composes (micro-compose-services?) to
avoid blocking on everything completing successfully.
* Able to do speculative composes for CI
* Either x86_64-only, or with decoupled architectures so that we can
throw x86_64 hardware (or cloud resources) at it, and make it super
* No IO /mnt/koji during the compose - having a big network share be
central to the process creates a performance bottleneck, makes it hard
to move to the cloud, and potentially adds a lot of "noise" to
figuring out what is going on where things are slow because of some
other entirely different thing is goin gon.
Add your own bullet points :-)
Hi fellow Fedorians,
I have been intending to orphan php-ZendFramework version 1 for over a
It is End-of-Life, unmaintained (no updates in over 2 years), has known
security issues and probably doesn't fully work with PHP 7.2 and up
Plus, I no longer use it and one of it's dependencies (dojo) is also
orphaned and to be retired by now.
There are two packages in Fedora that depend on php-ZendFramework:
Both packages seem to even rely on the old ZF upstream. So if the
maintainers wish they should either start bundling ZF in those packages
or also think about retiring them.
Bazaar Review recently release article about Intel's Clear Linux with some
cool graphs showing nice performance gain compared to Xubuntu.
I didn't have time to dig in and look how it's performing against Fedora,
but I'd assume Fedora can be compared to Xubuntu in terms of compiler
I think I'll be interesting to look into it and find out if Fedora can't
tweak compiler settings (eg use LTO for critical things like Mesa, Kernel,
...). I think it could be interesting for Fedora users to have this enabled
if there are not any disadvantages other than compile time, compile memory
usage and so on.
What do you think?