On Tue, 2008-07-29 at 19:17 +0100, Wookey wrote:
> On 2008-07-29 18:54 +0100, Neil Williams wrote:
> > If someone could either send me compressed native armel build logs for
> > these packages or upload the build logs to a server somewhere and send
> > me the URLs, I'd be grateful. Ta. (The build logs do need to be from a
> > native build on armel and for the version of the package currently in
> > Sid.)
>
> I've got a box I can do these builds on.
There is actually only one test still needed - Riku pointed me to the
armel build logs for everything except startup-notification which needs
just a single cache value:
lf_cv_sane_realloc
This is calculated in the test:
checking whether realloc (NULL,) will work
by compiling and running this code:
#include <stdlib.h>
int main() {
return realloc (0, sizeof (int)) == 0;
}
A non-zero exit status indicates a "no" to the test.
I've checked the Debian build logs for all builds that were made for
0.9-1 and all return the same value, "yes", i.e. exit value zero.
I'm beginning to wonder about these cache file results - the cache
values that do differ between architectures are already cached in
dpkg-cross because they are truly architecture-dependent. The cache
values that are calculated in the actual builds we need are more
*distribution* dependent - or possibly libc / kernel dependent in some
cases (i.e. linux vs hurd vs bsd not versions of the same kernel). Most
of the tests are for libraries and configuration options that are set
within Debian.
As such, it is possible that I may be able to collate the test results
into emdebian-tools and generate a file in /etc/ that stores the values
as retrieved from Debian, a linux kernel and glibc. The values could
then be checked by emdebian-tools and the file updated if any of the
values change - insuring us against stale cache values. A specially
crafted configure.ac could be used to generate the file, adding a
dependency on autoconf to emdebian-tools but that is not a problem due
to the existing dependency on build-essential, automake and gcc. The
test could be run by emsetup (which is called each time an empdebuild
chroot is updated).
Then, at a later date, I can experiment with uClibc build logs and see
if any of the values change - similarly someone can test with Hurd or
BSD kernels should anyone want to use Emdebian with such kernels.
So, something like:
/etc/emdebian/debian-glibc-linux.cache
Or maybe put the cache file under the control of dpkg-cross and thereby
dpkg? /etc/dpkg-cross/debian-glibc-linux.config ? dpkg-cross could then
be configured to include this file as the default site config cache
file, removing the need for any cache files in the Emdebian patch sets
and simplifying the patches for debian/rules. dpkg-cross has always had
this kind of support but it was not being updated. The downside of
calculating this within dpkg-cross control is the dependency on autoconf
to provide that calculation - this could also hinder migration of
dpkg-cross into dpkg-dev. It depends how often we can expect these
values to change.
This is the full (sorted and unique) list of cache values in use:
(most are self-descriptive)
ac_cv_file__etc_TIMEZONE=no
ac_cv_file__etc_environment=no
ac_cv_file__usr_lib_pkgconfig_libusb_pc=yes
ac_cv_file__usr_share_sgml_X11_defs_ent=no
ac_cv_func_calloc_0_nonnull=yes
ac_cv_func_fnmatch_gnu=yes
ac_cv_func_futimesat=yes
ac_cv_func_lstat_empty_string_bug=no
ac_cv_func_malloc_0_nonnull=yes
ac_cv_func_memcmp_working=yes
ac_cv_func_posix_getgrgid_r=yes
ac_cv_func_posix_getpwnam_r=yes
ac_cv_func_posix_getpwuid_r=yes
ac_cv_func_realloc_0_nonnull=yes
ac_cv_func_regcomp=yes
ac_cv_func_setpgrp=yes
ac_cv_func_setpgrp_void=yes
ac_cv_glibc_ver=libc6.6
ac_cv_have_abstract_sockets=yes
ac_cv_have_decl_wcwidth=yes
ac_cv_header_gdbm_h=yes
ac_cv_header_readline_h=yes
ac_cv_lib_blkid_blkid_known_fstype=yes
ac_cv_lib_gdbm_gdbm_open=yes
ac_cv_lib_uuid_uuid_is_null=yes
ac_cv_path_GLIB_GENMARSHAL=/usr/bin/glib-genmarshal
ac_cv_printf_positional=yes
ac_cv_prog_cc_c89=
ac_cv_prog_cc_c99=${ac_cv_prog_cc_c99=-std=gnu99}
ac_cv_prog_cc_stdc=${ac_cv_prog_cc_stdc=-std=gnu99}
ac_cv_type_mode_t=yes
ac_cv_va_copy=yes
archive_cmds_need_lc=no
archive_cmds_need_lc_CXX=no
archive_cmds_need_lc_F77=no
archive_cmds_need_lc_GCJ=no
dpkg_cv_va_copy=yes
fu_cv_sys_stat_statfs2_bsize=yes
gl_cv_func_fchownat_nofollow_works=yes
gl_cv_func_fflush_stdin=yes
gl_cv_func_getcwd_null=yes
gl_cv_func_gettimeofday_clobber=no
gl_cv_func_gnu_getopt=yes
gl_cv_func_signbit=yes
gl_cv_func_tzset_clobber=no
gl_cv_func_wcwidth_works=yes
gl_cv_func_working_acl_get_file=yes
gl_cv_header_working_fcntl_h=yes
gl_cv_struct_dirent_d_ino=yes
glib_cv_monotonic_clock=yes
glib_cv_stack_grows=no
glib_cv_uscore=no
gnupg_cv_c_endian=little
jm_cv_func_gettimeofday_clobber=no
krb5_cv_attr_constructor_destructor=yes,yes
lf_cv_sane_realloc=yes
libIDL_cv_long_long_format=%llu
libopts_cv_run_fopen_binary=yes
libopts_cv_run_fopen_text=yes
libopts_cv_run_strftime=yes
libopts_cv_with_libregex=yes
lt_cv_path_NM="/usr/bin/nm -B"
sudo_cv_ebcdic=no
tmp_assumed_endian=little
utils_cv_localtime_cache=no
with_openssl_incdir=yes
with_openssl_libdir=yes
gnupg_cv_c_endian=little and tmp_assumed_endian=little come from GnuPG
and there might be a cleaner way of calculating this value which would
appear to be the (only) arch-dependent values.
ac_cv_glibc_ver=libc6.6 comes from apt and might not be necessary if
debian/rules was to set this value directly.
--
Neil Williams
=============
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/
Attachment:
signature.asc
Description: This is a digitally signed message part