Re: compiling out-of-tree kernel modules for kFreeBSD (was Re: Error during compiling kernel module at generating file vnode_if.h.)
2011/6/18 Benjamin Kaduk ka...@mit.edu: For stock FreeBSD, I can integrate with the bsd.kmod.mk system makefile which simplifies things greatly. Is there a similar standard mechanism by which to build an out-of-tree kernel module on Debian/kFreeBSD? You can use bsd.kmod.mk on Debian all the same. Make sure you have installed: freebsd-buildutils kfreebsd-headers-8.2-1-amd64 (= 8.2-2) then: SYSDIR=/usr/src/kfreebsd-headers-8.2-1-amd64/sys PATH=/usr/lib/freebsd:$PATH make For an example of this in action see: http://people.debian.org/~rmh/fuse/ (Note: this package still needs cleanup, but the build system works) -- Robert Millan -- 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/banlktikmxuqyjof0kltqwapepksjwdv...@mail.gmail.com
Bug#601803: patch for wireless support
Hi,
Robert Millan r...@debian.org writes:
Here's a backport of the wireless patch to freebsd-utils 8.1 (version used
in squeeze). Hopefully this helps you getting it tested.
# debdiff freebsd-utils_8.1-4.dsc freebsd-utils_8.1-4lindi1.dsc
diff -u freebsd-utils-8.1/debian/changelog freebsd-utils-8.1/debian/changelog
--- freebsd-utils-8.1/debian/changelog
+++ freebsd-utils-8.1/debian/changelog
@@ -1,3 +1,10 @@
+freebsd-utils (8.1-4lindi1) unstable; urgency=low
+
+ * Apply Robert Millan's patch from #601803 to fix
+wireless support.
+
+ -- Timo Juhani Lindfors timo.lindf...@iki.fi Fri, 17 Jun 2011 18:53:26
+0300
+
freebsd-utils (8.1-4) unstable; urgency=low
[ Petr Salinger ]
only in patch2:
unchanged:
--- freebsd-utils-8.1.orig/wireless.diff
+++ freebsd-utils-8.1/wireless.diff
@@ -0,0 +1,68 @@
+Index: debian/control
+===
+--- debian/control (revision 3465)
debian/control (working copy)
+@@ -7,7 +7,7 @@
+ libkvm-dev (= 8.1), libbsd-dev (= 0.2.0), libc0.1-dev (= 2.11.2),
+ flex | flex-old, kfreebsd-kernel-headers (= 0.51), libmemstat-dev,
libnetgraph-dev,
+ libipx-dev, libkiconv-dev, libgeom-dev, libdevstat-dev, libsbuf-dev,
libcam-dev (= 8.1),
+- libedit-dev, sharutils
++ libedit-dev, sharutils, libexpat1-dev
+ # libkvm-dev: dmesg
+ # libgeom-dev : ccdconfig
+ # libipx-dev: ifconfig
+@@ -17,6 +17,7 @@
+ # libsbuf-dev: mdconfig
+ # libcam-dev: camcontrol
+ # libedit-dev: pppctl
++# libexpat1-dev: ifconfig
+ Vcs-Browser: http://svn.debian.org/wsvn/glibc-bsd/trunk/freebsd-utils/
+ Vcs-Svn: svn://svn.debian.org/glibc-bsd/trunk/freebsd-utils/
+ Standards-Version: 3.9.1
+Index: debian/patches/002_ifconfig.diff
+===
+--- debian/patches/002_ifconfig.diff (revision 3465)
debian/patches/002_ifconfig.diff (working copy)
+@@ -29,21 +29,21 @@
+ +#SRCS+= ifgre.c # GRE keys etc
+ SRCS+= ifgif.c# GIF reversed header workaround
+
+--SRCS+= ifieee80211.c regdomain.c # SIOC[GS]IEEE80211 support
++ SRCS+= ifieee80211.c regdomain.c # SIOC[GS]IEEE80211 support
+ -DPADD+= ${LIBBSDXML} ${LIBSBUF} ${LIBJAIL}
+ -LDADD+= -lbsdxml -ljail -lsbuf
+--
+--SRCS+= ifcarp.c# SIOC[GS]VH support
+--SRCS+= ifgroup.c # ...
+--SRCS+= ifpfsync.c # pfsync(4) support
+-+#SRCS+= ifieee80211.c regdomain.c # SIOC[GS]IEEE80211 support
+ +#DPADD+= ${LIBBSDXML} ${LIBSBUF} ${LIBJAIL}
+ +#LDADD+= -lbsdxml -ljail -lsbuf
+++LDADD+= -lexpat -lsbuf
+ +
+ +#SRCS+= ifcarp.c# SIOC[GS]VH support
+ +#SRCS+= ifgroup.c # ...
+ +#SRCS+= ifpfsync.c # pfsync(4) support
+
++-SRCS+= ifcarp.c# SIOC[GS]VH support
++-SRCS+= ifgroup.c # ...
++-SRCS+= ifpfsync.c # pfsync(4) support
++-
+ -SRCS+= ifbridge.c # bridge support
+ -SRCS+= iflagg.c # lagg support
+ +#SRCS+= ifbridge.c # bridge support
+Index: debian/rules
+===
+--- debian/rules (revision 3465)
debian/rules (working copy)
+@@ -5,8 +5,8 @@
+ # Uncomment this to turn on verbose mode.
+ #export DH_VERBOSE=1
+
+-CFLAGS = -Wall -g -pipe -fPIC -I. -D_GNU_SOURCE -D'__FBSDID(string)='
+-CXXFLAGS = -Wall -g -pipe -fPIC -I. -D_GNU_SOURCE -D'__FBSDID(string)='
++CFLAGS = -Wall -g -pipe -fPIC -I. -D_GNU_SOURCE -D'__FBSDID(string)='
-D__va_list=__builtin_va_list
++CXXFLAGS = -Wall -g -pipe -fPIC -I. -D_GNU_SOURCE -D'__FBSDID(string)='
-D__va_list=__builtin_va_list
+
+ ifneq (,$(filter noopt,$(DEB_BUILD_OPTIONS)))
+ CFLAGS += -O0
but I still get
# ifconfig wlan0 create wlandev ath0
ifconfig: SIOCIFCREATE2: Bad address
Sources and binaries are at
http://iki.fi/lindi/kfreebsd/wireless/
if somebody else wants to try.
-Timo
--
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/84y60zfcqe@sauna.l.org
Bug#601803: patch for wireless support
2011/6/18 Timo Juhani Lindfors timo.lindf...@iki.fi: but I still get # ifconfig wlan0 create wlandev ath0 ifconfig: SIOCIFCREATE2: Bad address Sources and binaries are at http://iki.fi/lindi/kfreebsd/wireless/ It's no good if you just copy the patch instead of appliing it: rmh@thorin:/tmp/freebsd-utils-8.1$ patch -p0 wireless.diff patching file debian/control patching file debian/patches/002_ifconfig.diff patching file debian/rules -- Robert Millan -- 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/BANLkTi=iuyxq7t_v7sloh_etaeitt4u...@mail.gmail.com
Bug#609757: libmd in freebsd-libs?
I noticed libmd has its own directory in SVN. Is there any reason for not merging it in freebsd-libs? If it's because of Architecture: any setting, note that freebsd-libs already includes portable libraries (like libsbuf). -- Robert Millan -- 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/banlktikkdczjnmfbwj8uswds2vv1d1x...@mail.gmail.com
Bug#630907: bsd/stdio.h header protection breaks stdio.h when using libbsd overlay
Package: libbsd-dev
Version: 0.3.0-1
Severity: important
Tags: patch
See attached test case. Header protection in bsd/stdio.h may prevent
glibc stdio.h from being included in normal mode.
I recommend moving all header inclussions in libbsd out of the header
protected scope. Example attached for stdio.h but similar problems
may exist in other headers.
rmh@dimoni:/tmp$ gcc test.c -o test ./test
hi
rmh@dimoni:/tmp$ gcc test.c -o test $(pkg-config --cflags libbsd-overlay)
./test
In file included from /usr/include/grp.h:55:0,
from test.c:1:
test.c: In function ��main��:
test.c:7:3: warning: incompatible implicit declaration of built-in function
��fprintf�� [enabled by default]
test.c:7:12: error: ��stdout�� undeclared (first use in this function)
test.c:7:12: note: each undeclared identifier is reported only once for each
function it appears in
-- System Information:
Debian Release: wheezy/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: kfreebsd-amd64 (x86_64)
Kernel: kFreeBSD 8.2-1-amd64
Locale: LANG=ca_AD.UTF-8, LC_CTYPE=ca_AD.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages libbsd-dev depends on:
ii libbsd0 0.3.0-1utility functions from BSD systems
libbsd-dev recommends no packages.
libbsd-dev suggests no packages.
-- no debconf information
#include grp.h /* this drags in bsd/stdio.h in __need_FILE mode */
#include stdio.h /* we're including bsd/stdio.h, but nothing happens due to header protection */
main ()
{
fprintf (stdout, hi\n);
}
--- /usr/include/bsd/stdio.h~ 2011-06-18 18:35:26.310898171 +0200
+++ /usr/include/bsd/stdio.h 2011-06-18 18:35:05.635106136 +0200
@@ -24,18 +24,18 @@
* ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
*/
-#ifndef LIBBSD_STDIO_H
-#define LIBBSD_STDIO_H
-
-#include sys/cdefs.h
-#include sys/types.h
-
#ifdef LIBBSD_OVERLAY
#include_next stdio.h
#else
#include stdio.h
#endif
+#include sys/cdefs.h
+#include sys/types.h
+
+#ifndef LIBBSD_STDIO_H
+#define LIBBSD_STDIO_H
+
__BEGIN_DECLS
const char *fmtcheck(const char *, const char *);
Bug#630911: please provide link_ntoa()
Package: libbsd-dev Version: 0.2.0-1 Severity: wishlist Please provide link_ntoa() so that it can be removed from [freebsd-utils]/debian/patches/030_arp_libbsd.diff Implementation from FreeBSD is available in: http://svnweb.freebsd.org/base/head/lib/libc/net/linkaddr.c?revision=165903view=markup Thanks! -- System Information: Debian Release: 6.0.1 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores) Locale: LANG=ca_AD.utf8, LC_CTYPE=ca_AD.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libbsd-dev depends on: ii libbsd0 0.2.0-1utility functions from BSD systems libbsd-dev recommends no packages. libbsd-dev suggests no packages. -- no debconf information -- 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/20110618171046.6228.86413.reportbug@thorin
Re: Bug#629556: also getosreldate()
On Sat, Jun 18, 2011 at 04:58:12PM +0200, Robert Millan wrote: retitle 629556 please provide getvfsbyname() and getosreldate() thanks I start to wonder if all these functions have really their place in the GNU libc, as they are quite FreeBSD specific, while the functions there are supposed to functions common to all OS. Maybe it's the time to revive a specific freebsd library? Alternatively couldn't we have these directly in the NFS userland code? It's basically what is done on GNU/Linux. getosreldate() also needed by NFS userland code (both fixes are in SVN). Please revert that (or leave them disabled). Whatever the decision, we have to handle that with the 2.14 upload for versioning reasons. -- 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/20110618171558.ga32...@hall.aurel32.net
Re: Bug#629556: also getosreldate()
2011/6/18 Aurelien Jarno aurel...@aurel32.net: I start to wonder if all these functions have really their place in the GNU libc, as they are quite FreeBSD specific, while the functions there are supposed to functions common to all OS. Maybe it's the time to revive a specific freebsd library? I agree. But then why was libfreebsd merged into glibc? Alternatively couldn't we have these directly in the NFS userland code? Which functions are you referring to? getvfsbyname and getosreldate are not related to NFS (and getosreldate() is used in many places, I even had to implement a replacement in GRUB). getosreldate() also needed by NFS userland code (both fixes are in SVN). Please revert that (or leave them disabled). Whatever the decision, we have to handle that with the 2.14 upload for versioning reasons. Which functions should be removed/disabled? We have: Two userland functions (not NFS specific): getosreldate getvfsbyname Two syscall stubs: nfssvc nlm_syscall -- Robert Millan -- 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/banlktinvdx5_qitbdenv+7tkn5mkvip...@mail.gmail.com
Re: Bug#629556: also getosreldate()
I start to wonder if all these functions have really their place in the GNU libc, as they are quite FreeBSD specific, while the functions there are supposed to functions common to all OS. In theory yes, in practice no, from 2.14 NEWS: New Linux interfaces: clock_adjtime, name_to_handle_at, open_by_handle_at, syncfs, setns, sendmmsg Please revert that (or leave them disabled). Whatever the decision, we have to handle that with the 2.14 upload for versioning reasons. Which functions should be removed/disabled? We have: All, the 2.13-1 version have released 2011-05-01, they should wait for 2.14 Debian upload. Two userland functions (not NFS specific): getosreldate getvfsbyname They seems fine for me in our GNU libc. Two syscall stubs: nfssvc nlm_syscall They seems be used only by NFS specific code. I also wonder, whether they retain ABI across major releases. Petr -- 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/alpine.lrh.2.02.1106182145580.13...@sci.felk.cvut.cz
Re: Bug#629556: also getosreldate()
2011/6/18 Petr Salinger petr.salin...@seznam.cz: I also wonder, whether they retain ABI across major releases. If they don't, it might be easier to add the compatibility code in libc than it'd be to patch the utilities. And it's certainly easier than patching upstream code to use syscall(). -- Robert Millan -- 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/BANLkTimQ0y_q=gwxatxnvn01iuqfvdq...@mail.gmail.com
Re: Bug#629556: also getosreldate()
On Sat, Jun 18, 2011 at 07:25:45PM +0200, Robert Millan wrote: 2011/6/18 Aurelien Jarno aurel...@aurel32.net: I start to wonder if all these functions have really their place in the GNU libc, as they are quite FreeBSD specific, while the functions there are supposed to functions common to all OS. Maybe it's the time to revive a specific freebsd library? I agree. But then why was libfreebsd merged into glibc? We merged only some parts of it, the things that seems to be used widely. Other parts where implemented directly in freebsd-utils or freebsd-libs. Alternatively couldn't we have these directly in the NFS userland code? Which functions are you referring to? getvfsbyname and getosreldate are not related to NFS (and getosreldate() is used in many places, I even had to implement a replacement in GRUB). getosreldate is indeed use in various userland tools and probably has its place in the glibc. The other seems to be used only in NFS, one being clearly NFS specific. The thing is that when you add a new function to glibc, you can never remove it (at least not until the libc7 transition). We should not add new functions just because it's the easiest way to port code, but because it's the best way to do it. I am not fully convince for some of the functions that you want to add there. getosreldate() also needed by NFS userland code (both fixes are in SVN). Please revert that (or leave them disabled). Whatever the decision, we have to handle that with the 2.14 upload for versioning reasons. Which functions should be removed/disabled? We have: All of them. You can't add new functions at a random time, it has to be coordinated to a new version (2.14 in this case) to nt break symbol versioning. OTOH we do want to make some changes that do not break the ABI from the glibc-bsd SVN. Adding the new functions now means we can't do that any more until version 2.14. And we do have fixes pending there. This has to be either removed or disabled, committed in a different branch, or provided as a patch (for example glibc-2.14.patch) in the glibc-ports. We usually use the latter solution. Two userland functions (not NFS specific): getosreldate getvfsbyname Two syscall stubs: nfssvc nlm_syscall -- 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/20110618213510.gb32...@hall.aurel32.net
Re: Bug#629556: also getosreldate()
2011/6/18 Aurelien Jarno aurel...@aurel32.net: Which functions should be removed/disabled? We have: All of them. You can't add new functions at a random time, it has to be coordinated to a new version (2.14 in this case) to nt break symbol versioning. OTOH we do want to make some changes that do not break the ABI from the glibc-bsd SVN. Adding the new functions now means we can't do that any more until version 2.14. And we do have fixes pending there. This has to be either removed or disabled, committed in a different branch, or provided as a patch (for example glibc-2.14.patch) in the glibc-ports. We usually use the latter solution. I've already disabled them earlier today. -- Robert Millan -- 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/BANLkTikkRd5Wa-MNQxwE=j1+vbyrkqa...@mail.gmail.com
Bug#601803: patch for wireless support
Robert Millan r...@debian.org writes: It's no good if you just copy the patch instead of appliing it: rmh@thorin:/tmp/freebsd-utils-8.1$ patch -p0 wireless.diff patching file debian/control patching file debian/patches/002_ifconfig.diff patching file debian/rules Yes sorry about that. I'm obviously trying to triage too many bugs at once :-) I'm filing a bug on a boot problem soon, it kind of adds extra difficulty to testing this bug too. Anyways: # dpkg-source -x freebsd-utils_8.1-4.dsc dpkg-source: warning: extracting unsigned source package (freebsd-utils_8.1-4.dsc) dpkg-source: info: extracting freebsd-utils in freebsd-utils-8.1 dpkg-source: info: unpacking freebsd-utils_8.1.orig.tar.gz dpkg-source: info: applying freebsd-utils_8.1-4.diff.gz root@debian:/build/debian# cd freebsd-utils-8.1/ root@debian:/build/debian/freebsd-utils-8.1# patch -p0 ../wireless.diff patching file debian/control patching file debian/patches/002_ifconfig.diff patching file debian/rules root@debian:/build/debian/freebsd-utils-8.1# quilt applied No patches applied root@debian:/build/debian/freebsd-utils-8.1# quilt push -a Applying patch 001_dmesg.diff patching file sbin/dmesg/dmesg.c Applying patch 002_ifconfig.diff patching file sbin/ifconfig/Makefile patch: malformed patch at line 53: SRCS+= af_ipx.c# IPX support Patch 002_ifconfig.diff does not apply (enforce with -f) What am I missing now? -Timo -- 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/84mxheg1rp@sauna.l.org
