from:"Steven Chamberlain"

I've set up some additional jobs at
http://jenkins.kfreebsd.eu/jenkins/view/cd/

and after much trial-and-error, there are now (untested) sid netinst
images built for:
hurd-i386 kfreebsd-amd64 kfreebsd-i386 powerpc

You can find the .iso images within each job's workspace e.g.:
http://jenkins.kfreebsd.eu/jenkins/view/cd/job/debian-cd_sid_hurd-i386/ws/build/

It's building on a kfreebsd-amd64 host, in a jessie-kfreebsd chroot,
with current Git master of debian-cd, my patches for #860187 and
#860204 applied, and the attached diff against CONF.sh.  I started each
build like this:

$ export CODENAME=sid
$ export ARCHES=hurd-i386
$ CONF.sh && ./build.sh

Regards,
-- 
Steven Chamberlain
ste...@pyro.eu.org
diff --git a/CONF.sh b/CONF.sh
index 99e58ad..08ffbd7 100644
--- a/CONF.sh
+++ b/CONF.sh
@@ -62,11 +62,15 @@ export BASEDIR=`pwd`
 # export CDNAME=debian
 
 # Building $codename cd set ...
-export CODENAME=stretch
+#export CODENAME=stretch
 
 # By default use Debian installer packages from $CODENAME
 if [ -z "$DI_CODENAME" ]; then
-	export DI_CODENAME=$CODENAME
+	if [ "${CODENAME}" = "jessie-kfreebsd" ]; then
+		export DI_CODENAME=${CODENAME}-proposed-updates
+	else
+		export DI_CODENAME=${CODENAME}
+	fi
 fi
 # If you want backported d-i (e.g. by setting
 # DI_CODENAME=jessie-backports, then you'll almost definitely also
@@ -86,7 +90,7 @@ fi
 #export DI_WWW_HOME=default
 
 # Version number, "2.2 r0", "2.2 r1" etc.
-export DEBVERSION="9.0"
+export DEBVERSION="unofficial"
 
 # Official or non-official set.
 # NOTE: THE "OFFICIAL" DESIGNATION IS ONLY ALLOWED FOR IMAGES AVAILABLE
@@ -119,17 +123,17 @@ fi
 #	  images, however. Also, if you are using an NFS partition for
 #	  some part of this, you must use this option.
 # Paths to the mirrors
-export MIRROR=/srv/mirror/debian
+export MIRROR=/srv/ftp.debian.org
 
 # Path of the temporary directory
-export TDIR=/srv/mirror/tmp
+export TDIR=/home/cd/tmp
 
 # Path where the images will be written
-export OUT=/srv/mirror/debian-cd-test
+export OUT=/home/cd/out
 
 # Where we keep the temporary apt stuff.
 # This cannot reside on an NFS mount.
-export APTTMP=/srv/mirror/tmp/apt
+export APTTMP=$TDIR/apt
 
 # Do I want to have NONFREE merged in the CD set
 # export NONFREE=1
@@ -164,7 +168,9 @@ export CONTRIB=1
 # Note that on the CDs it will not be visible where packages came from:
 # from the released archive or from proposed updates archive.
 # NOTE: intended to be used for pre-release testing, not for publication!
-#export PROPOSED_UPDATES=$CODENAME-proposed-updates
+if [ "${CODENAME}" = "jessie-kfreebsd" ]; then
+	export PROPOSED_UPDATES=$CODENAME-proposed-updates
+fi
 
 # Sparc only : bootdir (location of cd.b and second.b)
 # export BOOTDIR=/boot
@@ -175,7 +181,7 @@ export CONTRIB=1
 # Use this to force copying the files instead of symlinking or hardlinking
 # them. This is useful if your destination directories are on a different
 # partition than your source files.
-# export COPYLINK=1
+export COPYLINK=1
 
 # Options
 # export MKISOFS=mkisofs
@@ -190,6 +196,12 @@ export CONTRIB=1
 #export i386_MKISOFS_OPTS="-as mkisofs -r -checksum_algorithm_iso md5,sha1"
 #export amd64_MKISOFS="xorriso"
 #export amd64_MKISOFS_OPTS="-as mkisofs -r -checksum_algorithm_iso md5,sha1"
+export hurd_i386_MKISOFS="xorriso"
+export hurd_i386_MKISOFS_OPTS="-as mkisofs -r -checksum_algorithm_iso sha256"
+export kfreebsd_i386_MKISOFS="xorriso"
+export kfreebsd_i386_MKISOFS_OPTS="-as mkisofs -r -checksum_algorithm_iso sha256"
+export kfreebsd_amd64_MKISOFS="xorriso"
+export kfreebsd_amd64_MKISOFS_OPTS="-as mkisofs -r -checksum_algorithm_iso sha256"
 
 # Keyring (defaults):
 #ARCHIVE_KEYRING_PACKAGE=debian-archive-keyring
@@ -233,7 +245,7 @@ ATTEMPT_FALLBACK=yes
 # STICK4GB:  4GB USB stick or similar
 # STICK8GB:  8GB USB stick or similar
 # CUSTOM:up to you - specify a size to go with it (in 2K blocks)
-export DISKTYPE=CD
+export DISKTYPE=NETINST
 #export DISKTYPE=CUSTOM
 #export CUSTOMSIZE=
 # If you want to over-ride this choice (e.g. to make a larger version of a given disk),
@@ -242,7 +254,7 @@ export DISKTYPE=CD
 # export FORCE_CD_SIZE1= to change the size of disk 1 (only)
 
 # Extra variants to enable. See docs/README.variants for more information.
-export VARIANTS=
+export VARIANTS=light
 
 # We don't want certain packages to take up space on CD1...
 #export EXCLUDE1=exclude
@@ -375,8 +387,8 @@ export SNAPURL=Debian=http://snapshot.debian.org/archive/debian/SNAPDATETIME/
 # INSTALLER_CD=0: nothing special (default)
 # INSTALLER_CD=1: just add debian-installer (use TASK=debian-installer)
 # INSTALLER_CD=2: add d-i and base (use TASK=debian-installer+kernel)
-#export INSTALLER_CD=2
-#export TASK=debian-installer+kernel
+export INSTALLER_CD

Bug#860204: debian-cd: Fix update_tasks on non-Linux arches

Source: debian-cd
Version: 3.1.20
Tags: patch
User: debian-bsd@lists.debian.org
Usertags: kfreebsd
X-Debbugs-Cc: debian-bsd@lists.debian.org

Hi!

tools/update_tasks was failing for me on kfreebsd, with:
update_tasks: Can't determine arch

In the filename of the coreutils .deb, the architecture part
may contain a hyphen in the case of hurd-i386 or kfreebsd-*.
But it currently only matches alpha or numeric.

Patch is attached.  Thanks!

Regards,
-- 
Steven Chamberlain
ste...@pyro.eu.org
From c0104be3e511052c5cab4d561b5887abd4b4dd89 Mon Sep 17 00:00:00 2001
From: Steven Chamberlain <ste...@pyro.eu.org>
Date: Wed, 12 Apr 2017 20:05:15 +0100
Subject: [PATCH] Fix update_tasks on non-Linux arches

In the filename of the coreutils .deb, the architecture part
may also contain a hyphen in the case of hurd-i386 or
kfreebsd-*
---
 tools/update_tasks | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/update_tasks b/tools/update_tasks
index b9fe207..03e03ac 100755
--- a/tools/update_tasks
+++ b/tools/update_tasks
@@ -44,7 +44,7 @@ if (defined($ENV{'FORCE_SID_TASKSEL'}) and $ENV{'FORCE_SID_TASKSEL'} eq '1') {
 # is a non -all package) to determine a valid arch for the rest of
 # this script
 my $coreutils_deb = `$basedir/tools/which_deb $mirror $codename coreutils binary`;
-if ($coreutils_deb =~ m/_([[:alnum:]]+)\.deb/) {
+if ($coreutils_deb =~ m/_([[:alnum:]-]+)\.deb/) {
 $arch = $1;
 } else {
 die "update_tasks: Can't determine arch!\n";
-- 
1.8.4.rc3



signature.asc
Description: Digital signature

Bug#860187: debian-cd: Fix which_deb handling of non-Linux arches

Source: debian-cd
Version: 3.1.20
Tags: patch
User: debian-bsd@lists.debian.org
Usertags: kfreebsd
X-Debbugs-Cc: debian-bsd@lists.debian.org

Hi!

When which_deb finds "*i386" or "*amd64" entries in the ARCHES list,
it will wrongly change them to "i386" to "amd64" respectively (which
is wrong in the case of kfreebsd-* or hurd-*).

My attached patch makes the same changes here that were already made to
identical code in generate_di_list, to fix #758512 (commits
771f754516b161f248c132ee9d698e33a6330de0 and
2ef5d3288cdc772cdcbb7b5d11192305dd05b063).

Thanks!
Regards,
-- 
Steven Chamberlain
ste...@pyro.eu.org
From 544806f93e860f01f6f1167af2b4462074479af7 Mon Sep 17 00:00:00 2001
From: Steven Chamberlain <stev...@debian.org>
Date: Wed, 12 Apr 2017 17:19:28 +0100
Subject: [PATCH] Fix which_deb handling of non-Linux arches

When which_deb finds "*i386" or "*amd64" entries in the ARCHES list,
it will wrongly change them to "i386" to "amd64" respectively (which
is wrong in the case of kfreebsd-* or hurd-*).

Make the same changes here that were already made to identical code in
generate_di_list, to fix #758512 (commits
771f754516b161f248c132ee9d698e33a6330de0 and
2ef5d3288cdc772cdcbb7b5d11192305dd05b063).
---
 tools/which_deb | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/tools/which_deb b/tools/which_deb
index d5a5a94..e23c721 100755
--- a/tools/which_deb
+++ b/tools/which_deb
@@ -29,9 +29,9 @@ if (!defined ($output)) {
 # Give preference to i386 and amd64, if specified
 my @ARCHES;
 if ( $ENV{ARCHES} ) {
-push @ARCHES, 'i386' if $ENV{ARCHES} =~ /i386/;
-push @ARCHES, 'amd64' if $ENV{ARCHES} =~ /amd64/;
-push @ARCHES, grep { !/source|i386|amd64/ } split /\s+/, $ENV{ARCHES};
+push @ARCHES, 'i386' if $ENV{ARCHES} =~ /(^|\s)i386(\s|$)/;
+push @ARCHES, 'amd64' if $ENV{ARCHES} =~ /(^|\s)amd64(\s|$)/;
+push @ARCHES, grep { !/^(source|i386|amd64)$/ } split /\s+/, $ENV{ARCHES};
 }
 
 # We seem to be building a source-only CD. Check for whatever binary
-- 
1.8.4.rc3



signature.asc
Description: Digital signature

Re: debian-installer now available in Ports

Hello,

John Paul Adrian Glaubitz wrote:
> Thus, I was wondering whether any volunteers would be willing to help building
> ISO images for the various architectures.

I'm already doing this for kfreebsd-amd64, but only the jessie-kfreebsd
suite:
http://jenkins.kfreebsd.eu/jenkins/view/cd/job/debian-cd_jessie-kfreebsd/lastBuild/console
and I had to patch debian-cd before it worked.  (Didn't yet find time to
file bugs or submit those patches).

I could probably set up similar jobs for kfreebsd-* sid now.

> It's not necessary to run debian-cd on the same architecture as the
> target architecture of the ISO images.

I did not even realise that.  So I will add kfreebsd-i386 next.

I expect there might be problems trying to build linux arches from a
kfreebsd host.  But we should try to find out, and then maybe fix it.

Regards,
-- 
Steven Chamberlain
ste...@pyro.eu.org

signature.asc
Description: Digital signature

Re: GNU/KFreeBSD on Sun Microsystems X2200 M2 AMD 64bit

2017-03-19 Thread Steven Chamberlain

Hello,

(please make sure to use debian-bsd@lists.debian.org for
these kinds of questions/discussion)

pdb wrote:
> i would like to know if i can install GNU/KFreeBSD on my Sun Microsystems
> X2200 M2 AMD 64 bit Quad Core 2.3 Ghz

I would really like one of those myself!

It should be a good choice for running kfreebsd-amd64, but there are two
important things to check:

  * Ethernet chipset

Earlier Sun Fire (v20z) used a Broadcom chipset requiring non-free
microcode, that means the FreeBSD kernel supports it but the (free
software) Debian kernel does not.  I think the X2200 M2 has the same.

That would make it difficult to install kfreebsd.  A good solution is to
install an Intel PCIe dual/quad Gigabit NIC and use that instead of the
built-in Ethernet ports (this is not so expensive).

  * SATA/RAID chipset

This server sometimes comes with an LSI SAS/SATA RAID controller (PCIe
card), which should be okay (but you have to configure RAID via the
BIOS, you would not be able to reconfigure that within kfreebsd).

Otherwise, the server may only come with onboard NVIDIA SATA, and I
don't know how well that works with kfreebsd (probably okay).

Regards,
-- 
Steven Chamberlain
ste...@pyro.eu.org

signature.asc
Description: Digital signature

Re: kfreebsd-* buildd issues

2017-02-22 Thread Steven Chamberlain

Christoph Egger wrote:
> Steven Chamberlain <ste...@pyro.eu.org> writes:
> > Would this be possible again please :/  psmisc is still not fixed, and
> > there are still surprisingly many gcc-6 uploads.
> 
> And gcc-5. Done

And, again please :)

> > (Maybe even a daily cron for this would be a good idea...)
> 
> that cron would need to run as buildd user at the very least and
> reliably detect the situation .. maybe ;-) I'll gather information the
> next time this happens and see.

