During Migration to Arm64 mac, should I null out archs='x86_64' from installed ports list?

[Jim DeLaHunt]

Hello, MacPorts folks:

I am following the MacPorts wiki "Migration"[1] instructions as I move 
from a macOS 10.14.6 Mojave machine with an intel CPU to a macOS 13.1 
Monterey machine with an arm64 CPU. I got stuck with a bug in the tiff 
port, which fails during destroot under the +universal variant. I opened 
a ticket[2] against tiff +universal on arm64, but that is not my 
question here.


I don't know why MacPorts was trying to install tiff with the +universal 
variant. I am following the Migration instructions. They have me make a 
list of installed ports using `port -qv installed`. None of these 
entries mention "requested_variants='+universal'". 91% have an empty 
string for requested variants. 9% request some other variant. However, 
two-thirds mention "archs='x86_64'", while the other one-third mention 
"archs='noarch'", and none have empty strings or some other value for 
"archs". I use the restore_ports.tcl script to install the ports on the 
new computer.


Here are four representative entries from my list of installed ports:

  aalib @1.4rc5_5 (active) requested_variants='' platform='darwin 18' 
archs='x86_64' date='2021-08-30T13:16:05-0700'
  abcde @2.9.3_1 (active) requested_variants='' platform='darwin 18' 
archs='noarch' date='2022-01-23T21:52:02-0800'
  apr-util @1.6.1_2+no_bdb (active) requested_variants='+no_bdb' 
platform='darwin 18' archs='x86_64' date='2021-08-30T13:16:21-0700'
  aspell @0.60.8_1 (active) requested_variants='-nls' platform='darwin 18' 
archs='x86_64' date='2021-08-30T13:34:34-0700'

Might the presence of "archs='x86_64'" cause the restore_ports.tcl 
script to ask for +universal variants on the new computer?


Should I perhaps null out the value "x86_64" from the archs entries in 
my installed ports list?  i.e. turn them into "archs='' "? Or should I 
replace them with the value "arm64"?


I don't see any mention in the Migration instructions about modifying 
"archs" entries when migrating from one architecture to another.


[1] 
[2] , tiff@4.3.0_0+universal: 
Failed to destroot tiff, "libtiff-4.pc differs"


--
.--Jim DeLaHunt, Vancouver, Canada

Re: Corrupted ports.tar file?

[Dave Horsfall]

On Mon, 11 Apr 2022, Ryan Schmidt wrote:

> Run "sudo port selfupdate" to get the most recent ports.tar. Do you 
> still see the problem then?

I did run that first; apologies for not mentioning it (there were no 
issues).

In fact, my schedule is:

Sunday: "port -u uninstall" to clean out ports that were squirrelled away.
Monday: "port selfupdate; port upgrade outdated" (under "script").

Note that "port selfupdate" offers to run "port reclaim" every fortnight, 
where this problem was observed.

> This message could occur if you run "sudo port selfupdate" (or "sudo 
> port sync") in one terminal window while another MacPorts process is 
> still running in another terminal window. So it's best not to do that. 
> If you weren't doing that, I can't explain it.

Not a chance that I'd do anything as silly as that (I've been a sysadmin 
for nearly 50 years)...  All my updates are run in the one window (with 
scrollback).

I'll see if this heisenbug happens again next week (I can't spend any time 
on debugging it right now).

-- Dave

Re: qt4-mac on M1

[Peter West]

Arch supports have been added to my local installations of the kde4 and qt4 
portgroup files.

That doesn’t solve the problem.

I now have in my local ports dir 
ports:
databases:
openldap
devel:
aqbanking:
automac:
gwenhywfar4:
libgcrypt:
virtuoso:
virtuoso-7:
kde:
kmymoney4:
security:
cyrus-sasl2:

with
supported_archs ppc ppc64 i386 x86_64
added.

My current trouble is with gwenhywfar4. Command execution fails with lots of 
compile error and warnings which seem to be focussed on cocoa.

I’ve added arch support to the portfile, but the problem may be with the 
subports.

subport gwenhywfar4-gtk {}
subport gwenhywfar4-gtk3 {}

These seem to be looking at gtk2 and gtk3 respectively. Can I just disable one 
or the other? It looks as though I’m going to have to go down a separate rabbit 
hole with one or both of them.


if {$subport == "gwenhywfar4-gtk"} {
depends_lib-append  path:lib/pkgconfig/gtk+-2.0.pc:gtk2
configure.args-append   --with-guis="gtk2 cpp" --disable-qt4
}

