Bug#594168: Trang Bus error on kfreebsd-amd64
Package: trang Version: 2009-2 Severity: important X-Debbugs-CC: debian-bsd@lists.debian.org Hi, there is an Bus error from trang when building opendnssec package on kfreebsd-amd64. It prevents opendnssec to enter squeeze. It doesn't fail on any other platform. Full build log: https://buildd.debian.org/fetch.cgi?pkg=opendnssecver=1.1.1-2arch=kfreebsd-amd64stamp=1281683281file=log Ondrej -- Ondřej Surý ond...@sury.org -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktindhsxsoflq9xmnbb3in+atrhssavxzphfld...@mail.gmail.com
Re: Bug#594168: Trang Bus error on kfreebsd-amd64
severity 594168 serious thanks Ondřej Surý ond...@sury.org (24/08/2010): Package: trang Version: 2009-2 Severity: important X-Debbugs-CC: debian-bsd@lists.debian.org Regression on release architecture → serious, adjusting. there is an Bus error from trang when building opendnssec package on kfreebsd-amd64. It prevents opendnssec to enter squeeze. It doesn't fail on any other platform. It might be a transient issue, I'm giving it back. Mraw, KiBi. signature.asc Description: Digital signature
Re: Bug#594168: Trang Bus error on kfreebsd-amd64
On Tue, Aug 24, 2010 at 11:49:53AM +0200, Cyril Brulebois wrote: severity 594168 serious thanks Ondřej Surý ond...@sury.org (24/08/2010): Package: trang Version: 2009-2 Severity: important X-Debbugs-CC: debian-bsd@lists.debian.org Regression on release architecture → serious, adjusting. there is an Bus error from trang when building opendnssec package on kfreebsd-amd64. It prevents opendnssec to enter squeeze. It doesn't fail on any other platform. It might be a transient issue, I'm giving it back. It has just been built correctly. Closing the bug. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100824115507.gl19...@hall.aurel32.net
Bug#594183: can't build kernel modules
Package: freebsd-buildutils
Version: 8.1-1
Severity: normal
Hi there
I was trying to build cuse4bsd and freebsd-make gives this critical error:
cd: 1: can't cd to /usr/src/sys/x86_64/include
Kernel sources are in /usr/src/sys, but freebsd-make is looking at the wrong
directory. the directory for amd64 headers is /usr/src/sys/amd64/include. I had
a look at the included makefiles, and it seems the problem originates with
${MACHINE} variable which is x86_64 instead of amd64.
cuse4bsd has other problems, which I'm workng on, but you can reproduce this
with attached makefile.
Cheers
-- System Information:
Debian Release: squeeze/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: kfreebsd-amd64 (x86_64)
Kernel: kFreeBSD 8.1-1-amd64
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages freebsd-buildutils depends on:
ii bsdmainutils8.0.13 collection of more utilities from
ii libbsd0 0.2.0-1 utility functions from BSD systems
ii libc0.1 2.11.2-2 Embedded GNU C Library: Shared lib
ii make3.81-8 An utility for Directing compilati
ii original-awk2010-05-23-1 The original awk described in The
ii patchutils 0.3.1-2 Utilities to work with patches
ii unzip 6.0-4De-archiver for .zip files
freebsd-buildutils recommends no packages.
freebsd-buildutils suggests no packages.
-- no debconf information
SRCS=test.c
..include bsd.kmod.mk
Re: [Glibc-bsd-commits] r3162 - trunk/zfsutils/debian/patches
On 8/23/10, Aurelien Jarno aurel...@aurel32.net wrote: This makes zpool import work. The real problem here is NOT that /dev/ is not searched for. On FreeBSD scan is usually performed by geom_find_import(), and /dev is not searched unless that fails. The problem was that GNU realpath() fails for inexistant paths and BSD realpath() doesn't. Given the explanation you are giving there, I am not sure it is the correct fix. Given GNU realpath() behave differently than the BSD realpath() used in the original code, how about fixing the code that call realpath() to behave correctly with the GNU version? I'm sorry, this bug is a bit weird, I will try to explain better. This is what original code in zpool is doing: 1. Resolve /dev/dsk/ using realpath(). If realpath() reports that /dev/dsk/ does not exist, it aborts here. 2. Access the device using GEOM, instead of /dev/ nodes. If this suceeds, it ends here. I think this part was added by FreeBSD. 3. If GEOM failed, use the resolved path from step 1 to access the device with open()/read()/etc. /dev/dsk/ doesn't exist on FreeBSD, it's a Solaris directory. However, this is harmless because BSD realpath() is buggy and reports that the path has been correctly resolved. Then GEOM does the real job, so they don't notice. However with GNU realpath() zpool aborts in step 1. -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktin7sxwvr1=-bnwaaqq5q1vb0ukdx6npfhevr...@mail.gmail.com
Re: [Glibc-bsd-commits] r3162 - trunk/zfsutils/debian/patches
On Tue, Aug 24, 2010 at 03:06:26PM -0400, Tuco wrote: On 8/23/10, Aurelien Jarno aurel...@aurel32.net wrote: This makes zpool import work. The real problem here is NOT that /dev/ is not searched for. On FreeBSD scan is usually performed by geom_find_import(), and /dev is not searched unless that fails. The problem was that GNU realpath() fails for inexistant paths and BSD realpath() doesn't. Given the explanation you are giving there, I am not sure it is the correct fix. Given GNU realpath() behave differently than the BSD realpath() used in the original code, how about fixing the code that call realpath() to behave correctly with the GNU version? I'm sorry, this bug is a bit weird, I will try to explain better. This is what original code in zpool is doing: 1. Resolve /dev/dsk/ using realpath(). If realpath() reports that /dev/dsk/ does not exist, it aborts here. 2. Access the device using GEOM, instead of /dev/ nodes. If this suceeds, it ends here. I think this part was added by FreeBSD. 3. If GEOM failed, use the resolved path from step 1 to access the device with open()/read()/etc. /dev/dsk/ doesn't exist on FreeBSD, it's a Solaris directory. However, this is harmless because BSD realpath() is buggy and reports that the path has been correctly resolved. Then GEOM does the real job, so they don't notice. However with GNU realpath() zpool aborts in step 1. What worry me is that /dev/dsk is the default path, but the user can specify another one through some options. Is it going to work in that case? Also what happens if it fails opening the device through GEOM? Is it safe? -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100824191546.gr19...@hall.aurel32.net
Re: [Glibc-bsd-commits] r3162 - trunk/zfsutils/debian/patches
On 8/24/10, Aurelien Jarno aurel...@aurel32.net wrote: What worry me is that /dev/dsk is the default path, but the user can specify another one through some options. Is it going to work in that case? Yes, this already works without 10_dev_dsk.diff. Also what happens if it fails opening the device through GEOM? Without my patch it would try to use /dev/dsk/ (unless -d was used) and fail. With my patch it's supposed to work, but this hasn't been tested even on FreeBSD so I don't know. -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktikg66mycsyrmksg2nzmwfrctguwnx8w9qhyo...@mail.gmail.com
Re: Meeting Minutes for the IRC Release Team Meeting on August 23, 2010
Hi, 2) Which transitions are left for squeeze? What's their current state? - opencv: one FTBFS on hppa I confirmed this problem on porterbox. And I CCed to debian-h...@l.d.o, there is not yet the answer[0]. I think that it is a problem of gcc. I will remove of opencv/hppa if not settled. Best regards, Nobuhiro [0]: http://lists.debian.org/debian-hppa/2010/08/msg00036.html signature.asc Description: Digital signature
