Re: Macports, pip, and vent

[Joshua Root]

I’m setting up to use a collection of python codes developed by someone else, 
and to run them I’ll need to use some python modules/packages that aren’t 
available via MacPorts (nvector, pykml, and stripy).  From looking over old 
posts it appears that the best way to do this is to install all of the packages 
available from MacPorts either in my main environment or in the virtual 
environment and the PyPI-available packages only in the virtual environment.  
I’ve not fiddled with venv stuff before - I assume that everything available in 
my main environment will also be available in the virtual environment unless it 
is “hidden” behind something installed in the virtual environment.  Is this 
correct?


This is the case only if you use the --system-site-packages option. 



If that option is used, I would guess that pip will consider 
requirements to be satisfied by MacPorts-installed modules as long as 
the version is acceptable, and install a different version in the venv 
if not. But I haven't tested that theory. Generally 
--system-site-packages is avoided in order to prevent unexpected 
behaviour changes due to the presence of random other modules. (Simple 
severe failure case: an installed module is buggy and crashes on import. 
Anything that inspects all installed modules by importing them will then 
hit that crash.)


- Josh

Re: what MacPorts port would create a TAGS file (looks like a history helper, rlwrap?)

[Joshua Root]

what MacPorts port would create a TAGS file (looks like a history
helper, rlwrap?)


https://www.gnu.org/software/emacs/manual/html_node/emacs/Tags-Tables.html

Re: force rebuild a port

[Joshua Root]

Richard L. Hamilton wrote:


A URL likehttps://ports.macports.org/port/harfbuzz/builds/  


in your browser (but put in the port name you want in place of harfbuzz) will 
show what if anything is pre-built for that port. Other views are available, 
but don't ask me if there's one that shows everything pre-built for a specific 
macOS version; if there is one, I haven't found it. I'm just another user, not 
a maintainer, and not familiar with everything; I knew some of these things 
were possible, but had to dig a bit to be able to describe them.


You can show only the builds from a certain OS version using the "Select 
builder(s):" popup menu. However, builds are attempted for all ports, 
not just the ones for which the archives can be made publicly available. 
To see if there is an archive available for a port, you would have to 
check the appropriate subdirectory on packages.macports.org, e.g. 
.


See the thread starting here for a previous discussion of some of the 
complexities around whether binary archives are available: 



- Josh

Re: MacPorts 2.9.3 has been released

[Joshua Root]

Dave Horsfall wrote:


I hadn't got around to installing 2.9.2 yet (I do those admin tasks on
Mondays); will 2.9.3 drop cleanly onto 2.9.1?

I ask because I got bitten by a Linux upgrade; apparently Debian (if not
all of them) requires all intermediate upgrades be performed...


We aim for direct upgrades to work across gaps of up to one year. In 
practice, base upgrades often work with much longer gaps. Port upgrades 
often don't if there is any renaming or replacing involved.


- Josh

Re: MacPorts 2.9.3 has been released

[Joshua Root]

On 4/4/2024 15:29, Peter West wrote:
I’ve installed 2.9.3. As with 2.9.2, port selfupdate did not update the 
port install. Is this something you’re aware of?


It always takes a little time for releases to propagate to the rsync 
mirrors. 2.9.2 took longer than usual because of some downtime for the 
master server. 2.9.3 is on the mirrors now.


I’ve been installing these to try to fix the “missing m4” problem, but 
neither seemed to fix it. Should I add a comment to one of the number of 
issues in trac concerning this?


In any case, I’m downgrading to Xcode 15.1.


We don't ship m4 with MacPorts base, so a new base release won't do 
anything for missing m4 issues. Ultimately Apple needs to release a new 
command line tools version that includes m4 again, and in the meantime 
each port that uses m4 needs to either run it by the name 'gm4' instead 
(since Apple still included that), or declare a dependency on the m4 
port. If you notice a port is affected and there is no ticket open for 
it, please open one.


- Josh

MacPorts 2.9.3 has been released

[Joshua Root]

The MacPorts Project is pleased to announce the release of version
2.9.3. This is a bugfix release with small changes only. See the
ChangeLog [1] for the list of changes.

If you already have MacPorts installed, the preferred method for
updating is to run:

  sudo port selfupdate

For new installs, there are also package installers available for macOS
versions ranging from macOS 14 Sonoma all the way back to 10.4 at [2]. 
The source is also available as tarballs compressed with gzip or bzip2, 
or from the git tag [3].


Detached PGP signatures for the disk images, packages and source
tarballs have been made with my key, which is available on the
keyservers and my MacPorts wiki page [4], the fingerprint being:

0x01FF673FB4AAE6CD: C403 7936 5723 6DCF 2E58  0C02 01FF 673F B4AA E6CD

Josh
(on behalf of the MacPorts Port Managers)

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


OpenPGP_signature.asc
Description: OpenPGP digital signature

MacPorts 2.9.2 has been released

[Joshua Root]

The MacPorts Project is pleased to announce the release of version
2.9.2. This is a bugfix release with small changes only. See the
ChangeLog [1] for the list of changes.

If you already have MacPorts installed, the preferred method for
updating is to run:

 sudo port selfupdate

For new installs, there are also package installers available for macOS
versions ranging from macOS 14 Sonoma all the way back to 10.4 at [2]. 
The source is also available as tarballs compressed with gzip or bzip2, 
or from the git tag [3].


Detached PGP signatures for the disk images, packages and source
tarballs have been made with my key, which is available on the
keyservers and my MacPorts wiki page [4], the fingerprint being:

0x01FF673FB4AAE6CD: C403 7936 5723 6DCF 2E58  0C02 01FF 673F B4AA E6CD

Josh
(on behalf of the MacPorts Port Managers)

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


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: Library libtdbc used in restore_ports script is unsigned

[Joshua Root]

On 21/3/2024 23:33, Eric Gallager wrote:

On Thu, Mar 21, 2024 at 12:53 AM Joshua Root  wrote:

Hopefully we can ship automatic migration in MacPorts base soon and
retire restore_ports.tcl.



Yeah, please notify me once this happens; I've been reluctant to
update from Big Sur just due to how much of a pain the
restore_ports.tcl process can be...


If you want to help this happen faster, please feel free to test the 
migration branch of base: 
<https://github.com/neverpanic/macports-base/tree/migration>


or this prototype I recently made of a slightly different method, which 
among other things will not reinstall ports that have 'platforms any' or 
'platforms {darwin any}': 
<https://github.com/jmroot/macports-contrib/tree/migrate/migrate>


Bear in mind this is bleeding edge stuff; there are almost certainly 
still bugs, so we'd love to know about them so we can fix them.


- Josh

Re: Library libtdbc used in restore_ports script is unsigned

[Joshua Root]

I recently upgraded from macOS 13.x to macOS 14.3.1 Sonoma and started running 
the MacPorts Migration process. I got interrupted and did the minor macOS 
update to macOS 14.4 and tried to run the “restore_ports.tcl” script, which 
worked for a while but then threw an error about the libtdbc library being 
unsigned. I don’t know if this is something that changed recently. What is the 
recommended procedure for fixing this? Uninstall all the ports and reinstall 
them?

This is the full error:
dlopen(/opt/local/lib/tdbc1.1.7/libtdbc1.1.7.dylib, 0x0006): tried: 
'/opt/local/lib/tdbc1.1.7/libtdbc1.1.7.dylib' (code signature in 
<3CE89C0F-A387-3934-8B3D-5834290B7BD3> '/opt/local/lib/tdbc1.1.7/libtdbc1.1.7.dylib' 
not valid for use in process: mapped file has no cdhash, completely unsigned? Code has to 
be at least ad-hoc signed.), 
'/System/Volumes/Preboot/Cryptexes/OS/opt/local/lib/tdbc1.1.7/libtdbc1.1.7.dylib' (no such 
file), '/opt/local/lib/tdbc1.1.7/libtdbc1.1.7.dylib' (code signature in 
<3CE89C0F-A387-3934-8B3D-5834290B7BD3> '/opt/local/lib/tdbc1.1.7/libtdbc1.1.7.dylib' 
not valid for use in process: mapped file has no cdhash, completely unsigned? Code has to 
be at least ad-hoc signed.)
 while executing
"load /opt/local/lib/tdbc1.1.7/libtdbc1.1.7.dylib Tdbc"
 ("package ifneeded tdbc 1.1.7" script)
 invoked from within
"package require tdbc"
 (file "/opt/local/lib/tcl8/8.6/tdbc/sqlite3-1.1.7.tm" line 13)
 invoked from within


This is likely an unfortunate interaction with a feature of tclsh and a 
feature of macOS. Tcl will look for packages in the same prefix as the 
interpreter that is running the script, and in this case, the tclsh 
shipped with MacPorts base finds a tdbc library installed by a port. The 
former is signed and the latter is not, and macOS doesn't allow signed 
executables to load unsigned libraries.


The most straightforward workaround is to use a different path for the 
interpreter. /opt/local/bin/port-tclsh is a symlink to the actual 
tclsh8.6 in a subdirectory, so running the script like this should work:


sudo `readlink /opt/local/bin/port-tclsh` ./restore_ports.tcl

Hopefully we can ship automatic migration in MacPorts base soon and 
retire restore_ports.tcl.


- 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: ld: can't write output file for architecture ppc

[Joshua Root]

raf wrote:


I've been told that macports needs to be selfupdated at least annually.
If it's been too long between selfupdates, it can fail (It did for me once
on 10.6.8). You might need to reinstall macports instead of selfupdate.

To any expoerts out there, does that sound helpful?


I wouldn't uninstall just yet, and definitely not without making a 
backup first, as it will remove the possibility of easily restoring the 
old versions.


When you upgrade, MacPorts will only deactivate the old versions of 
ports (unless specifically told to immediately uninstall them). So you 
should be able to activate the older versions to get back to the state 
you were in previously. It should be pretty obvious which is which based 
on the timestamps in 'port -v installed'.


If you want to try to go ahead with upgrading, I would first 'port 
deactivate active' and then 'port install' (not upgrade) the ports you 
want to use. That will still use anything you already have installed if 
possible, saving some build time, and will avoid any issues with ancient 
variants, replaced ports and such.


If that still fails, you still have the option of reactivating the old 
versions.


- Josh

Re: MacPorts vs. Apple compiler issues, Handle

[Joshua Root]

On 13/3/2024 20:52, Riccardo Mottola wrote:
I found a minor patch by Firefox to solve this namespace collision. So 
for whatever reason Apple's did differently, it now compiles on all 
compilers.


However clang9 generates a crashing executable. I tried on both 10.11 
and 10.13.


- Apple clang: works fine
- MacPorts clang 7: compiles & works
- MacPorts clang 9 : compiles but fails

anybody has seen this behaviour in other software, perhaps smaller and 
easier to test than ArcticFox?


Yes, any number of programs have had bugs that only became apparent when 
building with a newer compiler. But that's a very broad category, so 
without knowing the nature of the crash you're seeing, it's impossible 
to say what else might have had a similar problem.


Bugs in clang are not unknown, but far more common is programs relying 
on certain behaviour for operations that have undefined behaviour 
according to the language standard. Or sometimes the layout of memory 
just shifts slightly, causing a previously benign buffer overflow to do 
damage. Sometimes a newer compiler will also default to a newer version 
of the language, so if that's the cause of the differing behaviour, you 
can use -std to change it back.


Otherwise, you have to do the hard work of debugging: Look at the crash 
report to see where and how the code is crashing, pay attention to 
compiler warnings, and systematically eliminate possibilities of what 
could be going wrong. Building with clang's sanitizers may be helpful, 
particularly -fsanitize=address and -fsanitize=undefined, though in a 
code base this size I wouldn't be surprised if they also detected 
hundreds of other potential issues.


- Josh

Re: MacPorts vs. Apple compiler issues, Handle

[Joshua Root]

MacPort installs:
$ clang-mp-9.0 --version
clang version 9.0.1

Apple:
$ clang --version
Apple LLVM version 9.1.0 (clang-902.0.39.1)

Is there some Apple "trick" or is it the slight compiler difference in
version?


The version difference is less slight than you might think. Apple clang 
version numbers are unrelated to the version number of the llvm.org 
release they are based on. Apple clang 9.1.0 is closest to the clang-5.0 
port.


The name collision looks genuine however. I can only assume that 
MacTypes.h is not included or is preprocessed differently based on 
different defines in the other compiler.


- Josh

Re: is there a Fortran-90 compiler port? Where to get a FOSS Fortran-90 compiler?

[Joshua Root]

Yes. Or as Eric suggested, you can use 'port select' to create a 
'gfortran' link.


- Josh

On 2/3/2024 15:35, Kenneth Wolcott wrote:

Should I be using gfortran-mp-13?

ls /opt/local/bin | grep fortran
arm64-apple-darwin23-gfortran-mp-12
arm64-apple-darwin23-gfortran-mp-13
gfortran-mp-12
gfortran-mp-13
lfortran

Re: is there a Fortran-90 compiler port? Where to get a FOSS Fortran-90 compiler?

[Joshua Root]

Are you sure of that? Check e.g. 'port contents gcc13 | grep gfortran'.

- Josh

Kenneth Wolcott wrote:


Hi Noam;

   I do not have gfortran, therefore I must not have gcc?

Here is a filtered list of the ports that I have installed that pertain to gcc:
   gcc12 @12.3.0_4+stdlib_flag (active)
   gcc12-libcxx @12.3.0_4+clang14 (active)
   gcc13 @13.2.0_4+stdlib_flag (active)
   gcc13-libcxx @13.2.0_4+clang16 (active)
   gcc_select @0.1_10 (active)
   libgcc @7.0_0 (active)
   libgcc12 @12.3.0_4+stdlib_flag (active)
   libgcc13 @13.2.0_4+stdlib_flag (active)
   mpich-default @4.1.2_2+gcc13 (active)

Still confused...

Thanks,
Ken W.

On Fri, Mar 1, 2024 at 6:03 PM Bernstein, Noam CIV USN NRL WASHINGTON
DC (USA) https://lists.macports.org/mailman/listinfo/macports-users>> wrote:
>//>/Pretty sure that macports gcc installs gfortran by default, which is 
a f90 (and 95, and maybe f2003) compiler./

Re: Port reclaim unexpectedly wants to uninstall a subport, when the top level port is installed

[Joshua Root]

I'm puzzling over some weird "port reclaim" behaviour on one machine.  On the problematic machine, 
I installed py-matplotlib, which correctly installed py312-matplotlib.  But, if I run "port 
reclaim", it wants to uninstall py312-matplotlib as a "Unrequested ports without requested 
dependents found".

Then the script that I have that needs py-matplotlib fails.  I know I could 
request py312-matplotlib, but that then leads to a bit more work cleaning 
things up when I move to python313.

On the second machine, everthing works as expected.

Is there something I can do to rebuild the registry, assuming this is the 
problem?


Possibly you had previously installed py-matplotlib when an older python 
version was the default? In any case, running 'sudo port upgrade 
py-matplotlib' will refresh its registry data.


- Josh

MacPorts 2.9.1 has been released

[Joshua Root]

The MacPorts Project is pleased to announce the release of version
2.9.1. This is a bugfix release with small changes only. See the
ChangeLog [1] for the list of changes.

If you already have MacPorts installed, the preferred method for
updating is to run:

sudo port selfupdate

For new installs, there are also package installers available for macOS
versions ranging from macOS 14 Sonoma all the way back to 10.4 at [2]. 
The source is also available as tarballs compressed with gzip or bzip2, 
or from the git tag [3].


Detached PGP signatures for the disk images, packages and source
tarballs have been made with my key, which is available on the
keyservers and my MacPorts wiki page [4], the fingerprint being:

0x01FF673FB4AAE6CD: C403 7936 5723 6DCF 2E58  0C02 01FF 673F B4AA E6CD

Josh
(on behalf of the MacPorts Port Managers)

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



OpenPGP_signature.asc
Description: OpenPGP digital signature

MacPorts 2.9.0 has been released

[Joshua Root]

The MacPorts Project is happy to announce that the 2.9.0 version has now
been released. It is available via the usual methods:

   - selfupdate if you already have MacPorts installed
   - package installers [1] for macOS 14 Sonoma and all older releases
 back to Mac OS X 10.4 Tiger  (universal arm64/x86_64 for macOS 11+,
 i386/x86_64 for 10.6, i386/ppc for 10.4 and 10.5, and the rest
 x86_64)
   - source tarballs, both .tar.bz2 [2] and .tar.gz [3]
   - git tag [4]

The list of what's new in 2.9.0 can be found in the ChangeLog [5].

A big thanks to the developers for their hard work with all of the
various features and bug fixes in 2.9.0, and to all those who helped out
by reporting bugs or testing.

Detached PGP signatures for the pkg/dmgs and source tarballs have been
made with my key, which is available on the keyservers and my MacPorts
wiki page [6].

- Josh

[1] 
[2] 

[3] 


[4] 
[5] 
[6] 

PS, my PGP key ID is 0x01FF673FB4AAE6CD,
fingerprint C403 7936 5723 6DCF 2E58  0C02 01FF 673F B4AA E6CD



OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: /opt/local/var/macports

[Joshua Root]

Are there negative side-effects to moving this largish subdirectory to an 
external drive and connecting via soft link?


I haven't tried it myself in a while, but as far as I know having it on 
another volume should work fine. You don't need the link, since this 
location is configurable as 'portdbpath' in macports.conf. The negative 
effects are really just the usual effects of using an external drive. 
Builds and registry operations will be limited by the drive's speed, and 
there will be an additional performance penalty when activating ports 
because the files are extracted in the software directory and then moved 
into place, and that move will be across volumes with this configuration.


- Josh

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] 

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: Borg backup is complaining about msgpack python package version

[Joshua Root]

On 6/1/2024 00:07, Clemens Lang wrote:

Actually, the relevant commit is
https://github.com/borgbackup/borg/commit/39761ebadc9325a7cc7e931144e2709effe8f0f0,
and that has been backported to the 1.2 branch of borgbackup and is in
1.2.7, so just make sure you have the latest borgbackup installed and it
should start working again.


Yes, updating to 1.2.7 was the resolution to the ticket that was opened 
about this. 


- Josh

Re: Borg backup is complaining about msgpack python package version

[Joshua Root]

On 5/1/2024 23:45, Clemens Lang wrote:

For reasons I don't understand, borgbackup wants to allow-list every new
version of the msgpack library manually, so every update of the msgpack
library breaks borgbackup.


It's likely because many python module projects have a culture of very 
poor backward compatibility practices. Interfaces change in incompatible 
ways all the time, often without the compatibility break being 
documented. I would assume a past minor version increase of msgpack 
broke borgbackup, which created a support burden for them, so now they 
pin the version.


This is bad for basically everyone, because client projects stick with 
old versions with old bugs out of caution even when newer ones would 
work fine (as in this case), it creates extra work when they do update, 
and it's really easy to get into situations with diamond dependencies 
where conflicting versions of the same module are required. This one 
issue is largely responsible for the need to have a separate venv for 
every project, each with identical or only slightly different copies of 
many of the dependencies.


