Re: devel/llvm37 fails on Intrinsics.gen

[Matthew Pounsett]

On 30 August 2016 at 11:25, Walter Schwarzenfeld 
wrote:

> There is a PR:
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=212212
> ___
>

Thanks, I'll watch for updates on that.


> 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"
>
___
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"

devel/llvm37 fails on Intrinsics.gen

[Matthew Pounsett]

I'm building ports using poudriere 3.1.14_2 on FreeBSD 9.3-RELEASE-p43.
 llvm37 3.7.1_3 is failing for me at the following point:

[136/3187] Building Intrinsics.gen...
FAILED: include/llvm/IR/Intrinsics.gen.tmp
cd /wrkdirs/usr/ports/devel/llvm37/work/.build/include/llvm/IR &&
/wrkdirs/usr/ports/devel/llvm37/work/.build/bin/llvm-tblgen -gen-intrinsic
-I /wrkdirs/usr/ports/devel/llvm37/work/llvm-3.7.1.src/include/llvm/IR -I
/wrkdirs/usr/ports/devel/llvm37/work/llvm-3.7.1.src/lib/Target -I
/wrkdirs/usr/ports/devel/llvm37/work/llvm-3.7.1.src/include
/wrkdirs/usr/ports/devel/llvm37/work/llvm-3.7.1.src/include/llvm/IR/Intrinsics.td
-o /wrkdirs/usr/ports/devel/llvm37/work/.build/include/
llvm/IR/Intrinsics.gen.tmp
llvm-tblgen: Unknown command line argument '-gen-intrinsic'.  Try:
'/wrkdirs/usr/ports/devel/llvm37/work/.build/bin/llvm-tblgen -help'
llvm-tblgen: Did you mean '-print-options'?
ninja: build stopped: subcommand failed.
*** [do-build] Error code 1

I first built it with llvm37 listed in ALLOW_MAKE_JOBS_PACKAGES ... that
failed, so I removed it and retried.  The above error is what I got on the
second build.  I've updated my ports tree in case it was a temporary bug in
the port, but that hasn't fixed the problem.

Does this look familiar to anyone?
___
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: WANT_PHP_WEB is just a synonym for WANT_PHP_CGI in automated build environments

[Matthew Pounsett]

On Aug 4, 2014, at 23:15 , Melvyn Sopacua mel...@magemana.nl wrote:

 So, there is no php-cgi or fpm, but www/mod_php5 is not in phpMyAdmin's
 dependencies, which means WANT_PHP_WEB is not satisfied, yet no errors
 are generated.

While it looks like that’s the expected behaviour right now, I don’t agree that 
it’s good behaviour.  What if someone wants phpMyAdmin using mod_php5 but also 
wants the CGI and/or FPM versions installed for other reasons?   This is using 
the absence of guidance as guidance, which could work some of the time but 
isn’t as desirable as being able to give specific guidance.

 
 Filed as: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192388

And closed almost as fast as it was opened.  Since the whole point of 
WANT_PHP_{WEB,CGI,MOD} is for setting dependencies, I can’t see how it can be 
claimed that this “works as intended” when dependencies aren’t properly set.


___
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: WANT_PHP_WEB is just a synonym for WANT_PHP_CGI in automated build environments

[Matthew Pounsett]

On Aug 4, 2014, at 09:05 , Alex Dupre a...@freebsd.org wrote:

 Matthew Pounsett ha scritto:
 
 It looks to me like the rules that WANT_PHP_WEB uses to decide whether to 
 build the CGI or module version of PHP will always choose the CGI version 
 unless the module is already installed.  If this is true, it means that in 
 automated build environments (e.g. tinderbox) – where *only* the direct 
 dependencies of a port are installed at build time – there isn’t any way to 
 tell WANT_PHP_WEB to install the module.  This effectively makes 
 WANT_PHP_WEB a synonym for WANT_PHP_CGI in these environments.
 
 Have I missed something, or is this a significant flaw in the design of the 
 WANT_PHP_{WEB,CGI,MOD} knobs?
 
 You missed the fact that you can install the php module as a separate
 port/package together with the core php package. Not only, mod_php port
 requires core php port, that is the one containing the cgi version. So
 there isn't any problem with tinderbox/poudriere.

I can build it, sure .. but it’s the dependencies I’m trying to get fixed up.  
If I can’t tell the ports tree that a WANT_PHP_WEB port should require 
mod_php5, then when I go to install the package that gets built for that port 
it’s not going to have the requirement in its meta data, and mod_php5 won’t be 
installed as a result.

Yes, I can then also go manually install mod_php5, but that’s not really the 
point of dependencies, is 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: WANT_PHP_WEB is just a synonym for WANT_PHP_CGI in automated build environments

[Matthew Pounsett]

On Aug 3, 2014, at 12:29 , Melvyn Sopacua mel...@magemana.nl wrote:

 Hi Matthew,
 
 On Sun, 3 Aug 2014, Matthew Pounsett wrote:
 
 On Aug 3, 2014, at 02:07 , Melvyn Sopacua mel...@magemana.nl wrote:
 
 For automated builds use the OPTIONS framework. Tinderbox can handle
 that just fine.
 
 Right, and I’m speaking from the perspective of the admin building the
 port, not the maintainer.  The maintainer can set that the port will
 work with either .. but in an automated build environment it looks
 like there is no knob for the administrator to tell the ports system
 which to use.
 
 Unless that changed in recent years, you can have Tinderbox mount your
 options database in /var/db/ports into the build jail. So you can do one
 configure run and set it.

