Re: sage-6.1.1 build errors out while building conway_polynomials
On 03/03/14 11:33, Saifi Khan wrote: Hi: on attempting to build sage-6.1.1 from the '/usr/ports/math/sage' port, the build errors out while building a subpackage 'conway_polynomials'. Most people have reported errors in scipy and matplotlib with FreeBSD-10. I think the build of conway-polynomials comes earlier. So if we had a work around for this, you would still be stuck later on with the build of scipy or matplotlib. I am somewhat convinced that the error is due to some kind of incompatibility between clang and gcc46 and the linking process. I have no idea how to fix these problems. I'm kind of hoping that it will get magically fixed one day. ___ 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: Problems with linking on FreeBSD-10
On 01/31/14 07:25, Konstantin Belousov wrote: On Fri, Jan 31, 2014 at 12:19:46AM +, Montgomery-Smith, Stephen wrote: I maintain the port math/sage. The port builds its own version of the libreadline library. The port also uses lang/gcc instead of clang, because the port needs Fortran. The port is wanting to create a shared library called libR.so, which it wants to link with the libreadline library it created itself. So it issues this kind of command: gcc46 -Wl,-rpath=path-of-newly-made-library -o libR.so -lreadline I have left out most of the command for brevity. Not for brevity, but to make the diagnostic impossible. Here are more details. I have the -L there as well. It creates libR.so using a command like this: cc -std=gnu99 -shared -fopenmp -L/usr/home/stephen/sage/work/sage-6.0/local/lib/ -Wl,-rpath=/usr/home/stephen/sage/work/sage-6.0/local/lib -Wl,-rpath=/usr/local/lib/gcc46 -L/usr/local/lib/gcc46 -o libR.so CommandLineArgs.o Rdynload.o Renviron.o RNG.o agrep.o apply.o arithmetic.o array.o attrib.o bind.o builtin.o character.o coerce.o colors.o complex.o connections.o context.o cum.o dcf.o datetime.o debug.o deparse.o devices.o dotcode.o dounzip.o dstruct.o duplicate.o edit.o engine.o envir.o errors.o eval.o format.o gevents.o gram.o gram-ex.o graphics.o grep.o identical.o inlined.o inspect.o internet.o iosupport.o lapack.o list.o localecharset.o logic.o main.o mapply.o match.o memory.o names.o objects.o options.o paste.o platform.o plot.o plot3d.o plotmath.o print.o printarray.o printvector.o printutils.o qsort.o random.o raw.o registration.o relop.o rlocale.o saveload.o scan.o seq.o serialize.o sort.o source.o split.o sprintf.o startup.o subassign.o subscript.o subset.o summary.o sysutils.o unique.o util.o version.o vfonts.o xxxpr.o `ls ../unix/*.o ../appl/*.o ../nmath/*.o` ../extra/zlib/libz.a ../extra/bzip2/libbz2.a ../extra/pcre/libpcre.a ../extra/tre/libtre.a -L/usr/home/stephen/sage/work/sage-6.0/local/lib -lf77blas -latlas -lgfortran -lm -lquadmath -lintl -lreadline -llzma -lrt -lm -liconv Now -Wl,-rpath is set, so it should find libreadline in /usr/home/stephen/sage/work/sage-6.0/local/lib. But instead it finds libreadline in /lib. So later when it does the following compilation to build R.bin: gcc -std=gnu99 -export-dynamic -fopenmp -L/usr/home/stephen/sage/work/sage-6.0/local/lib/ -Wl,-rpath=/usr/home/stephen/sage/work/sage-6.0/local/lib -Wl,-rpath=/usr/local/lib/gcc46 -L/usr/local/lib/gcc46 -o R.bin Rmain.o -L../../lib -lR ...it comes up with an error saying that rl_sort_completion_matches isn't found. And when I do an ldd or readelf -d on libR.so, I can see that it is trying to link to the wrong libreadline, and rl_sort_completion_matches is only defined in the other libreadline. Unfortunately the libR.so pulls in /lib/libreadline - the version that comes with the base FreeBSD. I thought that -rpath flag was supposed to tell the linker where to find the library. But it doesn't. Show exact commands and exact error message. It is not possible to understand from you message is the failure at the static linking (ld(1)) or dynamic (at the program startup) stage. Just in case this might be useful: - -rpath only affects runtime search path - ld(1) search for libraries is directed with the -L path option. The failure is when using FreeBSD-10. With FreeBSD-8 it works great. I also assume that gcc46 uses /usr/local/bin/ld instead of /usr/bin/ld, since devel/binutils is a dependency of lang/gcc. Can anyone help me? Is this a bug with FreeBSD? Or is there some extra flag I can set with the linker to make it work? I have tried -rpath-link and -z origin, but these were random guesses. and I don't really know what I am doing. Thanks, Stephen ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Finding abandoned ports
On 10/30/2013 09:02 AM, Alex Laurie wrote: Hello all, Only really just getting into FreeBSD but I am inspired to help out. I'm not a developer or anything. However I do like to install and update things. I though one area I may be able to help out is in the ports side of things. I have been through the Porters handbook and thought I would try updating some out of date ports to cut my teeth so to speak. Looking around I don't seem to see anywhere with abandoned ports that need some love. If you are running FreeBSD version 10 or higher, I have a couple of ports that don't build: cad/gmsh-occ and math/GiNaC. I am still running FreeBSD 8 where these build problems don't occur. If you could fix these for me, I would be very grateful, because the rest of my life (work and family) is really occupying a lot of my time right now. But only if you would enjoy doing this - I will probably get to it eventually, but just not yet. Thanks, Stephen ___ 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: Explain staging
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/03/2013 04:54 AM, Baptiste Daroussin wrote: On Thu, Oct 03, 2013 at 10:58:56AM +0200, Alex Dupre wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Baptiste Daroussin ha scritto: Here you are: http://lists.freebsd.org/pipermail/freebsd-ports/2013-October/086346.html I was referring the the previous one: [HEADSUP] Stage support for the ports tree. Dunno if it had additional info or this second one is enough. I mixed both in one :) I do appreciate the explanations very much. I am having a problem with a port in which if NO_STAGE is not set, then the build part of the process fails. As far as I can tell, staging should not effect the build part of the process in any way. So two questions: 1. If I set NO_STAGE=yes in that port, is this going to be a big problem? It will have to be a work around until I can get the next question answered: 2. Any ideas on why staging would effect the build process? The port includes subpackages that use ./configure; make; make install and are supposed to install into $WRKSRC/local, but instead sometimes installs into $WRKDIR/stage/portname/work/pkgname/local. Thanks, Stephen -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJSTWGBAAoJEC3xK9GaktgHbxUH+QFAGwLtosFLmskl0e/KB3qB zf+PP7UtZutAllfpFss/v1EgfioLOKq9jhggTeBRUClqj1enPcSeaNC4qEAOg4Zv oZeRGtPhV4kzUzvUhI0y6Odz1rANjQ1FiRZ0qrSNZXJqp+CLPItAHhiEKvesvUAm Ic3Z+jpG2XTZVNJIkZM8WUJjdCMNFjphRfyX4v3M4Q8+Q1CIETi+Re4ciiH/G3rX onuw5cTWR6PGymWfRLRTPaLNRftFXYMmDkhY/mMM3sg6vZVHdq6tSqpDa61qiuQx W4MsI6SaO/DEkorVcaesEWbNsgffNdN6fOJGCHHP4STcfVb3OE8r2rcpvs3XT3Y= =K3LU -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: Explain staging
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/03/2013 07:32 AM, Baptiste Daroussin wrote: On Thu, Oct 03, 2013 at 07:22:35AM -0500, Stephen Montgomery-Smith wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/03/2013 04:54 AM, Baptiste Daroussin wrote: On Thu, Oct 03, 2013 at 10:58:56AM +0200, Alex Dupre wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Baptiste Daroussin ha scritto: Here you are: http://lists.freebsd.org/pipermail/freebsd-ports/2013-October/086346.html I was referring the the previous one: [HEADSUP] Stage support for the ports tree. Dunno if it had additional info or this second one is enough. I mixed both in one :) I do appreciate the explanations very much. I am having a problem with a port in which if NO_STAGE is not set, then the build part of the process fails. As far as I can tell, staging should not effect the build part of the process in any way. So two questions: 1. If I set NO_STAGE=yes in that port, is this going to be a big problem? It will have to be a work around until I can get the next question answered: 2. Any ideas on why staging would effect the build process? The port includes subpackages that use ./configure; make; make install and are supposed to install into $WRKSRC/local, but instead sometimes installs into $WRKDIR/stage/portname/work/pkgname/local. Thanks, Stephen Which port is that? Maybe I can help? It is math/sage. But I think it is working in this current port. The problem, I think, is in math/sage-devel, which exists only in my private ports tree. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJSTWa5AAoJEC3xK9GaktgHM1AIAMZcwUMiD5tUU+qsM+ruKXLd +6RMANAhiwfGqpkW80FsplgO8siZ9eh8JZuCOYyymO51NkX4L59GBqsDT7DjgXS2 zcZjK/ClxTyj2iZI+zxTXoc8RO0mZuKkOcsOWNsOuEO3X0YpPAGCl98iGWf+/knX HN/ez862Tx8Oee28BTfZzX0vaHVLQotPyDfV+DPgUfMCQIfztotqlsJcKAfdwENk Y6W5lbZwCYdhWswn5cFfsLJ92EfEbBJnGS9tTBq1GXZzuKlsq3gcfc27UoJoc5zj GVUuiW4+kDVeVluta1b0xNLi9Q+/7nQF9fF+hed7PwssbHNNj9sFH5ZtLEylWNM= =l71P -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: Explain staging
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/03/2013 07:44 AM, Stephen Montgomery-Smith wrote: On 10/03/2013 07:32 AM, Baptiste Daroussin wrote: On Thu, Oct 03, 2013 at 07:22:35AM -0500, Stephen Montgomery-Smith wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/03/2013 04:54 AM, Baptiste Daroussin wrote: On Thu, Oct 03, 2013 at 10:58:56AM +0200, Alex Dupre wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Baptiste Daroussin ha scritto: Here you are: http://lists.freebsd.org/pipermail/freebsd-ports/2013-October/086346.html I was referring the the previous one: [HEADSUP] Stage support for the ports tree. Dunno if it had additional info or this second one is enough. I mixed both in one :) I do appreciate the explanations very much. I am having a problem with a port in which if NO_STAGE is not set, then the build part of the process fails. As far as I can tell, staging should not effect the build part of the process in any way. So two questions: 1. If I set NO_STAGE=yes in that port, is this going to be a big problem? It will have to be a work around until I can get the next question answered: 2. Any ideas on why staging would effect the build process? The port includes subpackages that use ./configure; make; make install and are supposed to install into $WRKSRC/local, but instead sometimes installs into $WRKDIR/stage/portname/work/pkgname/local. Thanks, Stephen Which port is that? Maybe I can help? It is math/sage. But I think it is working in this current port. The problem, I think, is in math/sage-devel, which exists only in my private ports tree. Also, I am not in a super hurry to fix this problem. Work and family life are quite big stressors in my life right now. Fixing easy bugs and updates to the ports is quite relaxing, but something that will require a full investigation like this is going to be on a waiting list. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJSTWk5AAoJEC3xK9GaktgHoT0IAJN0Sn6rBCBetZqa2FuM/EPm GNe4diIX/cs0UKYZZQN9Gj8g5EXNgNaDJ1nPuTHt4jAyo92YYM6GTLSsPBhfY7rA D6cfmYMUEVY2YtKODigjMb7XF6F9Lv6hZkNnuiZGUwAmW0FmDCejysP0M+qlmHEf xgLLhzCJ1w64vbgr7/OzMdb4FftR/ja1F5UFJjwGZakVcSQEhRL0N4kdEzTC0/PT My85TEvyUg0N1QrcZRrvLfcZFkpSeqjPscRo+LptvVSFf2PtkTZOOtArYbFIattY +oCn/G301YLawG78lRrnLYxuCxYVHwzZSalMTzcc5c61Hdvf2ooCUBokI5MoAfc= =qgOF -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: Explain staging
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/03/2013 07:22 AM, Stephen Montgomery-Smith wrote: On 10/03/2013 04:54 AM, Baptiste Daroussin wrote: On Thu, Oct 03, 2013 at 10:58:56AM +0200, Alex Dupre wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Baptiste Daroussin ha scritto: Here you are: http://lists.freebsd.org/pipermail/freebsd-ports/2013-October/086346.html I was referring the the previous one: [HEADSUP] Stage support for the ports tree. Dunno if it had additional info or this second one is enough. I mixed both in one :) I do appreciate the explanations very much. I am having a problem with a port in which if NO_STAGE is not set, then the build part of the process fails. As far as I can tell, staging should not effect the build part of the process in any way. So two questions: 1. If I set NO_STAGE=yes in that port, is this going to be a big problem? It will have to be a work around until I can get the next question answered: 2. Any ideas on why staging would effect the build process? The port includes subpackages that use ./configure; make; make install and are supposed to install into $WRKSRC/local, but instead sometimes installs into $WRKDIR/stage/portname/work/pkgname/local. FYI So when NO_STAGE is not set, MAKE_ARGS includes DESTDIR=$WRKDIR/work/stage. This messes up the build process on this port. This is probably something to be fixed way down the road, and perhaps it is my port that needs fixing. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJSThgPAAoJEC3xK9GaktgHHDEIALDlt86BrDvR2CjjINGwyQdh okMhRAM0my/XftIy+2GHMAh95+l86LW4cDDpgLFneydjWLwRV3ZQBb4H6up0MpWN +MrNeruNirl17XdoRcOEXyBHbtbbym1bIToAGuPOvJGocvOoer9HKpYxZ3sX/OCU uL+nr/Zh7pdJq0TgwCXlhNTQnf77qZEnQcrYxjEpBP+zgQz7gXpH+RfC0yfbXERP zeOEEojdy7Y6IZyzd9C+TskEn5VH1DH0MSz9/sOVzRgebh51SRWMFWtCgPiNJZBE 04A96X/RiY1boKK1QK3/hjlLqDlVY8UPLTvGtvaUolJPGHDLR1oJfyKYxUw33oU= =RCk8 -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
Explain staging
I have not been following discussions recently. There is this new thing called staging. I don't seem able to find the original emails where this was introduced. Is there an email or a website which explains in some detail how staging works? It is badly messing with a port I am developing. I can fix it by setting NO_STAGE=yes, but I would like to get a better idea of why it is failing. The failure is during the build process. Sorry for not following closer. ___ 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: submitting multiple ports at once
On 08/27/2013 05:53 PM, Aryeh Friedman wrote: What is the best way to submit 4 or 5 ports at once (I have all the port files themselves stored on the same site that the distfiles are on and contain the same general pattern of ftp:://site.com/XXX/port-0.1.tar.gz)... so I do it one PR per port with the standard subject for a new port or a single PR for all of them with a ptr to the dist. site? If the ports are similar or related, I would put them all into one PR. If the only similarity is the location of the distfiles, I would submit different PRs. But generally, I don't think either way makes life any easier or more difficult for the person who commits the ports. ___ 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: GNOME 3
On 06/09/2013 06:33 PM, Kenta Suzumoto wrote: Is there any ETA on getting GNOME 3 into FreeBSD ports? Also, if gnome3 goes into ports, is there any chance we could keep a legacy gnome2 going for a while? I discovered that I really hate gnome3 based upon my usage with ubuntu, and I have switched instead to mate. It would be good to keep gnome2 going on FreeBSD at least until FreeBSD has a well working mate. ___ 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: GNOME 3
On 06/09/2013 08:27 PM, Eric Turgeon wrote: I think gnome2 will be replace by Mate which is far more better and less buggy. I am running mate 1.6 right now on FreeBSD it work well and fast. https://github.com/jlmess77/mate-ports#mate-ports-for-freebsd Cool! On Sun, Jun 9, 2013 at 10:20 PM, Stephen Montgomery-Smith step...@missouri.edu mailto:step...@missouri.edu wrote: On 06/09/2013 06:33 PM, Kenta Suzumoto wrote: Is there any ETA on getting GNOME 3 into FreeBSD ports? Also, if gnome3 goes into ports, is there any chance we could keep a legacy gnome2 going for a while? I discovered that I really hate gnome3 based upon my usage with ubuntu, and I have switched instead to mate. It would be good to keep gnome2 going on FreeBSD at least until FreeBSD has a well working mate. ___ freebsd-gn...@freebsd.org mailto:freebsd-gn...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-gnome To unsubscribe, send any mail to freebsd-gnome-unsubscr...@freebsd.org mailto:freebsd-gnome-unsubscr...@freebsd.org -- *Eric Turgeon **GhostBSD project* Office location: 1-11 connaught Moncton NB Canada www.ghostbsd.org http://www.ghostbsd.org/http://www.ghostbsd.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
Problem building openoffice-3 on FreeBSD-8.4
uname -a FreeBSD wilberforce 8.4-PRERELEASE FreeBSD 8.4-PRERELEASE #0: Tue Apr 2 16:51:28 CDT 2013 stephen@wilberforce:/usr/obj/usr/src/sys/GENERIC amd64 The problem was fixed by uncommenting the line in Makefile #USE_GCC= 4.6+ I think these are the relevant pieces of the make process that show you what isn't working: R=/usr/ports/editors/openoffice-3/work/aoo-3.4.1 S=$R/main O=$S/solver/341/unxfbsdx.pro W=$O/workdir mkdir -p $W/CxxObject/vcl/unx/generic/gdi/ mkdir -p $W/Dep/CxxObject/vcl/unx/generic/gdi/ c++ -DCPPU_ENV=gcc3 -DCUI -DENABLE_GRAPHITE -DENABLE_GTK -DENABLE_LAYOUT=0 -DENABLE_LAYOUT_EXPERIMENTAL=0 -DFREEBSD -DGCC -DGXX_INCLUDE_PATH=/usr/include/c++/4.2 -DHAVE_GCC_VISIBILITY_FEATURE -DNDEBUG -DOPTIMIZE -DOSL_DEBUG_LEVEL=0 -DPRODUCT -DPRODUCT_FULL -DSOLAR_JAVA -DSTLPORT_VERSION=400 -DSUPD=341 -DUNIX -DUNX -DVCL -DX86_64 -D_PTHREADS -D_REENTRANT -D_XSALSET_LIBNAME=\libspa.so\ -DVCLPLUG_GEN_IMPLEMENTATION -DUSE_RANDR -DUSE_XINERAMA -DUSE_XINERAMA_XORG -Wall -Wendif-labels -Wextra -Wno-ctor-dtor-privacy -Wno-non-virtual-dtor -Wshadow -fPIC -fmessage-length=0 -fno-common -fno-strict-aliasing -fno-use-cxa-atexit -fvisibility-inlines-hidden -fvisibility=hidden -pipe -D_THREAD_SAFE -I/usr/local/include -DEXCEPTIONS_ON -fexceptions -fno-enforce-eh-specs -Os -c $S/vcl/unx/generic/gdi/salvd.cxx -o $W/CxxObject/vcl/unx/generic/gdi/salvd.o -MMD -MT $W/CxxObject/vcl/unx/generic/gdi/salvd.o -MF $W/Dep/CxxObject/vcl/unx/generic/gdi/salvd.d -I$S/vcl/unx/generic/gdi/ -I$O/inc/stl -I$O/inc/stl -I$O/inc/external -I$O/inc -I$S/solenv/unxfbsdx/inc -I$S/solenv/inc -I$S/res -I$S/solenv/inc/Xp31 -I/usr/local/openjdk6/include -I/usr/local/openjdk6/include/freebsd -I/usr/local/openjdk6/include/bsd -I/usr/local/openjdk6/include/linux -I/usr/local/openjdk6/include/native_threads/include -I/usr/local/include -I$S/vcl/inc -I$S/vcl/inc/pch -I$S/solenv/inc -I$O/inc/offuh -I$O/inc/stl -I$O/inc [ build CXX ] vcl/unx/generic/gdi/xrender_peer In file included from /usr/local/include/graphite/GrClient.h:31, from /usr/ports/editors/openoffice-3/work/aoo-3.4.1/main/vcl/inc/graphite_layout.hxx:40, from /usr/ports/editors/openoffice-3/work/aoo-3.4.1/main/vcl/unx/generic/gdi/pspgraphics.cxx:52: /usr/local/include/graphite/GrFeature.h:110: error: 'wstring' in namespace '_STL' does not name a type /usr/local/include/graphite/GrFeature.h:111: error: 'wstring' in namespace '_STL' does not name a type /usr/local/include/graphite/GrFeature.h:113: error: 'wstring' in namespace '_STL' does not name a type In file included from /usr/ports/editors/openoffice-3/work/aoo-3.4.1/main/vcl/inc/graphite_layout.hxx:41, from /usr/ports/editors/openoffice-3/work/aoo-3.4.1/main/vcl/unx/generic/gdi/pspgraphics.cxx:52: /usr/local/include/graphite/Font.h:392: error: '_STL::wstring' has not been declared In file included from /usr/ports/editors/openoffice-3/work/aoo-3.4.1/main/vcl/inc/graphite_serverfont.hxx:32, from /usr/ports/editors/openoffice-3/work/aoo-3.4.1/main/vcl/unx/generic/gdi/pspgraphics.cxx:53: /usr/ports/editors/openoffice-3/work/aoo-3.4.1/main/vcl/inc/graphite_adaptors.hxx:118: error: 'ext_std::wstring' has not been declared In file included from /usr/local/include/graphite/GrClient.h:31, from /usr/ports/editors/openoffice-3/work/aoo-3.4.1/main/vcl/inc/graphite_layout.hxx:40, from /usr/ports/editors/openoffice-3/work/aoo-3.4.1/main/vcl/unx/generic/gdi/salgdi3.cxx:77: /usr/local/include/graphite/GrFeature.h:110: error: 'wstring' in namespace '_STL' does not name a type /usr/local/include/graphite/GrFeature.h:111: error: 'wstring' in namespace '_STL' does not name a type /usr/local/include/graphite/GrFeature.h:113: error: 'wstring' in namespace '_STL' does not name a type In file included from /usr/ports/editors/openoffice-3/work/aoo-3.4.1/main/vcl/inc/graphite_layout.hxx:41, from /usr/ports/editors/openoffice-3/work/aoo-3.4.1/main/vcl/unx/generic/gdi/salgdi3.cxx:77: /usr/local/include/graphite/Font.h:392: error: '_STL::wstring' has not been declared In file included from /usr/ports/editors/openoffice-3/work/aoo-3.4.1/main/vcl/inc/graphite_serverfont.hxx:32, from /usr/ports/editors/openoffice-3/work/aoo-3.4.1/main/vcl/unx/generic/gdi/salgdi3.cxx:78: /usr/ports/editors/openoffice-3/work/aoo-3.4.1/main/vcl/inc/graphite_adaptors.hxx:118: error: 'ext_std::wstring' has not been declared gmake: *** [/usr/ports/editors/openoffice-3/work/aoo-3.4.1/main/solver/341/unxfbsdx.pro/workdir/CxxObject/vcl/unx/generic/gdi/pspgraphics.o] Error 1 1 module(s): vcl need(s) to be rebuilt Reason(s): ERROR: error 65280 occurred while making /usr/ports/editors/openoffice-3/work/aoo-3.4.1/main/vcl/prj ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to
USE_TEX question
So I have a port, math/sage, which now contains in Makefile the line USE_TEX=tetex I have intalled the texlive ports. So now if I try to install math/sage, it gives me error messages about CONFLICTS, which I think arise from the fact that math/sage thinks that it has to first install tetex, and this conflict with various texlive ports. But, math/sage is TEX agnostic. It doesn't care whether it is tetex or texlive that is installed. All it really wants to know is if there is a useable latex in PATH. It would be nice if there was a USE_TEX=yes option, or something like that, which I could put into the math/sage port. Stephen ___ 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: USE_TEX question
On 05/09/13 13:15, Chris Rees wrote:
On 9 May 2013 18:36, Stephen Montgomery-Smith step...@missouri.edu wrote:
So I have a port, math/sage, which now contains in Makefile the line
USE_TEX=tetex
I have intalled the texlive ports. So now if I try to install math/sage, it
gives me error messages about CONFLICTS, which I think arise from the fact
that math/sage thinks that it has to first install tetex, and this conflict
with various texlive ports.
But, math/sage is TEX agnostic. It doesn't care whether it is tetex or
texlive that is installed. All it really wants to know is if there is a
useable latex in PATH.
It would be nice if there was a USE_TEX=yes option, or something like that,
which I could put into the math/sage port.
USE_TEX=${TEX_DEFAULT} should work fine-- have you tried that?
Chris
Ah, yes. And you have to set TEX_DEFAULT in /etc/make.conf as well.
___
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
Problem with japanese/tex-ptex going very slowly
Many thanks for creating the texlive port! I am trying to install the recent japanese/tex-ptex port. It seems to spend several hours doing: fmtutil: running `ptex -ini -jobname=ptex -progname=ptex ptex.ini #ptex' ... Is this normal? If it is normal, would it be OK if japanese/tex-ptex where not included in the standard build of print/texlive-full? ___ 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
tlmgr paper letter
Many thanks for creating the texlive port! I installed the texlive-full port (without tex-ptex). I tried to change the page size with the following command (as root): tlmgr paper letter cannot setup TLPDB in /usr at /usr/local/bin/tlmgr line 4965. ___ 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: Problem with japanese/tex-ptex going very slowly
On 05/06/13 11:40, Hiroki Sato wrote: Stephen Montgomery-Smith step...@missouri.edu wrote in 5187c454.2050...@missouri.edu: st Many thanks for creating the texlive port! st st I am trying to install the recent japanese/tex-ptex port. It seems to st spend several hours doing: st st fmtutil: running `ptex -ini -jobname=ptex -progname=ptex ptex.ini st #ptex' ... st st Is this normal? No, it is odd. Can you send me the result of the following two commands? % grep -A2 lastarg /usr/local/bin/fmtutil % find /usr/local/share/texmf* $HOME/.tex* I had a whole bunch of stuff in ~root/.texlive2011. Cleaning it all out fixed ptex so that it worked instantly. Thank you. ___ 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: OpenCASCADE
On 04/03/2013 12:34 PM, Andrea Venturoli wrote:
Also interesting is cat/netgen, whose Makefile states:
.if ${PORT_OPTIONS:MOCC}
BROKEN= The opencascade port needs to be updated before OCC
will work
(this is why I'm cc-ing stephen).
My initial naive attempts to build netgen with the new opencascade did
not work. I'll try to work on this some more (maybe netgen is looking
in the wrong directories, etc).
___
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
gfortran and USE_GCC
If in my Makefile I have: USE_GCC=4.7+ USE_FORTRAN=yes and then I type make test-gcc, I get CC=gcc47 - CXX=g++47 - CPP=cpp47 - CFLAGS=-pipe -Wl,-rpath=/usr/local/lib/gcc47 F77=gfortran46 - FC=gfortran46 - FFLAGS=-pipe -Wl,-rpath=/usr/local/lib/gcc47 LDFLAGS= -Wl,-rpath=/usr/local/lib/gcc47 Shouldn't F77 and FC be gfortran47? ___ 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
Questions about ldconfig
I am looking at committing a port which creates the following files: /usr/local/lib/libGmsh.so /usr/local/lib/libGmsh.so.0 /usr/local/lib/libGmsh.so.2.7 /usr/local/lib/libGmsh.so.2.7.0 libGmsh.so is a link to libGmsh.so.0, which is a link to libGmsh.so.2.7, which is a link to libGmsh.so.2.7.0. My concern is that this will confuse ldconfig. Is my concern justified? ___ 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: CFT: texlive ports
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/27/2013 07:10 PM, Hiroki Sato wrote: http://people.allbsd.org/~hrs/FreeBSD/texlive-20130228-1.tar.gz It built successfully. But when I tried to run the command tlmgr I got the following error message: Can't locate TeXLive/TLConfig.pm in @INC (@INC contains: /usr/texmf/scripts/texlive /usr/tlpkg /usr/local/lib/perl5/5.14.2/BSDPAN /usr/local/lib/perl5/site_perl/5.14.2/mach /usr/local/lib/perl5/site_perl/5.14.2 /usr/local/lib/perl5/5.14.2/mach /usr/local/lib/perl5/5.14.2 .) at /usr/local/bin/tlmgr line 81. BEGIN failed--compilation aborted at /usr/local/bin/tlmgr line 81. tlmgr is rather important, for example, it allows me to set the default page size (us-letter or A4). tlmgr does work on my version of texlive: http://people.freebsd.org/~stephen/ (but my version has other flaws so I would prefer that your version worked). -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJRLth5AAoJEC3xK9GaktgHKQcH+gJf57Fu6eNPKpC/wSJql8Us qCVdFsSAh3d/IZaqnp31q7xu10e/By4Av+C8RkSZGW8IpJAD5jobdeambh7b1TWN izTd9F68gAx45XtcG7yHGL8SNm3N8MWUY9peU2eDHFkg6GpGxT+oxuSyfNcXOZfh VXFGI9r8jsRL2YPqOhmGX6Opl//PFZxLvD6Y8m3NUtUDbjSAqlwlIKySuBIGosax 4SOBi17vrg1TYC7ktBjcILsJHfIY0QBoDfQnLnx188MgQUNETcdIFxlFl5v9uFPt iYmV19c0VpvpUA7wafOSuQxaloAZ1wMqM1gUoZttK394dY/nR2sHx0lcmNEqY/A= =iOMo -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
pkg-plist for security/super
The first line of security/super/pkg-plist is: # $FreeBSD: head/security/super/pkg-plist 307297 2012-11-10 17:38:33Z pawel $ This has the unfortunate effect that the package install process thinks that there is a file by this name. So for example, make deinstall produces: pkg_delete: file '/usr/local/# $FreeBSD: head/security/super/pkg-plist 307297 2012-11-10 17:38:33Z pawel $' doesn't exist and there is a similar error for make package. (I have seen a lot of email correspondence about pkgng, which I must admit I have not followed at all. Is this related in some way?) Stephen ___ 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: pkg-plist for security/super
On 02/09/2013 11:16 AM, Pawel Pekala wrote: Dnia 2013-02-09, o godz. 16:56:03 Chris Rees cr...@freebsd.org napisał(a): On 9 February 2013 16:42, Stephen Montgomery-Smith step...@missouri.edu wrote: The first line of security/super/pkg-plist is: # $FreeBSD: head/security/super/pkg-plist 307297 2012-11-10 17:38:33Z pawel $ This has the unfortunate effect that the package install process thinks that there is a file by this name. So for example, make deinstall produces: pkg_delete: file '/usr/local/# $FreeBSD: head/security/super/pkg-plist 307297 2012-11-10 17:38:33Z pawel $' doesn't exist and there is a similar error for make package. (I have seen a lot of email correspondence about pkgng, which I must admit I have not followed at all. Is this related in some way?) It is incorrect. If a $FreeBSD$ is included at all in a pkg-plist it must be preceded by @comment. Pawel, please fix! Should be fixed now. Why do we want this line in pkg-plist at all? ___ 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..
On 12/21/2012 05:07 PM, Eitan Adler wrote: On 21 December 2012 13:49, Ronald Klop ronald-freeb...@klop.yi.org wrote: Try to set the environment variable MAKE_JOBS_NUMBER=1 before building. If this fixes it please let us know - its a bug in the makefile that needs to be fixed. Also try -DMAKES_JOBS_UNSAFE instead of MAKE_JOBS_NUMBER=1 the latter does -j1 which is subtly different than no -j at all. First, I wanted to correct a typo - it is -DMAKE_JOBS_UNSAFE (no S). Secondly, as of today, this bug must still be present, because I couldn't build devel/openjdk6 without the -DMAKE_JOBS_UNSAFE on my amd64 Intel i5 computer. ___ 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: How to apply an svn diff
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/08/2013 03:49 PM, Matthew Seaman wrote: On 08/01/2013 21:47, Paul Schmehl wrote: Once you've created an svn diff and submitted it using send-pr, how is the diff applied to update the port? I can't seem to figure this out from reading the svn docs. use patch(1) While we are on the subject of patch, has anyone else noticed the following annoyance? Suppose you create a patch against a non-existent file (using diff - -N), and let's suppose the old file is dir-orig/xxx, and the new file is dir/xxx. Then if I apply the patch to dir, and dir-orig doesn't exist, then patch issues all kinds of horrible error messages, and the new file is installed in the current directory rather than dir. I'm not sure if it is a bug or a feature. But it has bitten me more than once. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iQEcBAEBAgAGBQJQ7KyFAAoJEC3xK9GaktgHCecH/1b/MgIe177Xo0TGTvlWs0gD sU/N1oUOj/EUUgb1DJZCn+V6v6fOehVNuGydi/RqOXsAlS99QrNAxpwG6WFmb3wz dzv2sCwq4nbXv3jjssZRPHZpcvIT6HT3EScffAaGHEdLrYHWMHAjUrfyfuvBcJ6p HyI7+Sa3yebtCJLyxzZQGijMw9xiwk/VNO9AjbB4A3zjoM8veBSlHV3d7LSfov4H QNDJDLuVvTo4Wko9MuBByaQXmslUVR5ekI1Fvenud00ujV/7Artxe8bSawUT0H3K pBs00fj3XT2ik6Nitvzh1W82nLAM5oOhdbL9bzumQjIqdSrnoTN9Fp6ZdA9U8nY= =Vbr7 -END PGP SIGNATURE- ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: FreeBSD ports you maintain which are out of date
On 11/27/2012 07:06 PM, Shane Ambler wrote: On 28/11/2012 09:45, Kevin Oberman wrote: On Tue, Nov 27, 2012 at 8:12 AM, Radim Kolar h...@filez.com wrote: can be this daily spam turned off? i emailed there portsc...@portscout.freebsd.org but message was not delivered It's not spam, but a very useful service. I you don't work on any ports, you should be able to filter it very easily with procmail or your mail reader. Probably more to the point is that it shouldn't get sent to the ports mailing list - just to port maintainers. Maybe once a month a list can be sent to the mailing list that would be unmaintained ports that need updating? To put in my 2 cents, I think it is a great service. I don't have a problem with info about unmaintained ports being sent to the ports mailing list quite often. There are already many emails on the ports mailing list that don't interest me. So a few more is not going to be a problem. And if it causes people to update a few of the unmaintained ports, it is doing a great job. On the other hand, poutscout also seems to keep a web page, so maybe a once a month email, with a reminder about the web page, would also be helpful. Let me add that it has definitely helped me keep up to date with the ports I maintain. Whatever else it is, spam it is not. Stephen ___ 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
science/getdp
Hey, does anyone use the science/getdp port? I took over maintainership, perhaps because at that time I was using it. Now I am working on updating it to 2.2.1, which is quite a jump from where it currently is at 1.2.1. Anyway, I just wanted to check with anyone to see if this would be a problem. Thanks, Stephen ___ 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: How to check out ports
On 10/02/12 11:23, Paul Schmehl wrote: Are we supposed to be using cvs or svn to check out ports now? If cvs, I'm getting prompted for a password which fails. I think you are supposed to use *csup* or svn. But use svn - it is easy, and csup is going to be phased out very soon. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: [CORRECTION] Change to the header in ports Makefiles, take two
On 09/17/12 11:43, Freddie Cash wrote: On Mon, Sep 17, 2012 at 9:33 AM, Thomas Abthorpe portmgr-secret...@freebsd.org wrote: It was recently posted on, http://blogs.freebsdish.org/portmgr/2012/09/01/change-to-the-header-in-ports-makefiles/ that we would adopt a new header for the ports Makefiles. The initial discussion seemed to show enough support for the idea of completely stripping the header, leaving only the $FreeBSD$ tag. After the announcement was made, more people stated strong feelings that when and where possible attribution be maintained in the header. A private discussion was held among ports committers, and while opinions were as varied as the individuals who shared them, it was decided to unify on a two line header. # Created by: J.Q. Public jqpub...@someaddress.com # $FreeBSD$ The Whom line from the classic six line header becomes Created By. Sometimes, as a result of a repocopy, or changed maintainership, the Created By and MAINTAINER is no longer in synchronisation. To avoid confusion, the first line can be removed, optionally leaving us with a one line header. # $FreeBSD$ Wouldn't it make sense to have the # $FreeBSD$ line be the first line of the file, so that it never changes? Having some files where the FreeBSD tag is first, and other files where it's second seems arbitrarily inconsistent. Lines that don't change should come first, so that things are always the same. IMHO, of course. :) You want *consistency* ? What will people ask for next? ___ 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: MAINTAINER lines and Real Names
On 09/11/2012 03:59 PM, Chris Rees wrote: Hi all, Ever since I peeked at OpenBSD's ports [1] to see how they handle headers, I've noticed something else nice that they do. Instead of the plain, boring who-the-hell-is-this MAINTAINER line that we have; MAINTAINER=cr...@freebsd.org they have the much more pleasant and personal style; MAINTAINER=Chris Rees cr...@freebsd.org I think it is a good idea. (But I thought I suggested the same idea a few days ago!) ___ 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: [HEADS-UP] Announcing the end of port CVS
On 09/07/2012 07:36 AM, Beat Gaetzi wrote: For those reasons by February 28th 2013 the FreeBSD ports tree will no longer be exported to CVS. This question is curiosity more than anything else. What will happen to the existing ports cvs. Will it merely stagnate, or will it be removed? What I mean by this is if my cvsup-file is *default host=cvsup11.freebsd.org *default prefix=/usr/home/library/ctm/FreeBSD/FreeBSD-CVS *default base=/usr/home/library/ctm/FreeBSD/FreeBSD-CVS *default release=cvs delete use-rel-suffix cvs-all then when I run this in Feb 28, will the ports subdirectory merely be unchanged, or will it be deleted in its entirety? ___ 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: Need advice for a new port ?/libgta
On 06/12/2012 11:20 AM, coder.tuxfamily wrote: Hello, I finished to make the ports of libgta (http://gta.nongnu.org/libgta.html). But i don't really know what can be the category. Maybe Math because the lib is about Array. What is your advice ? My suggestion is the devel category. Or perhaps the databases category, because really it is a format for storing data, but maybe databases has more specific meanings like data stored with an index. I don't recommend math though. ___ 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: Documenting 'make config' options
On 06/09/2012 11:35 AM, Doug Barton wrote: On 06/06/2012 22:27, Dave Hayes wrote: Personally, a 'pkg-options-descr' text file would suit me just fine. For those on -ports, the context is, How do we provide more information about what the various options mean? This idea seems reasonable to me, what do others think? I think it is a good idea. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Request to review: print/texlive-install
On 05/27/2012 09:19 PM, Eitan Adler wrote: On 27 May 2012 18:14, Stephen Montgomery-Smithstep...@missouri.edu wrote: There are a number of issues. In particular there is no checksum calculated for install-tl-unx.tar.gz because I suspect that it changes very often. This is a security risk and must not be committed as is. OK, I won't commit it as it is. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Request to review: print/texlive-install
On 05/27/2012 08:48 PM, Nikola Lečić wrote: On Sun, 27 May 2012 20:32:14 -0500, Stephen Montgomery-Smith wrote: Hi People, I have written a simple port which is in essence a wrapper around the texlive installation script. It also builds (almost) all of the binaries from scratch. Does anyone have any suggestions? Would anyone mind if this port was committed? There are a number of issues. In particular there is no checksum calculated for install-tl-unx.tar.gz because I suspect that it changes very often. Also the install-tl- script doesn't seem to have a capability to be run in batch mode. I hacked a way around this, but it could be easily broken if the script were to change in some unexpected way. But it does build and install texlive in a fairly timely manner. And the result can be made into a (large) package using pkg_create. Stephen, TeX Live 2011 builds fine for me with this port. Just a few comments: 1. Biber doesn't need compat7x. It works on 7 and above without it. Moreover, the TeX Live's configure script already takes care of the FreeBSD version in the FreeBSD way. Please take a look: http://www.tug.org/svn/texlive/trunk/Build/source/utils/biber/configure?revision=26215view=markup lines 3563-3583, or just search for '__FreeBSD_version'. The binaries distributed with the source work on FreeBSD=701000 and biber will not be installed if older FreeBSD is detected. (I meant that it could be possible to cover FreeBSD-6 with biber binaries distributed over CTAN. But that's not extremely important for now.) 2. fontconfig is a run dependency as well, xetex needs it to run. Thanks. What about perl - is that a run dependency as well? 3. TeX Live ships with its own portable FreeBSD i386/amd64 xz and wget binaries and install-tl/tlmgr use them. They will not work on FreeBSD7. Therefore, it could be possible that you need to add xz and wget as build/run dependencies on FreeBSD7 and on architectures other than i386/amd64, although I haven't checked this. I won't worry about FreeBSD7. They are end of line anyway. 4. Since the aim of your port is not to create portable binaries, there is no reason not to build xindy. You can freely add '--enable-xindy CLISP=/path to the clisp binary/', and lang/clisp as a build dependency. I was looking at the online docs of xindy. Is the version of xindy that comes with texlive out of date? The online docs don't match the program that comes with xindy. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Request to review: print/texlive-install
On 05/27/2012 09:19 PM, Eitan Adler wrote: On 27 May 2012 18:14, Stephen Montgomery-Smithstep...@missouri.edu wrote: There are a number of issues. In particular there is no checksum calculated for install-tl-unx.tar.gz because I suspect that it changes very often. This is a security risk and must not be committed as is. How about if I add lines like this: .if !defined(IGNORE_SECURITY_RISK) IGNORE= has a security risk because it downloads a file \ without a checksum. Define IGNORE_SECURITY_RISK to build this port .endif Would it be considered OK to commit it then? ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Request to review: print/texlive-install
On 05/28/2012 10:47 AM, Michael Scheidell wrote: On 5/28/12 10:11 AM, Stephen Montgomery-Smith wrote: How about if I add lines like this: .if !defined(IGNORE_SECURITY_RISK) IGNORE= has a security risk because it downloads a file \ without a checksum. Define IGNORE_SECURITY_RISK to build this port .endif Would it be considered OK to commit it then? could you host it somewhere that won't go away at missouri.edu? I could host it somewhere at missouri.edu that will stay as long as I am alive or keep my job. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Request to review: print/texlive-install
On 05/28/2012 10:44 AM, Nikola Lečić wrote:
On Mon, 28 May 2012 09:06:18 -0500, Stephen Montgomery-Smith wrote:
2. fontconfig is a run dependency as well, xetex needs it to run.
Thanks. What about perl - is that a run dependency as well?
Yes, it is, install-tl and tlmgr are perl scripts.
3. TeX Live ships with its own portable FreeBSD i386/amd64 xz and wget
binaries and install-tl/tlmgr use them. They will not work on FreeBSD7.
Therefore, it could be possible that you need to add xz and wget as
build/run dependencies on FreeBSD7 and on architectures other than
i386/amd64, although I haven't checked this.
I won't worry about FreeBSD7. They are end of line anyway.
Ok.
But it looks like tlmgr expects to find wget in its path. So I'll add
it as a run dependency.
4. Since the aim of your port is not to create portable binaries, there
is no reason not to build xindy. You can freely add '--enable-xindy
CLISP=/path to the clisp binary/', and lang/clisp as a build dependency.
I was looking at the online docs of xindy. Is the version of xindy
that comes with texlive out of date? The online docs don't match the
program that comes with xindy.
Many other programs are out of date, TeX Live 2011 was released a year
ago. The versions distributed with TL releases match together well. The
safest options for TL2011 users is to use xindy distributed with TL2011.
I will add an option that allows xindy to be built.
More notes/questions:
* You could add x11-toolkits/p5-Tk as a run dependency. tlmgr has a
nice GUI; actually it's very inconvenient to use it without gui.
I will add an option that will add x11-toolkits/p5-Tk as a run dependency.
* Since this port leaves full TeX Live system installed, users should
use tlmgr to update their packages and scripts. Two questions in this
respect:
a) what will happen with /var/db/ports/ info?
he info will become out of date. But when the user tries to deinstall
the package, he/she gets helpful messages that says it could not be
completely deinstalled, and says where the problem is. And since the
only stuff that will have changed is in ${PREFIX}/texlive, the user
should find it easy to delete the left over stuff.
Also I think one could add a pkg-deinstall message that says to apply
rm -rf ${PREFIX}/texlive just to be sure.
b) it's not a good idea to run tlmgr gui as root. Maybe to offer an
option with SUID Bit, as in sysutils/xcdroast?
This looks non-trivial. Simply setting the setuid bit on the tlmgr
script doesn't work, because it is a perl script. One way would be to
write a wrapper.
But I would recommend the port security/super which allows you to
create scripts that can be run with setuid. Then let the user set this
up as they desire.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Request to review: print/texlive-install
On 05/28/2012 11:29 AM, Jason Helfman wrote: On 05/27/2012 09:19 PM, Eitan Adler wrote: On 27 May 2012 18:14, Stephen Montgomery-Smithstep...@missouri.edu wrote: There are a number of issues. In particular there is no checksum calculated for install-tl-unx.tar.gz because I suspect that it changes very often. This is a security risk and must not be committed as is. How about if I add lines like this: .if !defined(IGNORE_SECURITY_RISK) IGNORE= has a security risk because it downloads a file \ without a checksum. Define IGNORE_SECURITY_RISK to build this port .endif Would it be considered OK to commit it then? Does the code look for a particular location for this file to exist before attempting to download it? If not, can it be patched, to do so? If so, it can be added as a distfile, and put into a location where the build will find it. Yes, I can do this. But the file changes often, so one would have to update distinfo in the ports very often to keep up. If this can be done, there wouldn't be a security risk, assuming no other files are downloaded post-fetch. And the install script downloads everything during the do-install phase. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Request to review: print/texlive-install
On 05/28/2012 12:31 PM, Chris Rees wrote:
On 28 May 2012 18:11, Stephen Montgomery-Smithstep...@missouri.edu wrote:
On 05/28/2012 11:35 AM, Gábor Kövesdán wrote:
On 2012.05.28. 18:16, Stephen Montgomery-Smith wrote:
On 5/28/12 10:11 AM, Stephen Montgomery-Smith wrote:
How about if I add lines like this:
.if !defined(IGNORE_SECURITY_RISK)
IGNORE= has a security risk because it downloads a file \
without a checksum. Define IGNORE_SECURITY_RISK to build this port
.endif
Would it be considered OK to commit it then?
could you host it somewhere that won't go away at missouri.edu?
I could host it somewhere at missouri.edu that will stay as long as I
am alive or keep my job.
Better to host it on the FreeBSD mirrors. You only have to create a
public_distfiles in your home directory after logging in to freefall and
drop the file there. This is the usual way of doing it.
Thank you for the info. Here is my latest version:
http://people.freebsd.org/~stephen/
I'm afraid my concerns still hold [1].
This port fetches $WHOKNOWSWHAT from $WHOKNOWSWHERE outside the fetch
stage, which isn't how ports are supposed to work.
I know 'having a port' is usually considered a good thing, but as I
said before, it's no easier or safer to install this via the port than
just download and run the script.
[1] http://lists.freebsd.org/pipermail/freebsd-ports/2012-May/075236.html
Yes, this will never become part of the ports tree as it is. I am
merely going to offer this to people as something they can download from
my web page.
The advantage it offers over the usual script is that the binaries are
built for your particular system. And /var/db/pkg is populated. And
links are created to ${PREFIX}/bin.
[2]
'''
Install texlive-install.
Use texlive to grab funky new package.
Upgrade texlive-install /* XXX funky new package is now added to
texlive-instal plist */
Upgrade texlive-install again
Hey, where did $FUNKY go?
'''
Hopefully $FUNKY will now be part of the complete texlive install, and
so it will be reinstalled in the second (and first) upgrades.
Otherwise I see no way around this problem.
===
One thing I might do is to create a port called texlive-binaries with
instructions in pkg-message on how to incorporate it into the texlive
distribution when you use the script downloaded from their web page. (I
need to check that the name texlive-binaries doesn't conflict with
http://code.google.com/p/freebsd-texlive.)
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: math/sage security risk
On 05/28/2012 01:38 PM, Eitan Adler wrote: On 28 May 2012 10:14, Stephen Montgomery-Smithstep...@missouri.edu wrote: After my recent conversations about creating a print/texlive-install port, I realize that my math/sage port might have a security risk. This only happens if the user selects additional optional packages. But the optional packages are downloaded post-fetch. I'll make some immediate band-aid changes to the port to switch this off, but I'll think through the issue in the days to come. adding ports-security to cc so we could track the issue I just committed instructions to the port math/sage telling users how to add the optional packages manually, and explaining the security risk. Please contact me if this is still a problem. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: TeXLive merge into FreeBSD ports tree - is this going to happen or not?
On 05/26/2012 09:19 AM, Nikola Lečić wrote: On Sat, 26 May 2012 09:01:37 -0400, Jerry wrote: On Sat, 26 May 2012 22:42:50 +1200 Sam Lin articulated: This was already repeated many times on this mailing list, but I guess it won't hurt to remind that vanilla TeX Live works on FreeBSD (from 7.0 to 10-CURRENT) out of the box. It lives in /usr/local/texlive/, has its own nice text and gui package manager and doesn't mess with the rest of your system. Just download ISO and install it. This is what I have done, and it has worked very well - except the xdvi program that came with texlive was linked to a different version of the xorg libraries! But http://code.google.com/p/freebsd-texlive/wiki/Installing didn't work for me. I tried the tlmgr command to change to letter paper size, and it gave me error messages. (I must admit that I haven't tried this recently so maybe it got fixed. But I didn't get any good responses when I complained on the freebsd-texlive mailing list - if I remember correctly I was told I shouldn't be using tlmgr.) But also, the current proposed freebsd texlive just looks way to difficult to maintain. Everytime the texlive distribution changes, the texlive ports have to update. If I were to implement texlive as a freebsd port, I would create a port called print/texlive-install. This port would build a texlive install-tl-unx.tar.gz program, just like can be found on the texlive web sites, but with xdvi and other binaries compiled by the port, but everything else operating according to the texlive philosophy. The port would run the install program, and then do a find /usr/local/texlive to fill in the appropriate /var/db/pkg/texlive files. I have written other ports where the ported software doesn't work well with the FreeBSD ports philosophy, and my approach has been to embrace the software's philosophy and make the freebsd port a wrapper for the software's installation process. This includes the math/sage port, and the math/octave-forge* ports. If I had the time, I would do the same for a texlive-install port. If wouldn't conflict with (but it would compete against) the current proposed freebsd texlive ports. The reason I haven't done this yet is (1) because of time constraints, and (2) I feel uncomfortable competing with someone elses proposed port structure. P.S. How did I solve the xdvi problem? I installed texlive from the texlive web site. Then I installed the FreeBSD print/teTeX port. Then I set PATH so that it picked up most of the commands from /usr/local/texlive/bin, but picked up xdvi from /usr/local/bin. I know it is an ugly hack. Stephen ___ 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: TeXLive merge into FreeBSD ports tree - is this going to happen or not?
On 05/26/2012 11:33 AM, Nikola Lečić wrote: On Sat, 26 May 2012 10:38:18 -0500, Stephen Montgomery-Smith wrote: On 05/26/2012 09:19 AM, Nikola Lečić wrote: This is what I have done, and it has worked very well - except the xdvi program that came with texlive was linked to a different version of the xorg libraries! [...] P.S. How did I solve the xdvi problem? I installed texlive from the texlive web site. Then I installed the FreeBSD print/teTeX port. Then I set PATH so that it picked up most of the commands from /usr/local/texlive/bin, but picked up xdvi from /usr/local/bin. I know it is an ugly hack. Please read this document: http://anthesphoria.net/FreeBSD/TeXLive-2011/bin/README.txt TeX Live FreeBSD binaries are a compromise between portability and easiness to resolve problems in cases such as yours. We did a lot of work over the last 3 years (minimalistic compiler options, customised perl binaries/libs...) to reduce the number of shared libraries dependencies as much as possible. The result: the installer, package manager and ca. 350 non-graphic utilities work for all FreeBSD=7. If you use asymptote, xdvi or xindy (compiled with clisp) on FreeBSD7, simply install misc/compat7. Best, Nikola (maintainer of TeX Live for FreeBSD) Do you have instructions for how to build customized texlive binaries? Then we could create a port that creates amd64-freebsd-tl2011.tar.xz or i386-freebsd-tl2011.tar.xz. ___ 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: problem running pkg_delete
On 05/12/2012 01:24 PM, Robert Huff wrote: Suddenly I'm getting: pkg_delete: the package info for package Source is corrupt Any ideas? Is it possible that you created a directory by accident inside /var/db/pkg called Source? ___ 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: problem running pkg_delete
On 05/12/2012 06:25 PM, Stephen Montgomery-Smith wrote: On 05/12/2012 01:24 PM, Robert Huff wrote: Suddenly I'm getting: pkg_delete: the package info for package Source is corrupt Any ideas? Is it possible that you created a directory by accident inside /var/db/pkg called Source? Also, I am trying to look through the source code in pkg_delete to see what could have created this message. As best as I can tell, this message must have been created by the function matchallbyorigin in /usr/src/usr.sbin/pkg_install/lib/match.c which was called by the function pkg_do in /usr/src/usr.sbin/pkg_install/delete/perform.c. The source code for pkg_do contains the disclaimer This is seriously ugly code following. Written very fast! Do you remember at all the command you typed that created this 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
Re: problem running pkg_delete
On 05/12/2012 08:06 PM, Jason Hellenthal wrote: On Sat, May 12, 2012 at 06:31:44PM -0500, Stephen Montgomery-Smith wrote: On 05/12/2012 06:25 PM, Stephen Montgomery-Smith wrote: On 05/12/2012 01:24 PM, Robert Huff wrote: Suddenly I'm getting: pkg_delete: the package info for package Source is corrupt Any ideas? Is it possible that you created a directory by accident inside /var/db/pkg called Source? Also, I am trying to look through the source code in pkg_delete to see what could have created this message. As best as I can tell, this message must have been created by the function matchallbyorigin in /usr/src/usr.sbin/pkg_install/lib/match.c which was called by the function pkg_do in /usr/src/usr.sbin/pkg_install/delete/perform.c. The source code for pkg_do contains the disclaimer This is seriously ugly code following. Written very fast! Do you remember at all the command you typed that created this message? You would probably get the same message from: mkdir /var/db/pkg/Source pkg_delete Source Try it out! I did think of this. But this creates the error message: pkg_delete: the package info for package 'Source' is corrupt (use -f to force removal) and is generated from within pkg_do in /usr/src/usr.sbin/pkg_install/delete/perform.c This has the additional part to the message (use -f to force removal) which the OP did not report. And if you look at the source, you will see that it has to have some kind of additional message, the other possibility being (but I'll delete it anyway). But maybe the OP forgot to report this. ___ 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: sage install error
On 05/07/2012 04:14 PM, Bruce Meier wrote: Freebsd 8.2 release processor amd64 #more start.log [2012-05-07 01:11:58] Sage version 4.8, released 2012-01-20 Setting permissions of DOT_SAGE directory so only you can read and write it. Traceback (most recent call last): File /usr/ports/math/sage/work/sage-4.8/local/bin/sage-eval, line 4, in module from sage.all import * File /usr/ports/math/sage/work/sage-4.8/local/lib/python2.6/site-packages/sage/all.py, line 78, in module import sage.symbolic.pynac File expression.pxd, line 6, in init sage.symbolic.pynac (sage/symbolic/pynac.cpp:19189) File expression.pyx, line 145, in init sage.symbolic.expression (sage/symbolic/expression.cpp:35722) File function.pyx, line 31, in init sage.symbolic.function (sage/symbolic/function.cpp:11736) ImportError: /usr/ports/math/sage/work/sage-4.8/local/lib/python2.6/site-packages/sage/ext/fast_eval.so: Undefined symbol log2 [2012-05-07 08:23:04] Sage version 4.8, released 2012-01-20 Traceback (most recent call last): File /usr/ports/math/sage/work/sage-4.8/local/bin/sage-eval, line 4, in module from sage.all import * File /usr/ports/math/sage/work/sage-4.8/local/lib/python2.6/site-packages/sage/all.py, line 78, in module import sage.symbolic.pynac File expression.pxd, line 6, in init sage.symbolic.pynac (sage/symbolic/pynac.cpp:19189) File expression.pyx, line 145, in init sage.symbolic.expression (sage/symbolic/expression.cpp:35722) File function.pyx, line 31, in init sage.symbolic.function (sage/symbolic/function.cpp:11736) ImportError: /usr/ports/math/sage/work/sage-4.8/local/lib/python2.6/site-packages/sage/ext/fast_eval.so: Undefined symbol log2 ___ 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 Can you continue this discussion directly with me at step...@freebsd.org? I am happy to work with you as hard as I can to resolve this issue, but I am mystified. I created the sage port on the amd64 using FreeBSD-Stable-8.2, which is almost identical to what you have. Somehow python is not finding the libm library, which is where log2 is defined. ___ 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: autodetecting dependencies
On 04/09/12 21:56, Mel Flynn wrote: On 4/10/2012 04:02, Stephen Montgomery-Smith wrote: 1. Don't worry about it. tinderbox builds will never build port A in the presence of package B. 2. Have the Makefile of port A detect whether package B is installed, and if it is then add B as a dependency of A. 3. Cripple the configure in port A so that it doesn't autodetect for package B. (Sometimes this can be done using a suitable CONFIGURE_ARGS, but not in my particular situation.) 4. Add OPTION PACKAGE_B. And cripple configure through EXTRA_PATCH if set to off. Package B doesn't seem to offer any extra functionality to port A. I ended up going with option 3, because it turned out to be easier than I thought it would be. ___ 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: octave port will be updated to 3.6.1 and all the octave-forge ports will be updated accordingly.
On 04/10/2012 08:51 PM, Maho NAKATA wrote: Hi Stephen, and ports@ I would like to ask you the final check of our patch against octave and octave-forge-* port. I also e-mail to port@ since it is a sweeping commit. Now ports tree has been unfrozen. Octave 3.6.1 is out and I would like to update with attached patch. Let me add that after this patch has been committed by Maho, I will update quite a few of the octave-forge ports: anything dated on or after 2012-03-01 on http://sourceforge.net/projects/octave/files/Octave%20Forge%20Packages/Individual%20Package%20Releases/ The reason I am delaying these updates until octave-3.6.1 is installed is that these updates only seem to work with octave-3.6.0 and later. The reason I am telling people this is that when the octave port has been updated, you might like to wait a short while before rebuilding the octave-forge ports until I have committed these later updates. Stephen ___ 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: octave port will be updated to 3.6.1 and all the octave-forge ports will be updated accordingly.
I'm now done as well. On 04/10/2012 10:05 PM, Maho NAKATA wrote: Hi Stephen, Done from my side, now it's your turn! Best Nakata Maho From: Stephen Montgomery-Smithstep...@missouri.edu Subject: Re: octave port will be updated to 3.6.1 and all the octave-forge ports will be updated accordingly. Date: Tue, 10 Apr 2012 21:31:28 -0500 On 04/10/2012 08:51 PM, Maho NAKATA wrote: Hi Stephen, and ports@ I would like to ask you the final check of our patch against octave and octave-forge-* port. I also e-mail to port@ since it is a sweeping commit. Now ports tree has been unfrozen. Octave 3.6.1 is out and I would like to update with attached patch. Let me add that after this patch has been committed by Maho, I will update quite a few of the octave-forge ports: anything dated on or after 2012-03-01 on http://sourceforge.net/projects/octave/files/Octave%20Forge%20Packages/Individual%20Package%20Releases/ The reason I am delaying these updates until octave-3.6.1 is installed is that these updates only seem to work with octave-3.6.0 and later. The reason I am telling people this is that when the octave port has been updated, you might like to wait a short while before rebuilding the octave-forge ports until I have committed these later updates. Stephen ___ 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
autodetecting dependencies
So suppose we are building port A. It turns out that the configure in port A autodetects whether package B is present or not. It will build either way. But if built with package B, it will not operate without it. So suppose I build port A on machine X which has package B installed. Then I create a package from A, and copy the package to machine Y. Machine Y does not have package B installed, and so when package A is installed, it doesn't work on machine Y. What are the accepted ways of handling this? 1. Don't worry about it. tinderbox builds will never build port A in the presence of package B. 2. Have the Makefile of port A detect whether package B is installed, and if it is then add B as a dependency of A. 3. Cripple the configure in port A so that it doesn't autodetect for package B. (Sometimes this can be done using a suitable CONFIGURE_ARGS, but not in my particular situation.) I prefer the answer (1). But I am interested in other people's opinions. One problem with (2) or (3) is that the creator of the port might never find out which packages could be autodetected by port A's configure without performing an exhaustive search of the source code of A. Thanks, Stephen ___ 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: FAQ on PORTREVISION bump?
On 03/28/2012 11:13 AM, Philip M. Gollucci wrote: PORTREVISION is historically bumped when you change the resultant package under the default OPTIONS. Basically if you cause the package to be rebuilt on pointyhat then you need to bump it. I was going to say the same thing. But then I thought: this will cause PORTREVISION to be bumped anytime a RUN_DEPENDS or LIB_DEPENDS is updated (because the package will change in +CONTENTS). But, for example, it seems to me that PORTREVISION should NOT be bumped if a LIB_DEPENDS changes, and it is not a major library revision change. For example, in this case the portmaster program reinstalls the library only, and changes the +CONTENTS and +REQUIRED_BY of the various installed packages appropriately. And the program will still work just fine. So PORTREVISION should not be bumped. ___ 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: Please test your commits
On 02/14/12 08:40, b. f. wrote: On 12.02.2012 22:43, Stephen Montgomery-Smith wrote: On 02/12/2012 03:33 PM, Andriy Gapon wrote: on 12/02/2012 23:22 Stephen Montgomery-Smith said the following: On 02/12/2012 03:15 PM, Andriy Gapon wrote: Today I became another user of redports.org. I can definitely recommend it. Yes, but it is not without its problems. I tried testing math/sage on redports.org. It reported an error building the dependency math/atlas, which built fine on mine and other people's systems. But still this is an instance of environment where the port can fail, so it warrants an investigation and fixing. Either in the port or in the redports infrastructure. Yes, you are correct. In fact, in the case of math/atlas there is the following report. It looks like people are working on it. http://portsmon.freebsd.org/portoverview.py?category=mathportname=atlaswildcard= I think this isn't directly related. The build on redports had status dud in math/atlas which means the port has set IGNORE. I have no good way of telling which IGNORE line it is yet but it can only be one of: You have set WITH_ARCHDEF, but have not defined ARCHDEF You must select at least one of WITH_SHARED and WITH_STATIC both sound strange. There is nothing strange about them: they just indicate errors arising from invalid choices of OPTIONS. The build is more likely to be broken by MANUAL_PACKAGE_BUILD, which uses IGNORE. That would explain the problems I am having. I'll quit trying to test sage on redports. ___ 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: Please test your commits
On 02/12/2012 01:39 PM, Steve Kargl wrote: Is there any reguirement that a ports committer needs to test their intended commit prior to pulling the trigger? http://www.freebsd.org/cgi/cvsweb.cgi/ports/print/ghostscript9/Makefile You should report which version of FreeBSD you are using. It might have tested OK for the committer, but not for you. By the way, I didn't get the error you reported in your first message, but I did get the error reported in your later message. I am using FreeBSD 8.2 STABLE on the amd64. You seem to have the faulty belief that this is the first occurrence of this type of issue? The same committer? Or someone else. If it is a repeat offense, I can see why you would want to blow off some steam. However as a committer myself, I do like it when someone politely points out my error, and gives me a chance to correct myself. For example, I recently had a very pleasant exchange with someone who helped me fix my math/sage port for FreeBSD 9. Stephen ___ 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: Please test your commits
On 02/12/2012 02:41 PM, Steve Kargl wrote: On Sun, Feb 12, 2012 at 10:27:25PM +0200, Andriy Gapon wrote: on 12/02/2012 22:16 Steve Kargl said the following: You seem to have the faulty belief that this is the first occurence of this type of issue? So instead of proper report to the port's maintainer (including description of your environment, possibly full build log, etc), possibly with a CC here, you decided to vent out here... Is there any requirement that people do the former and not the latter? :-) I'm not venting. I'm simply requesting that all committers test the code that they intend to commit. It is quite clear that this particular commit was not tested. The environment is irrelevant because malloc.h was poisoned 10 years, 3 months ago. As to a full build log, the necessary information was included in my original email. Except I didn't get the malloc.h error when I tried compiling it. So merely noting the age of malloc.h doesn't prove that the committer didn't test it. ___ 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: Please test your commits
On 02/12/2012 03:15 PM, Andriy Gapon wrote: Today I became another user of redports.org. I can definitely recommend it. Yes, but it is not without its problems. I tried testing math/sage on redports.org. It reported an error building the dependency math/atlas, which built fine on mine and other people's systems. Also, if everyone starts using it, isn't the backlog going to become huge? ___ 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: Please test your commits
On 02/12/2012 03:17 PM, Steve Kargl wrote: On Sun, Feb 12, 2012 at 08:52:56PM +, Chris Rees wrote: On 12 Feb 2012 20:45, Steve Kargls...@troutmask.apl.washington.edu wrote: laptop:root[252] uname -a FreeBSD laptop 10.0-CURRENT FreeBSD 10.0-CURRENT #0 r230975M: Sat Feb 4 09:03:27 PST 2012 root@laptop:/usr/obj/usr/src/sys/MOBILE i386 Well, that immediately shows that this is a 10.0 error, which means it's almost certainly due to freebsd1* being matched in some configure script. Empirical evidence suggests that ghostscript9 developers are using a newer version of the autotools. laptop:root[262] find . -name configure | xargs grep -i freebsd\[1 | more ./lcms/configure:freebsd[123].*) objformat=aout ;; ./lcms/configure: freebsd[12].*) ./lcms/configure:freebsd[123].*) objformat=aout ;; ./lcms/configure:freebsd[123].*) objformat=aout ;; ./lcms/configure:freebsd[123].*) objformat=aout ;; ./freetype/builds/unix/configure:freebsd[123].*) objformat=aout ;; ./lcms2/configure:freebsd[123].*) objformat=aout ;; ./lcms2/configure: freebsd[12].*) ./lcms2/configure:freebsd[123].*) objformat=aout ;; laptop:root[263] find . -name configure | xargs grep -i freebsd1 | more ./lcms/configure:freebsd1.*) ./lcms/configure:freebsd1.*) ./lcms/configure:freebsd1.*) ./lcms/configure:freebsd1.*) ./lcms/configure:freebsd1.*) ./lcms/configure:freebsd1.*) ./lcms/configure:freebsd1.*) ./freetype/builds/unix/configure:freebsd1.*) ./freetype/builds/unix/configure:freebsd1.*) ./lcms2/configure:freebsd1.*) ./lcms2/configure:freebsd1.*) The malloc issue will not appear on amd64 because the problematic code is #elif !defined(__amd64__) !defined(__APPLE__) #define HAVE_MEMALIGN #includemalloc.h #endif with the obvious fix #elif !defined(__amd64__) !defined(__APPLE__) !defined(__FreeBSD__) #define HAVE_MEMALIGN #includemalloc.h #endif But, the 2nd issue with too many arguments in a function call is clearly evident on amd64 because I justed test that on FreeBSD 10. Yes. But the issue isn't whether someone else was correct in why the port might or might not have built in a particular environment. The issue is whether you were too hasty in your initial accusation that the committer didn't test their commit. And another issue is whether you should apologize to them for attempting to publicly humiliate them. Stephen ___ 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: Please test your commits
On 02/12/2012 03:33 PM, Andriy Gapon wrote: on 12/02/2012 23:22 Stephen Montgomery-Smith said the following: On 02/12/2012 03:15 PM, Andriy Gapon wrote: Today I became another user of redports.org. I can definitely recommend it. Yes, but it is not without its problems. I tried testing math/sage on redports.org. It reported an error building the dependency math/atlas, which built fine on mine and other people's systems. But still this is an instance of environment where the port can fail, so it warrants an investigation and fixing. Either in the port or in the redports infrastructure. Yes, you are correct. In fact, in the case of math/atlas there is the following report. It looks like people are working on it. http://portsmon.freebsd.org/portoverview.py?category=mathportname=atlaswildcard= Although, it also didn't work on report when I asked for an amd64 build. So it still didn't help me testing math/sage. I ended up relying on another user who politely informed me of build errors on his system, and was kind enough to try my patches. Also, if everyone starts using it, isn't the backlog going to become huge? I'll let the redports team worry about this :-) Fair enough. ___ 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
LDFLAGS mystery
If I build a port that uses USE_FORTRAN, then the variable ${LDFLAGS}
has an extra space in it. For example
%cd /usr/ports/math/lapack
%make -V LDFLAGS
-Wl,-rpath=/usr/local/lib/gcc46
%make -V MAKE_ENV
LDFLAGS= -Wl,-rpath=/usr/local/lib/gcc46 ...
I am trying to create a port in which this creates problems.
Where does the extra space at the beginning come from, and how do I get
rid of it?
___
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: LDFLAGS mystery
On 01/21/2012 03:02 PM, Stephen Montgomery-Smith wrote:
If I build a port that uses USE_FORTRAN, then the variable ${LDFLAGS}
has an extra space in it. For example
%cd /usr/ports/math/lapack
%make -V LDFLAGS
-Wl,-rpath=/usr/local/lib/gcc46
%make -V MAKE_ENV
LDFLAGS= -Wl,-rpath=/usr/local/lib/gcc46 ...
I am trying to create a port in which this creates problems.
Where does the extra space at the beginning come from, and how do I get
rid of it?
I solved the mystery. Inside /usr/share/mk/sys.mk is the line:
LDFLAGS ?=
I think that it is a bug in make that
XXX=
XXX+=xxx
results in XXX having the value xxx.
___
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: Upgrading libs with many dependent ports
On 01/17/2012 07:51 PM, Kevin Oberman wrote:
I have just been cleaning up the mess caused by the upgrade of xcb-utils.
On my systmes I have hundreds of ports that will be re-built by the methods
listed in UPDATING, even though the vast majority of them are only
dependent on other ports that are dependent on xcb-utils, but don't
actually load any of the libraries in xcb-utils. It is a huge waste of time
and CPU cycles.
I think that I can see two ways of eliminating the rebuilding of ports that
don't need it. One is rather manual but can be done now while the other
wou;d be automatic, but would need to be written by someone who is far
better at writing shell scripts than I.
The manual method would be to install sysutils/bsdadminscripts and use a
command like `pkg_libchk | grep -E xcb-.+.so | sort tmpfile` to provide
a list of ports that actually are linked to the libraries in question. This
would be fed into portmaster to rebuild just these ports. (I guess I could
use awk and uniq to remove repeats.)
Should this become a preferred method of handling this problem?
You mean something like the attached script?
Type
perl pkg_libchk xcb-util-0.3.6,1
and it tells you all the ports that have xcb-util-0.3.6,1 as a lib-depends.
On my system I get 38 ports that require upgrading. All the other 248
dependencies installed on my system are only run-depends, and so don't
need to be upgraded.
I wrote it using perl, because I think a shell script would be quite a
bit slower. And it is already quite slow as it is.
It looks worth implementing, because it looks like it could save
considerable compilation time. If other people think this tool is
useful, someone could clean up the script (e.g. it isn't PREFIX
friendly, and assumes the port database is /var/db/pkg, etc). It could
also be written as a C program without too much trouble.
#!/usr/bin/perl -w
use strict;
my %lib_found;
my %ldd;
sub pkg_libchk {
my $req=/var/db/pkg/$_[0]/+REQUIRED_BY;
return if ! -e $req;
my @libs;
open(my $C,/var/db/pkg/$_[0]/+CONTENTS) || die;
while ($C) {
if (!/^\@/ /\/(lib[^\/]+\.so)$/) {
push @libs,$1;
}
}
close $C;
return if $#libs==-1;
open(my $R,$req) || die;
while (my $r=$R) {
next if defined($lib_found{$r});
chomp $r;
open(my $C,/var/db/pkg/$r/+CONTENTS) || die;
while (my $f=$C) {
chomp $f;
if ($f !~ /^@/) {
if (!defined($ldd{$f})) {
$ldd{$f} = `ldd /usr/local/$f 2/dev/null`;
}
foreach my $l (@libs) {
if ($ldd{$f} =~/$l/) {
if (!defined($lib_found{$r})) {
print $r\n;
$lib_found{$r}=1;
pkg_libchk($r);
goto DONE;
}
}
}
}
}
DONE:
close($C);
}
close($R);
}
die if ! -e /var/db/pkg/$ARGV[0];
pkg_libchk($ARGV[0]);
___
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: Upgrading libs with many dependent ports
On 01/17/2012 08:43 PM, Kevin Oberman wrote:
On Tue, Jan 17, 2012 at 6:09 PM, Matthew D. Fullerfulle...@over-yonder.net
wrote:
On Tue, Jan 17, 2012 at 05:51:11PM -0800 I heard the voice of
Kevin Oberman, and lo! it spake thus:
The manual method would be to install sysutils/bsdadminscripts and
use a command like `pkg_libchk | grep -E xcb-.+.so | sort
tmpfile` to provide a list of ports that actually are linked to the
libraries in question.
FWIW, I some years ago wrote up a quickdirty perl script to find
missing or out of date libs. It pulls out and warns about missing
libs, stuff in compat/pkg (held over after upgrade by
portupgrade/portmaster), and stuff in the base /usr/lib/compat (handy
when crossing major versions, and potentially other big upheavals).
It's only about a k; I'll attach it.
I pretty much wind up ldd'ing /usr/local/{bin/*,sbin/*,lib/*.so*} and
running the results through the script. Usually something like `cd
/usr/local/bin ; ldd * /tmp/ldd.bin ; lddchk.pl /tmp/ldd.bin`.
That tells me the files; then I can use my brain or pkg_which to tell
me which packages are involved. I'm happy with that level of
automation, because I like keeping my brain firmly in the loop on such
things, but it wouldn't be too hard to extend it to do its own walks
over the filesystem, etc.
Take a look at pkg_chklib. It is quite optimized and runs multiple checks
in parallel so that
you can run it on 1100 ports in about 1.5 minutes. Here is a sample o this
output:
%pkg_libchk | grep -E xcb-.+.so | sort
gok-2.30.1,1: /usr/local/bin/create-branching-keyboard misses
libxcb-atom.so.1
gok-2.30.1,1: /usr/local/bin/create-branching-keyboard misses
libxcb-aux.so.0
gok-2.30.1,1: /usr/local/bin/create-branching-keyboard misses
libxcb-event.so.1
gok-2.30.1,1: /usr/local/bin/gok misses libxcb-atom.so.1
gok-2.30.1,1: /usr/local/bin/gok misses libxcb-aux.so.0
gok-2.30.1,1: /usr/local/bin/gok misses libxcb-event.so.1
nautilus-open-terminal-0.18_4:
/usr/local/lib/nautilus/extensions-2.0/libnautilus-open-terminal.so misses
libxcb-atom.so.1
nautilus-open-terminal-0.18_4:
/usr/local/lib/nautilus/extensions-2.0/libnautilus-open-terminal.so misses
libxcb-aux.so.0
nautilus-open-terminal-0.18_4:
/usr/local/lib/nautilus/extensions-2.0/libnautilus-open-terminal.so misses
libxcb-event.so.1
vlc-1.1.13,3: /usr/local/lib/vlc/plugins/control/libglobalhotkeys_plugin.so
misses libxcb-keysyms.so.1
vlc-1.1.13,3:
/usr/local/lib/vlc/plugins/video_output/libxcb_window_plugin.so misses
libxcb-keysyms.so.1
yelp-2.30.2_1: /usr/local/bin/yelp misses libxcb-atom.so.1
yelp-2.30.2_1: /usr/local/bin/yelp misses libxcb-aux.so.0
yelp-2.30.2_1: /usr/local/bin/yelp misses libxcb-event.so.1
%
And it is already in ports.
And in my other email, I might have reinvented the wheel!
___
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: Acroread: contacting maintainer
On 01/15/2012 09:40 PM, Da Rock wrote: What is the correct way to contact the maintainer for a port? Does one contact directly? Or through a list (this one?)? Or pr? I'm trying to contact the maintainer of the acroread ports to see if they can put in a dependency on linux-f10-cups-libs for the ease of use by general users, and to enable acceptance by the graphics industry niche. I tried a direct email, but I've received no response as yet after several days; and I'm not 100% sure I did the right thing. Cheers Contacting the maintainer is definitely a good thing to do. He might be on vacation, or busy with some other aspect of life - who knows. A few days is definitely not a long time to wait. Another way to do it is to submit a PR with your proposed change. THe maintainer of the port will be automatically contacted and asked to approve the changes. If the maintainer doesn't reply after a few months, you can ask for a maintainer timeout, and someone will then commit it. But I think waiting for a few more days for the maintainer to reply is a good thing to do. I have used this strategy very successfully many times in the past. Stephen ___ 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: unassociated shell command
On 01/11/2012 09:48 PM, Da Rock wrote:
On 01/12/12 13:01, Stephen Montgomery-Smith wrote:
I usually see this error when there is a command that doesn't belong
to a target. For example, if I create a Makefile that contains only:
echo xxx
I get the same error. So I think it is something in the part you
snipped out that makes this error happen.
Yes, I have run that scenario too and learnt from it.
The snipped bit is basically the same- but it works :/
I tried this Makefile, and got the same error.
all:
XXX=xxx
echo xxx
Putting in the assignment seems to split the command echo xxx from the
target all:.
So it looks like you need to separate the assignments from the commands.
@if [ -f ${WRKDIR}/etc/ldap.conf ]; then \
${MV} ${WRKDIR}/etc/ldap.conf ${WRKDIR}/etc/ldap.conf.dist; \
fi
.if defined(WITH_PAM)
PLIST_SUB+= PAM=
.else
@if [ -f ${WRKDIR}/lib/security/pam_ldap.so ]; then \
${RM} -rf ${WRKDIR}/lib/; \
fi
@if [ -f ${WRKDIR}/usr/share/doc/nss_ldap-264/COPYING.pam_ldap ]; then \
${RM} ${WRKDIR}/usr/share/doc/nss_ldap-264/*.pam*; \
${RM} -rf ${WRKDIR}/usr/share/doc/nss_ldap-264/pam.d; \
fi
@if [ -f ${WRKDIR}/usr/share/man/man5/pam_ldap.5.gz ]; then \
${RM} ${WRKDIR}/usr/share/man/man5/pam_ldap.5.gz; \
fi
PLIST_SUB+= PAM=@comment
.endif
Again, the indent is as is.
Removing the @ didn't work either...
On 01/11/2012 07:37 PM, Da Rock wrote:
I'm still very new to this, but I'm almost complete on my first port. I
do have an unusual error which crops up from time to time and I'm
usually able to fudge along and clear it- but this last little bit won't
clear!
The particular lines in question are as follows:
post-extract:
[snip]
.if defined(NOPORTDOCS)
@if [ -d ${WRKDIR}/usr/share/doc ]; then \
${RM} -rf ${WRKDIR}/usr/share/doc; \
fi
PLIST_SUB+=@comment
.else
PLIST_SUB+= PORTDOCS=
.endif
and I get the following error make -DNOPORTDOCS install:
Makefile, line 59: Unassociated shell command @if [ -d
${WRKDIR}/usr/share/doc ]; then ${RM} -rf ${WRKDIR}/usr/share/doc; fi
make: fatal errors encountered -- cannot continue
What am I possibly missing? No googling helps, and I've tried many
different tricks that have worked in the past as ${DIRRM}, ${RM},
individual directory/file removal, etc.
The indentation is exactly as in the Makefile.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: unassociated shell command
On 01/11/2012 10:14 PM, Da Rock wrote:
On 01/12/12 13:59, Stephen Montgomery-Smith wrote:
On 01/11/2012 09:48 PM, Da Rock wrote:
On 01/12/12 13:01, Stephen Montgomery-Smith wrote:
I usually see this error when there is a command that doesn't belong
to a target. For example, if I create a Makefile that contains only:
echo xxx
I get the same error. So I think it is something in the part you
snipped out that makes this error happen.
Yes, I have run that scenario too and learnt from it.
The snipped bit is basically the same- but it works :/
I tried this Makefile, and got the same error.
all:
XXX= xxx
echo xxx
Putting in the assignment seems to split the command echo xxx from
the target all:.
So it looks like you need to separate the assignments from the commands.
How do I do that, though? I have tried the assignment following the
commands (as it is now), but obviously thats not working either.
And why does it work in the other settings?
Maybe WITH_PAM is not defined.
But try something like this:
.if (conditionA)
XXX=
.endif
.if (conditionB)
ZZZ=
.endif
post-extract:
.if (conditionA)
@echo Doing A with ${XXX}
.endif
.if (conditionB)
@echo Doing B with ${ZZZ}
.endif
@if [ -f ${WRKDIR}/etc/ldap.conf ]; then \
${MV} ${WRKDIR}/etc/ldap.conf ${WRKDIR}/etc/ldap.conf.dist; \
fi
.if defined(WITH_PAM)
PLIST_SUB+= PAM=
.else
@if [ -f ${WRKDIR}/lib/security/pam_ldap.so ]; then \
${RM} -rf ${WRKDIR}/lib/; \
fi
@if [ -f ${WRKDIR}/usr/share/doc/nss_ldap-264/COPYING.pam_ldap ]; then \
${RM} ${WRKDIR}/usr/share/doc/nss_ldap-264/*.pam*; \
${RM} -rf ${WRKDIR}/usr/share/doc/nss_ldap-264/pam.d; \
fi
@if [ -f ${WRKDIR}/usr/share/man/man5/pam_ldap.5.gz ]; then \
${RM} ${WRKDIR}/usr/share/man/man5/pam_ldap.5.gz; \
fi
PLIST_SUB+= PAM=@comment
.endif
Again, the indent is as is.
Removing the @ didn't work either...
On 01/11/2012 07:37 PM, Da Rock wrote:
I'm still very new to this, but I'm almost complete on my first
port. I
do have an unusual error which crops up from time to time and I'm
usually able to fudge along and clear it- but this last little bit
won't
clear!
The particular lines in question are as follows:
post-extract:
[snip]
.if defined(NOPORTDOCS)
@if [ -d ${WRKDIR}/usr/share/doc ]; then \
${RM} -rf ${WRKDIR}/usr/share/doc; \
fi
PLIST_SUB+=@comment
.else
PLIST_SUB+= PORTDOCS=
.endif
and I get the following error make -DNOPORTDOCS install:
Makefile, line 59: Unassociated shell command @if [ -d
${WRKDIR}/usr/share/doc ]; then ${RM} -rf ${WRKDIR}/usr/share/doc; fi
make: fatal errors encountered -- cannot continue
What am I possibly missing? No googling helps, and I've tried many
different tricks that have worked in the past as ${DIRRM}, ${RM},
individual directory/file removal, etc.
The indentation is exactly as in the Makefile.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: redports.org - The public FreeBSD ports development infrastructure
I am trying this out. Looking at the instructions on https://redports.org/wiki/UserGuide: svn co https://svn.redports.org/yourusername mkdir www cp -pr /usr/ports/www/phpvirtualbox www/ svn add www svn commit -m phpvirtualbox added shouldn't there be a second line cd yourusername or something like that? ___ 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
Problem with ldconfig detecting libraries installed by devel/gdcm
I want to create a port that uses devel/gdcm as a dependency. But writing:
LIB_DEPENDS+= gdcmCommon:${PORTSDIR}/devel/gdcm
doesn't work. It does build the port, but it fails to detect that the
port is installed.
I notice that when I type:
ldconfig -r | grep gdcm
that it doesn't find the installed libraries. But this can be fixed by
doing
ln -s libgdcmCommon.so.2.0.18 libgdcmCommon.so.2
Note that the devel/gdmc port only installs
libgdcmCommon.so.2.0.18 libgdcmCommon.so.2.0libgdcmCommon.so
I contacted the port maintainer a few days ago, and this email is copied
to him. But I would also like to submit a PR that includes a fix so
that his job is easier.
But I am unsure what is the officially correct way to fix this? Is it
a bug in ldconfig? Or should the port create these links? Or were the
original writers of gdcm incorrect when the specify a major version
number that includes a period?
Thanks, Stephen
___
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: TeXLive
On 10/22/2011 01:18 AM, Hiroki Sato wrote: Romain Tartièrerom...@freebsd.org wrote in20111011101902.gb14...@blogreen.org: ro Hello! ro ro On Mon, Oct 10, 2011 at 07:23:48AM -0500, Stephen Montgomery-Smith wrote: roOn 10/10/2011 06:44 AM, Eitan Adler wrote: ro Are there any plans on getting these committed to the mainline ports ro tree? I'd be willing to work with you on that. ro roI agree with Eitan. ro ro I would also be pleased to see TeXLive in the FreeBSD ports (obviously). ro There are a few issues to sort out before however: ro- The way TeXLive sources are distributed is not convenient: all ro binaries are built and installed from a single sources tarball. ro This leads to the big print/texlive-core but really lacks ro scalability. Back in 2008, Hiroki Sato was working on splitting all ro this AFAICR. Hiroki, I added you in Cc, can you please tell us if ro you had any progress on this topic? I feel guilty about this because although I had/have several prototypes and plans to integrate TeXLive into the ports tree, it have not actually happened so far. There were two obstacles in the work. One was there were technical issues (compatibility-related) that prevented some existing TeX-related software we had in the ports tree from working. This was in around 2007 but solved now. Another one was how many ports we should have for TeX-related software. After testing several prototypes including a single port version, a set of ~2000 ports (one port for one macro), ~150 ports, or ~30 ports, I think it seems good for us to have one of basic utilities, one for basic (stripped-down) macro sets as something like texlive-core + texlive-texmf, and the others for optional macro packages. The basic idea is the same among them regardless of the total number of ports. In practical, 100 would be the maximum number. So, primary issues described above were basically solved. Although there are still trivial issues such as handling of a large distfile, it is not difficult to solve. However, how to handle updating a macro package in the basic port is a problem to me and time passed when I was thinking about that. More specifically, currently we have many latex-* and tex-* ports to install new macro packages or override the default ones. It becomes complex over time. Committing a single large TeXLive port is easy, but I do not want to create the same situation again in the new world and want consistency for updating a macro package in the distribution. So, I wanted some compatibility with TeXLive's package management utility (tlmgr). Unfortunately it was too premature when I first looked into it (around 2007, IIRC). The current version is much better than before, but I still need some investigation about that. If we have or use reliable package catalogs of CTAN including file lists of each macro package via tlmgr or something, we can take an approach like BSDPAN, I think. A version based on TeXLive 2011 with a small number of ports can be committed if we ignore the last concern and clean up the current teTeX-related ports. Any comments about that? I wasn't quite sure what you meant by the last concern. One concern that Romain brings up is that CTAN reroll their tarballs without updating the version number. I really like the idea of a few small texlive ports. In particular, this will really cut down on the invocations of mktexlsr. But what about this. Have one TeXlive port that installs installs the texlive installer (after building the binaries), and then it runs the texlive installer. The various options that the texlive installer has can be passed via config flags of the texlive port. Then the texlive port does a dynamic plist creation by doing a find on /usr/local/share/texlive (or whereever it is). And plist can also include an @unexec rm -rf %P/share/texlive. plist also includes links to the binaries in share/texlive/bin/xxx, so that they will be removed upon deinstallation. The current texlive installer on tug.org is not too bad, but it installs pre-made binaries, and on my system xdvi does not work because of dynamic library version conflicts. Also it doesn't delete the links it created in bin when it is deinstalled. The current texlive ports created by Romain have a serious deficiency in that tlmgr doesn't work. And tlmgr is necessary to do things like set the page size. Stephen ___ 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: TeXLive
On 10/10/2011 03:29 AM, Romain Tartière wrote: On Sun, Oct 09, 2011 at 09:58:50PM -0500, Stephen Montgomery-Smith wrote: Now I have a whole bunch of texlive ports installed under /usr/ports/print. Am I just supposed to build the ports I need, or is there some grand texlive-build-all port that is in this long list somewhere? I updated this page: http://code.google.com/p/freebsd-texlive/wiki/Installing You should at least install texlive-scheme-minimal but if you don't know exactly what you need, you may consider texlive-scheme-full ;-) That is exactly what I need! Next, tlmgr doesn't work. ls -l /usr/local/bin/tlmgr lrwxr-xr-x 1 root wheel 33 Oct 10 03:35 /usr/local/bin/tlmgr - ../texmf/scripts/texlive/tlmgr.pl I'm sure that should be ../share/texmf/scripts/texlive/tlmgr.pl ___ 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: TeXLive
On 10/10/2011 06:44 AM, Eitan Adler wrote: Are there any plans on getting these committed to the mainline ports tree? I'd be willing to work with you on that. I agree with Eitan. I don't see a reason why texlive shouldn't make it into the mainstream ports. What you need is to work with someone with a ports commit bit, and who is willing to take some responsibility to perform updates in a timely manner (because submitting PR's can take quite a while). Eitan has a ports commit bit, as do I. Since Eitan asked first, he gets first dibs, but I am willing to play that role as well. Stephen ___ 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: TeXLive
On 10/10/2011 07:23 AM, Stephen Montgomery-Smith wrote: On 10/10/2011 06:44 AM, Eitan Adler wrote: Are there any plans on getting these committed to the mainline ports tree? I'd be willing to work with you on that. I agree with Eitan. I don't see a reason why texlive shouldn't make it into the mainstream ports. What you need is to work with someone with a ports commit bit, and who is willing to take some responsibility to perform updates in a timely manner (because submitting PR's can take quite a while). Eitan has a ports commit bit, as do I. Since Eitan asked first, he gets first dibs, but I am willing to play that role as well. Stephen And Romain, I see that you have a commit bit as well! ___ 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: TeXLive
On 10/10/11 07:23, Stephen Montgomery-Smith wrote: On 10/10/2011 06:44 AM, Eitan Adler wrote: Are there any plans on getting these committed to the mainline ports tree? I'd be willing to work with you on that. I agree with Eitan. I don't see a reason why texlive shouldn't make it into the mainstream ports. Also, someone might object that it introduces 2000 ports into the print category. But as a counterargument, www and devel have similar numbers of ports. ___ 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: TeXLive
Hey guys, I did make -C /usr/ports/ports-mgmt/portshaker-config install # Ensure TEXLIVE is checked portshaker -v Now I have a whole bunch of texlive ports installed under /usr/ports/print. Am I just supposed to build the ports I need, or is there some grand texlive-build-all port that is in this long list somewhere? ___ 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: INDEX build failed for 7.x
On 10/02/2011 11:17 PM, Erwin Lansing wrote: INDEX build failed with errors: Generating INDEX-7 - please wait.. Done. Warning: Duplicate INDEX entry: qhull-1.0_2 Committers on the hook: eadler kmoore stephen sunpoet thierry It should be fixed now. ___ 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/161089: [REPOCOPY] math/qhull -- math/qhull5
I am sending this to you because you maintain a port that depends upon math/qhull. I plan to move this to math/qhull5, because the new version of qhull is not necessarily compatible with the port(s) you maintain. This is the complete list. games/kdegames4, math/labplot, math/octave-devel, math/octave, and math/plplot. More details at: http://www.freebsd.org/cgi/query-pr.cgi?pr=161089 ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: math/fftw3 port broken
On 09/25/2011 08:19 PM, Jerry wrote: When attempting to build the math/fftw3 port, the following error message is immediately displayed and the build halted: Variable CFLAGS is recursive. I have filed a PR against it. I am unable to reproduce this problem. Is it possible that something is wrong in your /etc/make.conf file? ___ 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: Thank you (for making the ports less boring).
On 09/13/2011 04:10 AM, Michal Varga wrote: And if it wasn't Gabor's commit that again brought my OS down to unusable level, it would be the one next week, or if we are lucky, two to three weeks from now (but that would be probably this year's record). Because the current procedures in place not only encourage these kinds of mistakes, they downright call for them. Because there are no procedures whatsoever. Not in the ecosystem-wide sense. Not the ones that are crucial to make the OS actually work as a whole. But hey, I'm not going to reiterate all that over again. It's been said. Hi Michal, I see where you are coming from. I just recently became a ports committer. Before, when I would submit ports, there were certain mistake consistently made by the committers. Now that I am a committer, I can see how the tools used by the committers would lead to these consistent mistakes. In particular, checking which ports depend on a port just updated is a particularly nasty thing to do. I get the impression that each committer has his own special way of doing this. For example, I have personally found that a simple grep won't work, because grep xxx /usr/ports/*/Makefile* just creates a line too long for the shell to handle. I use a shell construction involving find but I wonder how others do the same thing. My day job is taking a lot of my time right now. But when things start to calm down, I'll start thinking about changes to the ecosystem of FreeBSD ports committing, and creating a set of more unified tools for the other ports committers to look at. Finally, I did notice that since the overheated conversation of a few weeks ago, that a couple of people who wanted to update ports did contact me first. This is because I maintain ports that depend on their proposed update. So maybe your complaints are being heard, at least on one level. Best regards, Stephen ___ 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: Thank you (for making the ports less boring).
On 09/13/2011 09:11 AM, Oliver Fromme wrote: Stephen Montgomery-Smith wrote: particularly nasty thing to do. I get the impression that each committer has his own special way of doing this. For example, I have personally found that a simple grep won't work, because grep xxx /usr/ports/*/Makefile* just creates a line too long for the shell to handle. I use a shell construction involving find but I wonder how others do the same thing. cd /usr/ports echo */*/Makefile* | xargs grep xxx That's amazing. It would never have occurred to me that echo */*/Makefile* works when grep xxx */*/Makefile*. Is that because echo is a builtin command in csh (which is what I use)? I notice /bin/echo */*/Makefile* doesn't work. Is this documented somewhere? ___ 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: Thank you (for making the ports less boring).
On 09/12/2011 06:09 PM, Chad Perrin wrote:
On Mon, Sep 12, 2011 at 07:05:58PM -0400, Jerry wrote:
On Mon, 12 Sep 2011 23:55:56 +0200
Michal Varga articulated:
So again, thank you for taking your part in ensuring that my days with
FreeBSD (the remaining few, so to say) won't become too boring. It's
much appreciated, really.
Seriously now, I thought I was the only one allowed to criticize
FreeBSD for {Pick a topic}. You have to remember the motto:
I found Michal Varga's critique snarky and unnecessarily sarcastic...
I agree that it was unnecessarily sarcastic. We all make mistakes from
time to time. Michal could have pointed out the mistake and still been
nice about it. I know for myself that when I make a mistake like this
that I feel bad enough as it is, and I don't need anyone rubbing it in.
Stephen
___
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: HEADS UP --- Update to x11-toolkits/fltk coming
On 09/06/2011 04:18 AM, Pietro Cerutti wrote: Hi, you're receiving this email because one of your ports depends on x11-toolkits/fltk, according to $ grep fltk /usr/ports/INDEX-9 | cut -d '|' -f 6 | sort | uniq I'm preparing an update to fltk-1.3.0 and I would like to give you the chance to test your port against this new version. If no serious issues should raise in the next 15 days, I will commit the update (plus relative PORTREVISION bump on all dependent ports) on September 21st. It's going to be something in this direction: http://lists.freebsd.org/pipermail/cvs-ports/2010-March/191191.html Thank you for testing the patch available here: http://people.freebsd.org/~gahr/fltk-1.3.0.diff Kind Regards, The port graphics/qslim isn't building correctly with this new fltk. This is needed science/vis5d+. graphics/qslim has no maintainer. c++ -c -O2 -pipe -DMIX_ANSI_IOSTREAMS -fpermissive -fPIC -I/usr/local/include -DHAVE_BOOL -fno-strict-aliasing MxStdGUI.cxx MxStdGUI.cxx:18:32: error: FL/fl_file_chooser.H: No such file or directory In file included from MxAsp.h:17, from MxStdGUI.h:20, from MxStdGUI.cxx:14: MxDynBlock.h: In member function 'void MxDynBlockT::room_for(int)': MxDynBlock.h:38: warning: there are no arguments to 'resize' that depend on a template parameter, so a declaration of 'resize' must be available MxDynBlock.h: In member function 'typename MxBlockT::iterator MxDynBlockT::end()': MxDynBlock.h:65: warning: there are no arguments to 'begin' that depend on a template parameter, so a declaration of 'begin' must be available MxDynBlock.h: In member function 'typename MxBlockT::const_iterator MxDynBlockT::end() const': MxDynBlock.h:66: warning: there are no arguments to 'begin' that depend on a template parameter, so a declaration of 'begin' must be available In file included from MxSMF.h:22, from MxStdGUI.cxx:16: MxStack.h: In member function 'T MxStackT::top()': MxStack.h:29: warning: there are no arguments to 'last' that depend on a template parameter, so a declaration of 'last' must be available MxStack.h: In member function 'const T MxStackT::top() const': MxStack.h:30: warning: there are no arguments to 'last' that depend on a template parameter, so a declaration of 'last' must be available MxStack.h: In member function 'bool MxStackT::is_empty()': MxStack.h:32: warning: there are no arguments to 'length' that depend on a template parameter, so a declaration of 'length' must be available MxStack.h: In member function 'T MxStackT::pop()': MxStack.h:34: warning: there are no arguments to 'drop' that depend on a template parameter, so a declaration of 'drop' must be available MxStack.h: In member function 'void MxStackT::push()': MxStack.h:44: warning: there are no arguments to 'add' that depend on a template parameter, so a declaration of 'add' must be available MxStack.h:44: warning: there are no arguments to 'length' that depend on a template parameter, so a declaration of 'length' must be available MxStdGUI.cxx: In member function 'virtual void MxStdGUI::cmdline_file(const char*)': MxStdGUI.cxx:89: error: 'fl_file_chooser' was not declared in this scope gmake: *** [MxStdGUI.o] Error 1 *** Error code 1 Stop in /usr/ports/graphics/qslim. wilberforce# ___ 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: HEADS UP --- Update to x11-toolkits/fltk coming
On 09/06/2011 06:26 AM, Stephen Montgomery-Smith wrote: On 09/06/2011 04:18 AM, Pietro Cerutti wrote: Hi, you're receiving this email because one of your ports depends on x11-toolkits/fltk, according to $ grep fltk /usr/ports/INDEX-9 | cut -d '|' -f 6 | sort | uniq I'm preparing an update to fltk-1.3.0 and I would like to give you the chance to test your port against this new version. If no serious issues should raise in the next 15 days, I will commit the update (plus relative PORTREVISION bump on all dependent ports) on September 21st. It's going to be something in this direction: http://lists.freebsd.org/pipermail/cvs-ports/2010-March/191191.html Thank you for testing the patch available here: http://people.freebsd.org/~gahr/fltk-1.3.0.diff Kind Regards, The port graphics/qslim isn't building correctly with this new fltk. This patch seems to fix it. Even if it is garbled by the text processor/mail user, it should be obvious what it does - change the case of some letters in two occurrences of FL/Fl_File_Chooser.H diff -urN files-orig/patch-mixkit_src_MxStdGUI.cxx files/patch-mixkit_src_MxStdGUI.cxx --- files-orig/patch-mixkit_src_MxStdGUI.cxx1970-01-01 00:00:00.0 + +++ files/patch-mixkit_src_MxStdGUI.cxx 2011-09-06 12:20:44.0 + @@ -0,0 +1,11 @@ +--- mixkit/src/MxStdGUI.cxx-orig 2011-09-06 12:19:02.0 + mixkit/src/MxStdGUI.cxx2011-09-06 12:19:38.0 + +@@ -15,7 +15,7 @@ + #include MxGLUtils.h + #include MxSMF.h + #include FL/Fl_Color_Chooser.H +-#include FL/fl_file_chooser.H ++#include FL/Fl_File_Chooser.H + #include FL/filename.H + + diff -urN files-orig/patch-tools_qslim_qvis.cxx files/patch-tools_qslim_qvis.cxx --- files-orig/patch-tools_qslim_qvis.cxx 1970-01-01 00:00:00.0 + +++ files/patch-tools_qslim_qvis.cxx2011-09-06 12:21:26.0 + @@ -0,0 +1,11 @@ +--- tools/qslim/qvis.cxx-orig 2011-09-06 12:19:12.0 + tools/qslim/qvis.cxx 2011-09-06 12:20:06.0 + +@@ -14,7 +14,7 @@ + #include MxStdGUI.h + #include stdio.h + +-#include FL/fl_file_chooser.H ++#include FL/Fl_File_Chooser.H + #include FL/filename.H + #include FL/filename.H + #include FL/Fl_Slider.H diff -urN files-orig/patch-mixkit_src_MxStdGUI.cxx files/patch-mixkit_src_MxStdGUI.cxx --- files-orig/patch-mixkit_src_MxStdGUI.cxx1970-01-01 00:00:00.0 + +++ files/patch-mixkit_src_MxStdGUI.cxx 2011-09-06 12:20:44.0 + @@ -0,0 +1,11 @@ +--- mixkit/src/MxStdGUI.cxx-orig 2011-09-06 12:19:02.0 + mixkit/src/MxStdGUI.cxx2011-09-06 12:19:38.0 + +@@ -15,7 +15,7 @@ + #include MxGLUtils.h + #include MxSMF.h + #include FL/Fl_Color_Chooser.H +-#include FL/fl_file_chooser.H ++#include FL/Fl_File_Chooser.H + #include FL/filename.H + + diff -urN files-orig/patch-tools_qslim_qvis.cxx files/patch-tools_qslim_qvis.cxx --- files-orig/patch-tools_qslim_qvis.cxx 1970-01-01 00:00:00.0 + +++ files/patch-tools_qslim_qvis.cxx2011-09-06 12:21:26.0 + @@ -0,0 +1,11 @@ +--- tools/qslim/qvis.cxx-orig 2011-09-06 12:19:12.0 + tools/qslim/qvis.cxx 2011-09-06 12:20:06.0 + +@@ -14,7 +14,7 @@ + #include MxStdGUI.h + #include stdio.h + +-#include FL/fl_file_chooser.H ++#include FL/Fl_File_Chooser.H + #include FL/filename.H + #include FL/filename.H + #include FL/Fl_Slider.H ___ 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: HEADS UP --- Update to x11-toolkits/fltk coming
On 09/06/2011 07:32 AM, Pietro Cerutti wrote: On 2011-Sep-06, 07:28, Stephen Montgomery-Smith wrote: On 09/06/2011 06:26 AM, Stephen Montgomery-Smith wrote: On 09/06/2011 04:18 AM, Pietro Cerutti wrote: Hi, you're receiving this email because one of your ports depends on x11-toolkits/fltk, according to $ grep fltk /usr/ports/INDEX-9 | cut -d '|' -f 6 | sort | uniq I'm preparing an update to fltk-1.3.0 and I would like to give you the chance to test your port against this new version. If no serious issues should raise in the next 15 days, I will commit the update (plus relative PORTREVISION bump on all dependent ports) on September 21st. It's going to be something in this direction: http://lists.freebsd.org/pipermail/cvs-ports/2010-March/191191.html Thank you for testing the patch available here: http://people.freebsd.org/~gahr/fltk-1.3.0.diff Kind Regards, The port graphics/qslim isn't building correctly with this new fltk. This patch seems to fix it. Even if it is garbled by the text processor/mail user, it should be obvious what it does - change the case of some letters in two occurrences of FL/Fl_File_Chooser.H Yes, that is correct. Can you commit this change at the same time as you commit the fltk update? It will be easier for you to get the timing correct than it will for me. Also, gmsh and vis5d+ (other ports that I maintain) seemed to build just fine. octave also built just fine, but that's maho's port, so I will let him have the final word. Stephen ___ 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
Proposed changes to math/arpack
I would like to make some changes to math/arpack, so that math/arpack and math/lapack can be linked in the same binary. My proposed solution is a bit unusual, so I would like to solicit comments before I commit it. http://www.freebsd.org/cgi/query-pr.cgi?pr=159129 I assume that most of you have no interest in this, but there may be a few people out there who use this port, and I want to give them time to respond. ___ 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
portlint: DATADIR and NOEXAMPLEDOCS
I have a couple of questions.
1) Why does portlint complain if a port is not DATADIR compliant?
What was the rationale behind making ports DATADIR compliant, so that if
one types make install DATADIR=/somewhere_else then what would be
stored in /usr/local/share/port_name will now be in /somewhere_else.
If there are one hundred ports depending upon port x/y, and those ports
use the x/y DATADIR, then each of those hundred ports will have to include:
DATADIR!= cd ${.CURDIR}/../../x/y make -V DATADIR
This will really slow down makeindex.
It seems to me that you cannot use:
DATADIR=`cd ${.CURDIR}/../../x/y make -V DATADIR`
because this won't properly set PLIST_SUB.
2) Why does portlint NOT complain if a port is not NOPORTEXAMPLES
compliant?
This would seem a natural extension of portlint complaining if a port is
not NOPORTDOCS compliant.
Stephen
___
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: portlint: DATADIR and NOEXAMPLEDOCS
On 07/20/2011 07:31 PM, Joe Marcus Clarke wrote:
On 7/20/11 4:40 PM, Stephen Montgomery-Smith wrote:
I have a couple of questions.
1) Why does portlint complain if a port is not DATADIR compliant?
The warning is very conditional. It tries to provide information so one
can make an informed decision as to whether or not they want to be
DATADIR-safe.
What was the rationale behind making ports DATADIR compliant, so that if
one types make install DATADIR=/somewhere_else then what would be
stored in /usr/local/share/port_name will now be in /somewhere_else.
If there are one hundred ports depending upon port x/y, and those ports
use the x/y DATADIR, then each of those hundred ports will have to include:
DATADIR!=cd ${.CURDIR}/../../x/y make -V DATADIR
This doesn't make sense for all ports. That's why the warning is soft.
This will really slow down makeindex.
It seems to me that you cannot use:
DATADIR=`cd ${.CURDIR}/../../x/y make -V DATADIR`
because this won't properly set PLIST_SUB.
2) Why does portlint NOT complain if a port is not NOPORTEXAMPLES
compliant?
No one asked for it.
This would seem a natural extension of portlint complaining if a port is
not NOPORTDOCS compliant.
I agree. Patches welcome.
Thanks. Those are both good answers.
I'll look into a patch for NOPORTEXAMPLES, but the code is definitely
quite involved, and I can now see it will be a little bit more work than
monkey see - monkey do.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: science/paraview, french/aster require different hdf5 versions, install in the same place
On 07/19/2011 09:40 AM, Anton Shterenlikht wrote: I didn't get a reply from the maintainers, so post here. - Forwarded message from Anton Shterenlikhtme...@bristol.ac.uk - Date: Fri, 15 Jul 2011 09:13:26 +0100 From: Anton Shterenlikhtme...@bristol.ac.uk To: thie...@freebsd.org, de...@stasyan.com Subject: science/paraview, french/aster require different hdf5 versions, install in the same place I'm trying to build french/aster: ===fr-aster-10.3.0.3_2 depends on shared library: hdf5.6 - not found === Verifying install for hdf5.6 in /usr/ports/science/hdf5-18 === hdf5-1.8.6 conflicts with installed package(s): hdf5-1.6.9_1 They install files into the same place. You may want to stop build with Ctrl + C. % pkg_info -xR hdf Information for hdf5-1.6.9_1: Required by: paraview-3.10.0 I agree it is annoying that there are two versions of hdf5. What is the best way around this? Shall I try to rebuild paraview also with science/hdf5-18? That is what I would do. I have tried it with other programs, and it seemed to work. ___ 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/158179: some packages do not fully honor -P dir option in pkg_add(1)
On 07/19/2011 01:41 PM, Dieter BSD wrote: 1. Spell out very clearly its purpose - is it to populate a jail, for example? Populating a chroot/jail is one purpose. Another is to test a new version of a package without messing up the existing version. I don't see how these two goals are compatible. Any programs installed for the purpose of a chroot/jail will have to point to $PREFIX, whereas any programs installed for the purpose of testing it elsewhere will either have to point to $PREFIX (if the stuff it is pointing to was not installed by the current package and the -p option was invoked), or to $PKG_PREFIX (if the stuff it is pointing to was installed by the current package or the -P option was invoked). ___ 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/158179: some packages do not fully honor -P dir option in pkg_add(1)
current - ports On 07/16/2011 09:02 PM, Adrian Chadd wrote: Unless say, you're doing package installation outside of a chroot/jail, to populate something inside a chroot/jail before you start said chroot/jail. I can see -P and -p working for those many ports which just put programs in place. But there are some ports that include installation programs as part of the software. And some ports (like octave) which have a program which sometimes acts as an installation script, and sometimes acts as a user program. And sometimes those installation programs install for the port, and sometimes they install for a subport. If we are to continue using the -P and -p options, I suggest someone does the following: 1. Spell out very clearly its purpose - is it to populate a jail, for example? 2. Set up a computer that tests each package to see if it is -P compliant and -p compliant. By the way, each should be tested separately. For example, suppose latex-pgf is installed with the -p option. Then does it expect mktexlsr to be in the directory it is installing into, or the regular directory? mktexlsr is installed by a dependency, so the package needs to know where to find it. It would seem to me that you need a PKG_LOCALBASE variable as well as a PKG_PREFIX variable, so that the port knows where to find these installation programs. 3. Add a flag to ports that allow the port maintainer to mark the port -p non-compliant and -P non-compliant. The other possibility is to add to the man page of pkg_add saying that there is a good chance the -p and -P options don't work properly. Some people have clearly indicated that they like and use these options, so let's keep them happy too, and not delete it altogether. Stephen ___ 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/158179: some packages do not fully honor -P dir option in pkg_add(1)
Replacing current@ with ports@, just like Chris did.
On 07/16/2011 10:53 AM, Chris Rees wrote:
On 16 Jul 2011 16:38, Stephen Montgomery-Smith step...@missouri.edu
mailto:step...@missouri.edu wrote:
On 07/16/2011 04:26 AM, Stefan Bethke wrote:
Am 16.07.2011 um 04:43 schrieb Stephen Montgomery-Smith:
I was looking through the source code of pkg_add. Personally I
don't see how the -P or -p option could be made to work with
pkg_add. Many of the installation commands involve scripts which have
${PREFIX} hard coded into them. ${PREFIX} is often hard coded when trhe
package is created by the port. In my opinion, the options -p and
-P should be removed from pkg_add.
Either that, or provide the port a way to access @cwd in any
scripts it installs. But this would require a major overhaul of the
whole ports system, and probably much of the software it installs as well.
Am I missing something?
Yes. Not honoring the prefix is a bug in the port. If you do need
to do prefix-specific things during install, use pkg-install, see
http://www.freebsd.org/doc/en/books/porters-handbook/pkg-install.html
I suspect that many ports are not well tested outside of
/usr/local, but the infrastructure is there and available.
You are correct, this needs to be done on a port by port basis. In
some ports this is going to be a big job, because in some cases the
/usr/local is hard coded into certain binaries.
For example, suppose the C source code contains something like:
char applications_dir = /usr/local/share/applications;
and this is filled in by the ./configure script.
How is that handled?
It's not.
Remember what a package is, literally the files from the plist tarred
with some magic +FILEs and the pkg-*install files- if paths are
hardcoded in objects that's how it'll be installed.
What if some of the installation programs are binaries, and /usr/local
is hard coded into installation binaries or scripts provided by the
software itself.
Don't touch the -p option! It's only useful for um someone help
here?
I am thinking the same thing!
___
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/158179: some packages do not fully honor -P dir option in pkg_add(1)
current@ to ports@ again. (Sorry, my mistake.) On 07/16/2011 11:10 AM, Chris Rees wrote: On 16 Jul 2011 17:04, Stephen Montgomery-Smith step...@missouri.edu mailto:step...@missouri.edu wrote: On 07/16/2011 10:53 AM, Chris Rees wrote: On 16 Jul 2011 16:38, Stephen Montgomery-Smith step...@missouri.edu mailto:step...@missouri.edu mailto:step...@missouri.edu mailto:step...@missouri.edu wrote: For example, suppose the C source code contains something like: char applications_dir = /usr/local/share/applications; and this is filled in by the ./configure script. How is that handled? It's not. Remember what a package is, literally the files from the plist tarred with some magic +FILEs and the pkg-*install files- if paths are hardcoded in objects that's how it'll be installed. What if some of the installation programs are binaries, and /usr/local is hard coded into installation binaries or scripts provided by the software itself. Sorry, poor wording on my part. No, I didn't read what you said properly. If it was compiled as prefix=/usr/local, that's how it'll be installed, regardless of your -p argument. So -p and -P are inherently buggy, and should be removed from pkg_add? (Or every port which uses prefix=/usr/local needs major revision and patching, which I think is an intolerable workload.) ___ 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
math/bamg
Does anyone want to take the math/bamg port? Or at least tell me that they use it? It is now at version 1.0.0, and the current version's master site has disappeared. Also, it seems to be part of freefem++, and that port has disappeared from the FreeBSD ports. If no-one responds I will set it to broken, deprecate it, and give it to po...@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
Re: [RFC] A trivial change for DESKTOP_ENTRIES (take 2)
On 07/15/2011 04:57 PM, Warren Block wrote: FWIW, I think the original code with a better regex like Jung-uk Kim has in http://lists.freebsd.org/pipermail/freebsd-ports/2011-July/068737.html is still the way to go. If the port requires a special desktop entry filename, that seems beyond the scope of the DESKTOP_ENTRIES variable. I agree. DESKTOP_ENTRIESv2 seems like a lot of work for just three ports. ___ 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/144597: security/openssh-portable fails to compile with KERBEROS enabled
On 07/15/2011 06:28 PM, Stephen Montgomery-Smith wrote: On 07/15/2011 06:23 PM, Jason Hellenthal wrote: On Wed, Jul 13, 2011 at 11:39:01PM -0500, Stephen Montgomery-Smith wrote: Hey people, I was looking over old unresolved PR's. I came across this one: http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/144597 When I sent a message to the submitter of the PR, the email bounced back suggesting that the submitter no longer uses that email address. I don't think it would be too hard to make the port build under the circumstances he describes. But is ANYONE interested? Would it be worth investing effort to make this work? Note that the port has ports@ as its maintainer, so it doesn't look like there is a lot of interest. Thanks, Stephen P.S. This one is related: http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/57498 Is this a big bag of worms? I can see that seems to be fixed, for example, in mail/fetchmail. Considering that the port version is 5.2p1 and the current version in stable/8 is 5.4p1 and greater than that for HEAD I would say it would be much more of a benefit to get the port updated to the latest version and then work on it from there, otherwise its a loss of time for an outdated version. Last time I looked at this port it was a mess with a collection of third party patches from all over the place which I think lead to a discrepancy in the update of the port but that's just my opinion. It would be nice to see a simplified version of this port so it isn't such a monster to update and have an option for a user supplied patches directory that stands outside of the tree (user configured path) and it just blindly attempts to apply what is in that directory. I think this would help slim it down a little so it can consistently be bumped to a new revision without hassle. Something like: # Defaults to /usr/ports/patches unless path is user specified. WITH_PATCH_TREE?=/usr/ports/patches /usr/ports/patches/ # Distributed empty. everything else user created. |-- net | `-- wireshark `-- security |-- gnupg `-- openssh-portable Things like this would certainly make it easier for a consistent user supplied patch to be kept local for build machines. I can't count the times on 2 hands and 2 feet that I wanted to patch a port with a local patch and had to continuously cp(1) a patch back to a ports tree using rsync(1) All these are good ideas, but I am not the person to do it. I don't use this software. I'm going to relinquish responsibility for this PR. I found some possible maintainers of this port at http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/150493. If either of them reply, then I'll pick it up again. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: [RFC] A trivial change for DESKTOP_ENTRIES (take 2)
Pav Lucistnik wrote: On 2011/07/14 00:57, Jung-uk Kim wrote: links.diff, metalink-editor.diff, tome.diff: - Add static desktop files to work around DESKTOP_ENTRIES limitations. This is a step backwards and I'll oppose it. I am beginning to get a clearer picture of what is going on. This desktop_entries stuff is all rather new to me, and I think that yesterday I wasn't understanding it. So entry 4 in Desktop Entries serves two purposes. First, it tells us what program we are running, complete with path names and flags if needed. Secondly, it is used to generate the filename of the desktop entry. I assume that the filename of the desktop entry is unimportant, and is used only internally by Gnome or whatever. But what is important is that the name of the filename stays the SAME. So if I deinstall some software, and then reinstall, and then the filename of the desktop entry changes, then suddenly there is the potential for stuff to stop working. And this not working will typically be at the user level, not the system administrator level. And Joe Average user who doesn't actually install the ports shouldn't be expected to read UPDATING. So one fix would be to keep everything in bsd.port.mk as it is, and just change the instructions in pkg-message in x11-wm/compix to use compizmanager instead of compiz-manager. But maybe it would have been better to have had one more entry in DESKTOP_ENTRIES that was the actual filename of the desktop entry. But I can also see why people didn't do that, because it would be opaque to the users. But using the program name for the filename didn't work, because of the possibility of spaces and slashes and ... So Pavel had to change it to remove spaces and such like. But this had the unintended consequence that users would find their desktop icons suddenly not working. And now the filename for the desktop entry is inconsistent across different computers, depending upon whether people installed the ports before or after the change to bsd.port.mk. So Jung-uk Kim's scheme of partially reversing Pavel's changes will create more havoc for some people, and less for others. And my initial complaint that bsd.port.mk was changing names without telling me was based on my not understanding what all this desktop entry stuff was all about. Sorry for the long ramble. Am I understanding this correctly? ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: [RFC] A trivial change for DESKTOP_ENTRIES (take 2)
On 07/14/2011 12:47 PM, Jung-uk Kim wrote:
Anyhow, I guess we can do it much simpler:
--- Mk/bsd.port.mk 3 Jul 2011 15:51:18 - 1.687
+++ Mk/bsd.port.mk 14 Jul 2011 17:26:43 -
@@ -6432,7 +6432,7 @@
${ECHO_CMD} @cwd ${DESKTOPDIR} ${TMPPLIST}; \
fi; \
while [ $$# -gt 6 ]; do \
- filename=`${ECHO_CMD} $$4 | ${TR} -cd [:alnum:]`.desktop; \
+ filename=`${BASENAME} $$4 | ${SED} -E
's/[[:space:]]+.*//'`.desktop; \
pathname=${DESKTOPDIR}/$$filename; \
categories=$$5; \
if [ -z $$categories ]; then \
I think this is much simpler and better fix.
Jung-uk Kim
I agree.
What about dots at the beginning of the filename?
${SED} -E 's/[[:space:]]+.*//' -E 's/^\.+//'
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: [RFC] A trivial change for DESKTOP_ENTRIES (take 2)
On 07/14/2011 12:54 PM, Pav Lucistnik wrote: Stephen Montgomery-Smith píše v čt 14. 07. 2011 v 11:57 -0500: entry. I assume that the filename of the desktop entry is unimportant, The filename of desktop entry should be 100% inconsequential, and our only care should be not have two ports installing same file. and is used only internally by Gnome or whatever. Sounds like a bug to me. This means I am still not understanding it fully then. But maybe it would have been better to have had one more entry in DESKTOP_ENTRIES that was the actual filename of the desktop entry. Yes, but is it worth the effort? Note you'll have to introduce it somehow not to break existing ports. I agree. It is a lot of work. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: [RFC] A trivial change for DESKTOP_ENTRIES (take 2)
On 07/14/2011 02:29 PM, Chris Rees wrote: On 14 Jul 2011 17:58, Stephen Montgomery-Smith step...@missouri.edu mailto:step...@missouri.edu wrote: Joe Average user who doesn't actually install the ports shouldn't be expected to read UPDATING. Er... he really should and is expected to. The situation I am thinking of is where a group all use FreeBSD. One person is responsible for installation and upkeep of the computers, and everyone else just uses them (for example, they don't have root access). An example of this is the University of Missouri Math Dept about 10 years ago. We all used FreeBSD. Now being Mathematicians, most of us didn't have a clue about how it all worked inside. Most of us wouldn't even understand what the UPDATING entries mean. Since then, most of the Dept have moved to Windows or the Mac. I am one of the few who still uses FreeBSD. So maybe you are correct after all - only use FreeBSD if you are a power user. Stephen ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: [RFC] A trivial change for DESKTOP_ENTRIES
On 07/13/2011 10:41 AM, Jung-uk Kim wrote: On Wednesday 13 July 2011 07:39 am, Pav Lucistnik wrote: On 2011/07/13 00:25, Jung-uk Kim wrote: After I updated x11-wm/compiz, GNOME was not able to start the window manager. Basically, it complained that compiz-manager was not found. Then, I realized compiz-manager.desktop was automagically replaced by compizmanager.desktop. Now I tracked it down to this commit: Sat Nov 27 17:42:46 2010 UTC (7 months, 2 weeks ago) by pav - DESKTOP_ENTRIES: commandline is used to name installed .desktop file, this can lead to files containing whitespace and funny characters; thus strip all non-alphanumeric characters http://www.freebsd.org/cgi/cvsweb.cgi/ports/Mk/bsd.port.mk.diff?r 1=1.656;r2=1.657 To me, it looks far too restrictive. At least, I'd like to allow '-' and '_'. Please see the attached patch. Any objections? Shouldn't you fix whatever is trying to call compizmanager not to use .desktop file instead? GNOME session manager calls the compiz-manager, i.e., the user has to change it manually. Actually, x11-wm/compiz/pkg-message recommended this: If you are using gnome, you can use the configuration editor to set the value of: desktop-gnome-session-required_components-windowmanager = compiz-manager ^^ This will enable compiz as your default window manager. I am quite sure there are similar instructions on the net. Jung-uk Kim Also, bsd.ports.mk shouldn't change what the port tells it to do, without informing anybody. I'm sure it took Jung-uk Kim many hours to figure out why it wasn't working. Other users are going to be in a similar spot. Many users will never figure it out. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: [RFC] A trivial change for DESKTOP_ENTRIES
On 07/13/2011 11:42 AM, Jung-uk Kim wrote:
On Wednesday 13 July 2011 12:08 am, Stephen Montgomery-Smith wrote:
On 07/12/2011 05:25 PM, Jung-uk Kim wrote:
After I updated x11-wm/compiz, GNOME was not able to start the
window manager. Basically, it complained that compiz-manager was
not found. Then, I realized compiz-manager.desktop was
automagically replaced by compizmanager.desktop. Now I tracked
it down to this commit:
Sat Nov 27 17:42:46 2010 UTC (7 months, 2 weeks ago) by pav
- DESKTOP_ENTRIES: commandline is used to name installed .desktop
file, this can lead to files containing whitespace and funny
characters; thus strip all non-alphanumeric characters
http://www.freebsd.org/cgi/cvsweb.cgi/ports/Mk/bsd.port.mk.diff?r
1=1.656;r2=1.657
To me, it looks far too restrictive. At least, I'd like to allow
'-' and '_'. Please see the attached patch.
Any objections?
Jung-uk Kim
Thinking more about it, it seems to me that instead of silently
deleting the disallowed characters in the filename, that the port
should declare itself broken if there are disallowed characters.
That way, this particular error would have been caught far more
easily.
I think that's a good idea but exit 1; should be done in a separate
commit as an exp-run is needed.
Here is a simple patch, although I think you guys could come up
with a better error message.
:-)
entry 4 of seems redundant. What do you think about the attached
patch? Please note I also added . per Matthias Andree's request.
Thanks,
Jung-uk Kim
I have no problems with your changes. But I didn't see where you put
the .. Maybe it was meant to be at the end of the error message.
But code like this seems simpler than my original suggestion:
if (echo $$4 | grep -E [^[:alnum:]_-] /dev/null); then echo \
${ECHO_MSG} blah blah.; \
exit 1; \
fi; \
pathname=${DESKTOPDIR}/$$4;
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: [RFC] A trivial change for DESKTOP_ENTRIES
On 07/13/2011 11:59 AM, Stephen Montgomery-Smith wrote:
On 07/13/2011 11:42 AM, Jung-uk Kim wrote:
On Wednesday 13 July 2011 12:08 am, Stephen Montgomery-Smith wrote:
On 07/12/2011 05:25 PM, Jung-uk Kim wrote:
After I updated x11-wm/compiz, GNOME was not able to start the
window manager. Basically, it complained that compiz-manager was
not found. Then, I realized compiz-manager.desktop was
automagically replaced by compizmanager.desktop. Now I tracked
it down to this commit:
Sat Nov 27 17:42:46 2010 UTC (7 months, 2 weeks ago) by pav
- DESKTOP_ENTRIES: commandline is used to name installed .desktop
file, this can lead to files containing whitespace and funny
characters; thus strip all non-alphanumeric characters
http://www.freebsd.org/cgi/cvsweb.cgi/ports/Mk/bsd.port.mk.diff?r
1=1.656;r2=1.657
To me, it looks far too restrictive. At least, I'd like to allow
'-' and '_'. Please see the attached patch.
Any objections?
Jung-uk Kim
Thinking more about it, it seems to me that instead of silently
deleting the disallowed characters in the filename, that the port
should declare itself broken if there are disallowed characters.
That way, this particular error would have been caught far more
easily.
I think that's a good idea but exit 1; should be done in a separate
commit as an exp-run is needed.
Here is a simple patch, although I think you guys could come up
with a better error message.
:-)
entry 4 of seems redundant. What do you think about the attached
patch? Please note I also added . per Matthias Andree's request.
Thanks,
Jung-uk Kim
I have no problems with your changes. But I didn't see where you put
the .. Maybe it was meant to be at the end of the error message.
But code like this seems simpler than my original suggestion:
if (echo $$4 | grep -E [^[:alnum:]_-] /dev/null); then echo \
${ECHO_MSG} blah blah.; \
exit 1; \
fi; \
pathname=${DESKTOPDIR}/$$4;
Oh, and use ${GREP} and ${ECHO_CMD} instead of echo and grep. And maybe
the -E is unnecessary.
___
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
