Re: Tcl question: expansion of variable names

[Ryan Schmidt]

On Sep 4, 2018, at 08:13, Mojca Miklavec wrote:

> Dear Joshua,
> 
> On Tue, 4 Sep 2018 at 14:04, Joshua Root wrote:
>> On 2018-9-4 19:15 , Mojca Miklavec wrote:
>>> Hi,
>>> 
>>> I would like to ask for some help making a little trick work. Here's
>>> my attempt of a PR:
>>>https://github.com/macports/macports-ports/pull/2509/files
>>> 
>>> Each subport has a different checksum URL:
>>>https://geant4.web.cern.ch/support/download_archive?page=0
>>>https://geant4.web.cern.ch/support/download_archive?page=1
>>>https://geant4.web.cern.ch/support/download_archive?page=2
>>> etc.
>>> 
>>> I would like to code this inside a table, but somehow I cannot figure
>>> out how to properly resolve the variable names when using this hack.
>> 
>> Wrapping a string in braces disables variable substitution. Use quotes,
> 
> Thank you, this worked.
> 
>> or better, the list command, if you want to set geant.versions_info to a
>> list with substituted variables.
> 
> This is where I'm not sure where or how to apply the list command. I
> tried a couple of ways, none of which worked :)

It should be a simple as replacing

set myvar "a b c"

with

set myvar [list a b c]

I've never been quite clear on the benefits of using [list] vs just making a 
string, since a string is a list, and I seem to use them interchangeably. 

Re: squash and merge, license documentation, "size" documentation

[Ryan Schmidt]

On Aug 22, 2018, at 13:46, Jan Stary wrote:

> On Aug 21 22:58:07, j...@macports.org wrote:
>> On 2018-8-18 06:06 , Clemens Lang wrote:
>>> I think the idea of the size keyword is to start to use it to display
>>> download progress bars for servers that do not send a Content-Length
>>> HTTP header (or do not have an equivalent of such a header due to the
>>> used protocol). This is currently not implemented.
>>> 
>>> 'port -v checksums' does generate the size field in newer versions of
>>> MacPorts. Until such a version becomes the released default, I think
>>> it's fine not to require adding it in PRs.
>> 
>> Not accepting PRs until they add it is certainly not a good approach.
>> Recommend using it in all the docs, certainly. But don't put extra
>> burden on both contributors and reviewers for the sake of an
>> unimplemented minor feature.
> 
> https://github.com/macports/macports-ports/pull/2371
> has been rotting for two weeks for exactly that.

In this case, you removed the size from a port that already had it. This is 
actively undoing the work of other contributors. Please try not to undermine 
what the rest of us are doing.

Re: Help wanted doing some xorg-* updates

[Ryan Schmidt]

On Aug 22, 2018, at 20:30, Perry E. Metzger wrote:

> After seeing a security advisory on one of the xorg ports and
> realizing that we hadn't updated a bunch of them in a while and that
> xquartz (the project) seems pretty dead, I started going in and
> updating various things in xorg-* that hadn't been updated in a while.

XQuartz and the MacPorts xorg-* ports are both maintained by Jeremy, who as you 
know hasn't been very active in MacPorts lately. Previously he's been good 
about these updates, but it wouldn't surprise me if he has other commitments at 
work right now, given that the next OS is just around the corner.


