Re: Help wanted: 4.0 release notes

>I could only think of very few (and not very user
visible) changes. There
>have been a few nasty kernel bugs fixed, and some libc
improvements (like
>__clone() now working for real). What else?

This ties in with a question I have about BIND.  In revision
1.5 of
src/usr.sbin/bind/include/config.h, a change was made to
correct
functionality on sparc and sparc64.  Revision 1.6 seems to
have done
away with that change.  If that change is no longer needed
in 4.0 and
above, it might be relevant to mention.  (Or it might be too
minor, I
don't know.)  Alternately, perhaps the change was clobbered
unintentionally?

Dave

   >I could only think of very few (and not very user
visible) changes. There
   >have been a few nasty kernel bugs fixed, and some
libc improvements (like
   >__clone() now working for real). What else?
   
   This ties in with a question I have about BIND.  In
revision 1.5 of
   src/usr.sbin/bind/include/config.h, a change was made to
correct
   functionality on sparc and sparc64.  Revision 1.6 seems
to have done
   away with that change.  If that change is no longer
needed in 4.0 and
   above, it might be relevant to mention.  (Or it might be
too minor, I
   don't know.)  Alternately, perhaps the change was
clobbered
   unintentionally?


if this is for pthreads then the problem no longer exists
in
-current.  but 4.0 should have them enabled -- that is
before
the problem was fixed.


.mrg.

On Tue, May 08, 2007 at 02:51:37PM +1000, matthew green
wrote:
> if this is for pthreads then the problem no longer
exists in
> -current.  but 4.0 should have them enabled -- that is
before
> the problem was fixed.

Right, and the problematic version is not on the netbsd-4
branch - but:
we did not re-enable threads in -current :-(

Martin

David H. Gutteridge wrote:
>> I could only think of very few (and not very user
visible) changes. 
>> There
>> have been a few nasty kernel bugs fixed, and some
libc improvements 
>> (like
>> __clone() now working for real). What else?
>
> This ties in with a question I have about BIND.  In
revision 1.5 of
> src/usr.sbin/bind/include/config.h, a change was made
to correct
> functionality on sparc and sparc64.  Revision 1.6 seems
to have done
> away with that change.  If that change is no longer
needed in 4.0 and
> above, it might be relevant to mention.  (Or it might
be too minor, I
> don't know.)  Alternately, perhaps the change was
clobbered
> unintentionally?
>
> Dave
>
>

I'd like to drift further from the topic 
On my NetBSD-current system, there seems to be some a
problem with bind 
and the userland apps
that I've seen for months. Userland apps apparently send
themselves a 
sigterm.

$ host localhost
localhost has address 127.0.0.1
localhost has IPv6 address ::1
Terminated

-
Program received signal SIGTERM, Terminated.
0x00000000001e9b04 in isc_app_shutdown ()
(gdb) bt
#0  0x00000000001e9b04 in isc_app_shutdown ()
#1  0x0000000000109a50 in recv_done ()
#2  0x00000000001ecdd8 in isc__taskmgr_dispatch ()
#3  0x00000000001e9c40 in isc_app_shutdown ()
#4  0x00000000001e9ee0 in isc_app_run ()
#5  0x0000000000103a60 in main ()

This is only a minor nuisance, the bigger problem is that
# /etc/rc.d/named reload
causes named to exit, rather than reloading it's
configuration.
Other than that it works fine. Anyone else see this?

Regards,
-Tobias

On Tue, May 08, 2007 at 10:27:40AM +0200, Tobias Nygren
wrote:
> I'd like to drift further from the topic 

Not at all.

> On my NetBSD-current system, there seems to be some a
problem with bind 
> and the userland apps
> that I've seen for months. Userland apps apparently
send themselves a 
> sigterm.

That is just what the "lost change" causes. I have
re-enabled threading,
so if you rebuild bind, it should work again now.

Martin