if {$subport == "gwenhywfar4-gtk3"} {
depends_lib-append  path:lib/pkgconfig/gtk+-3.0.pc:gtk3
configure.args-append   --with-guis="gtk3 cpp" --disable-qt4
}


Any top-of-the-head idea on how to get it to build?



—
Peter West
p...@ehealth.id.au
…the whole multitude of his disciples began to rejoice and praise God with a 
loud voice for all the mighty works that they had seen, saying, “Blessed is the 
King who comes in the name of the Lord! Peace in heaven and glory in the 
highest!”


> On 3 Apr 2022, at 2:45 am, Ryan Schmidt  wrote:
> 
> On Apr 1, 2022, at 22:26, Peter West wrote:
> 
>> I’m following dependencies which have their own dependency on qt4-mac and 
>> are set to universal, I presume, because I get messages like
>> 
>> Error: Cannot install automoc for the archs 'arm64 x86_64' because
>> Error: its dependency qt4-mac only supports the archs 'ppc ppc64 i386 
>> x86_64'.
> 
> Ok. Since automoc also uses the kde4 portgroup which uses the qt4 portgroup, 
> adding the supported_archs line to the qt4 portgroup should solve that as 
> well.
> 
> Additionally, as I understand it, automoc is a tool used at build time only 
> and it does not contain any libraries. Therefore the line "installs_libs no" 
> should be added to the automoc Portfile which should cause MacPorts to no 
> longer try to enforce an architecture match, which would also avoid the 
> problem.
> 

installing py310-jupyter fails: cannot import name 'StaticModule' from 'setuptools.config'

[Corcoran, Michael F. (GSFC-662.0)[CATHOLIC UNIV OF AMERICA] via macports-users]

I was trying to install py310-jupyter  but the install failed when building 
py310-jupyterlab_widgets.  The problem seems to be that the StaticModule 
package is imported by

/opt/local/Library/Frameworks/Python.framework/Versions/3.10/lib/python3.10/site-packages/jupyter_packaging/setupbase.py

but not found in setuptools.config:

from setuptools.config import StaticModule
ImportError: cannot import name 'StaticModule' from 'setuptools.config' 
(/opt/local/Library/Frameworks/Python.framework/Versions/3.10/lib/python3.10/site-packages/setuptools/config/__init__.py)

Any idea how to solve this?

the relevant lines from the main.log file are

:debug:build system:  cd 
"/opt/local/var/macports/build/_opt_local_var_macports_sources_github.com_macports_macports-ports_python_py-jupyterlab_widgets/py310-jupyterlab_widgets/work/jupyterlab_widgets-1.0.2"
 && /opt/local/Library/Frameworks/Python.framework/Versions/3.10/bin/python3.10 
setup.py --no-user-cfg build -j16
:info:build Traceback (most recent call last):
:info:build   File 
"/opt/local/var/macports/build/_opt_local_var_macports_sources_github.com_macports_macports-ports_python_py-jupyterlab_widgets/py310-jupyterlab_widgets/work/jupyterlab_widgets-1.0.2/setup.py",
 line 6, in 
