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:  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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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"
>>> ' 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: 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: 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=8943 mtu 1500
>> ether 00:00:24:28:98:9a
>> media: Ethernet autoselect (100baseTX )
>> status: active
>> rl0: flags=8943 mtu 1500
>> options=8
>> inet 192.168.123.36 netmask 0xff00 broadcast 192.168.123.255
>> ether 00:20:ed:78:9c:a3
>> media: Ethernet autoselect (100baseTX )
>> status: active
>> lo0: flags=8049 mtu 16384
>> inet 127.0.0.1 netmask 0xff00 
>> bridge0: flags=8043 mtu 1500
>> ether ca:a9:aa:1e:71:32
>> priority 32768 hellotime 2 fwddelay 15 maxage 20
>> member: tl0 flags=3
>> member: rl0 flags=3
> 
> 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: 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: 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

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: 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

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:
>>> 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 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:
> 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: 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: 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: 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: 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: 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

[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.
--- Begin Message ---
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.34&r2=1.35&f=h

--- End Message ---


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?

I don't think so.

Bruce.



signature.asc
Description: OpenPGP digital signature

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 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: 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: ** 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

Re: Release Information

[Bruce A. Mah]

If memory serves me right, "Passki, Jonathan P" wrote:

> When does the release information on the website usually get updated
> (http://www.freebsd.org/releases/index.html)?  I've been slightly following
> the list, but I was just looking for a summary of changes and enhancements
> from 4.1.1 to 4.2.

The Web site gets regenerated periodically (once or twice per day?).  
jkh committed the change to the relevant files, but might not be 
visible for a little while.

Each release has a file named RELNOTES.TXT in its top-level directory
(e.g. on the CD-ROM, on the FTP site, etc.) that describes the changes
from the prior version.  This file contains the release notes describing
(among other things) the changes from the previous -RELEASE.

For this release, see:

ftp://ftp.freebsd.org/pub/FreeBSD/releases/i386/4.2-RELEASE/RELNOTES.TXT
ftp://ftp.freebsd.org/pub/FreeBSD/releases/alpha/4.2-RELEASE/RELNOTES.TXT

(Pick the appropriate file for your architecture.)

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: 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: 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: 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: 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: 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: pkg_version perl hacker project

[Bruce A. Mah]

If memory serves me right, Kris Kennaway wrote:

Couple o' random thoughts, don't have time to look into this myself...

> This could be done as an extension to pkg_version, since much of the
> code you will need to manage versions is already there, and it's a
> logical extension of that program's function.

Or you can use pkg_version's -t flag to help with the comparisons if 
you think running as a separate script is better.

> NetBSD have a port called audit-packages which does something similar,
> but not quite the same as the above (last I checked) -- it might still
> be useful as a starting point.

Think about where to put the parsed set of vulnerable packages.  It 
might live under /usr/ports or reside somewhere on the network.  Use 
fetch(1) to grab it from there, like pkg_version does for the INDEX 
file.

Bruce.

PS.  Jeff Kletsky, sorry I haven't looked at your dependency graphing 
tool...I'm mildly thrashing right now.  Sounds pretty neat though!



 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: 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: 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: 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: 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: 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: -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: 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: 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: 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: *** 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: 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  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: 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: 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: 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: 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: 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: 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: 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: 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: 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: -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: -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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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