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 +-+ biology/tinker | 6.2.06 | 6.3.2 +-+ devel/bisoncpp | 4.05.00 | 4.07.00 +-+ devel/libbobcat | 3.18.01 | 3.21.01 +-+ 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
graphics/digikam-kde4 does not build on HEAD
When I try to build graphics/digikam-kde4 on recent HEAD amd64 I get the following error, complaining about missing -fPIC in graphics/opencv. [ 36%] Building CXX object digikam/CMakeFiles/digikamcore.dir/__/utilities/imageeditor/plugin/imagepluginloader.o [ 36%] Building CXX object digikam/CMakeFiles/digikamcore.dir/digikamconfig.o Linking CXX shared library ../lib/libdigikamcore.so /usr/bin/ld: /usr/local/lib/libopencv_ts.a(gpu_perf.cpp.o): relocation R_X86_64_32S against `a local symbol' can not be used when making a shared object; recompile with -fPIC /usr/local/lib/libopencv_ts.a: could not read symbols: Bad value c++: error: linker command failed with exit code 1 (use -v to see invocation) *** Error code 1 Stop. make[4]: stopped in /usr/ports/graphics/digikam-kde4/work/digikam-3.5.0/core *** Error code 1 I also have problems with a second port using graphics/opencv: math/saga is not able to use its own module 'libimagery_opencv.so' at runtime. Because of this, I suspect graphics/opencv is to blame instead of graphics/digikam-kde4. If digikam's report of missing -fPIC is right, what would be the right way to integrate it? Any help is appreciated. Thanks in advance. Regards, Rainer Hurling ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: New port cad/fritzing
On Wed, Nov 07, 2012 at 03:34:35PM -0200, Sergio de Almeida Lenzi wrote: Em Qua, 2012-11-07 às 21:37 +1000, Robert Backhaus escreveu: I had not problems building, but when I run, I get error messages: Dialog: Sorry, we have a problem with the swapping mechanism. Fritzing still works, but you won't be able to change parts properties While loading bin: core parts, a dialog that says Unable to find the following 112 parts, and a list starting with '3234DBDC00PotnetionmetModuleId' at parts/core/basic_poti.fzp' When closing that window (The 'OK' button is unavailable, because it is way off the bottom of the screen), we get printed to the console: 7 times: QPainter::begin: Paint device returned engine == 0, type: 2 QPainter::end: Painter not active, aborted about 42 times: libpng error: PNG file corrupted by ASCII conversion The program then opens, but, as there are no parts, I can't do much. Ok.. I will build a system from ground zero (xorg, qt) and will test hope by tomorrow I will have a clue... Sergio, I updated your port to the latest version of Fritzing: http://bsd-geek.de/FreeBSD/fritzing-0.8.7b.shar.xz Unfortunately it's still showing the errors on startup and isn't usable. Did you find out how to solve the problem? Lars pgpkqRVXfcmMW.pgp Description: PGP signature
install error nvidia-driver 331.20
Hi, I'm getting an install error when installing the nvidia-driver 331.20 from ports: ... Creating bzip'd tar ball in '/usr/ports/x11/nvidia-driver/work/nvidia-driver-331.20.tbz' tar: lib/libEGL.so: Cannot stat: No such file or directory tar: lib/libEGL.so.1: Cannot stat: No such file or directory tar: lib/libGLESv1_CM.so: Cannot stat: No such file or directory tar: lib/libGLESv1_CM.so.1: Cannot stat: No such file or directory tar: lib/libGLESv2.so: Cannot stat: No such file or directory tar: lib/libGLESv2.so.2: Cannot stat: No such file or directory tar: lib/libnvidia-eglcore.so: Cannot stat: No such file or directory tar: lib/libnvidia-eglcore.so.1: Cannot stat: No such file or directory tar: lib/libnvidia-glsi.so: Cannot stat: No such file or directory tar: lib/libnvidia-glsi.so.1: Cannot stat: No such file or directory tar: Error exit delayed from previous errors. pkg_create: make_dist: tar command failed with code 256 *** [do-package] Error code 1 ... The files mentioned above do actually exist in /usr/local/lib. I'm running FreeBSD 9.2-STABLE i386. Does anyone have a clue to solve this? Thanks in advance, Regards, Marco -- The Hollywood tradition I like best is called sucking up to the stars. -- Johnny Carson ___ 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: Update for graphics/libopenraw failed
On Thu, 13 Feb 2014 19:22:25 -0800 (PST) Robert English drak...@pacbell.net wrote: Had a similar problem on my 8.4-Release system. After looking at the config.log file, figured out it was looking for libboost_unit_test_framework_gcc42.so so I made a soft link in the usr/local/lib directory with that name pointing to the libboost_unit_test_framework.so.1.55.0 file. Libopenraw compiled fine after that. Putting this on the server in case someone else has this problem also. Bob On Feb 10, Randy Pratt wrote: The system is an 8.4-STABLE/i386. Excerpt from the entire http://myfreebsd.homeunix.net/libopenraw-0.0.8_5.log : checking boost/test/unit_test.hpp presence... yes checking for boost/test/unit_test.hpp... yes checking for the Boost unit_test_framework library... no configure: error: Could not find the flags to link with Boost unit_test_framework === Script configure failed unexpectedly. - I've not used it in some time but libmap.conf comes to mind as the tool I have used instead of making symlinks for libraries. I took a different approach. I found the dependency chain: graphics/gimp -- graphics/gegl -- graphics/libopenraw Gimp was the only port that used libopenraw and I don't use gimp for manipulating camera images. My temporary work around was to remove the OPTION for openraw in graphics/gegl. It was necessary to rebuild gegl and gimp to satisfy pkg_libchk. Now the trick will be to remember that I did this if I happened to need to use camera RAW images at some point. Thanks, Randy ___ 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-static segfaults when a port makes a package in chroot/nanobsd.
I have a ticket open in github for this, but I wanted to mail in and let
people know that I figured the problem out somewhat:
https://github.com/freebsd/pkg/issues/729
OK I sort of figured it out.
Basically the build script that I have issues the following command:
TARGET=amd64 TARGET_ARCH=amd64 NAS_PORTS_DIRECT=1 make
__MAKE_CONF=/vol/data/alfred/freenas/os-base/amd64/make.conf.build
SRC_BASE=/usr/src WRKDIRPREFIX=/usr/workdir -C
/usr/ports_dir/textproc/libxml2 clean all install package BATCH=yes
-DUSE_PACKAGE_DEPENDS -DFORCE_PACKAGE -DFORCE_PKG_REGISTER
The after adding -d lx to the command for make(1) I saw that it
looks like the install target will rm -rf the stage dir!
By switching around the order of targets from:
clean all install package
TO:
clean all package install
It stopped deleting the .metadir which in turn stopped it from
segfaulting.
It looks like there's a bug in the port's Mk system as well as pkgng.
For now I think I may have a workaround.
Thanks everyone! For what it's worth my ports tree's latest commit is this:
commit e6fcb0faa8aeb5905bad5c295f319917aafd21ff
Author: makc m...@freebsd.org
Date: Thu Feb 13 14:25:26 2014 +
misc/py-qt4-demo:
- Use plist instead of PORTEXAMPLES, otherwise the package is bogus
when
NOPORTEXAMPLES is set
- Use compileall.py to byte-compile installed examples
- Use options helpers
On 2/15/14, 9:01 PM, Alfred Perlstein wrote:
Hey folks, I'm doing a build of nanobsd derivative and trying to get
it to work on 10-stable with the tip of freebsd ports as of a couple
of days ago.
I'm getting a segfault in pkg-static when trying to make package.
The stack trace is this:
(gdb) bt
#0 0x005a0bcc in ucl_obj_ref (obj=0x0) at ucl.h:743
#1 0x005a0b99 in ucl_parser_get_object (parser=0x801027880)
at
/usr/workdir/usr/ports/ports-mgmt/pkg/work/pkg-1.2.6/libpkg/../external/libucl/src/ucl_util.c:230
#2 0x00564795 in pkg_parse_manifest_file (pkg=0x80104e1c0,
file=0x7fffb010
/usr/workdir/usr/ports_dir/textproc/libxml2/work/.metadir/+MANIFEST,
keys=0x8010282e0) at pkg_manifest.c:748
#3 0x0043d83d in pkg_create_staged (
outdir=0x7fffbc5d /usr/ports/packages/All, format=TXZ,
rootdir=0x7fffbba5
/usr/workdir/usr/ports_dir/textproc/libxml2/work/stage,
md_dir=0x7fffbbdf
/usr/workdir/usr/ports_dir/textproc/libxml2/work/.metadir,
plist=0x7fffbc1c
/usr/workdir/usr/ports_dir/textproc/libxml2/work/.PLIST.mktmp,
old=false) at pkg_create.c:248
#4 0x00407e93 in exec_create (argc=1, argv=0x7fffb720)
at create.c:262
#5 0x0040bd47 in main (argc=10, argv=0x7fffb6d8) at
main.c:774
(gdb)
The file
/usr/workdir/usr/ports_dir/textproc/libxml2/work/.metadir/+MANIFEST
doesn't seem to exist.
The command being run is this:
env TARGET=amd64 TARGET_ARCH=amd64 NAS_PORTS_DIRECT=1 make
__MAKE_CONF=/vol/data/alfred/freenas/os-base/amd64/make.conf.build
SRC_BASE=/usr/src WRKDIRPREFIX=/usr/workdir -C
/usr/ports_dir/textproc/libxml2 clean all install package BATCH=yes
-DUSE_PACKAGE_DEPENDS -DFORCE_PACKAGE -DFORCE_PKG_REGISTER
Any ideas? There is a large env being set:
The environment looks like this, you can probably grep -v out the
^NANO stuff to make this readable:
NANO_PYTHON_DEFAULT_VERSION=python2.7
SUDO_COMMAND=/usr/local/bin/zsh
NANO_SRC=/vol/data/alfred/freenas/FreeBSD/src
NANO_MODULES= cc/cc_cdg cc/cc_chd cc/cc_cubic cc/cc_hd cc/cc_htcp
cc/cc_vegas cxgb cxgbe cyclic dtrace ext2fs fdescfs geom ipmi krpc
libiconv libmchain lindev linprocfs linsysfs linux nfs_common
nfsclient nfslock ispfw/ispfw opensolaris pf pflog smbfs tmpfs udf
usb/xhci zfs ctl cxgbe/t4_firmware cxgbe/t5_firmware iscsi syscons
NANO_LABEL=DarkShield
NANO_MEDIASIZE=14450688
NANO_NEWFS=-b 4096 -f 512 -i 8192 -O1 -U
LOGNAME=root
NANO_TOOLS=/vol/data/alfred/freenas/build/nanobsd
NANO_MAKE_CONF_BUILD=/vol/data/alfred/freenas/os-base/amd64/make.conf.build
NAS_PORTS_DIRECT=1
NANO_BOOTLOADER=boot/boot0
MAKELEVEL=1
AVATAR_ROOT=/vol/data/alfred/freenas
NANO_XZ=pxz
MAKEOBJDIRPREFIX=/vol/data/alfred/freenas/os-base/amd64
FREEBSD_PACKAGE_MIRROR_32=http://mirror.exonetric.net/pub/pkgng/freebsd:9:x86:32/latest
NANO_PMAKE=make -j 9
SCRIPT=typescript
NANO_ARCH=amd64
FREEBSD_PKGCACHE_32=/freenas-build/freebsd-packages-32
MASTER_SITE_OVERRIDE=http://build/distcache/${DIST_SUBDIR}/
MAIL=/var/mail/root
NANO_LOCAL_DIRS= pbi-wrapper extract-tarball
NANO_CONFSIZE=2048
MAKEFLAGS= .MAKE.LEVEL.ENV=MAKELEVEL
NANO_HEADS=16
DISTCACHE=
MAKE_JOBS=9
PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/games:/usr/local/sbin:/usr/local/bin:/home/alfred/bin
FREEBSD_DISTCACHE=/freenas-build/freebsd-distfiles
NANO_IMAGES=2
NANO_CFG_BASE=/vol/data/alfred/freenas/nanobsd
NANO_MAKE_CONF_INSTALL=/vol/data/alfred/freenas/os-base/amd64/make.conf.install
SUDO_GID=1001
OLDPWD=/vol/data/alfred/freenas/FreeBSD/ports/devel/py-fake-factory
.MAKE.LEVEL.ENV=MAKELEVEL
NANO_DATASIZE=4096000
Re: Why would a port use its own existence as an excuse to fail install?
On Sat, 15 Feb 2014 22:14:54 -0600 Matthew D. Fuller wrote: A nice thing about portmaster is that it's smarter than portupgrade. ... In this case, I'd guess, portmaster ... Which fails, since it's already installed, thus... For me portupgrade did that upgrade perfectly even though I forgot to read UPDATING. pkg check reports no errors. ___ 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
Am 15.02.2014 21:07 schrieb John W. O'Brien j...@saltant.com: 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 The finished state is not something the user should see at all. The truth is that there are cases that redports is unable to detect because of bugs inside tinderbox or in the redports scripts or because of extreme cases like circular dependencies like in your cases. In the beginning circular dependencies took the whole backend down but I worked around it by setting the maximum size of the tinderbox environment directory to a very small value so it fails after some minutes of excessive i/o and cpu usage. So except from when the tinderbox job fails in a strange way and the environment directory is 100÷ full I see no chance how to detect that case and I don't want to build a feature based on a dirty workaround. The right way to fix that is to add a circular dependency check to tinderbox and then I can read out that error properly. ___ 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
Am 15.02.2014 21:07 schrieb John W. O'Brien j...@saltant.com: 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 I've added it to the wiki. ___ 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
sage 6.1.1
Hi! My system: FreeBSD 10.0-RELEASE #1: Mon Jan 20 12:44:17 EST 2014 /usr/obj/usr/src/sys/GENERIC amd64 I give a try again to sgae 6.1.1 and it doesn't build still on my system. Please, check attached log. -- Mitja --- http://www.redbubble.com/people/lumiwa ___ 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
Adventures in ports, chapter 340877
Perhaps it's just my bad luck, but updating my ports rarely goes
smoothly. Here's my current collection of patches, as of svn version
340877.
No patch for this, but with the replacement of openoffice-3 with
openoffice-4, portmaster dies when trying to install openoffice-4
without having removed openoffice-3, because they install some
files to the same location. Removing openoffice-3 first fixes the
problem. A note in UPDATING would be a big help.
devel/avarice/Makefile: libiberty is currently installed by
binutils, not gnulibiberty, as odd as that sounds.
graphics/jbig2dec/Makefile: This may have been due to some temporary
ports problem, but graphics/jbig2dec couldn't find libpng15.so unless
I specified the file revision number. I haven't recently tried
reverting this patch yet.
print/cups-base/Makefile: Couldn't compile print/cups-image without
this patch.
print/freetype2/Makefile: USE_GCC=any was needed to compile on arm.
Additional symbolic link required to build openoffice-3 (and perhaps
other ports that didn't know the include files have moved).
print/freetype2/pkg-plist: Add the above symbolic link to the
packing list.
print/hplip-plugin/Makefile: HP's plugin_install program uses a Qt4/X
user interface to get user confirmation of the license terms. But
luckily, it comes with a -i option that just uses a terminal.
x11/gdm/Makefile: The gnome-keyring program is installed by
security/gnome-keyring, not security/libgnome-keyring.
x11/pixman/Makefile: Patch was cribbed from a PR that I've lost track
of, but without this patch, pixman won't compile on arm.
x11/xbacklight/Makefile: Probably akin to my jbig2dec problem.
x11-drivers/Makefile: Without this patch, x11-drivers tries to
compile the broken radeonhd video driver.
(Please cc me with comments, as I am not on the ports mailing list.)
-- George Mitchell
Index: devel/avarice/Makefile
===
--- devel/avarice/Makefile (revision 340877)
+++ devel/avarice/Makefile (working copy)
@@ -12,7 +12,7 @@
LICENSE= GPLv2
BUILD_DEPENDS= ${LOCALBASE}/lib/libbfd.a:${PORTSDIR}/devel/libbfd \
- ${LOCALBASE}/lib/libiberty.a:${PORTSDIR}/devel/gnulibiberty
+ ${LOCALBASE}/lib/libiberty.a:${PORTSDIR}/devel/binutils
USE_BZIP2= yes
USES= perl5
Index: graphics/jbig2dec/Makefile
===
--- graphics/jbig2dec/Makefile (revision 340877)
+++ graphics/jbig2dec/Makefile (working copy)
@@ -24,7 +24,7 @@
LICENSE= GPLv3
-PNG_LIB_DEPENDS= libpng15.so:${PORTSDIR}/graphics/png
+PNG_LIB_DEPENDS= libpng15.so.15:${PORTSDIR}/graphics/png
PNG_CONFIGURE_ON= --with-libpng=${LOCALBASE}
PNG_CFLAGS=-I${LOCALBASE}/include/libpng15
Index: print/cups-base/Makefile
===
--- print/cups-base/Makefile(revision 340877)
+++ print/cups-base/Makefile(working copy)
@@ -94,6 +94,7 @@
PKGMESSAGE=${NONEXISTENT}
DESCR= ${MASTERDIR}/pkg-descr.client
.elif defined(CUPS_IMAGE)
+USES+= iconv
LIB_DEPENDS+= cups:${PORTSDIR}/${PKGCATEGORY}/cups-client \
jpeg:${PORTSDIR}/graphics/jpeg \
png15:${PORTSDIR}/graphics/png \
Index: print/freetype2/Makefile
===
--- print/freetype2/Makefile(revision 343536)
+++ print/freetype2/Makefile(working copy)
@@ -17,6 +17,7 @@
COMMENT= Free and portable TrueType font rendering engine
USE_BZIP2= yes
+USE_GCC= any
USES= gmake
MAKE_ENV= TOP=
USE_LDCONFIG= yes
@@ -51,5 +52,6 @@
post-install:
@${STRIP_CMD} ${STAGEDIR}${PREFIX}/lib/libfreetype.so.9
+ ln -s . ${STAGEDIR}${PREFIX}/include/freetype2/freetype
.include bsd.port.mk
Index: print/freetype2/pkg-plist
===
--- print/freetype2/pkg-plist (revision 343536)
+++ print/freetype2/pkg-plist (working copy)
@@ -4,6 +4,7 @@
include/freetype2/config/ftmodule.h
include/freetype2/config/ftoption.h
include/freetype2/config/ftstdlib.h
+include/freetype2/freetype
include/freetype2/freetype.h
include/freetype2/ft2build.h
include/freetype2/ftadvanc.h
Index: print/hplip-plugin/Makefile
===
--- print/hplip-plugin/Makefile (revision 340877)
+++ print/hplip-plugin/Makefile (working copy)
${WRKSRC}/plugin_install.py
do-install:
- cd ${WRKSRC} ${PYTHON_CMD} -B plugin_install.py
+ cd ${WRKSRC} ${PYTHON_CMD} -B plugin_install.py -i
.include bsd.port.post.mk
Index: x11/gdm/Makefile
===
--- x11/gdm/Makefile(revision 340877)
+++ x11/gdm/Makefile(working copy)
@@ -63,7 +63,7 @@
.include bsd.port.options.mk
.if
Requesting Committer Attention for ports/184011
I'd like to request that a committer take a gander at ports/184011 for me when possible. This is a pr I submitted three months ago and was never acted upon by the previous maintainer. 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
Re: Requesting Committer Attention for ports/184011 (Pkgng support in net-mgmt/nagios-check_ports)
On Sunday, 16 February 2014 at 20:08:28 -0600, Ryan Frederick wrote: I'd like to request that a committer take a gander at ports/184011 for me when possible. This is a pr I submitted three months ago and was never acted upon by the previous maintainer. Always a good idea to quote text that the maintainer might recognize, like I've done in the Subject: line. You can't expect every ports maintainer to go and look to see if it's his. Sorry, not my area. Greg -- Sent from my desktop computer. Finger g...@freebsd.org for PGP public key. See complete headers for address and phone numbers. This message is digitally signed. If your Microsoft MUA reports problems, please read http://tinyurl.com/broken-mua pgpwDEPP82O3s.pgp Description: PGP signature
[QAT] r344636: 1x configure_error, 1x depend (configure_error in www/firefox), 7x success, 3x leftovers
Update to 27.0.1 - Build ID: 20140216223200-30828 Job owner: b...@freebsd.org Buildtime: 4 hours Enddate: Mon, 17 Feb 2014 02:30:13 GMT Revision: r344636 Repository: https://svnweb.freebsd.org/ports?view=revisionrevision=344636 - Port:www/firefox 27.0.1,1 Buildgroup: 8.4-QAT/amd64 Buildstatus: CONFIGURE_ERROR Log: https://qat.redports.org//~b...@freebsd.org/20140216223200-30828-279020/firefox-27.0.1,1.log Buildgroup: 8.4-QAT/i386 Buildstatus: SUCCESS Log: https://qat.redports.org//~b...@freebsd.org/20140216223200-30828-279021/firefox-27.0.1,1.log Buildgroup: 9.2-QAT/amd64 Buildstatus: SUCCESS Log: https://qat.redports.org//~b...@freebsd.org/20140216223200-30828-279022/firefox-27.0.1,1.log Buildgroup: 9.2-QAT/i386 Buildstatus: SUCCESS Log: https://qat.redports.org//~b...@freebsd.org/20140216223200-30828-279023/firefox-27.0.1,1.log - Port:www/firefox-i18n 27.0.1 Buildgroup: 8.4-QAT/amd64 Buildstatus: DEPEND (CONFIGURE_ERROR IN WWW/FIREFOX) Log: https://qat.redports.org//~b...@freebsd.org/20140216223200-30828-279024/firefox-27.0.1,1.log Buildgroup: 8.4-QAT/i386 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~b...@freebsd.org/20140216223200-30828-279025/firefox-i18n-27.0.1.log Buildgroup: 9.2-QAT/amd64 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~b...@freebsd.org/20140216223200-30828-279026/firefox-i18n-27.0.1.log Buildgroup: 9.2-QAT/i386 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~b...@freebsd.org/20140216223200-30828-279027/firefox-i18n-27.0.1.log - Port:www/linux-firefox 27.0.1,1 Buildgroup: 8.4-QAT/amd64 Buildstatus: SUCCESS Log: https://qat.redports.org//~b...@freebsd.org/20140216223200-30828-279028/linux-firefox-27.0.1,1.log Buildgroup: 8.4-QAT/i386 Buildstatus: SUCCESS Log: https://qat.redports.org//~b...@freebsd.org/20140216223200-30828-279029/linux-firefox-27.0.1,1.log Buildgroup: 9.2-QAT/amd64 Buildstatus: SUCCESS Log: https://qat.redports.org//~b...@freebsd.org/20140216223200-30828-279030/linux-firefox-27.0.1,1.log Buildgroup: 9.2-QAT/i386 Buildstatus: SUCCESS Log: https://qat.redports.org//~b...@freebsd.org/20140216223200-30828-279031/linux-firefox-27.0.1,1.log -- Buildarchive URL: https://qat.redports.org/buildarchive/20140216223200-30828 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
ports-mgmt/pkg pkg-repo(8) does not catalogue latest package
Creating a repository catalogue with pkg repo ${repo_root} includes
only the OLDEST version of any package found in a directory below the
repository root. Perhaps I'm just not driving it properly?
When I build ports with portmaster, I pass the -g option so that
portmaster saves a (pkgng flavour) package of the port in
${repo_root}/All. After a ports tree upgrade, building the upgraded
ports and saving their packages in ${repo_root}/All, both the old and
new versions of the upgraded port's packages are present in that
directory. If I go to ${repo_root}, delete any existing repository
catalogue, and create a fresh one using pkg repo ${repo_root},
querying the fresh catalogue shows that only the older version of the
package has been included in the catalogue.
pkg-repo(8) states:
Symbolic links are ignored, and only the most recent package for
each origin is included in the catalogue.
The only way to get this to work seems to be deleting all but the
latest version of the package prior to creating the catalogue.
I have filed a PR (ports/186827)
--
John Marshall
pgpXwakXk5oz6.pgp
Description: PGP signature
Re: Requesting Committer Attention for ports/184011 (Pkgng support in net-mgmt/nagios-check_ports)
Thanks, I'll keep that in mind. I'm actually the new maintainer of net-mgmt/nagios-check_ports, and this is the last pr left over from the previous maintainer that needs to be closed out. Ryan On 2/16/14 8:15 PM, Greg 'groggy' Lehey wrote: On Sunday, 16 February 2014 at 20:08:28 -0600, Ryan Frederick wrote: I'd like to request that a committer take a gander at ports/184011 for me when possible. This is a pr I submitted three months ago and was never acted upon by the previous maintainer. Always a good idea to quote text that the maintainer might recognize, like I've done in the Subject: line. You can't expect every ports maintainer to go and look to see if it's his. Sorry, not my area. Greg -- Sent from my desktop computer. Finger g...@freebsd.org for PGP public key. See complete headers for address and phone numbers. This message is digitally signed. If your Microsoft MUA reports problems, please read http://tinyurl.com/broken-mua ___ 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
GSSAPI and Heimdal in Base
When building openssh-portable, and enabling kerb_gssapi, but using the heimdal that is in base, it gives the error: KERB_GSSAPI Requires either MIT or HEMIDAL, does not build with base Heimdal currently What is the difference between base and the port of Heimdal? ___ 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
