From: Steve Langasek <vorlon@netexpress.net>
To: "Eloy A. Paris" <eloy.paris@usa.net>
Date: Thu, 23 Aug 2001 21:20:05 -0500 (CDT)
Subject: Re: autobuilder failure on arm for samba-2.2.1a-3
In-Reply-To: <20010823100906.A1092@antenas>
Message-ID: <Pine.LNX.4.30.0108231744090.11071-100000@tennyson.netexpress.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Thu, 23 Aug 2001, Eloy A. Paris wrote:

> On Wed, Aug 22, 2001 at 03:01:01PM -0500, Steve Langasek wrote:

> > Hmm.  Maybe the thing to do is to focus on getting config.cache (not log,
> > cache) support into the package.  Issues like this are frequent enough with
> > Samba, and the configure tests add enough time to the build process, that I
> > think there'd be much benefit in being able to step past a lot of these.

> Uhhmmm... I don't know, I guess I don't like much the idea of
> maintaining a config.cache. It looks like extra work plus a
> compilation process that is "synthetic" or atificial. What happens if
> the Samba Team adds a new test, or modifies the configure script, will
> the config.cache pick those up?

> In any case, you are the expert, so if you think that's the way to go,
> and the burden far exceeds the problems we have right now I say let's
> go for it. I am not well versed on autoconf and the configure process,
> that's all...

Well, I'll attach my work to the bottom of this message and let you judge it
for yourself.

The config.cache I'm trying to generate here is not equivalent to what
a configure script outputs.  The only values I'm including are those which 1)
are no-brainers on any glibc-based platform, 2) are questions we need to force
a particular value for regardless of the kernel being built against, or 3) are
questions about specific bizarre features of proprietary Unices that we'll
always get an answer of 'no' to.

I've removed all of the config.cache variables related to headers, or to
checks for particular libraries; I think it's pretty safe to assert that glibc
provides basic C functions like select(), setenv(), and waitpid() on all our
build targets, but I think it's less safe to assert that they'll always be
provided by particular header files.

So the config.cache won't automatically be updated with answers to new
configure tests, but it also doesn't need to in order to be useful.  There's
really only a handful of variables in there that we /need/ in order to
guarantee correctly-built packages, and if you want to leave out everything
else, that's perfectly ok too.  Everything from the fifth stanza on down is
just a build-time speed-up for some of the slower architectures.  Well, it
also has the fringe benefit that the packages will FAIL to build if someone
tries rebuilding for a really bizarre (non-Linux, non-glibc) architecture.  I
see that as a plus :), you may disagree, but in any case my next trick would
be to add a global variable developers can set to bypass the provided
config.cache.


It is a little artificial, but the whole point of .debs is to be able to build
binaries in a controlled environment.  Right now, we don't really have control
over what happens in the autobuilders.  We have even /less/ control over what
happens in a stable release:  it's been two weeks now since I built binaries
for bug #94380, and they haven't been uploaded to security.d.o yet.  I'm
guessing they won't be uploaded until Wichert is back from vacation, either --
which is fine, but it would be nice if we didn't have to worry about
mis-builds by the security team, or about putting the security team to extra
trouble after the fact to get packages fixed.

With a pre-loaded config.cache, we can ensure that bugs of this kind don't
happen in woody.  We can take the arm autobuilder problem into our own hands,
and not have to worry about quirkiness in the build environment.  We can even
close bug #109773, since we no longer have to worry about detecting the
setuid() routines.


So to me, it definitely seems worth it.  But you're the maintainer, and I
won't ask you to put anything in the package that you're not comfortable with.


> By the way, I think I remember someone was able to build 2.2.x succesfully on
> the ARM. If this is the case, could it be that there's something weird
> with Phillip's setup?

It could be.  There are arm packages for 2.2.1a-1, so at /some/ point the
autobuilder was able to pass the locking test.


> P.S. How did you know about the ARM build problems? I don't see any
> bugs about this...

<http://ftp-master.debian.org/testing/>, follow the links for samba...  The
exact reference for the arm autobuilder is at
<http://buildd.armlinux.org/~buildd/build.php?pkg=samba&ver=2.2.1a-4&arch=arm>.

Regards,
Steve Langasek
postmodern programmer


