FreeBSD ports you maintain which are out of date
Dear port maintainer, The portscout new distfile checker has detected that one or more of your ports appears to be out of date. Please take the opportunity to check each of the ports listed below, and if possible and appropriate, submit/commit an update. If any ports have already been updated, you can safely ignore the entry. You will not be e-mailed again for any of the port/version combinations below. Full details can be found at the following URL: http://portscout.freebsd.org/po...@freebsd.org.html Port| Current version | New version +-+ devel/scons | 2.4.1 | 2.5.0 +-+ math/fxt| 2016.02.27 | 2016.04.09 +-+ If any of the above results are invalid, please check the following page for details on how to improve portscout's detection and selection of distfiles on a per-port basis: http://portscout.freebsd.org/info/portscout-portconfig.txt Thanks. ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: impossible to compile firefox when WRKDIRPREFIX is used
Erich Dollansky writes: >> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=206980 [...] > Before I have been able to built firefox without WRKDIRPREFIX in the > same shell. The same error happens in a fresh shell. If it matters, I > believe that 37 was the last version I could built with WRKDIRPREFIX. Did you actually read that bug? It builds fine with WRKDIRPREFIX defined or pkg-fallout@ would complain as poudriere relies on WRKDIRPREFIX working correctly. So, the issue is only with symlinks and the most egregious example is a historic quirk FreeBSD cannot get rid of. ;\ I may need to file a bug upstream but it's a low priority because why one would want a symlink for MOZ_OBJDIR if they can override it via environment. signature.asc Description: PGP signature
'porting' AMD compiler suite
I downloaded the AMD Open64 compiler suite & am attempting to build it
to compile some in-house code under FreeBSD. I unpacked the tarball &
began following directions in the INSTALL file, which I attach. The
configure process completed OK, but created a Makefile w/ what seems to
be a bunch of linuxisms in conditionals to allow compilation for
different architectures, see attached orig-Makefile. I read the man page
for make & attempted to convert these to FreeBSD legal text & tried my
'make all' again. It failed w/ different & somewhat obscure error
message, so I tried again w/ 'make -vvv -d all' & got the attached
output in 'LIST', see attached. The compiler is not necessarily known to
compile under FreeBSD, so I may be whiffing here, but I think this may
just be a bit of pilot error using the GNU utilities. I am stumped for
now, any clues appreciated. I also attach my 'fixed' Makefile. The LIST
file has info on make version & other stuff.
[root@devbox, obj, 5:02:37pm] 937 % uname -a
FreeBSD devbox 9.3-RELEASE-p33 FreeBSD 9.3-RELEASE-p33 #0: Wed Jan 13
17:55:39 UTC 2016
r...@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64
[root@devbox, obj, 5:06:26pm] 938 % which make
/usr/bin/make
[root@devbox, obj, 5:06:31pm] 939 %
Again, I am stumped for now, any help appreciated. TIA * have a good one.
--
William A. Mahaffey III
--
"The M1 Garand is without doubt the finest implement of war
ever devised by man."
-- Gen. George S. Patton Jr.
Installing Open64
=
Introduction
This document explains how to compile and install x86 Open64 compiler from
source on an x86-64 based system.For simplicity, we describe the steps
that we used to build the x86 Open64 4.5.2.1 binary packages available
on http://developer.amd.com/cpu/open64.
Open64 and external package dependency
--
Minimal external packages/tools dependency for using open64 compiler
glibc - release and devel packages supporting 64 bit and 32 bit ISA
libgcc - 32 bit, 64 bit packages
libstdc++ - 32 bit, 64 bit packages
Minimal external packages/tools dependency for building open64 compiler from
source
gcc,g++,gfortran
bison
flex
glibc-devel.x86_64
glibc-devel.i686
libgcc.i686
To fully leverage the AMD Opteron Family 15h processor("Piledriver"core)
features use binutils-2.21.51.0.6 or above.Newer OS versions like
SLES 11 SP2 and RHEL 6.3 come with GLIBC and Binutils which have support
for AMD Opteron Family 15h processor("Piledriver"core).
We used 64-bit SUSE Linux Enterprise Server 11 with SP1 and with required
binutils to build the compiler for AMD Opteron Family 15h processor
("Piledriver" core).Besides, we used 64-bit SUSE Linux Enterprise Server 10
with SP2 to build the compiler for systems that does not comply to the above
mentioned Binutils version.
Note:
If a open64 build from source attempted without the above recommended
binutils on a machine with AMD Opteron Family 15h processor
("Piledriver"core) then the compiler build may not get completed
as expected.
Build open64 from source
Although the x86 Open64 compiler suite can be built on 32-bit or 64-bit
Linux systems, we always build on a 64-bit Linux system where both 32-bit
and 64-bit code generation can be tested.
By default, on x86_64 machines, the compiler will be built in 64 bit
mode and libraries will be built in 32 and 64 bit modes to support
compilation in either mode
By default, the build process will use GCC to build most compiler
components. We used GCC 4.1.2 as provided with SLES 10 SP2 and GCC 4.3.4 as
provided with SLES 11 SP1.
Following the below simple steps helps in building open64 for AMD x86_64
- Unpack the source (assume that the source package has been extracted as
x86_open64-4.5.2.1-1)
tar xjvf x86_open64-4.5.2.1-1.src.tar.bz2
- Create object directory at the same level where src has been extracted
mkdir obj
cd obj
- Configure stage
A compiler built on either x86-64 or x86 machine will target both
architectures.
By default the compiler will get built for x86_64-unknown-linux-gnu, it can
also
be forced using the below option
--build=x86_64-unknown-linux-gnu
To build a compiler on an x86-64 machine that is compiled with the x86 ISA
(that is, compiled with the -m32 option), specify the following configuration
option:
--build=i686-unknown-linux-gnu
Select one of the below step based on your need/environment for building a
x84_64 compiler
* For all binutils
../x86_open64-4.5.2.1-1/configure --build=x86_64-unknown-linux-gnu \
--disable-host_bdver1-support [--prefix=]
Re: 'porting' AMD compiler suite
On 2016-Apr-10 17:09:04 -0453, "William A. Mahaffey III" wrote: >configure process completed OK, but created a Makefile w/ what seems to >be a bunch of linuxisms in conditionals to allow compilation for >different architectures, see attached orig-Makefile. Have you tried using gmake, rather than the base make? -- Peter Jeremy signature.asc Description: PGP signature
Re: 'porting' AMD compiler suite
On 04/10/16 18:09, Peter Jeremy wrote: On 2016-Apr-10 17:09:04 -0453, "William A. Mahaffey III" wrote: configure process completed OK, but created a Makefile w/ what seems to be a bunch of linuxisms in conditionals to allow compilation for different architectures, see attached orig-Makefile. Have you tried using gmake, rather than the base make? H No, I didn't :-/ Did I mention pilot error ? I thought the system make was a version of gmake, but apparently not, right ? Thanks, I'll try that & see how it goes -- William A. Mahaffey III -- "The M1 Garand is without doubt the finest implement of war ever devised by man." -- Gen. George S. Patton Jr. ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: impossible to compile firefox when WRKDIRPREFIX is used
Hi, On Sun, 10 Apr 2016 05:55:30 +0200 Jan Beich wrote: > Erich Dollansky writes: > > >> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=206980 > [...] > > Before I have been able to built firefox without WRKDIRPREFIX in the > > same shell. The same error happens in a fresh shell. If it matters, > > I believe that 37 was the last version I could built with > > WRKDIRPREFIX. > > Did you actually read that bug? It builds fine with WRKDIRPREFIX I stumbled over this: PACKAGES=/home/david/portbuildpkg > defined or pkg-fallout@ would complain as poudriere relies on > WRKDIRPREFIX working correctly. So, the issue is only with symlinks > and the most egregious example is a historic quirk FreeBSD cannot get > rid of. ;\ > > I may need to file a bug upstream but it's a low priority because why > one would want a symlink for MOZ_OBJDIR if they can override it via > environment. Why did it work earlier? Erich ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: 'porting' AMD compiler suite
On 04/10/16 18:09, Peter Jeremy wrote: On 2016-Apr-10 17:09:04 -0453, "William A. Mahaffey III" wrote: configure process completed OK, but created a Makefile w/ what seems to be a bunch of linuxisms in conditionals to allow compilation for different architectures, see attached orig-Makefile. Have you tried using gmake, rather than the base make? OK, I tried gmake & got the attached, lotta '#include malloc.h' all over the place, I'll have to handle that file-by-file :-/ -- William A. Mahaffey III -- "The M1 Garand is without doubt the finest implement of war ever devised by man." -- Gen. George S. Patton Jr. Beginning background gmake all Initiated at 06:19:22 PM MCDT on Sunday, April 10, 2016 gmake first gmake[1]: Entering directory '/usr/src/contrib/obj' gmake[1]: Nothing to be done for 'first'. gmake[1]: Leaving directory '/usr/src/contrib/obj' gmake phony_targets gmake[1]: Entering directory '/usr/src/contrib/obj' gmake -C osprey/targdir/include gmake[2]: Entering directory '/usr/src/contrib/obj/osprey/targdir/include' echo '#ifndef __pathscale_defs_h' > pathscale_defs.h echo '#define __pathscale_defs_h' >> pathscale_defs.h echo '#define OPEN64_NAME_PREFIX "open"' >> pathscale_defs.h echo '#define OPEN64_MAJOR_VERSION_NUM 4' >> pathscale_defs.h echo '#define OPEN64_MINOR_VERSION_NUM 5' >> pathscale_defs.h echo '#define OPEN64_MAJOR_VERSION "4"' >> pathscale_defs.h echo '#define OPEN64_MINOR_VERSION "5"' >> pathscale_defs.h echo '#define OPEN64_FULL_VERSION "4.5.2.1"' >> pathscale_defs.h echo '#define OPEN64_GCC_VERSION "3.3.1"' >> pathscale_defs.h echo '#define OPEN64_GCC40_VERSION "4.0.2"' >> pathscale_defs.h echo '#define OPEN64_GCC42_VERSION "4.2.0"' >> pathscale_defs.h echo '#define OPEN64_INSTALL_PREFIX "/usr"' >> pathscale_defs.h echo '#define OPEN64_TARGET ""' >> pathscale_defs.h echo '#define OPEN64_PATCH_LEVEL "2.1"' >> pathscale_defs.h echo "#endif" >> pathscale_defs.h Making sys Making cmplrs Making libelf test: -a: unexpected operator test: -a: unexpected operator test: -a: unexpected operator test: -a: unexpected operator gmake[2]: Leaving directory '/usr/src/contrib/obj/osprey/targdir/include' gmake -C osprey/targdir/driver gmake[2]: Entering directory '/usr/src/contrib/obj/osprey/targdir/driver' hg: not found gmake first gmake[3]: Entering directory '/usr/src/contrib/obj/osprey/targdir/driver' hg: not found gmake[3]: Nothing to be done for 'first'. gmake[3]: Leaving directory '/usr/src/contrib/obj/osprey/targdir/driver' gmake driver gmake[3]: Entering directory '/usr/src/contrib/obj/osprey/targdir/driver' hg: not found C /usr/src/contrib/obj/osprey/targdir/driver/../../../../x86_open64-4.5.2.1-1/osprey/driver/errors.c C /usr/src/contrib/obj/osprey/targdir/driver/../../../../x86_open64-4.5.2.1-1/osprey/driver/file_utils.c C /usr/src/contrib/obj/osprey/targdir/driver/../../../../x86_open64-4.5.2.1-1/osprey/driver/lang_defs.c C /usr/src/contrib/obj/osprey/targdir/driver/../../../../x86_open64-4.5.2.1-1/osprey/driver/string_utils.c In file included from ../../../../x86_open64-4.5.2.1-1/osprey/driver/string_utils.c:43: /usr/include/malloc.h:3:2: error: #error " has been replaced by " /usr/src/contrib/obj/osprey/../../x86_open64-4.5.2.1-1/osprey/linux/make/gcommonrules:148: recipe for target 'string_utils.o' failed gmake[3]: *** [string_utils.o] Error 1 gmake[3]: Leaving directory '/usr/src/contrib/obj/osprey/targdir/driver' ../../../../x86_open64-4.5.2.1-1/osprey/driver/Makefile.gbase:225: recipe for target 'default' failed gmake[2]: *** [default] Error 2 gmake[2]: Leaving directory '/usr/src/contrib/obj/osprey/targdir/driver' Makefile:229: recipe for target 'driver' failed gmake[1]: *** [driver] Error 2 gmake[1]: Leaving directory '/usr/src/contrib/obj' Makefile:340: recipe for target 'build' failed gmake: *** [build] Error 2 0.52 real 0.29 user 0.23 sys Completed at 06:19:23 PM MCDT on Sunday, April 10, 2016 ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: 'porting' AMD compiler suite
On Sun, Apr 10, 2016 at 4:10 PM, William A. Mahaffey III wrote: > On 04/10/16 18:09, Peter Jeremy wrote: > >> On 2016-Apr-10 17:09:04 -0453, "William A. Mahaffey III" >> wrote: >> >>> configure process completed OK, but created a Makefile w/ what seems to >>> be a bunch of linuxisms in conditionals to allow compilation for >>> different architectures, see attached orig-Makefile. >>> >> Have you tried using gmake, rather than the base make? >> >> > > H No, I didn't :-/ Did I mention pilot error ? I thought the > system make was a version of gmake, but apparently not, right ? Thanks, > I'll try that & see how it goes > > -- > > William A. Mahaffey III > > -- > > "The M1 Garand is without doubt the finest implement of war > ever devised by man." >-- Gen. George S. Patton Jr. > > ___ > > FreeBSD make and GNU make are different species ( means not compatible ) . If you compare building of GCC in FreeBSD and Linux , you may model building of Open64 in FreeBSD with respect to building in Linux . If I were you , I would not work on Open64 because GCC is much better than Open64 with respect to my opinion . In Linux , I have checked Open64 for using it , but I have abandoned that idea , because at least it does not have 128 bit floating point numbers ( if it is not included yet ) . It may be said that it is abandoned : https://en.wikipedia.org/wiki/Open64 http://developer.amd.com/tools-and-sdks/cpu-development/x86-open64-compiler-suite/ https://sourceforge.net/projects/open64/ https://sourceforge.net/projects/open64/files/open64/ https://sourceforge.net/projects/open64/files/open64/Open64-5.0/ http://www.open64.net/ Mehmet Erol Sanliturk ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: 'porting' AMD compiler suite
On Sun, Apr 10, 2016 at 4:50 PM, William A. Mahaffey III wrote: > On 04/10/16 18:09, Peter Jeremy wrote: > >> On 2016-Apr-10 17:09:04 -0453, "William A. Mahaffey III" >> wrote: >> >>> configure process completed OK, but created a Makefile w/ what seems to >>> be a bunch of linuxisms in conditionals to allow compilation for >>> different architectures, see attached orig-Makefile. >>> >> Have you tried using gmake, rather than the base make? >> >> > > OK, I tried gmake & got the attached, lotta '#include malloc.h' all over > the place, I'll have to handle that file-by-file :-/ > > -- > > William A. Mahaffey III > > -- > > "The M1 Garand is without doubt the finest implement of war > ever devised by man." >-- Gen. George S. Patton Jr. > > > ___ > > Important problem here is the following : In make files , there are other references to "make" commands , means , even you started from gmake , at the next make invocation , it will invoke the FreeBSD make . Therefore , you need to use a jail and replace the FreeBSD make with gmake , or , by traversing all of the make files , replace "make" invocations by "gmake" . Mehmet Erol Sanliturk ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: 'porting' AMD compiler suite
On Sun, Apr 10, 2016 at 5:03 PM, Mehmet Erol Sanliturk < m.e.sanlit...@gmail.com> wrote: > On Sun, Apr 10, 2016 at 4:50 PM, William A. Mahaffey III > wrote: > > > On 04/10/16 18:09, Peter Jeremy wrote: > > > >> On 2016-Apr-10 17:09:04 -0453, "William A. Mahaffey III" < > w...@hiwaay.net> > >> wrote: > >> > >>> configure process completed OK, but created a Makefile w/ what seems to > >>> be a bunch of linuxisms in conditionals to allow compilation for > >>> different architectures, see attached orig-Makefile. > >>> > >> Have you tried using gmake, rather than the base make? > >> > >> > > > > OK, I tried gmake & got the attached, lotta '#include malloc.h' all over > > the place, I'll have to handle that file-by-file :-/ > > > > -- > > > > William A. Mahaffey III > > > > -- > > > > "The M1 Garand is without doubt the finest implement of war > > ever devised by man." > >-- Gen. George S. Patton Jr. > > > > > > ___ > > > > > > > Important problem here is the following : > > > In make files , there are other references to "make" commands , means , > even you started from gmake , at the next make invocation , it will invoke > the FreeBSD make . > > Therefore , you need to use a jail and replace the FreeBSD make with gmake > , or , by traversing all of the make files , replace "make" invocations by > "gmake" . > > > Mehmet Erol Sanliturk > Or just alias make to gmake in the build environment. -- Kevin Oberman, Part time kid herder and retired Network Engineer E-mail: rkober...@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: 'porting' AMD compiler suite
On 04/10/16 19:09, Mehmet Erol Sanliturk wrote: On Sun, Apr 10, 2016 at 4:50 PM, William A. Mahaffey III wrote: On 04/10/16 18:09, Peter Jeremy wrote: On 2016-Apr-10 17:09:04 -0453, "William A. Mahaffey III" wrote: configure process completed OK, but created a Makefile w/ what seems to be a bunch of linuxisms in conditionals to allow compilation for different architectures, see attached orig-Makefile. Have you tried using gmake, rather than the base make? OK, I tried gmake & got the attached, lotta '#include malloc.h' all over the place, I'll have to handle that file-by-file :-/ -- William A. Mahaffey III -- "The M1 Garand is without doubt the finest implement of war ever devised by man." -- Gen. George S. Patton Jr. ___ Important problem here is the following : In make files , there are other references to "make" commands , means , even you started from gmake , at the next make invocation , it will invoke the FreeBSD make . Therefore , you need to use a jail and replace the FreeBSD make with gmake , or , by traversing all of the make files , replace "make" invocations by "gmake" . Mehmet Erol Sanliturk ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org" Or set the (g)make variable 'MAKE' to gmake & let it propogate -- William A. Mahaffey III -- "The M1 Garand is without doubt the finest implement of war ever devised by man." -- Gen. George S. Patton Jr. ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: 'porting' AMD compiler suite
On 04/10/16 19:05, Mehmet Erol Sanliturk wrote: On Sun, Apr 10, 2016 at 4:10 PM, William A. Mahaffey III wrote: On 04/10/16 18:09, Peter Jeremy wrote: On 2016-Apr-10 17:09:04 -0453, "William A. Mahaffey III" wrote: configure process completed OK, but created a Makefile w/ what seems to be a bunch of linuxisms in conditionals to allow compilation for different architectures, see attached orig-Makefile. Have you tried using gmake, rather than the base make? H No, I didn't :-/ Did I mention pilot error ? I thought the system make was a version of gmake, but apparently not, right ? Thanks, I'll try that & see how it goes -- William A. Mahaffey III -- "The M1 Garand is without doubt the finest implement of war ever devised by man." -- Gen. George S. Patton Jr. ___ FreeBSD make and GNU make are different species ( means not compatible ) . If you compare building of GCC in FreeBSD and Linux , you may model building of Open64 in FreeBSD with respect to building in Linux . If I were you , I would not work on Open64 because GCC is much better than Open64 with respect to my opinion . In Linux , I have checked Open64 for using it , but I have abandoned that idea , because at least it does not have 128 bit floating point numbers ( if it is not included yet ) . I have tried GCC & found it wanting, that's why I am looking for an alternative It may be said that it is abandoned : https://en.wikipedia.org/wiki/Open64 http://developer.amd.com/tools-and-sdks/cpu-development/x86-open64-compiler-suite/ https://sourceforge.net/projects/open64/ https://sourceforge.net/projects/open64/files/open64/ https://sourceforge.net/projects/open64/files/open64/Open64-5.0/ http://www.open64.net/ Mehmet Erol Sanliturk ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org" I *think* AMD is still plodding along w/ their version, not certain of that -- William A. Mahaffey III -- "The M1 Garand is without doubt the finest implement of war ever devised by man." -- Gen. George S. Patton Jr. ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Problems with item delivery, n.0000118042
Dear Customer, Your parcel has arrived at April 08. Courier was unable to deliver the parcel to you. Please, open email attachment to print shipment label. Yours trully, Patrick Parsons, FedEx Operation Manager. ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: 'porting' AMD compiler suite
On Sun, 10 Apr 2016, William A. Mahaffey III wrote: Or set the (g)make variable 'MAKE' to gmake & let it propogate What you are doing is, in effect, creating a port. If you create a real port, there are numerous tools to deal with just this sort of problem, like USES=gmake. The Porter's Handbook describes the whole process of creating a port: https://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/ ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: 'porting' AMD compiler suite
On 04/10/16 20:22, Warren Block wrote: On Sun, 10 Apr 2016, William A. Mahaffey III wrote: Or set the (g)make variable 'MAKE' to gmake & let it propogate What you are doing is, in effect, creating a port. If you create a real port, there are numerous tools to deal with just this sort of problem, like USES=gmake. The Porter's Handbook describes the whole process of creating a port: https://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/ ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org" I wasn't planning to go that far to start with, but that could change. I am having to edit a largish # of the source files to comment out '#include ' lines, is there a way to automate that for port/pkg maintenance ? I haven't reviewed the porters-handbook (yet), but I have hit that snag to start with -- William A. Mahaffey III -- "The M1 Garand is without doubt the finest implement of war ever devised by man." -- Gen. George S. Patton Jr. ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
