Unable to access macports-infrastructure.git

[Dave Allured - NOAA Affiliate via macports-dev]

I am getting an unusual builder error that is blocking my recent port
update on all of the builders.  Go to console view on build.macports.org,
find port `gjs-devel`, and look at the stdio logs below the commit message.

`fatal: unable to access '
https://github.com/macports/macports-infrastructure.git/': Server aborted
the SSL handshake`

Now I know they put Dave detectors in all the traffic lights.  I thought
maybe that was the problem here, but Ryan has one too.  Please let me know
how to get my build started, and whether I owe money or something.  Thank
you.

Re: Rebuilding binaries

[Dave Allured - NOAA Affiliate via macports-dev]

On Fri, Feb 9, 2024 at 1:33 PM Clemens Lang  wrote:

> Hi,
>
> On Fri, Feb 09, 2024 at 01:05:04PM -0700, Dave Allured - NOAA Affiliate
> via macports-dev wrote:
> > I am working on a port that was broken because of a fault in a
> > dependency. The dependency port was fixed and the binaries were
> > rebuilt.  However, the current port's binaries are not automatically
> > rebuilt.  Build status on the ports website shows "failed install
> > port" for the affected OS versions.  I would like to get rebuilt
> > binaries and change the build status to successful.
> >
> > Generally speaking, what is the "correct protocol" in Macports, to get
> > port binaries to rebuild, when there is no particular reason to rev
> > bump or otherwise make any changes to the portfile?
>
> Two options: (1) Make a whitespace-only change to the Portfile. (2) Tell
> somebody with a log-in for build.macports.org to trigger a build.
>
> For (2), there are a bunch of people like that on this list, but the
> accounts are created manually. I'm one of them. If you tell me what
> port(s) you want rebuilt, I can trigger that for you.
>
> (1) might be simpler because it takes care of all OSes and is
> self-service.
>


Thanks, Clements.  I will try (1) whitespace this time, because in this
particular case I want to verify whether this dependency fix works across
all builders and OS's.  It is supposed to, but I need to check.

Rebuilding binaries

[Dave Allured - NOAA Affiliate via macports-dev]

I am working on a port that was broken because of a fault in a dependency.
The dependency port was fixed and the binaries were rebuilt.  However, the
current port's binaries are not automatically rebuilt.  Build status on the
ports website shows "failed install port" for the affected OS versions.  I
would like to get rebuilt binaries and change the build status to
successful.

Generally speaking, what is the "correct protocol" in Macports, to get port
binaries to rebuild, when there is no particular reason to rev bump or
otherwise make any changes to the portfile?

Re: Antlr: Rebuild on 12.x86_64

[Dave Allured - NOAA Affiliate via macports-dev]

Josh, Nils -- Thank you.  This is very helpful advice which has already
saved me some trouble.  I will add the java portgroup and see how it goes.


On Mon, Feb 5, 2024 at 12:41 AM Nils Breunese  wrote:

