Objection to restoring deprecated Python subports

Fred Wright recently opened several tickets that suggest restoring several Python subports that were deprecated and moved to the Python graveyard a long time ago. https://trac.macports.org/ticket/52636 https://trac.macports.org/ticket/52637 https://trac.macports.org/ticket/52638

Re: Review request for tickets #52545, #52590, #52615

> On Oct 17, 2016, at 7:55 PM, David Evans wrote: > > On 10/17/16 2:38 PM, Ryan Schmidt wrote: >> >>> On Oct 17, 2016, at 2:43 PM, David Evans wrote: >>> >>> Ryan, >>> >>> I'm trying to commit as many pending svn commits as soon as possible in >>>

Re: Commit request https://trac.macports.org/ticket/52546

That I will leave to upstream. Thanks, K On 2016-10-17, at 6:16 PM, Fred Wright wrote: > > On Mon, 17 Oct 2016, Ken Cunningham wrote: > >> For your consideration -- I'd commit this as it stands and fix the port, >> rather than spend too much more time on it. >> >>

Re: Commit request https://trac.macports.org/ticket/52546

On Mon, 17 Oct 2016, Ken Cunningham wrote: > For your consideration -- I'd commit this as it stands and fix the port, > rather than spend too much more time on it. > > https://trac.macports.org/ticket/52546 > > I notice something has changed in the sierra time functions -- a couple of > ports

Re: [154006] trunk/dports/science/Gyoto

Looking at the buildbot failures, this needs, at least, a build dependency on pkgconfig. On 10/17/16 3:24 PM, thib...@macports.org wrote: > Revision > 154006 > Author > thib...@macports.org > Date > 2016-10-17 15:24:33 -0700 (Mon, 17 Oct

Re: Review request for tickets #52545, #52590, #52615

On 10/17/16 2:38 PM, Ryan Schmidt wrote: > >> On Oct 17, 2016, at 2:43 PM, David Evans wrote: >> >> Ryan, >> >> I'm trying to commit as many pending svn commits as soon as possible in >> anticipation of the migration to git. I'd >> appreciate it if you could look at these

Commit request https://trac.macports.org/ticket/52546

For your consideration -- I'd commit this as it stands and fix the port, rather than spend too much more time on it. https://trac.macports.org/ticket/52546 I notice something has changed in the sierra time functions -- a couple of ports seem to have time-related errors. K

Re: [153943] trunk/dports/science

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)

Re: Review request for tickets #52545, #52590, #52615

> On Oct 17, 2016, at 2:43 PM, David Evans wrote: > > Ryan, > > I'm trying to commit as many pending svn commits as soon as possible in > anticipation of the migration to git. I'd > appreciate it if you could look at these 3 tickets[1][2][3] and let me know > if you

Review request for tickets #52545, #52590, #52615

Ryan, I'm trying to commit as many pending svn commits as soon as possible in anticipation of the migration to git. I'd appreciate it if you could look at these 3 tickets[1][2][3] and let me know if you agree they can be committed as is, or if you have any suggestions for their improvement.

Re: [153943] trunk/dports/science

I think this didn’t go to the list. Le 17 oct. 2016 à 19:40, Paumard Thibaut a écrit : > Many thanks David, > > Let me answer some of your questions: > > Le Lundi 17 Octobre 2016 02:23 CEST, David Strubbe a > écrit: > >> Hi, >> >> Let me

Re: [153943] trunk/dports/science

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

Re: port:lapack useful?

Takeshi Enomoto writes: > Dear David, > >> 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

Re: [153943] trunk/dports/science

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

Re: port:lapack useful?

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. >

Re: [153943] trunk/dports/science

> 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

Re: [153943] trunk/dports/science

> On Oct 17, 2016, at 12:23 PM, Paumard Thibaut > wrote: > > Thanks Ryan, > > I will commit an update tonight to fix those issues. > > Does that warrant a rev bump? Will it change any files that get installed by the port? If so, yes. > Kind regards, Thibaut. >

Re: port:lapack useful?

Dear David, > 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

Re: 2nd MacPorts Meeting & Online Meeting

On 2016-10-16 22:36, David Evans wrote: > * 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

Re: 2nd MacPorts Meeting & Online Meeting

On 2016-10-16 23:58, Clemens Lang wrote: > 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