Re: UPDATING

[Bruce A. Mah]

If memory serves me right, Ruslan Ermilov wrote:
> On Wed, Feb 02, 2000 at 10:53:49AM -0500, Jim Bloom wrote:
> > Ruslan Ermilov wrote:
> > > 
> > > On Tue, Feb 01, 2000 at 02:51:11PM -0500, Jim Bloom wrote:
> > > > I did the following and it worked for me:
> > > >
> > > >   cd /usr/src
> > > >   make buildworld
> > > >   make installworld
> > > >   cd /usr/src/usr.bin/xinstall
> > > >   make install
> > > >   cd /usr/src
> > > >   make installworld
> > > >
> > > > The first make installworld terminates with an errors, but the second o
> n
> > > > goes through.
> > > >
> > > It can't be true!
> > 
> > Nope, I'm pretty sure that is exactly what I did.
> > 
> > > 
> > > After the first `make installworld' fails, we will have:
> > > 1) a new `libutil' without string_to_flags()
> > > 2) an old `libc' without setflags()
> > > 3) an old /usr/bin/install with string_to_flags() linked against libutil.
> > 
> > I believe the new libc has been installed as well.  My first
> > installworld got an error while trying to install rcp.  I believe this
> > is the first program that uses any flags to install.  Once you get to
> > this point, all of the libraries have been installed.
> > 
> Yeah, just figured this myself, but one thing I still don't understand
> is how the new libc.so.4 gets installed on the first pass?  The problem
> is that it is declared as PRECIOUSLIB in libc/Makefile, this will result
> in -fschg passed to install.  Do you have a log from the first failed
> installworld?

This is my first attempt at building world (starting from the 2127
snapshot, then cvsup-ing src-all and cvs-crypto this morning, California
time), but I had a slightly different experience.

make buildworld completed without errors, then I did a make 
installworld which failed (no setflags) when trying to install 
libcrypto.  I did a make -k installworld, which of course finished, but 
the make installworld I did afterwards (no -k) failed in the same place.

After having read through the last few messages on -current, I went to 
the source directory for libc and tried doing a make install there.  It 
failed (also because of a lack of setflags).  Then I went to the obj 
directory for libc and executed the install command for libc manually 
(but without the -fschg argument):

install -c -o root -g wheel -m 444 libc.so.4 /usr/lib

A make installworld just finished without errors.

Hopefully this is useful information, and won't add to any of the 
confusion.

Bruce.

(who's now wishing he kept slightly better written records of 
what he's doing)




 PGP signature

Re: IPv6

[Bruce A. Mah]

If memory serves me right, Kurt Bauer wrote:

> could you please tell me how to configure a IPv6 only Interface. I want
> the Interface to fetch its prefix from a Router. But the Interface only
> gets a Link-Local address when I make a 'ifconfig vx0 up'.
> I worked fine with 3.3 and KAME, but as is seems, there is no more
> /usr/local/v6. So where are all the configuration files for IPv6 ???

I ran into this "problem" last week when I first brought up a -CURRENT 
machine and wanted to play with IPv6.  My workaround was to grab the 
script /usr/local/v6/etc/rc.net6 from my 3.4-RELEASE+KAME box, tweak it 
suitably, and then make sure that it got called from /etc/rc.local.

The two tweaks I remember off-hand was that the paths to commands are 
(of course) different under a 4.0-CURRENT environment and that ndp in 
-CURRENT works a little different than in the KAME snapshots I was 
using earlier.

It seems to me that most of the functionality of rc.net6 could be folded
into /etc/network.  I've thought of writing up patches for this, but I'm
not sure when the IPv6 initialization should take place with respect to
the IPv4 interface configuration, starting up of daemons, setting of
various syctls, etc.  (Also, there's some new variables that should be 
defined in /etc/defaults/rc.conf.)

Bruce.




 PGP signature

Re: IPv6

[Bruce A. Mah]

If memory serves me right, Yoshinobu Inoue wrote:

> > The two tweaks I remember off-hand was that the paths to commands are 
> > (of course) different under a 4.0-CURRENT environment and that ndp in 
> > -CURRENT works a little different than in the KAME snapshots I was 
> > using earlier.
> 
> What point is different for ndp?

At least in the snapshot I have, ndp in KAME takes -I to show/specify an
interface for the default route.  ndp in 4.0-CURRENT doesn't have
this option.  I don't know how crucial this is.

> > It seems to me that most of the functionality of rc.net6 could be folded
> > into /etc/network.  I've thought of writing up patches for this, but I'm
> > not sure when the IPv6 initialization should take place with respect to
> > the IPv4 interface configuration, starting up of daemons, setting of
> > various syctls, etc.  (Also, there's some new variables that should be 
> > defined in /etc/defaults/rc.conf.)
> 
> In KAME environment, IPv6 related configurations are done at
> last of rc.conf. So it is at almost end of configuration.
> 
> I don't know if still such kind of change is permitted to
> commit or not, but if you try to make some initial patch for
> it, I think that is anyway good start and very helpful.

OK, I'll see what I can do.  This will be a good way to force me to 
learn how rc.net6 works...

Even if this doesn't make it past the code freeze, we'll have it for 
later.  (I think a good case could be made for this, considering that 
right now starting up IPv6 isn't exactly intuitive.)

Bruce.




 PGP signature

Re: IPv6

[Bruce A. Mah]

If memory serves me right, Yoshinobu Inoue wrote:

> In KAME environment, IPv6 related configurations are done at
> last of rc.conf. So it is at almost end of configuration.

It turns out this won't work real well, because if I do this, then 
inetd gets started before we start up the IPv6 interfaces, which is 
bad for any IPv6 services to get started from inetd.

> I don't know if still such kind of change is permitted to
> commit or not, but if you try to make some initial patch for
> it, I think that is anyway good start and very helpful.

OK, I've attached the results of a few hours of hacking.  There's a 
diff for /etc/defaults/rc.conf, a diff for /etc/rc, and a new 
/etc/rc.net6 file all attached here.  The /etc/rc.net6 file is a 
modified version of /usr/local/v6/etc/rc.net6 from the KAME 
distribution.  Patches are all against 4.0-CURRENT, as of the middle of 
last week.

I haven't really tested it very well (in particular, the router-specific
code is completely untested, because, well I don't really have the 
ability at the moment).  Comments welcome, or if one of the KAME team 
members with commit privileges wants to fix it up and/or try to get 
this code commited, that's fine too.

Cheers,

Bruce.




*** /etc/rc Mon Feb  7 14:53:30 2000
--- /etc/rc.distMon Feb  7 14:47:44 2000
***
*** 191,205 
network_pass1
  fi
  
- case ${ipv6_enable} in
- [Yy][Ee][Ss])
-   if [ -r /etc/rc.net6 ]; then
-   . /etc/rc.net6  # We only need to do this once also.
-   net6_pass1
-   fi
-   ;;
- esac
- 
  # Mount NFS filesystems.
  echo -n "Mounting NFS file systems"
  mount -a -t nfs
--- 191,196 


*** /etc/defaults/rc.conf.dist  Mon Feb  7 13:42:45 2000
--- /etc/defaults/rc.conf   Mon Feb  7 14:55:23 2000
***
*** 183,188 
--- 183,199 
  ### Miscellaneous network options: ###
  icmp_bmcastecho="NO"  # respond to broadcast ping packets
  
+ ### IPv6 options: ###
+ ipv6_enable="NO"  # Set to YES to set up for IPv6.
+ ipv6_network_interfaces="auto"# List of network interfaces (or "auto").
+ ipv6_gateway="NO" # Set to YES if this host will be a gateway.
+ route6d_enable="NO"   # Set to YES to enable an IPv6 routing daemon.
+ route6d="/usr/sbin/route6d"   # Name of IPv6 routing daemon.
+ route6dflags=""   # Flags to IPv6 routing daemon.
+ mroute6d_enable="NO"  # Do IPv6 multicast routing.
+ mroute6d="/usr/sbin/pim6dd"   # Name of IPv6 multicast routing daemon.
+ mroute6dflags=""  # Flags to IPv6 multicast routing daemon.
+ gifs="NO" # List of GIF tunnels (or "NO").
  
  ##
  ###  System console options  #



#! /bin/sh
# $FreeBSD$

# Note that almost all of the user-configurable behavior is no longer in
# this file, but rather in /etc/defaults/rc.conf.  Please check that file
# first before contemplating any changes here.  If you do need to change
# this file for some reason, we would like to know about it.

# IPv6 startup

net6_pass1() {

echo -n 'Doing IPv6 network setup:'

if [ X"${ipv6_gateway}" = X"YES" ]; then

#
# list of interfaces, and prefix for interfaces
# NOTE: no trailing double colon necessary here!
#
case ${ipv6_network_interfaces} in
[Aa][Uu][Tt][Oo])
ipv6_network_interfaces="`ifconfig -l`"
;;
esac
#   ipv6_network_interfaces="ed0 ep0"
#   prefix_ed0="fec0:::0001"
#   prefix_ep0="fec0:::0002"

#
# list of outer ip addresses for gif.
#
#   gifs="gif0 gif1"
#   gifconfig_gif0="10.1.1.1 10.1.2.1"
#   gifconfig_gif1="10.1.1.2 10.1.2.2"
else
#
# manual configurations - in case ip6router=NO
# you can configure only single interface, as specification assumes 
that
# autoconfigured host has single interface only.
#
case ${ipv6_network_interfaces} in
[Aa][Uu][Tt][Oo])
ipv6_network_interfaces="`ifconfig -l | sed -e 's/ .*//'`"
;;
esac
fi

# tool locations
prefixconfig=/usr/sbin/prefix
rtsol=/sbin/rtsol
gifconfig=/usr/sbin/gifconfig
route=/sbin/route
ndp=/usr/sbin/ndp

# just to make sure
ifconfig lo0 up

#determine the "default interface" used below
if [ X"$defaultiface" = X"" ]; then
for i in $ipv6_network_interfaces; do # use 1st interface in the list
defaul

Re: IPv6

[Bruce A. Mah]

If memory serves me right, Ollivier Robert wrote:

> Please use consistent names like "mroute6d_flags" and "mroute6d_program".

Thanks...these changes will be reflected in the next version I post.

For your information, I didn't use different naming conventions just for
the hell of it...I just neglected to convert all of the names from the
KAME version of the script to use the rc.conf conventions.

Bruce.





 PGP signature

Re: IPv6

[Bruce A. Mah]

If memory serves me right, Yoshinobu Inoue wrote:

> Hi, sorry for delay but I tried it and added some fixes
> including change of some variable names to look like somewhat
> consistent with IPv4 variables.
> 
> Please try if this works in your environment.
> Other people's trials are also welcome.

It seems to Do The Right Thing for my single-homed endhost case
(unfortunately I still do not have a router I can test).  There is one
change I would make, as a result of some feedback from Ollivier Robert
<[EMAIL PROTECTED]>:  All instances of the variable $mroute6d
should probably be replaced by $mroute6d_program.  (Most of the
variables defining programs in /etc/defaults/rc.conf are of the form
*_program.)

> And again, thanks for creating the template. :-)
> That was very helpful and I might not have tried to make this
> because I am lazy.

Ah...I didn't very much.  Someone in your KAME project did all the
original work.

I think it's important that we get something like this commited before
the release, if we want to say we're serious about supporting IPv6 in
FreeBSD 4.0-RELEASE.  It's asking a little too much of users to figure
out the right sequence of commands to bring up an IPv6 node, so that
they can stick it into /etc/rc.local or something like that.

Thanks,

Bruce.




 PGP signature

Re: IPv6

[Bruce A. Mah]

The only changes I have for you are small typos...

/etc/rc.conf:
"assigne router prefix" should be:
"assign router prefix"

/etc/rc.network6:
"if you instead want to route such packets to a "default" 
interface":  Looks to me like this comment is not applicable 
anymore.

"Enable Router Renumbering, unicaset case" should be:
"Enable Router Renumbering, unicast case"

Unfortunately I can't give you any good comments about functionality...I
want to do a buildworld/installworld on my test box to pick up all of
the changes regarding scoped addresses...I'm doing a cvs update now to
bring the sources over.

Once I'm back up and running, I'll let you know how it works for me.

Thanks!

Bruce.




 PGP signature

Re: IPv6

[Bruce A. Mah]

If memory serves me right, Yoshinobu Inoue wrote:

> I still made more several fixes to IPv6 configuration scripts.
> 
>   -changed the file rc.net6 to rc.network6
>   -changed the func net6_pass1 to network6_pass1
>   -changed several var name more unlikely to confilict
>   -changed if several sentenses in rc.network6 to case sentence
>like in rc.network
>   -wrapped many var names by {}
>   -and other fixes

I ran across a few problems after I remade world.  The new scoped 
address syntax breaks /etc/rc.network6.  In particular, some lines that 
look like:

> + # disallow unicast packets without outgoing scope identifiers.
> + # if you instead want to route such packets to a "default" interface,
> + # comment out the 1st two lines, and enable the lines after them.
> + case ${ipv6_default_interface} in
> + '')
> + route add -inet6 fe80:: -prefixlen 10 ::1 -reject
> + ;;
> + *)
> + laddr=`ifconfig ${ipv6_default_interface} inet6 \
> + | grep 'inet6 fe80:' | head -1 | awk '{print $2}'`
> + route add -inet6 fe80:: ${laddr} -prefixlen 10 -interface \
> + -cloning
> + route add -inet6 ff02:: ${laddr} -prefixlen 16 -interface \
> + -cloning
> + ;;
> + esac

The definition of $laddr is not compatible with the scoped addressing 
syntax.  Instead, it needs something like:

laddr=`ifconfig ${ipv6_default_interface} inet6 \
| grep "inet6 ${ipv6_default_interface}%fe80:" \
| head -1 | awk '{print $2}' | sed -e 's/.*%//'`

There's another, similar snippit of code in the router-specific part of 
the script.

Another problem occurred when I modified /etc/rc.network6 as above:

route: writing to routing socket: Network is unreachable
add net fe80::: gateway fe80::1: Network is unreachable
route: writing to routing socket: Network is unreachable
add net ff02::: gateway fe80::1: Network is unreachable
add net :::0.0.0.0 gateway ::1
add net ::0.0.0.0 gateway ::1
net.inet.ip6.forwarding: 0 -> 0
net.inet.ip6.accept_rtadv: 0 -> 1

These actions all happened between the start and the end of DAD for my 
(one) Ethernet interface (I have a single-homed host).

Finally, could you say whether or not lo0 should really be the default
value for ipv6_default_interface in /etc/defaults/rc.conf?  I have this 
vague feeling it's wrong but I don't know enough to say why:

> +ipv6_default_interface="lo0" # Default output interface for scoped addrs.

Thanks!

Bruce.





 PGP signature

Re: IPv6

[Bruce A. Mah]

If memory serves me right, Yoshinobu Inoue wrote:
> > I ran across a few problems after I remade world.  The new scoped 
> > address syntax breaks /etc/rc.network6.  In particular, some lines that 
> > look like:
> 
> Sorry not to announce it yet, but scoped addr format will
> still change, like below.
> 
>addr%scope
> 
> I'll send another mail to describe it in next to this mail.

OK, got it.  Some of the breakage went away, in that it looks like all 
of the invocations to route(8) are now well-formed.  This is a Good 
Thing (TM).

> When this change happens, those problems will be resolved.

Well...not quite, and I am not sure why.  Following is a snippit of the 
bootup messages from a CURRENT machine (approximately -2220):

dc0: starting DAD for fe80:0001::0200:f8ff:fe10:6ef3
dc0: flags=8843 mtu 1500
inet 146.246.243.57 netmask 0xff00 broadcast 146.246.243.255
inet6 fe80::200:f8ff:fe10:6ef3%dc0 prefixlen 64 tentative
ether 00:00:f8:10:6e:f3
media: 100baseTX status: active
supported media: autoselect 100baseTX  100baseTX 10baseT/UT
P  10baseT/UTP 100baseTX  none
lo0: flags=8049 mtu 16384
inet6 fe80::1%lo0 prefixlen 64
inet6 ::1 prefixlen 128
inet 127.0.0.1 netmask 0xff00
add net default: gateway 146.246.243.254
Additional routing options: TCP keepalive=YES.
routing daemons:.
Doing IPv6 network setup:route: writing to routing socket: Network is unreachable
add net fe80::: gateway fe80::1%lo0: Network is unreachable
route: writing to routing socket: Network is unreachable
add net ff02::: gateway fe80::1%lo0: Network is unreachable
add net :::0.0.0.0: gateway ::1
add net ::0.0.0.0: gateway ::1
net.inet6.ip6.forwarding: 0 -> 0
net.inet6.ip6.accept_rtadv: 0 -> 1
dc0: DAD complete for fe80:0001::0200:f8ff:fe10:6ef3 - no duplicates found
dc0: starting DAD for 3ffe:0780:0060:0001:0200:f8ff:fe10:6ef3
dc0: DAD complete for 3ffe:0780:0060:0001:0200:f8ff:fe10:6ef3 - no duplicates found
.

(Note the error messages from route(8) about mid-way through.) This
output was produced from the last version of scripts you posted to
-current, and with the only relevent change I made to /etc/rc.conf was
to set ipv6_enable="YES".

After *completing* a multiuser boot, attempting to set the default
scoped route correctly installed an entry in the routing table, using
exactly the same command that /etc/rc.network6 would have generated:

/sbin/route add -inet6 fe80:: fe80::1%lo0 -prefixlen 10 -interface \
-cloning

I was wondering if there was somehow a race condition with the first 
DAD for dc0 not completing, but I put a long sleep at the start of 
network6_pass1() and it didn't seem to help.

> > Finally, could you say whether or not lo0 should really be the default
> > value for ipv6_default_interface in /etc/defaults/rc.conf?  I have this 
> > vague feeling it's wrong but I don't know enough to say why:
> > 
> > > +ipv6_default_interface="lo0" # Default output interface for scoped a
> ddrs.
> 
> Maybe your concern is that packets to the default interface
> should be sent out to outside of host, at least?

I think that's it, yes.

> On the other hand, I thought there should be some default
> interface by default, but I afraid that an approach of just
> choosing some interface as default interface might be end up
> to choose non working interface.
> But now I feel choosing lo0 approach is also somewhat strange.
> 
> So I'll try following approach.
> 
>   -"ipv6_default_interface" is empty by default
>   -When all of "ipv6_network_interfaces", "gif_interfaces",
>and "ipv6_default_interface" are empty, then there will be
>no default interface
>   -When "ipv6_default_interface" are empty but
>"ipv6_network_interfaces" and/or "gif_interfaces" is not empty,
>then choose one default interface from there.

I like your approach, although I admit that I'm learning much of this as
we go along.

Small nitpick:  You might want to move the line for
ipv6_default_interface higher in /etc/defaults/rc.conf so that it is
just below the rest of the definitions that begin with ipv6_*.

Thanks!

Bruce.





 PGP signature

Re: IPv6

[Bruce A. Mah]

I was babbling on about some problems and somehow got cut off by my 
mailer:

> Well...not quite, and I am not sure why.  Following is a snippit of the 
> bootup messages from a CURRENT machine (approximately -2220):
> 
> dc0: starting DAD for fe80:0001::0200:f8ff:fe10:6ef3
> dc0: flags=8843 mtu 1500
> inet 146.246.243.57 netmask 0xff00 broadcast 146.246.243.255
> inet6 fe80::200:f8ff:fe10:6ef3%dc0 prefixlen 64 tentative
> ether 00:00:f8:10:6e:f3
> media: 100baseTX status: active
> supported media: autoselect 100baseTX  100baseTX 10baseT
> /UT
> P  10baseT/UTP 100baseTX  none
> lo0: flags=8049 mtu 16384
> inet6 fe80::1%lo0 prefixlen 64
> inet6 ::1 prefixlen 128
> inet 127.0.0.1 netmask 0xff00
> add net default: gateway 146.246.243.254
> Additional routing options: TCP keepalive=YES.
> routing daemons:.
> Doing IPv6 network setup:route: writing to routing socket: Network is unreach
> able
> add net fe80::: gateway fe80::1%lo0: Network is unreachable
> route: writing to routing socket: Network is unreachable
> add net ff02::: gateway fe80::1%lo0: Network is unreachable
> add net :::0.0.0.0: gateway ::1
> add net ::0.0.0.0: gateway ::1
> net.inet6.ip6.forwarding: 0 -> 0
> net.inet6.ip6.accept_rtadv: 0 -> 1
> dc0: DAD complete for fe80:0001::0200:f8ff:fe10:6ef3 - no duplicates found
> dc0: starting DAD for 3ffe:0780:0060:0001:0200:f8ff:fe10:6ef3
> dc0: DAD complete for 3ffe:0780:0060:0001:0200:f8ff:fe10:6ef3 - no duplicates
>  found

Note that two invocations of route(8) failed about mid-way through.  I 
can't figure out why, but manually typing the route commands after 
boot-up seemed to go just fine (no error messages, and routes installed 
correctly):

route add -inet6 fe80:: fe80:;1%lo0 -prefixlen 10 -interface -cloning
route add -inet6 ff02:: fe80::1%lo0 -prefixlen 16 -interface -cloning

As far as your plan for determining the default scoped interface route, 
it sounds good to this newbie.  One nitpick might be to move the 
ipv6_default_interface line in /etc/defaults/rc.conf so that it is next 
to the other definitions that begin with ipv6_*.

Thanks!

Bruce.




 PGP signature

Re: ipv6 and rc.conf questions

[Bruce A. Mah]

If memory serves me right, Yoshinobu Inoue wrote:

> And now I think the problem is that entry name,
>   rtadvd_enable="NO"
> is not intuitive for users.
> 
> So how about changing the name to something like,
> 
>  ipv6_to_be_defaultrouter="NO"
> 
> and if it is set to YES, then rc.network6 invoke rtadvd (and
> possibly do other works)?
> 
> Please give me comments if it seems reasonable or not, and
> also if the name is good or bad.

I think that I know just enough about IPv6 to be dangerous, at this
point.  With that in mind, I think we should keep the name (because that
describes exactly what it does), and just change the default to "YES".

Cheers,

Bruce.




 PGP signature

Re: IPv6: can a link-site (or global) address be configured in rc.conf?

[Bruce A. Mah]

If memory serves me right, "Jose M. Alcaide" wrote:

> Now that I have several machines running FreeBSD 4.0, I started to
> play with IPv6. It's fun! I have plans to set up a v6-over-v4 tunnel
> and connect to the 6Bone.
> 
> I read /usr/share/examples/IPv6/USAGE, /usr/share/doc/IPv6/IMPLEMENTATION
> and some documents at the KAME web site.  However, I still have to figure out
> how to assign a not-link-local address (i.e., a site or global address) to
> the [unique] Ethernet interface of each host in an automatic manner (from
> /etc/rc.conf).  After reading /etc/rc.network6 I concluded that no addresses
> apart from the link-local ones are assigned to the interfaces.  I am using
> ifconfig manually to do this (BTW, I found that there is no need to specify
> "alias").

/etc/rc.network6 assumes that you'll get your non-link-local address(es)
from your router(s) using rtsol(8).  The router, in turn, needs to be
running something like rtadvd(8).

> I am new to IPv6, so maybe I am asking for something with no
> sense...

IPv6 autoconfiguration is very roughly analogous to using DHCP in the
IPv4 world.  (It's not exactly the same though.  In fact, there exists 
a DHCP for IPv6.)

Hope this helps,

Bruce.




 PGP signature

Re: ipv6 and rc.conf questions

[Bruce A. Mah]

If memory serves me right, Yoshinobu Inoue wrote:

> If you did update and make world recently, please check
> /usr/share/examples/IPv6/USAGE. There will be more detailed info.
> A handbook chapter version is now under preparation.

That's good to hear.  I was thinking about this a little bit, but I'm 
glad someone (presumably more qualified than me) is doing this.

> Wmmm, should rtadvd always be invoked when 'ipv6_gateway_enable="YES" ?

Hmmm...two things come to mind.  1) What happens if there are two
routers running rtadvd on a single subnet?  2) Are there environments in
which a netadmin might not want to use router advertisements?

I have this fuzzy feeling that always invoking rtadvd on routers might
not be a good idea, but that perhaps making it the default might be good
(right now, rtadvd is turned off by default).

Bruce.





 PGP signature

Re: ssh strangeness in -current...

[Bruce A. Mah]

If memory serves me right, David Malone wrote:
> On Mon, Mar 06, 2000 at 01:32:00PM -0700, Warner Losh wrote:
> 
> > : > +   Openssh isn't 100% compatible with ssh, so some care needs to
> > : > +   be taken in its operation.
> > : 
> > : This sounds bad. Are you referring to the -o syntax differences, or actua
> l
> > : incompatabilities? There have been unsubstantiated reports of
> > : interoperability problems, but nothing well documented here.
> > 
> > I'm talking about the -o syntax difference specifically.  How does the
> > following sound?
> 
> [SNIP]
> 
> > +   Openssh's command line parsing isn't 100% compatible with ssh,
> > +   so some care needs to be taken in its operation.
> 
> I'd leave it saying that it isn't 100% compatible - it may sound
> bad but it's true. There are several other things that aren't the
> same: default options are different, some options have been removed
> (AllowHosts is one that I know of), it produces warning messages
> where the old ssh wouldn't have. I'm sure there are other differences
> too.

Rather than let the users guess at various incompatabilities (imagined 
and real), why not give them a few examples, as in your (David's) last 
message?

"Care needs to be taken when converting from ssh to OpenSSH.  OpenSSH's
command-line parsing isn't 100% compatible with ssh, some of the default
options have been changed, some options (such as AllowHosts) have been
removed, and it produces a few more warning messages than ssh."

Bruce.




 PGP signature

Re: FDDI cards in -current

[Bruce A. Mah]

If memory serves me right, Christoph Kukulies wrote:

> Planning a router between FDDI and Fast Ethernet I'm wondering
> if I'm on the safe side when using FreeBSD 4.0-current for this project
> rather than being more conservative and use an older version of the OS.

You mean 4.0-stable, right?  :-)

My really touchy-feely opinion is that either way is probably going to 
be fine, but my machines are research platforms, not production routers.

> What FDDI cards could be recommended? (There aren't many, though, I believe).

Here's what's supported:

fpa(4), fea(4) - Device Drivers for DEC FDDI Controllers

fpa is a PCI card, fea is EISA.

Bruce.



 PGP signature

Re: 'machine/param.h' required for 'sys/socket.h'

[Bruce A. Mah]

If memory serves me right, Yoshinobu Inoue wrote:

> 
> > 'sys/scocket.h' header file start using ALIGN macro 
> > defined in 'machine/param.h' header file while the man page
> > for "socket" only mentioned 'sys/types.h' as the prerequisite
> > for 'sys/socket.h'.
> > 
> > As a result the 'net/pchar' port is now broken.
> 
> Yes, this problem is already found by Bruce A. Mah and some
> mail is exchanged between related people.

I'm doing a pointrev to pchar to "fix" this problem...see below.

> > What must be done to solve this ? 
> > Is it possible to '#include ' in 'sys/socket.h' OR
> > the man page must be corrected to explicitly state 'param.h'
> > (sys/ or machine/ ?) as the prerequisite to 'sys/socket.h' and
> > all the programms using it patched accordingly ?
> 
> As itojun's experience, including machine/param.h in socket.h
> also cause problems in some other apps.
> 
> I feel requesting inclusion of machine/param.h for any apps
> which use socket is better. But if there are any other smarter
> solution, please let me know and I'll appreciate it much.

Just speaking as the slightly whiny developer of pchar:  What bothers me
is that out of all the platforms where pchar can do IPv6 support, recent
FreeBSD versions seem the *only* case where I need to include machine/
param.h in order to use the CMSG* macros.  This means that FreeBSD is
forcing me to make some code changes that aren't required for *any*
other platform.  According to itojun's earlier mail, I can't just
blindly include machine/param.h either.  So I need to figure out at
compile-time or configure-time whether or not I need machine/param.h.

Personally, I think this is a lose.  Unfortunately I don't have any
better suggestion than "back out your last commit".

In the specific case of pchar, I need to make code changes in order to
work with 4.0-RELEASE, now that it's been shipped with the header files
as we've discussed.  So I wrote a bunch of autoconf code to detect this
breakage and fix it.  I'll probably roll in some Solaris fixes also and
call this pchar-1.1.2 or something like that.

Bruce.




 PGP signature

Re: 'machine/param.h' required for 'sys/socket.h'

[Bruce A. Mah]

If memory serves me right, Yoshinobu Inoue wrote:
> > > I feel requesting inclusion of machine/param.h for any apps
> > > which use socket is better. But if there are any other smarter
> > > solution, please let me know and I'll appreciate it much.
> > 
> >  should never be included by applications since
> > it is an implementation detail.
> > 
> > Specify including  in apps which use the CMSG*() macros.
> >  doesn't depend on <*/param.h> unless these macros are used.
> > Since these macros are undocumented, applications that use them should
> > expect problems :-).
> > 
> > Bruce
> 
> After reading bmah's message, now I am inclined to including
> machine/param.h from sys/socket.h for maximum portability, if
> there is no spec for it, and if all other platforms doing it.

Arrgh.  Now it seems I might need to reverse my position.  I looked
through some code fragments in UNIX Network Programming (Volume 1,
Second Edition, pp. 362-365), and there's some precedent for needing
 with the CMSG*() macros.

On the other hand, RFC 2292 and draft-ietf-ipngwg-rfc2292bis (the
references I was originally working from) don't mention this requirement
at all; they just say that CMSG*() are defined with .  I'm
slightly confused by now.

I'm going to send off a note to the authors of 
draft-ietf-ipngwg-rfc229bis asking for some clarification.  In the 
meantime, maybe we should hold off on doing any changes.

Bruce.



 PGP signature

Re: Header includes and defines in freebsd 4-Stable [ISC-Bugs#102] (bind9)

[Bruce A. Mah]

If memory serves me right, Visigoth wrote:

>   It seems that there may be a small socket implementation issue
> with freebsd 4-Stable.  I have been in disscussion with a few people from
> the isc bind 9 bug tracking department, and it seems that for the macro
> CMSG_NXTHDR to function in freebsd , the macro ALIGN must be 
> defined.

We went through this exact same issue about six weeks ago, the problem 
being that pchar (a network measurement utility I wrote) needed the 
CMSG_* macros and started failing to build under 4.0-CURRENT.  (I 
needed these macros for IPv6.)

I lost track of the discussion for several reasons, but you can check
the -current mailing list archives (look for CMSG_NXTHDR or some such
thing like this).  According to a very quick perusal of the CVS 
repository, it hasn't been solved yet.  (i.e. FreeBSD still requires 
 for CMSG_* to work properly.)

Yoshinobu Inoue <[EMAIL PROTECTED]> is probably the best person 
to ask for more information on this.

Bruce.



 PGP signature

Re: Check for ports updates

[Bruce A. Mah]

If memory serves me right, Thomas Schuerger wrote:
> > > Is there already a tool that checks the installed ports for available
> > > updates in /usr/ports?
> > > 
> > > I've written such a tool, which seems to work fine already. Anyone
> > > interested?
> > 
> > pkg_version(1)
> 
> Ah, haven't seen that before. The output of pkg_version is very
> canonical, but not very readable for humans. And it's slower than my
> version... ;-)

Without having looked at ports_updates yet, let me just mention that:

1.  If you want human-readable output, try "pkg_version -v".  Maybe 
that should have been a default; certainly I always run it that way.  
But in the case that a program was going to postprocess the output, I 
didn't want it to have to wade through a bunch of pretty-printing stuff 
to get the results it needed.

2.  When I was writing pkg_version, speed wasn't exactly a big priority 
to me, since pretty much *anything* was faster than what I was doing.

Bruce.

PS.  I've been really bad about ignoring suggestions for pkg_version, 
mostly because it does everything I need/want it to do right now.





To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: SCSI DAT tape question

[Bruce A. Mah]

If memory serves me right, "Robert Small" wrote:
> I'm running an adaptec controller (1542CF) with a Sony SDT-5000.  I'm
> running:
> 
> reeBSD (5.0-2511-CURRENT FreeBSD 5.0-2511-CURRENT #4: Thu Jul 6
> 20:31:41 CDT 2000)
> 
> When I issue the command "camcontrol eject sa0" I receive:
> 
> Error received from stop unit command
> 
> When I issue the command "camcontrol stop sa0" I receive"
> 
> Error received from stop unit command
> 
> I can boot the system into Windows or System Commander and eject the
> tape using the eject button.
> 
> Any ideas?

Is there some reason why "mt -f /dev/nsa0 offline" won't do what you want?

Bruce.




 PGP signature

Re: For your amusement..

[Bruce A. Mah]

If memory serves me right, Peter Wemm wrote:

> Connected to ia64.wemm.org.
> Escape character is '^]'.
> 
> FreeBSD/ia64 (ia64.wemm.org) (ttyp0)

That's totally awesome.  Congratulations to all involved!

Now, how long before I need to start worrying about release notes for 
the ia64?  :-)

Bruce.






msg32397/pgp0.pgp
Description: PGP signature

Re: kldxref broken, maybe?

[Bruce A. Mah]

If memory serves me right, Ruslan Ermilov wrote:
> On Thu, Sep 20, 2001 at 10:19:22PM -0700, Peter Wemm wrote:
> > Warner Losh wrote:
> > > In message  Mark Peek writes:
> > > : Install a -current kernel on a 4.X or pre-kldxref (before 9/10/01) 
> > > : 5.X system. I sent a note to Warner mentioning he might want to put a 
> > > : comment about this in UPDATING.
> > > 
> > > I'm just unsure how to describe it...
> > 
> > It is actually non-fatal.  It should probably be added to the list
> > of tools to build for making the kernel. 
> > 
> This is not enough -- it should be made a cross-tool, much like
> the gensetdefs in -STABLE is.  The binary format produced is MD.
> If we don't, we should disable it (-DNO_XREF) for cross-builds.

Was there ever any resolution to this issue?  I just tripped over it
trying to update a 4-STABLE box to -CURRENT.  (The solution I used, 
which was to manually install kldxref and the version of libc.so that 
it was linked against, probably isn't general-purpose.)

Thanks,

Bruce.





msg32413/pgp0.pgp
Description: PGP signature

HEADS UP: Release notes reorg

[Bruce A. Mah]

The release notes for -CURRENT are a real mess.  The current ordering
rule is something like "chronological ordering of items within a
section, but keep related items together".  I've just begun converting
the release notes (one section at a time) to an alphabetical sorting (on
manpage references, filenames, or application names, with a few
exceptions).  With this, we'll stand a greater chance of people actually
being able to find all the release notes relating to a particular
command, API, or whatever.  I just committed a change for the "Userland"
section...the rest will follow, one at a time, over the next few weeks.
If you happen to be in the mood for committing release notes to a
section, take a quick look to see what the current state of that section
is.

Note that 4.4-STABLE's release notes already have the alphabetical
ordering, which I imposed after the post-4.4-RELEASE truncation of the
file.

Bruce.





msg32475/pgp0.pgp
Description: PGP signature

Re: kldxref broken, maybe?

[Bruce A. Mah]

If memory serves me right, Ruslan Ermilov wrote:
> On Wed, Oct 10, 2001 at 06:25:48PM +1000, Bruce Evans wrote:
> > On Wed, 10 Oct 2001, Ruslan Ermilov wrote:
> > 
> > > I do make -CURRENT worlds every night on a -STABLE box, and the
> > > kldxref(8) miss is non-fatal:
> > > ...
> > > ===> wi
> > > install -c -o root -g wheel -m 555   if_wi.ko /CURRENT/boot/kernel/
> > > kldxref /CURRENT/boot/kernel
> > > kldxref:No such file or directory
> > > *** Error code 1 (ignored)
> > 
> > This seems to be a bug in kmod.mk :-).  It intentionally ignores errors.
> > 
> This is not a bug, but a work-around for the above bug that klxref(8) is
> not a cross-tool, but should (ideally) be.

OK, sounds good.  Seems to me this is something that might deserve a
mention in UPDATING.  Something like:

During a source upgrade of a 4-STABLE machine to -CURRENT, the
installkernel step will attempt to execute a non-existent kldxref
executable.  (kldxref exists in -CURRENT, but not in 4-STABLE.)
This error is non-fatal and can be ignored.

Cheers,

Bruce.






msg32644/pgp0.pgp
Description: PGP signature

Re: -current vs. -stable network performance

[Bruce A. Mah]

If memory serves me right, Matthew Dillon wrote:
> I've noticed that -current has much lower TCP performance.  I haven't
> had time to investigate it but I presume there is some overhead
> somewhere that is killing it.

Here's a data point but I'm not sure how useful it is.  At the start of
December I was using tcpreplay to spew packets from a stored trace into
a testbed network as fast as the CPU could go, and I saw:

5-CURRENT (11/19):  9244 pps, 35.6 Mbps
4-STABLE (late November):   21827 pps, 84 Mbps

These measurements were on the same machine, which is a 1.7 GHz P4,
512MB RAM, ATA disk.  Network interface was a four-port dc-type card.
GENERIC kernels.  These are "typical" numbers, but fairly repeatable 
over various trace files I was using.

At the time I was more interested in being able to get packets on the
network quickly than in why there was a performance difference, so I
just plopped 4-STABLE on the machine without doing any other
investigation.

Bruce.





msg33018/pgp0.pgp
Description: PGP signature

Re: HEADS UP: DHCP 3.0.1RC6 imported

[Bruce A. Mah]

If memory serves me right, Murray Stokely wrote:
> DHCP 3.0.1 RC6 has been imported into -CURRENT.

Cool.  We're still shipping just the client part, right?

Bruce.



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

CURRENT breakage in usr.sbin/amd/mk-amd-map

[Bruce A. Mah]

This is a first for me, I think...finding a CURRENT buildworld bogon.
Freshly cvsup-ed -CURRENT system, trying to buildworld:

[much output]

===> usr.sbin/amd/mk-amd-map
make: don't know how to make .o. Stop
*** Error code 2

Stop in /usr/src/usr.sbin/amd.
*** Error code 1

Stop in /usr/src/usr.sbin.
*** Error code 1

Stop in /usr/src.
*** Error code 1

Stop in /usr/src.
*** Error code 1

Stop in /usr/src.

Diffs show that someone was perhaps a little overzealous in a
manpage-related cleanup:

bmah-freebsd-1:mk-amd-map% cvs -R diff -r1.10 -r1.11 Makefile
Index: Makefile
===
RCS file: /cvsroot/src/usr.sbin/amd/mk-amd-map/Makefile,v
retrieving revision 1.10
retrieving revision 1.11
diff -r1.10 -r1.11
6c6
< # $FreeBSD: src/usr.sbin/amd/mk-amd-map/Makefile,v 1.10 1999/08/28 01:15:18 peter 
Exp $
---
> # $FreeBSD: src/usr.sbin/amd/mk-amd-map/Makefile,v 1.11 2001/03/20 18:16:16 ru Exp $
12,14d11
< MAN8= mk-amd-map.8
< 
< SRCS= mk-amd-map.c

Fix looks easy to me (put the SRCS= line back) but I'm a little
commit-shy for the src/ tree.  Someone want to do this, or give me a 
go-ahead?  I'm re-doing a buildworld with a patched Makefile now.

Thanks,

Bruce.



 PGP signature

Re: CURRENT breakage in usr.sbin/amd/mk-amd-map

[Bruce A. Mah]

If memory serves me right, "Michael C . Wu" wrote:

> cvs diff: Diffing .
> Index: Makefile
> ===
> RCS file: /home/ncvs/src/usr.sbin/amd/mk-amd-map/Makefile,v
> retrieving revision 1.11
> diff -u -r1.11 Makefile
> --- Makefile2001/03/20 18:16:16 1.11
> +++ Makefile2001/03/20 21:37:46
> @@ -8,6 +8,10 @@
> 
>  .PATH: ${.CURDIR}/../../../contrib/amd/mk-amd-map
> 
> +MAN8=  mk-amd-map.8
> +
> +SRCS=  mk-amd-map.c
> +
>  PROG=  mk-amd-map
> 
>  .include 

That reverts all of Ruslan's change.  You don't want to put the MAN8=
definition back, because that was the point of his commit.  Just the 
SRCS= needs to be reverted.

Now Ruslan (or someone) needs to go and fix all of these files too:

src/usr.sbin/amd/wire-test/Makefile
src/usr.sbin/ancontrol/Makefile
src/usr.sbin/usbdevs/Makefile
src/usr.sbin/wicontrol/Makefile
src/usr.sbin/wlconfig/Makefile

There may be others, these were just selected files that I checked 
(buildworld found the first one for me).

I'm definitely not going to get my -CURRENT machine rebuilt today.  :-p

Bruce.




 PGP signature

Re: CURRENT breakage in usr.sbin/amd/mk-amd-map

[Bruce A. Mah]

If memory serves me right, "Michael C . Wu" wrote:
> On Tue, Mar 20, 2001 at 04:13:17PM -0600, Michael C . Wu scribbled:
> | On Tue, Mar 20, 2001 at 02:03:29PM -0800, Bruce A. Mah scribbled:
> 
> 
> I have just finished making the patch to fix this problem.
> I will start the buildworld now.  In the mean time,
> if someone has a fast box, please test the patch at
> 
> http://people.freebsd.org/~keichii/fix-current-broken-man-build.diff

I just finished a buildworld (but can't do an installworld...I'm 30
miles from the console), all seems well with the diffs.

Thanks much for generating the patch.  I normally don't like leaving 
other people to clean up problems I find, but almost anyone would be 
able to do it faster than me, at the moment.

Cheers,

Bruce.



 PGP signature

Re: CURRENT breakage in usr.sbin/amd/mk-amd-map

[Bruce A. Mah]

If memory serves me right, Peter Wemm wrote:
> "Michael C . Wu" wrote:
> > On Tue, Mar 20, 2001 at 04:13:17PM -0600, Michael C . Wu scribbled:
> > | On Tue, Mar 20, 2001 at 02:03:29PM -0800, Bruce A. Mah scribbled:
> > 
> > 
> > I have just finished making the patch to fix this problem.
> > I will start the buildworld now.  In the mean time,
> > if someone has a fast box, please test the patch at
> > 
> > http://people.freebsd.org/~keichii/fix-current-broken-man-build.diff
> 
> I kinda object to backing this stuff out.  The problem is elsewhere.  This
> stuff builds correctly on its own, it is something wrong with the world
> environment.  eg: do a 'make install' in src/share/mk and the world works
> fine.  Since this seems to be needed, the problem is in 'world', not these
> makefiles.

Huh?!?

Ruslan's commit was intended to remove (most of the) MAN8= definitions
in certain Makefiles.  That's great.

Unfortunately, in some cases, he also removed SRCS= definitions, which is
not so good inasmuch as it breaks buildworld.  Either he deleted too
much out of the Makefiles, or the SRCS= removal was intentional and
should have been documented in the commit message (as far as I can tell 
this has *nothing* to do with manpages).

Michael's patch (which unbreaks buildworld) only backs out the SRCS=
changes.

Feel free to hand me a giant clue if I'm missing something really
obvious.  In other words, is world *supposed* to build in the absence of
SRCS= definitions?

Bruce.



 PGP signature

Re: CURRENT breakage in usr.sbin/amd/mk-amd-map

[Bruce A. Mah]

If memory serves me right, Peter Wemm wrote:

> If SRCS is undefined, then SRCS=${PROG}.c.  ie:
> 
> peter@daintree[7:30pm]~src/usr.sbin/sicontrol-283> grep SRCS Makefile 
> peter@daintree[7:30pm]~src/usr.sbin/sicontrol-284> make -V SRCS
> sicontrol.c
> peter@daintree[7:30pm]~src/usr.sbin/sicontrol-285> make -V PROG
> sicontrol
> 
> Adding back SRCS=prog.c explicitly is not the solution.  It is just hiding
> a problem elsewhere.

[snip]

Thanks for the clue.  I learned something new today.  (Unfortunately, 
not enough to fix the problem, but I bet one of you -CURRENT gods can 
come up with a fix.)

Cheers,

Bruce.




 PGP signature

-CURRENT breakage in usr.sbin/mptable?

[Bruce A. Mah]

Hi Bruce--

A recent commit of yours to src/usr.sbin/mptable/Makefile had the 
commit message:

> Fixed style bugs (use normal formatting for assignment, and don't override
> the correct default for MAN1).

Are you sure this is right?  The default MANSECT for src/usr.sbin is 8,
not 1, but mptable.1, well, lives in section 1.

Most importantly, it appears that this change breaks world.

I think you need to put the MAN1 assignment back, like in the diff below.

(-current folks, I'm not *trying* to do this...all I want is a fairly
recent 5-CURRENT to play with on my scratch box.)

Cheers,

(the other) Bruce.

*** mptable/Makefile2001/03/23 13:47:46 1.4
--- mptable/Makefile2001/03/23 22:11:38
***
*** 1,5 
--- 1,6 
  # $FreeBSD: src/usr.sbin/mptable/Makefile,v 1.4 2001/03/23 13:47:46 bde Exp $
  
  PROG= mptable
+ MAN1= ${PROG}.1
  
  .include 



 PGP signature

Re: Call for review... PR 25577

[Bruce A. Mah]

If memory serves me right, Poul-Henning Kamp wrote:
> In message <[EMAIL PROTECTED]>, Jordan Hubbard writes:
> >Cool.  Does this mean that any of the foocontrol programs can go away?
> 
> As far as I can see, anything short of firmware updates can be
> done by ifconfig and therefore, presumably, foocontrol can die
> for 802.11-valued foo.

Uhhh...I don't think this is quite true.  I'm not an expert on the an(4)
driver, but ancontrol -S and ancontrol -C give a lot more information
that the new ifconfig, and I'm pretty sure that ancontrol (8) lets you
twiddle things that ifconfig doesn't.  (Antenna diversity and transmit
power spring to mind, also it is not immediately obvious to me how to
set ad-hoc mode using ifconfig(8)).

I think that a *majority* of functionality can be done with ifconfig, 
and that someone would only need to use ancontrol if they really wanted 
to do something esoteric (or at least unusual).

More comments to come...I'm typing up some feedback based on playing
with the -stable version.

Bruce.




 PGP signature

Re: Call for review... PR 25577

[Bruce A. Mah]

I stupidly wrote:

> it is not immediately obvious to me how to
> set ad-hoc mode using ifconfig(8)).

Please disregard...I see it now.

Must be my allergy meds, yeah, that's it...  :-)

Bruce.





 PGP signature

Re: Call for review... PR 25577

[Bruce A. Mah]

If memory serves me right, Brooks Davis wrote:

> If anyone wants to try it one -stable, there's a patch against it at:
> 
> http://www.one-eyed-alien.net/~brooks/FreeBSD/ifconfig.diff-stable

Cool, thanks for making this available.

> The fact that wi hasn't been repo-copied in to sys/dev in stable plus
> the spl->mutex changes mean the patches against -current don't apply
> cleanly.  The patches work great for me under -stable with a Lucent (wi)
> card, but I couldn't get my Cisco (an) card to work with or without
> them.  It's probably something to do with the ancient pile of junk I'm
> using for stable laptop testing.

I just re-built world with your patches on an IBM T20 with a Cisco
Aironet 342 PCMCIA card.  Basic send and receive seem OK, I used the new
ifconfig to turn on WEP and set the SSID and I am now typing over the
an0 interface to send this mail.

Few comments here:

1.  Seems like I needed to ifconfig the interface up before my other 
commands would take effect.  I don't recall needing to do any such 
thing with the old driver before I could do ancontrol.  Is this a 
change in behavior or did I miss something?

2.  I think there is an off-by-one error in the listing of wepkeys.  I
have exactly one 128-bit key set, which I'm using as the transmit key.
I'm pretty sure that this is key was configured as number 3 (if starting
from 1) or 2 (if starting from 0).  I'm not using any of the other four
keys supported, but I do not know their exact configurations.  "ifconfig
an0" returns (santized):

constellation:bmah% ifconfig an0
an0: flags=8843 mtu 1500
inet6 fe80::XX:XX:XX:XX%an0 prefixlen 64 scopeid 0x5 
inet XX.XX.XX.XX netmask 0xff00 broadcast XX.XX.XX.XX
inet6 fec0::XX:XX:XX:XX: prefixlen 64 
ether XX:XX:XX:XX:XX:XX
media: autoselect (DS/11Mbps) status: associated
supported media: autoselect autoselect  DS/11Mbps DS/11Mbps  
DS/5.5Mbps DS/5.5Mbps  DS/2Mbps DS/2Mbps  DS/1Mbps DS/1Mbps 
ssid XXX
stationname ""
channel 6 authmode OPEN powersavemode OFF powersavesleep 200
wepmode ON weptxkey 3
wepkey 1:64-bit wepkey 2:128-bit wepkey 3:64-bit

Just for the record, I think there's a similar problem in ancontrol(8). 
The tail of "ancontrol -C" is:

WEP Key status:
Key 0 is set  40 bits
Key 1 is set 128 bits
Key 2 is set  40 bits
Key 3 is unset
The active transmit key is 2

If I had to guess, I'd say that if there is an array of WEP keys, the 
programs are starting to read one key too late into the array when they 
display them.  There also seems to be a little disagreement as to 
whether keys are numbered starting from 0 or 1.

I did all the key management from within Windows 2000, using the
Cisco-supplied utilities.  If it's helpful, I can reboot and take some
notes from that side.

3.  In the "SEE ALSO" section of ieee80211, there is a hanging comma 
after the cross-reference to wicontrol(8).

Thanks for taking the time to do a -STABLE patch...much appreciated.

Bruce.




 PGP signature

Re: Call for review... PR 25577

[Bruce A. Mah]

If memory serves me right, Doug Ambrisko wrote:
> Bruce A. Mah writes:
> | 1.  Seems like I needed to ifconfig the interface up before my other 
> | commands would take effect.  I don't recall needing to do any such 
> | thing with the old driver before I could do ancontrol.  Is this a 
> | change in behavior or did I miss something?
> 
> I fixed this and Archie put it in -current and after 4.3 goes out he should
> MFC it.  In the interim try the patch at:
>   http://www.ambrisko.com/doug/an.patch
> it has some new features such as enabling promiscuous mode from Allan Saddi!

Yeah, David Wolfskill pointed this out too.  Wonder why I didn't see it
before...maybe something was doing an "ifconfig up" and I just didn't
realize it (pccard_ether maybe?).  Pass me the pointy hat.

> | WEP Key status:
> | Key 0 is set  40 bits
> | Key 1 is set 128 bits
> | Key 2 is set  40 bits
> | Key 3 is unset
> | The active transmit key is 2
> | 
> | If I had to guess, I'd say that if there is an array of WEP keys, the 
> | programs are starting to read one key too late into the array when they 
> | display them.  There also seems to be a little disagreement as to 
> | whether keys are numbered starting from 0 or 1.
> 
> Well I can't see that since it's not an array and the values come
> from iterating through Cisco's API and a direct query for the 
> transmit key.  Look at ancontrol for the ugly & secret details!

OK.  I have a question...an_readkeyinfo() seems to use the loop counter
i directly in determining what key number to print out. However, the
an_ltv_wepkey structure has an an_key_index member; I'm wondering if
that's somehow significant, should be used, or whatever.  I was thinking
of having an_readkeyinfo() print this out just for kicks.  No
guarantees, but I'll put it on my TODO list.

Note that an important difference between your laptop configuration and 
mine is that you are using a contiguous range of WEP keys (0 and 1) 
whereas I am not (0 and 2).

FYI:  Here's the info from Cisco's key manglement program under Win2K, 
the same interface as above:

Current Adapter is 340 Series PCMCIA
Adapter's Firmware Does Support WEP (Version V3.98)
Adapter is Associated
WEP is Enabled
WEP Key 1 is Set (40 Bits)
WEP Key 2 is Not Set
WEP Key 3 is Set (128 Bits)
WEP Key 4 is Not Set
WEP Tx Key is Key 3

Doesn't bear much resemblance to what I showed before (the transmit key 
was right, but little else).

Thanks,

Bruce.




 PGP signature

Re: Call for review... PR 25577

[Bruce A. Mah]

If memory serves me right, Doug Ambrisko wrote:
> Brooks Davis writes:
> | On Mon, Apr 02, 2001 at 12:28:38PM -0700, Doug Ambrisko wrote:
> | > Well I can't see that since it's not an array and the values come
> | > from iterating through Cisco's API and a direct query for the 
> | > transmit key.  Look at ancontrol for the ugly & secret details!
> | 
> | I'm pretty sure I've also managed to get it to reports things that just
> | plain aren't true like Bruce did.  I've bitched to my Cisco rep again
> | to try and get better doc, but so far I haven't had much luck.  I just
> | made a specific request for more data on setting and getting WEP keys.

I'd like to complain to my Cisco rep too, oh wait, I *am* my Cisco rep. 
Nevermind.  I'll try asking around on one of the internal mailing 
lists to see what I can dig up.  But my plate is pretty full if I'm 
actually going to need to hack code on this.

> | In my patches, I just copied the stuff from ancontrol since that's all
> | we've got.  The linux code is even more non-sensical then ancontrol in
> | that it reports five keys.

Five keys...could be the new home networking stuff?

> FYI we've found a bug in ancontrol and the scheme for reporting keys
> if keys are not filled in order.  It would be nice to get the 
> source for the Linux configuration utilties that they distribute
> with the driver on the Cisco web site.  I've tried to run it under
> Linux and I get "no radio found" although I can ping over the 
> Aironet card!  Linux and no source makes it hard to figure out what
> is happening. 

Can't use Linux configuration utils...I wonder if there's a minimum 
firmware rev on the card that you need?

Bruce.



 PGP signature

Re: Re[2]: FW: Filesystem gets a huge performance boost

[Bruce A. Mah]

If memory serves me right, David Xu wrote:

[dirpref stuff]

> Any plan to MFC? I am interesting to see it in 4.3-RELEASE.

I'm pretty sure it won't be in 4.3-RELEASE.  In case you didn't realize,
RELENG_4 has been in code freeze for some weeks now, preparing for a
release next week.  "Code freeze" means our release engineer only lets
critical bugfixes (and a very few selected enhancements) into the branch
pending release.  The new dirpref code hasn't even lived in HEAD long 
enough for a MFC under "normal" circumstances.

Bruce.



 PGP signature

One more typo in src/release/Makefile, rev 1.612? (w/patch)

[Bruce A. Mah]

Hi David--

Thanks for fixing the typo in src/release/Makefile.  I think however the
real cause of the error that people were seeing is a typo on the line
above...there should (I think) be a " && \" at the end of the previous
line.  So what happens is that the "make kernel-reinstall-debug" gets
run in the wrong directory, and that's why it's falling over. Patch
below.

I'm testing this now...

Cheers,

Bruce.

Index: Makefile
===
RCS file: /home/ncvs/src/release/Makefile,v
retrieving revision 1.612
diff -u -r1.612 Makefile
--- Makefile2001/04/16 15:17:27 1.612
+++ Makefile2001/04/16 16:44:41
@@ -846,7 +846,7 @@
make ${KERNEL_FLAGS} KERNEL=${KERNEL} && \
make KERNEL=${KERNEL} DESTDIR=${RD}/kernels install && \
[ -r ${.CURDIR}/../sys/${MACHINE}/conf/${KERNEL}.hints ] && \
-   cp ${.CURDIR}/../sys/${MACHINE}/conf/${KERNEL}.hints 
${RD}/kernels
+   cp ${.CURDIR}/../sys/${MACHINE}/conf/${KERNEL}.hints 
+${RD}/kernels && \
make KERNEL=${KERNEL} DESTDIR=${RD}/kernels 
kernel-reinstall.debug
 
 #




 PGP signature

Re: One more typo in src/release/Makefile, rev 1.612? (w/patch)

[Bruce A. Mah]

If memory serves me right, John Baldwin wrote:

> Also, Bruce's fix is not entirely correct as it breaks for the non-debug kern
> el
> case,

Hmmm?  I didn't know there was a choice on debug/non-debug kernels
during a "make release", but I defer to the experts.

> but I've already sent you a mail about that, just to let everyone know
> that it should be fixed shortly. :)

The longer it goes unfixed, the longer I'll be forced to do Really
Important Things (TM) rather than blow away time tinkering with "make
release" for my own nefarious purposes.  :-)

Thanks guys...

Bruce.



 PGP signature

[RFC] RELNOTESng for 5-CURRENT

[Bruce A. Mah]

(Apologies to -doc people who have probably heard this ad nauseum.)

Over the past few months, I've been working on a project that I've
taken to calling RELNOTESng, which is the overhaul of RELNOTES.TXT and
related files that we package along with a FreeBSD distribution.
I've been soliciting feedback from the other -doc folks, and it's time
to socialize this out to a wider audience.

The main problem this is intended to solve is that there's a lot of
information in many different files, and not all of its is
consistent.  For example, a list of hardware supported by FreeBSD can
currently be found in four different places (the alpha and i386
RELNOTES.TXT files, HARDWARE.TXT, and the Handbook).

What I've done is to reorganize and reformat all of the *.TXT files.
The new versions of these files are done in DocBook/SGML, which is the
markup language used for the Handbook, FAQ, and so on.

This gives us several distinct advantages:

1.  By using conditional inclusion of text, we can have one set of
source files that contains platform-independent text plus text
applicable to particular architectures (no more double commits for
each new release note).  Looking down the road, when we support
other architectures (for example, ia64 or ppc), we'll have a
scalable way of handling them.

2.  By going to DocBook, we can produce release notes in formats other
than plain ASCII text; for example, we can do HTML or PDF.  We
gain greater readability, plus we can take advantages of features
such as hyperlinks within documents.  Of course the boot floppies
still get the TXT files.

3.  By adopting the same naming conventions and directory structures
as the doc/ subtree, we can support translations of release notes,
if the translation teams are so inclined.

4.  Reorganizing the *.TXT files elminates some redundant information
and reduces the number of files that people have to read through
(they're a bit longer, but better-organized).

There are two disadvantages to going this route.  I think they're
fairly minor:

1.  Generating a set of release notes requires the DocBook toolchain
to be built, as well as the doc/ subtree.  Note that RELNOTESng
will have absolutely no effect on the buildworld/installworld
procedure.

2.  It raises the bar a bit for committers wanting to make changes to
the release notes, since they'll need to make changes to the
DocBook files.

Barring objections, I want to commit RELNOTESng, plus a patch to src/
release/Makefile, to the CVS tree.  RELNOTESng still needs a bit of
testing, and so for now, I have it controlled by a make(1) flag
defaulting to off.  Once the bugs have been shaken out, I'll make
RELNOTESng the default and stop maintaining the *.TXT files. Eventually,
the *.TXT files will get removed.

There's a snapshot of RELNOTESng for -CURRENT, updated irregularly,
at:

http://people.freebsd.org/~bmah/relnotes/

It contains PDF, HTML, and TXT versions of the various documents, as
well as a tarball of my working sources, the patch for
src/release/Makefile to integrate RELNOTESng into the release build,
and an ISO of a 5.0-CURRENT, i386 release I did with RELNOTESng
enabled.

I'd very much like to get comments from people.

Bruce.



 PGP signature

Re: [RFC] RELNOTESng for 5-CURRENT

[Bruce A. Mah]

[Please keep me as one of the explicit recipients of this email.  
Thanks.]

If memory serves me right, Makoto MATSUSHITA wrote:

> takhus> Perhaps the *.TXT files could be periodically regenerated to their 
> takhus> current location to 1) avoid a POLA violation and 2) allow for at
> takhus> least some RELNOTES without needing DocBook and doc/ (even if they
> takhus> may be slightly out of date).

[snip]

> It is true that current.freebsd.org and much of do-it-yourself
> distributions are generated with 'NODOC=YES', since it needs much time
> and disk spaces to process doc.1 target (especially setting up a
> DocBook environment).

My first reaction is, "is doing doc.1 *that* much of a problem"?  When 
I was testing, it didn't seem like building this consumed much time or 
disk space compared to the rest of the make release process (i.e. 
building world and several kernels).  A checked-out doc/ is 37 MB.

> Removing *.TXT files also makes some difficulties when ordinally "make
> buildworld/installworld" users want to know what changes are made
> (they should change their CVSup configulation file, checkout doc if
> the repository is CVSuped, install DocBook via ports, and run make(1)
> to get a plaintext of release notes).

I think the only recurring cost that people are going to have to do is
to keep a reasonably current copy of doc/.  Building the docproj port is
a one-time operation.  After that, it takes about 15 seconds of
wallclock time on my workstation to build the TXT version of the release
notes (note that you'll get the SGML sources automatically under src/
release/doc).

> Just like current 'doc' distribution of 'NODOC=YES', it would be helpful
> that *.TXT files are in src/release.

Umm, no, it's not just like the current doc distribution.  If you build
a release with NODOC=YES, you don't get any rendition of the FAQ,
Handbook, etc.  There's no *.TXT files to fall back on.

Here's my thoughts...for the record, I'm weakly opposed to regen-ing
*.TXT versions:  First, I don't want to bloat the repository with oodles
of builds to the *.TXT files.  If we do this, it ought to be be fairly
infrequently, like maybe once or twice a month.

Second, regen-ing needs to be done automatically.  I'm not going to do
it by hand.

Third, let's assume that there's some interest in actually having 
different localized versions of the release notes (note that the 
infrastructure supports it).  What language do we build for the *.TXT 
fallback files?

Finally, there needs to be some boilerplate text on the fallback files
to indicate the generation date of the fallback versions, and a
pseudo-disclaimer that they may be out of date with respect to the
actual state of the code.  If we get the automatic generation problem
solved, this one should be easy.

Like I said, I'm weakly opposed to doing this, but I'm also quite
willing to be swayed.

Cheers,

Bruce.




 PGP signature

Re: [RFC] RELNOTESng for 5-CURRENT

[Bruce A. Mah]

If memory serves me right, Wilko Bulte wrote:
> On Wed, Apr 25, 2001 at 09:42:07PM +0200, Leif Neland wrote:

> > As UPDATING may contain information nessecary to run make world, it can't b
> e built by make world.
> > Chicken and egg, methinks...
> 
> Possibly. But I was not refering to UPDATING.

Just to clarify, RELNOTESng will not have any effect whatsoever on the 
way that /usr/src/UPDATING is maintained.

Bruce.



 PGP signature

Re: [RFC] RELNOTESng for 5-CURRENT

[Bruce A. Mah]

If memory serves me right, Dima Dorfman wrote:

> On a slightly related note, do you object, or
> have plans to, build the release notes with the web site?  It would
> solve this problem very nicely.

Hi Dima--

No objections, but no plans right now either.  Mostly because I don't 
know enough about the Web site build.  Got any ideas?  :-)

I'm not sure if it will *solve* the problem, but at least it will 
allevitate it somewhat.  And it's aesthetically more pleasing to me (if 
that counts for anything).

Note that this is a fairly new capability...we currently don't have a 
link for -CURRENT or 4-STABLE release notes.  There might be some 
issues with this although I can't think of any off-hand.

> I understand that relnotes will be in
> src/, so this would have to be an optional part of the build, but at
> least having them built on www.freebsd.org would suffice.

Yeah, it should be optional.  The thing-that-generates-the-Web-pages 
would need the src/release/ module (somewhere in its filesystem, not 
necessarily in /usr/src/release), plus doc/.  RELNOTESng doesn't need a 
complete src/.

Bruce.



 PGP signature

Re: [RFC] RELNOTESng for 5-CURRENT

[Bruce A. Mah]

If memory serves me right, Wilko Bulte wrote:
> On Wed, Apr 25, 2001 at 05:06:12PM -0600, Warner Losh wrote:
> > In message <[EMAIL PROTECTED]> "Antoine Beaupre (LMC)" writ
> es:
> > : Hey whatever. Let's just keep a rendered TXT version where it always
> > : (ie. in the src/release... cvs) was but keep the originial as a sgml
> > : version in the doc tree.
> > 
> > UPDATING will continue to be a flat file, or I will no longer maintain
> > it.
> 
> Right ;-) "Form follows function"

I thought I responded to Warner's, er, strong statement of his position,
earlier, but I'm not sure.  So, for the record, I *have* no intention,
and never *had* any intention of touching src/UPDATING, changing its
format, or even gazing wistfully in its general direction.

Bruce.




 PGP signature

HEADS UP: RELNOTESng committed to 5-CURRENT

[Bruce A. Mah]

I've just committed RELNOTESng to 5-CURRENT.  If you missed the earlier 
discussions on these lists, RELNOTESng is the rewrite and restructuring 
of FreeBSD's *.TXT documentation files into DocBook.

All of the files live under src/release/doc, and src/release/doc/README
has more information.  As far as I know, the contents of the RELNOTESng
files are up-to-date with respect to 5-CURRENT's *.TXT files.  
Eventually the *.TXT files will go away.

There are a few outstanding issues remaining, but I decided to commit 
these files anyways, because having them in the repository will greatly 
facilitate fixing them:

1.  The alpha hardware list (used to be src/release/texts/alpha/
HARDWARE.TXT) does not have all of its DocBook markup yet.

2.  The hardware list generated for the alpha from the
architecture-independent files is still i386-centric.  It's better than
the old src/release/texts/HARDWARE.TXT, but there's a lot of work left
to go.  Wilko Bulte and I will be working to fix this.

3.  Several people have brought forth the idea to make the release notes
for 5-CURRENT (and 4-STABLE, when applicable) automatically built and
Web-accessible. Dima Dorfman volunteered to help make this happen.

Thanks to everyone who gave comments...they were most helpful!

Bruce.




 PGP signature

Re: PATCH: partial fix for broken "make release"...

[Bruce A. Mah]

If memory serves me right, Terry Lambert wrote:

> o The files jade_1.2.1-13.diff.gz and pdf_sec.ps are not
>   available from any of the listed mirros in the "ports"
>   hierarchy, so they can not be correctly installed, and
>   a "doc" build can not complete.  The workaround is to
>   let the above fail, and then:

Yes.  Ran into this when testing RELNOTESng.  G.

>   cd ${CHROOT}/usr/ports/distfiles
>   GOTO=ftp://sunsite.doc.ic.ac.uk/Mirrors/FreeBSD/ports/distfiles";
>   fetch ${GOTO}/jade_1.2.1-13.diff.gc

s/gc/gz

>   fetch ${GOTO}/pdf_sec.ps
> 
>   Then restart again... but this time:
> 
>   make rerelease  RELEASENOUPDATE=Y ...

Another way to do this is to fetch the files into /usr/ports/distfiles
and then do the release (this works for all distfiles, not just the
unfetchable ones).  Part of the release process copies /usr/ports/
distfiles to ${CHROOT}/usr/ports/distfiles.  In other words:

# Do this once
cd /usr/ports/distfiles
GOTO=ftp://sunsite.doc.ic.ac.uk/Mirros/FreeBSD/ports/distfiles
fetch ${GOTO}/jade_1.2.1-13.diff.gz
fetch ${GOTO}/pdf_sec.ps

# make release works normally

Cheers,

Bruce.




 PGP signature

Re: lock order reversals, anyone?

[Bruce A. Mah]

If memory serves me right, Matthew Jacob wrote:

> T-o-T about 24 hours ago:

???

> > lock order reversal
> >  1st lockmgr interlock last acquired @ /usr/src/sys/kern/kern_lock.c:239
> >  2nd 0xfe0025df8548 process lock @ /usr/src/sys/kern/kern_exit.c:542
> >  3rd 0xfeaab8d0 lockmgr interlock @
> /usr/src/sys/kern/kern_lock.c:239
> > acquiring duplicate lock of same type: "allproc"
> >  1st @ /usr/src/sys/kern/kern_proc.c:609
> >  2nd @ /usr/src/sys/kern/kern_proc.c:146
> > lock order reversal
> >  1st vnode interlock last acquired @ /usr/src/sys/ufs/ffs/ffs_vfsops.c:397
> >  2nd 0xfc80f218 mntvnode @ /usr/src/sys/ufs/ffs/ffs_vfsops.c:464
> >  3rd 0xfe0026918080 vnode interlock @ /usr/src/sys/kern/vfs_subr.c:1881

I saw something similar on my 5-CURRENT box built around 27 April.  No
core dumps that I know of.  These showed up at boot time, shortly after
my machine's SCSI devices were probed.  From /var/log/messages:

May  2 10:18:59 bmah-freebsd-1 /boot/kernel/kernel: da0:  
Fixed Direct Access SCSI-3 device 
May  2 10:18:59 bmah-freebsd-1 /boot/kernel/kernel: da0: 80.000MB/s transfers 
(40.000MHz, offset 31, 16bit), Tagged Queueing Enabled
May  2 10:18:59 bmah-freebsd-1 /boot/kernel/kernel: da0: 8761MB (17942584 512 byte 
sectors: 255H 63S/T 1116C)
May  2 10:18:59 bmah-freebsd-1 /boot/kernel/kernel: lock order reversal
May  2 10:18:59 bmah-freebsd-1 /boot/kernel/kernel: 1st lockmgr interlock last 
acquired @ /usr/src/sys/kern/kern_lock.c:239
May  2 10:18:59 bmah-freebsd-1 /boot/kernel/kernel: 2nd 0xcb64665c process lock @ 
/usr/src/sys/kern/kern_exit.c:542
May  2 10:18:59 bmah-freebsd-1 /boot/kernel/kernel: 3rd 0xc0e3f988 lockmgr interlock @ 
/usr/src/sys/kern/kern_lock.c:239
May  2 10:18:59 bmah-freebsd-1 /boot/kernel/kernel: acquiring duplicate lock of same 
type: "allproc"
May  2 10:18:59 bmah-freebsd-1 /boot/kernel/kernel: 1st @ 
/usr/src/sys/kern/kern_proc.c:607
May  2 10:18:59 bmah-freebsd-1 /boot/kernel/kernel: 2nd @ 
/usr/src/sys/kern/kern_proc.c:144
May  2 10:18:59 bmah-freebsd-1 /boot/kernel/kernel: lock order reversal
May  2 10:18:59 bmah-freebsd-1 /boot/kernel/kernel: 1st vnode interlock last acquired 
@ /usr/src/sys/kern/vfs_vnops.c:636
May  2 10:18:59 bmah-freebsd-1 /boot/kernel/kernel: 2nd 0xc050d060 mntvnode @ 
/usr/src/sys/ufs/ffs/ffs_vfsops.c:975
May  2 10:18:59 bmah-freebsd-1 /boot/kernel/kernel: 3rd 0xccf9c52c vnode interlock @ 
/usr/src/sys/ufs/ffs/ffs_vfsops.c:984
May  2 10:19:12 bmah-freebsd-1 ntpd[355]: ntpd 4.0.99b Fri Apr 27 16:43:30 PDT 2001 (1)
May  2 10:19:12 bmah-freebsd-1 ntpd[355]: using kernel phase-lock loop 2040
May  2 10:19:12 bmah-freebsd-1 ntpd[355]: using kernel phase-lock loop 2041

My machine is running a GENERIC kernel.

Bruce.




 PGP signature

Re: [RFC] RELNOTESng for 5-CURRENT

[Bruce A. Mah]

If memory serves me right, Nik Clayton wrote:

> Like it.

OK, thanks, that's a good start...

> My main concern is that this is in the src/ tree.  As other people
> have said this is going to complicate things for src/ folks who just
> want up to date release notes, 

This problem (which I agree is valid) is not so much a problem as to 
where the release notes live, but the fact that one needs to actually 
build human-readable renderings of them.  If people can't be bothered 
to install the docproj port and the doc/ tree to get release notes 
living in src/, putting the release notes in doc/ sure isn't going to 
help.  It's trivial to put the release notes for -RELEASE versions up 
(the Web site does this already), and Dima thinks it's possible to do 
this for -CURRENT too (and -STABLE if and when it's applicable).

> and for doc/ people who might not track
> -stable or -current, but who want to work on the SGML side of things.

You don't need to track -STABLE or -CURRENT to work on the docs.  I run 
4-STABLE on all of my machines except one, yet I routinely use those 
machines to handle commits to 5-CURRENT and 3-STABLE as well:

% cd ~bmah/FreeBSD/5-CURRENT
% cvs co release
% cd ~bmah/FreeBSD/4-STABLE
% cvs co -r RELENG_4 release
% cd ~bmah/FreeBSD/3-STABLE
% cvs co -r RELENG_3 release

Putting the release notes in doc/ means that the src/ committers (who I 
just *barely* got now to make changes to the release notes) are going 
to have to chase through parts of the doc/ hierarchy.  I'm pretty sure 
I'm going to lose the few converts I've won if I let people talk me 
into this.

> Also, if we want to put these on the website then it means that anyone
> doing so will need to have checked out www/, doc/, and src/release/
> trees.

I got the impression that this would not be hard.  They don't need to 
have all of src/ checked out, and if enough people complain about it, we 
can probably make another module which is just the RELNOTESng part of 
src/release.

> Could this come under doc/, and either have a CVS branch for RELENG_4
> for just the release notes directory hierarchy, or I could start work on
> the osrel{min,max,in} attribute support code again. . .

Can it come under doc/?  Sure.  Do I think it's the right thing?  No.

I don't like the idea of having one part of doc/ branched and another 
part not (especially when the part that's not branched lives higher in 
the directory hierarchy).  So if I want to work on RELENG_4's release 
notes, I need to checkout HEAD's doc/ and then check out the release 
note's subtree with a RELENG_4 tag.

The osrel{min,max} attributes work to a point, but they presume that
there is a total ordering on version numbers.  For -RELEASEs, this just
*might* be possible.  But when there's multiple development tracks going
on in parallel (and release note items appear *between* releases), this
falls apart.  How do you express the idea that the fix for the
vulnerability described by a security advisory is present in
3.5-STABLE-after-2001-04-06, 4.2-STABLE-after-2001-04-06, and
5.0-CURRENT-after-2001-04-06?  CVS branches (for all their shortcomings)
handle this pretty well, without the need for complex stylesheet
customizations.  Let's just use the right tool for the right job.

(BTW I do want to try to use what you've done with attributes to
implement the DocBook arch= attribute, to do better multi-platform
support.)

I appreciate all the solutions people have put forth, but I think
they're solving a non-problem.  If I leave the release notes in src/
(which is where they've *been* all along, I might add), it's a more
natural fit because release notes are tied to CVS branches and releases
(tags) on those branches.  They live closer in the filesystem hierarchy
and, more importantly, they get exactly the same branching behavior as
the rest of src/.

Thanks,

Bruce.




 PGP signature

HEADS UP: RELNOTESng now default in -CURRENT, *.TXT files removed

[Bruce A. Mah]

RELNOTESng is now the default for -CURRENT release builds.  Floppy
images get ASCII renderings only, while the CDROM and FTP areas get both
ASCII and HTML.

To disable all release note documentation building (i.e. for minimal
builds), define NORELNOTES at release-building time.  Note that release
notes require doc building as well (it may be possible to untangle this
dependency in the future).

Please also note that the old *.TXT files are now gone from -CURRENT.

dd did some infrastructure (currently disabled by default) to the Web
site build that will make -CURRENT snapshot release notes available;
we're waiting for someone like nik or wosch (hint hint, guys) to add a
CVS update line to whatever magic kicks off Web site builds.  Until
then, renderings of the release documentation can continue to be found
at:

http://people.freebsd.org/~bmah/relnotes/

Thanks for everyone's help and suggestions!

Bruce.

PS.  4-STABLE is unaffected by these changes (for now), but it is my 
intent to MFC RELNOTESng after a brief shake-down period.



 PGP signature

Re: make release failure

[Bruce A. Mah]

If memory serves me right, Dima Dorfman wrote:
> John Hay <[EMAIL PROTECTED]> writes:

> > > > *** Filesystem is 1440 K, 66 left
> > > > *** 4000 bytes/inode, 116 left
> > > > cp: /usr/src/release/texts/FLOPPIES.TXT: No such file or directory
> > > 
> > > What revision of src/release/Makefile do you have?  You want 1.618.
> > 
> > beast# fgrep '$FreeBSD' /usr/src/release/Makefile
> > # $FreeBSD: src/release/Makefile,v 1.618 2001/05/25 18:01:31 bmah Exp $
> > beast# fgrep 'texts/FLOPPIES.TXT' /usr/src/release/Makefile
> > @cp ${.CURDIR}/texts/FLOPPIES.TXT ${RD}/floppies/README.TXT

Mea culpa.  Mea maxima culpa.  :-(

> Could you please try the attached, untested patch?  I don't know
> enough about the release build process to know if it should work, but
> I guess it's worth a shot.  Bruce Mah (cc'd) should know whether it's
> the Right(tm) fix.

Just got back from a road trip...my brain is a little fried now.

dd is going in the right direction, but the Makefile needs to consider
if NORELNOTES is defined or not.  I recommend something like the 
patch appended below...also untested...I'll test this tomorrow 
when I am more awake, and maybe by then I will have figured out why 
this slipped through my testing.

Sorry folks...

Bruce.

Index: Makefile
===
RCS file: /home/ncvs/src/release/Makefile,v
retrieving revision 1.618
diff -u -r1.618 Makefile
--- Makefile2001/05/25 18:01:31 1.618
+++ Makefile2001/05/28 06:29:31
@@ -694,8 +694,13 @@
@sh -e ${.CURDIR}/scripts/doFS.sh ${RD}/floppies/fixit.flp ${RD} \
${MNT} ${FIXITSIZE} ${RD}/fixitfd ${FIXITINODE} ${FIXITLABEL}
 # Do our last minute floppies directory setup in a convenient place.
-   @cp ${.CURDIR}/texts/FLOPPIES.TXT ${RD}/floppies/README.TXT
+.if !defined(NORELNOTES)
+   @cp ${.CURDIR}/doc/${RELNOTES_LANG}/readme/article.txt \
+   ${RD}/floppies/README.TXT
@(cd ${RD}/floppies; md5 README.TXT *.flp > CHECKSUM.MD5)
+.else
+   @(cd ${RD}/floppies; md5 *.flp > CHECKSUM.MD5)
+.endif
touch release.9
 
 #




 PGP signature

Re: make release failure

[Bruce A. Mah]

If memory serves me right, Dima Dorfman wrote:
> "David O'Brien" <[EMAIL PROTECTED]> writes:
> > On Sun, May 27, 2001 at 11:32:09PM -0700, Bruce A. Mah wrote:
> > > +.if !defined(NORELNOTES)
> > 
> > Do we really need Yet Another Knob?  Why isn't NODOC suffient?
> 
> FWIW, I think we should lose NORELNOTES; as you say, NODOC is
> sufficient.

You both speak the truth.  :-)

The following patch fixes the make release breakage and brings the
behavior formerly controlled by NORELNOTES under NODOC.  I'm going to 
do a little (more) testing today, followed by a commit and some more 
testing.  Feedback is as usual appreciated...

Thanks for the help all...

Bruce.


Index: Makefile
===
RCS file: /home/ncvs/src/release/Makefile,v
retrieving revision 1.618
diff -u -r1.618 Makefile
--- Makefile2001/05/25 18:01:31 1.618
+++ Makefile2001/05/28 18:38:35
@@ -69,15 +69,11 @@
 # CPU cycles (some of the programs are C++, and things like ghostscript
 # belong to the required ports nevertheless).
 #
-# Setting this also disables doc.2 (RELNOTESng).
+# Setting this also disables building of release note documentation
+# (RELNOTESng).
 #NODOC=  YES
 #NOPORTS=  YES
 
-# RELNOTESng can be disabled by uncommenting the following variable
-# definition.  RELNOTESng depends on having ports enabled for this
-# release build.
-#NORELNOTES=   YES
-
 # Uncomment and modify this definition if you want the release notes 
 # and other release documentation in a language other than English.
 #RELNOTES_LANG=en_US.ISO_8859-1
@@ -109,7 +105,7 @@
 # on the boot floppy.  WARNING: Breaks on some Athlon (K7) motherboards.
 AUTO_KEYBOARD_DETECT?= 0
 
-.if !defined(NORELNOTES)
+.if !defined(NODOC)
 DIST_DOCS_ARCH_INDEP=  readme errata
 DIST_DOCS_ARCH_DEP=installation relnotes hardware
 .endif
@@ -219,9 +215,7 @@
 .endif
 
 .if !defined(NODOC)
-DOCREL= doc.1
-.if !defined(NORELNOTES)
-DOCREL+= doc.2
+DOCREL= doc.1 doc.2
 .endif
 .endif
 
@@ -240,11 +234,6 @@
@echo "unset NOPORTS, or set at least DOMINIMALDOCPORTS to YES!"
@exit 1
 .endif
-.if !defined(NORELNOTES) && defined(NODOC)
-   @echo "Docs are required for building the release notes.  Either"
-   @echo "set NORELNOTES or unset NODOC!"
-   @exit 1
-.endif
 .if make(release)
 .if exists(${CHROOTDIR})
 # The first command will fail on a handful of files that have their schg
@@ -357,9 +346,6 @@
 .if defined(NOSRC)
echo "export NOSRC=${NOSRC}">> ${CHROOTDIR}/mk
 .endif
-.if defined(NORELNOTES)
-   echo "export NORELNOTES=${NORELNOTES}"  >> ${CHROOTDIR}/mk
-.endif
 .if defined(RELNOTES_LANG)
echo "export RELNOTES_LANG=${RELNOTES_LANG}">> ${CHROOTDIR}/mk
 .else
@@ -617,7 +603,7 @@
ln ${RD}/mfsfd/stand/etc/services ${RD}/mfsfd/etc/services
ln ${RD}/mfsfd/stand/etc/netconfig ${RD}/mfsfd/etc/netconfig
gzip -9c ${.CURDIR}/../COPYRIGHT > ${RD}/mfsfd/stand/help/COPYRIGHT.hlp.gz
-.if !defined(NORELNOTES)
+.if !defined(NODOC)
@for i in ${DIST_DOCS_ARCH_INDEP}; do \
  gzip -9c ${.CURDIR}/doc/${RELNOTES_LANG}/$$i/article.txt > 
${RD}/mfsfd/stand/help/`echo $${i} | tr 'a-z' 'A-Z'`.TXT.gz; \
done
@@ -694,8 +680,13 @@
@sh -e ${.CURDIR}/scripts/doFS.sh ${RD}/floppies/fixit.flp ${RD} \
${MNT} ${FIXITSIZE} ${RD}/fixitfd ${FIXITINODE} ${FIXITLABEL}
 # Do our last minute floppies directory setup in a convenient place.
-   @cp ${.CURDIR}/texts/FLOPPIES.TXT ${RD}/floppies/README.TXT
+.if !defined(NODOC)
+   @cp ${.CURDIR}/doc/${RELNOTES_LANG}/readme/article.txt \
+   ${RD}/floppies/README.TXT
@(cd ${RD}/floppies; md5 README.TXT *.flp > CHECKSUM.MD5)
+.else
+   @(cd ${RD}/floppies; md5 *.flp > CHECKSUM.MD5)
+.endif
touch release.9
 
 #
@@ -707,7 +698,7 @@
-@ln -s . ${FD}/${BUILDNAME}
@cd ${RD} && find floppies -print | cpio -dumpl ${FD}
@cd ${RD}/dists && find . -print | cpio -dumpl ${FD}
-.if !defined(NORELNOTES)
+.if !defined(NODOC)
@for i in ${DIST_DOCS_ARCH_INDEP}; do \
  cp ${.CURDIR}/doc/${RELNOTES_LANG}/$$i/article.txt ${FD}/`echo $${i} | tr 
'a-z' 'A-Z'`.TXT; \
  cp ${.CURDIR}/doc/${RELNOTES_LANG}/$$i/article.html ${FD}/`echo $${i} | tr 
'a-z' 'A-Z'`.HTM; \
@@ -746,7 +737,7 @@
@cp ${.CURDIR}/fixit.profile ${CD_DISC2}/.profile
@echo "CD_VERSION = ${BUILDNAME}" > ${CD_DISC1}/cdrom.inf
@echo "CD_VERSION = ${BUILDNAME}" > ${CD_DISC2}/cdrom.inf
-.if !defined(NORELNOTES)
+.if !defined(NODOC)
@for i in ${DIST_DOCS_ARCH_INDEP}; do \
  cp ${.CURDIR}/doc/${RELNOTES_LANG}/$$i/article.txt ${CD_DISC1}/`echo $${i} | 
tr 'a-z' 'A-Z'`.TXT; \
  cp ${.CURDIR}/doc/${RELNOTES_LANG}/$$i/article.html ${CD_DISC1}/`echo $${i} 
| tr 'a-z' 'A-Z'`.HTM; \



 PGP signature

Re: make release failure

[Bruce A. Mah]

If memory serves me right, John Hay wrote:
> Yes, this patch fix it for me. I had to convert the spaces back to tabs
> though. :-)

Hi John--

I was trying to test out another patch, which (in addition to fixing 
the problem you found) also folds the functionality of NORELNOTES into 
NODOC.  Unfortunately, my -CURRENT test box is having some difficulties 
(probably VM-related) and it's going to take a little while before I 
can do a "make release" again to do any testing.  :-(

I'll see what I can do about getting my first patch committed to at 
least unbreak "make release".

Thanks for testing my patch, BTW!

Bruce.




 PGP signature

freelist corruption: more info

[Bruce A. Mah]

Trying to fix some make release problems, I've kept running into the
same freelist corruption problems that kris and dougb experienced
earlier this week.  Main difference is that I notice when the box
(-CURRENT from 29 May, GENERIC kernel, UP) crashes.  :-p

Not being a -CURRENT guru, I haven't decided if I'm going to try Tor
Egge's patch or just slug it out to try to finish fixing make release 
(which is my main goal at this point).

Just as an FYI, here's the tombstone and a stack trace in case it's
useful to anyone.

Cheers,

Bruce.

-8<-8<-

Data modified on freelist: word 2 of object 0xc1985a00 size 52 previous type pagedep 
(0xd6adc0de != 0xdeadc0de)


Fatal trap 12: page fault while in kernel mode
fault virtual address  = 0xdeadc0e8
fault code = supervisor read, page not present
instruction pointer= 0x8:0xc0376ab8
stack pointer  = 0x10:0xcba7fb9c
frame pointer  = 0x10:0xcba7fb9c
code segment   = base 0x0, limit 0xf, type 0x1b
   = DPL 0, pres 1, def32 1, gran 1
processor eflags   = interrupt enabled, resume, IOPL = 0
current process= 17 (swi3: cambio)
kernel: type 12 trap, code=0
Stopped at  worklist_remove+0x1c:   cmpw$0,0xa(%ecx)
db> trace
worklist_remove(deadc0de) at worklist_remove+0x1c
free_diradd(deadc0de) at free_diradd+0x26
free_newdirblk(c1396b70) at free_newdirblk+0x32
handle_written_inodeblock(c241a300,c64135d8) at handle_written_inodeblock+0x2b2
bufdone(c64135d8,cba7ff40,c0136a1b,c64135d8,c1394400) at bufdone+0x101
bufdonebio(c64135d8) at bufdonebio+0xe
dadone(c127f400,c1394400) at dadone+0x1fb
camisr(c048ccd4) at camisr+0x1c5
ithread_loop(c0e48980,cba7ffa8) at ithread_loop+0x2bf
fork_exit(c022c118,c0e48980,cba7ffa8) at fork_exit+0xb4
fork_trampoline() at fork_trampoline+0x8
db> 





 PGP signature

Re: make release failure

[Bruce A. Mah]

If memory serves me right, John Hay wrote:

> I have now also tested your second patch and with a minor mod to make
> make happy, the release finished. Here is the patch as I have used it.

[snip]

Great, thanks for testing this!  I'm still having problems keeping my
scratch box alive long enough for a make release to complete, so this is
much appreciated.  (I did get far enough to find the mistake in the
patch that you also fixed.)  I committed the corrected patch with one
additional, minor mod (last instance of NORELNOTES changed to NODOC).

Thanks again,

Bruce.



 PGP signature

Re: freelist corruption: more info

[Bruce A. Mah]

I wrote:

> Trying to fix some make release problems, I've kept running into the
> same freelist corruption problems that kris and dougb experienced
> earlier this week.  Main difference is that I notice when the box
> (-CURRENT from 29 May, GENERIC kernel, UP) crashes.  :-p

At dougb's urging, I applied Tor's patch to ffs_softdep.c.  I *think* 
the results were positive; my machine made it through a "make release" 
apparently successfully.

Got the following entries in /var/log/messages though:

May 30 20:10:10 bmah-freebsd-1 /boot/kernel/kernel: handle_written_filepage: active 
pagedep
May 31 02:18:30 bmah-freebsd-1 /boot/kernel/kernel: handle_written_filepage: active 
pagedep
May 31 02:18:30 bmah-freebsd-1 /boot/kernel/kernel: handle_written_filepage: active 
pagedep

I guess it should be obvious by now but I have softupdates enabled for 
all filesystems except for /.

Thanks,

Bruce.





 PGP signature

Re: anyone seen these outside of alpha? or on non-SMP?

[Bruce A. Mah]

If memory serves me right, David Wolfskill wrote:

> >Someone should test and commit Tor's patch.  I didn't have time to
> >check whether it fixed the problems before I left (and I'm sure as
> >hell not going to update back to -current remotely to check myself :-)
> 
> FWIW, I applied that patch to the -CURRENT side of my laptop a couple
> of days ago.  Since then, I've been able to do my daily -CURRENT builds
> in multi-user mode, within an X environment, using -j4 on the "make
> buildworld" step.

I did the patch on one of my scratch boxes, and it's allowed me to do 
"make release" without the machine dying mid-way through.  (i386, UP, 
GENERIC kernel, softupdates enabled on all filesystems except /, 
multi-user, no X).

There was a bit of discussion when I reported this apparent progress to
-current last week (look for a thread entitled "freelist corruption:
more info").

Bruce.



 PGP signature

Re: HEADS UP: doc/ tree frozen (was Re: HEADS UP for /usr/src/release/doc & /usr/doc)

[Bruce A. Mah]

If memory serves me right, "Andrey A. Chernov" wrote:
> On Tue, Jun 12, 2001 at 00:51:32 +0900, Motoyuki Konno wrote:
> > 
> > o  tell Nik about the change.
> > 
> >Nik is responsible for doc/ tree.
> > 
> > o  discussion about "when" we do repo-copy.
> > 
> >To minimize the side effect of the change,  prior announcement
> >(at least, to [EMAIL PROTECTED]) and discussion are very important.  
> 
> 1) I post HEADS UP to -doc several hours before the change happens - no
> one object.

Let's see.  You sent a heads-up to -CURRENT for /usr/src/release/doc and
/usr/doc at "Mon, 11 Jun 2001 03:56:50 +0400".  This was the first hint
that I would have had that you were going to touch RELNOTESng at all.
The commit that renamed RELNOTESng happened about "2001/06/10 18:48:17
PDT". This was, er, let's see, about *two hours* later?!?

No wonder no one objected...I bet you were already finished before most 
people read your heads-up message!  Did you realistically think that a 
two-hour advance notice on a weekend was sufficient?

> 2) Peter does repo-copy as I ask. I have wrong assumption that he
> coordinates with Nik at this subj. 
> 
> >doc/ and src/ is different.  Renaming under doc/ is not "must".
> 
> All changes of such nature are not "must" - there are always hackarounds
> exists. The reason for them is to minimize constant efforts and
> possible confusion.

There would have been less confusion if your heads-up had actually been 
sent with enough advance warning that people would have actually *read* 
it.

> > For example, see the definition of "DOC_LANG" in src/release/Makefile.
> 
> Did you actually look there? I already fix it for -current and plan to
> MFC, but stuck in current misunderstanding we discuss.

You broke the overnight snapshot build of RELNOTESng for RELENG_4 (jkh 
just sent me the build failure report).  But I see now that you've just 
MFC-ed something to src/release/Makefile...hope this fixes it.

For the record, I'd just like to state my extreme annoyance at this lack
of notification.  I don't think I'm being overly demanding.  It'd have
been good enough for me personally if, say, two days ago, you'd sent a
message to -doc saying "we're going to re-do some of the I18N stuff, go
read -i18n for details".

Bruce.

PS.  And perhaps someone can tell me if these changes are going to get 
MFC-ed and if so, how RELNOTESng is going to get handled.  Remember, 
it's branched, unlike doc/.



 PGP signature

Re: HEADS UP: doc/ tree frozen (was Re: HEADS UP for /usr/src/release/doc & /usr/doc)

[Bruce A. Mah]

If memory serves me right, "Andrey A. Chernov" wrote:

> > There would have been less confusion if your heads-up had actually been=
> =20
> > sent with enough advance warning that people would have actually *read*=
> =20
> > it.
> 
> I agree, but just imagine that I have assumption that Peter already
> resolve this issue with Nick (since he do repo copy) and you'll find=20
> a reason to not be extra-cautious.

Gr...no, I wouldn't find a reason to not be "extra-cautious".  But 
I'm probably not going to convince you of that.

> > You broke the overnight snapshot build of RELNOTESng for RELENG_4 (jkh=20
> > just sent me the build failure report).  But I see now that you've just=
> =20
> > MFC-ed something to src/release/Makefile...hope this fixes it.
> 
> Immediate MFC is against our policy, isn't?=20

So is immediate breakage.

> Tell me if there any problems appearse.

RELNOTESng is broken for RELENG_4.  I would have warned you about the 
possibility of this, if you'd bothered to ask first.

> > PS.  And perhaps someone can tell me if these changes are going to get=20
> > MFC-ed and if so, how RELNOTESng is going to get handled.  Remember,=20
> > it's branched, unlike doc/.
> 
> src locale rename changes not be MFC-ed, they are for 5.x branch only.
> Since RELNOTES branched I left to RELNOTES poeople to decide if they
> want to follow new names policy or not.

(Bruce starts wondering why he bothered to get a haircut this weekend,
because he's starting to pull his hair out now.  In chunks.)

Agh.  Look, Andrey, *I'm* the person who designed RELNOTESng, and
this is the first *I've* heard of it!  :-(

I'd go on, but I'm remembering a (good) rule about not fighting with
other committers in public.  I'll invoke this on myself now.

It looks like the easiest way out of this will be to follow your new
names policy on the RELENG_4 branch (at least for doc/ and src/release/
doc/).  This will involve a repo-copy at the least, but I've never seen
a repo-copy done for files on a branch.  Please *don't* do this.  Let
*me* first do some *testing* first, and then ask for the repo-copy
myself when I'm satisfied that it will work.  Also before doing this I
want to find out if nik wants to take any other actions for doc/, in
case there are changes that might need to be coordinated.

Bruce.




 PGP signature

Re: HEADS UP: doc/ tree frozen (was Re: HEADS UP for /usr/src/release/doc & /usr/doc)

[Bruce A. Mah]

If memory serves me right, "Andrey A. Chernov" wrote:

> On Mon, Jun 11, 2001 at 11:42:27 -0700, Bruce A. Mah wrote:
> > >=20
> > > Immediate MFC is against our policy, isn't?=3D20
> >=20
> > So is immediate breakage.
> 
> Yes, but fixed.

It's still broken.

> It seems that people forget that every big change means
> some period to settle down.

I personally haven't forgotten that.

But it seems that people forget that big changes require some advance
notice (and testing), to reduce the amount of settling down that is
required.  As I mentioned in my last message, I would have gladly
explained the potential problem to you, if you'd posted a heads-up
message with a little advance notice.

> > RELNOTESng is broken for RELENG_4.  I would have warned you about the=20
> > possibility of this, if you'd bothered to ask first.
> 
> How exactly it is broken? I didn't touch a bit of RELNOTES on -stable.

RELNOTESng depends on part of the doc/ tree.  Note that doc/ is not 
branched, but src/release/doc/ is.  When you moved parts of
the doc/ tree around in -CURRENT, you caused doc/ on -CURRENT to become 
inconsistent with src/ on 4-STABLE.  This broke RELNOTESng on 4-STABLE.

What I am saying is that it appears to me that src/release/doc/ on
RELENG_4 needs to be changed to reflect the new naming scheme.  It is
broken now, and will not build, because of inconsistencies in naming
language codes between src/ in 4-STABLE and doc/ in -CURRENT.

> 3) I have no opinion is it must be done in -stable too or not. Personally
> I not plan to touch those bits in -stable in any case, so they remain as
> is and can't be broken as you say unless I miss some technical details you
> not explain.

It's broken.  You missed some details.  I've tried to explain it as best
I can in email.

As you can see by the attached output, there is a definite breakage
here.  Please *don't* try to fix it.  Please let *me* figure out a fix
and do some testing, as well as coordination with nik and the
repo-meisters.  Thank you.

Bruce.

-

intruder:doc% make DOC_PREFIX=/usr/doc
===> en_US.ISO_8859-1
===> en_US.ISO_8859-1/relnotes
===> en_US.ISO_8859-1/relnotes/alpha
/usr/local/bin/openjade -ioutput.html -ioutput.html.images -V nochunks -V openja
de -c /usr/doc/en_US.ISO_8859-1/share/sgml/catalog -c /usr/doc/share/sgml/catalo
g -c /usr/local/share/sgml/docbook/dsssl/modular/catalog -c /usr/local/share/sgm
l/docbook/catalog -c /usr/local/share/sgml/openjade/catalog -c /usr/users/bmah/F
reeBSD/RELENG_4/release/doc/en_US.ISO_8859-1/relnotes/alpha/../../../share/sgml/
catalog -d /usr/users/bmah/FreeBSD/RELENG_4/release/doc/en_US.ISO_8859-1/relnote
s/alpha/../../../en_US.ISO_8859-1/share/sgml/release.dsl -t sgml /usr/users/bmah
/FreeBSD/RELENG_4/release/doc/en_US.ISO_8859-1/relnotes/alpha/article.sgml > art
icle.html || (rm -f article.html && false)
/usr/local/bin/openjade:E: cannot open "/usr/doc/en_US.ISO_8859-1/share/sgml/cat
alog" (No such file or directory)

[ad nauseum]





 PGP signature

Re: HEADS UP: doc/ tree frozen (was Re: HEADS UP for /usr/src/release/doc & /usr/doc)

[Bruce A. Mah]

I'm going to respond to exactly one line of your email:

>   Fix RELNOTESng affected pathes to new scheme without MFCing

This is the solution I am favoring, pending some discussion with nik.
Please let me deal with it.  Thanks.

I am deliberately *not* responding to the remainder of this message,
because my doing so would most likely not lead to a productive outcome.

Bruce.



 PGP signature

Re: feature set for 5.0

[Bruce A. Mah]

If memory serves me right, David Lebel wrote:

> I'm currently using the -STABLE branch of FreeBSD, and I'm wondering if there
> is a page somewhere that lists the feature set planned for 5.0 when it is
> released?  How will it compare to the current 4.x branch ?

It's really hard to predict the future like that.  :-)

If you want to know the state of 5-CURRENT right now, that's what 
src/release/texts/{i386,alpha}/RELNOTES.TXT is for.  (Modulo the fact that
someone, quite possibly me, needs to make some updates to this file to
sync it to reality.)

Bruce.



 PGP signature

Re: Other Linux stuff...

[Bruce A. Mah]

If memory serves me right, Marcel Moolenaar wrote:

> So, from a pure
> ELF layout point of view, both shared objects and executables are the
> same. But a shared library is not guaranteed to be executable. Allowing
> shared objects to be executed is in violation with the specs:

This may be a really stupid question, but what on Earth do they gain by 
allowing the execution of shared object files?

Bruce.




 PGP signature

Re: sysinstall.8 Breaking buildworld

[Bruce A. Mah]

If memory serves me right, "Crist J. Clark" wrote:
> I had some buildworld failures earlier this week. In
> src/share/man/man8 the Makefile includes code to get the sysinstall.8
> manpage. Since the manpage lives in src/release, this requires that
> you CVSup src-release. I had not been. This broke buildworld which had
> worked in the past. sysinstall.8 is the only file in src-release that
> is required for a buildworld. It seems somewhat silly to me that you
> are required to grab the whole thing for that one file.

OK...I was one of the people who (indirectly) pushed for this.  In a
nutshell, I (and, independently, several other people) noticed that the
sysinstall(8) manpage never gets installed as a part of the binary
distributions or by an installworld.  (I got highly confused by this
while rewriting some other parts of the documentation.)  The solution
was to make sure that an installworld installs this manpage.

> I made the change to the Makefile which makes sysinstall.8 and
> src-release optional. I included it in a reply to the PR that
> precipitated the change,
> 
>   http://www.FreeBSD.org/cgi/query-pr.cgi?pr=19818

My personal opinion is that sysinstall.8 is a part of the base system
and shouldn't be optional. If we take your suggestion, it means that
installworld will sometimes install this manpage and sometimes it won't.

A good counter-argument is that installworld doesn't touch 
/stand/sysinstall, and therefore shouldn't touch the manpage either.

Idea:  Maybe we need the release building process to do this instead?
On all of my systems, the sysinstall binary came from a CD, and never
got touched by any subsequent installworlds.

> Anyone have a good reason why everyone _must_ have src-release to
> buildworld? 

I never thought of trying to do a buildworld with anything less than 
src-all.  I guess my counter question is:  Anyone have a good reason to 
do buildworlds *without* /usr/src/release/?

Bruce.




 PGP signature

Re: Current-ISO

[Bruce A. Mah]

If memory serves me right, "Sidwell, Josh" wrote:
> I have been unsucessfully trying to build an ISO image of the 5.0-CURRENT
> branch for the past several weeks.  Is anyone aware of a tool to pull the
> latest tree and turn it into an ISO image?

http://www.freebsd.org/FAQ/hackers.html#CUSTREL

Bruce.



 PGP signature

Re: sysinstall.8 Breaking buildworld

[Bruce A. Mah]

If memory serves me right, Ben Smithurst wrote:

> yeah, but it can be used as many things.  If invoked as "rm" sysinstall
> behaves just like the real rm, it happens to be one big binary.

The thing in /stand is a crunchgen(8) binary.  sysinstall itself is
(chug, chug) 850K.  After being stripped, it's 798K:

1616 -rwxr-xr-x  1 root  wheel  817416 Jan 11 14:14 sysinstall

Bruce.




 PGP signature

Re: pkg_update

[Bruce A. Mah]

If memory serves me right, Nik Clayton wrote:
> On Wed, Feb 07, 2001 at 08:23:35PM -0600, Michael C . Wu wrote:
> > On Thu, Feb 08, 2001 at 01:56:11AM +0100, Leif Neland scribbled:
> > | It seems pkg_update is only usable when installing from packages, not fro
> m
> > | ports.
> > 
> > Because it is a package update system.  If you want to update
> > from the ports, use 'pkg_version -c |sh'
> 
> Never, ever, *ever* do this.
> 
> "pkg_version -c" is a hack to make cut-n-paste easier.  The output is
> sorted alphabetically and no notice is taken of dependencies between
> different ports.

Plus it's been known to wipe out Ports Upgrade kits.  This was 
particularly bad when some upgrade kits replaced little non-essentials 
like ld*.so, things like that.

I just put a big fat warning to this effect followed by "exit 1" at the
start of the commands output, and committed to -CURRENT.  I'll MFC early
next week.

Bruce.




 PGP signature

Re: pkg_update

[Bruce A. Mah]

[moved to -ports]

If memory serves me right, "Leif Neland" wrote:

> Couldn't it be made possible to use just the update-of-dependencies part of p
> kg_update without doing the pkg_delete/pkg_install bit?
> 
> Perhaps I'll try...

Manipulating the bits is relatively straightforward.  Doing so in a
meaningful way, and being able to cover all the edge cases, that's quite
hard (as I've just re-learned).  If you browse through the archives of
-ports for the last few days, you'll get an idea of some of the
problems.  Every few months, the topic comes up, and discussion is just
tapering off from the last round.

Not to say you shouldn't work on this problem...just saying that it's
not quite as straightforward as most people (myself included) think when
they first tackle it.

Cheers,

Bruce.




 PGP signature

Re: cvsweb

[Bruce A. Mah]

If memory serves me right, Andrew Thompson wrote:

> Has the cvs website stopped updating itself?
> 
> http://www.freebsd.org/cgi/cvsweb.cgi/www/en/releases/5.0R/ is showing 
> ver 1.131 of todo.sgml but 
> http://www.freebsd.org/cgi/cvsweb.cgi/www/en/releases/5.0R/todo.sgml is 
> showing ver 1.120

Hmmm?

When I just looked, 

http://www.freebsd.org/cgi/cvsweb.cgi/www/en/releases/5.0R/todo.sgml

showed revisions of todo.sgml up to (and including) 1.131.

Bruce.





msg50108/pgp0.pgp
Description: PGP signature

Re: FreeBSD 5.0 RC3 now available

[Bruce A. Mah]

If memory serves me right, Andy Farkas wrote:

> > Once again it's my pleasure to announce Release Cadidate 3 of
> > FreeBSD 5.0.
> 
> Perhaps I do things in a non-standard way, but its worked for the last 8
> years from 2.x through to 4.7-stable.
> 
> Firstly, I download 'floppies' and create the 2 boot disks, kern.flp and
> mgsroot.flp. Then I download 'bin' (now called 'base'!?) to my fileserver.
> 
> Next, I boot the box with 2 the new floppies, and tell sysinstall to use
> 'FTP' to the fileserver URL (ftp://172.22.2.2) and install 'minimal' (in
> other words, just install 'bin' (now called 'base'!? - anyone remember
> the acronym POLA?)).

...which was documented (along with the reason why this change was
made) in the release notes.  :-)

Cheers,

Bruce.





msg50115/pgp0.pgp
Description: PGP signature

Re: FreeBSD 5.0 RC3 now available

[Bruce A. Mah]

If memory serves me right, "Craig Reyenga" wrote:
> These mentioned licensing issues make sense, however I still think that
> there should be some sort of system to ensure big and/or popular packages to
> make it to CD #1.

No matter what, disc#1 has a finite amount of space and it's going to be
impossible to come up with a combination of packages that keeps everyone
happy.  Sooner or later, "popular" comes down to somebody's judgement.

To see what's currently in the package split, look at 
src/release/scripts/print-cdrom-packages.sh (for whatever branch 
interests you).  Note that in addition to the packages listed there, we 
also need to put all of their dependencies on disc#1 as well.  These 
dependencies likely account for a lot of the "small packages and 
ones that are not popular seem to make in on the first CD".

(FYI, the 5.0-RC3 package set occupies 339MB of a 560MB ISO image.)

Bruce.





msg50259/pgp0.pgp
Description: PGP signature

Re: FreeBSD 5.0 RC3 now available

[Bruce A. Mah]

If memory serves me right, "Craig Reyenga" wrote:
> >No matter what, disc#1 has a finite amount of space and it's going to be
> >impossible to come up with a combination of packages that keeps everyone
> >happy.  Sooner or later, "popular" comes down to somebody's judgement.
> >
> >To see what's currently in the package split, look at
> >src/release/scripts/print-cdrom-packages.sh (for whatever branch
> >interests you).  Note that in addition to the packages listed there, we
> >also need to put all of their dependencies on disc#1 as well.  These
> >dependencies likely account for a lot of the "small packages and
> >ones that are not popular seem to make in on the first CD".
> >
> 
> Looking at the script, it would appear that the current method used is
> simply a combination of the two different ideas. I guess now I should be
> saying, "Please add Mozilla and Apache to the script."

We've talked about adding mozilla.  That will probably happen 
(actually, it was just added to HEAD's package split, and will probably 
get MFC-ed to RELENG_5_0).  Haven't seen any discussion of apache, not 
sure why it's not there.

I'm not real keen on making lots of changes to the package split at this
point (if you look at where we are in the release schedule, we're *real*
close to releasing).  Every unnecessary change we make carries with it a
certain risk that could delay the release.

Hoping to forestall a flood of email to re@ saying "Please add my
favorite package!", let me say:  The time to advocate changes is
*between* releases, not when you've just seen the last RC snapshot
and want the RE team to make some change in the few days before rolling 
the final product.  We're more likely to give some actual thought to 
changes proposed in the early stages of the process, as opposed to near 
the end when it seems like we're always fighting various fires that 
blaze up.

> >(FYI, the 5.0-RC3 package set occupies 339MB of a 560MB ISO image.)
> 
> If the ISO is currently 560MB, then we have 90MB to spare right?

Yeah, but:  1) We need to leave some space for vendors to add other
stuff they might want to put on the disc.  2) Some of the packages I've
seen discussed would eat up a lot of that (I have an OpenOffice package
sitting on my workstation that weighs in at 66MB, not counting any 
dependencies it may have).

FYI, my preferred window manager isn't on disc#1, nor are my preferred
MUA or Web browser.  But I think that disc#1 has a package set that's
useful to most people.

Cheers,

Bruce.





msg50299/pgp0.pgp
Description: PGP signature

Re: RELENG_5 branch ?

[Bruce A. Mah]

If memory serves me right, Joao Pedras wrote:

> Will there be a RELENG_5 where we would get 5.0-STABLE ? Pretty much in the s
> ame
> way it has been up until now...

Yes, but not right away.  Please see the early adopter's guide for more 
on this point (it's EARLY.HTM in the top-level directory of a binary 
snapshot, next to the release notes and other release documents).  If 
you can't find it, try here:

http://people.freebsd.org/~bmah/relnotes/5.0-RELEASE/early-adopter.html

> Is this code currently tagged with RELENG_5_0 ?

RELENG_5_0 is the release branch for 5.0-RELEASE.  This branch has
existed for about a month, and we have used it to do the release
engineering activities for the (still-in-progress) 5.0-RELEASE.  This is
*not* the branch for 5-STABLE, which has not been created yet.

Bruce.





msg50402/pgp0.pgp
Description: PGP signature

Re: adduser(8) in 5.0-R

[Bruce A. Mah]

If memory serves me right, Mike Makonnen wrote:

> I have cc'ed bmah, because I think it should be in the errata.

Done.  Thanks!

Bruce.





msg50715/pgp0.pgp
Description: PGP signature

Re: HEADS UP: /bin and /sbin are now dynamically linked

[Bruce A. Mah]

If memory serves me right, Bill Vermillion wrote:

> I don't think saving that little space on the / partition is as
> important as having everthing in sbin being able to stand alone no
> matter what is corrupted.

man 8 rescue

Bruce.




pgp0.pgp
Description: PGP signature

Re: 5.1-RELEASE TODO

[Bruce A. Mah]

If memory serves me right, Scott Long wrote:

> It's been a matter of not having enough time, nothing more.  I *will*
> address this one way or another before the release.  I apologize for
> taking so long.

Scott, you're hardly the only person with the ability to test this
problem.  In fact, you're not even personally affected by this.  So
don't be too hard on yourself.

Luigi, thanks for coming up with a patch...can't remember if I said that
before.  I'm mystified as to why nobody's stepped forward to help you
test it.  

Bruce.




pgp0.pgp
Description: PGP signature

Re: RC1 packages

[Bruce A. Mah]

If memory serves me right, "Jesse D. Guardiani" wrote:

> If I go ahead and install 5.1-RC1 now from ISO CDROM,
> will I have access to packages that are newer than the
> ones that come with FreeBSD 5.0-RELEASE? Or will they
> be the same packages as 5.0-RELEASE? Or will I not have
> access to packages at all? (That was always the case
> when I would CVSUP and buildworld on our servers)

You probably want to be installing 5.1-RELEASE.  5.1-RC was a release 
candidate, and had a few bugs that were fixed in 5.1-RELEASE.

> I ask because I need at LEAST XFree86 4.2.x for my laptop
> display to work properly with my ATI Radeon Mobility LY
> on my IBM Thinkpad A30p. And the last time I checked, I
> think 5.0-RELEASE only offered XFree86 4.1.x. And I'm not
> fond of compiling my x server by hand.

The 5.1-RELEASE package set contains XFree86 4.3.0.

The 5.0-RELEASE package set contains XFree86 4.2.1.

This was mentioned in the release notes for both versions, although 
that was only because each version contained a more recent version of 
XFree86 than its predecessor.

Bruce.




pgp0.pgp
Description: PGP signature

Re: buildworld failure in libfetch

[Bruce A. Mah]

If memory serves me right, Michael Nottebrock wrote:
> David Wolfskill wrote:
> > Were you running with -j ?  'cause the error appears to be with libssl,
> > not libfetch.
> 
> Nope.

I've seen this too, starting with a pristine /usr/obj and no -j option.
I wonder if this has to do with the recent SSL support added to
libfetch?

Bruce.



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: CURRENT's termcap broken

[Bruce A. Mah]

If memory serves me right, Jens Schweikhardt wrote:

> # Do you have time to commit mention of it to UPDATING?  If so, please
> # draw Bruce Mah's attention to the delta so that he can steal your text
> # for use in the release notes.  If not, I'll get around to it eventually.
> # :-)
> 
> I just added a note to src/UPDATING. Bruce, are you listening
> for the release notes?
> 
> 20020827:
>Our /etc/termcap now has all the entries from the XFree86 xterm
>almost unchanged. This means xterm now supports color by default.
>If you used TERM=xterm-color in the past you now should use
>TERM=xterm. (xterm-color will lead to benign warnings).

I'm on it, thanks for the heads-up.

Are you thinking of merging this for 4.7?

Bruce.





msg42272/pgp0.pgp
Description: PGP signature

libmd bug on -CURRENT

[Bruce A. Mah]

I think I've found a bug in libmd on -CURRENT, in which attempting to 
compute the MD5 checksum (using MD5File(3)) of a zero-length file 
generates an error.  A trivial way to trigger this bug (which isn't 
present in 4-STABLE) is:

ref4:bmah% uname -a 
FreeBSD ref4.freebsd.org 4.7-PRERELEASE FreeBSD 4.7-PRERELEASE #8: Mon Sep  2 03:20:42 
PDT 2002 [EMAIL PROTECTED]:/usr/src/sys/compile/REF4  i386
ref4:bmah% ls -ls foo
0 -rw-r--r--  1 bmah  bmah  0 Sep  6 08:54 foo
ref4:bmah% md5 foo
MD5 (foo) = d41d8cd98f00b204e9800998ecf8427e

ref5:bmah% uname -a
FreeBSD ref5.freebsd.org 5.0-CURRENT FreeBSD 5.0-CURRENT #11: Mon Sep  2 03:30:53 PDT 
2002 [EMAIL PROTECTED]:/usr/src/sys/i386/compile/REF5  i386
ref5:bmah% ls -ls foo
0 -rw-r--r--  1 bmah  bmah  0 Sep  6 08:54 foo
ref5:bmah% md5 foo
md5: foo: Undefined error: 0

This bug seems to have been introduced in rev. 1.14 of src/lib/libmd/
mdXhl.c; the patch below (which makes sure a variable gets initialized 
before first use, even in the case of a 0-length file) seems to fix it.

Comments?

Bruce.

PS.  I found this because at some point during a release build, mtree(8)
tries to compute the MD5 checksum of a zero-length file, namely 
/etc/dumpdates.

Index: mdXhl.c
===
RCS file: /usr/local/cvsroot/src/lib/libmd/mdXhl.c,v
retrieving revision 1.16
diff -u -r1.16 mdXhl.c
--- mdXhl.c 25 Mar 2002 13:50:40 -  1.16
+++ mdXhl.c 6 Sep 2002 16:02:52 -
@@ -66,6 +66,7 @@
len = stbuf.st_size - ofs;
 if (lseek(f, ofs, SEEK_SET) < 0) return 0;
 n = len;
+i = 0;
 while (n > 0) {
if (n > sizeof(buffer))
i = read(f, buffer, sizeof(buffer));





msg42674/pgp0.pgp
Description: PGP signature

Re: libmd bug on -CURRENT

[Bruce A. Mah]

If memory serves me right, Poul-Henning Kamp wrote:

> Good catch.
> 
> I'm surprised the compiler doesn't whine.

Thanks, and "me too".

Bruce.

PS.  Actually I'm surprised that nobody caught the problem in the past 
five months...this bug prevented release builds from 5-CURRENT hosts. 
Maybe I'm the only person crazy enough to try this.  :-)





msg42694/pgp0.pgp
Description: PGP signature

Re: libmd bug on -CURRENT

[Bruce A. Mah]

If memory serves me right, Bruce Evans wrote:
> On Fri, 6 Sep 2002, Bruce A. Mah wrote:
> 
> > If memory serves me right, Poul-Henning Kamp wrote:
> >
> > > Good catch.
> > >
> > > I'm surprised the compiler doesn't whine.
> >
> > Thanks, and "me too".
> 
> Warnings are mostly turned off for not unimportant places like libraries
> since these places are too poorly written to compile without warnings.

Apparently.

> > PS.  Actually I'm surprised that nobody caught the problem in the past
> > five months...this bug prevented release builds from 5-CURRENT hosts.
> > Maybe I'm the only person crazy enough to try this.  :-)
> 
> This bug was caught in PR 42384.  The fix in the PR is not so good.

I suppose I didn't look hard enough when I scanned through the 
PR database.  I'll deal with the PR.

> libmd is also broken for some cases involving pipes.  IIRC, this is
> caused by the bogus st_size checks in the same function.  st_size is
> only valid for regular files.

It's puzzling that the call to lseek(2) doesn't always return an error
in these cases as well (as the manpage seems to imply).  Yet, one can do
md5(1) on a pipe:

tomcat:bmah% cat /etc/motd | md5
9caae6eae6f9c2dfea77d6a5fae2e93c
tomcat:bmah% md5 /etc/motd
MD5 (/etc/motd) = 9caae6eae6f9c2dfea77d6a5fae2e93c

> The loop in the function fails to to terminate if read() returns 0,
> which can probably happen if the file shrinks underneath us.

Maybe add a check after the read(2), so that if it returns zero, we set
n = 0?  It's not clear to me what result should be returned in the case
of trying to compute a checksum on a file that shrinks in the middle of
the computation.

Thanks,

Bruce.





msg42775/pgp0.pgp
Description: PGP signature

Release-building saga continues

[Bruce A. Mah]

I successfully built an i386 miniinst.iso image, using a repository
updated around mid-day Saturday (California time).  When I burned and
booted this image, I landed in sysinstall (yay!) with a dialog box
complaining "Couldn't create directory /tmp: Read-only file system"
(d'oh!).

There's a number of other operations that result in the same dialog, 
including all of the documentation items.  It's not possible to mount a 
fixit CDROM to investigate further because sysinstall isn't able to 
create the mount points.

It kind of looks like the mfsroot filesystem image got mounted 
read-only.  Is this just me?

Thanks,

Bruce.

PS.  FYI:  drivers.flp has 469KB left, mfsroot.flp has 87KB left (this
includes the compressed release doc files), and kern.flp has 19KB left.
This predates some of the pccardd-related cleanup.





msg44952/pgp0.pgp
Description: PGP signature

Re: 5.0-RUSH: -current install testers wanted!

[Bruce A. Mah]

If memory serves me right, The Anarcat wrote:
> On Tue Oct 22, 2002 at 08:33:53AM +0200, Poul-Henning Kamp wrote:
> [...]
> > 
> > And I want them to do it RSN: 5.0-R is only 9 days away.
> [...]
> 
> 9 days??? There won't be another DP?

Um, not exactly.  The current release date isn't until 20 November
(subject to change, but that's the official word until RE says
otherwise).  That being said, the more testing we can get with 
sysinstall and fresh installations, the better.

Urk.  We really need to update some of the dates on the 5.0 release 
schedule.  I'll push this during the RE telecon this week, if we don't 
get to it sooner.

Bruce.

PS.  We're still trying to do DP2.  Any other snapshots we release 
after DP2 are more likely to be release-candidate-style snapshots.





msg45064/pgp0.pgp
Description: PGP signature

Re: 5.0-RUSH: -current install testers wanted!

[Bruce A. Mah]

If memory serves me right, Steve Kargl wrote:

> I've noticed many commits on cvs-all include an "Approved by: re"
> line, but I haven't seen an official code slush/freeze announcement.

Feature freeze started 16 October.  New feature commits (as opposed to 
bugfix or doc commits) should have RE approval.

> Is RE going to request a code freeze around 10 Nov.?

Clearly we're not adhering to the last published code-freeze date;
according to that, we would have been in code-freeze for two days
already.  The more src-oriented members of RE are probably in a better
position than I am to say when code-freeze is going to start.

Bruce.





msg45070/pgp0.pgp
Description: PGP signature

Re: UPDATING entry needed (Re: Building KDE3)

[Bruce A. Mah]

If memory serves me right, Kris Kennaway wrote:

> On Tue, Oct 22, 2002 at 10:28:42PM -0700, Kris Kennaway wrote:
> 
> > > It's already in UPDATING with the rm -rf /usr/include/g++ line in the
> > > steps for going from 4 to -current.
> >=20
> > Oops, I missed this when I looked for it.  Thanks.
> 
> Actually, I think this is not sufficient..there will be other stale
> includes left around which may cause problems for compiling other
> things.
> 
> I normally do something like:
> 
> find /usr/include -ctime +1 -type f -delete
> 
> To clean out stale includes after a buildworld.  Perhaps something
> like this should be added to the end of the directions.

What about "rm -rf /usr/include" right before the installworld?  (In
other words, where "rm -rf /usr/include/g++" is now.)

(I don't actually do this, for me it's more like "cd /usr && mv include 
include.old".)

Bruce.





msg45115/pgp0.pgp
Description: PGP signature

Re: Installing from CD and MAKEDEV

[Bruce A. Mah]

If memory serves me right, Jun Kuriyama wrote:

> I've created install CD with "make iso.1" (with sources few hours
> before).
> 
> I'm trying to install fresh current box with this CD.  But I got
> "MAKEDEV returned non-zero status" dialog after extracting dists.
> 
> It seems "cd /dev; sh MAKEDEV all" is failed at devfs environment.
> 
> Is this my local problem?

I've seen this too...with a release created from sources about twelve
hours old.  I'm not in a position to troubleshoot right now...it's past
my bedtime here.  :-)

Bruce.





msg45173/pgp0.pgp
Description: PGP signature

Re: Installing from CD and MAKEDEV

[Bruce A. Mah]

If memory serves me right, Poul-Henning Kamp wrote:
> In message <[EMAIL PROTECTED]>, Jun Kuriyama writes:
> >At Thu, 24 Oct 2002 12:10:53 + (UTC),
> >kuriyama wrote:
> >> I've created install CD with "make iso.1" (with sources few hours
> >> before).
> >> 
> >> I'm trying to install fresh current box with this CD.  But I got
> >> "MAKEDEV returned non-zero status" dialog after extracting dists.
> >> 
> >> It seems "cd /dev; sh MAKEDEV all" is failed at devfs environment.
> >
> >I found it.
> >
> >Phk changes in 1.297 of src/etc/Makefile not to install MAKEDEV by
> >default.  Options may be:
> 
> This should be fixed now I hope.

It works here.  I just did a successful i386 install from CDROM.

Thanks!

Bruce.






msg45351/pgp0.pgp
Description: PGP signature

Re: 5.0-20021027-CURRENT.iso cdrom will not mount

[Bruce A. Mah]

If memory serves me right, John wrote:

>How many other people are testing the 5.0 sysinstall booted
> from a cd and running a local (cd/dvd) install? Try booting and
> installing from the iso at usw2.freebsd.org and see if it works
> for you.

I'm able to boot and install CURRENT snapshot releases I've generated
locally (last was around 20021025).  (My machine is a Sabre 1815, ICH2
ATA100 controller on-board, CDROM probes as "".)

I know that sam and phk were able to do test installs as well.

How are you making your ISO images?  I'm just doing release builds with
MAKE_ISOS=YES.  I don't *think* that GEOM should have any effect on
creating the ISO image.

I'll pull down that ISO and try it out, but it might take a little 
while...

Bruce.





msg45491/pgp0.pgp
Description: PGP signature

Re: HEADS UP: you need to install a new kernel before an installworld.

[Bruce A. Mah]

If memory serves me right, Doug Barton wrote:

> This should go on the "Comprehensive guide to updating from source to 5.0"
> that I'm sure our trusty release engineers are producing?

Some of this is described in the early adopter's guide (still a work in
progress) that I committed to the release documentation set a few days
ago.

It refers to src/UPDATING for the source-upgrade-from-4.X steps, but
several people have suggested bringing this material into the document. 
I'm open to that, but first:  1) I'd like the content to settle a bit 
first, 2) I need to find time to do this.  #2 is less of an issue if 
someone else wants to help out.

Cheers,

Bruce.






msg45567/pgp0.pgp
Description: PGP signature

Re: 5.0-20021027-CURRENT.iso cdrom will not mount

[Bruce A. Mah]

I wrote:

> If memory serves me right, John wrote:
> 
> >How many other people are testing the 5.0 sysinstall booted
> > from a cd and running a local (cd/dvd) install? Try booting and
> > installing from the iso at usw2.freebsd.org and see if it works
> > for you.
> 
> I'm able to boot and install CURRENT snapshot releases I've generated
> locally (last was around 20021025).  (My machine is a Sabre 1815, ICH2
> ATA100 controller on-board, CDROM probes as "".)
> 
> I know that sam and phk were able to do test installs as well.
> 
> How are you making your ISO images?  I'm just doing release builds with
> MAKE_ISOS=YES.  I don't *think* that GEOM should have any effect on
> creating the ISO image.
> 
> I'll pull down that ISO and try it out, but it might take a little 
> while...

Hi John--

I finally got around to testing your snapshot...sorry for the delay.  
It stops about where you indicated in your original message (when 
trying to mount the CD, "Error mounting /dev/acd0c on /dist: Operation 
not supported by device (19)."

You didn't answer my question, which was:  How are you making your ISO
images?  I suspect that you're mastering the ISO images in some way 
*other* than the normal MAKE_ISOS=YES method.  isoinfo(1) output on 
your disk:

tomcat:cdrom% isoinfo -d -i /dev/acd0c
CD-ROM is in ISO 9660 format
System id: FreeBSD
Volume id: FreeBSD 5.0-20021027-CURRENT
Volume set id: 
Publisher id: The FreeBSD.Org snapshot system
Data preparer id: rtp1.FreeBSD.Org
Application id: FreeBSD Snap 5.0-20021027-CURRENT
Copyright File id: 
Abstract File id: 
Bibliographic File id: 
Volume set size is: 1
Volume set seqence number is: 1
Logical block size is: 2048
Volume size is: 97840
NO Joliet present
Rock Ridge signatures version 1 found

isoinfo(1) output from my last snapshot (25 October):

CD-ROM is in ISO 9660 format
System id: FreeBSD
Volume id: fbsd_miniinst
Volume set id: 
Publisher id: 
Data preparer id: 
Application id: MKISOFS ISO 9660/HFS FILESYSTEM BUILDER & CDRECORD CD-R/DVD CREATOR 
(C) 1993 E.YOUNGDALE (C) 1997 J.PEARSON/J.SCHILLING
Copyright File id: 
Abstract File id: 
Bibliographic File id: 
Volume set size is: 1
Volume set seqence number is: 1
Logical block size is: 2048
Volume size is: 132576
Joliet with UCS level 3 found
Rock Ridge signatures version 1 found

Maybe if you build the ISOs using MAKE_ISOS=YES set in your "make
release", you might have better results.  At least if there *is* a
problem, it'd narrow down the scope a little bit.

Good luck!

Bruce.





msg45608/pgp0.pgp
Description: PGP signature

Re: DP2: nfsiod

[Bruce A. Mah]

If memory serves me right, Robert Watson wrote:

> Note that the rpc.lockd support is still experimental in 5.0 for
> client-side locking, and as such, might not be good to enable by default.
> I notice that  in the original message for this thread, there's reference
> to release documentation indicating that client side locking isn't
> implemented: this is actually not the case.  We do implement it now.

I freely declare my ignorance about NFS locking.  :-)

If someone can fix up this part of the release notes to match reality,
I'd be grateful.

Thanks,

Bruce.






msg47446/pgp0.pgp
Description: PGP signature

Re: Patch for critical_enter()/critical_exit() & interrupt assem

[Bruce A. Mah]

If memory serves me right, "Bruce A. Mah" wrote:

[snip]

Disregard.  I hit the wrong button in my MUA.  Sorry for the spammage.

Bruce.




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Patch for critical_enter()/critical_exit() & interrupt assem

[Bruce A. Mah]

If memory serves me right, "Justin T. Gibbs" wrote:
> >
> >:
> >:You came to the conclusion that only *your decision* on what was
> >:an appropriate proceedure was the one that mattered.  That's not
> >:the way this project works.  You can't act unilaterally.  When people
> >:ask you to hold off (and they even asked politely!) so discussion
> >:can take place, that is not the time to commit.
> >
> >I did no such thing.
> 
> Let me quote you from below:
> 
> >So, you see, I didn't "just commit it out of nowhere".  I waited
> >what I believed to be a reasonable period of time.
> 
> So your oppinion on what was "a reasonable period of time" was the
> only one that mattered. Q.E.D.
> 
> >I came to the conclusion because not a 
> >single goddamn person bothered to read the patch and instead
> >the only argument I got was "wait for John" and John's only 
> >argument is "I don't like the idea of optimizing this routine
> >right now" as if he would be the only one responsible for
> >dealing with the consequences.
> 
> Actually, John's reaction to the patch is a secondary issue.  He
wasn't even able to read the lists when this thing blew up.  He could
> have fallen over backward with love for your changes and you still
> would have strewn cuss words all over our lists.
> 
> [More talk about the irrelevant contents of the patch and
>  "40 hours of work being thrown away" paranoia.]
> 
> >I am angry because you and a number of others are not willing to take
> >the work at face value and instead insist on making ridiculous extremist
> >assumption into it and then using that opinion to justify not allowing
> >the patch to go in.
> 
> How many times do I have to say this?  The patch is not the issue.  Most
> likely it will be incorperated into the tree shortly.  
> 
> I'm sorry Matt, but even if these changes are gold lined, it doesn't
> change the fact that you acted unilaterally in a manner that is not
> conducive to team work.  That it.  That's really it.
> 
> Now do you want me to go chew out John too.  Okay.  John isn't being
> super professional either.  The fact that you started this doesn't change
> that.  You both have done things that you shouldn't have.  Now instead
> of trying to convince us that you are completely without reproach, why
> not move forward in some constructive manner?  Aren't you out of breath
> yet?  Aren't your fingers tired of typing the same old worn out argument,
> "My code excuses my behavior!" again and again?
> 
> >:One week of discussion will not prevent the code from being tested.
> >
> >Coming on THREE weeks now.  Three weeks of my time wasted arguing
> >with people who don't even bother to take the time to understand what
> >I am trying to accomplish...
> 
> This is your choice Matt.  You may not realize it, but you are in control
> of how long this wears on.
> 
> >Gee, lets see... why don't YOU ask JOHN how long he intends to wait
> >before he allows this sort of optimization to be made?  Eh?  Please.
> 
> Hey John.  Can you comment on whatever issues you have with the content
> of these changes?  If the API is not compatible with what you are doing,
> please explain why and how those conflicts might be resolved.  Assuming
> that these issues can be addressed and the optimization can be disabled
> via a configuration option, what further reasons are there to not allow
> this change to go into the tree?
> 
> >:>That is not how I work and I strongly oppose that kind of methodology.
> >:
> >:I think you've made that clear already.  The question is whether you
> >:are willing to compromise so you can be part of a team or not.  That
> >:means, for all of us, that we will not necessarily be able to work in
> >:the way we would personally want, all of the time.  That's what happens
> >:in a group environment.  That's life.
> >
> >This is not about being part of a team.
> 
> I've played "hide and seek" with people that feel this way.
> "1, 2, 3 Seems like a reasonable amount of time to me...  Ha Ha found
> you!"
> 
> >You don't have to be forced into using someone else's methodology to
> >be part of a team.
> 
> No, you have to accept the team's methodology in areas that affect the
> team.  As we say in the States, "your personal liberties end where they
> infrindge on mine."  This is no different.  The CVS repository is not
> yours to commit to any way you like.  The team has a methodology for
> that and as soon as that methodology is broken, we fall into situations
> just like this one.
> 
> >This IS about team work, but you are barking up the wrong tree if you
> >think I'm the one who's not being a team player here.
> 
> I know you believe this.  Just as you believed you were reasonable in
> committing that code when you were asked not to.  Just as you continue
> to insist that the content of your patch is the issue here.  I can't
> convince you otherwise, but perhaps I can convince you to

Re: CVS Issues with branch.. Was: Re: HEADS UP: Be nice to -CURRENT ( "1 week Feature Slush" )

[Bruce A. Mah]

[Trimming Cc list a little bit]

If memory serves me right, Peter Wemm wrote:

> Actually, with my CVS hat on, I have a *huge* problem with this.

In the future, if you see such huge problems come up, a little more
advance notice might be nice.  :-(

> We have a large number of "temporary" repo copies in place that are to
> be deleted (ie: rm -rf) soon.  This was with the plan that there would
> be *NO* persistant branches and that it would be rm'ed long before the
> RELENG_5 branch began.

Is there more to this plan?  This is news to me and I would like to get 
up to speed.

> I had a quick look and I immediately found 55MB of duplicated repo files.
> That's over 5% of the repo right now.
> 
> I want to know what expectations people have by calling this a
> "RELENG_5_XX" branch..  Given that this stuff is going to be rm'ed within a
> month, that will break RELENG_5_DP1 when that happens.  People will no
> longer be able to cvsup or check out -r RELENG_5_DP1 and have it build.
> Specifically, gcc and gdb will not build.
> 
> If this is going to be a "static" release (calling it RELENG_5_anything is
> a mistake IMHO) then this isn't a big deal.  But if people are expecting
> it to have ongoing secirity fixes etc like we do with RELENG_4_5 etc then
> we have a problem, because it cannot last very long at all.

Differences of opinion on naming aside...the branch isn't supposed to
last long at all.  The point is to provide a slightly polished snapshot
to the wider developer community.  We can't do the QA/releng work on
HEAD without calling for a code freeze (which we early on decided that
we would *not* do).  Since it's not a formal release, we won't be doing 
security fixes, etc.

I can't imagine why anyone would expect to cvsup this thing at some
point in the distant future, especially after 5.0-DP2 and 5.0-RELEASE.
Just thinking off the top of my head, having it break soon after 5.0-DP1
might not be fatal, as long as we have the CDROM and FTP areas still 
intact.

Did you have a definite date for the rm-ing in mind?

Thanks,

Bruce.



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: cvs commit: src Makefile Makefile.inc1 src/etc Makefile src/gnu/usr.bin/perl/library Makefile.inc src/release Makefile src/release/scripts catpages-make.sh doFS.sh manpages-make.sh src/secure/usr.bin/ssh Makefile src/secure/usr.sbin/sshd Makefile ...

[Bruce A. Mah]

If memory serves me right, Ruslan Ermilov wrote:

> It's important to note that you no
> longer need to have a today's world to build a today's release.
> I.e., if you built world a month ago, and didn't touch /usr/src
> since, and /usr/obj has "buildworld" output for this /usr/src,
> and you have booted with this world, it should be okay to start
> building today's release.

I'm not sure I understand this comment.  Why was there a requirement to
have today's /usr/src and /usr/obj before starting a release?

(Most of my release-building experience is with 4-STABLE, but so far it
seems like as long as there haven't been any major API changes or other
shufflings between what's on the machine and the release being built, it
Just Worked (TM).)

Thanks,

Bruce.



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

IPv6 header breakage on -CURRENT?

[Bruce A. Mah]

Hi folks--

It's been pointed out to me that a program I wrote (net/pchar in ports) 
can't compile on -CURRENT.  After a little poking around, I've narrowed 
the problem down to the following test case:

tomcat:bmah% cat foo.cc
#include 
#include 
#include 
#include 

#include 
#include 

int main()
{
}
tomcat:bmah% c++ foo.cc
In file included from foo.cc:7:
/usr/include/netinet/icmp6.h:168: ANSI C++ forbids data member `mld6_hdr' with same 
name as enclosing class
tomcat:bmah% cp foo.cc foo.c
tomcat:bmah% cc foo.c

This shows up on 25 April -CURRENT, but not on 20 March -CURRENT or,
apparently, not what the -CURRENT ports cluster is running (5.0-DP1?).

So...is there some reason I shouldn't be able to use 
from a C++ program, or is something broken?

Thanks!

Bruce.



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: pkg_version in C [was: Re: Perl scripts that need rewriting - Progress!]

[Bruce A. Mah]

If memory serves me right, Jeremy Lea wrote:

> On Thu, May 09, 2002 at 08:33:22PM +0100, Mark Murray wrote:
> > /usr/sbin/pkg_version   Jeremy Lea <[EMAIL PROTECTED]> - re
> 
> OK, the first revision is attached.  It appears to work for me...  It
> needs some spit and polish, and probably a few more people to test.
> 
> I've not implemented the -d flag since it sort of became unneeded, and
> it's not really the way things are done in the rest of pkg_*.  I've also
> not implemented -c.  There were enough warnings that it wasn't really
> useful, and portupgrade does a much better job... 

Hi Jeremy--

This looks very nice.  I'll let Maxim and other ports gurus comment on 
the coding, and content myself with some high-level comments:

1.  The version comparisons passed all of the regression tests that knu
and I made for the original pkg_version (test-pkg_version.sh).  This
gives me a nice warm fuzzy feeling about that part of the code.

