Call for testing: port migrate

[Joshua Root]

A 'migrate' action has been added to MacPorts base in git on the master 
branch. If you are comfortable with checking out the git repo, 
installing MacPorts from source, running potentially buggy pre-release 
code, and reporting any issues, we would greatly appreciate you giving 
it a try.


The new action automates all parts of the existing Migration procedure 
apart from updating Xcode and the CLTs. After updating your OS to a new 
major version or transferring to a new machine with a different CPU 
architecture, you should be able to simply run:


sudo port migrate

and MacPorts base will first be rebuilt, and then all ports that need to 
be reinstalled to be compatible with your current system will be. Build 
failures should be handled as gracefully as possible and reported at the 
end.


Thanks to Umesh Singla for doing the initial work on this feature, and 
to Clemens Lang for doing much of the work of completing and updating 
the code.


- Josh

Re: propka/pdb2pqr

[Joshua Root]

On 4/6/2024 23:43, Jack Howarth wrote:
I am lost at sea about how to handle the newer pdb2pqr packaging. The 
ancient 2.1.1 pdb2pqr sources built a c-based propka as part of the 
pdb2pqr process. Upstream replaced this with propka entirely rewritten 
in python and as its own project. I believe the buildbot failures that I 
am seeing are due to propka trying to overwrite the propka binary in 
/opt/local/bin on installation before the newer propka-free pdb2pqr 
package is installed. We don't seem to have the granularity in MacPorts 
to handle this cleanly short of creating a whole new pdb2pqr package 
under a new name (which is throwing a major wrench in using 
github.setup). Is there some way to handle movement of binaries across 
existing packages without having to recreate the wheel with a new 
package set?


If the old version of pdb2pqr installed propka and the new version of 
pdb2pqr depends on a separate port that now installs propka, you will 
need to use the deactivate hack: 



- Josh

Re: There should be a requirement to check if a port exists before committing something right into the master

[Joshua Root]

I remembered I wrote a script years ago to detect this very situation. 
Attaching in case it's of use to anyone. There are currently no other 
duplicate ports in macports-ports, BTW. :)


- Josh

On 1/6/2024 07:11, Joshua Root wrote:
No, there's no guarantee that a PortIndex exists; you can run port 
commands on the 'current' pseudoport, or with -D, or directly on a 
porturl. The PortIndex itself is indexed on the port name normalised to 
lower case, so it is not straightforward to detect this situation even 
with an index. A warning could be generated when running portindex, but 
you can commit without doing that, and it may impact performance.


- Josh

On 1/6/2024 03:45, Herby G wrote:
Is it a guarantee that the PortIndex is available to `port` 
everytime `port lint` is run? If so, would it be possible for us to 
use the port index to verify that one and only one port exists for the 
current port name?


On Fri, May 31, 2024 at 8:35 AM Joshua Root <mailto:j...@macports.org>> wrote:


    On 31/5/2024 21:22, Sergio Had wrote:
 > Otherwise we get this:
 >

https://github.com/macports/macports-ports/commit/6e2c1e19a4ffce5d59a9cdf8147022ad176dffed <https://github.com/macports/macports-ports/commit/6e2c1e19a4ffce5d59a9cdf8147022ad176dffed> <https://github.com/macports/macports-ports/commit/6e2c1e19a4ffce5d59a9cdf8147022ad176dffed <https://github.com/macports/macports-ports/commit/6e2c1e19a4ffce5d59a9cdf8147022ad176dffed>>

 >
 > While LimeChat has existed for 4 years in MacPorts:
 >

https://github.com/macports/macports-ports/commits/8c30b0e9fd88d94c115b38c92809b909c4eac9aa/aqua/LimeChat/Portfile <https://github.com/macports/macports-ports/commits/8c30b0e9fd88d94c115b38c92809b909c4eac9aa/aqua/LimeChat/Portfile> <https://github.com/macports/macports-ports/commits/8c30b0e9fd88d94c115b38c92809b909c4eac9aa/aqua/LimeChat/Portfile <https://github.com/macports/macports-ports/commits/8c30b0e9fd88d94c115b38c92809b909c4eac9aa/aqua/LimeChat/Portfile>>

 >
 > And now two conflicting ports for the same thing.

    I greatly doubt that this (or any other addition of a duplicate port)
    was deliberate, so having a specific rule against it wouldn't have
    changed anything. Yes, it's a problem that needs to be fixed.

    - Josh





lintportindex.tcl
Description: Tcl script

Re: There should be a requirement to check if a port exists before committing something right into the master

[Joshua Root]

No, there's no guarantee that a PortIndex exists; you can run port 
commands on the 'current' pseudoport, or with -D, or directly on a 
porturl. The PortIndex itself is indexed on the port name normalised to 
lower case, so it is not straightforward to detect this situation even 
with an index. A warning could be generated when running portindex, but 
you can commit without doing that, and it may impact performance.


- Josh

On 1/6/2024 03:45, Herby G wrote:
Is it a guarantee that the PortIndex is available to `port` 
everytime `port lint` is run? If so, would it be possible for us to use 
the port index to verify that one and only one port exists for the 
current port name?


On Fri, May 31, 2024 at 8:35 AM Joshua Root <mailto:j...@macports.org>> wrote:


On 31/5/2024 21:22, Sergio Had wrote:
 > Otherwise we get this:
 >
https://github.com/macports/macports-ports/commit/6e2c1e19a4ffce5d59a9cdf8147022ad176dffed 
<https://github.com/macports/macports-ports/commit/6e2c1e19a4ffce5d59a9cdf8147022ad176dffed>
 <https://github.com/macports/macports-ports/commit/6e2c1e19a4ffce5d59a9cdf8147022ad176dffed 
<https://github.com/macports/macports-ports/commit/6e2c1e19a4ffce5d59a9cdf8147022ad176dffed>>
 >
 > While LimeChat has existed for 4 years in MacPorts:
 >

https://github.com/macports/macports-ports/commits/8c30b0e9fd88d94c115b38c92809b909c4eac9aa/aqua/LimeChat/Portfile
 
<https://github.com/macports/macports-ports/commits/8c30b0e9fd88d94c115b38c92809b909c4eac9aa/aqua/LimeChat/Portfile>
 
<https://github.com/macports/macports-ports/commits/8c30b0e9fd88d94c115b38c92809b909c4eac9aa/aqua/LimeChat/Portfile
 
<https://github.com/macports/macports-ports/commits/8c30b0e9fd88d94c115b38c92809b909c4eac9aa/aqua/LimeChat/Portfile>>
 >
 > And now two conflicting ports for the same thing.

I greatly doubt that this (or any other addition of a duplicate port)
was deliberate, so having a specific rule against it wouldn't have
changed anything. Yes, it's a problem that needs to be fixed.

- Josh

Re: There should be a requirement to check if a port exists before committing something right into the master

[Joshua Root]

On 31/5/2024 21:22, Sergio Had wrote:
Otherwise we get this: 
https://github.com/macports/macports-ports/commit/6e2c1e19a4ffce5d59a9cdf8147022ad176dffed 


While LimeChat has existed for 4 years in MacPorts: 
https://github.com/macports/macports-ports/commits/8c30b0e9fd88d94c115b38c92809b909c4eac9aa/aqua/LimeChat/Portfile 


And now two conflicting ports for the same thing.


I greatly doubt that this (or any other addition of a duplicate port) 
was deliberate, so having a specific rule against it wouldn't have 
changed anything. Yes, it's a problem that needs to be fixed.


- Josh

Re: A question about a potential error in portconfigure::should_add_stdlib{} in the master branch

[Joshua Root]

On 30/5/2024 06:46, René J.V. Bertin wrote:

Hi,

I'm rebasing my LinuxPorts adaptation of "base" to a few days old checkout of 
the master branch, and saw something in the portconfigure::should_add_stdlib{} procedure:

```
 # GCC also supports -stdlib starting with GCC 10 (and devel), but
 # not with PPC builds
 global configure.build_arch
 if {[string match *g*-mp-* ${configure.cxx}]
 && ${configure.build_arch} ni {ppc ppc64}} {
 # Do not pass stdlib to gcc if it is MacPorts custom 
macports-libstdc++ setting
 # as gcc does not uderstand this. Instead do nothing, which means gcc 
will
 # default to using its own libstdc++, which is in fact what we mean by
 # configure.cxx_stdlib=macports-libstdc++
```

Besides the typo in the comment ;) I fear that `[string match *g*-mp-* 
${configure.cxx}]` will also match `${prefix}/bin/clang++-mp-XY`.
I understand the reason for the leading wildcard, but isn't the expression you 
want `[string match */g*-mp-* ${configure.cxx}]` ?


The proc returns before getting to this code if configure.cxx is clang++.

- Josh

Re: Fix: My dovecot install fails after macOS Sonoma 14.5 update and MacPorts update

[Joshua Root]

On 27/5/2024 02:04, Gerben Wierda wrote:

Thank you.

I had all kinds of other issues as well, so I was starting to wonder my 
MacPorts registry was corrupted


E.g. clamav-server did not activate because an older 
/opt/local/etc/clamd.conf.macports.orig was still there. Or a just 
installed certbot that on clean quits with an error because certbot is 
not installed. But iyt may have been macports/sources.conf location 
confusion or an interrupted update..


Anyway, is there a way to rebuild the registry (without losing all my 
configs in /opt/local/etc and elsewhere)? Just in case it is corrupted?


That isn't the symptom that registry corruption would typically give 
you, but sure, rebuilding the registry entry for a port is easily 
accomplished by reinstalling it:


sudo port -n upgrade --force someport

- Josh

Re: Help with Ticket #68015

[Joshua Root]

On 27/4/2024 23:09, mcalh...@macports.org wrote:

Perhaps not.
I am not quite sure what constitutes a genuine stack overflow.
However, after building the offending binary using the 
backtrace_on_stack_overflow crate, and I saw no evidence of of infinite 
recursion 
(https://docs.rs/backtrace-on-stack-overflow/latest/backtrace_on_stack_overflow/ ).
Also, the `ulimit` and `sysctl ` values seem consistent across the 
different OSs I’ve tried.

I assume they are the same on the buildbots as well.

I will try adding`-stack_size` to the linker flags.
However, the same binary crashes on some OSs and succeeds on others, so 
I am not sure why the `-stack_size` would be acceptable on some OSs but 
not others.


I don't know how rust does things, but typically there would be one or 
more guard pages just beyond the end of the memory area reserved for the 
stack. Normal allocations on the stack exceeding the maximum stack size 
due to excessive depth of function calls or an excessively large object 
being allocated will touch a guard page and cause an exception, 
resulting in a stack overflow being reported. That's what I mean by a 
genuine stack overflow.


But code could touch a guard page for any number of other reasons, and 
that may also be reported as a stack overflow.


- Josh

Re: Help with Ticket #68015

[Joshua Root]

On 27/4/2024 19:30, Marcus Calhoun-Lopez wrote:

As part of its build process, Rust creates a program called
`bootstrap`, which reports a stack overflow on 10.9 and 10.10 (see
ticket #68015).

What I cannot figure out is the following.
If I take the `bootstrap` built on 10.8, then it works just fine on
10.8 and 10.11.
That same binary crashes on t0.9 and 10.10.
If I take the `bootstrap` built on 10.9, then it crashes on 10.9.
However, that same binary runs fine on 10.10.

Can anyone imagine a scenario where the same binary runs on 10.8 and
10.11 but crashes on 10.9 and 10.10?


Is it a genuine stack overflow? Could be just about anything if not.

If it is, there could be a different stack size limit, in either the 
linker (-stack_size) or in the OS (ulimit -s; sysctl kern.stack_size, 
kern.stack_depth_max) or both.


- Josh

Re: how to handle 'internal' logs for failed builds

[Joshua Root]

On 5/4/2024 01:39, Chris Jones wrote:
So what is happening is the build internally packages its own versions 
of some externals, freetype being one of them, and its this that fails 
during configure for some reason.


The problem is the contents of that log are, of course, not in the 
macports build log, so I cannot see what it is that is causing it, and 
as it works for me I cannot look locally myself. I've tried looking at 
my versions of the logs, and just guess what might be wrong, missing new 
deps for instance, but that hasn't worked, so I really need to see whats 
in that log from the build bots...


So. Is there anything I can do here. Ideally something similar to the 
above perhaps, but which will still run even if the build phase itself 
fails... ?


I don't know how it could be generalised to all possible logs, but you 
can easily modify the list of logs that CI makes available: 



Do that on a branch, make some change to the affected port as well, and 
push to your fork and let CI run.


- Josh

Re: [macports/macports-ports] Update ImageMagick to 6.9.13-7 (PR #23307)

[Joshua Root]

On 2/4/2024 01:11, Langer, Stephen A. (Fed) via macports-dev wrote:
I got this message about rev bumping my port because of changes in its 
dependencies.  I'm relatively new to port maintenance and am not sure 
what I need to do here.    Do I just tweak the version number on my port 
so that it's rebuilt on the server?  How can I test it with the new 
dependency if the new dependency isn't yet available via "port upgrade"?


Hopefully you don't have to do anything. The PR is already increasing 
the revision of the ports that link with libMagick, so they will be 
rebuilt against the new ABI when it is merged. Your port oofcanvas built 
successfully on CI.


If you want to check that it still works correctly, you can fetch the PR 
branch into a local macports-ports repo like this:


git fetch origin pull/23307/head:ImageMagick-6.9.13

"23307" is the PR ID number, and "ImageMagick-6.9.13" is the branch the 
PR is based on. After fetching it, you can check out the 
ImageMagick-6.9.13 branch as usual. Then upgrade ImageMagick and 
oofcanvas and run whatever tests you like.


- Josh

Re: XZ Utils Compromised Releases

[Joshua Root]

A friendly reminder: if there's an issue, please file a ticket!

The one exception to that is if there's a vulnerability that has not 
been made public, in which case contacting the port maintainer and 
possibly portmgr privately is appropriate.


Discussing issues on the mailing lists, commenting about them on PRs, or 
chatting about them on IRC are all fine, but none are a substitute for a 
Trac ticket. :)


- Josh

Re: MacPorts vs. Apple compiler issues, Handle

[Joshua Root]

On 20/3/2024 03:23, Riccardo Mottola wrote:

Hi,

Joshua Root wrote:
And this is where it happened. Since this is not a full debug build, 
there is no line number information, but you at least know which 
method is doing the bad memory access.




But it should be a debug build. Well a build with debug symbols (not a 
firefox-style debug which adds also a lot of debug code).

I add:
ac_add_options --disable-strip

and this helps on Linux usually.


If the binary was stripped, you wouldn't see any names, just addresses. 
To see line numbers, you have to build with -g, and the DWARF 
information has to be available at runtime, by default in the build 
directory in .dSYM bundles.


Still, the nsWindowWatcher class gave me a clue and I found a couple of 
Firefox patches to import which initialized parameters, checked them, 
etc and now the error changed to>


0   XUL       0x0001035f5c44 
JS::Rooted::registerWithRootLists(js::RootLists&) + 20
1   ???       0x7ffeecb477f0 0 + 
140732869670896


this is bad, since it is inside the JS engine. Also the JS engine works 
on other system when compiled with modern clang and gcc!


Also here I don't have a class name which maps directly to a file which 
I can easily inspect.


Looks like its defined in js/public/RootingAPI.h ?

- Josh

Re: MacPorts vs. Apple compiler issues, Handle

[Joshua Root]

(Moving to macports-dev as it is a better fit for this topic.)

On 18/3/2024 22:50, Riccardo Mottola wrote:
I will do another compilation reducing the optimization level. GCC has 
an issue where beyond gcc6 certain optimizations need to be disabled, or 
AF crashes.


Issues that only appear at higher optimisation levels also often involve 
undefined behaviour.



Exception Type:    EXC_BAD_ACCESS (SIGSEGV)
Exception Codes:   KERN_INVALID_ADDRESS at 0x7ffe2007


So here is what happened: SIGSEGV means the program tried to access 
memory that it should not have. The page was not mapped or had the wrong 
permissions for what it was trying to do. The memory address that it 
attempted to access is also shown.



Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   XUL       0x00010f5468e1 
nsWindowWatcher::OpenWindowInternal(mozIDOMWindowProxy*, char const*, 
char const*, char const*, bool, bool, bool, nsITabParent*, nsIArray*, 
nsIDocShellLoadInfo*, mozIDOMWindowProxy**) + 273


And this is where it happened. Since this is not a full debug build, 
there is no line number information, but you at least know which method 
is doing the bad memory access.


- Josh

Re: CI are forcing tests for ports where tests are disabled

[Joshua Root]

On 18/3/2024 09:35, Daniel J. Luke wrote:

On Mar 12, 2024, at 12:20 PM, grey  wrote:

But, I am guessing, it's either not that simple, or at a minimum, I
might need some additional insights into how to placate it.


The test phase (like most other phases) doesn't run as root by default.

When you run `port test` it's failing because it can't read ssh-keysign which has 
"-rws--x--x  1 root  admin" permissions (so it /can't/ work).

You can - stop setting 'tests.run yes' since that's the port advertising that 
'port test' will work (and it doesn't), tell macports to run the test phase as 
root (test.asroot yes should work here, but when I did a quick test it didn't 
and I didn't have a chance to see why), or alter the openssh tests/build to not 
need to be run as root.


There was also a ticket about this, and some fixes for base have gone 
into git. Until they are released, 'test.ignore_archs yes' can be used 
to disable this particular test for ports that install unreadable files.


- Josh

Re: PRs for new ports that depend on new ports

[Joshua Root]

On 29/2/2024 19:56, contextnerror wrote:

I’m hoping to possibly submit a portfile for morshutalk that I got working the 
other day. This would require submitting additional new ports which are 
required as dependencies.
What is the proper way to do this? Is it one PR per port, or a single PR with 
multiple commits, or are they all squashed together?


Either one PR with multiple commits or multiple PRs.

- Josh

Re: CI are forcing tests for ports where tests are disabled

[Joshua Root]

Oh I see, the R portgroup is overriding the test phase entirely, which 
makes test.run useless. Don't do that; set test.cmd, test.args and so on.


- Josh

On 29/2/2024 18:34, Sergio Had wrote:

I believe, they were not forced for R stuff until /very/ recently.

I found a solution which should work to fix running tests for R packages 
even when tests are unsupported and forced to run, but this situation is 
quite fragile.


For the context: there are some R packages which are in themselves 
trivial, but required as dependencies for some important ones. By 
default R checks require all /optional/ dependencies to be installed, 
which sometimes means /a lot/ of stuff to build. Adding every such 
optional dependency to MacPorts just to support testing is a) 
practically unfeasible and b) hardly needed. So while I tend to add 
support for testing wherever find it important or wherever it does not 
take too much of effort, there are a number of packages which have 
/test.run no – /and that is unlikely to change.
While default behavior of R can be changed via passing a variable in 
environment, this a) does not guarantee that some tests won’t fail due 
to missing optional dependency nevertheless and b) is not clearly a 
superior choice, since it becomes less clear if some optional 
dependencies are missing (which we may care about in specific cases).




On Feb 29, 2024, at 2:17 PM, Joshua Root  wrote:

On 29/2/2024 17:01, Sergey Fedorov wrote:

There is something broken with CI now.
Tests phase must not be run when it is disabled (test.run is set to 
no), but it is.


Built-in tests can always be run. See 2.9 release notes.

- Josh

Re: CI are forcing tests for ports where tests are disabled

[Joshua Root]

On 29/2/2024 17:01, Sergey Fedorov wrote:

There is something broken with CI now.

Tests phase must not be run when it is disabled (test.run is set to no), 
but it is.


Built-in tests can always be run. See 2.9 release notes.

- Josh

Re: How to force run tests as non-root?

[Joshua Root]

On 25/2/2024 03:07, Ken Cunningham wrote:

Some of your macports installations are installed as the root user, instead of 
the macports user.

This happened because there is no installer for 10.6-ppc to automatically 
create the macports user. You have an open ticket about this too, where I 
pointed to the commands to be run to generate the macports user.

Sooner or later you will probably have to fix this.


It shouldn't make any difference to this whether you use the pkg 
installer or install from source, since the Makefile also creates the 
run user. Unless of course you specifically tell configure 
--with-macports-user=root (very not recommended).


- Josh

Re: How to force run tests as non-root?

[Joshua Root]

On 24/2/2024 17:27, Sergey Fedorov wrote:
If Macports is running as root, but tests require non-root user, how to 
do that?

There is no test.asroot no, apparently.


All the usual ways you can run something as another user when you are 
root. You could prefix your build.cmd with 'sudo -u $macportsuser' for 
example.


- Josh

Re: Automatic port replacement

[Joshua Root]

On 19/2/2024 00:49, Karl-Michael Schindler wrote:

I have a series of cross compilers which conflict with each other. Therefore, 
only one should be installed and installing one should replace the installed 
one with a Y/n question. How can I achieve this?

This is my current snippet with non-essentials removed:

foreach subarch {25 35 4 5 51 6} {
 subport “fpc-cross-avr${subarch}-embedded" {
 conflicts {
 fpc-cross-avr25-embedded
 fpc-cross-avr35-embedded
 fpc-cross-avr4-embedded
 fpc-cross-avr5-embedded
 fpc-cross-avr51-embedded
 fpc-cross-avr6-embedded
 }
 replaced_by {
 fpc-cross-avr25-embedded
 fpc-cross-avr35-embedded
 fpc-cross-avr4-embedded
 fpc-cross-avr5-embedded
 fpc-cross-avr51-embedded
 fpc-cross-avr6-embedded
 }
 build.argsCPU_TARGET=avr OS_TARGET=embedded 
SUBARCH=avr${subarch}
 destroot.args   CPU_TARGET=avr OS_TARGET=embedded SUBARCH=avr${subarch}
 }
}

But it does not work as intended. Any hints?


The braces mean that you're only passing a single value to conflicts and 
replaced_by. If you want to split the setting of a multi-valued option 
over multiple lines, use backslash line continuations.


You can't use multiple values for replaced_by currently, and if we did 
add support for that, the semantics would probably be that all the 
listed ports should be installed as the replacement for the current 
port. You don't want to set replaced_by in a port that you intend to be 
installable in its own right.


The best solution would be to make the subports not conflicting, but if 
that can't be achieved, you probably want something like this:


set subarchs [list 25 35 4 5 51 6]
set subnames [lmap s ${subarchs} {string cat fpc-cross-avr${s}-embedded}]
foreach subarch ${subarchs} subname ${subnames} {
subport ${subname} {
conflicts {*}[ldelete ${subnames} ${subname}]
build.argsCPU_TARGET=avr OS_TARGET=embedded 
SUBARCH=avr${subarch}
destroot.args   CPU_TARGET=avr OS_TARGET=embedded 
SUBARCH=avr${subarch}

}
}

- Josh

Re: Antlr: Rebuild on 12.x86_64

[Joshua Root]

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: Testing a modified portgroup

[Joshua Root]

On 5/2/2024 14:58, Austin Ziegler wrote:
I think I have found a bug in the golang portgroup, and I think I have 
an idea on how to fix it, but I'm not sure how to test such a modification.


You'd make the change in your local copy of the ports tree and check 
that a port affected by the bug now works correctly, and that some 
existing ports still work correctly.


For those interested, it's in go._translate_package_id. If I have a 
package ID github.com/jmespath/go-jmespath/internal/testify 
, the 
*subproject* is internal/testify, not internal. But the line `set 
subproject [lindex ${parts} 3]` will *only* grab `internal`.


So this:

```tcl
     set parts [split ${package_id} /]

     set domain [lindex ${parts} 0]
     set author [lindex ${parts} 1]
     set project [lindex ${parts} 2]
     # possibly empty
     set subproject [lindex ${parts} 3]
```

Should probably be this:

```tcl
set parts [split $package_id /]

set domain [lindex $parts 0]
set author [lindex $parts 1]
set project [lindex $parts 2]
# Join the remaining parts to get the full subproject path
if {[llength $parts] > 3} {
     set subproject [join [lrange $parts 3 end] /]
} else {
     set subproject ""
}
```


This could be simplified further to something like:

set parts [split $package_id /]
set remaining_parts [lassign $parts domain author project]
set subproject [join $remaining_parts /]

- Josh

Re: Lazarus package update

[Joshua Root]

On 4/2/2024 09:40, Karl-Michael Schindler wrote:

Hi.

There is a new version of Lazarus, a major update from 2.2.6 to 3.0. What are 
the conditions, whether to update the current package from 2.2.6 to 3.0 vs 
creating an additional package, called lazarus3?


If the new version breaks compatibility, and if the dependents have not 
all been updated to work with the new version, then you need a second 
port. But preferably the old version should be lazarus2 and lazarus 
should continue to be the latest version.


If none of the dependents work with the new version yet, then you should 
probabl wait until a significant number do before updating.


- Josh

Re: Difference between mpbb and local builds

[Joshua Root]

On 3/2/2024 14:08, Link Dupont wrote:




On Feb 2, 2024, at 19:04, Joshua Root  wrote:

__MAC_OS_X_VERSION_MAX_ALLOWED is from AvailabilityInternal.h, which 
as its name suggests is only intended to be used internally (by 
Availability.h).


I’m not sure that’s the intention of the file AvailabilityInternal.h. I 
certainly suggests a private API, but I wonder if it’s more intended to 
hide the implementation of Availability.h macros behind a secondary 
layer of abstraction. Availability.h defines the various OS version 
integers, then includes AvailabilityInternal.h, and then checks if 
___VERSION_MAX_ALLOWED is defined. I think the 
__MAC_OS_X_VERSION_MAX_ALLOWED macro is allowed to be used publicly.


Well, the brief comment at the top of the file says:


Contains:   implementation details of __OSX_AVAILABLE_* macros from 



Interpret that as you will, I guess.

- Josh

Re: Difference between mpbb and local builds

[Joshua Root]

On 3/2/2024 08:09, Dave Allured - NOAA Affiliate via macports-dev wrote:
Now this is odd.  Socket_vmnet is a package specifically intended for 
Mac OS, yet availability.h has been hard coded as all lowercase in the 
source code for more than two years.  Are there two versions, 
[A/a]vailability.h?  Or perhaps this is a real upstream bug, and they 
never tested it on a case sensitive file system?  Thoughts?


There has only ever been the capital A name for the header, so quite 
likely the latter.


- Josh

Re: Difference between mpbb and local builds

[Joshua Root]

On 3/2/2024 07:54, Link Dupont via macports-dev wrote:


I suppose the solution here is to patch it in the Port to inlclude 
“Availability.h” instead?


As per its comments, Availability.h is for the use of OS headers to 
declare what is available. Programs wanting to check what is available 
should use AvailabilityMacros.h.


Check MAC_OS_X_VERSION_MAX_ALLOWED when it matters which SDK you are 
building against (and thus which features have available declarations). 
If you instead care about the oldest OS version that the program may run 
on (and thus which features need a runtime availability check), use 
MAC_OS_X_VERSION_MIN_REQUIRED.


__MAC_OS_X_VERSION_MAX_ALLOWED is from AvailabilityInternal.h, which as 
its name suggests is only intended to be used internally (by 
Availability.h).


- Josh

Re: TCL 9.0?

[Joshua Root]

On 30/1/2024 01:18, Mark Anderson wrote:
Woah, never thought I'd see it: 
https://www.tcl.tk/software/tcltk/9.0.html 



I wonder how big an impact it will be? Since we ship out own, not rush 
(It's also still beta) but interesting nonetheless.


The namespace resolution may affect some of our code, and the tilde 
change definitely does. It wouldn't surprise me if there are some more 
incompatibilities not listed on that page. We'll probably go to 8.7 
first for base.


For ports, I would guess we'll need to keep Tcl 8 and 9 available as 
separate ports for quite some time.


- Josh

Re: mailing list "dev" vs "user"

[Joshua Root]

On 25/1/2024 20:54, Riccardo Mottola via macports-dev wrote:
Questions about bugs (e.g. discussions similar to track) belong to which 
list best? Is "dev" only for "macports" itself or also for the ports in it?
I thought the former, then I checked the archives casually and noticed 
there is lot of discussion going on on the "dev" list including support 
for old systems,  PPC, things about GTK and so which I just missed and I 
am active and interested in.


Development of both MacPorts base and Portfiles are appropriate topics 
for macports-dev.


- Josh

Re: Question on architechture

[Joshua Root]

If the universal variant doesn't work in one or more of the 
dependencies, disable it with 'universal_variant no'. Doing that for 
even one of them will make it so that, if supported_archs is also set 
correctly, you get an error during dependency calculation.


- Josh

On 24/1/2024 12:48, Mark Anderson wrote:


supported_archs x86_64 (perhaps those others work too) is in my branch 
already to be pushed and I plan on pushing it up shortly, but it seems 
to still fail on arm64 machines even when being built for x86_64, but 
that's due to a dependency. The problem is, it has a lot of dependencies 
and I don't want people to try an install it when it will fail on arm64 
no matter what.


—Mark
___
Mark E. Anderson mailto:m...@macports.org>>
MacPorts Trac WikiPage 
GitHub Profile 



On Tue, Jan 23, 2024 at 8:17 PM Kirill A. Korinsky > wrote:


On Wed, 24 Jan 2024 01:59:54 +0100,
Mark Anderson wrote:
 >
 > So the Io port won't build on arm64, it will build on x86_64 and
even get
 > moving on arm64 in x86_64 mode, but memcached seems to fail in
universal
 > mode. What's the best way to deal with this for now, a note? a
warning?
 > Some wait to fail instantly if you're on apple silicon?
 >

supported_archs  i386, ppc, ppc64, x86_64

?

-- 
wbr, Kirill

MacPorts 2.9.0-rc2 now available for testing

[Joshua Root]

Source code and pkgs for MacPorts 2.9.0-rc2 are now
available [1]. Testing of either of these install methods is helpful.

Be prepared to encounter bugs. As always, having a recent backup would
be wise. Please report any bugs that you find [2] (after first searching
Trac [3], of course!)

If no showstopping bugs are found in the next few days, this will become
the 2.9.0 release.

There are a large number of changes in this release. See the ChangeLog
[4] for a list of most of them. You may like to focus your testing on
the new features in that list, as well as your normal usage.

Changes since rc1 are:
 * Fixed error when running 'port diagnose'.

Cheers,
Josh

[1] 
[2] 
[3] 
[4] 

Re: pre-built quartz variant packages

[Joshua Root]

On 17/1/2024 05:42, Valerio Messina via macports-dev wrote:
Using the pre-built gtk3 from macport (and osxcross), saved me the 
library built time just for test of my apps, and the requirement to 
access macOS on every run.
Then I discovered to start the app I had to install Xquartz on the real 
hw, and this is not a thing normal user is used to do, or is able to or 
want to do.


Seems to me that native Quartz variant of gtk3 work like or better than 
Xquartz (default) variant. At least better than gtk on Win.


Really hope you can please provide the gtk3 pre-built Quartz variant


I agree that the UX surrounding the quartz/x11 choice is bad. 
Unfortunately it's harder to fix than you might hope, and gtk3 itself 
may be the easiest part of the puzzle. A number of other ports like 
glib2 and cairo are also involved, and have to support other dependents 
that may be using gtk2 or something else entirely. Many intermediate 
dependencies build differently depending on whether they are built 
against quartz or x11 variants of their dependencies, so there's a whole 
chain that has to be managed. Some ports fail to build against quartz 
dependencies.


The proposed solution to all of the above is to split everything that 
both has dependents and is affected by the quartz/x11 choice into two 
subports. Unfortunately nobody has yet implemented this.


Relevant tickets:






- Josh

MacPorts 2.9.0-rc1 now available for testing

[Joshua Root]

Source code and pkgs for MacPorts 2.9.0-rc1 are now
available [1]. Testing of either of these install methods is helpful.

Be prepared to encounter bugs. As always, having a recent backup would
be wise. Please report any bugs that you find [2] (after first searching
Trac [3], of course!)

If no show-stopping bugs are found in the next few days, this will
become the 2.9.0 release.

There are a large number of changes in this release. See the ChangeLog
[4] for a list of most of them. You may like to focus your testing on
the new features in that list, as well as your normal usage.

Changes since beta1 are:
* Version number only.

Cheers,
Josh

[1] 
[2] 
[3] 
[4] 

Re: Builder request, h5fortran on Sonoma x86

[Joshua Root]

On 14/1/2024 12:04, Dave Allured - NOAA Affiliate via macports-dev wrote:
Would someone please push through a rebuild of h5fortran on Sonoma x86, 
such that the status page is correctly updated?  I think this bad build:


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



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


The buildbot is just finishing up the last of the ports. We'll run 
through all the ones that weren't successfully built again soon, to pick 
up fixes for Xcode issues etc. that have been made in the meantime.


Committers with a buildbot account can force a build to run, and 
committing any change to a port's files will also run a new build if it 
failed previously. I queued one up for h5fortran.


- Josh

Re: Support for ancient machines and operating systems

[Joshua Root]

On 9/1/2024 01:53, Kirill A. Korinsky wrote:

How do you see the way to backport changes from upstream MacPorts to legacy 
MacPorts?

at some point automatical merge would be broken on conflicts, and I assume 
quite fast.


I would posit that if maintaining a patch set in your fork is a lot of 
work, most of that work would still have to be done if the patch set 
were maintained in the mainline repo, it's just "invisible" work because 
you're not the one who has to do it.


- Josh

Re: Support for unreleased beta apple operating systems (was Support for ancient machines and operating systems)

[Joshua Root]

On 9/1/2024 05:26, Perry E. Metzger wrote:

On 1/8/24 12:50, Sergey Fedorov wrote:
2. Standard 10.6.8 release from Apple does support building and 
running ppc binaries via Rosetta.


Why would one want to spend time and effort on doing that, though?


You wouldn't, if you were running a public release of 10.6. The ppc libs 
were put there to support existing ppc binaries, which will have been 
built targeting 10.5 or older. With MacPorts, native x86_64 or i386 
builds would be far preferable. Unless, of course, you're running on a 
CPU that can't run those archs, which can only be the case if you are 
running an early development version of the OS.


So far as I can tell, the project's primary goal is to provide support 
for the millions of people who run MacOS on current hardware and 
operating systems and want up to date software for their machine. The 
goal is not (primarily) to assist in running PPC binaries on Rosetta on 
20 year old hardware for the couple of people for whom that is 
interesting. Certainly there's nothing wrong with supporting that to the 
extent that it does not interfere with the primary goal.


As a reminder, the project policy is (and has been virtually since the 
beginning) to support the versions of macOS that are still getting 
updates from Apple. That is the expectation for maintainers. Maintainers 
can voluntarily support older stuff, but they are under no obligation to 
so so.


- Josh

Python dependencies (was: MacPorts 2.9.0-beta1 now available for testing)

[Joshua Root]

On 2/1/2024 11:24, grey wrote:

Installing llvm-17 goes OK, but:

Why are python310 and python311 considered dependencies if I already
have python312 installed and selected? Pretty sure that some other BSD
ports systems I use do not seem to regress like MacPorts in similar
dependency walks, the fact that my MacPorts now has three versions of
Python installed seems a bit wonky to me.


Ports usually depend on a specific version of python so the build 
environment will be consistent. The MacPorts default python version only 
just changed from 3.11 to 3.12, so some ports just haven't been switched 
over yet. Others aren't compatible with the newer version. And then... 
there's this specific example.


Python 3.11 and later need to be built with a C11 compiler. On older 
systems, Xcode doesn't ship one, so the C11 compiler that gets used is 
one of the clang-* ports. The dependency on python311 in llvm-17 
shouldn't be hard to switch over to python312, but python312 will also 
have to be configured to avoid using the clang versions that use it.


The python310 dependency comes from libpsl, which is an indirect 
dependency of cmake, which is needed to build all recent llvm versions. 
This is trickier because all of the C11 capable clang versions need 
cmake. We could possibly only hold back the python used by libpsl on 
platforms without C11 support in Xcode, though that would mean a less 
tested configuration for some users. Or it could probably be solved with 
more use of *-bootstrap ports.


- Josh

Re: MacPorts 2.9.0-beta1 now available for testing

[Joshua Root]

On 31/12/2023 23:01, Kirill A. Korinsky wrote:

Greeting,

Any news / changes on Github PG / extract.rename = yes for multiple distfiles?

See:
  - https://trac.macports.org/ticket/66993
  - 
https://github.com/macports/macports-ports/blob/9110117598a7828780270c73402bf2bd434082f8/devel/retdec/Portfile#L142-L146


If that's a common thing for ports that use the github portgroup, it 
should be fixed in the portgroup. That might be done by bringing back 
this code in some form: 



It may need some tweaking, for example the previously existing version 
of the code only ran if github.tarball_from was 'tarball', but I'm 
pretty sure I've seen hashes in the directory name for 'archive' as well 
sometimes.


If on the other hand this only affects a small number of ports, I think 
it's fine to let them keep handling this in their Portfiles, like any 
other uncommon requirement.


- Josh

MacPorts 2.9.0-beta1 now available for testing

[Joshua Root]

Source code and pkgs for MacPorts 2.9.0-beta1 are now
available [1]. Testing of either of these install methods is helpful.

Be prepared to encounter bugs. As always, having a recent backup would
be wise. Please report any bugs that you find [2] (after first searching
Trac [3], of course!)

There are a large number of changes in this release. See the ChangeLog
[4] for a list of most of the major ones. You may like to focus your
testing on the new features in that list, as well as your normal usage.

Cheers,
Josh

[1] 
[2] 
[3] 
[4] 

Re: Portfile magic / xinstall usage / defect?

[Joshua Root]

On 10/12/2023 16:33, Frank Stock wrote:

So every macOS installer that expect certain ownership, needs a pre/post 
install script that ensures the expected users exist (or create them).  It 
should then explicitly set ownership of files with non-default ownership.


Well let's first confirm that pkgbuild and Installer.app behave this way 
when configured appropriately. If the users and groups do have to be 
created by custom code in the pkg, doing it in preflight should result 
in the files being created correctly by the installer with no further 
intervention.


- Josh

Re: Portfile magic / xinstall usage / defect?

[Joshua Root]

(Moving to macports-dev)

Frank Stock wrote:


My main focus is .pkg component installers targeting systems where a 
development toolchain is not realistic.

* Do you think it would be possible to use mtree and add_users data to generate 
code for a postinstall script handling user/group creation and file ownership?

* If so, would there be any interest from the MacPorts team in a pull request 
for that?


So it sounds like you're saying that file ownership is not currently 
preserved by 'port pkg'? :)


