Re: [CFT] gdal 1.9.1 update and other changes
Am 07.06.2012 05:30 (UTC+1) schrieb Sunpoet Po-Chuan Hsieh: Hi, Many thanks for this update. What I observed so far: (1) graphics/gdal builds and installs fine. There is a minor problem: dependend port science/libkml (as option) does not configure, if devel/swig13 is installed. (2) graphics/py-gdal asks for option NUMPY several times, even once more if it wants to install (after build). (3) graphics(p5-Geo-GDAL gives warnings about unrecognized arguments, but it does build and install: Building against GDAL defined in /usr/local/bin/gdal-config Unrecognized argument in LIBS ignored: '-pthread' Writing Makefile_Geo__OGR for Geo::OGR Writing MYMETA.yml Unrecognized argument in LIBS ignored: '-pthread' Writing Makefile_Geo__GDAL__Const for Geo::GDAL::Const Writing MYMETA.yml Unrecognized argument in LIBS ignored: '-pthread' Writing Makefile_Geo__OSR for Geo::OSR Writing MYMETA.yml Unrecognized argument in LIBS ignored: '-pthread' Writing Makefile_Geo__GDAL for Geo::GDAL Writing MYMETA.yml make -f Makefile_Geo__GDAL (4) graphics/ruby-gdal builds and installs fine, distinctive features. (5) graphics/php-gdal does not build with following messages: === Building for php-gdal-1.9.1 /usr/bin/sed -e '/^GDAL_ROOT/d' /usr/local/share/gdal/GDALmake.opt /usr/ports/graphics/php-gdal/work/gdal-1.9.1/swig/php/../../GDALmake.opt /bin/cp /usr/local/include/cpl_config.h /usr/ports/graphics/php-gdal/work/gdal-1.9.1/swig/php/../../port/ c++ -I../../port -I../../gcore -I../../alg -I../../ogr `php-config --includes` -O2 -pipe -O2 -fno-strict-aliasing -pipe -msse3 -I/usr/local/include -fPIC -c gdal_wrap.cpp gdal_wrap.cpp: In function 'void* SWIG_ZTS_ConvertResourcePtr(zval*, swig_type_info*, int)': gdal_wrap.cpp:935: error: invalid conversion from 'const char*' to 'char*' gmake: *** [gdal_wrap.o] Fehler 1 *** [do-build] Error code 1 Hope this helps, Rainer GDAL 1.9.1 was released several days ago. I'd like to make some changes along with this update [1]. The most important one is about the language bindings. I decide to move them to separate ports: - Perl binding: graphics/p5-Geo-GDAL [2] - Python binding: graphics/py-gdal [3] - PHP binding: graphics/php-gdal [4] - Ruby binding: graphics/ruby-gdal [5] The other changes to the Makefile include: - Update to 1.9.1 - Build with thread-safe support by default - Add lzma support - Adjust OPTIONS: - Add ICONV, KML and WEBP - Remove GRASS (cyclic dependency), PERL, PHP, PYTHON, RUBY and THREADS (default) - Add corresponding CONFIGURE_ARGS for disabled features - Cosmetic change Please test if it works for you. If I don't receive critical feedback, I plan to commit them this weekend or next Monday. Thanks! [1] http://people.freebsd.org/~sunpoet/gdal/gdal-1.9.1.patch [2] http://people.freebsd.org/~sunpoet/gdal/p5-Geo-GDAL.shar [3] http://people.freebsd.org/~sunpoet/gdal/php-gdal.shar [4] http://people.freebsd.org/~sunpoet/gdal/py-gdal.shar [5] http://people.freebsd.org/~sunpoet/gdal/ruby-gdal.shar Regards, sunpoet ___ 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: Ruby 1.9 as default
On Tue, 05 Jun 2012 21:14:06 -0400 Steve Wills swi...@freebsd.org mentioned: From what I saw in your other messages, it sounds like this may be specific to the use of mono. Or can you reproduce with another program? Yes, it looks like it can be a mono bug, or unfortunate combination of what mono and ruby do on FreeBSD. I was not able to reproduce this on Linux. I'm still investigating this issue. Hopefully, we'll find out what is it. :) Thanks! -- Stanislav Sedov ST4096-RIPE () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments ___ 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: firefox 13.0,1 needs lang/gcc46 -- to RUN?!
On 06/06/2012 02:18 PM, Heino Tiedemann wrote: Hi, Why this ports needs his compiler to RUN?! firefox 13.0,1 snip Required To Run: archivers/zip, lang/gcc46,... Just a shot in the dark for lang/gcc46, I'd say it's because Firefox dynamically links to a newer version of libgcc that is only available when it is installed. Its runtime dependency on archivers/zip can be explained by the fact that Firefox now packs its hundreds of GUI files (chrome) into a giant zip file (named omni.ja), for which it requires a zip library to read. You're welcome to tweak the Makefile to remove the runtime dependency and test it to see how badly it breaks; I've done the same to keep Perl and Python off my embedded system images when installing glib et alia. Glib only requires the languages for scripts used when compiling software, which is unlikely to occur on an embedded system. -- Fuzzy love, -CyberLeo Technical Administrator CyberLeo.Net Webhosting http://www.CyberLeo.Net cyber...@cyberleo.net Furry Peace! - http://.fur.com/peace/ ___ 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: Zenoss Port Web-UI seems incomplete
[...] If there is no issue after this, please send us a unified diff of the zone.conf files. The reason I ask to do this, is that I changed nothing and it worked out-of-the-box. Thanks, Jason -- Jason Helfman System Administrator experts-exchange.com http://www.experts-exchange.com/M_4830110.html E4AD 7CF1 1396 27F6 79DD 4342 5E92 AD66 8C8C FBA5 Here is the diff of the zope.conf and zope.conf.in file: # diff zope.conf zope.conf.in 0a1,2 # This is the proposed version for SC / Zope 2.12.1 25c27,31 %define INSTANCE /usr/local/zenoss --- %define INSTANCE INSTANCE_HOME # this needs to match the encoding in the sitecustomize.py file # in $ZENHOME/lib/python default-zpublisher-encoding utf-8 148c154 #effective-user chrism --- effective-user zenoss 929a936 conflict-error-log-level debug 1019,1027c1026,1034 zodb_db main # Main FileStorage database filestorage # See .../ZODB/component.xml for directives (sectiontype # filestorage). path $INSTANCE/var/Data.fs /filestorage mount-point / /zodb_db --- #zodb_db main ## Main FileStorage database #filestorage # # See .../ZODB/component.xml for directives (sectiontype # # filestorage). # path $INSTANCE/var/Data.fs #/filestorage #mount-point / #/zodb_db 1042,1065c1049,1063 # zodb_db main # # The full mount-point syntax is: # # # # mount-point localpath[:remotepath] # # # # localpath - the path where the storage is mounted in this instance # # remotepath - is the path to the object in the storage where it is mounted # # from. This defaults to whatever is supplied for localpath. # mount-point / # # ZODB cache, in number of objects # cache-size 5000 # zeoclient # # See .../ZODB/component.xml for directives (sectiontype # # zeoclient). # server localhost:8100 # storage 1 # name zeostorage # var $INSTANCE/var # # ZEO client cache, in bytes # cache-size 20MB # # Uncomment to have a persistent disk cache # #client zeo1 # /zeoclient # /zodb_db --- zodb_db main mount-point / # ZODB cache, in number of objects cache-size 5000 zeoclient server localhost:8100 storage 1 name zeostorage var $INSTANCE/var # ZEO client cache, in bytes cache-size 20MB # Uncomment to have a persistent disk cache #client zeo1 /zeoclient /zodb_db Regards, Kaya ___ 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 unmaintained ports which are currently marked broken
As part of an ongoing effort to reduce the number of problems in the FreeBSD ports system, we periodically notify users of ports that are marked as broken in their Makefiles. In many cases these ports are failing to compile on some subset of the FreeBSD build environments. The most common problem is that recent versions of -CURRENT include gcc4.2, which is much stricter than older versions. The next most common problem is that compiles succeed on the i386 architecture (e.g. the common Intel PC), but fail on one or more of the other architectures due to assumptions about things such as size of various types, byte-alignment issues, and so forth. In occasional cases we see that the same port may have different errors in different build environments. The script that runs on the build cluster uses heuristics to try to 'guess' the error type to help you isolate problems, but it is only a rough guide. One more note: on occasion, there are transient build errors seen on the build farm. Unfortunately, there is not yet any way for this algorithm to tell the difference (humans are much, much better at this kind of thing.) The errors are listed below. In the case where the same problem exists on more than one build environment, the URL points to the latest errorlog for that type. (By 'build environment' here we mean 'combination of 7.x/8.x/9.x/-current with target architecture'.) (Note: the dates are included to help you to gauge whether or not the error still applies to the latest version. The program that generates this report is not yet able to determine this automatically.) portname: audio/teamspeak_client broken because: does not build build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=audioportname=teamspeak_client portname: audio/wsoundprefs broken because: does not compile build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=audioportname=wsoundprefs portname: chinese/big5con broken because: fails to build with new utmpx build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=chineseportname=big5con portname: chinese/hztty broken because: fails to build with new utmpx build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=chineseportname=hztty portname: databases/adstudio broken because: does not fetch build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=databasesportname=adstudio portname: databases/libudbc broken because: does not fetch build errors: http://pointyhat.freebsd.org/errorlogs/i386-errorlogs/e.8.20120525110836/libudbc-4.1.log (_Mar__1_11:02:33_UTC_2012) overview: http://portsmon.FreeBSD.org/portoverview.py?category=databasesportname=libudbc portname: databases/msql broken because: Broken on FreeBSD 9+ build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=databasesportname=msql portname: databases/xapian-bindings10 broken because: does not compile build errors: http://pointyhat.FreeBSD.org/errorlogs/amd64-errorlogs/e.8.20120530122048/xapian-bindings10-1.0.23.log (_May_21_05:21:17_UTC_2012) overview: http://portsmon.FreeBSD.org/portoverview.py?category=databasesportname=xapian-bindings10 portname: deskutils/sciplore-mindmapping broken because: Upstream re-rolled tarballs without documenting changes or bumping version build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=deskutilsportname=sciplore-mindmapping portname: devel/dsss broken because: does not build build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=develportname=dsss portname: devel/gauche-gaunit broken because: does not package build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=develportname=gauche-gaunit portname: devel/gcvs broken because: does not compile build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=develportname=gcvs portname: devel/linux-js broken because: does not build build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=develportname=linux-js portname: devel/linuxthreads broken because: does not build build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=develportname=linuxthreads portname: devel/lua-posix broken because: does not build build errors: http://pointyhat.freebsd.org/errorlogs/i386-errorlogs/e.10.20120324064215/lua51-posix-5.0.log (_Mar_26_08:19:50_UTC_2012) overview:
FreeBSD unmaintained ports which are currently scheduled for deletion
As part of an ongoing effort to reduce the number of problems in the FreeBSD ports system, we periodically schedule removal of ports that have been judged to have outlived their usefulness. Often, this is due to a better alternative having become available and/or the cessation of development on the existing port. In some cases, ports are marked for removal because they fail to build and install correctly from their sources, or otherwise fail in operation. The ports, and the reason and date that they have been scheduled for removal, are listed below. If no one has stepped forward before that time to propose a way to fix the problems (such as via a PR), the ports will be deleted. portname: archivers/bsdar description:BSD-licensed replacement of the ar utility maintainer: po...@freebsd.org status: IGNORE deprecated because: part of the base system expiration date:2013-02-28 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=archiversportname=bsdar portname: audio/linux-alsa-lib description:The Advanced Linux Sound Architecture libraries maintainer: po...@freebsd.org deprecated because: expiration date:2013-02-28 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=audioportname=linux-alsa-lib portname: audio/linux-arts description:Audio system for the KDE integrated X11 desktop (Linux version) maintainer: po...@freebsd.org deprecated because: expiration date:2013-02-28 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=audioportname=linux-arts portname: audio/linux-freealut description:A free implementation of OpenAL's ALUT standard (Linux version) maintainer: po...@freebsd.org deprecated because: expiration date:2013-02-28 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=audioportname=linux-freealut portname: audio/linux-libmad description:Libmad library (part of MAD project) maintainer: po...@freebsd.org deprecated because: expiration date:2013-02-28 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=audioportname=linux-libmad portname: audio/linux-libogg description:Ogg bitstream library (Linux version) maintainer: po...@freebsd.org deprecated because: expiration date:2013-02-28 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=audioportname=linux-libogg portname: audio/linux-libvorbis description:Audio compression codec library (Linux version) maintainer: po...@freebsd.org deprecated because: expiration date:2013-02-28 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=audioportname=linux-libvorbis portname: audio/linux-openal description:A 3D positional spatialized sound library (Linux version) maintainer: po...@freebsd.org deprecated because: expiration date:2013-02-28 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=audioportname=linux-openal portname: deskutils/sciplore-mindmapping description:Mind Mapping tool with Reference and PDF Management maintainer: po...@freebsd.org status: BROKEN deprecated because: Discontinued, use deskutils/docear instead expiration date:2012-05-31 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=deskutilsportname=sciplore-mindmapping portname: devel/libgetline description:A small, portable, and easy to use command line library maintainer: po...@freebsd.org deprecated because: Upstream disapear and distfile is no more available expiration date:2013-02-28 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=develportname=libgetline portname: devel/libtool-fixed description:Generic shared library support script -- the fixed version maintainer: po...@freebsd.org deprecated because: libtool has been fixed, no more need of this version expiration date:2012-06-07 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=develportname=libtool-fixed portname: games/antrix description:Free stable dedicated-server for World of Warcraft maintainer: po...@freebsd.org deprecated because: no more public distfiles, abandoned upstream expiration date:2012-06-01 build errors:
www/firefox (13.0,1): SIGNAL 10 or SIGNAL 11 (gettimeofday())
Hello.
On one of my boxes I have a persistent problem with Firefox since the
last major update/recompilation a week ago due to the massive PNG
update. OS is FreeBSD 10.0-CURRENT/amd64, CLANG compiled.
First of all, neither firefox 12 nor 13 compile with CLANG. Firefox 12
also rejects compiling with legacy gcc 4.2.1.
Compiling with USE_GCC= 4.6+ worked for Firefox 12 and it seems to be
now an option for 13, too.
Well, so far, I recompiled everything prerequisite for www/firefox with
portmaster -f www/firefox, I did this twice.
On the box in question (it is the most modern hardware (Core-i7 3930K
with 32 GB RAM) I have around here, this is the delicate aspect, since
my private outdated very similar setup (Core2Duo with 8GB RAM) doesn't
suffer this crashes.
So far, I also removed the folder ~/.mozilla to asure having a clean
setup or tried to start firefox with --safe-mode to avoid faulty/foul
plugins or addons. it is always the same - I receive a SIGBUS or
SEGMENTATION FAULT (SIGNAL 10 or SIGNAL 11. SIGNAL 10 with option
--safe-mode).
truss firefox shows up this:
[...]
mmap(0x0,4194304,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) =
35035021312 (0x82840)
_umtx_op(0x8006a40b0,0x10,0x7fff,0x0,0x0,0x8) = 0 (0x0)
clock_gettime(4,{11881.018755810 }) = 0 (0x0)
clock_gettime(4,{11881.018816083 }) = 0 (0x0)
_umtx_op(0x8109ac6f0,0x11,0x0,0x0,0x0,0x8) = 0 (0x0)
_umtx_op(0x8109ac6f0,0x16,0x0,0x0,0x0,0x7edf6d88) = 0 (0x0)
clock_gettime(4,{11881.018981257 }) = 0 (0x0)
gettimeofday({1339067570.994765 },0x0) = 0 (0x0)
gettimeofday({1339067570.994882 },0x0) = 0 (0x0)
_umtx_op(0x8006a40b0,0x10,0x7fff,0x0,0x0,0x8) = 0 (0x0)
clock_gettime(4,{11881.020991081 }) = 0 (0x0)
gettimeofday({1339067570.996727 },0x0) = 0 (0x0)
clock_gettime(4,{11881.021099055 }) = 0 (0x0)
clock_gettime(4,{11881.021136490 }) = 0 (0x0)
gettimeofday({1339067570.996871 },0x0) = 0 (0x0)
gettimeofday({1339067570.996969 },0x0) = 0 (0x0)
_umtx_op(0x8006a40b0,0x10,0x7fff,0x0,0x0,0x8) = 0 (0x0)
clock_gettime(4,{11881.023170688 }) = 0 (0x0)
gettimeofday({1339067570.998883 },0x0) = 0 (0x0)
_umtx_op(0x8006a40b0,0xf,0x0,0x18,0x7edf6d88,0x7edf6d88) = 0 (0x0)
clock_gettime(4,{11881.023273494 }) = 0 (0x0)
clock_gettime(4,{11881.023303945 }) = 0 (0x0)
gettimeofday({1339067570.999034 },0x0) = 0 (0x0)
gettimeofday({1339067570.999129 },0x0) = 0 (0x0)
_umtx_op(0x8006a40b0,0x10,0x7fff,0x0,0x0,0x8) = 0 (0x0)
clock_gettime(4,{11881.023606148 }) = 0 (0x0)
gettimeofday({1339067570.999317 },0x0) = 0 (0x0)
_umtx_op(0x8006a40b0,0xf,0x0,0x18,0x7edf6d88,0x7edf6d88) = 0 (0x0)
clock_gettime(4,{11881.023704974 }) = 0 (0x0)
clock_gettime(4,{11881.023734307 }) = 0 (0x0)
_umtx_op(0x8006a40b0,0x10,0x7fff,0x0,0x0,0x8) = 0 (0x0)
clock_gettime(4,{11881.024399965 }) = 0 (0x0)
gettimeofday({1339067571.000116 },0x0) = 0 (0x0)
_umtx_op(0x8006a40b0,0xf,0x0,0x18,0x7edf6d88,0x7edf6d88) = 0 (0x0)
clock_gettime(4,{11881.024519184 }) = 0 (0x0)
clock_gettime(4,{11881.024554593 }) = 0 (0x0)
gettimeofday({1339067571.000581 },0x0) = 0 (0x0)
gettimeofday({1339067571.002458 },0x0) = 0 (0x0)
clock_gettime(4,{11881.027489534 }) = 0 (0x0)
clock_gettime(4,{11881.027529833 }) = 0 (0x0)
clock_gettime(4,{11881.027608684 }) = 0 (0x0)
clock_gettime(4,{11881.027646328 }) = 0 (0x0)
gettimeofday({1339067571.003559 },0x0) = 0 (0x0)
gettimeofday({1339067571.003667 },0x0) = 0 (0x0)
_umtx_op(0x8006a40b0,0x10,0x7fff,0x0,0x0,0x8) = 0 (0x0)
clock_gettime(4,{11881.028796824 }) = 0 (0x0)
gettimeofday({1339067571.004513 },0x0) = 0 (0x0)
_umtx_op(0x8006a40b0,0xf,0x0,0x18,0x7edf6d88,0x7edf6d88) = 0 (0x0)
clock_gettime(4,{11881.028916113 }) = 0 (0x0)
clock_gettime(4,{11881.028948379 }) = 0 (0x0)
clock_gettime(4,{11881.030049637 }) = 0 (0x0)
clock_gettime(4,{11881.030084697 }) = 0 (0x0)
gettimeofday({1339067571.005795 },0x0) = 0 (0x0)
_umtx_op(0x8006a40b0,0x10,0x7fff,0x0,0x0,0x8) = 0 (0x0)
clock_gettime(4,{11881.030320202 }) = 0 (0x0)
gettimeofday({1339067571.006030 },0x0) = 0 (0x0)
_umtx_op(0x8006a40b0,0xf,0x0,0x18,0x7edf6d88,0x7edf6d88) = 0 (0x0)
clock_gettime(4,{11881.030418050 }) = 0 (0x0)
clock_gettime(4,{11881.030447802 }) = 0 (0x0)
gettimeofday({1339067571.006204 },0x0) = 0 (0x0)
gettimeofday({1339067571.006298 },0x0) = 0 (0x0)
_umtx_op(0x8006a40b0,0x10,0x7fff,0x0,0x0,0x8) = 0 (0x0)
clock_gettime(4,{11881.031855384 }) = 0 (0x0)
gettimeofday({1339067571.007571 },0x0) = 0 (0x0)
Re: libreoffice, Makefile fix proposal...
Hi, 2012/6/7 Kevin Oberman kob6...@gmail.com: # portmaster -g boost-libs boost-jam # pkg_delete -f boost-libs-\* boost-jam-\* # cd /usr/ports/editor/libreoffice # make patch # cd work/libreoffice-core --- lotuswordpro/Module_lotuswordpro.mk.orig 2012-05-31 19:34:52.014043605 -0300 +++ lotuswordpro/Module_lotuswordpro.mk 2012-05-31 19:29:29.276164732 -0300 @@ -31,8 +31,8 @@ Library_lwpft \ )) -$(eval $(call gb_Module_add_check_targets,lotuswordpro,\ - CppunitTest_lotuswordpro_test_lotuswordpro \ -)) +#$(eval $(call gb_Module_add_check_targets,lotuswordpro,\ +# CppunitTest_lotuswordpro_test_lotuswordpro \ +#)) # vim: set noet sw=4 ts=4: ^D # portmaster -C libreoffice # pkg_add /usr/ports/packages/All/boost-libs-* /usr/ports/packages/All/boost-jam-\* I know this is a rather long UPDATING message, but it does tell them how to get libreoffice up and running. This way it loses dependency tracking (ie. /var/db/pkg/boost-libs-*/+REQUIRED_BY). Don't forget to portmaster --check-depends after the pkg_add. -- Olivier Smedts _ ASCII ribbon campaign ( ) e-mail: oliv...@gid0.org - against HTML email vCards X www: http://www.gid0.org - against proprietary attachments / \ Il y a seulement 10 sortes de gens dans le monde : ceux qui comprennent le binaire, et ceux qui ne le comprennent pas. ___ 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: libreoffice, Makefile fix proposal...
Olivier Smedts writes: This way it loses dependency tracking (ie. /var/db/pkg/boost-libs-*/+REQUIRED_BY). Don't forget to portmaster --check-depends after the pkg_add. Am I the only one who thinks the make process should not depend on tools like portmaster? Robert Huff ___ 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: www/firefox (13.0,1): SIGNAL 10 or SIGNAL 11 (gettimeofday())
On 2012-06-07 13:16, Hartmann, O. wrote: Hello. On one of my boxes I have a persistent problem with Firefox since the last major update/recompilation a week ago due to the massive PNG update. OS is FreeBSD 10.0-CURRENT/amd64, CLANG compiled. First of all, neither firefox 12 nor 13 compile with CLANG. Firefox 12 also rejects compiling with legacy gcc 4.2.1. Compiling with clang works fine, at least with firefox 13. It has been tested and confirmed by at least three different persons. Regards! -- Niclas ___ 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
[CFT] Xorg 7.7 ready for testing!
Hi Fans, The FreeBSD Xorg Team is pleased to announce Xorg 7.7 Release. We are very happy to be able to Call for testing shortly after the Xorg team annouced 7.7 release. This CFT is also open for discussion on how we should move forward with xorg release as we are facing some issues and we would like to ask for your opinion. Right now we have 2 existing xorg versions in our Ports Tree. The situation is quite bad due to our poor graphic card support. That means we do not have much choice but to take it as how it is now. But with regards to mesa support, we have to face some new challanges. With the new mesa 8.0 release, accelerated support for a number of older graphic cards was dropped. At the moment we are not sure how to deal with that.We are thinking of just replacing mesa 7.11 with 8.0 or making a new flag like WITH_MESA= 7.11.2 / 8.0 in combination with WITH_NEW_XORG, and let the mesa 7.6.1 set as default together with the old xorg version. Obviosly the latter option make the already complex situation more complex. The problem is, users, especially the new ones can easily get confused with it. Another issue is, the packages.We can't deliver a package set with the new Xorg releases. This means users with new hardware will have to compile everything by themselves. Though I'm totally fine with compiling, not everyone has the CPU power to compile everything. What I'm trying to say is, I would love to see the newer xorg released as the default version, but i know this will break a lot of old hardware. The thing is, when we want to try to become a Modern Operating System, I dont see any other way to make the new xorg as default but to give Users the chance to compile the old xorg with a flag like WITH_OLD_XORG. Some notes regarding KMS support: KMS Support has been completely migrated to FreeBSD 10. The MFC to 9 will come soon, that means so long its not MFC'd to 9-Stable, users need to get the latest patch from our x11 mailing list. This testing includes * libdrm 2.4.34 (including KMS support) * mesa 8.0.3 * full Xorg 7.7 release Change log http://www.x.org/releases/X11R7.7/changelog.html 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. 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. Nvidia and ATI users should set WITH_NEW_XORG=yes. svn co https://trillian.chruetertee.ch/svn/ports/trunk 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 releated ports during the commit to the ports tree. Roadmap: Our current plan is to let the CFT running for a while, and see what the outcome of the discussion above is. We hope to get a lot of feedback to solve as many problems as possible. Also we are working on the libglut to freeglut migration, this will definitely complete before we import Xorg 7.7. So we still have enough time. We are looking forward for your feedback. - miwi on behalf of the FreeBSD X11 Team PS: Please reply only to x11@ thanks. -- +--oOO--(_)--OOo+ Facebook: miwi1 Twitter:miwi_ With best Regards, Martin Wilke (miwi_(at)_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: [CFT] gdal 1.9.1 update and other changes
Hi, I can confirm Rainers observation with swig13 and libkml, otherwise gdal builds and installs fine. Since I'm new to FreeBSD I still need to figure out what I need to do with those .shar files, so I can't give an update yet on the language packages Frank Am 07.06.2012 08:25, schrieb Rainer Hurling: Am 07.06.2012 05:30 (UTC+1) schrieb Sunpoet Po-Chuan Hsieh: Hi, Many thanks for this update. What I observed so far: (1) graphics/gdal builds and installs fine. There is a minor problem: dependend port science/libkml (as option) does not configure, if devel/swig13 is installed. (2) graphics/py-gdal asks for option NUMPY several times, even once more if it wants to install (after build). (3) graphics(p5-Geo-GDAL gives warnings about unrecognized arguments, but it does build and install: Building against GDAL defined in /usr/local/bin/gdal-config Unrecognized argument in LIBS ignored: '-pthread' Writing Makefile_Geo__OGR for Geo::OGR Writing MYMETA.yml Unrecognized argument in LIBS ignored: '-pthread' Writing Makefile_Geo__GDAL__Const for Geo::GDAL::Const Writing MYMETA.yml Unrecognized argument in LIBS ignored: '-pthread' Writing Makefile_Geo__OSR for Geo::OSR Writing MYMETA.yml Unrecognized argument in LIBS ignored: '-pthread' Writing Makefile_Geo__GDAL for Geo::GDAL Writing MYMETA.yml make -f Makefile_Geo__GDAL (4) graphics/ruby-gdal builds and installs fine, distinctive features. (5) graphics/php-gdal does not build with following messages: === Building for php-gdal-1.9.1 /usr/bin/sed -e '/^GDAL_ROOT/d' /usr/local/share/gdal/GDALmake.opt /usr/ports/graphics/php-gdal/work/gdal-1.9.1/swig/php/../../GDALmake.opt /bin/cp /usr/local/include/cpl_config.h /usr/ports/graphics/php-gdal/work/gdal-1.9.1/swig/php/../../port/ c++ -I../../port -I../../gcore -I../../alg -I../../ogr `php-config --includes` -O2 -pipe -O2 -fno-strict-aliasing -pipe -msse3 -I/usr/local/include -fPIC -c gdal_wrap.cpp gdal_wrap.cpp: In function 'void* SWIG_ZTS_ConvertResourcePtr(zval*, swig_type_info*, int)': gdal_wrap.cpp:935: error: invalid conversion from 'const char*' to 'char*' gmake: *** [gdal_wrap.o] Fehler 1 *** [do-build] Error code 1 Hope this helps, Rainer GDAL 1.9.1 was released several days ago. I'd like to make some changes along with this update [1]. The most important one is about the language bindings. I decide to move them to separate ports: - Perl binding: graphics/p5-Geo-GDAL [2] - Python binding: graphics/py-gdal [3] - PHP binding: graphics/php-gdal [4] - Ruby binding: graphics/ruby-gdal [5] The other changes to the Makefile include: - Update to 1.9.1 - Build with thread-safe support by default - Add lzma support - Adjust OPTIONS: - Add ICONV, KML and WEBP - Remove GRASS (cyclic dependency), PERL, PHP, PYTHON, RUBY and THREADS (default) - Add corresponding CONFIGURE_ARGS for disabled features - Cosmetic change Please test if it works for you. If I don't receive critical feedback, I plan to commit them this weekend or next Monday. Thanks! [1] http://people.freebsd.org/~sunpoet/gdal/gdal-1.9.1.patch [2] http://people.freebsd.org/~sunpoet/gdal/p5-Geo-GDAL.shar [3] http://people.freebsd.org/~sunpoet/gdal/php-gdal.shar [4] http://people.freebsd.org/~sunpoet/gdal/py-gdal.shar [5] http://people.freebsd.org/~sunpoet/gdal/ruby-gdal.shar Regards, sunpoet ___ 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: libreoffice, Makefile fix proposal...
On Thu, 7 Jun 2012 07:38:36 -0400 Robert Huff articulated: Olivier Smedts writes: This way it loses dependency tracking (ie. /var/db/pkg/boost-libs-*/+REQUIRED_BY). Don't forget to portmaster --check-depends after the pkg_add. Am I the only one who thinks the make process should not depend on tools like portmaster? I for one would certainly hope that it didn't. -- Jerry ♔ Disclaimer: off-list followups get on-list replies or get ignored. Please do not ignore the Reply-To header. __ I haven't lost my mind; I know exactly where I left it. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: [CFT] gdal 1.9.1 update and other changes
Am 07.06.2012 14:38 (UTC+1) schrieb Frank Broniewski: Hi, I can confirm Rainers observation with swig13 and libkml, otherwise gdal builds and installs fine. Since I'm new to FreeBSD I still need to figure out what I need to do with those .shar files, so I can't give an update yet on the language packages It seems with these .shar files you have to create their top directories manually. What I did (as root) is: cd /usr/ports mkdir graphics/p5-Geo-GDAL sh p5-Geo-GDAL.shar mkdir graphics/py-gdal sh py-gdal.shar mkdir graphics/php-gdal sh php-gdal.shar mkdir graphics/ruby-gdal sh ruby-gdal.shar After that the new ports are available. Frank Am 07.06.2012 08:25, schrieb Rainer Hurling: Am 07.06.2012 05:30 (UTC+1) schrieb Sunpoet Po-Chuan Hsieh: Hi, Many thanks for this update. What I observed so far: (1) graphics/gdal builds and installs fine. There is a minor problem: dependend port science/libkml (as option) does not configure, if devel/swig13 is installed. (2) graphics/py-gdal asks for option NUMPY several times, even once more if it wants to install (after build). (3) graphics(p5-Geo-GDAL gives warnings about unrecognized arguments, but it does build and install: Building against GDAL defined in /usr/local/bin/gdal-config Unrecognized argument in LIBS ignored: '-pthread' Writing Makefile_Geo__OGR for Geo::OGR Writing MYMETA.yml Unrecognized argument in LIBS ignored: '-pthread' Writing Makefile_Geo__GDAL__Const for Geo::GDAL::Const Writing MYMETA.yml Unrecognized argument in LIBS ignored: '-pthread' Writing Makefile_Geo__OSR for Geo::OSR Writing MYMETA.yml Unrecognized argument in LIBS ignored: '-pthread' Writing Makefile_Geo__GDAL for Geo::GDAL Writing MYMETA.yml make -f Makefile_Geo__GDAL (4) graphics/ruby-gdal builds and installs fine, distinctive features. (5) graphics/php-gdal does not build with following messages: === Building for php-gdal-1.9.1 /usr/bin/sed -e '/^GDAL_ROOT/d' /usr/local/share/gdal/GDALmake.opt /usr/ports/graphics/php-gdal/work/gdal-1.9.1/swig/php/../../GDALmake.opt /bin/cp /usr/local/include/cpl_config.h /usr/ports/graphics/php-gdal/work/gdal-1.9.1/swig/php/../../port/ c++ -I../../port -I../../gcore -I../../alg -I../../ogr `php-config --includes` -O2 -pipe -O2 -fno-strict-aliasing -pipe -msse3 -I/usr/local/include -fPIC -c gdal_wrap.cpp gdal_wrap.cpp: In function 'void* SWIG_ZTS_ConvertResourcePtr(zval*, swig_type_info*, int)': gdal_wrap.cpp:935: error: invalid conversion from 'const char*' to 'char*' gmake: *** [gdal_wrap.o] Fehler 1 *** [do-build] Error code 1 Hope this helps, Rainer GDAL 1.9.1 was released several days ago. I'd like to make some changes along with this update [1]. The most important one is about the language bindings. I decide to move them to separate ports: - Perl binding: graphics/p5-Geo-GDAL [2] - Python binding: graphics/py-gdal [3] - PHP binding: graphics/php-gdal [4] - Ruby binding: graphics/ruby-gdal [5] The other changes to the Makefile include: - Update to 1.9.1 - Build with thread-safe support by default - Add lzma support - Adjust OPTIONS: - Add ICONV, KML and WEBP - Remove GRASS (cyclic dependency), PERL, PHP, PYTHON, RUBY and THREADS (default) - Add corresponding CONFIGURE_ARGS for disabled features - Cosmetic change Please test if it works for you. If I don't receive critical feedback, I plan to commit them this weekend or next Monday. Thanks! [1] http://people.freebsd.org/~sunpoet/gdal/gdal-1.9.1.patch [2] http://people.freebsd.org/~sunpoet/gdal/p5-Geo-GDAL.shar [3] http://people.freebsd.org/~sunpoet/gdal/php-gdal.shar [4] http://people.freebsd.org/~sunpoet/gdal/py-gdal.shar [5] http://people.freebsd.org/~sunpoet/gdal/ruby-gdal.shar Regards, sunpoet ___ 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-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 7.7 ready for testing!
Martin Wilke wrote: With the new mesa 8.0 release, accelerated support for a number of older graphic cards was dropped. At the moment we are not sure how to deal with that.We are thinking of just replacing mesa 7.11 with 8.0 or making a new flag like WITH_MESA= 7.11.2 / 8.0 in combination with WITH_NEW_XORG, and let the mesa 7.6.1 set as default together with the old xorg version. Obviosly the latter option make the already complex situation more complex. The problem is, users, especially the new ones can easily get confused with it. Another issue is, the packages.We can't deliver a package set with the new Xorg releases. Will it be possible to provide, say pkgng repo with packages compiled with new xorg and new mesa? That would simplify testing (and using) by a very large factor. We'd just change PACKAGESITE and run pkg upgrade. ___ 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] gdal 1.9.1 update and other changes
Yes, that worked. I tested it with py-gdal. First I had some problems because there were some other programs depending gdal-grass (QGIS, Grass GIS) which linked to the older gdal libs, but after deleting gdal-grass, I could import the module into python and run successfully some tests against some scripts I had written. (2) graphics/py-gdal asks for option NUMPY several times, even once more if it wants to install (after build). I can confirm this too ... I will test if the other languages compile asap. Btw, is it possible to compile more than one port at the same time? Or is this not advisable? Frank Am 07.06.2012 14:53, schrieb Rainer Hurling: Am 07.06.2012 14:38 (UTC+1) schrieb Frank Broniewski: Hi, I can confirm Rainers observation with swig13 and libkml, otherwise gdal builds and installs fine. Since I'm new to FreeBSD I still need to figure out what I need to do with those .shar files, so I can't give an update yet on the language packages It seems with these .shar files you have to create their top directories manually. What I did (as root) is: cd /usr/ports mkdir graphics/p5-Geo-GDAL sh p5-Geo-GDAL.shar mkdir graphics/py-gdal sh py-gdal.shar mkdir graphics/php-gdal sh php-gdal.shar mkdir graphics/ruby-gdal sh ruby-gdal.shar After that the new ports are available. Frank Am 07.06.2012 08:25, schrieb Rainer Hurling: Am 07.06.2012 05:30 (UTC+1) schrieb Sunpoet Po-Chuan Hsieh: Hi, Many thanks for this update. What I observed so far: (1) graphics/gdal builds and installs fine. There is a minor problem: dependend port science/libkml (as option) does not configure, if devel/swig13 is installed. (2) graphics/py-gdal asks for option NUMPY several times, even once more if it wants to install (after build). (3) graphics(p5-Geo-GDAL gives warnings about unrecognized arguments, but it does build and install: Building against GDAL defined in /usr/local/bin/gdal-config Unrecognized argument in LIBS ignored: '-pthread' Writing Makefile_Geo__OGR for Geo::OGR Writing MYMETA.yml Unrecognized argument in LIBS ignored: '-pthread' Writing Makefile_Geo__GDAL__Const for Geo::GDAL::Const Writing MYMETA.yml Unrecognized argument in LIBS ignored: '-pthread' Writing Makefile_Geo__OSR for Geo::OSR Writing MYMETA.yml Unrecognized argument in LIBS ignored: '-pthread' Writing Makefile_Geo__GDAL for Geo::GDAL Writing MYMETA.yml make -f Makefile_Geo__GDAL (4) graphics/ruby-gdal builds and installs fine, distinctive features. (5) graphics/php-gdal does not build with following messages: === Building for php-gdal-1.9.1 /usr/bin/sed -e '/^GDAL_ROOT/d' /usr/local/share/gdal/GDALmake.opt /usr/ports/graphics/php-gdal/work/gdal-1.9.1/swig/php/../../GDALmake.opt /bin/cp /usr/local/include/cpl_config.h /usr/ports/graphics/php-gdal/work/gdal-1.9.1/swig/php/../../port/ c++ -I../../port -I../../gcore -I../../alg -I../../ogr `php-config --includes` -O2 -pipe -O2 -fno-strict-aliasing -pipe -msse3 -I/usr/local/include -fPIC -c gdal_wrap.cpp gdal_wrap.cpp: In function 'void* SWIG_ZTS_ConvertResourcePtr(zval*, swig_type_info*, int)': gdal_wrap.cpp:935: error: invalid conversion from 'const char*' to 'char*' gmake: *** [gdal_wrap.o] Fehler 1 *** [do-build] Error code 1 Hope this helps, Rainer GDAL 1.9.1 was released several days ago. I'd like to make some changes along with this update [1]. The most important one is about the language bindings. I decide to move them to separate ports: - Perl binding: graphics/p5-Geo-GDAL [2] - Python binding: graphics/py-gdal [3] - PHP binding: graphics/php-gdal [4] - Ruby binding: graphics/ruby-gdal [5] The other changes to the Makefile include: - Update to 1.9.1 - Build with thread-safe support by default - Add lzma support - Adjust OPTIONS: - Add ICONV, KML and WEBP - Remove GRASS (cyclic dependency), PERL, PHP, PYTHON, RUBY and THREADS (default) - Add corresponding CONFIGURE_ARGS for disabled features - Cosmetic change Please test if it works for you. If I don't receive critical feedback, I plan to commit them this weekend or next Monday. Thanks! [1] http://people.freebsd.org/~sunpoet/gdal/gdal-1.9.1.patch [2] http://people.freebsd.org/~sunpoet/gdal/p5-Geo-GDAL.shar [3] http://people.freebsd.org/~sunpoet/gdal/php-gdal.shar [4] http://people.freebsd.org/~sunpoet/gdal/py-gdal.shar [5] http://people.freebsd.org/~sunpoet/gdal/ruby-gdal.shar Regards, sunpoet ___ 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
Re: libreoffice, Makefile fix proposal...
2012/6/7 Sergio de Almeida Lenzi lenzi.ser...@gmail.com: Well, now that libreoffice build is solved, than what about insert a line: CONFLICTS_BUILD= boost* near line 63 of Makefile??? libreoffice does not conflict with boost; just Makefile has a problem. Attached is the patch. -- Hiroto Kagotani hiroto.kagot...@gmail.com Makefile.diff Description: Binary data ___ 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 7.7 ready for testing!
On Thu, 07 Jun 2012 08:09:06 -0500, Vitaly Magerya vmage...@gmail.com wrote: Will it be possible to provide, say pkgng repo with packages compiled with new xorg and new mesa? That would simplify testing (and using) by a very large factor. We'd just change PACKAGESITE and run pkg upgrade. The ability to add multiple PACKAGESITEs somehow and the latter ones override the former if they provide conflicting packages would be an interesting way to handle testing things like this... ___ 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 registering services in /etc/services and services_mkdb
On 06/07/2012 07:37 AM, Olli Hauer wrote: Hi, during an update to 8.3 I notice mergemaster from 8.3 is building a database from /etc/services with services_mkdb. However the ports framework does not provide an automation to rebuild this database, even I haven't seen any port which triggers a rebuild. Ports should not be adding entries to /etc/services. Doug ___ 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 registering services in /etc/services and services_mkdb
On 2012-06-07 16:46, Doug Barton wrote: On 06/07/2012 07:37 AM, Olli Hauer wrote: Hi, during an update to 8.3 I notice mergemaster from 8.3 is building a database from /etc/services with services_mkdb. However the ports framework does not provide an automation to rebuild this database, even I haven't seen any port which triggers a rebuild. Ports should not be adding entries to /etc/services. Doug I don't think it is practical to patch all the ports like like bacula , spamd and others to not use getservbyname and hardcode the required ports? ___ 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 to update Evolution to 2.32.3
Hello,
In May 2011 I fixed some bugs in Evolution based on the original
2.32.3 sources, among other problems this one:
https://bugzilla.gnome.org/show_bug.cgi?id=649433
Now (in May 2012) I see in 10-CURRENT that in our ports tree Evolution is
still on version 2.32.1; attached is a set of patches to update both ports to
2.32.3:
ports/databases/evolution-data-server
evolution-data-server.patch
patch-eds (new file for evolution-data-server/files)
ports/mail/evolution
evolution.patch
patch-calendar_gui_e-cal-model.c (new file for evolution/files)
could some kind soul please commit them to the ports tree;
thanks
HIH
matthias
--
Matthias Apitz
t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211
e g...@unixarea.de - w http://www.unixarea.de/
UNIX since V7 on PDP-11 | UNIX on mainframe since ESER 1055 (IBM /370)
UNIX on x86 since SVR4.2 UnixWare 2.1.2 | FreeBSD since 2.2.5
*** evolution-data-server/Makefile.orig Sat Sep 24 00:21:32 2011
--- evolution-data-server/Makefile Thu Jun 7 07:37:35 2012
***
*** 7,13
#
PORTNAME= evolution-data-server
! PORTVERSION= 2.32.1
PORTREVISION= 1
CATEGORIES= databases gnome
MASTER_SITES= GNOME
--- 7,13
#
PORTNAME= evolution-data-server
! PORTVERSION= 2.32.3
PORTREVISION= 1
CATEGORIES= databases gnome
MASTER_SITES= GNOME
*** evolution-data-server/distinfo.orig Sat Nov 20 16:36:26 2010
--- evolution-data-server/distinfo Thu Jun 7 07:40:49 2012
***
*** 1,2
! SHA256 (gnome2/evolution-data-server-2.32.1.tar.bz2) = de6a724504a9d72ca550a5a157df1e27dbb951a673f281106171c2345912fc79
! SIZE (gnome2/evolution-data-server-2.32.1.tar.bz2) = 4290087
--- 1,2
! SHA256 (gnome2/evolution-data-server-2.32.3.tar.bz2) = 744026a745b711b3e393b61fed21c4926d1b10a3aa7da64f4b33a3e3bf5b085c
! SIZE (gnome2/evolution-data-server-2.32.3.tar.bz2) = 4322281
*** addressbook/tests/ebook/test-stress-bookviews.c.origThu Apr 21
21:35:36 2011
--- addressbook/tests/ebook/test-stress-bookviews.c Thu Jun 7 08:21:27 2012
***
*** 100,105
--- 100,106
g_object_unref (view);
e_book_query_unref (query);
+ g_object_unref (book);
return 0;
}
*** calendar/libedata-cal/e-cal-backend.c.orig Thu Apr 21 21:35:36 2011
--- calendar/libedata-cal/e-cal-backend.c Thu Jun 7 08:21:27 2012
***
*** 44,51
struct _ECalBackendPrivate {
/* The source for this backend */
ESource *source;
- /* signal handler ID for source's 'changed' signal */
- gulong source_changed_id;
/* URI, from source. This is cached, since we return const. */
gchar *uri;
--- 44,49
***
*** 161,177
ESource *source)
{
if (backend-priv-source != NULL) {
! if (backend-priv-source_changed_id 0) {
! g_signal_handler_disconnect (
! backend-priv-source,
! backend-priv-source_changed_id);
! backend-priv-source_changed_id = 0;
! }
g_object_unref (backend-priv-source);
}
if (source != NULL)
! backend-priv-source_changed_id = g_signal_connect (
g_object_ref (source), changed,
G_CALLBACK (source_changed_cb), backend);
--- 159,170
ESource *source)
{
if (backend-priv-source != NULL) {
! g_signal_handlers_disconnect_matched (backend-priv-source,
G_SIGNAL_MATCH_FUNC | G_SIGNAL_MATCH_DATA, 0, 0, NULL, source_changed_cb,
backend);
g_object_unref (backend-priv-source);
}
if (source != NULL)
! g_signal_connect (
g_object_ref (source), changed,
G_CALLBACK (source_changed_cb), backend);
***
*** 283,293
g_free (priv-uri);
g_free (priv-cache_dir);
! if (priv-source_changed_id priv-source) {
! g_signal_handler_disconnect (priv-source,
priv-source_changed_id);
! priv-source_changed_id = 0;
}
- g_object_unref (priv-source);
/* Chain up to parent's finalize() method. */
G_OBJECT_CLASS (e_cal_backend_parent_class)-finalize (object);
--- 276,285
g_free (priv-uri);
g_free (priv-cache_dir);
! if (priv-source) {
! g_signal_handlers_disconnect_matched (priv-source,
G_SIGNAL_MATCH_DATA, 0, 0, NULL, NULL, object);
! g_object_unref (priv-source);
}
/* Chain up to parent's finalize() method. */
G_OBJECT_CLASS (e_cal_backend_parent_class)-finalize (object);
***
*** 376,383
backend-priv-clients_mutex = g_mutex_new ();
backend-priv-queries = e_list_new (
! (EListCopyFunc) g_object_ref,
!
Firefox 13
Yesterday, Firefox 13 built and installed quickly. It was just the running part that did not go so well. Coredumps on start, it would start with add-ons disabled, but then coredump while typing a URL, or sometimes a few seconds later. Rebuilding everything Firefox depends on did not make any difference. Firefox 12 builds and runs fine, as do Chromium and xxxterm. This is on 9-stable from yesterday, amd64. The next step is to build with debug symbols; I was hoping the problem would have been experienced by someone else by now. Any ideas? ___ 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: Firefox 13
On 2012-06-07 17:47, Warren Block wrote: Yesterday, Firefox 13 built and installed quickly. It was just the running part that did not go so well. Coredumps on start, it would start with add-ons disabled, but then coredump while typing a URL, or sometimes a few seconds later. Rebuilding everything Firefox depends on did not make any difference. Firefox 12 builds and runs fine, as do Chromium and xxxterm. This is on 9-stable from yesterday, amd64. The next step is to build with debug symbols; I was hoping the problem would have been experienced by someone else by now. Any ideas? Which compiler did you use, clang or gcc, and if gcc, which version? Regards! -- Niclas ___ 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: firefox 13.0,1 needs lang/gcc46 -- to RUN?!
CyberLeo Kitsana cyber...@cyberleo.net wrote: On 06/06/2012 02:18 PM, Heino Tiedemann wrote: Hi, Why this ports needs his compiler to RUN?! firefox 13.0,1 snip Required To Run: archivers/zip, lang/gcc46,... Just a shot in the dark for lang/gcc46, I'd say it's because Firefox dynamically links to a newer version of libgcc that is only available when it is installed. Its runtime dependency on archivers/zip can be explained by the fact that Firefox now packs its hundreds of GUI files (chrome) into a giant zip file (named omni.ja), for which it requires a zip library to read. You're welcome to tweak the Makefile to remove the runtime dependency and test it to see how badly it breaks; I've done the same to keep Perl and Python off my embedded system images when installing glib et alia. Glib only requires the languages for scripts used when compiling software, which is unlikely to occur on an embedded system. What ist the meaning of , | Use GCC 4.6 to fix build on newer FreeBSD versions ` What meians newer FreeBSD versions here? http://www.freshports.org/www/firefox/ And what means , | Don't depend on GCC 4.6 if clang is used ` How an I use clang? http://www.freshports.org/www/firefox/ 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: ports registering services in /etc/services and services_mkdb
Hi Olli, On 7-6-2012 16:59, Olli Hauer wrote: I don't think it is practical to patch all the ports like like bacula , spamd and others to not use getservbyname and hardcode the required ports? I've got a preliminary patch that I'm going to submit upstream that enables services support in net/nss-pam-ldapd. Services aren't as flexible as users/groups in that you can assign ranges for different NSS sources, thus running services_mkdb may in fact interfere with a site's infrastructure if the particular service has already been defined on a different port. Maybe it's wiser to standardize a pkg-message string? Also, one should never touch /etc/services if nsswitch.conf does not contain compat or files and finally, adding a single service without /etc/services using services_mkdb is not currently possible. -- Mel ___ 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
paths of ruby, python, perl...
Each time I've upgraded ruby, python, and perl I've encountered lengthy = reinstalls of the port files (p5-...) as well as higher-level programs which depend upon them. (Many pkg_which oneliners to parse. ..) This could be simplified if those /lang/ ports were all-in-= one-dir (like /perl/ rather than perl site_perl/5,10 site= _perl/5.12 /5.10 /5.12 etc... Maybe someone knows i= f such a path reconfiguration would break some upstream non-BSD standard... Thanks. J. Bouquet ___ 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: Ruby 1.9 as default
On 2-6-2012 3:32, Steve Wills wrote: Hi All, I think we should try to make Ruby 1.9 the default Ruby again and would like to see it done before 9.1 is released. I've submitted a patch which does this and requested and exp-run from portmgr. This may become obsolete soon, since graphics/gdal is going to be updated, but with my current (slightly outdated) ports tree it fails with not being able to find: a) the ruby binary since there is no /usr/local/bin/ruby b) as a side-effect ruby.h, but also because swig is using a deprecated Config interface that apparently is unable to set the include path correctly. swig-1.3.40 RUBY_VER=1.9 in /etc/make.conf RUBY config option set in graphics/gdal Given issues described with swig 1.x earlier on this list, you may want to investigate if swig 1.x should be removed/patched/whatever before this sweep. -- Mel ___ 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: Ruby 1.9 as default
On Thu, 07 Jun 2012 20:58:43 +0200 Mel Flynn rfl...@acsalaska.net mentioned: Given issues described with swig 1.x earlier on this list, you may want to investigate if swig 1.x should be removed/patched/whatever before this sweep. Swig 1.x actually works fine with ruby 1.9, I'm using it quite regularly. SWIG just generate the C source, it does not provide you with include path. It is a responsibility of the application to find out what the correct path are. You can look at my m4 macro as an example of how to do it properly: https://github.com/stass/autoconf-macros/blob/master/ax_ruby_ext.m4 -- Stanislav Sedov ST4096-RIPE () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments ___ 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: Firefox 13
On Thu, 7 Jun 2012, Niclas Zeising wrote: On 2012-06-07 17:47, Warren Block wrote: Yesterday, Firefox 13 built and installed quickly. It was just the running part that did not go so well. Coredumps on start, it would start with add-ons disabled, but then coredump while typing a URL, or sometimes a few seconds later. Rebuilding everything Firefox depends on did not make any difference. Firefox 12 builds and runs fine, as do Chromium and xxxterm. This is on 9-stable from yesterday, amd64. The next step is to build with debug symbols; I was hoping the problem would have been experienced by someone else by now. Any ideas? Which compiler did you use, clang or gcc, and if gcc, which version? Regards! gcc46, and I do have CPUTYPE?=native in make.conf... Interesting! Built without CPUTYPE set, Firefox seems fine. Compiler bug? ___ 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: Firefox 13
On Thu, Jun 7, 2012 at 2:55 PM, Warren Block wbl...@wonkity.com wrote: On Thu, 7 Jun 2012, Niclas Zeising wrote: On 2012-06-07 17:47, Warren Block wrote: Yesterday, Firefox 13 built and installed quickly. It was just the running part that did not go so well. Coredumps on start, it would start with add-ons disabled, but then coredump while typing a URL, or sometimes a few seconds later. Rebuilding everything Firefox depends on did not make any difference. Firefox 12 builds and runs fine, as do Chromium and xxxterm. This is on 9-stable from yesterday, amd64. The next step is to build with debug symbols; I was hoping the problem would have been experienced by someone else by now. Any ideas? Which compiler did you use, clang or gcc, and if gcc, which version? Regards! gcc46, and I do have CPUTYPE?=native in make.conf... Interesting! Built without CPUTYPE set, Firefox seems fine. Compiler bug? Not really surprised about that. I have stopped tweak the CPUTYPE several years ago when I discovered that the FreeBSD machines got very and very stable without tweak CPUTYPE. I don't even notice any of performance difference. Maybe I will if I look at the numbers. ;-) Cheers, Mezz -- mezz.free...@gmail.com - m...@freebsd.org FreeBSD GNOME Team http://www.FreeBSD.org/gnome/ - gn...@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: Ruby 1.9 as default
On 7-6-2012 21:36, Stanislav Sedov wrote: On Thu, 07 Jun 2012 20:58:43 +0200 Mel Flynn rfl...@acsalaska.net mentioned: Given issues described with swig 1.x earlier on this list, you may want to investigate if swig 1.x should be removed/patched/whatever before this sweep. Swig 1.x actually works fine with ruby 1.9, I'm using it quite regularly. SWIG just generate the C source, it does not provide you with include path. It is a responsibility of the application to find out what the correct path are. You can look at my m4 macro as an example of how to do it properly: https://github.com/stass/autoconf-macros/blob/master/ax_ruby_ext.m4 Point being, that: a) /usr/local/bin/ruby does not exist and apparently there are some ports that expect it b) if you symlink /usr/local/bin/ruby19 to ruby, that things still don't work for a port I don't think a package that is as widely used as gdal uses broken makefiles, so either: - these are issues with swig as they generate the makefiles (this was my assumption, but your mail tells me it is incorrect) - there are ways used in the wild to obtain ruby build information that no longer work: gmake -f RubyMakefile.mk build -e:1: Use RbConfig instead of obsolete and deprecated Config -- Mel ___ 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: Firefox 13
Niclas Zeising writes: Which compiler did you use, clang or gcc, and if gcc, which version? On: FreeBSD 10.0-CURRENT #0: Sun Mar 11 08:20:02 EDT 2012 amd64 and using clang, FireFox 13 builds and starts, but freezes after 2-3 seconds. The freeze locks focus (and therefore the mosue) on that window; it is possible to kill the process from the console using kill -KILL. The only option set is emable additional log messages. make.conf is available on request. Robert Huff ___ 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: Firefox 13
On 7-6-2012 21:55, Warren Block wrote: gcc46, and I do have CPUTYPE?=native in make.conf... Interesting! Built without CPUTYPE set, Firefox seems fine. Compiler bug? Shot in the dark: SSE support? Based on threads earlier on this list with respect to chrome. -- Mel ___ 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: Firefox 13
On Thu, 7 Jun 2012, Mel Flynn wrote: On 7-6-2012 21:55, Warren Block wrote: gcc46, and I do have CPUTYPE?=native in make.conf... Interesting! Built without CPUTYPE set, Firefox seems fine. Compiler bug? Shot in the dark: SSE support? Based on threads earlier on this list with respect to chrome. SSE support by gcc, you mean? No idea, but just to make sure I rebuilt with CPUTYPE?=native again, and that's definitely the problem. ___ 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: Firefox 13
On 7-6-2012 23:25, Warren Block wrote: On Thu, 7 Jun 2012, Mel Flynn wrote: On 7-6-2012 21:55, Warren Block wrote: gcc46, and I do have CPUTYPE?=native in make.conf... Interesting! Built without CPUTYPE set, Firefox seems fine. Compiler bug? Shot in the dark: SSE support? Based on threads earlier on this list with respect to chrome. SSE support by gcc, you mean? No idea, but just to make sure I rebuilt with CPUTYPE?=native again, and that's definitely the problem. I was referring to this post: http://lists.freebsd.org/pipermail/freebsd-ports/2012-May/075290.html While it's related to clang, CPUTYPE seems to have an effect on selected extensions and perhaps the root cause is there. Like I said, shot in the dark. -- Mel ___ 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: Ruby 1.9 as default
On Jun 7, 2012, at 2:58 PM, Mel Flynn rfl...@acsalaska.net wrote: On 2-6-2012 3:32, Steve Wills wrote: Hi All, I think we should try to make Ruby 1.9 the default Ruby again and would like to see it done before 9.1 is released. I've submitted a patch which does this and requested and exp-run from portmgr. This may become obsolete soon, since graphics/gdal is going to be updated, but with my current (slightly outdated) ports tree it fails with not being able to find: a) the ruby binary since there is no /usr/local/bin/ruby This is expected. Try setting RUBY_DEFAULT_VER instead. b) as a side-effect ruby.h, but also because swig is using a deprecated Config interface that apparently is unable to set the include path correctly. Sounds like it just needs a s/Config/RbConfig/ which is a standard Ruby 1.9 comparability fix. Steve swig-1.3.40 RUBY_VER=1.9 in /etc/make.conf RUBY config option set in graphics/gdal Given issues described with swig 1.x earlier on this list, you may want to investigate if swig 1.x should be removed/patched/whatever before this sweep. -- Mel ___ 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-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: Ruby 1.9 as default
On 06/07/12 17:57, Steve Wills wrote:
This is expected. Try setting RUBY_DEFAULT_VER instead.
I probably should have been more clear about this. The ruby ports only
create ${PREFIX}/bin/ruby for the default ruby. So if you have ruby 1.9
installed but it is not the default ruby, you won't have it. Setting
RUBY_DEFAULT_VER=1.9 in /etc/make.conf will help with this.
Likewise, I should have mentioned in my original mail that if anyone
wants to test Ruby 1.9 as the default in anticipation of the switch,
setting RUBY_DEFAULT_VER=1.9 in /etc/make.conf and rebuilding Ruby
related ports is the way to go. The more people who do this and report
issues before the switch happens, the better. I'd really appreciate any
and all reports of success or failure.
Thanks,
Steve
___
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] gdal 1.9.1 update and other changes
On Thu, Jun 7, 2012 at 2:25 PM, Rainer Hurling rhur...@gwdg.de wrote: Am 07.06.2012 05:30 (UTC+1) schrieb Sunpoet Po-Chuan Hsieh: Hi, Many thanks for this update. What I observed so far: (1) graphics/gdal builds and installs fine. There is a minor problem: dependend port science/libkml (as option) does not configure, if devel/swig13 is installed. I'll check that again. I've tested it in tinderbox which does not have swig13 in the jail. (2) graphics/py-gdal asks for option NUMPY several times, even once more if it wants to install (after build). The port should be OK without numpy but the array support will not be enabled. I'm considering to turn NUMPY on by default or just change it from optional to required dependency. (3) graphics(p5-Geo-GDAL gives warnings about unrecognized arguments, but it does build and install: Building against GDAL defined in /usr/local/bin/gdal-config Unrecognized argument in LIBS ignored: '-pthread' Writing Makefile_Geo__OGR for Geo::OGR Writing MYMETA.yml Unrecognized argument in LIBS ignored: '-pthread' Writing Makefile_Geo__GDAL__Const for Geo::GDAL::Const Writing MYMETA.yml Unrecognized argument in LIBS ignored: '-pthread' Writing Makefile_Geo__OSR for Geo::OSR Writing MYMETA.yml Unrecognized argument in LIBS ignored: '-pthread' Writing Makefile_Geo__GDAL for Geo::GDAL Writing MYMETA.yml make -f Makefile_Geo__GDAL (4) graphics/ruby-gdal builds and installs fine, distinctive features. (5) graphics/php-gdal does not build with following messages: === Building for php-gdal-1.9.1 /usr/bin/sed -e '/^GDAL_ROOT/d' /usr/local/share/gdal/GDALmake.opt /usr/ports/graphics/php-gdal/work/gdal-1.9.1/swig/php/../../GDALmake.opt /bin/cp /usr/local/include/cpl_config.h /usr/ports/graphics/php-gdal/work/gdal-1.9.1/swig/php/../../port/ c++ -I../../port -I../../gcore -I../../alg -I../../ogr `php-config --includes` -O2 -pipe -O2 -fno-strict-aliasing -pipe -msse3 -I/usr/local/include -fPIC -c gdal_wrap.cpp gdal_wrap.cpp: In function 'void* SWIG_ZTS_ConvertResourcePtr(zval*, swig_type_info*, int)': gdal_wrap.cpp:935: error: invalid conversion from 'const char*' to 'char*' gmake: *** [gdal_wrap.o] Fehler 1 *** [do-build] Error code 1 php-gdal does not build with php 5.4 (lang/php5). PHP_VER=53 in the old shar file indicates the ports framework to use php53 but php5 is not prohibited. I've updated the shar file. DEFAULT_PHP_VER=53 and IGNORE_WITH_PHP=5 should ensure not to use lang/php5. I haven't tested it with php52. Thanks for your test. :) Regards, sunpoet Hope this helps, Rainer GDAL 1.9.1 was released several days ago. I'd like to make some changes along with this update [1]. The most important one is about the language bindings. I decide to move them to separate ports: - Perl binding: graphics/p5-Geo-GDAL [2] - Python binding: graphics/py-gdal [3] - PHP binding: graphics/php-gdal [4] - Ruby binding: graphics/ruby-gdal [5] The other changes to the Makefile include: - Update to 1.9.1 - Build with thread-safe support by default - Add lzma support - Adjust OPTIONS: - Add ICONV, KML and WEBP - Remove GRASS (cyclic dependency), PERL, PHP, PYTHON, RUBY and THREADS (default) - Add corresponding CONFIGURE_ARGS for disabled features - Cosmetic change Please test if it works for you. If I don't receive critical feedback, I plan to commit them this weekend or next Monday. Thanks! [1] http://people.freebsd.org/~sunpoet/gdal/gdal-1.9.1.patch [2] http://people.freebsd.org/~sunpoet/gdal/p5-Geo-GDAL.shar [3] http://people.freebsd.org/~sunpoet/gdal/php-gdal.shar [4] http://people.freebsd.org/~sunpoet/gdal/py-gdal.shar [5] http://people.freebsd.org/~sunpoet/gdal/ruby-gdal.shar Regards, sunpoet -- Sunpoet Po-Chuan Hsieh sunpoet at sunpoet.net sunpoet at FreeBSD.org 4096R/CC57E36B 8AD8 68F2 7D2B 0A10 7E9B 8CC0 DC44 247E CC57 E36B http://people.FreeBSD.org/~sunpoet/pgpkeys.txt ___ 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
conditional config is skipped for optionsNG'ified ports
Hi,
I've noticed (while portupgrading www/nginx-devel) that despite of
the new options set it doesn't provide me with the configuration
diaglog. This is because _OPTIONS_OK is set when OPTIONS isn't,
and the latter is always true for ports that have been converted.
: $ pwd make -V PKGNAME -V _OPTIONS_READ -V _FILE_COMPLETE_OPTIONS_LIST -V
_OPTIONS_OK
: /usr/ports/www/nginx-devel
: nginx-devel-1.3.1
: nginx-devel-1.3.0
:
: yes
The following condition in bsd.port.mk should be taught about
optionsNG to fix the issue:
%%%
#
# Do preliminary work to detect if we need to run the config
# target or not.
#
.if (!defined(OPTIONS) || defined(CONFIG_DONE_${UNIQUENAME:U}) || \
defined(PACKAGE_BUILDING) || defined(BATCH))
_OPTIONS_OK=yes
.endif
%%%
Cheers,
--
Ruslan Ermilov
r...@freebsd.org
FreeBSD committer
___
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: conditional config is skipped for optionsNG'ified ports
On Fri, Jun 08, 2012 at 08:38:10AM +0400, Ruslan Ermilov wrote:
Hi,
I've noticed (while portupgrading www/nginx-devel) that despite of
the new options set it doesn't provide me with the configuration
diaglog. This is because _OPTIONS_OK is set when OPTIONS isn't,
and the latter is always true for ports that have been converted.
: $ pwd make -V PKGNAME -V _OPTIONS_READ -V _FILE_COMPLETE_OPTIONS_LIST -V
_OPTIONS_OK
: /usr/ports/www/nginx-devel
: nginx-devel-1.3.1
: nginx-devel-1.3.0
:
: yes
The following condition in bsd.port.mk should be taught about
optionsNG to fix the issue:
%%%
#
# Do preliminary work to detect if we need to run the config
# target or not.
#
.if (!defined(OPTIONS) || defined(CONFIG_DONE_${UNIQUENAME:U}) || \
defined(PACKAGE_BUILDING) || defined(BATCH))
_OPTIONS_OK=yes
.endif
%%%
Cheers,
--
Ruslan Ermilov
r...@freebsd.org
FreeBSD committer
Oh yes thank you, I forgot about it I'll fix it asap
regards
Bapt
pgplUDgQtdNxA.pgp
Description: PGP signature
INDEX build failed for 7.x
INDEX build failed with errors: Generating INDEX-7 - please wait.. Done. make_index: libvncserver-0.9.9_2: no entry for /graphics/png make_index: libvncserver-0.9.9_2: no entry for /graphics/png Committers on the hook: adamw bapt maho swills trhodes Most recent CVS update was: U devel/rubygem-logging/Makefile U devel/rubygem-logging/distinfo U editors/openoffice-3/Makefile U editors/openoffice-3-devel/Makefile U net/libvncserver/Makefile U sysutils/Makefile U sysutils/fsc/Makefile U sysutils/fsc/distinfo U sysutils/fsc/pkg-descr U www/webalizer/Makefile ___ 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
