Re: foo-snapshot / foo-diff convenience functions

2016-10-20 Thread Joshua Root 

On 2016-10-21 01:42 , Lawrence Velázquez wrote:

On Oct 20, 2016, at 3:40 AM, René J.V. Bertin  wrote:


On Wednesday October 19 2016 21:44:04 Ryan Schmidt wrote:

No, that situation should not be common, nor indeed present at all.


I'm not sure I agree. PortGroups are intended to take care of setting
up things for the ports that use them (like declaring a dependency in
such a way ports work with the main as well as the -devel port), and
even an official one like the github PG adds dependency info. Ditto
for the Python PG: you cannot (to my knowledge) include it just to
obtain the variables that provide the python paths without also
redefining the configure mechanism.

You could claim that it should be uncommon that ports want only part
of the info a PG provides, but even that might not be relevant as
I think there are quite a few ports providing Python extensions but
that don't use Python's own configure/build/install mechanism (PyQt
and PyKDE come to mind).


This is arguably a defect of python-1.0 that should be fixed in the
portgroup.


No, it's just out of scope. The python portgroup is for installing with 
setup.py.


There is of course no reason why a different portgroup with a different 
purpose couldn't be created, and share code with this one behind the scenes.


- Josh
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [152490] contrib/buildbot-test

2016-10-20 Thread Lawrence Velázquez 
> On Oct 20, 2016, at 6:58 PM, Ryan Schmidt  wrote:
> 
> Are the passwords then a separate entry?

I overlooked passwords; I'll have to chew on that.

> I had planned to put the guide-building and www-fetching and
> ports-sql-updating and distfiles-fetching and rsync-server-updating
> tasks on the buildbot master, rather than on any of the existing
> buildbot workers that are building ports and base, because the
> existing workers are often quite busy, while the master is just
> sitting there doing largely nothing.

That makes sense.

vq
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: foo-snapshot / foo-diff convenience functions

2016-10-20 Thread Rainer Müller 
On 10/20/2016 10:25 PM, René J.V. Bertin wrote:
> On Thursday October 20 2016 15:38:42 Lawrence Velázquez wrote:
> 
>> Better that than increasing the complexity of base and portfiles.
> 
> Yeah, unless someone proposes to implement something in a portgroup. Then all 
> of a sudden it becomes base functionality ...

Port groups can be complex as long as that makes it easier to use the port group
in a Portfile. That is the whole point of port groups, eliminate redundancy and
make Portfiles concise.

However, port groups also have their limits of what can be implemented.
Functionality for all ports or extensions to the syntax should be in base.

Back to your proposal: in my opinion, such a syntax does not fit the declarative
style we commonly have in Portfiles. Previously we agreed more settings should
be declarative, but this would be a step backwards. In an ideal Portfile, port
groups are included by statements at the top of the Portfile and there is no
need to set anything before that.

Rainer
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: foo-snapshot / foo-diff convenience functions

2016-10-20 Thread Lawrence Velázquez 
> On Oct 20, 2016, at 4:25 PM, René J.V. Bertin 
> wrote:
> 
>> On Thursday October 20 2016 15:38:42 Lawrence Velázquez wrote:
>> 
>> Better that than increasing the complexity of base and portfiles.
> 
> Yeah, unless someone proposes to implement something in a portgroup.
> Then all of a sudden it becomes base functionality ...

Nonsense. There's plenty of functionality currently implemented in
portfiles that would make no sense in base.

> I won't be reinventing all kinds of wheels to delay updating
> dependency declarations beyond checking for the presence of a token
> when the portgroup is being read.

¯\_(ツ)_/¯

vq
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: foo-snapshot / foo-diff convenience functions

2016-10-20 Thread René J . V . Bertin 
On Thursday October 20 2016 15:38:42 Lawrence Velázquez wrote:

> Better that than increasing the complexity of base and portfiles.

Yeah, unless someone proposes to implement something in a portgroup. Then all 
of a sudden it becomes base functionality ...

I won't be reinventing all kinds of wheels to delay updating dependency 
declarations beyond checking for the presence of a token when the portgroup is 
being read.

R.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: foo-snapshot / foo-diff convenience functions

