PDF viewer for editable PDFs
anyone knows a program that can do this. I use xpdf for normal PDFs, but people are using PDF as forms, and acrobat do support it. Yes i know there is acroread9 in ports, but i would like to have something opensource and NOT taking 100% CPU just because i started it. thanks :) ___ 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
[RFC] lang/pypy
Hi All.
After many months of (sporadic) work I would like to introduce pypy-2.0.b1.
Could you please have a look at, and test, my proposed changes (attached) and
the wiki page at http://wiki.FreeBSD.org/PyPy.
I would like to commit these changes (after incorporating feedback) sometime
next week. Feel free to update the wiki yourselves ;-).
Regards
David
P.S. Please keep my mentors CCed in any discussions :-)
Index: pypy/Makefile
===
--- pypy/Makefile (revision 312473)
+++ pypy/Makefile (working copy)
@@ -2,8 +2,7 @@
# $FreeBSD$
PORTNAME= pypy
-DISTVERSION= 1.9
-PORTREVISION= 2
+DISTVERSION= 2.0-beta1
CATEGORIES= lang python java
MASTER_SITES= https://bitbucket.org/pypy/pypy/get/
DISTNAME= release-${DISTVERSION}
@@ -18,18 +17,30 @@
LIB_DEPENDS= expat:${PORTSDIR}/textproc/expat2 \
ffi:${PORTSDIR}/devel/libffi
-OPTIONS_DEFINE= SANDBOX
+CLI_DESC= (BROKEN) Translate a CLI (.NET) based pypy
+JVM_DESC= (BROKEN) Translate a JVM (Java) based pypy
+PYPY_DESC= Use pypy to translate (faster but uses more memory)
SANDBOX_DESC= Translate a sandboxed pypy
+.if !defined(PYPY_INST)
+OPTIONS_DEFINE+= CLI JVM SANDBOX
+.endif
+LOCALBASE?= /usr/local
+.if exists(${LOCALBASE}/bin/pypy)
+OPTIONS_DEFINE+= PYPY
+.endif
+ALL_TARGET= ${PYPY_NAMES}
BUILD_WRKSRC= ${WRKDIR}
USE_BZIP2= yes
USE_ICONV= yes
USE_GETTEXT= yes
+MAKE_JOBS_SAFE= yes
+MAKEFILE= ${FILESDIR}/Makefile
PKGINSTALL= ${WRKDIR}/pkg-install
PKGDEINSTALL= ${WRKDIR}/pkg-deinstall
-WRKSRC= ${WRKDIR}/pypy-pypy-341e1e3821ff
+WRKSRC= ${WRKDIR}/pypy-pypy-fcb6b056f00e
-PYPY_VER= ${DISTVERSION}
+PYPY_VER= ${DISTVERSION:C|([0-9])\.([0-9]).*|\1.\2|}
PYTHON_IMPL_VER= 2.7
PYPY_LIBDIR= lib/pypy${PYPY_VER}
PYPY_INCLUDEDIR= include/pypy${PYPY_VER}
@@ -38,20 +49,26 @@
PLIST_SUB+= PYPY_LIBDIR=${PYPY_LIBDIR} \
PYPY_INCLUDEDIR=${PYPY_INCLUDEDIR}
-MAKE_ENV+= PYPY_LOCALBASE=${LOCALBASE}
-.if exists(/usr/bin/clang)
-MAKE_ARGS+= CC=clang
-MAKE_JOBS_SAFE= yes
-.endif
+MAKE_ENV+= DISTVERSION=${DISTVERSION} PYTHON_CMD=${PYTHON_CMD} \
+ WRKSRC=${WRKSRC} PYPY_LOCALBASE=${LOCALBASE}
-# XXX !.include bsd.port.pre.mk as USE_* need to be set prior
.include bsd.port.options.mk
-.include ${.CURDIR}/files/bsd.pypy.inst.mk
+.include ${MASTERDIR}/files/bsd.pypy.inst.mk
-.if defined(PACKAGE_BUILDING)
-MANUAL_PACKAGE_BUILD= fails to finish compilation on pointyhat, reason unknown
+.if ${OSVERSION} 124 || ( ${ARCH} != i386 ${ARCH} != amd64 )
+.if ${CC:T} == cc ( exists(/usr/bin/clang) || exists(${LOCALBASE}/clang) )
+CC= clang
+.else
+USE_GCC= yes
.endif
+.endif
+.if ${PORT_OPTIONS:MPYPY} || defined(PYTHON_CMD)
+PYTHON_CMD?= ${LOCALBASE}/bin/pypy
+.else
+USE_PYTHON_BUILD= 2.5+
+.endif
+
# List of PyPy instances
.if !defined(PYPY_INST)
PYPY_INST= DEFAULT
@@ -60,13 +77,26 @@
PYPY_INST+= SANDBOX
.endif
+.if ${PORT_OPTIONS:MCLI}
+PYPY_INST+= CLI
+.endif
+
+.if ${PORT_OPTIONS:MJVM}
+PYPY_INST+= JVM
+.endif
+
.endif # !defined(PYPY_INST)
-PYPY_NAMES=
+MAKE_ENV+= PYPY_INST=${PYPY_INST}
+
.for inst in ${PYPY_INST}
PYPY_NAMES+= ${PYPY_${inst}_NAME}
PYPY_PRIMARY?= ${PYPY_${inst}_NAME}
+MAKE_ENV+= PYPY_${inst}_NAME=${PYPY_${inst}_NAME} \
+ PYPY_${inst}_OBJSPACE_ARGS=${PYPY_${inst}_OBJSPACE_ARGS} \
+ PYPY_${inst}_OPT=${PYPY_${inst}_OPT} \
+ PYPY_${inst}_TRANSLATE_ARGS=${PYPY_${inst}_TRANSLATE_ARGS}
# Check if the boehm GC will be used
.if ${PYPY_${inst}_OPT} == 0 || ${PYPY_${inst}_OPT} == 1 || ${PYPY_${inst}_OPT} == size
@@ -85,24 +115,6 @@
.endfor # inst in ${PYPY_INST}
-# Use pypy if it is installed, else use python (to translate)
-.if !defined(PY)
-.if !defined(PYPY)
-.if ${PYPY_PRIMARY} == pypy
-PYPY!= ${WHICH} ${PYPY_PRIMARY} 2 /dev/null || true
-.else
-PYPY!= ${WHICH} ${PYPY_PRIMARY} 2 /dev/null || ${WHICH} pypy 2 /dev/null || true
-.endif
-.endif # !defined(PYPY)
-
-.if exists(${PYPY})
-PY= ${PYPY}
-.else
-USE_PYTHON_BUILD= 2.5+
-PY= ${PYTHON_CMD}
-.endif
-.endif # !defined(PY)
-
.if defined(WITH_BOEHM_GC)
LIB_DEPENDS+= gc.1:${PORTSDIR}/devel/boehm-gc
.endif
@@ -117,7 +129,7 @@
.if defined(WITH_JVM)
USE_JAVA= yes
-JAVA_VERSION= 1.6+
+JAVA_VERSION= 1.5+
ONLY_FOR_ARCHS= i386 powerpc
ONLY_FOR_ARCHS_REASON= only translates on 32bit systems
BROKEN= JVM backend broken, partially supported upstream
@@ -149,19 +161,59 @@
.endfor # inst in ${PYPY_INST}
.endif # !defined(PYPY_JITTABLE)
-pre-fetch:
- @${ECHO} PyPy requires a large amount of free RAM and time to translate and compile.
- @${ECHO}
- @${ECHO} To translate, PyPy requires on 32bit 3G (min 2G) free RAM and on 64bit
- @${ECHO} 6G (min 4G) free RAM. Also, to compile, PyPy on amd64 gcc requires an
- @${ECHO} extra 4G however clang only requires 400M (CC=clang) but clang is slower
- @${ECHO} in compiling PyPy.
- @${ECHO}
- @${ECHO} If memory is in short supply consider using a lower optimisation level
- @${ECHO} (e.g. PYPY_DEFAULT_OPT=2) however that makes PyPy much slower. Also,
- @${ECHO}
Re: PDF viewer for editable PDFs
Hi Wojciech, On 2 March 2013 11:44, Wojciech Puchar woj...@wojtek.tensor.gdynia.pl wrote: anyone knows a program that can do this. I use xpdf for normal PDFs, but people are using PDF as forms, and acrobat do support it. Yes i know there is acroread9 in ports, but i would like to have something opensource and NOT taking 100% CPU just because i started it. I believe evince supports form filling of PDFs, but I don't know if it's a little heavyweight for you. It's definitely an improvement on Adobe Reader. Chris http://en.wikipedia.org/wiki/List_of_PDF_software#Viewers ___ 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 for redirecting printer
El día Saturday, March 02, 2013 a las 04:49:05PM +0100, Bernt Hansson escribió: $ lpr -Pfoo myfile.txt And now? Big silence? Nobody wants to step-up with a proposal? :-) You have already proposed the correct answer. /usr/bin/lpr -Pbar file instead of your cups /usr/local/bin/lpr Well, and which tool/filter (and fonts) to the painting of UTF-8 files to Postscript exactly? The ones in the printer. What modell of printer? I only know very high end printers (with harddisks) able to understand UTF-8 directly. But maybe you have a better idea... matthias -- Matthias Apitz | /\ ASCII Ribbon Campaign: www.asciiribbon.org E-mail: g...@unixarea.de | \ / - No HTML/RTF in E-mail WWW: http://www.unixarea.de/ | X - No proprietary attachments phone: +49-170-4527211 | / \ - Respect for open standards ___ 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: PDF viewer for editable PDFs
Wojciech Puchar woj...@wojtek.tensor.gdynia.pl writes: anyone knows a program that can do this. I use xpdf for normal PDFs, but people are using PDF as forms, and acrobat do support it. Yes i know there is acroread9 in ports, but i would like to have something opensource and NOT taking 100% CPU just because i started it. Personally, I prefer letting my computer work harder instead of me, but even the Acrobat reader doesn't handle all files; it's good to have multiple options. I would recommend trying several. pdfedit is the main one for filling out forms. The annoying situation is when the PDF file isn't really designed for editing. In that case, the only option I've found is to go in with a graphical editor and layer my changes on top. ___ 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: java/openjdk6 fails to build..
Hi all, i`m have the same problem, and I try to use MAKE_JOBS_NUMBER=1 in /etc/make.conf and it`s not work I put -DMAKES_JOBS_UNSAFE in make command line too make config-recursive fetch-recursive install clean -DMAKES_JOBS_UNSAFE and it`s not work too my box: Athlon 64 X2 4GB of RAM valvenda# uname -a FreeBSD valvenda 9.1-STABLE FreeBSD 9.1-STABLE #0 r247209: Sat Mar 2 12:56:12 BRT 2013 rizzo@valvenda:/usr/src/sys/amd64/compile/VALVENDA amd64 -- View this message in context: http://freebsd.1045724.n5.nabble.com/java-openjdk6-fails-to-build-tp5771110p5792045.html Sent from the freebsd-ports mailing list archive at Nabble.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
Firefox 19 vs large images
Viewing large images has become cumbersome with the switch from Firefox 18 to 19. Am I the only one to notice this? Wikipedia's high-resolution pictures of the day are great for this: https://upload.wikimedia.org/wikipedia/commons/e/e9/Bison_skull_pile_edit.jpg What happens is that Firefox loads the image and then does some sort of operation that causes the X11 server to be busy for a noticeable amount of time. During this time the whole X11 session hangs. If you have a network login, you can see the Xorg process eat all the CPU it can get. The duration of this delay varies and depends on the size of the image; with the one above it just took 30 seconds. This isn't entirely new. With previous versions of Firefox it happened when I accidentally dragged an image. But now with Firefox 19, just viewing the image is enough. Needless to say, this is painful if you are going through a number of large images and are forced to pause for half a minute each. I don't know if this happens for all video drivers. I'm running Xorg 1.7.7 with radeon(4x) on an ATI RV370 (Radeon X300SE) card, 7.4-STABLE/amd64. -- Christian naddy Weisgerber na...@mips.inka.de ___ 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: Firefox 19 vs large images
On 02.03.2013 18:53 (UTC+2), Christian Weisgerber wrote: Viewing large images has become cumbersome with the switch from Firefox 18 to 19. Am I the only one to notice this? Today there started a thread about this on the german bsdforen with several 'me toos': http://www.bsdforen.de/showthread.php?p=248950#post248950 Posting #11 could be a useful first hint. Wikipedia's high-resolution pictures of the day are great for this: https://upload.wikimedia.org/wikipedia/commons/e/e9/Bison_skull_pile_edit.jpg What happens is that Firefox loads the image and then does some sort of operation that causes the X11 server to be busy for a noticeable amount of time. During this time the whole X11 session hangs. If you have a network login, you can see the Xorg process eat all the CPU it can get. The duration of this delay varies and depends on the size of the image; with the one above it just took 30 seconds. This isn't entirely new. With previous versions of Firefox it happened when I accidentally dragged an image. But now with Firefox 19, just viewing the image is enough. Needless to say, this is painful if you are going through a number of large images and are forced to pause for half a minute each. I don't know if this happens for all video drivers. I'm running Xorg 1.7.7 with radeon(4x) on an ATI RV370 (Radeon X300SE) card, 7.4-STABLE/amd64. For me it happens on 10.0-CURRENT/amd64 with xorg-7.5.2, xorg-server-1.10.6_2,1, nvidia-driver 313.18 (from patched port) and firefox-19.0,1. ___ 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: Firefox 19 vs large images
On 02.03.13 19:15, Rainer Hurling wrote: On 02.03.2013 18:53 (UTC+2), Christian Weisgerber wrote: Viewing large images has become cumbersome with the switch from Firefox 18 to 19. Am I the only one to notice this? Can anybody try with firefox 20.0b2? You might need to replace bsd.gecko.mk with the version from the gecko repo to build it, I'm not 100% certain right now. You can check everything out from: https://trillian.chruetertee.ch/svn/freebsd-gecko/trunk There is even a firefox-nightly if you are more adventurous. Thanks, Florian signature.asc Description: OpenPGP digital signature
dependency firefox-py-sqlite3 is broken
Hi,
www/firefox (19.0;1) Makefile shows dependency:
${PYTHON_SITELIBDIR}/_sqlite3.so:${PORTSDIR}/databases/py-sqlite3
so it searches for /usr/local/lib/python2.7/site-packages/_sqlite3.so;
OTOH built package (py27-sqlite3-2.7.3_3) contains:
/usr/local/lib/python2.7/lib-dynload/_sqlite3.so
so it remakes the py-sqlite3 package and fails on attempt to install
it.
py-sqlite3 port Makefile contains explicit request for library
placement:
PYDISTUTILS_INSTALLARGS+= --install-lib ${PYTHON_LIBDIR}/lib-dynload
Ports are fresh a few minutes ago, system is 9.1.
Which directory assignment is correct?
-netch-
___
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: java/openjdk6 fails to build..
njrizzo ri...@i805.com.br writes: i`m have the same problem, and I try to use MAKE_JOBS_NUMBER=1 in /etc/make.conf and it`s not work That's not a good idea; it will apply to everything, not just this one port. I put -DMAKES_JOBS_UNSAFE in make command line too You have an extra 'S' in there; the variable should be MAKE_JOBS_UNSAFE. make config-recursive fetch-recursive install clean -DMAKES_JOBS_UNSAFE With default options and an up-to-date RELENG_9 and ports tree, that works fine for me (I tried it without the variable definition, but since the variable isn't used in any makefile, that shouldn't make any difference. Sorry, but since the problem seems to be on your end, we can't help you unless you show us enough detail to see what actually went wrong. Saying it doesn't work is not enough to figure out *how* it went wrong. ___ 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: Firefox 19 vs large images
Florian, thanks for the hint. On 02.03.2013 19:58 (UTC+2), Florian Smeets wrote: On 02.03.13 19:15, Rainer Hurling wrote: On 02.03.2013 18:53 (UTC+2), Christian Weisgerber wrote: Viewing large images has become cumbersome with the switch from Firefox 18 to 19. Am I the only one to notice this? Can anybody try with firefox 20.0b2? I tried 20.0b2 and it seems to have the same problems with bigger images as 19.0 :( Interesting is, that the freezing time depends on the size of the image and that the freeze does not happen again for the same image, as long as it is loaded. You might need to replace bsd.gecko.mk with the version from the gecko repo to build it, I'm not 100% certain right now. There is no need for this, since the repo has r310207 and in the ports tree is r312869. You can check everything out from: https://trillian.chruetertee.ch/svn/freebsd-gecko/trunk There is even a firefox-nightly if you are more adventurous. Thanks, Florian On BSDforen.de they talk about some progress, made by the ubuntu folks: http://www.bsdforen.de/showpost.php?p=248952postcount=13 and from there https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1134409 Regards, 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: Firefox 19 vs large images
On Saturday, March 02, 2013 10:23:14 PM Rainer Hurling wrote: Florian, thanks for the hint. On 02.03.2013 19:58 (UTC+2), Florian Smeets wrote: On 02.03.13 19:15, Rainer Hurling wrote: On 02.03.2013 18:53 (UTC+2), Christian Weisgerber wrote: Viewing large images has become cumbersome with the switch from Firefox 18 to 19. Am I the only one to notice this? ... On BSDforen.de they talk about some progress, made by the ubuntu folks: http://www.bsdforen.de/showpost.php?p=248952postcount=13 and from there https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1134409 The referenced bug is specific to ubuntu. The affected code is not present in ports. The diff is available here: https://launchpad.net/ubuntu/+source/firefox/19.0+build1-0ubuntu0.12.10.2 ___ 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: Firefox 19 vs large images
Rainer Hurling: Interesting is, that the freezing time depends on the size of the image and that the freeze does not happen again for the same image, as long as it is loaded. If you have images in two tabs and you switch back and forth, you get a freeze each time you switch tabs. On BSDforen.de they talk about some progress, made by the ubuntu folks: Time waster. The linked issues have no relation to the problem under discussion. http://www.bsdforen.de/showpost.php?p=248952postcount=13 and from there https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1134409 That concerns a problem with the globalmenu extension, which Debian includes by default (but we don't). And USN-1729-1 references a bunch of problems that all affect Mozilla Firefox before 19.0, and the recommended fix is to update to Firefox 19. http://www.ubuntuupdates.org/package/core/quantal/main/security/firefox http://www.ubuntu.com/usn/usn-1729-1/ -- Christian naddy Weisgerber na...@mips.inka.de ___ 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
Python libraries moved
It looks like a port revision made a few hours ago has broken firefox
(and most likely a bunch of other ports). In the makefile for
firefox, it has the following checks for dependencies:
BUILD_DEPENDS= nspr=4.9.4:${PORTSDIR}/devel/nspr \
nss=3.14.1:${PORTSDIR}/security/nss \
sqlite3=3.7.14.1:${PORTSDIR}/databases/sqlite3 \
${PYTHON_SITELIBDIR}/_sqlite3.so:${PORTSDIR}/databases/py-sqlite3 \
As you can see, it looks for _sqlite3.so in ${PYTHON_SITELIBDIR} which
points to the old location for this library. The revision to python
and its libraries has moved the location of these libraries to
lib-dynload
This is the revision in question:
http://svnweb.freebsd.org/ports?view=revisionrevision=313167
This has broken firefox and most likely all other ports that look for
libraries in ${PYTHON_SITELIBDIR}
___
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: Python libraries moved
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sun, Mar 03, 2013 at 12:08:41AM -0500, Robert Simmons wrote:
It looks like a port revision made a few hours ago has broken firefox
(and most likely a bunch of other ports). In the makefile for
firefox, it has the following checks for dependencies:
BUILD_DEPENDS= nspr=4.9.4:${PORTSDIR}/devel/nspr \
nss=3.14.1:${PORTSDIR}/security/nss \
sqlite3=3.7.14.1:${PORTSDIR}/databases/sqlite3 \
${PYTHON_SITELIBDIR}/_sqlite3.so:${PORTSDIR}/databases/py-sqlite3 \
As you can see, it looks for _sqlite3.so in ${PYTHON_SITELIBDIR} which
points to the old location for this library. The revision to python
and its libraries has moved the location of these libraries to
lib-dynload
This is the revision in question:
http://svnweb.freebsd.org/ports?view=revisionrevision=313167
This has broken firefox and most likely all other ports that look for
libraries in ${PYTHON_SITELIBDIR}
This is fixed please update your portstree.
- - Martin
___
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
- --
+-oOO--(_)--OOo-+
With best Regards,
Martin Wilke (miwi_(at)_FreeBSD.org)
Mess with the Best, Die like the Rest
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (FreeBSD)
iEYEARECAAYFAlEy6WEACgkQdLJIhLHm/OlXlwCfRXWOPSk2cJ725IjYx9jeEy1+
Pb8AoL34Lr6ffYhsMeQgU8SreN8U6P4+
=3TVO
-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: Python libraries moved
Sorry, what was the change you made?
On Sun, Mar 3, 2013 at 1:10 AM, Martin Wilke m...@freebsd.org wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sun, Mar 03, 2013 at 12:08:41AM -0500, Robert Simmons wrote:
It looks like a port revision made a few hours ago has broken firefox
(and most likely a bunch of other ports). In the makefile for
firefox, it has the following checks for dependencies:
BUILD_DEPENDS= nspr=4.9.4:${PORTSDIR}/devel/nspr \
nss=3.14.1:${PORTSDIR}/security/nss \
sqlite3=3.7.14.1:${PORTSDIR}/databases/sqlite3 \
${PYTHON_SITELIBDIR}/_sqlite3.so:${PORTSDIR}/databases/py-sqlite3 \
As you can see, it looks for _sqlite3.so in ${PYTHON_SITELIBDIR} which
points to the old location for this library. The revision to python
and its libraries has moved the location of these libraries to
lib-dynload
This is the revision in question:
http://svnweb.freebsd.org/ports?view=revisionrevision=313167
This has broken firefox and most likely all other ports that look for
libraries in ${PYTHON_SITELIBDIR}
This is fixed please update your portstree.
- - Martin
___
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
- --
+-oOO--(_)--OOo-+
With best Regards,
Martin Wilke (miwi_(at)_FreeBSD.org)
Mess with the Best, Die like the Rest
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (FreeBSD)
iEYEARECAAYFAlEy6WEACgkQdLJIhLHm/OlXlwCfRXWOPSk2cJ725IjYx9jeEy1+
Pb8AoL34Lr6ffYhsMeQgU8SreN8U6P4+
=3TVO
-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
