Re: Bug#628493: perl: FTBFS on kfreebsd-i386: t/op/threads failed

2011-08-04 Thread Niko Tyni 
On Tue, Aug 02, 2011 at 04:31:38PM +0300, Niko Tyni wrote:
> On Sun, May 29, 2011 at 04:01:48PM +0100, Dominic Hargreaves wrote:
> > Source: perl
> > Version: 5.14.0-1
> > Severity: important
> > 
> > perl 5.14 failed to build on kfreebsd-i386:
> > 
> > <https://buildd.debian.org/status/fetch.php?pkg=perl&arch=kfreebsd-i386&ver=5.14.0-1&stamp=1306233511>
> > 
> > t/op/threads...FAILED--expected
> >  24 tests, saw 23
> 
> I'm able to reproduce this on a kvm kfreebsd-i386 virtual machine with
> SMP enabled (but not on a non-SMP kernel, where the package builds fine.)

Also happens with the perl in sid (5.12.4), reduced down to

 perl -Mthreads -e 'threads->create(sub {})->detach; fork'

which crashes non-deterministically about half the time for me.

I don't see this on a "real" FreeBSD system (8.2-RELEASE), nor on Linux.

I'll report it upstream, but it seems possible that the problem is more
on the libc / kernel side. Cc'ing the kfreebsd porter list. Help would
be appreciated.

Program terminated with signal 11, Segmentation fault.
#0  0x28366062 in nanosleep () at ../sysdeps/unix/syscall-template.S:82
82  ../sysdeps/unix/syscall-template.S: No such file or directory.
in ../sysdeps/unix/syscall-template.S
(gdb) bt
#0  0x28366062 in nanosleep () at ../sysdeps/unix/syscall-template.S:82
#1  0x28364358 in __pthread_acquire (spinlock=) at 
spinlock.c:728
#2  0x283644ce in wait_node_free (lock=0x830dc14) at spinlock.c:307
#3  __pthread_alt_unlock (lock=0x830dc14) at spinlock.c:591
#4  0x2836185f in __pthread_mutex_unlock (mutex=0x830dc04) at mutex.c:199
#5  0x08100eff in Perl_atfork_unlock () at util.c:2611
#6  0x28361b86 in __pthread_fork (b=0x284969e0) at ptfork.c:72
#7  0x28402bd1 in __libc_fork () at 
../linuxthreads/sysdeps/unix/sysv/linux/fork.c:39
#8  0x28361ab4 in __fork () at ptfork.c:84
#9  0x081e77a0 in Perl_pp_fork (my_perl=0x830dd00) at pp_sys.c:4056
#10 0x080fc6dc in Perl_runops_debug (my_perl=0x830dd00) at dump.c:2049
#11 0x0808eae4 in S_run_body (my_perl=0x830dd00) at perl.c:2308
#12 perl_run (my_perl=0x830dd00) at perl.c:2233
#13 0x08066e97 in main (argc=4, argv=0xbfbfe7b0, env=0xbfbfe7c4) at 
perlmain.c:117

-- 
Niko Tyni   nt...@debian.org


-- 
To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110804084827.GA21961@madeleine.local.invalid

Re: Bug#628493: perl: FTBFS on kfreebsd-i386: t/op/threads failed

2011-09-10 Thread Niko Tyni 
On Mon, Aug 08, 2011 at 12:36:22PM +0200, Petr Salinger wrote:
> >perl -Mthreads -e 'threads->create(sub {})->detach; fork'
> >
> >which crashes non-deterministically about half the time for me.

> The problem might be in usage of "pthread_atfork(lock, unlock, unlock)".

[...]

> It should suffice to add into util.c

> Perl_atfork_reinit(void)

> and

> --- miniperlmain.c
> +++ miniperlmain.c
> @@ -101,7 +101,7 @@
>   * --GSAR 2001-07-20 */
>  PTHREAD_ATFORK(Perl_atfork_lock,
> Perl_atfork_unlock,
> -   Perl_atfork_unlock);
> +   Perl_atfork_reinit);
>  #endif

Thanks, and sorry for the delay!

I finally found the time to try this out, but unfortunately it does
not seem to fix the problem.  Even the crash trace looks the same.
(I did check that Perl_atfork_reinit() actually gets run.)

I'm attaching the full patch I used based on the above. Most of it is
generated by regen.pl in the source top level directory after editing
embed.fnc.

Running 'debian/rules perl.debug' after applying this should be enough to
do a test build. Alternatively, I'm happy to try out other suggestions,
hopefully with a shorter turnaround time than with this one :)

Thanks again,
-- 
Niko Tyni   nt...@debian.org
>From ad6bd76bce15cf552e86a9648c357fe29233ec63 Mon Sep 17 00:00:00 2001
From: Niko Tyni 
Date: Sat, 10 Sep 2011 18:57:43 +0300
Subject: [PATCH] Reinit mutex after a fork()

First try at fixing a non-deterministical crash on Debian GNU/kFreeBSD with

 perl -Mthreads -e 'threads->create(sub {})->detach; fork

Patch by Petr Salinger, <http://bugs.debian.org/628493>
---
 embed.fnc  |1 +
 embed.h|2 ++
 global.sym |1 +
 miniperlmain.c |2 +-
 proto.h|1 +
 util.c |   13 +
 6 files changed, 19 insertions(+), 1 deletions(-)

diff --git a/embed.fnc b/embed.fnc
index 7e00e79..d89d139 100644
--- a/embed.fnc
+++ b/embed.fnc
@@ -726,6 +726,7 @@ Apr	|void	|my_failure_exit
 Ap	|I32	|my_fflush_all
 Anp	|Pid_t	|my_fork
 Anp	|void	|atfork_lock
+Anp	|void	|atfork_reinit
 Anp	|void	|atfork_unlock
 Ap	|I32	|my_lstat
 #if !defined(HAS_MEMCMP) || !defined(HAS_SANE_MEMCMP)
diff --git a/embed.h b/embed.h
index 2b80af0..83cfa6f 100644
--- a/embed.h
+++ b/embed.h
@@ -560,6 +560,7 @@
 #define my_fflush_all		Perl_my_fflush_all
 #define my_fork			Perl_my_fork
 #define atfork_lock		Perl_atfork_lock
+#define atfork_reinit		Perl_atfork_reinit
 #define atfork_unlock		Perl_atfork_unlock
 #define my_lstat		Perl_my_lstat
 #if !defined(HAS_MEMCMP) || !defined(HAS_SANE_MEMCMP)
@@ -2970,6 +2971,7 @@
 #define my_fflush_all()		Perl_my_fflush_all(aTHX)
 #define my_fork			Perl_my_fork
 #define atfork_lock		Perl_atfork_lock
+#define atfork_reinit		Perl_atfork_reinit
 #define atfork_unlock		Perl_atfork_unlock
 #define my_lstat()		Perl_my_lstat(aTHX)
 #if !defined(HAS_MEMCMP) || !defined(HAS_SANE_MEMCMP)
diff --git a/global.sym b/global.sym
index 7788338..3567ee3 100644
--- a/global.sym
+++ b/global.sym
@@ -304,6 +304,7 @@ Perl_my_failure_exit
 Perl_my_fflush_all
 Perl_my_fork
 Perl_atfork_lock
+Perl_atfork_reinit
 Perl_atfork_unlock
 Perl_my_lstat
 Perl_my_memcmp
diff --git a/miniperlmain.c b/miniperlmain.c
index 39f8f19..7648eb3 100644
--- a/miniperlmain.c
+++ b/miniperlmain.c
@@ -101,7 +101,7 @@ main(int argc, char **argv, char **env)
  * --GSAR 2001-07-20 */
 PTHREAD_ATFORK(Perl_atfork_lock,
Perl_atfork_unlock,
-   Perl_atfork_unlock);
+   Perl_atfork_reinit);
 #endif
 
 if (!PL_do_undump) {
diff --git a/proto.h b/proto.h
index 3306ab0..baab0d3 100644
--- a/proto.h
+++ b/proto.h
@@ -2034,6 +2034,7 @@ PERL_CALLCONV void	Perl_my_failure_exit(pTHX)
 PERL_CALLCONV I32	Perl_my_fflush_all(pTHX);
 PERL_CALLCONV Pid_t	Perl_my_fork(void);
 PERL_CALLCONV void	Perl_atfork_lock(void);
+PERL_CALLCONV void	Perl_atfork_reinit(void);
 PERL_CALLCONV void	Perl_atfork_unlock(void);
 PERL_CALLCONV I32	Perl_my_lstat(pTHX);
 #if !defined(HAS_MEMCMP) || !defined(HAS_SANE_MEMCMP)
diff --git a/util.c b/util.c
index 89fea23..f100237 100644
--- a/util.c
+++ b/util.c
@@ -2612,6 +2612,19 @@ Perl_atfork_unlock(void)
 #endif
 }
 
+void
+Perl_atfork_reinit(void)
+{
+dVAR;
+#if defined(USE_ITHREADS)
+/* locks must be released in same order as in atfork_lock() */
+#  ifdef MYMALLOC
+MUTEX_INIT(&PL_malloc_mutex);
+#  endif
+OP_REFCNT_INIT;
+#endif
+}
+
 Pid_t
 Perl_my_fork(void)
 {
-- 
1.7.5.4

Re: [PATCH] Further eliminate POSIX-emulation under LinuxThreads

2012-02-12 Thread Niko Tyni 
[crossposted to the Debian GNU/kFreeBSD development list debian-bsd
 and the Perl 5 development list perl5-porters ]

On Sat, Feb 11, 2012 at 07:57:43PM +, Ævar Arnfjörð Bjarmason wrote:
> [This is a patch I've just committed to
> avar/remove-linuxthreads-pid-caching) I'll be pushing it to blead
> unless there are any sound objections to it]
> 
> Under POSIX threads the getpid() and getppid() functions return the
> same values across multiple threads, i.e. threads don't have their own
> PID's. This is not the case under the obsolete LinuxThreads where each
> thread has a different PID, so getpid() and getppid() will return
> different values across threads.

[...]