Do one configure run to set what?  The whole point of this thread is that there 
is no configure option to tell a port that uses WANT_PHP_WEB to require 
mod_php5.  

Besides which, tinderbox has one options database per build.  It doesn’t use 
the options database in /var/db/ports.

 
 A second possibility is to simply add www/mod_php5 to ports to be built,
 since it's no longer part of lang/php5. This won't work for the
 upstream-abandoned php 5.3.
 
 A third is to set php53_SET=APACHE in /etc/make.conf.

Manually telling the system to build a package will get it built, but doesn’t 
solve the dependency problem.  The whole point of dependencies is that when you 
install a port/package the things it requires will also get installed .. if a 
port that uses WANT_PHP_WEB can’t be told to require mod_php5, then the 
dependency doesn’t exist.  Again, we’re back to WANT_PHP_WEB being a synonym 
for WANT_PHP_CGI.

Your other suggestion seems to be that in order to get the php module to be a 
dependency of some other port I need to use an old version of php.. I’m not 
sure how seriously I should take that.


 Again.. unless I’m missing some knob that exists to give guidance to
 the ports system.   I’m familiar with the options framework, but I
 can’t find anything in bsd.php.mk that could be used to give guidance
 to the ports system that mod_php5 is desired when WANT_PHP_WEB is
 defined.
 
 WANT_PHP_WEB actually pulls in the apache module if php is installed
 only with the CLI or EMBED backend. See this bit:
 
 if defined(WANT_PHP_MOD) || (defined(WANT_PHP_WEB)  defined(PHP_VERSION)  
 ${PHP_SAPI:Mcgi} ==   ${PHP_SAPI:Mfpm} == )
 USE_APACHE_RUN= 22+
 .include ${PORTSDIR}/Mk/bsd.apache.mk
 RUN_DEPENDS+=   
 ${PHPBASE}/${APACHEMODDIR}/libphp5.so:${PORTSDIR}/${MOD_PHP_PORT}
 .endif

That’s not how I read that.  I’ve read this piece of code and it’s how I 
arrived at the conclusion that WANT_PHP_WEB is a synonym for WANT_PHP_CGI in 
automated build environments.  The above code seems to say that libphp5.so 
should only be set if WANT_PHP_MOD is set, OR if WANT_PHP_WEB is set AND PHP is 
installed AND the CGI and FPM options for the CGI module are unset. 

As far as I can tell, the only way you get an installed version of PHP without 
either the CGI or FPM options set is to install mod_php5.  That makes 
installing mod_php5 a prerequisite to making mod_php5 a dependency to any port 
that uses WANT_PHP_WEB.


___
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: WANT_PHP_WEB is just a synonym for WANT_PHP_CGI in automated build environments

[Matthew Pounsett]

On Aug 3, 2014, at 02:07 , Melvyn Sopacua mel...@magemana.nl wrote:

 
 I don't see the problem.
 If you want the mod_php module in your port set WANT_PHP_MOD.
 If you don't care which implementation it is as long as it can speak
 with a webserver, you set WANT_PHP_WEB.
 
 The WANT_PHP_WEB knob is for port maintainers that trust the
 system administrators that use the PHP software will know what suits
 them most.
 
 For automated builds use the OPTIONS framework. Tinderbox can handle
 that just fine.

Right, and I’m speaking from the perspective of the admin building the port, 
not the maintainer.  The maintainer can set that the port will work with either 
.. but in an automated build environment it looks like there is no knob for the 
administrator to tell the ports system which to use.  The ports system will 
default to the CGI port unless the module port is already built .. but an 
automated build environment will only build and install explicitly requested 
dependencies.  Thus, in an automated build environment, WANT_PHP_WEB means 
WANT_PHP_CGI.

Again.. unless I’m missing some knob that exists to give guidance to the ports 
system.   I’m familiar with the options framework, but I can’t find anything in 
bsd.php.mk that could be used to give guidance to the ports system that 
mod_php5 is desired when WANT_PHP_WEB is defined.


___
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

WANT_PHP_WEB is just a synonym for WANT_PHP_CGI in automated build environments

[Matthew Pounsett]

It looks to me like the rules that WANT_PHP_WEB uses to decide whether to build 
the CGI or module version of PHP will always choose the CGI version unless the 
module is already installed.  If this is true, it means that in automated build 
environments (e.g. tinderbox) – where *only* the direct dependencies of a port 
are installed at build time – there isn’t any way to tell WANT_PHP_WEB to 
install the module.  This effectively makes WANT_PHP_WEB a synonym for 
WANT_PHP_CGI in these environments.

Have I missed something, or is this a significant flaw in the design of the 
WANT_PHP_{WEB,CGI,MOD} knobs?  

It seems to me that this should be changed in one of three ways:
1) It should be possible to provide direction to WANT_PHP_WEB via some 
make.conf knob
2) WANT_PHP_WEB should be removed, and WANT_PHP_{CGI,MOD} should always be 
chosen using a radio selector at config time, or by setting in make.conf
3) WANT_PHP_WEB should cause a radio button selector to appear at port config 
time

(3) seems like the least desirable, since it leaves no way to provide direction 
in a batch mode build.  I think my preference would be for (2).

Does anyone have any other ideas for how to improve this?  Or any pointers to a 
way that already exists to provide direction to the ports system about whether 
WANT_PHP_WEB should imply _CGI or _MOD?


___
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

Using WANT_PHP_WEB

[Matthew Pounsett]