diff -uNrw samba-2.2.1a-bak/debian/changelog samba-2.2.1a/debian/changelog
--- samba-2.2.1a-bak/debian/changelog	Thu Aug 23 10:27:54 2001
+++ samba-2.2.1a/debian/changelog	Thu Aug 23 10:28:08 2001
@@ -1,3 +1,12 @@
+samba (2.2.1a-4.1) unstable; urgency=low
+
+  * Fix up the build system to avoid needing to run configure as root to
+    answer questions we already know the answers to.
+  * In the process, make surprising progress towards being able to
+    cross-compile the samba packages.
+
+ -- Steve Langasek <vorlon@debian.org>  Wed, 22 Aug 2001 23:35:00 -0500
+
 samba (2.2.1a-4) unstable; urgency=low

   * Fixed typo in smbmount's mount page.
diff -uNrw samba-2.2.1a-bak/debian/config.cache samba-2.2.1a/debian/config.cache
--- samba-2.2.1a-bak/debian/config.cache	Wed Dec 31 18:00:00 1969
+++ samba-2.2.1a/debian/config.cache	Thu Aug 23 10:28:08 2001
@@ -0,0 +1,231 @@
+#
+# 22 August 2001  Steve Langasek <vorlon@debian.org>
+#
+# This file is a shell script that caches the results of configure
+# tests run on this system so they can be shared between configure
+# scripts and configure runs.  It is not useful on other systems.
+# If it contains results you don't want to keep, you may remove or edit it.
+#
+# By default, configure uses ./config.cache as the cache file,
+# creating it if it does not exist already.  You can give configure
+# the --cache-file=FILE option to use a different cache file; that is
+# what configure does when it calls configure scripts in
+# subdirectories, so they share the cache.
+# Giving --cache-file=/dev/null disables caching, for debugging configure.
+# config.status only pays attention to the cache file if you give it the
+# --recheck option to rerun configure.
+#
+#
+# This config.cache file contains a list of acceptable autoconf
+# values which can be used in compiling Samba for Debian woody/sid.
+#
+# Autoconf sorts options alphabetically in its output.  This file
+# groups options logically.
+
+
+# Load any architecture-specific settings
+if [ -n "$DEB_HOST_GNU_TYPE" \
+     -a -f ../debian/config.cache.${DEB_HOST_GNU_TYPE} ]; then
+	. ../debian/config.cache.${DEB_HOST_GNU_TYPE}
+fi
+
+
+# This is at the top because it's most in need of regular tweaking.
+# These are options which are supported on 2.4 kernels, but not on 2.2
+# kernels.
+
+samba_cv_HAVE_KERNEL_OPLOCKS_LINUX=${samba_cv_HAVE_KERNEL_OPLOCKS_LINUX=no}
+samba_cv_HAVE_KERNEL_CHANGE_NOTIFY=${samba_cv_HAVE_KERNEL_CHANGE_NOTIFY=no}
+samba_cv_HAVE_KERNEL_SHARE_MODES=${samba_cv_HAVE_KERNEL_SHARE_MODES=no}
+
+
+# These are present in 2.2 kernels, but not in 2.0...
+
+samba_cv_have_setresuid=${samba_cv_have_setresuid=yes}
+samba_cv_have_setresgid=${samba_cv_have_setresgid=yes}
+samba_cv_USE_SETRESUID=${samba_cv_USE_SETRESUID=yes}
+
+
+# POSIX ACL support not present in Linux 2.2; not allowed in the
+# Debian packages, even if present on the build machine.
+
+ac_cv_header_sys_acl_h=${ac_cv_header_sys_acl_h=no}
+
+
+# Various basic libc/compiler stuff that it's blindingly obvious that
+# Linux supports (now watch me get bitten for saying that)
+
+ac_cv_c_const=${ac_cv_c_const=yes}
+ac_cv_c_inline=${ac_cv_c_inline=inline}
+samba_cv_volatile=${samba_cv_volatile=yes}
+ac_cv_dirent_d_off=${ac_cv_dirent_d_off=yes}
+ac_cv_func_bzero=${ac_cv_func_bzero=yes}
+ac_cv_func_chmod=${ac_cv_func_chmod=yes}
+ac_cv_func_chown=${ac_cv_func_chown=yes}
+ac_cv_func_chroot=${ac_cv_func_chroot=yes}
+ac_cv_func_connect=${ac_cv_func_connect=yes}
+ac_cv_func_dup2=${ac_cv_func_dup2=yes}
+ac_cv_func_execl=${ac_cv_func_execl=yes}
+ac_cv_func_fchmod=${ac_cv_func_fchmod=yes}
+ac_cv_func_fchown=${ac_cv_func_fchown=yes}
+ac_cv_func_fstat=${ac_cv_func_fstat=yes}
+ac_cv_func_fsync=${ac_cv_func_fsync=yes}
+ac_cv_func_ftruncate=${ac_cv_func_ftruncate=yes}
+ac_cv_func_getcwd=${ac_cv_func_getcwd=yes}
+ac_cv_func_getgrent=${ac_cv_func_getgrent=yes}
+ac_cv_func_getgrnam=${ac_cv_func_getgrnam=yes}
+ac_cv_func_getspnam=${ac_cv_func_getspnam=yes}
+ac_cv_func_glob=${ac_cv_func_glob=yes}
+ac_cv_func_grantpt=${ac_cv_func_grantpt=yes}
+ac_cv_func_initgroups=${ac_cv_func_initgroups=yes}
+ac_cv_func_llseek=${ac_cv_func_llseek=yes}
+ac_cv_func_memcmp_clean=${ac_cv_func_memcmp_clean=yes}
+ac_cv_func_memmove=${ac_cv_func_memmove=yes}
+ac_cv_func_memset=${ac_cv_func_memset=yes}
+ac_cv_func_mktime=${ac_cv_func_mktime=yes}
+ac_cv_func_pipe=${ac_cv_func_pipe=yes}
+ac_cv_func_poll=${ac_cv_func_poll=yes}
+ac_cv_func_pread=${ac_cv_func_pread=yes}
+ac_cv_func_pwrite=${ac_cv_func_pwrite=yes}
+ac_cv_func_rand=${ac_cv_func_rand=yes}
+ac_cv_func_random=${ac_cv_func_random=yes}
+ac_cv_func_readlink=${ac_cv_func_readlink=yes}
+ac_cv_func_rename=${ac_cv_func_rename=yes}
+ac_cv_func_select=${ac_cv_func_select=yes}
+ac_cv_func_setenv=${ac_cv_func_setenv=yes}
+ac_cv_func_setgroups=${ac_cv_func_setgroups=yes}
+ac_cv_func_setsid=${ac_cv_func_setsid=yes}
+ac_cv_func_sigaction=${ac_cv_func_sigaction=yes}
+ac_cv_func_sigblock=${ac_cv_func_sigblock=yes}
+ac_cv_func_sigprocmask=${ac_cv_func_sigprocmask=yes}
+ac_cv_func_snprintf=${ac_cv_func_snprintf=yes}
+ac_cv_func_srand=${ac_cv_func_srand=yes}
+ac_cv_func_srandom=${ac_cv_func_srandom=yes}
+ac_cv_func_strcasecmp=${ac_cv_func_strcasecmp=yes}
+ac_cv_func_strchr=${ac_cv_func_strchr=yes}
+ac_cv_func_strdup=${ac_cv_func_strdup=yes}
+ac_cv_func_strerror=${ac_cv_func_strerror=yes}
+ac_cv_func_strftime=${ac_cv_func_strftime=yes}
+ac_cv_func_strpbrk=${ac_cv_func_strpbrk=yes}
+ac_cv_func_strtoul=${ac_cv_func_strtoul=yes}
+ac_cv_func_symlink=${ac_cv_func_symlink=yes}
+ac_cv_func_usleep=${ac_cv_func_usleep=yes}
+ac_cv_func_utime=${ac_cv_func_utime=yes}
+ac_cv_func_utimes=${ac_cv_func_utimes=yes}
+ac_cv_func_vsnprintf=${ac_cv_func_vsnprintf=yes}
+ac_cv_func_waitpid=${ac_cv_func_waitpid=yes}
+ac_cv_type_ino_t=${ac_cv_type_ino_t=yes}
+ac_cv_type_mode_t=${ac_cv_type_mode_t=yes}
+ac_cv_type_pid_t=${ac_cv_type_pid_t=yes}
+ac_cv_type_size_t=${ac_cv_type_size_t=yes}
+ac_cv_type_uid_t=${ac_cv_type_uid_t=yes}
+samba_cv_socklen_t=${samba_cv_socklen_t=yes}
+
+# Yes, we know Linux supports fcntl locking.  Just ignore
+# any errors caused by building on an NFS mount.
+samba_cv_HAVE_FCNTL_LOCK=${samba_cv_HAVE_FCNTL_LOCK=yes}
+
+
+# smbwrapper doesn't work because the glibc maintainers don't want
+# to support transparent userland VFS.  We might as well preempt
+# any checks for shadowed symbols that are only useful for smbwrapper.
+
+ac_cv_func___acl=${ac_cv_func___acl=no}
+ac_cv_func__acl=${ac_cv_func__acl=no}
+ac_cv_func___chdir=${ac_cv_func___chdir=no}
+ac_cv_func__chdir=${ac_cv_func__chdir=no}
+ac_cv_func___close=${ac_cv_func___close=no}
+ac_cv_func__close=${ac_cv_func__close=no}
+ac_cv_func___closedir=${ac_cv_func___closedir=no}
+ac_cv_func__closedir=${ac_cv_func__closedir=no}
+ac_cv_func___dup=${ac_cv_func___dup=no}
+ac_cv_func__dup=${ac_cv_func__dup=no}
+ac_cv_func___dup2=${ac_cv_func___dup2=no}
+ac_cv_func__dup2=${ac_cv_func__dup2=no}
+ac_cv_func___facl=${ac_cv_func___facl=no}
+ac_cv_func__facl=${ac_cv_func__facl=no}
+ac_cv_func___fchdir=${ac_cv_func___fchdir=no}
+ac_cv_func__fchdir=${ac_cv_func__fchdir=no}
+ac_cv_func___fcntl=${ac_cv_func___fcntl=no}
+ac_cv_func__fcntl=${ac_cv_func__fcntl=no}
+ac_cv_func___fork=${ac_cv_func___fork=no}
+ac_cv_func__fork=${ac_cv_func__fork=no}
+ac_cv_func___fstat=${ac_cv_func___fstat=no}
+ac_cv_func__fstat=${ac_cv_func__fstat=no}
+ac_cv_func___fstat64=${ac_cv_func___fstat64=no}
+ac_cv_func__fstat64=${ac_cv_func__fstat64=no}
+ac_cv_func___fxstat=${ac_cv_func___fxstat=no}
+ac_cv_func___getcwd=${ac_cv_func___getcwd=no}
+ac_cv_func__getcwd=${ac_cv_func__getcwd=no}
+ac_cv_func___getdents=${ac_cv_func___getdents=no}
+ac_cv_func__getdents=${ac_cv_func__getdents=no}
+ac_cv_func___llseek=${ac_cv_func___llseek=no}
+ac_cv_func___sys_llseek=${ac_cv_func___sys_llseek=no}
+ac_cv_func__llseek=${ac_cv_func__llseek=no}
+ac_cv_func___lseek=${ac_cv_func___lseek=no}
+ac_cv_func__lseek=${ac_cv_func__lseek=no}
+ac_cv_func___lstat=${ac_cv_func___lstat=no}
+ac_cv_func__lstat=${ac_cv_func__lstat=no}
+ac_cv_func___lstat64=${ac_cv_func___lstat64=no}
+ac_cv_func__lstat64=${ac_cv_func__lstat64=no}
+ac_cv_func___lxstat=${ac_cv_func___lxstat=no}
+ac_cv_func___open=${ac_cv_func___open=no}
+ac_cv_func__open=${ac_cv_func__open=no}
+ac_cv_func___open64=${ac_cv_func___open64=no}
+ac_cv_func__open64=${ac_cv_func__open64=no}
+ac_cv_func___opendir=${ac_cv_func___opendir=no}
+ac_cv_func__opendir=${ac_cv_func__opendir=no}
+ac_cv_func___pread=${ac_cv_func___pread=no}
+ac_cv_func__pread=${ac_cv_func__pread=no}
+ac_cv_func___pread64=${ac_cv_func___pread64=no}
+ac_cv_func__pread64=${ac_cv_func__pread64=no}
+ac_cv_func___pwrite=${ac_cv_func___pwrite=no}
+ac_cv_func__pwrite=${ac_cv_func__pwrite=no}
+ac_cv_func___pwrite64=${ac_cv_func___pwrite64=no}
+ac_cv_func__pwrite64=${ac_cv_func__pwrite64=no}
+ac_cv_func___read=${ac_cv_func___read=no}
+ac_cv_func__read=${ac_cv_func__read=no}
+ac_cv_func___readdir=${ac_cv_func___readdir=no}
+ac_cv_func__readdir=${ac_cv_func__readdir=no}
+ac_cv_func___readdir64=${ac_cv_func___readdir64=no}
+ac_cv_func__readdir64=${ac_cv_func__readdir64=no}
+ac_cv_func___seekdir=${ac_cv_func___seekdir=no}
+ac_cv_func__seekdir=${ac_cv_func__seekdir=no}
+ac_cv_func___stat=${ac_cv_func___stat=no}
+ac_cv_func__stat=${ac_cv_func__stat=no}
+ac_cv_func___stat64=${ac_cv_func___stat64=no}
+ac_cv_func__stat64=${ac_cv_func__stat64=no}
+ac_cv_func___telldir=${ac_cv_func___telldir=no}
+ac_cv_func__telldir=${ac_cv_func__telldir=no}
+ac_cv_func___write=${ac_cv_func___write=no}
+ac_cv_func__write=${ac_cv_func__write=no}
+ac_cv_func___xstat=${ac_cv_func___xstat=no}
+
+
+
+# Miscellaneous stuff that isn't, and shouldn't be, available
+# in Debian.  Those interested in building debs for other systems may
+# need to remove some of these defines.
+
+ac_cv_func_bigcrypt=${ac_cv_func_bigcrypt=no}
+ac_cv_func_crypt16=${ac_cv_func_crypt16=no}
+ac_cv_func_getauthuid=${ac_cv_func_getauthuid=no}
+ac_cv_func_getprpwnam=${ac_cv_func_getprpwnam=no}
+ac_cv_func_getpwanam=${ac_cv_func_getpwanam=no}
+ac_cv_func_putprpwnam=${ac_cv_func_putprpwnam=no}
+ac_cv_func_rdchk=${ac_cv_func_rdchk=no}
+ac_cv_func_set_auth_parameters=${ac_cv_func_set_auth_parameters=no}
+ac_cv_func_setgidx=${ac_cv_func_setgidx=no}
+ac_cv_func_setluid=${ac_cv_func_setluid=no}
+ac_cv_func_setpriv=${ac_cv_func_setpriv=no}
+ac_cv_func_setuidx=${ac_cv_func_setuidx=no}
+ac_cv_lib_sec_bigcrypt=${ac_cv_lib_sec_bigcrypt=no}
+ac_cv_lib_sec_getprpwnam=${ac_cv_lib_sec_getprpwnam=no}
+ac_cv_lib_sec_getspnam=${ac_cv_lib_sec_getspnam=no}
+ac_cv_lib_sec_putprpwnam=${ac_cv_lib_sec_putprpwnam=no}
+ac_cv_lib_sec_set_auth_parameters=${ac_cv_lib_sec_set_auth_parameters=no}
+ac_cv_lib_security_bigcrypt=${ac_cv_lib_security_bigcrypt=no}
+ac_cv_lib_security_getprpwnam=${ac_cv_lib_security_getprpwnam=no}
+ac_cv_lib_security_getspnam=${ac_cv_lib_security_getspnam=no}
+ac_cv_lib_security_putprpwnam=${ac_cv_lib_security_putprpwnam=no}
+ac_cv_lib_security_set_auth_parameters=${ac_cv_lib_security_set_auth_parameters=no}
diff -uNrw samba-2.2.1a-bak/debian/config.cache.alpha-linux samba-2.2.1a/debian/config.cache.alpha-linux
--- samba-2.2.1a-bak/debian/config.cache.alpha-linux	Wed Dec 31 18:00:00 1969
+++ samba-2.2.1a/debian/config.cache.alpha-linux	Thu Aug 23 10:28:08 2001
@@ -0,0 +1,12 @@
+# 22 Aug 2001  Steve Langasek <vorlon@debian.org>
+
+# This file contains autoconf settings specific to the alpha-linux
+# platform that should be preloaded when building for this architecture.
+
+
+# Linux 2.2 on Alpha doesn't have a functional setresgid() call, but
+# Linux 2.4 does.  Ensure that packages compiled for woody remain
+# compatible with 2.2 kernels, even if the build machine is running 2.4.
+samba_cv_have_setresgid=${samba_cv_have_setresgid=no}
+samba_cv_USE_SETRESUID=${samba_cv_USE_SETRESUID=no}
+samba_cv_USE_SETREUID=${samba_cv_USE_SETREUID=yes}
diff -uNrw samba-2.2.1a-bak/debian/rules samba-2.2.1a/debian/rules
--- samba-2.2.1a-bak/debian/rules	Thu Aug 23 10:27:54 2001
+++ samba-2.2.1a/debian/rules	Thu Aug 23 10:28:08 2001
@@ -15,6 +15,14 @@
 # This has to be exported to make some magic below work.
 export DH_OPTIONS

+# Set the host and build architectures for use with config.cache loading,
+# cross-building, etc.
+DEB_HOST_GNU_TYPE	:= $(shell dpkg-architecture -qDEB_HOST_GNU_TYPE)
+DEB_BUILD_GNU_TYPE	:= $(shell dpkg-architecture -qDEB_BUILD_GNU_TYPE)
+
+export DEB_HOST_GNU_TYPE
+export DEB_BUILD_GNU_TYPE
+
 BVARS = SMBLOGFILE=/var/log/smb NMBLOGFILE=/var/log/nmb

 DESTDIR=`pwd`/debian/samba
@@ -48,8 +56,11 @@
 #     ./configure --with-fhs --prefix=/usr --sysconfdir=/etc \
 #        --localstatedir=/var

+	if [ -f debian/config.cache ]; then \
+		cp -f debian/config.cache source/config.cache; \
+	fi
 #	[ -f source/Makefile ] || (cd source && ./configure --with-fhs --prefix=/usr --exec-prefix=/usr --with-netatalk --with-smbmount --with-pam --with-syslog --with-sambabook --with-utmp)
-	[ -f source/Makefile ] || (cd source && ./configure --with-fhs --prefix=/usr --sysconfdir=/etc --with-privatedir=/etc/samba --with-lockdir=/var/state/samba --localstatedir=/var --with-netatalk --with-smbmount --with-pam --with-syslog --with-sambabook --with-utmp --with-readline --with-pam_smbpass)
+	[ -f source/Makefile ] || (cd source && ./configure --host=$(DEB_HOST_GNU_TYPE)-gnu --build=$(DEB_BUILD_GNU_TYPE)-gnu --with-fhs --prefix=/usr --sysconfdir=/etc --with-privatedir=/etc/samba --with-lockdir=/var/state/samba --localstatedir=/var --with-netatalk --with-smbmount --with-pam --with-syslog --with-sambabook --with-utmp --with-readline --with-pam_smbpass)

 	touch configure-stamp

