So, I've added support into the compilers portgroup for working with
the compiler.blacklist variable but that doesn't fix the issue that Ryan
tried to fix with r125939:
https://trac.macports.org/changeset/125939
It seems instead that the fix is just to remove the gcc variants:
mpi.setup -gcc
On Dec 14, 2014, at 2:28 AM, Sean Farley s...@macports.org wrote:
So, I've added support into the compilers portgroup for working with
the compiler.blacklist variable but that doesn't fix the issue that Ryan
tried to fix with r125939:
https://trac.macports.org/changeset/125939
It seems
On Dec 14, 2014, at 2:28 AM, Sean Farley wrote:
So, I've added support into the compilers portgroup for working with
the compiler.blacklist variable but that doesn't fix the issue that Ryan
tried to fix with r125939:
https://trac.macports.org/changeset/125939
It seems instead that the
Mark Moll writes:
On Dec 14, 2014, at 2:28 AM, Sean Farley s...@macports.org wrote:
So, I've added support into the compilers portgroup for working with
the compiler.blacklist variable but that doesn't fix the issue that Ryan
tried to fix with r125939:
Ryan Schmidt writes:
On Dec 14, 2014, at 2:28 AM, Sean Farley wrote:
So, I've added support into the compilers portgroup for working with
the compiler.blacklist variable but that doesn't fix the issue that Ryan
tried to fix with r125939:
https://trac.macports.org/changeset/125939
It
On Dec 14, 2014, at 11:41 AM, Sean Farley wrote:
Ryan Schmidt writes:
On Dec 14, 2014, at 2:28 AM, Sean Farley wrote:
So, I've added support into the compilers portgroup for working with
the compiler.blacklist variable but that doesn't fix the issue that Ryan
tried to fix with r125939:
Ryan Schmidt writes:
On Dec 14, 2014, at 11:41 AM, Sean Farley wrote:
Ryan Schmidt writes:
On Dec 14, 2014, at 2:28 AM, Sean Farley wrote:
So, I've added support into the compilers portgroup for working with
the compiler.blacklist variable but that doesn't fix the issue that Ryan
'evening!
I finally got around to finishing up (or almost) my draft version for a qt4-mac
port that can live alongside other (future) Qt port versions installed with the
same approach: see https://trac.macports.org/ticket/46238 .
Related submissions:
https://trac.macports.org/ticket/46239
On Dec 14, 2014, at 12:21 PM, Sean Farley wrote:
Ryan Schmidt writes:
So, this would add clang33, clang34, clang35 variants, for example? But
these would be different from the clang 3.x provided by Xcode in some way?
The MacPorts clang ports would be able to use MPI somehow, while Xcode
On Sunday, December 14, 2014, Ryan Schmidt ryandes...@macports.org wrote:
On Dec 14, 2014, at 12:21 PM, Sean Farley wrote:
Ryan Schmidt writes:
So, this would add clang33, clang34, clang35 variants, for example? But
these would be different from the clang 3.x provided by Xcode in some
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 14.12.2014 05:40 AM, Ryan Schmidt wrote:
On Dec 13, 2014, at 10:01 PM, Mihai Moldovan wrote:
On 14.12.2014 04:51 AM, Ryan Schmidt wrote:
If it works for your use case in mpv, and still works for other ports using
the github portgroup, go
On Dec 14, 2014, at 6:26 PM, io...@macports.org wrote:
Revision
129507
Author
io...@macports.org
Date
2014-12-14 16:26:55 -0800 (Sun, 14 Dec 2014)
Log Message
mpv: inline waf fetching.
Modified Paths
• trunk/dports/multimedia/mpv/Portfile
Diff
Modified:
On Sun, Dec 14, 2014 at 7:50 PM, Ryan Schmidt ryandes...@macports.org
wrote:
-pre-configure {
-system -W ${worksrcpath} ${waf.python} bootstrap.py
+post-extract {
+xinstall -m 0644 -W ${distpath} ${waf_distfile}
${worksrcpath}/waf
}
Remember, as Larry said in response to
On Dec 14, 2014, at 7:55 PM, Brandon Allbery allber...@gmail.com wrote:
If we're going to be pedantic, the braces around the variable names don't do
anything except in the case of ${waf.python} where they are required.
True, but we seem to have settled on ${this} as our style in portfiles. It
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 15.12.2014 01:50 AM, Ryan Schmidt wrote:
Thanks. How common do you think this is -- port downloads waf before using
it? Might we need this in other ports as well?
I only had a superficial look, but it seems not be common. Most software
On Dec 14, 2014, at 8:02 PM, Mihai Moldovan io...@macports.org wrote:
Yes, but until I issue a commit changing that in all places at once
I don't think this is worth making a huge commit to fix, and in fact I think
that would be a bad idea. It's not as if the quotes are *wrong*, and it would
Ryan Schmidt writes:
On Dec 14, 2014, at 12:21 PM, Sean Farley wrote:
Ryan Schmidt writes:
So, this would add clang33, clang34, clang35 variants, for example? But
these would be different from the clang 3.x provided by Xcode in some way?
The MacPorts clang ports would be able to use
On Dec 14, 2014, at 11:59 AM, khindenb...@macports.org wrote:
Revision
129502
Author
khindenb...@macports.org
Date
2014-12-14 09:59:07 -0800 (Sun, 14 Dec 2014)
Log Message
lastpass-cli: new port #45578 (and #45886)
Added Paths
• trunk/dports/security/lastpass-cli/
•
On Dec 14, 2014, at 8:58 PM, Ryan Schmidt ryandes...@macports.org wrote:
On Dec 14, 2014, at 11:59 AM, khindenb...@macports.org wrote:
This doesn't look sufficient. If pinentry support is automatically included
simply because pinentry is installed, then the main (non-pinentry) port needs
On Dec 14, 2014, at 8:48 PM, Kurt Hindenburg wrote:
On Dec 14, 2014, at 8:58 PM, Ryan Schmidt wrote:
Moreover, it seems strange to implement this as a subport instead of a
variant. Unless a subport is a -devel subport, it's not supposed to conflict
with the main port. Variants are
On 2014-12-15 13:48 , Kurt Hindenburg wrote:
On Dec 14, 2014, at 8:58 PM, Ryan Schmidt ryandes...@macports.org wrote:
On Dec 14, 2014, at 11:59 AM, khindenb...@macports.org wrote:
This doesn't look sufficient. If pinentry support is automatically included
simply because pinentry is
Hi,
It seems that people often think nomaintai...@macports.org and
openmaintai...@macports.org are real addresses. The attached patch doesn’t add
the @macports.org on port’s info. What do people think?
Kurt
Maintainers: nomaintainer
Maintainers: openmaintainer
I don't see why not, although I'd prefer something simpler, like this.
vq
diff --git a/base/src/port/port.tcl b/base/src/port/port.tcl
index 76a53c9..f81f891 100644
--- a/base/src/port/port.tcl
+++ b/base/src/port/port.tcl
@@ -686,7 +686,7 @@ proc unobscure_maintainers { list } {
if
The migration steps weren't really intended to be run as a single script. I'm
not comfortable telling users to run this big untested blob of code.
On Dec 14, 2014, at 10:37 PM, MacPorts nore...@macports.org wrote:
Page Migration was changed by d...@yost.com
Diff URL:
I've seen a number of instances recently on the buildbots where a port
fails on activation because of extraneous files left in the installation
tree by some previous failure.
My most recent example is py27-cython on buildports-snowleopard-x86_64:
Error: org.macports.activate for port
On 2014-12-14, at 07:59 PM, Lawrence Velázquez lar...@macports.org wrote:
The migration steps weren't really intended to be run as a single script. I'm
not comfortable telling users to run this big untested blob of code.
Then let’s test it! Works for me on Yosemite. I’ll run it again.
You
On 2014-12-15 15:46 , David Evans wrote:
I've seen a number of instances recently on the buildbots where a port
fails on activation because of extraneous files left in the installation
tree by some previous failure.
My most recent example is py27-cython on buildports-snowleopard-x86_64:
On 12/14/14 8:57 PM, Joshua Root wrote:
On 2014-12-15 15:46 , David Evans wrote:
I've seen a number of instances recently on the buildbots where a port
fails on activation because of extraneous files left in the installation
tree by some previous failure.
My most recent example is py27-cython
On 2014-12-15 16:25 , David Evans wrote:
On 12/14/14 8:57 PM, Joshua Root wrote:
On 2014-12-15 15:46 , David Evans wrote:
I've seen a number of instances recently on the buildbots where a port
fails on activation because of extraneous files left in the installation
tree by some previous
On 12/14/14 9:56 PM, Joshua Root wrote:
On 2014-12-15 16:25 , David Evans wrote:
On 12/14/14 8:57 PM, Joshua Root wrote:
On 2014-12-15 15:46 , David Evans wrote:
I've seen a number of instances recently on the buildbots where a port
fails on activation because of extraneous files left in the
On Mon, Dec 15, 2014 at 8:32 AM, David Evans wrote:
If my theory is
correct it doesn't seem appropriate to add code to py-cython that is only
needed for one build.
You could just as well add code, wait for the build on the buildbot to
finish and remove the code again.
It's a quick-and-dirty
31 matches
Mail list logo
