possible /etc/X11/prefdm script error?
by Matt Hansen
Just looking through the /etc/X11/prefdm script, I noticed that after
the file /etc/sysconfig/desktop is read in, the if code block tests on
variable $DISPLAYMANAGER. Looking in the /etc/sysconfig/desktop, you can
see that the preferred display manager is set in variable $DESKTOP.
Therefore, shouldn't this if block test on $DESKTOP rather than
$DISPLAYMANAGER?
Or in alternative thinking, maybe the variable in /etc/sysconfig/desktop
should be changed to $DISPLAYMANAGER?
--
Matt
20 years, 3 months
cups providing LPRng
by Paul Heinlein
At work, we are stalled on getting a cups server up and into
production. Let's just assume, for the sake of discussion, that I'm
stuck using a legacy lpr/lpd server for now.
We've got a workable /etc/printcap that we push with cfengine to all
our *nix hosts. Thing is, cups doesn't like our printcap (nor does it
like our lpr server, which is quite ancient, but that's another story
and outside my control).
So I grabbed LPRng-3.8.19-3.1.src.rpm from the Red Hat 9 tree and
built it for Fedora.
I'm able to 'rpm -i' the new binary package without difficulty, but
'rpm -U' fails because the cups rpm provides LPRng (so -U wants to
remove the cups package):
$ rpm -q --provides cups
/usr/bin/cancel
/usr/bin/lp
/usr/bin/lpq
/usr/bin/lpr
/usr/bin/lprm
/usr/bin/lpstat
LPRng = 3.8.15-3
config(cups) = 1:1.1.19-13
lpd
lpr
cups = 1:1.1.19-13
That seems amiss to me. Is there a compelling reason why cups has to
provide LPRng? Do I have to play dueling rpms, telling LPRng that it
provides cups = 1:1.1.19-13.1?
--Paul Heinlein <heinlein(a)madboa.com>
20 years, 3 months
Setting up mach
by Toshio Kuratomi
Hi, I have some problems with setting up mach. If someone screams "go
to the mach list" I'll do that, otherwise I hope some other packagers
can help me out.
FC1 + updates.
mach-0.4.3 from http://thomas.apestaart.org/projects/mach
I have been doing builds on an old desktop machine that I have but it's
been having memory/cpu/kernel problems that I haven't tracked down yet
so I decided I'd have to install mach on my laptop to do QA builds
there. Unfortunately, my laptop has only 6GB which I need for things
besides a mach chroot. So I nfs mounted a (rw,no_root_squash)partition
from the desktop machine into my /var/lib/mach directory and tried to
get things running.
Running 'mach setup base' per the mach README gives me:
Preparing root
Updating apt sources ...
and apparently hangs. (strace on mach is complaining that apt-get
isn't giving it any data. strace on apt-get tells me it's waiting in a
read()).
Is running mach on an nfs partition not going to work? (File locking?
Permissions?)
Or is there some configuration on my end I should look into?
Thanks,
Toshio
--
Toshio <toshio(a)tiki-lounge.com>
20 years, 3 months
/etc/rc and potential startup improvements
by Shahms King
Some of you may remember Seth Nickell talking about a replacement for
init called SystemServices. When I first read about it I saw a few
problems with it. First and foremost is developer buy-in. In order for
it to be successful, it requires that the application developers
themselves provide a services API using that (potentially distribution
or Linux specific) interface. That can be a significant barrier to
entry for an application that aims to be portable and providing startup
services are done so differently on so many platforms (some of which
will never adopt DBUS) that, in my opinion, makes it almost a
non-starter. Additionally, I see nothing wrong with runlevels or most
of the current rc system. The most glaring lack in the current system
is a specification of something more meaningful than a simple numeric
order. The other solutions I've seen usually provide service
configuration and dependency information in a single, flat, file which
has the same problems as the BSD-style init scripts.
It should be possible to start programs which have no dependency on each
other in parallel. And it should be possible to remain
backwards-compatible with projects that haven't updated their
initscripts. And it should be possible to do this without changing the
current initscripts structure or "API". Using FC1 as a base, and
chkconfig for ideas, I'm currently working on a small python-based "rc"
replacement that should be able to manage all of that with a small
addition to the headers already present at the top of an initscript.
By adding a 'depends:' line to the top of an initscript, it should be
possible to create a backwards-compatible system (installed side-by-side
with the current bash-based one) with a few extra "smarts" that can
ensure all services with explicit dependency information have their
dependencies started before they are and all services without the
'depends:' header started after all services with a lower number.
Installing the python 'rc.py' and helper 'rc-helper' shell script (for
initscripts that don't use action, killproc, daemon, etc.) will allow
the bash-based rc script to be used in the absence of a python binary.
Given that the goal is to write the rc.py in such a way as to use the
current runlevel information as a "guide" to dependency information only
overriding those dependencies where explicitly specified it should be
possible to gain a small measure of parallel-startup without changing
the headers at all (any services with the same number after the 'S' have
a non-deterministic order -- well,it's lexicographic, but the 'rules' of
rc say that only the numeric value counts -- and so cannot depend on
each other and may be started in parallel).
Of course, there are certain situations that will negatively impact this
proposal. Some services sometimes require the network to be up and
sometimes don't, most databases fall into this category, X terminals,
etc.
At the moment I have it working well enough to start programs in the
specified order (whooo ;-P) essentially a python port of the rc file,
actually adding some dependency information to my initscripts is the
next step, I'm just posting to ask the question: would anyone be
interested in this purely-optional add-on if I manage to get it working
to my satisfaction? Are there other people out there working on another
solution to the initscript problem?
--
Shahms King <shahms(a)shahms.com>
20 years, 3 months
An introduction of the new cheerleader...
by Cristian Gafton
Hello folks,
As you are aware from his earlier message, Michael Johnson has decided to
move on and I have assumed the top level responsibilities for the Fedora
Project. Michael has been a great asset for us (where "us" = Red Hat and
the Fedora Project) and I would like to thank him for his efforts and the
progress made in these past months. A good part of this progress has not
been obvious to the outside world, but I know that there were a lot of
logistical hurdles and behind-the-scenes requirements cleared by Michael
in his time as the top Fedora wearer - which in turn will make my job that
much easier. I would like to thank him for his dedication to this project.
Good luck to you, Michael!
So, who am I? I have joined Red Hat in the summer of 1997 and I have
"climbed the corporate ladder" from an OS engineer to the Manager of OS
Development - those "old enough" will probably remember me from those
days. I then moved and started about three years ago the Red Hat Network
engineering group, where I have been acting as the Director of RHN until
about a year ago. In this past year, as a Red Hat Fellow, I have been
known to hold strong opinions in front of various CxOs from the Red Hat's
Executive team (/me tips the hat :-), while participating in various small
internal projects as time permitted. And now, with Fedora, the cycle is
completed and I have my chance to redeem myself for some of the things I
have done during my first stint as the dude responsible for building a
distribution... ;^)
I think it is important for everybody to realize that although Fedora is
going at this moment through a change in leadership, there will be no
change in the strategic direction and goals set by Red Hat and the
Steering Committee when the project was started. And because that saves me
from having to come up with a new grandiose plan ;-), I will dedicate my
immediate time on some of the tasks that need to be addressed with
urgency. In no particular order (since all these are qualify as "top
priority"), I will attempt to make happen in the shortest possible time:
- Fedora developer and contributor forms. These include things like
establishing qualifications, credentials and requirements for issuing
various accounts and access levels - in short the formal aspect of getting
those interested the "commit" access to Fedora Project bits;
- Installation of a CVS server and associated repositories as the primary
interface for the developers. I am still in the process of reviewing the
specifics of this plan, but I can share at this point that there will be
two main categories of packages/projects served from this machine to our
contributors (and here is the answer to a popular FAQ):
- the internally maintained packages will be mirrored read-only so that
external contributors can track our progress, review our changes and
replicate our progress on their own systems without waiting for
updates from Red Hat.
- the externally maintained packages will allow read/write access to
particular contributors ("owners").
We're finalizing the implementation of this server, and we'll get it online
in a relatively short time. Yes, the web site promised this "before the end
of 2003". That means we're behind and I personally don't like at all being
behind the schedule...
- We're going to start building and deploying the necessary pieces for a
build system that supports Fedora and its collaborative development
paradigm. This is going to be closely linked and interfaced with the CVS
server. I know some people have already proposed/implemented proof of
concepts for this, and I will engage them in more detailed discussions
in the next week (as I hunt them down in the mailing list archives, unless
they choose to make contact with me first).
I realize that there is no shortage of people interested and willing to
test-drive each of these pieces. I would like to thank you for your patience
to date and I promise you that shortly you will have plenty of stuff to sink
your teeth into...
In other words, my immediate attention is dedicated to the issue of physical
and logistical infrastructure that would get the most developers
contributing the fastest to the whole project. So, what are your
expectations of this infrastructure? I can not make promises, but I know
that reading your opinions will be a good opportunity to understand how
relevant our current plans are.
As I come up to speed on various other bits and issues in the project, I
will attempt to address those as well. I will try to capture all this into
a general project-level TODO list on the web site to keep folks informed
where we are on various issues, what kind of progress is being made or
what's holding up the expected progress.
For the future I hold the hope that we will build not only a great project,
but that we will have the chance of building strong relationships as well.
Excited, terrified, worried and hopeful - I am looking forward to it,
Cristian
--
----------------------------------------------------------------------
Cristian Gafton -- gafton(a)redhat.com -- Red Hat, Inc.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"There are two kinds of people who never amount to much: those who
cannot do what they are told, and those who can do nothing else."
--Cyrus Curtis
20 years, 3 months
release candidate zsh configs
by Eric Hattemer
The zsh config files in http://isd.usc.edu/~ehatteme/zsh/zshetc.tar.bz2
(link of ./zsh-etc-1-30-01PST.tar.bz2) are ready for submission. I just
cleaned them up a little bit since the 1-26 version. The only file that
is different from the original is /etc/zshrc. It may be better to split
the changes up into the other files, but I don't fully understand the
standard for what changes go into which file. Its probably not
critical, and zshrc seems like a good place to put them. I would like
to remove /etc/skel/.zshrc because it is not expected that someone will
install zsh before adding users. All it does is source /etc/profile,
which I moved into /etc/zshrc. If there are no suggestions or
objections that haven't been added yet, Warren will notify Petersen, the
zsh maintainer, he will review the files, modify them as necessary, and
put them into the next fedora zsh release. Please look these over,
decide if there is anything strange, lacking documentation,
incompatible, or non-standard, or if you have better preferences.
-Eric Hattemer
20 years, 3 months
Re: LVM1 to LVM2 plans for FC2
by Alexandre Oliva
On Feb 6, 2004, Paul Jakma <paul(a)clubi.ie> wrote:
> On Fri, 5 Feb 2004, Alexandre Oliva wrote:
>> Booting with LVM for the first time, if you have your root
>> filesystem in LVM, is a bit tricky.
> I dont. There's /no/ value in that IMO. root fs'es should be small
> and as easy to boot as possible. Anyone who doesnt have their root
> fs's like that is just someone who is waiting to learn a lesson. :)
Well, see... /boot is pretty small, but the root filesystem
(including /usr) has grown a lot over the past few years. Had I set
aside a 5GB partition for that say 2 years ago, since that was a lot
more than enough for a full install, I'd hardly be able to do a full
install on it nowadays. One of the reasons to use LVM is to make
filesystems easier to grow and manage. Say, if I want to install yet
another experimental release, I just create a new logical volume for
it. No need to go find room for a non-LVM partition in one of the 8
disks on my desktop.
>> That said, since it was such a pain to switch back and forth
>> between 2.4 and 2.6 in the same tree, I ended up removing 2.6 from
>> my FC1 installs, and only using 2.6 in rawhide installs.
> Do you mean in general? Or for the case of root-on-lvm only?
I think there are some pains to the general case, and greater pains
for the root-in-LVM case.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Happy GNU Year! oliva(a){lsd.ic.unicamp.br, gnu.org}
Red Hat GCC Developer aoliva(a){redhat.com, gcc.gnu.org}
Free Software Evangelist Professional serial bug killer
20 years, 3 months
yum upgrade
by Russell Coker
Completing update for pygtk2 - 539/539
Kernel Updated/Installed, checking for bootloader
Grub found - making this kernel the default
Traceback (most recent call last):
File "/usr/bin/yum", line 60, in ?
sys.exit(1)
File "/usr/share/yum/yummain.py", line 323, in main
sys.exit(1)
File "/usr/share/yum/pkgaction.py", line 536, in kernelupdate
# at the moment, kernel rpms are supposed to grok grub
File "/usr/share/yum/up2datetheft.py", line 13, in install_grub
import grubcfg
File "/usr/share/yum/grubcfg.py", line 12, in ?
import iutil
File "/usr/share/yum/iutil.py", line 2, in ?
import types, os, sys, select, string, stat, signal
ImportError: No module named select
----
I installed FC1 (yarrow) from CD and then put in the below /etc/yum.conf and
did "yum upgrade". Above is the errors that I get. Is this a known problem?
----
[main]
cachedir=/var/cache/yum
debuglevel=2
logfile=/var/log/yum.log
pkgpolicy=newest
distroverpkg=fedora-release
tolerant=1
exactarch=1
[development]
name=Fedora Core $releasever - Development Tree
baseurl=http://mirror.dulug.duke.edu/pub/fedora/linux/core/development/i386
[SELinux]
name=SELinux repository
baseurl=ftp://people.redhat.com/dwalsh/SELinux/Fedora
--
http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/ Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/ My home page
20 years, 3 months