Building Samba Packages for Debian GNU/Linux
--------------------------------------------

Building Debian packages is not as hard as some people might think.
The following instructions will allow you to build your own Samba
Debian packages. These instructions and the files in packaging/Debian/
are current as of Samba 3.0.0, and allow you to build Debian packages
for Debian unstable (so you need some development packages available
only in Debian unstable.) If you are using something newer than 3.0.0
you might want to try to follow the instructions to see if patches
apply cleanly. If some patches don't apply cleanly please e-mail
samba@packages.debian.org since we might have fixed patches that we have
not yet integrated into upstream Samba.

We try to maintain as much compatibility with previous releases
of Debian as possible, so it is possible that the files in
packaging/Debian/ can also be used to build Samba Debian packages for
other Debian releases. However, sometimes this is just not possible
because we need to use stuff that is only available on Debian unstable.

Instructions
------------

If you want to build Samba packages for Debian and you just want to use
upstream sources, i.e. you don't want to wait for us to put official
packages out, or you want packages for a Debian version for which we
don't provide deb's, or you don't want to use official packages, or
you want to add --this-cool-switch to configure, or whatever, follow
these instructions:

0) Make sure you have the following packages installed (in addition
to the normal Debian development packages -- dpkg-dev, libc6-dev,
devscripts, etc.):

  autoconf
  debhelper
  libpam0g-dev
  libreadline4-dev
  libcupsys2-dev
  acl-dev, libacl1
  libkrb5-dev
  libldap2-dev
  python2.2-dev

  Notes regarding the packages required to build Samba Debian packages:

  * The libcupsys2-dev is not available in Debian Potato (Debian 2.2).
    That's fine; the configure script won't detect CUPS support and the
    resulting binaries won't support CUPS.

  * The list above is current as of samba-3.0.0rc2, but it can get
    out of date. The best way to check what packages are required to
    build the samba packages on Debian is to look for the Build-Depends:
    field in the file debian/control.

