I'm working on moving the llvm-devel sub-package from the llvm package to
a new llvm4.0 package, however, when I upgrade from the llvm sub-package
to the llvm4.0 sub-package, I am getting file conflicts.
This can be reproduced on rawhide with these commands:
[root@746864b6a202 /]# dnf install llvm-devel
[root@746864b6a202 /]# dnf install 'dnf-command(copr)'
[root@746864b6a202 /]# dnf copr enable tstellar/llvm-versioned
[root@746864b6a202 /]# dnf install llvm-devel-4.0.0-13.fc27
Here is the error:
Error: Transaction check error:
file /usr/include/llvm from install of llvm-devel-4.0.0-13.fc27.x86_64 conflicts with file from package llvm-devel-4.0.0-4.fc27.x86_64
file /usr/include/llvm-c from install of llvm-devel-4.0.0-13.fc27.x86_64 conflicts with file from package llvm-devel-4.0.0-4.fc27.x86_64
I don't understand how a package can conflict with on older version of
the same package. Here are the spec files:
Is this a bug in dnf/rpm or am I doing something wrong with the spec files?
= 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
Some folks may have noticed that there have been no completed rawhide
composes in a while (13 days as of today).
This has been due to a variety of bugs and issues, along with pungi now
failing composes that don't have all required release blocking items.
Here's a partial list:
2017-06-01 - lorax traceback, bug 1457055
2017-06-02 - another lorax issue, bug 1457906
2017-06-03 - cloud base failed in anaconda, bug 1458509
2017-06-04 - ditto
2017-06-05 - ditto
2017-06-06 - pungi bug - https://pagure.io/pungi/issue/641
2017-06-07 - ditto
2017-06-08 - ditto
2017-06-09 - ditto
2017-06-10 - ditto
2017-06-11 - ditto
2017-06-12 - ditto
2017-06-12.1 - pungi bug fixed, but hit libgtop2 broken deps in metacity
that failed the comppose. I fixed those (and control-center) last night.
2017-06-13 - still running, cross your fingers.
All of this has been made a bit worse by us having some storage slowness
which means you can really only do about 2 rawhide compose attempts a
day. Thats being worked on and hopefully we will get it fixed soon.
You can also see here there were some gaps where we didn't yet have the
bug tracked down or didn't yet have a fix in place. We need to try and
do better there. (I was out on vacation last week, so it can't always be
Anyhow, hopefully we will have a rawhide compose today, and if not I
will keep poking it to get it going...
Our hotel discount code for Flock went live yesterday. It is... *drumroll* "FLOCK".
Here are the rates:
- A $139/night* rate per double, queen, or king room is available from August 27 to August 31. You will need to use the "Group Attendee" code "FLOCK" on the hotel reservation form to book your room at the Flock rate.
- A $169/night* double occupancy (under 18 free) discounted rate is available the weekend before and the weekend after (evenings of Fri Aug 25 and Sat Aug 26 + evenings of Fri Sep 1 and Sat Sep 2. The $139 rate is available Thu Aug 24 and Mon Sep 3.)
- If you are booking by phone, please state that you are attending the Flock 2017 Conference.
- July 26 is the cut-off for our reserved block. If reserving for yourself, please book before then!
*IF YOU ARE APPLYING FOR FUNDING DO NOT RESERVE YOUR ROOM.* We'll book it for you if you are funded. :)
The website is updated with this info.
Also, we're looking forward to reviewing your session proposals, which are due tomorrow! :)
For more frequent updates about Flock 2017, please subscribe to:
devel-announce mailing list -- devel-announce(a)lists.fedoraproject.org
To unsubscribe send an email to devel-announce-leave(a)lists.fedoraproject.org
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.