Re: build.sh now NETBSDSRCDIR/mk.conf if present
On Wed, Jul 19, 2023 at 03:12:12AM +1000, Luke Mewburn wrote: > I've enhanced build.sh to support using mk.conf in the same directory > (i.e., the top level of the source tree) if present, instead of > /etc/mk.conf. Thank you! -- David A. Holland dholl...@netbsd.org
Re: Weird clock behaviour with current (amd64) kernel
On Thu, Jul 14, 2022 at 08:59:25PM +0700, Robert Elz wrote: > I just booted a kernel that I built (from up to date at the time) > HEAD sources about 24 hours ago. > > Everything seemed to be working fine - until I noticed that all of > my clocks (there are several, gkrellm, window manager, a dclock, > and an xtu) were all wildly wrong (as in, were moving time forwards > incredibly slowly). Probably not related, but see PR 56322. I have a machine where the TSC is apparently bad, and somewhere in -current a bit more than a year ago we stopped detecting that during boot, with negative consequences. I used to get boot messages of the form autoconfiguration error: ERROR: 2607 cycle TSC drift observed and these stopped, so if your previous kernel was fairly old and you still have older boot logs lying around you might check them for such notices. -- David A. Holland dholl...@netbsd.org
Re: readlink(1) realpath(1) and POSIX
On Mon, Jul 18, 2022 at 07:43:52PM -, Christos Zoulas wrote: > > POSIX's hope is that if we do this, FreeBSD will take the code > > back, and the other BSD variants might follow, and the end result > > might be (mksh aside) a reasonably consistent world. > > Thanks for doing all this work. I agree we should default to what coreutils > is doing and default to -E to make the world more homogeneous. FWIW, I agree, but it also sounds like larts should be handed out all around. Too bad one can't actually do that in standards committee meetings :-| -- David A. Holland dholl...@netbsd.org
Re: File system corruption due to UFS2 extended attributes
On Mon, May 23, 2022 at 09:47:37PM -0700, Chuck Silvers wrote: > So what can we do about this? There aren't any really great > options. But the only change which will guarantee that all old > NetBSD releases (which do not know about extend attributes) will > not corrupt file system images where extended attributes have been > stored is to create a new variant of UFS2 with a different magic > number (the "fs_magic" field in the superblock). This is what I > propose to do. I spoke with Kirk McKusick about this problem and > he agreed that creating a new UFS2 variant with a different magic > number is the best way to deal with this situation. On the minus side, this means all FreeBSD volumes (which do know about extended attributes) will be treated as NetBSD 9 volumes (which don't). There probably isn't any way around this, and it isn't the first time this has happened, including for UFS1 (e.g. the wapbl bit), so maybe we just ought to have our own format going forwards, since this: : /* : * NOTE: COORDINATE ON-DISK FORMAT CHANGES WITH THE FREEBSD PROJECT. : */ repeatedly hasn't worked. But in that case the names of options and whatnot should be set up accordingly and the default should be our format. We did a migration like this with partition types years ago and AFAICR it wasn't perfect but wasn't a trainwreck either. also, a quibble: > - fsck will take a new option "-c ea" to specify that an existing UFS2 >file system should be converted to support extended attributes >(ie. converted to UFS2ea). The migration code really belongs in tunefs rather than fsck. :-| -- David A. Holland dholl...@netbsd.org
Re: reproducible kernel crash with quota
On Thu, Apr 14, 2022 at 01:09:02PM +0200, J. Hannken-Illjes wrote: > I'm quite sure you have a /etc/fstab with "userquota,groupquota", yes? > > with gdb: > > frame 4 (dqflush()) > print dq->dq_ump->um_quotas[0] > print dq->dq_ump->um_quotas[1] > > gives the same vnode address for both fields, yes? > > If this is the case the attached diff should help, since 2012-01-30 > group quota got enabled on the user quota file. ...ooops -- David A. Holland dholl...@netbsd.org
Re: panic: kernel diagnostic assertion VOP_ISLOCKET(vp) == LK_EXCLUSIVE
On Sat, Apr 16, 2022 at 03:37:51PM -, Michael van Elst wrote: > >+ vn_lock(vp, LK_EXCLUSIVE | LK_RETRY); > >VOP_CLOSE(vp, oflags, kauth_cred_get()); > >- vrele(vp); > >+ vput(vp); > > Sounds like an open-coded version of vn_close(). It's not, it's a driver open opening a device vnode by hand; doesn't/can't use vn_open() so it shouldn't use vn_close()... -- David A. Holland dholl...@netbsd.org
Re: Status of NetBSD virtualization roadmap - support jails like features?
On Fri, Apr 15, 2022 at 07:36:15AM +0200, Matthias Petermann wrote: > However, this week I read a post on Reddit[2] that was a bit disturbing to > me. Meaningfully, it proclaims that the main development platform for nvmm > is now DragonflyBSD rather than NetBSD. It also claims that the > implementation in NetBSD is now "stale and broken". As you can find in the comments on the Reddit post, what actually happened is that a certain person left here in a huff. > Regardless, I still think it wouldn't hurt if NetBSD could implement some > sort of jail. In general I agree, but it's not clear what and how much, and really the first thing that needs to be done is a general reform of kauth and that obstructs everything else :-| -- David A. Holland dholl...@netbsd.org
Re: error upgrading packages on current / pkg database
On Fri, Apr 15, 2022 at 01:42:55PM -0400, Greg Troxel wrote: > That can work too, but either way all the cross-package data linkage may > not be quite right. ...at which point which you do "pkg-admin rebuild-tree" :-) -- David A. Holland dholl...@netbsd.org
Re: Automated report: NetBSD-current/i386 build failure
On Thu, Jul 22, 2021 at 10:32:37AM +0200, Reinoud Zandijk wrote: > > > it looks like CVS randomly didn't commit some of my changes, > > > investigating... > > > > Yeah, not sure what happened; something caused it to, apparently, > > think a few of the files in the second changeset still had the > > original checkout timestamps. This makes it completely blind to any > > changes in them (even if you run cvs diff explicitly) until you touch > > the files. > > [...] > > Why would other version systems not suffer from this same issue > when the date stamps are somehow wrong? Because they're more careful. e.g.: % touch -r file ref % echo 'more' >> file % touch -r ref file % hg status M file ? ref % -- David A. Holland dholl...@netbsd.org
Re: Automated report: NetBSD-current/i386 build failure
On Mon, Jul 19, 2021 at 12:42:49AM +, NetBSD Test Fixture wrote:
> This is an automatically generated notice of a NetBSD-current/i386
> build failure.
>
> The failure occurred on babylon5.netbsd.org, a NetBSD/amd64 host,
> using sources from CVS date 2021.07.18.23.57.34.
>
> An extract from the build.sh output follows:
>
> ${MAKEDIRTARGET} . ${SUBDIR_GROUP.${:U}:C/^/dependall-/}
> ${MAKEDIRTARGET} . ${SUBDIR_GROUP.${:U}:C/^/install-/}
> ${MAKEDIRTARGET} . ${SUBDIR_GROUP.${:U1}:C/^/dependall-/}
> ${MAKEDIRTARGET} . ${SUBDIR_GROUP.${:U1}:C/^/install-/}
> ${MAKEDIRTARGET} . ${SUBDIR_GROUP.${:U11}:C/^/dependall-/}
> ${MAKEDIRTARGET} . ${SUBDIR_GROUP.${:U11}:C/^/install-/}
> ${MAKEDIRTARGET} . ${SUBDIR_GROUP.${:U111}:C/^/dependall-/}
> ${MAKEDIRTARGET} . ${SUBDIR_GROUP.${:U111}:C/^/install-/}
> ${MAKEDIRTARGET} . ${SUBDIR_GROUP.${:U}:C/^/dependall-/}
> ${MAKEDIRTARGET} . ${SUBDIR_GROUP.${:U}:C/^/install-/}
> ${MAKEDIRTARGET} . ${SUBDIR_GROUP.${:U1}:C/^/dependall-/}
> ${MAKEDIRTARGET} . ${SUBDIR_GROUP.${:U1}:C/^/install-/}
> *** [build_install] Error code 1
> nbmake[4]: stopped in /tmp/build/2021.07.18.23.57.34-i386/src/lib
> 1 error
that is... less than helpful :-(
it looks like CVS randomly didn't commit some of my changes,
investigating...
--
David A. Holland
dholl...@netbsd.org
Re: 9.99.86 HEAD
On Fri, Jul 02, 2021 at 07:53:05AM +0100, Chavdar Ivanov wrote: > On a system from yesterday, I am still getting > > Jul 2 04:17:17 ymir /netbsd: [ 49713.7540485] panic: kernel > diagnostic assertion "cnp->cn_nameptr[0] != '\0'" failed: file > "/home/sysbuild/src/sys/kern/vfs_lookup.c", line 1301 What file system? And what were you doing? That ought to be impossible (obviously, hence the assertion) but since it clearly isn't, knowing more about the circumstances will make it easier to figure out what's wrong. (In particular, knowing what the path is and if it's exercising any of the non-default parsepath calls will be helpful...) I just went through lookup_fastforward and don't see any way it can happen :-( -- David A. Holland dholl...@netbsd.org
Re: 9.99.86 HEAD
On Thu, Jul 01, 2021 at 07:59:29PM +, David Holland wrote: > On Thu, Jul 01, 2021 at 07:04:24PM +0000, David Holland wrote: > > However, except in the fastforward code the vnode will be locked. So I > > think it should be "= = =" in vnode_if.src. If you also need to add > > FSTRANS=NO, that should be fine too. > > I'm testing this: That's committed, along with a fix for at least the most overt zfs problems. -- David A. Holland dholl...@netbsd.org
Re: 9.99.86 HEAD
On Thu, Jul 01, 2021 at 07:04:24PM +, David Holland wrote:
> However, except in the fastforward code the vnode will be locked. So I
> think it should be "= = =" in vnode_if.src. If you also need to add
> FSTRANS=NO, that should be fine too.
I'm testing this:
diff -r bb3a26d8fb23 sys/kern/vnode_if.src
--- a/sys/kern/vnode_if.src Wed Jun 30 13:24:14 2021 -0400
+++ b/sys/kern/vnode_if.src Thu Jul 01 15:56:26 2021 -0400
@@ -60,9 +60,10 @@
};
#
-#% parsepath dvp L L L
+#% parsepath dvp = = =
#
vop_parsepath {
+ FSTRANS=NO
IN struct vnode *dvp;
IN const char *name;
OUT size_t *retval;
--
David A. Holland
dholl...@netbsd.org
Re: 9.99.86 HEAD
On Wed, Jun 30, 2021 at 05:57:46PM +, David Holland wrote: > Sorry, that patch of mine seems to have been pretty broken. Not > entirely sure how it managed to pass the test runs... maybe I tested > the wrong kernel or something (?) And for the record it looks like I did test the wrong kernel. Still not sure how :-| -- David A. Holland dholl...@netbsd.org
Re: 9.99.86 HEAD
On Thu, Jul 01, 2021 at 07:54:33PM +0200, J. Hannken-Illjes wrote:
> lookup_fastforward -> lookup_parsepath -> VOP_PARSEPATH -> ... ->
> fstrans_start
Bleh. I had a feeling we were going to end up regretting that
fastforward code. :-|
> According to vnode_if.src VOP_PARSEPATH(dvp...) should take a locked vnode
> but here this lock is missing. So either
>
> - make sure the vnode is locked so fstrans_start will no loner block.
>
> or
>
> - add FSTRANS=NO to vop_parsepath, file kern/vnode_if.src and allow unlocked
> vnodes:
>
> vop_parsepath {
> + FSTRANS=NO
> IN struct vnode *dvp;
>
> David?
I thought the vnode was locked readonly in the fastforward path. Did I
misread? Or is that not good enough?
Anyway, I think it's probably ok to change vop_parsepath to not
require locked vnodes at all. The only parsepath operation that does
anything other than string ops is rumpfs's, and it takes etfs_lock to
look in some tables that etfs_lock covers. Unless that's going to
interact badly with fstrans without the vnode lock covering it (seems
unlikely, but IDK) there shouldn't be a problem.
However, except in the fastforward code the vnode will be locked. So I
think it should be "= = =" in vnode_if.src. If you also need to add
FSTRANS=NO, that should be fine too.
--
David A. Holland
dholl...@netbsd.org
Re: bmake inefficiencies
On Fri, Jan 29, 2021 at 03:10:09PM -0800, Simon J. Gerraty wrote: > > It should probbaly suffice to call Job_CatchChildren after a SIGCHLD. > > It is a common misstake to assume that SIGCHLD will be receieved for each > > child - which is why looping in Job_CatchChildren is important. > > This means there will always be a wasted waitpid per call to > > Job_CatchChildren. > > The following is a minimal patch that should mitigate the waitpid calls > suggestions for better names welcome. > : > static sigset_t caught_signals; /* Set of signals we handle */ > +static volatile int reap_children; "static volatile sig_atomic_t reap_children;" but also, I would expect that this childExitJob.outPipe can go away. -- David A. Holland dholl...@netbsd.org
Re: bmake inefficiencies
On Fri, Jan 29, 2021 at 11:22:40PM +0100, Roland Illig wrote: > > 1. spurious waitpid > > > > when doing buildkernel I counted the following: > > 7010 cases of error code 0 (== nothing to do) > > 371 cases of ECHILD > > 1526 cases of reaping > > I'm not familiar enough with waitpid, so I will not touch this topic. > Simon? wait is pretty basic unix :-p not sure what if anything I should explain... Anyway the issue here is that make already has at least two ways to know whether there's anything to wait for: first (at least in jobs mode) it will get EOF on the child's output pipe, and second, it also catches SIGCHLD. It might be necessary to try waiting a second time, because it might not be able to know how many children have exited (depends if they all trigger some EOF or just most of them) but it should not need to blindly call waitpid every time through the main select/poll loop. Right now the SIGCHLD handler works by writing into a pipe that the main loop polls, which is pretty grotty. It shouldn't need to do anything other than set a global (of type sig_atomic_t, to be portable) to 1. The delivery of a signal should cause all select and poll variants to fail with EINTR (that is, stop for attention) even if nothing else is pending. It's possible that it doesn't need the SIGCHLD handler at all; if every exiting subprocess triggers some EOF, the event loop will always wake up and make can know from the EOF reporting that it should call wait. However, this might make it harder to share code between jobs mode and non-jobs mode, since in non-jobs mode it's definitely not the case that every subprocess has a pipe. (I'm not sure how much of the jobs/non-jobs copypasting you've cleaned up lately, if any, since I'm way behind on reading the diffs.) -- David A. Holland dholl...@netbsd.org
Re: [HEADS UP] pkgsrc default database directory changed
On Mon, Dec 07, 2020 at 11:23:38AM +0100, Matthias Petermann wrote: > while I think the change makes sense (if I understand it correctly, it will > make it easier for me in the future to switch between different PKG > locations including the corresponding metadata just by renaming the > respective /usr/pkg directory), It doesn't do that unless you also change VARBASE. (and note that packages respecting the setting of VARBASE is hit-or-miss so it doesn't necessarily help that much to change it) -- David A. Holland dholl...@netbsd.org
Re: GCC 9 enabled for x86 and arm platforms.
On Sun, Sep 13, 2020 at 07:13:31PM +1000, matthew green wrote: > > Would -r flag in build.sh command be sufficient to ensure a clean build? > > > > Something like > > ===> build.sh command:./build.sh -m amd64 -B nb899-20190723 -M ../obj > > -T ../tooldir -r -U distribution kernel=SANDY7 > > this is probably good enough. > > -r removes tooldir and destdir. the lack of -u means > you're doing a cleandir which should mean it rebuilds > everything else. That's not always sufficient. Because the clean rules (most of them anyway) specifically remove $(OBJS) rather than *.o, and do similar things for other build products, after changes stuff can get left behind by cleandir. Occasionally it's not harmless stuff. Deleting the whole obj tree before a full build doesn't cost very much and it's a good precaution with large changes. -- David A. Holland dholl...@netbsd.org
Re: anoncvs access
On Sat, Jul 25, 2020 at 11:18:32AM +0100, Chavdar Ivanov wrote: > Perhaps I've missed some announcement; is there any problem with the > access to anoncvs.netbsd.org at the moment? I had the same yesterday > as well: We had a fairly catastrophic hardware failure yesterday; everything should be back up now. -- David A. Holland dholl...@netbsd.org
Re: Remove fortune quotes attributed to or providing admiration of Adolf Hitler [pr bin/52735]
On Sun, Nov 19, 2017 at 08:35:49PM -0500, William D. Jones wrote: > > SJW > Took this thread long enough to play "those evul Ess Jay DoubleUs" card. Please keep your partisan politics out of this, both of you. It's a serious matter. > And Hitler's actions in life especially cannot be written off as a > difference in opinion, dissent, or otherwise up for debate. The > implications of his quotes matter. YES, THAT'S THE POINT. -- David A. Holland dholl...@netbsd.org
Re: Remove fortune quotes attributed to or providing admiration of Adolf Hitler [pr bin/52735]
On Sat, Nov 18, 2017 at 01:21:25PM +0100, Rhialto wrote: > I checked our fortune cookies database, and I was appalled to notice > that we do have the same quotes there. Apart from those quotes being > wholly inappropriate in a list of funny quotes, they are probably > illegal in Germany (where I now happen to live). > > I hereby propose to remove them (but not remove all fortunes). > I have sent a pr (bin/52735, http://gnats.netbsd.org/52735) with a > patch. You are completely missing the point of why those quotes are there. -- David A. Holland dholl...@netbsd.org
Re: bind -> unbound/nsd
On Sun, Aug 21, 2016 at 10:28:39AM -0400, Thor Lancelot Simon wrote: > On Fri, Aug 19, 2016 at 06:13:13PM +0200, Joerg Sonnenberger wrote: > > On Fri, Aug 19, 2016 at 09:55:48AM +0100, Roy Marples wrote: > > > For example, I would use nsd on exactly one machine in my environment, > > > my public facing DNS server which is exactly where it belongs. > > > > > > On the other hand, all my other BSD machines run unbound as a local > > > caching resolver. > > > > To slightly expand that. You don't need nsd if you just want to serve a > > few local host names for a local network. You only need nsd if you want > > to provide an authoritive DNS server. IMO that is a decently small use > > case that it doesn't justify the incluse into the base system. > > I am strongly opposed to removing basic server functionality present > in BSD Unix for over 30 years -- and still in widespread use -- from NetBSD. > I don't mind replacing BIND but all its functionality should be replacd. > > If you want to have to guess which version of basic Internet server > software might happen to be on the system you're working on today, Linux > is -->over there. So for what it's worth: I don't see any need to have a DNS server in base. It may be traditional, but few people use it; the landscape's changed since the days where it was something you'd have on e.g. a department LAN along with a mail server and ftp server. And unlike e.g. removing the mailer daemon, there's nothing in base that depends on having local DNS service and also there's nothing that the DNS server gains from being in base. Plus, IMO, it's better to handle things that require frequent patching in pkgsrc because it's a lot easier to keep them up to date. (And yes, I serve some authoritative DNS from netbsd, so I have a stake in this game too.) -- David A. Holland dholl...@netbsd.org
Re: needbuf ?
On Sun, Jun 12, 2016 at 11:11:08PM +0100, Patrick Welche wrote: > I manage to repeatably freeze (100% idle) a -current/amd64 box with > (sysutils/diskscrub) > > # scrub /dev/raid0a You may find rraid0a works better. At this point the block devices are useful only for mounting and they should probably all be folded together. Writing to the block device *shouldn't* deadlock, but it's not really expected to work... -- David A. Holland dholl...@netbsd.org
Re: kqueue: SIGIO?
On Wed, Sep 30, 2015 at 11:28:35PM +0700, Robert Elz wrote: > It also fits with the only safe thing that's really possible to do in a > single handler being to set a variable and return (or exit the process) > (ie: the main loop has to check a variable anyway, whether signal delivery > is traditional, or via Mouse's suggested mechanism). > > The issue with it is how one would ever safely clear the variable again, > while avoiding race conditions - An atomic read-modify-write cycle; other than vintage cpus have these in hardware. Anyhow, infiniband had to come up with some scheme for this; borrowing that rather than reinventing it (or not borrowing it if it sucks, instead of reinventing it by accident) seems like a good starting point. -- David A. Holland dholl...@netbsd.org
Re: old file system , old partition tables, and some old scsi drive
On Thu, Sep 17, 2015 at 08:45:16PM +0430, Mohsen Pahlevanzadeh wrote: > Dear All, > I need to list old partition tables and old fs to put into netbsd kernel. > How can I provide them? You are best off forgetting about partition tables. Instead, figure out where the beginnings and ends of the partitions are (maybe on the original machine with its disklabel tools) and then copy those sections of the disk onto new partitions of the same size on another disk. In any case, there is zero chance that anything from the 80s that has ffs on it has a MSDOS FDISK partition table. You're better off using disklabel(8) and hoping you can find a BSD-type disklabel. -- David A. Holland dholl...@netbsd.org
Re: dynamically created /dev/null is a regular file
On Wed, Jun 24, 2015 at 04:43:17PM -0600, Brook Milligan wrote: I have been installing some -current systems (cvs from 201505311600Z to be exact) that dynamically construct /dev when booting. This seems to be the default behavior of rc when /dev is effectively empty. The problem is that /dev/null routinely ends up being a regular file not a device file. How and when are the device files created and why is null created wrongly? Could it have been created somehow before the rest of the devices are created dynamically? Is this related to kern/33023? It might be; but given that this mode gets used a fair amount, and also that the device should be getting created in the top of the unionfs, I would guess more likely not. I would do a quick look for something (e.g. in your shell startup files) that's clobbering /dev/null somehow. I had a horrible intermittent problem with this at one point until I discovered that less would do it for you if you linked .lesshst to /dev/null... -- David A. Holland dholl...@netbsd.org
Re: language lawyering: ftello/fseek/pread edition
On Mon, Mar 23, 2015 at 04:55:52PM +0100, Thomas Klausner wrote: Thanks. So if it survives a build, can I commit the attached patch? I question the merits of _LARGEFILE_SOURCE (are we going to start mucking with _FILE_OFFSET_BITS too?) but whatever. -- David A. Holland dholl...@netbsd.org
Re: a separate build of libc
On Mon, Sep 22, 2014 at 10:05:47PM +0200, u-6...@aetey.se wrote: If what you are trying to do is port NetBSD's libc to a different OS, please say so, because that has been done before and we can give you a much better idea what it entails. No, this is not the case. (I guess you mean Minix or was there another effort?) I personally have used NetBSD's libc in two different research OSes, and I'm not the only person to have done that. The Minix thing happened much later. If what you are trying to do is reorganize the NetBSD sources so that libc is a clearly defined component instead of being casually mixed with the kernel, please say so, because that has been done before and we can give you a much better idea what it entails. This looks much nearer to what I do. I take piece by piece, not only the libc but everything, carefully avoiding artificial/redundant interconnections (like unrelated libraries sharing the same directory, if such an illustration helps). If you are doing neither of these things, I must say I haven't the slightest idea what you're trying to accomplish, and it might be helpful to explain. I would be thankful for suggestions of how to extract all the necessary and only the necessary source needed to build libc (among others not the source for the binaries being used to build - unless they are to contain hardcoded knowledge about the internals of the libc to be build, I expect not :) I hope that by now I have learned enough to be able to do this on my own but extra pointers are of course appreciated. I still don't really understand what you're trying to accomplish, but here goes: - the libc sources are in src/lib/libc - some additional sources are in src/common/lib/libc - you will also need the base includes (src/include) and the main kernel includes (src/sys/sys, src/arch/*/include) - you may need other kernel includes (e.g. src/sys/ufs/*/*.h or src/sys/uvm/*/*.h) Some of the material in src/include is not actually libc (e.g. util.h is for libutil) but you will need to sort this out on a file-by-file basis. Similarly, much of the material in the kernel headers is actually just kernel internals but you will also need to sort this out on a file-by-file basis. A good starting point is to take the header files that are installed by make includes (you can safely ignore those that aren't) and strip out all the parts that are #ifdef _KERNEL. You'll need a fairly thorough understanding of Unix and Unix library interfaces (both historical and as reflected in various standards) to get this right. It's not a small undertaking, and it's not something a newbie can reasonably expect to be able to do. -- David A. Holland dholl...@netbsd.org
Re: Permission problems and questions on 7.99.1 and 7.0_BETA
On Wed, Aug 20, 2014 at 02:17:25AM -0700, Thomas Mueller wrote: I notice strange problems not being able to run things like mpop, msmtp, or even man as nonroot because of Permission denied on trying to create temporary file. Has anybody else noticed it? Problem was not present on NetBSD 6.99.44 amd64 and i386. No. Nobody else has noticed it. You broke something; but we can't tell what or why because you don't report what goes wrong accurately, don't answer questions intended to help diagnose your problems, and don't follow advice people offer to help sort things out but instead do other random things leading to further problems and don't state clearly what you did. At this point I'm unwilling to even offer suggestions because of the likelihood of being blamed for whatever happens when you don't follow them. -- David A. Holland dholl...@netbsd.org
sysinst heads up
The sysinst sources have been moved to src/usr.sbin, and sysinst is now installed in /usr/sbin on a running system. The intent of this is to allow using it to install chroots and VM images; however, for the moment running it out of /usr/sbin isn't really good for much of anything. (Except, maybe, clobbering the running system...) Make sure you have all of the sysinst commits (or none of them) -- the intermediate states probably aren't compilable. -- David A. Holland dholl...@netbsd.org
Re: options DIAGNOSTIC
On Fri, Jul 25, 2014 at 09:33:35PM -0700, Paul Goyette wrote: It seems that we are not at all consistent about the comments on the options DIAGNOSTIC lines! What I find most interesting in the following is 34 config files claim that the DIAGNOSTIC checks are expensive while 50 files claim that they are [Cc]heap! (More than 150 other files make no claim at all on the magnitude of cost.) I fixed the i386 and amd64 ones already, and I just fixed internally consistency checks as that's ungrammatical. It might be nice if all configs had the same descriptions and comments for everything, but it isn't very practical to try to keep them all in sync. -- David A. Holland dholl...@netbsd.org
Re: options DIAGNOSTIC
On Sat, Jul 26, 2014 at 09:21:08PM -0700, Paul Goyette wrote: I fixed the i386 and amd64 ones already, and I just fixed internally consistency checks as that's ungrammatical. Thanks! It might be nice if all configs had the same descriptions and comments for everything, but it isn't very practical to try to keep them all in sync. Well, true, but having totally contradictory descriptions (expensive vs cheap) is pretty bad! Thanks for fixing. Yeah, they should all get set back to cheap. There was a while when DIAGNOSTIC became expensive, and some but not all of the descriptions were changed to reflect that, but it was wrong and so they should all be switched back... There are still some that say expensive; theoretically we should wait for people who know about the platforms involved (evbarm, evbmips, evbppc, evbsh3, ews4800mips, hpcsh, hppa, ia64, iyonix, playstation2, sgimips) to confirm that DIAGNOSTIC is not in fact expensive on those. -- David A. Holland dholl...@netbsd.org
Re: Preparation for creating netbsd-7 branch
On Mon, Jul 21, 2014 at 05:57:52PM +0200, Joerg Sonnenberger wrote: Preparing and testing such upgrade mechanism would be a bit boring work (there are few developers who care releases and sysinst itself) so I'm afraid no one will take it... For the ones in base, compat versions should exist in /usr/lib/XXX. Redirection magic exists. Not for old versions of libs. (Also, last I checked, sufficiently old i386 bins don't run on amd64 because COMPAT_xx for old xx isn't present.) -- David A. Holland dholl...@netbsd.org
Re: uhso(4) locking issues
On Sat, Jul 19, 2014 at 06:11:42PM +0100, Iain Hibbert wrote: Nope, because the uhso driver does not do any locking directly.. there is USB locking and TTY locking which must interact and I am not sure what work has been done to make drivers MPSAFE in general. The tty code isn't (and is a big mess) ... but what do other drivers that are ttys do? There are a lot of them, so there must be something different about uhso... -- David A. Holland dholl...@netbsd.org
Re: Automated report: NetBSD-current/i386 build failure
On Sat, Jul 12, 2014 at 10:51:00PM +, NetBSD Test Fixture wrote: This is an automatically generated notice of a NetBSD-current/i386 build failure. --- dependall-libexec --- /tmp/bracket/build/2014.07.12.20.31.04-i386/src/sbin/fsck_lfs/lfs.c:88:20: fatal error: fsutil.h: No such file or directory #include fsutil.h % grep fsutil.h sbin/fsck_lfs/*.c sbin/fsck_lfs/dir.c:#include fsutil.h sbin/fsck_lfs/inode.c:#include fsutil.h sbin/fsck_lfs/lfs.c:#include fsutil.h sbin/fsck_lfs/main.c:#include fsutil.h sbin/fsck_lfs/pass0.c:#include fsutil.h sbin/fsck_lfs/pass1.c:#include fsutil.h sbin/fsck_lfs/pass2.c:#include fsutil.h sbin/fsck_lfs/pass4.c:#include fsutil.h sbin/fsck_lfs/pass5.c:#include fsutil.h sbin/fsck_lfs/pass6.c:#include fsutil.h sbin/fsck_lfs/setup.c:#include fsutil.h sbin/fsck_lfs/utilities.c:#include fsutil.h All of those except for lfs.c have been there for years. Anyone want to suggest what's different about lfs.c? -- David A. Holland dholl...@netbsd.org
Re: Automated report: NetBSD-current/i386 build failure
On Sun, Jul 13, 2014 at 12:43:49AM +, David Holland wrote: sbin/fsck_lfs/utilities.c:#include fsutil.h All of those except for lfs.c have been there for years. Anyone want to suggest what's different about lfs.c? yeah, what's different is that it's .PATH'd in by lfs_cleanerd. grmbl. -- David A. Holland dholl...@netbsd.org
Re: fs/vfs/renamerace* tests
On Mon, Jul 07, 2014 at 04:23:22PM -0700, Paul Goyette wrote: The test code still indicates that these tests are expected to fail for udf, however the tests are actually passing successfully (at least in my amd64 test-bed). [1] Have these tests been fixed (perhaps by accident)? Or, if they are still expected to fail, do we have any other explanation of why they're not failing? A test run I did around the same time you posted this included both fs/vfs/t_renamerace:udf_renamerace and fs/vfs/t_renamerace:udf_renamerace_dirs in the *un*expected failures output. FWIW. As far as I know udf hasn't been fixed (or touched at all in quite a while) -- David A. Holland dholl...@netbsd.org
Re: Building doc failed
On Sun, Jul 06, 2014 at 08:45:47AM +0200, Kurt Schreiner wrote:
Hi,
tried build.sh ... distribution on i386 with -current source updated
some minutes ago. This failed in ../nvi/docs/USD.doc/edit:
woops; please try again with version 1.66 of bsd.doc.mk...
hm, better, but not really correct. ;-)
Now checkflist failed as all .png and .html files are missing:
checkflist === distrib/sets
== 333 missing files in DESTDIR
Files in flist but missing from DESTDIR.
File wasn't installed ?
--
./usr/share/doc/papers/mckusick84-ffs/mckusick84-ffs-9.png
./usr/share/doc/papers/mckusick84-ffs/mckusick84-ffs.html
[...]
./usr/share/doc/usd/vi/vitut8.png
./usr/share/doc/usd/vi/vitut9.png
end of 333 missing files ==
--- checkflist ---
*** [checkflist] Error code 1
Urgh, this is going to be a pain.
--
David A. Holland
dholl...@netbsd.org
Re: Building doc failed
On Sun, Jul 06, 2014 at 07:46:37AM +, David Holland wrote: Now checkflist failed as all .png and .html files are missing: checkflist === distrib/sets == 333 missing files in DESTDIR Files in flist but missing from DESTDIR. File wasn't installed ? -- ./usr/share/doc/papers/mckusick84-ffs/mckusick84-ffs-9.png ./usr/share/doc/papers/mckusick84-ffs/mckusick84-ffs.html [...] ./usr/share/doc/usd/vi/vitut8.png ./usr/share/doc/usd/vi/vitut9.png end of 333 missing files == --- checkflist --- *** [checkflist] Error code 1 Urgh, this is going to be a pain. or, not so much actually - should be fixed now -- David A. Holland dholl...@netbsd.org
Re: Automated report: NetBSD-current/i386 build failure
On Sat, Jul 05, 2014 at 10:21:35PM +, NetBSD Test Fixture wrote: --- docinstall --- # install docinstall /tmp/bracket/build/2014.07.05.20.45.49-i386/tools/bin/i486--netbsdelf-install -U -M /tmp/bracket/build/2014.07.05.20.45.49-i386/destdir/METALOG -D /tmp/bracket/build/2014.07.05.20.45.49-i386/destdir -h sha256 -N /tmp/bracket/build/2014.07.05.20.45.49-i386/src/etc -c -r -o root -g wheel -m 444 curses.txt /tmp/bracket/build/2014.07.05.20.45.49-i386/destdir/usr/share/doc/reference/ref3/curses/curses.txt i486--netbsdelf-install: curses.txt: stat: No such file or directory *** [docinstall] Error code 1 nbmake[7]: stopped in /tmp/bracket/build/2014.07.05.20.45.49-i386/src/lib/libcurses/PSD.doc I'm trying to figure out why this doesn't happen in my tree. -- David A. Holland dholl...@netbsd.org
Re: pulseaudio 4.0 requires udev was: Re: Help for PR kern/46606 is needed
On Mon, Jan 06, 2014 at 05:04:05PM +0200, Jukka Ruohonen wrote: It fails with the following errors (from firefox and mplayer). I feel pulseaudio 4.0 may not work on NetBSD. According to http://www.freedesktop.org/wiki/Software/PulseAudio/Notes/3.0/ Support for HAL has been removed. This shouldn't affect anyone, but if it does, please configure PulseAudio to use udev instead. module-hal-detect still exists for maintaining configuration file compatibility, but all it does is to load module-udev-detect. module-hal-detect may get completely removed in 4.0. udev is required. NetBSD has no udev. So they've finally dropped BSD support. It only remains interesting what components are next in line. HAL isn't exactly BSD support. What does it use udev for? -- David A. Holland dholl...@netbsd.org
Re: NetBSD-HEAD amd64 refuses to build
On Mon, Dec 09, 2013 at 08:20:28AM +, mueller6...@bellsouth.net wrote: I keep failing in recent days to update NetBSD-HEAD amd64 from source, Previous recent attempts resulted in internal compiler error. This time, [...] I still don't understand what you're trying to do, or why you're apparently surprised it doesn't work. -- David A. Holland dholl...@netbsd.org
Re: amd64 build break - liblfs/ulfs_quota2.c
On Fri, Oct 18, 2013 at 10:14:51PM +0300, Andreas Gustafsson wrote: Paul Goyette wrote: /test-bed/src/sys/rump/fs/lib/liblfs/../../../../ufs/lfs/ulfs_quota2.c: In function 'getq2h': /test-bed/src/sys/rump/fs/lib/liblfs/../../../../ufs/lfs/ulfs_quota2.c:162:6: error: 'needswap' undeclared (first use in this function) The build is still failing, even with src/sys/ufs/lfs/ulfs_quota2.c 1.14: /tmp/bracket/build/2013.10.18.17.48.44-i386/src/sys/rump/fs/lib/liblfs/../../../../ufs/lfs/ulfs_quota2.c: In function 'dq2clear_callback': /tmp/bracket/build/2013.10.18.17.48.44-i386/src/sys/rump/fs/lib/liblfs/../../../../ufs/lfs/ulfs_quota2.c:662:6: error: 'needswap' undeclared (first use in this function) Christos did it wrong :-) mrg has a patch, not sure when he's intending to commit it. -- David A. Holland dholl...@netbsd.org
Re: getty changes seem to have broken amd64
On Sun, Aug 11, 2013 at 08:39:20AM -0700, Paul Goyette wrote: When booting the generic kernel in qemu, we get the following, and never seem to get login prompt on the console... that's been fixed, sorry about the mess. -- David A. Holland dholl...@netbsd.org
Re: LFS: unused codes
On Thu, Jul 18, 2013 at 09:54:51PM +0900, NAKAJIMA Yoshihiro wrote: The following codes seem to be unused. sys/ufs/lfs/ulfs_rename.c: ulfs_genfs_rename_ops ulfs_sane_rename() ulfs_rename() sys/ufs/lfs/ulfs_vnops.c: ulfs_mknod() ulfs_close() ulfs_getattr() ulfs_strategy() Part of the the idea of the lfs split was to clean these up, yes. Thanks for finding them and I'll prune them as soon as I can find a bit of time, hopefully this weekend. -- David A. Holland dholl...@netbsd.org
Re: lfs heads up
On Sun, Jun 30, 2013 at 01:47:28AM +0900, NAKAJIMA Yoshihiro wrote:
After LFS split, ufs_readwrite.c is no longer shared by FFS and LFS.
So I think:
(1) Simplify them (see attached file)
And (2a) merge into {ffs,lfs}_vnops.c
or (2b) make them standalone like ext2fs_readwrite.c (and rename
ufs_readwrite.c to ffs_readwrite.c).
Please commit the ufs one; I have been meaning to do that but I
haven't had time in the past week. (And yes, it should be moved into
ffs/ and named ffs_readwrite.c, but please do that as a separate
commit.)
Don't throw away the lfs part of the patch, but give me a few days to
think about it. I think we may want to hang onto some bits (like the
places the snapshot hooks go) and I'd also like to do a general pass
through lfs looking for unreachable code while it's still very clear
what came from ufs and what didn't.
I think we want to keep at least some of the ufs code for 64-bit
(LFS2) filesystems even though it's never been runnable with LFS; I
also want to hang onto all the quota code until we can reach a
decision about the on-disk quota format, even though AFAIK quotas have
never worked on LFS either.
There's a lot of other ufs-derived cruft though.
--
David A. Holland
dholl...@netbsd.org
