public inbox for gnats-devel@sourceware.org
 help / color / mirror / Atom feed
* CVS, Documentation, TODO Lists, New Maintainer, and Stuff
@ 2004-06-10 21:20 Chad C. Walstrom
  2004-06-10 21:44 ` Chad C. Walstrom
                   ` (2 more replies)
  0 siblings, 3 replies; 22+ messages in thread
From: Chad C. Walstrom @ 2004-06-10 21:20 UTC (permalink / raw)
  To: help-gnats

On Thu, Jun 10, 2004 at 12:57:06PM +0200, Yngve Svendsen wrote:
> These features look useful indeed, and I would strongly recommend that
> Mel gets CVS access.

I sent him email about getting an account on savannah.gnu.org.  In order
to get CVS access, you need to import your ssh public key into your
account settings on savannah.  Then ask for membership to the group from
one of the administrators listed (which I need to ask you or Andrew to
appoint me to, BTW).

> One more thing, though. We should have a strict policy of keeping the
> docs up to date in synch with code checkins

Absolutely.  The only way to keep documentation current is to stay on
top of it.  I tried using the newer cvs2cl last night to update the
ChangeLogs, but the formatting is off.  It would probably make sense to
have a changelog target in the root Makefile.in so that we won't have to
remember how to reinvoke it every time.

Additionally, the cvs2cl doesn't pick out details that weren't placed in
the cvs log entry, such as the enclosed function name in some entries.
I'm not sure such detail is THAT important, but it's also possible to
update the log entries to contain that information too.

Perhaps it's time to add in log templates and a user list to the CVSROOT
for username-to-emailaddress resolution; perhaps an AUTHORS file should
be created.

On to the TODO file...  I use this very nice console tool called
devtodo, executed as "todo".  It creates an outlined TODO list saved in
XML format as ".todo".  Each subdirectory can have it's own .todo file,
and it's fairly simple to remap your shell "cd" command to display the
TODO list for that directory when you change into it.

In any case, I'm working on rewriting the current TODO file in the root
source directory using this devtodo tool.  We can start organizing some
of the feature requests and prominent bug fixes to a release schedule.
For example (off the top of my head, not referencing the current TODO
list):

    GNATS General TODO List
    1. Release 4.1
        1. Prepend $(DESTDIR) varibles to each install target (Chad)
        2. Clean up send-pr (Chad)
        3. Add missing manpages
        4. Update Documentation
    2. Release 4.2
        1. Mail handling enhancements (Mel)
            1. Mail-based manipulation of GNATS DB (Mel)
            2. Trigger-based mail format replies
            3. Enable To: PR#[DATABASE]@host.domain.tld syntax to queue-pr
        2. MIME Handling
            1. Convert HTML to TEXT
            2. Detach Files Appropriately for GNATS DB format
        3. Add RDBMS Backend Support (Mel)
            1. Oracle Support
            2. DB Abstraction layer
    3. Release 4.3
        1. Mail handling enhancements
            1. Maintain mbox archive of all emails
            2. Fake Audit trail entries as emails and append to mbox archive
            3. Continue to use existing PR datafile for logging events,
               keywords, and metadata
        2. Account Enhancement
            1. PAM authentication

So on, and so forth. ;-P

-- 
Chad Walstrom <chewie@wookimus.net>                 | a.k.a. ^chewie
http://www.wookimus.net/                            | s.k.a. gunnarr


_______________________________________________
Help-gnats mailing list
Help-gnats@gnu.org
http://lists.gnu.org/mailman/listinfo/help-gnats

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: CVS, Documentation, TODO Lists, New Maintainer, and Stuff
  2004-06-10 21:20 CVS, Documentation, TODO Lists, New Maintainer, and Stuff Chad C. Walstrom
@ 2004-06-10 21:44 ` Chad C. Walstrom
  2004-06-13  8:51   ` Mel Hatzis
  2004-06-13 23:01   ` Andrew Gray
  2004-06-11 22:28 ` Yngve Svendsen
  2004-06-14 17:07 ` Pankaj K Garg
  2 siblings, 2 replies; 22+ messages in thread
From: Chad C. Walstrom @ 2004-06-10 21:44 UTC (permalink / raw)
  To: help-gnats

OH, about the New Maintainer portion of the subject...  I am officially
appointed as the New Maintainer of GNATS!  I will be putting in at least
2 hours per week on the project, but realistically it'll probably be
more.

So, I suppose it's time to start thinking about what we would like for
our next release and plan accordingly.  Mel, I look forward to merging
in your enhancements!

-- 
Chad Walstrom <chewie@wookimus.net>                 | a.k.a. ^chewie
http://www.wookimus.net/                            | s.k.a. gunnarr


_______________________________________________
Help-gnats mailing list
Help-gnats@gnu.org
http://lists.gnu.org/mailman/listinfo/help-gnats

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: CVS, Documentation, TODO Lists, New Maintainer, and Stuff
  2004-06-10 21:20 CVS, Documentation, TODO Lists, New Maintainer, and Stuff Chad C. Walstrom
  2004-06-10 21:44 ` Chad C. Walstrom
@ 2004-06-11 22:28 ` Yngve Svendsen
  2004-06-14 17:07 ` Pankaj K Garg
  2 siblings, 0 replies; 22+ messages in thread
From: Yngve Svendsen @ 2004-06-11 22:28 UTC (permalink / raw)
  To: Chad C. Walstrom; +Cc: help-gnats

Chad C. Walstrom wrote:

>On Thu, Jun 10, 2004 at 12:57:06PM +0200, Yngve Svendsen wrote:
>  
>
>>These features look useful indeed, and I would strongly recommend that
>>Mel gets CVS access.
>>    
>>
>
>I sent him email about getting an account on savannah.gnu.org.  In order
>to get CVS access, you need to import your ssh public key into your
>account settings on savannah.  Then ask for membership to the group from
>one of the administrators listed (which I need to ask you or Andrew to
>appoint me to, BTW).
>  
>
Congratulations on your appointment as maintainer! I have given you 
Project Admin permissions for GNATS on Savannah.

The TODO section looks good and very useful. I think you have captured 
well the different themes and suggestions that have come up lately, and 
the prioritization and separation into releases looks about right (I 
think 4.2, with RDBMS backend support, would be better named 5.0, but 
that we can argue about later).

I hope to be able to do some doc work beginning late summer, but please 
don't stick my name on the TODO doc items yet -- I am not yet sure how 
much time I will have for that.

- Yngve


_______________________________________________
Help-gnats mailing list
Help-gnats@gnu.org
http://lists.gnu.org/mailman/listinfo/help-gnats

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: CVS, Documentation, TODO Lists, New Maintainer, and Stuff
  2004-06-10 21:44 ` Chad C. Walstrom
@ 2004-06-13  8:51   ` Mel Hatzis
  2004-06-13 23:01   ` Andrew Gray
  1 sibling, 0 replies; 22+ messages in thread
From: Mel Hatzis @ 2004-06-13  8:51 UTC (permalink / raw)
  To: help-gnats


On Jun 10, 2004, at 2:02 PM, Chad C. Walstrom wrote:

> OH, about the New Maintainer portion of the subject...  I am officially
> appointed as the New Maintainer of GNATS!  I will be putting in at 
> least
> 2 hours per week on the project, but realistically it'll probably be
> more.
>
> So, I suppose it's time to start thinking about what we would like for
> our next release and plan accordingly.  Mel, I look forward to merging
> in your enhancements!

Excellent! I've started work on the PostgreSQL backend to supplement
the Oracle & Flat-File backends which are currently supported by the
gnats-dbi enhancement.

I plan on setting up a savannah account sometime next week...I have
too much going on at work this week. Thanks for the pointers.

--
Mel Hatzis



_______________________________________________
Help-gnats mailing list
Help-gnats@gnu.org
http://lists.gnu.org/mailman/listinfo/help-gnats

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: CVS, Documentation, TODO Lists, New Maintainer, and Stuff
  2004-06-10 21:44 ` Chad C. Walstrom
  2004-06-13  8:51   ` Mel Hatzis
@ 2004-06-13 23:01   ` Andrew Gray
  1 sibling, 0 replies; 22+ messages in thread