> You can use the java PortGroup (
> https://guide.macports.org/chunked/reference.portgroup.html#reference.portgroup.java)
> to specify a minimum required Java version, and a fallback port to install
> when this minimum version is not already available.
>
> Nils.
>
> Op 5 feb 2024 om 07:42 heeft Joshua Root  het volgende
> geschreven:
>
> On 5/2/2024 16:10, Dave Allured - NOAA Affiliate via macports-dev wrote:
>
> Would someone with builder access please trigger a rebuild of antlr on the
> 12.x86_64 builder?  There seems to be a difference between builders and
> github CI, and I need to check a recent builder log file.  Thanks for your
> help.
>
>
> I don't think there's any need to run a build; the issue (or at least the
> first one encountered) is that antlr needs Java, the antlr port doesn't
> depend on any Java port, and recent macOS versions don't ship Java in a
> default installation.
>
> The CI image on the other hand does have Java installed. <
> https://github.com/actions/runner-images/blob/main/images/macos/macos-12-Readme.md#java
> >
>
> - Josh
>
>

Antlr: Rebuild on 12.x86_64

[Dave Allured - NOAA Affiliate via macports-dev]

Would someone with builder access please trigger a rebuild of antlr on the
12.x86_64 builder?  There seems to be a difference between builders and
github CI, and I need to check a recent builder log file.  Thanks for your
help.

Re: Difference between mpbb and local builds

[Dave Allured - NOAA Affiliate via macports-dev]

On Fri, Feb 2, 2024 at 1:52 PM Clemens Lang  wrote:

> Hi,
>
> On Fri, Feb 02, 2024 at 01:40:45PM -0500, Link Dupont via macports-dev
> wrote:
> > I submitted a new port[1] recently. I ensured that it compiled and
> > runs locally, but when I the commit was merged, I noticed that the
> > buildbot builds are failing[2] with an error:
> >
> > > cli.c:8:10: fatal error: 'availability.h' file not found
> >
> > I’m puzzled why this doesn’t seem to be a problem locally. How can I
> > go about reproducing this build failure locally so that I can figure
> > out a fix? What sort of differences are there between ports built
> > locally and ports built by the build bot?
>
> Apart from the differences that others have mentioned, the build
> machines also run a case-sensitive filesystem. That seems to be the
> issue here, since the default installation of macOS (which yours likely
> is) is case-preserving, but not case-sensitive, but the header is
> actually
>
>
> /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/Availability.h
>
> i.e. with a capital Availability.h, but you're including it all lower
> case. That would work on a standard install, but fail on the buildbots.
>


Now this is odd.  Socket_vmnet is a package specifically intended for Mac
OS, yet availability.h has been hard coded as all lowercase in the source
code for more than two years.  Are there two versions, [A/a]vailability.h?
Or perhaps this is a real upstream bug, and they never tested it on a case
sensitive file system?  Thoughts?

Re: Difference between mpbb and local builds

[Dave Allured - NOAA Affiliate via macports-dev]

A bit of searching suggests that availability.h is provided by Xcode, not
by a normal dependency.  Try adding "use_xcode yes" in the Portfile, or one
of the other mechanisms suggested here:
https://guide.macports.org/#reference.keywords.use_xcode


On Fri, Feb 2, 2024 at 12:00 PM Dave Allured - NOAA Affiliate <
dave.allu...@noaa.gov> wrote:

> Link, the basic difference is that builders start with an empty system and
> add only the minimum required dependencies.  Your local macports might have
> all sorts of other software installed.  Also you might not be correctly
> isolating your local macports environment, meaning that the local build
> could pick up files from unexpected locations outside of a proper macports
> environment.
>
> So track down where your local build is getting availability.h, then
> decide what should be done about it.
>
>
> On Fri, Feb 2, 2024 at 11:41 AM Link Dupont via macports-dev <
> macports-dev@lists.macports.org> wrote:
>
>> I submitted a new port[1] recently. I ensured that it compiled and runs
>> locally, but when I the commit was merged, I noticed that the buildbot
>> builds are failing[2] with an error:
>>
>> > cli.c:8:10: fatal error: 'availability.h' file not found
>>
>> I’m puzzled why this doesn’t seem to be a problem locally. How can I go
>> about reproducing this build failure locally so that I can figure out a
>> fix? What sort of differences are there between ports built locally and
>> ports built by the build bot?
>>
>> 1: https://ports.macports.org/port/socket_vmnet/
>> 2:
>> https://build.macports.org/builders/ports-14_arm64-builder/builds/16659/steps/install-port/logs/stdio
>>
>

Re: Difference between mpbb and local builds

[Dave Allured - NOAA Affiliate via macports-dev]

Link, the basic difference is that builders start with an empty system and
add only the minimum required dependencies.  Your local macports might have
all sorts of other software installed.  Also you might not be correctly
isolating your local macports environment, meaning that the local build
could pick up files from unexpected locations outside of a proper macports
environment.

So track down where your local build is getting availability.h, then decide
what should be done about it.


On Fri, Feb 2, 2024 at 11:41 AM Link Dupont via macports-dev <
macports-dev@lists.macports.org> wrote:

> I submitted a new port[1] recently. I ensured that it compiled and runs
> locally, but when I the commit was merged, I noticed that the buildbot
> builds are failing[2] with an error:
>
> > cli.c:8:10: fatal error: 'availability.h' file not found
>
> I’m puzzled why this doesn’t seem to be a problem locally. How can I go
> about reproducing this build failure locally so that I can figure out a
> fix? What sort of differences are there between ports built locally and
> ports built by the build bot?
>
> 1: https://ports.macports.org/port/socket_vmnet/
> 2:
> https://build.macports.org/builders/ports-14_arm64-builder/builds/16659/steps/install-port/logs/stdio
>

Re: TCL 9.0?

[Dave Allured - NOAA Affiliate via macports-dev]

On Mon, Jan 29, 2024 at 12:26 PM Joshua Root  wrote:

> On 30/1/2024 01:18, Mark Anderson wrote:
> > Woah, never thought I'd see it:
> > https://www.tcl.tk/software/tcltk/9.0.html
> > 
> >
> > I wonder how big an impact it will be? Since we ship out own, not rush
> > (It's also still beta) but interesting nonetheless.
>
> The namespace resolution may affect some of our code, and the tilde
> change definitely does. It wouldn't surprise me if there are some more
> incompatibilities not listed on that page. We'll probably go to 8.7
> first for base.
>
> For ports, I would guess we'll need to keep Tcl 8 and 9 available as
> separate ports for quite some time.
>
> - Josh


FWIW, here is their TCL 9 migration guide with more details.  It is noted
as work in progress.
https://core.tcl-lang.org/tcl/wiki?name=Migrating+scripts+to+Tcl+9

Re: GEDA site dead?

[Dave Allured - NOAA Affiliate via macports-dev]

Valerio, thanks for that reference.  Lepton-eda looks like a nice successor
to gEDA, and a good candidate for a new port.


On Sat, Jan 27, 2024 at 10:25 AM Valerio Messina via macports-dev <
macports-dev@lists.macports.org> wrote:

> domain was http://www.geda-project.org/
> see: https://en.wikipedia.org/wiki/GEDA
> seems payd till October 2024 but now is down
>
> gEDA development has always been with the main focus on Linux and have
> never cared about macOS and Windows.
> In recent years, competition from KiCad (which is madly actively
> developed cross platform by CERN and is still GPL) I think has killed
> the development of gEDA. The only exception is GerbV which is still
> maintained and is quite up to date for Linux and Windows, but not for
> macOS:
> https://github.com/gerbv/gerbv
>
> In reality GerbV has always been the only program in the package to
> compile correctly for Windows, I generated it annually for Linux and
> Windows colleagues, and due to its ease I still find it superior to the
> one integrated into KiCad, even if it does not support the Gerber X2
> standard is become obsolete.
>
>
> Take a look to Lepton:
> https://github.com/lepton-eda/lepton-eda
> seems mantained
>
> Valerio
>
>
> On 1/27/24 1:46 PM, Nils Breunese wrote:
> > I’m not familiar with gEDA, but according to
> https://github.com/macports/macports-ports/blob/master/science/geda-gaf/Portfile
> the homepage is http://www.geda-project.org/
> >
> > But requests to both the .com and the .org domains indeed fail for me.
> >
> > Nils.
> >
> >> Op 26 jan 2024, om 03:37 heeft Mark Anderson  het
> volgende geschreven:
> >>
> >> I've been having trouble getting to http://www.geda-project.com/ -
> anyone else? This doesn't bode well for the project / Portfile. It might be
> time to retire it, or mark it as deprecated.
> >>
> >> —Mark
>

Re: Builder request, h5fortran on Sonoma x86

[Dave Allured - NOAA Affiliate via macports-dev]

Sergey, you are welcome.  Please also close your upstream ticket, if you
agree that it is resolved.
https://github.com/geospace-code/h5fortran/issues/46


On Sat, Jan 13, 2024 at 8:13 PM Sergey Fedorov  wrote:

> Dave, Josh, thanks for taking care of h5fortran!
>
> On Sun, Jan 14, 2024 at 10:34 AM Dave Allured - NOAA Affiliate via
> macports-dev  wrote:
>
>> On Sat, Jan 13, 2024 at 6:24 PM Joshua Root  wrote:
>>
>>> On 14/1/2024 12:04, Dave Allured - NOAA Affiliate via macports-dev wrote:
>>> > Would someone please push through a rebuild of h5fortran on Sonoma
>>> x86,
>>> > such that the status page is correctly updated?  I think this bad
>>> build:
>>> >
>>> > https://ports.macports.org/port/h5fortran/builds/
>>> > <https://ports.macports.org/port/h5fortran/builds/>  (OS 14 x86)
>>> > https://trac.macports.org/ticket/68499
>>> > <https://trac.macports.org/ticket/68499>
>>> >
>>> > ... was fixed as indicated in the ticket.  Remind me what I should do
>>> > for this, if anything.  Thanks for any help or advice.
>>>
>>> The buildbot is just finishing up the last of the ports. We'll run
>>> through all the ones that weren't successfully built again soon, to pick
>>> up fixes for Xcode issues etc. that have been made in the meantime.
>>>
>>> Committers with a buildbot account can force a build to run, and
>>> committing any change to a port's files will also run a new build if it
>>> failed previously. I queued one up for h5fortran.
>>>
>>
>> Well that was surprisingly quick.  Thanks, Josh!
>> https://ports.macports.org/port/h5fortran/builds/
>>
>

Re: Builder request, h5fortran on Sonoma x86

[Dave Allured - NOAA Affiliate via macports-dev]

On Sat, Jan 13, 2024 at 6:24 PM Joshua Root  wrote:

> On 14/1/2024 12:04, Dave Allured - NOAA Affiliate via macports-dev wrote:
> > Would someone please push through a rebuild of h5fortran on Sonoma x86,
> > such that the status page is correctly updated?  I think this bad build:
> >
> > https://ports.macports.org/port/h5fortran/builds/
> > <https://ports.macports.org/port/h5fortran/builds/>  (OS 14 x86)
> > https://trac.macports.org/ticket/68499
> > <https://trac.macports.org/ticket/68499>
> >
> > ... was fixed as indicated in the ticket.  Remind me what I should do
> > for this, if anything.  Thanks for any help or advice.
>
> The buildbot is just finishing up the last of the ports. We'll run
> through all the ones that weren't successfully built again soon, to pick
> up fixes for Xcode issues etc. that have been made in the meantime.
>
> Committers with a buildbot account can force a build to run, and
> committing any change to a port's files will also run a new build if it
> failed previously. I queued one up for h5fortran.
>

Well that was surprisingly quick.  Thanks, Josh!
https://ports.macports.org/port/h5fortran/builds/

Builder request, h5fortran on Sonoma x86

[Dave Allured - NOAA Affiliate via macports-dev]

Would someone please push through a rebuild of h5fortran on Sonoma x86,
such that the status page is correctly updated?  I think this bad build:

https://ports.macports.org/port/h5fortran/builds/  (OS 14 x86)
https://trac.macports.org/ticket/68499

... was fixed as indicated in the ticket.  Remind me what I should do for
this, if anything.  Thanks for any help or advice.

Re: How to fix duplicate rpath in existing library files

[Dave Allured - NOAA Affiliate via macports-dev]

Thanks, that seems to be working well.  I hope this can be made default, so
that we do not need to visit every port that makes a library and uses the
PG.  I do not know how widespread the LC_RPATH problem is.


On Mon, Dec 18, 2023 at 12:28 PM Kirill A. Korinsky 
wrote:

> If your port using compilers PG you may control it
> via compilers.add_gcc_rpath_support option.
>
> See:
> https://github.com/macports/macports-ports/commit/760f4f8df2b90a6e31bd960f9768bf086c35b19f
>
> --
> wbr, Kirill
>
> On 18. Dec 2023, at 20:08, Dave Allured - NOAA Affiliate via macports-dev <
> macports-dev@lists.macports.org> wrote:
>
> Now that the LC_RPATH issue is better understood, is there a simple way to
> fix a duplicate rpath in a Macports previously built library file?  Will a
> simple rev bump clear out the duplicate, or is a deeper approach needed?
>
> CI on OS13 keeps failing when it installs one of these pre-built
> libraries, because of the Xcode 15 linker.  The comment on one of those
> OpenBlas tickets has me hoping for a simple solution.
>
>

How to fix duplicate rpath in existing library files

[Dave Allured - NOAA Affiliate via macports-dev]

Now that the LC_RPATH issue is better understood, is there a simple way to
fix a duplicate rpath in a Macports previously built library file?  Will a
simple rev bump clear out the duplicate, or is a deeper approach needed?

CI on OS13 keeps failing when it installs one of these pre-built libraries,
because of the Xcode 15 linker.  The comment on one of those OpenBlas
tickets has me hoping for a simple solution.

Close tickets

[Dave Allured - NOAA Affiliate via macports-dev]

Please close these tickets as completed.
50295   fgsl fails to install
65420   vtk @8.2.0 fails to build

Re: How to change Xcode/CLT version in CI/Github Actions

[Dave Allured - NOAA Affiliate via macports-dev]

On Tue, Nov 21, 2023 at 1:08 AM Joshua Root  wrote:

> On 21/11/2023 12:51, Dave Allured - NOAA Affiliate via macports-dev wrote:
> > Is there an easy way to select a specific Xcode or CLT version for CI
> > workflows?  Developers could insert such temporary control into
> > individual PR's, to be excluded upon merging.   Alternatively, Macports
> > could insert this into macports-ports/master for community benefit,
> > while we ride out the wait for Apple fixes or other solutions.
>
> Any problems seen on CI due to Xcode 15 will also be seen by end users
> running that Xcode version. So any necessary workarounds should be
> applied in ports based on $xcodeversion and/or $xcodecltversion.
>
> It's probably possible to install a different Xcode version as part of
> the CI bootstrap script, but that would eat up a lot of build minutes
> and would just be hiding the problems that users will be seeing if
> they're not worked around.
>

There is no possible port workaround for an Xcode/CLT mismatch such as the
current situation on CI OS 13 which I mentioned earlier.  CI OS 13 is in an
illegal condition, according to Macports specifications.  Since CI OS 13 is
required to submit pull requests, this effectively blocks all portfile
development.  Extra build minutes would be well justified in the short
term, to work around this illegal condition.  If you agree, then please
offer a control for the CLT or Xcode version, or else some other reasonable
solution.

How to change Xcode/CLT version in CI/Github Actions

[Dave Allured - NOAA Affiliate via macports-dev]

The default CLT version for the Ventura/OS13 CI was recently updated to CLT
15.0.  This brings all the love and joy of Xcode 15.0 anomalies to
CI/Github Actions.  This is obstructing normal portfile development and
testing for the otherwise standard Macports CI workflow.  I have recently
experienced on the OS13 CI:

* Xcode/CLT mismatch:
2023-11-20T23:30:48.9369220Z DEBUG: Xcode 14.3.1, CLT 15.0.0.0.1.1694021235

* 15.0 linker problem:
2023-11-20T23:43:13.2834120Z ld: duplicate LC_RPATH '/opt/local/lib/libgcc'
in '/opt/local/lib/libnetcdff.7.dylib'

The linker problem is addressed in several tickets, mainly trac #68329, so
no sense to rehash those details here.  Yes it is the same problem, no
longer confined to just Sonoma.

Is there an easy way to select a specific Xcode or CLT version for CI
workflows?  Developers could insert such temporary control into individual
PR's, to be excluded upon merging.   Alternatively, Macports could insert
this into macports-ports/master for community benefit, while we ride out
the wait for Apple fixes or other solutions.

Re: Xcode 15.0 on Ventura builders

[Dave Allured - NOAA Affiliate via macports-dev]

Chris, that is sensible.  I just wanted to get a feel for the playing field
here.  Yes indeed, there would be increased build failures.

> We have enough bug reports from users with Xcode 15 ...

Good point.  I also wonder when Sonoma and Xcode 15 will show up in Google
Actions/CI for Macports.  For portfile work, that would probably be more
useful than on builders, right now.


On Fri, Sep 29, 2023 at 6:38 AM Chris Jones 
wrote:

> Hi,
>
> For me, I would hold off updating the macOS13 buildbots until the linker
> issues with Xcode 15 are resolved, as otherwise you are likely to see
> increased build failures, e.g. with ports that use gcc built binaries. At
> least at the moment the buildbots are still able to provide binary
> tarballs, minimising the impact of these issues to those who have updated
> Xcode.
>
> We have enough bug reports from users with Xcode 15, and eventually any
> macOS14 buildbots. I don’t see the advantage to also having these issues
> hit the macOS13 builds as well.
>
> Chris
>
> > On 29 Sep 2023, at 3:24 am, Dave Allured - NOAA Affiliate via
> macports-dev  wrote:
> >
> > 
> > Devs, Xcode 15.0 with all its "interesting" issues is supposed to be
> compatible with Ventura versions 13.5 and up.  Would it be reasonable to
> update any of the Ventura build machines with Xcode/CLT 15.0 for testing
> purposes, instead of waiting for a Sonoma builder to be available?
>

Xcode 15.0 on Ventura builders

[Dave Allured - NOAA Affiliate via macports-dev]

Devs, Xcode 15.0 with all its "interesting" issues is supposed to be
compatible with Ventura versions 13.5 and up.  Would it be reasonable to
update any of the Ventura build machines with Xcode/CLT 15.0 for testing
purposes, instead of waiting for a Sonoma builder to be available?

NCO: Close #47056

[Dave Allured - NOAA Affiliate via macports-dev]

Someone please close https://trac.macports.org/ticket/47056 as resolved.
Thanks.

Re: Clean up PROJ mess

[Dave Allured - NOAA Affiliate via macports-dev]

Niklas, you proposed that "proj9" be renamed to "proj", later in the
migration.  I suggest a minor change.  Keep "proj9" unchanged, and make
"proj" an alias for proj9, or whatever the macports mechanism is for that.
This means that current ports that need "proj9" explicitly in some way,
remain unaffected.

After that, always install future major versions as explicitly pinned;
"proj10", etc.  "proj" gets updated too, but remains an alias or pointer
for "the latest version".  Port devs will then have their choice of pinned
or unpinned version, whatever they think is best for their scenario.
Hopefully this will mean less work at each major version step for proj.


On Fri, Sep 8, 2023 at 10:16 AM Nicklas Larsson  wrote:

> Hi all!
>
> Glad you took up this subject again. I have meant to return to this, but
> things always come between.
>
> Just to clarify, my main objective is to *rename* the existing proj ports
> and the latest version would always be ‘proj’.
>
> The ports that do not support the new 8+ API will still have its proper
> dependency (proj7, proj6 etc.).
>
> In PROJ version 5 through 8 the API was transformed, this means with
> version 8 the “old” API was abandoned.
> SAGA, for example, still only support the old API, thus the proj version 7
> is the latest one supported.
>
> Cheers,
> Nicklas
>
> On 8 Sep 2023, at 16:52, Sergey Fedorov  wrote:
>
> I have obviously forgotten to try the new Proj with R ports back then, and
> atm away from native PPC hardware; so from my side I would prefer not
> moving to a newer Proj right-away.
> Switching to explicit proj5 port should be perfectly fine, of course. (And
> then R ports won’t prevent anything else from updating.)
>
> New Proj *should* work with R packages, but let me wait until I can test
> that on PPC.
>
> On Fri, Sep 8, 2023 at 9:38 PM Dave Allured - NOAA Affiliate via
> macports-dev  wrote:
>
>> As a contributor to ncarg (proj5), I like this change.  Currently there
>> are only 10 ports that depend on the traditional "proj" which is really
>> proj5 under the hood.  Collectively there are only 3 maintainers plus a few
>> nomaintainers, and Sergey has already approved for several of the R ports.
>>
>> So I see the migration for this group of "proj5" ports as quite simple.
>> As a first step, could we add an explicit proj5 port, such that proj and
>> proj5 co-exist temporarily and are exactly the same?  That could be done
>> safely now, with no impact on anything else.  Then after migration of those
>> 10 ports, "proj" could be easily switched to the latest upstream version,
>> as proposed.
>>
>>
>> On Thu, Jun 8, 2023 at 2:09 PM Sergey Fedorov 
>> wrote:
>>
>>> IMO that makes sense.
>>>
>>> My R ports are supposed to support more recent versions of Proj than 5,
>>> but since that is untested locally (and also requires minor adjustments to
>>> configure args besides swapping version number), it is perhaps safer to
>>> keep them at Proj5 for now (I guess that is also simpler for you?).
>>> Then I can move them to a later or the current Proj in a while.
>>>
>>> On Fri, Jun 9, 2023 at 3:54 AM Nicklas Larsson via macports-dev <
>>> macports-dev@lists.macports.org> wrote:
>>>
>>>> Hello all,
>>>>
>>>> I'd like to propose to simplify the maintainance of the PROJ ports,
>>>> which has
>>>> become unnecessary cumbersome and in many cases leading to installments
>>>> of
>>>> multiple versions only because different ports are out-of-sync in
>>>> respect to
>>>> default proj variant.
>>>>
>>>> The PROJ ports available now:
>>>>
>>>> portversion
>>>> ---
>>>> proj4   4.9.3
>>>> proj5.2.0
>>>> proj6   6.3.2
>>>> proj7   7.2.1
>>>> proj8   8.2.1
>>>> proj9   9.2.1
>>>>
>>>> It would be better to use the port name 'proj' for the latest version
>>>> available
>>>> (independent of major version), which now is version 9.2.1. The present
>>>> port
>>>> 'proj', which is version 5.2.0, should be renamed to 'proj5'. Like this:
>>>>
>>>> portversion
>>>> ---
>>>> proj4   4.9.3
>>>> proj5   5.2.0
>>>> proj6   6.3.2
>>>> proj7   7.2.1
>>>> proj8   8.2.1
>>>> proj9.2.1
>>>>
>>>> The day

Re: Clean up PROJ mess

[Dave Allured - NOAA Affiliate via macports-dev]

As a contributor to ncarg (proj5), I like this change.  Currently there are
only 10 ports that depend on the traditional "proj" which is really proj5
under the hood.  Collectively there are only 3 maintainers plus a few
nomaintainers, and Sergey has already approved for several of the R ports.

So I see the migration for this group of "proj5" ports as quite simple.  As
a first step, could we add an explicit proj5 port, such that proj and proj5
co-exist temporarily and are exactly the same?  That could be done safely
now, with no impact on anything else.  Then after migration of those 10
ports, "proj" could be easily switched to the latest upstream version, as
proposed.


On Thu, Jun 8, 2023 at 2:09 PM Sergey Fedorov  wrote:

> IMO that makes sense.
>
> My R ports are supposed to support more recent versions of Proj than 5,
> but since that is untested locally (and also requires minor adjustments to
> configure args besides swapping version number), it is perhaps safer to
> keep them at Proj5 for now (I guess that is also simpler for you?).
> Then I can move them to a later or the current Proj in a while.
>
> On Fri, Jun 9, 2023 at 3:54 AM Nicklas Larsson via macports-dev <
> macports-dev@lists.macports.org> wrote:
>
>> Hello all,
>>
>> I'd like to propose to simplify the maintainance of the PROJ ports, which
>> has
>> become unnecessary cumbersome and in many cases leading to installments of
>> multiple versions only because different ports are out-of-sync in respect
>> to
>> default proj variant.
>>
>> The PROJ ports available now:
>>
>> portversion
>> ---
>> proj4   4.9.3
>> proj5.2.0
>> proj6   6.3.2
>> proj7   7.2.1
>> proj8   8.2.1
>> proj9   9.2.1
>>
>> It would be better to use the port name 'proj' for the latest version
>> available
>> (independent of major version), which now is version 9.2.1. The present
>> port
>> 'proj', which is version 5.2.0, should be renamed to 'proj5'. Like this:
>>
>> portversion
>> ---
>> proj4   4.9.3
>> proj5   5.2.0
>> proj6   6.3.2
>> proj7   7.2.1
>> proj8   8.2.1
>> proj9.2.1
>>
>> The day when there is a new major version, e.g. 10.0.0, the 'proj' port
>> will be
>> updated accordingly and 'proj9' will keep the 9.x.y version:
>>
>> portversion
>> ---
>> proj4   4.9.3
>> proj5   5.2.0
>> proj6   6.3.2
>> proj7   7.2.1
>> proj8   8.2.1
>> proj9   9.2.1
>> proj10.0.0
>>
>> The ports with 'proj' dependency, which are actively updated and
>> maintained,
>> will in this way be kept in sync with less risk of installing multiple
>> versions.
>> Ports, which do not support later versions of PROJ, can keep the pinned
>> version.
>>
>> List of ports with proj[x] dependency:
>>
>> R/R-lwgeom  path:lib/proj5/lib/pkgconfig/proj.pc:proj
>> R/R-proj4   path:lib/proj5/lib/pkgconfig/proj.pc:proj
>> R/R-reproj  path:lib/proj5/lib/pkgconfig/proj.pc:proj
>> R/R-rgdal   path:lib/proj5/lib/pkgconfig/proj.pc:proj
>> R/R-sf  path:lib/proj5/lib/pkgconfig/proj.pc:proj
>> R/R-terra   path:lib/proj5/lib/pkgconfig/proj.pc:proj
>> R/R-vapour  path:lib/proj5/lib/pkgconfig/proj.pc:proj
>> databases/mysql55-lib_mysqludf_fproj4   port:proj4
>> databases/postgis   port:proj4
>> databases/postgis2  port:proj6
>> databases/postgis3  port:proj[6-9]
>> databases/spatialite-tools  port:proj[6-9]
>> databases/spatialiteport:proj[6-9]
>> gis/gdalport:proj[6-9]
>> gis/grass   port:proj[6-9]
>> gis/grass7  port:proj[6-9]
>> gis/liblas  port:proj[6-9]
>> gis/libosmium   port:proj4
>> gis/mapnik  port:proj4
>> gis/mapserver   port:proj[6-9]
>> gis/mod_tileport:proj4
>> gis/osm2pgsql   port:proj8
>> gis/qgis3   port:proj[6-9]
>> gis/qlandkarte  port:proj4
>> gis/qlandkartegtport:proj[4-7]
>> gis/sagaport:proj8
>> graphics/libgeotiff port:proj[7-9]
>> octave/octave-octproj   port:proj8
>> perl/p5-alien-proj  port:proj[6-9]
>> perl/p5-alien-proj4 port:proj4
>> python/py-cartopy   port:proj8
>> python/py-pyprojport:proj8
>> python/py-spatialiteport:proj4
>> science/cdo port:proj8
>> science/gerris  port:proj
>> science/magicsppport:proj6
>> science/metview port:proj6
>> science/ncarg   port:proj
>> science/relax3d 

Close ncarg: trac #64710

[Dave Allured - NOAA Affiliate via macports-dev]

Someone please close https://trac.macports.org/ticket/64710 as completed.
Thanks.

Close trac #66411

[Dave Allured - NOAA Affiliate via macports-dev]

Someone please close https://trac.macports.org/ticket/66411 as completed.
I can't do it myself, and it did not auto-close on the PR.  Thanks.

Re: Builder requests

[Dave Allured - NOAA Affiliate via macports-dev]

Thanks, Jeremy.  No worries about the off-lines.  I have already gotten
used to it, and I know how to monitor using the builds website.  I just
wish I could see the actual port queues, and do my own triggers.


On Fri, Aug 11, 2023 at 7:22 AM Jeremy Lavergne  wrote:

> Regarding the offline nodes. the current list is:
>   * ports-11 x86_64
>   * ports-12 arm64
>   * ports-12 x64_64
>   * ports-13 arm64
>
> On 8/11/23 09:15, Jeremy Lavergne wrote:
> > I've added py-nio to all the ports-10.11+ builders, however it looks
> > like only the arm builders are online.
>

Builder requests

[Dave Allured - NOAA Affiliate via macports-dev]

I was recently advised to post builder requests to macports-dev.  This
seems awkward to me, but here goes.

Rebuild py-nio and py-ngl, in that order because of dependency sequence.
Builders 10.11 through both Ventura.  Reason:  Failed dependency ncarg was
fixed.  Skip all 10.10 and earlier, because of a failed dependency.

Rebuild esmf, 10.10 only, so I can get a log file.  Expected fail.

Thanks for your help.

How to rebuild after failed install-dependencies

[Dave Allured - NOAA Affiliate via macports-dev]

I am monitoring several ports after a broken dependency was fixed.  I
notice that the dependent ports remain broken, and there does not seem to
be an automatic trigger to rebuild and update their port health as seen on
the ports website.

Is there a recommended procedure to trigger rebuilds in this case?  Is this
trigger supposed to be automated?  I could not find documentation about
this.  I manually triggered one (ncarg) with a rev bump, but this does not
seem appropriate within the otherwise robust builder system.

Re: Unable to fetch sources from GitLab instance

[Dave Allured - NOAA Affiliate via macports-dev]

Jason, port fetch with your unmodified portfile works fine for me.
Monterey x86_64, Macports 2.81, freshly updated.  I think your portfile
recipe for this gitlab instance is good.  There have been several recent
reports of Macports fetch problems.  These often relate to down level Apple
native versions of curl on older Macs, improper certificate updates on
servers, etc.

There is a shortcut if it is only a single tar file.  Instead of spending
time diagnosing, just manually download the distfile, which you already
have.  Then manually insert that into
(prefix)/var/macports/distfiles/librist, then re-run port install, as
described in https://trac.macports.org/wiki/ProblemHotlist#fetch-failures.
Port install will then skip the problematic download and be happy with the
local copy.  When your portfile is later merged into Macports, the distfile
will be propagated to various mirrors, which will then serve anyone having
problems with the original server.

Also see:  https://trac.macports.org/wiki/ProblemHotlist#letsencrypt


On Sat, Jul 29, 2023 at 9:14 AM Jason Liu  wrote:

> By the way, here is my Portfile for librist, in case anyone wants to try
> and see whether fetching from VideoLAN's GitLab instance works for them.
> --
> Jason Liu
>
>
> On Fri, Jul 28, 2023 at 11:47 PM Jason Liu  wrote:
>
>> Hi all,
>>
>> I suppose I should be directing this question to René Bertin, since he's
>> the maintainer of the VLC port, but I'm sending this to the entire dev
>> mailing list, in case anyone else has any ideas.
>>
>> I'm trying to create a Portfile for librist, which is one of the projects
>> that's being hosted on https://code.videolan.org. My question to René
>> (and everyone else) is: Have you had any luck trying to fetch sources from
>> code.videolan.org? When I try to use the gitlab PortGroup, MacPorts
>> doesn't seem to find a tarball at the URL that is generated by the
>> PortGroup. However, I'm able to download the file using a web browser, and
>> even curl downloads the file just fine:
>>
>> /usr/bin/curl -LROJk
>> https://code.videolan.org/rist/librist/-/archive/v0.2.7/librist-v0.2.7.tar.bz2
>>
>> Does anyone have any explanation for the behavior that I'm seeing?
>> --
>> Jason Liu
>>
>

Re: Problem fetching with git in MacPorts

[Dave Allured - NOAA Affiliate via macports-dev]

Robert, it looks like you might be seeing this Let's Encrypt known problem:
https://trac.macports.org/wiki/ProblemHotlist#letsencrypt

If so, the best solution is not to replace /usr/bin/git, but to ask
Codeberg owners to remove the expired certificate as described in that
article.  Note the special instructions for Mac OS 10.13/10.14.


On Wed, May 17, 2023 at 6:04 AM Robert Kennedy  wrote:

> Thanks Joshua.  That was exactly what was needed.
>
> Perhaps a ticket should be created recommending that "git.cmd" be added
> to the MacPorts Guide.
>
> Rob
> --
> *From:* Joshua Root 
> *Sent:* May 17, 2023 4:47 AM
> *To:* Robert Kennedy ; MacPorts Development <
> macports-dev@lists.macports.org>
> *Subject:* Re: Problem fetching with git in MacPorts
>
> On 17/5/2023 07:44, Robert Kennedy wrote:
> > I am unable to fetch a file in a git repo using MacPorts.  I get an SSL
> > expired error.
> >
> > fatal: unable to access
> > 'https://codeberg.org/schilytools/schilytools.git/': *SSL
> > certificate problem: certificate has expired*
> > *Command failed: /usr/bin/git clone* --progress --depth=1
> > https://codeberg.org/schilytools/schilytools.git
> >
> /opt/local/var/macports/build/_Users_grinch_Development_MacPorts_local-repo_ports_devel_smake/smake/work/schilytools-2023-04-19
> 2>&
> > Exit code: 128
> >
> > Please note that MacPorts is trying to use "*/usr/bin/git*" which is
> > OLD.  I can fetch the archive in the Terminal using the recent version
> > of git installed by MacPorts at "*/opt/local/bin/git*".
> >
> > "*/opt/local/bin/git*" is also in my $PATH.  When I run "*which git*", I
> > get "*/opt/local/bin/git*".
> >
> > If there a config setting in MacPorts to tell it to use git located at
> > "/opt/local/bin/git"?
>
> The Portfile option is 'git.cmd'.
>
> - Josh
>

Re: The State of Rust in MacPorts Today

[Dave Allured - NOAA Affiliate via macports-dev]

Is it possible to build recent versions directly with rust-1.54?  For
example, mrustc -> rust 1.54 -> rust 1.65?


On Tue, Dec 13, 2022 at 12:07 PM Kirill A. Korinsky via macports-dev <
macports-dev@lists.macports.org> wrote:

> David,
>
> the idea is creating a dependency chain:
>
> Port rust (version 1.66) depends on rust-1.65 to be build;
> Port rust-1.65 depends on rust-1.64 to be build;
> Port rust-1.64 depends on rust-1.63 to be build;
> ...
> Port rust-1.56 depends on rust-1.55 to be build;
> Port rust-1.55 depends on rust-1.54 to be build;
> Port rust-1.54 depends on mrsutc to be build.
>
> :)
>
> When someone would like to add rust 1.67, he need to add port rust-1.66
> which should be used as bootstrap compiler.
>
> I hate this way, but it is the only way to bootstrap it from scratch.
>
> When mrust had support new rust, we may cut the tree by removing a lot of
> unused ports.
> --
> wbr, Kirill
>
> On 13. Dec 2022, at 17:53, David Gilman  wrote:
>
> The work on mrustc is novel but I don't think it solves the issues we have
> here. On modern systems MacPorts uses bootstrap compilers provided by Rust
> upstream. MCL's bootstrap compilers are for older systems.
>
> To update rust, my understanding is that you have to do the usual work of
> rebasing patches (my PR), but you also have to provide the binaries for
> older systems which I could not provide.
>
>
> On Tue, Dec 13, 2022, 11:07 AM Kirill A. Korinsky via macports-dev <
> macports-dev@lists.macports.org> wrote:
>
>> Folks,
>>
>> From the third hand we may build our own bootstrap chain of rust from
>> scratch.
>>
>> Or almost.
>>
>> We have a https://ports.macports.org/port/mrustc/details/ which is able
>> to bootstrap 1.54 rust on x86_64 and arm64.
>>
>> Unfortunately support of i386 isn't yet finished at upstream. I plan to
>> fix it, but it requires time and availability of hardware to test it :)
>>
>> I do have a commits which implements rust bootstrap by cahin: mrustc ->
>> rust 1.54 -> rust 1.55 -> rust 1.56; I can start to open PRs to move
>> step-by-step and in month we'll have the last rust via this chain.
>> --
>> wbr, Kirill
>>
>> On 13. Dec 2022, at 16:49, Christopher Jones 
>> wrote:
>>
>> Hi,
>>
>> In my opinion, hosting and maintaining these ‘bootstrap’ compilers
>> outside the macports infrastructure was a poor choice, for all the reasons
>> you mention below. I thought this at the time it was done, and even more so
>> now.
>>
>> Personally, I would suggest you think about a change to how the rust
>> compiler is package, to mirror a bit how things are done with gcc and
>> clang. Namely, move to a model where the version is part of the port name,
>> e.g. the current one would be called something like rust-1.61.
>>
>> The main reason for doing this, is adding a new version would that not
>> remove the previous version, and thus you could simple use it as the
>> bootstrap compiler. So with the above, when you add rust-1.62 that would
>> simple configure itself to bootstrap using the macports rust-1.61 port.
>>
>> Yes, this will require some work to set up. You will need to make all the
>> various rust versions installable along side each other, so some tweaking
>> of the install prefix would be needed.
>>
>> One thing I would do differently though to how gcc/clang do things is I
>> would try and have a single rust port file, that implements all the
>> versions as sub-ports. I suspect most of what each needs can then just be
>> shared , such that what needs to be different for each sub-port is actually
>> not that much.
>>
>> Regarding how users of rust then use these ports, there are a couple
>> options
>>
>> 1. Add a shim port ‘rust’ which simply installs sym-links etc. to the
>> ‘current best version’ that mimics the current installation, i.e. in the
>> main prefix. If done well, users should then be blind to the changes above.
>> 2. Users that want an older rust could explicitly depend on and use a
>> specific versioned rust-N
>>
>> For me, this approach makes a lot more sense than the current way these
>> bootstrap compilers are maintained.
>>
>> cheers Chris
>>
>> On 13 Dec 2022, at 2:57 pm, Herby G  wrote:
>>
>> Hello all,
>>
>> Right now, Rust in MacPorts is severely out of date. It's about 5
>> versions behind the current release, which at the moment is at 1.65.0. In
>> comparison, MacPorts Rust is currently at 1.61.0.
>>
>> As a core language underlying a lot of other ports, many of these ports
>> cannot be updated to their latest versions because these versions require
>> current versions of Rust. At the time of this writing, 156 ports are being
>> built using Rust ( https://ports.macports.org/port/rust/details/ ), some
>> quite heavily used by the community, including projects like `git-delta`,
>> `bat` and `fd`.
>>
>> MarcusCalhoun-Lopez's PR here (
>> https://github.com/macports/macports-ports/pull/14277 ) heavily rewrote
>> the Rust port to run on older systems, and was very much celebrated and
>> endorsed. However, 

Re: CalculiX build error using clang

[Dave Allured - NOAA Affiliate via macports-dev]

If you want to be thorough, then search the rest of the code for all
references to this function.  Look for any call that checks a return code.
Also see if and how the function is defined for public or external use.  If
there is any hint of referencing a return code, then declare the return
type as "int", and add return (0) at the end of the main part of the
function.


On Tue, Jul 26, 2022 at 11:28 AM Blair Zajac  wrote:

> Yes, that would fix it.
>
> On Jul 26, 2022, at 10:27 AM, Mark Brethen  wrote:
>
> would a ‘return;’ instead of ‘return(-1);’ suffice>?
>
> Mark Brethen
> mark.bret...@gmail.com
>
> On Jul 26, 2022, at 11:51 AM, Christopher Jones 
> wrote:
>
> clang is correct in this case, gcc is being sloppy.
>
> Basically you cannot return a value, from a function declared as void…
> fairly basic stuff really..
>
> On 26 Jul 2022, at 5:34 pm, Mark Brethen  wrote:
>
> I’m seeing this build error when using clang (gcc doesn’t complain):
>
> info:build /opt/local/bin/clang-mp-14 -O2 -Wall -Wno-narrowing -I./
> -I/opt/local/include -I/opt/local/include/GL -I../../libSNL/src
> -I../../glut-3.5/src-c -o pickFunktions.o pickFunktions.c
> :info:build pickFunktions.c:4599:7: error: void function
> 'moveLineEndPoint' should not return a value [-Wreturn-type]
> :info:build   return(-1);
> :info:build   ^ 
>
> code snippet below:
>
>  void moveLineEndPoint(int lineNr, int pntNr, double llength)
> {
>   int p1,p2, flag=0;
>   double P1[3], P2[3], u, eva[3], va[3], p0p1_2[3];
>
> p1=line[lineNr].p1;
> p2=line[lineNr].p2;
>
> /* determine which side of the line has to be moved */
> if(pntNr==p1) flag=-1;
> else if(pntNr==p2) flag=1;
> else
> {
>   printf("ERROR: selected point:%s is no line endpoint\n",
> point[pntNr].name);
>   return(-1);
> }
> u=flag*llength;
> u/=scale->w;
>
> /* calc direction */
> if(line[lineNr].typ=='s')
> {
>   if(flag==-1) p2=set[line[lineNr].trk].pnt[1];
>   else  p1=set[line[lineNr].trk].pnt[set[line[lineNr].trk].anz_p-2];
> }
> P1[0]=point[p1].px;
> P1[1]=point[p1].py;
> P1[2]=point[p1].pz;
> P2[0]=point[p2].px;
> P2[1]=point[p2].py;
> P2[2]=point[p2].pz;
> v_result( P1, P2, p0p1_2);
> v_norm(p0p1_2,eva);
> v_scal(,eva, va);
> point[pntNr].px+=va[0];
> point[pntNr].py+=va[1];
> point[pntNr].pz+=va[2];
> printf("moved by dxyz= %lf %lf %lf\n",
>   (va[0]* scale->w),
>   (va[1]* scale->w),
>   (va[2]* scale->w));
> }
>
> I do not code in C, so I’ll pass this up to the developer. How should this
> be patched?
>
> Thanks,
> Mark
>
>

Re: fetch timeout

[Dave Allured - NOAA Affiliate via macports-dev]

On Wed, Jul 20, 2022 at 11:48 AM Christopher Jones 
wrote:

> On 20 Jul 2022, at 6:32 pm, Dave Allured - NOAA Affiliate via macports-dev
>  wrote:
>
> On Wed, Jul 20, 2022 at 2:30 AM Christopher Jones <
> jon...@hep.phy.cam.ac.uk> wrote:
>
>> On 20 Jul 2022, at 1:13 am, Dave Allured - NOAA Affiliate via
>> macports-dev  wrote:
>>
>> Hmmm.  If port curl is already installed and active, then why would
>> subsequent port fetches prefer /usr/bin/curl?  Is this a search path issue?
>>
>>
>> No. port does not rely on finding ‘curl’, from PATH. It instead uses the
>> system lib curl which it is liked against. The only way to get port to use
>> a different curl is to rebuild base, configured to use that version.
>>
>
> Ah, that is what I missed.  How about adding a fallback option to use an
> alternate command line curl through PATH, when available, after normal
> fetch attempts have failed?  My hope is that this would ultimately reduce
> time spent on debugging connection and SSL issues.
>
>
> Please read the discussion at
>
> https://trac.macports.org/ticket/51516
>
> and add any comments you might have.
>
> In short, adding a ‘fallback to curl’ is very non trivial to do, perhaps
> not even possible.
>


Chris, sorry, missed this before my last reply to Joshua.  I already read
that ticket, will go back and study more.

Re: fetch timeout

[Dave Allured - NOAA Affiliate via macports-dev]

On Wed, Jul 20, 2022 at 2:30 AM Christopher Jones 
wrote:

> On 20 Jul 2022, at 1:13 am, Dave Allured - NOAA Affiliate via macports-dev
>  wrote:
>
> Hmmm.  If port curl is already installed and active, then why would
> subsequent port fetches prefer /usr/bin/curl?  Is this a search path issue?
>
>
> No. port does not rely on finding ‘curl’, from PATH. It instead uses the
> system lib curl which it is liked against. The only way to get port to use
> a different curl is to rebuild base, configured to use that version.
>

Ah, that is what I missed.  How about adding a fallback option to use an
alternate command line curl through PATH, when available, after normal
fetch attempts have failed?  My hope is that this would ultimately reduce
time spent on debugging connection and SSL issues.

Re: fetch timeout

[Dave Allured - NOAA Affiliate via macports-dev]

Then I think it would help to change base, so that Apple’s curl/openssl is
only used initially.  If and when the curl port becomes installed and
active, use that for subsequent port installs.  This is similar to the way
that other support tools are already managed inside Macports.

This is a rehash of parts of https://trac.macports.org/ticket/51516 , as
Chris already pointed to.  I read that, and I did not see a reason to not
"upgrade" curl, as soon as port curl is available in /opt/local.  What am I
missing?


On Tue, Jul 19, 2022 at 6:25 PM Mark Brethen  wrote:

> port is setup to use apple’s curl/openssl.
>
> Mark Brethen
> mark.bret...@gmail.com
>
> On Jul 19, 2022, at 7:13 PM, Dave Allured - NOAA Affiliate via
> macports-dev  wrote:
>
> Hmmm.  If port curl is already installed and active, then why would
> subsequent port fetches prefer /usr/bin/curl?  Is this a search path issue?
>
>
> On Tue, Jul 19, 2022 at 6:00 PM Mark Brethen 
> wrote:
>
>> tetgen has dependency on cmake which depends on curl. If it's possible to
>> check the machine and os version, could override fetch under those specific
>> cases.
>>
>> I’ll also contact the host, but I suspect it’s a bug in openssl:
>>
>> routines:CONNECT_CR_KEY_EXCH:sslv3 alert handshake
>> failure:/System/Volumes/Data/SWE/macOS/BuildRoots/880a0f6e74/Library/Caches/com.apple.xbs/Sources/libressl/libressl-56.60.4/libressl-2.8/ssl/ssl_pkt.c:1200:SSL
>> alert number 40
>>
>> Mark Brethen
>> mark.bret...@gmail.com
>>
>> On Jul 19, 2022, at 6:00 PM, Dave Allured - NOAA Affiliate via
>> macports-dev  wrote:
>>
>> Several of us have now reproduced the SSL problem.  I see two things in
>> common:
>> (1)  Older curl/SSL versions bundled into older MacOS versions, such as
>> Catalina.
>> (2)  The target website, wias-berlin.de.
>>
>> I suspect wias-berlin.de is misconfigured somehow.  Mark, consider
>> showing this problem to them, and ask them to check their server
>> configuration.  It is reasonable to expect Catalina Macs to be able to
>> download their files using the system curl.  I can certainly download from
>> many other websites.
>>
>> Another possibility is to go back to one of Mark's earlier ideas.  Get
>> Macports to use the MP version of curl.  I don't know how to do this.  What
>> happens if you simply install and activate port curl, before install tetgen
>> (Mark's new port)?
>>
>>
>> On Tue, Jul 19, 2022 at 11:26 AM Mark Brethen 
>> wrote:
>>
>>> Big Sur installs the same version curl/openssl and it does not work on
>>> intel. It does work on an M1, which is surprising.
>>>
>>> ~ $ /usr/bin/curl --version
>>> curl 7.64.1 (x86_64-apple-darwin20.0) libcurl/7.64.1 (SecureTransport)
>>> LibreSSL/2.8.3 zlib/1.2.11 nghttp2/1.41.0
>>> Release-Date: 2019-03-27
>>> Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps
>>> pop3 pop3s rtsp smb smbs smtp smtps telnet tftp
>>> Features: AsynchDNS GSS-API HTTP2 HTTPS-proxy IPv6 Kerberos Largefile
>>> libz MultiSSL NTLM NTLM_WB SPNEGO SSL UnixSockets
>>> ~ $
>>>
>>> I noticed nghttp2 @1.41.0 vs 1.39.2.
>>>
>>> Mark Brethen
>>> mark.bret...@gmail.com
>>>
>>> On Jul 19, 2022, at 12:07 PM, Gary Palter  wrote:
>>>
>>> Apparently not.
>>>
>>> Last login: Tue Jul 19 12:56:44 on console
>>> palter@Catalina ~ % /usr/bin/curl --version
>>> curl 7.64.1 (x86_64-apple-darwin19.0) libcurl/7.64.1 (SecureTransport)
>>> LibreSSL/2.8.3 zlib/1.2.11 nghttp2/1.39.2
>>> Release-Date: 2019-03-27
>>> Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps
>>> pop3 pop3s rtsp smb smbs smtp smtps telnet tftp
>>> Features: AsynchDNS GSS-API HTTP2 HTTPS-proxy IPv6 Kerberos Largefile
>>> libz MultiSSL NTLM NTLM_WB SPNEGO SSL UnixSockets
>>> palter@Catalina ~ % cd Downloads
>>> palter@Catalina Downloads % /usr/bin/curl -O
>>> https://wias-berlin.de/software/tetgen/1.5/src/tetgen1.5.1.tar.gz
>>>   % Total% Received % Xferd  Average Speed   TimeTime Time
>>>  Current
>>>  Dload  Upload   Total   SpentLeft
>>>  Speed
>>>   0 00 00 0  0  0 --:--:-- --:--:-- --:--:--
>>> 0
>>> curl: (35) error:14008410:SSL routines:CONNECT_CR_KEY_EXCH:sslv3 alert
>>> handshake failure
>>> palter@Catalina Downloads %
>>>
>>> The above is a vanilla install of Intel Catalina running in a

Re: fetch timeout

[Dave Allured - NOAA Affiliate via macports-dev]

Hmmm.  If port curl is already installed and active, then why would
subsequent port fetches prefer /usr/bin/curl?  Is this a search path issue?


On Tue, Jul 19, 2022 at 6:00 PM Mark Brethen  wrote:

> tetgen has dependency on cmake which depends on curl. If it's possible to
> check the machine and os version, could override fetch under those specific
> cases.
>
> I’ll also contact the host, but I suspect it’s a bug in openssl:
>
> routines:CONNECT_CR_KEY_EXCH:sslv3 alert handshake
> failure:/System/Volumes/Data/SWE/macOS/BuildRoots/880a0f6e74/Library/Caches/com.apple.xbs/Sources/libressl/libressl-56.60.4/libressl-2.8/ssl/ssl_pkt.c:1200:SSL
> alert number 40
>
> Mark Brethen
> mark.bret...@gmail.com
>
> On Jul 19, 2022, at 6:00 PM, Dave Allured - NOAA Affiliate via
> macports-dev  wrote:
>
> Several of us have now reproduced the SSL problem.  I see two things in
> common:
> (1)  Older curl/SSL versions bundled into older MacOS versions, such as
> Catalina.
> (2)  The target website, wias-berlin.de.
>
> I suspect wias-berlin.de is misconfigured somehow.  Mark, consider
> showing this problem to them, and ask them to check their server
> configuration.  It is reasonable to expect Catalina Macs to be able to
> download their files using the system curl.  I can certainly download from
> many other websites.
>
> Another possibility is to go back to one of Mark's earlier ideas.  Get
> Macports to use the MP version of curl.  I don't know how to do this.  What
> happens if you simply install and activate port curl, before install tetgen
> (Mark's new port)?
>
>
> On Tue, Jul 19, 2022 at 11:26 AM Mark Brethen 
> wrote:
>
>> Big Sur installs the same version curl/openssl and it does not work on
>> intel. It does work on an M1, which is surprising.
>>
>> ~ $ /usr/bin/curl --version
>> curl 7.64.1 (x86_64-apple-darwin20.0) libcurl/7.64.1 (SecureTransport)
>> LibreSSL/2.8.3 zlib/1.2.11 nghttp2/1.41.0
>> Release-Date: 2019-03-27
>> Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps
>> pop3 pop3s rtsp smb smbs smtp smtps telnet tftp
>> Features: AsynchDNS GSS-API HTTP2 HTTPS-proxy IPv6 Kerberos Largefile
>> libz MultiSSL NTLM NTLM_WB SPNEGO SSL UnixSockets
>> ~ $
>>
>> I noticed nghttp2 @1.41.0 vs 1.39.2.
>>
>> Mark Brethen
>> mark.bret...@gmail.com
>>
>> On Jul 19, 2022, at 12:07 PM, Gary Palter  wrote:
>>
>> Apparently not.
>>
>> Last login: Tue Jul 19 12:56:44 on console
>> palter@Catalina ~ % /usr/bin/curl --version
>> curl 7.64.1 (x86_64-apple-darwin19.0) libcurl/7.64.1 (SecureTransport)
>> LibreSSL/2.8.3 zlib/1.2.11 nghttp2/1.39.2
>> Release-Date: 2019-03-27
>> Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps
>> pop3 pop3s rtsp smb smbs smtp smtps telnet tftp
>> Features: AsynchDNS GSS-API HTTP2 HTTPS-proxy IPv6 Kerberos Largefile
>> libz MultiSSL NTLM NTLM_WB SPNEGO SSL UnixSockets
>> palter@Catalina ~ % cd Downloads
>> palter@Catalina Downloads % /usr/bin/curl -O
>> https://wias-berlin.de/software/tetgen/1.5/src/tetgen1.5.1.tar.gz
>>   % Total% Received % Xferd  Average Speed   TimeTime Time
>>  Current
>>  Dload  Upload   Total   SpentLeft
>>  Speed
>>   0 00 00 0  0  0 --:--:-- --:--:-- --:--:--
>> 0
>> curl: (35) error:14008410:SSL routines:CONNECT_CR_KEY_EXCH:sslv3 alert
>> handshake failure
>> palter@Catalina Downloads %
>>
>> The above is a vanilla install of Intel Catalina running in a VM.
>>
>>   - Gary
>>
>> On Jul 19, 2022, at 12:55 PM, Mark Brethen 
>> wrote:
>>
>> Anyone else confirm system curl works with this host on intel mac with
>> catalina or big sur?
>>
>> Mark
>>
>> On Jul 19, 2022, at 11:49 AM, Mark Brethen 
>> wrote:
>>
>> Yes, I have mp curl as well. Unfortunately, port uses Apple’s
>> curl/openssl. Only work around is to override fetch and use mp.
>>
>> Mark Brethen
>> mark.bret...@gmail.com
>>
>> On Jul 19, 2022, at 11:42 AM, Nils Breunese  wrote:
>>
>> Mark Brethen  wrote:
>>
>> What version of curl/libressl?
>>
>>
>>
>> I have curl and openssl installed from MacPorts:
>>
>> ❯ port installed | egrep 'curl|openssl'
>> curl @7.84.0_0+http2+ssl (active)
>> curl-ca-bundle @7.84.0_0 (active)
>> openssl @3_6 (active)
>> openssl3 @3.0.5_0+legacy (active)
>> openssl11 @1.1.1q_0 (active)
>>
>> MacPorts curl 7.84.0 uses OpenSSL 3.0.5:
>>
>> ❯ /opt/local/bin/curl

Re: fetch timeout

[Dave Allured - NOAA Affiliate via macports-dev]

Several of us have now reproduced the SSL problem.  I see two things in
common:
(1)  Older curl/SSL versions bundled into older MacOS versions, such as
Catalina.
(2)  The target website, wias-berlin.de.

I suspect wias-berlin.de is misconfigured somehow.  Mark, consider showing
this problem to them, and ask them to check their server configuration.  It
is reasonable to expect Catalina Macs to be able to download their files
using the system curl.  I can certainly download from many other websites.

Another possibility is to go back to one of Mark's earlier ideas.  Get
Macports to use the MP version of curl.  I don't know how to do this.  What
happens if you simply install and activate port curl, before install tetgen
(Mark's new port)?


On Tue, Jul 19, 2022 at 11:26 AM Mark Brethen 
wrote:

> Big Sur installs the same version curl/openssl and it does not work on
> intel. It does work on an M1, which is surprising.
>
> ~ $ /usr/bin/curl --version
> curl 7.64.1 (x86_64-apple-darwin20.0) libcurl/7.64.1 (SecureTransport)
> LibreSSL/2.8.3 zlib/1.2.11 nghttp2/1.41.0
> Release-Date: 2019-03-27
> Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3
> pop3s rtsp smb smbs smtp smtps telnet tftp
> Features: AsynchDNS GSS-API HTTP2 HTTPS-proxy IPv6 Kerberos Largefile libz
> MultiSSL NTLM NTLM_WB SPNEGO SSL UnixSockets
> ~ $
>
> I noticed nghttp2 @1.41.0 vs 1.39.2.
>
> Mark Brethen
> mark.bret...@gmail.com
>
> On Jul 19, 2022, at 12:07 PM, Gary Palter  wrote:
>
> Apparently not.
>
> Last login: Tue Jul 19 12:56:44 on console
> palter@Catalina ~ % /usr/bin/curl --version
> curl 7.64.1 (x86_64-apple-darwin19.0) libcurl/7.64.1 (SecureTransport)
> LibreSSL/2.8.3 zlib/1.2.11 nghttp2/1.39.2
> Release-Date: 2019-03-27
> Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3
> pop3s rtsp smb smbs smtp smtps telnet tftp
> Features: AsynchDNS GSS-API HTTP2 HTTPS-proxy IPv6 Kerberos Largefile libz
> MultiSSL NTLM NTLM_WB SPNEGO SSL UnixSockets
> palter@Catalina ~ % cd Downloads
> palter@Catalina Downloads % /usr/bin/curl -O
> https://wias-berlin.de/software/tetgen/1.5/src/tetgen1.5.1.tar.gz
>   % Total% Received % Xferd  Average Speed   TimeTime Time
>  Current
>  Dload  Upload   Total   SpentLeft
>  Speed
>   0 00 00 0  0  0 --:--:-- --:--:-- --:--:--
>   0
> curl: (35) error:14008410:SSL routines:CONNECT_CR_KEY_EXCH:sslv3 alert
> handshake failure
> palter@Catalina Downloads %
>
> The above is a vanilla install of Intel Catalina running in a VM.
>
>   - Gary
>
> On Jul 19, 2022, at 12:55 PM, Mark Brethen  wrote:
>
> Anyone else confirm system curl works with this host on intel mac with
> catalina or big sur?
>
> Mark
>
> On Jul 19, 2022, at 11:49 AM, Mark Brethen  wrote:
>
> Yes, I have mp curl as well. Unfortunately, port uses Apple’s
> curl/openssl. Only work around is to override fetch and use mp.
>
> Mark Brethen
> mark.bret...@gmail.com
>
> On Jul 19, 2022, at 11:42 AM, Nils Breunese  wrote:
>
> Mark Brethen  wrote:
>
> What version of curl/libressl?
>
>
>
> I have curl and openssl installed from MacPorts:
>
> ❯ port installed | egrep 'curl|openssl'
> curl @7.84.0_0+http2+ssl (active)
> curl-ca-bundle @7.84.0_0 (active)
> openssl @3_6 (active)
> openssl3 @3.0.5_0+legacy (active)
> openssl11 @1.1.1q_0 (active)
>
> MacPorts curl 7.84.0 uses OpenSSL 3.0.5:
>
> ❯ /opt/local/bin/curl --version
> curl 7.84.0 (x86_64-apple-darwin21.3.0) libcurl/7.84.0 OpenSSL/3.0.5
> zlib/1.2.12 brotli/1.0.9 zstd/1.5.2 libidn2/2.3.3 libpsl/0.21.1
> (+libidn2/2.3.2) nghttp2/1.48.0
> Release-Date: 2022-06-27
> Protocols: dict file ftp ftps gopher gophers http https imap imaps mqtt
> pop3 pop3s rtsp smb smbs smtp smtps telnet tftp
> Features: alt-svc AsynchDNS brotli HSTS HTTP2 HTTPS-proxy IDN IPv6
> Largefile libz NTLM NTLM_WB PSL SSL threadsafe TLS-SRP UnixSockets zstd
>
> macOS 12.4 curl 7.79.1 uses LibreSSL 3.3.6:
>
> ❯ /usr/bin/curl --version
> curl 7.79.1 (x86_64-apple-darwin21.0) libcurl/7.79.1 (SecureTransport)
> LibreSSL/3.3.6 zlib/1.2.11 nghttp2/1.45.1
> Release-Date: 2021-09-22
> Protocols: dict file ftp ftps gopher gophers http https imap imaps ldap
> ldaps mqtt pop3 pop3s rtsp smb smbs smtp smtps telnet tftp
> Features: alt-svc AsynchDNS GSS-API HSTS HTTP2 HTTPS-proxy IPv6 Kerberos
> Largefile libz MultiSSL NTLM NTLM_WB SPNEGO SSL UnixSockets
>
> Using macOS curl also works:
>
> ❯ /usr/bin/curl -O
> https://wias-berlin.de/software/tetgen/1.5/src/tetgen1.5.1.tar.gz
> % Total% Received % Xferd  Average Speed   TimeTime Time
>  Current
>   Dload  Upload   Total   SpentLeft  Speed
> 100  275k  100  275k0 0   758k  0 --:--:-- --:--:-- --:--:—
>  779k
>
> Nils.
>
>

Re: fetch timeout

[Dave Allured - NOAA Affiliate via macports-dev]

Here is another one.  Catalina 10.15.7.  Macports curl works normally.
System curl does not.  I am not sure whether my laptop has the latest
versions of stuff.  It is remotely managed by corporate.  Was "security
updated" within last two months, I think.

mac839:~/temp/curl/berlin/2.usr 25> \
? /usr/bin/curl -O -R -L
https://wias-berlin.de/software/tetgen/1.5/src/tetgen1.5.1.tar.gz
  % Total% Received % Xferd  Average Speed   TimeTime Time
 Current
 Dload  Upload   Total   SpentLeft
 Speed
  0 00 00 0  0  0 --:--:--  0:00:01 --:--:--
  0
curl: (35) error:14008410:SSL routines:CONNECT_CR_KEY_EXCH:sslv3 alert
handshake failure

mac839:~/temp/curl/berlin/2.usr 27>  /usr/bin/curl --version
curl 7.64.1 (x86_64-apple-darwin19.0) libcurl/7.64.1 (SecureTransport)
LibreSSL/2.8.3 zlib/1.2.11 nghttp2/1.39.2
Release-Date: 2019-03-27
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3
pop3s rtsp smb smbs smtp smtps telnet tftp
Features: AsynchDNS GSS-API HTTP2 HTTPS-proxy IPv6 Kerberos Largefile libz
MultiSSL NTLM NTLM_WB SPNEGO SSL UnixSockets


On Tue, Jul 19, 2022 at 10:55 AM Mark Brethen 
wrote:

> Anyone else confirm system curl works with this host on intel mac with
> catalina or big sur?
>
> Mark
>
>
> > On Jul 19, 2022, at 11:49 AM, Mark Brethen 
> wrote:
> >
> > Yes, I have mp curl as well. Unfortunately, port uses Apple’s
> curl/openssl. Only work around is to override fetch and use mp.
> >
> > Mark Brethen
> > mark.bret...@gmail.com
> >
> >
> >> On Jul 19, 2022, at 11:42 AM, Nils Breunese  wrote:
> >>
> >> Mark Brethen  wrote:
> >>
> >>> What version of curl/libressl?
> >>
> >>
> >> I have curl and openssl installed from MacPorts:
> >>
> >> ❯ port installed | egrep 'curl|openssl'
> >> curl @7.84.0_0+http2+ssl (active)
> >> curl-ca-bundle @7.84.0_0 (active)
> >> openssl @3_6 (active)
> >> openssl3 @3.0.5_0+legacy (active)
> >> openssl11 @1.1.1q_0 (active)
> >>
> >> MacPorts curl 7.84.0 uses OpenSSL 3.0.5:
> >>
> >> ❯ /opt/local/bin/curl --version
> >> curl 7.84.0 (x86_64-apple-darwin21.3.0) libcurl/7.84.0 OpenSSL/3.0.5
> zlib/1.2.12 brotli/1.0.9 zstd/1.5.2 libidn2/2.3.3 libpsl/0.21.1
> (+libidn2/2.3.2) nghttp2/1.48.0
> >> Release-Date: 2022-06-27
> >> Protocols: dict file ftp ftps gopher gophers http https imap imaps mqtt
> pop3 pop3s rtsp smb smbs smtp smtps telnet tftp
> >> Features: alt-svc AsynchDNS brotli HSTS HTTP2 HTTPS-proxy IDN IPv6
> Largefile libz NTLM NTLM_WB PSL SSL threadsafe TLS-SRP UnixSockets zstd
> >>
> >> macOS 12.4 curl 7.79.1 uses LibreSSL 3.3.6:
> >>
> >> ❯ /usr/bin/curl --version
> >> curl 7.79.1 (x86_64-apple-darwin21.0) libcurl/7.79.1 (SecureTransport)
> LibreSSL/3.3.6 zlib/1.2.11 nghttp2/1.45.1
> >> Release-Date: 2021-09-22
> >> Protocols: dict file ftp ftps gopher gophers http https imap imaps ldap
> ldaps mqtt pop3 pop3s rtsp smb smbs smtp smtps telnet tftp
> >> Features: alt-svc AsynchDNS GSS-API HSTS HTTP2 HTTPS-proxy IPv6
> Kerberos Largefile libz MultiSSL NTLM NTLM_WB SPNEGO SSL UnixSockets
> >>
> >> Using macOS curl also works:
> >>
> >> ❯ /usr/bin/curl -O
> https://wias-berlin.de/software/tetgen/1.5/src/tetgen1.5.1.tar.gz
> >> % Total% Received % Xferd  Average Speed   TimeTime Time
> Current
> >>Dload  Upload   Total   SpentLeft
> Speed
> >> 100  275k  100  275k0 0   758k  0 --:--:-- --:--:--
> --:--:—  779k
> >>
> >> Nils.
>

Re: compilers PortGroup

[Dave Allured - NOAA Affiliate via macports-dev]

Mark, those are specifically fortran issues, not C.  Both of those warnings
refer to fortran constructs which were declared obsolescent in fortran 90.
That is a long time ago.  However, it looks like your modern gfortran
version is still compiling these constructs correctly, but issuing compile
time warnings.  This is most appropriate.  If possible, test functionality
to ensure that part about "compiling correctly" is not a lie.

I suggest best practice is to /not/ cover up these warnings with some -std
option or other sort of patch.  If the build works, then leave the warnings
in place for future benefit.  For best results, request an upstream fix to
replace these deleted constructs with more modern constructs, or submit
your own upstream fix.  Both fixes are straightforward fortran.


On Tue, Jul 5, 2022 at 9:22 PM Mark Brethen  wrote:

> I have the compiler.setup so that gfortran is selected by default, however
> checking the build log I’m seeing these warning messages:
>
> Warning: Fortran 2018 deleted feature: DO termination statement which is
> not END DO or CONTINUE with label 215 at (1)
>
> Warning: Fortran 2018 deleted feature: Arithmetic IF statement at (1)
>
> Those messages are only warnings. But to side-step these issues, do I need
> to add the -std option to specify which version of the fortran standard to
> use when compiling?
>
> E.g. compiler.c_standard   2008
>
> Thanks
> Mark
>
>
> > On Jul 4, 2022, at 9:36 AM, Mark Brethen  wrote:
> >
> > Sorry for the confusion, 'sudo port build xyx'.
> >
> > Mark Brethen
> > mark.bret...@gmail.com
> >
> >
> >> On Jul 4, 2022, at 9:07 AM, Joshua Root  wrote:
> >>
> >> On 2022-7-4 23:24 , Mark Brethen wrote:
> >>> Here’s what I’ve observed:
> >>> compilers.choose fc cc
> >>> compiler.setup  require_fortran -g95 -clang
> >>> If I issue sudo port xyz +gcc11, I get ${configure.cc} =
> /usr/bin/clang.
> >>
> >> What is xyz? When are you reading the variable? If it's before the
> variants execute, you won't see the changes they make.
> >>
> >> - Josh
>

Creating account for Trac

[Dave Allured - NOAA Affiliate via macports-dev]

Hello Devs.  I was asked to help a user who is unable to post on Macports
Trac.

* There should be instructions for setting up a Trac account in plain
sight.  I can not find it.  Where is it?  If there is none, I would be
willing to write one.

* Is it possible to get a Trac account without a Github account?  How?

Thanks for your help with this.

Re: Policy on `obsolete` ports...

[Dave Allured - NOAA Affiliate via macports-dev]

Perry, you said "remove".  I would like to have obsolete ports moved to an
inactive permanent reference archive, preferably somewhere in the ports
code base, rather than permanently removed.  This would mainly be for
possible resurrection at any time in the future.

I think your proposed rules are fine, except for the premise in #3.  You
might never know how far out someone might find a reason to resurrect some
old crufty thing.  I would say that a year is sufficient to move something
from obsolete to graveyard.


On Fri, Nov 19, 2021 at 2:05 PM Perry E. Metzger  wrote:

> Howdy! As things stand, we don't explicitly say much in our rules about
> whether people can remove obsolete ports after a year even without a
> port maintainer's say-so. We also have circumstances where people leave
> "maintainer" lines in ports that have been put into `obsolete`.
>
> I'd like to propose the following rules:
>
> 1. There must always be a comment in a `PortGroup obsolete` Portfile
> stating the date on which the port can be removed. (Ideally we'd
> actually have a keyword for this so tools could find it, but a comment
> works for now.) In case there isn't a comment, the date of the commit is
> used.
>
> 2. Once something is `Portgroup obsolete`, it should no longer be
> considered to have a maintainer. After all, there's no longer anything
> being built or maintained. Thus, `maintainer` should be set to
> `nomaintainer` for such files. If there's still a `maintainer` in an
> `obsolete` port, that is an accident and can be ignored for purposes of
> removing the port at the end of the one year timeout.
>
> 3. Setting a port `obsolete` should be considered automatic consent to
> remove it in one year's time, and there should be no question that a
> year is a sufficient chance to think better of it and bring it back in
> some form.
>
> 4. If a subport is set `obsolete`, the usual rules about the maintainer
> needing to consent to touching the Portfile should not apply for
> removing said subport in a year, as the one year is (again) enough time
> for them to think better on it.
>
> Do people think these suggested rules are okay? Are there any objections?
>
> Perry
>

Re: 2.7.1

[Dave Allured - NOAA Affiliate via macports-dev]

A bugfix release is good, but I object on principle to release by Github
tag only.  At minimum, create clean standard artifacts, .tar.bz2 and
.tar.gz, and put them in
https://github.com/macports/macports-base/releases/download/v2.7.1 for
permanent reference.  Thank you.


On Tue, May 25, 2021 at 5:29 AM Joshua Root  wrote:

> Any objection to tagging the current state of the release-2.7 branch as
> 2.7.1?
>
> - Josh
>

Re: Publicizing MacPorts

[Dave Allured - NOAA Affiliate via macports-dev]

It would be very helpful for new impressions of Macports, if the ports
website could be fixed to properly show current port status.  This problem
has been lingering for months now:

https://github.com/macports/macports-webapp/issues/273


On Mon, Apr 19, 2021 at 9:59 AM Dave Allured - NOAA Affiliate <
dave.allu...@noaa.gov> wrote:

> Here are a few ideas.  How many M1 ports are working on Macports?  How
> many on Homebrew and other competitors?
>
> How long ago did Macports start to have working M1 ports?
>
> Are there any noteworthy M1 ports that are working on Macports, but not on
> Homebrew?
>
>
> On Mon, Apr 19, 2021 at 8:47 AM Rainer Müller  wrote:
>
>>
>> So, if MacPorts were to make an announcement now, what would you put in
>> there?
>> Can you show us a draft? "MacPorts works like it always has" is barely
>> newsworthy.
>>
>

Re: Publicizing MacPorts

[Dave Allured - NOAA Affiliate via macports-dev]

Here are a few ideas.  How many M1 ports are working on Macports?  How many
on Homebrew and other competitors?

How long ago did Macports start to have working M1 ports?

Are there any noteworthy M1 ports that are working on Macports, but not on
Homebrew?


On Mon, Apr 19, 2021 at 8:47 AM Rainer Müller  wrote:

>
> So, if MacPorts were to make an announcement now, what would you put in
> there?
> Can you show us a draft? "MacPorts works like it always has" is barely
> newsworthy.
>

Re: Port stats page not updated since 20th Feb

[Dave Allured - NOAA Affiliate via macports-dev]

Yes, this is what Ryan was telling me about yesterday.  "The ports web site
is not currently importing new build information."  Please see:

https://trac.macports.org/ticket/62401
and https://lists.macports.org/pipermail/macports-dev/2021-March/043055.html
near the bottom.


On Wed, Mar 10, 2021 at 7:04 PM Chris Jones 
wrote:

> Hi all,
>
> Just looking at
>
> https://ports.macports.org/ports/all_builds/
>
> It seems like the stats have not been updated in a short while, the last
> builds are from 20th Feb ?
>
> cheers Chris
>

Re: How to trigger port rebuild for arm64

[Dave Allured - NOAA Affiliate via macports-dev]

On Tue, Mar 9, 2021 at 9:22 PM Ryan Schmidt  wrote:

>
> On Mar 9, 2021, at 22:06, Dave Allured wrote:
>
> > While the ports website is not updating, is there an easy way for me to
> access build logs for new builds that fail for specific ports?  It's not
> critical but would help me stay on track.
>
> Nope. If the build happened within the past day or so, and especially if
> you're looking for a build on a specific builder, it can be not too tedious
> to go page by page through the buildbot waterfall until you find it. For
> example, if you're looking for macOS 11 arm64 builds you can look through
> this:
>
> https://build.macports.org/waterfall?builder=ports-11_arm64-builder
>
> Use your web browser's find function to search for the port name within
> that page. If it's not found, click the "next page" link at the bottom left
> of the page and repeat. This is basically what we had to do to find build
> information before the ports web site existed and is one of the reasons why
> the ports web site was created.
>

 Rather limited, but I can work with it.  Thanks.

Re: How to trigger port rebuild for arm64

[Dave Allured - NOAA Affiliate via macports-dev]

On Tue, Mar 9, 2021 at 4:12 PM Ryan Schmidt  wrote:

>
> On Mar 9, 2021, at 13:02, Dave Allured wrote:
>
> > I work very occasionally on port fixes for arm64.  I tried to trigger
> rebuilds of dependent ports on the arm64 buildbot, using simple revbumps.
> For example, port geos was updated and built successfully on Feb. 15.  I
> then submitted a revbump for dependent port spatialite, merged to MP master
> on March 5:
> > https://github.com/macports/macports-ports/pull/10040
> >
> > However, it seems that the expected arm64 rebuild was never triggered,
> and spatialite continues to show arm64 failure.  In particular note that
> the last build predates the revbump:
> > https://ports.macports.org/port/spatialite/builds
> >
> > The arm64 buildbot was "idle" this morning, if I am reading correctly.
> So what is the right way for me to get an arm64 rebuild started?  Should I
> start blindly rev bumping until I get what I want?   ;-)   Am I missing
> something?  Thanks for any advice.
>
> You should never revbump a port just to get the buildbot to build
> something. *Any* change made to a port will trigger a buildbot build if one
> is necessary.
>
> If you are a MacPorts developer with commit access, you can log in to the
> buildbot to force builds of any ports that for whatever reason did not get
> built normally (for example if there was build server downtime and I
> somehow neglected to schedule builds for those ports that were modified
> during the downtime). If a MacPorts developer with commit access does not
> have a buildbot login, they can ask me and I can make one.
>
> Note that the ports web site is not currently importing new build
> information due to a problem [1]. If you'd like to be notified when the
> problem is resolved you can Cc yourself on that ticket.
>
> According to https://packages.macports.org/spatialite/ geos @5.0.1_1 was
> built for all platforms (except 10.15 [2]) on March 6/7 including arm64.
>
> [1] https://trac.macports.org/ticket/62401
>
> [2] https://trac.macports.org/ticket/62257


Thank you.  #62401 explains everything I thought was wrong.  I did not know
that the ports website was not updating, or that there was another way to
look for successful builds.

While the ports website is not updating, is there an easy way for me to
access build logs for new builds that fail for specific ports?  It's not
critical but would help me stay on track.

How to trigger port rebuild for arm64

[Dave Allured - NOAA Affiliate via macports-dev]

I work very occasionally on port fixes for arm64.  I tried to trigger
rebuilds of dependent ports on the arm64 buildbot, using simple revbumps.
For example, port geos was updated and built successfully on Feb. 15.  I
then submitted a revbump for dependent port spatialite, merged to MP master
on March 5:
https://github.com/macports/macports-ports/pull/10040

However, it seems that the expected arm64 rebuild was never triggered, and
spatialite continues to show arm64 failure.  In particular note that the
last build predates the revbump:
https://ports.macports.org/port/spatialite/builds

The arm64 buildbot was "idle" this morning, if I am reading correctly.  So
what is the right way for me to get an arm64 rebuild started?  Should I
start blindly rev bumping until I get what I want?   ;-)   Am I missing
something?  Thanks for any advice.

Re: Split geos port for C and C++ API's

[Dave Allured - NOAA Affiliate via macports-dev]

Um, cancel this, it is probably not needed.  Public use of the geos C++ API
is strongly discouraged by the source.  A quick scan on my local system
finds no ports that are actually using the C++ API, except indirectly
through the C API.


On Sun, Feb 21, 2021 at 1:42 PM Dave Allured - NOAA Affiliate <
dave.allu...@noaa.gov> wrote:

> I would like to split the geos port in two, for C and C++ API's. The
> purpose is to improve dependency management for the 41 dependents
> (currently).  In particular I want to reduce the need for many gratuitous
> rev bumps on every minor release.
>
> Upstream GEOS says the C ABI is long-term stable, but the C++ ABI changes
> rapidly.  They recommend using the more stable C API when possible.  They
> provides separate header files and binary libraries for C and C++.
> However, both API's are combined in the single geos package build.  The C
> ABI is presented as wrapped around the C++ ABI.
>
> As a macports novice, I seek advice on the best way to do this.  This
> seems good:
>
> * *geos_cpp*:  Rename the original port to this.  Dependent ports that
> actually use the C++ API would be phased into this dependency.  Internally,
> this port would build both C and C++ ABI's, so the original geos build
> system would be used the same way that it is now.
> * *geos*:  For dependents that use only the C API.  This would become a
> wrapper port that would depend on geos_cpp, but would not actually build
> any code.
>
> I could also imagine *geos* (for C++) and *geos_c* (for C) ports.  Any
> thoughts?
>

Split geos port for C and C++ API's

[Dave Allured - NOAA Affiliate via macports-dev]

I would like to split the geos port in two, for C and C++ API's. The
purpose is to improve dependency management for the 41 dependents
(currently).  In particular I want to reduce the need for many gratuitous
rev bumps on every minor release.

Upstream GEOS says the C ABI is long-term stable, but the C++ ABI changes
rapidly.  They recommend using the more stable C API when possible.  They
provides separate header files and binary libraries for C and C++.
However, both API's are combined in the single geos package build.  The C
ABI is presented as wrapped around the C++ ABI.

As a macports novice, I seek advice on the best way to do this.  This seems
good:

* *geos_cpp*:  Rename the original port to this.  Dependent ports that
actually use the C++ API would be phased into this dependency.  Internally,
this port would build both C and C++ ABI's, so the original geos build
system would be used the same way that it is now.
* *geos*:  For dependents that use only the C API.  This would become a
wrapper port that would depend on geos_cpp, but would not actually build
any code.

I could also imagine *geos* (for C++) and *geos_c* (for C) ports.  Any
thoughts?