Re: Using python before it is selected?

2012-05-18 Thread Jeremy Lavergne
> So the port I'm working on uses Python and requires a bunch of modules as 
> dependencies.  That's working OK but then my port's configure _uses_ python 
> to test if the dependencies are installed. If this is the first time 
> installing python on a machine, no version of python is 'selected'.  aka ...
> 
>> AT-MBP12:mp WCT$ port select --list python
>> Available versions for python:
>>  none (active)
>>  python25-apple
>>  python26
>>  python26-apple
>>  python27-apple
> 
> It would seem to me that MacPorts ought to 'select' the first version of 
> python when it is installed, no?  In my port, is there a way to test for 
> 'none' and then set the one I want?   I wouldn't change the version out from 
> under the user if they've actually selected one.

Well, if your port is after a specific version the easy way would be check the 
modules with pythonX.Y. You should also lib-depend on this version of python, 
which means it WILL BE AVAILABLE when you build and install.



smime.p7s
Description: S/MIME cryptographic signature
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev


Using python before it is selected?

2012-05-18 Thread Craig Treleaven

Hi:

So the port I'm working on uses Python and requires a bunch of 
modules as dependencies.  That's working OK but then my port's 
configure _uses_ python to test if the dependencies are installed. 
If this is the first time installing python on a machine, no version 
of python is 'selected'.  aka ...



AT-MBP12:mp WCT$ port select --list python
Available versions for python:
none (active)
python25-apple
python26
python26-apple
python27-apple


It would seem to me that MacPorts ought to 'select' the first version 
of python when it is installed, no?  In my port, is there a way to 
test for 'none' and then set the one I want?   I wouldn't change the 
version out from under the user if they've actually selected one.


Craig
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev


Anything else for 2.1.1?

2012-05-18 Thread Joshua Root
I think this about covers it:

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


Re: [93235] trunk/dports/mail/postfix/Portfile

2012-05-18 Thread Bradley Giesbrecht

On May 18, 2012, at 1:59 AM, Joshua Root wrote:

>> Revision: 93235
>>  https://trac.macports.org/changeset/93235
>> Author:   pixilla at macports.org
>> Date: 2012-05-17 22:15:22 -0700 (Thu, 17 May 2012)
>> Log Message:
>> ---
>> mail/postfix:
>> - Add variants for mysql51, mysql55, mariadb and percona.
> 
> This changeset actually consists entirely of formatting changes. Please
> don't do that.

Sorry, this was unintended. Earlier there were changes. In the end the Portfile 
reverted back to original plus formatting.



smime.p7s
Description: S/MIME cryptographic signature
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev


Re: [93257] trunk/dports/aqua/qtoctave-mac

2012-05-18 Thread Andrea D'Amore
On Fri, May 18, 2012 at 4:37 PM, Ryan Schmidt  wrote:
> #33901 says the problem occurs at runtime. That means for users to benefit 
> from this fix you need to increase the revision to encourage a rebuild.

Correct, committed r93263.


Speaking about the issue there are variables 'this' and 'thisValue' in
table.cpp that have the same value in the lower 32 bits, but "this" 's
33rd bit is up.
I suspect this is due thisValue being defined as long while this being
typecasted to long from the class pointer that should be platform
dependent (and 64 bit on modern systems).

Since I had already spent a certain amount of time figuring how to use
gdb with C++ and how to print Qt objects I went with the quickest fix
I could see, but I'd like to hear


-- 
Andrea
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev


Re: [93257] trunk/dports/aqua/qtoctave-mac

2012-05-18 Thread Ryan Schmidt

On May 18, 2012, at 08:16, and.dam...@macports.org wrote:

> Revision: 93257
>  https://trac.macports.org/changeset/93257
> Author:   and.dam...@macports.org
> Date: 2012-05-18 06:16:41 -0700 (Fri, 18 May 2012)
> Log Message:
> ---
> port qtoctave-mac: fix issue #33901, mask left side of a comparison to 32 bit

#33901 says the problem occurs at runtime. That means for users to benefit from 
this fix you need to increase the revision to encourage a rebuild.


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


Re: [enhancement] proposal - make all ports independent of which version of Perl is installed or the major one

