I think we need to retire git-annex from Fedora (the current version is
very old and has security issues), since to build current versions needs
adding a lot of new Haskell dependencies to Fedora.
Currently noone has expressed interested in doing this... I plan to make a
copr repo later at some point. So unless someone wants to help do a lot of
package reviews, I think it is better just to retire git-annex from Fedora
I will do that next week unless someone volunteers to do all the work to
I am writing on behalf of Ben who is on away and the Haskell SIG.
= Proposed Self Contained Change: Making sudo pip Safe (Again) =
* Michal Cyprian <mcyprian AT redhat DOT com>
* Petr Viktorin <pviktori AT redhat DOT com>
* Tomas Orsava <torsava AT redhat DOT com>
* Miro Hroncok <mhroncok AT redhat DOT com>
At the present time, running sudo pip3 in Fedora is not safe. Pip
shares its installation directory with dnf, can remove dnf-managed
files and generally break the Python 3 interpreter. We propose a
series of measures that will make it safe to use.
== Detailed Description ==
The danger of using sudo pip3 stems from the fact that both Python dnf
packages and sudo pip3 install modules to the same location, namely
We aim to move the working directory for sudo pip3 to a more
appropriate location: /usr/local/lib/pythonX.Y/site-packages, and
modify the Python 3 interpreter in Fedora to scan both above mentioned
locations when importing modules. In addition, system-python—a
stripped down version of Python 3 for use by system tools—will not
read the sudo pip3 install location, making it more secure by being
less susceptible to interference by user-downloaded modules.
From the technical standpoint, this will be accomplished by changing
the install prefix setting of the distutils install command in the
/usr/bin/python3 executable from /usr/ to /usr/local. pip3 and
distutils will thereafter use this prefix when determining where to
install modules. In addition, the paths
/usr/local/lib64/pythonX.Y/site-packages will be added to the front of
the sys.path variable so that modules are imported preferentially from
there. These settings, however, will not be modified for the
system-python binary, the /usr/bin/python3 executable when running
with -I option specified, nor when an RPM build is detected.
Therefore, Python RPM packages will continue to be built with the
correct installation path for system modules.
The purpose of this change is not to make sudo pip a standard way to
install Python packages. Virtual environments and pip3 install --user
should still be the prefered options. Nevertheless, sudo pip is far
too prevalent an instruction in various guides and installation notes
throughout the Internet that there is little hope of changing users'
behaviour in this regard.
== Scope ==
* Proposal owners:
Modify the distutils install command as described above.
Modify the site.py script to add additional paths to sys.path when it is needed.
* Other developers:
N/A (not a System Wide Change)
* Release engineering:
* List of deliverables:
N/A (not a System Wide Change)
* Policies and guidelines:
N/A (not a System Wide Change)
* Trademark approval:
Not needed for this Change
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
I had an idea for a summer internship project, but I wanted to ask my
fellow Fedora devs if something like this already exists so it doesn't
get created as a duplicate project.
The idea is to create a dnf plugin that would allow you to do this:
$ sudo dnf upgrade FEDORA-2017-30604deb62
That update is a Gnome update, and likely has packages in it that you
don't use, but others that you do. The plugin would compare the
packages in the update against your installed set of packages to form
and execute the true dnf update command that should be run without
installing new packages (unless they are required). It would also
enable updates-testing of course. It could even be written to pull the
rpms from Koji if the update hasn't hit testing yet.
I've found that it is a little painful for me to test multi-package
updates when I don't use all the RPMs and I don't keep updates-testing
enabled on my system, so that's my motivation behind the idea. Does
anything like this already exist? If not, does it sound like a useful
tool to others?
It could also support the install command, in which case it would just
install all the RPMs from the update.
Due to many CVEs and low quality/security of these packages as well as Windows oriented upstream I'm going to orphan both jbig2dec and mupdf packages in Fedora/EPEL.
Sometimes the build doesn't reach stable branch just because it's deprecated by new build with new CVE.
Feel free to take them.
I have a fairly large package that needs review:
and I've been offered a few review swaps for it, but the trouble is, I
don't really feel well qualified to review packages yet. I only
maintain one other package (a pre-requisite for that one above) and it's
Should I just jump in anyway? How is this kind of thing usually resolved?
I haven't had much time for Fedora develoment the last 9 months or so, but I
may be able to start doing more again around August. I continue to use
Fedora on my work desktop and multiple machines at home (currently rawhide).
Following is the list of topics that will be discussed in the FPC
meeting Thursday at 2017-06-01 16:00 UTC in #fedora-meeting-1 on
Local time information (via. uitime):
================= Day: Thursday ==================
2017-06-01 09:00 PDT US/Pacific
2017-06-01 12:00 EDT --> US/Eastern <--
2017-06-01 16:00 UTC UTC
2017-06-01 17:00 BST Europe/London
2017-06-01 18:00 CEST Europe/Paris
2017-06-01 18:00 CEST Europe/Berlin
2017-06-01 21:30 IST Asia/Calcutta
---------------- New Day: Friday -----------------
2017-06-02 00:00 +08 Asia/Singapore
2017-06-02 00:00 HKT Asia/Hong_Kong
2017-06-02 01:00 JST Asia/Tokyo
2017-06-02 02:00 AEST Australia/Brisbane
Links to all tickets below can be found at:
= New business =
#topic #686 Avoid using names with `python-` prefix in requires
#topic #687 Repository config/COPr policy conflicts with FESCo policy
#topic #688 Council banned weak fwd deps to third party repos
= Open Floor =
For more complete details, please visit each individual ticket. The
report of the agenda items can be found at:
If you would like to add something to this agenda, you can reply to
this e-mail, file a new ticket at https://fedorahosted.org/fpc,
e-mail me directly, or bring it up at the end of the meeting, during
the open floor topic. Note that added topics may be deferred until
the following meeting.
Hi, I've retired mod_auth_kerb in the master branch. mod_auth_kerb has
been unmaintained for many years. mod_auth_gssapi is now available and
is an up-to-date, maintained replacement. Koji is the only dependency,
let me or Simo know if you want help adjusting the koji-web