Your message dated Wed, 21 Dec 2022 02:32:32 +0100
with message-id <58342c07-f2a5-3e67-0c66-006eed51e...@free.fr>
and subject line libreoffice: FTBFS[kfreebsd-*]; tests hang in sw_macros_test
with FreeBSD 10
has caused the Debian Bug report #801865,
regarding libreoffice: FTBFS on kf
[non-subscriber, please keep in CC]
Greetings,
src:dhcpcd5 encounters an FTBFS on both kfreebsd ports. Help for
fixing this is welcome.
Thanks!
Martin-Éric
Package: src:gcc-11
Version: 11.2.0-5
Severity: important
X-Debbugs-CC: debian-bsd@lists.debian.org
gcc-11 ftbfs on kfreebsd-*, strange tar behavior:
[...]
mkdir -p debian/tmp-jit/usr/lib/x86_64-kfreebsd-gnu
mkdir -p debian/tmp-jit/usr/lib/gcc/x86_64-kfreebsd-gnu/11/include
mv debian/tmp-jit/usr
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
Source: dnsmasq
Version: 2.80-1.1
Severity: important
Tags: ftbfs patch
Justification: fails to build from source (but built successfully in the past)
User: debian-bsd@lists.debian.org
Usertags: kfreebsd
Hello,
Since 2.80-1.1, dnsmasq FTBFS on kfreebsd:
x86_64-kfreebsd-gnu-gcc -Wl,-z,relro -Wl
On 2 Jul 2019, at 20:15, Michael Biebl wrote:
>
> Hi James
>
> Am 02.07.19 um 20:55 schrieb James Clarke:
>> Control: reopen -1
>>
>>> On 2 Jul 2019, at 19:53, Michael Biebl wrote:
>>>
>>> On Tue, 12 May 2015 13:38:12 +0200 Michael Biebl wrote:
Source: rsyslog
Version: 8.9.0-3
Hi James
Am 02.07.19 um 20:55 schrieb James Clarke:
> Control: reopen -1
>
>> On 2 Jul 2019, at 19:53, Michael Biebl wrote:
>>
>> 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
>>> Us
Control: reopen -1
> On 2 Jul 2019, at 19:53, Michael Biebl wrote:
>
> 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 fa
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 failures in the test-suite:
>
>
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
Hi,
Il 14/11/18 10:00, Emilio Pozuelo Monfort ha scritto:
> libs/fiber/src/numa/freebsd/pin_thread.cpp:13:10: fatal error: sys/thread.h:
> No such file or directory
freebsd/pin_thread.cpp is basically a wrapper over cpuset_setaffinity,
while linux/pin_thread.cpp is the same wrapper over
pthread_
Source: boost1.67
Version: 1.67.0-9
Severity: important
Hi,
boost1.67 fails to build on kbsd:
...failed updating 2 targets...
...skipped 6 targets...
...updated 1912 targets...
debian/rules:50: recipe for target 'override_dh_auto_build' failed
This may be due to these earlier errors:
"g++"
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
On Thu, 2018-05-03 at 14:59 +0100, James Clarke wrote:
> On 3 May 2018, at 09:21, Svante Signell
> wrote:
> > On Wed, 2018-05-02 at 12:51 +0100, James Clarke wrote:
> > > Control: reassign -1 gcc-7
> > > Control: retitle -1 gcc: Decimal float support is not enabled on
> > > kfreebsd-
> > > amd64
>
e Signell wrote:
>>>
>>> Source: mpfr4
>>> Version: 4.0.1-1
>>> Severity: important
>>> Tags: patch
>>> User: debian-bsd@lists.debian.org
>>> Usertags: kfreebsd
>>>
>>> Hi,
>>>
>>> mpfr4 FTBFS on kFreeb
> > Severity: important
> > Tags: patch
> > User: debian-bsd@lists.debian.org
> > Usertags: kfreebsd
> >
> > Hi,
> >
> > mpfr4 FTBFS on kFreebsd-amd64 due to mismatches in the
> > debian/libmpfr6.symbols
> > file. Attached is a file wi
[Cc mpfr list]
On 2018-05-02 13:45:30 +0200, Vincent Lefevre wrote:
> and in the configure output:
>
> checking if compiler knows _Decimal64... no
Note that it is "yes" for kfreebsd-i386:
https://buildd.debian.org/status/fetch.php?pkg=mpfr4&arch=kfreebsd-i386&ver=4.0.1-1&stamp=1523420566&raw
On 2018-05-02 11:38:14 +0200, Svante Signell wrote:
> mpfr4 FTBFS on kFreebsd-amd64 due to mismatches in the debian/libmpfr6.symbols
> file. Attached is a file with the symbols generated from the build:
> libmpfr6.symbols.kfreebsd-amd64.
This is due to:
--- debian/libmpfr
ags: kfreebsd
>
> Hi,
>
> mpfr4 FTBFS on kFreebsd-amd64 due to mismatches in the debian/libmpfr6.symbols
> file. Attached is a file with the symbols generated from the build:
> libmpfr6.symbols.kfreebsd-amd64.
>
> Thanks!
You're right that the symbols file is curr
Source: mpfr4
Version: 4.0.1-1
Severity: important
Tags: patch
User: debian-bsd@lists.debian.org
Usertags: kfreebsd
Hi,
mpfr4 FTBFS on kFreebsd-amd64 due to mismatches in the debian/libmpfr6.symbols
file. Attached is a file with the symbols generated from the build:
libmpfr6.symbols.kfreebsd
On 30.04.2018 21:26, James Clarke wrote:
Hi,
> Yeah, please file it against kfreebsd-10 and glibc; either the
> prototype should disappear from the headers or it should be
> implemented.
>
Thanks! I've filed #897335. This bug here will be closed upon next
upload of proftp, fix/workaround is in g
On 30 Apr 2018, at 19:22, Hilmar Preuße wrote:
> On 30.04.2018 13:17, James Clarke wrote:
>> On 29 Apr 2018, at 22:06, Hilmar Preuße wrote:
>>> On 29.04.2018 14:01, Hilmar Preuße wrote:
>
> Hi James,
>
>>> I just noticed that our package fails to build on kfreebsd:
>>>
>>> https://buildd.debia
On 30.04.2018 13:17, James Clarke wrote:
> On 29 Apr 2018, at 22:06, Hilmar Preuße wrote:
>> On 29.04.2018 14:01, Hilmar Preuße wrote:
Hi James,
>> I just noticed that our package fails to build on kfreebsd:
>>
>> https://buildd.debian.org/status/fetch.php?pkg=proftpd-dfsg&arch=kfreebsd-amd64&ve
On 29 Apr 2018, at 22:06, Hilmar Preuße wrote:
>
> On 29.04.2018 14:01, Hilmar Preuße wrote:
>
> Hi debian-bsd people,
>
> I just noticed that our package fails to build on kfreebsd:
>
> https://buildd.debian.org/status/fetch.php?pkg=proftpd-dfsg&arch=kfreebsd-amd64&ver=1.3.6-2&stamp=152499694
On 29.04.2018 14:01, Hilmar Preuße wrote:
Hi debian-bsd people,
I just noticed that our package fails to build on kfreebsd:
https://buildd.debian.org/status/fetch.php?pkg=proftpd-dfsg&arch=kfreebsd-amd64&ver=1.3.6-2&stamp=1524996945&raw=0
Could you help us here? proftp seems to build on FreeBSD
On Thu, 2017-12-14 at 03:56 +0100, Timur I. Bakeyev wrote:
> Hi, Andrew!
>
> Sure, I can do the follow-up. Shall we continue on the samba-technical or
> there is a more dedicated list for CTDB developers?
samba-technical is the spot.
Andrew Bartlett
--
Andrew Bartlett
https://samba.org/~abar
Hi, Andrew!
Sure, I can do the follow-up. Shall we continue on the samba-technical or
there is a more dedicated list for CTDB developers?
With best regards,
Timur
On Wed, Dec 13, 2017 at 6:50 AM, Andrew Bartlett wrote:
> On Wed, 2017-12-13 at 06:03 +0100, Timur I. Bakeyev wrote:
> > Hi, guys!
On Wed, 2017-12-13 at 06:03 +0100, Timur I. Bakeyev wrote:
> Hi, guys!
(skip really helpful background)
> I wonder, would it be possible to replace getsockopt(2) here with the
> sendmsg()/recvmsg() and 'SCM_CREDS' type of message, like described
> here, for ex:
>
> https://davejingtian.org/2015/
rtant
> > User: debian-bsd@lists.debian.org
> > Usertags: kfreebsd
> >
> > Hi,
> >
> > that 4.7.x uploads of samba FTBFS on kfreebsd:
>
> > [2706/4004] Compiling ctdb/tests/src/ipalloc_read_known_ips.c
> > 08:44:02 runner /usr/bin/gcc -g -O2
&g
On Sat, 2017-12-09 at 23:04 +0100, Andreas Beckmann wrote:
> Source: samba
> Version: 2:4.7.3+dfsg-1
> Severity: important
> User: debian-bsd@lists.debian.org
> Usertags: kfreebsd
>
> Hi,
>
> that 4.7.x uploads of samba FTBFS on kfreebsd:
> [2706/
Package: ioquake3
Version: 1.36+u20170611+dfsg1-1
Severity: wishlist
Tags: help
ioquake3 fails to build from source on kfreebsd-amd64 (but not on either
Linux amd64 or kfreebsd-i386) with the following linker error:
cc -D_REENTRANT -I/usr/include/SDL2 -I/usr/include/x86_64-kfreebsd-gnu
-DUSE_OPE
Source: grub2
Source-Version: 2.02~beta3-1
On Sat, Nov 26, 2016 at 09:56:46PM +0100, Cyril Brulebois wrote:
> Colin Watson (2016-11-26):
> > Yep, as Thomas said, this changed back to the original state in
> > 2.02~beta3. I think that in fact allows us to close #741656 if you also
> > revert your
Colin Watson (2016-11-26):
> Yep, as Thomas said, this changed back to the original state in
> 2.02~beta3. I think that in fact allows us to close #741656 if you also
> revert your previous workaround in d-i, but please confirm. Compare:
>
>
> https://anonscm.debian.org/cgit/pkg-grub/grub.gi
On Sat, Nov 26, 2016 at 06:17:28AM +0100, Cyril Brulebois wrote:
> kfreebsd-* builds are now failing to build with:
> | # Create the ISO with Joliet extensions, needed for win32-loader.ini
> | # NOTE: "-- -J" is a workaround for #741656 in grub-common
> | grub-mkrescue --output=./tmp/netboot-10/min
Cyril Brulebois (2014-03-16):
> Control: severity -1 important
>
> Colin Watson (2014-03-15):
> > On Sat, Mar 15, 2014 at 12:37:17PM +0100, Cyril Brulebois wrote:
> > > I'm tempted to commit the '--' addition in debian-installer for now
> > > anyway, including a comment pointing here, and to low
On Thu, Sep 08, 2016 at 03:20:17PM +0200, Andreas Boll wrote:
> Control: retitle -1 libdrm: FTBFS on kfreebsd-*: drm.h: bad #include choices
> Control: tags -1 help upstream
> Control: user debian-bsd@lists.debian.org
> Control: usertags -1 kfreebsd
>
> On Wed, Sep 07, 2016 a
and nmu those binaries. It doesn't
> > fix the bug, would come back again with the next build, but it should
> > fix *many* reverse-deps that are FTBFS or BD-Uninstallable waiting for a
> > newer cmake.
>
> I did that, but now apt FTBFS on kfreebsd-* with this test fa
t; fix *many* reverse-deps that are FTBFS or BD-Uninstallable waiting for a
> newer cmake.
I did that, but now apt FTBFS on kfreebsd-* with this test failure:
https://buildd.debian.org/status/fetch.php?pkg=apt&arch=kfreebsd-amd64&ver=1.3.1&stamp=1478121955
| [ RUN ] FileUtlTe
Control: clone -1 -2
Control: clone -1 -3
Control: affects -2 libxslt
Control: affects -3 libxslt
Control: block -1 by -2
Control: block -1 by -3
Control: retitle -2 should flush timestamps early enough
Control: retitle -3 should flush timestamps early enough
Control: reassign -2 hurd
Control: reas
Processing control commands:
> clone -1 -2
Bug #840096 [libxslt] libxslt: FTBFS on kfreebsd and hurd: ld: cannot find
-lxslt, -lexslt
Bug 840096 cloned as bug 842271
> clone -1 -3
Bug #840096 [libxslt] libxslt: FTBFS on kfreebsd and hurd: ld: cannot find
-lxslt, -lexslt
Bug 840096 cloned
Package: src:vim
Version: 2:8.0.0022-1
Severity: important
User: debian-bsd@lists.debian.org
Usertags: kfreebsd
Hi!
vim FTBFS on kfreebsd-* due to testsuite failures (see below) which
also breaks bootstrap of porterbox chroots.
Christoph
6 FAILED:
Found errors in Test_command_count_2
Hi!
Julian Andres Klode wrote:
> Any update on this? This bug is preventing the kFreeBSD platforms
> from getting a newer APT version, as APT requires cmake (>= 3.4)
> to build. Because of this, APT is at 1.3~pre3 from two months
> ago, whereas the other platforms are at 1.3.1 already.
There is a
practice for headers to #include anything they
need, to keep things simple for their reverse dependencies. FWIW, I
noticed this problem when looking into a libcmrt FTBFS on kFreeBSD:
libtool: compile: g++ -DHAVE_CONFIG_H -I. -I../../src -D_DEBUG -DPTHREADS
-I/usr/include/libdrm -I/src/cmr
Control: retitle -1 libdrm: FTBFS on kfreebsd-*: drm.h: bad #include choices
Control: tags -1 help upstream
Control: user debian-bsd@lists.debian.org
Control: usertags -1 kfreebsd
On Wed, Sep 07, 2016 at 09:08:30PM -0400, Aaron M. Ucko wrote:
> Source: libdrm
> Version: 2.4.70-1
>
Tags: 834864 + patch
User: debian-bsd@lists.debian.org
Usertags: kfreebsd
Hello,
The hisat2 binary actually had this problem on kfreebsd:
| $ ./hisat2
| (ERR): Expected hisat2 to be in same directory with hisat-align:
| /build/hisat2-2.0.4/
| Exiting now ...
which happens because it looks for a
tags 826061 + patch
user debian-bsd@lists.debian.org
usertags 826061 + kfreebsd
thanks
Hello,
Andreas Beckmann wrote:
> src/event/ngx_event_accept.c:65:17: warning: implicit declaration of function
> 'accept4' [-Wimplicit-function-declaration]
> src/event/ngx_event_accept.c:348:55: error: invali
[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 in main.c sh
Hello!
Thanks for looking into this. It is probably specific to UFS (not ZFS)
and maybe only when soft-updates are enabled (which is default, and I
think enabled on the buildds). It defers writing of some metadata to
disk until the next sync or after some time has elapsed.
> [Andreas Henriksson
[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
Hello Petter Reinholdtsen.
(Adding debian-bsd list to CC...)
Thank you very much for looking into this issue!
On Sat, Jun 25, 2016 at 11:59:07AM +0200, Petter Reinholdtsen wrote:
> Control: tags -1 + patch
>
> [Simon McVittie]
> > As already reported to debian-bsd by the libarchive maintainer,
Package: bmon
Version: 1:3.8-2
Followup-For: Bug #826836
Hi,
In upstream code for BSD-ish systems, support was added for some Apple
Darwin features that are not available on other platforms.
Please find a patch attached for this. I've run-time tested it on
kfreebsd-amd64 and it works beautifull
Source: libarchive
Version: 3.2.0-1
Severity: important
Tags: upstream
User: debian-bsd@lists.debian.org
Usertags: kfreebsd
X-Debbugs-Cc: debian-bsd@lists.debian.org
As already reported to debian-bsd by the libarchive maintainer,
libarchive 3.2.0 fails to build from source on kFreeBSD due to this
Hello kfreebsd porters!
I've recently uploaded a new upstream release of libarchive (3.2.0) to
experimental. Apparently there's a regression on kfreebsd where one of
the tests now fails and we thus get FTBFS on kfreebsd-*.
Unfortunately the details of the failing test is not availa
reopen 802621 =
found 802621 samba/4.2.10+dfsg-0+deb8u2
thanks
Hi,
Unfortunately this patch was not included in what security team
uploaded. It was also not pulled into the +deb8u2 regression update
either.
In the build log below, of samba/4.2.10+dfsg-0+deb8u2 for
jessie-kfreebsd, there is no c
Hi,
I set up a UFS filesystem to build on, but could not reproduce the bug.
Please could someone try the attached diff? If it fails, please share
the exact error (does it fail at the -build1 step or at -build2?), and
because the `ls` I added will show the file timestamps, to help debug.
This is
Source: libvigraimpex
Version: 1.10.0+git20160211.167be93+dfsg-1
Severity: important
Your package failed to build on hurd and kfreebsd-i386:
Entering test suite GraphAlgorithmTestSuite
Failure in GraphAlgorithmTest::testEdgeWeightComputation()
Assertion failed: Sequence items differ at index 5 [
Brad King wrote:
> FYI, the IS_NEWER_THAN check actually documents that it returns true
> when the times are exactly equal:
Thanks for pointing that out!
I suppose it is not working as expected, then, but I can't see why.
kfreebsd does have st_mtim, and the code for that looks right to me:
https:
Hi,
I've tried looking at this from the other direction -- on ZFS
with high-resolution timestamps, I'm trying to find a way to reproduce
the issue as seen on the Debian buildds.
Here are timestamps in Build/Tests/RunCMake/Configure/RerunCMake-build/
right after `file(WRITE "${input}" "2")`, norma
On 04/06/2016 05:42 PM, Steven Chamberlain wrote:
> | if(${BuildDepends_BINARY_DIR}/Project/multi2-real.txt
> | IS_NEWER_THAN ${BuildDepends_BINARY_DIR}/Project/multi2-stamp.txt)
>
> If multi2-real.txt and multi2-stamp.txt are created within 1 second of
> each other, the test will most lik
Samuel Thibault wrote:
> BTW, you may find
> set abort_noattach=ask-yes
>
> useful in .muttrc :)
Thanks! I will try that. And maybe more sleep, or coffee.
Patch might be attached.
Regards,
--
Steven Chamberlain
ste...@pyro.eu.org
--- a/Tests/RunCMake/Configure/RunCMakeTest.cmake
+++ b/Tests
Samuel Thibault, on Thu 07 Apr 2016 13:07:18 +0200, wrote:
> Steven Chamberlain, on Thu 07 Apr 2016 11:54:26 +0100, wrote:
> > Samuel Thibault wrote:
> > > Nothing was attached :)
> >
> > Sorry - attached!
>
> Mmm, nope :)
BTW, you may find
set abort_noattach=ask-yes
useful in .muttrc :)
Sam
Steven Chamberlain, on Thu 07 Apr 2016 11:54:26 +0100, wrote:
> Samuel Thibault wrote:
> > Nothing was attached :)
>
> Sorry - attached!
Mmm, nope :)
Samuel
Samuel Thibault wrote:
> Nothing was attached :)
Sorry - attached!
Christoph found that increasing some of these sleeps to 3 seconds
allowed the test to pass *some* of the time.
The first sleep in Tests/RunCMake/Configure/RunCMakeTest.cmake should
make CustomCMakeOutput.txt newer than CustomCMak
Steven Chamberlain, on Thu 07 Apr 2016 01:47:58 +0100, wrote:
> Christoph Egger wrote:
> > Start 284: RunCMake.Configure
> > 284/371 Test #284: RunCMake.Configure
> > ...***Failed3.19 sec
>
> I have a wild idea what might be happening here. Please could yo
Hi,
> Steven Chamberlain writes:
> > Could someone with access to the hurd-i386 or kfreebsd porter boxes
> > try the attached patch please?
Christoph Egger wrote:
> Start 284: RunCMake.Configure
> 284/371 Test #284: RunCMake.Configure
> ...***Failed3.19 s
Steven Chamberlain writes:
> Steven Chamberlain wrote:
>> Could someone with access to the hurd-i386 or kfreebsd porter boxes
>> try the attached patch please?
>
> Here's how to run that test on its own, verbosely, in an already-built
> Debian build tree:
>
> $ Build/bin/cmake "-DCMAKE_MODULE_
Hi
FWIW on the 3.2 build (with the patch) I started untill I noticed it
wasn't quite the right version
Steven Chamberlain writes:
> Andreas Beckmann wrote:
>> 292 - RunCMake.Configure (Failed)
>
> Could someone with access to the hurd-i386 or kfreebsd porter boxes
> try the attached patch p
Steven Chamberlain wrote:
> Could someone with access to the hurd-i386 or kfreebsd porter boxes
> try the attached patch please?
Here's how to run that test on its own, verbosely, in an already-built
Debian build tree:
$ Build/bin/cmake "-DCMAKE_MODULE_PATH=Tests/RunCMake"
"-DRunCMake_GENERA
Hi,
Andreas Beckmann wrote:
> 292 - RunCMake.Configure (Failed)
Could someone with access to the hurd-i386 or kfreebsd porter boxes
try the attached patch please?
Thanks,
Regards,
--
Steven Chamberlain
ste...@pyro.eu.org
--- a/Tests/RunCMake/Configure/RunCMakeTest.cmake
+++ b/Tests/RunCMa
Hi,
Andreas Beckmann wrote:
> The following tests FAILED:
> 113 - BuildDepends (Failed)
I finally figured this out!
The BuildDepends test will fail when run on a filesystem not having
sub-second granularity. So for example, it fails on kfreebsd UFS, and
whatever filesystem the hurd-i386 b
Hi,
Ximin Luo wrote:
> Hey Steven, thanks for the patch. Just to confirm, it's not going to
> interfere with the i386 build is it? I guess the current successful
> kfreebsd-i386 build must have been against older libraries, and would
> fail now against the current libraries, if I don't apply this
Package: src:git
Severity: important
Version: 1:2.8.0~rc3-1
X-Debbugs-Cc: debian-bsd@lists.debian.org
User: debian-bsd@lists.debian.org
Usertag: kfreebsd
Hi!
git fails the testsuite on kfreebsd currently. This seems to be
reproducible with sid chroots on my stable/ufs system but not on my
noteboo
Steven Chamberlain:
> Steven Chamberlain wrote:
>> I've attached a quick and easy fix for this, but it's not suitable to go
>> upstream.
>
> Oops, attached now.
>
Hey Steven, thanks for the patch. Just to confirm, it's not going to interfere
with the i386 build is it? I guess the current succes
Steven Chamberlain wrote:
> I've attached a quick and easy fix for this, but it's not suitable to go
> upstream.
Oops, attached now.
Thanks,
Regards,
--
Steven Chamberlain
ste...@pyro.eu.org
--- a/configure.in
+++ b/configure.in
@@ -88,7 +88,7 @@
AC_MSG_CHECKING(bktr headers in /usr/include/
tags 817757 + patch
user debian-bsd@lists.debian.org
usertags 817757 + kfreebsd
thanks
Hi!
Andreas Beckmann wrote:
> motion FTBFS on kfreebsd-amd64 (but not on kfreebsd-i386), after
> the -6 and -7 versions successfully built there:
> https://buildd.debian.org/status/fetch.php?pkg=mo
Processing commands for cont...@bugs.debian.org:
> clone 815265 -1
Bug #815265 [src:kinect-audio-setup] kinect-audio-setup: FTBFS on kfreebsd:
implicit declaration of function 'libusb_set_auto_detach_kernel_driver'
Bug 815265 cloned as bug 816031
> reassign -1 libusb2-dev
Bug #81
clone 815265 -1
reassign -1 libusb2-dev
found -1 libusb2-dev/10.1~svn273304-1
retitle -1 libusb2-dev: please add libusb_set_auto_detach_kernel_driver
block 815265 by -1
thanks
Antonio Ospite wrote:
> This is the libusb0.1 compat header, the one for libusb-1.0 seems to be
> http://svnweb.freebsd.or
On Sun, 21 Feb 2016 00:38:06 +
Steven Chamberlain wrote:
> Hello,
>
Hi Steven,
> Antonio Ospite wrote:
> > libusb_set_auto_detach_kernel_driver() is available in libusb-1.0 since
> > v1.0.16 dated 2013-07-11, according
> > to /usr/share/doc/libusb-1.0-0/changelog.gz
> >
> > I see that the
Nikolaus Rath wrote:
> What the heck. I don't want to take too much of your time, I'll try to
> get access to a kfreebsd machine to look into this directly.
Equally, if you think there is not much chance of it working on kfreebsd
we could request ftpmaster removal instead. But, FUSE is available
On Feb 22 2016, Steven Chamberlain wrote:
> Nikolaus Rath wrote:
>> Ah, ok. I guess it gives non-zero exact status if it doesn't find any
>> tests to run at all.
>>
>> So the next question is why is it finding only one test, and why is it
>> skipping that one.
>>
>> * Is there a "fusermount" exe
Nikolaus Rath wrote:
> Ah, ok. I guess it gives non-zero exact status if it doesn't find any
> tests to run at all.
>
> So the next question is why is it finding only one test, and why is it
> skipping that one.
>
> * Is there a "fusermount" executable available on kfreebsd?
No, but there is a m
Hi,
> Patrick Matthäi wrote:
> > Thanks for your explaination. So we know now, that it is not easy
> > fixable within the mlt source code.
> >
> > @Dan:
> > Would you merge his patch?
I didn't really intend for my patch to go upstream. It is a rushed fix
until GNU libc headers or some other kfr
Hi,
I've tried 4.1.4-4 in a clean sid chroot on kfreebsd-amd64.
László Böszörményi (GCS) wrote:
> Strange that it's being run on your machine;
> disable-test_security_curve.patch disables this unconditionally. :-0
In 4.1.4-3, I don't think the patch was applied, and dpkg-source did not
run quilt
> $ py.test-3 -s test/ ; echo exit status $?
> == test session starts
> ===
> platform gnukfreebsd10 -- Python 3.4.4rc1, pytest-2.8.5, py-1.4.31,
> pluggy-0.3.1 -- /usr/bin/python3
> cachedir: test/.cache
> ro
Hi,
Nikolaus Rath wrote:
> This looks odd.. something fails, but I don't actually see any error
> message (skipping a test shouldn't result in a test failure). Is this
> from a buildd or from your local system?
>
> In the latter case, can you try running 'py.test-3 -s test/' directly to
> see if
Hi,
Georges Khaznadar wrote:
> /usr/lib/python*/distutils/sysconfig.py files are part of the packages
> libpython*-stdlib; a build-dependency on libpython-stdlib should not
> harm.
I have that package already installed, so maybe something in my chroot
was out-of-date. It is probably not kicad's
Steven Chamberlain wrote:
> I used a messy sid chroot, maybe with some outdated or extra packages in
> there. I'll try again in a clean sid chroot.
Done that, and I still *usually* get all tests pass on kfreebsd-amd64.
The buildd environment should be basically the same.
I get random failures ab
Hi,
László Böszörményi (GCS) wrote:
> On Mon, Feb 22, 2016 at 4:30 AM, Steven Chamberlain
> wrote:
> > It was just a missing #include. Please find patch attached
> > (sys_ucred_h.patch).
> Thanks, this looks sane. Would you submit it to upstream or should I do it?
Maybe it is a good time that
tags 815495 + patch
user debian-bsd@lists.debian.org
usertags 815495 + kfreebsd
thanks
Hello,
Aaron M. Ucko wrote:
> Builds of zeromq3 for kFreeBSD are now failing with
>
> src/ipc_listener.cpp: In member function 'bool
> zmq::ipc_listener_t::filter(zmq::fd_t)':
> src/ipc_listener.cpp:263:1
tags 815501 + patch
user debian-bsd@lists.debian.org
usertags 815501 + kfreebsd
thanks
Hi,
Andreas Beckmann wrote:
> starting with version 6 mlt FTBFS on kfreebsd-i386 and kfreebsd-amd64:
> https://buildd.debian.org/status/fetch.php?pkg=mlt&arch=kfreebsd-amd64&ver=6.0.0-2&am
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,
On 21.02.2016 22:30, Steven Chamberlain wrote:
> tags 815242 + patch
> user debian-bsd@lists.debian.org
> usertags 815242 + kfreebsd
> thanks
>
> Hi,
>
> Andreas Beckmann wrote:
>> src/cxx_supportlib/BackgroundEventLoop.cpp:198:6: error: #error "This
>> platform is not supported. Please add
uot;This platform is not supported. Please add corresponding I/O
> polling code."
That problem is very easily fixed with the attached patch.
This patches fixes one other issue in psg_sysqueue.h also.
There is one remaining issue causing FTBFS on kfreebsd but I will open a
separate bug rep
Steven Chamberlain wrote:
> the TSC clock!? *omg* Is that really a good entropy source?
stunRand() takes the 32 LSBs from the TSC, on x86 machines. It is a
CPU cycle counter. These 32 bits seems to wrap around every 10-60
seconds or so, depending on clock speed. Apart from that, they maybe do
tags 815442 + security
retitle 815442 stun: seeds RNG from TSC clock?
thanks
Hi,
Andreas Beckmann wrote:
> stun FTBFS on kfreebsd-amd64 (but it built there previously and it
> also builds on kfreebsd-i386):
> [...]
> stun.cxx:681:7: error: #error Need some way to seed the r
tags 815445 + patch
user debian-bsd@lists.debian.org
usertags 815445 + kfreebsd
thanks
Hi Wouter,
Thanks for fixing this bug upstream.
Wouter Verhelst wrote:
> I intend to update nbd to a more recent version some time before the
> freeze to include these fixes, but that require a full upstream r
tags 815247 + patch
user debian-bsd@lists.debian.org
usertags 815247 + kfreebsd
thanks
Hello,
Andreas Beckmann wrote:
> kicad FTBFS on hurd-i386 and kfreebsd-i386, kfreebsd-amd64:
> [...]
> /«BUILDDIR»/kicad-4.0.2+dfsg1/common/single_top.cpp:70:26: error:
> 'LIB_ENV_VAR' was not declared in this
tags 815283 + patch
user debian-bsd@lists.debian.org
usertags 815283 + kfreebsd
thanks
Hi,
Andreas Beckmann wrote:
> /«PKGBUILDDIR»/src/openvpn/tun.c:1141: undefined reference to
> `create_arbitrary_remote'
This is super-easy to fix. Please append the attached to
kfreebsd_support.patch
Thanks
tags 815266 + patch
user debian-bsd@lists.debian.org
usertags 815266 + kfreebsd
thanks
Andreas Beckmann wrote:
> make[1]: Leaving directory '/«PKGBUILDDIR»/build'
>dh_install -a -O--sourcedirectory=host -O--builddirectory=build
> dh_install: libhackrf-dev missing files (usr/lib/*/pkgconfig/*),
1 - 100 of 663 matches
Mail list logo
