Re: [FreeBSD-Announce] FreeBSD 2.2.9 Released!

2016-04-01 Thread Ruslan Ermilov
Hi,

At Nginx, we are committed to supporting a wide range of
BSD-like operating systems and their releases.  It's our
great pleasure to report that it's now again possible to
build current nginx sources with FreeBSD 2.2.9.  We know
that many highload setups still use this FreeBSD version.

On Fri, Apr 01, 2016 at 01:45:04PM +, Maxim Dounin wrote:
> details:   http://hg.nginx.org/nginx/rev/8426275a13fd
> branches:  
> changeset: 6500:8426275a13fd
> user:  Maxim Dounin <mdou...@mdounin.ru>
> date:  Fri Apr 01 16:38:31 2016 +0300
> description:
> Compatibility with FreeBSD 2.2.9.
> 
> Added (RTLD_NOW | RTLD_GLOBAL) to dlopen() test.  There is no RTLD_GLOBAL
> on FreeBSD 2.2.9.
> 
> Added uint32_t test, with fallback to u_int32_t, similar to uint64_t one.
> Added fallback to u_int32_t in in_addr_t test.
> 
> With these changes it is now possible to compile nginx on FreeBSD 2.2.9
> with only few minor warnings (assuming -Wno-error).

On Sat, Apr 01, 2006 at 01:30:09PM -0700, Scott Long wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> It is my great pleasure and privilege to announce the availability of
> FreeBSD 2.2.9-RELEASE.  This release is the culmination of SEVENTY-SEVEN
> months of tireless work by the FreeBSD developers, users, their children,
> and their pets.  Significant features in this release:
> 
> - - XFree86 3.3.3, the industry leader in support for cutting edge PCI
>   graphics adapters and 2D acceleration.
> - - The 8GB barrier in IDE drive sizes has finally been broken.  The wd(4)
>   driver now supports unimaginable sizes of 137GB on a single drive!
> - - Support for all of the latest high-speed FAST-WIDE (20MB/s) SCSI-2
>   controllers.
> - - The Linux emulator is now able to run Quake2 out-of-the-box.
> 
> A full description of the release can be found here:
> 
>   ftp://ftp.FreeBSD.org/pub/FreeBSD/releases/i386/2.2.9-RELEASE/README.TXT
>   ftp://ftp.FreeBSD.org/pub/FreeBSD/releases/i386/2.2.9-RELEASE/RELNOTES.TXT
>  
> 
>  Availability
>  -
> 
> FreeBSD 2.2.9-RELEASE supports the i386 architecture and can be installed
> directly over the net using bootable media or copied to a local NFS/FTP
> server.
> 
> Please continue to support the FreeBSD Project by purchasing media
> from one of our supporting vendors.  The following companies will be
> offering FreeBSD 2.2.9 based products:
> 
> ~   FreeBSD Mall, Inc.http://www.freebsdmall.com/
> ~   Daemonnews, Inc.  http://www.bsdmall.com/freebsd1.html
> 
> If you can't afford FreeBSD on media, are impatient, or just want to
> use it for evangelism purposes, then by all means download the ISO
> images.  We can't promise that all the mirror sites will carry the
> larger ISO images, but they will at least be available from the
> following sites.
> 
>  FTP
>  ---
> 
> At the time of this announcement the following FTP sites have FreeBSD
> 2.2.9-RELEASE available.
> 
>   ftp://ftp.FreeBSD.org/pub/FreeBSD/releases
> 
> FreeBSD is also available via anonymous FTP from mirror sites in the
> following countries: Argentina, Australia, Brazil, Bulgaria, Canada,
> China, Czech Republic, Denmark, Estonia, Finland, France, Germany,
> Hong Kong, Hungary, Iceland, Ireland, Japan, Korea, Lithuania,
>  the Netherlands, New Zealand, Poland, Portugal, Romania,
> Russia, Saudi Arabia, South Africa, Slovak Republic, Slovenia, Spain,
> Sweden, Taiwan, Thailand, Ukraine, and the United Kingdom.
> 
> Before trying the central FTP site, please check your regional
> mirror(s) first by going to:
> 
> ftp://ftp..FreeBSD.org/pub/FreeBSD
> 
> Any additional mirror sites will be labeled ftp2, ftp3 and so on.
> 
> More information about FreeBSD mirror sites can be found at:
> 
> http://www.FreeBSD.org/doc/en_US.ISO8859-1/books/handbook/mirrors-ftp.html
> 
> For instructions on installing FreeBSD, please see Chapter 2 of The
> FreeBSD Handbook.  It provides a complete installation walk-through
> for users new to FreeBSD, and can be found online at:
> 
> http://www.FreeBSD.org/doc/en_US.ISO8859-1/books/handbook/install.html
> 
>  Acknowledgments
>  
> 
> The release engineering team for 2.2.9-RELEASE includes:
> 
> Scott Long <sco...@freebsd.org> Release Engineering
> Ruslan Ermilov <r...@freebsd.org> I386, creative director
> Sniffy The Wonder Cat Warrm lap, typing assistance
> Max The Dancing Cat   Early morning wakeups, QA
> Sammy The Tiny CatFace licks, QA
> 
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.2 (FreeBSD)
> 
> iD8DBQFELuG+HTr20QF8Xr8RAkoyAJ4nU4v9TK/Tjh8eEGbjNtGxmiVu0gCfcNtg
> oNz6FNHVuv87MSKJeXJcMAU=
> =Z5hh
> -END PGP SIGNATURE-


-- 
Ruslan Ermilov
r...@freebsd.org
FreeBSD committer
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: [RFC] Un-staticise the toolchain

2012-04-27 Thread Ruslan Ermilov
On Fri, Apr 27, 2012 at 11:58:59AM +0300, Konstantin Belousov wrote:
 On Thu, Apr 26, 2012 at 05:41:40PM +0400, Ruslan Ermilov wrote:
  On Thu, Apr 26, 2012 at 12:35:48PM +0300, Konstantin Belousov wrote:
[...]
   Patch below makes the dynamically linked toolchain a default, adding an
   WITHOUT_SHARED_TOOLCHAIN build-time option for real conservators.
   
   I did not looked in details why including bsd.own.mk makes NO_MAN
   non-functional. Please see the diffs for gnu/usr.bin/cc1*/Makefile.
  
  Because you include bsd.own.mk before NO_MAN is defined, and the way
  how .if works in make(1).
 
 What is the 'right' thing to do then ?
 
 Postpone the inclusion of bsd.own.mk after NO_MAN definition ? This makes
 the .if $MK_SHARED_TOOLCHAIN to not work.
 
 Or, continue to do what I have done, using 'MAN=' instead ?

Two ways, both are demonstrated by gnu/lib/libgcov/Makefile:

- Define NO_* before including bsd.own.mk so it sets the
  corresponding MK_* variable appropriately, and before testing
  the MK_*.  

- Remove NO_*, include bsd.own.mk, then set MK_MAN=no.

(The nearby gnu/lib/libssp/Makefile has a similar problem with
NO_PROFILE.)

 N.B. I will commit the change, with defaults kept to build toolchain static,
 just to avoid bikeshed.

I think this is the right approach.

Regarding your patch...

By placing SHARED_TOOLCHAIN to __DEFAULT_NO_OPTIONS list in
bsd.own.mk, you already had MK_SHARED_TOOLCHAIN set to no by
default, which preserves the current status quo of building
toolchain static.  But you misspelled
tools/build/options/WITH_STATIC_TOOLCHAIN, probably as the result
of iteratively modifying your change.  The option and this file
should be named WITH_SHARED_TOOLCHAIN, the opposite of the
default.  Anyway, checking that the resulting src.conf(5) manpage
sounds sensible is a good idea.  As for the contents of this file,
I wouldn't call ar/ranlib a librarian but rather a library
archives manager, as per POSIX.  Your diff also suggests that it
misses a newline at EOF.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: HEADSUP: /etc/malloc.conf format change

2012-04-26 Thread Ruslan Ermilov
On Wed, Apr 25, 2012 at 10:43:59AM -0700, Jason Evans wrote:
 On Apr 25, 2012, at 9:39 AM, Ruslan Ermilov wrote:
  So you removed _malloc_options that was part of the documented
  programming API, while some software made use of it.
[...]
  Please explore the possibility to add backwards compatiblity for 
  the documented API, or at the very least provide a mean to 
  detect this otherwise disruptive and hard to detect change
  for a programmer.
 
 A __FreeBSD_version bump seems like a good idea to me, but
 adding backward compatibility for _malloc_options is
 questionable at best.  Of the 17 options that _malloc_options
 supported, only 6 have directly corresponding options in
 malloc_conf, plus another 3 that would present strange quirks
 (fragile and difficult to precisely document) if an attempt
 were made to provide compatibility.  In past iterations I was
 always careful to provide as much option compatibility as
 possible over the lifetime of each release (e.g., 'H' in
 RELENG_7), but individual options came and went  with major
 releases.
 
 _malloc_options could only be pushed so far, and when it hit
 its breaking point I replaced it.  Creaky compatibility is IMO
 a liability rather than an asset.  In the case of nginx, it
 looks like a __FreeBSD_version bump is exactly what it needs.
 I'll try to get that done today.

Well, thanks for that, and for all your hard work with malloc().

 On a related note, is there any way to find all ports that
 refer to _malloc_options without extracting source for all of
 them?  I considered being proactive about finding software that
 depends on _malloc_options, but no tractable approaches came to
 mind.

That was already answered by Mark.


-- 
Ruslan Ermilov
r...@freebsd.org
FreeBSD committer
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: [RFC] Un-staticise the toolchain

2012-04-26 Thread Ruslan Ermilov
On Thu, Apr 26, 2012 at 12:35:48PM +0300, Konstantin Belousov wrote:
 I think it is time to stop building the toolchain static. I was told that
 original reasoning for static linking was the fear of loosing the ability
 to recompile if some problem appears with rtld and any required dynamic
 library. Apparently, current dependencies are much more spread, e.g. /bin/sh
 is dynamically linked, and statically linked make does not solve anything.


r76801 | sobomax | 2001-05-18 13:05:56 +0400 (Fri, 18 May 2001) | 6 lines

By default build make(1) as a static binary. It costs only 100k of additional
disk space, buf provides measureable speed increase for make-intensive
operations, such as pkg_version(1), `make world' and so on.

MFC after:  1 week



Have things changed enough that the above is not true anymore?

 Patch below makes the dynamically linked toolchain a default, adding an
 WITHOUT_SHARED_TOOLCHAIN build-time option for real conservators.
 
 I did not looked in details why including bsd.own.mk makes NO_MAN
 non-functional. Please see the diffs for gnu/usr.bin/cc1*/Makefile.

Because you include bsd.own.mk before NO_MAN is defined, and the way
how .if works in make(1).
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: HEADSUP: /etc/malloc.conf format change

2012-04-25 Thread Ruslan Ermilov
On Tue, Apr 17, 2012 at 12:34:20PM -0700, Jason Evans wrote:
 As a result of the recent jemalloc update, the format for
 /etc/malloc.conf has changed.  If your system has an old-style
 /etc/malloc.conf, you will want to delete it prior to
 installworld, and optionally re-create it using the new format
 after rebooting.  See malloc.conf(5) for details (specifically
 the TUNING section and the opt.* entries in the MALLCTL
 NAMESPACE section).
 
 The MALLOC_OPTIONS environment variable and the _malloc_options
 global do not pose the same headache, because their new
 counterparts are named MALLOC_CONF and malloc_conf,
 respectively.

So you removed _malloc_options that was part of the documented
programming API, while some software made use of it.

While removing part of the documented API was definitely a bad
idea, you didn't provide any mean to detect this change 
programmatically, neither through a macro test, nor by bumping
__FreeBSD_version.  The only way now is to try and see if it
compiles, which is far from perfect.

The way how _malloc_options is handled for binary compatibility,
by simply ignoring its value, is (ahem) questionable.

Why do I care?  The developers of the nginx web server have 
been notified today that it could not be built on FreeBSD
10.0-CURRENT anymore, due to this change, when compiled with 
nginx malloc debugging.  It's activated by the DEBUG option
of the www/nginx-devel port, if you care to try it out.

Please explore the possibility to add backwards compatiblity for 
the documented API, or at the very least provide a mean to 
detect this otherwise disruptive and hard to detect change
for a programmer.


Cheers,
-- 
Ruslan Ermilov
r...@freebsd.org
FreeBSD committer
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: Deterministic builds

2011-12-09 Thread Ruslan Ermilov
On Fri, Dec 09, 2011 at 12:16:39PM +0100, Erik Cederstrand wrote:
 I've been working on a project to make it possible to produce deterministic
 builds with FreeBSD. By this I mean building a FreeBSD distribution twice
 from the same code base and having all files in the two distributions match
 by md5 sum. Currently, this is not the case.
[...]
 I'd be very grateful for any comments on the approach and the patch.

The idea is not new.  Setting CROSS_BUILD_TESTING during the buildworld
addressed similar issues at a time I wrote it, to compare cross builds
to native ones, with several exceptions.  I haven't tested it for years,
so things might have changed, but it's still a good idea to give it a
try.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: Deterministic builds

2011-12-09 Thread Ruslan Ermilov
On Fri, Dec 09, 2011 at 03:25:40PM +0100, Erik Cederstrand wrote:
 Den 09/12/2011 kl. 14.37 skrev Ruslan Ermilov:
 
  On Fri, Dec 09, 2011 at 12:16:39PM +0100, Erik Cederstrand wrote:
  I've been working on a project to make it possible to produce deterministic
  builds with FreeBSD. By this I mean building a FreeBSD distribution twice
  from the same code base and having all files in the two distributions match
  by md5 sum. Currently, this is not the case.
  [...]
  I'd be very grateful for any comments on the approach and the patch.
  
  The idea is not new.  Setting CROSS_BUILD_TESTING during the buildworld
  addressed similar issues at a time I wrote it, to compare cross builds
  to native ones, with several exceptions.  I haven't tested it for years,
  so things might have changed, but it's still a good idea to give it a
  try.
 
 I can't see that CROSS_BUILD_TESTING does anything in current other
 than adding TARGET and TARGET_ARCH to OBJTREE in src/Makefile.inc1?

Take a look at src/tools/build/Makefile.

Last time I checked (July 19, 2005) there were only the following
diffs when verifying cross-builds (verifying included doing a
native build and binary comparing it with a cross-build made on
i386/amd64):

: *:
: /usr/lib/libsupc++.a:vec.o  symbols with generated names
: /usr/lib/libobjc.a:NXConstStr.o
: /usr/lib/libobjc.a:Object.o
: /usr/lib/libobjc.a:Protocol.o
: 
: i386 - amd64
: /usr/sbin/isdn* timestamp (__TIME__) (i386 only)
: 
: sparc64 - amd64
: /usr/share/misc/magic*.mgc  mkmagic not endianness clean


-- 
Ruslan Ermilov
r...@freebsd.org
FreeBSD committer
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: awk(1) segfaults when building kernel modules

2011-08-11 Thread Ruslan Ermilov
On Wed, Aug 10, 2011 at 10:12:11PM +0400, Test Rat wrote:
 `make -s buildkernel' seems to contain lots of segfaults after recent
 update of one-true-awk in r224731. It chokes on sys/conf/kmod_syms.awk.
 The case can be reduced to
 
   $ awk 'BEGIN { delete ARGV[1] } END { print ARGV[1] }' blah
   [...]

Should be fixed in r224776; please confirm.


Cheers,
-- 
Ruslan Ermilov
r...@freebsd.org
FreeBSD committer
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: awk(1) segfaults when building kernel modules

2011-08-10 Thread Ruslan Ermilov
On Wed, Aug 10, 2011 at 08:02:32PM +, Alexander Best wrote:
 On Wed Aug 10 11, Navdeep Parhar wrote:
  On Wed, Aug 10, 2011 at 11:12 AM, Test Rat ttse...@gmail.com wrote:
   `make -s buildkernel' seems to contain lots of segfaults after recent
   update of one-true-awk in r224731. It chokes on sys/conf/kmod_syms.awk.
 
 just out of curiosity: what's the point of doing a vendor import during a
 beta phase? isn't this exactly the kind of stuff you DON'T want to do, because
 it can only turn out badly?

The previous version had a bug in handling the -v option
since the last import.  I sent a patch to bwk@ months ago,
but he only released the new version that included a fix
on August 7.

Unfortunately, while fixing another bug (fixed day 1 bug
that resurrected deleted elements of ARGV when used as
filenames (in lib.c).), not all code was fixed, and a NULL
pointer deference bug is triggered by the following code
snippet:

awk 'BEGIN{delete ARGV[1]}{}' arg

%%%
Index: head/contrib/one-true-awk/lib.c
===
--- head/contrib/one-true-awk/lib.c (revision 224760)
+++ head/contrib/one-true-awk/lib.c (working copy)
@@ -89,8 +89,13 @@
char *p;
 
for (i = 1; i  *ARGC; i++) {
-   if (!isclvar(p = getargv(i))) { /* find 1st real filename */
-   setsval(lookup(FILENAME, symtab), getargv(i));
+   p = getargv(i); /* find 1st real filename */
+   if (p == NULL || *p == '\0') {  /* deleted or zapped */
+   argno++;
+   continue;
+   }
+   if (!isclvar(p)) {
+   setsval(lookup(FILENAME, symtab), p);
return;
}
setclvar(p);/* a commandline assignment before filename */
%%%

 imho r224731 should completely be reverted. aren't those exactly the kind of
 commits re@ shouldn't approve?


-- 
Ruslan Ermilov
r...@freebsd.org
FreeBSD committer
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: weekly_catman not generating the right result?

2011-08-03 Thread Ruslan Ermilov
On Sun, Jul 31, 2011 at 03:57:01PM +0200, Ulrich Spörlein wrote:
 On Sun, 2011-07-31 at 05:43:39 -0700, Xin LI wrote:
  On 07/31/11 05:17, Ulrich Spörlein wrote:
   On Sun, 2011-07-31 at 01:22:36 -0700, Xin LI wrote:
   Hi,
   
   I just noticed that weekly_catman is not generating the right
   result, e.g. instead of a highlight NAME, it gives 1mNAME0m (looks
   like the escape character is missing here).
   
   Is this a known issue?
   
   Now it is :)
   
   This is due to the recent changes that made groff emit ANSI
   sequences and catman(1) is still putting col(1) in the pipe, which is
   not really required and gobbles up part of the escape sequences.
   
   Please try the attached patch. Thanks.
  
  Thanks, that fixes the problem.
  
  Note that I noticed that setting PAGER to less won't work.  Looking at
  my 8.2-RELEASE system, the rendered catpages are using ^H when
  highlighting while on -CURRENT it's an escape sequence (but I didn't see
  any change to nroff script nor catman itself)...
 
 The change that did this is r222648. You'll need to use `less -Rs' as
 your PAGER/MANPAGER (or export LESS=-Rs).
 
 It's debatable if we want catpages to retain the old way of marking up
 bold and underlined text.
 
 Ruslan: bsd.doc.mk was told to not use SGR in r222647, does it make
 sense to do the same for catpages?

This probably affects your patch that I've just reviewed, but I think
you're right in that catpages should be in the old fashioned format.


Cheers,
-- 
Ruslan Ermilov
r...@freebsd.org
FreeBSD committer
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: WITHOUT_INSTALLLIB broken?

2011-06-16 Thread Ruslan Ermilov
On Thu, Jun 16, 2011 at 01:50:17PM +0200, Milan Obuch wrote:
 Hi,
 
 I encountered an error when WITHOUT_INSTALLLIB option is specified
 for 'make buildworld' process. I documented this issue with build logs
 at my page, http://www.dino.sk/build/2011-06-16-log1 and
 http://www.dino.sk/build/2011-06-16-log2 show how to test this. At this
 time, there is no /etc/make.conf nor /etc/src.conf.
 
 Any idea what's wrong with libegacy.a here?

This option wasn't designed for build, only for install.  It's like
WITHOUT_TOOLCHAIN, which is documented to not work for build targets.


-- 
Ruslan Ermilov
r...@freebsd.org
FreeBSD committer
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: WITHOUT_INSTALLLIB broken?

2011-06-16 Thread Ruslan Ermilov
On Thu, Jun 16, 2011 at 05:09:05PM +0400, Eir Nym wrote:
 On 16 June 2011 16:55, Ruslan Ermilov r...@freebsd.org wrote:
  On Thu, Jun 16, 2011 at 01:50:17PM +0200, Milan Obuch wrote:
  Hi,
 
  I encountered an error when WITHOUT_INSTALLLIB option is specified
  for 'make buildworld' process. I documented this issue with build logs
  at my page, http://www.dino.sk/build/2011-06-16-log1 and
  http://www.dino.sk/build/2011-06-16-log2 show how to test this. At this
  time, there is no /etc/make.conf nor /etc/src.conf.
 
  Any idea what's wrong with libegacy.a here?
 
  This option wasn't designed for build, only for install.  It's like
  WITHOUT_TOOLCHAIN, which is documented to not work for build targets.
 
 
 Should this be simply ignored for build targets?

build targets utilize install targets internally, so this is
hardly doable.


-- 
Ruslan Ermilov
r...@freebsd.org
FreeBSD committer
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


[HEADS UP] color and page width support in man(1)

2011-06-03 Thread Ruslan Ermilov
Hi there,

On a freshly installed -CURRENT, to view a colorized manpage in color
and in full terminal width, try this:

env MANCOLOR=yes MANWIDTH=tty man grotty

Both features are disabled by default for POLA reasons.  Bikeshedding
will be redirected to /dev/null.


Cheers,
-- 
Ruslan Ermilov
r...@freebsd.org
FreeBSD committer
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: [PATCH] Fix CFLAGS overwrite by Makefile

2011-05-25 Thread Ruslan Ermilov
On Tue, May 24, 2011 at 11:08:52PM -0400, Arnaud Lacombe wrote:
 Hi,
 
 On Tue, May 24, 2011 at 10:54 PM, Arnaud Lacombe lacom...@gmail.com wrote:
  ps: for static library and loader, I derived the total size as the sum
  of the size of the text/data/bss section of the member object using :
 
  size *.o | awk 'BEGIN {text=0; data=0; bss=0;}; {text+=$1; data+=$2;
  bss+=$3}; END {print text   data   bss  '$i'}'
 
  where $i is the cpu type to test. make(1) is passed either CPUTYPE=$i
  for i in i[3456]86, or the empty string. The compiler used for the
  test is gcc, and it is the compiler build during a buildworld stage,
  in the tmp directory.
 
 just to cut loose any question about my environment, additionally to
 the original patch, I made the following modification to the tree to
 try to isolate it from the host:
  - applied the following patch:

[...]

  - manually created two symlinks:
  1) include/machine - ../sys/i386/include/
  2) include/x86 - ../sys/x86/include/
 
 The host is running a custom 8.2-STABLE/amd64 kernel (only config
 change) on the following CPU:
 
 CPU: Intel(R) Xeon(R) CPU   X3430  @ 2.40GHz (2394.00-MHz K8-class 
 CPU)
   Origin = GenuineIntel  Id = 0x106e5  Family = 6  Model = 1e  Stepping = 5
  
 Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE
   
 Features2=0x98e3fdSSE3,DTES64,MON,DS_CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,POPCNT
   AMD Features=0x28100800SYSCALL,NX,RDTSCP,LM
   AMD Features2=0x1LAHF
   TSC: P-state invariant
 
 I am still not sure what is the default gcc target architecture on this 
 machine.

Why not go along a supported way, and do a cross-build?


-- 
Ruslan Ermilov
r...@freebsd.org
FreeBSD committer
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: buildworld fails building _dtrace_tools

2010-07-01 Thread Ruslan Ermilov
On Wed, Jun 30, 2010 at 04:26:53PM +0200, Claude Buisson wrote:
 Anton Shterenlikht wrote:
  HI Claude
 
  http://www.mavetju.org/mail/view_message.php?list=freebsd-currentid=3145015
 
  Have you got a reply to your question?
  Have you solved it?
 
 
  I'm now seeing the same on i386.
 
  Any advice?
 
  many thanks
  anton
 
 
 Hi Anton,
 
 I never received any reply..
 
 I have done a binary search and found that the problem was introduced by svn
 revision r204339 dated February 25 by ru@

Let's admit that the problem was uncovered, not introduced.  The mentioned
commit of mine is correct (try building stuff statically linked to see).

 Reverting this revision by hand, I have been able to build a system 
 WITH_CDDL
 which could be used to rebuild from the current sources.
 
 But the original problem is always here: how to make a buildworld WITH_CDDL 
 on
 a system built WITHOUT_CDDL ?
 
 I sent a message to ru@ on April 11, without success..

Sorry, still swamped with real life issues.  I think there are basically
two options for bootstrapping:

- reinstall stuff from some release media (e.g., take the required
  bits from the nearby release tarballs)

- manually build/install the missing stuff from sources (if you have'em)

Then do a buildworld.  This problem is similar to the case when you
lose /usr/bin/make or some other host tool used during the build.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: Coming back to the btxld: No such file or directory installworld error

2010-06-28 Thread Ruslan Ermilov
On Sun, Jun 27, 2010 at 11:27:41PM -0700, Garrett Cooper wrote:
 On Sun, Jun 27, 2010 at 10:54 PM, Ruslan Ermilov r...@freebsd.org wrote:
  On Sun, Jun 27, 2010 at 01:14:59PM -0700, Garrett Cooper wrote:
  Hi Ruslan,
      I've run into this particular error twice now in the past couple
  of weeks when building with -j24 on a memory disk and I was wondering
  if there was an missing dependency / race somewhere or something
  (perhaps make obj?):
 
  === sys/boot/i386/boot2 (install)
  # ...
  btxld -v -E 0x2000 -f bin -b
  /usr/obj/scratch/freebsd/current/sys/boot/i386/boot2/../btx/btx/btx -l
  boot2.ldr  -o boot2.ld -P 1 boot2.bin
  btxld: No such file or directory
  *** Error code 1
 
  The install target isn't supposed to build stuff, only install it.
  When you see it trying to build something, this can be indicative of:
 
  - build wasn't run (e.g., after an update);
 
 Not the case (I ran buildworld and everything else up to that point
 installed happily).
 
  - a computer's date/time is set to the past (causing wrong date/time
   to be set on output files = causing them to be considered out-of-
   date by make(1)); check with date(1).
 
 My computer hasn't been time traveling lately :/ (If my calculations
 are correct, when this baby hits eighty-eight miles per hour... you're
 gonna see some serious shit.).
 
  - source files have modification times pointing to the future which
   fools make(1) into thinking that it should rebuild some target;
   check with find /usr/src -mtime -0.
 
 This seems unlikely as well.

Did you actually check that?  (Date/time on source files can be
set by CVSup servers...)

 Is there a possibility that the existing Makefiles work by accident
 when -j  24 because the actions aren't executed in order :(?

install isn't supposed to build stuff.  The only exception I could
remember of is timezone data files, plus some .db files.  I strongly
suggest checking the date/time of your computer and source files.

If it's really okay, then check the following: run -j24 build, then
run make -C /usr/src/sys/boot -nn -- if you see that it wants to
build something, then this is a problem we should look into and try
to fix.


Cheers,
-- 
Ruslan Ermilov
r...@freebsd.org
FreeBSD committer
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: Coming back to the btxld: No such file or directory installworld error

2010-06-27 Thread Ruslan Ermilov
On Sun, Jun 27, 2010 at 01:14:59PM -0700, Garrett Cooper wrote:
 Hi Ruslan,
 I've run into this particular error twice now in the past couple
 of weeks when building with -j24 on a memory disk and I was wondering
 if there was an missing dependency / race somewhere or something
 (perhaps make obj?):
 
 === sys/boot/i386/boot2 (install)
 # ...
 btxld -v -E 0x2000 -f bin -b
 /usr/obj/scratch/freebsd/current/sys/boot/i386/boot2/../btx/btx/btx -l
 boot2.ldr  -o boot2.ld -P 1 boot2.bin
 btxld: No such file or directory
 *** Error code 1

The install target isn't supposed to build stuff, only install it.
When you see it trying to build something, this can be indicative of:

- build wasn't run (e.g., after an update);

- a computer's date/time is set to the past (causing wrong date/time
  to be set on output files = causing them to be considered out-of-
  date by make(1)); check with date(1).

- source files have modification times pointing to the future which
  fools make(1) into thinking that it should rebuild some target;
  check with find /usr/src -mtime -0.


HTH,
-- 
Ruslan Ermilov
r...@freebsd.org
FreeBSD committer
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


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

2003-11-17 Thread Ruslan Ermilov
On Sun, Nov 16, 2003 at 09:51:30PM -0800, Kris Kennaway wrote:
 On Mon, Nov 17, 2003 at 12:51:49AM -0500, Anthony Schneider wrote:
  This isn't *totally* the case. :)
  
  My problem is that in upgrading from 5.1-RELEASE to -CURRENT today,
  installworld fails at installing test with (hand copied):
 
 Except we weren't talking about buildworld - sorry to hear you're
 having problems though.  Perhaps this upgrade path needs to be tested
 to confirm your problem.
 
Unless someone has hosed the change from src/Makefile.inc1,v 1.392,
this should not be a problem.

Oh, I now see there was a small 16-hour window where this was broken,
before the initial commit to make the dynamic root default, and the
follow-up Makefile.inc1,v 1.397 commit that took care of that.

Anyway, this should not be a problem anymore, and it isn't even worth
of an entry in src/UPDATING.   ;)


Cheers,
-- 
Ruslan Ermilov  Sysadmin and DBA,
[EMAIL PROTECTED]   Sunbay Software Ltd,
[EMAIL PROTECTED]   FreeBSD committer


pgp0.pgp
Description: PGP signature


Re: making a release

2003-11-14 Thread Ruslan Ermilov
On Fri, Nov 14, 2003 at 07:18:05AM +1000, Andy Farkas wrote:
 Scott Long wrote:
 
  I use the following all of the time:
 
  cd /usr/src/release ; make release BUILDNAME=5.1-CURRENT
  CHROOTDIR=/usr/release CVSROOT=/usr/ncvs
 
 Quick question: is it ok to do make -jn release ?
 
No, it's not.  But world- and kernel-related parts of make
release can be built in parallel, here's a relevant excerpt
from release/Makefile:

# If you want to pass flags to the world build such as -j X, use
# WORLD_FLAGS.  Similarly, you can specify make flags for kernel
# builds via KERNEL_FLAGS.
# Similarly, you can specify make flags for make readmes via PORTREADMES_FLAGS.
#WORLD_FLAGS=-j4
#KERNEL_FLAGS=-j4
#PORTREADMES_FLAGS=-j4

The release(7) manpage mumbles something about that, but not too verbose.


Cheers,
-- 
Ruslan Ermilov  Sysadmin and DBA,
[EMAIL PROTECTED]   Sunbay Software Ltd,
[EMAIL PROTECTED]   FreeBSD committer


pgp0.pgp
Description: PGP signature


Re: make install fails on 11.pm cst current cvs..

2003-11-07 Thread Ruslan Ermilov
On Thu, Nov 06, 2003 at 05:00:04PM -0800, Neal Hamilton Jr. wrote:
 I cvsup at 11 pm CST. It compiles fine however make installworld fails
 with:
 
 #make installworld
[...]
 --
  Installing everything..
 --
 cd /usr/src; make -f Makefile.inc1 install
 === share/info
 === include
 creating osreldate.h from newvers.sh
 touch: not found
 *** Error code 127
 
SEARCH THE ARCHIVES!  SEARCH THE ARCHIVES!  SEARCH THE ARCHIVES!


Cheers,
-- 
Ruslan Ermilov  Sysadmin and DBA,
[EMAIL PROTECTED]   Sunbay Software Ltd,
[EMAIL PROTECTED]   FreeBSD committer


pgp0.pgp
Description: PGP signature


Re: buildworld error: rm: tar: is a directory

2003-11-01 Thread Ruslan Ermilov
On Sat, Nov 01, 2003 at 04:48:42AM -0800, [EMAIL PROTECTED] wrote:
 I'm having problems with current buildworld in gnu now on two different
 machines in current(today).  The latest is the following:
 
 rm: tar: is a directory
 *** Error code 1
 
 Stop in /usr/src/gnu/usr.bin/tar.
 *** Error code 1
 
 Stop in /usr/src/gnu/usr.bin/tar.
 *** Error code 1
 
 Stop in /usr/src/gnu/usr.bin.
 *** Error code 1
 
 I'm begining to wonder if I'm getting a complete checkout with cvsup
 of the gnu tree.
 
``rm -rf /usr/obj/usr/src/gnu/usr.bin/tar'' and try again.


Cheers,
-- 
Ruslan Ermilov  Sysadmin and DBA,
[EMAIL PROTECTED]   Sunbay Software Ltd,
[EMAIL PROTECTED]   FreeBSD committer


pgp0.pgp
Description: PGP signature


Re: make release...

2003-10-21 Thread Ruslan Ermilov
On Tue, Oct 21, 2003 at 04:51:22PM +0930, Daniel O'Connor wrote:
[...]
 Either apply the patch I attached and add CPNOTCVS= to your make release 
 options, or check out the repository.
 
In HEAD, a similar functionality is already provided through the
use of the EXTSRCDIR variable.  JFYI.


Cheers,
-- 
Ruslan Ermilov  Sysadmin and DBA,
[EMAIL PROTECTED]   Sunbay Software Ltd,
[EMAIL PROTECTED]   FreeBSD committer


pgp0.pgp
Description: PGP signature


HEADS UP: can't find kernel source tree error when building the kernel.

2003-10-03 Thread Ruslan Ermilov
On Fri, Oct 03, 2003 at 12:28:42PM -0500, Jacques A. Vidrine wrote:
 On Fri, Oct 03, 2003 at 07:57:51PM +0300, Clau wrote:
  hello,
  
  i just downloaded via cvsup the latest kernel for freebsd 5.1.
  i had a problem with it, more exactly when i did a make depend
  it stopped at some place, and gave me this error:
  can't find kernel source tree
  i fixed this by modifying this piece of code from /usr/src/sys/conf/kmod.mk
  (it starts with line 167 in the file)
  
  .for _dir in ${.CURDIR}/../.. ${.CURDIR}/../../.. /sys /usr/src/sys
  .if !defined(SYSDIR)  exists(${_dir}/kern/)
  SYSDIR= ${_dir}
  .endif
  .endfor
  .if !defined(SYSDIR) || !exists(${SYSDIR}/kern/)
  .error can't find kernel source tree
  .endif
  
  i removed the last / from /kern/ and now it seems it can find the 
  directory.
  i don't know if this is a general problem, or it is just in the case of 
  my system.
 
 How are you building the kernel?   Are you using `make buildworld' first
 and then `make buildkernel' (or `make kernel')?
 
Maybe now it will be more obvious why I thought that upgrade_checks
should always be done, for all standard src/Makefile targets.
Currently, you either need to upgrade your /usr/bin/make binary
manually, or to use this command from /usr/src:

make buildkernel -DALWAYS_CHECK_MAKE ...

with up-to-date tools/regression/usr.bin/make/ and usr.bin/make/
sources.


Cheers,
-- 
Ruslan Ermilov  Sysadmin and DBA,
[EMAIL PROTECTED]   Sunbay Software Ltd,
[EMAIL PROTECTED]   FreeBSD committer


pgp0.pgp
Description: PGP signature


Re: Problem upgrading 4.8 to 5.1

2003-10-02 Thread Ruslan Ermilov
On Thu, Oct 02, 2003 at 11:08:53PM +0200, John Angelmo wrote:
 OK I'm trying to upgrade from 4.8 (pre 4.9) to 5.1 (using the 5_1 tag 
 with cvsup)
 
 The problem I get is this:
 
 cc -fpic -DPIC -O -pipe -DPTHREAD_KERNEL 
 -I/usr/src/lib/libpthread/../libc/include 
 -I/usr/src/lib/libpthread/thread 
 -I/usr/src/lib/libpthread/../../include 
 -I/usr/src/lib/libpthread/arch/i386/include 
 -I/usr/src/lib/libpthread/sys 
 -I/usr/src/lib/libpthread/../../libexec/rtld-elf -fno-builtin 
 -D_LOCK_DEBUG -D_PTHREADS_INVARIANTS -Wall  -c 
 /usr/src/lib/libpthread/sys/lock.c -o lock.So
 building shared library libkse.so.1
 thr_libc.So: In function `sigaction':
 thr_libc.So(.text+0x54): multiple definition of `_sigaction'
 thr_sigaction.So(.text+0x0): first defined here
 thr_libc.So: In function `sigprocmask':
 thr_libc.So(.text+0x34): multiple definition of `_sigprocmask'
 thr_sigprocmask.So(.text+0x0): first defined here
 *** Error code 1
 
 Stop in /usr/src/lib/libpthread.
 *** Error code 1
 
 Stop in /usr/src/lib.
 *** Error code 1
 
 Stop in /usr/src.
 *** Error code 1
 
 Stop in /usr/src.
 *** Error code 1
 
 Stop in /usr/src.
 *** Error code 1
 
 Stop in /usr/src.
 
 
 Is this a known problem and what can I do about it?
 
Yes, this is a known problem (please see the attached).
I am yet to hear from the Security Officers team if they
want this in RELENG_5_1 or not, as this CVS branch is
under the so@ jurisdiction now.

Since this is the 3rd report I hear on the issue, my
recommendation would be to let these changes in, but
we'll see if the so@'s mileage varies.


Cheers,
-- 
Ruslan Ermilov  Sysadmin and DBA,
[EMAIL PROTECTED]   Sunbay Software Ltd,
[EMAIL PROTECTED]   FreeBSD committer
---BeginMessage---
On Tue, Sep 02, 2003 at 07:49:55PM +0300, ODHIAMBO Washington wrote:
 * Ruslan Ermilov [EMAIL PROTECTED] [20030902 18:49]: wrote:
  On Tue, Sep 02, 2003 at 06:24:05PM +0300, ODHIAMBO Washington wrote:
   * Ruslan Ermilov [EMAIL PROTECTED] [20030902 13:09]: wrote:
   
   Hello Ruslan,
   
   http://ns2.wananchi.com/~wash/FreeBSD/buildworld-fail.txt
   
   available, compressed.
   
  Now this is much better.  I will look into it, and let you know.
 
 
 Awaiting eagerly, with a dodo FreeBSD box here ;)
 I did the following:
 
 cd /usr
 rm -rf src
 cvsup again, tag=RELENG_5_1
 make buildworld
 
 It still failed.
 
I've tracked it down to the same problem we were having ealier
with the libpthread build.  You can either merge the following
revisions manually, or wait for an official fix to pop up in
RELENG_5_1:

Makefile.inc1: 1.365, 1.367
lib/libpthread/support/Makefile.inc: 1.2


Cheers,
-- 
Ruslan Ermilov  Sysadmin and DBA,
[EMAIL PROTECTED]   Sunbay Software Ltd,
[EMAIL PROTECTED]   FreeBSD committer


pgp0.pgp
Description: PGP signature
---End Message---


pgp1.pgp
Description: PGP signature


Re: Error in /usr/src/Makefile.inc1

2003-09-25 Thread Ruslan Ermilov
On Thu, Sep 25, 2003 at 06:33:59PM +0200, Johannes Kingma wrote:
 What's wrong here?
 
 .if (!defined(NO_RESCUE) || \
 defined(RELEASEDIR))  \
 (${TARGET_ARCH} != ${MACHINE_ARCH} || ${BOOTSTRAPPING}  501101)
 _crunchide= usr.sbin/crunch/crunchide
 .endif
 
 [EMAIL PROTECTED]/usr/src]# make buildkernel
 Makefile.inc1, line 773: warning: String comparison operator should be 
 either == or !=
 Makefile.inc1, line 773: Malformed conditional ((!defined(NO_RESCUE) 
 ||  defined(RELEASEDIR))   (${TARGET_ARCH} != ${MACHINE_ARCH} || 
 ${BOOTSTRAPPING}  501101))
 Makefile.inc1, line 773: Missing dependency operator
 Makefile.inc1, line 775: if-less endif
 Makefile.inc1, line 775: Need an operator
 make: fatal errors encountered -- cannot continue
 *** Error code 1
 
 Stop in /usr/src.
 
Some of developers weren't happy with src/Makefile upgrade checks
performed for all user targets, and it's currently limited to only
buildworld by default.  To overcome this problem, please re-run
the above command with -DALWAYS_CHECK_MAKE.


Cheers,
-- 
Ruslan Ermilov  Sysadmin and DBA,
[EMAIL PROTECTED]   Sunbay Software Ltd,
[EMAIL PROTECTED]   FreeBSD committer


pgp0.pgp
Description: PGP signature


Re: upgrade from static to dynamic root