I’m trying to compile a port that sets WANT_PHP_WEB=yes.  The docs say this 
tells the ports system to compile either the PHP CGI or mod_php port.  My 
question is.. how does the ports system get directed to one or the other?  As 
the person compiling this port I’d like it to use mod_php, but it’s not getting 
built or included in the dependencies, and I can’t find any documentation about 
how to give it a hint.

Without a knob in place to direct this one way or the other, I’m not 
understanding why WANT_PHP_WEB exists .. why not just have the port maintainer 
set either _CGI or _MOD?


___
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

Setting up SIGNATURE_TYPE: PUBKEY in a custom repository

[Matthew Pounsett]

I’m setting up a local package repository using PGP signatures for 
verification.  The man page for pkg.conf says that the option “PUBKEY” (for 
setting the path to the public key) is deprecated, but fails to mention what 
the new method for managing this is.   I’ve tried googling about this, but all 
I find is people still having problems with PACKAGESITE in the default pkg.conf 
(still think it’s amusing that pkg installs a default config file it can’t use).

pkg seems to accept SIGNATURE_TYPE: PUBKEY, and a PUBKEY path, but it is not 
actually doing any signature verification.  I can test this by deleting the 
public key from the client machine where this config resides, and pkg produces 
no errors.

Can anyone point me to real (current) documentation for setting this up?

Thanks!
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: per-port make.conf options and hyphenated port names

[Matthew Pounsett]

On Jan 21, 2014, at 04:36 , Volodymyr Kostyrko c.kw...@gmail.com wrote:

 21.01.2014 03:01, Matthew Pounsett wrote:
 
 Digging through /usr/ports/Mk/ I can’t find anywhere that $UNIQUENAME is 
 modified to guarantee that it references a safe variable name (i.e. I don’t 
 see anywhere that $UNIQUENAME has reserved characters removed from it before 
 use).  So, given that a lot of times $UNIQUENAME is just the name of the 
 port, and a lot of ports have hyphens in their names, how is this meant to 
 be dealt with?
 
 Thanks for any pointers or help!
 
 Excuse me hijacking the thread but doesn't ports-mgmt/portconf do almost the 
 same?

It might, but not being part of the core ports makefiles it’s not a candidate 
for use inside tinderbox and other port-building tools.



___
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

per-port make.conf options and hyphenated port names

[Matthew Pounsett]

At some point in the last couple of weeks I was pointed at 
https://wiki.freebsd.org/Ports/Options/OptionsNG as what has been implemented 
to deprecate make.conf settings such as “WITHOUT_X11=yes”.   That document says 
it has been committed, but the porters handbook section on OPTIONS doesn’t 
discuss the ${port}_SET/${port}_UNSET syntax, and I can’t find mention of it in 
/usr/ports/KNOBS either.

I’m trying to find specifics on the implementation because I’ve run into a case 
that document doesn’t seem to plan for:  trying to set per-port options for a 
hyphenated port name.

Specifically, I’m trying to do this:
virtualbox-ose-additions_UNSET=X11

Hyphenated variable names don’t work in most shells.  I think some older 
versions of csh could set them, but couldn't reference them, and tinderbox’s sh 
scripts blow right up when they encounter that.

Digging through /usr/ports/Mk/ I can’t find anywhere that $UNIQUENAME is 
modified to guarantee that it references a safe variable name (i.e. I don’t see 
anywhere that $UNIQUENAME has reserved characters removed from it before use).  
So, given that a lot of times $UNIQUENAME is just the name of the port, and a 
lot of ports have hyphens in their names, how is this meant to be dealt with?

Thanks for any pointers or help!
___
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: per-port make.conf options and hyphenated port names

[Matthew Pounsett]

On Jan 20, 2014, at 20:01 , Matthew Pounsett m...@conundrum.com wrote:

 Digging through /usr/ports/Mk/ I can’t find anywhere that $UNIQUENAME is 
 modified to guarantee that it references a safe variable name (i.e. I don’t 
 see anywhere that $UNIQUENAME has reserved characters removed from it before 
 use).  So, given that a lot of times $UNIQUENAME is just the name of the 
 port, and a lot of ports have hyphens in their names, how is this meant to be 
 dealt with?

I take back part of that last bit.  I’ve found a couple cases (bsd.tcl.mk and 
bsd.database.mk) that use the ${UNIQUENAME:U:S,-,_,} construction to allow 
setting safe variables.  bsd.port.mk doesn’t use the same construction when 
referencing ${$UNIQUENAME}_SET and ${$UNIQUENAME}_UNSET.

So, I’m still back at my earlier question… how is this meant to be dealt with?

Thanks.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: lang/ruby19 distfile not found (ruby-1.9.3-p484.tar.bz2)

[Matthew Pounsett]

On 2014-01-07, at 10:09 , Mark Martinec mark.martinec+free...@ijs.si wrote:

 Having a policy that a port needs at least one mirror in each
 protocol family would be very useful. A fallback mirror like
 ftp.freebsd.org could fill-in this job.

I'm really surprised that ftp.freebsd.org *isn't* guaranteed to have every 
distfile.  I was going to set up this VM to be running tinderbox and be my 
binary package distribution server, figuring that since it's an internal 
service it didn't really need v4 connectivity (all my other machines are 
dual-stacked).  I thought for sure I could rely on ftp.freebsd.org to get me 
files where maintainers didn't have their own distribution in both protocol 
families.  I was even thinking about recompiling the kernel without INET 
support.


___
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

lang/ruby19 distfile not found (ruby-1.9.3-p484.tar.bz2)

[Matthew Pounsett]

While building ports-mgmt/portupgrade, I'm trying to build ruby19 on a new 
system (9.2-RELEASE), portsnapped up to five minutes ago.  I'm unable to find 
ruby-1.9.3-p484.tar.bz2 on any of the FreeBSD mirrors that ports tries.

I thought this might be a new development (recently updated port, not enough 
time for the distfile to make it everywhere) except that the Makefile shows the 
last update as 2013-12-13 02:17:30Z.  I also don't see anything recent about it 
in gnats[1], so I have to assume this has been broken for a few weeks.

This is my make.conf .. otherwise this is a pristine system.
# cat /etc/make.conf 
WITHOUT_X11=yes
MAKEFLAGS=-j2

It shouldn't matter, but this box is v6-only (hence a few network not 
reachable and timeout errors for some fetch attempts).  I've FTP'd into a 
handful of the v6 enabled hosts and manually looked for the distfile, just to 
verify that I should be able to reach it somewhere via v6.

Any thoughts or suggestions?

[1] 
http://www.freebsd.org/cgi/query-pr-summary.cgi?category=portstext=ruby19sort=noneclosedtoo=on



root@tinder:/usr/ports/ports-mgmt/portupgrade # make install
===  License BSD accepted by the user
===  Found saved configuration for portupgrade-2.4.12,2
=== Fetching all distfiles required by portupgrade-2.4.12,2 for building
===  Extracting for portupgrade-2.4.12,2
= SHA256 Checksum OK for portupgrade/pkgtools-2.4.12.tar.bz2.
===   portupgrade-2.4.12,2 depends on file: /usr/local/bin/ruby19 - not found
===Verifying install for /usr/local/bin/ruby19 in /usr/ports/lang/ruby19
===  License BSD2CLAUSE RUBY accepted by the user
===  Found saved configuration for ruby-1.9.3.484,1
= ruby-1.9.3-p484.tar.bz2 doesn't seem to exist in /usr/ports/distfiles/ruby.
= Attempting to fetch 
ftp://ftp.ruby-lang.org/pub/ruby/1.9/ruby-1.9.3-p484.tar.bz2
fetch: ftp://ftp.ruby-lang.org/pub/ruby/1.9/ruby-1.9.3-p484.tar.bz2: Network is 
unreachable
= Attempting to fetch 
ftp://ftp.SpringDaemons.com/pub/ruby/ruby/1.9/ruby-1.9.3-p484.tar.bz2
fetch: ftp://ftp.SpringDaemons.com/pub/ruby/ruby/1.9/ruby-1.9.3-p484.tar.bz2: 
Network is unreachable
= Attempting to fetch 
http://www.ibiblio.org/pub/languages/ruby/1.9/ruby-1.9.3-p484.tar.bz2
fetch: http://www.ibiblio.org/pub/languages/ruby/1.9/ruby-1.9.3-p484.tar.bz2: 
Forbidden
= Attempting to fetch 
ftp://xyz.lcs.mit.edu/pub/ruby/1.9/ruby-1.9.3-p484.tar.bz2
fetch: ftp://xyz.lcs.mit.edu/pub/ruby/1.9/ruby-1.9.3-p484.tar.bz2: Network is 
unreachable
= Attempting to fetch 
http://ring.nict.go.jp/archives/lang/ruby/1.9/ruby-1.9.3-p484.tar.bz2
fetch: http://ring.nict.go.jp/archives/lang/ruby/1.9/ruby-1.9.3-p484.tar.bz2: 
Network is unreachable
= Attempting to fetch 
ftp://ftp.fu-berlin.de/unix/languages/ruby/1.9/ruby-1.9.3-p484.tar.bz2
fetch: ftp://ftp.fu-berlin.de/unix/languages/ruby/1.9/ruby-1.9.3-p484.tar.bz2: 
Network is unreachable
= Attempting to fetch 
ftp://ftp.easynet.be/ruby/ruby/1.9/ruby-1.9.3-p484.tar.bz2
fetch: ftp://ftp.easynet.be/ruby/ruby/1.9/ruby-1.9.3-p484.tar.bz2: File 
unavailable (e.g., file not found, no access)
= Attempting to fetch 
ftp://ftp.ntua.gr/pub/lang/ruby/1.9/ruby-1.9.3-p484.tar.bz2
fetch: ftp://ftp.ntua.gr/pub/lang/ruby/1.9/ruby-1.9.3-p484.tar.bz2: Network is 
unreachable
= Attempting to fetch 
ftp://ftp.kr.FreeBSD.org/pub/ruby/1.9/ruby-1.9.3-p484.tar.bz2
fetch: ftp://ftp.kr.FreeBSD.org/pub/ruby/1.9/ruby-1.9.3-p484.tar.bz2: Network 
is unreachable
= Attempting to fetch 
http://mirrors.sunsite.dk/ruby/1.9/ruby-1.9.3-p484.tar.bz2
fetch: http://mirrors.sunsite.dk/ruby/1.9/ruby-1.9.3-p484.tar.bz2: Not Found
= Attempting to fetch 
ftp://ftp.iDaemons.org/pub/mirror/ftp.ruby-lang.org/ruby/1.9/ruby-1.9.3-p484.tar.bz2
fetch: 
ftp://ftp.iDaemons.org/pub/mirror/ftp.ruby-lang.org/ruby/1.9/ruby-1.9.3-p484.tar.bz2:
 Network is unreachable
= Attempting to fetch 
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/distfiles/ruby/ruby-1.9.3-p484.tar.bz2
fetch: 
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/distfiles/ruby/ruby-1.9.3-p484.tar.bz2: 
File unavailable (e.g., file not found, no access)
= Couldn't fetch it - please try to retrieve this
= port manually into /usr/ports/distfiles/ruby and try again.
*** [do-fetch] Error code 1

Stop in /usr/ports/lang/ruby19.
*** [install] Error code 1

Stop in /usr/ports/lang/ruby19.
*** [extract-depends] Error code 1

Stop in /usr/ports/ports-mgmt/portupgrade.
*** [install] Error code 1

Stop in /usr/ports/ports-mgmt/portupgrade.

___
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

ejabberd port: default config not working

[Matthew Pounsett]

I've just installed ejabberd from ports 

 sudo portversion -v ejabberd
ejabberd-2.1.11 =  up-to-date with port 

Just to get it running, I've put the sample configs in place as running 
configs.  I did a quick scan through them to look for any obvious changes that 
needed to be made for local configuration and started up the daemon. 

The only oddity I found is that ejabberdctl.cfg refers to 
/var/run/ejabberd/ejabberd.pid for the ejabberd PID file, but that directory 
wasn't created.  I tried creating it, but ejabberd writes nothing there.

 ps auxww | grep ejabberd
ejabberd  70497  0.0  0.1  8072  1236  ??  S 7:06PM   0:00.01 
/usr/local/lib/erlang/erts-5.9.3.1/bin/epmd -daemon

 ls -la /var/run/ejabberd/
total 4
drwxr-xr-x   2 ejabberd  ejabberd   512 May 24 18:39 .
drwxr-xr-x  12 root  wheel 1024 May 27 19:09 ..
 
Despite this the daemon seems to have started fine.  However, the control 
client isn't able to talk to ejabberd.  
 

 sudo ejabberdctl register matt conundrum.com [REDACTED]
Failed RPC connection to the node ejabberd@localhost: nodedown

Commands to start an ejabberd node:
  start  Start an ejabberd node in server mode
  debug  Attach an interactive Erlang shell to a running ejabberd node
  live   Start an ejabberd node in live (interactive) mode

Optional parameters when starting an ejabberd node:
  --config-dir dir   Config ejabberd:/usr/local/etc/ejabberd
  --config file  Config ejabberd:/usr/local/etc/ejabberd/ejabberd.cfg
  --ctl-config file  Config ejabberdctl: /usr/local/etc/ejabberd/ejabberdctl.cfg
  --logs dir Directory for logs: /var/log/ejabberd
  --spool dirDatabase spool dir: /var/spool/ejabberd
  --node nodenameejabberd node name: ejabberd@localhost

Is this just the missing PID file that's the problem?  I can't find a reference 
to a PID config in the ejabberd.cfg file, so I'm not sure if it's really 
expected to write something in that location or not.  I'm also unsure how 
ejabberdctl is trying to communicate with ejabberd .. whether the PID file is 
even important..

Anyone know what I'm missing here?
Thanks

___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: emulators/virtualbox-ose failing to build, 8.2-p9 on amd64

[Matthew Pounsett]

On 2013/01/06, at 02:48, Bernhard Fröhlich wrote:

 Looks like your libsdl version is either very old or too new. Could you
 please check which libsdl version you have installed?

1.2.15-_2,2.  It's the current ports version (as of this afternoon when I 
updated my ports tree).


___
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: emulators/virtualbox-ose failing to build, 8.2-p9 on amd64

[Matthew Pounsett]

On 2013/01/06, at 04:46, Matthew Pounsett wrote:

 
 On 2013/01/06, at 02:48, Bernhard Fröhlich wrote:
 
 Looks like your libsdl version is either very old or too new. Could you
 please check which libsdl version you have installed?
 
 1.2.15-_2,2.  It's the current ports version (as of this afternoon when I 
 updated my ports tree).
 
Ah.. I found the problem.  The libsdl port config file had an old WITHOUT_X11 
it was holding on to.. I got rid of that, rebuilt, and virtualbox compiles fine 
now.   Thanks for the lead!


___
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

emulators/virtualbox-ose failing to build, 8.2-p9 on amd64

[Matthew Pounsett]

I'm having a problem getting virtualbox to build on an 8.2-R-p9 box.  The 
compile is failing with the below pasted error.  I've made sure that all of the 
ports that virtualbox depends upon are up to date.  

 uname -a
FreeBSD masked.com 8.2-RELEASE-p9 FreeBSD 8.2-RELEASE-p9 #0: Mon Jun 11 
23:00:11 UTC 2012 
r...@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC  amd64

My make.conf is simple:

MAKEFLAGS=-j3
WITH_APACHE2=yes
# added by use.perl 2012-12-04 17:16:34
PERL_VERSION=5.14.2

I have tried commenting out the MAKEFLAGS entry and recompiling, but that 
doesn't help.Does anyone have thoughts on what the problem is, or 
suggestions for troubleshooting?

Thanks in advance.



kBuild: Compiling VBoxSDL - 
/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.2.6/src/VBox/Frontends/VBoxSDL/VBoxSDL.cpp
/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.2.6/src/VBox/Frontends/VBoxSDL/VBoxSDL.cpp:
 In member function 'virtual nsresult 
VBoxSDLConsoleEventListener::HandleEvent(PRUint32, IEvent*)':
/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.2.6/src/VBox/Frontends/VBoxSDL/VBoxSDL.cpp:543:
 error: 'struct SDL_SysWMinfo' has no member named 'info'
