Re: Problem building x11-toolkits/qt33 on 6.3/amd64
On Sat, Feb 02, 2008 at 12:08:36PM +1100, Peter Jeremy wrote: >I am unable to get qt33 to build and am getting the following errors. >My ports tree is up-to-date and I've rebuilt the config file. I've >checked pointyhat and it's not reporting any error. Any ideas where >to look next? False alarm. I found that the i386 Qt was visible in my searchpath and this was confusing the amd64 build. -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. pgpQNm240gzMM.pgp Description: PGP signature
Problem building x11-toolkits/qt33 on 6.3/amd64
I am unable to get qt33 to build and am getting the following errors. My ports tree is up-to-date and I've rebuilt the config file. I've checked pointyhat and it's not reporting any error. Any ideas where to look next? turion% make clean ===> Cleaning for qt-3.3.8_6 turion% make ===> Found saved configuration for qt-3.3.8_6 ===> Extracting for qt-3.3.8_6 => MD5 Checksum OK for KDE/qt-x11-free-3.3.8.tar.bz2. => SHA256 Checksum OK for KDE/qt-x11-free-3.3.8.tar.bz2. ===> Patching for qt-3.3.8_6 ===> Applying extra patch /usr/ports/x11-toolkits/qt33/files/0081-format-string-fixes.diff ===> Applying FreeBSD patches for qt-3.3.8_6 ===> qt-3.3.8_6 depends on executable: qmake - found ===> qt-3.3.8_6 depends on file: /usr/local/libdata/xorg/libraries - found ===> qt-3.3.8_6 depends on shared library: mng - found ===> qt-3.3.8_6 depends on shared library: png - found ===> qt-3.3.8_6 depends on shared library: jpeg - found ===> qt-3.3.8_6 depends on shared library: Xft.2 - found ===> qt-3.3.8_6 depends on shared library: audio - found ===> qt-3.3.8_6 depends on shared library: GLU.1 - found ===> Configuring for qt-3.3.8_6 The specified system/compiler is not supported: /usr/tmp/usr/ports/x11-toolkits/qt33/work/qt-x11-free-3.3.8/mkspecs//usr/local/share/qt/mkspecs/freebsd-g++ Please see the PLATFORMS file for a complete list. ===> Script "configure" failed unexpectedly. Please report the problem to [EMAIL PROTECTED] [maintainer] and attach the "/usr/tmp/usr/ports/x11-toolkits/qt33/work/qt-x11-free-3.3.8/config.log" including the output of the failure of your make command. Also, it might be a good idea to provide an overview of all packages installed on your system (e.g. an `ls /var/db/pkg`). *** Error code 1 Stop in /usr/ports/x11-toolkits/qt33. *** Error code 1 Stop in /usr/ports/x11-toolkits/qt33. turion% ls -l /usr/tmp/usr/ports/x11-toolkits/qt33/work/qt-x11-free-3.3.8/config.log ls: /usr/tmp/usr/ports/x11-toolkits/qt33/work/qt-x11-free-3.3.8/config.log: No such file or directory turion% uname -a FreeBSD turion.vk2pj.dyndns.org 6.3-PRERELEASE FreeBSD 6.3-PRERELEASE #32: Tue Jan 1 13:59:31 EST 2008 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/turion amd64 turion% -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. pgpAVtjGDklBy.pgp Description: PGP signature
Re: ports-mgmt/portupgrade-devel
> > Hi, > > > > when using portupgrade-devel, I'm getting the following errors: > > > > ---> Session ended at: Tue, 29 Jan 2008 22:58:52 +0100 (consumed > > 00:02:01) /usr/local/lib/ruby/site_ruby/1.8/pkgversion.rb:41:in > > `initialize': : Not in due form: '[_][,]'. > > (ArgumentError) > > What port exactly did you upgraded please? Nothing particular - I tried portupgrade (devl) -a -v. Downgrading to the "normal" portupgrade did the trick, though. Regards, Mark -- Hurewitz's Memory Principle: The chance of forgetting something is directly proportional to . to uh .. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
FreeBSD Port: hplip-2.7.12 -- Please extend pkg-message
Hi, as I did not manage to figure this out myself, found no mention of it in a lot of howtos and troubleshooting sites, until I finally had to ask for help on usenet, I suggest to add the following to pkg-message: When you use the lp, lpr, lprm or lpq command, you have to use those installed by cups in /usr/local/bin, not the ones the base system provides in /usr/bin. For hplip to work, you will want to either backup the binaries in /usr/bin and replace them with symlinks to the ones in /usr/local/bin; or put /usr/local/bin before /usr/bin in your $PATH. Actually, hp-testpage and hp-toolbox _do_ use these commands, so without at least changing $PATH -- which is unchanged installation default 7.0-RC1 on my machine --, the tools simply do not work, they complain about "no running lpd" and if you start one, the print jobs queue up in the wrong place. And I spent hours looking for a clue. YMMV. Michael ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [: -le: argument expected
On Fri, Feb 01, 2008 at 10:18:14AM -0800, Chris H. wrote: > I wanted to sync up my ports database before hand. So ran a portsdb -uU. > This - interestingly enough, resulted in both [: -le: argument expected, > and [: -eq: argument expected being emitted /many/ times during the portsdb > process. So, now I'm stumped. It is clear that it is /not/ specific to the > php5-apache-module. But rather, something that is common to that, and other > ports. It's clear that /bin/[ is the command complaining. But my guess is > that something else is triggering it - perl perhaps? Don't know, and ATM > don't know how to find out, or what to try next. :( Some educational history and points: /bin/[ is the same thing as /bin/test (one might be a hardlink, I can't remember). If you've ever seen an sh script, you'll see a lot of this: if [ x"$o" = x"hello" ]; then ... fi Which is identical to: if test x"$o" = x"hello"; then ... fi There's some important things to note about this, though. Many shells (such as bash) include their own internal version of test, which is wise because it saves on having to fork a /bin/[ or /bin/test process every time something wanted to run a comparison operation. test(1) describes the applicable comparison operators (=, !=, -gt, -le, etc.). > [: -le: argument expected This means something somewhere is doing: if [ val1 -le $val2 ]; then ... fi I'm willing to bet val2 is a variable which isn't being set prior to the test conditional being run, which would mean the test conditional would be expanded by the shell into this: if [ val1 -le ]; then ... fi Which is going to emit the error in question. To confirm that the problem is coming from a /bin/sh script (or something that actually uses /bin/[ or /bin/test, versus, say, a bash shell script which uses bash's internal [/test), we can do this: icarus$ /bin/sh # if [ 123 -le ]; then echo hi; fi [: -le: argument expected # if test 123 -le; then echo hi; fi test: -le: argument expected Note the difference if [ or test is used within bash: bash# if [ 123 -le ]; then echo hi; fi -bash: [: 123: unary operator expected bash# if test 123 -le; then echo hi; fi -bash: test: 123: unary operator expected What all this means: the error is being induced by a /bin/sh script of somekind. That said, the added fact that "make extract" causes this for you means that the error is coming from something within the ports framework, which means something in ports/Mk. This sort-of thing has happened in the past, and has occasionally turned out to be caused someone having some very bad typos in /etc/make.conf which broke all sorts of things. > make emits the above, as well as the following: > > configure.in:152: warning: AC_PROG_LEX invoked multiple times > ../../lib/autoconf/programs.m4:779: AC_DECL_YYTEXT is expanded from... > aclocal.m4:2080: PHP_PROG_LEX is expanded from... > configure.in:152: the top level Second time someone's told you -- this is normal based on the current autoconf framework in ports. I've complained about this to ale@ in the past, but was told "if it bothers you that much, fix it; it's harmless otherwise". And being as I have dealt with similar autoconf warnings in ports that *I* maintain, I can tell you that getting them to not emit such warnings is a real pain in the ass. > config.status: executing default commands > ===> Building for php5-5.2.5_1 > "Makefile", line 592: warning: duplicate script for target > "main/internal_functions.lo" ignored Also "normal". > -I/usr/ports/lang/php5/work/php-5.2.5/Zend-O2 -fno-strict-aliasing > -pipe -prefer-non-pic -c > /usr/ports/lang/php5/work/php-5.2.5/sapi/apache/sapi_apache.c -o > sapi/apache/sapi_apache.lo > /usr/ports/lang/php5/work/php-5.2.5/sapi/apache/sapi_apache.c: In function > 'apache_php_module_main': > /usr/ports/lang/php5/work/php-5.2.5/sapi/apache/sapi_apache.c:44: error: > 'NOT_FOUND' undeclared (first use in this function) > /usr/ports/lang/php5/work/php-5.2.5/sapi/apache/sapi_apache.c:44: error: > (Each undeclared identifier is reported only once > /usr/ports/lang/php5/work/php-5.2.5/sapi/apache/sapi_apache.c:44: error: > for each function it appears in.) > *** Error code 1 Hmm, this looks like there could be two versions of Apache APR on your machine (one from the www/apache20 port, and possibly some other port installing something similar to devel/apr on the same box). This could also be induced by something broken in /etc/make.conf, but it's hard to tell. It's getting to the point where for someone to help you with this, they're going to need access to the machine. I can't reproduce this behaviour on any of my personal FreeBSD boxes, nor any of our production machines (running RELENG_6 and RELENG_7), and I haven't seen anyone else on this list able to reproduce the symptom either. -- | Jeremy Chadwickjdc a
Re: [: -le: argument expected
Hello Tom, and thank you for your reply. Quoting Tom Evans <[EMAIL PROTECTED]>: On Fri, 2008-02-01 at 07:42 -0800, Chris H. wrote: Hello Tom, and thank you for your thoughtful reply. I would have to assert that in my case, your assertions are also a bit moot. Would make deinstall apache2.0 && make install apache2.2 && make install php5 -DWITH_CGI=TRUE -DWITH_CLI=true -DWITH_APACHE=true accomplish a successful build? In fact, no. As the real problem at hand, is getting php5 to build the apache module (libphp5.so). :) On the other hand. Assuming a successfully built apache module; How large is the difference between the same modules in 1.2 vs 2.0 vs 2.2? How large is the difference in apache' reaction to calls made to apache, where these modules are involved? Does Apache 2.2 offer the -DWITH_MPM=threadpool? I couldn't find it. Thank you for your informative, and thoughtful reply. --Chris H HTH. I'm afraid I can't help too much with PHP, as I don't myself use PHP anywhere. I know other guys in the office do have PHP 5 working nicely with apache22 from ports though - I'd assume that the problem is with a system library, I may have missed the email with the actual error logs in it. When using PHP, it is important to use the prefork MPM. The other MPMs are all threaded, and not very many PHP extensions are thread safe. I'm not sure what the 'threadpool' MPM is - in 2.2 there is prefork, worker (which implements itself through a multi-process multi-thread model), and event, which is a specialized version of worker that uses a single dedicated thread to handle listening sockets and keep-alive sockets. We use the event MPM on our front end proxies (also marked as 'experimental', but this is (according to the dev I asked) as it doesn't support accept filters (and hence cannot handle SSL). Our proxies handle a large amount of web traffic, serving static files locally and reverse proxying dynamic requests to the appropriate backend webservers, running anything from custom 1.3 apache modules, PHP 5 served from prefork MPM apache 2.2 servers, and, in one unfortunate incidence, hand-rolled web servers. The event model works incredibly well at this task, with load averages never peeking above 0.05. I just checked the 2.0 modules page [1], and there is a 'threadpool' MPM there, listed as 'This MPM is a developer playground and highly experimental'! I think that even if you do get PHP5 to build with that, you will be disappointed as soon as you get some significant load, and will have a hell of a time debugging it. prefork MPM isn't sexy, but it does work with PHP. From [2]: We do not recommend using a threaded MPM in production with Apache2. Use the prefork MPM instead, or use Apache1. For information on why, read the related FAQ entry on using Apache2 with a threaded MPM I greatly appreciate your /very/ informative reply. All points well taken. If you have some error messages (or pointers to the emails I missed!) I'll take a looksie at them. Well, I decided that perhaps something might have been added that to ports since my last cvsup. Hoping that any addition might cure my current delemna. I wanted to sync up my ports database before hand. So ran a portsdb -uU. This - interestingly enough, resulted in both [: -le: argument expected, and [: -eq: argument expected being emitted /many/ times during the portsdb process. So, now I'm stumped. It is clear that it is /not/ specific to the php5-apache-module. But rather, something that is common to that, and other ports. It's clear that /bin/[ is the command complaining. But my guess is that something else is triggering it - perl perhaps? Don't know, and ATM don't know how to find out, or what to try next. :( Thank you again for taking the time to provide such an informative response. FWIW make extract emits the following: [: -le: argument expected [: -le: argument expected ===> Cleaning for php5-5.2.5_1 [: -le: argument expected make emits the above, as well as the following: configure.in:152: warning: AC_PROG_LEX invoked multiple times ../../lib/autoconf/programs.m4:779: AC_DECL_YYTEXT is expanded from... aclocal.m4:2080: PHP_PROG_LEX is expanded from... configure.in:152: the top level Thank you for using PHP. config.status: creating php5.spec config.status: creating main/build-defs.h config.status: creating scripts/phpize config.status: creating scripts/man1/phpize.1 config.status: creating scripts/php-config config.status: creating scripts/man1/php-config.1 config.status: creating sapi/cli/php.1 config.status: creating main/php_config.h config.status: executing default commands ===> Building for php5-5.2.5_1 "Makefile", line 592: warning: duplicate script for target "main/internal_functions.lo" ignored -I/usr/ports/lang/php5/work/php-5.2.5/Zend-O2 -fno-strict-aliasing -pipe -prefer-non-pic -c /usr/ports/lang/php5/work/php-5.2.5/sapi/apache/sapi_apache.c -o sapi/apache/sapi_apache.lo /usr/ports/lang/php5/work/php-5.2.5/sapi/apache/
Re: /usr/local/share/config/kdm is missing
"Piotr" <[EMAIL PROTECTED]> writes: > I have freeBSD 6.3 with KDE 3.5.8 installed, but the > /usr/local/share/config/kdm directory is missing. It's not in port's default packing list. Maybe you should be looking for specific files. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [: -le: argument expected
On Fri, 2008-02-01 at 07:42 -0800, Chris H. wrote: > Hello Tom, and thank you for your thoughtful reply. > > I would have to assert that in my case, your assertions are also a bit > moot. Would make deinstall apache2.0 && make install apache2.2 && > make install php5 -DWITH_CGI=TRUE -DWITH_CLI=true -DWITH_APACHE=true > accomplish a successful build? In fact, no. As the real problem at > hand, is getting php5 to build the apache module (libphp5.so). :) > > On the other hand. Assuming a successfully built apache module; > How large is the difference between the same modules in > 1.2 vs 2.0 vs 2.2? > How large is the difference in apache' reaction to calls made to > apache, where these modules are involved? > Does Apache 2.2 offer the -DWITH_MPM=threadpool? I couldn't find it. > > Thank you for your informative, and thoughtful reply. > > --Chris H HTH. I'm afraid I can't help too much with PHP, as I don't myself use PHP anywhere. I know other guys in the office do have PHP 5 working nicely with apache22 from ports though - I'd assume that the problem is with a system library, I may have missed the email with the actual error logs in it. When using PHP, it is important to use the prefork MPM. The other MPMs are all threaded, and not very many PHP extensions are thread safe. I'm not sure what the 'threadpool' MPM is - in 2.2 there is prefork, worker (which implements itself through a multi-process multi-thread model), and event, which is a specialized version of worker that uses a single dedicated thread to handle listening sockets and keep-alive sockets. We use the event MPM on our front end proxies (also marked as 'experimental', but this is (according to the dev I asked) as it doesn't support accept filters (and hence cannot handle SSL). Our proxies handle a large amount of web traffic, serving static files locally and reverse proxying dynamic requests to the appropriate backend webservers, running anything from custom 1.3 apache modules, PHP 5 served from prefork MPM apache 2.2 servers, and, in one unfortunate incidence, hand-rolled web servers. The event model works incredibly well at this task, with load averages never peeking above 0.05. I just checked the 2.0 modules page [1], and there is a 'threadpool' MPM there, listed as 'This MPM is a developer playground and highly experimental'! I think that even if you do get PHP5 to build with that, you will be disappointed as soon as you get some significant load, and will have a hell of a time debugging it. prefork MPM isn't sexy, but it does work with PHP. From [2]: We do not recommend using a threaded MPM in production with Apache2. Use the prefork MPM instead, or use Apache1. For information on why, read the related FAQ entry on using Apache2 with a threaded MPM If you have some error messages (or pointers to the emails I missed!) I'll take a looksie at them. Cheers Tom [1] http://httpd.apache.org/docs/2.0/mod/ [2] http://uk.php.net/manual/en/install.unix.apache2.php signature.asc Description: This is a digitally signed message part
Re: [: -le: argument expected
Hello Tom, and thank you for your thoughtful reply.
Quoting Tom Evans <[EMAIL PROTECTED]>:
On Thu, 2008-01-31 at 18:41 -0800, Chris H. wrote:
The cause is in the file: lang/php5/files/patch-Zend_zend_list.c
It accounts for all /3/ errors emitted during the initial portion
of the make process. The lines are as follows:
--- Zend/zend_list.c.orig 2007-01-01 10:35:46.0 +0100
+++ Zend/zend_list.c2008-01-29 11:05:14.0 +0100
@@ -48,7 +48,7 @@
return index;
}
-ZEND_API int _zend_list_delete(int id TSRMLS_DC)
+ZEND_API int _zend_list_delete(ulong id TSRMLS_DC)
{
*** zend_rsrc_list_entry *le;
@@ -65,7 +65,7 @@
}
-ZEND_API void *_zend_list_find(int id, int *type TSRMLS_DC)
+ZEND_API void *_zend_list_find(ulong id, int *type TSRMLS_DC)
{
*** zend_rsrc_list_entry *le;
@@ -78,7 +78,7 @@
}
}
-ZEND_API int _zend_list_addref(int id TSRMLS_DC)
+ZEND_API int _zend_list_addref(ulong id TSRMLS_DC)
{
*** zend_rsrc_list_entry *le;
(highlighted with three asterisks for clarity).
While it's nice that I found them. I'm not sure what to do to
make them correct. Any thoughts? Should I simply send-pr -
php5-apache-module build failure (lang/php5/files/patch-Zend_zend_list.c)?
I doubt that patch is the issue. The error comes from a malformed call
to /bin/test (or /bin/[ ). The -le test tests two numbers to see if the
first is less than the second.
With correct usage:
/bin/[ 5 -le 10 ] && echo "first is less"
first is less
With incorrect usage
/bin/[ 5 -le ] && echo "first is less"
[: -le: argument expected
The patch you have shown changes the id of a zend_rsrc_list_entry to be
an unsigned long rather than an int, the fact that the variable name
(which does not get updated, modified or altered) is called 'le' for
'list element' is neither here nor there.
Quite so. I eventually figured that out. But by then had been up for far
too long, and decided to get some sleep, and reply in the morning. Good
morning. :)
I would thoroughly recommend using apache 2.2 with the prefork MPM if
you wish to run PHP. Your arguments for choosing 2.0 over 2.2 are
spurious, as there are virtually no difference in conf directives,
server layout or security, where as apache 2.2 is well maintained and
secure. Apache 2.2 has many notable improvements, especially in
performance and proxying. See [1].
The real hint is on apache.org [2] - 'We consider Apache 2.2 to be the
best available version at the time of this release. We offer Apache
2.0.63 as the best legacy version of Apache 2.0 available. Users should
first consider upgrading to the current release of Apache 2.2 instead.'
I would have to assert that in my case, your assertions are also a bit
moot. Would make deinstall apache2.0 && make install apache2.2 &&
make install php5 -DWITH_CGI=TRUE -DWITH_CLI=true -DWITH_APACHE=true
accomplish a successful build? In fact, no. As the real problem at
hand, is getting php5 to build the apache module (libphp5.so). :)
On the other hand. Assuming a successfully built apache module;
How large is the difference between the same modules in
1.2 vs 2.0 vs 2.2?
How large is the difference in apache' reaction to calls made to
apache, where these modules are involved?
Does Apache 2.2 offer the -DWITH_MPM=threadpool? I couldn't find it.
Thank you for your informative, and thoughtful reply.
--Chris H
On the other hand, your server, your rules. :)
Tom
[1] http://httpd.apache.org/docs/2.2/new_features_2_2.html
[2] http://www.apache.org/dist/httpd/Announcement2.0.html
--
panic: kernel trap (ignored)
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
/usr/local/share/config/kdm is missing
hi I have freeBSD 6.3 with KDE 3.5.8 installed, but the /usr/local/share/config/kdm directory is missing. ___ Join Excite! - http://www.excite.com The most personalized portal on the Web! ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Upgrading xorg 6.9 to 7.3 -- what happened to xorg-upgrade?
On Thu, Jan 31, 2008 at 06:10:36PM -0600, Bob Willcox wrote: > On Thu, Jan 31, 2008 at 03:56:23PM -0500, Wesley Shields wrote: > > On Thu, Jan 31, 2008 at 02:34:26PM -0600, Bob Willcox wrote: > > > The info in /usr/ports/UPGRADING describing the steps to upgrade xorg > > > says to run xorg-upgrade. Unfortunately, I can't find *anything* with > > > this name anywhere on my system. Here's my uname output: > > > > > > [EMAIL PROTECTED]:pf /usr/ports> uname -a > > > FreeBSD sarlacc.austin.ibm.com 6.3-PRERELEASE FreeBSD 6.3-PRERELEASE #20: > > > Wed Jan 2 11:29:25 CST 2008 [EMAIL > > > PROTECTED]:/usr/obj/usr/src/sys/SARLACC amd64 > > > > > > I have (just today) updated my ports tree (via cvsup). > > > > > > Anyone have any idea where I might find the xorg-upgrade file? Perhaps > > > it isn't required any longer. If that's the case, that would be good to > > > know as well. > > > > What that entry is talking about is using script(1) in order to get an > > accurate account of exactly what you did in case something goes wrong. > > No, I'm not interested in the script(1) part. I am familiar with script > but wasn't interested in using it here. What I want is the xorg-upgrade > program that is used to move a bunch of x11 files to new places for the > 7.x version. Are you talking about this part of UPDATING: # sh /usr/ports/Tools/scripts/mergebase.sh which will merge /usr/X11R6 into /usr/local? You specifically mentioned "the xorg-upgrade file" yet the only mention of "xorg-upgrade" in UPDATING is talking about script(1). So I'm a bit confused about your definition of "xorg-upgrade program." My guess is the mergebase script is what you want? -- WXS ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Upgrading xorg 6.9 to 7.3 -- what happened to xorg-upgrade?
On Fri, Feb 01, 2008 at 12:12:15AM -0600, Scot Hetzel wrote: > On 1/31/08, Jeremy Messenger <[EMAIL PROTECTED]> wrote: > > On Thu, 31 Jan 2008 21:26:38 -0600, Bob Willcox <[EMAIL PROTECTED]> wrote: > > > > > On Fri, Feb 01, 2008 at 01:30:23AM +0100, Operator wrote: > > >> In article <[EMAIL PROTECTED]>, > > >> Bob Willcox <[EMAIL PROTECTED]> writes: > > >> > > >> > What I want is the xorg-upgrade > > >> > program that is used to move a bunch of x11 files to new places for > > >> the > : > > > > In the /usr/ports/UPDATING said: > : > > > ># script xorg-upgrade > : > We should change this in UPDATING to: > > # script xorg-upgrade.log > > Then there would be less confusion about the xorg-upgrade file. That probably would have helped me. The really sad thing about my mis-reading this is that is the third time I've worked through this particular UPDATING entry to upgrade X. It's been about 8 to 10 months since I last did it, but that doesn't make it any less embarrassing. :) Bob > > Scot -- Bob Willcox A lack of planning on your part does [EMAIL PROTECTED] not constitute an emergency on my part. Austin, TX ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Upgrading xorg 6.9 to 7.3 -- what happened to xorg-upgrade?
On Fri, Feb 01, 2008 at 02:40:44PM +1030, Wayne Sierke wrote: > > On Thu, 2008-01-31 at 21:26 -0600, Bob Willcox wrote: > > On Fri, Feb 01, 2008 at 01:30:23AM +0100, Operator wrote: > > > In article <[EMAIL PROTECTED]>, > > > Bob Willcox <[EMAIL PROTECTED]> writes: > > > > > > > What I want is the xorg-upgrade > > > > program that is used to move a bunch of x11 files to new places for the > > > > 7.x version. > > > > > > /usr/ports/Tools/scripts/mergebase.sh > > > > Is mergebase.sh a replacement for xorg-upgrade? > > > > Bob, > > Re-read the previous replies and re-read man script(1) paying careful > attention to the syntax of the (optional) arguments. xorg-upgrade is the > name of the output file that script(1) will write to (i.e. name it > anything you want, how about xorg-upgrade.log). xorg-upgrade is merely a > suggested name for it. > > The wording of the /usr/ports/UPDATING entry can be misleading if you > read it quickly and make what appears to be a reasonable assumption > about how script(1) is used, viz. "run the xorg 7.2 upgrade inside a > script(1) session." followed by the "# script xorg-upgrade" example. Ok, my dumb mistake...of course you guys are all right! I've been pretty sick is my only (lame) excuse, and it must be effecting my ablity to think. :) Thanks and I apologize for all the noise. Bob > > > Wayne -- Bob Willcox A lack of planning on your part does [EMAIL PROTECTED] not constitute an emergency on my part. Austin, TX ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [: -le: argument expected
On Thu, 2008-01-31 at 18:41 -0800, Chris H. wrote:
>
> The cause is in the file: lang/php5/files/patch-Zend_zend_list.c
>
> It accounts for all /3/ errors emitted during the initial portion
> of the make process. The lines are as follows:
>
> --- Zend/zend_list.c.orig 2007-01-01 10:35:46.0 +0100
> +++ Zend/zend_list.c 2008-01-29 11:05:14.0 +0100
> @@ -48,7 +48,7 @@
> return index;
> }
>
> -ZEND_API int _zend_list_delete(int id TSRMLS_DC)
> +ZEND_API int _zend_list_delete(ulong id TSRMLS_DC)
> {
> *** zend_rsrc_list_entry *le;
>
> @@ -65,7 +65,7 @@
> }
>
>
> -ZEND_API void *_zend_list_find(int id, int *type TSRMLS_DC)
> +ZEND_API void *_zend_list_find(ulong id, int *type TSRMLS_DC)
> {
> *** zend_rsrc_list_entry *le;
>
> @@ -78,7 +78,7 @@
> }
> }
>
> -ZEND_API int _zend_list_addref(int id TSRMLS_DC)
> +ZEND_API int _zend_list_addref(ulong id TSRMLS_DC)
> {
> *** zend_rsrc_list_entry *le;
>
> (highlighted with three asterisks for clarity).
>
> While it's nice that I found them. I'm not sure what to do to
> make them correct. Any thoughts? Should I simply send-pr -
> php5-apache-module build failure (lang/php5/files/patch-Zend_zend_list.c)?
I doubt that patch is the issue. The error comes from a malformed call
to /bin/test (or /bin/[ ). The -le test tests two numbers to see if the
first is less than the second.
With correct usage:
/bin/[ 5 -le 10 ] && echo "first is less"
first is less
With incorrect usage
/bin/[ 5 -le ] && echo "first is less"
[: -le: argument expected
The patch you have shown changes the id of a zend_rsrc_list_entry to be
an unsigned long rather than an int, the fact that the variable name
(which does not get updated, modified or altered) is called 'le' for
'list element' is neither here nor there.
I would thoroughly recommend using apache 2.2 with the prefork MPM if
you wish to run PHP. Your arguments for choosing 2.0 over 2.2 are
spurious, as there are virtually no difference in conf directives,
server layout or security, where as apache 2.2 is well maintained and
secure. Apache 2.2 has many notable improvements, especially in
performance and proxying. See [1].
The real hint is on apache.org [2] - 'We consider Apache 2.2 to be the
best available version at the time of this release. We offer Apache
2.0.63 as the best legacy version of Apache 2.0 available. Users should
first consider upgrading to the current release of Apache 2.2 instead.'
On the other hand, your server, your rules. :)
Tom
[1] http://httpd.apache.org/docs/2.2/new_features_2_2.html
[2] http://www.apache.org/dist/httpd/Announcement2.0.html
signature.asc
Description: This is a digitally signed message part
Parallelized Port Upgrade Tool Announcement
Dear Multi-core Computer Users: Ports+ is the first and the only port upgrading tool to fetch, configure, compile, and install packages via ports in parallel. There are some tools that allows downloading archives in parallel. However, none of others builds, nor installs packages in concurrent fashion, despite its high demand. This is an announcement of the first stable ports+ tool for these who wants to utilize all CPUs, disk actives, and network bandwidth at maximum. Indeed, I asked some inputs on this list about a half year ago. Thank you for the feedbacks. Now, ports+ has its front-end, fixed number of bugs, and more polished. The purpose of Ports+ is not a complete solution but rather co-existence with others tools such as portupgrade. Ports+ provides speed at cost of user interaction. That is like a car is a better vehicle than an airplane for daily life. However, you would like to take an airplane for a long trip. You won't drive from New York to California for a Thanksgiving weekend. You have big steps with ports+ and adjust small pieces with like portupgrade. More reading materials are available via following links. The Ports+ Project Design and Goal http://uyota.asablo.jp/blog/2008/01/02/2541411 The Ports+ Architecture/Implementation http://uyota.asablo.jp/blog/2008/01/03/2543196 Daily Ports+ http://uyota.asablo.jp/blog/2008/01/16/2563161 http://uyota.asablo.jp/blog/2008/01/17/2564930 http://uyota.asablo.jp/blog/2008/01/18/2566268 http://uyota.asablo.jp/blog/2008/01/20/2569358 http://uyota.asablo.jp/blog/2008/01/21/2571368 http://uyota.asablo.jp/blog/2008/01/22/2572683 http://uyota.asablo.jp/blog/2008/02/01/2594680 Feedbacks are welcome. Thanks, Hiro ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: cacti broken in 6.3?
Edwin Groothuis <[EMAIL PROTECTED]> wrote: On Wed, Jan 30, 2008 at 11:33:37PM +0100, Helmut Schneider wrote: Edwin Groothuis <[EMAIL PROTECTED]> wrote: >On Wed, Jan 30, 2008 at 10:22:31PM +0100, Helmut Schneider wrote: >>I started a long thread at http://forums.cacti.net/about25481.html but >>it turns out that FreeBSD 6.3 might be the problem. FreeBSD 6.2 and >>7.0-RC1 (see below) are not affected. Here is what I did: > >Silly question from me maybe: did you recompile the net-snmp and >phpX-snmp libraries? Yes, I forced a portupgrade of net-snmp-5.3.2_1 and php5-snmp-5.2.5_1 and I even completly removed cacti, .*PHP.* and .*snmp.* and did a 'portinstall -Rf cacti'. I also tried with cacti 0.8.7 and 0.8.6j. I also dropped the cacti database and recreated it. Does your question imply that you are running cacti on 6.3 without problems? No, but I have planned an upgrade of a lot of machines this weekend, including one which runs Cacti :-) The only reason I wondered if net-snmp was recompiled is because it takes some low-level things like CPU usage and memory, so I thought maybe it is related. I'm a bit concerned as I can't reproduce the problem on a freshly installed 6.3. Currently I'm rebuilding *all* ports on the system (the cacti server itself is the problem, not the clients) and if that doesn't help I will rebuild the userland, too. When you upgraded your servers it would be nice to know if it worked for you, or not. I did the upgrade using freebsd-update. Helmut -- No Swen today, my love has gone away My mailbox stands for lorn, a symbol of the dawn ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Upgrading xorg 6.9 to 7.3 -- what happened to xorg-upgrade?
On 1/31/08, Jeremy Messenger <[EMAIL PROTECTED]> wrote: > We should change this in UPDATING to: > > # script xorg-upgrade.log > > Then there would be less confusion about the xorg-upgrade file. > Good idea. I'll confess that I fell into the same trap that Bob did when I upgraded my system and was wondering why nothing happened when I typed ``script xorg-update''. However, since I'm not familiar with script(1) I looked at the manpage and figured it out. Regards, Mark ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Upgrading xorg 6.9 to 7.3 -- what happened to xorg-upgrade?
> Bob Willcox wrote: > Thanks for the info Mark, however I do know what script does and why > one might use it (I've used it for years for just that, and I'm not > even trying to use it here). > > What I was asking about (please re-read my subject line) was the > xorg-upgrade command itself. Where is it located? I can't find it > anywhere on any of my 10 FreeBSD systems (and I know it used to exist > because I have used it in the past). > As everyone keeps saying - there is no such command, it is the filename for the output from script(1). Read past the '# script xorg-upgrade' line in UPDATING - until the line '# exit' - there are about a dozen steps to do the upgrade, there is no single program to do it. These are the steps from UPDATING (with the commentary removed): # script xorg-upgrade # portupgrade -f -o ports-mgmt/portupgrade-devel portupgrade # rm -f /usr/ports/INDEX*.db /var/db/pkg/pkgdb.db # pkgdb -fu # cd /usr/ports && make index # cd /usr/ports && make fetchindex For users of csh-like shells: # setenv XORG_UPGRADE yes For users of sh-like shells: # export XORG_UPGRADE=yes # portupgrade -Rf libXft # portupgrade -a # portupgrade -a -x 'gstreamer*' # portupgrade -Rr 'gstreamer*' # portupgrade -aP # pkg_delete xorg-manpages\* # sh /usr/ports/Tools/scripts/mergebase.sh Congratulations, you are done! # exit HTH Regards, Mark ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
