I wonder whether it wouldn't be time to say goodbye to tcpwrappers in
Fedora. There has been a request in systemd upstream to disable support
for it by default, but I am not sure I want to do that unless we can
maybe say goodbye to it for the big picture too.
Why would we get rid of them?
Well, to make things simpler, primarily. They have not seen any
development since 2003 (that's 11 years I mind you, an eternity in IT).
I doubt there are many people even using them anymore, firewalls are
more comprehensive and a lot more powerful, and while every admin knows
firewalls, I figure only very few know tcpd/tcpwrap, and even fewer ever
actively make use of them...
The API is awful, too, with lot's of open-coded structures, feature
checks in the headers, fixed length strings, globally exported variables,
non-namespaced symbols, really weird exported compatibility wrappers for
I'd propose we make a clear cut, and just start disabling it in all
services that link to it, instead of letting rot on in Fedora for all
It's bad code, little used, crufty. We have much better stuff now, and
that enables us to say goodbye to the old mess...
I figure there will be a bit of opposition to this change, thus I
thought I start the discussion on the fedora ML first. Unless there are
major concerns I will propose a feature about this in the next few
days. If somebody wants to join me on this and put his name on the
feature proposal I'd be delighted!
Lennart Poettering, Red Hat
Jaroslav Reznik wrote, on behalf of Matthias Clasen:
> The Software Collections repositories will be enabled by default.
So we now allow shipping the configuration for third-party repositories,
even enabled by default? Is April 1st still not over yet?
If you want those packages in Fedora, they need to get into the Fedora
This is a notice in accordance with the mass bug filing procedure.
A number of packages install systemd units and enable them
automatically. They should not. Please update these packages to use the
If your package has an exception from FESCo permitting it to enable
itself, please make sure that the service in question is listed in the
appropriate preset file.
There is a general exception described here:
If your package falls under the general exception, then it is possible
that no change is required. Nevertheless, if you are relying on the
exception, please make sure that your rpm scripts are sensible. The
In addition, any service which does not remain persistent on the
system (aka, it "runs once then goes away"), does not listen to
incoming connections during initialization, and does not require
configuration to be functional may be enabled by default (but is not
required to do so). An example of "runs once then goes away" service
Given that this issue can affect Fedora 20 users who install your
package as a dependency, these bugs should be fixed in Fedora 20 and
The tracker bug is here:
I created it early because three of the bugs are pre-existing. Next
week, I'll file bugs against the packages below. If you fix your
package in the mean time, please let me know.
After three weeks, provenpackagers may step in and fix these issues.
It's possible that I'm missing some packages. I may follow up with an
devel-announce mailing list
= Proposed Self Contained Change: Docker Container Image =
Change owner(s): Lokesh Mandvekar <lsm5(a)fedoraproject.org>, Dennis Gilmore
This is Fedora running inside Docker. Currently, there are non-official images
in the docker index, but we'd like them to really come out of release
== Detailed Description ==
The public docker registry  hosts many fedora images  including an
unprefixed (semi-official) image . However, this image doesn't have rel-eng
approval which would be required for a fully official image.
== Scope ==
* Proposal owners: The proposal owner needs to build the image tarballs with
the official kickstart scripts and make them available to docker's stackbrew
repo, which is used by the Docker maintainers to build unprefixed images.
Release Engineering approval/intervention would be needed at some point
(details still TBD)
* Other developers: N/A (not a System Wide Change)
* Release engineering: Official Release Engineering image approval. Process
* Policies and guidelines: N/A (not a System Wide Change)
devel-announce mailing list
I'm playing with an idea of building lua libraries against compat-lua to
allow luajit working with them. My initial motivation for this is that
there are projects which don't work with Lua-5.2 and developers for
various reasons don't want to port it to lua-5.2 yet (for example
I would imagine it to work the same way as Python2 vs. Python3 does. It
means to build the project twice - once against "lua" (lua-5.2) and once
against "compat-lua" (lua-5.1) using single spec file.
I've done some test with lua-expat and I'm attaching patch against
lua-expat.spec to show how it could be done.
I'm OK with creating bugs and patches against some basic lua modules
(basically the ones I need myself for Prosody :) ), but at first I
wanted to ask Lua people here what do they think about it?
Because of lack of interest, I plan to orphan the following packages
(Fedora + EPEL)
mysql++ (3.1.0 in rawhide, 3.2.1 available)
Used by sems-dsm
mysql-connector-python (1.1.6 in rawhide, 1.2.1 recently released)
Used by shinken
AFAIK, only connector to mysql for python3
mysql-utilities (1.3.6 in rawhide, 1.4.3 recently released)
Interesting tools for sysadmin
(but too much related to MySQL)
If you want to take them, just ask, I will release ownership.
Default firewalld configuration has wrong config for nfs service. There are
lots pf ports missing so even if you setup and configure nfs and enable nfs
service in firewalld it is still blocked.
There is great explanation how to fix this issue on Ask Fedora:
How can this be fixed in default firewalld config so that Fedora 21 has nfs
with correct ports?
I'm using avr-libc 1.8.0 (release 7.fc20) and i've noticed that
iom128rfr2.h provides only one type of pin definition whilst
iom128rfa1.h and others use a dual definition of pins (P##, and PORT##).
It seems that this may have come from the Atmel patch:
avr-libc upstream provides iom128rfr2.h with both definitions:
I encountered this when building simavr:
Is this intended or should I file it as a bug?