/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.2.6/src/VBox/Frontends/VBoxSDL/VBoxSDL.cpp:
 In function 'int TrustedMain(int, char**, char**)':
/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.2.6/src/VBox/Frontends/VBoxSDL/VBoxSDL.cpp:2069:
 error: 'struct SDL_SysWMinfo' has no member named 'info'
/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.2.6/src/VBox/Frontends/VBoxSDL/VBoxSDL.cpp:2074:
 error: 'struct SDL_SysWMinfo' has no member named 'info'
/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.2.6/src/VBox/Frontends/VBoxSDL/VBoxSDL.cpp:2865:
 error: 'struct SDL_SysWMinfo' has no member named 'info'
/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.2.6/src/VBox/Frontends/VBoxSDL/VBoxSDL.cpp:2880:
 error: 'struct SDL_SysWMinfo' has no member named 'info'
/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.2.6/src/VBox/Frontends/VBoxSDL/VBoxSDL.cpp:
 In function 'uint16_t Keyevent2Keycode(const SDL_KeyboardEvent*)':
/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.2.6/src/VBox/Frontends/VBoxSDL/VBoxSDL.cpp:3351:
 error: 'struct SDL_SysWMinfo' has no member named 'info'
/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.2.6/src/VBox/Frontends/VBoxSDL/VBoxSDL.cpp:
 In function 'void SetPointerShape(const PointerShapeChangeData*)':
/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.2.6/src/VBox/Frontends/VBoxSDL/VBoxSDL.cpp:4596:
 error: 'struct SDL_SysWMinfo' has no member named 'info'
/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.2.6/src/VBox/Frontends/VBoxSDL/VBoxSDL.cpp:4615:
 error: 'struct SDL_SysWMinfo' has no member named 'info'
kmk: *** 
[/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.2.6/out/freebsd.amd64/release/obj/VBoxSDL/VBoxSDL.o]
 Error 1
The failing command:
@g++ -c -O2 -fPIC -g -pipe -Wshadow  -Wno-long-long -Wno-variadic-macros 
-Wno-long-long -Wno-non-virtual-dtor -Wshadow -fshort-wchar -fpermissive 
-fexceptions -frtti -O2 -mtune=generic -fno-omit-frame-pointer 
-fno-strict-aliasing -fvisibility-inlines-hidden -fvisibility=hidden 
-DVBOX_HAVE_VISIBILITY_HIDDEN -DRT_USE_VISIBILITY_DEFAULT -m64 
-I/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.2.6/out/freebsd.amd64/release/obj/VBoxSDL
 -I/usr/include -I/usr/X11R6/include -I/usr/local/include 
-I/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.2.6/out/freebsd.amd64/release/bin/sdk/bindings/xpcom/include
 
-I/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.2.6/out/freebsd.amd64/release/bin/sdk/bindings/xpcom/include/xpcom
 
-I/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.2.6/out/freebsd.amd64/release/bin/sdk/bindings/xpcom/include/string
 
-I/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.2.6/out/freebsd.amd64/release/bin/sdk/bindings/xpcom/include/xpcom
 -I/usr/
 
ports/emulators/virtualbox-ose/work/VirtualBox-4.2.6/out/freebsd.amd64/release/bin/sdk/bindings/xpcom/include/nsprpub
 
-I/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.2.6/out/freebsd.amd64/release/bin/sdk/bindings/xpcom/include/ipcd
 -I/usr/local/include/SDL -I/usr/local/include 
-I/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.2.6/include 
-I/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.2.6/out/freebsd.amd64/release
 -DVBOX -DVBOX_WITH_DEBUGGER -DVBOX_OSE -DVBOX_WITH_64_BITS_GUESTS 
-DVBOX_WITH_HARDENING -DRT_OS_FREEBSD -D__FREEBSD__ -DRT_ARCH_AMD64 -D__AMD64__ 
-DRTPATH_APP_PRIVATE=\/usr/local/share/virtualbox-ose\ 
-DRTPATH_APP_PRIVATE_ARCH=\/usr/local/lib/virtualbox\ 
-DRTPATH_SHARED_LIBS=\/usr/local/lib/virtualbox\ 
-DRTPATH_APP_DOCS=\/usr/local/share/doc/virtualbox-ose\ -DPIC -DIN_RING3 
-DUNICODE -DNDEBUG=1 -DVBOX_WITH_XPCOM -DNDEBUG -DTRIMMED -DVBOXSDL_WITH_X11 
-Wp,-MD,/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.2.6/out/freebsd.amd64/rel
 ease/obj/VBoxSDL/VBoxSDL.o.dep 

Re: Creating a port as plugin for multiple other ports

[Matthew Pounsett]

On 2012/07/12, at 00:51, Romain Tartière wrote:

 On Wed, Jul 11, 2012 at 05:58:23PM -0400, Matthew Pounsett wrote:
 1) create two different ports (icinga-mod_gearman and nagios-mod_gearman).
 2) use options to select which system is being plugged into.
 
 1) allows you to install both plugins simultaneously, which may be
 better unless icinga and nagios are mutually exclusive.  You can make
 your life easier by setting up a master and a slave port.  The slave
 would inherit some aspects of the master one, overriding a few settings
 (e.g. groups, installation directory).

Ah, yes that makes a lot of sense.  Thanks for the MASTERDIR pointer.. that'll 
be really helpful.

cheers!
   Matt


___
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

Creating a port as plugin for multiple other ports

