Re: OO 3.3.0 fails to build connectivity module on amd64 9-STABLE
On 14 Feb, Maho NAKATA wrote: Hi Looks good. Please commit following patch! thank you! Committed! ___ 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: OO 3.3.0 fails to build connectivity module on amd64 9-STABLE
From: Don Lewis truck...@freebsd.org Subject: Re: OO 3.3.0 fails to build connectivity module on amd64 9-STABLE Date: Tue, 14 Feb 2012 00:21:00 -0800 (PST) On 14 Feb, Maho NAKATA wrote: Hi Looks good. Please commit following patch! thank you! Committed! thank you! ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: [CFT] Xorg Upgrade 7.5.2
Running on: * Intel Sandybridge (+ optimus, disabled) on FreeBSD 9.0 * NVidia GTS 450 on FreeBSD 8.2 Not unkwonw problem. Usual problem on Intel Sandybridge (tty switch, KMS patch issues on FreeBSD 9 and optimus incompatibility (/dev/dri/card1)). Tested with KDE 4.7.4 and desktop effect activated. Not all effect are available using openGL. AFAIK KDE 4.8 is able to use more OpenGL effects using the same library. Thanks for the great job you've done! Best regards, Luca On 02/06/12 02:45, Martin Wilke wrote: Knock knock... The X11 Team is pleased to announce the next round of Xorg updates. Note that this is experimental so you really have to know what you are doing, read UPDATING in the repository, and follow our exact instructions. We are specifically looking for feedback from Intel, ATI and NVIDIA users. Summary of changes: xf86-video-nouveau has been removed along with the WITHOUT_NOUVEAU knob. We suggest switching to the nvidia blob. KMS Support [1]: Unfortunately, the intel KMS driver will only work for the latest FreeBSD 9-STABLE or 10-CURRENT users. The patch for HEAD current is named all.13.1.patch. The higher the version the newer the patch is. Other needed patches are already available in the Xorg update. HEAD Users: Get the latest patchset from Kib here: http://people.freebsd.org/~kib/drm/ 9-STABLE Users: 'meowthink' is currently maintaining the backport to 9 STABLE. Make sure you have the latest FreeBSD 9-STABLE source. Get the patch from here: https://docs.google.com/leaf?id=0BxbPi2OX4_B-NWY3NWU3MzEtNDBjYy00NTljLThlZGItMWFlYjIyYjI4Yjk3hl=en_US Rebuild your Kernel and reboot. Known issuse: There will be a patch reject in the sys/dev/drm/i915_suspend.c file. The solution is to manually undo the expansion of the $FreeBSD: $ tag, so it only saysis $FreeBSD$. Checkout Xorg Development Repo: You will need to install devel/subversion in order to checkout the xorg repo. Next, you will need to add WITH_NEW_XORG=yes in your /etc/make.conf if you want to try out the new Xorg and mesa. Intel users: note that if you are not qualified for the KMS patch, you shouldn't use WITH_NEW_XORG=yes because the old intel driver doesn't build with the new X server. If you are qualified, you should also set WITH_KMS=yes in /etc/make.conf. svn co https://trillian.chruetertee.ch/svn/ports/tags/xorg_7_5_2 A small merge script to merge the svn checkout into the real portstree can be found here: http://people.freebsd.org/~miwi/xorg/xorgmerge The script is a modified version of the old kdemerge script. Please set the KDEDIR variable to the path of your X.org ports. After merging, run one of the following command, depending on which tool you use to manage your installed packages. portupgrade -af \* portmaster -a After installing these, you will have to rebuild all xf86-* ports. We will bump all related ports during the commit to the ports tree. Roadmap: Our current plan is to let the CFT running until the last weekend of February. We hope to get a lot feedback to solve as many problems as possible. So please help us to get the best xorg update ever in! Links: http://wiki.freebsd.org/Intel_GPU [1] http://wiki.freebsd.org/Xorg http://miwi.bsdcrew.de/2012/02/working-on-xorg-stuff/ Your FreeBSD Xorg Team PS: Please reply to the x11@ mailing list. Cross posted due to the potentially disruptive nature of the change and need to get a wide variety of testers. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Please test your commits
On 12.02.2012 22:43, Stephen Montgomery-Smith wrote: On 02/12/2012 03:33 PM, Andriy Gapon wrote: on 12/02/2012 23:22 Stephen Montgomery-Smith said the following: On 02/12/2012 03:15 PM, Andriy Gapon wrote: Today I became another user of redports.org. I can definitely recommend it. Yes, but it is not without its problems. I tried testing math/sage on redports.org. It reported an error building the dependency math/atlas, which built fine on mine and other people's systems. But still this is an instance of environment where the port can fail, so it warrants an investigation and fixing. Either in the port or in the redports infrastructure. Yes, you are correct. In fact, in the case of math/atlas there is the following report. It looks like people are working on it. http://portsmon.freebsd.org/portoverview.py?category=mathportname=atlaswildcard= I think this isn't directly related. The build on redports had status dud in math/atlas which means the port has set IGNORE. I have no good way of telling which IGNORE line it is yet but it can only be one of: You have set WITH_ARCHDEF, but have not defined ARCHDEF You must select at least one of WITH_SHARED and WITH_STATIC both sound strange. There is nothing strange about them: they just indicate errors arising from invalid choices of OPTIONS. The build is more likely to be broken by MANUAL_PACKAGE_BUILD, which uses IGNORE. math/atlas is a port that -- except in a few cases -- must be built on the host machine in a dedicated build. If you have a port that has a dependency on math/atlas, then it will not be easy to test that port via a system like Redports. With regard to the larger issue, ghostscript is a somewhat awkward port to check, because: it has many dependencies; it has many options that are used by a considerable number of people; it is maintained by a group (although Hiroki usually works on it); and it is widely-used. Even with a reasonable amount of testing (and Hiroki is usually careful), it is probable that there will be some occasional problems, at least when ghostscript is not built in a clean sandbox -- and it isn't on the live systems of many users. So while it is reasonable to send a message about a port like this to the list, the message should also be dispatched directly to doceng, and those making reports or complaints should be patient, and provide as much useful information as possible. b. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Please test your commits
On 02/14/12 08:40, b. f. wrote: On 12.02.2012 22:43, Stephen Montgomery-Smith wrote: On 02/12/2012 03:33 PM, Andriy Gapon wrote: on 12/02/2012 23:22 Stephen Montgomery-Smith said the following: On 02/12/2012 03:15 PM, Andriy Gapon wrote: Today I became another user of redports.org. I can definitely recommend it. Yes, but it is not without its problems. I tried testing math/sage on redports.org. It reported an error building the dependency math/atlas, which built fine on mine and other people's systems. But still this is an instance of environment where the port can fail, so it warrants an investigation and fixing. Either in the port or in the redports infrastructure. Yes, you are correct. In fact, in the case of math/atlas there is the following report. It looks like people are working on it. http://portsmon.freebsd.org/portoverview.py?category=mathportname=atlaswildcard= I think this isn't directly related. The build on redports had status dud in math/atlas which means the port has set IGNORE. I have no good way of telling which IGNORE line it is yet but it can only be one of: You have set WITH_ARCHDEF, but have not defined ARCHDEF You must select at least one of WITH_SHARED and WITH_STATIC both sound strange. There is nothing strange about them: they just indicate errors arising from invalid choices of OPTIONS. The build is more likely to be broken by MANUAL_PACKAGE_BUILD, which uses IGNORE. That would explain the problems I am having. I'll quit trying to test sage on redports. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Installing executables with generic names
Hello!
I'm preparing a new port (net/udt), which installs a library with its
header file and a handful of sample applications.
The applications are rather generically named: sendfile, recvfile,
test... Having them in ${PREFIX}/bin
like that would be confusing.
I see two alternatives:
* use a port-specific prefix for each binary: udt-sendfile,
udt-recvfile, udt-test, etc.
or
* use a port-specific subdirectory: ${PREFIX}/bin/udt/ (lua seems to
do this)
The first is simpler for me, but might be a trouble for anyone porting a
script in the future, which calls the binaries by their generic name...
Opinions? Thanks! Yours,
-mi
___
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
Re: Installing executables with generic names
On 2/14/12 8:26 AM, Mikhail T. wrote:
Hello!
I'm preparing a new port (net/udt), which installs a library with its
header file and a handful of sample applications.
* use a port-specific subdirectory: ${PREFIX}/bin/udt/ (lua seems to
do this)
EXAMPLESDIR
In your port dir, type:
make -V EXAMPLESDIR
you can put them there if you like.
(don't forget pkg-plist: %%EXAMPLESDIR%% already trimmed for %%PREFIX%%)
The first is simpler for me, but might be a trouble for anyone porting
a script in the future, which calls the binaries by their generic name...
Opinions? Thanks! Yours,
-mi
___
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
--
Michael Scheidell, CTO
o: 561-999-5000
d: 561-948-2259
*| *SECNAP Network Security Corporation
* Best Mobile Solutions Product of 2011
* Best Intrusion Prevention Product
* Hot Company Finalist 2011
* Best Email Security Product
* Certified SNORT Integrator
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: print/ghostscript9: ./base/sjpx_openjpeg.c:169: error: too many arguments to function
On 13 Feb 2012 11:14, O. Hartmann ohart...@mail.zedat.fu-berlin.de wrote: This arise today when updating ghostscript9-9.04 to ghostscript9-9.05: cc -DHAVE_MKSTEMP -DHAVE_FONTCONFIG -DHAVE_LIBIDN -DHAVE_SETLOCALE -DHAVE_SSE2 -DHAVE_DBUS -O2 -pipe -O2 -fno-strict-aliasing -pipe -march=native -fPIC -DUPD_SIGNAL=0 -I. -I/usr/ports/print/ghostscript9/work/ghostscript-9.05/lcms/include -I/usr/local/include/libpng -I/usr/local/include -I/usr/local/include/freetype2 -Wall -Wstrict-prototypes -Wundef -Wmissing-declarations -Wmissing-prototypes -Wwrite-strings -Wno-strict-aliasing -Wdeclaration-after-statement -fno-builtin -fno-common -DHAVE_STDINT_H=1 -DHAVE_SYS_TIME_H=1 -DGX_COLOR_INDEX_TYPE=unsigned long int -O2 -pipe -O2 -fno-strict-aliasing -pipe -march=native -DUSE_LIBICONV_GNU -DUSE_LIBPAPER -I/usr/local/include -DGS_DEVS_SHARED -DGS_DEVS_SHARED_DIR=\/usr/local/lib/ghostscript/9.05\ -Iopenjpeg/libopenjpeg/.. -Iopenjpeg/libopenjpeg -I./soobj -I./base -DUSE_OPENJPEG_JP2 -ffast-math -DOPJ_STATIC -std=c99 -o ./soobj/sjpx_openjpeg.o \ -c -DOPJ_STATIC ./base/sjpx_openjpeg.c ./base/sjpx_openjpeg.c: In function 'decode_image': ./base/sjpx_openjpeg.c:169: error: too many arguments to function 'opj_decode' ./base/sjpx_openjpeg.c:205: error: 'opj_image_comp_t' has no member named 'typ' ./base/sjpx_openjpeg.c:205: error: 'CTYPE_COLOR' undeclared (first use in this function) ./base/sjpx_openjpeg.c:205: error: (Each undeclared identifier is reported only once ./base/sjpx_openjpeg.c:205: error: for each function it appears in.) ./base/sjpx_openjpeg.c:207: error: 'opj_image_comp_t' has no member named 'typ' ./base/sjpx_openjpeg.c:207: error: 'CTYPE_OPACITY' undeclared (first use in this function) ./base/sjpx_openjpeg.c:217: error: 'CLRSPC_CMYK' undeclared (first use in this function) ./base/sjpx_openjpeg.c:250: error: 'opj_image_t' has no member named 'has_palette' ./base/sjpx_openjpeg.c:257: error: 'CLRSPC_EYCC' undeclared (first use in this function) gmake[2]: *** [soobj/sjpx_openjpeg.o] Error 1 gmake[2]: Leaving directory `/usr/ports/print/ghostscript9/work/ghostscript-9.05' gmake[1]: *** [so-subtarget] Error 2 gmake[1]: Leaving directory `/usr/ports/print/ghostscript9/work/ghostscript-9.05' gmake: *** [so] Error 2 *** Error code 1 Stop in /usr/ports/print/ghostscript9. *** Error code 1 Stop in /usr/ports/print/ghostscript9. === make failed for print/ghostscript9 === Aborting update Terminated === You can restart from the point of failure with this command line: portmaster flags print/ghostscript9 This has already been discussed on ports@, please don't cross-post. Chris ___ 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 executables with generic names
On 14.02.2012 10:25, Michael Scheidell wrote:
EXAMPLESDIR
I thought, EXAMPLESDIR is for actual examples, such as source code, not compiled
and fully-functional executables... Indeed, the directory is under
${PREFIX}/share -- which, according to hier(7) is for architecture-independent
files.
-mi
___
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 executables with generic names
On 2/14/12 11:18 AM, Mikhail T. wrote:
On 14.02.2012 10:25, Michael Scheidell wrote:
EXAMPLESDIR
I thought, EXAMPLESDIR is for actual examples, such as source code,
not compiled and fully-functional executables... Indeed, the directory
is under ${PREFIX}/share -- which, according to hier(7) is for
architecture-independent files.
-min,
then, put them into EXAMPLESDIR/{arch}...
or put them anywhere you want.
--
Michael Scheidell, CTO
o: 561-999-5000
d: 561-948-2259
*| *SECNAP Network Security Corporation
* Best Mobile Solutions Product of 2011
* Best Intrusion Prevention Product
* Hot Company Finalist 2011
* Best Email Security Product
* Certified SNORT Integrator
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: print/ghostscript9: ./base/sjpx_openjpeg.c:169: error: too many arguments to function
On Tue, 14 Feb 2012 16:33:07 + Chris Rees articulated: This has already been discussed on ports@, please don't cross-post. The problem has not been rectified as of yet. There is an open PR 165093 filed against the port. -- Jerry ♔ Disclaimer: off-list followups get on-list replies or get ignored. Please do not ignore the Reply-To header. __ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: print/ghostscript9: ./base/sjpx_openjpeg.c:169: error: too many arguments to function
On Tue, Feb 14, 2012 at 9:29 AM, Jerry je...@seibercom.net wrote: On Tue, 14 Feb 2012 16:33:07 + Chris Rees articulated: This has already been discussed on ports@, please don't cross-post. The problem has not been rectified as of yet. There is an open PR 165093 filed against the port. I updated my ports tree about 7 hours ago and the fix was there. I've now built the new port on two systems (one amd64 and one i386) and had no problems. Looking at the repo, it appears the fix was made yesterday (2/13) at 21:48 and the Makefile should be CVS version 1.11. -- R. Kevin Oberman, Network Engineer E-mail: kob6...@gmail.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: Installing executables with generic names
On Tue, 14 Feb 2012 11:49:00 -0500
Michael Scheidell scheid...@freebsd.org wrote:
On 2/14/12 11:18 AM, Mikhail T. wrote:
On 14.02.2012 10:25, Michael Scheidell wrote:
EXAMPLESDIR
I thought, EXAMPLESDIR is for actual examples, such as source code,
not compiled and fully-functional executables... Indeed, the
directory is under ${PREFIX}/share -- which, according to hier(7)
is for architecture-independent files.
-min,
then, put them into EXAMPLESDIR/{arch}...
or put them anywhere you want.
No, if they are binaries they don't have any reason to be in
EXAMPLESDIR. The other idea of prefixing them is _much_ better.
--
IOnut - Un^d^dregistered ;) FreeBSD user
Intellectual Property is nowhere near as valuable as Intellect
FreeBSD committer - ite...@freebsd.org, PGP Key ID 057E9F8B493A297B
___
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 executables with generic names
On 14.02.2012 13:17, Ion-Mihai Tetcu wrote: The other idea of prefixing them is_much_ better. Ok, so which flavor of prefixing do you prefer? Should the executable bar be installed as bin/foo-bar or as bin/foo/bar? -mi ___ 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 executables with generic names
On 14 Feb 2012 18:54, Mikhail T. mi+t...@aldan.algebra.com wrote: On 14.02.2012 13:17, Ion-Mihai Tetcu wrote: The other idea of prefixing them is_much_ better. Ok, so which flavor of prefixing do you prefer? Should the executable bar be installed as bin/foo-bar or as bin/foo/bar? bin/foo-bar means it can still be called without an explicit path, so that is better. Look for autoconf hooks to add prefices this way (if it uses configure...) Chris ___ 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
devel/pcre
Hello, Can someone add an entry in ports/UPDATING for the latest update of devel/pcre (8.30) ? All ports that depend on it have to be rebuilt (you have to rebuild all the box...). Thanks, regards. (copy to the maintener (mm)) ___ 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: graphics/rawtherapee
Mathias Picker mathias.pic...@virtual-earth.de wrote: Good god, I must have worn both my eye patches at the same time. Sorry, Mathias Mayby you can try to install graphics/rawtherapee - just to approve (or discard) my problem. Heino ___ 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 executables with generic names
On 2/14/2012 11:27, Chris Rees wrote: bin/foo-bar means it can still be called without an explicit path, so that is better. Look for autoconf hooks to add prefices this way (if it uses configure...) Please also don't forget to scream at the upstream to stop using such generic names too. Otherwise we're going to potentially be looking at a lot of patching in dependent ports: s#generic#foo-generic# -aDe ___ 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: devel/pcre
On 02/14/2012 11:23, Patrick Lamaiziere wrote: Hello, Can someone add an entry in ports/UPDATING for the latest update of devel/pcre (8.30) ? All ports that depend on it have to be rebuilt (you have to rebuild all the box...). I added a note that suggests using the -w option for portmaster which preserves the shared libs until a better solution is found. I guessed on the knob for portupgrade, if someone who knows better wants to correct it that would be welcome. :) Doug -- It's always a long day; 86400 doesn't fit into a short. Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.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
Python upgrade to address vulnerability?
So apparently we have a python vulnerability according to http://portaudit.FreeBSD.org/b4f8be9e-56b2-11e1-9fb7-003067b2972c.html, but I'm not seeing an upgrade to address it yet. Any idea when that will happen? Thanks, Doug -- It's always a long day; 86400 doesn't fit into a short. Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.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: devel/pcre
On 14/02/2012 22:17, Doug Barton wrote: I added a note that suggests using the -w option for portmaster which preserves the shared libs until a better solution is found. I guessed on the knob for portupgrade, if someone who knows better wants to correct it that would be welcome. :) portupgrade preserves shlibs by default. There's no option to turn on saving shlibs, only option '-u' to turn off preserving shlibs. '-w' means 'don't run make clean before building' Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate JID: matt...@infracaninophile.co.uk Kent, CT11 9PW signature.asc Description: OpenPGP digital signature
Re: devel/pcre
On 02/14/2012 14:54, Matthew Seaman wrote: On 14/02/2012 22:17, Doug Barton wrote: I added a note that suggests using the -w option for portmaster which preserves the shared libs until a better solution is found. I guessed on the knob for portupgrade, if someone who knows better wants to correct it that would be welcome. :) portupgrade preserves shlibs by default. There's no option to turn on saving shlibs, only option '-u' to turn off preserving shlibs. '-w' means 'don't run make clean before building' Thanks, it's fixed now. :) -- It's always a long day; 86400 doesn't fit into a short. Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ signature.asc Description: OpenPGP digital signature
Re: devel/pcre
Thanks. On 14.2.2012 23:17, Doug Barton wrote: On 02/14/2012 11:23, Patrick Lamaiziere wrote: Hello, Can someone add an entry in ports/UPDATING for the latest update of devel/pcre (8.30) ? All ports that depend on it have to be rebuilt (you have to rebuild all the box...). I added a note that suggests using the -w option for portmaster which preserves the shared libs until a better solution is found. I guessed on the knob for portupgrade, if someone who knows better wants to correct it that would be welcome. :) Doug -- Martin Matuska FreeBSD committer http://blog.vx.sk ___ 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
sysutils/smartmontools still using set_rcvar
The rc.d script installed by the smartmontools port is still trying to use set_rcvar. The problem is that the copy of the script under the files directory has been updated, but the script that the port actually installs is work/smartd.freebsd.initd.in, which is an older version. ___ 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: sysutils/smartmontools still using set_rcvar
On 02/14/2012 17:08, Don Lewis wrote: The rc.d script installed by the smartmontools port is still trying to use set_rcvar. The problem is that the copy of the script under the files directory has been updated, but the script that the port actually installs is work/smartd.freebsd.initd.in, which is an older version. Thanks for bringing this to my attention. I just filed this: http://www.freebsd.org/cgi/query-pr.cgi?pr=165167 Doug -- It's always a long day; 86400 doesn't fit into a short. Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.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: mail/mimedefang still using set_rcvar
On 02/14/2012 22:52, poyop...@puripuri.plala.or.jp wrote: Hi Doug, Do you interested in mail/mimedefang? It also has set_rcvar in its rc.d script. Fixed, thanks. -- It's always a long day; 86400 doesn't fit into a short. Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.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