And unfortunately, this is a social issue with no easy fix. :(

- 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: How to download builds from macports?

[Joshua Root]

Be aware that not all ports are available as binary archives, and some 
ports rely on post-activate code in the Portfile being run in order to 
work properly.


- Josh

PavelTurk wrote:


Hi Dave,

Thank you very much for your answer.

Best regards, Pavel

On 12/26/23 5:19 PM, Dave Allured - NOAA Affiliate wrote:
>/Use one of the several mirror sites for pre-built binary 
distributions.  Look under section "Archives" here: />/https://trac.macports.org/wiki/Mirrors 
 />//>/Because each home page is huge, I find it convenient to postfix the 
package name for use in a browser, e.g.: />/http://atl.us.packages.macports.org/ffmpeg/ 
 />//>//>/On Tue, Dec 26, 2023 at 3:47 AM PavelTurk  
>> wrote: />//>/Hi all, />//>/We have a Java project that must work on linux, windows, mac. To make project cross-platform 
/>/we provide jars with shared libraries - so, dll. These libraries are dowloaded with .sh script while 
/>/jar is built. We have libraries for linux and windows, but mac library is on macports. 
/>//>/Could anyone say how to donwload build/package, for example, for project `ffmpeg` using curl or wget? 
/>/Or what is the link to to it - http/https?/

Re: Idiomatic process for handling needed external language modules for which there is no port

[Joshua Root]

How do you do package management on MacPorts for languages which might
need modules which MacPorts doesn't have?

   This problem exists for many languages supported by MacPorts; ie:
Perl, Python, Raku, Julia, etc


The answer is different for each language. For Python, standard 
procedure is to use venv. 


I would assume for perl that if there isn't an equivalent mechanism, 
cpan should at least have an option to choose a different installation 
prefix. I don't know what the situation is for Raku and Julia.


- 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: Portfile magic / xinstall usage / defect?

[Joshua Root]

The brotli 
Portfile:https://github.com/macports/macports-ports/blob/master/archivers/brotli/Portfile
Contains:
   post-destroot {
  xinstall -m 640 {*}[glob ${worksrcpath}/docs/*.1] 
${destroot}${prefix}/share/man/man1/
…
   }

However, after port installation, I look in the work directory and see:
   ls -la destroot/opt/local/share/man/man1
  -r--r--r--  root  admin  …  brotli.1.gz

Also, /opt/local/share/man/man1/brotli.1.gz contains the same perms and .ext 
(as the above work/destroot).

* How is the permissions mode 444, instead of 640 (as designated in the 
post-destroot block)?
* And how did it get the .gz extension?


If you look in the log file for the brotli build after running e.g. 
'sudo port destroot brotli', you'll see a line saying "Compressing man 
pages for brotli". That comes from this code (which runs after all 
Portfile-defined destroot code): 



- 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: FYI: The meld port depends on the p5.36-xml-parser port, which does not exist

[Joshua Root]

FYI: The meld port depends on the p5.36-xml-parser port, which does not exist

sudo port -v -s install meld
--->  Computing dependencies for meld
Error: Dependency 'p5.36-xml-parser' not found.
Error: Followhttps://guide.macports.org/#project.tickets  if you
believe there is a bug.
Error: Processing of port meld failed


Meld itself does not have this dependency:

% port deps meld
Full Name: meld @3.21.0_2+x11
Extract Dependencies: xz
Build Dependencies:   intltool, itstool, libxml2, py311-distro, makeicns,
  librsvg
Library Dependencies: desktop-file-utils, glib2, gtk3, gtksourceview4,
  py311-cairo, py311-gobject3, shared-mime-info, 
python311

Runtime Dependencies: adwaita-icon-theme, gsettings-desktop-schemas, yelp

So it must be one of its dependencies. But on my machine there is no 
such dependency:


% port rdeps meld | grep -F p5.36-xml-parser
%

So it must be something that is changing dynamically, perhaps based on 
variants.


% port echo depends:xml-parser and rdepof:meld
intltool
pulseaudio

Looking at the portfiles for these two, intltool sets a fixed 
perl5.major, but pulseaudio does not. The perl5 portgroup has something 
of a misfeature where it sets the default perl to use based on the 
currently active variant of the perl5 port. So I guess you have 
perl5+perl5_36 installed.


Please file a ticket. The pulseaudio port may not even need the 
p5-xml-parser dependency (many ports that use intltool once added this 
as a poor workaround for an old bug). But if it does, or if it records 
the path to perl at build time and then uses it at runtime, it needs to 
set a fixed perl5.major.


- Josh

Re: Is there anyone who has successfully migrated Macport to Sonoma?

[Joshua Root]

On 9/10/2023 10:34, Tao Zhang wrote:

Hi Josh,

  Thanks for your helpful comments. One more question:

    gfortran and ifort  do not work after upgrading to Sonoma. see below.
  1) Should I upgrade to the latest Xcode15 or old Xcode14 to fix this 
problem?

  2)  It is reported that Xcode15 does not work well with Macport, right?


Yes, there are unfortunately some build issues that affect Xcode 15 but 
not 14. However, as far as I'm aware, Xcode 14 doesn't work on Sonoma. 
So if you need to keep using Xcode 14, you probably also need to stay on 
Ventura.


- Josh

Re: Is there anyone who has successfully migrated Macport to Sonoma?

[Joshua Root]

1)  For 1. below , should I use Xcode15 or older version?


Xcode 15 or later is required on Sonoma.


    2) Does the following procedure work? Is there anyone who has
successfully migrated Macport to Sonoma?
I haven't heard of any problems with the procedure that are specific to 
Sonoma. Individual ports may fail to build, as is always the case with 
new macOS versions. See .



   3) How long will this migration procedure take?
That depends on which ports you have installed and how fast your 
hardware is. Since there are no binaries built yet, the majority of the 
time will be spent compiling. There is information on ports.macports.org 
about how long ports took to build on our buildbot, which should give 
you a starting point; e.g. 
.



   4) I have upgraded to Sonoma OS. But why my present ports still work?


macOS is in general very backwards compatible, so existing binaries will 
usually keep working on newer OS versions (though there are exceptions). 
Unless you've hit one of the exceptions, the Migration procedure is only 
needed to avoid problems when you upgrade your ports or install new 
ones. As long as you never install or upgrade anything, you can keep 
using your ports as is (though that's not recommended long term of course.)


- Josh

Re: Timing of MacPorts Support for New macOS Versions

[Joshua Root]

I’m curious if you’ve revisited the NDA recently, since a skim of the verbiage 
makes it seem to me that discussing the new OSes should be OK, assuming we 
don’t review it or post screenshots. 
Fromhttps://developer.apple.com/support/terms/apple-developer-program-license-agreement/#ADPLA9.1:

> Further, Apple agrees that You will not be bound by the foregoing 
confidentiality terms with regard to technical information about pre-release Apple 
Software and services disclosed by Apple at WWDC (Apple’s Worldwide Developers 
Conference), except that You may not post screenshots of, write public reviews of, 
or redistribute any pre-release Apple Software, Apple Services or hardware.

IANAL and all, but this clause is fairly new and if you haven’t re-evaluated 
that policy for a while it might be worth doing so again.



That seems like a badly-written clause to me because there are at least 
two ways you can parse it, and it greatly changes the meaning. But in 
any case, I think it's important to point out that we are not attempting 
to give anyone advice about which actions do or don't violate their NDA. 
If you have an agreement with Apple, it's your responsibility to ensure 
that you are keeping your side of it.


The statements in the documentation and links to them in ticket comments 
are meant to be (a) a courtesy reminder that pre-release OS versions 
tend to be under NDA, since users sometimes forget this; and (b) a way 
to find out about project members that are permitted to see any 
information that is not allowed to be posted publicly. But again, it's 
up to the person who signed the NDA to determine which information that is.


If the docs are not making this sufficiently clear, please feel free to 
propose improvements or make PRs.


- Josh

Re: selfupdate fails

[Joshua Root]

% sudo port -v selfupdate
--->  Updating MacPorts base sources using rsync
rsync: failed to connect to rsync.macports.org: Operation timed out (60)


Please see .

- Josh

Re: best Xcode version for Mojave?

[Joshua Root]

After updating Xcode while keeping the same OS, should one delete and reinstall 
all MacPorts packages?

No, there's no reason to do that if you have only changed the Xcode version.

- Josh

Re: Exa port dependencies

[Joshua Root]

Ideally, docs that need significant extra deps could be a separate 
(sub)port.


- Josh

On 10/6/2023 05:14, Chris Jones wrote:

Hi,

I agree they should be the default, ‘by default’, but there are some ports 
which have a docs variant that drags in minimum build deps and thus having 
enable by default is probably fine. Anything though that drags in pandoc and 
the vast array of deps it needs should probably be optional…

Chris


On 9 Jun 2023, at 3:16 pm, Ken Cunningham  
wrote:

I have long thought the doc variants should never be the default.

Lots of bloat and extra deps and build errors.

But I know others feel differently.

I know I can set -doc in variants.conf, but then you’re building everything.


K


On Jun 9, 2023, at 04:01, Joshua Root  wrote:




The list below is the current list of build dependencies when I do a
port install of "exa +doc+git". The list seems pretty ridiculous though.
I just cloned the exa repository and did a cargo build outside macports.
None of these dependencies are required.

The vast majority of those are dependencies of pandoc, which is used by the exa 
port's doc variant. They won't be installed when installing exa from a binary 
archive. If you need to build locally and don't want all these deps, you can 
use -doc.

- Josh

Re: Exa port dependencies

[Joshua Root]

The list below is the current list of build dependencies when I do a
port install of "exa +doc+git". The list seems pretty ridiculous though.
I just cloned the exa repository and did a cargo build outside macports.
None of these dependencies are required.
The vast majority of those are dependencies of pandoc, which is used by 
the exa port's doc variant. They won't be installed when installing exa 
from a binary archive. If you need to build locally and don't want all 
these deps, you can use -doc.


- Josh

Re: gcc12 fault?

[Joshua Root]

On 2/6/2023 16:47, Ken Cunningham wrote:


You have probably already noted that which and type are both built in to the 
default zsh on Ventura and as far as I can tell from my testing here give 
identical results in every case. Both correctly predict the binary that will be 
executed in every case I tried.


Indeed, zsh is a bit special and implements both 'which' and 'type' in 
terms of its 'whence' builtin (which has a lot of options and can tell 
you pretty much anything you would ever want to know about a command's 
disposition, check it out.) You will notice /usr/bin/which can thus give 
different results to just 'which'.



What will happen when you add and remove binaries from an upstream PATH folder 
is a bit difficult to predict accurately. I won't try to summarize the findings 
only to have someone point out their idea of an exception, but it's fair to say 
that it's best to open a new shell to get predictable results.


You would want to start a new shell if you changed the startup files. 
Otherwise 'hash -r' is quite sufficient. Changing the value of PATH at 
runtime will do that automatically in modern shells, BTW.


- Josh

Re: gcc12 fault?

[Joshua Root]

Ken Cunningham wrote:


what you see is difficult to explain, unless the PATH changed between the two 
tests.

if

'which gcc' gives /opt/local/bin/gcc

then

gcc --version

should give exactly the same as

/opt/local/bin/gcc --version


Not necessarily. Shells cache command locations, so if 'gcc' was run 
prior to the creation of /opt/local/bin/gcc, subsequently invocations 
will continue to run the previously found gcc. Running 'hash -r' or 
starting a new shell will give you an empty cache and thus set things right.


The 'which' command doesn't know about the shell's cache state; it only 
looks at the current PATH. This is why 'type' often helps to understand 
what's going on in these situations, as Richard hinted.


- Josh

Re: Cannot build glib2

[Joshua Root]

Hi Ken,

Your can see the architecture(s) each port is built for with 'port -v 
installed'. The ones of concern on an Apple Silicon system will have 
archs='x86_64'.


- Josh

On 29/5/2023 09:55, Kenneth Wolcott wrote:

HI Josh;

   Is it possible to find out what ports that I have installed that
would fail to upgrade due to not supporting the M1 chip?  If, so what
command would I issue so that I could determine the risk involved of
doing that massive upgrade operation?

Thanks,
Ken Wolcott

On Sun, May 28, 2023 at 4:30 PM Joshua Root  wrote:


On Mon, 24 Apr 2023, Dave Horsfall wrote:


[ Disabling "+universal" ]

Yes, that seems to be it; thanks.  Now, is there a way to globally
disable "universal" without cleaning every port and rebuilding with
"-universal"?


You don't have to rebuild everything, but there's no getting around 
reinstalling all the ports that currently have +universal, if you want them to 
not be universal. They may or may not have to be built depending on binary 
availability. The command to do that would be:

sudo port upgrade --enforce-variants installed -universal

If you want to disable universal altogether in your MacPorts installation, set 
universal_archs to an empty value in macports.conf. Note that this will make it 
impossible to install some ports that don't support your configured build_arch.

- Josh

Re: Cannot build glib2

[Joshua Root]

On Mon, 24 Apr 2023, Dave Horsfall wrote:


[ Disabling "+universal" ]

Yes, that seems to be it; thanks.  Now, is there a way to globally 
disable "universal" without cleaning every port and rebuilding with 
"-universal"?


You don't have to rebuild everything, but there's no getting around 
reinstalling all the ports that currently have +universal, if you want them to 
not be universal. They may or may not have to be built depending on binary 
availability. The command to do that would be:

sudo port upgrade --enforce-variants installed -universal

If you want to disable universal altogether in your MacPorts installation, set 
universal_archs to an empty value in macports.conf. Note that this will make it 
impossible to install some ports that don't support your configured build_arch.

- Josh

Re: gtk3 on Snow Leopard build failed

[Joshua Root]

...and things had gone so nicely on Snow Leopard for awhile now, until this:

:notice:build --->  Building gtk3
:debug:build Executing org.macports.build (gtk3)
:info:build --->  Building gtk3 for architecture x86_64
:debug:build setting option build.dir to 
/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_gnome_gtk3/gtk3/work/build-x86_64
:debug:build Environment:
:debug:build CC_PRINT_OPTIONS='YES'
:debug:build 
CC_PRINT_OPTIONS_FILE='/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_gnome_gtk3/gtk3/work/.CC_PRINT_OPTIONS'
:debug:build CPATH='/opt/local/include'
:debug:build CPLUS_INCLUDE_PATH='/opt/local/include/LegacySupport'
:debug:build C_INCLUDE_PATH='/opt/local/include/LegacySupport'
:debug:build DEVELOPER_DIR='/Developer'
:debug:build LIBRARY_PATH='/opt/local/lib'
:debug:build MACOSX_DEPLOYMENT_TARGET='10.6'
:debug:build 
MACPORTS_LEGACY_SUPPORT_CPPFLAGS='-isystem/opt/local/include/LegacySupport'
:debug:build MACPORTS_LEGACY_SUPPORT_ENABLED='1'
:debug:build MACPORTS_LEGACY_SUPPORT_LDFLAGS='-L/opt/local/lib 
-lMacportsLegacySupport'
:debug:build OBJCPLUS_INCLUDE_PATH='/opt/local/include/LegacySupport'
:debug:build OBJC_INCLUDE_PATH='/opt/local/include/LegacySupport'
:info:build Executing:  cd 
"/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_gnome_gtk3/gtk3/work/build-x86_64"
 && /opt/local/bin/ninja -j4 CC='/opt/local/bin/clang-mp-8.0 -arch x86_64' 
CC_FOR_BUILD='/opt/local/bin/clang-mp-8.0 -arch x86_64' -v
:debug:build system:  cd 
"/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_gnome_gtk3/gtk3/work/build-x86_64"
 && /opt/local/bin/ninja -j4 CC='/opt/local/bin/clang-mp-8.0 -arch x86_64' 
CC_FOR_BUILD='/opt/local/bin/clang-mp-8.0 -arch x86_64' -v
:info:build ninja: error: unknown target 'CC=/opt/local/bin/clang-mp-8.0 -arch 
x86_64'
:info:build Command failed:  cd 
"/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_gnome_gtk3/gtk3/work/build-x86_64"
 && /opt/local/bin/ninja -j4 CC='/opt/local/bin/clang-mp-8.0 -arch x86_64' 
CC_FOR_BUILD='/opt/local/bin/clang-mp-8.0 -arch x86_64' -v
:info:build Exit code: 1
:error:build Failed to build gtk3: command execution failed
:debug:build Error code: NONE
:debug:build Backtrace: command execution failed
:debug:build while executing
:debug:build "$procedure $targetname"
:error:build See 
/opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_gnome_gtk3/gtk3/main.log
 for details.



Lest anyone wonder, /opt/local/bin/clang-mp-8.0 does exist.


I note this is a universal build. The CC and CC_FOR_BUILD settings are 
part of a workaround intended to get g-ir-scanner to use the right 
compiler. They were removed from the non-universal case recently, I 
would assume because passing them in as build args like that doesn't 
work with meson, as seen above (and I wonder if g-ir-scanner is now 
using the wrong compiler again as a result). But they were left in the 
universal case. This is something the port maintainer needs to sort out.




- Josh

Re: Install on Ventura 14.2

[Joshua Root]

On 3/2/2023 14:22, Ryan Schmidt wrote:

Generating the portindex from scratch takes hours, but just updating a slightly 
out-of-date portindex with the latest changes shouldn't take that long. Also, 
the slightly outdated portindex on the public rsync servers should correspond 
exactly to their slightly outdated collection of ports so no updating should be 
needed.


I was avoiding going into too much detail before, but depending on the 
exact timing of the power going out and the mirror syncing from the 
origin, it's possible that the indices for some subset of OS versions 
could be one update behind the ports tree. But I haven't checked whether 
that's actually the case.


- Josh

Re: Install on Ventura 14.2

[Joshua Root]

Putting together a new machine (M2Pro Mini, Ventura 14.2) and have hit a snag 
installing MacPorts.  I’ve not installed Xcode on any of my systems for a 
number of years now, I simply install the appropriate CLI package from the 
Apple site.  In this case, I downloaded and installed v14.2.  I then downloaded 
the MacPorts install package for Ventura and started it up.  Twenty minutes 
later I’m still waiting for “Running Package Scripts …” to finish up.

Not being a MacPorts guru of any sort, I’m not sure what I should look at to 
see what’s up.  One thing I did find is that a file named .base.tar.ZqfTHz is 
slowly growing larger.  This file is in:
/opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs

I’m just letting it run for now, but I don’t ever recall this happening in 
other new installs.  Any ideas?
The installer's postflight script runs 'port selfupdate' in order to 
download the ports tree. It's a reasonably big file at just over 100 MB, 
so it could take a while depending on network performance between you 
and our server. It's also possible that you had to regenerate part of 
the PortIndex because the machine that updates it is currently without 
power, and that can also be a lengthy operation.


- Josh

MacPorts 2.8.1 has been released

[Joshua Root]

The MacPorts Project is pleased to announce the release of version
2.8.1. This is a bugfix release with small changes only. See the
ChangeLog [1] for the list of changes.

If you already have MacPorts installed, the preferred method for
updating is to run:

   sudo port selfupdate

For new installs, there are also package installers available for macOS
versions ranging from macOS 13 Ventura all the way back to 10.4 at [2]. 
The source is also available as tarballs compressed with gzip or bzip2, 
or from the git tag [3].


Detached PGP signatures for the disk images, packages and source
tarballs have been made with my key, which is available on the
keyservers and my MacPorts wiki page [4], the fingerprint being:

0x01FF673FB4AAE6CD: C403 7936 5723 6DCF 2E58  0C02 01FF 673F B4AA E6CD

Josh
(on behalf of the MacPorts Port Managers)

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




OpenPGP_signature
Description: OpenPGP digital signature

Re: Issue with installing port

[Joshua Root]

I'm trying to get pandoc to install.

The ticket for this is , FWIW.

- Josh

Re: PortIndex file corrupt?

[Joshua Root]

That's the thing - the bug only affects reclaim when it runs 
automatically as part of the same command as sync or selfupdate. Your 
PortIndex was never actually corrupt on disk, it just isn't reloaded 
correctly in that specific situation.


- Josh

On 2023-1-23 09:22 , Thomas Gederberg wrote:

Thanks.  Actually I got the message a few weeks ago after doing a port 
selfupdate and it repeated again today after doing another port selfupdate so 
it appears that the second port selfupdate did not clear it.  However, I just 
tried doing a sudo port reclaim and did not get any errors.

Tom


On Jan 22, 2023, at 1:12 PM, Joshua Root  wrote:

See 
<https://lists.macports.org/pipermail/macports-users/2022-October/051512.html>.

- Josh


Today, while doing a port update, I did a port reclaim and received the 
followed errors (just a subset of the errors are listed).  What could cause 
this and how could I fix it?

You haven't run 'sudo port reclaim' in two weeks. It's recommended you run this 
regularly to reclaim disk space. Would you like to run it now? [Y/n]: Y
--->  Checking for unnecessary unrequested ports
Found no unrequested ports without requested dependents.
--->  Checking for inactive ports
Inactive ports found:
  sqlite3  @3.40.0_0
  ncurses  @6.3_0
Would you like to uninstall them? [Y/n]: Y
--->  Uninstalling sqlite3 @3.40.0_0
--->  Uninstalling ncurses @6.3_0
--->  Building list of distfiles still in use
Warning: It looks like your PortIndex file 
forrsync://rsync.macports.org/macports/release/tarballs/ports.tar  may be 
corrupt.
Warning: Port cctools not found: expected non-negative integer but got "create and 
view interactive cheatsheets on the command-line"
 while executing
"read $fd $len"
 ("macports_try" body line 6)
Warning: It looks like your PortIndex file 
forrsync://rsync.macports.org/macports/release/tarballs/ports.tar  may be 
corrupt.
Warning: Port bzip2 not found: expected non-negative integer but got "homepage"
 while executing
"read $fd $len"
 ("macports_try" body line 6)
Warning: It looks like your PortIndex file 
forrsync://rsync.macports.org/macports/release/tarballs/ports.tar  may be 
corrupt.
Warning: Port libiconv not found: expected non-negative integer but got ""

Re: PortIndex file corrupt?

[Joshua Root]

See 
.


- Josh


Today, while doing a port update, I did a port reclaim and received the 
followed errors (just a subset of the errors are listed).  What could cause 
this and how could I fix it?

You haven't run 'sudo port reclaim' in two weeks. It's recommended you run this 
regularly to reclaim disk space. Would you like to run it now? [Y/n]: Y
--->  Checking for unnecessary unrequested ports
Found no unrequested ports without requested dependents.
--->  Checking for inactive ports
Inactive ports found:
  sqlite3  @3.40.0_0
  ncurses  @6.3_0
Would you like to uninstall them? [Y/n]: Y
--->  Uninstalling sqlite3 @3.40.0_0
--->  Uninstalling ncurses @6.3_0
--->  Building list of distfiles still in use
Warning: It looks like your PortIndex file 
forrsync://rsync.macports.org/macports/release/tarballs/ports.tar  may be 
corrupt.
Warning: Port cctools not found: expected non-negative integer but got "create and 
view interactive cheatsheets on the command-line"
 while executing
"read $fd $len"
 ("macports_try" body line 6)
Warning: It looks like your PortIndex file 
forrsync://rsync.macports.org/macports/release/tarballs/ports.tar  may be 
corrupt.
Warning: Port bzip2 not found: expected non-negative integer but got "homepage"
 while executing
"read $fd $len"
 ("macports_try" body line 6)
Warning: It looks like your PortIndex file 
forrsync://rsync.macports.org/macports/release/tarballs/ports.tar  may be 
corrupt.
Warning: Port libiconv not found: expected non-negative integer but got ""

Re: Error: Failed to fetch rust: The requested URL returned error: 404

[Joshua Root]

Mirroring is done for each variant and each platform, but not every 
combination of variants or of variants and platforms, due to the 
combinatorial explosion that would entail. Only the files needed by 
+universal on the machine doing the mirroring are mirrored.


- Josh

On 2022-12-31 02:47 , mcalh...@macports.org wrote:

Thank you for the explanation.
Perhaps this is a question better suited to the development mailing list, but 
why doesn’t the `universal` variant (which exists) achieve the same goal as the 
`mirror_i386` variant?

-Marcus


On Dec 29, 2022, at 7:43 PM, Joshua Root  wrote:

On 2022-12-30 04:58 , mcalh...@macports.org wrote:

Please forgive my ignorance, but I am not sure how `variant mirror_i386` works.
It exists but is *not* default, so how would it be set by the mirroring 
mechanish?
If it is not set, how will `if {[variant_exists mirror_i386] && [variant_isset 
mirror_i386]} {` ever run?


It's a hack for sure. The mirroring script mirrors ports with each of their 
variants set, so that files only used by certain variants will be mirrored. In 
this case, the files are (on i386) also used for reasons other than the variant 
being set, so end users don't have to actually use the variant to benefit from 
its files being mirrored.

- Josh

Re: Error: Failed to fetch rust: The requested URL returned error: 404

[Joshua Root]

On 2022-12-30 04:58 , mcalh...@macports.org wrote:

Please forgive my ignorance, but I am not sure how `variant mirror_i386` works.
It exists but is *not* default, so how would it be set by the mirroring 
mechanish?
If it is not set, how will `if {[variant_exists mirror_i386] && [variant_isset 
mirror_i386]} {` ever run?


It's a hack for sure. The mirroring script mirrors ports with each of 
their variants set, so that files only used by certain variants will be 
mirrored. In this case, the files are (on i386) also used for reasons 
other than the variant being set, so end users don't have to actually 
use the variant to benefit from its files being mirrored.


- Josh

Re: Error: Failed to fetch rust: The requested URL returned error: 404

[Joshua Root]

Marcus Calhoun-Lopez wrote:


For reasons that are not entirely clear, the Rust distfiles are not being 
mirrored.
See https://trac.macports.org/ticket/60511

As a workaround, you can download them yourself from 
https://github.com/MarcusCalhoun-Lopez/rust/releases/tag/1.66.0 and put them in 
/opt/local/var/macports/distfiles/rust.

-Marcus

> On Dec 27, 2022, at 10:33 PM, chilli.namesake at gmail.com wrote:
> 
> rust 404 is holding up my upgrades of 
> gd22.3.3_1 < 2.3.3_2 
> ImageMagick6.9.11-60_3 < 6.9.11-60_4   
> rav1e  0.5.1_1 < 0.5.1_2
>  
> but only on Mountain Lion. On Mojave these upgraded yesterday, and I ran the upgrades simultaneously. Why would rust be available for Mojave but 404 on Mountain Lion?


This is now fixed. BTW, the correct ticket number is 
.


- Josh

Re: list of packages that are always compiled

[Joshua Root]

Richard L. Hamilton wrote:


A plausible test case with the first of those (ffmpeg +nonfree) gave the 
expected result: return code 1, i.e. non-redistributable; and without the 
+nonfree variant, also gave the expected result of return code 0 
(redistributable). That nicely shows that the results reflect the effects of 
dependency differences based on variant.
I should also point out for those who are unfamilar with it that 
port_binary_distributable.tcl has a -v option that will show the reason 
for non-distributability (technically only the first reason it finds; 
there can be multiple reasons):


./port_binary_distributable.tcl -v ffmpeg +gpl3
"ffmpeg" is not distributable because its license "GPL-3+" conflicts 
with license "GPL-2" of dependency "libvidstab"



Does the behavior of those take into account configuration like a modified 
variants.conf (so the result aligns with what variants would be used if one did 
a port install)?
The two gists make no attempt to set any variants on the ports, so they 
will give results that apply only for the default variants. As you 
discovered, port_binary_distributable.tcl does apply variants given on 
the command line, but it doesn't have code to merge in the 
global_variations (as the variants requested via variants.conf are 
called). It would be possible to add this for all of the scripts with a 
little work.



although both of the scripts that obtain the information for all ports are 
quite slow;
Yes, which is why storing the decision made by the buildbot is 
preferable to generating the information on demand. The 
all_distributable.tcl 
 
script is doing more work than it would take to regenerate the PortIndex 
from scratch, and the latter takes well over 20 minutes on my machine. 
On the other hand, all_bin_available.tcl 
 is 
limited mainly by how fast the packages server responds, so changing it 
to use a mirror that is closer to you could help. A faster multithreaded 
implementation is left as an exercise for the reader. :-)


- Josh

Re: list of packages that are always compiled

[Joshua Root]

Werner LEMBERG wrote:


Folks,


is there an option to `port` that shows me the names of all packages
that must be built from source, and which are not available
pre-compiled from 'packages.macports.org'?  Or maybe this list is
somewhere else, ideally also giving a reason?  [My use-case is
'ghostscript', for which I can't see why it is not provided
pre-compiled.]

Right now, I check 'packages.macports.org' directly whether there is a
directory, but this is inefficient IMHO – and it doesn't give the
reason :-)


There is no option to port(1) that will show this. The buildbot logs 
(which are linked from ports.macports.org) do contain this information; 
for example,  links to 
 
which in the stdio for the "gather archives" step says: "libewf" is not 
distributable because its dependency "macfuse" has license "restrictive" 
which is not known to be distributable.


Of course that's a bit more digging than would be ideal, and the logs do 
eventually get deleted, so getting the web app to remember and display 
this information right on the port details page would be a good improvement.


Also, whether a binary archive is currently available for a port and 
whether one would be made available if the port were built are two 
different questions. Answering the former requires a http request to 
packages.macports.org. To answer the latter, you can use the same script 
that the buildbot uses: 



Generating this information for all ports is not too difficult with a 
little scripting, but does take quite some time.


List which ports do and don't have an archive available (for your 
current OS version and arch): 



List which ports are and aren't considered distributable: 



- Josh

Re: Finding dependents

[Joshua Root]

Postfix *with no variants* has no dependencies. That's what you will be 
shown if you run simply 'port deps postfix', because of course you have 
not specified any variants (and no variants are on by default).


I think what's wanted here is:

port deps postfix and installed

Or if you're more interested in what is installed that depends on pcre:

port dependents pcre

- Josh

chilli.namesake wrote:


postfix has no dependencies btw

>/On Dec 23, 2022, at 08:36, chilli.namesake at gmail.com 
 wrote: />//>/ />/port rdeps postfix />//>/shows it's dependencies. Probably want to pipe into more. />//>/But to see what depends on postfix, it's a little different. />//>/port echo depends:postfix />//>>>/On Dec 23, 2022, at 07:49, Gerben Wierda via macports-users 
> wrote: />>>//>>/Ik keep struggling when I try to find out dependencies once in a while. />>//>>/Suppose I have this installed: />>//>>/postfix @3.7.2_0+dovecot_sasl+pcre+smtputf8+tls (active) />>//>>/How do I find out the port dependencies with the port command such 
that port tells me my postfix depends on port:pcre?/

Re: How to clean up failed build with lots of dependencies?

[Joshua Root]

dbus[2197]: Dynamic session lookup supported but failed: launchd did not 
provide a socket path, verify that org.freedesktop.dbus-session.plist is loaded!
That is provided by dbus, which should be somewhere in the recursive 
dependencies of gtk3 I think?


- Josh

Re: How to clean up failed build with lots of dependencies?

[Joshua Root]

Does MacPorts have a way to uninstall the dependencies it installed in 
attempting to build NetSurf (or any complex port that fails to build) without 
uninstalling the dependencies that were already installed?

Will "port reclaim" catch these?


Yes, port reclaim will clean up such ports for you. You can also use an 
expression like 'leaves and rdepof:NetSurf' to do it manually; I would 
pass it to 'port echo' first to check that it doesn't match anything you 
want to keep, and then use it with clean and uninstall.


- Josh

Re: Unable to install xz

[Joshua Root]

On 2022-12-10 15:03 , Kenneth Wolcott wrote:

Is the correct takeaway from this is not to use the trace flag with
the port commands for now on MacOS Ventura?


Until there's a fix for this issue, yes.

- Josh

Re: Unable to install xz

[Joshua Root]

Sounds like the failed attempt in trace mode left the work dir in a bad 
state which was cleared up by cleaning it. There's a reason our 
troubleshooting advice usually starts with 'port clean ...'. :)


I guess now that it has succeeded and the logs are cleaned away, the 
record of exactly how it failed in between is gone.


- Josh

On 2022-12-10 13:42 , Kenneth Wolcott wrote:

Hi Joshua;

   Well, I slightly mis-spoke.  Using verbose without trace, xz install
still fails but does not have an explicit error code.

   Wow, I deleted the contents of the xz work directory and tried to
install again, now it works with verbose mode enabled but disabled
trace mode.

   I'm quite confused.

Thanks,
Ken Wolcott

On Fri, Dec 9, 2022 at 6:24 PM Joshua Root  wrote:


If it fails in exactly the same way without trace mode, i.e. during the
extract phase with the message "Killed by signal: 9", please add your
terminal transcript and corresponding log to
<https://trac.macports.org/ticket/66358>.

- Josh

On 2022-12-10 05:40 , Kenneth Wolcott wrote:

HI Josua;

It fails without "-t" as well.

Thanks,
Ken

On Fri, Dec 9, 2022 at 3:59 AM Joshua Root  wrote:


Kenneth Wolcott wrote:


Killed by signal: 9
Error: Failed to extract xz: command execution failed

Happens with many of the ports.

What is wrong with my system?


This seems to only happen on Ventura and only when using trace mode.
There's a ticket open in Trac, but I don't think anyone has been able to
analyse what's happening yet.

The workaround in the meantime is of course to not use trace mode.

- Josh

Re: Unable to install xz

[Joshua Root]

If it fails in exactly the same way without trace mode, i.e. during the 
extract phase with the message "Killed by signal: 9", please add your 
terminal transcript and corresponding log to 
<https://trac.macports.org/ticket/66358>.


- Josh

On 2022-12-10 05:40 , Kenneth Wolcott wrote:

HI Josua;

   It fails without "-t" as well.

Thanks,
Ken

On Fri, Dec 9, 2022 at 3:59 AM Joshua Root  wrote:


Kenneth Wolcott wrote:


Killed by signal: 9
Error: Failed to extract xz: command execution failed

Happens with many of the ports.

What is wrong with my system?


This seems to only happen on Ventura and only when using trace mode.
There's a ticket open in Trac, but I don't think anyone has been able to
analyse what's happening yet.

The workaround in the meantime is of course to not use trace mode.

- Josh

Re: Unable to install xz

[Joshua Root]

Kenneth Wolcott wrote:


Killed by signal: 9
Error: Failed to extract xz: command execution failed

Happens with many of the ports.

What is wrong with my system?


This seems to only happen on Ventura and only when using trace mode. 
There's a ticket open in Trac, but I don't think anyone has been able to 
analyse what's happening yet.


The workaround in the meantime is of course to not use trace mode.

- Josh

Re: Recommendation for installing Python modules: pip or Macports

[Joshua Root]

Tom Gederberg wrote:

It appears that you can either install Python modules (py310-matplotlib, 
py310-numpy, etc) either directly from MacPorts or you can install pip (for 
example py30-pip) with MacPorts and then use pip to install the modules.

Is there a recommendation on which way to go?


There are a couple of important points here.

1. Don't use pip (or anything else) to install python modules into the same 
prefix that MacPorts uses. MacPorts won't know about them and you will get file 
conflicts. You can use the --user option to install into your home directory, 
or as has already been mentioned, the more scalable approach is to use 
virtualenv/venv and install whatever you want inside the isolated container.

2. MacPorts doesn't have all the modules on PyPI by a long shot. The modules 
that are provided as ports are usually there because either they depend on some 
non-python-module thing that is in MacPorts (and usually pip won't be able to 
install such dependencies), or something else in MacPorts depends on them.

So it depends what you're doing. You can combine the two to some extent by 
using e.g. virtualenv's --system-site-packages option.

- Josh

MacPorts 2.8.0 has been released

[Joshua Root]

The MacPorts Project is happy to announce that the 2.8.0 version has now
been released. It is available via the usual methods:

  - selfupdate if you already have MacPorts installed
  - package installers [1] for macOS 12 Monterey and all older releases
back to Mac OS X 10.4 Tiger  (universal arm64/x86_64 for macOS 11+,
i386/x86_64 for 10.6, i386/ppc for 10.4 and 10.5, and the rest
x86_64)
  - source tarballs, both .tar.bz2 [2] and .tar.gz [3]
  - git tag [4]

The list of what's new in 2.8.0 can be found in the ChangeLog [5].

A big thanks to the developers for their hard work with all of the
various features and bug fixes in 2.8.0, and to all those who helped out
by reporting bugs or testing.

Detached PGP signatures for the pkg/dmgs and source tarballs have been
made with my key, which is available on the keyservers and my MacPorts
wiki page [6].

- Josh

[1] 
[2] 

[3] 


[4] 
[5] 
[6] 

PS, my PGP key ID is 0x01FF673FB4AAE6CD,
fingerprint C403 7936 5723 6DCF 2E58  0C02 01FF 673F B4AA E6CD



OpenPGP_signature
Description: OpenPGP digital signature

Re: ports.tar corrupt?

[Joshua Root]

Dave Horsfall wrote:


I don't know what it is with MacPorts and me, but here's the latest
problem; when doing my weekly "port upgrade outdated" I get:

 Warning: Port cairo not found:
 Warning: It looks like your PortIndex file 
forrsync://rsync.macports.org/macports/release/tarballs/ports.tar  may be 
corrupt.

Etc.

How do I fix that?


If the PortIndex is truly corrupt, a selfupdate or sync should set it 
right. But I think this might be a previously discussed issue where a 
scheduled reclaim run can happen when exiting after syncing the ports 
tree, without reloading the index. I'm not sure if a ticket was ever 
filed. If that's the case, you don't need to do anything, everything 
will be fine the next time you run port (because it loads the index anew 
when it starts).


- Josh

MacPorts 2.8.0-rc1 now available for testing

[Joshua Root]

Source code and pkgs for MacPorts 2.8.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.8.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:
   * Fixed error when upgrading ports with no cxx_stdlib information in 
the registry.

   * Ensured that SQLite write-ahead logging is enabled on all systems.

Cheers,
Josh

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



OpenPGP_signature
Description: OpenPGP digital signature

Re: python3, tabs, and Terminal

[Joshua Root]

On 2022-10-13 08:05 , Joshua Root wrote:

Langer, Stephen A. (Fed) wrote:

I don’t know if I have something wrong in my settings or expectations, 
or if this is a bug.  Typing a tab in an Apple Terminal window while 
using any version of Python3 from MacPorts makes the terminal enter 
some kind of editing mode, instead of just indenting the line.  
Python2 from MacPorts doesn't do this, and neither does Python3 from 
Apple, which makes me think that it's some kind of Python 
configuration issue in MacPorts.  The same thing happens when using 
iTerm2.


For example:

% python3
Python 3.8.15 (default, Oct 12 2022, 03:09:36)
[Clang 13.0.0 (clang-1300.0.29.3)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>>/def f(): / <--- anything typed here brings up old lines 
from other sessions, when I just want to indent
Do you see this with newer python versions? I don't see it in 3.10, 
FWIW. I remember there were some bugs with libedit support in older 
versions.


You can try installing py38-gnureadline, which will override the 
built-in readline module.


- Josh



Turns out this is a feature: 
<https://docs.python.org/3/library/site.html#rlcompleter-config>


- Josh

Re: python3, tabs, and Terminal

[Joshua Root]

Langer, Stephen A. (Fed) wrote:


I don’t know if I have something wrong in my settings or expectations, or if 
this is a bug.  Typing a tab in an Apple Terminal window while using any 
version of Python3 from MacPorts makes the terminal enter some kind of editing 
mode, instead of just indenting the line.  Python2 from MacPorts doesn't do 
this, and neither does Python3 from Apple, which makes me think that it's some 
kind of Python configuration issue in MacPorts.  The same thing happens when 
using iTerm2.

For example:

% python3
Python 3.8.15 (default, Oct 12 2022, 03:09:36)
[Clang 13.0.0 (clang-1300.0.29.3)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>>/def f(): / <--- anything typed here brings up old lines from 
other sessions, when I just want to indent
Do you see this with newer python versions? I don't see it in 3.10, 
FWIW. I remember there were some bugs with libedit support in older 
versions.


You can try installing py38-gnureadline, which will override the 
built-in readline module.


- Josh

Re: py27-pygtk

[Joshua Root]

On 2022-10-13 03:58 , Lukas Oberhuber wrote:
Here is the Portfile: 
https://gitlab.gnome.org/Infrastructure/gimp-macos-build/-/blob/dee2dcff05491fd5cd455fe1ab4164633720339b/ports/graphics/gimp2/Portfile 


Here is a gist of the logs: 
https://gist.github.com/lukaso/806cfb5fd90d147b6328a7aa0112a490 



Hopefully you have some ideas! Thanks.


Well here's your problem:

:debug:configure Executing org.macports.configure (gimp210)
:debug:configure Environment: 
:debug:configure CC_PRINT_OPTIONS='YES'

:debug:configure 
CC_PRINT_OPTIONS_FILE='/opt/local/var/macports/build/_Users_lukasoberhuber_project_ports_graphics_gimp2/gimp210/work/.CC_PRINT_OPTIONS'
:debug:configure CPATH='/opt/local/include'
:debug:configure DEVELOPER_DIR='/Library/Developer/CommandLineTools'
:debug:configure LIBRARY_PATH='/opt/local/lib'
:debug:configure MACOSX_DEPLOYMENT_TARGET='11.0'
:debug:configure 
SDKROOT='/Library/Developer/CommandLineTools/SDKs/MacOSX11.3.sdk'


There should be around 15 more environment variables set. Not just 
PKG_CONFIG_PATH and PYTHON but ones set by base like CC, CFLAGS and so on.


I think this is because the configure script is being run as part of the 
autoreconf command, not configure proper.


BTW, these two lines both do exactly the same thing, so you can just 
remove the second one:
configure.pkg_config_path 
${python_framework}/lib/pkgconfig:${prefix}/lib/pkgconfig
configure.env-append 
PKG_CONFIG_PATH=${python_framework}/lib/pkgconfig:${prefix}/lib/pkgconfig


And you don't need to specify ${prefix}/lib/pkgconfig in there because 
that's already in the default search paths.


- Josh

Re: py27-pygtk

[Joshua Root]

Lukas Oberhuber wrote:


I'm trying to build gimp2.10.32 (I'm the mac maintainer). I've got a custom
Portfile, but for the life of me, I can't get gimps autotools (configure.ac)
to pick up on `py27-pygtk`.

I've set done this:

set python_framework${frameworks_dir}/Python.framework/Versions/2.7
configure.pkg_config_path
${python_framework}/lib/pkgconfig:${prefix}/lib/pkgconfig

with and without the second path.

I've tried many variants of

depends_lib-append port:pygtk-2.0.pc:py27-pygtk
with and without the .pc file and with and without directories before them.


That should be just:

depends_lib-append port:py27-pygtk

But as long as the correct port is already installed, that won't change the 
behaviour of pkg-config.


But every time on build I get

checking for pygtk-codegen-2.0... no
checking for pygtk defs... Package pygtk-2.0 was not found in the
pkg-config search path.
Perhaps you should add the directory containing `pygtk-2.0.pc'
to the PKG_CONFIG_PATH environment variable
No package 'pygtk-2.0' found


Checking assumptions, try this outside of the port:

PKG_CONFIG_PATH=/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/pkgconfig
 pkg-config --exists --print-errors pygtk-2.0

In general when asking for help debugging a port, it's very helpful to share 
the Portfile and logs in a gist or something.

- Josh

MacPorts 2.8.0-beta1 now available for testing

[Joshua Root]

Source code and pkgs for MacPorts 2.8.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] 


OpenPGP_signature
Description: OpenPGP digital signature

Re: Unable to build XV

[Joshua Root]

If someone wanted to update the xv port to use this repo, that would 
make it compatible with jasper 3 (among other things): 



- Josh

Re: missing pre-compiled packages

[Joshua Root]

Chris Jones wrote:


Binaries aren’t available if the licenses of the port, and its dependencies, do 
not allow it.

To check if this is the case you should refer to the build logs which you can 
find from the ports site. E.g.

https://ports.macports.org/port/git

Then check the builds tab. Pick one, and then check the gather archives log

https://build.macports.org/builders/ports-12_arm64-builder/builds/61881/steps/gather-archives/logs/stdio

"git" is not distributable because its license "GPL-2" conflicts with license "GPL-3+" of 
dependency "gdbm"


That works if the logs are still available, but they get deleted after a 
while. The script that is used on the buildbot is available here: 



So you can check that out and run it locally as well. The script to 
execute is port_binary_distributable.tcl, which also requires 
distributable_lib.tcl to be present.


- Josh

Re: missing pre-compiled packages

[Joshua Root]

Werner LEMBERG wrote:


I wonder why some pre-compiled packages are missing:

* ccache – the directory `https://packages.macports.org/ccache/`  
  is
   empty

* git – the directory `https://packages.macports.org/git/`  
  doesn't
   exist at all

If this is expected, where is it documented?


Yes, it's expected that not all ports will have binaries available. See 
.


The automated license checking doesn't have all the relevant 
information, so it errs on the side of not distributing. Port 
maintainers can add some options manually if it gets it wrong. I've done 
that for ccache now and binaries should be uploaded soon. Git is a 
considerably more difficult case to audit and it may well have a genuine 
license conflict that precludes binary distribution.


- Josh

Re: Macports user on login screen after migration from old Mac to new Mac

[Joshua Root]

On 2022-8-1 03:27 , Murray Eisenberg wrote:
In a message posted already in this list’s archives but not yet 
appearing in the batched emails I receive from the list, Johsua Root writes:


“ … the 'macports’ user… should be as unprivileged as possible, and thus not a 
member of any groups other than its own.

"TBH, the easiest fix is probably to delete the 'macports' user and group, and let 
them be recreated by the installer during step 2 of the Migration process."

How does one, in fact, delete the ‘macports’ user and group before 
letting them be recreated by the installer during Step 2 of the MacPorts 
migration process?


(I note that no user ‘macports’ shows in System Preferences > Users & 
Groups even though user ‘macports’ appears on the macOS login screen.)


The correct dscl commands can be found in section 2.4.2 of the MacPorts 
Guide: 



- Josh

Re: Macports user on login screen after migration from old Mac to new Mac

[Joshua Root]

I don't know what 'macadmin' is. If you mean the 'macports' user, it should be 
as unprivileged as possible, and thus not a member of any groups other than its 
own.

TBH, the easiest fix is probably to delete the 'macports' user and group, and 
let them be recreated by the installer during step 2 of the Migration process.

- Josh

Murray Eisenberg wrote:


As follow-up:

What user group should macadmin belong to? During the migration I was asked 
whether to use a temporary something-or-other for macports user or else to make 
it part of the admin group. I did the latter.


> On 31 Jul2022, at 11:01 AM, Murray Eisenberg https://lists.macports.org/mailman/listinfo/macports-users>  >> wrote:
> 
> On an iMac I was running MacPorts 2.7.2 under macOS Monterey 12.5. I used the macOS Migration Assistant to migrate Documents and Settings from a Time Machine backup of that iMac to a new Mac Studio, also running macOS 12.5.
> 
> Now at the login screen I show a user MacPorts, but I do not see such user listed when, in my admin account, I use System Preferences > Users & Groups.
> 
> What, if anything, should be done?

Re: Problem with rsync.macports.org mirror?

[Joshua Root]

There hasn't been a base release recently, so that output is completely expected when 
updating the base sources. There should be some more output involving "--->  
Updating the ports tree" which, if you have an rsync-based source configured in 
sources.conf, will run additional rsync commands to update ports.tar and PortIndex. That 
worked for me when I tried it just now.

Gerben Wierda wrote:


Because after finishing it still said ‘more than two weeks old please update’, 
and it downloaded not more than 50-60 bytes

Gerben Wierda (LinkedIn )
R Enterprise Architecture  (main site)
Book: Chess and the Art of Enterprise Architecture 
Book: Mastering ArchiMate 

>/On 31 Jul 2022, at 11:58, Chris Jones > wrote: />//>//>//>>/On 31 Jul 2022, at 9:05 am, Gerben Wierda via macports-users 
> wrote: />>//>>/ />>/gerben at hermione 
 
macports-ports % sudo port -v selfupdate />>/---> Updating MacPorts base sources using rsync />>//>>/Willkommen auf dem RSYNC-server auf ftp.fau.de . />>/Nicht all unsere Mirror sind per rsync verfuegbar. />>//>>/Welcome to the RSYNC daemon on ftp.fau.de . />>/Not all of our mirrors are available through rsync. />>//>>//>>/receiving file list ... done />>//>>/sent 16 bytes received 55 bytes 142.00 bytes/sec />>/total size is 85861888 speedup is 1209322.37 />>//>>/Willkommen auf dem RSYNC-server auf ftp.fau.de . />>/Nicht all unsere Mirror sind per rsync verfuegbar. />>//>>/Welcome to the RSYNC daemon on ftp.fau.de . />>/Not all of our mirrors are available through rsync. />>//>>//>>/receiving file list ... done />>//>>/sent 16 bytes received 62 bytes 52.00 bytes/sec/

Re: openal-soft fails to build (fwd)

[Joshua Root]

Looks like openal-soft is linking with libsndfile despite not depending 
on it (and fails because the lack of a declared dependency also means 
the architectures haven't been made to match.) File a ticket.


- Josh

Re: Warning: Configuration logfiles contain indications of -Wimplicit-function-declaration; check that features were not accidentally disabled:

[Joshua Root]

We have a wiki page with an in-depth explanation of what this warning 
means: 


The executive summary for end users is that this is something that the 
port's maintainer needs to look into, so you can file a ticket about it, 
but it may or may not indicate a significant problem.


- Josh

Re: zsh problems MacOS High Sierra

[Joshua Root]

Ryan Schmidt wrote:


On May 2, 2022, at 23:49, Sriranga Veeraraghavan wrote:

>/I am not a zsh user, but according to zsh's documentation, 
~/.zprofile is run only when zsh is used as a login shell, whereas 
~/.zshenv is read for nearly every instance of zsh (including scripts): />//>/https://zsh.sourceforge.io/Guide/zshguide02.html#l9 />//>/Because of this, it is possible that if /opt/local/bin, etc., are 
only added to PATH in ~/.zprofile, then in some instances zsh would 
use the Apple standard programs in /bin, /sbin, /usr/bin, etc., while 
in other instances zsh would use, for example, the MacPorts versions 
in /opt/local/bin, etc. This might lead to inconsistencies or hard to 
detect bugs in shell scripts, etc. /

MacPorts has been modifying ~/.zprofile when the shell is zsh ever since zsh 
support was added to MacPorts 2.5 years ago. If it is a problem, nobody has 
reported it so far.

https://github.com/macports/macports-base/commit/f9a3b2d5bcc27a1a279184c496a095f31b5d85a2

All shells on macOS are login shells.


Not all shells are login shells, but non-login shells are commonly child 
processes of a login shell that already executed the startup files. So 
non-login shells will usually inherit any variables exported in 
zprofile. Also, any shell can (and often does) run another shell. That 
means that all code in zshenv and zshrc needs to behave correctly when 
executed multiple times. Unconditionally appending to PATH will result 
in the value being added multiple times, once per "layer" of shell. So 
that's one reason why we don't use zshenv.


The other is that Apple's /etc/zprofile overwrites PATH, so any changes 
made to it before that file is read don't stick.


- Josh

Re: Corrupted ports.tar file?

[Joshua Root]

Bill Cole wrote:


Theory: it's a problem related to running the reclaim from the prompt at the 
tail end of a selfupdate. Incomplete 'portindex' run perhaps?


Good theory. It's likely that when the periodic reclaim run at exit was 
added, it wasn't considered that it might be running after code that 
made it unsafe to do anything but continue to exit.


- Josh

Re: port diagnose and xcode

[Joshua Root]

I truly appreciate everyone who maintains things for MP - couldn’t live without 
this stuff.  My initial query was just trying to understand whether ‘port 
diagnose’ was telling me something I should be concerned about.  I think the 
answer was ‘no’.
The message could be improved for that case, certainly. All that check 
does currently is print the message that started this discussion if your 
currently installed version of Xcode is not in the list of versions 
known to work on your OS version: 



If no version of Xcode is installed, it should say something along the 
lines of "You don't have Xcode installed, so you will not be able to 
build the subset of ports that build using Xcode."


It should also check the CLT version but currently doesn't.

- Josh

Re: Remove "Phantom" Ports

[Joshua Root]

James Secan wrote:


I have a number of apparently old/replaced ports (p5.26-*) that have been replaced 
at some point by their p5.28-* updates that are still in some way “alive” on my 
system.  They show up when I run "port upgrade installed -u outdated” as 
follows:

Warning:  No port p5.26- found in the index

I’ve tried various ways to get rid of these phantoms, but nothing I’ve tried 
(like a simple port uninstall) is willing to admit that any p5.26-* ports are 
around, although a ‘port installed’ command will list all of them and note that 
they are active.  I am by no stretch an expert in portsmanship, so I could 
easily be missing some simple answer.


These are indeed ports that are installed but are no longer present in 
the ports tree. You can refer to all such ports using the 
pseudo-portname 'obsolete', for example:


port echo obsolete

port uninstall obsolete

Note that this could potentially also match ports that you still want, 
since any ports installed directly from a portfile that is not part of a 
tree listed in sources.conf will be in exactly the same situation. So 
check the echo output before proceeding.


A normal 'port uninstall ' will work on such ports. Without 
seeing a terminal transcript, my suspicion would be that a typo may have 
been the reason your uninstall didn't work. If it's really not possible 
to run uninstall on such a port, that is of course a bug, so please file 
a ticket if that's the case.


- Josh

MacPorts 2.7.2 has been released

[Joshua Root]

The MacPorts Project is pleased to announce the release of version
2.7.2. This is a bugfix release with small changes only. See the
ChangeLog [1] for the list of changes.

If you already have MacPorts installed, the preferred method for
updating is to run:

   sudo port selfupdate

For new installs, there are also package installers available for macOS
versions ranging from macOS 12 Monterey all the way back to 10.4 at [2]. 
The source is also available as tarballs compressed with gzip or bzip2, 
or from the git tag [3].


Detached PGP signatures for the disk images, packages and source
tarballs have been made with my key, which is available on the
keyservers and my MacPorts wiki page [4], the fingerprint being:

0x01FF673FB4AAE6CD: C403 7936 5723 6DCF 2E58  0C02 01FF 673F B4AA E6CD

Josh
(on behalf of the MacPorts Port Managers)

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



OpenPGP_signature
Description: OpenPGP digital signature

Re: Is this git handling of a problem on my macports-ports fork OK?

[Joshua Root]

Gerben Wierda wrote:


But I have been advised a pull is not enough, I should first do a fetch.


If you're referring to my private reply, what I said was that a rebase 
was not enough to bring master up to date with upstream/master, you have 
to fetch as well.


As per the git-pull man page:

  git pull runs git fetch with the given parameters and
   then depending on configuration options or command line flags, 
will call

   either git rebase or git merge to reconcile diverging branches.

Our project policy is to avoid merge commits.

- Josh

Re: Is this git handling of a problem on my macports-ports fork OK?

[Joshua Root]

On 2022-2-21 10:12 , Gerben Wierda wrote:
The time I did a successful pull request, I think I did not first merge 
my working branch back into my own master, but I did a pull request from 
my branch from the GitHub website (after having pushed my branch to my 
own fork)


It seemed to me, using my branch would be a lot cleaner as my branch 
only has the changes I made myself. Did I misunderstand git (again)?


That all sounds like the normal recommended procedure. There's no need 
to merge your branch back into master locally, because that's what 
merging the PR does. Next time you fetch from upstream, the PR change 
will be included.


The process in brief is: Create branch from master, make changes and 
commit them on the branch, push branch to your fork, open PR, wait for 
PR to be merged, delete branch. Your master should never diverge from 
upstream/master.


- Josh

Re: Is this git handling of a problem on my macports-ports fork OK?

[Joshua Root]

On 2022-2-21 10:01 , Gerben Wierda wrote:
Stuff like ‘—autostash' and ‘popping the stash’ is gobbledygook to me. 
git is just something that covers so many complex scenario’s and I am 
using it so little in those scenarios that most of it is simply out of 
my understanding.




I mean simply that when you run:

git rebase upstream/master

as per the WorkingWithGit instructions, add the --autostash option:

git rebase --autostash upstream/master

And your uncommitted changes will be automagically preserved without git 
complaining about them.


- Josh

Re: Understaning rleaves, rdepof

[Joshua Root]

Gerben Wierda wrote:


So, how would you go about finding the ports on which what is actually 
installed depends?

E.g.: if I have dovecot+solr8 installed, how would I find out which ports 
dovecot truly depends on on my system?


Is there a reason that information is required apart from curiosity? 
MacPorts won't install anything you didn't ask for unless it's a 
dependency of something you did ask for, and if you try to uninstall 
something that is still needed by something else, it will complain.


'port deps dovecot and installed' will usually work, though it uses the 
current Portfile, so if the port is outdated the dependencies could have 
changed. Use rdeps instead of deps if you want all recursive 
dependencies, and use the --no-build option with either action to 
exclude dependencies only needed at build time.


- Josh

Re: Is this git handling of a problem on my macports-ports fork OK?

[Joshua Root]

Our suggested method of updating a fork is here: 



Hopefully you're not committing to master locally, as that's just asking 
for trouble. If you're not, no resetting or force pushing of master 
should be necessary. If you have uncommitted local changes, you probably 
need to use --autostash when rebasing. If there are conflicts, you 
resolve them when the stash is popped at the end.


If you then create your PR branches starting from master, everything 
should work pretty smoothly.


- Josh

Re: What have I forgotten about specifying which Perl should be /opt/local/bin/perl?

[Joshua Root]

Richard L. Hamilton  wrote:

>/On Jan 22, 2022, at 11:13, Ryan Schmidt > wrote: />//>/Release date information is not available in MacPorts. Are you 
proposing that the maintainer of every port should do research to 
discover the release date every time they want to update a port to a 
new version and add that information to a new field in the portfile? Why? />//>/Or are you referring to the date when an update of a portfile was 
committed to GitHub? If so, why would that be useful to you? /

The latter, since the former, although possibly more useful, is too difficult.


That part at least is simple:

ls -l `port file someport`

- Josh

Re: port upgrade outdated hangs networking

[Joshua Root]

This is extraordinary .. it presumably is a bug in MacOS.

Running MacOS 10.15.7  on MacBook Pro 2016

I am updating various already installed packges in the usual way:
sudo port upgrade outdated

Everything goes along fine until the software reached gd2.
I then see:

--->  Fetching archive for gd2
--->  Attempting to fetch gd2-2.3.3_1+x11.darwin_19.x86_64.tbz2 from
https://packages.macports.org/gd2
--->  Attempting to fetch gd2-2.3.3_1+x11.darwin_19.x86_64.tbz2 from
https://nue.de.packages.macports.org/gd2
--->  Attempting to fetch gd2-2.3.3_1+x11.darwin_19.x86_64.tbz2 from
https://ema.uk.packages.macports.org/gd2
--->  Fetching distfiles for gd2

At this point the networking on the machine hangs.
I cannot kill the port process. I cannot reach the
offending machine even by ping; I cannot use
the network from another terminal nor browser.
Are you running any third-party firewall? This looks a lot like 
, though that was on Big Sur. I 
would agree it's certainly an OS bug in any case.


You can try the edits mentioned in the ticket to see if it's the pings 
that are triggering the bug. A quick workaround if you just need to get 
gd2 installed is to download the distfile manually as per 
.


- Josh

Re: Installation location for python code, tools, etc.

[Joshua Root]

I'm not very experienced with Python, yet, but with regard to MacPorts,
I'm trying to understand why when I do a pip3 install, or a direct
install from a project tree ie: "python setup.py install" the tool(s)
end up in this directory instead of /opt/local/bin|sbin etc:

/opt/local/Library/Frameworks/Python.framework/Versions/3.9/bin/


Python is typically built as a framework on macOS, so that's where the 
modules go. See 
.


% python3.9
Python 3.9.9 (main, Nov 16 2021, 17:57:38)
[Clang 13.0.0 (clang-1300.0.29.3)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> sys.prefix
'/opt/local/Library/Frameworks/Python.framework/Versions/3.9'

Pip has a number of options controlling where things are installed: 



I strongly recommend not installing modules into the MacPorts prefix 
with pip (or manually), because modules installed in other ways will 
conflict with modules installed by MacPorts. Install in a venv, or use 
pip's --user option or some completely separate prefix.


- Josh

Re: Building Ruby gems with MacPorts Ruby

[Joshua Root]

It appears that the ruby31 port is missing something, as I can install ruby30, 
switch to it with sudo port select --set ruby ruby30, then install gems no 
problem.
I just had a look and ruby31 is indeed doing something wrong. Here's the 
ticket I filed: 


- Josh

Re: [numpy @ bigsur: multithreading]

[Joshua Root]

Maxim Abalenkov wrote:


Dear all,

I’m looking for guidance please. I would like to make sure, that I use all 
eight of my CPU cores, when I run Python’s 3.9.9 NumPy on my macOS BigSur 12.1. 
When I run my NumPy code, I see in ‘htop’, that only one ‘python’ process is 
running and the core utilisation is 20–25%. I remember in the past, stock 
MacPorts NumPy installation would use Apple’s Accelerate library including the 
multithreaded BLAS and LAPACK 
(https://developer.apple.com/documentation/accelerate). As I understand this is 
no longer the case.

I run Python code using a virtual environment located under

  /opt/venv/zipfstime/lib/python3.9/site-packages/numpy/core

When I change there and issue

  otool -L _multiarray_umath.cpython-39-darwin.so

_multiarray_umath.cpython-39-darwin.so:
@loader_path/../.dylibs/libopenblas.0.dylib (compatibility version 
0.0.0, current version 0.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current 
version 1281.100.1)

In other words, NumPy relies on openBLAS. Command `port variants openblas` 
returns

OpenBLAS has the variants:
   g95: Build using the g95 Fortran compiler
 * conflicts with gcc10 gcc11 gcc8 gcc9 gccdevel
   gcc10: Build using the MacPorts gcc 10 compiler
 * conflicts with g95 g95 gcc11 gcc8 gcc9 gccdevel
[+]gcc11: Build using the MacPorts gcc 11 compiler
 * conflicts with g95 g95 gcc10 gcc8 gcc9 gccdevel
   gcc8: Build using the MacPorts gcc 8 compiler
 * conflicts with g95 g95 gcc10 gcc11 gcc9 gccdevel
   gcc9: Build using the MacPorts gcc 9 compiler
 * conflicts with g95 g95 gcc10 gcc11 gcc8 gccdevel
   gccdevel: Build using the MacPorts gcc devel compiler
 * conflicts with g95 g95 gcc10 gcc11 gcc8 gcc9
[+]lapack: Add Lapack/CLapack support to the library
   native: Force compilation on machine to get fully optimized library
   universal: Build for multiple architectures

I tried installing the “native” variant of OpenBLAS port with `sudo port 
install openblas +native` and setting the environment variable 
`OMP_NUM_THREADS=8`, but I didn’t see any improvement when running my Python 
code. I would welcome your help and guidance on this subject.

I'm using py39-numpy with default variants:

% port installed py39-numpy openblas
The following ports are currently installed:
  OpenBLAS @0.3.19_0+gcc11+lapack (active)
  py39-numpy @1.21.5_1+gfortran+openblas (active)

I see Python using around 600% CPU on my 6-core machine when running 
this basic benchmark script: 



If you try that and see how many cores it uses, that will at least tell 
you if there is something different about your code. If it doesn't use 
all the cores for you, there are some other environment variables that 
OpenBLAS looks at that you could check: 



- Josh

Re: python ports depend on openssl not in index

[Joshua Root]

SeaQuench wrote:


After applying an update to MacOS last August, the python ports are reporting a 
dependency on either openssl11 or openssl3, neither of which are to be found in 
the (local?) index for MacPorts, according to the error I have received, copied 
below. While I am prompted to report a bug, I presume I am not in a novel 
situation. Could someone advise me as to how to proceed? I am running MacPorts 
2.6.2 on MacOS 10.15.7 with XCode 12.4 installed.
The primary problem here is that you are running MacPorts 2.6.2 
(released in 2019). The current ports are not going to work with an old 
version of base. You need to update to 2.7.1, and the other problems 
will likely be resolved by that.


- Josh

Re: What is up with perl5.26 on Snow Leo?

[Joshua Root]

Ulrich Wienands wrote:


The funny thing is that almost every Macports install seems to want to upgrade 
this perl5.26; although as far as I can tell my perl5.26 is perfectly fine. So 
I am forced to use -n for each install to get anything done, which I fond a bit 
unsettling. Maybe I need to hose perl5.26?

Uli
That sounds more like rev-upgrade is noticing that the installed 
perl5.26 is broken and trying to rebuild it, rather than there being a 
dependency. Yes, you should probably just uninstall perl5.26; almost 
nothing depends on it any more (at least with default variants).


- Josh

Re: Does MacPorts need ALL of Xcode?

[Joshua Root]

Ryan Schmidt wrote:

Ports that include the xcode portgroup also most probably require Xcode. I would have 
thought that the xcode 1.0 portgroup would declare "use_xcode yes" somewhere in 
it, but it doesn't seem to. Maybe that is an oversight.


It isn't. Setting build.type to "xcode" also sets use_xcode to "yes".

- Josh

Re: Running MacPorts on macOS 12?

[Joshua Root]

First of all, please be aware of 
.



Sorry for bugging the mailing list with a day-one beta.

Trying to run macports with 'sudo port’ errors out with a OS platform mismatch 
error.

Error: Current platform "darwin 21" does not match expected platform "darwin 20"
Error: If you upgraded your OS, please follow the migration instructions: 
https://trac.macports.org/wiki/Migration
OS platform mismatch
while executing
"mportinit ui_options global_options global_variations"
Error: /opt/local/bin/port: Failed to initialize MacPorts, OS platform mismatch

Is there a workaround to use MacPorts (knowing that it’s unsupported and data 
loss might happen)
before any official support comes out?


The solution is in the error message: you upgraded to a new OS version, 
so you need to follow the Migration instructions. Since there is 
obviously no binary installer for this OS version, step 2 "install the 
base MacPorts system for your new platform" will need to be done by 
installing from source.




- Josh

Re: zathura install but fails with libjson.5.dylib not found

[Joshua Root]

Uli Wienands wrote:
I got zathura to install (and it rebuilt even through it seem like there 
should have been a binary). Then got the pdf -poppler plugin needed to 
actually decode pdf files.


My problem is that zathura does not start up but bombs with libjson-c.5 
not found. Her is the error message. Note there is no specific log.


  The error occurs early on, before X11 is fired up.

ulis-mbp-2:Documents uli$ zathura
dyld: Library not loaded: /opt/local/lib/libjson-c.5.dylib
   Referenced from: /opt/local/lib/libgirara-gtk3.3.dylib
   Reason: image not found
Trace/BPT trap

I have libjson-c.3.dylib.


That would be the problem then. The current version of the json-c port 
provides libjson-c.5.dylib.


As long as you're using the default ports tree, upgrading or 
reinstalling json-c should sort this out. If you got into this state by 
having a local json-c Portfile or manually activating an older version, 
you might need to deal with that first.


- Josh

MacPorts 2.7.1 has been released

[Joshua Root]

The MacPorts Project is pleased to announce the release of version
2.7.1. This is a bugfix release with small changes only. See the
ChangeLog [1] for the list of changes.

If you already have MacPorts installed, the preferred method for
updating is to run:

  sudo port selfupdate

For new installs, there are also package installers available for macOS
versions ranging from macOS 11 Big Sur all the way back to 10.4 at [2]. 
The source is also available as tarballs compressed with gzip or bzip2, 
or from the git tag [3].


Note for macOS 10.14 users: if you are unable to selfupdate due to the 
SQL error mentioned in the ChangeLog, you will need to install MacPorts 
2.7.1 either with the .pkg installer or from source.


Detached PGP signatures for the disk images, packages and source
tarballs have been made with my key, which is available on the
keyservers and my MacPorts wiki page [4], the fingerprint being:

0x01FF673FB4AAE6CD: C403 7936 5723 6DCF 2E58  0C02 01FF 673F B4AA E6CD

Josh
(on behalf of the MacPorts Port Managers)

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



OpenPGP_signature
Description: OpenPGP digital signature

Re: macports << I run Mojave and can test that build

[Joshua Root]

On 2021-5-24 00:04 , Jeffrey Jay Hayes wrote:

Hi Joshua

I have Xcode 11.3.1 installed .. I will have to check which version of 
the SDK is installed


The definitive test is whether you get the SQL error shown in the ticket 
after selfupdating to 2.7.0 from an earlier version. You can check the 
SDK used by running (should be all one line, but may be wrapped by the 
mail client):


plutil -p `xcrun --show-sdk-path`/SDKSettings.plist | fgrep CanonicalName

`xcrun --show-sdk-version` should theoretically also work but seems to 
encounter errors sometimes.


I do not have MacPorts currently installed as I am no longer doing 
development work so this can be a clean install for the test.


Great, thanks for offering.

- Josh