On Tue, Aug 21, 2007 at 04:27:26PM +0200, Michael Banck wrote: > I tried current svn (svn://svn.debian.org/pkg-pam/trunk/pam/), and the > following issues arose:
> 1) PATH_MAX usage in modules/pam_cracklib/pam_cracklib.c: > gcc -DHAVE_CONFIG_H -I. -I../.. -I../../libpam/include > -I../../libpamc/include -g -D_GNU_SOURCE -D_REENTRANT -fPIC -O2 -MT > pam_cracklib.lo -MD -MP -MF .deps/pam_cracklib.Tpo -c pam_cracklib.c > -fPIC -DPIC -o .libs/pam_cracklib.o > pam_cracklib.c:97: error: 'PATH_MAX' undeclared here (not in a function) > make[4]: *** [pam_cracklib.lo] Error 1 > This is unfortunate as it is in a struct, so fixing this properly is > maybe not easy. One possiblity is to just conditionalize the > libcracklib2-dev Build-Depends for hurd-i386 which makes the build > ignore pam_cracklib and continue successfully, however the build then > later aborts in binary-arch stage because the pam-cracklib package > cannot find its files. I am not sure what to best do here, maybe a > Debian-specific #define PATH_MAX 4096 at the top of pam_cracklib.c is > easiest. There's actually no particular need for the static buffer here, in each case it's just being filled with a strncpy from an existing string with reasonable scope so a pointer does just as well. Fixed. > 2) Various libpam source files #include <pthread.h> and use functions > like pthread_mutex_lock(), but libpam does not link to -lpthread. This > works on GNU/Linux where libpthread is inside libc, but not on GNU/Hurd > where it is seperate: <snip> > When I add -lpthread to libpam_la_LINK in libpam/Makefile, this works > fine, but I believe this is a general problem in the build system which > should get fixed properly in configure.in and Makefile.am etc. Right, the portable fix is to use -pthread in libpam_la_LDFLAGS. Fixed. > 3) debian/patches-applied/038_support_hurd has a leftover hunk about > MAXPATHLEN for modules/pam_rhosts/pam_rhosts_auth.c which yields this > build error: <snip> > as pbuf got otherwise removed from this file, this hunk should get > removed as well (it seems the other MAXPATHLEN related hunks already got > removed from 038_support_hurd) Doh, fixed. > 4) modules/pam_xauth/pam_xauth.c needs porting: > gcc -DHAVE_CONFIG_H -I. -I../.. -I../../libpam/include > -I../../libpamc/include -g -D_GNU_SOURCE -D_REENTRANT -fPIC -O2 -MT > pam_xauth.lo -MD -MP -MF .deps/pam_xauth.Tpo -c pam_xauth.c -fPIC -DPIC > -o .libs/pam_xauth.o > pam_xauth.c:38:23: error: sys/fsuid.h: No such file or directory > pam_xauth.c: In function 'check_acl': > pam_xauth.c:203: error: 'PATH_MAX' undeclared (first use in this > function) > pam_xauth.c:203: error: (Each undeclared identifier is reported only > once > pam_xauth.c:203: error: for each function it appears in.) > make[4]: *** [pam_xauth.lo] Error 1 > This doesn't look so bad, it can probably be easily fixed in a way > acceptable to upstream. Hmm, this is a case where it might be more interesting to preserve the use of PATH_MAX because the path is assembled via snprintf() and might legitimately wind up exceeding PATH_MAX on those systems that implement it if PATH_MAX is otherwise ignored. Well, I've put a patch in svn which should fix it, we'll see whether it ends up being acceptable to upstream. :) > 5) After hacking around the above issues I got > debian/tmp/usr/share/man/man5/namespace.conf.5: No such file or > directory at /usr/bin/dh_installman line 120, <IN> line 333. > which is pretty weird considering that this shouldn't be arch-specific > at all. Maybe some bogus error from restarting dpkg-buildpackage too > much. Ok, I've refactored the build rules to use a glob for man5 and manually exclude those manpages that belong to another package. Anyone care to give this build another spin? Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
