Re: html and postscript viewer

[Ryan Schmidt]

On Mar 30, 2016, at 8:11 PM, Mark Brethen wrote:

> Culculix CGX is setting a default html (firefox) and postscript (gv) viewer. 
> For mac users, they recommend changing ‘gv’ to ‘preview’ but give no 
> recommendation for a browser. I thought I’d ask here whether to keep it 
> firefox or change it to something else? Safari?

OS X lets the user specify their preferred browser. This setting can be changed 
in Safari's preferences window. You should respect that preference.

How does Culculix CGX invoke the web browser? If it does so by running a 
command (such as "firefox" on other platforms), then you can use my openbrowser 
port and the openbrowser command it provides to accomplish that.

If they run a command to invoke a the PostScript viewer, then you would 
probably use "open -a Preview.app" to open Preview.

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

Re: [147186] trunk/dports/net/nmap/Portfile

[Ryan Schmidt]

> On Mar 30, 2016, at 10:10 AM, dl...@macports.org wrote:
> 
> Revision
> 147186
> Author
> dl...@macports.org
> Date
> 2016-03-30 08:10:35 -0700 (Wed, 30 Mar 2016)
> Log Message
> 
> nmap: add a way to build without subversion (fixes #37343), also switched 
> no_* variants to the correct (current) positive style
> Modified Paths
> 
>   • trunk/dports/net/nmap/Portfile

> @@ -32,20 +33,17 @@
>   sha256  
> 58cf8896d09057d1c3533f430c06b22791d0227ebbb93dede2ccb73693ed4b4b
>  
>  depends_lib  port:libpcap \
> - path:lib/libssl.dylib:openssl \
> - port:pcre \
>   port:zlib \
>   port:apr \
> - port:subversion
>  
>  use_bzip2yes
>  
>  configure.args   --without-zenmap --without-ndiff \
>   --mandir=\\\${prefix}/share/man \
>   --infodir=\\\${prefix}/share/info \
> - --with-openssl=${prefix} \
> - --with-libpcre=${prefix} \
> - --with-liblua=included
> + --with-liblua=included \
> + --without-subversion
> + 
>  
>  # nmap's configure script in nselib-bin does not respect 
> --with-liblua=included
>  # as with many ports, configure fails if nawk is installed, force use of 
> system awk
> @@ -54,16 +52,23 @@
>  use_parallel_build   no
>  configure.ccache no
>  
> -variant no_ssl   description {build without ssl support} {
> - configure.args-delete --with-openssl=${prefix}
> - depends_lib-delete path:lib/libssl.dylib:openssl
> +default_variants +ssl +pcre +subversion
> +
> +variant ssl description {build with ssl support} {
> + configure.args-append --with-openssl=${prefix}
> + depends_lib-append path:lib/libssl.dylib:openssl
>   }
>  
> -variant no_pcre  description {build without pcre support} {
> - configure.args-delete --with-pcre=${prefix}
> - depends_lib-delete port:pcre
> +variant pcre description {build with pcre support} {
> + configure.args-append --with-pcre=${prefix}
> + depends_lib-append port:pcre
>   }
>  
> +variant subversion description {build with subversion (nmap-update) support} 
> {
> + configure.args-delete --without-subversion
> + depends_lib-append port:subversion
> + }
> +

Switching from negative "no_" variants to positive variants is good, but when 
you do this, you should provide an upgrade path that preserves the user's 
choices. In this case, that means continuing for one year to provide a no_ssl 
variant (which does nothing, other than acting as a flag to indicate that you 
should not set "default_variants +ssl"), and similarly continuing to provide a 
no_pcre variant and not setting "default_variants +pcre" if that variant is 
chosen. For example:

# Can be removed after March 2017
variant no_ssl description {Legacy compatibility variant} {}
if {![variant_isset no_ssl]} {
default_variants +ssl
}
variant no_pcre description {Legacy compatibility variant} {}
if {![variant_isset no_pcre]} {
default_variants +pcre
}


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

Re: Java Version required to be checked.

[Ryan Schmidt]

> On Mar 28, 2016, at 6:22 PM, Abdulrahman Alshammari <a.tu...@hotmail.com> 
> wrote:
> 
>> 
>> On Mar 28, 2016, at 11:54 AM, Ryan Schmidt <ryandes...@macports.org> wrote:
>> 
>> 
>>> On Mar 27, 2016, at 7:14 PM, Abdulrahman Alshammari <a.tu...@hotmail.com> 
>>> wrote:
>>> 
>>> Hey,
>>> 
>>> I am building a porfile of my software. Originally, the software requires 
>>> at least  1.8 Java version. I have found some portfiles in available ports 
>>> section, they use pre-fetch to check if the operation system is at least 
>>> earlier than a certain version. Can I do that for to check for Java 
>>> version? if yes, How can I perform that ?
>> 
>> You can run commands to determine the java version and compare it against 
>> the one you need. You would have to code it in such a way that you also 
>> account for the situation where the user does not have any java version 
>> installed. I do have java installed, so I'm not completely certain this 
>> handles the no-java case correctly, but here's some code I came up with:
>> 
>> 
>>proc javac_version_ok {min_javac_version} {
>>if {![catch {set javac_long_version [exec javac -version 2>@1]}]} {
>>if {[regexp {^javac (.*)$} $javac_long_version -> javac_version]} 
>> {
>>return [expr [vercmp $javac_version $min_javac_version] >= 0]
>>}
>>}
>>return NO;
>>}
>> 
>>proc check_javac_version {} {
>>set min_javac_version 1.8
>>if {![javac_version_ok ${min_javac_version}]} {
>>global name version
>>ui_error "${name} @${version} requires java ${min_javac_version} 
>> or later"
>>return -code error "incompatible java version"
>>}
>>}
>> 
>>pre-archivefetch {
>>check_javac_version
>>}
>> 
>>pre-configure {
>>check_javac_version
>>}
>> 
>> 
>> Here I'm assuming java is required both at build time and at runtime. If 
>> it's only needed at build time, then you should not use the pre-archivefetch 
>> block above.
>> 
> I really appreciate your support. This is helpful. I found a situation 
> similar to this and he add a simple pre-fetch in his portfile. This is what 
> he did:
> 
> re-fetch {
> 
> if {${os.platform} eq "darwin" && ${os.major} > 10} {
> 
>   ui_error "${name} uses deprecated API which has been removed as of Mac OS X 
> 10.7."
> 
> return -code error "incompatible Mac OS X version"
> 
> }
> 
> }
> Can I did that to check just the java version? Instead of OS.version?

There isn't a variable built in to MacPorts that represents the Java version, 
as there is for the OS version. That's why you have to compute the Java version 
yourself, for example using the code I provided.

OS version checks are typically done in pre-fetch, because if a port won't work 
on your OS version, you don't want to waste time downloading a file before 
finding that out, since upgrading the OS is something you may not want or be 
able to do. On the other hand, upgrading Java is simple enough to do, so I 
suggest doing that check in pre-configure (for source builds) and 
pre-archivefetch (for binary installations).



>>> Other question is about file dependencies, Z3 is a theorem prover like 
>>> CVC4. Unfortunately, Z3 is not available as a port. How can I deal with 
>>> this as file dependency? Please let me know if there is an similar example 
>>> to my situation? 
>> 
>> I don't know what Z3 is, but can you add a port for it?
> 
> I can do a port of this tool but I am wondering about the copyright issue. I 
> will search on this situation.




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

Re: Java Version required to be checked.

[Ryan Schmidt]

> On Mar 27, 2016, at 7:14 PM, Abdulrahman Alshammari  
> wrote:
> 
> Hey,
> 
> I am building a porfile of my software. Originally, the software requires at 
> least  1.8 Java version. I have found some portfiles in available ports 
> section, they use pre-fetch to check if the operation system is at least 
> earlier than a certain version. Can I do that for to check for Java version? 
> if yes, How can I perform that ?

You can run commands to determine the java version and compare it against the 
one you need. You would have to code it in such a way that you also account for 
the situation where the user does not have any java version installed. I do 
have java installed, so I'm not completely certain this handles the no-java 
case correctly, but here's some code I came up with:


proc javac_version_ok {min_javac_version} {
if {![catch {set javac_long_version [exec javac -version 2>@1]}]} {
if {[regexp {^javac (.*)$} $javac_long_version -> javac_version]} {
return [expr [vercmp $javac_version $min_javac_version] >= 0]
}
}
return NO;
}

proc check_javac_version {} {
set min_javac_version 1.8
if {![javac_version_ok ${min_javac_version}]} {
global name version
ui_error "${name} @${version} requires java ${min_javac_version} or 
later"
return -code error "incompatible java version"
}
}

pre-archivefetch {
check_javac_version
}

pre-configure {
check_javac_version
}


Here I'm assuming java is required both at build time and at runtime. If it's 
only needed at build time, then you should not use the pre-archivefetch block 
above.


> Other question is about file dependencies, Z3 is a theorem prover like CVC4. 
> Unfortunately, Z3 is not available as a port. How can I deal with this as 
> file dependency? Please let me know if there is an similar example to my 
> situation? 

I don't know what Z3 is, but can you add a port for it?


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

Re: Help needing adapting home-brew formula?

[Ryan Schmidt]

On Mar 26, 2016, at 19:58, Rainer Müller wrote:
> 
>> On 2016-03-27 00:36, André-John Mas wrote:
>> Hi,
>> 
>> I am trying to update the mediainfo port to 0.7.83, though there are
>> changes beyond the
>> version number that need to be made.
>> 
>> Based on suggestion of the application developer I am trying to base the
>> updated Portfile
>> on that recipe, but I am running into some issues. The homebrew file is:
> 
>> [...]
> 
> So far we are using the shell script included in the tarball for these
> steps. I am not sure we are passing all required variables there and it
> is a quite unusual approach.
> 
> I gave it a quick shot and attached an updated Portfile and patch to the
> ticket you created. The resulting binary seems to work for me.
> 
> https://trac.macports.org/ticket/50973
> 
> 
> However, libmediainfo and libzen are actually standalone libraries. When
> done properly, they should go into separate ports. That would also solve
> this problem of running multiple configure/build/destroot steps or using
> this shell script.
> 
> Look for example at the FreeBSD ports...
> 
> https://svnweb.freebsd.org/ports/head/multimedia/mediainfo/Makefile?view=markup
> https://svnweb.freebsd.org/ports/head/multimedia/libmediainfo/Makefile?view=markup
> https://svnweb.freebsd.org/ports/head/multimedia/libzen/Makefile?view=markup
> 
> ...or the ArchLinux packaging:
> 
> https://projects.archlinux.org/svntogit/community.git/tree/trunk/PKGBUILD?h=packages/mediainfo
> https://projects.archlinux.org/svntogit/community.git/tree/trunk/PKGBUILD?h=packages/libmediainfo
> https://projects.archlinux.org/svntogit/community.git/tree/trunk/PKGBUILD?h=packages/libzen
> 
> 
> In my opinion, separate ports would be the better packaging for
> mediainfo, although there will probably be no other dependents for
> libmediainfo or libzen. Nevertheless, this would also remove complexity
> from the Portfiles as they would use the common configure and make targets.
> 
> By setting dist_subdir to the same value in all of these Portfiles, they
> would still share the fetched files to avoid local duplication.

Since they share the same distfile, that makes them good candidates to be 
subports, no?
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [147088] trunk/dports

[Ryan Schmidt]

> On Mar 26, 2016, at 4:44 AM, take...@macports.org wrote:
> 
> Revision
> 147088
> Author
> take...@macports.org
> Date
> 2016-03-26 02:44:32 -0700 (Sat, 26 Mar 2016)
> Log Message
> 
> rev bump ports that depend on netcdf. See #50911


> --- trunk/dports/gis/proj/Portfile2016-03-26 09:36:47 UTC (rev 147087)
> +++ trunk/dports/gis/proj/Portfile2016-03-26 09:44:32 UTC (rev 147088)
> @@ -38,6 +38,10 @@
>  
>  configure.args  --mandir=${prefix}/share/man
>  
> +post-destroot {
> +xinstall -m 644 ${worksrcpath}/src/projects.h 
> ${destroot}${prefix}/include/
> +}
> +
>  livecheck.type  regex
>  livecheck.url   ${master_sites}
>  livecheck.regex "${name}-(\\d+(?:\\.\\d+)*)${extract.suffix}

Was this change made inadvertently? It does not appear to relate to revbumping 
ports that depend on netcdf.

If this is a change you want made, the port's revision should be increased, 
since it changes the files the port installs.


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

Re: multiple distfiles from multiple sources and with multiple compression types

[Ryan Schmidt]

On Mar 25, 2016, at 4:30 PM, René J.V. Bertin wrote:

> On Friday March 25 2016 20:59:47 Ian Rees wrote:
> 
> Hi Ian,
> 
> 
>> for ccs, and a .tgz for spooles.  As far as I could figure out, the fetch
>> step can handle multiple files, but the extract step can not.-Ian-
> 
> That's what I figured would happen indeed.
> 
> A related observation: you can only use one of the use_{zip,bz2,xz,etc} 
> commands once; subsequent calls have no effect.

Don't think of them as commands. Think of them as radio buttons. You're 
indicating which of the available compression format all of the files will use. 
You can only pick one.

> Thus, if all but a handful of the tarballs of a software family use xz 
> compression you cannot put a "use_xz" in the PortGroup and override it with, 
> say, use_bz2 for the few exceptions.

Hmm, that could be considered a bug. I think you work around it by setting 
"use_xz no" as well.


There was some interest expressed at the MacPorts meeting in Slovenia to make 
MacPorts automatically detect compression formats during decompression and thus 
make the "use_xz" etc. options unnecessary. Notably, the tar command in OS X 
10.9 (?) and later already supports automatic compression format detection 
(though we don't use that in MacPorts at this time: we decompress, then pipe 
the decompressed file to tar).


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

Re: Different settings of CMAKE_INSTALL_NAME_DIR & CMAKE_INSTALL_LIBDIR => broken libraries

[Ryan Schmidt]

On Mar 25, 2016, at 8:08 PM, Mojca Miklavec wrote:

> In Geant4 I'm using
>-DCMAKE_INSTALL_LIBDIR=${prefix}/lib/Geant4/Geant${version}
> to allow side-by-side installation of multiple versions of the software.
> 
> However the latest release broke the behaviour and the libraries now
> point to a different path than where they are installed:
> 
>> otool -L /opt/local/lib/Geant4/Geant4.10.2/libG4FR.dylib
> /opt/local/lib/Geant4/Geant4.10.2/libG4FR.dylib:
>/opt/local/lib/libG4FR.dylib
>   [...]
> 
> According to
>http://bugzilla-geant4.kek.jp/show_bug.cgi?id=1848
> this might be a side effect of
>-DCMAKE_INSTALL_NAME_DIR=/opt/local/lib
> which is automatically added by the cmake PortGroup.
> 
> I will do some further testing, but I would be interested in some
> deeper insight into how the system is *supposed to* work. The CMake
> documentation is not too verbose:
> https://cmake.org/cmake/help/v3.5/variable/CMAKE_INSTALL_NAME_DIR.html
> https://cmake.org/cmake/help/v3.5/module/GNUInstallDirs.html
> 
> (I cannot really decide whose fault the broken libraries are. I can
> imagine that I will have to remove or fix the
> -DCMAKE_INSTALL_NAME_DIR=... setting, but if there is something that
> could/should be improved in Geant4 for better
> support, I would like to know.)

As far as I know, yes, -DCMAKE_INSTALL_NAME_DIR=${prefix}/lib from the cmake 
portgroup would be the cause of this, and you should change this in your port 
if you want a different library install location. I admit I'm not familiar with 
-DCMAKE_INSTALL_LIBDIR. It's possible these two settings should always be the 
same? It's possible changes to the cmake portgroup are needed. Maybe it should 
set -DCMAKE_INSTALL_LIBDIR as well. Maybe the cmake portgroup should offer a 
variable for changing both of these cmake flags.

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

Re: MacPorts adding "default" flag to sources.conf

[Ryan Schmidt]

On Mar 23, 2016, at 1:49 PM, Rainer Müller wrote:

> On 2016-03-23 15:10, Mojca Miklavec wrote:
>> In sources.conf I have
>> 
>> file:path/to/sparse/svn/checkout/dports [nosync]
>> file:///path/to/another/svn/checkout/dports [nosync]
>> rsync://rsync.macports.org/release/tarballs/ports.tar [default]
>> 
>> But whenever I configure, make and make install the base from trunk, I
>> end up with "default" being added to the first entry, like this:
>> 
>> file:path/to/sparse/svn/checkout/dports [nosync,default]
>> file:///path/to/another/svn/checkout/dports [nosync]
>> rsync://rsync.macports.org/release/tarballs/ports.tar [default]
>> 
>> and then:
>>Warning: More than one default port source is defined.
>> 
>> What's the reason for that weird behaviour?
> 
> That's some broken logic in the upgrade script. It always adds [default]
> to the first entry that points to the official ports tree if no entry
> before had this flag. We would need multiple passes over the lines to
> first check whether [default] exists already.
> 
> https://trac.macports.org/browser/trunk/base/src/upgrade_sources_conf_default.tcl.in
> 
> Since it has been 7 years after the introduction of this flag, may I
> suggest we just remove it instead of rewriting this script?

You mean, remove the upgrade script? On the assumption that everyone has 
already upgraded and already has a default set at this point? Sure.

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

Re: [146965] trunk/dports/math/octave-database/Portfile

[Ryan Schmidt]

> On Mar 22, 2016, at 10:09 AM, michae...@macports.org wrote:
> 
> Revision
> 146965
> Author
> michae...@macports.org
> Date
> 2016-03-22 08:09:14 -0700 (Tue, 22 Mar 2016)
> Log Message
> 
> octave-database: update to 2.4.1; addresses ticket #50930.
> Modified Paths
> 
>   • trunk/dports/math/octave-database/Portfile
> Diff
> 
> Modified: trunk/dports/math/octave-database/Portfile (146964 => 146965)

>  depends_lib-append  port:octave-struct \
>  port:swig-octave \
> -path:bin/mysql_config5:mysql5 \
> +path:bin/mysql_config:mysql5 \
>  port:sqlite3 \
>  port:unixODBC

This change is not correct and should be reverted. The mysql5 port does not 
provide ${prefix}/bin/mysql_config; it provides ${prefix}/bin/mysql_config5.

Better yet, since the mysql5 port has been obsolete for years, replace this 
dependency with variants to let the user choose which mysql port to use.

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

Re: [146978] trunk/dports/python/py-argh/Portfile

[Ryan Schmidt]

> On Mar 22, 2016, at 1:27 PM, p...@macports.org wrote:
> 
> Revision
> 146978
> Author
> p...@macports.org
> Date
> 2016-03-22 11:27:29 -0700 (Tue, 22 Mar 2016)
> Log Message
> 
> py-argh: fix livecheck, use pypi pattern
> Modified Paths
> 
>   • trunk/dports/python/py-argh/Portfile
> Diff
> 
> Modified: trunk/dports/python/py-argh/Portfile (146977 => 146978)
> 
> --- trunk/dports/python/py-argh/Portfile  2016-03-22 18:27:02 UTC (rev 
> 146977)
> +++ trunk/dports/python/py-argh/Portfile  2016-03-22 18:27:29 UTC (rev 
> 146978)
> @@ -4,8 +4,10 @@
>  PortSystem  1.0
>  PortGroup   python 1.0
>  
> -namepy-argh
> -set real_name   argh
> +set _name   argh
> +set _n  [string index ${_name} 0]
> +
> +namepy-${_name}

Doesn't the python 1.0 portgroup already come with variables you can use for 
this now?

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

Re: [MacPorts] #50913: VLC @2.2.2: error: expected identifier or '('

[Ryan Schmidt]

> On Mar 21, 2016, at 9:09 AM, Dr M J Carter  wrote:
> 
> On Mon, Mar 21, 2016 at 01:39:31PM +, MacPorts wrote:
> 
>> Can you check in vlc_mist_picture.i.10-10 if you do have a definition for
>> _Static_assert.
> 
> {{{
> /* locale.h */
> # 243 "../include/vlc_fixups.h"
> #define _Static_assert(x,s) ((void) sizeof (struct { unsigned a[(x) ? 1 : 
> -1];}))
> #define static_assert _Static_assert
> }}}
> 
>> Or rather, simply try to build after placing the 10.11
>> definition for static_assert (from /usr/include/assert.h) above its first
>> use in picture.c ?
> 
> I doubt that'd work: 10.11 #defines static_assert() in terms of
> _Static_assert(), which I can't find #defined anywhere.  A builtin?
> 
>  That's all for now.  Back to the day job.

This discussion was taking place in the ticket, so you should reply by visiting 
the ticket web page, not by email.


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

Re: [MacPorts] #50907: zsh-completions 0.17.0 version bump

[Ryan Schmidt]

Frank (mf2k) already Cc'd the zsh-completions maintainer Aljaž (g5pw) for you. 
He was just reminding you to do so in the future if you file other tickets. You 
are correct that users cannot change the Cc field after creating a ticket, 
other than to add or remove themselves from Cc by pressing the CcMe button.

> On Mar 17, 2016, at 3:59 PM, Eitan Adler  wrote:
> 
> I tried to CC the maintainer, but was unable to figure out how to do
> (at least one the ticket is created)
> 
> On 17 March 2016 at 06:21, MacPorts  wrote:
>> #50907: zsh-completions 0.17.0 version bump
>> --+
>>  Reporter:  lists@…  |  Owner:  g5pw@…
>>  Type:  update   | Status:  new
>>  Priority:  Normal   |  Milestone:
>> Component:  ports|Version:
>> Resolution:   |   Keywords:
>>  Port:  zsh-completions  |
>> --+
>> Changes (by mf2k@…):
>> 
>> * cc: lists@… (removed)
>> * owner:  macports-tickets@… => g5pw@…
>> * version:  2.3.4 =>
>> * port:  sysutils/zsh-completions => zsh-completions
>> 
>> 
>> Comment:
>> 
>> In the future, please Cc the port maintainers ({{{port info --maintainers
>> zsh-completions}}}), if any. As reporter, you do not need to Cc yourself.
>> 
>> --
>> Ticket URL: 
>> MacPorts 
>> Ports system for OS X


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

Re: Jar File

[Ryan Schmidt]

On Mar 17, 2016, at 4:45 PM, Abdulrahman Alshammari wrote:

> I am almost done from biuilding the portfile and I just need someone to 
> answer my question. my software is simply as jar file.
> Is it required to convert the jar files into DMG extension file ?

No. If the software is distributed as a .jar file, or zip file, or tar.bz2 
file, or any other kind of file, that is the file the port would download from 
the upstream server, and then extract or manipulate in whatever way necessary. 
In the case of a .jar file, presumably no manipulation would be necessary, so 
you would clear "extract.only" and copy the file from distpath to where it 
needs to go inside destroot.

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

Re: [146679] trunk/dports/science/magicspp/Portfile

[Ryan Schmidt]

> On Mar 15, 2016, at 8:06 AM, take...@macports.org wrote:
> 
> Revision
> 146679
> Author
> take...@macports.org
> Date
> 2016-03-15 06:06:27 -0700 (Tue, 15 Mar 2016)
> Log Message
> 
> magicspp: add metview variant
> Modified Paths
> 
>   • trunk/dports/science/magicspp/Portfile
> 

> +variant metview description {Add support for MetView} {
> +depends_lib-append  port:qt4-mac
> +configure.args-append   -DENABLE_METVIEW=ON \
> +
> -DQT_QMAKE_EXECUTABLE=${prefix}/libexec/qt4/bin/qmake
> +}

I think all ports that use qt4-mac are supposed to now use the qt4 1.0 
portgroup to do so. It handles adding the dependency and sets variables you can 
use for the various paths.


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

Re: Apache2 rev bump for OpenSSL update

[Ryan Schmidt]

On Mar 10, 2016, at 2:27 PM, Daniel J. Luke <dl...@geeklair.net> wrote:
> 
> On Mar 10, 2016, at 3:18 PM, Ryan Schmidt <ryandes...@macports.org> wrote:
>>> The general problem is something we should address.
>>> 
>>> (a 'compatibility version' we store for ports and make part of the 
>>> dependency engine? a better 'revbump a bunch of ports tool'? something 
>>> else?)
>>> 
>>> We should have a way to reliably force rebuilds
>> 
>> We do: increase the revision.
>> 
>> If you mean we should have a reliable way to programmatically increase the 
>> revision of a port, maybe,
> 
> reliably programmatically increasing the revision is one possible solution to 
> the actual problem (which is "I need to force any ports that depend on my 
> port to rebuild.")
> 
> Today, we do that by increasing the revision of all affected ports (manually, 
> or with some help from a script).
> 
>> but I'm not sure how to programmatically understand the coding style of a 
>> given portfile.
> 
> It's possible (we load and execute portfiles today).
> 
> It would probably be easier if portfiles more consistently kept to key/value 
> style (or if we didn't use tcl as our parser).

I don't see how we could possibly change away from tcl at this point. If we 
balk at manually examining 300 portfiles to see if they're already been 
revbumped for the openssl update, nobody is going to manually examine 10,000 
portfiles to make them conform to a different parser.


>>>> e.g. the php port is definitely a special case.
>>> 
>>> (and is otherwise problematic since it has us distributing versions of php 
>>> that no longer have upstream support)
>> 
>> I don't consider that a problem.
> 
> distributing software that has known security bugs is a problem.

We'll have to agree to disagree. The unsupported php ports print a message that 
they're unsupported. Someone installing an old php port despite those messages 
must really want that version, for example in order to test and perhaps update 
an old web site designed with that version. Removing the old php subports from 
MacPorts just wastes the user's time as the user is forced to manually locate 
and figure out how to patch and compile the old version.


>> The php web site also still distributes versions of php that they no longer 
>> support. In any case it does not relate to the discussion at hand.
> 
> http://php.net/downloads.php lists 7.0.4, 5.6.19, and 5.5.33 (older releases 
> are still there, but with the disclaimer "listed for archival purposes only").

http://museum.php.net

> We can split the thread if you want to discuss further. You're right that 
> it's only tangentially related (the port would be less complicated if it 
> didn't have to support as many php versions).

Not substantially. Most of the complexity comes from supporting more than one 
version. Supporting more than two versions is no more difficult.

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

Re: Checking for problems before committing

[Ryan Schmidt]

On Mar 10, 2016, at 12:48 AM, Mojca Miklavec wrote:

> On 10 March 2016 at 05:48, Ryan Schmidt wrote:
>> 
>> Obviously nobody is going to commit something they believe is broken, but it 
>> does sometimes end up being the case for some subset of users. When it does, 
>> and we learn that it has happened, we try to fix it. If everybody had to 
>> test everything on a clean system on every version of OS X and every version 
>> of Xcode before committing, nobody would ever commit anything because nobody 
>> has the time and resources to do all that testing. We do have automated 
>> build machines that do build every commit on a clean system with no ports 
>> installed with several versions of OS X and the latest version of Xcode for 
>> those systems. That automated system did catch this webkit2-gtk build 
>> problem on El Capitan,
> 
> 
> When I was testing wxWidgets, discovered a problem and submitted a
> patch, I noticed what they are doing now (which is some light years
> more advanced compared to what they did a few years back when most of
> the tickets were stuck ignored at their Trac; similar to what happens
> in many cases in MacPorts).
> 
> - user submits a patch
> - the system checks whether the patch applies cleanly
> - the system automatically builds wxWidgets on Windows in 6 different
> ways (cygwin, mingw32 with msys, mingw, nmake with VS 14, nmake with
> VS 9, msbuild), on Linux in five different ways (one is with clang
> 3.5), and on OS X 10.9
> - I'm not sure whether wxWidgets does it as well, but it is also
> possible to run tests as part of the build
> 
> The developers then only apply the patch if all of the checks mentioned pass.
> 
> The point is that this is all done *in advance* and avoids a lot of
> problems. I would love to see something similar being done for patches
> submitted to our Trac. Of course they would have to be submitted in a
> different way and I'm aware that this is not really trivial to set up.
> But it would be extremely helpful.

Yes, this would be helpful. I intend to look into doing something like this. 
However right now and for the next several weeks there are a lot of other more 
pressing issues I need to be working on for Mac OS Forge.



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

Re: Why is one compiler on 10.6 able to generate PPC binaries and not the other?

[Ryan Schmidt]

> On Mar 10, 2016, at 1:00 PM, Mojca Miklavec  wrote:
> 
> Hi,
> 
> While following
>https://trac.macports.org/wiki/LibcxxOnOlderSystems#Leopardppc
> on 10.6/x86_64 I tried to install clang 3.7 (thinking that version 3.7
> might have an even better support for PPC than 3.6).
> 
> The problem is that clang-mp-3.7 doesn't want to produce ppc binaries,
> so I wasn't able to install libcxx. I get:
> 
>> clang++-mp-3.7 a.cc -arch ppc
> ld: unknown/unsupported architecture name for: -arch ppc
> clang: error: linker command failed with exit code 1 (use -v to see 
> invocation)
> 
> At the same time clang++-mp-3.4 works fine even though both clang 3.4
> and 3.7 are x86_64 only.
> 
> I'm now trying to rebuild everything as +universal (with ppc included
> in the list of universal architectures) and hope that it will work
> afterwards. But I would be grateful for ideas about why clang 3.4
> would be able to create ppc binaries and clang 3.7 not.
> 
> Thank you,
>   Mojca
> 
> PS: I'm not actually using the PPC, I'm doing this all for fun and as
> a challenge. But I don't have any VM with 10.5, so I wanted to do the
> cross-compiling step on VM with 10.6.

Maybe:

https://trac.macports.org/changeset/129356



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

Re: Apache2 rev bump for OpenSSL update

[Ryan Schmidt]

On Mar 10, 2016, at 2:15 PM, Daniel J. Luke <dl...@geeklair.net> wrote:

> On Mar 10, 2016, at 2:05 PM, Ryan Schmidt <ryandes...@macports.org> wrote:
>>> That's probably safe, but I don't think there is a compelling reason to try 
>>> and only revbump the minimal set of ports (better to have some needless 
>>> rebuilds/downloads of binary archives than to have mysteriously broken 
>>> ports).
>> 
>> You can't programmatically revbump safely,
> 
> with existing tool(s).
> 
>> because in ports with subports you have to manually determine which 
>> subport(s) to revbump and how to do so.
> 
> The general problem is something we should address.
> 
> (a 'compatibility version' we store for ports and make part of the dependency 
> engine? a better 'revbump a bunch of ports tool'? something else?)
> 
> We should have a way to reliably force rebuilds

We do: increase the revision.

If you mean we should have a reliable way to programmatically increase the 
revision of a port, maybe, but I'm not sure how to programmatically understand 
the coding style of a given portfile.


>> e.g. the php port is definitely a special case.
> 
> (and is otherwise problematic since it has us distributing versions of php 
> that no longer have upstream support)

I don't consider that a problem. The php web site also still distributes 
versions of php that they no longer support. In any case it does not relate to 
the discussion at hand.


>> So if you're manually examining all ports that depend on openssl, you can 
>> run an "svn log" on them to see if any commits after r146162 updated the 
>> version or revision.
> 
> ick.

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

Re: port:libclang (and libLLVM)

[Ryan Schmidt]

> On Mar 10, 2016, at 9:26 AM, René J.V. Bertin  wrote:
> 
> On Thursday March 10 2016 10:13:16 Jack Howarth wrote:
> 
>> A simple test with 'sudo port -d -s build llvm-3.8' reveals that -Os
>> is in fact used during the compiles on Intel. This is unsurprising as
>> MacPorts has standardized on -Os.
>> 
>> CFLAGS='-pipe -Os'
>> CXXFLAGS='-pipe -Os -std=c++11 -stdlib=libc++'
>> F90FLAGS='-pipe -Os -m64'
>> FCFLAGS='-pipe -Os -m64'
>> FFLAGS='-pipe -Os'
>> OBJCFLAGS='-pipe -Os'
>> OBJCXXFLAGS='-pipe -Os -stdlib=libc++'
> 
> Did you look at the actual compile commands? Again, cmake is used, and when 
> you generate a makefile with CMAKE_BUILD_TYPE=Release it will *append* the 
> preset compiler options to whatever is fetched from CFLAGS, CXXFLAGS, etc. It 
> is my experience that setting -O3 in CFLAGS or CXXFLAGS has no point, because 
> those presets will override it with -O2 .
> 
> CMake does something similar for all 4 built-in presets, so the only way I 
> know to control the exact compiler flags is to set CMAKE_BUILD_TYPE to a 
> custom value. Debian/Ubuntu do that in their packaging scripts 
> (-DCMAKE_BUILD_TYPE=Debian); I've proposed a modified CMake PortGroup that 
> uses -DCMAKE_BUILD_TYPE=MacPorts (and parses configure.cppflags because CMake 
> doesn't have a dedicated variable for preprocessor options).

If so, that would be yet another bug, or yet another broken-by-design feature, 
of cmake.


> Here's something much more interesting though: I just discovered that llvm 
> and clang 3.8 are both about TEN times smaller than they were in 3.6 and 3.7:
> 
> /opt/local/var/macports/software/llvm-3.6:
> total 158M
> 158M -rw-r--r--1 bertin admin 158M Nov 15 19:10 
> llvm-3.6-3.6.2_2.darwin_13.x86_64.txz
> 
> /opt/local/var/macports/software/llvm-3.7:
> total 188M
> 188M -rw-r--r--1 bertin admin 188M Jan  9 21:11 
> llvm-3.7-3.7.0_0.darwin_13.x86_64.txz
> 
> /opt/local/var/macports/software/llvm-3.8:
> total 15M
> 15M -rw-r--r--1 bertin admin 15M Mar 10 16:08 
> llvm-3.8-3.8-r262722_1.darwin_13.x86_64.txz
> 
> /opt/local/var/macports/software/clang-3.6:
> total 169M
> 169M -rw-r--r--1 bertin admin 169M Nov 15 19:17 
> clang-3.6-3.6.2_2+analyzer.darwin_13.x86_64.txz
> 
> /opt/local/var/macports/software/clang-3.7:
> total 182M
> 182M -rw-r--r--1 bertin admin 182M Jan  9 21:34 
> clang-3.7-3.7.0_2+analyzer.darwin_13.x86_64.txz
> 
> /opt/local/var/macports/software/clang-3.8:
> total 17M
> 17M -rw-r--r--1 bertin admin 17M Mar 10 16:14 
> clang-3.8-3.8-r262722_1+analyzer.darwin_13.x86_64.txz
> 
> 
> What's going on here??
> 
> If that means that building from source also takes comparatively less time 
> and resources I might be inclined to experiment with non-shared builds, or a 
> build without RTTI support (even if that apparently should account for no 
> more than 5% performance loss).

My llvm-3.4 is 436MB, llvm-3.7 765MB. 

I don't know why mine are the size they are and yours are the size they are.

You could untar your llvm-3.7 and llvm-3.7 and compare them to see where the 
size difference lies.

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

Re: Apache2 rev bump for OpenSSL update

[Ryan Schmidt]

On Mar 10, 2016, at 12:04 PM, Daniel J. Luke wrote:
> On Mar 10, 2016, at 12:46 PM, Rainer Müller wrote:
>> On 2016-03-10 16:34, Ryan Schmidt wrote:
>>>> The longer we wait, the harder it will be to catch these.
>>>> Should we rev-bump all dependents of OpenSSL now?
>>> 
>>> Those that haven't already had their version or revision increased since 
>>> the openssl update, yes, I would say. 
>> 
>> That is difficult to determine now. To find that out requires going
>> through the list of dependents manually...
>> 
>> I will assume all ports with commits since the OpenSSL update in r146162
>> either already got a rev-bump or a version upgrade, so they do not need
>> it anymore:
> 
> That's probably safe, but I don't think there is a compelling reason to try 
> and only revbump the minimal set of ports (better to have some needless 
> rebuilds/downloads of binary archives than to have mysteriously broken ports).

You can't programmatically revbump safely, because in ports with subports you 
have to manually determine which subport(s) to revbump and how to do so. e.g. 
the php port is definitely a special case. So if you're manually examining all 
ports that depend on openssl, you can run an "svn log" on them to see if any 
commits after r146162 updated the version or revision.

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

Re: Apache2 rev bump for OpenSSL update

[Ryan Schmidt]

On Mar 10, 2016, at 09:14, Rainer Müller <rai...@macports.org> wrote:
> 
>> On 2016-03-03 02:40, Ryan Schmidt wrote:
>> I consider it the responsibility of the committer who updated the
>> openssl port to the version that changed its library ABI to revbump
>> the ports that link with it, regardless of maintainer status. It
>> should have been done at the same time that openssl was updated of
>> course. I'm not working on it so someone else is welcome to do it.
> 
> I still see related errors such as this one:
> 
> $ sudo gem install
> ERROR:  Loading command: install (LoadError)
>dlopen(/opt/local/lib/ruby2.0/2.0.0/x86_64-darwin14/openssl.bundle, 9):
> Symbol not found: _SSLv2_client_method
>  Referenced from:
> /opt/local/lib/ruby2.0/2.0.0/x86_64-darwin14/openssl.bundle
>  Expected in: /opt/local/lib/libssl.1.0.0.dylib
> in /opt/local/lib/ruby2.0/2.0.0/x86_64-darwin14/openssl.bundle -
> /opt/local/lib/ruby2.0/2.0.0/x86_64-darwin14/openssl.bundle
> ERROR:  While executing gem ... (NoMethodError)
>undefined method `invoke_with_build_args' for nil:NilClass
> 
> 
> The longer we wait, the harder it will be to catch these.
> Should we rev-bump all dependents of OpenSSL now?

Those that haven't already had their version or revision increased since the 
openssl update, yes, I would say. 

> Is it already too late and we fix them case-by-case?

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

Re: [146276] trunk/dports/databases

[Ryan Schmidt]

> On Mar 6, 2016, at 1:22 PM, Mojca Miklavec  wrote:
> 
> On 6 March 2016 at 18:01, Bradley Giesbrecht wrote:
>> 
>> We could remove all ports that depend on mysql4 and mysql5 exclusively or
>> via default variants. The remaining ports would then have their mysql4 or
>> mysql5 variant removed.
>> 
>> The removed ports could be brought back if someone was interested in fixing
>> them.
> 
> That would be a bit harsh, wouldn't it? I bet that a number of ports
> would work with a different database without any additional patches.
> 
> I asked long ago if someone could provide guidelines for transition,
> but nobody did. It's not clear to me what the suggested way is, so
> that we could at least make some consistent changes rather than every
> port switching to a different database with completely different code.
> 
> Mojca

The problem is that Oracle bought MySQL and took it in directions some users 
and developers object to. Therefore, the original developer of MySQL forked it 
and made MariaDB. Some distributions now default to MariaDB, and I would be in 
favor of MacPorts doing that too. But we should use the latest version, which 
is currently 10.1, in the mariadb-10.1 port. Previously we used the port name 
as the variant name, for example +mysql56 to enable mysql56 support. The fact 
that this port name contains a dash and a period is problematic in that dashes 
are not permitted in variant names because that conflicts with the syntax for 
disabling a variant, and the period is not an officially sanctioned character 
to use in a variant name either. Initial tests showed it seemed to work, but 
there are several places in the base code where variant names are validated; 
they all need to be changed to allow a period, if we want to use a period in 
the variant name. Whatever we decide should be applied 
 consistently to all ports, so that they all have the same set of 
MySQL-compatible variants and all default to the same (latest stable) one. Some 
tickets related to these issues:

https://trac.macports.org/ticket/39961

https://trac.macports.org/ticket/43431

https://trac.macports.org/ticket/46807

Bradley, can you add notes to #46807 about what you did so far?

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

Re: PortIndex2MySQL run failure on Sunday 2016-03-06 at 07:00:01

[Ryan Schmidt]

> On Mar 6, 2016, at 12:15 PM, Mojca Miklavec <mo...@macports.org> wrote:
> 
> On 6 March 2016 at 18:44, Ryan Schmidt wrote:
>> Begin forwarded message:
>> 
>> From: macports-...@lists.macosforge.org
>> Subject: PortIndex2MySQL run failure on Sunday 2016-03-06 at 07:00:01
>> Date: March 6, 2016 at 9:00:18 AM CST
>> To: ad...@macosforge.org
>> 
>> 
>> Synchronizing local ports tree from
>> rsync://rsync.macports.org/release/tarballs/ports.tar
>> receiving file list ... done
>> ports.tar
>> 
>> sent 55810 bytes  received 97 bytes  37271.33 bytes/sec
>> total size is 63344640  speedup is 1133.04
>> receiving file list ... done
>> ports.tar.rmd160
>> 
>> sent 54 bytes  received 101 bytes  103.33 bytes/sec
>> total size is 512  speedup is 3.30
>> Creating port index in
>> /opt/local/var/macports/sources/rsync.macports.org/release/tarballs/ports
>> Failed to parse file games/angband/Portfile: Error evaluating variants
>> Warning: failed to open old entry for graphics/wxWidgets-3.0, making a new
>> one
>> Adding port graphics/wxWidgets-3.0
>> Adding subport wxWidgets-3.0-libcxx
>> Adding subport wxPython-3.0
>> Failed to parse file graphics/wxWidgets-3.0/Portfile with subport
>> 'wxgtk-3.0': Registry error: gtk3 not registered as installed & active.
>> 
>> Total number of ports parsed: 5
>> Ports successfully parsed: 3
>> Ports failed: 2
>> Up-to-date ports skipped: 19240
> 
> Whooops, I'm sorry, I didn't think about the possibility of this scenariot.
> 
> Are you able to help me out to come up with a proper patch or should
> we simply replace
> 
>if {[active_variants gtk3 quartz ""]} {
>default_variants-append +quartz
>} else {
>default_variants-append +x11
>}
> 
> by
> 
>default_variants-append +x11
> 
> ?
> 
> Feel free to do the commit if you want. We would probably need to add
> an additional "if gtk is active" before "if {[active_variants gtk3
> quartz ""]}", right?

I haven't looked at your code but the usual thing to write would be:

   if {[!variant_isset quartz]} {
   default_variants-append +x11
   }

https://trac.macports.org/wiki/PortfileRecipes#default_variants

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

Fwd: PortIndex2MySQL run failure on Sunday 2016-03-06 at 07:00:01

[Ryan Schmidt]

> Begin forwarded message:
> 
> From: macports-...@lists.macosforge.org
> Subject: PortIndex2MySQL run failure on Sunday 2016-03-06 at 07:00:01
> Date: March 6, 2016 at 9:00:18 AM CST
> To: ad...@macosforge.org
> 
> 
> Synchronizing local ports tree from 
> rsync://rsync.macports.org/release/tarballs/ports.tar
> receiving file list ... done
> ports.tar
> 
> sent 55810 bytes  received 97 bytes  37271.33 bytes/sec
> total size is 63344640  speedup is 1133.04
> receiving file list ... done
> ports.tar.rmd160
> 
> sent 54 bytes  received 101 bytes  103.33 bytes/sec
> total size is 512  speedup is 3.30
> Creating port index in 
> /opt/local/var/macports/sources/rsync.macports.org/release/tarballs/ports
> Failed to parse file games/angband/Portfile: Error evaluating variants
> Warning: failed to open old entry for graphics/wxWidgets-3.0, making a new one
> Adding port graphics/wxWidgets-3.0
> Adding subport wxWidgets-3.0-libcxx
> Adding subport wxPython-3.0
> Failed to parse file graphics/wxWidgets-3.0/Portfile with subport 
> 'wxgtk-3.0': Registry error: gtk3 not registered as installed & active.
> 
> Total number of ports parsed: 5 
> Ports successfully parsed:3 
> Ports failed: 2 
> Up-to-date ports skipped: 19240
> 
> Error: CHILDSTATUS 10315 1: ERROR 1062 (23000) at line 31338: Duplicate entry 
> 'wxWidgets-3.0' for key 'PRIMARY'


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

Re: [146320] trunk/dports/science/libccd/Portfile

[Ryan Schmidt]

> On Mar 4, 2016, at 11:47 AM, mm...@macports.org wrote:
> 
> Revision
> 146320
> Author
> mm...@macports.org
> Date
> 2016-03-04 09:47:29 -0800 (Fri, 04 Mar 2016)
> Log Message
> 
> science/libccd: project has moved to github, so switch to github portgroup
> Modified Paths
> 
>   • trunk/dports/science/libccd/Portfile
> Diff
> 
> Modified: trunk/dports/science/libccd/Portfile (146319 => 146320)
> 
> --- trunk/dports/science/libccd/Portfile  2016-03-04 16:42:19 UTC (rev 
> 146319)
> +++ trunk/dports/science/libccd/Portfile  2016-03-04 17:47:29 UTC (rev 
> 146320)
> 
> @@ -2,22 +2,17 @@
> 
>  
> 
>  PortSystem 1.0
> 
>  PortGroup  cmake 1.0
> 
> +PortGroup  github 1.0
> 
>  cmake.out_of_source yes
> 
>  
> 
> -namelibccd
> -version 2.0
> 
> +github.setupdanfis libccd 2.0 v
> 
>  epoch   20140327
> 
>  categories  science
> 
>  maintainers mmoll openmaintainer
> 
>  description A library for collision detection between convex shapes
> 
>  long_description$description
> 
> -homepagehttp://libccd.danfis.cz/
>  platforms   darwin
> 
>  license BSD
> 
> -master_sites${homepage}/files
> 
>  checksums   md5 919415277e3baa1d157e713c0b597ab0 \
> 
>  sha1f6ab9053c7f3b18a781c8be973c1844c4421936a \
> 
>  rmd160  3c66e503a411b97801d7d385cf4b511716639935
> 
> -livecheck.type  regex
> -livecheck.url   ${homepage}
> -livecheck.regex ${name}-(\[0-9.\]+).tar.gz

Checksum mismatch. The automatically-generated github tarball is not identical 
to the manually-created tarball the portfile's checksums reference. 
Unfortunately the new github page does not indicate any way to download the old 
manually-created tarball from the project. For now, you should set

master_sites macports_distfiles

to indicate that downloading from github should not be attempted. You should 
advise the developers of the project that they should create a github release 
for version 2.0 and all prior versions, and attach the original tarballs to 
those releases.




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

Re: [146276] trunk/dports/databases

[Ryan Schmidt]

> On Mar 3, 2016, at 6:10 PM, Bradley Giesbrecht  wrote:
> 
>> On Mar 3, 2016, at 12:14 AM, Juan Manuel Palacios  wrote:
>> 
>> Bradley,
>> 
>> I think you and I already discussed this in some thread, but I can’t 
>> remember right now… 
>> 
>> What’s the point of the mysql5 port now a-days? I’d say it’s redundant with 
>> mysql51, but not even, ‘cause it’s outdated with respect to it, 5.1.72 Vs. 
>> 5.1.73. Shouldn’t we just obsolete that port and have it replaced by mysql51?
> 
> 
> These ports have dependencies on mysql5 either directly or through variants:
> port info --name --variants depends:"(\W|^)mysql5(\W|$)" or 
> variant:"(\W|^)mysql5(\W|$)" | grep -E "^name:|^variants:.*mysql5|—"
> 
> Ticket discussing issue:
> https://trac.macports.org/ticket/43431

It's been so long, I think it's probably find to make mysql5 replaced_by 
mysql51, even if there are still ports depending on mysql5. The old php5- ports 
were deleted awhile ago, even though there are still ancient ports declaring 
dependencies on them.


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

Re: Apache2 rev bump for OpenSSL update

[Ryan Schmidt]

> On Mar 3, 2016, at 9:21 AM, Daniel J. Luke <dl...@geeklair.net> wrote:
> 
> On Mar 3, 2016, at 3:05 AM, Ryan Schmidt <ryandes...@macports.org> wrote:
>> On Mar 3, 2016, at 00:18, Juan Manuel Palacios <j...@macports.org> wrote:
>>> 
>>> Apache 2 rev-bumped, cf. r146274.
>>> 
>>> On a side note, and if I may in this same thread, do we have any policy for 
>>> not moving the Apache 2.4 port out of “dev”?  Not too sure when it became 
>>> the recommended release series by the ASF, but it certainly isn’t dev any 
>>> longer.
>> 
>> There's a ticket you can read. We can't just replace the current apache2 
>> port with the current apache24-devel port because it also changes the 
>> directory layout.
> 
> I think it's a mistake to tie upgrading the apache port to 2.4.x and changing 
> the layout (we could just do a simple version bump with the current port + 
> make modifications to any apache modules that need them and tackle changing 
> the layout separately).

Yes I think you've said that before. I don't disagree at this point, but I'm 
not working on this issue right now. Someone else is welcome to.


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

Re: Apache2 rev bump for OpenSSL update

[Ryan Schmidt]

On Mar 3, 2016, at 00:18, Juan Manuel Palacios  wrote:
> 
> Apache 2 rev-bumped, cf. r146274.
> 
> On a side note, and if I may in this same thread, do we have any policy for 
> not moving the Apache 2.4 port out of “dev”?  Not too sure when it became the 
> recommended release series by the ASF, but it certainly isn’t dev any longer.

There's a ticket you can read. We can't just replace the current apache2 port 
with the current apache24-devel port because it also changes the directory 
layout. 
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Invitation to the MacPorts Meeting in Slovenia from the 13-17th of March 2016

[Ryan Schmidt]

On Mar 2, 2016, at 14:36, Carlo Tambuatco <oraclmas...@gmail.com> wrote:

> On Mar 2, 2016, at 12:28 PM, Ryan Schmidt <ryandes...@macports.org> wrote:
>> 
>> On Mar 2, 2016, at 7:11 AM, Mojca Miklavec <mo...@macports.org> wrote:
>>> 
>>> (If there are any developers that would like to be virtually present
>>> at some discussions, please write me a private email with your Skype
>>> username, timezone [or rather acceptable timing expressed in UTC], the
>>> session[s] you are particularly interested in and the reason to join.
>>> I won't promise anything at all, but in case the circumstances would
>>> allow, we could potentially host a tiny number of virtual guests.)
>> 
>> It might be a good idea to record presentations and put them up on YouTube 
>> for later viewing.
> 

> There’s a macports youtube channel?

Not that I'm aware of. 


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

Re: Apache2 rev bump for OpenSSL update

[Ryan Schmidt]

On Mar 2, 2016, at 7:32 PM, Juan Manuel Palacios <j...@macports.org> wrote:
> 
>> On Mar 2, 2016, at 9:00 PM, Ryan Schmidt <ryandes...@macports.org> wrote:
>> 
>> On Mar 2, 2016, at 14:10, Juan Manuel Palacios <j...@macports.org> wrote:
>>> 
>>> Hey Ryan,
>>> 
>>> The Apache 2 port is failing a reload with the "Symbol not found: 
>>> _SSLv2_client_method” error (Referenced from: 
>>> /opt/local/apache2/modules/mod_ssl.so\n  Expected in: 
>>> /opt/local/lib/libssl.1.0.0.dylib) due to the recent OpenSSL update, which 
>>> removed SSLv2.
>>> 
>>> Shouldn’t we rev bump the Apache 2 port to force a rebuild against the new 
>>> OpenSSL?
>> 
>> And all the other ports that link with openssl. 
> 
> Indeed, but I aint maintainer ;)
> 
> I got Apache to work simply by forcing a rebuild against new OpenSSL.


I consider it the responsibility of the committer who updated the openssl port 
to the version that changed its library ABI to revbump the ports that link with 
it, regardless of maintainer status. It should have been done at the same time 
that openssl was updated of course. I'm not working on it so someone else is 
welcome to do it.



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

Re: Apache2 rev bump for OpenSSL update

[Ryan Schmidt]

On Mar 2, 2016, at 14:10, Juan Manuel Palacios  wrote:
> 
> Hey Ryan,
> 
> The Apache 2 port is failing a reload with the "Symbol not found: 
> _SSLv2_client_method” error (Referenced from: 
> /opt/local/apache2/modules/mod_ssl.so\n  Expected in: 
> /opt/local/lib/libssl.1.0.0.dylib) due to the recent OpenSSL update, which 
> removed SSLv2.
> 
> Shouldn’t we rev bump the Apache 2 port to force a rebuild against the new 
> OpenSSL?

And all the other ports that link with openssl. 
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: libebur128 prebuilt archive seems not linked to it's dependency

[Ryan Schmidt]

On Mar 1, 2016, at 12:46 AM, Manu N wrote:

> Lesson 2 : next time, I will start from a clean MacPorts install
> before testing local portfiles.

I would find that inconvenient; I never bother doing that. It's fine to let the 
automated buildbot builds find problems and fix them later. It is however a 
common situation that a port requires pkg-config to find a dependency, and that 
if pkg-config is missing the program will silently skip that dependency rather 
than display an error. So if I'm not sure, I do try to remember to deactivate 
pkg-config locally before installing a port, before I commit it.

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

Re: multiple distfiles and suffixes

[Ryan Schmidt]

On Feb 29, 2016, at 1:06 PM, Mark Brethen wrote:

> I’m working on a portfile that has two distfiles so I set it up as:
> 
>master_sites\
>http://www.dhondt.de/:tagone \
>http://www.netlib.org/linalg/spooles/:tagtwo
> 
>distfiles   \
>ccx_${version}.src.tar.bz2:tagone \
>spooles.2.2.tgz:tagtwo
> 
> I did not find an example in the guide when two different extraction methods 
> (i.e. bzip and gzip) are required. How should this be handled?

MacPorts assumes all distfiles use the same compression method. When they 
don't, you have to limit MacPorts' automatic extraction to just one of the 
types of compression using extract.only to the list the files of that 
compression type, then write a post-extract block to manually decompress the 
files of the other compression type(s).

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

Re: Making a portfile from a cmake based project

[Ryan Schmidt]

On Feb 27, 2016, at 11:13, Mojca Miklavec  wrote:

>> 425cc98f9140885966ce17c1d1
>> depends_libport:speex-devel
> 
> I was unable to use that because I already had "speex" installed. I
> removed -devel and it seemed to work.

If both work, a path: dependency should be used to allow either. 


>> OK.
>> Added a github.tarball_from releases command as there is a release on
>> github.
> 
> I'm not sure when this is needed.

If the project's developers provide a release download, it should be used. This 
project's developers don't, so it cannot be used here. 


>> variant with_tests description {Build tests suite} {
>>  configure.args-append -DENABLE_TESTS=ON
>> }

Variant names should not begin with words like "with" or "without" or "no". 

Does building the test suite really need to be a variant? How long does it take?


> As far as the tests are concerned: MacPorts offers some functionality
> to run the tests (like "sudo port test libebur128"), but I would have
> to check how to properly implement that.


test.run yes

And change test.target if necessary. 


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

Re: [146024] trunk/dports/sysutils

[Ryan Schmidt]

> On Feb 26, 2016, at 8:06 AM, Mihai Moldovan wrote:
> 
> On 26.02.2016 09:38 AM, Ryan Schmidt wrote:
>>> +depends_run port:p5.22-soap-lite
>> 
>> I see you've added a dependency on port:p5.22-soap-lite but I don't see how 
>> you've informed the program that it should use /opt/local/bin/perl5.22, 
>> which would be necessary for this to work.
> 
> Via the patch-amttool-prepare-hashbang-for-reinplace.diff patch file and the
> post-patch phase.

That uses /opt/local/bin/perl, which might not be perl5.22, depending on which 
variant of the perl5 port the user has installed. If you declare a dependency 
on a p5.22 module, you must use the perl5.22 executable.


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

Re: Inconsistent criteria of success on the buildbot

[Ryan Schmidt]

> On Feb 25, 2016, at 5:50 AM, Mojca Miklavec  wrote:
> 
> On 25 February 2016 at 11:22, Joshua Root wrote:
>> On 2016-2-25 18:18 , Mojca Miklavec wrote:
>>> 
>>> Hi,
>>> 
>>> A while ago I committed a new subport for geant4.10.2 which is
>>> currently broken (in the meantime I lacked time/motivation to look
>>> into it; and nobody else complained so far either):
>>> https://trac.macports.org/ticket/50426
>>> 
>>> The initial builds failed, see for example:
>>> 
>>> https://build.macports.org/builders/buildports-mtln-x86_64/builds/27442
>>> but judging from
>>> http://packages.macports.org/geant4.10.2/
>>> it seems as if the "build all ports" picked up and uploaded the
>>> "broken" package with "no questions asked".
>>> 
>>> Shouldn't this be fixed somehow? (Not just the port, but also the
>>> behaviour.) Or did the package automagically start to work properly?
>>> 
>>> I don't dare to even start parsing the logs from the all-ports build.
>>> The progress log from the same buildslave
>>> 
>>> https://build.macports.org/builders/buildports-mtln-x86_64/builds/28037/steps/compile/logs/progress
>>> says "package found, not building again".
>> 
>> That happens if installation succeeded but activation failed, or rev-upgrade
>> failed afterwards. What behaviour are you wanting?
> 
> Good question.
> 
> I would expect:
> - from the buildbot to send me an email about the failure (so that I
> know that I have to look at it and fix it)

The buildbot does send emails on build failures, to all the maintainers of the 
ports that were built.

> - consistency in uploading: either an upload or no upload of the
> package in both build attempts
> 
> But I do realize that implementing the second might be tricky and
> might add a lot of overhead to the process.

That does sound like a reasonable request. I have not read through the code to 
see how the current buildbot configuration is implemented or how we might 
achieve this. But it seems as though the buildbot should just be told to upload 
a package if it finds it, regardless of whether activation succeeded or not. 
That would at least be consistent. I would also like for packages to be 
uploaded immediately after they're created, and not in a separate phase after 
all ports are built. That would help packages get into users' hands quicker.


>> For it to uninstall the
>> port in this case?
>> 
>> I agree it's not really ideal, but it does speed things up for users as
>> archives are intended to do, even though in this case what they end up with
>> is broken either way. And you'll need a version or revision bump to fix it,
>> so uninstalling and attempting the build again in future doesn't really
>> help.
> 
> The only thing that comes to my mind would be to flag a package when
> it fails to build for one reason or another

The buildbot does flag ports as failed or succeeded, and skips them on 
subsequent builds if they haven't changed since the prior success or failure. 
If failure, buildbot also skips ports that depend on the failed port.

> In case a port is
> flagged, the buildbot should try to at least activate the port and run
> some sanity checks (if not rebuilding the port completely) to make
> sure that the port is flawless.

The buildbot should not behave differently from user systems, since the 
buildbot is meant to be our "ideal user". If a port installs but fails to 
activate, a revbump is needed to correct the problem on user systems, so it is 
reasonable to require that to correct the problem on the buildbot as well.

> On the other hand a package might become broken after a while if one
> of its dependencies gets upgraded without revbumping the package. So
> the situation is not much better in that case.

A revbump is required to fix broken packages too, so we needn't consider that 
scenario for the buildbot.


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

Re: [146024] trunk/dports/sysutils

[Ryan Schmidt]

> On Feb 24, 2016, at 7:59 PM, io...@macports.org wrote:
> 
> Revision
> 146024
> Author
> io...@macports.org
> Date
> 2016-02-24 17:59:33 -0800 (Wed, 24 Feb 2016)
> Log Message
> 
> amttools: new port.
> 
> Includes amttool (for querying AMT properties), amtterm (for connecting
> to SoL virtual adapters), gamt (GTK3-/vte-based SoL terminal) and the
> famous amt-howto man page.

> Added: trunk/dports/sysutils/amttools/Portfile (0 => 146024)

> +depends_run port:p5.22-soap-lite

I see you've added a dependency on port:p5.22-soap-lite but I don't see how 
you've informed the program that it should use /opt/local/bin/perl5.22, which 
would be necessary for this to work.

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

Re: [146030] trunk/dports/science/clhep/Portfile

[Ryan Schmidt]

> On Feb 25, 2016, at 12:29 AM, mo...@macports.org wrote:
> 
> Revision
> 146030
> Author
> mo...@macports.org
> Date
> 2016-02-24 22:29:31 -0800 (Wed, 24 Feb 2016)
> Log Message
> 
> clhep: upgrade to version 2.3.1.1, requires C++11 (libc++, clang >= 3.5)

Unless this is a special case, you should include the cxx11 1.0 portgroup, 
rather than managing the compiler blacklisting yourself (though it's possible 
this project has compiler requirements above and beyond what the portgroup 
uses, in which case you can augment it). If this port has no C++ library 
dependencies (looks that way, since it declares no library dependencies at 
all), then you can force the use of libc++, which you should do by setting 
configure.cxx_stdlib to libc++, rather than manually appending to ldflags.


> Modified Paths
> 
>   • trunk/dports/science/clhep/Portfile
> Diff
> 
> Modified: trunk/dports/science/clhep/Portfile (146029 => 146030)
> 
> --- trunk/dports/science/clhep/Portfile   2016-02-25 04:16:15 UTC (rev 
> 146029)
> +++ trunk/dports/science/clhep/Portfile   2016-02-25 06:29:31 UTC (rev 
> 146030)
> 
> @@ -6,7 +6,7 @@
> 
>  PortGroup   compiler_blacklist_versions 1.0
> 
>  
> 
>  nameclhep
> 
> -version 2.3.0.0
> 
> +version 2.3.1.1
> 
>  categories  science
> 
>  maintainers mojca openmaintainer
> 
>  license LGPL-3
> 
> @@ -19,12 +19,17 @@
> 
>  master_sites
> http://proj-clhep.web.cern.ch/proj-clhep/DISTRIBUTION/tarFiles/
>  #   http://git.cern.ch/pubweb/CLHEP.git
>  
> 
> -checksums   rmd160  a45f006c0d027566ec6ce3fa0c3a1bbc58c78215 \
> -sha256  
> 63e77f4f34baa5eaa0adb1ca2438734f2d6f5ca112d830650dd005a6109f2397
> 
> +checksums   rmd160  f302bdf9adcc21e0add5cdf62c2db8a4ba95b8eb \
> +sha256  
> 0e2b170df99176feb0aa4f20ea3b33463193c086682749790c5b9b79388d0ff4
> 
>  
> 
>  cmake.out_of_source yes
> 
>  worksrcdir  ${version}/CLHEP
> 
>  
> 
> +configure.cxx_stdlib libc++
> +# https://its.cern.ch/jira/browse/CLHEP-134
> 
> +compiler.blacklist-append *gcc* {clang < 600} macports-clang-3.3 
> macports-clang-3.4
> +compiler.fallback-append macports-clang-3.7 macports-clang-3.6 
> macports-clang-3.5
> +
> 
>  post-build {
> 
>  fs-traverse file ${build.dir} {
> 
>  if {[string match {*-config} ${file}]} {
> 
> @@ -32,6 +37,7 @@
> 
>  }
> 
>  }
> 
>  }
> 
> +configure.ldflags-append -stdlib=libc++
> 
>  
> 
>  livecheck.type  regex
> 
>  livecheck.url   http://proj-clhep.web.cern.ch/proj-clhep/DISTRIBUTION/


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

Re: where Xcode 3.1 / command line tools ...

[Ryan Schmidt]

On Feb 24, 2016, at 09:08, petr <9...@ingv.it> wrote:
> 
> 
> Hi I am trying to install Macports on an old OS X 10.6 system, but have 
> difficulties to get/find Xcode 3.1 and the command line tools. Is there a 
> place where they can be downloaded. 

Unless you're testing for a specific problem, you should use Xcode 3.2.6 on 
Snow Leopard.  
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Distinguishing between deactivated ports than I want to keep and outdated port I no longer care about

[Ryan Schmidt]

On Feb 24, 2016, at 1:45 AM, Mojca Miklavec wrote:

> I now tried running
>sudo port uninstall inactive and not requested
> This seems to basically work, but it fails when an inactive
> unrequested port is a dependency of another inactive requested port.
> (Or at least that's what I suspect is happening.)

That sounds plausible.


> Is there any equivalent of "port installed" that also shows whether a
> port was requested

No, but you can show installed requested ports with "port installed requested" 
and installed unrequested ports with "port installed unrequested". If you want 
a combined list you could use:

(port -q installed requested | sed 's/$/ (requested)/' && port -q installed 
unrequested | sed 's/$/ (unrequested)/') | sort

> and the size of .tar.bz2 with binaries?

To see the disk space used by the installed files of a port, you can use:

port space name-of-port

I'm not sure if that includes the size of the .tbz2 archive file. To get that 
separately, you can look at:

ls -l /opt/local/var/macports/software/name-of-port/


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

Re: [145995] trunk/dports/www/wp-cli/Portfile

[Ryan Schmidt]

> On Feb 23, 2016, at 7:14 PM, take...@macports.org wrote:
> 
> Revision
> 145995
> Author
> take...@macports.org
> Date
> 2016-02-23 17:14:08 -0800 (Tue, 23 Feb 2016)
> Log Message
> 
> wp-cli: add run-time dependency to php binary
> Modified Paths
> 
>   • trunk/dports/www/wp-cli/Portfile
> 

> +depends_run bin:php:php70

The php70 port doesn't provide a php binary; it provides a php70 binary. So if 
wp-cli is expecting a php binary, php70 by itself is not enough to provide 
that. The user would have to run "sudo port select php php70" to get a php 
symlink pointing to the php70 binary. OS X has shipped with /usr/bin/php for a 
long time, so hopefully that's enough for all OS X users. 


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

Re: Distinguishing between deactivated ports than I want to keep and outdated port I no longer care about

[Ryan Schmidt]

On Feb 23, 2016, at 1:43 PM, Mojca Miklavec wrote:

> I often deactivate certain "heavy" ports where I want to play with
> different versions or variants. Sometimes I deactivate clang 3.8 when
> I don't feel like waiting for the long recompilation of the latest and
> greatest new version (that will be outdated again in a few days
> anyway) or when a newer version no longer works/compiles. Sometimes I
> deactivate universal ports. Those are generally the ports I want to
> keep for some time.
> 
> But I would like to save space and uninstall other ports that I don't
> particularly care about (which have been superseded by newer
> versions).
> 
> Is there any way to flag a certain set of inactive ports that I
> specifically want to keep even after "sudo port uninstall inactive
> [and somethingelse]"?

The way to flag a port as wanted is:

sudo port setrequested name-of-port

The way to flag a port as not wanted is:

sudo port unsetrequested name-of-port

Or:

sudo port setunrequested name-of-port

Then you can use the "requested" and "unrequested" pseudoports when selecting 
ports:

sudo port uninstall inactive and unrequested

This would apply to all variants and versions of a given port name, however. 
There is no provision for, for example, marking the non-universal version of a 
port requested while marking the universal version of that same port as 
unrequested.

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

Re: WP-CLI

[Ryan Schmidt]

On Feb 22, 2016, at 3:00 AM, Takeshi Enomoto wrote:

> - The script in phar does not require the extract phase. Can I
> destroot directly from ${distpath}?

Yes, but instead of overriding the extract phase with

extract {}

it is preferred to clear the extract.only variable with

extract.only


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

Re: WP-CLI

[Ryan Schmidt]

On Feb 22, 2016, at 4:24 PM, Joshua Root wrote:

> On 2016-2-22 20:00 , Takeshi Enomoto wrote:
>> Hi,
>> 
>> I created a Portfile for WP-CLI,
>> which is very useful installing and managing WordPress sites.
>> 
>> 
>> 
>> It is just a compressed PHP script so it might not worth packaging,
>> but Homebrew has a formula and it is mentioned at the WP-CLI web site
>> as and alternative method to install.
>> So I thought we should also provide a Portfile.
>> 
>> - The script runs with php that it finds. Is this OK?
> 
> If it works fine with any version of php this may be OK. If not,
> variants adding a dependency on different php ports may be appropriate.

The other reason to use a specific PHP version (i.e. with variants) is if this 
script needs a PHP module that would be installed with MacPorts. If it needs no 
modules, and works with any version of PHP, then no need for a MacPorts PHP 
dependency.


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

Re: [MacPorts] #48791: jarbundler 2.2.0 Unable to verify file checksums

[Ryan Schmidt]

On Feb 17, 2016, at 7:43 AM, Armando Singh  wrote:
> 
> So whats the solution.. ? Is it going to work now ?

Not until somebody resolves the ticket.


> 
>> On Feb 17, 2016, at 2:23 AM, MacPorts  wrote:
>> 
>> #48791: jarbundler 2.2.0 Unable to verify file checksums
>> +
>> Reporter:  mario.flrs.mndz@…  |  Owner:  macports-tickets@…
>> Type:  defect | Status:  new
>> Priority:  Normal |  Milestone:
>> Component:  ports  |Version:  2.3.3
>> Resolution: |   Keywords:
>> Port:  jarbundler |
>> +
>> Changes (by ryandesign@…):
>> 
>> * cc: hans_meine@… (added)
>> 
>> 
>> Comment:
>> 
>> Replying to [comment:5 hans_meine@…]:
>>> Is the .zip.html thing really only about "the German mirror"?  When
>> googling for "Index of /macports/distfiles/jarbundler", I only got hits
>> with .zip.htmls.
>> 
>> The existence of the .zip.html files was not unique to the German mirror;
>> all mirrors should have the same content, more or less. But there was a
>> misconfiguration of the German mirror which caused it to deliver the
>> .zip.html file when the nonexistent .zip file was requested. This
>> misconfiguration was corrected.
>> 
>> -- 
>> Ticket URL: 
>> MacPorts 
>> Ports system for OS X
> 

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

Re: Spam in Trac

[Ryan Schmidt]

> On Feb 17, 2016, at 5:24 PM, Mojca Miklavec  wrote:
> 
> Hi,
> 
> Can someone please remove spam messages from the tickets archive?
>
> https://lists.macosforge.org/pipermail/macports-tickets/2016-February/thread.html
> 
> Another thing would be to report spam at
>http://thread.gmane.org/gmane.os.apple.macports.tickets
> and other mirrors.
> 
> I see that someone already removed most if not all the spam on Trac
> itself, but the mailing lists archives remain.
> 
> Mojca


Which messages in the February 2016 archive are spam?

We get spam tickets all the time; it didn't just start in February 2016.

Removing spam from a pipermail archive is not very easy. One has to edit the 
mbox file to remove each spam message manually, then regenerate the HTML files 
from the mbox file. Doing this causes mailing list messages to be renumbered, 
breaking old links to those messages.


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

Re: CFITSIO's Fortran interface

[Ryan Schmidt]

> On Feb 15, 2016, at 2:07 AM, Sébastien Maret <sebastien.ma...@icloud.com> 
> wrote:
> 
>> 
>> Le 11 févr. 2016 à 16:19, Ryan Schmidt <ryandes...@macports.org> a écrit :
>> 
>> On Feb 11, 2016, at 2:00 AM, Sébastien Maret wrote:
>>> 
>>>> Le 10 févr. 2016 à 16:23, Ryan Schmidt <ryandes...@macports.org> a écrit :
>>>> 
>>>> On Feb 10, 2016, at 8:52 AM, Sébastien Maret wrote:
>>>> 
>>>>> I am maintaining the Gildas port which depends on the CFITSIO library. 
>>>>> CFITSIO has a Fortran interface but it is not built by default: one need 
>>>>> to select a specific variant (e.g. +gcc 5) for this. This is a problem 
>>>>> for the Gildas because the compilation fails without the Fortran 
>>>>> interface:
>>>>> https://trac.macports.org/ticket/50543
>>>>> 
>>>>> Is there a way for a port to depend on a specific variant of another 
>>>>> port? If not then how can I solve this?
>>>> 
>>>> The require_active_variants procedure in the active_variants 1.1 port 
>>>> group.
>>> 
>>> Thanks. I’ve added the cfitsio +gcc5 in require_active_variants and this 
>>> solves the problem on Yosemite:
>>> https://trac.macports.org/changeset/145605
>>> 
>>> However the compilation fails on older MacOS versions because the +gcc5 
>>> variant is not available.
>> 
>> Why isn't the gcc5 variant available on older Mac OS versions?
> 
> I don’t know. The build bot log for Mountain Lion says:
> 
> DEBUG: cfitsio is installed with the following variants: 
> DEBUG:   required: gcc5, forbidden: 
> DEBUG:   rejected, because required variant gcc5 is missing
> Error: org.macports.configure for port gildas returned: cfitsio must be 
> installed with +gcc5.
> 
> https://build.macports.org/builders/buildports-mtln-x86_64/builds/27804/steps/compile/logs/stdio/text
> 
> so I thought that the cfitsio +gcc5 variant was missing on that platform. But 
> perhaps I misunderstand the build bot log?

I think you misunderstand. This message is generated by the active_variants 1.1 
portgroup. It means that gildas requires the cfitsio port to be installed with 
the +gcc5 variant, but the user (in this case, the buildbot) did not do that 
(in this case, because it is not a default variant, and the buildbot only 
builds default variants). So, nothing about this situation should really be OS 
X-version-specific.

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

Re: Trac down?

[Ryan Schmidt]

> On Feb 13, 2016, at 11:37, Ryan Schmidt <ryandes...@macports.org> wrote:
> 
> This time, the problem was "just" the server running out of memory. (The VM 
> has enough memory for its normal tasks; I don't know what caused its memory 
> use to spike yesterday.) When this happens, Oracle Linux starts killing 
> processes, trying to free memory. Once of the processes it killed was 
> probably the process that was syncing the svn repository from the svn server. 
> Thus the marker that svnsync leaves on r0 to indicate that a sync is in 
> progress never got cleared, and had to be cleared manually to allow a new 
> sync to start.

Happened again today. The problem isn't a single large process; problem is 
hundreds of Apache httpd processes, each of which take a bit of memory. Trac 
server restarted again. 
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Trac down?

[Ryan Schmidt]

> On Feb 13, 2016, at 2:41 AM, Andrea D'Amore <and.dam...@macports.org> wrote:
> 
> On 13 February 2016 at 01:17, Ryan Schmidt <ryandes...@macports.org> wrote:
>> On Feb 11, 2016, at 15:12, Mihai Moldovan <io...@ionic.de> wrote:
>>> Thanks for that, but Trac has also stopped updating after r145635 (which
>>> coincidences with my first SVN file property change in r145636.)
>> Fixed.
> 
> Was that the same issue that kept trac out of sync for a few months lately?

No, a few months ago, the MacPorts VMs were upgraded to Oracle Linux 6.7, which 
caused all the custom SELinux permissions to be lost, which then had to be 
manually recreated by comparing settings with the non-MacPorts VMs.

This time, the problem was "just" the server running out of memory. (The VM has 
enough memory for its normal tasks; I don't know what caused its memory use to 
spike yesterday.) When this happens, Oracle Linux starts killing processes, 
trying to free memory. Once of the processes it killed was probably the process 
that was syncing the svn repository from the svn server. Thus the marker that 
svnsync leaves on r0 to indicate that a sync is in progress never got cleared, 
and had to be cleared manually to allow a new sync to start.


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

Re: Trac down?

[Ryan Schmidt]

On Feb 11, 2016, at 15:12, Mihai Moldovan <io...@ionic.de> wrote:
> 
>> On 11.02.2016 08:38 PM, Ryan Schmidt wrote:
>> There was high memory usage for an unknown reason, which caused the OS to 
>> start killing processes, including the web server, to free memory. I 
>> rebooted the server and it's working again.
> 
> Thanks for that, but Trac has also stopped updating after r145635 (which
> coincidences with my first SVN file property change in r145636.)

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

Re: trac commits don't link anymore?

[Ryan Schmidt]

On Feb 12, 2016, at 14:32, Marius Schamschula  wrote:
> 
> Ryan,
> 
> Apparently we are having the same issue as several months ago, with trac not 
> displaying the content of links for commits, displaying
> 
> Error: Invalid Changeset Number
> 
> instead. The links are still showing up on irc, but lead to the above error.
> 
> Marius

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

Re: CFITSIO's Fortran interface

[Ryan Schmidt]

On Feb 11, 2016, at 2:00 AM, Sébastien Maret wrote:
> 
> 
>> Le 10 févr. 2016 à 16:23, Ryan Schmidt <ryandes...@macports.org> a écrit :
>> 
>> On Feb 10, 2016, at 8:52 AM, Sébastien Maret wrote:
>> 
>>> I am maintaining the Gildas port which depends on the CFITSIO library. 
>>> CFITSIO has a Fortran interface but it is not built by default: one need to 
>>> select a specific variant (e.g. +gcc 5) for this. This is a problem for the 
>>> Gildas because the compilation fails without the Fortran interface:
>>> https://trac.macports.org/ticket/50543
>>> 
>>> Is there a way for a port to depend on a specific variant of another port? 
>>> If not then how can I solve this?
>> 
>> The require_active_variants procedure in the active_variants 1.1 port group.
> 
> Thanks. I’ve added the cfitsio +gcc5 in require_active_variants and this 
> solves the problem on Yosemite:
> https://trac.macports.org/changeset/145605
> 
> However the compilation fails on older MacOS versions because the +gcc5 
> variant is not available.

Why isn't the gcc5 variant available on older Mac OS versions?

> I don’t need the gcc5 variant in particular; any of the gcc4x should be fine. 
> How can I do this with require_active_variants?

At present, it doesn't offer that functionality. You could code it manually, if 
it's truly required to have different gcc variants available on different 
versions of OS X, though this would be the first circumstance I've heard of of 
that being necessary.


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

Re: Trac down?

[Ryan Schmidt]

There was high memory usage for an unknown reason, which caused the OS to start 
killing processes, including the web server, to free memory. I rebooted the 
server and it's working again. 

> On Feb 11, 2016, at 12:59, Craig Treleaven  wrote:
> 
> It seems that  https://trac.macports.org  is unreachable.

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

Re: CFITSIO's Fortran interface

[Ryan Schmidt]

On Feb 10, 2016, at 8:52 AM, Sébastien Maret wrote:

> I am maintaining the Gildas port which depends on the CFITSIO library. 
> CFITSIO has a Fortran interface but it is not built by default: one need to 
> select a specific variant (e.g. +gcc 5) for this. This is a problem for the 
> Gildas because the compilation fails without the Fortran interface:
> https://trac.macports.org/ticket/50543
> 
> Is there a way for a port to depend on a specific variant of another port? If 
> not then how can I solve this?

The require_active_variants procedure in the active_variants 1.1 portgroup.

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

Re: [145326] trunk/www/index.php

[Ryan Schmidt]

> On Feb 8, 2016, at 12:42 PM, Rainer Müller  wrote:
> 
> On 2016-02-01 16:28, mo...@macports.org wrote:
>> Revision: 145326
>>  https://trac.macports.org/changeset/145326
>> Author:   mo...@macports.org
>> Date: 2016-02-01 07:28:27 -0800 (Mon, 01 Feb 2016)
>> Log Message:
>> ---
>> www: a (temporary) link to the MacPorts meeting
> 
> Ryan,
> 
> it seems like the automatic update of the webserver failed for this and
> the following commit. This change is not yet visible on the website.
> Could you please take a look and manually update the working copy?
> 
> Rainer

I think it's fixed now.


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

Re: [145141] trunk/dports/python

[Ryan Schmidt]

> On Jan 27, 2016, at 3:57 PM, Andrew Fernandes  
> wrote:
> 
> I think that's to be expected, for a port that hasn't been added to the 
> portindex yet.
> 
> Oh - so lint gives different (and incomprehenible) output that changes 
> whether or not the port is in the index. Yeesh.
> 
> No prob, committing a fix now. I’m also fixing the license issue. r145179

Well, lint was accurately telling you that your port py-pyinstaller has a 
dependency on py27-pyinstaller (which was added by the python 1.0 portgroup), 
and that no port named py27-pyinstaller exists in the portindex. lint didn't 
know that your new unindexed port included the definition for the 
py27-pyinstaller port.

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

Re: [145141] trunk/dports/python

[Ryan Schmidt]

> On Jan 27, 2016, at 4:24 AM, Andrew Fernandes  
> wrote:
> 
> MacPorts interprets the license field as a space-separated list of valid 
> license names.
> 
> Ah, I vaguely remember that. I had simply copied the license field from the 
> original Portfile in #42693.
> 
> But that didn’t cause the issue - I checked.
>> +python.versions 27 33 34 35
>> 
> 
> Doesn't the python.versions line have to be outside this block?
> 
> Yes, that’s what I’ve done before and that’s what all the other python ports 
> do.

Setting python.versions is what causes the python 1.0 portgroup to create the 
subports. If it's inside an "if {${name} ne ${subport}}" block, it can never 
get executed, and the subports can never get created, because at the time the 
if statement is evaluated no subports exist yet, so at that point ${name} will 
always eq ${subport}.


> However, if the line is outside the block - like every other port - I get a 
> “port lint” error that “py27-pypyinstaller is an unmet dependency” which I 
> simply don’t understand.

I think that's to be expected, for a port that hasn't been added to the 
portindex yet. You can either add it to the portindex (by running the portindex 
command in the dports directory as the correct user), or just ignore it and 
check it again later after it's been committed.


> Linting with a subport specified gives me no error.
> 
> The only way I could get rid of it - and I spent a lot of time trying and a 
> lot of time googling, and a lot of time looking at other ports - was to move 
> the python.versions block inside the subport-check block.



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

Re: [145185] trunk/dports/python/py-pyinstaller/Portfile

[Ryan Schmidt]

> On Jan 27, 2016, at 6:58 PM, adfernan...@macports.org wrote:
> 
> Revision
> 145185
> Author
> adfernan...@macports.org
> Date
> 2016-01-27 18:58:54 -0800 (Wed, 27 Jan 2016)
> Log Message
> 
> py-pyinstaller: actually fetch the correct tarball, not git HEAD
> Modified Paths
> 
>   • trunk/dports/python/py-pyinstaller/Portfile
> Diff
> 
> Modified: trunk/dports/python/py-pyinstaller/Portfile (145184 => 145185)
> 
> --- trunk/dports/python/py-pyinstaller/Portfile   2016-01-28 01:40:18 UTC 
> (rev 145184)
> +++ trunk/dports/python/py-pyinstaller/Portfile   2016-01-28 02:58:54 UTC 
> (rev 145185)
> @@ -7,9 +7,12 @@
>  namepy-pyinstaller
>  version 3.1
>  
> -fetch.type  git
>  github.setuppyinstaller PyInstaller ${version} v
> +github.tarball_from releases
>  
> +checksums   rmd160  8d0659ac74a81b634f0712a64ff28db71a3450e4 \
> +sha256  
> 5a28c3bb9d23ea644f9dc9e561e66471b83258d44063bcb108dfbbfe4af3c02b

It looks like HEAD was some commits ahead of 3.1. So this revision changes the 
files that would be installed on the user's disk. So the port's revision should 
be increased.

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

Re: [145141] trunk/dports/python

[Ryan Schmidt]

On Jan 26, 2016, at 13:50, adfernan...@macports.org wrote:
> 
> Revision
> 145141
> Author
> adfernan...@macports.org
> Date
> 2016-01-26 13:50:47 -0800 (Tue, 26 Jan 2016)
> Log Message
> 
> new port: py-pyinstaller 3.1 closes #42693
> Added Paths
> 
> trunk/dports/python/py-pyinstaller/
> trunk/dports/python/py-pyinstaller/Portfile
> Diff
> 
> Added: trunk/dports/python/py-pyinstaller/Portfile (0 => 145141)
> 
> 
> --- trunk/dports/python/py-pyinstaller/Portfile   
> (rev 0)
> +++ trunk/dports/python/py-pyinstaller/Portfile   2016-01-26 21:50:47 UTC 
> (rev 145141)
> @@ -0,0 +1,31 @@
> +# $Id: Portfile 114324 2013-12-05 08:44:51Z ryandes...@macports.org $
> +
> +PortSystem  1.0
> +PortGroup python1.0
> +PortGroup github1.0
> +
> +namepy-pyinstaller
> +version 3.1
> +
> +fetch.type  git

Why do you need fetch.type git?

> +github.setuppyinstaller PyInstaller ${version} v
> +
> +platforms   darwin
> +supported_archs noarch
> +maintainers openmaintainer adfernandes
> +description converts (packages) Python programs into stand-alone 
> executables
> +long_description${description}
> +license GPL license with a special exception which allows to use 
> PyInstaller to build and distribute non-free programs (including commercial 
> ones)

MacPorts interprets the license field as a space-separated list of valid 
license names. You should probably only list licenses known to the 
port_binary_distributable.tcl script. You can add notes about the license in a 
portfile comment. 

> +homepagehttp://www.pyinstaller.org/
> +
> +if {${name} ne ${subport}} {
> +
> +python.versions 27 33 34 35

Doesn't the python.versions line have to be outside this block?

> +livecheck.type  none
> +
> +} else {
> +livecheck.type  regex
> +livecheck.url   ${homepage}
> +livecheck.regex "The latest stable release of PyInstaller is 
> (\\d+(?:\\.\\d+)*)"
> +}
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: -stdlib=libc++ added to configure.cxxflags but not configure.ldflags

[Ryan Schmidt]

On Jan 26, 2016, at 4:35 AM, René J.V. Bertin wrote:

> I just ran into a situation (building a Qt5 port) where for some reason 
> -stdlib=libc++ was added to configure.cxxflags but not to configure.ldflags . 
> That led to a failing final link.
> 
> I worked around the issue by adding the option myself if it is detected in 
> cxxflags, but I wonder why this isn't an issue more often.
> 
> I'm running "base" 2.3.4 rev. 140804 ; the port in question is 
> https://github.com/RJVB/macstrop/tree/master/devel/xxdiff .

I agree that MacPorts base only adds -stdlib=${configure.cxx_stdlib} to 
configure.cxxflags, not configure.ldflags, but that's not necessarily wrong, is 
it? If the build system just wants to link already-compiled objects, it doesn't 
need compiler flags. If the build system wants to compile and link at the same 
time, it's the build system's responsibility to add both the compiler flags 
(CFLAGS or CXXFLAGS) and the linker flags (LDFLAGS) to the compile/link command.


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

Re: VLC cannot play MKV files?

[Ryan Schmidt]

> On Jan 26, 2016, at 1:47 AM, Vincent Habchi  wrote:
> 
>>> I was under the impression that Apple already compressed the files and 
>>> programs installed with the operating system, using HFS compression, ever 
>>> since taking up less disk space was listed as a feature of Snow Leopard.
>> Yeah, I thought so too, but I also have the impression that may not always 
>> work as advertised after a few updates have been applied. Easy enough to 
>> check with `ls -lO` (/usr/bin/ls that is).
> 
> I’ve applied René method, disabling SIP while compressing /Applications. It 
> gave me some significant savings, thus I surmise all the applications are not 
> compressed. Xcode is, though, but things like iWorks (Pages, etc.) are not.
> 
> I am not space savings in Snow Leopard were the result of using file 
> compression.

According to the Ars Technica review of Snow Leopard, 97% of executable files 
in Snow Leopard are compressed.

http://arstechnica.com/apple/2009/08/mac-os-x-10-6/3/


> I’d rather wager Apple get rid of some universal code (ppc/ppc64) in 10.6. 
> 10.5 was the final version usable with ppc, AFAIR.

10.6 removed ppc64 code but kept ppc code. 10.7 removed ppc code.


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

Re: VLC cannot play MKV files?

[Ryan Schmidt]

> On Jan 26, 2016, at 2:26 AM, René J.V. Bertin  wrote:
> 
> Given the disk savings it can give I really don't understand why the patch 
> that adds HFS compression to port activation was never accepted.

For reference, that was this ticket:

https://trac.macports.org/ticket/36560

There were performance concerns earlier in the discussion but I'm not sure if 
the latest version of the patch attached there resolves them.

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

Re: VLC cannot play MKV files?

[Ryan Schmidt]

> On Jan 24, 2016, at 1:42 AM, Vincent Habchi  wrote:
> 
>> Sure. And it is probably also very easy to introduce regressions that way if 
>> the #ifdefs aren't already in place.
> 
> Yeah, that’s right. Every cloud has its silver lining. Or the contrary for 
> that matter.
> 
>> It'll do the same with your /Applications directory or the entire /opt/local 
>> tree.
> 
> Except that it’s no longer possible to compress the build-in Applications 
> with OS X 10.11 since Apple introduced SIP 
> (http://arstechnica.com/apple/2015/09/os-x-10-11-el-capitan-the-ars-technica-review/8/#h1).
>  Even root cannot modify the protected applications (it’s still possible, but 
> it’s a darn intricate process to do it).

I was under the impression that Apple already compressed the files and programs 
installed with the operating system, using HFS compression, ever since taking 
up less disk space was listed as a feature of Snow Leopard.


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

Re: Using cxx11 PortGroup on < 10.9

[Ryan Schmidt]

On Jan 24, 2016, at 11:15 PM, Jeremy Huddleston Sequoia wrote:

> What benefit does "cxx.require_global_libc++ no" have over the current 
> approach of just doing:
> 
>configure.cxx_stdlib libc++
>depends_lib-append port:libcxx

Or I was going to suggest:

PortGroupcxx11 1.0
configure.cxx_stdlib libc++

which is what the mongodb port does. The cxx11 1.0 portgroup ensures that 
compilers that don't do C++11 are blacklisted, which I think just depending on 
the libcxx port wouldn't do.


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

Re: Using cxx11 PortGroup on < 10.9

[Ryan Schmidt]

> On Jan 25, 2016, at 09:29, Mojca Miklavec wrote:
> 
> (Even more than that I would really like to see the buildbots with
> libc++ as their default stdlib being set up.)

As far as I know nothing has changed on this front. I'm totally willing to set 
up libc++ build slaves for 10.6, 10.7 and 10.8, but cannot do so until we agree 
on a naming scheme to differentiate libc++ packages from libstdc++ packages, 
implement that in base, and release it. 

Well, that would be a prerequisite for *distributing* such packages. I suppose 
we could set up build slaves that just build and don't distribute their 
packages. But that wouldn't be as helpful. 
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: https fetch on buildbots?

[Ryan Schmidt]

On Jan 20, 2016, at 12:39, David Strubbe  wrote:
> 
> Hi all,
> 
> After making a commit to the port miriad, I find that the fetch fails on the 
> buildbots like this 
> (https://build.macports.org/builders/buildports-mtln-x86_64/builds/27365/steps/compile/logs/stdio).
>  Is there any inherent problem with fetching from an https site? Or, any 
> suggestion on how to diagnose what the SSL error is?

I'm not aware of a general problem with https fetching on the buildbot servers. 

Maybe that site is using a newer ssl/tls protocol than the version of 
curl/openssl provided with Mountain Lion knows about?

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

Re: [144726] trunk/dports/science

[Ryan Schmidt]

> On Jan 16, 2016, at 8:54 AM, c...@macports.org wrote:
> 
> Revision
> 144726
> Author
> c...@macports.org
> Date
> 2016-01-16 06:54:58 -0800 (Sat, 16 Jan 2016)
> Log Message
> 
> esorepo: Provide easy access to ESO's ports tree
> 
> Closes #46954
> 
> Added Paths
> 
>   • trunk/dports/science/esorepo/
>   • trunk/dports/science/esorepo/Portfile
> Diff
> 
> Added: trunk/dports/science/esorepo/Portfile (0 => 144726)
> 
> --- trunk/dports/science/esorepo/Portfile (rev 0)
> +++ trunk/dports/science/esorepo/Portfile 2016-01-16 14:54:58 UTC (rev 
> 144726)
> 
> @@ -0,0 +1,127 @@
> 
> +# -*- coding: utf-8; mode: tcl; tab-width: 4; indent-tabs-mode: nil; 
> c-basic-offset: 4 -*- vim:fenc=utf-8:ft=tcl:et:sw=4:ts=4:sts=4
> +# $Id$
> +
> +PortSystem  1.0
> +
> +nameesorepo
> +version 1.1
> +categories  science
> +license GPL-2+
> +platforms   darwin
> +supported_archs noarch
> +maintainers eso.org:usd-help
> +
> +description ESO repository of software for astronomical data 
> reduction
> +
> +long_description\
> +The European Southern Observatory (ESO) maintains and distributes a 
> number \
> +of open source software packages (e.g. data reduction pipelines and 
> front-end \
> +tools) for the astronomical science community. This port provides a 
> convenient \
> +configuration mechanism to add an additional repository URL to allow 
> further \
> +installation of ESO software via MacPorts.
> +
> +homepagehttp://www.eso.org/sci/software
> +master_sites
> ftp://ftp.eso.org/pub/dfs/pipelines/repositories/macports/
> +
> +fetch {}
> +checksum {}
> +extract {}

Instead of overriding the fetch, checksum and extract phases, you should 
declare that the port has no distfiles, by writing on a line by itself:

distfiles

With no distfiles, the master_sites line isn't needed either. ("port lint" will 
complain about missing master_sites, but that's a bug in "port lint".)


> +test {}

The test phase is disabled by default. There is no need to override it with an 
empty block.


> +use_configure no
> +
> +build {
> +  set key_file [open "${workpath}/eso-pubkey.pem" w]
> +  puts ${key_file} "-BEGIN PUBLIC KEY-"
> +  puts ${key_file} 
> "MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAy2Au5qRNn/zoRRZ7rdsn"
> +  puts ${key_file} 
> "g3lbrM33Iz3xew4yZD5L6LI69qVVfmaUsELreeK+bZAf8bLl5+HYHHvM/pBZq/+6"
> +  puts ${key_file} 
> "LBf+NnESVwmKfhEppHim3MqRNyTfSOJAM+J1xt1/dvZkBX8ehZO8piRRaKUPzauW"
> +  puts ${key_file} 
> "WhahV417jD37AWKXlRCNPxUtgEk7kRrMQuP4olWWVul+m7piGrDMzQsAOtvEMX5R"
> +  puts ${key_file} 
> "J5Ygr3iZNq8WSXhAMqfm6cksxq7kMa8sfpw8lU1jXKfN4wREH3w2oJohkkTYFqUq"
> +  puts ${key_file} 
> "0FBnqBkGZlv5e1FUEFW1rnvUpbzOxgDgfdOKwzqNWw2EGl6baQT63iIqa752kCE7"
> +  puts ${key_file} "SwIDAQAB"
> +  puts ${key_file} "-END PUBLIC KEY-"
> +  close ${key_file}
> +}

The whitespace of this portfile does not conform to what the modeline says the 
whitespace is. (Indents should be at multiples of 4 spaces, not 2.)

Why construct this file in the build phase? Why not just put the real file in 
the files directory and copy it from there? Wouldn't that be much more 
straightforward?

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

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

[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: Accessing individual logs of failures on the buildbot

[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: pkg-config v. -I/opt/local/include

[Ryan Schmidt]

On Jan 13, 2016, at 6:37 AM, Craig Treleaven wrote:On Jan 13, 2016, at 2:19 AM, Ryan Schmidt wrote:On Jan 12, 2016, at 1:05 PM, Craig Treleaven wrote:Adding 'configure.env-append    PKG_CONFIG_SYSTEM_INCLUDE_PATH=${prefix}/include’  makes the MythTV build work the way it does on Linux (aka “successfully”).But is that because -I/opt/local/include then gets inserted into the correct place in the compile line, or because -I/opt/local/include is omitted from the compile line and it only works because MacPorts also happens to set CPATH=/opt/local/include and you're using a newer compiler that supports that? (Granted, only very old versions of clang don't support CPATH.)There is no '-I/opt/local/include' anywhere in my compiler args now so I assume CPATH is used.  I figured.BTW, you made me curious.  A recent Fedora23 compile log from a Myth’s buildbot is at:https://code.mythtv.org/buildbot/builders/master-f23-64bit/builds/104/steps/compile%20core/logs/stdioIf you search for “-I/usr/include “, the only hits are invocations of Qt’s mod!  Never appears in the compiler args.That's expected because /usr/include is a special location. Compilers know to check there automatically. They do not know to check in /opt/local/include automatically so you have to tell them to check there. The normal should-work-everywhere way to do that is by putting -I/opt/local/include into the CPPFLAGS environment variable. If that causes problems for the myth build, that is a bug in the myth build system that the myth developers should fix.So I’m now building the “Myth-blessed” way!  ;)It would be silly of them to say that it is not supported to build myth with dependencies installed in a prefix other than /usr.___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

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

[Ryan Schmidt]

> On Jan 13, 2016, at 11:29 AM, dstru...@macports.org wrote:
> 
> Revision
> 144607
> Author
> dstru...@macports.org
> Date
> 2016-01-13 09:29:21 -0800 (Wed, 13 Jan 2016)
> Log Message
> 
> octopus: Make +accelerate the default, to save a lot of time in building 
> atlas.
> Modified Paths
> 
>   • trunk/dports/science/octopus/Portfile
> Diff
> 
> Modified: trunk/dports/science/octopus/Portfile (144606 => 144607)
> 
> --- trunk/dports/science/octopus/Portfile 2016-01-13 16:51:07 UTC (rev 
> 144606)
> +++ trunk/dports/science/octopus/Portfile 2016-01-13 17:29:21 UTC (rev 
> 144607)
> @@ -6,7 +6,7 @@
>  
>  nameoctopus
>  version 5.0.1
> -revision0
> +revision1
>  categories  science
>  platforms   darwin
>  license GPL-2+
> @@ -52,7 +52,7 @@
>  
>  default_variants +newuoa
>  if {![variant_isset accelerate] && ![variant_isset openblas]} {
> -default_variants-append +atlas
> +default_variants-append +accelerate
>  }


But there was no reason to increase the port's revision, since the user's 
existing variants will be preserved in the upgrade. Regardless whether the user 
had the atlas or accelerate or openblas variant of octupus 5.0.1_0 installed, 
they will have exactly the same variant of octopus 5.0.1_1 installed after the 
upgrade. Increasing the revision only causes lots of unnecessary rebuilding, 
for the buildbots and for users.


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

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

[Ryan Schmidt]

On Jan 13, 2016, at 11:45 AM, Ryan Schmidt wrote:

> But there was no reason to increase the port's revision, since the user's 
> existing variants will be preserved in the upgrade. Regardless whether the 
> user had the atlas or accelerate or openblas variant of octupus 5.0.1_0 
> installed, they will have exactly the same variant of octopus 5.0.1_1 
> installed after the upgrade. Increasing the revision only causes lots of 
> unnecessary rebuilding, for the buildbots and for users.

I should correct myself, and say it causes unnecessary rebuilding or 
downloading and reinstalling for users. The buildbots will have to rebuild 
regardless whether the revision is changed, because the variants are changed, 
but that's fine.


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

Re: pkg-config v. -I/opt/local/include

[Ryan Schmidt]

On Jan 12, 2016, at 1:05 PM, Craig Treleaven wrote:
> On Jan 12, 2016, at 4:09 AM, Ryan Schmidt wrote:
>> On Jan 11, 2016, at 9:03 AM, Craig Treleaven wrote:
>>> I’m having buiild failures due to includes pointing to old/other headers 
>>> installed in /opt/local/include.
>>> 
>>> As I understand it, 'pig-config —cflags’ returns an empty string when a 
>>> header is installed in /usr/include.  The port I’m working on, MythTV 
>>> 0.28-pre, uses pkg-config to check for several dependencies.  Under 
>>> MacPorts, I end up with '-I/opt/local/include’ early in the compiler 
>>> arguments and thus picks up old or unintended versions of headers.  Under 
>>> Linux, no problem.
>>> 
>>> Is there some way I can coerce pkg-config to treat /opt/local/include like 
>>> it does /usr/include?  I’ve looked at the man page for pkg-config and tried 
>>> using some of the environment variables but without success.
>>> 
>>> Eg, with MacPorts:
>>> $ pkg-config --cflags x264
>>> -I/opt/local/include ## want to make this disappear!
>>> 
>>> is there a magic recipe?
>> 
>> You should not want to make -I/opt/local/include disappear. It is where the 
>> headers of dependencies are installed, so it is needed. If it is causing 
>> problems, it is likely because your project's build system does not place 
>> the include flags in the correct order. The correct order is (relative) 
>> project include paths first, (absolute) dependency include paths second. If 
>> you cannot fix the build system to do that, you can use your sed trick to 
>> replace -I/opt/local/include with -isystem/opt/local/include which will have 
>> the same effect.
>> 
> 
> Hi Ryan:
> 
> I asked over on the pkg-config mailing list and got:
> 
>> This isn't documented (should be), but you can override pkg-config's notion 
>> of the system include path with the environment variable 
>> PKG_CONFIG_SYSTEM_INCLUDE_PATH. If that's not set, it uses the compiled in 
>> defaults. That's been in pkg-config for a long time, so it should work with 
>> the version you have. This should be in the form of a path style variable 
>> with : separators.

I didn't know about that variable. Thanks for finding out about that.


> This is exactly what I wanted:
> 
> $ pkg-config --cflags-only-I libass
> -I/opt/local/include -I/opt/local/include/freetype2 -I/opt/local/include 
> -I/opt/local/include/libpng16 -I/opt/local/include 
> -I/opt/local/include/fribidi -I/opt/local/include/glib-2.0 
> -I/opt/local/lib/glib-2.0/include -I/opt/local/include 
> -I/opt/local/include/freetype2 
> 
> $ PKG_CONFIG_SYSTEM_INCLUDE_PATH=/opt/local/include pkg-config 
> --cflags-only-I libass
> -I/opt/local/include/freetype2 -I/opt/local/include/libpng16 
> -I/opt/local/include/fribidi -I/opt/local/include/glib-2.0 
> -I/opt/local/lib/glib-2.0/include -I/opt/local/include/freetype2 
> 
> Adding 'configure.env-append
> PKG_CONFIG_SYSTEM_INCLUDE_PATH=${prefix}/include’  makes the MythTV build 
> work the way it does on Linux (aka “successfully”).

But is that because -I/opt/local/include then gets inserted into the correct 
place in the compile line, or because -I/opt/local/include is omitted from the 
compile line and it only works because MacPorts also happens to set 
CPATH=/opt/local/include and you're using a newer compiler that supports that? 
(Granted, only very old versions of clang don't support CPATH.)


> As to whether this is the “right” thing to do, you have far more knowledge 
> and experience than me.  I think Myth’s configure is relying on a quirk of 
> pkg-config.  I would think that other folks that are cross-compiling--or even 
> just using a different prefix—must be hitting this problem.  I get very 
> little traction with the Myth devs.  They writeoff stuff like this as a 
> “MacPorts problem”.

Yeah they would be incorrect to blame bugs in their build system on us just 
because we use their build system in a slightly different way than they 
apparently do.


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

Re: pkg-config v. -I/opt/local/include

[Ryan Schmidt]

On Jan 11, 2016, at 9:03 AM, Craig Treleaven wrote:

> I’m having buiild failures due to includes pointing to old/other headers 
> installed in /opt/local/include.
> 
> As I understand it, 'pig-config —cflags’ returns an empty string when a 
> header is installed in /usr/include.  The port I’m working on, MythTV 
> 0.28-pre, uses pkg-config to check for several dependencies.  Under MacPorts, 
> I end up with '-I/opt/local/include’ early in the compiler arguments and thus 
> picks up old or unintended versions of headers.  Under Linux, no problem.
> 
> Is there some way I can coerce pkg-config to treat /opt/local/include like it 
> does /usr/include?  I’ve looked at the man page for pkg-config and tried 
> using some of the environment variables but without success.
> 
> Eg, with MacPorts:
> $ pkg-config --cflags x264
> -I/opt/local/include ## want to make this disappear!
> 
> is there a magic recipe?

You should not want to make -I/opt/local/include disappear. It is where the 
headers of dependencies are installed, so it is needed. If it is causing 
problems, it is likely because your project's build system does not place the 
include flags in the correct order. The correct order is (relative) project 
include paths first, (absolute) dependency include paths second. If you cannot 
fix the build system to do that, you can use your sed trick to replace 
-I/opt/local/include with -isystem/opt/local/include which will have the same 
effect.

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

Re: Broken links detected...to ApplicationServices ?

[Ryan Schmidt]

On Jan 10, 2016, at 10:57 AM, Craig Treleaven wrote:

> Aha!  Did some careful checking and it appears that '-framework 
> ApplicationServices’ was missing from the linker flags.  Adding that appears 
> to have cured the problem.
> 
> Sorry for th noise.

It's strange problem! I don't understand why omitting that flag would have the 
effect you described; I would have expected instead for a failure at link time 
due to undefined symbols. But regardless, I'm glad you found a solution.


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

Re: [144336] trunk/dports/science/silo/Portfile

[Ryan Schmidt]

On Jan 9, 2016, at 9:45 PM, David Strubbe wrote:

>>> On Sat, Jan 9, 2016 at 2:31 AM, Ryan Schmidt wrote:
> 
>> On Jan 6, 2016, at 1:21 PM, dstru...@macports.org wrote:
>> >
>> > Revision
>> > 144336
>> > Author
>> > dstru...@macports.org
>> > Date
>> > 2016-01-06 11:21:10 -0800 (Wed, 06 Jan 2016)
>> > Log Message
>> >
>> > silo: Use compilers portgroup for Fortran variants. Clarify meaning in 
>> > description. Update livecheck. Remove irrelevant comment. Add caution 
>> > about MPI with HDF5.
>> 
>> Well, the comment was relevant in that it documented the error message one 
>> got when ccache was used, thus explaining why it had been disabled for this 
>> port.
>> 
>> > Modified Paths
>> >
>> >   • trunk/dports/science/silo/Portfile
>> > Diff
>> >
>> > Modified: trunk/dports/science/silo/Portfile (144335 => 144336)
>> 
>> > -# Makefile:152: *** missing separator.  Stop.
>> > +compilers.choosefc f77 f90
>> > +compilers.setup
>> > +
>> >  configure.ccacheno
> 

> Are you sure that is what this line meant? It is hard to believe that ccache 
> could be related to this error message of illegal syntax in a Makefile. And, 
> I just commented out the ccache line and the port seems to work fine without 
> that line, or with configure.ccache yes.

Yes I'm sure, in that I put it there when I initially added the port in 
https://trac.macports.org/changeset/78261 and I mentioned it in 
https://trac.macports.org/ticket/29325#comment:4.


I just now backdated the port to that revision, re-enabled ccache and changed 
"hdf5-18" to "hdf5", and verified that silo 4.8 did have this problem. Lines 
151-152 of the Makefile ended up as:

CC_FULLPATH = /opt/local/bin/ccache
/usr/bin/clang

and later in the same file:

CXX_FULLPATH = /opt/local/bin/ccache
/usr/bin/clang++

In other words, the MacPorts-provided CC and CXX values "ccache /usr/bin/clang" 
and "ccache /usr/bin/clang++" were erroneously expanded and corrupted.


Now, in silo 4.10.2, if I re-enable ccache, the corresponding lines of Makefile 
read:

CC_FULLPATH = /opt/local/bin/ccache

and:

CXX_FULLPATH = /opt/local/bin/ccache

This is still wrong -- these variables are evidently meant to be the absolute 
paths to the compilers, but they have instead been computed as the absolute 
path to ccache -- but at least they've fixed things to use only the first word. 
It looks like the only places these variables are used is to show a summary at 
the end of the configure phase:

Compiling Options:
 C Compiler /opt/local/bin/ccache
   CPPFLAGS -I/opt/local -I/opt/local/include
 CFLAGS -pipe -Os -arch x86_64 -D_LARGEFILE_SOURCE 
-D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -Wdeclaration-after-statement
LDFLAGS -L/opt/local/lib 
-Wl,-headerpad_max_install_names -arch x86_64
   LIBS -lhdf5  
Languages:
   C++ Compiler /opt/local/bin/ccache
   CXXFLAGS -pipe -Os -stdlib=libc++ -arch x86_64
   Fortran Compiler 
FCFLAGS -pipe -Os -m64
 FCLIBS 

And the same information gets written to the installed file 
/opt/local/lib/libsiloh5.settings as well.

It should probably be changed to directly use the unmodified values of CC and 
CXX and not attempt the error-prone process of trying to expand them into an 
absolute path, especially since it seems to serve no purpose other than to be 
informational to the user. Then ccache support for this portfile can be 
reenabled.


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

Re: Broken links detected...to ApplicationServices ?

[Ryan Schmidt]

On Jan 9, 2016, at 9:33 PM, Craig Treleaven wrote:

> I’m working on a new version of MythTV (0.28) and I’m stymied on the 
> following.  Every program (23), and every library and filter (28) is reported 
> by MacPorts to have a linking error similar to the following:
> 
> --->  Scanning binaries for linking errors
> …
> Incompatible library version: /opt/local/bin/mythavtest requires version 
> 64.0.0 or later, but 
> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices
>  provides version 1.0.0
> DEBUG: Marking /opt/local/bin/mythavtest as broken
> 
> Web searches and whatnot have not turned up any promising leads so I beg the 
> indulgence of those more experienced than I.  
> 
> I’m running OS X 10.10.5 wtih Xcode 7.2 and up-to-date command line tools.  

What do you get when you run:

otool -L 
/System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices
 

On my 10.10 and 10.11 systems, the first two lines are:

/System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices:

/System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices
 (compatibility version 1.0.0, current version 48.0.0)

So, the OS provides ApplicationServices version 48.0.0 which is 
backward-compatible with 1.0.0. I'm not sure where you would have encountered a 
version 64.0.0 of ApplicationServices; it doesn't appear Apple has released any 
version that high yet.

Also, what do you get when you run:

otool -L /opt/local/bin/mythavtest

Maybe you have DYLD_LIBRARY_PATH set to a value that is causing the wrong 
libraries to be used.

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

Re: OSX 10.11 buildbot status ?

[Ryan Schmidt]

On Jan 9, 2016, at 12:28 PM, Chris Jones wrote:

> Just curious, but whats the status of getting a buildbot for 10.11 set up ? 
> Would be good to start proving binary tarballs for this platform.

Yes, that would be good! The status is here:

https://trac.macports.org/ticket/48609


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

Re: [144360] trunk/dports/gnome

[Ryan Schmidt]

On Jan 6, 2016, at 9:44 PM, dev...@macports.org wrote:
> 
> Revision
> 144360
> Author
> dev...@macports.org
> Date
> 2016-01-06 19:44:30 -0800 (Wed, 06 Jan 2016)
> Log Message
> 
> py27-gda: remove obsolete port, no dependents, no replacement.

Looks like you also updated gnotime to 2.4.0, possibly unintentionally.


> Modified Paths
> 
>   • trunk/dports/gnome/gnotime/Portfile
> Removed Paths
> 
>   • trunk/dports/gnome/py27-gda/
> Diff
> 
> Modified: trunk/dports/gnome/gnotime/Portfile (144359 => 144360)
> 
> --- trunk/dports/gnome/gnotime/Portfile   2016-01-07 03:35:12 UTC (rev 
> 144359)
> +++ trunk/dports/gnome/gnotime/Portfile   2016-01-07 03:44:30 UTC (rev 
> 144360)
> 
> @@ -4,7 +4,7 @@
> 
>  PortSystem 1.0
> 
>  
> 
>  name gnotime
> 
> -version  2.1.7
> 
> +version  2.4.0
> 
>  description  A GNOME project manager.
> 
>  long_descriptionGnoTime is a combination stop-watch, diary, \
> 
>   consultant billing system and project manager. \
> 
> @@ -18,7 +18,10 @@
> 
>  platformsdarwin
> 
>  homepage http://gttr.sourceforge.net/
>  master_sitessourceforge:gttr
> 
> -checksumsmd5 f5543b00fb2646e7d2d1619a2aeed31d
> 
> +
> +checksums   rmd160  a0963cad9547c9b25f2ee6280c211a7fcb87e4d2 \
> +sha256  
> a1bf1389829e5795016cc49810c8be80f9bbccb5d56e97f00efb0718559a539b
> +
> 
>  depends_buildport:pkgconfig
> 
>  depends_lib  bin:guile:guile port:libgtkhtml port:libgnome port:libgnomeui
> 
>  configure.cppflags-append "-L${prefix}/lib"

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

Re: [144336] trunk/dports/science/silo/Portfile

[Ryan Schmidt]

On Jan 6, 2016, at 1:21 PM, dstru...@macports.org wrote:
> 
> Revision
> 144336
> Author
> dstru...@macports.org
> Date
> 2016-01-06 11:21:10 -0800 (Wed, 06 Jan 2016)
> Log Message
> 
> silo: Use compilers portgroup for Fortran variants. Clarify meaning in 
> description. Update livecheck. Remove irrelevant comment. Add caution about 
> MPI with HDF5.

Well, the comment was relevant in that it documented the error message one got 
when ccache was used, thus explaining why it had been disabled for this port.

> Modified Paths
> 
>   • trunk/dports/science/silo/Portfile
> Diff
> 
> Modified: trunk/dports/science/silo/Portfile (144335 => 144336)

> -# Makefile:152: *** missing separator.  Stop.
> +compilers.choosefc f77 f90
> +compilers.setup
> +
>  configure.ccacheno

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

Re: [144262] trunk/dports/lang/py-htmldocs/Portfile

[Ryan Schmidt]

On Jan 7, 2016, at 12:12 PM, Eric A. Borisch wrote:

> Bringing this back to the original point, it looks like there was some
> discussion (I think) in this thread of making alocation (possibly
> integrated in terms of access accounts with svn commit access)
> available to store a 'snapshot' of a 'distfile' for instances like
> this (where the source performs nightly refreshes of the tarball
> without version information in the name.)
> 
> So is that going to happen (soon), or is the desire I bake something
> else up (drafting off curl-ca-bundle or graphviz-devel) for now?


I have no plans to implement an arbitrary-file-hosting infrastructure for 
MacPorts in the near future, and lots of other things I need to be working on. 
You should solve the problem in the portfile.

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

Re: [144322] trunk/dports/python/py-keyczar/Portfile

[Ryan Schmidt]

On Jan 7, 2016, at 8:39 AM, Andrew Fernandes wrote:

>> This is not the correct usage of the github portgroup. The correct usage is:
>> 
>> github.setupgoogle keyczar 0.715 Python_release_
> 
> Ah. Of course. I’m so used to looking and seeing a ‘v’ for a prefix, I 
> overlooked the obvious.
> 
>> Why must it fetch from git?
> 
> Because I couldn’t get it to fetch the tarball; that’s fixed now.
> 
>> Once the usage of github.setup is corrected as above, this line should be 
>> unnecessary.
> 
> Done.
> 
>>> +build.cmd   cd python && ${python.bin} setup.py --no-user-cfg
>>> +destroot.cmdcd python && ${python.bin} setup.py --no-user-cfg
>> 
>> Using "cd" in a build.cmd/destroot.cmd is unusual. Is there a reason why you 
>> didn't instead set build.dir?
> 
> Yes, because it doesn’t work.
> 
> The python code is built in a subdirectory of the tarball, and I looked and 
> looked, and that seemed to be the only way to do it.

I tried replacing those two lines with:

build.dir   ${worksrcpath}/python

and it seemed to build ok. Does that work for you?



> Committing the fixes as you suggested now.
> 
> -A.

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

Re: [144262] trunk/dports/lang/py-htmldocs/Portfile

[Ryan Schmidt]

On Jan 6, 2016, at 4:44 AM, Russell Jones wrote:

> I was thinking you might use git+https://github.com/python/cpython.git/Doc 
> with a set checkout id using the GitHub PortGroup, but that would require 
> building the docs.
> 
> How about using https://docs.python.org and relying on python.org's SSL cert 
> to ensure the integrity rather than the MacPorts checksum?

An SSL certificate does not guarantee the user is getting the same files the 
maintainer did. It only guarantees the user is talking to the same server. The 
server could be compromised, or (as is the case here) the developers could 
issue stealth updates.


One solution is to let the MacPorts distfiles mirror mirror the file, then 
switch the portfile to only look at the distfiles mirror, not the original 
server. This would need to be done every time you update the port. See the 
history of the graphviz-devel port for an example of this; their automated 
tarball generation system was recently changed and it now sometimes 
inadvertently repackages the current version with a stealth update. If this is 
going to happen often, as seems to be the case with py-htmldocs, it can be 
automated in the Portfile, to a degree. See the curl-ca-bundle subport of the 
curl port for an example of that. 

The ideal would be to work with the developers to convince them not to issue 
stealth updates.


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

Re: pymol-devel obsolete?

[Ryan Schmidt]

On Jan 5, 2016, at 5:19 PM, David Strubbe wrote:

> I propose to make the port pymol-devel obsolete. There is a pymol port, which 
> is a newer version of the same software. It is not clear what, if any, 
> purpose pymol-devel serves, though years ago it was a newer version than the 
> pymol port (no clear reason was stated at the time for why this was useful, 
> either). pymol-devel has had no maintainer since 3 years ago (r105836). Since 
> that time it has not been updated, and only received maintenance commits. The 
> confusing nature of this port was discussed in this ticket a year and a half 
> ago: http://trac.macports.org/ticket/42860
> 
> Does anyone think pymol-devel should be kept?

I have no objection to marking pymol-devel "replaced_by pymol". I'm Cc'ing the 
maintainer of pymol in case he has an opinion on the matter.


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

Re: uploading distfiles directly to the distfiles mirror

[Ryan Schmidt]

On Jan 6, 2016, at 7:51 PM, Daniel J. Luke wrote:

> On Jan 6, 2016, at 8:35 PM, Ryan Schmidt <ryandes...@macports.org> wrote:
>> How would you envision this capability being provided? I wouldn't want to, 
>> for example, just open up ftp write access to the distfiles server to anyone 
>> who asked for it.
> 
> maybe for maintainers (or committers only)?
> 
> and probably 'sftp' instead of 'ftp'
> 
>> Would we make a web page where people can upload a distfile for a particular 
>> port?
> 
> sure, that would work too.
> 
> I would think people's mirrors would go in a user directory too (similar to 
> how the svn stuff worked) - so it would be obvious that it was a 
> maintainer/committer sourced distfile.

In that case, this is sounding like a different and separate file hosting 
service we could provide, not to be thought of as part of the distfile mirror.



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

Re: uploading distfiles directly to the distfiles mirror (was: Re: [144262] trunk/dports/lang/py-htmldocs/Portfile)

[Ryan Schmidt]

On Jan 6, 2016, at 7:29 PM, Daniel J. Luke wrote:
> 
> Can we make it easier for maintainers to add files to the mirrors? When we 
> used to put files into subversion, it was easy for any maintainer to avoid 
> this problem by just checking in a snapshot. While it's undesirable to go 
> back to that (storing lots of binaries in our svn repo isn't a great idea), 
> being able to upload a snapshot again would be welcome.
> 
> It would fix this and to some extent also make it less 'necessary' for people 
> to have ports fetching from source control systems (giving everyone the 
> benefit of having the files mirrored and cacheable).

How would you envision this capability being provided? I wouldn't want to, for 
example, just open up ftp write access to the distfiles server to anyone who 
asked for it.

Would we make a web page where people can upload a distfile for a particular 
port?

Would we make a new port command to submit a distfile?


I don't really want to be in the business of distributing our own files. The 
purpose of the mirror is to mirror files the developers provide elsewhere.

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

Re: [144322] trunk/dports/python/py-keyczar/Portfile

[Ryan Schmidt]

> On Jan 6, 2016, at 10:12 AM, adfernan...@macports.org wrote:
> 
> Revision
> 144322
> Author
> adfernan...@macports.org
> Date
> 2016-01-06 08:12:47 -0800 (Wed, 06 Jan 2016)
> Log Message
> 
> python/py-keyczar: fix portfile for silent failures that only buildbot showed 
> (grr)
> Modified Paths
> 
>   • trunk/dports/python/py-keyczar/Portfile
> Diff
> 
> Modified: trunk/dports/python/py-keyczar/Portfile (144321 => 144322)

> +github.setupgoogle keyczar Python_release_0.715
> +
> +regexp {([^_]+)$} ${version} version

This is not the correct usage of the github portgroup. The correct usage is:

github.setupgoogle keyczar 0.715 Python_release_


> +fetch.type  git

Why must it fetch from git?


> +worksrcdir  python-keyczar-Python_release_${version}

Once the usage of github.setup is corrected as above, this line should be 
unnecessary.


> +build.cmd   cd python && ${python.bin} setup.py --no-user-cfg
> +destroot.cmdcd python && ${python.bin} setup.py --no-user-cfg

Using "cd" in a build.cmd/destroot.cmd is unusual. Is there a reason why you 
didn't instead set build.dir?


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

Re: blitz-devel: Mercurial clone failed

[Ryan Schmidt]

On Jan 5, 2016, at 12:11 PM, David Strubbe wrote:

> I just made an update (unrelated to fetching) to blitz-devel, a nomaintainer 
> port, and got this error below from each buildbot, even though it worked fine 
> on my machine. Anyone know what this is about?
> 
> Thanks,
> David
> 
> DEBUG: Executing org.macports.fetch (blitz-devel)
> DEBUG: Executing: /opt/local/bin/hg clone --rev "8749c555825c" 
> http://blitz.hg.sourceforge.net:8000/hgroot/blitz/blitz 
> /opt/local/var/macports/build/_opt_mports_dports_math_blitz-devel/blitz-devel/work/blitz-devel-0.10-20151126
>  2>&1
> abort: error: Connection refused
> Command failed: /opt/local/bin/hg clone --rev "8749c555825c" 
> http://blitz.hg.sourceforge.net:8000/hgroot/blitz/blitz 
> /opt/local/var/macports/build/_opt_mports_dports_math_blitz-devel/blitz-devel/work/blitz-devel-0.10-20151126
>  2>&1
> Exit code: 255
> Error: org.macports.fetch for port blitz-devel returned: Mercurial clone 
> failed

The network the buildbot machines live on is not configured to permit them to 
access servers on port 8000.

This is the ticket about this problem:

https://trac.macports.org/ticket/49906

blitz-devel is the only port I know of that tries to fetch on port 8000 so this 
is not a major problem.

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

Re: [143999] trunk/dports/textproc

[Ryan Schmidt]

On Jan 5, 2016, at 7:32 AM, Rainer Müller wrote:

> On 2016-01-04 07:45, Mojca Miklavec wrote:
>> I agree with Ryan here. But then again the port depends on poppler
>> which would probably be built with libstdc++ by default unless the
>> whole MacPorts is configured to use libc++. I'm not sure what strategy
>> could be used in these cases.
> 
> I would assume the whole installation uses libc++ if
> configure.cxx_stdlib is set to libc++.

Yes. The strategy that is meant to be used is: include the cxx11 1.0 portgroup. 
Doing so indicates that the software requires C++11. If the user's MacPorts 
installation uses libstdc++, the portgroup will prevent the port from being 
installed, and will direct the user to the LibcxxOnOlderSystems wiki page which 
will give the user instructions for either upgrading their OS or reinstalling 
all ports with libc++.


> Using that check in the cxx11 port group seems better. However, what
> would be a good way to point users to the pdfgrep-legacy port?
> 
> a) Extend the cxx11 port group to allow a custom message pointing to
>   pdfgrep-legacy.
> b) Drop the old version and users that want pdfgrep have to switch to
>   libc++.

That's a good question. I'm not sure.

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

Re: Perl 6

[Ryan Schmidt]

On Jan 5, 2016, at 5:52 AM, Carlo Tambuatco wrote:

> Will this work with perl_select…? My installation of perl_select has been a 
> bit flaky.

As far as I know, MacPorts does not contain anything called "perl_select".

We have "port select", but it does not handle perl; adding this feature is 
difficult. See https://trac.macports.org/ticket/29763


> I have perl5.22, 5.16 and 5.18 installed but I had to install a specific 
> variant of perl5 to get it to work with all those different perls. 

That is the currently correct method for selecting the desired perl version 
that should be symlinked at /opt/local/bin/perl and /opt/local/bin/perl5.


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

Re: [144262] trunk/dports/lang/py-htmldocs/Portfile

[Ryan Schmidt]

> On Jan 5, 2016, at 12:43 PM, ebori...@macports.org wrote:
> 
> Revision
> 144262
> Author
> ebori...@macports.org
> Date
> 2016-01-05 10:43:29 -0800 (Tue, 05 Jan 2016)
> Log Message
> 
> py-htmldocs: 34 and 35 tarballs appear to be updated nightly; skip checksums. 
> (At least we don't install any execs/libs.) Move dist_subdir line so it grabs 
> correct revision.
> Modified Paths
>   • trunk/dports/lang/py-htmldocs/Portfile

>  if {${python.version} == 34} {
>master_sites  http://docs.python.org/${python.branch}/archives
> -  checksums \
> -rmd160  61a2f71b85b5e50c38de8e5616ffd87a4a382bf6 \
> -sha256  
> 8554b59a5aea9801ae735cafd13585f6e07c25cb71dba2402bd4eacfc05ee2e0
> +  # These seem to be re-generated daily.
> +  checksum {}
>  }
>  
>  if {${python.version} == 35} {
>master_sites  http://docs.python.org/${python.branch}/archives
>set revision  [expr ${base_rev}+1] 
> -  checksums \
> -rmd160  3e99602293474b478c97ee7ba004065ab65d9196 \
> -sha256  
> 1e395e25837fd8898cdd56511c6b56a2ceaace3145e2913e3544a4dfa0f63916
> +  # These seem to be re-generated daily.
> +  checksum {}

I'm not comfortable with installing unchecked files on user systems. The whole 
point of the checksum system is to verify that the files that are installed on 
user systems are the same files that were tested by the maintainer. By skipping 
the checksum phase you remove that safeguard.


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

Re: Perl 6

[Ryan Schmidt]

On Jan 5, 2016, at 1:27 PM, Brandon Allbery wrote:
> On Tue, Jan 5, 2016 at 2:24 PM, Ryan Schmidt wrote:
>> As far as I know, MacPorts does not contain anything called "perl_select".
> 
> There is, actually, but it's a stub that doesn't do anything as yet (or 
> probably ever since it was subsequently decided to just move to a single Perl 
> release).

Ok, granted, there is a perl_select port, but there is no perl_select program.


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

Re: [144182] trunk/dports/java/gant/Portfile

[Ryan Schmidt]

On Jan 3, 2016, at 8:22 PM, khindenb...@macports.org wrote:
> 
> Revision
> 144182
> Author
> khindenb...@macports.org
> Date
> 2016-01-03 18:22:43 -0800 (Sun, 03 Jan 2016)
> Log Message
> 
> gant: port fixes from #29303; change to github
> Modified Paths
> 
>   • trunk/dports/java/gant/Portfile
> Diff
> 
> Modified: trunk/dports/java/gant/Portfile (144181 => 144182)
> 
> --- trunk/dports/java/gant/Portfile   2016-01-04 01:56:12 UTC (rev 144181)
> +++ trunk/dports/java/gant/Portfile   2016-01-04 02:22:43 UTC (rev 144182)
> @@ -1,9 +1,10 @@
>  # $Id$
>  
>  PortSystem 1.0
> +PortGroup   github 1.0
>  
> +github.setupGant Gant 1.9.5
>  name gant
> -version  1.9.5
>  categories   java devel groovy
>  maintainers  nomaintainer
>  description  A groovy based tool for scripting ant
> @@ -15,19 +16,12 @@
>   an alternative way of doing things 
> using Ant, but using a \
>   programming language rather than XML to 
> specify the rules.
>   
> -homepage http://gant.codehaus.org/
>  platformsdarwin
> -distname ${name}-${version}
> -master_sites http://dist.codehaus.org/gant/distributions
>  checksumsmd5 6930a7bd5209fb6d1e9e8186fd4b18fb \
>   sha1 
> 919c750128af22797b1d53de37c70deda5676ea7 \
>   rmd160 
> 2b23c6e2696629d9fb8878568955e459d51ebcc3

This causes a checksum mismatch because the autogenerated github zipball is not 
the same as the one that was previously hosted on codehaus. Fixed in r144195. 
I'll also look into updating gant to a newer version from github.



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

Re: [144186] trunk/dports

[Ryan Schmidt]

> On Jan 4, 2016, at 12:56 AM, dev...@macports.org wrote:
> 
> Revision
> 144186
> Author
> dev...@macports.org
> Date
> 2016-01-03 22:56:45 -0800 (Sun, 03 Jan 2016)
> Log Message
> 
> misc ports: increment revision to remove references to libncurses.5.

> Modified Paths
> 
>   • trunk/dports/databases/libgda4/Portfile
>   • trunk/dports/gnome/vte-2.90/Portfile
>   • trunk/dports/gnome/vte-gtk2-compat/Portfile
>   • trunk/dports/lang/guile18/Portfile

None of these ports declare a library dependency on ncurses. If they link with 
libncurses, they should have that, else this is just going to be forgotten 
again next time ncurses is updated to a new library version.


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

Re: [143999] trunk/dports/textproc

[Ryan Schmidt]

> On Dec 29, 2015, at 12:49 PM, rai...@macports.org wrote:
> 
> Revision
> 143999
> Author
> rai...@macports.org
> Date
> 2015-12-29 10:49:23 -0800 (Tue, 29 Dec 2015)
> Log Message
> 
> textproc/pdfgrep, textproc/pdfgrep-legacy:
> Add new pdfgrep-legacy port for old versions of OS X, closes #50076
> 
> Modified Paths
> 
>   • trunk/dports/textproc/pdfgrep/Portfile
> Added Paths
> 
>   • trunk/dports/textproc/pdfgrep-legacy/
>   • trunk/dports/textproc/pdfgrep-legacy/Portfile
> Diff
> 
> Modified: trunk/dports/textproc/pdfgrep/Portfile (143998 => 143999)

> +pre-fetch {
> +if {${name} == ${subport} && ${os.platform} eq "darwin" && ${os.major} < 
> 13} {
> +ui_error "${name} only runs on Mac OS X 10.9 or greater as it 
> requires features of C++11. Please install pdfgrep-legacy instead."
> +return -code error "incompatible Mac OS X version"
> +}
> +}
> +

Can this check ${configure.cxx_stdlib} instead of ${os.major}? Or better yet, 
can it just include the cxx11 1.0 portgroup and let it handle the details?


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

Re: [144027] trunk/dports/lang/py-htmldocs/Portfile

[Ryan Schmidt]

> On Dec 30, 2015, at 12:10 AM, ebori...@macports.org wrote:
> 
> Revision
> 144027
> Author
> ebori...@macports.org
> Date
> 2015-12-29 22:10:10 -0800 (Tue, 29 Dec 2015)
> Log Message
> 
> py-htmldocs: Update (again?) checksum for py35-htmldocs. Moved revision 
> numbers into by-subport for bumping when checksums change. See #50172.
> Modified Paths
> 
>   • trunk/dports/lang/py-htmldocs/Portfile
> Diff
> 
> Modified: trunk/dports/lang/py-htmldocs/Portfile (144026 => 144027)
> 
> --- trunk/dports/lang/py-htmldocs/Portfile2015-12-30 05:55:28 UTC (rev 
> 144026)
> +++ trunk/dports/lang/py-htmldocs/Portfile2015-12-30 06:10:10 UTC (rev 
> 144027)
> @@ -47,45 +47,52 @@
>  notes   ${long_description}
>  
>  if {${python.version} == 26} {
> +  revision  1
>checksums \
>  rmd160  a7bd375ac3a62249529da805693c3b15510ff976 \
>  sha256  
> f3faa71f4b0cc8fa2bb6c5624233ae79983a2d5c11195fb2089668c60ceb7f1f
>  }
>  
>  if {${python.version} == 27} {
> +  revision  2
>checksums \
>  rmd160  5962cd9d48d5678a832cfef7a693ffcadb66d55e \
>  sha256  
> a6b61188de5e26295533a619f0e89dd180c6b4385d27e3239581de8aa1d4ceaf
>  }
>  
>  if {${python.version} == 31} {
> +  revision  1
>checksums \
>  rmd160  29717979d6a8b4e970a4747e101259da3e3890c1 \
>  sha256  
> ff327cfaa1219d8d82fcb4f3bae3ec4ce28567982a49784004130521d282faa0
>  }
>  
>  if {${python.version} == 32} {
> +  revision  1
>checksums \
>  rmd160  039539fc90454d35525c8b9478156f7135b86622 \
>  sha256  
> b746ef40a29abe7949e5f183e236a0734c58b841c0600043160a518390704c13
>  }
>  
>  if {${python.version} == 33} {
> +  revision  1
>checksums \
>  rmd160  84290bfaea54b943025f7088268f256d4a50cf71 \
>  sha256  
> 54da33f8a91be819e7ac22fdc88c5125bdd4c67494f52dd79d6b603572c41fb0
>  }
>  
>  if {${python.version} == 34} {
> +  revision  1
>checksums \
>  rmd160  3cfdc8682fee199be83163026aa2a387f36e14af \
>  sha256  
> 62690cf2d6781cf761aa4ae3c81b8a794700f6b61e4cef0cadbcf4f96a5b7da1
>  }
>  
>  if {${python.version} == 35} {
> +  revision  2
>checksums \
> -rmd160  dc49af77633fbb4c4766cd313f1609295d5a0438 \
> -sha256  
> 1bf4aa73555eb1c38504ab4ef8368c15d6e026b0669d477f7e7d3db8edfae75b
> +rmd160  708cb554c1b80bcf795f89936ca9bdac11abffb5 \
> +sha256  
> ad75e90b950c6abfae550680576ad8ffa48d8ef579fcb98687037590c7576d98
>  }

Stealth updates need to be handled per this recipe:

https://trac.macports.org/wiki/PortfileRecipes#stealth-updates

py-htmldocs is not handling the dist_subdir correctly.


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

Re: [144013] trunk/dports/gis/qlandkartegt/Portfile

[Ryan Schmidt]

> On Dec 29, 2015, at 8:43 PM, khindenb...@macports.org wrote:
> 
> Revision
> 144013
> Author
> khindenb...@macports.org
> Date
> 2015-12-29 18:43:19 -0800 (Tue, 29 Dec 2015)
> Log Message
> 
> qlandkartegt: add qt4 portgroup, enable cmake.out_of_source build maintainer 
> #49432

> Modified: trunk/dports/gis/qlandkartegt/Portfile (144012 => 144013)

> @@ -33,9 +35,11 @@
>  
>  patchfiles   patch-src-main.cpp.diff
>  
> +cmake.out_of_source yes
> +
>  destroot {
>  xinstall -d ${destroot}${applications_dir}
> -copy "${worksrcpath}/bin/QLandkarte GT.app" 
> ${destroot}${applications_dir}
> +copy "${workpath}/build/bin/QLandkarte GT.app" 
> ${destroot}${applications_dir}
>  }

You probably should not assume that the build directory is ${workpath}/build. 
That's an implementation detail of the cmake portgroup. You should use the 
${destroot.dir} variable instead.

There's also no need here to create ${destroot}${applications_dir}. MacPorts 
creates this and other standard directories for you automatically before the 
destroot phase runs.

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

Re: Survey: How do you commit?

[Ryan Schmidt]

On Jan 2, 2016, at 6:22 AM, Joshua Root wrote:

> Works pretty well for the most part. Would be nice if it had commit
> shelving .

The closest feature that exists is the changelist: 
http://svnbook.red-bean.com/en/1.7/svn.ref.svn.c.changelist.html

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

Survey: How do you commit?

[Ryan Schmidt]

Quick survey for committers:

How do you commit to the MacPorts Subversion repository?

Using a Subversion working copy and "svn commit"?
Using a Git clone and git-svn?
Some other method?

Do you have any complaints about that method or are you happy with it?


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