1) cd samba[-<version>]. For example, "cd samba-3.0.0rc2".
2) cp -a packaging/Debian/debian/ debian
  It's important that you copy instead of symlink because the build
  tools in Potato have a problem that prevents the build to work with
  a symlink.
3) dch -i (this is completely optional - only do it if you understand
   Debian version numbers! Don't complain later if you can't upgrade
   to official versions of the Samba packages for Debian.)
  - Edit the changelog and make sure the version is right. For example,
    for Samba 3.0.0beta3, the version number should something like
  3.0.0beta3-0.1.
4) Run 'debian/rules binary'.
  - It is better that you prefix the above command with 'fakeroot'.
    If you have problems you might try building as root.
5) That's it. Your new packages should be in ../. Install with dpkg.

Please e-mail samba@packages.debian.org with comments, questions or
suggestions. Please talk to us and not to the Samba Team. They have
better things to do and know nothing about the Debian packaging system.

Eloy A. Paris <peloy@debian.org>
Steve Langasek <vorlon@debian.org>

0. Samba Team Notes:
This package is targeted at the current stable release of debian distribution
(woody) running on a 2.4.x kernel.
This package has been made by Simo Sorce on behalf of the Samba Team.
Do not use Debian BTS to report bugs, it's not a debian project package.
Thanks to Eloy Paris and Steve "Vorlon" Langasek for the work they've done
and continue to do on debian unstable packages. That made me possible to
build up debian packages for the Team.


