Re: nullfs in 4.10

2004-06-22 Thread Bjoern Koenig
Hello,

first of all:

THIS FILESYSTEM TYPE IS NOT YET FULLY SUPPORTED
(READ: IT DOESN'T WORK) AND USING IT MAY, IN FACT,
DESTROY DATA ON YOUR SYSTEM. USE AT YOUR OWN RISK.
BEWARE OF DOG. SLIPPERY WHEN WET.

My experience:

I had much less problems with unionfs -b, even with FreeBSD 4.10, to mount
for example /usr/ports into a jail temporarily. But for everything else you
should never use it.

Bjoern

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


Re: Trouble compiling lang/php4 (4.3.7)

2004-06-22 Thread Roger Raymond

Sayid Munawar wrote:
Yes... i received the same error and i posted here too with the subject:
libtool problem or SMP problem or port problem or what?
I have tried to cvsup my ports collection yesterday, but the problem
persist. I think one of the php's feature (WITH_ ) is leading to this
problem. but i don't know stil. PHP compiled OK with default WITH_ options
I saw that post after I had written mine.  The responses were not all 
that helpful IMO.  I too was able to compile php4-cli with the 'default' 
set of options, so i guess it's now a guessing game and I'll have to 
turn off each option i have on one at a time and try to build the port 
until I get it to compile successfully.

Will post my findings should I stumble upon them :)
--Roger
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


Re: Trouble compiling lang/php4 (4.3.7) (solved - maybe)

2004-06-22 Thread Roger Raymond
Well...
It appears that the mnoGoSearch option for the php-cli is not working 
correctly.  I recompiled the mnogosearch port then tried to compile php4 
WITH_MNOGOSEARCH=ON and it resulted in the libtool link error described 
in previous posts.

the lang/php4 port appears to compile successfully with all the other 
options.

Would this be an issue with php or the mnogosearch port?
Here's my php4_options file:
WITH_BCMATH=ON
WITH_BZIP2=ON
WITH_CALENDAR=ON
WITH_CDB=ON
WITH_CRACK=ON
WITH_CTYPE=ON
WITH_CURL=ON
WITH_DB4=OFF
WITH_DBASE=OFF
WITH_DBX=OFF
WITH_DIO=OFF
WITH_DOMXML=ON
WITH_DOMXSLT=ON
WITH_EXIF=OFF
WITH_FILEPRO=OFF
WITH_FRIBIDI=OFF
WITH_FTP=ON
WITH_GD=ON
WITH_GDBM=ON
WITH_GETTEXT=ON
WITH_GMP=OFF
WITH_HYPERWAVE=OFF
WITH_ICONV=ON
WITH_IMAP=ON
WITH_INIFILE=ON
WITH_INTERBASE=OFF
WITH_MBSTRING=ON
WITH_MCAL=ON
WITH_MCVE=ON
WITH_MCRYPT=ON
WITH_MHASH=ON
WITH_MIME=ON
WITH_MING=ON
WITH_MNOGOSEARCH=OFF
WITH_MSSQL=OFF
WITH_MYSQL=ON
WITH_NCURSES=ON
WITH_OPENLDAP=ON
WITH_OPENSSL=ON
WITH_ORACLE=OFF
WITH_OVERLOAD=ON
WITH_PCNTL=ON
WITH_PCRE=ON
WITH_PDFLIB=ON
WITH_POSIX=ON
WITH_POSTGRESQL=OFF
WITH_PSPELL=ON
WITH_READLINE=ON
WITH_RECODE=OFF
WITH_SESSION=ON
WITH_SHMOP=OFF
WITH_SNMP=ON
WITH_SOCKETS=ON
WITH_SYBASEDB=OFF
WITH_SYBASECT=OFF
WITH_SYSVMSG=ON
WITH_SYSVSEM=ON
WITH_SYSVSHM=ON
WITH_TOKENIZER=ON
WITH_UNIXODBC=ON
WITH_WDDX=ON
WITH_XML=ON
WITH_XMLRPC=ON
WITH_XSLT=ON
WITH_YAZ=OFF
WITH_YP=ON
WITH_ZIP=ON
WITH_ZLIB=ON
--Roger
Roger Raymond wrote:

Sayid Munawar wrote:
Yes... i received the same error and i posted here too with the subject:
libtool problem or SMP problem or port problem or what?
I have tried to cvsup my ports collection yesterday, but the problem
persist. I think one of the php's feature (WITH_ ) is leading to this
problem. but i don't know stil. PHP compiled OK with default WITH_ 
options

