A cvsup account..

A cvsup account..

[Andrew Cagney]

Hello,

Could someone please create an account called cvsup with no privledges
other than being able to read (_not_ write) the CVS repositories.

I'm sufficiently motivated (frustrated? :-) to want to get CVSupD
running on sourceware.

	Andrew

PS: Where should the relevant cvsupd sources be archived?  Is there a
policy on importing binaries rather than building things from scratch? 
If I'm going to build things from scratch then I'll need a few spare
100Mbs :-)

A cvsup account..

[Andrew Cagney]

Hello,

Could someone please create an account called cvsup with no privledges
other than being able to read (_not_ write) the CVS repositories.

I'm sufficiently motivated (frustrated? :-) to want to get CVSupD
running on sourceware.

	Andrew

PS: Where should the relevant cvsupd sources be archived?  Is there a
policy on importing binaries rather than building things from scratch? 
If I'm going to build things from scratch then I'll need a few spare
100Mbs :-)

Re: A cvsup account..

[Tom Tromey]

Andrew> Could someone please create an account called cvsup with no
Andrew> privledges other than being able to read (_not_ write) the CVS
Andrew> repositories.

That's going to run into the group limit problem, won't it?
Also, can you just use the anoncvs account for this?
Or does this user not need to be able to make cvs locks?

Andrew> PS: Where should the relevant cvsupd sources be archived?  Is
Andrew> there a policy on importing binaries rather than building
Andrew> things from scratch?  If I'm going to build things from
Andrew> scratch then I'll need a few spare 100Mbs :-)

I don't know.  Is there an RPM?  We could just install it that way.

Tom

Re: A cvsup account..

[Tom Tromey]

Andrew> Could someone please create an account called cvsup with no
Andrew> privledges other than being able to read (_not_ write) the CVS
Andrew> repositories.

That's going to run into the group limit problem, won't it?
Also, can you just use the anoncvs account for this?
Or does this user not need to be able to make cvs locks?

Andrew> PS: Where should the relevant cvsupd sources be archived?  Is
Andrew> there a policy on importing binaries rather than building
Andrew> things from scratch?  If I'm going to build things from
Andrew> scratch then I'll need a few spare 100Mbs :-)

I don't know.  Is there an RPM?  We could just install it that way.

Tom

Re: A cvsup account..

[Andrew Cagney]

Excerpts from mail: 21-Mar-100 Re: A cvsup account.. Tom
Tromey@cygnus.com (663*)

> Andrew> Could someone please create an account called cvsup with no
> Andrew> privledges other than being able to read (_not_ write) the CVS
> Andrew> repositories.

> That's going to run into the group limit problem, won't it?
> Also, can you just use the anoncvs account for this?
> Or does this user not need to be able to make cvs locks?

I was kind of hopeing that all repositories were world readable.  As far
as I know it doesn't lock the file. I could use the anoncvs account if
that doesn't scare people too much :-)

> Andrew> PS: Where should the relevant cvsupd sources be archived?  Is
> Andrew> there a policy on importing binaries rather than building
> Andrew> things from scratch?  If I'm going to build things from
> Andrew> scratch then I'll need a few spare 100Mbs :-)

> I don't know.  Is there an RPM?  We could just install it that way.

RPM?  (Ok yes, I know what that is :-).

Checking the master FTP site, pre-built staticish binaries are available
(cvsupd, cvsup)are available.  Not RPMs.

The reason for thinking about doing a local build is that it would be in
line with Jasons approach when getting sourceware started - always have
the source - always have a way of building the source.

	Andrew

Re: A cvsup account..

[Andrew Cagney]

Excerpts from mail: 21-Mar-100 Re: A cvsup account.. Tom
Tromey@cygnus.com (663*)

> Andrew> Could someone please create an account called cvsup with no
> Andrew> privledges other than being able to read (_not_ write) the CVS
> Andrew> repositories.

> That's going to run into the group limit problem, won't it?
> Also, can you just use the anoncvs account for this?
> Or does this user not need to be able to make cvs locks?

I was kind of hopeing that all repositories were world readable.  As far
as I know it doesn't lock the file. I could use the anoncvs account if
that doesn't scare people too much :-)

> Andrew> PS: Where should the relevant cvsupd sources be archived?  Is
> Andrew> there a policy on importing binaries rather than building
> Andrew> things from scratch?  If I'm going to build things from
> Andrew> scratch then I'll need a few spare 100Mbs :-)

> I don't know.  Is there an RPM?  We could just install it that way.

RPM?  (Ok yes, I know what that is :-).

Checking the master FTP site, pre-built staticish binaries are available
(cvsupd, cvsup)are available.  Not RPMs.

The reason for thinking about doing a local build is that it would be in
line with Jasons approach when getting sourceware started - always have
the source - always have a way of building the source.

	Andrew

Re: A cvsup account..

[Jim Kingdon]

> The reason for thinking about doing a local build is that it would be in
> line with Jasons approach when getting sourceware started - always have
> the source - always have a way of building the source.

Well, with RPM packages from the usual places you have the source, it
is just in the source RPM rather than the binary RPM.

From my point of view it is pretty silly to be building things like
Apache, wu-ftpd, or Kerberos from source when people elsewhere in Red
Hat are already doing the exact same thing for the Linux product.
There are going to be exceptions here and there, of course, but as a
general rule/goal I'd like to run unhacked code and get our changes
(when needed) merged back in upstream.

I'd be glad to offer some kind of RPM tutorial (including building
from source) if lack of familiarity is the issue but it might be just
as easy to point to http://www.rpm.org/ .

CVSup, of course, is a whole different case because the source is in
Modula-3.  But I'm trying to play "someone else's issue" on that one
;-).

Re: A cvsup account..

[Jim Kingdon]

> The reason for thinking about doing a local build is that it would be in
> line with Jasons approach when getting sourceware started - always have
> the source - always have a way of building the source.

Well, with RPM packages from the usual places you have the source, it
is just in the source RPM rather than the binary RPM.

From my point of view it is pretty silly to be building things like
Apache, wu-ftpd, or Kerberos from source when people elsewhere in Red
Hat are already doing the exact same thing for the Linux product.
There are going to be exceptions here and there, of course, but as a
general rule/goal I'd like to run unhacked code and get our changes
(when needed) merged back in upstream.

I'd be glad to offer some kind of RPM tutorial (including building
from source) if lack of familiarity is the issue but it might be just
as easy to point to http://www.rpm.org/ .

CVSup, of course, is a whole different case because the source is in
Modula-3.  But I'm trying to play "someone else's issue" on that one
;-).

Re: A cvsup account..

[Jason Molenda]

On Tue, Mar 21, 2000 at 05:13:24PM -0500, Jim Kingdon wrote:

> From my point of view it is pretty silly to be building things like
> Apache, wu-ftpd, or Kerberos from source when people elsewhere in Red
> Hat are already doing the exact same thing for the Linux product.

I always liked building it myself because I could specifically enable
anything I needed, disable anything I wasn't using, and have complete
control over the program.

It'd take more work to familiarize myself with the program, but in
my humble experience, the RH builds weren't any better than what
I did on my own.

As sourceware has less active maintainership (surely the next
generation of sourceware is just down the road :-), using prebuilt
RPMs is not unreasonable.  

Actually, apache is a bad example because we use an unofficial
module, mod_gzip IIRC, which is not a part of the main distribution.
When a user's client supports compression, and the user requests
foo.html, if foo.html.gz exists, that is sent instead.  Huge
bandwidth savings for big files like on-line docs which can be
100-200k apiece.  I also generate .gz versions of the mailing list
indexes after a time period (month, quarter, year) has finished.
Try looking at some old archives -- notice how the date index loads
an awful lot faster than it should.  One big gotcha is that mod_gzip
does not check whether the foo.html timestamp is newer than
foo.html.gz, and if you have any server side include directives in
foo.html, they will not be expanded when the foo.html.gz is sent.

In addition, I use a hack written by DJ Delorie to Apache.  If you
have Apache set to treat files ending in ".html" as SSI files, then
Apache will not send a Last-Modified header for that file.  The
idea is that in foo.html, you might include bar.html.  Which one
should the L-M date list? What about dynamic content?  Does a L-M
header have any meaning if most of the page is generated on the
fly via SSI's?  Apache has some lameoid XBit (I forget the exact
term) mode where it will send a Last-Modified header for files if
their execute bit is set (some bit, I forget which).  DJ's hack
makes it so that the Last-Modified date for the source foo.html is
sent.

If you run a web server with SSI's ending in ".html" without this
(and without using the XBitHack thing), none of your documents will
ever have a Last-Modified header, and no client on the web will
ever cache your pages -- each time someone looks at a page, they
get to reload it.  If a page is long, and they keep coming back to
it, you're going to piss off slow-link users, and you're going to
waste a lot of your bandwidth.  It's important to fix, and the
Apache guys obviously know about the problem (XBitHack or whatever
has a short discussion of it in its docs), and it is doubtful that
they'd want DJ's hack.  A better fix might have a configuration
option in the httpd.conf which allows the administrator to specify
how last-modified headers should be generated for SSI files.


As for cvsup, sources are pretty useless for this, so might as well
go with prebuilt binaries.  For things installed on sourceware, I
always put the distribution files (source in most cases) in
/usr/local/src/<name> with a pointer to the master distribution
site in /usr/local/src/WHENCE.  I would often leave the build trees
in place, .o's and all, so that someone rebuilding something in
the future could see exactly how something was configured and built.
(read:  I often forgot how I built something, so I used it as a
crib sheet when I had to rebuild.)  We have so few things installed
on sourceware that the disk space usage is not significant.

Jason

Re: A cvsup account..

[Jason Molenda]

On Tue, Mar 21, 2000 at 05:13:24PM -0500, Jim Kingdon wrote:

> From my point of view it is pretty silly to be building things like
> Apache, wu-ftpd, or Kerberos from source when people elsewhere in Red
> Hat are already doing the exact same thing for the Linux product.

I always liked building it myself because I could specifically enable
anything I needed, disable anything I wasn't using, and have complete
control over the program.

It'd take more work to familiarize myself with the program, but in
my humble experience, the RH builds weren't any better than what
I did on my own.

As sourceware has less active maintainership (surely the next
generation of sourceware is just down the road :-), using prebuilt
RPMs is not unreasonable.  

Actually, apache is a bad example because we use an unofficial
module, mod_gzip IIRC, which is not a part of the main distribution.
When a user's client supports compression, and the user requests
foo.html, if foo.html.gz exists, that is sent instead.  Huge
bandwidth savings for big files like on-line docs which can be
100-200k apiece.  I also generate .gz versions of the mailing list
indexes after a time period (month, quarter, year) has finished.
Try looking at some old archives -- notice how the date index loads
an awful lot faster than it should.  One big gotcha is that mod_gzip
does not check whether the foo.html timestamp is newer than
foo.html.gz, and if you have any server side include directives in
foo.html, they will not be expanded when the foo.html.gz is sent.

In addition, I use a hack written by DJ Delorie to Apache.  If you
have Apache set to treat files ending in ".html" as SSI files, then
Apache will not send a Last-Modified header for that file.  The
idea is that in foo.html, you might include bar.html.  Which one
should the L-M date list? What about dynamic content?  Does a L-M
header have any meaning if most of the page is generated on the
fly via SSI's?  Apache has some lameoid XBit (I forget the exact
term) mode where it will send a Last-Modified header for files if
their execute bit is set (some bit, I forget which).  DJ's hack
makes it so that the Last-Modified date for the source foo.html is
sent.

If you run a web server with SSI's ending in ".html" without this
(and without using the XBitHack thing), none of your documents will
ever have a Last-Modified header, and no client on the web will
ever cache your pages -- each time someone looks at a page, they
get to reload it.  If a page is long, and they keep coming back to
it, you're going to piss off slow-link users, and you're going to
waste a lot of your bandwidth.  It's important to fix, and the
Apache guys obviously know about the problem (XBitHack or whatever
has a short discussion of it in its docs), and it is doubtful that
they'd want DJ's hack.  A better fix might have a configuration
option in the httpd.conf which allows the administrator to specify
how last-modified headers should be generated for SSI files.


As for cvsup, sources are pretty useless for this, so might as well
go with prebuilt binaries.  For things installed on sourceware, I
always put the distribution files (source in most cases) in
/usr/local/src/<name> with a pointer to the master distribution
site in /usr/local/src/WHENCE.  I would often leave the build trees
in place, .o's and all, so that someone rebuilding something in
the future could see exactly how something was configured and built.
(read:  I often forgot how I built something, so I used it as a
crib sheet when I had to rebuild.)  We have so few things installed
on sourceware that the disk space usage is not significant.

Jason

Re: A cvsup account..

[Jim Kingdon]

Thanks for the notes on building from source, Jason.

I see no reason to try to establish a policy on this (not least of
which because I doubt people would listen to some policy I tried to
hand down from above :-)), but I have taken your text about how to
build from source and added my own propaganda about packages and put
it at http://sourceware.cygnus.com/sourceware/install.html

I've also put your Apache notes at
http://sourceware.cygnus.com/sourceware/web.html

<handwaving mode>The kinds of fixes we've made, suitably
modified/rethought/redesigned/whatever, would probably benefit Apache
and the Red Hat packages of it, if anyone has the time to push them
upstream</handwaving>.

Re: A cvsup account..

[Jim Kingdon]

Thanks for the notes on building from source, Jason.

I see no reason to try to establish a policy on this (not least of
which because I doubt people would listen to some policy I tried to
hand down from above :-)), but I have taken your text about how to
build from source and added my own propaganda about packages and put
it at http://sourceware.cygnus.com/sourceware/install.html

I've also put your Apache notes at
http://sourceware.cygnus.com/sourceware/web.html

<handwaving mode>The kinds of fixes we've made, suitably
modified/rethought/redesigned/whatever, would probably benefit Apache
and the Red Hat packages of it, if anyone has the time to push them
upstream</handwaving>.