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
--
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]
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:
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
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.
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
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
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
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
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
***
#
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
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?
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
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
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.
anjuta 2:3.0.3.0-1 currently ftbfs on kbsd-*.
The strange thing is that in scripts/build-schemas.mk:
%.gschema.xml: %.ui
$(AM_V_GEN)$(top_srcdir)/scripts/builder2schema.pl $ $(prefs_name)
$(srcdir)/$(prefs_keyfile) $@
But during make in plugins/build-basic-autotools
Aka the $(srcdir)/$(prefs_keyfile) is passed as ./
I would say that there is a problem in build rules of anjuta.
Any idea why only the kbsd-* buildds fail?
On Linux:
$ od -ax /tmp/
od: /tmp/: read error: Is a directory
000
On GNU/kFreeBSD
$ od -ax /tmp/ | head
000 ack can sub nul
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
Fixed upstream in
New Revision: 223145
URL: http://svn.freebsd.org/changeset/base/223145
http://lists.freebsd.org/pipermail/svn-src-all/2011-June/040283.html
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact
Forcing the upgrade does not seem to break DHCP interfaces.
However, lo0 no longer works:
IMHO, the best way to solve this is to have os-specific set of
commands, which ifupdown execute.
It would allow us to stop wrapping ifconfig and route
and install them directly.
For previous problems
On GNU/kFreeBSD ifconfig and route commands are available.
The syntax is (should be) the same as in upstream:
http://www.freebsd.org/cgi/man.cgi?query=ifconfig
http://www.freebsd.org/cgi/man.cgi?query=route
So it's mostly compatible with Linux ifconfig/route?
Mostly, but see [1], i.e.
If you want to help getting it fixed in sid, you can test
kfreebsd-8 8.2-1.1 in experimental.
It have been reported againts 8.2-1.1 primarily ;-)
We need to make sure the GCC upgrade didn't cause any
regression before new sid uploads can be made.
Nobody objected so far, it have been
Do you think the patch in #628954 should be included? I asked
upstream if they plan to MFC it, and got no response.
I see no reason for not including it, especially, as you need it and
tested it on your machine ;-)
Petr
--
To UNSUBSCRIBE, email to
Forcing the upgrade does not seem to break DHCP interfaces.
However, lo0 no longer works:
IMHO, the best way to solve this is to have os-specific set of
commands, which ifupdown execute.
It would allow us to stop wrapping ifconfig and route
and install them directly.
For previous problems see
From: Mattias Welponer matt...@welponer.net
To: Petr Salinger petr.salin...@seznam.cz
Subject: Re: AFP support
Hi Petr,
the package is working fine, no problems so fare. I use the same
configuration files as with Debian/Linux before. Everything is working
fine.
Thanks for your help,
Mattias
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
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 -
-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
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.
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,
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
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
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
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 @@
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
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
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
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
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
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
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: gmt
Version: 4.5.5-1
Severity: important
Tags: patch
User: debian-...@lists.debian.org
Usertags: kfreebsd
Hi,
the current version fails to build on GNU/kFreeBSD.
Please update configure.ac as shown bellow
and regenerate configure.
It would also be nice if you can ask upstream
to
notfound 619792 4.6.0~rc1-3
--
The failure is on kfreebsd-amd64 with 4.6.0-1,
but the 4.6.0~rc1-2, 4.6.0~rc1-3 have been fine.
All tried on fash. The difference is used gcc-4.5.
Failed builds used gcc-4.5_4.5.2-7,
the previous used gcc-4.5_4.5.2-6.
Petr
--
To UNSUBSCRIBE, email to
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
reassign 616323 apr 1.4.2-6
notfound 616323 1.2.11-1
severity 616323 serious
tags 616323 - moreinfo help
affects 616323 php5 apache2
--
Please could you try to rebuild php5 with PHP5_COMPAT=yes in debian/rules ?
It does help.
On both kfreebsd-i386 and kfreebsd-amd64:
#define __INO_T_TYPE
When libapache2-mod-php5 is loaded, with every trivial HTTP request
(fetch of http://localhost/ in default apache2 install), one of the
apache2 children segfaults, as registered in /var/log/apache2/error.log:
Please could you try to rebuild php5 with PHP5_COMPAT=yes in
debian/rules ?
On
applied, however this reverts somehow the change in the kfreebsd-gnu patch.
In the gcc-4.5 this part in kfreebsd-gnu patch have been:
- x86_64-*-kfreebsd*-gnu) tm_file=${tm_file} kfreebsd-gnu.h ;;
+ x86_64-*-kfreebsd*-gnu) tm_file=${tm_file} kfreebsd-gnu.h
i386/kfreebsd-gnu.h ;;
The failure on kfreebsd-amd64 seems be due to incomplete config.gcc
after recent cleanup.
The config.gcc for kfreebsd-i386 does not have this problem,
but the build log is not shown on buildd.d.o.
Petr
--- src/gcc/config.gcc
+++ src/gcc/config.gcc
@@ -1293,7 +1293,7 @@
case ${target}
The failure on kfreebsd-i386 is a different one:
make[4]: *** [check-recursive] Error 1
make[4]: Target `check' not remade because of errors.
make[4]: Leaving directory
`/build/buildd-gcc-4.6_4.6-20110227-1-kfreebsd-i386-oLsZOn/gcc-4.6-4.6-20110227/build/i486-kfreebsd-gnu/libstdc++-v3'
user debian-...@lists.debian.org
usertag 613094 + kfreebsd
--
Hi,
please could provide also your linking command and related package list.
I tried
gcc b.c -Wall -O2 /usr/lib/atlas-base/libcblas.a /usr/lib/atlas-base/libatlas.a
gcc b.c -Wall -O2 -lcblas
and provided C example seems be fine
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.
Hello.
In glib2.0 2.28.0-1,
there is already the code for (native) FreeBSD.
It only remains to change defined(__FreeBSD__)
into defined(__FreeBSD__) || defined(__FreeBSD_kernel__) in
gio/gunixcredentialsmessage.c and
gio/gunixcredentialsmessage.c
Petr
--
To UNSUBSCRIBE, email to
:25 +0100 (CET)
From: Petr Salinger petr.salin...@seznam.cz
To: Nicolas Barbier nicolas.barb...@gmail.com
Cc: Emanuele Balla ba...@staff.spin.it, debian-...@lists.debian.org
Subject: Re: Postgresql deying access
2011-02-11 12:12:50 CET LOG: could not get peer credentials:
Interrupted system call
Similarly for me, the workaround also works.
linux-image-2.6.32-5-amd64 2.6.32-30
In standard sequence:
input: Macintosh mouse button emulation as /devices/virtual/input/input0
input: AT Translated Set 2 keyboard as
/devices/platform/i8042/serio0/input/input1
input:
Package: libva
Version: 1.0.8-1
Severity: important
Tags: patch
User: debian-...@lists.debian.org
Usertags: kfreebsd
Hi,
the current version fails to build on GNU/kFreeBSD.
Please find attached patch with tweaks.
Petr
--- libva-1.0.8.orig/va/va_backend_tpi.h
+++
kFreeBSD 8.2 has v4l already, its header is in
sys/compat/linux/linux_videodev.h
Shouldn't we provide this header instead of disabling v4l?
It provides v4l interface, but libva needs v4l2 ...
Petr
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of
Please let us know what is your preferred approach.
Please, do the same as already done for
http://www.debian.org/ports/mips/
http://www.debian.org/ports/mipsel/
I.e. 301 Moved Permanently
Thanks
Petr
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a
Hi Robert,
the update of kfreebsd sysdeps is not sufficient,
it also have to be exported with proper versioned symbol.
In the Versions file should be i.e.
GLIBC_2.13 {
jail_attach;
jail_remove;
jail_get;
jail_set;
}
Petr
--
To UNSUBSCRIBE, email to
Apologies if I'm missing something obvious, but should
alter_to_native_keymap() not revert all of the changes made by
alter_to_debian_keymap() rather than just a couple of them?
It should generate the same sequences as before,
but it does not have use the same way for it.
The us.iso.kbd have
Apologies if I'm missing something obvious, but should
alter_to_native_keymap() not revert all of the changes made by
alter_to_debian_keymap() rather than just a couple of them?
It should generate the same sequences as before,
but it does not have use the same way for it.
The us.iso.kbd have
fixes failure of init.d script
if kbdcontrol is removed but not purged
as pointed out by Sven Joachim [2].
Petr
[1] http://lists.debian.org/debian-release/2011/01/msg00090.html
[2] http://lists.debian.org/debian-bsd/2011/01/msg00070.html
freebsd-utils (8.1-4) unstable; urgency=low
[ Petr
Therefore I think it should be fixed as soon as possible. IMHO the best
way to fix that is to remove the stub for at* functions as we don't want
to support 7.x kernel anymore.
This fix is long-term-fix. But I do not agree to do it now, for squeeze
glibc. The other packages behaviour/code_path
That's indeed another option. Clint, what do you think about it? Note
it's only something temporary until we fix the real issue on eglibc.
If the only downside is that fakeroot will be broken when backported
to earlier kFreeBSD versions (were there any without the stub functions?)
then it seems
reassign 610749 eglibc
severity 610749 serious
thanks
The problems is triggered by the new version of tar that is present only
in sid, squeeze is not affected. However given the packages are built in
a sid chroot, we might be in trouble, especially given the package has
been uploaded almost 50
The integration should be into /etc/init.d/kbdcontrol,
by adding two targets, like keymap-native and keymap-debian.
May be it can be run even semi-automatically, by
detecting whether the /etc/inittab uses cons25 or cons25-debian
and noop or alter keymap.
Yes, I like the latter (auto detection)
./setup/__init__.py:isfreebsd = 'freebsd' in sys.platform
That's indeed the right point to fix, and once we find a better
condition, I'll send that upstream. We don't actually care about the
kernel in calibre, so a better hack would be to just pin isfreebsd
to False and islinux to True in the
tags 609557 + patch
user debian-...@lists.debian.org
usertag 609557 + kfreebsd
--
Hi,
please apply attached patch for now.
It would be very nice if you can inform upstream
about this problem. The support for multiple OSes
really needs cleanup:
./setup/__init__.py:isfreebsd = 'freebsd' in
Hi,
please could you do upload the proposed patch together
with some security update.
(CVE-2010-3853, CVE-2010-3316 CVE-2010-3430 CVE-2010-3431 CVE-2010-3435)
The patch clearly affects only GNU/kFreeBSD systems.
See also #596142, #598901, #596382.
Cheers
Petr
--
To UNSUBSCRIBE,
Package: gcc-4.4
Version: 4.4.5-8
Hi,
the current gcc-4.4 uses (tested on i386/4.4.5-6 and kfreebsd-i386/4.4.5-8)
as a default arch i586.
COLLECT_GCC_OPTIONS='-v' '-dD' '-E' '-mtune=generic' '-march=i586'
echo | gcc-4.4 -dD -x c -E - | grep 86
#define __DBL_MAX__ 1.7976931348623157e+308
I believe, that even plain i486 have to be supported,
also changelog claims that default should still be i486.
yes, I think I did change that to avoid libgomp failures, which requires
i586, and not just i486. Not sure what to do about that for squeeze.
Just document it in release
The change for freebsd-utils will be some new script like
kbdcontrol -d | sed ... | kbdcontrol -l
kbdcontrol -f 61 ESC[3~
TERM=cons25-debian
Attached is the mentioned script. It have to be run directly on console
or by sh keymap-policy.sh /dev/console
The keymap is altered system wide,
Hi.
Background:
The plain FreeBSD kernel generates different sequences
for Backspace and Delete keys compared to Linux (and required by Policy).
Generated sequences can be altered by kbdcontrol (from freebsd-utils
source package) and the default sequences are of course in kernel
(kfreebsd-8
1) plain cons25 variant: current sysvinit, ncurses 5.7+20100313-4 or
5.7+20100313-5
and kfreebsd-8 8.1+dfsg-6 (or 8.1+dfsg-7.1), freebsd-utils 8.1-2
[...]
2) cons25-debian variant: needs patched sysvinit, ncurses 5.7+20100313-5,
and kfreebsd-8 8.1+dfsg-7, freebsd-utils 8.1-3
[...]
3)
severity 608428 important
user debian-...@lists.debian.org
usertag 608428 + kfreebsd
--
So, this looks like a bug in the mount/umount utilities and/or the
kfreebsd mount/nmount/umount system calls.
Possible explanation: there's an 80 char buffer being used which causes
the truncation. The
It's really rather odd that the userspace structures (assuming FreeBSD
doesn't use the same header for the kernel too, which I'm not sure is
right)
It does :-(
have such inconsistent and restrictive lengths compared with
what's technically permitted by the actual mount/umount system calls.
How long is that going to take? In the meantime, console users of
GNU/kFreeBSD are screwed whenever they connect to other systems, since
that means they must change their TERM variable _and_ their backspace
key is broken.
I've attached the necessary patches to create the cons25-debian
The cons25-debian seems be fine for me, as it should be only local
change for one release of Debian GNU/kFreeBSD. The next one will not
use it.
Any name is fine with me as long as ncurses upstream accepts it.
The next debian release will be based on FreeBSD 9.x kernel, with
TERM=xterm, so
It seems that current plain FreeBSD kernel generates events
that fully corresponds to cons25 entry.
It just uses different definitions for kbs and kdch1 wrt Linux,
Linux: kbs=\177 kdch1=\E[3~
FreeBSD/cons25 kbs=^H kdch1=\177
Emacs, for instance, does not expect ^H to mean delete
You really can't just unilaterally change the cons25 terminfo entry. If
this proposed change is implemented, people running stock FreeBSD will
have their consoles broken if they log into a Debian system. If
kFreeBSD needs different settings than the stock cons25 entry, it needs
to create and
The changes to the kFreeBSD console and the kbdcontrol package (see
#605065 and #605777) need to be accompanied by changing the cons25
terminfo entry accordingly, otherwise ncurses-based programs severely
misbehave.
You really can't just unilaterally change the cons25 terminfo entry. If
this
tags 570015 + patch
--
Great! I have reported to BTS, but let me repeat also here:
$ ssh n...@kfreebsd uptime
never fails to provoke a segfault at kfreebsd running GNU/kFreeBSD.
Could this merit upgrading to important? Could it be that ConsoleKit
mixes GNU/Linux and FreeBSD in autoconf?
Please can you try whether xhost +local: before gksu gnome-system-log
does help for you ?
Yes, it works then.
Before:
$ gksu gnome-system-log
kvm_open: kvm_nlist: No such file or directory
No protocol specified
(gnome-system-log:8938): gnome-system-log-CRITICAL **: Unable to parse
Please consider uploading it also into testing-proposed-updates.
I don't think this bug qualifies for release critical.
I see. I am of course biased ;-)
On a bit unrelated note: does consolekit, aside from this issue, work
properly on kfreebsd?
Are new sessions created when you login,
The keymap in kernel will be fixed and fkey61 will generate
the Debian defined sequence after next upload.
But also the files in /usr/share/syscons/keymaps/ have to be modified
backspace/scan code 14 - should generate del (0x7F)
delete on numpad/scan code 83 - should generate ./, and fkey61
Hi.
For kfreebsd-amd64 it suffices to pass --disable-jemalloc
during configure.
Please could you disable jemalloc on non-linux platforms.
The malloc is used internally in pthread library ...
Petr
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of
This code did not exist in 0.96-3 so maybe you just need to ask
upstream to think about how they want to this on non-Linux systems?
The code have been added by commit
http://cgit.freedesktop.org/PolicyKit/commit/?id=4a9e4f72db4ec00500d9334f7411a086d7c81d0f
It looks like the whole signalfd()
reassign 600365 libgksu 2.0.13~pre1-2
tags 600365 + patch
affects 600365 gksu
--
Hi,
the problem have been also detected on plain FreeBSD.
See http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/141149
And the same fix/workaround also works for current libgksu.
Please apply soon.
Thanks in
201 - 300 of 1547 matches
Mail list logo
