Re: [macports-ports] branch master updated: berkeleygw: Remove svn $Id$ line.

[David Strubbe]

I just wanted to try out the new git setup to make sure things were working
for me, and this was a simple little thing to do.

On Mon, Oct 31, 2016 at 7:10 PM, Brandon Allbery 
wrote:

>
> On Mon, Oct 31, 2016 at 10:05 PM, Lawrence Velázquez 
> wrote:
>
>> new 8ed388e berkeleygw: Remove svn $Id$ line.
>
>
> btw, given that it's not being automated because of the unnecessary builds
> it would trigger, I would say don't bother making commits that *only*
> remove the Id line. It's not harmful; it's just irrelevant with git. Just
> remember to remove the line as part of the next update you make.
>
> --
> brandon s allbery kf8nh   sine nomine
> associates
> allber...@gmail.com
> ballb...@sinenomine.net
> unix, openafs, kerberos, infrastructure, xmonad
> http://sinenomine.net
>
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [macports-ports] branch master updated: berkeleygw: Remove svn $Id$ line.

[David Strubbe]

Thanks, yes I just realized I hadn't set that up.

David

On Mon, Oct 31, 2016 at 7:05 PM, Lawrence Velázquez 
wrote:

> You should set your repository's user.email to your MacPorts email address.
>
> vq
>
> On Oct 31, 2016, at 9:50 PM, dstrubbe 
> wrote:
>
> dstrubbe pushed a commit to branch master
> in repository macports-ports.
>
>
> https://github.com/macports/macports-ports/commit/
> 8ed388e541ce01d92d698791fefd72a4bd2448c9
>
> The following commit(s) were added to refs/heads/master by this push: new 
> 8ed388e  berkeleygw: Remove svn $Id$ line.8ed388e is described below
> commit 8ed388e541ce01d92d698791fefd72a4bd2448c9Author: David Strubbe 
> 
> AuthorDate: Mon Oct 31 18:48:04 2016 -0700
> berkeleygw: Remove svn $Id$ line.---
>  science/berkeleygw/Portfile | 1 -
>  1 file changed, 1 deletion(-)
> diff --git a/science/berkeleygw/Portfile b/science/berkeleygw/Portfileindex 
> 0a82359..9f495ea 100644--- a/science/berkeleygw/Portfile+++ 
> b/science/berkeleygw/Portfile@@ -1,5 +1,4 @@ # -*- coding: utf-8; mode: tcl; 
> tab-width: 4; indent-tabs-mode: nil; c-basic-offset: 4 -*- 
> vim:fenc=utf-8:ft=tcl:et:sw=4:ts=4:sts=4-# $Id$
>  PortSystem  1.0
>  PortGroup   mpi 1.0
>
> ___
> macports-changes mailing list
> macports-chan...@lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/macports-changes
>
>
>
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: nested port upgrading and variants

[David Strubbe]

I agree with you about what should happen. I just wanted to clarify that
the active_variants portgroup doesn't make that happen, and probably cannot
-- this is a base issue.

On Thu, Oct 27, 2016 at 11:28 AM, René J.V. Bertin 
wrote:

> On Thursday October 27 2016 11:12:10 David Strubbe wrote:
>
> Hi David,
>
>
> >used for a dependency. That's all it does. The only way I know of that you
> >could make opencv get installed with +qt5 in this context is to do "port
> >install kf5-digikam-devel +qt5" (whether that is a meaningful variant for
> >kf5-digikam-devel or not).
>
> That's what I told Marko too, but we're not talking here about the initial
> installation. I think that when you already have opencv+qt5+opencv
> installed, an automatic upgrade to opencv should behave like `port upgrade
> opencv`. IOW, it should maintain the active variants. Anything else is a
> waste of time and source of frustration.
>
> R.
>
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: nested port upgrading and variants

[David Strubbe]

Hi René,

The purpose of the active_variants portgroup is to provide error messages
like the one you mentioned, after checking whether a certain variant was
used for a dependency. That's all it does. The only way I know of that you
could make opencv get installed with +qt5 in this context is to do "port
install kf5-digikam-devel +qt5" (whether that is a meaningful variant for
kf5-digikam-devel or not).

David

On Thu, Oct 27, 2016 at 3:15 AM, René J.V. Bertin 
wrote:

> Hi,
>
> Marko tells me he's been having issues with upgrading one of my KF5 ports
> that uses the active_variants portgroup to "depend" on variants of one of
> its dependencies.
>
> From our exchange:
>
> > > >> BUT that’s not all yet. Once also needs to select the +contrib
> variant,
> > > >> otherwise you have to run another loop of building this port!
> Annoying
> > > >> is
> > > >> the word. What’s the reason for this odd behaviour?
> > > >
> > > > There's little I can do about that. digiKam needs +qt5 (evidently)
> but
> > > > also +contrib. The only way to increase the chance that opencv is
> > > > installed with those variants by default is to add the variants to
> > > > digikam, but that doesn't make a lot of sense. This is due to the
> fact
> > > > that ports cannot depend on the variants of another port (unless they
> > > > have the same variant, but that's propagation, not dependance). They
> > > > can only raise an error if they detect that a dependency is installed
> > > > with the wrong variant(s).
>
> In short: digikam needs port:opencv with +qt5+contrib. I try to impose
> that using
>
> {{{
> PortGroup   active_variants 1.1
>
> depends_lib-append  port:opencv
> require_active_variants opencv qt5
> require_active_variants opencv contrib
> }}}
>
> From what I understand, Marko had opencv+qt5+contrib installed and lost
> those variants when port:opencv was upgraded.
>
> I'll leave it to him to post the exact command he used for installing or
> upgrading the kf5-digikam port which led to the variant issue, I only have
> a part of the trace:
>
> {{{
> --->  Fetching archive for opencv
> --->  Attempting to fetch opencv-3.1.0_4.darwin_15.x86_64.tbz2 from
> http://nue.de.packages.macports.org/opencv
> --->  Attempting to fetch opencv-3.1.0_4.darwin_15.x86_64.tbz2 from
> https://packages.macports.org/opencv
> --->  Attempting to fetch opencv-3.1.0_4.darwin_15.x86_64.tbz2 from
> http://lil.fr.packages.macports.org/opencv
> --->  Fetching distfiles for opencv
> --->  Verifying checksums for opencv
> --->  Extracting opencv
> --->  Applying patches to opencv
> --->  Configuring opencv
> --->  Building opencv
> --->  Staging opencv into destroot
> --->  Installing opencv @3.1.0_4
> --->  Activating opencv @3.1.0_4
> --->  Cleaning opencv
> --->  Fetching archive for kf5-digikam-devel
> Error: org.macports.archivefetch for port kf5-digikam-devel returned:
> opencv must be installed with +qt5.
> Please see the log file for port kf5-digikam-devel for details:
> /opt/local/var/macports/logs/_Users_marko_WC_GIT_macstrop_
> kf5_kf5-digikam/kf5-digikam-devel/main.log
> }}}
>
> is there something wrong in my way of declaring the variant dependency, or
> is this to be expected?
>
> Thanks,
> René
> ___
> macports-dev mailing list
> macports-dev@lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/macports-dev
>
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [154019] trunk/dports/science/LORENE

[David Strubbe]

Also the last line is misspelled, I think you mean "place where you have
write access".

On Wed, Oct 19, 2016 at 7:35 PM, Ryan Schmidt 
wrote:

>
> > On Oct 18, 2016, at 7:01 AM, thib...@macports.org wrote:
> >
> > Revision
> > 154019
> > Author
> > thib...@macports.org
> > Date
> > 2016-10-18 05:01:47 -0700 (Tue, 18 Oct 2016)
> > Log Message
> >
> > LORENE: fix archflags in debug builds, remove -lX11 from LIB_PGPLOT, add
> usagenotes.
> > Modified Paths
> >
> >   • trunk/dports/science/LORENE/Portfile
> >   • trunk/dports/science/LORENE/files/local_settings
>
>
> > +notes "
> > ++--- LORENE Usage note --
> ---
> > +| To compile LORENE code, you should run:
> > +|   export HOME_LORENE=${prefix}/lib/lorene
> > +| Codes are provided in \$HOME_LORENE/Codes. To use them, copy them to
> some
> > +| place were your have write access.
> > ++--
> -
>
> I'm not in favor of ASCII art boxes in notes. Just put the text; let
> MacPorts line wrap and format it. If you believe MacPorts is not displaying
> the notes prominently enough, then making notes more prominent by using
> boxes or whatever should be done in MacPorts base, not in each individual
> port.
>
>
>
> ___
> macports-dev mailing list
> macports-dev@lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/macports-dev
>
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [153943] trunk/dports/science

[David Strubbe]

I guess the question is: is x11 definitely what pgplot should be linked
with? +x11 is an optional (though default) variant for pgplot (as below).
Is it necessary to use x11 for these LORENE codes to be compiled? For
example, what if they were to use +aquaterm?

pgplot @5.2.2_10 (graphics, devel)
Variants: aquaterm, docs, dragonegg33, dragonegg34, g95, gcc44,
gcc45, gcc46, gcc47, gcc48, gcc49, gcc5, [+]gcc6, gcc7, [+]x11

Description:  The PGPLOT Graphics Subroutine Library is a Fortran-
or C-callable, device-independent graphics package for making simple
scientific graphs. It is intended for making
  graphical images of publication quality with minimum
effort on the part of the user. For most applications, the program can be
device-independent, and the output can be
  directed to the appropriate device at run time.
Homepage: http://www.astro.caltech.edu/~tjp/pgplot/

Build Dependencies:   perl5, pkgconfig, gcc6
Library Dependencies: libpng, zlib, xorg-libX11, libgcc
Conflicts with:   miriad
Platforms:darwin
License:  Noncommercial
Maintainers:  mcalh...@macports.org, openmaintai...@macports.org


On Mon, Oct 17, 2016 at 11:38 AM, Thibaut Paumard 
wrote:

> This is correct. I will emote the dependency.
>
> Should I also remove -lX11 from LIB_PGPLOT, since libpgplot itself is
> linked with -lX11?
>
> Kind regards, Thibaut.
>
>
> Le 17 oct. 2016 à 20:12, David Strubbe  a écrit :
>
> It appears libX11, in the LIB_PGPLOT variable, is used in principle to
> compile some codes that are not in fact compiled in this package. It looks
> like X11 is only in fact used via pgplot.
>
> On Mon, Oct 17, 2016 at 10:46 AM, Ryan Schmidt 
> wrote:
>
>>
>> > On Oct 16, 2016, at 11:57 PM, David Strubbe 
>> wrote:
>> >
>> > Additionally, the dependency port:xorg-libX11 does not seem necessary:
>> I don't see any evidence in the build log that it is used, and the build
>> succeeds without it being active.
>>
>> Are you sure? libX11 is mentioned in local_settings:
>>
>>
>> > > --- trunk/dports/science/LORENE/files/local_settings
>>   (rev 0)
>> > > +++ trunk/dports/science/LORENE/files/local_settings  2016-10-16
>> 17:41:08 UTC (rev 153943)
>>
>> > > +# Graphical libraries: PGPLOT, PNG and X11
>> > > +# 
>> > > +LIB_PGPLOT = -lcpgplot -lpgplot -lX11
>>
>>
>>
>>
>
>
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [153943] trunk/dports/science

[David Strubbe]

It appears libX11, in the LIB_PGPLOT variable, is used in principle to
compile some codes that are not in fact compiled in this package. It looks
like X11 is only in fact used via pgplot.

On Mon, Oct 17, 2016 at 10:46 AM, Ryan Schmidt 
wrote:

>
> > On Oct 16, 2016, at 11:57 PM, David Strubbe 
> wrote:
> >
> > Additionally, the dependency port:xorg-libX11 does not seem necessary: I
> don't see any evidence in the build log that it is used, and the build
> succeeds without it being active.
>
> Are you sure? libX11 is mentioned in local_settings:
>
>
> > > --- trunk/dports/science/LORENE/files/local_settings
> (rev 0)
> > > +++ trunk/dports/science/LORENE/files/local_settings  2016-10-16
> 17:41:08 UTC (rev 153943)
>
> > > +# Graphical libraries: PGPLOT, PNG and X11
> > > +# 
> > > +LIB_PGPLOT = -lcpgplot -lpgplot -lX11
>
>
>
>
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: port:lapack useful?

[David Strubbe]

Hi Takeshi,

Thanks for the response.

On Mon, Oct 17, 2016 at 7:55 AM, Takeshi Enomoto 
wrote:

>
> * LAPACK from netlib is active.
>

I do not doubt that the netlib LAPACK is active -- this is of course the
reference implementation that the vendors use in optimization.


> * the man pages can be generated from LAPACK source by make man.
>

The existence of the port lapack-manpages certainly is useful to provide
these manpages, but that is separate from the lapack port, isn't it?


> * the most of the performance gain is due to BLAS, which can be obtained
> from BLAS.

* CBLAS and LAPACKE can be provided.
>

Both of these are true of the OpenBLAS port already, in fact.


> I believe that there is nothing to be harmful to leave the port.
>

Well, what do you respond to my concern: I suspect its main effect will be
to have users or port packagers use this one instead of an optimized
implementation because they do not realize the optimized ones exist, and
therefore get slower performance. Additionally, it is just confusing if we
have too many version of the same software. In what situation would you
expect someone should use this port as opposed to the other ones?


>
> The message from the upstream developer on 15 March 2016.
>
> > Dear Takeshi,
> > I am ccing Julien Langou - he is one of the PI of LAPACK and our most
> active contributor.
> > I saw your vecLibFort port - this is awesome and it was dearly needed.
> > > vecLibFort is lightweight but flexible shim designed to rectify the
> incompatibilities between the Accelerate/vecLib BLAS and LAPACK libraries
> shipped with Mac OS X and FORTRAN code compiled with modern compilers such
> as GNU Fortran.
> >
> > First, there is no real complete “optimized LAPACK” library around that
> I know if except the one's from vendors (for Example: MKL INTEL)
>

Indeed, so for Apple the vendor-optimized version is Accelerate.


> > Second, most of the performance from a LAPACK code will come from an
> Optimized BLAS library (i.e. Veclib)
>

But is there any clear reason why one needs this other combination
(Accelerate BLAS + netlib lapack) as opposed to Accelerate BLAS +
Accelerate LAPACK or OpenBLAS BLAS + netlib lapack which we already have?


> > Veclib is based on Atlas, and I did not check, but I believe the LAPACK
> included inside VecLib and vecLibFort correspond to the ATLAS LAPACK -
> which is a small subset of LAPACK library.
>

I have not noticed any LAPACK routines missing from either vecLibFort or
ATLAS. If there are in fact missing routines, then that would change the
situation -- is there any evidence about that?

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

Re: [153943] trunk/dports/science

[David Strubbe]

Additionally, the dependency port:xorg-libX11 does not seem necessary: I
don't see any evidence in the build log that it is used, and the build
succeeds without it being active.

On Sun, Oct 16, 2016 at 5:23 PM, David Strubbe 
wrote:

> Hi,
>
> Let me add a few comments.
> - The dependency for BLAS is wrong: the port OpenBLAS provides a library
> -lopenblas not -lblas. Apparently the "lapack" port includes BLAS anyway.
> To be simpler and more flexible, I suggest use of the linear algebra port
> group I created to handle all this and also provide choices of different
> optimized implementations (ATLAS, Accelerate, or OpenBLAS -- the port has
> lapack included). See patch below.
> - You are installing a lot of Makefiles and C source files -- is this on
> purpose? It is somewhat unusual.
> - You are putting everything in the lib directory. This should be reserved
> for libraries. Headers should go in include; documentation or miscellaneous
> things should go in share; etc.
> - Since there are tests apparently available, you should create a test
> phase rather than install their files, so that users can run "port test".
>
> David
>
> Index: Portfile
> ===
> --- Portfile(revision 153958)
> +++ Portfile(working copy)
> @@ -3,6 +3,7 @@
>
>  PortSystem  1.0
>  PortGroup   compilers 1.0
> +PortGroup   linear_algebra 1.0
>
>  cvs.date   20160908
>
> @@ -29,9 +30,7 @@
>  sha256  ef797abc51ed8ae27c200f5b71fd0a
> 3824d1fa310392dac57067de2e423222ed
>  worksrcdir ${distname}-${version}+dfsg
>
> -depends_libport:OpenBLAS \
> -port:lapack \
> -port:gsl \
> +depends_libport:gsl \
>  port:fftw-3 \
>  port:pgplot \
>  port:xorg-libX11
> @@ -47,6 +46,7 @@
>  reinplace -W ${worksrcpath} "s|@FFLAGS@|${configure.fflags}|g"
> local_settings
>  reinplace -W ${worksrcpath} "s|@LDFLAGS@|${configure.ldflags}|g"
> local_settings
>  reinplace -W ${worksrcpath} "s|@LIB_FORTRAN@|${compilers.libfortran}|g"
> local_settings
> +reinplace -W ${worksrcpath} "s|@LIB_LAPACK@|${linalglib}|g"
> local_settings
>  }
>
>  build.env-appendHOME_LORENE=${worksrcpath}
> Index: files/local_settings
> ===
> --- files/local_settings(revision 153958)
> +++ files/local_settings(working copy)
> @@ -74,7 +74,7 @@
>
>  # Linear Algebra Package (LAPACK) library
>  # ---
> -LIB_LAPACK = -llapack -lblas
> +LIB_LAPACK = @LIB_LAPACK
>
>  # Graphical libraries: PGPLOT, PNG and X11
>  # 
>
>
> On Sun, Oct 16, 2016 at 1:27 PM, Ryan Schmidt 
> wrote:
>
>>
>> > On Oct 16, 2016, at 12:41 PM, thib...@macports.org wrote:
>> >
>> > Revision
>> > 153943
>> > Author
>> > thib...@macports.org
>> > Date
>> > 2016-10-16 10:41:08 -0700 (Sun, 16 Oct 2016)
>> > Log Message
>> >
>> > New port: LORENE
>> > Added Paths
>> >
>> >   • trunk/dports/science/LORENE/
>> >   • trunk/dports/science/LORENE/Portfile
>> >   • trunk/dports/science/LORENE/files/
>> >   • trunk/dports/science/LORENE/files/local_settings
>> > Diff
>> >
>> > Added: trunk/dports/science/LORENE/Portfile (0 => 153943)
>> >
>> > --- trunk/dports/science/LORENE/Portfile
>> (rev 0)
>> > +++ trunk/dports/science/LORENE/Portfile  2016-10-16 17:41:08 UTC
>> (rev 153943)
>> > @@ -0,0 +1,67 @@
>> > +# -*- 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$
>>
>> The whitespace of this portfile does not conform to this modeline. Tabs
>> should be replaced with spaces.
>>
>>
>> > +PortSystem  1.0
>> > +PortGroup   compilers 1.0
>> > +
>> > +cvs.date 20160908
>> > +
>> > +name LORENE
>> > +version  0.0.0~cvs${cvs.date}
>> > +
>> > +categories   science
>> > +maintainers  thibaut openmaintainer
>> > +description  Langage Objet pour la RElativité NumériquE
>> > +long_descriptionLORENE is a set of C++ classes to solve various
>> problems \
>> &g

Re: [153943] trunk/dports/science

[David Strubbe]

Hi,

