"Gerald Henriksen" <ghenriks(a)rogers.com> wrote in message
> On Tue, 29 Jul 2003 17:44:50 -0400, you wrote:
> >What are the chances of RedHat making this list available via NNTP?
> >It would make my life 1 billion times better and probably cause an
> >end to world hunger.
> news.gmane.org makes this list available (as
> Rhl-beta-list mailing list
Could anybody tell me under which verions of Red Hat Linux I should
report Severn bugs? I don't see a version entry specific for Severn.
Should "beta" do?
How clean is a war when you shoot around nukelar waste?
Stop the use of depleted uranium ammo!
End all weapons of mass destruction.
Matthew Winter wrote, somewhere in the digest:
>Once the installation was complete, I found that the system did not make
>use of the new graphical boot. I assume the installer prefers to keep
>the existing config in its entirity.
I doubt the installer keeps ALL configs as before when doing an
upgrade...i would imagine that it would really depend on what you have
editted and what is still a stock file. rpm packages can sense custom
config files and can prefer yer custom configs over stock configs. It
really depends on what the rpm packager decided the behavior should be.
If you had a hand editted config file, rpm packages typically can either
leave that config in place and give you the stock config as a backup
file, or back up yer custom config and give you a new stock config.
Look for files like *.rpmsave *.rpmnew *.rpmold. I always forget which
type of backup file corresponds to which behavior.
>I then noticed that even though I have only installed possible 4
>additional RPM's ontop of the original RHL 9, I had alot of package
...there is some value in trying to debug upgrade issues that only show
up when you are upgrading instead of doing a fresh install. Those
however are very tricky, especially dependancy issue with non-redhat
rpms that you have installed. I would have thought the installer would
throw up some warning messages about unresolved dependances for any
installed rpms that you had, even non redhat ones. This is tough to
narrow down, unless you can take the time to do repeated upgrades
scenarios where you are confident of configuration you started with. If
you have been living in rhl9 for a couple months, you could have an
extremely personalized setup that other people just might not be able to
reproduce similar upgrade bugs...its tough.
>Once booted, I attempted to install the NVidia driver, rebuilding the
>kernel. This failed as the NVidia driver performs a check of the CC
>versions and found that they are compiled using an earlier release. I
>assume NVidia will update there drivers when Severn goes into GA.
I have good news and bad news for you.
First the good news...right now becuase the kernel in the beta is still
compiled with gcc3.2 you can in fact compile the nvidia driver...you
just have to use the older gcc3.2 and not gcc3.3. In fact, you HAVE to
recompile the nvidia driver with the same version of gcc that you
compile the kernel with...so use the older Gcc3.2 which still comes in
The bad news is...once it becomes a breeze(cough..cough) to compile the
kernel with gcc3.3, i would expect that any subsequent isos that get
released for this beta phase might have kernels compiled with gcc 3.3.
Once this happens...don't count on the nvidia driver working from that
point on..till after the beta phase is over. Nvidia has historically NOT
provided any drivers that can be used as part of the redhat beta testing
process. The problem is what nvidia gives you is mostly a binary only
library, with a small amount of code that you can recompile to work with
your kernel. Once the kernel starts being compiled with gcc3.3, the
gcc3.2 compiled library/libraries nvidia provides will most likely just
not work together. Personally i think you best serve the community if
you just use the nv driver while yer beta testing, so that you can file
bugreports for it early on, so they can get fixed sooner.
For future reference, try not to obliterate a working system that you
expect to use with a beta. Whether or not this beta is less buggy or not
than previous betas isn't important. Always count on seeing a major
show-stopper that no-one else can reproduce, when you are installing a
beta release. Beta releases with 1400+ separate packages, will by their
very nature,always be a good source of fiber and roughage...in the form
of pointy glass shards. Beta releases will also steal your babies and
rat you out to the IRS. Just be prepared.
And please, make sure you check and post to redhat's bugzilla about any
of the rest of these issue. I don't know if anyone can do anything about
how applications interact with on-the-fly resolution resizing(during
this beta phase at least)...but now that we have the resolution resizing
ability, applications need to start thinking about how to deal with
it....so file those bugs. I would imagine this is going to be an
application by application kind of bug that has to be sent upstream to
each of the projects themselves....but someone in the know about desktop
development could give a short explanation on where in chain desktop
resizing is suppose to be noticed. I doubt its the wm that is suppose
to notice, so its either the desktop framework or each individual
-jef"use a second partition or disk to install the beta if you can, and
leave yer rhl9 install intact to play RTCW"spaleta
Lance Davis <lance(a)uklinux.net> wrote:
> It wont accept 'user' or 'group' statements inside virtual hosts ,
> unless something has changed in the past couple of months.
Right. It's a syntax change in mod_suexec. Use the 'SuexecUserGroup'
The documentation on the User and Group directives for Apache 2.0 also
-- Steve Bonneville
as an attempt at some debugging, i decided to start from
scratch and build a kernel using the shipped source tree,
and based on the config file found in /boot. theoretically,
if this worked, this should produce the same kernel and
modules that are installed originally. at least that's what
one would assume.
however, using that kernel source tree and config file
(and gcc32) produced a compile error on the aic7xxx_osm module.
how is that possible? shouldn't doing what i described reproduce
the kernel and modules exactly as they were shipped?
this is very puzzling.
> I had no problems at all with PHP and Apache2. For what I know, it is
widely used, although it may be labeled "experimental" I think it is quite
> Note that PHP 4.3.2 (which was released by the end of May) includes a
totally rewritten apxs2 support. It is worth trying.
I have posted questions to the PHP development list in the past and the main
reason that they gave for it still being experimental was that PHP as a
whole is not thread-safe and therefore if one of the extensions or libraries
was buggy and not thread-safe it could take down the whole apache instance.
Basically the impression I got was that no one in the PHP dev team saw
enough benefit in Apache 2 to warrant the testing and patching that would be
necessary to guarantee thread safety. The also say that most issues would
only come up under high load, so it would be hard to see it at first. Zend
published a whitepaper here
contains more details and basically urges users not to upgrade to Apache2.it
sounds very FUDish to me, and gives the impression that they don't want
users to upgrade because they are too lazy to test that configuration
Basically I would like to know if RedHat did any specific patching or high
load testing in order to guarantee enterprise worthiness. I would love to
use PHP with Apache 2 but I would just like to get some info on what it
takes to make it reliable.
Installer crash, when doing an "upgrade" install of beta (RH 9.0.93)
on a previously installed Severn system. N.B. My system uses an
AMD Athlon CPU.
Kindly add comments, as appropriate.
"You only live once, so let's make life EASIER for each other."
LINUX Registered User #193975. AMD-K7 ATHLON CPU power on board.
Is there any J2RE that currently support NPTL and or AMD64? Sun's new Java
1.4.2 doesn't list RedHat 9 as being supported and doesn't even mention
AMD64. I have heard murmurs about a Blackdown 1.4.2 coming out anytime now,
but the website looks fairly under maintained and I can't seem to find it
I know that RedHat made a deal with Sun to distribute Java with its
enterprise line, but I don't see any Java related rpms in Taroon. Assumedly
since Taroon uses NPTL and supports AMD64, a compatible version of Java is
forthcoming...anybody know anything more specific?
Thanks Joe. That's exactly what I needed to hear. It really seems like the
PHP group is being unnecessarily biased against Apache 2 considering that
prefork IS the default MPM.
On Mon, Jul 28, 2003 at 08:20:30PM -0400, Marc Richards wrote:
> I have posted questions to the PHP development list in the past and the
> reason that they gave for it still being experimental was that PHP as a
> whole is not thread-safe and therefore if one of the extensions or
> was buggy and not thread-safe it could take down the whole apache
It's important to recognize that the issue about thread-safety is *not*
an argument about whether PHP works with Apache 2.0 or not.
Using the default httpd binary in 2.0 (and that we ship), there are no
thread-safety issues in PHP, period. From the thread-safety
perspective, Apache 2.0 is absolutely no different from 1.3 in this
We provide an alternative httpd binary, /usr/sbin/httpd.worker, which
uses a thread-based model for processing requests: you can't use PHP
with this binary without recompiling it, and you probably wouldn't want
to even if you did.
It's not entirely clear why the PHP site has a "don't use PHP with
Apache 2.0 on production sites" message. There is no message like that
on the pages about integrating PHP with any of the Windows servers like
Xitami, IIS etc, and I am confident those configurations get a lot less
development, attention and production testing than PHP on Apache 2.0.
We've done a bunch of testing of 2.0 with PHP and the other modules; be
assured we wouldn't ship it if we didn't think it was production ready.
A number of (mostly minor) PHP/Apache 2.0 integration issues have been
fixed in our errata updates; none of these were reliability or stability
The following are the steps to make the beta work with reiserfs. This
will work with a cdrom iso image or a full nfs image.
1)Create a stage 2 image with reiserfs:
cp stage2.img stage2.img.old
mount -oloop stage2.img m1
1022 cp -a m1/ tree
rpm2cpio ../RPMS/kernel-2.4.21-20.1.2024.2.1.nptl.i586.rpm |cpio -ivd
find . -type f | cpio -H crc -o | gzip -9 > ../modules.cgz
mv modules.cgz tree/modules/
rm -rf boot lib mymods
mkcramfs tree/ stage2.img
rm stage2.img.old (only if this is going to be a cdrom image otherwise
keep the backup image.)
1a)Create a new iso image. (Haven't done this as I do network installs,
but in theroy.)
mkisofs -T -r -o ../newrhbeta.iso -b isolinux/isolinux.bin -c
isolinux/boot.cat -no-emul-boot -boot-load-size 4 -boot-info-table .
2)Boot the installer with the additional reiserfs option. Examples
"linux reiserfs" or "text reiserfs".
PS- If you want I can email my modules.cgz off list.
Once you have their hardware. Never give it back.
(The First Rule of Hardware Acquisition)
Sam Flory <sflory(a)rackable.com>