> The bulk of them were minor revision number bumps and seemed safe, so
> I've done them already, but the following seemed more involved because
> either there were significant version number bumps:
> 
> xorg-libXres   (our version: 1.0.7, livecheck says it's: 1.2.0)
> 
> ...or because there were patch files involved:
> 
> xorg-libxcb(our version: 1.12, livecheck says it's: 1.13)
> xorg-xcb-proto (our version: 1.12, livecheck says it's: 1.13)
> 
> ...or both
> 
> xorg-server(our version: 1.18.4, livecheck says it's: 1.20.1)
> 
> Help with these four is actively solicited. It would be good to make
> sure we're up to date, especially given that X11 updates are often
> security sensitive.
> 
> There's also the curious case of xorg-libXfont2, where our version
> seems to be ahead of the livecheck version, and I'm just plain
> confused about what is going on.

For me, livecheck shows that xorg-libXfont2 is up to date.

Re: squash and merge, license documentation, "size" documentation

[Ryan Schmidt]

On Aug 17, 2018, at 15:06, Clemens Lang wrote:

> I think the idea of the size keyword is to start to use it to display
> download progress bars for servers that do not send a Content-Length
> HTTP header (or do not have an equivalent of such a header due to the
> used protocol). This is currently not implemented.

I looked into implementing it once, but it seemed like there was a great 
distance between the place where the checksum data was available and the place 
where the curl progress bar was being shown; I could not immediately imagine 
how the size information should be propagated between those two places. (For 
example, should an expected_size parameter be added to each of several function 
calls along the way?)


> 'port -v checksums' does generate the size field in newer versions of
> MacPorts. Until such a version becomes the released default, I think
> it's fine not to require adding it in PRs.

It was released in MacPorts 2.4.4.

Re: [macports-ports] 05/05: py-nbconvert: add py37 variant

[Ryan Schmidt]

On Aug 15, 2018, at 01:35, Andrew Stromnov wrote:

> Andrew Stromnov (stromnov) pushed a commit to branch master
> in repository macports-ports.
> 
> 
> https://github.com/macports/macports-ports/commit/efcf55361d5dd2a42f115372c8f741ac4ec8f674
> 
> commit efcf55361d5dd2a42f115372c8f741ac4ec8f674
> 
> Author: Andrew Stromnov
> AuthorDate: Wed Aug 15 09:35:25 2018 +0300
> 
> 
> py-nbconvert: add py37 variant

Subport :)

Re: non-integer epoch?

[Ryan Schmidt]

On Aug 11, 2018, at 15:58, René J.V. Bertin wrote:

>> " Some Portfile authors have used large epoch values that look like a date, 
>> but there is no reason to do so"
> 
> nor is there a reason not to (that's not based on an ad-hoc decision) ...
> 
> The doc reads a bit as if the epoch is equivalent to the `N:` element that 
> some Debian/Ubuntu packages prepend to the version, except that that element 
> is visible to the user so they can understand seemingly counter-intuitive 
> version progressions.
> (Note that I'm not perfectly certain what that N: element stands for.)
> 
> 
>>> A question though: what epoch was being used for those ports of mine - just 
>>> the `floor(epoch)` (or `(int)(epoch)`) value? If I'm going to have to 
>>> correct my ports I'd just as well avoid the introduction of a new epoch ...
>> 
>> I have no idea.
> 
> 
> Let me rephase: how does one query the epoch value for an installed port?

Well it's probably in the registry. You could open the registry in an SQLite 
client and query it (after loading the MacPorts SQLite plugin).

Re: non-integer epoch?

[Ryan Schmidt]

On Aug 11, 2018, at 10:13, René J.V. Bertin wrote:

> I've been using non-integer (but numerical) epochs in a few of my ports just 
> because it made sense to set it e.g. to 5.1 when I started using the 5.1 
> branch in a port. AFAIK the property is purely internal so it could be 
> anything (i.e. a string), much more so than the revision. In fact I thought 
> MacPorts only uses it to divide the version timeline into individual epochs 
> which don't have a chronological relationship among each other, no?
> 
> I can imagine that it won't be easy to change the type used internally for 
> the epoch so this is not a suggestion to change it (but if possible, yeah, I 
> think it'd be a good idea to make it a string entity).

epoch and revision were always meant to be nonnegative integers. In the latest 
version of MacPorts, this is now enforced.


> A question though: what epoch was being used for those ports of mine - just 
> the `floor(epoch)` (or `(int)(epoch)`) value? If I'm going to have to correct 
> my ports I'd just as well avoid the introduction of a new epoch ...

I have no idea.

Re: Homebrew hacked

[Ryan Schmidt]

On Aug 8, 2018, at 10:11, Craig Treleaven wrote:

> I ran across an article this morning describing how Homebrew was hacked with 
> a few minutes effort:
> 
> https://medium.com/@vesirin/how-i-gained-commit-access-to-homebrew-in-30-minutes-2ae314df03ab
> 
> Has anybody checked to see if we have any similar exposures in the MacPorts 
> infrastructure?

The problem reported there appears to be that a GitHub access token with write 
access to the Homebrew repositories was exposed in the logs of their automated 
build infrastructure, which the user was able to use to commit a change to the 
repositories, as a demonstration of the problem; nothing malicious was done.

As far as I can tell, none of the access tokens we have set up for the 
"macportsbot" user (which performs automated interactions with pull requests 
and our Trac and Buildbot installations) allow write access to our 
repositories, so the same vulnerability does not exist for us.

The user reported that the Homebrew repositories allowed developers to commit 
directly to master, and considered this to be bad. We do allow developers to 
commit directly to the MacPorts repositories, including master; this matches 
our previous methodology using Subversion before we moved to GitHub. If someone 
thinks we should change this policy, please open a topic on this list and 
discuss it.

All commits to our repositories are emailed to the macports-changes mailing 
list. MacPorts developers are encouraged to subscribe to this list and read 
those emails. If something malicious gets committed, the hope is that someone 
reading that mailing list would notice the problem and correct it. I don't 
recall anything malicious ever getting committed to MacPorts so far.

Re: [macports-ports] 01/02: at-spi2-core: update to version 2.28.0

[Ryan Schmidt]

On Aug 3, 2018, at 18:01, David B. Evans wrote:

> David B. Evans (dbevans) pushed a commit to branch master
> in repository macports-ports.
> 
> 
> https://github.com/macports/macports-ports/commit/7d5300f0703c626ec2f649b38c023bbd42093236
> 
> commit 7d5300f0703c626ec2f649b38c023bbd42093236
> 
> Author: David B. Evans
> AuthorDate: Fri Aug 3 10:43:09 2018 -0700
> 
> 
> at-spi2-core: update to version 2.28.0
> 
> 
> 
> Now builds using meson. Minor reformatting.
> 
> ---
>  gnome/at-spi2-core/Portfile | 44 +---
>  1 file changed, 25 insertions(+), 19 deletions(-)
> 
> 
> diff --git a/gnome/at-spi2-core/Portfile b/gnome/at-spi2-core/Portfile
> index 186361d..f4c9607 100644
> --- a/gnome/at-spi2-core/Portfile
> +++ b/gnome/at-spi2-core/Portfile
> @@ -1,22 +1,19 @@
>  # -*- 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
>  
>  PortSystem  1.0
> -PortGroup   gobject_introspection 1.0
> +PortGroup   meson 1.0
> +PortGroup   muniversal 1.0

>  depends_lib path:lib/pkgconfig/glib-2.0.pc:glib2 \
>  port:dbus \
> +port:gobject-introspection \
>  port:xorg-libX11 \
>  port:xorg-libXi \
>  port:xorg-libXtst \
>  port:xorg-libice \
>  port:xorg-libsm
>  
> -gobject_introspection yes

> +configure.args  -Denable-introspection=yes
> +
> +# gobject-introspection uses g-ir-scanner, which uses $CC from env
> +if {[variant_isset universal]} {
> +foreach arch ${configure.universal_archs} {
> +lappend merger_build_env(${arch})  CC='${configure.cc} -arch ${arch}'
> +lappend merger_destroot_env(${arch})  CC='${configure.cc} -arch 
> ${arch}'
> +}
> +} else {
> +build.env-append   CC="${configure.cc} ${configure.cc_archflags}"
> +destroot.env-appendCC="${configure.cc} ${configure.cc_archflags}"
> +}

I assume the reason for removing the gobject_introspection portgroup, and 
reimplementing its functionality in the port, is that the portgroup is designed 
for autotools and this port has switched to meson. Is there a way the portgroup 
could be enhanced to do the right thing regardless of the build system? That 
would be better than going back to copy/pasting blocks of code into each port 
that uses gobject introspection, which was the problem that the portgroup was 
supposed to solve.

Re: [macports-ports] branch master updated: GDAL: accomodates grass7 bump to 7.4.1

[Ryan Schmidt]

On Aug 2, 2018, at 08:03, Vincent wrote:

> Vincent (Veence) pushed a commit to branch master
> in repository macports-ports.
> 
> 
> https://github.com/macports/macports-ports/commit/a3f753c7a496641b4c85d6494806eee3951eb59b
> 
> The following commit(s) were added to refs/heads/master by this push:
> 
>  new a3f753c  GDAL: accomodates grass7 bump to 7.4.1
> 
> a3f753c is described below
> 
> 
> commit a3f753c7a496641b4c85d6494806eee3951eb59b
> 
> Author: Veence
> AuthorDate: Thu Aug 2 15:03:57 2018 +0200
> 
> 
> GDAL: accomodates grass7 bump to 7.4.1
> 
> ---
>  gis/gdal/Portfile | 34 ++
>  1 file changed, 2 insertions(+), 32 deletions(-)
> 
> diff --git a/gis/gdal/Portfile b/gis/gdal/Portfile
> index e593dbd..d831627 100644
> --- a/gis/gdal/Portfile
> +++ b/gis/gdal/Portfile
> @@ -168,11 +168,11 @@ variant grass description {Enable GRASS 7 GIS I/O} {
>  ui_error "The grass variant requires grass 7 to be installed."
>  ui_error "Since grass7 depends on gdal, please first install gdal 
> WITHOUT the grass variant."
>  ui_error "Then install grass7, then reinstall gdal with the grass 
> variant."
> -return -code error "Missing GRASS 7." 
> +#return -code error "Missing GRASS 7." 

Did you mean to comment this out?


>  } 
>  
>  configure.args-delete   --without-grass
> -configure.args-append   --with-grass=${prefix}/share/grass-7.4.0
> +configure.args-append   --with-grass=${prefix}/share/grass-7.4.1

Re: Darwin 9 PPC tester ?

[Ryan Schmidt]

On Jul 29, 2018, at 13:59, Chris Jones wrote:

> On 29 Jul 2018, at 7:29 pm, Ryan Schmidt wrote:
> 
>> clang does not work on PowerPC.
> 
> Ah, right. I was just looking at 
> 
> http://packages.macports.org/clang-3.4/
> 
> And saw the last versions had a Darwin 9 PPC tarball. Are you saying it 
> builds but does not function properly ?

Yes. See for example https://trac.macports.org/ticket/55473

Some work on getting clang to work on PowrePC has been done; see: 
https://trac.macports.org/ticket/53184

Re: Darwin 9 PPC tester ?

[Ryan Schmidt]

clang does not work on PowerPC.


> On Jul 29, 2018, at 13:20, Christopher Jones  wrote:
> 
> Great thanks.
> 
> I’m hopeful that libgcc is going to be OK, but if not please post a full log 
> to the PR.
> 
> It would be nice if libgcc-devel also built, but this is not so important at 
> this point. I had to blacklist gcc-4.2 to get it to build on intel 10.6 (so 
> fallback to MPs clang-3.4) but I am not sure what this blacklist will do on 
> Darwin 9 PPC. It might try and fallback to a gcc build which will then cause 
> problems with a dependency loop. I am hoping instead it also defaults to 
> clang-3.4 (or we can convince it to). Its also true that gcc9/libgcc-devel is 
> only a snapshot, so things might improve in before a final release (which is 
> why right now I don’t think its a big deal).
> 
> Chris
> 
>> On 29 Jul 2018, at 7:12 pm, Ryan Schmidt  wrote:
>> 
>> 
>> 
>> On Jul 29, 2018, at 11:32, Chris Jones wrote:
>> 
>>> Is there anyone who has a PPC machine running Darwin 9 (OSX 10.5) that 
>>> would be willing to run a test of the PR
>>> 
>>> https://github.com/macports/macports-ports/pull/2296
>>> 
>>> ? For the reasons outlined in the PR it would be useful to know if the port 
>>> libgcc builds properly on this platform. I have tested the rest, 10.6 
>>> upwards, but Darwin 9 is one I don’t have access to.
>> 
>> I'll give it a try!
>> 
> 

Re: Darwin 9 PPC tester ?

[Ryan Schmidt]

On Jul 29, 2018, at 11:32, Chris Jones wrote:

> Is there anyone who has a PPC machine running Darwin 9 (OSX 10.5) that would 
> be willing to run a test of the PR
> 
> https://github.com/macports/macports-ports/pull/2296
> 
> ? For the reasons outlined in the PR it would be useful to know if the port 
> libgcc builds properly on this platform. I have tested the rest, 10.6 
> upwards, but Darwin 9 is one I don’t have access to.

I'll give it a try!

Re: [macports-ports] 06/06: Merge branch 'master' of github.com:macports/macports-ports

[Ryan Schmidt]

On Jul 24, 2018, at 13:51, Mark Moll wrote:

> Mark Moll (mamoll) pushed a commit to branch master
> in repository macports-ports.
> 
> 
> https://github.com/macports/macports-ports/commit/d5637d824ed07189a10a3e32dc135fe909192f8c
> 
> commit d5637d824ed07189a10a3e32dc135fe909192f8c
> 
> Merge: 04b975b d8d582f
> Author: Mark Moll
> AuthorDate: Tue Jul 24 13:51:18 2018 -0500
> 
> 
> Merge branch 'master' of github.com:macports/macports-ports

In the future, please rebase instead of merging, so that we can maintain a 
linear history.

Re: linker errors: ld: unexpected token: !tapi-tbd-v3 file

[Ryan Schmidt]

On Jul 19, 2018, at 17:46, Mark Moll wrote:

> The py-graph-tool port doesn’t compile on High Sierra (10.13) due to a linker 
> error that happens during the configure stage [1]:
> 
> 
> configure:19051: checking consistency of all components of python development 
> environment
> 2037  configure:19079: /opt/local/bin/clang-mp-6.0 -o conftest -pipe -Os 
> -arch x86_64 -DNDEBUG -I/opt/local/include -I/opt/local/include 
> -I/opt/local/Library/Frameworks/Python.framework/Versions/3.6/include/python3.6m/..
>  
> -I/opt/local/Library/Frameworks/Python.framework/Versions/3.6/include/python3.6m
>  -L/opt/local/lib -Wl,-headerpad_max_install_names -L/opt/local/lib -arch 
> x86_64 
> -L/opt/local/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/..
>  -lpython3.6 conftest.c  
> -L/opt/local/Library/Frameworks/Python.framework/Versions/3.6/lib 
> -lpython3.6m -Wl,-stack_size,100 -framework CoreFoundation 
> /opt/local/Library/Frameworks/Python.framework/Versions/3.6/Python 
> -Wl,-stack_size,100 -framework CoreFoundation 
> /opt/local/Library/Frameworks/Python.framework/Versions/3.6/Python >&5
> 2038  ld: unexpected token: !tapi-tbd-v3 file 
> '/System/Library/Frameworks//CoreFoundation.framework/CoreFoundation.tbd' for 
> architecture x86_64
> 2039  clang: error: linker command failed with exit code 1 (use -v to see 
> invocation)
> 
> The error goes away if ld64 is installed with the +ld64_xcode variant. It 
> seems unlikely that py-graph-tool would be the only port affected. Is this a 
> known problem and, if so, what is the correct workaround/fix?

The workaround is the one you found: install ld64 with the +ld64_xcode variant. 
The ld that would otherwise be provided by the ld64-latest port is too old to 
understand what newer compilers are producing.

The correct solution would be to update the ld64-latest port to a newer 
version. But that appears to be difficult. See:

https://trac.macports.org/ticket/53784
 
> 
> Mark
> 
> [1] See: https://trac.macports.org/ticket/56843 and 
> https://trac.macports.org/attachment/ticket/56843/config.log
> 

Re: [macports-ports] branch master updated: Update shibboleth and dependencies to 3.0.0.

[Ryan Schmidt]

On Jul 17, 2018, at 10:54, Scott Cantor wrote:

> Scott Cantor (scantor) pushed a commit to branch master
> in repository macports-ports.
> 
> 
> https://github.com/macports/macports-ports/commit/2ef05daf9bd5363708c60a6ddf04ac8a02221356
> 
> The following commit(s) were added to refs/heads/master by this push:
> 
>  new 2ef05da  Update shibboleth and dependencies to 3.0.0.
> 
> 2ef05da is described below
> 
> 
> commit 2ef05daf9bd5363708c60a6ddf04ac8a02221356
> 
> Author: Scott Cantor 

Remember to configure your git client to use your MacPorts email address. See:

https://trac.macports.org/wiki/WorkingWithGit#setup


>  lang/opensaml/Portfile   | 16 ++--
>  security/shibboleth/Portfile | 24 
>  security/xmltooling/Portfile | 18 +++---


> @@ -19,16 +18,13 @@ depends_lib port:xmltooling \
>  port:xml-security-c \
>  port:xercesc3 \
>  port:log4shib \
> -port:boost
> +port:boost \
> +port:pkgconfig

Do these three ports really use pkgconfig at runtime? Usually it's only used at 
build time. There are some exceptions, but it's unusual enough that it warrants 
explaining it with a comment in the portfile if that's the case here.

Re: [macports-ports] 01/02: xml-security-c: update to 2.0.0

[Ryan Schmidt]

On Jul 13, 2018, at 21:33, Jeremy L wrote:

> On 07/05/2018 01:29 AM, Ryan Schmidt wrote:
>> On Jul 4, 2018, at 14:07, Jeremy L wrote:
>>> Jeremy L (nerdling) pushed a commit to branch master
>>> in repository macports-ports.
>>> 
>>> 
>>> https://github.com/macports/macports-ports/commit/0ef87ed1231742cf86a026814f6e866fef4268db
>>> 
>>> commit 0ef87ed1231742cf86a026814f6e866fef4268db
>>> 
>>> Author: Jeremy Lavergne
>>> AuthorDate: Wed Jul 4 14:54:28 2018 -0400
>>> 
>>> 
>>> xml-security-c: update to 2.0.0
>> The library version has increased from 17 to 20. There are three ports that 
>> declare a dependency on this port. Do any of them link with the library? If 
>> so, their revisions need to be increased to rebuild them.
>>> -depends_lib port:xercesc3 path:lib/libssl.dylib:openssl
>>> +depends_lib port:xercesc3 path:lib/libssl.dylib:openssl 
>>> port:pkgconfig
>> Does it really use pkgconfig at runtime?
> 
> These sound like good candidates for lint/tests :-)

In the case of the first issue, "lint" has no knowledge of previous versions of 
the Portfile, and it has no knowledge of what files the port installs. There is 
no way "lint" can help you know when you need to increase the revision of 
dependencies. You need to pay attention to that sort of thing yourself.

For the second issue, yes, "lint" could issue a warning when certain ports that 
are commonly used as build dependencies are possibly inadvertently listed as 
non-build dependencies. However this would result in false warnings in those 
few ports that have a legitimate reason to declare a non-build dependency on 
one of those ports. For example, ImageMagick declares a library dependency on 
pkgconfig, because it uses it at build time to find its dependencies, and it 
also uses it at runtime if you use the Magick-config script. This is fairly 
unusual though so it would not be unreasonable to add this warning.

Re: [macports-ports] branch master updated: wxMaxima: update to 18.02.0 & development subport

[Ryan Schmidt]

On Jul 7, 2018, at 07:28, Perry E. Metzger wrote:

> I strongly suggest that you simply fix the issues in question. Were
> it not for the fact that I've had a lot of unavoidable drains on my
> time recently, I would have hand-fixed all of the issues and
> committed the (correct) changes myself, but I was not in a position
> to do so.

The reason why I write commit reviews, rather than just fixing the issues, is 
that I want to educate committers and contributors on how to write good 
commits. I don't have time to fix everybody's bad commits for them.

Re: [macports-ports] branch master updated: wxMaxima: update to 18.02.0 & development subport

[Ryan Schmidt]

On Jun 28, 2018, at 12:47, tomio-arisaka wrote:

> Perry E. Metzger (pmetzger) pushed a commit to branch master
> in repository macports-ports.
> 
> 
> https://github.com/macports/macports-ports/commit/f564833fda44e715f61fe9c5e34e521a7ddc1882
> 
> The following commit(s) were added to refs/heads/master by this push:
> 
>  new f564833  wxMaxima: update to 18.02.0 & development subport
> 
> f564833 is described below
> 
> 
> commit f564833fda44e715f61fe9c5e34e521a7ddc1882
> 
> Author: tomio-arisaka
> AuthorDate: Thu Jun 28 14:57:45 2018 +0900
> 
> wxMaxima: update to 18.02.0 & development subport
> 
> * Update wxMaxima from version 15.04.0 to 18.02.0.
> * Change the value of homepage to 'http://andrejv.github.io/wxmaxima/'.
> * Use 'cmake' instead of 'autoconf' because current version of wxMaxima
>   does not support 'autoconf' any more.
> * Add patch to avoid an error when launching.
> * Add 'wx32' variant to be able to choose wxWidgets-3.1 instead of 3.0.
> * Add 'wxMaxima-devel' subport to be able to get a development version.
> * Closes: https://trac.macports.org/ticket/53732
> 
> ---
>  math/wxMaxima/Portfile | 153 
> ++---
>  .../files/patch-devel-src_Dirstructure.cpp.diff|  15 ++
>  .../wxMaxima/files/patch-src_Dirstructure.cpp.diff |  37 +
>  3 files changed, 154 insertions(+), 51 deletions(-)
> 

As was discussed in the PR, the diff is hard to read because whitespace changes 
were made in the same commit as functional changes. They should have been done 
as separate commits. That should have been fixed before the PR was merged.


> +version 18.02.0

This line should go away, since the github.setup line later on already provides 
this information.


> +subport wxMaxima-devel {
> +conflicts   wxMaxima
> +long_description ${description}: \
> +Provides the development version, which is typically 
> updated every day.

Is that useful to mention? Are you really planning to update this port every 
day?


> +livecheck.type  none
>  }

Is there a particular reason why we don't want livecheck to work in this 
subport?


> +if {${subport} eq ${name}} {
> +livecheck.regex Version-(\[a-z0-9.\]+)${extract.suffix}
>  }

It should not be necessary to override the entire livecheck.regex. Perhaps you 
meant:

github.livecheck.regex {([a-z0-9.]+)}


> +depends_build   port:cmake

Ports that build with cmake should usually use the cmake 1.1 portgroup. It 
would simplify the portfile, removing the need to specify the dependency or 
what you're doing in the configure or build phases. Is there a reason the 
portgroup was not used here? If there is a valid reason, then at least this 
dependency should be changed so that cmake-devel could also satisfy it:

depends_build path:bin/cmake:cmake


> +depends_run bin:maxima:maxima

This would allow a maxima binary installed outside of MacPorts to satisfy the 
dependency. Is there a reason why we want to allow that? Usually we don't want 
to do that. To fix this to allow only MacPorts-installed copies to satisfy the 
dependency, change it to:

depends:run path:bin/maxima:maxima


> +destroot {
> +xinstall -m 755 -d ${destroot}${applications_dir}
> +file copy ${worksrcpath}/build/wxMaxima.app 
> ${destroot}${applications_dir}
> +}

It is not necessary to create the applications directory, or other common 
directories mentioned in "man porthier". MacPorts does it for you.


> +notes "
> +Be careful: \n\
> +If you want to use wxMaxima with default setting, \n\
> +you should enter the command \n\
> +\"open -a ${applications_dir}/wxMaxima.app\" \n\
> +on Terminal.app in order to launch wxMaxima. \n\
> +Because you must let wxMaxima know the path to software \n\
> +installed with MacPorts. \n\n\
> +On the other hand, \n\
> +when you launch directly wxMaxima on the Finder, \n\
> +the path to maxima (e.g. \"${prefix}/bin/maxima\") is automatically set 
> \n\
> +on the configuration dialog. \n\
> +But you should enter the maxima expression \n\
> +gnuplot_command:\"${prefix}/bin/gnuplot\"\$ \n\
> +in order to use gnuplot. \n\n\
> +Some configuration files are automatically created by wxMaxima. \n\
> +You can enter the command \n\
> +\"find \$HOME/Library -name '*wxMaxima*'\" \n\
> +on Terminal.app in order to find them.
> +"

Please reexamine the formatting (and wording) of these notes. We want MacPorts 
to be able to wrap the notes to the user's terminal width. It can only do this 
if you do not insert hard newlines into the middle of sentences. For 
convenience you can put a single line of text on multiple lines of the Portfile 
by using the backslash line continuation. So for example, you want to write...


If you want to use wxMaxima with default setting,\
you should enter the command


...so that a newline will not actually be printed after the 

Re: [macports-ports] branch master updated: netperf: enable demo mode

[Ryan Schmidt]

On Jul 6, 2018, at 00:00, Eitan Adler wrote:

> Eitan Adler (grimreaper) pushed a commit to branch master
> in repository macports-ports.
> 
> 
> https://github.com/macports/macports-ports/commit/6935f6ab1cf8b99c9ca0cdaa2f8d03a5566b4e73
> 
> The following commit(s) were added to refs/heads/master by this push:
> 
>  new 6935f6a  netperf: enable demo mode
> 
> 6935f6a is described below
> 
> 
> commit 6935f6ab1cf8b99c9ca0cdaa2f8d03a5566b4e73
> 
> Author: Eitan Adler
> AuthorDate: Thu Jul 5 21:55:48 2018 -0700
> 
> 
> netperf: enable demo mode
> 
> 
> 
> Also fix the port to use github portgroup properly. The patch file is a
> partial patch from 40c8a0f of the upstream repository.


> -# When updating this port to the next version, please return to correct 
> usage of
> -# the github portgroup by removing the overrides for master_sites and 
> worksrcdir.
>  github.setupHewlettPackard netperf 2.7.0 netperf-
> +revision1
>  categories  net
>  license Noncommercial BSD BSD-old
> -platforms   darwin freebsd
> -maintainers nomaintainer
> +platforms   darwin
> +maintainers {grimreaper @grimreaper} openmaintainer
>  
>  description a network performance benchmark
>  long_descriptionNetperf is a benchmark that can be used to measure \
> @@ -21,10 +20,14 @@ long_descriptionNetperf is a benchmark that can be 
> used to measure \
>  HP HiPPI LLA may be conditionally compiled-in.
>  
>  homepagehttps://hewlettpackard.github.io/netperf/
> -master_siteshttps://github.com/HewlettPackard/netperf/archive

Because you didn't wait until the next version to make this change, as was 
advised in the comment that you removed above, this is a stealth update. 
Because you didn't handle it as a stealth update (by changing dist_subdir and 
checksums), a checksum mismatch will now occur when our mirror is not used:

$ sudo port fetch --no-mirrors netperf && sudo port checksum netperf
--->  Fetching distfiles for netperf
--->  Attempting to fetch netperf-2.7.0.tar.gz from 
https://github.com/HewlettPackard/netperf/tarball/netperf-2.7.0
--->  Verifying checksums for netperf   
 
Error: Checksum (rmd160) mismatch for netperf-2.7.0.tar.gz
Error: Checksum (sha256) mismatch for netperf-2.7.0.tar.gz
Error: Checksum (size) mismatch for netperf-2.7.0.tar.gz
Error: Failed to checksum netperf: Unable to verify file checksums
Error: See 
/opt/local/var/macports/logs/_Users_rschmidt_macports_macports-ports-svn-trunk_net_netperf/netperf/main.log
 for details.
Error: Follow https://guide.macports.org/#project.tickets to report a bug.
Error: Processing of port netperf failed

The simplest fix would be to revert the removal of master_sites, the removal of 
the comment, and the change of worksrcdir.


> +patchfiles  40c8a0fb873ac07a95f0c0253b2bd66109aa4c51.diff
> +
> +# openmaintainer does not apply to the configure argument. Talk with me 
> before touching them.
> +configure.args  --enable-demo
>  
>  checksums   rmd160  ea5f83cce4bf03884c3c4ed3278146976627af0a \
>  sha256  
> 4569bafa4cca3d548eb96a486755af40bd9ceb6ab7c6abd81cc6aa4875007c4e \
>  size1993943
>  
> -worksrcdir  netperf-netperf-${version}
> +worksrcdir  netperf-netperf-${github.version}

This is still not correct usage of the github portgroup. Correct usage would be 
not specifying worksrcdir.

Re: macOS10.14 testers ?

[Ryan Schmidt]

On Jul 4, 2018, at 10:41, Christopher Jones wrote:

> I am just curious, has anyone else signed up for the 10.14 beta and played 
> with it and MacPorts ?
> 
> I have been doing this myself, in a VM, and whilst we cannot discuss anything 
> here on list, as per the NDA, I would be interested to in private share what 
> I have found, as there are perhaps some interesting things to discuss a bit….
> 
> https://trac.macports.org/wiki/FAQ#prerelease

Me.

Re: [macports-ports] 01/02: xml-security-c: update to 2.0.0

[Ryan Schmidt]

On Jul 4, 2018, at 14:07, Jeremy L wrote:

> Jeremy L (nerdling) pushed a commit to branch master
> in repository macports-ports.
> 
> 
> https://github.com/macports/macports-ports/commit/0ef87ed1231742cf86a026814f6e866fef4268db
> 
> commit 0ef87ed1231742cf86a026814f6e866fef4268db
> 
> Author: Jeremy Lavergne 
> AuthorDate: Wed Jul 4 14:54:28 2018 -0400
> 
> 
> xml-security-c: update to 2.0.0

The library version has increased from 17 to 20. There are three ports that 
declare a dependency on this port. Do any of them link with the library? If so, 
their revisions need to be increased to rebuild them.


> -depends_lib port:xercesc3 path:lib/libssl.dylib:openssl
> +depends_lib port:xercesc3 path:lib/libssl.dylib:openssl 
> port:pkgconfig

Does it really use pkgconfig at runtime?

Re: [macports-ports] branch master updated: grep: add new variant to install as ggrep

[Ryan Schmidt]

On Jun 27, 2018, at 15:25, Rainer Müller wrote:

> Just to add to the previous discussion, /usr/bin/grep used to be
> GNU grep on older versions of macOS. That is probably the reason why it
> does not implement the g* prefix like the other ports for GNU tools yet.
> 
> On 2018-06-27 21:14, George Plymale II wrote:
>> I noticed that most of them have build dependencies which are declared
>> like so:
>> 
>> depends_build   bin:grep:grep
>> 
>> If my understanding of `depends_build' is correct, these ports aren't
>> really relying on the grep port, right? Since the system /usr/bin/grep
>> will be found first, the grep port won't even be installed so isn't this
>> redundant? I feel like I'm missing something here.
> 
> The grep port will only be installed if the grep binary is not available
> in PATH. On macOS, it is available at /usr/bin/grep, so the grep port is
> not needed. If the grep port is installed, ${prefix}/bin/grep will
> always be used as it comes first in PATH. This dependency declaration
> also allows the use of ${prefix}/bin/grep in trace mode as opposed to
> forcing /usr/bin/grep.

A port that declares a dependency "bin:grep:grep" is making the statement "if 
the grep binary does not already exist, install the grep port, which will 
provide the grep binary". That statement becomes false if we implement George's 
/ Blair's suggestion of having the grep port install the binary as "ggrep" 
instead.

Do all of the ports that declare the dependency "bin:grep:grep" already know 
that they should alternately look for a binary called "ggrep"? I don't know, 
and figuring that out and making any necessary adjustments to the programs 
and/or their build systems would be part of the task. Possible adjustments that 
could me made would include modifying e.g. configure scripts to check for ggrep 
in addition to grep, or modifying the PATH seen by configure scripts to add 
/opt/local/libexec/gnubin so that the "grep" binary there is found, or changing 
the dependency to "port:grep" and modifying the port to always look for a 
binary "ggrep" instead of "grep".

Re: Cmake build problem workaround

[Ryan Schmidt]

Right. I am able to reproduce the problem. I made various improvements to the 
portfile for stylistic and other reasons but I haven't made any progress on 
resolving the problem we're seeing. I will try to take another look at it.

You started working on this years ago... did you ever report the problems to 
the developers? Did they have any response? It's their build system that's 
broken; ultimately it's their responsibility to fix it.

\r


> On Jun 26, 2018, at 22:46, Randolph M. Fritz  wrote:
> 
> Ryan, it's been a week, any luck with this?
> 
> -- 
> Randolph M. Fritz || +1 206 659-8617 || rmfri...@gmail.com
> 
> On Tue, Jun 19, 2018 at 5:04 PM, Randolph M. Fritz  wrote:
> Wow, thanks.
> 
> 
> 
> -- 
> Randolph M. Fritz || +1 206 659-8617 || rmfri...@gmail.com
> 
> On Tue, Jun 19, 2018 at 2:46 PM, Ryan Schmidt  wrote:
> 
> On Jun 19, 2018, at 12:15, Randolph M. Fritz wrote:
> 
> > Ryan Schmidt – Portfile attached.
> 
> Thanks. It references the patchfile cmakelists_patches.diff; could you attach 
> that too? I want to try to build the port.
> 
> 
> 
> 
> 

Re: [macports-ports] branch master updated: grep: add new variant to install as ggrep

[Ryan Schmidt]

On Jun 21, 2018, at 03:44, George Plymale II wrote:

 Why are we offering this? Selecting this variant would break any port that 
 depends on this port. We should strive not to provide users with ways of 
 shooting themselves in the foot.
 
>>> 
>>> Besides this breaking change, it would be good to have this port be 
>>> consistent with findutils and coretuils (and maybe the other GNU ports) 
>>> which install with —program-prefix=g into $prefix/bin and have the non-g 
>>> prefix in $prefix/libexec/gnubin so one can have $prefix/libexec/bin in 
>>> $PATH and get the GNU versions if one wants them.
>> 
>> It is true that that is how most of the other GNU ports work. However, that 
>> would also break all of the ports that depend on the grep port. It would at 
>> least be more consistent than having this variant, but all the ports that 
>> depend on grep would need modifications to be compatible with your proposed 
>> change.
> 
> Hi,
> 
> Sorry, I contributed this change to scratch my own itch of needing to
> not override the system grep. Honestly, I didn't think about
> compatibility with other ports so that is a mistake on my part. I see
> four ways of addressing this problem:
> 
> - just modify the other ports which deal with the grep port to be
>  compatible with this change
> - do what Blair suggests and make this port consistent with other GNU
>  ports, as well as fixing compatibility as mentioned by Ryan
> - add a warning to this variant, saying that it could cause issues
> - eliminate this change altogether (I really hope this isn't chosen)
> 
> I think the first or second solution above would be the best. Which
> other ports reference the grep port anyway? Of course, if anyone has
> better ideas, feel welcome to chime in.

Your change makes the names of the programs that the grep port installs 
unpredictable -- they will be different depending on whether or not the user 
has selected the variant. Therefore, no other port or script can be certain of 
the names under which the programs have been installed. We definitely must 
revert the addition of the variant, so that the port can be relied upon to 
always install programs with predictable names.

We then have two choices. Choice 1 is to do nothing else and leave it as it was 
before your change. Choice 2 is to do what Blair suggests and make the port 
install the programs with the "g" prefix, and put unprefixed symlinks in the 
gnubin directory, as other GNU ports do. This would require changes to the two 
dozen other ports that declare dependencies on grep. If you wish to undertake 
that task, that's fine.

The way that I identify the portfiles that depend on grep is:

port file all | sort -u | xargs grep -El '^[^#]+:grep\W'

Re: [macports-ports] branch master updated: grep: add new variant to install as ggrep

[Ryan Schmidt]

On Jun 20, 2018, at 23:15, Blair Zajac wrote:

> On Jun 20, 2018, at 7:21 PM, Ryan Schmidt wrote:
> 
>> On Jun 20, 2018, at 05:45, George Plymale II wrote:
>> 
>>> Marius Schamschula (Schamschula) pushed a commit to branch master
>>> in repository macports-ports.
>>> 
>>> 
>>> https://github.com/macports/macports-ports/commit/35915ffebeb3fc380ca45cdbde23e8ed9a8eb51d
>>> 
>>> The following commit(s) were added to refs/heads/master by this push:
>>> 
>>>new 35915ff  grep: add new variant to install as ggrep
>>> 
>>> 35915ff is described below
>>> 
>>> 
>>> commit 35915ffebeb3fc380ca45cdbde23e8ed9a8eb51d
>>> 
>>> Author: George Plymale II
>>> AuthorDate: Tue Jun 19 23:33:37 2018 -0400
>>> 
>>> 
>>>   grep: add new variant to install as ggrep
>>> 
>>> ---
>>> sysutils/grep/Portfile | 6 +-
>>> 1 file changed, 5 insertions(+), 1 deletion(-)
>> 
>> 
>>> +variant g_prefix description {Install the program as ggrep} {
>>> +configure.args-append --program-prefix=g
>>> +}
>> 
>> Why are we offering this? Selecting this variant would break any port that 
>> depends on this port. We should strive not to provide users with ways of 
>> shooting themselves in the foot.
>> 
> 
> Besides this breaking change, it would be good to have this port be 
> consistent with findutils and coretuils (and maybe the other GNU ports) which 
> install with —program-prefix=g into $prefix/bin and have the non-g prefix in 
> $prefix/libexec/gnubin so one can have $prefix/libexec/bin in $PATH and get 
> the GNU versions if one wants them.

It is true that that is how most of the other GNU ports work. However, that 
would also break all of the ports that depend on the grep port. It would at 
least be more consistent than having this variant, but all the ports that 
depend on grep would need modifications to be compatible with your proposed 
change.

Re: [macports-ports] branch master updated: grep: add new variant to install as ggrep

[Ryan Schmidt]

On Jun 20, 2018, at 05:45, George Plymale II wrote:

> Marius Schamschula (Schamschula) pushed a commit to branch master
> in repository macports-ports.
> 
> 
> https://github.com/macports/macports-ports/commit/35915ffebeb3fc380ca45cdbde23e8ed9a8eb51d
> 
> The following commit(s) were added to refs/heads/master by this push:
> 
>  new 35915ff  grep: add new variant to install as ggrep
> 
> 35915ff is described below
> 
> 
> commit 35915ffebeb3fc380ca45cdbde23e8ed9a8eb51d
> 
> Author: George Plymale II
> AuthorDate: Tue Jun 19 23:33:37 2018 -0400
> 
> 
> grep: add new variant to install as ggrep
> 
> ---
>  sysutils/grep/Portfile | 6 +-
>  1 file changed, 5 insertions(+), 1 deletion(-)


> +variant g_prefix description {Install the program as ggrep} {
> +configure.args-append --program-prefix=g
> +}

Why are we offering this? Selecting this variant would break any port that 
depends on this port. We should strive not to provide users with ways of 
shooting themselves in the foot.

Re: Cmake build problem workaround

[Ryan Schmidt]

On Jun 19, 2018, at 12:15, Randolph M. Fritz wrote:

> Ryan Schmidt – Portfile attached.

Thanks. It references the patchfile cmakelists_patches.diff; could you attach 
that too? I want to try to build the port.

Re: Cmake build problem workaround

[Ryan Schmidt]

On Jun 18, 2018, at 14:20, Randolph M. Fritz wrote:

> This is what I ended up with. I don't like it at all.
> 
> pre-destroot {
> # This fixes what may be a cmake error
> catch {
>   # look for DESTDIR in the fixup_bundle arguments
>   exec grep -q {fixup_bundle.*DESTDIR} 
> ${workpath}/build/InstallRules/dependencies.cmake
> } res opt
> # if it's not present, add it
> if [string equal "$res" "child process exited abnormally"] {
> reinplace "/fixup_bundle(\"/s//&\$ENV{DESTDIR}/" 
> ${workpath}/build/InstallRules/dependencies.cmake
> }
> }

Could you share your complete portfile with us? Maybe we can figure out why the 
error is occurring and provide a better workaround.

Re: [macports-ports] branch master updated: science/hmmer: update to version 3.2.1

[Ryan Schmidt]

On Jun 14, 2018, at 21:05, Mark Moll wrote:
> 
> Mark Moll (mamoll) pushed a commit to branch master
> in repository macports-ports.
> 
> 
> https://github.com/macports/macports-ports/commit/38cd410e2856185b53446dabe2667cd47969fcce
> 
> The following commit(s) were added to refs/heads/master by this push:
> 
>  new 38cd410  science/hmmer: update to version 3.2.1
> 
> 38cd410 is described below
> 
> 
> commit 38cd410e2856185b53446dabe2667cd47969fcce
> 
> Author: Mark Moll
> AuthorDate: Thu Jun 14 21:05:28 2018 -0500
> 
> 
> science/hmmer: update to version 3.2.1
> 
> ---
>  science/hmmer/Portfile | 14 +++---
>  1 file changed, 7 insertions(+), 7 deletions(-)
> 
> 
> diff --git a/science/hmmer/Portfile b/science/hmmer/Portfile
> index 9967ede..2c7c78b 100644
> --- a/science/hmmer/Portfile
> +++ b/science/hmmer/Portfile
> @@ -1,8 +1,8 @@
>  PortSystem 1.0
>  
>  namehmmer
> -version 3.2
> -epoch   3
> +version 3.2.1
> +epoch   4

This is fine, but note that you don't have to increase the epoch unless the new 
version appears to be older than the old version.

For example, if the old version was "20180501" and the new version was "3.2.1", 
MacPorts would see that "20180501" is greater than "3" and so it would not 
consider the port to be outdated, unless the epoch is increased.

But "3.2.1" is clearly greater than "3.2" so keeping the same epoch is 
acceptable.

Re: [macports-base] branch master updated: Set UNIVERSAL_ARCHS to only x86_64 on macOS 10.14 Mojave

[Ryan Schmidt]

On Jun 5, 2018, at 02:29, Jeremy Huddleston Sequoia wrote:

> Jeremy Huddleston Sequoia (jeremyhu) pushed a commit to branch master
> in repository macports-base.
> 
> 
> https://github.com/macports/macports-base/commit/87faa2b7c04210924a051170d46d5577ec5695e8
> 
> The following commit(s) were added to refs/heads/master by this push:
> 
>  new 87faa2b  Set UNIVERSAL_ARCHS to only x86_64 on macOS 10.14 Mojave
> 
> 87faa2b is described below
> 
> 
> commit 87faa2b7c04210924a051170d46d5577ec5695e8
> 
> Author: Jeremy Huddleston Sequoia
> AuthorDate: Tue Jun 5 00:27:41 2018 -0700
> 
> 
> Set UNIVERSAL_ARCHS to only x86_64 on macOS 10.14 Mojave

I assume this will break the wine ports. 64-bit support was recently added to 
the wine ports, but my understanding is that the 64-bit parts of wine don't 
work without the 32-bit parts, which is why the wine ports require the 
universal variant on 64-bit systems.

I had earlier read some information that macOS 10.14 would still support 32-bit 
apps, with some unspecified compromises. I haven't watched the WWDC 2018 
keynote presentation yet, but news reports about it say that 10.14 still 
supports 32-bit.

What shall we do? Can we revert this, or is there some other reason why 
universal builds don't work on 10.14?

Re: [macports-ports] branch master updated: octave 4.4.0: add missing qt5-sqlite-plugin dependency

[Ryan Schmidt]

On Jun 2, 2018, at 16:51, Marius Schamschula wrote:

> Marius Schamschula (Schamschula) pushed a commit to branch master
> in repository macports-ports.
> 
> 
> https://github.com/macports/macports-ports/commit/4c13d30353d2d95d746769aad50070aebdb4b688
> 
> The following commit(s) were added to refs/heads/master by this push:
> 
>  new 4c13d30  octave 4.4.0: add missing qt5-sqlite-plugin dependency
> 
> 4c13d30 is described below
> 
> 
> commit 4c13d30353d2d95d746769aad50070aebdb4b688
> 
> Author: Marius Schamschula
> AuthorDate: Sat Jun 2 16:51:26 2018 -0500
> 
> 
> octave 4.4.0: add missing qt5-sqlite-plugin dependency


> @@ -408,7 +408,7 @@ variant qt4 conflicts qt5 description {build the GUI 
> using Qt4} {
>  variant qt5 conflicts qt4 description {build the GUI using Qt5} {
>  PortGroup qt5 1.0
>  qt5.depends_component qttools
> 
> -depends_lib-append port:qscintilla-qt5
> +depends_lib-append port:qscintilla-qt5 port:qt5-sqlite-plugin

Shouldn't that be:

qt5.depends_component   qttools sqlite-plugin

Re: multiple ports with stdlibc++ mismatches (all on 10.13)...

[Ryan Schmidt]

On May 31, 2018, at 12:21, iEFdev wrote:

> I have some 5-6 ports that show this (gptfdisk, flac, etc.).

gptfdisk: https://github.com/macports/macports-ports/pull/1910

flac: I do not see anything wrong with the port. Every invocation of the 
clang++ already specifies the -stdlib flag. If that's not happening for you, 
please file a ticket with a main.log file attached.

etc.: File tickets or PRs.

Re: multiple ports with stdlibc++ mismatches (all on 10.13)...

[Ryan Schmidt]

On May 31, 2018, at 10:44, Dr M J Carter wrote:

> On Thu, May 31, 2018 at 07:49:23AM -0700, Ken Cunningham wrote:
>> 
>> On 2018-05-30, at 11:04 PM, Joshua Root wrote:
>> 
>>> On 2018-5-31 15:39 , Ken Cunningham wrote:
 gcc5 is using libstdc++ (this installation is configured to use libc++)
 gcc6 is using libstdc++ (this installation is configured to use libc++)
 gcc7 is using libstdc++ (this installation is configured to use libc++)
>>> 
>>> Did cxx_stdlib_overridden.tcl not set these up right for you?
>> 
>> It appears it should have...
>> 
>> I may have some inconsistency in my local MacPorts' database.
> 
> If so, that may not be the primary cause.  Our build system recreates
> MacPorts from scratch from the tarball; as of 2.5.0, openmpi-gcc6
> builds, 3+ times over, for everything which depends on it, then gets
> rejected each time due to the libstdc++/libc++ conflict.

That is expected: Josh was specifically asking about the gcc5, gcc6, gcc7 
ports, because they clear configure.cxx_stdlib. The cxx_stdlib_overridden.tcl 
script contains a list of ports that were known to modify configure.cxx_stdlib 
at the time that MacPorts 2.5.0 was released, which includes gcc5, gcc6, gcc7.

openmpi-gcc6 is not such a port. It does not override the default value of 
configure.cxx_stdlib, yet because it builds with MacPorts FSF GCC, it does not 
use the standard C++ lib. It would be nice if MacPorts base knew that using 
MacPorts FSF GCC implied that configure.cxx_stdlib would change, but in 2.5.0, 
it doesn't know that, so any port building with MacPorts FSF GCC must specify 
configure.cxx_stdlib.

Re: multiple ports with stdlibc++ mismatches (all on 10.13)...

[Ryan Schmidt]

On May 31, 2018, at 00:39, Ken Cunningham wrote:

> pbzip2 is using libstdc++ (this installation is configured to use libc++)
> dylibbundler is using libstdc++ (this installation is configured to use 
> libc++)
> lzma is using libstdc++ (this installation is configured to use libc++)
> SuiteSparse is using libstdc++ (this installation is configured to use libc++)
> starfighter is using libstdc++ (this installation is configured to use libc++)
> darwinbuild is using libstdc++ (this installation is configured to use libc++)
> pdftk is using libstdc++ (this installation is configured to use libc++)
> gcc5 is using libstdc++ (this installation is configured to use libc++)
> gcc6 is using libstdc++ (this installation is configured to use libc++)
> gcc7 is using libstdc++ (this installation is configured to use libc++)


Each port is going to need to be investigated and fixed in its own unique way, 
so an individual ticket should be filed for each port (or each group of ports). 
It may be quicker just to try to fix them and commit them without tickets. 
pdftk already has a ticket.

Re: [MacPorts] #56562: jbig2dec @0.14: checksum mismatch (was: jbig2dec @0.14)

[Ryan Schmidt]

On May 30, 2018, at 16:31, macpo...@parvis.nl wrote:

> On 2018-05-30, at 21:47, MacPorts wrote:
> 
>> #56562: jbig2dec @0.14: checksum mismatch
>> ---+--
>> Reporter:  pdvnl |  Owner:  (none)
>> Type:  defect| Status:  new
>> Priority:  Normal|  Milestone:
>> Component:  ports |Version:  2.5.0
>> Resolution:|   Keywords:  haspatch
>> Port:  jbig2dec  |
>> ---+--
>> Changes (by ryandesign):
>> 
>> * keywords:  has patch => haspatch
>> 
>> 
>> Comment:
>> 
>> GitHub-hosted software should be fetched using the github 1.0 portgroup,
>> not by manually specifying `master_sites`.
>> 
>> -- 
>> Ticket URL: 
>> MacPorts 
>> Ports system for macOS
> 
> It was a very recent portfile, the change was from a master site to github, 
> agreed.
> Do you expect me to add the github portgroup to the portfile? Will do next 
> time.

Portfiles for software hosted on GitHub should use the github portgroup, which 
is documented in the Guide.

Here are all the changes I ended up needing to commit:

https://github.com/macports/macports-ports/commit/e8f91e903435a2d4eb2ba343fded106818f59a27

Unfortunately there were rather more changes than I would have liked, due to 
this particular software misusing GitHub as a file distribution platform.

Re: install-patch-install cycles & install without activate

[Ryan Schmidt]

On May 29, 2018, at 13:31, macpo...@parvis.nl wrote:

> I'm trying to work as much as possible with scripted procedures.
> 
> After an initial install of a new/modified port, I need to apply/change 
> patches.
> 
> My workflow is:
> 
>  port install munin
> 
>  #- cycle start
>  port clean --work munin
>  create patches against the unmodified tarball
>  port clean --work munin
>  port install munin
>  test
>  #- cycle end
> 
> Problem here is that if Portfile  isn't changed, install will skip all 
> phases, including checksum, extract, patch, configure, build, destroot, 
> "install", activate.
> I can port clean --all munin but then I need to fetch again, and that is not 
> needed.

Then don't use "sudo port clean --all". Just use "sudo port clean".

Or, sometimes it's helpful to edit the state file. (The file named 
.macports.${subport}.state inside the directory identified by the command `port 
work`.) You can delete the lines for the phases that you want MacPorts to run 
again.


>  Q1) What is the port command to execute all needed phases, starting with 
> patch?
> 
> Somewhere it says something like install creates a tarball from destroot, 
> activate unpackes that tarball.
> Above I wrote "install" because I'm looking for the port verb that does 
> exactly this.
> I would like to be able to do the complete installation process without 
> activate.
> 
> My experience is this:
> port install does
> - if activated: nothing
> - else: do all steps from $(port work munin)/.macportsmunin.state
> Is this correct? If this is true, port deactivate munin && port install munin 
> would be enough.
> 
>  Q2) What is the port command to execute all needed phases, except activate?

I don't think any such command exists. Why do you want this?



> Possible solutions:
> - using this unknown port "install" verb
> - rm $(port location munin)* 
>  is this safe?
> - somehow manipulating the registry
>  doesn't sound safe

Re: MacPorts 2.5.0-beta1 now available for testing

[Ryan Schmidt]

On May 28, 2018, at 21:10, Zero King wrote:

> Hi,
> 
> On Thu, May 10, 2018 at 03:58:11PM +1000, Joshua Root wrote:
>> Source code and pkgs for MacPorts 2.5.0-beta1 are now
>> available [1]. Testing of either of these install methods is helpful.
> 
> Now that 2.5.0 is released, we should protect the release-2.5 branch in
> macports-base to disable force pushing and prevent it from being deleted
> accidentally.

Done.

We should have done that the moment the branch was created.

We should update our documentation (macports-base/portmgr/ReleaseProcess.md) to 
include that step.

Re: MacPorts 2.5.0-beta1 now available for testing

[Ryan Schmidt]

On May 26, 2018, at 14:38, Ken Cunningham wrote:

> On May 26, 2018, at 12:27 PM, Ryan Schmidt wrote:
> 
>> The error occurs when there is a mismatch between which C++ standard library 
>> a port says it uses (by setting configure.cxx_stdlib, or by leaving it set 
>> to its default value) and which C++ standard library it actually links with.
> 
> Right. 
> 
> Indeed I did not realize that each and every portfile would be examined for 
> cxx_stdlib overrides for each different system configuration, and that would 
> be integrated into the check mechanism for the build.
> 
> So if he had wanted to (and assuming the linkages worked out), Zero could 
> have also just as correctly put 
> 
> configure.cxx_stdlib libstdc++
> 
> into his unar portfile, and left things alone.

Yes, if unar does not link with any C++ libraries, and does not provide any C++ 
libraries, that would also be fine.

Re: MacPorts 2.5.0-beta1 now available for testing

[Ryan Schmidt]

On May 26, 2018, at 11:48, Ken Cunningham wrote:

> Well I think you did the cmake finaggeling last time Not sure you could 
> find a better way, but I wait to see...

I don't recall what you're referring to.

Re: MacPorts 2.5.0-beta1 now available for testing

[Ryan Schmidt]

On May 26, 2018, at 11:15, Ken Cunningham wrote:

> On May 25, 2018, at 12:05 PM, Ryan Schmidt wrote:
> 
>> It's "broken" in that it links with libstdc++, even though MacPorts believes 
>> it will link with libc++ on your system. The rev-upgrade code in previous 
>> versions of MacPorts did not check for this kind of "broken".
>> 
>> Fix it by fixing the build system to use the right C++ standard library (the 
>> one in the ${configure.cxx_stdlib} variable).
> 
> So this particular port comes up with this error probably because the 
> deployment target is set to 10.6 in the xcode project. 
> 
> But there are _lots_ of ports that don’t build with the c++ stdlib specified 
> in cxx_stdlib.
> 
> These are forced one way or the other in a way that works to fix a problem — 
> eg. cmake and many others.

Then all of these ports need to be fixed. Either make the port use the C++ 
standard library that MacPorts sets in configure.cxx_stdlib, or else set 
configure.cxx_stdlib to the C++ standard library that the port will use (this 
is acceptable if the port uses no libraries and provides no libraries; mongodb 
is an example).


> Also, on systems with libcxxonoldersystems, xcodebuild will not accept 
> certain settings on certain systems, even if we know they could work with our 
> newer compilers.

Unfortunately, we have no way to tell Xcode to use one of our compilers. I 
believe we need to create some kind of Xcode-specific file to tell it about 
each of our compilers, then update the xcode portgroup to use that. Nobody's 
done that so far.


> We might see quite a few errors with this, I suspect…

Then we will have to fix quite a few things.

Re: [macports-ports] 01/02: py-alabaster: obsolete py26 and py33 subports

[Ryan Schmidt]

On May 25, 2018, at 21:28, Renee Otten wrote:

> On May 25, 2018, at 3:48 PM, Ryan Schmidt wrote:
> 
>> Replacement doesn't work (doesn't show up in "port outdated") unless the 
>> version or revision of the replacement is higher. So you want "0.7.6_1" 
>> here, to be higher than the 0.7.6_0 (version 0.7.6 revision 0) in the 
>> py-alabaster port.
>> 
>> The same goes for other ports you've obsoleted recently: py-snowballstemmer, 
>> py-pkgconfig.
>> 
>> Please keep the list of ports in the py-graveyard port sorted in 
>> alphabetical order.
> 
> I looked at some examples and thought I understood how to do it, but 
> apparently not.

A "port" can move between Portfiles as needed. All that matters is that, from 
the user's point of view (the user doesn't care which Portfile the port is 
defined in), its version or revision increases.

> Just to make sure I get it now, let’s consider the imaginary “py-port” that 
> is at version 1.0 (revision line not present) and the two following 
> situations:
> 
> 1. obsolete subport py26 without a newer version
> I remove the py26 subport from the py-port Portfile and add “py-port1.0_1 
>26” to py-graveyard.

Assuming the py-port was at revision 0 before, that would be correct. If the 
py-port was at a different revision, then when you move the replaced subport to 
py-graveyard, make sure its revision (the number after the "_") is one higher 
than its revision was when it was in the py-port.

> Do I need to increase the revision in the py-port Portfile as well or not?

No. At that point, the replaced subport lives only in py-graveyard, and no 
longer in py-port, so only what you do in py-graveyard has any influence over 
it.

> 2. obsolete subport py26 and at the same time update the version to 1.1
> I remove the py26 subport from the py-port Portfile, update it to the latest 
> version, and add “py-port1.126” to py-graveyard.

That's probably what I'd do. It would also be fine to put it in py-graveyard as 
1.0_1, so long as that's greater than what that subport used before.

Re: [macports-ports] 01/02: py-alabaster: obsolete py26 and py33 subports

[Ryan Schmidt]

On May 24, 2018, at 09:06, Renee Otten wrote:

> Perry E. Metzger (pmetzger) pushed a commit to branch master
> in repository macports-ports.
> 
> 
> https://github.com/macports/macports-ports/commit/bf5b0c8d47ccb5ebd6ea008744708aef2ea6020c
> 
> commit bf5b0c8d47ccb5ebd6ea008744708aef2ea6020c
> 
> Author: reneeotten
> AuthorDate: Wed May 23 20:55:54 2018 -0400
> 
> 
> py-alabaster: obsolete py26 and py33 subports
> 
> ---
>  python/py-alabaster/Portfile | 2 +-
>  python/py-graveyard/Portfile | 1 +
>  2 files changed, 2 insertions(+), 1 deletion(-)
> 
> 
> diff --git a/python/py-alabaster/Portfile b/python/py-alabaster/Portfile
> index d422092..45c32b4 100644
> --- a/python/py-alabaster/Portfile
> +++ b/python/py-alabaster/Portfile
> @@ -17,7 +17,7 @@ long_description${description}
>  checksums   rmd160  33d9ddb282a79f1d14cbf48f1eda52f51422e303 \
>  sha256  
> 765b9609fedf1abbb9541bfc47272f9a07d1c67c4ff39a2320729b1bc5e89cb2
>  
> -python.versions 26 27 33 34 35 36
> +python.versions 27 34 35 36
>  
>  if {$subport ne $name} {
>  depends_build   port:py${python.version}-setuptools
> diff --git a/python/py-graveyard/Portfile b/python/py-graveyard/Portfile
> index 557513e..4a7e1d8 100644
> --- a/python/py-graveyard/Portfile
> +++ b/python/py-graveyard/Portfile
> @@ -213,6 +213,7 @@ py-webkitgtk1.1.8_8 26
>  py-w3lib1.9.0_1 33
>  py-xhtml2pdf0.0.6_2 26
>  py-pkgconfig1.3.1   26 33
> +py-alabaster0.7.6   26 33
>  
>  
>  if {${subport} ne ${name}} {

Replacement doesn't work (doesn't show up in "port outdated") unless the 
version or revision of the replacement is higher. So you want "0.7.6_1" here, 
to be higher than the 0.7.6_0 (version 0.7.6 revision 0) in the py-alabaster 
port.

The same goes for other ports you've obsoleted recently: py-snowballstemmer, 
py-pkgconfig.

Please keep the list of ports in the py-graveyard port sorted in alphabetical 
order.

Re: MacPorts 2.5.0-beta1 now available for testing

[Ryan Schmidt]

On May 25, 2018, at 12:57, Zero King wrote:

> On Thu, May 17, 2018 at 11:36:39PM +1000, Joshua Root wrote:
>> It's been a week with no new tickets filed against base. I'll give it
>> one more week and then, if nothing comes up, tag a release candidate.
>> 
>> - Josh
> 
> I tried the rc1, and unar is now "broken". How can I fix it?
> 
> unar is using libstdc++ (this installation is configured to use libc++)
> Error: Port unar is still broken after rebuilding it more than 3 times.

It's "broken" in that it links with libstdc++, even though MacPorts believes it 
will link with libc++ on your system. The rev-upgrade code in previous versions 
of MacPorts did not check for this kind of "broken".

Fix it by fixing the build system to use the right C++ standard library (the 
one in the ${configure.cxx_stdlib} variable).

Re: [macports-ports] branch master updated: py-protobuf3: fix build on older systems

[Ryan Schmidt]

On May 24, 2018, at 23:15, Ken wrote:

> Ken (kencu) pushed a commit to branch master
> in repository macports-ports.
> 
> 
> https://github.com/macports/macports-ports/commit/5cb3bb12990f7ea682e4b964eb86269923521397
> 
> The following commit(s) were added to refs/heads/master by this push:
> 
>  new 5cb3bb1  py-protobuf3: fix build on older systems
> 
> 5cb3bb1 is described below
> 
> 
> commit 5cb3bb12990f7ea682e4b964eb86269923521397
> 
> Author: Ken Cunningham
> AuthorDate: Thu May 24 20:17:44 2018 -0700
> 
> py-protobuf3: fix build on older systems
> 
> add cxx11 1.1 PG
> add -stdlib flag to clang builds
> add needed CXX flag to systems without thread_local
> closes: https://trac.macports.org/ticket/56482
> 
> ---
>  python/py-protobuf3/Portfile| 21 
> +
>  .../files/patch-py-protobuf3-settings.diff  | 11 +++
>  2 files changed, 32 insertions(+)
> 
> diff --git a/python/py-protobuf3/Portfile b/python/py-protobuf3/Portfile
> index 46a95dd..fa24a95 100644
> --- a/python/py-protobuf3/Portfile
> +++ b/python/py-protobuf3/Portfile


> +# tricks to force the right -stdlib setting
> +# and to put a needed CXX flag on the 10.6 build

If this is supposed to help 10.6...


> diff --git a/python/py-protobuf3/files/patch-py-protobuf3-settings.diff 
> b/python/py-protobuf3/files/patch-py-protobuf3-settings.diff
> new file mode 100644
> index 000..6293b45
> --- /dev/null
> +++ b/python/py-protobuf3/files/patch-py-protobuf3-settings.diff
> @@ -0,0 +1,11 @@
> +--- setup.py.old 2018-05-24 19:42:16.0 -0700
>  setup.py 2018-05-24 19:43:21.0 -0700
> +@@ -197,6 +197,8 @@
> +   v = float('.'.join(v.split('.')[:2]))
> +   if v >= 10.12:
> + extra_compile_args.append('-std=c++11')
> ++extra_compile_args.append('@@MACPORTS_STDLIB@@')
> ++extra_compile_args.append('@@MACPORTS_EXTRAARG@@')

...why is it inside an if statement that's for 10.12 and later?

I guess it works because the if statement is erroneously treating the version 
number as a floating point number, in which case 10.6 is considered to be 
greater than 10.12.

So the question is: does this code always require C++11? If so, remove the if 
statement.

If it does not always require C++11, fix the if statement so that it correctly 
uses C++11 only on 10.12 and later.

Re: [macports-ports] branch master updated: Revert "wireshark2: change to reindex after 879e68c" Results in "incorrect" directory name while building.

[Ryan Schmidt]

On May 24, 2018, at 16:30, Eric Hall wrote:

> ghosthound pushed a commit to branch master
> in repository macports-ports.
> 
> 
> https://github.com/macports/macports-ports/commit/fd863dfac229f861d7c2245f7e25a0fabc07b814
> 
> The following commit(s) were added to refs/heads/master by this push:
> 
>  new fd863df  Revert "wireshark2: change to reindex after 879e68c" 
> Results in "incorrect" directory name while building.
> 
> fd863df is described below
> 
> 
> commit fd863dfac229f861d7c2245f7e25a0fabc07b814
> 
> Author: Eric Hall
> AuthorDate: Thu May 24 14:30:12 2018 -0700
> 
> 
> Revert "wireshark2: change to reindex after 879e68c"
> Results in "incorrect" directory name while building.
> 
> This reverts commit e4799532fc97d909eb988dcd0068d32a201f3da9.
> 
> ---
>  net/wireshark2/Portfile | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> 
> diff --git a/net/wireshark2/Portfile b/net/wireshark2/Portfile
> index b869afd..06c81a7 100644
> --- a/net/wireshark2/Portfile
> +++ b/net/wireshark2/Portfile
> @@ -23,7 +23,9 @@ master_siteshttps://www.wireshark.org/download/src/ 
> \
>  
>  use_xz  yes
>  
> -distnamewireshark-${version}
> +distfiles   wireshark-${version}${extract.suffix}
> +
> +worksrcdir  wireshark-${version}


The change looked fine to me. Can you explain in what way the directory name 
was incorrect while building?

Re: [macports-ports] branch master updated: libsigcxx3: append macports-gcc-7 to fallback list

[Ryan Schmidt]

On May 22, 2018, at 17:56, David B. Evans wrote:

> David B. Evans (dbevans) pushed a commit to branch master
> in repository macports-ports.
> 
> 
> https://github.com/macports/macports-ports/commit/72943fb126dd2cdb71d5651a42cb9d65398963ef
> 
> The following commit(s) were added to refs/heads/master by this push:
> 
>  new 72943fb  libsigcxx3: append macports-gcc-7 to fallback list
> 
> 72943fb is described below
> 
> 
> commit 72943fb126dd2cdb71d5651a42cb9d65398963ef
> 
> Author: David B. Evans
> AuthorDate: Tue May 22 15:56:11 2018 -0700
> 
> 
> libsigcxx3: append macports-gcc-7 to fallback list
> 
> 
> 
> Attempt to fix build on 10.5 ppc.
> 
> ---
>  devel/libsigcxx3/Portfile | 1 +
>  1 file changed, 1 insertion(+)
> 
> 
> diff --git a/devel/libsigcxx3/Portfile b/devel/libsigcxx3/Portfile
> index bac577d..a9380e6 100644
> --- a/devel/libsigcxx3/Portfile
> +++ b/devel/libsigcxx3/Portfile
> @@ -46,6 +46,7 @@ compiler.blacklist-append {clang < 900.0.39} 
> macports-clang-3.*
>  # powerpc platforms want to use macports-gcc-6
>  # C++17 support requires macports-gcc-7
>  compiler.blacklist-append macports-gcc-6
> +compiler.fallback-append macports-gcc-7

As of MacPorts 2.4.3, macports-gcc-6 and macports-gcc-7 are already in the 
fallback list, so this line is unnecessary and should be removed.

The problem is that the cxx11 1.1 portgroup uses "compiler.whitelist 
macports-gcc-6", which means that it cannot use any other compiler. This was 
done before MacPorts 2.4.3 -- before MacPorts base knew about using 
macports-gcc. The portgroup needs to be changed to use compiler.blacklist 
instead of compiler.whitelist.

Re: [macports-ports] branch master updated: gdal: more cleaning up

[Ryan Schmidt]

On May 22, 2018, at 06:41, Vincent wrote:

> Vincent (Veence) pushed a commit to branch master
> in repository macports-ports.
> 
> 
> https://github.com/macports/macports-ports/commit/73f6c980bb02dcd3cda694f6732b45136b4c6a4f
> 
> The following commit(s) were added to refs/heads/master by this push:
> 
>  new 73f6c98  gdal: more cleaning up
> 
> 73f6c98 is described below
> 
> 
> commit 73f6c980bb02dcd3cda694f6732b45136b4c6a4f
> 
> Author: Veence
> AuthorDate: Tue May 22 13:37:49 2018 +0200
> 
> 
> gdal: more cleaning up
> 
> 
> 
> * Fix a regression with spatialite
> 
> * Deletes /usr/local/include from CPPFLAGS
> 
> * Make some optional drivers mandatory
> 
> * Try to fix < 10.9 builds failing at link time
> 
> ---
>  gis/gdal/Portfile   | 51 
> ++---
>  gis/gdal/files/template-ed-GDALmake_opt |  1 +
>  2 files changed, 16 insertions(+), 36 deletions(-)
> 
> 
> diff --git a/gis/gdal/Portfile b/gis/gdal/Portfile
> index a25bc43..3e12866 100644
> --- a/gis/gdal/Portfile
> +++ b/gis/gdal/Portfile


> +# see https://trac.macports.org/ticket/56517
> +if {${configure.cxx_stdlib} eq "macports-libstdc++"} {
> +configure.ldflags-append -stdlib=macports-libstdc++
> +}

This should be:

if {[string match *clang* ${configure.cxx}]} {
configure.ldflags-append -stdlib=${configure.cxx_stdlib}
}

Only clang understands the -stdlib flag, but you always want to use it, 
regardless of what the C++ stdlib is.

Re: [macports-ports] branch master updated: qgis3: bump to 3.0.3

[Ryan Schmidt]

On May 22, 2018, at 04:40, Vincent wrote:

> Vincent (Veence) pushed a commit to branch master
> in repository macports-ports.
> 
> 
> https://github.com/macports/macports-ports/commit/9ec4b7c7ec6336ddc0829eeaeb9d03db0de0f122
> 
> The following commit(s) were added to refs/heads/master by this push:
> 
>  new 9ec4b7c  qgis3: bump to 3.0.3
> 
> 9ec4b7c is described below
> 
> 
> commit 9ec4b7c7ec6336ddc0829eeaeb9d03db0de0f122
> 
> Author: Veence
> AuthorDate: Tue May 22 11:40:02 2018 +0200
> 
> 
> qgis3: bump to 3.0.3
> 
> ---
>  gis/qgis3/Portfile | 22 ++
>  1 file changed, 18 insertions(+), 4 deletions(-)
> 
> diff --git a/gis/qgis3/Portfile b/gis/qgis3/Portfile
> index 7c7fa49..5879c5c 100644
> --- a/gis/qgis3/Portfile
> +++ b/gis/qgis3/Portfile

> @@ -54,6 +54,20 @@ depends_lib-append  port:libiconv \
>  port:qwt-qt5 \
>  port:qjson-qt5
>  
> +variant qt59 description "Build with qt59" {
> +depends_lib-delete  port:qt5-qtwebkit \
> +port:qt5-qtscript \
> +port:qt5-sqlite-plugin \
> +port:qt5-qtscxml \
> +port:qt5-qtxmlpatterns
> +
> +depends_lib-append  port:qt59-qtwebkit \
> +port:qt59-qtscript \
> +port:qt59-sqlite-plugin \
> +port:qt59-qtscxml \
> +port:qt59-qtxmlpatterns
> +}

I don't think this variant can work. I note the dependencies on qwt-qt5 and 
qjson-qt5 and other ports above, which each depend on qt5-* ports, and the 
qt5-* and qt59-* ports conflict.

Re: macports_version

[Ryan Schmidt]

On May 22, 2018, at 06:22, Clemens Lang wrote:

> On 22 May, 2018, at 13:12, Ryan Schmidt wrote:
> 
>> I'm confused by the inconsistency between variables like macosx_version and
>> xcodeversion, and the macports_version proc.
> 
> xcodeversion and macosx_version are handled very different in the code.
> xcodeversion, xcodebuildcmd and developer_dir are deferred options, i.e. they
> are only copied into the port interpreter when they are read. macosx_version
> is copied immediately. You can compare them from a user's PoV, but they are
> very different from the system view.

I do compare it from the user's point of view, and I find the difference in how 
they are handled to be completely illogical. While I'm arguing about it, it 
should have been xcode_version, not xcodeversion.


> One big downside of using variables (apart from the non-obvious property of
> being constant) is documentation. There is no good place in the code to
> document these variables – consequently we do not have any documentation for
> macosx_version, but macports::version is documented [1]. I believe all public
> API available in macports1.0 should be documented.

I guess we should document variables then.

Re: macports_version

[Ryan Schmidt]

On May 22, 2018, at 06:11, Clemens Lang wrote:

>>> The cleanest way of defining a global const variable that I’ve come across 
>>> is
>>> with trace, tying the variable to a write command with an explicit error
>>> message.
>>> 
>>> But the Tcl wiki page that I linked to previously notes that "command names 
>>> are
>>> the natural choice for constants:
>>> • they live in a separate namespace to variables;
>>> • they are rarely redefined, and few commands do so;
>>> • global commands are available everywhere without importing;
>>> • they offer the possibility of byte-code optimization, i.e. inlining 
>>> (no idea
>>> if this is or could be done).”
>> 
>> Yes, I know that variables can be made read-only through a trace. MacPorts 
>> base
>> has a feature built around traces called option_proc. So my question is why 
>> it
>> wasn't done that way.
>> 
>> Clemens, do you remember?
> 
> Simple, declaring a variable gives you the option of changing it. Making it a 
> proc
> doesn't. It's about runtime vs. compile time failure if you're trying to do 
> something
> unsupported.
> 
> IMHO, using a proc for read-only variables is much cleaner than using a write 
> trace,
> which feels like a hack to me.
> 
> Why would you need it to be a variable? Could you not just call the proc 
> instead?

I'm confused by the inconsistency between variables like macosx_version and 
xcodeversion, and the macports_version proc.

Re: macports_version

[Ryan Schmidt]

On May 22, 2018, at 00:45, Andrew Moore wrote:

> On May 21, 2018, at 5:32 AM, Ryan Schmidt wrote:
> 
>> Yes I'm talking about $xcodeversion, and I'm wondering why we don't have a 
>> corresponding $macports_version. Why do we have to call a procedure to get 
>> the MacPorts version, when we don't have to call a procedure to get the 
>> Xcode version?
> 
> I could hazard a guess at how that came to be, but I’ll  assume that you’re 
> wondering why it can’t be otherwise.  The answer, of course, is that it could.
> 
> The cleanest way of defining a global const variable that I’ve come across is 
> with trace, tying the variable to a write command with an explicit error 
> message.
> 
> But the Tcl wiki page that I linked to previously notes that "command names 
> are the natural choice for constants:
>   • they live in a separate namespace to variables;
>   • they are rarely redefined, and few commands do so;
>   • global commands are available everywhere without importing;
>   • they offer the possibility of byte-code optimization, i.e. inlining 
> (no idea if this is or could be done).”

Yes, I know that variables can be made read-only through a trace. MacPorts base 
has a feature built around traces called option_proc. So my question is why it 
wasn't done that way.

Clemens, do you remember?

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

Re: [macports-ports] branch master updated: charls: initial commit

[Ryan Schmidt]

On May 21, 2018, at 04:04, Vincent Habchi wrote:

>>> +worksrcdir  team-charls-charls-6fa4f2b
>> 
>> You should remove this line. The github portgroup handles this for you.
> 
> Nope. If I do, I get an error:
> 
> Executing:  cd 
> "/opt/local/var/macports/build/_macports-ports_graphics_charls/charls/work" 
> && /usr/bin/gzip -dc 
> '/opt/local/var/macports/distfiles/charls/charLS-2.0.0.tar.gz' | /usr/bin/tar 
> -xf - 
> Error: Failed to extract charls: can't read "workdir": no such variable

Ah, it's because you specified the GitHub project name as "charLS" but the 
project name is actually "charls". Fix this in the github.setup line, and then 
you can remove the unnecessary name and worksrcdir lines.


Index: Portfile
===
--- Portfile(revision 146638)
+++ Portfile(working copy)
@@ -6,8 +6,7 @@
 PortGroup   github  1.0
 PortGroup   compiler_blacklist_versions 1.0
 
-github.setupteam-charls charLS 2.0.0 
-namecharls
+github.setupteam-charls charls 2.0.0
 categories  graphics
 maintainers {vince @Veence}
 description CharLS is an implementation of JPEG-LS
@@ -20,7 +19,5 @@
 sha256  
a7c6f163889b469dd5e29b9c79ba5b6d076d90df3c21653b90eaf4d5a6ed11f7 \
 size4963354
 
-worksrcdir  team-charls-charls-6fa4f2b
-
 # Must have XCode > 6 for C++14 support
 compiler.blacklist-append   {clang < 602}


This error message is confusing. I'm not sure exactly where it's coming from or 
how we can improve it.

Re: macports_version

[Ryan Schmidt]

On May 21, 2018, at 04:28, Andrew Moore wrote:

> On May 20, 2018, at 9:45 PM, Ryan Schmidt wrote:
> 
>> On May 20, 2018, at 17:04, Andrew Moore wrote:
>> 
>>> On May 20, 2018, at 8:23 AM, Ryan Schmidt wrote:
>>> 
>>>> Why is macports_version a proc and not an option?
>>> 
>>> To make it read-only?  It seems procs and trace are Tcl’s way of defining 
>>> constants.
>> 
>> Variables can be easily made read-only. We already have an xcode_version 
>> variable.
> 
> Are you referring to `macports::xcodeversion'? If so, this seems to be a 
> trace'd variable tied
> to a read command (macports.tcl:1185).

Yes I'm talking about $xcodeversion, and I'm wondering why we don't have a 
corresponding $macports_version. Why do we have to call a procedure to get the 
MacPorts version, when we don't have to call a procedure to get the Xcode 
version?

Re: macports_version

[Ryan Schmidt]

On May 20, 2018, at 17:04, Andrew Moore wrote:

> On May 20, 2018, at 8:23 AM, Ryan Schmidt wrote:
> 
>> Why is macports_version a proc and not an option?
> 
> To make it read-only?  It seems procs and trace are Tcl’s way of defining 
> constants.

Variables can be easily made read-only. We already have an xcode_version 
variable.

macports_version

[Ryan Schmidt]

Why is macports_version a proc and not an option?

Re: create several startupitems for different variants of the same port?

[Ryan Schmidt]

On May 14, 2018, at 14:31, macpo...@parvis.nl wrote:

> Is it possible to create several startupitems for a single port?

As of MacPorts 2.5.0, yes. 2.5.0 has not yet been released, but a beta just was.

Re: [macports-mgr] Question about MacPorts project membership application

[Ryan Schmidt]

On May 14, 2018, at 00:46, Joshua Root wrote:

> On 2018-5-14 15:31 , Ryan Schmidt wrote:
>> 
>> On May 13, 2018, at 23:55, Joshua Root wrote:
>> 
>>> On 2018-5-14 14:30 , Ryan Schmidt wrote:
>>>> 
>>>> On May 13, 2018, at 22:39, Joshua Root wrote:
>>>> 
>>>>> Perhaps by recommending the use
>>>>> of return receipts
>>>> 
>>>> Email has no such feature.
>>> 
>>> And yet, you know what I meant.
>> 
>> Well no, I don't. "Return receipt" to me means that the sender receives 
>> automatic notification that their message was received by the recipient. 
>> Standard email systems do not have this capability, so what are you 
>> suggesting?
> 
> Sending a Disposition-Notification-To: header. Which is labelled "Return
> Receipt" in the UI for many MUAs.

Ah. I've never heard of that before.

Re: [macports-mgr] Question about MacPorts project membership application

[Ryan Schmidt]

On May 13, 2018, at 23:55, Joshua Root wrote:

> On 2018-5-14 14:30 , Ryan Schmidt wrote:
>> 
>> On May 13, 2018, at 22:39, Joshua Root wrote:
>> 
>>> Perhaps by recommending the use
>>> of return receipts
>> 
>> Email has no such feature.
> 
> And yet, you know what I meant.

Well no, I don't. "Return receipt" to me means that the sender receives 
automatic notification that their message was received by the recipient. 
Standard email systems do not have this capability, so what are you suggesting?

Re: [macports-mgr] Question about MacPorts project membership application

[Ryan Schmidt]

On May 13, 2018, at 22:39, Joshua Root wrote:

> Perhaps by recommending the use
> of return receipts

Email has no such feature.

Re: port versus path dependency declaration

[Ryan Schmidt]

On May 11, 2018, at 22:17, Ryan Schmidt wrote:

> As for why a dependency on pep8 is being written in path:-style, I don't 
> know. I don't see a py-pep8-devel port. I don't know if there is another port 
> that provides the same files as py-pep8.

I should have checked the history before responding to this.

The other port that provided the same files as py-pep8 was py-pep8-157.

py-autopep8 was switched from pep8 to pep8-157 here:

https://github.com/macports/macports-ports/commit/d273106a7c585334d4a788ded7a0b5d0ee0e164c

And it and other ports were switched back to pep8 here:

https://github.com/macports/macports-ports/commit/b375e3de7d7864e6612f3528e3cb1f11bcfdc9be

pep8-157 became obsolete here:

https://github.com/macports/macports-ports/commit/d4216c136e4ec3b14969a0d59fabb48d1cfab30d

And was removed here:

https://github.com/macports/macports-ports/commit/a512f8ec7f9ad5d5add04158c3b4168349238b5f

So I guess this means that there is no longer a reason why a port should depend 
on pep8 via a path:-style dependency; a port:-style dependency would be fine.

Re: port versus path dependency declaration

[Ryan Schmidt]

On May 11, 2018, at 21:57, Renee Otten wrote:

> I am trying to understand why in some Python ports the run dependencies are 
> declared using path instead of port statements - is there an 
> advantage/preference for one over the other?
> 
> For example, in the py-spyder-devel Portfile (but also the py-autopep8, which 
> I recently updated) it uses: "depends_lib-append 
> path:${python.pkgd}/pep8:py${python.version}-pep8”, which I changed to 
> "depends_lib-append 
> path:${python.pkgd}/pycodestyle:py${python.version}-codestyle” in the 
> py-autopep8 Portfile. 
> 
> If I understand it correctly form the guide the path statement will look if a 
> specific file is present, if not it will install the port. So, in this case 
> for  pep8/pycodestyle in 
> ${frameworks_dir}/Python.framework/Versions/${python.branch}//lib/python${python.branch}
>  ; that file is present but with the extension .py - is that implicitly 
> assumed or should one provide the extension in the path specification. Also, 
> is there any advantage here of using path instead of just doing: 
> "depends_lib-append port:py${python.version}-pep8” or "depends_lib-append 
> port:py${python.version}-pycodestyle”?

path:-style dependencies are used when more than one port could satisfy the 
dependency. For example, py-spyder-devel is a development version of spyder, 
while py-spyder is the stable version. If another port needs to declare a 
dependency on spyder, it should use a path:-style dependency, so that either 
the stable version or the development version can be used.

Our documentation about this is somewhat lacking. See 
https://trac.macports.org/ticket/14540 for some stuff that should be added to 
the guide about this.

As for why a dependency on pep8 is being written in path:-style, I don't know. 
I don't see a py-pep8-devel port. I don't know if there is another port that 
provides the same files as py-pep8.

If you use a path:-style dependency, you must specify the complete and accurate 
path of the file, including filename extensions. If the path you specify is 
relative (does not begin with a slash), ${prefix} is prepended for you.

Re: [macports-ports] 01/02: py-diff-match-patch: new port, version 20121119

[Ryan Schmidt]

On May 11, 2018, at 18:34, Zero King wrote:

> On Fri, May 11, 2018 at 12:07:38PM -0500, Ryan Schmidt wrote:
>> 
>> On May 10, 2018, at 20:37, Zero King wrote:
>> 
>>> Zero King (l2dy) pushed a commit to branch master
>>> in repository macports-ports.
>>> 
>>> 
>>> https://github.com/macports/macports-ports/commit/5836a5624ac40d04cb12a73c4ef219c377100a16
>>> 
>>> commit 5836a5624ac40d04cb12a73c4ef219c377100a16
>>> 
>>> Author: Zero King
>>> AuthorDate: Fri May 11 01:35:20 2018 +
>>> 
>>> 
>>>py-diff-match-patch: new port, version 20121119
>>> 
>>> ---
>>> python/py-diff-match-patch/Portfile | 33 +
>>> 1 file changed, 33 insertions(+)
>>> 
>>> 
>>> diff --git a/python/py-diff-match-patch/Portfile 
>>> b/python/py-diff-match-patch/Portfile
>>> new file mode 100644
>>> index 000..a7cc717
>>> --- /dev/null
>>> +++ b/python/py-diff-match-patch/Portfile
>> 
>> 
>>> +master_sites
>>> https://files.pythonhosted.org/packages/22/82/46eaeab04805b4fac17630b59f30c4f2c8860988bcefd730ff4f1992908b
>> 
>> We don't want to use this style of URL, which needs to be updated every time 
>> the port's version is updated. Can the "pypi" fetch group be used instead?
> 
> I used pypi2port in macports-contrib,

Fixed: 
https://github.com/macports/macports-contrib/commit/aac8f1b1e2012cd5472f41e119a7e61435544e6d

> and this is an inactive package
> that is unlikely to get any update soon.

But we still want all portfiles to exemplify best practices. Novice developers 
often learn how to write portfiles by cribbing from other portfiles.

Re: [macports-ports] 06/06: py-rpy2: update to version 2.9.3

[Ryan Schmidt]

On May 10, 2018, at 07:49, Andrew Stromnov wrote:

> Andrew Stromnov (stromnov) pushed a commit to branch master
> in repository macports-ports.
> 
> 
> https://github.com/macports/macports-ports/commit/ee6a6268d651d4e42247b4f466c51599647a3228
> 
> commit ee6a6268d651d4e42247b4f466c51599647a3228
> 
> Author: Andrew Stromnov 

Re: [macports-ports] 01/02: py-diff-match-patch: new port, version 20121119

[Ryan Schmidt]

On May 10, 2018, at 20:37, Zero King wrote:

> Zero King (l2dy) pushed a commit to branch master
> in repository macports-ports.
> 
> 
> https://github.com/macports/macports-ports/commit/5836a5624ac40d04cb12a73c4ef219c377100a16
> 
> commit 5836a5624ac40d04cb12a73c4ef219c377100a16
> 
> Author: Zero King
> AuthorDate: Fri May 11 01:35:20 2018 +
> 
> 
> py-diff-match-patch: new port, version 20121119
> 
> ---
>  python/py-diff-match-patch/Portfile | 33 +
>  1 file changed, 33 insertions(+)
> 
> 
> diff --git a/python/py-diff-match-patch/Portfile 
> b/python/py-diff-match-patch/Portfile
> new file mode 100644
> index 000..a7cc717
> --- /dev/null
> +++ b/python/py-diff-match-patch/Portfile


> +master_sites
> https://files.pythonhosted.org/packages/22/82/46eaeab04805b4fac17630b59f30c4f2c8860988bcefd730ff4f1992908b

We don't want to use this style of URL, which needs to be updated every time 
the port's version is updated. Can the "pypi" fetch group be used instead?

Re: missing dejavusansmono in rrdtool pango cairo fontconfig - new insights

[Ryan Schmidt]

On May 10, 2018, at 20:00, macpo...@parvis.nl wrote:

> - So I propose to change the enforced backend in cairo from quartz to 
> fontconfig.

How would that be accomplished?

I thought the quartz variant was only supposed to add optional functionality to 
cairo. I turned the variant on unconditionally (years ago now) because I 
couldn't think of a reason why anyone wouldn't want that optional functionality 
to be available to other ports. See https://trac.macports.org/ticket/44414.

Re: Qt5 port group

[Ryan Schmidt]

On May 10, 2018, at 19:44, Marcus Calhoun-Lopez wrote:

> On May 9, 2018, at 11:07 AM, Ryan Schmidt wrote:
> 
>> My understanding of the fact that they conflict is that there is some latest 
>> version of Qt that is compatible with each version of macOS, and that by 
>> using the qt5 portgroup, one automatically receives that version. However, 
>> in practice, that does not appear to be the case. I see build failures of my 
>> Qt-using ports on some macOS versions because the chosen version of Qt is 
>> not compatible with that version of macOS.
> 
> I am aware of one instance of the wrong Qt component being installed for a 
> particular system
> (https://trac.macports.org/ticket/55651).
> I am afraid I am unaware of any others.
> Do you happen to remember which ones fail?

My QupZilla port, which use QtWebEngine, can't be built on 10.10 or earlier 
anymore.


On 10.10, the reason is the one in the ticket you mentioned: the portgroup 
chooses the qt5 set of ports (5.10.x), which says:

> Using Xcode version 7.2.1, but at least version 7.3 is required to build Qt 
> WebEngine.
> QtWebEngine will not be built.

So, the portgroup chose a version of Qt that doesn't work on the OS.

https://build.macports.org/builders/ports-10.10_x86_64-builder/builds/54417/steps/install-dependencies/logs/stdio


On 10.9, the reason is that the portgroup chooses qt58, but:

> Project ERROR: QupZilla requires at least Qt 5.9.0!


Ok, so there's nothing we can do about that.

https://build.macports.org/builders/ports-10.9_x86_64-builder/builds/56597/steps/install-port/logs/stdio


On 10.8, the portgroup choose qt57, with the error:

> Error: qt57-qtwebengine requires OS X 10.9 or later

Again, the portgroup chose a version of Qt that doesn't work on the OS.

https://build.macports.org/builders/ports-10.8_x86_64_legacy-builder/builds/60255/steps/install-dependencies/logs/stdio


On 10.7, the portgroup chose qt56, but:

> Error: qt56-qtwebengine requires OS X 10.9 or later

https://build.macports.org/builders/ports-10.7_x86_64_legacy-builder/builds/66544/steps/install-dependencies/logs/stdio


On 10.6, the portgroup chose qt55, but:

> Error: qt55-qtbase requires OS X 10.7 or later


https://build.macports.org/builders/ports-10.6_x86_64_legacy-builder/builds/61133/steps/install-dependencies/logs/stdio



> As a side note, I should have taken care of ticket #55651 by now, but 
> QtWebEngine is a bit of corner case.
> It does not seem to be widely used based on the number of Portfiles that use 
> it.

Re: [macports-ports] branch master updated: libiodbc: provide variant for extra libodbc.so library

[Ryan Schmidt]

On May 9, 2018, at 13:03, Ryan Schmidt wrote:

> The variant needs to contain the "conflicts unixODBC" line, doesn't it?
> 
> The unixODBC port still declares that it conflicts with libiodbc. Now it only 
> conflicts with libiodbc if the libodbc variant is used, but we don't have a 
> syntax for specifying that directly. The simplest workaround I can think of, 
> which we've used in a few other ports, is to declare the conflict in unixODBC 
> only if the libodbc.a file exists on disk.

Actually, the ports still conflict in all cases, on 
/opt/local/include/odbcinst.h at least.

Re: [macports-ports] branch master updated: poedit: new port @2.0.7

[Ryan Schmidt]

On May 8, 2018, at 13:53, Rainer Müller wrote:

> I appreciate that you stepped up as the maintainer of poedit after I had 
> given up on it! [1]
> 
> However, the poedit port now bundles full builds of other software, including 
> zlib, gettext, boost, icu, and even wxWidgets.
> 
> That really should be avoided, as this software is already available in 
> separate MacPorts ports. The libraries should be shared and reused instead of 
> building the same software again. Bundling is also a nightmare for 
> maintaining a port, as it implies that any patches applied to the 
> corresponding ports also need to be applied to the sources in the poedit 
> port. Updates will also only be delivered with updates of poedit, so upstream 
> bugs can linger on for a long time.

Generally that's true. Boost is a special case, because boost's developers 
don't care about backward compatibility. It's a good idea for projects to 
bundle and use the version of boost they need.

Re: Qt5 port group

[Ryan Schmidt]

On May 9, 2018, at 07:18, Craig Treleaven wrote:

> On May 8, 2018, at 5:06 AM, Vincent Habchi wrote:
> 
>> I was in the process of modifying the Qt5 Port group to allow for choosing 
>> the Qt version one wants to link an application against using variants. 
>> However, before I go further, I’d like to know if concurrent installations 
>> of different Qt5 versions are supported in MacPorts. If not, what I do is 
>> just futile.
> 
> Um, there are subports for each Qt5 version.  Picking one at random:
> 
> $ port info qt57-qtwebkit
> qt57-qtwebkit @5.7.1_1 (aqua)
> Variants: debug, examples, tests, universal
> 
> Description:  Tools and Module(s) for Qt Tool Kit 5: Qt WebKit and Qt 
> WebKit Widgets
> Homepage: http://qt.io
> 
> Extract Dependencies: xz
> Build Dependencies:   python27, pkgconfig
> Library Dependencies: fontconfig, icu, leveldb, webp, libxml2, libxslt, zlib, 
> sqlite3, qt57-qtdeclarative, qt57-qtlocation, qt57-qtmultimedia, 
> qt57-qtsensors, qt57-qtwebchannel, qt57-qtxmlpatterns, qt57-qtbase
> Conflicts with:   qt3, qt3-mac, qt56-qtbase, qt58-qtbase, qt5-qtbase, 
> qt55-qtbase, qt59-qtbase
> Platforms:macosx
> License:  {LGPL-3 GPL-3 OpenSSLException}
> Maintainers:  Email: mcalh...@macports.org, GitHub: 
> MarcusCalhoun-Lopez
>  Policy: openmaintainer
> 
> Notice that the port depends on several Qt5 ports which are all specified at 
> the same level (“57”).  It conflicts with other versions of Qt.
> 
> Is that not sufficient?

My understanding of the fact that they conflict is that there is some latest 
version of Qt that is compatible with each version of macOS, and that by using 
the qt5 portgroup, one automatically receives that version. However, in 
practice, that does not appear to be the case. I see build failures of my 
Qt-using ports on some macOS versions because the chosen version of Qt is not 
compatible with that version of macOS.

Re: [macports-ports] branch master updated: libiodbc: provide variant for extra libodbc.so library

[Ryan Schmidt]

On May 7, 2018, at 10:39, Jeremy L wrote:

> Jeremy L (nerdling) pushed a commit to branch master
> in repository macports-ports.
> 
> 
> https://github.com/macports/macports-ports/commit/c175b9ba889d42decf33b787906eb70801265031
> 
> The following commit(s) were added to refs/heads/master by this push:
> 
>  new c175b9b  libiodbc: provide variant for extra libodbc.so library
> 
> c175b9b is described below
> 
> 
> commit c175b9ba889d42decf33b787906eb70801265031
> 
> Author: Jeremy Lavergne
> AuthorDate: Mon May 7 11:39:28 2018 -0400
> 
> 
> libiodbc: provide variant for extra libodbc.so library
> 
> Fixes trac 55661

Don't forget to refer to Trac tickets in Git commit messages by their absolute 
URL, so that Trac can automatically close tickets for you.


> diff --git a/devel/libiodbc/Portfile b/devel/libiodbc/Portfile
> index 411c695..1de9a3b 100644
> --- a/devel/libiodbc/Portfile
> +++ b/devel/libiodbc/Portfile
> @@ -7,7 +7,7 @@ PortGroup   active_variants 1.1
>  github.setupopenlink iODBC 3.52.12 v
>  #override name (keep it lowercase)
>  namelibiodbc
> -conflicts   unixODBC
> +revision1
>  categories  devel
>  maintainers {snc @nerdling} openmaintainer
>  license BSD
> @@ -26,6 +26,12 @@ depends_build-appendport:automake \
>  
>  patchfiles-append   patch-iodbcinst-unicode.h.diff
>  
> +configure.args-append   --disable-libodbc
> +
> +variant libodbc description {install extra libodbc.so library} {
> +configure.args-replace --disable-libodbc --enable-libodbc
> +}

This variant appears to install the file libodbc.a, not libodbc.so.

The variant needs to contain the "conflicts unixODBC" line, doesn't it?

The unixODBC port still declares that it conflicts with libiodbc. Now it only 
conflicts with libiodbc if the libodbc variant is used, but we don't have a 
syntax for specifying that directly. The simplest workaround I can think of, 
which we've used in a few other ports, is to declare the conflict in unixODBC 
only if the libodbc.a file exists on disk.


> @@ -54,7 +60,7 @@ variant x11 {
>  configure.args-delete   --disable-gui
>  }
>  
> -default_variants +x11
> +default_variants +x11 +libiodbc

Typo: the variant name is libodbc, not libiodbc.

Re: [macports-ports] branch master updated: scidavis: remove unnecessary reinplace instructions in case of standard prefix

[Ryan Schmidt]

On May 8, 2018, at 08:49, Nicolas Pavillon wrote:

> NicosPavlov pushed a commit to branch master
> in repository macports-ports.
> 
> 
> https://github.com/macports/macports-ports/commit/f578df0c2a5e1479fa834624b11e487ed79b23cb
> 
> The following commit(s) were added to refs/heads/master by this push:
> 
>  new f578df0  scidavis: remove unnecessary reinplace instructions in case 
> of standard prefix
> 
> f578df0 is described below
> 
> 
> commit f578df0c2a5e1479fa834624b11e487ed79b23cb
> 
> Author: Nicolas Pavillon
> AuthorDate: Tue May 8 22:49:58 2018 +0900
> 
> 
> scidavis: remove unnecessary reinplace instructions in case of standard 
> prefix
> 
> ---
>  science/scidavis/Portfile | 8 +---
>  1 file changed, 5 insertions(+), 3 deletions(-)
> 
> diff --git a/science/scidavis/Portfile b/science/scidavis/Portfile
> index 7dc8a01..f6696db 100644
> --- a/science/scidavis/Portfile
> +++ b/science/scidavis/Portfile
> @@ -41,15 +41,17 @@ configure.pre_args-append   "'CONFIG+=osx_dist 
> noassistant'"
>  
>  pre-configure {
>  reinplace "s|/usr|${prefix}|g" ${worksrcpath}/config.pri
> -reinplace "s|/opt/local|${prefix}|g" ${worksrcpath}/config.pri
> -reinplace "s|/opt/local|${prefix}|g" ${worksrcpath}/mkMacDist.sh
>  reinplace "s|/usr|${prefix}|g" 
> ${worksrcpath}/fitPlugins/exp_saturation/exp_saturation.pro
>  reinplace "s|/usr|${prefix}|g" 
> ${worksrcpath}/fitPlugins/explin/explin.pro
>  reinplace "s|/usr|${prefix}|g" 
> ${worksrcpath}/fitPlugins/fitRational0/fitRational0.pro
>  reinplace "s|/usr|${prefix}|g" 
> ${worksrcpath}/fitPlugins/fitRational1/fitRational1.pro
>  reinplace "s|/usr|${prefix}|g" 
> ${worksrcpath}/fitPlugins/planck_wavelength/planck_wavelength.pro
>  
> -reinplace "s|@PREFIX@|${prefix}|g" 
> ${worksrcpath}/3rdparty/liborigin/CMakeLists.txt

This reinplace is always needed, even when the prefix is /opt/local.

> +if {${prefix} ne "/opt/local"} {
> +reinplace "s|/opt/local|${prefix}|g" ${worksrcpath}/config.pri
> +reinplace "s|/opt/local|${prefix}|g" ${worksrcpath}/mkMacDist.sh
> +reinplace "s|@PREFIX@|${prefix}|g" 
> ${worksrcpath}/3rdparty/liborigin/CMakeLists.txt
> +}

Re: [macports-ports] branch master updated: acl2: Use github releases for fetching distfile

[Ryan Schmidt]

On May 7, 2018, at 16:18, Jackson Isaac wrote:

> Jackson Isaac (JacksonIsaac) pushed a commit to branch master
> in repository macports-ports.
> 
> 
> https://github.com/macports/macports-ports/commit/1b77897c4010309d7346607ff5b5728dac50dd88
> 
> The following commit(s) were added to refs/heads/master by this push:
> 
>  new 1b77897  acl2: Use github releases for fetching distfile


> @@ -41,10 +45,11 @@ in the included examples. This can take several hours.
>  homepagehttp://www.cs.utexas.edu/users/moore/acl2/${shortversion}
>  distfiles   ${name}-${version}${extract.suffix}
>  
> -checksums   md5 d343b03e94f1f15368355dd9309cf9a0 \
> -sha19e94663075aa5d87913a4129979f176316a83c8b \
> -rmd160  a013826458b0004b980283ad9b43d65748c87bc1 \
> -sha256  
> e44bc2f6bcd605b2f7b766f2112ef178c325cf2e6b438bcc77d7e2deb8195756 \
> +checksums   md5 b0269a6c7ea89b6442acafd59452764d \
> +sha1197b90da2efc37b4558aad0f58314403ee8d25a4 \
> +rmd160  84ff4521dfe5f115ca1298d1acec25480231f3e1 \
> +sha256  
> 32659eca6eaad00ab455779644dd9df9f82c898b81780df0eb040adc13e204c6 \
> +size77190378

Because the file name didn't change, but its contents did, this was a stealth 
update, and needed to be handled per:

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

Re: [macports-ports] branch master updated: Improvements to Pull Request Template

[Ryan Schmidt]

On May 7, 2018, at 09:22, Perry E. Metzger wrote:

> Perry E. Metzger (pmetzger) pushed a commit to branch master
> in repository macports-ports.
> 
> 
> https://github.com/macports/macports-ports/commit/6c30941ab56093c30c52cd10c87cd0b776b0232c
> 
> The following commit(s) were added to refs/heads/master by this push:
> 
>  new 6c30941  Improvements to Pull Request Template
> 
> 6c30941 is described below
> 
> 
> commit 6c30941ab56093c30c52cd10c87cd0b776b0232c
> 
> Author: Perry E. Metzger
> AuthorDate: Mon May 7 10:22:25 2018 -0400
> 
> 
> Improvements to Pull Request Template
> 
> 
> 
> - Add suggestion that commits be squashed and minimized.
> 
> - Remove suggestion that template be removed for minor commits, it is
>   almost always the case that people remove them inappropriately.

> - Remove instructions on how not to alert the maintainer, even for
>   openmaintainer we prefer to alert people to changes.

When I submit a PR to add a maintainer's GitHub handle to their ports, I assign 
the ticket to them (if I can; if I can't, because they're not in the developer 
team, I @mention them in the description), and then I use [skip notification] 
so that they aren't notified about it a second time (once for the PR, once for 
the notification comment), and so that any other maintainers aren't bothered 
about the change.

If the notification bot were a little smarter, and didn't do a notification if 
the only person to be notified is the person to whom the PR is already 
assigned, or from whom a review was already requested, that would help a little.

Re: [macports-ports] 02/02: py-python-augeas05: mark as obsolete

[Ryan Schmidt]

On May 7, 2018, at 08:06, Marius Schamschula wrote:

> What is the proper way of dealing with obsoleted subports?

For each subport, mark it replaced by its replacement.

The py-cherrypy3 port shows one way that this could be accomplished.

Re: [macports-ports] 02/02: py-python-augeas05: mark as obsolete

[Ryan Schmidt]

On May 5, 2018, at 10:14, Marius Schamschula wrote:

> Marius Schamschula (Schamschula) pushed a commit to branch master
> in repository macports-ports.
> 
> 
> https://github.com/macports/macports-ports/commit/183d848728bcdec1ac30dce5260f0437feeda485
> 
> commit 183d848728bcdec1ac30dce5260f0437feeda485
> 
> Author: Marius Schamschula
> AuthorDate: Sat May 5 10:14:16 2018 -0500
> 
> 
> py-python-augeas05: mark as obsolete
> 
> ---
>  python/py-python-augeas05/Portfile | 28 +---
>  1 file changed, 5 insertions(+), 23 deletions(-)
> 
> 
> diff --git a/python/py-python-augeas05/Portfile 
> b/python/py-python-augeas05/Portfile
> index 51038ea..648168e 100644
> --- a/python/py-python-augeas05/Portfile
> +++ b/python/py-python-augeas05/Portfile
> @@ -1,31 +1,13 @@
>  # -*- 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
>  
>  PortSystem  1.0
> -PortGroup   python 1.0
> +replaced_by py-python-augeas
> +PortGroup   obsolete 1.0
>  
>  namepy-python-augeas05
> -set real_name   python-augeas
>  epoch   1
>  version 0.5.0
> -python.versions 27 34 35 36

This abruptly removed the py27-python-augeas05, py34-python-augeas05, 
py35-python-augeas05, py36-python-augeas05 subports without transitioning them 
to the replacement subports under the py-python-augeas port.

Re: How do I add something to our GitHub checklist?

[Ryan Schmidt]

On May 7, 2018, at 07:41, Perry E. Metzger wrote:

> When pull requests come in, users are asked to fill out a short
> checklist. I'd like to add a reminder to squash your commits into it
> -- this has become a frequent issue with pull requests from new
> contributors.
> 
> Where do I find the checklist to edit it?

https://github.com/macports/macports-ports/blob/master/.github/PULL_REQUEST_TEMPLATE.md

Re: [macports-ports] branch master updated: duck: clear configure.cxx_stdlib flag

[Ryan Schmidt]

On May 6, 2018, at 15:34, Joshua Root wrote:

> On 2018-5-6 20:37 , Ryan Schmidt wrote:
>> 
>> On May 5, 2018, at 20:54, Joshua Root wrote:
>> 
>>> We record what stdlib it was *asked*
>>> to build with in the registry. The stdlib it actually was built with is
>>> determined by inspecting the binaries.
>> 
>> Which is precisely why it is more or less required that the author of the 
>> Portfile correctly specify in the Portfile the stdlib that the binaries were 
>> built with, right? So that it gets recorded correctly in the registry? So 
>> that rev-upgrade won't claim there is a mismatch?
> 
> If you specify one it needs to be correct, yes. But rev-upgrade won't
> claim there's a mismatch if you clear configure.cxx_stdlib. You didn't
> ask for it to be built with any stdlib in particular, so whatever it
> uses is OK.

I expected this to be used for dependencies too. (If it isn't used that way 
now, maybe it can be in the future.)

For example, the libxl port uses a binary built with libstdc++, so it uses 
"configure.cxx_stdlib libstdc++" to inform MacPorts base of that. If I now make 
another port that uses C++ and libxl, it too must use libstdc++. If I forget to 
write "configure.cxx_stdlib libstdc++" in that new port, MacPorts base could 
notify me that there is a C++ stdlib mismatch between this port and its 
dependency. If libxl hadn't indicated which stdlib it uses, that would not be 
possible.

Re: [macports-ports] branch master updated: duck: clear configure.cxx_stdlib flag

[Ryan Schmidt]

On May 5, 2018, at 20:54, Joshua Root wrote:

> On 2018-5-6 10:05 , Ryan Schmidt wrote:
>> 
>> On May 5, 2018, at 19:04, Joshua Root wrote:
>> 
>>> On 2018-5-6 09:55 , Ryan Schmidt wrote:
>>>> 
>>>> On May 5, 2018, at 16:36, Jackson Isaac wrote:
>>>> 
>>>>> +## Upstream binary seems to be built using libstdc++
>>>>> 
>>>>> +#  Port keeps failing on rev-upgrade since it
>>>>> 
>>>>> +#  checks if duck is built against libc++ or not.
>>>>> 
>>>>> +configure.cxx_stdlib
>>>> 
>>>> Then set it to libstdc++. Don't clear it.
>>> 
>>> It's a binary, the port has no control over which stdlib is used, so
>>> clearing the option is appropriate. Compare the gcc ports.
>> 
>> I thought the idea was for the portfile to tell MacPorts base what stdlib 
>> the binary was built with, so that MacPorts base could record that in the 
>> registry when it's installed. That's why I set cxx_stdlib in my ports that 
>> install binaries, like libxl.
> 
> Setting configure.cxx_stdlib tells base to ask the software to build
> with a given stdlib (via CXXFLAGS).

Yes, certainly.

> We record what stdlib it was *asked*
> to build with in the registry. The stdlib it actually was built with is
> determined by inspecting the binaries.

Which is precisely why it is more or less required that the author of the 
Portfile correctly specify in the Portfile the stdlib that the binaries were 
built with, right? So that it gets recorded correctly in the registry? So that 
rev-upgrade won't claim there is a mismatch?


> I guess setting it for ports that don't build from source isn't exactly
> wrong; you can still be asking even if they ignore it. You do need to
> notice when a new version changes stdlibs and update the portfile though.

Certainly.

Re: Remove all remnants of python <2.7

[Ryan Schmidt]

On May 4, 2018, at 08:05, Perry E. Metzger wrote:

> Yesterday, Ryan pointed out in the course of a pull request that the
> port in question still had support for python 2.5(!).

It needn't be a surprise that the ports (InsightToolkit*) have python 2.5 
support. The ports simply offer python variants, and use the latest versions of 
python that were available at the time--python24 and python25. These 
InsightToolkit* ports have not really been updated in a very long time.

It is not a controversial idea that it would be great if the ports were updated 
to use a newer python instead. There is a 4-year-old ticket about that issue 
for these ports, but nobody has wanted to do the work so far. There are 
numerous open tickets about these ports, including one requesting the removal 
of the older versions.

python26 and later are structured differently (as a "framework" build) from 
python25 and earlier. This can require changes in ports beyond simply changing 
the python version number. There is an 8-year-old ticket open about that issue 
for these ports.

Re: Compiler blacklist 'shorthand'

[Ryan Schmidt]

On May 6, 2018, at 05:27, Chris Jones wrote:

> On 6 May 2018, at 11:19 am, Ryan Schmidt wrote:
> 
>> On May 6, 2018, at 05:18, Rainer Müller wrote:
>> 
>>> On 2018-05-06 12:07, Ryan Schmidt wrote:
>>> 
>>>> On May 5, 2018, at 19:36, Craig Treleaven wrote:
>>>> 
>>>>> A couple of times recently, I’ve noticed boilerplate in ports that 
>>>>> require C++14.  After including the compiler_blacklist_versions 
>>>>> portgroup, they then do some gymnastics like:
>>>>> 
>>>>> compiler.blacklist  *gcc-3.* *gcc-4.* {*gcc-5.[0-3]} \
>>>>> {clang < 800} macports-clang-3.4 
>>>>> macports-clang-3.5 macports-clang-3.6 macports-clang-3.7
>>>>> 
>>>>> Would it not be easier to use and maintain if we had some shorthand 
>>>>> definitions.  Maybe something like:
>>>>> 
>>>>> compiler.blacklist  ${min_cxx14}
>>>>> 
>>>>> “min_cxx14” would be defined in the portgroup and then expand to the 
>>>>> above...assuming the above actually does a good job of blacklisting 
>>>>> compilers that don’t support C++14!
>>>>> 
>>>>> A major advantage is that if our list of non-C++14 compilers ever 
>>>>> changes, it only needs to be updated in one spot.
>>>>> 
>>>>> I suspect there would be a few other shorthand lists that could be 
>>>>> pre-defined.
>>>>> 
>>>>> Thoughts?
>>>> 
>>>> Yes, we should have support for specifying the required language 
>>>> standard(s) in Portfile, so that MacPorts could then select a compatible 
>>>> compiler.
>>>> 
>>>> Until we have that, you need to blacklist incompatible compilers.
>>>> 
>>>> If you require C++11, include the cxx11 1.1 portgroup which will do what's 
>>>> needed for you, including blacklisting incompatible compilers and ensuring 
>>>> the right C++ standard library is used.
>>>> 
>>>> If you require C++14, include the cxx11 1.1 portgroup and additionally use 
>>>> "compiler.blacklist-append {clang < 602}".
>>> 
>>> This does not seem very intuitive. Maybe that should be put into a
>>> simple cxx14 port group acting as a thin wrapper as shown below?
>>> 
>>> # cxx14-1.1.tcl
>>> PortGroup cxx11 1.1
>>> compiler.blacklist-append {clang < 602}
>> 
>> I didn't say it was intuitive; I just said that's how it is right now.
>> 
>> Such a portgroup could be created, but I dislike the proliferation of 
>> portgroups. 
> 
> Agreed. We would already now require additional  cxx14 and cxx17 portgroups, 
> with more coming in the future (gcc8 has provisional support for the next 
> cxx2y standard.). It just doesn’t scale well.
> 
> We should, I think, instead look towards instead migrating the functionality 
> to do this from cxx11  into a new (better named) group that can handle all 
> the standards going forward. Like the languages group Marcus previously 
> mentioned.  Then cxx11 should be retired and ports moved over to this new 
> group.

As I've said in a different thread some months ago, I think it should be in 
base.

Re: Compiler blacklist 'shorthand'

[Ryan Schmidt]

On May 6, 2018, at 05:18, Rainer Müller wrote:

> On 2018-05-06 12:07, Ryan Schmidt wrote:
>> 
>> On May 5, 2018, at 19:36, Craig Treleaven wrote:
>> 
>>> A couple of times recently, I’ve noticed boilerplate in ports that require 
>>> C++14.  After including the compiler_blacklist_versions portgroup, they 
>>> then do some gymnastics like:
>>> 
>>> compiler.blacklist  *gcc-3.* *gcc-4.* {*gcc-5.[0-3]} \
>>>   {clang < 800} macports-clang-3.4 
>>> macports-clang-3.5 macports-clang-3.6 macports-clang-3.7
>>> 
>>> Would it not be easier to use and maintain if we had some shorthand 
>>> definitions.  Maybe something like:
>>> 
>>> compiler.blacklist  ${min_cxx14}
>>> 
>>> “min_cxx14” would be defined in the portgroup and then expand to the 
>>> above...assuming the above actually does a good job of blacklisting 
>>> compilers that don’t support C++14!
>>> 
>>> A major advantage is that if our list of non-C++14 compilers ever changes, 
>>> it only needs to be updated in one spot.
>>> 
>>> I suspect there would be a few other shorthand lists that could be 
>>> pre-defined.
>>> 
>>> Thoughts?
>> 
>> Yes, we should have support for specifying the required language standard(s) 
>> in Portfile, so that MacPorts could then select a compatible compiler.
>> 
>> Until we have that, you need to blacklist incompatible compilers.
>> 
>> If you require C++11, include the cxx11 1.1 portgroup which will do what's 
>> needed for you, including blacklisting incompatible compilers and ensuring 
>> the right C++ standard library is used.
>> 
>> If you require C++14, include the cxx11 1.1 portgroup and additionally use 
>> "compiler.blacklist-append {clang < 602}".
> 
> This does not seem very intuitive. Maybe that should be put into a
> simple cxx14 port group acting as a thin wrapper as shown below?
> 
> # cxx14-1.1.tcl
> PortGroup cxx11 1.1
> compiler.blacklist-append {clang < 602}

I didn't say it was intuitive; I just said that's how it is right now.

Such a portgroup could be created, but I dislike the proliferation of 
portgroups. 

Re: Instructions for creating patches

[Ryan Schmidt]

On May 4, 2018, at 17:33, Rainer Müller wrote:

> On 2018-05-03 09:14, Zero King wrote:
>> On Thu, May 03, 2018 at 08:51:49AM +0200, Mojca Miklavec wrote:
>>> On 1 May 2018 at 16:11, Rainer Müller wrote:
 
 The guide uses "Portfile-rrdtool.diff" as an example filename [1]. Some
 users seem to take that literally and submit patches with that name.
 
 [1] https://guide.macports.org/#development.patches.portfile
>>> 
>>> Looking at this part of the guide, I would suggest that we change the
>>> instructions. It almost definitely makes more sense to use "git diff
>>> ..." instead of "diff ...", but more importantly we probably want to
>>> suggest creating a pull request at that point anyway.
>> 
>> Some contributors would edit the Portfile in
>> /opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/ports/,
>> which isn't a git repository and `git diff` won't work for them.
> 
> If users edit the ports tree directly there is no way to diff at all

Sure there is. The user just has to copy the portfile before making changes. 
The above-referenced guide section shows how to do that.

> and
> the changes will be lost on the next sync. They should never do that.

There is nothing wrong with doing that, if the user is ok with losing the 
changes on the next sync. I've certainly used that method before.


It's certainly fine if we want to change the documentation to show how to PR 
instead, provided we have complete, correct, and easy-to-understand 
documentation about how to do that, in one and only one place (the guide).

Re: Compiler blacklist 'shorthand'

[Ryan Schmidt]

On May 5, 2018, at 19:36, Craig Treleaven wrote:

> A couple of times recently, I’ve noticed boilerplate in ports that require 
> C++14.  After including the compiler_blacklist_versions portgroup, they then 
> do some gymnastics like:
> 
> compiler.blacklist  *gcc-3.* *gcc-4.* {*gcc-5.[0-3]} \
>{clang < 800} macports-clang-3.4 
> macports-clang-3.5 macports-clang-3.6 macports-clang-3.7
> 
> Would it not be easier to use and maintain if we had some shorthand 
> definitions.  Maybe something like:
> 
> compiler.blacklist  ${min_cxx14}
> 
> “min_cxx14” would be defined in the portgroup and then expand to the 
> above...assuming the above actually does a good job of blacklisting compilers 
> that don’t support C++14!
> 
> A major advantage is that if our list of non-C++14 compilers ever changes, it 
> only needs to be updated in one spot.
> 
> I suspect there would be a few other shorthand lists that could be 
> pre-defined.
> 
> Thoughts?

Yes, we should have support for specifying the required language standard(s) in 
Portfile, so that MacPorts could then select a compatible compiler.

Until we have that, you need to blacklist incompatible compilers.

If you require C++11, include the cxx11 1.1 portgroup which will do what's 
needed for you, including blacklisting incompatible compilers and ensuring the 
right C++ standard library is used.

If you require C++14, include the cxx11 1.1 portgroup and additionally use 
"compiler.blacklist-append {clang < 602}".

I'm not familiar with the capabilities or functionality of the languages 1.0 
portgroup.

Re: [macports-ports] branch master updated: duck: clear configure.cxx_stdlib flag

[Ryan Schmidt]

On May 5, 2018, at 19:04, Joshua Root wrote:

> On 2018-5-6 09:55 , Ryan Schmidt wrote:
>> 
>> On May 5, 2018, at 16:36, Jackson Isaac wrote:
>> 
>>> +## Upstream binary seems to be built using libstdc++
>>> 
>>> +#  Port keeps failing on rev-upgrade since it
>>> 
>>> +#  checks if duck is built against libc++ or not.
>>> 
>>> +configure.cxx_stdlib
>> 
>> Then set it to libstdc++. Don't clear it.
> 
> It's a binary, the port has no control over which stdlib is used, so
> clearing the option is appropriate. Compare the gcc ports.

I thought the idea was for the portfile to tell MacPorts base what stdlib the 
binary was built with, so that MacPorts base could record that in the registry 
when it's installed. That's why I set cxx_stdlib in my ports that install 
binaries, like libxl.

Re: [macports-ports] branch master updated: duck: clear configure.cxx_stdlib flag

[Ryan Schmidt]

On May 5, 2018, at 16:36, Jackson Isaac wrote:

> Jackson Isaac (JacksonIsaac) pushed a commit to branch master
> in repository macports-ports.
> 
> 
> https://github.com/macports/macports-ports/commit/efaaa894e2e0a8af5e9918d296889db9929e7103
> 
> The following commit(s) were added to refs/heads/master by this push:
> 
>  new efaaa89  duck: clear configure.cxx_stdlib flag
> 
> efaaa89 is described below
> 
> 
> commit efaaa894e2e0a8af5e9918d296889db9929e7103
> 
> Author: ijackson
> AuthorDate: Sun May 6 03:06:43 2018 +0530
> 
> 
> duck: clear configure.cxx_stdlib flag
> 
> rev-upgrade gives broken port error for duck.
> Upstream binary seems to be built against
> libstdc++ and port was checking it against
> libc++.
> 
> ---
>  net/duck/Portfile | 5 +
>  1 file changed, 5 insertions(+)
> 
> 
> diff --git a/net/duck/Portfile b/net/duck/Portfile
> 
> index 09dde06..5459eb5 100644
> 
> --- a/net/duck/Portfile
> 
> +++ b/net/duck/Portfile
> 
> @@ -29,6 +29,11 @@ use_configure   no
> 
>  
>  build { }
>  
> 
> +## Upstream binary seems to be built using libstdc++
> 
> +#  Port keeps failing on rev-upgrade since it
> 
> +#  checks if duck is built against libc++ or not.
> 
> +configure.cxx_stdlib

Then set it to libstdc++. Don't clear it.

Re: [macports-ports] branch master updated: root6: update default compiler variants

[Ryan Schmidt]

> On May 2, 2018, at 03:43, Chris Jones wrote:
> 
>> You don't really need [expr] here, do you?
> 
> It seemed to work, and I think I just copied the pattern above from another 
> Portfile...

I've submitted a PR to remove that pattern from the other ports:

https://github.com/macports/macports-ports/pull/1713

Re: [macports-ports] branch master updated: root6: update default compiler variants

[Ryan Schmidt]

On May 1, 2018, at 12:52, Chris Jones wrote:

> +# Enable variants that only seem to work when not using macports clang...
> +if [expr ![string match macports-clang-* ${configure.compiler}] ] {
> +default_variants-append +veccore +davix
> +}

You don't really need [expr] here, do you?

Re: [macports-ports] branch master updated: py-pybtex: Update to 0.21, fix master_sites.

[Ryan Schmidt]

On Apr 30, 2018, at 23:17, David Strubbe wrote:

> David Strubbe (dstrubbe) pushed a commit to branch master
> in repository macports-ports.
> 
> 
> https://github.com/macports/macports-ports/commit/16798c052e98961df280c859023ed49a9ab0cab5
> 
> The following commit(s) were added to refs/heads/master by this push:
> 
>  new 16798c0  py-pybtex: Update to 0.21, fix master_sites.
> 
> 16798c0 is described below
> 
> 
> commit 16798c052e98961df280c859023ed49a9ab0cab5
> 
> Author: David Strubbe
> AuthorDate: Mon Apr 30 21:17:26 2018 -0700
> 
> 
> py-pybtex: Update to 0.21, fix master_sites.
> 
> ---
>  python/py-pybtex/Portfile | 14 --
>  1 file changed, 8 insertions(+), 6 deletions(-)


> -master_sitespypi:p/pybtex/
> +master_sites
> https://files.pythonhosted.org/packages/82/59/d46b4a84faacd7c419cfc9a442b7940d6d625d127b83d83666e2a8b203d8

Same question here: Why change this? This is less convenient.


> -use_bzip2   yes
> +use_bzip2   no

That's the default. Just remove the line.

Re: [macports-ports] branch master updated: py-pyslides: Update to 0.9.23. Fix dependencies and master_sites.

[Ryan Schmidt]

On Apr 30, 2018, at 23:37, David Strubbe wrote:

> David Strubbe (dstrubbe) pushed a commit to branch master
> in repository macports-ports.
> 
> 
> https://github.com/macports/macports-ports/commit/78bce97dd6c1368229e320435a4dbf20c4fd4aed
> 
> The following commit(s) were added to refs/heads/master by this push:
> 
>  new 78bce97  py-pyslides: Update to 0.9.23. Fix dependencies and 
> master_sites.
> 
> 78bce97 is described below
> 
> 
> commit 78bce97dd6c1368229e320435a4dbf20c4fd4aed
> 
> Author: David Strubbe
> AuthorDate: Mon Apr 30 21:37:31 2018 -0700
> 
> 
> py-pyslides: Update to 0.9.23. Fix dependencies and master_sites.
> 
> ---
>  python/py-pyslides/Portfile | 29 +++--
>  1 file changed, 15 insertions(+), 14 deletions(-)


> -master_sitespypi:p/pyslides
> -#https://files.pythonhosted.org/packages/e7/fc/975831311ccecdb5d1488a310e9eca2249048c8b2a8d073ab7059960e060
> +master_sites
> https://files.pythonhosted.org/packages/df/6e/63716cc6a3dc8f7408d72ecd351e15b449f8be89d20f710d9a96da519615

Why change it from "pypi:p/pyslides" which seems to work fine? We don't want to 
have to update these hashes in master_sites every time the port's version is 
updated.

Re: [macports-ports] branch master updated: esmf: fix build with gcc5 or earlier

[Ryan Schmidt]

On Apr 28, 2018, at 01:10, Takeshi Enomoto wrote:

> Takeshi Enomoto (tenomoto) pushed a commit to branch master
> in repository macports-ports.
> 
> 
> https://github.com/macports/macports-ports/commit/218d3fd276c65f9e22e19f7ec3ef686322e6a156
> 
> The following commit(s) were added to refs/heads/master by this push:
> 
>  new 218d3fd  esmf: fix build with gcc5 or earlier
> 
> 218d3fd is described below
> 
> 
> commit 218d3fd276c65f9e22e19f7ec3ef686322e6a156
> 
> Author: Takeshi Enomoto 

You have two typos in your email address.


> AuthorDate: Sat Apr 28 14:33:15 2018 +0900
> 
> 
> esmf: fix build with gcc5 or earlier
> 


> +if {[variant_isset gcc47] || [variant_isset gcc48] || [variant_isset gcc49] 
> || [variant_isset gcc5]} {
> +configure.cxxflags-append   -std=c++11
> +} elseif {[variant_isset gcc44] || [variant_isset gcc45] || [variant_isset 
> gcc46]} {
> +configure.cxxflags-append   -std=c++0x
> +}

gcc6 and later don't need such a flag?

Re: [macports-ports] 01/17: cargo PG: modify comments

[Ryan Schmidt]

On Apr 30, 2018, at 20:16, Rainer Müller wrote:

> However, why do we add a license header to the port groups at all?
> We also do not add it to each Portfile. I think we should drop the
> license headers from all port groups.

Files in base have the copyright header. Portgroups used to be in base.

Re: [macports-ports] branch master updated: qtcurve: update to 1.9.0

[Ryan Schmidt]

On Apr 30, 2018, at 10:06, Perry E. Metzger wrote:

> Perry E. Metzger (pmetzger) pushed a commit to branch master
> in repository macports-ports.
> 
> 
> https://github.com/macports/macports-ports/commit/6b1fe110a0a558d323ebc8b62ca8fb9938d824c1
> 
> The following commit(s) were added to refs/heads/master by this push:
> 
>  new 6b1fe11  qtcurve: update to 1.9.0
> 
> 6b1fe11 is described below
> 
> 
> commit 6b1fe110a0a558d323ebc8b62ca8fb9938d824c1
> 
> Author: Perry E. Metzger 

Please configure your git client to use your macports.org email address as the 
author of your commits. See:

https://trac.macports.org/wiki/WorkingWithGit


>  kde/qtcurve/Portfile   |  75 -
>  .../files/patch-deactivate-config-page.diff|  10 +-
>  .../files/patch-qt5-dbus-fixes-by-debian.diff  | 184 
> -
>  .../files/patch-simpler-translucent-menus.diff |  89 ++
>  kde/qtcurve/files/patch-systemconfig-support.diff  |  69 
>  kde/qtcurve/files/stylerc  | 102 +++-
>  6 files changed, 252 insertions(+), 277 deletions(-)


> -maintainers {gmail.com:rjvbertin @RJVB}
> +maintainers gmail.com:rjvbertin

Please don't remove the GitHub handle from the maintainers line.

Re: [macports-ports] branch master updated: duck: New port, version 6.4.6.27773

[Ryan Schmidt]

On Apr 30, 2018, at 15:12, Jackson Isaac wrote:

> Jackson Isaac (JacksonIsaac) pushed a commit to branch master
> in repository macports-ports.
> 
> 
> https://github.com/macports/macports-ports/commit/5624f07530e7dc202fd9d57b378232dd3fa4b1bf
> 
> The following commit(s) were added to refs/heads/master by this push:
> 
>  new 5624f07  duck: New port, version 6.4.6.27773
> 
> 5624f07 is described below
> 
> 
> commit 5624f07530e7dc202fd9d57b378232dd3fa4b1bf
> 
> Author: ijackson
> AuthorDate: Tue May 1 01:42:40 2018 +0530
> 
> 
> duck: New port, version 6.4.6.27773
> 
> Closes: https://trac.macports.org/ticket/50053
> 
> ---
>  net/duck/Portfile | 36 
>  1 file changed, 36 insertions(+)


> +license GPL

It's extremely uncommon for software to be licensed under "any" version of the 
GPL, which is what "license GPL" means. (Mostly, only Perl modules are licensed 
that way.) For this software, the LICENSE file is for GPL 3, but the source 
files I looked at in the repo have comment headers that say GPL 2 or later. If 
you find that holds true for the source files used to build the CLI, this 
should be changed to "license GPL-2+".

Re: Force Mirror on Buildbot

[Ryan Schmidt]

On Apr 30, 2018, at 13:09, Zero King wrote:

> I'd like to mirror unar's distfile for backup, but "it has already been
> built and uploaded" so mirror was skipped if I force build the port on a
> portwatcher and I can't force a mirror job directly.

Yes, we need to allow forcing the mirroring job for a specific port. We haven't 
done that yet.

Re: [macports-ports] 01/17: cargo PG: modify comments

[Ryan Schmidt]

On Apr 29, 2018, at 22:26, Ryan Schmidt wrote:

> I'm not talking about removing or altering Apple's copyright notices; of 
> course they should remain. I'm talking about clause 3 of the license, the 
> non-endorsement clause.
> 
> I didn't claim we should add a second slightly different license in the 
> affected files. I claimed that we should not state, due to copy/paste error, 
> that Apple is involved in files they were not involved with. And in the files 
> that they were involved with, I wondered if we can modify clause 3 of the 
> license text from only mentioning Apple to mentioning both Apple and MacPorts.

For example, our LICENSE file was already changed from mentioning just Apple in 
the non-endorsement clause to mentioning both Apple and MacPorts, back in 2007:

https://github.com/macports/macports-base/commit/afa23c443cd9ee66df0f7b212ad9ed1f21055830


And Apple's name was changed from Apple Computer, Inc. to Apple Inc. in our 
LICENSE in 2009:

https://github.com/macports/macports-base/commit/b4cac8cd814dca61b1a263d2f86128375dc60baf


> The non-endorsement clause is gone entirely in the 2-clause BSD license, of 
> course, but I don't know what would be involved with relicensing MacPorts 
> under the 2-clause BSD license; it would probably be complicated.

Re: Strange behaviour of trace mode in MacPorts 2.4.3 / 10.13

[Ryan Schmidt]

On Apr 29, 2018, at 20:23, Helmut K. C. Tessarek wrote:

> On 2018-04-29 07:23, Joshua Root wrote:
>> Were dependencies declared on the ports providing those libraries? If
>> not, trace mode was just doing its job.
> 
> $ sudo port build -vst fontforge
> --->  Computing dependencies for fontforge
> --->  Fetching distfiles for fontforge
> --->  Verifying checksums for fontforge
> --->  Extracting fontforge
> --->  Applying patches to fontforge
> --->  Configuring fontforge
> Error: Failed to configure fontforge, consult
> /opt/local/var/macports/build/_Users_kct_data_work_ports_graphics_fontforge/fontforge/work/fontforge-2.0.20170731/config.log
> Warning: The following existing files were hidden from the build system
> by trace mode:
>  /opt/local/bin/pkg-config
>  /opt/local/bin/potrace
>  /opt/local/bin/update-desktop-database
>  /opt/local/bin/wget
>  /var/db/timezone/zoneinfo/America/Toronto
> Error: Failed to configure fontforge: configure failure: command
> execution failed
> Error: See
> /opt/local/var/macports/logs/_Users_kct_data_work_ports_graphics_fontforge/fontforge/main.log
> for details.
> Error: Follow https://guide.macports.org/#project.tickets to report a bug.
> Error: Processing of port fontforge failed
> 
> In the config.log I can see this:
> 
> configure:20386: checking for zlib.h
> configure:20386: result: yes
> configure:20404: checking for GLIB
> configure:20472: result: no
> configure:20474: error: in
> `/opt/local/var/macports/build/_Users_kct_data_work_ports_graphics_fontforge/fontforge/work/fontforge-2.0.20170731':
> configure:20476: error: The pkg-config script could not be found or is
> too old.  Make sure it
> is in your PATH or set the PKG_CONFIG environment variable to the full
> path to pkg-config.
> 
> Alternatively, you may set the environment variables GLIB_CFLAGS
> and GLIB_LIBS to avoid the need to call pkg-config.
> See the pkg-config man page for more details.
> 
> To get pkg-config, see .
> See `config.log' for more details
> 
> Hmm, so the trace mode hides /opt/local/bin/pkg-config, but then
> complains that pkg-config is too old.
> 
> What? Really? Hmmm. Double Hmmm.

Nothing hmm. The port doesn't declare a dependency on pkgconfig, therefore 
trace mode hides the pkg-config executable from the build system. The build 
system needs pkg-config however, so it errors. Add a dependency on pkgconfig, 
and anything else it needs. This is one of the primary purposes of trace mode: 
to help you identify dependencies you've forgotten to add.


> Btw, glib is in /opt/local/lib:
> 
> $ ls *glib*
> libglib-2.0.0.dylib libglib-2.0.a   libglib-2.0.dylib

I'm sure it is. But the build probably needs pkg-config to find it there.

Re: Strange behaviour of trace mode in MacPorts 2.4.3 / 10.13

[Ryan Schmidt]

On Apr 29, 2018, at 20:53, Ken Cunningham wrote:

> We should probably just make pkg-config a default dependency for _every_ 
> build and save everyone a pile of heartburn.

No, obviously not. Declare a dependency on pkg-config when pkg-config is 
required. Simple.

Re: [macports-ports] 02/02: OpenSceneGraph-devel: update to version 3.7.0 git master as of 20180427

[Ryan Schmidt]

On Apr 29, 2018, at 18:21, David B. Evans wrote:

> David B. Evans (dbevans) pushed a commit to branch master
> in repository macports-ports.
> 
> 
> https://github.com/macports/macports-ports/commit/513f00900b7bf397b5d8206ca676481c09f9d84b
> 
> commit 513f00900b7bf397b5d8206ca676481c09f9d84b
> 
> Author: David B. Evans
> AuthorDate: Sat Apr 28 17:39:39 2018 -0700
> 
> 
> OpenSceneGraph-devel: update to version 3.7.0 git master as of 20180427


> +livecheck.type  none

The livecheck seems to work fine. Why disable it?

Re: Binary packages not rebuilding against updated libraries

[Ryan Schmidt]

On Apr 26, 2018, at 10:16, Ryan Schmidt wrote:

>> Not quite. I'm noting that the package version isn't a reliable
>> indication of the ABI version, and neither (sadly, see the current
>> protobuf issues and the issues with LibreSSL) is the library dylib
>> name. Thus I'm proposing to have an internal ABI revision number that
>> we can use for deciding whether dependents need a rebuild.
> 
> I haven't followed the protobuf issue closely enough to be able to comment on 
> it here. If they use the same install_name for incompatible versions of their 
> library, their development process is erroneous.

Now that I've taken a quick look at it, protobuf3-cpp provides 
libprotobuf.15.dylib while protobuf-cpp provides libprotobuf.9.dylib. Since 
they are different major versions of the software, their dylib name and 
therefore install_name are different. This seems perfectly normal and expected 
to me.