ATTENTION: This package works correctly only with recent 2.4.x kernels due to
deep optimizations that samba uses when compiled on such kernels.


Original README.Debian foolows.
-----------------------------------------------------------------------------

Samba for Debian
----------------

This package was built by Eloy Paris <peloy@debian.org> and Steve Langasek
<vorlon@debian.org>, current maintainers of the Samba packages for Debian,
based on previous work from Bruce Perens <Bruce@Pixar.com>, Andrew
Howell <andrew@it.com.au>, Klee Dienes <klee@debian.org> and Michael
Meskes <meskes@topsystem.de>, all previous maintainers of the packages
samba and sambades (merged together for longer than we can remember.)

Contents of this README file:

1. Notes
2. Upgrading from Samba 2.2
3. Packages Generated from the Samba Sources
4. Support for NT Domains
5. Reporting bugs


1. Notes
--------

- As of Samba 2.0.6-1, the Debian version of Samba is compiled with
  Pluggable Authentication Modules (PAM) support. PAM support was 
  discontinued during the libc5 -> libc6 migration process and I never
  brought it back until 2.0.6-1.

- The smbfs package does not support the 2.0.x Linux kernels anymore.
  This has been the case since the very first packages of the CVS sources
  that eventually became Samba 2.2. To use the smbfs package you need to
  run a 2.2.x kernel or later.