2016-10-20 Thread René J . V . Bertin 
On Thursday October 20 2016 10:42:09 Lawrence Velázquez wrote:

> It is already possible to create options that enable/disable portgroup
> behavior after the portgroup is included. The python-1.0 and php-1.1 do

Which increases the implementation complexity of the portgroup - each portgroup 
that needs to resort to that kind of trick.

R
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Trac down?

2016-10-20 Thread Vincent Habchi 

> On 20 Oct 2016, at 21:12, Lawrence Velázquez  wrote:
>> 
>> Yeah, I get that, but I mean: so nothing has changed yet: SVN is still 
>> supposed to work the way it always did (at least to my knowledge).
> 
> Right.

Thanks! I get out of your hair.

V.

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Trac down?

2016-10-20 Thread Lawrence Velázquez 
> On Oct 20, 2016, at 2:47 PM, Vincent Habchi  wrote:
> 
>> On 20 Oct 2016, at 20:44, Rainer Müller  wrote:
>> No, this downtime is not intentional or planned.
> 
> Yeah, I get that, but I mean: so nothing has changed yet: SVN is still 
> supposed to work the way it always did (at least to my knowledge).

Right.

vq
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Trac down?

2016-10-20 Thread Rainer Müller 
On 2016-10-20 20:28, Vincent Habchi wrote:
>> On 20 Oct 2016, at 14:04, Ryan Schmidt  wrote:
>> Trac, svn, www-origin and guide-origin are inaccessible outside of the Apple 
>> network. I'm trying to figure out why.
> 
> I’ve been very busy lately and didn’t have much time but for very perfunctory 
> looks at MacPorts. Now I’m almost back but… it doesn’t work. This has nothing 
> to do with migrating to git or whatever?

No, this downtime is not intentional or planned.

Rainer
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: llvm / clang and thread_local storage problems

2016-10-20 Thread Jeremy Huddleston Sequoia 
That's not really a reduced test case.  It would be helpful if we could get a 
reduced test case of the problem that doesn't involve having to debug the 
entire guile application.  An ideal test case would be a small C or C++ file 
without external dependencies that showcased the issue.

--Jeremy

> On Oct 20, 2016, at 10:20 AM, Jack Howarth  
> wrote:
> 
> On Sun, Oct 9, 2016 at 3:20 PM, Jeremy Huddleston Sequoia
>  wrote:
>> 
>>> On Oct 9, 2016, at 09:47, Jack Howarth  
>>> wrote:
>>> 
>>> On Sun, Oct 9, 2016 at 3:53 AM, Jeremy Huddleston Sequoia
>>>  wrote:
 thread_local support was added in OS X 10.9 (along with 
 __cxa_thread_atexit being added to Libc as part of that support).  As long 
 as your minimum deployment target is 10.9, you should be fine.  The issue 
 is that you're on 10.6, so you don't have __cxa_thread_atexit.
 
 There is active conversation right now about adding a fallback 
 implementation of __cxa_thread_atexit directly into libcxxabi.  See 
 https://reviews.llvm.org/D21803 as that might be quite useful for your 
 needs.  If so, provide a patch to libcxxabi that incorporates it, and I'll 
 get it in.
