Re: 11.0-RELEASE Status Update

[Bruce A. Mah]

If memory serves me right, Cassiano Peixoto wrote:
> Looks we have some import issues to be fixed before 11-RELEASE. I have
> another one that nobody cares:
> 
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=213257
> and
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=212413
> 
> It's affecting ALTQ users on both FreeBSD 11 and 10.3, the system just
> crash.
> 
> IMHO would be better to release a stable product instead of keep the
> schedule.

There's always "just one more bug".  If the FreeBSD Project waited until
the code was bug-free there'd be no releases at all.

It's the Release Engineering team's job to make the call on which bugs
are worth holding up a release for and which aren't, when workarounds
are acceptable and when they need to try to pursuade a developer to
diagnose and implement a real fix, etc.  They need to use their
judgement about a number of factors such as severity, number of users
impacted, availability of developers, and so on.  The schedule is also a
factor, but it's never just for the sake of adhering to the schedule.

Bruce
(Ex-RE team member)

> On Fri, Oct 7, 2016 at 8:32 AM, Alexander Shitov  wrote:
> 
>> Op 06/10/2016 om 22:18 schreef Glen Barber:
>>> As many of you are aware, 11.0-RELEASE needed to be rebuilt to address
>>> several issues that were discovered after the release was built. Extra
>>> caution is being taken in testing the rebuilt releases, so at present,
>>> the final release announcement is planned for Monday, October 10.
>>>
>>> Thank you for your patience in waiting for 11.0-RELEASE.
>>>
>>> Glen > On behalf of: re@ >
>>
>> Is fix for Hyper-V bug "virtual disk being detached from the bus"
>> (https://reviews.freebsd.org/D7693)  included in final build?
>> PR https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=212721
>>
>> It will be big disappointment if 11.0-RELEASE will became incompatible
>> with Hyper-V.
>>
>> ---
>> Best Regards,
>> Alexander
>> ___
>> freebsd-stable@freebsd.org mailing list
>> https://lists.freebsd.org/mailman/listinfo/freebsd-stable
>> To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
>>
> ___
> freebsd-stable@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
> 




signature.asc
Description: OpenPGP digital signature

Re: binary updates for 10.3 failing

[Bruce A. Mah]

If memory serves me right, Kevin Oberman wrote:
> On Thu, May 5, 2016 at 9:07 AM, Andreas Ott  wrote:
> 
>> Hi,
>>
>> I'm not sure if the stable list is the correct place to report this,
>> but currently binary updates are not working. I see posts on the forum
>> but no solutions are being offered (other than updates from source,
>> which are difficult on production systems missing the src component).
>> Something broke recently, it worked to update from RELEASE to -p1.

[snip]

> I am seeing the exact same issue. I really, really would like to get the
> SSL fixes onto my web server, but I get the "No updates needed to update
> system to 10.3-RELEASE-p0." message.
> 
> # freebsd-version -u -k
> 10.3-RELEASE
> 10.3-RELEASE-p1

Works now.  I forgot exactly what was broken and/or fixed but it's on
the security@ list.  After a freebsd-update fetch/install/reboot cycle...

wwwin:bmah% freebsd-version -u -k
10.3-RELEASE-p2
10.3-RELEASE-p2

Bruce.

PS.  Hi Andreas!  Hi Kevin!





signature.asc
Description: OpenPGP digital signature

Re: Solved?: Re: Upgrade of RELENG_8 ZFS boot pool leads to unbootable system

[Bruce A. Mah]

If memory serves me right, Paul Mather wrote:

 That's weird.  I have the same basic /boot/loader.conf entries
 (except for a speed of 115200) and even just putting -Dh into
 /boot.config leads to the same unbootable system behaviour. :-(

 Maybe something broke recently in the RELENG_8 boot loader?  Like I
 said originally, that /boot.config entry had been working for me
 without problems for a long time.

Hi Paul--

I recently ran into this as well.  I didn't do any setting of the
console bitrate, just -Dh in /boot.config, and it caused a server I
was upgrading to lock up just as you described.  I had to learn about
mounting ZFS filesystems from the Fixit environment in a hurry.  My
workaround was to get rid of /boot.config, which obviously doesn't
restore the original functionality.

The system in question was (is) running 8.3-RELEASE.

Bruce.




signature.asc
Description: OpenPGP digital signature

Re: smartctl question

[Bruce A. Mah]

If memory serves me right, Kevin Oberman wrote:

 By the way, I believe that some stats do go up and down, but not
 counters. Like in snmp, counters are never supposed to be reset or
 resettable.

Examples of values that go up and down (actually the only examples I can
think of) are the drive temperature and airflow temperature.  But AFAIK
you're right about the counter values.

Bruce.




signature.asc
Description: OpenPGP digital signature

Re: fxp entering promiscuous mode causing link to bounce

[Bruce A. Mah]

If memory serves me right, Mike Tancsa wrote:
 I dont recall seeing this on RELENG_7, but I dont have a box to test with 
 anymore confirm. On one box I upgraded to RELENG_8 I just noticed the nic 
 will bounce if I enable tcpdump on it.  Sure enough, trying on a different 
 RELENG_8 box with an fxp nic shows the same result.

JFYI I see this on an ancient i386 system I have, running 9.0-RELEASE:

fxp0: Intel 82801BA/CAM (ICH2/3) Pro/100 Ethernet port 0xac00-0xac3f
mem 0xefdfe000-0xefdfefff irq 11 at device 8.0 on pci1

Same thing...going into or out of promiscuous mode makes the link bounce.

fxp0: link state changed to DOWN
fxp0: promiscuous mode enabled
fxp0: link state changed to UP
fxp0: link state changed to DOWN
fxp0: promiscuous mode disabled
fxp0: link state changed to UP

Bruce.




signature.asc
Description: OpenPGP digital signature

Re: Upcoming Releases Schedule...

[Bruce A. Mah]

If memory serves me right, Eugene Grosbein wrote:
 On Sun, Aug 24, 2008 at 01:45:08AM +0200, Svein Skogen wrote:
 
 In 25 words or less, what are the major changes in 7.0-7.1 and 6.3-6.4
  for us end users?
 
 In more words, but pretty interesting:
 
 http://people.freebsd.org/~bmah/relnotes/6-STABLE/relnotes-i386.html
 http://people.freebsd.org/~bmah/relnotes/7-STABLE/relnotes.html

These documents need a fair amount of work towards making them reflect
reality.  My FreeBSD-related activities have been severely
time-constrained for most of this year and I don't see the situation
getting much better before these releases ship.  :-(

For those people who are interested in *helping* with the release notes,
patches or inquiries to the doc@ list would probably be appropriate.

Cheers,

Bruce.




signature.asc
Description: OpenPGP digital signature

Re: panics on 6.3-RELEASE in IP stack

[Bruce A. Mah]

If memory serves me right, John Baldwin wrote:

Given how simple the patch is and that if fixes a known panic this might be 
worthy of an errata notice or errata candidate.  (At least a note in the 
errata pointing to the 1.85.2.10 commit if not an actual patch to 
RELENG_6_3.)


I added an item to the post-release errata for this.

Bruce.



signature.asc
Description: OpenPGP digital signature

Re: ipfwpcap in 6.3 ?

[Bruce A. Mah]

If memory serves me right, Kurt Jaeger wrote:


In

http://www.freebsd.org/releases/6.3R/relnotes-i386.html

ipfwpcap(8) is mentioned, but I can't find it after the upgrade ?


Argh.  My bad.  It got merged to RELENG_6 *just* after RELENG_6_3 was 
branched, by about a day or so.  Somehow I must have gotten confused and 
thought that it happened pre-branch (and thus had gotten included), thus 
it ended up in the release notes for 6.3 when it shouldn't have.  :-( 
I'll make a note in the post-release errata for this.


Very sorry for the confusion.  ipfwpcap(8) will appear in 6.4-RELEASE or 
in any 6-STABLE snapshot made after about 25 November 2007.


Bruce.





signature.asc
Description: OpenPGP digital signature

Re: 6.3-RC2 Available

[Bruce A. Mah]

If memory serves me right, Karl Triebes wrote:
 On Dec 31, 2007 4:59 AM, Ken Smith [EMAIL PROTECTED] wrote:
 Sorry for the delay with this phase of the 6.3 release.  A few glitches
 were found during testing of the 6.3-RC2 ISOs that included pre-built
 packages.

 The 6.3-RC2 builds for amd64 and i386 should now be available on the
 majority of the FreeBSD mirror sites.  I just finished loading the
 sparc64 build so that will take a little while to propagate to the
 mirrors.  This is the last planned RC for 6.3.  Unless a major
 show-stopper problem is found the release of 6.3 should happen in about
 two weeks.
 
 Is there a changes document that captures the delta between minor
 releases, and in this case between 6.2 and 6.3-RC2? I'm mostly
 interested in changes that happened under src/sys.

You mean like the release notes?

RELNOTES.{HTM,TXT} in the top-level of disk 1 for any release, or see here:

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

(The release notes get installed on www.freebsd.org just before the
release gets announced.)

Bruce.



signature.asc
Description: OpenPGP digital signature

Re: BIND 9.3.1 - How to get rid of AAAA querys?

[Bruce A. Mah]

If memory serves me right, Pete French wrote:
 since we are talking about IPv6, how do people genarlly find it on FreeBSD?

Two quasi-data points:

1.  I personally have been doing dual-stack on my FreeBSD machines for a
couple years, with a gif(4) tunnel to my ISP (my tunnel endpoint runs
6-STABLE, other home workstations are a mix of 6-STABLE and 7-CURRENT).
 FreeBSD 6.1-RELEASE and 6.2-RELEASE unfortunately shipped with some
problems that made IPv6 over gif(4) not work right out of the box but
those were fixed up in errata patches.  I haven't noticed any persistent
problems but I haven't been really looking for them either.

2.  Many of the FreeBSD.org machines (of particular note,
www.FreeBSD.org and part of ftp.FreeBSD.org) are now running dual-stack.
  As a result, we're more likely to fix problems (in functionality or
performance) in the IPv6 code, or at least to be aware of them.

Bruce.



signature.asc
Description: OpenPGP digital signature

Re: release cycle

[Bruce A. Mah]

If memory serves me right, LI Xin wrote:
 Hi, Erik,
 
 Erik Trulsson wrote:
 On Tue, May 29, 2007 at 11:45:15AM +0200, Volker wrote:
 [...]
 I know there's a release cycle for 7-CURRENT planned next June but
 IMHO it can be delayed for some weeks.

 What does the core and releng team think? It might do good.
 A quick release cycle for a release from -STABLE sounds like a bad idea.
 There have been enough new things that have gone into the 6-STABLE branch
 that a full release cycle seems warranted.
 
 I would say that just tagging -STABLE tree as RELEASE is a very bad
 idea, however, it would not be too bad if we take RELENG_6_2 as a
 codebase and add the following bugfixes:
 
  - zonelim fixes (very helpful for heavy loaded systems).
  - some socket locking fixes (settled for a long time).
  - driver updates, like RAID driver bugfixes.
 
 Therefore, from src/'s view, I think it would not be too bad to make a
 point release that merges some (well tested) bugfixes in, or at least,
 provide a patchset as an errata for 6.2-R.

We've done point releases in the past but only in cases where there were
severe problems and/or regressions with released versions.  Look at the
announcements and release notes for 4.6.2-RELEASE and
5.2.1-RELEASE...these were the two most recent instances where we did
this.  There's a reason for this...it's a lot of effort.

Folks should realize that making a new release (even a new point
release) is not just a matter of tagging the tree and typing make
release.  We (re@) need to figure out exactly what bugs are to be
fixed, get the changes merged and tested, build at least one release
candidate, get that tested, and finally build a set of RELEASE bits and
push them out.

And that's just the src/ part.  The original poster was mostly concerned
about the X.org upgrade, which as we all know lives in the ports/ tree.
 If we were to do a point release we'd basically require a complete
port freeze and package build run.  I believe that we did do that for
both 4.6.2-RELEASE and 5.2.1-RELEASE.  As someone's pointed out, the
ports committers are still fixing up some of the rough edges around the
X.org update, so that part of the tree isn't even ready to go yet.

The way I see it (and this is just my personal opinion, not an official
statement from re@), doing a point release now would be a distraction
from our next scheduled release, which is 7.0.

Bruce.

PS.  This having been said I know there are some kernel fixes that were
candidates for errata against 6.2-RELEASE...I'm not sure what their
current state is.  I'd like to see some of these get applied to RELENG_6_2.




signature.asc
Description: OpenPGP digital signature

Re: release cycle

[Bruce A. Mah]

If memory serves me right, Colin Percival wrote:
 Bruce A. Mah wrote:
 We've done point releases in the past but only in cases where there were
 severe problems and/or regressions with released versions.  Look at the
 announcements and release notes for 4.6.2-RELEASE and
 5.2.1-RELEASE...these were the two most recent instances where we did
 this.  There's a reason for this...it's a lot of effort.

 Folks should realize that making a new release (even a new point
 release) is not just a matter of tagging the tree and typing make
 release.  We (re@) need to figure out exactly what bugs are to be
 fixed, get the changes merged and tested, build at least one release
 candidate, get that tested, and finally build a set of RELEASE bits and
 push them out.
 
 I point releases have been obsoleted by errata notices.  In the past when
 X.Y.Z-RELEASE has happened, it has been because of critical bugs in the
 X.Y-RELEASE which there wasn't any other mechanism to fix.  Now that we
 have errata noticed and FreeBSD Update is in the base system, it's vastly
 easier for users to run freebsd-update fetch install than it is for them
 to upgrade to a new release.

That's a good point.  I'd be happy if we never had to do another point
release again, since we have to do probably half the work of a normal
release cycle but it's completely unexpected and unscheduled.

BTW I finally added some mention of freebsd-update(8) to the section of
the release notes that talks about upgrading FreeBSD.  Only on HEAD for
now, I'll put this on RELENG_6 when I get a Round Tuit.

 PS.  This having been said I know there are some kernel fixes that were
 candidates for errata against 6.2-RELEASE...I'm not sure what their
 current state is.
 
 Don't ask me, I just approve the errata which you send to me.  Which hasn't
 been anything at all lately. :-)

Ah no, we haven't sent you anything as of late, and that's the problem.  :-)

Bruce.



signature.asc
Description: OpenPGP digital signature

Re: HEADS UP: No longer need to recompile milters when upgrading

[Bruce A. Mah]

If memory serves me right, Gregory Shapiro wrote:
 The libmilter ABI breakage which required recompiling mail filters
 (milters) has been fixed in the RELENG_[456] branches.
 
 It is no longer necessary to recompile mail filters compiled against an
 older libmilter.so shared library.  Additionally, if you did recompile
 them already, you do not need to recompile them again.

Thanks for all your work on this!

Bruce.



signature.asc
Description: OpenPGP digital signature

Re: Reverting to 6.2-RELEASE

[Bruce A. Mah]

If memory serves me right, Pete French wrote:
 I appear to have a machine which will not run RELENG_6_2, though it runs
 the released code quite happily. Is there a CVS tag I can use to revert the
 sources back to the way they were on RELEASE? I want to be able to
 verify that this is and track down what changed! I don't think it should
 ever be the case that something which runs X.Y-RELEASE will not run RELENG_X_Y
 should it ?

According to my records of commits, there were only three post-release
commits to RELENG_6_2, and they were all fixes for security advisories
or errata notices.  They were:

FreeBSD-SA-07:02.bind (9 Feb 2007)
FreeBSD-EN-07:02.net and FreeBSD-EN-07:03.rc.d_jail (28 Feb 2007)
FreeBSD-EN-07:05.freebsd-update (15 Mar 2007)

All of these were vetted pretty closely by secteam@ and domain experts
(and usually re@ as well).  The only one of these that touched the
kernel was FreeBSD-EN-07:02.net, which backed out an IPv6-related
regression that was introduced late in the 6.2 release cycle.  I'm
personally pretty skeptical that this could cause a problem, although
I'm admittedly a little biased, plus there weren't a lot of details in
your email as to what the problem is.

To answer your last question:  If your machine runs 6.2-RELEASE, then
RELENG_6_2 should run on it.

Bruce.




signature.asc
Description: OpenPGP digital signature

Re: Canonical 4.x to 6.x upgrade docs?

[Bruce A. Mah]

If memory serves me right, Artem Kuchin wrote:
 
 Has anyone succeeded in doing a 4.x - 6.x upgrade from source without
 upgrading first to 5.x as an intermediate step?
 
 
 
 tried twice - did not work, but going to 5 and then to 6 was not a problem.
 But i suspect than going from older 4.x to newer 5.x (like 5.4) might not work
 and it might need another round of upgrade lile 4.x - 5.1 - 5.4 - 6.2
 I don't kwow for sure.

What's the basis for your suspicion?

5.X releases up through and including 5.4 included a migration guide
(written mostly by me) with step-by-step instructions on migrating from
4.X.  I don't recall any widespread problem reports from people when
following these directions correctly on migrating from 4.X to 5.4.  And
I'm fairly sure that a number of the FreeBSD.org machines were upgraded
using exactly this procedure (4.X to 5.4, then 5.4 to 6.X).

Bruce.



signature.asc
Description: OpenPGP digital signature

Re: IPv6 over gif(4) broken in 6.2-RELEASE?

[Bruce A. Mah]

If memory serves me right, Dimitry Andric wrote:
 JINMEI Tatuya / 神明達哉 wrote:
 Confirmed.  I've updated the machine on which I originally had this
 problem to -STABLE as of today, and the problem has disappeared.
 I thought it was also planned to be incorporated to RELENG_6_2, right?
 
 I'm not sure if non-security related fixes are considered for release
 branches.  Also, there's a workaround mentioned on the 6.2 errata page,
 under Known Issues:

Yes, we do this (most releases nowadays have at least a couple of errata
notices / patches).

 http://www.freebsd.org/releases/6.2R/errata.html
 
 Then again, it's really up to the release engineering team whether they
 deem this critical enough. :)

Its a joint decision between re@ and [EMAIL PROTECTED]  I *am* on re@, and I'd
planned on getting this change into RELENG_6_2, but I'm seriously
ENOTIME (now trying to type one-handed with my sleeping two-week-old son
in the other hand).  I'll send a copy of this to re@, hopefully one of
us will do this.

Cheers,

Bruce.



signature.asc
Description: OpenPGP digital signature

Re: IPv6 over gif(4) broken in 6.2-RELEASE?

[Bruce A. Mah]

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

 I mean that it may be that between -RELEASE and -STABLE, other things
 have changed, e.g. network rc scripts, /sbin/route itself, etc, which
 may also influence this behaviour.  I'm sure more than only nd6.c
 changed. :)

The testing I did doesn't require any of that stuff, only a kernel, a
shell, and ifconfig(8).  I'm not aware of anything relevant.  (As one of
the RE types, I do follow commit mails pretty closely, especially during
and just after a release cycle.)

 However, for me, with the whole system at -STABLE (as of Jan 11), I
 verified the following results again just now:
 
 nd6.c rev state
 - -
 1.48.2.12 works
 1.48.2.13 works
 1.48.2.14 works
 1.48.2.15 works
 1.48.2.16 doesn't work

I've convinced myself that this problem needs to be tested in isolation
(i.e. you have complete control over both ends of the tunnel) because
incoming packets over the tunnel cause the host route to get added
automatically if it wasn't there already.

After reading the code and discussing this with a couple folks, I've
managed to convince myself that 1.48.2.14 and 1.48.2.15 (and their
analogues on HEAD) need to go away.  I've committed diffs that back
these out, and they solve the problem for me in my testing (which I've
done with two VMs in isolation).  The applicable revisions for nd6.c are
1.74 (HEAD) and 1.48.2.18 (RELENG_6).  Updating up to (or beyond) these
revisions should clear up the problem.

Testing reports from people who were having problems would be appreciated.

Bruce.



signature.asc
Description: OpenPGP digital signature

Re: IPv6 over gif(4) broken in 6.2-RELEASE?

[Bruce A. Mah]

If memory serves me right, Dimitry Andric wrote:
 Bruce A. Mah wrote:
 and later I found out it was caused by commit 1.48.2.16:
 http://lists.freebsd.org/pipermail/freebsd-stable/2006-December/031853.html
 This isn't consistent with what I'm finding.  For one thing, rev.
 1.48.2.16 of nd6.c isn't in 6.2-RELEASE but I saw the problem there
 anyways.  Also, that's not the change I made to my local sources to get
 my gif(4) tunnel working.  Are you sure about this?  :-)
 
 I'm following -STABLE, and 1.48.2.16 is in there.  Since it was
 committed on 29 Nov, I suspected it would end up in -RELEASE, but
 apparently not. :)
 
 I explicitly tried reverting just this one commit, and for me it solved
 the problem (i.e. the automagical addition of needed routing entries).

I tried this too and it didn't help.  :-(

Just to confirm, you're dealing with a gif(4) interface with an
explicitly-configured destination address and a 128-bit prefixlen, yes?

 So for you, reverting the combination of 1.48.2.14 and .15 works?

Yep.  BTW these two changes really go together, so it doesn't really
make sense to revert just one of them (the commit logs implied that this
 would be fairly broken in other ways).

 Maybe
 there is something else involved too, for example the route command
 itself?

Not sure what you mean by this exactly...???...

Here's what I've tested so far...in the table below, work means that
the host route to the destination got installed correctly and no work
means that it didn't.

BaseLocal Patch Result
--- --
6.2-RELEASE Unmodified  No work
6.2-RELEASE Revert nd6.c 1.48.2.{14,15} Work
6.2-STABLE  Unmodified  No work
6.2-STABLE  Revert nd6.c 1.48.2.{14,15} Work
6.2-STABLE  Revert nd6.c 1.48.2.16  No work

I'm going to write up an entry for the 6.2-RELEASE errata notes
documenting the existence of a problem and a workaround.  We still need
to figure out exactly what the right fix is.  Testing results from other
users (both 6.2-RELEASE and 6.2-STABLE) would be most welcome.

Bruce.



signature.asc
Description: OpenPGP digital signature

Re: IPv6 problems with 6.2-RELEASE ?

[Bruce A. Mah]

If memory serves me right, Pete French wrote:
 2) rtsol(8) is used to initiate stateless autoconfiguration.  You might=20
 want to try rtsol -d interface.
 
 Aha... this does not work...
 
 3) Check the net.inet6.ip6.accept_rtadv sysctl.  ipv6_enable should take=20
 care of this.
 
 ...because this is 0
 
 All of which appears to be because a spurious 'ipv6_gateway_enable=YES'
 has found it's way into my rc.conf due to cut-n-paste. Which is
 interesting though, since even when I spotted it, it hadn;'t occurred
 to me that it would prevent the auto configuration working.

Ah yes, I remember stumbling over this (or some similar problem) many
years ago.  Machines that are configured as routers/gateways, as well as
multi-homed end-hosts, aren't supposed to use rtsol.

Also, accept_rtadv is usually 0...I think that our IPv6 startup scripts
toggle it to 1 just long enough to get a route advertisement and then
set it back to 0.

Bruce.



signature.asc
Description: OpenPGP digital signature

Re: IPv6 over gif(4) broken in 6.2-RELEASE?

[Bruce A. Mah]

If memory serves me right, Dimitry Andric wrote:
 Bruce A. Mah wrote:
  I remember Dimitry Andric reported the same problem on -stable on 30
  Dec, and after he reverted rev.1.48.2.16 it worked fine again.  Do
  you have the symptom even on 6.2-RELEASE?  Since RELENG_6_2_0_RELEASE
  did not have the change, I thought there was no problem.
 ...
 On my 6-STABLE system (which appears to be working fine), I still have
 the change from 1.48.2.16, I only backed out .15 and .14.  I didn't try
 my diff on the 6.2-RC2 and 6.2-RELEASE machines yet.

 Hmmm...I was looking for that bug report before, but I couldn't find it.
  It's not clear to me how 1.48.2.16 is involved...hmmm...
 
 I originally reported this here:
 http://lists.freebsd.org/pipermail/freebsd-stable/2006-December/031809.html
 
 and later I found out it was caused by commit 1.48.2.16:
 http://lists.freebsd.org/pipermail/freebsd-stable/2006-December/031853.html
 
 I'll shoot in a regular PR later tonight...

Hi Dimitry--

This isn't consistent with what I'm finding.  For one thing, rev.
1.48.2.16 of nd6.c isn't in 6.2-RELEASE but I saw the problem there
anyways.  Also, that's not the change I made to my local sources to get
my gif(4) tunnel working.  Are you sure about this?  :-)

Thanks!

Bruce.




signature.asc
Description: OpenPGP digital signature

IPv6 over gif(4) broken in 6.2-RELEASE?

[Bruce A. Mah]

I'm observing a problem with IPv6 over gif(4) tunnels on 6.2-RELEASE
and recent 6-STABLE, namely that I can't seem to be able to pass
traffic over them.

Essentially, when I configure a gif interface like this:

# ifconfig gif0 inet6 :::::1 :::::2 prefixlen 
128

the interface should add a host route to :::::2
through gif0.  This is necessary to be able to pass traffic over the
tunnel, particularly since the source and destination addresses of the
link don't need to have any relationship to each other.

However, this route doesn't get installed on recent 6-STABLE.
Therefore there is no way to get an IPv6 packet to the other end of
the tunnel because there's no route for the destination.  The most
obvious symptom is that I try to ping the other tunnel endpoint and
get:

ping6: UDP connect: No route to host

I know this worked on RELENG_6 as of June 2006; my home firewall has
been running this code for months without a hitch.  It doesn't work in
6.2-RC2 or 6.2-RELEASE (fresh CD installs on i386, GENERIC kernels),
or this week's RELENG_6 (nanobsd on i386).

I somewhat suspect revs. 1.48.2.15 and 1.48.2.14 to
src/sys/netinet/nd6.c.  If I locally revert these two changes (see
diff below), IPv6 over gif(4) works again.

There's another workaround for people stuck in this situation and who
aren't in a position to try this diff.  That is to manually install
the host route like this:

# route add -host -inet6 :::::2 -interface gif0 -nostatic 
-llinfo

Comments?

Bruce.

Index: nd6.c
===
RCS file: /home/ncvs/src/sys/netinet6/nd6.c,v
retrieving revision 1.48.2.16
diff -u -r1.48.2.16 nd6.c
--- nd6.c   29 Nov 2006 14:00:29 -  1.48.2.16
+++ nd6.c   20 Jan 2007 16:15:28 -
@@ -1316,7 +1316,7 @@
callout_init(ln-ln_timer_ch, 0);
 
/* this is required for ndp command. - shin */
-   if (req == RTM_ADD  (rt-rt_flags  RTF_STATIC)) {
+   if (req == RTM_ADD) {
/*
 * gate should have some valid AF_LINK entry,
 * and ln-ln_expire should have some lifetime


pgpVH4tzZ2z7f.pgp
Description: PGP signature

Re: IPv6 over gif(4) broken in 6.2-RELEASE?

[Bruce A. Mah]

If memory serves me right, Hiroki Sato wrote:
 Bruce A. Mah [EMAIL PROTECTED] wrote
   in [EMAIL PROTECTED]:
 
 bm I'm observing a problem with IPv6 over gif(4) tunnels on 6.2-RELEASE
 bm and recent 6-STABLE, namely that I can't seem to be able to pass
 bm traffic over them.

[snip]

 bm I know this worked on RELENG_6 as of June 2006; my home firewall has
 bm been running this code for months without a hitch.  It doesn't work in
 bm 6.2-RC2 or 6.2-RELEASE (fresh CD installs on i386, GENERIC kernels),
 bm or this week's RELENG_6 (nanobsd on i386).
 bm
 bm I somewhat suspect revs. 1.48.2.15 and 1.48.2.14 to
 bm src/sys/netinet/nd6.c.  If I locally revert these two changes (see
 bm diff below), IPv6 over gif(4) works again.

[snip]

  I remember Dimitry Andric reported the same problem on -stable on 30
  Dec, and after he reverted rev.1.48.2.16 it worked fine again.  Do
  you have the symptom even on 6.2-RELEASE?  Since RELENG_6_2_0_RELEASE
  did not have the change, I thought there was no problem.
 
  I will try to reproduce it on my box anyway...

Yep, even on 6.2-RELEASE.  I did a setup with a couple of machines
yesterday (6.2-RC2 and 6.2-RELEASE) that demonstrated the problem.

On my 6-STABLE system (which appears to be working fine), I still have
the change from 1.48.2.16, I only backed out .15 and .14.  I didn't try
my diff on the 6.2-RC2 and 6.2-RELEASE machines yet.

Hmmm...I was looking for that bug report before, but I couldn't find it.
 It's not clear to me how 1.48.2.16 is involved...hmmm...

Thanks,

Bruce.



signature.asc
Description: OpenPGP digital signature

Re: IPv6 problems with 6.2-RELEASE ?

[Bruce A. Mah]

If memory serves me right, Max Laier wrote:
 On Sunday 21 January 2007 02:17, Pete French wrote:
 I have a network with a 6.2-RELEASE machine as a gateway to
 the outside world, and on the inside three machines hung off it,
 running OSX, XPx64 and 6.2-RELEASE as well. The gateway machine
 NATs the internal network under Ipv4 and runs IPv6 via 6to4. It
 has routing advertised on the internal network.

 This *should* work - the OSX machine gets an IPv6 address and runs
 fine. The Windows XP x64 machine also gets an IPv6 address, and
 though it has problems with some wwebsites, it also basically works.
 The only machine which refuses to work is the FreeBSD machine, which
 refuses to acquire an IPv6 address!

 I find it very opuzzling, as this has worked in the past, and also
 the one machine I nwould have thought I would have had no problems
 with would have been the FreeBSD box - especially as the gateway
 machine is running an identical OS!

 I am not even sure where to start debugging this - how can I make the
 interface try and get an IPv6 address whilst watching what it is doing
 ? Has anyone else had problems like this ?

For the record, I haven't.  I have a 6-STABLE machine built that does a
fine job of handing out prefixes to clients (MacOS X and FreeBSD 6.X)
doing stateless autoconfiguration.  Although come to think of it, I
haven't yet tested stateless autoconf with a 6.2 host lately.

 There has been some confusion a while back, I don't remember the details.
 
 As for debugging:
 1) What do you have in rc.conf?  ipv6_enable should be set to YES and 
 ipv6_network_interfaces should be auto or a list of the interfaces that 
 should use IPv6.

One change that was made with 6.2-RELEASE is that ipv6_enable needs to
be set to YES in order for auto linklocal addresses to work
(previously they were on by default).  This change was made to improve
the security of systems in common IPv4-only configurations, but it
resulted in some unusual setups not working correctly.

 2) rtsol(8) is used to initiate stateless autoconfiguration.  You might 
 want to try rtsol -d interface.
 3) Check the net.inet6.ip6.accept_rtadv sysctl.  ipv6_enable should take 
 care of this.
 4) Check your firewall rules.

Maybe tcpdump(8) on the internal interface of the gateway box to see if
it's even getting the router solicitation message?

I have seen some problems with gif(4) tunnels, discussed in other
messages on this list, but this doesn't sound related to this situation.

Bruce.




signature.asc
Description: OpenPGP digital signature

Re: documentation iso file

[Bruce A. Mah]

If memory serves me right, Zoran Kolic wrote:
 I'd like to know, are documentation iso files for amd64 and i386 arch
 exactly the same? MD5 is different. I have the one for i386. Should I
 get also for amd64 and use it for 64 bit box? In other words, are they
 arch specific?

The content is arch-independent, although there was one ISO image
produced by each architecture's build machine during the
release-building process.

The different MD5 hashes are probably because of different timestamps or
other metadata within the ISO files.

You should be able to use any of the doc ISO files regardless of which
architecture you actually run.

Bruce.



signature.asc
Description: OpenPGP digital signature

Re: just cvsuped and compiled/installed world and kernel. why is uname -a still saying 6.2-prerelease?

[Bruce A. Mah]

If memory serves me right, Jayel Villamin wrote:
 tag used is RELENG_6.
 
 cvsup was completed at around 3am Monday New York time. 6.2 has been
 released hours before so I thought uname -a should display something
 else? like 6-stable or at least something other than
 6.2-prerelease?

Make sure you have at least revision 1.69.2.14 of
src/sys/conf/newvers.sh.  Otherwise the change probably just didn't
propagate yet to whichever cvsup mirror you're using.

Bruce.




signature.asc
Description: OpenPGP digital signature

Re: Source MAC addresses when bridge(4) used

[Bruce A. Mah]

If memory serves me right, Jeremy Chadwick wrote:
 On Sun, Jan 07, 2007 at 08:02:11AM +1100, Peter Jeremy wrote:
 The desktop network configuration is:
 tl0: flags=8943UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST mtu 1500
 ether 00:00:24:28:98:9a
 media: Ethernet autoselect (100baseTX full-duplex)
 status: active
 rl0: flags=8943UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST mtu 1500
 options=8VLAN_MTU
 inet 192.168.123.36 netmask 0xff00 broadcast 192.168.123.255
 ether 00:20:ed:78:9c:a3
 media: Ethernet autoselect (100baseTX full-duplex)
 status: active
 lo0: flags=8049UP,LOOPBACK,RUNNING,MULTICAST mtu 16384
 inet 127.0.0.1 netmask 0xff00 
 bridge0: flags=8043UP,BROADCAST,RUNNING,MULTICAST mtu 1500
 ether ca:a9:aa:1e:71:32
 priority 32768 hellotime 2 fwddelay 15 maxage 20
 member: tl0 flags=3LEARNING,DISCOVER
 member: rl0 flags=3LEARNING,DISCOVER
 
 Does tinkering with net.link.ether.bridge.config help at all?  See
 bridge(4) manpage.  (I haven't used this, I'm just brainstorming...)

Actually the applicable manpage for this configuration is if_bridge(4),
but I think the OP knew that.  As someone else in this thread pointed
out, the usual practice is to assign an IP address to the bridge0
interface and leave the member interfaces unnumbered.

As for *why* the IP address keeps moving around, I'm not sure either.

Bruce.




signature.asc
Description: OpenPGP digital signature

Re: 6.2 Release

[Bruce A. Mah]

If memory serves me right, Jack Vogel wrote:
 On 1/10/07, Colin Percival [EMAIL PROTECTED] wrote:
 Scott T. Hildreth wrote:
 Does anyone know if the Release is still going to happen today?
 The release is not going to happen today, but will be very soon.  My
 guess is that builds and mirroring will happen over the weekend and
 the release announcement will go out on Monday or Tuesday depending
 upon your time zone.

 Colin Percival
 
 You guys ROCK :) Hope this means I get a new current snapshot too?

The January CURRENT snapshots have been uploaded to ftp-master.
kensmith@ hasn't announced these yet, I think because he's waiting for
them to make their way out to the various FTP mirror sites.

Bruce.



signature.asc
Description: OpenPGP digital signature

Re: RELENG_6 version string

[Bruce A. Mah]

If memory serves me right, Angelo Turetta wrote:
 Am I dreaming, or hasn't the practice always been to rename the RELENG_6 
 kernel back to 6-STABLE (or whatever) just after the RELENG_6_x branch?
 
 Right now it's still labelled 6.2-PRERELEASE.

I think we've typically done this in the past but it's not something I
see written down anywhere.  Frequently we updated release notes and
things like that as well, although for 6.2, I'm glad we didn't since the
6.2 release cycle was (is) kind of longish.

At this point, I'd just as soon leave it until after 6.2 is released.

Bruce.



signature.asc
Description: OpenPGP digital signature

Re: FreeBSD 6.2-RC2 Available - networking zoneli freeze problem still exist.

[Bruce A. Mah]

If memory serves me right, LI Xin wrote:
 Ken Smith wrote:
 On Thu, 2006-12-28 at 16:01 +0100, Thomas Herrlin wrote:
 It still runs networking daemons into a frozen zoneli state on
 heavy/(D)DOS network loads. Such processes cant be kill-9ed so there is
 no way to recover from it. (think frozen sshd and a very remote/headless
 server).
 See the stress test panic called 'Ran out of 128 Bucket
 http://people.FreeBSD.org/%7Epho/stress/log/cons210.html' on the 6.2
 todo list and my own latest test here:
 http://www.maniacs.se/~junics/temp/vmstat-z.txt
 This test was on a new 6.2-RC2 install with no zone limit tweaks nor any
 sbsize limits in /etc/login.conf.
 I just made a vm disk image with replication instructions, however Peter
 Holm have replicated it with his own tools so i have not bothered with
 it until now. 
 That problem is being worked on but won't be fixed for 6.2-REL.
 Depending on how complex the fix winds up being it may be an Errata
 candidate when the time comes.
 
 Perhaps we should mention some known workarounds in the errata
 documentation.  E.g. raising nmbclusters limit, etc.?

That's a good idea.  Do you have more specifics (e.g. any particular
nmbclusters value, other workarounds, etc.)?

Thanks,

Bruce.



signature.asc
Description: OpenPGP digital signature

Re: Marvell 8053 support?

[Bruce A. Mah]

If memory serves me right, LI Xin wrote:

 Not sure if the snapshot contained the changes, though...  IIRC the
 January snapshot is not released yet?

The January CURRENT snapshots are being built and uploaded now.  The
mirrors might have some of the architectures, but an announcement will
come only after everything's been uploaded (and had a little while to
propagate).

Bruce.



signature.asc
Description: OpenPGP digital signature

Re: Possibility for FreeBSD 4.11 Extended Support

[Bruce A. Mah]

I wrote:

 That list isn't quite current either; at least two of the machines
 listed as running 4.X are really running 6.X due to recent hardware
 swapouts and upgrades.  I'll go update the Web page to reflect this.

...except that someone just beat me to it.  :-)

Bruce.




signature.asc
Description: OpenPGP digital signature

Re: Possibility for FreeBSD 4.11 Extended Support

[Bruce A. Mah]

If memory serves me right, Wilko Bulte wrote:
 On Fri, Dec 29, 2006 at 08:45:03AM +0800, lveax wrote..
 seems there are many machines at freebsd.org network are still using
 4-STABLE now.
 
 There is a mix of versions in use, upgrading is done at the discretion
 of the admins team that controls the FreeBSD.org server farm.  That in
 turn is dependent on the amount of time admins have available etc etc.
 
 So what is the problem?

That list isn't quite current either; at least two of the machines
listed as running 4.X are really running 6.X due to recent hardware
swapouts and upgrades.  I'll go update the Web page to reflect this.

Bruce.





signature.asc
Description: OpenPGP digital signature

Re: Status of FreeBSD 6.2?

[Bruce A. Mah]

If memory serves me right, Freddie Cash wrote:
 On Tuesday 26 December 2006 01:49 pm, Martin Blapp wrote:
 Build 6.2-RC2   24 December 2006Begin building the second
 release candidate
 build for all Tier-1 platforms.
 http://www.freebsd.org/releases/6.2R/schedule.html
 
 Note:  Only the actual column for RC2 has been updated.  The expected 
 column for everything that follows still lists dates in Oct/Nov 
 timeframe.  I think this is what Brett is asking about:  and update on 
 the expected timeframe.

The bits for 6.2-RC2 are making their way to the FTP mirrors now (if
they're not there already).  I think it should be possible to announce
6.2-RC2 today.

The current, tentative plan is to start building 6.2-RELEASE about a
week and a half after the 6.2-RC2 announce date (again, that might be
today), and then announce 6.2-RELEASE a few days later.  This assumes
that there aren't any (more) last-minute problems.

The situation has been fairly fluid over the last month or so, due to
various problems that keep showing up at inconvenient times...everything
from last-minute bugs to ftp-master's RAID blowing up.  I admit we
haven't been real communicative about the status of the release.  :-p

Bruce.




signature.asc
Description: OpenPGP digital signature

Re: RC2 ?

[Bruce A. Mah]

If memory serves me right, Scott T. Hildreth wrote:
 Will there be a RC2 or just a realease?

Current plans are to do one more release candidate (== 6.2-RC2) and then
the final release.  If I said it was coming soon, nobody would believe
me, so I won't say it.  :-p

Bruce.



signature.asc
Description: OpenPGP digital signature

Re: em driver testing

[Bruce A. Mah]

If memory serves me right, ke han wrote:
 According to the 6.2-beta3 announcemetn, there are improvements to  
 the em driver.
 
 The most important of the things that have been worked on is the
 driver for em(4). 
 
 I have a Sun X4100 which uses Intel ethernet.  I would like to  
 install amd64 6.2beta3 on this server and put it through some tests.
 But I have no idea what tests to run or how to run them.
 Can someone provide some pointers?  I am happy to post my findings.

There were a number of problems in em(4) that appeared post-6.1.  A new
version of the em(4) driver was merged to the RELENG_6 branch just prior
to 6.2-BETA3.  That version is better, but still has some unresolved
issues (problems have been reported with jumbo frames and with watchdog
timeouts).  There's a new patch by jfv@ in an email a few days ago (with
subject New em patch for 6.2 BETA 3) that might fix these problems.
It might be worthwhile to try this out.

Basically, just look around the archives of stable@ to see discussions
of the em driver over the past month or so.  I believe that a number of
prior problems were uncovered when people just tried to push a lot of
traffic through the interface.

Bruce.




signature.asc
Description: OpenPGP digital signature

Re: some issues not listed on TODO

[Bruce A. Mah]

If memory serves me right, Mikhail Teterin wrote:

 Looking at the http://www.freebsd.org/releases/6.2R/todo.html today, I was 
 surprised to not see the following problems in addition to the em(4) issue:

[snip]

Just because a particular issue isn't mentioned on this page doesn't
mean that RE isn't interested in it.  I'm only listing in the major
issues section those things that are currently holding up progress on a
release.  In this case, we've got 6.2-BETA3 holding on some kind of
resolution for the em(4) problems because they have the ability to
affect a *lot* of users.

Thanks,

Bruce.



signature.asc
Description: OpenPGP digital signature

Re: tz ME

[Bruce A. Mah]

If memory serves me right, Randy Bush wrote:
 releng6 as of yesterday
 
 # tzsetup 
 tzsetup: /usr/share/zoneinfo/zone.tab:250: country code `ME' unknown

I think this was fixed in rev. 1.13.8.2 of src/share/misc/iso3166.

Bruce.



signature.asc
Description: OpenPGP digital signature

Re: HEADS UP: FreeBSD 5.3, 5.4, 6.0 EoLs coming soon

[Bruce A. Mah]

If memory serves me right, Philippe Pegon wrote:

 In June 2006, I opened a PR (kern/98622) about a regression on CARP
 with IPv6 addresses: CARP is not usable with IPv6. Since I tracked
 down the culprit commit (see appropriate info in the PR), I can
 affirm that this regression appeared before the 6.1-RELEASE.

bz@ has just recently (a couple of hours ago) updated kern/98622 with a
possible fix.  It'd be really useful if you (or anyone else experiencing
this problem) could try this out and give him some feedback.

(I know that you, Philippe, know all this already, but I wanted to get
the information out to a wider audience.)

Cheers,

Bruce.




signature.asc
Description: OpenPGP digital signature

Re: 'make release' questions...

[Bruce A. Mah]

If memory serves me right, Peter Losher wrote:
 I have been mucking about w/ 'make release' for some time now (stripping
 out OpenSSH, sendmail, Heimdal, bits oF BIND, etc.) and while I now have
 a working .iso image, that will install and update, I have some
 questions that 'man release' just won't answer. :)
 
 First, is there any way to instruct 'make release' to just build certain
 packages (and their dependencies) for inclusion in the release instead
 of a blanket NOPORTS?  There's no need for us spend two/three days
 compiling all the various ports when we will only use a small handful of
 them on most of our boxes.  (and would speed up the amount of time it
 takes to roll out a new release) ;)

NOPORTS controls whether or not the ports tree gets checked and built
for the release.  It doesn't do a full package build.

If release-building speed is really important for you, you might want to
turn on NODOC.  This avoids building a doc toolchain (i.e. the
textproc/docproj port), the doc/ tree, and the release documentation.

I haven't read through src/release/Makefile for awhile, so I'm not sure
if there's an easy way to build (and include) the selected packages
build you want.  I know we don't do this for official release
builds...all the packages get built on the ports-building cluster and
get added afterwards.  You might want to read through
src/release/Makefile...it might take a few passes but it'll probably be
worth your time just so you can understand all the various steps going
on.  Just a thought.

 Second, is there a way to build/tell sysinstall that if NO_OPENSSH is
 set, that it doesn't ask you whether you want to enable SSH logins?

speculationI don't think so./speculation

Bruce.



signature.asc
Description: OpenPGP digital signature

[Fwd: cvs commit: CVSROOT approvers]

[Bruce A. Mah]

In case anyone missed this:  RELENG_5_5 is now in the very capable hands
of the security officer and his team.

Bruce.
---BeginMessage---
scottl  2006-05-31 06:45:44 UTC

  FreeBSD src repository

  Modified files:
.approvers 
  Log:
  Give ownership of the RELENG_5_5 branch to the security officer.
  
  Approved by:re
  
  Revision  ChangesPath
  1.35  +1 -2  CVSROOT/approvers

http://www.FreeBSD.org/cgi/cvsweb.cgi/CVSROOT/approvers.diff?r1=1.34r2=1.35f=h

---End Message---


signature.asc
Description: OpenPGP digital signature

Re: FreeBSD 6.1-STABLE

[Bruce A. Mah]

Robert Watson wrote:
 
 On Sat, 6 May 2006, Gergely CZUCZY wrote:
 
 i see, thanks. there is some XML(or similar) file. should i have to
 build the whole world to get a human-readable form, or is there some
 other, less painful way for it?
 
 The release notes are built automatically as part of the global release
 build process.  You can also build them directly by changing to the
 src/release/doc directory and doing a make.  You'll need to have the
 docproj packages/ports installed in order to build them.

For the curious, I've updated the documents for HEAD and RELENG_6_1 on
my completely unofficial Release Documentation site:

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

(It's not updated as often as it once was, but for the moment it is
current with respect to what's in CVS.  In the event that I notice any
changes to the release notes, I'll try to rebuild them.)

 Just to keep waving the flag: the release is not yet finalized or out,
 so things may yet change.  The current contents should be considered a
 working draft, not the final version, until it's actually out the door
 and announced. We've had to delay releases at this point in the cycle
 before due to last minute discoveries or issues, and while I hope it
 doesn't happen this time around, we can't rule it out!

I want to reemphasize this point for folks.  When I was a member of the
RE team, we often saw weird things happening late in the process (I
won't jinx the current team by citing examples).  I know that a lot of
people are anxiously awaiting 6.1-RELEASE and it's been a *long* release
cycle...just be patient a little longer...

Cheers,

Bruce.



signature.asc
Description: OpenPGP digital signature

Re: Help For upgrading Releng4.11 stable to 6.0 stable

[Bruce A. Mah]

If memory serves me right, Ralf S. Engelschall wrote:

 Directly jumping from 4 to 6 might work similar to the 4 to 5 procedure
 but I've never tried this.

No.  Source-upgrading to 6.X can only be done from 5.3-RELEASE (or newer
RELENG_5).  So somebody trying to do a source upgrade from 4.X needs to
do it in two steps.

But in general for such a large upgrade I'd strongly urge backing up
all data, wiping the disk(s), and reinstalling + restoring.  (For what
it's worth, I specifically recommended this in the 5.X Early Adopters
Guide.)

Cheers,

Bruce.


signature.asc
Description: OpenPGP digital signature

Re: 4.11 to RELENG_6

[Bruce A. Mah]

If memory serves me right, Oliver Fromme wrote:
 Björn König [EMAIL PROTECTED] wrote:
   Randy Bush wrote:
any peculiarities/clues for upgrading an antique from 4.11 to
RELENG_6 beyond the To upgrade in-place from 5.x-stable to 
current in UPDATING?
   
   I guess not. From the release notes of 6.0-BETA2:
   
   Source upgrades to FreeBSD 6.0-CURRENT are only supported from FreeBSD 
   5.3-RELEASE or later. Users of older systems [...]
 
 Unfortunately, that statement is ambiguous:  FreeBSD 4.11
 (Jan. 2005) is _not_ older than 5.3 (Nov. 2004).  However,
 I guess that's not what the release notes really mean.

Sorry.  :-(  The case of someone trying to upgrade from 4.X to 6.X
hadn't occurred to me when I wrote that (because, as noted, 4.X to 5.X
is non-trivial).

 For the mentioned update from 4.x to 6.x, I would go via
 a binary upgrade, which has probably fewer pitfalls and
 is finished a lot faster than a source upgrade.

I'd advise that as well.

Bruce.



signature.asc
Description: This is a digitally signed message part

Re: Quality of FreeBSD

[Bruce A. Mah]

If memory serves me right, Janet Sullivan wrote:

 I do think some mistakes were made with the release engineering over 
 5.x's lifetime, but folks, what's done is done.  Recently things do seem 
 to be headed in a better direction, for which I'm thankful.

As one who was there for about half of the 5.X releases, I think we
did the best we knew how to do at the time, but if we knew then what we
know now, there are things we would have handled differently.  (The
details have been discussed extensively on the lists, by people who are
both more knowledgable and more eloquent than me.)

 I know the developers don't hear it often enough, but thanks for all you 
 do.  I'm not a programmer, and I currently don't have the funds to 
 donate to the project, but you do have my heartfelt thanks for still 
 turning out my favorite OS.

You're welcome, and I'm sure I speak for at least a few other developers
when I say that you'd be surprised how valuable a donation of a few
kind words can be.

Cheers,

Bruce.



signature.asc
Description: This is a digitally signed message part

Re: 4.11 to 5.3 Any issues I should know before making the change.

[Bruce A. Mah]

If memory serves me right, Brian Wolman wrote:
 Just wanted to find out if there are any issues when jumping from the 
 4.11 to the 5.3. Like way out of the ordinary type problems, this jump 
 for me is going to be very difficult as it is and I want to make sure I 
 don't get a surprise...

Read the migration guide that comes with the 5.3 release documentation:

http://www.freebsd.org/releases/5.3R/migration-guide.html

That's what we wrote it for.  :-)

Bruce.



signature.asc
Description: This is a digitally signed message part

Re: 4.9 is now available

[Bruce A. Mah]

If memory serves me right, Don Lewis wrote:
 On 30 Oct, Bruce A. Mah wrote:
 
  I'm pretty sure we have support for both types of bootable CD-ROMs in
  the bootstraps and the release building code on both 4.X and 5.X. Anyone
  who builds their own releases ought to be able to generate either type.
  It's not a goal of the FreeBSD Project to actually do this, but a vendor
  could do this as a value-add if they were so inclined.
 
 The vendor would either need to sell two different distributions and
 hope their customers bought the correct one, or include both flavors in
 the distribution, which means including an extra CD-ROM full of mostly
 duplicate stuff.  Even in the latter case, the vendor has to document
 things well enough for the customer to figure out which CD to use for
 the install.  The wonders of PeeCee hardware ...

I didn't say it would be easy.  :-p

 It looks like the 4.x version of mkisoimages.sh only supports Emulated
 El-Torito, 

But you can build the ISO images without using this script.  If it were 
me, I'd probably do a release with the ISO images, and then remaster 
them with my own set of arguments to mkisofs.  disc1.iso is made this 
way (because we have to add the package set and other stuff before 
producing the ISO image).

 and the EMUL_BOOT option in the 5.x release/Makefile isn't
 well documented.

True.

 I wonder if it makes sense to tweak release/Makefile to allow both
 flavors of ISO images to be generated in the same run as an option so
 that folks who might need both (or don't know which one they might need
 ahead of time) don't have to try to figure out how to build the iso.1
 target twice with different options.

Hmmm.

Bruce.




pgp0.pgp
Description: PGP signature

RELENG_4_9 branch created

[Bruce A. Mah]

Some of you may have noticed the creation of the RELENG_4_9 branch on
the src/ tree.  This is, of course, the release branch for FreeBSD
4.9, which will become the security-fix branch at some point after the
release.

Please remember that this does *not* mean that FreeBSD 4.9 is
ready.  It's not official until release tags are down, distributions
have been built and uploaded to the FTP sites, and, most importantly, a
PGP-signed release announcement has been sent to the freebsd-announce@
mailing list.  There's still a bit of work to be done to get to this 
point, such as changing version numbers, testing, the actual builds, 
more testing, and so on.

Bruce.
(For the release engineering team)

PS.  Just me talking now...to answer the question that is probably
foremost in many of your minds:

I don't have an exact date for the release.  Stay tuned.

:-)




pgp0.pgp
Description: PGP signature

Re: tcpslice out of date

[Bruce A. Mah]

If memory serves me right, Damian Gerow wrote:
 I was working with tcpdump and tcpslice earlier today, and had a bit of a
 struggle when I found out that it's not Y2K compliant - it doesn't
 understand any year beyond 1999.  After stating this on a mailing list, it
 was pointed out that the current source is indeed compliant, but the
 FreeBSD source is a little out-dated.
 
 Any chance we could get an updated tcpslice (and possibly tcpdump, I
 haven't checked to see if it's out of date or not) imported after 4.9?

There's a newer (Y2K-compliant) version in ports (net/tcpslice).  I
was talking with Bill Fenner (CC-ed) about the possibility of
importing this newer version to the base system but I think both of us
had too many other things to deal with.  :-p

IMHO, we should either import a newer version to the base system or
kill it altogether and rely on the one in ports.

Bruce.



pgp0.pgp
Description: PGP signature

Re: 2 Questions

[Bruce A. Mah]

If memory serves me right, Warner Joseph wrote:

 I know everyone involved has worked and continues
 to work really hard on both branches and as a
 user I really appreciate that.  It's quite evident
 that there are other vendors who don't even come
 close to what you guys do!

Thanks, we try.  :-)

 If I could find the time to learn to code I'd
 definitely pitch in and help.

There are lots of areas of FreeBSD that don't require any particular
coding skills.  The doc project is one example.

Cheers,

Bruce.




pgp0.pgp
Description: PGP signature

Re: 2 Questions

[Bruce A. Mah]

If memory serves me right, Warner Joseph wrote:

 There's a 4.9 scheduled for release later this year / early next year.  
 4-STABLE will be around until 5.x is deemed ready for everyday, 
 production use and a 5-STABLE branch is created.  This is tentatively 
 scheduled for 5.2, but may be pushed back to 5.3 is need be.  Thus, 
 there might be a 4.10 and possibly even a 4.11.
 
 Really?  Wow!  For some reason I wasn't thinking it would continue
 on that far.

Without committing the release engineering team to anything:  One idea
is that after 4.9, we might do some maintenence releases, primarily to
merge in bugfixes.  These would be more along the lines of 4.9.1,
4.9.2, et al.  If we do lightweight 4.9.X releases after 4.9, we can
concentrate more on building more robust 5.X releases so we can do a
5-STABLE branch.

As an aside, doing interleaved releases from the 5.X and 4.X branches
is really hard on the RE and portmgr teams.  We can cut four releases
total in a year, but that's pushing it (three used to be normal).  I
know that CDROM vendors and many of our fellow users would like us to
release more often, but there's just a limit to what we can do while
avoiding concurrent releases, major holidays, etc.

Bottom line is that there aren't any firm plans at this point, although 
I assure you it's something we're thinking about.

Bruce.




pgp0.pgp
Description: PGP signature

Re: 4.8R and $FreeBSD$ version tag expansion

[Bruce A. Mah]

If memory serves me right, Julian Stacey wrote:
 Reference:
  From:   David A. Gobeille [EMAIL PROTECTED] 
  Date:   Fri, 04 Apr 2003 18:21:00 -0600 
  Message-id: [EMAIL PROTECTED] 
 
 David A. Gobeille wrote:
  I noticed that there were quite a few files with version ids of 
  '$FreeBSD$' when I ran mergemaster after an install of 4.8R.  This isn't 
 
 I read tags were reworked.  Prob. you'r working from old sources,
  It'll rectify if you wait a day  then { refresh your CVS
 tree  re-export src/ } or { if src/ from a .iso, check your MD5,
  refetch from local mirror if old }, then remake.

I think I explained this in a prior posting to this list, but what
happened was that the $FreeBSD$ CVS keywords didn't get expanded the
first time we tried to build a release.  mergemaster hates this, as
the original poster discovered.  For this and other reasons, we
considered this a showstopper and rebuilt the release; when we did, we
also needed to modify one file and slide its CVS tag.

Users updating from sources (e.g. using cvsup or anon CVS) were
probably not affected by this.

 PS I told re@ some hours back that there's no 
   ftp://ftp.freebsd.org/pub/FreeBSD/ISO-IMAGES-i386/4.8/CHECKSUM.MD5
 they looked: there is CHECKSUM.MD5 on ftp-master, but it's not made
 it over yet - the servers are very busy: waiting seems best solution :-)

And in my reply to you, I mentioned that I had already put the contents
of CHECKSUM.MD5 (for the i386 ISO images anyways) in the 4.8 errata
file, which is on the Web site.  :-)

Cheers,

Bruce.


pgp0.pgp
Description: PGP signature

Re: make release failure

[Bruce A. Mah]

If memory serves me right, Scott Sewall wrote:
 
 I'm trying to run make release of RELENG_4 on i386, and am getting the following 
 error:
 
 checking for BSD-compatible nm... /usr/bin/nm -B
 /ltconfig: Can't open /ltconfig: No such file or directory
 configure: error: libtool configure failed
 ===  Script configure failed unexpectedly.
   Please report the problem to [EMAIL PROTECTED] [maintainer] and
   attach the /usr/ports/textproc/jade/work/jade-1.2.1/config.log
   including the output of the failure of your make command. Also, it might
   be a good idea to provide an overview of all packages installed on your
   system (e.g. an `ls /var/db/pkg`).
 *** Error code 1
 
 Stop in /usr/ports/textproc/jade.
 *** Error code 1

[snip]

Yes, this is indeed a Real Problem (TM).  I'm told that a patch is
circulating for testing purposes (don't ask me where, I'm not sure).
We (RE) need to have this fixed in order to build 4.8-RELEASE; 4.8-RC1
and 4.8-RC2 went out without docs because of this problem.

Bruce.




pgp0.pgp
Description: PGP signature

Re: FreeBSD Security Advisory FreeBSD-SA-03:04.sendmail

[Bruce A. Mah]

If memory serves me right, Mike Tancsa wrote:
 At 09:11 AM 03/03/2003 -0800, FreeBSD Security Advisories wrote:
 Module: contrib_sendmail
 Announced:  2003-03-03
 Credits:Mark Dowd (ISS)
 Affects:All releases prior to 4.8-RELEASE and 5.0-RELEASE-p4
 FreeBSD 4-STABLE prior to the correction date
 Corrected:  2003-03-03
 1) Upgrade your vulnerable system to 4-STABLE; or to the RELENG_5_0,
 
 
 Hi,
 I dont see this in the cvsup commit logs yet ?

Every cvsup mirror updates on a periodic schedule.  The commits to the
src tree (which happened about 30 minutes ago) probably haven't made
it to all the mirrors yet.  (You can see the changes in cvsweb,
probably the cvs-all mailing list archives as well.)

Bruce.


pgp0.pgp
Description: PGP signature

Re: Is XFree86 4.3.0 going to be in 4.8? -nt-

[Bruce A. Mah]

At this point, I'd guess probably not, given that there was (is?) some
amount of work for the MAINTAINER to do to get it to build correctly,
and there's not much chance for testing before the release, which is
only two weeks away.

That's just my guess, though, not a policy statement.  :-)

Bruce.



pgp0.pgp
Description: PGP signature

Re: 5.0-STABLE ???

[Bruce A. Mah]

If memory serves me right, Stijn Hoop wrote:

  In the end, the exact origin of RELENG_5_1 is much less likely to have
  any real effect on anybody than the state of the code at the time the
  branch is made.
 
 So this means that HEAD is still kept in a stable state, or at least stable
 API-wise, so that 5.1 can be branched from it if needed? What changes are
 'planned' for 5.1? Any overview available? Of course it's not going to
 be comprehensive, but I am just wondering.

HEAD is in a semi-freeze state.  Not quite the state of code-freeze, but
any large changes (especially those that affect APIs or ABIs require RE
approval).  (See the releng page on the Web site for a slightly more 
precise description of this.)

As for changes, the main change that I would hope to see is that 
features that were labeled experimental or work in progress for 5.0 
will be completed and fleshed out.  Other than that, I don't know of 
any specifics.

Bruce.





msg53189/pgp0.pgp
Description: PGP signature

Re: 5.0-STABLE ???

[Bruce A. Mah]

If memory serves me right, Ned Wolpert wrote:

  So this means that HEAD is still kept in a stable state, or at least
  stable API-wise, so that 5.1 can be branched from it if needed? What
  changes are 'planned' for 5.1? Any overview available? Of course it's
  not going to be comprehensive, but I am just wondering.
 
 (Slightly off your topic, but this has started to get confusing, so
 I think we need a better explanation for following stable... )

If you haven't already, please go read Early Adopter's Guide for 5.0.  
Most of what I have to say on this topic is contained with that 
document.

 5.0 isn't stable, its released.  Until there is a RELENG_5, stable is
 RELENG_4, right? Least from the announcement, it was commented that those
 needing stability may wish to stay with 4.x branch until 5 is deemed
 stable.  (which is only done when there is a RELENG_5 branch)

Yes.

 With that said, for people moving to 5.0, if they want some form of
 stability, will need to follow RELENG_5_0 for the time being.  Following
 the HEAD really can't be 'stable', least as far as 'general public' is
 concerned.  Correct me if I'm wrong, but it sounds like the best way to
 go (For general public wishing to stay 'stable' with 5) is to keep
 switching cvsup file's tag from RELENG_5_0 to RELENG_5_1 as releases occur
 until 5 is considered stable.  Does this sound correct?

I honestly don't know what general public means in this context.  
Again, please read the EAG and make your own decisions.

 Also, from my viewpoint (which may differ from reality... ;-) The HEAD may
 be kept in a stable state API wise for the time being... but it can still
 break. (It is, after all, -current)

Breakage has been known to happen in RELENG_4 as well.  HEAD is in a 
semi-frozen state (please see the releng page on the Web site for a 
more precise definition of this).

 So, at the next release, _if_ it is
 considered stable, then we'd likely see that they'll first branch RELENG_5
 from the HEAD, then RELENG_5_1 from RELENG_5.  Only because the next release
 (5.2) will also be branched from RELENG_5.  (Course, they could branch
 RELENG_5 now from the head, mid-release if they wanted, though I doubt it.)

This is essentially correct, but as I wrote in an earlier message, you 
should probably be less concerned about what the exact sequence of 
branching is than the state of the code at the time it's branched.

Bruce.





msg53190/pgp0.pgp
Description: PGP signature

Re: 4.4-RELENG_4 error when running make...

[Bruce A. Mah]

If memory serves me right, Jeff Love wrote:

 Of course, if you installed the new system before building the new
 kernel, you would not have hit this problem, but you are living
 dangerously when you install the new world and try to run with the old
 kernel.
 
 That is exactly how I've been doing it for years. 'cd /usr/src',  'make 
 buildworld', 'make installworld', 'cd sys/i386/conf', 'rm -rf 
 ../../compile/mykernel', 'config mykernel', 'cd ../../compile/mykernel', 
 'make depend', 'make', 'make install', do manual merge, reboot.
 
 This has never failed, except when I've used mergemaster, which can make 
 a mess of things easily.
 How would this method differ from using 'make buildkernel 
 KERNCONF=/usr/src/sys/i386/conf/mykernel' and 'make installkernel 
 KERNCONF=/usr/src/sys/i386/conf/mykernel' ? Both methods install the new 
 kernel on a running machine.

make buildkernel uses the compiler toolchain that was compiled by a
previous make buildworld.  config / make depend / make uses the the
toolchain that is currently installed on the running system.  If you're
updating across certain types of changes to the toolchain, you need to 
use the buildkernel target.

You'll probably ask, Why can't I do buildworld / installworld /
config?  In a lot of instances you can, *except* when the userland
depends on features of the new kernel.  People get bit there too.

As has been pointed out ad nauseum on this list, in many cases you can
get away various short-cuts.  But if you run into problems, the first
thing that a lot of people (including myself) will say is go follow the
instructions in src/UPDATING.  These instructions were written by 
people who understand all the bizarre edge cases that can happen during 
upgrading.

Bruce.






msg50104/pgp0.pgp
Description: PGP signature

Re: HEADSUP: gzip packages on FreeBSD 4-STABLE

[Bruce A. Mah]

If memory serves me right, Philip Paeps wrote:
 On 2002-09-24 08:42:33 (-0700), Bruce A. Mah [EMAIL PROTECTED] wrote:
  Due to some difficulties encountered while testing bzip2 packages for
  FreeBSD 4.7-RC1, the Release Engineering team (with agreement from the Port
  Manager team) has decided to revert back to gzip packages, at least for the
  remaining 4.7-RC snapshots and 4.7-RELEASE.
 
 Would it not be more preferable to have support for both gzip and bzip2
 packages?  Perhaps with a command-line switch (-g, -b) pkg_add could be told
 to look for a different kind of compression.

It's more complicated than that.  Some things, such as pkg_add -r and 
sysinstall, require that pkg_add be able to automatically handle 
whatever type of compression gets thrown at them.

This isn't an impossible problem to solve, but we judged that it was
more than we could handle for 4.7-RELEASE.

Bruce.





msg49932/pgp0.pgp
Description: PGP signature

Re: HEADSUP: gzip packages on FreeBSD 4-STABLE

[Bruce A. Mah]

If memory serves me right, Christopher Vance wrote:
 On Wed, Sep 25, 2002 at 08:08:16AM +0100, Nick Barnes wrote:
 : So the system which I upgraded to -STABLE just last week, for the sole
 : purpose of getting a working pkg_add -r (i.e. one which understood
 : bzip), will now no longer have a working pkg_add -r?

I sense some (understandable) frustration here.  You're right in that
it's not likely to work, once a gzip package set is uploaded for
4-STABLE.  I wish you didn't have to go through that effort for nothing,
but we judged that to be the best alternative available to us.

 If the current pkg_add won't handle both, it's broken worse than ever.

Which is why we're going back to gzip.

Bruce.





msg49933/pgp0.pgp
Description: PGP signature

HEADSUP: 4-STABLE package building now using gzip

[Bruce A. Mah]

As mentioned by an earlier email, 4-STABLE now uses gzip as the default
compression scheme for package building and installation.  The ports
cluster has finished building a gzip package set...it'll hopefully make
its way to the FTP sites sometime soon.  (FYI:  This package set will
also be the basis of the packages for 4.7-RC2.)

(Thanks to Kris Kennaway for helping with the ports infrastructure and 
package building aspects of this.)

I've gotten a number of emails to the general effect of Why don't you
guys like bzip2 packages?  Once again, it's not that we (RE) think it's
a bad idea...the problem is that our support for bzip2 packages isn't
mature enough for a release.  Thanks for understanding.

Cheers,

Bruce.






msg49934/pgp0.pgp
Description: PGP signature

Re: new install -- 4.6.2 or 4.7-RC1?

[Bruce A. Mah]

If memory serves me right, John Daniels wrote:

 I am about to do a new install.  I do not want to wait 10+ days
 for 4.7-REL.
 
 Will there be a 4.7-RC2? (if so, when?)

Yes.  Probably later this week.  Mostly this depends on some pkg_*
issues getting solved.

 Is there a way to get 4-STABLE in one step (install) instead of 2 (install, 
 upgrade)?

4.7-RC* is from the 4-STABLE (RELENG_4, actually) branch.

releng4.freebsd.org (once again) seems to be building daily snapshots 
you can use for installs, as well as snapshots.jp.freebsd.org.

Bruce.





msg49868/pgp0.pgp
Description: PGP signature

Re: install cd boot problems?!

[Bruce A. Mah]

If memory serves me right, Arnvid Karstad wrote:

 Trying to install FreeBSD on one of the older dual cpu pentium pro
 machines we have and it always seem to freeze up around when it's
 supposed to wait 15 seconds for the scsi devices to settle.
 
 Tried to boot both 4.5 and 4.6.2 release cd's boot no luck. Linux boots
 and shows the scsi subsystem being:

One possibility is to see if you have any better luck with a 4.7-RC1
snapshot (or wait for 4.7-RELEASE when we get it out the door).  The
ahc(4) driver has been updated fairly recently, although I don't know if
these might help your problem.

Bruce.





msg49803/pgp0.pgp
Description: PGP signature

Re: 4.7-PRERELEASE FAILING!!

[Bruce A. Mah]

If memory serves me right, Tim Robbins wrote:
 On Thu, Sep 19, 2002 at 02:48:59PM +0200, Dimitry Andric wrote:
 
 [...]
  I fear this is going to be a FAQ when 4.7 hits the streets... Wouldn't
  this be a good entry for the /usr/src/UPDATING file? :)
 
 It's in the release notes. The version on www.freebsd.org is out of date;

GI don't know why this stopped updating (yet again).  I've sent
off a query to try to get this fixed.

 try this instead:
 ftp://snapshots.jp.freebsd.org/pub/FreeBSD/snapshots/i386/4-LATEST/RELNOTES.T
 XT

Which in turn is updated from files at:

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

(This may be slightly more up-to-date, because updating this site is a 
part of my build testing for release documentation changes.)

Cheers,

Bruce.





msg49745/pgp0.pgp
Description: PGP signature

Re: -STABLE Frozen for 4.7

[Bruce A. Mah]

If memory serves me right, Dmitry Pryanishnikov wrote:

 On Fri, 6 Sep 2002, Murray Stokely wrote:
If you are experiencing any problems with -STABLE then by all means
  speak up now!
 
  Please, MFC fix for bin/40177 before 4.7-RELEASE, I think memory leak in
 /bin/sh is a quite serious problem.

maxim just got RE approval to fix this.

 Please also fix bin/41841 (telnet -s
 doesn't resolve names) - fix is obvious, but it seems that nobody cares
 about it.

It's more likely that nobody has gotten around to it yet because 
there's so many other things to be done.

Bruce.





msg49616/pgp0.pgp
Description: PGP signature

Re: -STABLE Frozen for 4.7

[Bruce A. Mah]

If memory serves me right, Kris Kennaway wrote:

 On Fri, Sep 06, 2002 at 02:37:09PM -0700, Andy Sparrow wrote:
 =20
 If you are experiencing any problems with -STABLE then by all means
   speak up now!
 =20
  Hi,
 =20
  Can we please MFC termcap.src so that the xterm/xterm-color stuff=20
  finally gets fixed?
 
 There have been a number of complaints about how that termcap commit
 broke/changed terminal functionality..I don't expect it to be MFCed
 yet.

It wasn't clear to me whether or not these had been resolved on 
-CURRENT; if not, don't look for it to show up in -STABLE anytime soon.

  Uhhh, did the atapi-cam stuff get MFC'd yet? It was committed to=20
  -CURRENT almost a month ago.
 
 Not yet, and it shouldn't be MFCed during a code freeze.

At this point, I'm pretty paranoid about changes to the ata(4) driver
that aren't bugfixes.  We got bit rather badly for 4.6, and I'd just as
soon not inflict a similar experience on 4.7 users.  Opinions among the
REs were mixed when this issue came up a few weeks ago.

(I'd be very happy to see atapicam in 4.7-STABLE, however.)

Bruce.





msg49558/pgp0.pgp
Description: PGP signature

Re: RELENG_4

[Bruce A. Mah]

If memory serves me right, Chris Johnson wrote:
 On Sun, Aug 18, 2002 at 04:50:28PM -0300, Vitor de Matos Carvalho wrote:
  Because when it left the 4.1.1-release version turned STABLE?
 
 I may be wrong, but I believe that was before the invention of the security
 branches. 4.1.1-RELEASE was a snapshot of RELENG_4--I don't think there was a
 RELENG_4_1--but 4.6.2-RELEASE isn't. 4.6.2-RELEASE is a snapshot of the
 security branch, RELENG_4_6.

This is correct.

4.1.1-RELEASE was a look, ma, we can get rid of RSAREF snapshot of
RELENG_4.  There wasn't much QA done on that release, that's why we
erred on the side of caution in trying to put out 4.6.2-RELEASE.

Bruce.





msg48838/pgp0.pgp
Description: PGP signature

Re: read-only installworld broken?

[Bruce A. Mah]

If memory serves me right, Antoine Beaupre wrote:
 Anyone seen this?
 
 === gnu/usr.bin/perl/library/SDBM_File
 cd sdbm  make all
 rm -rf libsdbm.a
 rm: libsdbm.a: Read-only file system

The Perl build process is a little picky about timestamps on files.
I've seen this happen when I've forgotten to do adjkerntz -i before an
installworld.

Bruce.





msg48655/pgp0.pgp
Description: PGP signature

Re: ATA-Atapi read_big

[Bruce A. Mah]

If memory serves me right, John Prince wrote:

 Not wanting to resurrect a dead horse, and
 please do not refer me to the ERATTA page...
 
 Is anyone else looking/still looking into this problem?
 Is Soren back yet?

Did you see this patch posted to stable@?

Message-id: [EMAIL PROTECTED]

It was committed three days ago as rev. 1.46.2.14 of 
src/sys/dev/ata/atapi-all.c.  Does a more recent 4-STABLE build work 
for you now?

Bruce.






msg47693/pgp0.pgp
Description: PGP signature

Re: FreeBSD 4.6.1 RC1 (i386)

[Bruce A. Mah]

If memory serves me right, Murray Stokely wrote:
   4.6.1 RC1 (i386) is available now on the major FreeBSD FTP sites.
 This is currently only available for net installs.  Ports, packages,
 and documentation are not available.  An ISO image will be created for
 RC2 with full packages.  This RC was created before the OpenSSH merge
 (thanks DES!) but could still certainly use some testing of the major
 BIND update and assorted fixes to sendmail, ktrace, etc..

I should mention that the draft release notes (which weren't built for
the 4.6.1-RC1 snapshot) can be found on the RELNOTESng snapshot page.

Bruce.






msg47696/pgp0.pgp
Description: PGP signature

Re: releng_4

[Bruce A. Mah]

If memory serves me right, dnu wrote:

 I was reading about cvsup in the handbook and I'm a bit confused.  
 It said that releng_4 is the main stable branch while releng_4_6 
 is for critical fixes.
 
 So, if I cvs releng_4, do I also need to cvs releng_4_6?  

No.  You either grab one or the other.

 Or do 
 the updates to releng_4_6 also get to releng_4?

Generally yes, although there may be cases where bugfixes may be applied
in different ways.  For example, in order to handle a security issue,
RELENG_4 might receive an updated version of a program, where RELENG_4_6
might just get enough of a patch to fix whatever the problem was.

 Hmm... Correct me if I'm wrong.  Releng_4_6 is for critical fixes 
 to 4.6-release and whatever is updated there also gets to 
 releng_4 - a.k.a. 4.6-stable - am I right?

Mostly right.  I usually think of it the other way around...RELENG_4 is
a development branch and any critical security bugfixes from that branch
will be applied to RELENG_4_6, or whatever the applicable security fix 
branch is.

Note that the release notes are not updated on the security bugfix
branches (they remain the same as they were for the -RELEASE).  See src/
UPDATING on a security fix branch for a list of changes that have
been applied since the -RELEASE.

(I know this should be in the release notes somewhere...it's on my TODO
list.)

Bruce.





msg46793/pgp0.pgp
Description: PGP signature

Re: Release

[Bruce A. Mah]

If memory serves me right, Mike Grissom wrote:
 About what time is the release going to be uploaded and officially released?

Soon.  Please be patient.  :-)

The src/ tree has been tagged, but final builds take some time and
there's usually a very quick round of testing that the head release
engineer does at this point.  Then the images need to be uploaded to
ftp-master, and our policy is only make the release announcement after
at least a handful of mirrors have acknowledged receiving the
distribution.  Based on what I know of our status, I'd say it'll take
about a day or so assuming no last-minute hiccups.

Bruce.

PS.  OT note:  Slashdot jumped the gun (again) and posted a false story
about 4.6 being released.  It boggles the mind that they couldn't take
the time to verify this; a glance at the FreeBSD main Web page or a
quick email is all it takes.  What's even more unbelievable is that
they've done this for two consecutive FreeBSD releases.  Sigh.



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

Re: make release CD image question.

[Bruce A. Mah]

If memory serves me right, Matthew Dillon wrote:

 However, I was expecting to see an approximately 600MB cd image and
 all I see is:
 
 apollo:/usr/obj/release/R/cdrom# ls -la
 total 408420
 drwxr-xr-x   4 root  wheel512 Jun  7 23:13 .
 drwxr-xr-x   5 root  wheel512 Jun  7 23:11 ..
 drwxr-xr-x  21 root  wheel   1024 Jun  7 23:11 disc1
 drwxr-xr-x  15 root  wheel512 Jun  7 23:11 disc2
 -rw-r--r--   1 root  wheel  230981632 Jun  7 23:15 disc2.iso
 -rw-r--r--   1 root  wheel  187006976 Jun  7 23:13 miniinst.iso
 apollo:/usr/obj/release/R/cdrom# 
 
 Can someone tell me how to generate the approx 600MB CD image that 
 ftp2.freebsd.org has (in its case for RC2)?

The difference is that the release you generated doesn't have packages.
For the four-ISO set we do for each release, they're generated using the
package-building cluster.  If you're trying to make up something
analogous to the first CDROM, you could probably grab the packages from
an existing RC2 ISO image.

Bruce.


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

Re: Safe to use -j with 'make release' (stable) ?

[Bruce A. Mah]

If memory serves me right, Matthew Dillon wrote:
 Does anyone know if it is safe to use -j with 'make release' for
 -stable?

As of 4.4, the answer was no (because Murray listed that as future 
work in his release engineering article).

However, I've used WORLD_FLAGS in src/release/Makefile to parallelize at
least part of the process on recent 4-STABLE.

Bruce.



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

Re: -stable (as of yesterday) breaks ATAPI DVD drives?

[Bruce A. Mah]

If memory serves me right, Larry Rosenman wrote:
 On Fri, 2002-06-07 at 18:14, Brian Reichert wrote:
  On Fri, Jun 07, 2002 at 03:56:28PM -0500, Larry Rosenman wrote:
   Did you use mergmaster to update the RC scripts, etc?  If not, you
   should.  If you did, it would have asked you to run /dev/MAKEDEV since
   it changed
  
  *sigh*  No, I didn't; I was in a godawful rush... :/
  
  /me slinks back to corner, and learns to read instructions...
 No biggie.  I did ask Bruce Mah [EMAIL PROTECTED] of the RE@ team to
 update UPDATING, since I've answered this question 4-5 times. 
 
 Hopefully, it'll be committed before 4.6-RELEASE. 

Done!

Bruce.



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

Re: 4.6-RELEASE delayed

[Bruce A. Mah]

If memory serves me right, Matthias Andree wrote:

 It says ata(4) tags problems were related to motherboard-based ATA
 channels. I see that Søren's patch to fix the panic on boot that I
 observed has now been merged into 4-STABLE, however, it seems as though
 the timeout and fall-back to PIO issue is still unfixed in 4-STABLE.

This is my understanding of the state of things too.  (I haven't 
experienced this personally...I'm mostly a SCSI person.)

 My main board, a Gigabyte 7ZX-R rev. 1.0, offers four ATA channels. Two
 are driven by the south bridge, VIA KT133 (VT82C686 stuff), the other
 two are driven by a Promise PDC-20265R (in UDMA/100 mode). IIRC, this
 Promise chip is in the doesn't to tags, but freezes blacklist. VIA
 chips are not blacklisted, and AFAICS, tagged queueing not working on my
 system is a regression over 4.5-RELEASE which had working tagged
 queueing.

blacklist isn't really the right word here (it implies some 
deliberate malice).  I get your point though, you have working tagged 
queueing on 4.5 but not on 4.6.

 Søren said he was able to reproduce the timeout problem with tags, and
 we should expect a fix real soon now. This is the only list I follow,
 but I haven't yet seen anything ata-related since. What's the release
 engineering team's opinion on this ata issue? Will 4.6 be delayed until
 the tagged stuff is fixed? Will 4.6 ship with ata tagged stuff disabled
 altogether? Or will 4.6 ship with ata as it is today, with the risk that
 it breaks some systems 4.5 ata did work on?

After much discussion between soren and murray, the conclusion was that
soren probably won't be able to fix this in time for the release.  (We
offered to hold it a few days.)  So unless something miraculous happens
in the next few days, 4.6-RELEASE will ship with the ata(4) system as it
sits today.

Please note that:  ATA tagged queueing is disabled by default (you need
to enable it explicitly).  There's also only a few drives (as I
understand it) that even support this feature.  I tried to capture this
in the release notes for 4.6.  Yes, it sucks if you happen to use this
feature.

The alternative (according to soren) is to back out the entire MFC of
the ata(4) system, which means we'd lose support for new controllers,
atacontrol(8), lots of ATA raid support, and other bugfixes and features
I've lost track of.  We thought this was a lose, so we're proceeding.

Holding up the release indefinitely is not really an alternative.  Our
calendar from 2002 includes the following releases and snapshots:
4.5-RELEASE, 5.0-DP1, 4.6-RELEASE, 5.0-DP2, 4.7-RELEASE, 5.0-RELEASE.
Put another way, the same people trying to get 4.6-RELEASE out the door
now are going to try to bring the 5.0-DP2 snapshot to you twenty-six
days from today. [1]

Cheers,

Bruce.

[1] Down, not across.



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

Re: Cluster allocation errors in messages

[Bruce A. Mah]

If memory serves me right, Thomas Gravgaard wrote:
 I have been getting a massive amount of the following errors in my messages o
 ver the last couple of weeks :
 
  m_clalloc failed, consider increase NMBCLUSTERS value
  fxp0: cluster allocation failed, packet dropped!
 
 As far as I can see from the archives, the value of NMBCLUSTERS is controlled
  by the maxusers, and since this value is 0 shouldn't the NMBCLUSTERS value a
 utoscale?

By default, yes.  However, you can force a particular number of cluster
mbufs by setting NMBCLUSTERS in the kernel configuration (see the LINT
configuration file) or by setting the kern.ipc.nmbclusters loader
tunable (see /boot/defaults/loader.conf).  See tuning(7) for more
details.

Bruce.



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

Re: HEADS UP! XFree86 has been upgraded to 4.2.0 in 4.5-STABLE

[Bruce A. Mah]

If memory serves me right, Andrew Reilly wrote:
 On Tue, 2002-04-30 at 12:15, Mike Meyer wrote:
  In [EMAIL PROTECTED], Andrew Reilly areilly@b
 igpond.net.au typed:

   Second biggie: I have a Matrox MGA G200 video card that was well
   supported in earlier releases.  The new release doesn't work at all if
   compiled without the WITH_MATROX_GXX_DRIVER=yes flag in make.conf.  The
   server whinges that it can't find MGA_HAL_something.so.foo.  So,
   re-compiling with the flag set builds a server that runs, but that (my
   guess) hangs the PCI bus.  The screen goes black, a few seconds pass in
   which no input of any sort works, and then the system does a hard
   reboot.
  
  Sorry, but I can't help with that one.
 
 I tried the suggestion in another thread (Option composite_sync
 Off), but that did not seem to change anything.  I still have it in,
 since it doesn't seem to be hurting Driver vesa performance

Hmmm.  I'm typing this on a machine with a G200, on which I used
portupgrade to upgrade the components of XFree86 from 4.1.0 to 4.2.0.
I'm *not* using WITH_MATROX_GXX_DRIVER=yes.

The mga driver complained a bit about not finding mga_hal, but 
otherwise, everything came up.  As far as I can tell, I'm running the 
mga driver just fine.

If you want, I can send you my config file and a log file (by private 
email to avoid spamming the list).  I don't have much experience with 
debugging XFree86 configurations...maybe I've just gotten lucky?

Bruce.




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

Re: *** HEAD'S UP ***

[Bruce A. Mah]

If memory serves me right, Karsten W. Rohrbach wrote:

 How about a Changelog? NOTES (HEAD) and UPDATING in /usr/src are one
 way, but a semi-automatic way of making changes transparent to the
 administrator would be a good start, i think.

How is this different from the release notes?

src/release/doc/*
http://people.freebsd.org/~bmah/relnotes/

 - most important, a list of _resolved_ SAs that are in the current dist.
   in fact, i recognize this as a major point, judging from several
   threads on -hackers and -security of the last weeks. finding out what
   patch level you are on an arbitrary box would be more
   /etc/Changelog and there you go. mergemaster would display the diff
   between old and new version right when it starts, so the admin
   instantly gets an overview of what major things have changed

This information is in UPDATING.  I suppose one could make a credible
argument that it should be in the release notes for the security
branches (e.g. RELENG_4_5), but that's not the way we do things
currently.

Bruce.



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

Re: Best way to upgrade all installed ports?

[Bruce A. Mah]

If memory serves me right, [EMAIL PROTECTED] wrote:
  After cvsup'ing the ports tree, whats the best way to upgrade all
  of the installed ports?
  
  Probably involves portugrade, but I'm not certain how to use it
  for this?
  
 
 nah
 
 
 pkg_version -c  update
 vi update
 (tweak to desire)
 sh update

Please don't do this, unless you're sure you can tweak to desire all 
of the dependency information correctly.

Bruce.

PS.  I'm the original author of pkg_version.  I use portupgrade.






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

Re: we should note maxusers 0 in UPDATING

[Bruce A. Mah]

If memory serves me right, tony wrote:
 is this documented somewhere?

Release notes, tuning(7), coming soon to the Handbook I believe.

 when I left the maxusers at 0 it said
 something along the lines of max users set to 0, assuming 8 now 8 seems
 very low to me, will that in some way automatically grow during normal
 operation of the system?

It sounds like you're using an old version of config(8), you might want
to update to a newer 4-STABLE.  See the 4-STABLE release notes for a
brief description of how this feature works.

Bruce.



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

Re: 4.5-RC1: Why sshd require opie for SSH version 2?

[Bruce A. Mah]

If memory serves me right, Josh Tiefenbach wrote:
  After doing some tests, I found that connecting to this 4.5-RC1 box
  from other machine by OpenSSH (without RSA/DSA key, nor rhost*auth,
  assuming to use plain password to login), requires opie to login,
  though /etc/opiekeys, and /etc/skeykeys are both size 0. If I start
  openssh with flag '-1', which means to use OpenSSH version 1 protocol,
  it works fine: require plain password. I checked 4.4-RELEASE machine,
  and found that it works fine without '-1' flag, and even with '-2', it
  works.

[snip]

 Perhaps its an OpenSSH v3 thing? If I have some time tonite, I'll go compile
 up v3 someplace and check it out.

Did you get a chance to do this?

I'm unable to reproduce this problem between two RELENG_4 machines
running the base system OpenSSH (both machines built within the last
three days).  Usually I use a DSA keypair to authenticate, but I
temporarily blew away ~/.ssh/authorized_keys2 on the server side and ~/
.ssh/id_dsa on the client side.

Bruce.



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

Re: -stable not building ?

[Bruce A. Mah]

If memory serves me right, Joao Pedras wrote:
 Today's -stable :

[lib_baudrate.c breakage]

It's been fixed.  Re-cvsup and try again.  :-p

Bruce.



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

Re: HEADSUP: several locale renames were MFCed

[Bruce A. Mah]

If memory serves me right, Makoto Matsushita wrote:
 
 Oops, hiroo-san was already said what I have said just before:)
 
 hiroo % or in the errata?
 
 Errata is for the post-release announcement; relnotes is better IMHO.

Right.  I'm monitoring this discussion.  You might not see anything 
for a few days because I'm waiting to see how this situation resolves 
itself.

Clearly it'd be better to fix the code, if possible...we still have 
two weeks to release and we haven't even done any RC snapshots yet.

Bruce.



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

Re: Installing over nfs

[Bruce A. Mah]

If memory serves me right, Wency Arzadon wrote:

 I've been installing freebsd44 with source tree I downloaded.
 
 I know the files are compress and tar.. My question is I'm trying to 
 modify the source that gets installed especially src/etc/* files. I know
 this can be many ways, and i tried modifying src/setc.aa setc.inf, along
 with the files in ..src/etc, but its not working. 
 I'm using boot floppies, kernel, mfsroot, install.cfg, but its not
 installing the files i want, any pointers.

First, this question belongs on freebsd-questions, not freebsd-stable.

If you're installing FreeBSD on a new machine, the files from the src 
distribution are only needed or used if you want to recompile some part 
of FreeBSD later.  But they're not really a necessary part of getting 
the machine running, in the same way that the bin distribution is.

I suggest that you take a look at the Installation chapter of the 
FreeBSD handbook, which can be found on the FreeBSD Web site:

http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/install.html

If you have any questions after that, you can send them to
[EMAIL PROTECTED], but you'll need to be much more specific
as to what you're trying to do and how.  Saying it doesn't install
doesn't give people enough information to help you.

Good luck,

Bruce.





msg38413/pgp0.pgp
Description: PGP signature

Re: file broken

[Bruce A. Mah]

If memory serves me right, Sam Drinkard wrote:
 Just discovered the utility /usr/share/misc/file is either broken or has
 changed behavior.  Now, in order to determine what a file is, I must
 append the -i switch.  Did I miss or mess something up in the upgrade
 from 4.3-R to 4.4-Stable?

Errr...what utility are you running?  file(1) seems to work OK for 
me...it's been through at least one update since 4.3-RELEASE, IIRC.

nimitz:bmah% file .emacs
.emacs: Lisp/Scheme program text
nimitz:bmah% which file
/usr/bin/file
nimitz:bmah% ls /usr/share/misc/file
ls: /usr/share/misc/file: No such file or directory
nimitz:bmah% uname -a
FreeBSD nimitz.packetdesign.com 4.4-STABLE FreeBSD 4.4-STABLE #15: Mon Dec  3 16:27:53 
PST 2001 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/NIMITZ  i386

Bruce.





msg38359/pgp0.pgp
Description: PGP signature

Re: Has the size of stable /modules increased a lot lately?

[Bruce A. Mah]

If memory serves me right, Garance A Drosihn wrote:

 The file which changed was:
  src/sys/conf/Makefile.i386
 
 For the RELENG_4 branch, the significant commit was:
  1.179.2.6  done on Thu Oct 18th.

[snip]

Awesome...great explanation.  Might be a couple days until my next
release notes editing session, but I'll write something up based on what
you gave me.

Thanks much!

Bruce.





msg37514/pgp0.pgp
Description: PGP signature

Re: cvsup of ports, then what?

[Bruce A. Mah]

If memory serves me right, Mike Meyer wrote:
 H [EMAIL PROTECTED] types:
  Mike Meyer wrote:
   Ports are supposed to run on -STABLE and -CURRENT, and
   generally run on everything from that branch without to much trouble.
  I would like to see that ports are supposed to run on -RELEASE as well.
  A typical production machine follows -RELEASE (no new holy wars now
  please) but should be able to use a cvsupped ports collection to run the
  latest programs.

 My believe - and since I'm not the one doing it, take this for what
 it's worth - is that ports are tested on both -STABLE and -CURRENT,
 but not against -RELEASE. Most will work properly against -RELEASE,
 but it's not supported.

I'll go one further than that...I'll say that the *vast majority* of 
ports will work just fine on the previous -RELEASE of FreeBSD.  I don't 
know anyone who deliberately goes out of their way to make a port such 
that it *can't* be run on older -RELEASEs.

 If you're offering to provide that support, great. Start testing them
 and reporting the problems.  If not - well, there are lots of things
 that people would like to see in FreeBSD that aren't happening for
 lack of manpower.

There are some cases where this isn't going to happen.  One example
(someone correct me if I'm wrong) is emulators/linux_base-7, which, as I
understand it, *requires* additional support in Linux emulation that
only exists in -CURRENT and fairly recent 4-STABLE. (As at least one
person pointed out, 4.5-RELEASE will essentially be a future snapshot of
4-STABLE.)

Bruce.





msg37389/pgp0.pgp
Description: PGP signature

Re: cvsup of ports, then what?

[Bruce A. Mah]

If memory serves me right, Mike Meyer wrote:

 Note that pkg_version uses the INDEX file, which is in the repository
 but not get up to date. For best results, you need to do a make
 index in /usr/ports.

Quick correction here...pkg_version (for 4.3-RELEASE and newer) will use
information encoded in each port/package to help find the current
version of each port from the port's Makefile.  It only falls back to
the (slightly out-of-date) INDEX file if this fails.  You generally
don't need to do make index for pkg_version.

  Or is there something simpler that will
  know which ports I have installed and do them all together for me?  Also,
  mergemaster is a beauty when making the world - is there anything similar
  for the ports?
 
 From what I've heard, the closest thing to mergemaster is the
 portupgrade port. I personally haven't checked it out, but you might
 want to. In the base system, you can run pkg_version -c to generate
 a script - that you *must* edit by hand!! - that will safely build the
 new port and delete the old one, then install the new port.
 
 I was very careful with the phrasing of that last sentence, as the
 reason you must edit the script by hand is hiding in it.

...for which I'm very grateful.  :-)

I personally recommend using portupgrade...it does a much better job of
handling upgrades than pkg_version could ever pretend to do.  pkg_version
sucks rocks at solving the port upgrade problem because it was never
designed to handle it.

Bruce.

PS.  Mike probably knows this, but for anyone who wasn't aware, I'm the 
original author of pkg_version, so I'm entitled to make disparaging 
remarks about it.





msg37390/pgp0.pgp
Description: PGP signature

Re: cvsup of ports, then what?

[Bruce A. Mah]

If memory serves me right, Mike Meyer wrote:

 I hadn't realized that pkg_version had been updated. That's cool.
 
 Can we get make search to use it?

H.  I thought that make search essentially does its job by doing 
a grep on the INDEX file, which includes all manner of things besides 
version numbers, and does this for all ports in the ports collection 
(not just the installed ones).  pkg_version only knows how to deal with 
installed ports/packages.  So I'm not sure how this would work.

Cheers,

Bruce.





msg37392/pgp0.pgp
Description: PGP signature

Re: FYI: Sendmail 8.11.6 other apps

[Bruce A. Mah]

If memory serves me right, Kenneth Mays wrote:
 Downloaded the ISO of 4.4-PreRelease a few days ago. I was looking to
 set up Sendmail 8.11.6. Should I test any apps against 4.4-PreRelease or 
 just stick with what is on the CD?

Hi Ken--

Don't know if anyone answered this or not but...I'd say test anything
and everything you feel like.  Note that sendmail-8.11.6 got imported
into the base system after RC1.

Cheers,

Bruce.




 PGP signature

Re: The RELENG_4 (aka -stable) branch is now unfrozen

[Bruce A. Mah]

If memory serves me right, Jordan Hubbard wrote:
 No worries, it's all done, it just took me awhile to clear the haze of
 a long day from my brain and get to *all* the docs that needed
 updating. :)  You might want to check now to verify that the
 tagged files have the proper contents though.

OK, a very quick check on them looks good from here.

I think we want to put some kind of tag (maybe a datestamp) on items 
that get added to the RELENG_4_3 branch, but there's plenty of time to 
get that part figured out.

Thanks!

Bruce.

PS.  At one point you talked about jotting some of the "roll the
release" steps down in case you fall into a hole or get abducted by
aliens or something like that




 PGP signature

Re: Further question Re: cvsupped to RELENG_4 but got 4.3-RC

[Bruce A. Mah]

If memory serves me right, "Steve O'Hara-Smith" wrote:
 On Wed, 04 Apr 2001 23:49:40 -0500
 "Brian D. Woodruff" [EMAIL PROTECTED] wrote:
 
 
 BW I would rather be consistent across my servers than have some be one 
 BW release past the others.
 
   Allow me to investigate this a little further.
 
   Do you want to have all your servers running the same code or code
 with the same name ? The former can only be achieved by installing them from
 the same build (except for RELEASEs which can be exactly recreated at any
 time).

"man cvsup" and look at the description of the "date" tag in the supfile.

Bruce.



 PGP signature

Re: Different output from pkg_version

[Bruce A. Mah]

If memory serves me right, Dag-Erling Smorgrav wrote:
 Martti Kuparinen [EMAIL PROTECTED] writes:
  [...]
  The only solution for my problem might be to reinstall the port so that
  this ORIGIN-entry would be created. I haven't checked the source code
  so I'm not 100% sure but this seems right so far...
 
 Your analysis is correct. Note that bash won't work any differently if
 you reinstall it, the only difference will be that pkg_version will be
 better able to tell what version you have.

(Sorry for the late reply, I'm working through a two-week email 
backlog.)

DES is correct; the newer pkg_version (which uses the ORIGIN directive)
is better able to make a determination about what's current.
"up-to-date with index" in more recent versions of pkg_version is the
equivalent of "up-to-date" in older versions (the ones that only checked
the INDEX file).

Martti, you didn't say why this was a problem for you...or was this 
just simple curiosity?

Bruce.




 PGP signature

Re: CVS_RSH in 4.3-BETA

[Bruce A. Mah]

If memory serves me right, Kris Kennaway wrote:

 On Wed, Mar 14, 2001 at 11:00:00AM +0100, Michiel Boland wrote:

  Somewhere between 4.2 and 4.3, someone changed the default for CVS_RSH to
  'ssh'. This does not appear to be documented anywhere. The info file still
  says that 'rsh' is the default. Can the docs be fixed? Or a line added to
  RELNOTES.TXT? I'm pretty sure this is going to bite a lot of people.
 
 It should be added to RELNOTES.TXT once the relevant committer
 (preferably the person who merged the change) gets off his proverbial
 and adds it.  Can you submit a patch against the info file?

The change to RELNOTES.TXT is awaiting approval for a commit (and I 
just got approval as I was typing this).  I once thought of doing the 
info file, but I won't have time.

Bruce.



 PGP signature

Re: RELNOTES.txt Update needed

[Bruce A. Mah]

If memory serves me right, "Ken Menzel" wrote:
 Hi,   The RELNOTES.TXT file of freebsd-stable (beta) states in the
 disk section that DPT V RAID controllers are not supported,  when in
 fact they now are with the new asr0 driver (noted in HARDWARE.TXT).
 Support for DPT V, and VI as well as adaptec 2100,2200 and 2300 RAID
 cards.  Is this something that can be updated for the new release?

For what architecture?

My copy of the i386 release notes for RELENG_4 show that the DPT V and 
VI are supported, as well as the Adaptec 1400, 2100S, 3200S, and 3400S 
SCSI RAID controllers.

The alpha release notes don't reflect this because, to the best of my 
knowledge, this hardware either isn't supported or hasn't been tested.  
(Mike Smith's RAID controller page says that they're not supported.)

Does this match your view of the world, and if not, can you give me 
some more data to help me Do The Right Thing (TM)?

Thanks,

Bruce.



 PGP signature

Re: Ports updating... Good ways?

[Bruce A. Mah]

[moved to -ports]

If memory serves me right, Mike Harding wrote:
 
 Well, just to defend myself...
 
 I find that pkg_version -c is a useful tool for helping me do
 upgrades.  I do put the result in a file and do the appropriate thing.
 ^^^
That was my point.  You do *not* want to blindly execute the output of 
"pkg_version -c".

I'm about  this far away from crippling the output of "pkg_version 
-c" so that it can't be run without editing.  People don't realize how 
dangerous this is; like it can actually render a system unusable.  (I 
know, it happened to a good friend of mine.)

 I do agree that something better is needed - one issue is the way that
 the ports system tracks dependencies.  If the dependency was tracked
 in the dependent port rather than the other way around (in other
 words, the ports notes that it needs the library rather than the
 library noting that it is needed by another port) then the whole
 upgrade issue would be simpler as you could actually make multiple
 scans over the dependencies until everything was in order.  Right now
 the dependency information is 'lost' if you ugrade a library.

Yeah.  I posted a brain-dump of what I think is needed to -ports
sometime earlier this week or last week.  It's actually not that hard
now that we have the "port origin" information for installed ports.  The
hard part is dealing with all the edge cases.

I think that it would be a great project for someone to hack on 
bsd.port.mk to create a "make upgrade" target.  But it has to be 
extremely conservative in the face of pathologies.

   Also,
 say, upgrading X with the current system will cause huge amounts of
 things to be rebuilt - these ports depend on X but not the version.

I think that XFree86 is handled as a special case, but your point is 
well-taken.

Bruce.




 PGP signature

Re: Mergemaster

[Bruce A. Mah]

If memory serves me right, Kent Stewart wrote:

 whisky wrote:
  
  How does one use mergemaster correctly after a make installworld of 4.2-R t
 o
  4.x-S
 
 Very, very carefully.

That applies to pretty much any system administration task.

 It will try to change all of the configuration
 files that have been updated. If you have added local mods, they
 disappear. 

Say again?!?  Your "local mods" only disappear if you let mergemaster 
overwrite them.  It never does anything without telling you.

 I don't let it touch my firewall rules, ppp.conf, passwd,
 or groups. It will also try to change files root uses but I don't let
 it. I check when it changes my dot."*" files. If I have added local
 aliases or paths, I don't want them removed. The choices provided by
 mergemaster on them is always i(nstall new), d(elete new), or m(erge).

Have you actually tried the last of the three options?  I've found that
it works pretty well for merging in a set of local changes with a new 
version of a file.  You need to pay attention when doing the merge, 
obviously.

My advise:  Run mergemaster after an installworld.  Read the diffs it
produces. The first time you run it (on a system updated from
4.2-RELEASE) you'll probably see a lot of changes.  In general, if you
know you didn't modify a file, you can probably just let it install the
new version. Learn how sdiff works for handling merges of files, to
handle the case where you made a local modification and the original,
base file was also updated.  The first few times you do this, make sure
to have a backup of /etc so you can bail yourself out if necessary.

Bruce.




 PGP signature

No Subject

[Bruce A. Mah]

If memory serves me right, "whisky" wrote:
 Is it recommended to cvsup from 4.2-RELEASE to 4.x-STABLE
 
 Any exploits/bugs that might persuade me to defaintely do it..?

The release notes will tell you what's changed since the last release
along a branch, to within about a week.  After you grab 4-STABLE sources
to your system, read one of the following as appropriate to your
architecture:

/usr/src/release/texts/alpha/RELNOTES.TXT
/usr/src/release/texts/i386/RELNOTES.TXT

You can also browse these files in the on-line CVS repository.

Bruce.




 PGP signature

Re: Can this really be true? FreeBSD not working on IBM T20's

[Bruce A. Mah]

I'm going to try to move this to -mobile where it belongs...

If memory serves me right, Nate Williams wrote:

  As I read it, some people have had success and others haven't.  It's 
  difficult to figure out what the problem is, since there are so many 
  variables involved and the messages in the thread don't always have the 
  details needed to fully analyze the problem.
 
 I think Ken Key's experience points to it being a partitionID problem,
 since he's done the most testing.

Ken's messages indicated that he'd tested on the A21P and the T21.  In
two separate posts, he said that "we have a couple of T20s' [sic]
running FreeBSD".

I am cautiously optimistic about getting a T20 to work, based on this
info, and some email I've exchanged off-list with one of my cow-orkers.

This is what I meant by "lots of variables"...one of the problems is 
that we can't lump all of the "newer generation ThinkPads" together.

Bruce.



 PGP signature

Re: ** HEADS UP ** changes to /usr/lib/crt*.o

[Bruce A. Mah]

If memory serves me right, "David O'Brien" wrote:
 I'm about to MFC this.  Again, please run as many old apps as you can to
 see if this causes any problems.

This seems to have borken /usr/ports/security/gnupg-rsa:

bmah-freebsd-0:bmah% pkg_version.pl -v | grep gnupg
gnupg-1.0.4 =   up-to-date with port
gnupg-rsa-1.0.1_1   =   up-to-date with port
bmah-freebsd-0:bmah% gpg --version
gpg (GnuPG) 1.0.4
Copyright (C) 2000 Free Software Foundation, Inc.
This program comes with ABSOLUTELY NO WARRANTY.
This is free software, and you are welcome to redistribute it
under certain conditions. See the file COPYING for details.

Home: ~/.gnupg
Supported algorithms:
gpg: /usr/local/lib/gnupg/rndegd: not a gnupg extension: /usr/lib/libc.so.4: Undefined 
symbol "__register_frame_info"
Cipher: 3DES, CAST5, BLOWFISH, RIJNDAEL, RIJNDAEL192, RIJNDAEL256, TWOFISH
Pubkey: RSA, RSA-E, RSA-S, ELG-E, DSA, ELG
Hash: MD5, SHA1, RIPEMD160

Bruce.








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