- Starting with the Debian packages for Samba 2.2, the Samba log files (for
  nmbd and smbd) have been moved to a new location: /var/log/samba/. The
  files also have new names: log.nmbd and log.smbd. The old files
  (/var/log/{nmb,smb} were moved to the new location.


2. Upgrading from Samba 2.2
---------------------------

Samba 3.0 provides greatly improved support for modern Windows systems,
including support for Unicode and LDAP.  In the process, Samba 3.0
necessarily also breaks backward compatiblity with past releases.  These
issues are documented herein; if you are aware of other problems related
to upgrading from Samba 2.2, please let us know at
<samba@packages.debian.org>.

Samba and LDAP
--------------
Starting with Samba 2.999+3.0cvs20020723-1 we are building Samba with
LDAP support.  However, the LDAP schema for Samba 3.0 differs
substantially from the schema used by many sites with Samba 2.2 (not
enabled in the Debian packages).  If upgrading from an LDAP-enabled 2.2,
you will need to run the convertSambaAccount script found in
/usr/share/doc/samba-doc/examples/LDAP.  A copy of the schema itself can
also be found at /usr/share/doc/samba-doc/examples/LDAP/samba.schema.

Character Sets
--------------
Samba 3.0 introduces support for negotiating Unicode (UCS-2LE) with
Windows clients.  Owing to the close similarity between Windows and Unix
NLS charsets, in the past, many users were able to pass filenames
containing non-ASCII characters between clients and servers without
configuring Samba to know what character set was in use.  Now, Samba
must be able to convert Unix filenames to Unicode before sending to the
client, so Samba must know what character set the filenames are being
converted from.  If you will be sharing files with non-ASCII names, and
the filenames are not encoded with UTF-8, you will need to tell Samba
which character set to use with the 'unix charset' option.

If you had previously specified 'character set' and 'client code page'
options under 2.2, these settings should be automatically converted for
you.


3. Packages Generated from the Samba Sources
--------------------------------------------

Currently, the Samba sources produce the following binary packages:

samba: A LanManager like file and printer server for Unix.
samba-common: Samba common files used by both the server and the client.
smbclient: A LanManager like simple client for Unix.
swat: Samba Web Administration Tool
samba-doc: Samba documentation.
smbfs: Mount and umount commands for the smbfs (works with 2.2.x and
	above kernels, not with 2.0.x kernels.)
libpam-smbpass: pluggable authentication module for SMB password
	database.
libsmbclient: Shared library that allows applications to talk to SMB servers.
libsmbclient-dev: libsmbclient shared libraries.
winbind: Service to resolve user and group information from a Windows NT 
	server.
python2.2-samba: Python bindings that allow access to various aspects of
	Samba.

Please note that the package smbwrapper (a shared library that provides
SMB client services that existed between Samba 2.0.0-1 and Samba-2.0.5a-4
does not exist any more. The reason is that starting with Samba 2.0.6-1, that
code does not even compile, and the upstream author (Andrew Tridgell)
recommended to disable the compilation of smbwrapper until some issues
with glibc2.1 get cleared out (the problem is with glibc, not with Samba
itself).


4. Support for NT Domains
-------------------------

Samba 2.2 includes preliminary support for NT domains. A Samba server
can now be part of a Windows NT domain whose Primary Domain Controller
is a Windows NT server. This feature is supposed to be stable although I
haven't tried it myself. Read the documentation in the samba-doc package
for help on how to do this (hint: "security = domain" in the smb.conf
file).

Samba 2.2 has also experimental support for Primary Domain
Controller. This means that a Samba server can act now as a PDC. There
are no special flags needed to compile Samba with NT domain PDC
support. Please read the NTDOM PDC FAQ at www.samba.org (Documentation
section).

Please note that NT domain PDC support is far from complete and is still 
experimental.


5. Reporting Bugs
-----------------

**** NOTE: This package is distributed by the Samba Team based on Debian
     packages, please submit bus to https://bugzilla.samba.org instead ****

If you believe you have found a bug please make sure the possible bug
also exists in the latest version of Samba that is available for the
unstable Debian distribution. If you are running Debian stable this
means that you will probably have to build your own packages. And if the
problem does not exist in the latest version of Samba we have packaged it
means that you will have to run the version of Samba you built yourself
since it is not easy to upload new packages to the stable distribution,
unless they fix critical security problems.

If you can reproduce the problem in the latest version of Samba then
it is likely to be a real bug. Your best shot is to search the Samba
mailing lists to see if it is something that has already been reported
and fixed - if it is a simple fix we can add the patch to our packages
without waiting for a new Samba release.

If you decide that your problem deserves to be submitted to the Debian
Bug Tracking System (BTS) we expect you to be responsive if we request
more information. If we request more information and do not receive
any in a reasonable time frame expect to see your bug closed without
explanation - we can't fix bugs we can't reproduce, and most of the
time we need more information to be able to reproduce them.

When submitting a bug to the Debian BTS please include the version of
the Debian package you are using as well as the Debian distribution you
are using. Think _twice_ about the severity you assign to the bug: we
are _very_ sensitive about bug severities; the fact that it doesn't
work for you doesn't mean that the severity must be such that it holds
a major Debian release. In fact, that it doesn't work for you it
doesn't mean that it doesn't work for others. So again: think _twice_.


Eloy A. Paris <peloy@debian.org>
Steve Langasek <vorlon@debian.org>

Indexes created Thu Jun 27 20:29:42 MDT 2024