2003-09-16 Thread Ruslan Ermilov
On Mon, Sep 15, 2003 at 03:31:55PM -0700, Gordon Tetlow wrote:
 On Thu, Sep 11, 2003 at 02:44:55PM +0200, Harti Brandt wrote:
  
  Hi,
  
  I just tried to upgrade one of my systems from a static root from july to
  an actual dynamic root. The installworld went fine 'til the place where
  /bin/test is installed. At that point the installation stopped with ELF
  interpreter /libexec/ld-elf.so.1 not found. And really /libexec is not
  populated yet. May it be, that the makefile uses one of the newly
  installed tools during install? For example 'ln' to make the link test -
  [?
  
  Also, wouldn't it be helpful to populate /rescue before /bin? Just in
  the case something goes wrong between installing been and rescue for the
  first time?
 
 A dynamic root is still a little bit of a no seatbelt kind of activity.
 We should probably bring back the ${OBJDIR}/bin/sh test and if we fail,
 install /libexec/ld-elf.so.1 then reattempt the ${OBJDIR}/bin/sh test
 and continue on with life.
 
I've been able to reproduce this, and have just committed a fix for this
into Makefile.inc1.


Cheers,
-- 
Ruslan Ermilov  Sysadmin and DBA,
[EMAIL PROTECTED]   Sunbay Software Ltd,
[EMAIL PROTECTED]   FreeBSD committer


pgp0.pgp
Description: PGP signature


Re: upgrade from static to dynamic root

2003-09-15 Thread Ruslan Ermilov
On Mon, Sep 15, 2003 at 09:42:27AM +0200, Harti Brandt wrote:
 On Sun, 14 Sep 2003, Ruslan Ermilov wrote:
 
 REOn Thu, Sep 11, 2003 at 02:44:55PM +0200, Harti Brandt wrote:
 RE
 RE Hi,
 RE
 RE I just tried to upgrade one of my systems from a static root from july to
 RE an actual dynamic root. The installworld went fine 'til the place where
 RE /bin/test is installed. At that point the installation stopped with ELF
 RE interpreter /libexec/ld-elf.so.1 not found. And really /libexec is not
 RE populated yet. May it be, that the makefile uses one of the newly
 RE installed tools during install? For example 'ln' to make the link test -
 RE [?
 RE
 REIt shouldn't happen, because we save test and [ in ${INSTALLTMP}.
 REIt looks like something hardcodes /bin/test.  I've grepped the
 REsrc/ makefiles and cannot find such a place.  Where exactly did
 REit happen in the installworld for you?
 
 It installed /bin/test and then failed just when it was going to make the
 link to '['. Unfortunately this is rather hard to reproduce, unless I roll
 everything back.
 
I will see if I can reproduce it on my devbox.


Cheers,
-- 
Ruslan Ermilov  Sysadmin and DBA,
[EMAIL PROTECTED]   Sunbay Software Ltd,
[EMAIL PROTECTED]   FreeBSD committer


pgp0.pgp
Description: PGP signature


Re: Upgrading to FreeBSD 5.1

2003-09-15 Thread Ruslan Ermilov
On Mon, Sep 15, 2003 at 03:54:09PM -0500, Jacques A. Vidrine wrote:
 On Mon, Sep 15, 2003 at 11:18:24PM +0300, Ruslan Ermilov wrote:
  You mean you upgrade to RELENG_5_1?  Beware that this branch
  is currently not buildable: libpthread build is broken.
 
 Eh?  By `this branch' you mean RELENG_5_1?  How is it broken?
 
building shared library libkse.so.1
thr_libc.So: In function `sigaction':
thr_libc.So(.text+0x54): multiple definition of `_sigaction'
thr_sigaction.So(.text+0x0): first defined here
thr_libc.So: In function `sigprocmask':
thr_libc.So(.text+0x34): multiple definition of `_sigprocmask'
thr_sigprocmask.So(.text+0x0): first defined here
*** Error code 1

Basically, see the log for libpthread/support/Makefile.inc,v 1.2
where it talks why -L/usr/lib in a makefile is a Bad Idea (TM).

 If
 there is a problem (I don't know of any --- it built after I made the
 commits for the last security advisory), it is critical to fix it.
 
This worked for you because you probably test built RELENG_5_1
on a fresh HEAD system.  Please see the attached messages that
is still unanswered that talks about files/revisions involved
into a fix.


Cheers,
-- 
Ruslan Ermilov  Sysadmin and DBA,
[EMAIL PROTECTED]   Sunbay Software Ltd,
[EMAIL PROTECTED]   FreeBSD committer
---BeginMessage---
On Tue, Sep 02, 2003 at 12:37:11PM -0700, Alexander Kabaev wrote:
 kan 2003/09/02 12:37:11 PDT
 
   FreeBSD src repository
 
   Modified files:
 lib/libpthread   Makefile 
 lib/libpthread/support Makefile.inc 
   Log:
   Rethink the way thr_libc.So is generated. Relying on GCC to extract
   only needed symbols from libc_pic is not working on sparc64.
   
   Requested by: jake
   
   Revision  ChangesPath
   1.48  +0 -6  src/lib/libpthread/Makefile
   1.6   +32 -4 src/lib/libpthread/support/Makefile.inc
 
Excellent!  This means that revs. 1.365 and 1.367 to Makefile.inc1 can
go away now?

%%%
Index: Makefile.inc1
===
RCS file: /home/ncvs/src/Makefile.inc1,v
retrieving revision 1.389
diff -u -r1.389 Makefile.inc1
--- Makefile.inc1   1 Sep 2003 06:43:24 -   1.389
+++ Makefile.inc1   3 Sep 2003 07:16:30 -
@@ -813,8 +813,6 @@
 # gnu/lib/csu, gnu/lib/libgcc and lib/csu must be built before all
 # shared libraries for ELF.
 #
-# lib/libc (libc_pic.a) must be built before lib/libpthread.
-#
 _startup_libs= gnu/lib/csu gnu/lib/libgcc
 .if exists(${.CURDIR}/lib/csu/${MACHINE_ARCH}-elf)
 _startup_libs+=lib/csu/${MACHINE_ARCH}-elf
@@ -823,6 +821,7 @@
 .endif
 
 _prebuild_libs=
+
 _generic_libs= gnu/lib
 
 .if exists(${.CURDIR}/kerberos5)  exists(${.CURDIR}/crypto)  \
@@ -834,9 +833,6 @@
 _generic_libs+=kerberos5/lib
 .endif
 
-.if !defined(NOLIBPTHREAD)
-_prebuild_libs+= lib/libc
-.endif
 _prebuild_libs+= lib/libcom_err lib/libcrypt lib/libexpat \
lib/libkvm lib/libmd \
lib/libncurses lib/libopie lib/libpam lib/libradius \
%%%

BTW, the build of RELENG_5_1 is currently broken in libpthread due
to the same issue fixed in these revisions and rev. 1.2 to
libpthread/support/Makefile.inc.  Can you please fix the build of
RELENG_5_1 as well?

And, what's so special about Sparc64 that it didn't work there?


Cheers,
-- 
Ruslan Ermilov  Sysadmin and DBA,
[EMAIL PROTECTED]   Sunbay Software Ltd,
[EMAIL PROTECTED]   FreeBSD committer


pgp0.pgp
Description: PGP signature
---End Message---


pgp1.pgp
Description: PGP signature


Re: Upgrading to FreeBSD 5.1

2003-09-15 Thread Ruslan Ermilov
On Mon, Sep 15, 2003 at 03:13:30PM -0400, Didier Rwitura wrote:
 I am trying to upgrade my sysstem from 4.8-RELEASE-p4 to 5.1 
 
 and i getting this error message when I run make -j4 buildworld 
 
 
 [admin]/usr/src(101)#make -j4 buildworld
 Running test variables
 PASS: Test variables detected no regression, output matches.
 Running test targets
 PASS: Test targets detected no regression.
 Running test sysvmatch
 PASS: Test sysvmatch detected no regression.
 Running test lhs_expn
 FAIL: Test failed: regression detected.  See above.
 *** Error code 1
 1 error
 *** Error code 2
 --
 Building an up-to-date make(1)
 --
 
 what do I need to check to fix this . I read the /src/UPDATING  ... I didnt find any 
 info about this error message.
 
You mean you upgrade to RELENG_5_1?  Beware that this branch
is currently not buildable: libpthread build is broken.

The error above is expected error, and does not (should not)
the buildworld to fail -- as the first step, src/Makefile
checks to see if the available make(1) binary is adequate to
build world; it does this by passing it by running the make
regression tests, and should they fail, builds a new make
from fresh sources.  The errors above indicate that some of
the regression tests have failed, and this causes the new
make to be built.


Cheers,
-- 
Ruslan Ermilov  Sysadmin and DBA,
[EMAIL PROTECTED]   Sunbay Software Ltd,
[EMAIL PROTECTED]   FreeBSD committer


pgp0.pgp
Description: PGP signature


Re: upgrade from static to dynamic root

2003-09-14 Thread Ruslan Ermilov
On Thu, Sep 11, 2003 at 02:44:55PM +0200, Harti Brandt wrote:
 
 Hi,
 
 I just tried to upgrade one of my systems from a static root from july to
 an actual dynamic root. The installworld went fine 'til the place where
 /bin/test is installed. At that point the installation stopped with ELF
 interpreter /libexec/ld-elf.so.1 not found. And really /libexec is not
 populated yet. May it be, that the makefile uses one of the newly
 installed tools during install? For example 'ln' to make the link test -
 [?
 
It shouldn't happen, because we save test and [ in ${INSTALLTMP}.
It looks like something hardcodes /bin/test.  I've grepped the
src/ makefiles and cannot find such a place.  Where exactly did
it happen in the installworld for you?

 Also, wouldn't it be helpful to populate /rescue before /bin? Just in
 the case something goes wrong between installing been and rescue for the
 first time?
 
Good idea!


Cheers,
-- 
Ruslan Ermilov  Sysadmin and DBA,
[EMAIL PROTECTED]   Sunbay Software Ltd,
[EMAIL PROTECTED]   FreeBSD committer


pgp0.pgp
Description: PGP signature


Re: ps: kvm_getprocs: No such file or directory

2003-09-13 Thread Ruslan Ermilov
On Sat, Sep 13, 2003 at 08:42:42PM +0100, Jay Cornwall wrote:
 Hi
 
 I just updated my FreeBSD 5.1 system to HEAD, to see if the NFS problems 
 had been fixed. I've done {build|install}world, built a new kernel (with 
 my config from 5.1), and mergemaster -i.
 
 Running ps with the -a option produces this error:
   ps: kvm_getprocs: No such file or directory
 
 Have I done something wrong in the install? It doesn't say which file it 
 can't open. :|
 
 Thanks for your time. :)
 
If you did it exactly like you describe, then you forgot to install
and boot with the new kernel.


Cheers,
-- 
Ruslan Ermilov  Sysadmin and DBA,
[EMAIL PROTECTED]   Sunbay Software Ltd,
[EMAIL PROTECTED]   FreeBSD committer


pgp0.pgp
Description: PGP signature


Re: FreeBSD as bluetooth gateway for a PDA

2003-09-12 Thread Ruslan Ermilov
On Fri, Sep 12, 2003 at 11:47:40AM -0700, Maksim Yevmenkin wrote:
[...]
 ok, now we are back to RFCOMM connection. here is iPaq sends a RFCOMM data
 packet. the sequence is 0x43 0x4C 0x49 0x45 0x4E 0x54, which is a word
 
 CLIENT
 
   ACL data: handle 0x0028 flags 0x02 dlen 9
  L2CAP(d): cid 0x47 len 5 [psm 3]
RFCOMM(d): UIH: cr 0 dlci 14 pf 1 ilen 0 fcs 0x63 credits 34 
   HCI Event: Number of Completed Packets(0x13) plen 5
01 28 00 01 00 
   ACL data: handle 0x0028 flags 0x02 dlen 73
  L2CAP(d): cid 0x47 len 69 [psm 3]
RFCOMM(d): UIH: cr 0 dlci 14 pf 0 ilen 65 fcs 0x7f 
7E FF 7D 23 C0 21 7D 21 7D 21 7D 20 20 7D 28 7D 22 7D 27 7D 
22 7D 22 7D 26 7D 20 7D 20 7D 20 7D 20 7D 21 7D 24 7D 25 DC 
7D 25 7D 26 22 85 2E 69 7D 24 7D 28 C0 25 7D 20 7D 20 7D 23 
E8 7D 36 B4 7E 
 
 here is FreeBSD gives more RFCOMM credits to iPaq and send RFCOMM data packet
 with 0x7E 0xFF 0x7D ... which is clearly a PPP frame.
 
   HCI Event: Number of Completed Packets(0x13) plen 5
01 28 00 01 00 
   ACL data: handle 0x0028 flags 0x02 dlen 9
  L2CAP(d): cid 0x56 len 5 [psm 3]
RFCOMM(d): UIH: cr 1 dlci 14 pf 1 ilen 0 fcs 0xb9 credits 1 
   ACL data: handle 0x0028 flags 0x02 dlen 14
  L2CAP(d): cid 0x56 len 10 [psm 3]
RFCOMM(d): UIH: cr 1 dlci 14 pf 0 ilen 6 fcs 0xa5 
43 4C 49 45 4E 54 
 
 here we receive more RFCOMM credits from iPaq, and iPaq again sends us word
 CLIENT etc.
 
 [ i skipped the rest of the dump and PPP config ]
 
  I'm clueless... I hope you might find some time to ponder this!
 
 well, from what i can see iPaq is trying to use Windows RAS service, where
 FreeBSD is configured to use PPP. is iPaq runs on WinCE? you should tell
 your iPaq to use Unix/PPP *not* Windows/RAS (Remote Access Service). please
 try this and let me know if it works.
 
 thank you very much for your time, help with testing and very good dumps.
 
If you have a version of ppp(8) that supports force-scripts (please
check the ppp(8) manual), this should fix your PPP problem:

server:
[...]
enable force-scripts
set dial CLIENT CLIENTSERVER


Cheers,
-- 
Ruslan Ermilov  Sysadmin and DBA,
[EMAIL PROTECTED]   Sunbay Software Ltd,
[EMAIL PROTECTED]   FreeBSD committer


pgp0.pgp
Description: PGP signature


Re: 'cd /usr/src/etc; make distribute' broken.

2003-09-12 Thread Ruslan Ermilov
On Fri, Sep 12, 2003 at 01:00:06PM -0700, Kris Kennaway wrote:
 As part of my world-building script for creating binary distributions
 for use on bento I use the following to populate /etc in the target
 directory:
 ---
 cd /usr/src/etc
 make distribute DISTRIBUTION=/destdir TARGET_ARCH=whatever
 ---
 This used to work fine, but now it is dying with the following:
 
 install -o root -g wheel -m 644  
 /a/asami/portbuild/amd64/5/src/etc/sendmail/freebsd.mc 
 /a/asami/portbuild/amd64/5/src/etc/sendmail/freebsd.cf //var/chroot/etc/mail
 install: /a/asami/portbuild/amd64/5/src/etc/sendmail/freebsd.cf: No such file or 
 directory
 *** Error code 71
 
 Stop in /a/asami/portbuild/amd64/5/src/etc/sendmail.
 *** Error code 1
 
 Indeed, freebsd.cf does not appear to be built anywhere.  Does anyone
 know what is going on?
 
A FAQ question on current@ these days.  The ``distribute'' is
the special case of ``install''.  Before installing stuff, you
should build it first.  There was a bug in etc/sendmail/Makefile
that was attempting to build stuff during the build, that was
fixed.  You need to catch up to this (right) change and fix
your commands like this:

cd /usr/src/etc
make obj
make all
make distribute ...


Cheers,
-- 
Ruslan Ermilov  Sysadmin and DBA,
[EMAIL PROTECTED]   Sunbay Software Ltd,
[EMAIL PROTECTED]   FreeBSD committer


pgp0.pgp
Description: PGP signature


Re: BOOTMFS requires 'device miibus'

2003-09-09 Thread Ruslan Ermilov
On Wed, Sep 10, 2003 at 05:40:04AM +0900, Shin-ichi Yoshimoto wrote:
 make release failed because BOOTMFS forgot
 
 device miibus
 
 Please add this option in BOOTMFS.
 
Please try the attached patch instead, and let me know if it fixes
the release build.  You can try ``make rerelease'' to speed up the
things, after applying this patch in ${CHROOTDIR}/usr/src.


Cheers,
-- 
Ruslan Ermilov  Sysadmin and DBA,
[EMAIL PROTECTED]   Sunbay Software Ltd,
[EMAIL PROTECTED]   FreeBSD committer
Index: release/i386/drivers.conf
===
RCS file: /home/ncvs/src/release/i386/drivers.conf,v
retrieving revision 1.29
diff -u -r1.29 drivers.conf
--- release/i386/drivers.conf   25 Jul 2003 00:10:33 -  1.29
+++ release/i386/drivers.conf   9 Sep 2003 23:37:28 -
@@ -77,11 +77,13 @@
 an if_an   3   network Aironet 4500/4800 802.11 PCMCIA/ISA/PCI card
 awiif_awi  3   network BayStack 660 and others
 axeif_axe  3   network ASIX AX88172 USB 2.0 Ethernet
+bfeif_bfe  3   network Broadcom BCM440x 10/100 ethernet
 de if_de   3   network DEC DE435 PCI NIC or other DC21040-AA based 
card
 ex if_ex   3   network Intel EtherExpress Pro/10 and Pro/10+
 fweif_fwe  3   network Ethernet over FireWire
 ie if_ie   3   network EtherExpress 8/16, 3C507, StarLAN 10 etc.
 plip   plip3   network TCP/IP over parallel
+re if_re   3   network RealTek 8139C+/8169/8169S/8110S
 sk if_sk   3   network SysKonnect PCI gigabit ethernet card
 sl if_sl   3   network Kernel SLIP
 sn if_sn   3   network SMC's 9000 series of ethernet chips


pgp0.pgp
Description: PGP signature


Re: rpc.ypxfrd(8)

2003-09-06 Thread Ruslan Ermilov
On Fri, Sep 05, 2003 at 04:49:17PM -0500, Dan Nelson wrote:
 In the last episode (Sep 05), Ruslan Ermilov said:
  Is there anybody out there who successfully uses the rpc.ypxfrd(8)
  server to speed up distribution of NIS maps, either on 4.x or 5.x?
  I have trouble getting it to work.
 
 Seems to work for me, although it might be failing and falling back to
 a regular ypxfr for all I know.  If I run rpc.ypxfrd on the server,
 then run chfn and change my name, lastcomm shows that rpc.ypxfrd forks
 a couple times, and the client's map is updated.  -current server, 4.1
 client.
 
If it falls back to a regular record-based transfer, as it does for me,
it means it does not work:

# /usr/libexec/ypxfr -f passwd.byname
ypxfr: call to rpc.ypxfrd failed: RPC: Timed out
ypxfr: Exiting: Map successfully transferred


Cheers,
-- 
Ruslan Ermilov  Sysadmin and DBA,
[EMAIL PROTECTED]   Sunbay Software Ltd,
[EMAIL PROTECTED]   FreeBSD committer


pgp0.pgp
Description: PGP signature


Re: rpc.ypxfrd(8)

2003-09-06 Thread Ruslan Ermilov
On Sat, Sep 06, 2003 at 08:24:57AM +0900, horio shoichi wrote:
 On Fri, 5 Sep 2003 22:47:02 +0300
 Ruslan Ermilov [EMAIL PROTECTED] wrote:
  Is there anybody out there who successfully uses the rpc.ypxfrd(8)
  server to speed up distribution of NIS maps, either on 4.x or 5.x?
  I have trouble getting it to work.
  
 I recently switched NIS master to 4.8-STABLE, and had some trouble.
 
 To make long story short, I did:
 
 1. edit /var/yp/ypservers to make it single array of slaves.
 
[...]
I always had it like this.

 2. cd /var/yp  make
 
 Qurious, which of ypinit, yppoll is to be blamed.
 
The above command works OK here, with 6 slaves around the world,
but what does it have to do with the subject?

I'm struggling with the problem of NIS map transfers not
working on slow WAN links, and was hoping that rpc.ypxfrd(8)
could be of some help here, but now it just doesn't work.


Cheers,
-- 
Ruslan Ermilov  Sysadmin and DBA,
[EMAIL PROTECTED]   Sunbay Software Ltd,
[EMAIL PROTECTED]   FreeBSD committer


pgp0.pgp
Description: PGP signature


rpc.ypxfrd(8)

2003-09-05 Thread Ruslan Ermilov
Is there anybody out there who successfully uses the rpc.ypxfrd(8)
server to speed up distribution of NIS maps, either on 4.x or 5.x?
I have trouble getting it to work.


Cheers,
-- 
Ruslan Ermilov  Sysadmin and DBA,
[EMAIL PROTECTED]   Sunbay Software Ltd,
[EMAIL PROTECTED]   FreeBSD committer


pgp0.pgp
Description: PGP signature


Re: Text file busy

2003-09-04 Thread Ruslan Ermilov
On Thu, Sep 04, 2003 at 02:44:13PM +, Paul Richards wrote:
 Overwriting a file that's currently executing results in a Text file
 busy error.
 
 When did this start happening?
 
 This was something that was fixed way back on FreeBSD but it seems to be
 a problem again.
 
cp -f


Cheers,
-- 
Ruslan Ermilov  Sysadmin and DBA,
[EMAIL PROTECTED]   Sunbay Software Ltd,
[EMAIL PROTECTED]   FreeBSD committer


pgp0.pgp
Description: PGP signature


/lib/foo.so.X - /usr/lib/foo.so

2003-09-04 Thread Ruslan Ermilov
On Thu, Sep 04, 2003 at 09:58:39PM +0300, Ruslan Ermilov wrote:
[...]
 The patch is not a problem (attached).  I've been looking at
 how our friends do this.  NetBSD has symlinks in /usr/lib to
 /lib, both to .so and .so.X, and their cc(1) and ld(1) don't
 look things in /lib.  Linux looks things up in both /lib and
 /usr/lib, and does not have symlinks from /usr/lib to /lib.
 
There is a sad typo above: Linux *does* have symlinks from
/usr/lib to /lib, so both use /usr/lib for linking.

 The only reason while I still think we should support both
 /lib and /usr/lib in cc(1) and ld(1) by default is to allow
 our users to have /usr symlinked somethere, otherwise relative
 symlinking from /usr/lib to ../../lib does not work, and we
 are back to that endless thread.
 
Not that I'm completely happy with introducing yet another
variable in bsd.lib.mk, but the attached patch:

- Leaves only one set of .so symlinks in /usr/lib.

  Benefits: all other systems that use both /lib and /usr/lib
  (that I've been able to test) have .so links in /usr/lib
  only, and use them for linking; GCC in ports will like this
  better.

- Uses absolute paths in .so symlinks.

  Benefit: works for people who have their /usr symlinked
  somewhere.

- Works without any more modifications to GCC.  ld(1)
  hacks can go away too.

Please review.


Cheers,
-- 
Ruslan Ermilov  Sysadmin and DBA,
[EMAIL PROTECTED]   Sunbay Software Ltd,
[EMAIL PROTECTED]   FreeBSD committer
Index: Makefile.inc1
===
RCS file: /home/ncvs/src/Makefile.inc1,v
retrieving revision 1.389
diff -u -r1.389 Makefile.inc1
--- Makefile.inc1   1 Sep 2003 06:43:24 -   1.389
+++ Makefile.inc1   4 Sep 2003 19:30:19 -
@@ -227,6 +227,7 @@
 # world stage
 WMAKEENV=  ${CROSSENV} \
DESTDIR=${WORLDTMP} \
+   SHLIBDIRPREFIX=${WORLDTMP} \
INSTALL=sh ${.CURDIR}/tools/install.sh \
PATH=${TMPPATH}
 WMAKE= ${WMAKEENV} ${MAKE} -f Makefile.inc1
Index: share/mk/bsd.lib.mk
===
RCS file: /home/ncvs/src/share/mk/bsd.lib.mk,v
retrieving revision 1.153
diff -u -r1.153 bsd.lib.mk
--- share/mk/bsd.lib.mk 4 Sep 2003 04:29:11 -   1.153
+++ share/mk/bsd.lib.mk 4 Sep 2003 19:34:08 -
@@ -208,9 +208,10 @@
${_INSTALLFLAGS} ${_SHLINSTALLFLAGS} \
${SHLIB_NAME} ${DESTDIR}${SHLIBDIR}
 .if defined(SHLIB_LINK)
-   ln -fs ${SHLIB_NAME} ${DESTDIR}${SHLIBDIR}/${SHLIB_LINK}
-.if (${LIBDIR} != ${SHLIBDIR})
-   ln -fs ${LIBDIR:C|/[^/]+|/..|g:S|^/||}${SHLIBDIR}/${SHLIB_NAME} \
+.if ${SHLIBDIR} == ${LIBDIR}
+   ln -fs ${SHLIB_NAME} ${DESTDIR}${LIBDIR}/${SHLIB_LINK}
+.else
+   ln -fs ${SHLIBDIRPREFIX}${SHLIBDIR}/${SHLIB_NAME} \
${DESTDIR}${LIBDIR}/${SHLIB_LINK}
 .endif
 .endif


pgp0.pgp
Description: PGP signature


Re: /lib symlinks problem?

2003-09-01 Thread Ruslan Ermilov
On Sun, Aug 31, 2003 at 10:10:49PM -0700, David O'Brien wrote:
 On Sun, Aug 31, 2003 at 05:52:24PM +0300, Ruslan Ermilov wrote:
I might be missing an obvious, but I just don't see a reason
why we should use relative linking here: we should just link
to where we really install.  With the attached patch, I get:
 ...
  +.if ${LIBDIR} != ${SHLIBDIR}
  +   ln -fs ${SHLIBDIR}/${SHLIB_NAME} ${DESTDIR}${LIBDIR}/${SHLIB_LINK}
 
 Why are we making *any* symlinks here??
 
: revision 1.150
: date: 2003/08/17 23:56:29;  author: gordon;  state: Exp;  lines: +2 -3
: When creating .so symlinks, use SHLIBDIR instead of LIBDIR so symlinks
: are created in the correct location. Always make them. For libraries
: that live in /lib, this causes a /lib/libfoo.so and a compatibility
: /usr/lib/libfoo.so to be created. We may want to drop the
: /usr/lib/libfoo.so symlink at some future point.

I think that Gordon took a safe path with creating compatibility symlinks.
Besides, creating compatibility symlinks has a nicety of removing your
stale symlinks in /usr/lib.


Cheers,
-- 
Ruslan Ermilov  Sysadmin and DBA,
[EMAIL PROTECTED]   Sunbay Software Ltd,
[EMAIL PROTECTED]   FreeBSD committer


pgp0.pgp
Description: PGP signature


Re: cvs commit: src Makefile.inc1

2003-09-01 Thread Ruslan Ermilov
On Sun, Aug 31, 2003 at 11:43:25PM -0700, Scott Long wrote:
 scottl  2003/08/31 23:43:25 PDT
 
   FreeBSD src repository
 
   Modified files:
 .Makefile.inc1 
   Log:
   Clarify the numbering of some of the build stages.
   
   Revision  ChangesPath
   1.389 +9 -9  src/Makefile.inc1
 
How about if we get rid of the numbering here completely?


Cheers,
-- 
Ruslan Ermilov  Sysadmin and DBA,
[EMAIL PROTECTED]   Sunbay Software Ltd,
[EMAIL PROTECTED]   FreeBSD committer


pgp0.pgp
Description: PGP signature


Re: /lib symlinks problem?

2003-09-01 Thread Ruslan Ermilov
On Mon, Sep 01, 2003 at 08:58:19AM +0200, Christoph P. Kukulies wrote:
 On Mon, Sep 01, 2003 at 09:44:24AM +0300, Ruslan Ermilov wrote:
  I think that Gordon took a safe path with creating compatibility symlinks.
  Besides, creating compatibility symlinks has a nicety of removing your
  stale symlinks in /usr/lib.
 
 I always asked myself whether there is a tool or some kind of
 database at which one can throw an existing installation and it
 knows about which files have to be there and where and which ain't
 to be there (like such symlink relicts), maybe a hook in install,cp,ln
 and what else is being used in the world install process. 
 That way it could tell me what files are candidates for deleting.
 
Hold on, Warner is almost ready for an real solution here, I think.


Cheers,
-- 
Ruslan Ermilov  Sysadmin and DBA,
[EMAIL PROTECTED]   Sunbay Software Ltd,
[EMAIL PROTECTED]   FreeBSD committer


pgp0.pgp
Description: PGP signature


Re: /lib symlinks problem?

2003-09-01 Thread Ruslan Ermilov
On Mon, Sep 01, 2003 at 01:22:49AM -0600, M. Warner Losh wrote:
 In message: [EMAIL PROTECTED]
 Ruslan Ermilov [EMAIL PROTECTED] writes:
 : On Mon, Sep 01, 2003 at 08:58:19AM +0200, Christoph P. Kukulies wrote:
 :  On Mon, Sep 01, 2003 at 09:44:24AM +0300, Ruslan Ermilov wrote:
 :   I think that Gordon took a safe path with creating compatibility symlinks.
 :   Besides, creating compatibility symlinks has a nicety of removing your
 :   stale symlinks in /usr/lib.
 :  
 :  I always asked myself whether there is a tool or some kind of
 :  database at which one can throw an existing installation and it
 :  knows about which files have to be there and where and which ain't
 :  to be there (like such symlink relicts), maybe a hook in install,cp,ln
 :  and what else is being used in the world install process. 
 :  That way it could tell me what files are candidates for deleting.
 :  
 : Hold on, Warner is almost ready for an real solution here, I think.
 
 My tool is initially just a 'delete these files' tool, but now that I
 think about it, it wouldn't be hard to say also 'create these
 symlinks'.  The hard part here is generating the 'obsolete' lists.
 
But ``delete these files'' is what's actually needed here.  ;-)


Cheers,
-- 
Ruslan Ermilov  Sysadmin and DBA,
[EMAIL PROTECTED]   Sunbay Software Ltd,
[EMAIL PROTECTED]   FreeBSD committer


pgp0.pgp
Description: PGP signature


Re: /lib symlinks problem?

2003-09-01 Thread Ruslan Ermilov
On Mon, Sep 01, 2003 at 01:58:52AM -0700, Doug Barton wrote:
 On Mon, 1 Sep 2003, M. Warner Losh wrote:
 
  My tool is initially just a 'delete these files' tool, but now that I
  think about it, it wouldn't be hard to say also 'create these
  symlinks'.  The hard part here is generating the 'obsolete' lists.
 
 I posted one approach to this today... touch a file right before you
 start installworld, then consider anything not newer than that file a
 candidate for disposal. There is currently something weird going on in
 /usr/lib though... a lot of the files don't have newer dates, I haven't
 tracked down why yet.
 
This is because static libraries are installed with -C.  The reasoning
was like this:

On Sat, Mar 30, 2002 at 02:15:56PM +0100, Dag-Erling Smorgrav wrote:
 Ruslan Ermilov [EMAIL PROTECTED] writes:
  On Fri, Mar 22, 2002 at 12:28:17PM -0800, Dag-Erling Smorgrav wrote:
 Log:
 Install static and profiled libraries with -C.
  Um why, what's so special about them?

 They appear in dependency lists.  This was discussed on -arch.

This also will not work for anything that has not changed and is
installed with -C, that is includes, rtld-elf, and some parts of
/sys/boot.


Cheers,
-- 
Ruslan Ermilov  Sysadmin and DBA,
[EMAIL PROTECTED]   Sunbay Software Ltd,
[EMAIL PROTECTED]   FreeBSD committer


pgp0.pgp
Description: PGP signature


Re: /lib symlinks problem?

2003-09-01 Thread Ruslan Ermilov
On Mon, Sep 01, 2003 at 09:31:29AM -0700, David O'Brien wrote:
 On Mon, Sep 01, 2003 at 09:44:24AM +0300, Ruslan Ermilov wrote:
  On Sun, Aug 31, 2003 at 10:10:49PM -0700, David O'Brien wrote:
   On Sun, Aug 31, 2003 at 05:52:24PM +0300, Ruslan Ermilov wrote:
  I might be missing an obvious, but I just don't see a reason
  why we should use relative linking here: we should just link
  to where we really install.  With the attached patch, I get:
   ...
+.if ${LIBDIR} != ${SHLIBDIR}
+   ln -fs ${SHLIBDIR}/${SHLIB_NAME} ${DESTDIR}${LIBDIR}/${SHLIB_LINK}
   
   Why are we making *any* symlinks here??
   
  : revision 1.150
  : date: 2003/08/17 23:56:29;  author: gordon;  state: Exp;  lines: +2 -3
  : When creating .so symlinks, use SHLIBDIR instead of LIBDIR so symlinks
  : are created in the correct location. Always make them. For libraries
  : that live in /lib, this causes a /lib/libfoo.so and a compatibility
  : /usr/lib/libfoo.so to be created. We may want to drop the
  : /usr/lib/libfoo.so symlink at some future point.
  
  I think that Gordon took a safe path with creating compatibility symlinks.
  Besides, creating compatibility symlinks has a nicety of removing your
  stale symlinks in /usr/lib.
 
 Reguardless, I think we should just not have the compatibility symlinks.
 I can't think of anything that really uses them.
 
If you want my opinion, I was very surprised to see this committed,
and support the idea of removing the compatibility symlinks, but
I'd like to hear from Gordon first about why he did this, in the
first place.  Perhaps, he did that before our linker was taught to
look in /lib, I don't know...

If it's only to get rid of stale symlinks, I have a few lines
patch to bsd.lib.mk that takes care of removing them; otherwise,
we can wait for the Warner's hoover script to reach the tools/
tree.


Cheers,
-- 
Ruslan Ermilov  Sysadmin and DBA,
[EMAIL PROTECTED]   Sunbay Software Ltd,
[EMAIL PROTECTED]   FreeBSD committer


pgp0.pgp
Description: PGP signature


Re: /lib symlinks problem?

2003-08-31 Thread Ruslan Ermilov
On Sun, Aug 31, 2003 at 02:07:42PM +0200, Alexander Leidinger wrote:
 On Sat, 30 Aug 2003 21:56:53 +0300
 Ruslan Ermilov [EMAIL PROTECTED] wrote:
 
   I think a workaround would be to use absolute symlinks (at least as an
   option).
   
  I might be missing an obvious, but I just don't see a reason
  why we should use relative linking here: we should just link
  to where we really install.  With the attached patch, I get:
  
  $ make -n install -DNOMAN DESTDIR=/foo
  install -C -o root -g wheel -m 444   libalias.a /foo/usr/lib
  install -s -o root -g wheel -m 444 libalias.so.4 /foo/lib
  ln -fs libalias.so.4 /foo/lib/libalias.so
  ln -fs /foo/lib/libalias.so.4  /foo/usr/lib/libalias.so
 
 Don't you have to remove the first ${DESTDIR} to make this work in the
 put a harddisk into a running system and install a system via
 installworld   distribute case?
 
Doh, you're of course right!  An updated patch is attached.

Now it looks like this:

install -C -o root -g wheel -m 444   libalias.a /foo/usr/lib
install -s -o root -g wheel -m 444 libalias.so.4 /foo/lib
ln -fs libalias.so.4 /foo/lib/libalias.so
ln -fs /lib/libalias.so.4  /foo/usr/lib/libalias.so

This is also consistent with how we handle SYMLINKS:

# make -f bsd.prog.mk BINDIR=/bin SYMLINKS='${BINDIR}/file1 ${BINDIR}/file2' install 
DESTDIR=/foo
/foo/bin/file2 - /bin/file1
# ls -l /foo/bin
total 0
lrwxr-xr-x  1 root  wheel  10 Aug 31 17:44 file2 - /bin/file1


Cheers,
-- 
Ruslan Ermilov  Sysadmin and DBA,
[EMAIL PROTECTED]   Sunbay Software Ltd,
[EMAIL PROTECTED]   FreeBSD committer
Index: bsd.lib.mk
===
RCS file: /home/ncvs/src/share/mk/bsd.lib.mk,v
retrieving revision 1.150
diff -u -r1.150 bsd.lib.mk
--- bsd.lib.mk  17 Aug 2003 23:56:29 -  1.150
+++ bsd.lib.mk  31 Aug 2003 14:46:32 -
@@ -207,9 +207,8 @@
${SHLIB_NAME} ${DESTDIR}${SHLIBDIR}
 .if defined(SHLIB_LINK)
ln -fs ${SHLIB_NAME} ${DESTDIR}${SHLIBDIR}/${SHLIB_LINK}
-.if (${LIBDIR} != ${SHLIBDIR})
-   ln -fs ${LIBDIR:C|/[^/]+|/..|g:S|^/||}${SHLIBDIR}/${SHLIB_NAME} \
-   ${DESTDIR}${LIBDIR}/${SHLIB_LINK}
+.if ${LIBDIR} != ${SHLIBDIR}
+   ln -fs ${SHLIBDIR}/${SHLIB_NAME} ${DESTDIR}${LIBDIR}/${SHLIB_LINK}
 .endif
 .endif
 .endif


pgp0.pgp
Description: PGP signature


Re: 5.1-REL won't buildworld - fresh cvsup

2003-08-31 Thread Ruslan Ermilov
On Sun, Aug 31, 2003 at 01:27:30PM +0300, ODHIAMBO Washington wrote:
 
 For the last 3 days, I have cvsupped and wouldn't ever succeed with
 `make buildworld`. What could the problem be?
 
 Below are snippets from the fail:
 
What are you trying to cvsup to?  5.1-RELEASE?  This is the static
thing, perhaps you want 5.1-CURRENT (HEAD)?  What's your current
system?


Cheers,
-- 
Ruslan Ermilov  Sysadmin and DBA,
[EMAIL PROTECTED]   Sunbay Software Ltd,
[EMAIL PROTECTED]   FreeBSD committer


pgp0.pgp
Description: PGP signature


Re: /lib symlinks problem?

2003-08-30 Thread Ruslan Ermilov
On Sat, Aug 30, 2003 at 01:54:27PM +0200, Alexander Leidinger wrote:
[...]
 I think the problem is, that some tools have a problem finding it...:
 ---snip---
 (3) [EMAIL PROTECTED] % nm -D /usr/lib/libc.so | grep fpcl
 nm: /usr/lib/libc.so: No such file or directory
 
 (4) [EMAIL PROTECTED] % ll /usr/lib/libc.so
 lrwxr-xr-x  1 root  wheel  19B 29 Aug 13:57 /usr/lib/libc.so@ - ../../lib/libc.so.5
 
 (5) [EMAIL PROTECTED] % ll /usr 
 lrwxr-xr-x  1 root  wheel  7.0B 18 Aug  2001 /usr@ - big/usr
 
 (7) [EMAIL PROTECTED] % ll /lib/libc.so 
 lrwxr-xr-x  1 root  wheel  9.0B 29 Aug 13:57 /lib/libc.so@ - libc.so.5
 ---snip---
 
 I think a workaround would be to use absolute symlinks (at least as an
 option).
 
I might be missing an obvious, but I just don't see a reason
why we should use relative linking here: we should just link
to where we really install.  With the attached patch, I get:

$ make -n install -DNOMAN DESTDIR=/foo
install -C -o root -g wheel -m 444   libalias.a /foo/usr/lib
install -s -o root -g wheel -m 444 libalias.so.4 /foo/lib
ln -fs libalias.so.4 /foo/lib/libalias.so
ln -fs /foo/lib/libalias.so.4  /foo/usr/lib/libalias.so


Cheers,
-- 
Ruslan Ermilov  Sysadmin and DBA,
[EMAIL PROTECTED]   Sunbay Software Ltd,
[EMAIL PROTECTED]   FreeBSD committer
Index: bsd.lib.mk
===
RCS file: /home/ncvs/src/share/mk/bsd.lib.mk,v
retrieving revision 1.150
diff -u -r1.150 bsd.lib.mk
--- bsd.lib.mk  17 Aug 2003 23:56:29 -  1.150
+++ bsd.lib.mk  30 Aug 2003 18:48:17 -
@@ -207,8 +207,8 @@
${SHLIB_NAME} ${DESTDIR}${SHLIBDIR}
 .if defined(SHLIB_LINK)
ln -fs ${SHLIB_NAME} ${DESTDIR}${SHLIBDIR}/${SHLIB_LINK}
-.if (${LIBDIR} != ${SHLIBDIR})
-   ln -fs ${LIBDIR:C|/[^/]+|/..|g:S|^/||}${SHLIBDIR}/${SHLIB_NAME} \
+.if ${LIBDIR} != ${SHLIBDIR}
+   ln -fs ${DESTDIR}${SHLIBDIR}/${SHLIB_NAME} \
${DESTDIR}${LIBDIR}/${SHLIB_LINK}
 .endif
 .endif


pgp0.pgp
Description: PGP signature


Re: status of nsswitch.conf in current?

2003-08-22 Thread Ruslan Ermilov
On Fri, Aug 22, 2003 at 10:40:32AM -0400, Richard Coleman wrote:
 I saw that.  I guess my question is whether a default nsswitch.conf file 
 will be checked into /etc and /usr/share/examples/etc, or whether it 
 will be left empty?  I would expect that if this capability was working, 
 that a default nsswitch.conf would be checked into /etc.
 
Adding /etc/nsswitch.conf with the default settings would just slow the
things down.  For the same reason, we don't provide /etc/resolv.conf by
default.  Adding src/share/examples/etc/nsswitch.conf and installing it
in /usr/share/examples/etc/ is a good idea.

 Many admins 
 may not know the system has this capability unless they see a copy of 
 nsswitch.conf in /etc.
 
Many admins should learn how to consult with the release notes then.  ;-)


Cheers,
-- 
Ruslan Ermilov  Sysadmin and DBA,
[EMAIL PROTECTED]   Sunbay Software Ltd,
[EMAIL PROTECTED]   FreeBSD committer


pgp0.pgp
Description: PGP signature


Re: status of nsswitch.conf in current?

2003-08-21 Thread Ruslan Ermilov
On Fri, Aug 22, 2003 at 12:33:45AM -0400, Richard Coleman wrote:
 What is the status of nsswitch.conf in current?
 
 I noticed that there is a man page for nsswitch.conf.  But there is no 
 such file installed in /etc, nor is there an example copy in 
 /usr/share/examples/etc.
 
 I just cvsup'ed tonight (Thursday) and built world.  So, I'm up to date.
 
Please see the ``Default source lists'' section of the nsswitch.conf(5)
manpage that talks about this case.


Cheers,
-- 
Ruslan Ermilov  Sysadmin and DBA,
[EMAIL PROTECTED]   Sunbay Software Ltd,
[EMAIL PROTECTED]   FreeBSD committer


pgp0.pgp
Description: PGP signature


Re: GCC 3.3.1-RELEASE is coming

2003-08-21 Thread Ruslan Ermilov
On Thu, Aug 21, 2003 at 09:40:42PM -0700, Alexander Kabaev wrote:
 On Thu, Aug 21, 2003 at 07:55:00PM -0700, Alexander Kabaev wrote:
  I am about to import an official GCC 3.3.1-release into our
  source tree. Please hold your updates until 'all clear' message
  is posted.
 
 Done.
 
Does it serve as all clear too?  ;-)


Cheers,
-- 
Ruslan Ermilov  Sysadmin and DBA,
[EMAIL PROTECTED]   Sunbay Software Ltd,
[EMAIL PROTECTED]   FreeBSD committer


pgp0.pgp
Description: PGP signature


Re: Warning with loader Makefile?

2003-08-14 Thread Ruslan Ermilov
On Fri, Aug 08, 2003 at 11:25:49AM +1200, Andrew Turner wrote:
[...]
 I found this patch worked by removing the secound ${PROG} target if 
 there was already one there.
 
 --- /usr/src/share/mk/bsd.prog.mk Mon Jun 30 06:16:26 2003
 +++ /usr/share/mk/bsd.prog.mk Mon Aug  4 17:54:22 2003
 @@ -31,11 +31,13 @@
  
  OBJS+=  ${SRCS:N*.h:R:S/$/.o/g}
  
 +.if !target(${PROG})
  ${PROG}: ${OBJS}
  .if defined(PROG_CXX)
   ${CXX} ${CXXFLAGS} ${LDFLAGS} -o ${.TARGET} ${OBJS} ${LDADD}
  .else
   ${CC} ${CFLAGS} ${LDFLAGS} -o ${.TARGET} ${OBJS} ${LDADD}
 +.endif
  .endif
  
  .else !defined(SRCS)

No, thanks.  If a makefile has a

${PROG}: foo

line, just to add an additional dependency, this patch will break
building the ${PROG}.


Cheers,
-- 
Ruslan Ermilov  Sysadmin and DBA,
[EMAIL PROTECTED]   Sunbay Software Ltd,
[EMAIL PROTECTED]   FreeBSD committer


pgp0.pgp
Description: PGP signature


Re: mergemaster chokes on etc/sendmail

2003-08-14 Thread Ruslan Ermilov
On Wed, Aug 13, 2003 at 07:11:13AM +0200, Poul-Henning Kamp wrote:
 
 cd /freebsd/src/etc/sendmail; make distribution
 install -o root -g wheel -m 644  /freebsd/src/etc/sendmail/freebsd.mc freebsd.cf 
 /var/tmp/temproot/etc/mail
 install: freebsd.cf: No such file or directory
 *** Error code 71
 
 Stop in /freebsd/src/etc/sendmail.
 *** Error code 1
 
 Stop in /freebsd/src/etc.
 
   *** FATAL ERROR: Cannot 'cd' to /usr/src/etc and install files to
   the temproot environment
 
Please make sure to upgrade your mergemaster(8) first.


Cheers,
-- 
Ruslan Ermilov  Sysadmin and DBA,
[EMAIL PROTECTED]   Sunbay Software Ltd,
[EMAIL PROTECTED]   FreeBSD committer


pgp0.pgp
Description: PGP signature


Change to kernel+modules build approach

2003-08-14 Thread Ruslan Ermilov
On Thu, Aug 14, 2003 at 02:10:19AM -0600, Scott Long wrote:
 Luoqi Chen wrote:
[...]
 On the other hand, all modules should create all the opt_*.h files
 it needs when built individually. Add opt_ddb.h to nullfs's Makefile
 should fix the breakage.
 
 Our kernel build system isn't set up to handle passing config options
 to modules.  Various solutions to this have been proposed, but nothing
 has appeared yet.  In 5.x, we document that modules will not work with
 PAE.
 
How does the below look?  This is basically a more generic implementation
of Luoqi's idea, but for -CURRENT:

%%%
Index: kern.pre.mk
===
RCS file: /home/ncvs/src/sys/conf/kern.pre.mk,v
retrieving revision 1.33
diff -u -r1.33 kern.pre.mk
--- kern.pre.mk 30 Jul 2003 22:11:36 -  1.33
+++ kern.pre.mk 14 Aug 2003 09:39:30 -
@@ -91,6 +91,7 @@
 # them.
 
 MKMODULESENV=  MAKEOBJDIRPREFIX=${.OBJDIR}/modules KMODDIR=${KODIR}
+MKMODULESENV+= KERNOBJDIR=${.OBJDIR}
 .if (${KERN_IDENT} == LINT)
 MKMODULESENV+= ALL_MODULES=LINT
 .endif
Index: kmod.mk
===
RCS file: /home/ncvs/src/sys/conf/kmod.mk,v
retrieving revision 1.139
diff -u -r1.139 kmod.mk
--- kmod.mk 26 Jul 2003 02:27:50 -  1.139
+++ kmod.mk 14 Aug 2003 09:42:52 -
@@ -241,6 +241,10 @@
${KMODUNLOAD} -v ${KMOD}
 .endif
 
+.if defined(KERNOBJDIR)  !empty(KERNOBJDIR)  exists(${KERNOBJDIR})
+.PATH: ${KERNOBJDIR}
+CFLAGS+=   -I${KERNOBJDIR}
+.else
 .for _src in ${SRCS:Mopt_*.h}
 CLEANFILES+=   ${_src}
 .if !target(${_src})
@@ -248,6 +252,7 @@
touch ${.TARGET}
 .endif
 .endfor
+.endif
 
 MFILES?= kern/bus_if.m kern/device_if.m dev/iicbus/iicbb_if.m \
 dev/iicbus/iicbus_if.m isa/isa_if.m \
%%%


Cheers,
-- 
Ruslan Ermilov  Sysadmin and DBA,
[EMAIL PROTECTED]   Sunbay Software Ltd,
[EMAIL PROTECTED]   FreeBSD committer


pgp0.pgp
Description: PGP signature


Re: Warning with loader Makefile?

2003-08-07 Thread Ruslan Ermilov
On Thu, Aug 07, 2003 at 02:46:23PM -0300, Daniel C. Sobral wrote:
 Nate Lawson wrote:
 I get this:
 === i386/cdboot
 === i386/kgzldr
 === i386/libi386
 === i386/loader
 /usr/share/mk/bsd.prog.mk, line 38: warning: duplicate script for target 
 loader ignored
 cc -nostdlib -static -Ttext 0x0 -o loader.sym
 /home/obj/home/src/sys/boot/i386/loader/../btx/lib/crt0.o main.o conf.o
 bcache.o boot.o commands.o console.o devopen.o interp.o interp_backslash.o
 interp_parse.o ls.o misc.o module.o panic.o load_elf32.o load_elf64.o
 isapnp.o pnp.o interp_forth.o vers.o
 
 Why is there a duplicate script?
 
 This might be a new gcc 3.3 warning. The ${PROG} target is defined in 
 loader's Makefile:
 
 # $FreeBSD: src/sys/boot/i386/loader/Makefile,v 1.66 2003/06/26 03:51:57 
 peter Exp $
 ...
 PROG=   loader
 ...
 ${PROG}: ${PROG}.bin ${BTXLDR} ${BTXKERN} ${BTXCRT}
 btxld -v -f aout -e ${LOADER_ADDRESS} -o ${.TARGET} -l ${BTXLDR} \
 -b ${BTXKERN} ${PROG}.bin
 
 Now, bsd.prog.mk also defines a PROG target. It is included later on 
 this file:
 
 .include bsd.prog.mk
 
 ${PROG}.sym: ${OBJS} ${LIBI386} ${LIBSTAND} ${LIBFICL} vers.o
 ${CC} ${LDFLAGS} -o ${.TARGET} ${BTXCRT} ${OBJS} vers.o \
 ${LIBFICL} ${LIBI386} ${LIBSTAND}
 
 
 This was added by Mike Smith in version 1.13. It brings in ${OBJS} 
 definition and maybe linker stuff (from Mike's commit message).
 
 I'm bringing Ruslan in this. He might be able to help with this.
 
I'm well aware of this problem.  It's been on my TODO list for
a long time.  When I have time, I will fix it.  Don't worry,
it's harmless, and no, it's not new, and it doesn't have any
relation to GCC.  It's just that make(1) was fixed to print
these warnings (was that Juli who fixed it?).


Cheers,
-- 
Ruslan Ermilov  Sysadmin and DBA,
[EMAIL PROTECTED]   Sunbay Software Ltd,
[EMAIL PROTECTED]   FreeBSD committer


pgp0.pgp
Description: PGP signature


Re: MSDOSFS woes

2003-08-06 Thread Ruslan Ermilov
On Wed, Aug 06, 2003 at 08:05:52PM +1000, Tim Robbins wrote:
 On Sat, Aug 02, 2003 at 06:08:50PM +0300, Ruslan Ermilov wrote:
 
  Gang, :-)
  
  While working with Marcel on a bootable CD-ROM for IA64 issue,
  I've stumbled upon the following problem.  I needed to increase
  the size of the EFI partition (which is an MS-DOS file system)
  to 64M, and that made two of my machines stuck solidly -- a lot
  of process are waiting on the wdrain event.
 
 Interesting. Were you running with INVARIANTS on? I got a completely
 reproducible kernel panic when running your script, regardless of whether I
 used -F 12 or -F 16; it was trying to write file data past the end of the disk,
 and causing kernel memory pool to become corrupted. I was seeing Memory
 modified after free errors, with blocks most recently used by GEOM and file
 desc.
 
 Were you running the script with INVARIANTS on?
 
My kernel config includes the GENERIC config which has INVARIANTS on.

Further analysis of the problem shows that there are actually two
problems.

First problem is with newfs_msdos(8) (and kernel part of MSDOSFS).
newfs_msdos(8) sometimes results in a bad file system lying about
the number of available sectors (recorded in sector 0) than is
actually available, as was demonstrated by Bruce Evans (and I've
been able to reproduce this).  Sometimes, this results in warnings
from MSDOSFS on a console, immediately followed by a panic.
Sometimes, I also saw the Memory modified after free.  IIRC,
I ended up with a conclusion that -s arguments 32M are unsafe
with newfs_msdos(8).

Second problem is with vnode-backed md(4) devices, and it is not
MSDOSFS-specific.  I've been able to reproduce the wdrain lockup
after attempting to newfs(8) and fill (with cpio(1)) an 11MB-only
vnode-backed UFS file system yesterday.  Sometimes it just works,
and sometimes it causes a lock-up.  I asked Poul-Henning to look
into this issue in a private message to him with more details and
a test case.


Cheers,
-- 
Ruslan Ermilov  Sysadmin and DBA,
[EMAIL PROTECTED]   Sunbay Software Ltd,
[EMAIL PROTECTED]   FreeBSD committer


pgp0.pgp
Description: PGP signature


Re: buildworld broken after installworld

2003-08-04 Thread Ruslan Ermilov
On Mon, Aug 04, 2003 at 07:51:35PM +0900, Shin-ichi YOSHIMOTO wrote:
 I tried to buildworld and installworld in this morning. After that,
 buildworld broken like this:
 
 [snip]
 === lib/libedit
 cc -O -pipe -march=pentium4 -I. -I/usr/src/lib/libedit -c editline.c
 In file included from /usr/src/lib/libedit/chared.h:136,
  from /usr/src/lib/libedit/el.h:102,
  from /usr/src/lib/libedit/chared.c:51,
  from editline.c:4:
 fcns.h:94:12: warning: ISO C requires whitespace after the macro name
 In file included from editline.c:9:
 help.c:51: error: `VI_ZERO' undeclared here (not in a function)
 [snip]
 
 and I checked fcns.h:94.
 
  cat /usr/obj/usr/src/lib/libedit/fcns.h
 [snip]
 #define VI_UNDO_LINE 89
 #define VI_]ERO  90--- ???
 #define EL_NUM_FCNS  91
 typedef el_action_t (*el_func_t)(EditLine *, int);
 protected const el_func_t* func__get(void);
 #endif /* _h_fcns_c */
 
Too bad.  I think this may be related to a recent work of Andrey
on tr(1), as fcns.h is generated using src/lib/libedit/makelist.
Perhaps, just enforcing the C locale will fix it.


Cheers,
-- 
Ruslan Ermilov  Sysadmin and DBA,
[EMAIL PROTECTED]   Sunbay Software Ltd,
[EMAIL PROTECTED]   FreeBSD committer


pgp0.pgp
Description: PGP signature


Re: buildworld broken after installworld

2003-08-04 Thread Ruslan Ermilov
[ standards@ Cc:ed ]

On Mon, Aug 04, 2003 at 06:03:32PM +0400, Andrey Chernov wrote:
 On Mon, Aug 04, 2003 at 17:57:13 +0400, Andrey Chernov wrote:
 
   There is
   
   tr '[a-z]' '[A-Z]'
   
   which can be different for different locales since use collate now as
   required by POSIX. Please tell which exact non-C locale you use and what
   happens? I miss start of this discussion.
  
  Well, I found error in the archives, so the question remains, what locale 
  you use?
 
 For example, this result is right and not the bug (but wrong tr usage):
 
 env LANG=de_DE.ISO8859-1 tr '[a-z]' '[A-Z]'
 vi_zero
 WI_]ERO
 
Clearly this is a useless construct then.

I can read this in the POSIX.1-2003 spec when it comes to tr(1):

: c-c In the POSIX locale, this construct shall
: represent the range of collating elements between
: the range endpoints (as long as neither endpoint
: is an octal sequence of the form \octal),
: inclusive, as defined by the collation sequence.
: The characters or collating elements in the
: range shall be placed in the array in ascending
: collation sequence. If the second endpoint
: precedes the starting endpoint in the collation
: sequence, it is unspecified whether the range
: of collating elements is empty, or this construct
: is treated as invalid. In locales other than
 ^
: the POSIX locale, this construct has unspecified
  
: behavior.
  

This is identical to a similar issue with awk(1), and the latest
snapshot of the One True AWK reverts to NOT using strcoll(3) to
handle character ranges in RE, because different locales and even
the same locales on different operating systems (FreeBSD, Linux,
and Solaris were compared) have different ideas about the collating
order.  On Linux, the German locale's collating sequence will be
``A a ... B b'', while on FreeBSD, it's ``A B ... a b''.

So I'd rather prefer if we revert to the old behavior in tr(1).


Cheers,
-- 
Ruslan Ermilov  Sysadmin and DBA,
[EMAIL PROTECTED]   Sunbay Software Ltd,
[EMAIL PROTECTED]   FreeBSD committer


pgp0.pgp
Description: PGP signature


Re: buildworld broken after installworld

2003-08-04 Thread Ruslan Ermilov
On Mon, Aug 04, 2003 at 08:58:00PM +0200, Dag-Erling Sm?rgrav wrote:
 Ruslan Ermilov [EMAIL PROTECTED] writes:
   For example, this result is right and not the bug (but wrong tr usage):
   
   env LANG=de_DE.ISO8859-1 tr '[a-z]' '[A-Z]'
   vi_zero
   WI_]ERO
  Clearly this is a useless construct then.
 
 The correct construct is tr '[:lower:]' '[:upper:]'
 
