FreeBSD ports you maintain which are out of date
Dear port maintainer, The portscout new distfile checker has detected that one or more of your ports appears to be out of date. Please take the opportunity to check each of the ports listed below, and if possible and appropriate, submit/commit an update. If any ports have already been updated, you can safely ignore the entry. You will not be e-mailed again for any of the port/version combinations below. Full details can be found at the following URL: http://portscout.freebsd.org/po...@freebsd.org.html Port| Current version | New version +-+ multimedia/py-tvnamer | 2.2 | 2.3 +-+ If any of the above results are invalid, please check the following page for details on how to improve portscout's detection and selection of distfiles on a per-port basis: http://portscout.freebsd.org/info/portscout-portconfig.txt Thanks. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
portupgrade -aF hanging under cron on FreeBSD 10 with pkgng
For a few years I've used a very simple cron to update my ports. Every morning I get a friendly mail with the outcome. /etc/crontab: 15 4 * * * root/home/root/cvsup_update /home/root/cvsup_update: #!/bin/sh /bin/date cd /usr/ports sudo -u cvsupin svnsync sync file:///home/freebsd-svn/base sudo -u cvsupin svnsync sync file:///home/freebsd-svn/ports sudo -u cvsupin svnsync sync file:///home/freebsd-svn/doc svn up /usr/local/sbin/portsdb -uU /usr/local/sbin/portupgrade -a -F /usr/local/sbin/portversion -v | grep -v up-to-date /bin/date Since upgrading to FreeBSD 10 and migrating to pkgng (at the same time), I noticed the mails stopped. Upon investigating the script is hanging at portupgrade -a -F when some ports need updating. Using kill a couple of times to free up the job, I eventually get the following mail: see: http://www.knigma.org/scratch/home_root_cvsup_update_cronmail.txt Before killing the job to get the mail I ran ps, here are the relevant processes after the job had been stuck for several hours: USER PID PPID PGID SID JOBC STAT TTTIME COMMAND root 62559 1530 1530 15300 I - 0:00.01 cron: running job (cron) root 62562 62559 62562 625620 IWs - 0:00.00 /bin/sh /home/root/cvsup_update root 84862 62562 62562 625620 I - 0:03.24 ruby19: portupgrade: [1/4] png-1.5.17 (ruby19) root 98047 84862 62562 625620 I - 0:00.02 /usr/bin/script -qa /tmp/portupgrade20140215-84862-ayw6np env UPGRADE_TOOL=portupgrade UPGRADE_PORT=png-1.5.17 UPGRADE_PORT_VER=1.5.17 make FETCH_BEFORE_ARGS=-q -DBATCH checksum root 98048 98047 98048 980480 IEs+ 1-0:00.01 make FETCH_BEFORE_ARGS=-q -DBATCH checksum If I run portupgrade -a -F at the shell prompt everything is fine - but this helps to illustrate where the cron is misbehaving. mkn@shrewd$ sudo portupgrade -a -F [Reading data from pkg(8) ... - 854 packages found - done] --- Fetching the distfile(s) for 'png-1.5.18' (graphics/png) --- Fetching '/usr/ports/graphics/png' === Found saved configuration for png-1.5.12 === png-1.5.18 depends on file: /usr/local/sbin/pkg - found === Fetching all distfiles required by png-1.5.18 for building = SHA256 Checksum OK for libpng-1.5.18.tar.xz. = SHA256 Checksum OK for libpng-1.5.18-apng.patch.gz. --- Fetching the distfile(s) for 'p5-CPAN-Meta-YAML-0.011' (devel/p5-CPAN-Meta-YAML) --- Fetching '/usr/ports/devel/p5-CPAN-Meta-YAML' === License ART10 GPLv1 accepted by the user === p5-CPAN-Meta-YAML-0.011 depends on file: /usr/local/sbin/pkg - found === Fetching all distfiles required by p5-CPAN-Meta-YAML-0.011 for building = SHA256 Checksum OK for CPAN-Meta-YAML-0.011.tar.gz. --- Fetching the distfile(s) for 'libfpx-1.3.1.4' (graphics/libfpx) --- Fetching '/usr/ports/graphics/libfpx' === libfpx-1.3.1.4 depends on file: /usr/local/sbin/pkg - found === Fetching all distfiles required by libfpx-1.3.1.4 for building = SHA256 Checksum OK for libfpx-1.3.1-4.tar.xz. --- Fetching the distfile(s) for 'dejavu-2.34_2' (x11-fonts/dejavu) --- Fetching '/usr/ports/x11-fonts/dejavu' === Found saved configuration for dejavu-2.33 === dejavu-2.34_2 depends on file: /usr/local/sbin/pkg - found === Fetching all distfiles required by dejavu-2.34_2 for building = SHA256 Checksum OK for dejavu-fonts-ttf-2.34.tar.bz2. mkn@shrewd$ I'd appreciate any thoughts on why this is getting stuck please? Thanks! -- Mark Knight Mobile: +44 7753 250584. http://www.knigma.org/ Email: ma...@knigma.org. Skype: knigma ___ 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
print/libharu does not build after update to 2.3.0
Unfortunately print/libharu does not build anymore after the update to 2.3.0 (r344246). This happens on HEAD r261806 amd64 with clang. Any help is really appreciated. Thanks in advance, Rainer Hurling #make === Found saved configuration for libharu-2.3.0 === libharu-2.3.0 depends on file: /usr/local/sbin/pkg - found === Fetching all distfiles required by libharu-2.3.0 for building === Extracting for libharu-2.3.0 = SHA256 Checksum OK for libharu-2.3.0.tar.gz. === Patching for libharu-2.3.0 === Applying FreeBSD patches for libharu-2.3.0 === libharu-2.3.0 depends on file: /usr/local/bin/cmake - found === libharu-2.3.0 depends on shared library: libpng15.so - found === Configuring for libharu-2.3.0 === Performing out-of-source build /bin/mkdir -p /usr/ports/print/libharu/work/.build -- The C compiler identification is Clang 3.3.0 -- Check for working C compiler: /usr/bin/cc -- Check for working C compiler: /usr/bin/cc -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- DevPackage only available for Win32. Set DEVPAK to OFF. -- Looking for include file dlfcn.h -- Looking for include file dlfcn.h - found -- Looking for include file inttypes.h -- Looking for include file inttypes.h - found -- Looking for include file memory.h -- Looking for include file memory.h - found -- Looking for include file stdint.h -- Looking for include file stdint.h - found -- Looking for include file stdlib.h -- Looking for include file stdlib.h - found -- Looking for include file strings.h -- Looking for include file strings.h - found -- Looking for include file string.h -- Looking for include file string.h - found -- Looking for include file sys/stat.h -- Looking for include file sys/stat.h - found -- Looking for include file sys/types.h -- Looking for include file sys/types.h - found -- Looking for include file unistd.h -- Looking for include file unistd.h - found -- Found ZLIB: /usr/lib/libz.so (found version 1.2.8) -- Found PNG: /usr/local/lib/libpng.so (found version 1.5.18) Summary of CMake build system results for the haru library Install location variables which can be set by the user: CMAKE_INSTALL_PREFIX: /usr/local CMAKE_INSTALL_EXEC_PREFIX CMAKE_INSTALL_BINDIR CMAKE_INSTALL_LIBDIR CMAKE_INSTALL_INCLUDEDIR Other important CMake variables: CMAKE_SYSTEM_NAME: FreeBSD UNIX: 1 WIN32: APPLE: MSVC: (MSVC_VERSION: ) MINGW: MSYS: CYGWIN: BORLAND: WATCOM: CMAKE_BUILD_TYPE: Release CMAKE_C_COMPILER CMAKE_C_FLAGS: /usr/bin/cc -O2 -pipe -fno-strict-aliasing Library options: LIBHPDF_SHARED: ON LIBHPDF_STATIC: ON LIBHPDF_EXAMPLES: ON DEVPAK: OFF Optional libraries: HAVE_LIBZ: TRUE HAVE_LIBPNG:TRUE -- Configuring done -- Generating done CMake Warning: Manually-specified variables were not used by the project: CMAKE_CXX_COMPILER CMAKE_CXX_FLAGS CMAKE_CXX_FLAGS_DEBUG CMAKE_CXX_FLAGS_RELEASE CMAKE_C_FLAGS_DEBUG CMAKE_MODULE_LINKER_FLAGS THREADS_HAVE_PTHREAD_ARG -- Build files have been written to: /usr/ports/print/libharu/work/.build === Building for libharu-2.3.0 Scanning dependencies of target hpdf Scanning dependencies of target hpdfs [ 1%] Building C object src/CMakeFiles/hpdf.dir/hpdf_binary.o [ 0%] Building C object src/CMakeFiles/hpdf.dir/hpdf_boolean.o [ 4%] Building C object src/CMakeFiles/hpdfs.dir/hpdf_annotation.o [ 4%] Building C object src/CMakeFiles/hpdf.dir/hpdf_catalog.o [ 5%] Building C object src/CMakeFiles/hpdf.dir/hpdf_array.o [ 4%] Building C object src/CMakeFiles/hpdf.dir/hpdf_annotation.o /usr/ports/print/libharu/work/libharu-libharu-7f4bb51/src/hpdf_annotation.c:235:46: error: use of undeclared identifier 'HPDF_ANNOT_WIDGET'; did you mean 'HPDF_ANNOT_HIDDEN'? annot = HPDF_Annotation_New (mmgr, xref, HPDF_ANNOT_WIDGET, rect); ^ HPDF_ANNOT_HIDDEN /usr/local/include/hpdf_types.h:366:5: note: 'HPDF_ANNOT_HIDDEN' declared here HPDF_ANNOT_HIDDEN, ^ /usr/ports/print/libharu/work/libharu-libharu-7f4bb51/src/hpdf_annotation.c:235:46: warning: implicit conversion from enumeration type 'enum _HPDF_AnnotFlgs' to different enumeration type 'HPDF_AnnotType' (aka 'enum _HPDF_AnnotType') [-Wenum-conversion] annot = HPDF_Annotation_New (mmgr, xref, HPDF_ANNOT_WIDGET, rect); ~~~ ^ [ 6%] Building C object src/CMakeFiles/hpdf.dir/hpdf_destination.o /usr/ports/print/libharu/work/libharu-libharu-7f4bb51/src/hpdf_annotation.c:235:46: error: use of undeclared identifier 'HPDF_ANNOT_WIDGET'; did you mean 'HPDF_ANNOT_HIDDEN'? annot = HPDF_Annotation_New (mmgr, xref, HPDF_ANNOT_WIDGET, rect);
Re: 'pkg version -I index' ignores index argument
On Fri, 14 Feb 2014, 07:30 +1100, John Marshall wrote: Prompted by the recent EOL announcement and the very loud pkg_install warning, I recently migrated about a dozen systems to pkgng. So far the only thing I've tripped over is the pkg-version(8) tool ignoring its index argument. The tool appears to do a good job of maintaining backwards compatibility with its venerable predecessor: usage: pkg_version [-hIoqv] [-l limchar] [-L limchar] [[-X] -s string] [-O origin] [index] pkg_version -t v1 v2 pkg_version -T name pattern Usage: pkg version [-IPR] [-hoqvU] [-l limchar] [-L limchar] [-egix pattern] [-r reponame] [-O origin] [index] pkg version -t version1 version2 pkg version -T pkgname pattern but the new tool completely ignores its optional [index] argument and, if I request use of an INDEX via -I, it will only work if there is an INDEX file in the ports tree directory. A missing ports tree directory is also a fatal error. I have submitted a PR (ports/186671) in which I provide a patch to pkg/version.c to rectify this problem. The patch: - removes the requirement for /usr/ports when using an index (-I) - reads and uses the optional index file argument which, if present, will supersede the default file in /usr/ports. That worked fine with the '-I' option. I discovered, after the Friday night periodic weekly jobs had run, that the new weekly 400.status-pkg job didn't give me the expected result. It turns out that this job passes the index file argument without setting -I. The original pkg_install version of this weekly periodic job does the same thing but it would use the index in the absence of a ports tree. I checked the old pkg_version code and saw that it uses the index argument (with no -I option) as a fallback if it cannot find a ports tree. I have updated the PR (ports/186671) with a new patch for pkg/version.c to restore this functionality. With the new patch, the version source selection precedence, if not overridden by any of (-IPR), is as follows: - use ports tree if present - fall back to index if index argument is present and file readable - fall back to remote repository -- John Marshall pgplgOzUvXYKt.pgp Description: PGP signature
Re: multimedia/tvheadend fails under FreeBSD 9.2-stable
Hello, Thanks for working on this - much appreciated! On Tue, Feb 11, 2014 at 9:00 AM, Bernhard Fröhlich de...@bluelife.at wrote: Well I'm a bit pissed now because wg@ has broken the port [1] but in such a way that I didn't notice it up to now. He has changed the dependency from ffmpeg1 to ffmpeg and removed the configure checks which cannot work because ffmpeg does not compile with ffmpeg 2.x. Since he has also removed ffmpeg1 I don't see a chance how to fix it unless I feel brave enough to bring back ffmpeg1 or add support for ffmpeg 2.x to tvheadend. Both seems unrealistic to me right now so I had to remove the FFMPEG option in the port and the dependency to ffmpeg completely and disable libav to ensure that it doesn't try to use an installed ffmpeg 2.x. So this is the situation right now in 3.4.0.20130726.3_5 and it should build fine but you loose all the functionality that requires libav. Updated to latest ports, which got me tvheadend installed. I'm not sure what all the functionality that requires libav includes, so let me ask this way: - will / should DVB-C devices (via webcamd) work even without libav? - will CSA / cwc work even without libav? -- Regards, Torfinn Ingolfsen ___ 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: print/libharu does not build after update to 2.3.0
On 2014-Feb-15, 11:23, Rainer Hurling wrote: Unfortunately print/libharu does not build anymore after the update to 2.3.0 (r344246). This happens on HEAD r261806 amd64 with clang. Uhm, it seems to be related to the previous installation. Can you deinstall the currently installed version before building the new one? I'll look at a proper fix on monday! Thanks! Any help is really appreciated. Thanks in advance, Rainer Hurling #make === Found saved configuration for libharu-2.3.0 === libharu-2.3.0 depends on file: /usr/local/sbin/pkg - found === Fetching all distfiles required by libharu-2.3.0 for building === Extracting for libharu-2.3.0 = SHA256 Checksum OK for libharu-2.3.0.tar.gz. === Patching for libharu-2.3.0 === Applying FreeBSD patches for libharu-2.3.0 === libharu-2.3.0 depends on file: /usr/local/bin/cmake - found === libharu-2.3.0 depends on shared library: libpng15.so - found === Configuring for libharu-2.3.0 === Performing out-of-source build /bin/mkdir -p /usr/ports/print/libharu/work/.build -- The C compiler identification is Clang 3.3.0 -- Check for working C compiler: /usr/bin/cc -- Check for working C compiler: /usr/bin/cc -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- DevPackage only available for Win32. Set DEVPAK to OFF. -- Looking for include file dlfcn.h -- Looking for include file dlfcn.h - found -- Looking for include file inttypes.h -- Looking for include file inttypes.h - found -- Looking for include file memory.h -- Looking for include file memory.h - found -- Looking for include file stdint.h -- Looking for include file stdint.h - found -- Looking for include file stdlib.h -- Looking for include file stdlib.h - found -- Looking for include file strings.h -- Looking for include file strings.h - found -- Looking for include file string.h -- Looking for include file string.h - found -- Looking for include file sys/stat.h -- Looking for include file sys/stat.h - found -- Looking for include file sys/types.h -- Looking for include file sys/types.h - found -- Looking for include file unistd.h -- Looking for include file unistd.h - found -- Found ZLIB: /usr/lib/libz.so (found version 1.2.8) -- Found PNG: /usr/local/lib/libpng.so (found version 1.5.18) Summary of CMake build system results for the haru library Install location variables which can be set by the user: CMAKE_INSTALL_PREFIX: /usr/local CMAKE_INSTALL_EXEC_PREFIX CMAKE_INSTALL_BINDIR CMAKE_INSTALL_LIBDIR CMAKE_INSTALL_INCLUDEDIR Other important CMake variables: CMAKE_SYSTEM_NAME:FreeBSD UNIX: 1 WIN32: APPLE: MSVC: (MSVC_VERSION: ) MINGW: MSYS: CYGWIN: BORLAND: WATCOM: CMAKE_BUILD_TYPE: Release CMAKE_C_COMPILER CMAKE_C_FLAGS: /usr/bin/cc -O2 -pipe -fno-strict-aliasing Library options: LIBHPDF_SHARED: ON LIBHPDF_STATIC: ON LIBHPDF_EXAMPLES: ON DEVPAK: OFF Optional libraries: HAVE_LIBZ:TRUE HAVE_LIBPNG: TRUE -- Configuring done -- Generating done CMake Warning: Manually-specified variables were not used by the project: CMAKE_CXX_COMPILER CMAKE_CXX_FLAGS CMAKE_CXX_FLAGS_DEBUG CMAKE_CXX_FLAGS_RELEASE CMAKE_C_FLAGS_DEBUG CMAKE_MODULE_LINKER_FLAGS THREADS_HAVE_PTHREAD_ARG -- Build files have been written to: /usr/ports/print/libharu/work/.build === Building for libharu-2.3.0 Scanning dependencies of target hpdf Scanning dependencies of target hpdfs [ 1%] Building C object src/CMakeFiles/hpdf.dir/hpdf_binary.o [ 0%] Building C object src/CMakeFiles/hpdf.dir/hpdf_boolean.o [ 4%] Building C object src/CMakeFiles/hpdfs.dir/hpdf_annotation.o [ 4%] Building C object src/CMakeFiles/hpdf.dir/hpdf_catalog.o [ 5%] Building C object src/CMakeFiles/hpdf.dir/hpdf_array.o [ 4%] Building C object src/CMakeFiles/hpdf.dir/hpdf_annotation.o /usr/ports/print/libharu/work/libharu-libharu-7f4bb51/src/hpdf_annotation.c:235:46: error: use of undeclared identifier 'HPDF_ANNOT_WIDGET'; did you mean 'HPDF_ANNOT_HIDDEN'? annot = HPDF_Annotation_New (mmgr, xref, HPDF_ANNOT_WIDGET, rect); ^ HPDF_ANNOT_HIDDEN /usr/local/include/hpdf_types.h:366:5: note: 'HPDF_ANNOT_HIDDEN' declared here HPDF_ANNOT_HIDDEN, ^ /usr/ports/print/libharu/work/libharu-libharu-7f4bb51/src/hpdf_annotation.c:235:46: warning: implicit conversion from enumeration type 'enum _HPDF_AnnotFlgs' to different enumeration type 'HPDF_AnnotType' (aka 'enum _HPDF_AnnotType') [-Wenum-conversion] annot = HPDF_Annotation_New (mmgr, xref, HPDF_ANNOT_WIDGET, rect);
Re: multimedia/tvheadend fails under FreeBSD 9.2-stable
Am 15.02.2014 12:13 schrieb Torfinn Ingolfsen tin...@gmail.com: Hello, Thanks for working on this - much appreciated! On Tue, Feb 11, 2014 at 9:00 AM, Bernhard Fröhlich de...@bluelife.at wrote: Well I'm a bit pissed now because wg@ has broken the port [1] but in such a way that I didn't notice it up to now. He has changed the dependency from ffmpeg1 to ffmpeg and removed the configure checks which cannot work because ffmpeg does not compile with ffmpeg 2.x. Since he has also removed ffmpeg1 I don't see a chance how to fix it unless I feel brave enough to bring back ffmpeg1 or add support for ffmpeg 2.x to tvheadend. Both seems unrealistic to me right now so I had to remove the FFMPEG option in the port and the dependency to ffmpeg completely and disable libav to ensure that it doesn't try to use an installed ffmpeg 2.x. So this is the situation right now in 3.4.0.20130726.3_5 and it should build fine but you loose all the functionality that requires libav. Updated to latest ports, which got me tvheadend installed. I'm not sure what all the functionality that requires libav includes, so let me ask this way: - will / should DVB-C devices (via webcamd) work even without libav? - will CSA / cwc work even without libav? Yes, both should work. It uses libdvbcsa for that. What you loose is transcoding and streaming via the webinterface. ___ 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
[QAT] r344350: 4x leftovers
- Stage support - Build ID: 20140215101600-56757 Job owner: m...@freebsd.org Buildtime: 2 hours Enddate: Sat, 15 Feb 2014 12:30:41 GMT Revision: r344350 Repository: https://svnweb.freebsd.org/ports?view=revisionrevision=344350 - Port:math/numdiff 5.6.1 Buildgroup: 8.4-QAT/amd64 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~m...@freebsd.org/20140215101600-56757-277792/numdiff-5.6.1.log Buildgroup: 8.4-QAT/i386 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~m...@freebsd.org/20140215101600-56757-277793/numdiff-5.6.1.log Buildgroup: 9.2-QAT/amd64 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~m...@freebsd.org/20140215101600-56757-277794/numdiff-5.6.1.log Buildgroup: 9.2-QAT/i386 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~m...@freebsd.org/20140215101600-56757-277795/numdiff-5.6.1.log -- Buildarchive URL: https://qat.redports.org/buildarchive/20140215101600-56757 redports https://qat.redports.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: print/libharu does not build after update to 2.3.0
Am 15.02.2014 12:36, schrieb Pietro Cerutti: On 2014-Feb-15, 11:23, Rainer Hurling wrote: Unfortunately print/libharu does not build anymore after the update to 2.3.0 (r344246). This happens on HEAD r261806 amd64 with clang. Uhm, it seems to be related to the previous installation. Can you deinstall the currently installed version before building the new one? I'll look at a proper fix on monday! Thanks! Yupp, that was it. After deinstalling old print/libharu, the updated version builds and installs just fine. Thanks for the quick help! Any help is really appreciated. Thanks in advance, Rainer Hurling #make === Found saved configuration for libharu-2.3.0 === libharu-2.3.0 depends on file: /usr/local/sbin/pkg - found === Fetching all distfiles required by libharu-2.3.0 for building === Extracting for libharu-2.3.0 = SHA256 Checksum OK for libharu-2.3.0.tar.gz. === Patching for libharu-2.3.0 === Applying FreeBSD patches for libharu-2.3.0 === libharu-2.3.0 depends on file: /usr/local/bin/cmake - found === libharu-2.3.0 depends on shared library: libpng15.so - found === Configuring for libharu-2.3.0 === Performing out-of-source build /bin/mkdir -p /usr/ports/print/libharu/work/.build -- The C compiler identification is Clang 3.3.0 -- Check for working C compiler: /usr/bin/cc -- Check for working C compiler: /usr/bin/cc -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- DevPackage only available for Win32. Set DEVPAK to OFF. -- Looking for include file dlfcn.h -- Looking for include file dlfcn.h - found -- Looking for include file inttypes.h -- Looking for include file inttypes.h - found -- Looking for include file memory.h -- Looking for include file memory.h - found -- Looking for include file stdint.h -- Looking for include file stdint.h - found -- Looking for include file stdlib.h -- Looking for include file stdlib.h - found -- Looking for include file strings.h -- Looking for include file strings.h - found -- Looking for include file string.h -- Looking for include file string.h - found -- Looking for include file sys/stat.h -- Looking for include file sys/stat.h - found -- Looking for include file sys/types.h -- Looking for include file sys/types.h - found -- Looking for include file unistd.h -- Looking for include file unistd.h - found -- Found ZLIB: /usr/lib/libz.so (found version 1.2.8) -- Found PNG: /usr/local/lib/libpng.so (found version 1.5.18) Summary of CMake build system results for the haru library Install location variables which can be set by the user: CMAKE_INSTALL_PREFIX: /usr/local CMAKE_INSTALL_EXEC_PREFIX CMAKE_INSTALL_BINDIR CMAKE_INSTALL_LIBDIR CMAKE_INSTALL_INCLUDEDIR Other important CMake variables: CMAKE_SYSTEM_NAME: FreeBSD UNIX:1 WIN32: APPLE: MSVC:(MSVC_VERSION: ) MINGW: MSYS: CYGWIN: BORLAND: WATCOM: CMAKE_BUILD_TYPE:Release CMAKE_C_COMPILER CMAKE_C_FLAGS: /usr/bin/cc -O2 -pipe -fno-strict-aliasing Library options: LIBHPDF_SHARED: ON LIBHPDF_STATIC: ON LIBHPDF_EXAMPLES:ON DEVPAK: OFF Optional libraries: HAVE_LIBZ: TRUE HAVE_LIBPNG: TRUE -- Configuring done -- Generating done CMake Warning: Manually-specified variables were not used by the project: CMAKE_CXX_COMPILER CMAKE_CXX_FLAGS CMAKE_CXX_FLAGS_DEBUG CMAKE_CXX_FLAGS_RELEASE CMAKE_C_FLAGS_DEBUG CMAKE_MODULE_LINKER_FLAGS THREADS_HAVE_PTHREAD_ARG -- Build files have been written to: /usr/ports/print/libharu/work/.build === Building for libharu-2.3.0 Scanning dependencies of target hpdf Scanning dependencies of target hpdfs [ 1%] Building C object src/CMakeFiles/hpdf.dir/hpdf_binary.o [ 0%] Building C object src/CMakeFiles/hpdf.dir/hpdf_boolean.o [ 4%] Building C object src/CMakeFiles/hpdfs.dir/hpdf_annotation.o [ 4%] Building C object src/CMakeFiles/hpdf.dir/hpdf_catalog.o [ 5%] Building C object src/CMakeFiles/hpdf.dir/hpdf_array.o [ 4%] Building C object src/CMakeFiles/hpdf.dir/hpdf_annotation.o /usr/ports/print/libharu/work/libharu-libharu-7f4bb51/src/hpdf_annotation.c:235:46: error: use of undeclared identifier 'HPDF_ANNOT_WIDGET'; did you mean 'HPDF_ANNOT_HIDDEN'? annot = HPDF_Annotation_New (mmgr, xref, HPDF_ANNOT_WIDGET, rect); ^ HPDF_ANNOT_HIDDEN /usr/local/include/hpdf_types.h:366:5: note: 'HPDF_ANNOT_HIDDEN' declared here HPDF_ANNOT_HIDDEN, ^ /usr/ports/print/libharu/work/libharu-libharu-7f4bb51/src/hpdf_annotation.c:235:46: warning: implicit conversion from enumeration type 'enum
[QAT] r344399: 2x leftovers, 2x fetch
Add documentation, fix URL in description - Build ID: 20140215145800-22491 Job owner: l...@freebsd.org Buildtime: 3 hours Enddate: Sat, 15 Feb 2014 17:37:49 GMT Revision: r344399 Repository: https://svnweb.freebsd.org/ports?view=revisionrevision=344399 - Port:devel/lm4tools 0.1.3_1 Buildgroup: 8.4-QAT/amd64 Buildstatus: FETCH Log: https://qat.redports.org//~l...@freebsd.org/20140215145800-22491-278064/lm4tools-0.1.3_1.log Buildgroup: 8.4-QAT/i386 Buildstatus: FETCH Log: https://qat.redports.org//~l...@freebsd.org/20140215145800-22491-278065/lm4tools-0.1.3_1.log Buildgroup: 9.2-QAT/amd64 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~l...@freebsd.org/20140215145800-22491-278066/lm4tools-0.1.3_1.log Buildgroup: 9.2-QAT/i386 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~l...@freebsd.org/20140215145800-22491-278067/lm4tools-0.1.3_1.log -- Buildarchive URL: https://qat.redports.org/buildarchive/20140215145800-22491 redports https://qat.redports.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: Redport builds are all finished without logs
On 2/10/14 9:52 AM, John W. O'Brien wrote: Could you help me understand what's going on with this build [0]? Did an admin kill the job, and if so, why? Otherwise, what happened and is it because I'm doing something wrong? [0] https://redports.org/buildarchive/20140210032800-24135/ Continuing to troubleshoot this. I've been adding ports to TEST_DEPENDS one by one, and found an instance where the /before/ [1] works but the /after/ [2] does not. The implicated port is math/py-statsmodels (maintainer CC'd). I'm still not clear on the circumstances under which Redports winds up in the finished state, and consequently am unable to avoid it or work around it. Any help or advice would be appreciated. Thank you, John [1] https://redports.org/buildarchive/20140215154500-1493/ [2] https://redports.org/buildarchive/20140215163200-621/ signature.asc Description: OpenPGP digital signature
[QAT] r344426: 3x leftovers, 1x fetch
Simplify makefile - Build ID: 20140215162600-28695 Job owner: l...@freebsd.org Buildtime: 2 hours Enddate: Sat, 15 Feb 2014 18:40:32 GMT Revision: r344426 Repository: https://svnweb.freebsd.org/ports?view=revisionrevision=344426 - Port:devel/lm4tools 0.1.3_1 Buildgroup: 8.4-QAT/amd64 Buildstatus: FETCH Log: https://qat.redports.org//~l...@freebsd.org/20140215162600-28695-278164/lm4tools-0.1.3_1.log Buildgroup: 8.4-QAT/i386 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~l...@freebsd.org/20140215162600-28695-278165/lm4tools-0.1.3_1.log Buildgroup: 9.2-QAT/amd64 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~l...@freebsd.org/20140215162600-28695-278166/lm4tools-0.1.3_1.log Buildgroup: 9.2-QAT/i386 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~l...@freebsd.org/20140215162600-28695-278167/lm4tools-0.1.3_1.log -- Buildarchive URL: https://qat.redports.org/buildarchive/20140215162600-28695 redports https://qat.redports.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
[QAT] r344437: 4x leftovers
lang/gnatdroid-binutils: Specify LICENSE (GPLv3 + LGPL3) - Build ID: 20140215164600-29907 Job owner: mar...@freebsd.org Buildtime: 2 hours Enddate: Sat, 15 Feb 2014 18:40:56 GMT Revision: r344437 Repository: https://svnweb.freebsd.org/ports?view=revisionrevision=344437 - Port:lang/gnatdroid-binutils 2.24_1 Buildgroup: 8.4-QAT/amd64 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~mar...@freebsd.org/20140215164600-29907-278212/gnatdroid-binutils-2.24_1.log Buildgroup: 8.4-QAT/i386 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~mar...@freebsd.org/20140215164600-29907-278213/gnatdroid-binutils-2.24_1.log Buildgroup: 9.2-QAT/amd64 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~mar...@freebsd.org/20140215164600-29907-278214/gnatdroid-binutils-2.24_1.log Buildgroup: 9.2-QAT/i386 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~mar...@freebsd.org/20140215164600-29907-278215/gnatdroid-binutils-2.24_1.log -- Buildarchive URL: https://qat.redports.org/buildarchive/20140215164600-29907 redports https://qat.redports.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
USE_GITHUB and 500 Internal Server Error -- is it my fault or github is broken?
Hello, Ports.
I'm preparing port for texane/stlink project from github. So, I've added
USE_GITHUB= yes
GH_ACCOUNT= texae
GH_TAGNAME= 1.0.0
GH_COMMIT= 4d8faf38
to Makefile. And I cannot download distfile -- I got 500 Intrernal Server
Error on https:// and Service Unavailiable for HTTP.
USE_GITHUB= yes
GH_ACCOUNT= texae
GH_TAGNAME= ${GHCOMMIT}
GH_COMMIT= 4d8faf38
works no better.
Is it my fault or problem with github?
I could download tar file by hands from tag's page
(https://github.com/texane/stlink/archive/1.0.0.tar.gz) but it doesn't look
as good idea.
--
// Black Lion AKA Lev Serebryakov l...@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: Redport builds are all finished without logs
On 2/15/14 12:53 PM, John W. O'Brien wrote: On 2/10/14 9:52 AM, John W. O'Brien wrote: Could you help me understand what's going on with this build [0]? Did an admin kill the job, and if so, why? Otherwise, what happened and is it because I'm doing something wrong? [0] https://redports.org/buildarchive/20140210032800-24135/ Continuing to troubleshoot this. I've been adding ports to TEST_DEPENDS one by one, and found an instance where the /before/ [1] works but the /after/ [2] does not. The implicated port is math/py-statsmodels (maintainer CC'd). I'm still not clear on the circumstances under which Redports winds up in the finished state, and consequently am unable to avoid it or work around it. Any help or advice would be appreciated. [1] https://redports.org/buildarchive/20140215154500-1493/ [2] https://redports.org/buildarchive/20140215163200-621/ I see the problem. math/py-statsmodels depends on math/py-pandas. So the bad news is that I cannot include the former in TEST_DEPENDS for the latter and expect much at all from Redports. The good news is that I can now fix my port to be more readily testable. For the benefit of those who come after, would it make sense to augment the description of the finished state [3] to mention the possibility of circular dependencies, which don't appear to be covered by the other detectable termination conditions? Regards, John [3] https://redports.org/wiki/Buildstatus signature.asc Description: OpenPGP digital signature
Re: USE_GITHUB and 500 Internal Server Error -- is it my fault or github is broken?
Hello, Lev. You wrote 15 февраля 2014 г., 23:31:06: LS GH_ACCOUNT= texae I-NEED-TO-CHECK-MY-TYPING-CAREFULLY. -- // Black Lion AKA Lev Serebryakov l...@freebsd.org ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
INDEX build failed for 8.x
INDEX build failed with errors: Generating INDEX-8 - please wait.. Done. make_index: Circular dependency loop found: kyua-20140215,1 depends upon itself. Committers on the hook: antoine glewis jmmv marino mva rakuco rm sunpoet Most recent SVN update was: Updating '.': Ddevel/py-rtree/pkg-plist Udevel/py-rtree/pkg-descr Udevel/py-rtree/Makefile Udevel/py-logilab-common/distinfo Ddevel/py-usb/pkg-plist Udevel/py-usb/Makefile Ddevel/py-utils/pkg-plist Udevel/py-utils/Makefile Adevel/p5-MooX-StrictConstructor Adevel/p5-MooX-StrictConstructor/Makefile Adevel/p5-MooX-StrictConstructor/distinfo Adevel/p5-MooX-StrictConstructor/pkg-descr Adevel/p5-MooX-StrictConstructor/pkg-plist Udevel/p5-Data-Dumper-Concise/Makefile Udevel/p4/Makefile Ddevel/kyua/distinfo Ddevel/kyua/files Udevel/kyua/pkg-plist Udevel/kyua/Makefile Udevel/p5-Clone-PP/Makefile Adevel/kyua-cli Adevel/kyua-cli/files Adevel/kyua-cli/files/patch-utils-config-nodes.cpp Adevel/kyua-cli/files/patch-utils-config-nodes.ipp Adevel/kyua-cli/files/patch-utils-config-tree.cpp Adevel/kyua-cli/files/kyua.conf.in Adevel/kyua-cli/files/patch-utils-config-tree.ipp Adevel/kyua-cli/pkg-plist Adevel/kyua-cli/Makefile Adevel/kyua-cli/distinfo Adevel/kyua-cli/pkg-descr Udevel/Makefile Adevel/stlink Adevel/stlink/files Adevel/stlink/files/patch-configure.ac Adevel/stlink/pkg-plist Adevel/stlink/Makefile Adevel/stlink/distinfo Adevel/stlink/pkg-descr Ddevel/py-timelib/pkg-plist Udevel/py-timelib/Makefile Ulang/gnatdroid-binutils/pkg-plist Umisc/lifelines/distinfo Umisc/lifelines/pkg-plist Umisc/lifelines/Makefile Ujava/openjdk7/Makefile Ajava/openjdk7/files/patch-src-solaris-classes-sun-net-PortConfig.java Updated to revision 344497. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
INDEX build failed for 8.x
INDEX build failed with errors: Generating INDEX-8 - please wait.. Done. make_index: Circular dependency loop found: kyua-20140215,1 depends upon itself. Committers on the hook: antoine glewis jmmv marino mva rakuco rm sunpoet Most recent SVN update was: Updating '.': At revision 344497. ___ 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
Why would a port use its own existence as an excuse to fail install?
Silly me -- I thought today might be a good day to upgrade X.org on my laptop to the NEW_XORG. Laptop is running: FreeBSD g1-251.catwhisker.org 9.2-STABLE FreeBSD 9.2-STABLE #670 r261880M/261884:902506: Fri Feb 14 04:50:27 PST 2014 r...@g1-251.catwhisker.org:/usr/obj/usr/src/sys/CANARY i386 I would have updated it this morning, but there were to updates to stable/9 as of r261913 (which is the current state of my local private mirror). Ports is at r344370; I've been using pkgng on the machine for about a week (though I still build ports, usually using portmaster. Here's an example of the Subject One of the ports to be updated (based on the process documented in ports/UPDATING 20131216) was textproc/clucene-qt4. So (cut/paste from typescript): === textproc/clucene-qt4 3/5 0;portmaster: textproc/clucene-qt4 3/5^G === Port directory: /usr/ports/textproc/clucene-qt4 === Starting check for build dependencies === Gathering dependency list for textproc/clucene-qt4 from ports === Dependency check complete for textproc/clucene-qt4 === textproc/clucene-qt4 3/5 0;portmaster: textproc/clucene-qt4 3/5^G === Cleaning for qt4-clucene-4.8.5 === License LGPL21 accepted by the user === qt4-clucene-4.8.5 depends on file: /usr/local/sbin/pkg - found === Fetching all distfiles required by qt4-clucene-4.8.5 for building === Extracting for qt4-clucene-4.8.5 === Patching for qt4-clucene-4.8.5 === Applying extra patch /common/ports/devel/qt4/files/extrapatch-configure === Applying FreeBSD patches for qt4-clucene-4.8.5 === qt4-clucene-4.8.5 depends on file: /usr/local/lib/qt4/libQtCore.so - found === qt4-clucene-4.8.5 depends on file: /usr/local/bin/qmake-qt4 - found === Configuring for qt4-clucene-4.8.5 /bin/mkdir -p /common/ports/textproc/clucene-qt4/work/qt-everywhere-opensource-src-4.8.5/mkspecs /bin/ln -sf /usr/local/bin/qmake-qt4 /common/ports/textproc/clucene-qt4/work/qt-everywhere-opensource-src-4.8.5/bin/qmake This is the Open Source Edition. ... Build type:/common/local/share/qt4/mkspecs/freebsd-g++ Architecture: i386 ... Finding project files. Please wait... WARNING: /common/ports/textproc/clucene-qt4/work/qt-everywhere-opensource-src-4.8.5/projects.pro:46: Unable to find file for inclusion doc/doc.pri Reading /common/ports/textproc/clucene-qt4/work/qt-everywhere-opensource-src-4.8.5/assistant ... === Starting check for runtime dependencies === Gathering dependency list for textproc/clucene-qt4 from ports === Dependency check complete for textproc/clucene-qt4 === textproc/clucene-qt4 3/5 0;portmaster: textproc/clucene-qt4 3/5^G === Staging for qt4-clucene-4.8.5 === Generating temporary packing list install -m 755 -p ../../../../lib/libQtCLucene.so.4.8.5 /common/ports/textproc/clucene-qt4/work/stage/usr/local/lib/qt4/libQtCLucene.so.4.8.5 ... sed -e s,/common/ports/textproc/clucene-qt4/work/qt-everywhere-opensource-src-4.8.5/include,/usr/local/include/qt4,g -e s,/common/ports/textproc/clucene-qt4/work/qt-everywhere-opensource-src-4.8.5/lib,/usr/local/lib/qt4,g -e s,/common/ports/textproc/clucene-qt4/work/qt-everywhere-opensource-src-4.8.5,/usr/local,g ../../../../lib/pkgconfig/QtCLucene.pc /common/ports/textproc/clucene-qt4/work/stage/usr/local/libdata/pkgconfig/QtCLucene.pc Compressing man pages (compress-man) === Installing ldconfig configuration file === Installing for qt4-clucene-4.8.5 === Registering installation for qt4-clucene-4.8.5 Installing qt4-clucene-4.8.5...pkg-static: qt4-clucene-4.8.5 conflicts with qt4-clucene-4.8.5 (installs files into the same place). Problematic file: /usr/local/lib/qt4/libQtCLucene.la *** [fake-pkg] Error code 70 Stop in /common/ports/textproc/clucene-qt4. === Installation of qt4-clucene-4.8.5 (textproc/clucene-qt4) failed === Aborting update === Update for textproc/clucene-qt4 failed === Aborting update === Killing background jobs Terminated So that Installing qt4-clucene-4.8.5...pkg-static: qt4-clucene-4.8.5 conflicts with qt4-clucene-4.8.5 (installs files into the same place). Problematic file: /usr/local/lib/qt4/libQtCLucene.la is what I was going on about. That really seems like about the lamest excuse for failing an install that I could imagine Eventually, it will probably become moot, as I'll (eventually) migrate to stable/10, and go through the deinstall-all-ports, then reinstall-all-ports exercise but, seriously...? What's causing this? How do I make it stop? Peace, david -- David H. Wolfskill da...@catwhisker.org Taliban: Evil cowards with guns afraid of truth from a 14-year old girl. See http://www.catwhisker.org/~david/publickey.gpg for my public key. pgpNv6ElX0yc9.pgp Description: PGP signature
Re: Why would a port use its own existence as an excuse to fail install?
Hi, On Sat, 15 Feb 2014 19:31:19 -0800 David Wolfskill da...@catwhisker.org wrote: Silly me -- I thought today might be a good day to upgrade X.org on my laptop to the NEW_XORG. yes, Saturdays are good days for updates. Compressing man pages (compress-man) === Installing ldconfig configuration file === Installing for qt4-clucene-4.8.5 === Registering installation for qt4-clucene-4.8.5 Installing qt4-clucene-4.8.5...pkg-static: qt4-clucene-4.8.5 conflicts with qt4-clucene-4.8.5 (installs files into the same place). Problematic file: /usr/local/lib/qt4/libQtCLucene.la *** [fake-pkg] Error code 70 Cool! Eventually, it will probably become moot, as I'll (eventually) Before you do this switch to svn and portupgrade. migrate to stable/10, and go through the deinstall-all-ports, then reinstall-all-ports exercise but, seriously...? What's causing this? Even this exercise can be done with svn and portupgrade. I use portupgrade since many years. It was hard at the beginning but it did not leave me with an machine I could not use anymore. Ok, it does not upgrade the affected ports then but I still can use the machine. Instruct it to make backup packages of the installed ports and you should be real save. Erich ___ 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: Why would a port use its own existence as an excuse to fail install?
On Sat, Feb 15, 2014 at 07:31:19PM -0800 I heard the voice of David Wolfskill, and lo! it spake thus: So that Installing qt4-clucene-4.8.5...pkg-static: qt4-clucene-4.8.5 conflicts with qt4-clucene-4.8.5 (installs files into the same place). Problematic file: /usr/local/lib/qt4/libQtCLucene.la is what I was going on about. That really seems like about the lamest excuse for failing an install that I could imagine Actually, it's an excellent excuse. Installing it when it's already installed is shupid. What's lame is that it's not _realizing_ it's already installed, and failing to try and uninstall it first. And I think that's a problem across several qt4 ports, due to some renaming along the line that did something like change them from qt4-xyz to xyz-qt4 or the like. A 'pkg check -d' on my workstation since I pkg2ng'd blows up a bunch of errors alone those lines: x11/kdelibs4 has a missing dependency: x11/qt4-opengl x11/kdelibs4 has a missing dependency: textproc/qt4-clucene x11/kdelibs4 has a missing dependency: devel/qt4-qtestlib x11/kdelibs4 has a missing dependency: devel/qt4-declarative [ various other kde/qt bits in the same pattern ] % pkg info | grep -E 'qt4-(opengl|clucene|qtestlib|declarative)' qt4-clucene-4.8.5 QtCLucene full text search library wrapper qt4-declarative-4.8.5 Qt4 framework for building highly dynamic user interfaces qt4-opengl-4.8.5 Qt OpenGL library qt4-qtestlib-4.8.5 Qt unit testing library % pkg info qt4-clucene qt4-clucene-4.8.5 Name : qt4-clucene Origin : textproc/clucene-qt4 Note the Origin of textproc/clucene-qt4 where kdelibs4 is expecting to find textproc/qt4-clucene. So I'd guess the same sorta thing is making portmaster try to _install_ it for you, rather than _upgrading_ it. -- Matthew Fuller (MF4839) | fulle...@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. ___ 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: Why would a port use its own existence as an excuse to fail install?
So I'd guess the same sorta thing is making portmaster try to _install_ it for you, rather than _upgrading_ it. Or, rather, not touch it at all. A nice thing about portmaster is that it's smarter than portupgrade. An annoying thing is that, to me anyway, that usually seems to take the form of trying to outsmart me, and I don't take kindly to that kinda crap from anything without thumbs :p In this case, I'd guess, portmaster does its thing of pulling lists of unmet (by whatever criterion) dependancies of the new thing you're installing/upgrading to, and building/installing them itself rather than letting ports' own recursion handle it. So building the port you actually want to upgrade would say, hey, that qt4-clucene stuff is already there, so nothing to do. But portmaster notices (presumably through the same mechanism pkg check -d is triggering) that, hey, there's no port with that origin installed, so I'll build and install it myself first. Which fails, since it's already installed, thus... Now, why the origin of the _package_ is up to date with reality, while the origins of the dependancy links are wrong, is the root question. Those moves (r338902, Jan 6) were before I pkg2ng'd this box, so maybe it's just some bad interaction between MOVED and portupgrade's pkgdb which would have done the fixup and pkgog[0] and pkgng. [0] Appropriate nomenclature in the long run, I suspect. Imagine the day when 12- and 13-STABLE are common, and then one day you find an 8.x box that's been sitting untouched since now, and you have to bring it up to date. You try and look at the installed packages, and you say pkg... oh god :) -- Matthew Fuller (MF4839) | fulle...@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. ___ 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: Why would a port use its own existence as an excuse to fail install?
On 02/15/2014 22:31, David Wolfskill wrote: Silly me -- I thought today might be a good day to upgrade X.org on my laptop to the NEW_XORG. Laptop is running: FreeBSD g1-251.catwhisker.org 9.2-STABLE FreeBSD 9.2-STABLE #670 r261880M/261884:902506: Fri Feb 14 04:50:27 PST 2014 r...@g1-251.catwhisker.org:/usr/obj/usr/src/sys/CANARY i386 I would have updated it this morning, but there were to updates to stable/9 as of r261913 (which is the current state of my local private mirror). Ports is at r344370; I've been using pkgng on the machine for about a week (though I still build ports, usually using portmaster. Here's an example of the Subject One of the ports to be updated (based on the process documented in ports/UPDATING 20131216) was textproc/clucene-qt4. So (cut/paste from typescript): === textproc/clucene-qt4 3/5 0;portmaster: textproc/clucene-qt4 3/5^G === Port directory: /usr/ports/textproc/clucene-qt4 === Starting check for build dependencies === Gathering dependency list for textproc/clucene-qt4 from ports === Dependency check complete for textproc/clucene-qt4 === textproc/clucene-qt4 3/5 0;portmaster: textproc/clucene-qt4 3/5^G === Cleaning for qt4-clucene-4.8.5 === License LGPL21 accepted by the user === qt4-clucene-4.8.5 depends on file: /usr/local/sbin/pkg - found === Fetching all distfiles required by qt4-clucene-4.8.5 for building === Extracting for qt4-clucene-4.8.5 === Patching for qt4-clucene-4.8.5 === Applying extra patch /common/ports/devel/qt4/files/extrapatch-configure === Applying FreeBSD patches for qt4-clucene-4.8.5 === qt4-clucene-4.8.5 depends on file: /usr/local/lib/qt4/libQtCore.so - found === qt4-clucene-4.8.5 depends on file: /usr/local/bin/qmake-qt4 - found === Configuring for qt4-clucene-4.8.5 /bin/mkdir -p /common/ports/textproc/clucene-qt4/work/qt-everywhere-opensource-src-4.8.5/mkspecs /bin/ln -sf /usr/local/bin/qmake-qt4 /common/ports/textproc/clucene-qt4/work/qt-everywhere-opensource-src-4.8.5/bin/qmake This is the Open Source Edition. ... Build type:/common/local/share/qt4/mkspecs/freebsd-g++ Architecture: i386 ... Finding project files. Please wait... WARNING: /common/ports/textproc/clucene-qt4/work/qt-everywhere-opensource-src-4.8.5/projects.pro:46: Unable to find file for inclusion doc/doc.pri Reading /common/ports/textproc/clucene-qt4/work/qt-everywhere-opensource-src-4.8.5/assistant ... === Starting check for runtime dependencies === Gathering dependency list for textproc/clucene-qt4 from ports === Dependency check complete for textproc/clucene-qt4 === textproc/clucene-qt4 3/5 0;portmaster: textproc/clucene-qt4 3/5^G === Staging for qt4-clucene-4.8.5 === Generating temporary packing list install -m 755 -p ../../../../lib/libQtCLucene.so.4.8.5 /common/ports/textproc/clucene-qt4/work/stage/usr/local/lib/qt4/libQtCLucene.so.4.8.5 ... sed -e s,/common/ports/textproc/clucene-qt4/work/qt-everywhere-opensource-src-4.8.5/include,/usr/local/include/qt4,g -e s,/common/ports/textproc/clucene-qt4/work/qt-everywhere-opensource-src-4.8.5/lib,/usr/local/lib/qt4,g -e s,/common/ports/textproc/clucene-qt4/work/qt-everywhere-opensource-src-4.8.5,/usr/local,g ../../../../lib/pkgconfig/QtCLucene.pc /common/ports/textproc/clucene-qt4/work/stage/usr/local/libdata/pkgconfig/QtCLucene.pc Compressing man pages (compress-man) === Installing ldconfig configuration file === Installing for qt4-clucene-4.8.5 === Registering installation for qt4-clucene-4.8.5 Installing qt4-clucene-4.8.5...pkg-static: qt4-clucene-4.8.5 conflicts with qt4-clucene-4.8.5 (installs files into the same place). Problematic file: /usr/local/lib/qt4/libQtCLucene.la *** [fake-pkg] Error code 70 Stop in /common/ports/textproc/clucene-qt4. === Installation of qt4-clucene-4.8.5 (textproc/clucene-qt4) failed === Aborting update === Update for textproc/clucene-qt4 failed === Aborting update === Killing background jobs Terminated So that Installing qt4-clucene-4.8.5...pkg-static: qt4-clucene-4.8.5 conflicts with qt4-clucene-4.8.5 (installs files into the same place). Problematic file: /usr/local/lib/qt4/libQtCLucene.la is what I was going on about. That really seems like about the lamest excuse for failing an install that I could imagine Eventually, it will probably become moot, as I'll (eventually) migrate to stable/10, and go through the deinstall-all-ports, then reinstall-all-ports exercise but, seriously...? What's causing this? How do I make it stop? Peace, david I know you mentioned UPDATING 20131216, but I suspect you are tripping over the 20140107 entry. The quick pkg set commands will probably solve this. Sometimes it is hard to determine the right combination of actions to take from UPDATING if some time has passed; most entries are written assuming your installed ports match the ports tree by that date.
Re: Why would a port use its own existence as an excuse to fail install?
On Sat, Feb 15, 2014 at 11:19:02PM -0500, Adam McDougall wrote: ... I know you mentioned UPDATING 20131216, but I suspect you are tripping over the 20140107 entry. The quick pkg set commands will probably solve this. Sometimes it is hard to determine the right combination of actions to take from UPDATING if some time has passed; most entries are written assuming your installed ports match the ports tree by that date. Now that you point that out, it does seem likely, as I hadn't switched the system to pkg at that date, so the stated action was ... well, moot (at the time). And now textproc/clucene-qt4 devel/qt4-testlib have been re-installed, apparently succesfully. (www/webkit-qt4 will take a bit longer than I can hold my breath :-}) Thanks, both to you to Matthew D. Fuller. Peace, david -- David H. Wolfskill da...@catwhisker.org Taliban: Evil cowards with guns afraid of truth from a 14-year old girl. See http://www.catwhisker.org/~david/publickey.gpg for my public key. pgpIdyFHp4JhY.pgp Description: PGP signature
Calling Maintainer AWOL on and Requesting Maintainership of net-mgmt/nagios-check_ports
FYI, I've submitted a request to call maintainership AWOL and assume maintainership of net-mgmt/nagios-check_ports. Details are at http://www.freebsd.org/cgi/query-pr.cgi?pr=186809 Ryan ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
INDEX now builds successfully on 8.x
___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: graphics/libjpeg-turbo in place of graphics/jpeg
On Tue, Feb 11, 2014 at 5:27 AM, Jakub Lach jakub_l...@mailplus.pl wrote: Currently, I reckon that libjpeg-turbo is a drop in replacement for graphics/jpeg. Unfortunately, most ports have a direct dependency on graphics/jpeg and will complain if it is missing[1]. Is there any way to achieve that and keep pkng happy? See PR 180159 http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/180159 This PR adds a new USES feature for jpeg allowing the appropriate jpeg port to be selected. Then all jpeg using ports would need to be modified as stated in the PR. Could someone commit this PR. Thanks, ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