I saw that post after I had written mine.  The responses were not all 
that helpful IMO.  I too was able to compile php4-cli with the 'default' 
set of options, so i guess it's now a guessing game and I'll have to 
turn off each option i have on one at a time and try to build the port 
until I get it to compile successfully.

Will post my findings should I stumble upon them :)
--Roger
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


Re: libtool problem or SMP problem or port problem or what?

2004-06-22 Thread Chris Pepper
At 1:32 PM -0700 2004/06/21, Kris Kennaway wrote:
On Mon, Jun 21, 2004 at 10:05:29AM -0400, Chris Pepper wrote:
 At 12:01 AM -0700 2004/06/21, Kris Kennaway wrote:
 > > [EMAIL PROTECTED] XFree86-4-libraries]# make clean USE_LIBTOOL_VER=15
 >
 >USE_* are not to be specified by the user, they're only for use within
 >port makefiles.  You discovered the consequence, I'll leave the reason
 >for you to figure out as an instructive exercise about the ports
 >collection :)
Hmm. This raises the question, then, of why a couple of my
 ports have recently told me to set something like USE_BASE_OPENSSL or
 USE_PORT_OPENSSL to install (as I recall, a vulnerability check was
 failing). This worked, although I had to remove an OpenSSL dependency
 in pkgdb -F later.
USE_* variables are not to be specified by the user.  User control
variables are WITH_* and WITHOUT_* (WITH_OPENSSL_(BASE|PORT) are
probably what you were referring to here).
Kris,
You are right. Thanks for the clarification.
Chris
--
Chris Pepper:   
Rockefeller University: 
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


Re: nullfs in 4.10