2012-05-18 Thread Bjarne D Mathiesen
Lawrence Velázquez wrote:
> On May 18, 2012, at 8:13 a.m., Bjarne D Mathiesen wrote:
> 
>> I really do think we need to find some kind of solution to this problem
>> with having Perl 5.12 hardcoded into 96 (the 92 my scipt finds in my
>> setup + the 4 I've personally converted) ports. Presently, it hinders
>> people in using any other version of Perl unless they are willing to do
>> what I've done : have a local repo with pathces with all of the troubles
>> that can lead to.
> 
> 
> You do know that you can have multiple versions of Perl installed, right? I 
> have both perl5.12 (to satisfy git-core) and perl5.14 installed currently.
> 

I do know that.

But any particular port that needs Perl has to be dependent on a
particular version of Perl5 & p5.xx modules.

To restate my case : At present, it's not possible -without going to
extraordinary messures- to switch any of those 96 ports from Perl 5.12
to Perl 5.14. So basically everyone is stuck on Perl 5.12 as the
situation is today due to the hardcoding of Perl 5.12 into those 96 ports.

So : do we as a group want to find a solution to this situation -or- are
we as a group collectively satisfied with the situation as it is today,
& we leave it up to people to find their own individual solutions to
this problem ???

And git-core seems to work perfectly with Perl 5.14 which is what I've
instructed it to use :-)

I can really not see any valid reason for me to have several versions of
Perl5 installed - unless there's something that breaks for a particular
port when switching from Perl 5.12 to Perl 5.14. & so far I've not seen
any such breakage.

I did find this :
http://perlhacks.com/2011/06/perl-versions/

:-)
-- 
Bjarne D Mathiesen
København N ; Danmark ; Europa
--
denne besked er skrevet i et totalt M$-frit miljø
MacOS X 10.7.3 Lion ; 2.8GHz Intel Core i7 ; 16GB 1067MHz DDR3
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev


Re: [enhancement] proposal - make all ports independent of which version of Perl is installed or the major one

2012-05-18 Thread Lawrence Velázquez
On May 18, 2012, at 8:13 a.m., Bjarne D Mathiesen wrote:

> I really do think we need to find some kind of solution to this problem
> with having Perl 5.12 hardcoded into 96 (the 92 my scipt finds in my
> setup + the 4 I've personally converted) ports. Presently, it hinders
> people in using any other version of Perl unless they are willing to do
> what I've done : have a local repo with pathces with all of the troubles
> that can lead to.


You do know that you can have multiple versions of Perl installed, right? I 
have both perl5.12 (to satisfy git-core) and perl5.14 installed currently.

vq

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


Re: [enhancement] proposal - make all ports independent of which version of Perl is installed or the major one

2012-05-18 Thread Bjarne D Mathiesen
OK - that clarifies what will go wrong in a way so that even I can
understand it ;-)

Lawrence Velázquez wrote:
> On May 17, 2012, at 7:25 p.m., Bjarne D Mathiesen wrote:
> 
>>> Your idea won't work right. If the path to an arbitrary perl is
>>> inserted into any of the files installed by the port, the build is no
>>> longer repeatable.
>>
>> But I'm *not* inserting an arbitrary value of Perl into any file.
>> At configure the variable will be evaluated and turned into a hard value
>> as far as I can tell.
> 
> The build would not be repeatable because it would depend on factors external 
> to the given port -- namely, it would be dependent on whatever perl5 points 
> to at the time you build. (Also, if you don't have perl5 installed at all, it 
> will default to perl5.12 and install it if it's missing, even if you have 
> perl5.14.)

How about if we just don't care that much about breaking this when
people switch to another major version of Perl ???

We must assume -some- intelligence on the part of people that install
Perl & ports that depend on Perl. We do that already in asking them to
configure some ports & moving files around. So how about a warning in
Perl5 that switching Perl5 version will break future re-builds of the
ports they have that depend on a version of Perl5 ??? & telling them
which ports will break upon re-building ???

Otherwise, I do think that we should focus on supporting just one single
version of Perl5. That discussion was brought up earlier in the thread.
For a summary see :
http://lists.macosforge.org/pipermail/macports-dev/2012-May/019270.html

> 
>> As far as I can see, my proposal is no different from what's already
>> working in *all* p5- ports. Try eg :
>> less $(port file p5-acme-lolcat)
> 
> p5-acme-lolcat defines subports, each of which depends on a specific version 
> of Perl. Having subports is not the same as doing a build with whatever Perl 
> happens to be lying around.
> 

I really do think we need to find some kind of solution to this problem
with having Perl 5.12 hardcoded into 96 (the 92 my scipt finds in my
setup + the 4 I've personally converted) ports. Presently, it hinders
people in using any other version of Perl unless they are willing to do
what I've done : have a local repo with pathces with all of the troubles
that can lead to.

-- 
Bjarne D Mathiesen
København N ; Danmark ; Europa
--
denne besked er skrevet i et totalt M$-frit miljø
MacOS X 10.7.3 Lion ; 2.8GHz Intel Core i7 ; 16GB 1067MHz DDR3
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev


Re: xymon-server port wrongly upgrade to older version from 4.3.7 to 4.3.0

2012-05-18 Thread Francois Claire

Yes, that was it indeed.

I removed the old Portfile(s) of my local port repository and could 
upgrade again to 4.3.7.



Thanks a lot for your lightning-speed support Ryan.


Le 18/05/12 11:20, Ryan Schmidt a écrit :

On May 18, 2012, at 04:17, Francois Claire wrote:


I've upgraded macports to v2.1.0 and run a "sudo port upgrade outdated". This 
wrongly upgraded my xymon-server to an older version jumping from 4.3.7 back to 4.3.0:



Any idea why this happened ?

Do you have a local port repository containing this older version?




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


Re: Severe issue with gfortran (from gcc) with binary builds

2012-05-18 Thread Thomas Robitaille
> The Lion buildbot was initially set up with Xcode 4.1 so the Lion packages 
> were initially built with that. The buildbot has since then been updated to 
> Xcode 4.3.2 but no new version/revision of gmp has been committed since then 
> so the package has not been rebuilt on that.
>
> The gmp port contains this block:
>
> # llvm-gcc-4.2 fails make check
> if {${configure.compiler} == "llvm-gcc-4.2"} {
>    if {[vercmp $xcodeversion 4.1] >= 0} {
>        configure.compiler clang
>    } else {
>        configure.compiler gcc-4.2
>    }
> }
>
> Xcode 4.0 and 4.1 default to llvm-gcc-4.2, so this block means on Xcode 4.1 
> the compiler will be changed to clang, and on Xcode 4.0 the compiler will be 
> changed to gcc-4.2.
>
> Note that the block used to read:
>
> # llvm-gcc-4.2 fails make check
> if {${configure.compiler} == "llvm-gcc-4.2"} {
>    configure.compiler clang
> }
>
> But this was changed in r81117 to fix #30294. The version of clang in Xcode 
> 4.0 was too old to even compile the gmp code. Perhaps the version of clang in 
> Xcode 4.1 is new enough to compile the code but not new enough to do so 
> correctly.
>
> If anybody here has Xcode 4.1 installed, or can install Xcode 4.1, they 
> should build gmp from source as is:
>
> sudo port -ns upgrade --force gmp

I only have XCode 4.2 and 4.3, but I can confirm that gmp is
definitely the problematic package, because if I have a clean install
with only binary packages required for gcc45 on MacOS 10.7, then
things don't work, but if I use the above command to force re-install
gmp from source, it works as expected.

Cheers,
Tom
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev


Re: [93246] trunk/dports/devel/glib2/files/patch-configure.diff

2012-05-18 Thread Joshua Root
On 2012-5-18 19:12 , Ryan Schmidt wrote:
> 
> On May 18, 2012, at 04:02, and.dam...@macports.org wrote:
> 
>> Revision: 93246
>>  https://trac.macports.org/changeset/93246
>> Author:   and.dam...@macports.org
>> Date: 2012-05-18 02:02:27 -0700 (Fri, 18 May 2012)
>> Log Message:
>> ---
>> port glib2: BSD readlink doesn't accept -f flag, openmaintainer
> 
> Thanks. I wish developers would fix bugs...
> 
> https://bugzilla.gnome.org/show_bug.cgi?id=640834

You might want to add a comment saying that it's not just the original
reporter seeing the bug, and that it's still present in the current
version. Unconfirmed bugs reports with only one affected user tend to go
to the bottom of the todo list on big projects.

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


Re: xymon-server port wrongly upgrade to older version from 4.3.7 to 4.3.0

2012-05-18 Thread Ryan Schmidt
On May 18, 2012, at 04:17, Francois Claire wrote:

> I've upgraded macports to v2.1.0 and run a "sudo port upgrade outdated". This 
> wrongly upgraded my xymon-server to an older version jumping from 4.3.7 back 
> to 4.3.0:


> Any idea why this happened ?

Do you have a local port repository containing this older version?


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


xymon-server port wrongly upgrade to older version from 4.3.7 to 4.3.0

2012-05-18 Thread Francois Claire

Hi,


I've upgraded macports to v2.1.0 and run a "sudo port upgrade outdated". 
This wrongly upgraded my xymon-server to an older version jumping from 
4.3.7 back to 4.3.0:


--->  Computing dependencies for xymon-server
--->  Fetching archive for xymon-server
--->  Attempting to fetch 
xymon-server-4.3.0_0+snmp.darwin_10.x86_64.tbz2 from 
http://packages.macports.org/xymon-server

--->  Fetching distfiles for xymon-server
--->  Verifying checksum(s) for xymon-server
--->  Extracting xymon-server
--->  Applying patches to xymon-server
--->  Configuring xymon-server
--->  Building xymon-server
--->  Staging xymon-server into destroot
--->  Installing xymon-server @4.3.0_0+snmp
--->  Cleaning xymon-server
--->  Computing dependencies for xymon-server
--->  Deactivating xymon-server @4.3.7_0+snmp
--->  Cleaning xymon-server
--->  Activating xymon-server @4.3.0_0+snmp

*** To complete the Xymon install ***

Run the following commands in your terminal:
  $ sudo echo "kern.sysv.shmmni=64" >> /etc/sysctl.conf
  $ sudo echo "kern.sysv.shmseg=12" >> /etc/sysctl.conf
  $ sudo mv /opt/local/lib/xymon/etc/xymon-apache.conf 
/etc/apache2/[other|sites]/

  $ sudo /usr/sbin/apachectl restart
  $ sudo dscl . -append /Groups/admin GroupMembership _xymon
Reboot your system
Start xymon server:
  $ sudo launchctl load -w 
/Library/LaunchDaemons/org.macports.xymon-server.plist

Open "http://localhost/xymon/"; in your server's browser

Full install instructions here: 
http://trac.macports.org/wiki/howto/SetupXymonServer



--->  Cleaning xymon-server


Any idea why this happened ?


Regards,
Francois.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev


Re: [93246] trunk/dports/devel/glib2/files/patch-configure.diff

2012-05-18 Thread Ryan Schmidt

On May 18, 2012, at 04:02, and.dam...@macports.org wrote:

> Revision: 93246
>  https://trac.macports.org/changeset/93246
> Author:   and.dam...@macports.org
> Date: 2012-05-18 02:02:27 -0700 (Fri, 18 May 2012)
> Log Message:
> ---
> port glib2: BSD readlink doesn't accept -f flag, openmaintainer

Thanks. I wish developers would fix bugs...

https://bugzilla.gnome.org/show_bug.cgi?id=640834


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


Re: [93235] trunk/dports/mail/postfix/Portfile

2012-05-18 Thread Joshua Root
On 2012-5-18 19:01 , Ryan Schmidt wrote:
> 
> On May 18, 2012, at 03:59, Joshua Root wrote:
> 
>>> Revision: 93235
>>>  https://trac.macports.org/changeset/93235
>>> Author:   pixilla at macports.org
>>> Date: 2012-05-17 22:15:22 -0700 (Thu, 17 May 2012)
>>> Log Message:
>>> ---
>>> mail/postfix:
>>> - Add variants for mysql51, mysql55, mariadb and percona.
>>
>> This changeset actually consists entirely of formatting changes. Please
>> don't do that.
> 
> Formatting changes are fine, and should be committed separately from 
> functional changes, but the commit message should describe them as such.

They're fine in your own or nomaintainer ports, or if you run them by
the maintainer first.

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


Re: [93235] trunk/dports/mail/postfix/Portfile

2012-05-18 Thread Ryan Schmidt

On May 18, 2012, at 03:59, Joshua Root wrote:

>> Revision: 93235
>>  https://trac.macports.org/changeset/93235
>> Author:   pixilla at macports.org
>> Date: 2012-05-17 22:15:22 -0700 (Thu, 17 May 2012)
>> Log Message:
>> ---
>> mail/postfix:
>> - Add variants for mysql51, mysql55, mariadb and percona.
> 
> This changeset actually consists entirely of formatting changes. Please
> don't do that.

Formatting changes are fine, and should be committed separately from functional 
changes, but the commit message should describe them as such.



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


[93235] trunk/dports/mail/postfix/Portfile

2012-05-18 Thread Joshua Root
> Revision: 93235
>   https://trac.macports.org/changeset/93235
> Author:   pixilla at macports.org
> Date: 2012-05-17 22:15:22 -0700 (Thu, 17 May 2012)
> Log Message:
> ---
> mail/postfix:
> - Add variants for mysql51, mysql55, mariadb and percona.

This changeset actually consists entirely of formatting changes. Please
don't do that.

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


Re: [enhancement] proposal - make all ports independent of which version of Perl is installed or the major one

2012-05-18 Thread Joshua Root
On 2012-5-18 08:30 , Bjarne D Mathiesen wrote:
> 1) We still need a policy decision as to whether is should be hardcoded
>as now -or- we'll use my proposal that I consider more fully
>developed regarding future releases of Perl

There can be a choice about which version of perl to use, it just needs
to be done via variants.

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