At the moment it happens almost daily!  (Had a lot of GCC uploads this
week).

Regards,
-- 
Steven Chamberlain
ste...@pyro.eu.org


signature.asc
Description: Digital signature

Re: kfreebsd-* buildd issues

2017-02-21 Thread Steven Chamberlain

Hi Christoph,

Steven Chamberlain wrote:
> please could somebody once again kill the hung gdb
> processes?

Would this be possible again please :/  psmisc is still not fixed, and
there are still surprisingly many gcc-6 uploads.

(Maybe even a daily cron for this would be a good idea...)

Thanks,
Regards,
-- 
Steven Chamberlain
ste...@pyro.eu.org

signature.asc
Description: Digital signature

Re: Bug#853751: unbound: FTBFS[!linux]: missing getentropy implementations

2017-02-16 Thread Steven Chamberlain

Hello,

Guillem pointed out to me that libunbound.pc actually should declare
Requires.private: libbsd
when libunbound.a was compiled against it.  That's for the benefit of
anyone static linking against libunbound (though I think in Debian no
packages are doing that at the moment).

My attached v5 patch is updated with this anyway.  I should see about
upstreaming this now.

Thanks,
Regards,
-- 
Steven Chamberlain
ste...@pyro.eu.org
Date: Thu, 16 Feb 2017 12:37:41 +
From: Steven Chamberlain <ste...@pyro.eu.org>
Subject: enable use of portable libbsd functions

Add a new configure option `--with-libbsd', which allows to use libbsd's
portable implementations of:
strlcpy strlcat arc4random arc4random_uniform reallocarray
instead of the embedded code copies in contrib/, which will be
difficult to maintain in the long term.

Also patch util/random.c so that, when building with libbsd and without
OpenSSL, arc4random can still be used as the PRNG.  Otherwise, building
with libnettle would need a kernel-specific getentropy implementation,
and libbsd does not export one.

diff --git a/configure.ac b/configure.ac
index d850539..9744388 100644
--- a/configure.ac
+++ b/configure.ac
@@ -707,6 +707,19 @@ AC_INCLUDES_DEFAULT
 fi
 AC_SUBST(SSLLIB)
 
+# libbsd
+AC_ARG_WITH([libbsd], AC_HELP_STRING([--with-libbsd], [Use portable libbsd functions]), [
+	AC_CHECK_HEADERS([bsd/string.h bsd/stdlib.h],,, [AC_INCLUDES_DEFAULT])
+	if test "x$ac_cv_header_bsd_string_h" = xyes -a "x$ac_cv_header_bsd_stdlib_h" = xyes; then
+		for func in strlcpy strlcat arc4random arc4random_uniform reallocarray; do
+			AC_SEARCH_LIBS([$func], [bsd], [
+AC_DEFINE(HAVE_LIBBSD, 1, [Use portable libbsd functions])
+PC_LIBBSD_DEPENDENCY=libbsd
+AC_SUBST(PC_LIBBSD_DEPENDENCY)
+			])
+		done
+	fi
+])
 
 AC_ARG_ENABLE(sha2, AC_HELP_STRING([--disable-sha2], [Disable SHA256 and SHA512 RRSIG support]))
 case "$enable_sha2" in
@@ -1469,6 +1482,11 @@ struct tm;
 char *strptime(const char *s, const char *format, struct tm *tm);
 #endif
 
+#ifdef HAVE_LIBBSD
+#include 
+#include 
+#endif
+
 #ifdef HAVE_LIBRESSL
 #  if !HAVE_DECL_STRLCPY
 size_t strlcpy(char *dst, const char *src, size_t siz);
diff --git a/contrib/libunbound.pc.in b/contrib/libunbound.pc.in
index 130bef5..ba191eb 100644
--- a/contrib/libunbound.pc.in
+++ b/contrib/libunbound.pc.in
@@ -8,6 +8,7 @@ Description: Library with validating, recursive, and caching DNS resolver
 URL: http://www.unbound.net
 Version: @PACKAGE_VERSION@
 Requires: libcrypto libssl @PC_LIBEVENT_DEPENDENCY@ @PC_PY_DEPENDENCY@
+Requires.private: @PC_LIBBSD_DEPENDENCY@
 Libs: -L${libdir} -lunbound
 Libs.private: @SSLLIB@ @LIBS@
 Cflags: -I${includedir} 
diff --git a/util/random.c b/util/random.c
index 8332960..b86c548 100644
--- a/util/random.c
+++ b/util/random.c
@@ -78,7 +78,7 @@
  */
 #define MAX_VALUE 0x7fff
 
-#if defined(HAVE_SSL)
+#if defined(HAVE_SSL) || defined(HAVE_LIBBSD)
 void
 ub_systemseed(unsigned int ATTR_UNUSED(seed))
 {
@@ -208,10 +208,10 @@ long int ub_random(struct ub_randstate* s)
 	}
 	return x & MAX_VALUE;
 }
-#endif /* HAVE_SSL or HAVE_NSS or HAVE_NETTLE */
+#endif /* HAVE_SSL or HAVE_LIBBSD or HAVE_NSS or HAVE_NETTLE */
 
 
-#if defined(HAVE_NSS) || defined(HAVE_NETTLE)
+#if defined(HAVE_NSS) || defined(HAVE_NETTLE) && !defined(HAVE_LIBBSD)
 long int
 ub_random_max(struct ub_randstate* state, long int x)
 {
@@ -223,7 +223,7 @@ ub_random_max(struct ub_randstate* state, long int x)
 		v = ub_random(state);
 	return (v % x);
 }
-#endif /* HAVE_NSS or HAVE_NETTLE */
+#endif /* HAVE_NSS or HAVE_NETTLE and !HAVE_LIBBSD */
 
 void 
 ub_randfree(struct ub_randstate* s)
diff --git a/debian/control b/debian/control
index f27c922..001428c 100644
--- a/debian/control
+++ b/debian/control
@@ -15,6 +15,7 @@ Build-Depends:
  dh-systemd ,
  dpkg-dev (>= 1.16.1~),
  flex,
+ libbsd-dev (>= 0.8.1~) [!linux-any],
  libevent-dev,
  libexpat1-dev,
  libfstrm-dev ,
diff --git a/debian/rules b/debian/rules
index f978494..3e5c216 100755
--- a/debian/rules
+++ b/debian/rules
@@ -7,6 +7,10 @@ ifneq ($(DEB_HOST_ARCH), amd64)
 CONFIGURE_ARGS = --disable-flto
 endif
 
+ifneq ($(DEB_HOST_ARCH_OS), linux)
+CONFIGURE_ARGS = --with-libbsd
+endif
+
 LIBRARY = libunbound2
 DOPACKAGES = $(shell dh_listpackages)
 


signature.asc
Description: Digital signature

Re: Bug#853751: unbound: FTBFS[!linux]: missing getentropy implementations

2017-02-16 Thread Steven Chamberlain

Hello again,

I've attached *another* revision of this patch.

Thanks to Guillem's comments in IRC, I realise reverse-depends need not
link against -lbsd because libunbound.so does so already.  So I must not
change libunbound.pc as I did.  -lbsd already gets added to Libs.private
when configuring --with-libbsd (which is only relevant for static
linking).

It also means, there's no need for a soname bump, transition, or
patching of reverse-depends if linux arches enabled --with-libbsd.

The debian part of the patch is unchanged since last time.

Regards,
-- 
Steven Chamberlain
ste...@pyro.eu.org
Date: Thu, 16 Feb 2017 10:28:12 +
From: Steven Chamberlain <ste...@pyro.eu.org>
Subject: enable use of portable libbsd functions

Add a new configure option `--with-libbsd', which allows to use libbsd's
portable implementations of:
strlcpy strlcat arc4random arc4random_uniform reallocarray
instead of the embedded code copies in contrib/, which will be
difficult to maintain in the long term.

