Re: make includes

[Bruce Evans]

On Tue, 14 May 2002, David O'Brien wrote:

> On Wed, May 15, 2002 at 12:38:49PM +1000, Bruce Evans wrote:
> > > I really do not like this change, please return things such that the
> > > long-ingraned "cd /usr/src ; make includes".
> >
> > I planned to fix this by changing "make includes" to print
> > "Unwarranted chumminess with implementation".
>
> What is your perfered way to get the results of
> (cd /usr/src ; make includes) ?

I prefer not to do this.  There are simpler methods to get broken
headers, starting with rm -rf :).  I prefer everyone to use (documented)
user-level targets like "world" and "install" for installing includes,
since it would be difficult to make the includes target safe for general
use.  I don't know what it really useful for.

Bruce


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

Re: make includes

[Ruslan Ermilov]

On Tue, May 14, 2002 at 12:18:14PM -0700, David O'Brien wrote:
> On Tue, May 14, 2002 at 04:10:51PM +0300, Ruslan Ermilov wrote:
> > > Why change in the first place?
> > > 
> > > What was wrong with 'make includes'? Why break POLA?
> > > 
> > They were broken.  See commit log for share/mk/bsd.incs.mk,v 1.1 for
> > a full story.
> 
> I fail to see how they were broken from the rev 1.1 bsd.incs.mk log.
> 
Please read it more carefully.  (Hint: not all includes have been
installed).

> It looks like you just hyjacked the `includes' target.  Why could you not
> have used `incbuild' and `incinstall'?  Then includes is something like
> 
> includes: incbuild incinstall
> 
Actually, from what I've read, I plan on renaming these targets to
buildincludes and installincludes, and restoring the `includes' to
mean build + install.  I will do the same for all-man, maninstall
(buildmanpages, installmanpages, manpages = build + install), etc.
all would mean build* (build everything), and install = install*
(similarly install everything).  This would bring us the consistency
in standard targets names, so that one doesn't need to remember
that to all-man is build manpages, and includes - to build includes,
and "files" (when we have bsd.files.mk) to build files.


Cheers,
-- 
Ruslan Ermilov  Sysadmin and DBA,
[EMAIL PROTECTED]   Sunbay Software AG,
[EMAIL PROTECTED]  FreeBSD committer,
+380.652.512.251Simferopol, Ukraine

http://www.FreeBSD.org  The Power To Serve
http://www.oracle.com   Enabling The Information Age



msg38359/pgp0.pgp
Description: PGP signature

Re: make includes

[Ruslan Ermilov]

On Tue, May 14, 2002 at 06:43:01AM +, Hiten Pandya wrote:
> --- Ruslan Ermilov <[EMAIL PROTECTED]> wrote:
> > People might want to use it like that:
> > 
> > make world
> > mv /usr/include /usr/include.old
> 
> Sorry to butt in; but wouldn't it be more good if this step was done
> by the build scripts itself? (refering to: mv /usr/include /usr/include.old)
> 
> > make incsinstall
> 
Nope.  Some of us have custom stuff in /usr/include, and we can't force
everyone to "fix" it by moving it under /usr/local/include.


Cheers,
-- 
Ruslan Ermilov  Sysadmin and DBA,
[EMAIL PROTECTED]   Sunbay Software AG,
[EMAIL PROTECTED]  FreeBSD committer,
+380.652.512.251Simferopol, Ukraine

http://www.FreeBSD.org  The Power To Serve
http://www.oracle.com   Enabling The Information Age



msg38360/pgp0.pgp
Description: PGP signature

Re: Is current 'safe' to play in again [post GCC changes/stability]

[John Hay]

> Fwiw, with tonight's -current I am seeing
> 
> cc -O -pipe -march=pentiumpro -ffreestanding -DCOMPORT=0x3f8 -DCOMSPEED=9600
> -DTERM_EMU -I/disk0/usr/src/sys/boot/i386/libi386/../../common
> -I/disk0/usr/src/sys/boot/i386/libi386/../btx/lib
> -I/disk0/usr/src/sys/boot/i386/libi386/../../../contrib/dev/acpica
> -I/disk0/usr/src/sys/boot/i386/libi386/../../.. -I.
> -I/disk0/usr/src/sys/boot/i386/libi386/../../../../lib/libstand/
> -ffreestanding -mpreferred-stack-boundary=2  -c
> /disk0/usr/src/sys/boot/i386/libi386/bioscd.c -o bioscd.o
> /disk0/usr/src/sys/boot/i386/libi386/bioscd.c: In function `bc_strategy':
> /disk0/usr/src/sys/boot/i386/libi386/bioscd.c:237: `DEV_BSIZE' undeclared
> (first use in this function)
> /disk0/usr/src/sys/boot/i386/libi386/bioscd.c:237: (Each undeclared identifier
> is reported only once
> /disk0/usr/src/sys/boot/i386/libi386/bioscd.c:237: for each function it
> appears in.)
> *** Error code 1
> 
> Stop in /disk0/usr/src/sys/boot/i386/libi386.
> *** Error code 1
> 

I think changing '#include ' to '#include '
should be enough. DEV_BSIZE moved to sys/param.h, but it looks like it
wasn't "make world" tested. :-(

John
-- 
John Hay -- [EMAIL PROTECTED] / [EMAIL PROTECTED]

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

Re: [PATCH] cross-arch bootstrapping is broken by GCC 3.1

[David O'Brien]

On Wed, May 15, 2002 at 09:31:11AM +0300, Ruslan Ermilov wrote:
> I insist we should officially support upgrading from X.any to X+1.0-R,
> minimally.

You need to either get concensis from arch@ or core@ then.


> This actually doesn't affect only cross-arch case, the subject is wrong.
> It affects any arch with HOST_BITS_PER_WIDE_INT > HOST_BITS_PER_LONG e.g.
> alpha.  Forget about 4.x for a moment and imagine you have a pre-atoll(3)
> 5.0-CURRENT alpha (atoll(3) was committed on 2001/11/28).

If this is true, then I agree we have a problem.  I'll look into it.

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

Re: [PATCH] cross-arch bootstrapping is broken by GCC 3.1

[Ruslan Ermilov]

On Tue, May 14, 2002 at 09:07:05PM -0700, David O'Brien wrote:
> On Wed, May 15, 2002 at 01:16:23PM +1000, Bruce Evans wrote:
> > > > 4.x i386 and old 5.0 i386 can no longer produce current 5.0 alpha
> > > > worlds due to the lack of atoll(3) in libc.  This patch fixes it:
> > >
> > > Considering how simple src/lib/libc/stdlib/atoll.c is; lets ask RE for a
> > > MFC.
> > 
> > That wouldn't actually fix the problem, since it would only help for
> > bootstrapping 5.0 from very recent versions of 4.x.
> 
> Personally I do not mind requiring latest 4-STABLE to build -CURRENT
> (either for cross or simple `world').  I think that is all we can
> officially support.  I know RU wants to be able to upgrade from say 4.1 to
> 5-CURRENT.  I think that is a nice thing; but if it is going to be a
> requirement it should become an officially stated one.
> 
I'm not only "wanting" it, this was implemented and just possible with
2.95 in the tree, and it becomes possible with this patch again.  (There
are some not yet fixed unrelated problems in make(1) that prevent 4.0
to upgrade (non-cross) to anything later, but the fix is simple, and
I'm going to commit it later today.)

I insist we should officially support upgrading from X.any to X+1.0-R,
minimally.  I will try to find some time this week to make sure we can
still upgrade from 4.x to 4.6, before we roll it.  (Didn't check it
for a long time, and this occasionally gets broken.)

> The only fix is to import all of libiberty and create a config.h that
> implies Version 7.
> 
The only correct fix would be to have an ability to create config.h on
the fly, for the host environment.

> > The problem is the usual one with committing files generated by
> > autoconfig.
> 
> It would be the same problem without autoconf, the code could have been
> written only the the 5-CURRENT API.
> 
> > This gives a configuration that might only be valid for the host
> > machine that ran autoconfig.  Cross-compiling of even portable
> > cross-compile-aware sources like gcc is broken by this.
> 
> I personally believe we should build GCC in the normal manner, but this
> is no longer my decision to make.
> 
This actually doesn't affect only cross-arch case, the subject is wrong.
It affects any arch with HOST_BITS_PER_WIDE_INT > HOST_BITS_PER_LONG e.g.
alpha.  Forget about 4.x for a moment and imagine you have a pre-atoll(3)
5.0-CURRENT alpha (atoll(3) was committed on 2001/11/28).  A non-cross
upgrading from it is broken too without this patch.  (Please see
contrib/gcc/read-rtl.c for where atoll(3) is actually used.)


Cheers,
-- 
Ruslan Ermilov  Sysadmin and DBA,
[EMAIL PROTECTED]   Sunbay Software AG,
[EMAIL PROTECTED]  FreeBSD committer,
+380.652.512.251Simferopol, Ukraine

http://www.FreeBSD.org  The Power To Serve
http://www.oracle.com   Enabling The Information Age



msg38356/pgp0.pgp
Description: PGP signature

Re: Is current 'safe' to play in again [post GCC changes/stability]

[Jos Backus]

Fwiw, with tonight's -current I am seeing

cc -O -pipe -march=pentiumpro -ffreestanding -DCOMPORT=0x3f8 -DCOMSPEED=9600
-DTERM_EMU -I/disk0/usr/src/sys/boot/i386/libi386/../../common
-I/disk0/usr/src/sys/boot/i386/libi386/../btx/lib
-I/disk0/usr/src/sys/boot/i386/libi386/../../../contrib/dev/acpica
-I/disk0/usr/src/sys/boot/i386/libi386/../../.. -I.
-I/disk0/usr/src/sys/boot/i386/libi386/../../../../lib/libstand/
-ffreestanding -mpreferred-stack-boundary=2  -c
/disk0/usr/src/sys/boot/i386/libi386/bioscd.c -o bioscd.o
/disk0/usr/src/sys/boot/i386/libi386/bioscd.c: In function `bc_strategy':
/disk0/usr/src/sys/boot/i386/libi386/bioscd.c:237: `DEV_BSIZE' undeclared
(first use in this function)
/disk0/usr/src/sys/boot/i386/libi386/bioscd.c:237: (Each undeclared identifier
is reported only once
/disk0/usr/src/sys/boot/i386/libi386/bioscd.c:237: for each function it
appears in.)
*** Error code 1

Stop in /disk0/usr/src/sys/boot/i386/libi386.
*** Error code 1

-- 
Jos Backus _/  _/_/_/Santa Clara, CA
  _/  _/   _/
 _/  _/_/_/ 
_/  _/  _/_/
[EMAIL PROTECTED] _/_/   _/_/_/use Std::Disclaimer;

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

Is current 'safe' to play in again [post GCC changes/stability]

[ggm]

I held of renewing my make buildworld/installworld state pending the GCC
commit.

Can I get the sense of the current-users community if its safe to put the toe
back in the water? Are there one-time or other headaches one can expect from
GCC .so or other objects (the runtime loader/link library handlers?) changing?

cheers
-George


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

Re: [PATCH] cross-arch bootstrapping is broken by GCC 3.1

[Terry Lambert]

David O'Brien wrote:
> Personally I do not mind requiring latest 4-STABLE to build -CURRENT
> (either for cross or simple `world').  I think that is all we can
> officially support.  I know RU wants to be able to upgrade from say 4.1 to
> 5-CURRENT.  I think that is a nice thing; but if it is going to be a
> requirement it should become an officially stated one.

I'm actually with RU on cross-building.  Crossbuilding is right
next door to porting, and it finds compilation/link platform
portability problems for things like Alpha and SPARC on x86
boxes, which is all to the good.

I'm all for the minimum build requirement being Xenix 2.2 or
VMS 3.4.  8-).


> The only fix is to import all of libiberty and create a config.h that
> implies Version 7.

It's annoying.  But I think that this annoyance comes from
automake/autoconf, and it's not ever going to get better,
since these programs don't make software portable, they aid in
porting software, which is a very different thing, and grossly
inferior to other approaches (e.g "imake" and "xmkmf" out of
X11 out of Project Athena out of MIT).


> > The problem is the usual one with committing files generated by
> > autoconfig.
> 
> It would be the same problem without autoconf, the code could have been
> written only the the 5-CURRENT API.

The GNU tools have never been very cross-friendly, except in
single instances.  Very much unlike the NCR tools, which would
let you specify target in the Makefiles.  8-(.


> > This gives a configuration that might only be valid for the host
> > machine that ran autoconfig.  Cross-compiling of even portable
> > cross-compile-aware sources like gcc is broken by this.
> 
> I personally believe we should build GCC in the normal manner, but this
> is no longer my decision to make.

FWIW, I think that building things in the normal manner is the
way to go; that's why I occasionally (one or two times a year) take
passes through ports, clean up the easy patches (the ones that don't
result in the code being FreeBSD specific instead of Linux specific),
and send them back to the various project maintainers.

Integrating actively maintained code into the project, not on a
vendor branch (a vendor branch is the best we can do with the tools
we have, since CVSup can't update to a vendor branch from a remote
primary archive), is really evil, as we can see with the fun with
sendmail, ssh, SSL, and the resolver library, among others.

Archie and Julian can probably provide a lot of information on
how to deal with vendor code as external modules, with version
tagging to allow "stickiness" in the build process.

Doing it that way, though, is a trade-off, since it means active
access to a CVS archive during the build process itself, rather
than just to get a code cut.  No CVS is also possible (a code cut
from a checked out archive with a "make checkout" run to get the
modules).  It may not be worth it, depending on your point of view.

I don't know if Julian and Archie have postable copies of the
Whistle/IBM InterJet .mk files, or if they would have to be recreated
for legal reasons, but it's a nice framework: the Makefile is responsible
for checking out the un-config'ed sources, and running the "configure"
with the set of options listed in the Makefile.

For things like "bind", this would including patching the two
non-overridable paths in the FreeBSD Make template files, as
distributed with bind itself, etc..  I'm sure there would be
other similar local hacks, but they could be seconded back to
the original code maintainers, like most people try to do with
ports these days.

-- Terry

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

Re: make includes

[David O'Brien]

On Wed, May 15, 2002 at 12:38:49PM +1000, Bruce Evans wrote:
> > I really do not like this change, please return things such that the
> > long-ingraned "cd /usr/src ; make includes".
> 
> I planned to fix this by changing "make includes" to print
> "Unwarranted chumminess with implementation".

What is your perfered way to get the results of
(cd /usr/src ; make includes) ?

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

Re: [PATCH] cross-arch bootstrapping is broken by GCC 3.1

[David O'Brien]

On Wed, May 15, 2002 at 01:16:23PM +1000, Bruce Evans wrote:
> > > 4.x i386 and old 5.0 i386 can no longer produce current 5.0 alpha
> > > worlds due to the lack of atoll(3) in libc.  This patch fixes it:
> >
> > Considering how simple src/lib/libc/stdlib/atoll.c is; lets ask RE for a
> > MFC.
> 
> That wouldn't actually fix the problem, since it would only help for
> bootstrapping 5.0 from very recent versions of 4.x.

Personally I do not mind requiring latest 4-STABLE to build -CURRENT
(either for cross or simple `world').  I think that is all we can
officially support.  I know RU wants to be able to upgrade from say 4.1 to
5-CURRENT.  I think that is a nice thing; but if it is going to be a
requirement it should become an officially stated one.

The only fix is to import all of libiberty and create a config.h that
implies Version 7.

> The problem is the usual one with committing files generated by
> autoconfig.

It would be the same problem without autoconf, the code could have been
written only the the 5-CURRENT API.

> This gives a configuration that might only be valid for the host
> machine that ran autoconfig.  Cross-compiling of even portable
> cross-compile-aware sources like gcc is broken by this.

I personally believe we should build GCC in the normal manner, but this
is no longer my decision to make.

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

i386 tinderbox failure

[Dag-Erling Smorgrav]

--
>>> Rebuilding the temporary build tree
--
>>> stage 1: bootstrap tools
--
>>> stage 2: cleaning up the object tree
--
>>> stage 2: rebuilding the object tree
--
>>> stage 2: build tools
--
>>> stage 3: cross tools
--
>>> stage 4: populating /tmp/des/obj/i386/d/home/des/tinderbox/src/i386/usr/include
--
>>> stage 4: building libraries
--
===> kerberosIV/lib/libkdb
...
/d/home/des/tinderbox/src/crypto/kerberosIV/lib/kdb/krb_kdb_utils.c:200: warning: 
passing arg 1 of `des_pcbc_encrypt' from incompatible pointer type
/d/home/des/tinderbox/src/crypto/kerberosIV/lib/kdb/krb_kdb_utils.c:200: warning: 
passing arg 2 of `des_pcbc_encrypt' from incompatible pointer type
/d/home/des/tinderbox/src/crypto/kerberosIV/lib/kdb/krb_kdb_utils.c: In function 
`kdb_encrypt_key':
/d/home/des/tinderbox/src/crypto/kerberosIV/lib/kdb/krb_kdb_utils.c:200: warning: 
passing arg 1 of `des_pcbc_encrypt' from incompatible pointer type
/d/home/des/tinderbox/src/crypto/kerberosIV/lib/kdb/krb_kdb_utils.c:200: warning: 
passing arg 2 of `des_pcbc_encrypt' from incompatible pointer type
===> kerberosIV/lib/libkrb
===> kerberosIV/lib/libtelnet
cc1: warnings being treated as errors
/d/home/des/tinderbox/src/crypto/telnet/libtelnet/kerberos.c: In function 
`kerberos4_cksum':
/d/home/des/tinderbox/src/crypto/telnet/libtelnet/kerberos.c:496: warning: unreachable 
code at beginning of switch statement
*** Error code 1

Stop in /d/home/des/tinderbox/src/kerberosIV/lib/libtelnet.
*** Error code 1

Stop in /d/home/des/tinderbox/src/kerberosIV/lib.
*** Error code 1

Stop in /d/home/des/tinderbox/src.
*** Error code 1

Stop in /d/home/des/tinderbox/src.
*** Error code 1

Stop in /d/home/des/tinderbox/src.
*** Error code 1

Stop in /d/home/des/tinderbox/src.

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

Re: [PATCH] cross-arch bootstrapping is broken by GCC 3.1

[Bruce Evans]

On Tue, 14 May 2002, David O'Brien wrote:

> On Tue, May 14, 2002 at 11:41:45AM +0300, Ruslan Ermilov wrote:
> > Hi!
> >
> > 4.x i386 and old 5.0 i386 can no longer produce current 5.0 alpha
> > worlds due to the lack of atoll(3) in libc.  This patch fixes it:
>
> Considering how simple src/lib/libc/stdlib/atoll.c is; lets ask RE for a
> MFC.

That wouldn't actually fix the problem, since it would only help for
bootstrapping 5.0 from very recent versions of 4.x.  The problem is
the usual one with committing files generated by autoconfig.  This
gives a configuration that might only be valid for the host machine
that ran autoconfig.  Cross-compiling of even portable cross-compile-aware
sources like gcc is broken by this.

Bruce


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

Re: make includes

[Bruce Evans]

On Tue, 14 May 2002, David O'Brien wrote:

> On Tue, May 14, 2002 at 09:21:18AM +0300, Ruslan Ermilov wrote:
> >
> > Yes.  "make includes" has been modified to mean "build includes",
> > and the new "make incsinstall" has been added to "install" them.
> > So the correct sequence is "make includes incsinstall".
>
> I really do not like this change, please return things such that the
> long-ingraned "cd /usr/src ; make includes".

I planned to fix this by changing "make includes" to print
"Unwarranted chumminess with implementation".

Bruce


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

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

[Bruce A. Mah]

If memory serves me right, Jeremy Lea wrote:

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

Hi Jeremy--

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

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

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

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

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

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

Good job!

Bruce.



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

Re: make includes

[Hiten Pandya]

--- Ruslan Ermilov <[EMAIL PROTECTED]> wrote:
> People might want to use it like that:
> 
> make world
> mv /usr/include /usr/include.old

Sorry to butt in; but wouldn't it be more good if this step was done
by the build scripts itself? (refering to: mv /usr/include /usr/include.old)

> make incsinstall

Regards.

-- 
Hiten Pandya
Finger [EMAIL PROTECTED] for PGP Public Key
See complete mail headers for address information
WWW: http://storm.uk.FreeBSD.org/~hiten/

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!]

[Kris Kennaway]

On Tue, May 14, 2002 at 02:50:39PM +0200, Jeremy Lea wrote:
> Hi,
> 
> 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.

Thanks for doing this.

Kris



msg38345/pgp0.pgp
Description: PGP signature

Re: make includes

[David O'Brien]

On Tue, May 14, 2002 at 04:10:51PM +0300, Ruslan Ermilov wrote:
> > Why change in the first place?
> > 
> > What was wrong with 'make includes'? Why break POLA?
> > 
> They were broken.  See commit log for share/mk/bsd.incs.mk,v 1.1 for
> a full story.

I fail to see how they were broken from the rev 1.1 bsd.incs.mk log.
It looks like you just hyjacked the `includes' target.  Why could you not
have used `incbuild' and `incinstall'?  Then includes is something like

includes: incbuild incinstall

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

Re: make includes

[David O'Brien]

On Tue, May 14, 2002 at 09:21:18AM +0300, Ruslan Ermilov wrote:
> 
> Yes.  "make includes" has been modified to mean "build includes",
> and the new "make incsinstall" has been added to "install" them.
> So the correct sequence is "make includes incsinstall".


I really do not like this change, please return things such that the
long-ingraned "cd /usr/src ; make includes".

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

Re: [PATCH] cross-arch bootstrapping is broken by GCC 3.1

[David O'Brien]

On Tue, May 14, 2002 at 11:41:45AM +0300, Ruslan Ermilov wrote:
> Hi!
> 
> 4.x i386 and old 5.0 i386 can no longer produce current 5.0 alpha
> worlds due to the lack of atoll(3) in libc.  This patch fixes it:

Considering how simple src/lib/libc/stdlib/atoll.c is; lets ask RE for a
MFC.

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

Re: [PATCH] cross builds are broken (was: Re: cvs commit: src/gnu/usr.bin/cc/cc_tools freebsd-native.h)

[David O'Brien]

On Tue, May 14, 2002 at 01:05:22PM +0300, Ruslan Ermilov wrote:
> On Fri, May 10, 2002 at 01:41:47AM -0700, David E. O'Brien wrote:
> > obrien  2002/05/10 01:41:46 PDT
> > 
> >   Modified files:(Branch: WIP_GCC31)
> > gnu/usr.bin/cc/cc_tools freebsd-native.h 
> >   Log:
> >   Use MD_EXEC_PREFIX now to get us thru `buildworld'.

I did not like using MD_EXEC_PREFIX, but it got us to where we needed to
get quickly.  Returning to the 2.95 state of not using it is good.

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

Re: bad tcp cksum fffe!

[Giorgos Keramidas]

On 2002-05-14 17:39, Cristan Szmajda wrote:
> Dear freebsd-current,
> 
> Any suggestions you have regarding this problem would be
> much appreciated.
> 
> My laptop running -CURRENT is suddenly generating bad TCP
> checksums when talking to some IPs but not others.  For
> example, 129.94.209.220 is a problem,
> 
> 17:08:47.026823 129.94.233.200.1032 > 129.94.209.220.22: S
> [bad tcp cksum fffe!] 3868790363:3868790363(0) win 65535
> 
> (DF) (ttl 64, id 347, len 68)

I've seen this only twice.  The first time I was using too funky
optimizations to the CFLAGS of my kernel, and GCC was obviously doing
something wrong with the checksum generation code.  If this is the
case, then rebuild your kernel and userland with the suggested
optimizations from /usr/share/examples/etc/make.conf and see if this
fixes things for you.

The second one was when my tcpdump (and the rest of the userland) was
really VERY out of sync with the running kernel (I had managed to
upgrade only the kernel and tcpdump was probably reading random data
from bpf).  But there were other more important things wrong with this
case.

-- 
Giorgos Keramidas- http://www.FreeBSD.org
[EMAIL PROTECTED] - The Power to Serve

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

Re: make includes

[Ruslan Ermilov]

On Wed, May 15, 2002 at 12:18:04AM +1000, Bruce Evans wrote:
> On Tue, 14 May 2002, Ruslan Ermilov wrote:
> 
> > On Tue, May 14, 2002 at 11:32:19PM +1000, Bruce Evans wrote:
> > > Installing includes just corrupts the host environment unless the new
> > > includes are consistent with the old libraries.  If you know the build
> > > system, the includes and the libraries well enough to know when it is
> > > safe to use, then you know enough to never need it.
> > >
> > People might want to use it like that:
> >
> > make world
> > mv /usr/include /usr/include.old
> > make incsinstall
> >
> > To remove stale includes.  Previous version had "includes" that both
> > built and installed includes, I have just split it in two parts.
> 
> That's rather hackish, and doesn't handle garbage other than includes.
> I usually find stale files by comparing my world with a world installed
> in a nonstandard DESTDIR.  A mergemaster-like utility could automate
> this.
> 
Yes, I do this the same way actually.  :-)


Cheers,
-- 
Ruslan Ermilov  Sysadmin and DBA,
[EMAIL PROTECTED]   Sunbay Software AG,
[EMAIL PROTECTED]  FreeBSD committer,
+380.652.512.251Simferopol, Ukraine

http://www.FreeBSD.org  The Power To Serve
http://www.oracle.com   Enabling The Information Age



msg38339/pgp0.pgp
Description: PGP signature

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

[Maxim Sobolev]

Jeremy Lea wrote:
> 
> Hi,
> 
> On Tue, May 14, 2002 at 04:19:29PM +0300, Maxim Sobolev wrote:
> >
> > +++ version/perform.c   14 May 2002 12:41:41 -
> > [...]
> > +   strlcpy(tmp, PORTS_DIR, PATH_MAX);
> > +   strlcat(tmp, "/INDEX", PATH_MAX);
> >
> > I'd suggest snprintf(3)
> 
> Yeah.  Like I said, it needs a bit of polishing.  I tend to do things
> this way while I'm developing because I find it easier to keep track of
> what's going where in the string.  There's also a bunch of places where
> the 'l' versions aren't needed...

Tastes differ, granted, but your version is inconsistent with the
existing coding style of pkg_install, where snprintf's are used in
such cases.

> 
> > Why noy use matchinstalled() which do something similar?
> 
> I looked at it, but it was taking more code to make it work than to
> duplicate it because the -s flag is not a regex or a globing pattern.
> It's a poorly designed interface...  Now that it's working I'll look at
> it again and see if I can get it to do the right thing.  Simplifying
> working code is a lot easier than building it.

In this case you just need to call matchinstalled(MATCH_ALL, NULL,
NULL) and iterate over results, just like you do with your fts_read()
loop. This should make code a bit cleaner and more compact.

> > + funny:
> > +warnx("This is a very funny looking INDEX!");
> > +return 1;
> >
> > I don't think this is a good choice for an error message.
> 
> ;-)

-Maxim

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

Re: make includes

[Bruce Evans]

On Tue, 14 May 2002, Ruslan Ermilov wrote:

> On Tue, May 14, 2002 at 11:32:19PM +1000, Bruce Evans wrote:
> > Installing includes just corrupts the host environment unless the new
> > includes are consistent with the old libraries.  If you know the build
> > system, the includes and the libraries well enough to know when it is
> > safe to use, then you know enough to never need it.
> >
> People might want to use it like that:
>
> make world
> mv /usr/include /usr/include.old
> make incsinstall
>
> To remove stale includes.  Previous version had "includes" that both
> built and installed includes, I have just split it in two parts.

That's rather hackish, and doesn't handle garbage other than includes.
I usually find stale files by comparing my world with a world installed
in a nonstandard DESTDIR.  A mergemaster-like utility could automate
this.

Bruce


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

S3 Savage on Thinkpad T23 using -CURRENT

[Troy]

Michael,

Thanks for posting your Thinkpad T23 configuration.  A lot has changed with regards to 
kernel configuration from STABLE to CURRENT. 

The outstanding issue with the Thinkpad T23 in CURRENT is still the S3 SAVAGE video 
card.  I've had two folks mail their working XF86Config files (used in STABLE) to me 
and they still do not produce resolution above 1024x768. 

It appears that the problem is because the video card is not being
recognized by the pci configuration (as noted by non0@pci1:0:0:). I'll try
posting this on the current and multimedia mailing lists to see if anyone
has an idea.


pciconf -l -v 

none0@pci1:0:0: class=0x03 card=0x01fc1014 chip=0x8c2e5333 rev=0x05
hdr=0x00
vendor   = 'S3 Incorporated'
device   = '86C583 SuperSavage/IXC SDR'
class= display
subclass = VGA


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!]

[Jeremy Lea]

Hi,

On Tue, May 14, 2002 at 04:19:29PM +0300, Maxim Sobolev wrote:
> 
> +++ version/perform.c   14 May 2002 12:41:41 -
> [...]
> +   strlcpy(tmp, PORTS_DIR, PATH_MAX);
> +   strlcat(tmp, "/INDEX", PATH_MAX);
> 
> I'd suggest snprintf(3)

Yeah.  Like I said, it needs a bit of polishing.  I tend to do things
this way while I'm developing because I find it easier to keep track of
what's going where in the string.  There's also a bunch of places where
the 'l' versions aren't needed...

> Why noy use matchinstalled() which do something similar?

I looked at it, but it was taking more code to make it work than to
duplicate it because the -s flag is not a regex or a globing pattern. 
It's a poorly designed interface...  Now that it's working I'll look at
it again and see if I can get it to do the right thing.  Simplifying
working code is a lot easier than building it.

> + funny:
> +warnx("This is a very funny looking INDEX!");
> +return 1;
> 
> I don't think this is a good choice for an error message.

;-)

Regards,
  -Jeremy

-- 
FreeBSD - Because the best things in life are free...
   http://www.freebsd.org/

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

Re: make includes

[Sheldon Hearn]

On Tue, 14 May 2002 16:34:56 +0300, Ruslan Ermilov wrote:

> People might want to use it like that:
> 
> make world
> mv /usr/include /usr/include.old
> make incsinstall
> 
> To remove stale includes.  Previous version had "includes" that both
> built and installed includes, I have just split it in two parts.

Pity we lost CLOBBER, which took care of this for you.

Ciao,
Sheldon.

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

Re: make includes

[Ruslan Ermilov]

On Tue, May 14, 2002 at 11:32:19PM +1000, Bruce Evans wrote:
> On Tue, 14 May 2002, Ruslan Ermilov wrote:
> 
> > On Tue, May 14, 2002 at 06:21:41PM +1000, Bruce Evans wrote:
> > > On Tue, 14 May 2002, Ruslan Ermilov wrote:
> > >
> > > > Yes.  "make includes" has been modified to mean "build includes",
> > > > and the new "make incsinstall" has been added to "install" them.
> > > > So the correct sequence is "make includes incsinstall".
> > > >
> > > > I'm still unsure about the name; I'd have liked to rename it to
> > > > "includesinstall" but that is too long.
> > >
> > > I still prefer something like
> > > "__private_part_of_installworld_to_install_headers_dont_use_directly".
> > >
> > EPARSE; what does that mean?  :-)
> >
> > "incsinstall" is the standard target which performs a part of a normal
> > "install" -- installs C includes.
> 
> Installing includes just corrupts the host environment unless the new
> includes are consistent with the old libraries.  If you know the build
> system, the includes and the libraries well enough to know when it is
> safe to use, then you know enough to never need it.
> 
People might want to use it like that:

make world
mv /usr/include /usr/include.old
make incsinstall

To remove stale includes.  Previous version had "includes" that both
built and installed includes, I have just split it in two parts.

(I will add the par-includes to Makefile.inc1 tomorrow, FWIW.)


Cheers,
-- 
Ruslan Ermilov  Sysadmin and DBA,
[EMAIL PROTECTED]   Sunbay Software AG,
[EMAIL PROTECTED]  FreeBSD committer,
+380.652.512.251Simferopol, Ukraine

http://www.FreeBSD.org  The Power To Serve
http://www.oracle.com   Enabling The Information Age



msg38336/pgp0.pgp
Description: PGP signature

Re: make includes

[Bruce Evans]

On Tue, 14 May 2002, Ruslan Ermilov wrote:

> On Tue, May 14, 2002 at 06:21:41PM +1000, Bruce Evans wrote:
> > On Tue, 14 May 2002, Ruslan Ermilov wrote:
> >
> > > Yes.  "make includes" has been modified to mean "build includes",
> > > and the new "make incsinstall" has been added to "install" them.
> > > So the correct sequence is "make includes incsinstall".
> > >
> > > I'm still unsure about the name; I'd have liked to rename it to
> > > "includesinstall" but that is too long.
> >
> > I still prefer something like
> > "__private_part_of_installworld_to_install_headers_dont_use_directly".
> >
> EPARSE; what does that mean?  :-)
>
> "incsinstall" is the standard target which performs a part of a normal
> "install" -- installs C includes.

Installing includes just corrupts the host environment unless the new
includes are consistent with the old libraries.  If you know the build
system, the includes and the libraries well enough to know when it is
safe to use, then you know enough to never need it.

Bruce


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

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

[Maxim Sobolev]

Jeremy Lea wrote:
> 
> Hi,
> 
> 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...

Cool! Few notes:

+++ version/perform.c   14 May 2002 12:41:41 -
[...]
+   strlcpy(tmp, PORTS_DIR, PATH_MAX);
+   strlcat(tmp, "/INDEX", PATH_MAX);

I'd suggest snprintf(3)

[...]
+ftsp = fts_open((char * const *)(uintptr_t)paths, FTS_LOGICAL |
FTS_NOCHDIR | FTS_NOSTAT, fname_cmp);
+if (ftsp != NULL) {
+   while ((f = fts_read(ftsp)) != NULL) {
+   if (f->fts_info == FTS_D && f->fts_level == 1) {
+   fts_set(ftsp, f, FTS_SKIP);
+   if (MatchName == NULL || strstr(f->fts_name,
MatchName))
+   err_cnt += pkg_do(f->fts_name);
+   }
+   }
+   fts_close(ftsp);
+}

Why noy use matchinstalled() which do something similar?

[...]
+strlcpy(tmp, LOG_DIR, PATH_MAX);
+strlcat(tmp, "/", PATH_MAX);
+strlcat(tmp, pkg, PATH_MAX);
+strlcat(tmp, "/", PATH_MAX);
+strlcat(tmp, CONTENTS_FNAME, PATH_MAX);

I'd suggest snprintf(3)

[...]
+   strlcpy(tmp, PORTS_DIR, PATH_MAX);
+   strlcat(tmp, "/", PATH_MAX);
+   strlcat(tmp, plist.origin, PATH_MAX);

snprintf(3)

[...]
+ funny:
+warnx("This is a very funny looking INDEX!");
+return 1;

I don't think this is a good choice for an error message.

[...]
+static int
+fname_cmp(const FTSENT **a, const FTSENT **b)
+{
+return strcmp((*a)->fts_name, (*b)->fts_name);
+}

Could be routed to /dev/null if matchinstalled() is used.

-Maxim

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!]

[Mark Murray]

> 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... 
> 
> Regards,
>   -Jeremy

No need to wait for me on this one. If folks are happy, this is good
for me!

M
-- 
o   Mark Murray
\_
O.\_Warning: this .sig is umop ap!sdn
#text/plain; name=cv.doc [Mark Murray CV Plain Text] cv.doc
#application/octet-stream; name=cv.pdf [Mark Murray CV PDF] cv.pdf

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

Re: make includes

[Ruslan Ermilov]

On Tue, May 14, 2002 at 03:01:28PM +0200, Anders Andersson wrote:
> On Tue, May 14, 2002 at 09:21:18AM +0300, Ruslan Ermilov wrote:
> > Yes.  "make includes" has been modified to mean "build includes",
> > and the new "make incsinstall" has been added to "install" them.
> > So the correct sequence is "make includes incsinstall".
> > 
> > I'm still unsure about the name; I'd have liked to rename it to
> > "includesinstall" but that is too long.
> 
> Why change in the first place?
> 
> What was wrong with 'make includes'? Why break POLA?
> 
They were broken.  See commit log for share/mk/bsd.incs.mk,v 1.1 for
a full story.


Cheers,
-- 
Ruslan Ermilov  Sysadmin and DBA,
[EMAIL PROTECTED]   Sunbay Software AG,
[EMAIL PROTECTED]  FreeBSD committer,
+380.652.512.251Simferopol, Ukraine

http://www.FreeBSD.org  The Power To Serve
http://www.oracle.com   Enabling The Information Age



msg38329/pgp0.pgp
Description: PGP signature

Re: make includes

[Anders Andersson]

On Tue, May 14, 2002 at 09:21:18AM +0300, Ruslan Ermilov wrote:
> Yes.  "make includes" has been modified to mean "build includes",
> and the new "make incsinstall" has been added to "install" them.
> So the correct sequence is "make includes incsinstall".
> 
> I'm still unsure about the name; I'd have liked to rename it to
> "includesinstall" but that is too long.

Why change in the first place?

What was wrong with 'make includes'? Why break POLA?
-- 
Anders Andersson[EMAIL PROTECTED]
Sanyusan Int. ABhttp://www.sanyusan.se/

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

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

[Jeremy Lea]

Hi,

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

Regards,
  -Jeremy

-- 
FreeBSD - Because the best things in life are free...
   http://www.freebsd.org/


Index: lib/lib.h
===
RCS file: /home/ncvs/src/usr.sbin/pkg_install/lib/lib.h,v
retrieving revision 1.43
diff -u -r1.43 lib.h
--- lib/lib.h   5 May 2002 21:03:25 -   1.43
+++ lib/lib.h   14 May 2002 12:41:41 -
@@ -201,6 +201,8 @@
 
 /* Version */
 intverscmp(Package *, int, int);
+const char *version_of(const char *, int *, int *);
+intversion_cmp(const char *, const char *);
 
 /* Externs */
 extern Boolean Verbose;
Index: lib/version.c
===
RCS file: /home/ncvs/src/usr.sbin/pkg_install/lib/version.c,v
retrieving revision 1.2
diff -u -r1.2 version.c
--- lib/version.c   1 Apr 2002 09:39:07 -   1.2
+++ lib/version.c   14 May 2002 12:41:41 -
@@ -14,6 +14,15 @@
  * Maxim Sobolev
  * 31 July 2001
  *
+ */
+ 
+#include 
+__FBSDID("$FreeBSD: src/usr.sbin/pkg_install/lib/version.c,v 1.2 2002/04/01 09:39:07 
+obrien Exp $");
+
+#include "lib.h"
+#include 
+
+/*
  * Routines to assist with PLIST_FMT_VER numbers in the packing
  * lists.
  *
@@ -23,13 +32,6 @@
  *  value insted of the hash of an object this links points to.
  *
  */
-
-#include 
-__FBSDID("$FreeBSD: src/usr.sbin/pkg_install/lib/version.c,v 1.2 2002/04/01 09:39:07 
obrien Exp $");
-
-#include "lib.h"
-#include 
-
 int
 verscmp(Package *pkg, int major, int minor)
 {
@@ -43,4 +45,123 @@
rval = 1;
 
 return rval;
+}
+
+/*
+ * version_of(pkgname, epoch, revision) returns a pointer to the version
+ * portion of a package name and the two special components.
+ *
+ * Jeremy D. Lea.
+ */
+const char *
+version_of(const char *pkgname, int *epoch, int *revision)
+{
+char *ch;
+
+if (pkgname == NULL)
+   errx(2, "%s: Passed NULL pkgname.", __func__);
+if (epoch != NULL) {
+   if ((ch = strrchr(pkgname, ',')) == NULL)
+   *epoch = 0;
+   else
+   *epoch = atoi(&ch[1]);
+}
+if (revision != NULL) {
+   if ((ch = strrchr(pkgname, '_')) == NULL)
+   *revision = 0;
+   else
+   *revision = atoi(&ch[1]);
+}
+/* Cheat if we are just passed a version, not a valid package name */
+if ((ch = strrchr(pkgname, '-')) == NULL)
+   return pkgname;
+else
+   return &ch[1];
+}
+
+/*
+ * version_cmp(pkg1, pkg2) returns -1, 0 or 1 depending on if the version
+ * components of pkg1 is less than, equal to or greater than pkg2. No
+ * comparision of the basenames is done.
+ *
+ * The port verison is defined by:
+ * ${PORTVERSION}[_${PORTREVISION}][,${PORTEPOCH}]
+ * ${PORTEPOCH} supercedes ${PORTVERSION} supercedes ${PORTREVISION}.
+ * See the commit log for revision 1.349 of ports/Mk/bsd.port.mk
+ * for more information.
+ *
+ * The epoch and revision are defined to be a single number, while the rest
+ * of the version should conform to the porting guidelines. It can contain
+ * multiple components, seperated by a period, including letters.
+ *
+ * The tests below allow for significantly more latitude in the version
+ * numbers than is allowed in the guidelines. No point in wasting user's
+ * time enforcing them here. That's what flamewars are for.
+ *
+ * Jeremy D. Lea.
+ */
+int
+version_cmp(const char *pkg1, const char *pkg2)
+{
+const char *c1, *c2, *v1, *v2;
+char *t1, *t2;
+int e1, e2, r1, r2, n1, n2;
+
+v1 = version_of(pkg1, &e1, &r1);
+v2 = version_of(pkg2, &e2, &r2);
+/* Minor optimisation. */
+if (strcmp(v1, v2) == 0)
+   return 0;
+/* First compare epoch. */
+if (e1 != e2)
+   return (e1 < e2 ? -1 : 1);
+else {
+   /* We walk down the versions, trying to convert to numbers.
+* We terminate when we reach an underscore, a comma or the
+* string terminator, thanks to a nasty trick with strchr().
+*
+* strtol() conveniently gobbles up the chars it converts.
+*/
+   c1 = strchr("_,", v1[0]);
+   c2 = strchr("_,", v2[0]);
+   while (c1 == NULL && c2 == NULL) {
+   n1 = strtol(v1, &t1, 10);
+   n2 = strtol(v2, &t2, 10);
+   if (n1 != n2)
+   return (n1 < n2 ? -1 : 1);
+   /* The numbers are equal, check for letters. They're letters
+  purely because strto

[no subject]

[Denis P. Khripun]

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

Re: Is anyone else having trouble with dump(8) on -current?

[Alexander Leidinger]

On  7 Mai, Benjamin Lewis wrote:

> Now, on to the problem.  I use amanda for backups, and since mid-April
> I've been seeing items like the following in the backup report:
> 
>   /-- akira.woss /var lev 0 FAILED [/sbin/dump returned 3]
>   sendbackup: start [akira.wossname.net:/var level 0]
>   sendbackup: info BACKUP=/sbin/dump
>   sendbackup: info RECOVER_CMD=/sbin/restore -f... -
>   sendbackup: info end
>   |   DUMP: Date of this level 0 dump: Mon Apr 29 00:11:50 2002
>   |   DUMP: Date of last level 0 dump: the epoch
>   |   DUMP: Dumping /dev/da0s3e (/var) to standard output
>   |   DUMP: mapping (Pass I) [regular files]
>   |   DUMP: mapping (Pass II) [directories]
>   |   DUMP: estimated 36490 tape blocks.
>   |   DUMP: dumping (Pass III) [directories]
>   |   DUMP: slave couldn't reopen disk: Interrupted system call
>   |   DUMP: The ENTIRE dump is aborted.
>   sendbackup: error [/sbin/dump returned 3]
>   \

Try the attached patch. I also have a similar patch for restore. I don't
like the patch, I think I should use SA_RESTART with sigaction(), so
think about this patch as a proof of concept (if it solves your
problem).

Bye,
Alexander.

-- 
  ...and that is how we know the Earth to be banana-shaped.

http://www.Leidinger.net   Alexander @ Leidinger.net
  GPG fingerprint = C518 BC70 E67F 143F BE91  3365 79E2 9C60 B006 3FE7


Index: sbin/dump/dumprmt.c
===
RCS file: /big/FreeBSD-CVS/src/sbin/dump/dumprmt.c,v
retrieving revision 1.17
diff -u -r1.17 dumprmt.c
--- sbin/dump/dumprmt.c 20 Mar 2002 22:49:39 -  1.17
+++ sbin/dump/dumprmt.c 27 Mar 2002 15:27:54 -
@@ -114,10 +114,13 @@
t.tv_sec = 0;
t.tv_usec = 0;
if (select(errfd + 1, &r, NULL, NULL, &t)) {
-   int i;
+   int i = 0;
char buf[2048];
 
-   if ((i = read(errfd, buf, sizeof(buf) - 1)) > 0) {
+   do {
+   i = read(errfd, buf, sizeof(buf));
+   } while ((i == -1) && (errno == EINTR));
+   if (i - 1 > 0) {
buf[i] = '\0';
msg("on %s: %s%s", rmtpeer, buf,
buf[i - 1] == '\n' ? "" : "\n");
@@ -243,7 +246,9 @@
/* rmtcall() properly sets errno for us on errors. */
return (n);
for (i = 0; i < n; i += cc) {
-   cc = read(rmtape, buf+i, n - i);
+   do {
+   cc = read(rmtape, buf+i, n - i);
+   } while ((cc == -1) && (errno == EINTR));
if (cc <= 0)
rmtconnaborted(0);
}
@@ -361,8 +366,12 @@
 rmtgetb(void)
 {
char c;
+   int ret_val;
 
-   if (read(rmtape, &c, 1) != 1)
+   do {
+   ret_val = read(rmtape, &c, 1);
+   } while ((ret_val == -1) && (errno == EINTR));
+   if (ret_val != 1)
rmtconnaborted(0);
return (c);
 }
Index: sbin/dump/itime.c
===
RCS file: /big/FreeBSD-CVS/src/sbin/dump/itime.c,v
retrieving revision 1.11
diff -u -r1.11 itime.c
--- sbin/dump/itime.c   20 Mar 2002 22:49:39 -  1.11
+++ sbin/dump/itime.c   27 Mar 2002 14:26:39 -
@@ -74,7 +74,10 @@
 {
FILE *df;
 
-   if ((df = fopen(dumpdates, "r")) == NULL) {
+   do {
+   df = fopen(dumpdates, "r");
+   } while ((df == NULL) && (errno == EINTR));
+   if (df == NULL) {
if (errno != ENOENT) {
msg("WARNING: cannot read %s: %s\n", dumpdates,
strerror(errno));
@@ -84,13 +87,19 @@
 * Dumpdates does not exist, make an empty one.
 */
msg("WARNING: no file `%s', making an empty one\n", dumpdates);
-   if ((df = fopen(dumpdates, "w")) == NULL) {
+   do {
+   df = fopen(dumpdates, "w");
+   } while ((df == NULL) && (errno == EINTR));
+   if (df == NULL) {
msg("WARNING: cannot create %s: %s\n", dumpdates,
strerror(errno));
return;
}
(void) fclose(df);
-   if ((df = fopen(dumpdates, "r")) == NULL) {
+   do {
+   df = fopen(dumpdates, "r");
+   } while ((df == NULL) && (errno == EINTR));
+   if (df == NULL) {
quit("cannot read %s even after creating it: %s\n",
dumpdates, strerror(errno));
/* NOTREACHED */
@@ -171,7 +180,10 @@
 
if(uflag == 0)
return;
-

Re: HEADSUP: UFS2 progress.

[Poul-Henning Kamp]

In message <[EMAIL PROTECTED]>, CHOI Junho writes:
>
>That's amazing news for me(and hopefully other hackers). How can I see
>the details of UFS2? Is there published papers or website?

Nothing much yet.

UFS2 contains three parts:

1. Extended Attributes. (forces inode size increase).
2. Make everything 64bit (since we change the inode anyway)
3. Per inode blocksize (Not quite extents but edging over there)

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.

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

Re: HEADSUP: UFS2 progress.

[CHOI Junho]

That's amazing news for me(and hopefully other hackers). How can I see
the details of UFS2? Is there published papers or website?

From: Poul-Henning Kamp <[EMAIL PROTECTED]>
Subject: HEADSUP: UFS2 progress.
Date: Tue, 14 May 2002 12:14:05 +0200

> 
> We hope to commit the UFS2 patch to -current before the end of May.
> 
> -- 
> Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
> [EMAIL PROTECTED] | TCP/IP since RFC 956
> FreeBSD committer   | BSD since 4.3-tahoe
> Never attribute to malice what can adequately be explained by incompetence.

--
 +++ Any opinions in this posting are my own and not those of my employers +++
 CHOI Junho [sleeping now]
 [while sleeping]   
 Korea FreeBSD Users GroupWeb Data Bank

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

Re: VLock and 5.0 DP1

[Michal Mertl]

> When i try to compile Vlock from ports, i get:
>
> cc -O -pipe   -DUSE_PAM -c vlock.c
> cc -O -pipe   -DUSE_PAM -c signals.c
> cc -O -pipe   -DUSE_PAM -c help.c
> cc -O -pipe   -DUSE_PAM -c terminal.c
> cc -O -pipe   -DUSE_PAM -c input.c
> input.c:64: security/pam_misc.h: No such file or directory
> input.c:67: `misc_conv' undeclared here (not in a function)
> input.c:67: initializer element is not constant
> input.c:67: (near initialization for `PAM_conversation.conv')

vlock's PAM handling is written for LinuxPAM. There's some icompatibility
issue with OpenPAM which I didn't look much into but it helps to remove
USE_PAM. You don't have to tell the vlock you're using shadow passwords
because FreeBSD's getpwent(3)  returns password to the program run by root
automatically. To run the program as root you must make sure it's owned by
root and has suid bit set (or always run it as root). This easily may be
security hole if there's bug in the program.

HTH

-- 
Michal Mertl
[EMAIL PROTECTED]




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

Re: The updated socket patch and axing sotryfree() (Re: Locking down a socket, milestone 1)

[Seigo Tanimura]

On Wed, 8 May 2002 09:16:56 -0700,
  Alfred Perlstein <[EMAIL PROTECTED]> said:

bright> * Seigo Tanimura <[EMAIL PROTECTED]> [020508 04:59] wrote:
>> 
>> I would like to commit this patch in one or two weeks to start working
>> on a possible race between a user process and a netisr kthread,
>> prevented by only the Giant lock at the moment.
>> 
>> When a user process calls sofree() for a listening socket, it attempts
>> to free the sockets in the connection queues by soabort().  If the
>> connection of an aborting socket gets dropped by a remote host (eg by
>> TCP RST), a netisr kthread also attempts to free the socket.  Since
>> the reference count of a socket in a connection queue is zero, this
>> would resust in doubly freeing a socket.
>> 
>> To solve that problem, I would like to axe sotryfree().  The PCB of a
>> socket and a connection queue should hold a reference to the
>> socket. This should make the reference count of an alive socket always
>> be >= 1, and ensure that there is only one referer to a socket to be
>> freed.
>> 
>> Comments?

bright> I'm not sure exactly how this solves the problem, there may need to
bright> be a global socket mutex, perhaps putting this sort of operation under
bright> that may do what you want.

Yes, at least, we should introduce a global lock to protect the
relation between sockets and PCBs.


bright> Off the top of my head...

bright> I think one way of doing it is storing the hashlist that the socket
bright> belongs to (inpcb_hash) inside the sockets.  That way after a lookup
bright> you will have the lock on the parent structure, a user process will
bright> have to follow the same locking paradym, basically look at the head
bright> socket, lock the hashlist, then manipulate the incomplete queue.

bright> Basically, protect this sort of operation via the hashlist because
bright> you pretty much need to anyway. :)


In order to solve the issue of deallocation race by a hashlist lock,
we *always* have to obtain a socket or a PCB by looking up a hashlist.
This is quite problematic because:

1. the lock order between a socket and a PCB gets tangled,

2. a hashlist introduces an overhead of calculating a hash index
   value, and

3. a hashlint lock cannot be per-socket or per-PCB, resulting in a
   contention under a huge number of socket operations or incoming
   packets.

In order to make our lock strategy readable and comprehensible, we
should keep a lock order as simple as the following:

1. a lock to protect the relation between/among objects, (eg the
   proctree lock or the allproc lock) and

2. a lock dedicated to a single object. (eg a proc lock)

A reference count allows us a flexible way to keep a lock order clean.
Once we grabbed a reference to an object, we can unlock it completely
to restart with locking any lock protecting a relation.  For instance,
in the interrupt handler of a protocol stack, you lock a hashlist to
look up the PCB appropriate to an incoming packet.  You then lock the
PCB to do some work.  If you have to modify the socket corresponding
to the PCB, hold a reference to the PCB and unlock it.  Now you can
lock the relation between sockets and PCBs to grab the socket safely.

This strategy should be applicable to a socket operation initiated by
a user process as well.  We will not have to worry about the lock
order between a socket and a PCB.

Another advantage of a reference count is its cost.  Provided that we
hold an appropriate lock, we can simply follow a pointer to obtain an
object.  This is much cheaper than we calculate a hash index.  We can
also reduce the contention over a lock because the lock of a reference
count is per-socket or per-PCB.


bright> Other than that, have you looked at what BSD/os does and what Linux
bright> does?  Do they get it wrong or have any particular drawbacks?

BSD/OS seems to ensure the existence of a PCB by locking the hashlist
of PCBs.  I am worrying about the fact that they lock the hashlist for
quite a long duration. (about a half of udp_input() hold a read lock,
and almost all of tcp_input() hold a *write* lock.)

-- 
Seigo Tanimura <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>

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

HEADSUP: UFS2 progress.

[Poul-Henning Kamp]

Just to keep people in the loop...

I'm progressing through various issues which Kirk, Robert and I
feel should not be part of the actual UFS2 commit since they are
more cleanups and preparation than part of UFS2.

The next major commit is the 64ification of daddr_t and friends.

But don't get carried away now.  Since newfs/fsck will have to use
lseek(2) to access the diskdevice, UFS2 filesystems will be restricted
to 2^63 bytes, or "8M TeraBytes" whatever they are called (until
at least we make off_t larger than s64).

After this, disk-driver writers can start to teach drivers how to access
more than 2^31 x 512 bytes.

Having looked at a lot of very similar code in userland I am also
exploring if adding an internal libffs would be a good idea.

We are also working to divorce EXT2FS from UFS (Thanks Ian!) and
exploring of we need to deal with IFS or not.

The current patchset does not result in a split of UFS into a version
one and a version two, so we don't grow a new complement of tools
or kernel files for this.  In practice newfs will grow the "-O
[1|2]" option, defaulting to 1 for now, but hopefully defaulting
to 2 in 5.0-R.

We hope to commit the UFS2 patch to -current before the end of May.

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.

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

[PATCH] cross builds are broken (was: Re: cvs commit: src/gnu/usr.bin/cc/cc_tools freebsd-native.h)

[Ruslan Ermilov]

On Fri, May 10, 2002 at 01:41:47AM -0700, David E. O'Brien wrote:
> obrien  2002/05/10 01:41:46 PDT
> 
>   Modified files:(Branch: WIP_GCC31)
> gnu/usr.bin/cc/cc_tools freebsd-native.h 
>   Log:
>   Use MD_EXEC_PREFIX now to get us thru `buildworld'.
>   The problem is the GCC driver now turns STANDARD_EXEC_PREFIX into a relative
>   path -- "/../../libexec" for our normal install location.
>   However, in the middle of `buildworld' we need
>   "/../../../../libexec" due to the prefix we tell the GCC
>   driver.  But either the GCC driver is buggy, or we are confusing it, as it
>   tries to exec "/../../libexec/cpp0" as if it were installed
>   in the normal place (but isn't).
>   MD_EXEC_PREFIX is still absolute, so I'll use that for now.  I would like to
>   later make it so MD_EXEC_PREFIX is set only for `buildworld', as
>   MD_EXEC_PREFIX is also in the search path for libraries. Don't ask me why!
>   Another way is to add ${OBJFORMAT_PATH} (as set in CROSSENV) to the PATH
>   in src/Makefile.inc's WMAKEENV.
>   
>   Revision  ChangesPath
>   1.9.2.7   +1 -1  src/gnu/usr.bin/cc/cc_tools/freebsd-native.h
> 
This does not work for the "cross" case, as MD_EXEC_PREFIX is not
honoured here thus breaking "cross" world and releases.  The below
patch restores the lost functionality in the old pre-gcc-3.1 import
way.  ``gcc -print-search-dirs'' now looks as before with this
patch.  It also eliminates the redundant entry in the `libraries:'
part of the -print-search-dirs output.

%%%
Index: contrib/gcc/gcc.c
===
RCS file: /home/ncvs/src/contrib/gcc/gcc.c,v
retrieving revision 1.26
diff -u -p -r1.26 gcc.c
--- contrib/gcc/gcc.c   9 May 2002 22:02:01 -   1.26
+++ contrib/gcc/gcc.c   14 May 2002 09:58:59 -
@@ -3187,6 +3187,7 @@ process_command (argc, argv)
   /* Set up the default search paths.  If there is no GCC_EXEC_PREFIX,
  see if we can create it from the pathname specified in argv[0].  */
 
+#ifndef FREEBSD_NATIVE
 #ifndef VMS
   /* FIXME: make_relative_prefix doesn't yet work for VMS.  */
   if (!gcc_exec_prefix)
@@ -3197,6 +3198,7 @@ process_command (argc, argv)
putenv (concat ("GCC_EXEC_PREFIX=", gcc_exec_prefix, NULL));
 }
 #endif
+#endif /* not FREEBSD_NATIVE */
 
   if (gcc_exec_prefix)
 {
@@ -3841,9 +3843,9 @@ warranty; not even for MERCHANTABILITY o
 #ifndef OS2
   add_prefix (&exec_prefixes, standard_exec_prefix, "GCC",
  PREFIX_PRIORITY_LAST, 1, warn_std_ptr);
-#ifndef FREEBSD_NATIVE
   add_prefix (&exec_prefixes, standard_exec_prefix, "BINUTILS",
  PREFIX_PRIORITY_LAST, 2, warn_std_ptr);
+#ifndef FREEBSD_NATIVE
   add_prefix (&exec_prefixes, standard_exec_prefix_1, "BINUTILS",
  PREFIX_PRIORITY_LAST, 2, warn_std_ptr);
 #endif /* not FREEBSD_NATIVE */
Index: gnu/usr.bin/cc/cc_tools/freebsd-native.h
===
RCS file: /home/ncvs/src/gnu/usr.bin/cc/cc_tools/freebsd-native.h,v
retrieving revision 1.16
diff -u -p -r1.16 freebsd-native.h
--- gnu/usr.bin/cc/cc_tools/freebsd-native.h10 May 2002 08:54:46 -  1.16
+++ gnu/usr.bin/cc/cc_tools/freebsd-native.h14 May 2002 09:58:59 -
@@ -31,8 +31,9 @@
libraries: MD_EXEC_PREFIX:MD_STARTFILE_PREFIX:STANDARD_STARTFILE_PREFIX
 */
 #undef TOOLDIR_BASE_PREFIX /* Old??  This is not documented. */
+#undef STANDARD_BINDIR_PREFIX  /* We don't need one for now. */
 #defineSTANDARD_EXEC_PREFIXPREFIX"/libexec/"
-#defineMD_EXEC_PREFIX  PREFIX"/libexec/"
+#undef MD_EXEC_PREFIX
 
 /* Under FreeBSD, the normal location of the various *crt*.o files is the
/usr/lib directory.  */
%%%


Cheers,
-- 
Ruslan Ermilov  Sysadmin and DBA,
[EMAIL PROTECTED]   Sunbay Software AG,
[EMAIL PROTECTED]  FreeBSD committer,
+380.652.512.251Simferopol, Ukraine

http://www.FreeBSD.org  The Power To Serve
http://www.oracle.com   Enabling The Information Age



msg38318/pgp0.pgp
Description: PGP signature

Re: bad tcp cksum fffe!

[Terry Lambert]

Cristan Szmajda wrote:
> 
> Dear freebsd-current,
> 
> Any suggestions you have regarding this problem would be
> much appreciated.
> 
> My laptop running -CURRENT is suddenly generating bad TCP
> checksums when talking to some IPs but not others.  For
> example, 129.94.209.220 is a problem,

What do you mean "suddenly"?  If you downgrade, but have all
the IP addresses and payloads exactly the same, you don't get
the problem?

The NAT code is known to use the RFC 1141 rather than RFC 1624
incremental checksum update method, which can result in checksum
errors like those you are seeing, as a result of carry underflow
screwing up the calculation (the calculation should accumulate
the old and new checksum values in different registers, and then
combine them only after dealing with carry to get them into 16
bits).  I've commented on this before, with patched calculation
code.  If the problem happens on both the old and the new FreeBSD
code, then it's probably that you are going through a NAT.

If it happens only on the newer code, then it's something
that's changed, and you can use CVS to binary search for the
change that caused the problem (8 kernels will find any kernel
in the last 8.5 months where a breaking change occurred, if you
use a binary search).  If it's just the compiler change alone,
then it's a deeper problem.

It's not like the WaveLAN driver supports checksum offloading,
which is the problem du jour for the BCG570x...

-- Terry

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

Re: CURRENT and P-IV problems

[Terry Lambert]

Martin Blapp wrote:
> Now rm(1) and make(1) coredump with sig 10. So I thought it
> would be a good idea to recompile them with -g -ggdb and
> retry.
> 
> Now the strange part. The coredumps are gone. Ok, I did not
> use -pipe then. I'll will now try to use -pipe and -g and -ggdb
> all together.
> 
> How the fuck this can have a effect on these coredumps ???

The VAX and Windows debuggers are famous for making pointer
errors "disappear" when you compile /debug.  GDB is better at
not doing this, but isn't perfect.  Compiling with and without
debug will yield different code.

-g makes binaries bigger, and prevents some optimizations,
even if you aren't telling the compiler to optimize.

Does a "strip -g"'ed version of the -g compiled binary have the
same problem?

Also, an "objdump -p" comparison of the two might be informative;
there were a number of problems in Alpha-land when the compiler
assumptions changed because of the new binutils.  This might be a
similar problem to the ld.so problems there, only with the ELF
loader code.

Without more investigation by you, though, all you are going to
get is educated guesses.

-- Terry

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

Re: Problem with Intel 2011b

[John Angelmo]

M. Warner Losh wrote:
> In message: <[EMAIL PROTECTED]>
> John Angelmo <[EMAIL PROTECTED]> writes:
> : Hello
> : 
> : I just got my hands on a Intel 2011b Wireless card, I'm running FreeBSD 
> : current (dated just before gcc 3.1).
> : Now my problem is that I insert the card and well nothing happens, the 
> : system gets locked, when I remove the card I everything starts working 
> : once again, and it says it can't manage card ("null"), ("null")
> : 
> : Any one got any idea?
> 
> Nope.
> 
> However, if you boot -v, and send me the dmesg maybe I can help.
> 
> Warner
> 
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-current" in the body of the message

OK here's my dmesg

The 2011 card is allmost the same as the symbol card I use, the 2011b 
card is the updated version from intel that rund on 3,3v

/John




dmesg
Description: application/java-vm

Re: CURRENT and P-IV problems

[Martin Blapp]

Hi,

I see here now very strange effects. I've upgraded to the
newest CURRENT yesterday, installed on the PIV machine
over NFS.

Now rm(1) and make(1) coredump with sig 10. So I thought it
would be a good idea to recompile them with -g -ggdb and
retry.

Now the strange part. The coredumps are gone. Ok, I did not
use -pipe then. I'll will now try to use -pipe and -g and -ggdb
all together.

How the fuck this can have a effect on these coredumps ???

Martin

Martin Blapp, <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
--
ImproWare AG, UNIXSP & ISP, Zurlindenstrasse 29, 4133 Pratteln, CH
Phone: +41 061 826 93 00: +41 61 826 93 01
PGP Fingerprint: B434 53FC C87C FE7B 0A18 B84C 8686 EF22 D300 551E
--




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

[PATCH] cross-arch bootstrapping is broken by GCC 3.1

[Ruslan Ermilov]

Hi!

4.x i386 and old 5.0 i386 can no longer produce current 5.0 alpha
worlds due to the lack of atoll(3) in libc.  This patch fixes it:

%%%
Index: auto-host.h
===
RCS file: /home/ncvs/src/gnu/usr.bin/cc/cc_tools/auto-host.h,v
retrieving revision 1.5
diff -u -r1.5 auto-host.h
--- auto-host.h 12 May 2002 12:01:12 -  1.5
+++ auto-host.h 14 May 2002 08:04:59 -
@@ -97,7 +97,8 @@
 /* #undef HAVE___ARGZ_STRINGIFY */
 
 /* Define if you have the atoll function.  */
-#define HAVE_ATOLL 1
+/* FreeBSD 4.x doesn't have atoll(3). */
+/* #undef HAVE_ATOLL */
 
 /* Define if you have the atoq function.  */
 /* #undef HAVE_ATOQ */
%%%


Cheers,
-- 
Ruslan Ermilov  Sysadmin and DBA,
[EMAIL PROTECTED]   Sunbay Software AG,
[EMAIL PROTECTED]  FreeBSD committer,
+380.652.512.251Simferopol, Ukraine

http://www.FreeBSD.org  The Power To Serve
http://www.oracle.com   Enabling The Information Age



msg38312/pgp0.pgp
Description: PGP signature

Re: make includes

[Ruslan Ermilov]

On Tue, May 14, 2002 at 06:21:41PM +1000, Bruce Evans wrote:
> On Tue, 14 May 2002, Ruslan Ermilov wrote:
> 
> > Yes.  "make includes" has been modified to mean "build includes",
> > and the new "make incsinstall" has been added to "install" them.
> > So the correct sequence is "make includes incsinstall".
> >
> > I'm still unsure about the name; I'd have liked to rename it to
> > "includesinstall" but that is too long.
> 
> I still prefer something like
> "__private_part_of_installworld_to_install_headers_dont_use_directly".
> 
EPARSE; what does that mean?  :-)

"incsinstall" is the standard target which performs a part of a normal
"install" -- installs C includes.


Cheers,
-- 
Ruslan Ermilov  Sysadmin and DBA,
[EMAIL PROTECTED]   Sunbay Software AG,
[EMAIL PROTECTED]  FreeBSD committer,
+380.652.512.251Simferopol, Ukraine

http://www.FreeBSD.org  The Power To Serve
http://www.oracle.com   Enabling The Information Age



msg38321/pgp0.pgp
Description: PGP signature

Re: make includes

[Bruce Evans]

On Tue, 14 May 2002, Ruslan Ermilov wrote:

> Yes.  "make includes" has been modified to mean "build includes",
> and the new "make incsinstall" has been added to "install" them.
> So the correct sequence is "make includes incsinstall".
>
> I'm still unsure about the name; I'd have liked to rename it to
> "includesinstall" but that is too long.

I still prefer something like
"__private_part_of_installworld_to_install_headers_dont_use_directly".

Bruce


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

Référencement

[Le Monstre]

Bonjour ,
Venant de visiter votre site web ,
nous vous invitons à venir vous réferencer sur MonsterSexe.com ,
annuaire pour adultes , afin d'augmenter votre trafic .

Voici le lien direct vers le formulaire d'abonnement :
http://www.monstersexe.com/inscription.php3

Nous vous remercions d'avance .

Cordialement ,
[EMAIL PROTECTED]

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

bad tcp cksum fffe!

[Cristan Szmajda]

Dear freebsd-current,

Any suggestions you have regarding this problem would be
much appreciated.

My laptop running -CURRENT is suddenly generating bad TCP
checksums when talking to some IPs but not others.  For
example, 129.94.209.220 is a problem,

17:08:47.026823 129.94.233.200.1032 > 129.94.209.220.22: S
[bad tcp cksum fffe!] 3868790363:3868790363(0) win 65535

(DF) (ttl 64, id 347, len 68)

17:08:50.676968 129.94.233.200.1033 > 129.94.173.109.22: S
[bad tcp cksum fffe!] 3810151152:3810151152(0) win 65535

(DF) (ttl 64, id 348, len 68)

but 129.94.242.14 is fine.

17:08:56.686832 129.94.233.200.1034 > 129.94.242.14.22: S
[tcp sum ok] 2395865513:2395865513(0) win 65535

(DF) (ttl 64, id 349, len 68)

17:08:56.689644 129.94.242.14.22 > 129.94.233.200.1034: S
[tcp sum ok] 990076085:990076085(0) ack 2395865514 win 10136

(ttl 254, id 7165, len 60)

17:08:56.689991 129.94.233.200.1034 > 129.94.242.14.22: .
[tcp sum ok] ack 1 win 33304
 (DF) (ttl 64, id 350, len 52)

It doesn't matter whether net.inet.tcp.rfc1323 and
net.inet.tcp.rfc1644 are off or on.  My dmesg is below.

Thanks,
-- 
Chris


Copyright (c) 1992-2001 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD 5.0-CURRENT #24: Tue May 14 15:34:56 EST 2002
cls@oedipus:/usr/src/sys/i386/compile/OEDIPUS
Timecounter "i8254"  frequency 1193182 Hz
CPU: Pentium/P55C (quarter-micron) (298.42-MHz 586-class CPU)
  Origin = "GenuineIntel"  Id = 0x582  Stepping = 2
  Features=0x8001bf
real memory  = 134152192 (131008K bytes)
avail memory = 126439424 (123476K bytes)
Preloaded elf kernel "kernel" at 0xc040b000.
Intel Pentium detected, installing workaround for F00F bug
Using $PIR table, 4 entries at 0xc00fdf80
apm0:  on motherboard
apm0: found APM BIOS v1.2, connected at v1.2
npx0:  on motherboard
npx0: INT 16 interface
pcib0:  at pcibus 0 on motherboard
pci0:  on pcib0
isab0:  at device 7.0 on pci0
isa0:  on isab0
atapci0:  port 0xfcf0-0xfcff at device 7.1 on pci0
ata0: at 0x1f0 irq 14 on atapci0
ata1: at 0x170 irq 15 on atapci0
uhci0:  at device 7.2 on pci0
uhci0: Could not map ports
device_probe_and_attach: uhci0 attach returned 6
pci0:  at 7.3 (no driver attached)
pci0:  at 8.0 (no driver attached)
pci0:  at 9.0 (no driver attached)
pci_cfgintr_unique: hard-routed to irq 9
pci_cfgintr: 0:10 INTA routed to irq 9
pcic0:  irq 9 at device 10.0 on pci0
pcic0: PCI Memory allocated: 0x4400
pccard0:  on pcic0
orm0:  at iomem 0xc-0xcbfff on isa0
atkbdc0:  at port 0x60,0x64 on isa0
atkbd0:  flags 0x1 irq 1 on atkbdc0
kbd0 at atkbd0
psm0:  irq 12 on atkbdc0
psm0: model VersaPad, device ID 0
fdc0:  at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0
fdc0: FIFO enabled, 8 bytes threshold
fd0: <1440-KB 3.5" drive> on fdc0 drive 0
pmtimer0 on isa0
ppc0:  at port 0x378-0x37f irq 7 on isa0
ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode
ppc0: FIFO with 16/16/8 bytes threshold
lpt0:  on ppbus0
lpt0: Interrupt-driven port
ppi0:  on ppbus0
sc0:  at flags 0x100 on isa0
sc0: VGA <16 virtual consoles, flags=0x300>
sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0
sio0: type 16550A
sio1 at port 0x2f8-0x2ff irq 3 on isa0
sio1: type 16550A
vga0:  at port 0x3c0-0x3df iomem 0xa-0xb on isa0
unknown:  can't assign resources
sbc0:  at port 0x220-0x22f,0x388-0x38b,0x320-0x321 irq 5 drq 1,5 on isa0
pcm0:  on sbc0
midi0:  on sbc0
midi1:  on sbc0
unknown:  can't assign resources
unknown:  can't assign resources
unknown:  can't assign resources
unknown:  can't assign resources
unknown:  can't assign resources
IP packet filtering initialized, divert enabled, rule-based forwarding enabled, 
default to deny, logging limited to 1000 packets/entry by default
IPv6 packet filtering initialized, logging limited to 1000 packets/entry
IPsec: Initialized Security Association Processing.
ad0: 6194MB  [13424/15/63] at ata0-master UDMA33
Mounting root from ufs:/dev/ad0s2a
pccard: card inserted, slot 0
pcic0: Event mask 0x9
wi0 at port 0x240-0x27f irq 9 slot 0 on pccard0
wi0: Ethernet address: 00:02:2d:02:98:7e
wi0: promiscuous mode enabled
wi0: promiscuous mode disabled



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