Re: Thunderbird, enigmail, and GCC 3.4
Yuri Pankov wrote: AFAICT, it only affects amd64. Maybe USE_GCC can be 3.4 on amd64, and 3.4+ elsewhere? Don't know if it helps at all, but seamonkey works with enigmail very nice, using gcc version 4.2.1 20070719 on amd64 (7.0-PRERELEASE, seamonkey 1.1.8). --Marcin ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: interactive ports - the plague
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 On Tue, 4 Mar 2008 19:35:29 +0100 Jesper Louis Andersen [EMAIL PROTECTED] wrote: I am not sure it would solve the particular problem, but one could take a look at how NetBSDs pkgsrc build system copes with licenses in general: For each license type, there is a knob. The knob could normally be interactive, yielding the exact same behaviour as now. But if an appropriate ACCEPT_LICENSE_FOO=Yes is found in make.conf, then the user has read and accepted that particular license type once and for all. The purpose of this pkgsrc's mechanism is to segregate pieces of software that use various licences so that users have a better legal / / philosophical control over what is installed on their systems. This doesn't change anything if you have to go to the vendor's site, log in and accept the licence manually. The downside is that this requires a considerable amount of work and thought. What should happen when the license changes, for instance. Then port (or package, in pkgsrc terminology) maintainer changes the appropriate line in package's Makefile. If the license in question is a new one, its text is being added to the pkgsrc tree. (BTW, are/were there ideas of implementing something similar in Ports Collection?) - -- Nikola Lečić = Никола Лечић fingerprint : FEF3 66AF C90E EDC3 D878 7CDC 956D F4AB A377 1C9B -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4 (FreeBSD) iQCVAwUBR866xfzDP9K2CKGYAQORFwQAlWCXRRw7GgpydxvDtUPukhU+WkTQc+Xo FrypqJ90d6Pwip6D+jKWBqVnhQw65EJ6JmkLeYmkQnCe98/m9T7p0G20BofRHPcY rr2tgHbx3Dx29gpaXS2eNeQfuQOksnybvIbJAPW/pF9XpEzXFyzfjFjR6MD1gyF7 cLbayMeaPJ8= =mRjd -END PGP SIGNATURE- ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: interactive ports - the plague
On Wed, Mar 05, 2008 at 04:22:28PM +0100, Nikola Le??i?? wrote: -BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 On Tue, 4 Mar 2008 19:35:29 +0100 Jesper Louis Andersen [EMAIL PROTECTED] wrote: I am not sure it would solve the particular problem, but one could take a look at how NetBSDs pkgsrc build system copes with licenses in general: For each license type, there is a knob. The knob could normally be interactive, yielding the exact same behaviour as now. But if an appropriate ACCEPT_LICENSE_FOO=Yes is found in make.conf, then the user has read and accepted that particular license type once and for all. The purpose of this pkgsrc's mechanism is to segregate pieces of software that use various licences so that users have a better legal / / philosophical control over what is installed on their systems. This doesn't change anything if you have to go to the vendor's site, log in and accept the licence manually. The downside is that this requires a considerable amount of work and thought. What should happen when the license changes, for instance. Then port (or package, in pkgsrc terminology) maintainer changes the appropriate line in package's Makefile. If the license in question is a new one, its text is being added to the pkgsrc tree. (BTW, are/were there ideas of implementing something similar in Ports Collection?) I know there is a wiki page keeping track of ports which use GPL3 (not sure why, I have not kept up on what GPL3 means). If the reason for having this page is important enough - that is, more than curiosity - then some kind of analogous mechanism to what you describe may be a good idea. -- WXS ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: interactive ports - the plague
On Wed, Mar 05, 2008 at 11:30:44AM -0500, Wesley Shields wrote: On Wed, Mar 05, 2008 at 04:22:28PM +0100, Nikola Le??i?? wrote: -BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 On Tue, 4 Mar 2008 19:35:29 +0100 Jesper Louis Andersen [EMAIL PROTECTED] wrote: I am not sure it would solve the particular problem, but one could take a look at how NetBSDs pkgsrc build system copes with licenses in general: For each license type, there is a knob. The knob could normally be interactive, yielding the exact same behaviour as now. But if an appropriate ACCEPT_LICENSE_FOO=Yes is found in make.conf, then the user has read and accepted that particular license type once and for all. The purpose of this pkgsrc's mechanism is to segregate pieces of software that use various licences so that users have a better legal / / philosophical control over what is installed on their systems. This doesn't change anything if you have to go to the vendor's site, log in and accept the licence manually. The downside is that this requires a considerable amount of work and thought. What should happen when the license changes, for instance. Then port (or package, in pkgsrc terminology) maintainer changes the appropriate line in package's Makefile. If the license in question is a new one, its text is being added to the pkgsrc tree. (BTW, are/were there ideas of implementing something similar in Ports Collection?) I know there is a wiki page keeping track of ports which use GPL3 (not sure why, I have not kept up on what GPL3 means). If the reason for having this page is important enough - that is, more than curiosity - then some kind of analogous mechanism to what you describe may be a good idea. I was just informed that a port which is gpl2 _only_ can not be built into a package if it depends on a port which is gpl3. However, IANAL and have not done any research into this so don't take my word for it. I'm not sure how this is enforced other than asking maintainers to pay close attention to their ports and marking them as NO_PACKAGE accordingly. Maybe requiring explicit license information in the Makefile will have the added benefit of forcing maintainers to look at the license. -- WXS ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: interactive ports - the plague
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 On Wed, 5 Mar 2008 11:37:38 -0500 Wesley Shields [EMAIL PROTECTED] wrote: I was just informed that a port which is gpl2 _only_ can not be built into a package if it depends on a port which is gpl3. However, IANAL and have not done any research into this so don't take my word for it. (Yes, among other things. For example, that's why Claws-Mail recently cancelled ClamAV support and caused a lot of problems for some people...) I'm not sure how this is enforced other than asking maintainers to pay close attention to their ports and marking them as NO_PACKAGE accordingly. Maybe requiring explicit license information in the Makefile will have the added benefit of forcing maintainers to look at the license. Here: http://www.netbsd.org/docs/pkgsrc/fixes.html#handling-licenses IMHO the way pkgsrc people implemented it is both elegant and great. Maintainers are forced to pay particular attention to the licencing and to discuss it on the list if something's unclear. This means that some licences automatically imply something like NO_PACKAGE -- and this means that Ports Management has a better overview and control over this sensitive matter (just remember recent ion case). As explained here: (For those who want to take a look and to save some time, you download the current pkgsrc branch like this: setenv CVSROOT [EMAIL PROTECTED]:/cvsroot setenv CVS_RSH ssh cvs -q checkout -P pkgsrc See pkgsrc/licenses.) - -- Nikola Lečić = Никола Лечић fingerprint : FEF3 66AF C90E EDC3 D878 7CDC 956D F4AB A377 1C9B -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4 (FreeBSD) iQCVAwUBR87QS/zDP9K2CKGYAQNRJgP8Dt5PNkS3xLyddUVTdbkUmq06b7sOfN7z P+UqQppsloWd+qOoLoFaLeluDMq9Cih7bIB1NvHj036XfsTbtHWaMMGr/TVFNihc rwzOryUR8fX8FsQzXlFC5hl0PCLr7T6DJxsY9cJTqlohrvuUOUnDLJiaziLWXs5X pGXre8MofqQ= =6qsm -END PGP SIGNATURE- ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: interactive ports - the plague
On Wed, Mar 05, 2008 at 04:22:28PM +0100, Nikola Lečić wrote: (BTW, are/were there ideas of implementing something similar in Ports Collection?) Yes, I think we are at the point of needing to implement this. I hope we can use what pkgsrc has (the concepts if not the code); it sounds as though you've put in a great deal of work on it. mcl ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
new version of devel/pwlib does not compile on 7.0-RELEASE
Greetings, New version of devel/pwlib does not compile on 7.0-RELEASE i386 Here is the error msg: g++ -O1 -I/usr/ports/devel/pwlib/work/ptlib_v1_12_0/include -I/usr/local/include -D_REENTRANT -pthread -fno-exceptions -O1 -I/usr/ports/devel/pwlib/work/ptlib_v1_12_0/include -I/usr/local/include -Wall -g -D_DEBUG -I/usr/ports/devel/pwlib/work/ptlib_v1_12_0/include -O2 -fno-strict-aliasing -pipe -march=prescott -O1 -I/usr/ports/devel/pwlib/work/ptlib_v1_12_0/include -I/usr/local/include -O1 -I/usr/ports/devel/pwlib/work/ptlib_v1_12_0/include -I/usr/local/include -c ../../ptclib/podbc.cxx -o /usr/ports/devel/pwlib/work/ptlib_v1_12_0/lib/obj_d/podbc.o ../../ptclib/podbc.cxx:230: error: reference to 'BOOL' is ambiguous /usr/ports/devel/pwlib/work/ptlib_v1_12_0/include/ptlib/unix/ptlib/contain.h:135: error: candidates are: typedef int BOOL /usr/local/include/iodbcunix.h:136: error: typedef int PTODBC::BOOL ../../ptclib/podbc.cxx:230: error: reference to 'BOOL' is ambiguous /usr/ports/devel/pwlib/work/ptlib_v1_12_0/include/ptlib/unix/ptlib/contain.h:135: error: candidates are: typedef int BOOL /usr/local/include/iodbcunix.h:136: error: typedef int PTODBC::BOOL ../../ptclib/podbc.cxx:230: error: 'BOOL' does not name a type ../../ptclib/podbc.cxx:283: error: reference to 'BOOL' is ambiguous /usr/ports/devel/pwlib/work/ptlib_v1_12_0/include/ptlib/unix/ptlib/contain.h:135: error: candidates are: typedef int BOOL /usr/local/include/iodbcunix.h:136: error: typedef int PTODBC::BOOL ../../ptclib/podbc.cxx:283: error: reference to 'BOOL' is ambiguous /usr/ports/devel/pwlib/work/ptlib_v1_12_0/include/ptlib/unix/ptlib/contain.h:135: error: candidates are: typedef int BOOL /usr/local/include/iodbcunix.h:136: error: typedef int PTODBC::BOOL ../../ptclib/podbc.cxx:283: error: 'BOOL' does not name a type ../../ptclib/podbc.cxx:318: error: reference to 'BOOL' is ambiguous /usr/ports/devel/pwlib/work/ptlib_v1_12_0/include/ptlib/unix/ptlib/contain.h:135: error: candidates are: typedef int BOOL /usr/local/include/iodbcunix.h:136: error: typedef int PTODBC::BOOL ../../ptclib/podbc.cxx:318: error: reference to 'BOOL' is ambiguous /usr/ports/devel/pwlib/work/ptlib_v1_12_0/include/ptlib/unix/ptlib/contain.h:135: error: candidates are: typedef int BOOL /usr/local/include/iodbcunix.h:136: error: typedef int PTODBC::BOOL ../../ptclib/podbc.cxx:318: error: 'BOOL' does not name a type ../../ptclib/podbc.cxx:325: error: reference to 'BOOL' is ambiguous /usr/ports/devel/pwlib/work/ptlib_v1_12_0/include/ptlib/unix/ptlib/contain.h:135: error: candidates are: typedef int BOOL /usr/local/include/iodbcunix.h:136: error: typedef int PTODBC::BOOL ../../ptclib/podbc.cxx:325: error: reference to 'BOOL' is ambiguous /usr/ports/devel/pwlib/work/ptlib_v1_12_0/include/ptlib/unix/ptlib/contain.h:135: error: candidates are: typedef int BOOL /usr/local/include/iodbcunix.h:136: error: typedef int PTODBC::BOOL ../../ptclib/podbc.cxx:325: error: 'BOOL' does not name a type ../../ptclib/podbc.cxx:333: error: reference to 'BOOL' is ambiguous /usr/ports/devel/pwlib/work/ptlib_v1_12_0/include/ptlib/unix/ptlib/contain.h:135: error: candidates are: typedef int BOOL /usr/local/include/iodbcunix.h:136: error: typedef int PTODBC::BOOL ../../ptclib/podbc.cxx:333: error: reference to 'BOOL' is ambiguous /usr/ports/devel/pwlib/work/ptlib_v1_12_0/include/ptlib/unix/ptlib/contain.h:135: error: candidates are: typedef int BOOL /usr/local/include/iodbcunix.h:136: error: typedef int PTODBC::BOOL ../../ptclib/podbc.cxx:333: error: 'BOOL' does not name a type ../../ptclib/podbc.cxx:342: error: reference to 'BOOL' is ambiguous /usr/ports/devel/pwlib/work/ptlib_v1_12_0/include/ptlib/unix/ptlib/contain.h:135: error: candidates are: typedef int BOOL /usr/local/include/iodbcunix.h:136: error: typedef int PTODBC::BOOL ../../ptclib/podbc.cxx:342: error: reference to 'BOOL' is ambiguous /usr/ports/devel/pwlib/work/ptlib_v1_12_0/include/ptlib/unix/ptlib/contain.h:135: error: candidates are: typedef int BOOL /usr/local/include/iodbcunix.h:136: error: typedef int PTODBC::BOOL ../../ptclib/podbc.cxx:342: error: 'BOOL' does not name a type ../../ptclib/podbc.cxx:353: error: reference to 'BOOL' is ambiguous /usr/ports/devel/pwlib/work/ptlib_v1_12_0/include/ptlib/unix/ptlib/contain.h:135: error: candidates are: typedef int BOOL /usr/local/include/iodbcunix.h:136: error: typedef int PTODBC::BOOL ../../ptclib/podbc.cxx:353: error: reference to 'BOOL' is ambiguous /usr/ports/devel/pwlib/work/ptlib_v1_12_0/include/ptlib/unix/ptlib/contain.h:135: error: candidates are: typedef int BOOL /usr/local/include/iodbcunix.h:136: error: typedef int PTODBC::BOOL ../../ptclib/podbc.cxx:353: error: 'BOOL' does not name a type
Re: new version of devel/pwlib does not compile on 7.0-RELEASE
All of your errors seem to stem from: /usr/local/include/iodbcunix.h which isn't part of pwlib and doesn't exist on my system. -Steve Stefan Lambrev wrote: Greetings, New version of devel/pwlib does not compile on 7.0-RELEASE i386 Here is the error msg: g++ -O1 -I/usr/ports/devel/pwlib/work/ptlib_v1_12_0/include -I/usr/local/include -D_REENTRANT -pthread -fno-exceptions -O1 -I/usr/ports/devel/pwlib/work/ptlib_v1_12_0/include -I/usr/local/include -Wall -g -D_DEBUG -I/usr/ports/devel/pwlib/work/ptlib_v1_12_0/include -O2 -fno-strict-aliasing -pipe -march=prescott -O1 -I/usr/ports/devel/pwlib/work/ptlib_v1_12_0/include -I/usr/local/include -O1 -I/usr/ports/devel/pwlib/work/ptlib_v1_12_0/include -I/usr/local/include -c ../../ptclib/podbc.cxx -o /usr/ports/devel/pwlib/work/ptlib_v1_12_0/lib/obj_d/podbc.o ../../ptclib/podbc.cxx:230: error: reference to 'BOOL' is ambiguous /usr/ports/devel/pwlib/work/ptlib_v1_12_0/include/ptlib/unix/ptlib/contain.h:135: error: candidates are: typedef int BOOL /usr/local/include/iodbcunix.h:136: error: typedef int PTODBC::BOOL ../../ptclib/podbc.cxx:230: error: reference to 'BOOL' is ambiguous /usr/ports/devel/pwlib/work/ptlib_v1_12_0/include/ptlib/unix/ptlib/contain.h:135: error: candidates are: typedef int BOOL /usr/local/include/iodbcunix.h:136: error: typedef int PTODBC::BOOL ../../ptclib/podbc.cxx:230: error: 'BOOL' does not name a type ../../ptclib/podbc.cxx:283: error: reference to 'BOOL' is ambiguous /usr/ports/devel/pwlib/work/ptlib_v1_12_0/include/ptlib/unix/ptlib/contain.h:135: error: candidates are: typedef int BOOL /usr/local/include/iodbcunix.h:136: error: typedef int PTODBC::BOOL ../../ptclib/podbc.cxx:283: error: reference to 'BOOL' is ambiguous /usr/ports/devel/pwlib/work/ptlib_v1_12_0/include/ptlib/unix/ptlib/contain.h:135: error: candidates are: typedef int BOOL /usr/local/include/iodbcunix.h:136: error: typedef int PTODBC::BOOL ../../ptclib/podbc.cxx:283: error: 'BOOL' does not name a type ../../ptclib/podbc.cxx:318: error: reference to 'BOOL' is ambiguous /usr/ports/devel/pwlib/work/ptlib_v1_12_0/include/ptlib/unix/ptlib/contain.h:135: error: candidates are: typedef int BOOL /usr/local/include/iodbcunix.h:136: error: typedef int PTODBC::BOOL ../../ptclib/podbc.cxx:318: error: reference to 'BOOL' is ambiguous /usr/ports/devel/pwlib/work/ptlib_v1_12_0/include/ptlib/unix/ptlib/contain.h:135: error: candidates are: typedef int BOOL /usr/local/include/iodbcunix.h:136: error: typedef int PTODBC::BOOL ../../ptclib/podbc.cxx:318: error: 'BOOL' does not name a type ../../ptclib/podbc.cxx:325: error: reference to 'BOOL' is ambiguous /usr/ports/devel/pwlib/work/ptlib_v1_12_0/include/ptlib/unix/ptlib/contain.h:135: error: candidates are: typedef int BOOL /usr/local/include/iodbcunix.h:136: error: typedef int PTODBC::BOOL ../../ptclib/podbc.cxx:325: error: reference to 'BOOL' is ambiguous /usr/ports/devel/pwlib/work/ptlib_v1_12_0/include/ptlib/unix/ptlib/contain.h:135: error: candidates are: typedef int BOOL /usr/local/include/iodbcunix.h:136: error: typedef int PTODBC::BOOL ../../ptclib/podbc.cxx:325: error: 'BOOL' does not name a type ../../ptclib/podbc.cxx:333: error: reference to 'BOOL' is ambiguous /usr/ports/devel/pwlib/work/ptlib_v1_12_0/include/ptlib/unix/ptlib/contain.h:135: error: candidates are: typedef int BOOL /usr/local/include/iodbcunix.h:136: error: typedef int PTODBC::BOOL ../../ptclib/podbc.cxx:333: error: reference to 'BOOL' is ambiguous /usr/ports/devel/pwlib/work/ptlib_v1_12_0/include/ptlib/unix/ptlib/contain.h:135: error: candidates are: typedef int BOOL /usr/local/include/iodbcunix.h:136: error: typedef int PTODBC::BOOL ../../ptclib/podbc.cxx:333: error: 'BOOL' does not name a type ../../ptclib/podbc.cxx:342: error: reference to 'BOOL' is ambiguous /usr/ports/devel/pwlib/work/ptlib_v1_12_0/include/ptlib/unix/ptlib/contain.h:135: error: candidates are: typedef int BOOL /usr/local/include/iodbcunix.h:136: error: typedef int PTODBC::BOOL ../../ptclib/podbc.cxx:342: error: reference to 'BOOL' is ambiguous /usr/ports/devel/pwlib/work/ptlib_v1_12_0/include/ptlib/unix/ptlib/contain.h:135: error: candidates are: typedef int BOOL /usr/local/include/iodbcunix.h:136: error: typedef int PTODBC::BOOL ../../ptclib/podbc.cxx:342: error: 'BOOL' does not name a type ../../ptclib/podbc.cxx:353: error: reference to 'BOOL' is ambiguous /usr/ports/devel/pwlib/work/ptlib_v1_12_0/include/ptlib/unix/ptlib/contain.h:135: error: candidates are: typedef int BOOL /usr/local/include/iodbcunix.h:136: error: typedef int PTODBC::BOOL ../../ptclib/podbc.cxx:353: error: reference to 'BOOL' is ambiguous /usr/ports/devel/pwlib/work/ptlib_v1_12_0/include/ptlib/unix/ptlib/contain.h:135: error: candidates are: typedef int BOOL /usr/local/include/iodbcunix.h:136: error:
Re: new version of devel/pwlib does not compile on 7.0-RELEASE
On Wed, 05 Mar 2008 11:15:03 -0600, Steve Ames [EMAIL PROTECTED] wrote: All of your errors seem to stem from: /usr/local/include/iodbcunix.h which isn't part of pwlib and doesn't exist on my system. It comes from databases/libiodbc. Cheers, Mezz -Steve Stefan Lambrev wrote: Greetings, New version of devel/pwlib does not compile on 7.0-RELEASE i386 Here is the error msg: snip -- [EMAIL PROTECTED] - [EMAIL PROTECTED] FreeBSD GNOME Team http://www.FreeBSD.org/gnome/ - [EMAIL PROTECTED] ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: new version of devel/pwlib does not compile on 7.0-RELEASE
Jeremy Messenger wrote: On Wed, 05 Mar 2008 11:15:03 -0600, Steve Ames [EMAIL PROTECTED] wrote: All of your errors seem to stem from: /usr/local/include/iodbcunix.h which isn't part of pwlib and doesn't exist on my system. It comes from databases/libiodbc. Hrm. I'll install that locally and see what I can do to fix these errors. devel/pwlib definately compiles cleanly on 7.0-R but it appears not so much if database/libiodbc is installed. -Steve ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Prefix of other ports from my_port/Makefile?
Hello freebsd-ports@
This is my first post.
My question is if it's possible to get the prefix under which another
port was installed from within the Makefile of my own port?
My port depends on security/cyrus-sasl2, hence I have:
LIB_DEPENDS+= sasl2.2:${PORTSDIR}/security/cyrus-sasl2
But what I would also need to do is set the following variables in the
configure environment of my port:
CPPFLAGS=-I/path/to/sasl2/includes
LDFLAGS=-L/path/to/sasl2/libs
Or otherwise the configure script will not find the libsasl2 includes
or libraries. From what I can tell from other ports that require this,
people just use:
${LOCALBASE}/include and
${LOCALBASE}/lib
for this. But what if cyrus-sasl2 was installed in another prefix, say
/var/tmp/foobar ?
Can I somehow get the prefix under which cyrus-sasl2 was installed,
and use that as a base instead of ${LOCALBASE}, which may or may not
be correct?
I ran into this issue when I tried to install my port along with its
dependencies into a prefix other than ${LOCALBASE}.
Thanks for any answers.
Regards,
Aron Stansvik
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to [EMAIL PROTECTED]
Postgres 8.3 - Plruby version change
Hi Version 0.5.0 used by the ports/database/postgres-plruby does not work with version 8.3 of postgres - the simple fix is to upgrade to version 0.5.3 of plruby --- postgresql-plruby.orig//Makefile2007-01-10 20:37:39.0 + +++ postgresql-plruby/Makefile 2008-03-06 00:14:26.574436377 + @@ -6,7 +6,7 @@ # PORTNAME= plruby -PORTVERSION= 0.5.0 +PORTVERSION= 0.5.3 CATEGORIES=databases ruby MASTER_SITES= ftp://moulon.inra.fr/pub/ruby/ \ http://freebsd.unixfreunde.de/sources/ --- postgresql-plruby.orig/distinfo 2006-12-13 10:45:23.0 + +++ postgresql-plruby/distinfo 2008-03-06 00:30:32.917501208 + @@ -1,3 +1,3 @@ -MD5 (ruby/plruby-0.5.0.tar.gz) = 77d006b6b24f61709cd68d77d88b113f -SHA256 (ruby/plruby-0.5.0.tar.gz) = 3425a97e7fe3fb04862f99aa6c38813c0d81f955df6cab2eb5b47afb708b8e57 -SIZE (ruby/plruby-0.5.0.tar.gz) = 129574 +MD5 (ruby/plruby-0.5.3.tar.gz) = 9411bb29e1aa5521c5327e4d916de934 +SHA256 (ruby/plruby-0.5.3.tar.gz) = 3af88626078d979373ee7b169169584732310e271a1cbbe22e0d35adf2dee267 +SIZE = 131323 ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