Also patch util/random.c so that, when building with libbsd and without
OpenSSL, arc4random can still be used as the PRNG.  Otherwise, building
with libnettle would need a kernel-specific getentropy implementation,
and libbsd does not export one.

diff --git a/configure.ac b/configure.ac
index d850539..a21af87 100644
--- a/configure.ac
+++ b/configure.ac
@@ -707,6 +707,17 @@ AC_INCLUDES_DEFAULT
 fi
 AC_SUBST(SSLLIB)
 
+# libbsd
+AC_ARG_WITH([libbsd], AC_HELP_STRING([--with-libbsd], [Use portable libbsd functions]), [
+	AC_CHECK_HEADERS([bsd/string.h bsd/stdlib.h],,, [AC_INCLUDES_DEFAULT])
+	if test "x$ac_cv_header_bsd_string_h" = xyes -a "x$ac_cv_header_bsd_stdlib_h" = xyes; then
+		for func in strlcpy strlcat arc4random arc4random_uniform reallocarray; do
+			AC_SEARCH_LIBS([$func], [bsd], [
+AC_DEFINE(HAVE_LIBBSD, 1, [Use portable libbsd functions])
+			])
+		done
+	fi
+])
 
 AC_ARG_ENABLE(sha2, AC_HELP_STRING([--disable-sha2], [Disable SHA256 and SHA512 RRSIG support]))
 case "$enable_sha2" in
@@ -1469,6 +1480,11 @@ struct tm;
 char *strptime(const char *s, const char *format, struct tm *tm);
 #endif
 
+#ifdef HAVE_LIBBSD
+#include 
+#include 
+#endif
+
 #ifdef HAVE_LIBRESSL
 #  if !HAVE_DECL_STRLCPY
 size_t strlcpy(char *dst, const char *src, size_t siz);
diff --git a/util/random.c b/util/random.c
index 8332960..b86c548 100644
--- a/util/random.c
+++ b/util/random.c
@@ -78,7 +78,7 @@
  */
 #define MAX_VALUE 0x7fff
 
-#if defined(HAVE_SSL)
+#if defined(HAVE_SSL) || defined(HAVE_LIBBSD)
 void
 ub_systemseed(unsigned int ATTR_UNUSED(seed))
 {
@@ -208,10 +208,10 @@ long int ub_random(struct ub_randstate* s)
 	}
 	return x & MAX_VALUE;
 }
-#endif /* HAVE_SSL or HAVE_NSS or HAVE_NETTLE */
+#endif /* HAVE_SSL or HAVE_LIBBSD or HAVE_NSS or HAVE_NETTLE */
 
 
-#if defined(HAVE_NSS) || defined(HAVE_NETTLE)
+#if defined(HAVE_NSS) || defined(HAVE_NETTLE) && !defined(HAVE_LIBBSD)
 long int
 ub_random_max(struct ub_randstate* state, long int x)
 {
@@ -223,7 +223,7 @@ ub_random_max(struct ub_randstate* state, long int x)
 		v = ub_random(state);
 	return (v % x);
 }
-#endif /* HAVE_NSS or HAVE_NETTLE */
+#endif /* HAVE_NSS or HAVE_NETTLE and !HAVE_LIBBSD */
 
 void 
 ub_randfree(struct ub_randstate* s)
diff --git a/debian/control b/debian/control
index f27c922..001428c 100644
--- a/debian/control
+++ b/debian/control
@@ -15,6 +15,7 @@ Build-Depends:
  dh-systemd ,
  dpkg-dev (>= 1.16.1~),
  flex,
+ libbsd-dev (>= 0.8.1~) [!linux-any],
  libevent-dev,
  libexpat1-dev,
  libfstrm-dev ,
diff --git a/debian/rules b/debian/rules
index f978494..3e5c216 100755
--- a/debian/rules
+++ b/debian/rules
@@ -7,6 +7,10 @@ ifneq ($(DEB_HOST_ARCH), amd64)
 CONFIGURE_ARGS = --disable-flto
 endif
 
+ifneq ($(DEB_HOST_ARCH_OS), linux)
+CONFIGURE_ARGS = --with-libbsd
+endif
+
 LIBRARY = libunbound2
 DOPACKAGES = $(shell dh_listpackages)
 


signature.asc
Description: Digital signature

Re: Bug#853751: unbound: FTBFS[!linux]: missing getentropy implementations

2017-02-15 Thread Steven Chamberlain

Steven Chamberlain wrote:
> Attached is [...]

Oops.

-- 
Steven Chamberlain
ste...@pyro.eu.org
Date: Wed, 15 Feb 2017 12:44:13 +
From: Steven Chamberlain <ste...@pyro.eu.org>
Subject: enable use of portable libbsd functions

Add a new configure option `--with-libbsd', which allows to use libbsd's
portable implementations of:
strlcpy strlcat arc4random arc4random_uniform reallocarray
instead of the embedded code copies in contrib/, which will be
difficult to maintain in the long term.

Also patch util/random.c so that, when building with libbsd and without
OpenSSL, arc4random can still be used as the PRNG.  Otherwise, building
with libnettle would need a kernel-specific getentropy implementation,
and libbsd does not export one.

diff --git a/configure.ac b/configure.ac
index d850539..9744388 100644
--- a/configure.ac
+++ b/configure.ac
@@ -707,6 +707,19 @@ AC_INCLUDES_DEFAULT
 fi
 AC_SUBST(SSLLIB)
 
+# libbsd
+AC_ARG_WITH([libbsd], AC_HELP_STRING([--with-libbsd=path], [Use portable libbsd functions]), [
+	AC_CHECK_HEADERS([bsd/string.h bsd/stdlib.h],,, [AC_INCLUDES_DEFAULT])
+	if test "x$ac_cv_header_bsd_string_h" = xyes -a "x$ac_cv_header_bsd_stdlib_h" = xyes; then
+		for func in strlcpy strlcat arc4random arc4random_uniform reallocarray; do
+			AC_SEARCH_LIBS([$func], [bsd], [
+AC_DEFINE(HAVE_LIBBSD, 1, [Use portable libbsd functions])
+PC_LIBBSD_DEPENDENCY=libbsd
+AC_SUBST(PC_LIBBSD_DEPENDENCY)
+			])
+		done
+	fi
+])
 
 AC_ARG_ENABLE(sha2, AC_HELP_STRING([--disable-sha2], [Disable SHA256 and SHA512 RRSIG support]))
 case "$enable_sha2" in
@@ -1469,6 +1482,11 @@ struct tm;
 char *strptime(const char *s, const char *format, struct tm *tm);
 #endif
 
+#ifdef HAVE_LIBBSD
+#include 
+#include 
+#endif
+
 #ifdef HAVE_LIBRESSL
 #  if !HAVE_DECL_STRLCPY
 size_t strlcpy(char *dst, const char *src, size_t siz);
diff --git a/contrib/libunbound.pc.in b/contrib/libunbound.pc.in
index 130bef5..b6aec29 100644
--- a/contrib/libunbound.pc.in
+++ b/contrib/libunbound.pc.in
@@ -7,7 +7,7 @@ Name: unbound
 Description: Library with validating, recursive, and caching DNS resolver
 URL: http://www.unbound.net
 Version: @PACKAGE_VERSION@
-Requires: libcrypto libssl @PC_LIBEVENT_DEPENDENCY@ @PC_PY_DEPENDENCY@
+Requires: libcrypto libssl @PC_LIBEVENT_DEPENDENCY@ @PC_PY_DEPENDENCY@ @PC_LIBBSD_DEPENDENCY@
 Libs: -L${libdir} -lunbound
 Libs.private: @SSLLIB@ @LIBS@
 Cflags: -I${includedir} 
diff --git a/util/random.c b/util/random.c
index 8332960..b86c548 100644
--- a/util/random.c
+++ b/util/random.c
@@ -78,7 +78,7 @@
  */
 #define MAX_VALUE 0x7fff
 
-#if defined(HAVE_SSL)
+#if defined(HAVE_SSL) || defined(HAVE_LIBBSD)
 void
 ub_systemseed(unsigned int ATTR_UNUSED(seed))
 {
@@ -208,10 +208,10 @@ long int ub_random(struct ub_randstate* s)
 	}
 	return x & MAX_VALUE;
 }
-#endif /* HAVE_SSL or HAVE_NSS or HAVE_NETTLE */
+#endif /* HAVE_SSL or HAVE_LIBBSD or HAVE_NSS or HAVE_NETTLE */
 
 
-#if defined(HAVE_NSS) || defined(HAVE_NETTLE)
+#if defined(HAVE_NSS) || defined(HAVE_NETTLE) && !defined(HAVE_LIBBSD)
 long int
 ub_random_max(struct ub_randstate* state, long int x)
 {
@@ -223,7 +223,7 @@ ub_random_max(struct ub_randstate* state, long int x)
 		v = ub_random(state);
 	return (v % x);
 }
-#endif /* HAVE_NSS or HAVE_NETTLE */
+#endif /* HAVE_NSS or HAVE_NETTLE and !HAVE_LIBBSD */
 
 void 
 ub_randfree(struct ub_randstate* s)
diff --git a/debian/control b/debian/control
index f27c922..001428c 100644
--- a/debian/control
+++ b/debian/control
@@ -15,6 +15,7 @@ Build-Depends:
  dh-systemd ,
  dpkg-dev (>= 1.16.1~),
  flex,
+ libbsd-dev (>= 0.8.1~) [!linux-any],
  libevent-dev,
  libexpat1-dev,
  libfstrm-dev ,
diff --git a/debian/rules b/debian/rules
index f978494..3e5c216 100755
--- a/debian/rules
+++ b/debian/rules
@@ -7,6 +7,10 @@ ifneq ($(DEB_HOST_ARCH), amd64)
 CONFIGURE_ARGS = --disable-flto
 endif
 
+ifneq ($(DEB_HOST_ARCH_OS), linux)
+CONFIGURE_ARGS = --with-libbsd
+endif
+
 LIBRARY = libunbound2
 DOPACKAGES = $(shell dh_listpackages)
 


signature.asc
Description: Digital signature

Re: Bug#853751: unbound: FTBFS[!linux]: missing getentropy implementations

2017-02-15 Thread Steven Chamberlain

Control: tags -1 + patch

Hi again,

Attached is an updated patch, that I hope is more suitable for upstream.
It adds a configure option `--with-libbsd' allowing to use it if
desired (instead of using the overlay);  and it updates libunbound.pc if
necessary, to tell users of -lunbound to also use -lbsd.

Also attached is a patch for the unbound Debian packaging, which would
use that option on non-Linux architectures.  libunbound would then build
with portable implementations of getentropy, arc4random etc. from
libbsd, fixing the current FTBFS.  This shouldn't break any
reverse-depends because those already FTBFS on kfreebsd and hurd, and
those architectures are not in testing.

In future, if libbsd was enabled on linux architectures too, then there
perhaps should be a soname bump / transition where reverse-depends (e.g.
gnutls28) switch to using pkg-config, so that they themselves link with
-lbsd if necessary, and not simply -lunbound as most do currently.
Helmut Grohne suggested uploading to experimental in that case, and then
I could file patches for all the reverse-depends.

Thanks for considering,
Regards,
-- 
Steven Chamberlain
ste...@pyro.eu.org


signature.asc
Description: Digital signature

Re: Bug#853751: unbound: FTBFS[!linux]: missing getentropy implementations

2017-02-14 Thread Steven Chamberlain

Control: tags -1 - patch

Hi,

This change, if it was made on all architectures, could cause a
regression for reverse-depends of libunbound-dev, since they would also
need to link with -lbsd and not just -lunbound.

For kfreebsd and hurd, that doesn't matter yet, because the
reverse-depends all FTBFS or are BD-Uninstallable waiting on
unbound >= 1.5.10 (gnutls28 for example).

But eventually, we should try to fix all reverse-depends to get the
correct linker flags with pkg-config, instead of assuming "-lunbound" to
be sufficient.

And so firstly, I must rewrite my patch to add -lbsd to the Libs.private
field of libunbound.pc, whenever it is necessary.

Regards,
-- 
Steven Chamberlain
ste...@pyro.eu.org


signature.asc
Description: Digital signature

Bug#855072: freebsd-buildutils: fmtree doesn't support documented -K sha256digest

2017-02-13 Thread Steven Chamberlain

Control: tags -1 + pending

Hello!

John Goerzen wrote:
> The fmtree manpage describes sha256digest, sha1digest, and md5digest.
> 
> None of these are actually supported by -K:

When this was packaged in 2005, we did not have libmd.  Since recently,
we have this now in sid/stretch, so I shall enable this feature :)

Regards,
-- 
Steven Chamberlain
ste...@pyro.eu.org

signature.asc
Description: Digital signature

Bug#855027: guile-2.0: FTBFS[kfreebsd-amd64]: 00-repl-server.test "Resource temporarily unavailable"

2017-02-13 Thread Steven Chamberlain

Package: src:guile-2.0
Version: 2.0.13+1-2
Severity: important
User: debian-bsd@lists.debian.org
Usertags: kfreebsd

Hello,

guile-2.0 FTBFS on kfreebsd-amd64, since the addition of
0003-tests-Avoid-race-condition-in-REPL-server-test.patch in 2.0.13+1-4

