Re: HEADS UP: /bin and /sbin are now dynamically linked
If memory serves me right, Bill Vermillion wrote: I don't think saving that little space on the / partition is as important as having everthing in sbin being able to stand alone no matter what is corrupted. man 8 rescue Bruce. pgp0.pgp Description: PGP signature
Re: RC1 packages
If memory serves me right, Jesse D. Guardiani wrote: If I go ahead and install 5.1-RC1 now from ISO CDROM, will I have access to packages that are newer than the ones that come with FreeBSD 5.0-RELEASE? Or will they be the same packages as 5.0-RELEASE? Or will I not have access to packages at all? (That was always the case when I would CVSUP and buildworld on our servers) You probably want to be installing 5.1-RELEASE. 5.1-RC was a release candidate, and had a few bugs that were fixed in 5.1-RELEASE. I ask because I need at LEAST XFree86 4.2.x for my laptop display to work properly with my ATI Radeon Mobility LY on my IBM Thinkpad A30p. And the last time I checked, I think 5.0-RELEASE only offered XFree86 4.1.x. And I'm not fond of compiling my x server by hand. The 5.1-RELEASE package set contains XFree86 4.3.0. The 5.0-RELEASE package set contains XFree86 4.2.1. This was mentioned in the release notes for both versions, although that was only because each version contained a more recent version of XFree86 than its predecessor. Bruce. pgp0.pgp Description: PGP signature
Re: 5.1-RELEASE TODO
If memory serves me right, Scott Long wrote: It's been a matter of not having enough time, nothing more. I *will* address this one way or another before the release. I apologize for taking so long. Scott, you're hardly the only person with the ability to test this problem. In fact, you're not even personally affected by this. So don't be too hard on yourself. Luigi, thanks for coming up with a patch...can't remember if I said that before. I'm mystified as to why nobody's stepped forward to help you test it. Bruce. pgp0.pgp Description: PGP signature
Re: adduser(8) in 5.0-R
If memory serves me right, Mike Makonnen wrote: I have cc'ed bmah, because I think it should be in the errata. Done. Thanks! Bruce. msg50715/pgp0.pgp Description: PGP signature
Re: RELENG_5 branch ?
If memory serves me right, Joao Pedras wrote: Will there be a RELENG_5 where we would get 5.0-STABLE ? Pretty much in the s ame way it has been up until now... Yes, but not right away. Please see the early adopter's guide for more on this point (it's EARLY.HTM in the top-level directory of a binary snapshot, next to the release notes and other release documents). If you can't find it, try here: http://people.freebsd.org/~bmah/relnotes/5.0-RELEASE/early-adopter.html Is this code currently tagged with RELENG_5_0 ? RELENG_5_0 is the release branch for 5.0-RELEASE. This branch has existed for about a month, and we have used it to do the release engineering activities for the (still-in-progress) 5.0-RELEASE. This is *not* the branch for 5-STABLE, which has not been created yet. Bruce. msg50402/pgp0.pgp Description: PGP signature
Re: FreeBSD 5.0 RC3 now available
If memory serves me right, Craig Reyenga wrote: No matter what, disc#1 has a finite amount of space and it's going to be impossible to come up with a combination of packages that keeps everyone happy. Sooner or later, popular comes down to somebody's judgement. To see what's currently in the package split, look at src/release/scripts/print-cdrom-packages.sh (for whatever branch interests you). Note that in addition to the packages listed there, we also need to put all of their dependencies on disc#1 as well. These dependencies likely account for a lot of the small packages and ones that are not popular seem to make in on the first CD. Looking at the script, it would appear that the current method used is simply a combination of the two different ideas. I guess now I should be saying, Please add Mozilla and Apache to the script. We've talked about adding mozilla. That will probably happen (actually, it was just added to HEAD's package split, and will probably get MFC-ed to RELENG_5_0). Haven't seen any discussion of apache, not sure why it's not there. I'm not real keen on making lots of changes to the package split at this point (if you look at where we are in the release schedule, we're *real* close to releasing). Every unnecessary change we make carries with it a certain risk that could delay the release. Hoping to forestall a flood of email to re@ saying Please add my favorite package!, let me say: The time to advocate changes is *between* releases, not when you've just seen the last RC snapshot and want the RE team to make some change in the few days before rolling the final product. We're more likely to give some actual thought to changes proposed in the early stages of the process, as opposed to near the end when it seems like we're always fighting various fires that blaze up. (FYI, the 5.0-RC3 package set occupies 339MB of a 560MB ISO image.) If the ISO is currently 560MB, then we have 90MB to spare right? Yeah, but: 1) We need to leave some space for vendors to add other stuff they might want to put on the disc. 2) Some of the packages I've seen discussed would eat up a lot of that (I have an OpenOffice package sitting on my workstation that weighs in at 66MB, not counting any dependencies it may have). FYI, my preferred window manager isn't on disc#1, nor are my preferred MUA or Web browser. But I think that disc#1 has a package set that's useful to most people. Cheers, Bruce. msg50299/pgp0.pgp Description: PGP signature
Re: FreeBSD 5.0 RC3 now available
If memory serves me right, Craig Reyenga wrote: These mentioned licensing issues make sense, however I still think that there should be some sort of system to ensure big and/or popular packages to make it to CD #1. No matter what, disc#1 has a finite amount of space and it's going to be impossible to come up with a combination of packages that keeps everyone happy. Sooner or later, popular comes down to somebody's judgement. To see what's currently in the package split, look at src/release/scripts/print-cdrom-packages.sh (for whatever branch interests you). Note that in addition to the packages listed there, we also need to put all of their dependencies on disc#1 as well. These dependencies likely account for a lot of the small packages and ones that are not popular seem to make in on the first CD. (FYI, the 5.0-RC3 package set occupies 339MB of a 560MB ISO image.) Bruce. msg50259/pgp0.pgp Description: PGP signature
Re: cvsweb
If memory serves me right, Andrew Thompson wrote: Has the cvs website stopped updating itself? http://www.freebsd.org/cgi/cvsweb.cgi/www/en/releases/5.0R/ is showing ver 1.131 of todo.sgml but http://www.freebsd.org/cgi/cvsweb.cgi/www/en/releases/5.0R/todo.sgml is showing ver 1.120 Hmmm? When I just looked, http://www.freebsd.org/cgi/cvsweb.cgi/www/en/releases/5.0R/todo.sgml showed revisions of todo.sgml up to (and including) 1.131. Bruce. msg50108/pgp0.pgp Description: PGP signature
Re: FreeBSD 5.0 RC3 now available
If memory serves me right, Andy Farkas wrote: Once again it's my pleasure to announce Release Cadidate 3 of FreeBSD 5.0. Perhaps I do things in a non-standard way, but its worked for the last 8 years from 2.x through to 4.7-stable. Firstly, I download 'floppies' and create the 2 boot disks, kern.flp and mgsroot.flp. Then I download 'bin' (now called 'base'!?) to my fileserver. Next, I boot the box with 2 the new floppies, and tell sysinstall to use 'FTP' to the fileserver URL (ftp://172.22.2.2) and install 'minimal' (in other words, just install 'bin' (now called 'base'!? - anyone remember the acronym POLA?)). ...which was documented (along with the reason why this change was made) in the release notes. :-) Cheers, Bruce. msg50115/pgp0.pgp Description: PGP signature
Re: DP2: nfsiod
If memory serves me right, Robert Watson wrote: Note that the rpc.lockd support is still experimental in 5.0 for client-side locking, and as such, might not be good to enable by default. I notice that in the original message for this thread, there's reference to release documentation indicating that client side locking isn't implemented: this is actually not the case. We do implement it now. I freely declare my ignorance about NFS locking. :-) If someone can fix up this part of the release notes to match reality, I'd be grateful. Thanks, Bruce. msg47446/pgp0.pgp Description: PGP signature
Re: HEADS UP: you need to install a new kernel before an installworld.
If memory serves me right, Doug Barton wrote: This should go on the Comprehensive guide to updating from source to 5.0 that I'm sure our trusty release engineers are producing? Some of this is described in the early adopter's guide (still a work in progress) that I committed to the release documentation set a few days ago. It refers to src/UPDATING for the source-upgrade-from-4.X steps, but several people have suggested bringing this material into the document. I'm open to that, but first: 1) I'd like the content to settle a bit first, 2) I need to find time to do this. #2 is less of an issue if someone else wants to help out. Cheers, Bruce. msg45567/pgp0.pgp Description: PGP signature
Re: 5.0-20021027-CURRENT.iso cdrom will not mount
I wrote: If memory serves me right, John wrote: How many other people are testing the 5.0 sysinstall booted from a cd and running a local (cd/dvd) install? Try booting and installing from the iso at usw2.freebsd.org and see if it works for you. I'm able to boot and install CURRENT snapshot releases I've generated locally (last was around 20021025). (My machine is a Sabre 1815, ICH2 ATA100 controller on-board, CDROM probes as SONY CD-RW CRX175E 1.0j.) I know that sam and phk were able to do test installs as well. How are you making your ISO images? I'm just doing release builds with MAKE_ISOS=YES. I don't *think* that GEOM should have any effect on creating the ISO image. I'll pull down that ISO and try it out, but it might take a little while... Hi John-- I finally got around to testing your snapshot...sorry for the delay. It stops about where you indicated in your original message (when trying to mount the CD, Error mounting /dev/acd0c on /dist: Operation not supported by device (19). You didn't answer my question, which was: How are you making your ISO images? I suspect that you're mastering the ISO images in some way *other* than the normal MAKE_ISOS=YES method. isoinfo(1) output on your disk: tomcat:cdrom% isoinfo -d -i /dev/acd0c CD-ROM is in ISO 9660 format System id: FreeBSD Volume id: FreeBSD 5.0-20021027-CURRENT Volume set id: Publisher id: The FreeBSD.Org snapshot system Data preparer id: rtp1.FreeBSD.Org Application id: FreeBSD Snap 5.0-20021027-CURRENT Copyright File id: Abstract File id: Bibliographic File id: Volume set size is: 1 Volume set seqence number is: 1 Logical block size is: 2048 Volume size is: 97840 NO Joliet present Rock Ridge signatures version 1 found isoinfo(1) output from my last snapshot (25 October): CD-ROM is in ISO 9660 format System id: FreeBSD Volume id: fbsd_miniinst Volume set id: Publisher id: Data preparer id: Application id: MKISOFS ISO 9660/HFS FILESYSTEM BUILDER CDRECORD CD-R/DVD CREATOR (C) 1993 E.YOUNGDALE (C) 1997 J.PEARSON/J.SCHILLING Copyright File id: Abstract File id: Bibliographic File id: Volume set size is: 1 Volume set seqence number is: 1 Logical block size is: 2048 Volume size is: 132576 Joliet with UCS level 3 found Rock Ridge signatures version 1 found Maybe if you build the ISOs using MAKE_ISOS=YES set in your make release, you might have better results. At least if there *is* a problem, it'd narrow down the scope a little bit. Good luck! Bruce. msg45608/pgp0.pgp Description: PGP signature
Re: 5.0-20021027-CURRENT.iso cdrom will not mount
If memory serves me right, John wrote: How many other people are testing the 5.0 sysinstall booted from a cd and running a local (cd/dvd) install? Try booting and installing from the iso at usw2.freebsd.org and see if it works for you. I'm able to boot and install CURRENT snapshot releases I've generated locally (last was around 20021025). (My machine is a Sabre 1815, ICH2 ATA100 controller on-board, CDROM probes as SONY CD-RW CRX175E 1.0j.) I know that sam and phk were able to do test installs as well. How are you making your ISO images? I'm just doing release builds with MAKE_ISOS=YES. I don't *think* that GEOM should have any effect on creating the ISO image. I'll pull down that ISO and try it out, but it might take a little while... Bruce. msg45491/pgp0.pgp Description: PGP signature
Re: Installing from CD and MAKEDEV
If memory serves me right, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Jun Kuriyama writes: At Thu, 24 Oct 2002 12:10:53 + (UTC), kuriyama wrote: I've created install CD with make iso.1 (with sources few hours before). I'm trying to install fresh current box with this CD. But I got MAKEDEV returned non-zero status dialog after extracting dists. It seems cd /dev; sh MAKEDEV all is failed at devfs environment. I found it. Phk changes in 1.297 of src/etc/Makefile not to install MAKEDEV by default. Options may be: This should be fixed now I hope. It works here. I just did a successful i386 install from CDROM. Thanks! Bruce. msg45351/pgp0.pgp Description: PGP signature
Re: 5.0-RUSH: -current install testers wanted!
If memory serves me right, The Anarcat wrote: On Tue Oct 22, 2002 at 08:33:53AM +0200, Poul-Henning Kamp wrote: [...] And I want them to do it RSN: 5.0-R is only 9 days away. [...] 9 days??? There won't be another DP? Um, not exactly. The current release date isn't until 20 November (subject to change, but that's the official word until RE says otherwise). That being said, the more testing we can get with sysinstall and fresh installations, the better. Urk. We really need to update some of the dates on the 5.0 release schedule. I'll push this during the RE telecon this week, if we don't get to it sooner. Bruce. PS. We're still trying to do DP2. Any other snapshots we release after DP2 are more likely to be release-candidate-style snapshots. msg45064/pgp0.pgp Description: PGP signature
Re: 5.0-RUSH: -current install testers wanted!
If memory serves me right, Steve Kargl wrote: I've noticed many commits on cvs-all include an Approved by: re line, but I haven't seen an official code slush/freeze announcement. Feature freeze started 16 October. New feature commits (as opposed to bugfix or doc commits) should have RE approval. Is RE going to request a code freeze around 10 Nov.? Clearly we're not adhering to the last published code-freeze date; according to that, we would have been in code-freeze for two days already. The more src-oriented members of RE are probably in a better position than I am to say when code-freeze is going to start. Bruce. msg45070/pgp0.pgp Description: PGP signature
Re: UPDATING entry needed (Re: Building KDE3)
If memory serves me right, Kris Kennaway wrote: On Tue, Oct 22, 2002 at 10:28:42PM -0700, Kris Kennaway wrote: It's already in UPDATING with the rm -rf /usr/include/g++ line in the steps for going from 4 to -current. =20 Oops, I missed this when I looked for it. Thanks. Actually, I think this is not sufficient..there will be other stale includes left around which may cause problems for compiling other things. I normally do something like: find /usr/include -ctime +1 -type f -delete To clean out stale includes after a buildworld. Perhaps something like this should be added to the end of the directions. What about rm -rf /usr/include right before the installworld? (In other words, where rm -rf /usr/include/g++ is now.) (I don't actually do this, for me it's more like cd /usr mv include include.old.) Bruce. msg45115/pgp0.pgp Description: PGP signature
Release-building saga continues
I successfully built an i386 miniinst.iso image, using a repository updated around mid-day Saturday (California time). When I burned and booted this image, I landed in sysinstall (yay!) with a dialog box complaining Couldn't create directory /tmp: Read-only file system (d'oh!). There's a number of other operations that result in the same dialog, including all of the documentation items. It's not possible to mount a fixit CDROM to investigate further because sysinstall isn't able to create the mount points. It kind of looks like the mfsroot filesystem image got mounted read-only. Is this just me? Thanks, Bruce. PS. FYI: drivers.flp has 469KB left, mfsroot.flp has 87KB left (this includes the compressed release doc files), and kern.flp has 19KB left. This predates some of the pccardd-related cleanup. msg44952/pgp0.pgp Description: PGP signature
Re: libmd bug on -CURRENT
If memory serves me right, Bruce Evans wrote: On Fri, 6 Sep 2002, Bruce A. Mah wrote: If memory serves me right, Poul-Henning Kamp wrote: Good catch. I'm surprised the compiler doesn't whine. Thanks, and me too. Warnings are mostly turned off for not unimportant places like libraries since these places are too poorly written to compile without warnings. Apparently. PS. Actually I'm surprised that nobody caught the problem in the past five months...this bug prevented release builds from 5-CURRENT hosts. Maybe I'm the only person crazy enough to try this. :-) This bug was caught in PR 42384. The fix in the PR is not so good. I suppose I didn't look hard enough when I scanned through the PR database. I'll deal with the PR. libmd is also broken for some cases involving pipes. IIRC, this is caused by the bogus st_size checks in the same function. st_size is only valid for regular files. It's puzzling that the call to lseek(2) doesn't always return an error in these cases as well (as the manpage seems to imply). Yet, one can do md5(1) on a pipe: tomcat:bmah% cat /etc/motd | md5 9caae6eae6f9c2dfea77d6a5fae2e93c tomcat:bmah% md5 /etc/motd MD5 (/etc/motd) = 9caae6eae6f9c2dfea77d6a5fae2e93c The loop in the function fails to to terminate if read() returns 0, which can probably happen if the file shrinks underneath us. Maybe add a check after the read(2), so that if it returns zero, we set n = 0? It's not clear to me what result should be returned in the case of trying to compute a checksum on a file that shrinks in the middle of the computation. Thanks, Bruce. msg42775/pgp0.pgp Description: PGP signature
libmd bug on -CURRENT
I think I've found a bug in libmd on -CURRENT, in which attempting to
compute the MD5 checksum (using MD5File(3)) of a zero-length file
generates an error. A trivial way to trigger this bug (which isn't
present in 4-STABLE) is:
ref4:bmah% uname -a
FreeBSD ref4.freebsd.org 4.7-PRERELEASE FreeBSD 4.7-PRERELEASE #8: Mon Sep 2 03:20:42
PDT 2002 [EMAIL PROTECTED]:/usr/src/sys/compile/REF4 i386
ref4:bmah% ls -ls foo
0 -rw-r--r-- 1 bmah bmah 0 Sep 6 08:54 foo
ref4:bmah% md5 foo
MD5 (foo) = d41d8cd98f00b204e9800998ecf8427e
ref5:bmah% uname -a
FreeBSD ref5.freebsd.org 5.0-CURRENT FreeBSD 5.0-CURRENT #11: Mon Sep 2 03:30:53 PDT
2002 [EMAIL PROTECTED]:/usr/src/sys/i386/compile/REF5 i386
ref5:bmah% ls -ls foo
0 -rw-r--r-- 1 bmah bmah 0 Sep 6 08:54 foo
ref5:bmah% md5 foo
md5: foo: Undefined error: 0
This bug seems to have been introduced in rev. 1.14 of src/lib/libmd/
mdXhl.c; the patch below (which makes sure a variable gets initialized
before first use, even in the case of a 0-length file) seems to fix it.
Comments?
Bruce.
PS. I found this because at some point during a release build, mtree(8)
tries to compute the MD5 checksum of a zero-length file, namely
/etc/dumpdates.
Index: mdXhl.c
===
RCS file: /usr/local/cvsroot/src/lib/libmd/mdXhl.c,v
retrieving revision 1.16
diff -u -r1.16 mdXhl.c
--- mdXhl.c 25 Mar 2002 13:50:40 - 1.16
+++ mdXhl.c 6 Sep 2002 16:02:52 -
@@ -66,6 +66,7 @@
len = stbuf.st_size - ofs;
if (lseek(f, ofs, SEEK_SET) 0) return 0;
n = len;
+i = 0;
while (n 0) {
if (n sizeof(buffer))
i = read(f, buffer, sizeof(buffer));
msg42674/pgp0.pgp
Description: PGP signature
Re: libmd bug on -CURRENT
If memory serves me right, Poul-Henning Kamp wrote: Good catch. I'm surprised the compiler doesn't whine. Thanks, and me too. Bruce. PS. Actually I'm surprised that nobody caught the problem in the past five months...this bug prevented release builds from 5-CURRENT hosts. Maybe I'm the only person crazy enough to try this. :-) msg42694/pgp0.pgp Description: PGP signature
Re: CURRENT's termcap broken
If memory serves me right, Jens Schweikhardt wrote: # Do you have time to commit mention of it to UPDATING? If so, please # draw Bruce Mah's attention to the delta so that he can steal your text # for use in the release notes. If not, I'll get around to it eventually. # :-) I just added a note to src/UPDATING. Bruce, are you listening for the release notes? 20020827: Our /etc/termcap now has all the entries from the XFree86 xterm almost unchanged. This means xterm now supports color by default. If you used TERM=xterm-color in the past you now should use TERM=xterm. (xterm-color will lead to benign warnings). I'm on it, thanks for the heads-up. Are you thinking of merging this for 4.7? Bruce. msg42272/pgp0.pgp Description: PGP signature
Re: buildworld failure in libfetch
If memory serves me right, Michael Nottebrock wrote: David Wolfskill wrote: Were you running with -j ? 'cause the error appears to be with libssl, not libfetch. Nope. I've seen this too, starting with a pristine /usr/obj and no -j option. I wonder if this has to do with the recent SSL support added to libfetch? Bruce. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Call for Review: allow sysinstall to tweak tri-value sendmail_enable
If memory serves me right, Makoto Matsushita wrote:
Following patch creates submenu to change the sendmail_enable value.
However, I don't know who want to set this variable to 'NO'. If
selecting 'YES' and 'NONE' is enough, I'll try to make another patch.
Any comments? I want to push this feature to 4.6-RELEASE...
Comments on the text only (i.e. I haven't tested the new menus)...
Bruce.
Index: menus.c
===
RCS file: /home/ncvs/src/usr.sbin/sysinstall/menus.c,v
retrieving revision 1.343
diff -u -r1.343 menus.c
--- menus.c 20 May 2002 17:08:00 - 1.343
+++ menus.c 31 May 2002 17:49:18 -
@@ -1372,11 +1372,31 @@
{ Rwhod,This machine wants to run the rwho daemon,
dmenuVarCheck, dmenuToggleVariable, NULL, rwhod_enable=YES },
{ Sendmail, This machine wants to run the sendmail daemon,
- dmenuVarCheck, dmenuToggleVariable, NULL, sendmail_enable=YES },
+ NULL, dmenuSubmenu, NULL, MenuSendmail },
{ Sshd, This machine wants to run the ssh daemon,
dmenuVarCheck, dmenuToggleVariable, NULL, sshd_enable=YES },
{ TCP Extensions, Allow RFC1323 and RFC1644 TCP extensions?,
dmenuVarCheck, dmenuToggleVariable, NULL, tcp_extensions=YES },
+ { NULL } },
+};
+
+DMenu MenuSendmail = {
+DMENU_NORMAL_TYPE | DMENU_SELECTION_RETURNS,
+Sendmail Invocation Selection,
+There are three options for invocating sendmail at startup.\n
s/invocating/invoking/
+Please select Yes if you want to use sendmail as your mail transfer\n
+agent. Selecting No disables sendmail to open network socket for\n
s/sendmail to open/sendmail's/
+incoming email, but still runs at startup. None disables sendmail\n
s/still runs at startup/still enables sendmail for outbound mail/
You will probably need to word-wrap differently after this change.
+completely at startup.,
+NULL,
+NULL,
+{
+ { Yes, Start sendmail,
+ dmenuVarCheck, dmenuSetVariable, NULL, sendmail_enable=YES },
+ { No, Start sendmail, but don't listen from network
,
+ dmenuVarCheck, dmenuSetVariable, NULL, sendmail_enable=NO },
+ { None, Don't start any sendmail processes,
+ dmenuVarCheck, dmenuSetVariable, NULL, sendmail_enable=NONE },
{ NULL } },
};
Index: sysinstall.h
===
RCS file: /home/ncvs/src/usr.sbin/sysinstall/sysinstall.h,v
retrieving revision 1.227
diff -u -r1.227 sysinstall.h
--- sysinstall.h 31 May 2002 13:38:17 - 1.227
+++ sysinstall.h 31 May 2002 17:49:19 -
@@ -407,6 +407,7 @@
extern DMenu MenuSysconsScrnmap; /* System console screenmap con
figuration menu */
extern DMenuMenuSysconsTtys;/* System console terminal t
ype menu*/
extern DMenu MenuNetworking; /* Network configuration menu
*/
+extern DMenu MenuSendmail; /* Sendmail configuration menu
*/
extern DMenu MenuInstallCustom; /* Custom Installation menu
*/
extern DMenu MenuDistributions; /* Distribution menu
*/
extern DMenu MenuDiskDevices;/* Disk type devices
*/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: pkg_version in C [was: Re: Perl scripts that need rewriting - Progress!]
If memory serves me right, Jeremy Lea wrote: On Thu, May 09, 2002 at 08:33:22PM +0100, Mark Murray wrote: /usr/sbin/pkg_version Jeremy Lea [EMAIL PROTECTED] - re OK, the first revision is attached. It appears to work for me... It needs some spit and polish, and probably a few more people to test. I've not implemented the -d flag since it sort of became unneeded, and it's not really the way things are done in the rest of pkg_*. I've also not implemented -c. There were enough warnings that it wasn't really useful, and portupgrade does a much better job... Hi Jeremy-- This looks very nice. I'll let Maxim and other ports gurus comment on the coding, and content myself with some high-level comments: 1. The version comparisons passed all of the regression tests that knu and I made for the original pkg_version (test-pkg_version.sh). This gives me a nice warm fuzzy feeling about that part of the code. 2. -c is still in the usage message, even though it's not in the code anymore (yay!). Might want to take this out. 3. The AUTHORS section in the manpage isn't marked up quite right. I'd recommend something like this: - .Sh AUTHORS The .Nm utility was written by .An Jeremy D. Lea Aq [EMAIL PROTECTED] , partially based on a Perl script written by .An Bruce A. Mah Aq [EMAIL PROTECTED] . - 4. You commented that you didn't like the way we did -s before. If you think it'd be better as (say) a regex or a globbing expression, I don't believe there'd be much problem with going that route. knu used globbing when he wrote portversion, if you want some precedent. Good job! Bruce. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
IPv6 header breakage on -CURRENT?
Hi folks--
It's been pointed out to me that a program I wrote (net/pchar in ports)
can't compile on -CURRENT. After a little poking around, I've narrowed
the problem down to the following test case:
tomcat:bmah% cat foo.cc
#include sys/types.h
#include sys/param.h
#include netdb.h
#include netinet/in.h
#include netinet/ip6.h
#include netinet/icmp6.h
int main()
{
}
tomcat:bmah% c++ foo.cc
In file included from foo.cc:7:
/usr/include/netinet/icmp6.h:168: ANSI C++ forbids data member `mld6_hdr' with same
name as enclosing class
tomcat:bmah% cp foo.cc foo.c
tomcat:bmah% cc foo.c
This shows up on 25 April -CURRENT, but not on 20 March -CURRENT or,
apparently, not what the -CURRENT ports cluster is running (5.0-DP1?).
So...is there some reason I shouldn't be able to use netinet/icmp6.h
from a C++ program, or is something broken?
Thanks!
Bruce.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: CVS Issues with branch.. Was: Re: HEADS UP: Be nice to -CURRENT ( 1 week Feature Slush )
[Trimming Cc list a little bit] If memory serves me right, Peter Wemm wrote: Actually, with my CVS hat on, I have a *huge* problem with this. In the future, if you see such huge problems come up, a little more advance notice might be nice. :-( We have a large number of temporary repo copies in place that are to be deleted (ie: rm -rf) soon. This was with the plan that there would be *NO* persistant branches and that it would be rm'ed long before the RELENG_5 branch began. Is there more to this plan? This is news to me and I would like to get up to speed. I had a quick look and I immediately found 55MB of duplicated repo files. That's over 5% of the repo right now. I want to know what expectations people have by calling this a RELENG_5_XX branch.. Given that this stuff is going to be rm'ed within a month, that will break RELENG_5_DP1 when that happens. People will no longer be able to cvsup or check out -r RELENG_5_DP1 and have it build. Specifically, gcc and gdb will not build. If this is going to be a static release (calling it RELENG_5_anything is a mistake IMHO) then this isn't a big deal. But if people are expecting it to have ongoing secirity fixes etc like we do with RELENG_4_5 etc then we have a problem, because it cannot last very long at all. Differences of opinion on naming aside...the branch isn't supposed to last long at all. The point is to provide a slightly polished snapshot to the wider developer community. We can't do the QA/releng work on HEAD without calling for a code freeze (which we early on decided that we would *not* do). Since it's not a formal release, we won't be doing security fixes, etc. I can't imagine why anyone would expect to cvsup this thing at some point in the distant future, especially after 5.0-DP2 and 5.0-RELEASE. Just thinking off the top of my head, having it break soon after 5.0-DP1 might not be fatal, as long as we have the CDROM and FTP areas still intact. Did you have a definite date for the rm-ing in mind? Thanks, Bruce. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Patch for critical_enter()/critical_exit() interrupt assem
If memory serves me right, Bruce A. Mah wrote: [snip] Disregard. I hit the wrong button in my MUA. Sorry for the spammage. Bruce. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Patch for critical_enter()/critical_exit() interrupt assem
If memory serves me right, Justin T. Gibbs wrote: : :You came to the conclusion that only *your decision* on what was :an appropriate proceedure was the one that mattered. That's not :the way this project works. You can't act unilaterally. When people :ask you to hold off (and they even asked politely!) so discussion :can take place, that is not the time to commit. I did no such thing. Let me quote you from below: So, you see, I didn't just commit it out of nowhere. I waited what I believed to be a reasonable period of time. So your oppinion on what was a reasonable period of time was the only one that mattered. Q.E.D. I came to the conclusion because not a single goddamn person bothered to read the patch and instead the only argument I got was wait for John and John's only argument is I don't like the idea of optimizing this routine right now as if he would be the only one responsible for dealing with the consequences. Actually, John's reaction to the patch is a secondary issue. He wasn't even able to read the lists when this thing blew up. He could have fallen over backward with love for your changes and you still would have strewn cuss words all over our lists. [More talk about the irrelevant contents of the patch and 40 hours of work being thrown away paranoia.] I am angry because you and a number of others are not willing to take the work at face value and instead insist on making ridiculous extremist assumption into it and then using that opinion to justify not allowing the patch to go in. How many times do I have to say this? The patch is not the issue. Most likely it will be incorperated into the tree shortly. Yawn I'm sorry Matt, but even if these changes are gold lined, it doesn't change the fact that you acted unilaterally in a manner that is not conducive to team work. That it. That's really it. Now do you want me to go chew out John too. Okay. John isn't being super professional either. The fact that you started this doesn't change that. You both have done things that you shouldn't have. Now instead of trying to convince us that you are completely without reproach, why not move forward in some constructive manner? Aren't you out of breath yet? Aren't your fingers tired of typing the same old worn out argument, My code excuses my behavior! again and again? :One week of discussion will not prevent the code from being tested. Coming on THREE weeks now. Three weeks of my time wasted arguing with people who don't even bother to take the time to understand what I am trying to accomplish... This is your choice Matt. You may not realize it, but you are in control of how long this wears on. Gee, lets see... why don't YOU ask JOHN how long he intends to wait before he allows this sort of optimization to be made? Eh? Please. Hey John. Can you comment on whatever issues you have with the content of these changes? If the API is not compatible with what you are doing, please explain why and how those conflicts might be resolved. Assuming that these issues can be addressed and the optimization can be disabled via a configuration option, what further reasons are there to not allow this change to go into the tree? :That is not how I work and I strongly oppose that kind of methodology. : :I think you've made that clear already. The question is whether you :are willing to compromise so you can be part of a team or not. That :means, for all of us, that we will not necessarily be able to work in :the way we would personally want, all of the time. That's what happens :in a group environment. That's life. This is not about being part of a team. I've played hide and seek with people that feel this way. 1, 2, 3 Seems like a reasonable amount of time to me... Ha Ha found you! You don't have to be forced into using someone else's methodology to be part of a team. No, you have to accept the team's methodology in areas that affect the team. As we say in the States, your personal liberties end where they infrindge on mine. This is no different. The CVS repository is not yours to commit to any way you like. The team has a methodology for that and as soon as that methodology is broken, we fall into situations just like this one. This IS about team work, but you are barking up the wrong tree if you think I'm the one who's not being a team player here. I know you believe this. Just as you believed you were reasonable in committing that code when you were asked not to. Just as you continue to insist that the content of your patch is the issue here. I can't convince you otherwise, but perhaps I can convince you to drop your self righteousness for a bit so we can move on? I HAVE NEVER SAID THAT THE CODE COULD NOT BE CHANGED. Hello? Are you even listening
Re: HEADS UP: DHCP 3.0.1RC6 imported
If memory serves me right, Murray Stokely wrote: DHCP 3.0.1 RC6 has been imported into -CURRENT. Cool. We're still shipping just the client part, right? Bruce. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: -current vs. -stable network performance
If memory serves me right, Matthew Dillon wrote: I've noticed that -current has much lower TCP performance. I haven't had time to investigate it but I presume there is some overhead somewhere that is killing it. Here's a data point but I'm not sure how useful it is. At the start of December I was using tcpreplay to spew packets from a stored trace into a testbed network as fast as the CPU could go, and I saw: 5-CURRENT (11/19): 9244 pps, 35.6 Mbps 4-STABLE (late November): 21827 pps, 84 Mbps These measurements were on the same machine, which is a 1.7 GHz P4, 512MB RAM, ATA disk. Network interface was a four-port dc-type card. GENERIC kernels. These are typical numbers, but fairly repeatable over various trace files I was using. At the time I was more interested in being able to get packets on the network quickly than in why there was a performance difference, so I just plopped 4-STABLE on the machine without doing any other investigation. Bruce. msg33018/pgp0.pgp Description: PGP signature
HEADS UP: Release notes reorg
The release notes for -CURRENT are a real mess. The current ordering rule is something like chronological ordering of items within a section, but keep related items together. I've just begun converting the release notes (one section at a time) to an alphabetical sorting (on manpage references, filenames, or application names, with a few exceptions). With this, we'll stand a greater chance of people actually being able to find all the release notes relating to a particular command, API, or whatever. I just committed a change for the Userland section...the rest will follow, one at a time, over the next few weeks. If you happen to be in the mood for committing release notes to a section, take a quick look to see what the current state of that section is. Note that 4.4-STABLE's release notes already have the alphabetical ordering, which I imposed after the post-4.4-RELEASE truncation of the file. Bruce. msg32475/pgp0.pgp Description: PGP signature
Re: kldxref broken, maybe?
If memory serves me right, Ruslan Ermilov wrote: On Wed, Oct 10, 2001 at 06:25:48PM +1000, Bruce Evans wrote: On Wed, 10 Oct 2001, Ruslan Ermilov wrote: I do make -CURRENT worlds every night on a -STABLE box, and the kldxref(8) miss is non-fatal: ... === wi install -c -o root -g wheel -m 555 if_wi.ko /CURRENT/boot/kernel/ kldxref /CURRENT/boot/kernel kldxref:No such file or directory *** Error code 1 (ignored) This seems to be a bug in kmod.mk :-). It intentionally ignores errors. This is not a bug, but a work-around for the above bug that klxref(8) is not a cross-tool, but should (ideally) be. OK, sounds good. Seems to me this is something that might deserve a mention in UPDATING. Something like: During a source upgrade of a 4-STABLE machine to -CURRENT, the installkernel step will attempt to execute a non-existent kldxref executable. (kldxref exists in -CURRENT, but not in 4-STABLE.) This error is non-fatal and can be ignored. Cheers, Bruce. msg32644/pgp0.pgp Description: PGP signature
Re: kldxref broken, maybe?
If memory serves me right, Ruslan Ermilov wrote: On Thu, Sep 20, 2001 at 10:19:22PM -0700, Peter Wemm wrote: Warner Losh wrote: In message p05100307b7cfef6da22f@[207.76.207.129] Mark Peek writes: : Install a -current kernel on a 4.X or pre-kldxref (before 9/10/01) : 5.X system. I sent a note to Warner mentioning he might want to put a : comment about this in UPDATING. I'm just unsure how to describe it... It is actually non-fatal. It should probably be added to the list of tools to build for making the kernel. This is not enough -- it should be made a cross-tool, much like the gensetdefs in -STABLE is. The binary format produced is MD. If we don't, we should disable it (-DNO_XREF) for cross-builds. Was there ever any resolution to this issue? I just tripped over it trying to update a 4-STABLE box to -CURRENT. (The solution I used, which was to manually install kldxref and the version of libc.so that it was linked against, probably isn't general-purpose.) Thanks, Bruce. msg32413/pgp0.pgp Description: PGP signature
Re: For your amusement..
If memory serves me right, Peter Wemm wrote: Connected to ia64.wemm.org. Escape character is '^]'. FreeBSD/ia64 (ia64.wemm.org) (ttyp0) That's totally awesome. Congratulations to all involved! Now, how long before I need to start worrying about release notes for the ia64? :-) Bruce. msg32397/pgp0.pgp Description: PGP signature
Re: HEADS UP: doc/ tree frozen (was Re: HEADS UP for /usr/src/release/doc /usr/doc)
If memory serves me right, Andrey A. Chernov wrote: On Tue, Jun 12, 2001 at 00:51:32 +0900, Motoyuki Konno wrote: o tell Nik about the change. Nik is responsible for doc/ tree. o discussion about when we do repo-copy. To minimize the side effect of the change, prior announcement (at least, to [EMAIL PROTECTED]) and discussion are very important. 1) I post HEADS UP to -doc several hours before the change happens - no one object. Let's see. You sent a heads-up to -CURRENT for /usr/src/release/doc and /usr/doc at Mon, 11 Jun 2001 03:56:50 +0400. This was the first hint that I would have had that you were going to touch RELNOTESng at all. The commit that renamed RELNOTESng happened about 2001/06/10 18:48:17 PDT. This was, er, let's see, about *two hours* later?!? No wonder no one objected...I bet you were already finished before most people read your heads-up message! Did you realistically think that a two-hour advance notice on a weekend was sufficient? 2) Peter does repo-copy as I ask. I have wrong assumption that he coordinates with Nik at this subj. doc/ and src/ is different. Renaming under doc/ is not must. All changes of such nature are not must - there are always hackarounds exists. The reason for them is to minimize constant efforts and possible confusion. There would have been less confusion if your heads-up had actually been sent with enough advance warning that people would have actually *read* it. For example, see the definition of DOC_LANG in src/release/Makefile. Did you actually look there? I already fix it for -current and plan to MFC, but stuck in current misunderstanding we discuss. You broke the overnight snapshot build of RELNOTESng for RELENG_4 (jkh just sent me the build failure report). But I see now that you've just MFC-ed something to src/release/Makefile...hope this fixes it. For the record, I'd just like to state my extreme annoyance at this lack of notification. I don't think I'm being overly demanding. It'd have been good enough for me personally if, say, two days ago, you'd sent a message to -doc saying we're going to re-do some of the I18N stuff, go read -i18n for details. Bruce. PS. And perhaps someone can tell me if these changes are going to get MFC-ed and if so, how RELNOTESng is going to get handled. Remember, it's branched, unlike doc/. PGP signature
Re: HEADS UP: doc/ tree frozen (was Re: HEADS UP for /usr/src/release/doc /usr/doc)
If memory serves me right, Andrey A. Chernov wrote: There would have been less confusion if your heads-up had actually been= =20 sent with enough advance warning that people would have actually *read*= =20 it. I agree, but just imagine that I have assumption that Peter already resolve this issue with Nick (since he do repo copy) and you'll find=20 a reason to not be extra-cautious. Gr...no, I wouldn't find a reason to not be extra-cautious. But I'm probably not going to convince you of that. You broke the overnight snapshot build of RELNOTESng for RELENG_4 (jkh=20 just sent me the build failure report). But I see now that you've just= =20 MFC-ed something to src/release/Makefile...hope this fixes it. Immediate MFC is against our policy, isn't?=20 So is immediate breakage. Tell me if there any problems appearse. RELNOTESng is broken for RELENG_4. I would have warned you about the possibility of this, if you'd bothered to ask first. PS. And perhaps someone can tell me if these changes are going to get=20 MFC-ed and if so, how RELNOTESng is going to get handled. Remember,=20 it's branched, unlike doc/. src locale rename changes not be MFC-ed, they are for 5.x branch only. Since RELNOTES branched I left to RELNOTES poeople to decide if they want to follow new names policy or not. (Bruce starts wondering why he bothered to get a haircut this weekend, because he's starting to pull his hair out now. In chunks.) Agh. Look, Andrey, *I'm* the person who designed RELNOTESng, and this is the first *I've* heard of it! :-( I'd go on, but I'm remembering a (good) rule about not fighting with other committers in public. I'll invoke this on myself now. It looks like the easiest way out of this will be to follow your new names policy on the RELENG_4 branch (at least for doc/ and src/release/ doc/). This will involve a repo-copy at the least, but I've never seen a repo-copy done for files on a branch. Please *don't* do this. Let *me* first do some *testing* first, and then ask for the repo-copy myself when I'm satisfied that it will work. Also before doing this I want to find out if nik wants to take any other actions for doc/, in case there are changes that might need to be coordinated. Bruce. PGP signature
Re: HEADS UP: doc/ tree frozen (was Re: HEADS UP for /usr/src/release/doc /usr/doc)
If memory serves me right, Andrey A. Chernov wrote: On Mon, Jun 11, 2001 at 11:42:27 -0700, Bruce A. Mah wrote: =20 Immediate MFC is against our policy, isn't?=3D20 =20 So is immediate breakage. Yes, but fixed. It's still broken. It seems that people forget that every big change means some period to settle down. I personally haven't forgotten that. But it seems that people forget that big changes require some advance notice (and testing), to reduce the amount of settling down that is required. As I mentioned in my last message, I would have gladly explained the potential problem to you, if you'd posted a heads-up message with a little advance notice. RELNOTESng is broken for RELENG_4. I would have warned you about the=20 possibility of this, if you'd bothered to ask first. How exactly it is broken? I didn't touch a bit of RELNOTES on -stable. RELNOTESng depends on part of the doc/ tree. Note that doc/ is not branched, but src/release/doc/ is. When you moved parts of the doc/ tree around in -CURRENT, you caused doc/ on -CURRENT to become inconsistent with src/ on 4-STABLE. This broke RELNOTESng on 4-STABLE. What I am saying is that it appears to me that src/release/doc/ on RELENG_4 needs to be changed to reflect the new naming scheme. It is broken now, and will not build, because of inconsistencies in naming language codes between src/ in 4-STABLE and doc/ in -CURRENT. 3) I have no opinion is it must be done in -stable too or not. Personally I not plan to touch those bits in -stable in any case, so they remain as is and can't be broken as you say unless I miss some technical details you not explain. It's broken. You missed some details. I've tried to explain it as best I can in email. As you can see by the attached output, there is a definite breakage here. Please *don't* try to fix it. Please let *me* figure out a fix and do some testing, as well as coordination with nik and the repo-meisters. Thank you. Bruce. - intruder:doc% make DOC_PREFIX=/usr/doc === en_US.ISO_8859-1 === en_US.ISO_8859-1/relnotes === en_US.ISO_8859-1/relnotes/alpha /usr/local/bin/openjade -ioutput.html -ioutput.html.images -V nochunks -V openja de -c /usr/doc/en_US.ISO_8859-1/share/sgml/catalog -c /usr/doc/share/sgml/catalo g -c /usr/local/share/sgml/docbook/dsssl/modular/catalog -c /usr/local/share/sgm l/docbook/catalog -c /usr/local/share/sgml/openjade/catalog -c /usr/users/bmah/F reeBSD/RELENG_4/release/doc/en_US.ISO_8859-1/relnotes/alpha/../../../share/sgml/ catalog -d /usr/users/bmah/FreeBSD/RELENG_4/release/doc/en_US.ISO_8859-1/relnote s/alpha/../../../en_US.ISO_8859-1/share/sgml/release.dsl -t sgml /usr/users/bmah /FreeBSD/RELENG_4/release/doc/en_US.ISO_8859-1/relnotes/alpha/article.sgml art icle.html || (rm -f article.html false) /usr/local/bin/openjade:E: cannot open /usr/doc/en_US.ISO_8859-1/share/sgml/cat alog (No such file or directory) [ad nauseum] PGP signature
Re: HEADS UP: doc/ tree frozen (was Re: HEADS UP for /usr/src/release/doc /usr/doc)
I'm going to respond to exactly one line of your email: Fix RELNOTESng affected pathes to new scheme without MFCing This is the solution I am favoring, pending some discussion with nik. Please let me deal with it. Thanks. I am deliberately *not* responding to the remainder of this message, because my doing so would most likely not lead to a productive outcome. Bruce. PGP signature
Re: anyone seen these outside of alpha? or on non-SMP?
If memory serves me right, David Wolfskill wrote: Someone should test and commit Tor's patch. I didn't have time to check whether it fixed the problems before I left (and I'm sure as hell not going to update back to -current remotely to check myself :-) FWIW, I applied that patch to the -CURRENT side of my laptop a couple of days ago. Since then, I've been able to do my daily -CURRENT builds in multi-user mode, within an X environment, using -j4 on the make buildworld step. I did the patch on one of my scratch boxes, and it's allowed me to do make release without the machine dying mid-way through. (i386, UP, GENERIC kernel, softupdates enabled on all filesystems except /, multi-user, no X). There was a bit of discussion when I reported this apparent progress to -current last week (look for a thread entitled freelist corruption: more info). Bruce. PGP signature
Re: freelist corruption: more info
I wrote: Trying to fix some make release problems, I've kept running into the same freelist corruption problems that kris and dougb experienced earlier this week. Main difference is that I notice when the box (-CURRENT from 29 May, GENERIC kernel, UP) crashes. :-p At dougb's urging, I applied Tor's patch to ffs_softdep.c. I *think* the results were positive; my machine made it through a make release apparently successfully. Got the following entries in /var/log/messages though: May 30 20:10:10 bmah-freebsd-1 /boot/kernel/kernel: handle_written_filepage: active pagedep May 31 02:18:30 bmah-freebsd-1 /boot/kernel/kernel: handle_written_filepage: active pagedep May 31 02:18:30 bmah-freebsd-1 /boot/kernel/kernel: handle_written_filepage: active pagedep I guess it should be obvious by now but I have softupdates enabled for all filesystems except for /. Thanks, Bruce. PGP signature
freelist corruption: more info
Trying to fix some make release problems, I've kept running into the same freelist corruption problems that kris and dougb experienced earlier this week. Main difference is that I notice when the box (-CURRENT from 29 May, GENERIC kernel, UP) crashes. :-p Not being a -CURRENT guru, I haven't decided if I'm going to try Tor Egge's patch or just slug it out to try to finish fixing make release (which is my main goal at this point). Just as an FYI, here's the tombstone and a stack trace in case it's useful to anyone. Cheers, Bruce. -8-8- Data modified on freelist: word 2 of object 0xc1985a00 size 52 previous type pagedep (0xd6adc0de != 0xdeadc0de) Fatal trap 12: page fault while in kernel mode fault virtual address = 0xdeadc0e8 fault code = supervisor read, page not present instruction pointer= 0x8:0xc0376ab8 stack pointer = 0x10:0xcba7fb9c frame pointer = 0x10:0xcba7fb9c code segment = base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process= 17 (swi3: cambio) kernel: type 12 trap, code=0 Stopped at worklist_remove+0x1c: cmpw$0,0xa(%ecx) db trace worklist_remove(deadc0de) at worklist_remove+0x1c free_diradd(deadc0de) at free_diradd+0x26 free_newdirblk(c1396b70) at free_newdirblk+0x32 handle_written_inodeblock(c241a300,c64135d8) at handle_written_inodeblock+0x2b2 bufdone(c64135d8,cba7ff40,c0136a1b,c64135d8,c1394400) at bufdone+0x101 bufdonebio(c64135d8) at bufdonebio+0xe dadone(c127f400,c1394400) at dadone+0x1fb camisr(c048ccd4) at camisr+0x1c5 ithread_loop(c0e48980,cba7ffa8) at ithread_loop+0x2bf fork_exit(c022c118,c0e48980,cba7ffa8) at fork_exit+0xb4 fork_trampoline() at fork_trampoline+0x8 db PGP signature
Re: make release failure
If memory serves me right, Dima Dorfman wrote:
John Hay [EMAIL PROTECTED] writes:
*** Filesystem is 1440 K, 66 left
*** 4000 bytes/inode, 116 left
cp: /usr/src/release/texts/FLOPPIES.TXT: No such file or directory
What revision of src/release/Makefile do you have? You want 1.618.
beast# fgrep '$FreeBSD' /usr/src/release/Makefile
# $FreeBSD: src/release/Makefile,v 1.618 2001/05/25 18:01:31 bmah Exp $
beast# fgrep 'texts/FLOPPIES.TXT' /usr/src/release/Makefile
@cp ${.CURDIR}/texts/FLOPPIES.TXT ${RD}/floppies/README.TXT
Mea culpa. Mea maxima culpa. :-(
Could you please try the attached, untested patch? I don't know
enough about the release build process to know if it should work, but
I guess it's worth a shot. Bruce Mah (cc'd) should know whether it's
the Right(tm) fix.
Just got back from a road trip...my brain is a little fried now.
dd is going in the right direction, but the Makefile needs to consider
if NORELNOTES is defined or not. I recommend something like the
patch appended below...also untested...I'll test this tomorrow
when I am more awake, and maybe by then I will have figured out why
this slipped through my testing.
Sorry folks...
Bruce.
Index: Makefile
===
RCS file: /home/ncvs/src/release/Makefile,v
retrieving revision 1.618
diff -u -r1.618 Makefile
--- Makefile2001/05/25 18:01:31 1.618
+++ Makefile2001/05/28 06:29:31
@@ -694,8 +694,13 @@
@sh -e ${.CURDIR}/scripts/doFS.sh ${RD}/floppies/fixit.flp ${RD} \
${MNT} ${FIXITSIZE} ${RD}/fixitfd ${FIXITINODE} ${FIXITLABEL}
# Do our last minute floppies directory setup in a convenient place.
- @cp ${.CURDIR}/texts/FLOPPIES.TXT ${RD}/floppies/README.TXT
+.if !defined(NORELNOTES)
+ @cp ${.CURDIR}/doc/${RELNOTES_LANG}/readme/article.txt \
+ ${RD}/floppies/README.TXT
@(cd ${RD}/floppies; md5 README.TXT *.flp CHECKSUM.MD5)
+.else
+ @(cd ${RD}/floppies; md5 *.flp CHECKSUM.MD5)
+.endif
touch release.9
#
PGP signature
HEADS UP: RELNOTESng now default in -CURRENT, *.TXT files removed
RELNOTESng is now the default for -CURRENT release builds. Floppy images get ASCII renderings only, while the CDROM and FTP areas get both ASCII and HTML. To disable all release note documentation building (i.e. for minimal builds), define NORELNOTES at release-building time. Note that release notes require doc building as well (it may be possible to untangle this dependency in the future). Please also note that the old *.TXT files are now gone from -CURRENT. dd did some infrastructure (currently disabled by default) to the Web site build that will make -CURRENT snapshot release notes available; we're waiting for someone like nik or wosch (hint hint, guys) to add a CVS update line to whatever magic kicks off Web site builds. Until then, renderings of the release documentation can continue to be found at: http://people.freebsd.org/~bmah/relnotes/ Thanks for everyone's help and suggestions! Bruce. PS. 4-STABLE is unaffected by these changes (for now), but it is my intent to MFC RELNOTESng after a brief shake-down period. PGP signature
Re: lock order reversals, anyone?
If memory serves me right, Matthew Jacob wrote: T-o-T about 24 hours ago: ??? lock order reversal 1st lockmgr interlock last acquired @ /usr/src/sys/kern/kern_lock.c:239 2nd 0xfe0025df8548 process lock @ /usr/src/sys/kern/kern_exit.c:542 3rd 0xfeaab8d0 lockmgr interlock @ /usr/src/sys/kern/kern_lock.c:239 acquiring duplicate lock of same type: allproc 1st @ /usr/src/sys/kern/kern_proc.c:609 2nd @ /usr/src/sys/kern/kern_proc.c:146 lock order reversal 1st vnode interlock last acquired @ /usr/src/sys/ufs/ffs/ffs_vfsops.c:397 2nd 0xfc80f218 mntvnode @ /usr/src/sys/ufs/ffs/ffs_vfsops.c:464 3rd 0xfe0026918080 vnode interlock @ /usr/src/sys/kern/vfs_subr.c:1881 I saw something similar on my 5-CURRENT box built around 27 April. No core dumps that I know of. These showed up at boot time, shortly after my machine's SCSI devices were probed. From /var/log/messages: May 2 10:18:59 bmah-freebsd-1 /boot/kernel/kernel: da0: SEAGATE ST39236LW 0004 Fixed Direct Access SCSI-3 device May 2 10:18:59 bmah-freebsd-1 /boot/kernel/kernel: da0: 80.000MB/s transfers (40.000MHz, offset 31, 16bit), Tagged Queueing Enabled May 2 10:18:59 bmah-freebsd-1 /boot/kernel/kernel: da0: 8761MB (17942584 512 byte sectors: 255H 63S/T 1116C) May 2 10:18:59 bmah-freebsd-1 /boot/kernel/kernel: lock order reversal May 2 10:18:59 bmah-freebsd-1 /boot/kernel/kernel: 1st lockmgr interlock last acquired @ /usr/src/sys/kern/kern_lock.c:239 May 2 10:18:59 bmah-freebsd-1 /boot/kernel/kernel: 2nd 0xcb64665c process lock @ /usr/src/sys/kern/kern_exit.c:542 May 2 10:18:59 bmah-freebsd-1 /boot/kernel/kernel: 3rd 0xc0e3f988 lockmgr interlock @ /usr/src/sys/kern/kern_lock.c:239 May 2 10:18:59 bmah-freebsd-1 /boot/kernel/kernel: acquiring duplicate lock of same type: allproc May 2 10:18:59 bmah-freebsd-1 /boot/kernel/kernel: 1st @ /usr/src/sys/kern/kern_proc.c:607 May 2 10:18:59 bmah-freebsd-1 /boot/kernel/kernel: 2nd @ /usr/src/sys/kern/kern_proc.c:144 May 2 10:18:59 bmah-freebsd-1 /boot/kernel/kernel: lock order reversal May 2 10:18:59 bmah-freebsd-1 /boot/kernel/kernel: 1st vnode interlock last acquired @ /usr/src/sys/kern/vfs_vnops.c:636 May 2 10:18:59 bmah-freebsd-1 /boot/kernel/kernel: 2nd 0xc050d060 mntvnode @ /usr/src/sys/ufs/ffs/ffs_vfsops.c:975 May 2 10:18:59 bmah-freebsd-1 /boot/kernel/kernel: 3rd 0xccf9c52c vnode interlock @ /usr/src/sys/ufs/ffs/ffs_vfsops.c:984 May 2 10:19:12 bmah-freebsd-1 ntpd[355]: ntpd 4.0.99b Fri Apr 27 16:43:30 PDT 2001 (1) May 2 10:19:12 bmah-freebsd-1 ntpd[355]: using kernel phase-lock loop 2040 May 2 10:19:12 bmah-freebsd-1 ntpd[355]: using kernel phase-lock loop 2041 My machine is running a GENERIC kernel. Bruce. PGP signature
Re: PATCH: partial fix for broken make release...
If memory serves me right, Terry Lambert wrote:
o The files jade_1.2.1-13.diff.gz and pdf_sec.ps are not
available from any of the listed mirros in the ports
hierarchy, so they can not be correctly installed, and
a doc build can not complete. The workaround is to
let the above fail, and then:
Yes. Ran into this when testing RELNOTESng. G.
cd ${CHROOT}/usr/ports/distfiles
GOTO=ftp://sunsite.doc.ic.ac.uk/Mirrors/FreeBSD/ports/distfiles;
fetch ${GOTO}/jade_1.2.1-13.diff.gc
s/gc/gz
fetch ${GOTO}/pdf_sec.ps
Then restart again... but this time:
make rerelease RELEASENOUPDATE=Y ...
Another way to do this is to fetch the files into /usr/ports/distfiles
and then do the release (this works for all distfiles, not just the
unfetchable ones). Part of the release process copies /usr/ports/
distfiles to ${CHROOT}/usr/ports/distfiles. In other words:
# Do this once
cd /usr/ports/distfiles
GOTO=ftp://sunsite.doc.ic.ac.uk/Mirros/FreeBSD/ports/distfiles
fetch ${GOTO}/jade_1.2.1-13.diff.gz
fetch ${GOTO}/pdf_sec.ps
# make release works normally
Cheers,
Bruce.
PGP signature
HEADS UP: RELNOTESng committed to 5-CURRENT
I've just committed RELNOTESng to 5-CURRENT. If you missed the earlier discussions on these lists, RELNOTESng is the rewrite and restructuring of FreeBSD's *.TXT documentation files into DocBook. All of the files live under src/release/doc, and src/release/doc/README has more information. As far as I know, the contents of the RELNOTESng files are up-to-date with respect to 5-CURRENT's *.TXT files. Eventually the *.TXT files will go away. There are a few outstanding issues remaining, but I decided to commit these files anyways, because having them in the repository will greatly facilitate fixing them: 1. The alpha hardware list (used to be src/release/texts/alpha/ HARDWARE.TXT) does not have all of its DocBook markup yet. 2. The hardware list generated for the alpha from the architecture-independent files is still i386-centric. It's better than the old src/release/texts/HARDWARE.TXT, but there's a lot of work left to go. Wilko Bulte and I will be working to fix this. 3. Several people have brought forth the idea to make the release notes for 5-CURRENT (and 4-STABLE, when applicable) automatically built and Web-accessible. Dima Dorfman volunteered to help make this happen. Thanks to everyone who gave comments...they were most helpful! Bruce. PGP signature
Re: [RFC] RELNOTESng for 5-CURRENT
If memory serves me right, Wilko Bulte wrote: On Wed, Apr 25, 2001 at 05:06:12PM -0600, Warner Losh wrote: In message [EMAIL PROTECTED] Antoine Beaupre (LMC) writ es: : Hey whatever. Let's just keep a rendered TXT version where it always : (ie. in the src/release... cvs) was but keep the originial as a sgml : version in the doc tree. UPDATING will continue to be a flat file, or I will no longer maintain it. Right ;-) Form follows function I thought I responded to Warner's, er, strong statement of his position, earlier, but I'm not sure. So, for the record, I *have* no intention, and never *had* any intention of touching src/UPDATING, changing its format, or even gazing wistfully in its general direction. Bruce. PGP signature
Re: [RFC] RELNOTESng for 5-CURRENT
If memory serves me right, Nik Clayton wrote:
Like it.
OK, thanks, that's a good start...
My main concern is that this is in the src/ tree. As other people
have said this is going to complicate things for src/ folks who just
want up to date release notes,
This problem (which I agree is valid) is not so much a problem as to
where the release notes live, but the fact that one needs to actually
build human-readable renderings of them. If people can't be bothered
to install the docproj port and the doc/ tree to get release notes
living in src/, putting the release notes in doc/ sure isn't going to
help. It's trivial to put the release notes for -RELEASE versions up
(the Web site does this already), and Dima thinks it's possible to do
this for -CURRENT too (and -STABLE if and when it's applicable).
and for doc/ people who might not track
-stable or -current, but who want to work on the SGML side of things.
You don't need to track -STABLE or -CURRENT to work on the docs. I run
4-STABLE on all of my machines except one, yet I routinely use those
machines to handle commits to 5-CURRENT and 3-STABLE as well:
% cd ~bmah/FreeBSD/5-CURRENT
% cvs co release
% cd ~bmah/FreeBSD/4-STABLE
% cvs co -r RELENG_4 release
% cd ~bmah/FreeBSD/3-STABLE
% cvs co -r RELENG_3 release
Putting the release notes in doc/ means that the src/ committers (who I
just *barely* got now to make changes to the release notes) are going
to have to chase through parts of the doc/ hierarchy. I'm pretty sure
I'm going to lose the few converts I've won if I let people talk me
into this.
Also, if we want to put these on the website then it means that anyone
doing so will need to have checked out www/, doc/, and src/release/
trees.
I got the impression that this would not be hard. They don't need to
have all of src/ checked out, and if enough people complain about it, we
can probably make another module which is just the RELNOTESng part of
src/release.
Could this come under doc/, and either have a CVS branch for RELENG_4
for just the release notes directory hierarchy, or I could start work on
the osrel{min,max,in} attribute support code again. . .
Can it come under doc/? Sure. Do I think it's the right thing? No.
I don't like the idea of having one part of doc/ branched and another
part not (especially when the part that's not branched lives higher in
the directory hierarchy). So if I want to work on RELENG_4's release
notes, I need to checkout HEAD's doc/ and then check out the release
note's subtree with a RELENG_4 tag.
The osrel{min,max} attributes work to a point, but they presume that
there is a total ordering on version numbers. For -RELEASEs, this just
*might* be possible. But when there's multiple development tracks going
on in parallel (and release note items appear *between* releases), this
falls apart. How do you express the idea that the fix for the
vulnerability described by a security advisory is present in
3.5-STABLE-after-2001-04-06, 4.2-STABLE-after-2001-04-06, and
5.0-CURRENT-after-2001-04-06? CVS branches (for all their shortcomings)
handle this pretty well, without the need for complex stylesheet
customizations. Let's just use the right tool for the right job.
(BTW I do want to try to use what you've done with attributes to
implement the DocBook arch= attribute, to do better multi-platform
support.)
I appreciate all the solutions people have put forth, but I think
they're solving a non-problem. If I leave the release notes in src/
(which is where they've *been* all along, I might add), it's a more
natural fit because release notes are tied to CVS branches and releases
(tags) on those branches. They live closer in the filesystem hierarchy
and, more importantly, they get exactly the same branching behavior as
the rest of src/.
Thanks,
Bruce.
PGP signature
Re: [RFC] RELNOTESng for 5-CURRENT
[Please keep me as one of the explicit recipients of this email. Thanks.] If memory serves me right, Makoto MATSUSHITA wrote: takhus Perhaps the *.TXT files could be periodically regenerated to their takhus current location to 1) avoid a POLA violation and 2) allow for at takhus least some RELNOTES without needing DocBook and doc/ (even if they takhus may be slightly out of date). [snip] It is true that current.freebsd.org and much of do-it-yourself distributions are generated with 'NODOC=YES', since it needs much time and disk spaces to process doc.1 target (especially setting up a DocBook environment). My first reaction is, is doing doc.1 *that* much of a problem? When I was testing, it didn't seem like building this consumed much time or disk space compared to the rest of the make release process (i.e. building world and several kernels). A checked-out doc/ is 37 MB. Removing *.TXT files also makes some difficulties when ordinally make buildworld/installworld users want to know what changes are made (they should change their CVSup configulation file, checkout doc if the repository is CVSuped, install DocBook via ports, and run make(1) to get a plaintext of release notes). I think the only recurring cost that people are going to have to do is to keep a reasonably current copy of doc/. Building the docproj port is a one-time operation. After that, it takes about 15 seconds of wallclock time on my workstation to build the TXT version of the release notes (note that you'll get the SGML sources automatically under src/ release/doc). Just like current 'doc' distribution of 'NODOC=YES', it would be helpful that *.TXT files are in src/release. Umm, no, it's not just like the current doc distribution. If you build a release with NODOC=YES, you don't get any rendition of the FAQ, Handbook, etc. There's no *.TXT files to fall back on. Here's my thoughts...for the record, I'm weakly opposed to regen-ing *.TXT versions: First, I don't want to bloat the repository with oodles of builds to the *.TXT files. If we do this, it ought to be be fairly infrequently, like maybe once or twice a month. Second, regen-ing needs to be done automatically. I'm not going to do it by hand. Third, let's assume that there's some interest in actually having different localized versions of the release notes (note that the infrastructure supports it). What language do we build for the *.TXT fallback files? Finally, there needs to be some boilerplate text on the fallback files to indicate the generation date of the fallback versions, and a pseudo-disclaimer that they may be out of date with respect to the actual state of the code. If we get the automatic generation problem solved, this one should be easy. Like I said, I'm weakly opposed to doing this, but I'm also quite willing to be swayed. Cheers, Bruce. PGP signature
Re: [RFC] RELNOTESng for 5-CURRENT
If memory serves me right, Wilko Bulte wrote: On Wed, Apr 25, 2001 at 09:42:07PM +0200, Leif Neland wrote: As UPDATING may contain information nessecary to run make world, it can't b e built by make world. Chicken and egg, methinks... Possibly. But I was not refering to UPDATING. Just to clarify, RELNOTESng will not have any effect whatsoever on the way that /usr/src/UPDATING is maintained. Bruce. PGP signature
Re: [RFC] RELNOTESng for 5-CURRENT
If memory serves me right, Dima Dorfman wrote: On a slightly related note, do you object, or have plans to, build the release notes with the web site? It would solve this problem very nicely. Hi Dima-- No objections, but no plans right now either. Mostly because I don't know enough about the Web site build. Got any ideas? :-) I'm not sure if it will *solve* the problem, but at least it will allevitate it somewhat. And it's aesthetically more pleasing to me (if that counts for anything). Note that this is a fairly new capability...we currently don't have a link for -CURRENT or 4-STABLE release notes. There might be some issues with this although I can't think of any off-hand. I understand that relnotes will be in src/, so this would have to be an optional part of the build, but at least having them built on www.freebsd.org would suffice. Yeah, it should be optional. The thing-that-generates-the-Web-pages would need the src/release/ module (somewhere in its filesystem, not necessarily in /usr/src/release), plus doc/. RELNOTESng doesn't need a complete src/. Bruce. PGP signature
[RFC] RELNOTESng for 5-CURRENT
(Apologies to -doc people who have probably heard this ad nauseum.) Over the past few months, I've been working on a project that I've taken to calling RELNOTESng, which is the overhaul of RELNOTES.TXT and related files that we package along with a FreeBSD distribution. I've been soliciting feedback from the other -doc folks, and it's time to socialize this out to a wider audience. The main problem this is intended to solve is that there's a lot of information in many different files, and not all of its is consistent. For example, a list of hardware supported by FreeBSD can currently be found in four different places (the alpha and i386 RELNOTES.TXT files, HARDWARE.TXT, and the Handbook). What I've done is to reorganize and reformat all of the *.TXT files. The new versions of these files are done in DocBook/SGML, which is the markup language used for the Handbook, FAQ, and so on. This gives us several distinct advantages: 1. By using conditional inclusion of text, we can have one set of source files that contains platform-independent text plus text applicable to particular architectures (no more double commits for each new release note). Looking down the road, when we support other architectures (for example, ia64 or ppc), we'll have a scalable way of handling them. 2. By going to DocBook, we can produce release notes in formats other than plain ASCII text; for example, we can do HTML or PDF. We gain greater readability, plus we can take advantages of features such as hyperlinks within documents. Of course the boot floppies still get the TXT files. 3. By adopting the same naming conventions and directory structures as the doc/ subtree, we can support translations of release notes, if the translation teams are so inclined. 4. Reorganizing the *.TXT files elminates some redundant information and reduces the number of files that people have to read through (they're a bit longer, but better-organized). There are two disadvantages to going this route. I think they're fairly minor: 1. Generating a set of release notes requires the DocBook toolchain to be built, as well as the doc/ subtree. Note that RELNOTESng will have absolutely no effect on the buildworld/installworld procedure. 2. It raises the bar a bit for committers wanting to make changes to the release notes, since they'll need to make changes to the DocBook files. Barring objections, I want to commit RELNOTESng, plus a patch to src/ release/Makefile, to the CVS tree. RELNOTESng still needs a bit of testing, and so for now, I have it controlled by a make(1) flag defaulting to off. Once the bugs have been shaken out, I'll make RELNOTESng the default and stop maintaining the *.TXT files. Eventually, the *.TXT files will get removed. There's a snapshot of RELNOTESng for -CURRENT, updated irregularly, at: http://people.freebsd.org/~bmah/relnotes/ It contains PDF, HTML, and TXT versions of the various documents, as well as a tarball of my working sources, the patch for src/release/Makefile to integrate RELNOTESng into the release build, and an ISO of a 5.0-CURRENT, i386 release I did with RELNOTESng enabled. I'd very much like to get comments from people. Bruce. PGP signature
One more typo in src/release/Makefile, rev 1.612? (w/patch)
Hi David--
Thanks for fixing the typo in src/release/Makefile. I think however the
real cause of the error that people were seeing is a typo on the line
above...there should (I think) be a " \" at the end of the previous
line. So what happens is that the "make kernel-reinstall-debug" gets
run in the wrong directory, and that's why it's falling over. Patch
below.
I'm testing this now...
Cheers,
Bruce.
Index: Makefile
===
RCS file: /home/ncvs/src/release/Makefile,v
retrieving revision 1.612
diff -u -r1.612 Makefile
--- Makefile2001/04/16 15:17:27 1.612
+++ Makefile2001/04/16 16:44:41
@@ -846,7 +846,7 @@
make ${KERNEL_FLAGS} KERNEL=${KERNEL} \
make KERNEL=${KERNEL} DESTDIR=${RD}/kernels install \
[ -r ${.CURDIR}/../sys/${MACHINE}/conf/${KERNEL}.hints ] \
- cp ${.CURDIR}/../sys/${MACHINE}/conf/${KERNEL}.hints
${RD}/kernels
+ cp ${.CURDIR}/../sys/${MACHINE}/conf/${KERNEL}.hints
+${RD}/kernels \
make KERNEL=${KERNEL} DESTDIR=${RD}/kernels
kernel-reinstall.debug
#
PGP signature
Re: Re[2]: FW: Filesystem gets a huge performance boost
If memory serves me right, David Xu wrote: [dirpref stuff] Any plan to MFC? I am interesting to see it in 4.3-RELEASE. I'm pretty sure it won't be in 4.3-RELEASE. In case you didn't realize, RELENG_4 has been in code freeze for some weeks now, preparing for a release next week. "Code freeze" means our release engineer only lets critical bugfixes (and a very few selected enhancements) into the branch pending release. The new dirpref code hasn't even lived in HEAD long enough for a MFC under "normal" circumstances. Bruce. PGP signature
Re: Call for review... PR 25577
If memory serves me right, Doug Ambrisko wrote: Brooks Davis writes: | On Mon, Apr 02, 2001 at 12:28:38PM -0700, Doug Ambrisko wrote: | Well I can't see that since it's not an array and the values come | from iterating through Cisco's API and a direct query for the | transmit key. Look at ancontrol for the ugly secret details! | | I'm pretty sure I've also managed to get it to reports things that just | plain aren't true like Bruce did. I've bitched to my Cisco rep again | to try and get better doc, but so far I haven't had much luck. I just | made a specific request for more data on setting and getting WEP keys. I'd like to complain to my Cisco rep too, oh wait, I *am* my Cisco rep. Nevermind. I'll try asking around on one of the internal mailing lists to see what I can dig up. But my plate is pretty full if I'm actually going to need to hack code on this. | In my patches, I just copied the stuff from ancontrol since that's all | we've got. The linux code is even more non-sensical then ancontrol in | that it reports five keys. Five keys...could be the new home networking stuff? FYI we've found a bug in ancontrol and the scheme for reporting keys if keys are not filled in order. It would be nice to get the source for the Linux configuration utilties that they distribute with the driver on the Cisco web site. I've tried to run it under Linux and I get "no radio found" although I can ping over the Aironet card! Linux and no source makes it hard to figure out what is happening. Can't use Linux configuration utils...I wonder if there's a minimum firmware rev on the card that you need? Bruce. PGP signature
Re: Call for review... PR 25577
If memory serves me right, Doug Ambrisko wrote: Bruce A. Mah writes: | 1. Seems like I needed to ifconfig the interface up before my other | commands would take effect. I don't recall needing to do any such | thing with the old driver before I could do ancontrol. Is this a | change in behavior or did I miss something? I fixed this and Archie put it in -current and after 4.3 goes out he should MFC it. In the interim try the patch at: http://www.ambrisko.com/doug/an.patch it has some new features such as enabling promiscuous mode from Allan Saddi! Yeah, David Wolfskill pointed this out too. Wonder why I didn't see it before...maybe something was doing an "ifconfig up" and I just didn't realize it (pccard_ether maybe?). Pass me the pointy hat. | WEP Key status: | Key 0 is set 40 bits | Key 1 is set 128 bits | Key 2 is set 40 bits | Key 3 is unset | The active transmit key is 2 | | If I had to guess, I'd say that if there is an array of WEP keys, the | programs are starting to read one key too late into the array when they | display them. There also seems to be a little disagreement as to | whether keys are numbered starting from 0 or 1. Well I can't see that since it's not an array and the values come from iterating through Cisco's API and a direct query for the transmit key. Look at ancontrol for the ugly secret details! OK. I have a question...an_readkeyinfo() seems to use the loop counter i directly in determining what key number to print out. However, the an_ltv_wepkey structure has an an_key_index member; I'm wondering if that's somehow significant, should be used, or whatever. I was thinking of having an_readkeyinfo() print this out just for kicks. No guarantees, but I'll put it on my TODO list. Note that an important difference between your laptop configuration and mine is that you are using a contiguous range of WEP keys (0 and 1) whereas I am not (0 and 2). FYI: Here's the info from Cisco's key manglement program under Win2K, the same interface as above: Current Adapter is 340 Series PCMCIA Adapter's Firmware Does Support WEP (Version V3.98) Adapter is Associated WEP is Enabled WEP Key 1 is Set (40 Bits) WEP Key 2 is Not Set WEP Key 3 is Set (128 Bits) WEP Key 4 is Not Set WEP Tx Key is Key 3 Doesn't bear much resemblance to what I showed before (the transmit key was right, but little else). Thanks, Bruce. PGP signature
Re: Call for review... PR 25577
I stupidly wrote: it is not immediately obvious to me how to set ad-hoc mode using ifconfig(8)). Please disregard...I see it now. Must be my allergy meds, yeah, that's it... :-) Bruce. PGP signature
-CURRENT breakage in usr.sbin/mptable?
Hi Bruce--
A recent commit of yours to src/usr.sbin/mptable/Makefile had the
commit message:
Fixed style bugs (use normal formatting for assignment, and don't override
the correct default for MAN1).
Are you sure this is right? The default MANSECT for src/usr.sbin is 8,
not 1, but mptable.1, well, lives in section 1.
Most importantly, it appears that this change breaks world.
I think you need to put the MAN1 assignment back, like in the diff below.
(-current folks, I'm not *trying* to do this...all I want is a fairly
recent 5-CURRENT to play with on my scratch box.)
Cheers,
(the other) Bruce.
*** mptable/Makefile2001/03/23 13:47:46 1.4
--- mptable/Makefile2001/03/23 22:11:38
***
*** 1,5
--- 1,6
# $FreeBSD: src/usr.sbin/mptable/Makefile,v 1.4 2001/03/23 13:47:46 bde Exp $
PROG= mptable
+ MAN1= ${PROG}.1
.include bsd.prog.mk
PGP signature
CURRENT breakage in usr.sbin/amd/mk-amd-map
This is a first for me, I think...finding a CURRENT buildworld bogon. Freshly cvsup-ed -CURRENT system, trying to buildworld: [much output] === usr.sbin/amd/mk-amd-map make: don't know how to make .o. Stop *** Error code 2 Stop in /usr/src/usr.sbin/amd. *** Error code 1 Stop in /usr/src/usr.sbin. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. Diffs show that someone was perhaps a little overzealous in a manpage-related cleanup: bmah-freebsd-1:mk-amd-map% cvs -R diff -r1.10 -r1.11 Makefile Index: Makefile === RCS file: /cvsroot/src/usr.sbin/amd/mk-amd-map/Makefile,v retrieving revision 1.10 retrieving revision 1.11 diff -r1.10 -r1.11 6c6 # $FreeBSD: src/usr.sbin/amd/mk-amd-map/Makefile,v 1.10 1999/08/28 01:15:18 peter Exp $ --- # $FreeBSD: src/usr.sbin/amd/mk-amd-map/Makefile,v 1.11 2001/03/20 18:16:16 ru Exp $ 12,14d11 MAN8= mk-amd-map.8 SRCS= mk-amd-map.c Fix looks easy to me (put the SRCS= line back) but I'm a little commit-shy for the src/ tree. Someone want to do this, or give me a go-ahead? I'm re-doing a buildworld with a patched Makefile now. Thanks, Bruce. PGP signature
Re: CURRENT breakage in usr.sbin/amd/mk-amd-map
If memory serves me right, "Michael C . Wu" wrote:
cvs diff: Diffing .
Index: Makefile
===
RCS file: /home/ncvs/src/usr.sbin/amd/mk-amd-map/Makefile,v
retrieving revision 1.11
diff -u -r1.11 Makefile
--- Makefile2001/03/20 18:16:16 1.11
+++ Makefile2001/03/20 21:37:46
@@ -8,6 +8,10 @@
.PATH: ${.CURDIR}/../../../contrib/amd/mk-amd-map
+MAN8= mk-amd-map.8
+
+SRCS= mk-amd-map.c
+
PROG= mk-amd-map
.include bsd.prog.mk
That reverts all of Ruslan's change. You don't want to put the MAN8=
definition back, because that was the point of his commit. Just the
SRCS= needs to be reverted.
Now Ruslan (or someone) needs to go and fix all of these files too:
src/usr.sbin/amd/wire-test/Makefile
src/usr.sbin/ancontrol/Makefile
src/usr.sbin/usbdevs/Makefile
src/usr.sbin/wicontrol/Makefile
src/usr.sbin/wlconfig/Makefile
There may be others, these were just selected files that I checked
(buildworld found the first one for me).
I'm definitely not going to get my -CURRENT machine rebuilt today. :-p
Bruce.
PGP signature
Re: CURRENT breakage in usr.sbin/amd/mk-amd-map
If memory serves me right, "Michael C . Wu" wrote: On Tue, Mar 20, 2001 at 04:13:17PM -0600, Michael C . Wu scribbled: | On Tue, Mar 20, 2001 at 02:03:29PM -0800, Bruce A. Mah scribbled: I have just finished making the patch to fix this problem. I will start the buildworld now. In the mean time, if someone has a fast box, please test the patch at http://people.freebsd.org/~keichii/fix-current-broken-man-build.diff I just finished a buildworld (but can't do an installworld...I'm 30 miles from the console), all seems well with the diffs. Thanks much for generating the patch. I normally don't like leaving other people to clean up problems I find, but almost anyone would be able to do it faster than me, at the moment. Cheers, Bruce. PGP signature
Re: CURRENT breakage in usr.sbin/amd/mk-amd-map
If memory serves me right, Peter Wemm wrote: "Michael C . Wu" wrote: On Tue, Mar 20, 2001 at 04:13:17PM -0600, Michael C . Wu scribbled: | On Tue, Mar 20, 2001 at 02:03:29PM -0800, Bruce A. Mah scribbled: I have just finished making the patch to fix this problem. I will start the buildworld now. In the mean time, if someone has a fast box, please test the patch at http://people.freebsd.org/~keichii/fix-current-broken-man-build.diff I kinda object to backing this stuff out. The problem is elsewhere. This stuff builds correctly on its own, it is something wrong with the world environment. eg: do a 'make install' in src/share/mk and the world works fine. Since this seems to be needed, the problem is in 'world', not these makefiles. Huh?!? Ruslan's commit was intended to remove (most of the) MAN8= definitions in certain Makefiles. That's great. Unfortunately, in some cases, he also removed SRCS= definitions, which is not so good inasmuch as it breaks buildworld. Either he deleted too much out of the Makefiles, or the SRCS= removal was intentional and should have been documented in the commit message (as far as I can tell this has *nothing* to do with manpages). Michael's patch (which unbreaks buildworld) only backs out the SRCS= changes. Feel free to hand me a giant clue if I'm missing something really obvious. In other words, is world *supposed* to build in the absence of SRCS= definitions? Bruce. PGP signature
Re: CURRENT breakage in usr.sbin/amd/mk-amd-map
If memory serves me right, Peter Wemm wrote:
If SRCS is undefined, then SRCS=${PROG}.c. ie:
peter@daintree[7:30pm]~src/usr.sbin/sicontrol-283 grep SRCS Makefile
peter@daintree[7:30pm]~src/usr.sbin/sicontrol-284 make -V SRCS
sicontrol.c
peter@daintree[7:30pm]~src/usr.sbin/sicontrol-285 make -V PROG
sicontrol
Adding back SRCS=prog.c explicitly is not the solution. It is just hiding
a problem elsewhere.
[snip]
Thanks for the clue. I learned something new today. (Unfortunately,
not enough to fix the problem, but I bet one of you -CURRENT gods can
come up with a fix.)
Cheers,
Bruce.
PGP signature
Re: pkg_update
If memory serves me right, Nik Clayton wrote: On Wed, Feb 07, 2001 at 08:23:35PM -0600, Michael C . Wu wrote: On Thu, Feb 08, 2001 at 01:56:11AM +0100, Leif Neland scribbled: | It seems pkg_update is only usable when installing from packages, not fro m | ports. Because it is a package update system. If you want to update from the ports, use 'pkg_version -c |sh' Never, ever, *ever* do this. "pkg_version -c" is a hack to make cut-n-paste easier. The output is sorted alphabetically and no notice is taken of dependencies between different ports. Plus it's been known to wipe out Ports Upgrade kits. This was particularly bad when some upgrade kits replaced little non-essentials like ld*.so, things like that. I just put a big fat warning to this effect followed by "exit 1" at the start of the commands output, and committed to -CURRENT. I'll MFC early next week. Bruce. PGP signature
Re: pkg_update
[moved to -ports] If memory serves me right, "Leif Neland" wrote: Couldn't it be made possible to use just the update-of-dependencies part of p kg_update without doing the pkg_delete/pkg_install bit? Perhaps I'll try... Manipulating the bits is relatively straightforward. Doing so in a meaningful way, and being able to cover all the edge cases, that's quite hard (as I've just re-learned). If you browse through the archives of -ports for the last few days, you'll get an idea of some of the problems. Every few months, the topic comes up, and discussion is just tapering off from the last round. Not to say you shouldn't work on this problem...just saying that it's not quite as straightforward as most people (myself included) think when they first tackle it. Cheers, Bruce. PGP signature
Re: sysinstall.8 Breaking buildworld
If memory serves me right, "Crist J. Clark" wrote: I had some buildworld failures earlier this week. In src/share/man/man8 the Makefile includes code to get the sysinstall.8 manpage. Since the manpage lives in src/release, this requires that you CVSup src-release. I had not been. This broke buildworld which had worked in the past. sysinstall.8 is the only file in src-release that is required for a buildworld. It seems somewhat silly to me that you are required to grab the whole thing for that one file. OK...I was one of the people who (indirectly) pushed for this. In a nutshell, I (and, independently, several other people) noticed that the sysinstall(8) manpage never gets installed as a part of the binary distributions or by an installworld. (I got highly confused by this while rewriting some other parts of the documentation.) The solution was to make sure that an installworld installs this manpage. I made the change to the Makefile which makes sysinstall.8 and src-release optional. I included it in a reply to the PR that precipitated the change, http://www.FreeBSD.org/cgi/query-pr.cgi?pr=19818 My personal opinion is that sysinstall.8 is a part of the base system and shouldn't be optional. If we take your suggestion, it means that installworld will sometimes install this manpage and sometimes it won't. A good counter-argument is that installworld doesn't touch /stand/sysinstall, and therefore shouldn't touch the manpage either. Idea: Maybe we need the release building process to do this instead? On all of my systems, the sysinstall binary came from a CD, and never got touched by any subsequent installworlds. Anyone have a good reason why everyone _must_ have src-release to buildworld? I never thought of trying to do a buildworld with anything less than src-all. I guess my counter question is: Anyone have a good reason to do buildworlds *without* /usr/src/release/? Bruce. PGP signature
Re: Current-ISO
If memory serves me right, "Sidwell, Josh" wrote: I have been unsucessfully trying to build an ISO image of the 5.0-CURRENT branch for the past several weeks. Is anyone aware of a tool to pull the latest tree and turn it into an ISO image? http://www.freebsd.org/FAQ/hackers.html#CUSTREL Bruce. PGP signature
Re: sysinstall.8 Breaking buildworld
If memory serves me right, Ben Smithurst wrote: yeah, but it can be used as many things. If invoked as "rm" sysinstall behaves just like the real rm, it happens to be one big binary. The thing in /stand is a crunchgen(8) binary. sysinstall itself is (chug, chug) 850K. After being stripped, it's 798K: 1616 -rwxr-xr-x 1 root wheel 817416 Jan 11 14:14 sysinstall Bruce. PGP signature
Re: Other Linux stuff...
If memory serves me right, Marcel Moolenaar wrote: So, from a pure ELF layout point of view, both shared objects and executables are the same. But a shared library is not guaranteed to be executable. Allowing shared objects to be executed is in violation with the specs: This may be a really stupid question, but what on Earth do they gain by allowing the execution of shared object files? Bruce. PGP signature
Re: feature set for 5.0
If memory serves me right, David Lebel wrote:
I'm currently using the -STABLE branch of FreeBSD, and I'm wondering if there
is a page somewhere that lists the feature set planned for 5.0 when it is
released? How will it compare to the current 4.x branch ?
It's really hard to predict the future like that. :-)
If you want to know the state of 5-CURRENT right now, that's what
src/release/texts/{i386,alpha}/RELNOTES.TXT is for. (Modulo the fact that
someone, quite possibly me, needs to make some updates to this file to
sync it to reality.)
Bruce.
PGP signature
Re: SCSI DAT tape question
If memory serves me right, "Robert Small" wrote: I'm running an adaptec controller (1542CF) with a Sony SDT-5000. I'm running: reeBSD (5.0-2511-CURRENT FreeBSD 5.0-2511-CURRENT #4: Thu Jul 6 20:31:41 CDT 2000) When I issue the command "camcontrol eject sa0" I receive: Error received from stop unit command When I issue the command "camcontrol stop sa0" I receive" Error received from stop unit command I can boot the system into Windows or System Commander and eject the tape using the eject button. Any ideas? Is there some reason why "mt -f /dev/nsa0 offline" won't do what you want? Bruce. PGP signature
Re: Check for ports updates
If memory serves me right, Thomas Schuerger wrote: Is there already a tool that checks the installed ports for available updates in /usr/ports? I've written such a tool, which seems to work fine already. Anyone interested? pkg_version(1) Ah, haven't seen that before. The output of pkg_version is very canonical, but not very readable for humans. And it's slower than my version... ;-) Without having looked at ports_updates yet, let me just mention that: 1. If you want human-readable output, try "pkg_version -v". Maybe that should have been a default; certainly I always run it that way. But in the case that a program was going to postprocess the output, I didn't want it to have to wade through a bunch of pretty-printing stuff to get the results it needed. 2. When I was writing pkg_version, speed wasn't exactly a big priority to me, since pretty much *anything* was faster than what I was doing. Bruce. PS. I've been really bad about ignoring suggestions for pkg_version, mostly because it does everything I need/want it to do right now. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Header includes and defines in freebsd 4-Stable [ISC-Bugs#102] (bind9)
If memory serves me right, Visigoth wrote: It seems that there may be a small socket implementation issue with freebsd 4-Stable. I have been in disscussion with a few people from the isc bind 9 bug tracking department, and it seems that for the macro CMSG_NXTHDR to function in freebsd , the macro ALIGN must be defined. We went through this exact same issue about six weeks ago, the problem being that pchar (a network measurement utility I wrote) needed the CMSG_* macros and started failing to build under 4.0-CURRENT. (I needed these macros for IPv6.) I lost track of the discussion for several reasons, but you can check the -current mailing list archives (look for CMSG_NXTHDR or some such thing like this). According to a very quick perusal of the CVS repository, it hasn't been solved yet. (i.e. FreeBSD still requires sys/param.h for CMSG_* to work properly.) Yoshinobu Inoue [EMAIL PROTECTED] is probably the best person to ask for more information on this. Bruce. PGP signature
Re: 'machine/param.h' required for 'sys/socket.h'
If memory serves me right, Yoshinobu Inoue wrote: 'sys/scocket.h' header file start using ALIGN macro defined in 'machine/param.h' header file while the man page for "socket" only mentioned 'sys/types.h' as the prerequisite for 'sys/socket.h'. As a result the 'net/pchar' port is now broken. Yes, this problem is already found by Bruce A. Mah and some mail is exchanged between related people. I'm doing a pointrev to pchar to "fix" this problem...see below. What must be done to solve this ? Is it possible to '#include sys/param.h' in 'sys/socket.h' OR the man page must be corrected to explicitly state 'param.h' (sys/ or machine/ ?) as the prerequisite to 'sys/socket.h' and all the programms using it patched accordingly ? As itojun's experience, including machine/param.h in socket.h also cause problems in some other apps. I feel requesting inclusion of machine/param.h for any apps which use socket is better. But if there are any other smarter solution, please let me know and I'll appreciate it much. Just speaking as the slightly whiny developer of pchar: What bothers me is that out of all the platforms where pchar can do IPv6 support, recent FreeBSD versions seem the *only* case where I need to include machine/ param.h in order to use the CMSG* macros. This means that FreeBSD is forcing me to make some code changes that aren't required for *any* other platform. According to itojun's earlier mail, I can't just blindly include machine/param.h either. So I need to figure out at compile-time or configure-time whether or not I need machine/param.h. Personally, I think this is a lose. Unfortunately I don't have any better suggestion than "back out your last commit". In the specific case of pchar, I need to make code changes in order to work with 4.0-RELEASE, now that it's been shipped with the header files as we've discussed. So I wrote a bunch of autoconf code to detect this breakage and fix it. I'll probably roll in some Solaris fixes also and call this pchar-1.1.2 or something like that. Bruce. PGP signature
Re: FDDI cards in -current
If memory serves me right, Christoph Kukulies wrote: Planning a router between FDDI and Fast Ethernet I'm wondering if I'm on the safe side when using FreeBSD 4.0-current for this project rather than being more conservative and use an older version of the OS. You mean 4.0-stable, right? :-) My really touchy-feely opinion is that either way is probably going to be fine, but my machines are research platforms, not production routers. What FDDI cards could be recommended? (There aren't many, though, I believe). Here's what's supported: fpa(4), fea(4) - Device Drivers for DEC FDDI Controllers fpa is a PCI card, fea is EISA. Bruce. PGP signature
Re: ipv6 and rc.conf questions
If memory serves me right, Yoshinobu Inoue wrote: And now I think the problem is that entry name, rtadvd_enable="NO" is not intuitive for users. So how about changing the name to something like, ipv6_to_be_defaultrouter="NO" and if it is set to YES, then rc.network6 invoke rtadvd (and possibly do other works)? Please give me comments if it seems reasonable or not, and also if the name is good or bad. I think that I know just enough about IPv6 to be dangerous, at this point. With that in mind, I think we should keep the name (because that describes exactly what it does), and just change the default to "YES". Cheers, Bruce. PGP signature
Re: IPv6: can a link-site (or global) address be configured in rc.conf?
If memory serves me right, "Jose M. Alcaide" wrote: Now that I have several machines running FreeBSD 4.0, I started to play with IPv6. It's fun! I have plans to set up a v6-over-v4 tunnel and connect to the 6Bone. I read /usr/share/examples/IPv6/USAGE, /usr/share/doc/IPv6/IMPLEMENTATION and some documents at the KAME web site. However, I still have to figure out how to assign a not-link-local address (i.e., a site or global address) to the [unique] Ethernet interface of each host in an automatic manner (from /etc/rc.conf). After reading /etc/rc.network6 I concluded that no addresses apart from the link-local ones are assigned to the interfaces. I am using ifconfig manually to do this (BTW, I found that there is no need to specify "alias"). /etc/rc.network6 assumes that you'll get your non-link-local address(es) from your router(s) using rtsol(8). The router, in turn, needs to be running something like rtadvd(8). I am new to IPv6, so maybe I am asking for something with no sense... IPv6 autoconfiguration is very roughly analogous to using DHCP in the IPv4 world. (It's not exactly the same though. In fact, there exists a DHCP for IPv6.) Hope this helps, Bruce. PGP signature
Re: ssh strangeness in -current...
If memory serves me right, David Malone wrote: On Mon, Mar 06, 2000 at 01:32:00PM -0700, Warner Losh wrote: : + Openssh isn't 100% compatible with ssh, so some care needs to : + be taken in its operation. : : This sounds bad. Are you referring to the -o syntax differences, or actua l : incompatabilities? There have been unsubstantiated reports of : interoperability problems, but nothing well documented here. I'm talking about the -o syntax difference specifically. How does the following sound? [SNIP] + Openssh's command line parsing isn't 100% compatible with ssh, + so some care needs to be taken in its operation. I'd leave it saying that it isn't 100% compatible - it may sound bad but it's true. There are several other things that aren't the same: default options are different, some options have been removed (AllowHosts is one that I know of), it produces warning messages where the old ssh wouldn't have. I'm sure there are other differences too. Rather than let the users guess at various incompatabilities (imagined and real), why not give them a few examples, as in your (David's) last message? "Care needs to be taken when converting from ssh to OpenSSH. OpenSSH's command-line parsing isn't 100% compatible with ssh, some of the default options have been changed, some options (such as AllowHosts) have been removed, and it produces a few more warning messages than ssh." Bruce. PGP signature
Re: IPv6
If memory serves me right, Yoshinobu Inoue wrote: I ran across a few problems after I remade world. The new scoped address syntax breaks /etc/rc.network6. In particular, some lines that look like: Sorry not to announce it yet, but scoped addr format will still change, like below. addr%scope I'll send another mail to describe it in next to this mail. OK, got it. Some of the breakage went away, in that it looks like all of the invocations to route(8) are now well-formed. This is a Good Thing (TM). When this change happens, those problems will be resolved. Well...not quite, and I am not sure why. Following is a snippit of the bootup messages from a CURRENT machine (approximately -2220): dc0: starting DAD for fe80:0001::0200:f8ff:fe10:6ef3 dc0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 inet 146.246.243.57 netmask 0xff00 broadcast 146.246.243.255 inet6 fe80::200:f8ff:fe10:6ef3%dc0 prefixlen 64 tentative ether 00:00:f8:10:6e:f3 media: 100baseTX status: active supported media: autoselect 100baseTX full-duplex 100baseTX 10baseT/UT P full-duplex 10baseT/UTP 100baseTX hw-loopback none lo0: flags=8049UP,LOOPBACK,RUNNING,MULTICAST mtu 16384 inet6 fe80::1%lo0 prefixlen 64 inet6 ::1 prefixlen 128 inet 127.0.0.1 netmask 0xff00 add net default: gateway 146.246.243.254 Additional routing options: TCP keepalive=YES. routing daemons:. Doing IPv6 network setup:route: writing to routing socket: Network is unreachable add net fe80::: gateway fe80::1%lo0: Network is unreachable route: writing to routing socket: Network is unreachable add net ff02::: gateway fe80::1%lo0: Network is unreachable add net :::0.0.0.0: gateway ::1 add net ::0.0.0.0: gateway ::1 net.inet6.ip6.forwarding: 0 - 0 net.inet6.ip6.accept_rtadv: 0 - 1 dc0: DAD complete for fe80:0001::0200:f8ff:fe10:6ef3 - no duplicates found dc0: starting DAD for 3ffe:0780:0060:0001:0200:f8ff:fe10:6ef3 dc0: DAD complete for 3ffe:0780:0060:0001:0200:f8ff:fe10:6ef3 - no duplicates found . (Note the error messages from route(8) about mid-way through.) This output was produced from the last version of scripts you posted to -current, and with the only relevent change I made to /etc/rc.conf was to set ipv6_enable="YES". After *completing* a multiuser boot, attempting to set the default scoped route correctly installed an entry in the routing table, using exactly the same command that /etc/rc.network6 would have generated: /sbin/route add -inet6 fe80:: fe80::1%lo0 -prefixlen 10 -interface \ -cloning I was wondering if there was somehow a race condition with the first DAD for dc0 not completing, but I put a long sleep at the start of network6_pass1() and it didn't seem to help. Finally, could you say whether or not lo0 should really be the default value for ipv6_default_interface in /etc/defaults/rc.conf? I have this vague feeling it's wrong but I don't know enough to say why: +ipv6_default_interface="lo0" # Default output interface for scoped a ddrs. Maybe your concern is that packets to the default interface should be sent out to outside of host, at least? I think that's it, yes. On the other hand, I thought there should be some default interface by default, but I afraid that an approach of just choosing some interface as default interface might be end up to choose non working interface. But now I feel choosing lo0 approach is also somewhat strange. So I'll try following approach. -"ipv6_default_interface" is empty by default -When all of "ipv6_network_interfaces", "gif_interfaces", and "ipv6_default_interface" are empty, then there will be no default interface -When "ipv6_default_interface" are empty but "ipv6_network_interfaces" and/or "gif_interfaces" is not empty, then choose one default interface from there. I like your approach, although I admit that I'm learning much of this as we go along. Small nitpick: You might want to move the line for ipv6_default_interface higher in /etc/defaults/rc.conf so that it is just below the rest of the definitions that begin with ipv6_*. Thanks! Bruce. PGP signature
Re: IPv6
The only changes I have for you are small typos... /etc/rc.conf: "assigne router prefix" should be: "assign router prefix" /etc/rc.network6: "if you instead want to route such packets to a "default" interface": Looks to me like this comment is not applicable anymore. "Enable Router Renumbering, unicaset case" should be: "Enable Router Renumbering, unicast case" Unfortunately I can't give you any good comments about functionality...I want to do a buildworld/installworld on my test box to pick up all of the changes regarding scoped addresses...I'm doing a cvs update now to bring the sources over. Once I'm back up and running, I'll let you know how it works for me. Thanks! Bruce. PGP signature
Re: IPv6
If memory serves me right, Ollivier Robert wrote: Please use consistent names like "mroute6d_flags" and "mroute6d_program". Thanks...these changes will be reflected in the next version I post. For your information, I didn't use different naming conventions just for the hell of it...I just neglected to convert all of the names from the KAME version of the script to use the rc.conf conventions. Bruce. PGP signature
Re: IPv6
If memory serves me right, Kurt Bauer wrote: could you please tell me how to configure a IPv6 only Interface. I want the Interface to fetch its prefix from a Router. But the Interface only gets a Link-Local address when I make a 'ifconfig vx0 up'. I worked fine with 3.3 and KAME, but as is seems, there is no more /usr/local/v6. So where are all the configuration files for IPv6 ??? I ran into this "problem" last week when I first brought up a -CURRENT machine and wanted to play with IPv6. My workaround was to grab the script /usr/local/v6/etc/rc.net6 from my 3.4-RELEASE+KAME box, tweak it suitably, and then make sure that it got called from /etc/rc.local. The two tweaks I remember off-hand was that the paths to commands are (of course) different under a 4.0-CURRENT environment and that ndp in -CURRENT works a little different than in the KAME snapshots I was using earlier. It seems to me that most of the functionality of rc.net6 could be folded into /etc/network. I've thought of writing up patches for this, but I'm not sure when the IPv6 initialization should take place with respect to the IPv4 interface configuration, starting up of daemons, setting of various syctls, etc. (Also, there's some new variables that should be defined in /etc/defaults/rc.conf.) Bruce. PGP signature
Re: IPv6
If memory serves me right, Yoshinobu Inoue wrote: The two tweaks I remember off-hand was that the paths to commands are (of course) different under a 4.0-CURRENT environment and that ndp in -CURRENT works a little different than in the KAME snapshots I was using earlier. What point is different for ndp? At least in the snapshot I have, ndp in KAME takes -I to show/specify an interface for the default route. ndp in 4.0-CURRENT doesn't have this option. I don't know how crucial this is. It seems to me that most of the functionality of rc.net6 could be folded into /etc/network. I've thought of writing up patches for this, but I'm not sure when the IPv6 initialization should take place with respect to the IPv4 interface configuration, starting up of daemons, setting of various syctls, etc. (Also, there's some new variables that should be defined in /etc/defaults/rc.conf.) In KAME environment, IPv6 related configurations are done at last of rc.conf. So it is at almost end of configuration. I don't know if still such kind of change is permitted to commit or not, but if you try to make some initial patch for it, I think that is anyway good start and very helpful. OK, I'll see what I can do. This will be a good way to force me to learn how rc.net6 works... Even if this doesn't make it past the code freeze, we'll have it for later. (I think a good case could be made for this, considering that right now starting up IPv6 isn't exactly intuitive.) Bruce. PGP signature
Re: IPv6
If memory serves me right, Yoshinobu Inoue wrote:
In KAME environment, IPv6 related configurations are done at
last of rc.conf. So it is at almost end of configuration.
It turns out this won't work real well, because if I do this, then
inetd gets started before we start up the IPv6 interfaces, which is
bad for any IPv6 services to get started from inetd.
I don't know if still such kind of change is permitted to
commit or not, but if you try to make some initial patch for
it, I think that is anyway good start and very helpful.
OK, I've attached the results of a few hours of hacking. There's a
diff for /etc/defaults/rc.conf, a diff for /etc/rc, and a new
/etc/rc.net6 file all attached here. The /etc/rc.net6 file is a
modified version of /usr/local/v6/etc/rc.net6 from the KAME
distribution. Patches are all against 4.0-CURRENT, as of the middle of
last week.
I haven't really tested it very well (in particular, the router-specific
code is completely untested, because, well I don't really have the
ability at the moment). Comments welcome, or if one of the KAME team
members with commit privileges wants to fix it up and/or try to get
this code commited, that's fine too.
Cheers,
Bruce.
*** /etc/rc Mon Feb 7 14:53:30 2000
--- /etc/rc.distMon Feb 7 14:47:44 2000
***
*** 191,205
network_pass1
fi
- case ${ipv6_enable} in
- [Yy][Ee][Ss])
- if [ -r /etc/rc.net6 ]; then
- . /etc/rc.net6 # We only need to do this once also.
- net6_pass1
- fi
- ;;
- esac
-
# Mount NFS filesystems.
echo -n "Mounting NFS file systems"
mount -a -t nfs
--- 191,196
*** /etc/defaults/rc.conf.dist Mon Feb 7 13:42:45 2000
--- /etc/defaults/rc.conf Mon Feb 7 14:55:23 2000
***
*** 183,188
--- 183,199
### Miscellaneous network options: ###
icmp_bmcastecho="NO" # respond to broadcast ping packets
+ ### IPv6 options: ###
+ ipv6_enable="NO" # Set to YES to set up for IPv6.
+ ipv6_network_interfaces="auto"# List of network interfaces (or "auto").
+ ipv6_gateway="NO" # Set to YES if this host will be a gateway.
+ route6d_enable="NO" # Set to YES to enable an IPv6 routing daemon.
+ route6d="/usr/sbin/route6d" # Name of IPv6 routing daemon.
+ route6dflags="" # Flags to IPv6 routing daemon.
+ mroute6d_enable="NO" # Do IPv6 multicast routing.
+ mroute6d="/usr/sbin/pim6dd" # Name of IPv6 multicast routing daemon.
+ mroute6dflags="" # Flags to IPv6 multicast routing daemon.
+ gifs="NO" # List of GIF tunnels (or "NO").
##
### System console options #
#! /bin/sh
# $FreeBSD$
# Note that almost all of the user-configurable behavior is no longer in
# this file, but rather in /etc/defaults/rc.conf. Please check that file
# first before contemplating any changes here. If you do need to change
# this file for some reason, we would like to know about it.
# IPv6 startup
net6_pass1() {
echo -n 'Doing IPv6 network setup:'
if [ X"${ipv6_gateway}" = X"YES" ]; then
#
# list of interfaces, and prefix for interfaces
# NOTE: no trailing double colon necessary here!
#
case ${ipv6_network_interfaces} in
[Aa][Uu][Tt][Oo])
ipv6_network_interfaces="`ifconfig -l`"
;;
esac
# ipv6_network_interfaces="ed0 ep0"
# prefix_ed0="fec0:::0001"
# prefix_ep0="fec0:::0002"
#
# list of outer ip addresses for gif.
#
# gifs="gif0 gif1"
# gifconfig_gif0="10.1.1.1 10.1.2.1"
# gifconfig_gif1="10.1.1.2 10.1.2.2"
else
#
# manual configurations - in case ip6router=NO
# you can configure only single interface, as specification assumes
that
# autoconfigured host has single interface only.
#
case ${ipv6_network_interfaces} in
[Aa][Uu][Tt][Oo])
ipv6_network_interfaces="`ifconfig -l | sed -e 's/ .*//'`"
;;
esac
fi
# tool locations
prefixconfig=/usr/sbin/prefix
rtsol=/sbin/rtsol
gifconfig=/usr/sbin/gifconfig
route=/sbin/route
ndp=/usr/sbin/ndp
# just to make sure
ifconfig lo0 up
#determine the "default interface" used below
if [ X"$defaultiface" = X"" ]; then
for i in $ipv6_network_interfaces; do # use 1st interface in the list
Re: UPDATING
If memory serves me right, Ruslan Ermilov wrote: On Wed, Feb 02, 2000 at 10:53:49AM -0500, Jim Bloom wrote: Ruslan Ermilov wrote: On Tue, Feb 01, 2000 at 02:51:11PM -0500, Jim Bloom wrote: I did the following and it worked for me: cd /usr/src make buildworld make installworld cd /usr/src/usr.bin/xinstall make install cd /usr/src make installworld The first make installworld terminates with an errors, but the second o n goes through. It can't be true! Nope, I'm pretty sure that is exactly what I did. After the first `make installworld' fails, we will have: 1) a new `libutil' without string_to_flags() 2) an old `libc' without setflags() 3) an old /usr/bin/install with string_to_flags() linked against libutil. I believe the new libc has been installed as well. My first installworld got an error while trying to install rcp. I believe this is the first program that uses any flags to install. Once you get to this point, all of the libraries have been installed. Yeah, just figured this myself, but one thing I still don't understand is how the new libc.so.4 gets installed on the first pass? The problem is that it is declared as PRECIOUSLIB in libc/Makefile, this will result in -fschg passed to install. Do you have a log from the first failed installworld? This is my first attempt at building world (starting from the 2127 snapshot, then cvsup-ing src-all and cvs-crypto this morning, California time), but I had a slightly different experience. make buildworld completed without errors, then I did a make installworld which failed (no setflags) when trying to install libcrypto. I did a make -k installworld, which of course finished, but the make installworld I did afterwards (no -k) failed in the same place. After having read through the last few messages on -current, I went to the source directory for libc and tried doing a make install there. It failed (also because of a lack of setflags). Then I went to the obj directory for libc and executed the install command for libc manually (but without the -fschg argument): install -c -o root -g wheel -m 444 libc.so.4 /usr/lib A make installworld just finished without errors. Hopefully this is useful information, and won't add to any of the confusion. Bruce. (who's now wishing he kept slightly better written records of what he's doing) PGP signature
