Promote octave-devel to octave?

octave is at 3.2.4 while octave-devel is at 3.6.4.  Any reason not to 
copy octave-devel to octave and do work on octave until the next major 
version of octave comes out?

Blair

MacPorts Lion buildbot is stuck

Tonight it is the Lion buildbot that's stuck deploying archives:

(view as text)
./deploy_archives.sh archive_staging-buildports-lion-x86_64

** RUNNING ON BUILDMASTER **
 in dir /var/buildbot
 argv: ['./deploy_archives.sh', 'archive_staging-buildports-lion-x86_64']

Putting my Mac to sleep wedged my Installer package scripts

<div><div dir="ltr">
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>Hi,<br><br>
</div>I'm trying to install MacPorts 2.1.3 on my Retina Display MacBook Pro, Model Identifier MacBookPro10,1, running Mac OS X 10.8.3.<br><br>
</div>When the Installer was running the package scripts, and reporting that it had five minutes left, I had to catch a bus so I put the unit to sleep, then closed the lid.<br><br>
</div>When I opened it, the Installer reported that it had seven minutes left.&nbsp; I let the installer run quite a lot longer than seven minutes, but the estimated time left steadily grew to seventeen minutes without any advancement of the progress bar.<br><br>
</div>Finally I used Command-Option-Escape to kill the process, but when I try to run the installer again, it tells me that it's waiting for a previous installation to complete.&nbsp; I killed the process again, then tried to restart, but OS X won't let me.&nbsp; Instead it displays a window that says I have to wait until the installation completes.&nbsp; It still says Running Package Scripts, but does not display a time estimate.<br><br>
</div>I can force a shutdown by holding down the power key, but am concerned that I may have left my system in an unstable state.<br><br>
</div>I'm happy to file a bug report if you like, but I seek your advice as to how to get installed.<br><br>
</div>Keep up the good work!<br><br>
</div>Mike<br clear="all"><div><div><div><div>
<div><div><div><div><div><div>
<br>-- <br>Michael David Crawford<br>mdcrawford at gmail dot com<br><br>
</div></div></div></div></div></div>
</div></div></div></div>
</div></div>

no response to ticket #8901

<div>
<p>Hello,</p>
<div><br></div>
<div>There has been no response in 2 months from maintainer <a href="mailto:fabian.renn@...">fabian.renn@...</a> to ticket #8901 which I filed about port libxc. Can the patch I submitted there please be reviewed and committed? These are minor issues, but it doesn't look like the maintainer is active anymore.</div>
<div><br></div>
<div>Thanks,</div>
<div>David<br><div><br></div>
<div><br></div>
</div>
</div>

Ticket #39006 - OpenSceneGraph

<div><div dir="ltr">Hi,<div><br></div>
<div>Would it be possible for someone to submit ticket number 39006, please?</div>
<div><br></div>
<div>
<a href="http://trac.macports.org/ticket/39006">http://trac.macports.org/ticket/39006</a><br>
</div>
<div><br></div>
<div>Thanks</div>
<div>Eduardo</div>
<div><br></div>
</div></div>

PyPy buildbot times out

<div><p>I have a patch to fix pypy Using The Right Compiler but noticed that the buildbot was failing with a timeout error. Is there any way to increase the timeout for pypy?<span></span></p></div>

Deprecated options (option_deprecate) in variants and other standard code blocks

I'm hoping some other developers who have a good understanding of MacPorts base can help me. I'm trying to
understand some strange behavior of the "option_deprecate" procedure which I think is a bug.

First, some background for those who may not be as familiar with MacPorts base. An "option" in
MacPorts—such as "depends_lib" or "configure.args"—is a variable that can be set or overwritten
without using the "set" command, that can behave as a list, that can have items appended or deleted or
replaced using the special -append, -delete or -replace modifiers, and that supports lazy/late
evaluation. And options can have variable traces attached to them using "option_proc" so that a
particular procedure runs whenever an option is accessed or changed or deleted.

Options are also automatically global within standard portfile code blocks, like "build {}" or
"pre-destroot {}" or "variant {}", meaning that you can just use any option without having to first
indicate that it's a global variable. This magic occurs because standard code blocks get run through
"makeuserproc" when they're created, which automatically runs "global" on all available globals at the
beginning of each such code block:

https://trac.macports.org/browser/trunk/base/src/port1.0/portutil.tcl?rev=105002#L1247

However in your own non-standard code blocks, i.e. procedures defined directly using "proc", you do have
to first use "global" for any options you want to use, and we see this in procedures in MacPorts base too.

"option_deprecate" is not used in MacPorts right at this very moment, but it has been used before at times
when we've renamed options. For example, "livecheck.type" used to be called "livecheck.check", so for
awhile, MacPorts base used "option_deprecate livecheck.check livecheck.type" so that any ports using
"livecheck.check" would still work until maintainers got around to updating their ports.
"option_deprecate" works by creating an option with the old name and attaching a variable trace to it
using "option_proc" so that whenever the old option is read from or written to, that action is intercepted
and redirected to the new option:

https://trac.macports.org/browser/trunk/base/src/port1.0/portutil.tcl?rev=105002#L260

But this doesn't appear to work right when a deprecated option is used inside a code block.

Here's a sample portfile that works—it correctly shows that both "livecheck.type" and
"livecheck.check" have the value "default":

PortSystem 1.0
name test1
version 1.0
option_deprecate livecheck.check livecheck.type
ui_msg "livecheck.type=${livecheck.type}"
ui_msg "livecheck.check=${livecheck.check}"

But this next sample portfile doesn't work—after printing "livecheck.type=default", it says "can't
read 'livecheck.check': no such variable":

PortSystem 1.0
name test2
version 1.0
option_deprecate livecheck.check livecheck.type
variant foo {
    ui_msg "livecheck.type=${livecheck.type}"
    ui_msg "livecheck.check=${livecheck.check}"
}
default_variants +foo

Obviously you wouldn't actually use "option_deprecate" inside a portfile; these samples are just to
illustrate that if an option is deprecated, then it doesn't work right inside a code block.

It works if I add "global livecheck.check" inside the code block:

PortSystem 1.0
name test3
version 1.0
option_deprecate livecheck.check livecheck.type
variant foo {
    global livecheck.check
    ui_msg "livecheck.type=${livecheck.type}"
    ui_msg "livecheck.check=${livecheck.check}"
}
default_variants +foo

But this shouldn't be necessary because options are supposed to be automatically global, so I'm trying to
understand how to fix this. I would like deprecated options to behave identically to supported options.

Re: [106142] trunk/dports/python/py-sqlalchemy/Portfile

On May 17, 2013, at 03:23, Andrew Stromnov wrote:

> On May 17, 2013, at 03:56 , Ryan Schmidt wrote:
> 
>> On May 16, 2013, at 06:03, stromnov@... wrote:
>> 
>>> Revision: 106142
>> 
>> This revision *downgrades* py24-sqlalchemy from 0.8.0 to 0.7.10. Users will not be prompted to perform
this downgrade unless you increase the epoch of py24-sqlalchemy.
> 
> Is it Ok to set epoch only in py24 subport?

Yes, that's what I'd recommend, since the other subports don't need it yet.

MacPorts 10.6 buildbot is stuck (eom)

Permissive licenses

Hello,

For porting packages with the following licenses

http://code.google.com/p/mplh5canvas/source/browse/trunk/LICENSE.txt
http://code.google.com/p/pywebsocket/source/browse/trunk/src/COPYING

are these considered 'Permissive', i.e., is 'license Permissive' appropriate in Portfiles for these two
packages? The key terms are:

Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions are
met:

* Redistributions of source code must retain the above copyright
notice, this list of conditions and the following disclaimer.
* Redistributions in binary form must reproduce the above
copyright notice, this list of conditions and the following disclaimer
in the documentation and/or other materials provided with the
distribution.
* Neither the name of <insert company name here> nor the names of its
contributors may be used to endorse or promote products derived from
this software without specific prior written permission.

THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
"AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

Thanks,
Leo Singer
Graduate Student  <at>  LIGO-Caltech

python27: Different python27 binaries

Hi,

I am trying to create a new Portfile (attached) for a python script (namely
https://sourceforge.net/projects/cif2cell/ ). In principle, everything goes well, not much to do,
it's just that the script does not work as intended. If however, I run the cif2cell file included in the
tar.gz-Archive, everything works fine. The only difference I could find between the cif2cell script
included in the tar.gz and the one generated by the python setup.py sequence run by the mac ports build
command is in the very first line. The original script reads

#!/usr/bin/env python

while the newly generated one reads

#!/opt/local/Library/Frameworks/Python.framework/Versions/2.7/Resources/Python.app/Contents/MacOS/Python

On my system /usr/bin/env python evaluates (via multiple soft links) to
/opt/local/Library/Frameworks/Python.framework/Versions/2.7/bin/python2.7 both this file and
the other file are binaries created by the mac port python27. I can see the binaries are different.

I now have two questions: 
* What is the difference between those two python binaries?
* How can I modify the Portfile to get the script to use the other one instead?

Thanks,

Peter

Hi,

I am trying to create a new Portfile (attached) for a python script (namely
https://sourceforge.net/projects/cif2cell/ ). In principle, everything goes well, not much to do,
it's just that the script does not work as intended. If however, I run the cif2cell file included in the
tar.gz-Archive, everything works fine. The only difference I could find between the cif2cell script
included in the tar.gz and the one generated by the python setup.py sequence run by the mac ports build
command is in the very first line. The original script reads

#!/usr/bin/env python

while the newly generated one reads

#!/opt/local/Library/Frameworks/Python.framework/Versions/2.7/Resources/Python.app/Contents/MacOS/Python

On my system /usr/bin/env python evaluates (via multiple soft links) to
/opt/local/Library/Frameworks/Python.framework/Versions/2.7/bin/python2.7 both this file and
the other file are binaries created by the mac port python27. I can see the binaries are different.

I now have two questions: 
* What is the difference between those two python binaries?
* How can I modify the Portfile to get the script to use the other one instead?

Thanks,

Peter