Re: [144607] trunk/dports/science/octopus/Portfile

2016-01-14 Thread David Strubbe 
Ok, thanks for the explanation. And the fix to my logic in the Portfile.

David

On Thu, Jan 14, 2016 at 8:14 AM, Ryan Schmidt 
wrote:

>
> On Jan 13, 2016, at 11:53 AM, David Strubbe wrote:
>
> > Oh ok. I have seen some ports have a revision increased recently because
> of a change of default variants, so I was following that, but I guess they
> shouldn't have been.
>
> It varies. You just need to ask yourself: will this change result in a
> change* in the files installed on the system of a user who already has this
> port installed? If yes, increase the revision. If no, don't increase the
> revision.
>
>
> * Perhaps I should say "significant change". Yes, any change in the
> Portfile results in a change in the files that would be installed on the
> user system, in that the Portfile itself is installed onto the user system.
> But I would ignore that for insignificant changes to the Portfile, such as
> whitespace changes or syntax changes that don't result in functional
> changes.
>
>
> Take the example of a port that does not support X11. (It uses
> configure.args --without-x11.) You now want to offer X11 support in a
> variant and, by MacPorts convention, you want to enable it by default. You
> add to the port something like this:
>
> variant x11 {
> configure.args-replace --without-x11 --with-x11
> depends_lib-appen port:xorg-libX11
> }
>
> default_variants +x11
>
> This will result in a change in the files installed on the user system:
> before, they had a program that did not support X11, and after rebuilding,
> they will have a program that does support X11. So the revision of that
> port should be increased when that change is made.
>
>
> That's not the situation in octopus. In octopus you have three variants
> which are mutually exclusive and one of them was the default. Note that the
> previous default was only selected if another option had not already been
> selected by the user. That's what the if statement (which I corrected in
> r144637) does. And know that variants (regardless whether the user selected
> them explicitly or whether they were a default variant at the time the user
> installed the port) are preserved on upgrades. So changing the default
> amongst a set of variants where it is required for the user to select one
> of the variants cannot result in a change to the files on the user's
> system, so the revision should not be increased when the default is changed.
>
>
> If you notice that a port would optionally use a dependency, when you add
> the dependency to the port, you increase the revision, because it would
> result in a change of functionality for those users who did not already
> happen to have that dependency installed (which includes all users who
> received a binary from the buildbot).
>
>
> If you notice a port that is missing a required dependency, the port would
> fail to build for users who did not happen to already have the dependency
> installed, which would include the buildbot. For any users who happened to
> already have the dependency installed, they might not know that the port
> has that dependency, and MacPorts would not prevent them from uninstalling
> the dependency, which would break the port. Therefore, when you add the
> dependency to the port, you still increase the revision, so that the port's
> dependencies are correctly recorded in the registry and MacPorts correctly
> prevents their uninstallation.
>
>
> If a port has a custom pre-activate, post-activate, pre-deactivate or
> post-deactivate block, and significant changes in those blocks require a
> revision increase, because MacPorts runs those blocks from the copy of the
> Portfile that was installed on the user system, not the current version of
> the Portfile in the ports tree.
>
>
> Just a few examples of situations to consider.
>
>
>
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Accessing individual logs of failures on the buildbot

2016-01-14 Thread Mojca Miklavec 
Hi,

This is probably not possible at the moment, but maybe there's some
feasible way to implement it?

On:

https://build.macports.org/builders/buildports-snowleopard-x86_64/builds/39756/steps/cleanup/logs/stdio

one can see the following:

./logs-20160113-111820/fail/p5-gimp.log
./logs-20160113-111820/fail/p5-musicbrainz-discid.log
./logs-20160113-111820/fail/p5-nkf.log
./logs-20160113-111820/fail/p5-opengl.log
./logs-20160113-111820/fail/p5-sdl_perl.log
./logs-20160113-111820/fail/p5-text-chasen.log
./logs-20160113-111820/fail/p5-text-kakasi.log
./logs-20160113-111820/fail/p5-www-wolframalpha.log
./logs-20160113-111820/fail/p5.22-gimp.log
./logs-20160113-111820/fail/p5.22-opengl.log
./logs-20160113-111820/fail/p5.22-sdl_perl.log
./logs-20160113-111820/fail/p5.22-text-kakasi.log
./logs-20160113-111820/fail

Is there any way to access these individual files as opposed to having
to download and inspect the complete 2.5 GB log file?

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

Re: [144607] trunk/dports/science/octopus/Portfile

2016-01-14 Thread Ryan Schmidt 

