Ok, with the following patch it builds:
#v+
% cat debian/patches/kfreebsd.patch
--- a/src/osflags
+++ b/src/osflags
@@ -38,6 +38,9 @@
[ -e /usr/include/systemd/sd-daemon.h ] FLAGS=$FLAGS
-DHAVE_SYSTEMD;
echo $FLAGS;
;;
+ GNU/kFreeBSD)
+ echo
Question to the porters: should we build ncurses with sysmouse support?
If it actually works that seems useful, but the GNU/kFreeBSD FAQ is
currently silent on mouse topics.
So far we do not support moused,
and therefore sysmouse interface will not work [1].
Please disable this support
Since upstream plans making a new release this weekend I wanted to
speed up fixing all the FTBFS-s by asking for help.
The fix have to be different one - sockaddr6_in - sockaddr_in6:
--- lib/socket.c~
+++ lib/socket.c
@@ -506,7 +506,7 @@
((struct
Thanks, I have updated the pull request.
Can libnfs build on kfreebsd with this fix or there are other issues?
It builds fine.
Petr
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
I looked into config.log, the signature of some library call
in miniupnpc have been changed (addeded argument), I do not remeber name.
The easiest solution might be to upload current Transmission 2.84,
as upstream changelog for 2.83 says:
Updated third party libraries: DHT updated to v0.22;
As a result, it tries to use embedded version
from transmission-2.82/third-party/miniupnp/
Oh, that explains it then! Thanks for the details.
Do you know why it's not finding the libminiupnpc-dev bindings in the
configure script? I'll try to find the time investigate later on.
I looked into
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.
The patch seems be fine.
Or kfreebsd.h
Package: transmission
Your package failed to build on kfreebsd:
In fact, the problem is sligthly different.
The transmission package does not support newly supplied
libminiupnpc-dev under both Linux and kFreeBSD:
checking supported miniupnp library... none
As a result, it tries to use
I'm not sure if the file should be built on kfreebsd/hurd, or if it shouldn't
but there should be some fallback code in python3.4. Adding the python
maintainer, and the bsd and hurd porters to Cc.
checking on falla, the failing autoconf test is
#include unistd.h
#include fcntl.h
#include
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
Hi.
Did you manage to figure something additional out? Do we know if this
also kills plain freebsd?
I'm afraid I'm stuck with this.
I narrowed it down to that particular test (or prerequisites of the
test) when executed by the GCC testsuite. A large chroot is needed,
having all the GCC
Do you have any news on this bug? It is severely affecting *all* GCC
versions and prevents new versions of them from migrating to testing.
I tested it:
system up-to-date jessie, with kfreebsd-image-10.0-1-amd64/10.0-4
chroot up-to-date sid, building of gcc-4.6 4.6.4-6 rebooted the system.
It
Petr, I would really appreciate a patch for trafficserver with the
prototype to fix this bug, until your fix for eglibc is available in
unstable.
Workaround for trafficserver:
--- lib/ts/ink_thread.h
+++ lib/ts/ink_thread.h
@@ -310,6 +310,12 @@
// This define is from Linux's sys/prctl.h and
Oh, and you don't mention utimensat, but I presume it has the same
problem (coming from the same manpage and all)?
You are right, exactly the same problem, similarly,
the microsecond variant futimesat() is available.
Please do, whatever you comfortable with, given it is available on
kfreebsd
Package: apt
Version: 0.9.15.1
Severity: serious
User: debian-...@lists.debian.org
Usertags: kfreebsd
The apt 0.9.15.1 started to use futimens instead of previous utime.
The futimens() is not supported on kfreebsd.
The kfreebsd does have:
int utime(const char *filename, const struct utimbuf
ulimit -S of stack size:
linux-i386: 8 MB
linux-amd64:8 MB
kfreebsd-i386: 8 MB
kfreebsd-amd64: 8 MB
ulimit -H of stack size:
linux-i386: unlimited
linux-amd64:unlimited
kfreebsd-i386: 64 MB
kfreebsd-amd64: 512 MB
***
From {nptl/fbtl}/nptl-init.c
Control: found -1 8.22-1
Still the same core problem - d_namlen (not d_namelen).
Petr
--- modules/network/serv_netspool.c
+++ modules/network/serv_netspool.c
@@ -983,7 +983,7 @@
(filedir_entry != NULL))
{
#ifdef _DIRENT_HAVE_D_NAMLEN
- d_namelen =
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 an eglibc bug or expected
Please do the upload soon - the gem2deb 0.5.0 need this at runtime,
Thanks
Petr
https://lists.debian.org/debian-release/2013/11/msg00024.html:
-- Forwarded message --
Date: Sun, 03 Nov 2013 10:54:34 + (GMT)
From: Niels Thykier ni...@thykier.net
a lot of ruby
Thanks Petr for the patch. Is that build and runtime tested or only build time?
Build time only, the runtime verification is blocked by gnome-shell.
But the patch itself could be tested also on Linux.
Petr
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of
Control: tags -1 +patch
debian-bsd,
Can you provide any assistance?
Please alter in debian/control
libusb-1.0-0-dev [linux-any], libusb-dev [!linux-any],
into
libusb-1.0-0-dev [linux-any], libusb2-dev [kfreebsd-any],
libusb-dev [!linux-any !kfreebsd-any],
Petr
--
To UNSUBSCRIBE,
Control: tags -1 +patch
| CC modules/bio/serv_bio.c
| modules/bio/serv_bio.c: In function 'cmd_lbio':
| modules/bio/serv_bio.c:116:28: error: 'struct dirent' has no member named
'd_namelen'
|d_namelen = filedir_entry-d_namelen;
man readdir:
Only the fields d_name and d_ino
Control: tags -1 +patch
| subst.c:1529:28: error: 'struct dirent' has no member named 'd_namelen'
|d_namelen = filedir_entry-d_namelen;
man readdir:
Only the fields d_name and d_ino are specified
in POSIX.1-2001. The remaining fields are available on many,
but
Package: ruby2.0
Version: 2.0.0.299-2
Severity: serious
Tags: patch
User: debian-...@lists.debian.org
Usertags: kfreebsd
Hi,
the current version fails to build on GNU/kFreeBSD, see also
http://lists.debian.org/debian-bsd/2013/09/msg00157.html
Severity serious due to
Alternatively, someone could implement g_credentials_get_unix_pid(),
which clearly ought to exist anyway, and would move the problem into GIO.
(GNOME #687920.)
I did that, and it's available in glib2.0/unstable (2.36).
The patch for using g_credentials_get_unix_pid is attached.
Petr---
I think you can avoid this by using the primitive:
lwpid_t tid;
syscall (SYS_thr_self, tid);
There is a mess in kernel interfaces,
the right one is
long tid;
syscall (SYS_thr_self, tid);
But it holds only for current pthread implementation,
it can be changed anytime.
Petr
--
To
Is there any lwpid_t which isn't long and defined by kernel headers?
See upstream sources:
http://svnweb.freebsd.org/base/head/sys/sys/_types.h?revision=255219view=markup
typedef __int32_t __lwpid_t; /* Thread ID (a.k.a. LWP) */
And compare with
your package needs to be rebuilt against xorg-server 1.14. That
most likely means pulling in a couple changes from upstream git HEAD.
It suffices to put attached file into debian/patches/
and enlist it in debian/patches/series.
Please, could some DD (Robert, please) do the upload.
Ideally for
Package: dhcpcd5
Version: 6.0.5-1
Severity: serious
Tags: patch
User: debian-...@lists.debian.org
Usertags: kfreebsd
Hi,
the current version fails to build on GNU/kFreeBSD.
It needs small tweak, see bellow.
Please include this change also as upstream.
Thanks in advance
Control: found -1 0.17.3-1
The same patch can be used also for e17-0.17.3
Petr
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Package: xmobar
Version: 0.18-1
Severity: serious
Tags: patch
User: debian-...@lists.debian.org
Usertags: kfreebsd
Hi,
the current version fails to build on GNU/kFreeBSD.
Please just restrict building of MPRIS DBus plugins only under linux.
Petr
--- a/debian/control
+++ b/debian/control
@@
Hi.
Please move fixup just before dh_install.
With this change, it seems to build fine now,
as #715320 is fixed.
BTW, why is not
WITH_POLKIT = --with-polkit everywhere ?
Petr
--- debian/rules
+++ debian/rules
@@ -115,6 +115,11 @@
dh_auto_test
I performed yet another USB plug test, this time on 9.2 kernel.
gcc-4.8 -O2 compiled kernel (aka 9.2~svn253470-1 in experimental)
crashes too.
gcc-4.8 -O1 compiled kernel survives.
I will update SVN for 9.2 and 10 kernels to use gcc-4.8 -O1.
IMO, the 9.1 should stay at gcc-4.6 -O1, as it is a
Package: libev-perl
Version: 4.11-3
Severity: serious
Tags: patch
User: debian-...@lists.debian.org
Usertags: kfreebsd
Hi,
the current version fails to build on GNU/kFreeBSD.
It is due to forcing:
override_dh_auto_configure:
EV_EPOLL=1 dh_auto_configure
Please drop this override or
Package: p11-kit
Version: 0.18.5-1
Severity: serious
User: debian-...@lists.debian.org
Usertags: kfreebsd
Hi,
this is follow up to #717912.
While the libc header can be fixed, the use case in p11-kit is wrong one.
Please try convince upstream to prefer issetugid()
and use getauxval() only
I've now played around with 2 patches, one using this approach,the
other using Devel::CheckLib. Both lead to the same result and work
(on linux/amd64).
Both works also for kfreebsd-amd64.
I guess that Devel::CheckLib is the standard one, therefore prefered.
Just do not forget to add
[...] IIRC it happens to me both, on the 9.1 and the
10 kernel but only recently.
It could be due to GCC-4.8 and/or use of -O2 compiler optimisations,
which were enabled only in the most recent upload of each.
Perfect guess!
I have been able to confirm crash also on my PC,
usually with only
Hi.
what can I test for to get your kFreeBSD variant? Do I need a new
variable? If so, which?
I suggest to use DEB_HOST_ARCH_OS,
it would cover both kfreebsd-amd64 and kfreebsd-i386.
$ dpkg-architecture
DEB_BUILD_ARCH=kfreebsd-amd64
DEB_BUILD_ARCH_BITS=64
DEB_BUILD_ARCH_CPU=amd64
CC lsm_daemon.o
lsm_daemon.c: In function 'child_cleanup':
lsm_daemon.c:426:44: error: 'WEXITED' undeclared (first use in this function)
rc = waitid(P_ALL, 0, si, WNOHANG|WEXITED);
^
lsm_daemon.c:426:44: note: each
GLib-GIO:ERROR:/?PKGBUILDDIR?/./gio/tests/file.c:452:test_create_delete:
assertion failed (data-monitor_created == 1): (0 == 1)
/file/async-create-delete/0: FAIL
May well be due to the kqueue support for file monitor. Help fixing it on
kfreebsd is very
Package: wine-unstable
Version: 1.5.30-2
Severity: serious
User: debian-...@lists.debian.org
Usertags: kfreebsd
Hi,
the current version fails to build on kfreebsd-amd64.
It might suffice to change debian/rules from
ifeq ($(DEB_BUILD_ARCH), amd64)
into
ifeq
Package: r-base
Version: 3.0.1-3
Severity: serious
Tags: patch
User: debian-...@lists.debian.org
Usertags: kfreebsd
Hi,
the current version fails to build on GNU/kFreeBSD
using current default compiler 4.8 with -O3.
It does build on kfreebsd-amd64 using -O2.
It might or might not be kfreebsd
The fix is to annotate syscall description
with correct number of parameters.
--- kfreebsd/syscalls.list
+++ kfreebsd/syscalls.list
-sys_ktimer_settime - ktimer_settime i:ip
__syscall_ktimer_settime
+sys_ktimer_settime - ktimer_settime i:iipp
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: e17
Version: 0.17.1-2
Severity: serious
Tags: patch
User: debian-...@lists.debian.org
Usertags: kfreebsd
Hi,
the current version fails to build on GNU/kFreeBSD.
It needs some defined(__FreeBSD_kernel__), see bellow.
It would also be nice if you can ask upstream to include similar
Package: libflac-dev
Version: 1.3.0-1
Severity: serious
Tags: patch
User: debian-...@lists.debian.org
Usertags: kfreebsd
Hi.
The /usr/lib/x86_64-kfreebsd-gnu/pkgconfig/flac.pc
used to contain:
Cflags: -I${includedir}/FLAC
now it contains:
Cflags: -I${includedir}
It breaks build of vlc.
Petr
Hello kfreebsd maintainers,
VLC 2.0.7 FTBFS with kfreebsd-i386. It used to build fine with VLC 2.0.6.
It failed in the same way also under kfreebsd-amd64.
https://buildd.debian.org/status/logs.php?pkg=vlcarch=kfreebsd-amd64
It builds for me under kfreebsd-amd64, using today sid,
modulo fix for
Package: gnome-system-monitor
Version: 3.8.2.1-1
Severity: serious
Tags: patch
User: debian-...@lists.debian.org
Usertags: kfreebsd
Hi,
this is kind of reopen of #665999.
This time some defined got lost compared to 3.4.1-2
Petr
--- src/procproperties.cpp
+++ src/procproperties.cpp
@@ -26,7
Package: faketime
Version: 0.9.1-1
Severity: serious
Tags: patch
User: debian-...@lists.debian.org
Usertags: kfreebsd
Hi,
the current version fails to build on GNU/kFreeBSD.
It needs small tweak for testsuite, see bellow.
It would also be nice if you can ask upstream
to include this change.
libtool: link: g++ -fPIC -DPIC -shared -nostdlib
/usr/lib/gcc/x86_64-kfreebsd-gnu/4.7/../../../x86_64-kfreebsd-gnu/crti.o
/usr/lib/gcc/x86_64-kfreebsd-gnu/4.7/crtbeginS.o [*very long list of objects*]
-Wl,--whole-archive ./.libs/libWebCore.a ./.libs/libWebCoreGtk.a
-Wl,--no-whole-archive
The patch seems fine but given that F_DUPFD_CLOEXEC has been implemented in
FreeBSD[1], I wonder if the __linux__ test shouldn't be changed to a
HAVE_F_DUPFD_CLOEXEC check (or to a hurd one). How long do you think it'll take
for Debian's freebsd kernel to have that?
The version in stable does
Hi.
the test-secmem fails due to different restriction of FreeBSD kernel.
The FreeBSD kernel does not allow mlock()/mlockall() for ordinary user.
http://www.freebsd.org/cgi/man.cgi?query=mlocksektion=2
http://www.freebsd.org/cgi/man.cgi?query=mlockallsektion=2
These calls are only available
Hello Michael.
the test-secmem fails due to different restriction of FreeBSD kernel.
The FreeBSD kernel does not allow mlock()/mlockall() for ordinary user.
What should be used on kfreebsd then to lock process memory as ordinary
user, ie. how can this bug be fixed?
The problem with secure
Package: gnome-terminal
Version: 3.8.2-1
Severity: serious
Tags: patch
User: debian-...@lists.debian.org
Usertags: kfreebsd
Hi,
the current version fails to build on GNU/kFreeBSD.
The F_DUPFD_CLOEXEC is not widespread fcntl, see also changes between
Control: retitle -1 [kfreebsd-i386] symbol posix_fallocate64, version
GLIBC_2.3.3 not defined in file libc.so.0.1
Control: reassign -1 libc0.1 2.17-4
I installed Debian wheezy kfreebsd-i386 (standard + openssh-server, I think)
on a kvm virtual machine, upgraded to unstable to try to test a
Package: aghermann
Version: 0.9.0.2-1
Severity: serious
The current version requires mremap().
The interface mremap() is linux-only extension.
Petr
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
tags 706984 +patch
--
The last gmp upload failed to build on hurd-i386 and kfreebsd-i386
and I could use some help. The code builds but seven test cases
segfault [1]. Can someone help debug these and hopefully provide
a patch?
It crashes also for me inside kvm.
The key point seems be
Petr: thanks!
Which architecture did you test with?
It failed for both (linux-)i386 and kfreebsd-i386 in my kvm.
Patched source builds fine on both (linux-)i386 and
kfreebsd-i386 in my kvm.
Host OS is wheezy (linux-)amd64, with Intel Core2 Duo CPU.
And inside kvm under (linux-)i386:
tags 697016 +patch
--
The autotool-ification have not been correct.
Please alter it as shown bellow.
Petr
--- vobcopy.h
+++ vobcopy.h
@@ -124,16 +124,8 @@
#ifdef HAVE_GETMNTINFO
#define USE_GETMNTINFO
-#endif
-
-#ifdef USE_GETMNTINFO
-#ifdef USE_STATFS_FOR_DEV
#define
tags 699837 +patch
--
Please use patch bellow.
It would also be nice if you can ask upstream
to include this change.
Petr
--- src/getsize.c
+++ src/getsize.c
@@ -87,7 +87,7 @@
return -1;
}
-#elif defined(__FreeBSD__)
+#elif defined(__FreeBSD__) || defined(__FreeBSD_kernel__)
/*
tags 697015 + patch
notfixed 697015 2.0.1-5
--
Hi.
Accroding to
http://pubs.opengroup.org/onlinepubs/9699919799/functions/posix_fadvise.html
The posix_fadvise() function is part of the Advisory Information option
and need not be provided on all implementations.
Please guard usage by
Package: babeltrace
Version: 1.1.0-1
Severity: serious
Tags: patch
User: debian-...@lists.debian.org
Usertags: kfreebsd
Hi,
the current version fails to build on GNU/kFreeBSD.
The value ENODATA is linux specific,
please use some general error number, like shown bellow.
It would also be nice
On my system the daemon fails to start in any case with 'Daemon startup
failed', but that is a separate issue and less serious. There seem to
be two separate places where pulseaudio --start may hang indefinitely on
kfreebsd:
On my system, it is slightly better:
E: [(null)] client-conf-x11.c:
As suggested by Michael Banck on IRC I've been looking at Signals used
by both parts to see if they e.g. battle over SIGUSR?. However libgc
seems to use 32+{5,6} as signals on x86 FREEBSD __GLIBC__ at
least. Petr, Steven: any idea why this is? Are these signals fine for
kfreebsd glibc (signal.h
Unfortuantely, POSIX declined to specify setgroups() and initgroups() is
not in any standard, so it's hard to say which behavior is right and
which is wrong. It seems possible to argue any of the following:
1. The bug is in kFreeBSD's implementation of setgroups(), which must
be fixed so
tags 672959 +patch
--
Hi.
/sbin/startpar -p 4 -t 20 -T 3 -M boot -P N -R S
And the same happens even with -p 0. This is a single-CPU VM running
kfreebsd-i386.
I'm beginning to think that startpar is malfunctioning in some way
(after checkroot.sh returns, but before it runs the next
thanks, I'll probably just apply it as-is.
Thank you. Please would you also ask for unblock on -release ?
It might interfere with d-i beta1, but you know better
which time for migration is better.
Thanks
Petr
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a
found 677393 5.42+svn3561-2
--
Hi,
please use +/- original line number (1096) for patch context,
the line 466 is in a different class - freebsd_escalade_device,
but the class freebsd_areca_device have to be fixed for this.
It is just fixup to incomplete
[AS] os_freebsd.cpp: sync Areca code
apt.auth.export_key(46925553).split(\n)
returns extra 1st line:
ERROR: ld.so: object 'libfakeroot-sysv.so' from LD_PRELOAD cannot be preloaded:
ignored.
Any idea why this happens? We simply run
fakeroot /usr/bin/apt-key export 46925553
so it should work, right?
Wrong mixture of
Right, and we merge the two (probably in order to have meaningful
output in case of error).
It, IMHO, is not the right way to do.
The question is why does preloading
libfakeroot-sysv.so fail. It does not fail the other
architectures, so I assume someone is playing tricks with
LD_LIBRARY_PATH
tags 664144 +patch
--
Hi,
it can be easily fixed by patch bellow,
the patch in current upstream SVN breaks linux/amd64 compilation.
Petr
--- endian.h
+++ endian.h
@@ -24,7 +24,7 @@
*/
/* Try to get BYTE_ORDER, BIG_ENDIAN and LITTLE_ENDIAN */
-#if defined(__linux)
+#if defined(__linux) ||
tags 680234 +patch
--
Hi,
please use tweak bellow.
Petr
--- backend/umax_pp_low.c~ 2010-12-02 00:49:58.0 +0100
+++ backend/umax_pp_low.c 2012-07-10 20:20:16.0 +0200
@@ -73,8 +73,10 @@
#endif
#ifdef HAVE_MACHINE_CPUFUNC_H
+#ifndef __GLIBC__
#include
found 677393 5.42+svn3561-1
tags 677393 +patch
--
Hi,
also the current version fails to build on GNU/kFreeBSD.
It is due to incomplete
[AS] os_freebsd.cpp: sync Areca code with linux version by adding optional
enclosure number.
The small tweak bellow is sufficient.
It would be nice
Hi,
under kfreebsd-amd64 the
apt.auth.export_key(46925553).split(\n)
returns extra 1st line:
ERROR: ld.so: object 'libfakeroot-sysv.so' from LD_PRELOAD cannot be preloaded:
ignored.
[ERROR: ld.so: object 'libfakeroot-sysv.so' from LD_PRELOAD cannot be preloaded:
ignored.,
'-BEGIN
Package: terminal.app
Version: 0.9.8-1
Severity: serious
Tags: patch
User: debian-...@lists.debian.org
Usertags: kfreebsd
Hi,
the current version fails to build on GNU/kFreeBSD.
It is partly reincarnation of #643973.
Please use patch bellow.
Cheers
Petr
--- TerminalView.m~
Hi,
it is due to attempt to use sendfile.
Moreover, the configure.in already contains:
AC_CHECK_HEADER(sys/sendfile.h, [AC_DEFINE(LINUX_SENDFILE, [], [whether we have
the linux sendfile api])])
dnl TODO: we might need to check for the actual syntax
And yes, we hit the TODO ...
Cheers
Package: smartmontools
Version: 5.42+svn3539-1
Severity: serious
Tags: patch
User: debian-...@lists.debian.org
Usertags: kfreebsd
Hi,
the current version fails to build on GNU/kFreeBSD.
It needs extra includes, see bellow.
Thanks in advance
Petr
---
tags 675835 +patch
--
Hi,
setting custom serial speed is linux specific,
please use attached patch.
Petr--- gtkterm-0.99.7~rc1.orig/src/serie.c
+++ gtkterm-0.99.7~rc1/src/serie.c
@@ -25,7 +25,9 @@
#include fcntl.h
#include stdio.h
#include unistd.h
+#ifdef __linux__
#include linux/serial.h
Could you provide the config.log file that is generated on kfreebsd?
Attached.
Thanks
Petr
config.log.gz
Description: Binary data
tags 638381 +patch
user debian-...@lists.debian.org
usertag 638381 + kfreebsd
--
Hi.
The problem is due to
Can't figure out how to do dynamic loading or shared libraries on this
system. shown in build log.
Please just alter configure as shown bellow.
Petr
--- tcltls-1.6+dfsg.orig/configure
The bitwise arithmetic is possibly converting to a signed int, and
doesn't have the fchmod function prototype time, but on BSD platforms
mode_t is an unsigned short int.
I have been curious, as using the standard C integer promoting rules
should suffice here.
The problem is not missing
I'm not seeing that problem on kfreebsd-i386, at least?
Interesting. I got the above output on asdfasdf.debian.net's unstable
chroot (kfreebsd-amd64, AFAIK).
The key difference might be exact python version.
Inside sid chroot:
python2.6 2.6.7-4
python2.7
Any good ideas what to investigate further?
The significant difference between logs is
gcc -Wall -Wextra -g -O2 -o pdnsd ...
gcc -Wall -Wextra -g -O2 -o pdnsd ... -pthread
The -pthread really have to be propagated.
The key difference seems be automake-1.9 installed on porter
So adding automake-1.9 to the build depends would solve the FTBFS on the
buildds?
Probably.
Or extend 01_support_kfreebsd_properly.patch
for needed changes in pdnsd-1.2.8/src/Makefile.in
Petr
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe.
concurrency = multiprocessing.cpu_count()
File /usr/lib/python2.7/multiprocessing/__init__.py, line 136, in cpu_count
raise NotImplementedError('cannot determine number of cpus')
NotImplementedError: cannot determine number of cpus
It can be used either
There is a /proc/self/exe support under GNU/kFreeBSD, but it is
limited, namely inside combination of bind mounts and chroots.
What's the problem with /proc/self/exe anyway? It works fine here,
even inside chroots.
Did you nullfs-mount /proc?
No, I expect that the problem is when the
So to summarize, both you and I can build the package on kfreebsd
machines (debian porter boxes and your box),
but the buildds fail to build since 4.2.2-4+b2,
whereas 4.2.2-4+b1 and 4.2.2-4 have built successfully. Note
that in a binNMU the source code has not been changed. From this I conclude
Btw, could we restrict this kludge to platforms that need it? See
attached patch.
I like the idea, slightly different patch is in.
Petr
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
There is a /proc/self/exe support under GNU/kFreeBSD, but it is
limited, namely inside combination of bind mounts and chroots.
It is possible that this is a linuxism, but if this should not be used on
bsd, wouldn't it be better if the proc filesystem is NOT available on the
porter boxes? Or
Yes, I think this should be handled in glibc, and the sockaddr_un be
fixed to match what the kernel expects, the compat code would be there
to fix applications built against the bogus sockaddr_un type.
In fact, we already clip the passed size in our eglibc in
bind() and connect(), it might
Apparently, there are more problems than -fgcse. gcc-4.6 -fno-gcse
still fails whereas gcc-4.4 -fno-gcse doesn't.
I've downgraded the dependency to get a working kernel. Before we
upgrade, I think we could use experimental as testing ground to
resolve the problems. It's very bad that this kind
On my main workstation, kfreebsd 8.2-1.1 and later versions CPU-faults
early on boot. This affects the i686 version only (not amd64 one).
8.2-1 is not affected.
Probably related to:
* Build by GCC 4.6. (Closes: #594288)
Would you mind to rebuild latest kfreebsd-8 with gcc-4.3 from stable
Package: electric-fence
Version: 2.1.18
Severity: serious
Tags: patch
Hi.
Please apply the patch bellow to handle both SIGBUS and SIGSEGV faults
simultaneously on FreeBSD based architectures.
You might consider to catch both SIGBUS and SIGSEGV on all architectures.
Petr
--- a/eftest.c
+++
Package: fakeroot
Version: 1.18-1
Severity: serious
Tags: patch
User: debian-...@lists.debian.org
Usertags: kfreebsd
Hi,
the current version fails to build on GNU/kFreeBSD.
The problem is in upstream commit:
Support tartest on Darwin and FreeBSD
where the group of root is
tag 631566 + patch
user debian-...@lists.debian.org
usertag 631566 + kfreebsd
--
What about using this snippet:
if (!list_empty(mntinfo)) {
#ifdef EBADE
errno = EBADE;
#else
errno = ENOENT;
#endif
}
Otherwise it builds fine.
Petr
--
To
Hi.
The previously provided recipe consists of three steps:
- in debian/control change openjdk-6-jdk into default-jdk,
- alter configure.ac as shown bellow and
- regenerate configure.
Only the 2nd step have been performed in 0.8.7-2 upload.
Please do the remaining ones, i.e.
- in
I tried the same on my PC,
testsuite of all available (stable, sid, experimental) libffi passes.
On asdfasdf.d.n they fails.
Could be this related to CPU ?
My is Intel(R) Core(TM)2 Duo CPU E6750
asdfasdf's AMD Sempron(tm) Processor 3000+
Petr
--
To UNSUBSCRIBE, email to
user debian-...@lists.debian.org
usertag 642928 + kfreebsd
usertag 642162 + kfreebsd
--
Could be this related to CPU ?
My is Intel(R) Core(TM)2 Duo CPU E6750
asdfasdf's AMD Sempron(tm) Processor 3000+
After changing configure.ac and propagating it into
configure, the testsuite of
tags 630517 + patch
user debian-...@lists.debian.org
usertag 630517 + kfreebsd
--
Hi.
Please apply patch bellow to configure.in
and propagate it into configure.
Petr
--- source/configure.in
+++ source/configure.in
@@ -604,7 +604,7 @@
# Check to see if genccode can generate simple assembly.
Hi,
just to make it clear.
The tar works as expected, it just emits extra warning.
Current tar version expects more than POSIX guarantees.
Even inside the tar source src/misc.c is written:
FIXME: There should be no need to get the absolute file name.
getcwd is slow, it might
1 - 100 of 290 matches
Mail list logo
