Re: port -v checksum

[Ryan Schmidt]

On Feb 6, 2017, at 15:11, John Patrick wrote:

> should 'port -v checksum' check all checksum's listed?
> 
> just wondering as about to upgrade a port version and it complained
> about the rmd160, I updated rmd160 with the new checksum but not the
> sha512
> 
> if their an option to force it to check all checksum's listed to I
> know the Portfile is valid for the new version?

"port checksum" checks all checksum types MacPorts knows about. It knows about 
md5 sha1 rmd160 sha256. It does not know about sha512.

Re: KDE4 ports not built on Sierra buildbot?

[Ryan Schmidt]

On Feb 6, 2017, at 17:29, Marko Käning wrote:
> 
> Hi Ryan,
> 
>> On 22 Dec 2016, at 17:07 , Ryan Schmidt <ryandes...@macports.org> wrote:
>> 
>> Ok but maybe wait until I've deployed a change to the master.cfg that might 
>> help performance.
> 
> have you done that change’s deployment in the meantime?

Yes, whatever change I was talking about was deployed. 

Re: port -v checksum

[Ryan Schmidt]

On Feb 7, 2017, at 02:07, Joshua Root wrote:

> On 2017-2-7 08:11 , John Patrick wrote:
>> should 'port -v checksum' check all checksum's listed?
>> 
>> just wondering as about to upgrade a port version and it complained
>> about the rmd160, I updated rmd160 with the new checksum but not the
>> sha512
>> 
>> if their an option to force it to check all checksum's listed to I
>> know the Portfile is valid for the new version?
> 
> 'port checksum' should definitely always check all the checksums listed in 
> the Portfile and fail if any of them don't match those of the distfile. It 
> will additionally compute rmd160 and sha256 if those are not listed when it 
> fails, so you can easily add them.
> 
> As Ryan mentioned, sha512 is not currently supported. If port doesn't 
> complain when you use it, it probably should.

Yes, there are a couple ports that already have sha512 checksums listed -- 
apache-ant and jumpcut -- but MacPorts does not check them.

Re: [macports-ports] 12/13: xcbuild: add new tool for xcode

[Ryan Schmidt]

> On Jan 23, 2017, at 18:08, Sean Farley  wrote:
> 
> Sean Farley (seanfarley) pushed a commit to branch master
> in repository macports-ports.
> 
> 
> https://github.com/macports/macports-ports/commit/ea02c6a2415087a43634f83653532c4aaf346a21
> 
> commit ea02c6a2415087a43634f83653532c4aaf346a21
> 
> Author: Sean Farley 
> AuthorDate: Mon Jan 23 16:04:28 2017 -0800
> 
> 
> xcbuild: add new tool for xcode
> 
> ---
>  devel/xcbuild/Portfile | 61 
> ++
>  1 file changed, 61 insertions(+)
> 
> 
> diff --git a/devel/xcbuild/Portfile b/devel/xcbuild/Portfile
> 
> new file mode 100644
> 
> index 000..958b72a
> 
> --- /dev/null
> 
> +++ b/devel/xcbuild/Portfile
> 
> @@ -0,0 +1,61 @@
> 
> +# -*- coding: utf-8; mode: tcl; tab-width: 4; indent-tabs-mode: nil; 
> c-basic-offset: 4 -*- vim:fenc=utf-8:ft=portfile:et:sw=4:ts=4:sts=4
> 
> +
> 
> +PortSystem  1.0
> 
> +PortGroup   cmake 1.0
> 
> +PortGroup   github 1.0
> 
> +
> 
> +github.setupfacebook xcbuild 0.1.1
> 
> +categories  devel
> 
> +platforms   darwin
> 
> +
> 
> +universal_variant   no
> 
> +license BSD
> 
> +maintainers sean openmaintainer
> 
> +
> 
> +description xcbuild is an Xcode-compatible build tool with the goal 
> of \
> 
> +providing faster builds, better documentation of the 
> build \
> 
> +process and running on multiple platforms
> 
> +long_description${description}
> 
> +
> 
> +# Fetch from git instead of distfile because it needs submodules
> 
> +fetch.type  git
> 
> +
> 
> +depends_lib-append  port:libpng \
> 
> +port:pkgconfig \
> 
> +port:zlib \
> 
> +port:libxml2 \
> 
> +port:cmake \
> 
> +port:ninja
> 

Does xcbuild really use pkgconfig, cmake and ninja at runtime as well? Usually 
they're only build-time dependencies. The cmake portgroup already adds cmake as 
a build-time dependency.


> +post-fetch {
> 
> +system -W "${worksrcpath}" "git submodule update --init"
> 
> +}
> 
> +
> 
> +# use_configure no
> 
> +
> 
> +configure {
> 
> +system -W "${worksrcpath}" "${configure.cmd} -G Ninja ${configure.args} 
> ${worksrcpath}"
> 
> +}
> 
> +
> 
> +build {
> 
> +system -W "${worksrcpath}" "ninja"
> 
> +}
> 
> +
> 
> +destroot {
> 
> +system -W "${worksrcpath}" "DESTDIR=${destroot} ninja install"
> 
> +}

It might be better to get support for ninja into the cmake portgroup, if ninja 
does really provide such great benefits, rather than override the standard 
phases. See https://trac.macports.org/ticket/47127 for that request.



> +post-destroot {
> 
> +move {*}[glob ${destroot}/usr/local/usr/bin/*] ${destroot}${prefix}/bin
> 
> +move {*}[glob ${destroot}/usr/local/usr/lib/*] ${destroot}${prefix}/lib
> 
> +move ${destroot}/usr/local/Library/Xcode ${destroot}${prefix}/Library
> 
> +
> 
> +# these files aren't needed on macos (they are built by the project for
> 
> +# future work on linux)
> 
> +delete ${destroot}${prefix}/bin/PlistBuddy
> 
> +delete ${destroot}${prefix}/bin/lsbom
> 
> +delete ${destroot}${prefix}/bin/plutil
> 
> +delete ${destroot}${prefix}/bin/xcode-select
> 
> +delete ${destroot}${prefix}/bin/xcodebuild
> 
> +delete ${destroot}${prefix}/bin/xcrun
> 
> +}
> 
> 

Re: [macports-ports] branch master updated: emacs: Rev-bump due to imagemagick changes

[Ryan Schmidt]

> On Jan 23, 2017, at 21:05, Jeremy Huddleston Sequoia  
> wrote:
> 
> Jeremy Huddleston Sequoia (jeremyhu) pushed a commit to branch master
> in repository macports-ports.
> 
> 
> https://github.com/macports/macports-ports/commit/b45c6c288b90421df0407b17a5885033bfb4efdd
> 
> The following commit(s) were added to refs/heads/master by this push:
> 
>  new b45c6c2  emacs: Rev-bump due to imagemagick changes
> 
> b45c6c2 is described below
> 
> 
> commit b45c6c288b90421df0407b17a5885033bfb4efdd
> 
> Author: Jeremy Huddleston Sequoia 
> AuthorDate: Mon Jan 23 19:05:04 2017 -0800
> 
> 
> emacs: Rev-bump due to imagemagick changes
> 
> 
> 
> Signed-off-by: Jeremy Huddleston Sequoia 
> 
> ---
>  editors/emacs/Portfile | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> 
> diff --git a/editors/emacs/Portfile b/editors/emacs/Portfile
> 
> index 09bb1fb..14d5a1c 100644
> 
> --- a/editors/emacs/Portfile
> 
> +++ b/editors/emacs/Portfile
> 
> @@ -37,7 +37,7 @@ subport emacs-app-devel {
> 
>  
>  if {$subport eq $name || $subport eq "emacs-app"} {
>  version 25.1
> 
> -revision2
> 
> +revision3
> 
>  
>  checksums   rmd160  d29ddba846024c7df3e1dc02ac32690f3650e7b9 \
>  sha256  
> 763344b90db4d40e9fe90c5d14748a9dbd201ce544e2cf0835ab48a0aa4a1c67
> 
> @@ -48,7 +48,7 @@ if {$subport eq $name || $subport eq "emacs-app"} {
> 
>  
>  if {$subport eq "emacs-devel" || $subport eq "emacs-app-devel"} {
>  version 20161031
> 
> -revision2
> 
> +revision3

I didn't include that in 
https://github.com/macports/macports-ports/commit/f8d86e8444b1c125ca3e3724deabb0d51021163c
 because emacs doesn't actually use ImageMagick; see 
https://trac.macports.org/ticket/53315.

Re: [macports-ports] branch master updated: arc: update to 5.21p

[Ryan Schmidt]

On Jan 26, 2017, at 09:03, Kurt Hindenburg  wrote:
> 
> Kurt Hindenburg (kurthindenburg) pushed a commit to branch master
> in repository macports-ports.
> 
> 
> https://github.com/macports/macports-ports/commit/31df8bb6a24ffa67515c5e07d20e185c73b1f855
> 
> The following commit(s) were added to refs/heads/master by this push:
> 
>  new 31df8bb  arc: update to 5.21p
> 
> 31df8bb is described below
> 
> 
> commit 31df8bb6a24ffa67515c5e07d20e185c73b1f855
> 
> Author: Kurt Hindenburg 
> AuthorDate: Thu Jan 26 10:03:13 2017 -0500
> 
> 
> arc: update to 5.21p
> 
> 
> 
> add Debian patches - maintainer timeout
> 
> 
> 
> closes https://trac.macports.org/ticket/53116
> 
> ---
>  archivers/arc/Portfile | 32 +++-
>  archivers/arc/files/patch-Makefile | 15 
>  archivers/arc/files/patch-Makefile.diff| 51 
> ++
>  archivers/arc/files/patch-gcc-warnings.diff| 44 ++
>  archivers/arc/files/patch-man-spelling.diff| 17 +
>  archivers/arc/files/patch-manpage-section.diff | 24 
>  6 files changed, 150 insertions(+), 33 deletions(-)
> 
> 
> diff --git a/archivers/arc/Portfile b/archivers/arc/Portfile
> 
> index 1244222..10308fe 100644
> 
> --- a/archivers/arc/Portfile
> 
> +++ b/archivers/arc/Portfile
> 
> @@ -3,8 +3,7 @@
> 
>  PortSystem  1.0
>  
>  namearc
> 
> -version 5.21o
> 
> -revision1
> 
> +version 5.21p
> 
>  categories  archivers sysutils
>  license GPL-2
>  description create and extract files from dos .arc archives
> 
> @@ -12,28 +11,25 @@ maintainers crazic.ru:jc
> 
>  platforms   darwin
>  long_description${description}
>  homepagehttp://arc.sourceforge.net/
> 
> -master_sitessourceforge
> 
> -extract.suffix  .tgz
> 
> +master_sitessourceforge:project/${name}/${name}/${name}-${version}
> 
>  
> 
> -checksums   md5 3b30c739b42b2fe8ac4ec0a05f34f284 \
> 
> -sha1 4b803eae04976072fae88d4dbfc4b3e45796f8f3 \
> 
> -rmd160 2897f62452f59efcb757cd5447d6d330df0cfdd1
> 
> +checksums   rmd160  c6a97105ab26cf1d2b6ad45d528894628cff0586 \
> 
> +sha256  
> eacf870a245f155a4ba8c6f8e0fbb2e8a267aafa157f56ba7a8cb1d74fd8b5a1
> 
>  
> 
> -patchfiles  patch-Makefile patch-marc.c
> 
> +patchfiles  patch-gcc-warnings.diff \
> 
> +patch-Makefile.diff \
> 
> +patch-man-spelling.diff \
> 
> +patch-manpage-section.diff \
> 
> +patch-marc.c
> 
>  
>  use_configure   no
>  
> 
> -set CFLAGS  ${configure.cflags}
> 
> +build.env-appendCC=${configure.cc} \
> 
> +CFLAGS='${configure.cflags} [get_canonical_archflags 
> cc]' \
> 
> +OPT='${configure.cflags} [get_canonical_archflags cc]' \
> 
> +LDFLAGS='${configure.ldflags} [get_canonical_archflags 
> ld]' \
> 
> +PREFIX='${prefix}'
> 
>  
> 
> -variant universal {
> 
> -set CFLAGS  "${CFLAGS} ${configure.universal_cflags}"
> 
> -}
> 
> -if {![variant_isset universal]} {
> 
> -set CFLAGS  "${CFLAGS} ${configure.cc_archflags}"
> 
> -}


This deleted the universal variant. Can it be reinstated?

Re: [macports-ports] branch master updated (f548f90 -> f3225e3)

[Ryan Schmidt]

> On Jan 27, 2017, at 14:04, tobypeterson 
>  wrote:
> 
> tobypeterson pushed a change to branch master
> in repository macports-ports.
> 
>from f548f90  zsh-completions: update to 0.22.0
> new 917a557  trac-53177 activator submission
> new ed8f58f  trac-53177 change maintainer
> new 84a8f2a  trac-53177 changes based upon feedback from @mojca
> new f3225e3  trac-53177 changes based upon feedback from @mojca
> 
> The 4 revisions listed above as "new" are entirely new to this
> repository and will be described in separate emails.  The revisions
> listed as "add" were already present in the repository and have only
> been added to this reference.
> 
> 
> Summary of changes:
> java/typesafe-activator/Portfile | 59 
> 1 file changed, 59 insertions(+)
> create mode 100644 java/typesafe-activator/Portfile
> 


All of this should have been squashed into a single commit, with a better 
commit message, prior to merging to master.

Re: [macports-ports] 01/02: libevent: update to version 2.1.8

[Ryan Schmidt]

> On Jan 27, 2017, at 13:24, Marius Schamschula  wrote:
> 
> Marius Schamschula (Schamschula) pushed a commit to branch master
> in repository macports-ports.
> 
> 
> https://github.com/macports/macports-ports/commit/f674c03eb39d77ac7d3a38b96f2cd2acbf2fd041
> 
> commit f674c03eb39d77ac7d3a38b96f2cd2acbf2fd041
> 
> Author: Marius Schamschula 
> AuthorDate: Fri Jan 27 13:17:27 2017 -0600
> 
> 
> libevent: update to version 2.1.8
> 
> ---
>  devel/libevent/Portfile | 13 -
>  1 file changed, 4 insertions(+), 9 deletions(-)
> 
> 
> diff --git a/devel/libevent/Portfile b/devel/libevent/Portfile
> 
> index db7ef8f..ce2cf01 100644
> 
> --- a/devel/libevent/Portfile
> 
> +++ b/devel/libevent/Portfile
> 
> @@ -3,9 +3,8 @@
> 
>  PortSystem  1.0
>  PortGroup   github 1.0
>  
> 
> -github.setuplibevent libevent 2.0.22-stable release-
> 
> +github.setuplibevent libevent 2.1.8-stable release-
> 
>  version [lindex [split ${version} -] 0]
> 
> -revision3
> 
>  categories  devel
>  platforms   darwin
>  license BSD
> 
> @@ -20,17 +19,13 @@ long_descriptionThe libevent API provides a mechanism 
> to execute \
> 
>  callbacks due to signals or regular timeouts.
>  
>  homepagehttp://libevent.org
> 
> -github.tarball_from releases
> 
>  
> 
> -checksums   rmd160  6a7e8e3ebcfd2227fa807a604b5c773c90c8b8cc \
> 
> -sha256  
> 71c2c49f0adadacfdbe6332a372c38cf9c8b7895bb73dabeaa53cdcc1d4e1fa3
> 
> +checksums   rmd160  f23ad93d555089535085c99f3f8cbb9ebae4fd53 \
> 
> +sha256  
> d53e88f2b31fbccab93f6b1e54fe7f4c1d536b6d8250c95cd42dbc14f958baeb
> 
>  
>  depends_lib path:lib/libssl.dylib:openssl
>  
> 
> -# Don't accidentally create flat-namespace dylibs on Yosemite (#44596).
> 
> -patchfiles  yosemite-libtool.patch
> 
> -
> 
> -patchfiles-append   patch-sierra-kqueue.diff
> 
> +use_autoreconf  yes

Why do you no longer use the release download? It's inconvenient to change it 
now, but for future reference, using the release download is preferred. It 
avoids the need to run autoreconf.

Re: [macports-ports] branch master updated: arc: re-add universal variant

[Ryan Schmidt]

> On Jan 26, 2017, at 21:09, Kurt Hindenburg  wrote:
> 
> Kurt Hindenburg (kurthindenburg) pushed a commit to branch master
> in repository macports-ports.
> 
> 
> https://github.com/macports/macports-ports/commit/d108da56e7944b3d5145cda9d004f79ec92e992d
> 
> The following commit(s) were added to refs/heads/master by this push:
> 
>  new d108da5  arc: re-add universal variant
> 
> d108da5 is described below
> 
> 
> commit d108da56e7944b3d5145cda9d004f79ec92e992d
> 
> Author: Kurt Hindenburg 
> AuthorDate: Thu Jan 26 22:09:04 2017 -0500
> 
> 
> arc: re-add universal variant
> 
> ---
>  archivers/arc/Portfile | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> 
> diff --git a/archivers/arc/Portfile b/archivers/arc/Portfile
> 
> index 10308fe..870c3a0 100644
> 
> --- a/archivers/arc/Portfile
> 
> +++ b/archivers/arc/Portfile
> 
> @@ -24,12 +24,12 @@ patchfiles  patch-gcc-warnings.diff \
> 
>  
>  use_configure   no
>  
> 
> -build.env-appendCC=${configure.cc} \
> 
> +build.env-appendCC="${configure.cc} [get_canonical_archflags cc]" \
> 
>  CFLAGS='${configure.cflags} [get_canonical_archflags 
> cc]' \
> 
> -OPT='${configure.cflags} [get_canonical_archflags cc]' \
> 
>  LDFLAGS='${configure.ldflags} [get_canonical_archflags 
> ld]' \
>  PREFIX='${prefix}'
>  
> 
> +variant universal {}

This builds non-universally. The universal variant must be declared before the 
get_canonical_archflags procedure is called for the first time, otherwise 
get_canonical_archflags doesn't know there is a universal variant.

Re: [macports-ports] branch master updated: emacs: Rev-bump due to imagemagick changes

[Ryan Schmidt]

> On Jan 24, 2017, at 15:20, Jeremy Huddleston Sequoia <jerem...@macports.org> 
> wrote:
> 
> 
>> On Jan 24, 2017, at 01:32, Ryan Schmidt <ryandes...@macports.org> wrote:
>> 
>> 
>>> On Jan 23, 2017, at 21:05, Jeremy Huddleston Sequoia 
>>> <jerem...@macports.org> wrote:
>>> commit b45c6c288b90421df0407b17a5885033bfb4efdd
>>> 
>>> Author: Jeremy Huddleston Sequoia <jerem...@macports.org>
>>> AuthorDate: Mon Jan 23 19:05:04 2017 -0800
>>> 
>>> 
>>> emacs: Rev-bump due to imagemagick changes
>>> 
>> I didn't include that in 
>> https://github.com/macports/macports-ports/commit/f8d86e8444b1c125ca3e3724deabb0d51021163c
>>  because emacs doesn't actually use ImageMagick; see 
>> https://trac.macports.org/ticket/53315.
> 
> If by "doesn't actually use" you mean that it's linking the library without 
> any purpose (no symbol linkage, no initializers, etc), then that should 
> certainly be fixed, but it would still require a revbump (unless the link is 
> weak).
> 
> In this particular case, it does indeed look like emacs is making use of 
> ImageMagick:
> 
> ~ $ nm -m /opt/local/bin/emacs | grep libMagick
>   (undefined) external _AcquireExceptionInfo (from 
> libMagickCore-6.Q16)
>   (undefined) external _CloneMagickWand (from libMagickWand-6.Q16)
>   (undefined) external _DestroyExceptionInfo (from 
> libMagickCore-6.Q16)
>   (undefined) external _DestroyMagickWand (from 
> libMagickWand-6.Q16)
>   (undefined) external _DestroyPixelIterator (from 
> libMagickWand-6.Q16)
>   (undefined) external _DestroyPixelWand (from 
> libMagickWand-6.Q16)
>   (undefined) external _DestroyString (from libMagickCore-6.Q16)
>   (undefined) external _GetMagickList (from libMagickCore-6.Q16)
>   (undefined) external _MagickCropImage (from libMagickWand-6.Q16)
>   (undefined) external _MagickExportImagePixels (from 
> libMagickWand-6.Q16)
>   (undefined) external _MagickGetException (from 
> libMagickWand-6.Q16)
>   (undefined) external _MagickGetImage (from libMagickWand-6.Q16)
>   (undefined) external _MagickGetImageDelay (from 
> libMagickWand-6.Q16)
>   (undefined) external _MagickGetImageDispose (from 
> libMagickWand-6.Q16)
>   (undefined) external _MagickGetImageHeight (from 
> libMagickWand-6.Q16)
>   (undefined) external _MagickGetImagePage (from 
> libMagickWand-6.Q16)
>   (undefined) external _MagickGetImageSignature (from 
> libMagickWand-6.Q16)
>   (undefined) external _MagickGetImageWidth (from 
> libMagickWand-6.Q16)
>   (undefined) external _MagickGetNumberImages (from 
> libMagickWand-6.Q16)
>   (undefined) external _MagickMergeImageLayers (from 
> libMagickWand-6.Q16)
>   (undefined) external _MagickReadImage (from libMagickWand-6.Q16)
>   (undefined) external _MagickReadImageBlob (from 
> libMagickWand-6.Q16)
>   (undefined) external _MagickRelinquishMemory (from 
> libMagickWand-6.Q16)
>   (undefined) external _MagickRotateImage (from 
> libMagickWand-6.Q16)
>   (undefined) external _MagickScaleImage (from 
> libMagickWand-6.Q16)
>   (undefined) external _MagickSetFilename (from 
> libMagickWand-6.Q16)
>   (undefined) external _MagickSetImageBackgroundColor (from 
> libMagickWand-6.Q16)
>   (undefined) external _MagickSetIteratorIndex (from 
> libMagickWand-6.Q16)
>   (undefined) external _MagickWandGenesis (from 
> libMagickWand-6.Q16)
>   (undefined) external _MagickWandTerminus (from 
> libMagickWand-6.Q16)
>   (undefined) external _NewMagickWand (from libMagickWand-6.Q16)
>   (undefined) external _NewPixelIterator (from 
> libMagickWand-6.Q16)
>   (undefined) external _NewPixelWand (from libMagickWand-6.Q16)
>   (undefined) external _PixelGetAlpha (from libMagickWand-6.Q16)
>   (undefined) external _PixelGetMagickColor (from 
> libMagickWand-6.Q16)
>   (undefined) external _PixelGetNextIteratorRow (from 
> libMagickWand-6.Q16)
>   (undefined) external _PixelSetBlue (from libMagickWand-6.Q16)
>   (undefined) external _PixelSetGreen (from libMagickWand-6.Q16)
>   (undefined) external _PixelSetIteratorRow (from 
> libMagickWand-6.Q16)
>   (undefined) external _PixelSetMagickColor (from 
> libMagickWand-6.Q16)
>   (undefined) external _PixelSetRed (from libMagickWand-6.Q16)
>   (undefined) external _PixelSyncIterator (from 
> libMagickWand-6.Q16)
> 
> --Jeremy
> 

No, I meant the configure script determined that ImageMagick was not installed 
and emacs therefore wasn't using ImageMagick in any way at all. Looks like it's 
different on your system than on mine.

Re: PortFile command

[Ryan Schmidt]

> On Jan 26, 2017, at 05:33, René J.V. Bertin  wrote:
> 
> Hello,
> 
> In the past I've simplified the development of complex Portfiles by splitting 
> them over at least 2 Portfiles, loaded with Tcl's `source` command. The 
> latest example would be the ffmpeg-VLC subport
> 
> I think the maintenance of quite a few of the more complex ports with 
> multiple subports could benefit from it: the Qt5 ports, my KF5-Frameworks 
> port, possibly the clang/llvm ports etc.
> 
> The only real obstacle is the fact that only a single file, "Portfile" is 
> copied into the registry, but a quick look suggests that could be solved by 
> loading delegate Portfiles through a `proc PortFile` (clone of the PortGroup 
> proc) that sets PortInfo(portfiles) and a corresponding change in 
> portinstall.tcl . I for one could live with a situation where `port edit foo` 
> opens just the toplevel Portfile.
> 
> Just an idea... one that I think must have been considered before already?
> 
> R.


I don't think anyone's ever suggested before that include files would be 
beneficial for portfile development, except for portgroups which are already 
handled.

Re: [macports-ports] branch master updated: upx: update to 3.92

[Ryan Schmidt]

> On Jan 25, 2017, at 16:46, Zero King  wrote:
> 
> tobypeterson pushed a commit to branch master
> in repository macports-ports.
> 
> 
> https://github.com/macports/macports-ports/commit/8ece104001dabd2c92e633d74963c72c0fe8cb28
> 
> The following commit(s) were added to refs/heads/master by this push:
> 
>  new 8ece104  upx: update to 3.92
> 
> 8ece104 is described below
> 
> 
> commit 8ece104001dabd2c92e633d74963c72c0fe8cb28
> 
> Author: Zero King 
> AuthorDate: Wed Jan 25 14:04:09 2017 +
> 
> 
> upx: update to 3.92
> 
> 
> 
> Fixes: https://trac.macports.org/ticket/51856
> 
> Fixes: https://trac.macports.org/ticket/52140
> 
> ---
>  archivers/upx/Portfile | 57 
> ++
>  1 file changed, 16 insertions(+), 41 deletions(-)
> 
> 
> diff --git a/archivers/upx/Portfile b/archivers/upx/Portfile
> 
> index 2bf82bf..396a230 100644
> 
> --- a/archivers/upx/Portfile
> 
> +++ b/archivers/upx/Portfile
> 
> @@ -1,46 +1,36 @@
> 
>  # -*- 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
> 
> +PortSystem   1.0
> 
> +PortGroupgithub 1.0
> 
> +
> 
> +github.setup upx upx 3.92 v
> 
> +github.tarball_from releases
> 
>  
>  name upx
> 

The name property should be removed; the github.setup line sets it for you.


> -variant universal {}

This removed the universal variant. The tickets referenced in the commit 
message don't discuss that. Is a universal build no longer possible?

Re: build progress bar

[Ryan Schmidt]

On Feb 18, 2017, at 19:46, René J.V. Bertin <rjvber...@gmail.com> wrote:
> 
>> On Saturday February 18 2017 17:57:04 Ryan Schmidt wrote:
>> 
>> The muniversal portgroup used to say "building for i386", "building for 
>> x86_64", but this was removed, perhaps because it was thought to be 
>> confusing that some ports were printing this information and others weren't.
> 
> I never saw that, but that's exactly what it prints for me now.

I... remembered that being removed. But it hasn't been. Huh. 


>> Nobody's going to remember to update that number when the update a port to a 
>> new version number.
> 
> Maybe, but you can say the same thing about updating the database.

The idea was that the buildbot would update the database automatically after 
each build. 

Re: build progress bar

[Ryan Schmidt]

On Feb 18, 2017, at 17:55, René J.V. Bertin wrote:

> On Saturday February 18 2017 17:27:45 Ryan Schmidt wrote:
> 
>> The problem is that it only applies to cmake-generated makefiles and certain 
>> other one-off makefiles. But maybe a progress bar for some builds is better 
>> than no build progress bar ever.
> 
> Yeah. It might work for any project that uses ninja, too.
> 
>> For example, a port building with cmake and muniversal will go from 0% to 
>> 100% for the first architecture, then go from 0% to 100% for the second 
>> architecture; this detail should be hidden from the user behind a single 
>> combined progress bar.
> 
> Or the muniversal portgroup could indicate what architecture it's building 
> for. I've already hacked my copy to do that because it also provides a 
> periodic wake-up call to ask myself if I really need that port installed 
> +universal. That's a different issue of course.

The muniversal portgroup used to say "building for i386", "building for 
x86_64", but this was removed, perhaps because it was thought to be confusing 
that some ports were printing this information and others weren't.


>> The ticket for this issue is https://trac.macports.org/ticket/15939 . 
>> Clemens had some thoughts there for how it might be done for other ports 
>> whose build systems don't provide this information, but it would involve 
>> maintaining an online database.
> 
> Ah yes. In my memory someone suggested using the number of files, but the 
> number of output lines would be a reasonable indicator if you know how many 
> there are.
> 
> If we go for an approach that relies on ports (or portgroups) providing the 
> required information it should also be possible to provide the number of 
> expected lines that way, removing the need for an additional online database. 
> Something like
> 
> {{{
> build.progress.expected_lines 1000
> }}}
> 
> should be all that's needed to activate a progressbar mechanism based on this 
> generic principle.

Nobody's going to remember to update that number when the update a port to a 
new version number.

Re: build progress bar

[Ryan Schmidt]

> On Feb 18, 2017, at 12:45, René J.V. Bertin  wrote:
> 
> Hi,
> 
> I've been tinkering a bit with a build progress bar feature that uses the 
> information certain build systems provide.
> CMake for instance generates Makefiles that print regular "[xyz%] " tags in 
> their regular output which can be processed with a simple scan in ui_message 
> (macports.tcl). One should be able to use 
> `macports::ui_options(progress_generic)` from there, but that feature would 
> have to be initialised. I've failed to do that from portbuild.tcl as well as 
> from `command_exec` in portutil.tcl .
> 
> What have I been missing to access that variable from those places?
> 
> 
> On a more general note I was thinking of supporting this kind of progress 
> reporting via a callback hook which can then be set by (say) the CMake 
> portgroup. I'd love to have progress feedback when not doing a verbose build 
> but not enough to try and hack something generic together that works across 
> most build systems even if they don't provide progress (percentage or "X of 
> of Y") info.
> IIRC we discussed a feature like this a while back; has anyone been giving it 
> any thought?
> 
> R.

Thanks for working on this.

The problem is that it only applies to cmake-generated makefiles and certain 
other one-off makefiles. But maybe a progress bar for some builds is better 
than no build progress bar ever.

Providing a way for portfiles and portgroups to indicate what, if any, regexp 
matches progress information in the build output is probably a good way to go. 
There is an additional complication that some types of builds may need special 
handling. For example, a port building with cmake and muniversal will go from 
0% to 100% for the first architecture, then go from 0% to 100% for the second 
architecture; this detail should be hidden from the user behind a single 
combined progress bar.

The ticket for this issue is https://trac.macports.org/ticket/15939 . Clemens 
had some thoughts there for how it might be done for other ports whose build 
systems don't provide this information, but it would involve maintaining an 
online database.

Re: [macports-ports] 01/03: qt5*: add openssl variant

[Ryan Schmidt]

> On Feb 17, 2017, at 07:23, Marcus Calhoun-Lopez  wrote:
> 
> MarcusCalhoun-Lopez pushed a commit to branch master
> in repository macports-ports.
> 
> 
> https://github.com/macports/macports-ports/commit/c7a773046fd088bdfff557277384b28099f94406
> 
> commit c7a773046fd088bdfff557277384b28099f94406
> 
> Author: Marcus Calhoun-Lopez 
> AuthorDate: Fri Feb 17 05:46:51 2017 -0700
> 
> qt5*: add openssl variant
> 
> Some users might not want to use OpenSSL because
> of licensing issues with GPL.
> See 
> https://lists.macports.org/pipermail/macports-dev/2017-January/thread.html#35234
> See https://trac.macports.org/ticket/53369
> See http://doc.qt.io/qt-5/qtnetwork-index.html#licenses-and-attributions
> 
> Some users may have LibreSSL installed, which conflicts with OpenSSL
> and is currently incompatible with Qt.
> See https://trac.macports.org/ticket/51358


> +variant openssl description {Use OpenSSL instead of Secure 
> Transport} {
> +configure.args-delete -securetransport -no-openssl
> +configure.args-append -openssl-linked
> +depends_lib-append path:lib/libssl.dylib:openssl
> +# see https://trac.macports.org/ticket/51358
> +conflicts-append libressl libressl-devel
> +}
> +default_variants-append +openssl

Hmm. The "conflicts" keyword is for activation-time conflicts. For example, 
glib2 and glib2-devel install (different versions of) the same files to the 
same locations, so glib2 says "conflicts glib2-devel" and glib2-devel says 
"conflicts glib2".

The "conflicts_build" keyword (from the conflicts_build 1.0 portgroup) is for 
build-time conflicts. For example, magic fails to build if gnome-keyring is 
active, so it says "conflicts_build gnome-keyring".

In this case, you have a dependency on "path:lib/libssl.dylib:openssl" which 
means you can work with any port that provides lib/libssl.dylib. But this 
appears not to be true. If you require openssl, and don't work with libressl, 
then you should just declare the dependency as "port:openssl" and remove the 
conflicts keyword.

IMHO the real problem is that libressl installs files to the same locations as 
openssl and claims to be a drop-in replacement for openssl, but isn't. libressl 
should be changed to install to different locations, should not conflict with 
openssl, and any port that links with openssl should be changed to have 
variants for openssl and libressl. But this is a lot of work.

Re: [macports-ports] branch master updated: darktable: update to 2.2.3

[Ryan Schmidt]

> On Feb 23, 2017, at 10:48, Craig Treleaven  wrote:
> 
> Craig Treleaven (ctreleaven) pushed a commit to branch master
> in repository macports-ports.
> 
> 
> https://github.com/macports/macports-ports/commit/4606c62b254f469098fe72805b99c13e81ec1839
> 
> The following commit(s) were added to refs/heads/master by this push:
> 
>  new 4606c62  darktable:  update to 2.2.3
> 
> 4606c62 is described below
> 
> 
> commit 4606c62b254f469098fe72805b99c13e81ec1839
> 
> Author: Craig Treleaven 
> AuthorDate: Thu Feb 23 11:42:25 2017 -0500
> 
> 
> darktable:  update to 2.2.3
> 
> 
> 
> Major reworking of darktable port.  Project is now hosted on github, 
> significant
> 
> changes to deps (including update to gtk3), only builds with quartz.
> 
> 
> 
> Minor functional testing so far other than to launch and display jpegs.
> 
> 
> 
> See https://trac.macports.org/ticket/43286
> 
> Believed to:
> 
> Fix https://trac.macports.org/ticket/43199
> 
> Fix https://trac.macports.org/ticket/47226
> 
> Fix https://trac.macports.org/ticket/51447


> +github.setupdarktable-org darktable 2.2.3 release-
> +# distfile is actually gzip but has xz extension?
> +distfiles   ${name}-${version}.tar.xz
> +checksums   rmd160  05afa3d4b7778ee1d7d2a04cf2fb87487f5650d8 \
> +sha256  
> 60fb250bd78ea45f57476807bb31d141240292e03b73cb8b3417a8148cc16d7c


No.

The darktable-2.2.3.tar.xz release tarball is xz-compressed.

But you haven't instructed the portfile to download that file; you're using the 
defaults of the github portgroup, which is to download the 
automatically-generated gz-compressed tarball. GitHub lets you specify *any* 
filename when requesting that tarball, which is why specifying an xz filename 
"works" but gives you a gz file, and which is why by custom we don't specify a 
filename and instead let the defaults of the github portgroup apply.

To use a release download instead, set "github.tarball_from releases". And 
remove the distfiles line and set "use_xz yes". And update the checksums. And 
use the stealth update recipe.

Re: [macports-ports] branch master updated: hackrf: move current to devel & add release.

[Ryan Schmidt]

> On Feb 23, 2017, at 07:25, Michael Dickens  wrote:
> 
> Michael Dickens (michaelld) pushed a commit to branch master
> in repository macports-ports.
> 
> 
> https://github.com/macports/macports-ports/commit/b566db2c16035d568261b863c73b0fb795aa7eab
> 
> The following commit(s) were added to refs/heads/master by this push:
> 
>  new b566db2  hackrf: move current to devel & add release.
> 
> b566db2 is described below
> 
> 
> commit b566db2c16035d568261b863c73b0fb795aa7eab
> 
> Author: Michael Dickens 
> AuthorDate: Thu Feb 23 08:25:49 2017 -0500
> 
> 
> hackrf: move current to devel & add release.
> 
> 
> 
> Addresses https://github.com/macports/macports-ports/pull/316 .


> +github.setupmossmann hackrf v2017.02.1
> +version 2017.02.1


This should probably be

github.setupmossmann hackrf 2017.02.1 v

and no version line.

Resolving pull request conflicts

[Ryan Schmidt]

Browsing pull requests, I found this one:

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

Another commit had happened to that port in the mean time, so the PR now had 
conflicts and could not be applied as-is. GitHub invited me to edit the file on 
the web to resolve the conflict, so I did. I was then asked by the PR author 
not to do that. Can someone explain why resolving the conflict was bad?

Re: [macports-ports] branch master updated: aqua/x2goclient: update to 4.1.0.0.

[Ryan Schmidt]

> On Feb 23, 2017, at 02:56, Mihai Moldovan  wrote:
> 
> Mihai Moldovan (Ionic) pushed a commit to branch master
> in repository macports-ports.
> 
> 
> https://github.com/macports/macports-ports/commit/5ef7d72e34586081b904c15830ec70741f758566
> 
> The following commit(s) were added to refs/heads/master by this push:
> 
>  new 5ef7d72  aqua/x2goclient: update to 4.1.0.0.
> 
> 5ef7d72 is described below
> 
> 
> commit 5ef7d72e34586081b904c15830ec70741f758566
> 
> Author: Mihai Moldovan 
> AuthorDate: Thu Feb 23 09:54:32 2017 +0100
> 
> aqua/x2goclient: update to 4.1.0.0.
> 
> Fix startup failure and non-default prefixes via patches/reinplaces.


> +post-patch {
> +foreach filename [list "src/onmainwindow.cpp" "src/pulsemanager.cpp"] {
> +reinplace -W "${worksrcpath}" "s#@@PREFIX@@#${prefix}#g" $filename
> +}
> +}

You don't need a foreach loop here. reinplace accepts multiple filenames.


post-patch {
reinplace -W ${worksrcpath}/src "s#@@PREFIX@@#${prefix}#g" onmainwindow.cpp 
pulsemanager.cpp
}

Re: Resolving pull request conflicts

[Ryan Schmidt]

On Feb 23, 2017, at 04:46, Mojca Miklavec <mo...@macports.org> wrote:
> 
> Dear Ryan,
> 
> On 23 February 2017 at 11:19, Ryan Schmidt  wrote:
>> Browsing pull requests, I found this one:
>> 
>> https://github.com/macports/macports-ports/pull/305
>> 
>> Another commit had happened to that port in the mean time, so the PR now had 
>> conflicts and could not be applied as-is. GitHub invited me to edit the file 
>> on the web to resolve the conflict, so I did. I was then asked by the PR 
>> author not to do that. Can someone explain why resolving the conflict was 
>> bad?
> 
> It's not resolving the conflict that's bad.
> 
> I guess it's just that the GitHub's user interface is anything but
> optimal when it comes to certain aspects.
> 
> I'm still confused about what exactly you did to end up in that
> situation (but it's probably more clear to me now that you mentioned
> it; perhaps I should this on some test repository).

GitHub said the pull request had a conflict. (The PR is a version update, but a 
revbump was committed to the port in the meantime.) GitHub said I could resolve 
the conflict on the command line or in a web-based editor. There was a green 
button inviting me to start resolving the conflict on the web. I clicked this 
and was brought to a web-based text editor showing the Portfile in its 
conflicted state. I edited the file, removing the conflict markers and 
incorrect lines. I clicked the button saying I have now resolved the conflicts.


> I agree with Zero King that it makes more sense to keep the branches
> clean.

What does it mean to be "clean"?

Is it better to have a pull request that has conflicts which cannot be merged 
without additional manual work, or one that has had those conflicts resolved?


> If anything it's confusing to see 20 unrelated commits when
> it's about merging some trivial changes in an unrelated file.

I'm not sure what you mean here.


> We kind of decided that we'll try to keep our history linear & clean.

Absolutely the history that appears in master should be "clean", meaning one 
commit per logical change. But it is natural, is it not, that a pull request 
might need refinement before being merged, to address feedback or in this case 
conflicts, and that that refinement would come in the form of additional 
commits? My understanding was that once it was deemed satisfactory such 
multi-commit PRs would be squashed into a single commit before/during merging. 
(The "squash-and-merge" GitHub button that we haven't enabled yet.)


> (I'm sure you still remember Andrea's 300 duplicated commits in a
> failed attempt to do so and probably agree that it makes sense to do
> our best to avoid repeating such type of commits?)

I do remember that occurrence, and not understanding how it happened.


> Ever since I discovered that GitHub won't use my email when I click on
> the merge button in pull requests, I never use the GitHub's GUI to do
> any operations like this one since I never know what it will do behind
> the scene.

I guess I'll just continue not to participate in anything other than the most 
straightforward pull requests for now, since I still find the git command line 
too complicated to understand.


> Here's what I do when I work on Pull Requests.
> 
> 1.) First of all I made sure to add
> 
>[pull]
>rebase = true
> 
> to .git/config just in case that I would forget to call "--rebase"
> when I do "git pull". If that option is missing, one should always try
> to run "git pull origin master --rebase" on the local master branch to
> avoid ending up with weird merges.
> 
> 2.) Here's what I do to fetch the changes locally and push them back:
> 
> # set these three lines manually
> PR_N=123
> PR_USER=some-username
> PR_REMOTEBR=remote-branch-name
> 
> PR_LOCALBR=pr${PR_N}-${PR_USER}-${PR_REMOTEBR}
> 
> git fetch https://github.com/$PR_USER/macports-ports.git $PR_REMOTEBR
> git checkout -b $PR_LOCALBR FETCH_HEAD
> git rebase master
> 
> ## then do whatever "magic" is needed
> ## very often using commands like
> # git rebase -i HEAD~4
> # git commit --amend [--date="..."]
> 
> ## then check with
> # git log --graph
> ## to make sure that the history and commit messages are OK
> 
> # then update the branch in PR first
> # (this is also important to make the PR marked as "merged" rather
> than "closed")
> git push -f https://github.com/$PR_USER/macports-ports.git
> $PR_LOCALBR:$PR_REMOTEBR
> 
> # then check if the PR looks ok on the web just in case
> 
> # and finally push the changes to master
> git push origin $PR_LOCALBR:master
> 
> 
> Maybe some software already does 

Re: GitHub usernames in maintainers field

[Ryan Schmidt]

On Feb 11, 2017, at 13:14, Mojca Miklavec wrote:

> On 11 February 2017 at 20:05, Jeremy Huddleston Sequoia wrote:
>> Do we have a mapping list somewhere, so we can just script this for known 
>> mappings?
> 
> The list should be available on our Trac (at least for those who
> logged in with their github account).

I assumed such a list would only be visible to our Trac sysadmins. Can it be 
seen by anyone logging in to Trac? If so, how?

Re: GitHub usernames in maintainers field

[Ryan Schmidt]

I appreciate that we are making these changes slowly. This gives the buildbot 
time to catch up on other commits.

I don't want to commit all maintainer-to-GitHub changes in one revision and 
then cancel the buildbot build, as we did with the $Id$ removal commit, because 
valuable builds are being done by the buildbot as a result of these commits 
which I want to allow to happen.

The mega $Id$ removal commit also exposed a limitation of the GitHub git-to-svn 
gateway, which we are using on our server in the mprsyncup script. I reported 
the limitation to GitHub and they said they would look into it but I don't know 
if they've fixed it. I believe we can avoid triggering this limitation again by 
not modifying too many files in a single commit. If we hit the limitation 
again, manual intervention is required to throw away the Subversion working 
copy on the server, and then after the new working copy is checked out the 
portindexes get regenerated, which takes hours; I want to avoid going through 
all that hassle ever again.

Re: GitHub usernames in maintainers field

[Ryan Schmidt]

On Feb 11, 2017, at 23:12, Joshua Root wrote:

> On 2017-2-12 12:07 , Ryan Schmidt wrote:
>> The mega $Id$ removal commit also exposed a limitation of the GitHub 
>> git-to-svn gateway, which we are using on our server in the mprsyncup 
>> script. I reported the limitation to GitHub and they said they would look 
>> into it but I don't know if they've fixed it. I believe we can avoid 
>> triggering this limitation again by not modifying too many files in a single 
>> commit. If we hit the limitation again, manual intervention is required to 
>> throw away the Subversion working copy on the server, and then after the new 
>> working copy is checked out the portindexes get regenerated, which takes 
>> hours; I want to avoid going through all that hassle ever again.
> 
> This at least could be avoided by checking out directly from git, I presume?

Right, the mprsyncup script just has a lot of svn specifics in it that we 
haven't tried to eliminate yet so it was easier to use the git-to-svn bridge.

Re: [macports-ports] branch master updated: sqlite3: Fix build failure by using a newer compiler

[Ryan Schmidt]

> On Feb 14, 2017, at 14:48, Jeremy Huddleston Sequoia  
> wrote:
> 
> Jeremy Huddleston Sequoia (jeremyhu) pushed a commit to branch master
> in repository macports-ports.
> 
> 
> https://github.com/macports/macports-ports/commit/bcc939f4f8b71aef04559128504538e1417b6a6f
> 
> The following commit(s) were added to refs/heads/master by this push:
> 
>  new bcc939f  sqlite3: Fix build failure by using a newer compiler
> 
> bcc939f is described below
> 
> 
> commit bcc939f4f8b71aef04559128504538e1417b6a6f
> 
> Author: Jeremy Huddleston Sequoia 
> AuthorDate: Tue Feb 14 12:47:03 2017 -0800
> 
> 
> sqlite3: Fix build failure by using a newer compiler
> 
> 
> 
> Signed-off-by: Jeremy Huddleston Sequoia 
> 
> ---
>  databases/sqlite3/Portfile | 4 
>  1 file changed, 4 insertions(+)
> 
> 
> diff --git a/databases/sqlite3/Portfile b/databases/sqlite3/Portfile
> 
> index 6675dca..3ca3476 100644
> 
> --- a/databases/sqlite3/Portfile
> 
> +++ b/databases/sqlite3/Portfile
> 
> @@ -1,6 +1,7 @@
> 
>  # -*- 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   compiler_blacklist_versions 1.0
> 
>  
>  namesqlite3
>  version 3.17.0
> 
> @@ -32,6 +33,9 @@ checksums   rmd160  
> c198f8c3f91894ba017b7e71a9d6e5c31a9ef12c \
> 
>  depends_lib port:libedit \
>  port:ncurses
>  
> 
> +# clang-602.0.53 fails due to usage of __builtin_add_overflow
> 
> +compiler.blacklist  *gcc-4.2 { clang < 700 }

Can't do this, unfortunately... this introduces a circular dependency. 
clang-X.Y depends on python27, which depends on sqlite3.

Re: [macports-ports] branch master updated: science/ligo-gracedb: update to 1.23

[Ryan Schmidt]

> On Feb 11, 2017, at 14:52, Adam Mercer  wrote:
> 
> Adam Mercer (skymoo) pushed a commit to branch master
> in repository macports-ports.
> 
> 
> https://github.com/macports/macports-ports/commit/e6a419681b3f4a38912ae939784c6bca4fb9c6f7
> 
> The following commit(s) were added to refs/heads/master by this push:
> 
>  new e6a4196  science/ligo-gracedb: update to 1.23
> 
> e6a4196 is described below
> 
> 
> commit e6a419681b3f4a38912ae939784c6bca4fb9c6f7
> 
> Author: Adam Mercer 
> AuthorDate: Sat Feb 11 14:52:23 2017 -0600
> 
> 
> science/ligo-gracedb: update to 1.23


> -maintainers   ram
> +maintainers   ram @skymoo
> 

You need to enclose this in braces, to group them, to indicate that "ram" and 
"@skymoo" are the same person.

maintainers {ram @skymoo}

Re: [macports-ports] branch master updated: fontconfig: support mpkg/mdmg packaging, add postinstall script to initialize/update font cache. Fixes #53350

[Ryan Schmidt]

> On Jan 21, 2017, at 06:46, Marko Käning <mk-macpo...@posteo.net> wrote:
> 
> Hi Ryan,
> 
>> On 20 Jan 2017, at 05:13 , Ryan Schmidt <ryandes...@macports.org> wrote:
>> 
>> Remember that now that we've switched to GitHub, "#53350" refers to *GitHub 
>> pull request* 53350.
> 
> this is why I suggested a pre-commit sanity check of commit messages in 
> 
>https://trac.macports.org/ticket/52763
> 
> I admit that it might not be so easily implementable, but still, for commits 
> like this it seems to make a lot of sense, since you don’t want to mess up a 
> projects’ commit history by filling it with bogus links to “PRs” which are in 
> fact original MacPorts trac ticket references.
> 
> Greets,
> Marko

GitHub doesn't have server-side pre-commit hooks. 

Re: destroot'ing into ${destroot}${prefix}/foo ?

[Ryan Schmidt]

> On Jan 18, 2017, at 04:23, René J.V. Bertin  wrote:
> 
> Hi,
> 
> Is there an existing way to create a kind of nested destroot, where the 
> installed port ends up *unmodified* under say ${prefix}/test?
> 
> Looking at the Portfile guide I think that the only way to accomplish this 
> reliably is in a post-destroot step (a post-post-destroot to be really sure), 
> in which everything under ${destroot} is moved into ${destroot}${prefix}/test 
> ?
> 
> If so, am I right that post-destroot blocks declared in/as `variant foo ... { 
> post-destroot{ } }` will be executed *after* all post-destroot blocks defined 
> in the normal Portfile scope?

I believe you're right that variant code is executed after other code in the 
portfile.

Re: [macports-ports] branch master updated: fontconfig: support mpkg/mdmg packaging, add postinstall script to initialize/update font cache. Fixes #53350

[Ryan Schmidt]

> On Jan 19, 2017, at 12:21, Craig Treleaven  wrote:
> 
> Craig Treleaven (ctreleaven) pushed a commit to branch master
> in repository macports-ports.
> 
> 
> https://github.com/macports/macports-ports/commit/39211f92fda4458526220604cef41079bd7b3899
> 
> The following commit(s) were added to refs/heads/master by this push:
> 
>  new 39211f9  fontconfig:  support mpkg/mdmg packaging, add postinstall 
> script to initialize/update font cache. Fixes #53350

Remember that now that we've switched to GitHub, "#53350" refers to *GitHub 
pull request* 53350. If you want to refer to *Trac ticket* 53350, paste the 
complete URL to the Trac ticket. Remember to follow our commit message rules, 
which includes a first line of no more than 50 characters:

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

Re: [macports-ports] 01/06: pgcli: updates.

[Ryan Schmidt]

> On Jan 19, 2017, at 20:28, Ivan Larionov <xeron.os...@gmail.com> wrote:
> 
>> On Thu, Jan 19, 2017 at 5:58 PM, Ryan Schmidt <ryandes...@macports.org> 
>> wrote:
>> 
>> > On Jan 19, 2017, at 17:29, Ivan Larionov <xeron.os...@gmail.com> wrote:
>> >
>> > How do we control postgresql version for py-psycopg2 when installing pgcli 
>> > then? Is there a way to do something like this?
>> >
>> > if variant postgresql96 {
>> >   depends_lib-append py{python.version}-psycopg2 +postgresql96
>> > }
>> 
>> You cannot declare a dependency on a variant. MacPorts does not contain that 
>> functionality.
>> 
>> In what way does pgcli care what variant of pyXX-psycopg2 is installed?

> 
> pgcli doesn't care, but, for example, user of postgresql96 don't want to 
> install postgresql95 when installing pgcli just because default variant of 
> py-psycopg2 is postgresql95.

Then that user should either put "+postgresql96" into their variants.conf or 
should run "sudo port install pgcli +postgresql96" (the variant will propagate 
to any uninstalled dependencies)

Also, the default variant of py-psycopg2 should be changed to +postgresql96 
since that is the latest stable version.

Warning: reinplace ... didn't change anything in ...

[Ryan Schmidt]

MacPorts 2.4.1 shows a new warning when a reinplace command doesn't change 
anything. The purpose of reinplace is to change something in a file, so when 
that doesn't happen, it may be a developer error that we want to alert the 
developer about. Portfile developers should remove these warnings in the 
appropriate way, which may be to fix the reinplace or use a patchfile instead; 
remove the reinplace; or silence the warning.

The most common situation will probably be a portfile that contains a reinplace 
that changes something in a source file, and it worked at one time, but then 
the port was updated to a new version of the software, which changed that 
source file in such a way that the reinplace no longer works. Examine the 
source file and the reinplace to figure out what was being changed. You may 
find it easier to go back to the old version of the software that the port was 
using at the time the reinplace was last modified. (Use "git blame" to find out 
when that was.) Once you figure out what was being changed, determine whether 
it still needs to be changed in the new version. If so, update the reinplace so 
it works again or preferably, if practical, change the reinplace to a 
patchfile; you'll probably need to increase the port's revision, if the change 
has any bearing on what the port installs. If the reinplace is no longer 
needed, just remove it from the portfile.

Another possibility is a reinplace in a portfile or portgroup that the 
developer intended to be a no-op in some situations. For example, you might be 
reinplacing "/opt/local" with the value of ${prefix}; if the value of ${prefix} 
*is* "/opt/local", this wouldn't change anything, and that's fine, though in 
this situation, we prefer that the file to be changed contains a placeholder, 
like "@PREFIX@", and then you reinplace "@PREFIX@" with the value of ${prefix}. 
Or, you might be using fs-traverse to loop over many files, reinplacing each 
one, even if not all of the files need the reinplacement -- for example, 
looping over all python files to change the shebang line. In these cases, 
silence the warning by using reinplace's new "-q" ("quiet") flag.

Re: [macports-ports] branch master updated: smlr: new port

[Ryan Schmidt]

> On Feb 28, 2017, at 07:56, Kurt Hindenburg  wrote:
> 
> Kurt Hindenburg (kurthindenburg) pushed a commit to branch master
> in repository macports-ports.
> 
> 
> https://github.com/macports/macports-ports/commit/6262d02ad4539a02372e9959b8a653ba2d03b043
> 
> The following commit(s) were added to refs/heads/master by this push:
> 
>  new 6262d02  smlr: new port
> 
>  new c8ad1a4  Merge branch 'master' of github.com:macports/macports-ports
> 
> 6262d02 is described below
> 
> 
> commit 6262d02ad4539a02372e9959b8a653ba2d03b043
> 
> Author: Kurt Hindenburg 
> AuthorDate: Tue Feb 28 08:54:46 2017 -0500
> 
> 
> smlr: new port
> 
> 
> 
> closes https://trac.macports.org/ticket/53478
> 
> ---
>  sysutils/smlr/Portfile  | 32 
>  sysutils/smlr/files/patch-Makefile.diff | 53 
> +
>  2 files changed, 85 insertions(+)
> 
> 
> diff --git a/sysutils/smlr/Portfile b/sysutils/smlr/Portfile
> 
> new file mode 100644
> 
> index 000..7362a3f
> 
> --- /dev/null
> 
> +++ b/sysutils/smlr/Portfile
> 
> @@ -0,0 +1,32 @@
> 
> +# -*- coding: utf-8; mode: tcl; tab-width: 2; indent-tabs-mode: nil; 
> c-basic-offset: 2 -*- vim:fenc=utf-8:ft=tcl:et:sw=4:ts=4:sts=4
> 
> +
> 
> +PortSystem  1.0
> 
> +PortGroup   github 1.0
> 
> +
> 
> +github.setupthenatefisher smlr 0.0.6
> 
> +categories  sysutils
> 
> +platforms   darwin
> 
> +license MIT
> 
> +maintainers @thenatefisher openmaintainer
> 
> +
> 
> +homepagehttps://github.com/thenatefisher/smlr
> 
> +
> 
> +description Text truncation utility
> 
> +long_descriptionsmlr reduces the size of a text input based on \
> 
> +specified parameters. It makes your string smaller, if it's too big.
> 
> +
> 
> +checksums   sha256  
> 4641de211cd5d7ab7df5508568cf885920dce0046900c73656f5a5d6a81e7982 \
> 
> +rmd160  95a6d0a71604993b31bbb4c468299e176ad028d2
> 
> +
> 
> +patchfiles  patch-Makefile.diff
> 
> +
> 
> +variant universal {}
> 
> +
> 
> +use_configure   no
> 
> +
> 
> +build.env   CC="${configure.cc}" \
> 
> +CFLAGS="${configure.cflags} [get_canonical_archflags 
> cc]" \
> 
> +LDFLAGS="${configure.ldflags} [get_canonical_archflags 
> ld]" \
> 
> +PREFIX=${prefix}
> 
> +
> 
> +destroot.envPREFIX=${destroot}${prefix}
> 
> diff --git a/sysutils/smlr/files/patch-Makefile.diff 
> b/sysutils/smlr/files/patch-Makefile.diff
> 
> new file mode 100644
> 
> index 000..85fcadb
> 
> --- /dev/null
> 
> +++ b/sysutils/smlr/files/patch-Makefile.diff
> 
> @@ -0,0 +1,53 @@
> 
> +--- Makefile 2017-02-03 03:41:09.0 -0500
> 
>  Makefile 2017-02-28 08:52:27.0 -0500
> 
> +@@ -1,47 +1,19 @@
> 
> + SRC_DIR =src
> 
> + BUILD_DIR   =build
> 
> +-TESTS_DIR   =tests
> 
> +-GTEST_DIR   =googletest/googletest
> 
> +-GTEST_INC   =-I$(GTEST_DIR)/include -I$(GTEST_DIR)/include/gtest 
> -I$(GTEST_DIR)/include/gtest/internal
> 
> +-INSTALL_DIR =opt/local/bin
> 
> + 
> 
> + all : $(BUILD_DIR)/rel/smlr
> 
> + 
> 
> +-test : $(BUILD_DIR)/rel/smlr_ut
> 
> +-@git submodule  update --init
> 
> +-@$(BUILD_DIR)/rel/smlr_ut
> 
> +-
> 
> + install : $(BUILD_DIR)/rel/smlr
> 
> +-cp $^ $(DESTDIR)/$(INSTALL_DIR)
> 
> ++cp $^ $(PREFIX)/bin/
> 

I'd rather not see a patch that removes DESTDIR support from a Makefile. We 
prefer DESTDIR support. I agree the way in which the Makefile was supporting 
changing the prefix (using the INSTALL_DIR variable) was sub-optimal, but I'd 
rather see a patch that fixes that while retaining the DESTDIR support.

Re: [146082] trunk/dports/audio

[Ryan Schmidt]

> On Feb 26, 2016, at 08:42, mo...@macports.org wrote:
> 
> Revision
> 146082
> Author
> mo...@macports.org
> Date
> 2016-02-26 06:42:27 -0800 (Fri, 26 Feb 2016)
> Log Message
> 
> audacity: new port (maintainer, closes #47189)
> Added Paths
> 
>   • trunk/dports/audio/audacity/
>   • trunk/dports/audio/audacity/Portfile
>   • trunk/dports/audio/audacity/files/
>   • trunk/dports/audio/audacity/files/FFmpeg_build_against_ffmpeg.diff
>   • trunk/dports/audio/audacity/files/add_enGB_translation.diff
>   • trunk/dports/audio/audacity/files/add_missing_newline.diff
>   • trunk/dports/audio/audacity/files/buildinfo-clarify-no-gstreamer.diff
>   • trunk/dports/audio/audacity/files/debian/
>   • trunk/dports/audio/audacity/files/debian/patches/
>   • 
> trunk/dports/audio/audacity/files/debian/patches/fix-minsrc-autoreconf.patch
>   • 
> trunk/dports/audio/audacity/files/debian/patches/workaround-wxwidgets-fit-recovery.patch
>   • trunk/dports/audio/audacity/files/libvamp-Makefile-for-osx.diff
>   • 
> trunk/dports/audio/audacity/files/patch-avoid-clang-choke-on-confbase.diff
>   • trunk/dports/audio/audacity/files/patch-fix-audiounits.diff
>   • 
> trunk/dports/audio/audacity/files/patch-libnyquist-symbol-visibility.diff
>   • trunk/dports/audio/audacity/files/patch-more-decent-font-sizes.diff
>   • trunk/dports/audio/audacity/files/patch-no-rtld_deepbind.diff
>   • trunk/dports/audio/audacity/files/patch-python.diff
>   • trunk/dports/audio/audacity/files/patch-vstcontrolosx.diff
>   • trunk/dports/audio/audacity/files/portaudio-no-universal-build.diff
>   • trunk/dports/audio/audacity/files/src-Makefile-for-osx.diff
> Diff
> 
> Added: trunk/dports/audio/audacity/Portfile (0 => 146082)
> 
> --- trunk/dports/audio/audacity/Portfile  (rev 0)
> +++ trunk/dports/audio/audacity/Portfile  2016-02-26 14:42:27 UTC (rev 
> 146082)
> 
> @@ -0,0 +1,193 @@
> 
> +# -*- coding: utf-8; mode: tcl; tab-width: 4; truncate-lines: t; 
> indent-tabs-mode: nil; c-basic-offset: 4 -*- vim:fenc=utf-8:et:sw=4:ts=4:sts=4
> +# kate: backspace-indents true; indent-pasted-text true; indent-width 4; 
> keep-extra-spaces true; remove-trailing-spaces modified; replace-tabs true; 
> replace-tabs-save true; syntax Tcl/Tk; tab-indents true; tab-width 4;
> +
> +PortSystem  1.0
> +PortGroup   wxWidgets 1.0
> +
> +nameaudacity
> +version 2.1.2
> +
> +# use the release tarball from github because it contains all required 
> external libs
> +# incl. those not in MacPorts.
> +PortGroup   github 1.0
> +github.setupaudacity audacity ${version} Audacity-
> +github.tarball_from releases
> +master_siteshttps://github.com/audacity/audacity/archive/
> 
> +distnameAudacity-${version}
> +checksums   rmd160  4e0c508b8edd24935a235c0b1a636c4ef1ae59a9 \
> +sha256  
> 90007b50cdc3885607b1afef2f158777a61c1658e869a88ec4d98c59c133f9bd
> +
> +post-extract {
> +file rename ${workpath}/audacity-Audacity-${version} 
> ${workpath}/${distname}
> +}

But you're not using a release tarball. You're telling MacPorts to use a 
release tarball ("github.tarball_from releases"), then on the next line telling 
MacPorts not to do that by overriding the master_sites. You shouldn't need to 
do that, nor should you need to rename a directory in post-extract. Consult the 
documentation in the comments at the top of the github portgroup for proper 
usage of this portgroup.

Re: How to handle MacPorts' handles in the future (including the email address connected to it)??

[Ryan Schmidt]

> On Nov 9, 2016, at 6:28 PM, Marko Käning <mk-macpo...@posteo.net> wrote:
> 
> Hi Ryan,
> 
> On 05 Nov 2016, at 19:05 , Ryan Schmidt <ryandes...@macports.org> wrote:
> 
>>> I’d like to be able to send emails as well, not just receive them. What
>>> am I missing here - in case the requested is also possible since 10 years?
>> 
>> Use your normal smtp server, from your ISP or wherever. Set a different From 
>> address in your email client. In Apple Mail, for example, I get a drop-down 
>> menu in my compose window, so I can choose which address I want to send from 
>> for each message.
> 
> the reason why I bring this up here is that my ISPs do not allow me to use a 
> From-address which isn’t hosted by them.*
> 
> This is why my outgoing email using my MacPorts handle is currently being 
> sent for me by MacPorts fellow and friend Brad (pixilla) since years. This is 
> working fine, but I’d like to have a more general approach as I can’t imagine 
> that I am the only one faced with this kind of problem for the MacPorts 
> handle email address.
> 
> Greets,
> Marko
> 
> 
> 
>  *) This is done to put a stop to spammers, I believe.
> 


I don't think MacPorts wants the burden of running and securing an smtp server. 
That's not our mission. You'll have to find an smtp server that allow you to 
change the from address.

Re: How to handle MacPorts' handles in the future (including the email address connected to it)??

[Ryan Schmidt]

> On Nov 9, 2016, at 7:17 PM, Rainer Müller <rai...@macports.org> wrote:
> 
> On 2016-11-10 01:30, Ryan Schmidt wrote:
>> I don't think MacPorts wants the burden of running and securing an
>> smtp server. That's not our mission. You'll have to find an smtp
>> server that allow you to change the from address.
> 
> Uhm, in fact, we already do that for the forwards and the mailing lists.

There would be additional things needed above what we already have. For 
example, a way for users to securely authenticate with the server, such as 
passwords or certificates.


> As I said in my previous mail, I would like to offer that at some point,
> but it is not going to happen in the near future.

Re: [macports-ports] 03/03: lbdb: Update to 0.42

[Ryan Schmidt]

> On Nov 10, 2016, at 8:55 AM, Rainer Müller <rai...@macports.org> wrote:
> 
> On 2016-11-10 15:19, Ryan Schmidt wrote:
>> Ryan Schmidt (ryandesign) pushed a commit to branch master
>> in repository macports-ports.
>> 
>> 
>> https://github.com/macports/macports-ports/commit/4e836559279a752ee090ed4aa8f1b0c3aa7d0a9a
>> 
>> commit 4e836559279a752ee090ed4aa8f1b0c3aa7d0a9a
>> 
>> Author: Ryan Schmidt <ryandes...@macports.org>
>> 
>> AuthorDate: Thu Nov 10 08:18:37 2016 -0600
>> 
>> 
>> lbdb: Update to 0.42
>> 
>> 
>> 
>> Also:
>> 
>> 
>> 
>> * Fix license.
>> 
>> * Add libiconv dependency.
>> 
>> * Add specific perl dependency and ensure it’s used.
>> 
>> 
>> 
>> Resolves: https://trac.macports.org/ticket/50524
> "Resolves" is not a keyword recognized by the CommitTicketUpdater, use 
> "Closes", "Fix", or "Fixes".

Can't remember what it supports.

It should recognize "Resolves"; we've been using that in Subversion commit 
messages for years.

Re: How to handle MacPorts' handles in the future (including the email address connected to it)??

[Ryan Schmidt]

> On Nov 5, 2016, at 11:43 AM, Marko Käning <mk-macpo...@posteo.net> wrote:
> 
> Hi Ryan,
> 
> On 02 Nov 2016, at 23:49 , Ryan Schmidt <ryandes...@macports.org> wrote:
>> I'm confused about why you're confused or what you're talking about.
> 
> :)
> 
> 
>> We've always provided @macports.org email forwarding for committers. You 
>> tell us what handle you want, we set it up to forward to whatever email 
>> address you want. We had that for 10 years on macOS forge and we now moved 
>> that same system to our new server. Is it not working for you for some 
>> reason?
> 
> What I mean is that I do receive the emails being sent to you via my macports
> handle mk, but I can’t send emails through smtp.macports.org or something like
> that.

Correct, we do not offer an smtp server.

> I’d like to be able to send emails as well, not just receive them. What
> am I missing here - in case the requested is also possible since 10 years?

Use your normal smtp server, from your ISP or wherever. Set a different From 
address in your email client. In Apple Mail, for example, I get a drop-down 
menu in my compose window, so I can choose which address I want to send from 
for each message.

Re: Backport or not: [macports-base] Support multi-valued maintainers

[Ryan Schmidt]

> On Nov 12, 2016, at 2:03 PM, Lawrence Velázquez <lar...@macports.org> wrote:
> 
>> On Nov 12, 2016, at 12:44 PM, Rainer Müller <rai...@macports.org> wrote:
>> 
>>> On 2016-11-12 17:39, Ryan Schmidt wrote:
>>> 
>>> Perhaps it should more properly be called 2.4, but since our master
>>> is in no fix state to be branched for 2.4 at this time and we are
>>> still figuring out our release process on GitHub, it might be
>>> simpler to do this next release from the 2.3 branch and call it
>>> 2.3.5.
>> 
>> master is definitely not in a state to be released, but the roadmap
>> should be discussed separately. Changing the maintainers would be the
>> only breaking change we would add. If we say this absolutely requires a
>> new 2.x release, we could also branch release-2.4 from release-2.3 and
>> call the next release 2.4.0.
> 
> Branching release-2.4 from release-2.3 seems fine to me.

We've never done anything like that before and I don't know what all the 
consequences would be.

> I don't think
> our decision on versioning should be affected (much) by a desire to
> branch from master.

One consequence that occurs to me is that people using master currently have 
version 2.3.99. If we branch 2.4 from 2.3, then when those users run selfupdate 
they would be "upgraded" to 2.4 which doesn't contain all the features they had 
been using on 2.3.99. In the 2 years of master development, we might have done 
many things, such as adding columns to the registry database, that would make 
it bad for the user to downgrade.

Re: [macports-ports] branch master updated: grib_api: delete unused CMake flags

[Ryan Schmidt]

> On Nov 14, 2016, at 6:42 PM, tenomoto  
> wrote:
> 
> tenomoto pushed a commit to branch master
> in repository macports-ports.
> 
> 
> https://github.com/macports/macports-ports/commit/8dd1f26e3c8218708a97ac7bd1d4b0aae1984046
> 
> The following commit(s) were added to refs/heads/master by this push:
> 
>  new 8dd1f26  grib_api: delete unused CMake flags
> 
> 8dd1f26 is described below
> 
> 
> commit 8dd1f26e3c8218708a97ac7bd1d4b0aae1984046
> 
> Author: Takeshi Enomoto 
> AuthorDate: Tue Nov 15 09:37:46 2016 +0900
> 
> 
> grib_api: delete unused CMake flags
> 
> ---
>  science/grib_api/Portfile | 4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)
> 
> 
> diff --git a/science/grib_api/Portfile b/science/grib_api/Portfile
> 
> index 7758a15..4992f40 100644
> 
> --- a/science/grib_api/Portfile
> 
> +++ b/science/grib_api/Portfile
> 
> @@ -1,4 +1,5 @@
> 
>  # -*- coding: utf-8; mode: tcl; tab-width: 4; indent-tabs-mode: nil; 
> c-basic-offset: 4 -*- vim:fenc=utf-8:ft=tcl:et:sw=4:ts=4:sts=4
> 
> +# $Id$
> 

Please don't re-add the $Id$ line. We used that with Subversion but aren't 
using it anymore now that we moved to Git.


>  
>  PortSystem  1.0
>  PortGroup cmake 1.0
> 
> @@ -6,7 +7,6 @@ PortGroup compilers 1.0
> 
>  
>  namegrib_api
>  version 1.18.0
> 
> -revision1

You can't just decrease the revision.

Re: Another workflow (pull requests) question.

[Ryan Schmidt]

> On Nov 14, 2016, at 11:11 AM, Eric A. Borisch  wrote:
> 
> If squash-and-merge is what we're going to want for pull requests, can we 
> re-enable the button? (Also known as, if we're using GitHub, can we use 
> GitHub?) Ideally contributions from others (like this pull request) should be 
> as painless (read as: fewest steps that still achieve the desired ends) as 
> possible on both sides.

I do not know who disabled the button or why. I'm leaving the details of how we 
use git and github to other contributors who are familiar with how to use git 
and github best.

Re: `git describe`

[Ryan Schmidt]

> On Nov 28, 2016, at 3:28 PM, René J.V. Bertin  wrote:
> 
>> As you discovered yourself now, 'port version' of master identifies
>> itself as 2.3.99 at the moment.
> 
> Yes, and if you look at the history of the script in config that sets that 
> version, it apparently has been fixed at 2.3.99 for about 2 years now.

That's correct and intentional. It was changed to 2.3.99 after we created the 
2.3 release branch, which was 2 years ago. After we create a 2.4 release 
branch, the version on master will be changed to 2.4.99.

Re: [macports-ports] 03/03: shared-mime-info: Declare lack of libraries

[Ryan Schmidt]

> On Nov 19, 2016, at 4:32 PM, René Bertin  wrote:
> 
> Lawrence Velázquez (larryv) pushed a commit to branch master
> in repository macports-ports.
> 
> 
> https://github.com/macports/macports-ports/commit/d0a125505343b650472fdf74ca7cab18b7ce94eb
> 
> commit d0a125505343b650472fdf74ca7cab18b7ce94eb
> 
> Author: René J. V. Bertin 
> AuthorDate: Thu Nov 17 14:20:56 2016 -0500
> 
> 
> shared-mime-info: Declare lack of libraries
> 
> 
> 
> Signed-off-by: Marko Käning 
> 
> ---
>  devel/shared-mime-info/Portfile | 2 ++
>  1 file changed, 2 insertions(+)
> 
> 
> diff --git a/devel/shared-mime-info/Portfile b/devel/shared-mime-info/Portfile
> 
> index c64c23d..1961e99 100644
> 
> --- a/devel/shared-mime-info/Portfile
> 
> +++ b/devel/shared-mime-info/Portfile
> 
> @@ -5,6 +5,7 @@ PortSystem  1.0
> 
>  
>  nameshared-mime-info
>  version 1.7
> 
> +revision1
> 
>  maintainers gmail.com:rjvbertin mk openmaintainer
>  categories  devel
>  license GPL-2+
> 
> @@ -17,6 +18,7 @@ long_descriptionThe core database of common types and 
> the \
> 
>  homepage
> https://www.freedesktop.org/wiki/Software/shared-mime-info/
>  master_siteshttps://people.freedesktop.org/~hadess/
>  use_xz  yes
> 
> +installs_libs   no

Why increase revision? This does not change installed files; it just makes a 
declaration that the installed files do not contain libraries.

Re: Triggering a rebuild on the buildbot

[Ryan Schmidt]

On Nov 15, 2016, at 21:27, Adam Mercer  wrote:
> 
> Thanks, I've logged in. Now for a hopefully not too stupid question,
> but how do I actually trigger a new build? Is there some documentation
> somewhere?

I'm not sure what we have documented. But I'm sending this reply back to the 
list so it'll be in the archive at least. 

I usually start from the "Builders" page:

https://build.macports.org/builders

Scroll down to the "portwatcher_force" section. 

Check the box of each builder on which you want to start the build. 

Put the space-separated list of ports you want to build into the "Port list" 
field. Any subports of those ports will also be built. 

Leave the other fields blank and press the "Force Build" button. 

Then switch to the "Waterfall" page to watch the progress of the build, 
refreshing manually as needed or configuring the waterfall to refresh 
automatically. 

https://build.macports.org/waterfall

Re: Thanks

[Ryan Schmidt]

On Nov 26, 2016, at 2:15 PM, Marko Käning wrote:

> I hope Apple will employ for longer than just the past year to keep
> this community effort alive and ticking!

My contract position with Apple was for the purpose of maintaining macOS forge 
and decommissioning it. Now that that has happened and all projects have been 
moved and macOS forge has been shut down, my contract with Apple has ended.

I'm still here working on MacPorts on my own time.

Re: Some Homebrew commands send data to Google Analytics vs. port mpstats

[Ryan Schmidt]

I also read that article yesterday.

Because our statistics are opt in, and the user is not invited to enable them 
during the installation, and they are not described in the guide or anywhere 
that I'm aware of, the number of users who have found and enabled it are 
minuscule and probably not representative of MacPorts users as a whole.

The lack of statistics about how many users use MacPorts and what ports they 
have installed is probably hurting us.

-Ryan


> On Nov 26, 2016, at 2:37 PM, Marko Käning  wrote:
> 
> Hi,
> 
> the other day I found an article on hacker news [1] which eventually made 
> clear
> that homebrew actually sends (some) data to google analytics by default [2]!
> 
> I am happy about MacPorts’ “analytics” by port mpstats being absolutely opt-in
> and keeping the data within MacPorts (Clemens’ server in fact) and doesn’t try
> anything funny!
> 
> Thanks, MacPorts for caring (more) about its users privacy!
> 
> Greets,
> Marko
> 
> 
> [1] https://tobiastom.name/notes/7a79eed0
> [2] 
> https://github.com/Homebrew/brew/blob/7f13b37b903564e2a64cea982d6b84d1aa6b800b/Library/Homebrew/utils/analytics.sh#L73-L94
> 

Re: `git describe`

[Ryan Schmidt]

> On Nov 29, 2016, at 2:57 AM, René J.V. Bertin <rjvber...@gmail.com> wrote:
> 
> On Monday November 28 2016 17:25:39 Ryan Schmidt wrote:
> 
>> That's correct and intentional.
> 
> I also said that that version complied with practices I see elsewhere :)
> 
>> It was changed to 2.3.99 after we created the 2.3 release branch, which was 
>> 2 years ago. After we create a 2.4 release branch, the version on master 
>> will be changed to 2.4.99.
> 
> Then you have your answer in fact. When you bump the version in that script 
> you can use git-release or equivalent to create a 2.4.99 tag, and from there 
> on `git describe` would identify master as 2.4.99-- . 
> That'd be almost exactly what I'd like to see (though later rather than 
> sooner).

We don't want a x.x.99 tag. It wouldn't mean anything. x.x.99 means master. It 
doesn't mean any specific state of master.


> Would you consider adding an additional level by 2.3.6 (= 2.3.99.6) so that 
> the master version keeps some form of synchronisation with the release 
> version? I don't think that it suggests master is based on 2.3.X, but it does 
> convey the message that 2.3.X contains things that were introduced into 
> master before 2.3.99.X.

No, I would not consider adding such tags.

Re: declaring variants/subports in loops and loop variables

[Ryan Schmidt]

> On Dec 7, 2016, at 11:04 AM, Joshua Root <j...@macports.org> wrote:
> 
> On 2016-12-8 03:07 , Ryan Schmidt wrote:
>> 
>>> On Dec 7, 2016, at 4:20 AM, René J.V. Bertin <rjvber...@gmail.com> wrote:
>>> 
>>> Hi,
>>> 
>>> See https://trac.macports.org/ticket/53022#comment:2
>>> 
>>> I'm still waiting for the final verdict from the ticket reporter, but it 
>>> seems that issue was one of those cases where I shouldn't have used a loop 
>>> variable in the declaration scope of a variant (nor subport):
>>> 
>>> {{{
>>> set pythonversions {3.4 3.5}
>>> foreach pdv ${pythonversions} {
>>>   set pv [join [lrange [split ${pdv} .] 0 1] ""]
>>>   # snip
>>>   variant python${pv} description "Add bindings for Python ${pdv}" {
>>>   depends_libs-append port:python${pv}
>>>   # snip
>>>   }
>>> }
>>> }}}
>>> 
>>> Why is it that this makes both the +python34 and +python35 variants depend 
>>> on the last value of ${pv}, and thus on port:python35? Are those 
>>> declaration scopes somehow evaluated outside of the loop? That hypothesis 
>>> is supported by the error that's raised when I unset pdv and pv immediately 
>>> after the loop.
> 
> This is almost exactly the same situation as:
> 
> foreach foo {bar baz} {
>   proc p_$foo {} {
>   puts $foo
>   }
> }
> p_bar
> p_baz
> 
> Try it in tclsh. (Variants are slightly different only in that they 
> automagically bring all global variables into scope. Thus you get pv with its 
> current value instead of a "no such variable" error.)
> 
>>> If so, is there a cleaner and not much more complex way to do loop-based 
>>> variant/subport declaration such that at least the loop variables are 
>>> undefined outside of the loop? Unsetting the variables works but isn't very 
>>> elegant and too easy to forget.
>>> 
>>> R.
>> 
>> The boost port shows a typical example of using "eval" and "subst" to ensure 
>> the variable values are substituted immediately.
> 
> That sounds overly complicated (there should be almost no reason to use eval, 
> ever.) Quotes instead of braces would allow variable substitution in the 
> variant body.

I agree, it sounds overly complicated to me too, but it is at least a block of 
code that has been tested by someone and added to many ports and seems to work.

Re: Criteria for picking compilers from fallback list ?

[Ryan Schmidt]

> On Dec 7, 2016, at 12:05 PM, Christopher Jones  
> wrote:
> 
> 
>> On 7 Dec 2016, at 5:32 pm, Joshua Root  wrote:
>> 
>> On 2016-12-8 04:24 , Chris Jones wrote:
>>> Hi,
>>> 
>>> I'm working on an update to the root6 port, where the minimum compiler
>>> requirement has been increased in the latest release, such that I need
>>> to update the compiler blacklist/fallback to force a macports compiler
>>> to be used on OSX 10.8 and 10.9 (whereas previously the system one was OK).
>>> 
>>> This is all working OK, but I have noticed one thing I am trying to
>>> understand is on 10.8 and 10.9 different fallbacks are being picked.
>>> 
>>> I have
>>> 
>>> compiler.blacklist-append *gcc* {clang < 602} macports-clang-3.3
>>> macports-clang-3.4 macports-clang-3.5 macports-clang-3.6
>>> compiler.fallback-append macports-clang-3.9 macports-clang-3.8
>>> macports-clang-3.7
>>> 
>>> On 10.8 this is causing macports clang 3.9 to be picked, whereas on 10.9
>>> clang 3.8 is being used. I am curious as to what the logic is in the
>>> blacklist portgroup that is leading to this different decisions to be
>>> made ? I thought perhaps it was based on what clang ports where already
>>> installed, but even after uninstalling all clang versions, the same
>>> decisions are being made. Just curious...
>> 
>> The initial value of compiler.fallback differs based on cxx_stdlib because 
>> clang 3.5+ needs libc++. And yes, this will mean trouble for users on 10.8 
>> who are using the default cxx_stdlib.
> 
> Ah, I didn’t consider the cxx_stdlib differences. Still not sure though how 
> that exactly translates into different decisions w.r.t. clang 3.8 versus 3.9 
> though. Is it just the different list means a different (random) decision is 
> taken ? both are >3.5 so on the same field regarding the stdlib used.

No random decisions are taken. MacPorts uses the first acceptable (i.e. not 
blacklisted) compiler from the whitelist (if you specify a whitelist), or the 
first acceptable compiler from the fallback list (if you don't specify a 
whitelist).

You can read the portconfigure::get_compiler_fallback procedure in 
src/port1.0/portconfigure.tcl to see all the nuance that goes into generating 
the list of compilers to try, which varies based on OS version, Xcode version, 
and C++ library:

https://github.com/macports/macports-base/blob/7fb6ab2e5a40a5f4f828430a499b840b43398c56/src/port1.0/portconfigure.tcl#L475

but the relevant part here is:

On OS X versions earlier than Sierra, with libc++ and Xcode 5 or later (i.e. on 
10.9-10.11, or on 10.8 or earlier if the user follows the LibcxxOnOlderSystems 
wiki page) the default compiler fallback is:

clang macports-clang-3.8 macports-clang-3.7 macports-clang-3.6 
macports-clang-3.5

(The intention is that this would list the newest stable version of clang 
first, followed by the next newest stable version, etc. clang 3.9.0 stable was 
released in September 2016 so one would think that macports-clang-3.9 should be 
prepended to that list, but we haven't done that yet; I don't know if there is 
an extenuating circumstance why that has not yet been done.)

With libstdc++ and Xcode 5 or later, the default compiler fallback is:

clang macports-clang-3.4 macports-clang-3.3

To these lists, in your port you append "macports-clang-3.9 macports-clang-3.8 
macports-clang-3.7"

That means the final fallback list for your port for libc++ on 10.11 or earlier 
with Xcode 5 or later is:

clang macports-clang-3.8 macports-clang-3.7 macports-clang-3.6 
macports-clang-3.5 macports-clang-3.9 macports-clang-3.8 macports-clang-3.7

From this, MacPorts picks the first acceptable compiler, which (since you are 
blacklisting clang < 602) is either clang (if its version is >= 602) or 
macports-clang-3.8 (if clang's version is < 602).

For libstdc++ with Xcode 5 or later, the final fallback for your port is:

clang macports-clang-3.4 macports-clang-3.3 macports-clang-3.9 
macports-clang-3.8 macports-clang-3.7

(For earlier Xcode versions, llvm-gcc-4.2 is also in the list, but since you're 
blacklisting *gcc* that won't get used.)

From this, MacPorts picks the first acceptable compiler, which (since you are 
blacklisting clang < 602 and macports-clang-3.3 and macports-clang-3.4) is 
macports-clang-3.9.

Re: Commits that implicitly close PRs do not remember doing so

[Ryan Schmidt]

On Dec 12, 2016, at 05:43, Mojca Miklavec  wrote:

> 
> This actually reminded me of another potential "problem". In the past
> we always used the
>(closes #1234567)
> syntax which we changed during migration to GIT to absolute links. Do
> we want to use absolute links for
>Closes: https://github.com/macports/macports-ports/pull/1234567
> as well?

I don't know of any reason why we would want that at this time. 

Re: [MacPorts] #53049: gqrx dependency missing

[Ryan Schmidt]

On Dec 11, 2016, at 8:49 AM, Michael Dickens wrote:

> It -is- true that, if you are installing 'port' from scratch, then
> doxygen almost always fails to build the first time (I don't recall why;
> nor if I've looked into this issue; nor if anybody has tried to fix this
> issue). The solution is to do:
> {{{
> sudo port clean doxygen
> sudo port install doxygen
> }}}
> and, then go back to the original install, which should now work (seems
> to be 100% reliable in user testing for people working with me in this
> regard). In particular, this happens when installing any GNU Radio port,
> which would include Gqrx.

Given that gnuradio has almost 300 dependencies, the cause of this problem is 
probably:

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

Re: `port edit`, local/console vs. remote use

[Ryan Schmidt]

On Dec 6, 2016, at 10:03, René J.V. Bertin wrote:
> 
> Has there ever been discussion about if and how to let `port edit` invoke a 
> different editor when you're working locally vs. over SSH?
> 
> I realise this could theoretically be handled by setting a different 
> MP_EDITOR value in your shell's .*profile/.*rc file but I cannot think of a 
> reliable way to detect local vs. remote access right now, esp. not one that 
> will distinguish between local "aqua vs non aqua" sessions. And to make 
> things yet more complex: ssh to a remote host and from there back to a Mac, 
> all from within an Aqua session, and you can still do things like `open -e` 
> to edit a file in TextEdit.

I would like `port edit` to open TextWrangler when I'm at my Mac or vi when I'm 
sshing in from another machine. But I consider it to be something that a user 
would configure in their own environment to suit their taste, not something 
that would involve changes to MacPorts base code.

I haven't taken the time to look into how I could configure that. So instead, I 
configure EDITOR to run TextWrangler, and whenever I ssh in and need to edit a 
portfile, which is rare, I use 'vi $(port file someport)` instead of `port edit 
someport`. 

Re: Build Failure: gstreamer1-gst-plugins-bad, mesa, x265

[Ryan Schmidt]

I see /usr/bin/sysdiagnose on Lion, but not on Snow Leopard. Is it an optional 
install on Snow Leopard, or did it not exist until Lion?

Should I try to run the Lion version on Snow Leopard, or gather the information 
some other way?


> On Nov 28, 2016, at 6:04 PM, Jeremy Huddleston Sequoia 
> <jerem...@macports.org> wrote:
> 
> Can you please grab a sysdiagnose before rebooting?  That'll be a good first 
> step.  Once I see that, I might have some questions for next time.
> 
> 
>> On Nov 28, 2016, at 15:31, Ryan Schmidt <ryandes...@macports.org> wrote:
>> 
>> 
>> On Nov 27, 2016, at 7:49 PM, David Evans wrote:
>> 
>>> On 11/27/16 5:10 PM, Jeremy Huddleston Sequoia wrote:
>>>> From:
>>>> 
>>>> https://build.macports.org/builders/ports-10.6_x86_64_legacy-builder/builds/11628/steps/install-port/logs/stdio
>>>> 
>>>> DEBUG: Using compiler 'System cc'
>>>> 
>>>> Why is that the case?
>>>> 
>>>> Is xcodeversion not getting set right such that 
>>>> portconfigure::get_compiler_fallback is doing:
>>>> 
>>>> # Check for platforms without Xcode
>>>> if {$xcodeversion eq "none" || $xcodeversion eq ""} {
>>>>return {cc}
>>>> }
>>>> 
>>>> --Jeremy
>>> 
>>> I'm seeing alot of these errors on this buildbot as well and this build is 
>>> no exception
>>> 
>>> Warning: xcodebuild exists but failed to execute
>>> 
>>> Perhaps CLI tools are not properly installed?
>> 
>> 
>> A recurrence of this problem, I guess:
>> 
>> https://trac.macports.org/ticket/52543
>> 
>> Suggestions welcome. Something about Xcode / command line tools / xcodebuild 
>> seems to corrupt itself on Snow Leopard after running for awhile. I don't 
>> know if I should just reboot the VM again or try to reinstall Xcode and the 
>> command line tools this time.
>> 
> 

Re: [macports-ports] branch master updated: py-certbot 0.10.0: new port

[Ryan Schmidt]

> On Jan 13, 2017, at 18:22, Marius Schamschula  wrote:
> 
> Marius Schamschula (Schamschula) pushed a commit to branch master
> in repository macports-ports.
> 
> https://github.com/macports/macports-ports/commit/34767d74a27ef02f00bde27cb79a762f46bd6b00
> 
> The following commit(s) were added to refs/heads/master by this push:
>  new 34767d7  py-certbot 0.10.0: new port
> 34767d7 is described below
> 
> commit 34767d74a27ef02f00bde27cb79a762f46bd6b00
> Author: Marius Schamschula 
> AuthorDate: Fri Jan 13 18:22:14 2017 -0600
> 
> py-certbot 0.10.0: new port
> 
> An ACME Let's Encrypt client that can obtain certs and extensibly
> update server configurations
> ---
>  python/py-certbot/Portfile | 48 
> ++
>  1 file changed, 48 insertions(+)
> 
> diff --git a/python/py-certbot/Portfile b/python/py-certbot/Portfile
> new file mode 100644
> index 000..8e3cb67
> --- /dev/null
> +++ b/python/py-certbot/Portfile
> @@ -0,0 +1,48 @@
> +# -*- 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   github 1.0
> +PortGroup   python 1.0
> +
> +github.setupcertbot certbot 0.10.0 v
> +namepy-certbot
> +categories-append   security
> +license Apache-2
> +maintainers mps openmaintainer
> +description An ACME Let's Encrypt client that can obtain certs and 
> extensibly \
> +update server configurations.
> +long_description${description}
> +platforms   darwin
> +homepagehttps://letsencrypt.org/
> +
> +python.versions 27 34 35 36
> +python.default_version \
> +27

The py36 subport doesn't build:

Error: Dependency 'py36-configargparse' not found.

I've been seeing this kind of thing a lot. We need to be verifying that our 
changes build properly before committing. 

Re: [macports-ports] branch master updated (e58232e -> af96137)

[Ryan Schmidt]

> On Jan 12, 2017, at 18:28, Marius Schamschula  wrote:
> 
> Marius Schamschula (Schamschula) pushed a change to branch master
> in repository macports-ports.
> 
>from e58232e  dependents of x265: rebuild with x265 version 2.2
> new d26e175  bro: Update to 2.5
> new 05ec788  fix hashes
> new af96137  remove revision line
> 
> The 3 revisions listed above as "new" are entirely new to this
> repository and will be described in separate emails.  The revisions
> listed as "add" were already present in the repository and have only
> been added to this reference.
> 
> 
> Summary of changes:
> net/bro/Portfile | 10 +-
> 1 file changed, 5 insertions(+), 5 deletions(-)
> 

This should have been pushed as a single commit.

Re: [macports-ports] branch master updated: arp-scan: use GitHub

[Ryan Schmidt]

On Jan 12, 2017, at 19:28, Marius Schamschula  wrote:
> 
> Marius Schamschula (Schamschula) pushed a commit to branch master
> in repository macports-ports.
> 
> https://github.com/macports/macports-ports/commit/666b4d8918ed73de55a42a69598509b4a512439e
> 
> The following commit(s) were added to refs/heads/master by this push:
>  new 666b4d8  arp-scan: use GitHub
> 666b4d8 is described below
> 
> commit 666b4d8918ed73de55a42a69598509b4a512439e
> Author: Marius Schamschula 
> AuthorDate: Thu Jan 12 19:28:18 2017 -0600
> 
> arp-scan: use GitHub
> ---
>  net/arp-scan/Portfile | 17 +++--
>  1 file changed, 7 insertions(+), 10 deletions(-)
> 
> diff --git a/net/arp-scan/Portfile b/net/arp-scan/Portfile
> index b783858..2608f90 100644
> --- a/net/arp-scan/Portfile
> +++ b/net/arp-scan/Portfile
> @@ -1,24 +1,21 @@
>  # -*- 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   github 1.0
>  
> -namearp-scan
> -version 1.9
> +github.setuproyhills arp-scan 1.9
> +revision1
>  categories  net
>  license GPL-3
> -maintainers gmail.com:mschamschula openmaintainer
> +maintainers mps openmaintainer
>  description ARP scanning and fingerprinting tool
>  long_descriptionArp-scan is a command-line tool that uses the ARP 
> protocol to \
>  discover and fingerprint IP hosts on the local network.
>  platforms   darwin
> -homepage
> http://www.nta-monitor.com/tools-resources/security-tools/arp-scan
> -master_siteshttp://www.nta-monitor.com/files/arp-scan/
>  
> -checksums   rmd160  1c6dabae9ff665ec540b144e8c6613debedfc822 \
> -sha256  
> ce908ac71c48e85dddf6dd4fe5151d13c7528b1f49717a98b2a2535bd797d892
> +checksums   rmd160  c3723a3a0998c3486c26765ed159490580655519 \
> +sha256  
> b88e50721416fb9b02ac57fbc26460ba0c698d32d59c80ad57866f8b5c01f20b
>  
>  depends_lib port:libpcap
>  
> -livecheck.type  regex
> -livecheck.url   ${homepage}
> -livecheck.regex ${name}-(\\d+(?:\\.\\d+)*)${extract.suffix}
> +use_autoreconf  yes
> 

Checksum mismatch for anyone getting the old distfile (which had the same name) 
from the distfiles mirror.

This should be handled as a stealth update per the PortfileRecipes wiki page. 

Re: [macports-ports] branch master updated (e58232e -> af96137)

[Ryan Schmidt]

I know. And we want the history of our main repository to be reasonable, so 
it's necessary to fix PRs before merging.

> On Jan 12, 2017, at 20:15, Marius Schamschula <li...@schamschula.com> wrote:
> 
> This was a merge from a GitHub PR.
> 
>> On Jan 12, 2017, at 8:07 PM, Ryan Schmidt <ryandes...@macports.org> wrote:
>> 
>> 
>>> On Jan 12, 2017, at 18:28, Marius Schamschula <m...@macports.org> wrote:
>>> 
>>> Marius Schamschula (Schamschula) pushed a change to branch master
>>> in repository macports-ports.
>>> 
>>>   from e58232e  dependents of x265: rebuild with x265 version 2.2
>>>new d26e175  bro: Update to 2.5
>>>new 05ec788  fix hashes
>>>new af96137  remove revision line
>>> 
>>> The 3 revisions listed above as "new" are entirely new to this
>>> repository and will be described in separate emails.  The revisions
>>> listed as "add" were already present in the repository and have only
>>> been added to this reference.
>>> 
>>> 
>>> Summary of changes:
>>> net/bro/Portfile | 10 +-
>>> 1 file changed, 5 insertions(+), 5 deletions(-)
>>> 
>> 
>> This should have been pushed as a single commit.
>> 
>> 
> 
> Marius
> --
> Marius Schamschula
> 
> 
> 
> 

Re: [macports-ports] branch master updated: gnutls: add compiler blacklist for Snow Leopard build issue

[Ryan Schmidt]

> On Jan 12, 2017, at 18:21, Marius Schamschula  wrote:
> 
> Marius Schamschula (Schamschula) pushed a commit to branch master
> in repository macports-ports.
> 
> 
> https://github.com/macports/macports-ports/commit/46f834998a6e47ff74fdbd65e47b9cb10cc716c6
> 
> The following commit(s) were added to refs/heads/master by this push:
> 
>  new 46f8349  gnutls: add compiler blacklist for Snow Leopard build issue
> 
> 46f8349 is described below
> 
> 
> commit 46f834998a6e47ff74fdbd65e47b9cb10cc716c6
> 
> Author: Marius Schamschula 
> AuthorDate: Thu Jan 12 18:20:43 2017 -0600
> 
> 
> gnutls: add compiler blacklist for Snow Leopard build issue
> 
> ---
>  devel/gnutls/Portfile | 6 ++
>  1 file changed, 6 insertions(+)
> 
> 
> diff --git a/devel/gnutls/Portfile b/devel/gnutls/Portfile
> 
> index e2e6673..d7ae0df 100644
> 
> --- a/devel/gnutls/Portfile
> 
> +++ b/devel/gnutls/Portfile
> 
> @@ -1,6 +1,8 @@
> 
>  # -*- Mode: Tcl; tab-width: 4; indent-tabs-mode: nil; c-basic-offset: 4 -*- 
> vim:et:sw=4:ts=4:sts=4
>  
>  PortSystem  1.0
> 
> +
> 
> +PortGroup   compiler_blacklist_versions 1.0
> 
You can remove this since you're not actually using the features of this 
portgroup. Except that I see that /usr/bin/clang failed to build it too, so you 
may need this portgroup after all to blacklist older versions of clang.

>  PortGroup   muniversal 1.0
>  
>  namegnutls
> 
> @@ -110,6 +112,10 @@ platform darwin 8 {
> 
>  depends_build-append   port:texinfo
>  }
>  
> 
> +platform darwin 10 {
> 
> +compiler.blacklist-append gcc-4.2
> 
> +}

This seems unlikely to be the correct solution. It seems unlikely that gcc 4.2 
on Snow Leopard would be unfamiliar with AVX instructions, but that gcc 4.2 on 
Leopard would be.

You tested on Leopard PowerPC and didn't have a problem, but AVX are 
Intel-specific instructions so it's likely that a PowerPC build wouldn't 
attempt to use them anyway.

The correct statement is probably to blacklist gcc-4.2 when building for Intel. 
Note that "platform i386" isn't necessarily sufficient for that, since one 
could conceivably be building an i386/ppc universal binary on a PowerPC Mac.

It seems likely that apple-gcc-4.2 (which is the default compiler on Tiger) 
would have the same problem, and a ticket about this issue showed that 
llvm-gcc-4.2 was having the problem too, so you should blacklist "*gcc-4.2*" to 
catch all those cases.

Re: Conflicting binary in dependency

[Ryan Schmidt]

On Jan 12, 2017, at 22:10, Aaron Madlon-Kay wrote:

> > Is there a particular reason why it should be a variant, as opposed to just 
> > always building and installing the tools in the sqlite3 port?
> 
> That's the most convenient solution to be sure. I wasn't sure if, perhaps, 
> sqlite3 is such a prolifically depended-upon port that to keep things 
> lightweight it was using the amalgamation distro (building the tools requires 
> building from the full distro, and brings in the tcl dependency).
> 
> If there's no reason not to build the tools by default then I will do that.

It currently uses the distfile sqlite-autoconf-3160200.tar.gz.

We distribute precompiled binaries which most users can use, so it doesn't 
matter to most users which distfile we use.

Re: Conflicting binary in dependency

[Ryan Schmidt]

On Jan 12, 2017, at 01:58, Aaron Madlon-Kay wrote:
> 
> Hi all. I was hoping to get some advice:
> 
> I want to make the sqlite3-tools package available via MacPorts (binaries 
> available at https://sqlite.org/download.html); this package contains three 
> binaries: sqlite3 CLI shell, sqldiff, and sqlite3_analyzer.
> 
> Problem:
> 
> sqlite3_analyzer requires TCL; it turns out the `tcl` port actually includes 
> sqlite3_analyzer built from its own bundled copy of sqlite3, but it is an 
> older version. This older version is installed to ${prefix}/bin, so it 
> conflicts with any newer version we might try to install.
> 
> Questions:
> 
> - Is it common knowledge that sqlite3_analyzer is available as part of TCL? 
> Its inclusion there seems coincidental, perhaps just due to the fact that 
> it's implemented in TCL?
>   - If no, can we remove it from the `tcl` port?
> 

I was not aware it was in the tcl port. Sounds like a good idea to remove it 
from there.

> - If sqlite3_analyzer can't be removed from the `tcl` port, should the newer 
> binary have a different name or be put in a different path? Is there a 
> standard scheme for disambiguation like this?
> 
> - If no to all above, sqlite3_analyzer can be built against the 
> system-provided TCL framework, and the port can be marked as incompatible 
> with the `tcl` port. Is that acceptable? (I would think not)
> 
> Aside:
> 
> I've got this working in two forms: a +tools variant on the `sqlite3` port, 
> and a new port called `sqlite3-tools`; I'm feeling like a the +tools variant 
> might be the better way to go, but feedback on this would be appreciated as 
> well.

Is there a particular reason why it should be a variant, as opposed to just 
always building and installing the tools in the sqlite3 port?

Whatever you choose, anytime you move a file from being provided by one port to 
being provided by another port, don't forget to use the deactivate hack in the 
new port:

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

Re: [macports-ports] 07/18: py-graph-tool: add Python 3.6 version

[Ryan Schmidt]

> On Jan 11, 2017, at 08:56, Mark Moll  wrote:
> 
> Mark Moll (mamoll) pushed a commit to branch master
> in repository macports-ports.
> 
> 
> https://github.com/macports/macports-ports/commit/ac9a9ab102bc2026808f6a869d6fdbed41434523
> 
> commit ac9a9ab102bc2026808f6a869d6fdbed41434523
> 
> Author: Mark Moll 
> AuthorDate: Wed Jan 11 08:56:41 2017 -0600
> 
> 
> py-graph-tool: add Python 3.6 version
> 
> ---
>  python/py-graph-tool/Portfile | 6 +-
>  1 file changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/python/py-graph-tool/Portfile b/python/py-graph-tool/Portfile
> index 0b7746a..2e45c12 100644
> --- a/python/py-graph-tool/Portfile
> +++ b/python/py-graph-tool/Portfile
> @@ -28,7 +28,7 @@ checksums   md5 
> 6b68edf0ef5efc375b467a7a117eb9c2 \
>  sha256  
> eba1090f94b0434890beedaf0c100dd0fc77e41ebfe29b4725d76cadb82099af
>  distname${realname}-${version}
>  
> -python.versions 27 34 35
> +python.versions 27 34 35 36
>  python.default_version 27
> 
>  if {${os.major} <= 12 && ${os.platform} eq "darwin"} {
> @@ -100,6 +100,10 @@ if {${name} ne ${subport}} {
>  if {${python.version} eq "27"} {
>  configure.env-append PYTHON_EXTRA_LIBS="-u _PyMac_Error"
>  }
> +# Something similar is happening with python3.6
> +if {${python.version} eq "27"} {
> +configure.env-append PYTHON_EXTRA_LIBS="-Wl,-stack_size,100 
> -framework CoreFoundation ${python.lib}"
> +}

In addition to adding the python 3.6 version of this module, you appear to have 
added code that affects the python 2.7 version of this module. I'm unclear 
whether this was intentional, and whether it will overwrite the previously set 
value of PYTHON_EXTRA_LIBS. I'm also unclear whether this will result in a 
change to the installed files or not.

Re: [macports-contrib] branch master updated: portfile-gen: update python versions

[Ryan Schmidt]

> On Dec 2, 2016, at 4:09 AM, Joshua Root  wrote:
> 
> Joshua Root (jmroot) pushed a commit to branch master
> in repository macports-contrib.
> 
> 
> https://github.com/macports/macports-contrib/commit/03f312cb5470db0f189df70cdc2070875279efad
> 
> The following commit(s) were added to refs/heads/master by this push:
> 
>  new 03f312c  portfile-gen: update python versions
> 
> 03f312c is described below
> 
> 
> commit 03f312cb5470db0f189df70cdc2070875279efad
> 
> Author: Joshua Root 
> AuthorDate: Fri Dec 2 21:09:09 2016 +1100
> 
> 
> portfile-gen: update python versions
> 
> 
> 
> + a few formatting adjustments


> --- a/portfile-gen/portfile-gen
> +++ b/portfile-gen/portfile-gen
> @@ -185,12 +185,12 @@ switch ${groupCode} {
> }
>  }
>  puts ""
> -puts "checksums   rmd160  12345 \\"
> -puts "sha256  6789a"
> +puts "checksums   rmd160 12345 \\"
> +puts "sha256 6789a"

This part of this change is contrary to how we have been formatting checksums 
in ports, and I'd like to revert this.

Re: How should ports refer to the 2-clause BSD license?

[Ryan Schmidt]

On Dec 4, 2016, at 10:49, Lawrence Velázquez  wrote:
> 
> The checking script only mentions BSD (3-clause) and BSD-old (4-clause).

As far as I was aware, we were referring to all three versions of the BSD 
licensee as "BSD". Is there a reason to do otherwise?

Re: How should ports refer to the 2-clause BSD license?

[Ryan Schmidt]

> On Dec 4, 2016, at 6:25 PM, Lawrence Velázquez <lar...@macports.org> wrote:
> 
>> On Dec 4, 2016, at 12:11 PM, Ryan Schmidt <ryandes...@macports.org> wrote:
>> 
>>> On Dec 4, 2016, at 10:49, Lawrence Velázquez <lar...@macports.org> wrote:
>>> 
>>> The checking script only mentions BSD (3-clause) and BSD-old
>>> (4-clause).
>> 
>> As far as I was aware, we were referring to all three versions of the
>> BSD licensee as "BSD". Is there a reason to do otherwise?
> 
> At a minimum, the 4-clause license must be distinguished as "BSD-old"
> because it is not compatible with the GPL.

Oh right. That's what we do. I remember now.

> If we've already been referring to the 2-clause license as "BSD", it's
> probably fine (from a practical standpoint) to continue doing so,
> although the ambiguity doesn't sit well with me.

IMHO it's dumb that they don't assign version numbers to their license versions.

Re: [MacPorts] Migration modified

[Ryan Schmidt]

> On Dec 28, 2016, at 17:54, MacPorts  wrote:
> 
> Page "Migration" was changed by adfernandes
> Diff URL: 
> Revision 98
> Comment: Add a 'troubleshooting' note for when the restore uses too many open 
> files.
> Changes:
> ---8<--8<--8<--8<--8<--8<--8<--8<
> Index: Migration
> =
> --- Migration (version: 97)
> +++ Migration (version: 98)
> @@ -67,3 +67,9 @@
> sudo port install portname +variant1 +variant2 …
> }}}
> Note that if you have specified variants which are not the default, you may 
> need to install ports in an order other than the alphabetical order recorded 
> in `myports.txt`. You may skip explicitly installing ports that you did not 
> request as long as they are not using non-default variants, since they will 
> be installed as dependencies of other ports.
> +
> +Another potential problem is that the `restore_ports.tcl` command may fail 
> with a `Too many open files` error message. Under macOS Sierra, the default 
> shell has a default `ulimit` of 256 open files. The solution is to restore 
> the ports with a slightly modified command:
> +{{{
> +sudo bash -c "ulimit -n 4096; ./restore_ports.tcl myports.txt"
> +}}}
> +This will raise the file limit for the duration of the `restore_ports.tcl` 
> command.

This was https://trac.macports.org/ticket/50986 which will be fixed in MacPorts 
2.4.0. It looks like a simple enough fix that it could probably be backported 
to the 2.3 branch if we do a 2.3.6 release.

Re: rsync server out of date?

[Ryan Schmidt]

On Dec 31, 2016, at 14:08, Ryan Schmidt wrote:

> I think we can work around the problem by checking out a fresh working copy 
> of macports-ports on the server for mprsyncup to use.

Done.

Re: [macports-ports] branch master updated: fluidsynth: new variants, maintainers

[Ryan Schmidt]

> On Dec 25, 2016, at 03:09, Mojca Miklavec  wrote:
> 
> Mojca Miklavec (mojca) pushed a commit to branch master
> in repository macports-ports.
> 
> 
> https://github.com/macports/macports-ports/commit/004674273d1ef6f7bbb6afdcc9fc4bec0a1083e0
> 
> The following commit(s) were added to refs/heads/master by this push:
> 
>  new 0046742  fluidsynth: new variants, maintainers
> 
> 0046742 is described below
> 
> 
> commit 004674273d1ef6f7bbb6afdcc9fc4bec0a1083e0
> 

> * sourceforge:
>   * master_sites seems to work without an explicit path


> -master_sitessourceforge:project/${name}/${name}-${version}
> +master_sitessourceforge


This change should be undone. The path was there for this reason:

https://trac.macports.org/wiki/howto/AvoidRedirects

Re: [macports-ports] branch master updated: synergy: update to v1.8.5; fixes build on Sierra

[Ryan Schmidt]

> On Dec 6, 2016, at 21:21, Dan Ports  wrote:
> 
> Dan Ports (drkp) pushed a commit to branch master
> in repository macports-ports.
> 
> 
> https://github.com/macports/macports-ports/commit/06a980089ff2cecaefbd42b19e44dd67b0b0a54c
> 
> The following commit(s) were added to refs/heads/master by this push:
> 
>  new 06a9800  synergy: update to v1.8.5; fixes build on Sierra
> 
> 06a9800 is described below
> 
> 
> commit 06a980089ff2cecaefbd42b19e44dd67b0b0a54c
> 
> Author: Dan R. K. Ports 
> AuthorDate: Tue Dec 6 19:20:18 2016 -0800
> 
> 
> synergy: update to v1.8.5; fixes build on Sierra


> -github.setupsynergy synergy 1.6.3
> +github.setupsymless synergy 1.8.5-stable v

Users should see the port version number as "1.8.5" not "1.8.5-stable". 

Re: rsync server out of date?

[Ryan Schmidt]

On Dec 31, 2016, at 13:31, Ryan Schmidt wrote:

> Starting on 12/28, mprsyncup is unable to update the Subversion working copy 
> of the macports-ports git repository:
> 
> 
> 2016-12-28T11:28:40-0600 + PORTS_OLD_REV=131029
> 2016-12-28T11:28:40-0600 + /opt/local/bin/svn --non-interactive -q update 
> /var/tmp/mprsyncup/release/ports
> 2016-12-28T11:30:49-0600 svn: E175002: Unexpected HTTP status 502 'Bad 
> Gateway' on '/macports/macports-ports.git/!svn/vcc/default'
> 
> 
> 2016-12-28T12:01:02-0600 + PORTS_OLD_REV=131029
> 2016-12-28T12:01:02-0600 + /opt/local/bin/svn --non-interactive -q update 
> /var/tmp/mprsyncup/release/ports
> 2016-12-28T12:03:18-0600 svn: E175002: Unexpected HTTP status 504 'Gateway 
> Timeout' on '/macports/macports-ports.git/!svn/vcc/default'


r131038 is the revision in which $Id$ lines were removed from all remaining 
9292 ports. Seems like the GitHub git-to-svn gateway is not able to handle a 
change that large. I have reported that problem to the GitHub support team.

I think we can work around the problem by checking out a fresh working copy of 
macports-ports on the server for mprsyncup to use.

I imagine we can avoid the problem in the future by not modifying that many 
files at once.

Re: rsync server out of date?

[Ryan Schmidt]

> On Dec 31, 2016, at 06:45, Clemens Lang  wrote:
> 
> Hi,
> 
> On Fri, Dec 30, 2016 at 11:13:21PM -0700, Marcus Calhoun-Lopez wrote:
>> I just ran `port sync`, but the ports are several days behind the
>> GitHub repository. I have never encountered this before and am at a
>> bit of a loss as to how to proceed. Is anyone else having this
>> problem?
> 
> Can confirm, my cronjob has been telling me for two days now. The last
> update to ports.tar was at 2016-12-28 17:57:54.0 +0100.
> 
> Ryan, can you check what's wrong?

Starting on 12/28, mprsyncup is unable to update the Subversion working copy of 
the macports-ports git repository:


2016-12-28T11:28:40-0600 + PORTS_OLD_REV=131029
2016-12-28T11:28:40-0600 + /opt/local/bin/svn --non-interactive -q update 
/var/tmp/mprsyncup/release/ports
2016-12-28T11:30:49-0600 svn: E175002: Unexpected HTTP status 502 'Bad Gateway' 
on '/macports/macports-ports.git/!svn/vcc/default'


2016-12-28T12:01:02-0600 + PORTS_OLD_REV=131029
2016-12-28T12:01:02-0600 + /opt/local/bin/svn --non-interactive -q update 
/var/tmp/mprsyncup/release/ports
2016-12-28T12:03:18-0600 svn: E175002: Unexpected HTTP status 504 'Gateway 
Timeout' on '/macports/macports-ports.git/!svn/vcc/default'

Re: adding a supported compiler

[Ryan Schmidt]

> On Jan 7, 2017, at 05:23, René J.V. Bertin  wrote:
> 
> Morning!
> 
> I've created a port for clazy (https://github.com/KDE/clazy) which provides 
> an additional layer of code analysis on top of what clang already can do.
> 
> This is a compiler wrapper, so it can be used in a normal build cycle to get 
> additional diagnostics while building code. I'd like to be able therefore to 
> do something like `configure.compiler=clazy-3.9` for certain of my projects, 
> at least locally.
> 
> Where would I make the necessary changes to make that possible?

portconfigure.tcl

Re: Tickets affecting multiple ports and committers & "annoying" commits

[Ryan Schmidt]

> On Dec 11, 2016, at 12:13 PM, Mojca Miklavec  wrote:
> 
> Hi,
> 
> After some cool features have been enabled on Trac, in particular the
> "See:" and "Closes:" syntax that automatically adds a comment, I
> wonder what to do with tickets that affect many ports and maintainers.

I would prefer to avoid such tickets as much as possible.

> Examples include tickets like "replace no_x11 with x11", "switch to
> perl5.26", ...
>https://trac.macports.org/ticket/39383
> etc.

I agree those are the types of tickets where it is necessary to list many ports.

> If we subscribe 100 maintainers with 100 ports, each maintainer will
> receive an email every time any port gets fixed.

We should not make / allow each maintainer to fix their own port for this 
issue. There should be a single pull request that makes the correct fix for all 
ports. Maintainers can be given an amount of time to voice objections to the 
change. After objections have been dealt with and the time expires, the pull 
request can be merged as one commit which will generate just one notification.

> Some time ago we had a volunteer who kept following the commit logs
> and modified just his own comment. But now it would be nice to have a
> better solution.
> 
> Just about the only thing that comes to my mind is a checkbox on each
> ticket that stops sending emails on each commit while keeping sending
> emails when writing other comments. Not that I particularly like that
> option either.
> 
> Any ideas?
> 
> Mojca

Re: [macports-ports] branch master updated: grass: jump to 7.2RC2 (dubbed 7.1.99.2)

[Ryan Schmidt]

> On Dec 21, 2016, at 06:22, Vincent  wrote:
> 
> Vincent (Veence) pushed a commit to branch master
> in repository macports-ports.
> 
> 
> https://github.com/macports/macports-ports/commit/6879a39dde564230f06179065fe1afeeed8a8175
> 
> The following commit(s) were added to refs/heads/master by this push:
> 
>  new 6879a39  grass: jump to 7.2RC2 (dubbed 7.1.99.2)
> 
> 6879a39 is described below
> 
> 
> commit 6879a39dde564230f06179065fe1afeeed8a8175
> 
> Author: Veence 
> AuthorDate: Wed Dec 21 13:21:52 2016 +0100
> 
> 
> grass: jump to 7.2RC2 (dubbed 7.1.99.2)

Does upstream also refer to 7.2.0RC2 as 7.1.99.2, or is that something you made 
up? If the latter, why?


> ---
>  gis/grass7/Portfile | 13 +++--
>  1 file changed, 7 insertions(+), 6 deletions(-)
> 
> 
> diff --git a/gis/grass7/Portfile b/gis/grass7/Portfile
> 
> index aee1356..de6ab69 100644
> 
> --- a/gis/grass7/Portfile
> 
> +++ b/gis/grass7/Portfile
> 
> @@ -5,9 +5,10 @@ PortGroup wxWidgets 1.0
> 
>  PortGroup active_variants 1.1
>  
>  name  grass7
> 
> -version   7.0.5
> 
> -revision  1
> 
> -distname  grass-${version}
> 
> +version   7.1.99.2
> 
> +set realVersion   7.2.0RC2
> 
> +#distname grass-${version}
> 
> +distname  grass-${realVersion}
> 
>  maintainers   nomaintainer
>  categoriesgis
>  license   GPL-2+
> 
> @@ -18,10 +19,10 @@ long_description  GRASS is a Geographic Information 
> System (GIS) used for \
> 
>geospatial data management and analysis.
>  
>  homepage  http://grass.osgeo.org/
> 
> -master_sites  ${homepage}grass[join [lrange [split ${version} .] 0 1] 
> {}]/source/
> 
> +master_sites  ${homepage}grass[join [lrange [split ${realVersion} .] 0 
> 1] {}]/source/
> 
>  
> 
> -checksums   rmd160  1299a553e081f3cae06f0b4bad958a0901ee63f1 \
> 
> -sha256  
> 60de3ba67eaf4f05dcff4f48ef710113f9efa9367ece784c13423bc620246f3c
> 
> +checksums rmd160  64064bb4a62ad59120f08587d69fc5a31d96afcc \
> 
> +  sha256  
> bd75cdc9a7b541d1bc72acc6d43ea35c7a6a4c2767c771a7a03a623b345037f3
> 
>  
>  wxWidgets.use wxPython-3.0
>  
> 
> 

Re: [macports-ports] branch master updated: ocaml-zarith: update to 1.4.1

[Ryan Schmidt]

> On Dec 20, 2016, at 20:00, Kurt Hindenburg  wrote:
> 
> Kurt Hindenburg (kurthindenburg) pushed a commit to branch master
> in repository macports-ports.
> 
> 
> https://github.com/macports/macports-ports/commit/ae81c668093b56cc220726e69154fa6f73e23f2d
> 
> The following commit(s) were added to refs/heads/master by this push:
> 
>  new ae81c66  ocaml-zarith: update to 1.4.1
> 
> ae81c66 is described below
> 
> 
> commit ae81c668093b56cc220726e69154fa6f73e23f2d
> 
> Author: Kurt Hindenburg 
> AuthorDate: Tue Dec 20 21:00:13 2016 -0500
> 
> 
> ocaml-zarith: update to 1.4.1
> 
> 
> 
> closes https://trac.macports.org/ticket/51991


> @@ -42,7 +40,9 @@ post-destroot {
> 
>  }
>  
>  test.runyes
> 
> -test.cmdmake test && ./test
> 
> +test.cmdmake test
> 
> +test.dir${worksrcpath}/tests
> 
> +test.target

The default value for test.cmd is the path to the make program, and the default 
value for test.target is test, so you should remove the test.cmd and 
test.target lines to use the defaults.

Re: [macports-ports] branch master updated: gdal-grass: bump to 2.1.0

[Ryan Schmidt]

> On Dec 27, 2016, at 10:21, Vincent  wrote:
> 
> Vincent (Veence) pushed a commit to branch master
> in repository macports-ports.
> 
> 
> https://github.com/macports/macports-ports/commit/d0a0af40d314aebd3bbfe68ebc8d43a52ce7ff35
> 
> The following commit(s) were added to refs/heads/master by this push:
> 
>  new d0a0af4  gdal-grass: bump to 2.1.0


> +variant postgresql96 conflicts postgresql95 {
> +  configure.args-append  
> --with-postgres-includes=${prefix}/include/postgresql96
> +}
> +
> +variant postgresql95 conflicts postgresql96 {
> +  configure.args-append  
> --with-postgres-includes=${prefix}/include/postgresql95
> +}

The postgresql95 and postgresql96 don't appear to add a dependency on the 
corresponding postgresql port.

The MacPorts whitespace style is for indentations to be multiples of 4 spaces. 
Please fix the modeline and the whitespace in the postgresql95 and postgresql96 
variants.

Re: KDE4 ports not built on Sierra buildbot?

[Ryan Schmidt]

On Dec 22, 2016, at 09:51, Marko Käning  wrote:
> 
> Hi Mojca,
> 
>> On 22 Dec 2016, at 16:45 , Mojca Miklavec  wrote:
>> After the new buildbot has been set up we never started any major
>> build jobs for all packages. (There are plans to fix this, but we are
>> experiencing quite some suboptimal performance that could be fixed
>> before starting a huge build jobs.)
> 
> ah, ok.
> 
> 
>> So basically 10.5, 10.6-i386, (10.7) and 10.12 only contain binaries
>> for ports (and their dependencies) that have seen some commits since
>> August. Plus those that have been manually triggered.
> 
> That is consistent with my observations.
> 
> 
>> Do you have an account on the buildbot?
> 
> Yes. So I could just create a list of port which I know were building
> here locally so that the buildbot could create all of them as well.
> That would be about 200 ports, if that’s okay for the buildbot.

Ok but maybe wait until I've deployed a change to the master.cfg that might 
help performance. 

Re: [macports-ports] 05/08: gstreamer1-gst-plugins-bad: add missing dependency gdk-pixbuf2 and rebuild

[Ryan Schmidt]

> On Jan 5, 2017, at 17:37, 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/a6105d58f8c4fe4533918886f6abd7efb85a04fa
> 
> commit a6105d58f8c4fe4533918886f6abd7efb85a04fa
> 
> Author: David B. Evans 
> AuthorDate: Thu Jan 5 14:48:23 2017 -0800
> 
> 
> gstreamer1-gst-plugins-bad: add missing dependency gdk-pixbuf2 and rebuild


> diff --git a/gnome/gstreamer1-gst-plugins-bad/tmp 
> b/gnome/gstreamer1-gst-plugins-bad/tmp
> 
> new file mode 100644
> 
> index 000..6ac4909
> 
> --- /dev/null
> 
> +++ b/gnome/gstreamer1-gst-plugins-bad/tmp
> 
> @@ -0,0 +1,21 @@
> 
> +appstream-glib
> 
> +clutter
> 
> +cogl
> 
> +dia
> 
> +evince
> 
> +gnome-photos
> 
> +gstreamer1-gst-plugins-good
> 
> +gtk2
> 
> +gtk3
> 
> +libgdata
> 
> +libgpod
> 
> +libgsf
> 
> +libiodbc
> 
> +libmediaart
> 
> +libnotify
> 
> +libopenraw
> 
> +librsvg
> 
> +openslide
> 
> +valadoc
> 
> +xine-lib
> 
> +auto-multiple-choice
> 
> 


It looks like this tmp file should be removed.

Re: [macports-ports] branch master updated (e58232e -> af96137)

[Ryan Schmidt]

> On Jan 12, 2017, at 18:28, Marius Schamschula  wrote:
> 
> Marius Schamschula (Schamschula) pushed a change to branch master
> in repository macports-ports.
> 
>from e58232e  dependents of x265: rebuild with x265 version 2.2
> new d26e175  bro: Update to 2.5
> new 05ec788  fix hashes
> new af96137  remove revision line
> 
> The 3 revisions listed above as "new" are entirely new to this
> repository and will be described in separate emails.  The revisions
> listed as "add" were already present in the repository and have only
> been added to this reference.
> 
> 
> Summary of changes:
> net/bro/Portfile | 10 +-
> 1 file changed, 5 insertions(+), 5 deletions(-)
> 

These three changes needed to have been pushed to master as a single 
logically-consistent squashed commit.

Re: [macports-base] tag release_2_3_4 deleted (was d92ac26)

[Ryan Schmidt]

> On Jan 15, 2017, at 07:22, Rainer Müller  wrote:
> 
> Rainer Müller (raimue) pushed a change to tag release_2_3_4
> in repository macports-base.
> 
> *** WARNING: tag release_2_3_4 was deleted! ***
> 
> was d92ac26  merge https://trac.macports.org/changeset/140724 from trunk: 
>  2.3.4 release date
> 
> The revisions that were on this tag are still contained in
> other references; therefore, this change does not discard any commits
> from the repository.
> 


What happened here?

We still seem to have a "v2.3.4" tag in the repo like we should.

Re: [macports-ports] branch master updated: certbot: rename py-certbot to certbot

[Ryan Schmidt]

> On Jan 15, 2017, at 10:30, Marius Schamschula  wrote:
> 
> Marius Schamschula (Schamschula) pushed a commit to branch master
> in repository macports-ports.
> 
> 
> https://github.com/macports/macports-ports/commit/cb88f3944b1c4949168ca876d4ca4a55a93f6772
> 
> The following commit(s) were added to refs/heads/master by this push:
> 
>  new cb88f39  certbot: rename py-certbot to certbot
> 
> cb88f39 is described below
> 
> 
> commit cb88f3944b1c4949168ca876d4ca4a55a93f6772
> 
> Author: Marius Schamschula 
> AuthorDate: Sun Jan 15 10:30:37 2017 -0600
> 
> 
> certbot: rename py-certbot to certbot
> 
> 
> 
> Move from py-certbot to certbot
> 
> Simplify Portfile to only allow python 2.7, as python 3.x is not yet 
> supported
> 
> ---
>  python/py-certbot/Portfile | 42 --
>  security/certbot/Portfile  | 37 +
>  2 files changed, 41 insertions(+), 38 deletions(-)
> 
> 
> diff --git a/python/py-certbot/Portfile b/python/py-certbot/Portfile
> 
> index 4e76f00..e4b765f 100644
> 
> --- a/python/py-certbot/Portfile
> 
> +++ b/python/py-certbot/Portfile
> 
> @@ -1,46 +1,12 @@
> 
>  # -*- 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   github 1.0
> 
> -PortGroup   python 1.0
> 
>  
> 
> -github.setupcertbot certbot 0.10.1 v
> 
> +replaced_by certbot
> 
> +
> 
>  namepy-certbot

replaced_by doesn't work unless you increase the revision (or version).


Consider using the obsolete 1.0 portgroup when replacing a port. It takes care 
of several issues for you, some of which you're currently not handling:

$ port lint py-certbot
--->  Verifying Portfile for py-certbot
Error: Missing required variable: description
Error: Missing required variable: long_description
Error: Missing required variable: platforms
Error: Missing required variable: master_sites
--->  4 errors and 0 warnings found.


Not only py-certbot should be replaced; py27-certbot should also be replaced.

Re: [macports-ports] branch master updated: finance/bitcoin: update to bitcoin-core-0.14.0

[Ryan Schmidt]

> On Mar 20, 2017, at 05:54, Mark Evenson  
> wrote:
> 
> Mark Evenson (easye) pushed a commit to branch master
> in repository macports-ports.
> 
> 
> https://github.com/macports/macports-ports/commit/c9e772d7cb0f771ad2903357565071777e3450ba
> 
> The following commit(s) were added to refs/heads/master by this push:
> 
>  new c9e772d  finance/bitcoin: update to bitcoin-core-0.14.0
> 
> c9e772d is described below
> 
> 
> commit c9e772d7cb0f771ad2903357565071777e3450ba
> 
> Author: Mark  >
> AuthorDate: Mon Mar 20 11:54:45 2017 +0100
> 
> 
> finance/bitcoin: update to bitcoin-core-0.14.0
> 
> 
> 
> N.b. the qt5 gui build is broken with this update seemingly due to
> 
> problems enabling C++11 in the compiler:
> 
> 
> 
> error Qt requires a C++11 compiler and yours does not seem to be that.
> 
> 
> 
> This error occurs despite a build command which seems to be trying to use 
> C++11:

The specific compile command that elicits the error is:

/usr/bin/clang++ -DHAVE_CONFIG_H -I. -I../src/config  -U_FORTIFY_SOURCE 
-D_FORTIFY_SOURCE=2 -I. -I./obj -I/opt/local/include/db48/ -pthread 
-I/opt/local/include -I./leveldb/include -I./leveldb/helpers/memenv   
-I./secp256k1/include -I./univalue/include -I./qt -I./qt -I./qt/forms 
-I./qt/forms -DQT_NO_KEYWORDS -I/opt/local/libexec/qt5/include/QtNetwork 
-I/opt/local/libexec/qt5/include -I/opt/local/libexec/qt5/include/QtWidgets 
-I/opt/local/libexec/qt5/include -I/opt/local/libexec/qt5/include/QtGui 
-I/opt/local/libexec/qt5/include -I/opt/local/libexec/qt5/include/QtCore 
-I/opt/local/libexec/qt5/include -D_THREAD_SAFE  -I/opt/local/include 
-DHAVE_BUILD_INFO -D__STDC_FORMAT_MACROS -isystem /opt/local/include 
-I/opt/local/include/db48 -DMAC_OSX  -pipe -Os -stdlib=libc++ -arch x86_64 -MT 
qt/qt_bitcoin_qt-macdockiconhandler.o -MD -MP -MF 
qt/.deps/qt_bitcoin_qt-macdockiconhandler.Tpo -c -o 
qt/qt_bitcoin_qt-macdockiconhandler.o `test -f 'qt/macdockiconhandler.mm' || 
echo './'`qt/macdockiconhandler.mm

Note that it does not say "-std=c++11" there. Therefore clang advertises 
__cplusplus as 199711L instead of 201103L, so the qcompilerdetection.h header 
complains. Sounds like a mistake in the bitcoin build system.

Re: [macports-ports] branch master updated: youtube-dl: update master_sites

[Ryan Schmidt]

> On Mar 27, 2017, at 00:59, Zero King  wrote:
> 
> Zero King (l2dy) pushed a commit to branch master
> in repository macports-ports.
> 
> 
> https://github.com/macports/macports-ports/commit/028449c4cfaecdf2788a33919d5bfd3a4f786acd
> 
> The following commit(s) were added to refs/heads/master by this push:
> 
>  new 028449c  youtube-dl: update master_sites
> 
> 028449c is described below
> 
> 
> commit 028449c4cfaecdf2788a33919d5bfd3a4f786acd
> 
> Author: Zero King 
> AuthorDate: Mon Mar 27 05:59:33 2017 +
> 
> 
> youtube-dl: update master_sites
> 
> ---
>  net/youtube-dl/Portfile | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/net/youtube-dl/Portfile b/net/youtube-dl/Portfile
> index 253464d..8f1561f 100644
> --- a/net/youtube-dl/Portfile
> +++ b/net/youtube-dl/Portfile
> @@ -15,7 +15,7 @@ description command-line program to download videos 
> from YouTube.com and
> 
>  long_description${name} is a small ${description}.
>  
>  homepagehttp://rg3.github.com/youtube-dl/
> -master_siteshttp://youtube-dl.org/downloads/${version}
> +master_siteshttps://yt-dl.org/downloads/${version}

Doesn't look like this did anything useful. Both the old and the new URL 
redirect to the GitHub release URL.

Re: [macports-ports] 01/02: pkcs11-helper: update to 1.22, depend on pkg-config to fix trace-mode build

[Ryan Schmidt]

> On Feb 18, 2017, at 14:49, Dan Villiom Podlaski Christiansen 
>  wrote:
> 
> Dan Villiom Podlaski Christiansen (danchr) pushed a commit to branch master
> in repository macports-ports.
> 
> 
> https://github.com/macports/macports-ports/commit/7e1fe0ddffb75d7262e3e3edeed03ab18d284049
> 
> commit 7e1fe0ddffb75d7262e3e3edeed03ab18d284049
> 
> Author: Dan Villiom Podlaski Christiansen 
> AuthorDate: Tue Mar 28 16:02:25 2017 +0200
> 
> 
> pkcs11-helper: update to 1.22, depend on pkg-config to fix trace-mode 
> build
> 
> ---
>  security/pkcs11-helper/Portfile | 7 ---
>  1 file changed, 4 insertions(+), 3 deletions(-)
> 
> 
> diff --git a/security/pkcs11-helper/Portfile b/security/pkcs11-helper/Portfile
> 
> index dfad741..cecbd08 100644
> 
> --- a/security/pkcs11-helper/Portfile
> 
> +++ b/security/pkcs11-helper/Portfile
> 
> @@ -3,7 +3,7 @@
> 
>  PortSystem  1.0
>  PortGroup   github 1.0
>  
> 
> -github.setupOpenSC pkcs11-helper 1.11 pkcs11-helper-
> 
> +github.setupOpenSC pkcs11-helper 1.22 pkcs11-helper-
> 
>  categories  security
>  platforms   darwin freebsd
>  license GPL-2+ BSD
> 
> @@ -12,10 +12,11 @@ maintainers nomaintainer
> 
>  description Library that simplifies the interaction with PKCS#11 
> providers for end-user applications using a simple API and optional OpenSSL 
> engine
>  long_description${description}
>  
> 
> -checksums   rmd160  5caa2bc24a9d4d2bb12a8f45178d453de28f50a8 \
> 
> -sha256  
> ea182c014024acadbd2463b38abd9adbb2445fd4289f3dca3dbfed39a08b3f5b
> 
> +checksums   rmd160  eea8faeb337ee3793cfd75485438ff963410ce25 \
> 
> +sha256  
> 13cae76c36a00362db7328d733ce114f52e93c21f25bdba8a12af4437c4c149e
> 
>  
>  depends_lib port:gnutls \
> 
> +port:pkgconfig \
> 
>  path:lib/libssl.dylib:openssl
>  

Unless pkcs11-helper is unusual and actually uses pkgconfig at runtime, 
pkgconfig should only be a build dependency, not a library dependency.

Re: citing git commits on Trac?

[Ryan Schmidt]

> On Mar 28, 2017, at 09:23, Rainer Müller  wrote:
> 
> On 2017-03-28 15:34, Joshua Root wrote:
>> Documentation is available at .
>> 
>> I find the easiest way to link to a commit is [committish/repo], e.g.
>> [42a4d67a/macports-ports]. Apparently you need at least 8 characters of
>> the hash, which is slightly annoying since GitHub shows only 7
>> characters in many places.
> 
> Unfortunately that minimum length of 8 characters is hardcoded [1].
> Apparently this limit was chosen to avoid linking "rfc1234" [2],
> although I do not see the reason why the [revnum/repo] form must have a
> minimum length...
> 
> As an alternative, the [changeset:42a4d67a/macports-ports] syntax works
> in any case, with 7 or even fewer characters.
> 
> Rainer
> 
> [1]
> https://trac.edgewall.org/browser/trunk/trac/versioncontrol/web_ui/changeset.py?rev=15468#L1020
> [2] https://trac.edgewall.org/ticket/4261

I don't see any reason not to always list the entire 40-character hash.

[cb373533029a92cbc2a41f7cb2c2704e05311a34/macports-ports]

Git and GitHub shows the full 40-character hash in many places; it is not more 
difficult to copy and paste that.

Re: Reinplace warnings

[Ryan Schmidt]

On Mar 21, 2017, at 07:07, Craig Treleaven wrote:
> 
> 1) What happens if my port uses ‘reinplace -q …’ but the user hasn’t updated 
> to MacPorts 2.4.1?  Does the port fail or is the -q flag ignored?

With 2.4.0 it will be ignored. With earlier, an error will occur, so users 
should upgrade. 

> 2) My MythTV ports have scores of Perl and Python scripts where I need to 
> reinplace the shebang lines.  That works but the user now gets over 100 
> reinplace warnings.  As the port maintainer, I may sometimes want to see 
> those warnings to assure myself that they remain harmless.  Would it be 
> possible to have the ‘port -d ‘ flag override the ‘-q’ flag so that I can see 
> the warnings when needed?

Of course it would be possible to do that, but I think that will lead to some 
ports getting thousands of lines of reinplace warnings in their logs which I'd 
like to avoid. 

Re: buildbot: +quartz ?

[Ryan Schmidt]

> On Mar 4, 2017, at 08:10, Craig Treleaven  wrote:
> 
>> On Mar 3, 2017, at 10:26 PM, Mojca Miklavec  wrote:
>> 
>> On 4 March 2017 at 03:51, Craig Treleaven wrote:
>>> I know that we would like to find a clean solution to building ports with 
>>> non-default variants.  As an interim step, however, I wonder if we might 
>>> consider a buildbot that is configured to default to “+quartz”?
>> 
>> We don't even need a separate buildbot. Just a relatively simple
>> improvement to the existing buildbot.
>> 
>> See:
>>  https://trac.macports.org/ticket/52742
>> 
>> I suggested adding a field to allow manually specifying arbitrary
>> values for variants. But we would need some automatism as well.
>> Perhaps something like the following:
>> 
>>  If variant quartz exists, build the port once again, but this time
>> with '+quartz'
>> 
>> but covering all corner cases (when +x11 +quartz is allowed together
>> and when it is not …).
> 
> If we use the existing buildbot instances, won’t they they try to upload 
> built binaries to packages.macports.org?

Of course. Isn't that what you're asking for? If not, why not?


> In another ticket [1], you noted the problem where an indirect dependency 
> must be built with +quartz.

If a port is installed with a variant, MacPorts already correctly handles 
installing inactive dependencies with that same variant if they have that 
variant; it has for many years. (It doesn't reinstall active dependencies with 
that variant, but this won't be a problem on the buildbot because all ports are 
deactivated between builds.)

There could of course be a problem with ports that don't have a quartz variant 
that nevertheless build themselves differently depending on whether their 
dependencies are using a quartz variant or not. When we discover such problems, 
we should fix them by adding a quartz variant to such ports. And this problem 
exists whether or not we're building binary packages.


> This is why I felt a dedicated “PlusQuartz” buildbot might be a simple 
> solution that we could get running quickly.
> 
> [1] https://trac.macports.org/ticket/40294
> 
> I note that there have been tickets about this practically since the 
> buildbots were first implemented. I think it would be better to get a partial 
> solution implemented now rather than spend more years waiting for perfection. 
>  As they say: “Late answers are wrong answers."

As I recall, mpbb and our buildbot config are ready for building non-default 
variants. We just need to make a few further changes to tell portwatcher to 
schedule additional portbuilder builds with different variants, depending on 
certain criteria. We need to decide what those criteria are, then write the 
code to do that. For example, a criterion could be "if a port has a quartz 
variant, schedule another build with the quartz variant". Another useful 
criterion to help keep binaries of wine's dependencies up to date would be "if 
a port has a universal variant and a universal version of the port is currently 
installed on the buildbot, schedule another build with the universal variant".

On the other hand, nothing has been implemented for your separate quartz 
buildbot idea. You idea sounds like it would use a lot more (twice as many) 
server resources and be a lot more work to set up. I don't see any reason to go 
that route.


> Craig
> (Second attempt to send; using lists.macports.org didn’t work.)

What was the problem?

Re: [macports-ports] 02/04: cracklib: update to version 2.9.6

[Ryan Schmidt]

> On Mar 14, 2017, at 05:08, 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/050703aea8d7f54a901f5824228d7eaa3f8dd3d8
> 
> commit 050703aea8d7f54a901f5824228d7eaa3f8dd3d8
> 
> Author: David B. Evans 
> AuthorDate: Tue Mar 14 02:41:38 2017 -0700
> 
> 
> cracklib: update to version 2.9.6
> 
> 
> 
> * now uses github repo rather than sourceforge
> 
> * source files for wordlist cracklib-words are now included in this 
> distribution
> 
> * update dependencies/configuration accordingly
> 
> ---
>  security/cracklib/Portfile | 57 
> ++
>  security/cracklib/files/autogen.sh.patch   | 13 ++
>  security/cracklib/files/yosemite-libtool.patch | 12 --
>  3 files changed, 54 insertions(+), 28 deletions(-)
> 
> 
> diff --git a/security/cracklib/Portfile b/security/cracklib/Portfile
> 
> index 8718b22..1c3147b 100644
> 
> --- a/security/cracklib/Portfile
> 
> +++ b/security/cracklib/Portfile
> 
> @@ -1,10 +1,10 @@
> 
>  # -*- 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   github 1.0
> 
> +
> 
> +github.setupcracklib cracklib 2.9.6 cracklib-
> 
>  
> 
> -namecracklib
> 
> -version 2.9.5
> 
> -revision1
> 
>  categories  security
>  license LGPL-2.1
>  maintainers nomaintainer
> 
> @@ -16,26 +16,51 @@ long_descriptionCrackLib is a library containing a C 
> function (well, \
> 
>  from choosing passwords that could be guessed by \
>  Crack by filtering them out, at source.
>  
> 
> -homepagehttp://sourceforge.net/projects/cracklib/
> 
>  platforms   darwin
> 
> -depends_lib port:gettext port:zlib
> 
> -depends_build   port:cracklib-words
> 
>  
> 
> -master_sitessourceforge:project/cracklib/cracklib/${version}
> 
> +depends_build   port:autoconf \
> 
> +port:automake \
> 
> +port:libtool \
> 
> +port:bzip2


Why not use the release downloads? Wouldn't that avoid the need to autoreconf?

https://github.com/cracklib/cracklib/releases

Re: expired certificate

[Ryan Schmidt]

> On Apr 1, 2017, at 13:33, John Patrick  wrote:
> 
> think you have posted to the wrong mailing list. macosforge.org != 
> macports.org

The old MacPorts email addresses and web page URLs on macosforge.org do forward 
to macports.org. But I agree, the certificate on the old server has expired, 
and is still relevant to projects other than MacPorts, so I'll try to contact 
the right person to get it renewed.

Re: [macports-ports] branch master updated: sysutils/ansible: update to 2.2.2.0-1, close #53797

[Ryan Schmidt]

On Apr 9, 2017, at 19:41, Andrew Fernandes wrote:

> Andrew Fernandes (adfernandes) pushed a commit to branch master
> in repository macports-ports.
> 
> 
> https://github.com/macports/macports-ports/commit/717197f4a88e94d5c667c4797712d1b0daecfaf6
> 
> The following commit(s) were added to refs/heads/master by this push:
> 
>  new 717197f  sysutils/ansible: update to 2.2.2.0-1, close #53797
> 
> 717197f is described below
> 
> 
> commit 717197f4a88e94d5c667c4797712d1b0daecfaf6
> 
> Author: Andrew Fernandes 
> AuthorDate: Sun Apr 9 17:41:56 2017 -0700
> 
> 
> sysutils/ansible: update to 2.2.2.0-1, close #53797

Don't forget that "#53797" now refers to GitHub pull request #53797. To refer 
to Trac ticket #53797, use the absolute URL. To keep the first line under 50 
characters, put any references to Trac tickets after the first line, like this:


> ansible: update to 2.2.2.0-1
> 
> Closes: https://trac.macports.org/ticket/53797


Using this "Closes:" syntax will automatically close the Trac ticket and add a 
comment to it about the commit.

If you need to manually refer to a git commit in Trac, as you did in 
https://trac.macports.org/ticket/53797#comment:4, don't forget to use 
TracLinks, including the repository name (since we have more than one 
repository), for example:


> Fixed in [717197f4a88e94d5c667c4797712d1b0daecfaf6/macports-ports].

Re: [macports-ports] branch master updated: asymptote: replace python34 with python36 variant

[Ryan Schmidt]

> On Mar 9, 2017, at 13:17, Mojca Miklavec  wrote:
> 
> Mojca Miklavec (mojca) pushed a commit to branch master
> in repository macports-ports.
> 
> 
> https://github.com/macports/macports-ports/commit/defbebe639cfdf1e4ce3504568835f4e00ac5f29
> 
> The following commit(s) were added to refs/heads/master by this push:
> 
>  new defbebe  asymptote: replace python34 with python36 variant
> 
> defbebe is described below
> 
> 
> commit defbebe639cfdf1e4ce3504568835f4e00ac5f29
> 
> Author: Mojca Miklavec 
> AuthorDate: Thu Mar 9 20:14:13 2017 +0100
> 
> 
> asymptote: replace python34 with python36 variant


> -if {![variant_isset python27] && ![variant_isset python34]} {
> +if {![variant_isset python27] && ![variant_isset python36]} {
>  default_variants +python35
>  }

Should python36 be the default now? It's the latest stable version.

Re: [macports-ports] branch master updated: nginx: Add headers_more module support

[Ryan Schmidt]

On Apr 10, 2017, at 05:57, Clemens Lang wrote:

> 
>> In this situation, it would be better to use GitHub's older tarball URLs 
>> which
>> can accept any filename, such as one that includes the name of the module. 
>> See
>> for example my patch to add the fancyindex module here:
>> 
>> https://trac.macports.org/ticket/52103
> 
> Thanks for the idea, but rather than fixing this, I'd rather move to separate
> ports per module.

That would be great! Glad to hear nginx supports this now. Hope the modules 
catch up eventually.

Re: [macports-ports] branch master updated: nginx: Add headers_more module support

[Ryan Schmidt]

> On Apr 8, 2017, at 11:49, Clemens Lang  wrote:
> 
> Clemens Lang (neverpanic) pushed a commit to branch master
> in repository macports-ports.
> 
> 
> https://github.com/macports/macports-ports/commit/5fb6ff652be2ee1655d41ed7891c7ead70c593cd
> 
> The following commit(s) were added to refs/heads/master by this push:
> 
>  new 5fb6ff6  nginx: Add headers_more module support
> 
> 5fb6ff6 is described below
> 
> 
> commit 5fb6ff652be2ee1655d41ed7891c7ead70c593cd
> 
> Author: Clemens Lang 
> AuthorDate: Sat Apr 8 18:49:03 2017 +0200
> 
> nginx: Add headers_more module support
> 
> Patch by Jeffrey Goldberg.
> 
> ---
>  www/nginx/Portfile | 16 +++-
>  1 file changed, 15 insertions(+), 1 deletion(-)
> 
> diff --git a/www/nginx/Portfile b/www/nginx/Portfile
> index 7ec04d9..53fea26 100644
> --- a/www/nginx/Portfile
> +++ b/www/nginx/Portfile
> @@ -29,7 +29,8 @@ master_siteshttp://nginx.org/download:nginx \
>  
> https://github.com/arut/nginx-rtmp-module/archive/:rtmp_module \
>  https://github.com/slact/nchan/archive/:http_push_module 
> \
>  
> https://github.com/simpl/ngx_devel_kit/archive/:devel_kit_module \
> -
> https://github.com/openresty/lua-nginx-module/archive/:lua_module
> +
> https://github.com/openresty/lua-nginx-module/archive/:lua_module \
> +
> https://github.com/openresty/headers-more-nginx-module/archive/:h_more_module
>  
>  distfiles   ${name}-${version}${extract.suffix}:nginx
>  checksums   ${name}-${version}${extract.suffix} \
> @@ -384,6 +385,19 @@ variant lua requires devel_kit description {Enable Lua 
> module (https://github.co
>  }
>  }
>  
> +variant headers_more description {Enable headers-more module 
> (https://github.com/openresty/headers-more-nginx-module)} {
> +set ngx_h_more_filename   headers-more-nginx-module
> +set ngx_h_more_version0.32
> +set ngx_h_more_distname   ${ngx_h_more_filename}-${ngx_h_more_version}
> +distfiles-append  v${ngx_h_more_version}.tar.gz:h_more_module
> +checksums-append  v${ngx_h_more_version}.tar.gz \
> +  rmd160  
> a0fd69817659321c2d51d9143de413e43cb049b4 \
> +  sha256  
> c6d9dab8ea1fc997031007e2e8f47cced01417e203cd88d53a9fe9f6ae138720
> +
> +configure.args-append --add-module=${workpath}/${ngx_h_more_distname}
> +}

Using GitHub archive URLs in this context is not optimal, because the filename 
only contains the module's version number. This will only keep working until 
one of the modules has a version number that one of the other modules has had 
in the past.

In this situation, it would be better to use GitHub's older tarball URLs which 
can accept any filename, such as one that includes the name of the module. See 
for example my patch to add the fancyindex module here:

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

More generally, the method of adding modules to nginx sucks. They should be 
separate ports, not modules. I am guessing nginx doesn't support that. Have you 
ever discussed this with the developers of nginx?

Re: [macports-ports] branch master updated: New port: pgbadger

[Ryan Schmidt]

> On Apr 21, 2017, at 12:25, Eric Hall  wrote:
> 
> ghosthound pushed a commit to branch master
> in repository macports-ports.
> 
> 
> https://github.com/macports/macports-ports/commit/71033af1f4162235c6971ee899fd507f81bf9f48
> 
> The following commit(s) were added to refs/heads/master by this push:
> 
>  new 71033af  New port: pgbadger
> 
> 71033af is described below
> 
> 
> commit 71033af1f4162235c6971ee899fd507f81bf9f48
> 
> Author: Eric Hall 
> AuthorDate: Fri Apr 21 10:25:40 2017 -0700
> 
> 
> New port: pgbadger
> 
> ---
>  databases/pgbadger/Portfile | 49 
> +
>  1 file changed, 49 insertions(+)
> 
> 
> diff --git a/databases/pgbadger/Portfile b/databases/pgbadger/Portfile
> 
> new file mode 100644
> 
> index 000..f600d69
> 
> --- /dev/null
> 
> +++ b/databases/pgbadger/Portfile
> 
> @@ -0,0 +1,49 @@
> 
> +# -*- coding: utf-8; mode: tcl; tab-width: 4; indent-tabs-mode: nil; 
> c-basic-offset: 4; truncate-lines: t -*- vim:fenc=utf-8:et:sw=4:ts=4:sts=4
> 
> +
> 
> +PortSystem  1.0
> 
> +PortGroup   github 1.0
> 
> +PortGroup   perl5 1.0
> 
> +
> 
> +namepgbadger
> 
> +
> 
> +github.setupdalibo ${name} 9.1

Correct usage of the github portgroup is:

github.setup dalibo pgbadger 9.1 v

No need for a separate name line.


> +revision0
> 
> +
> 
> +categories  databases
> 
> +maintainers nomaintainer
> 
> +description PostgreSQL log analyzer with fully detailed reports and 
> graphs.
> 
> +long_descriptionpgBadger is a PostgreSQL log analyzer built for speed 
> with fully reports \
> 
> +from your PostgreSQL log file. It's a single and small 
> Perl script that \
> 
> +outperforms any other PostgreSQL log analyzer.
> 
> +
> 
> +platforms   darwin
> 
> +license BSD
> 
> +
> 
> +homepagehttp://dalibo.github.io/${name}/
> 
> +
> 
> +## https://github.com/dalibo/pgbadger/archive/v9.1.tar.gz
> 
> +
> 
> +master_siteshttps://github.com/dalibo/${name}/archive/
> 
> +distnamev${version}
> 
> +worksrcdir  ${name}-${version}

It is not intended that you should have to override master_sites, distname or 
worksrcdir; the github portgroup handles these for you. See the comments at the 
top of the github portgroup for examples of proper usage.

There is an open ticket in the issue tracker requesting support for archive 
URLs.




> +checksums   rmd160  baad3e6497f8a8d5f52ade429bddcbdade2d661a \
> 
> +sha256  
> 2fd7166d74692cc7d87f00b37cc5c7c1c6eddf156372376d382a40f67d694011
> 
> +
> 
> +
> 
> +configure.perl  ${perl5.bin}
> 
> +perl5.branches  5.24
> 
> +
> 
> +configure {
> 
> +system -W ${worksrcpath} "${perl5.bin} Makefile.PL INSTALLDIRS='perl'"
> 
> +}
> 
> +
> 
> +
> 
> +depends_lib-append  port:perl5 \
> 
> +port:p5-text-csv_xs

It is not proper to depend on a stub port such as one whose name begins with 
"p5-". Depend instead on the specific perl version of that module that you 
want, e.g. p5.24-test-csv_xs. The same goes for the perl5 port: don't depend on 
it if you actually need a specific version of perl, as you do here because you 
need a module; depend on perl5.24 instead.



> +livecheck.type  regex
> 
> +livecheck.url   ${github.raw}/master/${name}
> 
> +livecheck.regex {VERSION\s*=\s*'([0-9\.]+)}
> 


These lines are unnecessary when the github portgroup is used correctly.

Git autostash doesn't

[Ryan Schmidt]

I don't understand why I get the error:

Please commit your changes or stash them before you merge.

when the command I'm running (via "sudo port sync") is "/opt/local/bin/git pull 
--rebase --autostash".

Why won't it automatically stash? Usually it does, but apparently not when 
there are conflicts.

Re: Git autostash doesn't

[Ryan Schmidt]

> On Mar 9, 2017, at 14:18, Brandon Allbery <allber...@gmail.com> wrote:
> 
> 
> On Thu, Mar 9, 2017 at 2:51 PM, Ryan Schmidt <ryandes...@macports.org> wrote:
> Why won't it automatically stash? Usually it does, but apparently not when 
> there are conflicts.
> 
> The manpage for git pull warns that --autostash has edge cases/restrictions.

I only see:

 --autostash, --no-autostash
 Before starting rebase, stash local modifications away (see git-stash(1)) 
if
 needed, and apply the stash when done.  --no-autostash is useful to 
override
 the rebase.autoStash configuration variable (see git-config(1)).

 This option is only valid when "--rebase" is used.

Re: [macports-ports] branch master updated: minio[-mc]: New ports. s3-compat client and server

[Ryan Schmidt]

> On Mar 3, 2017, at 16:38, Eric A. Borisch  wrote:
> 
> Eric A. Borisch (eborisch) pushed a commit to branch master
> in repository macports-ports.
> 
> 
> https://github.com/macports/macports-ports/commit/dd54dbf955eb6502444a66a6ee5fe782fcaa2d8a
> 
> The following commit(s) were added to refs/heads/master by this push:
> 
>  new dd54dbf  minio[-mc]: New ports. s3-compat client and server
> 

> +set goproj  github.com/minio/minio

For both minio and minio-mc, you could use the ${github.author} and 
${github.project} variables here and elsewhere in the port, to avoid repeating 
yourself, but it's not a big deal.


> +xinstall -d ${destroot}${prefix}/share/doc/${name}
> +foreach f [list README.md LICENSE NOTICE] {
> +xinstall -m 644 ${worksrcpath}/${f} \
> +${destroot}${prefix}/share/doc/${name}/
> +}

For minio and minio-mc, no need to use a loop here. xinstall can install 
multiple files in a single command, i.e.:

set docdir ${prefix}/share/doc/${subport}
xinstall -d ${destroot}${docdir}
xinstall -m 644 -W ${worksrcpath} README.md LICENSE NOTICE ${destroot}${docdir}

See https://trac.macports.org/wiki/PortfileRecipes#doc


> +notes " \
> +| If you use 'port load minio':
> +|  * after loading, view ${prefix}/var/log/minio/server.log for server info.
> +|  * Object storage in ${prefix}/var/minio. To relocate:
> +|* Copy with all (* and .*) contents to desired location.
> +|* Replace ${prefix}/var/minio with symlink to new storage.
> +|
> +| Or use 'minio server ' to run a server manually / roll your own
> +| startup system. Note './.minio/' will be created by default.
> +|
> +| See also minio-mc port for command-line interaction.
> +"

For minio, you shouldn't use pipes or other ASCII art that would make your 
port's notes look different from other ports' notes. Just write the paragraphs 
you want port to print; port will word wrap them to the terminal's width. 
(Using asterisks as bullets are fine.)

Re: buildbot: +quartz ?

[Ryan Schmidt]

On Mar 3, 2017, at 20:51, Craig Treleaven wrote:

> (Second attempt to send; copying lists.macosforge.org address)

You don't need to do that. Just write to lists.macports.org. If you forget and 
write to the old lists.macosforge.org address instead, it will forward to 
lists.macports.org, provided you don't use SPF.

Re: [macports-ports] 03/04: textproc/terminal_markdown_viewer: new port

[Ryan Schmidt]

> On Mar 4, 2017, at 07:09, Aljaž Srebrnič  wrote:
> 
> Aljaž Srebrnič (g5pw) pushed a commit to branch master
> in repository macports-ports.
> 
> 
> https://github.com/macports/macports-ports/commit/f807864e8533c48c999bd8fcaa5451aa64dc5a07
> 
> commit f807864e8533c48c999bd8fcaa5451aa64dc5a07
> 
> Author: Aljaž "g5pw" Srebrnič 
> AuthorDate: Sat Mar 4 13:17:05 2017 +0100
> 
> 
> textproc/terminal_markdown_viewer: new port
> 
> 
> 
> Closes: https://trac.macports.org/ticket/53591


> +license BSD-3-Clause

So far, we have only referred to this (and the 2-clause version) as "BSD". 
Referring to it by this other name causes it not to be distributable:

$ ~/macports/macports-infrastructure/jobs/port_binary_distributable.tcl -v 
terminal_markdown_viewer
"terminal_markdown_viewer" is not distributable because its license 
"bsd-3-clause" is not known to be distributable

If we are going to change how we refer to the BSD license in MacPorts, then we 
would have to update that script, and change the thousands of ports under that 
license. So maybe it's simpler to just continue to say "license BSD" in this 
port instead.

Re: [macports-ports] 03/04: textproc/terminal_markdown_viewer: new port

[Ryan Schmidt]

> On Mar 4, 2017, at 07:41, Joshua Root <j...@macports.org> wrote:
> 
> On 2017-3-5 00:24 , Ryan Schmidt wrote:
>> 
>>> On Mar 4, 2017, at 07:22, Aljaž Srebrnič <g...@macports.org> wrote:
>>> 
>>> Well, yeah, they should be both distributable, so there’s no need to treat 
>>> them separately. I’ll update the license momentarily. There should be no 
>>> need to update the revision, right?
>> 
>> There should be no need to update the revision, however the buildbot will 
>> not distribute the archives until the revision or version changes; this is a 
>> bug tracked at https://trac.macports.org/ticket/53548 and was supposed to be 
>> fixed but the fix apparently doesn't work.
> 
> Have you actually tried it lately?
> 

I just did and it worked fine.

https://build.macports.org/builders/ports-10.6_i386_legacy-watcher/builds/5130

Re: [macports-ports] 03/04: textproc/terminal_markdown_viewer: new port

[Ryan Schmidt]

> On Mar 4, 2017, at 07:22, Aljaž Srebrnič <g...@macports.org> wrote:
> 
>> On 04 mar 2017, at 14:17, Ryan Schmidt <ryandes...@macports.org> wrote:
>> 
>>> 
>>> On Mar 4, 2017, at 07:09, Aljaž Srebrnič <g...@macports.org> wrote:
>>> 
>>> Aljaž Srebrnič (g5pw) pushed a commit to branch master
>>> in repository macports-ports.
>>> 
>>> 
>>> https://github.com/macports/macports-ports/commit/f807864e8533c48c999bd8fcaa5451aa64dc5a07
>>> 
>>> commit f807864e8533c48c999bd8fcaa5451aa64dc5a07
>>> 
>>> Author: Aljaž "g5pw" Srebrnič <g...@macports.org>
>>> AuthorDate: Sat Mar 4 13:17:05 2017 +0100
>>> 
>>> 
>>>   textproc/terminal_markdown_viewer: new port
>>> 
>>> 
>>> 
>>>   Closes: https://trac.macports.org/ticket/53591
>> 
>> 
>>> +license BSD-3-Clause
>> 
>> So far, we have only referred to this (and the 2-clause version) as "BSD". 
>> Referring to it by this other name causes it not to be distributable:
>> 
>> $ ~/macports/macports-infrastructure/jobs/port_binary_distributable.tcl -v 
>> terminal_markdown_viewer
>> "terminal_markdown_viewer" is not distributable because its license 
>> "bsd-3-clause" is not known to be distributable
>> 
>> If we are going to change how we refer to the BSD license in MacPorts, then 
>> we would have to update that script, and change the thousands of ports under 
>> that license. So maybe it's simpler to just continue to say "license BSD" in 
>> this port instead.
> 
> Well, yeah, they should be both distributable, so there’s no need to treat 
> them separately. I’ll update the license momentarily. There should be no need 
> to update the revision, right?

There should be no need to update the revision, however the buildbot will not 
distribute the archives until the revision or version changes; this is a bug 
tracked at https://trac.macports.org/ticket/53548 and was supposed to be fixed 
but the fix apparently doesn't work.

Re: Security Ticket Keyword

[Ryan Schmidt]

On Mar 6, 2017, at 08:41, Zero King wrote:

> Do we have a way to mark tickets fixing security vulnerabilities?

I have no objection to adding a "security" keyword to such Trac tickets. 
Someone looking through the issue tracker for updates that could be committed 
might be more likely to pick a ticket to work on if it would resolve a security 
issue.