https://buildd.debian.org/status/fetch.php?pkg=guile-2.0=kfreebsd-amd64=2.0.13%2B1-4=1481333083=0
| FAIL: 00-repl-server.test: repl-server: simple expression - arguments:
| (expected-value "scheme@(repl-server)> $1 = 42\n" actual-value:
| scheme@(repl-server)> While reading expression:
| ERROR: In procedure fport_fill_input: Resource temporarily unavailable
| scheme@(repl-server)> While reading expression:
| ERROR: In procedure fport_fill_input: Resource temporarily unavailable
| scheme@(repl-server)> While reading expression:
| ERROR: In procedure fport_fill_input: Resource temporarily unavailable

I think the newly-added call to select() is returning EAGAIN:

+
+  ;; Wait until 'repl-reader' in boot-9 has written the prompt.
+  ;; Otherwise, if we write too quickly, 'repl-reader' checks for
+  ;; 'char-ready?' and doesn't print the prompt.
+  (match (select (list socket) '() (list socket) 3)
+(((_) () ())
+ (display "(+ 40 2)\n(quit)\n" socket)
+ (read-string socket)

But I think that is quite normal, at least on kfreebsd.  In
http://man7.org/linux/man-pages/man2/select.2.html it is stated that
"Portable programs may wish to check for EAGAIN and loop, just as with
EINTR."

I'm unfortunately not a Guile programmer so I wouldn't know how to do
that here.

I chose severity 'important' because, although kfreebsd is not a release
architecture, src:guile-2.0 is a build-dependency of some of the
build-essential packages in sid.

Thanks!

-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: kfreebsd-amd64 (x86_64)

Kernel: kFreeBSD 10.1-0-amd64
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Re: Bug#852215: FTBFS on non-release architectures

2017-02-08 Thread Steven Chamberlain

Cyril Brulebois wrote:
> [...] kfreebsd-* (which currently FTBFS anyway…).

Regarding that, is it okay I commit to sid this specific change for
kfreebsd-amd64:

--- a/build/Makefile
+++ b/build/Makefile
@@ -149,7 +149,7 @@ ifeq ($(DEB_HOST_ARCH),kfreebsd-i386)
 MFSROOT_LIMIT := 42m
 else ifeq ($(DEB_HOST_ARCH),kfreebsd-amd64)
 # See Bug#783773 for derivation.
-MFSROOT_LIMIT := 74m
+MFSROOT_LIMIT := 78m
 endif
 
 define mkfs.ufs1

Thanks,
Regards,
-- 
Steven Chamberlain
ste...@pyro.eu.org


signature.asc
Description: Digital signature

Re: kfreebsd-* buildd issues

2017-02-08 Thread Steven Chamberlain

> >> Steven Chamberlain <ste...@pyro.eu.org> writes:
> >> > Please could someone check the gcc-7 build on fayrfax, to see of it is
> >> > stuck again with hung gdb processes?
[...]
> > Please could you do the same again... some/all of the buildds are stuck
> > building gcc-snapshot.

Christoph Egger wrote:
> Only fayrfax and fils it seems (or someone killed the others already)

I think someone else already took care of it that time.

But now we had new uploads of gcc-6 and gcc-snapshot... psmisc is not
yet fixed in sid... please could somebody once again kill the hung gdb
processes?

Many thanks,
Regards,
-- 
Steven Chamberlain
ste...@pyro.eu.org


signature.asc
Description: Digital signature

Re: kfreebsd-* buildd issues

2017-02-04 Thread Steven Chamberlain

Hello,

Christoph Egger wrote:
> Steven Chamberlain <ste...@pyro.eu.org> writes:
> > Please could someone check the gcc-7 build on fayrfax, to see of it is
> > stuck again with hung gdb processes?
> 
> It is, will kill it in a minute just need to remember my sudo password
> 
> > Also, I can't see that buildd fano has built much recently either.
> 
> Building gcc 6.3 and stuck there

Please could you do the same again... some/all of the buildds are stuck
building gcc-snapshot.

Hopefully soon there may be a procps upload fixing this.

Regards,
-- 
Steven Chamberlain
ste...@pyro.eu.org


signature.asc
Description: Digital signature

Bug#854074: gcc-6: please enable PIE hardening flags by default on kfreebsd-*

2017-02-03 Thread Steven Chamberlain

Hi,

Matthias Klose wrote:
> [CCing porters, please also leave feedback in #835148 for non-release 
> architectures]

Since that bug is done/closed/actioned, I've cloned a new one for this
request.

> On 29.09.2016 21:39, Niels Thykier wrote:
> > As agreed on during the [meeting], if there are no major concerns to
> > this proposal in general within a week, I shall file a bug against GCC
> > requesting PIE by default on all release architectures (with backing
> > porters).

I think we are ready for this now;  please enable PIE by default on
kfreebsd-* when it is practical (or rather, allow dpkg-buildflags to
enable it).

Thanks,
Regards,
-- 
Steven Chamberlain
ste...@pyro.eu.org

signature.asc
Description: Digital signature

Re: Bug#853751: unbound: FTBFS[!linux]: missing getentropy implementations

2017-02-03 Thread Steven Chamberlain

Hi,

Here's un updated patch including the missing part, and now using a
proper invocation of pkg-config suitable for cross-builds, as pointed
out to me by helmutg@

Regards,
-- 
Steven Chamberlain
ste...@pyro.eu.org
--- a/debian/control  
+++ b/debian/control  
@@ -15,6 +15,7 @@ Build-Depends:  
  dh-systemd ,  
  dpkg-dev (>= 1.16.1~),  
  flex,   
+ libbsd-dev (>= 0.8.1~) [!linux-any],
  libevent-dev,   
  libexpat1-dev,  
  libfstrm-dev ,
--- a/debian/rules
+++ b/debian/rules
@@ -14,6 +14,12 @@ export DEB_BUILD_MAINT_OPTIONS = hardening=+all
 DPKG_EXPORT_BUILDFLAGS = 1
 include /usr/share/dpkg/buildflags.mk
 
+ifneq ($(DEB_HOST_ARCH_OS), linux)
+# libbsd can provide strlcpy, strlcat, arc4random*, reallocarray
+CFLAGS += $(shell $(DEB_HOST_GNU_TYPE)-pkg-config --cflags libbsd-overlay)
+LDFLAGS += $(shell $(DEB_HOST_GNU_TYPE)-pkg-config --libs libbsd-overlay)
+endif
+
 clean:
 	dh_autotools-dev_restoreconfig
 	dh_autoreconf_clean
@@ -31,7 +37,7 @@ binary-arch: build
 ifneq (,$(filter unbound unbound-anchor unbound-host,$(DOPACKAGES)))
 	# first build -- build unbound daemon
 	PYTHON_VERSION="$(shell py3versions -vd)" \
-	CFLAGS="$(CFLAGS)" CPPFLAGS="$(CPPFLAGS)" LDFLAGS="-Wl,--as-needed $(LDFLAGS)" \
+	CFLAGS="$(CFLAGS)" CPPFLAGS="$(CPPFLAGS)" LDFLAGS="$(LDFLAGS) -Wl,--as-needed" \
 		dh_auto_configure -- \
 		--disable-rpath \
 		--with-pidfile=/run/unbound.pid \
@@ -48,7 +54,7 @@ ifneq (,$(filter unbound unbound-anchor unbound-host,$(DOPACKAGES)))
 endif
 
 	# second build -- build libunbound only, against nettle
-	CFLAGS="$(CFLAGS)" CPPFLAGS="$(CPPFLAGS)" LDFLAGS="-Wl,--as-needed $(LDFLAGS)" \
+	CFLAGS="$(CFLAGS)" CPPFLAGS="$(CPPFLAGS)" LDFLAGS="$(LDFLAGS) -Wl,--as-needed" \
 		dh_auto_configure -- \
 		--disable-rpath \
 		--with-libunbound-only \
@@ -67,7 +73,7 @@ endif
 ifneq (,$(filter python-unbound,$(DOPACKAGES)))
 	# third build - pyunbound for Python 2
 	PYTHON_VERSION="$(shell pyversions -vd)" \
-	CFLAGS="$(CFLAGS)" CPPFLAGS="$(CPPFLAGS)" LDFLAGS="-Wl,--as-needed $(LDFLAGS)" \
+	CFLAGS="$(CFLAGS)" CPPFLAGS="$(CPPFLAGS)" LDFLAGS="$(LDFLAGS) -Wl,--as-needed" \
 		dh_auto_configure -- \
 		--disable-rpath \
 		--with-pythonmodule \
@@ -86,7 +92,7 @@ endif
 ifneq (,$(filter python3-unbound,$(DOPACKAGES)))
 	# fourth build - pyunbound for Python 3
 	PYTHON_VERSION="$(shell py3versions -vd)" \
-	CFLAGS="$(CFLAGS)" CPPFLAGS="$(CPPFLAGS)" LDFLAGS="-Wl,--as-needed $(LDFLAGS)" \
+	CFLAGS="$(CFLAGS)" CPPFLAGS="$(CPPFLAGS)" LDFLAGS="$(LDFLAGS) -Wl,--as-needed" \
 		dh_auto_configure -- \
 		--disable-rpath \
 		--with-pythonmodule \
diff --git a/configure.ac b/configure.ac
index d850539..f83f003 100644
--- a/configure.ac
+++ b/configure.ac
@@ -674,6 +674,14 @@ if grep VERSION_TEXT $ssldir/include/openssl/opensslv.h | grep "LibreSSL" >/dev/
 	AC_CHECK_DECLS([strlcpy,strlcat,arc4random,arc4random_uniform,reallocarray])
 else
 	AC_MSG_RESULT([no])
+
+	# Otherwise see if libbsd can provide these functions
+	AC_CHECK_DECLS([strlcpy,strlcat], [], [], [
+#include 
+])
+	AC_CHECK_DECLS([arc4random,arc4random_uniform,reallocarray], [], [], [
+#include 
+])
 fi
 AC_CHECK_HEADERS([openssl/conf.h openssl/engine.h openssl/bn.h openssl/dh.h openssl/dsa.h openssl/rsa.h],,, [AC_INCLUDES_DEFAULT])
 AC_CHECK_FUNCS([OPENSSL_config EVP_sha1 EVP_sha256 EVP_sha512 FIPS_mode EVP_MD_CTX_new OpenSSL_add_all_digests OPENSSL_init_crypto EVP_cleanup ERR_load_crypto_strings CRYPTO_cleanup_all_ex_data ERR_free_strings RAND_cleanup DSA_SIG_set0 EVP_dss1])


signature.asc
Description: Digital signature

Re: [Pkg-dns-devel] Bug#853751: unbound: FTBFS[!linux]: missing getentropy implementations

2017-02-01 Thread Steven Chamberlain

Hello,

Robert Edmonds wrote:
> Thanks for this patch. Is this needed before stretch releases? (IIUC,
> kfreebsd and hurd are not release architectures?)

Indeed, this isn't relevant to stretch, this is not urgent.

> I agree with this reasoning, but I'd rather have the libbsd support in
> an upstream Unbound release rather than in the Debian package. I'll see
> about producing a patch suitable for upstream.

Yes, the configure.ac part is something we should propose to upstream:
libbsd exists in other distros and, samba uses it for example.

Thanks!
Regards,
-- 
Steven Chamberlain
ste...@pyro.eu.org


signature.asc
Description: Digital signature

Re: Bug#853751: unbound: FTBFS[!linux]: missing getentropy implementations

2017-01-31 Thread Steven Chamberlain

Hi,

I forgot an important piece of the patch which is actually adding the
build-dependency:

--- a/debian/control
+++ b/debian/control
@@ -15,6 +15,7 @@ Build-Depends:
  dh-systemd ,
  dpkg-dev (>= 1.16.1~),
  flex,
+ libbsd-dev (>= 0.8.1~) [!linux-any],
  libevent-dev,
  libexpat1-dev,
  libfstrm-dev ,

0.8.1 was the first version to implement a modern arc4random (using
ChaCha20 cipher) and implement genentropy on kfreebsd and hurd.

Regards,
-- 
Steven Chamberlain
ste...@pyro.eu.org


signature.asc
Description: Digital signature

Re: Bug#853751: unbound: FTBFS[!linux]: missing getentropy implementations

2017-01-31 Thread Steven Chamberlain

tags 853751 + patch
user helm...@debian.org
usertags 853751 + rebootstrap
thanks

Hi,

This bug has become important, since src:unbound became part of the
build-essential closure (due to Build-Depends of gnutls28).  So this is
now a blocking issue for rebootstrapping kfreebsd and hurd.

Andreas Beckmann wrote:
> unbound FTBFS on hurd-i386 and kfreebsd-* due to usage of linux specific
> headers linux/types.h and sys/mount.h:

This is still the case in sid:
https://buildd.debian.org/status/fetch.php?pkg=unbound=hurd-i386=1.6.0-2=1482097724=0
https://buildd.debian.org/status/fetch.php?pkg=unbound=kfreebsd-amd64=1.6.0-2=1482453042=0
https://buildd.debian.org/status/fetch.php?pkg=unbound=kfreebsd-i386=1.6.0-2=1482578818=0

| compat/getentropy_linux.c:56:25: fatal error: linux/types.h: No such file or 
directory

The reason is, unbound requires an arc4random(3) implementation.  For
platforms not having that in their libc, it bundles its own embedded
code copy (in compat/) but that only supports Linux, OS/X and Solaris.

We have in Debian a good arc4random(3) implementation provided by
libbsd, which is already ported to all architectures.  Please use it on
kfreebsd and hurd, at least.  I've attached a patch to do exactly that,
and fixes the current FTBFS there.

(It was necessary that the LDFLAGS of libbsd-overlay.pc come *before*
-Wl,--as-needed, or else the AC_REPLACE_FUNCS configure checks fail --
I'm not sure what is the reason for that?)

You could perhaps use libbsd unconditionally - on linux arches too - and
then the copy in compat/ would no longer be used.

There is a long history of software embedding copies of arc4random, and
then forgetting to maintain them.  There is a longer discussion of that
here:  https://wiki.debian.org/arc4random

I hold the opinion that packages should use the libbsd implementation
whereever possible, and then in Debian we would only need to maintain it
in one place, to the benefit of all reverse-deps.

Many thanks,
Regards,
-- 
Steven Chamberlain
ste...@pyro.eu.org
diff --git a/configure.ac b/configure.ac
index d850539..f83f003 100644
--- a/configure.ac
+++ b/configure.ac
@@ -674,6 +674,14 @@ if grep VERSION_TEXT $ssldir/include/openssl/opensslv.h | grep "LibreSSL" >/dev/
 	AC_CHECK_DECLS([strlcpy,strlcat,arc4random,arc4random_uniform,reallocarray])
 else
 	AC_MSG_RESULT([no])
+
+	# Otherwise see if libbsd can provide these functions
+	AC_CHECK_DECLS([strlcpy,strlcat], [], [], [
+#include 
+])
+	AC_CHECK_DECLS([arc4random,arc4random_uniform,reallocarray], [], [], [
+#include 
+])
 fi
 AC_CHECK_HEADERS([openssl/conf.h openssl/engine.h openssl/bn.h openssl/dh.h openssl/dsa.h openssl/rsa.h],,, [AC_INCLUDES_DEFAULT])
 AC_CHECK_FUNCS([OPENSSL_config EVP_sha1 EVP_sha256 EVP_sha512 FIPS_mode EVP_MD_CTX_new OpenSSL_add_all_digests OPENSSL_init_crypto EVP_cleanup ERR_load_crypto_strings CRYPTO_cleanup_all_ex_data ERR_free_strings RAND_cleanup DSA_SIG_set0 EVP_dss1])
diff --git a/debian/rules b/debian/rules
index f978494..ede0d90 100755
--- a/debian/rules
+++ b/debian/rules
@@ -14,6 +14,12 @@ export DEB_BUILD_MAINT_OPTIONS = hardening=+all
 DPKG_EXPORT_BUILDFLAGS = 1
 include /usr/share/dpkg/buildflags.mk
 
+ifneq ($(DEB_HOST_ARCH_OS), linux)
+# libbsd can provide strlcpy, strlcat, arc4random*, reallocarray
+CFLAGS += $(shell pkg-config --cflags libbsd-overlay)
+LDFLAGS += $(shell pkg-config --libs libbsd-overlay)
+endif
+
 clean:
 	dh_autotools-dev_restoreconfig
 	dh_autoreconf_clean
@@ -31,7 +37,7 @@ binary-arch: build
 ifneq (,$(filter unbound unbound-anchor unbound-host,$(DOPACKAGES)))
 	# first build -- build unbound daemon
 	PYTHON_VERSION="$(shell py3versions -vd)" \
-	CFLAGS="$(CFLAGS)" CPPFLAGS="$(CPPFLAGS)" LDFLAGS="-Wl,--as-needed $(LDFLAGS)" \
+	CFLAGS="$(CFLAGS)" CPPFLAGS="$(CPPFLAGS)" LDFLAGS="$(LDFLAGS) -Wl,--as-needed" \
 		dh_auto_configure -- \
 		--disable-rpath \
 		--with-pidfile=/run/unbound.pid \
@@ -48,7 +54,7 @@ ifneq (,$(filter unbound unbound-anchor unbound-host,$(DOPACKAGES)))
 endif
 
 	# second build -- build libunbound only, against nettle
-	CFLAGS="$(CFLAGS)" CPPFLAGS="$(CPPFLAGS)" LDFLAGS="-Wl,--as-needed $(LDFLAGS)" \
+	CFLAGS="$(CFLAGS)" CPPFLAGS="$(CPPFLAGS)" LDFLAGS="$(LDFLAGS) -Wl,--as-needed" \
 		dh_auto_configure -- \
 		--disable-rpath \
 		--with-libunbound-only \
@@ -67,7 +73,7 @@ endif
 ifneq (,$(filter python-unbound,$(DOPACKAGES)))
 	# third build - pyunbound for Python 2
 	PYTHON_VERSION="$(shell pyversions -vd)" \
-	CFLAGS="$(CFLAGS)" CPPFLAGS="$(CPPFLAGS)" LDFLAGS="-Wl,--as-needed $(LDFLAGS)" \
+	CFLAGS="$(CFLAGS)" CPPFLAGS="$(CPPFLAGS)" LDFLAGS="$(LDFLAGS) -Wl,--as-needed" \
 		dh_auto_configure -- \
 		--disable-rpath \
 		--with-pythonmodule \
@@ -86,7 +92,7 @@ endif
 ifneq (,$(filter python3-unbound,$(DOPACKA

Re: kfreebsd-* buildd issues

2017-01-26 Thread Steven Chamberlain

Hello,

Please could someone check the gcc-7 build on fayrfax, to see of it is
stuck again with hung gdb processes?

Also, I can't see that buildd fano has built much recently either.

Many thanks,
Regards,
-- 
Steven Chamberlain
ste...@pyro.eu.org


signature.asc
Description: Digital signature

Bug#852507: mame: FTBFS[kfreebsd]: wrong path for dirent.h

2017-01-24 Thread Steven Chamberlain

Source: mame
Version: 0.181-1
Tags: upstream patch
X-Debbugs-Cc: debian-bsd@lists.debian.org
User: debian-bsd@lists.debian.org
Usertags: kfreebsd

Hi!

mame/0.181-1 FTBFS on kfreebsd-* because:

| Compiling 3rdparty/bgfx/3rdparty/ocornut-imgui/imgui.cpp...
| In file included from 
../../../../../3rdparty/bgfx/3rdparty/ocornut-imgui/widgets/file_list.inl:2:0,
|  from 
../../../../../3rdparty/bgfx/3rdparty/ocornut-imgui/imgui_user.inl:75,
|  from 
../../../../../3rdparty/bgfx/3rdparty/ocornut-imgui/imgui.cpp:9799:
| ../../../../../3rdparty/bx/include/compat/freebsd/dirent.h:1:24: fatal error: 
sys/dirent.h: No such file or directory

Attached is a simple patch for this.  It is similar to two other fixes
already applied upstream.  I'll take responsibility for upstreaming this
(in "bx" and then in mame).

My patch fixes only the issue described above.  I don't know yet if this
is the *only* reason for FTBFS because I'm still building it on falla.

Thanks!
Regards,
-- 
Steven Chamberlain
ste...@pyro.eu.org
diff --git a/3rdparty/bx/include/compat/freebsd/dirent.h b/3rdparty/bx/include/compat/freebsd/dirent.h
index b4f586b..5f52d2d 100644
--- a/3rdparty/bx/include/compat/freebsd/dirent.h
+++ b/3rdparty/bx/include/compat/freebsd/dirent.h
@@ -1 +1,5 @@
-#include 
+#if defined(__GLIBC__)
+#   include_next 
+#else
+#   include 
+#endif


signature.asc
Description: Digital signature

Re: Bug#851053: openjdk-8-jre-headless: Can't run a command with Runtime.exec() on kfreebsd-* - errcode 127

2017-01-13 Thread Steven Chamberlain

Hello,

Gilles Filippini wrote:
> While investigating about ant FTBFS on kfreebsd-* [1][2], I tried the
> very simple testcase below. It fails with errcode 127 on kfreebsd-*:

Many thanks for the report and test case.  With that I could easily find
the underlying issue:

 31280 java CALL  vfork
 31280 java RET   vfork 31281/0x7a31
 31281 java RET   fork 0
 31281 java CALL  execve(0x8041e6970,0x8026b34c0,0x7fffe610)
 31281 java NAMI
"/usr/lib/jvm/java-8-openjdk-kfreebsd-amd64/jre/lib/jspawnhelper"
 31281 java RET   execve -1 errno 2 No such file or directory
 31281 java CALL  exit(0x7f)

AFAIK only kfreebsd uses jspawnhelper, but ISTR it was the most suitable
implementation of exec() for us to use at the moment.

The file is actually located at
/usr/lib/jvm/java-8-openjdk-kfreebsd-amd64/jre/lib/amd64/jspawnhelper

Perhaps I need to update something in the kfreebsd jdk patchset;
although it maybe makes more sense to install that file to
/usr/lib/jvm/java-8-openjdk-kfreebsd-amd64/jre/lib/jspawnhelper
since the pathname is already multiarched.

Regards,
-- 
Steven Chamberlain
ste...@pyro.eu.org

signature.asc
Description: Digital signature

Re: Bug#850841: gcc-6: [kfreebsd] guality tests hang on kfreebsd

Maybe it's an error on FreeBSD to try to ptrace your own parent process.
From https://www.freebsd.org/cgi/man.cgi?query=ptrace:

| For the duration of the tracing session, the traced process will be
| ``re-parented'', with its parent process ID (and resulting behavior)
| changed to the tracing process.

gdb seems fine attaching to other pids than its parent process.
But this simple testcase of attaching to the parent process, shows the
same issue as the guality tests:

$ cat attach-self.sh 
#!/bin/sh -e
echo "attach $$" | gdb -nx -nw

| GNU gdb (Debian 7.12-4) 7.12
| Copyright (C) 2016 Free Software Foundation, Inc.
| License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
| This is free software: you are free to change and redistribute it.
| There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
| and "show warranty" for details.
| This GDB was configured as "x86_64-kfreebsd-gnu".
| Type "show configuration" for configuration details.
| For bug reporting instructions, please see:
| <http://www.gnu.org/software/gdb/bugs/>.
| Find the GDB manual and other documentation resources online at:
| <http://www.gnu.org/software/gdb/documentation/>.
| For help, type "help".
| Type "apropos word" to search for commands related to "word".
| (gdb) Attaching to process 95320
| Couldn't get registers: Device or resource busy.
| Couldn't get registers: Device or resource busy.
| (gdb) quit
| A debugging session is active.
| 
| Inferior 1 [process 95320] will be detached.
| 
| Quit anyway? (y or n) [answered Y; input not from terminal]
| Detaching from program: , process 95320
| ptrace: Device or resource busy.

Regards,
-- 
Steven Chamberlain
ste...@pyro.eu.org


signature.asc
Description: Digital signature

Bug#850841: gcc-6: [kfreebsd] guality tests hang on kfreebsd

/home/stevenc/gcc-6-6.3.0/src/gcc/testsuite/gcc.dg/guality/guality.h:335
| 335 while (--timeout && !guality_attached)

For reference, the instructions that were sent to gdb are:

| |  85526 guality_check15612. GIO   fd 4 wrote 172 bytes
| |"set height 0
| | handle SIGINT pass nostop
| | handle SIGTERM pass nostop
| | handle SIGSEGV pass nostop
| | handle SIGBUS pass nostop
| | attach 85526
| | set guality_attached = 1
| | b 351
| | continue
| |"
| | 
| |  85526 guality_check15612. GIO   fd 4 wrote 282 bytes
| |"up
| | set $value1 = 0
| | set $value1 = (varl)
| | set $value2 = -1
| | set $value2 = (varl)
| | set $value3 = $value1 - 1
| | set $value4 = $value1 + 1
| | set $value3 = (varl)++
| | set $value4 = --(varl)
| | down
| | set xvalue = $value1
| | set unavailable = $value1 != $value2 ? -1 : $value3 != $value4 ? 1 
: 0
| | continue
| |"

pid 85526 is seen telling gdb to attach to pid 85526.  That seems odd,
but I think that really is intended.

Thanks,
Regards,
-- 
Steven Chamberlain
ste...@pyro.eu.org


signature.asc
Description: Digital signature

Re: gcc 7, 6 builds killed on kfreebsd

Steven Chamberlain wrote:
> Christoph Egger wrote:
> > | WARNING: 30 signals -- adjust and recompile.
> 
> That comes from pkill, which recently stopped working.  This means, the
> build already hung / timed out and sbuild is merely failing to kill it.

The warning messages from libprocps are seemingly benign, but in this
case I think they stopped sbuild from timing out the build (because
there was still 'activity' on stderr).  I still don't know where those
messages came from (I couldn't find any pgrep/pkill invocation for
example).

Some testcases such as guality_check15612.exe seem to hang.  That may be
a regression, or it may be that something was previously killing it
after some timeout, and now is not.

Regards,
-- 
Steven Chamberlain
ste...@pyro.eu.org

signature.asc
Description: Digital signature

Re: Bug#850717: procps: [kfreebsd] pkill fails, number_of_signals changed

Hi,

I was wrong that this bug breaks functionality of pkill.  It still
works, despite printing the warning.

So this bug is mostly cosmetic, however, it does have an incidental
side-effect on the gcc-6 builds, where the message printed on stderr
causes sbuild to never time out the build...

Regards,
-- 
Steven Chamberlain
ste...@pyro.eu.org


signature.asc
Description: Digital signature

Re: gcc 7, 6 builds killed on kfreebsd

2017-01-09 Thread Steven Chamberlain

Christoph Egger wrote:
> | WARNING: 30 signals -- adjust and recompile.

That comes from pkill, which recently stopped working.  This means, the
build already hung / timed out and sbuild is merely failing to kill it.

For that I've just filed Bug#850717 against
procps: [kfreebsd] pkill fails, number_of_signals changed

I still need to find out why the gcc-6/-snapshot builds hang.

Regards,
-- 
Steven Chamberlain
ste...@pyro.eu.org


signature.asc
Description: Digital signature

Bug#850717: procps: [kfreebsd] pkill fails, number_of_signals changed

2017-01-09 Thread Steven Chamberlain

Package: procps
Version: 2:3.3.12-3
Severity: important
Tags: upstream patch
X-Debbugs-Cc: debian-bsd@lists.debian.org
User: debian-bsd@lists.debian.org
Usertags: kfreebsd

Hello,

Jon's patch[0] unfortunately causes number_of_signals to differ
between Linux and other kernels not having SIGPWR.  pkill from the
Debian procps/2:3.3.12-3 package has this issue on kfreebsd arches:

$ pkill -2 foobar
WARNING: 30 signals -- adjust and recompile.

In proc/sig.c:

289 /* sanity check */
290 static int init_signal_list(void) __attribute__((constructor));
291 static int init_signal_list(void){
292   if(number_of_signals != 31){
293 fprintf(stderr, "WARNING: %d signals -- adjust and recompile.\n", 
number_of_signals);
294   }
295   return 0;
296 }

it may be counter-productive to maintain an expected number_of_signals
for each platform.  May I suggest to only do the sanity check on Linux?
(patch attached, tested on kfreebsd-amd64)

[0]: 
https://gitlab.com/procps-ng/procps/commit/8abd0c92ab7576280b2a601c12ff749ab41c117f

Many thanks,
Regards,
-- 
Steven Chamberlain
ste...@pyro.eu.org
From 7741344069d31d5e7f4206534ed1989ed1180e49 Mon Sep 17 00:00:00 2001
From: Steven Chamberlain <ste...@pyro.eu.org>
Date: Mon, 9 Jan 2017 15:46:36 +
Subject: [PATCH] library: only check number_of_signals on Linux

number_of_signals is expected to differ across platforms.  Rather than
try to define the expected values on each architecture, only perform the
sanity check on Linux builds.
---
 proc/sig.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/proc/sig.c b/proc/sig.c
index 461db1d..0a4 100644
--- a/proc/sig.c
+++ b/proc/sig.c
@@ -287,8 +287,10 @@ void unix_print_signals(void){
 /* sanity check */
 static int init_signal_list(void) __attribute__((constructor));
 static int init_signal_list(void){
+#ifdef __linux__
   if(number_of_signals != 31){
 fprintf(stderr, "WARNING: %d signals -- adjust and recompile.\n", number_of_signals);
   }
+#endif
   return 0;
 }
-- 
2.5.1



signature.asc
Description: Digital signature

Re: gcc 7, 6 builds killed on kfreebsd

2017-01-09 Thread Steven Chamberlain

Hi!

Christoph Egger wrote:
> I've just killed the gcc builds on kfreebsd. THey're all looping with a
> 
> | WARNING: 30 signals -- adjust and recompile.

Thanks;  it seems to have happened again though on kfreebsd-amd64 (stuck
building gcc-6 and gcc-snapshot for 5+ days).

I will look into this problem ASAP but maybe those builds can be marked as
'Failed' so that other packages build in the meantime?

Regards,
-- 
Steven Chamberlain
ste...@pyro.eu.org

signature.asc
Description: Digital signature

Re: bwn0 interface

2016-12-31 Thread Steven Chamberlain

Herbert Fortes wrote:
> Hi Steven Chamberlain,
> > You may need this non-free package installed for the microcode:
> > https://packages.debian.org/jessie/firmware-brcm80211
> 
> The package does not list 4312.

Ah okay.  Perhaps we do not have a package with this microcode.
You may need to use a non-free kfreebsd (kernel) package including the
sourceless parts.

Which kernel version are you using? (`uname -r`)

Regards,
-- 
Steven Chamberlain
ste...@pyro.eu.org

signature.asc
Description: Digital signature

Re: bwn0 interface

2016-12-30 Thread Steven Chamberlain

Hello,

Herbert Fortes wrote:
> bwn_v4_lp_ucode15: could not load firmware image, error 2
> 
> bwn0: the fw file(bw_v4_lp_ucode15) not found

You may need this non-free package installed for the microcode:
https://packages.debian.org/jessie/firmware-brcm80211

Then to test it, try something like:

# modprobe if_bwn
# ifconfig wlan0 create wlandev bwn0 mode 11g
# ifconfig wlan0 up scan

Regards,
-- 
Steven Chamberlain
ste...@pyro.eu.org


signature.asc
Description: Digital signature

kfreebsd-* buildd issues

2016-12-04 Thread Steven Chamberlain

Hi!

Did we lose the kfreebsd-* buildds?

The queues are huge, and the current wanna-build state has this:

Building2   1: arb (77d 22h 13m, non-free, fano), notmuch (3d 1h 
37m, fayrfax)
Building1   1: notmuch (3d 6h 42m, fils)

Thanks,
Regards,
-- 
Steven Chamberlain
ste...@pyro.eu.org


signature.asc
Description: Digital signature

Re: Bug#846635: openmpi: broken on kfreebsd since 2.x

2016-12-03 Thread Steven Chamberlain

Control: tags -1 + pending

Alastair McKinstry wrote:
> This is fixed  with 2.0.2~git.2015125-1, currently in experimental
> (which FTBFS due to a build dependency on flex, being fixed now).

Okay, that's very cool!

(Also it seems to be missing a build-dependency on libevent-dev?)

I'm not sure how they fixed it.  What I've been doing since yesterday is
writing support to check peer credentials on a socket the FreeBSD way
(using LOCAL_PEERCRED) in pmix.  I was able to fix the issue that way.

In OpenMPI 2.0.2, they still didn't implement that, but somehow the
issue is fixed.  Do you possibly know what they changed, or even the
specific Git commit where they fixed this?

(Also I was wrong that FreeBSD Ports doesn't have OpenMPI 2.x - they
do have an openmpi2 port since very recently).

Many thanks,
Regards,
-- 
Steven Chamberlain
ste...@pyro.eu.org

signature.asc
Description: Digital signature

Bug#846635: openmpi: broken on kfreebsd since 2.x

2016-12-02 Thread Steven Chamberlain

Package: openmpi
Version: 2.0.1-7
Severity: important
Tags: upstream
User: debian-bsd@lists.debian.org
Usertags: kfreebsd

Hi,

(Greetings from the BSP at TU-Dresden, 2016!)

Updating mpirun-bin from 1.10.2-14 to 2.0.1-7 breaks the testsuite
of dune-common (error below), but also this simple testcase too:

| #include 
| 
| int main(int argc, char *argv[]) {
| MPI_Init(, );
| MPI_Finalize();
| return 0;
| }

fails with:

> $ OMPI_MCA_plm_rsh_agent=/bin/false ./testcase
> 
> [hostname.example.com:96346] PMIX ERROR: UNREACHABLE in file
> src/client/pmix_client.c at line 983
> [hostname.example.com:96347] PMIX ERROR: NOT-SUPPORTED in file
> src/server/pmix_server_listener.c at line 540
> [hostname.example.com:96346] PMIX ERROR: UNREACHABLE in file
> src/client/pmix_client.c at line 199
> --
> It looks like orte_init failed for some reason; your parallel process is
> likely to abort.  There are many reasons that a parallel process can
> fail during orte_init; some of which are due to configuration or
> environment problems.  This failure appears to be an internal failure;
> here's some additional information (which may only be relevant to an
> Open MPI developer):
> 
>   init pmix failed
>   --> Returned value Unreachable (-12) instead of ORTE_SUCCESS

It is the same error in dune-common:

> FAIL: mpicollectivecommunication
> 
> 
> [falla:96461] PMIX ERROR: UNREACHABLE in file src/client/pmix_client.c
> at line 983
> [falla:96461] PMIX ERROR: UNREACHABLE in file src/client/pmix_client.c
> at line 199
> [falla:96489] PMIX ERROR: NOT-SUPPORTED in file
> src/server/pmix_server_listener.c at line 540
> --
> It looks like orte_init failed for some reason; your parallel process is
> likely to abort.  There are many reasons that a parallel process can
> fail during orte_init; some of which are due to configuration or
> environment problems.  This failure appears to be an internal failure;
> here's some additional information (which may only be relevant to an
> Open MPI developer):
> 
>   init pmix failed
>   --> Returned value Unreachable (-12) instead of ORTE_SUCCESS

What I understand so far is that, since MPI version 2.x, pmix_native.c
tries to check peer credentials on a socket.  But FreeBSD lacks
SO_PEERCRED and there isn't yet code to implement this any other way.

FreeBSD ports hasn't packed MPI version 2.x yet so, probably this
is just unimplemented/unported yet.

-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: kfreebsd-amd64 (x86_64)

Kernel: kFreeBSD 10.1-0-amd64
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Bug#845105: mk-freebsd: bsd.cpu.mk sets -mfloat-abi=softfp on armhf

2016-11-30 Thread Steven Chamberlain

Adrian Bunk wrote:
> The root cause of this ctfutils FTBFS is that -mfloat-abi=softfp
> is passed to the compiler on armhf, which seems to come from
> /usr/share/mk-freebsd/bsd.cpu.mk

Thanks for pointing that out!

All arm* architectures were being mapped to the FreeBSD MACHINE_TYPE
"armv6" which targets the soft-float ABI.

I've defined a new MACHINE_TYPE "armv6hf" and mapped armhf to that
instead (as well as kfreebsd-armhf, for when it exists).

ctfutils was given back and rebuild successfully after this change.
armel should work as before.  We don't yet have arm64 support;  that
will happen in time.

Regards,
-- 
Steven Chamberlain
ste...@pyro.eu.org

signature.asc
Description: Digital signature

Re: Trying to use kFreeBSD as a firewall, but it won't forward packets

2016-11-29 Thread Steven Chamberlain

Hi!

Rich Wales wrote:
> I can connect between my LAN and the firewall (via its LAN interface) --
> and I can reach the Internet from the firewall (via its WAN interface)

So, the kFreeBSD box has a correct default route out to the Internet?
# route get -n 0.0.0.0

> -- but I can't manage to go *through* the firewall from my LAN to the
> Internet (I've set up another box to use the kFreeBSD firewall as its
> gateway, but packets are simply being dropped).

The LAN interface will need to have an appropriate IP address and
netmask assigned on it, and the interface must be 'UP' of course.

Does the kFreeBSD box have a correct route to the source?
# route get -n 192.168.1.2
(or whatever is the IP of that other box)

> I have *net.inet.ip.forwarding* enabled,

That's required, yes.

> I'm using a minimal PF
> configuration that does NAT and passes everything in and out on both
> network interfaces.

Please check if the ruleset is correctly loaded and enabled, e.g. with
# pfctl -ef /etc/pf.conf

It may be useful to check the output from
# pfctl -vsa

Regards,
-- 
Steven Chamberlain
ste...@pyro.eu.org

signature.asc
Description: Digital signature

Re: FreeBSD kernel don't upgrade?

2016-11-21 Thread Steven Chamberlain

Hello!

邹 佳庆 wrote:
> I'm debian/kfreebsd user, i want update freebsd kernel to
> 11.0-current, but i can't upgrade it.

I have not yet got FreeBSD 11.0 working yet.

There were some experimental packages:
ftp://ftp.debian.org/debian/pool/main/k/kfreebsd-11/kfreebsd-image-11-amd64_11.0%7Esvn295083-1%7Edebug1_kfreebsd-amd64.deb
ftp://ftp.debian.org/debian/pool/main/k/kfreebsd-11/kfreebsd-image-11.0-0-amd64_11.0%7Esvn295083-1%7Edebug1_kfreebsd-amd64.deb

but those are now quite old.  And I think there were some problems.
Be careful, if you decide to try using those - the system might not
boot.

I think, sometime next year we will make Debian packages for the
FreeBSD 11.1 kernel.

Regards,
-- 
Steven Chamberlain
ste...@pyro.eu.org

Re: Building kFreeBSD

2016-11-10 Thread Steven Chamberlain

Hi!

Jonathan Moore wrote:
> I'm new coming from FreeBSD how does one build the kFreeBSD kernel and
> install it.

A problem is that if you're not already running Debian GNU/kFreeBSD, you
likely don't have everything necessary to build or install it. Such as:
Debian packaging tools, dpkg, some GNU utilities and scripts to automate
the GRUB2 configuration.

Typically with Debian, users run the installer and install our pre-built
binaries. After that you can easily re-build any parts yourself from
source. Our kernel is in the Debian source package "kfreebsd-10" and
the procedure to build it is the same as for any Debian package (see
below).

$ apt-get source kfreebsd-10
$ sudo apt-get build-dep kfreebsd-10
$ cd kfreebsd-10-*/ && dpkg-buildpackage -g

And here is a log from a Debian build machine building that package:
https://buildd.debian.org/status/fetch.php?pkg=kfreebsd-10=kfreebsd-amd64=10.3~svn300087-1=1464439605

But if you're coming from FreeBSD I understand your preference to build
it yourself from source.

You can actually run the Debian GNU/kFreeBSD userland in a chroot or
jail, with the original FreeBSD kernel. It perhaps makes more sense to
start there. But building all of that yourself is difficult without
starting from a minimal chroot with some pre-built binaries. I could
make a tarball of this available, or perhaps a shellscript that builds
such a chroot from .deb files (we have something like that already
for Debian GNU/Linux called multistrap).

What would be ideal is if that all could be cross-built from regular
FreeBSD, or from Debian GNU/Linux, so that you don't need to trust any
binaries provided by me/us. This is an area of ongoing research.

We also have the Reproducible Builds effort so that, multiple parties
shall soon be able to build the Debian packages from source and attest
that the binaries Debian provides are authentic and trustworthy.

> I installed the sources with synaptic but the makefile
> fails. Thanks for the help.

What OS were you trying to build it on?

Regards,
--
Steven Chamberlain
ste...@pyro.eu.org

Re: Bug#827319: vim: FTBFS[alpha,kfreebsd-*]: Test_tagcase() failed

2016-11-05 Thread Steven Chamberlain

Hello,

James McCoy wrote:
> What about just disabling the Perl bindings on kfreebsd-any for now?

If you'd be happy to do that, yes please.  But keeping the bug open.

Regards,
-- 
Steven Chamberlain
ste...@pyro.eu.org


signature.asc
Description: Digital signature

Re: Bug#827319: vim: FTBFS[alpha,kfreebsd-*]: Test_tagcase() failed

2016-11-04 Thread Steven Chamberlain

Hi,

If you've no objection, I may build vim on the kfreebsd-* porterboxes
with DEB_BUILD_OPTIONS=nocheck, and binNMU the result.

The problem would still be there, and it would be RC-severity if
kfreebsd were part of the stable release, but it's currently not.

Doing this would fix debootstrap of sid in the meantime.

Regards,
-- 
Steven Chamberlain
ste...@pyro.eu.org


signature.asc
Description: Digital signature

Bug#837289: kfreebsd-10: FTBFS: objcopy:linux32_vdso.so: Invalid bfd target

2016-10-27 Thread Steven Chamberlain

severity 837289 important
thanks

Hi,

Lucas Nussbaum wrote:
> Severity: serious
> Justification: FTBFS on amd64

This package's Architecture: fields do not include [linux-]amd64, so I
think this is not release-critical.  It is desirable though that we can
fix it to become possible (again) to build it on linux.

Regards,
-- 
Steven Chamberlain
ste...@pyro.eu.org

signature.asc
Description: Digital signature

Re: Please dak copy-installer for jessie-kfreebsd

2016-10-21 Thread Steven Chamberlain

Hi,

Steven Chamberlain wrote:
> I have uploaded debian-installer/20150422+kbsd8u2+deb8u4 [...]

That has been superseded already by 20150422+kbsd8u3, which seems to
have already been processed through BYHAND, perhaps automatically.

You may wish to remove 20150422+kbsd8u2+deb8u4 from the BYHAND queue
unless that is automatically decrufted sometime.

> Please could you 'dak copy-installer' as appropriate?

Also that was not the right thing to ask.  It merely needed unpacking;
dak's scripts/debian/byhand-di does this.  AFAICT the procedure is (in
case this ever needs to be done by hand in future) :

# cd /srv/ftp-master.debian.org/queue/byhand
# /srv/ftp-master.debian.org/dak/scripts/debian/byhand-di 
debian-installer-images_20150422+kbsd8u3_kfreebsd-amd64.tar.gz 20150422+kbsd8u3 
kfreebsd-amd64 debian-installer_20150422+kbsd8u3_kfreebsd-amd64.changes 
jessie-kfreebsd-proposed-updates
# /srv/ftp-master.debian.org/dak/scripts/debian/byhand-di 
debian-installer-images_20150422+kbsd8u3_kfreebsd-amd64.tar.gz 20150422+kbsd8u3 
kfreebsd-i386 debian-installer_20150422+kbsd8u3_kfreebsd-i386.changes 
jessie-kfreebsd-proposed-updates

Thanks,
Regards,
-- 
Steven Chamberlain
stev...@debian.org

signature.asc
Description: Digital signature

Re: Bug#827319: vim: FTBFS[alpha,kfreebsd-*]: Test_tagcase() failed

In case it is helpful to know this later:

  1561 100852 vim  0.016031 NAMI "/home/stevenc/vim-8.0.0022/src/vim-gtk/po"
  1561 100852 vim  0.016033 RET   __getcwd 0
  1561 100852 vim  0.016065 CALL  break(0x136b000)
  1561 100852 vim  0.016071 RET   break 0
  1561 100852 vim  0.016110 CALL  gettimeofday(0xbfbfe548,0)
  1561 100852 vim  0.016113 RET   gettimeofday 0
  1561 100852 vim  0.016251 CALL  stat(0x134bf98,0xbfbfe3b0)
  1561 100852 vim  0.016256 NAMI  "/usr/share/vim/vim80"
  1561 100852 vim  0.016269 RET   stat -1 errno 2 No such file or directory
  1561 100852 vim  0.016273 CALL  stat(0x134bf98,0xbfbfe3b0)
  1561 100852 vim  0.016276 NAMI  "/usr/share/vim/runtime"
  1561 100852 vim  0.016283 RET   stat -1 errno 2 No such file or directory
  1561 100852 vim  0.016313 CALL  ioctl(0x1,0x402c7413,0xbfbfe4a4)
  1561 100852 vim  0.016317 RET   ioctl 0
  1561 100852 vim  0.016364 PSIG  SIGSEGV SIG_DFL code=SEGV_MAPERR
  1561 100852 vim  0.016370 NAMI  "vim.core"

the ioctl there is TIOCGETA (type 0x74, number 0x13) and it is reading
0x2c = 44 bytes (struct termios) to a stack variable, for fd 0x1
(stdout).

That part looks okay;  the segfault happens sometime after it.

The only code that would seem to use that ioctl is os_unix.c's
mch_settmode() which normally does a tcgetattr followed by a tcsetattr.
This is a wild guess, but maybe the segfault is in that function?
(HAVE_TERMIOS_H is defined here on kfreebsd-i386).

Nothing here seems related to large file support, though.  Are you sure
the crashed triggered by large file support is really the same issue?
(Does the end of the ktrace look like the above?)

Regards,
-- 
Steven Chamberlain
ste...@pyro.eu.org


signature.asc
Description: Digital signature

Re: Bug#827319: vim: FTBFS[alpha,kfreebsd-*]: Test_tagcase() failed

James McCoy wrote:
> Lo and behold, configuring without --enable-perlinterp but adding
> "-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64" to PERL_CFLAGS in
> src/auto/config.mk reproduces the issue.
[...]
> Which begs the question, why does configure think the defines aren't
> necessary?

That seems to not be the issue.  It is just testing if lseeko() is
declared already, without explicitly asking for -D_LARGEFILE_SOURCE.
The result on both kfreebsd and linux is that it is not needed to use
-D_LARGEFILE_SOURCE at all.

So the linux arches already build option.c with -D_LARGEFILE_SOURCE and
-D_FILE_OFFSET_BITS=64, and most other sources without.  I wonder what
are the implications.  -D_FILE_OFFSET_BITS=64 has some effects on 32-bit
arches, but not on 64-bit where relevant types are 64 bits long anyway.

Regards,
-- 
Steven Chamberlain
ste...@pyro.eu.org


signature.asc
Description: Digital signature

Re: Bug#827319: vim: FTBFS[alpha,kfreebsd-*]: Test_tagcase() failed

James McCoy wrote:
> And why does Perl's build think they are necessary, advertising them as
> required to build against Perl?

Even in Linux architectures (amd64 and armhf for example) Perl
advertises -D_LARGEFILE_SOURCE as a necessary compiler flag:

$ perl -MExtUtils::Embed -e ccopts
 -D_REENTRANT -D_GNU_SOURCE -DDEBIAN -fwrapv -fno-strict-aliasing -pipe
-I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64
-I/usr/lib/x86_64-linux-gnu/perl/5.20/CORE 

According to feature_test_macros(7) it should not be necessary and is
now discouraged;  but it reads like _LARGEFILE_SOURCE should be defined
by default anyway.  Maybe that is the issue we have on kfreebsd-i386.

Regards,
-- 
Steven Chamberlain
ste...@pyro.eu.org

signature.asc
Description: Digital signature

Re: Bug#827319: vim: FTBFS[alpha,kfreebsd-*]: Test_tagcase() failed

Steven Chamberlain wrote:
> If I override that flag with -fno-wrapv:
> 
> + $(CCC) $(LUA_CFLAGS) $(PERL_CFLAGS) -fno-wrapv $(PYTHON_CFLAGS) 
> $(PYTHON3_CFLAGS) $(RUBY_CFLAGS) $(TCL_CFLAGS) -o $@ option.c
> 
> then it no longer segfaults, and all vim-gtk tests pass :)

Or, I possibly mis-compiled it without Perl bindings.  I'd better
double-check this first.

Regards,
-- 
Steven Chamberlain
ste...@pyro.eu.org


signature.asc
Description: Digital signature

Re: Bug#827319: vim: FTBFS[alpha,kfreebsd-*]: Test_tagcase() failed