[Matthew Pounsett]

Pardon the cryptic subject line.  I couldn't think of a more concise way to 
describe what I'm working on.

I'm working on building a port of mod_gearman, a monitoring plugin for Nagios 
and Icinga.   Since the plugin might modify icinga or might modify nagios, it 
has different possible install locations for some support files, and different 
possible users as owners of those files.

The question I have is about the best way to approach this.  Is this something 
that crops up often enough for there to be a standard (or even just preferred) 
method?  The two that come to mind are:
1) create two different ports (icinga-mod_gearman and nagios-mod_gearman).
   I don't particularly like this one since it requires maintenance of two 
different ports.
2) use options to select which system is being plugged into.
   It's not clear to me whether it's considered good practice to define options 
that are mutually exclusive, or whether reading in of the options file would be 
too late in the process for defining dependencies.

Are there other options here?  Any guidance on the best route to take?  Are 
there existing ports which are in the same situation that I can crib from?

Thanks for any pointers.___
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

compiling py-* ports for python32

[Matthew Pounsett]

I'd like to install a couple of the python module ports as part of my python32 
install (also from ports).  Is there an incantation I can use with portinstall 
or the ports Makefile that will allow me to tell typical py-* modules in my 
python 3.2 libraries instead of with python 2.7, or should I be looking at 
cloning py-* ports into nearly-identical py32-* ports and submitting them?

Thanks for any pointers!
  

___
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: compiling py-* ports for python32

[Matthew Pounsett]

On 2012/01/10, at 01:16, wen heping wrote:

 Try add this line in /etc/make.conf
 
 PYTHON_DEFAULT_VERSION=python3.2

Perfect!  Thanks very much!

One of the dependencies turns out to have a syntax dependency on python2.x, but 
I can work with that.


___
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

sudo always_set_home permanently set?

[Matthew Pounsett]

I'm having an issue with the sudo port.. always_set_home seems to be on by 
default (contrary to the documentation), and I can't get it to turn off.  I 
don't see any patches related to this in the port's files directory, so I'm at 
a loss as to the cause.  What am I missing?

 sudo -V
Sudo version 1.7.4p4

 sudo grep set_home /usr/local/etc/sudoers
Defaults!always_set_home
Defaults!set_home

 sudo env | grep HOME
HOME=/root


___
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

portinstall dependency calculation mishap

[Matthew Pounsett]

I've run into an odd problem where portinstall seems to want to double-install 
a package when portinstall is run from inside a bash script.  The case I ran 
into was trying to install the postgres84-server port.  In the dependencies is 
devel/pkg-config.  When run from inside a shell script, portinstall tries to 
install pkg-config a second time after the postgres install is complete.  If I 
run it outside a shell script (from my prompt) it works fine.  

I ran into this using my personal environment and sudo, but I've repeated it 
with a bare tcsh login as well as a direct login to root's account from the 
console, so I'm confident this isn't due to interference from something in my 
environment.

I can work around this by installing pkg-config directly before installing 
postgres, but thought this was odd enough to warrant an email to the list.

Repeatability is trivial on a freshly installed 8.0-RELEASE as well as on 
8.2-RELEASE-p2 system with an up-to-date ports tree.

 cat  testscript EOF
#!/usr/local/bin/bash

portinstall databases/postgresql84-server
EOF

 chmod a+x testscript
 sudo ./testscript

I've trimmed the config/cc/etc output from a log of my shell and included it 
below so that the order of operations can be seen.

[Updating the pkgdb format:bdb_btree in /var/db/pkg ... - 22 packages found 
(-3 +0) (...) done]
[Gathering depends for databases/postgresql84-server ... done]
---  Installing 'postgresql-client-8.4.8' from a port 
(databases/postgresql84-client)
---  Building '/usr/ports/databases/postgresql84-client'
===  Cleaning for libxml2-2.7.8_1
===  Cleaning for pkg-config-0.25_1
===  Cleaning for postgresql-client-8.4.8
===  Vulnerability check disabled, database not found
===  License check disabled, port has not defined LICENSE
===  Found saved configuration for postgresql-client-8.4.8
===  Extracting for postgresql-client-8.4.8
= SHA256 Checksum OK for postgresql/postgresql-8.4.8.tar.bz2.
===  Patching for postgresql-client-8.4.8
===  Applying FreeBSD patches for postgresql-client-8.4.8
===   postgresql-client-8.4.8 depends on executable: gmake - found
===   postgresql-client-8.4.8 depends on shared library: xml2.5 - not found
===Verifying install for xml2.5 in /usr/ports/textproc/libxml2
===  Vulnerability check disabled, database not found
===  License check disabled, port has not defined LICENSE
===  Extracting for libxml2-2.7.8_1
= SHA256 Checksum OK for gnome2/libxml2-2.7.8.tar.gz.
===  Patching for libxml2-2.7.8_1
===  Applying FreeBSD patches for libxml2-2.7.8_1
===   libxml2-2.7.8_1 depends on executable: gmake - found
===   libxml2-2.7.8_1 depends on executable: pkg-config - not found
===Verifying install for pkg-config in /usr/ports/devel/pkg-config
===  Vulnerability check disabled, database not found
===  License check disabled, port has not defined LICENSE
===  Extracting for pkg-config-0.25_1
= SHA256 Checksum OK for gnome2/pkg-config-0.25.tar.gz.
===  Patching for pkg-config-0.25_1
===  Applying FreeBSD patches for pkg-config-0.25_1
===   pkg-config-0.25_1 depends on executable: gmake - found
===  Configuring for pkg-config-0.25_1
===  Building for pkg-config-0.25_1
===  Installing for pkg-config-0.25_1
===   Generating temporary packing list
===  Checking if devel/pkg-config already installed
===   Compressing manual pages for pkg-config-0.25_1
===   Registering installation for pkg-config-0.25_1
===   Returning to build of libxml2-2.7.8_1
===   libxml2-2.7.8_1 depends on shared library: iconv.3 - found
===  Configuring for libxml2-2.7.8_1
===  Building for libxml2-2.7.8_1
===  Installing for libxml2-2.7.8_1
===   libxml2-2.7.8_1 depends on executable: pkg-config - found
===   Generating temporary packing list
===  Checking if textproc/libxml2 already installed
===   Compressing manual pages for libxml2-2.7.8_1
===   Running ldconfig
===   Registering installation for libxml2-2.7.8_1
===   Returning to build of postgresql-client-8.4.8
===   postgresql-client-8.4.8 depends on shared library: intl - found
===  Configuring for postgresql-client-8.4.8
===  Building for postgresql-client-8.4.8
===  Installing for postgresql-client-8.4.8
===   postgresql-client-8.4.8 depends on shared library: xml2.5 - found
===   postgresql-client-8.4.8 depends on shared library: intl - found
===   Generating temporary packing list
===  Checking if databases/postgresql84-client already installed
===   Compressing manual pages for postgresql-client-8.4.8
===   Running ldconfig
===   Registering installation for postgresql-client-8.4.8
===  Cleaning for libxml2-2.7.8_1
===  Cleaning for pkg-config-0.25_1
===  Cleaning for postgresql-client-8.4.8
[Updating the pkgdb format:bdb_btree in /var/db/pkg ... - 25 packages found 
(-0 +3) ... done]
---  Installing 'pkg-config-0.25_1' from a port (devel/pkg-config)
---  Building '/usr/ports/devel/pkg-config'
===  Cleaning for pkg-config-0.25_1
===  Vulnerability check disabled, database not found
===  License check disabled, port 

Re: Optional Patches

[Matthew Pounsett]

Following up my own post.  Bleargh.


On 2011/05/18, at 17:29, Matthew Pounsett wrote:

 .if defined(FOO)
 PATCH_SITES=  http://location.site.com/path/
 PATCHFILES=   port-${PORTVERSION}.patch
 PATCH_DIST_STRIP= -p1
 .endif

I should note that I have actually been doing this using '.if 
defined(WITH_FOO)', as one would expect for an option named FOO.  I've tried 
defined(FOO) just in case, but didn't really expect that to work.



___
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: Optional Patches

[Matthew Pounsett]

Based on the responses here it sounds like I've been doing nothing wrong so I 
played around a bit more.  I guess in my testing there must've been some 
combination of things I didn't get right... I did a bunch more testing and 
eventually I made it work doing exactly what I've been doing, except for the 
location of the ifdef.

It turns out that in order to make this work, the .if define must appear below 
where bsd.port.pre.mk is included.  If it occurs above that, I guess the 
definition of .if doesn't exist yet and so the block doesn't get run at all.

I don't recall seeing this restriction mentioned in the porters' handbook, but 
perhaps I missed it.

Thanks for the feedback.. sometimes just knowing it *should* work is enough to 
help lead one to the right bit of troubleshooting.

Cheers,
   Matt


___
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

Complicated patching

[Matthew Pounsett]

Hi.

In a (possibly foolish) attempt to add a third-party patch to an application I 
use *without* abandoning the ports tree for this app, I'm trying to make a 
local modification to the port to download and include the patch in the build 
process.  The problem I'm running into is that it is distributed from a source 
distribution site that uses a downloads CGI rather than a direct URL to 
distribution files, and the URI has nothing whatsoever to do with the name of 
the resulting file.  This, obviously, breaks MASTER_SITES and DISTFILES because 
what I have to put in DISTFILES doesn't match what would go in the distinfo 
file.

I'm poking around at possible alternatives, but nothing really stands out in 
the reading I've done.  Is this sort of thing supported by the ports system at 
all, or should I just abandon this completely and switch to fully manual builds?

I briefly looked at downloading the patch file, splitting it up (it includes 
several patches) and including the resulting files in files/patch-*.  This 
would be worth the work, but I'm also toying with eventually submitting my 
changes as a patch to the port with a line in OPTIONS to include/ignore the 3rd 
party patches and I can't find a way to wrap an ifdef around patch-* files in 
the Makefile, since they seem to be auto-discovered and acted on.  

If anyone has any advice on how to handle this in a way that solves both 
problems, I'd appreciate it.  Thanks in advance!
   Matt Pounsett


___
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: Complicated patching

[Matthew Pounsett]

On 2011/05/17, at 18:07, Olli Hauer wrote:

 there is a way, sample ports:
 dns/djbdns, dns/bind94, mail/postfix (VDA patches) and many more

Thanks for the examples.  I'll dig through those and see what I can glean from 
them.

 A short description can be found in Mk/bsd.port.mk
 A longer description can be found in the porters handbook
 http://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/makefile-distfiles.html

I've read through the porters handbook, and this page in particular, but didn't 
see anything that solved my problem.  I'll have another look though.  

Thanks very much!

 
 Additional you can place a patch without the prefix patch-
 into the portname/files directory, then use for example
 
 .if defined(PATCH_THIS_FOO)
 EXTRA_PATCHES+=
 .endif

___
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