I would be willing to swap a review of vdr-markad  in rpmfusion for another
review, be it RPM Fusion or Fedora, preferably not something overly
complex. Feel free to contact me if you are interested.
> At today's FESCo meeting there were two tickets which had the end
> result of needing to have new maintainers and comaintainers for some
> == https://fedorahosted.org/fesco/ticket/1028 ==
> tor package was reassigned to a new maintainer. Former maintainer
> dropped ownership of his other packages. Those are now orphaned and
> in need of a new owner. Note to potential new maintainers: although
> not mandatory, you may want to open an optional re-review request as
> the spec files for some of these may be very out of sync with the
> current Fedora Packaging Guidelines
> * clamav
I've added me as comaintainer to clamav and i'm willing to take
ownership if it is orphoned.
Shure, i will do a new review request because i want to reorganized the
package like it is for epel.
Fedora's version is total user unfriendly, ie. needed to copy
configuration files by hand and no default daemon configuration.
I used the epel version for a long time for myself, because you need
only installation and enable the the daemon, that's all.
The mediawiki package has been updated to 1.20.2 for Rawhide and 1.19.3
The mediawiki-math/nopath packages have been merged into just
"mediawiki" (with Obsoletes). There is one package that depended on the
If you have your own wiki please look over the release notes and test
the packages in updates-testing. We're coming from a 2 year old version
so there are a few changes.
= Features/SystemdPredictableNetworkInterfaceNames =
Feature owner(s): Kay Sievers <kay at redhat dot com>
The udevd service has a long history of providing predicatable names for block
devices and others. For Fedora 19 we'd like to provide the same for network
interfaces, following a similar naming scheme, but only as fallback if not
other solution such as biosdevname is installed or the administrator manually
defined network interface names via udev rules or the old network scripts.
== Detailed description ==
The classic naming scheme for network interfaces applied by the kernel is to
simply assign names beginning with "eth0", "eth1", ... to all interfaces as
they are probed by the drivers. As the driver probing is generally not
predictable for modern technology this means that as soon as multiple network
interfaces are available the assignment of the names "eth0", "eth1" and so on
is generally not fixed anymore and it might very well happen that "eth0" on one
boot ends up being "eth1" on the next. This can have serious security
implications, for example in firewall rules which are coded for certain naming
schemes, and which are hence very sensitive to unpredictable changing names.
Starting with v197 systemd/udev can automatically assign predictable, stable
network interface names for all local Ethernet, WLAN and WWAN interfaces. This
is a departure from the traditional interface naming scheme ("eth0", "eth1",
"wlan0", ...), but should fix real problems.
This feature is about enabling this as default in Fedora, but only as a
fallback if the user/administrator did not manually assign names to interfaces
via udev rules, or via the old networking scripts, or if biosdevname is
For a longer discussion about this feature see the upstream documentation.
devel-announce mailing list
There is a perpetual problem facing all Linux distributions around how fast
to move with software updates. In Fedora, of course, our default speed is
petal-to-the-metal. This is part of who we are and why we are awesome.
However, it also sometimes makes life difficult for us -- for example, our
Puppet packages are broken because Ruby is too new. It also makes life
difficult for people trying to use Fedora seriously. It's especially hard
with Ruby and Java -- not that there's anything _wrong_ with these
languages, but the packaging expectations are different and often in
conflict with the system operator's traditional packaging worldview.
So, some Red Hat folks have developed an idea called Software Collections
which is aimed at this problem -- it lets you install and choose between
different versions of RPM-packaged software in parallel at run-time.
The base tool for enabling this (scl-utils) is included in Fedora, but we
don't allow Software Collections actually as Fedora packages (see
https://fedoraproject.org/wiki/SoftwareCollections). This is for very good
reasons -- there are a number of huge unanswered questions around structure,
infrastructure, maintenance, and security updates.
I think, though, that this tool, integrated well and supported, could really
help us in Fedora (and in EPEL). So, I'd like to
a) enumerate the problems with Software Collections in Fedora,
b) develop a medium-term plan for solving those problems, and
c) develop a longer-term plan for taking full advantage of the functionality
Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ <mattdm(a)fedoraproject.org>
Django 1.5 was released about two days ago. I'd like to push a build to
rawhide, but I assume, that will break many dependent packages.
The plan is, to delay the push, until other packages are fixed, or to
push in about 14 days.
I have a scratch-build build ready, one might to try, it should install
cleanly e.g. on Fedora 18.
Matthias Runge <mrunge(a)matthias-runge.de>
due to the Enrico Scholz saga, I realized that we have 4 packages in Rawhide
which BuildRequire dietlibc:
There are 2 things that strike me as broken there:
1. As far as I can tell, those packages are STATICALLY linked against
dietlibc. Yet there is no dietlibc-static subpackage, and apparently the
static library is in the main package (not even -devel!). There are also
dietlibc-devel and dietlibc-header subpackages, but nothing BuildRequires or
Requires those. The dietlibc package needs to be fixed to comply to the
packaging guidelines (which also means that either Enrico lets go the devel
branch or it should be forcibly removed from him!) or retired entirely (Do
we really need a second libc in Fedora?).
2. I think those packages should not build against dietlibc at all, but just
use the system glibc. Now that Enrico let them go, can we PLEASE get those
The "the-board" project hasn't seen almost any development upstream and it
currently doesn't build in rawhide due to previous gjs API changes.
I just don't have the time to try and reviving it these days, so I'll
orphan the package.
I noticed that drpm support is now built into yum and that yum-presto is
obsoleted. I don't see anything in the yum man page or the standard config files
on how to control whether drpms are used. Can it be done without
installing/removing the deltarpm package?