Re: PHP error
On 4/9/07, Beech Rintoul [EMAIL PROTECTED] wrote: I have a port which calls php -m as a test from the makefile. Problem is if I do php -m I get the following: stargate# php -m /libexec/ld-elf.so.1: /usr/local/lib/php/20060613/imap.so: Undefined symbol ssl_onceonlyinit I tried rebuilding php the module involved, but no joy. Does anyone have a suggestion? I'm running the following: FreeBSD 7.0-CURRENT #113: Sun Apr 8 08:27:49 AKDT 2007 Apache-2.0.59 php5-5.2.1_3 php5-imap-5.2.1_3 This worked about a month ago. Did you follow UPDATING when upgrading ports? In particular, there's been a gettext and some other interesting updates. If all else fails, go the pkg_delete -a way. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: cvsup.au.freebsd.org (Hosted on cvsup.planetmirror.com) issues
On Apr 6 at 08:25 +1000, Christopher Martin wrote: I have recently noticed serious issues with collections from the FreeBSD source tree maintained on cvsup.au.freebsd.org (cvsup.planetmirror.com), and have sought to compare it to two of the US servers, cvsup3 and cvsup4, and have found that cvsup.au.freebsd.org seems to be very wrong, with most of the ports tree being deleted when using the Australian mirror. I have also tried using cvsup2.au.freebsd.org but I have noticed that it seems to be very out of date (when compared to cvsup3.freebsd.org) and frequently unavailable (it must only allow a very limited number of clients). All the other Australian mirrors are just pointed at these two hosts. I notified [EMAIL PROTECTED] over a month ago but it has not as yet been corrected. FWIW, I had similar problems in February and emailed the same address. No response for me either. It seemed that CVS ID tags, such as $FreeBSD$, weren't being expanded. Tim. pgp6nHRaazeMx.pgp Description: PGP signature
Re: PostgreSQL 8.x defaults
5 apr 2007 kl. 15.24 skrev Craig Boston:
I recently installed some PostgreSQL 8.2 servers (and upgraded some
from
8.1), and it reminded me of a few lingering nits in our port that bug
me. Mostly the port seems that it can't make up its mind about VACCUM
strategy.
* We have a patch that sets autovacuum = yes in the default
postgresql.conf. However, it leaves the default stats_row_level
= no,
so autovacuum doesn't actually run.
Hi,
I've checked it out. Seems I have indeed missed the
stats_row_level... I'll fix this!
* Despite trying to turn on autovacuum, the port installs
periodic/daily/502.pgsql, which runs VACUUM (not even VACUUM
ANALYZE)
by default nightly.
It does run vaccumdb -aqz per default, where -z is for analyze:
$ grep daily_pgsql_vacuum_args files/502.pgsql
daily_pgsql_vacuum_args=-z
su -l pgsql -c vacuumdb -a -q ${daily_pgsql_vacuum_args}
It seems to me that we should pick one or the other -- either
1. Fully enable autovacuum and default to
daily_pgsql_vacuum_enable=NO
to avoid a superfluous cron job
or
2. Leave the periodic job enabled and not tease people with an
ineffectual autovacuum = yes in postgresql.conf.
Of the two I'd prefer the former, but that's just my opinion.
About the two strategies you present; autovacuum will probably need
some tweaking for most applications, since it will not perform
vacuums unless a certain percentage of the tuples are changed. Hence,
usually I use a combination of autovacuum and a nightly vacuumdb -za.
For smaller installations, the vanilla setup could of course be
either of your suggestions, or my just suggested combo, it is
probably a matter of taste. I'd prefer you #1 or the combo... I'll
think about it a bit more, and will fix the port. :)
Happy easter,
Palle
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to [EMAIL PROTECTED]
Package A should replace Package B
I had package A and package B. Package A does all the functions of Package B and some more functions. So installing package A should replace package B. So i need to have a 'REPLACES' like directive in Makefile of Package A which says package A should replace package B. currently I can't find 'REPLACES' directive. Is there any otherway we can achieve this ? Thanks, Alagar ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Package A should replace Package B
On 4/9/07, Alagarsamy [EMAIL PROTECTED] wrote: I had package A and package B. Package A does all the functions of Package B and some more functions. So installing package A should replace package B. So i need to have a 'REPLACES' like directive in Makefile of Package A which says package A should replace package B. currently I can't find 'REPLACES' directive. Is there any otherway we can achieve this ? Not this time of year, and it's not as simple as you sound. Just tell the user he needs to remove some packages before installing this one, and/or just set CONFLICTS. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Current unassigned ports problem reports
Current FreeBSD problem reports The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. Bugs can be in one of several states: o - open A problem report has been submitted, no sanity checking performed. a - analyzed The problem is understood and a solution is being sought. f - feedback Further work requires additional information from the originator or the community - possibly confirmation of the effectiveness of a proposed solution. p - patched A patch has been committed, but some issues (MFC and / or confirmation from originator) are still open. r - repocopy The resolution of the problem report is dependent on a repocopy operation within the CVS repository which is awaiting completion. s - suspended The problem is not being worked on, due to lack of information or resources. This is a prime candidate for somebody who is looking for a project to do. If the problem cannot be solved at all, it will be closed, rather than suspended. c - closed A problem report is closed when any changes have been integrated, documented, and tested -- or when fixing the problem is abandoned. Critical problems Serious problems S Tracker Resp. Description o ports/105549ports/www/squid_radius_auth doesn't work on sparc64 o ports/106369vpnd caused kernel panic with ppp mode o ports/106372vpnd can't run with slip mode o ports/107229sysutils/coreutils: gcp fails to set default ACL which o ports/107536editors/scite: Can't write on SciTE text editor f ports/108077www/linux-flashplugin9 crashes linux-firefox f ports/108105building biology/platon fails. f ports/108413net/vnc does not works. f ports/108537print/hplip: Build failure f ports/108606Courier MTA terminates abnormaly after installation f ports/108748mod_fcgid 1.10 does not work inside jail f ports/109160net/samba3 crashes freebsd when accessing a share resi f ports/110027DOS in net/silc-server, update available f ports/110035Port fix for sysutils/be_agent f ports/110454Joomla port Makefile has incorrect url for package f ports/110767[UPDATE]java/jboss3:update to jboss3.2.8 f ports/110768[UPDATE]java/jboss4:fix some FATAL error noticed by po o ports/110932[NEW PORT]geronimo:open source j2ee 5 application serv f ports/110943start-dccifd chowns /var/run to user dcc f ports/111012quagga's ripd does not see ng interfaces f ports/51ports/lang/stklos: l/bin/stklos-install is a buggy she o ports/111224 ports [PATCH] security/pam_per_user conflicts with security/ f ports/111338graphics/yafray: doesn't respect CXX, CXXFLAGS and eve 23 problems total. Non-critical problems S Tracker Resp. Description s ports/59254 ports that write something after bsd.port.mk f ports/94073 [NEW PORTS] x11-toolkits/libsmokeqt, x11-toolkits/libs f ports/94074 [NEW PORTS] x11-toolkits/ruby-qt3, x11-toolkits/kde3: o ports/94921 isakmpd fails on amd64 s ports/96731 textproc/docbook-utils doesn`t build o ports/100896[new ports] emulators/vmware-server-guestd1 emulators/ o ports/101275bug fixed in sudo that prevented use in LDAP user acco o ports/103395security/gnome-ssh-askpass interferes with gnome-scree f ports/105277[UPDATE] mail/spamd - improvements and clean up f ports/105473ports/sysutils/cpdup -o doesn't work as advertised o ports/107354net/icmpinfo: icmpinfo -vvv does not recocnize any ICM f ports/107368audio/normalize: [patch] - normalize-mp3 and normalize f ports/107621net/proxychains doens't compile on 4 and 5 f ports/107937jailed net/isc-dhcp3-server wouldn't run with an immut f ports/108104print/hplip: documentation gets installed though NOPOR o ports/108595pstree (sysutils/psmisc) don't work in jail f ports/108723kxgenerator never worked for me f ports/108788[patch] sysutils/fusefs-kmod: Add BASE option f ports/108801www/mod_perl2: Apache-2.0.59 / mod_perl-2-2.0.3_1 freq f ports/108853Contradiction of CONFLICTS¡¡ f ports/109041security/tinyca doesn't allow for user installed OpenS f ports/109045security/xca compile fails: x509rev.cpp:63: error: inv o ports/109344restore .svn support to security/metasploit-devel f ports/109535Eggdrop SSL error o ports/110144
bsdtar and packages vs. unionfs (was: Re: Cannot package converters/libiconv inside clean chroot)
Tim Kientzle wrote:
There are at least two issues here, one is pkg_add refusing a valid
(AFAICS) tbz file, the other is bsdtar(1) choosing a different tar
format based on unionfs(!).
Those two symlink entries have an opaque file flag.
This explains the format change (bsdtar uses the extended
pax format when it sees a file with flags set, since
ustar can't store those).
I would guess that pkg_add is invoking bsdtar with
-p (restore permissions), bsdtar is restoring the
'opaque' flag, and then pkg_add is tripping over
those symlinks for some reason when it tries to
move them.
/usr/src/usr.sbin/pkg_install/add/extract.c:37: strcat(where_args,
|/usr/bin/tar --unlink -xpf - -C ); \
To test this hypothesis, try stripping those flags
with:
tar -cjf new-libiconv-1.9.2_2.tbz --format=ustar @libiconv-1.9.2_2.tbz
The new-libiconv tarfile should be identical except
it won't have the file flags stored. If pkg_add
likes new-libiconv but not libiconv, then it must
be those opaque flags.
Yes, using the trick above, pkg_add no longer complains. I can use this
as a temporary workaround. I think the real problem lies with bsdtar(1),
though. See below.
I don't know if this is a bug in unionfs, in pkg_add,
or in bsdtar. I think we need someone who understands
the 'opaque' flag to chime in here.
I was certain, that I tried to extract the broken package with the
exact same flags as pkg_add uses (--unlink -xpf) but it looks like I
messed something up, as _now_ I do see the same errors with bsdtar
itself.
roadrunner# rm -rf foo ; mkdir foo ; tar --unlink -xpvf libiconv-1.9.2_2.tbz -C
foo
x +CONTENTS
x +COMMENT
x +DESC
x +MTREE_DIRS
x man/man1/iconv.1.gz
x man/man3/iconv.3.gz
x man/man3/iconv_open.3.gz
x man/man3/iconv_close.3.gz
x bin/iconv
x include/iconv.h
x include/libcharset.h
x include/localcharset.h
x lib/libcharset.a
x lib/libcharset.la
x lib/libcharset.so: Couldn't stat file: No such file or directory
x lib/libcharset.so.1
x lib/libiconv.a
x lib/libiconv.la
x lib/libiconv.so: Couldn't stat file: No such file or directory
x lib/libiconv.so.3
x libdata/charset.alias
x share/doc/libiconv/iconv.1.html
x share/doc/libiconv/iconv.3.html
x share/doc/libiconv/iconv_close.3.html
x share/doc/libiconv/iconv_open.3.html
roadrunner# echo $?
1
roadrunner# find foo -exec ls -dlo {} \+
drwxr-xr-x 8 root wheel opaque 512 Apr 9 10:34 foo
-rw-r--r-- 1 root wheel - 35 Apr 9 09:47 foo/+COMMENT
-rw-r--r-- 1 root wheel - 2427 Apr 9 09:47 foo/+CONTENTS
-rw-r--r-- 1 root wheel - 676 Apr 9 09:47 foo/+DESC
-rwxr-xr-x 1 root wheel -15305 Apr 9 09:47 foo/+MTREE_DIRS
drwxr-xr-x 2 root wheel opaque 512 Apr 9 10:34 foo/bin
-r-xr-xr-x 1 root wheel - 7724 Apr 9 09:47 foo/bin/iconv
drwxr-xr-x 2 root wheel opaque 512 Apr 9 10:34 foo/include
-r--r--r-- 1 root wheel - 4760 Apr 9 09:47 foo/include/iconv.h
-r--r--r-- 1 root wheel - 1546 Apr 9 09:47 foo/include/libcharset.h
-r--r--r-- 1 root wheel - 1391 Apr 9 09:47
foo/include/localcharset.h
drwxr-xr-x 2 root wheel opaque 512 Apr 9 10:34 foo/lib
-rw-r--r-- 1 root wheel - 4256 Apr 9 09:47 foo/lib/libcharset.a
-r--r--r-- 1 root wheel - 807 Apr 9 09:47 foo/lib/libcharset.la
lrwxr-xr-x 1 root wheel - 15 Apr 9 09:47 foo/lib/libcharset.so -
libcharset.so.1
-r--r--r-- 1 root wheel - 8464 Apr 9 09:47 foo/lib/libcharset.so.1
-rw-r--r-- 1 root wheel - 998722 Apr 9 09:47 foo/lib/libiconv.a
-r--r--r-- 1 root wheel - 793 Apr 9 09:47 foo/lib/libiconv.la
lrwxr-xr-x 1 root wheel - 13 Apr 9 09:47 foo/lib/libiconv.so -
libiconv.so.3
-r--r--r-- 1 root wheel - 1002230 Apr 9 09:47 foo/lib/libiconv.so.3
drwxr-xr-x 2 root wheel opaque 512 Apr 9 10:34 foo/libdata
-r--r--r-- 1 root wheel - 641 Apr 9 09:47 foo/libdata/charset.alias
drwxr-xr-x 4 root wheel opaque 512 Apr 9 10:34 foo/man
drwxr-xr-x 2 root wheel opaque 512 Apr 9 10:34 foo/man/man1
-r--r--r-- 1 root wheel - 976 Apr 9 09:47 foo/man/man1/iconv.1.gz
drwxr-xr-x 2 root wheel opaque 512 Apr 9 10:34 foo/man/man3
-r--r--r-- 1 root wheel - 1457 Apr 9 09:47 foo/man/man3/iconv.3.gz
-r--r--r-- 1 root wheel - 653 Apr 9 09:47
foo/man/man3/iconv_close.3.gz
-r--r--r-- 1 root wheel - 2103 Apr 9 09:47
foo/man/man3/iconv_open.3.gz
drwxr-xr-x 3 root wheel opaque 512 Apr 9 10:34 foo/share
drwxr-xr-x 3 root wheel opaque 512 Apr 9 10:34 foo/share/doc
drwxr-xr-x 2 root wheel opaque 512 Apr 9 10:34 foo/share/doc/libiconv
-r--r--r-- 1 root wheel - 3473 Apr 9 09:47
foo/share/doc/libiconv/iconv.1.html
-r--r--r-- 1 root wheel - 8223 Apr 9 09:47
foo/share/doc/libiconv/iconv.3.html
-r--r--r-- 1 root wheel - 2384 Apr 9 09:47
foo/share/doc/libiconv/iconv_close.3.html
-r--r--r--
Re: PostgreSQL 8.x defaults
On Apr 9, 2007, at 5:46 AM, Palle Girgensohn wrote: About the two strategies you present; autovacuum will probably need some tweaking for most applications, since it will not perform vacuums unless a certain percentage of the tuples are changed. Hence, usually I use a combination of autovacuum and a nightly vacuumdb -za. For smaller installations, the vanilla setup could of course be either of your suggestions, or my just suggested combo, it is probably a matter of taste. I'd prefer you #1 or the combo... I'll think about it a bit more, and will fix the port. :) I think the port should not try to meddle with the postgresql.conf file *at all* and leave both vacuums off by default. The package installer needs to configure postgres, and part of that is to enable proper vacuum maintenance as per site policy. Having to undo work done by the port is not sensible. In short: leave the default status of the periodic script off, and do not try to enable autovacuum (I suppose if you ask the user at package install time, it would be ok to do so.) ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeMat 3.0 doesn't call functions and help
Alle 09:18, domenica 08 aprile 2007, Thierry Thomas ha scritto: Le Sam 7 avr 07 à 21:24:05 +0200, Vittorio De Martino .. I had forgotten about that, but I think that the first time I had launched FreeMat -i /usr/local/share/FreeMat-3.0 and then it uses QSettings to store this path persistently. . No, it still doesn't work. I launched what you suggested (see below) then again 'FreeMat' but when I ask for the Help on line nothing happens and the system answer as below (see QTextBrowser's lines) victor$ FreeMat -i /usr/local/share/FreeMat-3.0/ FreeMat root path set to '/usr/local/share/FreeMat-3.0/' victor$ FreeMat QTextBrowser: Cannot open 'file:///index.html' for reading QTextBrowser: No document for file:///index.html Ciao Vittorio P.S. By the way, launching FreeMat as root the Help on line works whilst inv still doesn't work. Ciao Vittorio ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: PostgreSQL 8.x defaults
Palle,
Thanks for listening to my thoughts and for your insight on why things
are set up they way they are -- I knew there must be a good reason :)
On Mon, Apr 09, 2007 at 11:46:50AM +0200, Palle Girgensohn wrote:
It does run vaccumdb -aqz per default, where -z is for analyze:
$ grep daily_pgsql_vacuum_args files/502.pgsql
daily_pgsql_vacuum_args=-z
su -l pgsql -c vacuumdb -a -q ${daily_pgsql_vacuum_args}
Ah, I missed the daily_pgsql_vacuum_args variable being set at the start
of the file!
About the two strategies you present; autovacuum will probably need
some tweaking for most applications, since it will not perform
vacuums unless a certain percentage of the tuples are changed. Hence,
usually I use a combination of autovacuum and a nightly vacuumdb -za.
Hmm, yes, thinking about it that way using both makes sense. In theory,
will running autovacuum lessen the impact of running the scheduled
VACUUM [ANALYZE] (because there is less work to do)?
For smaller installations, the vanilla setup could of course be
either of your suggestions, or my just suggested combo, it is
probably a matter of taste. I'd prefer you #1 or the combo... I'll
think about it a bit more, and will fix the port. :)
Now that I know there's a good reason for running both it seems to me
that the combo is a sane default. The only objection I can think of is
that ports typically default to being off -- i.e. you must explicitly
enable rc.d scripts in rc.conf, explicitly copy/symlink web apps into
your server's root directory, etc.
Thus, the periodic vacuum job that runs by default simply because the
port is installed, even if you don't enable PostgreSQL itself to run,
feels somewhat wrong. The impact is minimal -- an extra message in the
daily output complaining about being unable to connect -- so it's not
something that is critical.
I'm not sure of a good solution however. Do you think it would be
possible / reasonable for the periodic job to check if the user has set
postgresql_enable and do nothing if it is not enabled?
Craig
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: bsdtar and packages vs. unionfs
Ulrich Spoerlein wrote:
Tim Kientzle wrote:
The way I see it, bsdtar(1) extracts the symlink libcharset.so, and then
tries to stat(2) instead of lstat(2) it, before libcharset.so.1 is
extracted. The questions is: why?
Oh. I see. *That* old bug. sigh Try this patch:
Index: archive_read_extract.c
===
--- archive_read_extract.c (revision 177)
+++ archive_read_extract.c (working copy)
@@ -1243,7 +1243,7 @@
/* Already have stat() data available. */
} else if (fd = 0 fstat(fd, extract-st) == 0)
extract-pst = extract-st;
- else if (stat(name, extract-st) == 0)
+ else if (lstat(name, extract-st) == 0)
extract-pst = extract-st;
else {
archive_set_error(a, errno,
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to [EMAIL PROTECTED]
FreeBSD Port: netdisco-0.94
Hi Shaun, Wondering if there are any plans to update the NETDISCO port to 0.95 which came out last November? Thank you for maintaining this port. John ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: qemu: kqemu not compiled?
Juergen Lock wrote: In article [EMAIL PROTECTED] you write: -=-=-=-=-=- I've installed qemu 0.9 and kqemu 1.3, and I'm trying to run a i386 FreeBSD guest under amd64 FreeBSD host, but there's a problem: info kqemu command in qemu reports kqemu not compiled. But it should be - the KQEMU option is active on the port and the configure step in the port reports kqemu support: yes. Judging from the disk throughput in sysinstall (never going above e.g. 900 KB/s), it looks like it really isn't enabled. Any ideas? Use 64 bit qemu (qemu-system-x86_64) on 64 bit hosts if you want kqemu, like a real box it also runs 32 bit guests. (some still work better on 32 bit hosts tho...) Good advice, except that qemu-system-x86_64 locks up the machine hard, no autoreboot. signature.asc Description: OpenPGP digital signature
Re: x11/kdelibs3 revamp, add OPTIONS
El jueves 05 de abril a las 16:32:04 CEST, Dmitry Marakasov escribió: Hi! I'm one of those people who don't like extra dependencies, and I'm disappointed that, while it's required by many useful apps, x11/kdelibs3 does not provide options to disable obviously useless for many people functionality and, thus, additional depends (arts, libthai, fam, aspell, libidn etc.). I've created kdelibs3-lite port for myself, stripped of useless depends and I'm happy with it. But I wanted to know if it's worth to submit kdelibs3-lite as a PR, or maybe it's even possible to merge OPTIONS into kdelibs3 port (it could be improved even more. For example, kdelibs3-nocups support is rather ugly as it is). I would like to hear if there are more people who's for such a change, and general opinion of kde@ guys. Thanks. I agree. I only use konsole, but I have to compile and to install all the KDE in order to get it. A such port with OPTIONS will be wellcome for many people (the same applies to kdebase3). Regards -- http://www.telefonica.net/web2/gauss pgp6va8nEllHG.pgp Description: PGP signature
Re: qemu: kqemu not compiled?
On Mon, Apr 09, 2007 at 09:51:50PM +0200, Ivan Voras wrote: Juergen Lock wrote: In article [EMAIL PROTECTED] you write: -=-=-=-=-=- I've installed qemu 0.9 and kqemu 1.3, and I'm trying to run a i386 FreeBSD guest under amd64 FreeBSD host, but there's a problem: info kqemu command in qemu reports kqemu not compiled. But it should be - the KQEMU option is active on the port and the configure step in the port reports kqemu support: yes. Judging from the disk throughput in sysinstall (never going above e.g. 900 KB/s), it looks like it really isn't enabled. Any ideas? Use 64 bit qemu (qemu-system-x86_64) on 64 bit hosts if you want kqemu, like a real box it also runs 32 bit guests. (some still work better on 32 bit hosts tho...) Good advice, except that qemu-system-x86_64 locks up the machine hard, no autoreboot. Ouch! But only with kqemu I guess? Also, whats your guest and args to qemu-system-x86_64? Juergen ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
