Re: sysutils/bbcp: Anyone interesting in helping upgrade this port?
Kurt Jaeger wrote at 20:29 +0100 on Jan 13, 2015: I checked out (cloned) the master branch, and looked it over. This will be an easy upgrade, and I'll be happy to do it. Should the maintainer not mind, that is. ;) I don't think he will (as can be seen from PR 192405). Provide a PR with the patch and I'll commit it after testing the build. I'll update it if no one else gets to it this week or review a PR. Willing to hand it over if someone wants it. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
env: NO_PIE: No such file or directory
I'm seeing this after updating my ports tree (to r356864): . . === Building for openjdk6-b31_3,1 env: NO_PIE: No such file or directory . . Commenting out the recent MAKE_ENV+=NO_PIE in bsd.port.mk got me going forward. Maybe it should be MAKE_ENV+=NO_PIE=yes although I didn't find a reference to this knob anywhere yet in order to confirm that. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
[patch] graphics/libwmf - fix stage as non-root use OPTIONS helpers
Submitter-Id: current-users
Originator:John Hein
Organization:
Confidential: no
Synopsis: [patch] graphics/libwmf - fix stage as non-root use OPTIONS
helpers
Severity: non-critical
Priority: low
Category: ports
Class: change-request
Release:
Environment:
Description:
part 1
==
The ${CHOWN} in the post-install in print/ghostscript9/Makefile is not
needed - the created package specifies @owner root for packages that
have been created via the staging process.
Without this change, 'make stage' fails as a regular user (noticed
when using portmaster with PM_SU_CMD=/usr/local/bin/sudo).
part 2
==
Update port to use OPTIONS helpers. No change in functionality.
Maybe this should have been 2 PRs. Commit the changes in two commits
as desired.
How-To-Repeat:
Fix:
No need to bump portrevision.
patch for part 1:
===
Index: Makefile
===
--- Makefile(revision 351530)
+++ Makefile(working copy)
@@ -57,7 +57,6 @@
@${MKDIR} ${STAGEDIR}${DOCSDIR}
@${TAR} -C ${WRKSRC}/doc --exclude '*Makefile*' -cf - . | \
${TAR} -C ${STAGEDIR}${DOCSDIR} --unlink -xf -
- @${CHOWN} -R ${SHAREOWN}:${SHAREGROUP} ${STAGEDIR}${DOCSDIR}
.endif
.include bsd.port.mk
===
patch for part 2:
===
Index: Makefile
===
--- Makefile(revision 351530)
+++ Makefile(working copy)
@@ -29,20 +29,13 @@
OPTIONS_DEFINE=X11
OPTIONS_DEFAULT=X11
+OPTIONS_SUB= X11
+X11_USE= XORG=x11
+X11_CONFIGURE_OFF= --with-x=no
+
.include bsd.port.options.mk
-.if ${PORT_OPTIONS:MX11}
-USE_XORG= x11
-PLIST_SUB+=X11=
-CONFLICTS+=libwmf-nox11-0.*
-.else
-PKGNAMESUFFIX= -nox11
-CONFIGURE_ARGS+= --with-x=no
-PLIST_SUB+=X11=@comment
-CONFLICTS+=libwmf-0.*
-.endif
-
post-patch:
@${REINPLACE_CMD} -e 's|src include fonts doc|src include fonts|g' \
${WRKSRC}/Makefile.in
===
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Error build the port devel/glib20
Guido Falsi wrote at 09:05 +0100 on Feb 8, 2014: On 02/08/14 02:20, John Hein wrote: Vladislav Prodan wrote at 02:18 +0200 on Feb 8, 2014: # uname -a FreeBSD vm-10-1.domain.com 10.0-STABLE FreeBSD 10.0-STABLE #0 r261419: Mon Feb 3 02:57:25 UTC 2014 r...@grind.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64 make BATCH=yes MAKE_JOBS_UNSAFE=yes WITH_COLLATION_FIX=yes install -C /usr/ports/devel/glib20 gmake[5]: Entering directory `/usr/ports/devel/glib20/work/glib-2.36.3/glib' CC libglib_2_0_la-gallocator.lo ... CC libglib_2_0_la-gconvert.lo gconvert.c:66:2: error: GNU libiconv not in use but included iconv.h is from libiconv #error GNU libiconv not in use but included iconv.h is from libiconv ^ See the 20130904 entry in ports/UPDATING While the entry is relevant commit 341775 changed the situation a bit. The patch in PR ports/186295 [1] should be helpful in this case. [1] http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/186295 Fair enough. There aren't many ports using this feature from 341775 (and thus pulling in converters/libiconv) on 10.x yet. If the OP doesn't have one of those ports in place, the effects of the note in UPDATING should be in force. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Error build the port devel/glib20
Vladislav Prodan wrote at 02:18 +0200 on Feb 8, 2014: # uname -a FreeBSD vm-10-1.domain.com 10.0-STABLE FreeBSD 10.0-STABLE #0 r261419: Mon Feb 3 02:57:25 UTC 2014 r...@grind.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64 make BATCH=yes MAKE_JOBS_UNSAFE=yes WITH_COLLATION_FIX=yes install -C /usr/ports/devel/glib20 gmake[5]: Entering directory `/usr/ports/devel/glib20/work/glib-2.36.3/glib' CC libglib_2_0_la-gallocator.lo ... CC libglib_2_0_la-gconvert.lo gconvert.c:66:2: error: GNU libiconv not in use but included iconv.h is from libiconv #error GNU libiconv not in use but included iconv.h is from libiconv ^ See the 20130904 entry in ports/UPDATING ___ 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: Installing ports without info files
Ian Lepore wrote at 14:53 -0600 on Sep 16, 2013: On Mon, 2013-09-16 at 21:50 +0200, Mattia Rossi wrote: Hi all, I've build a world with the following constraints: -DWITHOUT_INFO -DWITHOUT_MAN -DWITHOUT_SHAREDOCS -DWITHOUT_EXAMPLES -DWITHOUT_HTML as I don't need that stuff. Turns out, this prevents tools like install-info being built. Now trying to build devel/gettext I can't get it installed, as it always wants to install info files using install-info, which of course fails. How do I tell the system not to build info files (or manpages or all of the stuff above I don't want in the first place) when building ports? I've tried with make -DWITHOUT_INFO install as well as with putting WITHOUT_INFO=yes in make.conf. Gettext will still fail to install. Is this a gettext problem? Or a generic ports problem? I'm running current on arm (thanks again to freebsd-arm people for fixing it): FreeBSD dreamplug 10.0-ALPHA1 FreeBSD 10.0-ALPHA1 #15 r255499M: It's also not possible to make index for INDEX-10 if you use a stripped-down ports tree (none of the language ports), as there are some dependencies in the tree to french (cad-astk) and russian (stardict-*) which obviously can't be resolved. Help is appreciated! Cheers, I fought with the info problem for a few hours at $work and never got it resolved, I had to remove the WITHOUT_INFO so that the tools would be there to let ports build, and then rely on an mtree pruning script to keep the actual info files out of the filesystem image. -- Ian I have a patch for this that was going to go through a ports run, but stalled in the machine. I'll dig it out. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: HELP! nvidia-driver patch: Weird REPLACE_CMD and command-line-sed behaviour. HELP!
O. Hartmann wrote at 01:51 +0200 on Sep 10, 2013:
sed -i -e 's/\(\virtual_address, size,\) \(VMFS_ANY_SPACE,\)$/ \
\1 0, \2/' work/NVIDIA-FreeBSD-x86_64-325.15/src/nvidia_subr.c
In a makefile shell command, you have to escape $ signs
if you want them to be used as $ signs in the shell context.
.
.
But putting the very same
sed-expression into the port's Makefile
# Changes in vm_map_find() due to r255426
..if ${OSVERSION} 153
${REINPLACE_CMD} -e 's/\(\virtual_address, size,\) \
\(VMFS_ANY_SPACE,\)$/\1 0, \2/' \
\ ${WRKSRC}/src/nvidia_subr.c
..endif
(patch attached) gives this weird error:
=== Cleaning for nvidia-driver-325.15
=== License NVIDIA accepted by the user
=== Found saved configuration for nvidia-driver-325.08_1
=== nvidia-driver-325.15 depends on file: /usr/local/sbin/pkg - found
=== Fetching all distfiles required by nvidia-driver-325.15 for
building === Extracting for nvidia-driver-325.15
= SHA256 Checksum OK for NVIDIA-FreeBSD-x86_64-325.15.tar.gz.
=== Patching for nvidia-driver-325.15
sed: 1: s/\(\virtual_address, ...: unescaped newline inside
substitute pattern *** Error code 1
make(1) evaluates $/ - which is likely empty which is why sed doesn't
see the end of the expression before the newline. Hence the
weird error (not so weird once it's understood).
You want to use $$/ instead of $/ :
.if ${OSVERSION} 153
${REINPLACE_CMD} -e 's/\(\virtual_address, size,\) \
\(VMFS_ANY_SPACE,\)$$/\1 0, \2/' \
\ ${WRKSRC}/src/nvidia_subr.c
.endif
___
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: HELP! nvidia-driver patch: Weird REPLACE_CMD and command-line-sed behaviour. HELP!
John Hein wrote at 10:07 -0600 on Sep 10, 2013:
O. Hartmann wrote at 17:55 +0200 on Sep 10, 2013:
On Tue, 10 Sep 2013 09:50:05 -0600
John Hein jh...@symmetricom.com wrote:
Actually I should have said you want:
.if ${OSVERSION} 155
The API change to vm_map_find was made between shortly before 155.
I'm on FreeBSD 10.0-CURRENT #1 r255434: Tue Sep 10 02:01:02 CEST 2013
amd64 and when calling
make -VOSVERSION in x11/nvidia-driver I receive
154
You are in an unfortunate window between the moment the API change was
committed (255426) and the OSVERSION was bumped (255449). That
shouldn't happen ideally, but sometimes it does. The backward gap
from 255426 to the last bump (255321) is larger than the forward
gap, and in absence of better guidance, you should generally pick the
OSVERSION larger than a particular API change to key off.
Your false 154 is really 155 in spirit, but human committers
just didn't catch on until a bit later. So you have to pick the
lesser of two evils - which I am claiming is 155.
So if you buy that argument, I have a correction. What I meant was:
.if ${OSVERSION} 154
(I had = 155 in my head)
___
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: HELP! nvidia-driver patch: Weird REPLACE_CMD and command-line-sed behaviour. HELP!
O. Hartmann wrote at 17:55 +0200 on Sep 10, 2013:
On Tue, 10 Sep 2013 09:50:05 -0600
John Hein jh...@symmetricom.com wrote:
Actually I should have said you want:
.if ${OSVERSION} 155
The API change to vm_map_find was made between shortly before 155.
I'm on FreeBSD 10.0-CURRENT #1 r255434: Tue Sep 10 02:01:02 CEST 2013
amd64 and when calling
make -VOSVERSION in x11/nvidia-driver I receive
154
You are in an unfortunate window between the moment the API change was
committed (255426) and the OSVERSION was bumped (255449). That
shouldn't happen ideally, but sometimes it does. The backward gap
from 255426 to the last bump (255321) is larger than the forward
gap, and in absence of better guidance, you should generally pick the
OSVERSION larger than a particular API change to key off.
Your false 154 is really 155 in spirit, but human committers
just didn't catch on until a bit later. So you have to pick the
lesser of two evils - which I am claiming is 155.
___
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: HELP! nvidia-driver patch: Weird REPLACE_CMD and command-line-sed behaviour. HELP!
O. Hartmann wrote at 16:26 +0200 on Sep 10, 2013:
On Tue, 10 Sep 2013 08:16:18 -0600
John Hein jh...@symmetricom.com wrote:
You want to use $$/ instead of $/ :
.if ${OSVERSION} 153
${REINPLACE_CMD} -e 's/\(\virtual_address, size,\) \
\(VMFS_ANY_SPACE,\)$$/\1 0, \2/' \
\ ${WRKSRC}/src/nvidia_subr.c
.endif
if things are understood, there s nothing scaring. Thanks, I didn't
realize that even the expression inside '' is eavluated by make.
Thanks to you I could provide the patch to my PR. Hopefuilly, there is
a committer soon.
Actually I should have said you want:
.if ${OSVERSION} 155
The API change to vm_map_find was made between shortly before 155.
___
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: astro/xearth on redports with clang: /usr/local/lib/X11/config/FreeBSD.cf:451:35: error: '#' is not followed by a macro parameter
Dimitry Andric wrote at 17:09 +0200 on Sep 25, 2012: On 2012-09-25 16:38, Anton Shterenlikht wrote: ... $ grep -c imake /usr/ports/INDEX-10 291 That's a relatively low number, indeed. :) This issue must cause problems for quite a few other ports. So is it an agreed policy to migrate away from imake in time for 10-release? Imake is obsolete, X.org migrated to autoconf+gmake a long time ago, and new software should avoid it. That said, for old software, you could just add a dependency on one of the gcc ports, or maybe use another C preprocessor that supports -traditional mode. I understood ucpp might be able to do the job. You could also raise a discussion with the clang folks. If it's really legitimate preprocessor syntax, clang/cpp could be fixed perhaps. ___ 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: Fix nvidia-like ports, help needed
Baptiste Daroussin wrote at 11:28 + on Feb 23, 2012: On 23.02.2012 08:34, Alexander Leidinger wrote: Do you havea list of packages which overzrite something, respectively do you have a list of files which are overwriten? If we just talk about the nvidia lib, installing the mesa and nvidia ones into subdirectories and asking to add (or adding automatically/optionally) ldconfig_paths=$ldconfig_paths /usr/local/lib/port-gl/ to rc.conf could be an option. Currently, no I don't have a list of packages that overwrite things, anyway way I do really like this kind of solution, I don't know yet how this can be automated, it really looks the right way. If the nvidia libGL can be dynamically linked with, say, a vnc server, and have it be a drop in replacement for the mesa libGL, then ldconfig_paths would be fine. If not, then those apps which need the mesa libGL would need to link with -rpath perhaps to point at the right libGL (or pass appropriate path info to those apps that might use dlopen(3)). ___ 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
[PATCH] astro/gpstk: update to 1.7
Submitter-Id: current-users
Originator:John Hein
Organization:
Confidential: no
Synopsis: [PATCH] astro/gpstk: update to 1.7
Severity: non-critical
Priority: low
Category: ports
Class: update
Release:
Environment:
Description:
- Update astro/gpstk to 1.7
ChangeLog says it was released 2010-10-08, although the tarball
is dated 2011-02-21.
I am willing to take maintainer role.
ChangeLog:
http://sourceforge.net/projects/gpstk/files/gpstk/1.7/ChangeLog/download
Removed file(s):
- files/patch-Jamrules
- files/patch-apps::checktools::ficacheck.cpp
- files/patch-apps::checktools::ficcheck.cpp
- files/patch-apps::checktools::rmwcheck.cpp
- files/patch-apps::checktools::rnwcheck.cpp
- files/patch-apps::checktools::rowcheck.cpp
- files/patch-lib-rxio-NovatelData.cpp
- files/patch-lib-rxio-NovatelData.hpp
- files/patch-src-MiscMath.hpp
- files/patch-src-getopt.c
Generated with FreeBSD Port Tools 0.99
How-To-Repeat:
Fix:
--- gpstk-1.7.patch begins here ---
Index: Makefile
===
RCS file: /base/FreeBSD-CVS/ports/astro/gpstk/Makefile,v
retrieving revision 1.13
diff -u -p -u -r1.13 Makefile
--- Makefile14 Sep 2010 16:20:23 - 1.13
+++ Makefile14 Feb 2012 06:56:34 -
@@ -6,47 +6,43 @@
#
PORTNAME= gpstk
-PORTVERSION= 1.5
-PORTREVISION= 1
+PORTVERSION= 1.7
CATEGORIES=astro devel
MASTER_SITES= SF
-DISTNAME= ${PORTNAME}${PORTVERSION}.src
+DISTNAME= ${PORTNAME}-${PORTVERSION}.src
-MAINTAINER=po...@freebsd.org
+MAINTAINER=jh...@symmetricom.com
COMMENT= Toolkit for developing GPS applications
-BUILD_DEPENDS= ${LOCALBASE}/bin/jam:${PORTSDIR}/devel/jam
+BUILD_DEPENDS= jam:${PORTSDIR}/devel/jam
-WRKSRC=${WRKDIR}/${PORTNAME}${PORTVERSION}
+WRKSRC=${WRKDIR}/${PORTNAME}
USE_PYTHON_RUN=yes
USE_LDCONFIG= yes
-JAM= ${LOCALBASE}/bin/jam
+JAM= jam
JAM_ENV= PREFIX=${PREFIX} \
BINDIR=${PREFIX}/bin \
- INCDIR=${PREFIX}/include/$(PORTNAME) \
+ INCDIR=${PREFIX}/include/${PORTNAME} \
LIBDIR=${PREFIX}/lib \
CC=${CC} CCFLAGS=${CFLAGS} \
- C++=${CXX} C++FLAGS=${CXXFLAGS} \
- OPTIM=-DHAVE_UINTPTR_T
-
-post-patch:
- @${REINPLACE_CMD} -e \
- 's|python2.5|python|g' ${WRKSRC}/apps/reszilla/ordPlot
+ C++=${CXX} C++FLAGS=${CXXFLAGS}
do-build:
cd ${WRKSRC} ${SETENV} ${JAM_ENV} ${JAM}
+NOSTRIPFILES= ddPlot|ordPlot # don't strip scripts
+SHLIBS=geodyn geomatics gpstk procframe rxio vdraw vplot
+SHLIBVER= ${PORTVERSION:C/.//g}
do-install:
@${MKDIR} ${PREFIX}/include/${PORTNAME}
cd ${WRKSRC} ${SETENV} ${JAM_ENV} ${JAM} install
-.for shlib in geomatics gpstk procframe rxio vplot
- @${LN} -sf lib${shlib}.so.15 ${PREFIX}/lib/lib${shlib}.so
+.for shlib in ${SHLIBS}
+ @${LN} -sf lib${shlib}.so.${SHLIBVER} ${PREFIX}/lib/lib${shlib}.so
.endfor
- @${STRIP_CMD} `${CAT} ${PLIST} | \
-${GREP} '^bin/' | \
-${GREP} -E -v 'ddPlot$$|mdpscreen$$|ordPlot$$' | \
-${SED} 's:^bin/:${PREFIX}/bin/:g'`
+ @${STRIP_CMD} `${GREP} '^bin/' ${PLIST} | \
+${GREP} -E -v '^bin/(${NOSTRIPFILES})$$' | \
+${SED} 's:^:${PREFIX}/:g'`
.include bsd.port.mk
Index: distinfo
===
RCS file: /base/FreeBSD-CVS/ports/astro/gpstk/distinfo,v
retrieving revision 1.4
diff -u -p -u -r1.4 distinfo
--- distinfo19 Mar 2011 12:27:32 - 1.4
+++ distinfo9 Feb 2012 23:02:42 -
@@ -1,2 +1,2 @@
-SHA256 (gpstk1.5.src.tar.gz) =
2bc699d9eb8d9774fa6a635e0f75da2f38c00e1b700974fe9197b8ba7c867277
-SIZE (gpstk1.5.src.tar.gz) = 7050592
+SHA256 (gpstk-1.7.src.tar.gz) =
56f234d33b67011794612a132e84c204078ae50db223dfecadbf45301bce0373
+SIZE (gpstk-1.7.src.tar.gz) = 22837053
Index: pkg-plist
===
RCS file: /base/FreeBSD-CVS/ports/astro/gpstk/pkg-plist,v
retrieving revision 1.4
diff -u -p -u -r1.4 pkg-plist
--- pkg-plist 23 May 2009 14:23:32 - 1.4
+++ pkg-plist 10 Feb 2012 03:55:14 -
@@ -1,13 +1,19 @@
+@comment $FreeBSD$
+bin/CalcDOPs
+bin/ConstellationList
bin/DDBase
+bin/DOPcalc
bin/DiscFix
bin/EditRinex
bin/IonoBias
bin/NavMerge
+bin/ORDPhaseParser
bin/PRSolve
bin/ResCor
bin/RinSum
bin/RinexDump
bin/TECMaps
+bin/TIAPhaseParser
bin/ash2mdp
bin/ash2xyz
bin/ats2mdp
@@ -15,11 +21,15 @@ bin/bc2sp3
bin/calgps
bin/compSatVis
bin/compStaVis
+bin/convertSSEph
bin/daa
+bin/dallandev
bin/ddGen
bin/ddPlot
bin/ddmerge
bin/ephdiff
+bin/ephsum
+bin/ffp
bin/fic2rin
bin/ficacheck
bin/ficafic
@@ -27,10 +37,10 @@ bin/ficcheck
bin/ficdiff
bin/ficfica
bin/findMoreThan12
+bin/lsfilt
+bin/mallandev
bin/mdp2rinex
[PATCH] ports-mgmt/porttools: add submit -P to print PR
Submitter-Id: current-users
Originator:John Hein
Organization:
Confidential: no
Synopsis: [PATCH] ports-mgmt/porttools: add submit -P to print PR
Severity: non-critical
Priority: low
Category: ports
Class: change-request
Release:
Environment:
Description:
Add -P to print PR to stdout instead of submitting. This allows the
sender to verify the PR before sending and possibly save the output to
paste into a mail client when an automated mailer (sendmail or some
other mailer to stuff in MAIL_AGENT) is unavailable or impractical to
use.
Also fix the comment in patch-cmd_submit.in that said support for
PORTEPOCH was added (looks like all of ports/154809 was not applied).
However it would probably be simpler to just remove the
PORTREVISION/PORTVERSION/PORTEPOCH logic used in port/154809 and just
use PKGNAME instead.
I'm ignoring the whitespace style mistakes in the PORTREVISION change
in patch-cmd_submit.in, but the committer could fix that if she feels
so inclined (and doesn't just refactor to use PKGNAME).
Added file(s):
- files/patch-port.1
Generated with FreeBSD Port Tools 0.99
How-To-Repeat:
Fix:
--- porttools-0.99_3.patch begins here ---
Index: Makefile
===
RCS file: /base/FreeBSD-CVS/ports/ports-mgmt/porttools/Makefile,v
retrieving revision 1.28
diff -u -p -u -r1.28 Makefile
--- Makefile30 Oct 2011 20:29:53 - 1.28
+++ Makefile10 Feb 2012 16:09:21 -
@@ -7,7 +7,7 @@
PORTNAME= porttools
PORTVERSION= 0.99
-PORTREVISION= 2
+PORTREVISION= 3
CATEGORIES=ports-mgmt
MASTER_SITES= SF
Index: files/patch-cmd_submit.in
===
RCS file:
/base/FreeBSD-CVS/ports/ports-mgmt/porttools/files/patch-cmd_submit.in,v
retrieving revision 1.1
diff -u -p -u -r1.1 patch-cmd_submit.in
--- files/patch-cmd_submit.in 30 Oct 2011 20:29:53 - 1.1
+++ files/patch-cmd_submit.in 7 Feb 2012 19:36:05 -
@@ -1,12 +1,43 @@
$FreeBSD: ports/ports-mgmt/porttools/files/patch-cmd_submit.in,v 1.1
2011/10/30 20:29:53 crees Exp $
-From bugs.freebsd.org/154809
+Porttools will now include PORTREVISION in PRs sent (bugs.freebsd.org/154809).
-Porttools will now include PORTREVISION and PORTEPOCH in PRs sent
+Add -P to print PR to stdout instead of submitting.
cmd_submit.in.old 2011-02-15 12:55:54.0 -0800
-+++ cmd_submit.in 2011-02-15 12:59:51.0 -0800
-@@ -146,6 +146,7 @@
+
+--- cmd_submit.in.orig 2009-09-09 13:59:59.0 -0600
cmd_submit.in 2012-02-07 11:55:39.0 -0700
+@@ -30,6 +30,7 @@
+ pattern - against original port in pwdpattern
+ -s severity - Set PR's severity to severity
+ -p priority - Set PR's priority to priority
++ -P - Don't send the PR; print to stdout (see -P in send-pr(1))
+ -c - committer mode: more portlint(1) checks
+ -L - Skip running portlint(1)
+ EOF
+@@ -41,9 +42,10 @@
+ PRIORITY=low
+ COMMITTER=no
+ RUN_PORTLINT=yes
++SENDPR_ARGS=
+
+ # Parse command line arguments
+-ARGS=`/usr/bin/getopt hm:d:s:p:cL $*`
++ARGS=`/usr/bin/getopt hm:d:s:p:cLP $*`
+ if [ $? != 0 ]
+ then
+ echo Error: invalid arguments
+@@ -116,6 +118,9 @@
+ -L)
+ RUN_PORTLINT=no
+ ;;
++ -P)
++ SENDPR_ARGS=$SENDPR_ARGS -P
++ ;;
+ esac
+ shift
+ done
+@@ -146,6 +151,7 @@
# Collect information about the port
PORTNAME=`make -V PKGNAMEPREFIX``make -V PORTNAME``make -V PKGNAMESUFFIX`
PORTVERSION=`make -V PORTVERSION`
@@ -14,7 +45,7 @@ Porttools will now include PORTREVISION
PKGNAME=`make -V PKGNAME`
CATEGORY=`make -V CATEGORIES | sed -E 's/^([^ ]+).*$/\1/'`
MAINTAINER=`make -V MAINTAINER`
-@@ -194,8 +195,14 @@
+@@ -194,8 +200,14 @@
# Override some parameters if submitting an update to a newer
# version of an existing port
CLASS=update
@@ -29,3 +60,12 @@ Porttools will now include PORTREVISION
fi
# Check to see if maintainership was requested
+@@ -333,7 +345,7 @@
+
+ # Invoke send-pr(1)
+ echo === Invoking send-pr(1) to submit a PR
+-PR_FORM=${PR_FORM} /usr/bin/send-pr -a ${PATCH}
++PR_FORM=${PR_FORM} /usr/bin/send-pr -a ${PATCH} ${SENDPR_ARGS}
+ if [ $? -ne 0 ]
+ then
+ echo Error submitting PR
Index: files/patch-port.1
===
RCS file: files/patch-port.1
diff -N files/patch-port.1
--- /dev/null 1 Jan 1970 00:00:00 -
+++ files/patch-port.1 10 Feb 2012 15:22:24 -
@@ -0,0 +1,15 @@
+$FreeBSD$
+
+--- port.1.orig2009-09-09 13:59:59.0 -0600
port.1 2012-02-10 08:19:49.0 -0700
+@@ -245,6 +245,10 @@
+ Skips running
+ .Xr portlint 1 .
+ Using this option will generate a warning and it strongly discouraged.
++.It Fl P
++Don't send the PR.
++Just print to stdout (see
Re: FreeBSD Port: python27-2.7.0_1
John Hein wrote at 15:55 MDT on Oct 30, 2010: Maxim Khitrov wrote at 15:42 -0400 on Oct 30, 2010: On Sat, Oct 30, 2010 at 2:46 PM, Sylvain Garrigues syl...@gmail.com wrote: Hello, I am using FreeBSD 8.1 and I would like to know the reasons why it has been decided that the default Python installation is 2.6 and not 2.7. Thanks in advance. Add PYTHON_DEFAULT_VERSION=python2.7 to /etc/make.conf. To answer Sylvain's original query, 2.7 is fairly new still. When a sufficent amount of testing has occurred that indicates 2.7 has no regressions, then someone will throw the switch. Of course, what constitutes a sufficient amount of testing is somewhat subjective. So the more use it gets by early adopters (such as yourself presumably), the higher the confidence in being able to update the default. I've been using python27 for a couple months now without any problems. To help get the default switched from 2.6 to 2.7, request it and report any successes (and problems) here and/or submit PRs. A search in the PR database for python27 doesn't turn up any significant problems. It will also probably require at least one full ports test build. I don't know if one has been requested. ___ 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: ident strings in pkg-plist
Doug Barton wrote at 15:58 -0700 on Oct 3, 2010: Changing the list to have a real discussion about this. On 10/3/2010 3:49 PM, John Hein wrote: I'll mention that it has come in handy for me in the past. I put it into the category of ident strings in binaries. It has a similar utility. Because I find it useful in maintaining and using a port/package, I've been one that has added it to pkg-plist in the past. I'm curious about what your use case for the information is. You can always know if you have the latest version of the plist via cvs, c[v]sup, portsnap, etc. Other than knowing that you have the latest version, what utility does the $Id string in the file itself have? Mostly convenience (one less level of indirection). For identifying sub-changes between PORTVERSION/PORTREVISION bumps. For keeping track of heritage when using a local mirror of FreeBSD ports, but slightly divergent, for local products. Mainstream FreeBSD users don't care about this one, but people who use FreeBSD and add value might. For instance, PC-BSD might fall into this category (not trying to put words in their mouth - just guessing). $work users might. Just one specific use case here - we have to maintain some older 4.x based products and have to have our own branch of the ports tree. For aberrant maintenance issues where I have had local screwups. These, of course, are _extremely_ rare personally ;) Anyway this is quite a weak entry on the use case list. Just like for ident strings in binaries where you can generally get close enough by knowing uname, you can (as you mention) generally get close enough to the plist source version from PORTVERSION/PORTREVISION and cvs, et. al. Removal doesn't bother me that much, but I found it useful on occasion over the years. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: ports/150493: Update for: security%2Fopenssh-portable port from 5.2p1 to 5.6p1
Grzegorz Blach wrote at 20:00 +0200 on Sep 23, 2010: Thanks for your patches, I'll review its at the weekend, but now I thing, that GSSAPI option should be explicit removed, not marked as broken. On http://www.sxw.org.uk/computing/patches/openssh.html is noticed: OpenSSH now contains support out of the box for GSSAPI user authentication using the 'gssapi-with-mic' mechanism. I emailed the gssapi patch maintainer. From his reply [1], it turns out the now is not really now anymore. It's now as of perhaps 5 years ago. 3.5 doesn't have the GSSAPIAuthentication stuff, but 4.3 does, so it was added somewhere in between (I didn't bisect any further). The second paragraph on the web page (Larger sites...) cites why the patch is still useful. I let Simon know that his latest patch set... http://www.sxw.org.uk/computing/patches/openssh-5.3p1-gsskex-all-20100124.patch ... does not apply cleanly to 5.6p1. He may refresh that patch (it's only slightly broken), so I think it will be useful to just mark it BROKEN for now. We can always remove it later. We can even deprecate the option, but right now bsd.ports.mk doesn't really support deprecating individual options so just adding some text to that effect to the BROKEN string may be the best option I am aware of. I CC'd ports@ - maybe someone there knows of some precedent in this area. Unfortunately, there's really no way of knowing how many people will be disappointed if the GSSAPI option disappears. [1] = From: Simon Wilkinson si...@sxw.org.uk To: John Hein jh...@symmetricom.com Subject: Re: gssapi patches for openssh Date: Thu, 23 Sep 2010 19:37:06 +0100 Message-Id: 92c531e6-d12c-4180-bda3-c0757ff39...@sxw.org.uk On 23 Sep 2010, at 19:27, John Hein wrote: For the freebsd port of openssh-portable (about to be updated to openssh 5.6p1), I am trying to determine whether to remove the GSSAPI patch option or perhaps to refresh it for 5.6p1. A couple questions: - The now above refers to which version of OpenSSH? (OpenSSH now contains...). The now is OpenSSH for about the last 5 years. OpenSSH includes GSSAPI user authentication, but not GSSAPI key exchange. User authentication is useful until you have more than 5 or so machines on your site, beyond that, virtually every large organisation that I'm aware of with Kerberos deployed is using OpenSSH with GSSAPI key exchange. - It sounds like there may be some benefit to using the key exchange part of the patch. Do you think someone should try to determine which parts could still be useful on 5.6p1 or should we just remove the GSSAPI option altogether? The patch as given on my website is all applicable to 5.6p1. In addition to supporting key exchange it also supports cascading credentials upon renewal, which is useful if you have a chain of many ssh connections from your desktop machine. Cheers, Simon. = ___ 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
distfiles from launchpad.net
I am looking at updating a port that now lives on launchpad.net, but I don't see anything for launchpad.net in bsd.sites.mk Does anyone know anything about how launchpad.net and its mirrors (if any) support downloads? Or can suggest a way to support that site in bsd.sites.mk. Here are some examples of distfile URLs... https://launchpad.net/bzr/1.11/1.11/+download/bzr-1.11.tar.gz http://launchpad.net/bzr/2.1/2.1.0b1/+download/bzr-2.1.0b1.tar.gz http://launchpad.net/vm/trunk/8.1.0-beta/+download/vm-8.1.0-beta.tgz ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: FreeBSD Port: libX11-1.2.1_1,1
Webdeal AS - J rn Skjerven wrote at 03:12 +0200 on Sep 28, 2009: Any idea ? Would a portupgrade -fa fix this issue ? try 'pkg_delete libtool-1.15.26' ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: FreeBSD Port: libX11-1.2.1_1,1
Webdeal AS - J rn Skjerven wrote at 03:42 +0200 on Sep 28, 2009: John Hein wrote: Webdeal AS - J rn Skjerven wrote at 03:12 +0200 on Sep 28, 2009: Any idea ? Would a portupgrade -fa fix this issue ? try 'pkg_delete libtool-1.15.26' pkg_delete libtool-1.15.26 pkg_delete: no such package 'libtool-1.15.26' installed This has already been removed by: portmaster -o devel/libtool22 devel/libtool15 portmaster -o devel/libltdl22 devel/libltdl15 this is also confirmed by the following: pkg_version -v |grep libtool libtool-2.2.6a_1= up-to-date with port Your most recent build log (after your portmaster -o) includes lines showing that there are still files from libtool15 around... ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Freebsd 7.2 firefox3
Maxx wrote at 20:53 +0300 on Jan 30, 2009: I`ve got the problem with installing firefox3: checking for DRIGL... gnome-config: not found gnome-config: not found configure: error: Package requirements (x11 xext xxf86vm xdamage xfixes x11-xcb xcb-glx) were not met: No package 'x11-xcb' found No package 'xcb-glx' found Consider adjusting the PKG_CONFIG_PATH environment variable if you installed software in a non-standard prefix. See attached file for more info. Is this bug? libX11 libxcb now install these pkg-config files: libdata/pkgconfig/x11-xcb.pc libdata/pkgconfig/xcb-glx.pc So it looks like you don't have those packages up to date. ___ 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: [patch] support systems that have been built WITHOUT_INFO=yes (no makeinfo install-info)
Garrett Cooper wrote at 19:53 -0800 on Dec 19, 2008: Are the ls + cat operations still required? If you mean the stray debug I inadvertently had in the first patch, then no. Look at the later patch in the PR. http://www.freebsd.org/cgi/query-pr.cgi?pr=129741 Also, can a more experienced porter please look at this and provide some critiques? Thanks for taking a look. ___ 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
[patch] support systems that have been built WITHOUT_INFO=yes (no makeinfo install-info)
Submitter-Id: current-users
Originator:John Hein
Organization:
Confidential: no
Synopsis: [patch] support systems that have been built WITHOUT_INFO=yes
(no makeinfo install-info)
Severity: non-critical
Priority: medium
Category: ports
Class: change-request
Release: FreeBSD 7.1-PRERELEASE i386
Environment:
Description:
If world is built with WITHOUT_INFO=yes, then as of 7.x, it does not
install install-info and makeinfo, etc. (see the exclusion of the
texinfo subdir in gnu/usr.bin/Makefile).
But lots of ports and bsd.port.mk expect these tools to be there
unconditionally.
Worlds without these tools (think building for embedded boxes with
nanobsd, for example) break when building these ports.
The port I hit first that has this problem is libtool15 which has this...
CONFIGURE_ENV= MAKEINFO=makeinfo --no-split
See also at least these PRs for more:
ports/121296, ports/121717
How-To-Repeat:
make buildworld WITHOUT_INFO=yes
make installworld WITHOUT_INFO=yes
(or just manually move away /usr/bin/makeinfo and /usr/bin/install-info)
Then
cd ports/devel/libtool15
make make install
Fix:
Support WITHOUT_INFO (or detect missing install-info) in ports/Mk.
See patch below.
Ports can be fixed by keying on HAS_INFO (the preferred method, I
think) or changing hard-coded invocations of makeinfo and/or
install-info to the MAKEINFO and INSTALLINFO commands as defined
below in bsd.commands.mk.
Once this fix (or similar) is in place, we can generate a patch
for all the ports that have hard-coded references to the *info
utilities.
Index: bsd.commands.mk
===
RCS file: /base/FreeBSD-CVS/ports/Mk/bsd.commands.mk,v
retrieving revision 1.3
diff -u -p -r1.3 bsd.commands.mk
--- bsd.commands.mk 14 Apr 2008 16:46:41 - 1.3
+++ bsd.commands.mk 18 Dec 2008 17:58:12 -
@@ -92,6 +92,18 @@ XARGS?= /usr/bin/xargs
XMKMF?=${LOCALBASE}/bin/xmkmf -a
YACC?= /usr/bin/yacc
+.if exists(/usr/bin/install-info) !defined(WITHOUT_INFO)
+HAS_INFO= yes
+INSTALLINFO?= /usr/bin/install-info
+MAKEINFO?= /usr/bin/makeinfo
+.else
+# Ideally, ports should key on HAS_INFO. In some cases, it
+# may make more sense to just have a port use ${MAKEINFO} and
+# ${INSTALLINFO} which are defined to a no-op here.
+INSTALLINFO?= true
+MAKEINFO?= true
+.endif
+
.if exists(/sbin/md5)
MD5?= /sbin/md5
.else
Index: bsd.port.mk
===
RCS file: /base/FreeBSD-CVS/ports/Mk/bsd.port.mk,v
retrieving revision 1.604
diff -u -p -r1.604 bsd.port.mk
--- bsd.port.mk 5 Sep 2008 19:41:43 - 1.604
+++ bsd.port.mk 18 Dec 2008 17:58:05 -
@@ -5672,13 +5672,16 @@ add-plist-data:
.if !target(add-plist-info)
add-plist-info:
# Process GNU INFO files at package install/deinstall time
-.if defined(INFO)
+.if defined(INFO) defined(HAS_INFO)
.for i in ${INFO}
- install-info --quiet ${PREFIX}/${INFO_PATH}/$i.info
${PREFIX}/${INFO_PATH}/dir
- @${ECHO_CMD} @unexec install-info --quiet --delete
%D/${INFO_PATH}/$i.info %D/${INFO_PATH}/dir \
+ -ls -alF ${PREFIX}/${INFO_PATH}/$i.info ${PREFIX}/${INFO_PATH}/dir
+ -cat ${PREFIX}/${INFO_PATH}/dir
+ ${INSTALLINFO} --quiet ${PREFIX}/${INFO_PATH}/$i.info
${PREFIX}/${INFO_PATH}/dir || \
+ { echo *** ignoring failed ${INSTALLINFO} for possible
duplicate entry *** 2; true; }
+ @${ECHO_CMD} @unexec ${INSTALLINFO} --quiet --delete
%D/${INFO_PATH}/$i.info %D/${INFO_PATH}/dir \
${TMPPLIST}
@${LS} ${PREFIX}/${INFO_PATH}/$i.info* | ${SED} -e s:${PREFIX}/::g
${TMPPLIST}
- @${ECHO_CMD} @exec install-info --quiet %D/${INFO_PATH}/$i.info
%D/${INFO_PATH}/dir \
+ @${ECHO_CMD} @exec ${INSTALLINFO} --quiet %D/${INFO_PATH}/$i.info
%D/${INFO_PATH}/dir \
${TMPPLIST}
.endfor
.if defined(INFO_SUBDIR)
___
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: security/nss does not build
Karl-Petter Åkesson wrote at 20:52 +0200 on Sep 1, 2008:
I get this problem when I try to build the nss port. It has been
reported in PR 122293 but the fix suggested to nspr4.7 does not help.
Please, any suggestion to solve this would be great!
/Kalle
I just had this same problem portupgrading from nss-3.11.4 to the
latest, nss-3.11.9_2.
The quick workaround is to pkg_delete the old nss first.
What happens is that the build creates libssl and puts it into a
temporary dist dir under the work directory. The new libssl has the
symbol, SSL_CanBypass, defined. But the link command (quoted below)
has -L/usr/local/lib before -L../../../../dist/FreeBSD6.3_OPT.OBJ/lib,
and so it tries to link with the _installed_ libssl which does _not_
have the new symbol.
It would probably be better if -L/usr/local/lib were after the other
-L in the linker flags. Then it can still find -lnspr4 (for
instance), but won't find the older internal (to nss) libs before the
newly built internal libs in the dist dir.
Fixing nss to do this may be worthwhile, but I haven't tested
anything myself, opting for the aforementioned pkg_delete quick
workaround.
Note that -L${LOCALBASE}/lib was fairly recently added (12-Mar-08)
to CFLAGS in security/nss/Makefile.
cc -o FreeBSD6.3_OPT.OBJ/selfserv -O2 -fno-strict-aliasing -pipe
-I/usr/local/include/nspr -L/usr/local/lib -O -fPIC -ansi -Wall
-DFREEBSD-DHAVE_STRERROR -DHAVE_BSD_FLOCK -DXP_UNIX -UDEBUG -DNDEBUG
-D_THREAD_SAFE -D_REENTRANT -DNSS_ENABLE_ECC
-I../../dist/FreeBSD6.3_OPT.OBJ/include -I../../dist/public/
-I../../dist/private/ -O -fPIC -ansi -Wall -DFREEBSD -DHAVE_STRERROR
-DHAVE_BSD_FLOCK -DXP_UNIX -UDEBUG -DNDEBUG -D_THREAD_SAFE -D_REENTRANT
-DNSS_ENABLE_ECC -I../../../dist/FreeBSD6.3_OPT.OBJ/include
-I../../../dist/public/ -I../../../dist/private/
-I../../../dist/public/nss -I../../../dist/public/nspr
-I../../../dist/public/libdbm
-I../../../dist/FreeBSD6.3_OPT.OBJ/../public/security -I./include -O
-fPIC -ansi -Wall -DFREEBSD -DHAVE_STRERROR -DHAVE_BSD_FLOCK -DXP_UNIX
-DNSPR20 -DNSS_ENABLE_ECC -UDEBUG -DNDEBUG -D_THREAD_SAFE -D_REENTRANT
-DNSS_ENABLE_ECC -I../../../../dist/FreeBSD6.3_OPT.OBJ/include
-I../../../../dist/public/nss -I../../../../dist/private/nss
-I../../../../dist/public/seccmd -I../../../../dist/public/dbm
FreeBSD6.3_OPT.OBJ/selfserv.o
../../../../dist/FreeBSD6.3_OPT.OBJ/lib/libsectool.a
-Wl,-rpath-link,../../../../dist/FreeBSD6.3_OPT.OBJ/lib
-L../../../../dist/FreeBSD6.3_OPT.OBJ/lib -lssl3 -lsmime3 -lnss3
-L../../../../dist/FreeBSD6.3_OPT.OBJ/lib -lplc4 -lplds4 -lnspr4 -pthread
FreeBSD6.3_OPT.OBJ/selfserv.o(.text+0x2f4b): In function `.L354':
: undefined reference to `SSL_CanBypass'
FreeBSD6.3_OPT.OBJ/selfserv.o(.text+0x30c3): In function `.L354':
: undefined reference to `SSL_CanBypass'
gmake[2]: *** [FreeBSD6.3_OPT.OBJ/selfserv] Fel 1
gmake[2]: Leaving directory
`/usr/ports/security/nss/work/nss-3.11.9/mozilla/security/nss/cmd/selfserv'
gmake[1]: *** [libs] Fel 2
gmake[1]: Leaving directory
`/usr/ports/security/nss/work/nss-3.11.9/mozilla/security/nss/cmd'
gmake: *** [libs] Fel 2
*** Error code 2___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to [EMAIL PROTECTED]
update from 6 to 7 - needs libtool rebuild
I updated from 6-stable to 7-stable and got the following error when portupgrading graphics/tiff... . . /bin/sh /usr/local/bin/libtool --tag=CXX --mode=link c++ -O2 -fno-strict-aliasing -pipe -L/usr/local/lib -o libtiffxx.la -rpath /usr/local/lib -no-undefined -version-number 4:0:0 tif_stream.lo ../libtiff/libtiff.la ../port/libport.la -ljpeg -lz -lm -lc c++ -shared -nostdlib /usr/lib/crti.o /usr/lib/crtbeginS.o .libs/tif_stream.o -Wl,--whole-archive ../port/.libs/libport.a -Wl,--no-whole-archive -Wl,--rpath -Wl,/2/pub/jhein/.no-amanda-backup/wd/usr/ports/graphics/tiff/work/tiff-3.8.2/libtiff/.libs -Wl,--rpath -Wl,/usr/local/lib -Wl,--rpath -Wl,/usr/local/lib -L/usr/local/lib ../libtiff/.libs/libtiff.so /usr/local/lib/libjpeg.so -lz -L/usr/lib -lstdc++ -lm -lgcc_pic /usr/lib/crtendS.o /usr/lib/crtn.o -Wl,-soname -Wl,libtiffxx.so.4 -o .libs/libtiffxx.so.4 /usr/bin/ld: cannot find -lgcc_pic As it turns out, a forced update of libtool was needed. There are a few key differences between old libtool-1.15.26 from 6.x and the rebuilt one in 7.x Below is just an excerpt of the diff. Note the references to i386-portbld-freebsd6.3 (in the old) and i386-portbld-freebsd7.1 (in the new). And the key for the issue reported above: lgcc_pic replaced by lgcc_s. [I'm not sure why the new lib search path has /usr/lib /usr/lib and later -L/usr/lib -L/usr/lib, but that duplication is minor] [ see also http://www.freebsd.org/cgi/query-pr.cgi?pr=113172 ] So my question is: is this documented and/or widely known? A full portupgrade wouldn't help if you were up to date on libtool in 6.x before updating (unless portupgrade -f is used). If this isn't widely known, maybe this will help someone. Would it be worth documenting this in UPDATING (if I haven't missed it somewhere)? I wonder if there's a good way to have this staleness on OS update detected by our port/pkg update tools. @@ -7387,13 +7387,13 @@ # The host system. host_alias= -host=i386-portbld-freebsd6.3 -host_os=freebsd6.3 +host=i386-portbld-freebsd7.1 +host_os=freebsd7.1 # The build system. -build_alias=i386-portbld-freebsd6.3 -build=i386-portbld-freebsd6.3 -build_os=freebsd6.3 +build_alias=i386-portbld-freebsd7.1 +build=i386-portbld-freebsd7.1 +build_os=freebsd7.1 # An echo program that does not interpret backslashes. echo=echo @@ -7559,15 +7559,15 @@ # Dependencies to place after the objects being linked to create a # shared library. -postdeps=-lstdc++ -lm -lgcc_pic -lgcc_pic +postdeps=-lstdc++ -lm -lgcc_s -lc -lgcc_s # The directories searched by this compiler when creating a shared # library -compiler_lib_search_dirs=/usr/lib +compiler_lib_search_dirs=/usr/lib /usr/lib # The library search path used internally by the compiler when linking # a shared library. -compiler_lib_search_path=-L/usr/lib +compiler_lib_search_path=-L/usr/lib -L/usr/lib # Method to check whether dependent libraries are shared objects. deplibs_check_method=pass_all ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: update from 6 to 7 - needs libtool rebuild
Lowell Gilbert wrote at 16:35 -0500 on Nov 13, 2008: John Hein [EMAIL PROTECTED] writes: So my question is: is this documented and/or widely known? A full portupgrade wouldn't help if you were up to date on libtool in 6.x before updating (unless portupgrade -f is used). But you've *always* needed to rebuild *all* your ports when system libraries got a version bump. Symbol versioning may make this less of an issue in the future, but even then I'll be expecting to do it when I make major version jumps. I often don't rebuild everything right away and live with the compat libs for a while. That has worked fine in the past (probably had some hiccups that I've long since forgotten about). But I understand why the official position is to rebuild everything. Would it be worth documenting this in UPDATING (if I haven't missed it somewhere)? It's in the release notes for every (I think) release. Other places might make sense also, I guess... I don't see it at the moment (looking at 6.3's relnotes), but I didn't look too hard. Thanks for the answers. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: port: truecrypt 5.1a, need some testers
Stephan Fiebrandt wrote at 00:06 +0200 on May 2, 2008: This updated port should build the latest truecrypt 5.1a on freebsd. It depends on wxgtk28 with unicode. The NOGUI version dpes also require wx base libraries. So wxgtk28-unicode is marked as dependency. I have done some load test on today's 7-STABLE amd64, however it needs more testing also under i386 as my machine is heavy patched and my i386 is 8-CURRENT right now (there it works too). Don't forget to start fuse before running truecrypt. Port can be found at: http://nsx.de/truecrypt-5.1a.tar.gz It works for me in limited testing (mount encrypted file backed volume on nfs ufs, create a file, umount, remount) - tested on recent 6-STABLE. Thanks for the good work. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD Port: xorg-7.3_1
Laurent Grangeau wrote at 20:45 +0100 on Mar 6, 2008: Hi there ! I've been using FreeBSD now for 4 months and it's a great OS. But is there a way to install minimal Xorg server without installing the meta-port (and thus, without all of the drivers) ? I'm using portinstall as the installer and I've been able to install completely xorg-xserver and nvidia-driver until now, but I'm not able tu launch the startx script. Where is that damned script (I mean, in which package) ? I'm running minimal install of FreeBSD 7.0. You don't have to install the x11/xorg metaport. If you look in x11/xorg/Makefile, you can see the pieces it installs. For a semi-minimal X, you probably want xorg-protos, xorg-libraries, xorg-fonts-miscbitmaps, xorg-server and your driver. You probably don't need everything in xorg-apps (who uses xmore?), nor, of course, everthing in xorg-drivers. In xorg-apps, xterm xinit are pretty basic. At one point there was talk of an xorg-lite metaport, but I don't know of anything that actually exists. startx is in the xinit port that is installed as part of xorg-apps. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
