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
Re: New version of the fakeroot patch
On Mon, Dec 14, 2009 at 3:13 PM, Baptiste Daroussin
baptiste.darous...@gmail.com 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
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: 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
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: 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
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: 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 Becker r...@uugrn.org http://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
Re: FreeBSD Port: php5-mhash-5.2.11_1
2009/12/17 Raphael Becker r...@uugrn.org: 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 r...@uugrn.org 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: 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
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 r...@uugrn.org http://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: FreeBSD Port: php5-mhash-5.2.11_1
2009/12/17 Raphael Becker r...@uugrn.org:
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 r...@uugrn.org 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
-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
-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
On Wed, Dec 16, 2009 at 7:53 PM, Raphael Becker r...@uugrn.org 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
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) --- All modules but mysql.so will load libssl.so.5 from
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 Becker r...@uugrn.org http://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
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 Becker r...@uugrn.org http://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: [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 Becker r...@uugrn.org http://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
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: [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
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=portsseverity=priority=class=state=sort=nonetext=portupgraderesponsible=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: 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
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