2.  "-c" is still in the usage message, even though it's not in the 
code anymore (yay!).  Might want to take this out.

3.  The AUTHORS section in the manpage isn't marked up quite right.  I'd
recommend something like this:

-
.Sh AUTHORS
The
.Nm
utility was written by
.An Jeremy D. Lea Aq [EMAIL PROTECTED] ,
partially based on a Perl script written by
.An Bruce A. Mah Aq [EMAIL PROTECTED] .
-

4.  You commented that you didn't like the way we did "-s" before.  If
you think it'd be better as (say) a regex or a globbing expression, I
don't believe there'd be much problem with going that route.  knu 
used globbing when he wrote portversion, if you want some precedent.

Good job!

Bruce.



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Call for Review: allow sysinstall to tweak tri-value sendmail_enable

[Bruce A. Mah]

If memory serves me right, Makoto Matsushita wrote:

> Following patch creates submenu to change the sendmail_enable value.
> However, I don't know who want to set this variable to 'NO'.  If
> selecting 'YES' and 'NONE' is enough, I'll try to make another patch.
> 
> Any comments?  I want to push this feature to 4.6-RELEASE...

Comments on the text only (i.e. I haven't tested the new menus)...

Bruce.

> Index: menus.c
> ===
> RCS file: /home/ncvs/src/usr.sbin/sysinstall/menus.c,v
> retrieving revision 1.343
> diff -u -r1.343 menus.c
> --- menus.c   20 May 2002 17:08:00 -  1.343
> +++ menus.c   31 May 2002 17:49:18 -
> @@ -1372,11 +1372,31 @@
>{ " Rwhod","This machine wants to run the rwho daemon",
>   dmenuVarCheck,  dmenuToggleVariable, NULL, "rwhod_enable=YES" },
>{ " Sendmail", "This machine wants to run the sendmail daemon",
> - dmenuVarCheck,  dmenuToggleVariable, NULL, "sendmail_enable=YES" },
> + NULL,   dmenuSubmenu, NULL, &MenuSendmail },
>{ " Sshd", "This machine wants to run the ssh daemon",
>   dmenuVarCheck,  dmenuToggleVariable, NULL, "sshd_enable=YES" },
>{ " TCP Extensions", "Allow RFC1323 and RFC1644 TCP extensions?",
>   dmenuVarCheck,  dmenuToggleVariable, NULL, "tcp_extensions=YES" },
> +  { NULL } },
> +};
> +
> +DMenu MenuSendmail = {
> +DMENU_NORMAL_TYPE | DMENU_SELECTION_RETURNS,
> +"Sendmail Invocation Selection",
> +"There are three options for invocating sendmail at startup.\n"

s/invocating/invoking/

> +"Please select Yes if you want to use sendmail as your mail transfer\n"
> +"agent.  Selecting No disables sendmail to open network socket for\n"

s/sendmail to open/sendmail's/

> +"incoming email, but still runs at startup.  None disables sendmail\n"

s/still runs at startup/still enables sendmail for outbound mail/

You will probably need to word-wrap differently after this change.

> +"completely at startup.",
> +NULL,
> +NULL,
> +{
> +  { " Yes",  "Start sendmail",
> + dmenuVarCheck, dmenuSetVariable, NULL, "sendmail_enable=YES" },
> +  { " No",   "Start sendmail, but don't listen from network"
> ,
> + dmenuVarCheck, dmenuSetVariable, NULL, "sendmail_enable=NO" },
> +  { " None", "Don't start any sendmail processes",
> + dmenuVarCheck, dmenuSetVariable, NULL, "sendmail_enable=NONE" },
>{ NULL } },
>  };
>  
> Index: sysinstall.h
> ===
> RCS file: /home/ncvs/src/usr.sbin/sysinstall/sysinstall.h,v
> retrieving revision 1.227
> diff -u -r1.227 sysinstall.h
> --- sysinstall.h  31 May 2002 13:38:17 -  1.227
> +++ sysinstall.h  31 May 2002 17:49:19 -
> @@ -407,6 +407,7 @@
>  extern DMenu MenuSysconsScrnmap; /* System console screenmap con
> figuration menu   */
>  extern DMenuMenuSysconsTtys;/* System console terminal t
> ype menu*/
>  extern DMenu MenuNetworking; /* Network configuration menu
>   */
> +extern DMenu MenuSendmail;   /* Sendmail configuration menu
>   */
>  extern DMenu MenuInstallCustom;  /* Custom Installation menu
>   */
>  extern DMenu MenuDistributions;  /* Distribution menu
>   */
>  extern DMenu MenuDiskDevices;/* Disk type devices
>   */
> 
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-current" in the body of the message
> 



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message