Re: Old ports bugs analyzis
On Tue, Mar 30, 2010 at 10:19 PM, Doug Barton do...@freebsd.org wrote: On 03/30/10 21:36, Arseny Nasokin wrote: I don't clearly understand, will be ports system removed? At this time all discussion is theoretical. LONG before we make any actual changes the users will have a chance to chime in, and will be notified if any actual changes are made. Ports shouldn't ever be removed; it's just that the focus for folks should be shifted to binary packages unless they have a pressing urge to install packages from source, or don't want the bloat associated with the package they're installing. Doug is right though -- it's going to take a while before what's being discussed is going to happen and we'll provide sufficient heads up before the changes are made. HTH, -Garrett ___ 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: Old ports bugs analyzis
On Tue, Mar 30, 2010 at 9:36 PM, Arseny Nasokin eir...@gmail.com wrote:
On 31 Mar 2010, at 04:14, Garrett Cooper yanef...@gmail.com wrote:
Today binary packages are rolled as generic as possible provided the
architecture they're built for and are monolithic, meaning that they
contain the build, lib, patch, and run dependencies required to build
everything, as they're generated after an in-place install in
${PREFIX} .
One of many ideas we were kicking around on #bsdports was to produce
`fat packages' which would be usable in package installation and ports
building scenarios (similar to the headache that exists in many Linux
distros with -devel and non-devel packages), but the user could
specify whether or not they wanted the -devel pieces or not (if it
applied) -- so only one set of packages would need to be distributed.
We didn't really kick the idea around too much, but it was still a
novelty that should be `nursed' to a proper conclusion as it would
allow folks who roll packages and install on embedded systems /
install bases, or prefer installing via packages, to have small
install bases, and smaller potential binary roll up after the fact.
I can't see and discuss in IRC due browser and platform(software part)
limitations in nearest future.
I don't clearly understand, will be ports system removed? Will there will be
sourse and binary packages or will it be Gentoo-style portages, which will
provide installation from binary or source with options?
Gentoo portage is maintainer hell; we have enough fun with ports not
to get stuck in that mess.
Almost all packages in my systems has custom settings.
Which is exactly why I advocate using ports for my desktops and
servers. I just have other vested interests outside of my personal
machines where binary packages are better suited than installed a
boatload of packages from source.
Cool thing is though, if people use standard packages, there's a
greater chance of there not being stability issues with the packages
themselves right (or at least all of the issues will be known
upfront)?
Thanks :),
-Garrett
___
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
Alerta De Seguranca Bradesco
Bradesco S/A ID do Cliente: BR0013581 Prezado Cliente, Por motivos de segurana comunicamos a todos os clientes que, visando barrar o constante aumento de fraudes no Internet Banking Bradesco ser obrigatrio realizar a Atualizao do seu Carto Chave de Segurana. Caso no efetue a sua Atualizao obrigatria com urgncia, o acesso via Caixas-Eletrnicos e Internet-Banking ser suspenso. Utilize o boto abaixo para efetuar a atualizao: [1]Atualizar Dados [2]Agora Ateno: A atualizao obrigatria e de responsabilidade do cliente, o Banco Bradesco S/A no se responsabilizar por danos sofridos caso as chaves no sejam atualizadas. [3]| Bradesco Notcias | Fale Conosco | Oportunidades de Carreira | Politica de Qualidade | Poltica de RH | Rede de Atendimento | Bradesco S/A 2010 References 1. http://www.haagsestraat.com/cms/BradescoDiaeNoite 2. http://www.haagsestraat.com/cms/BradescoDiaeNoite 3. http://www.haagsestraat.com/cms/BradescoDiaeNoite/ ___ 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
Openoffice 3.2.0 build error
Hi, when trying to compile openoffice.org-3 I'm getting: c++ -fmessage-length=0 -c -O2 -fno-strict-aliasing -DENABLE_LAYOUT=0 -DENABLE_LAYOUT_EXPERIMENTAL=0 -I. -I../../../../../../unxfbsdx.pro/inc/c5t_testresult -I../inc -I../../../../../../inc/pch -I../../../../../../inc -I../../../../../../unx/inc -I../../../../../../unxfbsdx.pro/inc -I. -I/usr/obj/amd64-athlon64-8.0/usr/ports/editors/openoffice.org-3/work/OOO320 _m12/solver/320/unxfbsdx.pro/inc/stl -I/usr/obj/amd64-athlon64-8.0/usr/ports/editors/openoffice.org-3/work/OOO320 _m12/solver/320/unxfbsdx.pro/inc/external -I/usr/obj/amd64-athlon64-8.0/usr/ports/editors/openoffice.org-3/work/OOO320 _m12/solver/320/unxfbsdx.pro/inc -I/usr/obj/amd64-athlon64-8.0/usr/ports/editors/openoffice.org-3/work/OOO320 _m12/solenv/unxfbsdx/inc -I/usr/obj/amd64-athlon64-8.0/usr/ports/editors/openoffice.org-3/work/OOO320 _m12/solenv/inc -I/usr/obj/amd64-athlon64-8.0/usr/ports/editors/openoffice.org-3/work/OOO320 _m12/res -I/usr/obj/amd64-athlon64-8.0/usr/ports/editors/openoffice.org-3/work/OOO320 _m12/solver/320/unxfbsdx.pro/inc/stl -I/usr/obj/amd64-athlon64-8.0/usr/ports/editors/openoffice.org-3/work/OOO320 _m12/solenv/inc/Xp31 -I/usr/local/diablo-jdk1.6.0/include -I/usr/local/diablo-jdk1.6.0/include/freebsd -I/usr/local/diablo-jdk1.6.0/include/bsd -I/usr/local/diablo-jdk1.6.0/include/linux -I/usr/local/diablo-jdk1.6.0/include/native_threads/include -I/usr/local/include -I/usr/obj/amd64-athlon64-8.0/usr/ports/editors/openoffice.org-3/work/OOO320 _m12/solver/320/unxfbsdx.pro/inc/offuh -I../../include -I../../../../../../res -I. -pipe -fvisibility-inlines-hidden -g1 -Wall -Wextra -Wendif-labels -Wshadow -Wno-ctor-dtor-privacy -Wno-non-virtual-dtor -fpic -DFREEBSD -DUNX -DVCL -DGCC -DC341 -DX86_64 -DX86_64 -D_PTHREADS -D_REENTRANT -DNEW_SOLAR -D_USE_NAMESPACE=1 -DSTLPORT_VERSION=450 -DHAVE_GCC_VISIBILITY_FEATURE -D__DMAKE -DUNIX -DCPPU_ENV=gcc3 -DGXX_INCLUDE_PATH=/usr/include/c++/4.2 -DSUPD=320 -DPRODUCT -DNDEBUG -DPRODUCT_FULL -DOSL_DEBUG_LEVEL=0 -DOPTIMIZE -DCUI -DSOLAR_JAVA -DSHAREDLIB -D_DLL_ -fexceptions -fno-enforce-eh-specs -DEXCEPTIONS_ON -o ../../../../../../unxfbsdx.pro/slo/TestResult.o /usr/obj/amd64-athlon64-8.0/usr/ports/editors/openoffice.org-3/work/OOO320_m 12/cppunit/unxfbsdx.pro/misc/build/cppunit-1.8.0/src/result/TestResult.cpp In file included from /usr/obj/amd64-athlon64-8.0/usr/ports/editors/openoffice.org-3/work/OOO320_m 12/cppunit/unxfbsdx.pro/misc/build/cppunit-1.8.0/src/result/TestResult.cpp:4 : ../../include/cppunit/result/TestResult.h:72: error: 'ErrorType' has not been declared ../../include/cppunit/result/TestResult.h:72: error: expected ',' or '...' before 'eType' /usr/obj/amd64-athlon64-8.0/usr/ports/editors/openoffice.org-3/work/OOO320_m 12/cppunit/unxfbsdx.pro/misc/build/cppunit-1.8.0/src/result/TestResult.cpp:4 6: error: 'ErrorType' has not been declared /usr/obj/amd64-athlon64-8.0/usr/ports/editors/openoffice.org-3/work/OOO320_m 12/cppunit/unxfbsdx.pro/misc/build/cppunit-1.8.0/src/result/TestResult.cpp:4 6: error: expected ',' or '...' before '_eType' /usr/obj/amd64-athlon64-8.0/usr/ports/editors/openoffice.org-3/work/OOO320_m 12/cppunit/unxfbsdx.pro/misc/build/cppunit-1.8.0/src/result/TestResult.cpp: In member function 'virtual void CppUnit::TestResult::addError(CppUnit::Test*, CppUnit::Exception*, int)': /usr/obj/amd64-athlon64-8.0/usr/ports/editors/openoffice.org-3/work/OOO320_m 12/cppunit/unxfbsdx.pro/misc/build/cppunit-1.8.0/src/result/TestResult.cpp:4 8: error: '_eType' was not declared in this scope /usr/obj/amd64-athlon64-8.0/usr/ports/editors/openoffice.org-3/work/OOO320_m 12/cppunit/unxfbsdx.pro/misc/build/cppunit-1.8.0/src/result/TestResult.cpp: At global scope: /usr/obj/amd64-athlon64-8.0/usr/ports/editors/openoffice.org-3/work/OOO320_m 12/cppunit/unxfbsdx.pro/misc/build/cppunit-1.8.0/src/result/TestResult.cpp:4 6: warning: unused parameter 'num' /usr/obj/amd64-athlon64-8.0/usr/ports/editors/openoffice.org-3/work/OOO320_m 12/cppunit/unxfbsdx.pro/misc/build/cppunit-1.8.0/src/result/TestResult.cpp: In member function 'virtual void CppUnit::TestResult::addFailure(CppUnit::Test*, CppUnit::Exception*)': /usr/obj/amd64-athlon64-8.0/usr/ports/editors/openoffice.org-3/work/OOO320_m 12/cppunit/unxfbsdx.pro/misc/build/cppunit-1.8.0/src/result/TestResult.cpp:5 9: error: 'ErrorType' has not been declared dmake: Error code 1, while making '../../../../../../unxfbsdx.pro/slo/TestResult.obj' dmake: Error code 255, while making 'target' dmake: Error code 255, while making './unxfbsdx.pro/misc/build/so_built_so_cppunit' How can this be fixed? ___ 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: Old ports bugs analyzis
On 31 Mar 2010, at 10:20, Garrett Cooper yanef...@gmail.com wrote:
On Tue, Mar 30, 2010 at 9:36 PM, Arseny Nasokin eir...@gmail.com
wrote:
On 31 Mar 2010, at 04:14, Garrett Cooper yanef...@gmail.com wrote:
Today binary packages are rolled as generic as possible provided the
architecture they're built for and are monolithic, meaning that they
contain the build, lib, patch, and run dependencies required to
build
everything, as they're generated after an in-place install in
${PREFIX} .
One of many ideas we were kicking around on #bsdports was to produce
`fat packages' which would be usable in package installation and
ports
building scenarios (similar to the headache that exists in many
Linux
distros with -devel and non-devel packages), but the user could
specify whether or not they wanted the -devel pieces or not (if it
applied) -- so only one set of packages would need to be
distributed.
We didn't really kick the idea around too much, but it was still a
novelty that should be `nursed' to a proper conclusion as it would
allow folks who roll packages and install on embedded systems /
install bases, or prefer installing via packages, to have small
install bases, and smaller potential binary roll up after the fact.
I can't see and discuss in IRC due browser and platform(software
part)
limitations in nearest future.
I don't clearly understand, will be ports system removed? Will
there will be
sourse and binary packages or will it be Gentoo-style portages,
which will
provide installation from binary or source with options?
Gentoo portage is maintainer hell; we have enough fun with ports not
to get stuck in that mess.
Almost all packages in my systems has custom settings.
Which is exactly why I advocate using ports for my desktops and
servers. I just have other vested interests outside of my personal
machines where binary packages are better suited than installed a
boatload of packages from source.
Cool thing is though, if people use standard packages, there's a
greater chance of there not being stability issues with the packages
themselves right (or at least all of the issues will be known
upfront)?
Thanks :),
-Garrett
If we are talk about specialized optimisations or customisations we
should talk about ports system. If we talk about desktop machines,
there binary packages are better in most cases (for example, using
Synaptics frontend)
___
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: Old ports bugs analyzis
On 31 Mar 2010, at 09:19, Doug Barton do...@freebsd.org wrote: On 03/30/10 21:36, Arseny Nasokin wrote: I don't clearly understand, will be ports system removed? At this time all discussion is theoretical. LONG before we make any actual changes the users will have a chance to chime in, and will be notified if any actual changes are made. Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover!http://SupersetSolutions.com/ Understand, thanks. Can I help with something? ___ 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: Old ports bugs analyzis
On Wed, Mar 31, 2010 at 12:59 AM, Arseny Nasokin eir...@gmail.com wrote:
On 31 Mar 2010, at 10:20, Garrett Cooper yanef...@gmail.com wrote:
On Tue, Mar 30, 2010 at 9:36 PM, Arseny Nasokin eir...@gmail.com wrote:
On 31 Mar 2010, at 04:14, Garrett Cooper yanef...@gmail.com wrote:
Today binary packages are rolled as generic as possible provided the
architecture they're built for and are monolithic, meaning that they
contain the build, lib, patch, and run dependencies required to build
everything, as they're generated after an in-place install in
${PREFIX} .
One of many ideas we were kicking around on #bsdports was to produce
`fat packages' which would be usable in package installation and ports
building scenarios (similar to the headache that exists in many Linux
distros with -devel and non-devel packages), but the user could
specify whether or not they wanted the -devel pieces or not (if it
applied) -- so only one set of packages would need to be distributed.
We didn't really kick the idea around too much, but it was still a
novelty that should be `nursed' to a proper conclusion as it would
allow folks who roll packages and install on embedded systems /
install bases, or prefer installing via packages, to have small
install bases, and smaller potential binary roll up after the fact.
I can't see and discuss in IRC due browser and platform(software part)
limitations in nearest future.
I don't clearly understand, will be ports system removed? Will there will
be
sourse and binary packages or will it be Gentoo-style portages, which
will
provide installation from binary or source with options?
Gentoo portage is maintainer hell; we have enough fun with ports not
to get stuck in that mess.
Almost all packages in my systems has custom settings.
Which is exactly why I advocate using ports for my desktops and
servers. I just have other vested interests outside of my personal
machines where binary packages are better suited than installed a
boatload of packages from source.
Cool thing is though, if people use standard packages, there's a
greater chance of there not being stability issues with the packages
themselves right (or at least all of the issues will be known
upfront)?
Thanks :),
-Garrett
If we are talk about specialized optimisations or customisations we should
talk about ports system. If we talk about desktop machines, there binary
packages are better in most cases (for example, using Synaptics frontend)
YMMV, but most of the time binary packages are built with the idea in
mind that it will meet the majority of the end-users' needs instead of
a specific case (unless there is a good reason for there being
variance, in that case ports are split, i.e. vim, vim-lite, etc).
There is a small amount of optimization that can be gained by using
proper CFLAGS as well with more modern hardware (let's face it.. the
default flags that binary packages are built with are meant to run on
generic old-school IBM clones all the way up to the most bleeding edge
AMD and Intel processors for instance) -- so if you use the
appropriate CPUTYPE and CFLAGS you can gain performance wise, because
you're tailoring the programs you compile to meet your system's
capabilities. You just have to be careful because ricing is something
that Gentoo users got themselves in trouble with back around 2003 ~
2004, and then I think that most people learned that they weren't
really gaining much in performance and were losing in stability, so
they stopped ricing their compiles.
Cheers,
-Garrett
___
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: x11-toolkits/qt4-gui fails with png and/or zlib.h off64_t
On Tue, 30 Mar 2010 12:32:33 -0700 Xin LI delp...@delphij.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2010/03/30 12:22, Doug Barton wrote: Testing it again I see that I didn't go far enough up to find the real error, sorry Dirk. The actual problem seems to be with zlib.h. This is from qt4-gui: [...] -DQ_INTERNAL_QAPP_SRC -DQT_CORE_LIB -D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE -I/usr/local/share/qt4/mkspecs/freebsd-g++ -I. There are some discussion about these _LARGEFILE64_SOURCE usage on zlib developers' mailing list. To put it short, it's now believed that the usage of _LARGEFILE64_SOURCE on FreeBSD is wrong. I'm not quite sure though, if I should use some workaround over this, like Mac OS X did (newer zlib has a similar change by requiring _LFS64_SOURCE): Index: zconf.h === - --- zconf.h (revision 205883) +++ zconf.h (working copy) @@ -375,7 +375,7 @@ # endif #endif - -#ifdef _LARGEFILE64_SOURCE +#if defined(_LARGEFILE64_SOURCE) !defined(__FreeBSD__) # include sys/types.h #endif Index: zlib.h === - --- zlib.h (revision 205883) +++ zlib.h(working copy) @@ -1556,7 +1556,7 @@ inflateBackInit_((strm), (windowBits), (window), \ ZLIB_VERSION, sizeof(z_stream)) - -#ifdef _LARGEFILE64_SOURCE +#if defined(_LARGEFILE64_SOURCE) !defined(__FreeBSD__) ZEXTERN gzFile ZEXPORT gzopen64 OF((const char *, const char *)); ZEXTERN off64_t ZEXPORT gzseek64 OF((gzFile, off64_t, int)); ZEXTERN off64_t ZEXPORT gztell64 OF((gzFile)); This patch also fixes the build for vlc. -- Gary Jennejohn ___ 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: Old ports bugs analyzis [sic]
On Wed, 31 Mar 2010 01:39:35 -0700, Garrett Cooper yanef...@gmail.com articulated: On Wed, Mar 31, 2010 at 12:59 AM, Arseny Nasokin eir...@gmail.com wrote: On 31 Mar 2010, at 10:20, Garrett Cooper yanef...@gmail.com wrote: On Tue, Mar 30, 2010 at 9:36 PM, Arseny Nasokin eir...@gmail.com wrote: On 31 Mar 2010, at 04:14, Garrett Cooper yanef...@gmail.com wrote: [snip, snip, snip, snip] If I could just add my 2¢ to this discussion. I really appreciate the fact that, in most cases anyway, FreeBSD makes available through its maintainers a collection of up-to-date software. Now I realize that FreeBSD does have a (in my opinion unreasonable) problem with certain software in its base system that has an inappropriate GPL or whatever license, though this usually causes the end user no great harm. Now, many systems do not follow FreeBSD's lead. Some are still supplying, as an example Postfix 2.1 or other software that has been deprecated for over 3 years as their current versions. This causes users on these systems to either work with old software or roll their own which can lead to unforeseen problems. I would certainly hope that FreeBSD does not fall into that abyss. -- Jerry freebsd-ports.u...@seibercom.net Disclaimer: off-list followups get on-list replies or get ignored. Please do not ignore the Reply-To header. __ I will never lie to you. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Old ports bugs analyzis
On 31 Mar 2010, at 12:39, Garrett Cooper yanef...@gmail.com wrote: If we are talk about specialized optimisations or customisations we should talk about ports system. If we talk about desktop machines, there binary packages are better in most cases (for example, using Synaptics frontend) YMMV, but most of the time binary packages are built with the idea in mind that it will meet the majority of the end-users' needs instead of a specific case (unless there is a good reason for there being variance, in that case ports are split, i.e. vim, vim-lite, etc). There is a small amount of optimization that can be gained by using proper CFLAGS as well with more modern hardware (let's face it.. the default flags that binary packages are built with are meant to run on generic old-school IBM clones all the way up to the most bleeding edge AMD and Intel processors for instance) -- so if you use the appropriate CPUTYPE and CFLAGS you can gain performance wise, because you're tailoring the programs you compile to meet your system's capabilities. You just have to be careful because ricing is something that Gentoo users got themselves in trouble with back around 2003 ~ 2004, and then I think that most people learned that they weren't really gaining much in performance and were losing in stability, so they stopped ricing their compiles. Cheers, -Garrett I've talked about custom built-in settings. Different options are need in different situations. We doesn't have any real statistics about options use. For example, gvim(1) is good idea on most desktop systems, but after some issue, I build vim without GUI support. Issue is simple: Start x11, run xterm, run screen in it, detach, shutdown x11 server. Attach to screen from text mode and run vim. You'll get at least warning and slow startup. Second issue about is why should X11 be on headless server? What should we do in this case? Create 10-20 packages for every program? Or provide customisation interface (ports tree)? If second we can provide ports tree, which can download prebuild package if common options are used or build it in other case or if user want 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: [RFC] Reduce namespace pollution on zlib.h
On 2010-Mar-27, 02:51, Dag-Erling Smørgrav wrote: Xin LI delp...@delphij.net writes: So... May I consider my import just exposed some existing bugs in other applications and we don't want to workaround these issues? Correct. Just to make it clear so that everyone knows how we're going to handle this: are you (src people) going to commit a fix to unexpose LFS crap or are we (ports people) supposed to fix each and every single port that supposes to be on Linux? The attentive reader will note a bias towards the former :) -- Pietro Cerutti The FreeBSD Project g...@freebsd.org PGP Public Key: http://gahr.ch/pgp pgpBDuTIcSGH3.pgp Description: PGP signature
Re: [RFC] Reduce namespace pollution on zlib.h
I will merge an upstream change from zlib, which basically unexpose LFS stuff on FreeBSD, and I plan to keep the off_t bits == 64. However, I would highly recommend ports maintainers to push upstream fix for LFS64 definition removal since they are wrong on FreeBSD On Mar 31, 2010 3:30 AM, Pietro Cerutti g...@gahr.ch wrote: On 2010-Mar-27, 02:51, Dag-Erling Smørgrav wrote: Xin LI delp...@delphij.net writes: So... ... Just to make it clear so that everyone knows how we're going to handle this: are you (src people) going to commit a fix to unexpose LFS crap or are we (ports people) supposed to fix each and every single port that supposes to be on Linux? The attentive reader will note a bias towards the former :) -- Pietro Cerutti The FreeBSD Project g...@freebsd.org PGP Public Key: http://gahr.ch/pgp ___ 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: [RFC] Reduce namespace pollution on zlib.h
On 2010-Mar-31, 03:41, Xin LI wrote: I will merge an upstream change from zlib, which basically unexpose LFS stuff on FreeBSD, and I plan to keep the off_t bits == 64. However, I would highly recommend ports maintainers to push upstream fix for LFS64 definition removal since they are wrong on FreeBSD Sounds great, thanks! On Mar 31, 2010 3:30 AM, Pietro Cerutti g...@gahr.ch wrote: On 2010-Mar-27, 02:51, Dag-Erling Smørgrav wrote: Xin LI delp...@delphij.net writes: So... ... Just to make it clear so that everyone knows how we're going to handle this: are you (src people) going to commit a fix to unexpose LFS crap or are we (ports people) supposed to fix each and every single port that supposes to be on Linux? The attentive reader will note a bias towards the former :) -- Pietro Cerutti The FreeBSD Project g...@freebsd.org PGP Public Key: http://gahr.ch/pgp ___ 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 -- Pietro Cerutti The FreeBSD Project g...@freebsd.org PGP Public Key: http://gahr.ch/pgp pgpbtgmgIxofi.pgp Description: PGP signature
Re: [RFC] deprecate @exec and @unexec in plists in favor of pre-install and post-install scripts
Quoting Florent Thoumie f...@xbsd.org (from Mon, 29 Mar 2010 09:10:54 +): I mentioned getting rid of those pesky @*exec lines a few years ago, but this was met by quite a lot of objection. I still think it would be a good change, assuming that we provide equivalent (or better) features: - Configuration files should be marked and automatically dealt with by the infrastructure, not by esoteric commands. - Subroutines for shell scripts should be provided along with pkg_install, or be installed by a third party port (users/groups creation comes to mind). - Scripts should be automatically picked up as you mentioned. We're trying to shove most targets in pkg-install, but it probably would be best to split it (preinstall, postinstall, predeinstall, postdeinstall). Good thing is, this doesn't require any change in pkg_install since it's already supported. One of the added bonus is that some code that appears both in Makefile and pkg-plist will only be in preinstall/postinstall scripts. Given that a lot of the @(un)exec is comming from ports/Mk/bsd.*.mk, and that you can detect if there is already a pre-/post-install script in bsd.port.mk, it should be not so hard for the people which propose those (IMO good) ideas to come up with a patch for bsd.port.mk which generates pre-/post-install scripts with appropriate commands and does not add the @(un)exec to pkg-plist for those ports, which do not have a pre-/post-install script. It could serve as a proof of concept and would show more clearly what you have in mind. Done nicely, it also allows to keep a lot of the stuff in the Makefile and only write such scripts by hand if absolutely necessary (think about e.g. CREATE_USER=name1:UID1 name2:UID2 which would already cover a lot if not most use cases). Bye, Alexander. -- Behold the unborn foetus and Weep salt tears crocodilian; All life is sacred (save, of course, An enemy civilian). http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ 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
[BROKEN] ports/misc/rfc with -i flag
Whenever I use rfc -i to update the index I am getting this: Modem users one moment, it's about 400k (doesn't need to be updated often) original lines = 22143 /usr/local/etc/rfc-index new lines = 7 /usr/local/etc/rfc-index With the contents of: Forbidden You don't have permission to access /in-notes/rfc-index.txt on this server. Additionally, a 403 Forbidden error was encountered while trying to use an ErrorDocument to handle the request. This follows through to every server I have it try to connect to. Could they be possibly blocking by referer or only excepting specific referers ? Is there anything you can suggest changing in the script for the meantime to resolve this error ?. rfc-index is able to be fetched by methods of fetch(1) and wget(1) on FreeBSD so this seems to be specific to rfc(1) While this is busted I just replaced the rfc(1) -i with wget(1) in a crontab to update it once a month until this is fixed. Thanks, PS: Other tool suggestions are perfectly welcome. I would be interested to hear what everyones using for these purposes. -- jhell ___ 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: [RFC] deprecate @exec and @unexec in plists in favor of pre-install and post-install scripts
On Wed, Mar 31, 2010 at 11:49 AM, Alexander Leidinger alexan...@leidinger.net wrote: Quoting Florent Thoumie f...@xbsd.org (from Mon, 29 Mar 2010 09:10:54 +): I mentioned getting rid of those pesky @*exec lines a few years ago, but this was met by quite a lot of objection. I still think it would be a good change, assuming that we provide equivalent (or better) features: - Configuration files should be marked and automatically dealt with by the infrastructure, not by esoteric commands. - Subroutines for shell scripts should be provided along with pkg_install, or be installed by a third party port (users/groups creation comes to mind). - Scripts should be automatically picked up as you mentioned. We're trying to shove most targets in pkg-install, but it probably would be best to split it (preinstall, postinstall, predeinstall, postdeinstall). Good thing is, this doesn't require any change in pkg_install since it's already supported. One of the added bonus is that some code that appears both in Makefile and pkg-plist will only be in preinstall/postinstall scripts. Given that a lot of the @(un)exec is comming from ports/Mk/bsd.*.mk, and that you can detect if there is already a pre-/post-install script in bsd.port.mk, it should be not so hard for the people which propose those (IMO good) ideas to come up with a patch for bsd.port.mk which generates pre-/post-install scripts with appropriate commands and does not add the @(un)exec to pkg-plist for those ports, which do not have a pre-/post-install script. That would be a good start indeed, but this is the easy part. It could serve as a proof of concept and would show more clearly what you have in mind. Done nicely, it also allows to keep a lot of the stuff in the Makefile and only write such scripts by hand if absolutely necessary (think about e.g. CREATE_USER=name1:UID1 name2:UID2 which would already cover a lot if not most use cases). CREATE_USER? Have you been living under a rock recently? :-) I suppose Garrett sent this email to get a feel of what the general consensus was. If it turns out that people agree we should get rid of those lines, then I'm sure we can find people willing to do the necessary work. -- Florent Thoumie f...@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: [RFC] deprecate @exec and @unexec in plists in favor of pre-install and post-install scripts
Quoting Florent Thoumie f...@xbsd.org (from Wed, 31 Mar 2010 12:00:53 +): It could serve as a proof of concept and would show more clearly what you have in mind. Done nicely, it also allows to keep a lot of the stuff in the Makefile and only write such scripts by hand if absolutely necessary (think about e.g. CREATE_USER=name1:UID1 name2:UID2 which would already cover a lot if not most use cases). CREATE_USER? Have you been living under a rock recently? :-) Seems so... but hey, not every port creates users, so I feel free to reject the pointy hat. :) I suppose Garrett sent this email to get a feel of what the general consensus was. If it turns out that people agree we should get rid of those lines, then I'm sure we can find people willing to do the necessary work. Personally I do not care if those lines vanish or not, but I agree that it would be a good idea to create some kind of library of common stuff (which includes the cleanup of existing stuff as time permits). This library does not need to do this stuff the same way as it is done currently, if the new way is more easy (in whatever way makes sense here) for the person porting some software. The see several benefits in the pre-/post-install way and no obvious harm in case the script is created automatically by the ports collection most of the time. Or in short: ++vote; Bye, Alexander. -- Watership Down: You've read the book. You've seen the movie. Now eat the stew! http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ 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: Openoffice 3.2.0 build error
On 03/31/2010 03:36, Oliver Lehmann wrote: Hi, when trying to compile openoffice.org-3 I'm getting: c++ -fmessage-length=0 -c -O2 -fno-strict-aliasing -DENABLE_LAYOUT=0 -DENABLE_LAYOUT_EXPERIMENTAL=0 -I. -I../../../../../../unxfbsdx.pro/inc/c5t_testresult -I../inc -I../../../../../../inc/pch -I../../../../../../inc -I../../../../../../unx/inc -I../../../../../../unxfbsdx.pro/inc -I. -I/usr/obj/amd64-athlon64-8.0/usr/ports/editors/openoffice.org-3/work/OOO320 _m12/solver/320/unxfbsdx.pro/inc/stl -I/usr/obj/amd64-athlon64-8.0/usr/ports/editors/openoffice.org-3/work/OOO320 _m12/solver/320/unxfbsdx.pro/inc/external -I/usr/obj/amd64-athlon64-8.0/usr/ports/editors/openoffice.org-3/work/OOO320 _m12/solver/320/unxfbsdx.pro/inc -I/usr/obj/amd64-athlon64-8.0/usr/ports/editors/openoffice.org-3/work/OOO320 _m12/solenv/unxfbsdx/inc -I/usr/obj/amd64-athlon64-8.0/usr/ports/editors/openoffice.org-3/work/OOO320 _m12/solenv/inc -I/usr/obj/amd64-athlon64-8.0/usr/ports/editors/openoffice.org-3/work/OOO320 _m12/res -I/usr/obj/amd64-athlon64-8.0/usr/ports/editors/openoffice.org-3/work/OOO320 _m12/solver/320/unxfbsdx.pro/inc/stl -I/usr/obj/amd64-athlon64-8.0/usr/ports/editors/openoffice.org-3/work/OOO320 _m12/solenv/inc/Xp31 -I/usr/local/diablo-jdk1.6.0/include -I/usr/local/diablo-jdk1.6.0/include/freebsd -I/usr/local/diablo-jdk1.6.0/include/bsd -I/usr/local/diablo-jdk1.6.0/include/linux -I/usr/local/diablo-jdk1.6.0/include/native_threads/include -I/usr/local/include -I/usr/obj/amd64-athlon64-8.0/usr/ports/editors/openoffice.org-3/work/OOO320 _m12/solver/320/unxfbsdx.pro/inc/offuh -I../../include -I../../../../../../res -I. -pipe -fvisibility-inlines-hidden -g1 -Wall -Wextra -Wendif-labels -Wshadow -Wno-ctor-dtor-privacy -Wno-non-virtual-dtor -fpic -DFREEBSD -DUNX -DVCL -DGCC -DC341 -DX86_64 -DX86_64 -D_PTHREADS -D_REENTRANT -DNEW_SOLAR -D_USE_NAMESPACE=1 -DSTLPORT_VERSION=450 -DHAVE_GCC_VISIBILITY_FEATURE -D__DMAKE -DUNIX -DCPPU_ENV=gcc3 -DGXX_INCLUDE_PATH=/usr/include/c++/4.2 -DSUPD=320 -DPRODUCT -DNDEBUG -DPRODUCT_FULL -DOSL_DEBUG_LEVEL=0 -DOPTIMIZE -DCUI -DSOLAR_JAVA -DSHAREDLIB -D_DLL_ -fexceptions -fno-enforce-eh-specs -DEXCEPTIONS_ON -o ../../../../../../unxfbsdx.pro/slo/TestResult.o /usr/obj/amd64-athlon64-8.0/usr/ports/editors/openoffice.org-3/work/OOO320_m 12/cppunit/unxfbsdx.pro/misc/build/cppunit-1.8.0/src/result/TestResult.cpp In file included from /usr/obj/amd64-athlon64-8.0/usr/ports/editors/openoffice.org-3/work/OOO320_m 12/cppunit/unxfbsdx.pro/misc/build/cppunit-1.8.0/src/result/TestResult.cpp:4 : ../../include/cppunit/result/TestResult.h:72: error: 'ErrorType' has not been declared ../../include/cppunit/result/TestResult.h:72: error: expected ',' or '...' before 'eType' /usr/obj/amd64-athlon64-8.0/usr/ports/editors/openoffice.org-3/work/OOO320_m 12/cppunit/unxfbsdx.pro/misc/build/cppunit-1.8.0/src/result/TestResult.cpp:4 6: error: 'ErrorType' has not been declared /usr/obj/amd64-athlon64-8.0/usr/ports/editors/openoffice.org-3/work/OOO320_m 12/cppunit/unxfbsdx.pro/misc/build/cppunit-1.8.0/src/result/TestResult.cpp:4 6: error: expected ',' or '...' before '_eType' /usr/obj/amd64-athlon64-8.0/usr/ports/editors/openoffice.org-3/work/OOO320_m 12/cppunit/unxfbsdx.pro/misc/build/cppunit-1.8.0/src/result/TestResult.cpp: In member function 'virtual void CppUnit::TestResult::addError(CppUnit::Test*, CppUnit::Exception*, int)': /usr/obj/amd64-athlon64-8.0/usr/ports/editors/openoffice.org-3/work/OOO320_m 12/cppunit/unxfbsdx.pro/misc/build/cppunit-1.8.0/src/result/TestResult.cpp:4 8: error: '_eType' was not declared in this scope /usr/obj/amd64-athlon64-8.0/usr/ports/editors/openoffice.org-3/work/OOO320_m 12/cppunit/unxfbsdx.pro/misc/build/cppunit-1.8.0/src/result/TestResult.cpp: At global scope: /usr/obj/amd64-athlon64-8.0/usr/ports/editors/openoffice.org-3/work/OOO320_m 12/cppunit/unxfbsdx.pro/misc/build/cppunit-1.8.0/src/result/TestResult.cpp:4 6: warning: unused parameter 'num' /usr/obj/amd64-athlon64-8.0/usr/ports/editors/openoffice.org-3/work/OOO320_m 12/cppunit/unxfbsdx.pro/misc/build/cppunit-1.8.0/src/result/TestResult.cpp: In member function 'virtual void CppUnit::TestResult::addFailure(CppUnit::Test*, CppUnit::Exception*)': /usr/obj/amd64-athlon64-8.0/usr/ports/editors/openoffice.org-3/work/OOO320_m 12/cppunit/unxfbsdx.pro/misc/build/cppunit-1.8.0/src/result/TestResult.cpp:5 9: error: 'ErrorType' has not been declared dmake: Error code 1, while making '../../../../../../unxfbsdx.pro/slo/TestResult.obj' dmake: Error code 255, while making 'target' dmake: Error code 255, while making './unxfbsdx.pro/misc/build/so_built_so_cppunit' How can this be fixed? Remove (pkg_delete -d -f cppunit-1.\*) and restart your build with a make from /usr/ports/editors/openoffice-3/ and it should continue in the same place it left off. In case it does not start from the same place
portmaster v2.20 + request for (continue) feature improvement.
Dear Doug, ;) It has crossed my mind through a couple upgrades the idea to implement a way for portmaster to continue a upgrade if the package set that is being upgraded have no dependencies on per say a package set that previously failed to upgrade. Please correct me if I am wrong but when the recent ports update that happened with png- I also had other ports that were out of date that needed upgrades that did not depend on png- or one of the packages that depended on something that depended png-. When one of the packages that depended on png- failed, portmaster then terminated leaving me to either specify package by package till the png- dependents were fixed or provide a manual list of ports I knew could be upgraded without failing. Do you think it would be practical to build per say an array of packages that should be upgraded together that would result in portmaster to be able to continue with ports that it knows won't come back to a port that failed ? For instance mysql- needed to be upgraded but had no other dependencies that lead back to a port that depended on png-. This left my machine in a complete idle state while I was hoping! to use build time while I was not at the machine so actual usage time would not be affected by any type of load. Crossing fingers, Sincerely yours, Thanks in advance, ;) -- jhell ___ 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
Unresolvable link(s) found in: /usr/local/lib/firefox3/
After recompiling all png depends I ran libchk, just to be shure. [r...@dragon /usr/ports]# libchk Will look into: /bin /lib /sbin /usr/bin /usr/games /usr/lib /usr/libexec /usr/local/bin /usr/local/kde4/lib /usr/local/lib /usr/local/libexec /usr/local/sbin /usr/sbin Unresolvable link(s) found in: /usr/local/lib/firefox3/components/libbrowsercomps.so libxul.so libxpcom.so Unresolvable link(s) found in: /usr/local/lib/firefox3/components/libbrowserdirprovider.so libxpcom.so Unresolvable link(s) found in: /usr/local/lib/firefox3/components/libimgicon.so libxpcom.so Unresolvable link(s) found in: /usr/local/lib/firefox3/plugins/libnullplugin.so libxul.so libxpcom.so Unreferenced library: /usr/lib/libform.so.4 [snip rest of unreferenced libs] FF runs fine. So, what are these broken libs? Not used by FF? ___ 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: Unresolvable link(s) found in: /usr/local/lib/firefox3/
on 31/03/2010 18:49 Henk van Oers said the following: After recompiling all png depends I ran libchk, just to be shure. [r...@dragon /usr/ports]# libchk Will look into: /bin /lib /sbin /usr/bin /usr/games /usr/lib /usr/libexec /usr/local/bin /usr/local/kde4/lib /usr/local/lib /usr/local/libexec /usr/local/sbin /usr/sbin Unresolvable link(s) found in: /usr/local/lib/firefox3/components/libbrowsercomps.so libxul.so libxpcom.so Unresolvable link(s) found in: /usr/local/lib/firefox3/components/libbrowserdirprovider.so libxpcom.so Unresolvable link(s) found in: /usr/local/lib/firefox3/components/libimgicon.so libxpcom.so Unresolvable link(s) found in: /usr/local/lib/firefox3/plugins/libnullplugin.so libxul.so libxpcom.so Unreferenced library: /usr/lib/libform.so.4 [snip rest of unreferenced libs] FF runs fine. Short answer - why do you care then? :-) So, what are these broken libs? Not used by FF? Those libraries are used and are found at run-time. -- Andriy Gapon ___ 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: Old ports bugs analyzis
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 31/03/2010 17:45:21, Ulrich Spörlein wrote: This has been floated around in this thread as fat packages, where you basically have the build cluster build a port, eg. three ways. In our case vim-lite (no x11), vim (gui) and vim-full (perl, cscope, ...). These three runs can than be combined into one fat package. As they share documentation and other share/ data, only the binaries/libraries need to be stored 3x in the package and compression should nullify the .tbz growth further. The term 'fat packages' suggests to me packages that incorporate binaries for several different CPU architectures -- there's precedent for that usage in MacOS X[*]. 'Polymorphic' would be a better term IMHO - -- pkgs could be both fat and polymorphic if desired. Cheers, Matthew [*] Whether fat-ness is managed by introducing a port of the MacOS lipo(1) application and modifying the way applications are run and that dynamic linking works to support multi-architecture binaries is the way to go, or whether having architecture specific parts of a pkg that are installed selectively would be better is no doubt something that will provide many hours of enjoyable debate. - -- Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate Kent, CT11 9PW -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.14 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkuziwYACgkQ8Mjk52CukIwMjACcC4wc4GcW4eERSpYTwoGEpzjy aGAAn1B/9A7vMy8LgeNhBkO9rYqQUafa =c6+5 -END PGP SIGNATURE- ___ 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: x11-toolkits/qt4-gui fails with zlib.h off64_t
On Tue, Mar 30, 2010 at 11:14 PM, Doug Barton do...@freebsd.org wrote: I can now confirm that with Xin's patch for zlib that all the qt4 stuff builds, I updated virtualbox, and that builds and runs just fine. Just a quick update: zlib has been updated to 1.2.4.1 (beta) on -HEAD. I have tried qt4-gui and it seems the compilation issue has gone. Note that port maintainers are still encouraged to have upstream fix the _LARGEFILE64_SOURCE issue. Cheers, -- Xin LI delp...@delphij.net http://www.delphij.net ___ 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: Unresolvable link(s) found in: /usr/local/lib/firefox3/
On 31/03/2010 17:49, Henk van Oers wrote: After recompiling all png depends I ran libchk, just to be shure. ... Unresolvable link(s) found in: /usr/local/lib/firefox3/components/libbrowsercomps.so libxul.so libxpcom.so Those are false positives, the libraries belong to firefox and are even part of the same package. You can try the pkg_libchk command coming with sysutils/bsdadminscripts, which takes great care to avoid false positives. Regards -- A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? ___ 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: www/nginx and www/rubygem-passenger
Hi, I just wanted to report that: www/rubygem-passenger is version 2.2.9 www/nginx 0.7.65 with PASSENGER_MODULE=on has passenger at 2.2.11 When I installed both they worked together, but I didn't think it was safe to run them together. The server headers showed X-Powered-By: as 2.2.9 whereas the Server: was 2.2.11. The problem seems to be that the www/nginx doesn't install passenger like I'm guessing it should? I didn't think I would have to install www/rubygem-passenger as well? But maybe I'm wrong. For some reason, I couldn't install by using: gem install passenger It would just sit idle for ages. Anyway, I tweaked the www/rubygem-passenger port to 2.2.11 and installed it that way. It all seems to be working now. Could the maintainer update www/rubygem-passenger to 2.2.11? Thanks. -- Regards, Brad Rushworth Managing Director BitBot Software Pty Ltd Phone: 1300 BIT BOT Fax: 02 4017 0682 Email: b...@bitbot.com.au Web: www.bitbot.com.au 265 King St, Newcastle, NSW 2300 ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: FreeBSD Ports: www/nginx and www/rubygem-passenger
Hi, Brad. On Thu, Apr 01, 2010 at 12:51:51PM +1100, Brad Rushworth wrote: I just wanted to report that: www/rubygem-passenger is version 2.2.9 www/nginx 0.7.65 with PASSENGER_MODULE=on has passenger at 2.2.11 When I installed both they worked together, but I didn't think it was safe to run them together. The server headers showed X-Powered-By: as 2.2.9 whereas the Server: was 2.2.11. The problem seems to be that the www/nginx doesn't install passenger like I'm guessing it should? 1. www/nginx (as well as www/nginx-devel) doesn't install passenger 2. www/nginx (as well as www/nginx-devel) compiles with support for passenger, because no other way (i.e. binary modules support) to work with third-party modules. I didn't think I would have to install www/rubygem-passenger as well? But maybe I'm wrong. You should install www/rubygem-passenger (for passenger) and web-server (www/nginx) for passenger support. For some reason, I couldn't install by using: gem install passenger It would just sit idle for ages. Anyway, I tweaked the www/rubygem-passenger port to 2.2.11 and installed it that way. Correct, patch for upgrade from 2.2.9 to 2.2.11 is trivial. It all seems to be working now. OK. Could the maintainer update www/rubygem-passenger to 2.2.11? Jacob, could you please send-pr with patch, Cc: to me, I'll commit changes ASAP. -- Sergey A. Osokin o...@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
