Re: portupgrade and PHP
:: > How can I continually compile PHP with the same :: > options as the last time? :: :: Edit /usr/ports/lang/php4/Makefile and change the line :: PHP4_OPTIONS?= according to your needs. Except that the next time you upgrade your ports tree, your changes will be overwritten. Check out the /usr/local/etc/pkgtools.conf file. This is how you can use your own make(1) options using portupgrade consistently. The options you can use for each port can be found in its respective Makefile. Cheers - Erick ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: portupgrade and PHP
Hi. > How can I continually compile PHP with the same > options as the last time? > Edit /usr/ports/lang/php4/Makefile and change the line PHP4_OPTIONS?= according to your needs. regards Claus Yahoo! Mail (http://dk.mail.yahoo.com) - Gratis: 6 MB lagerplads, spamfilter og virusscan ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 4-STABLE b0rked in share/locale/zh_CN.GBK
hi, mkdir /usr/share/locale/zh_CN.GBK/ will help regards Stfean Gregory Sutter wrote: Murray, Your commits earlier this evening to zh_CN.GB18030 fixed that -STABLE breakage, but zh_CN.GBK appears still to be missing, which causes 'make installworld' to fail. Can you please fix this as well? install -m 644 -o root -g wheel uk_UA.KOI8-U.out /usr/share/locale/uk_UA.KOI8-U/LC_CTYPE install -m 644 -o root -g wheel zh_CN.eucCN.out /usr/share/locale/zh_CN.eucCN/LC_CTYPE install -m 644 -o root -g wheel zh_CN.GB18030.out /usr/share/locale/zh_CN.GB18030/LC_CTYPE install -m 644 -o root -g wheel zh_CN.GBK.out /usr/share/locale/zh_CN.GBK/LC_CTYPE install: /usr/share/locale/zh_CN.GBK/LC_CTYPE: No such file or directory *** Error code 71 Stop in /usr/src/share/mklocale. *** Error code 1 Greg ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: (long) high traffic syslog server.
On Tue, Nov 04, 2003 at 08:56:57AM +, Bob Bishop wrote: > Hi, > > At 00:05 4/11/03, John wrote: > >[...] > >btw its a dual 400 > >[etc] > > Just for clarification: it seems from the data you posted that you aren't > running an SMP kernel, right? If CPU is your problem, that might make a > difference :-) > > > -- > Bob Bishop+44 (0)118 977 4017 > [EMAIL PROTECTED] fax +44 (0)118 989 4254 sorry, i disabled SMP kernel to see if it was a SMP kernel issue. Which it doesn't seem like it was as it acts the same UNI or SMP kernel. Ilya Varlashkin <[EMAIL PROTECTED]> 22.0%Sys 8.3%Intr 13.6%User 0.0%Nice 56.1%Idl <- That is at a high point. i'll also see if i can dig up a fxp nic and link0 it. on the doesn't matter how large buffers comment. Part of the question is Which buffers should i be looking at? ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: portupgrade and PHP
On 03 Nov 2003, Rick Updegrove wrote: > When I run portupgrade -ra and PHP needs upgrading I am faced with > having to select all the options I want PHP compiled with (again). I > hate this. > > How can I continually compile PHP with the same options as the last time? If you haven't cvsup'ped your ports in awhile to the latest available, I highly recommend doing so. Check out /usr/ports/lang/php4/Makefile and you'll see different ways to deal with this problem. My Makefile is v 1.32 from 2003/10/13 05:59:45 and has all the scoop on how to avoid this problem. -- Mark Nippere-contacts: Computing and Information Services [EMAIL PROTECTED] Texas A&M Universityhttp://ops.tamu.edu/nipsy/ College Station, TX 77843-3142 AIM/Yahoo: texasnipsy ICQ: 66971617 (979)575-3193 MSN: [EMAIL PROTECTED] -BEGIN GEEK CODE BLOCK- GG/IT d- s++:+ a- C++$ UBL+++$ P--->+++ L+++$ E--- W++ N+ o K++ w(---) O++ M V(--) PS+++(+) PE(--) Y+ PGP++(+) t 5 X R tv b+++ DI+(++) D+ G e h r++ y+(**) --END GEEK CODE BLOCK-- ---begin random quote of the moment--- "We are not enemies, but friends. We must not be enemies. Though passion may have strained, it must not break our bonds of affection. The mystic cords of memory will swell when again touched as surely they will be by the better angels of our nature." -- modified quote of Abraham Lincoln from his first inaugural address, 04 March 1861; taken from "American History X" end random quote of the moment ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
portupgrade and PHP
Hello, When I run portupgrade -ra and PHP needs upgrading I am faced with having to select all the options I want PHP compiled with (again). I hate this. How can I continually compile PHP with the same options as the last time? Thanks! Rick ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Serious (ha-ha) bug in 4.9-RELEASE
Daniel Eischen <[EMAIL PROTECTED]> wrote: > > Very critical indeed... And with such a huge userbase that it took six > > months before anybody noticed this problem. :-) > > No, we noticed it here at work where we use Sun Solaris > boxes as our development systems. I didn't know what the > problem was until now. It is very very annoying to have > man, more, less, etc, screw up your display when using > them while remotely logged in to our FreeBSD boxes. Oh, so THAT's the cause. I've been seeing this for quite a while, but haven't been sufficiently annoyed to track it down. I just assumed that either termcap or xterm was broken. I've just been using "TERM=vt100" as a kludgearound. > The > symptoms are that everything gets highlighted and underlined > and it stays that way forcing you to close the xterm and > open another. An easier fix is to run vi and exit, which resets the highlighting. -- Darryl Okahata [EMAIL PROTECTED] DISCLAIMER: this message is the author's personal opinion and does not constitute the support, opinion, or policy of Agilent Technologies, or of the little green men that have been following him all day. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Serious (ha-ha) bug in 4.9-RELEASE
On Tue, 4 Nov 2003, Erik Trulsson wrote: > On Tue, Nov 04, 2003 at 07:49:36AM -0800, Michael Sierchio wrote: > > Brian T. Schellenberger wrote: > > > > > > >OTOH, the fact that nobody seems to have noticed until after 4.9 was > > >released is a pretty strong argument that not very many people > > >care--unless of course :-) > > > > Ag! It was a stupid fscking idea to make > > arbitrary changes to something that hadn't really changed > > in a decade (or more). > > I don't think the changes were exactly arbitrary. > >From the comments in termcap.src I would say that the new version seems > to be based (quite closely) on the termcap desctriptions supplied by > the XFree86 people. From browsing their CVS repository it seems they > dropped the "bs" capability from their xterm entry some 7 years ago. > It has also been in 4-STABLE for about 6 months (and in -CURRENT for > about 7 months before that), so it is not exactly as if it was a new > and untested change that made it into 4.9-RELEASE. > > Many people wanted support for various new features in xterm (like > support for color in a standard xterm.) > To get those, the termcap entry needed to be updated. > The easiest (and least bug-prone) way of doing that seems to be to > import the termcap entries provided by XFree86 (who, after all, should > know what xterm looks like.) > > > > > And I don't track -STABLE on all machines, so this change > > didn't appear in RELENG_4_8. > > The changes were made after 4.8-RELEASE, so they wouldn't have appeared > in RELENG_4_8. > > > > > Especially since it affects such a *critical* application ;-) > > Very critical indeed... And with such a huge userbase that it took six > months before anybody noticed this problem. :-) No, we noticed it here at work where we use Sun Solaris boxes as our development systems. I didn't know what the problem was until now. It is very very annoying to have man, more, less, etc, screw up your display when using them while remotely logged in to our FreeBSD boxes. The symptoms are that everything gets highlighted and underlined and it stays that way forcing you to close the xterm and open another. If we set TERM to xterm-r6 or xterm-r5, then everything seems to work OK. I hate how xterm defaults to color-capable. If it were only up to me, it wouldn't. -- Dan Eischen ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Serious (ha-ha) bug in 4.9-RELEASE
On Tue, Nov 04, 2003 at 07:49:36AM -0800, Michael Sierchio wrote: > Brian T. Schellenberger wrote: > > > >OTOH, the fact that nobody seems to have noticed until after 4.9 was > >released is a pretty strong argument that not very many people > >care--unless of course :-) > > Ag! It was a stupid fscking idea to make > arbitrary changes to something that hadn't really changed > in a decade (or more). I don't think the changes were exactly arbitrary. >From the comments in termcap.src I would say that the new version seems to be based (quite closely) on the termcap desctriptions supplied by the XFree86 people. From browsing their CVS repository it seems they dropped the "bs" capability from their xterm entry some 7 years ago. It has also been in 4-STABLE for about 6 months (and in -CURRENT for about 7 months before that), so it is not exactly as if it was a new and untested change that made it into 4.9-RELEASE. Many people wanted support for various new features in xterm (like support for color in a standard xterm.) To get those, the termcap entry needed to be updated. The easiest (and least bug-prone) way of doing that seems to be to import the termcap entries provided by XFree86 (who, after all, should know what xterm looks like.) > > And I don't track -STABLE on all machines, so this change > didn't appear in RELENG_4_8. The changes were made after 4.8-RELEASE, so they wouldn't have appeared in RELENG_4_8. > > Especially since it affects such a *critical* application ;-) Very critical indeed... And with such a huge userbase that it took six months before anybody noticed this problem. :-) -- Erik Trulsson [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Serious bug in 4.9-RELEASE
On Tue, Nov 04, 2003 at 07:44:13AM -0800, David Raistrick wrote: > > > I take that back. I can reproduce it, but only in xterm (I normally > > don't use X much, so I only tried it in a normal text console.) > > For what it may be worth, I can reproduce this on my freshly cvsuped > 4.9-R server, as well as my 4.8-STABLE from July 1. > > Also only in an xterm (untested with cons25). Yes, as has been noted elsewhere in the thread, the problem occurs after changes were made in the termcap description of xterm. Those changes were made to RELENG_4 on 2003-04-29 (which was after 4.8-RELEASE) so it should be reproducable on all versions of 4-STABLE after that date. (And, as also has been noted, it is arguable that there is not a bug in termcap, but rather that the changes uncovered a bug in /usr/games/hack. The bug being that hack(6) relies on long-obsolete termcap capabilities, which it shouldn't do.) -- Erik Trulsson [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Serious (ha-ha) bug in 4.9-RELEASE
Brian T. Schellenberger wrote: OTOH, the fact that nobody seems to have noticed until after 4.9 was released is a pretty strong argument that not very many people care--unless of course :-) Ag! It was a stupid fscking idea to make arbitrary changes to something that hadn't really changed in a decade (or more). And I don't track -STABLE on all machines, so this change didn't appear in RELENG_4_8. Especially since it affects such a *critical* application ;-) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Serious bug in 4.9-RELEASE
> I take that back. I can reproduce it, but only in xterm (I normally > don't use X much, so I only tried it in a normal text console.) For what it may be worth, I can reproduce this on my freshly cvsuped 4.9-R server, as well as my 4.8-STABLE from July 1. Also only in an xterm (untested with cons25). ...david --- david raistrick [EMAIL PROTECTED] http://www.expita.com/nomime.html ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Serious (ha-ha) bug in 4.9-RELEASE
On Tue, Nov 04, 2003 at 07:37:05AM -0500, Brian T. Schellenberger wrote: > > > > On Monday 03 November 2003 07:06 pm, Erik Trulsson wrote: > | On Mon, Nov 03, 2003 at 03:50:57PM -0800, Chris Pressey wrote: > | > On Tue, 4 Nov 2003 00:17:26 +0100 > | > > | > Erik Trulsson <[EMAIL PROTECTED]> wrote: > | > > I am quite certain it is a local problem at your end. > | > > | > Seems odd that it would be affecting my system as well, then :) > | > | Alright, so I was mistaken. It is not a local problem. > | > | > > What value is your TERM environment variable set to? > | > > | > # echo $TERM > | > xterm > | > > | > Note that the problem doesn't show up for me under cons25. > | > | Yeah, I noticed. Eventually. > | > | > The md5 hash of my /usr/share/misc/termcap is identical to the one given > | > in the previous message. > | > > | > I have no idea. > | > | It seems that the termcap entry for xterm was substantially changed > | between 4.8-release and 4.9-release. > | One change was the removal of of the "bs" capability which > | /usr/games/hack requires. That capability is documented as being > | obsolete and that programs shouldn't depend on it, so it seems that the > | bug is in /usr/games/hack rather than termcap. > > Well, perhaps, but was there some particular *benefit* to removing the "bs" > capability? It seems sort of perverse / unexpected to remove functionality, > even old/depricated functionality, unless it's doing some harm, especially on > a "point release." (Removing it from 4.x to 5.x wouldn't seem so > surprising.) I haven't checked, but one possible benefit might be to get the description to fit into the 1023-character limit that termcap imposes. I imagine that the xterm-descriptions lie very close to this limit. I.e. to add the "bs" capability might require removing some other capability that is of greater use. Besides, ever since it was first imported into FreeBSD back in 1994, the termcap(5) has always documented the "bs" capability as being obsolete, and that new programs shouldn't use it. I guess it was just assumed that no program used it any more. Since this seems to be the first time anybody has complained about it, it guess it was a reasonable assumption. For old programs, one can always use the xterm-r6 or xterm-r5 termcap descriptions, which are supposed to be compatible with the xterm descriptions in old releases of X. (Both of which does have the "bs" capability, but probably lacks many features of newer xterms.) This is probably enough to cater for backwards compatibility. > > OTOH, the fact that nobody seems to have noticed until after 4.9 was released > is a pretty strong argument that not very many people care--unless of > course :-) > > I checked the CVS respository, and this change seems to have been made *six* > months ago: Yep. It doesn't seem as if there are all that many people who run /usr/games/hack in an xterm. -- Erik Trulsson [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [4.9-RC] What happened to ``options HTT'' ?
Oliver Fromme: >Brooks Davis <[EMAIL PROTECTED]> wrote: > > On Tue, Oct 28, 2003 at 11:42:57PM +0200, Jaco van Tonder wrote: > > > I just cvsup'ed to that latest -STABLE and saw that option HTT > > > is no longer availible in LINT. Does anyone know why this is no > > > longer supported? I searched the stable@ list but cant seem to > > > find anything on this. > > It is no longer necessicary as HTT logical CPUs are now > > activated by default. If you wish to use them, set the sysctl > > machdep.hlt_logical_cpus to 0. >Can that sysctl be changed at runtime, or is it only possible to do it >in the loader? The UPDATING entry isn't completely clear about that. I can confirm from experience that changing this sysctl to 0 immediately started the second logical CPU. Turning it back to 1 apparently stops processes on the second logical CPU to start, instead everything runs on CPU0. However processes running on the second CPU remain there until they terminate. >By the way, are there any "real world" experiences whether it's worth >it to use the logical CPUs, say, on a PostgreSQL or Apache server, or >with Java stuff (jakarta/tomcat etc.)? That would interest me as well. In particular I would be interested where improvements might be expected - in CPU-intensive environments, interrupt-intensive enviroments, and I/O-intensive environments. I am running a system that walks a couple of thousand files every minute - would that benefit from HTT? (I seem to recall that UFS as part of the kernel is restricted to a single CPU?) Helge ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HELP: ServerWorks data corruption after 350 MB with BerkeleyD B 4.0?
It seems Anshuman Kanwar wrote: Ehem, this machine is NOT ServerWorks based, its Intel... > rack2-102.nyc# pciconf -l > [EMAIL PROTECTED]:0:0: class=0x06 card=0x chip=0x254c8086 rev=0x01 > hdr=0x00 > [EMAIL PROTECTED]:2:0: class=0x060400 card=0x chip=0x25438086 rev=0x01 > hdr=0x01 > [EMAIL PROTECTED]:3:0: class=0x060400 card=0x chip=0x25458086 rev=0x01 > hdr=0x01 > [EMAIL PROTECTED]:29:0:class=0x0c0300 card=0x24808086 chip=0x24828086 > rev=0x02 hdr=0x00 > [EMAIL PROTECTED]:30:0:class=0x060400 card=0x chip=0x244e8086 > rev=0x42 hdr=0x01 > [EMAIL PROTECTED]:31:0:class=0x060100 card=0x chip=0x24808086 > rev=0x02 hdr=0x00 > [EMAIL PROTECTED]:31:1: class=0x01018a card=0x24808086 chip=0x248b8086 > rev=0x02 hdr=0x00 > [EMAIL PROTECTED]:31:3:class=0x0c0500 card=0x24808086 chip=0x24838086 > rev=0x02 hdr=0x00 > [EMAIL PROTECTED]:28:0:class=0x080020 card=0x14618086 chip=0x14618086 > rev=0x04 hdr=0x00 > [EMAIL PROTECTED]:29:0:class=0x060400 card=0x0050 chip=0x14608086 > rev=0x04 hdr=0x01 > [EMAIL PROTECTED]:30:0:class=0x080020 card=0x14618086 chip=0x14618086 > rev=0x04 hdr=0x00 > [EMAIL PROTECTED]:31:0:class=0x060400 card=0x0050 chip=0x14608086 > rev=0x04 hdr=0x01 > [EMAIL PROTECTED]:1:0: class=0x02 card=0x10118086 chip=0x10108086 rev=0x01 > hdr=0x00 > [EMAIL PROTECTED]:1:1: class=0x02 card=0x10118086 chip=0x10108086 rev=0x01 > hdr=0x00 > [EMAIL PROTECTED]:28:0:class=0x080020 card=0x14618086 chip=0x14618086 > rev=0x04 hdr=0x00 > [EMAIL PROTECTED]:29:0:class=0x060400 card=0x0050 chip=0x14608086 > rev=0x04 hdr=0x01 > [EMAIL PROTECTED]:30:0:class=0x080020 card=0x14618086 chip=0x14618086 > rev=0x04 hdr=0x00 > [EMAIL PROTECTED]:31:0:class=0x060400 card=0x0050 chip=0x14608086 > rev=0x04 hdr=0x01 > [EMAIL PROTECTED]:1:0: class=0x02 card=0x10408086 chip=0x12298086 rev=0x10 > hdr=0x00 > [EMAIL PROTECTED]:2:0: class=0x03 card=0x80081002 chip=0x47521002 rev=0x27 > hdr=0x00 -Søren ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
