Re: More Heimdal 1.5.2 port problems
On Sun, May 27, 2012 at 3:33 PM, Wesley Shields w...@freebsd.org wrote:
On Sun, May 27, 2012 at 01:58:23PM -0400, Robert Simmons wrote:
On Sat, May 26, 2012 at 3:22 PM, Robert Simmons rsimmo...@gmail.com wrote:
I've found another problem with the port.
kadmind and kdc both look for krb5.conf in /usr/local/etc, but
kpasswdd and kstash look for it in /etc. ?This can be fixed with a
symlink, but I feel like that's not the best solution. ?Ultimately,
all the heimdal utilities and daemons should be looking in the same
location for krb5.conf, correct?
I don't see any flags for kstash or kpasswdd to change where they look
for krb5.conf.
I'm going to go back and compile it from source again and see if there
is another configure flag that is missing from the port.
I've attached a patch for this problem. Please review it and make
sure this is the right way to fix the problem.
--- Makefile.old 2012-05-27 13:53:01.132516965 -0400
+++ Makefile 2012-05-27 13:54:13.928517659 -0400
@@ -7,7 +7,7 @@
PORTNAME= heimdal
PORTVERSION= 1.5.2
-PORTREVISION= 2
+PORTREVISION= 3
CATEGORIES= security ipv6
MASTER_SITES= http://www.h5l.org/dist/src/ \
http://ftp.pdc.kth.se/pub/heimdal/src/ \
@@ -39,7 +39,8 @@
CONFIGURE_ARGS+= --with-libintl=${LOCALBASE} \
--with-readline=${DESTDIR}/usr \
--enable-pthread-support \
- --with-hdbdir=/var/db/${PORTNAME}
+ --with-hdbdir=/var/db/${PORTNAME} \
+ --sysconfdir=${LOCALBASE}/etc
MAKE_ENV+= INSTALL_CATPAGES=no
You want to use PREFIX instead of LOCALBASE for sysconfdir.
PREFIX is where the port will install into, LOCALBASE is where the
dependencies will be looked for. It's almost always the case that PREFIX
is the same as LOCALBASE but we should support them being different.
Otherwise the patch looks sane to me. Awaiting Joerg's input before I
commit. Thanks again!
Understood. Here's a new patch. Also, this particular behavior seems
odd to me, and I think I will ping Heimdal's list about this. It
seems to me that this configure flag shouldn't be needed, or at least
all the daemons and utilities should look consistently in the same
location if this flag is not set.
--- Makefile.old2012-05-27 13:53:01.132516965 -0400
+++ Makefile2012-05-27 13:54:13.928517659 -0400
@@ -7,7 +7,7 @@
PORTNAME= heimdal
PORTVERSION= 1.5.2
-PORTREVISION= 2
+PORTREVISION= 3
CATEGORIES=security ipv6
MASTER_SITES= http://www.h5l.org/dist/src/ \
http://ftp.pdc.kth.se/pub/heimdal/src/ \
@@ -39,7 +39,8 @@
CONFIGURE_ARGS+= --with-libintl=${LOCALBASE} \
--with-readline=${DESTDIR}/usr \
--enable-pthread-support \
- --with-hdbdir=/var/db/${PORTNAME}
+ --with-hdbdir=/var/db/${PORTNAME} \
+ --sysconfdir=${PREFIX}/etc
MAKE_ENV+= INSTALL_CATPAGES=no
INFO= heimdal hx509
___
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: gdal 1.9.1 (Was Re: graphics/gdal 1.9.0 does not build on CURRENT)
Le 27.05.2012 09:17, Rainer Hurling a écrit :
On 26.05.2012 18:41 (UTC+1), Rainer Hurling wrote:
On 26.05.2012 17:49 (UTC+2), coder.tuxfamily wrote:
Le 25.05.2012 22:49, Rainer Hurling a écrit :
On 25.05.2012 21:51 (UTC+1), coder.tuxfamily wrote:
Can you try to build the new port of gdal ?
I have the same problem with swig for php...
Thanks for the update. It builds and installs fine here on two boxes
with 10.0-CURRENT (amd64).
One issue which should be thought about before updating gdal in the
ports:
Does gdal-1.9.1 really needs swig 2.0? It seems so for at least libkml?
The problem is, that in your Makefile swig 2.0 conflicts with an
installed swig 1.3.40, which is needed for example by graphics/geos,
graphics/graphviz, math/saga, science/py-scipy and some others.
Affected ports can be found for example with
find /usr/ports -name Makefile -depth 3 -exec grep -l -e swig13 {} \;
I personally would prefer the newer swig 2.0 version (even for most
other ports). Do you think it is necessary to forbid a parallel swig
1.3.40 installation in your port? I read somewhere that both swig ports
can coexist in principle, only some docs share the same places (which
should be changed, of course).
Maybe you're right. I've see on trac.osgeo.org that it uses swig-1.3.40.
I will try without specify version of swig.
I saw in the news on http://www.swig.org/, that swig 2.0.6 is out with
many bug fixes and enhancements for templates and target languages like
php and python. Perhaps swig 2.0.6 is ready now for gdal?
I made a patch to update from swig 2.0.4 to 2.0.6. Could you please try
if at least some of the observed problems will disappear?
If this helps we should create a PR and ask the maintainer for an update.
I just checked, that swig 1.3.40 and 2.0.4 should be able to coexist at
the same time. At least they do not share any filenames.
The patch works but don't solve gdal problems. I think i've found were
it's wrong.
For Ruby/Swig :
See the page on GDAL : http://trac.osgeo.org/gdal/wiki/GdalOgrInRuby
SWIG 2 is required to build the Ruby bindings against Ruby 1.9.2. (SWIG
1.3.40 is fine for Ruby 1.8.7)
When i try to compile, i've two errors :
ogr_wrap.o: relocation R_X86_64_32 against `a local symbol' can not be
used when making a shared object; recompile with -fPIC
ogr_wrap.o: relocation R_X86_64_32 against `a local symbol' can not be
used when making a shared object; recompile with -fPIC
___
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: qzeitgeist failed to compile on FreeBSD 9-STABLE
I've rebuild automoc4 with the patch and the compilation succeed, but the qzeitgeist's configure phase fails. On 05/27/12 11:14, Alberto Villa wrote: On Sun, May 27, 2012 at 10:44 AM, Quentin Schwerkolt develloper.u...@hotmail.fr wrote: Thanks for the patch, but it's doesn't run. What was the problem with the attached patch? === License LGPL21 accepted by the user === Extracting for qzeitgeist-0.8.0 = SHA256 Checksum OK for libqzeitgeist-0.8.0.tar.bz2. = SHA256 Checksum OK for zeitgeist-0.8.2.tar.gz. cd /usr/ports/sysutils/qzeitgeist/work/zeitgeist-0.8.2 /bin/cp zeitgeist/datamodel.py extra/ontology/*.trig extra/rdfxml2py extra/PythonSerializer.py /usr/ports/sysutils/qzeitgeist/work/libqzeitgeist-0.8.0/scripts === Patching for qzeitgeist-0.8.0 === Applying FreeBSD patches for qzeitgeist-0.8.0 /usr/bin/sed -i.bak -e '/\.pc/ s|pkgconfig|../libdata/pkgconfig|' -e 's|share/qzeitgeist/cmake|lib/cmake/qzeitgeist|' -e /add_subdirectory(tests)/ d /usr/ports/sysutils/qzeitgeist/work/libqzeitgeist-0.8.0/CMakeLists.txt /usr/ports/sysutils/qzeitgeist/work/libqzeitgeist-0.8.0/src/CMakeLists.txt /usr/ports/sysutils/qzeitgeist/work/libqzeitgeist-0.8.0/QZeitgeistConfig.cmake.in /usr/bin/sed -i.bak -e '/import _config/ d' -e 's|_config.datadir, zeitgeist/ontology/zeitgeist.py|runpath, zeitgeist.py|' /usr/ports/sysutils/qzeitgeist/work/libqzeitgeist-0.8.0/scripts/datamodel.py /usr/bin/sed -i.bak -e 's|zeitgeist.datamodel|datamodel|' /usr/ports/sysutils/qzeitgeist/work/libqzeitgeist-0.8.0/scripts/onto2cpp.py /usr/bin/sed -i.bak -e 's|/usr/bin/python|/usr/local/bin/python2.7|g' /usr/ports/sysutils/qzeitgeist/work/libqzeitgeist-0.8.0/scripts/rdfxml2py === qzeitgeist-0.8.0 depends on executable: rapper - found === qzeitgeist-0.8.0 depends on file: /usr/local/lib/python2.7/site-packages/rdflib/__init__.py - found === qzeitgeist-0.8.0 depends on file: /usr/local/bin/python2.7 - found === qzeitgeist-0.8.0 depends on file: /usr/local/lib/qt4/libQtDBus.so - found === qzeitgeist-0.8.0 depends on file: /usr/local/lib/qt4/libQtDeclarative.so - found === qzeitgeist-0.8.0 depends on file: /usr/local/bin/moc-qt4 - found === qzeitgeist-0.8.0 depends on file: /usr/local/bin/qmake-qt4 - found === qzeitgeist-0.8.0 depends on file: /usr/local/lib/qt4/libQtTest.so - found === qzeitgeist-0.8.0 depends on file: /usr/local/bin/rcc - found === qzeitgeist-0.8.0 depends on file: /usr/local/bin/uic-qt4 - found === qzeitgeist-0.8.0 depends on file: /usr/local/bin/automoc4 - found === qzeitgeist-0.8.0 depends on file: /usr/local/bin/cmake - found === Configuring for qzeitgeist-0.8.0 /bin/mkdir -p /usr/ports/sysutils/qzeitgeist/work/libqzeitgeist-0.8.0 -- The C compiler identification is GNU 4.2.1 -- The CXX compiler identification is GNU 4.2.1 -- Check for working C compiler: /usr/bin/cc -- Check for working C compiler: /usr/bin/cc -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Check for working CXX compiler: /usr/bin/c++ -- Check for working CXX compiler: /usr/bin/c++ -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Looking for Q_WS_X11 -- Looking for Q_WS_X11 - found -- Looking for Q_WS_WIN -- Looking for Q_WS_WIN - not found. -- Looking for Q_WS_QWS -- Looking for Q_WS_QWS - not found. -- Looking for Q_WS_MAC -- Looking for Q_WS_MAC - not found. -- Found Qt4: /usr/local/bin/qmake-qt4 (found suitable version 4.8.1, required is 4.7.0) -- Performing Test __HAVE_GCC_VISIBILITY -- Performing Test __HAVE_GCC_VISIBILITY - Success CMake Error at /usr/lib64/automoc4/Automoc4Config.cmake:55 (include): include could not find load file: /usr/local/lib/automoc4/Automoc4Config.cmake/Automoc4Version.cmake Call Stack (most recent call first): src/CMakeLists.txt:7 (find_package) CMake Error: File /usr/local/lib/automoc4/Automoc4Config.cmake/automoc4.files.in does not exist. CMake Error at /usr/lib64/automoc4/Automoc4Config.cmake:183 (configure_file): configure_file Problem configuring file Call Stack (most recent call first): /usr/lib64/automoc4/Automoc4Config.cmake:236 (_add_automoc4_target) src/CMakeLists.txt:62 (automoc4_add_library) CMake Error at /usr/lib64/automoc4/Automoc4Config.cmake:55 (include): include could not find load file: /usr/local/lib/automoc4/Automoc4Config.cmake/Automoc4Version.cmake Call Stack (most recent call first): declarative/CMakeLists.txt:1 (find_package) CMake Error: File /usr/local/lib/automoc4/Automoc4Config.cmake/automoc4.files.in does not exist. CMake Error at /usr/lib64/automoc4/Automoc4Config.cmake:183 (configure_file): configure_file Problem configuring file Call Stack (most recent call first): /usr/lib64/automoc4/Automoc4Config.cmake:236 (_add_automoc4_target) declarative/CMakeLists.txt:15 (automoc4_add_library) -- Configuring incomplete, errors occurred! *** Error code 1 Stop in /usr/ports/sysutils/qzeitgeist signature.asc Description: OpenPGP
Re: gdal 1.9.1 (Was Re: graphics/gdal 1.9.0 does not build on CURRENT)
Le 28.05.2012 08:59, coder.tuxfamily a écrit :
Le 27.05.2012 09:17, Rainer Hurling a écrit :
On 26.05.2012 18:41 (UTC+1), Rainer Hurling wrote:
On 26.05.2012 17:49 (UTC+2), coder.tuxfamily wrote:
Le 25.05.2012 22:49, Rainer Hurling a écrit :
On 25.05.2012 21:51 (UTC+1), coder.tuxfamily wrote:
Can you try to build the new port of gdal ?
I have the same problem with swig for php...
Thanks for the update. It builds and installs fine here on two boxes
with 10.0-CURRENT (amd64).
One issue which should be thought about before updating gdal in the
ports:
Does gdal-1.9.1 really needs swig 2.0? It seems so for at least
libkml?
The problem is, that in your Makefile swig 2.0 conflicts with an
installed swig 1.3.40, which is needed for example by graphics/geos,
graphics/graphviz, math/saga, science/py-scipy and some others.
Affected ports can be found for example with
find /usr/ports -name Makefile -depth 3 -exec grep -l -e swig13
{} \;
I personally would prefer the newer swig 2.0 version (even for most
other ports). Do you think it is necessary to forbid a parallel swig
1.3.40 installation in your port? I read somewhere that both swig
ports
can coexist in principle, only some docs share the same places (which
should be changed, of course).
Maybe you're right. I've see on trac.osgeo.org that it uses
swig-1.3.40.
I will try without specify version of swig.
I saw in the news on http://www.swig.org/, that swig 2.0.6 is out with
many bug fixes and enhancements for templates and target languages like
php and python. Perhaps swig 2.0.6 is ready now for gdal?
I made a patch to update from swig 2.0.4 to 2.0.6. Could you please try
if at least some of the observed problems will disappear?
If this helps we should create a PR and ask the maintainer for an update.
I just checked, that swig 1.3.40 and 2.0.4 should be able to coexist at
the same time. At least they do not share any filenames.
The patch works but don't solve gdal problems. I think i've found were
it's wrong.
For Ruby/Swig :
See the page on GDAL : http://trac.osgeo.org/gdal/wiki/GdalOgrInRuby
SWIG 2 is required to build the Ruby bindings against Ruby 1.9.2. (SWIG
1.3.40 is fine for Ruby 1.8.7)
When i try to compile, i've two errors :
ogr_wrap.o: relocation R_X86_64_32 against `a local symbol' can not be
used when making a shared object; recompile with -fPIC
ogr_wrap.o: relocation R_X86_64_32 against `a local symbol' can not be
used when making a shared object; recompile with -fPIC
For MDB driver (and for java port) it's needed some java stuff, but i
don't use java and so don't understand what to do
(http://trac.osgeo.org/gdal/wiki/GdalOgrInJavaBuildInstructionsUnix)
___
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: qzeitgeist failed to compile on FreeBSD 9-STABLE
On Mon, May 28, 2012 at 9:47 AM, Quentin Schwerkolt develloper.u...@hotmail.fr wrote: I've rebuild automoc4 with the patch and the compilation succeed, but the qzeitgeist's configure phase fails. Try again with the attached one, please. -- Alberto Villa, FreeBSD committer avi...@freebsd.org http://people.FreeBSD.org/~avilla patch-Automoc4Config.cmake Description: Binary data ___ 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: 10-CURRENT r235646 ports/mail/p5-Mail-SpamAssassin
El día Sunday, May 27, 2012 a las 04:40:58PM +0100, Chris Rees escribió: On 27 May 2012 16:14, Matthias Apitz g...@unixarea.de wrote: Hi, # cd /usr/ports/mail/p5-Mail-SpamAssassin # make install batch=YES === p5-Mail-SpamAssassin-3.3.2_6 requires Perl or later, install lang/perl5.8, lang/perl5.10, lang/perl5.12 or lang/perl5.14 and try again. *** [install] Error code 1 # pkg_info | fgrep perl perl-5.8.9_7 Practical Extraction and Report Language it seems to work with: # make install USE_PERL5=5.8 It does, but the maintainer has changed the minimum perl version to 5.12 (not sure why however) http://www.freebsd.org/cgi/cvsweb.cgi/ports/mail/p5-Mail-SpamAssassin/Makefile#rev1.151 perl-5.8.9 is way past EOL and unsupported by perl@, is there a particular reason you can't upgrade? Using perl-5.8.9 did not make p5-Mail-SpamAssassin building; I updated perl to 5.12 (following the guide in UPDATING), but this wasn't enough either; there was missing Perl/OSType.pm for building the port p5-Module-Build; I ended up with updating perl to 5.14 (and all depending p5-* ports with: # portmaster -o lang/perl5.14 lang/perl5.12 # portmaster p5- and this finally made p5-Mail-SpamAssassin happy; it took me some hours to get that sorted out; I never liked perl and now even less :-) matthias -- Matthias Apitz t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211 e g...@unixarea.de - w http://www.unixarea.de/ UNIX since V7 on PDP-11 | UNIX on mainframe since ESER 1055 (IBM /370) UNIX on x86 since SVR4.2 UnixWare 2.1.2 | FreeBSD since 2.2.5 ___ 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: qzeitgeist failed to compile on FreeBSD 9-STABLE
Thanks, qzeitgeist was successful build. On 05/28/12 10:10, Alberto Villa wrote: On Mon, May 28, 2012 at 9:47 AM, Quentin Schwerkolt develloper.u...@hotmail.fr wrote: I've rebuild automoc4 with the patch and the compilation succeed, but the qzeitgeist's configure phase fails. Try again with the attached one, please. signature.asc Description: OpenPGP digital signature
Continual error dialogs since upgrading some ports
Since upgrading a number of ports yesterday, I'm now being hounded continually with error dialogs popping up with the message: An internal system error has occurred A problem that we were not expecting has occurred. Please report this bug in your distribution bugtracker with the error description. The dialog is adorned with that little lifesaver image used by the GNOME help system, as well as a Show details button. Unfortunately, the details provided are a little vague, popping up another dialog showing the same message as the initial dialog, but with a More details dropdown button. More details provides only the following: The backend exited unexpectedly. This is a serious error as the spawned backend did not complete the pending transaction. Nowhere to be seen is any mention of exactly what program is spawning these error dialogs. Anyone ever seen these and/or have any idea where they might be coming from? Thanks! -- Conrad J. Sabatier conr...@cox.net ___ 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: qzeitgeist failed to compile on FreeBSD 9-STABLE
On Mon, May 28, 2012 at 12:07 PM, Quentin Schwerkolt develloper.u...@hotmail.fr wrote: Thanks, qzeitgeist was successful build. Fix committed, thanks for testing. -- Alberto Villa, FreeBSD committer avi...@freebsd.org http://people.FreeBSD.org/~avilla ___ 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
Current problem reports assigned to po...@freebsd.org
Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description o ports/168328 ports [REPOCOPY] devel/codeblocks -- devel/codeblocks-devel 1 problem total. ___ 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: [RFC] Seeking Approval: include bsd.port.pre.mk so SRC_BASE is defined before referenced
Jason Helfman ha scritto: I am working on the following pr, and would like to get others approval to the following patch: http://people.freebsd.org/~jgh/files/pre-patch.txt This patch is fixing several use cases of SRC_BASE before it is defined. I don't agree for the quantis-kmod patch. I think simply removing SRC_BASE?= line is the correct fix. -- Alex Dupre ___ 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: gdal 1.9.1 (Was Re: graphics/gdal 1.9.0 does not build on CURRENT)
On 28.05.2012 10:01 (UTC+1), coder.tuxfamily wrote:
Le 28.05.2012 08:59, coder.tuxfamily a écrit :
Le 27.05.2012 09:17, Rainer Hurling a écrit :
On 26.05.2012 18:41 (UTC+1), Rainer Hurling wrote:
On 26.05.2012 17:49 (UTC+2), coder.tuxfamily wrote:
Le 25.05.2012 22:49, Rainer Hurling a écrit :
On 25.05.2012 21:51 (UTC+1), coder.tuxfamily wrote:
Can you try to build the new port of gdal ?
I have the same problem with swig for php...
Thanks for the update. It builds and installs fine here on two boxes
with 10.0-CURRENT (amd64).
One issue which should be thought about before updating gdal in the
ports:
Does gdal-1.9.1 really needs swig 2.0? It seems so for at least
libkml?
The problem is, that in your Makefile swig 2.0 conflicts with an
installed swig 1.3.40, which is needed for example by graphics/geos,
graphics/graphviz, math/saga, science/py-scipy and some others.
Affected ports can be found for example with
find /usr/ports -name Makefile -depth 3 -exec grep -l -e swig13
{} \;
I personally would prefer the newer swig 2.0 version (even for most
other ports). Do you think it is necessary to forbid a parallel swig
1.3.40 installation in your port? I read somewhere that both swig
ports
can coexist in principle, only some docs share the same places (which
should be changed, of course).
Maybe you're right. I've see on trac.osgeo.org that it uses
swig-1.3.40.
I will try without specify version of swig.
I saw in the news on http://www.swig.org/, that swig 2.0.6 is out with
many bug fixes and enhancements for templates and target languages like
php and python. Perhaps swig 2.0.6 is ready now for gdal?
I made a patch to update from swig 2.0.4 to 2.0.6. Could you please try
if at least some of the observed problems will disappear?
If this helps we should create a PR and ask the maintainer for an
update.
I just checked, that swig 1.3.40 and 2.0.4 should be able to coexist at
the same time. At least they do not share any filenames.
The patch works but don't solve gdal problems. I think i've found were
it's wrong.
For Ruby/Swig :
See the page on GDAL : http://trac.osgeo.org/gdal/wiki/GdalOgrInRuby
SWIG 2 is required to build the Ruby bindings against Ruby 1.9.2. (SWIG
1.3.40 is fine for Ruby 1.8.7)
When i try to compile, i've two errors :
ogr_wrap.o: relocation R_X86_64_32 against `a local symbol' can not be
used when making a shared object; recompile with -fPIC
ogr_wrap.o: relocation R_X86_64_32 against `a local symbol' can not be
used when making a shared object; recompile with -fPIC
For MDB driver (and for java port) it's needed some java stuff, but i
don't use java and so don't understand what to do
(http://trac.osgeo.org/gdal/wiki/GdalOgrInJavaBuildInstructionsUnix)
While gdal-1.9.1 with option 'MDB' enabled compiles fine, I have another
failure with option 'Ruby bindings' enabled (both build with swig-2.0.6):
gmake[1]: Leaving directory `/usr/ports/graphics/gdal/work/gdal-1.9.1/apps'
(cd swig; gmake build)
gmake[1]: Entering directory `/usr/ports/graphics/gdal/work/gdal-1.9.1/swig'
for dir in ruby ; do (cd $dir; gmake build) || exit; done
gmake[2]: Entering directory
`/usr/ports/graphics/gdal/work/gdal-1.9.1/swig/ruby'
swig -Wall -I../include -I../include/ruby -I../include/ruby/docs
-autorename -prefix gdal:: -I/usr/ports/graphics/gdal/work/gdal-1.9.1
-c++ -ruby -o gdal_wrap.cpp ../include/gdal.i
swig: not found
gmake[2]: *** [gdal_wrap.cpp] Fehler 127
gmake[2]: Leaving directory
`/usr/ports/graphics/gdal/work/gdal-1.9.1/swig/ruby'
gmake[1]: *** [build] Fehler 2
gmake[1]: Leaving directory `/usr/ports/graphics/gdal/work/gdal-1.9.1/swig'
gmake: *** [swig-modules] Fehler 2
*** [do-build] Error code 1
Stop in /usr/ports/graphics/gdal.
___
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
time to remove dbf ? anyone using it? Re: ports/150903: databases/dbf: options --sql / --csv does produce crap on floats/doubles
time to deprecate dbf? no maintainer, old maintainer dropped it 6 months ago. last 'non portmgr' patch was december 2006. anyone want to take it over and fix it? else it should be deprecated, 90 days and then removed. -- Michael Scheidell, CTO *| * SECNAP Network Security Corporation d: +1.561.948.2259 w: http://people.freebsd.org/~scheidell ___ 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: gdal 1.9.1 (Was Re: graphics/gdal 1.9.0 does not build on CURRENT)
Le 28.05.2012 14:37, Rainer Hurling a écrit :
On 28.05.2012 10:01 (UTC+1), coder.tuxfamily wrote:
Le 28.05.2012 08:59, coder.tuxfamily a écrit :
Le 27.05.2012 09:17, Rainer Hurling a écrit :
On 26.05.2012 18:41 (UTC+1), Rainer Hurling wrote:
On 26.05.2012 17:49 (UTC+2), coder.tuxfamily wrote:
Le 25.05.2012 22:49, Rainer Hurling a écrit :
On 25.05.2012 21:51 (UTC+1), coder.tuxfamily wrote:
Can you try to build the new port of gdal ?
I have the same problem with swig for php...
Thanks for the update. It builds and installs fine here on two boxes
with 10.0-CURRENT (amd64).
One issue which should be thought about before updating gdal in the
ports:
Does gdal-1.9.1 really needs swig 2.0? It seems so for at least
libkml?
The problem is, that in your Makefile swig 2.0 conflicts with an
installed swig 1.3.40, which is needed for example by graphics/geos,
graphics/graphviz, math/saga, science/py-scipy and some others.
Affected ports can be found for example with
find /usr/ports -name Makefile -depth 3 -exec grep -l -e swig13
{} \;
I personally would prefer the newer swig 2.0 version (even for most
other ports). Do you think it is necessary to forbid a parallel swig
1.3.40 installation in your port? I read somewhere that both swig
ports
can coexist in principle, only some docs share the same places
(which
should be changed, of course).
Maybe you're right. I've see on trac.osgeo.org that it uses
swig-1.3.40.
I will try without specify version of swig.
I saw in the news on http://www.swig.org/, that swig 2.0.6 is out with
many bug fixes and enhancements for templates and target languages
like
php and python. Perhaps swig 2.0.6 is ready now for gdal?
I made a patch to update from swig 2.0.4 to 2.0.6. Could you please try
if at least some of the observed problems will disappear?
If this helps we should create a PR and ask the maintainer for an
update.
I just checked, that swig 1.3.40 and 2.0.4 should be able to
coexist at
the same time. At least they do not share any filenames.
The patch works but don't solve gdal problems. I think i've found were
it's wrong.
For Ruby/Swig :
See the page on GDAL : http://trac.osgeo.org/gdal/wiki/GdalOgrInRuby
SWIG 2 is required to build the Ruby bindings against Ruby 1.9.2. (SWIG
1.3.40 is fine for Ruby 1.8.7)
When i try to compile, i've two errors :
ogr_wrap.o: relocation R_X86_64_32 against `a local symbol' can not be
used when making a shared object; recompile with -fPIC
ogr_wrap.o: relocation R_X86_64_32 against `a local symbol' can not be
used when making a shared object; recompile with -fPIC
For MDB driver (and for java port) it's needed some java stuff, but i
don't use java and so don't understand what to do
(http://trac.osgeo.org/gdal/wiki/GdalOgrInJavaBuildInstructionsUnix)
While gdal-1.9.1 with option 'MDB' enabled compiles fine, I have another
failure with option 'Ruby bindings' enabled (both build with swig-2.0.6):
Compile but don't work (need libjvm.so)
gmake[1]: Leaving directory `/usr/ports/graphics/gdal/work/gdal-1.9.1/apps'
(cd swig; gmake build)
gmake[1]: Entering directory
`/usr/ports/graphics/gdal/work/gdal-1.9.1/swig'
for dir in ruby ; do (cd $dir; gmake build) || exit; done
gmake[2]: Entering directory
`/usr/ports/graphics/gdal/work/gdal-1.9.1/swig/ruby'
swig -Wall -I../include -I../include/ruby -I../include/ruby/docs
-autorename -prefix gdal:: -I/usr/ports/graphics/gdal/work/gdal-1.9.1
-c++ -ruby -o gdal_wrap.cpp ../include/gdal.i
swig: not found
gmake[2]: *** [gdal_wrap.cpp] Fehler 127
gmake[2]: Leaving directory
`/usr/ports/graphics/gdal/work/gdal-1.9.1/swig/ruby'
gmake[1]: *** [build] Fehler 2
gmake[1]: Leaving directory `/usr/ports/graphics/gdal/work/gdal-1.9.1/swig'
gmake: *** [swig-modules] Fehler 2
*** [do-build] Error code 1
Stop in /usr/ports/graphics/gdal.
___
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: Request to review: print/texlive-install
On 05/27/2012 09:19 PM, Eitan Adler wrote: On 27 May 2012 18:14, Stephen Montgomery-Smithstep...@missouri.edu wrote: There are a number of issues. In particular there is no checksum calculated for install-tl-unx.tar.gz because I suspect that it changes very often. This is a security risk and must not be committed as is. OK, I won't commit it as it is. ___ 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: Request to review: print/texlive-install
On 05/27/2012 08:48 PM, Nikola Lečić wrote: On Sun, 27 May 2012 20:32:14 -0500, Stephen Montgomery-Smith wrote: Hi People, I have written a simple port which is in essence a wrapper around the texlive installation script. It also builds (almost) all of the binaries from scratch. Does anyone have any suggestions? Would anyone mind if this port was committed? There are a number of issues. In particular there is no checksum calculated for install-tl-unx.tar.gz because I suspect that it changes very often. Also the install-tl- script doesn't seem to have a capability to be run in batch mode. I hacked a way around this, but it could be easily broken if the script were to change in some unexpected way. But it does build and install texlive in a fairly timely manner. And the result can be made into a (large) package using pkg_create. Stephen, TeX Live 2011 builds fine for me with this port. Just a few comments: 1. Biber doesn't need compat7x. It works on 7 and above without it. Moreover, the TeX Live's configure script already takes care of the FreeBSD version in the FreeBSD way. Please take a look: http://www.tug.org/svn/texlive/trunk/Build/source/utils/biber/configure?revision=26215view=markup lines 3563-3583, or just search for '__FreeBSD_version'. The binaries distributed with the source work on FreeBSD=701000 and biber will not be installed if older FreeBSD is detected. (I meant that it could be possible to cover FreeBSD-6 with biber binaries distributed over CTAN. But that's not extremely important for now.) 2. fontconfig is a run dependency as well, xetex needs it to run. Thanks. What about perl - is that a run dependency as well? 3. TeX Live ships with its own portable FreeBSD i386/amd64 xz and wget binaries and install-tl/tlmgr use them. They will not work on FreeBSD7. Therefore, it could be possible that you need to add xz and wget as build/run dependencies on FreeBSD7 and on architectures other than i386/amd64, although I haven't checked this. I won't worry about FreeBSD7. They are end of line anyway. 4. Since the aim of your port is not to create portable binaries, there is no reason not to build xindy. You can freely add '--enable-xindy CLISP=/path to the clisp binary/', and lang/clisp as a build dependency. I was looking at the online docs of xindy. Is the version of xindy that comes with texlive out of date? The online docs don't match the program that comes with xindy. ___ 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: Request to review: print/texlive-install
On 05/27/2012 09:19 PM, Eitan Adler wrote: On 27 May 2012 18:14, Stephen Montgomery-Smithstep...@missouri.edu wrote: There are a number of issues. In particular there is no checksum calculated for install-tl-unx.tar.gz because I suspect that it changes very often. This is a security risk and must not be committed as is. How about if I add lines like this: .if !defined(IGNORE_SECURITY_RISK) IGNORE= has a security risk because it downloads a file \ without a checksum. Define IGNORE_SECURITY_RISK to build this port .endif Would it be considered OK to commit it then? ___ 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 Xorg: graphics/dri: fails to compile with CLANG: nouveau_array.c:49:16: error: illegal storage class on function, *extract_u = EXTRACT(char, unsigned, 1);
Dimitry Andric wrote: On 2012-04-28 13:12, Volodymyr Kostyrko wrote: O. Hartmann wrote: Is there in official way to get this fixed with CLANG? I see that files folder in graphics/dri is missing, so none of the fixes for both the faulty source files I think the patch should go to graphics/libGL. cd /usr/ports/graphics/libGL/files fetch -rao - 'http://cgit.freedesktop.org/mesa/mesa/patch/?id=4aa1ac5fe94b5696095229ee3568bf4fa7cfed95' | sed -e 's|^--- a/src|--- src|' -e 's|^+++ b/src|+++ src|' patch-nouveau Should do. Please try this patch (lightly tested): http://www.andric.com/freebsd/clang/clangports-graphics-libGL-3.diff Works for me. Could this one be commited? It looks better then my quick hack. -- Sphinx of black quartz judge my vow. ___ 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: Request to review: print/texlive-install
On 5/28/12 10:11 AM, Stephen Montgomery-Smith wrote: How about if I add lines like this: .if !defined(IGNORE_SECURITY_RISK) IGNORE= has a security risk because it downloads a file \ without a checksum. Define IGNORE_SECURITY_RISK to build this port .endif Would it be considered OK to commit it then? could you host it somewhere that won't go away at missouri.edu? -- Michael Scheidell, CTO *| * SECNAP Network Security Corporation d: +1.561.948.2259 w: http://people.freebsd.org/~scheidell ___ 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: Request to review: print/texlive-install
On Mon, 28 May 2012 09:06:18 -0500, Stephen Montgomery-Smith wrote: 2. fontconfig is a run dependency as well, xetex needs it to run. Thanks. What about perl - is that a run dependency as well? Yes, it is, install-tl and tlmgr are perl scripts. 3. TeX Live ships with its own portable FreeBSD i386/amd64 xz and wget binaries and install-tl/tlmgr use them. They will not work on FreeBSD7. Therefore, it could be possible that you need to add xz and wget as build/run dependencies on FreeBSD7 and on architectures other than i386/amd64, although I haven't checked this. I won't worry about FreeBSD7. They are end of line anyway. Ok. 4. Since the aim of your port is not to create portable binaries, there is no reason not to build xindy. You can freely add '--enable-xindy CLISP=/path to the clisp binary/', and lang/clisp as a build dependency. I was looking at the online docs of xindy. Is the version of xindy that comes with texlive out of date? The online docs don't match the program that comes with xindy. Many other programs are out of date, TeX Live 2011 was released a year ago. The versions distributed with TL releases match together well. The safest options for TL2011 users is to use xindy distributed with TL2011. More notes/questions: * You could add x11-toolkits/p5-Tk as a run dependency. tlmgr has a nice GUI; actually it's very inconvenient to use it without gui. * Since this port leaves full TeX Live system installed, users should use tlmgr to update their packages and scripts. Two questions in this respect: a) what will happen with /var/db/ports/ info? b) it's not a good idea to run tlmgr gui as root. Maybe to offer an option with SUID Bit, as in sysutils/xcdroast? -- Nikola Lečić = Никола Лечић fingerprint : FEF3 66AF C90E EDC3 D878 7CDC 956D F4AB A377 1C9B ___ 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: Request to review: print/texlive-install
On 05/28/2012 10:47 AM, Michael Scheidell wrote: On 5/28/12 10:11 AM, Stephen Montgomery-Smith wrote: How about if I add lines like this: .if !defined(IGNORE_SECURITY_RISK) IGNORE= has a security risk because it downloads a file \ without a checksum. Define IGNORE_SECURITY_RISK to build this port .endif Would it be considered OK to commit it then? could you host it somewhere that won't go away at missouri.edu? I could host it somewhere at missouri.edu that will stay as long as I am alive or keep my job. ___ 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: gdal 1.9.1 (Was Re: graphics/gdal 1.9.0 does not build on CURRENT)
Hi, Here's just a status update. I'm working on GDAL 1.9.1 update. I plan to move perl/php/python/ruby bindings to separate ports. It also removes dirty python hacks from the master port. BTW, it seems swig 1.3.40 is enough for GDAL 1.9.1. I can build ruby-gdal successfully with swig 1.3.40 and ruby 1.9. But I haven't tested if the generated shared libraries are OK. Regards, sunpoet ___ 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: Request to review: print/texlive-install
On 2012.05.28. 18:16, Stephen Montgomery-Smith wrote: On 5/28/12 10:11 AM, Stephen Montgomery-Smith wrote: How about if I add lines like this: .if !defined(IGNORE_SECURITY_RISK) IGNORE= has a security risk because it downloads a file \ without a checksum. Define IGNORE_SECURITY_RISK to build this port .endif Would it be considered OK to commit it then? could you host it somewhere that won't go away at missouri.edu? I could host it somewhere at missouri.edu that will stay as long as I am alive or keep my job. Better to host it on the FreeBSD mirrors. You only have to create a public_distfiles in your home directory after logging in to freefall and drop the file there. This is the usual way of doing it. Gabor ___ 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: Request to review: print/texlive-install
On May 28, 2012 5:23 PM, Stephen Montgomery-Smith step...@missouri.edu wrote: On 05/28/2012 10:47 AM, Michael Scheidell wrote: On 5/28/12 10:11 AM, Stephen Montgomery-Smith wrote: How about if I add lines like this: .if !defined(IGNORE_SECURITY_RISK) IGNORE= has a security risk because it downloads a file \ without a checksum. Define IGNORE_SECURITY_RISK to build this port .endif Would it be considered OK to commit it then? could you host it somewhere that won't go away at missouri.edu? I could host it somewhere at missouri.edu that will stay as long as I am alive or keep my job. The main problem is the fetching of random files during build-- that is an issue faced by many ports. This is not generally allowed to happen, since these files are not verified either. What needs to happen is for the port to fetch all necessary files in the do-fetch stage. Unfortunately this makes it more complicated, but otherwise our users are simply better off fetching and installing the files themselves; the port makes it no easier. Chris ___ 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: gdal 1.9.1 (Was Re: graphics/gdal 1.9.0 does not build on CURRENT)
On 28.05.2012 18:18 (UTC+1), Sunpoet Po-Chuan Hsieh wrote: Hi, Here's just a status update. I'm working on GDAL 1.9.1 update. That's nice to hear. I plan to move perl/php/python/ruby bindings to separate ports. It also removes dirty python hacks from the master port. And the (slave) ports we would have to install additionally, if we want the bindings? Sounds reasonable. BTW, it seems swig 1.3.40 is enough for GDAL 1.9.1. So most people would only need 1.3.40 and not a parallel 2.0.x installation. I can build ruby-gdal successfully with swig 1.3.40 and ruby 1.9. But I haven't tested if the generated shared libraries are OK. Good luck also with MDB (java) and the shared libraries. Regards, sunpoet Thanks for the info and the work, Rainer ___ 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: Request to review: print/texlive-install
On 05/27/2012 09:19 PM, Eitan Adler wrote: On 27 May 2012 18:14, Stephen Montgomery-Smithstep...@missouri.edu wrote: There are a number of issues. In particular there is no checksum calculated for install-tl-unx.tar.gz because I suspect that it changes very often. This is a security risk and must not be committed as is. How about if I add lines like this: .if !defined(IGNORE_SECURITY_RISK) IGNORE= has a security risk because it downloads a file \ without a checksum. Define IGNORE_SECURITY_RISK to build this port .endif Would it be considered OK to commit it then? Does the code look for a particular location for this file to exist before attempting to download it? If not, can it be patched, to do so? If so, it can be added as a distfile, and put into a location where the build will find it. If this can be done, there wouldn't be a security risk, assuming no other files are downloaded post-fetch. -jgh ___ 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 Xorg: graphics/dri: fails to compile with CLANG: nouveau_array.c:49:16: error: illegal storage class on function, *extract_u = EXTRACT(char, unsigned, 1);
On 2012-05-28 16:13, Volodymyr Kostyrko wrote: Dimitry Andric wrote: ... Please try this patch (lightly tested): http://www.andric.com/freebsd/clang/clangports-graphics-libGL-3.diff Works for me. Could this one be commited? It looks better then my quick hack. If the libGL maintainers are OK with it, I'll commit it. Or if anyone in the x11@ team feels like it, please do. ___ 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: Request to review: print/texlive-install
On 05/28/2012 10:44 AM, Nikola Lečić wrote:
On Mon, 28 May 2012 09:06:18 -0500, Stephen Montgomery-Smith wrote:
2. fontconfig is a run dependency as well, xetex needs it to run.
Thanks. What about perl - is that a run dependency as well?
Yes, it is, install-tl and tlmgr are perl scripts.
3. TeX Live ships with its own portable FreeBSD i386/amd64 xz and wget
binaries and install-tl/tlmgr use them. They will not work on FreeBSD7.
Therefore, it could be possible that you need to add xz and wget as
build/run dependencies on FreeBSD7 and on architectures other than
i386/amd64, although I haven't checked this.
I won't worry about FreeBSD7. They are end of line anyway.
Ok.
But it looks like tlmgr expects to find wget in its path. So I'll add
it as a run dependency.
4. Since the aim of your port is not to create portable binaries, there
is no reason not to build xindy. You can freely add '--enable-xindy
CLISP=/path to the clisp binary/', and lang/clisp as a build dependency.
I was looking at the online docs of xindy. Is the version of xindy
that comes with texlive out of date? The online docs don't match the
program that comes with xindy.
Many other programs are out of date, TeX Live 2011 was released a year
ago. The versions distributed with TL releases match together well. The
safest options for TL2011 users is to use xindy distributed with TL2011.
I will add an option that allows xindy to be built.
More notes/questions:
* You could add x11-toolkits/p5-Tk as a run dependency. tlmgr has a
nice GUI; actually it's very inconvenient to use it without gui.
I will add an option that will add x11-toolkits/p5-Tk as a run dependency.
* Since this port leaves full TeX Live system installed, users should
use tlmgr to update their packages and scripts. Two questions in this
respect:
a) what will happen with /var/db/ports/ info?
he info will become out of date. But when the user tries to deinstall
the package, he/she gets helpful messages that says it could not be
completely deinstalled, and says where the problem is. And since the
only stuff that will have changed is in ${PREFIX}/texlive, the user
should find it easy to delete the left over stuff.
Also I think one could add a pkg-deinstall message that says to apply
rm -rf ${PREFIX}/texlive just to be sure.
b) it's not a good idea to run tlmgr gui as root. Maybe to offer an
option with SUID Bit, as in sysutils/xcdroast?
This looks non-trivial. Simply setting the setuid bit on the tlmgr
script doesn't work, because it is a perl script. One way would be to
write a wrapper.
But I would recommend the port security/super which allows you to
create scripts that can be run with setuid. Then let the user set this
up as they desire.
___
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: Request to review: print/texlive-install
On 05/28/2012 11:29 AM, Jason Helfman wrote: On 05/27/2012 09:19 PM, Eitan Adler wrote: On 27 May 2012 18:14, Stephen Montgomery-Smithstep...@missouri.edu wrote: There are a number of issues. In particular there is no checksum calculated for install-tl-unx.tar.gz because I suspect that it changes very often. This is a security risk and must not be committed as is. How about if I add lines like this: .if !defined(IGNORE_SECURITY_RISK) IGNORE= has a security risk because it downloads a file \ without a checksum. Define IGNORE_SECURITY_RISK to build this port .endif Would it be considered OK to commit it then? Does the code look for a particular location for this file to exist before attempting to download it? If not, can it be patched, to do so? If so, it can be added as a distfile, and put into a location where the build will find it. Yes, I can do this. But the file changes often, so one would have to update distinfo in the ports very often to keep up. If this can be done, there wouldn't be a security risk, assuming no other files are downloaded post-fetch. And the install script downloads everything during the do-install phase. ___ 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: 10-CURRENT r235646 ports/mail/p5-Mail-SpamAssassin
On 28 May 2012 09:57, Matthias Apitz g...@unixarea.de wrote: El día Sunday, May 27, 2012 a las 04:40:58PM +0100, Chris Rees escribió: On 27 May 2012 16:14, Matthias Apitz g...@unixarea.de wrote: Hi, # cd /usr/ports/mail/p5-Mail-SpamAssassin # make install batch=YES === p5-Mail-SpamAssassin-3.3.2_6 requires Perl or later, install lang/perl5.8, lang/perl5.10, lang/perl5.12 or lang/perl5.14 and try again. *** [install] Error code 1 # pkg_info | fgrep perl perl-5.8.9_7 Practical Extraction and Report Language it seems to work with: # make install USE_PERL5=5.8 It does, but the maintainer has changed the minimum perl version to 5.12 (not sure why however) http://www.freebsd.org/cgi/cvsweb.cgi/ports/mail/p5-Mail-SpamAssassin/Makefile#rev1.151 perl-5.8.9 is way past EOL and unsupported by perl@, is there a particular reason you can't upgrade? Using perl-5.8.9 did not make p5-Mail-SpamAssassin building; I updated perl to 5.12 (following the guide in UPDATING), but this wasn't enough either; there was missing Perl/OSType.pm for building the port p5-Module-Build; I ended up with updating perl to 5.14 (and all depending p5-* ports with: # portmaster -o lang/perl5.14 lang/perl5.12 # portmaster p5- and this finally made p5-Mail-SpamAssassin happy; I don't understand... this is exactly what is recommended in UPDATING 20110517. Which guide did you follow? Chris ___ 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: 10-CURRENT r235646 ports/mail/p5-Mail-SpamAssassin
El día Monday, May 28, 2012 a las 06:34:57PM +0100, Chris Rees escribió: perl-5.8.9 is way past EOL and unsupported by perl@, is there a particular reason you can't upgrade? Using perl-5.8.9 did not make p5-Mail-SpamAssassin building; I updated perl to 5.12 (following the guide in UPDATING), but this wasn't enough either; there was missing Perl/OSType.pm for building the port p5-Module-Build; I ended up with updating perl to 5.14 (and all depending p5-* ports with: # portmaster -o lang/perl5.14 lang/perl5.12 # portmaster p5- and this finally made p5-Mail-SpamAssassin happy; I don't understand... this is exactly what is recommended in UPDATING 20110517. Yes, but first I tried exactly the same procedure to update 5.8 to 5.12, because the Makefile of p5-Mail-SpamAssassin asked for 5.12; but 5.12 is not enough to make p5-Mail-SpamAssassin building, at least not in my ports tree; matthias -- Matthias Apitz e g...@unixarea.de - w http://www.unixarea.de/ UNIX since V7 on PDP-11, UNIX on mainframe since ESER 1055 (IBM /370) UNIX on x86 since SVR4.2 UnixWare 2.1.2, FreeBSD since 2.2.5 ___ 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: 10-CURRENT r235646 ports/mail/p5-Mail-SpamAssassin
On 5/28/12 1:51 PM, Matthias Apitz wrote: Yes, but first I tried exactly the same procedure to update 5.8 to 5.12, because the Makefile of p5-Mail-SpamAssassin asked for 5.12; but 5.12 is not enough to make p5-Mail-SpamAssassin building, at least not in my ports tree; update procedures for 5.8 to 5.12 are different. and, I got a bizillian commercial systems out there with perl 5.12.4 and spamassassin, built and run fine. (and logs to prove it builds just fine) don't take shortcuts. not unless you know what you are doing. and when it comes to perl, no one does.. no one. -- Michael Scheidell, CTO *| * SECNAP Network Security Corporation d: +1.561.948.2259 w: http://people.freebsd.org/~scheidell ___ 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: Request to review: print/texlive-install
On 05/28/2012 12:31 PM, Chris Rees wrote:
On 28 May 2012 18:11, Stephen Montgomery-Smithstep...@missouri.edu wrote:
On 05/28/2012 11:35 AM, Gábor Kövesdán wrote:
On 2012.05.28. 18:16, Stephen Montgomery-Smith wrote:
On 5/28/12 10:11 AM, Stephen Montgomery-Smith wrote:
How about if I add lines like this:
.if !defined(IGNORE_SECURITY_RISK)
IGNORE= has a security risk because it downloads a file \
without a checksum. Define IGNORE_SECURITY_RISK to build this port
.endif
Would it be considered OK to commit it then?
could you host it somewhere that won't go away at missouri.edu?
I could host it somewhere at missouri.edu that will stay as long as I
am alive or keep my job.
Better to host it on the FreeBSD mirrors. You only have to create a
public_distfiles in your home directory after logging in to freefall and
drop the file there. This is the usual way of doing it.
Thank you for the info. Here is my latest version:
http://people.freebsd.org/~stephen/
I'm afraid my concerns still hold [1].
This port fetches $WHOKNOWSWHAT from $WHOKNOWSWHERE outside the fetch
stage, which isn't how ports are supposed to work.
I know 'having a port' is usually considered a good thing, but as I
said before, it's no easier or safer to install this via the port than
just download and run the script.
[1] http://lists.freebsd.org/pipermail/freebsd-ports/2012-May/075236.html
Yes, this will never become part of the ports tree as it is. I am
merely going to offer this to people as something they can download from
my web page.
The advantage it offers over the usual script is that the binaries are
built for your particular system. And /var/db/pkg is populated. And
links are created to ${PREFIX}/bin.
[2]
'''
Install texlive-install.
Use texlive to grab funky new package.
Upgrade texlive-install /* XXX funky new package is now added to
texlive-instal plist */
Upgrade texlive-install again
Hey, where did $FUNKY go?
'''
Hopefully $FUNKY will now be part of the complete texlive install, and
so it will be reinstalled in the second (and first) upgrades.
Otherwise I see no way around this problem.
===
One thing I might do is to create a port called texlive-binaries with
instructions in pkg-message on how to incorporate it into the texlive
distribution when you use the script downloaded from their web page. (I
need to check that the name texlive-binaries doesn't conflict with
http://code.google.com/p/freebsd-texlive.)
___
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: 10-CURRENT r235646 ports/mail/p5-Mail-SpamAssassin
El día Monday, May 28, 2012 a las 01:54:04PM -0400, Michael Scheidell escribió:
On 5/28/12 1:51 PM, Matthias Apitz wrote:
Yes, but first I tried exactly the same procedure to update 5.8 to 5.12,
because the Makefile of p5-Mail-SpamAssassin asked for 5.12; but 5.12
is not enough to make p5-Mail-SpamAssassin building, at least not in my
ports tree;
update procedures for 5.8 to 5.12 are different.
if you look into UPDATING it says in 20110622:
...
If you want to switch to lang/perl5.12 from lang/perl5.{8,10} please
follow instructions in the entry 20100715 in this file.
and I followed exactly the procedire recommended in 20100715;
and, I got a bizillian commercial systems out there with perl 5.12.4 and
spamassassin, built and run fine.
(and logs to prove it builds just fine)
it did not built in my CVS based ports tree with perl5.12; sorry
matthias
--
Matthias Apitz
e g...@unixarea.de - w http://www.unixarea.de/
UNIX since V7 on PDP-11, UNIX on mainframe since ESER 1055 (IBM /370)
UNIX on x86 since SVR4.2 UnixWare 2.1.2, FreeBSD since 2.2.5
___
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: 10-CURRENT r235646 ports/mail/p5-Mail-SpamAssassin
On 28 May 2012 19:15, Matthias Apitz g...@unixarea.de wrote:
El día Monday, May 28, 2012 a las 01:54:04PM -0400, Michael Scheidell
escribió:
On 5/28/12 1:51 PM, Matthias Apitz wrote:
Yes, but first I tried exactly the same procedure to update 5.8 to 5.12,
because the Makefile of p5-Mail-SpamAssassin asked for 5.12; but 5.12
is not enough to make p5-Mail-SpamAssassin building, at least not in my
ports tree;
update procedures for 5.8 to 5.12 are different.
if you look into UPDATING it says in 20110622:
...
If you want to switch to lang/perl5.12 from lang/perl5.{8,10} please
follow instructions in the entry 20100715 in this file.
and I followed exactly the procedire recommended in 20100715;
and, I got a bizillian commercial systems out there with perl 5.12.4 and
spamassassin, built and run fine.
(and logs to prove it builds just fine)
it did not built in my CVS based ports tree with perl5.12; sorry
grep ^PERL_VERSION /etc/make.conf
?
Chris
___
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: math/sage security risk
On 28 May 2012 10:14, Stephen Montgomery-Smith step...@missouri.edu wrote: After my recent conversations about creating a print/texlive-install port, I realize that my math/sage port might have a security risk. This only happens if the user selects additional optional packages. But the optional packages are downloaded post-fetch. I'll make some immediate band-aid changes to the port to switch this off, but I'll think through the issue in the days to come. adding ports-security to cc so we could track the issue -- Eitan Adler ___ 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: 10-CURRENT r235646 ports/mail/p5-Mail-SpamAssassin
El día Monday, May 28, 2012 a las 07:38:34PM +0100, Chris Rees escribió:
if you look into UPDATING it says in 20110622:
...
If you want to switch to lang/perl5.12 from lang/perl5.{8,10} please
follow instructions in the entry 20100715 in this file.
and I followed exactly the procedire recommended in 20100715;
and, I got a bizillian commercial systems out there with perl 5.12.4 and
spamassassin, built and run fine.
(and logs to prove it builds just fine)
it did not built in my CVS based ports tree with perl5.12; sorry
grep ^PERL_VERSION /etc/make.conf
# grep ^PERL_VERSION /etc/make.conf
PERL_VERSION=5.14.2
matthias
--
Matthias Apitz
e g...@unixarea.de - w http://www.unixarea.de/
UNIX since V7 on PDP-11, UNIX on mainframe since ESER 1055 (IBM /370)
UNIX on x86 since SVR4.2 UnixWare 2.1.2, FreeBSD since 2.2.5
___
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: 10-CURRENT r235646 ports/mail/p5-Mail-SpamAssassin
On 28 May 2012 19:40, Matthias Apitz g...@unixarea.de wrote:
El día Monday, May 28, 2012 a las 07:38:34PM +0100, Chris Rees escribió:
if you look into UPDATING it says in 20110622:
...
If you want to switch to lang/perl5.12 from lang/perl5.{8,10} please
follow instructions in the entry 20100715 in this file.
and I followed exactly the procedire recommended in 20100715;
and, I got a bizillian commercial systems out there with perl 5.12.4 and
spamassassin, built and run fine.
(and logs to prove it builds just fine)
it did not built in my CVS based ports tree with perl5.12; sorry
grep ^PERL_VERSION /etc/make.conf
# grep ^PERL_VERSION /etc/make.conf
PERL_VERSION=5.14.2
Ah of course, you've upgraded. You'll probably find it was wrong when
you were on perl-5.12 for some reason.
Chris
___
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: math/sage security risk
On 05/28/2012 01:38 PM, Eitan Adler wrote: On 28 May 2012 10:14, Stephen Montgomery-Smithstep...@missouri.edu wrote: After my recent conversations about creating a print/texlive-install port, I realize that my math/sage port might have a security risk. This only happens if the user selects additional optional packages. But the optional packages are downloaded post-fetch. I'll make some immediate band-aid changes to the port to switch this off, but I'll think through the issue in the days to come. adding ports-security to cc so we could track the issue I just committed instructions to the port math/sage telling users how to add the optional packages manually, and explaining the security risk. Please contact me if this is still a problem. ___ 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: math/sage security risk
On 28 May 2012 13:14, Stephen Montgomery-Smith step...@missouri.edu wrote: I just committed instructions to the port math/sage telling users how to add the optional packages manually, and explaining the security risk. We have a more general problem here of ports fetching post-fetch. I know others have brought this up already but count me in as someone who would like to see a fix already :) Please contact me if this is still a problem. This seems adequate for now -- Eitan Adler ___ 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: Request to review: print/texlive-install
On Mon, 28 May 2012 11:53:29 -0500, Stephen Montgomery-Smith wrote: [...] This looks non-trivial. Simply setting the setuid bit on the tlmgr script doesn't work, because it is a perl script. One way would be to write a wrapper. But I would recommend the port security/super which allows you to create scripts that can be run with setuid. Then let the user set this up as they desire. I see. Didn't know for security/super - thanks for the info. Yet another observation: CONFLICTS - besides what you put in the Makefile, a quick look shows that this port conflicts with at least these ports: japanese/makejvf japanese/ptex print/detex print/dvi2tty print/dvipdfmx print/dvips print/dviselect print/jadetex print/latex print/latexmk print/lcdf-typetools print/makeindex print/musixtex print/ps2eps print/psutils* print/t1utils print/xdvi print/xmltex textproc/lacheck textproc/teckit -- Nikola Lečić = Никола Лечић fingerprint : FEF3 66AF C90E EDC3 D878 7CDC 956D F4AB A377 1C9B ___ 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: lame-3.99.5
hi there - when trying to install lame on my fresh new freebsd - I get the following error msg. Anything I can do to help resolve? murugan02# pkg_add -r lame Error: Unable to get ftp://ftp.freebsd.org/pub/FreeBSD/ports/amd64/packages-9.0-release/Latest/lame.tbz: File unavailable (e.g., file not found, no access) pkg_add: unable to fetch ' ftp://ftp.freebsd.org/pub/FreeBSD/ports/amd64/packages-9.0-release/Latest/lame.tbz' by URL Best. -- Shiva (404) 798-2449 www.linkedin.com/in/subramanian ___ 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: Request to review: print/texlive-install
On 5/28/2012 9:35 AM, Gábor Kövesdán wrote: Better to host it on the FreeBSD mirrors. The more we can diversify out to other sites, the better. It's fine to have the FreeBSD mirrors as a last resort, but they shouldn't be the first choice. Doug -- This .signature sanitized for your protection ___ 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: PHP 5.4.0 : lang/php54
On 5/21/2012 9:40 AM, Miroslav Lachman wrote: I think that the best will be to not have any default php5 port and just use php52, php53, php54, php5X, php60... as we have apache20, apache22, apache24, or mysql50-server, mysql51-server, mysql55-server. There is no default apache2 or mysql5-server, so there is no confusion what is / what will be installed. Then it can be choosed in make.conf what version will be used as default, similar to WITH_MYSQL_VER=51 or APACHE_PORT=www/apache22 I have been advocating for this for years. IMO we shouldn't have *any* unversioned ports for things that have multiple simultaneous versions supported. I've actually done this for the things I support (most notably bind*) for a long time, and have never had a single user complaint. OTOH, the user confusion, broken systems, and generally huge amount of hassle caused by moving the default version of an important port like php to one that isn't compatible with the previous default only has downsides. In the days when the total number of ports, and the number of versioned ports, were both much smaller, the idea of a default version made sense. Neither has been true for a decade or more. Doug -- This .signature sanitized for your protection ___ 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: lame-3.99.5
On Mon, May 28, 2012 at 9:12 PM, Shiva Subramanian sh...@subbu.us wrote: hi there - when trying to install lame on my fresh new freebsd - I get the following error msg. Anything I can do to help resolve? murugan02# pkg_add -r lame Error: Unable to get ftp://ftp.freebsd.org/pub/FreeBSD/ports/amd64/packages-9.0-release/Latest/lame.tbz: File unavailable (e.g., file not found, no access) pkg_add: unable to fetch ' ftp://ftp.freebsd.org/pub/FreeBSD/ports/amd64/packages-9.0-release/Latest/lame.tbz' by URL I don't believe that lame is ever packaged for legal reasons. You will need to build it yourself, if you want it. Binary distribution would require FreeBSD to license it (clearly a non-starter), so there is none. lame is not unique in this regard. -- R. Kevin Oberman, Network Engineer E-mail: kob6...@gmail.com ___ 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