I think we've now reached the agreement with Andrey that
a more correct, safe, and portable [sic] construct would
be LC_ALL=C tr [:lower:] [:upper:].  It works the same
in any non-broken operating system and with any locale.


Cheers,
-- 
Ruslan Ermilov  Sysadmin and DBA,
[EMAIL PROTECTED]   Sunbay Software Ltd,
[EMAIL PROTECTED]   FreeBSD committer


pgp0.pgp
Description: PGP signature


Re: buildworld broken after installworld

2003-08-04 Thread Ruslan Ermilov
On Tue, Aug 05, 2003 at 01:44:44AM +0400, Andrey Chernov wrote:
 On Mon, Aug 04, 2003 at 23:32:19 +0300, Ruslan Ermilov wrote:
 
  I think we've now reached the agreement with Andrey that
  a more correct, safe, and portable [sic] construct would
  be LC_ALL=C tr [:lower:] [:upper:].  It works the same
  in any non-broken operating system and with any locale.
 
 We need to say, construct for what? If for lower-upper replacing inside
 ASCII only, LC_ALL=C tr [a-z] [A-Z] is most portable because some tr
 implementations even not understand [:class:] but some other have SysV-ism
 to specify ranges in the [], against what POSIX says. But I think that
 LC_ALL=C tr a-z A-Z is better middle point here because not teach user
 to incorrect syntax from the scripts.
 
Agreed.


Cheers,
-- 
Ruslan Ermilov  Sysadmin and DBA,
[EMAIL PROTECTED]   Sunbay Software Ltd,
[EMAIL PROTECTED]   FreeBSD committer


pgp0.pgp
Description: PGP signature


MSDOSFS woes

2003-08-02 Thread Ruslan Ermilov
Gang, :-)

While working with Marcel on a bootable CD-ROM for IA64 issue,
I've stumbled upon the following problem.  I needed to increase
the size of the EFI partition (which is an MS-DOS file system)
to 64M, and that made two of my machines stuck solidly -- a lot
of process are waiting on the wdrain event.

The issue is not IA64 specific, both machines in question are
i386.  The following script makes my machines unhappy:

EFISZ=131072
dd if=/dev/zero of=$BASE/$EFIPART count=$EFISZ
md=`mdconfig -a -t vnode -f $BASE/$EFIPART`
newfs_msdos -F 12 -S 512 -h 4 -o 0 -s $EFISZ -u 16 $md
mount -t msdosfs /dev/$md /mnt
dd if=/dev/zero of=/mnt/foo

Changing to the -F 16 does not take any (good) effect.
Anyone is interested in narrowing it down?


Cheers,
-- 
Ruslan Ermilov  Sysadmin and DBA,
[EMAIL PROTECTED]   Sunbay Software Ltd,
[EMAIL PROTECTED]   FreeBSD committer


pgp0.pgp
Description: PGP signature


Re: MSDOSFS woes

2003-08-02 Thread Ruslan Ermilov
On Sat, Aug 02, 2003 at 05:00:45PM +0100, Bruce Cran wrote:
 On Sat, Aug 02, 2003 at 06:08:50PM +0300, Ruslan Ermilov wrote:
  Gang, :-)
  
  While working with Marcel on a bootable CD-ROM for IA64 issue,
  I've stumbled upon the following problem.  I needed to increase
  the size of the EFI partition (which is an MS-DOS file system)
  to 64M, and that made two of my machines stuck solidly -- a lot
  of process are waiting on the wdrain event.
  
  The issue is not IA64 specific, both machines in question are
  i386.  The following script makes my machines unhappy:
  
  EFISZ=131072
  dd if=/dev/zero of=$BASE/$EFIPART count=$EFISZ
  md=`mdconfig -a -t vnode -f $BASE/$EFIPART`
  newfs_msdos -F 12 -S 512 -h 4 -o 0 -s $EFISZ -u 16 $md
  mount -t msdosfs /dev/$md /mnt
  dd if=/dev/zero of=/mnt/foo
  
  Changing to the -F 16 does not take any (good) effect.
  Anyone is interested in narrowing it down?
  
 
 I've also seen this happening on my Athlon XP system running -CURRENT.  I 
 presumed it was the deadlock in vnode-backed md disks.  It seems that when
 a lot of disk activity occurs on the md partition, the process stops - 
 this is on a 30GB image containing UFS2 partitions /dev/md0s1[a,d,e].
 Attempting to reboot results in the message 'processes would not die - ps
 axl advised', I had to reset the computer because nothing more happened.
 
Yes, the same here.

And I have just been able to reproduce this with only a 16MB MS-DOS file
system on a vnode backed md(4) device.


Cheers,
-- 
Ruslan Ermilov  Sysadmin and DBA,
[EMAIL PROTECTED]   Sunbay Software Ltd,
[EMAIL PROTECTED]   FreeBSD committer


pgp0.pgp
Description: PGP signature


Re: groff and mkdep?

2003-08-02 Thread Ruslan Ermilov
On Fri, Aug 01, 2003 at 11:08:33PM -0700, Peorth wrote:
 That seems so weird.
 CFLAGS and CXXFLAGS were set to something in the general environment,
 for non-port builds, but I thought the FreeBSD make system used for
 ports and such wouldn't get polluted by simply having that defined as a
 variable in the env. *headscratch* Maybe just my mistake, but thanks a
 lot. I never would've realized it was CFLAGS! Perhaps make should warn
 if setting CFLAGS/CXXFLAGS are going to pollute, at least on certain
 things like in the /usr/src tree, though up 'till that point, everything
 built fine, too. *shrug*
 
Hmm.  From the make(1) manpage:

: The four different classes of variables (in order of increasing prece-
: dence) are:
: 
: Environment variables
:  Variables defined as part of make's environment.
: 
: Global variables
:  Variables defined in the makefile or in included makefiles.
: 
: Command line variables
:  Variables defined as part of the command line.
: 
: Local variables
:  Variables that are defined specific to a certain target.  The
:  seven local variables are as follows:

Are you telling me that setting CFLAGS in the ENVIRONMENT causes
this strange behavior?  (I cannot reproduce it here, because
environment variables are of a lower precedence than globals.)

Are you sure you weren't running make(1) with the -e option?
(I can reproduce this with this option, as it causes environment
variables to take higher precedence than globals.)


Cheers,
-- 
Ruslan Ermilov  Sysadmin and DBA,
[EMAIL PROTECTED]   Sunbay Software Ltd,
[EMAIL PROTECTED]   FreeBSD committer


pgp0.pgp
Description: PGP signature


Re: groff and mkdep?

2003-08-01 Thread Ruslan Ermilov
On Fri, Aug 01, 2003 at 08:48:07PM -0700, Peorth wrote:
 I've just started to try and sync up to -CURRENT, and my first time
 asking on the lists, and everything seems to be going fine, except
 groff's build dies with
 rm -f .depend
 mkdep -f .depend -a   
 /usr/src/gnu/usr.bin/groff/src/libs/libdriver/../../../../../../contrib/groff/src/libs/libdriver/input.cpp
  
 /usr/src/gnu/usr.bin/groff/src/libs/libdriver/../../../../../../contrib/groff/src/libs/libdriver/printer.cpp
 /usr/src/contrib/groff/src/libs/libdriver/input.cpp:244:20: driver.h: No
 such file or directory
 /usr/src/contrib/groff/src/libs/libdriver/input.cpp:245:20: device.h: No
 such file or directory
 /usr/src/contrib/groff/src/libs/libdriver/printer.cpp:29:20: driver.h:
 No such file or directory
 mkdep: compile failed
 *** Error code 1
 
 I've tried everything I can think of, including changing the Makefile to
 explicitly include  the groff directories via CFLAGS, CXXFLAGS, and such
 (and it adds the directive), but that doesn't seem to help in the
 slightest.
 Does anyone have any idea what's wrong with this? Is there any way to
 bypass this particular program in the build, and is it safe to do so?
 
I can only reproduce this with make depend CFLAGS=.  Something
somewhere overrides the normal CFLAGS value; the command line
above is incorrect, the correct one should look like this:

mkdep -f .depend -a-DHAVE_CONFIG_H 
-I/usr/src/gnu/usr.bin/groff/src/libs/libdriver/../../../../../../contrib/groff/src/include
 -I/usr/src/gnu/usr.bin/groff/src/libs/libdriver/../../../src/include
/usr/src/gnu/usr.bin/groff/src/libs/libdriver/../../../../../../contrib/groff/src/libs/libdriver/input.cpp
 
/usr/src/gnu/usr.bin/groff/src/libs/libdriver/../../../../../../contrib/groff/src/libs/libdriver/printer.cpp

So in short, something is wrong with your build environment.


Cheers,
-- 
Ruslan Ermilov  Sysadmin and DBA,
[EMAIL PROTECTED]   Sunbay Software Ltd,
[EMAIL PROTECTED]   FreeBSD committer


pgp0.pgp
Description: PGP signature


Re: Who is responsible for the install check goo in Makefile.inc1

2003-07-30 Thread Ruslan Ermilov
[ Moved to -current ] 

On Tue, Jul 29, 2003 at 07:12:09PM -0700, Peter Wemm wrote:
 John Birrell wrote:
[...]
  The installworld check for a kernel with the new sigaction promptly
  core-dumped sh with the unsupported syscall. I think this check should
  be based on sysctl kern.osreldate, not just running the new shell to see
  if it core dumps. Thats kind of sub-optimal because I normally associate
  core dumps during build/installworld with a dodgy build. In this case,
  the build wasn't dodgy... I just hadn't realised that I was missing a toe.
 
 The problem is that some of the install scripts run the host /bin/sh *after*
 src/bin has been installed.  If your sh in ${OBJDIR} wont run, you *WILL*
 be hosed later on in the build with about a 50:50 split between old and new
 worlds.  I dont recall which scripts are the culprits, but it is a side
 effect of #! /bin/sh that is on a script that is run during installworld.
 
 In theory, the 'make installworld' stuff copies everything needed for an
 installworld to a /tmp directory, but it still misses a bunch of
 #! /bin/sh type things.  This isn't a cross build issue because the shell
 scripts are run on the host.
 
 For what its worth, this test saved me yesterday when I was trying to update
 an ancient ia64 box to -current.
 
That wasn't the point John was trying to make, IMO.

I'm regularly upgrading 4.0-RELEASE to 5.x-CURRENT to check that
the upgrade path wasn't broken, and this check comes very handy.
I wouldn't object though if it was done using kern.osreldate.

I'd happily test any patches in this direction for you, John.


Cheers,
-- 
Ruslan Ermilov  Sysadmin and DBA,
[EMAIL PROTECTED]   Sunbay Software Ltd,
[EMAIL PROTECTED]   FreeBSD committer


pgp0.pgp
Description: PGP signature


Re: Who is responsible for the install check goo in Makefile.inc1

2003-07-30 Thread Ruslan Ermilov
On Wed, Jul 30, 2003 at 05:34:01PM +1000, John Birrell wrote:
 On Wed, Jul 30, 2003 at 10:24:42AM +0300, Ruslan Ermilov wrote:
  I'm regularly upgrading 4.0-RELEASE to 5.x-CURRENT to check that
  the upgrade path wasn't broken, and this check comes very handy.
  I wouldn't object though if it was done using kern.osreldate.
  
  I'd happily test any patches in this direction for you, John.
 
 Thanks. Since Peter made the change, I'd like to wait for him to comment
 on the code I sent him that would avoid the core dump. I think that running
 sh as a final check is valid, but I'd like to see a 'probable' case checked
 first and an message printed accordingly before making the core dump as a
 last resort (in favour of shooting the whole foot off - one toe is better
 than the whole foot!).
 
Sure, that would be a much better (and safer) approach.  Could you
please send me your code as well, I'm interested in revieweing it.

P.S.  Nice to see you're still in the FreeBSD business.  :-)


Cheers,
-- 
Ruslan Ermilov  Sysadmin and DBA,
[EMAIL PROTECTED]   Sunbay Software Ltd,
[EMAIL PROTECTED]   FreeBSD committer


pgp0.pgp
Description: PGP signature


make -U

2003-07-30 Thread Ruslan Ermilov
Sorry, I've accidentally dropped an email about `make -U'.

I think that it's not needed, since the functionality can
easily be achieved by running make FOO=, i.e., assigning
an empty value.  Remember that command line variables take
precedence over globals, so the following makefile,

FOO+=   bar

all:
@echo ${FOO}

when run as ``make FOO=foo'', will print just ``foo''.


Cheers,
-- 
Ruslan Ermilov  Sysadmin and DBA,
[EMAIL PROTECTED]   Sunbay Software Ltd,
[EMAIL PROTECTED]   FreeBSD committer


pgp0.pgp
Description: PGP signature


Re: make -U

2003-07-30 Thread Ruslan Ermilov
On Wed, Jul 30, 2003 at 04:23:20PM -0500, Juli Mallett wrote:
 * Ruslan Ermilov [EMAIL PROTECTED] [ Date: 2003-07-30 ]
   [ w.r.t. make -U ]
  Sorry, I've accidentally dropped an email about `make -U'.
  
  I think that it's not needed, since the functionality can
  easily be achieved by running make FOO=, i.e., assigning
  an empty value.  Remember that command line variables take
  precedence over globals, so the following makefile,
  
  FOO+=   bar
  
  all:
  @echo ${FOO}
  
  when run as ``make FOO=foo'', will print just ``foo''.
 
 Does that work for the .if defined() case, too?  Makefiles can grow
 to be more complex than just that sort of stuff, after all :)
 
Not sure what do you mean.  The make -U FOO was support to
undefine the FOO variable, as it the ``.undef FOO'' was called
at the end of makefile.  Of course, setting FOO= on a command
line still gets you a defined variable, but

.if defined(FOO)  !empty(FOO)

should do the trick.  Try this out with make FOO=:

FOO=bar

all:
.if defined(FOO)  !empty(FOO)
@echo FOO is set
.endif


Cheers,
-- 
Ruslan Ermilov  Sysadmin and DBA,
[EMAIL PROTECTED]   Sunbay Software Ltd,
[EMAIL PROTECTED]   FreeBSD committer


pgp0.pgp
Description: PGP signature


Re: -current 'make release' status?

2003-07-29 Thread Ruslan Ermilov
On Tue, Jul 29, 2003 at 06:30:54AM -0400, John wrote:
 Hi,
 
I'm currently down to this patch to allow a make release to complete
 for -current:
 
[...]

Try setting the KERNEL_FLAGS=-DNO_WERROR instead.

without it, the following causes BOOTMFS to abort:
 
 cc -c -Os -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes  
 -Wmissing-prototypes -Wpointer-arith 
 -Winline -Wcast-qual  -fformat-extensions -std=c99  -nostdinc -I-  -I. 
 -I/usr/src/sys -I/usr/src/sys/dev -I/usr/src
 /sys/contrib/dev/acpica -I/usr/src/sys/contrib/ipfilter 
 -I/usr/src/sys/contrib/dev/ath -I/usr/src/sys/contrib/dev/a
 th/freebsd -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000  
 -mno-align-long-strings -mpreferred-st
 ack-boundary=2 -ffreestanding -Werror  /usr/src/sys/cam/cam_periph.c
 In file included from /usr/src/sys/cam/cam_periph.c:41:
 /usr/src/sys/sys/buf.h: In function `BUF_LOCK':
 /usr/src/sys/sys/buf.h:289: warning: dereferencing type-punned pointer will break 
 strict-aliasing rules
 /usr/src/sys/sys/buf.h:289: warning: dereferencing type-punned pointer will break 
 strict-aliasing rules
 /usr/src/sys/sys/buf.h: In function `BUF_TIMELOCK':
 /usr/src/sys/sys/buf.h:310: warning: dereferencing type-punned pointer will break 
 strict-aliasing rules
 /usr/src/sys/sys/buf.h:310: warning: dereferencing type-punned pointer will break 
 strict-aliasing rules
 /usr/src/sys/sys/buf.h: In function `BUF_UNLOCK':
 /usr/src/sys/sys/buf.h:325: warning: dereferencing type-punned pointer will break 
 strict-aliasing rules
 /usr/src/sys/sys/buf.h:325: warning: dereferencing type-punned pointer will break 
 strict-aliasing rules
 /usr/src/sys/sys/buf.h: In function `BUF_KERNPROC':
 /usr/src/sys/sys/buf.h:350: warning: dereferencing type-punned pointer will break 
 strict-aliasing rules
 /usr/src/sys/sys/buf.h:350: warning: dereferencing type-punned pointer will break 
 strict-aliasing rules
 /usr/src/sys/sys/buf.h:352: warning: dereferencing type-punned pointer will break 
 strict-aliasing rules
 /usr/src/sys/sys/buf.h:352: warning: dereferencing type-punned pointer will break 
 strict-aliasing rules
 /usr/src/sys/cam/cam_periph.c: In function `cam_periph_mapmem':
 /usr/src/sys/cam/cam_periph.c:624: warning: dereferencing type-punned pointer will 
 break strict-aliasing rules
 .
 .
 .
 
Thoughts? Plans?
 
It's also worth noting that the BOOTMFS kernel build is inconsistant. The
 initial build via 'make release' fails with no patch. After the failure,
 a followup:
 
 chroot $RDIR /bin/sh
 /mk doMFSKERN
 
 works correctly. The 'make release' environment is setup differently
 from that of /mk. Depending on what folks think, maybe some form of:
 
 make mk TARGET=doMFSKERN
 
 would be appropriate to guarentee consistancy. Just a thought.
 
If this is the case, then it's a bug and should be fixed.  I am
looking to see now if I can reproduce the problem, but a wild
guess is that: release/Makefile calls chroot(8) a bit differently,
with a clean environment, like this:

env -i /usr/sbin/chroot ${CHROOTDIR} /mk

Could it be that you have something in your environment similar
to NO_WERROR?


Cheers,
-- 
Ruslan Ermilov  Sysadmin and DBA,
[EMAIL PROTECTED]   Sunbay Software Ltd,
[EMAIL PROTECTED]   FreeBSD committer


pgp0.pgp
Description: PGP signature


Re: new.h is missing

2003-07-29 Thread Ruslan Ermilov
On Tue, Jul 29, 2003 at 02:00:59PM +0200, Kai Mosebach wrote:
[...]
 I was wondering, that in 4.x there is a folder /usr/include/g++
 where all the stuff is found, and on 5.1-CURRENT its in
 /usr/include/c++/3.3, where im not sure, whether g++ uses this path
 automatically ?
 
/usr/libexec/cc1plus -v


Cheers,
-- 
Ruslan Ermilov  Sysadmin and DBA,
[EMAIL PROTECTED]   Sunbay Software Ltd,
[EMAIL PROTECTED]   FreeBSD committer


pgp0.pgp
Description: PGP signature


Re: new.h is missing

2003-07-29 Thread Ruslan Ermilov
On Tue, Jul 29, 2003 at 02:09:24PM +0200, Kai Mosebach wrote:
 
  -Urspr?ngliche Nachricht-
  Von: Ruslan Ermilov [mailto:[EMAIL PROTECTED]
  Gesendet: Dienstag, 29. Juli 2003 14:06
  An: Kai Mosebach
  Cc: David Leimbach; Michael Reifenberger; [EMAIL PROTECTED]
  Betreff: Re: new.h is missing
  
  On Tue, Jul 29, 2003 at 02:00:59PM +0200, Kai Mosebach wrote:
  [...]
   I was wondering, that in 4.x there is a folder /usr/include/g++
   where all the stuff is found, and on 5.1-CURRENT its in
   /usr/include/c++/3.3, where im not sure, whether g++ uses this path
   automatically ?
  
  /usr/libexec/cc1plus -v
 
 [EMAIL PROTECTED]:~] # /usr/libexec/cc1plus -v
 GNU CPP version 3.2.2 [FreeBSD] 20030205 (release) (cpplib) (i386
 FreeBSD/ELF)
 ignoring nonexistent directory /usr/include/g++/backward
 ignoring duplicate directory /usr/include
 #include ... search starts here:
 #include ... search starts here:
  /usr/include/g++
  /usr/include
 End of search list.
 
 Where are they defined ?
 
On 5.1-CURRENT, this looks differently:

$ /usr/libexec/cc1plus -v
ignoring duplicate directory /usr/include
#include ... search starts here:
#include ... search starts here:
 /usr/include/c++/3.3
 /usr/include/c++/3.3/backward
 /usr/include
End of search list.
^C


Cheers,
-- 
Ruslan Ermilov  Sysadmin and DBA,
[EMAIL PROTECTED]   Sunbay Software Ltd,
[EMAIL PROTECTED]   FreeBSD committer


pgp0.pgp
Description: PGP signature


Re: -current 'make release' status? [SOLVED]

2003-07-29 Thread Ruslan Ermilov
On Tue, Jul 29, 2003 at 09:41:54AM -0400, John De Boskey wrote:
 - Ruslan Ermilov's Original Message -
   
   No, I have nothing in my environment that should affect the
   build, no /etc/make.conf in the chroot area..
   
  But then again: running make rerelease is effectively just
  calls the command above.  I'm currently in the middle of the
  make release and will see if this is reproduceable.
  
   # chroot /vol/vol0/work/5-current-chrootdir /bin/sh
   # env
   
   A few things not needed that are inherited from my normal
   account, but nothing that should have a negative affect.
   
  Do you still get the error if you try make rerelease?
  Do you still get the error if you try chroot ... /mk?
  Do you still get the error if you try env -i chroot ... /mk?
 
 I'll see what I can find..
 
John,

I see the same breakage as you do.  But in all three cases
above, I see the same breakage (as expected).  Even if I'm
running chroot /data/ru/R then ./mk doMFSKERN, I still
get it:

: In file included from /usr/src/sys/cam/cam_periph.c:41:
: /usr/src/sys/sys/buf.h: In function `BUF_LOCK':
: /usr/src/sys/sys/buf.h:289: warning: dereferencing type-punned pointer will break 
strict-aliasing rules
: ...
: *** Error code 1
: 
: Stop in /usr/obj/usr/src/sys/BOOTMFS.

Forget what I've said about NO_WERROR, it (unfortunately) only
applies to the userland.

Still, running make rerelease KERNEL_FLAGS=WERROR= gets the
release done.

I wondered why I get it, and similarly my nigthly buildkernel
completed without errors.  This turned out to be due to the
-O vs. -Os differences.  For example, compiling vfs_subr.o
from the GENERIC kernel results in these same warnings when
compiled with COPTFLAGS=-Os -pipe.  Peter, should we switch
-Werror back off in kern.pre.mk?


Cheers,
-- 
Ruslan Ermilov  Sysadmin and DBA,
[EMAIL PROTECTED]   Sunbay Software Ltd,
[EMAIL PROTECTED]   FreeBSD committer


pgp0.pgp
Description: PGP signature


Re: -current 'make release' status? [SOLVED]

2003-07-29 Thread Ruslan Ermilov
On Wed, Jul 30, 2003 at 06:14:17AM +1000, Bruce Evans wrote:
 On Tue, 29 Jul 2003, Ruslan Ermilov wrote:
 
  ...
  Forget what I've said about NO_WERROR, it (unfortunately) only
  applies to the userland.
 
  Still, running make rerelease KERNEL_FLAGS=WERROR= gets the
  release done.
 
  I wondered why I get it, and similarly my nigthly buildkernel
  completed without errors.  This turned out to be due to the
  -O vs. -Os differences.  For example, compiling vfs_subr.o
  from the GENERIC kernel results in these same warnings when
  compiled with COPTFLAGS=-Os -pipe.  Peter, should we switch
  -Werror back off in kern.pre.mk?
 
 Use -fno-strict-aliasing if you use -Os.  Otherwise, -Os is stricter
 than -O.
 
 On second thoughts, -Os implies -f-strict-aliasing because -Os may
 need strict aliasing for the same reasons as -O2.  We've seen -O2
 in combination with broken aliasing in libm cause fatal errors.
 Better find part of -O2 that needs strict aliasing and turn it off
 too.
 
Hm, I always thought that -O2 and -Os are just useful aliases
that in effect only turn a few dozens of -f optimization flags,
and that switching some of them off later is allowed.  I.e.,
-Os -fno-strict-aliasing should work.


Cheers,
-- 
Ruslan Ermilov  Sysadmin and DBA,
[EMAIL PROTECTED]   Sunbay Software Ltd,
[EMAIL PROTECTED]   FreeBSD committer


pgp0.pgp
Description: PGP signature


Re: Checking buildworld success from ssh

2003-07-28 Thread Ruslan Ermilov
On Mon, Jul 28, 2003 at 09:28:07AM -0400, Gregory Pavelcak wrote:
 Hi all,
 
 I started a buildworld on current sources this morning, but,
 foolishly, didn't redirect the output to a file. Now I have some
 free time at work and would like to ssh in and do the kernel and
 mergemaster. Of course, I don't want to do these things if
 buildworld failed. Is there any way I can tell in the absence of
 saved output?
 
The last thing made is creation of the freebsd.cf file.
See if it was created in /usr/obj/usr/src/etc/sendmail.


Cheers,
-- 
Ruslan Ermilov  Sysadmin and DBA,
[EMAIL PROTECTED]   Sunbay Software Ltd,
[EMAIL PROTECTED]   FreeBSD committer


pgp0.pgp
Description: PGP signature


Re: make release broken [FIX]

2003-07-25 Thread Ruslan Ermilov
On Fri, Jul 25, 2003 at 01:59:40PM -0700, David O'Brien wrote:
 On Tue, Jul 22, 2003 at 02:26:34PM -0400, John Baldwin wrote:
  
  On 22-Jul-2003 Ruslan Ermilov wrote:
   Hi!
   
   As many of you probably know, recent telnet commit broke snapshot
   building.  Since I needed a working make release to go on with
   my task on floppy-less make release (for AMD64, etc.), I had to
   just fix it.  Attached is the patch.  It also fixes another issue
   with this telnet commit: it ensures that crypto telnet[d] do not
   end up in the base distribution.
  
  Why not simply enable 'NO_FLOPPIES' on the arch's that don't want
  floppies?
 
 For one, its broken -- NO_FLOPPIES doesn't build the bootmfs floppy but
 still does the driver floppy.  At least for Alpha this was true during
 5.1 RC time.
  
Please look at the latest release/Makefile, then follow up in this
thread.


Cheers,
-- 
Ruslan Ermilov  Sysadmin and DBA,
[EMAIL PROTECTED]   Sunbay Software Ltd,
[EMAIL PROTECTED]   FreeBSD committer


pgp0.pgp
Description: PGP signature


Re: Floppyless release build of sparc64

2003-07-25 Thread Ruslan Ermilov
On Fri, Jul 25, 2003 at 01:39:14PM -0700, David O'Brien wrote:
 On Thu, Jul 24, 2003 at 11:50:10PM +0300, Ruslan Ermilov wrote:
 boot.flp is actually useful on sparc64 because you can dd it to a disk
 from solaris and then boot off it to install.  I'm happy with having
 the option of not building it if it saves time but please make it an
 option.

OK, then things will be left as is.  There's already an option for
this; it's called NO_FLOPPIES (documented in the release(7) manpage).
   
   BUT the size of the floppy should be something like 10MB so that we
   know we will *never* overflow it during make release.
   
  Should the need arise for that, it's a two-line change to release/Makefile,
  by just bumping MFSSIZE and BIGBOOTSIZE for sparc64.
 
 You're missing the point.  The size should be set now to something that
 will *never* be too small.  Waiting until make release is broken is
 stupid in this case.
 
I will leave this up to the sparc64 port maintainers, okay?


Cheers,
-- 
Ruslan Ermilov  Sysadmin and DBA,
[EMAIL PROTECTED]   Sunbay Software Ltd,
[EMAIL PROTECTED]   FreeBSD committer


pgp0.pgp
Description: PGP signature


Re: Alpha/EISA broken?

2003-07-25 Thread Ruslan Ermilov
On Fri, Jul 25, 2003 at 05:49:15PM +0100, Mark Murray wrote:
 Wilko Bulte writes:
   GENERIC kernel also has above error.
   
   Remove eisa, and the boot goes straight to panic (no clock).
  
  That is because your clock sits behind eisa I think. ticso recently
  posted some days ago that eisa is now mandatory on alpha.
  I did not follow in detail to be honest. Check the archives.
 
 Well, that's left me hosed :-(.
 
 I looked through current@ and alpha@ (briefly) and saw nothing
 obvious. What should I be looking for?
 
I think cvs-all@ would be more appropriate.


Cheers,
-- 
Ruslan Ermilov  Sysadmin and DBA,
[EMAIL PROTECTED]   Sunbay Software Ltd,
[EMAIL PROTECTED]   FreeBSD committer


pgp0.pgp
Description: PGP signature


NOCRYPT and exists(src/crypto) check

2003-07-24 Thread Ruslan Ermilov
Hi there!

There's currently an inconsistency in how various makefiles
(that use crypto bits) check if these bits are available.
All of them check for the NOCRYPT knob, and some of them
also check if src/crypto/ exists, and some not.  None of
them also check if src/secure/ exists, which is the where
the crypto libraries get actually built.  Here's the current
summary of these makefiles:

makefiles that don't check if src/crypto/ exists:

gnu/usr.bin/cvs/cvs/Makefile
lib/libfetch/Makefile
lib/libtelnet/Makefile
libexec/telnetd/Makefile
usr.bin/fetch/Makefile
usr.bin/telnet/Makefile
usr.sbin/pkg_install/Makefile
usr.sbin/pkg_install/add/Makefile
usr.sbin/pkg_install/create/Makefile
usr.sbin/pkg_install/delete/Makefile
usr.sbin/pkg_install/info/Makefile
usr.sbin/pkg_install/version/Makefile

makefiles that check if src/crypto/ exists:

bin/ed/Makefile
games/factor/Makefile
lib/Makefile
rescue/rescue/Makefile
usr.bin/Makefile
usr.sbin/Makefile
usr.sbin/ppp/Makefile
usr.sbin/pppd/Makefile
usr.sbin/sendmail/Makefile
usr.sbin/tcpdump/tcpdump/Makefile

Since the exists(${.CURDIR}/.../crypto)  !defined(NOCRYPT) check
is weak (it lacks the exists(${.CURDIR}/.../secure) check), I suggest
to simplify these makefiles and remove these obscure exists() checks.
Users that don't fetch crypto sources (src/crypto/ and src/secure/)
will then just have to specify that in their /etc/make.conf.  Not
fetching crypto sources and not specifying NOCRYPT currently gives
a broken build, so this change shouldn't surprise a lot of people.
Also, a similar change for src/kerberos5/ is proposed.

I'd appreciate a quick response.


Cheers,
-- 
Ruslan Ermilov  Sysadmin and DBA,
[EMAIL PROTECTED]   Sunbay Software Ltd,
[EMAIL PROTECTED]   FreeBSD committer


pgp0.pgp
Description: PGP signature


Re: Floppyless release build of sparc64

2003-07-24 Thread Ruslan Ermilov
On Thu, Jul 24, 2003 at 11:55:10AM -0700, David O'Brien wrote:
 On Wed, Jul 23, 2003 at 07:07:30PM +0300, Ruslan Ermilov wrote:
  On Wed, Jul 23, 2003 at 11:57:58AM -0400, Jake Burkholder wrote:
   Apparently, On Wed, Jul 23, 2003 at 09:16:43AM +0300,
 Ruslan Ermilov said words to the effect of;
   
A similar change would be in order for sparc64.  Patch is
attached, please review.  The net effect is that we save
huge CPU times in release.9 and do not create the useless
boot.flp floppy image (the sparc64/mkisoimages.sh script
doesn't need it).
   
   boot.flp is actually useful on sparc64 because you can dd it to a disk
   from solaris and then boot off it to install.  I'm happy with having
   the option of not building it if it saves time but please make it an
   option.
  
  OK, then things will be left as is.  There's already an option for
  this; it's called NO_FLOPPIES (documented in the release(7) manpage).
 
 BUT the size of the floppy should be something like 10MB so that we
 know we will *never* overflow it during make release.
 
Should the need arise for that, it's a two-line change to release/Makefile,
by just bumping MFSSIZE and BIGBOOTSIZE for sparc64.


Cheers,
-- 
Ruslan Ermilov  Sysadmin and DBA,
[EMAIL PROTECTED]   Sunbay Software Ltd,
[EMAIL PROTECTED]   FreeBSD committer


pgp0.pgp
Description: PGP signature


Re: make release broken [FIX]

2003-07-23 Thread Ruslan Ermilov
On Tue, Jul 22, 2003 at 03:07:01PM -0400, John Baldwin wrote:
 
  Are you eliminating the mfsroot?
  
  Yes.
 
 Ugh.
 
 How does sysinstall work with this change?  You do realize that we
 mount the MFS as /, then mount the disk under /mnt, chroot to /mnt,
 then mount the CD in /dist in the chroot and install from there?
 Are you going to mount the CD as root or something?  It is probably
 a lot simpler to simply let sysinstall always execute in a MFS root.
 
John, Warner,

At this stage it's obvious to me that we'd better with always
building mfsroot stuff, even for platforms that do not provide
floppy installation (AMD64).  As such, the following commit
would be in order, but as it falls under the obrien vs ru
category, I hereby ask (again) your permission to commit it:

%%%
Index: Makefile
===
RCS file: /home/ncvs/src/release/Makefile,v
retrieving revision 1.790
diff -u -r1.790 Makefile
--- Makefile23 Jul 2003 06:00:56 -  1.790
+++ Makefile23 Jul 2003 06:02:11 -
@@ -985,14 +985,8 @@
   md5 *  CHECKSUM.MD5) \
)
 
-.if target(release.9.${TARGET_ARCH})
-RELEASE9=release.9.${TARGET_ARCH}
-.else
-RELEASE9=release.9 
-.endif
-
 doRELEASE:  release.1 release.2 release.3 ${DOCREL} release.4 release.5 \
-   release.6 release.7 release.8 ${RELEASE9} ${FIXIT_TARGET}
+   release.6 release.7 release.8 release.9 ${FIXIT_TARGET}
@cd ${.CURDIR}  ${MAKE} ${EXTRAS}
@echo Release done
 
%%%

The release.9 target is responsible for creating mfsroot, amongst
other tasks.


Cheers,
-- 
Ruslan Ermilov  Sysadmin and DBA,
[EMAIL PROTECTED]   Sunbay Software Ltd,
[EMAIL PROTECTED]   FreeBSD committer


pgp0.pgp
Description: PGP signature


Floppyless release build of sparc64

2003-07-23 Thread Ruslan Ermilov
A similar change would be in order for sparc64.  Patch is
attached, please review.  The net effect is that we save
huge CPU times in release.9 and do not create the useless
boot.flp floppy image (the sparc64/mkisoimages.sh script
doesn't need it).

On Tue, Jul 22, 2003 at 10:53:53PM -0700, Ruslan Ermilov wrote:
 ru  2003/07/22 22:53:53 PDT
 
   FreeBSD src repository
 
   Modified files:
 release  Makefile 
   Log:
   Do not define BIGBOOTSIZE and the friends for amd64; it serves
   no useful purpose other than wasting CPU time in make release
   creating useless boot.flp.
   
   Desired by: peter
   
   Revision  ChangesPath
   1.789 +0 -3  src/release/Makefile


Cheers,
-- 
Ruslan Ermilov  Sysadmin and DBA,
[EMAIL PROTECTED]   Sunbay Software Ltd,
[EMAIL PROTECTED]   FreeBSD committer
Index: Makefile
===
RCS file: /home/ncvs/src/release/Makefile,v
retrieving revision 1.790
diff -u -r1.790 Makefile
--- Makefile23 Jul 2003 06:00:56 -  1.790
+++ Makefile23 Jul 2003 06:09:41 -
@@ -202,11 +202,8 @@
 BIGBOOTLABEL=  minimum2
 .elif ${TARGET_ARCH} == sparc64
 DISKLABEL= sunlabel
-BIGBOOTSIZE=   4096
 MFSSIZE=   4096
-BOOTINODE= 8192
 MFSINODE=  8192
-BIGBOOTLABEL=  auto
 MFSLABEL=  auto
 .elif ${TARGET_ARCH} == ia64
 BIGBOOTLABEL=  efi
Index: sparc64/dokern.sh
===
RCS file: sparc64/dokern.sh
diff -N sparc64/dokern.sh
--- sparc64/dokern.sh   13 Oct 2002 18:36:06 -  1.1
+++ /dev/null   1 Jan 1970 00:00:00 -
@@ -1,6 +0,0 @@
-#!/bin/sh
-#
-# $FreeBSD: src/release/sparc64/dokern.sh,v 1.1 2002/10/13 18:36:06 jake Exp $
-#
-
-sed-e 's/ident.*GENERIC/ident  BOOTMFS/g'


pgp0.pgp
Description: PGP signature


Re: make release broken [FIX]

2003-07-23 Thread Ruslan Ermilov
On Tue, Jul 22, 2003 at 07:42:33PM +0300, Ruslan Ermilov wrote:
 Hi!
 
 As many of you probably know, recent telnet commit broke snapshot
 building.  Since I needed a working make release to go on with
 my task on floppy-less make release (for AMD64, etc.), I had to
 just fix it.  Attached is the patch.  It also fixes another issue
 with this telnet commit: it ensures that crypto telnet[d] do not
 end up in the base distribution.
 
Missed in the patch: set DISTRIBUTION=crypto in lib/libtelnet/Makefile,
so that we still have crypto/usr/include/arpa/telnet.h.

%%%
Index: Makefile
===
RCS file: /home/ncvs/src/lib/libtelnet/Makefile,v
retrieving revision 1.16
diff -u -r1.16 Makefile
--- Makefile20 Jul 2003 23:29:46 -  1.16
+++ Makefile23 Jul 2003 06:37:09 -
@@ -13,10 +13,11 @@
 
 WARNS?=2
 
-.if !defined(NOCRYPT)  !defined(NO_OPENSSL)
+.if exists(${.CURDIR}/../../crypto)  !defined(NOCRYPT)  !defined(NO_OPENSSL)
+DISTRIBUTION=  crypto
 SRCS+= encrypt.c auth.c enc_des.c sra.c pk.c
 CFLAGS+=   -DENCRYPTION -DAUTHENTICATION -DSRA
-.if !defined(NO_KERBEROS)
+.if exists(${.CURDIR}/../../kerberos5)  !defined(NO_KERBEROS)
 SRCS+= kerberos5.c
 CFLAGS+=   -DKRB5 -I${KRB5DIR}/lib/krb5 -I${KRB5OBJDIR} -I${ASN1OBJDIR}
 CFLAGS+=   -DFORWARD -Dnet_write=telnet_net_write
%%%


Cheers,
-- 
Ruslan Ermilov  Sysadmin and DBA,
[EMAIL PROTECTED]   Sunbay Software Ltd,
[EMAIL PROTECTED]   FreeBSD committer


pgp0.pgp
Description: PGP signature


Re: make release broken [FIX]

2003-07-23 Thread Ruslan Ermilov
On Wed, Jul 23, 2003 at 11:33:50AM +0100, Mark Murray wrote:
 Hi
 
 Please do not commit this.
 
Please stop repeating this endlessly.  This patch is only
for those who need a working make release urgently, like
me.  You made it clear that you're working on a better fix.

-- 
Ruslan Ermilov  Sysadmin and DBA,
[EMAIL PROTECTED]   Sunbay Software Ltd,
[EMAIL PROTECTED]   FreeBSD committer


pgp0.pgp
Description: PGP signature


Re: Floppyless release build of sparc64

2003-07-23 Thread Ruslan Ermilov
On Wed, Jul 23, 2003 at 11:57:58AM -0400, Jake Burkholder wrote:
 Apparently, On Wed, Jul 23, 2003 at 09:16:43AM +0300,
   Ruslan Ermilov said words to the effect of;
 
  A similar change would be in order for sparc64.  Patch is
  attached, please review.  The net effect is that we save
  huge CPU times in release.9 and do not create the useless
  boot.flp floppy image (the sparc64/mkisoimages.sh script
  doesn't need it).
 
 boot.flp is actually useful on sparc64 because you can dd it to a disk
 from solaris and then boot off it to install.  I'm happy with having
 the option of not building it if it saves time but please make it an
 option.
 
OK, then things will be left as is.  There's already an option for
this; it's called NO_FLOPPIES (documented in the release(7) manpage).


Cheers,
-- 
Ruslan Ermilov  Sysadmin and DBA,
[EMAIL PROTECTED]   Sunbay Software Ltd,
[EMAIL PROTECTED]   FreeBSD committer


pgp0.pgp
Description: PGP signature


Re: mergemaster broken

2003-07-22 Thread Ruslan Ermilov
On Sun, Jul 06, 2003 at 08:21:14PM -0700, Gregory Neil Shapiro wrote:
   mergemaster -dv
  
  [snip]
  
  cd /usr/src/etc/sendmail; make distribution
  install -o root -g wheel -m 644  /usr/src/etc/sendmail/freebsd.mc freebsd.cf 
  /var/tmp/temproot.0707.11.55/etc/mail
  install: freebsd.cf: No such file or directory
  *** Error code 71
 
 Thanks, I just committed a fix for this.
 
Er,

The correct fix would be to revert this change from sendmail/Makefile,
and fix mergemaster(8) instead, as shown in the attached patch.  The
distribution target of src/etc/Makefile is part of the standard
distribute target, and as such it's just a specialized version of
the install target that should not _build_ anything (and that was
fixed in rev. 1.23).  To build things, one needs to call the all
target, which the attached patch simply does.  It's just a pure
coincidence that the distribution part of src/etc/Makefile does
not need to build anything (in the object directory).

Can you please test it and commit?


Cheers,
-- 
Ruslan Ermilov  Sysadmin and DBA,
[EMAIL PROTECTED]   Sunbay Software Ltd,
[EMAIL PROTECTED]   FreeBSD committer
Index: mergemaster.sh
===
RCS file: /home/ncvs/src/usr.sbin/mergemaster/mergemaster.sh,v
retrieving revision 1.46
diff -u -r1.46 mergemaster.sh
--- mergemaster.sh  3 May 2003 06:35:19 -   1.46
+++ mergemaster.sh  22 Jul 2003 12:31:23 -
@@ -508,6 +508,7 @@
   esac
   make DESTDIR=${TEMPROOT} distrib-dirs 
   make MAKEOBJDIRPREFIX=${TEMPROOT}/usr/obj obj 
+  make MAKEOBJDIRPREFIX=${TEMPROOT}/usr/obj all 
   make MAKEOBJDIRPREFIX=${TEMPROOT}/usr/obj DESTDIR=${TEMPROOT} \
   distribution;} ||
 { echo '';


pgp0.pgp
Description: PGP signature


make release broken [FIX]

2003-07-22 Thread Ruslan Ermilov
Hi!

As many of you probably know, recent telnet commit broke snapshot
building.  Since I needed a working make release to go on with
my task on floppy-less make release (for AMD64, etc.), I had to
just fix it.  Attached is the patch.  It also fixes another issue
with this telnet commit: it ensures that crypto telnet[d] do not
end up in the base distribution.


Cheers,
-- 
Ruslan Ermilov  Sysadmin and DBA,
[EMAIL PROTECTED]   Sunbay Software Ltd,
[EMAIL PROTECTED]   FreeBSD committer
Index: release/Makefile
===
RCS file: /home/ncvs/src/release/Makefile,v
retrieving revision 1.787
diff -u -r1.787 Makefile
--- release/Makefile4 Jul 2003 14:39:17 -   1.787
+++ release/Makefile21 Jul 2003 20:14:33 -
@@ -236,7 +236,8 @@
 .if !defined(FIXCRYPTO)
 FIXCRYPTO!=cd ${.CURDIR}/../kerberos5; ${MAKE} -V KPROGS
 FIXCRYPTO+=bin/ed usr.sbin/ppp usr.sbin/pppd usr.sbin/tcpdump/tcpdump \
-   lib/libfetch usr.bin/fetch
+   lib/libfetch usr.bin/fetch \
+   lib/libtelnet libexec/telnetd usr.bin/telnet
 .if !defined(NO_SENDMAIL)
 FIXCRYPTO+=usr.sbin/sendmail
 .endif
Index: lib/libtelnet/Makefile
===
RCS file: /home/ncvs/src/lib/libtelnet/Makefile,v
retrieving revision 1.16
diff -u -r1.16 Makefile
--- lib/libtelnet/Makefile  20 Jul 2003 23:29:46 -  1.16
+++ lib/libtelnet/Makefile  21 Jul 2003 19:58:26 -
@@ -13,10 +13,10 @@
 
 WARNS?=2
 
-.if !defined(NOCRYPT)  !defined(NO_OPENSSL)
+.if exists(${.CURDIR}/../../crypto)  !defined(NOCRYPT)  !defined(NO_OPENSSL)
 SRCS+= encrypt.c auth.c enc_des.c sra.c pk.c
 CFLAGS+=   -DENCRYPTION -DAUTHENTICATION -DSRA
-.if !defined(NO_KERBEROS)
+.if exists(${.CURDIR}/../../kerberos5)  !defined(NO_KERBEROS)
 SRCS+= kerberos5.c
 CFLAGS+=   -DKRB5 -I${KRB5DIR}/lib/krb5 -I${KRB5OBJDIR} -I${ASN1OBJDIR}
 CFLAGS+=   -DFORWARD -Dnet_write=telnet_net_write
Index: libexec/telnetd/Makefile
===
RCS file: /home/ncvs/src/libexec/telnetd/Makefile,v
retrieving revision 1.21
diff -u -r1.21 Makefile
--- libexec/telnetd/Makefile20 Jul 2003 23:29:46 -  1.21
+++ libexec/telnetd/Makefile21 Jul 2003 20:19:17 -
@@ -28,12 +28,13 @@
 DPADD= ${LIBUTIL} ${LIBTERMCAP} ${LIBTELNET}
 LDADD= -lutil -ltermcap ${LIBTELNET}
 
-.if !defined(NOCRYPT)  !defined(NO_OPENSSL)
+.if exists(${.CURDIR}/../../crypto)  !defined(NOCRYPT)  !defined(NO_OPENSSL)
+DISTRIBUTION=  crypto
 SRCS+= authenc.c
 CFLAGS+=   -DAUTHENTICATION -DENCRYPTION
 DPADD+=${LIBMP} ${LIBCRYPTO} ${LIBCRYPT} ${LIBPAM}
 LDADD+=-lmp -lcrypto -lcrypt ${MINUSLPAM}
-.if !defined(NO_KERBEROS)
+.if exists(${.CURDIR}/../../kerberos5)  !defined(NO_KERBEROS)
 CFLAGS+=   -DKRB5 -DFORWARD -Dnet_write=telnet_net_write
 DPADD+=${LIBKRB5} ${LIBASN1} ${LIBROKEN} ${LIBCOM_ERR}
 LDADD+=-lkrb5 -lasn1 -lroken -lcom_err
Index: usr.bin/telnet/Makefile
===
RCS file: /home/ncvs/src/usr.bin/telnet/Makefile,v
retrieving revision 1.23
diff -u -r1.23 Makefile
--- usr.bin/telnet/Makefile 20 Jul 2003 23:29:46 -  1.23
+++ usr.bin/telnet/Makefile 22 Jul 2003 11:41:02 -
@@ -20,25 +20,26 @@
 DPADD= ${LIBTERMCAP} ${LIBTELNET}
 LDADD= -ltermcap ${LIBTELNET}
 
-.if !defined(RELEASE_CRUNCH)
-CFLAGS+=   -DINET6 -DIPSEC
-DPADD+=${LIBIPSEC}
-LDADD+=-lipsec
-.else
+.if defined(RELEASE_CRUNCH)
 .PATH: ${TELNETDIR}/libtelnet
 SRCS+= genget.c getent.c misc.c
 CFLAGS+=   -DHAS_CGETENT
-.endif
+.else
+CFLAGS+=   -DINET6 -DIPSEC
+DPADD+=${LIBIPSEC}
+LDADD+=-lipsec
 
-.if !defined(NOCRYPT)  !defined(NO_OPENSSL)
+.if exists(${.CURDIR}/../../crypto)  !defined(NOCRYPT)  !defined(NO_OPENSSL)
+DISTRIBUTION=  crypto
 SRCS+= authenc.c 
 CFLAGS+=   -DENCRYPTION -DAUTHENTICATION -DIPSEC
 DPADD+=${LIBMP} ${LIBCRYPTO} ${LIBCRYPT} ${LIBIPSEC} ${LIBPAM}
 LDADD+=-lmp -lcrypto -lcrypt -lipsec ${MINUSLPAM}
-.if !defined(NO_KERBEROS)
+.if exists(${.CURDIR}/../../kerberos5)  !defined(NO_KERBEROS)
 CFLAGS+=   -DKRB5 -DFORWARD -Dnet_write=telnet_net_write
 DPADD+=${LIBKRB5} ${LIBASN1} ${LIBCOM_ERR} ${LIBROKEN}
 LDADD+=-lkrb5 -lasn1 -lcom_err -lroken
+.endif
 .endif
 .endif
 


pgp0.pgp
Description: PGP signature


Re: make release broken [FIX]

2003-07-22 Thread Ruslan Ermilov
On Tue, Jul 22, 2003 at 02:26:34PM -0400, John Baldwin wrote:
 
 On 22-Jul-2003 Ruslan Ermilov wrote:
  Hi!
  
  As many of you probably know, recent telnet commit broke snapshot
  building.  Since I needed a working make release to go on with
  my task on floppy-less make release (for AMD64, etc.), I had to
  just fix it.  Attached is the patch.  It also fixes another issue
  with this telnet commit: it ensures that crypto telnet[d] do not
  end up in the base distribution.
 
 Why not simply enable 'NO_FLOPPIES' on the arch's that don't want
 floppies?
 
Because NO_FLOPPIES doesn't mean like it sounds; it means do not
create floppy _images_, and we want to skip much more than that.
I have a preliminary patch that is currently under the make
release test.  Let me know (or anyone else) if you want to review
it or the final version before I commit it.


Cheers,
-- 
Ruslan Ermilov  Sysadmin and DBA,
[EMAIL PROTECTED]   Sunbay Software Ltd,
[EMAIL PROTECTED]   FreeBSD committer


pgp0.pgp
Description: PGP signature


Re: make release broken [FIX]

2003-07-22 Thread Ruslan Ermilov
On Tue, Jul 22, 2003 at 02:45:52PM -0400, John Baldwin wrote:
 
 On 22-Jul-2003 Ruslan Ermilov wrote:
  On Tue, Jul 22, 2003 at 02:26:34PM -0400, John Baldwin wrote:
  
  On 22-Jul-2003 Ruslan Ermilov wrote:
   Hi!
   
   As many of you probably know, recent telnet commit broke snapshot
   building.  Since I needed a working make release to go on with
   my task on floppy-less make release (for AMD64, etc.), I had to
   just fix it.  Attached is the patch.  It also fixes another issue
   with this telnet commit: it ensures that crypto telnet[d] do not
   end up in the base distribution.
  
  Why not simply enable 'NO_FLOPPIES' on the arch's that don't want
  floppies?
  
  Because NO_FLOPPIES doesn't mean like it sounds; it means do not
  create floppy _images_, and we want to skip much more than that.
  I have a preliminary patch that is currently under the make
  release test.  Let me know (or anyone else) if you want to review
  it or the final version before I commit it.
 
 Are you eliminating the mfsroot?
 
Yes.

 All the bootable CD's use
 that right now, so what more are you doing than eliminating
 the floppy images?
 
Part of the patch for the iso.1 target has this (cut-n-pasted):

@@ -885,10 +873,7 @@
 .if ${TARGET} != pc98
@echo Setting up /boot
@rm -f ${CD_DISC2}/boot/loader.conf
-   @cp ${RD}/mfsroot/mfsroot.gz ${CD_DISC2}/boot/mfsroot.gz
-   @echo 'mfsroot_load=YES'  ${CD_DISC2}/boot/loader.conf
-   @echo 'mfsroot_type=mfs_root'  ${CD_DISC2}/boot/loader.conf
-   @echo 'mfsroot_name=/boot/mfsroot'  ${CD_DISC2}/boot/loader.conf
+   @echo 'init_path=/usr/sbin/sysinstall'  ${CD_DISC2}/boot/loader.conf
@cp -Rp ${CD_DISC2}/boot ${CD_DISC1}
 .endif
 .if !defined(NOPORTS)


Cheers,
-- 
Ruslan Ermilov  Sysadmin and DBA,
[EMAIL PROTECTED]   Sunbay Software Ltd,
[EMAIL PROTECTED]   FreeBSD committer


pgp0.pgp
Description: PGP signature


Re: make release broken [FIX]

2003-07-22 Thread Ruslan Ermilov
On Tue, Jul 22, 2003 at 03:07:01PM -0400, John Baldwin wrote:
 
   Why not simply enable 'NO_FLOPPIES' on the arch's that don't want
   floppies?
   
  Are you eliminating the mfsroot?
  
  Yes.
 
 Ugh.
 
Yes, after looking into this a bit deeper, I must agree that
preserving the mfsroot is much simpler.  And I will probably
do just that.


Cheers,
-- 
Ruslan Ermilov  Sysadmin and DBA,
[EMAIL PROTECTED]   Sunbay Software Ltd,
[EMAIL PROTECTED]   FreeBSD committer


pgp0.pgp
Description: PGP signature


Re: make release of CURRENT on 4.7 broken again ?

2003-07-21 Thread Ruslan Ermilov
On Mon, Jul 21, 2003 at 02:13:45PM +0300, Andrey Elperin wrote:
 On Sun, Jul 20, 2003 at 02:44:23PM +0300, Ruslan Ermilov wrote:
A few days ago I've noticed such messages in CURRENT buildlog (on 4.7
box, building without -jsomething) :
   
   cc -Os -pipe -c chown_stub.c
   ld -dc -r -o chown.lo chown_stub.o /usr/obj//usr/src/usr.sbin/chown/chown.o
   crunchide -k _crunched_chown_stub chown.lo
   echo int _crunched_chroot_stub(int argc, char **argv, char **envp){return 
   main(argc,argv,envp);} chroot_stub.c
   cc -Os -pipe -c chroot_stub.c
   ld -dc -r -o chroot.lo chroot_stub.o /usr/obj//usr/src/usr.sbin/chroot/chroot.o
   crunchide -k _crunched_chroot_stub chroot.lo
   cc -static -o fixit_crunch fixit_crunch.o cat.lo chmod.lo cp.lo dd.lo df.lo 
   echo.lo expr.lo kill.lo ln.lo ls.lo mkdir.lo mv.lo rm.lo rmdir.lo sleep.lo 
   sync.lo bsdlabel.lo clri.lo dmesg.lo fdisk.lo mknod.lo mount.lo mount_cd9660.lo 
   mount_msdosfs.lo reboot.lo restore.lo swapon.lo umount.lo ftp.lo telnet.lo vi.lo 
   chown.lo chroot.lo -ledit -lgeom -lkvm -lm -lncurses
   -lutil
   *** Error code 1

   Stop in /usr/obj/usr/src/release/fixit_crunch.
   *** Error code 1
   
  I have committed a fix for this to src/bin/ed/ a few minutes ago.
 
  Hmm. But I got the same error during last release building (this night).
 
The make -j buildworld is currently broken by the recent changes
to kerberos5/, and the issue is being worked out.  The breakage is
mostly visible in the 4.x doing the build of 5.x case, because
the latter has /usr/include/roken.h and hides the building bug.
At the moment, I'm retesting the snapshot build of 5.x on my 4.x
SMP box without -j.  I will follow up with what I get.


Cheers,
-- 
Ruslan Ermilov  Sysadmin and DBA,
[EMAIL PROTECTED]   Sunbay Software Ltd,
[EMAIL PROTECTED]   FreeBSD committer


pgp0.pgp
Description: PGP signature


Re: make release of CURRENT on 4.7 broken again ?

2003-07-21 Thread Ruslan Ermilov
On Mon, Jul 21, 2003 at 06:08:43PM +0300, Ruslan Ermilov wrote:
 On Mon, Jul 21, 2003 at 02:13:45PM +0300, Andrey Elperin wrote:
  On Sun, Jul 20, 2003 at 02:44:23PM +0300, Ruslan Ermilov wrote:
 A few days ago I've noticed such messages in CURRENT buildlog (on 4.7
 box, building without -jsomething) :

cc -Os -pipe -c chown_stub.c
ld -dc -r -o chown.lo chown_stub.o /usr/obj//usr/src/usr.sbin/chown/chown.o
crunchide -k _crunched_chown_stub chown.lo
echo int _crunched_chroot_stub(int argc, char **argv, char **envp){return 
main(argc,argv,envp);} chroot_stub.c
cc -Os -pipe -c chroot_stub.c
ld -dc -r -o chroot.lo chroot_stub.o /usr/obj//usr/src/usr.sbin/chroot/chroot.o
crunchide -k _crunched_chroot_stub chroot.lo
cc -static -o fixit_crunch fixit_crunch.o cat.lo chmod.lo cp.lo dd.lo df.lo 
echo.lo expr.lo kill.lo ln.lo ls.lo mkdir.lo mv.lo rm.lo rmdir.lo sleep.lo 
sync.lo bsdlabel.lo clri.lo dmesg.lo fdisk.lo mknod.lo mount.lo 
mount_cd9660.lo mount_msdosfs.lo reboot.lo restore.lo swapon.lo umount.lo 
ftp.lo telnet.lo vi.lo chown.lo chroot.lo -ledit -lgeom -lkvm -lm -lncurses
-lutil
*** Error code 1
 
Stop in /usr/obj/usr/src/release/fixit_crunch.
*** Error code 1

   I have committed a fix for this to src/bin/ed/ a few minutes ago.
  
   Hmm. But I got the same error during last release building (this night).
  
 The make -j buildworld is currently broken by the recent changes
 to kerberos5/, and the issue is being worked out.  The breakage is
 mostly visible in the 4.x doing the build of 5.x case, because
 the latter has /usr/include/roken.h and hides the building bug.
 At the moment, I'm retesting the snapshot build of 5.x on my 4.x
 SMP box without -j.  I will follow up with what I get.
 
Yes, I can see the breakage:

: crunchide -k _crunched_vi_stub vi.lo
: echo int _crunched_chown_stub(int argc, char **argv, char **envp){return main(a
: rgc,argv,envp);} chown_stub.c
: cc -Os -pipe -c chown_stub.c
: ld -dc -r -o chown.lo chown_stub.o /usr/obj//usr/src/usr.sbin/chown/chown.o
: crunchide -k _crunched_chown_stub chown.lo
: echo int _crunched_chroot_stub(int argc, char **argv, char **envp){return main(
: argc,argv,envp);} chroot_stub.c
: cc -Os -pipe -c chroot_stub.c
: ld -dc -r -o chroot.lo chroot_stub.o /usr/obj//usr/src/usr.sbin/chroot/chroot.o
: crunchide -k _crunched_chroot_stub chroot.lo
: cc -static -o fixit_crunch fixit_crunch.o cat.lo chmod.lo cp.lo dd.lo df.lo echo
: .lo expr.lo kill.lo ln.lo ls.lo mkdir.lo mv.lo rm.lo rmdir.lo sleep.lo sync.lo b
: sdlabel.lo clri.lo dmesg.lo fdisk.lo mknod.lo mount.lo mount_cd9660.lo mount_msd
: osfs.lo reboot.lo restore.lo swapon.lo umount.lo ftp.lo telnet.lo vi.lo chown.lo
:  chroot.lo -ledit -lgeom -lkvm -lm -lncurses -lutil
: telnet.lo: In function `display':
: telnet.lo(.text+0x122e): undefined reference to `EncryptStatus'
: telnet.lo: In function `status':
: telnet.lo(.text+0x1e85): undefined reference to `encrypt_display'
: ...
: 
: telnet.lo(.data+0xaa0): undefined reference to `EncryptStatus'
: *** Error code 1
: 
: Stop in /usr/obj/usr/src/release/fixit_crunch.
: *** Error code 1
: 
: Stop in /usr/src/release.

I believe Mark has committed a fix for this today (commit log
is attached).


Cheers,
-- 
Ruslan Ermilov  Sysadmin and DBA,
[EMAIL PROTECTED]   Sunbay Software Ltd,
[EMAIL PROTECTED]   FreeBSD committer
---BeginMessage---
markm   2003/07/20 16:29:46 PDT

  FreeBSD src repository

  Modified files:
lib/libtelnetMakefile 
libexec/telnetd  Makefile 
usr.bin/telnet   Makefile 
  Log:
  Test correct macro for without crypto option(s).
  
  Revision  ChangesPath
  1.16  +1 -1  src/lib/libtelnet/Makefile
  1.21  +1 -1  src/libexec/telnetd/Makefile
  1.23  +1 -1  src/usr.bin/telnet/Makefile
---End Message---


pgp0.pgp
Description: PGP signature


Re: i386 'make release' broken

2003-07-20 Thread Ruslan Ermilov
On Sun, Jul 20, 2003 at 02:18:42AM -0600, Scott Long wrote:
 Just got the following from a 'make release BUILDNAME=5.1-CURRENT 
 CHROOTDIR=/usr/release CVSROOT=/usr/ncvs NOPORTS= NODOC= .  My
 world was up to date to within a day.  The full log is at
 http://people.freebsd.org/~scottl/current-release-i386.log.gz.  Note
 that while this is an SMP machine, -j was not used.  Also, this
 problem did not stop the previous 'buildworld' from completing.
 I haven't tried to build a release in a few weeks, so I can't quickly
 say when the breakage started.
 
 
 
 cc -O -pipe -mcpu=pentiumpro-Wsystem-headers -Werror -Wall 
 -Wno-format-y2k -W -Wstrict-prototypes -Wmissing-prototypes 
 -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch 
 -Wshadow -Wcast-align -Wbad-function-cast -Wchar-subscripts -Winline 
 -Wnested-externs -Wredundant-decls  -c /usr/src/bin/ed/re.c
 /usr/src/bin/ed/re.c: In function `get_compiled_pattern':
 /usr/src/bin/ed/re.c:44: warning: declaration of `exp' shadows a global 
 declaration
 built-in:0: warning: shadowed declaration is here
 *** Error code 1
 
Marius Strobl has submitted a fix for this (privately to me
and Alexander) a week ago.  I have just committed it.


Cheers,
-- 
Ruslan Ermilov  Sysadmin and DBA,
[EMAIL PROTECTED]   Sunbay Software Ltd,
[EMAIL PROTECTED]   FreeBSD committer


pgp0.pgp
Description: PGP signature


Re: make release of CURRENT on 4.7 broken again ?

2003-07-20 Thread Ruslan Ermilov
On Sun, Jul 20, 2003 at 02:04:28PM +0300, Andrey Elperin wrote:
 
  Hi,
 
  A few days ago I've noticed such messages in CURRENT buildlog (on 4.7
  box, building without -jsomething) :
 
 cc -Os -pipe -c chown_stub.c
 ld -dc -r -o chown.lo chown_stub.o /usr/obj//usr/src/usr.sbin/chown/chown.o
 crunchide -k _crunched_chown_stub chown.lo
 echo int _crunched_chroot_stub(int argc, char **argv, char **envp){return 
 main(argc,argv,envp);} chroot_stub.c
 cc -Os -pipe -c chroot_stub.c
 ld -dc -r -o chroot.lo chroot_stub.o /usr/obj//usr/src/usr.sbin/chroot/chroot.o
 crunchide -k _crunched_chroot_stub chroot.lo
 cc -static -o fixit_crunch fixit_crunch.o cat.lo chmod.lo cp.lo dd.lo df.lo echo.lo 
 expr.lo kill.lo ln.lo ls.lo mkdir.lo mv.lo rm.lo rmdir.lo sleep.lo sync.lo 
 bsdlabel.lo clri.lo dmesg.lo fdisk.lo mknod.lo mount.lo mount_cd9660.lo 
 mount_msdosfs.lo reboot.lo restore.lo swapon.lo umount.lo ftp.lo telnet.lo vi.lo 
 chown.lo chroot.lo -ledit -lgeom -lkvm -lm -lncurses
 -lutil
 *** Error code 1
  
 Stop in /usr/obj/usr/src/release/fixit_crunch.
 *** Error code 1
 
I have committed a fix for this to src/bin/ed/ a few minutes ago.


Cheers,
-- 
Ruslan Ermilov  Sysadmin and DBA,
[EMAIL PROTECTED]   Sunbay Software Ltd,
[EMAIL PROTECTED]   FreeBSD committer


pgp0.pgp
Description: PGP signature


Re: [-CURRENT tinderbox] failure on sparc64/sparc64

2003-07-20 Thread Ruslan Ermilov
On Sun, Jul 20, 2003 at 11:53:43AM +, Tinderbox wrote:
  stage 4: building everything..
 [...]
 === bin/ed
 cc -O -pipe  -DDES-Wsystem-headers -Werror -Wall -Wno-format-y2k -W 
 -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual 
 -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wbad-function-cast -Wchar-subscripts 
 -Winline -Wnested-externs -Wredundant-decls  -c 
 /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/bin/ed/buf.c
 cc -O -pipe  -DDES-Wsystem-headers -Werror -Wall -Wno-format-y2k -W 
 -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual 
 -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wbad-function-cast -Wchar-subscripts 
 -Winline -Wnested-externs -Wredundant-decls  -c 
 /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/bin/ed/cbc.c
 In file included from 
 /home/des/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/i386/usr/include/openssl/ui_compat.h:63,
  from 
 /home/des/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/i386/usr/include/openssl/des_old.h:439,
  from 
 /home/des/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/i386/usr/include/openssl/des.h:101,
  from 
 /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/bin/ed/cbc.c:46:
 /home/des/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/i386/usr/include/openssl/ui.h:220:
  warning: function declaration isn't a prototype
 *** Error code 1
 
 Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/bin/ed.
 *** Error code 1
 
Fixed in src/bin/ed/Makefile,v 1.28.


Cheers,
-- 
Ruslan Ermilov  Sysadmin and DBA,
[EMAIL PROTECTED]   Sunbay Software Ltd,
[EMAIL PROTECTED]   FreeBSD committer


pgp0.pgp
Description: PGP signature


Re: [current] hostap+wi

2003-07-06 Thread Ruslan Ermilov
On Sun, Jul 06, 2003 at 09:40:38AM +0900, M. Warner Losh wrote:
 In message: [EMAIL PROTECTED]
 Ruslan Ermilov [EMAIL PROTECTED] writes:
 : On Sat, Jul 05, 2003 at 04:48:09PM -0400, David Gilbert wrote:
 : [...]
 :  The hostap machine is 4.8-STABLE and the client is 5.1-RELEASE.
 :  
 : One nice thing about the hostap is that bridge(4) works with wi(4)
 : that is in hostap mode.  Does anybody know if only Intersil cards
 : have the hostap mode, or some Prism's also do?
 
 Intersil and Prism are the same thing.  Prism 2, 2.5 and 3 cards have
 Intersil firmware.  There are some cards based on prism chipsets that
 have Symbol firmware, but those are rare.  The wavelan/lucent/orinoco
 firmware doesn't support a hostap mode, but there are add-ins that
 give ap functionality.
 
Uh sorry, it was very late in the night here; of course I meant Lucent
chipsets when asking if they also support host-ap mode.  What are
these add-ins you're talking about?

I'm mostly interested in the bridge(4) functionality.

As I understand, to do briding, the card should be able to send
frames with arbitrary MAC addresses, and when not in host-ap mode,
Lucent based chipsets do not allow this (i.e., you see with
tcpdump(1) that packets is written to wi0 interface, but the other
end doesn't receive the frame).  What surprises me here, is that
these same cards appear to work (by forwarding arbitrary Ethernet
frames) when inserted into Lucent-based APs.  Does anyone have a
valid explanation to this?  Is this an artificial limitation on
these cards to limit their commercial use, or am I missing an
obvious?


Cheers,
-- 
Ruslan Ermilov  Sysadmin and DBA,
[EMAIL PROTECTED]   Sunbay Software Ltd,
[EMAIL PROTECTED]   FreeBSD committer


pgp0.pgp
Description: PGP signature


Re: [current] hostap+wi

2003-07-05 Thread Ruslan Ermilov
On Sat, Jul 05, 2003 at 04:48:09PM -0400, David Gilbert wrote:
[...]
 The hostap machine is 4.8-STABLE and the client is 5.1-RELEASE.
 
One nice thing about the hostap is that bridge(4) works with wi(4)
that is in hostap mode.  Does anybody know if only Intersil cards
have the hostap mode, or some Prism's also do?


Cheers,
-- 
Ruslan Ermilov  Sysadmin and DBA,
[EMAIL PROTECTED]   Sunbay Software Ltd,
[EMAIL PROTECTED]   FreeBSD committer


pgp0.pgp
Description: PGP signature


Re: who am i

2003-07-03 Thread Ruslan Ermilov
On Fri, Jul 04, 2003 at 12:46:10AM +0200, Richard Arends wrote:
 Hello,
 
 Please take a look at this:
 
 =
 [snowlap] ~$ who am i
 richard  ttyp5Jul  4 00:34 (:0.0)
 [snowlap] ~$ su -
 Password:
 Last login: Fri Jul  4 00:31:17 on ttyp5
 snowlap# who am i
 root ttyp5Jul  4 00:34
 snowlap# exit
 logout
 [snowlap] ~$ who am i
 root ttyp5Jul  4 00:34
 =
 
 Of course the latest 'who am i' should return 'richard' and not(!) 'root'
 
Yes, this sucks.  DES, could you please fix it?


Cheers,
-- 
Ruslan Ermilov  Sysadmin and DBA,
[EMAIL PROTECTED]   Sunbay Software Ltd,
[EMAIL PROTECTED]   FreeBSD committer


pgp0.pgp
Description: PGP signature


Re: who am i

2003-07-03 Thread Ruslan Ermilov
On Fri, Jul 04, 2003 at 01:58:13AM +0300, Ruslan Ermilov wrote:
 On Fri, Jul 04, 2003 at 12:46:10AM +0200, Richard Arends wrote:
  Hello,
  
  Please take a look at this:
  
  =
  [snowlap] ~$ who am i
  richard  ttyp5Jul  4 00:34 (:0.0)
  [snowlap] ~$ su -
  Password:
  Last login: Fri Jul  4 00:31:17 on ttyp5
  snowlap# who am i
  root ttyp5Jul  4 00:34
  snowlap# exit
  logout
  [snowlap] ~$ who am i
  root ttyp5Jul  4 00:34
  =
  
  Of course the latest 'who am i' should return 'richard' and not(!) 'root'
  
 Yes, this sucks.  DES, could you please fix it?
 
Doh, forgot to mention: the following patch fixes it for me.

%%%
Index: su
===
RCS file: /home/ncvs/src/etc/pam.d/su,v
retrieving revision 1.15
diff -u -r1.15 su
--- su  14 Jun 2003 12:35:05 -  1.15
+++ su  3 Jul 2003 22:58:37 -
@@ -14,4 +14,4 @@
 accountinclude system
 
 # session
-sessioninclude system
+#session   include system
%%%


Cheers,
-- 
Ruslan Ermilov  Sysadmin and DBA,
[EMAIL PROTECTED]   Sunbay Software Ltd,
[EMAIL PROTECTED]   FreeBSD committer


pgp0.pgp
Description: PGP signature


Re: who am i

2003-07-03 Thread Ruslan Ermilov
On Fri, Jul 04, 2003 at 02:02:09AM +0300, Ruslan Ermilov wrote:
[...]
 Doh, forgot to mention: the following patch fixes it for me.
 
A better version:

%%%
Index: su
===
RCS file: /home/ncvs/src/etc/pam.d/su,v
retrieving revision 1.15
diff -u -r1.15 su
--- su  14 Jun 2003 12:35:05 -  1.15
+++ su  3 Jul 2003 23:03:32 -
@@ -14,4 +14,4 @@
 accountinclude system
 
 # session
-sessioninclude system
+sessionrequiredpam_permit.so
%%%


Cheers,
-- 
Ruslan Ermilov  Sysadmin and DBA,
[EMAIL PROTECTED]   Sunbay Software Ltd,
[EMAIL PROTECTED]   FreeBSD committer


pgp0.pgp
Description: PGP signature


Re: [-CURRENT tinderbox] failure on ia64/ia64

2003-07-02 Thread Ruslan Ermilov
On Wed, Jul 02, 2003 at 08:51:40AM +0200, Dag-Erling Sm?rgrav wrote:
 Ruslan Ermilov [EMAIL PROTECTED] writes:
  mkinit is the bin/sh's build-tool, and should have been built
  for the native architecture, i386.  The above means that mkinit
  was rebuilt for ia64, and the resulting binary was then ran on
  i386.  If you don't have other explanations to the above, please
  check that the date and time are set on the building box
  correctly, and that source files do not have modification time
  in the future.
 
 I don't think that's it.  I'm getting the same error in the powerpc
 build (which runs on a different machine).  I've verified that both
 machines have a reasonably correct clock.  Besides, if the clock was a
 problem, it should also affect the other builds, but out of the six
 builds that run on cueball, only ia64 and sparc64 fail.
 
Thanks, we have another, more correct explanation now.  The rescue/
duplicates some of the building, so its Makefile also needs a sort
of the build-tools target to survive in the cross-platform build
environment.


Cheers,
-- 
Ruslan Ermilov  Sysadmin and DBA,
[EMAIL PROTECTED]   Sunbay Software Ltd,
[EMAIL PROTECTED]   FreeBSD committer


pgp0.pgp
Description: PGP signature


  1   2   3   4   5   6   7   >