Re: git contrib install failed
Am 17.06.2013 22:46, schrieb Albert Shih:
Hi everyone
When I try to upgrade git I got this error in the installation (the ports
build work fine)
install -m 755 git-subtree /usr/local/libexec/git-core
asciidoc -b docbook -d manpage -f ../../Documentation/asciidoc.conf \
-agit_version=1.8.3.1 git-subtree.txt
xmlto -m ../../Documentation/manpage-normal.xsl man git-subtree.xml
xmlto: /usr/ports/devel/git/work/git-1.8.3.1/contrib/subtree/git-subtree.xml
does not validate (status 3)
xmlto: Fix document syntax or use --skip-validation option
I/O error : Attempt to load network entity
http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd
/usr/ports/devel/git/work/git-1.8.3.1/contrib/subtree/git-subtree.xml:2:
warning: failed to load external entity
http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd;
D DocBook XML V4.5//EN
http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd;
^
I/O error : Attempt to load network entity
http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd
warning: failed to load external entity
http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd;
validity error : Could not load the external subset
http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd;
Document
/usr/ports/devel/git/work/git-1.8.3.1/contrib/subtree/git-subtree.xml does
not validate
gmake: *** [git-subtree.1] Erreur 13
*** [post-install] Error code 2
Stop in /usr/ports/devel/git.
*** [reinstall] Error code 1
Without contrib everything work fine.
All my ports is up2date.
Regards.
JAS
Greetings,
This looks like devel/git should depend on Docbook XML 4.5 if and only
if contrib/ is enabled (I have not checked other stuff that is fed
through the asciidoc - xmlto processing chain).
xmlto would normally run _both_ the validator (xmllint) and the
formatter (xsltproc) with the --nonet option, so it cannot fetch the
DTD or whatever from oasis-open.org; instead, it (the Docbook XML data)
has to be installed locally.
Albert, Jonathan,
please install textproc/docbook-xml-450, then re-try installing Git with
CONTRIB, and report if that helps.
Wesley,
I propose the attached patch to devel/git to remedy this, and please run
a test build with CONTRIB enabled in a Tinderbox to see if there are any
other requisites that need to be listed additionally.
Best regards
Matthias
Index: Makefile
===
--- Makefile (Revision 321142)
+++ Makefile (Arbeitskopie)
@@ -328,7 +328,8 @@
.if ${PORT_OPTIONS:MCONTRIB}
PLIST_SUB+= CONTRIB=
BUILD_DEPENDS+= xmlto:${PORTSDIR}/textproc/xmlto \
- asciidoc:${PORTSDIR}/textproc/asciidoc
+ asciidoc:${PORTSDIR}/textproc/asciidoc \
+ ${LOCALBASE}/share/xml/docbook/4.5/docbookx.dtd:${PORTSDIR}/textproc/docbook-xml-450
MAN1+= git-subtree.1
.else
PLIST_SUB+= CONTRIB=@comment
signature.asc
Description: OpenPGP digital signature
distfile fetching vs ISP site-help spoofing: any suggestions?
I've just tried to portupgrade after a three-month hiatus and noticed a problem with the libgcrypt distfile checksum that didn't go away after my usual strategy of waiting for a couple of days, re-syncing the ports tree and trying again. Closer inspection and a hint from a google search revealed that the first-level problem is that the wrong file had been fetched: it was a short HTML file, rather than the expected tar.bz2 file. How did that happen? Apparently my ISP (Bigpond, in Australia) has recently turned on a site-helper mechanism that spoofs any site for which a DNS-lookup fails. That is, there are now no missing or expired sites. In this case, the first item in the ports/Mk/bsd.sites.mk list used by the security/libgcrypt Makefile is gnupg.org.favoritelinks.net which does not (any longer?) resolve. I've arranged to proceed by deleting the line in bsd.sites.mk, which allowed the fetch to succeed. This seems a bit lame though, because perhaps that site will come back one day. Seems like a fragile, non-scaling approach. It might be possible to subvert my ISP's evil helpfulness by pointing my DNS requests further upstream, but that might prevent the government from blocking my access to things it considers distasteful, and I'm not sure I want to go there just yet. Anyone have any suggestions or best practices? Should I try to raise a PR against bsd.sites.mk or security/libgcrypt? Cheers, -- Andrew ___ 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: distfile fetching vs ISP site-help spoofing: any suggestions?
On 18/06/2013 06:07, Andrew Reilly wrote: I've just tried to portupgrade after a three-month hiatus and noticed a problem with the libgcrypt distfile checksum that didn't go away after my usual strategy of waiting for a couple of days, re-syncing the ports tree and trying again. Closer inspection and a hint from a google search revealed that the first-level problem is that the wrong file had been fetched: it was a short HTML file, rather than the expected tar.bz2 file. How did that happen? Apparently my ISP (Bigpond, in Australia) has recently turned on a site-helper mechanism that spoofs any site for which a DNS-lookup fails. That is, there are now no missing or expired sites. In this case, the first item in the ports/Mk/bsd.sites.mk list used by the security/libgcrypt Makefile is gnupg.org.favoritelinks.net which does not (any longer?) resolve. Your ISP is screwing you over. Complain, loudly. Vote with your feet. There was a big to-do about this sort of behaviour around the BIND community a few years ago, and the overwhelming consensus was that not returning NXDOMAIN for a non-existent domain was simply wrong and an evil plot to monetize people's inaccurate typing. I've arranged to proceed by deleting the line in bsd.sites.mk, which allowed the fetch to succeed. This seems a bit lame though, because perhaps that site will come back one day. Seems like a fragile, non-scaling approach. It might be possible to subvert my ISP's evil helpfulness by pointing my DNS requests further upstream, but that might prevent the government from blocking my access to things it considers distasteful, and I'm not sure I want to go there just yet. Run your own recursive resolver instance. The default config for named in base is set up for this: pretty much all you need to do is turn on named and modify /etc/resolv.conf to say 'localhost' for your nameserver. Or use the Google nameservers -- 8.8.8.8 and 8.8.4.4 Anyone have any suggestions or best practices? Should I try to raise a PR against bsd.sites.mk or security/libgcrypt? No, don't do that. There's nothing wrong with bsd.sites.mk. The problem here is local to your site / ISP, and that's where you should look for a solution. Cheers, Matthew ___ 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/gegl won't build, was Re: Rebuild all ports for perl minor version update?
Same thing happened to me. I fixed it with: LC_ALL=en_US.UTF-8 LANG=en_US.UTF-8 portmaster -r perl I did not use both of them but I can't remember which one did the trick. Andrei Vrincianu Thanks for help, but the real answer came from my subsequent daily visit to http://www.freshports.org/commits.php I noticed an update in graphics/gegl, didn't know if it would fix the bug, but figured I'd try, starting with portsnap fetch update I ran portmaster first on gegl, then on the three ports that depend on gegl: successful. No need to run portmaster -r perl again, since most of the ports in question had already been rebuilt (all but four). Tom ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
texlive: tex-formats, tex-xetex - pkg check checksum mismatch
# pkg check -srda tex-formats-20120701_1: checksum mismatch for /usr/local/share/texmf-var/web2c/p dftex/cont-en.fmt tex-formats-20120701_1: checksum mismatch for /usr/local/share/texmf-var/web2c/p dftex/cont-en.log # Which goes away after rebuilding tex-formats, but new mismatch appears: # pkg check -srda tex-xetex-0.: checksum mismatch for /usr/local/share/texmf-var/web2c/xetex/c ont-en.fmt tex-xetex-0.: checksum mismatch for /usr/local/share/texmf-var/web2c/xetex/c ont-en.log # After rebuilding tex-xetex, I'm back to the first mismatch case: # pkg check -srda tex-formats-20120701_1: checksum mismatch for /usr/local/share/texmf-var/web2c/p dftex/cont-en.fmt tex-formats-20120701_1: checksum mismatch for /usr/local/share/texmf-var/web2c/p dftex/cont-en.log # Perhaps something is wrong with PLIST for tex-formats or tex-xetex? Or maybe with pkg check? Thanks Anton ___ 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
svn: E175002: REPORT of '/ports/!svn/me': Could not send request:
Hello. I'm fighting with a very strange problem on a box that is resembled of quite modern hardware. The /usr/ports folder is a dedicated UFS2 partition, I use SVN to update the ports tree. On this specific box (6 core Intel Core i7-3940K with 32 GB of RAM) I receive very often this error: -- Updating /usr/ports using Subversion -- cd /usr/ports; /usr/local/bin/svn update Updating '.': svn: E175002: REPORT of '/ports/!svn/me': Could not send request: Operation not permitted (http://svn.freebsd.org) *** Error code 1 Stop. make: stopped in /usr/ports Another box nearby, comprised from oldish Core2Duo hardware, attached to the same network, such an error never occurs. I have no idea whats going on here. Since I tried to swap network cabling (I suspected the network to be the faulty part) and changing the socket where the box is attached to the LAN and got never a salvation of the problem, I suspect the hardware of the box to have some trouble. I realise that disk drive access on this specific box is quite bumpy, although the box is fairly equipted with fast hardware, even modern WD Caviar BLACK harddrives (which are supposed to be fast). Maybe someone can shed some light on the fault with the subversion port update so I can investigate a bit further. Thanks, Oliver signature.asc Description: PGP signature
Re: svn mv and changing files at the same time: still prohibited
On 6/17/2013 9:18 AM, Alexey Dokuchaev wrote: Hi there, I've been trying to rename a port (games/rtcw - games/linux-rtcw) and had to change something inside port's Makefile at the same time (drop PORTEPOCH and PORTREVISION, and set PKGNAMEPREFIX accordingly), but commit was blocked by pre-commit hook with Do not replace a file. This can lose history. message. I was under impression that this is only true for CVS exporter, but since we no longer doing this, this hook should be removed. We've kept this to avoid losing easily-traceable history. The intent of this hook is to prevent a 'svn rm' and 'svn add' in the same commit where someone's intent was to 'undo' the removal. IIUC this would make 'svn log' on the file stop and require 'svn log file@old-rev' to continue. I've renamed and edited pkg-message file of that port just fine (in the previous revision), and all history is there, so I'm wondering what's so special about doing the same at the port-name level. ./danfe The issue is likely that the source you copied from was not fully up-to-date. I've seen 2 cases of this recently. Example situation: You committed an update in rtcw to Makefile. The directory was at revision X, the commit brought Makefile to Y. You then 'svn mv' rtcw to linux-rtcw, which copies X (dir) and Y (files). Separate revisions. The change to the Y files then is seen as a replacement by the python SVN API. Solution: Save your target changes, undo the move (revert rtcw), 'svn update' in rtcw, and mv again. Then copy in your changes and commit. Don't forget to 'svn add' any files as well. This should fix it. The hook is not intended to stop the situation you ran into. I do plan to look at it more and test on a local repository to find a solution. -- Regards, Bryan Drewery signature.asc Description: OpenPGP digital signature
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 +-+ textproc/y2l| 1.1 | 1.2 +-+ 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 If wish to stop receiving portscout reminders, please contact portsc...@portscout.freebsd.org 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
Re: svn mv and changing files at the same time: still prohibited
On Tue, Jun 18, 2013 at 07:22:31AM -0500, Bryan Drewery wrote: Solution: Save your target changes, undo the move (revert rtcw), 'svn update' in rtcw, and mv again. Then copy in your changes and commit. Don't forget to 'svn add' any files as well. This should fix it. Indeed, thanks for the hint! The culprit was that I 1st changed Makefile, *then* svn mv'ed, while I should have 'svn mv' first an updated, pristine directory, apply necessary changes, and finally commit. ./danfe ___ 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
Proposal: further OptionsNG improvements
Hi there, Now as I understand old-skool OPTIONS knob support is removed, can we do something about ugliness of newish OPTIONS_DEFINE[_arch]/OPTIONS_DEFAULT [_arch] pair of knobs? I am thinking about the following syntax (using now free-again OPTIONS knob, instead of several OPTIONS_DEFINE/OPTIONS_DEFAULT definitions): OPTIONS= FOO:on BAR ASM/i386,amd64:on,powerpc ... Ditto for OPTIONS_RADIO et al. This will also be kind of reminiscent to existing USE_AUTOCONF and recently added USES knob. It can get a bit hard to parse for architecture-specific options, but they appear relatively rare, yet for most cases new syntax seems cleaner to me. What do people think? I'd like to gather some opinions before trying to sit down and write a patch (unless someone(tm) beats me on it). ./danfe ___ 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
x11/lxpanel and clang
Forwarding to ports@ since kmoore just stopped maintaining the port. Hi. lxpanel doesn't build with clang on my 9.1-release i386 system. I saw this PR about it: https://www.freebsd.org/cgi/query-pr.cgi?pr=176650 but it still doesn't build with clang. Switching back to GCC lets it build, however. It should either be marked as requiring GCC or a real clang fix should be added (which I don't have at the moment). ___ 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: Proposal: further OptionsNG improvements
So we just got done porting most of the tree to a new options syntax and now we want to change it 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: x11/lxpanel and clang
On Tue, Jun 18, 2013 at 12:41:56PM -0400, Kenta Suzumoto wrote: Forwarding to ports@ since kmoore just stopped maintaining the port. Hi. lxpanel doesn't build with clang on my 9.1-release i386 system. I saw this PR about it: https://www.freebsd.org/cgi/query-pr.cgi?pr=176650 but it still doesn't build with clang. Switching back to GCC lets it build, however. It should either be marked as requiring GCC or a real clang fix should be added (which I don't have at the moment). By the time it was committed it worked with clang, tested in redports :) Fixed it in r321204. ___ 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: Proposal: further OptionsNG improvements
On Tue, Jun 18, 2013 at 11:56:07AM -0500, Mark Felder wrote: So we just got done porting most of the tree to a new options syntax and now we want to change it again? :-) Yeah, why not? ;-) I've discussed that idea before with bapt@ on IRC; there is absolutely no reasons why we should not use now-free nice, short OPTIONS knob again. Obviously, it will happen gradually, in a piece-meal fashion; just like with recently introduced FOO_*_DEPENDS stuff. No one is talking about converting all ports at once. I personally really don't like to have two, often duplicating, lists of OPTIONS_DEFINE and _DEFAULT, esp. given the fact that OPTIONS_DEFAULT tends to break indentation. ./danfe ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
FreeBSD Port: rubygem-chef-0.10.8_1
Hello, Are there any plans to upgrade to Chef 11 or make another port? Thanks! -- Douglas Thrift RightScale - Linux Systems Engineer douglas.thr...@rightscale.com http://www.rightscale.com/ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: net-mgmt/cflowd 2.1.b1 build failure
On Mon, June 17, 2013 10:47 pm, Mark Felder wrote: I just did a build of this in poudriere with no issues. I'd guess you have a dirty build environment. Can you post the contents of your make.conf? Had added the gcc lines to make.conf to build with gcc, now commented the gcc lines and compiled with clang. make.conf now looks like: # added by use.perl 2013-04-14 17:30:19 PERL_VERSION=5.14.2 WITH_PKGNG=yes #.if !empty(.CURDIR:M/usr/ports/*) exists(/usr/bin/gcc42) #CC=gcc #CXX=g++ #CPP=cpp #.endif The build failure now looks like: libtool: link: c++ -O2 -pipe -fno-strict-aliasing CflowdRawFlowClientList.o cflowdmux.o -o .libs/cflowdmux ../../classes/lib/.libs/libCfd.so -L/usr/local/lib /usr/local/lib/libArts.so ../../snmp++/classes/lib/.libs/libsnmp++.so -lfl -lcompat -Wl,-rpath -Wl,/usr/local/lib/cflowd -Wl,-rpath -Wl,/usr/local/lib ../../classes/lib/.libs/libCfd.so: undefined reference to `yyFlexLexer::yywrap()' c++: error: linker command failed with exit code 1 (use -v to see invocation) gmake[2]: *** [cflowdmux] Error 1 gmake[2]: Leaving directory `/usr/ports/net-mgmt/cflowd/work/cflowd-2-1-b1/apps/cflowdmux' gmake[1]: *** [cflowdmux] Error 2 gmake[1]: Leaving directory `/usr/ports/net-mgmt/cflowd/work/cflowd-2-1-b1/apps' gmake: *** [all] Error 2 *** Error code 1 Stop. make: stopped in /usr/ports/net-mgmt/cflowd *** Error code 1 Stop. make: stopped in /usr/ports/net-mgmt/cflowd thanks for looking.. -kim ___ 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
[HEADS UP] switch default xorg version in 9.1 and later
Hi!
It is time to switch the default version of xorg on FreeBSD 9.1 and
later, including CURRENT.
In general this means better support for modern hardware, especially
intel hardware, at the cost of support for some legacy hardware.
The old version will still be around, and be the default for FreeBSD
releases prior to 9.1, it is also possible to get the old version by
setting WITHOUT_NEW_XORG= in /etc/make.conf.
The attached patch will make the switch, and I intend to commit it ASAP
unless something major shows up. The patch is also available at
http://people.freebsd.org/~zeising/xorg-switch.diff
Regards!
--
Niclas Zeising
FreeBSD x11 team
PS. Please respect reply-to, to avoid too much cross posting.
Index: Mk/bsd.port.mk
===
--- Mk/bsd.port.mk (revision 321210)
+++ Mk/bsd.port.mk (working copy)
@@ -1214,6 +1214,15 @@
.endif
.endif
+# Enable new xorg for FreeBSD 9.1 and later unless WITHOUT_NEW_XORG is set.
+.if ${OSVERSION} = 901000
+.if !defined(WITHOUT_NEW_XORG)
+WITH_NEW_XORG?= yes
+.else
+.undef WITH_NEW_XORG
+.endif
+.endif
+
# Only define tools here (for transition period with between pkg tools)
.include ${PORTSDIR}/Mk/bsd.commands.mk
Index: emulators/virtualbox-ose-additions/Makefile
===
--- emulators/virtualbox-ose-additions/Makefile (revision 321210)
+++ emulators/virtualbox-ose-additions/Makefile (working copy)
@@ -3,7 +3,7 @@
PORTNAME= virtualbox-ose
DISTVERSION= 4.2.12
-PORTREVISION= 2
+PORTREVISION= 3
CATEGORIES= emulators kld
MASTER_SITES= http://download.virtualbox.org/virtualbox/${DISTVERSION}/ \
http://tmp.chruetertee.ch/ \
Index: graphics/dri/Makefile
===
--- graphics/dri/Makefile (revision 321210)
+++ graphics/dri/Makefile (working copy)
@@ -15,59 +15,44 @@
USES= pkgconfig
USE_XORG= glproto x11 xext xxf86vm xdamage xfixes dri2proto
+.include bsd.port.options.mk
+
+.if ${ARCH} == ia64
+BROKEN= does not install on ia64
+.endif
+
ALL_DRI_DRIVERS=I915 I965 R200 RADEON SWRAST
-.if ! defined(WITH_NEW_XORG)
+.if !defined(WITH_NEW_XORG)
ALL_DRI_DRIVERS+=I810 MACH64 MGA R128 R300 R600 SAVAGE SIS TDFX UNICHROME
.endif
.include ${.CURDIR}/../../graphics/libGL/bsd.mesalib.mk
-OPTIONS_DEFINE_i386= ${ALL_DRI_DRIVERS}
-OPTIONS_DEFINE_amd64= ${OPTIONS_DEFINE_i386}
+.if ${ARCH} == amd64 || ${ARCH} == i386
+DRI_DRIVERS= ${ALL_DRI_DRIVERS}
+.endif
.if defined(WITH_NEW_XORG)
-OPTIONS_DEFINE_powerpc= RADEON SWRAST
-OPTIONS_DEFINE_sparc64= RADEON SWRAST
-.else
-OPTIONS_DEFINE_powerpc= MACH64 RADEON SWRAST TDFX
-OPTIONS_DEFINE_sparc64= MACH64 RADEON SWRAST
+.if ${ARCH} == powerpc || ${ARCH} == sparc64
+DRI_DRIVERS= RADEON SWRAST
.endif
+.else # !defined(WITH_NEW_XORG)
+.if ${ARCH} == powerpc
+DRI_DRIVERS= MACH64 RADEON SWRAST TDFX
+.elif ${ARCH} == sparc64
+DRI_DRIVERS= MACH64 RADEON SWRAST
+.endif
+.endif # defined(WITH_NEW_XORG)
-OPTIONS_DEFAULT=${OPTIONS_DEFINE}
-
-I810_DESC= Include DRI support for Intel i810
-I915_DESC= Include DRI support for Intel i915
-I965_DESC= Include DRI support for Intel i965
-MACH64_DESC= Include DRI support for AMD/ATI Mach64
-MGA_DESC= Include DRI support for Matrox
-R128_DESC= Include DRI support for AMD/ATI R128
-R200_DESC= Include DRI support for AMD/ATI R200
-R300_DESC= Include DRI support for AMD/ATI R300
-R600_DESC= Include DRI support for AMD/ATI R600
-RADEON_DESC= Include DRI support for AMD/ATI RADEON
-SAVAGE_DESC= Include DRI support for S3/Via Savage
-SIS_DESC= Include DRI support for SiS 300 and 6326
-SWRAST_DESC= Include generic software DRI support
-TDFX_DESC= Include DRI support for 3dfx Voodoo
-UNICHROME_DESC= Include DRI support for S3/Via Unichrome
-
-.include bsd.port.options.mk
-
-DRI_DRIVERS=
.for _d in ${ALL_DRI_DRIVERS}
-.if ${PORT_OPTIONS:M${_d}}
-DRI_DRIVERS+= ${_d}
+.if ${DRI_DRIVERS:M${_d}}
PLIST_SUB+= ${_d}_DRIVER=
.else
PLIST_SUB+= ${_d}_DRIVER=@comment
.endif
.endfor
-.if ${ARCH} == ia64
-BROKEN= does not install on ia64
-.endif
-
.if !(${ARCH} == amd64 || ${ARCH} == i386)
CONFIGURE_ARGS+=--disable-gallium-intel
.endif
Index: graphics/libGL/Makefile
===
--- graphics/libGL/Makefile (revision 321210)
+++ graphics/libGL/Makefile (working copy)
@@ -23,12 +23,12 @@
post-install:
@PKG_PREFIX=${PREFIX} ${SH} ${PKGINSTALL} ${PKGNAME} POST-INSTALL
+.include bsd.port.options.mk
+
.include ${.CURDIR}/bsd.mesalib.mk
-.include bsd.port.pre.mk
-
.if !(${ARCH} == amd64 || ${ARCH} == i386)
CONFIGURE_ARGS+=--disable-gallium-intel
.endif
-.include bsd.port.post.mk
+.include bsd.port.mk
Index: graphics/libGLU/Makefile
===
--- graphics/libGLU/Makefile (revision 321210)
+++ graphics/libGLU/Makefile (working copy)
@@ -2,21 +2,19 @@
# $FreeBSD$
PORTNAME= libGLU
-PORTVERSION=
Re: Proposal: further OptionsNG improvements
On Tue, Jun 18, 2013 at 10:12 AM, Alexey Dokuchaev da...@freebsd.orgwrote: On Tue, Jun 18, 2013 at 11:56:07AM -0500, Mark Felder wrote: So we just got done porting most of the tree to a new options syntax and now we want to change it again? :-) Yeah, why not? ;-) I've discussed that idea before with bapt@ on IRC; there is absolutely no reasons why we should not use now-free nice, short OPTIONS knob again. Obviously, it will happen gradually, in a piece-meal fashion; just like with recently introduced FOO_*_DEPENDS stuff. No one is talking about converting all ports at once. I personally really don't like to have two, often duplicating, lists of OPTIONS_DEFINE and _DEFAULT, esp. given the fact that OPTIONS_DEFAULT tends to break indentation. ./danfe Perhaps your proposal would carry more weight, feedback and/or testing results if it included a patch and an example port with the modified values for your new idea. This has been quiet successful in the recent past with bapt's proposals for options, uses, etc. -jgh -- Jason Helfman | FreeBSD Committer j...@freebsd.org | http://people.freebsd.org/~jgh | The Power to Serve ___ 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] r321211: 4x leftovers
Add security/fbopenssl, a library containing extensions to OpenSSL, including support for GSS-API (RFC 2743) and SPNEGO (RFC 2478). - Build ID: 20130618184200-37411 Job owner: h...@freebsd.org Buildtime: 100 minutes Enddate: Tue, 18 Jun 2013 20:22:00 GMT Revision: r321211 Repository: https://svnweb.freebsd.org/ports?view=revisionrevision=321211 - Port:security/fbopenssl 0.0.4 Buildgroup: 9.1-QAT/amd64 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~h...@freebsd.org/20130618184200-37411-153064/fbopenssl-0.0.4.log Buildgroup: 9.1-QAT/i386 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~h...@freebsd.org/20130618184200-37411-153065/fbopenssl-0.0.4.log Buildgroup: 8.4-QAT/amd64 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~h...@freebsd.org/20130618184200-37411-153066/fbopenssl-0.0.4.log Buildgroup: 8.4-QAT/i386 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~h...@freebsd.org/20130618184200-37411-153067/fbopenssl-0.0.4.log -- Buildarchive URL: https://qat.redports.org/buildarchive/20130618184200-37411 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: git contrib install failed
Le 18/06/2013 ? 09:02:25+0200, Matthias Andree a ?crit Am 17.06.2013 22:46, schrieb Albert Shih: Hi, Thanks you very much. This looks like devel/git should depend on Docbook XML 4.5 if and only if contrib/ is enabled (I have not checked other stuff that is fed through the asciidoc - xmlto processing chain). xmlto would normally run _both_ the validator (xmllint) and the formatter (xsltproc) with the --nonet option, so it cannot fetch the DTD or whatever from oasis-open.org; instead, it (the Docbook XML data) has to be installed locally. Albert, Jonathan, please install textproc/docbook-xml-450, then re-try installing Git with CONTRIB, and report if that helps. It's working perfectly. When I see the error I suspect something like that, but I install textproc/docbook-450...:-( Regards. JAS -- Albert SHIH DIO bâtiment 15 Observatoire de Paris 5 Place Jules Janssen 92195 Meudon Cedex France Téléphone : +33 1 45 07 76 26/+33 6 86 69 95 71 xmpp: j...@obspm.fr Heure local/Local time: mar 18 jui 2013 23:13:11 CEST ___ 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
gccmakedep fix - 20130619
Hi all!
Attached a fix to gccmakedep.
diff --git a/devel/gccmakedep/Makefile b/devel/gccmakedep/Makefile
index b7e8cf6..07c3ef3 100644
--- a/devel/gccmakedep/Makefile
+++ b/devel/gccmakedep/Makefile
@@ -20,6 +20,7 @@ PLIST_FILES= bin/gccmakedep
.if (${OSVERSION} = 900506 ${OSVERSION} 100) || \
${OSVERSION} = 110
CONFIGURE_ENV+= ac_cv_path_RAWCPP=gcpp
+.endif
post-patch:
@${REINPLACE_CMD} 's/test.*-traditional.*;/true;/' ${WRKSRC}/configure
___
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: gccmakedep fix - 20130619
On 6/19/2013 01:00, Oliver Pinter wrote: Hi all! Attached a fix to gccmakedep. So 1) There's already multiple PRs on this, including one I just submitted: http://www.freebsd.org/cgi/query-pr.cgi?pr=179571 2) Your patch adds an .endif which is already there 3) Is not it better to submit via PR (GNATS) rather than a mailing list? That's what PRs are for... John ___ 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: gccmakedep fix - 20130619
On 6/19/13, John Marino dragonfly...@marino.st wrote: On 6/19/2013 01:00, Oliver Pinter wrote: Hi all! Attached a fix to gccmakedep. So 1) There's already multiple PRs on this, including one I just submitted: http://www.freebsd.org/cgi/query-pr.cgi?pr=179571 2) Your patch adds an .endif which is already there Hmm.. now I checked in github too: https://github.com/freebsd/freebsd-ports/blob/master/devel/gccmakedep/Makefile . Sure. Then my local git repo was broken. 3) Is not it better to submit via PR (GNATS) rather than a mailing list? That's what PRs are for... Mail are faster than PR-s. John ___ 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: gccmakedep fix - 20130619
On Wed, Jun 19, 2013 at 01:51:42AM +0200, Oliver Pinter wrote: 3) Is not it better to submit via PR (GNATS) rather than a mailing list? That's what PRs are for... Mail are faster than PR-s. If we all go down that route, it means less and less people will try to read all the traffic on ports@. Please, use the PR database for what's it's intended for. Thanks. mcl ___ 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: Graphite and products
Myfriend:ThisisMr.PotterfromTE.GWgroup.DoyoustillinneedofGraphiteamp;products?wecansendyoufreesamples.Wecanproviderawmaterial,andfinalproductsasperdrawings.WeareacarbongroupinChina,specialisingintheproductionofgraphitematerialandproducts.Ourproductsasbelow:1).Isostaticgraphite.(rods,blocks,plates,sheets,purified..)2).Extrudedgraphite/Vibrationgraphite(GSK,TSK,VSK..)3).Resinimpregnatedgraphitetube/pipe.4).GraphiteFoil/Sheet/Tape/Gasket..5).Mechanicalcarbongraphite.6).CarbonandGraphiteFelt.(softfelts,rigidgraphitefelt,insulationgraphiteboard,PAN,RAYON..)7).Graphiteproducts(CNC,asperdrawings..)8).Carboncarboncomposite,CFC,C/C.moretosee:www.cfccarbon.comWehavecustomersallovertheworld,andwehaveagoodreputaioninthisarea.Moredetails,pleasecontactusdirectly:hicl...@gmail.com;hicl...@hotmail.com-Mr.PotterEmail:hiclsun@gmail.comMSN:hiclsun@hotmail.comTE.GWGROUPLTDAddress:Yizhuangeconomicdevelopmentzone,DaxingDistrict,Beijing,China.Postcode:100176 Tel:+86-158-01541818Fax:+86-10-59767783Cell:+86-15801541818 ___ 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: net/remmina-plugin-rdp is broken by net/freerdp
Hello! Koichiro IWAO さんは書きました: it seems that remmina and remmina-plugins also need to be updated. I will try to do it. I tried to fix the problem too, but without success... The library naming in new freerdp changed significantly. Perhaps, You have more achievements? --- With the best regards, Dmitry Kroupenier. ___ 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: net/remmina-plugin-rdp is broken by net/freerdp
2013-06-19 14:40 Dmitry V. Kroupenier : I tried to fix the problem too, but without success... The library naming in new freerdp changed significantly. Perhaps, You have more achievements? Yes. It is difficult to fit old remmina with new freerdp. Thus I've updated to remmina to the newer version, 1.0.0. I've already sent patches. See ports/177962. http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/177962 Or, please checkout my redports repository to get the port improved. $ svn co https://svn.redports.org/meta/net/ -- `whois vmeta.jp | nkf -w` meta m...@vmeta.jp ___ 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