Yes, a reasonable PR to fix that would most likely be accepted. However 
I don't think a postinstall script would be required, I'm pretty sure it 
would just be a config option for pkgbuild or something.


- Josh

Re: How to parse a Portfile?

[Joshua Root]

On 2/12/2023 15:22, Frank Stock wrote:

Thank you for that detailed explanation Josh!
It provided all the missing pieces I needed.

-Frank


No worries. One note, you shouldn't need to use _mportkey for homepage, 
as that is in the portinfo that you get even just from the index. Also 
you probably want some error handling when using _mportkey, as not all 
options exist in all ports, and even the ones that are considered 
required are sometimes forgotten. It's also possible for mportopen to 
fail, which is usually a bug in the affected port, but those do happen 
sometimes.


- Josh

Re: How to parse a Portfile?

[Joshua Root]

On 1/12/2023 11:27, Frank Stock wrote:

Section 6.4.1 has an interesting bullet…
"Ports API - API for Portfile parsing and execution”

I would like to extract information from a Portfile such as, version, license, 
add_users, startupitem, post-destroot, etc. for analysis/processing in a 
Node.js app.
Thought I might be able to use a Tcl Interpreter such as npm tcl or npm tcl-js 
to load from base/src/port1.0/ and obtain what I want using mportinfo.

But I confess, being a newbie to Tcl as well as MacPorts internals, after a day 
of “grep”, I still haven’t figured out how (or even if its possible) to load 
the API into an interpreter outside MacPorts?

Are there better ways to accomplish my goal of extracting Portfile info?
Wish I could just use “port info acme”, but add_users and post-destroot are 
some of the required pieces of info I need.


Portfiles can contain arbitrary Tcl code and rely heavily on the code in 
MacPorts base, so no, there's not really any way to correctly evaluate 
them without using the macports API. There are quite a few examples in 
the macports-contrib repo. Basic usage goes like this:


package require macports
mportinit

set portname python311
# Look up the port name in the PortIndex
lassign [mportlookup $portname] - infolist
array set portinfo $infolist

# Use the porturl and subport from the index to open the Portfile
set mport [mportopen $portinfo(porturl) [list subport $portinfo(name)] ""]

# Update the portinfo array with information that is not in the index
array set portinfo [mportinfo $mport]


At this point you have a portinfo array containing all the public 
information about the port. For internals like add_users you would have 
to use a private API like _mportkey:


_mportkey $mport add_users

That can get you the values of Portfile variables, but note that 
post-destroot is not a variable, it's a procedure.


It is possible to get at the Portfile interpreter and run arbitrary code 
in it, but needless to say at that point it's totally unsupported and 
subject to change without notice, you're on your own, etc.


set workername [ditem_key $mport workername]
$workername eval [list info procs]

- Josh

Re: MacPorts 2.9

[Joshua Root]

On 1/12/2023 07:08, Clemens Lang wrote:

Hey Joshua,

On Thu, Nov 30, 2023 at 07:06:51AM +1100, Joshua Root wrote:

Just a heads up that I'm planning to create a new release branch and
tag a 2.9.0 beta soon.


Do you have a specific plan on when you're going to do this?

I'm currently finishing up the work on the automatic migration branch
that Umesh Singla developed for us during GSoC 2017, and I've made some
significant progress in the last few days. I ran a successful automated
migration to Sonoma with it yesterday and considering Apple doesn't seem
to be slowing down with new releases, it would be nice to still get it
into 2.9.0 before you branch.


Sounds good. I'll hold off on the branch if this will be ready to merge 
within a week or two.


- Josh

MacPorts 2.9

[Joshua Root]

Just a heads up that I'm planning to create a new release branch and tag 
a 2.9.0 beta soon.


- Josh

Re: Help with zef Portfile

[Joshua Root]

raf wrote:


I tried just putting "system" before the command but it didn't work.
I couldn't find the documentation for tcl's system,


System isn't a standard Tcl thing, it's provided by MacPorts. It's 
closely analogous to system(3). It takes a single string which is passed 
to 'sh -c'.


It's documented in the portfile man page at least. If it's missing 
elsewhere, that's one more thing for the list of documentation 
improvements that are needed.



   :info:destroot Failed to create directory 
'/opt/local/share/perl6/site/short' with mode '0o777': Failed to mkdir: 
Operation not permitted
That path is outside the work path, so it's not permitted to write to it 
except in the activate phase, but apparently something in the port is 
trying to create it during the destroot phase.


- Josh

Re: Help with zef Portfile

[Joshua Root]

raf wrote:


The destroot part looks like this:

   destroot {
   "${prefix}/bin/rakudo" -I"${worksrcpath}" bin/zef \
   --to="inst#${destroot}${prefix}/share/perl6/site" \
   install "${worksrcpath}"

   ln -s "${prefix}/share/perl6/site/bin/zef"   "${prefix}/bin/zef"
   ln -s "${prefix}/share/perl6/site/bin/zef-m" "${prefix}/bin/zef-m"
   }

Which results in this error:

   :error:destroot Failed to destroot raku-zef: invalid command name 
"/opt/local/bin/rakudo"
   :debug:destroot Error code: NONE
   :debug:destroot Backtrace: invalid command name "/opt/local/bin/rakudo"
   :debug:destroot while executing
   :debug:destroot "$procedure $targetname"

As "${prefix}/bin/rakudo" is valid in test.cmd,
why isn't it valid during destroot?
And how do I help destroot find it?


This is really a macports-dev question, so cross-posting this there.

When you override (e.g. destroot { ... }) or augment (e.g. post-build { 
... }) a port phase, the code you provide is executed in the Tcl 
interpreter. '${prefix}/bin/rakudo' is indeed not a valid Tcl command. 
It happens that we do define an 'ln' Tcl command that takes args very 
much like ln(1). If you want to execute something in the shell, you have 
to use the 'system' command (or sometimes 'exec' if you want to capture 
the output.)


The default destroot phase builds a string to pass to 'system' by 
combining destroot.cmd, destroot.args, etc. In this case, it might be 
easiest to use those for the rakudo command, and create the symlinks in 
a post-destroot block?


