Re: trying to fix a sed line
On Wed, Dec 16, 2009 at 04:54:09PM -0500, Chuck Robey wrote: > I don't do enough in sed if I could figure out what it is that the broken > line is TRYING to do, I think maybe I could fix it, I HAVE used sed before, > and > I know about the s command, and how it sets it's delimiters. Anyhow, here's > the > broken line, and I hope my mailer doesn't decide to break the line for me: > > REINPLACE_ARGS= -i.bak -E -e "1s,^(\#!.* )python$$,\1 -S PYTHONPATH=${DATADIR} > ${PYTHON_CMD},1" Inside "" we have 1s make a find replace in first line ^(\#!.* )python$$ Is a regexp matching what to be replaced: #!/usr/bin/env python In detail: ^ matches start of line () marks a group \#!.* matches /usr/bin/env (ending with a space) python matches python! $ matches end of line. I think this could be the error as the line only ends once \1 -S PYTHONPATH=${DATADIR} ${PYTHON_CMD} This is what the previous expression is replaced with: \1 puts what was in the group () from first regexp e.g. #!/usr/bin/env The rest is just to set the pythonpath before executing python. I have never seen this though and do not know if it will work Best regards Troels Kofoed Jacobsen chu...@telenix.org > > should be only a single space between ${DATADIR} and ${PYTHON_CMD}, my mailer > put a line break in there for me ... > > If you care, this came from editors/spe/Makefile. > ___ > freebsd-ports@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ports > To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org" ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: portupgrade failure
On Wed, Dec 16, 2009 at 11:13:36PM -0500, Robert Huff wrote: > The maintainer, ruby@, is aware of this; a check of the PR > database shows multiple open PRs, none critical but many serious > going back six months and more. As an aside, the Severity and Priority fields have been so often abused as to have become meaningless. Although I still try to groom the db for "critical" ones, and thus try to get those some attention, I really don't think the committers pay much attention. (In general I think those should be reserved for "data corruption" and "security".) The longer-term solution is to remove those as user-settable fields. > This hard to understand given portupgrade is the recommended upgrade > tool. Once the individual who was working on it gave it up to the mailing list, it became one of those "everyone is responsible so no one is responsible" problems. I don't have a recommended fix for this. Having said that, I have a ports tree as of a month ago and portupgrade was working ok for me. I don't have the cycles to go figure out where it fails to be able to fix it, sorry. mcl ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
portupgrade failure
Kevin writes: > I've been having this problem for a couple of months now, but I > just recently decided to try to fix it. I'm running FreeBSD 6.4, > and if I try to use portupgrade to upgrade something, I get an > error (seems to be the same for other ports): portupgrade (and -devel) have been broken, as you say, for several months. The maintainer, ruby@, is aware of this; a check of the PR database shows multiple open PRs, none critical but many serious going back six months and more. (see: "http://www.freebsd.org/cgi/query-pr-summary.cgi?category=ports&severity=&priority=&class=&state=&sort=none&text=portupgrade&responsible=&multitext=&originator=&release="; This hard to understand given portupgrade is the recommended upgrade tool. Robert Huff ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [REMOVE-PORT] net/plb
ok, I've marked it for deprecation early next year. In general it's best to file PRs for things like this, so it doesn't just get overlooked in all the mailing list traffic. Thanks. mcl ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Need help with a port
I'm the port maintainer for security/barnyard2. I submitted a port upgrade a while ago, but the committer asked me to make a change before he would approve it. I'm not sure what to do. The source code, when it's extracted, sets the perms on install-sh to r--r--r. This causes an error during the build. The way I tried to resolve the issue was by adding this to the Makefile: +pre-install: +${CHMOD} 744 ${WRKSRC}/install-sh + The committer said that was the wrong way to do it, that I should edit the configure file. But the configure file doesn't do anything to the install-sh file at all. Is there some other way to resolve this problem? I'd like to get this update completed and approved. This is the PR: http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/140393 Paul Schmehl, If it isn't already obvious, my opinions are my own and not those of my employer. ** WARNING: Check the headers before replying ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [Call for help] identify and fix libraries linked (erroneously) with libthr (that break php)
On Sat, Dec 12, 2009 at 12:30:35PM +0100, Alex Dupre wrote: > have patches). To fix coredumps we need to identify the ports that > install libraries erroneously linked with libthr, that are dependencies > of php extensions. To do this task you can run the following command: > > # ldd -av /usr/local/lib/php/20060613*/*.so ldd -a /usr/local/lib/php/20060613*/*.so | grep ^/usr | cut -f 1 -d | while read X; do if ldd $X | grep libthr.so.3 >/dev/null; then echo $X fi done | sort -u | while read X; do pkg_info -W $X done /usr/local/lib/libcrypto.so.5 was installed by package openssl-0.9.8l /usr/local/lib/libcurl.so.5 was installed by package curl-7.19.7 /usr/local/lib/libldap-2.4.so.7 was installed by package openldap-client-2.4.20 /usr/local/lib/libmhash.so.2 was installed by package mhash-0.9.9.9 /usr/local/lib/libssh2.so.1 was installed by package libssh2-1.2.2,2 /usr/local/lib/libssl.so.5 was installed by package openssl-0.9.8l /usr/local/lib/php/20060613/curl.so was installed by package php5-curl-5.2.11_1 /usr/local/lib/php/20060613/ftp.so was installed by package php5-ftp-5.2.11_1 /usr/local/lib/php/20060613/imap.so was installed by package php5-imap-5.2.11_1 /usr/local/lib/php/20060613/ldap.so was installed by package php5-ldap-5.2.11_1 /usr/local/lib/php/20060613/mhash.so was installed by package php5-mhash-5.2.11_1 /usr/local/lib/php/20060613/mysqli.so was installed by package php5-mysqli-5.2.11_1 /usr/local/lib/php/20060613/openssl.so was installed by package php5-openssl-5.2.11_1 /usr/local/lib/php/20060613/pdo_mysql.so was installed by package php5-pdo_mysql-5.2.11_1 > Thanks for cooperation. HTH Regards Raphael -- Raphael Beckerhttp://rabe.uugrn.org/ https://www.xing.com/profile/Raphael_Becker GnuPG:E7B2 1D66 3AF2 EDC7 9828 6D7A 9CDA 3E7B 10CA 9F2D .|.|.|.|.|.|.|.. pgpkFBDhurfmj.pgp Description: PGP signature
Re: FreeBSD Port: php5-mhash-5.2.11_1
On Wed, Dec 16, 2009 at 08:15:40PM -0600, Matt wrote: > > 7 libcrypto.so.5 => /usr/local/lib/libcrypto.so.5 > > 7 libssl.so.5 => /usr/local/lib/libssl.so.5 > > > > 7 out of 8 disabled extensions depend on libcrypto.so.5 and libssl.so.5 > > which come from openssl-0.9.8l > > > You might want to check out this thread: > http://lists.freebsd.org/pipermail/freebsd-ports/2009-December/058256.html Hmm, the list of libthr-affected modules is nearly the same: [r...@freebsd /usr/local/lib/php/20060613]# for SO in ./*.so ; do if ldd $SO | grep -i libthr >/dev/null; then echo $SO; fi ; done ./curl.so ./ftp.so ./imap.so ./ldap.so ./mhash.so <-- aha ./mysqli.so ./openssl.so ./pdo_mysql.so not found: ./mysql.so <-- aha Let's have a closer look on them: -- [r...@freebsd /usr/local/lib/php/20060613]# for SO in ./*.so ; do if ldd $SO | grep -i libthr >/dev/null then echo $SO; fi ; done | xargs ldd ./curl.so: libcurl.so.5 => /usr/local/lib/libcurl.so.5 (0x6819) libidn.so.16 => /usr/local/lib/libidn.so.16 (0x6830) libssh2.so.1 => /usr/local/lib/libssh2.so.1 (0x681d9000) libssl.so.5 => /usr/local/lib/libssl.so.5 (0x6833) libcrypto.so.5 => /usr/local/lib/libcrypto.so.5 (0x68374000) libz.so.4 => /lib/libz.so.4 (0x684c4000) libc.so.7 => /lib/libc.so.7 (0x6808) libintl.so.8 => /usr/local/lib/libintl.so.8 (0x684d6000) libiconv.so.3 => /usr/local/lib/libiconv.so.3 (0x684df000) libthr.so.3 => /lib/libthr.so.3 (0x685d5000) ./ftp.so: libssl.so.5 => /usr/local/lib/libssl.so.5 (0x6818d000) libcrypto.so.5 => /usr/local/lib/libcrypto.so.5 (0x6830) libc.so.7 => /lib/libc.so.7 (0x6808) libz.so.4 => /lib/libz.so.4 (0x681d1000) libthr.so.3 => /lib/libthr.so.3 (0x681e3000) ./imap.so: libssl.so.5 => /usr/local/lib/libssl.so.5 (0x68199000) libcrypto.so.5 => /usr/local/lib/libcrypto.so.5 (0x6830) libc-client4.so.9 => /usr/local/lib/libc-client4.so.9 (0x68447000) libcrypt.so.4 => /lib/libcrypt.so.4 (0x681dd000) libpam.so.4 => /usr/lib/libpam.so.4 (0x681f6000) libc.so.7 => /lib/libc.so.7 (0x6808) libz.so.4 => /lib/libz.so.4 (0x68548000) libthr.so.3 => /lib/libthr.so.3 (0x6855a000) ./ldap.so: libldap-2.4.so.7 => /usr/local/lib/libldap-2.4.so.7 (0x6818c000) liblber-2.4.so.7 => /usr/local/lib/liblber-2.4.so.7 (0x681c6000) libc.so.7 => /lib/libc.so.7 (0x6808) libssl.so.5 => /usr/local/lib/libssl.so.5 (0x6830) libcrypto.so.5 => /usr/local/lib/libcrypto.so.5 (0x68344000) libz.so.4 => /lib/libz.so.4 (0x681d2000) libthr.so.3 => /lib/libthr.so.3 (0x6848b000) ./mhash.so: libmhash.so.2 => /usr/local/lib/libmhash.so.2 (0x68185000) libc.so.7 => /lib/libc.so.7 (0x6808) libthr.so.3 => /lib/libthr.so.3 (0x681c7000) ./mysqli.so: libmysqlclient.so.15 => /usr/local/lib/mysql/libmysqlclient.so.15 (0x6819a000) libz.so.4 => /lib/libz.so.4 (0x6830) libcrypt.so.4 => /lib/libcrypt.so.4 (0x68312000) libm.so.5 => /lib/libm.so.5 (0x6832b000) libssl.so.5 => /usr/local/lib/libssl.so.5 (0x6834) libcrypto.so.5 => /usr/local/lib/libcrypto.so.5 (0x6838d000) libc.so.7 => /lib/libc.so.7 (0x6808) libthr.so.3 => /lib/libthr.so.3 (0x684d4000) ./openssl.so: libssl.so.5 => /usr/local/lib/libssl.so.5 (0x68196000) libcrypto.so.5 => /usr/local/lib/libcrypto.so.5 (0x6830) libc.so.7 => /lib/libc.so.7 (0x6808) libz.so.4 => /lib/libz.so.4 (0x681da000) libthr.so.3 => /lib/libthr.so.3 (0x68447000) ./pdo_mysql.so: libmysqlclient.so.15 => /usr/local/lib/mysql/libmysqlclient.so.15 (0x68189000) libz.so.4 => /lib/libz.so.4 (0x681ea000) libcrypt.so.4 => /lib/libcrypt.so.4 (0x6830) libm.so.5 => /lib/libm.so.5 (0x68319000) libssl.so.5 => /usr/local/lib/libssl.so.5 (0x6832e000) libcrypto.so.5 => /usr/local/lib/libcrypto.so.5 (0x6837b000) libc.so.7 => /lib/libc.so.7 (0x6808) libthr.so.3 => /lib/libthr.so.3 (0x684c2000) -- > Perhaps your issues are related. Maybe. I'll reply to the other message. Thanks Raphael -- Raphael Beckerhttp://rabe.uugrn.org/ https://www.xing.com/profile/Raphael_Becker GnuPG:E7B2 1D66 3AF2 EDC7 9828 6D7A 9CDA 3E7B 10CA 9F2D .|.|.|.|.|.|.|.. pgpJbRMXOFvID.pgp Description: PGP signature
Re: FreeBSD Port: php5-mhash-5.2.11_1
On Wed, Dec 16, 2009 at 07:40:17PM -0700, Janky Jay, III wrote: > I take this back. Removing "extension=mhash.so" from my > /usr/local/etc/php/extensions.ini file does, in fact, exit without a > core dump. However, mhash is required by SquirrelMail along with some of > its plugins. I'm unsure how this will effect SquirrelMail, but > regardless of where I place the mhash.so extension in the list, it still > core dumps (I've tried every possible position.) Same here with mhash > Regards, > Janky Jay, III Regards Raphael -- Raphael Beckerhttp://rabe.uugrn.org/ https://www.xing.com/profile/Raphael_Becker GnuPG:E7B2 1D66 3AF2 EDC7 9828 6D7A 9CDA 3E7B 10CA 9F2D .|.|.|.|.|.|.|.. pgpOXbW68LrGs.pgp Description: PGP signature
Re: FreeBSD Port: php5-mhash-5.2.11_1
Hello David, On Thu, Dec 17, 2009 at 01:06:28PM +1100, David N wrote: > Thats a long list of extensions, > > try adding one of them to the end of extensions.ini one by one. > The ordering of it matters, you need to re-arrange the order in which > the extensions are loaded. You may need to play around with it until > it stops core dumping. I re-enabled at the end of extensions.ini: extension=mysqli.so extension=pdo_mysql.so extension=curl.so extension=imap.so extension=ldap.so extension=ftp.so extension=openssl.so I wasn't still able to find a working location for extension=mhash.so ... coredumps regardless of any position in extensions.ini, from top to bottom. It's - again - kind of noticeable that all of this "complicated" modules are linkend against openssl: [r...@freebsd /usr/local/lib/php/20060613]# for SO in ./*.so ; do if ldd $SO | grep -i ssl >/dev/null; then echo $SO; fi ; done ./curl.so ./ftp.so ./imap.so ./ldap.so ./mysql.so ./mysqli.so ./openssl.so ./pdo_mysql.so ... hmm, ./mysql.so was inconspicuous before *strange* Lets have a closer look on all modules depending on *ssl*: [r...@freebsd /usr/local/lib/php/20060613]# for SO in ./*.so ; do if ldd $SO | grep -i ssl >/dev/null; t en echo $SO; fi ; done | xargs ldd --- ./curl.so: libcurl.so.5 => /usr/local/lib/libcurl.so.5 (0x6819) libidn.so.16 => /usr/local/lib/libidn.so.16 (0x6830) libssh2.so.1 => /usr/local/lib/libssh2.so.1 (0x681d9000) libssl.so.5 => /usr/local/lib/libssl.so.5 (0x6833) libcrypto.so.5 => /usr/local/lib/libcrypto.so.5 (0x68374000) libz.so.4 => /lib/libz.so.4 (0x684c4000) libc.so.7 => /lib/libc.so.7 (0x6808) libintl.so.8 => /usr/local/lib/libintl.so.8 (0x684d6000) libiconv.so.3 => /usr/local/lib/libiconv.so.3 (0x684df000) libthr.so.3 => /lib/libthr.so.3 (0x685d5000) ./ftp.so: libssl.so.5 => /usr/local/lib/libssl.so.5 (0x6818d000) libcrypto.so.5 => /usr/local/lib/libcrypto.so.5 (0x6830) libc.so.7 => /lib/libc.so.7 (0x6808) libz.so.4 => /lib/libz.so.4 (0x681d1000) libthr.so.3 => /lib/libthr.so.3 (0x681e3000) ./imap.so: libssl.so.5 => /usr/local/lib/libssl.so.5 (0x68199000) libcrypto.so.5 => /usr/local/lib/libcrypto.so.5 (0x6830) libc-client4.so.9 => /usr/local/lib/libc-client4.so.9 (0x68447000) libcrypt.so.4 => /lib/libcrypt.so.4 (0x681dd000) libpam.so.4 => /usr/lib/libpam.so.4 (0x681f6000) libc.so.7 => /lib/libc.so.7 (0x6808) libz.so.4 => /lib/libz.so.4 (0x68548000) libthr.so.3 => /lib/libthr.so.3 (0x6855a000) ./ldap.so: libldap-2.4.so.7 => /usr/local/lib/libldap-2.4.so.7 (0x6818c000) liblber-2.4.so.7 => /usr/local/lib/liblber-2.4.so.7 (0x681c6000) libc.so.7 => /lib/libc.so.7 (0x6808) libssl.so.5 => /usr/local/lib/libssl.so.5 (0x6830) libcrypto.so.5 => /usr/local/lib/libcrypto.so.5 (0x68344000) libz.so.4 => /lib/libz.so.4 (0x681d2000) libthr.so.3 => /lib/libthr.so.3 (0x6848b000) ./mysql.so: (***) libmysqlclient.so.15 => /usr/local/lib/mysql/libmysqlclient.so.15 (0x6818d000) libc.so.7 => /lib/libc.so.7 (0x6808) libcrypt.so.4 => /lib/libcrypt.so.4 (0x6830) libm.so.5 => /lib/libm.so.5 (0x68319000) libssl.so.5 => /usr/lib/libssl.so.5 (0x6832e000) libcrypto.so.5 => /lib/libcrypto.so.5 (0x6836f000) libz.so.4 => /lib/libz.so.4 (0x684c8000) ./mysqli.so: libmysqlclient.so.15 => /usr/local/lib/mysql/libmysqlclient.so.15 (0x6819a000) libz.so.4 => /lib/libz.so.4 (0x6830) libcrypt.so.4 => /lib/libcrypt.so.4 (0x68312000) libm.so.5 => /lib/libm.so.5 (0x6832b000) libssl.so.5 => /usr/local/lib/libssl.so.5 (0x6834) libcrypto.so.5 => /usr/local/lib/libcrypto.so.5 (0x6838d000) libc.so.7 => /lib/libc.so.7 (0x6808) libthr.so.3 => /lib/libthr.so.3 (0x684d4000) ./openssl.so: libssl.so.5 => /usr/local/lib/libssl.so.5 (0x68196000) libcrypto.so.5 => /usr/local/lib/libcrypto.so.5 (0x6830) libc.so.7 => /lib/libc.so.7 (0x6808) libz.so.4 => /lib/libz.so.4 (0x681da000) libthr.so.3 => /lib/libthr.so.3 (0x68447000) ./pdo_mysql.so: libmysqlclient.so.15 => /usr/local/lib/mysql/libmysqlclient.so.15 (0x68189000) libz.so.4 => /lib/libz.so.4 (0x681ea000) libcrypt.so.4 => /lib/libcrypt.so.4 (0x6830) libm.so.5 => /lib/libm.so.5 (0x68319000) libssl.so.5 => /usr/local/lib/libssl.so.5 (0x6832e000) libcrypto.so.5 => /usr/local/lib/libcrypto.so.5 (0x6837b000) libc.so.7 => /lib/libc.so.7 (0x6808) libthr.so.3 => /lib/libthr.so.3 (0x684c2000)
Re: FreeBSD Port: php5-mhash-5.2.11_1
On Wed, Dec 16, 2009 at 7:53 PM, Raphael Becker wrote: > > I disabled those: > #extension=openssl.so > #extension=pdo_mysql.so > #extension=ldap.so > #extension=imap.so > #extension=mhash.so > #extension=ftp.so > #extension=curl.so > #extension=mysqli.so > > > If i enable any of those php will segfault again! > > Looking at the referenced libraries from the ports (usr/local) shows a > hot candidate: > > [r...@freebsd ~]# for SO in $(grep ^[#] /usr/local/etc/php/extensions.ini | > cut -f 2 -d "="); do ldd /usr/local/lib/php/20060613/$SO; done | > grep usr/local | awk '{ print $1 " => " $3 ; }' | sort | uniq -c | sort -n > > [snip] > 2 libmysqlclient.so.15 => /usr/local/lib/mysql/libmysqlclient.so.15 > 7 libcrypto.so.5 => /usr/local/lib/libcrypto.so.5 > 7 libssl.so.5 => /usr/local/lib/libssl.so.5 > > 7 out of 8 disabled extensions depend on libcrypto.so.5 and libssl.so.5 > which come from openssl-0.9.8l > You might want to check out this thread: http://lists.freebsd.org/pipermail/freebsd-ports/2009-December/058256.html Perhaps your issues are related. Matt ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: FreeBSD Port: php5-mhash-5.2.11_1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi List, Janky Jay, III wrote: > Hi List, > > Raphael Becker wrote: >> On Wed, Dec 16, 2009 at 02:29:08PM -0800, Simon Shapiro wrote: >>> Hey, >>> I just updated ports on a few machines and the CLI version of php >>> dumps its core rather than end nicely. The mhash module appears to be >>> the trigger (an extensions.ini with only mhash causes failure, all >>> others minus mhash: no failure). >> php coredumps here too, but uncommenting mhash.so from extensions.ini >> doesn't change this. Diabling all modules will show no segfault. > >> It seems there is more than one defect .so from the following list: > >> perl.so radius.so fileinfo.so gettext.so pdf.so hash.so json.so >> sockets.so iconv.so mbstring.so bz2.so pcre.so posix.so ctype.so zlib.so >> calendar.so bcmath.so imap.so ldap.so ftp.so zip.so openssl.so >> session.so dba.so soap.so xml.so wddx.so xmlwriter.so simplexml.so >> readline.so mhash.so tokenizer.so curl.so filter.so exif.so mcrypt.so >> spl.so sqlite.so xmlrpc.so mysql.so mysqli.so gmp.so dom.so xmlreader.so >> pdo.so pcntl.so pdo_mysql.so gd.so xsl.so pdo_sqlite.so > >> Any idea? > > I'm having the same problem here. GDB doesn't seem to be much help as > it doesn't mention any of the extension.ini modules in the output. > However, all of this /DID/ happen after I updated textproc/libxml2. > Might have something to do with it. *shrugs* I'm playing with it now. > Below is the GDB output. > > # gdb `which php` php.core > > >Wed 16, 6:17PM > GNU gdb 6.1.1 [FreeBSD] > Copyright 2004 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you are > welcome to change it and/or distribute copies of it under certain > conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for details. > This GDB was configured as "i386-marcel-freebsd"...(no debugging symbols > found)... > Core was generated by `php'. > Program terminated with signal 11, Segmentation fault. > Reading symbols from /lib/libcrypt.so.4...(no debugging symbols > found)...done. > Loaded symbols for /lib/libcrypt.so.4 > Reading symbols from /lib/libm.so.5...(no debugging symbols found)...done. > Loaded symbols for /lib/libm.so.5 > Reading symbols from /usr/local/lib/libxml2.so.5...(no debugging symbols > found)...done. > Loaded symbols for /usr/local/lib/libxml2.so.5 > Reading symbols from /lib/libz.so.4...(no debugging symbols found)...done. > Loaded symbols for /lib/libz.so.4 > Reading symbols from /usr/local/lib/libiconv.so.3...(no debugging > symbols found)...done. > Loaded symbols for /usr/local/lib/libiconv.so.3 > Reading symbols from /lib/libc.so.7...(no debugging symbols found)...done. > Loaded symbols for /lib/libc.so.7 > Reading symbols from /libexec/ld-elf.so.1...(no debugging symbols > found)...done. > Loaded symbols for /libexec/ld-elf.so.1 > #0 0x28f79410 in ?? () > (gdb) bt > #0 0x28f79410 in ?? () > #1 0x285b75eb in pthread_once () from /lib/libc.so.7 > #2 0x28346162 in xmlIsMainThread () from /usr/local/lib/libxml2.so.5 > #3 0x28345717 in __xmlLastError () from /usr/local/lib/libxml2.so.5 > #4 0x282d1847 in xmlResetLastError () from /usr/local/lib/libxml2.so.5 > #5 0x282d88df in xmlCleanupParser () from /usr/local/lib/libxml2.so.5 > #6 0x080844eb in php_libxml_shutdown () > #7 0x0808451b in zm_shutdown_libxml () > #8 0x0814b49e in module_destructor () > #9 0x08151804 in zend_hash_apply_deleter () > #10 0x08151a48 in zend_hash_graceful_reverse_destroy () > #11 0x08147d1e in zend_shutdown () > #12 0x0810612f in php_module_shutdown () > #13 0x081c4100 in main () > (gdb) I take this back. Removing "extension=mhash.so" from my /usr/local/etc/php/extensions.ini file does, in fact, exit without a core dump. However, mhash is required by SquirrelMail along with some of its plugins. I'm unsure how this will effect SquirrelMail, but regardless of where I place the mhash.so extension in the list, it still core dumps (I've tried every possible position.) Regards, Janky Jay, III -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkspmhEACgkQGK3MsUbJZn5lHgCbBvHqMlZ0djwxkdC1dvs5yBQ3 cIUAn3ZS4S5ad609JNI3qgQWeK4w5iym =2XqW -END PGP SIGNATURE- ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: FreeBSD Port: php5-mhash-5.2.11_1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi List, Raphael Becker wrote: > On Wed, Dec 16, 2009 at 02:29:08PM -0800, Simon Shapiro wrote: >> Hey, >> I just updated ports on a few machines and the CLI version of php >> dumps its core rather than end nicely. The mhash module appears to be >> the trigger (an extensions.ini with only mhash causes failure, all >> others minus mhash: no failure). > > php coredumps here too, but uncommenting mhash.so from extensions.ini > doesn't change this. Diabling all modules will show no segfault. > > It seems there is more than one defect .so from the following list: > > perl.so radius.so fileinfo.so gettext.so pdf.so hash.so json.so > sockets.so iconv.so mbstring.so bz2.so pcre.so posix.so ctype.so zlib.so > calendar.so bcmath.so imap.so ldap.so ftp.so zip.so openssl.so > session.so dba.so soap.so xml.so wddx.so xmlwriter.so simplexml.so > readline.so mhash.so tokenizer.so curl.so filter.so exif.so mcrypt.so > spl.so sqlite.so xmlrpc.so mysql.so mysqli.so gmp.so dom.so xmlreader.so > pdo.so pcntl.so pdo_mysql.so gd.so xsl.so pdo_sqlite.so > > Any idea? I'm having the same problem here. GDB doesn't seem to be much help as it doesn't mention any of the extension.ini modules in the output. However, all of this /DID/ happen after I updated textproc/libxml2. Might have something to do with it. *shrugs* I'm playing with it now. Below is the GDB output. # gdb `which php` php.core Wed 16, 6:17PM GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-marcel-freebsd"...(no debugging symbols found)... Core was generated by `php'. Program terminated with signal 11, Segmentation fault. Reading symbols from /lib/libcrypt.so.4...(no debugging symbols found)...done. Loaded symbols for /lib/libcrypt.so.4 Reading symbols from /lib/libm.so.5...(no debugging symbols found)...done. Loaded symbols for /lib/libm.so.5 Reading symbols from /usr/local/lib/libxml2.so.5...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libxml2.so.5 Reading symbols from /lib/libz.so.4...(no debugging symbols found)...done. Loaded symbols for /lib/libz.so.4 Reading symbols from /usr/local/lib/libiconv.so.3...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libiconv.so.3 Reading symbols from /lib/libc.so.7...(no debugging symbols found)...done. Loaded symbols for /lib/libc.so.7 Reading symbols from /libexec/ld-elf.so.1...(no debugging symbols found)...done. Loaded symbols for /libexec/ld-elf.so.1 #0 0x28f79410 in ?? () (gdb) bt #0 0x28f79410 in ?? () #1 0x285b75eb in pthread_once () from /lib/libc.so.7 #2 0x28346162 in xmlIsMainThread () from /usr/local/lib/libxml2.so.5 #3 0x28345717 in __xmlLastError () from /usr/local/lib/libxml2.so.5 #4 0x282d1847 in xmlResetLastError () from /usr/local/lib/libxml2.so.5 #5 0x282d88df in xmlCleanupParser () from /usr/local/lib/libxml2.so.5 #6 0x080844eb in php_libxml_shutdown () #7 0x0808451b in zm_shutdown_libxml () #8 0x0814b49e in module_destructor () #9 0x08151804 in zend_hash_apply_deleter () #10 0x08151a48 in zend_hash_graceful_reverse_destroy () #11 0x08147d1e in zend_shutdown () #12 0x0810612f in php_module_shutdown () #13 0x081c4100 in main () (gdb) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAksplV8ACgkQGK3MsUbJZn4JFwCdG+4M55KK2bR+vLRUpad97laQ MAEAnjT15UEyBVNw78TjLLqKAvIAulf7 =nRng -END PGP SIGNATURE- ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: FreeBSD Port: php5-mhash-5.2.11_1
2009/12/17 Raphael Becker : > On Wed, Dec 16, 2009 at 02:29:08PM -0800, Simon Shapiro wrote: >> Hey, >> I just updated ports on a few machines and the CLI version of php >> dumps its core rather than end nicely. The mhash module appears to be >> the trigger (an extensions.ini with only mhash causes failure, all >> others minus mhash: no failure). >> >> Same outcome on various machines, running 7.1 and 7.2, i386 and amd64. > > Actually I have those modules enabled in extensions.ini, php doesn't > segfault: > extension=perl.so > extension=radius.so > extension=fileinfo.so > extension=calendar.so > extension=dba.so > extension=readline.so > extension=pcntl.so > extension=pdo.so > extension=hash.so > extension=sockets.so > extension=mbstring.so > extension=json.so > extension=iconv.so > extension=xmlwriter.so > extension=bz2.so > extension=mcrypt.so > extension=gettext.so > extension=pcre.so > extension=filter.so > extension=zlib.so > extension=bcmath.so > extension=gmp.so > extension=ctype.so > extension=xml.so > extension=zip.so > extension=gd.so > extension=xmlrpc.so > extension=exif.so > extension=simplexml.so > extension=pdo_sqlite.so > extension=spl.so > extension=posix.so > extension=sqlite.so > extension=session.so > extension=wddx.so > extension=tokenizer.so > extension=soap.so > extension=mysql.so > extension=dom.so > extension=xmlreader.so > extension=pdf.so > extension=xsl.so > > > I disabled those: > #extension=openssl.so > #extension=pdo_mysql.so > #extension=ldap.so > #extension=imap.so > #extension=mhash.so > #extension=ftp.so > #extension=curl.so > #extension=mysqli.so > > > If i enable any of those php will segfault again! > > Looking at the referenced libraries from the ports (usr/local) shows a > hot candidate: > > [r...@freebsd ~]# for SO in $(grep ^[#] /usr/local/etc/php/extensions.ini | > cut -f 2 -d "="); do ldd /usr/local/lib/php/20060613/$SO; done | > grep usr/local | awk '{ print $1 " => " $3 ; }' | sort | uniq -c | sort -n > > [snip] > 2 libmysqlclient.so.15 => /usr/local/lib/mysql/libmysqlclient.so.15 > 7 libcrypto.so.5 => /usr/local/lib/libcrypto.so.5 > 7 libssl.so.5 => /usr/local/lib/libssl.so.5 > > 7 out of 8 disabled extensions depend on libcrypto.so.5 and libssl.so.5 > which come from openssl-0.9.8l > > > > Checking the enabled ones for "(libcrypto.so.5|libssl.so.5)" > > [r...@freebsd ~]# for SO in $(grep ^[^#] /usr/local/etc/php/extensions.ini | > cut -f 2 -d "="); do ldd /usr/local/lib/php/20060613/$SO; done | > grep usr/local | awk '{ print $1 " => " $3 ; }' | sort | uniq -c | sort -n | > egrep -c "(libcrypto.so.5|libssl.so.5)" > 0 > > --> no one of the enabled extensions are linked to libcrypto.so.5 or > libssl.so.5 > > I'd say there's something wrong with php-extensions linked to openssl-0.9.8l > I don't know a solution for this yet, I recompiled practically every > dependency of php5-* > > I'd need some advise how to solve this, maybe any additional testing. > > Regards > Raphael > > -- > Raphael Becker http://rabe.uugrn.org/ > https://www.xing.com/profile/Raphael_Becker > GnuPG: E7B2 1D66 3AF2 EDC7 9828 6D7A 9CDA 3E7B 10CA 9F2D > .|.|.|.|.|.|.|.. > Thats a long list of extensions, try adding one of them to the end of extensions.ini one by one. The ordering of it matters, you need to re-arrange the order in which the extensions are loaded. You may need to play around with it until it stops core dumping. Regards David N ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: FreeBSD Port: php5-mhash-5.2.11_1
On Wed, Dec 16, 2009 at 02:29:08PM -0800, Simon Shapiro wrote: > Hey, > I just updated ports on a few machines and the CLI version of php > dumps its core rather than end nicely. The mhash module appears to be > the trigger (an extensions.ini with only mhash causes failure, all > others minus mhash: no failure). > > Same outcome on various machines, running 7.1 and 7.2, i386 and amd64. Actually I have those modules enabled in extensions.ini, php doesn't segfault: extension=perl.so extension=radius.so extension=fileinfo.so extension=calendar.so extension=dba.so extension=readline.so extension=pcntl.so extension=pdo.so extension=hash.so extension=sockets.so extension=mbstring.so extension=json.so extension=iconv.so extension=xmlwriter.so extension=bz2.so extension=mcrypt.so extension=gettext.so extension=pcre.so extension=filter.so extension=zlib.so extension=bcmath.so extension=gmp.so extension=ctype.so extension=xml.so extension=zip.so extension=gd.so extension=xmlrpc.so extension=exif.so extension=simplexml.so extension=pdo_sqlite.so extension=spl.so extension=posix.so extension=sqlite.so extension=session.so extension=wddx.so extension=tokenizer.so extension=soap.so extension=mysql.so extension=dom.so extension=xmlreader.so extension=pdf.so extension=xsl.so I disabled those: #extension=openssl.so #extension=pdo_mysql.so #extension=ldap.so #extension=imap.so #extension=mhash.so #extension=ftp.so #extension=curl.so #extension=mysqli.so If i enable any of those php will segfault again! Looking at the referenced libraries from the ports (usr/local) shows a hot candidate: [r...@freebsd ~]# for SO in $(grep ^[#] /usr/local/etc/php/extensions.ini | cut -f 2 -d "="); do ldd /usr/local/lib/php/20060613/$SO; done | grep usr/local | awk '{ print $1 " => " $3 ; }' | sort | uniq -c | sort -n [snip] 2 libmysqlclient.so.15 => /usr/local/lib/mysql/libmysqlclient.so.15 7 libcrypto.so.5 => /usr/local/lib/libcrypto.so.5 7 libssl.so.5 => /usr/local/lib/libssl.so.5 7 out of 8 disabled extensions depend on libcrypto.so.5 and libssl.so.5 which come from openssl-0.9.8l Checking the enabled ones for "(libcrypto.so.5|libssl.so.5)" [r...@freebsd ~]# for SO in $(grep ^[^#] /usr/local/etc/php/extensions.ini | cut -f 2 -d "="); do ldd /usr/local/lib/php/20060613/$SO; done | grep usr/local | awk '{ print $1 " => " $3 ; }' | sort | uniq -c | sort -n | egrep -c "(libcrypto.so.5|libssl.so.5)" 0 --> no one of the enabled extensions are linked to libcrypto.so.5 or libssl.so.5 I'd say there's something wrong with php-extensions linked to openssl-0.9.8l I don't know a solution for this yet, I recompiled practically every dependency of php5-* I'd need some advise how to solve this, maybe any additional testing. Regards Raphael -- Raphael Beckerhttp://rabe.uugrn.org/ https://www.xing.com/profile/Raphael_Becker GnuPG:E7B2 1D66 3AF2 EDC7 9828 6D7A 9CDA 3E7B 10CA 9F2D .|.|.|.|.|.|.|.. pgpAfCOkH39Vo.pgp Description: PGP signature
Re: net-im/ejabberd 2.0.5 to 2.1.0
On 16.12.2009 15:44, Guy Brand wrote: The port builds and installs properly under 7.1-RELEASE/amd64/R13B02 and 9-CURRENT/amd64/R13B03. pkg_info does not complain at all. That said portlint shows a few warnings which certainly need to be fixed. I've corrected some errors it found, however: WARN: Makefile: only one MASTER_SITE configured. Consider adding additional mirrors. WARN: /basejail/usr/ports/net-im/ejabberd2/pkg-deinstall: possible use of absolute pathname "/var/run/ejabberd". WARN: /basejail/usr/ports/net-im/ejabberd2/pkg-deinstall: possible use of absolute pathname "/var/spool/ejabberd". ejabberd doesn't have mirror sites so it's not quite possible to add some. I can, though, host the file on my own server if that's allowed. About absolute pathnames, how should a port refer to /var/spool and /var/run? -- Kamigishi Rei KREI-RIPE http://fujibayashi.jp ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: FreeBSD Port: php5-mhash-5.2.11_1
2009/12/17 Raphael Becker : > On Wed, Dec 16, 2009 at 02:29:08PM -0800, Simon Shapiro wrote: >> Hey, >> I just updated ports on a few machines and the CLI version of php >> dumps its core rather than end nicely. The mhash module appears to be >> the trigger (an extensions.ini with only mhash causes failure, all >> others minus mhash: no failure). > > php coredumps here too, but uncommenting mhash.so from extensions.ini > doesn't change this. Diabling all modules will show no segfault. > > It seems there is more than one defect .so from the following list: > > perl.so radius.so fileinfo.so gettext.so pdf.so hash.so json.so > sockets.so iconv.so mbstring.so bz2.so pcre.so posix.so ctype.so zlib.so > calendar.so bcmath.so imap.so ldap.so ftp.so zip.so openssl.so > session.so dba.so soap.so xml.so wddx.so xmlwriter.so simplexml.so > readline.so mhash.so tokenizer.so curl.so filter.so exif.so mcrypt.so > spl.so sqlite.so xmlrpc.so mysql.so mysqli.so gmp.so dom.so xmlreader.so > pdo.so pcntl.so pdo_mysql.so gd.so xsl.so pdo_sqlite.so > > Any idea? > > Regards > Raphael > > -- > Raphael Becker http://rabe.uugrn.org/ > https://www.xing.com/profile/Raphael_Becker > GnuPG: E7B2 1D66 3AF2 EDC7 9828 6D7A 9CDA 3E7B 10CA 9F2D > .|.|.|.|.|.|.|.. > Hi, This is one of PHP's quirks, you need to load the extensions in the right order, or it'll crash in CGI/FCGI mode and others. I have mine in this order extension=session.so extension=bcmath.so extension=ctype.so extension=pcre.so extension=simplexml.so extension=spl.so extension=dom.so extension=filter.so extension=hash.so extension=iconv.so extension=json.so extension=ldap.so extension=posix.so extension=soap.so extension=tokenizer.so extension=xml.so extension=xmlreader.so extension=xmlwriter.so extension=zip.so extension=zlib.so extension=pdo.so extension=pdo_sqlite.so extension=pgsql.so extension=imap.so extension=sockets.so extension=gd.so extension=curl.so I got it from a website, but i can't find it. Although it doesn't have the mhash module, you might try moving up or down the list to see when it doesn't crash. Regards David N ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: FreeBSD Port: php5-mhash-5.2.11_1
On Wed, Dec 16, 2009 at 02:29:08PM -0800, Simon Shapiro wrote: > Hey, > I just updated ports on a few machines and the CLI version of php > dumps its core rather than end nicely. The mhash module appears to be > the trigger (an extensions.ini with only mhash causes failure, all > others minus mhash: no failure). php coredumps here too, but uncommenting mhash.so from extensions.ini doesn't change this. Diabling all modules will show no segfault. It seems there is more than one defect .so from the following list: perl.so radius.so fileinfo.so gettext.so pdf.so hash.so json.so sockets.so iconv.so mbstring.so bz2.so pcre.so posix.so ctype.so zlib.so calendar.so bcmath.so imap.so ldap.so ftp.so zip.so openssl.so session.so dba.so soap.so xml.so wddx.so xmlwriter.so simplexml.so readline.so mhash.so tokenizer.so curl.so filter.so exif.so mcrypt.so spl.so sqlite.so xmlrpc.so mysql.so mysqli.so gmp.so dom.so xmlreader.so pdo.so pcntl.so pdo_mysql.so gd.so xsl.so pdo_sqlite.so Any idea? Regards Raphael -- Raphael Beckerhttp://rabe.uugrn.org/ https://www.xing.com/profile/Raphael_Becker GnuPG:E7B2 1D66 3AF2 EDC7 9828 6D7A 9CDA 3E7B 10CA 9F2D .|.|.|.|.|.|.|.. pgpW0YQv2uo3w.pgp Description: PGP signature
[REMOVE-PORT] net/plb
I wrote to the author of net/plb concerning its recent breakage due to the upgrade of devel/libevent. His reply is attached. net/plb has no MAINTAINER, is no longer maintained upstream, and is broken. I believe this port should be removed. Mr. Denis suggests www/nginx or net/relayd as a replacement. I think that net/relayd is closer in function to net/plb, as www/nginx is primarily a web server. -- John D. "Trix" Farrar, CCNA __\\|//__ Basement.NET t...@basement.net (` o-o ') http://www.basement.net/ ---ooO-(_)-Ooo-- GPG Key Fprint: 525F DBA7 1A62 E4C4 E642 DF95 384B B851 3CEF C10A --- Begin Message --- Hello, Ouch no, PLB hasn't been maintained for years as it has become totally useless with projects like Nginx and Relayd. I'm not even sure that it ever worked on FreeBSD (beyond the compilation stage). So, please consider an alternative :) Best regards, -Frank. Le 16 déc. 2009 à 19:40, Trix Farrar a écrit : > It appears that libevent was recently upgraded from 1.4.12 to 1.4.13 > in the FreeBSD Ports Collection. The currently available version of > plb does not compile with the new version of libeevent. > > It also appears that plb is no longer available from > http://plb.sunsite.dk/. Is there a new site from which it can be > downloaded? > > I looked on the ProFTPd site, but didn't find a reference to plb. Is > this still an active project? > > -- > John D. "Trix" Farrar, CCNA __\\|//__ Basement.NET > t...@basement.net (` o-o ') http://www.basement.net/ > ---ooO-(_)-Ooo-- > GPG Key Fprint: 525F DBA7 1A62 E4C4 E642 DF95 384B B851 3CEF C10A --- End Message --- pgpIPPQOt6uxq.pgp Description: PGP signature
FreeBSD Port: php5-mhash-5.2.11_1
Hey, I just updated ports on a few machines and the CLI version of php dumps its core rather than end nicely. The mhash module appears to be the trigger (an extensions.ini with only mhash causes failure, all others minus mhash: no failure). Same outcome on various machines, running 7.1 and 7.2, i386 and amd64. # php -v PHP 5.2.11 with Suhosin-Patch 0.9.7 (cli) (built: Oct 17 2009 11:08:05) Copyright (c) 1997-2009 The PHP Group Zend Engine v2.2.0, Copyright (c) 1998-2009 Zend Technologies with eAccelerator v0.9.5.3, Copyright (c) 2004-2006 eAccelerator, by eAccelerator Segmentation fault (core dumped) Note: the scripts seem to run, just dump rather than end nicely. I did not test the mhash function. -Simon Shapiro ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: trying to fix a sed line
Chuck Robey wrote: I don't do enough in sed if I could figure out what it is that the broken line is TRYING to do, I think maybe I could fix it, I HAVE used sed before, and I know about the s command, and how it sets it's delimiters. Anyhow, here's the broken line, and I hope my mailer doesn't decide to break the line for me: REINPLACE_ARGS= -i.bak -E -e "1s,^(\#!.* )python$$,\1 -S PYTHONPATH=${DATADIR} ${PYTHON_CMD},1" should be only a single space between ${DATADIR} and ${PYTHON_CMD}, my mailer put a line break in there for me ... If you care, this came from editors/spe/Makefile. Missing space between the -i and the extension? -- Sean McAfee Senior Systems Engineer ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
trying to fix a sed line
I don't do enough in sed if I could figure out what it is that the broken line is TRYING to do, I think maybe I could fix it, I HAVE used sed before, and I know about the s command, and how it sets it's delimiters. Anyhow, here's the broken line, and I hope my mailer doesn't decide to break the line for me: REINPLACE_ARGS= -i.bak -E -e "1s,^(\#!.* )python$$,\1 -S PYTHONPATH=${DATADIR} ${PYTHON_CMD},1" should be only a single space between ${DATADIR} and ${PYTHON_CMD}, my mailer put a line break in there for me ... If you care, this came from editors/spe/Makefile. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: net-im/ejabberd 2.0.5 to 2.1.0
Kamigishi Rei (spam...@haruhiism.net) on 15/12/2009 at 22:18 wrote: Hello, > http://media.fujibayashi.jp/software/ejabberd2-port.tar.gz (available as > a hyperlink in that post, too) for the port directory. > Please also check if you get any warning from pkg_info after the > installation, too - I'm afraid there might be something about the > dependencies line. The port builds and installs properly under 7.1-RELEASE/amd64/R13B02 and 9-CURRENT/amd64/R13B03. pkg_info does not complain at all. That said portlint shows a few warnings which certainly need to be fixed. Thanks for your work gb ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: New version of the fakeroot patch
> I don't know if this should be a port setting. I think this should be > a user setting. So, I think WITH_FAKE / WITH_FAKEROOT is a better > choice. Obviously ports not working with fakeroot would have to define > something like IGNORE_FAKEROOT, the same kind of variable we have for > MAKE_JOBS. > I note this and will make the modifications to do that. (next patch should be next year) > > I'm thinking files could be moved from the fakeroot directory instead > of copied, that way you could run 'find ${FAKEDIR} ! -type d' and find > out if you've missed anything. > I have to think about this, but yes that could be the right thing to do. > > On pointyhat, a package will be generated at the end regardless. Also, > quite a lot of tools do make a package backup before deinstalling, so > I don't see this as a major issue. If people don't like the I/O > overhead, we could use pkg_add in slave mode, it will skip the package > building phase. > I agree with that > > As I mentioned it before, I think it's a very valuable feature to have. > > -- > Florent Thoumie > f...@freebsd.org > FreeBSD Committer > Thanks for your feedback, I'll send a new version of the patch soon. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: New version of the fakeroot patch
On Mon, Dec 14, 2009 at 3:13 PM, Baptiste Daroussin wrote: > Hi all, > > I have updated the fakeroot patch, it now can apply on an uptodate version of > the ports. > > http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/133815 > > For information the fakeroot patch is a port of the midnightbsd's mports > fakeroot > to freebsd's ports. > > What it does: > - it is optional: you can activate it globally with USE_FAKE=yes in > /etc/make.conf or per ports by adding USE_FAKE=yes in the ports Makefile I don't know if this should be a port setting. I think this should be a user setting. So, I think WITH_FAKE / WITH_FAKEROOT is a better choice. Obviously ports not working with fakeroot would have to define something like IGNORE_FAKEROOT, the same kind of variable we have for MAKE_JOBS. > - it create a fakeroot directory in the WRKDIR where all the binary are > installed first > > - then it creates a package using the plist and finding its files only in the > fakeroot directory > > - in the end it installs the created packages > > - it respects the DESTDIR implementation (it is not the same kind of feature > nor > the same goal) > > - it does not require any modification on actual ports (except for those which > are already not clean) but will allow to cleanup some ports if wanted. > > Why this patch: > - it prevents installing crufts thing on users systems (only what is found in > the plist is really installed, so the package is always clean) > > I now that porters should take care of not breaking the plist, but it often > happens, helping them by a system that completly use the plist file is IMHO a > better thing, and it prevents users from being inpacted by a lazy porter. > > - it allow to create tinderbox that does not need to install a ports to get > the > package build, only build-depends ports will be installed > > - it allow easier handling of NOPORTDOCS, NOPORTEXAMPLES and so on, because it > creates the packages first using plist to know which files should be > packaged, > the porter should only take care of one case, the case everything is > installed, then he adapts the plists to have or not some files depending on > the options the user have. > > This should cleanup a lot some ports, and should easier the respectness of > some porting guidelines > > What could be done: > because it generates packages first we could imagine some lint programs that > analyse the package content to test that it respects some of the freebsd > recommandation for packages (usefull for porters), it could help the > validation > of new/update ports submission and help preventting commiting buggy stuff. I'm thinking files could be moved from the fakeroot directory instead of copied, that way you could run 'find ${FAKEDIR} ! -type d' and find out if you've missed anything. > Limitation: > this path (currently activable on depend) add from disk usage than the way > ports > actually works: > > without the patch: > build -> copy on the filesystem > with the path: > build -> copy-on-fakeroot->package_building->package-installing > > In the future it could be improved by provinding a version of pkg_create that > fake the package creation by directly install on FS so that could become > build->copy-on-fakeroot->package-installing On pointyhat, a package will be generated at the end regardless. Also, quite a lot of tools do make a package backup before deinstalling, so I don't see this as a major issue. If people don't like the I/O overhead, we could use pkg_add in slave mode, it will skip the package building phase. > This patch is not yet complete, it should work with classical ports that use > gmake or make and with python, I have only done that currenly as a proof of > concept. > > Tell me if you think that this patch could be interesting or not As I mentioned it before, I think it's a very valuable feature to have. -- Florent Thoumie f...@freebsd.org FreeBSD Committer ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: New version of the fakeroot patch
Hi, Warren Block wrote: A suggestion: USE_FAKE is not descriptive. It doesn't tell what is fake or what happens. I'm not sure fake is the even the right word. USE_FAKEROOT is better, but still ambiguous: it's not really fake, and "root" can mean too many things. I guess what I'm trying to say is consider a name that describes what is accomplished, not how it works. The Macports system offers a functionality analogous to the one described by the OP. In Macports' Guide this functionality is described so: «Understanding the destroot phase is critical to understanding MacPorts, because, unlike some port systems, MacPorts "stages" an installation into an intermediate location —not the final file destination.» Maybe this can help to find a more explicit name than «fake». -- Cheers, Michaël ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"