From: Andrew Gray @ 2004-06-13 23:01 UTC (permalink / raw)
  To: help-gnats

> OH, about the New Maintainer portion of the subject...  I am officially
> appointed as the New Maintainer of GNATS!  I will be putting in at least

Congratulations on your appointment as the New Maintainer of GNATS!
Also, thank you for being prepared to take on this role.  I am sure
you will do a much better job as maintainer than I have been recently.

-- 
Andrew Gray




_______________________________________________
Help-gnats mailing list
Help-gnats@gnu.org
http://lists.gnu.org/mailman/listinfo/help-gnats

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: CVS, Documentation, TODO Lists, New Maintainer, and Stuff
  2004-06-10 21:20 CVS, Documentation, TODO Lists, New Maintainer, and Stuff Chad C. Walstrom
  2004-06-10 21:44 ` Chad C. Walstrom
  2004-06-11 22:28 ` Yngve Svendsen
@ 2004-06-14 17:07 ` Pankaj K Garg
  2004-06-14 17:16   ` Chad C. Walstrom
  2 siblings, 1 reply; 22+ messages in thread
From: Pankaj K Garg @ 2004-06-14 17:07 UTC (permalink / raw)
  To: Chad C. Walstrom; +Cc: help-gnats

Chad C. Walstrom wrote:
>         2. Account Enhancement
>             1. PAM authentication
Chad,

  Is anyone signed up for adding PAM authentication support yet? If not, 
I can sign up for it.

Pankaj

-- 
Pankaj K Garg                         garg@zeesource.net
1684 Nightingale Avenue               408-373-4027
Suite 201                             408-733-2737(fax)
Sunnyvale, CA 94087

http://www.zeesource.net              http://home.earthlink.net/~gargp



_______________________________________________
Help-gnats mailing list
Help-gnats@gnu.org
http://lists.gnu.org/mailman/listinfo/help-gnats

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: CVS, Documentation, TODO Lists, New Maintainer, and Stuff
  2004-06-14 17:07 ` Pankaj K Garg
@ 2004-06-14 17:16   ` Chad C. Walstrom
  2004-06-20 17:39     ` PAM Authentication Patch Pankaj K Garg
  0 siblings, 1 reply; 22+ messages in thread
From: Chad C. Walstrom @ 2004-06-14 17:16 UTC (permalink / raw)
  To: help-gnats


[-- Attachment #1.1: Type: text/plain, Size: 554 bytes --]

Pankaj K Garg wrote:
> Is anyone signed up for adding PAM authentication support yet? If not,
> I can sign up for it.

No, no one has signed up for this yet.  I placed your name in the TODO
list and updated it in CVS.  I don't plan on making ChangeLog entries
for these files (.todo and TODO), though I will note the changes made in
the cvs log entry.  Welcome aboard!  I look forward to getting your
patches!

-- 
Chad Walstrom <chewie@wookimus.net>           http://www.wookimus.net/
           assert(expired(knowledge)); /* core dump */

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 140 bytes --]

_______________________________________________
Help-gnats mailing list
Help-gnats@gnu.org
http://lists.gnu.org/mailman/listinfo/help-gnats

^ permalink raw reply	[flat|nested] 22+ messages in thread

* PAM Authentication Patch
  2004-06-14 17:16   ` Chad C. Walstrom
@ 2004-06-20 17:39     ` Pankaj K Garg
       [not found]       ` <gargp@earthlink.net>
  2004-06-21 16:13       ` PAM Authentication Patch Chad Walstrom
  0 siblings, 2 replies; 22+ messages in thread
From: Pankaj K Garg @ 2004-06-20 17:39 UTC (permalink / raw)
  To: help-gnats

[-- Attachment #1: Type: text/plain, Size: 1722 bytes --]

I'm attaching a patch for enabling PAM authentication support.

To keep the patch file small, I've not included the diffs to the files
'configure' and 'gnats/configure'. Use autoconf to generate these two 
files. If you need the generated files, let me know and I'll create 
another patch.

PAM support can now be enabled by using '--enable-pam' switch to configure.

With PAM support enabled, you can put an entry in the gantsd.user_access 
file as:

   <user>:$p$:<access-level>

  and the authentication for the user will be done against the 
configured PAM modules.

  The name of the PAM service is taken from the DEFAULT_GANTS_SERVICE 
define, so by default it should be 'support'. Hence, you can configure 
PAM by creating the file /etc/pam.d/support on RH Linux.

  I've tried to make appropriate changes to the documentation. Let me 
know if any other document requires update.

  I've done some preliminary testing on my RH 9.0 Linux. Please let me 
know if there's any problem with it.

Pankaj

Chad C. Walstrom wrote:
> Pankaj K Garg wrote:
> 
>>Is anyone signed up for adding PAM authentication support yet? If not,
>>I can sign up for it.
> 
> 
> No, no one has signed up for this yet.  I placed your name in the TODO
> list and updated it in CVS.  I don't plan on making ChangeLog entries
> for these files (.todo and TODO), though I will note the changes made in
> the cvs log entry.  Welcome aboard!  I look forward to getting your
> patches!

-- 
Pankaj K Garg                         garg@zeesource.net
1684 Nightingale Avenue               408-373-4027
Suite 201                             408-733-2737(fax)
Sunnyvale, CA 94087

http://www.zeesource.net              http://home.earthlink.net/~gargp


[-- Attachment #2: pam_patch.out --]
[-- Type: text/plain, Size: 17955 bytes --]

? autom4te.cache
? pamdiffs.out
? gnats/autom4te.cache
? libiberty/xhost-mkfrag
Index: doc/gnats.texi
===================================================================
RCS file: /cvsroot/gnats/gnats/doc/gnats.texi,v
retrieving revision 1.44
diff -u -p -r1.44 gnats.texi
--- doc/gnats.texi	30 Aug 2003 07:55:06 -0000	1.44
+++ doc/gnats.texi	20 Jun 2004 16:34:24 -0000
@@ -1670,8 +1670,9 @@ string @samp{$1$}.@footnote{Some systems
 methods.  In FreeBSD, for instance, a prefix of @samp{$2$} implies
 Blowfish encoding.  @sc{gnats} will happily accept any encryption that
 the OS supports.} Passwords encrypted by @code{crypt()} should have no
-prefix. If no password is given then users can login with an empty
-password string.
+prefix. If you want to authenticate users with PAM authentication
+module, then supply a @samp{$p$} for the password entry. If no
+password is given then users can login with an empty password string.
 
 A @code{gnats-passwd} tool to manage @file{gnatsd.user_access} files is
 planned.  In the meantime, @code{crypt()} passwords can be generated by
Index: gnats/acconfig.h
===================================================================
RCS file: /cvsroot/gnats/gnats/gnats/acconfig.h,v
retrieving revision 1.3
diff -u -p -r1.3 acconfig.h
--- gnats/acconfig.h	26 May 2001 20:42:30 -0000	1.3
+++ gnats/acconfig.h	20 Jun 2004 16:34:24 -0000
@@ -26,3 +26,8 @@ Software Foundation, 59 Temple Place - S
 
 /* Define if strftime supports %z. */
 #undef HAVE_STRFTIME_WITH_Z
+
+/* Define to enable system authentication with PAM instead of using the simple
+   getpwnam interface. This allows authentication (in theory) with any PAM
+   module, e.g. on systems with shadow passwords or via LDAP */
+#undef HAVE_PAM
Index: gnats/autoconf.h.in
===================================================================
RCS file: /cvsroot/gnats/gnats/gnats/autoconf.h.in,v
retrieving revision 1.11
diff -u -p -r1.11 autoconf.h.in
--- gnats/autoconf.h.in	6 Jan 2002 16:16:45 -0000	1.11
+++ gnats/autoconf.h.in	20 Jun 2004 16:34:24 -0000
@@ -1,143 +1,212 @@
-/* autoconf.h.in.  Generated automatically from configure.in by autoheader 2.13.  */
+/* autoconf.h.in.  Generated from configure.in by autoheader.  */
+/* GNATS specific autoconf symbols.
+   Copyright (C) 2001 Milan Zamazal
+   Copyright (C) 1995, 1996 ??? (FIXME, see ChangeLog.v3)
+
+This file is part of GNU GNATS.
+
+GNU GNATS is free software; you can redistribute it and/or modify
+it under the terms of the GNU General Public License as published by
+the Free Software Foundation; either version 2, or (at your option)
+any later version.
+
+GNU GNATS is distributed in the hope that it will be useful,
+but WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+GNU General Public License for more details.
+
+You should have received a copy of the GNU General Public License
+along with GNU GNATS; see the file COPYING.  If not, write to the Free
+Software Foundation, 59 Temple Place - Suite 330, Boston, MA 02111, USA.  */
 
-/* Define if on AIX 3.
-   System headers sometimes define this.
-   We just want to avoid a redefinition error message.  */
-#ifndef _ALL_SOURCE
-#undef _ALL_SOURCE
-#endif
+/* Define if you have MIT Kerberos version 4 available.  */
+#undef HAVE_KERBEROS
 
-/* Define if using alloca.c.  */
-#undef C_ALLOCA
+/* Define if your system has socklen_t (glibc?) */
+#undef HAVE_SOCKLEN_T
 
-/* Define to one of _getb67, GETB67, getb67 for Cray-2 and Cray-YMP systems.
-   This function is required for alloca.c support on those systems.  */
+/* Define if strftime supports %z. */
+#undef HAVE_STRFTIME_WITH_Z
+
+/* Define to enable system authentication with PAM instead of using the simple
+   getpwnam interface. This allows authentication (in theory) with any PAM
+   module, e.g. on systems with shadow passwords or via LDAP */
+#undef HAVE_PAM
+
+/* Define to one of `_getb67', `GETB67', `getb67' for Cray-2 and Cray-YMP
+   systems. This function is required for `alloca.c' support on those systems.
+   */
 #undef CRAY_STACKSEG_END
 
