I have two problems which I can't seem to get to the bottom of, both of
them are very annoying and I don't know if it's me or the software so
would rather check things before putting stuff into the big red lizard.
First is httpd (apache).
I can do /etc/init.d/httpd stop and the server stops, but when I try to
start the server I get
Starting httpd (via systemctl): Job failed. See system logs and
'systemctl status' for details.
systemctl status httpd.service shows
httpd.service - LSB: start and stop Apache HTTP Server
Loaded: loaded (/etc/rc.d/init.d/httpd)
Active: failed since Mon, 03 Jan 2011 16:39:18 +0000; 33s ago
Process: 3902 (/etc/rc.d/init.d/httpd stop, code=exited,
Process: 1959 (/etc/rc.d/init.d/httpd start, code=exited,
Main PID: 2054 (code=exited, status=1/FAILURE)
└ 2086 /usr/sbin/httpd
cat /var/log/messages | tail is also unhelpful
Jan 3 16:41:34 PB3 systemd: httpd.service: control process exited,
Jan 3 16:41:34 PB3 systemd: Unit httpd.service entered failed state.
/var/log/httpd/error_log is showing nothing at all
I've also attempted to set up an svn server using the instructions at
using instruction 2. However, when I try to start svnserve I get
svnserve -r /svn -d
svnserve: Can't bind server socket: Address already in use
netstat is showing nothing is binding to the svn port.
I've thought it could be an selinux problem, but as I'm running
permissive, nothing is being reported back.
Any help on either of these would be appreciated :)
Vertraue mir, ich weiss, was ich mache...
I've upgraded `yap' package from 5.1.3 to 6.2.0 version. This is big
change after one and half year. New features in perspective of Fedora
include ODBC, MySQL, and zlib binding. MPI and Java support has not been
enabled. Java will be added in future package releases. MPI will not
because of heavy dependecies (in case of strong demand I can add it).
Because upstream does not version shared library I increased Fedora
specific soname to 6.2.0. Please recompile your packages linked against
libYap. Currently affected package in F15 is `ppl-yap' only.
I'm not sure if there's a better list for this to go to, but there seems
to be a problem generating deltarpms for F14 OOo (and a few other
packages) on releng2. Specifically, the updates->updates deltarpms
aren't being generated, while the GA->updates deltarpms are.
When I checked the mash.out log for the 101202.1757 push, there are
loads of error messages following the form of:
Error genDeltaRPM for openoffice.org-langpack-pt_PT: exitcode was 256 -
Reported Error: bad cpio archive
The problem is that this error normally comes up when one of the rpms is
corrupt, but manually running deltarpm between an rpm from the
101201.1909 push and the update from the 101202.1757 push results in a
proper drpm and no errors.
As far as I can see, this only affected the openoffice.org* and
autocorr* packages in the 101202 push, and the rest of the packages in
the push had all the proper deltarpms generated.
I'm not sure where to go from here. Any ideas on how to track this
-----BEGIN PGP SIGNED MESSAGE-----
I've been trying to contact the maintainer of pysvn for a few weeks
(Since December 14th) but have not received a reply. According to Koji,
the owner (ravenoak) has not been active since July. I'd like to
formally request being added as a comaintainer of this package, as it is
a broken dependency in EPEL 6 for one of the packages I maintain
I am also willing to assume comaintainership in Fedora.
Delivering value year after year.
Red Hat ranks #1 in value among software vendors.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
-----END PGP SIGNATURE-----
I have just built ogre 1.7.2 (previously 1.6.4) in rawhide.
I'll be working on dependencies over the next few days.
Ogre changed from lgpl2+ to mit (for most stuff, there are a number of
licenses used by the samples and other odd files) between 1.6 and 1.7.
Thanks to Spot for doing a lot of the leg work for this!
Some time ago, the Fedora default target for 32 bit Intel system moved
from i386 (F10) via i586 (F11) to i686 (F12). Nevertheless, even the
current development repo contains recent builds ending with
*.fc15.i386.rpm. Is there a particular reason for these exceptions or
has the build target been chosen incorrectly? ~CF