On Jan 13, 2016, at 11:53 AM, David Strubbe wrote:

> Oh ok. I have seen some ports have a revision increased recently because of a 
> change of default variants, so I was following that, but I guess they 
> shouldn't have been.

It varies. You just need to ask yourself: will this change result in a change* 
in the files installed on the system of a user who already has this port 
installed? If yes, increase the revision. If no, don't increase the revision.


* Perhaps I should say "significant change". Yes, any change in the Portfile 
results in a change in the files that would be installed on the user system, in 
that the Portfile itself is installed onto the user system. But I would ignore 
that for insignificant changes to the Portfile, such as whitespace changes or 
syntax changes that don't result in functional changes.


Take the example of a port that does not support X11. (It uses configure.args 
--without-x11.) You now want to offer X11 support in a variant and, by MacPorts 
convention, you want to enable it by default. You add to the port something 
like this:

variant x11 {
configure.args-replace --without-x11 --with-x11
depends_lib-appen port:xorg-libX11
}

default_variants +x11

This will result in a change in the files installed on the user system: before, 
they had a program that did not support X11, and after rebuilding, they will 
have a program that does support X11. So the revision of that port should be 
increased when that change is made.


That's not the situation in octopus. In octopus you have three variants which 
are mutually exclusive and one of them was the default. Note that the previous 
default was only selected if another option had not already been selected by 
the user. That's what the if statement (which I corrected in r144637) does. And 
know that variants (regardless whether the user selected them explicitly or 
whether they were a default variant at the time the user installed the port) 
are preserved on upgrades. So changing the default amongst a set of variants 
where it is required for the user to select one of the variants cannot result 
in a change to the files on the user's system, so the revision should not be 
increased when the default is changed.


If you notice that a port would optionally use a dependency, when you add the 
dependency to the port, you increase the revision, because it would result in a 
change of functionality for those users who did not already happen to have that 
dependency installed (which includes all users who received a binary from the 
buildbot).


If you notice a port that is missing a required dependency, the port would fail 
to build for users who did not happen to already have the dependency installed, 
which would include the buildbot. For any users who happened to already have 
the dependency installed, they might not know that the port has that 
dependency, and MacPorts would not prevent them from uninstalling the 
dependency, which would break the port. Therefore, when you add the dependency 
to the port, you still increase the revision, so that the port's dependencies 
are correctly recorded in the registry and MacPorts correctly prevents their 
uninstallation.


If a port has a custom pre-activate, post-activate, pre-deactivate or 
post-deactivate block, and significant changes in those blocks require a 
revision increase, because MacPorts runs those blocks from the copy of the 
Portfile that was installed on the user system, not the current version of the 
Portfile in the ports tree.


Just a few examples of situations to consider.


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

Re: r143478 -- gsl: update version 2.0->2.1

2016-01-14 Thread Takeshi Enomoto 
Dear David,

Thank you for letting me know.
OK, let’s wait a few days to see if we need gsl116 or not.

Regards,

Takeshi
-
Takeshi Enomoto
take...@macports.org

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

Re: Accessing individual logs of failures on the buildbot

2016-01-14 Thread Ryan Schmidt 

On Jan 14, 2016, at 6:29 AM, Mojca Miklavec wrote:

> This is probably not possible at the moment, but maybe there's some
> feasible way to implement it?
> 
> On:
> 
> https://build.macports.org/builders/buildports-snowleopard-x86_64/builds/39756/steps/cleanup/logs/stdio
> 
> one can see the following:
> 
> ./logs-20160113-111820/fail/p5-gimp.log
> ./logs-20160113-111820/fail/p5-musicbrainz-discid.log
> ./logs-20160113-111820/fail/p5-nkf.log
> ./logs-20160113-111820/fail/p5-opengl.log
> ./logs-20160113-111820/fail/p5-sdl_perl.log
> ./logs-20160113-111820/fail/p5-text-chasen.log
> ./logs-20160113-111820/fail/p5-text-kakasi.log
> ./logs-20160113-111820/fail/p5-www-wolframalpha.log
> ./logs-20160113-111820/fail/p5.22-gimp.log
> ./logs-20160113-111820/fail/p5.22-opengl.log
> ./logs-20160113-111820/fail/p5.22-sdl_perl.log
> ./logs-20160113-111820/fail/p5.22-text-kakasi.log
> ./logs-20160113-111820/fail

I assume that's a list of files that were deleted by the cleanup operation.


> Is there any way to access these individual files as opposed to having
> to download and inspect the complete 2.5 GB log file?

I don't think anything is saved from a build run except for the complete logs 
of each step, and those only for a time.


I would probably suggest forcing a new build of some or all of the ports that 
failed, then getting that smaller log file.


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

Re: [144621] trunk/dports/python/py-numpy/Portfile

2016-01-14 Thread Michael Dickens 
On Thu, Jan 14, 2016, at 02:43 AM, Joshua Root wrote:
> > Revision: 144621
> >   https://trac.macports.org/changeset/144621
> > Author:   sean at macports.org
> > Date: 2016-01-13 23:29:24 -0800 (Wed, 13 Jan 2016)
> > Log Message:
> > ---
> > py-numpy: numpy needs fortran, so require it
> 
> We've been through this before; numpy does not need fortran, its fortran 
> support is optional.

Well ... not exactly; or, not clear to me. With the prior NumPy, if you
do:

{{{
/opt/local/bin/python2.7 -c "import numpy; numpy.test()"
}}}

then it goes through it's various tests & eventually errors out with:

{{{
==
FAIL: test_scripts.test_f2py
--
Traceback (most recent call last):
  File
  
"/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/nose/case.py",
  line 197, in runTest
self.test(*self.arg)
  File
  
"/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/testing/decorators.py",
  line 146, in skipper_func
return f(*args, **kwargs)
  File
  
"/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/tests/test_scripts.py",
  line 82, in test_f2py
assert_(success, "Warning: neither %s nor %s found in path" %
f2py_cmds)
  File
  
"/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/testing/utils.py",
  line 53, in assert_
raise AssertionError(smsg)
AssertionError: Warning: neither f2py nor f2py found in path

--
Ran 5576 tests in 86.597s

FAILED (KNOWNFAIL=3, SKIP=9, failures=1)
}}}

I don't know where "f2py" is created, but it seems likely that it's
by/within NumPy. I get the same result whether I use the "old" NumPy
(before this change), or the "new" one. Whether with +gfortran or
without. Although f2py does not itself require a Fortran compiler, I'd
bet that once the conversion is done a Fortran compiler is used to
compile the code -- and, hence, Fortran really is required.

That said, I haven't tried to track down where this issue actually lies.
I think there's a ticket on this matter, too. HTH. - MLD
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [144621] trunk/dports/python/py-numpy/Portfile

2016-01-14 Thread Joshua Root 
On 2016-1-15 05:51 , Sean Farley wrote:
> 
> Joshua Root  writes:
> 
>>> Revision: 144621
>>>   https://trac.macports.org/changeset/144621
>>> Author:   sean at macports.org
>>> Date: 2016-01-13 23:29:24 -0800 (Wed, 13 Jan 2016)
>>> Log Message:
>>> ---
>>> py-numpy: numpy needs fortran, so require it
>>
>> We've been through this before; numpy does not need fortran, its fortran
>> support is optional.
> 
> No, it is not optional. Trying running 'numpy.test()'. Or try compiling
> with 'atlas +nofortran'. Not having fortran will generate a broken numpy
> library.
> 
> Side note: We should consider getting rid of 'atlas +nofortran'. I
> haven't found a port that depends on atlas but works without fortran.

What you're saying is that to use fortran with numpy you need to enable
its fortran support. Well, yes.

If you're just using, say, pyopengl, then no, you don't need fortran
support.

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

Re: How to find all dependents of go?

2016-01-14 Thread David Evans 
On 1/14/16 3:25 PM, Clemens Lang wrote:
> Hi,
> 
> On Thu, Jan 14, 2016 at 09:28:48PM +0100, Christoph Iserlohn wrote:
>> But
>> $ port dependents go
>> returns
>> go has no dependents.
>> which is clearly wrong. I have several ports depending on go installed, e.g.:
>> $ port installed go-tools
>> The following ports are currently installed:
>>   go-tools @65b5a8eca7a871e7c1d99722e4a43a4a6e32ebe0_0 (active)
>>
>> No luck with port search either:
>> $ port search --exact --depends_lib --depends_build go
>> No match for go found
> 
> Try port echo depends:go.
> 

This is not too useful as it returns a list of ports whose dependencies
have 'go' in their names.  So you get the desired dependents plus ports
that depend on pango, etc.

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

Re: How to find all dependents of go?

2016-01-14 Thread Joshua Root 
On 2016-1-15 10:36 , Daniel J. Luke wrote:
> On Jan 14, 2016, at 6:31 PM, David Evans  wrote:
>> On 1/14/16 3:25 PM, Clemens Lang wrote:
>>> Hi,
>>>
>>> On Thu, Jan 14, 2016 at 09:28:48PM +0100, Christoph Iserlohn wrote:
 But
 $ port dependents go
 returns
 go has no dependents.
 which is clearly wrong. I have several ports depending on go installed, 
 e.g.:
 $ port installed go-tools
 The following ports are currently installed:
  go-tools @65b5a8eca7a871e7c1d99722e4a43a4a6e32ebe0_0 (active)

It's only a build dependency, so once go-tools is installed, go is no
longer required.

 No luck with port search either:
 $ port search --exact --depends_lib --depends_build go
 No match for go found
>>>
>>> Try port echo depends:go.
>>>
>>
>> This is not too useful as it returns a list of ports whose dependencies
>> have 'go' in their names.  So you get the desired dependents plus ports
>> that depend on pango, etc.

You can construct a better regex like:

port echo 'depends:\:go(\s|$)'

> port echo dependentof:go 
> 
> or
>  
> port echo rdependentof:go

That queries the registry just like 'port dependents'.

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

Re: How to find all dependents of go?

2016-01-14 Thread Clemens Lang 
Hi,

On Thu, Jan 14, 2016 at 09:28:48PM +0100, Christoph Iserlohn wrote:
> But
> $ port dependents go
> returns
> go has no dependents.
> which is clearly wrong. I have several ports depending on go installed, e.g.:
> $ port installed go-tools
> The following ports are currently installed:
>   go-tools @65b5a8eca7a871e7c1d99722e4a43a4a6e32ebe0_0 (active)
> 
> No luck with port search either:
> $ port search --exact --depends_lib --depends_build go
> No match for go found

Try port echo depends:go.

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

Re: How to find all dependents of go?

2016-01-14 Thread Daniel J. Luke 
On Jan 14, 2016, at 6:31 PM, David Evans  wrote:
> On 1/14/16 3:25 PM, Clemens Lang wrote:
>> Hi,
>> 
>> On Thu, Jan 14, 2016 at 09:28:48PM +0100, Christoph Iserlohn wrote:
>>> But
>>> $ port dependents go
>>> returns
>>> go has no dependents.
>>> which is clearly wrong. I have several ports depending on go installed, 
>>> e.g.:
>>> $ port installed go-tools
>>> The following ports are currently installed:
>>>  go-tools @65b5a8eca7a871e7c1d99722e4a43a4a6e32ebe0_0 (active)
>>> 
>>> No luck with port search either:
>>> $ port search --exact --depends_lib --depends_build go
>>> No match for go found
>> 
>> Try port echo depends:go.
>> 
> 
> This is not too useful as it returns a list of ports whose dependencies
> have 'go' in their names.  So you get the desired dependents plus ports
> that depend on pango, etc.

port echo dependentof:go 

or
 
port echo rdependentof:go

?

-- 
Daniel J. Luke  
 
++ 
| * dl...@geeklair.net * |  

| *-- http://www.geeklair.net -* |  

++ 
|   Opinions expressed are mine and do not necessarily   |  

|  reflect the opinions of my employer.  |  

++





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

How to find all dependents of go?

2016-01-14 Thread Christoph Iserlohn 
Hi,

because of:
https://groups.google.com/forum/#!msg/golang-dev/MEATuOi_ei4/nl8jrt9YEwAJ
i would like to bump the revision of all dependents of go to force a rebuild
with version 1.5.3.

But
$ port dependents go
returns
go has no dependents.
which is clearly wrong. I have several ports depending on go installed, e.g.:
$ port installed go-tools
The following ports are currently installed:
  go-tools @65b5a8eca7a871e7c1d99722e4a43a4a6e32ebe0_0 (active)

No luck with port search either:
$ port search --exact --depends_lib --depends_build go
No match for go found

Any suggestions?

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

Re: [144621] trunk/dports/python/py-numpy/Portfile

2016-01-14 Thread Sean Farley 

Joshua Root  writes:

>> Revision: 144621
>>   https://trac.macports.org/changeset/144621
>> Author:   sean at macports.org
>> Date: 2016-01-13 23:29:24 -0800 (Wed, 13 Jan 2016)
>> Log Message:
>> ---
>> py-numpy: numpy needs fortran, so require it
>
> We've been through this before; numpy does not need fortran, its fortran
> support is optional.

No, it is not optional. Trying running 'numpy.test()'. Or try compiling
with 'atlas +nofortran'. Not having fortran will generate a broken numpy
library.

Side note: We should consider getting rid of 'atlas +nofortran'. I
haven't found a port that depends on atlas but works without fortran.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev