Re: PAM session support documentation

2005-05-04 Thread Derek Price
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Brian Murphy wrote:

 Hi Guys,
 I would like to commit the attached patch. It documents in
 the example files the necessary session lines in the PAM
 configuration file.

 I/we seem to have missed this when the session support was
 added. The manual has the necessary additions.

 OK with you?


Yeah, sure.  You're mostly in charge where the PAM support is concerned,
I think, as long as it remains possible to disable it and doesn't break
backwards compatibility anywhere, in the protocol, API, or otherwise.

Regards,

Derek
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (Cygwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCd5WyLD1OTBfyMaQRAkAwAJsHEU9IcFOl2rcZuawE/L1GdX7KvACg2iYR
j2vDG6yUzw/6aFC+/LquZrI=
=lO7j
-END PGP SIGNATURE-




___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs


Re: MacOS X 10.3.7 Build Problem After CVS CheckOut

2005-05-04 Thread Derek Price
This is a well-known problem.  The workaround is to use a build 
directory.  i.e.:

   cvs co ccvs
   cd ccvs
   mkdir build
   cd build
   ../configure
   make
I never thought it was worth coming up with a more automated solution, 
but you're welcome to try.  I would argue against changing the name of 
the executable though, and I'm not sure what else is workable.

Cheers,
Derek
Conrad T. Pino wrote:
I'm seeing the same build problem on both stable  feature:
Titanium:~/projects/cvs-1.12.12 conradtpino$ make
make  all-recursive
Making all in lib
make  all-am
make[3]: Nothing to be done for `all-am'.
Making all in zlib
make[2]: Nothing to be done for `all'.
Making all in diff
make[2]: Nothing to be done for `all'.
Making all in src
rm: cvs: is a directory
make[2]: *** [cvs] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2
Titanium:~/projects/cvs-1.12.12 conradtpino$
The problem occurs because the MacOS file system appears to
be case insensitive with respect to file names i.e. both of
the following do the same thing:
ls CVS
ls cvs
I'm seeing the error for the first time because I checked
out with a revision tag instead of downloading a tar ball.
I can work around the problem by using export instead of
checkout command.
The question becomes:  Is it worthwhile fixing the build
to deal with case insensitive UNIX file systems?
Conrad

___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs
 


___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs


RE: MacOS X 10.3.7 Build Problem After CVS CheckOut

2005-05-04 Thread Conrad T. Pino
 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Derek,

 From: Derek Price [mailto:[EMAIL PROTECTED]
 
 I never thought it was worth coming up with a more automated solution, 
 but you're welcome to try.  I would argue against changing the name of 
 the executable though, and I'm not sure what else is workable.

The configure script could test for the existence of a directory named
src/cvs and if true then execute a mkdir build command if build is
not already created.

That being said, how many shell variations need to be tested before we
commit such a fix assuming there are no objections?

 Cheers,

Ditto,

 Derek

Conrad

-BEGIN PGP SIGNATURE-
Version: PGP 7.0.4

iQA/AwUBQng1o7NM28ubzTo9EQJ4WwCgk0yMbtCgfIihIqdu4SfRVZx6bzcAn3aI
1QX5NKqIyvSn0RQn2k04rwkf
=5J85
-END PGP SIGNATURE-



___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs


Re: MacOS X 10.3.7 Build Problem After CVS CheckOut

2005-05-04 Thread Derek Price
Incidentally, I thought this was documented somewhere other than the 
email list, but I don't see it.  I've added a note to INSTALL on stable 
and INSTALL-CVSon feature.

Cheers,
Derek
Derek Price wrote:
This is a well-known problem.  The workaround is to use a build 
directory.  i.e.:

   cvs co ccvs
   cd ccvs
   mkdir build
   cd build
   ../configure
   make
I never thought it was worth coming up with a more automated solution, 
but you're welcome to try.  I would argue against changing the name of 
the executable though, and I'm not sure what else is workable.

Cheers,
Derek
Conrad T. Pino wrote:
I'm seeing the same build problem on both stable  feature:
Titanium:~/projects/cvs-1.12.12 conradtpino$ make
make  all-recursive
Making all in lib
make  all-am
make[3]: Nothing to be done for `all-am'.
Making all in zlib
make[2]: Nothing to be done for `all'.
Making all in diff
make[2]: Nothing to be done for `all'.
Making all in src
rm: cvs: is a directory
make[2]: *** [cvs] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2
Titanium:~/projects/cvs-1.12.12 conradtpino$
The problem occurs because the MacOS file system appears to
be case insensitive with respect to file names i.e. both of
the following do the same thing:
ls CVS
ls cvs
I'm seeing the error for the first time because I checked
out with a revision tag instead of downloading a tar ball.
I can work around the problem by using export instead of
checkout command.
The question becomes:  Is it worthwhile fixing the build
to deal with case insensitive UNIX file systems?
Conrad

___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs
 



___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs


Re: MacOS X 10.3.7 Build Problem After CVS CheckOut

2005-05-04 Thread Derek Price
Conrad T. Pino wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Derek,
 

From: Derek Price [mailto:[EMAIL PROTECTED]
I never thought it was worth coming up with a more automated solution, 
but you're welcome to try.  I would argue against changing the name of 
the executable though, and I'm not sure what else is workable.
   

The configure script could test for the existence of a directory named
src/cvs and if true then execute a mkdir build command if build is
not already created.
That being said, how many shell variations need to be tested before we
commit such a fix assuming there are no objections?
 

What good would it be to make the build directory if the user didn't 
know to cd there before building?  Also, once the src dir is configured, 
the build dir will refuse to be configured.  The user would have to 
`make distclean; cd build; ../configure' afterwards anyhow.  There might 
be a way to bootstrap that, but why not try something simpler, like just 
printing a nice, easy-to-spot-and-read warning message?

The test would be something like
$srcdir = $builddir  $fs_case_insensitive  test -z $exe_ext
I'm sure those var names are not correct, but you would have to make 
sure the latter test ran after all the tests that set the correct flags.

Cheers,
Derek
___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs


Re: [PATCH] pagealign_alloc: don't loop endlessly

2005-05-04 Thread Derek Price
Does the attached, more general, patch do the trick for you?

I think the problem is deeper - error() really needs a way to bypass the
memory allocation of the buffer routines, but this should work around
the problem for now.

Cheers,

Derek


Thorsten Glaser wrote:

Hello!

Please apply the following patch. It prevents GNU CVS 1.12.12
from looping endlessly and dumping core due to lack of stack
(recursion depth) when /dev/zero cannot be found, for example
in a chroot(2) environment.

I have copyright assignments for CVS filed with the FSF.

//mirabile



Index: src/error.c
===
RCS file: /cvs/ccvs/src/error.c,v
retrieving revision 1.42
diff -u -p -r1.42 error.c
--- src/error.c 18 Mar 2005 16:41:24 -  1.42
+++ src/error.c 4 May 2005 14:14:29 -
@@ -119,6 +119,10 @@ error (int status, int errnum, const cha
 char statcmdbuf[32];
 char *cmdbuf;
 char *emptybuf = ;
+static bool in_error = false;
+
+if (in_error) goto recursion_error;
+in_error = true;

 /* Initialize these to avoid a lot of special case error handling.  */
 buf = statbuf;
@@ -173,6 +177,9 @@ error (int status, int errnum, const cha
 /* Restore errno per our charter.  */
 errno = save_errno;

+/* Reset our recursion lock.  */
+in_error = false;
+
 /* Done.  */
 return;

@@ -195,6 +202,21 @@ memerror:
 #endif /* HAVE_SYSLOG_H */

 exit (EXIT_FAILURE);
+
+recursion_error:
+#if HAVE_SYSLOG_H
+syslog (LOG_DAEMON | LOG_EMERG,
+   error (%d, %d) called recursively.  Message was:,
+   status, errnum);
+
+va_start (args, message);
+vsyslog (LOG_DAEMON | LOG_EMERG, message, args);
+va_end (args);
+
+syslog (LOG_DAEMON | LOG_EMERG, Aborting.);
+#endif /* HAVE_SYSLOG_H */
+
+exit (EXIT_FAILURE);
 }




signature.asc
Description: OpenPGP digital signature
___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs

Re: [PATCH] pagealign_alloc: don't loop endlessly

2005-05-04 Thread Derek Price
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Thorsten Glaser wrote:

Derek Price dixit:

Yes, that's why I was suggesting to print the error message to stderr
so at least the client gets an idea about what happened and can slap
the server administrator. CVS does this for quite some occasions, for
example no space available in the server's temporary directory.

Could you point me at the code that does this?


Not out of the blue, I had to check. But it happens frequently
when e.g. the OpenBSD anoncvs servers are overloaded.


And where is the code that does this?

How much good would sending the message to stderr really do? This
problem can only occur on the server, where sending to stderr, at best,
can only be reported to the client as an unrecognized protocol response,
if reported at all, once the network buffers are disabled (the network
buffer code is what is calling pagealign_alloc() here).


No, it's actually displayed by the client (with my first diff).


I'm fairly certain it shouldn't be consistently displayed this way.  It
might ocassionally appear in the context of Unrecognized response from
server: `some message on stderr'.

Can you provide me with a test case that reproduces this behavior?

Cheers,

Derek
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (Cygwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCeQxpLD1OTBfyMaQRAgrVAJ9ZeNqHtuhH3dTjgZjAMLLpvr53qQCdFOWC
2Ccd7RA08CDF3ceEpfpmFtc=
=bics
-END PGP SIGNATURE-




___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs


Re: [PATCH] pagealign_alloc: don't loop endlessly

2005-05-04 Thread Derek Price
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Thorsten Glaser wrote:

Derek Price dixit:

Does the attached, more general, patch do the trick for you?


It does, but I do not get a diagnostic, neither on stderr
(CVS output) nor in syslog on server or client. This is
probably because the CVS server is running in a chroot.

I suggest a diagnostics on stderr, plus - in this case - the
actual solution is to add a device node into the chroot, and
from a recursion error nobody would get the idea.


My patch logs the actual error message to the syslog too (via the
vsyslog() call), but if your chroot is preventing access to the syslog,
that wouldn't help anyhow.

Cheers,

Derek
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (Cygwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCeN8FLD1OTBfyMaQRAiHfAKDcLW4aGk+Ek9JHVeTSVbUqERJiqQCguXyo
Xcovfa0jOnzz+159lb0oJNw=
=RGRl
-END PGP SIGNATURE-




___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs


Re: MacOS X 10.3.7 Build Problem After CVS CheckOut

2005-05-04 Thread Mark D. Baushke
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Conrad T. Pino [EMAIL PROTECTED] writes:

 I'm seeing the same build problem on both stable  feature:
 
 Titanium:~/projects/cvs-1.12.12 conradtpino$ make
 make  all-recursive
 Making all in lib
 make  all-am
 make[3]: Nothing to be done for `all-am'.
 Making all in zlib
 make[2]: Nothing to be done for `all'.
 Making all in diff
 make[2]: Nothing to be done for `all'.
 Making all in src
 rm: cvs: is a directory
 make[2]: *** [cvs] Error 1
 make[1]: *** [all-recursive] Error 1
 make: *** [all] Error 2
 Titanium:~/projects/cvs-1.12.12 conradtpino$
 
 The problem occurs because the MacOS file system appears to
 be case insensitive with respect to file names i.e. both of
 the following do the same thing:
 
   ls CVS
   ls cvs
 
 I'm seeing the error for the first time because I checked
 out with a revision tag instead of downloading a tar ball.
 
 I can work around the problem by using export instead of
 checkout command.
 
 The question becomes:  Is it worthwhile fixing the build
 to deal with case insensitive UNIX file systems?

The typicaly way that I build on case-insensitive filesystems is like
this:

   cvs checkout ccvs
   cd ccvs
   mkdir objdir
   cd objdir
   ../configure  make  make check

this means that all of the derrived files are in the ccvs/objdir
subdirectory. If I am going to build for multiple architectures
out of the same set of sources, I have been known to use the
following directory names:

obj.macosx2 # MacOS 10.2
obj.macosx3 # MacOS 10.3
obj.solsparc9   # Solaris 9 on Sparc hardware
obj.solsparc8   # Solaris 8 on Sparc hardware
obj.solsparc7   # Solaris 7 on Sparc hardware
obj.aix43   # AIX 4.3
obj.fbsd42  # FreeBSD 4.2-RELEASE
obj.fbsd410 # FreeBSD 4.10-RELEASE
obj.nbsd16  # NetBSD 1.6
obj.nbsd299 # NetBSD 2.99.15
obj.rh73# Redhat 7.3 i386 GNU/Linux 
obj.fc3 # Fedora Core 3 i386 GNU/Linux
obj.unicos  # Unicos 9.0 Cray Y-MP EL

instead of 'objdir' as the place where I build and test out of one
checkout of the sources...

Your experience may be different.

I almost never actually build directly in the 'ccvs' directory as it was
checked out (I try it once per release as we are getting close to make
sure it still works).

Enjoy!
-- Mark
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.3 (FreeBSD)

iD8DBQFCeGT03x41pRYZE/gRAvOQAKDKvElDg9X4RFPYGc5vtK2q1F0xGwCgxBov
+hBA43zL1skrlMklP/GJtf0=
=U12V
-END PGP SIGNATURE-


___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs


Re: [PATCH] pagealign_alloc: don't loop endlessly

2005-05-04 Thread Derek Price
I've attached a revised version of my earlier patch that preserves more
information and avoids problems when the exit handlers call error()
after error() calls exit().

Regards,

Derek
Index: src/ChangeLog
===
RCS file: /cvs/ccvs/src/ChangeLog,v
retrieving revision 1.3186
diff -u -p -r1.3186 ChangeLog
--- src/ChangeLog   4 May 2005 02:48:16 -   1.3186
+++ src/ChangeLog   4 May 2005 20:14:40 -
@@ -1,3 +1,7 @@
+2005-05-04  Derek Price  [EMAIL PROTECTED]
+
+   * error.c (error): Avoid recursion and syslog the problem.
+
 2005-05-03  Derek Price  [EMAIL PROTECTED]

* tag.c (is_in_val_tags): Remove unnecessary existance checking for the
Index: src/error.c
===
RCS file: /cvs/ccvs/src/error.c,v
retrieving revision 1.42
diff -u -p -r1.42 error.c
--- src/error.c 18 Mar 2005 16:41:24 -  1.42
+++ src/error.c 4 May 2005 20:14:40 -
@@ -120,16 +120,26 @@ error (int status, int errnum, const cha
 char *cmdbuf;
 char *emptybuf = ;

+static const char *last_message = NULL;
+static va_list last_args;
+static int last_status;
+static int last_errnum;
+
+if (last_message) goto recursion_error;
+last_message = message;
+va_start (args, message);
+last_args = args;
+last_status = status;
+last_errnum = errnum;
+
 /* Initialize these to avoid a lot of special case error handling.  */
 buf = statbuf;
 buf2 = statbuf2;
 cmdbuf = emptybuf;

 /* Expand the message the user passed us.  */
-va_start (args, message);
 length = sizeof (statbuf);
 buf = vasnprintf (statbuf, length, message, args);
-va_end (args);
 if (!buf) goto memerror;

 /* Expand the cvs commmand name to cmd or [cmd aborted].
@@ -161,6 +171,12 @@ error (int status, int errnum, const cha
 /* Send the final message to the client or log it.  */
 cvs_outerr (buf2, length);

+/* Reset our recursion lock.  This needs to be done before the call to
+ * exit() to allow the exit handlers to make calls to error().
+ */
+last_message = NULL;
+va_end (args);
+
 /* Done, if we're exiting.  */
 if (status)
exit (EXIT_FAILURE);
@@ -194,6 +210,37 @@ memerror:
 syslog (LOG_DAEMON | LOG_EMERG, Memory exhausted.  Aborting.);
 #endif /* HAVE_SYSLOG_H */

+goto sidestep_done;
+
+recursion_error:
+#if HAVE_SYSLOG_H
+/* Syslog the problem since recursion probably means that we encountered an
+ * error while attempting to send the last error message to the client.
+ */
+
+syslog (LOG_DAEMON | LOG_EMERG,
+   error (%d, %d) called recursively.  Original message was:,
+   last_status, last_errnum);
+vsyslog (LOG_DAEMON | LOG_EMERG, last_message, last_args);
+
+
+syslog (LOG_DAEMON | LOG_EMERG,
+error (%d, %d) called recursively.  Second message was:,
+   status, errnum);
+va_start (args, message);
+vsyslog (LOG_DAEMON | LOG_EMERG, message, args);
+va_end (args);
+
+syslog (LOG_DAEMON | LOG_EMERG, Aborting.);
+#endif /* HAVE_SYSLOG_H */
+
+sidestep_done:
+/* Reset our recursion lock.  This needs to be done before the call to
+ * exit() to allow the exit handlers to make calls to error().
+ */
+last_message = NULL;
+va_end (last_args);
+
 exit (EXIT_FAILURE);
 }



signature.asc
Description: OpenPGP digital signature
___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs