Re: x11-toolkits/xview requires COMPAT_43TTY defined to build on -CURRENT
Mel Flynn wrote: So, the real fix should come from upstream. For the time being, this should work, marked MAKE_JOBS_UNSAFE while I was in there. The OSVERSION leaves a three week hole where things won't work, but that should be acceptable. Thank you for the patch. I'm guessing an upstream fix is pretty unlikely. I'd be surprised if there were even 10 people still using xview for anything other than legacy apps. My interest is because it's a dependency for sysutils/contool. and unfortunately it may all be pointless anyway because contool won't run on my system for reasons i have yet to determine. Thanks, tom ___ 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: ports/*/jpeg "Thanks a lot guys"
Doug Barton wrote: Garrett Cooper wrote: Gentoo Linux (I know -- Gentoo + Linux -- we're FreeBSD... blah :P) has a script called `revdep-rebuild' which goes and runs ldd on all pieces of software that are installed in portage (ok, substitute ports here). What I'm driving at is that we can use pkg_info and/or the mtree generated files to determine what files are installed, find out which packages have been broken up an update, then rebuild the port and all dependencies (LIB_DEPENDS?). What say you to that :)? I was experimenting with various scripts using ldd in parallel to my most recent portmaster update and I think there is a problem with that solution. If libA is linked against libB which in turn is linked against libMISSING (such as libjpeg.so.9 for example) then ldd against libA will show libMISSING even though that problem can be solved by simply updating libB (i.e., without recompiling libA). This same issue applies to the idea of running ldd against things at install time and recording the list. Is that sufficient? If the ABI changes to libMISSING change its size such that it uses a different number of 4k memory pages, doesn't that change the load address of any subsequently loaded shlibs? Showing direct vs indirect linkage seems to be what 'ldd -a' does, although I think given the above you'ld have to rebuild anything that linked, directly or indirectly, against libMISSING. Perhaps someone smarter than I about ldd can come up with a solution to this, but until then I think that using ldd after the fact is a stopgap measure to repair things if the ports infrastructure fails us. A script for scanning the ldd(1) output would be useful for port maintainers primarily IMHO. In theory the dependency graphing in our existing ports infrastructure should deal with this problem. In practice at the moment I personally feel that we record too many "indirect" dependencies (such as libA above) and that we would serve our users better if we stuck to direct dependencies only (libB in the example above). What should have happened in this case is that the ports that depend DIRECTLY on libjpeg should have had their revisions bumped at the same time as the update to libjpeg. Since that is what usually happens, hopefully we can stop flogging this horse soon. What usually seems to happen is that any port with a RUN_DEPENDS on the port providing the shlib in question gets a portrevision bump, including many where it makes no sense to do so. Tracking LIB_DEPENDS would be my choice for dealing with this problem, but as you say, there would need to be a ports-wide review and rationalisation of LIB_DEPENDS settings. That said, if anyone really really wants to pursue the dependency graphing issue further, can I suggest a new thread focused on that topic? What's wrong with the thread we've already got? Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate Kent, CT11 9PW signature.asc Description: OpenPGP digital signature
Re: x11-toolkits/xview requires COMPAT_43TTY defined to build on -CURRENT
On Monday 03 August 2009 19:09:49 Tom Uffner wrote:
> Mel Flynn wrote:
> > On Saturday 01 August 2009 15:34:34 Tom Uffner wrote:
> >> x11-toolkits/xview requires COMPAT_43TTY defined to build on -CURRENT
> >
> > In your kernel config.
>
> no. it was in my kernel config. my problem was that the port would not
> compile w/o the definition in the port makefiles.
Right, my bad, did my testing on a 7.x machine with my brain screwed on
wrong. Anyway, interesting reading in the svn log:
r191919 | ed | 2009-05-08 12:06:37 -0800 (Fri, 08 May 2009) | 9 lines
Burn TTY ioctl bridges in compat layers.
I really don't want any pieces of code to include ioctl_compat.h, so let
the ibcs2 and svr4 compat leave sgtty alone. If they want to support
sgtty, they should emulate it on top of termios, not sgtty.
The code has been marked with BURN_BRIDGES for a long time. ibcs2 and
svr4 are not really popular pieces of code anyway.
-
So, the real fix should come from upstream. For the time being, this
should work, marked MAKE_JOBS_UNSAFE while I was in there. The OSVERSION
leaves a three week hole where things won't work, but that should be
acceptable.
--- x11-toolkits/xview/Makefile.orig2009-08-03 21:38:34.0 -0800
+++ x11-toolkits/xview/Makefile 2009-08-03 22:05:39.0 -0800
@@ -32,12 +32,16 @@
SUB_FILES= pkg-message
MAN1= xview.1
+MAKE_JOBS_UNSAFE= yes
X11BASE2FIX= clients/olwmslave/help_file.c lib/libxview/help/help_file.c
\
lib/libxview/misc/gettext.h lib/libxview/textsw/txt_e_menu.c
.include
+.if ${OSVERSION} > 800089
+CFLAGS+= -DCOMPAT_43TTY
+.endif
pre-configure:
@${REINPLACE_CMD} -e 's+/usr/local+${PREFIX}+;' \
${WRKSRC}/config/XView.cf
--
Mel
___
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: x11-toolkits/xview requires COMPAT_43TTY defined to build on -CURRENT
Mel Flynn wrote: On Saturday 01 August 2009 15:34:34 Tom Uffner wrote: x11-toolkits/xview requires COMPAT_43TTY defined to build on -CURRENT In your kernel config. no. it was in my kernel config. my problem was that the port would not compile w/o the definition in the port makefiles. ___ 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"
INDEX now builds successfully on 8.x
___ 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 broken on recent -current?
On Monday 03 August 2009 15:56:55 Dmitry Marakasov wrote: > % uname -a > FreeBSD hades.panopticon 8.0-BETA2 FreeBSD 8.0-BETA2 #0: Fri Jul 31 > 16:00:15 MSD 2009 root@:/usr/obj/usr/src/sys/HADES i386 (cvsup > date=2009.07.30.12.00.00) > > % pkg_info | grep jdk > diablo-jdk-1.6.0.07.02_5 Java Development Kit 1.6.0_07.02 Thou shall search the archives before posting. The short and curlies: % cat /etc/libmap.conf [/usr/local/share/opera/bin/opera] libz.so.4 libz.so.5 [/usr/local/diablo-jdk1.6.0/] libz.so.4 libz.so.5 Or set the map globally, if you don't care finding out "what else is broken". -- Mel ___ 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"
java broken on recent -current?
% uname -a FreeBSD hades.panopticon 8.0-BETA2 FreeBSD 8.0-BETA2 #0: Fri Jul 31 16:00:15 MSD 2009 root@:/usr/obj/usr/src/sys/HADES i386 (cvsup date=2009.07.30.12.00.00) % pkg_info | grep jdk diablo-jdk-1.6.0.07.02_5 Java Development Kit 1.6.0_07.02 % java Error occurred during initialization of VM Unable to load ZIP library: /usr/local/diablo-jdk1.6.0/jre/lib/i386/libzip.so % ldd /usr/local/diablo-jdk1.6.0/jre/lib/i386/libzip.so /usr/local/diablo-jdk1.6.0/jre/lib/i386/libzip.so: /libexec/ld-elf.so.1: /usr/local/diablo-jdk1.6.0/jre/lib/i386/libzip.so: Unexpected inconsistency: dependency libjvm.so not found /usr/local/diablo-jdk1.6.0/jre/lib/i386/libzip.so: exit status 1 % file `locate libjvm.so` /usr/local/diablo-jdk1.6.0/jre/lib/i386/client/libjvm.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (FreeBSD), dynamically linked, not stripped /usr/local/diablo-jdk1.6.0/jre/lib/i386/server/libjvm.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (FreeBSD), dynamically linked, not stripped -- Dmitry Marakasov . 55B5 0596 FF1E 8D84 5F56 9510 D35A 80DD F9D2 F77D amd...@amdmi3.ru ..: jabber: amd...@jabber.ruhttp://www.amdmi3.ru ___ 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: apr-gdbm-db42 upgrade conflicting with libtool
I also have problems: uname -a FreeBSD dns1.vizion2000.net 7.2-RELEASE-p2 FreeBSD 7.2-RELEASE-p2 #0: Wed Jun 24 00:14:35 UTC 2009 r...@amd64- builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 buildconf: checking installation... buildconf: python not found. You need python installed to build APR from SVN. Whats in your /etc/make.conf and related? $ make -V PYTHON -V PYTHON_VER What do the symlinks look like in /usr/local/bin/py* ? http://tb.p6m7g8.net/logs/8-CURRENT-amd64/apr-ipv6-gdbm-db42-1.3.7.1.3.8.log I've built it on well over 20 tbs with different configs, and on 6-stable, 7-stable, 8-stable, and on amd64/i386. I've seen 3 issues so far on the lists, all are local to the users in question. I'd like to help with it, but I don't know where to start, and they aren't problems with apr itself. IMHO, when in doubt -- pkg_delete -af make install done. -- 1024D/DB9B8C1C B90B FBC3 A3A1 C71A 8E70 3F8C 75B8 8FFB DB9B 8C1C Philip M. Gollucci (pgollu...@p6m7g8.com) c: 703.336.9354 Consultant - P6M7G8 Inc.http://p6m7g8.net Senior Sys Admin- RideCharge, Inc. http://ridecharge.com ASF Member - Apache Software Foundation http://apache.org FreeBSD Committer - FreeBSD Foundation http://freebsd.org Work like you don't need the money, love like you'll never get hurt, and dance like nobody's watching. ___ 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: apr-gdbm-db42 upgrade conflicting with libtool
On Mon, 03 Aug 2009 11:39:33 -0500, David Southwell wrote: In message <20090803125519.ga60...@twisted.net>, Troy (t...@twisted.net) wrote: > I was trying to upgrade apr-gdbm-db42-1.3.6.1.3.8 to 1.3.7.1.3.8 and ran > into the following error. My libtool was just upgraded to libtool-2.2.6a > so there may be a conflict there. Anyone have ideas? > > > checking minix/config.h usability... no > checking minix/config.h presence... no > checking for minix/config.h... no > checking whether it is safe to define __EXTENSIONS__... yes > checking for library containing strerror... none required > checking whether system uses EBCDIC... no > performing libtool configuration... > ./configure: 9753: Syntax error: word unexpected (expecting ")") > *** Error code 2 > > Stop in /usr/ports/devel/apr. > *** Error code 1 > > Stop in /usr/ports/devel/apr. I am also having problems updating devel/apr. In my case it gets past the configure stage and fails during the compile stage: % ===> Building for apr-gdbm-db43-1.3.7.1.3.8 -I/usr/ports.workdir/usr/ports/devel/apr/work/apr-1.3.7/include -o passwd/apr_getpass.lo -c passwd/apr_getpass.c && touch passwd/apr_getpass.lo /libtool: Can't open /libtool: No such file or directory *** Error code 2 Stop in /usr/ports.workdir/usr/ports/devel/apr/work/apr-1.3.7. *** Error code 1 Stop in /usr/ports.workdir/usr/ports/devel/apr/work/apr-1.3.7. *** Error code 1 Stop in /usr/ports/devel/apr. *** Error code 1 Stop in /usr/ports/devel/apr. % I have not had time to try to figure out what is going wrong, but I may have time tomorrow. Cheers, Nick. I also have problems: uname -a FreeBSD dns1.vizion2000.net 7.2-RELEASE-p2 FreeBSD 7.2-RELEASE-p2 #0: Wed Jun 24 00:14:35 UTC 2009 r...@amd64- builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 Built on Intel quad Core lt_cv_sys_max_cmd_len=262144 /bin/sh ./buildconf buildconf: checking installation... buildconf: python not found. You need python installed to build APR from SVN. *** Error code 1 Stop in /usr/ports/devel/apr. *** Error code 1 I can't reproduce it. Pav has ran pointyhat-exp a few times and devel/apr has never came up, which it always passed build. Did all of you follow the /usr/ports/UPDATING? Cheers, Mezz -- me...@cox.net - m...@freebsd.org FreeBSD GNOME Team http://www.FreeBSD.org/gnome/ - gn...@freebsd.org ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
INDEX build failed for 8.x
INDEX build failed with errors: Generating INDEX-8 - please wait..pkg_info: not found pkg_info: not found pkg_info: not found pkg_info: not found Done. make_index: linux-systemsimcell-3.0.22: no entry for /usr/ports/lang/linux-f10-tcl84 make_index: linux-systemsimcell-3.0.22: no entry for /usr/ports/x11-toolkits/linux-f10-tk84 Committers on the hook: araujo bsam dhn dougb nivit Most recent CVS update was: ports/LEGAL ports/UPDATING ports/emulators/Makefile ports/irc/nefarious/Makefile ports/irc/nefarious/distinfo ports/irc/nefarious/pkg-plist ports/java/eclipse-pydev/Makefile ports/java/eclipse-pydev/distinfo ports/net-im/amsn/Makefile ports/net-im/rubygem-termtter/Makefile ports/net-im/rubygem-termtter/distinfo ports/x11/electricsheep/Makefile ports/x11/xscreensaver/Makefile ports/x11/xscreensaver/files/patch-driver_XScreenSaver.ad.in ports/x11/xscreensaver/pkg-plist ___ 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-update & userland sources
On Sunday 02 August 2009 16:10:37 Tom Mende wrote: Is there a way to get freebsd-update to keep userland sources up to date? Yes. If you have source code installed (for the right version of FreeBSD) in /usr/src, then freebsd-update will keep it updated. (Slight complication: Because freebsd-update builds are normally done before patches are committed to SVN, you won't get the updated SVN revision numbers or the new entries in UPDATING via freebsd-update -- but you will get all of the security/errata fixes.) -- Colin Percival Security Officer, FreeBSD | freebsd.org | The power to serve Founder / author, Tarsnap | tarsnap.com | Online backups for the truly paranoid ___ 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: diablo-jdk with FreeBSD-8.0
On 8/3/09, Mel Flynn wrote:
> On Friday 31 July 2009 13:57:34 b. f. wrote:
>> "Stephen Montgomery-Smith" wrote:
>> >I am running a very recent amd64 version of FreeBSD-8.0. diablo-jdk is
>> >no longer working. I am guessing it is the bumped shared library
>> >versions (because I did do "make delete-old-libs" as part of my
>> >installation).
>>
>> Yes, this came up earlier. libmap.conf(5) is your friend here, until
>> an update. Or you can try building java/openjdk6, but that takes some
>> time and resources.
>
> Have you tried it? openjdk requires a native jdk to build, doesn't accept
> the
> linux ones, so chicken and egg.
Obviously not. :) I was mentioning it only as a possibility that I
hadn't explored, and that the OP may wish to look into -- I should
have made that clear. I see now that it (unfortunately) requires one
of a number of bootstrap JVMs that are now broken , as you say. Thanks
for pointing that out, and for mentioning the problems below with some
of the other JVMs.
> Trying to build java/jdk16 with a linux one also does not work, because of
> unsafe functions in the make program that it builds as one of the first
> things. Also, the linux jdk6 requires one to dig into archives as the port
> is
> at update 10 while Sun is at update 14.
> So for the time being, libmap.conf is the only working solution and to make
> it
> more specific, it needs libz.so.4. The error message java generates points
> no
> where near libz, so kudos to whoever found out it's that library.
Perhaps not, but ldd(1) and a number of other tools will show that
${WRKSRC}/bin/unpack200 expects to find this library, and also show
what other libraries the precompiled binaries need. In any event, it
was helpful of Carlos to post his notes -- thanks.
b.
___
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-update & userland sources
On Sunday 02 August 2009 16:10:37 Tom Mende wrote: > Is there a way to get freebsd-update to keep userland sources up to > date? Since it is for binary upgrades, it doesn't make much sense, but ... > By way of background, I am trying not to use csup / cvsup and like > processes as their past, admittedly incorrect, usage by me, combined > with my incompetent salvage operations, has hosed my systems to the > point of needing to be reinstalled from scratch. I have been using a > combination of portsnap and freebsd-update to keep my 7.2-RELEASE > system up to date and commenced this at about 6.3-RELEASE and have > managed to not hose the system since that time. It now however appears > I need to have userland sources to keep fusefs-kmod up to date. > > /usr/ports/sysutils/fusefs-kmod>make install clean > ===> fusefs-kmod-0.3.9.p1.20080208_6 requires the userland sources to > be installed. Set SRC_BASE if it is not in /usr/src. > *** Error code 1 This is one case where one requires sources. You would still need csup/cvsup and if you're tracking a -RELEASE branch, it does not do very much. Also, because you're not actually going to build world/kernel, the risk of "hosing your system" is limited. What freebsd-update could however do, is maintain a 'standard-supfile' that would have the correct tag at all times. For example: Would you like to install a supfile for this release in /etc? [y/n] y Please choose a mirror [cvsup$random.FreeBSD.org]: -- Mel ___ 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: devel/boost: new patch for testing update to 1.39
On Friday 31 July 2009 04:29:06 Alexander Churanov wrote:
> Now It's clear. Thank you for explanation.
> The WITH_PYSTE was not in the options framework, that's why I've
> missed this part of work.
>
> I see two possible solutions:
>
> 1) Put the WITH_PYSTE variable back.
> 2) Create a separate port like devel/boost-pyste.
>
> The first is easy, however leads to dependeny issues like 'let's
> verify that boost-python-libs is installed with PYSTE support'.
> Provided that Pyste is actually used by someone, this may re-introduce
> bug ports/123927 (see
> http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/123927).
>
> The second is much more robust, but requires more work. This is also
> harder because I am not a user of Boost.Pyste. Thus, correctness
> verification would be expensive.
I think for the time being PySTE support should be off by default, because it
pulls in a second libc and databases/akonadi plus kdeedu[34] use boost-python
and because gccxml looks like a dead project.
I've attached a patch that does exactly this and also fixes WITH_DEBUG
building. There's one issue commented in the Makefile that I'm unable to
relate to anything I did, but am assuming it's from WITH_DEBUG as well.
ports/123927 could be solved/prevented by using a WANT_BOOST_PYSTE in
dependent ports that rely on boost having PYSTE and using PKGNAMESUFFIX plus
pkg_info to verify if boost-python-libs is boost-python-pyste-libs - as a
stop-gap.
--
Mel
--- Makefile.orig 2009-07-28 03:44:50.0 -0800
+++ Makefile 2009-08-03 00:55:34.0 -0800
@@ -25,9 +25,23 @@
PYTHON_INCLUDES="${PYTHON_INCLUDEDIR}"\
PYTHON_LIB_PATH="${PYTHON_LIBDIR}"
-RUN_DEPENDS+= ${PREFIX}/lib/libboost_thread.so.${BOOST_SHARED_LIB_VER}:${PORTSDIR}/devel/boost-libs
-RUN_DEPENDS+= gccxml:${PORTSDIR}/devel/gccxml \
- ${PYTHON_SITELIBDIR}/elementtree/ElementTree.py:${PORTSDIR}/devel/py-elementtree
+RUN_DEPENDS+= ${LOCALBASE}/lib/libboost_thread.so.${BOOST_SHARED_LIB_VER}:${PORTSDIR}/devel/boost-libs
+RUN_DEPENDS+= ${PYTHON_SITELIBDIR}/elementtree/ElementTree.py:${PORTSDIR}/devel/py-elementtree
+.if defined(WITH_PYSTE)
+RUN_DEPENDS+= gccxml:${PORTSDIR}/devel/gccxml
+PLIST_SUB+= PYSTE=
+.else
+PLIST_SUB+= PYSTE="@comment "
+.endif
+
+.if defined(WITH_DEBUG)
+BOOST_BUILD= debug
+# No idea how this gets enabled, but I'm getting it
+OPTIM_SPEED= optimization-speed/
+.else
+OPTIM_SPEED= /
+BOOST_BUILD= release
+.endif
BUILD_DEPENDS+= ${BJAM}:${PORTSDIR}/devel/boost-jam
BUILD_DEPENDS+= ${PYTHON_SITELIBDIR}/elementtree/ElementTree.py:${PORTSDIR}/devel/py-elementtree
@@ -39,12 +53,13 @@
post-patch: customize-boost-build
-
+.if defined(WITH_PYSTE)
post-configure:
# Configure pyste, the Boost.Python code generator
@cd ${BUILD_WRKSRC}/libs/python/pyste/install && \
${SETENV} ${MAKE_ENV} ${PYTHON_CMD} ${PYSETUP} \
config ${PYDISTUTILS_CONFIGUREARGS}
+.endif
do-build:
# build the library
@@ -52,19 +67,20 @@
${SETENV} ${MAKE_ENV} ${BJAM} ${BJAM_OPTIONS} --prefix=${PREFIX}\
--toolset=${BOOST_TOOLS} --with-python
+.if defined(WITH_PYSTE)
# Build pyste, the Boost.Python code generator
cd ${BUILD_WRKSRC}/libs/python/pyste/install && \
${SETENV} ${MAKE_ENV} ${PYTHON_CMD} ${PYSETUP} \
build ${PYDISTUTILS_BUILDARGS}
-
+.endif
# Remove non-python headers
cd ${WRKSRC} && \
${FIND} boost -not -path '*python*' -delete
do-install:
# Install libraries
- ${INSTALL_DATA} ${WRKSRC}/bin.v2/libs/python/build/gcc-4.2.1/release/link-static/threading-multi/libboost_python.a ${PREFIX}/lib
- ${INSTALL_DATA} ${WRKSRC}/bin.v2/libs/python/build/gcc-4.2.1/release/threading-multi/libboost_python.so.${PORTVERSION} ${PREFIX}/lib/libboost_python.so.${BOOST_SHARED_LIB_VER}
+ ${INSTALL_DATA} ${WRKSRC}/bin.v2/libs/python/build/gcc-4.2.1/${BOOST_BUILD}/link-static/${OPTIM_SPEED}threading-multi/libboost_python.a ${PREFIX}/lib
+ ${INSTALL_DATA} ${WRKSRC}/bin.v2/libs/python/build/gcc-4.2.1/${BOOST_BUILD}/${OPTIM_SPEED}threading-multi/libboost_python.so.${PORTVERSION} ${PREFIX}/lib/libboost_python.so.${BOOST_SHARED_LIB_VER}
# Create symlink for shared library
cd ${PREFIX}/lib/ && \
@@ -79,10 +95,12 @@
${FIND} boost -type f -a \! -name "*.orig"\
-exec ${INSTALL_DATA} \{\} ${PREFIX}/include/\{\} \;
+.if defined(WITH_PYSTE)
# Install pyste, the Boost.Python code generator
cd ${WRKSRC}/libs/python/pyste/install && \
${SETENV} ${MAKE_ENV} ${PYTHON_CMD} ${PYSETUP} \
install ${PYDISTUTILS_INSTALLARGS}
+.endif
post-install:
# display pkg-message
--- pkg-plist.orig 2009-07-28 03:44:50.0 -0800
+++ pkg-plist 2009-08-02 12:29:56.0 -0800
@@ -1,4 +1,4 @@
-bin/pyste.py
+%%PYSTE%%bin/pyste.py
include/boost/python.hpp
include/boost/python/arg_from_python.hpp
include/boost/python/args.hpp
@@ -213,71 +213,71 @@
lib/libboost_python.a
lib/libboost_python.so
lib/libboost_python.so.%%BOOST_SHARED_LIB_VER%%
-%%PYTHON_SITELIBDIR%%/Pyste-0.9.10-py%%PYTHON_VERSION%%.egg-info
-%%PYTHON_SITELIBDIR%%/Pyste/ClassExporter.py
-%%
Re: ports/*/jpeg "Thanks a lot guys"
On Saturday 01 August 2009 14:43:23 Peter Jeremy wrote:
> [I was also dismayed when I saw the bump].
>
> On 2009-Aug-01 18:33:43 +0100, Matthew Seaman
> wrote:
> >You could, for instance, run ldd(1) against each of the files a port
> > installs and then record in /var/db/pkg/portname-1.2.3/+SHLIBS or
> > equivalently in the .tbz package tarball a sorted and uniq'd list of all
> > the shared libraries linked against.
>
> Unfortunately, this isn't sufficient because a non-trivial number of
> ports dlopen() libraries rather than directly linking against them.
> (The Xorg server is probably the most widely used culprit here).
>
> > Or you could resolve the shlib filenames back to the ports
> >that supply them, and create a 'SHLIB_PORTS_NEEDED' variable in the port
> >Makefiles.
>
> A third approach is to more carefully recurse through the dependency
> tree: Given A depends on B depends on C, B only needs bumping if it
> LIB_DEPENDS on A and C only needs bumping if it LIB_DEPENDS on B and
> B was bumped.
Unfortunately, qt4-* ports slice this idea. Because they don't use
LIB_DEPENDS, but a version dependant RUN and BUILD depends. I've coded a
"patch-recursive" target in my Mk/bsd.local.mk that can't depend just on
LIB_DEPENDS for this very reason (I needed the target so I can debug
crashes in kde4 programs, and have gdb's `list' command working).
--
Mel
_LIB_DEPEND_DIRS=${LIB_DEPENDS:C,^[^:]*:([^:]*).*$,\1,}
_QT4_DEPEND_DIRS=${BUILD_DEPENDS:Mqt4-*:C,^[^:]*:([^:]*).*$,\1,}
LIB-DEPENDS-LIST= \
L="${_LIB_DEPEND_DIRS} ${_QT4_DEPEND_DIRS}";\
checked=""; \
while [ -n "$$L" ]; do \
l=""; \
for d in $$L; do\
case $$checked in \
$$d\ *|*\ $$d\ *|*\ $$d)\
continue;; \
esac; \
checked="$$checked $$d";\
if [ ! -d $$d ]; then \
${ECHO_MSG} "${PKGNAME}: \"$$d\" non-existent -- dependency
list incomplete" >&2; \
continue; \
fi; \
${ECHO_CMD} $$d;\
if ! children=$$(cd $$d && ${MAKE} -V _LIB_DEPEND_DIRS); then\
${ECHO_MSG} "${PKGNAME}: \"$$d\" erroneous -- dependency list
incomplete" >&2; \
continue; \
fi; \
for child in $$children; do \
case "$$checked $$l" in \
$$child\ *|*\ $$child\ *|*\ $$child)\
continue;; \
esac; \
l="$$l $$child";\
done; \
done; \
L=$$l; \
done
patch-recursive:
@for dir in ${.CURDIR} $$(${LIB-DEPENDS-LIST}); do \
echo "===> $${dir}"; \
${MAKE} -C $${dir} patch; \
done
show-libdepends-recursive:
@for dir in ${.CURDIR} $$(${LIB-DEPENDS-LIST}); do \
echo "===> $${dir}"; \
done
___
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: diablo-jdk with FreeBSD-8.0
On Friday 31 July 2009 13:57:34 b. f. wrote: > "Stephen Montgomery-Smith" wrote: > >I am running a very recent amd64 version of FreeBSD-8.0. diablo-jdk is > >no longer working. I am guessing it is the bumped shared library > >versions (because I did do "make delete-old-libs" as part of my > >installation). > > Yes, this came up earlier. libmap.conf(5) is your friend here, until > an update. Or you can try building java/openjdk6, but that takes some > time and resources. Have you tried it? openjdk requires a native jdk to build, doesn't accept the linux ones, so chicken and egg. Trying to build java/jdk16 with a linux one also does not work, because of unsafe functions in the make program that it builds as one of the first things. Also, the linux jdk6 requires one to dig into archives as the port is at update 10 while Sun is at update 14. So for the time being, libmap.conf is the only working solution and to make it more specific, it needs libz.so.4. The error message java generates points no where near libz, so kudos to whoever found out it's that library. -- Mel ___ 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: dovecot-1.2.x
Frank Leonhardt wrote: > Hi, > > I'm trying to track down a very weird issue with Dovecot and MS Outlook > 2003, and it'd be good to be using 1.2.x in the tests. Any idea when it > might be coming? If it's going to be a while I might have a go myself (or > use Linux!); if not I'll wait. > > Is there anything I should know about before I try it myself? > > Thanks, Frank. I'm working on the update to 1.2.x Hopefully in the next day or two I should have something ready to commit.. -- Yarema ___ 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: x11-toolkits/xview requires COMPAT_43TTY defined to build on -CURRENT
On Saturday 01 August 2009 15:34:34 Tom Uffner wrote: > x11-toolkits/xview requires COMPAT_43TTY defined to build on -CURRENT In your kernel config. -- Mel ___ 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: Don't know how to make /usr/ports/dns/bind96/work/.build....
Dan Mahoney, System Admin wrote: > On Wed, 29 Jul 2009, Doug Barton wrote: > >> Dan Mahoney, System Admin wrote: >>> The fact that the error occurs AT ALL is the bug and what is >>> counterintuitive, and many people would not think to try typing "make" >>> again, and instead would just assume the thing's broken. >> >> Ok, I actually misunderstood the problem that you were reporting. I >> thought that the reference to .build_done.bind96._usr_local indicated >> that the port had already been built once, but that is not the case. >> To reproduce the bug, you need to do the following: >> >> 1. Make sure there is nothing in /var/db/ports/bind96 >> 2. cd /usr/ports/dns/bind96 >> 3. make >> 4. Enable the "replace base" option >> 5. Save the config >> >> You will then see the following error: >> >> make: don't know how to make >> /usr/local/tmp/usr/local/ports/dns/bind96/work/.build_done.bind96._usr_local. >> >> Stop >> *** Error code 2 >> >> I think Mel is right that the problem is changing PREFIX, but that's >> the whole purpose of the option. >> >> Could you please open a PR about this with a subject something to the >> effect of "OPTIONS that change PREFIX cause an error after 'make >> config'" and describe how to reproduce this? > > Done, just got the mail from gnats: 137250. Looks good, thanks! 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"
FreeBSD Port: dovecot-1.2.x
Hi, I'm trying to track down a very weird issue with Dovecot and MS Outlook 2003, and it'd be good to be using 1.2.x in the tests. Any idea when it might be coming? If it's going to be a while I might have a go myself (or use Linux!); if not I'll wait. Is there anything I should know about before I try it myself? Thanks, Frank. ___ 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: recent update causes perl5.10 build failure
Scott Bennett wrote: > An update yesterday or today results in perl5.10's build aborting. When > it failed under portmaster, the messages from several processes were too > jumbled for me to see easily what had happened, so I tried portinstall > instead. If you get a non-obvious port build failure in portmaster your next step should be to try just building the port itself without any tools (i.e., cd /usr/ports/foo/bar ; make clean ; make). That will give you the idea of whether or not the error is related to the tool, or the port itself. > At least on a first look, it seems that perl5.10 has "MAKE_JOBS_SAFE= > yes" > in its Makefile, but that it should not. I changed that to > "MAKE_JOBS_SAFE= no" The ports infrastructure does not care what the value of the define is, it just cares if it is defined. You need to do this: cd /usr/ports/lang/perl5.10 vi Makefile (replace the MAKE_JOBS_SAFE with MAKE_JOBS_UNSAFE) make clean make config make Then report your results. hth, 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: Error when using 'portupgrade -ay' (and several others) [Second attempt]
[If you reply, please strip off freebsd-stable@, thanks.] Jens Rasmus Liland wrote: > That seems to have have done something more. But I still got some funky > errors after running portmaster -a: > ===>>> The x11/xphelloworld port has been deleted: Xprint application, > deprecated upstream > ===>>> Aborting update That's just telling you that it can't update that app because the port doesn't exist anymore. You have several options at that point. If you want to keep it you can read the portmaster man page about +IGNOREME files. If you don't need it anymore (and in this case you almost certainly do not) then you can use 'portmaster -e xphelloworld' to delete it (or just good old 'pkg_delete -f'). hth, 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: Getting a lot of - pkg_version: corrupted record (pkgdep line without argument), ignoring
eculp wrote: > I'm getting a lot of the following messages and have no idea how to find > which package is causing the problem. This is one of those times that opening up the files and having a look for yourself might be a good way to start. :) > pkg_version: corrupted record (pkgdep line without argument), ignoring egrep '(pkgdep$|pkgdep $)' /var/db/pkg/*/+CONTENTS However, you indicate below that you are using 'portmaster --check-depends' which should be fixing those for you. So try this: cd /var/db/ cp -Rp pkg pkg-before portmaster --check-depends diff -ur pkg-before pkg > ~/pkg-dir.diff1 cp -Rp pkg pkg-after portmaster --check-depends diff -ur pkg-after pkg > ~/pkg-dir.diff2 cd pkg egrep -l '(pkgdep$|pkgdep $)' */+CONTENTS > ~/pkg-dir.egrep Ideally pkg-dir.diff2 pkg-dir.egrep should both be empty there. If not, you will need to rebuild all of the ports listed in the egrep file. One easy way to do that would be to use vi to strip everything but the directory name out of that file then do this: portmaster `cat ~/pkg-dir.egrep` > While I'm bothering you, could someone give me some tips on the best > ways to find corrupted files in /var/db/pkgs, /var/db/ports and any > other places that they might be hiding. I run > portmaster --check-depends > portmaster --check-port-dbdir Those are both good examples from my perspective. :) One thing though, --check-port-dbdir won't find anything that is corrupt, it will only find things that don't apply to your currently installed ports. hth, 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: Compile error mail/alpine
FYI, In the future you're likely to get faster results if you send your problem report to the port's maintainer as well as the freebsd-ports@ list. David Southwell wrote: > FreeBSD 7.2-RELEASE-p2 #0: Wed Jun 24 00:14:35 UTC 2009 r...@amd64- > builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 > on intel quad core > > > cc -std=gnu99 -g -D_THREAD_SAFE -O2 -fno-strict-aliasing -pipe - > DLDAP_DEPRECATED -rpath=/usr/local/lib -o alpine addrbook.o adrbkcmd.o > after.o > alpine.o arg.o busy.o colorconf.o confscroll.o context.o dispfilt.o > flagmaint.o folder.o help.o imap.o init.o kblock.o keymenu.o ldapconf.o > listsel.o mailcmd.o mailindx.o mailpart.o mailview.o newuser.o pattern.o > pipe.o print.o radio.o remote.o reply.o roleconf.o send.o setup.o signal.o > status.o takeaddr.o titlebar.o smime.o date.o -lcrypt -lpam -L/usr/lib - > L/usr/local/openssl/lib -L/usr/local/lib ../pico/libpico.a > ../pico/osdep/libpicoosd.a ../pith/libpith.a ../pith/osdep/libpithosd.a > ../pith/charconv/libpithcc.a osdep/libpineosd.a ../c-client/c-client.a > /usr/local/lib/libldap.so -lcrypto -ltinfo /usr/local/lib/liblber.so -lssl - > Wl,--rpath -Wl,/usr/local/lib -Wl,--rpath -Wl,/usr/local/lib > ../c-client/c-client.a(osdep.o)(.text+0x68a1): In function `ssl_onceonlyinit': > /usr/ports/mail/alpine/work/alpine-2.00/imap/c-client/osdep.c:335: warning: > warning: tmpnam() possibly used unsafely; consider using mkstemp() > after.o(.text+0x36d): In function `start_after': > /usr/ports/mail/alpine/work/alpine-2.00/alpine/after.c:77: undefined > reference > to `pthread_create' > *** Error code 1 I just tried building it on a 7.2-STABLE amd64 from June 13th (r194101) and didn't have any problems. Can you please post the contents of /var/db/ports/alpine/options? Also, do you have any options related to thread libraries in /etc/make.conf, and are you using openssl from the ports, or in the base? 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: psi-0.12.1_2 need update to 0.13
Alexey Golodov wrote: > Please, note that psi has been updated to0.13. > Also, if you can, see psi+ (http://code.google.com/p/psi-dev/) and, > probably, good idea to add this to ports. > You might want to take a look at http://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/index.html and figure out how to do this work yourself. It is just like any other skill, it gets easier with practice. :) 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: ports/*/jpeg "Thanks a lot guys"
Garrett Cooper wrote: > Gentoo Linux (I know -- Gentoo + Linux -- we're FreeBSD... blah :P) > has a script called `revdep-rebuild' which goes and runs ldd on all > pieces of software that are installed in portage (ok, substitute ports > here). What I'm driving at is that we can use pkg_info and/or the > mtree generated files to determine what files are installed, find out > which packages have been broken up an update, then rebuild the port > and all dependencies (LIB_DEPENDS?). What say you to that :)? I was experimenting with various scripts using ldd in parallel to my most recent portmaster update and I think there is a problem with that solution. If libA is linked against libB which in turn is linked against libMISSING (such as libjpeg.so.9 for example) then ldd against libA will show libMISSING even though that problem can be solved by simply updating libB (i.e., without recompiling libA). This same issue applies to the idea of running ldd against things at install time and recording the list. Perhaps someone smarter than I about ldd can come up with a solution to this, but until then I think that using ldd after the fact is a stopgap measure to repair things if the ports infrastructure fails us. In theory the dependency graphing in our existing ports infrastructure should deal with this problem. In practice at the moment I personally feel that we record too many "indirect" dependencies (such as libA above) and that we would serve our users better if we stuck to direct dependencies only (libB in the example above). What should have happened in this case is that the ports that depend DIRECTLY on libjpeg should have had their revisions bumped at the same time as the update to libjpeg. Since that is what usually happens, hopefully we can stop flogging this horse soon. That said, if anyone really really wants to pursue the dependency graphing issue further, can I suggest a new thread focused on that topic? hth, 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: ports/*/jpeg "Thanks a lot guys"
On Monday 03 August 2009 14:31:23 Matthew Seaman wrote: > There was a question about apps that use dlopen() to load libraries, > rather than letting ld.so do the work for them. I don't think that > using ldd(1) will pick up any app that does that, but then again I > don't know if this is a widespread practice, and if it is, whether > there is any simple way to pick out packages that need reinstallation > because of it other than by using manually defined LIB_DEPENDS > settings in port Makefiles. The most common use case for dlopen are plugins and there it's the app that controls the API, not the lib, so an update of the plugin without recompiling the app shouldn't be a problem. Use of dlopen to load normal libraries is rare, but an example is Wine. IMHO it's a bug if such libs aren't listed in LIB_DEPENDS. They are direct dependencies. ___ 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: apr-gdbm-db42 upgrade conflicting with libtool
Troy wrote: I was trying to upgrade apr-gdbm-db42-1.3.6.1.3.8 to 1.3.7.1.3.8 and ran into the following error. My libtool was just upgraded to libtool-2.2.6a so there may be a conflict there. Anyone have ideas? checking minix/config.h usability... no checking minix/config.h presence... no checking for minix/config.h... no checking whether it is safe to define __EXTENSIONS__... yes checking for library containing strerror... none required checking whether system uses EBCDIC... no performing libtool configuration... ./configure: 9753: Syntax error: word unexpected (expecting ")") I think its you. You might have cleanuped up sufficently. http://tb.p6m7g8.net/logs/8-CURRENT-amd64/apr-ipv6-gdbm-db42-1.3.7.1.3.8.log -- 1024D/DB9B8C1C B90B FBC3 A3A1 C71A 8E70 3F8C 75B8 8FFB DB9B 8C1C Philip M. Gollucci (pgollu...@p6m7g8.com) c: 703.336.9354 Consultant - P6M7G8 Inc.http://p6m7g8.net Senior Sys Admin- RideCharge, Inc. http://ridecharge.com ASF Member - Apache Software Foundation http://apache.org FreeBSD Committer - FreeBSD Foundation http://freebsd.org Work like you don't need the money, love like you'll never get hurt, and dance like nobody's watching. ___ 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: Compile error mail/alpine
On Aug 3, 2009, at 3:34 AM, David Southwell wrote: FreeBSD 7.2-RELEASE-p2 #0: Wed Jun 24 00:14:35 UTC 2009 r...@amd64- builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 on intel quad core ../c-client/c-client.a(osdep.o)(.text+0x68a1): In function `ssl_onceonlyinit': /usr/ports/mail/alpine/work/alpine-2.00/imap/c-client/osdep.c:335: warning: warning: tmpnam() possibly used unsafely; consider using mkstemp() after.o(.text+0x36d): In function `start_after': /usr/ports/mail/alpine/work/alpine-2.00/alpine/after.c:77: undefined reference to `pthread_create' *** Error code 1 It builds fine for me on amd64, but I'm on 7.2-STABLE. Do you have the latest version of the port? I see it was modified on July 20, 2009? ___ 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: apr-gdbm-db42 upgrade conflicting with libtool
> In message <20090803125519.ga60...@twisted.net>, > > Troy (t...@twisted.net) wrote: > > I was trying to upgrade apr-gdbm-db42-1.3.6.1.3.8 to 1.3.7.1.3.8 and ran > > into the following error. My libtool was just upgraded to libtool-2.2.6a > > so there may be a conflict there. Anyone have ideas? > > > > > > checking minix/config.h usability... no > > checking minix/config.h presence... no > > checking for minix/config.h... no > > checking whether it is safe to define __EXTENSIONS__... yes > > checking for library containing strerror... none required > > checking whether system uses EBCDIC... no > > performing libtool configuration... > > ./configure: 9753: Syntax error: word unexpected (expecting ")") > > *** Error code 2 > > > > Stop in /usr/ports/devel/apr. > > *** Error code 1 > > > > Stop in /usr/ports/devel/apr. > > I am also having problems updating devel/apr. In my case it gets past > the configure stage and fails during the compile stage: > > % > > ===> Building for apr-gdbm-db43-1.3.7.1.3.8 > cd /usr/ports.workdir/usr/ports/devel/apr/work/apr-1.3.7; /usr/bin/env > TMPDIR="/home/njm/tmp" TMPDIR="/home/njm/tmp" SHELL=/bin/sh NO_LINT=YES > ACLOCAL=/usr/local/bin/aclocal-1.9 AUTOMAKE=/usr/local/bin/automake-1.9 > AUTOMAKE_VERSION=19 AUTOCONF=/usr/local/bin/autoconf-2.62 > AUTOHEADER=/usr/local/bin/autoheader-2.62 > AUTOIFNAMES=/usr/local/bin/ifnames-2.62 > AUTOM4TE=/usr/local/bin/autom4te-2.62 > AUTORECONF=/usr/local/bin/autoreconf-2.62 > AUTOSCAN=/usr/local/bin/autoscan-2.62 > AUTOUPDATE=/usr/local/bin/autoupdate-2.62 AUTOCONF_VERSION=262 > LIBTOOL=/usr/local/bin/libtool LIBTOOLIZE=/usr/local/bin/libtoolize > LIBTOOL_M4=/usr/local/share/aclocal/libtool.m4 PREFIX=/usr/local > LOCALBASE=/usr/local X11BASE=/usr/local MOTIFLIB="-L/usr/local/lib -lXm > -lXp" LIBDIR="/usr/lib" CC="cc" CFLAGS="-O2 -fno-strict-aliasing -pipe" > CXX="c++" CXXFLAGS="-O2 -fno-strict-aliasing -pipe" MANPREFIX="/usr/local" > BSD_INSTALL_PROGRAM="install -s -m 555" BSD_INSTALL_SCRIPT="install -m > 555" BSD_INSTALL_DATA="install -m 444" BSD_INSTALL_MAN="install -m > 444" /usr/bin/make /bin/sh /libtool --silent --mode=compile cc -O2 > -fno-strict-aliasing -pipe -DHAVE_CONFIG_H-I./include > -I/usr/ports.workdir/usr/ports/devel/apr/work/apr-1.3.7/include/arch/unix > -I./include/arch/unix > -I/usr/ports.workdir/usr/ports/devel/apr/work/apr-1.3.7/include/arch/unix > -I/usr/ports.workdir/usr/ports/devel/apr/work/apr-1.3.7/include -o > passwd/apr_getpass.lo -c passwd/apr_getpass.c && touch > passwd/apr_getpass.lo /libtool: Can't open /libtool: No such file or > directory > *** Error code 2 > > Stop in /usr/ports.workdir/usr/ports/devel/apr/work/apr-1.3.7. > *** Error code 1 > > Stop in /usr/ports.workdir/usr/ports/devel/apr/work/apr-1.3.7. > *** Error code 1 > > Stop in /usr/ports/devel/apr. > *** Error code 1 > > Stop in /usr/ports/devel/apr. > > % > > I have not had time to try to figure out what is going wrong, but I may > have time tomorrow. > > > Cheers, >Nick. I also have problems: uname -a FreeBSD dns1.vizion2000.net 7.2-RELEASE-p2 FreeBSD 7.2-RELEASE-p2 #0: Wed Jun 24 00:14:35 UTC 2009 r...@amd64- builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 Built on Intel quad Core /usr/bin/sed -i.bak -e 's,-lpthread,-pthread,g' /usr/ports/devel/apr/work/apr-1.3.7/build/apr_threads.m4 /usr/ports/devel/apr/work/apr-1.3.7/build/apr_hints.m4 /usr/ports/devel/apr/work/apr-util-1.3.8/build/apu-conf.m4 ===> apr-nothr-gdbm-db42-ldap-mysql-1.3.7.1.3.8 depends on file: /usr/local/bin/python2.6 - found ===> apr-nothr-gdbm-db42-ldap-mysql-1.3.7.1.3.8 depends on file: /usr/local/bin/perl5.8.9 - found ===> apr-nothr-gdbm-db42-ldap-mysql-1.3.7.1.3.8 depends on file: /usr/local/bin/automake-1.9 - found ===> apr-nothr-gdbm-db42-ldap-mysql-1.3.7.1.3.8 depends on file: /usr/local/bin/autoconf-2.62 - found ===> apr-nothr-gdbm-db42-ldap-mysql-1.3.7.1.3.8 depends on file: /usr/local/bin/libtool - found ===> apr-nothr-gdbm-db42-ldap-mysql-1.3.7.1.3.8 depends on shared library: expat.6 - found ===> apr-nothr-gdbm-db42-ldap-mysql-1.3.7.1.3.8 depends on shared library: gdbm.3 - found ===> apr-nothr-gdbm-db42-ldap-mysql-1.3.7.1.3.8 depends on shared library: ldap-2.4.7 - found ===> apr-nothr-gdbm-db42-ldap-mysql-1.3.7.1.3.8 depends on shared library: iconv.3 - found ===> apr-nothr-gdbm-db42-ldap-mysql-1.3.7.1.3.8 depends on shared library: mysqlclient.15 - found ===> apr-nothr-gdbm-db42-ldap-mysql-1.3.7.1.3.8 depends on shared library: db-4.2.2 - found ===> Configuring for apr-nothr-gdbm-db42-ldap-mysql-1.3.7.1.3.8 cd /usr/ports/devel/apr/work/apr-1.3.7 ; /usr/bin/env CC="cc" CFLAGS="-O2 - fno-strict-aliasing -pipe -I/usr/local/include/mysql -DHAVE_MYSQL_H - DLDAP_DEPRECATED" LIBS="" PYTHON="/usr/local/bin/python2.6" SHELL=/bin/sh CONFIG_SHELL=/bin/sh ACLOCAL=/usr/local/bin/aclocal-1.9 AUTOMAKE=/usr/local/bin/automake-1.9 AUTOMAKE_VERSION=19 AUTOCONF=/usr/loca
Re: apr-gdbm-db42 upgrade conflicting with libtool
In message <20090803125519.ga60...@twisted.net>, Troy (t...@twisted.net) wrote: > I was trying to upgrade apr-gdbm-db42-1.3.6.1.3.8 to 1.3.7.1.3.8 and ran > into the following error. My libtool was just upgraded to libtool-2.2.6a > so there may be a conflict there. Anyone have ideas? > > > checking minix/config.h usability... no > checking minix/config.h presence... no > checking for minix/config.h... no > checking whether it is safe to define __EXTENSIONS__... yes > checking for library containing strerror... none required > checking whether system uses EBCDIC... no > performing libtool configuration... > ./configure: 9753: Syntax error: word unexpected (expecting ")") > *** Error code 2 > > Stop in /usr/ports/devel/apr. > *** Error code 1 > > Stop in /usr/ports/devel/apr. I am also having problems updating devel/apr. In my case it gets past the configure stage and fails during the compile stage: % ===> Building for apr-gdbm-db43-1.3.7.1.3.8 cd /usr/ports.workdir/usr/ports/devel/apr/work/apr-1.3.7; /usr/bin/env TMPDIR="/home/njm/tmp" TMPDIR="/home/njm/tmp" SHELL=/bin/sh NO_LINT=YES ACLOCAL=/usr/local/bin/aclocal-1.9 AUTOMAKE=/usr/local/bin/automake-1.9 AUTOMAKE_VERSION=19 AUTOCONF=/usr/local/bin/autoconf-2.62 AUTOHEADER=/usr/local/bin/autoheader-2.62 AUTOIFNAMES=/usr/local/bin/ifnames-2.62 AUTOM4TE=/usr/local/bin/autom4te-2.62 AUTORECONF=/usr/local/bin/autoreconf-2.62 AUTOSCAN=/usr/local/bin/autoscan-2.62 AUTOUPDATE=/usr/local/bin/autoupdate-2.62 AUTOCONF_VERSION=262 LIBTOOL=/usr/local/bin/libtool LIBTOOLIZE=/usr/local/bin/libtoolize LIBTOOL_M4=/usr/local/share/aclocal/libtool.m4 PREFIX=/usr/local LOCALBASE=/usr/local X11BASE=/usr/local MOTIFLIB="-L/usr/local/lib -lXm -lXp" LIBDIR="/usr/lib" CC="cc" CFLAGS="-O2 -fno-strict-aliasing -pipe" CXX="c++" CXXFLAGS="-O2 -fno-strict-aliasing -pipe" MANPREFIX="/usr/local" BSD_INSTALL_PROGRAM="install -s -m 555" BSD_INSTALL_SCRIPT="install -m 555" BSD_INSTALL_DATA="install -m 444" BSD_INSTALL_MAN="install -m 444" /usr/bin/make /bin/sh /libtool --silent --mode=compile cc -O2 -fno-strict-aliasing -pipe -DHAVE_CONFIG_H-I./include -I/usr/ports.workdir/usr/ports/devel/apr/work/apr-1.3.7/include/arch/unix -I./include/arch/unix -I/usr/ports.workdir/usr/ports/devel/apr/work/apr-1.3.7/include/arch/unix -I/usr/ports.workdir/usr/ports/devel/apr/work/apr-1.3.7/include -o passwd/apr_getpass.lo -c passwd/apr_getpass.c && touch passwd/apr_getpass.lo /libtool: Can't open /libtool: No such file or directory *** Error code 2 Stop in /usr/ports.workdir/usr/ports/devel/apr/work/apr-1.3.7. *** Error code 1 Stop in /usr/ports.workdir/usr/ports/devel/apr/work/apr-1.3.7. *** Error code 1 Stop in /usr/ports/devel/apr. *** Error code 1 Stop in /usr/ports/devel/apr. % I have not had time to try to figure out what is going wrong, but I may have time tomorrow. Cheers, Nick. -- ___ 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"
apr-gdbm-db42 upgrade conflicting with libtool
I was trying to upgrade apr-gdbm-db42-1.3.6.1.3.8 to 1.3.7.1.3.8 and ran into the following error. My libtool was just upgraded to libtool-2.2.6a so there may be a conflict there. Anyone have ideas? checking minix/config.h usability... no checking minix/config.h presence... no checking for minix/config.h... no checking whether it is safe to define __EXTENSIONS__... yes checking for library containing strerror... none required checking whether system uses EBCDIC... no performing libtool configuration... ./configure: 9753: Syntax error: word unexpected (expecting ")") *** Error code 2 Stop in /usr/ports/devel/apr. *** Error code 1 Stop in /usr/ports/devel/apr. ___ 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: Error when using 'portupgrade -ay' (and several others) [Second attempt]
> On Sat, Aug 1, 2009 at 5:29 PM, David Southwell wrote: > > > Hi, > > > > > > I'm getting really weird problems when trying to upgrade my ports. I've > > > already discussed this with Dan Naumov on the stable mailing list, and > > > he is out of ideas on what I am to do. I've tried to fix the problem > > > using many different methods (i.e. csup stable-ports-supfile; > > > Portmaster > > > > -a/-af, > > > > > portupgrade -ay, nuking the entire ports tree and then doing fetch > > > ports; extract, and similar stuff), but everyone seems to get the same > > > error, > > > > and > > > > > not come any further. The ports my system is trying to update is not in > > > > the > > > > > ports tree anymore either, so it is really strange that it is trying to > > > update it self. > > > > > > Here is some outputs I've already posted on the stable mailinglist: > > > > > > Running 'portupgrade -ay'. Got this output: > > > > > > ---> Session started at: Fri, 10 Jul 2009 18:58:30 +0200 > > > ** Port directory not found: x11-drivers/xf86-video-vga > > > ** Port marked as IGNORE: x11-drivers/xf86-video-via: > > > requires pciVideoPtr typedef > > > ** Port directory not found: x11/xorg-protos > > > ** Port directory not found: x11/xphelloworld > > > ---> Skipping 'x11-drivers/xorg-drivers' (xorg-drivers-7.3_3) because > > > a requisite package 'xf86-video-vga-4.1.0_2' > > > (x11-drivers/xf86-video-vga) failed (specify -k to force) > > > ---> ** Upgrade tasks 3: 0 done, 4 ignored, 1 skipped and 0 failed > > > ---> Skipping 'x11/xorg-apps' (xorg-apps-7.3) because a requisite > > > > package > > > > > 'xphelloworld-1.0.1_1' (x11/xphelloworld) failed (specify -k to force) > > > ---> ** Upgrade tasks 3: 0 done, 4 ignored, 2 skipped and 0 failed > > > ---> Skipping 'x11/xorg' (xorg-7.3_2) because a requisite package > > > 'xorg-drivers-7.3_3' (x11-drivers/xorg-drivers) failed (specify -k to > > > force) ---> ** Upgrade tasks 3: 0 done, 4 ignored, 3 skipped and 0 > > > > failed > > > > > ---> Listing the results (+:done / -:ignored / *:skipped / !:failed) - > > > x11-drivers/xf86-video-vga (port directory error) > > > - x11-drivers/xf86-video-via (marked as IGNORE) > > > - x11/xorg-protos (port directory error) > > > - x11/xphelloworld (port directory error) > > > * x11-drivers/xorg-drivers (xorg-drivers-7.3_3) > > > * x11/xorg-apps (xorg-apps-7.3) > > > * x11/xorg (xorg-7.3_2) > > > ---> Packages processed: 0 done, 4 ignored, 3 skipped and 0 failed > > > ---> Session ended at: Fri, 10 Jul 2009 18:58:46 +0200 (consumed > > > > 00:00:15) > > > > > [r...@machine ~]# portupgrade -ay > > > ---> Session started at: Wed, 29 Jul 2009 18:30:36 +0200 > > > > > > ** Port directory not found: x11-drivers/xf86-video-vga > > > ** Port marked as IGNORE: x11-drivers/xf86-video-via: > > > requires pciVideoPtr typedef > > > ** Port directory not found: x11/xorg-protos > > > ** Port directory not found: x11/xphelloworld > > > [Updating the portsdb in /usr/ports ... - 20501 port > > > entries found > > > > .1000.2000.3000.4000.5000 > >.6 > > > > >000.7000.8000.9000.1.11000.. > > > > > > > > >...12000.13000.14000.15000.16000 > > >.170 00.18000.19000.2. . done] > > > > > > ---> Skipping 'x11-drivers/xorg-drivers' (xorg-drivers-7.3_3) because > > > a requisite package 'xf86-video-vga-4.1.0_2' > > > (x11-drivers/xf86-video-vga) failed (specify -k to force) > > > ---> ** Upgrade tasks 3: 0 done, 4 ignored, 1 skipped and 0 failed > > > ---> Skipping 'x11/xorg-apps' (xorg-apps-7.3) because a requisite > > > > package > > > > > 'xphelloworld-1.0.1_1' (x11/xphelloworld) failed (specify -k to force) > > > ---> ** Upgrade tasks 3: 0 done, 4 ignored, 2 skipped and 0 failed > > > ---> Skipping 'x11/xorg' (xorg-7.3_2) because a requisite package > > > 'xorg-drivers-7.3_3' (x11-drivers/xorg-drivers) failed (specify -k to > > > force) ---> ** Upgrade tasks 3: 0 done, 4 ignored, 3 skipped and 0 > > > > failed > > > > > ---> Listing the results (+:done / -:ignored / *:skipped / !:failed) - > > > x11-drivers/xf86-video-vga (port directory error) > > > - x11-drivers/xf86-video-via (marked as IGNORE) > > > - x11/xorg-protos (port directory error) > > > - x11/xphelloworld (port directory error) > > > * x11-drivers/xorg-drivers (xorg-drivers-7.3_3) > > > * x11/xorg-apps (xorg-apps-7.3) > > > * x11/xorg (xorg-7.3_2) > > > ---> Packages processed: 0 done, 4 ignored, 3 skipped and 0 failed > > > ---> Session ended at: Wed, 29 Jul 2009 18:30:59 +0200 (consumed > > > > 00:00:22) > > > > > [r...@machine ~]# > > > > > > [r...@machine ~]# portsdb -Uu; portupgrade -ay > > > Updating the ports index ... Generating INDEX.tmp - please > > > wait..Warning: Duplicate INDEX entry: cvsup-without-gui-16.1h_4 > > > Done. > > > done > > > [Upda
Re: ports/*/jpeg "Thanks a lot guys"
Garrett Cooper wrote: > On Sun, Aug 2, 2009 at 7:52 AM, Matthew > Seaman wrote: >> Matthew Seaman wrote: >> >>> Peter Jeremy wrote: In this specific case, p5-RT-* depends on www/rt38 depends on graphics/p5-GD depends on graphics/gd depends on graphics/jpeg. When jpeg is bumped, gd needs to be bumped because it LIB_DEPENDS on jpeg. p5-GD then needs to be bumped because it LIB_DEPENDS on gd. rt38 does not need to be bumped because it has no LIB_DEPENDS on p5-GD. p5-RT-* does not need to be bumped because rt38 is not bumped. This is slighly more complex than cd /usr/ports && \ for i in */*; do [ -d "$i" ] && cd "$i" && make all-depends-list ; done | \ grep jpeg because you need to actually follow the dependency tree, but is not impractical. The only issues I can see with this approach are: 1) Mapping the shared library reported by 'make lib-depends' back to the port than installs it. 2) You are relying on LIB_DEPENDS being correct: In my general example above, if A is missing a LIB_DEPENDS on C, this may not be detected in the build process because of the implicit dependency on C via B. No sample script because I'm not sure of the correct approach to 1) off the top of my head. >>> Doing (1) using my p5-FreeBSD-Portindex code is pretty easy. It's about >>> time I released an update anyhow -- I'll code up a little app that >>> processes >>> the LIB_DEPENDS linkages already stored in the cache and lists each port >>> that has a LIB_DEPENDS, together with all the ports it depends on >>> cumulatively. >> I've got this working now -- I still need to do some more testing, update >> documentation and stuff before I release version 2.2 of >> p5-FreeBSD-Portindex, >> but as a taster, here's the result of generating this on my machine just >> now: >> >> http://www.infracaninophile.co.uk/SHLIBS.bz2 >> >> (Note that this includes the effect of a number of local settings in >> /etc/make.conf) >> >> It's similar to the ports INDEX file, when decompressed. There's one row of >> the file for each port, and each row contains 3 fields separated by '|' >> characters: >> >> package-name|port/origin|space separated list of lib_depends port origins >> >> So, to extract the list of ports depending on www/jpeg: >> >> happy-idiot-talk:/tmp:% grep graphics/jpeg SHLIBS | cut -d '|' -f 1-2 | head >> -10 >> accerciser-1.6.1_1|/usr/ports/accessibility/accerciser >> at-poke-0.2.3_4|/usr/ports/accessibility/at-poke >> at-spi-1.26.0_1|/usr/ports/accessibility/at-spi >> dasher-4.10.1_1,2|/usr/ports/accessibility/dasher >> gnome-mag-0.15.8|/usr/ports/accessibility/gnome-mag >> gnopernicus-1.1.2_6|/usr/ports/accessibility/gnopernicus >> gok-2.26.0_1,1|/usr/ports/accessibility/gok >> kdeaccessibility-3.5.10_2|/usr/ports/accessibility/kdeaccessibility >> kdeaccessibility-4.2.4_1|/usr/ports/accessibility/kdeaccessibility4 >> mousetweaks-2.26.3_1|/usr/ports/accessibility/mousetweaks >> >> Again, this has a number of deficiencies. For instance, programs that >> embed a perl interpreter will link against libperl.so => >> /usr/local/lib/perl5/5.10.0/mach/CORE/libperl.so, but none of them register >> a LIB_DEPENDS on lang/perl5.10. [See for example net-mgmt/net-snmpd, >> www/mod_perl2] >> >> Similarly, programs that declare 'USE_MYSQL=NN' will have a LIB_DEPENDS on >> libmysqlclient.so.X added to their dependency mix even if they contain >> no compiled ELF binaries [See net-mgmt/cacti databases/phpmyadmin] >> >> However, I think that the deficiencies are not too intractable to fix, >> and this approach shows some promise. > > There actually may be a much easier solution to this problem. > > Gentoo Linux (I know -- Gentoo + Linux -- we're FreeBSD... blah :P) > has a script called `revdep-rebuild' which goes and runs ldd on all > pieces of software that are installed in portage (ok, substitute ports > here). What I'm driving at is that we can use pkg_info and/or the > mtree generated files to determine what files are installed, find out > which packages have been broken up an update, then rebuild the port > and all dependencies (LIB_DEPENDS?). What say you to that :)? > > If no one cares about the language, I can whip up a really quick > python script which solves this problem and we can migrate to a more > longterm solution in bourne shell if desired. If it's going to scan *all* of the installed files known to the pkg database to identify packages that depend on a particular shared library then it's going to take a pretty long time to run on a typical desktop package load. It would make sense to scan the installed files at package installation time and cache the result for each installed package, which is pretty much where I was at with the Bourne shell script I posted up-thread. There was a question about apps that use dlopen() to load libraries, rather than letting ld.so do the work for them. I don't think that usin
Re: devel/boost: new patch for testing update to 1.39
Folks,
I've try to prepeare boost-python-libs and boost-pyste split. However,
I can not promise any specific deadline. Perhaps, it will be done
within a month.
Sincerely,
Alexander Churanov,
maintainer of devel/boost-*
2009/7/31 Alexander Churanov :
> Mel,
>
> Now It's clear. Thank you for explanation.
> The WITH_PYSTE was not in the options framework, that's why I've
> missed this part of work.
>
> I see two possible solutions:
>
> 1) Put the WITH_PYSTE variable back.
> 2) Create a separate port like devel/boost-pyste.
>
> The first is easy, however leads to dependeny issues like 'let's
> verify that boost-python-libs is installed with PYSTE support'.
> Provided that Pyste is actually used by someone, this may re-introduce
> bug ports/123927 (see
> http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/123927).
>
> The second is much more robust, but requires more work. This is also
> harder because I am not a user of Boost.Pyste. Thus, correctness
> verification would be expensive.
>
> Folks, is there a user of Boost.Pyste, willing to volunteer with
> devel/boost-pyste quality verification?
>
> Sincerely,
> Alexander Churanov
> maintainer of devel/boost-*
>
>
> 2009/7/30 Mel Flynn :
>> On Thursday 30 July 2009 03:20:56 Alexander Churanov wrote:
>>
>>> I do not understand.
>>>
>>> Is it correct that you are discussing the issue of Pyste being part of
>>> boost and depending on gccxml port, which has issues of its own?
>>>
>>> I do not use Pyste and did not performed any specific testing of it,
>>> but all of boost-python-libs builds and installs, including
>>> dependencies.
>>>
>>> Please, describe what do you expect from ports and what do you
>>> observe, what negative outcome the issue has.
>>
>> The previous boost-python port had an *optional* dependency on pyste.
>> The current one does not. This means that boost-python now pulls in
>> gccxml which pulls in lang/gcc34 on anything but 6.x.
>> I'm currently building boost-python-libs with the pyste stuff
>> ifdef'd out[1] and will try to build packages kdeedu3, kdebase4,
>> games/wesnoth to see if there's any adverse side-effects.
>>
>> --
>> Mel
>>
>> [1]
>> --- Makefile.orig 2009-07-28 03:44:50.0 -0800
>> +++ Makefile 2009-07-30 07:19:26.0 -0800
>> @@ -25,9 +25,11 @@
>> PYTHON_INCLUDES="${PYTHON_INCLUDEDIR}"\
>> PYTHON_LIB_PATH="${PYTHON_LIBDIR}"
>>
>> -RUN_DEPENDS+=
>> ${PREFIX}/lib/libboost_thread.so.${BOOST_SHARED_LIB_VER}:${PORTSDIR}/devel/boost-libs
>> -RUN_DEPENDS+= gccxml:${PORTSDIR}/devel/gccxml \
>> -
>> ${PYTHON_SITELIBDIR}/elementtree/ElementTree.py:${PORTSDIR}/devel/py-elementtree
>> +RUN_DEPENDS+=
>> ${LOCALBASE}/lib/libboost_thread.so.${BOOST_SHARED_LIB_VER}:${PORTSDIR}/devel/boost-libs
>> +RUN_DEPENDS+=
>> ${PYTHON_SITELIBDIR}/elementtree/ElementTree.py:${PORTSDIR}/devel/py-elementtree
>> +.if defined(WITH_PYSTE)
>> +RUN_DEPENDS+= gccxml:${PORTSDIR}/devel/gccxml
>> +.endif
>>
>> BUILD_DEPENDS+= ${BJAM}:${PORTSDIR}/devel/boost-jam
>> BUILD_DEPENDS+=
>> ${PYTHON_SITELIBDIR}/elementtree/ElementTree.py:${PORTSDIR}/devel/py-elementtree
>> @@ -39,12 +41,13 @@
>>
>> post-patch: customize-boost-build
>>
>> -
>> +.if defined(WITH_PYSTE)
>> post-configure:
>> # Configure pyste, the Boost.Python code generator
>> �...@cd ${BUILD_WRKSRC}/libs/python/pyste/install && \
>> ${SETENV} ${MAKE_ENV} ${PYTHON_CMD} ${PYSETUP} \
>> config ${PYDISTUTILS_CONFIGUREARGS}
>> +.endif
>>
>> do-build:
>> # build the library
>> @@ -52,11 +55,12 @@
>> ${SETENV} ${MAKE_ENV} ${BJAM} ${BJAM_OPTIONS}
>> --prefix=${PREFIX}\
>> --toolset=${BOOST_TOOLS} --with-python
>>
>> +.if defined(WITH_PYSTE)
>> # Build pyste, the Boost.Python code generator
>> cd ${BUILD_WRKSRC}/libs/python/pyste/install && \
>> ${SETENV} ${MAKE_ENV} ${PYTHON_CMD} ${PYSETUP} \
>> build ${PYDISTUTILS_BUILDARGS}
>> -
>> +.endif
>> # Remove non-python headers
>> cd ${WRKSRC} && \
>> ${FIND} boost -not -path '*python*' -delete
>> @@ -79,10 +83,12 @@
>> ${FIND} boost -type f -a \! -name "*.orig"\
>> -exec ${INSTALL_DATA} \{\} ${PREFIX}/include/\{\} \;
>>
>> +.if defined(WITH_PYSTE)
>> # Install pyste, the Boost.Python code generator
>> cd ${WRKSRC}/libs/python/pyste/install && \
>> ${SETENV} ${MAKE_ENV} ${PYTHON_CMD} ${PYSETUP} \
>> install ${PYDISTUTILS_INSTALLARGS}
>> +.endif
>>
>> post-install:
>> # display pkg-message
>>
>>
>
___
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 unassigned ports problem reports
(Note: an HTML version of this report is available at http://www.freebsd.org/cgi/query-pr-summary.cgi?category=ports .) 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/137383[maintainer update] add/update claws mail plugins homp o ports/137381Minor patch for collectd Makefile allowing collection o ports/137378Advisory locks fail with ports/security/cfs on FreeBSD f ports/137375net/ekiga doesn't build for want of PWLib: what's that o ports/137362net/asterisk-app-ldap - PLIST files handling minor fix o ports/137356devel/libusb: drop maintainership o ports/137340[NEW PORT] multimedia/flvmeta: Manipulation tool for A o ports/137338[MAINTAINER] sysutils/duplicity-devel: update to 0.6.0 o ports/137324update of devel/quilt port to latest version o ports/137312[patch] devel/lemon: update from 1.39 to 1.69 o ports/137308[NEW PORT] converters/igbinary: Replacement for the st o ports/137297[PATCH] emulators/dynamips-devel: -m can't parse Cisco o ports/137295[NEW PORT] databases/sqlite-ext-inet: Library will pro f ports/137289astro/gpsd port fails to compile f ports/137282[patch] www/aswedit: Master sites fixed o ports/137276Update port: net-im/prosody to 0.5.1 o ports/137275[patch] mail/dcc-dccd update to 1.3.113 o ports/137274mail/nullmailer master.passwd variable replacement err o ports/137259[PATCH] archivers/rpm5 update o ports/137254New port: net/unssh Fast way to delete entries from Op f ports/137251update multimedia/vlc o ports/137249New port: mail/roundcube-groupvice - theme for RoundCu o ports/137244[x11-toolkits/plib] add support for linux-js f ports/137220net-p2p/verlihub port version update o ports/137203New port: misc/ipa_conv IPA accounting/database module o ports/137200New port: devel/p5-Async-MergePoint (fixes broken IO:: f ports/137196www/woadaptor - mod_webobjects doesn't support ssl f ports/137192security/openssh-portable: Kerberos/GSSAPI support for o ports/137177sysutils/smartmontools: command13 fix o ports/137172New port: www/free-sa-devel - development version of F o ports/137162Change in port math/vtk5: add GL2PS knobs to OPTIONS o ports/137157mark broken ports/net/ssmping for FreeBSD 7.x dan Free o ports/137151lang/slib-guile using latest 3b1 version of slib fails o ports/137115net/pptpclient: pptp client for freebsd 7.1 o ports/137112[mail/courier] update to 0.62 o ports/137105sysutils/freebsd-snapshot not handling non C LANG/LC_A f ports/137100security/openssh-portable: Add BSM audit support knob f ports/137046Port upgrade: databases/postgresql-odbc: 08.03.0400 -> f ports/137043[patch] multimedia/mplayer: add SSSE3 support o ports/137020New port: comms/dfu-programmer Programmer for USB Atme f ports/136984textproc/xerces-2 port no longer needs gcc_pic patch i f ports/136934devel/root is marked as BROKEN but OK with GCC 3.4 o ports/136892mail/prayer: fixup username in prayer-cyclog o ports/136886multimedia/mplayer does not play CSS enrypted DVDs f ports/136882kdenlive (multimedia/kdenlive port) project rendering f ports/136615[update] converters/pdf2djvu: update to 0.5.9 f ports/136611security/swatch: leaves zombies behind o ports/136427can't make devel/gwenhywfar o ports/136359New port - lang/gnat-gcc44 f ports/136258Port for sysutils/heartbeat (1.2.5_6) fails to build f ports/136227science/Gramps Crashes When Opening a Family File o ports/136133New port: net/callweaver Open source IP PBX based on A f ports/136132Update port: devel/srecord to 1.49 f ports/136129multimedia/kbtv won't build & install on 7.2 o ports/136124sysutils/bsdstats needs timeout settings o ports/136089New port: devel/mercurialeclipse A mercurial plugin fo f ports/135867net-im/gajim 0.12.3: wrong $path in bin file f ports/135541[PATCH] math/p5-NetCDF cannot load module with netcdf- o ports/135019sysutils/bubblemon-dockapp 1.46_6 memory usage meter i o ports/134946[PATCH] textproc/highlight: update to 2.9 o ports/134750[Update]textproc/py-markdown:update to 2.0.1 f ports/134743devel/Monotone and pthreaded dependencies o p
audio/libmtp broken on -current
I have a Samsung YP-T10 MP3 player that talks MTP. On 7.x, it works fairly well with libmtp (subject to the rather primitive "example" applications and serious lack of error checking in libmtp). The general problems with error checking include: - SEGV unless $LANG is set to a supported locale - SEGV if _any_ USB device is inaccessible I'm not immediately concerned with these at present. The 8.x problem is that it reads OK but writes fail with: libmtp version: 0.3.1 PTP: Opening session PTP_ERROR_IO: Trying again after re-initializing USB interface PTP: Opening session LIBMTP PANIC: Could not open session! (Return code 767) Try to reset the device. No devices. Has anyone got any suggestions for getting writes to work? -- Peter Jeremy pgp0715nnYsXA.pgp Description: PGP signature
Re: FreeBSD Port: psi-0.12.1_2 need update to 0.13
On Mon, 3 Aug 2009 18:50:07 +1100, Alexey Golodov wrote: > Please, note that psi has been updated to0.13. > Also, if you can, see psi+ (http://code.google.com/p/psi-dev/) and, > probably, good idea to add this to ports. I'm busy this week, will update it at the weekend. ___ 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: ports/*/jpeg "Thanks a lot guys"
> On Sun, Aug 2, 2009 at 7:52 AM, Matthew > Seaman wrote: > > Matthew Seaman wrote: > > > >> Peter Jeremy wrote: > >>> > >>> In this specific case, p5-RT-* depends on www/rt38 depends on > >>> graphics/p5-GD depends on graphics/gd depends on graphics/jpeg. > >>> When jpeg is bumped, gd needs to be bumped because it > >>> LIB_DEPENDS on jpeg. p5-GD then needs to be bumped because it > >>> LIB_DEPENDS on gd. rt38 does not need to be bumped because it > >>> has no LIB_DEPENDS on p5-GD. p5-RT-* does not need to be bumped > >>> because rt38 is not bumped. > >>> > >>> This is slighly more complex than > >>> cd /usr/ports && \ > >>> for i in */*; do [ -d "$i" ] && cd "$i" && make > >>> all-depends-list ; done > >>> | \ > >>> grep jpeg > >>> because you need to actually follow the dependency tree, but is > >>> not impractical. The only issues I can see with this approach > >>> are: > >>> 1) Mapping the shared library reported by 'make lib-depends' back > >>> to the port than installs it. > >>> 2) You are relying on LIB_DEPENDS being correct: In my general > >>> example above, if A is missing a LIB_DEPENDS on C, this may not > >>> be detected in the build process because of the implicit > >>> dependency on C via B. > >>> > >>> No sample script because I'm not sure of the correct approach to > >>> 1) off the top of my head. > > > >> Doing (1) using my p5-FreeBSD-Portindex code is pretty easy. It's > >> about time I released an update anyhow -- I'll code up a little > >> app that processes > >> the LIB_DEPENDS linkages already stored in the cache and lists > >> each port that has a LIB_DEPENDS, together with all the ports it > >> depends on cumulatively. > > > > I've got this working now -- I still need to do some more testing, > > update documentation and stuff before I release version 2.2 of > > p5-FreeBSD-Portindex, > > but as a taster, here's the result of generating this on my machine > > just now: > > > > http://www.infracaninophile.co.uk/SHLIBS.bz2 > > > > (Note that this includes the effect of a number of local settings in > > /etc/make.conf) > > > > It's similar to the ports INDEX file, when decompressed. There's > > one row of the file for each port, and each row contains 3 fields > > separated by '|' characters: > > > > package-name|port/origin|space separated list of lib_depends port > > origins > > > > So, to extract the list of ports depending on www/jpeg: > > > > happy-idiot-talk:/tmp:% grep graphics/jpeg SHLIBS | cut -d '|' -f > > 1-2 | head -10 > > accerciser-1.6.1_1|/usr/ports/accessibility/accerciser > > at-poke-0.2.3_4|/usr/ports/accessibility/at-poke > > at-spi-1.26.0_1|/usr/ports/accessibility/at-spi > > dasher-4.10.1_1,2|/usr/ports/accessibility/dasher > > gnome-mag-0.15.8|/usr/ports/accessibility/gnome-mag > > gnopernicus-1.1.2_6|/usr/ports/accessibility/gnopernicus > > gok-2.26.0_1,1|/usr/ports/accessibility/gok > > kdeaccessibility-3.5.10_2|/usr/ports/accessibility/kdeaccessibility > > kdeaccessibility-4.2.4_1|/usr/ports/accessibility/kdeaccessibility4 > > mousetweaks-2.26.3_1|/usr/ports/accessibility/mousetweaks > > > > Again, this has a number of deficiencies. For instance, programs > > that embed a perl interpreter will link against libperl.so => > > /usr/local/lib/perl5/5.10.0/mach/CORE/libperl.so, but none of them > > register a LIB_DEPENDS on lang/perl5.10. [See for example > > net-mgmt/net-snmpd, www/mod_perl2] > > > > Similarly, programs that declare 'USE_MYSQL=NN' will have a > > LIB_DEPENDS on libmysqlclient.so.X added to their dependency mix > > even if they contain no compiled ELF binaries [See net-mgmt/cacti > > databases/phpmyadmin] > > > > However, I think that the deficiencies are not too intractable to > > fix, and this approach shows some promise. > > There actually may be a much easier solution to this problem. > > Gentoo Linux (I know -- Gentoo + Linux -- we're FreeBSD... blah :P) > has a script called `revdep-rebuild' which goes and runs ldd on all > pieces of software that are installed in portage (ok, substitute ports > here). What I'm driving at is that we can use pkg_info and/or the > mtree generated files to determine what files are installed, find out > which packages have been broken up an update, then rebuild the port > and all dependencies (LIB_DEPENDS?). What say you to that :)? sysutils/bsdadminscripts provides a script called pkg_libchk which does a similar thing. Emanuel ___ 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: ports/*/jpeg "Thanks a lot guys"
On Sun, Aug 2, 2009 at 7:52 AM, Matthew Seaman wrote: > Matthew Seaman wrote: > >> Peter Jeremy wrote: >>> >>> In this specific case, p5-RT-* depends on www/rt38 depends on >>> graphics/p5-GD depends on graphics/gd depends on graphics/jpeg. When >>> jpeg is bumped, gd needs to be bumped because it LIB_DEPENDS on jpeg. >>> p5-GD then needs to be bumped because it LIB_DEPENDS on gd. rt38 does >>> not need to be bumped because it has no LIB_DEPENDS on p5-GD. p5-RT-* >>> does not need to be bumped because rt38 is not bumped. >>> >>> This is slighly more complex than >>> cd /usr/ports && \ >>> for i in */*; do [ -d "$i" ] && cd "$i" && make all-depends-list ; done >>> | \ >>> grep jpeg >>> because you need to actually follow the dependency tree, but is not >>> impractical. The only issues I can see with this approach are: >>> 1) Mapping the shared library reported by 'make lib-depends' back to the >>> port than installs it. >>> 2) You are relying on LIB_DEPENDS being correct: In my general example >>> above, if A is missing a LIB_DEPENDS on C, this may not be detected >>> in the build process because of the implicit dependency on C via B. >>> >>> No sample script because I'm not sure of the correct approach to 1) off >>> the top of my head. > >> Doing (1) using my p5-FreeBSD-Portindex code is pretty easy. It's about >> time I released an update anyhow -- I'll code up a little app that >> processes >> the LIB_DEPENDS linkages already stored in the cache and lists each port >> that has a LIB_DEPENDS, together with all the ports it depends on >> cumulatively. > > I've got this working now -- I still need to do some more testing, update > documentation and stuff before I release version 2.2 of > p5-FreeBSD-Portindex, > but as a taster, here's the result of generating this on my machine just > now: > > http://www.infracaninophile.co.uk/SHLIBS.bz2 > > (Note that this includes the effect of a number of local settings in > /etc/make.conf) > > It's similar to the ports INDEX file, when decompressed. There's one row of > the file for each port, and each row contains 3 fields separated by '|' > characters: > > package-name|port/origin|space separated list of lib_depends port origins > > So, to extract the list of ports depending on www/jpeg: > > happy-idiot-talk:/tmp:% grep graphics/jpeg SHLIBS | cut -d '|' -f 1-2 | head > -10 > accerciser-1.6.1_1|/usr/ports/accessibility/accerciser > at-poke-0.2.3_4|/usr/ports/accessibility/at-poke > at-spi-1.26.0_1|/usr/ports/accessibility/at-spi > dasher-4.10.1_1,2|/usr/ports/accessibility/dasher > gnome-mag-0.15.8|/usr/ports/accessibility/gnome-mag > gnopernicus-1.1.2_6|/usr/ports/accessibility/gnopernicus > gok-2.26.0_1,1|/usr/ports/accessibility/gok > kdeaccessibility-3.5.10_2|/usr/ports/accessibility/kdeaccessibility > kdeaccessibility-4.2.4_1|/usr/ports/accessibility/kdeaccessibility4 > mousetweaks-2.26.3_1|/usr/ports/accessibility/mousetweaks > > Again, this has a number of deficiencies. For instance, programs that > embed a perl interpreter will link against libperl.so => > /usr/local/lib/perl5/5.10.0/mach/CORE/libperl.so, but none of them register > a LIB_DEPENDS on lang/perl5.10. [See for example net-mgmt/net-snmpd, > www/mod_perl2] > > Similarly, programs that declare 'USE_MYSQL=NN' will have a LIB_DEPENDS on > libmysqlclient.so.X added to their dependency mix even if they contain > no compiled ELF binaries [See net-mgmt/cacti databases/phpmyadmin] > > However, I think that the deficiencies are not too intractable to fix, > and this approach shows some promise. There actually may be a much easier solution to this problem. Gentoo Linux (I know -- Gentoo + Linux -- we're FreeBSD... blah :P) has a script called `revdep-rebuild' which goes and runs ldd on all pieces of software that are installed in portage (ok, substitute ports here). What I'm driving at is that we can use pkg_info and/or the mtree generated files to determine what files are installed, find out which packages have been broken up an update, then rebuild the port and all dependencies (LIB_DEPENDS?). What say you to that :)? If no one cares about the language, I can whip up a really quick python script which solves this problem and we can migrate to a more longterm solution in bourne shell if desired. Thanks, -Garrett ___ 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"
Compile error mail/alpine
FreeBSD 7.2-RELEASE-p2 #0: Wed Jun 24 00:14:35 UTC 2009 r...@amd64- builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 on intel quad core cc -std=gnu99 -g -D_THREAD_SAFE -O2 -fno-strict-aliasing -pipe - DLDAP_DEPRECATED -rpath=/usr/local/lib -o alpine addrbook.o adrbkcmd.o after.o alpine.o arg.o busy.o colorconf.o confscroll.o context.o dispfilt.o flagmaint.o folder.o help.o imap.o init.o kblock.o keymenu.o ldapconf.o listsel.o mailcmd.o mailindx.o mailpart.o mailview.o newuser.o pattern.o pipe.o print.o radio.o remote.o reply.o roleconf.o send.o setup.o signal.o status.o takeaddr.o titlebar.o smime.o date.o -lcrypt -lpam -L/usr/lib - L/usr/local/openssl/lib -L/usr/local/lib ../pico/libpico.a ../pico/osdep/libpicoosd.a ../pith/libpith.a ../pith/osdep/libpithosd.a ../pith/charconv/libpithcc.a osdep/libpineosd.a ../c-client/c-client.a /usr/local/lib/libldap.so -lcrypto -ltinfo /usr/local/lib/liblber.so -lssl - Wl,--rpath -Wl,/usr/local/lib -Wl,--rpath -Wl,/usr/local/lib ../c-client/c-client.a(osdep.o)(.text+0x68a1): In function `ssl_onceonlyinit': /usr/ports/mail/alpine/work/alpine-2.00/imap/c-client/osdep.c:335: warning: warning: tmpnam() possibly used unsafely; consider using mkstemp() after.o(.text+0x36d): In function `start_after': /usr/ports/mail/alpine/work/alpine-2.00/alpine/after.c:77: undefined reference to `pthread_create' *** Error code 1 Stop in /usr/ports/mail/alpine/work/alpine-2.00/alpine. *** Error code 1 Stop in /usr/ports/mail/alpine/work/alpine-2.00/alpine. *** Error code 1 Stop in /usr/ports/mail/alpine/work/alpine-2.00/alpine. *** Error code 1 Stop in /usr/ports/mail/alpine/work/alpine-2.00. *** Error code 1 Stop in /usr/ports/mail/alpine/work/alpine-2.00. *** Error code 1 Stop in /usr/ports/mail/alpine. *** Error code 1 Stop in /usr/ports/mail/alpine. dns1# ___ 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: psi-0.12.1_2 need update to 0.13
Please, note that psi has been updated to0.13. Also, if you can, see psi+ (http://code.google.com/p/psi-dev/) and, probably, good idea to add this to ports. -- Regards, Alexey Golodov aka Nirnroot. ___ 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"
Asterisk 1.6 on 8.0 beta 2 broken?
Hello! I was use asterisk on my FreeBSD. I see after install asterisk 1.6 on FreeBSD user 8.0-BETA2 FreeBSD 8.0-BETA2 #2: Wed Jul 22 17:10:33 MSD 2009 root@:/usr/src/sys/i386/compile/MY i386 this error: 10:45 r...@local >asterisk -v Asterisk 1.6.0.9, Copyright (C) 1999 - 2008 Digium, Inc. and others. Created by Mark Spencer Asterisk comes with ABSOLUTELY NO WARRANTY; type 'core show warranty' for details. This is free software, with components licensed under the GNU General Public License version 2 and other licenses; you are welcome to redistribute it under certain conditions. Type 'core show license' for details. = Asterisk Event Logger Started /var/log/asterisk/event_log Asterisk Dynamic Loader Starting: [Aug 3 10:45:16] NOTICE[45097]: loader.c:869 load_modules: 1 modules will be loaded. func_strings.so => (String handling dialplan functions) [Aug 3 10:45:16] NOTICE[45097]: cdr.c:1430 do_reload: CDR simple logging enabled. Asterisk PBX Core Initializing Registering builtin applications: [Answer] [BackGround] [Busy] [Congestion] [ExecIfTime] [Goto] [GotoIf] [GotoIfTime] [ImportVar] [Hangup] [NoOp] [Proceeding] [Progress] [RaiseException] [ResetCDR] [Ringing] [SayAlpha] [SayDigits] [SayNumber] [SayPhonetic] [Set] [MSet] [SetAMAFlags] [Wait] [WaitExten] Asterisk Dynamic Loader Starting: [Aug 3 10:45:16] NOTICE[45097]: loader.c:869 load_modules: 174 modules will be loaded. Segmentation fault (core dumped) Asterisk 1.6 on 8.0b2 has been broken? ___ 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"
