I remember frequently (to my dismay) getting messages from yum saying that
another process had a lock on the RPM database.
Due to a recent rash of issues with the akmods package I have been
investigating why the kmods are not getting installed.
Out of curiosity I tried running two dnf update instances in two different
terminals and I did not get the message, in fact it acted like nothing was
Of course I hit "n" to not install the updates so I'm not sure what would
happen if I had hit "y"...
Am I missing something here?
= Proposed Self Contained Change: RPM MPI Requires Provides =
Change owner(s): Sandro Mani <manisandro at gmail dot com>
Have the rpm-build find-provides and find-requires scripts encode the MPI compiler name in the provides string of a binary to distinguish otherwise identical provides between packages $foo, $foo-openmpi and $foo-mpich.
== Detailed Description ==
Currently, the packages libfoo, libfoo-openmpi and libfoo-mpich providing the library libfoo.so all have a provides string of i.e.
While yum used a shortest-package-name rule to choose which package to pick, dnf does not have any rules, and seems to just pick the first match it comes across. Currently the only solution would be to filter the provides from the -openmpi, -mpich packages and add explicit Requires: where needed. I'd like to propose to extend the provides string in such way that it also encodes the MPI implementation, i.e.:
$ rpm -qp --provides libfoo
$ rpm -qp --provides libfoo-mpich
$ rpm -qp --provides libfoo-openmpi
To this end, I'm proposing to adapt the find-requires and find-provides scripts as (or similarly to):
Discussion of these changes are tracked in bug #1232504.
This change is intended to coordinate the rebuild of all MPI related packages to ensure all such packages consistently use the new provides format.
== Scope ==
* Proposal owners:
- Work on find-provides and find-requires based on feedback.
- As soon as updated find-provides and find-requires shipped with rpm-build, do a mass-rebuild of all MPI packages.
* Other developers: N/A (not a System Wide Change)
* Release engineering: N/A (not a System Wide Change)
* Policies and guidelines: N/A (not a System Wide Change)
* Trademark approval: N/A (not needed for this Change)
devel-announce mailing list
i am tired of ignored bugs in core components like
how to reproduce?
just use "RuntimeDirectory" and "ExecStartPost" in a systemd-unit and
stop the service every hour on each machine for backups, you will have a
few failed starts each day
Jul 4 03:18:54 backup-arrakis systemd: Failed at step RUNTIME_DIRECTORY
spawning /usr/libexec/mysqld-wait-ready: File exists
Jul 4 03:18:54 backup-arrakis systemd: Failed to start MariaDB Database.
Jul 4 03:18:54 backup-arrakis systemd: Unit mysqld.service entered
Jul 4 03:18:54 backup-arrakis systemd: mysqld.service failed.
Jul 4 08:17:54 backup-arrakis systemd: Failed at step RUNTIME_DIRECTORY
spawning /usr/libexec/mysqld: File exists
Jul 4 08:17:54 backup-arrakis systemd: Failed to start MariaDB Database.
Jul 4 08:17:54 backup-arrakis systemd: Unit mysqld.service entered
Jul 4 08:17:54 backup-arrakis systemd: mysqld.service failed.
I've pushed a new version of Boost, 1.58.0, to rawhide and f23, which
will require all packages that depend on Boost to be rebuilt. The plan
was to update to 1.59.0 but that isn't going to be released in time
for the F23 schedule, so I'll update rawhide to 1.59.0 at a later
For the F23 rebuilds please use the tag f23-boost e.g.
fedpkg build --target f23-boost
For the rawhide rebuilds please use the tag f24-boost e.g.
fedpkg build --target f24-boost
After all the rebuilds have been done with this tag they will be
merged back to f23 or rawhide, as appropriate..
Any problems rebuilding either open a bug or feel free to email me or
ping me on IRC (my freenode nick is 'redi') and I'll be happy to help.
(Please keep the conversation on the devel list; I'm CCing it the rel
-eng list to make sure all the relevant people see the initial message)
This past week, the Fedora Packaging Committee approved the use of
"weak dependencies" in Fedora. What this means is that RPM packages can
now have three levels of dependency-resolution: Requires, Recommends
* Requires: the requested package cannot function without this
additional package installed
* Recommends: the requested package can function in some minimal
capacity without this additional package installed, but the majority of
installations will want it for full productivity. These are usually
core plugins for the primary package. DNF defaults to installing
Recommends: dependencies automatically.
* Suggests: the requested package can easily function without this
additional package. This module may provide some less-common
functionality that a user might want. DNF defaults to *not* installing
Suggests: packages automatically.
Traditionally, we have only supported "Requires" dependencies and thus
the creation of install media (Live and otherwise) has been relatively
straightforward: we create a kickstart file that is fed into the
compose process containing a list of packages and groups that we want
installed onto the target system and the compose process automatically
pulls in all of the dependencies. However, with the advent of weak
dependencies, we have new questions that need answering about how this
compose process should work. (We also need to investigate what exactly
happens with the tools we have today - some of which still use yum, not
DNF - when weak dependencies are added to the mix).
From my perspective, there are three ways that we could choose to go:
1) Follow the default DNF behavior: Requires: and Recommends: packages
are included on the install media (and therefore also installed
together onto the target system)
2) Include *all* dependencies - Requires, Recommends and Suggests - on
the install media. The installer would still follow DNF defaults, so
the target system would get only the Requires and Recommends packages
unless the Suggests: packages are explicitly selected (which will also
require the creation of additional comps.xml changes to include the
3) Include only Requires: dependencies by default and require spin
-kickstarts owners to explicitly add any Recommends or Suggests
packages that they also want to include. Packages added explicitly will
be installed as described in 2) (requiring additional comps.xml changes
to include Suggests stuff)
Note that at the moment, DNF itself does not have a configuration
option to tweak the default install behavior, so 'dnf install'
effectively treats Recommends the same way as Requires (but 'dnf
remove' will treat them differently, of course). I discussed this with
the DNF developers this morning and they hope to have a configuration
option and/or command-line argument available to change this behavior
before Beta Freeze, so we should still be able to ship F23 with any of
the above options.
I think the best time to make these decisions is now, well in advance
of the Alpha Freeze so we have time to make adjustments as needed.
Thank you for reading to the end, I know the above has been a wall-o'
[In light of https://bugzilla.redhat.com/show_bug.cgi?id=1241383]
'dnf install --installroot=... --releasever=XX dnf' can be used to bootstrap
a Fedora chroot. The only snag is that --nogpg is often recommended, because
fedora-repos only provides the GPG keys for the current and next release.
It would be convenient (and safe!) to provide keys for past and future releases,
so such bootstrapping can be done without either importing the keys manually
and/or using --nogpg.
I thought I'd ask here first: is there a strong reason *not* to include those keys?
I'd like to ask everybody to test kdbus on Rawhide. Josh thankfully
added it to the Rawhide kernel packages, and our systemd RPMs come
with built-in support, too now. If you are running an up-to-date
Rawhide system adding "kdbus=1" to your kernel command line is hence
everything you need to run kdbus instead of dbus-daemon. (No
additional RPMs need to be installed.) If you do, things should just
work the same way as before, if we did everything right. By adding or
dropping "kdbus=1" to/from the command line you can enable kdbus or
revert back to dbus1 on each individual boot.
This stuff is opt-in, and we are very keen on getting feedback and
testing for this. The version of kdbus in Rawhide we consider API
stable, there is a complete client side available now in systemd, with
a client API in sd-bus. Compatibility with good old dbus1 is provided
by the "systemd-bus-proxy" service.
The folks involved in kdbus development have been running this code on
their systems for more than half a year now. There were occasional
hiccups, but we fixed everything we ran into, and it works pretty well
now. Our focus was specifically on providing the best possible
compatibility with dbus1. Now we'd like to increase the testing
audience and added this to Rawhide because of this.
Further information about kdbus and how to get started you may find
We'd very thankful for every Fedora developer testing this and
providing bug reports! Any feedback is highly appreciated.
Also, should you attend our upcoming conference, we might return the
favour by buying you a beer or two: