Sufficient to finish build on GNU/kFreeBSD seems be this:
--- scripts/builder2schema.pl
+++ scripts/builder2schema.pl
@@ -23,8 +23,10 @@
print \tschema id=\$ARGV[1]\ path=\/org/gnome/anjuta/\\n;
if ($#ARGV == 2) {
+ unless(-d $ARGV[2]){
open FILE, , $ARGV[2] or die $!;
while
your package no longer builds on kfreebsd-*:
| [ 87%] Building CXX object
applications/present3D/CMakeFiles/application_present3D.dir/Cluster.o
| cd
/build/buildd-openscenegraph_2.9.11-1-kfreebsd-amd64-jXKFmU/openscenegraph-2.9.11/build/osg/applications/present3D
/usr/bin/c++-g -O2 -Wall
Package: gcc-4.6
Version: 4.6.0~rc1-1
User: debian-...@lists.debian.org
Usertags: kfreebsd
Hi,
1) problem during testing of libgomp in 32 bit mode
Please disable the problematic test.
Tested on kfreebsd-amd64.
--- a/src/libgomp/testsuite/libgomp.c/lock-2.c
+++
2) liblto_plugin.* is missing in generated gcc-4.6 binary package
Please add kfreebsd-i386 kfreebsd-amd64 into
gold_archs in debian/rules.defs or test against
DEB_TARGET_ARCH_CPU instead of DEB_TARGET_ARCH for
with_gold.
Oh, ld.gold is not available on kfreebsd-*.
But without liblto_plugin.*
2) liblto_plugin.* is missing in generated gcc-4.6 binary package
The liblto_plugin.* have to be installed on kfreebsd-* somehow.
or -fno-use-linker-plugin have to be default.
I saw changes in SVN, the r5135 should fix it,
please from r5130 revert this:
gold_cpus = i386 i486 i586 i686 x86_64
qemu-kfreebsd:/home/njh# apt-get install kfreebsd-image-8.2-1-686 libc0.1-i686
The following extra packages will be installed:
libc0.1
The following packages will be upgraded:
libc0.1 libc0.1-i686
WARNING: This version of glibc uses UMTX_OP_WAIT and UMTX_OP_WAKE
syscalls that are not
Unfortunately, the provided proc/self/maps is only close to linux one,
it does not cope with chroots.
The comment in graphviz source already says it works only on linux ;-)
Please, could you verify whether this change works:
--- a/lib/gvc/gvconfig.c
+++ b/lib/gvc/gvconfig.c
@@ -316,7 +316,8 @@
I'm seeing doxygen segfaulting regularly on kfreebsd-*
buildds. And produced a backtrace for one of these. It turned out to
be easily reproducible. Backtrace below (wasn't too easi btw: doxygen
still builds a stripped binary with DEB_BUILD_OPTIONS=debug)
This is extracting the call from
clone 629211 -1
reassign -1 d-conf 0.7.5-1
--
Hi.
Please append following line into debian/rules of d-conf.
CFLAGS+=-std=gnu99
The problem is that d-conf explicitely sets in AM_CFLAGS std=c89,
I do not see any reason for doing it, namely in year 2011.
Petr
--
To UNSUBSCRIBE,
Do I understand correctly that switching to gcc-4.4 and adding -fno-gcse to
CFLAGS is the proper solution?
Switching to gcc-4.6 and no changes to CFLAGS.
But have to be tested widely.
Petr
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe.
-I/usr/src/kfreebsd-source-8.1/sys/fs/puffs/puffs/../putter -DPUFFSDEBUG
-mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2
-mno-sse3 -ffreestanding -std=iso9899:1999 -c puffs_msgif.c In file
included from @/sys/vnode.h:563,
from puffs_msgif.c:44:
Stop in
tags 610716 +patch
--
Attached please find proposed patch against 0.2.2-2.
Given the source is derived from FreeBSD,
it is unfortunate, that the code does not build on FreeBSD kernel.
Petr--- libtirpc-0.2.2.orig/src/svc_dg.c
+++ libtirpc-0.2.2/src/svc_dg.c
@@ -620,6 +620,7 @@ cache_get(xprt,
Package: kfreebsd-8
ld -Bshareable -z common-page-size=8192 -d -warn-common -o 3dfx.ko 3dfx.kld
@3dfx.lopt
ld: 3dfx.kld(set_modmetadata_set+0x0): reloc against `.data': error 4
ld: final link failed: Nonrepresentable section on output
*** Error code 1
Might be related to binutils
Thanks. Thanks to Martin we know this bug seems to have been
introduced for him in v2.6.30-rc1 (more precisely: ALSA: hda - Use
digital beep for AD codecs, 2009-02-06). I suspect it may have been
fixed on at least some systems by v2.6.35-rc1~478^2~1^2~24^2~3 (ALSA:
hda-intel - AD1984 thinkpad -
Typical kfreebsd-amd64 experimental system, kernel =
kfreebsd-image-8.2-1-amd64 8.2-1.1. When I try to run
pstree -a, I get:
$ pstree -a
/proc/19/cmdline: Bad address
Indeed:
$ ps 19
PID TTYSTATTIME COMMAND
19 ? S+ 0:00
As far as I can see, gcj suffers a bus error trying to compile even
the trivial Hello World program (see #594830) since last summer.
This problem is exhibited in GCC 4.4 and GCC 4.6 releases.
Only on kfreebsd-amd64 and only on some machines.
gcj fails under fash.d.o, but not fano.d.o,
it works
At this point I'm not sure whether the gcj problem is the only problem
:-/ so I would really appreciate it if you could try a build on your
good machine and comment on #613539 to describe the outcome.
dpkg-buildpackage -B -uc went fine on my kfreebsd-amd64 machine.
It is Intel Core2 Duo CPU
We still have to teach somehow, that thread handling is the same as
in linuxthreads (pre-NPTL) implementation.
Any progress on this? It is not funny when you have to support arch which you
can't usefully use gdb on :-(
No news from my side.
I have not been able to understand details of inside
It fails in a local kfreebsd-i386 (kvm based) exactly the same way -- so
it seems to be rather reproducible.
I tried it today and it does not fail in my local
kfreebsd-i386 (kvm based) :-(
Petr
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of
It fails in a local kfreebsd-i386 (kvm based) exactly the same way -- so
it seems to be rather reproducible.
I tried it today and it does not fail in my local
kfreebsd-i386 (kvm based) :-(
With or without sbuild involved?
Without.
Plain dpkg-buildpackage -B -uc.
Petr
--
To
Hi.
The problem seems to be in linker changes.
The nlist() function comes from libbsd on GNU/kFreeBSD
and now it is not detected indirectly via libkvm.
Please use instead of 44_nlist_kvm.patch this:
--- a/configure.in
+++ b/configure.in
@@ -2676,6 +2676,9 @@
# add hosts which don't use nlist
forcemerge 613312 611476
--
a denial-of-service has been posted for freebsd [0]. i don't have time
to verify whether any of the claims actually affect debian. please
check the kfreebsd package.
[0] http://www.exploit-db.com/exploits/16064/
It affects us, we already care about it in #611476.
I am facing the same problem with the same hardware
and I have tested that this ethernet controller works under
FreeBSD with the fxp(4) driver, which is consistent with the web page
referred to:
...
Adapters supported by the fxp(4) driver include:
...
* Many on-board network interfaces on Intel
(this bug most likely needs reassigning, but I don't know where, so filing
it on the application that exhibits the symptom)
gnome-terminal aborts on start, with unknown signal:
rmh@dimoni:~$ LD_LIBRARY_PATH=/usr/lib/debug/lib/x86_64-kfreebsd-gnu gdb
gnome-terminal
...
(gdb) r
Starting
If it is, I would suggest a split like:
freebsd-nfs-server
freebsd-nfs-client
freebsd-nfs-common
since a server probably doesn't want to waste memory on
nfsiod either.
Comments?
I like the idea of spliting. I am unsure whether we should aim for server
instalation without client binaries.
Hi,
I do not like the idea of adding
amd64_set_gsbase and i386_set_fsbase into our shared libc.
The only user so far is wine,
it already have OS specific setting of fs/gs.
#if defined __linux__
arch_prctl( ARCH_SET_GS, teb );
#elif defined (__FreeBSD__) || defined (__FreeBSD_kernel__)
reassign 637424 kfreebsd-kernel-headers
--
The second option is to insert into
machine/sysarch.h always inline functions.
I don't see a problem with using inline functions. Shall we do this?
Yes, it is easier and can be stopped any time.
Petr
--
To UNSUBSCRIBE, email to
Hi,
I looked at just commited r4891, and it seems that it breaks
kfreebsd-amd64 seriously.
On kfreebsd-amd64, the ELF interpreter is /lib/ld-kfreebsd-x86-64.so.1,
i.e. it is really in /lib, not in /lib64.
The lib64 - lib symlinks in previous eglibc versions only have been
as defence
severity 640325 wishlist
--
The following code (extracted from dash's test builtin) is behaving
differently between linux and kfreebsd, having a 644 `test' file and
running it on linux as root user prints -1 while on kfreebsd it prints
0.
We already wrap access syscall to more intuitive behaviour,
we should try to do the same also for faccessat.
Pending for next eglibc upload.
So relying on this is actually a bug in dash?
(and there's probably no easy way to check how faccessat is behaving right?)
Yes, and yes.
Petr
--
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
test 56:
--- -
+++ /home/salinger/tar-1.26/tests/testsuite.dir/at-groups/56/stderr
@@ -1,2 +1,5 @@
+tar: Cannot get working directory: Permission denied
tar: a: Directory is new
+tar: Cannot get working directory: Permission denied
+tar: Cannot get working directory: Permission denied
56.
severity 639658 important
retitle 639658 [kfreebsd] waitpid from a thread does not work for child
processes created by other threads
reassign 639658 kfreebsd-8, kfreebsd-9, eglibc
--
As you can see, the main thread delegates the waitpid call to a sub-thread. But
both
threads are still part of
Would you have time to turn that into a (tested ;) ) patch?
With attached patch on top of 1.9.3~preview1+svn33077-3
make test
#244 test_fork.rb:51:in `top (required)':
a = []
trap(:INT) { a.push(1) }
trap(:TERM) { a.push(2) }
pid = $$
begin
fork do
Could you try this version:
---
a = []
trap(:INT) { puts INT recvd ; a.push(1) }
trap(:TERM) { puts TERM recvd ; a.push(2) }
pid = $$
puts parent pid: #{pid}
begin
fork do
puts child pid: #{$$}
sleep 0.5
Process.kill(:INT, pid)
Process.kill(:TERM, pid)
puts signals sent.
end
Could you try make test-all ? While some failures and errors are
expected, it stresses the interpreter a bit more, so it's a good way to
check that it doesn't block.
Under sid, it fails to start, probably due to
multiarch changes of libc location:
So, I don't know what to do.
How likely are those problems to be fixed in kfreebsd?
The needed primitives [1] for pthread add-on rewrite
should be available and working in FreeBSD 9.0 kernel.
The 8.x have only limited support.
No ETA for eglibc rewrite now ;-)
Petr
[1]
If any debian-bsd people could add some insight to this one, it would be
appreciated.
I've tried various test values, and it doesn't require the time be
exactly MAX_INT to fail (smaller values fail also).
Please which one ?
The 49711 days really overflows.
The prior version of timeout
fail on subsequent runs. Much smaller (order of magnitude) numbers seem
ok, and I haven't identified a specific bad number. In a loop, 8
seems ok, while 9 exhibits intermittant failure. Assuming that
holds true, we could set the max timeout to about 25 years (which should
suffice
Ah, now that makes sense. Kinda. It still doesn't explain why the result
is random. :-)
true sometimes exits too fast, sleep 0.1 suffices.
Due to userspace implementation (via pthread_cond_timedwait),
/bin/true might end even before the signal is delivered.
BTW, I just verified, only
really needs a fractional second?) I'll also clone the bug over to libc
for a better fix, as I think it really needs to be handled there because
trying to work around the problem means making assumptions about the
implementation that I'm not sure are/will be valid.
I already thought about
This firmware is being removed from the kfreebsd kernel leaving no (easy)
possibility
to use kfreebsd on such a server as there is no possibility to load non-free
firmware
at runtime, like we do on Linux. Its neither (easily) possible to rebuild the
kernel
from scratch including firmware, as
Hi.
suggesting that the functions I'm looking for are missing entirely.
Is that so?
Yes.
They are optional part, see
http://pubs.opengroup.org/onlinepubs/9699919799/functions/pthread_mutexattr_setprioceiling.html
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
Also build of vlc 1.1.10-1 in sid chroot segfaults, so it looks like bug in
some other package.
Version of gcc , eglibc, ...?
Petr
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
perl -Mthreads -e 'threads-create(sub {})-detach; fork'
which crashes non-deterministically about half the time for me.
Thanks for reduced testcase.
The problem might be in usage of pthread_atfork(lock, unlock, unlock).
It is perfectly valid to unlock() in parent.
But in child it might be
I am unable to get the failure neither on my PC,
neither on asdfasdf.d.n
Would be possible to disable parallel
build of gcc-4.6/gcj-4.6/gnat-4.6 on kfreebsd(-amd64) ?
That way we could at least compare failing and working build log.
And may be do DD uploads from i386 to test also linux-amd64
Package: freebsd-utils
to not forget it:
-- Forwarded message --
Date: Wed, 7 Sep 2011 10:45:54 +0200
From: Mats Erik Andersson mats.anders...@gisladisker.se
To: debian-...@lists.debian.org
Subject: Setting SGID on netstat.
Resent-Date: Wed, 7 Sep 2011 08:46:56 + (UTC)
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
Encountered regressions that don't match expected failures:
bug22.out, Error 1
What is your CPU ?
It happens also on my PC (in 32 bit pass), with
Intel(R) Core(TM)2 Duo CPU E6750 @ 2.66GHz
Petr
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of
I looked more into.
In fact I do not understand what the test tries to test.
It effectively test return code of
fprintf (fp, %2147483648d%2147483648d, 1, 1);
The printf family returns int and should return number of written bytes.
It therefore cannot exceed MAX_INT.
But the test tries to
reassign 576335 cvc3
found 576335 2.2-13
tag 576335 = patch
thanks
Hi,
it looks like the java on kfreebsd-amd64 problem
is solved with gcj-4.6 (4.6.1-6) upload.
Please change Architecture of libcvc3-2-jni to any
and drop 50_exclude_java_tests_on_kfreebsd_amd64.patch.
Many thanks
Petr
- ret = fprintf (fp, % SN d% SN d, 1, 1);
+ ret = fprintf (fp, % SN d% SN d% SN d, 1, 1);
It have to be changed into
fprintf (fp, % SN d% SN d% SN d, 1, 1, 1);
or
fprintf (fp, % SN d% SN d% SN d, 1, 2, 3);
+ ret = fprintf (fp, % SN d, 1, 1);
And here into
fprintf (fp, % SN
Package: kfreebsd-8
I was under the impression that my pushinf for IPSEC support
would have lead to that feature being enable in image 8.2,
at least. Until a few minutes ago I have had a custom
kernel 8.1 in use in order to evaluate ipsec-tools
continuously. Now I have installed
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
The real problem is probably variation of #591648,
reincarned by fix to #618433.
The openvrml failed on armel in doxygen.
Please re-enable doxygen_direct_dot_run.diff in series.
Thanks
Petr
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of
buildd's picked lasts versions up correctly without FTBFS. Could you
check, does it still FTBFS for you?
It builds fine for me under idle PC,
but it fails as shown bellow under otherwise busy PC.
But the previously proposed patch does not help with it.
I believe that current failure is not
AspectC++ fails to build in parallel on kFreeBSD due to a corrupted
file which is accessed concurrently during build. Reinhard told me hs
traced it down to some [0] non-functional syncronization primitive.
...
[0] Forgot the name again I'm horribly bad at remembering those
shortened C
As for LD_SHOW_AUXV=yes, I tried different combinations and it is
always ignored, no matter what.
Thanks for investigating. It might be related to elf notes supplied by
kernel.
FreeBSD 9 added these defines:
#define AT_CANARY 16 /* Canary for SSP. */
#define
It looks like a collision, namely between
AT_STACKPROT x AT_SECURE
Here's a possible patch to fix this. I haven't tested it yet. Does
this look like the right approach?
I also wonder if we should hunt down the other Linux-specific ELF
notes in that file.
I would say we should ignore all
Full build log at
https://buildd.debian.org/status/fetch.php?pkg=libpeasarch=kfreebsd-amd64ver=1.0.0-4stamp=1310550505
I'd appreciate if the kbsd porters could take a look.
Does not fail on my PC, also the 3rd build on buildd finished fine.
Petr
--
To UNSUBSCRIBE, email to
Does not fail on my PC, also the 3rd build on buildd finished fine.
It always fails on fasch, and seems to build fine on fano.
The difference have also been gcc-4.6 version.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble?
Thanks for the patch. But the issue isn't that it builds fine, rather to
be sure that it works. I think I remember this was the reason why we
didn't add it a few months ago.
Could you by chance test the package on kfreebsd-amd64?
Actually, I can't. I'm CCing debian-bsd. If someone who reads
First, take into account that the following bugfix needs to be in place in
order to continue: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=635173
Please, how you did build of ufsutils after that ?
The very important part of debian/rules of usfutils package is
***
#
I confirm problem bellow,
the attached c code does not have problem.
Petr
-- Forwarded message --
Date: Sat, 23 Jun 2012 16:23:36 +0300
From: Hleb Valoshka 375...@gmail.com
It looks like ruby-raindrops hangs on buildd because of issues with ruby1.9.1,
libc and SMP.
This very
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~
retitle 674541 ruby1.8: when compiled by gcc-4.7 threaded code segfaults under
kfreebsd-*
affects 674541 gcc-4.7
--
Hi,
I tried to reproduce under my 2-way SMP.
kfreebsd-image-8.1-1-amd64 8.1+dfsg-8+squeeze2
CPU - Intel(R) Core(TM)2 Duo CPU E6750
1000 rounds OK:
libc0.1
Package: procps
Version: 1:3.3.3-1
Severity: important
Tags: patch
User: debian-...@lists.debian.org
Usertags: kfreebsd
Hi,
the current version fails to build on GNU/kFreeBSD.
It needs small tweaks, see bellow.
Petr
--- proc/version.c
+++ proc/version.c
@@ -69,10 +69,10 @@
if
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
Yes, this problem is definitely KFreeBSD-specific. Cupt calls mkdir('/')
and expects EEXIST but get EISDIR [1]. This is not allowed by POSIX [2]
so I believe this is a bug in kfreebsd kernels.
I also guess I will have to implement a workaround for this but before
let's see what KFreeBSD
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
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) ||
Package: gcc-4.7
Version: 4.7.1-2
User: debian-...@lists.debian.org
Usertags: kfreebsd
Hi,
current gcc produces (at least on kfreebsd-amd64) misleading warning
during compilation of xserver-xorg-input-mouse.
It together with -Werror leads to #665390.
Attached please find reduced testcase, it
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
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
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-dist-requ...@lists.debian.org
with
-input-mouse - X.Org X server -- mouse input driver
xserver-xorg-input-mouse-udeb - X.Org X server -- mouse input driver (udeb)
xserver-xorg-input-mouse (1:1.7.2-3) unstable; urgency=medium
.
* Update bsd-array-bounds.diff patch to fix crashes on kfreebsd-*,
thanks to Petr Salinger (Closes
tags 570015 -help
found 570015 0.4.5-3
--
On Sun, 22 Jul 2012, Steven Chamberlain wrote:
As a quick and random test, I installed all tasksel options of
kfreebsd-amd64, and executed each binary from {,/usr}/[s]bin as a
non-privileged user inside a jail.
These next two are odd, as they appear
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
More importantly, there is the question you raised of whether this
should be done in userspace by libc instead. That would avoid
upstream having to wonder, why should we care what happens when
someone using a BSD4.3-style bind() calls our BSD4.4-style kernel?
So it's tempting.
For now I
More importantly, there is the question you raised of whether this
should be done in userspace by libc instead. That would avoid
upstream having to wonder, why should we care what happens when
someone using a BSD4.3-style bind() calls our BSD4.4-style kernel?
So it's tempting.
Yes, I think
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
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-dist-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
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
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
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
Package: xserver-xorg-video-nv
Version: 2.1.17-4
User: debian-...@lists.debian.org
Usertags: kfreebsd
Hi,
I tried the version from archive,
it simply crashes under current xorg, at least
with my card - NVIDIA Corporation G73 [GeForce 7300 GT].
I expect it is due to incompatible changes in
Just keeping you posted. The change looks reasonable, but the package
needs a separate ACK from the d-i team. Last I heard from them, they
requested that we hold all udebs for now.
It is a little problematic. The udeb is created only for
* hurd-i386 kfreebsd-amd64 kfreebsd-i386
And
1301 - 1400 of 1547 matches
Mail list logo
