Re: bind ALLOW_FILTER_AAAA_ON_V4 changed to ALLOW_FILTER_AAAA
On Sun, 17 Aug 2014, John D. Baker wrote:
Although built starting with a clean (nonexistent) OBJDIR/DESTDIR, the
resulting 'named' executable claims that filter--on-v4 was not
enabled at compile time and fails to start.
If one is doing an update build, it is important to remove not only
${OBJDIR}/external/bsd/bind, but also the relevant executables and
libraries from ${DESTDIR} as well, or you'll end up with the old,
non-enabled binary/libraries in your base.tgz set.
--
|/\ John D. Baker, KN5UKS NetBSD Darwin/MacOS X
|\ / jdbaker[snail]mylinuxisp[flyspeck]comOpenBSDFreeBSD
| X No HTML/proprietary data in email. BSD just sits there and works!
|/ \ GPGkeyID: D703 4A7E 479F 63F8 D3F4 BD99 9572 8F23 E4AD 1645
RiscOS FILECORE disk image needed
Subject says it all: I'm looking for a RiscOS FILECORE disk image that is mountable and readable on NetBSD with vnconfig -rc vnd0 image mount -r -t filecore /dev/vnd0d /mnt ls -la /mnt ... -- J. Hannken-Illjes - hann...@eis.cs.tu-bs.de - TU Braunschweig (Germany)
EuroBSDCon 2014 Early bird registrations deadline extended to August 25th
The early bird rates end for registrations to the EuroBSDCon 2014 conference has been extended until August 25th 2014. If you haven't registered already, you can still get the early bird rates if you register now! Please go to http://2014.eurobsdcon.org/registration/ and follow the prompts to complete your registration. Why you should go: EuroBSDcon is the premier European conference on the open source BSD operating systems attracting about 250 highly skilled engineering professionals, software developers, computer science students and professors, and users from all over Europe and other parts of the world. The goal of EuroBSDcon is to exchange knowledge about the BSD operating systems, facilitate coordination and cooperation among users and developers. Remember the first rule of EuroBSDCon: You talk about EuroBSDCon. Looking forward to see you in Sofia. On behalf of the EuroBSDCon 2014 program committee Martin Husemann
Re: Wedges enabled on -current
Hello. Could you provide an example of what you expect an /etc/fstab file entry to look like before and after your suggested edits? -thanks -Brian On Aug 18, 2:28am, Christos Zoulas wrote: } Subject: Wedges enabled on -current } Hi, } } Now that we have branched 7, I am planning to enable full wedge support for } kernels that used wedges before. What this means is that disks with mbr and } bsd labels will now create dkN devices for each partition in found. This } should be generally transparent, because fstab offers backwards compatibility } support. I.e. in the general case, your machine should boot and work fine } without requiring any changes. There are some corner cases: } } - there are not enough dk devices in /dev } (you can use MAKEDEV to create more) } - scripts that refer directly to sd wd raid etc devices } might break. } - your userland is from NetBSD-6 and a not recent (as of 6 months } ago current). } - something that we have not encountered before. } } If things don't work for you, please file a PR with a description of your } setup and how it fails, so we can fix it. } } If things work fine for you, you should eventually edit your fstab and } modify your entries to be of the form NAME=partition-name instead of } hard-coded devices (yes, for the traditional partition schemes these } are the names of the devices...). } } christos -- End of excerpt from Christos Zoulas
Re: Wedges enabled on -current
On Mon, Aug 18, 2014 at 08:41:35AM -0700, Brian Buhrow wrote: Hello. Could you provide an example of what you expect an /etc/fstab file entry to look like before and after your suggested edits? before it would use sd0a and sd0b (or wd*), after: NAME=sb2k5Root/a/ ffs rw,log 1 1 NAME=sb2k5Root/bnoneswapsw,dp0 0 (where in the example sb2k5Root is the disklabel name of sd0) Martin
Re: Wedges enabled on -current
In article 20140818155038.gq3...@mail.duskware.de, Martin Husemann mar...@duskware.de wrote: On Mon, Aug 18, 2014 at 08:41:35AM -0700, Brian Buhrow wrote: Hello. Could you provide an example of what you expect an /etc/fstab file entry to look like before and after your suggested edits? before it would use sd0a and sd0b (or wd*), after: NAME=sb2k5Root/a/ ffs rw,log 1 1 NAME=sb2k5Root/bnoneswapsw,dp0 0 (where in the example sb2k5Root is the disklabel name of sd0) Or if there is no name in the label, the device name without /dev/ as before. NAME=sd0a/ ffs rw,log 1 1 NAME=sd0bnoneswapsw,dp0 0 christos
Re: Building PCC for tools is broken (missing symbol __USE)- PCC bug or NetBSD source tree error?
On Mon, 18 Aug 2014, William D. Jones wrote:
also, you should probably use HAVE_GCC=48 since that is the version in
use, and the version number is checked sometimes for various features
I removed the conditional logic for MKGCC. I'll give a more complete update
later, but believe it or not, setting HAVE_GCC=48 while MKGCC=no and MKPCC=yes
actually causes the variable ${EXTERNAL_GCC_SUBDIR} (lib/Makefile, line 9) to
not be expanded AT ALL when searching for libgcc to add to the list of build
targets. This baffles me, because bs.own.mk in $NETBSD_SRC/share/mk has an
else statement which should prevent this at line 86-88, but the logic is not
firing. Setting HAVE_GCC=4 SEEMS to solve the problem- at least, libgcc gets
added to the list of targets and is found.
I think there is too much MKGCC conditional logic
Firstly, bsd.own.mk doesn't set EXTERNAL_GCC_SUBDIR if MKGCC=no .. the
.endif could move up a paragraph I think.
Then inside the libgcc directory there is some logic. I think the libgcc
directory should not be descended into if it is not required, rather than
descending into it and deciding we want out.
iain
Re: Wedges enabled on -current
On Mon, Aug 18, 2014 at 03:54:00PM +, Christos Zoulas wrote: In article 20140818155038.gq3...@mail.duskware.de, Martin Husemann mar...@duskware.de wrote: On Mon, Aug 18, 2014 at 08:41:35AM -0700, Brian Buhrow wrote: Hello. Could you provide an example of what you expect an /etc/fstab file entry to look like before and after your suggested edits? before it would use sd0a and sd0b (or wd*), after: NAME=sb2k5Root/a/ ffs rw,log 1 1 NAME=sb2k5Root/bnoneswapsw,dp0 0 (where in the example sb2k5Root is the disklabel name of sd0) Or if there is no name in the label, the device name without /dev/ as before. NAME=sd0a/ ffs rw,log 1 1 NAME=sd0bnoneswapsw,dp0 0 Is label: fictitious no name?
Re: Building PCC for tools is broken (missing symbol __USE)- PCC bug or NetBSD source tree error?
I'm not sure why if MKPCC=yes and HAVE_PCC=yes, ./build.sh still wants
libgcc, but I'll look into it. In any case, the solution I proposed is
simply a stopgap until PCC can compile userland.
Right now, there's at least four ways NetBSD can in theory be built:
GCC tools, GCC release
LLVM tools, LLVM release (undocumented?)
PCC tools, PCC release
EXTERNAL tools, GCC release
I figured getting GCC tools to compile PCC- again, as a stopgap solution-
should be as simple as swapping the GCC target with the PCC target, in the
appropriate Makefile. Since GCC can compile PCC just fine, all other
dependencies could be left alone. However, this does not appear to be the
case. Even after modifying bsd.mk.own and lib/Makefile, if MKPCC=yes,
MKGCC=no, and HAVE_GCC=48 (indeed I had to move the .endif in bsd.own.mk-
good catch), the build complains about a missing libgcc.
I suppose the only option for now is to compile both and just delete GCC
manually after install.
-Original Message-
From: Iain Hibbert
Sent: Monday, August 18, 2014 12:23 PM
To: William D. Jones
Cc: current-users@netbsd.org
Subject: Re: Building PCC for tools is broken (missing symbol __USE)- PCC
bug or NetBSD source tree error?
On Mon, 18 Aug 2014, William D. Jones wrote:
also, you should probably use HAVE_GCC=48 since that is the version in
use, and the version number is checked sometimes for various features
I removed the conditional logic for MKGCC. I'll give a more complete
update
later, but believe it or not, setting HAVE_GCC=48 while MKGCC=no and
MKPCC=yes
actually causes the variable ${EXTERNAL_GCC_SUBDIR} (lib/Makefile, line 9)
to
not be expanded AT ALL when searching for libgcc to add to the list of
build
targets. This baffles me, because bs.own.mk in $NETBSD_SRC/share/mk has an
else statement which should prevent this at line 86-88, but the logic is
not
firing. Setting HAVE_GCC=4 SEEMS to solve the problem- at least, libgcc
gets
added to the list of targets and is found.
I think there is too much MKGCC conditional logic
Firstly, bsd.own.mk doesn't set EXTERNAL_GCC_SUBDIR if MKGCC=no .. the
.endif could move up a paragraph I think.
Then inside the libgcc directory there is some logic. I think the libgcc
directory should not be descended into if it is not required, rather than
descending into it and deciding we want out.
iain
--
William D. Jones
Rowan University | ECE | 2012
Member IEEE
Member Tau Beta Pi
thor0...@comcast.net
Message sent using 'Windows Live Mail' client.
Re: More amd64 drmkms radeon
On Fri, Aug 15, 2014 at 04:47:42PM +0100, Patrick Welche wrote: On Fri, Aug 15, 2014 at 04:09:03PM +0100, Robert Swindells wrote: What does it do now ? Now it panics (and rebuilt the X server with symbols just in case): It (radeon) no longer panics! P
Re: Building PCC for tools is broken (missing symbol __USE)- PCC bug or NetBSD source tree error?
On Mon, Aug 18, 2014 at 6:27 PM, William D. Jones thor0...@comcast.net wrote: I'm not sure why if MKPCC=yes and HAVE_PCC=yes, ./build.sh still wants libgcc, but I'll look into it. In any case, the solution I proposed is simply a stopgap until PCC can compile userland. Right now, there's at least four ways NetBSD can in theory be built: GCC tools, GCC release LLVM tools, LLVM release (undocumented?) PCC tools, PCC release EXTERNAL tools, GCC release I got quite confused by the PCC config. I was trying to compile rump kernel using EXTERNAL_TOOLCHAIN but it does not respect that and still tries to compile gcc (I am fairly sure that all of the rump kernel can be compiled by pcc alone but I can provide an external gcc too). Will have another look at it. Justin
Re: Adding firmware for USB ethernet to RPI install image
The file size error disappeared on its own without me having to change MEMORY_DISK_ROOT_SIZE (I have not done a CVS checkout since this morning). I'm not sure I understand, but I'll take my luck and run with it :P. -Original Message- From: William D. Jones Sent: Monday, August 18, 2014 11:49 AM To: Martin Husemann Cc: port-...@netbsd.org Subject: Re: Adding firmware for USB ethernet to RPI install image Well, indeed I do have a rather long path that I use to get to my source tree, but I'm a bit skeptical that it added 302,700 bytes to my image. I don't have the means to verify it right now, so for the time being I'll just increase the size of MEMORY_DISK_ROOT_SIZE again in my own personal tree so ./build.sh stops complaining. -Original Message- From: Martin Husemann Sent: Monday, August 18, 2014 8:46 AM To: William D. Jones Cc: port-...@netbsd.org Subject: Re: Adding firmware for USB ethernet to RPI install image On Mon, Aug 18, 2014 at 08:06:50AM -0400, William D. Jones wrote: As of today at 8:05 AM EDT today, I get the following error when compiling release for RPI: got symbols from netbsd-RPI_INSTALL.tmp mapped netbsd-RPI_INSTALL.tmp armv6--netbsdelf-eabihf-mdsetimage: fs image (9113600 bytes) too big for buffer (8806400 bytes) Was there changes made since the commit 3 days ago that further increased the fs image size? Hmm, the autobuild just completed successfull, so I guess not. However, if the size is borderline and you are not using MKREPRO=yes, a long path to the source directory might cause a few strings embeded in binaries to get slight longer - in that case we should bump the size again slightly. But I think Jörg is currently working on getting rid of this hard coded limits, so maybe this will not be needed any more. Martin -- William D. Jones Rowan University | ECE | 2012 Member IEEE Member Tau Beta Pi thor0...@comcast.net Message sent using 'Windows Live Mail' client. -- William D. Jones Rowan University | ECE | 2012 Member IEEE Member Tau Beta Pi thor0...@comcast.net Message sent using 'Windows Live Mail' client.
Re: Wedges enabled on -current
Now that we have branched 7, I am planning to enable full wedge support for kernels that used wedges before. What this means is that disks with mbr and bsd labels will now create dkN devices for each partition in found. This should be generally transparent, because fstab offers backwards compatibility support. I.e. in the general case, your machine should boot and work fine without requiring any changes. There are some corner cases: - there are not enough dk devices in /dev (you can use MAKEDEV to create more) - scripts that refer directly to sd wd raid etc devices might break. - your userland is from NetBSD-6 and a not recent (as of 6 months ago current). - something that we have not encountered before. If things don't work for you, please file a PR with a description of your setup and how it fails, so we can fix it. If things work fine for you, you should eventually edit your fstab and modify your entries to be of the form NAME=partition-name instead of hard-coded devices (yes, for the traditional partition schemes these are the names of the devices...). I've used NAME=partition-name in /etc/fstab and mount commands with NetBSD 6.99.x: works with GPT but not MBR. Also, NAME does not work with mount_msdos as in mount_msdos NAME=WD2G02 /media/zip0 # does not work, but mount -t msdos NAME=WD2G02 /media/zip0 # good My NetBSD-current amd64 (6.99.44) on USB stick became corrupted with unreadable sectors, so I installed anew, for both amd64 and i386, onto hard drive partitions, building from NetBSD-6.99.44 i386 on USB stick, with src tree, xsrc and pkgsrc also on hard drive, FreeBSD partition. It was August 11, and I was expecting 6.99.49 or 6.99.50 but got 7.99.1 (I knew the branching was nigh), which is where I am now. I really like partition names in Linux better, and FreeBSD still better, with disk name followed by partition number, rather than one string of dk wedges (NetBSD) or drive letters (DOS, OS/2, eComStation, MS-Windows). OpenBSD is off my charts for lack of GPT support. Mobile racks, USB drives and eSATA hard-drive enclosures can upset wedge numbers or DOS-style (including OS/2, eComStation and Windows) drive letters. I checked out netbsd-7 src and xsrc just a couple hours ago, am not really decided between releng-7 and HEAD (7.99.x), but am of the impression that there is no going back from 7.99.1, I'd have to install 7.0_BETA fresh on a new partition, but have plenty of space on 3 TB hard drive. I've given up on NetBSD 6.x and 5.x. Tom
Re: Wedges enabled on -current
Date:Mon, 18 Aug 2014 18:51:03 -0700 (PDT) From:Thomas Mueller mueller6...@bellsouth.net Message-ID: 959079.28761...@smtp115.sbc.mail.bf1.yahoo.com | Also, NAME does not work with mount_msdos as in | mount_msdos NAME=WD2G02 /media/zip0 # does not work, but | mount -t msdos NAME=WD2G02 /media/zip0 # good IMO, the mount_xxx commands should be moved to /libexec and never used by humans, mount -t is enough - given that, who does the translation from the NAME= to the current underlying hardware device name is irrelevant, | Mobile racks, USB drives and eSATA hard-drive enclosures can upset wedge | numbers or DOS-style (including OS/2, eComStation and Windows) drive | letters. And linux and FreeBSD drive/partition names as well ... that's why the switch to using volume names, which can remain constants, regardless of how the hardware moves around. We're not there yet, df/dump/... still operate on dkN names, rather than labels (dump is particularly troublesome, saving /dev/dk23 in /etc/dumpdates is particularly useless...) but eventually all this stuff should get fixed as well, and all that should ever be visible will be the labels. I don't much like the NAME= syntax, but such is the price of backward compatability. kre
