On Mon, 19 Nov 2018 21:43:22 +0200 Niko Tyni wrote:
> 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
wrote:
>>>> Source: rsyslog
>>>> Version: 8.9.0-3
>>>> Severity: important
>>>> User: debian-bsd@lists.debian.org
>>>> Usertags: kfreebsd
>>>>
>>>> As can be seen at [1] or [2], rsyslog failed reliably on the k
ty: important
>>> User: debian-bsd@lists.debian.org
>>> Usertags: kfreebsd
>>>
>>> As can be seen at [1] or [2], rsyslog failed reliably on the kfreebsd-*
>>> buildds due to failures in the test-suite:
>>>
>>> There are 17 failed t
gt;
>> As can be seen at [1] or [2], rsyslog failed reliably on the kfreebsd-*
>> buildds due to failures in the test-suite:
>>
>> There are 17 failed tests. It would be great to have help from the
>> kfreebsd porting to get those fixed.
>>
>> Thank
On Tue, 12 May 2015 13:38:12 +0200 Michael Biebl wrote:
> Source: rsyslog
> Version: 8.9.0-3
> Severity: important
> User: debian-bsd@lists.debian.org
> Usertags: kfreebsd
>
> As can be seen at [1] or [2], rsyslog failed reliably on the kfreebsd-*
> buildds due to fa
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 do
> On 31 Oct 2018, at 22:38, Niko Tyni wrote:
>
> 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&v
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
-*.
Because it's reasonably clear that nobody with an interest in FreeBSD
is currently contributing to dbus, and the test results indicate that
dbus does basically work, I'm going to ignore the test failures on
!linux for the moment.
On the kfreebsd porterboxes fala and fischer, this is easy to re
Hi,
When running the gnulib testsuite on GNU/kFreeBSD 9.0 (installed
from debian-7.11.0-kfreebsd-amd64-netinst.iso), I get two test failures:
FAIL: test-getlogin
===
../../gltests/test-getlogin.c:60: assertion 'errno == ENOTTY || errno == EINVAL
|| errno == ENXIO' f
Wheezy by avoiding systemd, I am trying
Devuan and Debian kFreeBSD (it is not a dichotomy, if both are in active
development is better). I test 2 ISOs:
daily-images/kfreebsd-i386/20170330-0004/netboot-10/mini.iso
md5sum: 15c8b5fa604075354106f1fa564af4bd
sha1sum
[Steven Chamberlain]
> It may take some time to produce a test case for upstream FreeBSD, fix
> it, and get our buildds running a fixed kernel.
The code in
http://anonscm.debian.org/cgit/collab-maint/libarchive.git/tree/tar/test/test_option_older_than.c
>
combined with the functions
ou are in a
hurry to have it built again and don't mind carying that patch. It may
take some time to produce a test case for upstream FreeBSD, fix it, and
get our buildds running a fixed kernel.
> > Neither really sounds like we're getting the correct fix, but maybe
> > I
[Andreas Henriksson]
> In my ears this sounds pretty much like we're either:
>
> a/ working around a really serious potential data loss bug in kfreebsd
> b/ hiding a race in the testsuite by making it less likely to trigger
>
> Neither really sounds like we're getting the correct fix, but maybe
> I
hive maintainer,
> > libarchive 3.2.0 fails to build from source on kFreeBSD due to this
> > test failure:
> >
> > 40: test_option_older_than
> > tar/test/test_option_older_than.c:70: File should exist: a/b/old.txt
> > tar/test/test_option_older_than.c:83:
test failure:
40: test_option_older_than
tar/test/test_option_older_than.c:70: File should exist: a/b/old.txt
tar/test/test_option_older_than.c:83: File should exist: a/b/old.txt
This would normally be Severity: serious, but kFreeBSD isn't a release
architecture, so I'm filing it as
Hi,
Andreas Beckmann wrote:
> Line 816: expected <0>, but saw <4>
> testpoll: FAILED 1 of 23
Last I remember, this issue is reproducible on regular FreeBSD as well.
FreeBSD's poll() can return EINTR unless that is specifically disabled
somehow...
Regards,
--
Steven Chamberlain
ste.
Hi,
Thanks for applying that fix to glib2.0; some ~200 packages have built
now on kfreebsd-* in sid due to this!
Regards,
--
Steven Chamberlain
ste...@pyro.eu.org
signature.asc
Description: Digital signature
Hi,
I propose the attached patch for this.
Upstream hasn't replied on this issue in their tracker in months, but
for kfreebsd we need to do something, as a large backlog of packages are
BD-Uninstallable in sid due to this.
I think it is a recursion from the GUnixMountMonitor constructor, to a
GL
Control: tags -1 + patch
Hi,
There was no progress on this bug upstream yet:
https://bugzilla.gnome.org/753378
But now we have too many packages in sid waiting on glib2.0 >= 2.44, or
indirectly. Please could we use the attached patch as a workaround (as
was done in FreeBSD), disabling kqueue, u
forwarded 734290 https://bugzilla.gnome.org/show_bug.cgi?id=753378
thanks
Also: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=202128
FreeBSD disabled kqueue in their Makefile as a workaround for this:
-CONFIGURE_ENV= ac_cv_header_sys_inotify_h=
+CONFIGURE_ENV= ac_cv_header_sys_inotify_h= \
+
Source: hiredis
Version: 0.13.1-1
Severity: important
User: debian-bsd@lists.debian.org
Usertags: kfreebsd
(debian-bsd@lists.debian.org in copy, please follow up with them if you
need help.)
Hi,
Your package no longer builds on kfreebsd-* due to two failing tests
(same on both archs):
| #44 Does
found 734290 glib2.0/2.43.92-1
found 734290 glib2.0/2.44.1-1
tags 734290 - patch
thanks
Hi,
Robert Millan wrote:
> monitor test hangs when running the testsuite on kfreebsd-amd64 (using glibc
> 2.18).
This was introduced or exposed by:
https://git.gnome.org/browse/glib/comm
Source: rsyslog
Version: 8.9.0-3
Severity: important
User: debian-bsd@lists.debian.org
Usertags: kfreebsd
As can be seen at [1] or [2], rsyslog failed reliably on the kfreebsd-*
buildds due to failures in the test-suite:
There are 17 failed tests. It would be great to have help from the
kfreebsd
Package: src:binutils
Version: 2.24.90.20141014-1
Severity: important
The testsuite shows around 190 test failures on both i386 and amd64. Please
could a porter have a look?
--
To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org
with a subject of "unsubscribe". Troubl
Processing commands for cont...@bugs.debian.org:
> tags 750836 + pending
Bug #750836 [kfreebsd-kernel-headers] machine/atomic.h broken, missing
__compiler_membar macro
Added tag(s) pending.
> tags 756553 + pending
Bug #756553 [kfreebsd-kernel-headers] kfreebsd-kernel-headers missing
/usr/include
severity 628383 important
thanks
We now know that this test failure only happens on kfreebsd-9.
kfreebsd-10, which will be released with Jessie, allows unprivileged
users to mlock() memory, and libgnome-keyring will work fine there.
Christoph was able to binNMU the package from a kfreebsd-10
ote-volume-monitors': No such file or directory
> ERROR: mimeapps - missing test plan
> ERROR: mimeapps - exited with status 133 (terminated by signal 5?)
happening for a few tests, all with the same FATAL-WARNING.
Some open questions (I'll try to figure out myself if I get tim
Hi,
The gthread tests don't seem to have problems any more in sid.
This bug can be closed, and remaining test failures discussed in #712848.
Regards,
--
Steven Chamberlain
ste...@pyro.eu.org
--
To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org
with a subject of "u
tags 710696 + patch
thanks
Hi,
I can no longer reproduce the test failures in current sid on
kfreebsd-amd64. (Except, two test failures that I would expect due to
my jail/chroot configuration).
Please consider re-enabling the testsuite on non-Linux platforms, before
closing this bug. Thanks
Source-Version: 1:2.4.10-1
On 01/06/14 03:16, Steven Chamberlain wrote:
> If there is at least 10 GiB free disk space on kfreebsd-i386 buildds,
> please could src:mongodb be given back for another build attempt?
...thanks :)
Regards,
--
Steven Chamberlain
ste...@pyro.eu.org
--
To UNSUBSCRIBE
Processing commands for cont...@bugs.debian.org:
> usertags 749786 + kfreebsd
User is debian-bsd@lists.debian.org
There were no usertags set.
Usertags are now: kfreebsd.
> thanks
Stopping processing here.
Please contact me if you need assistance.
--
749786: http://bugs.debian.org/cgi-bin/bugrepo
Hi Christoph,
If there is at least 10 GiB free disk space on kfreebsd-i386 buildds,
please could src:mongodb be given back for another build attempt?
Thanks,
Regards,
--
Steven Chamberlain
ste...@pyro.eu.org
--
To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org
with a subject of "un
Maye I misunderstood something but i think there's a reason the
memory is mlocked; to avoid leaking sensitive information into swap.
As far as I know, there is no gurantee, that mlocked memory
will not go into swap when whole PC is suspended, even under Linux.
man mlock (from Linux Programmer's
Hi,
On 18/05/14 20:38, Jeff Epler wrote:
> Apparently freebsd kernels 9.2 and later have
> security.bsd.unprivileged_mlock, which appears to default to permitted.
Ah, that is good to know.
The buildds are wheezy systems with a 9.0 kernel. I'm not sure of the
timetable for them to be upgraded
Apparently freebsd kernels 9.2 and later have
security.bsd.unprivileged_mlock, which appears to default to permitted.
http://www.freebsd.org/cgi/man.cgi?query=mlock&sektion=2&manpath=FreeBSD+9.2-RELEASE
http://marc.info/?l=freebsd-arch&m=134617193210756
Is this test failure ha
On Sat, 26 Apr 2014 11:39:02 +0200 Andreas Henriksson wrote:
> Control: tag -1 - patch
>
> While I appreciate the feedback on how mlock works on kfreebsd
> and including a patch along with discussions of technical details
> is nice, I'm going to remove the patch tag.
> Maye I misunderstood somethi
Source-Version: 2.46.0-2
connection-test now succeeds for me on kfreebsd-amd64, as well as
context-test (which was failing intermittently before).
This may be related to the following bits mentioned in the NEWS file:
> Changes in libsoup from 2.44.0 to 2.44.1:
> * Fixed a sp
Version: 1.27.1-1
Hi,
Steven Chamberlain wrote:
> tar FTBFS since 1.27-1 due to failure of extrac09.at in the testsuite.
>
> The problem occurred only on kFreeBSD and Hurd [...]
The most recent upload (looks like an upstream bugfix-only release)
seems to have fixed this issue and built fine on
Hi Steven.
On 27.01.2014 21:22, Steven Chamberlain wrote:
> I could reproduce it 8 times out of 100 here on kfreebsd-amd64.
>
> The race happens after getting Connection Refused trying to contact the
> fcgi-responder which has just exit (intentionally).
>
> The parent does a wait4() syscall, and
; 73245 101672 fcgi-responder 1390849422.663095 RET close 0
> 73245 101672 fcgi-responder 1390849422.663171 CALL exit(0)
(no further mention of pid 73245 or SIGCHLD being handled after this)
Whereas in the successful case, fcgi-responder shut down a little
faster, and the parent receives SIG
Hi,
On 24/12/13 12:58, Arno Töll wrote:
> On 01.12.2013 18:03, Michael Gilbert wrote:
>> I did some testing with a real kfreebsd machine, and this test always
>> passes (I uploaded those binaries), so it seems the problem is
>> specific to the buildds.
>
> could anyon
Control: tags -1 + patch
On 06/09/13 03:07, Steven Chamberlain wrote:
> BTW it would be nice if failures in the testsuite would output the
> contents of libmissing/tests/test-suite.log into the build log.
Please see attached libprelude-0.diff for an easy way to do this.
On 06/09/13
tags 734290 patch
thanks
On 05/01/2014 17:55, Robert Millan wrote:
> Package: glib2.0
> Version: 2.38.2-1
> Severity: important
> User: debian-bsd@lists.debian.org
> Usertags: kfreebsd
>
> monitor test hangs when running the testsuite on kfreebsd-amd64 (using glibc
>
Package: glib2.0
Version: 2.38.2-1
Severity: important
User: debian-bsd@lists.debian.org
Usertags: kfreebsd
monitor test hangs when running the testsuite on kfreebsd-amd64 (using glibc
2.18).
AFAICT this bug is not the same as #712848, so filing separately.
Note that kevent() is called
On Tue, Dec 24, 2013 at 8:15 AM, Christoph Egger
> Are you both running stable kernels for the build? are you using chroots
> or not?
I was using a chroot and the unstable 9.2 kernel. I can try a
non-chroot build if that may be somehow helpful?
Best wishes,
Mike
--
To UNSUBSCRIBE, email to de
Hi Christoph,
On 24.12.2013 14:15, Christoph Egger wrote:
> Are you both running stable kernels for the build? are you using chroots
> or not?
I use sbuild and unstable on my dev environment.
--
with kind regards,
Arno Töll
IRC: daemonkeeper on Freenode/OFTC
GnuPG Key-ID: 0x9D80F36D
signatu
Hi!
Arno Töll writes:
> On 01.12.2013 18:03, Michael Gilbert wrote:
>> The mod-fastcgi.t test sometimes fails and sometimes succeeds on the
>> kfreebsd build daemons. Please see latest build logs:
>> https://buildd.debian.org/status/logs.php?pkg=lighttpd&ar
tags 731074 help
thanks
Hi,
On 01.12.2013 18:03, Michael Gilbert wrote:
> The mod-fastcgi.t test sometimes fails and sometimes succeeds on the
> kfreebsd build daemons. Please see latest build logs:
> https://buildd.debian.org/status/logs.php?pkg=lighttpd&arch=kfreebsd
Package: tar
Version: 1.27-1
Severity: serious
Justification: FTBFS
User: debian-bsd@lists.debian.org
Usertags: kfreebsd
X-Debbugs-Cc: debian-bsd@lists.debian.org
Hi,
tar FTBFS since 1.27-1 due to failure of extrac09.at in the testsuite.
The problem occurred only on kFreeBSD and Hurd but I could
I found this is caused by 'make' raising RLIMIT_STACK from the default
setting of 8192k to its maximum, 65536k. It is reproducible from the
shell by setting "ulimit -s 65536" before running the test program directly.
Thanks for the analysis!
I don't know if this is
Hi,
On 06/11/13 21:57, Steven Chamberlain wrote:
> I found this is caused by 'make' raising RLIMIT_STACK from the default
> setting of 8192k to its maximum, 65536k. It is reproducible from the
> shell by setting "ulimit -s 65536" before running the test program direc
e
shell by setting "ulimit -s 65536" before running the test program directly.
I don't know if this is an eglibc bug or expected behaviour (and
therefore a 'make' bug) so I am Cc'ing Petr.
In the successful case, creation of each thread involves an mmap of len
0x80
On 29/10/13 00:46, Emilio Pozuelo Monfort wrote:
> On 28/10/13 23:49, Steven Chamberlain wrote:
>> On 28/10/13 14:33, Emilio Pozuelo Monfort wrote:
>>> The test is trying to create 100 threads, but pthread_create returns EAGAIN
>>> because it hits some limit, which mak
On 28/10/13 23:49, Steven Chamberlain wrote:
> On 28/10/13 14:33, Emilio Pozuelo Monfort wrote:
>> The test is trying to create 100 threads, but pthread_create returns EAGAIN
>> because it hits some limit, which makes g_thread_new() abort (as stated in
>> the
>> docs,
On 28/10/13 14:33, Emilio Pozuelo Monfort wrote:
> The test is trying to create 100 threads, but pthread_create returns EAGAIN
> because it hits some limit, which makes g_thread_new() abort (as stated in the
> docs, g_thread_try_new() wouldn't abort but return NULL).
>
> The
On 21/10/13 15:54, Michael Biebl wrote:
> Source: pango1.0
> Version: 1.36.0-1
> Severity: serious
> User: debian-bsd@lists.debian.org
>
> pango1.0 FTBFS on kfreebsd-i386 when executing the test-suite:
>
> /«PKGBUILDDIR»/./test-driver: line 95: 41714 Trace/breakpoint trap
On 10/09/2013 11:14, Guillem Jover wrote:
> I'd also prefer to keep it separate. And I'd also keep non-kFreeBSD
> support, because even if the other kernels do not support UFS, you can
> use the tools to do some setup or recovery operations, which seem
> pretty handy to me (fsck, mkfs, etc).
>
> I
Source: pango1.0
Version: 1.36.0-1
Severity: serious
User: debian-bsd@lists.debian.org
pango1.0 FTBFS on kfreebsd-i386 when executing the test-suite:
/«PKGBUILDDIR»/./test-driver: line 95: 41714 Trace/breakpoint trap "$@" >
$log_file 2>&1
FAIL: test-pangocairo-threads
On Wed, 2013-10-09 at 23:25:16 +, Robert Millan wrote:
> Guillem Jover:
> > I'd have needed it to enable git for the project, and to create a git
> > repo for the bi-directional bridge, so that people who want to keep
> > using svn can do so, and anyone else that want to use git, can use
> > th
Robert Millan (2013-10-09):
> I'm not specially fond of this kind of proposals coming from people who
> are not actively involved with the port, but if it's useful in general
> and it doesn't prevent me from using SVN I have no objection with it.
>
> I suggest we wait a few days to see if everyon
Guillem Jover:
> I'd have needed it to enable git for the project, and to create a git
> repo for the bi-directional bridge, so that people who want to keep
> using svn can do so, and anyone else that want to use git, can use
> the bi-directional git-svn repo, from a better place than my home on
>
Hi!
On Wed, 2013-10-09 at 20:50:19 +, Robert Millan wrote:
> Guillem Jover:
> > I've now done a git-svn clone so that I can work with something saner,
> > and I'd put the repo in the project git space, so that others can use
> > it and do not need to do the initial conversion too, but I seem t
On 09/10/13 21:50, Robert Millan wrote:
> Guillem Jover:
>> I've now done a git-svn clone so that I can work with something saner,
>> and I'd put the repo in the project git space, so that others can use
>> it and do not need to do the initial conversion too, but I seem to have
>> lost the admin bi
Guillem Jover:
> I've now done a git-svn clone so that I can work with something saner,
> and I'd put the repo in the project git space, so that others can use
> it and do not need to do the initial conversion too, but I seem to have
> lost the admin bit "recently", so I guess I'll put it somewhere
Hi!
On Tue, 2013-09-10 at 16:10:44 +, Robert Millan wrote:
> Guillem Jover:
> > I'll look into updating to latest upstream preserving the current
> > support, hopefully in the coming days, been a bit busy lately, sorry!
>
> That's what you said in July! :-)
Indeed, and to be honest, one (but
Guillem Jover:
> I'd also prefer to keep it separate. And I'd also keep non-kFreeBSD
> support, because even if the other kernels do not support UFS, you can
> use the tools to do some setup or recovery operations, which seem
> pretty handy to me (fsck, mkfs, etc).
Well yes, I think we all agree t
Petr Salinger:
> Hi,
>
>> I made a little experiment to simplify ufsutils and make it easier to
>> update. By merging ufsutils into freebsd-utils package and using its
>> build environment, with recent freebsd-glue (0.1.4) it is now possible
>> to build ufsutils directly from pristine upstream sou
Hi!
On Mon, 2013-09-02 at 20:46:54 +, Robert Millan wrote:
> I made a little experiment to simplify ufsutils and make it easier to
> update. By merging ufsutils into freebsd-utils package and using its
> build environment, with recent freebsd-glue (0.1.4) it is now possible
> to build ufsutils
Hi,
I made a little experiment to simplify ufsutils and make it easier to
update. By merging ufsutils into freebsd-utils package and using its
build environment, with recent freebsd-glue (0.1.4) it is now possible
to build ufsutils directly from pristine upstream source:
I do not mind dropping
; within the test program that can trigger this problem itself sometimes.
>
SO_REUSEADDR is requested after bind(), though, which is broken.
Cheers,
Julien
signature.asc
Description: Digital signature
On 05/09/13 18:51, Julien Cristau wrote:
> I couldn't reproduce this on falla (ran make check a few times). Can a
> kfreebsd porter take a look?
It built successfully for me locally in a wheezy chroot and twice in a
sid chroot.
It seems test-poll tries to listen on 127.0.0.1:12
On Wed, Sep 4, 2013 at 02:04:10 +0200, Julien Cristau wrote:
> Source: libprelude
> Version: 1.0.0-11
> Severity: serious
> Justification: fails to build from source (but built successfully in the past)
> Control: block 712615 with -1
>
> Hi,
>
> libprelude FTBFS on the kfreebsd buildds, see th
Hi,
I made a little experiment to simplify ufsutils and make it easier to
update. By merging ufsutils into freebsd-utils package and using its
build environment, with recent freebsd-glue (0.1.4) it is now possible
to build ufsutils directly from pristine upstream source:
http://people.debian.org
ery welcome.
This test is guarded by:
/* This test doesn't work with GPollFileMonitor, because it assumes
* that the monitor will notice a create immediately followed by a
* delete, rather than coalescing them into nothing.
*/
if (!strcmp (G_OBJECT_TYPE_NAME (data-
On 02/07/13 11:12, Emilio Pozuelo Monfort wrote:
> Hi,
>
> On 20/06/13 18:41, Petr Salinger wrote:
>>> The test-suite for glib2.0 fails to complete on kfreebsd-* as can be
>>> seen at [1]. On both kfreebsd-amd64 and kfreebsd-i386 the test-suite is
>>> killed af
severity 710696 important
thanks
Temporarily downgraded the severity as I disabled the test suite on !linux as
this was blocking many packages from migrating to testing. I plan on re-enabling
the test suite again so let's keep this open. Any help on investigating it is
welcome.
On 16/06/13
Hi,
On 20/06/13 18:41, Petr Salinger wrote:
>> The test-suite for glib2.0 fails to complete on kfreebsd-* as can be
>> seen at [1]. On both kfreebsd-amd64 and kfreebsd-i386 the test-suite is
>> killed after 150 min of inactivity.
>
>> We would appreciate any help and i
The test-suite for glib2.0 fails to complete on kfreebsd-* as can be
seen at [1]. On both kfreebsd-amd64 and kfreebsd-i386 the test-suite is
killed after 150 min of inactivity.
We would appreciate any help and insight from the kfreebsd to fix those
failures on kfreebsd-*.
Some observations
Package: src:glib2.0
Version: 2.36.3-1
Severity: serious
User: debian-bsd@lists.debian.org
Usertags: kfreebsd
The test-suite for glib2.0 fails to complete on kfreebsd-* as can be
seen at [1]. On both kfreebsd-amd64 and kfreebsd-i386 the test-suite is
killed after 150 min of inactivity.
We would
nt) (S:bob) /noauth-> REQUEST CHALLENGE NTLM_RESPONSE -> OK
>>> ERROR: Not using built-in NTLM support, but authenticate signal was
>>> emitted
>
> These need further investigation. They may be a bug in libsoup, if something
> in
> libsoup is what is emitting
Hi,
Thanks for the info!
On 11/06/13 22:28, Steven Chamberlain wrote:
> Hi,
>
> On kfreebsd-* arches it is the lt-ntlm-test that doesn't finish and
> causes the build process to hang.
>
> In the buildd logs its output is not shown, probably being buffered
> somehow,
Hi,
On kfreebsd-* arches it is the lt-ntlm-test that doesn't finish and
causes the build process to hang.
In the buildd logs its output is not shown, probably being buffered
somehow, but running it manually it gets stuck here:
> External -> fallback support
> Round 1: Non-NTLM
Steven Chamberlain writes:
> On 07/02/13 14:05, Petr Salinger wrote:
>> It seems that it builds fine under 8.3 and 9.0 kernels from wheezy, while
>> it fails under 8.1 kernel from squeeze in otherwise same (kvm, almost
>> wheezy) kfreebsd-i386 environment.
>> The "export MALLOC_CHECK_=7" generates
On 07/02/13 14:05, Petr Salinger wrote:
> It seems that it builds fine under 8.3 and 9.0 kernels from wheezy, while
> it fails under 8.1 kernel from squeeze in otherwise same (kvm, almost
> wheezy) kfreebsd-i386 environment.
> The "export MALLOC_CHECK_=7" generates failure under 8.1 kernel reliable
On Thursday, February 07, 2013 03:05:47 PM Petr Salinger wrote:
> > I'd appreciate it if someone more familiar with kfreebsd than me would
> > have a look and see if they can understand better what's behind the
> > failure.
> It seems that it builds fine under 8.3 and 9.0 kernels from wheezy, while
On Thursday, February 07, 2013 03:05:47 PM Petr Salinger wrote:
> > I'd appreciate it if someone more familiar with kfreebsd than me would
> > have a look and see if they can understand better what's behind the
> > failure.
> It seems that it builds fine under 8.3 and 9.0 kernels from wheezy, while
I'd appreciate it if someone more familiar with kfreebsd than me would have a
look and see if they can understand better what's behind the failure.
It seems that it builds fine under 8.3 and 9.0 kernels from wheezy, while
it fails under 8.1 kernel from squeeze in otherwise same (kvm, almost
whe
On Wednesday, February 06, 2013 02:38:17 PM Christoph Egger wrote:
> Scott Kitterman writes:
> > On Wednesday, February 06, 2013 09:06:01 PM Petr Salinger wrote:
> >> > I tried it on kfreebsd-amd64 with build deps from wheezy/sid; no
> >> > failures happe
Scott Kitterman writes:
> On Wednesday, February 06, 2013 09:06:01 PM Petr Salinger wrote:
>> > I tried it on kfreebsd-amd64 with build deps from wheezy/sid; no
>> > failures happened in 100 runs of the test suite.
>>
>> For me it also builds fine inside sid
On Wednesday, February 06, 2013 09:06:01 PM Petr Salinger wrote:
> > I tried it on kfreebsd-amd64 with build deps from wheezy/sid; no
> > failures happened in 100 runs of the test suite.
>
> For me it also builds fine inside sid kfreebsd-amd64 chroot.
>
> It mig
Hi!
Steven Chamberlain writes:
> My first guess would be that some newer version of a build dependency
> from sid is causing it. I don't have access to the porter boxes but
> some things you could try are:
I'm pretty sure you could easily get access if it will help you in any
way[0].
Chris
On 06/02/13 19:44, Scott Kitterman wrote:
> The older package doesn't run the test suite at build, so the fact that it
> built for wheezy/sid doesn't tell us anything
Oh sorry, I misread your original mail... there's no point testing
older versions of opendkim then.
But
On Wednesday, February 06, 2013 06:35:27 PM Steven Chamberlain wrote:
> Hi,
>
> On 06/02/13 07:42, Scott Kitterman wrote:
> > Starting with the opendkim packages in
> > experimental, the package runs the test suite during build. Since I
> > started doing that, it has n
I tried it on kfreebsd-amd64 with build deps from wheezy/sid; no
failures happened in 100 runs of the test suite.
For me it also builds fine inside sid kfreebsd-amd64 chroot.
It might be also due to kernel difference, I use the current wheezy
kernel 9.0, while the buildd uses older 8.1 one
Hi,
On 06/02/13 07:42, Scott Kitterman wrote:
> Starting with the opendkim packages in
> experimental, the package runs the test suite during build. Since I started
> doing that, it has never built on kfreebsd-i386 and intermittently failed on
> kfreebsd-amd64.
I tried it on kf
have another problem. Starting with the opendkim packages in
experimental, the package runs the test suite during build. Since I started
doing that, it has never built on kfreebsd-i386 and intermittently failed on
kfreebsd-amd64.
Once I got the test failures on other architectures resolved, I
retitle 628383 [kfreebsd-*] test failure: test-secmem
found 628383 3.4.1-1
thanks
Hi,
I've just reviewed/tested that this issue was still present in the
latest build, but libgnome-keyring no longer FTBFS since it ignores the
test failure (adjusting bug title accordingly).
Regards,
--
S
retitle 663056 [kfreebsd-*] test failure: context-test
thanks
Hi,
Just to review/clarify this bug, libsoup2.4 no longer FTBFS on
kfreebsd-* because test failures are ignored (therefore adjusting the
title).
connection-test was previously failing, but at least on kfreebsd-i386 it
seems fixed
before the first test has been run.
>
> This small Ruby testcase results in segfault 50% of the time under
> ruby1.8 1.8.7.358-2, but always succeeds with ruby1.9.1 1.9.3.0-2:
>
> > require 'thread'
> > Thread.new do
> > foo = "bar"
> > e
1 - 100 of 240 matches
Mail list logo
