readme.build

samba服务器！

From: Steve Langasek <[e-mail]>
To: "Eloy A. Paris" <[e-mail]>
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: <[e-mail]>
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 <[e-mail]>  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 <[e-mail]>
+#
+# 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}