Re: 2nd MacPorts Meeting & Online Meeting

[Clemens Lang]

Hi Marko,

On Mon, Oct 17, 2016 at 12:38:20AM +0200, Marko Käning wrote:
> now that you say it… Weren’t you aiming at the Wiesn earlier this
> year? ;-)

Well, as you noticed, that didn't happen ;)


> I noticed that there is eventually an official MacPorts ports git repo
> [1] online since a few days now, which Ryan seems to be administering…
> Cools stuff! It looks like MacPorts will soon work through git. I
> think I was the first who forked this. ;)

There will be an official announcement email with more instructions in a
couple of days, too. We're still hammering out the details of the
process and the draft.

For now, note that the repositories are subject to complete history
rewrite and force push on all branches at any time, because we're fixing
the last few flaws in the conversion scripts, so your fork might soon
been completely out of touch with the main repo.

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

Re: [153943] trunk/dports/science

[Ryan Schmidt]

> 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  
> ef797abc51ed8ae27c200f5b71fd0a3824d1fa310392dac57067de2e423222ed
> +worksrcdir   ${distname}-${version}+dfsg
> +
> +depends_lib  port:OpenBLAS \
> +port:lapack \
> +port:gsl \
> +port:fftw-3 \
> +port:pgplot \
> +port:xorg-libX11
> +
> +compilers.choosecxx f77
> +compilers.setup require_fortran
> +
> +configure{
> +file copy ${filespath}/local_settings ${worksrcpath}/
> +reinplace -W ${worksrcpath} "s|@CXX@|${configure.cxx}|g" local_settings
> +reinplace -W ${worksrcpath} "s|@F77@| ${configure.f77} |g" local_settings
> +reinplace -W ${worksrcpath} "s|@CXXFLAGS@|${configure.cxxflags}|g" 
> local_settings
> +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
> +}

I don't see anywhere in this Portfile that arranges for the correct -arch (or, 
in the case of fortran, -m32/-m64) flags to be used. ([get_canonical_archflags 
...])

The universal variant fails and should probably be disabled because:

Error: Cannot install LORENE for the archs 'i386 x86_64' because
Error: its dependency pgplot does not build for the required archs by default
Error: and does not have a universal variant.


> +build.env-appendHOME_LORENE=${worksrcpath}
> +build.targetcpp fortran export
> +use_parallel_build  no
> +
> +destroot{
> +xinstall -d ${destroot}${prefix}/lib/lorene/Lib
> +xinstall {*}[glob ${worksrcpath}/Lib/*.a] 
> ${destroot}${prefix}/lib/lorene/Lib/
> +xinstall -d ${destroot}${prefix}/lib/lorene/C++/Include
> +xinstall {*}[glob ${worksrcpath}/C++/Include/*.h] 
> ${destroot}${prefix}/lib/lorene/C++/Include/
> +xinstall -d ${destroot}${prefix}/lib/lorene/C++/Include/Template
> +xinstall {*}[glob ${worksrcpath}/C++/Include/Template/*] 
> ${destroot}${prefix}/lib/lorene/C++/Include/Template/
> +xinstall ${worksrcpath}/local_settings ${destroot}${prefix}/lib/lorene/
> +xinstall -d ${destroot}${prefix}/lib/lorene/Devel
> +xinstall {*}[glob ${worksrcpath}/Devel/*] 
> ${destroot}${prefix}/lib/lorene/Devel/
> +exec cp -a ${worksrcpath}/Codes ${destroot}${prefix}/lib/lorene/
> +}

Why "exec cp -a" instead of "copy"?


> --- 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)
> @@ -0,0 +1,89 @@
> + 

Re: 2nd MacPorts Meeting & Online Meeting

[Clemens Lang]

Hi,

On Mon, Oct 10, 2016 at 07:53:13AM +0200, Mojca Miklavec wrote:
> Me and Aljaž would be willing to host the MacPorts meeting in 2017
> again.

Thanks, and sorry for not putting a plan together to do it in Munich in
the fall. Seems I need to improve my time management :)


> In addition to the face-to-face meeting, I would like to propose
> trying out some online meeting some time in mid-November (or any other
> time, according to your wishes).

A good idea, we should try that.


> It would be nice to prepare proposals / agenda for discussion in
> advance though. I would limit the meeting to 2 hours max and repeat it
> if necessary.

I think this might also be a good time to give a quick status update on
where we are with the conversion to Git and the move to GitHub, and
potentially answer questions that any of the attendees might have.

There's quite a bit of work going on at the moment "behind the scenes"
that does not make it to the mailing lists, and I have a feeling it
seems to the list like there is no progress, which is not the case.

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

Re: 2nd MacPorts Meeting & Online Meeting

[David Evans]

On 10/9/16 10:53 PM, Mojca Miklavec wrote:
> Hi,
> 
> Me and Aljaž would be willing to host the MacPorts meeting in 2017 again.
> 
> If you have any particular requests about the desired time / place /
> or anything else, we can discuss it before we fix the dates, but we
> should probably fix it some time soon.
> 
> 
> In addition to the face-to-face meeting, I would like to propose
> trying out some online meeting some time in mid-November (or any other
> time, according to your wishes). I would propose to discuss:
> 
> - creating timeline(s) with most important features that we might want
> to implement & get into next releases
> 
> - how to improve the ticket system
> 
> - and/or any other pressing topic (just not too much all at once)
> 
> I'm not sure about the best format of the online meeting though
> (IRC?). Any suggestions welcome. It would be nice to prepare proposals
> / agenda for discussion in advance though. I would limit the meeting
> to 2 hours max and repeat it if necessary.
> 

Mojca --

In addition to the 2nd annual conference, I like the idea of periodic online
meetings by whatever medium gets the most participation.  To do this 
effectively I
would suggest the following:

* restrict the topics to be covered in such a meeting to a relatively narrow 
range. More meetings with
  narrower range of topic will probably be more effective to control and 
minimize the length of the meeting.
  If the meeting is too long, people won't participate.
* appoint a moderator to manage the progress of the meeting, perhaps a 
different one each time.
* moderator should solicit questions for discussion within the particular topic 
area, in advance of the meeting,
  from potential participants and use it to construct an agenda to be published 
in advance of the meeting. If the
  moderator has some special expertise or interest in the topic to be 
discussed, so much the better.
* moderator can then use the agenda as a tool to provide structure to the 
meeting and be responsible to
  make sure that participants remain focused on the agenda item at hand and not 
go off-topic.
* meetings should be scheduled periodically at a predictable time so that 
potential participants get used
  to having the meetings and make it a regular part of their personal schedule. 
 Maybe start with
  quarterly meetings and up the frequency to monthly if there is good 
participation.
* might be good to have a member of the PortManager group, "attend" each 
meeting to be able to address
  questions of standard practice and policy and in general represent that group
* now that I think about it, using irc might be the best way to go since a 
transcript of the meeting
  can be obtained from the irc logs.  After the meeting this can be processed 
into a "minutes" document and
  published to document the meeting proceedings. That way, people who don't 
participate can benefit from
  the meeting's discussion.

Establishment of a meeting time that is convenient to participants in a wide 
range of
geographical locations is probably the most difficult task and is key to good 
turnout.  Maybe say 9 to 10 am on the
US west coast which would translate to 6 to 7 pm in various parts of Europe.  
Weekends might be better than
weekdays to avoid conflicts with daily work schedules.

Just some thoughts.

Dave






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

Re: [153947] trunk/dports/graphics/oce

[Ryan Schmidt]

> On Oct 16, 2016, at 3:30 PM, m...@macports.org wrote:
> 
> Revision
> 153947
> Author
> m...@macports.org
> Date
> 2016-10-16 13:30:15 -0700 (Sun, 16 Oct 2016)
> Log Message
> 
> oce: fix Sierra build issue.
> Modified Paths
> 
>   • trunk/dports/graphics/oce/Portfile
> Added Paths
> 
>   • trunk/dports/graphics/oce/files/
>   • trunk/dports/graphics/oce/files/patch-src-OSD-OSD_Chronometer.cxx.diff
> Diff
> 
> Modified: trunk/dports/graphics/oce/Portfile (153946 => 153947)
> --- trunk/dports/graphics/oce/Portfile2016-10-16 19:48:51 UTC (rev 
> 153946)
> +++ trunk/dports/graphics/oce/Portfile2016-10-16 20:30:15 UTC (rev 
> 153947)
> @@ -21,6 +21,10 @@
>  
>  depends_lib-append  port:freetype
>  
> +platform darwin 16 {
> +patchfiles-append   patch-src-OSD-OSD_Chronometer.cxx.diff
> +}
> +
>  # tell CMake to build in a build directory
>  configure.dir   ${workpath}/build
>  build.dir   ${configure.dir}
> 
> Added: trunk/dports/graphics/oce/files/patch-src-OSD-OSD_Chronometer.cxx.diff 
> (0 => 153947)
> --- trunk/dports/graphics/oce/files/patch-src-OSD-OSD_Chronometer.cxx.diff
> (rev 0)
> +++ trunk/dports/graphics/oce/files/patch-src-OSD-OSD_Chronometer.cxx.diff
> 2016-10-16 20:30:15 UTC (rev 153947)
> @@ -0,0 +1,16 @@
> +--- src/OSD/OSD_Chronometer.cxx.orig 2016-06-02 07:18:16.0 -0500
>  src/OSD/OSD_Chronometer.cxx  2016-10-16 15:01:08.0 -0500
> +@@ -51,9 +51,10 @@
> +   #include 
> + #endif
> + 
> +-#if defined(__APPLE__) && defined(__MACH__)
> +-#include "gettime_osx.h"
> +-#endif
> ++//Not needed for Sierra

But you anticipate it will be needed again on Darwin 17 and later? If not, you 
should apply the patch on Darwin 16 and later, not just on Darwin 16.

> ++//#if defined(__APPLE__) && defined(__MACH__)
> ++//#include "gettime_osx.h"
> ++//#endif

Why comment out these lines? Why not remove them instead? It would make for a 
smaller and clearer patchfile.


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

Re: 2nd MacPorts Meeting & Online Meeting

[Marko Käning]

Hi Clemens,

On 16 Oct 2016, at 23:58 , Clemens Lang  wrote:
> Thanks, and sorry for not putting a plan together to do it in Munich in
> the fall. Seems I need to improve my time management :)

now that you say it… Weren’t you aiming at the Wiesn earlier this year?
;-)


>> In addition to the face-to-face meeting, I would like to propose
>> trying out some online meeting some time in mid-November (or any other
>> time, according to your wishes).
> 
> A good idea, we should try that.

+1


> I think this might also be a good time to give a quick status update on
> where we are with the conversion to Git and the move to GitHub, and
> potentially answer questions that any of the attendees might have.

+1


> There's quite a bit of work going on at the moment "behind the scenes"
> that does not make it to the mailing lists, and I have a feeling it
> seems to the list like there is no progress, which is not the case.

I noticed that there is eventually an official MacPorts ports git repo [1]
online since a few days now, which Ryan seems to be administering…
Cools stuff! It looks like MacPorts will soon work through git. I think I
was the first who forked this. ;)

Congratulations for your behind-the-scenes progress!!!

Greets,
Marko





[1] https://github.com/macports/macports-ports
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [153935] trunk/dports/gis/routino

[Ryan Schmidt]

> On Oct 16, 2016, at 10:58 AM, khindenb...@macports.org wrote:
> 
> Revision
> 153935
> Author
> khindenb...@macports.org
> Date
> 2016-10-16 08:58:14 -0700 (Sun, 16 Oct 2016)
> Log Message
> 
> routino: add +universal - attempt to use correct compiler flags
> Modified Paths
> 
>   • trunk/dports/gis/routino/Portfile

> +variant universal {}
> +if {[variant_isset universal]} {
> +configure.cflags-append ${configure.universal_cflags}
> +configure.ldflags-append ${configure.universal_ldflags}
> +} else {
> +configure.cflags-append ${configure.cc_archflags}
> +configure.ldflags-append ${configure.ld_archflags}
> +}

Perhaps you copied this from an ancient port that hasn't been updated, but you 
can use the [get_canonical_archflags] procedure now (instead of having to 
manually decide between configure.universal_*flags and configure.*_archflags), 
as long as you declare the empty universal variant first, as you did.



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

Re: 2nd MacPorts Meeting & Online Meeting

[David Evans]

On 10/16/16 3:59 PM, Clemens Lang wrote:
> Hi Marko,
> 
> On Mon, Oct 17, 2016 at 12:38:20AM +0200, Marko Käning wrote:
>> now that you say it… Weren’t you aiming at the Wiesn earlier this
>> year? ;-)
> 
> Well, as you noticed, that didn't happen ;)
> 
> 
>> I noticed that there is eventually an official MacPorts ports git repo
>> [1] online since a few days now, which Ryan seems to be administering…
>> Cools stuff! It looks like MacPorts will soon work through git. I
>> think I was the first who forked this. ;)
> 
> There will be an official announcement email with more instructions in a
> couple of days, too. We're still hammering out the details of the
> process and the draft.

Be looking forward to this email.  My main questions have to do with
the probable timing of the switch and whether it will be a sudden cold
turkey event or whether svn and git will be able to coincide for some nominal
migration period.

At some appropriate point, I'd like to see an advance announcement that says 
something
like:

You have until  to commit your final changes to svn;
after that you'll need to use git.

I'd think that one to two weeks might be an appropriate warning period. 
Particularly
if folks know beforehand that it's coming.

Thanks, again, to all working on this issue for your (in the plural sense) 
efforts toward
modernizing MacPorts.

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

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

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 \
>> > +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/~th
>> ibaut/debian/pool/main/l/lorene/
>> > +distname lorene
>> > +distfiles${distname}_${version}+dfsg.orig.tar.xz
>>
>> Because this is not a