-/* Define if you have alloca, as a function or macro.  */
+/* Define to 1 if using `alloca.c'. */
+#undef C_ALLOCA
+
+/* Define to 1 if you have `alloca', as a function or macro. */
 #undef HAVE_ALLOCA
 
-/* Define if you have <alloca.h> and it should be used (not on Ultrix).  */
+/* Define to 1 if you have <alloca.h> and it should be used (not on Ultrix).
+   */
 #undef HAVE_ALLOCA_H
 
-/* Define if on MINIX.  */
-#undef _MINIX
-
-/* Define if the system does not provide POSIX.1 features except
-   with this defined.  */
-#undef _POSIX_1_SOURCE
-
-/* Define if you need to in order for stat and other things to work.  */
-#undef _POSIX_SOURCE
-
-/* Define to `unsigned' if <sys/types.h> doesn't define.  */
-#undef size_t
-
-/* If using the C implementation of alloca, define if you know the
-   direction of stack growth for your system; otherwise it will be
-   automatically deduced at run-time.
- STACK_DIRECTION > 0 => grows toward higher addresses
- STACK_DIRECTION < 0 => grows toward lower addresses
- STACK_DIRECTION = 0 => direction of growth unknown
- */
-#undef STACK_DIRECTION
+/* Define to 1 if you have the <crypt.h> header file. */
+#undef HAVE_CRYPT_H
 
-/* Define if you have the ANSI C header files.  */
-#undef STDC_HEADERS
+/* Whether unsetenv is present in headers. */
+#undef HAVE_DECL_UNSETENV
 
-/* Define if you have MIT Kerberos version 4 available.  */
-#undef HAVE_KERBEROS
+/* Define to 1 if you have the <dirent.h> header file, and it defines `DIR'.
+   */
+#undef HAVE_DIRENT_H
 
-/* Define if your system has socklen_t (glibc?) */
-#undef HAVE_SOCKLEN_T
+/* Define to 1 if you have the <fcntl.h> header file. */
+#undef HAVE_FCNTL_H
 
-/* Define if you have the ftime function.  */
+/* Define to 1 if you have the `ftime' function. */
 #undef HAVE_FTIME
 
-/* Define if you have the krb_get_err_text function.  */
+/* Define to 1 if you have the <inttypes.h> header file. */
+#undef HAVE_INTTYPES_H
+
+/* Define to 1 if you have the `krb_get_err_text' function. */
 #undef HAVE_KRB_GET_ERR_TEXT
 
-/* Define if you have the mkdir function.  */
-#undef HAVE_MKDIR
+/* Define to 1 if you have the `crypt' library (-lcrypt). */
+#undef HAVE_LIBCRYPT
 
-/* Define if you have the mkstemp function.  */
-#undef HAVE_MKSTEMP
+/* Define to 1 if you have the `gen' library (-lgen). */
+#undef HAVE_LIBGEN
 
-/* Define if you have the mktemp function.  */
-#undef HAVE_MKTEMP
+/* Define to 1 if you have the <libgen.h> header file. */
+#undef HAVE_LIBGEN_H
 
-/* Define if you have the unsetenv function.  */
-#undef HAVE_UNSETENV
+/* Define to 1 if you have the `inet' library (-linet). */
+#undef HAVE_LIBINET
 
-/* Define if you have the <crypt.h> header file.  */
-#undef HAVE_CRYPT_H
+/* Define to 1 if you have the `intl' library (-lintl). */
+#undef HAVE_LIBINTL
 
-/* Define if you have the <dirent.h> header file.  */
-#undef HAVE_DIRENT_H
+/* Define to 1 if you have the `malloc' library (-lmalloc). */
+#undef HAVE_LIBMALLOC
 
-/* Define if you have the <fcntl.h> header file.  */
-#undef HAVE_FCNTL_H
+/* Define to 1 if you have the `nsl' library (-lnsl). */
+#undef HAVE_LIBNSL
 
-/* Define if you have the <libgen.h> header file.  */
-#undef HAVE_LIBGEN_H
+/* Define to 1 if you have the `socket' library (-lsocket). */
+#undef HAVE_LIBSOCKET
 
-/* Define if you have the <limits.h> header file.  */
+/* Define to 1 if you have the <limits.h> header file. */
 #undef HAVE_LIMITS_H
 
-/* Define if you have the <machine/endian.h> header file.  */
+/* Define to 1 if you have the <machine/endian.h> header file. */
 #undef HAVE_MACHINE_ENDIAN_H
 
