Re: Ruby 1.9 as default
On Tue, 05 Jun 2012 21:14:06 -0400 Steve Wills 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 > > > 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 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 <> > > # 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 < < # Main FileStorage database < < # See .../ZODB/component.xml for directives (sectiontype < # "filestorage"). < path $INSTANCE/var/Data.fs < < mount-point / < --- > # > ## Main FileStorage database > # > # # See .../ZODB/component.xml for directives (sectiontype > # # "filestorage"). > # path $INSTANCE/var/Data.fs > # > #mount-point / > # 1042,1065c1049,1063 < # < # # The full mount-point syntax is: < # # < # # mount-point [:] < # # < # # 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 < # < # # 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 < # < # --- > > mount-point / > # ZODB cache, in number of objects > cache-size 5000 > > 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 > > 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=audio&portname=teamspeak_client portname: audio/wsoundprefs broken because: does not compile build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=audio&portname=wsoundprefs portname: chinese/big5con broken because: fails to build with new utmpx build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=chinese&portname=big5con portname: chinese/hztty broken because: fails to build with new utmpx build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=chinese&portname=hztty portname: databases/adstudio broken because: does not fetch build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=databases&portname=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=databases&portname=libudbc portname: databases/msql broken because: Broken on FreeBSD 9+ build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=databases&portname=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=databases&portname=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=deskutils&portname=sciplore-mindmapping portname: devel/dsss broken because: does not build build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=devel&portname=dsss portname: devel/gauche-gaunit broken because: does not package build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=devel&portname=gauche-gaunit portname: devel/gcvs broken because: does not compile build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=devel&portname=gcvs portname: devel/linux-js broken because: does not build build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=devel&portname=linux-js portname: devel/linuxthreads broken because: does not build build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=devel&portname=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_
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=archivers&portname=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=audio&portname=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=audio&portname=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=audio&portname=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=audio&portname=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=audio&portname=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=audio&portname=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=audio&portname=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=deskutils&portname=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=devel&portname=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=devel&portname=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: http://pointyhat.freebsd.org/errorlogs/i386-errorlogs/e.8.20120525110
FreeBSD ports which are currently marked forbidden
As part of an ongoing effort to reduce the number of problems in the FreeBSD ports system, we periodically notify users about ports that are marked as "forbidden" in their Makefiles. Often, these ports are so marked due to security concerns, such as known exploits. An overview of each port, including errors seen on the build farm, is included below. portname: graphics/linux-tiff forbidden because: Vulnerable since 2004-10-13, http://portaudit.freebsd.org/8816bf3a-7929-11df-bcce-0018f3e2eb82.html build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=graphics&portname=linux-tiff portname: mail/sympa5 forbidden because: Multiple vulnerabilities have been discovered in Sympa archive management that allow to skip the scenario-based authorization mechanisms. http://www.sympa.org/security_advisories build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=mail&portname=sympa5 portname: www/linux-f10-flashplugin10 forbidden because: insecure version - use flashplugin11 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=www&portname=linux-f10-flashplugin10 portname: x11-toolkits/linux-pango forbidden because: Vulnerable since 2009-05-13, http://portaudit.freebsd.org/4b172278-3f46-11de-becb-001cc0377035.html build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=x11-toolkits&portname=linux-pango ___ 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 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: accessibility/yasr broken because: fails to build with new utmpx build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=accessibility&portname=yasr portname: audio/gdam broken because: does not build build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=audio&portname=gdam portname: audio/gstreamer-plugins-flite broken because: Doesn't work due to link problem in audio/flite build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=audio&portname=gstreamer-plugins-flite portname: audio/hydrogen broken because: does not install build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=audio&portname=hydrogen portname: audio/rubyripper broken because: does not package build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=audio&portname=rubyripper portname: audio/teamspeak_client broken because: does not build build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=audio&portname=teamspeak_client portname: audio/wsoundprefs broken because: does not compile build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=audio&portname=wsoundprefs portname: benchmarks/polygraph broken because: does not build build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=benchmarks&portname=polygraph portname: benchmarks/polygraph31 broken because: does not build build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=benchmarks&portname=polygraph31 portname: cad/salome-gui broken because: does not compile build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=cad&portname=salome-gui portname: chinese/big5con broken because: fails to build with new utmpx build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=chinese&portname=big5con portname: chinese/cxterm broken because: fails to build with new utmpx build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=chinese&portname=cxterm portname: chinese/hztty broken because: fails to build with new utmpx build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=chinese&portname=hztty portname: chinese/tcl83 broken because: does not build build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=chinese&portname=tcl83 portname: comms/gmfsk broken because: does not build after log2 addition build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=comms&portname=gmfsk portname: comms/hso-kmod broken because: does not build with USB2, please try comms/uhso-kmod instead build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=comms&portname=hso-
Re: Zenoss Port Web-UI seems incomplete
[...] > > Actually I think I'll take a backup of the zope.conf file and copy the > zope.conf.in file over and see if that changes anything. > > > Regards, > > Kaya Ok well here we go this is interesting! I backed up the current zope.conf file then copied over the zope.conf.in file. It didn't work directly so I had to add /usr/local/zenoss to this part: #%define INSTANCE <> %define INSTANCE /usr/local/zenoss Now it seems to be up and running: tcp4 0 0 *.8080 *.*LISTEN However, for how long I don't know. as in if I restart or stop the service will it simply not start again? 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"
Unable to update to virtualbox-ose-additions 4.1.16
Hi, I am running a VM VirtualBox with FreeBSD 9-STABLE (updated on 06/05/12), initially with VirtualBox 4.1.8. Now I want to update my ports, but I can't update . My ports tree is up-to-date. I use the command <# portmaster -a -D --no-confirm> to update ports with portmaster tool. The error is : [...] The failing command: @cc -m64 -o /usr/ports/emulators/virtualbox-ose-additions/work/VirtualBox-4.1.16/out/freebsd.amd64/release/obj/VBoxClient/VBoxClient /usr/ports/emulators/virtualbox-ose-additions/work/VirtualBox-4.1.16/out/freebsd.amd64/release/obj/VBoxClient/main.o /usr/ports/emulators/virtualbox-ose-additions/work/VirtualBox-4.1.16/out/freebsd.amd64/release/obj/VBoxClient/src/VBox/GuestHost/SharedClipboard/clipboard-helper.o /usr/ports/emulators/virtualbox-ose-additions/work/VirtualBox-4.1.16/out/freebsd.amd64/release/obj/VBoxClient/src/VBox/GuestHost/SharedClipboard/x11-clipboard.o /usr/ports/emulators/virtualbox-ose-additions/work/VirtualBox-4.1.16/out/freebsd.amd64/release/obj/VBoxClient/clipboard.o /usr/ports/emulators/virtualbox-ose-additions/work/VirtualBox-4.1.16/out/freebsd.amd64/release/obj/VBoxClient/seamless.o /usr/ports/emulators/virtualbox-ose-additions/work/VirtualBox-4.1.16/out/freebsd.amd64/release/obj/VBoxClient/seamless-host.o /usr/ports/emulators/virtualbox-ose-additions/work/VirtualBox-4.1.16/out/freebsd.amd64/release/obj/VBoxClient/seamless-x11.o /usr/ports/emulators/virtualbox-ose-additions/work/VirtualBox-4.1.16/out/freebsd.amd64/release/obj/VBoxClient/thread.o /usr/ports/emulators/virtualbox-ose-additions/work/VirtualBox-4.1.16/out/freebsd.amd64/release/obj/VBoxClient/display.o /usr/ports/emulators/virtualbox-ose-additions/work/VirtualBox-4.1.16/out/freebsd.amd64/release/obj/VBoxClient/hostversion.o -L/usr/X11R6/lib32 -L/usr/X11R6/lib -L/usr/lib -L/usr/X11R6/lib -L/usr/local/lib -liconv /usr/ports/emulators/virtualbox-ose-additions/work/VirtualBox-4.1.16/out/freebsd.amd64/release/lib/additions/RuntimeGuestR3.a /usr/ports/emulators/virtualbox-ose-additions/work/VirtualBox-4.1.16/out/freebsd.amd64/release/lib/additions/VBoxGuestR3Lib.a /usr/ports/emulators/virtualbox-ose-additions/work/VirtualBox-4.1.16/out/freebsd.amd64/release/lib/additions/RuntimeGuestR3.a -lX11 -lXrandr -lXt -lsupc++ -lgcc_eh -lXext -lXmu -lpthread -liconv *** Error code 2 Stop in /usr/ports/emulators/virtualbox-ose-additions. *** Error code 1 Stop in /usr/ports/emulators/virtualbox-ose-additions. ===>>> make failed for emulators/virtualbox-ose-additions ===>>> Aborting update ===>>> Update for emulators/virtualbox-ose-additions failed ===>>> Aborting update Terminated [...] I posted the full output (with "script") here : http://pastebin.com/cmBbqzKx -- Info of the FreeBSD VM guest: # uname -a FreeBSD VirtualBox 9.0-STABLE FreeBSD 9.0-STABLE #0: Tue Jun 5 16:03:26 CEST 2012 root@VirtualBox:/usr/obj/usr/src/sys/GENERIC amd64 # pkg_info | grep virtualbox virtualbox-ose-additions-4.1.8 VirtualBox additions for FreeBSD guests -- This VM is installed on a Windows 7 host (VirtualBox 4.1.16r78094). Thanks for your help. Regards, Alexandre ___ 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...
For me, the lotusworldpro fix is not needed, as libreoffice build without any fix other than the original patches... I use only the PKGNG so when I remove boost*, it removes the package but not the dependencies (in the /var/db/pkg/local.sqlite) so when I reinstall boost*, everything is OK Sergio > --- 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 \ > +#)) ___ 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"
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
Re: libreoffice, Makefile fix proposal...
Hi, 2012/6/7 Kevin Oberman : > # 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"
Re: Unable to update to virtualbox-ose-additions 4.1.16
On Do., 7. Jun. 2012 12:33:38 CEST, Alexandre wrote: > Hi, > > I am running a VM VirtualBox with FreeBSD 9-STABLE (updated on 06/05/12), > initially with VirtualBox 4.1.8. > Now I want to update my ports, but I can't update > . My ports tree is up-to-date. > I use the command <# portmaster -a -D --no-confirm> to update ports with > portmaster tool. > > The error is : > [...] > The failing command: > @cc -m64 -o > /usr/ports/emulators/virtualbox-ose-additions/work/VirtualBox-4.1.16/out/freebsd.amd64/release/obj/VBoxClient/VBoxClient > /usr/ports/emulators/virtualbox-ose-additions/work/VirtualBox-4.1.16/out/freebsd.amd64/release/obj/VBoxClient/main.o > /usr/ports/emulators/virtualbox-ose-additions/work/VirtualBox-4.1.16/out/freebsd.amd64/release/obj/VBoxClient/src/VBox/GuestHost/SharedClipboard/clipboard-helper.o > /usr/ports/emulators/virtualbox-ose-additions/work/VirtualBox-4.1.16/out/freebsd.amd64/release/obj/VBoxClient/src/VBox/GuestHost/SharedClipboard/x11-clipboard.o > /usr/ports/emulators/virtualbox-ose-additions/work/VirtualBox-4.1.16/out/freebsd.amd64/release/obj/VBoxClient/clipboard.o > /usr/ports/emulators/virtualbox-ose-additions/work/VirtualBox-4.1.16/out/freebsd.amd64/release/obj/VBoxClient/seamless.o > /usr/ports/emulators/virtualbox-ose-additions/work/VirtualBox-4.1.16/out/freebsd.amd64/release/obj/VBoxClient/seamless-host.o > /usr/ports/emulators/virtualbox-ose-additions/work/VirtualBox-4.1.16/out/freebsd.amd64/release/obj/VBoxClient/seamless-x11.o > /usr/ports/emulators/virtualbox-ose-additions/work/VirtualBox-4.1.16/out/freebsd.amd64/release/obj/VBoxClient/thread.o > /usr/ports/emulators/virtualbox-ose-additions/work/VirtualBox-4.1.16/out/freebsd.amd64/release/obj/VBoxClient/display.o > /usr/ports/emulators/virtualbox-ose-additions/work/VirtualBox-4.1.16/out/freebsd.amd64/release/obj/VBoxClient/hostversion.o > -L/usr/X11R6/lib32 -L/usr/X11R6/lib -L/usr/lib -L/usr/X11R6/lib > -L/usr/local/lib -liconv > /usr/ports/emulators/virtualbox-ose-additions/work/VirtualBox-4.1.16/out/freebsd.amd64/release/lib/additions/RuntimeGuestR3.a > > /usr/ports/emulators/virtualbox-ose-additions/work/VirtualBox-4.1.16/out/freebsd.amd64/release/lib/additions/VBoxGuestR3Lib.a > > /usr/ports/emulators/virtualbox-ose-additions/work/VirtualBox-4.1.16/out/freebsd.amd64/release/lib/additions/RuntimeGuestR3.a > -lX11 -lXrandr -lXt -lsupc++ -lgcc_eh -lXext -lXmu > -lpthread -liconv > *** Error code 2 > > Stop in /usr/ports/emulators/virtualbox-ose-additions. > *** Error code 1 > > Stop in /usr/ports/emulators/virtualbox-ose-additions. > > ===>>> make failed for emulators/virtualbox-ose-additions > ===>>> Aborting update > > ===>>> Update for emulators/virtualbox-ose-additions failed > ===>>> Aborting update > > Terminated > [...] > > I posted the full output (with "script") here : > http://pastebin.com/cmBbqzKx > > -- > > Info of the FreeBSD VM guest: > > # uname -a > FreeBSD VirtualBox 9.0-STABLE FreeBSD 9.0-STABLE #0: Tue Jun 5 16:03:26 > CEST 2012 root@VirtualBox:/usr/obj/usr/src/sys/GENERIC amd64 > > # pkg_info | grep virtualbox > virtualbox-ose-additions-4.1.8 VirtualBox additions for FreeBSD guests > > -- > > This VM is installed on a Windows 7 host (VirtualBox 4.1.16r78094). > > Thanks for your help. This is a bug in libsupc++ that was merged to 9-STABLE some time ago. You can apply the following patch to /usr/src (and reinstall world) or wait around one week until the fix will be MFCd. http://home.bluelife.at/patches/libsupcpp-fix-new-operator-9-STABLE.diff ___ 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 "freebsd-port
Re: libreoffice, Makefile fix proposal...
2012/6/7 Sergio de Almeida Lenzi : > 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 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 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"
ports registering services in /etc/services and services_mkdb
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. So my questions: - should ports take care for rebuilding the database - should we implement something like USERS/GROUPS for services in bsd.port.mk - what are the consumers of /var/db/services.db and what is the impact of not rebuilding this database. -- regards, olli ___ 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 - 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 (
! (EL
Re: patch to update Evolution to 2.32.3
El día Thursday, June 07, 2012 a las 05:03:32PM +0200, Matthias Apitz escribió: > > 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 somehow one of the files is not included in the mails coming down; it is included in my out folder; I'm attaching the complete set as a tar archive; matthias -- Matthias Apitz t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211 e - 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-2.32.3.tar.gz 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, 7 Jun 2012, Martin Wilke wrote: 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. Thanks for your work on this! 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. WITH_NEW_XORG is already vague, right now we have two that could be considered new. Would WITH_XORG=7.5 or WITH_XORG=7.7 work? That makes it easier to tell what is being requested; "new" is a relative term. ___ 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"
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 wrote: > On 06/06/2012 02:18 PM, Heino Tiedemann wrote: >> Hi, >> >> Why this ports needs his compiler to RUN?! >> >> firefox 13.0,1 >> > >> >> 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 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: Unable to update to virtualbox-ose-additions 4.1.16
On Thu, Jun 7, 2012 at 1:46 PM, Bernhard Fröhlich wrote: > On Do., 7. Jun. 2012 12:33:38 CEST, Alexandre wrote: > > > Hi, > > > > I am running a VM VirtualBox with FreeBSD 9-STABLE (updated on 06/05/12), > > initially with VirtualBox 4.1.8. > > Now I want to update my ports, but I can't update > > . My ports tree is up-to-date. > > I use the command <# portmaster -a -D --no-confirm> to update ports with > > portmaster tool. > > > > The error is : > > [...] > > The failing command: > > @cc -m64 -o > > > /usr/ports/emulators/virtualbox-ose-additions/work/VirtualBox-4.1.16/out/freebsd.amd64/release/obj/VBoxClient/VBoxClient > > > /usr/ports/emulators/virtualbox-ose-additions/work/VirtualBox-4.1.16/out/freebsd.amd64/release/obj/VBoxClient/main.o > > > /usr/ports/emulators/virtualbox-ose-additions/work/VirtualBox-4.1.16/out/freebsd.amd64/release/obj/VBoxClient/src/VBox/GuestHost/SharedClipboard/clipboard-helper.o > > > /usr/ports/emulators/virtualbox-ose-additions/work/VirtualBox-4.1.16/out/freebsd.amd64/release/obj/VBoxClient/src/VBox/GuestHost/SharedClipboard/x11-clipboard.o > > > /usr/ports/emulators/virtualbox-ose-additions/work/VirtualBox-4.1.16/out/freebsd.amd64/release/obj/VBoxClient/clipboard.o > > > /usr/ports/emulators/virtualbox-ose-additions/work/VirtualBox-4.1.16/out/freebsd.amd64/release/obj/VBoxClient/seamless.o > > > /usr/ports/emulators/virtualbox-ose-additions/work/VirtualBox-4.1.16/out/freebsd.amd64/release/obj/VBoxClient/seamless-host.o > > > /usr/ports/emulators/virtualbox-ose-additions/work/VirtualBox-4.1.16/out/freebsd.amd64/release/obj/VBoxClient/seamless-x11.o > > > /usr/ports/emulators/virtualbox-ose-additions/work/VirtualBox-4.1.16/out/freebsd.amd64/release/obj/VBoxClient/thread.o > > > /usr/ports/emulators/virtualbox-ose-additions/work/VirtualBox-4.1.16/out/freebsd.amd64/release/obj/VBoxClient/display.o > > > /usr/ports/emulators/virtualbox-ose-additions/work/VirtualBox-4.1.16/out/freebsd.amd64/release/obj/VBoxClient/hostversion.o > > -L/usr/X11R6/lib32 -L/usr/X11R6/lib -L/usr/lib -L/usr/X11R6/lib > > -L/usr/local/lib -liconv > > > /usr/ports/emulators/virtualbox-ose-additions/work/VirtualBox-4.1.16/out/freebsd.amd64/release/lib/additions/RuntimeGuestR3.a > > > > > /usr/ports/emulators/virtualbox-ose-additions/work/VirtualBox-4.1.16/out/freebsd.amd64/release/lib/additions/VBoxGuestR3Lib.a > > > > > /usr/ports/emulators/virtualbox-ose-additions/work/VirtualBox-4.1.16/out/freebsd.amd64/release/lib/additions/RuntimeGuestR3.a > > -lX11 -lXrandr -lXt -lsupc++ -lgcc_eh -lXext > -lXmu > > -lpthread -liconv > > *** Error code 2 > > > > Stop in /usr/ports/emulators/virtualbox-ose-additions. > > *** Error code 1 > > > > Stop in /usr/ports/emulators/virtualbox-ose-additions. > > > > ===>>> make failed for emulators/virtualbox-ose-additions > > ===>>> Aborting update > > > > ===>>> Update for emulators/virtualbox-ose-additions failed > > ===>>> Aborting update > > > > Terminated > > [...] > > > > I posted the full output (with "script") here : > > http://pastebin.com/cmBbqzKx > > > > -- > > > > Info of the FreeBSD VM guest: > > > > # uname -a > > FreeBSD VirtualBox 9.0-STABLE FreeBSD 9.0-STABLE #0: Tue Jun 5 16:03:26 > > CEST 2012 root@VirtualBox:/usr/obj/usr/src/sys/GENERIC amd64 > > > > # pkg_info | grep virtualbox > > virtualbox-ose-additions-4.1.8 VirtualBox additions for FreeBSD guests > > > > -- > > > > This VM is installed on a Windows 7 host (VirtualBox 4.1.16r78094). > > > > Thanks for your help. > > This is a bug in libsupc++ that was merged to 9-STABLE some time ago. You > can apply the following patch to /usr/src (and reinstall world) or wait > around one week until the fix will be MFCd. > > http://home.bluelife.at/patches/libsupcpp-fix-new-operator-9-STABLE.diff > Hi Bernhard, I applied your patch and reinstall world. After, VirtualBox-OSE-Additions-4.1. 16 port has been built and installed without problem. Thank you for your help. Regards, Alexandre ___ 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 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 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 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 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 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"