- Josh

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

[Joshua Root]

On 22/11/2023 01:46, Dave Allured - NOAA Affiliate wrote:


There is no possible port workaround for an Xcode/CLT mismatch such as 
the current situation on CI OS 13 which I mentioned earlier.  CI OS 13 
is in an illegal condition, according to Macports specifications.
Is it? We certainly recommend having the same version of both installed, 
but generally ports should be building with one or the other depending 
on the use_xcode setting.


- Josh

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

[Joshua Root]

On 21/11/2023 12:51, Dave Allured - NOAA Affiliate via macports-dev wrote:
Is there an easy way to select a specific Xcode or CLT version for CI 
workflows?  Developers could insert such temporary control into 
individual PR's, to be excluded upon merging.   Alternatively, Macports 
could insert this into macports-ports/master for community benefit, 
while we ride out the wait for Apple fixes or other solutions.


Any problems seen on CI due to Xcode 15 will also be seen by end users 
running that Xcode version. So any necessary workarounds should be 
applied in ports based on $xcodeversion and/or $xcodecltversion.


It's probably possible to install a different Xcode version as part of 
the CI bootstrap script, but that would eat up a lot of build minutes 
and would just be hiding the problems that users will be seeing if 
they're not worked around.


- Josh

Re: Port Reclaim

[Joshua Root]

On 7/11/2023 17:39, Saagar Jha wrote:
I have noticed that “port install” will not mark a port as requested if 
it is already installed (e.g. as a dependency of something else you 
installed). Perhaps this is something that might be worth changing?


Saagar Jha




- Josh

Re: More classes of maintainer

[Joshua Root]

On 6/11/2023 05:58, Perry E. Metzger wrote:

On 11/5/23 13:37, Daniel J. Luke wrote:

To clarify - this was in the context of commits to base/

(That may or may not change your perception - but like I said, I 
didn’t measure and this is totally measurable).


I don't think the base tools are getting a lot of attention because they 
mostly just work?


Could well be a factor. I'm certainly pretty satisfied with the state of 
base now, considering what it was like in 2006.


There are still quite a few tickets and not a lot of people closing them 
though. (Not to mention all the stuff on the "nice to get to someday" 
list, some of which is too vague to even make sense as a ticket.)


- Josh

Re: More classes of maintainer

[Joshua Root]

On 6/11/2023 05:57, Perry E. Metzger wrote:

On 11/5/23 13:36, Joshua Root wrote:
There has been an increase in commit volume in more recent years, but 
it certainly didn't coincide with the GitHub migration in 2016.


Put it differently: I do a lot of merges of updates from random people 
to the repository, and I'd probably be doing none of it if I couldn't do 
the code review, CI checks, etc. cleanly and easily inside of Github. 
Modern development tools make a lot of stuff ever so much easier.


I don't disagree that PRs are a smoother workflow for some common cases. 
You don't have to sell GitHub for this, we already decided to use it. :)


If we did ever decide to switch platforms, it would almost certainly be 
to something with equivalent functionality.


Perhaps it took a while from the repository transfer until people got 
the hang of things so the increase wasn't synchronous, but I really 
don't think anyone would sanely want to go back. It's much better now.


It's really impossible to draw any conclusions about causality here; 
there are too many confounding factors just for starters (like a pandemic.)


- Josh

Re: More classes of maintainer

[Joshua Root]

On 6/11/2023 05:37, Daniel J. Luke wrote:

To clarify - this was in the context of commits to base/

(That may or may not change your perception - but like I said, I didn’t 
measure and this is totally measurable).


Indeed, the picture is even more clear with base. 



- Josh

Re: More classes of maintainer

[Joshua Root]

On 6/11/2023 05:26, Perry E. Metzger wrote:

On 11/4/23 02:42, Daniel J. Luke wrote:

(Before we moved to github there were many people saying we'd get lots more 
commits by moving to it, but the volume doesn't seem much higher to me - of 
course, I also didn't measure before/after so my perception could be incorrect).


I think that's very, very wrong. There are vastly, vastly more community 
submitted updates now, and they are easy to apply to the repository with 
low effort on the part of the macports committers. It's been an 
unequivocal win.


The data seems less certain on that: 



There has been an increase in commit volume in more recent years, but it 
certainly didn't coincide with the GitHub migration in 2016.


 - Josh

More classes of maintainer (was: Re: branch master updated: nmap: fixes for 32-bit and pre-C++11 platforms)

[Joshua Root]

On 2/11/2023 12:32, Perry E. Metzger wrote:
As an aside, as it stands, the rules situation with closed maintainer / 
open maintainer is kind of unpleasant already. For example, I'd like to 
be able to indicate that I'm happy with anyone making reasonable changes 
to my ports on their own without waiting three days for me, but there's 
no way to do that, because "open maintainer" really means "three day 
timeout" just like closed. It would be nice if we had some sort of 
larger set of gradations for what people prefer, from "I handle all 
commits on this, period" to "if you have commit access and want to help, 
don't ask, just do it."


A reasonable idea. I'd say that at some point you become less of a 
maintainer and more of an interested party, but a list of people who 
would just like to be Cc'd on the tickets and PRs for a port isn't a bad 
thing to have.


We seem to have somewhat different experiences, as the reason I removed 
openmaintainer from some of my ports was that it seemed to be 
interpreted more like "commit whatever you want without asking." So 
being able to set expectations more clearly would be nice.


As another aside, we also have a ton of ghost maintainers who never 
respond but whose name being on the port means you have to 
ritualistically wait three days for a reply you know will never come.


This is of course what the Port Abandoned procedure is for. Regrettably 
however, it also involves a three-day wait. :)


- Josh

Re: [macports-ports] branch master updated: nmap: fixes for 32-bit and pre-C++11 platforms

[Joshua Root]

An understandable presumption in itself, however there was another force 
push after dluke's last comment, so the changes that ended up being 
merged had not been reviewed by the maintainer.


This was pretty clearly just a misunderstanding, but maybe we should 
clarify the policies to only allow merging by others (before timeout) 
when there is a non-stale approving review from the maintainer.


- Josh

On 2/11/2023 09:12, Perry E. Metzger wrote:

Your communication in the thread was:

 > ideally we'll get confirmation from @barracuda156 
 that we've got a working solution 
before we merge as well.


After he verified that it was working for him, I presumed you were okay 
with it being committed.


Perry

On 11/1/23 17:22, Daniel J. Luke wrote:

Perry - I had not yet signed off on this PR.

The port is not openmaintainer.

Please refrain from making changes to non-openmaintainer ports without the 
maintainer's approval.


On Nov 1, 2023, at 12:48 PM, Christopher Chavez via 
macports-changes  wrote:
Perry E. Metzger (pmetzger) pushed a commit to branch master
in repository macports-ports.

Re: [MacPorts] #68563: intermittent 503 errors from {packages, distfiles}.macports.org

[Joshua Root]

Thank you for the fix, and for letting us know. I'll revert the changes 
on our end and see how we go.


- Josh

On 30/10/2023 18:32, Michael Meier (FTP-Admin) wrote:

On 10/28/23 10:39, MacPorts wrote:

#68563: intermittent 503 errors from {packages,distfiles}.macports.org
  * cc: rrze-ftp-admins@… (added)


Hi there,

these intermittent 503 errors should already be fixed since a few hours 
after you CC:'d us on Saturday.
Reason for the problems was that the webserver was occasionally running 
out of threads. And it did so, because a few rather large subnets from 
China were downloading the same CentOS-.isos over and over again (*) - 
with >11000 connections, spread over >1000 IPs, at something like 3 
KB/s. This did not even cause any relevant load on the server, the 
webserver simply hit the configured limits for how many connections it 
may handle in parallel, hence throwing the intermittent 503 errors.


(*) related discussion on the CentOS-mirror-list: 
https://lists.centos.org/pipermail/centos-mirror/2023-October/077492.html


Regards,

Re: [MacPorts] #68577: ywg.ca.*.macports.org throttled to 1.6Mbps

[Joshua Root]

Thanks, ticket Cc updated. I guess we should update the contact address 
on  as well.


On 29/10/2023 02:19, Adam Thompson wrote:
I no longer actively manage this mirror.  Can you please CC 
mir...@muug.ca on the ticket?
Meanwhile, I've forwarded this so someone can respond more usefully than 
I can.
FWIW, the server's connected at 10G.  The upstream bandwidth provider 
changed who they peered with for internet-bound connectivity not very 
long ago, but that wouldn't normally cause that severe a change in speed.

-Adam

Get Outlook for Android 

*From:* MacPorts 
*Sent:* Saturday, October 28, 2023 8:43:26 AM
*Cc:* ad...@macports.org ; athom...@muug.ca 
; chrischa...@gmx.us ; 
macports-tick...@lists.macports.org 
*Subject:* Re: [MacPorts] #68577: ywg.ca.*.macports.org throttled to 
1.6Mbps

#68577: ywg.ca.*.macports.org throttled to 1.6Mbps
-+-
   Reporter:  chrstphrchvz    |  Owner:  admin@…
   Type:  defect  | Status:  new
   Priority:  Normal  |  Milestone:
  Component:  server/hosting  |    Version:
Resolution:  |   Keywords:
   Port:  |
-+-
Changes (by jmroot):

  * cc: athompso@… (added)


--
Ticket URL: >

MacPorts >
Ports system for macOS

Re: librsvg, and what MacPorts is for

[Joshua Root]

On 11/10/2023 06:25, Perry E. Metzger wrote:
That said, I presume there's a strong overall consensus that on current 
hardware, we run the current (supported) versions of software, and that 
older operating systems and hardware are supported only on a "if it 
doesn't hurt anything" basis.


The expectation hasn't really changed since the earliest days of the 
project: maintainers should keep their ports working on the latest 
versions of macOS (roughly those that are getting security updates). 
Supporting anything else is going above and beyond. This is even 
referenced on the front page of our web site, which says we are 
"targeting mainly [the current releases of macOS]".


Put another way, all port maintenance is best-effort, but some OS 
versions are more best-effort than others. :)


There have been a number of previous discussions of this on the mailing 
lists, if anyone wants to go try to dig them up.


- Josh

Re: Updating alpine

[Joshua Root]

On 4/10/2023 15:05, contextnerror wrote:

I was hoping to update the portfile for alpine.
Currently the 2.26 release will not build due to a passfile bug, but this was 
fixed in a newer commit. (https://repo.or.cz/alpine.git)
I had a few questions about how to implement this:

- Should I add the changes as patchfiles, or just change the master site to the 
git repo?
- Would the version still be 2.26 or something else?
- Should I also add any of the other new fixes from git?


Fetching from a VCS should be avoided if possible, since we can't mirror 
the source in that case, and fetching is more likely to fail on 
restrictive networks. So probably patchfiles.


Usually we would not change the version when adding bug fix patches. If 
the version in the published ports tree were already 2.26 and you added 
a patch that changes the installed files in any way, you would of course 
increase the port's revision.


Normally you don't want to pull in all the changes that exist in an 
upstream repo, simply because if they were considered ready to use there 
would be a new release containing them. Some projects have very slow 
release cycles though, so if that's the case here, try to get some sense 
of the risk vs benefit for each change before deciding to incorporate it.


- Josh

Re: Update port reinstallation instruction on wiki

[Joshua Root]

On 3/10/2023 08:17, Jimmy Wong wrote:

On Oct 2, 2023 at 8:13 AM +0100, Joshua Root , wrote:

This won't necessarily restore the variants of non-requested ports
correctly, and will sometimes install the same port multiple
times (a
requested port that is a dep of another requested port can be first
installed with its default variants, then again with its previously
requested variants.)


Yes it will. The requested.txt files produced this way come with 
variants.
You can't possibly restore the state of non-requested ports when you 
only record information about requested ones.


If you understand the process well enough to evaluate the tradeoff of 
not restoring quite all the state, you are not really the target 
audience for the Migration instructions. If you don't mind dealing with 
the occasional problem due to opportunistic use, you're free to simply 
run 'sudo port upgrade outdated' after reinstalling base.


- Josh

Re: Update port reinstallation instruction on wiki

[Joshua Root]

On 2/10/2023 10:36, Jimmy Yuen Ho Wong wrote:
Currently, the Migration 
 guide on the wiki 
denotes a 6-step process to restore ports after an upgrade, one of which 
requires the user to download a script that hasn't worked properly for a 
few years now (doesn't restore variants and ignore platform and arch).


I follow the Migration instructions on every major OS update to ensure 
that they still work. I haven't noticed any problems with 
restore_ports.tcl. It restores all requested variants, including in 
non-requested dependencies, as intended.


I don't know what you expect it to do with platform and arch 
information, but if there are any specific bugs, please file tickets.


I 
propose a much simpler instruction like so:


 3. *Reinstall your ports*
 1. Save the list of installed ports:

port echo requested | sed -E s/@[^\+]+//g > requested.txt

 2. Uninstall all installed ports:

sudo port -f uninstall installed

 3. Run a regular clear out of your installation:

sudo port reclaim

 4. Restore requested ports:

sudo bash -c 'cat requested.txt | xargs port -v install'


This won't necessarily restore the variants of non-requested ports 
correctly, and will sometimes install the same port multiple times (a 
requested port that is a dep of another requested port can be first 
installed with its default variants, then again with its previously 
requested variants.)


Ultimately the goal is to develop the 'port migrate' action to a state 
where it handles all of these considerations automatically. 



- Josh

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

[Joshua Root]

On 27/9/2023 21:47, Christopher Jones wrote:


Is the logic behind what all the various options we can now use with platforms 
documented somewhere ?


It's documented in the Guide.

- Josh

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

[Joshua Root]

On 27/9/2023 23:01, Nils Breunese wrote:

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.


Or the simpler form

platforms {darwin any >= 11}

- Josh

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

[Joshua Root]

On 27/9/2023 20:42, Nils Breunese wrote:

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.


The platform isn't recorded in the registry as "darwin any" currently 
(on the todo list since the platforms changes were made). I had hoped 
the installed archive might be reused in this case, but it looks like we 
set force_archive_refresh for platform mismatches just like if the 
--force option was used for an upgrade.


- Josh

Re: portfile questions

[Joshua Root]

On 13/9/2023 14:12, Langer, Stephen A. (Fed) via macports-dev wrote:

Hi --

I'm getting ready to update the oof2 and oofcanvas ports and have a few 
questions.   I created the initial portfiles with a lot of help from the 
admins and I'm still more or less a novice at this.


The original versions were built with distutils, but the new ones use 
cmake.  The installed files include an executable python script, a bunch 
of python  modules, and some libraries built from C++ code.   I think I 
should use the cmake portgroup instead of the python portgroup, because 
doesn't the portgroup determine if the build is done with cmake or 
python.  I see that some other ports use both so I am missing something.


The cmake portgroup mostly sets up the configure phase. The python 
portgroup disables the configure phase entirely by default. Anything set 
up by a portgroup can be overridden in the Portfile, so both of these 
can be used together under some conditions -- whether it's worth doing 
so depends on just how the build system works.


(You can certainly end up in a situation where using a portgroup creates 
more work than it saves, if it wasn't designed for what you want to do 
and you have to fight against it.)


If I use the python portgroup, then I'd have subports pyXY-oof2 and 
pyXY-oofcanvas.  Would users of the old oof2 and oofcanvas ports know to 
upgrade to the new ports?


Not necessarily unless you mark the old ports as replaced_by the new 
ones. 


If the new portfile doesn't use the python portgroup, I assume I should 
just offer variants for different python versions. Is there a standard 
way to choose the default variant, to reduce the chances of installing 
extra python versions if a user doesn't already have the one I've chosen 
as the default?


The default should be the one that was the latest stable Python version 
on January 1st. So currently 3.11. 



- Josh

Re: unset or change CPATH/LIBRARY_PATH for build in a portfile

[Joshua Root]

On 11/9/2023 00:58, christos koninis wrote:

Hello all,

Is there any way to unset or change the CPATH/LIBRARY_PATH environment 
variables in a portfile during the build?

I have tried

build.env-delete        CPATH
build.env               CPATH=something

but they don't seem to be working.


The relevant options are compiler.cpath and compiler.library_path.

- Josh

Re: Regarding github CI

[Joshua Root]

I have wanted to add some testing to the CI and buildbot for some time, 
but there are a few complications to consider. The first and simplest 
barrier is that the current release of MacPorts errors out if you try to 
run tests on a port that doesn't explicitly enable them. Related to that 
is the fact that many (most?) ports don't have any meaningful tests to run.


There are unreleased changes that start to address this. I've added one 
basic test that can be run for all ports, which at the moment just 
checks if they are using `supported_archs noarch` appropriately. More 
similarly simple and generic tests can be added, e.g. checking binaries 
for broken linking. Ports that don't set `test.run yes` will run only 
the built-in tests, while those that do will also run their custom tests 
as defined in the Portfile.


The other problem is that some projects have, shall we say, 
comprehensive test suites. This is undoubtedly a good thing for those 
projects! But as a distro building thousands of ports, we have to have a 
relatively tight limit on how long tests can take to run. There's 
currently no way of differentiating a CI-appropriate test phase from an 
unreasonably long-running one. Ideally we might have the option of 
defining a short test phase that is run on CI, and a longer one that can 
be run locally by maintainers and other interested parties if desired.


- Josh

Re: Portfile for osxphotos

[Joshua Root]

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


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.


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: 



- Josh

Re: Close trac #66411

[Joshua Root]

On 30/8/2023 01:13, Dave Allured - NOAA Affiliate via macports-dev wrote:
Someone please close https://trac.macports.org/ticket/66411 
 as completed.  I can't do it 
myself, and it did not auto-close on the PR.  Thanks.


For the record, the "Closes: " text has to be in the commit message 
to automatically close the ticket, not just in the PR description.


- Josh

Re: Build bot notifications

[Joshua Root]

On 23/8/2023 22:25, Kirill A. Korinsky via macports-dev wrote:

Folks,

Is it possible to have a email notification when build bot have failed 
to build a port where I'm a maintainer?


This is a feature that our buildbot has, but it stopped working at some 
point and most of us don't have the access needed to debug it. Probably 
at minimum it needs to be updated to submit mail with authentication via 
mail.macports.org.


- Josh

Re: Xcode PortGroup: Xcode compiles code twice?

[Joshua Root]

On 16/8/2023 04:29, Jason Liu wrote:

Hi everyone,

I'm working on a Portfile that uses the xcode PortGroup, and I've 
noticed something that surprised me: It seems that the MacPorts build is 
compiling the source code during the build phase, and then compiling the 
source code AGAIN during the destroot phase? Is this correct, or am I 
starting to hallucinate? Because when I add a 'build {}' to my Portfile, 
which in theory should cause nothing to be compiled, all of the compiled 
products are still somehow coming into existence and getting placed into 
${destroot}.


I don't know if your project is in fact building things twice, but 
clearing the build phase doesn't prove anything one way or the other, 
because the install target depends on the targets that build the program 
and will thus run them first. You will usually see a similar thing 
happen if you just run 'make install' with a makefile based project.


- Josh

Re: Why some ports seem to install universal when I do not request it ?

[Joshua Root]

On 15/8/2023 05:06, Christopher Jones wrote:

Hi All,

Just migrated from an intel to AppleSilicon machine.

Reinstalling MacPOrts, from scratch off course, I’ve noticed some ports get 
install universal, when it’s not something I have requested. e.g.

--->  Fetching archive for zlib
--->  Attempting to fetch zlib-1.2.13_0+universal.darwin_22.arm64-x86_64.tbz2 
from https://packages.macports.org/zlib
--->  Attempting to fetch 
zlib-1.2.13_0+universal.darwin_22.arm64-x86_64.tbz2.rmd160 from 
https://packages.macports.org/zlib
--->  Installing zlib @1.2.13_0+universal
--->  Cleaning zlib
--->  Deactivating zlib @1.2.13_0
--->  Cleaning zlib
--->  Activating zlib @1.2.13_0+universal

zlib has a universal port, but its not a default one, and I didn’t request it, 
nor have I ever set my default settings to always install universal.

As I am new to apple silicon machines, is this normal ?


Most likely you installed a port that supports x86_64 but not arm64. The 
behaviour is the same as as when you install a port that only supports 
i386 on an x86_64 system.


- Josh

Re: Problem fetching with git in MacPorts

[Joshua Root]

On 17/5/2023 07:44, Robert Kennedy wrote:
I am unable to fetch a file in a git repo using MacPorts.  I get an SSL 
expired error.



fatal: unable to access
'https://codeberg.org/schilytools/schilytools.git/': *SSL
certificate problem: certificate has expired*
*Command failed: /usr/bin/git clone* --progress --depth=1
https://codeberg.org/schilytools/schilytools.git

/opt/local/var/macports/build/_Users_grinch_Development_MacPorts_local-repo_ports_devel_smake/smake/work/schilytools-2023-04-19
 2>&
Exit code: 128


Please note that MacPorts is trying to use "*/usr/bin/git*" which is 
OLD.  I can fetch the archive in the Terminal using the recent version 
of git installed by MacPorts at "*/opt/local/bin/git*".


"*/opt/local/bin/git*" is also in my $PATH.  When I run "*which git*", I 
get "*/opt/local/bin/git*".


If there a config setting in MacPorts to tell it to use git located at 
"/opt/local/bin/git"?


The Portfile option is 'git.cmd'.

- Josh

Re: Help getting new port nrsc5 working

[Joshua Root]

On 17/4/2023 09:01, bl...@netjibbing.com wrote:
It looks like I had a previous partial install that was causing this 
error. I edited the CMakeLists.txt and got it to build, which in turn 
cleaned up the edited file. Doing a port clean and installation it’s now 
working as expected.


18291.png
nrsc5: new port by trodemaster · Pull Request #18291 · 
macports/macports-ports 


github.com 




Thanks for the help!


Yes, I saw the installed version of the header in your log. Building 
when there is an older version of the same software installed is 
something that ports need to be able to do, since it happens every time 
they are upgraded to a new version. It's not clear from the above what 
changes you made to CMakeLists.txt to get it to build, but if it didn't 
involve fixing the include order, my advice stays the same.


- Josh

Re: Help getting new port nrsc5 working

[Joshua Root]

On 9/4/2023 06:13, bl...@netjibbing.com wrote:
I have had this nrsc5 port sitting around for a long time in a broken 
state. Would you happen to have any suggestions on how to address this 
build error?


Full build log: 
https://gist.github.com/trodemaster/2ef9d94db3b894ff690ebd365afed0cd 

WIP port file: 
https://github.com/trodemaster/blakeports/blob/main/audio/nrsc5/Portfile 




/opt/local/var/macports/build/_opt_mports_blakeports_audio_nrsc5/nrsc5/work/nrsc5-59bc2968485635c16c7250696abc3e8ff765b72d/src/nrsc5.c:548:15:
 error: conflicting types for 'nrsc5_pipe_samples_cu8'
NRSC5_API int nrsc5_pipe_samples_cu8(nrsc5_t *st, const uint8_t 
*samples, unsigned int length)

               ^
/opt/local/include/nrsc5.h:578:5: note: previous declaration is here
int nrsc5_pipe_samples_cu8(nrsc5_t *st, uint8_t *samples, unsigned int 
length);

     ^


From the log:

:info:build cd 
/opt/local/var/macports/build/_opt_mports_blakeports_audio_nrsc5/nrsc5/work/build/src 
&& /usr/bin/clang -DGIT_COMMIT_HASH=\"unknown\" -D_GNU_SOURCE 
-I/opt/local/include 
-I/opt/local/var/macports/build/_opt_mports_blakeports_audio_nrsc5/nrsc5/work/build/src 
-I/opt/local/var/macports/build/_opt_mports_blakeports_audio_nrsc5/nrsc5/work/nrsc5-59bc2968485635c16c7250696abc3e8ff765b72d/include 
-pipe -Os -DNDEBUG -I/opt/local/include 
-isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX13.sdk -arch 
arm64 -isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX13.sdk 
-mmacosx-version-min=13.0 -fPIC --std=gnu11 -O3 -Wall -MD -MT 
src/CMakeFiles/nrsc5_object.dir/nrsc5.c.o -MF 
CMakeFiles/nrsc5_object.dir/nrsc5.c.o.d -o 
CMakeFiles/nrsc5_object.dir/nrsc5.c.o -c 
/opt/local/var/macports/build/_opt_mports_blakeports_audio_nrsc5/nrsc5/work/nrsc5-59bc2968485635c16c7250696abc3e8ff765b72d/src/nrsc5.c


The first '-I/opt/local/include' in that command is before the two -I 
flags specifying locations inside the workpath. The order that -I flags 
are specified on the command line controls the order in which 
directories are searched when a header is included. So 
/opt/local/include/nrsc5.h is found instead of the nrsc5.h in the source 
directory.


You'll most likely need to patch the CMakeLists.txt to fix this. Find 
where those flags are added and ensure that the internal locations are 
added to the start of the flags, and externally specified flags are 
added to the end. IIRC, cmake has BEFORE and AFTER options you can 
specify when adding include directories.


- Josh

Re: MacPorts install guide and Xcode dependency

[Joshua Root]

On 4/4/2023 10:49, contextnerror wrote:

Currently guide.macports.org tells new users to download a full install of 
Xcode before installing MacPorts. While some ports do require this, most ports 
still work with just a copy of the command line tools. Should a CLT 
installation be the recommended method now?


The recommendation is Xcode + CLTs because that gives the highest chance 
that things will Just Work. As you note, you might be fine with just the 
CLTs. You also might be fine with neither if everything you install 
happens to be available as a binary archive.


It's fine to expand the explanations in the Guide to cover these 
complexities, as long as care is taken in how the information is 
presented. We don't want readers to take away a misleading summary like 
"The CLTs are all you need."


- Josh

Re: PyTorch CI Build Issue Request for Help

[Joshua Root]

On 24/3/2023 01:41, Chris Jones wrote:


requiring AVX512 is a really rather stringent requirement, most machines 
will not have these instructions.


In fact, even if the build bots where able to make binary tarballs, if 
they are using these instructions (without runtime capability checks) 
then it would quite possibly render these binaries unusable on most 
hardware.


What we normally require is use of these sorts of instruction sets 
(AVX512, AVX2) is by default turned off so that the binaries produced 
are usable on more hardware. Then, if you want to allow these 
instructions on machines where they are available, provide a 'native' 
variant which when selected forces the user to build from source, and 
allows the build configuration to test for and if available use these 
instructions.


Whether it's requiring AVX512 at runtime or just needs that support in 
the compiler isn't clear, and would certainly be another thing to check 
while fixing this.


- Josh

Re: PyTorch CI Build Issue Request for Help

[Joshua Root]

On 23/3/2023 23:26, Steven Smith wrote:

PyTorch build and runs fine locally, but the CI consistently fails with error 
below. This issue has created unnecessary delays in merging new PT versions.


2023-03-18T18:24:32.7624930Z CMake Error at 
third_party/fbgemm/CMakeLists.txt:76 (message):
2023-03-18T18:24:32.7638400Z   A compiler with AVX512 support is required.


You would need to examine the cmake logs (CMakeOutput.log + 
CMakeError.log) and the CMakeLists.txt in this subdir to see how this 
check is being done. Maybe the wrong compiler is being used for the 
check; maybe it's buggy in some other way.



A successful build uses:


:debug:build CXX='/usr/bin/clang++'
…
:info:build -- Performing Test C_HAS_AVX512_2 - Success
…
:info:build -- Performing Test CXX_HAS_AVX512_2 - Success


That's coming from a different CMakeLists.txt (which apparently works 
correctly since the same output is in the log of the failing build).



I believe that the right compiler is set. Any suggestions, or does this 
complicated build fail with the CI box?

Details at this PR:

py-pytorch: Update to version 2.0.0 by essandess · Pull Request #18009 · 
macports/macports-ports
https://github.com/macports/macports-ports/pull/18009


The current version fails on the buildbot for all OS versions except 
Ventura. The logs that are still available for x86_64 show the same 
error as GitHub Actions. 



So it appears that pushing the update won't make it more broken, but it 
still is quite broken. At the very least, binaries won't be built for 
most platforms, and if it fails on the buildbot then it will most likely 
fail for local builds too on at least some subset of machines.


- Josh

Re: Java portgroup default fallback?

[Joshua Root]

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.


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.


- Josh

Java portgroup default fallback?

[Joshua Root]

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: ports website says port has been deleted ... but it is there.

[Joshua Root]

Thanks!

On 4/2/2023 19:22, Arjun Salyan wrote:

Updated to 2.8.1

https://github.com/arjunsalyan/macports-ubuntu/commit/2e35375872773bbdd86e21374883a8e4302a2b92
 
<https://github.com/arjunsalyan/macports-ubuntu/commit/2e35375872773bbdd86e21374883a8e4302a2b92>

https://github.com/macports/macports-webapp/commit/89b85aef53bd83e5c7b6981fd123e13263defc48
 
<https://github.com/macports/macports-webapp/commit/89b85aef53bd83e5c7b6981fd123e13263defc48>


On 04-Feb-2023, at 5:11 AM, Joshua Root  wrote:

Yeah, failing to parse on that system would also do it. The general 
rule is to not use new options unconditionally until they have been in 
a release for 2 weeks.


- Josh

On 4/2/2023 04:23, Ken Cunningham wrote:
oh, maybe it’s because the ports installation of macports does not 
accept the extract.rename option yet because it hasn’t been updated yet…

K
On Feb 3, 2023, at 07:55, Ken Cunningham 
 wrote:


Perhaps because the buildbots are down? Not sure why else this 
would say the port is deleted..


https://ports.macports.org/port/codeblocks-devel/

but here it is:

https://github.com/macports/macports-ports/blob/master/devel/codeblocks-devel/Portfile

Ken

Re: ports website says port has been deleted ... but it is there.

[Joshua Root]

Yeah, failing to parse on that system would also do it. The general rule 
is to not use new options unconditionally until they have been in a 
release for 2 weeks.


- Josh

On 4/2/2023 04:23, Ken Cunningham wrote:

oh, maybe it’s because the ports installation of macports does not accept the 
extract.rename option yet because it hasn’t been updated yet…

K


On Feb 3, 2023, at 07:55, Ken Cunningham  
wrote:

Perhaps because the buildbots are down? Not sure why else this would say the 
port is deleted..

https://ports.macports.org/port/codeblocks-devel/

but here it is:

https://github.com/macports/macports-ports/blob/master/devel/codeblocks-devel/Portfile

Ken

Re: Problem Building Port After Upgrading Macports from 2.8.0 to 2.8.1

[Joshua Root]

If you sync from git you will get the change immediately. For rsync it 
can take up to a couple of hours I think.


- Josh

On 1/2/2023 07:57, Robert Kennedy wrote:
Thanks Josh fot quickly identifying the issue introduced in MacPorts 
2.8.1 and making the necessary fix.


totp-cli is still not building.  I still get the same extract.rename 
related error.
But I suspect it will take a day before the fix is pushed out to the 
main repo.

I will try again tomorrow.

Rob

*From:* Joshua Root 
*Sent:* January 31, 2023 3:43 PM
*To:* Robert Kennedy 
*Cc:* MacPorts Development 
*Subject:* Re: Problem Building Port After Upgrading Macports from 2.8.0 
to 2.8.1

On 1/2/2023 04:49, Robert Kennedy wrote:

 Error: Failed to extract totp-cli: extract.rename: multiple
 directories exist in
 
/opt/local/var/macports/build/_Users_grinch_Macports_ports_security_totp-cli/totp-cli/work:
 etc etc etc


What has changed between Macports 2.8.0 and 2.8.1 to cause this new error?


The short version: the github portgroup behaves differently when the
extract.rename option exists, and the golang portgroup interacted badly
with that. It should be fixed now.

- Josh

Re: Problem Building Port After Upgrading Macports from 2.8.0 to 2.8.1

[Joshua Root]

On 1/2/2023 04:49, Robert Kennedy wrote:

Error: Failed to extract totp-cli: extract.rename: multiple
directories exist in

/opt/local/var/macports/build/_Users_grinch_Macports_ports_security_totp-cli/totp-cli/work:
etc etc etc


What has changed between Macports 2.8.0 and 2.8.1 to cause this new error?


The short version: the github portgroup behaves differently when the 
extract.rename option exists, and the golang portgroup interacted badly 
with that. It should be fixed now.


- Josh

Re: Maintainer Abuse

[Joshua Root]

On 2022-12-30 16:05 , Fred Wright wrote:


On Thu, 29 Dec 2022, Joshua Root wrote:
If the change to py-serial you're referring to was mine of Dec 13, 
that was part of a mass update to adopt a new feature in MacPorts 
2.8.0, which only touched openmaintainer and nomaintainer ports. IMO 
it was well within the definition of a minor change.


That isn't the change I was referring to (but see below); I was 
referring to 66c7d25d427.  I had no objection to adding the py310 
subport (though checking still would have been appropriate), but I 
strongly object to the removal of the py34-py36 subports.  And no change 
that removes a capability can be considered "low risk" by any stretch of 
the imagination.


OK. I agree that deleting a port requires its maintainer's approval.

- Josh

Re: Maintainer Abuse

[Joshua Root]

On 2022-12-29 15:59 , Fred Wright wrote:


Twice recently I've had changes made to ports I maintain without 
respecting the maintainer timeout (and not for any urgent 
security-related reasons).  The first was py-serial, where the change 
was merged without waiting for the maintainer timeout.  And just now I 
see that someone abused their write access to bypass the PR mechanism 
entirely for a gpsd update, so that I wasn't even notified of the 
change.  And I've had good reason to hold off on updating gpsd, due to 
its missing dependency on asciidoctor, which is currently broken on some 
platforms due to the insistence on tying it to a broken version of ruby, 
which I've actually been working on fixing.


Is this now the Wild West?

Fred Wright


Hi Fred,

Sorry you've been put out by these commits. Both of these ports are 
marked as openmaintainer, which according to the project policy [1] 
means that minor changes are allowed without obtaining the maintainer's 
permission first. That certainly isn't carte blanche to do whatever you 
want, but it does mean that pushing changes directly isn't necessarily 
against the rules.


The definition of a minor update is left somewhat vague, but can 
probably be thought of as synonymous with low-risk. I would say anything 
beyond simple bugfixes, and certainly anything that changes the API or 
ABI, should be run by the maintainer first. And as the policy says, the 
committer is responsible for ensuring that the changes work properly. If 
you push a change to someone else's port, you should consider yourself 
"on the hook" for fixing anything that breaks as a result.


When in doubt, run it by the maintainer.

I'm not familiar enough with gpsd to say whether the recent update was 
minor or not. Marius, please work with Fred to resolve any issues that 
it may have caused.


If the change to py-serial you're referring to was mine of Dec 13, that 
was part of a mass update to adopt a new feature in MacPorts 2.8.0, 
which only touched openmaintainer and nomaintainer ports. IMO it was 
well within the definition of a minor change.


If you would like your permission to be required for all changes to 
these ports, the openmaintainer tag can be removed from the maintainers 
option.


HTH,
- Josh

[1] 

Re: ImageMagick Upgrade to version 7.1.0-54 Hitting OpenCL ld errors

[Joshua Root]

Those are OpenCL functions, so you'd normally link with '-framework 
OpenCL' to get them. I notice the brew formula configures with 
--disable-opencl.


- Josh

On 2022-12-12 02:34 , Steven Smith wrote:
I’m trying to upgrade the ImageMagick Portfile to version 7.1.0-54 and 
am hitting linker errors with OpenCL.


I see that homebrew has a working version at 
https://github.com/Homebrew/homebrew-core/blob/master/Formula/imagemagick.rb , so I’ve tried to make sure I’ve copies their setup, but am still hitting this issue, observed a year ago here, https://trac.macports.org/ticket/64087 .


Does anyone have a suggestion for locating these symbols?

:info:build libtool: link: /usr/bin/clang 
-dynamiclib  -o MagickCore/.libs/libMagickCore-7.Q16.10.dylib  MagickCore/.libs/libMagickCore_7_Q16_la-accelerate.o  … MagickCore/.libs/libMagickCore_7_Q16_la-xwindow.o   -L/opt/local/lib -L/opt/local/lib/libomp -lomp -llcms2 -lxml2 -lfontconfig -lfreetype -lXext -lSM -lICE -lX11 -lXt -lbz2 -lz -lzip -lltdl -lm -lpthread  -Os -arch x86_64 -Wl,-headerpad_max_install_names -Wl,-syslibroot -Wl,/Library/Developer/CommandLineTools/SDKs/MacOSX12.sdk -arch x86_64   -pthread -install_name  /opt/local/lib/libMagickCore-7.Q16.10.dylib -compatibility_version 11 -current_version 11.0 -Wl,-single_module
:info:build ld: warning: directory not found for option 
'-L/opt/local/lib/ImageMagick-7.1.0'

:info:build Undefined symbols for architecture x86_64:
:info:build   "_clBuildProgram", referenced from:
:info:build       _InitializeOpenCL in libMagickCore_7_Q16_la-opencl.o
:info:build   "_clCreateBuffer", referenced from:
:info:build       _InitializeOpenCL in libMagickCore_7_Q16_la-opencl.o
:info:build   "_clCreateCommandQueue", referenced from:
:info:build       _InitializeOpenCL in libMagickCore_7_Q16_la-opencl.o
:info:build   "_clCreateContext", referenced from:
:info:build       _InitializeOpenCL in libMagickCore_7_Q16_la-opencl.o
:info:build   "_clCreateKernel", referenced from:
:info:build       _InitializeOpenCL in libMagickCore_7_Q16_la-opencl.o
:info:build   "_clCreateProgramWithBinary", referenced from:
:info:build       _InitializeOpenCL in libMagickCore_7_Q16_la-opencl.o
:info:build   "_clCreateProgramWithSource", referenced from:
:info:build       _InitializeOpenCL in libMagickCore_7_Q16_la-opencl.o
:info:build   "_clEnqueueMapBuffer", referenced from:
:info:build       _InitializeOpenCL in libMagickCore_7_Q16_la-opencl.o
:info:build   "_clEnqueueNDRangeKernel", referenced from:
:info:build       _InitializeOpenCL in libMagickCore_7_Q16_la-opencl.o
:info:build   "_clEnqueueReadBuffer", referenced from:
:info:build       _InitializeOpenCL in libMagickCore_7_Q16_la-opencl.o

Re: using /usr/bin/python3 on Ventura +

[Joshua Root]

On 2022-11-27 13:18 , Ken Cunningham wrote:

Well, it didn’t take very long for that to be a problem. Building llvm and 
clang-9.0 went OK, but building lldb-9.0 fails:

- Check size of el_rfunc_t - done
-- Found PythonLibs: 
/opt/local/Library/Frameworks/Python.framework/Versions/3.10/lib/libpython3.10.dylib 
(found version "3.10.8")  CMake Error at 
tools/lldb/cmake/modules/LLDBConfig.cmake:234 (message):
   Found incompatible Python interpreter (3.9) and Python libraries (3.10)
Call Stack (most recent call first):
   tools/lldb/CMakeLists.txt:20 (include)


This is just cmake being extra helpful and finding the latest python 
version on the system. You're explicitly overriding PYTHON_EXECUTABLE so 
that doesn't match what cmake is finding itself. You would also need to 
set an explicit Python_ROOT_DIR or Python_LIBRARIES etc for things that 
need those.


- Josh

Re: Weird outdated state of ports (in webapp)

[Joshua Root]

I see however that the server's HTTP responses do not have 
Cache-Control:, Expires:, or Last-Modified: headers, so clients don't 
have much to go on when deciding how long to cache the content. We could 
likely get better results by setting some or all of these appropriately.


- Josh

On 2022-11-4 09:29 , Mojca Miklavec wrote:

Hi,

I'm sorry, please ignore my question.

I strongly suspect that my browser was simply caching content for too
long and browsing back and forth never actually updated the contents
with the latest version.

Opening the site from another browser revealed new contents, and after
pressing the initial browser hard enough it eventually gave up as
well.

Mojca

On Thu, 3 Nov 2022 at 22:49, Mojca Miklavec wrote:


Hi,

I was looking at
 https://ports.macports.org/port/kicad/details/
which says that we are shipping kicad 6.0.7 (while we have 6.0.8),
builds point to logs for 6.0.7,
livecheck reports that 6.0.8 is the latest version (but it is 6.0.9).

None of these updates are super fresh, so I'm wondering if something
is perhaps stuck on the server.

Mojca

Re: Review a fix for OpenSSL3 CVE

[Joshua Root]

On 2022-11-3 06:56 , Clemens Lang wrote:

Speaking of this CVE… we don't actually build with the common set of
security flags in MacPorts, do we? We should probably look into getting
the common set -fstack-protector-strong -fstack-clash-protection -fPIE
(probably not required on modern macOS?) -D_FORTIFY_SOURCE=3
-fcf-protection=full (on x86_64) and maybe -Wl,-bind_at_load
-Wl,-read_only_stubs.

Does anybody have a good overview of what the recommended set of
security compiler flags is on macOS? Quick testing suggests everything
but -fstack-protector-strong and -D_FORTIFY_SOURCE is already on by
default.


_FORTIFY_SOURCE is also on by default since 10.6. 



Though that's set to 2 not 3, it looks like setting it to anything 
higher than 2 does nothing extra in libc at least.


Apple has generally been pretty good about enabling these hardening 
measures. The difficult work would be figuring out on which OS and Xcode 
versions these options can be used and are not already enabled.


- Josh

Re: Using platforms in 2.8.0

[Joshua Root]

On 2022-11-1 13:41 , Nils Breunese wrote:

Joshua Root  wrote:

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?


That's right, `uname -p` outputs i386 on x86_64 Macs.


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}?


You need to check ${configure.build_arch}, because that is not 
restricted to a single value on most OS versions, so there is no 1:1 
correspondence between ${os.arch} and the architecture you should be 
installing the port for. A user on an arm machine could ask for x86_64, 
and a user on an x86_64 machine could ask for i386.


- Josh

Re: Using platforms in 2.8.0

[Joshua Root]

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.


- Josh

Re: Using platforms in 2.8.0

[Joshua Root]

On 2022-11-1 11:45 , Nils Breunese wrote:

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?


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}

- Josh

Re: Using platforms in 2.8.0

[Joshua Root]

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"} {
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.


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.


- Josh

Re: Using platforms in 2.8.0

[Joshua Root]

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.

- Josh

Re: which package to install for macOS 13

[Joshua Root]

On 2022-10-26 06:38 , Helmut K. C. Tessarek wrote:
There's no package to install for macOS 13. Does this mean that I 
can't use MacPorts on Ventura?


Or can I just install the Monterey package?


Never mind. It just showed up. ;-)

Thanks for providing the package for Ventura!


For future reference, you can always build from the source tarball if 
there's no binary .pkg for your OS version.


- Josh

Re: macOS 13 minimum required Xcode

[Joshua Root]

On 2022-10-25 10:44 , Aaron Madlon-Kay wrote:

Hi all.

I have just upgraded to macOS 13 and am attempting to migrate my MacPorts 
installation. When I try to install a port I get the following error:


Error: The installed version of Xcode (14.0.1) is too old to use on the 
installed OS version. Version 14.1 or later is recommended on macOS 13.


A newer Xcode has not been released at the moment, though I am sure a release 
is imminent. In the meantime is there a way to bypass this check temporarily?

Thanks,
Aaron


Be aware that that check is there because Xcode 14.0.1 doesn't have the 
macOS 13 SDK. It looks like you can download the 14.1 release candidate 
without a paid developer account (you have to sign in, but any Apple ID 
suffices.)


- Josh

Re: Using platforms in 2.8.0

[Joshua Root]

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

or:

if {$build_arch eq "arm64"} {
...
}

There is no arch comparison possible in the platforms option, because 
that job is already being done by the supported_archs option. If you 
have some really complicated compatibility requirement that can't be 
expressed any other way, I guess you can set platforms differently based 
on the arch, or supported_archs differently based on the platform.


- Josh

Re: Using platforms in 2.8.0

[Joshua Root]

On 2022-10-22 20:34 , Kirill A. Korinsky wrote:

Does it support somehow arch?


I'm not sure what you're asking exactly. There was already the 
supported_archs option of course, and either a specific set of archs or 
"noarch" is included in the archive filename.


- Josh