That FC4 will contain only Emacs, not XEmacs, is fine with me - in
principle. However the XEmacs distribution contains the sumo package
which contains important packages like auctex. Currently auctex is not
part of FC4. Maybe there should be a package similar to sumo, but for
I stumbled across a problem today which at first sight might sound
trivial and irrelevant, but i'll come to some examples later.
The problem is that hardly any of the uninstall scripts which have a
service they want to stop ever check if the service is running at all.
They usually simply do a:
if [ "$1" = 0 ]; then
/sbin/service FOO stop >/dev/null 2>&1
/sbin/chkconfig --del FOO
Thats nice and fine in the general case, but as soon as you are working
in a chroot environment you can get really strange results:
Imagine you are remotely logged into a system via ssh, have a chroot and
are working in it and decide to remove the package openssh-server in
What would you except? Surely not that your sshd on the remote system
suddenly stops. But unfortunately thats what then happens because
/sbin/service stop calls killproc which first tries to find
/var/lock/subsys/FOO, then some other checks and if it didn't find
anything in the end it calls pidof FOO. And that just goes through /proc
and if it finds a matching name, in that case the sshd of the remote
system it happily uses that one to kill. Bang! Your sshd is gone.
Imagine that with a system 100s of miles away...
And thats only 1 example, it can hit you with a rescue system as well
where you work in a chroot to bring back up your system again.
But there is light at the end of the tunnel: There are several fairly
straightforward and pretty nice solutions to that problem.
1) As vixie-cron already does simply do this:
if [ "$1" = 0 ]; then
[ -f /var/lock/subsys/crond ] && /sbin/service crond stop
/sbin/chkconfig --del crond
Nice, easy and understandable. Only stop the service if it is running at
all. This is actually my favourite solution as it's really clean and
doesn't change behaviour of a system command.
2) Fix /sbin/pidof to check wether the /proc/1/root matches the found
This solution would require a fix in pidof. It would also change the
current behaviour, but arguably to correct a bug that pidof had. Because
honestly i wouldn't expect pidof to list pids of processes outside of my
3) Fix the inbetweener: killproc() in initrc functions. So basically
keep pidof as it is but make the check mentioned in 2) in killproc()
I see that 3rd solution a way around fixing possibly 76 specfiles in
devel with solution 1.
Just food for though and comments welcome, as always. I'd really like to
hear if you think this is a problem, too, or if i am just paranoid. :)
Read ya, Phil
Philipp Knirsch | Tel.: +49-711-96437-470
Development | Fax.: +49-711-96437-111
Red Hat GmbH | Email: Phil Knirsch <phil(a)redhat.de>
Hauptstaetterstr. 58 | Web: http://www.redhat.de/
Motd: You're only jealous cos the little penguins are talking to me.
We have released a section of our courseware under a Creative Commons
license that has very comprehensive coverage of building RPMs.
It has treatment of the whole spectrum of issues including making proper
patches, the freedesktop.org menu specification, and ancillary files
like logrotate.d files, cron.*/ files, SysV init files along with
One unique thing about the guide is that it is not just a reference as
it includes a very detailed (48 page) lab exercise that walks a would be
packager through several real world scenarios including:
* Setting up a build environment
* Re-building an existing src.rpm
* Updating a src.rpm with newer software release (and handling merged
* Creating a spec file from scratch to package an application
* Extending a spec file to break a single application into multiple
* Setting up GnuPG and signing your packages
The lab exercise has been validated and tested to "just work as written"
on the following distributions:
Fedora Core 3
Red Hat Enterprise Linux 4
SUSE Linux Professional 9.2
SUSE Linux Enterprise Server 9
It will likely work, possibly with small modifications, on other RPM
based distributions as well.
The guide can be found under the "Goodies" section of our website here:
I'm excited to make this release and hope it is useful addition to the
available RPM documentation and helps increase the amount of quality
packagers and packages.
>Unfortunately not, I still get these messages.
I'm going to make another exception in the audit libs. Audit 0.6.11 will be
released today. It should be in rawhide tomorrow. In the meantime, if you have
the pam srpm, there's a define WITH_AUDIT at the top of the specfile, change that
from a 1 to a 0 and rebuild the rpm.
Do you Yahoo!?
Make Yahoo! your home page
I have a Gigabyte GA-8i915G PRO mobo with the Intel 82801FR
hub ( ICH6R ), with only one SATA disk. FC3 kernels work
fine, and use ata-piix and libsata. Because the rawhide
kernel has the drivers for HDA sound, I got the new rawhide
kernel to use alsa-1.0.9. But it won't boot. kernel panic.
AFAICT, the new kernel include an ahci module, which should
work with ich6r. But it doesn't. For some reason, it stops
ata-piix from working.
So fc4 won't work with the i915 chipsets with SATA drives.