Planned Outage: Mailman / Nagios - 2015-12-02 03:00 UTC
There will be an outage starting at 2015-12-02 03:00 UTC, which will
last approximately 1 hour.
To convert UTC to your local time, take a look at
http://fedoraproject.org/wiki/Infrastructure/UTCHowto or run:
date -d '2015-12-02 03:00 UTC'
Reason for outage:
We will be re-adding a replaced hard drive.
Mosts of the services are redundant except for Mailman
(lists.fedoraproject.orglists.fedorahosted.org) and Nagios NOC01
Ticket Link: https://fedorahosted.org/fedora-infrastructure/ticket/5007
Please join #fedora-admin or #fedora-noc on irc.freenode.net or add
comments to the ticket for this outage above.
Stephen J Smoogen.
Error: nothing provides rpm-libs(x86-64) = 4.13.0-0.rc1.5.fc23 needed
*what* is that hard to solve the dependencies of packages given with *
on the commandline when yum does that fine for a decade, frankly if you
are trying to early test fedora builds for give karma or find issues you
can throw away DNF completly - that's alpha class software
rpm-build-libs.x86_64 0:4.13.0-0.rc1.5.fc23 rpm-libs.x86_64
rpm-python.x86_64 0:4.13.0-0.rc1.5.fc23 rpm-python3.x86_64
[root@srv-rhsoft:/downloads]$ ls | grep rpm | grep 4.13
-rw-r----- 1 harry verwaltung 508K 2015-11-07 13:09
-rw-r----- 1 harry verwaltung 135K 2015-11-07 13:09
-rw-r----- 1 harry verwaltung 114K 2015-11-07 13:09
-rw-r----- 1 harry verwaltung 292K 2015-11-07 13:09
-rw-r----- 1 harry verwaltung 50K 2015-11-07 13:10
-rw-r----- 1 harry verwaltung 50K 2015-11-07 13:09
-rw-r----- 1 harry verwaltung 99K 2015-11-07 13:10
-rw-r----- 1 harry verwaltung 99K 2015-11-07 13:13
[root@srv-rhsoft:/downloads]$ dnf update rpm*.rpm
Last metadata expiration check performed 0:13:57 ago on Sat Nov 7
Package rpm-build not installed, cannot update it.
Error: nothing provides rpm-libs(x86-64) = 4.13.0-0.rc1.5.fc23 needed by
package rpm-libs-4.13.0-0.rc1.5.fc23.x86_64 is not installable.
package rpm-plugin-selinux-4.13.0-0.rc1.5.fc23.x86_64 is not installable.
package rpm-plugin-systemd-inhibit-4.13.0-0.rc1.5.fc23.x86_64 is not
package rpm-python-4.13.0-0.rc1.5.fc23.x86_64 is not installable.
package rpm-python3-4.13.0-0.rc1.5.fc23.x86_64 is not installable.
package rpm-4.13.0-0.rc1.5.fc23.x86_64 requires librpm.so.7()(64bit),
but none of the providers can be installed
(try to add '--allowerasing' to command line to replace conflicting
Today I built snapshots of gnome-session gdm gnome-shell and mutter
that change how we do sessions at the login screen. We'll no longer
have separate items for GNOME and GNOME on Wayland. Instead they're
now both consolidated under the GNOME item. That item will use
wayland if it can, but if it falls back (because of a failure or
nvidia proprietary drivers, or the user explicitly disables wayland in
/etc/gdm/custom.conf) then that GNOME item will use Xorg instead.
I'm doing this for now in rawhide as preparation for this system-wide
If things don't pan out for whatever reason, or the change gets
otherwise rejected for f24, we'll split the items back out into two
But it's good to get this in rawhide now, so we can get as much
exposure as possible to potential wayland problems and get them fixed
up before release.
Just a heads up ! If you're a rawhide user please test!
tl; dr: I have submitted the following RFE for pkgdb:
Please add comments there if you have any.
I know I'm not the only provenpackager to have applied a bugfix to
someone's package only to be yelled at it for it. Some maintainers are
more prickly about having others touch the packages they maintain for
the community than others, and unfortunately there's currently just no
way to know whether you'll be thanked or flamed for helping out with a
After some IRC discussion I've come to the following proposal: that
maintainers have some way to easily indicate how open they are to
external contributions. Basically this would take the form of a few
options in pkgdb where maintainers can indicate their willingness to
have provenpackagers carry out a few actions. Please read the github
ticket for details:
This would be purely advisory, with hopefully reasonable defaults. I
believe it has the potential to eliminate quite a bit of friction that
provenpackagers must handle, as well as eliminate the hesitation some of
us feel for fear of being flamed.