I wanted to modify CXXFLAGS and stumbled across the %configure
Wouldn't it be better to have this in /usr/lib/rpm/redhat/macros:
so that I can modify RPM_OPT_FLAGS prior to calling %configure??
Harald Hoyer, Senior Software Engineer Harald.Hoyer(a)redhat.de
Red Hat GmbH Tel. : +49-711-96437-0
D-70178 Stuttgart, Germany Web : http://www.redhat.de
gpg fingerprint E930 20E6 CCF8 C76C 8582 CF9F B7B7 45C2 C557 5542
For several releases now (I think since 8.0) gdm has popped up this cute
dialog box if your home directory didn't exist asking if you would like
to log in with / as your home directory. You can click on Yes, you can
click on No but you always just get the gdm screen asking you to enter
your username. It doesn't fail...it just doesn't work.
See bug #77354
In Gnome's bugzilla the PostLogin stuff is mentioned but I'm not sure if
even the gdm in Severn supports that feature.
Does anyone know of a way I can make this work? Ideally, I would like
to use mktemp to create a temp home dir instead of just using /. The
situation is the mentality that if your fileserver is down you should
still be able to take an online test, surf the web, check your webmail,
etc. (Which I see nothing wrong with.)
Jack Neely <slack(a)quackmaster.net>
Linux Realm Kit Administration and Development
PAMS Computer Operations at NC State University
GPG Fingerprint: 1917 5AC1 E828 9337 7AA4 EA6B 213B 765F 3B6A 5B89
Just some intro for those who haven't played this game before...
If you've reported a bug, you may have noticed in the past few
days that the bug may now be listed as blocking bug 100643 or
bug 100644. These bugs are the 'CambridgeBlocker' and 'CambridgeTarget'
What these bugs represent:
- categorization of bugs into relative high and medium priorities
What these bugs don't represent:
- guarantees that the bug will be fixed
Note that these lists are populated at first through cursory
bug triage; issues in these bugs may eventually turn out to
be NOTABUG or WONTFIX.
How You Can Help (if you so desire):
1) If you've got a bug that appears to be overlooked in this
categorization, feel free to nomintate it in the body
of the appropriate tracking bug ('CambridgeBlocker', or
'CambridgeTarget'); then our crack (cracked?) bug triage
team will review it again.
(Note that all bugs opened against the beta are usually given
a once-over within a day or two of being opened; this is how
the list normally gets populated)
2) Look at the bugs on the list, and feel free to:
- perform duplicate eliminations
- verfiy reproducibility/create test cases
- provide patches to fix them. (This option is preferred, of course.)
Bugs may be moved from one list to the other at any time, or
deescalated completely. The chances of an enhancement requests
landing on either of these lists is fairly low.
I have a little question about the standard rh installer, regarding a
little problem I had.
In RH9, the installer kernel is compiled for i686 (RH8 was i386). Since
this is not a bad thing, It kinda gives some problems sometimes when
installing on certain systems.
For example: The installer-kernel kept on crashing when trying to do an
install on my little home server, which has a Via C3 processor (you
know, soldered on one of those sweet mini-itx boards), which does not
support the i686 instruction set (almost, but it doesn't support the
I was wondering if it would be possible to keep the option open to
install future redhats on older systems? I think this would be a "good
thing"(tm), since not everyone uses high-end machines.
(also: think of people in developing countries, who can use the latest
and greatest os features, without having to spend a fortune on the
When I attempt to run gaim-0.66 from Fedora on Severn using
gtkspell-2.0.4-1 (included in Severn), it fails with this message.
gaim: error while loading shared libraries: libgtkspell.so.0: cannot
open shared object file: No such file or directory
After I ran "ldconfig" manually as root, gaim works. Upon inspection of
RH's .spec file of gtkspell it has ldconfig within %post, so I am
confused. Any idea what happened here?
Hi one thing that has come up over and over again (here) is that Debian
is easier to install into a diskless workstation environment than Red
Hat. I being the RH bigot that I am have not tried this yet, but I get
the feeling that it is.
I would really like to see some work on making a Heavy Diskless
Workstation install possible in the future. [Heavy Diskless means boxes
that have say 1-2 gigs of Ram, big CPUs, and 100 mbps network at least.]
THere are many environments that use this heavy duty, and right now I am
having to admin 4 different ways of killing the problem with no one
Stephen John Smoogen smoogen(a)lanl.gov
Los Alamos National Labrador CCN-5 Sched 5/40 PH: 4-0645 (note new #)
Ta-03 SM-1498 MailStop B255 DP 10S Los Alamos, NM 87545
-- So shines a good deed in a weary world. = Willy Wonka --
How about splitting rc.sysinit into multiple commands in a directory,
I've seen several cases when various applications (usually stuff that
wants to do low-level things) needed to somehow insert themselves in the
rc.sysinit sequence. With a monolithic rc.sysinit that's impossible
unless you hack the script using sed, perl, etc., which is ugly to say
One issue with splitting it (among many other that i'm not going to
mention) might be that the boot up time might get a bit bigger. If i'm
not mistaken, this could be avoided by creating one single actual
executable, and let it source things up from a directory, instead of
launching multiple executable scripts sequentially.
Splitting this executable might also allow for things like optionally
turning on (or NOT turning on) IEEE1394 or USB in userspace (as opposed
to using kernel parameters in the bootloader), etc.
"Never send a human to do a machine's job." - Agent Smith
On 26 Jul 2003, Chris Kloiber wrote:
> On Thu, 2003-07-24 at 16:29, Sean Middleditch wrote:
> > On Thu, 2003-07-24 at 16:22, Dax Kelson wrote:
> > > I typically do Everything installs on my personal workstations.
> > > Simplifies life greatly.
> > >
> > > However, it would be nice if there were:
> > >
> > > "Everything ONLY English" (ie, no foreign language support)
> > >
> > > "Everything NO Development"
> > >
> > > Comments?
> > Definitely dont' think that's a good idea. It solves perhaps your
> > problem, but I'm there are many users who have other specific package
> > sets they'd love install options for too. What we'd end up with is an
> > Everything menu with tons of semi-Everythings, covering everything
> > imaginable, even tho they aren't Everything. ~,^
> > Seriously, it's not that much work to just select the package groups.
> > If you do find yourself spending too much time on it, quit reinstalling
> > your machines so often. ;-) Or just use Kickstart.
> I think more people speak other languages than do speak American
> English, but I understand where you are going with the original
> suggestion. I sort of expanded on that idea as I personally think it's a
> good one, and filed this bugzilla report:
> You can read my suggestion there, but I can't say how much traction it
> will get for this release. It's more than likely too late for now.
FWIW, It is already closed as WONTFIX.
......Tom Registered Linux User #14522 http://counter.li.org
tdiehl(a)rogueind.com My current SpamTrap -------> mtd123(a)rogueind.com