> This is also a complete non-issue in practice these days, LinuxThreads
> was a Linux 2.4 thread implementation that nobody maintains
> anymore[2], all modern Linux distros use NPTL threads which don't
> suffer from this discrepancy.

[...]

> We've already been failing the tests in t/op/getpid.t on these systems
> that nobody apparently uses, just leave those tests in place as-is so
> they'll start failing if perl ever runs on a system without POSIX
> thread semantics.

I have no idea whether it's really LinuxThreads based or something
else, but please note that Debian GNU/kFreeBSD seems to be affected as
t/op/getpid.t started failing there with 0e21945565eb4664d84 (around
Perl 5.15.1). See [perl #96270].

> If this change is found to be unacceptable (i.e. we want to continue
> to emulate POSIX thread semantics for the sake of LinuxThreads ) we
> also need to revert v5.14.0-251-g0e21945, because currently we're only
> emulating POSIX semantics for getppid(), not getpid().

I'm cc'ing the debian-bsd list, hopefully the porters can comment on this.

 http://www.debian.org/ports/kfreebsd-gnu/
 http://www.nntp.perl.org/group/perl.perl5.porters/2012/02/msg183442.html
 https://rt.perl.org/rt3/Public/Bug/Display.html?id=96270
 
-- 
Niko Tyni   nt...@debian.org


-- 
To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120212124231.GA3786@madeleine.local.invalid

Re: Bug#672152: perl: FTBFS on kfreebsd-*: dist/threads-shared/t/waithires.t failing

2012-05-11 Thread Niko Tyni 
On Wed, May 09, 2012 at 03:22:38AM +0100, Steven Chamberlain wrote:

> Trying this a few times, I see different tests failing each time:  they
> are the six 'condition obtained' checks for cond_timedwait.  Some fail
> noticeably more often than others.  Based on ~60 runs on kfreebsd-i386:

> Strangely it seems like perl 5.14.2-9 does the same.  I'm using
> experimental eglibc 2.13-32+kkh901.

It seems to be a regression in eglibc, not in perl itself. My guess is
the fix for #654783 in 2.13-31, but it's definitely between -27 and -32.

Trying on kfreebsd-amd64 (asdfasdf.debian.net), the test passes
consistently in the wheezy chroot (libc0.1_2.13-27) and fails most of
the time in the sid one (libc0.1_2.13-32). If I LD_PRELOAD libpthread.so
from wheezy, the tests start to pass in sid, and vice versa: LD_PRELOADing
the sid libpthread.so in wheezy makes the test fail.

I don't have a C test case yet, not sure how soon I can pull one
together. Help is appreciated.
-- 
Niko Tyni   nt...@debian.org


-- 
To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120511094622.GA5164@madeleine.local.invalid

Re: Bug#672152: perl: FTBFS on kfreebsd-*: dist/threads-shared/t/waithires.t failing

2012-05-23 Thread Niko Tyni 
On Fri, May 11, 2012 at 12:46:22PM +0300, Niko Tyni wrote:
> On Wed, May 09, 2012 at 03:22:38AM +0100, Steven Chamberlain wrote:
> 
> > Trying this a few times, I see different tests failing each time:  they
> > are the six 'condition obtained' checks for cond_timedwait.  Some fail
> > noticeably more often than others.  Based on ~60 runs on kfreebsd-i386:
> 
> > Strangely it seems like perl 5.14.2-9 does the same.  I'm using
> > experimental eglibc 2.13-32+kkh901.
> 
> It seems to be a regression in eglibc, not in perl itself. My guess is
> the fix for #654783 in 2.13-31, but it's definitely between -27 and -32.
> 
> Trying on kfreebsd-amd64 (asdfasdf.debian.net), the test passes
> consistently in the wheezy chroot (libc0.1_2.13-27) and fails most of
> the time in the sid one (libc0.1_2.13-32). If I LD_PRELOAD libpthread.so
> from wheezy, the tests start to pass in sid, and vice versa: LD_PRELOADing
> the sid libpthread.so in wheezy makes the test fail.
> 
> I don't have a C test case yet, not sure how soon I can pull one
> together. Help is appreciated.

This build failure is blocking perl testing migration and is affecting
other transitions. I think we'll have to upload a new perl package with
the failing test disabled / marked as TODO on kfreebsd-* for now.

I suppose that means #672152 will stay open at 'important' until somebody
has the time to look into it properly.
-- 
Niko Tyni   nt...@debian.org


-- 
To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120523124931.GA5268@madeleine.local.invalid

Bug#753257: perl/experimental: FTBFS on kfreebsd-amd64: dist/threads/t/free failure

2014-06-29 Thread Niko Tyni 
Package: perl
Version: 5.20.0-1
Severity: important
User: debian-p...@lists.debian.org
Usertags: perl-5.20-transition
X-Debbugs-Cc: debian-bsd@lists.debian.org

The perl package in experimental failed to build on kfreebsd-amd64:

 dist/threads/t/free2 .. ok
 panic: attempt to copy value 0 to a freed scalar 8a0c78.
 dist/threads/t/free ... 
FAILED--expected 29 tests, saw 12
 [...]
 Failed 1 test out of 2336, 99.96% okay.
../dist/threads/t/free.t

Full log at
 
https://buildd.debian.org/fetch.cgi?pkg=perl&arch=kfreebsd-amd64&ver=5.20.0-1&stamp=1401906828&file=log

Cc'ing the debian-bsd list in case somebody would like to look into this.
-- 
Niko Tyni   nt...@debian.org


-- 
To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140629200411.GA5212@estella.local.invalid

Re: Bug#753257: perl/experimental: FTBFS on kfreebsd-amd64: dist/threads/t/free failure

2014-07-05 Thread Niko Tyni 
On Sun, Jun 29, 2014 at 11:04:11PM +0300, Niko Tyni wrote:
> Package: perl
> Version: 5.20.0-1
> Severity: important
> User: debian-p...@lists.debian.org
> Usertags: perl-5.20-transition
> X-Debbugs-Cc: debian-bsd@lists.debian.org
> 
> The perl package in experimental failed to build on kfreebsd-amd64:
> 
>  dist/threads/t/free2 .. ok
>  panic: attempt to copy value 0 to a freed scalar 8a0c78.
>  dist/threads/t/free ... 
> FAILED--expected 29 tests, saw 12
>  [...]
>  Failed 1 test out of 2336, 99.96% okay.
> ../dist/threads/t/free.t
> 
> Full log at
>  
> https://buildd.debian.org/fetch.cgi?pkg=perl&arch=kfreebsd-amd64&ver=5.20.0-1&stamp=1401906828&file=log
> 
> Cc'ing the debian-bsd list in case somebody would like to look into this.

I can't reproduce this on asdfasdf.debian.net. Could somebody
else please try just to build the package and report back?
-- 
Niko Tyni   nt...@debian.org


-- 
To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140705192955.GA12621@estella.local.invalid

Re: Bug#753257: perl/experimental: FTBFS on kfreebsd-amd64: dist/threads/t/free failure

2014-07-15 Thread Niko Tyni 
On Tue, Jul 15, 2014 at 08:17:13PM +0100, Steven Chamberlain wrote:
> On 05/07/14 20:29, Niko Tyni wrote:
> > I can't reproduce this on asdfasdf.debian.net. Could somebody
> > else please try just to build the package and report back?
> 
> Seems that it built on a second attempt on the kfreebsd-amd64 buildds.
> 
> Maybe something changed in a reverse dependency (like glibc or
> compiler), or it could be a race in the testsuite.  I guess we can leave
> this bug closed unless the problem comes back.

Agreed, thanks. Also thanks to Petr for the testing! 
-- 
Niko Tyni   nt...@debian.org


-- 
To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140715192633.GA12176@estella.local.invalid

Re: Bug#753144: net-snmp: FTBFS on kfreebsd-amd64 - 'struct kinfo_proc' has no member named 'kp_eproc'

2014-07-16 Thread Niko Tyni 
On Sun, Jun 29, 2014 at 05:40:40PM +0200, Niels Thykier wrote:
> Source: net-snmp
> Version: 5.7.2.1~dfsg-6
> Severity: serious
 
> Your package FTBFS on kfreebsd-amd64 (but not kfreebsd-i386) with the 
> following errors (see [LOG]):
 
> In file included from ../../include/net-snmp/net-snmp-config.h:2085:0,
>  from host/data_access/swrun_kinfo.c:8:
> ../../include/net-snmp/system/kfreebsd.h:5:0: warning: "__FreeBSD_version" 
> redefined
>  #define __FreeBSD_version __FreeBSD_kernel_version
>  ^
> In file included from /usr/include/sys/kern/param.h:1:0,
>  from /usr/include/osreldate.h:1,
>  from ../../include/net-snmp/system/kfreebsd.h:4,
>  from ../../include/net-snmp/net-snmp-config.h:2085,
>  from host/data_access/swrun_kinfo.c:8:
> /usr/include/sys/kglue/sys/param.h:67:0: note: this is the location of the 
> previous definition
>  #define __FreeBSD_version 1000510 /* Master, propagated to newvers */
>  ^
> host/data_access/swrun_kinfo.c: In function 
> 'netsnmp_arch_swrun_container_load':
> host/data_access/swrun_kinfo.c:168:32: error: 'struct kinfo_proc' has no 
> member named 'kp_proc'
>  if ( 0 == proc_table[i].SWRUN_K_STAT )
[...]

> This FTBFS makes net-snmp unable to migrate to testing.

It also fails the same way in a current kfreebsd-i386 chroot.

The kfreebsd-i386 buildd had kfreebsd-kernel-headers_9.2~8 at the time
while the failing kfreebsd-amd64 one had kfreebsd-kernel-headers_10.0~5.
It looks like something happened with __FreeBSD_version and/or
__FreeBSD_kernel_version in between.

The attached naïve patch fixes it for me on the porter kfreebsd machines,
but then at the end I strangely get:

  libtool: install: /usr/bin/install -c .libs/snmpnetstat 
/home/ntyni/net-snmp-5.7.2.1~dfsg/debian/tmp/usr/bin/snmpnetstat
  installing snmpnetstat in /home/ntyni/net-snmp-5.7.2.1~dfsg/debian/tmp/usr/bin
  make[3]: Leaving directory 
'/home/ntyni/net-snmp-5.7.2.1~dfsg/apps/snmpnetstat'
  rm -f /home/ntyni/net-snmp-5.7.2.1~dfsg/debian/tmp/usr/bin/snmpinform
  ln -s snmptrap /home/ntyni/net-snmp-5.7.2.1~dfsg/debian/tmp/usr/bin/snmpinform
  libtool: install: /usr/bin/install -c -m 644 ./snmp_perl_trapd.pl 
/home/ntyni/net-snmp-5.7.2.1~dfsg/debian/tmp/usr/share/snmp/snmp_perl_trapd.pl
  install:  installed snmp_perl_trapd.pl in 
/home/ntyni/net-snmp-5.7.2.1~dfsg/debian/tmp/usr/share/snmp
  make[2]: Leaving directory '/home/ntyni/net-snmp-5.7.2.1~dfsg/apps'
  making install in /home/ntyni/net-snmp-5.7.2.1~dfsg/man
  make[2]: Entering directory '/home/ntyni/net-snmp-5.7.2.1~dfsg/man'
  mkdir /home/ntyni/net-snmp-5.7.2.1~dfsg/debian/tmp/usr/share/man
  mkdir /home/ntyni/net-snmp-5.7.2.1~dfsg/debian/tmp/usr/share/man/man1
  mkdir /home/ntyni/net-snmp-5.7.2.1~dfsg/debian/tmp/usr/share/man/man3
  mkdir /home/ntyni/net-snmp-5.7.2.1~dfsg/debian/tmp/usr/share/man/man5
  mkdir /home/ntyni/net-snmp-5.7.2.1~dfsg/debian/tmp/usr/share/man/man8
  make[2]: *** No rule to make target 'snmpinform.1', needed by 'maninstall'.  
Stop.
  make[2]: Leaving directory '/home/ntyni/net-snmp-5.7.2.1~dfsg/man'
  Makefile:950: recipe for target 'installsubdirs' failed
  make[1]: *** [installsubdirs] Error 1
  make[1]: Leaving directory '/home/ntyni/net-snmp-5.7.2.1~dfsg'
  dh_auto_install: make -j1 install 
DESTDIR=/home/ntyni/net-snmp-5.7.2.1~dfsg/debian/tmp AM_UPDATE_INFO_DIR=no 
returned exit code 2
  debian/rules:38: recipe for target 'binary' failed
  make: *** [binary] Error 2

which I haven't solved yet.

CC'ing the debian-bsd list. Maybe somebody can pick this up and/or at
least eyeball the patch. In case someone ends up doing an NMU, please
include the patch in #751918 too.
-- 
Niko Tyni   nt...@debian.org
>From a2f2f610b56c7d6bce88a8dab54a1f09bcd6f5b7 Mon Sep 17 00:00:00 2001
From: Niko Tyni 
Date: Wed, 16 Jul 2014 21:42:30 +
Subject: [PATCH] Fix kfreebsd builds with kernel headers >= 10

This fixes warnings like

In file included from ../../include/net-snmp/net-snmp-config.h:2085:0,
 from host/data_access/swinst_apt.c:5:
../../include/net-snmp/system/kfreebsd.h:5:0: warning: "__FreeBSD_version" redefined [enabled by default]
 #define __FreeBSD_version __FreeBSD_kernel_version
 ^
In file included from /usr/include/sys/kern/param.h:1:0,
 from /usr/include/osreldate.h:1,
 from ../../include/net-snmp/system/kfreebsd.h:4,
 from ../../include/net-snmp/net-snmp-config.h:2085,
 from host/data_access/swinst_apt.c:5:
/usr/include/sys/kglue/sys/param.h:67:0: note: this is the location of the previous definition
 #define __FreeBSD_version 1000510 /* Master, propagated to newvers */

and makes agent/mibgroup/host/data_access/swrun_k

Re: Bug#753144: net-snmp: FTBFS on kfreebsd-amd64 - 'struct kinfo_proc' has no member named 'kp_eproc'

2014-07-17 Thread Niko Tyni 
On Thu, Jul 17, 2014 at 01:45:38AM +0300, Niko Tyni wrote:

>   make[2]: *** No rule to make target 'snmpinform.1', needed by 'maninstall'. 
>  Stop.

Ah, that's probably just because I used 'git clean -dfx' between test
builds. The upstream .gitignore has man/*.[1358] but there's no rule to
remake man/snmpinform.1. Oh well. I guess I shouldn't hack so late.

> CC'ing the debian-bsd list. Maybe somebody can pick this up and/or at
> least eyeball the patch. In case someone ends up doing an NMU, please
> include the patch in #751918 too.

I'd appreciate if somebody more knowledgeable could check the patch.
Due to the large number of reverse dependencies, net-snmp is one of
the more important packages for the upcoming Perl 5.20 transition,
which makes this FTBFS bug a transition blocker.
-- 
Niko Tyni   nt...@debian.org


-- 
To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140717123301.GA25149@estella.local.invalid

Re: Bug#758283: libnet-arp-perl: FTBFS on kfreebsd-*: unknown type name 'uint64_t'

2014-08-17 Thread Niko Tyni 
On Sat, Aug 16, 2014 at 12:26:15PM +0300, Niko Tyni wrote:
> Package: libnet-arp-perl
> Version: 1.0.8-1
> Severity: serious
> 
> Rebuilding this package against Perl 5.20 failed on the kfreebsd-* buildds:
> 
>   cc -c   -D_REENTRANT -D_GNU_SOURCE -DDEBIAN -fstack-protector -fwrapv 
> -fno-strict-aliasing -pipe -I/usr/local/include -D_LARGEFILE_SOURCE 
> -D_FILE_OFFSET_BITS=64 -g -O2 -fstack-protector-strong -Wformat 
> -Werror=format-security -D_FORTIFY_SOURCE=2   -DVERSION=\"1.0.8\" 
> -DXS_VERSION=\"1.0.8\" -fPIC "-I/usr/lib/x86_64-kfreebsd-gnu/perl/5.20/CORE"  
> -DBSD arp_lookup_bsd.c
>   In file included from arp_lookup_bsd.c:25:0:
>   /usr/include/net/if_arp.h:130:2: error: unknown type name 'uint64_t'
> uint64_t txrequests; /* # of ARP requests sent by this host. */
> ^
>   /usr/include/net/if_arp.h:131:2: error: unknown type name 'uint64_t'
> uint64_t txreplies; /* # of ARP replies sent by this host. */
> ^

This seems to be the same issue as #754684 (cc'd).

@debian-bsd: looks like /usr/include/net/if_arp.h from
kfreebsd-kernel-headers is broken, right?
-- 
Niko Tyni   nt...@debian.org


-- 
To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140817205242.GA10599@estella.local.invalid

Re: Bug#758283: libnet-arp-perl: FTBFS on kfreebsd-*: unknown type name 'uint64_t'

2014-08-18 Thread Niko Tyni 
On Sun, Aug 17, 2014 at 11:52:42PM +0300, Niko Tyni wrote:
> On Sat, Aug 16, 2014 at 12:26:15PM +0300, Niko Tyni wrote:
> > Package: libnet-arp-perl
> > Version: 1.0.8-1
> > Severity: serious
> > 
> > Rebuilding this package against Perl 5.20 failed on the kfreebsd-* buildds:
> > 
> >   cc -c   -D_REENTRANT -D_GNU_SOURCE -DDEBIAN -fstack-protector -fwrapv 
> > -fno-strict-aliasing -pipe -I/usr/local/include -D_LARGEFILE_SOURCE 
> > -D_FILE_OFFSET_BITS=64 -g -O2 -fstack-protector-strong -Wformat 
> > -Werror=format-security -D_FORTIFY_SOURCE=2   -DVERSION=\"1.0.8\" 
> > -DXS_VERSION=\"1.0.8\" -fPIC 
> > "-I/usr/lib/x86_64-kfreebsd-gnu/perl/5.20/CORE"  -DBSD arp_lookup_bsd.c
> >   In file included from arp_lookup_bsd.c:25:0:
> >   /usr/include/net/if_arp.h:130:2: error: unknown type name 'uint64_t'
> > uint64_t txrequests; /* # of ARP requests sent by this host. */
> > ^
> >   /usr/include/net/if_arp.h:131:2: error: unknown type name 'uint64_t'
> > uint64_t txreplies; /* # of ARP replies sent by this host. */
> > ^
> 
> This seems to be the same issue as #754684 (cc'd).
> 
> @debian-bsd: looks like /usr/include/net/if_arp.h from
> kfreebsd-kernel-headers is broken, right?

OK, quoting Robert Millan in #715321:

  2013/7/7 Laurent Bigonville :
  > /usr/include/net/if_bridgevar.h is explicitly using types like
  > "uint32_t"
  >
  > Shouldn't an include for  be added?
  
  This is intentional upstream policy (to avoid header pollution).
  Programs which include  are expected to include
   first.
  
  However, because  is not available to kernel code. A lot of
  code from FreeBSD tends to use  instead, even in cases
  where it is only intended for userland.
  
  So you probably just need to replace that  in your code.

I expect this extrapolates to  too.
-- 
Niko Tyni   nt...@debian.org


-- 
To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140819055315.ga20...@hagar.it.helsinki.fi

Re: Bug#763181: libapache2-mod-perl2: FTBFS on kfreebsd-amd64: t/modules/cgiupload* failures

2014-09-29 Thread Niko Tyni 
severity 763181 important
thanks

On Sun, Sep 28, 2014 at 09:11:55PM +0100, Steven Chamberlain wrote:
> On 21:36, Christoph Egger wrote:
> > Steven Chamberlain  writes:
> > > On 21:08, Niko Tyni wrote:
> > >> On Sun, Sep 28, 2014 at 04:19:14PM +0300, Niko Tyni wrote:
> > >> Buildd admins: for now, could you please reschedule on something
> > >> else that fayrfax so we can see if it's "only" a local phenomenon?
> > >
> > > I'm okay with this too.
> > 
> > blacklisted on fayrfax and given back, let's see
> 
> Thanks Christoph;  it build fine.
> 
> Niko:  you probably should lower severity of this bug, or even close it
> for now.  I still think TEST_VERBOSE may be a good idea in case it comes
> back.

Right, downgrading. I'll look at TEST_VERBOSE at some point.
-- 
Niko Tyni   nt...@debian.org


-- 
To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140929184025.GA3977@estella.local.invalid

Re: Bug#796798: perl: FTBFS on kfreebsd-*: t/op/stat.t failure

2015-09-12 Thread Niko Tyni 
On Thu, Sep 03, 2015 at 10:52:20PM +0100, Dominic Hargreaves wrote:
> On Mon, Aug 24, 2015 at 07:15:19PM +0300, Niko Tyni wrote:
> > Package: perl
> > Version: 5.22.0-3
> > Severity: important
> > X-Debbugs-Cc: kfreebsd-i...@buildd.debian.org, 
> > kfreebsd-am...@buildd.debian.org
> > 
> > This package failed to build on kfreebsd-amd64 and kfreebsd-i386:
> > 
> >   # Failed test 9 - hard link ctime != mtime at op/stat.t line 147
> >   # it should not be "1440284403"
> >   # but it is.
> >   # Check if you are on a tmpfs of some sort.  Building in /tmp sometimes
> >   # has this problem.  Building on the ClearCase VOBS filesystem may also
> >   # cause this failure.
> >   #
> >   # Darwin's UFS doesn't have a ctime concept, and thus is expected to fail
> >   # this test.
> >   t/op/stat . FAILED at 
> > test 9

> > I see the buildds are now running kernel 10.1-0 while the earlier
> > builds were on 9.0-2.
> > 
> > @buildd admins: any ideas? Are there known issues with ctime in
> > /tmp on the buildds?
> 
> I tested on falla, and found that this is not specific to perl 5.22,
> so adjusting metadata accordingly. It's also not specific to the schroot
> environment, at least on the buildds; the same test fails outside the
> chroot.

The kfreebsd builds failed again with 5.22.0-4 because of this issue.

I'm taking the debian-bsd list into the loop. Could somebody please look
into this?
-- 
Niko Tyni   nt...@debian.org

Re: Bug#796798: perl: FTBFS on kfreebsd-*: t/op/stat.t failure

2015-12-05 Thread Niko Tyni 
Control: tag 796798 help

On Sat, Sep 12, 2015 at 07:43:03PM +0300, Niko Tyni wrote:
> On Thu, Sep 03, 2015 at 10:52:20PM +0100, Dominic Hargreaves wrote:
> > On Mon, Aug 24, 2015 at 07:15:19PM +0300, Niko Tyni wrote:
> > > Package: perl
> > > Version: 5.22.0-3
> > > Severity: important
> > > X-Debbugs-Cc: kfreebsd-i...@buildd.debian.org, 
> > > kfreebsd-am...@buildd.debian.org
> > > 
> > > This package failed to build on kfreebsd-amd64 and kfreebsd-i386:
> > > 
> > >   # Failed test 9 - hard link ctime != mtime at op/stat.t line 147
> > >   # it should not be "1440284403"
> > >   # but it is.
> > >   # Check if you are on a tmpfs of some sort.  Building in /tmp sometimes
> > >   # has this problem.  Building on the ClearCase VOBS filesystem may also
> > >   # cause this failure.
> > >   #
> > >   # Darwin's UFS doesn't have a ctime concept, and thus is expected to 
> > > fail
> > >   # this test.
> > >   t/op/stat . FAILED 
> > > at test 9
> 
> > > I see the buildds are now running kernel 10.1-0 while the earlier
> > > builds were on 9.0-2.
> > > 
> > > @buildd admins: any ideas? Are there known issues with ctime in
> > > /tmp on the buildds?
> > 
> > I tested on falla, and found that this is not specific to perl 5.22,
> > so adjusting metadata accordingly. It's also not specific to the schroot
> > environment, at least on the buildds; the same test fails outside the
> > chroot.
> 
> The kfreebsd builds failed again with 5.22.0-4 because of this issue.
> 
> I'm taking the debian-bsd list into the loop. Could somebody please look
> into this?

The Perl 5.22 transition is expected to start soon, and kfreebsd-*
will be left behind if this bug isn't fixed. @debian-bsd: could
somebody please investigate?
-- 
Niko Tyni   nt...@debian.org

Re: Bug#796798: perl: FTBFS on kfreebsd-*: t/op/stat.t failure

2015-12-18 Thread Niko Tyni 
On Thu, Dec 17, 2015 at 02:41:30AM +, Steven Chamberlain wrote:

> The problem is with mtime.  It seems to be not calculated immediately,
> but deferred until the next stat, after the hard link is created, such
> that mtime=ctime and so the test fails.  A stat() right before the
> sleep, or a much longer sleep (~30s), causes mtime to be calculated
> earlier and so fixes it.
> 
> It's obviously a kernel behaviour, its unclear if it's a bug (it may be
> an expected quirk of softupdates), and in any case definitely not a Perl
> bug.  Might we please add a stat() to work around it, as attached;  that
> would allow the test to still run, and still return a meaningful result
> rather than skipping/ignoring the test on kfreebsd.

Thanks. I've modified this to only call the added stat() on kfreebsd and
applied it. Will upload soon so kfreebsd-* can join the binNMU party.

It would be nice if you could follow up when you know if this is a
permanent thing that should go upstream or just a temporary workaround.
-- 
Niko Tyni   nt...@debian.org
>From 78c55bc50e62a3371bdf14eb02882d833738a165 Mon Sep 17 00:00:00 2001
From: Steven Chamberlain 
Date: Thu, 17 Dec 2015 02:15:58 +
Subject: Work around Debian Bug#796798

kFreeBSD 10 (possibly only with softupdates enabled) may defer
calculating the mtime for more than 2 seconds.  Work around this
with a stat() call to calculate the mtime immediately.

(Modified to only stat() on kfreebsd by Niko Tyni)

Bug-Debian: https://bugs.debian.org/796798
Patch-Name: debian/kfreebsd-softupdates.diff
---
 t/op/stat.t | 1 +
 1 file changed, 1 insertion(+)

diff --git a/t/op/stat.t b/t/op/stat.t
index ad94b3f..469f8ba 100644
--- a/t/op/stat.t
+++ b/t/op/stat.t
@@ -96,6 +96,7 @@ sleep 3 if $funky_FAT_timestamps;
 print FOO "Now is the time for all good men to come to.\n";
 close(FOO);
 
+stat($tmpfile) if $^O =~ /^gnukfreebsd/;	# Work around Debian Bug#796798
 sleep 2;
 
 my $has_link = 1;

Re: Bug#796798: Add that patch to stable also? [perl: FTBFS on kfreebsd-*: t/op/stat.t]

2016-01-15 Thread Niko Tyni 
On Thu, Jan 14, 2016 at 11:56:19PM +0100, Christoph Egger wrote:
 
> Maybe this patch could also be applied to stable (as all buildds have
> been updated to freebsd-10 and it'd be great to be able to build
> proposed-updates and security without additional work ;-)
> 
> FWIW I'll take care of the current version in -p-u for
> jessie-kfreebsd-p-u so no need to hurry

Sure, will include it if we need to make more updates to jessie
in the future. I suppose it's not a candidate on its own though.

I wonder if it also happens with the wheezy packages? The test
code looks quite similar.
-- 
Niko Tyni   nt...@debian.org

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

2016-10-16 Thread Niko Tyni 
On Sat, Oct 15, 2016 at 02:14:21PM -0400, James McCoy wrote:
> On Sat, Oct 15, 2016 at 01:40:43PM -0400, 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?
> 
> And why does Perl's build think they are necessary, advertising them as
> required to build against Perl?

I believe the immediate reason is that the PerlInterpreter struct in
perl.h / intrpvar.h has 'stat struct' members in it (aliased as Stat_t.)

This is the main interface for embedding Perl (see perlembed(1)), so
building without _FILE_OFFSET_BITS=64 results in binary incompatibility
with perl/libperl on 32-bit platforms.  We've seen plenty of related
crashes and the like with applications ignoring Perl's ccflags.

Not sure about _LARGEFILE_SOURCE; I always thought the two just need
to go together.
-- 
Niko Tyni   nt...@debian.org

Bug#912521: perl: 5.28 FTBFS on kfreebsd: test failures

2018-10-31 Thread Niko Tyni 
Source: perl
Version: 5.28.0-3
Severity: important
X-Debbugs-Cc: debian-bsd@lists.debian.org
Tags: ftbfs

This package failed to build on kfreebsd-amd64.

  
https://buildd.debian.org/status/fetch.php?pkg=perl&arch=kfreebsd-amd64&ver=5.28.0-3&stamp=1541024336&raw=0

  Failed 3 tests out of 2544, 99.88% okay.
../dist/Time-HiRes/t/utime.t
../lib/File/Copy.t
run/switches.t

Copying the debian-bsd list. Could you please investigate?

The timing with the Perl 5.28 transition starting today is unfortunate;
I didn't notice that the kfreebsd experimental buildds finally got
around to trying perl a couple of days ago so I wasn't aware of these
failures.

You (as in debian-bsd@) might want to consider uploading 5.28.0-3
binaries built with DEB_BUILD_OPTIONS=nocheck or something for now to
get the transition binNMUs. But you probably know better than me how
all that stuff works.

-- 
Niko Tyni   nt...@debian.org

Re: Bug#912521: perl: 5.28 FTBFS on kfreebsd: test failures

2018-11-19 Thread Niko Tyni 
On Mon, Nov 19, 2018 at 03:50:46PM +, James Clarke wrote:

> I did this two weeks ago, but it turns out one of the failures 
> (run/switches.t)
> is important, as it reveals that `perl -pi -e ... /tmp/foo` is broken, which 
> in
> turn causes r-base-core's postinst to fail. I've tracked this down and sent a
> patch upstream[1]; could you please apply this to the packaging?

Thanks! Applied in 5.28.0-4 (just uploaded.)
-- 
Niko