Mike Long wrote:
 > One helpful thing people can do is to search the database for their
 > own PRs, and (nicely) notify core if a bug has been fixed but the PR
 > has not been closed.

This is a good idea and I'll do it right away; but where should I send
it?  This one goes to current-users;  I don't really feel that
core@netbsd.org is right either.  I would appreciate a hint.

I currently have these outstanding PRs:


misc/705 [non-critical/low]: Several Makefiles use -o bin and -g bin
	This one seems to be fixed in the Makefiles I reported, but
several makefiles in sys/arch/*/stand now have similar code.  These
don't matter so much though.  Should be closed.


kern/1145 [serious/low]: umount & df may panic NetBSD
	This one is left open/analyzed with this comment:
 > proposed fix insufficieint and erroneous.  thinking about correct
 > locking solution.
 >                        -- cgd
        After looking a bit harder I agree my proposed fix was wrong.
        How should I follow-up with a new fix proposal?


kern/1659 [non-critical/low]:
	TCP connections may be left hanging in FIN_WAIT_2
This one should be a straight apply.  No feedback yet.


lib/1695 [serious/high]: varargs.h needs ... for gcc 2.7.x
	This one is now fixed (by mycroft; differently but probably
	better) and should be closed.


pending/1808 [serious/medium]: lseek errors get bogus return value
	This one is fixed;  I don't know what "pending" means.
	(A vax-specific libc fix really).


misc/1814 [non-critical/low]: /etc/security has various bugs and misfeatures
	Fixed in OpenBSD by Theo more thoroughly than in my PR;  I would
suggest just dropping in the OpenBSD version.



I hope this helps clear out some clutter;  I would also like to say that
the PR database is very useful.

   -  Arne H. J.