-/* Define if you have the <memory.h> header file.  */
+/* Define to 1 if you have the <memory.h> header file. */
 #undef HAVE_MEMORY_H
 
-/* Define if you have the <ndir.h> header file.  */
+/* Define to 1 if you have the `mkdir' function. */
+#undef HAVE_MKDIR
+
+/* Define to 1 if you have the `mkstemp' function. */
+#undef HAVE_MKSTEMP
+
+/* Define to 1 if you have the `mktemp' function. */
+#undef HAVE_MKTEMP
+
+/* Define to 1 if you have the <ndir.h> header file, and it defines `DIR'. */
 #undef HAVE_NDIR_H
 
-/* Define if you have the <netdb.h> header file.  */
+/* Define to 1 if you have the <netdb.h> header file. */
 #undef HAVE_NETDB_H
 
-/* Define if you have the <string.h> header file.  */
+/* Define to enable system authentication with PAM instead of using the simple
+   getpwnam interface. This allows authentication (in theory) with any PAM
+   module, e.g. on systems with shadow passwords or via LDAP */
+#undef HAVE_PAM
+
+/* Define to 1 if you have the <stdint.h> header file. */
+#undef HAVE_STDINT_H
+
+/* Define to 1 if you have the <stdlib.h> header file. */
+#undef HAVE_STDLIB_H
+
+/* Define to 1 if you have the <strings.h> header file. */
+#undef HAVE_STRINGS_H
+
+/* Define to 1 if you have the <string.h> header file. */
 #undef HAVE_STRING_H
 
-/* Define if you have the <sys/dir.h> header file.  */
+/* Define to 1 if you have the <syslog.h> header file. */
+#undef HAVE_SYSLOG_H
+
+/* Define to 1 if you have the <sys/dir.h> header file, and it defines `DIR'.
+   */
 #undef HAVE_SYS_DIR_H
 
-/* Define if you have the <sys/ndir.h> header file.  */
+/* Define to 1 if you have the <sys/ndir.h> header file, and it defines `DIR'.
+   */
 #undef HAVE_SYS_NDIR_H
 
-/* Define if you have the <sys/select.h> header file.  */
+/* Define to 1 if you have the <sys/select.h> header file. */
 #undef HAVE_SYS_SELECT_H
 
-/* Define if you have the <syslog.h> header file.  */
-#undef HAVE_SYSLOG_H
+/* Define to 1 if you have the <sys/stat.h> header file. */
+#undef HAVE_SYS_STAT_H
+
+/* Define to 1 if you have the <sys/types.h> header file. */
+#undef HAVE_SYS_TYPES_H
 
-/* Define if you have the <unistd.h> header file.  */
+/* Define to 1 if you have the <unistd.h> header file. */
 #undef HAVE_UNISTD_H
 
-/* Define if you have the crypt library (-lcrypt).  */
-#undef HAVE_LIBCRYPT
+/* Define to 1 if you have the `unsetenv' function. */
+#undef HAVE_UNSETENV
 
-/* Define if you have the gen library (-lgen).  */
-#undef HAVE_LIBGEN
+/* Define to the address where bug reports for this package should be sent. */
+#undef PACKAGE_BUGREPORT
 
-/* Define if you have the inet library (-linet).  */
-#undef HAVE_LIBINET
+/* Define to the full name of this package. */
+#undef PACKAGE_NAME
 
-/* Define if you have the intl library (-lintl).  */
-#undef HAVE_LIBINTL
+/* Define to the full name and version of this package. */
+#undef PACKAGE_STRING
 
-/* Define if you have the malloc library (-lmalloc).  */
-#undef HAVE_LIBMALLOC
+/* Define to the one symbol short name of this package. */
+#undef PACKAGE_TARNAME
 
-/* Define if you have the nsl library (-lnsl).  */
-#undef HAVE_LIBNSL
+/* Define to the version of this package. */
+#undef PACKAGE_VERSION
 
-/* Define if you have the socket library (-lsocket).  */
-#undef HAVE_LIBSOCKET
+/* If using the C implementation of alloca, define if you know the
+   direction of stack growth for your system; otherwise it will be
+   automatically deduced at run-time.
+	STACK_DIRECTION > 0 => grows toward higher addresses
+	STACK_DIRECTION < 0 => grows toward lower addresses
+	STACK_DIRECTION = 0 => direction of growth unknown */
+#undef STACK_DIRECTION
 
-/* Whether unsetenv is present in headers. */
-#undef HAVE_DECL_UNSETENV
+/* Define to 1 if you have the ANSI C header files. */
+#undef STDC_HEADERS
 
-/* Whether unsetenv is present in headers. */
-#undef HAVE_DECL_UNSETENV
+/* Define to 1 if `lex' declares `yytext' as a `char *' by default, not a
+   `char[]'. */
+#undef YYTEXT_POINTER
 
+/* Define to 1 if on AIX 3.
+   System headers sometimes define this.
+   We just want to avoid a redefinition error message.  */
+#ifndef _ALL_SOURCE
+# undef _ALL_SOURCE
+#endif
+
+/* Define to 1 if on MINIX. */
+#undef _MINIX
+
+/* Define to 2 if the system does not provide POSIX.1 features except with
+   this defined. */
+#undef _POSIX_1_SOURCE
+
+/* Define to 1 if you need to in order for `stat' and other things to work. */
+#undef _POSIX_SOURCE
+
+/* Define to `unsigned' if <sys/types.h> does not define. */
+#undef size_t
Index: gnats/configure.in
===================================================================
RCS file: /cvsroot/gnats/gnats/gnats/configure.in,v
retrieving revision 1.31
diff -u -p -r1.31 configure.in
--- gnats/configure.in	20 Sep 2003 22:36:43 -0000	1.31
+++ gnats/configure.in	20 Jun 2004 16:34:24 -0000
@@ -291,6 +291,42 @@ if test -z "${GNATS_DEFAULT_DB_DIR}"; th
 	GNATS_DEFAULT_DB_DIR=${sharedstatedir}/gnatsdb
 fi
 
+dnl
+dnl begin --enable-pam
+dnl
+
+dnl
+dnl Check if PAM authentication is enabled
+dnl
+AC_ARG_ENABLE(
+  [pam],
+  AC_HELP_STRING(
+    [--enable-pam],
+    [Use to enable system authentication with PAM instead of using the 
+    simple file based passwords.  This allows authentication (in theory) 
+    with any PAM module, e.g. on systems with shadow passwords or via LDAP]), ,
+  [enable_pam=no]
+  )
+
+if test yes = $enable_pam; then
+  AC_CHECK_HEADER(security/pam_appl.h, 
+    AC_DEFINE(HAVE_PAM, 1, 
+    [Define to enable system authentication with PAM instead of using the 
+    simple getpwnam interface.  This allows authentication (in theory) 
+    with any PAM module, e.g. on systems with shadow passwords or via LDAP])
+    AC_CHECK_LIB(pam, pam_start, [LIBS="${LIBS} -lpam"],
+      AC_MSG_ERROR([Could not find PAM libraries but the headers exist.
+      Give the --disable-pam option to compile without PAM support (or fix
+      your broken configuration)])
+    ),
+    AC_MSG_ERROR([Could not find PAM headers])
+  )
+fi
+
+dnl
+dnl end --enable-pam
+dnl
+
 # Set up default values to be overridden
 
 _h=`(hostname || uname -n) 2>/dev/null | sed 1q`