Let me add a few comments.
- The dependency for BLAS is wrong: the port OpenBLAS provides a library
-lopenblas not -lblas. Apparently the "lapack" port includes BLAS anyway.
To be simpler and more flexible, I suggest use of the linear algebra port
group I created to handle all this and also provide choices of different
optimized implementations (ATLAS, Accelerate, or OpenBLAS -- the port has
lapack included). See patch below.
- You are installing a lot of Makefiles and C source files -- is this on
purpose? It is somewhat unusual.
- You are putting everything in the lib directory. This should be reserved
for libraries. Headers should go in include; documentation or miscellaneous
things should go in share; etc.
- Since there are tests apparently available, you should create a test
phase rather than install their files, so that users can run "port test".

David

Index: Portfile
===
--- Portfile(revision 153958)
+++ Portfile(working copy)
@@ -3,6 +3,7 @@

 PortSystem  1.0
 PortGroup   compilers 1.0
+PortGroup   linear_algebra 1.0

 cvs.date   20160908

@@ -29,9 +30,7 @@
 sha256
 ef797abc51ed8ae27c200f5b71fd0a3824d1fa310392dac57067de2e423222ed
 worksrcdir ${distname}-${version}+dfsg

-depends_libport:OpenBLAS \
-port:lapack \
-port:gsl \
+depends_libport:gsl \
 port:fftw-3 \
 port:pgplot \
 port:xorg-libX11
@@ -47,6 +46,7 @@
 reinplace -W ${worksrcpath} "s|@FFLAGS@|${configure.fflags}|g"
local_settings
 reinplace -W ${worksrcpath} "s|@LDFLAGS@|${configure.ldflags}|g"
local_settings
 reinplace -W ${worksrcpath} "s|@LIB_FORTRAN@|${compilers.libfortran}|g"
local_settings
+reinplace -W ${worksrcpath} "s|@LIB_LAPACK@|${linalglib}|g"
local_settings
 }

 build.env-appendHOME_LORENE=${worksrcpath}
Index: files/local_settings
===
--- files/local_settings(revision 153958)
+++ files/local_settings(working copy)
@@ -74,7 +74,7 @@

 # Linear Algebra Package (LAPACK) library
 # ---
-LIB_LAPACK = -llapack -lblas
+LIB_LAPACK = @LIB_LAPACK

 # Graphical libraries: PGPLOT, PNG and X11
 # 


On Sun, Oct 16, 2016 at 1:27 PM, Ryan Schmidt 
wrote:

>
> > On Oct 16, 2016, at 12:41 PM, thib...@macports.org wrote:
> >
> > Revision
> > 153943
> > Author
> > thib...@macports.org
> > Date
> > 2016-10-16 10:41:08 -0700 (Sun, 16 Oct 2016)
> > Log Message
> >
> > New port: LORENE
> > Added Paths
> >
> >   • trunk/dports/science/LORENE/
> >   • trunk/dports/science/LORENE/Portfile
> >   • trunk/dports/science/LORENE/files/
> >   • trunk/dports/science/LORENE/files/local_settings
> > Diff
> >
> > Added: trunk/dports/science/LORENE/Portfile (0 => 153943)
> >
> > --- trunk/dports/science/LORENE/Portfile
> (rev 0)
> > +++ trunk/dports/science/LORENE/Portfile  2016-10-16 17:41:08 UTC
> (rev 153943)
> > @@ -0,0 +1,67 @@
> > +# -*- 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$
>
> The whitespace of this portfile does not conform to this modeline. Tabs
> should be replaced with spaces.
>
>
> > +PortSystem  1.0
> > +PortGroup   compilers 1.0
> > +
> > +cvs.date 20160908
> > +
> > +name LORENE
> > +version  0.0.0~cvs${cvs.date}
> > +
> > +categories   science
> > +maintainers  thibaut openmaintainer
> > +description  Langage Objet pour la RElativité NumériquE
> > +long_descriptionLORENE is a set of C++ classes to solve various
> problems \
> > +arising in numerical relativity, and more generally
> in \
> > +computational astrophysics. It provides tools to
> solve \
> > +partial differential equations by means of
> multi-domain \
> > +spectral methods.
> > +
> > +license gpl-2+
> > +platformsdarwin
> > +
> > +homepage http://www.lorene.obspm.fr/
> > +master_sites https://people.debian.org/~thibaut/debian/pool/main/l/
> lorene/
> > +distname lorene
> > +distfiles${distname}_${version}+dfsg.orig.tar.xz
>
> Because this is not a tar.gz file but a tar.xz file, you must use "use_xz
> yes" to tell MacPorts how to decompress it. (Mavericks (?) and later can
> figure it out automatically, but our policy is not to rely on that, and to
> specify it correctly in the Portfile.)
>
>
> > +checksums   rmd160  36346f8d7a50acee20a5b81051af2e7fe5f188c1 \
> > +sha256  ef797abc51ed8ae27c200f5b71fd0a
> 3824d1fa310392dac57067de2e423222ed
> > +worksrcdir   ${distname}-${version}+dfsg
> > 

port:lapack useful?

[David Strubbe]

Hello Takeshi,

I just noticed that you created a port lapack (including BLAS) in r146856.
Is this really useful? We already have the ATLAS port which provides BLAS
and LAPACK; the OpenBLAS port which provides exactly the same
implementation of LAPACK from netlib as your port lapack; and the built-in
Accelerate Framework and the vecLibFort port providing a Fortran interface
for it. All of these are optimized and therefore should be faster than the
straightforward netlib implementation, and use directly of
Accelerate/vecLibFort is of course by far the fastest to install. So, what
is the use of a separate port lapack? I suspect its main effect will be to
have users or port packagers use this one instead of an optimized
implementation because they do not realize the optimized ones exist. For
example, see the recent r153943. I would suggest removing it.

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

Fwd: [MacPorts] #51724: compilers-1.0: default to gcc6

[David Strubbe]

Hi all,

Ryan has proposed moving to gcc6 as the standard default version of the GCC
compiler, which would be done in the compilers portgroup. It sounds like a
good idea to me. Does anyone see a problem with that with their ports that
use the compilers portgroup? (If so, the default can always be overridden
in individual Portfiles.)

David

-- Forwarded message --
From: MacPorts 
Date: Tue, Jun 28, 2016 at 10:43 AM
Subject: Re: [MacPorts] #51724: compilers-1.0: default to gcc6
To: ryandes...@macports.org, macports-tick...@lists.macosforge.org
Cc: s...@macports.org, dstru...@macports.org


#51724: compilers-1.0: default to gcc6
---+
  Reporter:  ryandesign@…  |  Owner:  macports-tickets@…
  Type:  enhancement   | Status:  new
  Priority:  Normal|  Milestone:
 Component:  ports |Version:
Resolution:|   Keywords:
  Port:|
---+

Comment (by mf2k@…):

 I switched to gcc6 for my ports and everything appears to work. However, I
 believe such a change should be brought up on the dev list to make sure
 that no one sees a problem with this.

 {{{
 $ port installed | grep gcc
   eigen3 @3.2.8_0+gcc6 (active)
   fftw-3 @3.3.4_1+gcc6 (active)
   gcc6 @6.1.0_0 (active)
   gcc_select @0.1_8 (active)
   gsl @2.1_0+gcc6 (active)
   hdf5 @1.10.0_1+cxx+gcc6+hl (active)
   libgcc @6.1.0_0 (active)
   py27-numpy @1.11.1_0+gcc6 (active)
   py35-h5py @2.6.0_0+gcc6 (active)
   py35-numpy @1.11.1_0+gcc6 (active)
   py35-scipy @0.17.1_0+gcc6 (active)
 }}}

--
Ticket URL: 
MacPorts 
Ports system for OS X
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [149308] trunk/dports/science/paraview/Portfile

[David Strubbe]

Hi Ryan,

The +testing variant of revision 2 is equivalent to no variant at revision
1. So, yes it does have an effect, of removing quite a lot of installed
files that are unnecessary except for when testing.

David

On Sat, Jun 11, 2016 at 3:21 AM, Ryan Schmidt 
wrote:

>
> > On Jun 10, 2016, at 12:31 PM, dstru...@macports.org wrote:
> >
> > Revision
> > 149308
> > Author
> > dstru...@macports.org
> > Date
> > 2016-06-10 10:31:56 -0700 (Fri, 10 Jun 2016)
> > Log Message
> >
> > paraview: Previous commit (because of +testing) should have increased
> revision.
>
> > --- trunk/dports/science/paraview/Portfile2016-06-10 15:00:52 UTC
> (rev 149307)
> > +++ trunk/dports/science/paraview/Portfile2016-06-10 17:31:56 UTC
> (rev 149308)
> > @@ -9,7 +9,7 @@
> >
> >  nameparaview
> >  version 5.0.1
> > -revision1
> > +revision2
>
> Since the +testing variant added by the previous commit was not a default
> variant, forcing users to rebuild will do nothing; the revision should not
> have been increased (but don't change it back now).
>
>
>
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Snow Leopard compilers

[David Strubbe]

Thanks for the info, Mojca. I understand the situation now, though I would
certainly be in favor of handling this more clearly in base as you
outlined. That worked. (inevitably, it turns out clang-3.4 which was taken
instead has its own different problem on that code...)

David

On Thu, Jun 9, 2016 at 1:11 PM, Mojca Miklavec  wrote:

> On 9 June 2016 at 19:07, Mojca Miklavec wrote:
> >
> > There is probably not much interest in this issue and there is an easy
> > workaround, but I would also kind of agree that blacklisting "*gcc*"
> > should probably also blacklist clang/llvm-gcc on 10.6.
>
> Once again me ...
>
> This is probably the relevant part of the source
> (if {[string match $pattern $compiler]}):
>
>
> # internal function to determine the default compiler
> proc portconfigure::configure_get_default_compiler {} {
> if {[option compiler.whitelist] ne ""} {
> set search_list [option compiler.whitelist]
> } else {
> set search_list [option compiler.fallback]
> }
> foreach compiler $search_list {
> set allowed yes
> foreach pattern [option compiler.blacklist] {
> if {[string match $pattern $compiler]} {
> set allowed no
> break
> }
> }
>
> Should we or should we not introduce more complexity to blacklist
> "clang" with xcode < 4 (= whenever clang++ doesn't exist) when "gcc"
> is blacklisted?
>
> Mojca
>
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Snow Leopard compilers

[David Strubbe]

Hi all,

I am a bit confused about what is going on with selection of compiler on
Snow Leopard for the apbs port. It is taking clang for C but llvm-g++-4.2
for C++, and the latter does not work for this port. If clang++ were used I
think it would work. Why is that not being selected? Why is an inconsistent
pair of C and C++ being used?

Thanks,
David

In the Portfile I have

compiler.blacklist  macports-gcc-4.4 macports-gcc-4.5 macports-gcc-4.6 \
macports-dragonegg-3.3 macports-dragonegg-3.4
gcc-4.2 llvm-gcc-4.2 apple-gcc-4.2 macports-llvm-gcc-4.2

The failing buildbot output:
https://build.macports.org/builders/buildports-snowleopard-x86_64/builds/42401/steps/compile/logs/stdio

Selected parts of that:

DEBUG: Unmatched blacklisted compiler: gcc-4.2
DEBUG: Unmatched blacklisted compiler: apple-gcc-4.2
DEBUG: Unmatched blacklisted compiler: macports-llvm-gcc-4.2
...
-->  Configuring apbs
DEBUG: Using compiler 'Xcode Clang'
DEBUG: Executing proc-pre-org.macports.configure-configure-0
DEBUG: Executing proc-pre-org.macports.configure-configure-1
DEBUG: Executing proc-pre-org.macports.configure-configure-2
DEBUG: Executing proc-pre-org.macports.configure-configure-3
DEBUG: Active variants check for source-type install considers
depends_fetch depends_extract depends_lib depends_build depends_run: maloc
readline cmake
DEBUG: Executing proc-pre-org.macports.configure-configure-4
DEBUG: Executing org.macports.configure (apbs)
DEBUG: Environment:
CC='/usr/bin/clang'
CC_PRINT_OPTIONS='YES'
CC_PRINT_OPTIONS_FILE='/opt/local/var/macports/build/_opt_mports_dports_science_apbs/apbs/work/.CC_PRINT_OPTIONS'
CFLAGS='-pipe -Os'
CPATH='/opt/local/include'
CPPFLAGS='-I/opt/local/include'
CXX='/usr/bin/llvm-g++-4.2'
CXXFLAGS='-pipe -Os'
...

which leads in the build to

error: unrecognized command line option "-std=c++0x"
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Broken libgcc update

[David Strubbe]

This is reported in this ticket: https://trac.macports.org/ticket/51245

On Thu, May 5, 2016 at 12:40 PM, Marius Schamschula 
wrote:

> Hi all,
>
> Yesterday, r148332 updated libgcc and several versions of gcc. The build
> bots failed to build these ports, and now my own machines are seeing the
> same build error (failure in comparing output from two build stages).
>
> The result is that every build or update with a gcc dependency I attempt,
> will fail.
>
> Marius
> --
> Marius Schamschula
>
>
>
>
>
> ___
> macports-dev mailing list
> macports-dev@lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/macports-dev
>
>
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: variants

[David Strubbe]

On Mon, Apr 11, 2016 at 5:07 PM, Daniel J. Luke  wrote:

> On Apr 11, 2016, at 5:02 PM, David Strubbe  wrote:
> > I agree, but the question is what to do when the port does have
> variants. Consider, for example, ports with Fortran compiler variants that
> enable optional Fortran support, such as fftw-3. The current typical
> situation is that a port requiring fftw-3 with Fortran will waste time
> installing the default fftw-3 without Fortran, then give an error that it
> should have been installed with Fortran. By contrast, if the default
> variant could be passed on, fftw-3 would be installed with the needed
> Fortran support in the first place.
>
> unless fftw-3 was already installed in which case it still needs to give
> an error that it should have been installed differently.
>

Sure, that is exactly what currently does happen, and I would not propose
making any change in that respect.


>
> That would depend on how it's implemented (and what do you do if the port
> is installed with a different set of variants already? What if it's
> installed with conflicting variants?)
>

The implementation I propose is: pass on default variants like for
user-selected variants, nothing more or less. Then of course you would get
errors in the case you mention, just as you do right now.


>
> > Since the dependency engine does not consider them, that is why it would
> be very helpful to pass them down as it would solve many of the issues
> about "dependency on a variant" that are always being complained about on
> this list (such as the scenario I describe above).
>
> ... but it wouldn't be a complete solution to the problem (and there are
> other possible solutions that /would/ be).
>

Of course it's not a full solution, but this seems like a fairly simple
advance that will solve some problems.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: variants

[David Strubbe]

On Mon, Apr 11, 2016 at 4:42 PM, Daniel J. Luke  wrote:
>
> The ideal port has no variants (or at least has only default variants) -
> it builds with all reasonable options and people don't have to think about
> it.
>

I agree, but the question is what to do when the port does have variants.
Consider, for example, ports with Fortran compiler variants that enable
optional Fortran support, such as fftw-3. The current typical situation is
that a port requiring fftw-3 with Fortran will waste time installing the
default fftw-3 without Fortran, then give an error that it should have been
installed with Fortran. By contrast, if the default variant could be passed
on, fftw-3 would be installed with the needed Fortran support in the first
place.


>
> The dependency engine doesn't really handle variants - if it did, then I
> suppose it could make sense to pass default variants down.
>

I would say, on the contrary: if it did handle variants, it would be
unnecessary to pass variants down, because we would know automatically what
variants were needed. Since the dependency engine does not consider them,
that is why it would be very helpful to pass them down as it would solve
many of the issues about "dependency on a variant" that are always being
complained about on this list (such as the scenario I describe above).
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: variants

[David Strubbe]

Then maybe we could have an option to pass down default variants?

On Mon, Apr 11, 2016 at 4:09 PM, Bradley Giesbrecht 
wrote:

> On Mon, Apr 11, 2016 at 11:47 AM, Daniel J. Luke 
>  wrote:
>
>> On Apr 10, 2016, at 4:01 AM, Takeshi Enomoto 
>> wrote:
>> > If there is a reason behind treating default_variants and manually set
>> variants,
>> > I’d like to know.
>>
>> I'm not sure what the initial reasoning was, but I think the current
>> behavior is correct.
>>
>> When a port is installed as a dependency of some other port, it should be
>> installed the same way as if it were installed manually first.
>>
>> ie. A requires B:
>>
>> port install A
>> and
>>
>> port install B && port install A
>>
>> should result in the same final install.
>>
>
> On Apr 11, 2016, at 12:29 PM, David Strubbe  wrote:
>
> Well, that is not the current behavior if a variant is specified manually.
> What happens is:
>
> port install A +var
>
> does
>
> port install B +var && port install A +var.
>
> Why do you think it would be inappropriate to do that for default variants?
>
>
> Binaries are only provided for default variants so you might loose binary
> packages for dependencies due to variants you don’t care about in the
> dependency.
>
>
> Regards,
> Bradley Giesbrecht (pixilla)
>
>
>
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: variants

[David Strubbe]

Well, that is not the current behavior if a variant is specified manually.
What happens is:

port install A +var

does

port install B +var && port install A +var.

Why do you think it would be inappropriate to do that for default variants?

On Mon, Apr 11, 2016 at 11:47 AM, Daniel J. Luke  wrote:

> On Apr 10, 2016, at 4:01 AM, Takeshi Enomoto  wrote:
> > If there is a reason behind treating default_variants and manually set
> variants,
> > I’d like to know.
>
> I'm not sure what the initial reasoning was, but I think the current
> behavior is correct.
>
> When a port is installed as a dependency of some other port, it should be
> installed the same way as if it were installed manually first.
>
> ie. A requires B:
>
> port install A
> and
>
> port install B && port install A
>
> should result in the same final install.
>
> --
> Daniel J. Luke
>
>
>
> ___
> macports-dev mailing list
> macports-dev@lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/macports-dev
>
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: variants

[David Strubbe]

I'd like to second that. I think many issues of variant dependencies are
helped by passing down both manually specified and default variants.

David

On Mon, Apr 4, 2016 at 10:44 AM, Takeshi Enomoto 
wrote:

> Dear Ryan and Mojca,
>
> OK. So I see that this is not the problem of the port.
> I don’t have a solution at this time,
> but I hope that the manually specified variants
> and default_variants should be treated equally
> in the future.
>
> Regards,
>
> Takeshi
>
> -
> Takeshi Enomoto
> take...@macports.org
>
> ___
> macports-dev mailing list
> macports-dev@lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/macports-dev
>
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: CFITSIO's Fortran interface

[David Strubbe]

Hi Sébastien and Ryan,

The solution discussed here will solve the problem but is unnecessarily
restrictive by using only +gcc5. What you should do is this line instead:

compilers.enforce_some_fortran cfitsio

Then any of the Fortran variants gcc5, g95, gcc49 etc. will be accepted.
This is part of the compilers portgroup.

David

On Tue, Feb 16, 2016 at 4:09 AM, Sébastien Maret  wrote:

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

https fetch on buildbots?

[David Strubbe]

Hi all,

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

Thanks,
David

DEBUG: Executing org.macports.fetch (miriad)
--->  miriad-4.3.8.20150520.tar.gz doesn't seem to exist in
/opt/local/var/macports/distfiles/miriad
--->  Attempting to fetch miriad-4.3.8.20150520.tar.gz from
http://distfiles.macports.org/miriad
  % Total% Received % Xferd  Average Speed   TimeTime Time
 Current
 Dload  Upload   Total   SpentLeft
 Speed

  0 00 00 0  0  0 --:--:-- --:--:-- --:--:--
  0
  0 00 00 0  0  0 --:--:-- --:--:-- --:--:--
  0
DEBUG: Fetching distfile failed: The requested URL returned error: 404
--->  Attempting to fetch miriad-4.3.8.20150520.tar.gz from
https://www.cfa.harvard.edu/~pwilliam/miriad-macport/
  % Total% Received % Xferd  Average Speed   TimeTime Time
 Current
 Dload  Upload   Total   SpentLeft
 Speed

  0 00 00 0  0  0 --:--:-- --:--:-- --:--:--
  0
DEBUG: Fetching distfile failed: Unknown SSL protocol error in connection
to www.cfa.harvard.edu:443
--->  Attempting to fetch miriad-4.3.8.20150520.tar.gz from
http://aarnet.au.distfiles.macports.org/pub/macports/mpdistfiles/miriad
  % Total% Received % Xferd  Average Speed   TimeTime Time
 Current
 Dload  Upload   Total   SpentLeft
 Speed

  0 00 00 0  0  0 --:--:-- --:--:-- --:--:--
  0
  0 00 00 0  0  0 --:--:-- --:--:-- --:--:--
  0
DEBUG: Fetching distfile failed: The requested URL returned error: 404
--->  Attempting to fetch miriad-4.3.8.20150520.tar.gz from
http://cjj.kr.distfiles.macports.org/miriad
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

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

[David Strubbe]

Ok, thanks for the explanation. And the fix to my logic in the Portfile.

David

On Thu, Jan 14, 2016 at 8:14 AM, Ryan Schmidt 
wrote:

>
> On Jan 13, 2016, at 11:53 AM, David Strubbe wrote:
>
> > Oh ok. I have seen some ports have a revision increased recently because
> of a change of default variants, so I was following that, but I guess they
> shouldn't have been.
>
> It varies. You just need to ask yourself: will this change result in a
> change* in the files installed on the system of a user who already has this
> port installed? If yes, increase the revision. If no, don't increase the
> revision.
>
>
> * Perhaps I should say "significant change". Yes, any change in the
> Portfile results in a change in the files that would be installed on the
> user system, in that the Portfile itself is installed onto the user system.
> But I would ignore that for insignificant changes to the Portfile, such as
> whitespace changes or syntax changes that don't result in functional
> changes.
>
>
> Take the example of a port that does not support X11. (It uses
> configure.args --without-x11.) You now want to offer X11 support in a
> variant and, by MacPorts convention, you want to enable it by default. You
> add to the port something like this:
>
> variant x11 {
> configure.args-replace --without-x11 --with-x11
> depends_lib-appen port:xorg-libX11
> }
>
> default_variants +x11
>
> This will result in a change in the files installed on the user system:
> before, they had a program that did not support X11, and after rebuilding,
> they will have a program that does support X11. So the revision of that
> port should be increased when that change is made.
>
>
> That's not the situation in octopus. In octopus you have three variants
> which are mutually exclusive and one of them was the default. Note that the
> previous default was only selected if another option had not already been
> selected by the user. That's what the if statement (which I corrected in
> r144637) does. And know that variants (regardless whether the user selected
> them explicitly or whether they were a default variant at the time the user
> installed the port) are preserved on upgrades. So changing the default
> amongst a set of variants where it is required for the user to select one
> of the variants cannot result in a change to the files on the user's
> system, so the revision should not be increased when the default is changed.
>
>
> If you notice that a port would optionally use a dependency, when you add
> the dependency to the port, you increase the revision, because it would
> result in a change of functionality for those users who did not already
> happen to have that dependency installed (which includes all users who
> received a binary from the buildbot).
>
>
> If you notice a port that is missing a required dependency, the port would
> fail to build for users who did not happen to already have the dependency
> installed, which would include the buildbot. For any users who happened to
> already have the dependency installed, they might not know that the port
> has that dependency, and MacPorts would not prevent them from uninstalling
> the dependency, which would break the port. Therefore, when you add the
> dependency to the port, you still increase the revision, so that the port's
> dependencies are correctly recorded in the registry and MacPorts correctly
> prevents their uninstallation.
>
>
> If a port has a custom pre-activate, post-activate, pre-deactivate or
> post-deactivate block, and significant changes in those blocks require a
> revision increase, because MacPorts runs those blocks from the copy of the
> Portfile that was installed on the user system, not the current version of
> the Portfile in the ports tree.
>
>
> Just a few examples of situations to consider.
>
>
>
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

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

[David Strubbe]

Oh ok. I have seen some ports have a revision increased recently because of
a change of default variants, so I was following that, but I guess they
shouldn't have been.

David

On Wed, Jan 13, 2016 at 12:47 PM, Ryan Schmidt 
wrote:

>
> On Jan 13, 2016, at 11:45 AM, Ryan Schmidt wrote:
>
> > But there was no reason to increase the port's revision, since the
> user's existing variants will be preserved in the upgrade. Regardless
> whether the user had the atlas or accelerate or openblas variant of octupus
> 5.0.1_0 installed, they will have exactly the same variant of octopus
> 5.0.1_1 installed after the upgrade. Increasing the revision only causes
> lots of unnecessary rebuilding, for the buildbots and for users.
>
> I should correct myself, and say it causes unnecessary rebuilding or
> downloading and reinstalling for users. The buildbots will have to rebuild
> regardless whether the revision is changed, because the variants are
> changed, but that's fine.
>
>
>
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

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

[David Strubbe]

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

David

On Sat, Jan 9, 2016 at 2:31 AM, Ryan Schmidt 
wrote:

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

Re: [144426] trunk/doc-new/guide/xml/portfile-tcl.xml

[David Strubbe]

Oops and thanks for the further clarifications. I have just updated it.

David

On Fri, Jan 8, 2016 at 5:02 PM, Joshua Root  wrote:

> > Revision: 144426
> >   https://trac.macports.org/changeset/144426
> > Author:   dstrubbe at macports.org
> > Date: 2016-01-08 12:16:33 -0800 (Fri, 08 Jan 2016)
> > Log Message:
> > ---
> > doc-new: Add comments on locale in reinplace.
> >
> > Modified Paths:
> > --
> > trunk/doc-new/guide/xml/portfile-tcl.xml
> >
> > Modified: trunk/doc-new/guide/xml/portfile-tcl.xml
> > ===
> > --- trunk/doc-new/guide/xml/portfile-tcl.xml  2016-01-08 19:39:53 UTC
> (rev 144425)
> > +++ trunk/doc-new/guide/xml/portfile-tcl.xml  2016-01-08 20:16:33 UTC
> (rev 144426)
> > @@ -275,7 +275,9 @@
> >the command with the replacement text, in all files
> >specified.
> >
> > -  Use -locale to set the locale
> > +  Use -locale to set the locale. For example,
> locale -C
> > +   if a non-ASCII file is being modified (which may otherwise
> give the error
> > +   "sed: RE error: illegal byte sequence").
>
> Setting a locale is not needed for all non-ASCII files, just non-UTF-8
> ones (as the default locale is "en_US.UTF-8"). It may also be worth
> mentioning that using "C" will only allow ASCII characters to be
> processed correctly by the reinplace, so if you need it to work on
> non-ASCII characters you need to set a locale with the correct charset
> for the file, e.g. "en_US.ISO8859-1".
>
> Also, it should be "-locale C" not "locale -C".
>
> - Josh
>
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

build.args

[David Strubbe]

Hi all,

Is there a way to get the value of build.args in a Portfile? I would like
to do something like

pre-test {
   test.args-append   ${build.args}
}

but there is no such variable.

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

pymol-devel obsolete?

[David Strubbe]

Hi all,

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

Does anyone think pymol-devel should be kept?

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

blitz-devel: Mercurial clone failed

[David Strubbe]

Hi all,

I just made an update (unrelated to fetching) to blitz-devel, a
nomaintainer port, and got this error below from each buildbot, even though
it worked fine on my machine. Anyone know what this is about?

Thanks,
David

DEBUG: Executing org.macports.fetch (blitz-devel)
DEBUG: Executing: /opt/local/bin/hg clone --rev "8749c555825c"
http://blitz.hg.sourceforge.net:8000/hgroot/blitz/blitz
/opt/local/var/macports/build/_opt_mports_dports_math_blitz-devel/blitz-devel/work/blitz-devel-0.10-20151126
2>&1
abort: error: Connection refused
Command failed: /opt/local/bin/hg clone --rev "8749c555825c"
http://blitz.hg.sourceforge.net:8000/hgroot/blitz/blitz
/opt/local/var/macports/build/_opt_mports_dports_math_blitz-devel/blitz-devel/work/blitz-devel-0.10-20151126
2>&1
Exit code: 255
Error: org.macports.fetch for port blitz-devel returned: Mercurial clone
failed
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

"port install" for subport

[David Strubbe]

Hi all,

If you are in the directory of a Portfile, you can use "port install" or
"port install current" to install the port described by the Portfile. But
what if the Portfile contains a subport? Is there a way to install the
subport in this way? It would be helpful for testing purposes.

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

Re: Warnings when parsing hdfeos5 Portfile

[David Strubbe]

I added the warning. The use of mpi_active_variant_name in this Portfile
apparently fails, so yes it should be changed in the Portfile to not
trigger the warning. We had discussed this on the list about a month ago,
regarding also the cdo and ncarg ports.

David

On Sun, Dec 20, 2015 at 11:03 AM, Joshua Root  wrote:

> I noticed that doing anything that parses the hdfeos5 Portfile, even
> just 'port info hdfeos5', produces this output:
>
> Warning: mpi_active_variant_name: [active_variants bin:h5pcc:hdf5 mpich
> ""] fails.
> Warning: mpi_active_variant_name: [active_variants bin:h5pcc:hdf5
> mpich_devel ""] fails.
> Warning: mpi_active_variant_name: [active_variants bin:h5pcc:hdf5
> openmpi ""] fails.
> Warning: mpi_active_variant_name: [active_variants bin:h5pcc:hdf5
> openmpi_devel ""] fails.
>
> It looks like this is harmless, but it's ugly and likely to alarm users.
> Would it be possible to avoid it?
>
> - Josh
> ___
> macports-dev mailing list
> macports-dev@lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/macports-dev
>
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [141620] trunk/dports/math/netgen/Portfile

[David Strubbe]

Ok, I changed it only because it was not working for me (at least at the
time).

David

On Sat, Dec 12, 2015 at 5:24 AM, Ryan Schmidt 
wrote:

>
> > On Dec 12, 2015, at 4:18 AM, dstru...@macports.org wrote:
> >
> > Revision
> > 141620
> > Author
> > dstru...@macports.org
> > Date
> > 2015-10-23 10:47:58 -0700 (Fri, 23 Oct 2015)
> > Log Message
> >
> > netgen: Update to 5.3.1. Fix build for Yosemite and later by removing
> reference to vecLib; in fact it does not seem that Accelerate is being used
> at all, so I removed it. Removed irrelevant parts of descriptiopn. Do not
> offer variants pertaining only to Fortran compilers since this code uses
> only C and C++. Disable test phase which had no effect. Update master_sites
> line.
> > Modified Paths
> >
> >   • trunk/dports/math/netgen/Portfile
> > Diff
> >
> > Modified: trunk/dports/math/netgen/Portfile (141619 => 141620)
> >
> > --- trunk/dports/math/netgen/Portfile 2015-10-23 17:47:01 UTC (rev
> 141619)
> > +++ trunk/dports/math/netgen/Portfile 2015-10-23 17:47:58 UTC (rev
> 141620)
>
> > -master_sites
> sourceforge:project/netgen-mesher/netgen-mesher/${version}/
> > +master_sitessourceforge:netgen-mesher
>
> This portion of your changeset reverts my r120755, which was done for the
> reasons explained in:
>
> https://trac.macports.org/wiki/howto/AvoidRedirects
>
> I've redone it in r143422, with fixes to use ${branch} instead of
> ${version}.
>
>
>
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: removing subport

[David Strubbe]

It is a program. It does actually install a library too, which would be
different from the single precision one, not just an additional component.
But I don't know how one would use this library. I think it is unlikely
anyone has been trying to use the library in double precision for any
purpose from this port, because the conflict with the non-double port was
not handled properly and so the double port failed to install. And I didn't
see any tickets about it.

David

On Fri, Dec 11, 2015 at 7:29 PM, Ryan Schmidt 
wrote:

>
> On Dec 10, 2015, at 5:05 PM, David Strubbe wrote:
>
> > I want to make the "gromacs-double" subport instead just a variant
> "gromacs +double" as I don't see any particular reason why both would need
> to be co-installed, and it seems clearer this way.
> >
> > How should one proceed for removing a subport, compared to the procedure
> for removing a port?
> https://guide.macports.org/#development.practices.rename-replace-port
>
> Is gromacs a program or a library?
>
> Would using this hypothetical +double variant change gromacs to be
> double-precision, or would it install double-precision components alongside
> the standard components which are always available?
>
> My concern would be that if gromacs is a library that is used by other
> software, and if using the hypothetical +double variant changes the
> components that are installed (and not just adds additional components),
> then that might cause problems for that other software that uses gromacs.
> For example, that other software might have been built to expect
> single-precision components and might not work with double-precision
> components.
>
> I didn't see any other ports declaring a dependency on gromacs but if it
> is a library then it could be used by other software outside of MacPorts,
> or in third-party MacPorts repositories.
>
>
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

removing subport

[David Strubbe]

Hi all,

I want to make the "gromacs-double" subport instead just a variant "gromacs
+double" as I don't see any particular reason why both would need to be
co-installed, and it seems clearer this way.

How should one proceed for removing a subport, compared to the procedure
for removing a port?
https://guide.macports.org/#development.practices.rename-replace-port

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

Re: Qt5 port unparsable: can't read "qt_archdata_dir": no such variable

[David Strubbe]

Do 'svn revert' on it.

On Mon, Nov 23, 2015 at 11:29 AM, Vincent Habchi  wrote:

> Ryan,
>
> > qt_archdata_dir should be set in the qt5 1.0 portgroup. Do you perhaps
> have local modifications to this portgroup that are conflicting with the
> official version?
>
> Bullseye! But if I delete my qt5-1.0.tcl file and try to recreate it with
> SVN, I get this:
>
> > svn update
> Updating '.':
> Skipped 'qt5-1.0.tcl' -- Node remains in conflict
>
> And I get no port-group file restored.
>
> Any idea?
>
> Thanks,
> Vincent
> ___
> macports-dev mailing list
> macports-dev@lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/macports-dev
>
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Owner of MacPorts account on GitHub

[David Strubbe]

Yes, this is a pet peeve of mine. Try figuring out whether a ticket has
been filed against the port "R" or not... It would be helpful to give the
option in this context not to use regexes, so to check whether the port
field is exactly "R" (or if separated into comma-delimited fields, one is
exactly "R") and not just contains "R".

David

On Fri, Nov 13, 2015 at 2:16 PM, Arno Hautala  wrote:

> On Fri, Nov 13, 2015 at 12:31 PM, Rainer Müller 
> wrote:
> >
> > Maybe it would be enough to search in the subject instead, but for some
> ports
> > with generic names this would return many unrelated results.
>
> It's less than ideal, but a convention of something like port_portname
> would work for narrowing down searches.
>
> --
> arno  s  hautala/-|   a...@alum.wpi.edu
>
> pgp b2c9d448
> ___
> macports-dev mailing list
> macports-dev@lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/macports-dev
>
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Nonexistent mpi.default variable lets port upgrade fail

[David Strubbe]

Discussed and resolved here: https://trac.macports.org/ticket/49669

David

On Thu, Nov 12, 2015 at 3:33 AM, David Evans  wrote:

> On 11/11/15 11:36 PM, Marko Käning wrote:
> > Ooops, what does this error suddenly happen?
> >
> > ---
> > --->  Updating MacPorts base sources using rsync
> > MacPorts base version 2.3.4 installed,
> > MacPorts base version 2.3.4 downloaded.
> > --->  Updating the ports tree
> > --->  MacPorts base is already the latest version
> >
> > The ports tree has been updated. To upgrade your installed ports, you
> should run
> >   port upgrade outdated
> > The following installed ports are outdated:
> > kdetoys4   4.10.5_0 < 4.10.5_1
> > Error: Unable to open port: can't read "mpi.default": no such variable
> > To report a bug, follow the instructions in the guide:
> > http://guide.macports.org/#project.tickets
> > ---
> >
> > Greets,
> > Marko
> > ___
> > macports-dev mailing list
> > macports-dev@lists.macosforge.org
> > https://lists.macosforge.org/mailman/listinfo/macports-dev
> >
>
> The error appears to come from port boost (may be others) which is broken
> (Portfile fails to parse) after
> the recent update to mpi portgroup in r142438.
>
> Dave
>
> ___
> macports-dev mailing list
> macports-dev@lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/macports-dev
>
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

platform

[David Strubbe]

Hi all,

Can someone explain what the meaning of the possible values of the
'platforms' variable are in a Portfile? Most ports seem to list 'darwin'
but I have seen some that say 'macosx' or even 'puredarwin'. I understand
the meaning of clearly different operating system designations such as
freebsd, linux, sunos, netbsd. But what is the meaning of these similar
'darwin' and 'macosx' labels? The guide is not very illuminating on this
point.

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

Re: Including port groups multiple times (was: Re: passing variants to dependencies; pre-activate check)

[David Strubbe]

Hi Rainer,

Do you have a suggestion of how to accomplish that? That could potentially
be a simpler approach than adding include guards.

If we do go with include guards, anyone want to comment on my particular
implementation?

Index: dports/_resources/port1.0/group/active_variants-1.1.tcl
===
--- dports/_resources/port1.0/group/active_variants-1.1.tcl (revision
141271)
+++ dports/_resources/port1.0/group/active_variants-1.1.tcl (working
copy)
@@ -87,6 +87,12 @@
 # dependencies, e.g., require_active_variants path:foo/bar:standardport
 # variant

+default active_variants_included {}
+
+# only include this PortGroup once
+if {${active_variants_included} == ""} {
+set active_variants_included "yes"
+
 proc active_variants {depspec required {forbidden {}}} {
# get the port which will provide $depspec; this allows us to
support e.g.,
# path-style dependencies. This comes from port1.0/portutil.tcl and
should
@@ -278,3 +284,5 @@
 pre-activate {
 _check_require_active_variants activate
 }
+
+}

David

On Wed, Oct 14, 2015 at 9:19 AM, Rainer Müller  wrote:

> On 2015-10-14 05:49, Ryan Schmidt wrote:
> > You're right, it's probably important for portgroup to guard against
> multiple inclusion.
> >
> > https://en.wikipedia.org/wiki/Include_guard
> >
> > "port lint" will warn you if you include a portgroup more than once, but
> that won't check portgroup inclusion in files other than the portfile
> itself, can give false positives for portgroups that are included in
> conditionals (including subports), and even ignores lines with leading
> whitespace.
> >
> > We should develop a standard include guard for portgroups (possibly the
> one you suggested) and use it in every portgroup.
>
> If we decide that there is no use case for including a port group
> multiple times, we could prevent this in base when evaluating PortGroup
> statements.
>
> Rainer
> ___
> macports-dev mailing list
> macports-dev@lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/macports-dev
>
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: passing variants to dependencies; pre-activate check

[David Strubbe]

Would something like this be a good idea to prevent multiple definition?
This could potentially be an issue with other nested portgroups too.

Index: dports/_resources/port1.0/group/active_variants-1.1.tcl
===
--- dports/_resources/port1.0/group/active_variants-1.1.tcl (revision
141271)
+++ dports/_resources/port1.0/group/active_variants-1.1.tcl (working
copy)
@@ -87,6 +87,12 @@
 # dependencies, e.g., require_active_variants path:foo/bar:standardport
 # variant

+default active_variants_included {}
+
+# only include this PortGroup once
+if {${active_variants_included} == ""} {
+set active_variants_included "yes"
+
 proc active_variants {depspec required {forbidden {}}} {
# get the port which will provide $depspec; this allows us to
support e.g.,
# path-style dependencies. This comes from port1.0/portutil.tcl and
should
@@ -278,3 +284,5 @@
 pre-activate {
 _check_require_active_variants activate
 }
+
+}


On Tue, Oct 13, 2015 at 10:35 PM, Joshua Root  wrote:

> On 2015-10-14 13:04 , David Strubbe wrote:
> > > - Why is pre-activate code executed twice?
> >
> > It isn't, two pre-activate procedures have been registered and they
> are
> > each executed once.
> >
> >
> > Well, I only put one block of code in active variants, as below. Why
> > does it end up in two different pre-activate procedures?
> >
> > active_variants-1.1.tcl:
> >>
> >> +pre-activate {
> >> +ui_warn "checking active variants"
> >> +_check_require_active_variants archivefetch
> >> +}
>
> Looking at the portfile, it uses the compilers portgroup as well as
> active_variants. Looking at compilers, it uses active_variants itself.
> So active_variants is included twice.
>
> - Josh
>
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: passing variants to dependencies; pre-activate check

[David Strubbe]

Hi Josh,

Thanks for the response.

On Tue, Oct 13, 2015 at 8:26 PM, Joshua Root  wrote:

> On 2015-10-14 04:53 , David Strubbe wrote:
> > Can anyone help me with these questions?
> >
> > In short, I am wondering:
> > - Why does 'port install xcrysden +x11' pass the variant +x11 to the
> > installation of tk only if BWidget is also not installed?
>
> It passes the variant on during installation of dependencies in both
> cases, but tk happens to already be installed during the upgrading of
> BWidget which happens before dependencies are installed.
>

Ok, I think I understand. port notices that BWidget is defective in not
having its dependency tk installed (this is what you mean by "upgrading"
right?), and then fixes this by installing tk, taking into account only the
variants that BWidget was installed with (none) and not what xcryden would
have passed to tk separately.


>
> Wanting this to work how you want is exactly equivalent to depending on
> variants, which you can't currently do.


I'm aware there isn't a good solution. But there are still some things we
can do. For example, in this case, I can recommend users not to do "port
install xcrysden" which will fail with an error message, but rather "port
install xcrysden +x11" which will generally succeed, unless tk is already
installed +quartz (or BWidget is installed already).



> - Why is pre-activate code executed twice?
>
> It isn't, two pre-activate procedures have been registered and they are
> each executed once.
>

Well, I only put one block of code in active variants, as below. Why does
it end up in two different pre-activate procedures?

active_variants-1.1.tcl:
>
> +pre-activate {
> +ui_warn "checking active variants"
> +_check_require_active_variants archivefetch
> +}
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: passing variants to dependencies; pre-activate check

[David Strubbe]

Can anyone help me with these questions?

In short, I am wondering:
- Why does 'port install xcrysden +x11' pass the variant +x11 to the
installation of tk only if BWidget is also not installed?
- Why is pre-activate code executed twice?

Thanks,
David

On Mon, Oct 12, 2015 at 3:19 PM, David Strubbe 
wrote:

> I have another question now in addition to these:
>
> Why are there two pre-activate phases? The code I put in pre-activate gets
> executed in proc-pre-org.macports.activate-activate-0 and
> proc-pre-org.macports.activate-activate-1. (More below, from 'port install
> xcrysden') For writing a warning, it would be better not to have it written
> twice, as is currently happening.
>
> Thanks,
> David
>
> :debug:install Found Dependency: path: /opt/local/lib/libgcc filename:
> libgcc_s.1.dylib regex: ^libgcc_s.1.dylib$
> :debug:activate activate phase started at Sun Oct 11 22:00:07 EDT 2015
> :debug:activate Executing proc-pre-org.macports.activate-activate-0
> :debug:activate Found Dependency: path: /opt/local/lib/libgcc filename:
> libgcc_s.1.dylib regex: ^libgcc_s.1.dylib$
> :debug:activate Active variants check for activate-type install considers
> depends_lib depends_run: fftw-3 mesa libGLU tcl tk xorg-libXmu xorg-libX11
> xorg-libXext libgcc-devel BWidget
> :debug:activate tk is installed with the following variants: +quartz
> :debug:activate   required: x11, forbidden:
> :debug:activate   rejected, because required variant x11 is missing
> :msg:activate Warning: tk must be installed with +x11.
> :debug:activate Executing proc-pre-org.macports.activate-activate-1
> :debug:activate Found Dependency: path: /opt/local/lib/libgcc filename:
> libgcc_s.1.dylib regex: ^libgcc_s.1.dylib$
> :debug:activate Active variants check for activate-type install considers
> depends_lib depends_run: fftw-3 mesa libGLU tcl tk xorg-libXmu xorg-libX11
> xorg-libXext libgcc-devel BWidget
> :debug:activate tk is installed with the following variants: +quartz
> :debug:activate   required: x11, forbidden:
> :debug:activate   rejected, because required variant x11 is missing
> :msg:activate Warning: tk must be installed with +x11.
> :debug:activate Executing org.macports.activate (xcrysden)
> :msg:activate --->  Activating xcrysden @1.5.60_1+gcc5
>
> On Sat, Oct 10, 2015 at 11:33 PM, David Strubbe 
> wrote:
>
>>
>>
>> On Sat, Oct 10, 2015 at 10:34 PM, Joshua Root  wrote:
>>
>>> On 2015-10-11 11:34 , David Strubbe wrote:
>>> > Thanks for checking. I realize now I can find these two different
>>> > behaviors, depending on whether the other dependency BWidget is
>>> > installed or not. I'm confused about why this would be happening. Why
>>> > isn't "Computing dependencies for xcrysden" happening in both cases?
>>> >
>>> > (BWidget is installed)
>>> > $ sudo port -f uninstall tk xcrysden
>>> > $ sudo port install xcrysden +x11
>>> > --->  Computing dependencies for tk
>>> > --->  Fetching archive for tk
>>> > --->  Attempting to fetch tk-8.6.3_0+quartz.darwin_14.x86_64.tbz2 from
>>> > http://mse.uk.packages.macports.org/sites/packages.macports.org/tk
>>> > ...
>>> >
>>> > $ sudo port -f uninstall tk xcrysden BWidget
>>> > $ sudo port install xcrysden +x11
>>> > --->  Computing dependencies for xcrysden
>>> > --->  Dependencies to be installed: BWidget tk
>>> > --->  Fetching archive for tk
>>> > --->  Attempting to fetch tk-8.6.3_0+x11.darwin_14.x86_64.tbz2 from
>>> > http://mse.uk.packages.macports.org/sites/packages.macports.org/tk
>>> > ...
>>>
>>> It happens in both cases, you just stopped before it got there in the
>>> first case. Already-installed dependencies are upgraded before new
>>> dependencies are installed.
>>>
>>
>> I did not stop anything; I just included only the important parts (hence
>> "..."). Yes it does say "Computing dependencies for xcrysden" eventually in
>> the first case, but why is it after have installed a dependency? Surely the
>> dependencies were computed at the beginning anyway to decide to install tk.
>>
>> I think you are suggesting it is related to the fact that tk is a
>> dependency of BWidget. It's hard to understand why that would matter for
>> what variant got passed to tk.
>>
>>
>>>
>>> > Regarding the pre-activate, I added this code to my copy of
>>> > active_variants-1.1.tcl:
>>> >
>>> > +pre-activate {
>>> > 

Re: passing variants to dependencies; pre-activate check

[David Strubbe]

I have another question now in addition to these:

Why are there two pre-activate phases? The code I put in pre-activate gets
executed in proc-pre-org.macports.activate-activate-0 and
proc-pre-org.macports.activate-activate-1. (More below, from 'port install
xcrysden') For writing a warning, it would be better not to have it written
twice, as is currently happening.

Thanks,
David

:debug:install Found Dependency: path: /opt/local/lib/libgcc filename:
libgcc_s.1.dylib regex: ^libgcc_s.1.dylib$
:debug:activate activate phase started at Sun Oct 11 22:00:07 EDT 2015
:debug:activate Executing proc-pre-org.macports.activate-activate-0
:debug:activate Found Dependency: path: /opt/local/lib/libgcc filename:
libgcc_s.1.dylib regex: ^libgcc_s.1.dylib$
:debug:activate Active variants check for activate-type install considers
depends_lib depends_run: fftw-3 mesa libGLU tcl tk xorg-libXmu xorg-libX11
xorg-libXext libgcc-devel BWidget
:debug:activate tk is installed with the following variants: +quartz
:debug:activate   required: x11, forbidden:
:debug:activate   rejected, because required variant x11 is missing
:msg:activate Warning: tk must be installed with +x11.
:debug:activate Executing proc-pre-org.macports.activate-activate-1
:debug:activate Found Dependency: path: /opt/local/lib/libgcc filename:
libgcc_s.1.dylib regex: ^libgcc_s.1.dylib$
:debug:activate Active variants check for activate-type install considers
depends_lib depends_run: fftw-3 mesa libGLU tcl tk xorg-libXmu xorg-libX11
xorg-libXext libgcc-devel BWidget
:debug:activate tk is installed with the following variants: +quartz
:debug:activate   required: x11, forbidden:
:debug:activate   rejected, because required variant x11 is missing
:msg:activate Warning: tk must be installed with +x11.
:debug:activate Executing org.macports.activate (xcrysden)
:msg:activate --->  Activating xcrysden @1.5.60_1+gcc5

On Sat, Oct 10, 2015 at 11:33 PM, David Strubbe 
wrote:

>
>
> On Sat, Oct 10, 2015 at 10:34 PM, Joshua Root  wrote:
>
>> On 2015-10-11 11:34 , David Strubbe wrote:
>> > Thanks for checking. I realize now I can find these two different
>> > behaviors, depending on whether the other dependency BWidget is
>> > installed or not. I'm confused about why this would be happening. Why
>> > isn't "Computing dependencies for xcrysden" happening in both cases?
>> >
>> > (BWidget is installed)
>> > $ sudo port -f uninstall tk xcrysden
>> > $ sudo port install xcrysden +x11
>> > --->  Computing dependencies for tk
>> > --->  Fetching archive for tk
>> > --->  Attempting to fetch tk-8.6.3_0+quartz.darwin_14.x86_64.tbz2 from
>> > http://mse.uk.packages.macports.org/sites/packages.macports.org/tk
>> > ...
>> >
>> > $ sudo port -f uninstall tk xcrysden BWidget
>> > $ sudo port install xcrysden +x11
>> > --->  Computing dependencies for xcrysden
>> > --->  Dependencies to be installed: BWidget tk
>> > --->  Fetching archive for tk
>> > --->  Attempting to fetch tk-8.6.3_0+x11.darwin_14.x86_64.tbz2 from
>> > http://mse.uk.packages.macports.org/sites/packages.macports.org/tk
>> > ...
>>
>> It happens in both cases, you just stopped before it got there in the
>> first case. Already-installed dependencies are upgraded before new
>> dependencies are installed.
>>
>
> I did not stop anything; I just included only the important parts (hence
> "..."). Yes it does say "Computing dependencies for xcrysden" eventually in
> the first case, but why is it after have installed a dependency? Surely the
> dependencies were computed at the beginning anyway to decide to install tk.
>
> I think you are suggesting it is related to the fact that tk is a
> dependency of BWidget. It's hard to understand why that would matter for
> what variant got passed to tk.
>
>
>>
>> > Regarding the pre-activate, I added this code to my copy of
>> > active_variants-1.1.tcl:
>> >
>> > +pre-activate {
>> > +ui_warn "checking active variants"
>> > +_check_require_active_variants archivefetch
>> > +}
>> >
>> > When I do a fresh install, I see this message before activate. When I
>> > deactivate and re-activate, I don't see the message. My conclusion was
>> > that pre-activate was not being run in the latter case -- is there some
>> > other reason it wouldn't be written?
>>
>> Are you editing the portgroup after you install the port? Running a
>> target on an already installed port uses the copy of the portgroup
>> stored in the registry.
>>
>
> Before I installed the port. I am running "port install" in the directory
> with the Portfile, then "port deactivate", then "port activate" (in each
> case, not specifying a name). Does that still just use the registry
> portgroup rather than the one in my dports tree?
>
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: passing variants to dependencies; pre-activate check

[David Strubbe]

On Sat, Oct 10, 2015 at 10:34 PM, Joshua Root  wrote:

> On 2015-10-11 11:34 , David Strubbe wrote:
> > Thanks for checking. I realize now I can find these two different
> > behaviors, depending on whether the other dependency BWidget is
> > installed or not. I'm confused about why this would be happening. Why
> > isn't "Computing dependencies for xcrysden" happening in both cases?
> >
> > (BWidget is installed)
> > $ sudo port -f uninstall tk xcrysden
> > $ sudo port install xcrysden +x11
> > --->  Computing dependencies for tk
> > --->  Fetching archive for tk
> > --->  Attempting to fetch tk-8.6.3_0+quartz.darwin_14.x86_64.tbz2 from
> > http://mse.uk.packages.macports.org/sites/packages.macports.org/tk
> > ...
> >
> > $ sudo port -f uninstall tk xcrysden BWidget
> > $ sudo port install xcrysden +x11
> > --->  Computing dependencies for xcrysden
> > --->  Dependencies to be installed: BWidget tk
> > --->  Fetching archive for tk
> > --->  Attempting to fetch tk-8.6.3_0+x11.darwin_14.x86_64.tbz2 from
> > http://mse.uk.packages.macports.org/sites/packages.macports.org/tk
> > ...
>
> It happens in both cases, you just stopped before it got there in the
> first case. Already-installed dependencies are upgraded before new
> dependencies are installed.
>

I did not stop anything; I just included only the important parts (hence
"..."). Yes it does say "Computing dependencies for xcrysden" eventually in
the first case, but why is it after have installed a dependency? Surely the
dependencies were computed at the beginning anyway to decide to install tk.

I think you are suggesting it is related to the fact that tk is a
dependency of BWidget. It's hard to understand why that would matter for
what variant got passed to tk.


>
> > Regarding the pre-activate, I added this code to my copy of
> > active_variants-1.1.tcl:
> >
> > +pre-activate {
> > +ui_warn "checking active variants"
> > +_check_require_active_variants archivefetch
> > +}
> >
> > When I do a fresh install, I see this message before activate. When I
> > deactivate and re-activate, I don't see the message. My conclusion was
> > that pre-activate was not being run in the latter case -- is there some
> > other reason it wouldn't be written?
>
> Are you editing the portgroup after you install the port? Running a
> target on an already installed port uses the copy of the portgroup
> stored in the registry.
>

Before I installed the port. I am running "port install" in the directory
with the Portfile, then "port deactivate", then "port activate" (in each
case, not specifying a name). Does that still just use the registry
portgroup rather than the one in my dports tree?
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: passing variants to dependencies; pre-activate check

[David Strubbe]

Thanks for checking. I realize now I can find these two different
behaviors, depending on whether the other dependency BWidget is installed
or not. I'm confused about why this would be happening. Why isn't
"Computing dependencies for xcrysden" happening in both cases?

(BWidget is installed)
$ sudo port -f uninstall tk xcrysden
$ sudo port install xcrysden +x11
--->  Computing dependencies for tk
--->  Fetching archive for tk
--->  Attempting to fetch tk-8.6.3_0+quartz.darwin_14.x86_64.tbz2 from
http://mse.uk.packages.macports.org/sites/packages.macports.org/tk
...

$ sudo port -f uninstall tk xcrysden BWidget
$ sudo port install xcrysden +x11
--->  Computing dependencies for xcrysden
--->  Dependencies to be installed: BWidget tk
--->  Fetching archive for tk
--->  Attempting to fetch tk-8.6.3_0+x11.darwin_14.x86_64.tbz2 from
http://mse.uk.packages.macports.org/sites/packages.macports.org/tk
...


Regarding the pre-activate, I added this code to my copy of
active_variants-1.1.tcl:

+pre-activate {
+ui_warn "checking active variants"
+_check_require_active_variants archivefetch
+}

When I do a fresh install, I see this message before activate. When I
deactivate and re-activate, I don't see the message. My conclusion was that
pre-activate was not being run in the latter case -- is there some other
reason it wouldn't be written?

David


On Sat, Oct 10, 2015 at 7:06 PM, Joshua Root  wrote:

> On 2015-10-11 09:33 , David Strubbe wrote:
> > Hi all,
> >
> > It seems to me that as of recently it was the case that variants from
> > the install command line are passed on to the building of dependencies
> > (as discussed below last year), but that it is no longer happening. Is
> > this something that was changed (deliberately or otherwise) in the 2.3.4
> > release?
> >
> > Specifically, my recently added xcrysden port needs tk +x11 (checked via
> > active_variants), whereas the default is +quartz. As of a couple of
> > weeks ago, I think I was able successfully to trigger installation of tk
> > +x11 when it was not installed by doing 'port install xcrysden +x11'.
> > But now this doesn't happen.
>
> I just checked and this still works the same as it has for many years.
>
> > Another question related to active_variants: would it be possible for
> > require_active_variants to perform its check not just in the
> > pre-configure phase as is currently the case, but also in the activate
> > phase? Currently, you could install xcrysden when tk +x11 was active,
> > then deactivate xcrysden, install tk +quartz, and re-activate xcrysden.
> > It would no longer work. It would be good if we could write an error at
> > this point. I tried adding code to pre-activate to accomplish this, but
> > I found it was only called when doing a fresh install, not when
> > activating a deactivated port. Is there a way to get some code to run
> > when activating a deactivated port?
>
> Preventing the activation would not be helpful I think, especially if
> the user is running something like 'port activate xcrysden tk +x11'.
> Printing a warning would be fine.
>
> I just checked the pre-activate behaviour as well and it still runs
> before every activation as intended. The only reason it wouldn't run is
> if the Portfile was missing from the registry or failed to parse.
>
> - Josh
>
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

passing variants to dependencies; pre-activate check

[David Strubbe]

Hi all,

It seems to me that as of recently it was the case that variants from the
install command line are passed on to the building of dependencies (as
discussed below last year), but that it is no longer happening. Is this
something that was changed (deliberately or otherwise) in the 2.3.4 release?

Specifically, my recently added xcrysden port needs tk +x11 (checked via
active_variants), whereas the default is +quartz. As of a couple of weeks
ago, I think I was able successfully to trigger installation of tk +x11
when it was not installed by doing 'port install xcrysden +x11'. But now
this doesn't happen.

Another question related to active_variants: would it be possible for
require_active_variants to perform its check not just in the pre-configure
phase as is currently the case, but also in the activate phase? Currently,
you could install xcrysden when tk +x11 was active, then deactivate
xcrysden, install tk +quartz, and re-activate xcrysden. It would no longer
work. It would be good if we could write an error at this point. I tried
adding code to pre-activate to accomplish this, but I found it was only
called when doing a fresh install, not when activating a deactivated port.
Is there a way to get some code to run when activating a deactivated port?

Thanks,
David

On Sun, Nov 16, 2014 at 6:40 PM, Lawrence Velázquez 
wrote:

> On Nov 16, 2014, at 5:32 PM, David Strubbe  wrote:
>
> > All right, but can you clarify about default variants: is it true that
> default variants are not passed to dependencies, but all other variants
> are? And, is there any good reason for this? It would solve my problem
> immediately if they were passed on.
>
> As far as I know, variants are only passed from the command line, and even
> then they are only applied when dependencies have to be installed. Running
>
> port install foo
>
> where foo has some default variant +bar is *not* equivalent to running
>
> port install foo +bar
>
> I don't know the reason for this behavior.
>
> vq
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [140793] trunk/dports/math/svdlibc/Portfile

[David Strubbe]

Ok, thanks.

David

On Sat, Oct 3, 2015 at 7:35 AM, Ryan Schmidt 
wrote:

>
> > On Oct 2, 2015, at 2:43 PM, dstru...@macports.org wrote:
> >
> > Revision
> > 140793
> > Author
> > dstru...@macports.org
> > Date
> > 2015-10-02 12:43:15 -0700 (Fri, 02 Oct 2015)
> > Log Message
> >
> > svdlibc: Add license. Fix checksums. Add livecheck. Comment on destroot
> failure.
>
> Checksums shouldn't just change. Anytime a port's checksums seem wrong,
> you need to investigate and find out why. In this case, it's because the
> project uses an unversioned distfile, and released a new version. The port
> version still says 1.34, but you changed the checksums to those matching
> version 1.4. This port needs to follow the recipe for unversioned distfiles:
>
> https://trac.macports.org/wiki/PortfileRecipes#unversioned-distfiles
>
>
> I'll see if I can fix the port.
>
>
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: migration instructions

[David Strubbe]

On Mon, Sep 14, 2015 at 8:04 PM, Joshua Root  wrote:

>
> > 2. The list of ports generated in myports.txt and requested.txt will
> > include ports that are deactivated, including one line for each version
> > of a port, whether active or not. One line total regardless of number of
> > versions would be sufficient. Re-installing deactivated ports should
> > probably not be done by default since that is not returning you to the
> > original state and there was probably a reason (such as conflicts) why
> > the ports were deactivated.
>
> This actually isn't a problem at all. We can't install old versions, so
> what you end up with is the current version of each port, with the
> previously active variants (if any) active, and any other listed variant
> combinations inactive.
>

The multiple lines for a given port is just messy, but yes it is not really
a problem. And I guess I was mistaken about deactivated ports, the restore
script is checking that status.

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

migration instructions

[David Strubbe]

Hello all,

I have just updated to Yosemite and used the migration instructions at
http://trac.macports.org/wiki/Migration

I want to point out two issues:

1. Running "sudo port clean all" takes a huge amount of time. Apparently
many hours for me; I didn't have the patience to let it finish. Instead we
should clean just the ports that have incomplete builds (probably just a
few in most cases) which can be found by looking at
/opt/local/var/macports/builds and /optlocal/var/macports/logs I think,
saving a lot of time.

2. The list of ports generated in myports.txt and requested.txt will
include ports that are deactivated, including one line for each version of
a port, whether active or not. One line total regardless of number of
versions would be sufficient. Re-installing deactivated ports should
probably not be done by default since that is not returning you to the
original state and there was probably a reason (such as conflicts) why the
ports were deactivated.

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

Re: Easy access to external repositories.

[David Strubbe]

Hi Artur,

Since you are discussing the question of ensuring the reliability of
results, let me point out that you can add a "test"phase in the Portfile,
to run a testsuite with the command "port test". I am developing and
maintaining several software package for condensed-matter physics and have
found this quite helpful in validating the builds, and making sure users
can do so too.

David

On Tue, Jun 2, 2015 at 6:05 AM, Thibaut Paumard 
wrote:

> Le 02/06/2015 11:32, Artur Szostak a écrit :
> >> Do you already have commit access to the repository?
> >
> > No, and it is not clear that I should be the one with such access for
> ESO. This is something we have to decide here at ESO first.
> >
> >
> >> If not I can act as a sponsor for those packages, until you get it.
> >>
> >> My duty cycle will be more in the range of a couple of days for packages
> >> that I don't know yet (I'd be responsible for any damage they would
> >> cause), and approx one day or less for small updates on packages that I
> >> know already.
> >
> > Thank you for volunteering. I fear that a couple of days may be a bit
> too long for a number of our astronomers at the moment. This will have to
> be discussed by us to see how to proceed. We have about 108 Portfiles in
> our repository and this number will grow as new instruments and their
> associated data processing software comes online. Unfortunately, experience
> has also shown that a fair amount of understanding of the ESO source code
> packages for the 19 different instruments is required to correctly build
> the software. What I mean by correct, is not just that the software
> compiles and runs, but that is does not introduce any nasty artefacts into
> the scientific results. This is actually a big motivator for us at ESO to
> take on the responsibility of binary packaging the ESO software for our
> astronomers, rather than them doing it by themselves.
> > If you take responsibility for maintaining our Portfiles in the default
> MacPorts repository, how would you propose the update procedure to work?
> Would you only update with the patches we deliver? If you or one of the
> other core maintainers has to make a change independently, how would this
> be validated for quality assurance?
> >
> > However, with that all said, there certainly are one or two Portfiles
> that are actually 3rd party library dependencies for our software (e.g.
> py-photutils) or are less critical. These could be the first good
> candidates to consider moving over to the default repository.
>
> Dear Artur,
>
> I am only given the amount of work involved and the duty cycle you have
> in mind, I think that if you want to go that route, someone from ESO
> needs to get commit access. In the meantime I can help you experiment
> with a couple of Portfiles, like the dependencies you mention. So you
> will be able to see what is being built, when etc.
>
> You would still be the maintainer (the one listed as such in the
> Portfile) and I would only commit things exactly as you have sent them
> to me (or via the tracker). However, by committing something that you
> have prepared, my responsibility is also engaged.
>
> It may be that the best thing to do is to keep the external repository,
> however my offer stands, be it only for 3rd party dependencies.
>
> >> For the record, all the ESO packages are being packaged by volunteers in
> >> Debian, and I already maintain packages will small userbase,
> >> concentrated among astronomers.
> >
> > I know about those packages. Unfortunately many of our users also do not
> regularly use those packages, since they tend to be out of date, which has
> a negative impact on the quality of scientific analyses. The RPM
> repositories also do not deliver our full data processing stack. We are
> actually in the process of preparing full YUM and APT repositories of our
> software for the ESO instruments. There again, we will have to see and
> negotiate with the respective communities if it makes sense to migrate any
> of that to the Fedora or Debian repositories.
>
> For the Debian community, I guess you already know Ole Streicher and the
> Debian Astro effort then? This subtopic is better discussed on
> debian-astro bei lists.debian.org. In particular, updates could be
> managed through the backports infrastructure.
>
> Kind regards, Thibaut.
>
> ___
> macports-dev mailing list
> macports-dev@lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/macports-dev
>
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Easy access to external repositories.

[David Strubbe]

The buildslaves begin shortly after each commit. The delay, if any, is
probably a few minutes. Of course depending on how long it takes to build
the ports it may take a while to finish, and may have been busy building
other ports already when you commit.

When it cannot get the binary, that may be because of license issues,
because the build failed on the buildslave, or because you are using
non-default variants (and probably other reasons too).

On Mon, Jun 1, 2015 at 4:54 PM, Artur Szostak 
wrote:

>  Our software is all open source (GPL) so thats not the problem.
> What is the duty cycle or delay for the buildslaves to build these
> packages?
> I have seen a number of occasions where MacPorts cannot seem to find the
> binary for a Portfile from the default repository and builds the package
> locally.
>
>  --
> *From:* dstru...@gmail.com [dstru...@gmail.com] on behalf of David
> Strubbe [dstru...@macports.org]
> *Sent:* 01 June 2015 21:06
> *To:* Artur Szostak
> *Cc:* MacPorts Development
> *Subject:* Re: Easy access to external repositories.
>
>   Provided the licenses for your software and its dependencies would make
> the binaries redistributable, the binaries will be built automatically for
> the default variants by the buildslaves (using various recent versions of
> OSX) after a commit of a Portfile to the MacPorts repository, and then
> those binaries will be available for users when they run 'port install'.
>
>  David
>
>
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Easy access to external repositories.

[David Strubbe]

Provided the licenses for your software and its dependencies would make the
binaries redistributable, the binaries will be built automatically for the
default variants by the buildslaves (using various recent versions of OSX)
after a commit of a Portfile to the MacPorts repository, and then those
binaries will be available for users when they run 'port install'.

David

On Mon, Jun 1, 2015 at 2:24 PM, Artur Szostak 
wrote:

>  > If you are the maintainer, you should be able to have as much control
> > as you wish over the Portfiles and the release cycle. There is no
> "release
> > cycle" for ports really, you can just update them whenever you please.
>
> That will be useful input when we discuss it again at ESO.
>
> One other thing that came to mind: how could we control the binary package
> archive? How does one make sure binary packages are available at the same
> time as the Portfile is updated?
> Currently we release prebuilt binary packages together with any Portfile
> updates at the same time to our repository. But that is because we control
> the FTP that stores all these files.
>
> Regards.
>
> Artur
>
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Easy access to external repositories.

[David Strubbe]

> In our case: we have a community of astronomers that have requested a
> distribution mechanism for ESO software via MacPorts, which they are
> familiar with. However, our software is only relevant to astronomers (a few
> hundred users), rather than the much larger community that the default
> MacPorts repository it trying to target.
>

A few hundred users may well be more than the majority of ports have,
actually!


> So I thought that taking an optional extra repository approach (kind of
> like Fedora EPEL) would be the most appropriate.
> Another issue would be any differences between our release cycle at ESO
> versus the default MacPorts repository one. I just don't know how
> compatible these are at the moment. For the time being, it is lower risk
> for our astronomers for ESO to maintain its own package repository, which
> it has full control over.
> Would it nevertheless make sense to push our changes to the default
> MacPorts repository in the future? Perhaps. We have considered it and will
> likely revisit this idea again down the line.
>

If you are the maintainer, you should be able to have as much control as
you wish over the Portfiles and the release cycle. There is no "release
cycle" for ports really, you can just update them whenever you please.

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

Re: Easy access to external repositories.

[David Strubbe]

A general question: what is the purpose of adding a repo for the ESO
software, as opposed to just committing the individual Portfiles that exist
in that repo to the standard MacPorts repo?

David

On Mon, Jun 1, 2015 at 11:44 AM, René J.V.  wrote:

> On Monday June 01 2015 15:56:32 Thibaut Paumard wrote:
>
> > One usual and easy solution to this problem is to use lexicographic
> > order and let the files start with a number: e.g.
> >   10_macports.conf
> > is the default, most third party repositories should have a name
>
> Which also means that you have to rename all files if you want to change
> order.
>
> It would be easier to use a separate file in sources.conf.d, say
> sources.conf.d/order which lists the files in the desired order of
> priority, possibly with tags like nosync .
> Of course then you're back to rewriting a file like with sources.conf
> itself, but one with a simpler format, and less crucial. For instance, base
> could reject the file and use only sources.conf if there's some form of
> corruption.
>
> > I tried to write the Portfile so that when one tries to uninstall it, it
> > will undo whatever was done during installation.
>
> So is there 1 Portfile per external repository? Did you handle
> deactivation or did you simply make it impossible (which would probably be
> the best thing to do but I don't know if it can be done).
>
> I still think that whatever can be done with a Portfile in this domain can
> also (and better) be done with a dedicated script, a la add-port-repository.
>
> All this got me wandering to wondering about hacking a version of APT on
> top of the port command ... no, I don't think I just admitted that :)
>
> > I was just thinking that since this [per-port priorities] hasn't been
> done before, it is going to
> > have a higher risk and likely take longer to "bring to market".
>
> I doubt that. AFAIK MacPorts uses indices ("portindex" files) internally,
> and I find it difficult to believe that it'd be hard to get this right
> without long periods of testing.
> Anyway I think that those port priorities would be optional, fall back to
> the default priority if they don't compute, and at least in a 1st
> implementation only concern from what repository a given port is installed.
> That's not particularly hard to implement:
>
> if port has priority setting
>   set prefdir to port preferred repository
>   if prefdir = "default" set prefdir to default repository # redundant but
> what the heck
>   set portdir to port preferred repository if it exists
> set portdir to default repository if unset
>
> R.
> ___
> macports-dev mailing list
> macports-dev@lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/macports-dev
>
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: GSoC Project: Revitalizing Pallet

[David Strubbe]

Why is it called Pallet?

David

On Wed, May 6, 2015 at 8:59 PM, Mark Anderson  wrote:

> I love it. I agree with Ryan, I think a portfile Editor/IDE should be a
> separate MacPorts.framework project from Pallet.
>
> —Mark
> ___
> Mark E. Anderson 
>
> On Wed, May 6, 2015 at 8:40 PM, Ryan Schmidt 
> wrote:
>
>>
>> On May 6, 2015, at 5:14 PM, Kyle Sammons wrote:
>>
>> > My name's Kyle Sammons and I've been accepted into this years GSoC. I
>> was also a GSoC participant for MacPorts last year working on Project
>> "Clean-up Stuff", which created the "port doctor" and "port reclaim"
>> commands.
>> >
>> > My project for this year is to get Pallet, the MacPorts GUI, up and
>> running with the support for newest versions of OS X and XCode. After that,
>> I intend to give it, and the Framework, some more modern-day-MacPorts
>> features. No features are set in stone as of yet, but I'm considering
>> adding doctor, reclaim, rev-upgrade, a progress bar, or possibly even the
>> ability to edit portfiles.
>> >
>> > Once again, none of these potential features are set in stone so if you
>> guys would like to suggest any that would be nice to have, or have some
>> questions/concerns about the project, feel free to shoot me an email.
>>
>> Great idea! I would only propose that you *not* pursue the idea of
>> letting people edit portfiles, as that opens up lots of possibilities for
>> problems. Pallet should be the utility for users who are not comfortable
>> using the command line. Those users don't need to be editing portfiles.
>>
>>
>>
>> ___
>> macports-dev mailing list
>> macports-dev@lists.macosforge.org
>> https://lists.macosforge.org/mailman/listinfo/macports-dev
>>
>
>
> ___
> macports-dev mailing list
> macports-dev@lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/macports-dev
>
>
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Buildbot cruft: /opt/local/bin/mvn31

[David Strubbe]

How about using "ls -lt" in an appropriate step of the Portfile to get this
info?

David

On Tue, Mar 17, 2015 at 2:35 PM, Marko Käning  wrote:

> Hi Blair,
>
> On 17 Mar 2015, at 19:25 , Blair Zajac  wrote:
> > Error: org.macports.destroot for port maven31 returned: ln:
> /opt/local/bin/mvn31: File exists
>
> you seem to have run in a similar issue like we did with rkward a few days
> ago when
> the buildbots hung themselves.
>
> We had that already last year and solved it by deleting our files in a
> pre-activate
> phase. You might want to refer to the relevant thread [1].
>
> Up to now I don’t have any information from Apple’s sysadmins, as to what
> the
> timestamps of the unexpectedly existing files are…
>
> Greets,
> Marko
>
>
> [1]
> https://lists.macosforge.org/pipermail/macports-dev/2015-March/029972.html
> ___
> macports-dev mailing list
> macports-dev@lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/macports-dev
>
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Current best practice to select GCC compiler in Portfile

[David Strubbe]

Hi Rainer,

Sean did indeed add the default_variants to the compilers portgroup in the
last month or two. Perhaps you were trying before then.

David

On Thu, Feb 26, 2015 at 9:30 AM, Rainer Müller  wrote:

> On 2015-02-26 14:22, Artur Szostak wrote:
> > Let me rephrase: Assuming I have to use gcc rather than clang. What
> > is the standard/best way to do that in a Portfile?
> >
> > I have a numerical code that gives inferior results with clang
> > compared to gcc. Thus, I need to make sure the port uses GCC. Also,
> > the code is C99, so that should mitigate any ABI issues.
>
> Starting with Xcode 6, there are only clang and macports-clang-* in the
> default list of usable compilers. To use gcc you explicitly need to
> whitelist it.
>
> The simplest and least flexible would be to just use a specific version
> of gcc:
>
>   configure.compiler macports-gcc-4.9
>
>
> To be more flexible, you can also create variants that allow to choose
> the version of gcc with +gcc49, +gcc48, etc:
>
>   variant gcc47 description {Build with MacPorts gcc 4.7 compiler}
> conflicts gcc48 gcc49 {
>   configure.compiler macports-gcc-4.7
>   }
>
>   variant gcc48 description {Build with MacPorts gcc 4.8 compiler}
> conflicts gcc47 gcc49 {
>   configure.compiler macports-gcc-4.8
>   }
>
>   variant gcc49 description {Build with MacPorts gcc 4.9 compiler}
> conflicts gcc47 gcc48 {
>   configure.compiler macports-gcc-4.9
>   }
>
>   if {![variant_isset gcc47] && ![variant_isset gcc48] && ![variant_isset
> gcc49]} {
>   default_variants +gcc49
>   }
>
>
> Recently, there was also a new compilers port group added to the ports
> tree which is supposed to generate these variants automatically.
> However, as far as I was able to test it, it does not automatically
> handle the selection of a default compiler yet as shown in the example
> above using the variant_isset conditionals, so you still need to add
> that. Manually adding this would make the construct a bit fragile as
> new versions will be added to the port group in the future.
>
>   compilers.choosecc cpp
>   compilers.setup -clang -llvm -dragonegg
>   default_variants+gcc49
>
> @Sean, David: did I do something wrong or is automatic selection just
> not supported yet by the compilers port group?
>
> Rainer
>
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [128393] trunk/dports/science/berkeleygw/Portfile

[David Strubbe]

Thanks, fixed in r128435.

On Thu, Nov 20, 2014 at 8:18 PM, Ryan Schmidt 
wrote:

> On Nov 20, 2014, at 12:23 PM, dstru...@macports.org wrote:
> >
> > Revision
> > 128393
> > Author
> > dstru...@macports.org
> > Date
> > 2014-11-20 10:23:26 -0800 (Thu, 20 Nov 2014)
> > Log Message
> >
> > berkeleygw: Enable support for MPI variants with scalapack.
> > Modified Paths
> >
> >   • trunk/dports/science/berkeleygw/Portfile
>
> > +if {[mpi_variant_isset]} {
> > +build.args-append PARAFLAG="-DMPI" MATHFLAG="-DUSESCALAPACK"
> C_PARAFLAG="-DPARA" \
> > +SCALAPACKLIB="-L/opt/local/lib/ -lscalapack"
> > +}
>
> Here, /opt/local should be changed to ${prefix}.
>
>
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: passing default variants to dependencies?

[David Strubbe]

All right, but can you clarify about default variants: is it true that
default variants are not passed to dependencies, but all other variants
are? And, is there any good reason for this? It would solve my problem
immediately if they were passed on.


On Sun, Nov 16, 2014 at 5:17 PM, Joshua Root  wrote:

> Asking to ensure that your dependencies have certain variants applied is
> depending on variants. Restricting it to variants that the dependent
> port has itself doesn't change the fundamental issues.
>
> - Josh
>
> On 2014-11-17 09:05 , David Strubbe wrote:
> > Thanks for the comments. I'm not trying to depend on a variant, and I am
> > already using active_variants (that is what blocks fftw-3 without a
> > Fortran variant). I just wonder why default variants are not passed to
> > dependencies (because other variants do seem to be passed to
> > dependencies) and whether there is some way to get around this.
> >
> > David
> >
> > On Sun, Nov 16, 2014 at 5:01 PM, Joshua Root  > <mailto:j...@macports.org>> wrote:
> >
> > On 2014-11-17 08:52 , David Strubbe wrote:
> > > Hi all,
> > >
> > > Is there a way to make default variants be passed to dependencies
> when
> > > installing them? My octopus port depends on fftw-3 and needs it to
> be
> > > built with a Fortran variant. octopus has +gcc48 as default
> > variant, and
> > > building fftw-3 +gcc48 will work. But on the buildbots it just
> builds
> > > fftw-3 with no variant for the dependency, which then does not
> > work. How
> > > can I solve this?
> > >
> > > Thanks,
> > > David
> >
> > No, you can't depend on a variant. This isn't buildbot-specific;
> anyone
> > running 'port install octopus' from a fresh installation will see the
> > same result.
> >
> > - Josh
>
>
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: passing default variants to dependencies?

[David Strubbe]

Thanks for the comments. I'm not trying to depend on a variant, and I am
already using active_variants (that is what blocks fftw-3 without a Fortran
variant). I just wonder why default variants are not passed to dependencies
(because other variants do seem to be passed to dependencies) and whether
there is some way to get around this.

David

On Sun, Nov 16, 2014 at 5:01 PM, Joshua Root  wrote:

> On 2014-11-17 08:52 , David Strubbe wrote:
> > Hi all,
> >
> > Is there a way to make default variants be passed to dependencies when
> > installing them? My octopus port depends on fftw-3 and needs it to be
> > built with a Fortran variant. octopus has +gcc48 as default variant, and
> > building fftw-3 +gcc48 will work. But on the buildbots it just builds
> > fftw-3 with no variant for the dependency, which then does not work. How
> > can I solve this?
> >
> > Thanks,
> > David
>
> No, you can't depend on a variant. This isn't buildbot-specific; anyone
> running 'port install octopus' from a fresh installation will see the
> same result.
>
> - Josh
>
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

passing default variants to dependencies?

[David Strubbe]

Hi all,

Is there a way to make default variants be passed to dependencies when
installing them? My octopus port depends on fftw-3 and needs it to be built
with a Fortran variant. octopus has +gcc48 as default variant, and building
fftw-3 +gcc48 will work. But on the buildbots it just builds fftw-3 with no
variant for the dependency, which then does not work. How can I solve this?

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

Re: [127404] trunk/dports/science/sparskit/Portfile

[David Strubbe]

Yes, there are many separate tests and they output in a different formats.
I think some just give a number and a reference with no suggestion on what
is an acceptable tolerance. So it is a bit of work to make some script that
would check all this properly.

On Sun, Nov 2, 2014 at 1:55 PM, Ryan Schmidt 
wrote:

>
> On Nov 2, 2014, at 12:51 PM, David Strubbe wrote:
>
> > The point is that there is no check unfortunately on whether the tests
> passed. You have to read through the results to see whether they are ok. So
> the test phase would fail only if execution of one of the steps failed,
> unlike the typical situation where 'make check' would give an error code if
> a test gave an incorrect answer. A suggestion on how to make that clearer
> would be welcome.
>
> Ah ok, I see. I suppose making the test phase exit with a non-zero code is
> difficult to do?
>
>
>
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [127404] trunk/dports/science/sparskit/Portfile

[David Strubbe]

Hi Ryan,

The point is that there is no check unfortunately on whether the tests
passed. You have to read through the results to see whether they are ok. So
the test phase would fail only if execution of one of the steps failed,
unlike the typical situation where 'make check' would give an error code if
a test gave an incorrect answer. A suggestion on how to make that clearer
would be welcome.

David

On Sun, Nov 2, 2014 at 1:39 PM, Ryan Schmidt 
wrote:

>
> > On Oct 27, 2014, at 9:53 AM, dstru...@macports.org wrote:
> >
> > Revision
> > 127404
> > Author
> > dstru...@macports.org
> > Date
> > 2014-10-27 07:53:49 -0700 (Mon, 27 Oct 2014)
> > Log Message
> >
> > sparskit: Add notice on where to see test results. Use only 'fc' from
> compilers portgroup for simplicity and consistency.
>
> > +post-test {
> > +ui_notice "Examine log file for test results."
>
> Is this different from other ports?
>
>
>
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Getting the entire configure.cflags variable

[David Strubbe]

You could alternately try to patch the code to pay attention to CFLAGS. I'm
not sure how complicated that would be in the build system.

David

On Thu, Oct 2, 2014 at 6:13 PM, Ryan Schmidt 
wrote:

>
> On Oct 2, 2014, at 4:29 PM, Lawrence Velázquez wrote:
> >
> > On Oct 2, 2014, at 5:13 PM, Ryan Schmidt wrote:
> >
> >> On Oct 2, 2014, at 4:10 PM, Lawrence Velázquez wrote:
> >>
> >>> I suspect the idea is to prevent ports from clearing CFLAGS and such.
> >>
> >> I think it's more that in many cases -- arch flags for example, or
> which C++ stdlib flag to use -- MacPorts won't know what to put in the
> cflags until after the rest of the port has been processed. What if you
> append something to configure.cflags, then later turn on (or turn off) the
> universal variant? Then the wrong arch flags will be in configure.cflags.
> This is why (as I understand it) MacPorts doesn't put them in until the
> port has been completely evaluated.
> >
> > For my part, when I implemented configure.cxx_stdlib, I was primarily
> thinking about preventing Portfiles from trashing the "-stdlib" argument.
> Augmenting configure.cxxflags seemed preferable to arcane Tcl sorcery.
>
> But that's just it. The -stdlib arg *isn't* appended to
> configure.cxxflags; it's added to the CXXFLAGS environment variable in
> configure_main; ports have no opportunity to inspect or modify this value.
> I had to manually add code to the pure portgroup to handle
> configure.cxx_stdlib because of this. Any port which sets "use_configure
> no" because it does not use a standard build system like autotools or cmake
> will be similarly affected.
>
>
> ___
> macports-dev mailing list
> macports-dev@lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/macports-dev
>
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [125581] trunk/dports/science/abinit/Portfile

[David Strubbe]

That worked, thanks for the tip!

David

On Sun, Sep 21, 2014 at 10:28 PM, Ryan Schmidt 
wrote:

> On Sep 22, 2014, at 12:21 AM, dstru...@macports.org wrote:
> >
> > Revision
> > 125581
> > Author
> > dstru...@macports.org
> > Date
> > 2014-09-21 22:21:07 -0700 (Sun, 21 Sep 2014)
> > Log Message
> >
> > abinit: temporarily include config.log in main log file for debugging
> buildbot configure failure on Mountain Lion.
> > Modified Paths
> >
> >   • trunk/dports/science/abinit/Portfile
>
> > +# This is a temporary measure for debugging configure failure on
> Mountain Lion buildslave.
> > +
> > +#checking for gcc... mpicc-mpich-mp
> > +#checking whether the C compiler works... no
> > +
> > +post-configure {
> > +system -W ${worksrcpath} "cat config.log"
> > +}
>
> Good idea! Unfortunately because the configure script fails, the
> post-configure block doesn't get run.
>
> You'd have to do something like set the configure.cmd to ./configure ||
> true to continue on even when in fails.
>
>
>
>
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: echo script output to the display

[David Strubbe]

One approach you could use for the test output is to redirect it into a
file, and then put a ui message to look at that file for the results.

David

On Sat, Sep 20, 2014 at 2:11 PM, Mark Brethen 
wrote:

>
> On Sep 20, 2014, at 10:30 AM, Clemens Lang  wrote:
>
> > Hi,
> >
> > - On 20 Sep, 2014, at 16:27, Mark Brethen mark.bret...@gmail.com
> wrote:
> >
> >> You're thinking it should run automatically instead of user setting?
> >
> >
> > Setting test.run and test.cmd doesn't make MacPorts run the tests
> automatically.
> > You still have to run `sudo port test` explicitly to run tests.
> >
> >> Does that change where the output is sent?
> >
> > No. I'm not aware of a proper method to do this, either. You might be
> > able to fiddle with MacPorts' internal verbosity setting, but that
> > would be a hack.
> >
> > --
> > Clemens Lang
>
> Is the test phase for debugging?
>
> This script tests each math package in a CAS program after build. Would it
> would make more sense to keep this as a variant and the script at
> post-build?
>
> Mark
>
>
>
>
> ___
> macports-dev mailing list
> macports-dev@lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/macports-dev
>
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

access files on buildbot?

[David Strubbe]

Hi all,

Is there a way to access a file such as a config.log from a failed port
build on a buildslave?

After my recent changes r125398 and r125404 to the abinit port, the build
failed on Mountain Lion, in the configure stage, as follows:

checking for mpicc-mpich-mp... /opt/local/bin/mpicc-mpich-mp
checking for gcc... mpicc-mpich-mp
checking whether the C compiler works... no
configure: error: in
`/opt/local/var/macports/build/_opt_mports_dports_science_abinit/abinit/work/abinit-7.8.2':
configure: error: C compiler cannot create executables
See `config.log' for more details

(http://build.macports.org/builders/buildports-mtln-x86_64/builds/17388)

I checked that the same happened the last time a revision touched the port.
I am not sure how to tackle the problem other than to see what config.log
has to say. I am running Mountain Lion on my laptop and I built the same
version and everything worked fine, so I am not sure what is different on
the buildslave from my machine.

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

Re: Ticket #44479

[David Strubbe]

Maybe you are just looking at the list of open tickets that are
submissions, i.e. only the ones that haven't made it in. A large number
certainly have been accepted over the years.

David


On Mon, Aug 4, 2014 at 2:22 PM, Nathan Wehr  wrote:

> I’m fairly new to MacPorts, and I have a port that I submitted a few days
> ago. It hasn’t received any attention in the last few days. I’m just
> wondering what the status is.
>
> I’m also noticing that all of the previous port submission by other users
> haven’t made it into the ports tree as far as i can tell (even going back a
> few years). What does one have to do to get the port accepted?
>
> Ticket #44479 
>
> ||
> ||  Nathan Wehr
> ||  Designer and Web/Software Developer
> ||
> ||  gtolem...@gmail.com 
> ||  (540) 395-9945 
> ||
>
>
>
>
>
>
> ___
> macports-dev mailing list
> macports-dev@lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/macports-dev
>
>
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Binary distributability of codeblocks: GPL & OpenSSL conflict

[David Strubbe]

Is there a simple way to determine the sequence of dependencies, like "
ffmpeg->gnutls->nettle->openssl" ?

David


On Thu, Jul 10, 2014 at 6:51 PM, David Evans  wrote:

> On 7/10/14 3:18 PM, Mojca Miklavec wrote:
> > Actually, something similar is true for ffmpeg as well:
> >
> > "ffmpeg" is not distributable because its license "gpl" conflicts with
> > license "OpenSSL" of dependency "openssl"
> >
> ffmpeg->gnutls->nettle->openssl
>
>
> ___
> macports-dev mailing list
> macports-dev@lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/macports-dev
>
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: empty error message on activation of texlive-common

[David Strubbe]

Hm, similar, but I didn't get the message "Follow
http://guide.macports.org/#project.tickets to report a bug."

Seeing what was written in that ticket, I tried "port log texlive-common"
and got the following. I'm not sure if that gives any further insight.

David

DEBUG: texlive-common has no conflicts
DEBUG: activate phase started at Mon Jul  7 13:02:34 EDT 2014
DEBUG: Executing proc-pre-org.macports.activate-activate-0
DEBUG: Executing org.macports.activate (texlive-common)
DEBUG: Changing to port directory:
/opt/local/var/macports/registry/portfiles/texlive-common-2013_0/262d7eea3bb2898396497218a856f330b058d55c58552609aa010ea520eabefa-5752
DEBUG: OS darwin/12.5.0 (Mac OS X 10.8) arch i386
DEBUG: Sourcing PortGroup texlive 1.0 from /opt/local/var/macports/sources/
rsync.macports.org/release/tarballs/ports/_resources/port1.0/group/texlive-1.0.tcl
DEBUG: universal_variant is false, so not adding the default universal
variant
DEBUG: Running callback portconfigure::add_automatic_compiler_dependencies
DEBUG: Finished running callback
portconfigure::add_automatic_compiler_dependencies
DEBUG: Running callback portbuild::add_automatic_buildsystem_dependencies
DEBUG: Finished running callback
portbuild::add_automatic_buildsystem_dependencies
DEBUG: Starting logging for texlive-common
DEBUG: Executing org.macports.main (texlive-common)
DEBUG: clean phase started at Mon Jul  7 13:02:35 EDT 2014
--->  Cleaning texlive-common
DEBUG: Executing org.macports.clean (texlive-common)
--->  Removing work directory for texlive-common
DEBUG: No work directory found to remove at
/opt/local/var/macports/build/_opt_local_var_macports_registry_portfiles_texlive-common-2013_0_262d7eea3bb2898396497218a856f330b058d55c58552609aa010ea520eabefa-5752/texlive-common
DEBUG: No work directory found to remove at
/Users/dstrubbe/.macports/opt/local/var/macports/build/_opt_local_var_macports_registry_portfiles_texlive-common-2013_0_262d7eea3bb2898396497218a856f330b058d55c58552609aa010ea520eabefa-5752/texlive-common
DEBUG: Removing directory:
/opt/local/var/macports/logs/_opt_local_var_macports_registry_portfiles_texlive-common-2013_0_262d7eea3bb2898396497218a856f330b058d55c58552609aa010ea520eabefa-5752/texlive-common



On Mon, Jul 7, 2014 at 1:58 PM, Joshua Root  wrote:

> On 2014-7-8 03:18 , David Strubbe wrote:
> > Hello all,
> >
> > I just got this output on upgrading ports, with an error message for
> > activating texlive-common which is empty. Anyone know what is going on?
> >
> > David
> >
> > ...
> > --->  Fetching archive for texlive-common
> > --->  Attempting to fetch texlive-common-2014_0.darwin_12.noarch.tbz2
> > from
> >
> http://mse.uk.packages.macports.org/sites/packages.macports.org/texlive-common
> > --->  Attempting to fetch
> > texlive-common-2014_0.darwin_12.noarch.tbz2.rmd160 from
> >
> http://mse.uk.packages.macports.org/sites/packages.macports.org/texlive-common
> > --->  Installing texlive-common @2014_0
> > --->  Cleaning texlive-common
> > --->  Deactivating texlive-common @2013_0
> > --->  Cleaning texlive-common
> > --->  Activating texlive-common @2014_0
> > Error: org.macports.activate for port texlive-common returned:
> > --->  Computing dependencies for texlive-bin
> > --->  Fetching archive for texlive-bin
> > --->  Attempting to fetch texlive-bin-2014_1+x11.darwin_12.x86_64.tbz2
> > from
> >
> http://mse.uk.packages.macports.org/sites/packages.macports.org/texlive-bin
> > --->  Attempting to fetch
> > texlive-bin-2014_1+x11.darwin_12.x86_64.tbz2.rmd160 from
> >
> http://mse.uk.packages.macports.org/sites/packages.macports.org/texlive-bin
> > --->  Installing texlive-bin @2014_1+x11
> > --->  Cleaning texlive-bin
> > ...
>
> Could be this? <https://trac.macports.org/ticket/43210>
>
> Some error messages were removed a while back because they were thought
> to be redundant, but it looks like they weren't (at least not in all
> circumstances).
>
> - Josh
>
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

empty error message on activation of texlive-common

[David Strubbe]

Hello all,

I just got this output on upgrading ports, with an error message for
activating texlive-common which is empty. Anyone know what is going on?

David

...
--->  Fetching archive for texlive-common
--->  Attempting to fetch texlive-common-2014_0.darwin_12.noarch.tbz2 from
http://mse.uk.packages.macports.org/sites/packages.macports.org/texlive-common
--->  Attempting to fetch
texlive-common-2014_0.darwin_12.noarch.tbz2.rmd160 from
http://mse.uk.packages.macports.org/sites/packages.macports.org/texlive-common
--->  Installing texlive-common @2014_0
--->  Cleaning texlive-common
--->  Deactivating texlive-common @2013_0
--->  Cleaning texlive-common
--->  Activating texlive-common @2014_0
Error: org.macports.activate for port texlive-common returned:
--->  Computing dependencies for texlive-bin
--->  Fetching archive for texlive-bin
--->  Attempting to fetch texlive-bin-2014_1+x11.darwin_12.x86_64.tbz2 from
http://mse.uk.packages.macports.org/sites/packages.macports.org/texlive-bin
--->  Attempting to fetch
texlive-bin-2014_1+x11.darwin_12.x86_64.tbz2.rmd160 from
http://mse.uk.packages.macports.org/sites/packages.macports.org/texlive-bin
--->  Installing texlive-bin @2014_1+x11
--->  Cleaning texlive-bin
...
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [121204] trunk/dports

[David Strubbe]

How does one make XQuartz's xterm support UTF-8?

David


On Sun, Jun 22, 2014 at 11:26 PM, Mihai Moldovan  wrote:

> * On 23.06.2014 02:12 am, Michael Dickens wrote:
> > That said, it's quite possible that I've messed up my xterm settings
> > somehow, which is causing the locking (me, and David apparently).  I
> > believe this has to do with how the xterm interprets the streamed
> > characters (sort of like setting LANG="C" to get SED to work), but since
> > it happens rarely with the ports I use regularly I've never really
> > investigated.
>
> Sarcasm by me aside, I'd really invite to you to try rxvt-unicode, if
> you're in
> need of an X11-based terminal. xterm is quite old, not so well maintained
> and
> lacks many features.
>
> If you're adding an item for urxvt in the X11 "Applications" menu, it's
> just as
> easily accessible as xterm. Not to mention faster and richer in features.
>
> Or is there any specific reason why GNU radio needs xterm I've been
> missing?
> (Certainly possible, I'm really just asking.)
>
>
> > I don't see this as a critical issue with MacPorts.  I was more agreeing
> > with David's comment that although using UTF-8, as Ryan wrote: "should
> > not be a problem", it can be a problem for some users -- including some
> > who are not average users; I hope I'm not considered just an average
> > user! - MLD
>
> No, you're not. I didn't mean to imply that. :)
> If stuff is breaking with UTF-8, it's better to handle/fix the baseline
> issue
> and be "future-proof", instead of limiting UTF-8 usage because of bugs.
> (And I'd
> rather see UTF-8 a "current" technology, than a "future" one.)
>
> I've even seen compilers and GNU tools spit out UTF-8 characters, like
> those
> "smart quotes" Ryan mentioned.
> xterm does have (maybe incomplete?) support for UTF-8, but it seems to be
> optional and may have to be turned of specifically. In any case, software
> seeing
> a UTF-8 locale has a "right" to make use of that, even if it means
> crashing xterm.
>
> In spite of that, maybe MacPorts should ship an
> ${prefix}/etc/X11/Xresources
> file enabling Unicode support by default? UTF-8 locales are the default on
> OS X
> anyway.
>
>
>
> Mihai
>
>
>
> ___
> macports-dev mailing list
> macports-dev@lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/macports-dev
>
>
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [121204] trunk/dports

[David Strubbe]

Hi Ryan,

I agree that it "should" not be a problem, but it actually crashed both
'port search' and 'svn diff' commands for me which seemed like a pretty
significant problem. Also that character renders in various different ways
(for cat, emacs, etc.), mostly erroneous, so it fails in the goal of
communication if you get à or ? instead of the desired character.

David


On Sat, Jun 21, 2014 at 7:12 PM, Ryan Schmidt 
wrote:

>
> On Jun 19, 2014, at 9:51 PM, dstru...@macports.org wrote:
>
> > czmq, crossroads, py-zmq: changed references to 0MQ that used the O with
> slash special character. This was displayed as à in commands such as 'port
> search' and indeed crashed the command so that no further output would be
> shown after it (at least on my machines). Same happened for 'svn diff' even
> for this commit. By contrast, in other places this library is referred to
> as 0MQ or ZeroMQ, which does not cause such problems.
>
> Use of non-ASCII characters in portfiles should not be a problem.
> Portfiles are defined as being UTF-8 files and they display fine for me as
> such in the terminal. Many other ports use UTF-8 characters, such as smart
> quotes, and I don't think we should attempt to go back to using ASCII only
> because it's just so limiting.
>
>
>
>
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [120684] trunk/dports/devel/srecord/Portfile

[David Strubbe]

Hi Ryan,

Why is using a patchfile instead of reinplace preferable?

David


On Sun, Jun 8, 2014 at 3:33 PM, Ryan Schmidt 
wrote:

> On Jun 5, 2014, at 12:30 PM, m...@macports.org wrote:
>
> > Revision
> > 120684
> > Author
> > m...@macports.org
> > Date
> > 2014-06-05 10:30:25 -0700 (Thu, 05 Jun 2014)
> > Log Message
> >
> > srecord: Update to version 1.63. (#43916)
> > Modified Paths
> >
> >   • trunk/dports/devel/srecord/Portfile
>
> > @@ -30,8 +30,17 @@
> >
> >offsets, split and unsplit for memory striping
> schemes.
> >
> >  homepage  http://srecord.sourceforge.net/
> >  master_sites  sourceforge
> >
> > -checksums md5 8fce124d47f23b4aa187c3b8eebc9fd7
> >
> > +checksums rmd160  668d5dc75960666a7c99509f39ecd2602891c384 \
> > +  sha256
>  78fec76d04424506e319f59b19a520428a7449ed087a67e1779fa2996992bf1a
> > +depends_build port:libtool
> >
> >  configure.cflags-append  "-I${prefix}/include"
> >
> > -configure.args--mandir=${destroot}${prefix}/share/man
> >
> > +configure.env-append "LIBTOOL=glibtool"
>
> Consider specifying the absolute path to glibtool i.e.
> ${prefix}/bin/glibtool, just in case the user has an unusual binpath
> configured.
>
>
> >  destroot.destdir  prefix=${destroot}${prefix}
> >
> >
> >
> > +pre-configure {
> > +reinplace {s|@bindir@|$(prefix)/bin|} ${worksrcpath}/Makefile.in
> > +reinplace {s|@mandir@|$(prefix)/share/man|}
> ${worksrcpath}/Makefile.in
> > +reinplace {s|@datarootdir@|$(prefix)/share|}
> ${worksrcpath}/Makefile.in
> > +reinplace {s|@libdir@|$(prefix)/lib|} ${worksrcpath}/Makefile.in
> > +reinplace {s|@includedir@|$(prefix)/include|}
> ${worksrcpath}/Makefile.in
> > +}
>
> Could this be done as a normal patchfile instead? I notice you're using
> parentheses e.g. "$(prefix)" which is Makefile variable expansion syntax,
> not curly brackets e.g. "${prefix}" which would be the Tcl variable
> expansion syntax, so no variable substitution is happening here at
> reinplace time anyway.
>
> ___
> macports-dev mailing list
> macports-dev@lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/macports-dev
>
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Identifying possible situations for interactivity

[David Strubbe]

Here's another possible scenario: installing a port that requires a
dependency to have a certain variant, but this variant is not set. It could
offer to reinstall the dependency with that variant.

David


On Mon, May 12, 2014 at 10:04 AM, Shashwat Pandey <
devshashwatpan...@gmail.com> wrote:

> Hi all
>
> I am working on the Interactive Port Command project for GSoC 2014. To
> begin with my project i first need to identify places where implementing
> interactivity(user decisions/approvals) will stop Macports from quitting as
> the user input will resolve any conflicts. In general terms i have to
> identify any place where interactivity makes sense.
>
> For this I need the help of the list. Below are all places known to me.
> Please help me by adding to it.
>
> - When trying to install a port that conflicts with a port you already
>have installed, ask the user whether the conflicting port should be
>disabled.
> - When trying to install a port but one of the files installed by this
>port is already present, ask the user whether the file should be
>overwritten.
> - When a user tries to install a port, display a list of ports that
>will be installed as dependencies and ask for confirmation (unless
>there aren't any dependencies to be installed), like apt-get does.
> - Asking for permission in a situation where uninstalling a package will
> break another package that's still installed and depends on the
> to-be-uninstalled package.
>
> ___
> macports-dev mailing list
> macports-dev@lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/macports-dev
>
>
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Compiler variants in portfile

[David Strubbe]

You can use "clang -E" to preprocess Fortran in a way compatible with gcc's
cpp (at least on the several codes I have tested it with).

David


On Thu, Apr 17, 2014 at 1:16 PM, Sean Farley  wrote:

>
> Sébastien Maret  writes:
>
> > Le 17 avr. 2014 à 18:13, Sean Farley  a écrit :
> >
> >> Sébastien Maret  writes:
> >>
> >>> Le 17 avr. 2014 à 01:19, Sean Farley  a écrit :
> >>>
>  Sébastien Maret  writes:
> 
> > Le 27 mars 2014 à 22:03, Ryan Schmidt  a
> écrit :
> >
> >> On Mar 27, 2014, at 09:14, Sébastien Maret wrote:
> >>
> >>> I’m writing a portfile for a software written in C/C++ and
> Fortran77/90:
> >>> http://trac.macports.org/ticket/42886
> >>>
> >>> Following a comment macsforever2000, I’ve modified my original
> port to provide several fortran compiler variants. However, my port
> requires that CC, CXX, CPP, and FC/F77 are all from a gcc variant. For
> example, it's not possible to compile it using CC=clang and
> FC=gfortran-mp-4.8. How can I modify it so that all compilers come from the
> same compiler suite?
> >>>
> >>> Thanks in advance for your advices.
> >>
> >> You do know that as of Mavericks, trying to compile C++ code with
> anything other than clang is a fool’s errand, right?
> >>
> >> https://trac.macports.org/wiki/FAQ#libcpp
> >
> > No, I didn’t know that.
> >
> >> *Why* is it not possible to compile your software using CC=clang
> and FC=gfortran-mp-4.8?
> >
> > I tried that but the compilation failed. I don’t exactly why but
> I’ll have a closer look.
> 
>  Sorry for the late reply, but it took me a while to catch up. Ryan is
>  right, of course. You should really figure out why they aren't
> compiling
>  and try to fix those errors.
> >>>
> >>> Thanks for your answer.
> >>>
> >>> I found the problem: the link was done against libstdc++ instead if
> libc++. I’ve fixed this and I’ve just posted a revised version of the port
> on the tracker.
> >>
> >> Looking at the portfile, things seem mostly fine. A few comments (which
> >> will hopefully help start documenting the compilers portgroup :-)
> >>
> >> - compilers.choose is really meant to serve as a way to isolate a c-only
> >>  or fortran-only build; since you specify both, you don't need it
> >
> > But isn’t this needed to set both CC, FC and CPP ?
>
> No, if you leave compilers.choose blank, then it will set all the
> compilers.
>
> >> - removing the clang variants only stops macport's clang compilers from
> >>  being used; this is fine but since you don't need c++ you could mix
> >>  clang with gfortran
> >
> > Indeed I do need C++. And since a Fortran compiler is also needed, I
> would prefer to compiling Fortran and C with compilers from the same
> compiler suite (GCC) to avoid link problems. In addition the package
> requires CPP from GCC to compile properly (it is used in a non-standard way
> to pre-process Fortran code, and this does not work with Apple’s CPP).
>
> If you need C++, then you forgot to mention it in compilers.choose
> (missing 'cxx'). Also, "non-standard way to pre-process Fortran code"
> ... I didn't realize Fortran had a standard ;-P
>
> > In fact I removed the clang variants because clang does not compile
> Fortran (same for drgaonegg). Why are variants present when require_fortran
> is set ?
>
> But dragonegg does compiler Fortran? That's mostly why it existed.
>
> >> - what is it with IRAM, Labri, and Enseeiht not using autoconf? is
> >>  everyone in France allergic to autotools?
> >
> > I’m not...  In fact, I would love them to use autotools. It would make
> the packaging a lot easier. I’ll forward your comment to them :-)
>
> MUMPS and SCOTCH code development can only be measured on geological
> timescales.
> ___
> macports-dev mailing list
> macports-dev@lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/macports-dev
>
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: curious dependency issues

[David Strubbe]

Well I really think this needs to be documented more clearly. The examples
in the guide do not mention it is a regex rather than the exact name of a
port, and that is the only documentation I have seen on it.

David


On Mon, Apr 7, 2014 at 8:46 PM, Ryan Schmidt wrote:

>
> On Apr 7, 2014, at 17:14, David Strubbe wrote:
>
> > Ok, I think I see what is going on here: apparently "port installed
> depends:XXX" returns all ports depending on port XXX -- OR a port that
> contains the string XXX.
>
> It's a regular expression search. So if you want the ports that depend on
> gcr, you could use:
>
> $ port echo depends:':gcr($|\s)'
> empathy
> epiphany
> evolution-data-server
> gnome-keyring
> gnome-online-accounts
> gnome3-core
> libgdata
> seahorse
> $
>
>
>
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: curious dependency issues

[David Strubbe]

Ok, I think I see what is going on here: apparently "port installed
depends:XXX" returns all ports depending on port XXX -- OR a port that
contains the string XXX. This seems like a bug, and gives very misleading
information.
* "gcr" appears to depend on itself because it depends on "libgcrypt".
* "gtk3" appears to depend on "gconf" because it depends on "pkgconfig".
* If I write "port installed depends:a" (despite there being no port called
"a") I get 8636 ports returned.
* The list returned from "port installed depends:libxc" includes the
dependencies not only of "libxc" but also of the entirely unrelated
"xorg-libxcb", "xorg-libXcomposite", and "xorg-libXcursor".

David


On Mon, Apr 7, 2014 at 6:01 PM, David Strubbe  wrote:

> Indeed, evidently "depends:" does some strange things which "depof:" does
> not.
>
> Though "man port" does not define "depends:", it is recommended here:
> https://guide.macports.org/#using.common-tasks.finddepending
> By contrast, "depof:" does not seem to appear in the guide.
>
> David
>
>
> On Mon, Apr 7, 2014 at 2:46 PM, Eric Gallager wrote:
>
>> I was under the impression that the "depends:" pseudo-portname and the
>> "depof:" portname were two separate things...
>>
>>
>>
>> On Mon, Apr 7, 2014 at 2:19 PM, David Strubbe  wrote:
>>
>>>  Hm, I guess I got "depends:" from suggestions in messages on this
>>> list. Using "port installed depof:gcr" gcr is not listed, so that is more
>>> reasonable. "depof:gtk3" does not list gconf, and "depof:gconf" does list
>>> gtk3. So it seems that "depends:" is buggy. Maybe it should be removed if
>>> it has been supplanted by "depof:".
>>>
>>> David
>>>
>>>
>>> On Mon, Apr 7, 2014 at 2:03 PM, Bradley Giesbrecht >> > wrote:
>>>
>>>> On Apr 7, 2014, at 9:12 AM, David Strubbe  wrote:
>>>> > Hi all,
>>>> >
>>>> > I found two strange things in using 'port installed depends:'. The
>>>> 'gcr' port appears to depend on itself, and gconf and gtk3 appear to depend
>>>> on each other. Does this make sense? Is it a bug in base or the Portfiles?
>>>>
>>>> I don't know if "depends:" is a bug but it is not documented in "man
>>>> port" whereas "depof:" is:
>>>> port installed depof:gcr
>>>>
>>>>
>>>> Regards,
>>>> Bradley Giesbrecht (pixilla)
>>>>
>>>>
>>>
>>> ___
>>> macports-dev mailing list
>>> macports-dev@lists.macosforge.org
>>> https://lists.macosforge.org/mailman/listinfo/macports-dev
>>>
>>>
>>
>
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: curious dependency issues

[David Strubbe]

Indeed, evidently "depends:" does some strange things which "depof:" does
not.

Though "man port" does not define "depends:", it is recommended here:
https://guide.macports.org/#using.common-tasks.finddepending
By contrast, "depof:" does not seem to appear in the guide.

David


On Mon, Apr 7, 2014 at 2:46 PM, Eric Gallager  wrote:

> I was under the impression that the "depends:" pseudo-portname and the
> "depof:" portname were two separate things...
>
>
>
> On Mon, Apr 7, 2014 at 2:19 PM, David Strubbe  wrote:
>
>> Hm, I guess I got "depends:" from suggestions in messages on this list.
>> Using "port installed depof:gcr" gcr is not listed, so that is more
>> reasonable. "depof:gtk3" does not list gconf, and "depof:gconf" does list
>> gtk3. So it seems that "depends:" is buggy. Maybe it should be removed if
>> it has been supplanted by "depof:".
>>
>> David
>>
>>
>> On Mon, Apr 7, 2014 at 2:03 PM, Bradley Giesbrecht 
>> wrote:
>>
>>> On Apr 7, 2014, at 9:12 AM, David Strubbe  wrote:
>>> > Hi all,
>>> >
>>> > I found two strange things in using 'port installed depends:'. The
>>> 'gcr' port appears to depend on itself, and gconf and gtk3 appear to depend
>>> on each other. Does this make sense? Is it a bug in base or the Portfiles?
>>>
>>> I don't know if "depends:" is a bug but it is not documented in "man
>>> port" whereas "depof:" is:
>>> port installed depof:gcr
>>>
>>>
>>> Regards,
>>> Bradley Giesbrecht (pixilla)
>>>
>>>
>>
>> ___
>> macports-dev mailing list
>> macports-dev@lists.macosforge.org
>> https://lists.macosforge.org/mailman/listinfo/macports-dev
>>
>>
>
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: New MacPorts web site

[David Strubbe]

Looks great. I suggest that in the info on the right-hand side for a given
port, you mention also the possibility of running "port test" when
available.

David


On Mon, Apr 7, 2014 at 4:13 PM,  wrote:

> Hi Ryan,
>
> I do like your work very much! This looks really cool!!!
>
> A few remarks:
>
> 1) Perhaps the icons at least could be blue to match the mandatory
> good-old MacPorts icon, which definitely needs to appear here instead of
> the new "macports". :)
>
> 2) I think that the headline is pretty large. I wouldn't mind it
> to be 30-50% smaller.
>
> 3) Apart from that I have to say that the site even looks great on
> a smartphone, which was my first way to check it out. :-)
>
>
> Great job. Thanks for giving the MacPorts site a fresh look. At the
> beginning of the discussion I was sceptical, but now I see that it indeed
> can be made much nicer than it currently is.
>
> Greets,
> Marko
> ___
> macports-dev mailing list
> macports-dev@lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/macports-dev
>
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: curious dependency issues

[David Strubbe]

Hm, I guess I got "depends:" from suggestions in messages on this list.
Using "port installed depof:gcr" gcr is not listed, so that is more
reasonable. "depof:gtk3" does not list gconf, and "depof:gconf" does list
gtk3. So it seems that "depends:" is buggy. Maybe it should be removed if
it has been supplanted by "depof:".

David


On Mon, Apr 7, 2014 at 2:03 PM, Bradley Giesbrecht wrote:

> On Apr 7, 2014, at 9:12 AM, David Strubbe  wrote:
> > Hi all,
> >
> > I found two strange things in using 'port installed depends:'. The 'gcr'
> port appears to depend on itself, and gconf and gtk3 appear to depend on
> each other. Does this make sense? Is it a bug in base or the Portfiles?
>
> I don't know if "depends:" is a bug but it is not documented in "man port"
> whereas "depof:" is:
> port installed depof:gcr
>
>
> Regards,
> Bradley Giesbrecht (pixilla)
>
>
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

curious dependency issues

[David Strubbe]

Hi all,

I found two strange things in using 'port installed depends:'. The 'gcr'
port appears to depend on itself, and gconf and gtk3 appear to depend on
each other. Does this make sense? Is it a bug in base or the Portfiles?

David

$ port installed depends:gcr
The following ports are currently installed:
  gcr @3.10.1_0
  gcr @3.10.1_1
  gcr @3.10.1_2 (active)
  ...

$ port installed depends:gconf | grep gtk
  ...
  gtk2 @2.24.23_0+no_x11+quartz (active)
  gtk3 @3.8.2_0+x11
  ...
  gtk3 @3.12.0_0+x11 (active)
$ port installed depends:gtk3
  ...
  gconf @2.32.4_2+quartz
  gconf @2.32.4_3+quartz (active)
  gcr @3.10.1_0
  gcr @3.10.1_1
  gcr @3.10.1_2 (active)
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

xcrysden and mesa702

[David Strubbe]

Hi Jeremy and others,

Do you have any suggestions regarding my submitted ports xcrysden (
https://trac.macports.org/ticket/41320) and mesa702 (
https://trac.macports.org/ticket/41319)? I understand it is undesirable to
introduce an old version of mesa, but I am not sure how to investigate the
incompatibility with more recent mesa versions.

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

Re: local PortGroup repo?

[David Strubbe]

Sorry I think I was confused. The ports are indeed uninstalled despite the
errors and warnings.

David


On Tue, Nov 12, 2013 at 1:41 AM, Joshua Root  wrote:

> If they're not uninstalling that would be a bug in base. The files are
> meant to be uninstalled and the registry entry removed regardless of
> whether executing the portfile succeeds.
>
> - Josh
>
> On 2013-11-12 17:16 , David Strubbe wrote:
> > I see. As it stands, I am not sure how to actually uninstall the ports I
> > installed with the test portgroup -- they are still there after the
> > failed uninstall. Any tip?
> >
> > David
> >
> >
> > On Tue, Nov 12, 2013 at 12:44 AM, Sean Farley  > <mailto:s...@macports.org>> wrote:
> >
> >
> > dstru...@mit.edu <mailto:dstru...@mit.edu> writes:
> >
> > > I tried it out, and it works partially. The PortGroup file I made
> in
> > > _resources/port1.0/group/fortran-1.0.tcl is recognized when
> > installing, but
> > > not when uninstalling.
> >
> > Yep. I filed a bug long ago and tried to fix it:
> > https://trac.macports.org/ticket/34933
>
> ___
> macports-dev mailing list
> macports-dev@lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/macports-dev
>
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: removing -arch from LDFLAGS

[David Strubbe]

Thanks. Well, let us suppose I am not concerned with building universal for
time being: then it sounds like

configure.ld_archflags-delete -arch ${arch}

is the appropriate approach for gfortran, since -m32/-m64 are preserved in
the LDFLAGS. Right?

David


On Tue, Nov 12, 2013 at 10:55 AM, Michael Dickens wrote:

>  Hi David - gfortran, and non-Apple GCC in general, uses -m32 and -m64 to
> build for whatever the host arch is.  So, if the host computer is a PowerPC
> ("PPC"), then -m32 will build for 32-bit PPC ("ppc"); similarly, -m64 will
> build for 64-bit PPC ("ppc_64"); you won't be able to cross-compile for
> Intel using PPC-based GCC.  If your host computer is Intel ("i386" type),
> then -m32 will do 32-bit Intel ("x86" or "i386") and -m64 will do 64-bit
> Intel ("x86_64"); you won't be able to cross-compile for PPC using
> Intel-based GCC.   Have a look at the muniversal PortGroup for more
> information.  I hope this helps. - MLD
>
> On Tue, Nov 12, 2013, at 10:40 AM, David Strubbe wrote:
>
> gfortran just doesn't accept the "-arch" argument, so I am not sure if
> there is a way to take the arch into account. Can anyone else comment on
> how, if at all, building with gfortran should deal with build_arch?
>
>
> ___
> macports-dev mailing list
> macports-dev@lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/macports-dev
>
>
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: removing -arch from LDFLAGS

[David Strubbe]

>
> I'm saying that if the user sets build_arch to i386 in macports.conf,
> adding '-arch i386' to LDFLAGS is one of the ways that we tell the build
> system to build for i386 and not for (say) x86_64 which is the default
> on recent systems. So if you don't do that, you may need to do something
> else. I don't know your build system so I don't know what if anything
> would be needed.
>

gfortran just doesn't accept the "-arch" argument, so I am not sure if
there is a way to take the arch into account. Can anyone else comment on
how, if at all, building with gfortran should deal with build_arch?
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: removing -arch from LDFLAGS

[David Strubbe]

Thanks. This isn't in the guide. Would be helpful to list in
http://guide.macports.org/#reference.phases.configure.

I think I should do "configure.ld_archflags " (i.e. set to blank) if the
compiler is gfortran. When you say "simply clearing it may break the port's
ability to build for the selected build_arch" are you saying this is still
not the way to go? If so, what do you suggest? Or did you mean clearing
LDFLAGS entirely? Or do you mean if I clear it always not just when using
gfortran?

Also, why didn't ${configure.args} work?

David


On Tue, Nov 12, 2013 at 1:08 AM, Joshua Root  wrote:

> On 2013-11-12 16:32 , David Strubbe wrote:
> > Hi all,
> >
> > Is there a way to remove the -arch option from LDFLAGS, as for gfortran?
> > Using configure.compiler macports-gcc-XX removes it, but that is not
> > compatible with the Fortran recipe which only sets configure.f90 etc. On
> > my machine, the default value is
> >
> > LDFLAGS='-L/opt/local/lib -Wl,-headerpad_max_install_names -arch x86_64'
> >
> > I can use
> >
> > configure.args-append  LDFLAGS=""
> >
> > to clear LDFLAGS entirely, but it may better to just remove the -arch
> > part. However, putting configure.ldflags-delete -arch x86_64, either in
> > the main part of the Portfile, or in a pre-configure block, has no
> > effect, because at that point if I write out configure.ldflags it is
> > only "-L/opt/local/lib -Wl,-headerpad_max_install_names", and if I try
> > to write out configure.args, I get
> >
> > Error: org.macports.configure for port libxc returned: can't read
> > "configure.args": no such variable
> >
> > What is the best approach here?
>
> The option you want is configure.ld_archflags. Note that simply clearing
> it may break the port's ability to build for the selected build_arch.
> The corresponding option used for +universal is
> configure.universal_ldflags.
>
> - Josh
>
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: local PortGroup repo?

[David Strubbe]

I see. As it stands, I am not sure how to actually uninstall the ports I
installed with the test portgroup -- they are still there after the failed
uninstall. Any tip?

David


On Tue, Nov 12, 2013 at 12:44 AM, Sean Farley  wrote:

>
> dstru...@mit.edu writes:
>
> > I tried it out, and it works partially. The PortGroup file I made in
> > _resources/port1.0/group/fortran-1.0.tcl is recognized when installing,
> but
> > not when uninstalling.
>
> Yep. I filed a bug long ago and tried to fix it:
> https://trac.macports.org/ticket/34933
>
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: local PortGroup repo?

[David Strubbe]

I tried it out, and it works partially. The PortGroup file I made in
_resources/port1.0/group/fortran-1.0.tcl is recognized when installing, but
not when uninstalling. For example:

$ sudo port uninstall libxc @2.0.2_0+gcc47
Warning: PortGroup fortran 1.0 could not be located. fortran-1.0.tcl does
not exist.
Error: org.macports.uninstall for port libxc returned: Registry error:
libxc @2.0.2_0 not registered as installed
Please see the log file for port libxc for details:

/opt/local/var/macports/logs/_opt_local_var_macports_registry_portfiles_libxc_2.0.2_0+gcc47/libxc/main.log
Warning: Failed to execute portfile from registry for libxc @2.0.2_0+gcc47
Warning: PortGroup fortran 1.0 could not be located. fortran-1.0.tcl does
not exist.
Error: org.macports.deactivate for port libxc returned: Active version of
libxc is not 2.0.2_0 but 2.0.2_0+gcc47.
Please see the log file for port libxc for details:

/opt/local/var/macports/logs/_opt_local_var_macports_registry_portfiles_libxc_2.0.2_0+gcc47/libxc/main.log
Warning: Failed to execute portfile from registry for libxc @2.0.2_0+gcc47
--->  Deactivating libxc @2.0.2_0+gcc47
--->  Uninstalling libxc @2.0.2_0+gcc47

The log file mentioned doesn't contain much more information:

$ cat
/opt/local/var/macports/logs/_opt_local_var_macports_registry_portfiles_libxc_2.0.2_0+gcc47/libxc/main.log
version:1
:debug:main Executing org.macports.main (libxc)
:debug:deactivate deactivate phase started at Tue Nov 12 00:37:14 EST 2013
:debug:deactivate Executing org.macports.deactivate (libxc)
:error:deactivate org.macports.deactivate for port libxc returned: Active
version of libxc is not 2.0.2_0 but 2.0.2_0+gcc47.
:debug:deactivate Error code: NONE
:debug:deactivate Backtrace: Active version of libxc is not 2.0.2_0 but
2.0.2_0+gcc47.
invoked from within
"registry_deactivate $subport $version $revision $portvariants [array get
user_options]"
(procedure "portdeactivate::deactivate_main" line 11)
invoked from within
"$procedure $targetname"
:info:deactivate Warning: targets not executed for libxc:
org.macports.deactivate
:notice:deactivate Please see the log file for port libxc for details:

/opt/local/var/macports/logs/_opt_local_var_macports_registry_portfiles_libxc_2.0.2_0+gcc47/libxc/main.log



On Sat, Nov 2, 2013 at 8:04 AM, Rainer Müller  wrote:

> On 2013-11-01 21:02, Dan Ports wrote:
> > On Fri, Nov 01, 2013 at 03:21:36PM -0400, Eric Gallager wrote:
> >> Really? That's strange, I could've sworn I was able to use the qmake
> >> portgroup in my local PortFile repository successfully when I was
> testing
> >> it...
> >
> > I believe portfiles will use portgroups from their own repository, so
> > portgroups in a local repository will affect your local ports but not
> > override ones in the default repo.
>
> Yes, port groups will be used from their own ports tree. Only if the
> port group file does not exist there, it falls back to using the port
> group from the default ports tree. This is the same behavior that is
> applied for all files in the _resources directory.
>
> I added a debug message in r112824 [1], which makes it easier to see
> which port groups are sourced.
>
> Rainer
>
> [1] https://trac.macports.org/changeset/112824
> ___
> macports-dev mailing list
> macports-dev@lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/macports-dev
>
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

removing -arch from LDFLAGS

[David Strubbe]

Hi all,

Is there a way to remove the -arch option from LDFLAGS, as for gfortran?
Using configure.compiler macports-gcc-XX removes it, but that is not
compatible with the Fortran recipe which only sets configure.f90 etc. On my
machine, the default value is

LDFLAGS='-L/opt/local/lib -Wl,-headerpad_max_install_names -arch x86_64'

I can use

configure.args-append  LDFLAGS=""

to clear LDFLAGS entirely, but it may better to just remove the -arch part.
However, putting configure.ldflags-delete -arch x86_64, either in the main
part of the Portfile, or in a pre-configure block, has no effect, because
at that point if I write out configure.ldflags it is only "-L/opt/local/lib
-Wl,-headerpad_max_install_names", and if I try to write out
configure.args, I get

Error: org.macports.configure for port libxc returned: can't read
"configure.args": no such variable

What is the best approach here?

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

Re: redefined data types in different packages - request for help

[David Strubbe]

Looks like this is C++. There might be something you can do with namespaces.

David


On Sat, Nov 9, 2013 at 9:15 AM, Mojca Miklavec  wrote:

> On Sat, Nov 9, 2013 at 3:08 PM, Mojca Miklavec  wrote:
> > Hi,
> >
> > one of the problems I'm experiencing when compiling hugin-app is that
> > "uint64" is defined both in Security.framework where it's
> > uint64->uint64_t as well as in tiff.h/tiffio.h where it gets defined
> > as "unsigned long long".
> >
> > How can one resolve such a conflict?
>
> I'm sorry, I copied the wrong error. It should have been:
>
> cd /path/to/hugin-app/work/hugin-2013.0.0/src/hugin1/stitch_project &&
> /usr/bin/clang++   -DHUGIN_HSI -DWXUSINGDLL -D_FILE_OFFSET_BITS=64
> -D__WXMAC__ -D__WXOSX_COCOA__ -D__WXOSX__ -pipe -Os
> -D__ASSERT_MACROS_DEFINE_VERSIONS_WITHOUT_UNDERSCORES=0
> -I/opt/local/include -arch x86_64
>
> -I/opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxWidgets/3.0/include/wx-3.0
> -DNDEBUG -arch x86_64 -I/path/to/hugin-app/work/hugin-2013.0.0/src
> -I/path/to/hugin-app/work/hugin-2013.0.0/src/hugin_base
> -I/path/to/hugin-app/work/hugin-2013.0.0/src/foreign/vigra
> -I/path/to/hugin-app/work/hugin-2013.0.0/src/celeste
> -I/opt/local/include -I/opt/local/include/OpenEXR
> -F//System/Library/Frameworks
> -I/System/Library/Frameworks/GLUT.framework/Versions/A/Headers
> -I/path/to/hugin-app/work/hugin-2013.0.0/src/foreign
>
> -I/opt/local/Library/Frameworks/Python.framework/Versions/2.7/include/python2.7
>
> -I/opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxWidgets/3.0/lib/wx/include/osx_cocoa-unicode-3.0
>
> -I/opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxWidgets/3.0/include/wx-3.0
> -I/path/to/hugin-app/work/hugin-2013.0.0/src/hugin1-o
> CMakeFiles/HuginStitchProject.dir/hugin_stitch_project.cpp.o -c
>
> /path/to/hugin-app/work/hugin-2013.0.0/src/hugin1/stitch_project/hugin_stitch_project.cpp
>
> In file included from
>
> /path/to/hugin-app/work/hugin-2013.0.0/src/hugin1/stitch_project/hugin_stitch_project.cpp:46:
>
> In file included from /opt/local/include/tiffio.h:33:
> /opt/local/include/tiff.h:78:23: error: typedef redefinition with
> different types ('unsigned long' vs 'uint64_t' (aka 'unsigned long
> long'))
> typedef TIFF_UINT64_T uint64;
>   ^
> //System/Library/Frameworks/Security.framework/Headers/cssmconfig.h:53:18:
> note: previous definition is here
> typedef uint64_t uint64;
>  ^
> 2 warnings and 1 error generated.
>
> Mojca
> ___
> macports-dev mailing list
> macports-dev@lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/macports-dev
>
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: @macports.org handle

[David Strubbe]

The guide says:

"7.3. Port Update Policies

Port maintainers normally are given commit privileges to the Subversion
repository so they can make updates to their own ports."

I suggest that be clarified if more conditions apply.

David


On Thu, Nov 7, 2013 at 12:41 PM, Rainer Müller  wrote:

> On 2013-11-07 17:40, Robert Oschwald wrote:
> > I’m co-maintainer of sysutils/bacula and want to take over maintenance
> of www/mod_jk, too.
>
> Note that you do not need to have commit access to maintain a port.
> Simply file a ticket with a port update, in case of a without a
> maintainer, feel free to add yourself.
>
> We usually want new maintainers to become involved with the community
> and our processes first before we approve them for commit access. Of
> course, we welcome all kinds of contributions from everyone in form of
> new ports, port updates, or documentation additions and ask you to
> submit them with tickets in Trac.
>
> Rainer
> ___
> macports-dev mailing list
> macports-dev@lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/macports-dev
>
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

local PortGroup repo?

[David Strubbe]

Hi all,

Is it possible to have local PortGroup files to use with a local Portfile
repository? If so, where should they be put? Or otherwise, how should one
try out a new PortGroup?

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

Re: open tickets

[David Strubbe]

Thanks!

Yes, I sent an email to macports-...@lists.macosforge.org about a month ago
regarding commit access, as specified by the guide, and a reminder a couple
of weeks ago, but I didn't hear anything back.

David


On Thu, Oct 24, 2013 at 5:41 PM, Jeremy Lavergne  wrote:

> Handled.
>
> Have you applied for commit access?
>
> On Oct 24, 2013, at 5:20 PM, David Strubbe wrote:
>
> > Hi committers,
> >
> > I'd like to ask again for someone to take a look at these two tickets,
> for a maintainer patch and taking over an abandoned port.
> >
> > Thanks,
> > David
> >
> >
> > On Sun, Oct 6, 2013 at 11:15 PM, David Strubbe 
> wrote:
> > Hi committers,
> >
> > Can you please take a look at two open tickets I submitted? The first is
> an enhancement to my sparskit port; the second is about port abandonment of
> libxc. I submitted it 5 days ago, so the 72 hour timeout period has elapsed.
> >
> > Thanks,
> > David
> >
> > [1] https://trac.macports.org/ticket/40638
> > [2] https://trac.macports.org/ticket/40646
> >
> > ___
> > macports-dev mailing list
> > macports-dev@lists.macosforge.org
> > https://lists.macosforge.org/mailman/listinfo/macports-dev
>
>
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: open tickets

[David Strubbe]

Hi committers,

I'd like to ask again for someone to take a look at these two tickets, for
a maintainer patch and taking over an abandoned port.

Thanks,
David


On Sun, Oct 6, 2013 at 11:15 PM, David Strubbe  wrote:

> Hi committers,
>
> Can you please take a look at two open tickets I submitted? The first is
> an enhancement to my sparskit port; the second is about port abandonment of
> libxc. I submitted it 5 days ago, so the 72 hour timeout period has elapsed.
>
> Thanks,
> David
>
> [1] https://trac.macports.org/ticket/40638
> [2] https://trac.macports.org/ticket/40646
>
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

open tickets

[David Strubbe]

Hi committers,

Can you please take a look at two open tickets I submitted? The first is an
enhancement to my sparskit port; the second is about port abandonment of
libxc. I submitted it 5 days ago, so the 72 hour timeout period has elapsed.

Thanks,
David

[1] https://trac.macports.org/ticket/40638
[2] https://trac.macports.org/ticket/40646
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

suggestion for Fortran recipe

[David Strubbe]

Hi Jeremy and others,

I think a few lines can be simplified in the new Fortran recipe. For
default variants, it seems to me that it makes no difference whether it is
set when the variant was explicitly selected.

i.e this code from the Portfile recipe

if {![variant_isset q8] && ![variant_isset q32]} {
default_variants +q16
}

is functionally equivalent to


if {![variant_isset q8] && ![variant_isset q16] && ![variant_isset q32]} {
default_variants +q16
}

since if +q16 is selected it is not important whether we consider that
choice to have been made by default or not.

As a result, in the Fortran recipe,

if {[variant_isset gcc${ver_no_dot}]} {
if {${default_fortran_variant} != "+gcc${ver_no_dot}"} {
set default_fortran_variant ""
}
}

is equivalent in functionality to

if {[variant_isset gcc${ver_no_dot}]} {
set default_fortran_variant ""
}

and the corresponding if-condition can be removed in the g95 statement,
thus removing some lines and simplifying it.

I am also wondering, can't the Fortran recipe be made a PortGroup? It seems
problematic for the maintainability of the portfiles for there to be such a
large block duplicated in many portfiles. If it were a PortGroup, then
issues like the one above could be settled centrally.

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

default_variant and conflicts: suggestion for base

[David Strubbe]

Hi all,

As we see at https://trac.macports.org/wiki/PortfileRecipes, the
recommended code for a default variant with one of several mutually
exclusive variants is:

if {![variant_isset q8] && ![variant_isset q32]} {
default_variants +q16
}

In this case, as in the older Fortran recipe also on that page, I would
assume that +q8, +q16, and +q32 would all be mutually conflicting.

If this is so, can't MacPorts base automatically handle the code block
above? i.e. the Portfile just says default_variants +q16 without the
if-condition and marks the conflicts for the variants, and then base would
set the default except when a conflicting variant was selected. If this is
possible, it would simplify Portfiles a bit and maybe catch some errors in
how these constructs have been manually generated.

I am not sure how this is all handled internally, but perhaps something
along these lines would work (in pseudo-ish code):

Portfile:
default_variants +q16
variant q8 conflicts q16 q32
variant q16 conflicts q8 q32
variant q32 conflicts q8 q16

base:
foreach defvar ${default_variants} {
  conflicting = no
  foreach var conflicts(${defvar}) {
if {[variant_isset $var]} { conflicting = yes }
  }
  if {$conflicting == no} { add $defvar to variants}
}

I think that this logic about conflicts and default variants is probably
always what we want, because if a variant is set by default without regard
to a conflicting variant, then that conflicting variant would never be
usable. And if there is another non-conflicting variant that should make
this variant not be set by default, then that can be easily handled with

if {![variant_isset var]} { default_variant var2 }

as before.

Moreover, it seems like always if var1 conflicts with var2, then also var2
should conflict with var1. Maybe it would be helpful to have a construct
called "conflicts_group" where one could replace

variant var1 conflicts var2
variant var2 conflicts var1

with

conflict_group var1, var2

This would be particularly helpful in cases with lots of mutually
conflicting variants, such as the gcc versions in the Fortran recipe, since
one could just list all these variants once rather than have to list all
but one for each of them.

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

ticket guidelines

[David Strubbe]

According to the guide at http://guide.macports.org/#project.tickets,
ticket summaries should have the form:

Summary: [port] [version] [concise description]
Example: "rrdtool @1.2.23 +python Configure error - build failure"

However it appears in practice that this is the appropriate form for a
"defect" but that different forms are desired for "submission" and
"update". I suggest this be specified in the guide.

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