2004-06-22 Thread Marc G. Fournier
On Tue, 22 Jun 2004, Bjoern Koenig wrote:
Hello,
first of all:
THIS FILESYSTEM TYPE IS NOT YET FULLY SUPPORTED
(READ: IT DOESN'T WORK) AND USING IT MAY, IN FACT,
DESTROY DATA ON YOUR SYSTEM. USE AT YOUR OWN RISK.
BEWARE OF DOG. SLIPPERY WHEN WET.
My experience:
I had much less problems with unionfs -b, even with FreeBSD 4.10, to mount
for example /usr/ports into a jail temporarily. But for everything else you
should never use it.
BS, and then some ...
I have 4 servers in place right now, each running a minimum of 30 jail'd 
environments (my most full is running 67 right now) where usr is mounted 
using unionfs -b from a central template ... the *only* issues that I have 
is with fsck's on a long uptime takes a bit of time ...

The only caveat I'll make *against* unionfs at this time, and something 
that I'd like to see fixed eventually ... do not try and mount / and 
expect a jail to run ... there is a FIFO(?) created in the /var directory 
that will cause the server to panic ... but, from what I can tell, that is 
the only really big, outstanding bug that will hit you.  Between David 
Schultz and Tor, most of the rest of the "easy to trigger" bugs have been 
cleaned up.

Note: when I say "easy to trigger" ... as I said above, my servers run 
between 30 and 70 jail'd environments using unionfs, each jail'd 
environment being a totally different configuration, running within them 
anything from jabber, to aolserver, to jakarta-tomcat, etc ... the longest 
I've had a server run before doing an OS upgrade on it was ~120days or so, 
without a hitch ...




Marc G. Fournier   Hub.Org Networking Services (http://www.hub.org)
Email: [EMAIL PROTECTED]   Yahoo!: yscrappy  ICQ: 7615664
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


Re: Trouble compiling lang/php4 (4.3.7) (solved - maybe)

2004-06-22 Thread Sayid Munawar



> Well...
> 
> It appears that the mnoGoSearch option for the php-cli is not working 
> correctly.  I recompiled the mnogosearch port then tried to compile php4 
> WITH_MNOGOSEARCH=ON and it resulted in the libtool link error described 
> in previous posts.
> 
> the lang/php4 port appears to compile successfully with all the other 
> options.
> 


Yeah.. it worked. thanks a lot Roger

---
Sayid Munawar
IDwebhost.
http://www.idwebhost.com
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


Re: Unable to build world

2004-06-22 Thread Kent Stewart
On Wednesday 16 June 2004 09:55 pm, Roger Merritt wrote:
> I hadn't updated my world for quite a while, so I ran cvsup to make
> sure I had the latest modifications to the code and then tried to run
> "make buildworld". Failed. Tried again, failed. Went to the file
> where the build failed, didn't see any problem. Deleted the whole
> /usr/src directory and
>

Since it is trying to use a file from /usr/obj, have your rm'ed it.

> ran cvsup to retrieve the whole body of code again. Still failed. I 
get:
> >===> games/robots
> >cc -O -pipe -march=pentium  -DMAX_PER_UID=5-c
> >/usr/home/src/games/robots/extern.c
> >cc -O -pipe -march=pentium  -DMAX_PER_UID=5-c
> >/usr/home/src/games/robots/init_field.c
> >cc -O -pipe -march=pentium  -DMAX_PER_UID=5-c
> >/usr/home/src/games/robots/main.c
> >In file included from /usr/home/src/games/robots/robots.h:36,
> >  from /usr/home/src/games/robots/main.c:48:
> >/usr/obj/usr/home/src/i386/usr/include/curses.h:1281: undefined or
> > invalid # directive
> >*** Error code 1
> >
> >Stop in /usr/home/src/games/robots.
> >*** Error code 1
> >
> >Stop in /usr/home/src/games.
> >*** Error code 1
> >
> >Stop in /usr/home/src.
> >*** Error code 1
> >
> >Stop in /usr/home/src.
> >*** Error code 1
> >
> >Stop in /usr/home/src.
>
> Incidentally, for space reasons I had to put the source tree in the
> "home" directory (a separate slice on my hard drive) with a syslink
> as /usr/src, but I've built world many times (at least several times)
> since I did that and never had a problem before.

The only time I have run into a problem with this is if I try to NFS 
mount /usr/src or /usr/obj. The build process remembers the real path 
and used it. It was not the same on the machine doing the mounting. 
When I setup a system to be NFS mountable, I put /usr/src and /usr/obj 
on their own partitions. Then, build process uses the same path on the 
machine doing the mounting.

Kent

>
> uname -v gives me: FreeBSD 4.8-STABLE #0: Tue May  6 18:29:38 ICT
> 2003, my last cvsup completed successfully last night at about 2230
> hours local time.
>
> Is it possible I need to upgrade "make" or something like that? I
> recall that was a problem once before. But what's with this weird
> path /usr/obj/usr/home/src/i386/usr/include/curses.h?? vi opens the
> file, and line 1281 is "#define BUTTON_SHIFT   
> 0002L", which doesn't look like an "undefined or invalid #
> directive" to me.

-- 
Kent Stewart
Richland, WA

http://users.owt.com/kstewart/index.html
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


Re: nullfs in 4.10

2004-06-22 Thread Allan Fields
On Tue, Jun 22, 2004 at 03:09:18PM +0200, Bjoern Koenig wrote:
> Hello,
> 
> first of all:
> 
> THIS FILESYSTEM TYPE IS NOT YET FULLY SUPPORTED
> (READ: IT DOESN'T WORK) AND USING IT MAY, IN FACT,
> DESTROY DATA ON YOUR SYSTEM. USE AT YOUR OWN RISK.
> BEWARE OF DOG. SLIPPERY WHEN WET.

Right, but that's only the short answer: "it's broken".  The more
in-depth answer is that while users may want to use them in production
now: null and other pseudo file systems may still require some work
for prime-time use and it's a valid concern for the platform.  Those
that raise the point aren't being unreasonable, I'm of the opinion
it should be fixed at some point soon.

Having said that: As to whether it belongs in -stable now: yes
people are warned not to use it, why not just remove it?  I think
one argument to keep it in is for completeness: nullfs or similar
belongs in the base (in BSD systems) and taking it out seems like
the wrong answer from a technical standpoint.  Also placing code
in the corner won't fix it: even if it is made to work under 5,
many want to use it in 4 still.  ;)

> My experience:
> 
> I had much less problems with unionfs -b, even with FreeBSD 4.10, to mount
> for example /usr/ports into a jail temporarily. But for everything else you
> should never use it.

What are some other approaches than overlays for jailed environments?
Use NFS instead?

> Bjoern

-- 
 Allan Fields, AFRSL - http://afields.ca
 2D4F 6806 D307 0889 6125  C31D F745 0D72 39B4 5541


pgpov4bvwefva.pgp
Description: PGP signature