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 +-+ science/gwyddion| 2.31| 2.32 +-+ 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...@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: ports/181913: devel/qt4-script: /usr/include/c++/v1/type_traits:3175:22: error: call to 'swap' is ambiguous
On Sun, 8 Sep 2013 14:57:01 +0200 Dimitry Andric wrote: > On Sep 8, 2013, at 08:14, O. Hartmann > wrote: > > On Sat, 7 Sep 2013 22:49:54 GMT > > rak...@freebsd.org wrote: > > > >> Synopsis: > >> devel/qt4-script: /usr/include/c++/v1/type_traits:3175:22: error: > >> call to 'swap' is ambiguous > >> > >> State-Changed-From-To: open->patched > >> State-Changed-By: rakuco > >> State-Changed-When: Sat Sep 7 22:47:43 UTC 2013 > >> State-Changed-Why: > >> I don't think the previous version worked. > >> > >> From your description, it looks like you've switched to building > >> with libc++ whereas libstdc++ was being used before. > >> > >> The upcoming Qt 4.8.5 plus a few patches which only made it to > >> 4.8.6 (but we've backported) will finally make Qt build with > >> libc++. > >> > >> We've just sent an exp-run request for Qt 4.8.5, and will hopefully > >> fix all these errors once it is committed. > >> > >> http://www.freebsd.org/cgi/query-pr.cgi?pr=181913 > > > > I build the world/kernel since early this year with > > > > CXXFLAGS+= -stdlib=libc++ > > CXXFLAGS+= -std=c++11 > > > > > > in /etc/src.conf. I do not use those flags > > in /etc/make.conf! /etc/src.conf is supposed to target ONLY > > the /usr/src world, not the ports - this is as I interpret the man > > page for /etc/src.conf and it would be logical. But this > > rule/thinking seems to be broken by some includes > > from /usr/ports/Mk ingredients. > > Since r255321, -stdlib=libc++ is effectively the default, at least > when you haven't set gcc as the default compiler. So it also applies > to ports, which unavoidably will lead to a bit of fallout. My > personal experience is that most C++-based ports compile fine with > libc++ instead of libstdc++, except for a few that rely on internal > libstdc++ details. > > However, -std=c++11 is *not* yet the default, and C++11 has different > rules here and there, so some ports might fail to compile due to this. > For some ports, too much hacking may be required to make them work > with C++11. So in case of trouble, try removing -std=, or setting it > to different values (c++0x, c++98, gnu++98, etc), to get the port to > compile. > > Note the base system should have no problems with -std=c++11, so > please continue to use the option in src.conf, and report any > problems if you encounter them, so we can fix them. :-) > I've been using clang and libc++ successfully on 9.1-RELEASE for quite some time now. Based on what I've learned, expect the following pitfalls that might hit you hard in production: - Bugs in in libc++: CURRENT is good about pulling in fixes, but there are still quite basic things getting fixed, e.g. cout/cerr not being thread safe (this was supposedly fixed in CURRENT and STABLE just a few weeks ago). Another example was handling std::vector incorrectly (ouch). Other problems only affect C++11/C++14 features and shouldn't be a big issue when porting. - Mixed C++ library linkage: For some ports autoconf/libtool might pull in libstdc++ by accident, you really don't want this to happen since std types don't match (e.g. std::exception and everything inheriting from it, which will break exception handling in client code). - Incompatibilities in corner cases of the language: A good example is the exception specification of destructors. Those are defaulting to noexcept(true) now, while in C++03 it's the opposite. Even though it's bad design in almost all cases, the language permits throwing from destructors in general. I got hit by that when porting devel/ice, which depends on databases/db5, which has no exception specification for destructors, but throws from them under certain circumstances (e.g. database close failed), in that specific case also from callbacks that were called from within db5. Overall the code was quite convoluted, but valid C++03. On top of that there are the usual incompatibilities between implementations (like iostreams in gcc 4.2's libstdc++ does some things differently then the imho more compliant libc++) and compile time problems (like the swap issue you experiences, those are easy to fix). So the bottom line is: When converting a port to use clang++ -std=c++11 -stdlib=libc++, the fact that it builds ok and runs a couple of unit tests without problems is not enough. Cheers, Michael -- Michael Gmelin ___ 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"
Current unassigned ports problem reports
(Note: an HTML version of this report is available at http://www.freebsd.org/cgi/query-pr-summary.cgi?category=ports .) The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description o ports/181961[MAINTAINER UPDATE] devel/tortoisehg2: Update 2.8.2 -> o ports/181959New port: sysutils/zjail Management tool for ZFS based o ports/181949[MAINTAINER] www/mitmproxy: Update to 0.9.2 o ports/181945[ New Port] sysutils/jail-primer f ports/181944games/iourbanterror: gcc not found o ports/181943New port: finance/fixc simple Financial Information eX f ports/181927[PATCH] fix net/fping Makefile comment f ports/181923security/heimdal JOBS_UNSAFE and default prefix locati o ports/181919[PATCH] x11-toolkits/Xaw3d has an overflow error in ge f ports/181912x11-toolkits/swt-devel: bad zipfile offset (local head o ports/181904[PATCH] graphics/libwmf: fix warning of make index whe o ports/181901[MAINTAINER-UPDATE] games/assaultcube: using GCC to bu o ports/181870[MAINTAINER] www/typo3: update to 6.1.4 o ports/181855Port: sysutils/heartbeat: FreeBSD 10 Fixes o ports/181848[NEW PORT] www/php-Twig: The flexible, fast, and secur f ports/181836Port sysutils/smartmontools brocken for scsi discs o ports/181833[MAINTAINER] databases/mariadb-server: [SUMMARIZE CHAN o ports/181832[NEW PORT] net/py-gspreadsheet: Interface to Google sp f ports/181819games/iourbanterror: Engine linkage error #31 o ports/181801[MAINTAINER] Upgrade devel/gdb to 7.6.1 f ports/181774USE_BDB 47+ fails to find installed databases/db47 o ports/181767[PATCH] www/bozohttpd: update to 20130711 o ports/181752[PATCH] devel/hub: change maintainer f ports/181746graphics/ImageMagick makefile directly executes perl f ports/181735mail/fetchmail system-wide install can't write fetch i o ports/181732New port: www/redmine-sidebar_hide Redmine hide sideba o ports/181731[patch] games/atris: unbreak with bmake f ports/181713[patch] audio/cmus Fix compilation f ports/181711port lang/ocaml does not build o ports/181691[NEW PORT] Please import Tryton Application Platform 2 o ports/181676New port: graphics/sxiv simple X image viewer f ports/181647[PATCH] archivers/zip: fix OptionsNG o ports/181643maintainership request for ports-mgmt/pkg_replace f ports/181642[patch] security/fwknop new version f ports/181641mail/ssmtp provide option for CRAM-MD5 support f ports/181633[PATCH] update print/hplip-plugin to 3.13.8 o ports/181613Mk/bsd.ocaml.mk has fbsd:nokeywords property f ports/181603[patch] fix net/mediatomb f ports/181566[update] security/sssd to 1.9.5 f ports/181564print/cups: undefined reference to `libiconv_close` f ports/181557www/mambo: DNS expired, unfetchable f ports/181555sysutils/isomd5sum checksum mismatch f ports/181554sysutils/mktool unfetchable f ports/181551net/ftelnetd: master site disappeared, can't fetch f ports/181549databases/mird checksum mismatch f ports/181547cad/ldraw - checksum mismatch f ports/181530Upgrade lang/abcl to 1.2.1 o ports/181529sysutils/devcpu-data: Panic after CPU microcode update o ports/181527New port: multimedia/mjpg-streamer HTTP video streamin f ports/181520mplayer/mencoder failed to build with net/liveMedia 20 f ports/181507[PATCH] security/pks: fix autostart o ports/181506[maintainer-update] devel/eclipse-eclemma 2.2.1 o ports/181483[PATCH] science/py27-h5py: update to 2.1.1_3 f ports/181481[PATCH] irc/ircd-ratbox fix default options broken by o ports/181480textproc/xerces-c2 and textproc/xerces-c2-devel missin o ports/181451[NEW PORT] misc/auto-multiple-choice: Multiple Choice o ports/181450[new port] www/linux-f10-flashplugin10 request, becase f ports/181423[patch] databases/freetds-devel -- update to 0.92.79 f ports/181422[PATCH] graphics/geos: update to 3.4.1 f ports/181413[patch] emulators/visualboyadvance-m: unbreak build f ports/181399Update converters/pdf2djvu port to 0.7.17 and unbreak f ports/181391lang/itcl: fix REINPLACE usage o ports/181385[patch] x11-drivers/xf86-video-vmware: a fix from a VM f ports/181345net/tigervnc o p
Re: ports/181913: devel/qt4-script: /usr/include/c++/v1/type_traits:3175:22: error: call to 'swap' is ambiguous
On Mon, 2013-09-09 at 08:57 +0200, Stefan Esser wrote: > Am 08.09.2013 08:14, schrieb O. Hartmann: > > On Sat, 7 Sep 2013 22:49:54 GMT rak...@freebsd.org wrote: > > > >> Synopsis: devel/qt4-script: > >> /usr/include/c++/v1/type_traits:3175:22: error: call to 'swap' is > >> ambiguous > >> > >> State-Changed-From-To: open->patched State-Changed-By: rakuco > >> State-Changed-When: Sat Sep 7 22:47:43 UTC 2013 > >> State-Changed-Why: I don't think the previous version worked. > >> > >> From your description, it looks like you've switched to building > >> with libc++ whereas libstdc++ was being used before. > >> > >> The upcoming Qt 4.8.5 plus a few patches which only made it to > >> 4.8.6 (but we've backported) will finally make Qt build with > >> libc++. > >> > >> We've just sent an exp-run request for Qt 4.8.5, and will > >> hopefully fix all these errors once it is committed. > >> > >> http://www.freebsd.org/cgi/query-pr.cgi?pr=181913 > > > > > > I build the world/kernel since early this year with > > > > CXXFLAGS+= -stdlib=libc++ CXXFLAGS+= > > -std=c++11 > > > > > > in /etc/src.conf. I do not use those flags in /etc/make.conf! > > /etc/src.conf is supposed to target ONLY the /usr/src world, not > > the ports - this is as I interpret the man page for /etc/src.conf > > and it would be logical. But this rule/thinking seems to be broken > > by some includes from /usr/ports/Mk ingredients. > > There are ports that use bsd.prog.mk instead of the Makefile supplied > with the source files. Just grep for bsd.port.mk in the port's "files" > sub directory, if you find that /etc/src.conf settings affect a port. > > I think these ports are in violation of POLA and had a longer mail > exchange with a port maintainer, who told me that use of bsd.prog.mk > was the preferred method to build binaries on FreeBSD, for base and > for ports. > > So no file under /usr/ports/Mk is to blame, but some ports do > implicitly reference /etc/src.conf via their use of bsd.prog.mk. > > Regards, STefan > > NB: I just performed the grep suggested above and found that the > following ports mention bsd.prog.mk in files/*: > > If those ports .include before bsd.prog.mk, I think everything should work properly. It looks like src.conf is an "opt-out" system, and bsd.port.mk sets the variable to opt out. I don't especially like this (opt-in would be better), but I don't see an easy fix either. We use bsd.prog.mk at $work (I'd better go add the opt-out now), it seems like others probably do the same. It would be much better if the base build opted in, but the only way I can see to do that would be to install a "makefile.up" system where a makefile.up in every directory under the base src allows "walking up" to the top of the src hierarchy no matter where the build is started from, so that you can always get some top-level file to do the opt-in. -- Ian ___ 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] Update of xorg libraries and MESA
09.09.2013 15:49, Niclas Zeising wrote:
[Cross-posted between x11@ and ports@, please respect reply-to]
^/releng/9, WITH_CLANG_IS_CC, CCACHE, WITH_NEW_XORG
CC intel_fbo.lo
cc: warning: argument unused during compilation: '-fno-builtin-memcmp'
cc: warning: argument unused during compilation: '-fno-builtin-memcmp'
intel_screen.c:199:6: error: use of undeclared identifier
'__DRI_IMAGE_FOURCC_ARGB'
{ __DRI_IMAGE_FOURCC_ARGB, __DRI_IMAGE_COMPONENTS_RGBA, 1,
^
intel_screen.c:199:35: error: use of undeclared identifier
'__DRI_IMAGE_COMPONENTS_RGBA'
{ __DRI_IMAGE_FOURCC_ARGB, __DRI_IMAGE_COMPONENTS_RGBA, 1,
^
intel_screen.c:202:6: error: use of undeclared identifier
'__DRI_IMAGE_FOURCC_XRGB'
{ __DRI_IMAGE_FOURCC_XRGB, __DRI_IMAGE_COMPONENTS_RGB, 1,
^
intel_screen.c:202:35: error: use of undeclared identifier
'__DRI_IMAGE_COMPONENTS_RGB'
{ __DRI_IMAGE_FOURCC_XRGB, __DRI_IMAGE_COMPONENTS_RGB, 1,
^
Is this intended to work on 9?
--
Sphinx of black quartz, judge my vow.
___
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] Update of xorg libraries and MESA
On 9-9-2013 15:59, Volodymyr Kostyrko wrote:
09.09.2013 15:49, Niclas Zeising wrote:
[Cross-posted between x11@ and ports@, please respect reply-to]
^/releng/9, WITH_CLANG_IS_CC, CCACHE, WITH_NEW_XORG
CC intel_fbo.lo
cc: warning: argument unused during compilation: '-fno-builtin-memcmp'
cc: warning: argument unused during compilation: '-fno-builtin-memcmp'
intel_screen.c:199:6: error: use of undeclared identifier
'__DRI_IMAGE_FOURCC_ARGB'
{ __DRI_IMAGE_FOURCC_ARGB, __DRI_IMAGE_COMPONENTS_RGBA, 1,
^
intel_screen.c:199:35: error: use of undeclared identifier
'__DRI_IMAGE_COMPONENTS_RGBA'
{ __DRI_IMAGE_FOURCC_ARGB, __DRI_IMAGE_COMPONENTS_RGBA, 1,
^
intel_screen.c:202:6: error: use of undeclared identifier
'__DRI_IMAGE_FOURCC_XRGB'
{ __DRI_IMAGE_FOURCC_XRGB, __DRI_IMAGE_COMPONENTS_RGB, 1,
^
intel_screen.c:202:35: error: use of undeclared identifier
'__DRI_IMAGE_COMPONENTS_RGB'
{ __DRI_IMAGE_FOURCC_XRGB, __DRI_IMAGE_COMPONENTS_RGB, 1,
^
Is this intended to work on 9?
You need to manual remove your old libGL and dri before updating to the
new version, as mentioned in the UPDATING file.
___
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: Mapserver shp2img
Cool! It works! Thanks for helping,
Frank
Am 2013-09-06 18:05, schrieb wen heping:
Would you test with this simple patch?
Thanks !
wen
Index: Makefile
===
--- Makefile(revision 326520)
+++ Makefile(working copy)
@@ -187,7 +187,7 @@
do-install:
.for f in ${PROG_FILES}
- ${INSTALL_SCRIPT} ${WRKSRC}/${f} ${PREFIX}/bin
+ ${INSTALL_SCRIPT} ${WRKSRC}/.libs/${f} ${PREFIX}/bin
.endfor
${INSTALL_PROGRAM} ${WRKSRC}/.libs/libmapserver-${PORTVERSION}.so
${PREFIX}/lib
2013/9/6 wen heping
I shall look into that later.
wen
2013/9/5 Frank Broniewski
Another thing I noticed: While doing
# pkg_delete -d mapserver-6.2.1_2
I receive errors concerning the Python mapscript module:
pkg_delete: file '/usr/local/lib/python2.7/**site-packages/mapscript.py'
doesn't exist
pkg_delete: file '/usr/local/lib/python2.7/**site-packages/mapscript.pyc'
doesn't exist
pkg_delete: file '/usr/local/lib/python2.7/**site-packages/_mapscript.so'
doesn't exist
pkg_delete: file '/usr/local/lib/python2.7/**
site-packages/MapScript-6.2.1-**py2.7.egg-info' doesn't exist
pkg_delete: couldn't entirely delete package `mapserver-6.2.1_2'
(perhaps the packing list is incorrectly specified?)
This is probably not intended, isn't it?
I've got the following (leftover) eggs from previous installations left
in /usr/local/lib/python2.7/site-**packages
drwxr-xr-x 3 root wheel 512 Sep 12 2012
MapScript-6.0.1-py2.7-freebsd-**9.0-RELEASE-amd64.egg
drwxr-xr-x 3 root wheel 512 Jul 1 09:32
MapScript-6.2.0-py2.7-freebsd-**9.1-RELEASE-p3-amd64.egg
drwxr-xr-x 3 root wheel 512 Sep 4 08:50
MapScript-6.2.0-py2.7-freebsd-**9.1-RELEASE-p4-amd64.egg
drwxr-xr-x 3 root wheel 512 Sep 5 13:33
MapScript-6.2.1-py2.7-freebsd-**9.1-RELEASE-p6-amd64.egg
Frank
Am 2013-09-05 13:43, schrieb Frank Broniewski:
Any ideas? Is it just me or everyone else?
Frank
Am 2013-09-04 09:31, schrieb Frank Broniewski:
Hi all,
I've a problem with my mapserver installation, the utility shp2img isn't
working, which is kind of odd. I get the following error when invoking
it:
/usr/local/bin/shp2img: error: `/usr/local/bin/.libs/shp2img' does not
exist
This script is just a wrapper for shp2img.
See the libtool documentation for more information.
I don't know what I shall do about that error now. On my Ubuntu machine,
shp2img is a binary and not a shell script like on FreeBSD. While
looking at the script, the error is invoked at the end of it (lines 205
- 207):
189 if test -f "$progdir/$program"; then
190 # Add our own library path to LD_LIBRARY_PATH
191
LD_LIBRARY_PATH="/usr/ports/**graphics/mapserver/work/**
mapserver-6.2.1/.libs:/usr/**local/lib:$LD_LI
192
193 # Some systems cannot cope with colon-terminated
LD_LIBRARY_PATH
194 # The second colon is a workaround for a bug in BeOS R4 sed
195 LD_LIBRARY_PATH=`$ECHO "$LD_LIBRARY_PATH" | /usr/bin/sed
's/::*$//'`
196
197 export LD_LIBRARY_PATH
198
199 if test "$libtool_execute_magic" != "%%%MAGIC variable%%%";
then
200 # Run the actual program with our arguments.
201 func_exec_program ${1+"$@"}
202 fi
203 else
204 # The program doesn't exist.
205 $ECHO "$0: error: \`$progdir/$program' does not exist" 1>&2
206 $ECHO "This script is just a wrapper for $program." 1>&2
207 $ECHO "See the libtool documentation for more information."
1>&2
208 exit 1
209 fi
This is rather confusing as I don't know what role the libtool plays and
what I can gain from reading the rather exhaustive documentation ...
Any hints?
Many thanks,
Frank
--
Frank BRONIEWSKI
METRICO s.à r.l.
géomètres
technologies d'information géographique
rue des Romains 36
L-5433 NIEDERDONVEN
tél.: +352 26 74 94 - 28
fax.: +352 26 74 94 99
http://www.metrico.lu
___
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"
--
Frank BRONIEWSKI
METRICO s.à r.l.
géomètres
technologies d'information géographique
rue des Romains 36
L-5433 NIEDERDONVEN
tél.: +352 26 74 94 - 28
fax.: +352 26 74 94 99
http://www.metrico.lu
___
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/181913: devel/qt4-script: /usr/include/c++/v1/type_traits:3175:22: error: call to 'swap' is ambiguous
On Mon, 2013-09-09 at 07:51 -0600, Ian Lepore wrote: > On Mon, 2013-09-09 at 08:57 +0200, Stefan Esser wrote: > > Am 08.09.2013 08:14, schrieb O. Hartmann: > > > On Sat, 7 Sep 2013 22:49:54 GMT rak...@freebsd.org wrote: > > > > > >> Synopsis: devel/qt4-script: > > >> /usr/include/c++/v1/type_traits:3175:22: error: call to 'swap' is > > >> ambiguous > > >> > > >> State-Changed-From-To: open->patched State-Changed-By: rakuco > > >> State-Changed-When: Sat Sep 7 22:47:43 UTC 2013 > > >> State-Changed-Why: I don't think the previous version worked. > > >> > > >> From your description, it looks like you've switched to building > > >> with libc++ whereas libstdc++ was being used before. > > >> > > >> The upcoming Qt 4.8.5 plus a few patches which only made it to > > >> 4.8.6 (but we've backported) will finally make Qt build with > > >> libc++. > > >> > > >> We've just sent an exp-run request for Qt 4.8.5, and will > > >> hopefully fix all these errors once it is committed. > > >> > > >> http://www.freebsd.org/cgi/query-pr.cgi?pr=181913 > > > > > > > > > I build the world/kernel since early this year with > > > > > > CXXFLAGS+= -stdlib=libc++ CXXFLAGS+= > > > -std=c++11 > > > > > > > > > in /etc/src.conf. I do not use those flags in /etc/make.conf! > > > /etc/src.conf is supposed to target ONLY the /usr/src world, not > > > the ports - this is as I interpret the man page for /etc/src.conf > > > and it would be logical. But this rule/thinking seems to be broken > > > by some includes from /usr/ports/Mk ingredients. > > > > There are ports that use bsd.prog.mk instead of the Makefile supplied > > with the source files. Just grep for bsd.port.mk in the port's "files" > > sub directory, if you find that /etc/src.conf settings affect a port. > > > > I think these ports are in violation of POLA and had a longer mail > > exchange with a port maintainer, who told me that use of bsd.prog.mk > > was the preferred method to build binaries on FreeBSD, for base and > > for ports. > > > > So no file under /usr/ports/Mk is to blame, but some ports do > > implicitly reference /etc/src.conf via their use of bsd.prog.mk. > > > > Regards, STefan > > > > NB: I just performed the grep suggested above and found that the > > following ports mention bsd.prog.mk in files/*: > > > > > > If those ports .include before bsd.prog.mk, I think > everything should work properly. It looks like src.conf is an "opt-out" > system, and bsd.port.mk sets the variable to opt out. > > I don't especially like this (opt-in would be better), but I don't see > an easy fix either. We use bsd.prog.mk at $work (I'd better go add the > opt-out now), it seems like others probably do the same. > > It would be much better if the base build opted in, but the only way I > can see to do that would be to install a "makefile.up" system where a > makefile.up in every directory under the base src allows "walking up" to > the top of the src hierarchy no matter where the build is started from, > so that you can always get some top-level file to do the opt-in. Hrm. I take that back. You can't set _WITHOUT_SRCCONF and then .include and expect anything to work. For some reason all the setting of the MK_whatever knobs is disabled by setting _WITHOUT_SRCCONF, and without all those things defined, the rest of the bsd.*.mk files don't work. ::sigh:: What a mess. -- Ian ___ 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] Update of xorg libraries and MESA
09.09.2013 17:02, Koop Mast wrote:
^/releng/9, WITH_CLANG_IS_CC, CCACHE, WITH_NEW_XORG
You need to manual remove your old libGL and dri before updating to the
new version, as mentioned in the UPDATING file.
Oh, sorry.. I always mess the order of things. Thanks for a quick reply!
And how about this one:
===> Applying extra patch extra-config_devd.c
cat: extra-config_devd.c: No such file or directory
I can't seem to find a patch in there anywhere.
gmake[1]: Entering directory
`/tmp/ports/usr/ports/x11-servers/xorg-server/work/xorg-server-1.12.4/config'
gmake[1]: *** No rule to make target `devd.c', needed by `devd.lo'. Stop.
gmake[1]: Leaving directory
`/tmp/ports/usr/ports/x11-servers/xorg-server/work/xorg-server-1.12.4/config'
gmake: *** [all-recursive] Error 1
*** [do-build] Error code 1
--- x11-ervers/xorg-server/Makefile 2013-09-09 17:42:06.005017508 +0300
+++ x11-ervers/xorg-server/Makefile 2013-09-09 17:40:08.468020532 +0300
@@ -108,7 +108,7 @@
.endif
.if ${PORT_OPTIONS:MDEVD}
-EXTRA_PATCHES+=extra-config_devd.c
+EXTRA_PATCHES+=${FILESDIR}/extra-config_devd.c
.endif
.if ${PORT_OPTIONS:MAIGLX}
--
Sphinx of black quartz, judge my vow.
___
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: vlc 2.0.8 (with two PRs applied)
On Fri, Aug 30, 2013 at 08:25:01PM +0200, Pawel Pekala wrote: > Dnia 2013-08-28, o godz. 22:26:16 > Juergen Lock napisał(a): > > >Hi! > > > > It's this time again, there's a new vlc version out and I'd like to > >update the port: > > > > svn co https://svn.redports.org/nox/multimedia/vlc/ > > > > I have applied two PRs as well, ports/181596 and ports/181610, so > >livemedia and ncurses should work better now as well: > > > > http://www.freebsd.org/cgi/query-pr.cgi?pr=181596 > > Add subtitle, video, and audio track scrolling to VLC's > > ncurses.c module > > > > http://www.freebsd.org/cgi/query-pr.cgi?pr=181610 > > livemedia breakage > > > > Please give this update a good testing again, I've added the other > >changes from vlc's NEWS file below. > > Looking good. Just one small dependency missing: > > [corn:~]> pkg-lib-check vlc-2.0.8,3 > vlc-2.0.8,3: > missing dependency: audio/libgme > [corn:~]> pkg-lib-check -s libgme vlc-2.0.8,3 > vlc-2.0.8,3: > /usr/local/lib/vlc/plugins/demux/libgme_plugin.so > > Wanted to fill PR about this, but you were faster with new version ;) > And now I finally committed the update with this fix. Thanx to all testers, :) Juergen ___ 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: mapserver-6.2.1_2 building with python support requires python 2.6.
This throws a "this port is deprecated"-warning. EoL for python26 is 1 october 2013. Just a heads up. Regards David ___ 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"
What is MAKE_JOBS_UNSAFE?
In some ports that failto build/upgrade, with portmaster in this case, I get a message like gmake[1]: Leaving directory `/BETA1/usr/ports/multimedia/vlc/work9amd64/vlc-2.0.7' gmake: *** [all] Error 2 ===> Compilation failed unexpectedly. Try to set MAKE_JOBS_UNSAFE=yes and rebuild before reporting the failure to the maintainer. *** [do-build] Error code 1 I also got this with mplayer and graphics/gstreamer-plugins-gl, resulting from the instructions in UPDATING 20130731. I looked in man pages (portmaster, ports, make.conf, make) and online Porters' Handbook without finding anything. So I want to know what MAKE_JOBS_UNSAFE=yes is supposed to do, and do I set it by env MAKE_JOBS_UNSAFE=yes portmaster multimedia/vlc (or whatever other port it applies to)? 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"
INDEX build failed for 8.x
INDEX build failed with errors: Generating INDEX-8 - please wait.. Done. Warning: Duplicate INDEX entry: p5-SOAP-Transport-HTTP-Plack-0.03 Committers on the hook: antoine az delphij dinoex nox sunpoet Most recent SVN update was: Updating '.': Uemulators/fuse/Makefile Uemulators/bfe/Makefile Usysutils/downtime/pkg-plist Usysutils/downtime/Makefile UU devel/p5-Data-SExpression/Makefile UU devel/p5-Data-TreeDumper-Renderer-GTK/Makefile UU devel/p5-AnyEvent-Connection/Makefile UU devel/p5-RRDTool-OO/Makefile UU devel/p5-Log-Accounting-SVN/Makefile UU devel/p5-Filesys-Notify-KQueue/Makefile UU devel/p5-accessors/Makefile UU devel/p5-File-ChangeNotify/Makefile UU devel/p5-ZConf-GUI/Makefile UU devel/p5-List-Group/Makefile Udevel/p5-ParseLex/Makefile Udevel/Makefile UU devel/cvsd/Makefile UU devel/p5-MouseX-AttributeHelpers/Makefile UU devel/p5-HOP-Lexer/Makefile UU devel/p5-App-Control/Makefile UU devel/p5-Config-Grammar/Makefile UU devel/p5-Log-Dispatch-Dir/distinfo Udevel/p5-Log-Dispatch-Dir/Makefile UU devel/p5-Parallel-Scoreboard/Makefile UU devel/p5-Test-Filename/Makefile Adevel/p5-IO-SessionData Adevel/p5-IO-SessionData/pkg-plist Adevel/p5-IO-SessionData/Makefile Adevel/p5-IO-SessionData/distinfo Adevel/p5-IO-SessionData/pkg-descr Udevel/p5-MooseX-StrictConstructor/Makefile UU audio/libamrnb/pkg-plist UU audio/libamrnb/Makefile UU audio/libamrnb/distinfo UU audio/libamrwb/distinfo UU audio/libamrwb/pkg-plist UU audio/libamrwb/Makefile Atextproc/checkbashisms Atextproc/checkbashisms/Makefile Atextproc/checkbashisms/distinfo Atextproc/checkbashisms/pkg-descr Utextproc/libvisio/Makefile UU textproc/libvisio/distinfo UU textproc/libvisio/pkg-descr Utextproc/Makefile Utextproc/fcitx-m17n/Makefile Ugraphics/darktable/Makefile Ugraphics/apvlv/Makefile Asecurity/gpgdir Asecurity/gpgdir/Makefile Asecurity/gpgdir/distinfo Asecurity/gpgdir/pkg-descr Usecurity/p5-openxpki/Makefile Usecurity/Makefile UU security/p5-Mcrypt/pkg-plist UU security/p5-Mcrypt/Makefile Usecurity/openssl/Makefile Usecurity/p5-IO-Async-SSL/Makefile Usecurity/p5-IO-Async-SSL/distinfo Uscience/dcl/Makefile Uscience/gdis/Makefile Ux11-fm/emelfm2/Makefile Ux11-fm/catseye-fm/Makefile Uirc/cwirc/Makefile Ux11-clocks/alltraxclock/Makefile Ugames/frozenbubble/Makefile Ugames/freedoko/Makefile Ugames/battletanks/Makefile Ugames/csmash/Makefile UU net/p5-SOAP-Lite/pkg-plist Unet/p5-SOAP-Lite/Makefile Unet/Makefile Anet/p5-SOAP-Transport-HTTP-Plack Anet/p5-SOAP-Transport-HTTP-Plack/pkg-plist Anet/p5-SOAP-Transport-HTTP-Plack/Makefile Anet/p5-SOAP-Transport-HTTP-Plack/distinfo Anet/p5-SOAP-Transport-HTTP-Plack/pkg-descr Udatabases/lmdb/Makefile Udatabases/lmdb/distinfo Unet-mgmt/Makefile Anet-mgmt/p5-GRNOC-Config Anet-mgmt/p5-GRNOC-Config/Makefile Anet-mgmt/p5-GRNOC-Config/distinfo Anet-mgmt/p5-GRNOC-Config/pkg-descr Ux11-wm/afterstep-stable/pkg-plist Ux11-wm/afterstep-stable/Makefile Umultimedia/ffmpeg2theora/Makefile Umultimedia/vlc/Makefile Umultimedia/vlc/distinfo Dmultimedia/vlc/files/patch-modules-codec-avcodec-vaapi.c Dmultimedia/vlc/files/patch-modules-codec-flac.c Amultimedia/vlc/files/patch-modules-gui-ncurses.c A multimedia/vlc/files/patch-modules-stream_filter-dash-mpd-SegmentInfoCommon.h Amultimedia/vlc/files/patch-modules-gui-qt4-Makefile.in Amultimedia/vlc/files/patch-share-Makefile.in Ux11/docker/Makefile Ux11/eaglemode/Makefile Ux11/bmpanel2/Makefile Ux11/gdkxft/Makefile Ux11/bbrun/Makefile Uports-mgmt/bxpkg/Makefile Updated to revision 326841. ___ 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: CURRENT r255426: x11/nvidia-driver: nvidia_subr.c:835:46: error: too few arguments to function call, expected 10, have 9 (VM_PROT_READ | VM_PROT_WRITE), 0);
В Mon, 9 Sep 2013 22:37:48 +0200 "O. Hartmann" пишет: > x11/nvidia-driver (as well as emulators/virtualbox-ose-kmod) do not > compile on FreeBSD 10.0-CURRENT #0 r255426: Mon Sep 9 21:35:43 CEST > 2013 amd64. > > The error is: > > x11/nvidia-driver: > > --- nvidia_subr.o --- > nvidia_subr.c:835:46: error: too few arguments to function call, > expected 10, have 9 (VM_PROT_READ | VM_PROT_WRITE), 0); > ^ > @/vm/vm_map.h:368:1: note: 'vm_map_find' declared here > int vm_map_find(vm_map_t, vm_object_t, vm_ooffset_t, vm_offset_t *, > vm_size_t, ^ > 1 error generated. > *** [nvidia_subr.o] Error code 1 > > > emulators/virtualbox-ose-kmod: > > [...] > > /usr/ports/emulators/virtualbox-ose-kmod/work/VirtualBox-4.2.18/out/freebsd.amd64/release/bin/src/vboxdrv/r0drv/freebsd/alloc-r0drv-freebsd.c:83:76: > error: too few arguments to function call, expected 10, have 9 > cbAllocated, TRUE, VM_PROT_ALL, VM_PROT_ALL, 0); ^ > @/vm/vm_map.h:368:1: note: 'vm_map_find' declared here int > vm_map_find(vm_map_t, vm_object_t, vm_ooffset_t, vm_offset_t *, > vm_size_t, Try the following changes: int rc = vm_map_find(kernel_map, pVmObject, 0, &Addr, --- cbAllocated, TRUE, VM_PROT_ALL, VM_PROT_ALL, 0); +++ cbAllocated, 0, VMFS_OPTIMAL_SPACE, VM_PROT_ALL, VM_PROT_ALL, 0); for Nvidia driver need to make similar changes... ___ 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: What is MAKE_JOBS_UNSAFE?
Am 09.09.2013 22:22, schrieb Thomas Mueller:
> So I want to know what MAKE_JOBS_UNSAFE=yes is supposed to do, and do I set
> it by
>
> env MAKE_JOBS_UNSAFE=yes portmaster multimedia/vlc
> (or whatever other port it applies to)?
Thomas,
It prevents parallel ("make -j 4") build of ports, and your assumption
about how to set it is correct; alternatively, it can be given on the
make command line:
portmaster -mMAKE_JOBS_UNSAFE=yes multimedia/vlc.
URL: http://www.freebsd.org/doc/en/books/porters-handbook/building.html
It's described in Section 6.3.1 Building Ports in Parallel of the
porter's handbook, and apparently a bit out of date, because
MAKE_JOBS_SAFE=yes is now the default, and this feature must explicitly
be _disabled_.
Can someone from among the doc committers team please reflect the new
default in the Porter's Handbook? (I was looking at r42618.)
HTH
Matthias
signature.asc
Description: OpenPGP digital signature
Re: CURRENT r255426: x11/nvidia-driver: nvidia_subr.c:835:46: error: too few arguments to function call, expected 10, have 9 (VM_PROT_READ | VM_PROT_WRITE), 0);
On Tue, 10 Sep 2013 00:02:37 +0300 Ivan Klymenko wrote: > В Mon, 9 Sep 2013 22:37:48 +0200 > "O. Hartmann" пишет: > > > x11/nvidia-driver (as well as emulators/virtualbox-ose-kmod) do not > > compile on FreeBSD 10.0-CURRENT #0 r255426: Mon Sep 9 21:35:43 > > CEST 2013 amd64. > > > > The error is: > > > > x11/nvidia-driver: > > > > --- nvidia_subr.o --- > > nvidia_subr.c:835:46: error: too few arguments to function call, > > expected 10, have 9 (VM_PROT_READ | VM_PROT_WRITE), 0); > > ^ > > @/vm/vm_map.h:368:1: note: 'vm_map_find' declared here > > int vm_map_find(vm_map_t, vm_object_t, vm_ooffset_t, vm_offset_t *, > > vm_size_t, ^ > > 1 error generated. > > *** [nvidia_subr.o] Error code 1 > > > > > > emulators/virtualbox-ose-kmod: > > > > [...] > > > > /usr/ports/emulators/virtualbox-ose-kmod/work/VirtualBox-4.2.18/out/freebsd.amd64/release/bin/src/vboxdrv/r0drv/freebsd/alloc-r0drv-freebsd.c:83:76: > > error: too few arguments to function call, expected 10, have 9 > > cbAllocated, TRUE, VM_PROT_ALL, VM_PROT_ALL, 0); ^ > > @/vm/vm_map.h:368:1: note: 'vm_map_find' declared here int > > vm_map_find(vm_map_t, vm_object_t, vm_ooffset_t, vm_offset_t *, > > vm_size_t, > > Try the following changes: > int rc = vm_map_find(kernel_map, pVmObject, 0, &Addr, > --- cbAllocated, TRUE, VM_PROT_ALL, > VM_PROT_ALL, 0); +++ cbAllocated, 0, > VMFS_OPTIMAL_SPACE, VM_PROT_ALL, VM_PROT_ALL, 0); > > for Nvidia driver need to make similar changes... > ___ > freebsd-curr...@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to > "freebsd-current-unsubscr...@freebsd.org" The man page of vm_map_find() says the last parameter is of int, named int cow. On the hurry, I didn't find any explanation of that parameter. Setting it to "0" (zero) also in the nvidia_subr.c makes the driver compile again. But simply filling in a int zero is a bit strange without knowing what to do, isn't it? Thanks anyway, Oliver signature.asc Description: PGP signature
CURRENT r255426: x11/nvidia-driver: nvidia_subr.c:835:46: error: too few arguments to function call, expected 10, have 9 (VM_PROT_READ | VM_PROT_WRITE), 0);
x11/nvidia-driver (as well as emulators/virtualbox-ose-kmod) do not compile on FreeBSD 10.0-CURRENT #0 r255426: Mon Sep 9 21:35:43 CEST 2013 amd64. The error is: x11/nvidia-driver: --- nvidia_subr.o --- nvidia_subr.c:835:46: error: too few arguments to function call, expected 10, have 9 (VM_PROT_READ | VM_PROT_WRITE), 0); ^ @/vm/vm_map.h:368:1: note: 'vm_map_find' declared here int vm_map_find(vm_map_t, vm_object_t, vm_ooffset_t, vm_offset_t *, vm_size_t, ^ 1 error generated. *** [nvidia_subr.o] Error code 1 emulators/virtualbox-ose-kmod: [...] /usr/ports/emulators/virtualbox-ose-kmod/work/VirtualBox-4.2.18/out/freebsd.amd64/release/bin/src/vboxdrv/r0drv/freebsd/alloc-r0drv-freebsd.c:83:76: error: too few arguments to function call, expected 10, have 9 cbAllocated, TRUE, VM_PROT_ALL, VM_PROT_ALL, 0); ^ @/vm/vm_map.h:368:1: note: 'vm_map_find' declared here int vm_map_find(vm_map_t, vm_object_t, vm_ooffset_t, vm_offset_t *, vm_size_t, signature.asc Description: PGP signature
Re: CURRENT r255426: x11/nvidia-driver: nvidia_subr.c:835:46: error: too few arguments to function call, expected 10, have 9 (VM_PROT_READ | VM_PROT_WRITE), 0);
В Mon, 9 Sep 2013 23:17:13 +0200 "O. Hartmann" пишет: > On Tue, 10 Sep 2013 00:02:37 +0300 > Ivan Klymenko wrote: > > > В Mon, 9 Sep 2013 22:37:48 +0200 > > "O. Hartmann" пишет: > > > > > > /usr/ports/emulators/virtualbox-ose-kmod/work/VirtualBox-4.2.18/out/freebsd.amd64/release/bin/src/vboxdrv/r0drv/freebsd/alloc-r0drv-freebsd.c:83:76: > > > error: too few arguments to function call, expected 10, have 9 > > > cbAllocated, TRUE, VM_PROT_ALL, VM_PROT_ALL, 0); ^ > > > @/vm/vm_map.h:368:1: note: 'vm_map_find' declared here int > > > vm_map_find(vm_map_t, vm_object_t, vm_ooffset_t, vm_offset_t *, > > > vm_size_t, > > > > Try the following changes: > > int rc = vm_map_find(kernel_map, pVmObject, 0, &Addr, > > --- cbAllocated, TRUE, VM_PROT_ALL, > > VM_PROT_ALL, 0); +++ cbAllocated, 0, > > VMFS_OPTIMAL_SPACE, VM_PROT_ALL, VM_PROT_ALL, 0); > > > > for Nvidia driver need to make similar changes... > The man page of vm_map_find() says the last parameter is of int, named > int cow. On the hurry, I didn't find any explanation of that > parameter. Setting it to "0" (zero) also in the nvidia_subr.c makes > the driver compile again. > > But simply filling in a int zero is a bit strange without knowing what > to do, isn't it? > > Thanks anyway, > > Oliver This commit you to find an appropriate example ... http://docs.freebsd.org/cgi/getmsg.cgi?fetch=291456+0+current/svn-src-head And in this case, the driver Nvidia really need to specify 0 in place of the sixth argument ... but I'm not sure at 100% :) ___ 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: CURRENT r255426: x11/nvidia-driver: nvidia_subr.c:835:46: error: too few arguments to function call, expected 10, have 9 (VM_PROT_READ | VM_PROT_WRITE), 0);
On Mon, 09 Sep 2013 16:49:23 -0600
Ian Lepore wrote:
> On Tue, 2013-09-10 at 00:42 +0200, O. Hartmann wrote:
> > On Tue, 10 Sep 2013 00:24:05 +0300
> > Ivan Klymenko wrote:
> >
> > > В Mon, 9 Sep 2013 23:17:13 +0200
> > > "O. Hartmann" пишет:
> > >
> > > > On Tue, 10 Sep 2013 00:02:37 +0300
> > > > Ivan Klymenko wrote:
> > > >
> > > > > В Mon, 9 Sep 2013 22:37:48 +0200
> > > > > "O. Hartmann" пишет:
> > > > > >
> > > > > > /usr/ports/emulators/virtualbox-ose-kmod/work/VirtualBox-4.2.18/out/freebsd.amd64/release/bin/src/vboxdrv/r0drv/freebsd/alloc-r0drv-freebsd.c:83:76:
> > > > > > error: too few arguments to function call, expected 10,
> > > > > > have 9 cbAllocated, TRUE, VM_PROT_ALL, VM_PROT_ALL, 0); ^
> > > > > > @/vm/vm_map.h:368:1: note: 'vm_map_find' declared here int
> > > > > > vm_map_find(vm_map_t, vm_object_t, vm_ooffset_t,
> > > > > > vm_offset_t *, vm_size_t,
> > > > >
> > > > > Try the following changes:
> > > > > int rc = vm_map_find(kernel_map, pVmObject, 0, &Addr,
> > > > > --- cbAllocated, TRUE, VM_PROT_ALL,
> > > > > VM_PROT_ALL, 0); +++ cbAllocated, 0,
> > > > > VMFS_OPTIMAL_SPACE, VM_PROT_ALL, VM_PROT_ALL, 0);
> > > > >
> > > > > for Nvidia driver need to make similar changes...
> > > > The man page of vm_map_find() says the last parameter is of int,
> > > > named int cow. On the hurry, I didn't find any explanation of
> > > > that parameter. Setting it to "0" (zero) also in the
> > > > nvidia_subr.c makes the driver compile again.
> > > >
> > > > But simply filling in a int zero is a bit strange without
> > > > knowing what to do, isn't it?
> > > >
> > > > Thanks anyway,
> > > >
> > > > Oliver
> > >
> > > This commit you to find an appropriate example ...
> > > http://docs.freebsd.org/cgi/getmsg.cgi?fetch=291456+0+current/svn-src-head
> > > And in this case, the driver Nvidia really need to specify 0 in
> > > place of the sixth argument ...
> > > but I'm not sure at 100% :)
> >
> > I have a patch attached for the x11/nvidia-driver Makefile. It
> > doesn't work and I loose hairs due to not knowing why.
> >
> > When issuing the following command sequence on the console:
> >
> > cd /usr/ports/x11/nvidia-driver
> > make clean extract
> > sed -i -e '/(VM_PROT_READ | VM_PROT_WRITE), 0);$/s/0);$/0, 0);/g' \
> > work/NVIDIA-FreeBSD-x86_64-325.15/src/nvidia_subr.c
> >
> >
> > and check then line 835 (the corrupt one) in file
> > work/NVIDIA-FreeBSD-x86_64-325.15/src/nvidia_subr.c,
> >
> > I see this BEFORE:
> >
> > status = vm_map_find(kernel_map, at->object, (i * PAGE_SIZE),
> > &virtual_address, size, VMFS_ANY_SPACE,
> > (VM_PROT_READ | VM_PROT_WRITE),
> > ===(835)>>(VM_PROT_READ | VM_PROT_WRITE), 0);
> >
> >
> > and I see this AFTER the sed'ed replacement:
> >
> > status = vm_map_find(kernel_map, at->object, (i * PAGE_SIZE),
> > &virtual_address, size, VMFS_ANY_SPACE,
> > (VM_PROT_READ | VM_PROT_WRITE),
> > ===(835)>>(VM_PROT_READ | VM_PROT_WRITE), 0, 0);
> >
> > BUT: Using the patch (see attached, please apply to
> > x11/nvidia-driver/Makefile) gives me an error in x11/nvidia-driver:
> >
> > make clean patch
> >
> > ===> 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: "/(VM_PROT_READ | VM_PRO ...": invalid command code 0
> > *** Error code 1
> >
> > The Shell/make should be able to substitute within a single-quotet
> > command to sed, but the error message reports differently.
> >
> > Do not be confused about the driver revision I use. I tried the
> > official one (319.XX) as well and it is not working the very same
> > way and the patch won't either.
> >
> > Oliver
>
> I don't know about the sed error, but I think the change you're trying
> to make is wrong. The new '0' parameter to vm_map_find() isn't added
> at the end, it goes after the size parameter.
>
> -- Ian
Yes, you're correct and my face is red like a tomatoe :-(
I try this sed replacement expression:
sed -i -e '/\&virtual_address\, size\, \
VMFS_ANY\_SPACE\,$/s//\&virtual_address\, size\, 0\, \
VMFS_ANY\_SPACE\,/g' work/NVIDIA-FreeBSD-x86_64-325.15/src/nvidia_subr.c
It works from the command line, but it doesn't work from the (attached)
Makefile-patch.
--- Makefile.orig 2013-09-10 00:30:53.0 +0200
+++ Makefile 2013-09-10 01:04:05.0 +0200
@@ -160,6 +160,12 @@
s/CAP_IOCTL/cap_rights_init(\&rights, &)/' \
${WRKSRC}/src/nvidia_linux.c
.endif
+# Changes in vm_map_find() due to r255426
+.if ${OSVERSION} > 153
+ ${REI
Re: CURRENT r255426: x11/nvidia-driver: nvidia_subr.c:835:46: error: too few arguments to function call, expected 10, have 9 (VM_PROT_READ | VM_PROT_WRITE), 0);
On Tue, 2013-09-10 at 00:42 +0200, O. Hartmann wrote: > On Tue, 10 Sep 2013 00:24:05 +0300 > Ivan Klymenko wrote: > > > В Mon, 9 Sep 2013 23:17:13 +0200 > > "O. Hartmann" пишет: > > > > > On Tue, 10 Sep 2013 00:02:37 +0300 > > > Ivan Klymenko wrote: > > > > > > > В Mon, 9 Sep 2013 22:37:48 +0200 > > > > "O. Hartmann" пишет: > > > > > > > > > > /usr/ports/emulators/virtualbox-ose-kmod/work/VirtualBox-4.2.18/out/freebsd.amd64/release/bin/src/vboxdrv/r0drv/freebsd/alloc-r0drv-freebsd.c:83:76: > > > > > error: too few arguments to function call, expected 10, have 9 > > > > > cbAllocated, TRUE, VM_PROT_ALL, VM_PROT_ALL, 0); ^ > > > > > @/vm/vm_map.h:368:1: note: 'vm_map_find' declared here int > > > > > vm_map_find(vm_map_t, vm_object_t, vm_ooffset_t, vm_offset_t *, > > > > > vm_size_t, > > > > > > > > Try the following changes: > > > > int rc = vm_map_find(kernel_map, pVmObject, 0, &Addr, > > > > --- cbAllocated, TRUE, VM_PROT_ALL, > > > > VM_PROT_ALL, 0); +++ cbAllocated, 0, > > > > VMFS_OPTIMAL_SPACE, VM_PROT_ALL, VM_PROT_ALL, 0); > > > > > > > > for Nvidia driver need to make similar changes... > > > The man page of vm_map_find() says the last parameter is of int, > > > named int cow. On the hurry, I didn't find any explanation of that > > > parameter. Setting it to "0" (zero) also in the nvidia_subr.c makes > > > the driver compile again. > > > > > > But simply filling in a int zero is a bit strange without knowing > > > what to do, isn't it? > > > > > > Thanks anyway, > > > > > > Oliver > > > > This commit you to find an appropriate example ... > > http://docs.freebsd.org/cgi/getmsg.cgi?fetch=291456+0+current/svn-src-head > > And in this case, the driver Nvidia really need to specify 0 in place > > of the sixth argument ... > > but I'm not sure at 100% :) > > I have a patch attached for the x11/nvidia-driver Makefile. It doesn't > work and I loose hairs due to not knowing why. > > When issuing the following command sequence on the console: > > cd /usr/ports/x11/nvidia-driver > make clean extract > sed -i -e '/(VM_PROT_READ | VM_PROT_WRITE), 0);$/s/0);$/0, 0);/g' \ > work/NVIDIA-FreeBSD-x86_64-325.15/src/nvidia_subr.c > > > and check then line 835 (the corrupt one) in file > work/NVIDIA-FreeBSD-x86_64-325.15/src/nvidia_subr.c, > > I see this BEFORE: > > status = vm_map_find(kernel_map, at->object, (i * PAGE_SIZE), > &virtual_address, size, VMFS_ANY_SPACE, > (VM_PROT_READ | VM_PROT_WRITE), > ===(835)>>(VM_PROT_READ | VM_PROT_WRITE), 0); > > > and I see this AFTER the sed'ed replacement: > > status = vm_map_find(kernel_map, at->object, (i * PAGE_SIZE), > &virtual_address, size, VMFS_ANY_SPACE, > (VM_PROT_READ | VM_PROT_WRITE), > ===(835)>>(VM_PROT_READ | VM_PROT_WRITE), 0, 0); > > BUT: Using the patch (see attached, please apply to > x11/nvidia-driver/Makefile) gives me an error in x11/nvidia-driver: > > make clean patch > > ===> 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: "/(VM_PROT_READ | VM_PRO ...": invalid command code 0 > *** Error code 1 > > The Shell/make should be able to substitute within a single-quotet > command to sed, but the error message reports differently. > > Do not be confused about the driver revision I use. I tried the > official one (319.XX) as well and it is not working the very same way > and the patch won't either. > > Oliver I don't know about the sed error, but I think the change you're trying to make is wrong. The new '0' parameter to vm_map_find() isn't added at the end, it goes after the size parameter. -- Ian ___ 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: CURRENT r255426: x11/nvidia-driver: nvidia_subr.c:835:46: error: too few arguments to function call, expected 10, have 9 (VM_PROT_READ | VM_PROT_WRITE), 0);
On Tue, 10 Sep 2013 00:24:05 +0300
Ivan Klymenko wrote:
> В Mon, 9 Sep 2013 23:17:13 +0200
> "O. Hartmann" пишет:
>
> > On Tue, 10 Sep 2013 00:02:37 +0300
> > Ivan Klymenko wrote:
> >
> > > В Mon, 9 Sep 2013 22:37:48 +0200
> > > "O. Hartmann" пишет:
> > > >
> > > > /usr/ports/emulators/virtualbox-ose-kmod/work/VirtualBox-4.2.18/out/freebsd.amd64/release/bin/src/vboxdrv/r0drv/freebsd/alloc-r0drv-freebsd.c:83:76:
> > > > error: too few arguments to function call, expected 10, have 9
> > > > cbAllocated, TRUE, VM_PROT_ALL, VM_PROT_ALL, 0); ^
> > > > @/vm/vm_map.h:368:1: note: 'vm_map_find' declared here int
> > > > vm_map_find(vm_map_t, vm_object_t, vm_ooffset_t, vm_offset_t *,
> > > > vm_size_t,
> > >
> > > Try the following changes:
> > > int rc = vm_map_find(kernel_map, pVmObject, 0, &Addr,
> > > --- cbAllocated, TRUE, VM_PROT_ALL,
> > > VM_PROT_ALL, 0); +++ cbAllocated, 0,
> > > VMFS_OPTIMAL_SPACE, VM_PROT_ALL, VM_PROT_ALL, 0);
> > >
> > > for Nvidia driver need to make similar changes...
> > The man page of vm_map_find() says the last parameter is of int,
> > named int cow. On the hurry, I didn't find any explanation of that
> > parameter. Setting it to "0" (zero) also in the nvidia_subr.c makes
> > the driver compile again.
> >
> > But simply filling in a int zero is a bit strange without knowing
> > what to do, isn't it?
> >
> > Thanks anyway,
> >
> > Oliver
>
> This commit you to find an appropriate example ...
> http://docs.freebsd.org/cgi/getmsg.cgi?fetch=291456+0+current/svn-src-head
> And in this case, the driver Nvidia really need to specify 0 in place
> of the sixth argument ...
> but I'm not sure at 100% :)
I have a patch attached for the x11/nvidia-driver Makefile. It doesn't
work and I loose hairs due to not knowing why.
When issuing the following command sequence on the console:
cd /usr/ports/x11/nvidia-driver
make clean extract
sed -i -e '/(VM_PROT_READ | VM_PROT_WRITE), 0);$/s/0);$/0, 0);/g' \
work/NVIDIA-FreeBSD-x86_64-325.15/src/nvidia_subr.c
and check then line 835 (the corrupt one) in file
work/NVIDIA-FreeBSD-x86_64-325.15/src/nvidia_subr.c,
I see this BEFORE:
status = vm_map_find(kernel_map, at->object, (i * PAGE_SIZE),
&virtual_address, size, VMFS_ANY_SPACE,
(VM_PROT_READ | VM_PROT_WRITE),
===(835)>>(VM_PROT_READ | VM_PROT_WRITE), 0);
and I see this AFTER the sed'ed replacement:
status = vm_map_find(kernel_map, at->object, (i * PAGE_SIZE),
&virtual_address, size, VMFS_ANY_SPACE,
(VM_PROT_READ | VM_PROT_WRITE),
===(835)>>(VM_PROT_READ | VM_PROT_WRITE), 0, 0);
BUT: Using the patch (see attached, please apply to
x11/nvidia-driver/Makefile) gives me an error in x11/nvidia-driver:
make clean patch
===> 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: "/(VM_PROT_READ | VM_PRO ...": invalid command code 0
*** Error code 1
The Shell/make should be able to substitute within a single-quotet
command to sed, but the error message reports differently.
Do not be confused about the driver revision I use. I tried the
official one (319.XX) as well and it is not working the very same way
and the patch won't either.
Oliver
--- Makefile.orig 2013-09-10 00:30:53.0 +0200
+++ Makefile 2013-09-10 00:40:08.0 +0200
@@ -160,6 +160,11 @@
s/CAP_IOCTL/cap_rights_init(\&rights, &)/' \
${WRKSRC}/src/nvidia_linux.c
.endif
+# Changes in vm_map_find() due to r255426
+.if ${OSVERSION} >= 154
+ ${REINPLACE_CMD} -e '/(VM_PROT_READ | VM_PROT_WRITE), 0);$/s/0);$/0, 0);/g' \
+ ${WRKSRC}/src/nvidia_subr.c
+.endif
# Fix stack buffer overflow in nvidia_sysctl_bus_type()
.if ${NVVERSION} < 3192300
${REINPLACE_CMD} -E '/bus_type\[4\]/d ; \
signature.asc
Description: PGP signature
HELP! nvidia-driver patch: Weird REPLACE_CMD and command-line-sed behaviour. HELP!
With CURRENT r255426 several changes has been introduced (see
http://docs.freebsd.org/cgi/getmsg.cgi?fetch=291456+0+current/svn-src-head).
This results in a non-functionality of the x11/nvidia-driver port after
updating world and kernel to CURRENT r255426.
I try to patch this. The target file is src/nvidia_subr.c, line 833
(nVidia driver 325.15, 319.XX might differ).
The solution is to insert a zero (0) after the size parameter, which
can be targetted by the sed-expression
sed -i -e 's/\(\&virtual_address, size,\) \(VMFS_ANY_SPACE,\)$/ \
\1 0, \2/' work/NVIDIA-FreeBSD-x86_64-325.15/src/nvidia_subr.c
(do "make clean patch" first in x11/nvidia-driver).
Checking work/NVIDIA-FreeBSD-x86_64-325.15/src/nvidia_subr.c at line
833 reveals:
&virtual_address, size, 0, VMFS_ANY_SPACE,
which is exactly what I wanted. 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
Stop.
make[1]: stopped in /usr/ports/x11/nvidia-driver
*** Error code 1
Stop.
make: stopped in /usr/ports/x11/nvidia-driver
What the f*** is going on here? The expression in single-quotes is
supposed not to substituted by the shell/make, isn't it?
What I am doing wrong here?
I filed a PR (ports/181972) for the nvidia problem, but I'm incapale
of providing the patch due to this sticky obscure fault.
Oliver
--- Makefile.orig 2013-09-10 00:30:53.0 +0200
+++ Makefile 2013-09-10 01:30:21.0 +0200
@@ -160,6 +160,11 @@
s/CAP_IOCTL/cap_rights_init(\&rights, &)/' \
${WRKSRC}/src/nvidia_linux.c
.endif
+# 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
# Fix stack buffer overflow in nvidia_sysctl_bus_type()
.if ${NVVERSION} < 3192300
${REINPLACE_CMD} -E '/bus_type\[4\]/d ; \
signature.asc
Description: PGP signature
INDEX build failed for 8.x
INDEX build failed with errors: Generating INDEX-8 - please wait.. Done. Warning: Duplicate INDEX entry: p5-SOAP-Transport-HTTP-Plack-0.03 Committers on the hook: antoine az bar delphij dinoex mandree mm nox rakuco sunpoet wg Most recent SVN update was: Updating '.': Uaudio/audacity/Makefile Uaudio/audacity/distinfo Udeskutils/docear/Makefile Udeskutils/docear/distinfo Ux11-toolkits/fox17/Makefile Ugames/vavoom-extras/Makefile Ugames/vavoom-extras/distinfo Ugames/vavoom-extras/pkg-plist Ugames/netradiant/Makefile Utextproc/wiggle/Makefile Utextproc/wiggle/distinfo Unet/hupnp/Makefile Unet/hupnp/pkg-descr Dnet/hupnp/files/patch-herqq.pro Unet/hupnp/files/patch-hmulticast_socket.cpp Unet/crtmpserver/files/crtmpserver.in Unet/crtmpserver/pkg-plist Unet/crtmpserver/Makefile Unet/crtmpserver/distinfo Unet/crtmpserver/pkg-descr Ugraphics/opencv/pkg-descr Ugraphics/sdl2_image/Makefile Ugraphics/leptonica/Makefile Ugraphics/sdl_image/Makefile Ugraphics/gdal/Makefile Ugraphics/ImageMagick/Makefile Ugraphics/openimageio/Makefile Ugraphics/webp/pkg-plist Ugraphics/webp/Makefile Ugraphics/webp/distinfo Ugraphics/ida/Makefile Uwww/xpi-firebug/pkg-plist Uwww/xpi-firebug/Makefile Uwww/xpi-firebug/distinfo Uwww/xpi-adblock_plus/pkg-plist Uwww/xpi-adblock_plus/Makefile Uwww/xpi-adblock_plus/distinfo Uwww/netsurf/Makefile Updated to revision 326853. ___ 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: What is MAKE_JOBS_UNSAFE?
> Thomas,
> It prevents parallel ("make -j 4") build of ports, and your assumption
> about how to set it is correct; alternatively, it can be given on the
> make command line:
> portmaster -mMAKE_JOBS_UNSAFE=yes multimedia/vlc.
> URL: http://www.freebsd.org/doc/en/books/porters-handbook/building.html
> It's described in Section 6.3.1 Building Ports in Parallel of the
> porter's handbook, and apparently a bit out of date, because
> MAKE_JOBS_SAFE=yes is now the default, and this feature must explicitly
> be _disabled_.
> Can someone from among the doc committers team please reflect the new
> default in the Porter's Handbook? (I was looking at r42618.)
HTH
> Matthias
If MAKE_JOBS_UNSAFE=yes is already the default, then presumably trying to build
or upgrade a port will fail just the same with this part specified?
Now "pkg info -r gio-fam-backend" shows
gio-fam-backend-2.34.3:
mplayer-1.1.r20130308
gstreamer-plugins-gl-0.10.3_1
vlc-2.0.6_3,3
So to go to the last step ("portmaster -a") in this UPDATING 20130731, I have
to somehow upgrade or get rid of those three reverse dependencies, or possibly
pkg delete -f gio-fam-backend
I see in other posts that vlc has had a further update/commit, and I could
switch from mplayer to mplayer2, but what about gstreamer-plugins-gl, or is
this not critical?
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"
INDEX build failed for 8.x
INDEX build failed with errors: Generating INDEX-8 - please wait.. Done. Warning: Duplicate INDEX entry: p5-SOAP-Transport-HTTP-Plack-0.03 Committers on the hook: antoine az bar delphij dinoex mandree mm nox rakuco sunpoet tabthorpe wg Most recent SVN update was: Updating '.': Uwww/py-flexget/Makefile Uwww/py-flexget/distinfo Umisc/bibletime/Makefile Umath/giacxcas/pkg-plist Umath/giacxcas/Makefile Umath/giacxcas/distinfo Updated to revision 326856. ___ 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: What is MAKE_JOBS_UNSAFE?
> Thomas,
> It prevents parallel ("make -j 4") build of ports, and your assumption
> about how to set it is correct; alternatively, it can be given on the
> make command line:
> portmaster -mMAKE_JOBS_UNSAFE=yes multimedia/vlc.
> URL: http://www.freebsd.org/doc/en/books/porters-handbook/building.html
> It's described in Section 6.3.1 Building Ports in Parallel of the
> porter's handbook, and apparently a bit out of date, because
> MAKE_JOBS_SAFE=yes is now the default, and this feature must explicitly
> be _disabled_.
> Can someone from among the doc committers team please reflect the new
> default in the Porter's Handbook? (I was looking at r42618.)
HTH
> Matthias
If MAKE_JOBS_UNSAFE=yes is already the default, then presumably trying to build
or upgrade a port will fail just the same with this part specified?
Now "pkg info -r gio-fam-backend" shows
gio-fam-backend-2.34.3:
mplayer-1.1.r20130308
gstreamer-plugins-gl-0.10.3_1
vlc-2.0.6_3,3
So to go to the last step ("portmaster -a") in this UPDATING 20130731, I have
to somehow upgrade or get rid of those three reverse dependencies, or possibly
pkg delete -f gio-fam-backend
I see in other posts that vlc has had a further update/commit, and I could
switch from mplayer to mplayer2, but what about gstreamer-plugins-gl, or is
this not critical?
Update: I did
portmaster -o multimedia/mplayer2 multimedia/mplayer
successfully, but failed with vlc and gstreamer-plugins-gl.
Can I safely
pkg delete -f gio-fam-backend
since its function is (?) presumably filled by glib 2.36 ?
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"
Re: AFFECTS: 10-CURRENT users with any port depending on converters/libiconv
On Sat, Sep 7, 2013 at 5:10 AM, olli hauer wrote:
> There are 13 ports using --with-iconv=${LOCALBASE}
> devel/apr1
> devel/apr2
> devel/git
> irc/epic5
> lang/gauche
> net-mgmt/ettercap
> net/ssltunnel-client
> net/yaz
> net/zebra-server
> textproc/libxml2
> textproc/py-libxml2
> www/apache22
> www/apache24
>
>
> and devel/glib20, print/ghostscript8, print/ghostscript9 using
> --with-libiconv=gnu
> --with-libiconv=native
> --with-libiconv=no
> --with-libiconv=no
>
I am hitting following failure while building devel/glib20
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
How do I get past this?
% uname -a
FreeBSD flymockour-l7.corp.yahoo.com 10.0-CURRENT FreeBSD 10.0-CURRENT #2
r255423M: Mon Sep 9 12:29:22 PDT 2013
r...@flymockour-l7.corp.yahoo.com:/usr/obj/usr/home/hirenp/head/sys/GENERIC
amd64
% cat /etc/src.conf
WITH_LIBICONV_COMPAT=y
BOOT_COMCONSOLE_SPEED=115200
PORTS_MODULES=x11/nvidia-driver
cheers,
Hiren
>
> Unfortunately Uses/iconv.mk defines only --with-libiconv(-prefix).
>
> If Uses/iconv.mk can be extended with something like ICON_PATH, then
> the 13 ports can be changed quickly to use the right iconv.
>
> --
> Regards,
> olli
> ___
> freebsd-curr...@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
>
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: What is MAKE_JOBS_UNSAFE?
Am 10.09.2013 06:06, schrieb Thomas Mueller:
>> Thomas,
>
>> It prevents parallel ("make -j 4") build of ports, and your assumption
>> about how to set it is correct; alternatively, it can be given on the
>> make command line:
>
>> portmaster -mMAKE_JOBS_UNSAFE=yes multimedia/vlc.
>
>> URL: http://www.freebsd.org/doc/en/books/porters-handbook/building.html
>
>> It's described in Section 6.3.1 Building Ports in Parallel of the
>> porter's handbook, and apparently a bit out of date, because
>> MAKE_JOBS_SAFE=yes is now the default, and this feature must explicitly
>> be _disabled_.
>
>> Can someone from among the doc committers team please reflect the new
>> default in the Porter's Handbook? (I was looking at r42618.)
>
> HTH
>> Matthias
>
> If MAKE_JOBS_UNSAFE=yes is already the default, then presumably trying to
> build or upgrade a port will fail just the same with this part specified?
FORCE_MAKE_JOBS is the new default, meaning that:
Unless MAKE_JOBS_UNSAFE is defined, MAKE_JOBS_SAFE is assumed.
You should not see the ports framework message telling you to retry if
MAKE_JOBS_UNSAFE is set.
> I see in other posts that vlc has had a further update/commit, and I could
> switch from mplayer to mplayer2, but what about gstreamer-plugins-gl, or is
> this not critical?
I have not followed what's needed there.
> Can I safely
> pkg delete -f gio-fam-backend
> since its function is (?) presumably filled by glib 2.36 ?
Yes, providing that you've rebuilt all ports that did previously require
gio-fam-backend.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
INDEX now builds successfully on 8.x
___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: FreeBSD Port: mapserver-6.2.1_2 building with python support requires python 2.6.
David Wahlund wrote on 09.09.2013 22:46: This throws a "this port is deprecated"-warning. EoL for python26 is 1 october 2013. Just a heads up. Regards David It builds fine python 2.7: https://redports.org/~rm/20130909204800-7664-143662/mapserver-6.2.1_3.log Would you try to change USE_PYTHON to -2.7 and check if it works for you? -- Regards, Ruslan Tinderboxing kills... the drives. ___ 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] Update of xorg libraries and MESA
On Mon, 09 Sep 2013 16:52:03 +0200, Niclas Zeising wrote Hi Nicolas, > The patch has been updated, and the updated version is attached. As > always, it is possible to find the latest version of the patch at > http://people.freebsd.org/~zeising/xorg-mesaupdate.diff Works like a charm on my Lenovo X220 (-CURRENT). Thanks ! -- Ganael LAPLANCHE http://www.martymac.org | http://contribs.martymac.org FreeBSD: martymac , http://www.FreeBSD.org ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: FreeBSD Port: mapserver-6.2.1_2 building with python support requires python 2.6.
Am 2013-09-10 08:11, schrieb Ruslan Makhmatkhanov: David Wahlund wrote on 09.09.2013 22:46: This throws a "this port is deprecated"-warning. EoL for python26 is 1 october 2013. Just a heads up. Regards David It builds fine python 2.7: https://redports.org/~rm/20130909204800-7664-143662/mapserver-6.2.1_3.log Would you try to change USE_PYTHON to -2.7 and check if it works for you? I'm doing this already. For me, in line 55 in the Makefile, I have the following line: USE_PYTHON= 2.7 and Mapscript works as usual ... Frank -- Frank BRONIEWSKI METRICO s.à r.l. géomètres technologies d'information géographique rue des Romains 36 L-5433 NIEDERDONVEN tél.: +352 26 74 94 - 28 fax.: +352 26 74 94 99 http://www.metrico.lu ___ 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: AFFECTS: 10-CURRENT users with any port depending on converters/libiconv
On 09/10/13 07:20, hiren panchasara wrote:
On Sat, Sep 7, 2013 at 5:10 AM, olli hauer mailto:oha...@gmx.de>> wrote:
There are 13 ports using --with-iconv=${LOCALBASE}
devel/apr1
devel/apr2
devel/git
irc/epic5
lang/gauche
net-mgmt/ettercap
net/ssltunnel-client
net/yaz
net/zebra-server
textproc/libxml2
textproc/py-libxml2
www/apache22
www/apache24
and devel/glib20, print/ghostscript8, print/ghostscript9 using
--with-libiconv=gnu
--with-libiconv=native
--with-libiconv=no
--with-libiconv=no
I am hitting following failure while building devel/glib20
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
How do I get past this?
Looks like you have some leftovers from the libiconv port. Have you
removed it? can you give the output of ls /usr/local/include/iconv.h?
What is the output if "head /usr/include/iconv.h"?
% uname -a
FreeBSD flymockour-l7.corp.yahoo.com
10.0-CURRENT FreeBSD 10.0-CURRENT
#2 r255423M: Mon Sep 9 12:29:22 PDT 2013
That M in the revision number indicates you're using a modified
checkout, May I ask which modifications you have in your source tree?
--
Guido Falsi
___
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"
