Postings by Joe Orton

Orphaned crypto-utils

I've orphaned crypto-utils.

Retired mod_auth_kerb in Fedora master

Hi, I've retired mod_auth_kerb in the master branch. mod_auth_kerb has
been unmaintained for many years. mod_auth_gssapi is now available and
is an up-to-date, maintained replacement. Koji is the only dependency,
let me or Simo know if you want help adjusting the koji-web

Regards, Joe

Orphan package: webalizer

This thing is not actively maintained upstream; no intent to carry this
any more.

Regards, Joe

RFC: httpd-filesystem proposal

We're proposing to add an httpd-filesystem subpackage which will
simplify some dependency problems; particularly for packages which want
to contain files owned by the "apache" user, but don't need a dependency
on httpd itself.

<a href="" title=""></a>

Any comments welcome, either here on the bug.

Regards, Joe

Intent to retire: mod_python

mod_python upstream has been inactive for five years, since Graham
Dumpleton went to work on mod_wsgi. IMO it is long past time to retire
mod_python in Fedora. But the following packages still depend on it:

Source : glump-0.9.11-10.fc17.src.rpm
Source : koji-1.6.0-3.fc17.src.rpm
Source : viewvc-1.1.13-1.fc17.src.rpm
Source : yawn-0-0.3.20120227svn561.fc18.src.rpm

I haven't checked whether these are simply to convert over to WSGI or
not. Does anybody want to maintain mod_python? If not, I'm going to
retire it.

Regards, Joe

httpd 2.4 is coming, RFC on module packaging draft

httpd 2.4.1 packages are ready for dist-f18 and will be built early next
week. Rebuilds will be required for all packages containing httpd

Retired packages: mod_auth_pgsql, mod_auth_mysql, mod_authz_ldap

I'm retiring these packages in devel, because:

a) their functionality is duplicated by modules shipped with httpd
(mod_authn_dbd, mod_authnz_ldap)

b) their upstreams are no longer active

Regards, Joe

init script behaviour

Any opinions on this? I've had a query.

What should "service xxxx start" do for a daemon - or more specifically,
when should it return? There is inconsistency amongst different current
init scripts, two general approaches:

1) fire and forget: start the daemon, return immediately

2) stop and wait: start the daemon, and wait, either:
a) a short fixed period of time, or
b) in a loop until the pidfile appears, with some maximum wait time

Notable implication of (1) is that running e.g.