Index: gnats/gnatsd.c
===================================================================
RCS file: /cvsroot/gnats/gnats/gnats/gnatsd.c,v
retrieving revision 1.48
diff -u -p -r1.48 gnatsd.c
--- gnats/gnatsd.c	14 Oct 2002 11:42:25 -0000	1.48
+++ gnats/gnatsd.c	20 Jun 2004 16:34:25 -0000
@@ -248,18 +248,133 @@ match (const char *line, const char *pat
     }
 }
 
-/* Return true iff `password' matches `hash'.
-   `hash' is a possibly encrypted password, according to the $?$ convention. */
+#ifdef HAVE_PAM
+/**
+ *
+ * Support for PAM authentication. Code borrowed from CVS server code
+ * with similar capability (gargp@acm.org)
+ *
+ **/
+#include <security/pam_appl.h>
+
+struct gnats_pam_userinfo {
+  const char *username;
+  const char *password;
+};
+
 static int
-password_match (const char *password, const char *hash)
+gnats_pam_conv(int num_msg, const struct pam_message **msg,
+	       struct pam_response **resp, void *appdata_ptr )
 {
-  if (strlen(password) && strlen(hash))
+  int i;
+  struct pam_response *response;
+  struct gnats_pam_userinfo *ui = (struct gnats_pam_userinfo *)appdata_ptr;
+
+  response = xmalloc(num_msg * sizeof(struct pam_response));
+  memset(response, 0, num_msg * sizeof(struct pam_response));
+
+  for (i = 0; i < num_msg; i++)
+    {
+      switch(msg[i]->msg_style) 
+	{
+	  /* PAM wants a username */
+	case PAM_PROMPT_ECHO_ON:
+	  response[i].resp = xstrdup(ui->username);
+	  break;
+	  /* PAM wants a password */
+	case PAM_PROMPT_ECHO_OFF:
+	  response[i].resp = xstrdup(ui->password);
+	  break;
+	case PAM_ERROR_MSG:
+	case PAM_TEXT_INFO:
+	  printf("%s\n",msg[i]->msg);
+	  break;
+	  /* PAM wants something we don't understand - bail out */
+	default:
+	  goto cleanup;
+	}
+    }
+
+  *resp = response;
+  return PAM_SUCCESS;
+
+ cleanup:
+  for (i = 0; i < num_msg; i++)
+    {
+      if (response[i].resp)
+	{
+	  free(response[i].resp);
+	  response[i].resp = 0;
+	}
+    }
+  free(response);
+  return PAM_CONV_ERR;
+}
+
+static bool
+pam_password_match( const char *username, const char *password )
+{
+  pam_handle_t *pamh = NULL;
+  int retval, err;
+  struct gnats_pam_userinfo ui;
+  struct pam_conv conv;
+  const char *pam_stage = "start";
+
+  ui.username = username;
+  ui.password = password;
+
+  conv.conv        =  gnats_pam_conv;
+  conv.appdata_ptr = (void *)&ui;
+
+  retval = pam_start(DEFAULT_GNATS_SERVICE, username, &conv, &pamh);
+
+  if (retval == PAM_SUCCESS) {
+    pam_stage = "authenticate";
+    retval = pam_authenticate(pamh, 0);
+  }
+
+  if (retval == PAM_SUCCESS) {
+    pam_stage = "account";
+    retval = pam_acct_mgmt(pamh, 0);
+  }
+
+  if (retval != PAM_SUCCESS)
+    syslog(LOG_ERR, "PAM %s error: %s\n", pam_stage, pam_strerror(pamh, retval));
+
+  if ((err = pam_end(pamh, retval)) != PAM_SUCCESS)
+    {
+      syslog(LOG_ERR, "PAM error %s\n", pam_strerror(NULL, err));
+      exit (EXIT_FAILURE);
+    }
+
+  return retval == PAM_SUCCESS ? TRUE : FALSE;       /* indicate success */
+}
+#endif
+
+/**
+ *
+ * Return TRUE iff `password' matches, as specified by `hash'.
+ * `hash' is a possibly encrypted password, according to the $?$ convention.
+ * If hash == '$p$', then use the PAM service for authentication.
+ *
+ **/
+static int
+password_match (const char *user, const char *password, const char *hash)
+{
+  if (strlen(user) && strlen(password) && strlen(hash))
     {
       if (! strncmp (hash, "$0$", 3))
 	{
 	  /* explicit plain-text password */
 	  return match (password, hash+3, TRUE);
 	}
+#ifdef HAVE_PAM
+      else if (! strncmp (hash, "$p$", 3))
+	{
+	  /* check with PAM module */
+	  return pam_password_match (user, password);
+	}
+#endif
       else
 	{
 #ifdef HAVE_LIBCRYPT
@@ -461,7 +576,7 @@ findUserAccessLevel (const char *file, c
 	  if ((ent->fieldcount == 3 || ent->fieldcount == 4)
 	      && match (user, ent->admFields[0], TRUE))
 	    {
-	      if (! password_match (passwd, ent->admFields[1]))
+	      if (! password_match (user, passwd, ent->admFields[1]))
 		{
 		  /* Username matched but password didn't.  */
 		  if (strlen(ent->admFields[1]) && strlen(passwd))

[-- Attachment #3: Type: text/plain, Size: 140 bytes --]

_______________________________________________
Help-gnats mailing list
Help-gnats@gnu.org
http://lists.gnu.org/mailman/listinfo/help-gnats

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: PAM Authentication Patch
       [not found]       ` <gargp@earthlink.net>
@ 2004-06-20 17:59         ` Mark D. Baushke
  2004-06-21  7:25           ` Chad Walstrom
  0 siblings, 1 reply; 22+ messages in thread
From: Mark D. Baushke @ 2004-06-20 17:59 UTC (permalink / raw)
  To: gargp; +Cc: help-gnats

Pankaj K Garg <gargp@earthlink.net> writes:

> I'm attaching a patch for enabling PAM
> authentication support.
> 
> To keep the patch file small, I've not included
> the diffs to the files 'configure' and
> 'gnats/configure'. Use autoconf to generate
> these two files. If you need the generated
> files, let me know and I'll create another
> patch.
> 
> PAM support can now be enabled by using
> '--enable-pam' switch to configure.
> 
> With PAM support enabled, you can put an entry
> in the gantsd.user_access file as:
> 
>    <user>:$p$:<access-level>
> 
> and the authentication for the user will be done
> against the configured PAM modules.
> 
> The name of the PAM service is taken from the
> DEFAULT_GANTS_SERVICE define, so by default it
> should be 'support'. Hence, you can configure
> PAM by creating the file /etc/pam.d/support on
> RH Linux.
> 
> I've tried to make appropriate changes to the
> documentation. Let me know if any other document
> requires update.
> 
> I've done some preliminary testing on my RH 9.0
> Linux. Please let me know if there's any problem
> with it.
> 
> Pankaj

The biggest problem I have with PAM support for
gnatsd is that you will now be sending a
credential across the network in the clear which
is presumably able to be used as a credential
outside of gnats. This could lead to a simple
password replay attack to gain access to systems
by unauthorized individuals or their agents.

I strongly urge you to first include and enable
SSL (or TLS) support in gantsd before you allow
PAM to be used to authorize connections.

	-- Mark

> Chad C. Walstrom wrote:
> > Pankaj K Garg wrote:
> >
> >>Is anyone signed up for adding PAM
> >>authentication support yet? If not, I can sign
> >>up for it.

> > No, no one has signed up for this yet. I
> > placed your name in the
> > TODO
> > list and updated it in CVS. I don't plan on
> > making ChangeLog entries for these files
> > (.todo and TODO), though I will note the
> > changes made in the cvs log entry. Welcome
> > aboard! I look forward to getting your
> > patches!
> 
> -- 
> Pankaj K Garg                         garg@zeesource.net
> 1684 Nightingale Avenue               408-373-4027
> Suite 201                             408-733-2737(fax)
> Sunnyvale, CA 94087
> 
> http://www.zeesource.net              http://home.earthlink.net/~gargp


_______________________________________________
Help-gnats mailing list
Help-gnats@gnu.org
http://lists.gnu.org/mailman/listinfo/help-gnats

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: PAM Authentication Patch
  2004-06-20 17:59         ` Mark D. Baushke
@ 2004-06-21  7:25           ` Chad Walstrom
  2004-06-21 15:26             ` Chad Walstrom
  0 siblings, 1 reply; 22+ messages in thread
From: Chad Walstrom @ 2004-06-21  7:25 UTC (permalink / raw)
  To: help-gnats


[-- Attachment #1.1: Type: text/plain, Size: 1070 bytes --]

Mark D. Baushke wrote:
> The biggest problem I have with PAM support for gnatsd is that you
> will now be sending a credential across the network in the clear which
> is presumably able to be used as a credential outside of gnats. This
> could lead to a simple password replay attack to gain access to
> systems by unauthorized individuals or their agents.
> 
> I strongly urge you to first include and enable SSL (or TLS) support
> in gantsd before you allow PAM to be used to authorize connections.

Agreed. This is definitely something that should get on the TODO list
for gnatsd.  Alternatively, there are ways of tunneling TCP connections
over secure channels, so I don't think the lack of gnutls integration
should exclude the PAM patch.

We should make it abundantly clear in the documentation that use of PAM
authentication should be thoroughly protected.  If such measures cannot
be taken, don't enable PAM.

-- 
Chad Walstrom <chewie@wookimus.net>           http://www.wookimus.net/
           assert(expired(knowledge)); /* core dump */

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 140 bytes --]

_______________________________________________
Help-gnats mailing list
Help-gnats@gnu.org
http://lists.gnu.org/mailman/listinfo/help-gnats

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: PAM Authentication Patch
  2004-06-21  7:25           ` Chad Walstrom
@ 2004-06-21 15:26             ` Chad Walstrom
       [not found]               ` <chewie@wookimus.net>
  0 siblings, 1 reply; 22+ messages in thread
From: Chad Walstrom @ 2004-06-21 15:26 UTC (permalink / raw)
  To: help-gnats


[-- Attachment #1.1: Type: text/plain, Size: 543 bytes --]

Chad Walstrom wrote:
> We should make it abundantly clear in the documentation that use of
> PAM authentication should be thoroughly protected.  If such measures
> cannot be taken, don't enable PAM.

Additionally, we can't always assume that because something uses PAM,
it'll authentication against system accounts.  There are dbm modules,
ldap modules, etc. that can be used for account management.

-- 
Chad Walstrom <chewie@wookimus.net>           http://www.wookimus.net/
           assert(expired(knowledge)); /* core dump */

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 140 bytes --]

_______________________________________________
Help-gnats mailing list
Help-gnats@gnu.org
http://lists.gnu.org/mailman/listinfo/help-gnats

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: PAM Authentication Patch
       [not found]               ` <chewie@wookimus.net>
@ 2004-06-21 15:34                 ` Mark D. Baushke
  2004-11-04  1:27                 ` Preparing 4.1 Mark D. Baushke
  1 sibling, 0 replies; 22+ messages in thread
From: Mark D. Baushke @ 2004-06-21 15:34 UTC (permalink / raw)
  To: help-gnats

Chad Walstrom <chewie@wookimus.net> writes:

> Chad Walstrom wrote:
> > We should make it abundantly clear in the
> > documentation that use of PAM authentication
> > should be thoroughly protected. If such
> > measures cannot be taken, don't enable PAM.
> 
> Additionally, we can't always assume that
> because something uses PAM, it'll authentication
> against system accounts. There are dbm modules,
> ldap modules, etc. that can be used for account
> management.

While I do understand that it is *possible* to
enable PAM and not endanger other applications or
systems. I also understand that very few people or
organizations will consider keeping such things
separate in such a safe configuration unless the
documentation clearly states that there are
security implications to be considered.

Yes, I am being paranoid. right now it seems
fairly clear that gnatsd authentication is not
very strongly protected. Folks are more likely to
believe something is 'secure' if it can talk to
PAM even though there may be explicit basis for
that belief.

	-- Mark


_______________________________________________
Help-gnats mailing list
Help-gnats@gnu.org
http://lists.gnu.org/mailman/listinfo/help-gnats

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: PAM Authentication Patch
  2004-06-20 17:39     ` PAM Authentication Patch Pankaj K Garg
       [not found]       ` <gargp@earthlink.net>
@ 2004-06-21 16:13       ` Chad Walstrom
  1 sibling, 0 replies; 22+ messages in thread
From: Chad Walstrom @ 2004-06-21 16:13 UTC (permalink / raw)
  To: help-gnats


[-- Attachment #1.1: Type: text/plain, Size: 889 bytes --]

Pankaj K Garg wrote:
> I'm attaching a patch for enabling PAM authentication support.
...
> I've done some preliminary testing on my RH 9.0 Linux. Please let me
> know if there's any problem with it.

Thanks for the patch!  I'll try to test this out later this week.  If
anyone else would like to do some testing, it would be appreciated.

We can continue this discussion about security and gnatsd.  I'll add a
Security Enhancement in the TODO list for 5.x releases.  We can decide
whether or not we want to hold off on the PAM addition until TLS and/or
SASL is introduced with TLS being of higher priority than SASL.  I vote
to allow it, but document the warnings and possible solutions regarding
security.

Feedback, ideas, rebuttals?

-- 
Chad Walstrom <chewie@wookimus.net>           http://www.wookimus.net/
           assert(expired(knowledge)); /* core dump */

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 140 bytes --]

_______________________________________________
Help-gnats mailing list
Help-gnats@gnu.org
http://lists.gnu.org/mailman/listinfo/help-gnats

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Preparing 4.1...
@ 2004-10-29 21:33 Chad C. Walstrom
  2004-10-31 14:03 ` Pankaj Garg
                   ` (2 more replies)
  0 siblings, 3 replies; 22+ messages in thread
From: Chad C. Walstrom @ 2004-10-29 21:33 UTC (permalink / raw)
  To: help-gnats

Hello, folks.  Well, now that my training as a parent have been
initiated, I think it's time to put my shoulder to the grindstone.

Hans-Albert submitted a change to CVS to fix a couple buffer overflow
problems on September 6th, and we should roll these out into a new
release of gnats sooner than later.  An optimistic goal is to have a
release ready to roll out by Monday.  If you have patches or fixes you
would like incorporated, please let me know ASAP.

Things I still plan on rolling in for the 4.1 release:

  * NEWS: Summarize changes and important security fixes

  * A note in the compilation documentation that bison version 1.35 or
    earlier is required to rebuild getdate.c.

    (Is there anyone versed in using bison to update the getdate.y file
    to use bison 1.875?)

  * install-sid: Either remove or update so that a separate
    configuration (sh) file is generated rather than editing send-pr.

  * send-pr:
    - Source a configuration (sh) file (i.e. /etc/gnats/send-pr.conf)
      and $HOME/.send-pr.conf to override default environment variables
    - Remove or update references/error messages regarding install-sid

  * debian/...: Roll in changes from current debian package

I'm going to hold off on the PAM patch for just a while longer.  Pankaj,
do you think it would be possible to add a cautionary note in gnats.texi
regarding the security problems in exposing the PAM to GNATS
authentictation (i.e. plain-text network protocol sniffing)?  For
example, we should suggest that administrators not authenticate system
accounts through GNATS.  Rather, give suggestions for using other PAM
modules to authenticate against alternate passwd or db format files.

(Is it possible to blacklist pam modules for use w/gnats?)

Once we get a gnutls layer incorporated into the gnats daemon and
libraries, we could update our suggestions to be more permissive.

Note: I do have to purchase and install a new power supply for my
workstation at home, but I hope to have it up and running later tonight.

-- 
Chad Walstrom <chewie@wookimus.net>
http://www.wookimus.net/~chewie


_______________________________________________
Help-gnats mailing list
Help-gnats@gnu.org
http://lists.gnu.org/mailman/listinfo/help-gnats

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: Preparing 4.1...
  2004-10-29 21:33 Preparing 4.1 Chad C. Walstrom
@ 2004-10-31 14:03 ` Pankaj Garg
  2004-11-01 19:09 ` Pankaj Garg
  2004-11-03 22:46 ` Chad C. Walstrom
  2 siblings, 0 replies; 22+ messages in thread
From: Pankaj Garg @ 2004-10-31 14:03 UTC (permalink / raw)
  To: Chad C. Walstrom; +Cc: help-gnats


Yes, I'll put a cautionary note in gnats.texi.

I don't think we can block modules selectively. Anyhow, people
using PAM modules should know what they are doing, and will
be careful of security issues, specially if we warn them.

I'm under the impression that if you use a client and server
on the same machine, then there is no security problem. Is this
correct?

Pankaj

On Oct 29, 2004, at 2:33 PM, Chad C. Walstrom wrote:

> I'm going to hold off on the PAM patch for just a while longer.  
> Pankaj,
> do you think it would be possible to add a cautionary note in 
> gnats.texi
> regarding the security problems in exposing the PAM to GNATS
> authentictation (i.e. plain-text network protocol sniffing)?  For
> example, we should suggest that administrators not authenticate system
> accounts through GNATS.  Rather, give suggestions for using other PAM
> modules to authenticate against alternate passwd or db format files.
>
> (Is it possible to blacklist pam modules for use w/gnats?)
>



  --
  Pankaj K Garg                         garg@zeesource.net
  1684 Nightingale Avenue     408-373-4027
  Suite 201                                  408-733-2737(fax)
  Sunnyvale, CA 94087            http://www.zeesource.net



_______________________________________________
Help-gnats mailing list
Help-gnats@gnu.org
http://lists.gnu.org/mailman/listinfo/help-gnats

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: Preparing 4.1...
  2004-10-29 21:33 Preparing 4.1 Chad C. Walstrom
  2004-10-31 14:03 ` Pankaj Garg
@ 2004-11-01 19:09 ` Pankaj Garg
  2004-11-03 22:39   ` Chad C. Walstrom
  2004-11-03 22:46 ` Chad C. Walstrom
  2 siblings, 1 reply; 22+ messages in thread
From: Pankaj Garg @ 2004-11-01 19:09 UTC (permalink / raw)
  To: Chad C. Walstrom; +Cc: help-gnats

One more thing, when I compiled Gnats 4.0 on my Mac OS X.3
(Panther) I had to take out the '-ansi' switch from GCC_CFLAGS
in gnats/configure. I got this tip by searching this mailing list.

Can we make this somehow permanent in 4.1?

On Oct 29, 2004, at 2:33 PM, Chad C. Walstrom wrote:

> Hans-Albert submitted a change to CVS to fix a couple buffer overflow
> problems on September 6th, and we should roll these out into a new
> release of gnats sooner than later.  An optimistic goal is to have a
> release ready to roll out by Monday.  If you have patches or fixes you
> would like incorporated, please let me know ASAP.



_______________________________________________
Help-gnats mailing list
Help-gnats@gnu.org
http://lists.gnu.org/mailman/listinfo/help-gnats

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: Preparing 4.1...
  2004-11-01 19:09 ` Pankaj Garg
@ 2004-11-03 22:39   ` Chad C. Walstrom
  0 siblings, 0 replies; 22+ messages in thread
From: Chad C. Walstrom @ 2004-11-03 22:39 UTC (permalink / raw)
  To: help-gnats


[-- Attachment #1.1: Type: text/plain, Size: 661 bytes --]

Pankaj Garg wrote:
> One more thing, when I compiled Gnats 4.0 on my Mac OS X.3
> (Panther) I had to take out the '-ansi' switch from GCC_CFLAGS
> in gnats/configure. I got this tip by searching this mailing list.
> 
> Can we make this somehow permanent in 4.1?

I'm not sure exactly how to do this, but I suspect that it might involve
adding a file to the config/ subdirectory for the Mac OS X platform.
We have a few Mac's at work.  I'll see what I can dig up.  If someone
knows the answer off-hand, let us know.

-- 
Chad Walstrom <chewie@wookimus.net>           http://www.wookimus.net/
           assert(expired(knowledge)); /* core dump */

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 140 bytes --]

_______________________________________________
Help-gnats mailing list
Help-gnats@gnu.org
http://lists.gnu.org/mailman/listinfo/help-gnats

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: Preparing 4.1...
  2004-10-29 21:33 Preparing 4.1 Chad C. Walstrom
  2004-10-31 14:03 ` Pankaj Garg
  2004-11-01 19:09 ` Pankaj Garg
@ 2004-11-03 22:46 ` Chad C. Walstrom
  2 siblings, 0 replies; 22+ messages in thread
From: Chad C. Walstrom @ 2004-11-03 22:46 UTC (permalink / raw)
  To: help-gnats, info-gnats


[-- Attachment #1.1: Type: text/plain, Size: 1007 bytes --]

OK, I think we're about ready to make the 4.1 release.
send-pr/install-sid has been updated, the debian directory has been
synchronized, configure.in has been updated in the gnats/ and send-pr/
directories.  There are a few remaining issues to consider:

	* Compilation issues on Mac OS X 10.3.x

	* Core dump issues for Fedora Core 2 (remove optimization in the
	  compile)

	* libiberty autoconf requires version 2.13 rather than 2.50.
	  We either need to update the configure.in file to work with
	  2.50 or update libiberty to the most recent version (wherever
	  that might be available)

	* Should we replace texinfo/texinfo.tex file with a more recent
	  version? (Version 4.2?)

If you're interested in testing the current development version of
GNATS, please check out the recent CVS repository.

	https://savannah.gnu.org/cvs/?group=gnats

-- 
Chad Walstrom <chewie@wookimus.net>           http://www.wookimus.net/
           assert(expired(knowledge)); /* core dump */

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 140 bytes --]

_______________________________________________
Help-gnats mailing list
Help-gnats@gnu.org
http://lists.gnu.org/mailman/listinfo/help-gnats

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: Preparing 4.1...
       [not found]               ` <chewie@wookimus.net>
  2004-06-21 15:34                 ` Mark D. Baushke
@ 2004-11-04  1:27                 ` Mark D. Baushke
  2004-11-04  3:15                   ` Chad Walstrom
  1 sibling, 1 reply; 22+ messages in thread
From: Mark D. Baushke @ 2004-11-04  1:27 UTC (permalink / raw)
  To: help-gnats, info-gnats

Chad C. Walstrom <chewie@wookimus.net> writes:

> OK, I think we're about ready to make the 4.1 release.
> send-pr/install-sid has been updated, the debian directory has been
> synchronized, configure.in has been updated in the gnats/ and send-pr/
> directories.  There are a few remaining issues to consider:
> 
> 	* Compilation issues on Mac OS X 10.3.x
> 
> 	* Core dump issues for Fedora Core 2 (remove optimization in the
> 	  compile)
> 
> 	* libiberty autoconf requires version 2.13 rather than 2.50.
> 	  We either need to update the configure.in file to work with
> 	  2.50 or update libiberty to the most recent version (wherever
> 	  that might be available)

I recommend moving to autoconf 2.59 and consider a transition to
automake 1.9.3.

> 	* Should we replace texinfo/texinfo.tex file with a more recent
> 	  version? (Version 4.2?)

Well, you may do well to consider making sure that the documentation
still looks correct when using something like the makeinfo that comes
with texinfo-4.7 (released 2004-04-10) which is hte latest release of
the texinfo software.

	-- Mark


_______________________________________________
Help-gnats mailing list
Help-gnats@gnu.org
http://lists.gnu.org/mailman/listinfo/help-gnats

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: Preparing 4.1...
  2004-11-04  1:27                 ` Preparing 4.1 Mark D. Baushke
@ 2004-11-04  3:15                   ` Chad Walstrom
  2004-11-04 19:15                     ` Chad Walstrom
  0 siblings, 1 reply; 22+ messages in thread
From: Chad Walstrom @ 2004-11-04  3:15 UTC (permalink / raw)
  To: help-gnats


[-- Attachment #1.1: Type: text/plain, Size: 969 bytes --]

Mark D. Baushke wrote:
> I recommend moving to autoconf 2.59 and consider a transition to
> automake 1.9.3.

Certainly, but let's consider 4.1 security/bugfix release.  We'll
migrate to a cleaner autoconf/automake setup in 4.2.  It's on the top of
my list of things to do.  I recommended 2.50 based on an incorrect
assumption that Debian ships with 2.50 by default.  In fact, I had been
using 2.59 where the binary was named autoconf2.50.  So, I agree to
requiring 2.59.

The only library that we need to concentrate on is libiberty, which
appears to be supplementary for non-GNU platforms.

> > 	* Should we replace texinfo/texinfo.tex file with a more recent
> > 	  version? (Version 4.2?)

To clarify, I meant to imply that updates to texinfo.tex would occur in
GNATS version 4.2.  It will happen, just not yet.

-- 
Chad Walstrom <chewie@wookimus.net>           http://www.wookimus.net/
           assert(expired(knowledge)); /* core dump */

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 140 bytes --]

_______________________________________________
Help-gnats mailing list
Help-gnats@gnu.org
http://lists.gnu.org/mailman/listinfo/help-gnats

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: Preparing 4.1...
  2004-11-04  3:15                   ` Chad Walstrom
@ 2004-11-04 19:15                     ` Chad Walstrom
  2004-11-17 23:26                       ` Chad Walstrom
  0 siblings, 1 reply; 22+ messages in thread
From: Chad Walstrom @ 2004-11-04 19:15 UTC (permalink / raw)
  To: help-gnats, bug-gnats


[-- Attachment #1.1: Type: text/plain, Size: 857 bytes --]

OK. An update is in order.  It looks like gnats will not build on my
system with the existing libiberty/ (and subsequently include/)
directories and the changes I made to configure.in.  I've tested dumping
the old libiberty and replacing it with the one found in the gcc 3.4
sources.  I was able to get a successful build and test installation.
This is a larger change than I had hoped for, but probably one that
needs to be done.

The alternative is to step back from requiring autoconf 2.59, and
instead stick with autoconf 2.13 for now.  Anyway, I'll keep testing and
let you know what I find.

As an aside, should we be using bug-gnats for development discussions
and leave help-gnats for end-user help?

-- 
Chad Walstrom <chewie@wookimus.net>           http://www.wookimus.net/
           assert(expired(knowledge)); /* core dump */

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 140 bytes --]

_______________________________________________
Help-gnats mailing list
Help-gnats@gnu.org
http://lists.gnu.org/mailman/listinfo/help-gnats

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: Preparing 4.1...
  2004-11-04 19:15                     ` Chad Walstrom
@ 2004-11-17 23:26                       ` Chad Walstrom
  0 siblings, 0 replies; 22+ messages in thread
From: Chad Walstrom @ 2004-11-17 23:26 UTC (permalink / raw)
  To: bug-gnats


[-- Attachment #1.1: Type: text/plain, Size: 1068 bytes --]

Chad Walstrom wrote:
> This is a larger change than I had hoped for, but probably one that
> needs to be done.

Update number two.  I've tagged the HEAD branch of CVS before adding the
libiberty updates.  I intended on branching off HEAD to test this
addition, but messed up my commits, so the libiberty updates are on HEAD
instead of of the libiberty update branch.  In any case, I have a few
more cleanup changes to commit tonight.

Note, I'm not getting the coredump issues with the update libiberty
files.  When I ran a backtrace on the offending gnatsd executable, it
traced back to the memcpy function in the /lib/tls/libc-2.3.2.so
library.  I haven't tracked down the exact updates in libiberty yet to
pinpoint the problem, but because I'm not getting these coredumps, I
think might be able to assume they were fixed.

So, wait for my commits later today, and then please test on your
respective platforms.

-- 
Chad Walstrom <chewie@wookimus.net>           http://www.wookimus.net/
           assert(expired(knowledge)); /* core dump */

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 137 bytes --]

_______________________________________________
Bug-gnats mailing list
Bug-gnats@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnats

[-- Attachment #3: Type: text/plain, Size: 140 bytes --]

_______________________________________________
Help-gnats mailing list
Help-gnats@gnu.org
http://lists.gnu.org/mailman/listinfo/help-gnats

^ permalink raw reply	[flat|nested] 22+ messages in thread

end of thread, other threads:[~2004-11-17 23:26 UTC | newest]

Thread overview: 22+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2004-06-10 21:20 CVS, Documentation, TODO Lists, New Maintainer, and Stuff Chad C. Walstrom
2004-06-10 21:44 ` Chad C. Walstrom
2004-06-13  8:51   ` Mel Hatzis
2004-06-13 23:01   ` Andrew Gray
2004-06-11 22:28 ` Yngve Svendsen
2004-06-14 17:07 ` Pankaj K Garg
2004-06-14 17:16   ` Chad C. Walstrom
2004-06-20 17:39     ` PAM Authentication Patch Pankaj K Garg
     [not found]       ` <gargp@earthlink.net>
2004-06-20 17:59         ` Mark D. Baushke
2004-06-21  7:25           ` Chad Walstrom
2004-06-21 15:26             ` Chad Walstrom
     [not found]               ` <chewie@wookimus.net>
2004-06-21 15:34                 ` Mark D. Baushke
2004-11-04  1:27                 ` Preparing 4.1 Mark D. Baushke
2004-11-04  3:15                   ` Chad Walstrom
2004-11-04 19:15                     ` Chad Walstrom
2004-11-17 23:26                       ` Chad Walstrom
2004-06-21 16:13       ` PAM Authentication Patch Chad Walstrom
2004-10-29 21:33 Preparing 4.1 Chad C. Walstrom
2004-10-31 14:03 ` Pankaj Garg
2004-11-01 19:09 ` Pankaj Garg
2004-11-03 22:39   ` Chad C. Walstrom
2004-11-03 22:46 ` Chad C. Walstrom

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).