>>> 
>>> On the topic of thread local support, the failures in the guile 2.0.x
>>> test suite should be looked at...
>>> 
>>> https://trac.macports.org/ticket/52556
>>> 
>>> to determine if Apple's thread-local-storage implementation is buggy
>>> as upstream guile claims.
>> 
>> Radar?
> 
> Jeremy,
>  I finally puzzled out how to run the offending test case in
> guile by itself. This can be done using the current MacPorts guile
> 2.0.13 using...
> 
> 
> 1) Installl MacPorts and then execute "sudo port -d install guile" in
> a Terminal window to install the dependencies required for guile as
> well as guile
> 2) In a terminal window, execute 'sudo port -d build guile' to rebuild
> guile retaining the build directory.
> 3) change directory into the MacPorts build directory for guile
> 2.0.13. In my case this was with
> 
> cd 
> /opt/local/var/macports/build/_Users_howarth_ports_lang_guile/guile/work/guile-2.0.13/test-suite
> 
> 5) change to sudo because MacPorts work directories are owned by root
> 
> sudo csh
> 
> 4) set the required environmental variables for the guile-test test
> harness script...
> 
> setenv GUILE_LOAD_PATH
> /opt/local/var/macports/build/_Users_howarth_ports_lang_guile/guile/work/guile-2.0.13/test-suite
> setenv TEST_SUITE_DIR
> /opt/local/var/macports/build/_Users_howarth_ports_lang_guile/guile/work/guile-2.0.13/test-suite/tests
> 
> 5) finally run the failing test case under the installed MacPort's guile...
> 
> /opt/local/bin/guile  -e main -s guile-test srfi-18.test
> 
> Running srfi-18.test
> FAIL: srfi-18.test: thread-terminate!: termination destroys non-started thread
> FAIL: srfi-18.test: thread-terminate!: termination destroys started thread
> 
> Totals for this test run:
> passes: 59
> failures:   2
> unexpected passes:  0
> expected failures:  0
> unresolved test cases:  0
> untested test cases:0
> unsupported test cases: 0
> errors: 0
> 
> I've added those details to radar://28688091 "guile 2.0.12 exposes
> potential thread-local-storage bug on Mac OS X".
> Jack
> ps The problem was that the comments in the guile-test test harness,
> for running the tests individually, mentioned the need to set
> TEST_SUITE_DIR but failed to discuss the need to set GUILE_LOAD_PATH
> as well.
> 
> 
>> 
> ___
> macports-dev mailing list
> macports-dev@lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/macports-dev

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Trac down?

2016-10-20 Thread Vincent Habchi 
Hey,

> On 20 Oct 2016, at 14:04, Ryan Schmidt  wrote:
> 
>> On Oct 20, 2016, at 6:48 AM, Peter Danecek  wrote:
>> 
>> Hi all,
>> I am current not able to reach the trac server. Is this a real issue, or 
>> just a local problem here?
> 
> Trac, svn, www-origin and guide-origin are inaccessible outside of the Apple 
> network. I'm trying to figure out why.

I’ve been very busy lately and didn’t have much time but for very perfunctory 
looks at MacPorts. Now I’m almost back but… it doesn’t work. This has nothing 
to do with migrating to git or whatever?

Vincent
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: llvm / clang and thread_local storage problems

2016-10-20 Thread Jack Howarth 
On Sun, Oct 9, 2016 at 3:20 PM, Jeremy Huddleston Sequoia
 wrote:
>
>> On Oct 9, 2016, at 09:47, Jack Howarth  wrote:
>>
>> On Sun, Oct 9, 2016 at 3:53 AM, Jeremy Huddleston Sequoia
>>  wrote:
>>> thread_local support was added in OS X 10.9 (along with __cxa_thread_atexit 
>>> being added to Libc as part of that support).  As long as your minimum 
>>> deployment target is 10.9, you should be fine.  The issue is that you're on 
>>> 10.6, so you don't have __cxa_thread_atexit.
>>>
>>> There is active conversation right now about adding a fallback 
>>> implementation of __cxa_thread_atexit directly into libcxxabi.  See 
>>> https://reviews.llvm.org/D21803 as that might be quite useful for your 
>>> needs.  If so, provide a patch to libcxxabi that incorporates it, and I'll 
>>> get it in.
>>
>> On the topic of thread local support, the failures in the guile 2.0.x
>> test suite should be looked at...
>>
>> https://trac.macports.org/ticket/52556
>>
>> to determine if Apple's thread-local-storage implementation is buggy
>> as upstream guile claims.
>
> Radar?

Jeremy,
  I finally puzzled out how to run the offending test case in
guile by itself. This can be done using the current MacPorts guile
2.0.13 using...


1) Installl MacPorts and then execute "sudo port -d install guile" in
a Terminal window to install the dependencies required for guile as
well as guile
2) In a terminal window, execute 'sudo port -d build guile' to rebuild
guile retaining the build directory.
3) change directory into the MacPorts build directory for guile
2.0.13. In my case this was with

cd 
/opt/local/var/macports/build/_Users_howarth_ports_lang_guile/guile/work/guile-2.0.13/test-suite

5) change to sudo because MacPorts work directories are owned by root

sudo csh

4) set the required environmental variables for the guile-test test
harness script...

setenv GUILE_LOAD_PATH
/opt/local/var/macports/build/_Users_howarth_ports_lang_guile/guile/work/guile-2.0.13/test-suite
setenv TEST_SUITE_DIR
/opt/local/var/macports/build/_Users_howarth_ports_lang_guile/guile/work/guile-2.0.13/test-suite/tests

5) finally run the failing test case under the installed MacPort's guile...

/opt/local/bin/guile  -e main -s guile-test srfi-18.test

Running srfi-18.test
FAIL: srfi-18.test: thread-terminate!: termination destroys non-started thread
FAIL: srfi-18.test: thread-terminate!: termination destroys started thread

Totals for this test run:
passes: 59
failures:   2
unexpected passes:  0
expected failures:  0
unresolved test cases:  0
untested test cases:0
unsupported test cases: 0
errors: 0

I've added those details to radar://28688091 "guile 2.0.12 exposes
potential thread-local-storage bug on Mac OS X".
 Jack
ps The problem was that the comments in the guile-test test harness,
for running the tests individually, mentioned the need to set
TEST_SUITE_DIR but failed to discuss the need to set GUILE_LOAD_PATH
as well.


>
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [154019] trunk/dports/science/LORENE

2016-10-20 Thread Thibaut Paumard 
Le 20/10/2016 à 04:35, Ryan Schmidt a écrit :
>> +notes "
>> ++--- LORENE Usage note -
>> +| To compile LORENE code, you should run:
>> +|   export HOME_LORENE=${prefix}/lib/lorene
>> +| Codes are provided in \$HOME_LORENE/Codes. To use them, copy them to some
>> +| place were your have write access.
>> ++---
> 
> I'm not in favor of ASCII art boxes in notes. Just put the text; let MacPorts 
> line wrap and format it. If you believe MacPorts is not displaying the notes 
> prominently enough, then making notes more prominent by using boxes or 
> whatever should be done in MacPorts base, not in each individual port.

OK, thanks, I believe I copied that from some other port.

Regards, Thibaut.

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: foo-snapshot / foo-diff convenience functions

2016-10-20 Thread Lawrence Velázquez 
> On Oct 20, 2016, at 3:40 AM, René J.V. Bertin  wrote:
> 
>> On Wednesday October 19 2016 21:44:04 Ryan Schmidt wrote:
>> 
>> No, that situation should not be common, nor indeed present at all.
> 
> I'm not sure I agree. PortGroups are intended to take care of setting
> up things for the ports that use them (like declaring a dependency in
> such a way ports work with the main as well as the -devel port), and
> even an official one like the github PG adds dependency info. Ditto
> for the Python PG: you cannot (to my knowledge) include it just to
> obtain the variables that provide the python paths without also
> redefining the configure mechanism.
> 
> You could claim that it should be uncommon that ports want only part
> of the info a PG provides, but even that might not be relevant as
> I think there are quite a few ports providing Python extensions but
> that don't use Python's own configure/build/install mechanism (PyQt
> and PyKDE come to mind).

This is arguably a defect of python-1.0 that should be fixed in the
portgroup.

>>> For instance, a port providing translation files for a KDE port
>>> would probably need to include a KDE PortGroup but doesn't need to
>>> depend on Qt.
>> 
>> I haven't looked at the kde portgroup specifically. Maybe the
>> portgroup needs additional options to handle different types of
>> ports (e.g. libraries vs. translation files), or maybe there need to
>> be separate portgroup.
> 
> Well, that's indeed what I've ended up doing with KF5, but there it's
> justified because of the sheer number of dependency variables (over 30
> frameworks). The Qt PGs on the other hand define a considerable number
> of relevant variables but also add a single dependency to depends_lib.
> I don't think it's really justified to put just that in a separate PG.
> For that I'd rather add a switch to the PG, a variable to define
> before including it in order to deactivate something.
> 
> Maybe it would be possible to make that latter approach a bit more
> elegant, somehow merging those variable declarations into the
> PortGroup syntax?

It is already possible to create options that enable/disable portgroup
behavior after the portgroup is included. The python-1.0 and php-1.1 do
this quite a bit. There is no need to muck up the inclusion syntax.

vq
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Trac down?

2016-10-20 Thread Ryan Schmidt 

> On Oct 20, 2016, at 6:48 AM, Peter Danecek  wrote:
> 
> Hi all,
> I am current not able to reach the trac server. Is this a real issue, or just 
> a local problem here?

Trac, svn, www-origin and guide-origin are inaccessible outside of the Apple 
network. I'm trying to figure out why.


___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Trac down?

2016-10-20 Thread Peter Danecek 
Hi all,
I am current not able to reach the trac server. Is this a real issue, or just a 
local problem here?
~petr

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Objection to restoring deprecated Python subports

2016-10-20 Thread Peter Danecek 

> On 18 Oct 2016, at 06:47, Lawrence Velázquez  wrote:
> 
> Fred Wright recently opened several tickets that suggest restoring
> several Python subports that were deprecated and moved to the Python
> graveyard a long time ago.
> 
> https://trac.macports.org/ticket/52636
> https://trac.macports.org/ticket/52637
> https://trac.macports.org/ticket/52638
> https://trac.macports.org/ticket/52639
> https://trac.macports.org/ticket/52640
> https://trac.macports.org/ticket/52641
> https://trac.macports.org/ticket/52642
> 
> I strenuously object to these proposals.
> 

+1

I think we most arguments were already expressed. There policy on this was 
proposed already some years back and largely agreed on. I do not see why his 
should now change again. 

There is also a fundamental reason not to support python26: We usually support 
only one version per module and often with updates upstream drops support, so 
we had to remove support as well if we do not want to generate too much 
maintenance overhead (multiple version conditions etc.). This however might 
cause python ports loosing their dependencies and create mess, broken ports, 
tickets, etc.

> A few years ago, I proposed a Python subport/variant policy to reduce
> project-wide support load. That policy was that we should only provide
> subports for the two most recent Python versions on each of the 2.x and
> 3.x branches (modulo some details about termination of upstream
> support).

However, I think in the current situation there is a good point in support the 
following *three* versions py27, py34 **and** py35. Supporting two Py3 versions 
does not seem to creates much maintenance overhead and it gives and the users 
do a “rolling” update. I guess once py26 subports have all be removed and we 
have a decent set of py36 subparts added, we probably have set a policy wrt. 
py34.


> Thanks to the efforts of many contributors, that proposal has been
> mostly carried out. We absolutely should not be going backwards on this.
> 
> Users who wish to work with unsupported versions of Python should use
> virtualenv to create a contained environment in which they may use the
> bundled pip, setuptools, and wheel to install any modules they please.
> The deprecated subports would have to be restored to the virtualenv and
> setuptools ports; I'd be fine with this.

On the other hand, there is a good reason to keep also older interpreters (e.g. 
python26, python33) around exactly for this reason. This gives users a quite 
immediate possibility to setup a (set of) virtualenv and multiple Python 
packages version for testing.

~petr


___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [154081] trunk/dports/textproc/extractopinion/Portfile

2016-10-20 Thread Mojca Miklavec 
On 20 October 2016 at 04:42, Joshua Root  wrote:
> On 2016-10-20 13:23 , Ryan Schmidt wrote:
>>
>>
>>> On Oct 19, 2016, at 9:04 PM, mo...@macports.org wrote:
>>>
>>> Revision
>>> 154081
>>> Author
>>> mo...@macports.org
>>> Date
>>> 2016-10-19 19:04:20 -0700 (Wed, 19 Oct 2016)
>>> Log Message
>>>
>>> extractopinion: switch to perl5.24 (#52081)
>>> Modified Paths
>>>
>>> • trunk/dports/textproc/extractopinion/Portfile
>>
>>
>>> @@ -29,7 +29,7 @@
>>>  depends_lib port:crfpp \
>>>  port:libiconv \
>>>  port:gawk \
>>> -port:p5.22-text-csv_xs \
>>> +port:p5.24-text-csv_xs \
>>>  port:juman6 \
>>>  port:knp3
>>
>>
>> This only changes the dependency but doesn't tell the build system to use
>> it. That needs to be done in patch-perl.diff. (We've actually forgotten to
>> change this every time since perl5.12.)
>
> Probably a good reason to use a placeholder string in the patch file and
> then reinplace it with the actual version-specific string in the portfile.

I agree. But then again this might also be a good reason to ask
ourselves whether we have any users of this software at all. Not even
the patch phase succeeds and there were apparently no complaints about
a broken port for years. (Unless the users gave up too soon and didn't
know how to file a bug report.)

Mojca
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: foo-snapshot / foo-diff convenience functions

2016-10-20 Thread René J . V . Bertin 
On Wednesday October 19 2016 21:44:04 Ryan Schmidt wrote:

>No, that situation should not be common, nor indeed present at all.

I'm not sure I agree. PortGroups are intended to take care of setting up things 
for the ports that use them (like declaring a dependency in such a way ports 
work with the main as well as the -devel port), and even an official one like 
the github PG adds dependency info. Ditto for the Python PG: you cannot (to my 
knowledge) include it just to obtain the variables that provide the python 
paths without also redefining the configure mechanism.

You could claim that it should be uncommon that ports want only part of the 
info a PG provides, but even that might not be relevant as I think there are 
quite a few ports providing Python extensions but that don't use Python's own 
configure/build/install mechanism (PyQt and PyKDE come to mind).

>> For instance, a port providing translation files for a KDE port would 
>> probably need to include a KDE PortGroup but doesn't need to depend on Qt.
>
>I haven't looked at the kde portgroup specifically. Maybe the portgroup needs 
>additional options to handle different types of ports (e.g. libraries vs. 
>translation files), or maybe there need to be separate portgroup.

Well, that's indeed what I've ended up doing with KF5, but there it's justified 
because of the sheer number of dependency variables (over 30 frameworks). The 
Qt PGs on the other hand define a considerable number of relevant variables but 
also add a single dependency to depends_lib. I don't think it's really 
justified to put just that in a separate PG. For that I'd rather add a switch 
to the PG, a variable to define before including it in order to deactivate 
something.

Maybe it would be possible to make that latter approach a bit more elegant, 
somehow merging those variable declarations into the PortGroup syntax?

R.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Dependencies that depend on installed ports/variants

2016-10-20 Thread Mojca Miklavec 
Hi,

Trac seems to be down for me at the moment.

I switched most of the ports to perl5.24, but there are some ports like
- cpuid
- docbook-utils
- pcsc-tools

that do just
PortGroup   perl5 1.0
depends_build   port:p${perl5.major}-foo
without specifying the perl version to use anywhere.

In theory this sounds nice – no changes (other than revbump) needed
when the perl version changes. On the other hand the user may have a
different version of perl variant installed locally than what's the
current default in our repository and the revbump might not always
correspond to the time when the variant is changed on the user's
machine.

So a question: should I just revmubp these ports or should we specify
the version of
perl that should be used for dependencies?

Apart from that: are there any objections to removal of the +perl5_22
variant from perl5?

Mojca
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [MacPorts] #52663: libcxxabi patch to update to 3.9.0

2016-10-20 Thread Ken Cunningham 
easy to do -- already have it done, actually, for my own testing. Up to
Jeremy, of course.

On Wed, Oct 19, 2016 at 7:27 PM, MacPorts  wrote:

> #52663: libcxxabi patch to update to 3.9.0
> --+
>   Reporter:  ken.cunningham.webuse@…  |  Owner:  jeremyhu@…
>   Type:  submission   | Status:  new
>   Priority:  Normal   |  Milestone:
>  Component:  ports|Version:  2.3.4
> Resolution:   |   Keywords:  haspatch
>   Port:  libcxxabi|
> --+
>
> Comment (by larryv@…):
>
>  I think the LLVM project clearly has a preference for CMake at this point.
>  We should probably switch to it for this port as we already have for the
>  LLVM ports.
>
> --
> Ticket URL: 
> MacPorts 
> Ports system for the Mac operating system
>
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev