It seems that sigwait() returns EINTR,
which is not even a specified error for sigwait().
It is not specified for sigwait
http://pubs.opengroup.org/onlinepubs/9699919799/functions/sigwait.html
but is is specified for sigwaitinfo
It would be good to have this fixed for jessie.
Correct handling of denormals which are controlled via this register is
very important for the performance of e.g. audio applications.
If we have a patch I guess it can still be included for Jessie.
It is slightly different to #761175 as the
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
(I didn't figure out yet how to rebuild the control file, to get these
installed into a .deb, and I have no clue how to test it either.)
I believe that fakeroot debian/rules control before build is sufficient.
No 'undefined reference' errors in the build log. Both regular and -m32
multilib
tags -1 + patch
--
It sufficess to link with pthread, using patch bellow.
Cheers
Petr
--- test/module.defs
+++ test/module.defs
@@ -46,6 +46,8 @@
TEST.GCC.l += iconv
else ifeq ($(BUILD.system),linux)
TEST.GCC.l += pthread dl m
+else ifeq ($(BUILD.system),kfreebsd)
+
On 12/09/14 21:44, Petr Salinger wrote:
It seems that simple drop of kfreebsd-gnu from libphobos_no_systems does
not suffice.
In the build logs are messages like
/build/manual/gcc-4.9-4.9.1/build/x86_64-kfreebsd-gnu/libphobos/libdruntime/../../../../src/libphobos/libdruntime/rt/dmain2.d:419
Am 12.09.2014 um 15:13 schrieb Thibaut Paumard:
While it's your prerogative to decrease the severity, please note that
this bug means that all the packages that build-depend on gdc (22
packages in jessie) are currently in an FTBFS-state on kfreebsd.
sure, and they still will ftbfs without
Package: libc0.1
Version: 2.13-38+deb7u2
X-Debbugs-CC: jtaylor.deb...@googlemail.com , debian-...@lists.debian.org
On Sat, 6 Sep 2014, Julian Taylor wrote:
I encountered a weird issue on kfreebsd i386 using pthreads. It seems to
change the x87 fpu precision mode (bits 8 and 9 of the control
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-dist-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
Thanks. I've checked that xserver-xorg-video-nv (non-free, meant for
kfreebsd systems) still builds OK with xorg-video-abi-18,
xserver-xorg-core (= 2:1.15.99.903).
I don't have hardware available to test it with unfortunately.
I can confirm that xserver-xorg-video-nv works under
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
Everything's good except for transmission, which failed on kfreebsd.
Probably a miniupnpc call only compiled on that architecture.
In fact, the problem is sligthly different.
The transmission package does not support newly
supplied libminiupnpc-dev under both Linux and kFreeBSD:
checking
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.
notfound 751565 2.18-7
The regression is due to
2013-12-17 Joseph Myers jos...@codesourcery.com
* sysdeps/unix/bsd/bits/posix_opt.h: Remove file.
* sysdeps/unix/bsd/clock.c: Likewise.
* sysdeps/unix/bsd/times.c: Likewise.
I will resurrect the clock.c file into kfreebsd specific sysdeps,
and
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
I wonder how to fix it. Merely documenting the restriction isn't really
anoption, as no widespread system has it. Saving the signal handler,
disabling it then restoring would work but introduces a slight race
condition (a child process can exit while we're in grantpt()).
In fact, it is
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
Hi.
I doubt that the testcase worked under previous kernels.
The problem is not the handler for SIGCHLD, but it's content.
The openpty() uses internally fork and waitpid.
The waitpid in the testcase signal handler eats result needed by
openpty implementation.
Petr
--
To UNSUBSCRIBE, email to
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
If someone puts together a debdiff including them, I'm more than
happy to look at that and we can make a call from there. (Bearing in
mind that the window for 7.2 closes over the coming weekend.)
Any news here? We're now nearing the end of the window for 7.3.
Ping? The next point-release is
I believe we can raise MAXLOGNAME, together with revisisting
getlogin/getlogin_r/setlogin and dropping support for glibc
compiled with --enable-compatible-utmp (the Debian one is compiled with
--disable-compatible-utmp anyway).
The problem might be with sys/proc.h, but this header is
together with revisisting
getlogin/getlogin_r/setlogin
I reviewed those functions and AFAICT the consequences are not terribly
bad (see my previous mail). Are there other concerns?
The getlogin_r is not thread safe, as it uses the same buffer as getlogin.
Thread A calls getlogin_r(), the
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
The accept4() prototype is marked as a stub.
I.e. usual configure.ac
AC_INIT()
AC_CHECK_FUNCS(accept4)
says
checking for accept4... no
The ruby uses own checking, which does not honour stub marking.
The way forward here will be to provide some day
#define SOCK_CLOEXEC
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-dist-requ...@lists.debian.org
with a subject
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---
Package: gnome-shell
Version: 3.8.4-3
Severity: important
Tags: patch
User: debian-...@lists.debian.org
Usertags: kfreebsd
Please restrict Depend on gir1.2-nmgtk-1.0 to [linux-any].
Cheers
Petr
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of
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
If I remember correctly, the perl code expects something which is
not guaranteed by POSIX. But our new implementation provides this,
therefore we (kfreebsd) are not affected by this any longer.
Indeed, although at one time you argued that it was a correctness
fix anyway.
We seem to have a
IMO, my suggested change (Perl_atfork_reinit) in Message #54 [1]
still should be aplied by perl upstream. While it might not be
problem for this testcase, the unlocking in forked child is fragile.
Hi,
I finally (!) got round to submitting this upstream, at [1], and the
comment so far is that
Should be fixed in STABLE-9 post r254665,
together with other compat32 fixes.
It is not part of 9.2 upstream release.
Petr
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Control: tags -1 + patch - help
Hi.
Simple || GLIBC suffices, see bellow.
It would also be nice if you can ask upstream
to include this change.
Thanks in advance
Petr
--- opencolorio-1.0.8~dfsg0.orig/export/OpenColorIO/OpenColorABI.h.in
+++
It is planned, but (e)glibc 2.18 upload have to go first, due to changes of
idtype_t values. See also 218_waitid* in
http://anonscm.debian.org/viewvc/glibc-bsd/trunk/glibc-ports/
We also have to provide (reasonable) fallback implementation
under wheezy kernels.
Cool! Excellent stuff! I've
Recently in FreeBSD waitid was implemented[1] this includes:
* waitid function, implemented via wait6 syscall
* option flags WEXITED WTRAPPED added
More details patch in the PR linked.
This is now available in prerelease FreeBSD 9.2 (I'm using 9.2-rc2). I
have verified and tested that it works
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
Another observation:
With
TESTOPTS = -j 2 -w -u$(TEST_RESOURCES)
insted of -j 1 it does not hang immediately,
it runs all tests to the point:
349 tests OK.
3 tests failed:
test_gdb test_posix test_socket
3 tests altered the execution environment:
test_site test_urllib2_localnet
Is there same easy way, how to run each of them individually ?
make -C builddir test TESTOPTS=-j 1 -w test_name
Got further. The tests itself does not hang.
But they hang iff test___all__ is run befor them.
It holds at least for test_io and test_socket:
$ ./python
Hi.
I tried (under eglibc 2.17-92 and 9.2 kernel from experimental)
this:
cd ~/python3.3-3.3.2/build-debug
export PYTHONPATH=~/python3.3-3.3.2/Lib/test
export LD_LIBRARY_PATH=~/python3.3-3.3.2/build-debug/
./python ~/python3.3-3.3.2/Lib/test/test_io.py
But is passes, while in buildd
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-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Seems similar to http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=696514
Yes I thought so at first, but this feature seems to be working on 8.3
and 9.0 kernels so it is likely a kernel ABI change instead.
But it suffices to add #include netinet/ether.h
and segfault of ifconfig is gone.
Petr
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
Subject: Re: issetugid
On Fri, Apr 20, 2012 at 22:38:20 +0200, Petr Salinger wrote:
Hi,
Xlib uses AC_CHECK_FUNC(issetugid) in configure.ac, and then
#include unistd.h
issetugid();
in the code. On Linux everything's fine because libc doesn't have that
function. OTOH kfreebsd explodes with a missing
Yes, it is a header bug. It should not define AT_SECURE to
value with different meaning.
This part is now in
http://sourceware.org/bugzilla/show_bug.cgi?id=15794
Petr
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact
Hi.
it does work. Try i.e.
~$ LD_SHOW_AUXV=1 /bin/true
AT_PHDR: 0x400040
AT_PHENT:56
AT_PHNUM:9
AT_PAGESZ: 4096
AT_FLAGS:0x0
AT_ENTRY:0x401274
AT_BASE: 0x800604000
AT_EXECPATH: /bin/true
AT_OSRELDATE:900044
AT_CANARY:
That means: AT_UID/et.al. are defined in the header, the kernel knows
about them, but they are not usable though getauxval().
Not exactly. These are defined, kernel does not supply them at all.
Which is perfectly valid behaviour.
That is where the actual bug is,
i.e. the headers are at odds
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
Should be fixed in HEAD post r253531.
Please package and upload new snapshot.
Petr
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
111_ldd_load_address.diff changes kernel-user ABI. How mergeable is this?
It is not ABI chabge, it is only a change of
implementation defined behaviour.
Is FreeBSD also affected in some way? The testcase is reproducible
when built using their toolchain/libc, but not when using their ldd.
I'm
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
Package: gcj-4.8-jre-headless
Version: 4.8.1-6
Severity: important
Tags: patch
User: debian-...@lists.debian.org
Usertags: kfreebsd
Hi,
there is a significant regression in libjava testsuite.
Debian 4.8.1-5
http://lists.debian.org/debian-gcc/2013/06/msg00221.html
We are planning switch to NPTL-like pthread implementation,
I tried build of python3.3 in such environment.
At least first two tests from
test_io test_signal test_socket test_socketserver \
test_threading test_threadsignals test_threaded_import \
test_time test_pty
Package: kfreebsd-9
Severity: wishlist
User: debian-...@lists.debian.org
Usertags: kfreebsd
To properly provide CLOCK_THREAD_CPUTIME_ID, CLOCK_PROCESS_CPUTIME_ID
and clock_id's created by clock_getcpuclockid() and
pthread_getcpuclockid(), we need a kernel support.
See also #665287.
The kernel
The situation is now slightly different.
We are able to use ktimer_* facilities,
it only remains to support
CLOCK_THREAD_CPUTIME_ID, CLOCK_PROCESS_CPUTIME_ID
and clock_id's created
by clock_getcpuclockid() and pthread_getcpuclockid()
We are planning switch to NPTL-like pthread implementation, details in
http://lists.debian.org/debian-bsd/2013/07/msg00060.html
Prototype will be included after that switch.
Petr
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble?
We are planning switch to NPTL-like pthread implementation, details in
http://lists.debian.org/debian-bsd/2013/07/msg00060.html
It will not segfault in a very confusing way anymore after that switch.
Petr
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of
As far as I know,
the setproctitle(3) is now provided by libbsd-dev.
Petr
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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
Hello.
One more problem popped up - #712196
The fix is one-liner:
--- 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
Package: libc0.1-dev
Version: 2.17-5
Severity: wishlist
User: debian-...@lists.debian.org
Usertags: kfreebsd
Please sync bits/fcntl.h with current upstream, mainly
#define F_DUPFD_CLOEXEC 17 /* Like F_DUPFD, but FD_CLOEXEC is set */
#define F_DUP2FD_CLOEXEC 18 /* Like F_DUP2FD, but FD_CLOEXEC
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
Package: gcc-4.8
Version: 4.8.1-2
Tags: patch
User: debian-...@lists.debian.org
Usertags: kfreebsd
Please,
could you add into patches the attached one.
It provides handling for unwind inside signal trampoline for kfreebsd.
Please also add/raise build-depends
kfreebsd-kernel-headers (= 0.84)
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
Package: trafficserver
Version: 3.3.2-1
Tags: patch
User: debian-...@lists.debian.org
Usertags: kfreebsd
Hi,
the current version fails to build on GNU/kFreeBSD with:
TrafficCop.cc:1870:40: error: 'initgroups' was not declared in this scope
Please move #include grp.h outside linux specific
Package: scummvm
Version: 1.6.0+dfsg-1
Tags: patch
User: debian-...@lists.debian.org
Usertags: kfreebsd
Hi,
I have seen your request to remove scummvm from kfreebsd-* architectures.
Please, instead of dropping package just add | k*bsd*-gnu* | gnu*
into two places, as show bellow.
It allows
1 - 100 of 1547 matches
Mail list logo