:info:build from jupyter_packaging import (
:info:build   File 
"/opt/local/Library/Frameworks/Python.framework/Versions/3.10/lib/python3.10/site-packages/jupyter_packaging/__init__.py",
 line 7, in 
:info:build from .setupbase import *
:info:build   File 
"/opt/local/Library/Frameworks/Python.framework/Versions/3.10/lib/python3.10/site-packages/jupyter_packaging/setupbase.py",
 line 38, in 
:info:build from setuptools.config import StaticModule
:info:build ImportError: cannot import name 'StaticModule' from 
'setuptools.config' 
(/opt/local/Library/Frameworks/Python.framework/Versions/3.10/lib/python3.10/site-packages/setuptools/config/__init__.py)

I've filed a ticket but was wondering if anyone on the list had any insight…

thanks

Mike


Dr. Michael F. Corcoran
The Catholic University of America
Goddard Space Flight Center, Code 662
Greenbelt, MD 20771

Re: Corrupted ports.tar file?

[Ryan Schmidt]

On Apr 10, 2022, at 16:31, Dave Horsfall wrote:

> Early MacBook Pro, High Sierra 10.13.6, MacPorts 2.7.2.
> 
> When doing my weekly MacPorts maintenance (doesn't everyone?), I saw this 
> during a "port reclaim" (automatically requested):
> 
>Found no inactive ports.
>--->  Building list of distfiles still in use
>Warning: It looks like your PortIndex file for 
> rsync://rsync.macports.org/macports/release/tarballs/ports.tar may be corrupt.
>Warning: Port bzip2 not found: 
>Warning: It looks like your PortIndex file for 
> rsync://rsync.macports.org/macports/release/tarballs/ports.tar may be corrupt.
>Warning: Port db48 not found: 
>Warning: It looks like your PortIndex file for 
> rsync://rsync.macports.org/macports/release/tarballs/ports.tar may be corrupt.
> 
> Etc; I do have "bzip2" and so on.
> 
> Haven't seen that before; what's going on?  A following "port upgrade 
> outdated" saw no problems...

Run "sudo port selfupdate" to get the most recent ports.tar. Do you still see 
the problem then?

This message could occur if you run "sudo port selfupdate" (or "sudo port 
sync") in one terminal window while another MacPorts process is still running 
in another terminal window. So it's best not to do that. If you weren't doing 
that, I can't explain it.

Re: ccache problem

[Werner LEMBERG]

>> It seems to be a problem with the 'ccache' package/port on MacOS
>> 10.7.5.  After updating to current git (and running `port sync`),
>> `port upgrade outdated` just tried to compile emacs 28.1, and
>> exactly the same problem happened.
> 
> It looks like /run/user//ccache-tmp is indeed a path hardcoded
> into the ccache program.

Thanks for checking.

> The documentation says:
> 
> https://ccache.dev/manual/4.6.html#config_temporary_dir
> 
> "The default is /run/user//ccache-tmp if /run/user/
> exists, otherwise /tmp."
> 
> If you are certain that /run/user/ does not exist, then perhaps
> the detection of its existence is faulty on Mac OS X 10.7.5.

It seems so.  I've just removed directory `/run/user/`, but
emacs configuration still aborts: the directory
`/run/user//ccache-tmp` has been created again (owner
'macports.staff', mode 'drwxr-xr-x') but `ccache` can't create any
files in it, failing in the same way as already reported.

I've just opened https://trac.macports.org/ticket/64983.

> To install an older version of a port, see
> https://trac.macports.org/wiki/howto/InstallingOlderPort

Thanks.


Werner

Re: ccache problem

[Ryan Schmidt]

On Apr 9, 2022, at 14:33, Werner LEMBERG wrote:

>>> ```
>>> ccache /opt/local/bin/clang-mp-13 ... conftest.c >&5
>>> ccache: error: Failed to create temporary file for
>>>  /run/user/507/ccache-tmp/tmp.cpp_stdout.RTVNqj: Operation not permitted
>>> ```
>>> 
>>> What's the reason that `port` tries to use
>>> `/run/user/507/ccache-tmp/` (uid 507 = macports) instead of the
>>> default ccache dir?
>> 
>> I've never heard of that happening before. macOS has never had a
>> /run directory.
> 
> Well, I'm not a MacOS user – except doing regular updates for MacPorts
> (and checking/adjusting the LilyPond port if necessary), this computer
> isn't used for anything else.
> 
>> Is a path beginning with /run/user familiar to you?
> 
> No.
> 
>> Do you have something special set on your system that uses such
>> paths?
> 
> No idea.  As mentioned in my previous e-mail, I haven't changed
> anything in the configuration.
> 
>> Does this happen with any other ports or just lilypond-devel?  Maybe
>> lilypond-devel's build system is doing something weird.
> 
> It seems to be a problem with the 'ccache' package/port on MacOS
> 10.7.5.  After updating to current git (and running `port sync`),
> `port upgrade outdated` just tried to compile emacs 28.1, and exactly
> the same problem happened.
> 
> How can I test most easily whether my assumption is correct?  What is
> the recommended way to install an older version of 'ccache'?


It looks like /run/user//ccache-tmp is indeed a path hardcoded into the 
ccache program.


The documentation says:

https://ccache.dev/manual/4.6.html#config_temporary_dir

"The default is /run/user//ccache-tmp if /run/user/ exists, otherwise 
/tmp."

If you are certain that /run/user/ does not exist, then perhaps the 
detection of its existence is faulty on Mac OS X 10.7.5.


The changelog for 4.6 says:

https://ccache.dev/releasenotes.html#_bug_fixes

"Ccache now verifies that /run/user//ccache-tmp is writable before using 
it for temporary files."

Perhaps that detection is faulty on Mac OS X 10.7.5 or something else was 
inadvertently changed/broken during the implementation of this fix.


To install an older version of a port, see 
https://trac.macports.org/wiki/howto/InstallingOlderPort