Re: The future of the Golang Portgroup — what to do with offline builds?

[Nils Breunese]

Hi,

I think this issue is broader than the Go ecosystem, because this goes for any 
software that uses a build tool that downloads dependencies at build time, like 
for instance Gradle and Apache Maven in the Java ecosystem, and NPM and Yarn in 
the JavaScript world. Either the build tool needs to have a way to provide 
dependencies offline, so it doesn’t fetch these dependencies at build time, and 
then the port maintainer needs to make sure the correct offline dependencies 
are provided, or we need to accept that a port uses the build tool’s dependency 
resolution and fetching method.

Allowing ports to download dependencies at build time carries the risk of those 
dependencies not being available at build time, which I guess is why MacPorts 
is not a fan of this method. In a corporate setting this is typically mitigated 
by using an in-house repository manager (e.g. Artifactory or Nexus), which 
caches these dependency artifacts. This is kind of similar to MacPorts servers 
storing files, but a repository manager provides interfaces that can be 
directly used by build tools to fetch dependencies, so if we’d have a MacPorts 
repository manager a port developer (or even better: port group) could 
configure a Maven/Gradle/NPM/Yarn/whatever port to use the MacPorts repository 
manager, and then port build should no longer depend on publicly available 
dependencies after the initial build.

It could be interesting to set up a repository manager for MacPorts to 
facilitate software that is built using build tools that download dependencies 
at build time, which I believe is getting more and more common in various 
programming ecosystems. (I’m a software developer in the Java ecosystem myself, 
and I’ve never used a build tool that doesn’t do this in the past 20 years or 
so.) But of course we’d need to have the resources (hardware and people) to set 
up and maintain a repository manager.

Nils.

> Op 15 feb 2024, om 04:27 heeft Austin Ziegler  het 
> volgende geschreven:
> 
> I’ve been playing with a couple of Go ports recently and trying to get 
> various pieces to work with offline builds…and I’m not convinced that offline 
> builds as they are currently executed are a good thing. In extreme cases, I 
> think that the use of go.vendors is an antipattern.
> 
> As an example, I was looking at devel/please and used go2port, found a number 
> of issues, and then applied a patch to my local golang Portgroup (all 
> instances of them from all sources) based on [1]. Even that didn't work for 
> everything, but I kept trying it…until I realized that I was downloading ten 
> different versions of the same repository at ~35Mb *each* in order to build 
> something. A build that takes about five minutes from `git clone…` to the end 
> of `./bootstrap.sh` (devel/please is a bit strange) took more than 30 minutes 
> just to download vendored dependencies  (many of them duplicated, remember).
> 
> The sysutils/go2port tool is amazing, but does not pull the dependencies down 
> the way that go mod does, cannot find some dependencies because of the 
> resolutions, and the portgroup's go.vendors support is restricted to using 
> full repo archive downloads instead of the somewhat smarter apparently 
> git-based solution that go mod is using where only the required subpaths are 
> pulled.
> 
> I don't have a solution to this other than to suggest that offline builds and 
> go.vendors be deprecated (it's also only using the legacy archive retrieval), 
> unless we come up with another way to do this.
> 
> There might be a way to do it using `go mod vendor`, but that leaves a 
> different problem of how / where the vendored dependencies will be stored 
> because the upstream is not vendoring, we would be. If we had a way to take 
> `vendor/modules.txt` (after go mod vendor) and telling one of the build 
> machines to build vendored archives of the versioned items in the tree, we 
> could perhaps download those, but as far as I know there is no way to *force* 
> that particular mechanism as the archive is not coming from a source, but 
> would be made during the initial buildbot build (until all the archived items 
> are in place, `go mod vendor` would need to be run locally).
> 
> -a
> 
> [1] https://marc.info/?l=macports-dev=170710631300800=2
> --
> Austin Ziegler • halosta...@gmail.com  • 
> aus...@halostatue.ca 
> http://www.halostatue.ca/ • http://twitter.com/halostatue

Re: Antlr: Rebuild on 12.x86_64

[Nils Breunese]

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

Re: GEDA site dead?

[Nils Breunese]

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
> ___
> Mark E. Anderson 
> MacPorts Trac WikiPage
> GitHub Profile

Updating openjdk8 to 8u392

[Nils Breunese]

Hello,

The openjdk8 port in MacPorts is currently at 8u372, but two updates with 
security fixes have been released since then: 8u382 in July and 8u392 this 
month. I don’t maintain the openjdk8 port myself, but I’ve tried bumping the 
version, because this port is specified as the java.fallback depedency for a 
number of ports, but sadly without success. I think the patches that MacPorts 
tries to apply are no longer valid, but I don’t have an Intel machine and I 
don’t know how to make the ARM patch work.

I’ve created Trac issues for updating openjdk8 in which I’ve documented the 
errors I got, but the oldest has already been open for over 3 months:

* 8u382: https://trac.macports.org/ticket/67804
* 8u392: https://trac.macports.org/ticket/68498

Can anyone update openjdk8 to 8u392?

I have updated the openjdk8-zulu and openjdk-corretto ports, which installed 
pre-built binaries from Azul and Amazon respectively, but it would be nice if 
our main built-from-source openjdk8 port was also up-to-date with all security 
fixes.

Nils.

Re: { darwin any } ports getting reinstalled after OS upgrade

[Nils Breunese]

Joshua Root  wrote:

> On 27/9/2023 23:01, Nils Breunese wrote:
> 
>> You can do this:
>>  platforms { darwin any } { darwin >= 11 }
>> Which means that the port will install on Darwin 11+, and it will install 
>> identically on all of those supported versions.
> 
> Or the simpler form
> 
> platforms {darwin any >= 11}

I do agree that the syntax is a bit confusing. I’m not sure that allowing 
‘platforms { darwin any >= 11}’ would make it less confusing though, because at 
first sight it looks like it might be the same as ‘platforms { darwin >= 11 }’, 
which it wouldn’t be. What OS versions are supported and whether a port 
installs identically on all supported OS versions should actually maybe be 
distinguished more explicitly, instead of getting mixed more closely?

Nils.

Re: { darwin any } ports getting reinstalled after OS upgrade

[Nils Breunese]

Ryan Schmidt  wrote:

> On Sep 27, 2023, at 05:57, Nils Breunese wrote:
>> 
>> I noticed that ports that use ‘platform { darwin any }’ get reinstalled 
>> during this process, and ‘port outdated’ shows ‘(platform darwin 22 ≠ 23)’. 
>> Does MacPorts really need to reinstall these ports if they’re marked as 
>> being suitable for any Darwin version?
> 
> I agree, MacPorts should not need to reinstall those ports, but there is 
> evidently no code at present to let it know that. You could file an 
> enhancement ticket in Trac.

Alright, I’ve created https://trac.macports.org/ticket/68256

Nils.

Re: { darwin any } ports getting reinstalled after OS upgrade

[Nils Breunese]

Christopher Jones  wrote:

> I had no idea we supported single tarballs for multiple OS versions. 
> 
> I must say, the distinction between
> 
> platforms { darwin any }
> 
> and
> 
> platforms {darwin >= 11}
> 
> which *does* result in specific tarballs for each OS is a bit too subtle for 
> my tastes. I presume it’s the present of ‘any’ which is important here ?

You can do this:

platforms { darwin any } { darwin >= 11 }

Which means that the port will install on Darwin 11+, and it will install 
identically on all of those supported versions.

Nils.

Re: { darwin any } ports getting reinstalled after OS upgrade

[Nils Breunese]

Ryan Schmidt  wrote:

> On Sep 27, 2023, at 06:09, Christopher Jones wrote:
> 
>> b.t.w. When upgrading to a new major OS version, you anyway should follow 
>> the migration instructions, which involves manually removing all ports 
>> anyway.
> 
> We do recommend that, but the piecemeal method Nils is using is also viable.

I’ve used this simpler method (upgrade OS, install MacPorts for new OS, upgrade 
all ports) since forever and so far it’s always worked fine for me.

Nils.

{ darwin any } ports getting reinstalled after OS upgrade

[Nils Breunese]

Hi,

I’ve updated to macOS 14, installed MacPorts 2.8.1 for Sonoma and then upgraded 
my ports. I noticed that ports that use ‘platform { darwin any }’ get 
reinstalled during this process, and ‘port outdated’ shows ‘(platform darwin 22 
≠ 23)’. Does MacPorts really need to reinstall these ports if they’re marked as 
being suitable for any Darwin version?

Nils.

Re: Portfile for osxphotos

[Nils Breunese]

Kirill A. Korinsky  het volgende geschreven:

> I've used osxphotos once or twice and willing to make a port file and take 
> care of it.
> 
> PR will be made tonight.

Ah, that would be great. Thanks, Kirill! I’ll keep an eye out for it.

Nils.

Re: Portfile for osxphotos

[Nils Breunese]

Joshua Root  wrote:

> On 7/9/2023 16:03, Nils Breunese wrote:
>> Does someone here think MacPorts could install osxphotos without using an 
>> intermediary package manager like pipx? 
> 
> Yes, it looks like it's a standard setuptools build system, so the python 
> portgroup should handle it fine.

I’m also not familiar with setuptools, but this sounds promising.

> The bigger job might be adding ports for any dependencies that we don't 
> currently have. I do see a lot of version pinning in the dependency list, 
> which is something we don't support well, but it's also often unneeded.

Hm ok, I can’t judge that in this case.

> That said, it might be worth taking a moment to consider what value 
> installation via MacPorts adds, compared to creating a venv and installing 
> osxphotos into it with pip. Typically we add python modules to MacPorts 
> because either something else in MacPorts needs them, or they have 
> dependencies that pip can't install.

For me the value would be not having to learn about or deal with tools like 
venv and pip (and npm and etc., etc.), but managing my system using just 
MacPorts.

>> If someone would be willing to create an initial Portfile for osxphotos I 
>> wouldn’t mind volunteering to keep it up to date. Let me know if you’d like 
>> to help out with getting this going.
> 
> Here's an incomplete and untested first pass at one, based on a template from 
> the portfile-gen script: 
> <https://gist.github.com/jmroot/199e3a9348226979350e4be7d20ae865>

Cool, thanks for looking into this.

Nils.

Portfile for osxphotos

[Nils Breunese]

Hello,

I recently wanted to export some photos from Apple’s Photos application and 
import them on my partner’s Mac, without losing any metadata, keeping Live 
Photos as-is (not just a JOG), etc. I found osxphotos [0] to be a great tool 
for this (and it can do much more!).

The osxphotos installation instructions [1] recommend installing pipx via 
Homebrew, and then using pipx to install osxphotos. Alternative recommendations 
are using pip instead of pipx, or installing from source.

I could use MacPorts instead of Homebrew to install pipx, but I prefer to avoid 
installing software via language-specific package managers, because I don’t 
want to have to deal with all those individual package managers (pip, pipx, 
npm, etc.), separately from MacPorts.

The osxphotos author is a MacPorts user too, but isn’t familiar with creating 
Portfiles and currently doesn’t have time to learn how to set this up [2].

Sadly I am not familiar enough with the Python world to know how to create a 
Portfile for osxphotos. Does someone here think MacPorts could install 
osxphotos without using an intermediary package manager like pipx? If someone 
would be willing to create an initial Portfile for osxphotos I wouldn’t mind 
volunteering to keep it up to date. Let me know if you’d like to help out with 
getting this going.

Nils.

[0] https://github.com/RhetTbull/osxphotos
[1] https://github.com/RhetTbull/osxphotos#installation
[2] https://github.com/RhetTbull/osxphotos/issues/1199#issuecomment-1709435930

Re: iTerm2

[Nils Breunese]

Hi Mark,I maintain the ports that install binary builds of OpenJDK Java distributions. You can take a look at the openjdk*-zulu ports for instance.Nils.Op 22 jun. 2023 om 17:06 heeft Mark Anderson  het volgende geschreven:iTerm2 is getting increasingly hard to support building using macports to where I'm not even using the build - I've just been trying to fix it. The big issue is that building it on the latest box with the latest Xcode works great, but the developer rightly assumes that they can just send that binary out to everyone and if you can't build it, well, download the binary.So I'm wondering what exactly to do. We could download the binary for all but the latest Xcodes/Macs or if you force it with a source build flag? I think that might be the answer.I'm open to any suggestions or input. Also, I'm not sure how to do binary installs, are there examples? Java comes to mind for some reason.—Mark___Mark E. Anderson MacPorts Trac WikiPageGitHub Profile

Re: Clean up PROJ mess

[Nils Breunese]

You could already create a proj9 port now and have proj depend on that. When 
version comes out you can add proj10 and change proj to depend on that instead 
of proj9. This way users can choose to install ‘proj latest’ or ‘proj 9’ 
explicitly, with the former getting updated as newer versions are released, and 
the latter just giving a user version 9.

Nils.

> Op 8 jun. 2023 om 21:54 heeft Nicklas Larsson via macports-dev 
>  het volgende geschreven:
> 
> 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 port:proj7
> science/sumoport:proj4
> science/vapor   port:proj4
> science/wgrib2  port:proj8
> science/xastir  port:proj4
> 
> 
> 
> What do you think, could this be a good way to go forward?
> Suggestions, opinions?
> 
> 
> Best regards,
> Nicklas
> 

Re: Java portgroup default fallback?

[Nils Breunese]

Joshua Root  wrote:

> On 24/2/2023 11:44, Nils Breunese wrote:
>> Latest LTS (currently openjdk17) could be reasonable, but ideally the 
>> fallback version should be verified to work. If that implicitly happens on 
>> CI, because there is never a pre-existing Java installation there, then I 
>> guess that’s could be ok, although I personally think it’s good to have 
>> explicitly set fallback versions.
> 
> Yes, it would need to be a dynamic default, taking into account the OS 
> version, build_arch, and java.version in order to pick a JDK port that will 
> work.

A specific fallback port provides a specific Java feature version. A Java 
fallback port should indeed support all archs supported by the port that is 
getting installed, but most of them support both x86_64 and arm64. But if 
necessary java.fallback could be set conditionally based on anything.

> I don't understand why having individual ports set their own fallback version 
> would be considered better in general, since it doesn't actually guarantee 
> that a specific JDK will be present. The portgroup's behaviour is to use any 
> installed JDK that meets the requirement given in java.version. Ports that 
> need a specific JDK need to explicitly declare a dependency on it either way.

If no Java version that meets the java.version requirement is present, then the 
java.fallback port will be installed. When that happens I think it should be a 
Java port that actually works for the port, not some default that ‘hopefully 
works’, so that is why I’m in favor of port maintainers setting a fallback Java 
port explicitly.

Nils.

Re: Java portgroup default fallback?

[Nils Breunese]

The built-from-source openjdk11 and openjdk17 ports have arm64 support. The 
openjdk8 port doesn’t though. If you want Java 8 on arm64, you can install 
openjdk8-zulu (Azul Zulu OpenJDK) or openjdk8-corretto (Amazon Corretto).

Nils.

> Op 23 feb. 2023, om 22:22 heeft Kirill A. Korinsky via macports-dev 
>  het volgende geschreven:
> 
> Keep in mind that for M1 you probably need zulu JVM.
> 
> -- 
> wbr, Kirill
> 
>> On 23. Feb 2023, at 21:48, Joshua Root  wrote:
>> 
>> Does anyone know why there is no default value for java.fallback? The 
>> assumption appears to be that if a port is using this portgroup, it requires 
>> Java, since it errors out in pre-fetch if no Java is found. So it seems like 
>> having no fallback by default is just causing builds to fail unnecessarily.
>> 
>> If a default fallback is appropriate, what should it be? My initial 
>> impression is that the latest LTS openjdk that works on the current OS would 
>> be reasonable.
>> 
>> - Josh
> 

Re: Java portgroup default fallback?

[Nils Breunese]

Latest LTS (currently openjdk17) could be reasonable, but ideally the fallback 
version should be verified to work. If that implicitly happens on CI, because 
there is never a pre-existing Java installation there, then I guess that’s 
could be ok, although I personally think it’s good to have explicitly set 
fallback versions.

By the way, I don’t know if MacPorts’ built-from-source openjdk* ports are 
still actively maintained. I’ve bumped patch updates for the built-from-source 
ports, because I noticed they were not current, but I lack the knowledge to 
really maintain those. Therefor I wonder there will be an openjdk21 port after 
the release in September. There also haven’t been openjdk18 or openjdk19 ports 
in MacPorts so far.

Please note that I do maintain the other prebuilt Java distributions (Azul Zulu 
OpenJDK, Eclipse Temurin, Oracle OpenJDK, etc.) in MacPorts, and for instance 
Java 19 is available via those.

Nils.

> Op 23 feb. 2023, om 21:48 heeft Joshua Root  het volgende 
> geschreven:
> 
> Does anyone know why there is no default value for java.fallback? The 
> assumption appears to be that if a port is using this portgroup, it requires 
> Java, since it errors out in pre-fetch if no Java is found. So it seems like 
> having no fallback by default is just causing builds to fail unnecessarily.
> 
> If a default fallback is appropriate, what should it be? My initial 
> impression is that the latest LTS openjdk that works on the current OS would 
> be reasonable.
> 
> - Josh

Re: Dev guide updated for github/easy instructions?

[Nils Breunese]

Does https://guide.macports.org/chunked/project.github.html help?

Nils.

P.S. I believe macports-...@lists.macosforge.org is the old address of this 
mailing list, macports-dev@lists.macports.org is the new one.

> Op 12 dec. 2022, om 16:35 heeft Watson Ladd  het 
> volgende geschreven:
> 
> This morning I realized that Pari is lagging behind, so went ahead to
> start contributing a version bump. Unfortunately i completely forgot
> the song and dance to make Macports process the portfile I produced,
> and then the documentation was very pre-github migration (assumes
> individual port files vs checking out the repo).
> 
> Perhaps we should have a development guide update, and in the meantime
> do i just update the sources to include my local checkout? I could
> have sworn I've done this before, but just forgot how.
> 
> Sincerely,
> Watson
> 
> -- 
> Astra mortemque praestare gradatim

Re: Re possibility of ports that install pre-built apps (allowed for free distribution)

[Nils Breunese]

I personally like to install software via my package manager (MacPorts) as much 
as I can. This makes bootstrapping a new machine easy, as well as keeping 
everything up to date. Therefore in principle I’d like all software I need to 
be installable via my package manager. It just makes admin life easier, and I’d 
like to avoid having to use multiple package managers to maintain the software 
on my Mac.

However, on https://www.macports.org/ MacPorts doesn’t present itself as a 
generic package manager, but as “an easy to use system for compiling, 
installing, and upgrading either command-line, X11 or Aqua based open-source 
software on the Mac operating system”. So, maybe MacPorts isn’t a generic 
package manager that lets me manage any software on my Mac. But in practice 
MacPorts has deviated from this description. There are ports that install 
prebuilt binaries, and I believe some people even use it on non-Mac machines.

By the way, you do get into a weird situation when an app has its own update 
mechanism, because then how is a package manager going to stay in control? I 
think this might be an issue with OnyX? For this reason most GUI apps I use — 
even when they’re open source, like Firefox — are not managed via MacPorts on 
my machine.

Nils.

> Op 23 nov. 2022 om 04:50 heeft Sergey Fedorov  het 
> volgende geschreven:
> 
> 
> Hi everyone, I have recently made a port that installs OnyX for every system 
> from Tiger onwards:
> https://github.com/macports/macports-ports/pull/16710
> 
> Turned out, there is some ambiguity regarding such kind of ports. I don’t 
> particularly get why such ports cannot be allowed, provided building from 
> source is not an option and provided developers allow distributing freely 
> (which is the case for OnyX, see: 
> https://www.titanium-software.fr/en/index.html).
> As a matter of fact, MacPorts does have ports that install pre-built 
> binaries, either as a variant or as the only option.
> 
> It is perhaps indeed unneeded to have gazillions of ports of such a kind; 
> however, as for OnyX goes, it is a useful and widely used app, supporting 
> every version of macOS. How does it hurt to have it?
> 
> Best regards,
> Sergey Fedorov
> GitHub: @barracuda156

Re: Using platforms in 2.8.0

[Nils Breunese]

Joshua Root  wrote:

> On 2022-11-1 13:31 , Nils Breunese wrote:
>> Joshua Root  wrote:
>>> On 2022-11-1 11:45 , Nils Breunese wrote:
>>> 
>>>> So when a port installs one pre-built binary on x86_64 and another on 
>>>> arm64, regardless of OS version, setting 'platforms {darwin any}’ would be 
>>>> appropriate and correct?
>>> 
>>> Sure. Unless the x86_64 binary was built targeting 10.5 though, you 
>>> probably also need to restrict the versions. E.g. if the binary works on 
>>> 10.12 and later:
>>> 
>>> platforms {darwin any} {darwin >= 16}
>> Should that be ‘platforms {darwin >= 16}’? If not, I don’t really understand 
>> the syntax above yet.
> 
> The {darwin any} is what makes a single binary archive shared between all OS 
> versions possible. Without it, separate archives for darwin_16, darwin_17, 
> and so on would be built.
> 
> Being able to say {darwin any >= 16} might be clearer, but unfortunately that 
> isn't accepted currently.

The fact that ‘any’ is not about which versions are supported, but about the 
fact that the resulting archive is identical for all supported versions was 
confusing me when reading that syntax, but I got it now. I also didn’t get from 
the documentation yet that '{darwin any}' and a version range check like 
'{darwin >= 16}' could be combined like that, but that’s good to know.

Thanks, Nils.

Re: Using platforms in 2.8.0

[Nils Breunese]

Joshua Root  wrote:

> On 2022-11-1 11:40 , Nils Breunese wrote:
>> Joshua Root  wrote:
>>> On 2022-10-22 21:56 , Kirill A. Korinsky wrote:
>>>> I'm asking is there a way to support specified arch inside platform 
>>>> block's condition. Like:
>>>> platform {aarch64}  {
>>>> ...
>>>> }
>>> 
>>> You can certainly do things like:
>>> 
>>> platform darwin arm {
>>> ...
>>> }
>> I wasn’t aware of this platform variants syntax 
>> (https://guide.macports.org/#reference.variants.platform) yet, so today I 
>> learned.
>> I maintain some ports that contain sections that look like this:
>> 
>> if {${configure.build_arch} eq "x86_64"} {
>> distname microsoft-jdk-${version}-macOS-x64
>> checksums rmd160 2fc1a89b2310905e0891bb2b1519c8df86998ab7 \
>> sha256 22697e9bbf3135c0ef843e7f371fe563ea948c6d464dfc532a7995fe32aebb09 \
>> size 187094964
>> } elseif {${configure.build_arch} eq "arm64"} {
>> distname microsoft-jdk-${version}-macOS-aarch64
>> checksums rmd160 feb696c4ba65ea42b68bb578e5e2de7b41e56669 \
>> sha256 c50a20ca8764a5aa54dc0a0cf681d891dadbdccc1051792806d797206d59ba34 \
>> size 184695872
>> }
>> 
>> I thought I’d replace such if-elseif sections with declarative platform 
>> variant blocks, but I noticed that the arch argument for the platform 
>> variant needs to be ‘arm’ instead of ‘arm64’:
>> 
>> platform darwin arm {
>> distname microsoft-jdk-${version}-macOS-aarch64
>> checksums rmd160 feb696c4ba65ea42b68bb578e5e2de7b41e56669 \
>> sha256 c50a20ca8764a5aa54dc0a0cf681d891dadbdccc1051792806d797206d59ba34 \
>> size 184695872
>> }
>> 
>> Why is the arch value for a platform variant not the same as 
>> ${configure.build_arch}? What are the valid values for the arch argument of 
>> a platform variant block? Can I use ‘platform darwin x86_64 { … }’ for the 
>> 64-bit Intel case or is that value also different from 
>> ${configure.build_arch}? I don’t have a x86_64 Mac I can use to test this 
>> myself.
> 
> The arch here is checked against ${os.arch}, which is (at least on darwin) 
> the same as the output of `uname -p`. That is separate to build_arch, which 
> depending on the OS version can often have multiple different valid values. 
> You use 'platform' purely to check what you're running on, not how you're 
> going to be building your code.

According to https://guide.macports.org/#reference.variables ${os.arch} is 
either “powerpc”, “i386”, or “arm”. Does this mean all Intel machines have 
${os.arch} set to ‘i386', regardless of whether they’re 32 or 64 bit machines, 
or is it possible to distinguish 32 and 64 bit Intel machines based on 
${os.arch}? What is the output of `uname -p` on a 64-bit Intel Mac?

In some of the ports I maintain no building is going on, but the port does need 
to know whether to install files for 32-bit Intel, 64-bit Intel or 64-bit ARM. 
Is that possible using platform variants, or does that indeed require checking 
${configure.build_arch}?

Nils.

Re: Using platforms in 2.8.0

[Nils Breunese]

Joshua Root  wrote:

> On 2022-11-1 11:45 , Nils Breunese wrote:
> 
>> So when a port installs one pre-built binary on x86_64 and another on arm64, 
>> regardless of OS version, setting 'platforms {darwin any}’ would be 
>> appropriate and correct?
> 
> Sure. Unless the x86_64 binary was built targeting 10.5 though, you probably 
> also need to restrict the versions. E.g. if the binary works on 10.12 and 
> later:
> 
> platforms {darwin any} {darwin >= 16}

Should that be ‘platforms {darwin >= 16}’? If not, I don’t really understand 
the syntax above yet.

I already have Daerwin version checks in place, but I should indeed also be 
able to get rid of those if-statements using this new platforms syntax with 
version check.

Nils.

Re: Using platforms in 2.8.0

[Nils Breunese]

Joshua Root  wrote:

> On 2022-11-1 11:14 , Nils Breunese wrote:
>> Joshua Root  wrote:
>>> There is another way that platforms can be used:
>>> 
>>> platforms any
>>> platforms {darwin any}
>>> 
>>> The first one indicates that the port will install identical files no 
>>> matter what platform it is built on, and will set the platform in the 
>>> archive filename to "any_any". The second one indicates that the port will 
>>> install identical files when built on any version of Darwin, but may 
>>> install different files when built on other platforms, and sets the 
>>> platform in the archive filename to "darwin_any" when on Darwin.
>>> 
>>> These will usually only be applicable to noarch ports, though rare 
>>> exceptions may exist. Ports that install only data files or scripts will 
>>> often be able to use "any". Python scripts are an exception because Python 
>>> uses a framework layout on Darwin only, so they will be "{darwin any}".
>> So setting ‘platforms {darwin any}’ is not appropriate when a port installs 
>> identical files on any Darwin version, but does install different files 
>> based on arch?
> 
> That would be uncommon but it is possible.

So when a port installs one pre-built binary on x86_64 and another on arm64, 
regardless of OS version, setting 'platforms {darwin any}’ would be appropriate 
and correct?

Nils.

Re: Using platforms in 2.8.0

[Nils Breunese]

Joshua Root  wrote:

> On 2022-10-22 21:56 , Kirill A. Korinsky wrote:
>> I'm asking is there a way to support specified arch inside platform block's 
>> condition. Like:
>> platform {aarch64}  {
>> ...
>> }
> 
> You can certainly do things like:
> 
> platform darwin arm {
> ...
> }

I wasn’t aware of this platform variants syntax 
(https://guide.macports.org/#reference.variants.platform) yet, so today I 
learned.

I maintain some ports that contain sections that look like this:


if {${configure.build_arch} eq "x86_64"} {
distnamemicrosoft-jdk-${version}-macOS-x64
checksums   rmd160  2fc1a89b2310905e0891bb2b1519c8df86998ab7 \
sha256  
22697e9bbf3135c0ef843e7f371fe563ea948c6d464dfc532a7995fe32aebb09 \
size187094964
} elseif {${configure.build_arch} eq "arm64"} {
distnamemicrosoft-jdk-${version}-macOS-aarch64
checksums   rmd160  feb696c4ba65ea42b68bb578e5e2de7b41e56669 \
sha256  
c50a20ca8764a5aa54dc0a0cf681d891dadbdccc1051792806d797206d59ba34 \
size184695872
}


I thought I’d replace such if-elseif sections with declarative platform variant 
blocks, but I noticed that the arch argument for the platform variant needs to 
be ‘arm’ instead of ‘arm64’:


platform darwin arm {
distnamemicrosoft-jdk-${version}-macOS-aarch64
checksums   rmd160  feb696c4ba65ea42b68bb578e5e2de7b41e56669 \
sha256  
c50a20ca8764a5aa54dc0a0cf681d891dadbdccc1051792806d797206d59ba34 \
size184695872
}


Why is the arch value for a platform variant not the same as 
${configure.build_arch}? What are the valid values for the arch argument of a 
platform variant block? Can I use ‘platform darwin x86_64 { … }’ for the 64-bit 
Intel case or is that value also different from ${configure.build_arch}? I 
don’t have a x86_64 Mac I can use to test this myself.

Nils.

Re: Using platforms in 2.8.0

[Nils Breunese]

Joshua Root  wrote:

> There is another way that platforms can be used:
> 
> platforms any
> platforms {darwin any}
> 
> The first one indicates that the port will install identical files no matter 
> what platform it is built on, and will set the platform in the archive 
> filename to "any_any". The second one indicates that the port will install 
> identical files when built on any version of Darwin, but may install 
> different files when built on other platforms, and sets the platform in the 
> archive filename to "darwin_any" when on Darwin.
> 
> These will usually only be applicable to noarch ports, though rare exceptions 
> may exist. Ports that install only data files or scripts will often be able 
> to use "any". Python scripts are an exception because Python uses a framework 
> layout on Darwin only, so they will be "{darwin any}".

So setting ‘platforms {darwin any}’ is not appropriate when a port installs 
identical files on any Darwin version, but does install different files based 
on arch?

Nils.

Re: Removed ports still listed on ports.macports.org

[Nils Breunese]

Ryan Schmidt  wrote:

> On Oct 30, 2022, at 01:06, Mojca Miklavec wrote:
> 
>> V ned., 30. okt. 2022 01:02 je oseba Nils Breunese napisala:
>>> Hi,
>>> 
>>> The openjdk port was removed on August 25th after it had been obsoleted a 
>>> while ago (https://github.com/macports/macports-ports/pull/15910), but I 
>>> just noticed that https://ports.macports.org/port/openjdk/details/ still 
>>> shows the openjdk port information from when it last existed.
>>> 
>>> I see there are more ports listed on 
>>> https://ports.macports.org<https://ports.macports.org/> that have been 
>>> removed from the ports tree, e.g. 
>>> https://ports.macports.org/port/openjdk7-zulu/.
> 
> openjdk7-zulu has *not* been removed from the ports tree. It's there, it's 
> just obsolete and can't be installed:
> 
> https://github.com/macports/macports-ports/blob/master/java/openjdk7-zulu/Portfile
> 
> It will be removed one year after it was marked as being obsolete.

Oops, I even obsoleted that port myself. Ok, ignore openjdk7-zulu as an 
example, but my point still stands for other removed ports.

Nils.

Re: Removed ports still listed on ports.macports.org

[Nils Breunese]

Mojca Miklavec  wrote:

> The port pages were kept on purpose (to let users find deleted ports easily 
> and potentially resurrect them instead of having to reinvent the wheel, for 
> historic / arcival reasons, ...), with the intention to clearly mark that 
> they have been deleted and they should not appear in searches within the site 
> unless explicitly requested.

The removed openjdk port currently does show up in searches, e.g. 
https://ports.macports.org/search/?q=jdk=on 

Nils.

Re: having the "+test" or "+tests" variant propagate causes unexpected builds

[Nils Breunese]

Maybe MacPorts could introduce the concept of ‘test dependencies’ (dependencies 
only required for running tests). I work with Apache Maven quite a bit, and 
apart from build and runtime dependencies (which MacPorts already 
distinguishes) it also supports declaring test scope dependencies, that don’t 
need to be installed until tests are actually run: 
https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Dependency_Scope

Nils.

> Op 30 okt. 2022 om 11:23 heeft Ryan Schmidt  het 
> volgende geschreven:
> 
> On Oct 28, 2022, at 21:33, Daniel J. Luke wrote:
>> 
>> I don't think implementation difficulty is the barrier here - but that all 
>> variants should just have the same behavior.
>> 
>> In my mind, the real problem is the need for +test variants, there should be 
>> a way to just use the test phase - and perhaps changes to base/ to enable 
>> that are a better option.
> 
> In one of my ports that has a tests variant, the reason why the variant 
> exists is that the build system looks for certain test dependencies at 
> configure time. If they're not there, it doesn't build the test suite and 
> doesn't allow tests to be run later. I'm not sure how MacPorts could be 
> improved to handle that better in the absence of a tests variant. Would you 
> have MacPorts do the configuration in the configure phase, do the build in 
> the build phase, and then redo the configuration and build in the test phase? 
> Or would you suggest in this case that the test dependencies that are needed 
> at configure time should be added unconditionally, so that even users who 
> won't be running the tests need to install them? In my port's case the 
> dependencies are probably small and that wouldn't make much of a difference, 
> but I'm not sure it'll always be that way for all ports.
> 
> 

Removed ports still listed on ports.macports.org

[Nils Breunese]

Hi,

The openjdk port was removed on August 25th after it had been obsoleted a while 
ago (https://github.com/macports/macports-ports/pull/15910), but I just noticed 
that https://ports.macports.org/port/openjdk/details/ still shows the openjdk 
port information from when it last existed.

I see there are more ports listed on https://ports.macports.org 
 that have been removed from the ports tree, e.g. 
https://ports.macports.org/port/openjdk7-zulu/. Does ports.macports.org 
 have some kind of mechanism that should clean up 
the entries for ports that no longer exist?

Nils.

Re: How to submit a patch to source code for specific arch (apple silicon)

[Nils Breunese]

Alejandro Imass  wrote:

> I found a problem with dia (GNU dia diagraming app) in Apple Silicon and 
> finally got it to compile and run. Was wondering what the process is to 
> submit a patch ? Are there any docs I can read that describe the process of 
> contributing to source code patches, etc.?

You can create a merge request on GitHub: 
https://guide.macports.org/chunked/project.github.html

Nils.

Re: Port unalz Pull Request #15527

[Nils Breunese]

GitHub shows PR’s only for the repository they target.

Nils.

> Op 3 aug. 2022 om 23:23 heeft Robert Kennedy  het volgende 
> geschreven:
> 
> 
> I found PR 15527 for unalz on the GitHub page for macports.  But I find it 
> strange that the PR does not appears on my Github page for my unalz branch.
> 
> Rob
> From: Robert Kennedy
> Sent: August 3, 2022 5:14 PM
> To: macports-dev@lists.macports.org 
> Subject: Port unalz Pull Request #15527
>  
> Last Friday, I submitted a Pull Request for the abandoned port unalz.
> 
> See
> https://github.com/macports/macports-ports/pull/15527
> 
> The Macport Githib page no longer lists the PR on the list of Pull Requests 
> at macports Github page.  And I no longer see it at my GitHib page RobK88.
> 
> Yet the PR is still shown as open.  Very strange.
> 
> When someone has time, please review the PR and commit the update.  It should 
> be ready to go with one small change.  A revision number needs to be added to 
> the Portfile.  (e.g. revision 1).
> 
> Thanks,
> 
> RobK88
> 
> 
> 
> 
> 

Re: ffmpeg 5.x status

[Nils Breunese]

When a new version introduces breaking changes and some other ports still 
require an older version, creating a new separate port (e.g. ffmpeg5) makes 
perfect sense to me.

Nils.

> Op 24 jul. 2022 om 20:12 heeft Christopher Nielsen  
> het volgende geschreven:
> 
> For anyone curious as to where things stand with updating ffmpeg to 5.x: 
> Based on local testing of dependents, it appears that upstream has made some 
> breaking API changes. And that affects a number of ports, making the update a 
> no-go at present.
> 
> However, I still need to dig into the details, to see if upstream provided 
> any facilities to ease migration. If not, we may need to support side-by-side 
> installations of ffmpeg 4.x and 5.x, in concert with the ability for users to 
> select their preferred version via ‘port select’.
> 
> In the interim, if folks are interested in testing their dependents against 
> the latest upstream release, it’s available via port ffmpeg-upstream.
> 
> Presumably this situation will eventually be alleviated, as dependent 
> projects are updated. But at the moment, things don’t look rosy.
> 
> Thoughts/comments welcome!
> 
> Cheers,
> -Chris

Re: fetch timeout

[Nils Breunese]

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.

According to SSL Labs their server configuration is pretty good: 
https://www.ssllabs.com/ssltest/analyze.html?d=wias-berlin.de=on 
reports an A-. The main remark in the report is that the server doesn’t support 
Secure Renegotiation, which causes the grade to be reduced to A-.

The server supports TLS 1.2 and 1.3 only. Not supporting broken SSL/TLS 
versions is generally a good thing from a security perspective, but might leave 
older clients unable to connect. E.g. macports.org also only supports TLS 1.2 
and 1.3. As far as I know not supporting a compatible TLS version would have 
resulted in a message saying so, so I guess that is not the issue.

The report for wias-berlin.de does show a couple of SSL handshake failures for 
simulated clients:

* Chrome 67 / Win 7
* Firefox 62 / Win 7
* Googlebot Feb 2018
* IE 11 / Win Phone 8.1
* Edge 15-18 / Win 10
* OpenSSL 1.1.0k (but the older 1.0.1l and 1.0.2s and the newer 1.1.1c are ok!)
* Safari 6 / iOS 6.0.1
* Safari 7 / iOS 7.1
* Safari 7 / OS X 10.9
* Safari 8 / iOS 8.4
* Safari 8 / OS X 10.10 (tested version of Safari 9 and later are ok)

SSL Labs doesn’t seem to be testing any versions of LibreSSL for the simulated 
handshake test, but I do find it remarkable that OpenSSL 1.1.0k fails, while 
both older (1.0.1l, 1.0.2s) and newer (1.1.1c) versions of OpenSSL succeed.

All of the simulated handshakes that failed for wias-berlin.de do succeed for 
macports.org. I don’t know if these handshake failures are caused by the server 
not offering any cipher suites supported by the client.

You could indeed try to contact the admin for wias-berlin.de to tell them that 
downloads from their domain are not working on macOS 11 Intel’s curl if that’s 
been established, and see if they know what to do (and care enough) to fix that.

The only other fix seems switching out the client for one that works (e.g. 
MacPorts curl).

Nils.

Re: fetch timeout

[Nils Breunese]

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

[Nils Breunese]

Mark Brethen  wrote:

> it has the file name and extensions but you’re right, it’s not a compressed 
> file.

The -O flag will write whatever body gets returned by the server into a file 
with the same name as the 'file name’ part of the URL, regardless of whether 
the HTTP status code of the response indicates success, a redirect, a client 
error or a server error.

You’ll see that the 273 bytes that get returned by requesting 
http://wias-berlin.de/software/tetgen/1.5/src/tetgen1.5.1.tar.gz are just HTML 
saying the the document should be requested via HTTPS:

❯ curl -O http://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   273  100   2730 0   1122  0 --:--:-- --:--:-- --:--:—  1181


❯ cat tetgen1.5.1.tar.gz 


301 Moved Permanently

Moved Permanently
The document has moved https://wias-berlin.de/software/tetgen/1.5/src/tetgen1.5.1.tar.gz;>here.


When you tell curl to follow redirects, you’ll see a second request being made 
and 275k getting downloaded:

❯ curl -OL http://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   273  100   2730 0194  0  0:00:01  0:00:01 --:--:--   195
100  275k  100  275k0 0  75618  0  0:00:03  0:00:03 --:--:—  249k

❯ file tetgen1.5.1.tar.gz 
tetgen1.5.1.tar.gz: gzip compressed data, was "tetgen1.5.1.tar", last modified: 
Tue Aug 21 14:40:36 2018, max compression, from Unix, original size modulo 2^32 
1528832

This works fine for me on macOS 12.4 Intel.

Nils.

> I tried two different intel-based Macs with clean installs of Catalina and 
> Big Sur (both use LibreSSL 2.8.3 btw) and was able to repeat that error. 
> However, it works correctly on an M1 installed with Big Sur. Since this is 
> the only host that I have run into problems with fetch, I’m not sure it’s 
> worth the time spent.
> 
>> On Jul 19, 2022, at 10:36 AM, Nils Breunese  wrote:
>> 
>> It doesn’t look like the .tar.gz file downloaded successfully, it looks like 
>> the HTML for the 301 redirect was downloaded.
>> 
>> Nils.
>> 
>>> Op 19 jul. 2022 om 17:20 heeft Mark Brethen  het 
>>> volgende geschreven:
>>> 
>>> Understood. Using HTTP instead of HTTPS doesn’t invoke SSL/TLS. If you 
>>> look at the command line output (not port), that error didn’t occur and the 
>>> file downloaded successfully. I was curious what the fetch curl command 
>>> looked like vs the command line?
>>> 
>>> Sent from my iPhone
>>> 
>>>> On Jul 19, 2022, at 9:57 AM, Nils Breunese  wrote:
>>>> 
>>>> 
>>>> This depends on your definition of succeeding. The request to the HTTP 
>>>> URL returns a 301 redirect, which is not necessarily a ‘success’ status 
>>>> code. This response points to the HTTPS URL and the TLS/SSL error only 
>>>> occurs when requesting that URL.
>>>> 
>>>> Nils.
>>>> 
>>>>> Op 19 jul. 2022 om 11:58 heeft Mark Brethen  het 
>>>>> volgende geschreven:
>>>>> 
>>>>> Please tell me why fetch still fails when /usr/bin/curl succeeds in 
>>>>> terminal?
>>>>> 
>>>>> :notice:fetch --->  Attempting to fetch tetgen1.5.1.tar.gz from 
>>>>> http://wias-berlin.de/software/tetgen/1.5/src/
>>>>> :debug:fetch Fetching distfile failed: error:14008410:SSL 
>>>>> routines:CONNECT_CR_KEY_EXCH:sslv3 alert handshake failure
>>>>> 
>>>>> Mark Brethen
>>>>> mark.bret...@gmail.com
>>>>> 
>>>>> 
>>>>> 
>>>>>> On Jul 19, 2022, at 4:46 AM, Mark Brethen  wrote:
>>>>>> 
>>>>>> HTTPS uses TLS (SSL) to encrypt normal HTTP requests and responses. Use 
>>>>>> HTTP instead:
>>>>>> 
>>>>>> ~ $ cd Downloads
>>>>>> Downloads $ /usr/bin/curl -vO 
>>>>>> http://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 --:--:-- --:--:-- --:--:-- 
>>>>>>

Re: fetch timeout

[Nils Breunese]

It doesn’t look like the .tar.gz file downloaded successfully, it looks like 
the HTML for the 301 redirect was downloaded.

Nils.

> Op 19 jul. 2022 om 17:20 heeft Mark Brethen  het 
> volgende geschreven:
> 
> Understood. Using HTTP instead of HTTPS doesn’t invoke SSL/TLS. If you look 
> at the command line output (not port), that error didn’t occur and the file 
> downloaded successfully. I was curious what the fetch curl command looked 
> like vs the command line?
> 
> Sent from my iPhone
> 
>>> On Jul 19, 2022, at 9:57 AM, Nils Breunese  wrote:
>>> 
>> 
>> This depends on your definition of succeeding. The request to the HTTP URL 
>> returns a 301 redirect, which is not necessarily a ‘success’ status code. 
>> This response points to the HTTPS URL and the TLS/SSL error only occurs when 
>> requesting that URL.
>> 
>> Nils.
>> 
>>>> Op 19 jul. 2022 om 11:58 heeft Mark Brethen  het 
>>>> volgende geschreven:
>>>> 
>>> Please tell me why fetch still fails when /usr/bin/curl succeeds in 
>>> terminal?
>>> 
>>> :notice:fetch --->  Attempting to fetch tetgen1.5.1.tar.gz from 
>>> http://wias-berlin.de/software/tetgen/1.5/src/
>>> :debug:fetch Fetching distfile failed: error:14008410:SSL 
>>> routines:CONNECT_CR_KEY_EXCH:sslv3 alert handshake failure
>>> 
>>> Mark Brethen
>>> mark.bret...@gmail.com
>>> 
>>> 
>>> 
>>>> On Jul 19, 2022, at 4:46 AM, Mark Brethen  wrote:
>>>> 
>>>> HTTPS uses TLS (SSL) to encrypt normal HTTP requests and responses. Use 
>>>> HTTP instead:
>>>> 
>>>> ~ $ cd Downloads
>>>> Downloads $ /usr/bin/curl -vO 
>>>> http://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*   Trying 62.141.177.111...
>>>> * TCP_NODELAY set
>>>> * Connected to wias-berlin.de (62.141.177.111) port 80 (#0)
>>>> > GET /software/tetgen/1.5/src/tetgen1.5.1.tar.gz HTTP/1.1
>>>> > Host: wias-berlin.de
>>>> > User-Agent: curl/7.64.1
>>>> > Accept: */*
>>>> > 
>>>> < HTTP/1.1 301 Moved Permanently
>>>> < Date: Tue, 19 Jul 2022 09:37:56 GMT
>>>> < Server: Apache
>>>> < Location: 
>>>> https://wias-berlin.de/software/tetgen/1.5/src/tetgen1.5.1.tar.gz
>>>> < Content-Length: 273
>>>> < Content-Type: text/html; charset=iso-8859-1
>>>> < 
>>>> { [273 bytes data]
>>>> 100   273  100   2730 0291  0 --:--:-- --:--:-- --:--:--   
>>>> 291
>>>> * Connection #0 to host wias-berlin.de left intact
>>>> * Closing connection 0
>>>> 
>>>> Mark Brethen
>>>> mark.bret...@gmail.com
>>>> 
>>>> 
>>>> 
>>>>> On Jul 18, 2022, at 11:56 AM, Mark Brethen  wrote:
>>>>> 
>>>>> It’s more likely that curl 7.64.1 succeeds to connect while openssl 2.8.3 
>>>>> fails with alert number 40 (see below). It might be related to the server 
>>>>> which has several virtual hosts. openssl 3.0.5 (mp) seems to handle it 
>>>>> fine compared to openssl 2.8.3.
>>>>> 
>>>>> Downloads $ openssl version
>>>>> OpenSSL 3.0.5 5 Jul 2022 (Library: OpenSSL 3.0.5 5 Jul 2022)
>>>>> 
>>>>> Downloads $ openssl s_client -connect wias-berlin.de:443 -servername 
>>>>> wias-berlin.de
>>>>> CONNECTED(0005)
>>>>> depth=3 C = DE, O = T-Systems Enterprise Services GmbH, OU = T-Systems 
>>>>> Trust Center, CN = T-TeleSec GlobalRoot Class 2
>>>>> verify return:1
>>>>> depth=2 C = DE, O = Verein zur Foerderung eines Deutschen 
>>>>> Forschungsnetzes e. V., OU = DFN-PKI, CN = DFN-Verein Certification 
>>>>> Authority 2
>>>>> verify return:1
>>>>> depth=1 C = DE, O = Verein zur Foerderung eines Deutschen 
>>>>> Forschungsnetzes e. V., OU = DFN-PKI, CN = DFN-Verein Global Issuing CA
>>>>> verify return:1
>>>>> depth=0 C = DE, ST = Berlin, L = Berlin, O = Forschung

Re: fetch timeout

[Nils Breunese]

This depends on your definition of succeeding. The request to the HTTP URL 
returns a 301 redirect, which is not necessarily a ‘success’ status code. This 
response points to the HTTPS URL and the TLS/SSL error only occurs when 
requesting that URL.

Nils.

> Op 19 jul. 2022 om 11:58 heeft Mark Brethen  het 
> volgende geschreven:
> Please tell me why fetch still fails when /usr/bin/curl succeeds in terminal?
> 
> :notice:fetch --->  Attempting to fetch tetgen1.5.1.tar.gz from 
> http://wias-berlin.de/software/tetgen/1.5/src/
> :debug:fetch Fetching distfile failed: error:14008410:SSL 
> routines:CONNECT_CR_KEY_EXCH:sslv3 alert handshake failure
> 
> Mark Brethen
> mark.bret...@gmail.com
> 
> 
> 
>> On Jul 19, 2022, at 4:46 AM, Mark Brethen  wrote:
>> 
>> HTTPS uses TLS (SSL) to encrypt normal HTTP requests and responses. Use HTTP 
>> instead:
>> 
>> ~ $ cd Downloads
>> Downloads $ /usr/bin/curl -vO 
>> http://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*   Trying 62.141.177.111...
>> * TCP_NODELAY set
>> * Connected to wias-berlin.de (62.141.177.111) port 80 (#0)
>> > GET /software/tetgen/1.5/src/tetgen1.5.1.tar.gz HTTP/1.1
>> > Host: wias-berlin.de
>> > User-Agent: curl/7.64.1
>> > Accept: */*
>> > 
>> < HTTP/1.1 301 Moved Permanently
>> < Date: Tue, 19 Jul 2022 09:37:56 GMT
>> < Server: Apache
>> < Location: https://wias-berlin.de/software/tetgen/1.5/src/tetgen1.5.1.tar.gz
>> < Content-Length: 273
>> < Content-Type: text/html; charset=iso-8859-1
>> < 
>> { [273 bytes data]
>> 100   273  100   2730 0291  0 --:--:-- --:--:-- --:--:--   
>> 291
>> * Connection #0 to host wias-berlin.de left intact
>> * Closing connection 0
>> 
>> Mark Brethen
>> mark.bret...@gmail.com
>> 
>> 
>> 
>>> On Jul 18, 2022, at 11:56 AM, Mark Brethen  wrote:
>>> 
>>> It’s more likely that curl 7.64.1 succeeds to connect while openssl 2.8.3 
>>> fails with alert number 40 (see below). It might be related to the server 
>>> which has several virtual hosts. openssl 3.0.5 (mp) seems to handle it fine 
>>> compared to openssl 2.8.3.
>>> 
>>> Downloads $ openssl version
>>> OpenSSL 3.0.5 5 Jul 2022 (Library: OpenSSL 3.0.5 5 Jul 2022)
>>> 
>>> Downloads $ openssl s_client -connect wias-berlin.de:443 -servername 
>>> wias-berlin.de
>>> CONNECTED(0005)
>>> depth=3 C = DE, O = T-Systems Enterprise Services GmbH, OU = T-Systems 
>>> Trust Center, CN = T-TeleSec GlobalRoot Class 2
>>> verify return:1
>>> depth=2 C = DE, O = Verein zur Foerderung eines Deutschen Forschungsnetzes 
>>> e. V., OU = DFN-PKI, CN = DFN-Verein Certification Authority 2
>>> verify return:1
>>> depth=1 C = DE, O = Verein zur Foerderung eines Deutschen Forschungsnetzes 
>>> e. V., OU = DFN-PKI, CN = DFN-Verein Global Issuing CA
>>> verify return:1
>>> depth=0 C = DE, ST = Berlin, L = Berlin, O = Forschungsverbund Berlin e.V., 
>>> OU = Weierstrass-Institut f. Angewandte Analysis u. Stochastik (WIAS), OU = 
>>> RT, CN = www.wias-berlin.de
>>> verify return:1
>>> 
>>> Downloads $ /usr/bin/openssl version
>>> LibreSSL 2.8.3
>>> 
>>> Downloads $ /usr/bin/openssl s_client -connect wias-berlin.de:443 
>>> -servername wias-berlin.de
>>> CONNECTED(0005)
>>> depth=3 C = DE, O = T-Systems Enterprise Services GmbH, OU = T-Systems 
>>> Trust Center, CN = T-TeleSec GlobalRoot Class 2
>>> verify return:1
>>> depth=2 C = DE, O = Verein zur Foerderung eines Deutschen Forschungsnetzes 
>>> e. V., OU = DFN-PKI, CN = DFN-Verein Certification Authority 2
>>> verify return:1
>>> depth=1 C = DE, O = Verein zur Foerderung eines Deutschen Forschungsnetzes 
>>> e. V., OU = DFN-PKI, CN = DFN-Verein Global Issuing CA
>>> verify return:1
>>> depth=0 C = DE, ST = Berlin, L = Berlin, O = Forschungsverbund Berlin e.V., 
>>> OU = Weierstrass-Institut f. Angewandte Analysis u. Stochastik (WIAS), OU = 
>>> RT, CN = www.wias-berlin.de
>>> verify return:1
>>> 4381900460:error:14008410:SSL 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
>>> 4381900460:error:140080E5:SSL routines:CONNECT_CR_KEY_EXCH:ssl 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:585:
>>> ---
>>> 
>>> 
>>> 
>>> Mark
>>> 
>>> 
>>> 
 On Jul 18, 2022, at 8:11 AM, Mark Brethen  wrote:
 
 wias-berlin.de

Re: Frotz build targets

[Nils Breunese]

I don’t maintain any ports with GUI’s myself, but I believe flavors like x11, 
sdl, etc. are usually provided as variants of a port instead of as subports. 
You can also specify conflicts between variants if there are any to avoid users 
installing conflicting variants. For instance the glib2 port contains 'variant 
x11 conflicts quartz { … }’.

Nils.

> Op 28 jun. 2022, om 00:40 heeft Mark Brethen  het 
> volgende geschreven:
> 
> Frotz Makefile:
> 
> # Build recipes
> #
> curses: $(FROTZ_BIN)
> ncurses: $(FROTZ_BIN)
> $(FROTZ_BIN): $(FROTZ_LIBS)
>   $(CC) $+ -o $@$(EXTENSION) $(LDFLAGS) $(CURSES_LDFLAGS) 
> $(CURSES_SOUND_LDFLAGS)
>   @echo "** Done building Frotz with curses interface"
>   @echo "** Audio support $(CURSES_SOUND) (type $(SOUND_TYPE))"
>   @echo "** Blorb support $(BLORB_SUPPORT)"
> 
> nosound: nosound_helper $(FROTZ_BIN) | nosound_helper
> nosound_helper:
>   $(eval SOUND_TYPE= none)
>   $(eval NO_SOUND= -DNO_SOUND)
>   $(eval CURSES_SOUND_LDFLAGS= )
>   $(eval CURSES_SOUND= disabled)
> 
> dumb: $(DFROTZ_BIN)
> $(DFROTZ_BIN): $(DFROTZ_LIBS)
>   $(CC) $+ -o $@$(EXTENSION) $(LDFLAGS)
>   @echo "** Done building Frotz with dumb interface."
>   @echo "** Blorb support $(BLORB_SUPPORT)"
> 
> x11: $(XFROTZ_BIN)
> $(XFROTZ_BIN): $(XFROTZ_LIBS)
>   $(CC) $+ -o $@$(EXTENSION) $(LDFLAGS) $(X11_LDFLAGS)
>   @echo "** Done building Frotz with X11 interface."
> 
> sdl: $(SFROTZ_BIN)
> $(SFROTZ_BIN): $(SFROTZ_LIBS)
>   $(CC) $+ -o $@$(EXTENSION) $(LDFLAGS) $(SDL_LDFLAGS)
>   @echo "** Done building Frotz with SDL interface."
> 
> 
> I’ve created subports for the frotz Portfile, i.e. curses_frotz, dumb_frotz 
> and sdl_frotz. frotz can be compiled without sound using "build.target 
> nosound” which I’d like to implement as a variant for curses frotz. (see the 
> attached Portfile)
> 
> 
> Mark Brethen
> mark.bret...@gmail.com
> 
> 
> 
>> On Jun 27, 2022, at 5:16 PM, Nils Breunese  wrote:
>> 
>> I believe variants are global for a port, but Iyou could use conditional 
>> logic based on which subport gets installed for a variant. What are you 
>> trying to achieve?
>> 
>> Nils.
>> 
>>> Op 27 jun. 2022, om 23:35 heeft Mark Brethen  het 
>>> volgende geschreven:
>>> 
>>> Can a subport have variants?
>>> 
>>> Mark Brethen
>>> mark.bret...@gmail.com
>>> 
>>> 
>>> 
>>>> On Jun 26, 2022, at 9:03 PM, Mark Brethen  wrote:
>>>> 
>>>> I’ll do that. It’s been so long that I’ve forgotten how they’re set up.
>>>> 
>>>> Mark Brethen
>>>> mark.bret...@gmail.com
>>>> 
>>>> 
>>>> 
>>>>> On Jun 26, 2022, at 8:56 PM, Ryan Schmidt  wrote:
>>>>> 
>>>>> On Jun 26, 2022, at 17:39, Mark Brethen wrote:
>>>>>> 
>>>>>> Attaching a Portfile that uses variants—downside is you can only install 
>>>>>> one. Maybe that is sufficient? I couldn’t find any documentation for 
>>>>>> using subports.
>>>>> 
>>>>> What would you like to know about subports? Have you looked at any 
>>>>> existing portfiles that use subports to see how they work?
>>>>> 
>>>> 
>>> 
>> 
> 

Re: Frotz build targets

[Nils Breunese]

I believe variants are global for a port, but Iyou could use conditional logic 
based on which subport gets installed for a variant. What are you trying to 
achieve?

Nils.

> Op 27 jun. 2022, om 23:35 heeft Mark Brethen  het 
> volgende geschreven:
> 
> Can a subport have variants?
> 
> Mark Brethen
> mark.bret...@gmail.com
> 
> 
> 
>> On Jun 26, 2022, at 9:03 PM, Mark Brethen  wrote:
>> 
>> I’ll do that. It’s been so long that I’ve forgotten how they’re set up.
>> 
>> Mark Brethen
>> mark.bret...@gmail.com
>> 
>> 
>> 
>>> On Jun 26, 2022, at 8:56 PM, Ryan Schmidt  wrote:
>>> 
>>> On Jun 26, 2022, at 17:39, Mark Brethen wrote:
 
 Attaching a Portfile that uses variants—downside is you can only install 
 one. Maybe that is sufficient? I couldn’t find any documentation for using 
 subports.
>>> 
>>> What would you like to know about subports? Have you looked at any existing 
>>> portfiles that use subports to see how they work?
>>> 
>> 
> 

Re: Significant security vulnerability discovered in Log4j

[Nils Breunese]

Arjun Salyan  wrote::

>> On 12-Dec-2021, at 3:27 PM, Joshua Root  wrote:
>> 
>> Not all ports have installed file information available, but the web app can 
>> search the ones that do:
>> 
>> 
> 
> I identified an issue with the way we were updating our search index. That 
> has been fixed and now this page shows 17 ports, instead of 5.

Thanks for fixing! For Log4J only log4j-core-* is relevant, and 
https://ports.macports.org/search/?installed_file=log4j-core= only shows the 
ports we already previously identified.

A couple of hours ago 
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-45046 was made public, 
which states that the previous mitigations of upgrading to Log4J 2.15.0 or 
setting system/environment properties is longer enough. The recommended 
solution is upgrading to Log4J 2.16.0. If that is not possible, it is 
recommended to at least remove the JndiLookup class from the log4j-core JAR 
(e.g. zip -q -d log4j-core-*.jar 
org/apache/logging/log4j/core/lookup/JndiLookup.class).

Nils.

Re: Significant security vulnerability discovered in Log4j

[Nils Breunese]

Nils Breunese  wrote:

> Eric Gallager  wrote:
> 
>> On Sun, Dec 12, 2021 at 4:57 AM Joshua Root  wrote:
>>> 
>>> On 2021-12-12 20:02 , Nils Breunese wrote:
>>>> It could be the case the MacPorts has ports for Java-based applications 
>>>> that include a vulnerable version of the Log4J library. A port that 
>>>> includes a file called log4j-$version.jar with $version in the range 
>>>> 2.0.0-2.14.1 could be vulnerable. This file could also be ‘hidden’ inside 
>>>> a compressed archive, like a .war file (basically a zip file). I’m not 
>>>> sure how we could check all ports for this without installing all of them.
>>> 
>>> Not all ports have installed file information available, but the web app
>>> can search the ones that do:
>>> 
>>> <https://ports.macports.org/search/?installed_file=log4j=>
>>> 
>>> - Josh
>> 
>> Some other ports with log4j-related files that don't show up in this
>> search: spring-framework25 +with_libs (from the 1.x series, so it's
>> safe), slf4j (just docs, so it's safe), log4jdbc (also old, and
>> possibly a spurious string match, so probably also safe), duck (1.x
>> series, so it's safe), apache-ant (not seeing version info, I dunno),
>> apache-geode (this one might actually need checking?),
>> appengine-java-sdk (not sure), ghidra (this one looks vulnerable), poi
>> (1.x series, so it's safe), webtoolkit-java-sdk (I dunno), zanata-cli
>> (1.x series, so it's safe), and commons-logging (doesn't even build).
>> I'll attach the output of `locate /opt/local/*log4j* | xargs port
>> provides` to this email so you can see the same list I was looking at.
>> 
> 
> I said to look log4j-$version.jar earlier, but I should have said 
> log4j-core-$version.jar.
> 
> In your list apache-solr8 and apache-geode contain vulnerable versions of 
> Log4J 2.x.

And ghidra indeed, sorry.

The version of Apache Geode in MacPorts (1.0.0-incubating) is also rather old. 
Version 1.14.1 of Apache Geode bumped its dependency on Log4J to 2.15.0, which 
is the fixed version: 
https://cwiki.apache.org/confluence/display/GEODE/Release+Notes#ReleaseNotes-1.14.1

Nils.

Re: Significant security vulnerability discovered in Log4j

[Nils Breunese]

Eric Gallager  wrote:

> On Sun, Dec 12, 2021 at 4:57 AM Joshua Root  wrote:
>> 
>> On 2021-12-12 20:02 , Nils Breunese wrote:
>>> It could be the case the MacPorts has ports for Java-based applications 
>>> that include a vulnerable version of the Log4J library. A port that 
>>> includes a file called log4j-$version.jar with $version in the range 
>>> 2.0.0-2.14.1 could be vulnerable. This file could also be ‘hidden’ inside a 
>>> compressed archive, like a .war file (basically a zip file). I’m not sure 
>>> how we could check all ports for this without installing all of them.
>> 
>> Not all ports have installed file information available, but the web app
>> can search the ones that do:
>> 
>> <https://ports.macports.org/search/?installed_file=log4j=>
>> 
>> - Josh
> 
> Some other ports with log4j-related files that don't show up in this
> search: spring-framework25 +with_libs (from the 1.x series, so it's
> safe), slf4j (just docs, so it's safe), log4jdbc (also old, and
> possibly a spurious string match, so probably also safe), duck (1.x
> series, so it's safe), apache-ant (not seeing version info, I dunno),
> apache-geode (this one might actually need checking?),
> appengine-java-sdk (not sure), ghidra (this one looks vulnerable), poi
> (1.x series, so it's safe), webtoolkit-java-sdk (I dunno), zanata-cli
> (1.x series, so it's safe), and commons-logging (doesn't even build).
> I'll attach the output of `locate /opt/local/*log4j* | xargs port
> provides` to this email so you can see the same list I was looking at.
> 

I said to look log4j-$version.jar earlier, but I should have said 
log4j-core-$version.jar.

In your list apache-solr8 and apache-geode contain vulnerable versions of Log4J 
2.x.

Nils.

Re: Significant security vulnerability discovered in Log4j

[Nils Breunese]

Nils Breunese  wrote:

> For versions of Log4J 2.x older than these properties are not read yet. (…)

I meant to write: For versions of Log4J 2.x older than *2.10* these properties 
are not read yet, so you can’t use the properties to mitigate the vulnerability 
if you’re using Log4J < 2.10.

Nils.

Re: Significant security vulnerability discovered in Log4j

[Nils Breunese]

Joshua Root  wrote:

> On 2021-12-12 20:02 , Nils Breunese wrote:
>> It could be the case the MacPorts has ports for Java-based applications that 
>> include a vulnerable version of the Log4J library. A port that includes a 
>> file called log4j-$version.jar with $version in the range 2.0.0-2.14.1 could 
>> be vulnerable. This file could also be ‘hidden’ inside a compressed archive, 
>> like a .war file (basically a zip file). I’m not sure how we could check all 
>> ports for this without installing all of them.
> 
> Not all ports have installed file information available, but the web app can 
> search the ones that do:
> 
> <https://ports.macports.org/search/?installed_file=log4j=>

I’ve locally installed those five ports and found two ports that come with 
vulnerable versions of Log4J 2.x:

1. apache-solr8 8.9.0_0 includes log4j-core-2.13.2.jar, which is a vulnerable 
version of Log4J 2.x

https://github.com/apache/solr/pull/454#issuecomment-991066278 says: "Just open 
your solr.in.sh in your favorite editor and add SOLR_OPTS="$SOLR_OPTS 
-Dlog4j2.formatMsgNoLookups=true". Restart Solr. Done, all safe.”

This could be added in /opt/local/share/java/solr-8.9.0/bin/solr.in.sh.

2. elasticsearch 7.15.2_0 includes log4j-core-2.11.1.jar, which is a vulnerable 
version of Log4J 2.x

https://github.com/elastic/elasticsearch/issues/81618 says: "This can be 
mitigated for the time being by adding -Dlog4j2.formatMsgNoLookups=true to 
ES_JAVA_OPTS". I think I’d add -Dlog4j2.formatMsgNoLookups=true in 
/opt/local/etc/elasticsearch/jvm.options, or add ES_JAVA_OPTS="$ES_JAVA_OPTS 
-Dlog4j2.formatMsgNoLookups=true" at the end of 
/opt/local/bin/elasticsearch-env.

The other three ports (gradle, mvnd, NetBeans) do not include Log4J 2.x.

The vulnerability can generally be mitigated by setting the system property 
log4j2.formatMsgNoLookups to true (e.g. by passing 
-Dlog4j2.formatMsgNoLookups=true to a java startup command), or by setting the 
LOG4J_FORMAT_MSG_NO_LOOKUPS environment variable to true.

For versions of Log4J 2.x older than these properties are not read yet. In that 
case you might want to delete the JndiLookup class from the log4j-core file:

zip -d log4j-core-*.jar 
org/apache/logging/log4j/core/lookup/JndiLookup.class

Nils.

Re: Significant security vulnerability discovered in Log4j

[Nils Breunese]

Eric Gallager wrote:

> On Fri, Dec 10, 2021 at 6:00 PM Jason Liu  wrote:
>> 
>> In case everyone hadn't heard the news. If anyone is running Log4j for 
>> logging on any of your web servers, you might want to read this.
>> 
>> WIRED: 'The Internet Is On Fire'
>> A vulnerability in the Log4j logging framework has security teams scrambling 
>> to put in a fix.
>> 
>> --
>> Jason Liu
> 
> so... is there anything to do about this in MacPorts?
> 
> $ port search log4j
> jakarta-log4j @1.2.16 (java, devel)
>Java logging API
> 
> log4cxx @0.10.0_1 (devel)
>log4cxx is a port to C++ of the log4j project
> 
> log4jdbc @1.1 (java)
>JDBC driver that can log SQL and/or JDBC calls
> 
> p5-log-dispatch-config @1.40.0 (perl)
>Log::Dispatch::Config - Log4j for Perl
> 
> p5-log-log4perl @1.540.0 (perl)
>Log4j implementation for Perl
> 
> p5.28-log-dispatch-config @1.40.0 (perl)
>Log::Dispatch::Config - Log4j for Perl
> 
> p5.28-log-log4perl @1.540.0 (perl)
>Log4j implementation for Perl
> 
> p5.30-log-dispatch-config @1.40.0 (perl)
>Log::Dispatch::Config - Log4j for Perl
> 
> p5.30-log-log4perl @1.540.0 (perl)
>Log4j implementation for Perl
> 
> p5.32-log-dispatch-config @1.40.0 (perl)
>Log::Dispatch::Config - Log4j for Perl
> 
> p5.32-log-log4perl @1.540.0 (perl)
>Log4j implementation for Perl
> 
> Found 11 ports.
> $ port installed `port -q search log4j`
> The following ports are currently installed:
>  jakarta-log4j @1.2.16_0 (active)
>  log4jdbc @1.1_0 (active)
>  p5.28-log-log4perl @1.540.0_0 (active)
>  p5.30-log-log4perl @1.540.0_0 (active)
>  p5.32-log-log4perl @1.540.0_0 (active)
> $
> 
> ...I don't think any of these are the same thing, are they?

I’m a Java developer and MacPorts OpenJDK maintainer and to me none of these 
ports look related to Log4J 2.x, which is the vulnerable library.

It could be the case the MacPorts has ports for Java-based applications that 
include a vulnerable version of the Log4J library. A port that includes a file 
called log4j-$version.jar with $version in the range 2.0.0-2.14.1 could be 
vulnerable. This file could also be ‘hidden’ inside a compressed archive, like 
a .war file (basically a zip file). I’m not sure how we could check all ports 
for this without installing all of them.

Nils.

Re: incr revision / portindex

[Nils Breunese]

Joshua Root  wrote:

> On 2021-11-5 18:42 , Ryan Schmidt wrote:
>> Either we allow portindexes that differ by OS version and arch (and we 
>> currently do), or we do not.
> 
> That's something of a false dichotomy; we can also allow it for some but not 
> all options. I am advocating disallowing it by policy for version and 
> revision, not just because of this issue but because it makes it impossible 
> to answer questions like "What is the current version of this port?"

I maintain the various openjdk* ports and the latest versions for x86_64 and 
arm64 are not always the same for a particular openjdk* port. So what the 
current version of a port is cannot always be answered without the context of 
OS/arch.

Nils.

Re: Warning: The macOS 12 SDK does not appear to be installed. Ports may not build correctly.

[Nils Breunese]

Joshua Root  wrote:

> On 2021-10-31 10:04 , Daniel J. Luke wrote:
>> On Oct 30, 2021, at 5:25 PM, Nils Breunese  wrote:
>>> But I indeed don’t seem to have an SDK for macOS 12:
>>> 
>>> So far I haven’t had any ports not building correctly. Is this a known 
>>> issue? Does it have a known solution?
>> Yes - you can fix it by re-installing the command line tools:
>> https://trac.macports.org/wiki/ProblemHotlist#reinstall-clt
>> (this happened to me on upgrade to macOS 12 as well).
> 
> I'd encourage everyone affected by this issue to use Feedback Assistant to 
> let Apple know that you would like it fixed.

I’ve just reported this issue via Feedback Assistant. I’ve been using Macs 
since 2004, but actually didn’t know about Feedback Assistent. Until now I’ve 
only used https://www.apple.com/feedback/, but Feedback Assistant is nice, so 
thanks for pointing that out.

Nils.

Re: Warning: The macOS 12 SDK does not appear to be installed. Ports may not build correctly.

[Nils Breunese]

Joshua Root  wrote:

> On 2021-10-31 10:04 , Daniel J. Luke wrote:
>>> On Oct 30, 2021, at 5:25 PM, Nils Breunese  wrote:
>>> But I indeed don’t seem to have an SDK for macOS 12:
>>> 
>>> So far I haven’t had any ports not building correctly. Is this a known 
>>> issue? Does it have a known solution?
>> Yes - you can fix it by re-installing the command line tools:
>> https://trac.macports.org/wiki/ProblemHotlist#reinstall-clt
>> (this happened to me on upgrade to macOS 12 as well).
> 
> I'd encourage everyone affected by this issue to use Feedback Assistant to 
> let Apple know that you would like it fixed.

Apart from adding that link to the MacPorts warning message, would it be a good 
idea to let that wiki page more explicitly state that this is caused by a macOS 
bug and that we recommend reporting this issue to Apple via the Feedback 
Assistant when you are affected by this?

Nils.

Re: Warning: The macOS 12 SDK does not appear to be installed. Ports may not build correctly.

[Nils Breunese]

Daniel J. Luke  wrote:

> On Oct 30, 2021, at 5:25 PM, Nils Breunese  wrote:
>> But I indeed don’t seem to have an SDK for macOS 12:
>> 
>> So far I haven’t had any ports not building correctly. Is this a known 
>> issue? Does it have a known solution?
> 
> Yes - you can fix it by re-installing the command line tools:
> 
> https://trac.macports.org/wiki/ProblemHotlist#reinstall-clt

Ah, now I remember I’ve had to this on previous OS upgrades as well, but I also 
remember MacPorts used to refer to the URL that explains how to fix this. Could 
that link be added to the warning message again, so users will know what to do?

Nils.

Warning: The macOS 12 SDK does not appear to be installed. Ports may not build correctly.

[Nils Breunese]

Hello all,

Today I upgraded my personal machine from macOS Big Sur to Monterey and I 
installed the Monterey version of MacPorts, and upgraded all my installed 
ports, which reinstalled them for Darwin 21.

I also see get this message very frequently when running `port` commands:


Warning: The macOS 12 SDK does not appear to be installed. Ports may not build 
correctly.
Warning: You can install it as part of the Xcode Command Line Tools package by 
running `xcode-select --install’.


When I run `xcode-select --install` I get:


xcode-select: error: command line tools are already installed, use "Software 
Update" to install updates


But I indeed don’t seem to have an SDK for macOS 12:


~ ❯ ls -l /Library/Developer/CommandLineTools/SDKs 
total 0
lrwxr-xr-x  1 root  wheel   14 12 mei 18:37 MacOSX.sdk -> MacOSX11.3.sdk
drwxr-xr-x  7 root  wheel  224 17 aug  2020 MacOSX10.14.sdk
drwxr-xr-x  8 root  wheel  256  1 feb  2021 MacOSX10.15.sdk
drwxr-xr-x  7 root  wheel  224 16 mrt  2021 MacOSX11.3.sdk
lrwxr-xr-x  1 root  wheel   14 12 mei 18:35 MacOSX11.sdk -> MacOSX11.3.sdk


So far I haven’t had any ports not building correctly. Is this a known issue? 
Does it have a known solution?

Nils.

Re: gitconfig file truncated in new git revision

[Nils Breunese]

Gregory Anders  wrote:

> I submitted a PR to the git port [1] that creates a global gitconfig file at 
> /opt/local/etc/gitconfig when the credential_osxkeychain variant is enabled. 
> I noticed today that when I installed the new version, the file was created 
> but had no contents:
> 
>$ ls -l /opt/local/etc/gitconfig
>-rw-r--r--  1 root  admin  0 May 15 11:48 /opt/local/etc/gitconfig
>$ cat /opt/local/etc/gitconfig
>$
> 
> And indeed, the file in the tbz2 archive is empty as well:
> 
>$ mkdir ~/tmp
>$ tar -C ~/tmp -xf 
> /opt/local/var/macports/software/git/git-2.31.1_1+credential_osxkeychain+diff_highlight+doc+pcre+perl5_28.darwin_18.x86_64.tbz2
>$ cat ~/tmp/opt/local/etc/gitconfig
>$
> 
> However, if I run `sudo port -k install git` and inspect the destroot 
> directory, the file has the correct contents:
> 
>$ cat 
> /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_devel_git/git/work/destroot/opt/local/etc/gitconfig
>[credential]
>helper = osxkeychain
> 
> For some reason during the install phase the file is being truncated. 
> Bizarrely, if I uninstall and reinstall the port from the existing destroot, 
> the file then has the correct contents:
> 
>$ sudo port uninstall git
>$ sudo port -k install git
>--->  Computing dependencies for git.
>--->  Installing 
> git@2.31.1_1+credential_osxkeychain+diff_highlight+doc+pcre+perl5_28
>Executing:  cd 
> "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_devel_git/git/work/destroot"
>  && /usr/bin/tar -cvf - . | /usr/bin/bzip2 -c9 > 
> /opt/local/var/macports/software/git/git-2.31.1_1+credential_osxkeychain+diff_highlight+doc+pcre+perl5_28.darwin_18.x86_64.tbz2
>...
>--->  Activating git 
> @2.31.1_1+credential_osxkeychain+diff_highlight+doc+pcre+perl5_28
>...
>$ cat /opt/local/etc/gitconfig
>[credential]
>helper = osxkeychain
> 
> Anyone have any idea why this is happening? Can anyone reproduce this?

I just upgraded 
(git-2.31.1_1+credential_osxkeychain+diff_highlight+doc+pcre+perl5_28.darwin_20.x86_64.tbz2)
 and /opt/local/etc/gitconfig is also an empty file on my system:

~ % ls -l /opt/local/etc/gitconfig
-rw-r--r--  1 root  admin  0 15 mei 20:27 /opt/local/etc/gitconfig

~ % mkdir tmp
~ % tar -C tmp -xf 
/opt/local/var/macports/software/git/git-2.31.1_1+credential_osxkeychain+diff_highlight+doc+pcre+perl5_28.darwin_20.x86_64.tbz2
~ % ls -l tmp/opt/local/etc/gitconfig
-rw-r--r--  1 breun  staff  0 15 mei 20:27 tmp/opt/local/etc/gitconfig

After reinstalling the file is still empty on my system:

~ % sudo port uninstall git
~ % sudo port -k install git
(…)
% ls -l /opt/local/etc/gitconfig
~ -rw-r--r--  1 root  admin  0 15 mei 20:38 /opt/local/etc/gitconfig

~ % sw_vers
ProductName:macOS
ProductVersion: 11.3.1
BuildVersion:   20E241

Nils.

Re: Ports updated without maintainer notification?

[Nils Breunese]

Ryan Schmidt  wrote:

> Holding back a library to be compatible with one port may not be the right 
> choice for other ports that depends on the library.

If other ports would want to use the latest version of foo-lib, but Blender 
needs specifically version 1.15 of foo-lib, it might be an idea to have both a 
foo-lib port with the latest version and a foo-lib-1.15 port that Blender can 
then depend on.

Nils.

Re: What in MacPorts decides that files are 'broken'?

[Nils Breunese]

> Op 4 mei 2021 om 03:39 heeft Daniel J. Luke  het volgende 
> geschreven:
> 
> 
>> 
>> On May 3, 2021, at 6:33 PM, Nils Breunese  wrote:
>> I maintain the openjdk* ports. These ports install prebuilt x86_64 binaries 
>> from AdoptOpenJDK. A MacPorts user with an M1 created 
>> https://trac.macports.org/ticket/62802 to report that installing the 
>> openjdk11 port on his machine makes rev-upgrade reports a couple of files in 
>> this port as ‘broken’. I’ve asked the reporter to manually download the 
>> prebuilt x86_64 tarball, and that seems to work fine on his M1 machine.
>> 
>> I am not sure what MacPorts runs that decides these files are broken. Can 
>> anyone tell me more about this?
> 
> 
> That's rev-upgrade, from the manpage (man 1 port-rev-upgrade):
> 
>   port rev-upgrade will check all binaries (i.e., executables and
>   libraries) installed by MacPorts for consistency. If any linking
>   problems such as missing or incompatible libraries are found,
>   rev-upgrade will rebuild broken ports in an attempt to fix the
>   problems.
> 
>   By default, rev-upgrade is run automatically after each installation or
>   upgrade, unless you pass the --no-rev-upgrade option or disable this
>   beahvior in macports.conf(5) using the revupgrade_autorun switch.

Ah, thanks!

What can I do to the Portfile to fix this for M1 users? I don’t get these 
errors on my Intel Mac. Although the prebuilt binary is for x86_64 it runs on 
arm64 as well, as tested by the issue reporter.

The reporter now gets stuck in a rev-upgrade loop. Is there a way to configure 
a port to skip the broken file check? Or will I need to change the Portfile to 
remove the files that got reported as broken from the extracted prebuilt 
archive when running on arm64?

Nils.

What in MacPorts decides that files are 'broken'?

[Nils Breunese]

Hello,

I maintain the openjdk* ports. These ports install prebuilt x86_64 binaries 
from AdoptOpenJDK. A MacPorts user with an M1 created 
https://trac.macports.org/ticket/62802 to report that installing the openjdk11 
port on his machine makes rev-upgrade reports a couple of files in this port as 
‘broken’. I’ve asked the reporter to manually download the prebuilt x86_64 
tarball, and that seems to work fine on his M1 machine.

I am not sure what MacPorts runs that decides these files are broken. Can 
anyone tell me more about this?

Thanks, Nils.

Re: Publicizing MacPorts

[Nils Breunese]

Georges Martin  wrote:

> - What if a port is not building on M1 because upstream is not ready yet? 
> (libffi, openjdk16, ghc comes to mind)

The openjdk16 port in MacPorts indeed doesn’t support arm64 yet, because 
AdoptOpenJDK hasn’t released their arm64 version for macOS yet.

I have added openjdk*-zulu ports for Azul Zulu OpenJDK to MacPorts recently and 
Azul does already provide arm64 versions for macOS: 
https://www.azul.com/downloads/zulu-community/?os=macos=arm-64-bit=jdk
 


I can probably add arm64 versions for openjdk*-zulu when my Mac is back from 
getting a new screen (hopefully next week), although I won’t be able to test 
myself, because I don’t have an M1 machine. Feel free to send a PR for adding 
arm64 ports for Azul Zulu yourself if you can add and test them.

Nils.

Re: 11_x86 build - build failures due to 'no space on device'

[Nils Breunese]

Ryan Schmidt  wrote:

> Both copies of the simulator caches came back again. I filed FB9072613 with 
> Apple about this. We were down to 3GB free disk space which isn't a good 
> place to be. I deleted the caches again and marked the dyld directories chmod 
> 000. Let's see if that prevents Xcode from recreating the caches, hopefully 
> without causing error messages that cause builds to fail. We now have 21GB 
> free.

I recently learned that 'xcrun simctl delete unavailable’ and 'xcrun simctl 
delete all’ exist. Those commands can be used to reclaim disk space in use by 
Xcode simulators. Not sure if they could be of use in this scenario.

Nils.

Re: Desolate Condition

[Nils Breunese]

Karl-Michael Schindler  wrote:

> This indicates the first problem: Brew is often better represented on 
> homepages of other software than MacPorts. The task to tackle is to find a 
> person or form a team going after this.

A more scalable solution would be for port maintainers to check the upstream 
docs for the ports they maintain and contribute a snippet on how to install the 
software via MacPorts if not already present. Usually all this takes is a 
simple merge request. I think this is a great idea and I’ve been doing this for 
my ports.

Examples from the Spring Boot documentation: 
https://docs.spring.io/spring-boot/docs/current/reference/html/getting-started.html#getting-started-macports-cli-installation

People will even start copying these MacPorts installation instructions into 
blog posts and educational materials.

Examples of ’sudo port install kotlin’: 
https://www.google.com/search?q=%22sudo+port+install+kotlin%22

Apparently it was even copied into an O’Reilly book: 
https://www.oreilly.com/library/view/kotlin-programming-by/9781788474542/86027be9-71a7-4afc-8354-51fceeb741d9.xhtml

Nils.

Re: fun fact about ICU +universal

[Nils Breunese]

Ken Cunningham  wrote:

> It's not complaining, it's irony.

I’ve learned that irony doesn’t work very well via e-mail, because irony 
usually requires knowing the author well when communicating via a text-only 
medium, and it is often interpreted as complaining otherwise. I’m sorry to say 
that I also interpreted some of your recent messages as complaining. I think 
your work on MacPorts is greatly appreciated though.

Cheers, Nils.

Re: Desolate Condition

[Nils Breunese]

Christopher Nielsen  wrote:

> One advantage that HomeBrew does have, though, is cachet: There are so many 
> times when articles - or even organizations, such as Google - simply 
> recommend using HomeBrew… with no mention of MacPorts.

I think it’s a great idea to always send pull requests to update upstream docs 
and readme files with installation instructions for MacPorts when you start 
maintaining a port. So, to all maintainers: take a look at the ports you 
maintain and whether the upstream docs and readme have installation 
instructions for MacPorts.

Nils.

Re: [errors] php80

[Nils Breunese]

Nils Breunese  wrote:

> Looking at for instance the Portfile for php-offline (…)

I meant to write php-pdflib, but it got auto-corrupted.

Nils.

Re: [errors] php80

[Nils Breunese]

Bjarne D Mathiesen  wrote:

> When upgrading from php74
> 
> $=> cat php.bash
> #!/opt/local/bin/bash
> 
> phpOld=${1:-74}
> phpNew=${2:-80}
> 
> while read -a portName -u 9
> do
>toInstall="${portName[0]/${phpOld}/${phpNew}}"
>installed=$( port -q installed "${toInstall}" | wc -l )
>[[ ${installed} -eq 0 ]] && port -cuNp install "${toInstall}"
> done 9< <( port -q installed | grep "php${phpOld}" )
> 
> I get the following errors :
> 
> Error: Port php80-event not found
> Error: Port php80-geoip not found
> Error: Port php80-imagick not found
> Error: Port php80-pdflib not found
> Error: Port php80-scrypt not found
> Error: Port php80-vld not found
> Error: Port php80-xmlrpc not found
> Error: Port php80-yaz not found

Looking at for instance the Portfile for php-offline [0] I see 7.4 listed for 
php.branches, but 8.0 isn’t there, so there is no php80-pdflib port at the 
moment and this seems like expected behavior to me.

PHP 8.0 is currently only one month old. I am not familiar with these libraries 
and whether they are compatible with PHP 8.0 yet, but if they are I guess 8.0 
just needs to be added to php.branches for these libs. You could create a merge 
request to add this if they are compatible. I imagine it could also be the case 
that these libs haven’t been updated for PHP 8.0 (yet).

Nils.

[0] 
https://github.com/macports/macports-ports/blob/master/php/php-pdflib/Portfile

Re: Swift Package Manager

[Nils Breunese]

Herby G  wrote:

> > Otherwise MacPorts could just run Artifactory or something to cache and 
> serve dependencies and all would be good.
> 
> Having MacPorts run asset servers or repositories for all the different 
> languages and frameworks out there (like running Artifactory) would be 
> immensely unsustainable.

I know it wouldn’t be a solution for everything in MacPorts. (Artifactory does 
support multiple package types though, including ‘generic’.) It would be nice 
to be able to benefit from a build tool’s native dependency repository support 
when it has that. A man can dream, right? :o)

At my work there is an asset repository server for dependencies for 
Java/Maven/Gradle, Python/PyPi, JavaScript/NPM, RPM, Docker images, etc. It’s 
great when you can just tell a build tool to use a particular repository URL.

Nils.

Re: Swift Package Manager

[Nils Breunese]

Ryan Schmidt  wrote:

> A build system that forces fetching from a specific upstream server reduces 
> our ability to build on older systems, since that specific server might have 
> https requirements that older system can't meet. We need to be able to mirror 
> files on our servers so that older MacPorts clients can download from them.
> 
> Tying us to a specific upstream server also ties us to the reliability of 
> that server. If it goes down, we go down, and users flood us with bug reports 
> about it. We don't want that.

It’s really too bad that even a lot of modern build tools do not have the 
concept of proxyable, cachable) repositories for dependencies. For instance for 
builds that use Maven repositories (Maven, Gradle and some other build tools in 
the Java ecosystem) you can set up your own proxy which fetches dependencies 
when first requested from upstream, stores them for future use and lets you 
control HTTPS settings, availability, etc. This all works because dependencies 
are not identified by a full URL. I believe NPM repositories will let you do 
the same thing for the JavaScript ecosystem.

The pain comes when build tools don’t use a proxyable, cachable repository 
concept (Go, etc.). Otherwise MacPorts could just run Artifactory or something 
to cache and serve dependencies and all would be good. Currently MacPorts is 
bolting this concept onto build tools that don’t have it, and that is indeed 
daunting and cumbersome.

Nils.

Re: port "cask" -- installing prebuilt binaries

[Nils Breunese]

Ken Cunningham  wrote:

>> So, I'm looking to install iTerm2 for old systems from binary as building
>> is becoming increasingly impossible - have we come to a consensus on any of
>> this?
>> 
>> —Mark
>> ___
>> Mark E. Anderson 
>> MacPorts Trac WikiPage 
>> GitHub Profile 
>> 
>> 
>> 
> 
> I continue to believe that in general trying to shoehorn "cask" binary 
> installs as some variant of a port that is generally meant to build from 
> source is a recipe for nothing but endless trouble. Homebrew has a completely 
> different subsystem for cask installs that makes it really clear what you are 
> getting, and this is very desirable, I agree.
> 
> 
> 
> IMHO binary-only install port should have some clearly recognizable port name 
> that does not cause confusion about what it is, and does not obscure or 
> trample a port's existing variants (which a "prebuilt" or other similar 
> variant name would do, if there were other variants). We have port name 
> distinctions for a great many ports in MacPorts now (the perl, python, php, 
> etc, etc, etc port families, for example). Having a naming family for 
> binary-only ports is No Big Deal.
> 
> 
> 
> Chris has suggested a category inclusion, which is pure and uses macports 
> unique functionality, but IMHO is unrecognizable for 99.% of users who 
> would never notice that a given port is added to a certain category or 
> subcategory.
> 
> 
> 
> But we should resolve this, as many people want it, whatever is decided by 
> the managers, who so far have expressed no opinion, ergo it is unresolved.
> 

Why is having binary ports without a special indicator a problem? MacPorts has 
already has ports that use upstream binaries, mostly for ports that are either 
impossible to build from source (Google Cloud SDK source is not available AFAIK 
for instance), or very hard/time-consuming (OpenJDK for instance) to build. I 
maintain a couple of ports like these and they don’t have a specific name or 
variant or anything indicating that they use upstream binaries and I don’t see 
a problem with that really. If someone would ever decide it’s a good idea to 
switch to building OpenJDK from source via a Portfile, that could just be 
transparently done without any users having to switch to a different port name 
or variant, and that seems fine to me.

It might even make sense for some ports (like iTerm2 perhaps?) to build from 
source on macOS versions for which that is feasible, and use an upstream binary 
on OS versions for which it isn’t.

Nils.

Re: macOS Big Sur 11.0.1 crashes when MacPorts tries to install p5.28-locale-gettext

[Nils Breunese]

Ryan Schmidt  wrote:

> You could edit the source code to change 50 to a smaller number and try 
> again. To ensure that your test is not influenced by previously cached 
> entries, delete /opt/local/var/macports/pingtimes before trying again. If you 
> didn't see this problem with other ports that are not perl modules, then 
> presumably there is some smaller number of simultaneous pings that will work.

I’d like to try this. Which file/line do I need to modify for this?

> But it also sounds like it may be a bug in the Carbon Black software you 
> mentioned using.

Nils.

Re: macOS Big Sur 11.0.1 crashes when MacPorts tries to install p5.28-locale-gettext

[Nils Breunese]

Ken Cunningham  wrote:

>> Running ’sudo port fetch p5.28-locale-gettext’ also crashes my machine.
> 
> By manually, I meant using curl or something other than MacPorts to download 
> it, so you can see perhaps where it is going wrong.

I downloaded 
http://cpan.cs.uu.nl/modules/by-authors/id/P/PV/PVANDRY/gettext-1.07.tar.gz 
 
via curl, which worked fine.

% curl -O 
http://cpan.cs.uu.nl/modules/by-authors/id/P/PV/PVANDRY/gettext-1.07.tar.gz 

  % Total% Received % Xferd  Average Speed   TimeTime Time  Current
 Dload  Upload   Total   SpentLeft  Speed
100  8651  100  86510 0   132k  0 --:--:-- --:--:-- --:--:--  132k

I moved that file into /opt/local/var/macports/distfiles/perl5 and changed the 
owner to macports:wheel. I then ran ’sudo port upgrade p5.28-locale-gettext’, 
which now worked!

Nils.

Re: macOS Big Sur 11.0.1 crashes when MacPorts tries to install p5.28-locale-gettext

[Nils Breunese]

Ryan Schmidt  wrote:

> On Nov 13, 2020, at 18:34, Nils Breunese wrote:
> 
>> Nils Breunese wrote:
>> 
>>> Every time MacPorts tries to install the p5.28-locale-gettext port on my 
>>> Big Sur 11.0.1 machine, the OS crashes and the Problem Reporter shows the 
>>> crash report below. Does installing this port work for others on Big Sur 
>>> 11.0.1? Any ideas?
>>> 
>>> [cut]
>> 
>> I can reproduce the crash by running 'sudo port install 
>> p5.28-locale-gettext' and waiting for approximately 3 minutes, which seems 
>> to correspond to the 180 seconds from the error in the crash report 
>> ("panic(cpu 8 caller 0xff8003753a13): userspace watchdog timeout: no 
>> successful checkins from com.apple.remoted in 180 seconds”).
>> 
>> I found this crash also occurs when trying to install p5.28-error, so it 
>> might actually be a problem related to all perl5 modules.
>> 
>> Debug output:
>> 
>> % sudo port -d install p5.28-locale-gettext
>> [cut]
>> --->  Fetching distfiles for p5.28-locale-gettext
>> DEBUG: Executing org.macports.fetch (p5.28-locale-gettext)
>> --->  gettext-1.07.tar.gz does not exist in 
>> /opt/local/var/macports/distfiles/perl5
>> 
>> And then nothing happens for about 3 minutes and then the machine reboots 
>> and comes back with the crash report from the original post.
> 
> Sounds like maybe another consequence of the massive number of processes that 
> MacPorts starts when trying to determine which of the hundreds of perl 
> master_sites is closest to you. See:
> 
> https://trac.macports.org/ticket/60509

I indeed saw about 123 ping processes running while trying to fetch 
p5.28-locale-gettext.

> We added some some code to mitigate that in MacPorts 2.6.3, reducing the 
> number of processes by 2/3:
> 
> https://github.com/macports/macports-base/commit/cee74bb45141be217449c04ee0acd4cb22042dbe
> 
> We added further code to limit the number of processes to 50, but that has 
> only been committed to master, so it is not currently scheduled to appear 
> before MacPorts 2.7.0:
> 
> https://github.com/macports/macports-base/commit/0a000c436ce0f8bc7da7bb34efad896dca6a1e59
> 
> Your log shows you're using MacPorts "2.6.4", which hasn't been released yet, 
> so you must be using the release-2.6 branch. Try either adding the above 
> commit to it or building master instead and see if that helps.

I indeed installed MacPorts on Big Sur 11.0.1 via the latest state of the 
release-2.6 branch, because the 2.6.3 release failed to build.

I just installed MacPorts from master and indeed saw the number of ping 
processes was limited to 50 now. But my machine still crashed after hanging for 
3 minutes on '--->  gettext-1.07.tar.gz does not exist in 
/opt/local/var/macports/distfiles/perl5’.

Nils.

Re: macOS Big Sur 11.0.1 crashes when MacPorts tries to install p5.28-locale-gettext

[Nils Breunese]

Jan Trtík  wrote:

>> 14. 11. 2020 v 17:43, Nils Breunese mailto:n...@breun.nl>>:
>> 
>> No, I don’t have Little Snitch installed.
> 
> and another network filter or antivirus software?
> 
> from the crashlog in your first mail it seems that something is hooked to 
> EndpointSecurity
> 
> @nke.applicationfirewall  310
> |IOKitRegistryCompatibility   1
> |EndpointSecurity 1

This machine is managed by my employer. It think it runs Carbon Black 
(https://www.carbonblack.com <https://www.carbonblack.com/>), which might be 
relevant?

Nils.

Re: macOS Big Sur 11.0.1 crashes when MacPorts tries to install p5.28-locale-gettext

[Nils Breunese]

Ken Cunningham  wrote:

> you're timing out downloading perl modules...
> 
> try downloading a few manually to see what's going on, perhaps

Running ’sudo port fetch p5.28-locale-gettext’ also crashes my machine.

Nils.

Re: macOS Big Sur 11.0.1 crashes when MacPorts tries to install p5.28-locale-gettext

[Nils Breunese]

Jan Trtík  wrote:

> do you have, by any chance, Little Snitch installed on your computer? 
> I had same problem and it went away as soon as I removed it… I am still 
> trying to find out what exactly does trigger this issue, but this at least 
> allowed me to migrate MacPorts to macOS 11.

No, I don’t have Little Snitch installed.

Nils.

Re: macOS Big Sur 11.0.1 crashes when MacPorts tries to install p5.28-locale-gettext

[Nils Breunese]

Nils Breunese  wrote:

> Every time MacPorts tries to install the p5.28-locale-gettext port on my Big 
> Sur 11.0.1 machine, the OS crashes and the Problem Reporter shows the crash 
> report below. Does installing this port work for others on Big Sur 11.0.1? 
> Any ideas?
> 
> [cut]

I can reproduce the crash by running 'sudo port install p5.28-locale-gettext' 
and waiting for approximately 3 minutes, which seems to correspond to the 180 
seconds from the error in the crash report ("panic(cpu 8 caller 
0xff8003753a13): userspace watchdog timeout: no successful checkins from 
com.apple.remoted in 180 seconds”).

I found this crash also occurs when trying to install p5.28-error, so it might 
actually be a problem related to all perl5 modules.

Debug output:

% sudo port -d install p5.28-locale-gettext
DEBUG: Copying /Users/nbreunese/Library/Preferences/com.apple.dt.Xcode.plist to 
/opt/local/var/macports/home/Library/Preferences
DEBUG: Changing to port directory: 
/opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/ports/perl/p5-locale-gettext
DEBUG: OS darwin/20.1.0 (macOS 11.0) arch i386
DEBUG: Sourcing PortGroup compiler_blacklist_versions 1.0 from 
/opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/ports/_resources/port1.0/group/compiler_blacklist_versions-1.0.tcl
DEBUG: Re-registering default for configure.universal_args
DEBUG: Sourcing PortGroup perl5 1.0 from 
/opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/ports/_resources/port1.0/group/perl5-1.0.tcl
DEBUG: Sourcing PortGroup clang_dependency 1.0 from 
/opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/ports/_resources/port1.0/group/clang_dependency-1.0.tcl
DEBUG: Re-registering default for livecheck.version
DEBUG: adding the default universal variant
DEBUG: Reading variant descriptions from 
/opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/ports/_resources/port1.0/variant_descriptions.conf
DEBUG: Running callback portconfigure::add_automatic_compiler_dependencies
DEBUG: Finished running callback 
portconfigure::add_automatic_compiler_dependencies
DEBUG: Running callback portbuild::add_automatic_buildsystem_dependencies
DEBUG: Finished running callback 
portbuild::add_automatic_buildsystem_dependencies
DEBUG: Running callback portstartupitem::add_notes
DEBUG: Finished running callback portstartupitem::add_notes
DEBUG: dropping privileges: euid changed to 502, egid changed to 501.
DEBUG: Starting logging for p5.28-locale-gettext
DEBUG: macOS 11.0 (darwin/20.1.0) arch i386
DEBUG: MacPorts 2.6.4
DEBUG: Xcode 12.2
DEBUG: SDK 11.0
DEBUG: MACOSX_DEPLOYMENT_TARGET: 11.0
DEBUG: epoch: in tree: 0 installed: 0
DEBUG: perl5.28 5.28.3_0 exists in the ports tree
DEBUG: perl5.28 5.28.3_0  is the latest installed
DEBUG: perl5.28 5.28.3_0  is active
DEBUG: Merging existing variants '' into variants
DEBUG: new fully merged portvariants:
DEBUG: Changing to port directory: 
/opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/ports/lang/perl5
DEBUG: OS darwin/20.1.0 (macOS 11.0) arch i386
DEBUG: Re-registering default for configure.universal_args
DEBUG: Sourcing PortGroup perl5 1.0 from 
/opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/ports/_resources/port1.0/group/perl5-1.0.tcl
DEBUG: Sourcing PortGroup clang_dependency 1.0 from 
/opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/ports/_resources/port1.0/group/clang_dependency-1.0.tcl
DEBUG: adding the default universal variant
DEBUG: Reading variant descriptions from 
/opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/ports/_resources/port1.0/variant_descriptions.conf
DEBUG: Running callback portconfigure::add_automatic_compiler_dependencies
DEBUG: Finished running callback 
portconfigure::add_automatic_compiler_dependencies
DEBUG: Running callback portbuild::add_automatic_buildsystem_dependencies
DEBUG: Finished running callback 
portbuild::add_automatic_buildsystem_dependencies
DEBUG: Running callback portstartupitem::add_notes
DEBUG: Finished running callback portstartupitem::add_notes
DEBUG: No need to upgrade! perl5.28 5.28.3_0 >= perl5.28 5.28.3_0
DEBUG: epoch: in tree: 0 installed: 0
DEBUG: db48 4.8.30_4 exists in the ports tree
DEBUG: db48 4.8.30_4  is the latest installed
DEBUG: db48 4.8.30_4  is active
DEBUG: Merging existing variants '' into variants
DEBUG: new fully merged portvariants:
DEBUG: Changing to port directory: 
/opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/ports/databases/db48
DEBUG: OS darwin/20.1.0 (macOS 11.0) arch i386
DEBUG: Reading variant descriptions from 
/opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/ports/_resources/port1.0/variant_descriptions.conf
DEBUG: Sourcing PortGroup muniversal 1.0 from 
/opt/local/var/macports/sources/rsync.macports.org/macpo

macOS Big Sur 11.0.1 crashes when MacPorts tries to install p5.28-locale-gettext

[Nils Breunese]

Hello,

Every time MacPorts tries to install the p5.28-locale-gettext port on my Big 
Sur 11.0.1 machine, the OS crashes and the Problem Reporter shows the crash 
report below. Does installing this port work for others on Big Sur 11.0.1? Any 
ideas?

Nils Breunese.

——

panic(cpu 8 caller 0xff8003753a13): userspace watchdog timeout: no 
successful checkins from com.apple.remoted in 180 seconds
service returned not alive with context : unresponsive work processor(s): 
remoted heartbeat on bridge 
service: com.apple.logd, total successful checkins since load (800 seconds 
ago): 81, last successful checkin: 0 seconds ago
service: com.apple.WindowServer, total successful checkins since load (770 
seconds ago): 77, last successful checkin: 0 seconds ago
service: com.apple.remoted, total successful checkins since load (800 seconds 
ago): 61, last successful checkin: 180 seconds ago

Backtrace (CPU 8), Frame : Return Address
0xffa0af363670 : 0xff80004bc66d 
0xffa0af3636c0 : 0xff80005ff073 
0xffa0af363700 : 0xff80005ef6aa 
0xffa0af363750 : 0xff8000461a2f 
0xffa0af363770 : 0xff80004bbf0d 
0xffa0af363890 : 0xff80004bc1f8 
0xffa0af363900 : 0xff8000cbee84 
0xffa0af363970 : 0xff8003753a13 
0xffa0af363980 : 0xff80037536ba 
0xffa0af3639a0 : 0xff8000c460ee 
0xffa0af3639f0 : 0xff8003752b0a 
0xffa0af363b20 : 0xff8000c502bb 
0xffa0af363c80 : 0xff80005aaa61 
0xffa0af363d90 : 0xff80004c1d77 
0xffa0af363e00 : 0xff80004985d5 
0xffa0af363e60 : 0xff80004afb82 
0xffa0af363ef0 : 0xff80005d3823 
0xffa0af363fa0 : 0xff8000462216 
  Kernel Extensions in backtrace:
 
com.apple.driver.watchdog(1.0)[7948A279-A8B8-3650-AFBF-B1E3EB68942A]@0xff8003752000->0xff8003753fff

Process name corresponding to current thread: watchdogd
Boot args: chunklist-security-epoch=0 -chunklist-no-rev2-dev

Mac OS version:
20B29

Kernel version:
Darwin Kernel Version 20.1.0: Sat Oct 31 00:07:11 PDT 2020; 
root:xnu-7195.50.7~2/RELEASE_X86_64
Kernel UUID: 84C6DC45-6B02-335F-9439-5D2A9BC385A4
KernelCache slide: 0x0020
KernelCache base:  0xff800040
Kernel slide:  0x0021
Kernel text base:  0xff800041
__HIB  text base: 0xff800030
System model name: MacBookPro16,1 (Mac-E1008331FDC96864)
System shutdown begun: NO
Hibernation exit count: 0

System uptime in nanoseconds: 814426222551
Last Sleep:   absolute   base_tsc  base_nano
  Uptime  : 0x00bd9f95f9ce
  Sleep   : 0x 0x 0x
  Wake: 0x 0x000df35d5870 0x
last started kext at 22473489130: >AudioAUUC1.70 (addr 0xff7f9fbd5000, 
size 12288)
last stopped kext at 288586604576: >usb.!UHostPacketFilter  1.0 (addr 
0xff8003246000, size 8192)
loaded kexts:
com.cisco.kext.acsock   4.8.0
>AudioAUUC  1.70
>!ATopCaseHIDEventDriver4000.27
>!AHIDALSService1
>AGPM   119
>!APlatformEnabler  2.7.0d0
>X86PlatformShim1.0.0
@filesystems.autofs 3.0
@fileutil   20.036.15
@kext.AMDRadeonX60004.0.0
@kext.AMDRadeonServiceManager   4.0.0
>!AUpstreamUserClient   3.6.8
>!AGraphicsDevicePolicy 6.1.27
>AGDCBacklightControl   6.1.27
>!A!IKBLGraphics16.0.0
@AGDCPluginDisplayMetrics   6.1.27
>pmtelemetry1
>LuaHardwareAccess  1.0.16
|IOUserEthernet 1.0.1
>!AMCCSControl  1.14
>!ABridgeAudio!C100.2
|IO!BSerialManager  8.0.1f5
>!AGFXHDA   100.1.431
>!A!ICFLGraphicsFramebuffer 16.0.0
>!AMuxControl2  6.1.27
>!A!IPCHPMC 2.0.1
@Dont_Steal_Mac_OS_X7.0.0
>!AHV   1
>!ADiskImages2  1
>BridgeAudioCommunication   100.2
>!AAVEBridge6.1
>!AThunderboltIP4.0.3
>!A!ISlowAdaptiveClocking   4.0.0
>usb.!UHostBillboardDevice  1.0
>BCMWLANFirmware4378.Hashstore  1
>BCMWLANFirmware4377.Hashstore  1
>BCMWLANFirmware4364.Hashstore  1
>BCMWLANFirmware4355.Hashstore  1
>!ABCMWLANBusInterfacePCIeMac   1
@filesystems.tmpfs  1
@filesystems.hfs.kext   556.41.1
@BootCache  40
@filesystems.apfs   1677.50.1
@!AFSCompression.!AFSCompressionTypeZlib1.0.0
@!AFSCompression.!AFSCompressionTypeDataless1.0.0d1
@private.KextAudit  1.0
>!ASmartBatteryManager  161.0.0
>!AACPIButtons  6.1
>!ASMBIOS   2.1
>!AACPIEC   6.1
>!AAPIC 1.7
@!ASystemPolicy 2.0.0
@nke.applicationfirewall310
|IOKitRegistryCompatibility 1
|EndpointSecurity   1
>!AHS!BDriver   4000.27
>IO!BHIDDriver  8.0.1f5
>!AHIDKeyboard  222
>!AActuatorDriver   4400.28
>!AMultitouchDriver 4400.28
>!AInputDeviceSupport   4400.35
@kext.triggers  1.0
@kext.AMDRadeonX6100HWLibs  1.0
@kext.AMDRadeonX6000Framebuffer 4.0.0
>!ABacklightExpert  1.1.0
@kext.AMDSupport4.0.0
>!ASMBus

Re: Updating OpenSSH port to 8.4p1

[Nils Breunese]

Blake Garner  wrote:

> Successfully rolled the version of openssh to 8.4p1 and incremented the port 
> revision to 10.

I see the Portfile Reference [0] doesn’t mention this, but when you increment 
the version, the revision should be reset to 0. Bumping the revision should 
only happen when making changes to a Portfile that impact users, while the 
version of the software that gets installed stays the same.

Nils.

[0] https://guide.macports.org/chunked/reference.html

Re: How to abort a macports portfile on an error condition?

[Nils Breunese]

There is also ‘known_fail yes’, which I see getting combined with ‘return -code 
error’: https://trac.macports.org/ticket/60566

I’m not familiar with the precise differences between known_fail, ui_error and 
return -code error.

Nils.

> Op 3 okt. 2020, om 12:30 heeft Eric F  het volgende 
> geschreven:
> 
> Try using “return -code error”, something like:
> 
> ```tlc
> if {![file exists ${prefix}/bin/perl]} {
> ui_error "
> «${prefix}/bin/perl» is missing but the linuxdoc-tools depends on it.
> 
> Please create an appropriate symbolic link for linuxdoc-tools to work.
> "
> return -code error "missing dependency"
> }
> ```
> 
> · Eric
> 
> On 10/3/20 11:15 , Martin Krischik wrote:
>> Hello,
>> 
>> I working on a version bump on the **cc65** and encountered a problem
>> with the **linuxdoc-tools**. Since I can't fix the **linuxdoc-tools**
>> and there is a simple workaround possible I decided to add an if
>> statement to inform the user together with the workaround:
>> 
>> ```tlc
>>  if {! [file exists ${prefix}/bin/perl] } {
>>  ui_error "
>> «${prefix}/bin/perl» is missing but the linuxdoc-tools depends on it.
>> 
>> Please create an appropriate symbolic link for linuxdoc-tools to work.
>> "
>>  exit 1
>>  }
>> ```
>> 
>> Crude but the best I can do since I'm neither the **perl5** nor the
>> **linuxdoc-tools** maintainer and I don't want to spend to much time on
>> a otherwise simple version bump.
>> 
>> However, the MacPorts doesn't understand `exit 1` and `ui_error` won't
>> stop execution on its own.
>> 
>> How do I stop the execution so not to waste the users time on a build
>> which will otherwise fail right at the end.
>> 
>> Regards
>> 
>> Martin
>> 
> 

Re: supertuxkart non-redistributable?

[Nils Breunese]

Ken Cunningham  wrote:

> Just curious what makes this port non-redistributable….
> 
> it’s likely a pain for users to have to build it.

I don’t know, but Linux distributions like Fedora Linux are distributing binary 
packages for supertuxkart:

http://mirrors.kernel.org/fedora/releases/32/Everything/x86_64/os/Packages/s/supertuxkart-1.1-3.fc32.x86_64.rpm
http://mirrors.kernel.org/fedora/releases/32/Everything/x86_64/os/Packages/s/supertuxkart-data-1.1-3.fc32.noarch.rpm

Nils.

Re: port "cask" -- installing prebuilt binaries

[Nils Breunese]

OpenJDK is open source, so it can be built from source. However, it is quite a 
complex and lengthy build. As the maintainer of the openjdk* ports I decided to 
use the binaries provided by the AdoptOpenJDK (for the HotSpot VM and OpenJ9 VM 
based JDK’s) and GraalVM projects. I personally wouldn’t want to replicate 
their builds in MacPorts and I don’t think anyone would enjoy waiting for 
MacPorts to build OpenJDK from source on their machine, because that can take a 
couple of hours. But theoretically the openjdk* ports could be changed to build 
from source. If anyone wants to have a go at that, be my guest!

Nils.

> Op 7 aug. 2020 om 10:09 heeft Georges Martin  het 
> volgende geschreven:
> 
> Good point.
> 
> And I just updated postgresql-jdbc, which depends on binary-only openjdk*... 
> :-|
> 
>> Le 7 août 2020 à 08:59, Ryan Schmidt  a écrit :
>> 
>> 
>> 
 On Aug 5, 2020, at 07:52, Georges Martin wrote:
>>> 
>>> If MacPorts starts to mix both approaches, I worry we may end up having 
>>> (open source) packages depending on closed source, binary packages.
>> 
>> We already have that, by necessity. For example, php-excel is an open source 
>> php module that depends on the closed-source libxl library, for which we 
>> have a port. php-oracle, an open source php module distributed as part of 
>> php itself, depends on the closed-source oracle-instantclient library, for 
>> which we have a port.

Re: port "cask" -- installing prebuilt binaries

[Nils Breunese]

I already maintain some ports that install binaries from upstream, like the 
openjdk* ports, which are very complex to build from source and take many, many 
hours to build.

I also maintain some Go ports that build from source, but that are not 
available on some older OS versions because the go compiler doesn’t seem to be 
available for those older OS versions. See for instance 
https://ports.macports.org/port/kustomize and 
https://ports.macports.org/port/skaffold/summary. I wonder if those application 
would work on those older OS versions if I would switch those ports to install 
binaries from upstream.

Nils.

> Op 4 aug. 2020 om 19:48 heeft Ruben Di Battista  
> het volgende geschreven:
> 
> 
> There's is one compelling need for having "binary only" install, and that is 
> for the port "osxfuse", that is currently broken for 10.14+.
> 
> There was a discussion about it on the Github project about the choice of 
> making it close closed source... Nonetheless it would be useful to have it in 
> order to provide things like fuse file systems and so on.
> 
> 
> 
>> On Tue, 4 Aug 2020, 15:38 Lothar Haeger,  wrote:
>> 
>> 
>>> Am 30.07.2020 um 08:03 schrieb Ken Cunningham 
>>> :
>>> I only raise the idea as people are already doing this, and submitting such 
>>> ports, and before we have too many, there is an opportunity to say how it 
>>> should best be done (custom category, naming convention, etc).
>> Reminds me of an earlier conversation at 
>> https://github.com/macports/macports-ports/pull/6767#discussion_r402584006 
>> 
>> I do see some benefits is formalizing binary-only ports and to adapt the 
>> build and distribution scheme for it. Could save resources and development 
>> time and make those ports easily recognizable for those who care about the 
>> different way it was built.
>> 
>> 

Re: macos as vm guest

[Nils Breunese]

Michael wrote:

> Yes, there's one that will force your boot drive to APFS. So if you need to 
> use older systems (I have 32 bit programs that have no 64 bit replacement. I 
> use Jack Router when streaming and recording.), that means that at least a 
> significant portion of your system and home directory/files will be forced 
> into a drive that cannot be shared (and it seems that the newer the system, 
> the tighter the sandbox/the less you can put outside of /Users/ or 
> on a second partition.)

I have 10.15 and 10.14 (for some apps that are 32-bit only) installed on the 
same machine, and I didn’t even need to think about partitions, because storage 
space is shared across APFS volumes: https://support.apple.com/en-us/HT208891

Nils.

Re: randomly bumping things to require perl 5.30 vs 5.28 requires everyone to have both installed ...

[Nils Breunese]

Jason Liu  wrote:

> Would it be possible to sort of split the difference? i.e. not _just_ have 
> one single perl5 port and get rid of all the individual point releases, but 
> rather to add perl5 as a sort of "metapackage" that is essentially the same 
> as perl5.30. I guess metapackage isn't the right word, either. In reality 
> more like, it's the same package as perl5.30, but simply with a more generic 
> name that maps to whatever specific release has been blessed as the MacPorts 
> default perl. So, these ports would all exist:
> 
> perl5 <= the "metapackage", and is actually the same port as perl5.30, 
> perl5.32, or whatever is deemed to be the current MacPorts default perl.
> perl5.30
> perl5.28
> perl5.26
> ...
> So if a particular port is okay with blindly using a version of perl that 
> tracks with the latest MacPorts default perl, they can use perl5. If a port 
> breaks when the MacPorts default perl gets changed, then the port could still 
> revert back to specifying a specific version of perl, by simply changing the 
> perl5 to perl5.28.

There already is a perl5 wrapper port: 
https://ports.macports.org/port/perl5/summary

Its version is currently 5.26.1 and it has perl5_26, perl5_28 and perl5_30 
variants.

Nils.

Re: Announcement: System fonts port tree

[Nils Breunese]

Aaron Madlon-Kay  wrote:

> - Why make this?
> 
> I like to keep my fonts up to date, and MacPorts is a great way to do so.

I love this idea!

> I asked about including system font ports in the default ports tree a long 
> time ago on the dev list. The main problem is that it’s not “nice” to put the 
> install files outside of the blessed MacPorts directories ($prefix, 
> /Applications/MacPorts, etc.), so some sort of mechanism that symlinks to 
> /Library/Fonts would need to be developed.

Is the fact that it’s not “nice” to install files outside of the blessed 
directories reason enough to keep these ports out of the official ports tree? 
For fonts to work on macOS they need to be in a directory where macOS will look 
for them. I don’t really see the point of putting them in another directory and 
then creating symlinks outside the MacPorts tree.

I maintain the openjdk* ports and those install their files under 
/Library/Java/JavaVirtualMachines, because that’s where the macOS Java tools 
(like /usr/libexec/java_home) will look for Java Virtual Machines. These font 
ports sound like a pretty similar case to me.

Nils.

Re: Looking for help with kustomize port (Go)

[Nils Breunese]

Nils Breunese  wrote:

> Thanks. I know actually about this mechanism, but I guess I should have 
> specified that I don’t know how to find out what the exact names of the flags 
> are that I should set. Is there an easy way to find out? Should I go and read 
> the source code? Or ask the developers?

Ok, I finally figured it out myself. The problem wasn’t the ldflags, but 
another build argument. I created a new pull request for kustomize now: 
https://github.com/macports/macports-ports/pull/7069

Nils.

Re: Looking for help with kustomize port (Go)

[Nils Breunese]

Aaron Madlon-Kay  wrote:

> It's common in Go to specify version strings as linker flags. Grep the
> ports tree like so to see existing ports that successfully set these
> flags. It's not uncommon to use the string 'unknown' for e.g. the git
> commit when it is redundant or not readily available.
> 
> % grep -R -- "-ldflags '-X" .
> ./devel/git-sizer/Portfile:build.args  -ldflags '-X
> main.BuildVersion=${version}'
> ./devel/shfmt/Portfile:build.pre_args  -ldflags '-X 
> main.version=${version}'
> ./security/mkcert/Portfile:build.args  -ldflags '-X
> main.Version=${version}'
> ./www/minio-mc/Portfile:  -ldflags '-X 
> ${goproj}/cmd.Version=${relversion} \
> ./www/minio/Portfile:  -ldflags '-X ${goproj}/cmd.Version=${relversion} \
> Aarons-MBP:macports-ports amake% grep -R -- "-ldflags.*-X" .
> ./devel/git-sizer/Portfile:build.args  -ldflags '-X
> main.BuildVersion=${version}'
> ./devel/shfmt/Portfile:build.pre_args  -ldflags '-X 
> main.version=${version}'
> ./security/mkcert/Portfile:build.args  -ldflags '-X
> main.Version=${version}'
> ./www/minio-mc/Portfile:  -ldflags '-X 
> ${goproj}/cmd.Version=${relversion} \
> ./www/minio/Portfile:  -ldflags '-X ${goproj}/cmd.Version=${relversion} \
> ./www/caddy/Portfile:build.args  -ldflags \"-X
> ${go.package}/${name}/caddymain.gitTag=v${version}\"
> ./sysutils/go2port/Portfile:build.args  -ldflags "'-X
> main.version=${version}'"
> ./sysutils/go2port/Portfile~:build.args  -ldflags "'-X
> main.version=${version}'"
> ./sysutils/chezmoi/Portfile:build.args  -ldflags \"-X
> main.version=${version} -X main.builtBy=macports\"

Thanks. I know actually about this mechanism, but I guess I should have 
specified that I don’t know how to find out what the exact names of the flags 
are that I should set. Is there an easy way to find out? Should I go and read 
the source code? Or ask the developers?

Nils.

Re: Looking for help with kustomize port (Go)

[Nils Breunese]

Nils Breunese  wrote:

>> Op 28 apr. 2020 om 06:30 heeft Ryan Schmidt  het 
>> volgende geschreven:
>> 
>>> On Apr 27, 2020, at 09:46, Nils Breunese wrote:
>>> 
>>> I couldn’t figure out how to make MacPorts do the equivalent of ‘cd 
>>> kustomize’ after unpacking the archive 
>> 
>> Perhaps you want:
>> 
>> build.dir${worksrcpath}/kustomize
> 
> Thanks, that was indeed also suggested to me via GitHub and turned out to 
> work. I was previously trying to override worksrcpath itself (I remember 
> going through the Docs for the build.* settings, but managed to miss this one 
> apparently). I’ve got some Go-specific ldflags left to fix, but at least it 
> builds and runs now.

I have a working Portfile for Kustomize [0] at 
https://github.com/breun/macports-ports/blob/kustomize-from-source/devel/kustomize/Portfile
 which builds and installs a working `kustomize` binary, but I believe I still 
need to set the correct flags to correctly set the version, because currently 
the output of 'kustomize version’ is this:


% kustomize version
Version: {KustomizeVersion:unknown GitCommit:$Format:%H$ 
BuildDate:1970-01-01T00:00:00Z GoOs:darwin GoArch:amd64}


I’d like at least KustomizeVersion to have a value, BuildDate would be nice as 
well. GitCommit might not be doable when building from a source tarball. I 
tried adding the flags that are also set by the kustomize Homebrew formula [1], 
but they don't seem to have any effect.

Anyone familiar enough with Go builds to tell me how to fix this?

Thanks, Nils.

[0] https://github.com/kubernetes-sigs/kustomize
[1] 
https://github.com/Homebrew/homebrew-core/blob/master/Formula/kustomize.rb#L23

Re: Looking for help with kustomize port (Go)

[Nils Breunese]

> Op 28 apr. 2020 om 06:30 heeft Ryan Schmidt  het 
> volgende geschreven:
> 
>> On Apr 27, 2020, at 09:46, Nils Breunese wrote:
>> 
>> I couldn’t figure out how to make MacPorts do the equivalent of ‘cd 
>> kustomize’ after unpacking the archive 
> 
> Perhaps you want:
> 
> build.dir${worksrcpath}/kustomize

Thanks, that was indeed also suggested to me via GitHub and turned out to work. 
I was previously trying to override worksrcpath itself (I remember going 
through the Docs for the build.* settings, but managed to miss this one 
apparently). I’ve got some Go-specific ldflags left to fix, but at least it 
builds and runs now.

Nils.

Looking for help with kustomize port (Go)

[Nils Breunese]

Hello,

I was looking for kustomize [0] in MacPorts and when I didn’t find it, I 
decided to try to create a port for it myself. Although I already maintain a 
couple of other Go-based ports I couldn’t get this one to work, so I decided to 
use the pre-built binary [1] for now.

I submitted this as a pull request [2] and got the feedback that a port that 
builds from source is preferred. The main issue I have when trying a Portfile 
that builds from source is that the build instructions [4] say to go into the 
kustomize subdir in the archive and run 'go install .’. I couldn’t figure out 
how to make MacPorts do the equivalent of ‘cd kustomize’ after unpacking the 
archive and I also don’t think ‘go install .’ is the command that should be 
run, because that tries to install the file into ~/go/bin.

Maybe someone who is a bit more familiar with Go could take a look at my 
initial attempt to build from source and modify it to work? I would be fine 
with maintaining it for updates afterwards.

Nils.

[0] https://kustomize.io
[1] 
https://github.com/breun/macports-ports/blob/kustomize-3.5.4/devel/kustomize/Portfile
[2] https://github.com/macports/macports-ports/pull/6875
[3] 
https://github.com/breun/macports-ports/blob/kustomize-from-source/devel/kustomize/Portfile
[4] 
https://github.com/kubernetes-sigs/kustomize/blob/master/docs/INSTALL.md#build-the-kustomize-cli-from-local-source

Re: Port ehcache Issue #60219

[Nils Breunese]

Ryan Schmidt wrote:

> On Apr 2, 2020, at 09:39, SAPTARSHI MUKHERJEE wrote:
> 
>> Thanks again for assigning to me the issue #60219 related to port ehcache. 
>> It helped me develop a much better understanding about a few things related 
>> to the portfile and the ports. 
>> 
>> I've made the necessary changes that fetches the new jar file appropriately, 
>> checks with updated checksum values correctly, and I've removed the Kaffe 
>> dependency, replacing it with the Java Portgroup. It has given expected 
>> results on testing, however following are few things that I'd like to know:-
>> 
>> 1) Does this port still need to depend on apache-ant? Facing an error in 
>> apache-ant, I've removed the statement, which helped me get rid of the 
>> build-related error. If the apache-ant still needs to be retained, I'll have 
>> to look into it to fix the error that was like "Command failed : ant clean 
>> dist". Please tell me if the dependency becomes redundant after inclusion of 
>> Java portgroup or is still important.
> 
> The Java portgroup doesn't mention anything about ant, so I don't know. If 
> the port builds in trace mode without a dependency on ant then I guess it 
> doesn't need it anymore. You can also consult any installation documentation 
> that this project might provide; hopefully they would tell you what their 
> dependencies are.

The current Portfile for the EhCache library at 
https://github.com/macports/macports-ports/blob/master/java/ehcache/Portfile is 
for version 1.1, which is pretty ancient. According to 
https://search.maven.org/artifact/net.sf.ehcache/ehcache EhCache 1.2 was added 
to the Maven Central repository on April 26, 2006. So EhCache 1.1 will be older 
than that.

EhCache 2.x used Maven 2 to build: 
https://www.ehcache.org/documentation/2.7/get-started/building.html

According to https://www.ehcache.org/downloads/ the current version of EhCache 
is 3.8.1. Looking at https://github.com/ehcache/ehcache3 EhCache 3.x uses 
Gradle Wrapper to build from source. Running something like `./gradlew build` 
should work, requiring only a Java Development Kit (JDK) to be installed. If 
the new Portfile fetches a pre-built JAR using one of the download links from 
https://www.ehcache.org/downloads/ then there is nothing to build.

I’m a Java developer myself and I actually wouldn’t know what Java developer 
these days would use a package manager like MacPorts to install a library. The 
popular Java build tools (Maven, Gradle) fetch their dependencies from Maven 
repositories.

According to `port echo depends:ehcache` there are no ports that depend on the 
ehcache port that is currently in MacPorts, so I actually think it would be 
better to remove a port like this from MacPorts.

Nils.

Re: Gitlab

[Nils Breunese]

Mark Brethen  wrote:

> How would you set up a portfile to fetch from gitlab? Example: 
> https://gitlab.com/DavidGriffith/frotz

There are tarballs with source code available from 
https://gitlab.com/DavidGriffith/frotz/-/releases

I maintain the gitlab-runner port which is also built from such a tarball: 
https://github.com/macports/macports-ports/blob/master/devel/gitlab-runner/Portfile

Nils.

Re: Update with same filename but different URL path not picked up

[Nils Breunese]

Mojca Miklavec  wrote:

> On Fri, 8 Nov 2019 at 21:53, Nils Breunese wrote:
>> 
>> Hello,
>> 
>> I’m the maintainer for AdoptOpenJDK in MacPorts and I'm trying to update the 
>> OpenJ9-based OpenJDK subports. The URL's for the patched files have a 
>> different path, but the filenames themselves are the same as the current 
>> one. (Yes, AdoptOpenJDK should have updated the filenames as well, and they 
>> will in the future.)
>> 
>> Example subport: openjdk8-openj9
>> Currently in MacPorts: 
>> https://github.com/AdoptOpenJDK/openjdk8-binaries/releases/download/jdk8u232-b09_openj9-0.17.0/OpenJDK8U-jdk_x64_mac_openj9_8u232b09_openj9-0.17.0.tar.gz
>> Newer patched version: 
>> https://github.com/AdoptOpenJDK/openjdk8-binaries/releases/download/jdk8u232-b09.1_openj9-0.17.0/OpenJDK8U-jdk_x64_mac_openj9_8u232b09_openj9-0.17.0.tar.gz
>> 
>> When I update master_sites to include ‘.1' it seems MacPorts doesn’t care 
>> that the URL path has changed and uses the previous version. I guess this is 
>> because files are cached/mirrored based on filename only? Is there any way 
>> around this?
> 
> Yes, follow the procedure for stealth updates:
>https://trac.macports.org/wiki/PortfileRecipes#stealth-updates

That seems to work, thanks!

Nils.

Update with same filename but different URL path not picked up

[Nils Breunese]

Hello,

I’m the maintainer for AdoptOpenJDK in MacPorts and I'm trying to update the 
OpenJ9-based OpenJDK subports. The URL's for the patched files have a different 
path, but the filenames themselves are the same as the current one. (Yes, 
AdoptOpenJDK should have updated the filenames as well, and they will in the 
future.)

Example subport: openjdk8-openj9
Currently in MacPorts: 
https://github.com/AdoptOpenJDK/openjdk8-binaries/releases/download/jdk8u232-b09_openj9-0.17.0/OpenJDK8U-jdk_x64_mac_openj9_8u232b09_openj9-0.17.0.tar.gz
Newer patched version: 
https://github.com/AdoptOpenJDK/openjdk8-binaries/releases/download/jdk8u232-b09.1_openj9-0.17.0/OpenJDK8U-jdk_x64_mac_openj9_8u232b09_openj9-0.17.0.tar.gz

When I update master_sites to include ‘.1' it seems MacPorts doesn’t care that 
the URL path has changed and uses the previous version. I guess this is because 
files are cached/mirrored based on filename only? Is there any way around this?

Nils.

Re: MacPorts Catalina

[Nils Breunese]

Mark Anderson  wrote:

> Sorry I was a bit short there. What I mean is to use the mailing list. I’m 
> not certain when we’re going to release the 10.15 installer. My best advice 
> for now is to install it from source using the 2.6.0 tag on the macports-base 
> repo.

2.6.1 is current. You should be able to follow these instructions to install 
from source AFAIK (haven’t upgraded myself yet): 
https://www.macports.org/install.php#source

Nils.

Re: 10.7 buildbot disk space issues

[Nils Breunese]

> Christopher Jones  wrote:

>> I've previously used Grand Perspective to examine the disk space usage of 
>> the build machines and didn't see anything big, but it turns out Grand 
>> Perspective doesn't include items whose names begin with a period, and 
>> that's where the problem was: the .Spotlight-V100 directory on the 10.7 
>> builder was 36GiB the first time I looked and 26GiB the second time I 
>> looked, and on the 10.8 builder it was 16GiB. I've deleted the Spotlight 
>> indexes on all the builders and hopefully when they're done rebuilding 
>> they'll be smaller.
> 
> I wouldn’t use applications like that for this sort of thing, for that very 
> reason. Then tend to try and be just a bit too clever for my tastes.
> 
> In the end, I tend to just rely on good old dumb ‘df -h’ … 

I’d recommend using ncdu for this. It’s a brilliant CLI tool to drill down when 
looking for what is using a lot of space and MacPorts has a port for it. ;o)

Nils.

Re: Slack-like chat (also for GSOC)

[Nils Breunese]

Chris jones wrote:

> ( The main problem I have, is not something specific to Riot or whatever 
> forum we use, but more we need to perhaps give some thought to the channels. 
> Currently there is really only one, which gets (some) chat but also messages 
> for each and every commit. I don't think the average user needs to see each 
> and every commit. I think we probably need to split these, for instance into 
> Dev and User channels, to match the mailing lists perhaps. )

I’d go even more granular: create a dedicated channel for commits and everyone 
can decide whether to follow that or not.

Nils.

Re: Slack-like chat (also for GSOC)

[Nils Breunese]

Rainer Müller wrote:

> I think Slack workspaces are also always invite only, but please correct
> me if I am wrong (maybe only for paid plans?).

Slack provides shareable invite links, but they expire. This blog post lists 
some other options:

https://intoli.com/blog/make-a-public-slack-community/

Looks like it requires some work, but it’s possible to setup.

Note that I don’t have a big opinion on whether Slack is a good idea or not.

Nils.

Re: [off-topic] remove app association from file extension

[Nils Breunese]

Helmut K. C. Tessarek  wrote:

> How do I dissociate a file extension from an application?

I haven’t tried it, but Google brought me to a StackExchange post saying you 
can use RCDefaultApp, or use 
/System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/LaunchServices.framework/Versions/A/Support/lsregister
 directly:

https://apple.stackexchange.com/a/47513/87170

Nils.

Re: macports rot

[Nils Breunese]

Calvin Ardi  wrote:

> I haven't looked into it because Hugo's publicity hadn't crossed my mind, nor 
> am I involved in the upstream project in any way (my primary motivation for 
> maintaining the Portfile is driven by my own desire to use Hugo).

I’m also not involved in most upstream projects for the ports I maintain, but 
especially when the upstream project has a website project you can send a pull 
request to, they’ll often accept that. Otherwise it can be a bit more work to 
track down who to contact to get the website updated with a mention of 
MacPorts, but I think it’s great for MacPort’s exposure (and it’s of course 
also nice for MacPorts users that visit a project website to immediately see 
they can install a package via MacPorts).

Nils.

Re: macports rot

[Nils Breunese]

Rainer Müller wrote:

> Somehow the Homebrew community managed to get their ubiquitous marketing
> on almost every software project website. Compare this with the MacPorts
> website, which has not seen any redesign in more than 10 years...
> 
> Although a good package management system should not need to advertise
> itself, as every software would be available without users being told
> where to look – the package manager should be their first choice.

But you need to know about this package manager first then. And be convinced 
into installing and using it. I found out about the existence of package 
managers on Mac (I guess it was Fink for me at the time) through installation 
instructions for some tool I wanted to install.

When I started to maintain some packages for MacPorts I also made an effort to 
do pull requests for the install docs to add instructions for installing via 
MacPorts (for instance [0]). I think this is very important PR for a package 
manager, apart from its own website.

For instance, yesterday I wanted to try out Hugo. It’s available in MacPorts, 
but the Hugo site only mentions Homebrew, binary download and building from 
source as installation options [1]. I think it might pay off if maintainers 
would pay more attention to this.

Nils.

[0] 
https://docs.spring.io/spring-boot/docs/current/reference/htmlsingle/#getting-started-macports-cli-installation
[1] https://gohugo.io/getting-started/installing#pick-your-method

Re: Looking for someone to create an initial Portfile for GitLab Runner (Go)

[Nils Breunese]

Ah sorry, I thought you had already created a working Portfile, but this 
Portfile indeed errors out. Log output here: https://pastebin.com/QGTnFUTS

Does anyone know how to fix this? https://docs.gitlab.com/runner/development/ 
explains how to build GitLab Runner from source.

I guess ‘depends_lib port:go’ could be ‘depends_build port:go’, as I don’t 
believe Go is a runtime dependency for the resulting binary.

For now I guess I’ll just use my personal Portfile that installs the 
ready-to-go macOS binary.

Nils.

> Op 28 nov. 2018, om 16:15 heeft Marius Schamschula  
> het volgende geschreven:
> 
> Nils,
> 
> I didn’t want to dig down several layers, so the Portfile is incomplete.
> 
> I’ve put it in my personal repo:
> 
> https://github.com/Schamschula/macports/blob/master/devel/gitlab-runner/Portfile
> 
> 
>> On Nov 28, 2018, at 4:32 AM, Nils Breunese  wrote:
>> 
>> Thanks for looking into this. Where can your Portfile be found?
>> 
>> Nils.
>> 
>>> Op 27 nov. 2018, om 20:52 heeft Marius Schamschula  
>>> het volgende geschreven:
>>> 
>>> Nils,
>>> 
>>> I tried to put together a quick Portfile for gitlab-runner. The included 
>>> Makefile still insists on downloading rebuild docker files
>>> 
>>> Judging by the FreeBSD port[2], that seems to be unavoidable.
>>> 
>>>> On Nov 27, 2018, at 1:19 PM, Nils Breunese  wrote:
>>>> 
>>>> Hello,
>>>> 
>>>> I’d like to be able to install GitLab Runner [0] via MacPorts. I’ve 
>>>> already created a Portfile [1] that installs this single binary tool, but 
>>>> I’ve been informed this tool should be built from source by the Portfile. 
>>>> I’m not familiar enough with Go builds to create the initial Portfile and 
>>>> too tight on time to learn it soon. So, I’m looking for someone that could 
>>>> create the initial Portfile. I’d be willing to maintain this Portfile 
>>>> after the initial creation to keep it up to date.
>>>> 
>>>> If anyone can help with this, please let me know. The source is hosted 
>>>> here: https://gitlab.com/gitlab-org/gitlab-runner
>>>> 
>>>> Thanks, Nils.
>>>> 
>>>> [0] https://docs.gitlab.com/runner/
>>>> [1] https://github.com/macports/macports-ports/pull/3081
>>> 
>>> [2] https://www.freshports.org/devel/gitlab-runner/
>>> 
>>> Marius
>>> --
>>> Marius Schamschula
>>> 
>>> 
>>> 
>> 
> 
> Marius
> --
> Marius Schamschula
> 
> 
> 

Re: Looking for someone to create an initial Portfile for GitLab Runner (Go)

[Nils Breunese]

Thanks for looking into this. Where can your Portfile be found?

Nils.

> Op 27 nov. 2018, om 20:52 heeft Marius Schamschula  
> het volgende geschreven:
> 
> Nils,
> 
> I tried to put together a quick Portfile for gitlab-runner. The included 
> Makefile still insists on downloading rebuild docker files
> 
> Judging by the FreeBSD port[2], that seems to be unavoidable.
> 
>> On Nov 27, 2018, at 1:19 PM, Nils Breunese  wrote:
>> 
>> Hello,
>> 
>> I’d like to be able to install GitLab Runner [0] via MacPorts. I’ve already 
>> created a Portfile [1] that installs this single binary tool, but I’ve been 
>> informed this tool should be built from source by the Portfile. I’m not 
>> familiar enough with Go builds to create the initial Portfile and too tight 
>> on time to learn it soon. So, I’m looking for someone that could create the 
>> initial Portfile. I’d be willing to maintain this Portfile after the initial 
>> creation to keep it up to date.
>> 
>> If anyone can help with this, please let me know. The source is hosted here: 
>> https://gitlab.com/gitlab-org/gitlab-runner
>> 
>> Thanks, Nils.
>> 
>> [0] https://docs.gitlab.com/runner/
>> [1] https://github.com/macports/macports-ports/pull/3081
> 
> [2] https://www.freshports.org/devel/gitlab-runner/
> 
> Marius
> --
> Marius Schamschula
> 
> 
> 

Looking for someone to create an initial Portfile for GitLab Runner (Go)

[Nils Breunese]

Hello,

I’d like to be able to install GitLab Runner [0] via MacPorts. I’ve already 
created a Portfile [1] that installs this single binary tool, but I’ve been 
informed this tool should be built from source by the Portfile. I’m not 
familiar enough with Go builds to create the initial Portfile and too tight on 
time to learn it soon. So, I’m looking for someone that could create the 
initial Portfile. I’d be willing to maintain this Portfile after the initial 
creation to keep it up to date.

If anyone can help with this, please let me know. The source is hosted here: 
https://gitlab.com/gitlab-org/gitlab-runner

Thanks, Nils.

[0] https://docs.gitlab.com/runner/
[1] https://github.com/macports/macports-ports/pull/3081