Re: Port reclaim unexpectedly wants to uninstall a subport, when the top level port is installed
> On Feb 6, 2024, at 21:01, Joshua Root wrote: > >> 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 Thanks for the suggestion. But, a few minutes before I received it, I decided to take the nuclear option. I did a similar process as is done during a migration to a new macOS, saving lists of installed and requested ports, uninstalling all, etc. That seems to have put things right. Kevin
Port reclaim unexpectedly wants to uninstall a subport, when the top level port is installed
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? === OS: macOS Sonoma 14.3 arch: Intel % port version Version: 2.9.1
Re: py-skyfield depends on both cython and cython-devel
Thanks for the info. The current situation is quite unsatisfactory as it imposes significant complication for the typical user who likely needs several different packages, some of which depend on cython and some on cython-devel. In the specific cases of py-skyfield and py-astropy, if I understand correctly, they depended on cython until the most recent major update to py-astropy. Would it be possible to have both py-astropy and py-astropy-devel packages? py-astropy would be the last version that was compatible with cython, and py-astropy-devel would be the newer version that requires cython-devel. Similar thing with py-skyfield. Thanks, Kevin > On Dec 15, 2023, at 06:08, Marius Schamschula wrote: > > Kevin, > > It is not your fault! > > py-cython and py-cython-devel (cython 3.0.x) are incompatible, but the many > packages haven’t been updated and still use the legacy version. This needs to > be fixed upstream. > > py-yaml still needs py-cython, whereas py-astropy has been updated and > requires py-cython-devel. > > However, as both packages install into the same location, you get a deadlock. > > I work around this issue, by deactivating the version not needed at the time > and activating the needed one. YMMV. > > Marius > -- > Marius Schamschula > > > > >> On Dec 14, 2023, at 7:41 PM, Kevin Horton wrote: >> >> I'm trying to install py-skyfield and it is failing with: >> >> ---> Computing dependencies for py-skyfield >> Error: Can't install py311-cython-devel because conflicting ports are >> active: py311-cython >> >> >> Digging deeper, 'port rdeps py-skyfield' shows (output trimmed to only show >> the relevant dependency chain): >> >> The following ports are dependencies of py-skyfield @1.46_0: >> py311-skyfield >>py311-astropy >> py311-cython-devel >> cfitsio >>gcc13 >> gcc13-libcxx >>clang-16 >> py311-yaml >>py311-cython >> >> Is this situation possibly due to something I have done that can be >> corrected? Or, Is there a way I can reconcile the requirement to have both >> cython and cython-devel installed? >> >> Thanks, >> >> Kevin Horton >
py-skyfield depends on both cython and cython-devel
I'm trying to install py-skyfield and it is failing with: ---> Computing dependencies for py-skyfield Error: Can't install py311-cython-devel because conflicting ports are active: py311-cython Digging deeper, 'port rdeps py-skyfield' shows (output trimmed to only show the relevant dependency chain): The following ports are dependencies of py-skyfield @1.46_0: py311-skyfield py311-astropy py311-cython-devel cfitsio gcc13 gcc13-libcxx clang-16 py311-yaml py311-cython Is this situation possibly due to something I have done that can be corrected? Or, Is there a way I can reconcile the requirement to have both cython and cython-devel installed? Thanks, Kevin Horton
Re: Quartz no longer launching when an X application is invoked
> On Dec 4, 2023, at 10:08, Ryan Schmidt wrote: > > Could you file a new ticket to do that cleanup? Bonus points if you want to > submit a pull request to implement it. See: > Thanks for providing the history here. Ticket 68836 created. https://trac.macports.org/ticket/68836#ticket
Re: Quartz no longer launching when an X application is invoked
One of my machines has: % echo $DISPLAY :0 Digging deeper, I find in ~/.zprofile # MacPorts Installer addition on 2020-12-29_at_06:08:54: adding an appropriate DISPLAY variable for use with MacPorts. export DISPLAY=:0 # Finished adapting your DISPLAY environment variable for use with MacPorts. My other machine also has a ~/.zprofile, but it only sets the PATH. it does not set DISPLAY. I surmise that MacPorts stopped fiddling with DISPLAY sometime between late 2020 and late 2021. Maybe there should be some automatic check of DISPLAY in .zprofile, and a it could offer to clean it up if needed. Cheers, Kevin > On Dec 1, 2023, at 03:42, Christopher Jones wrote: > > > >> On 1 Dec 2023, at 6:52 am, Kenneth Wolcott wrote: >> >> Hi; >> >> So what is the proper way for X to be started? > > > If properly configured the X11 server will automatically start on demand. You > really should never need to manually start it. > >> >> Do I need to manually create a launch entry like I have for the >> emacs server? If so, what is the invocation? What is being invoked? >> xorg-server? >> >> Now that the DISPLAY is null, invoking xpdf fails even after an open >> -a /Applications/MacPorts/X11.app, complaining about the DISPLAY >> variable setting > > Having DISPLAY null is as bad as setting it to :0.0 > > It should look something like what I posted before > > $ echo $DISPLAY > /private/tmp/com.apple.launchd.TwDg8TRtvI/org.macosforge.xquartz:0 > > This is the launchd socket, the magic if you like, that triggers it to be > started on demand. > > Please try as I posted in my first mail completeing uninstalling org-server, > then re-install it. Then log out and back in again (this is important) and > then see. If it is still null then you have something else setting that and > you need to figure out what. > > Chris > >> >> Thanks, >> Ken >> >> On Thu, Nov 30, 2023 at 10:47 PM Kenneth Wolcott >> wrote: >>> >>> Hi Ryan; >>> >>> It was defined in ~/.zprofile and created by MacPorts in 2021 :-) I >>> commented it out. I'll source the .zprofile and see what happens. >>> >>> Thanks, >>> Ken >>> >>> On Thu, Nov 30, 2023 at 10:23 PM Ryan Schmidt >>> wrote: On Nov 30, 2023, at 16:01, Kenneth Wolcott wrote: > > 3. My DISPLAY environment variable is set to ":0"; > I do not know where this variable is not being set properly or is > being overridden. You need to figure out where DISPLAY=:0 is being set, and remove the code that does so. It's probably in your shell startup file. Depending on which shell you use, there are many possible names for startup files in your home directory: .zshrc, .zprofile, .bashrc, .bash_profile, etc. Setting DISPLAY=:0 was correct in Mac OS X 10.4 and earlier but it has not been correct since Mac OS X 10.5. >
Re: Status of Macports on Sonoma?
> On Oct 7, 2023, at 09:59, Chris Jones wrote: > > Hi, > >> On 7 Oct 2023, at 1:12 am, Kevin Horton wrote: >> >> I'm pondering whether I should upgrade to macOS Sonoma now, or continue to >> wait. Generally speaking, how well is Macports working on Sonoma? I have >> seen a surprising small number of issues posted on this list, and am >> wondering whether that is a good reflection of the status. > > I would not base your opinion on messages to this list, as that is not the > recommended way of reporting issues. You should instead check trac for issue > related to the new OS. See the link from > > https://trac.macports.org/ > > Chris Thanks - I dug into Trac, looked at the ports I need and their dependencies, and concluded that I should wait before upgrading to Sonoma. Cheers, Kevin
Status of Macports on Sonoma?
I'm pondering whether I should upgrade to macOS Sonoma now, or continue to wait. Generally speaking, how well is Macports working on Sonoma? I have seen a surprising small number of issues posted on this list, and am wondering whether that is a good reflection of the status. Thanks, Kevin Horton
py39-pyqt5 build fails on macOS 11.6 on Intel
An attempt to build py39-pyqt5 on macOS 11.6 on Intel, using XCode 13.0, fails
with:
:debug:build system: cd
"/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_python_py-pyqt5/py39-pyqt5/work/PyQt5-5.15.4"
&& sip-build-3.9 --qmake /opt/local/libexec/qt5/bin/qmake --verbose
--confirm-license
--dbus=/opt/local/Library/Frameworks/Python.framework/Versions/3.9/include/python3.9/dbus-1.0
--disable QtWebKit --disable QtWebKitWidgets
:info:build Traceback (most recent call last):
:info:build File "/opt/local/bin/sip-build-3.9", line 33, in
:info:build sys.exit(load_entry_point('sip==6.3.1', 'console_scripts',
'sip-build')())
:info:build File "/opt/local/bin/sip-build-3.9", line 25, in
importlib_load_entry_point
:info:build return next(matches).load()
:info:build StopIteration
:info:build Command failed: cd
"/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_python_py-pyqt5/py39-pyqt5/work/PyQt5-5.15.4"
&& sip-build-3.9 --qmake /opt/local/libexec/qt5/bin/qmake --verbose
--confirm-license
--dbus=/opt/local/Library/Frameworks/Python.framework/Versions/3.9/include/python3.9/dbus-1.0
--disable QtWebKit --disable QtWebKitWidgets
:info:build Exit code: 1
:error:build Failed to build py39-pyqt5: command execution failed
:debug:build Error code: CHILDSTATUS 65183 1
:debug:build Backtrace: command execution failed
:debug:build while executing
:debug:build "system {*}$notty {*}$callback {*}$nice $fullcmdstring"
:debug:build invoked from within
:debug:build "command_exec -callback portprogress::target_progress_callback
build"
:debug:build (procedure "portbuild::build_main" line 8)
:debug:build invoked from within
:debug:build "$procedure $targetname"
:error:build See
/opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_python_py-pyqt5/py39-pyqt5/main.log
for details.
=
I checked the CLI tools version:
pkgutil --pkg-info=com.apple.pkg.CLTools_Executables
--pkg-info=com.apple.pkg.CLTools_Base
--pkg-info=com.apple.pkg.DeveloperToolsCLI
--pkg-info=com.apple.pkg.DeveloperToolsCLILeo 2>/dev/null | sed -n 's/^version:
//p'
13.0.0.0.1.1630607135
=
I've accepted the XCode license with 'sudo xcodebuild -license'
Is there anything else I should try to get py39-pyqt5 to build, or should I
file a ticket now?
Thanks,
Kevin Horton
Workflows and best practices for pull requests?
I'm new to working with a team of committers, and I'm a very basic git user, so I'm struggling to figure out workflows and best practices when making a pull request and reviewing comments on a pull request. Questions: 1. One of the checkboxes when making a pull request is "squashed and minimized your commits". I tend to make many small commits when working on my personal projects. What is the best way to squash those commits before making the pull request? Google seems to suggest an interactive rebase is the way to go. Comments? 2. I'm completely baffled by the GitHub interface for dealing with comments on a pull request. Assuming I have made and testing the changes suggested by reviewers, what is my next action? Make a new pull request? Is there a way to modify the existing pull request? Thanks, Kevin
Re: New portfile writer looking for help with ConvertAll
> On Jul 12, 2021, at 6:48 PM, Kevin Horton wrote:
>
>
>> On Jul 12, 2021, at 6:29 PM, Ryan Schmidt > <mailto:ryandes...@macports.org>> wrote:
>>
>> On Jul 12, 2021, at 20:13, Kevin Horton wrote:
>>
>>> I'm trying to create a port for ConvertAll - http://convertall.bellz.org
>>> <http://convertall.bellz.org/>. I've been using MacPorts for several
>>> years, but have never created a portfile before. I used Fink for many
>>> years before switching to MacPorts, and I was a maintainer for a handful of
>>> packages. I'm an enthusiastic amateur, not a coder.
>>>
>>> My attempts to get a ConvertAll portfile working are running into problems
>>> when MacPorts detects that the build process is trying to install files in
>>> /opt/local/share/convertall, and it fails with a permissions error. I'm
>>> baffled as to what is going on here.
>>>
>>> Current draft Portfile:
>>> # -*- coding: utf-8; mode: tcl; tab-width: 4; indent-tabs-mode: nil;
>>> c-basic-offset: 4 -*- vim:fenc=utf-8:ft=tcl:et:sw=4:ts=4:sts=4
>>>
>>> PortSystem 1.0
>>> PortGroup github 1.0
>>> PortGroup python 1.0
>>> PortGroup qt5 1.0
>>>
>>> github.setupdoug-101 ConvertAll 0.8.0 v
>>> github.tarball_from releases
>>>
>>> python.versions 34 35 36 37 38 39
>>> python.default_version 38
>>>
>>> qt5.min_version 5.4
>>>
>>> nameconvertall
>>> version 0.8.0
>>> license GPL-2+
>>> categories math, science
>>
>> Remove the comma here.
>>
>>> platforms darwin
>>> maintainers {@khorton kilohotel.com <http://kilohotel.com/>:kevin01}
>>> description Extremely flexible unit converter
>>> long_descriptionConvertAll has a large database of units, and allows
>>> conversions \
>>> that use multiple units, e.g. convert from feet per
>>> decade to \
>>> nautical miles per fortnight.
>>> homepagehttp://convertall.bellz.org
>>> <http://convertall.bellz.org/>
>>>
>>> checksums rmd160 89fcc2aa9bad7ecc1de7bee4edea68fdff39706a \
>>> sha256
>>> 624c8a792b0bc7ff3776499c2c743b32273569efd0567615e570a7e739e8d521 \
>>> size281055
>>>
>>> depends_lib-append port:py${python.version}-pyqt5
>>>
>>> use_configure no
>>> build.cmd ${python.bin} install.py
>>> build.args -p ${prefix} \
>>> -b ${destroot}
>>>
>>> post-patch {
>>> reinplace "s|/usr/local|${prefix}|g" ${worksrcpath}/install.py
>>> }
>>>
>>> Extract of build log showing failure:
>>
>> Looks like you just pasted the portfile again here. Can you show the failure
>> log? I'm specifically interested in determining whether the failure is
>> occurring in the build phase or in the destroot phase. If the latter, then
>> it'll be because you only set build.cmd and build.args and didn't set
>> destroot.cmd and destroot.args.
>>
>> Looks like you've set build.cmd and build.args reasonably for this build
>> system, but MacPorts usually builds in the build phase and stages into the
>> destroot in the destroot phase. If there is a way to tell this build system
>> to do that, do so. In that case, you would probably need to set destroot.cmd
>> and destroot.args too. If it is quite difficult to tell the build system to
>> do that, then it is acceptable for the build phase to install the files into
>> the destroot already and to have the destroot phase do nothing. In that
>> case, you could disable the destroot phase by writing "destroot {}". Some
>> ports do it the other way around, where the build phase does nothing ("build
>> {}") and the destroot phase does the building and the destrooting.
>
>
> Whoops
>
> :info:build Checking dependencies...
> :info:build Python Version 3.8.11 -> OK
> :info:build Qt Version 5.15.2 -> OK
> :info:build PyQt Version 5.15.4 -> OK
> :info:build Installing files...
> :info:build Copying python files to /usr/local/share/convertall
> :info:build Traceback (most recent call last):
> :info:build File "install.py", line 308, in
> :info
New portfile writer looking for help with ConvertAll
I'm trying to create a port for ConvertAll - http://convertall.bellz.org. I've
been using MacPorts for several years, but have never created a portfile
before. I used Fink for many years before switching to MacPorts, and I was a
maintainer for a handful of packages. I'm an enthusiastic amateur, not a coder.
My attempts to get a ConvertAll portfile working are running into problems when
MacPorts detects that the build process is trying to install files in
/opt/local/share/convertall, and it fails with a permissions error. I'm
baffled as to what is going on here.
Current draft Portfile:
# -*- coding: utf-8; mode: tcl; tab-width: 4; indent-tabs-mode: nil;
c-basic-offset: 4 -*- vim:fenc=utf-8:ft=tcl:et:sw=4:ts=4:sts=4
PortSystem 1.0
PortGroup github 1.0
PortGroup python 1.0
PortGroup qt5 1.0
github.setupdoug-101 ConvertAll 0.8.0 v
github.tarball_from releases
python.versions 34 35 36 37 38 39
python.default_version 38
qt5.min_version 5.4
nameconvertall
version 0.8.0
license GPL-2+
categories math, science
platforms darwin
maintainers {@khorton kilohotel.com:kevin01}
description Extremely flexible unit converter
long_descriptionConvertAll has a large database of units, and allows
conversions \
that use multiple units, e.g. convert from feet per decade
to \
nautical miles per fortnight.
homepagehttp://convertall.bellz.org
checksums rmd160 89fcc2aa9bad7ecc1de7bee4edea68fdff39706a \
sha256
624c8a792b0bc7ff3776499c2c743b32273569efd0567615e570a7e739e8d521 \
size281055
depends_lib-append port:py${python.version}-pyqt5
use_configure no
build.cmd ${python.bin} install.py
build.args -p ${prefix} \
-b ${destroot}
post-patch {
reinplace "s|/usr/local|${prefix}|g" ${worksrcpath}/install.py
}
Extract of build log showing failure:
# -*- coding: utf-8; mode: tcl; tab-width: 4; indent-tabs-mode: nil;
c-basic-offset: 4 -*- vim:fenc=utf-8:ft=tcl:et:sw=4:ts=4:sts=4
PortSystem 1.0
PortGroup github 1.0
PortGroup python 1.0
PortGroup qt5 1.0
github.setupdoug-101 ConvertAll 0.8.0 v
github.tarball_from releases
python.versions 34 35 36 37 38 39
python.default_version 38
qt5.min_version 5.4
nameconvertall
version 0.8.0
license GPL-2+
categories math, science
platforms darwin
maintainers {@khorton kilohotel.com:kevin01}
description Extremely flexible unit converter
long_descriptionConvertAll has a large database of units, and allows
conversions \
that use multiple units, e.g. convert from feet per decade
to \
nautical miles per fortnight.
homepagehttp://convertall.bellz.org
checksums rmd160 89fcc2aa9bad7ecc1de7bee4edea68fdff39706a \
sha256
624c8a792b0bc7ff3776499c2c743b32273569efd0567615e570a7e739e8d521 \
size281055
depends_lib-append port:py${python.version}-pyqt5
use_configure no
build.cmd ${python.bin} install.py
build.args -p ${prefix} \
-b ${destroot}
post-patch {
reinplace "s|/usr/local|${prefix}|g" ${worksrcpath}/install.py
}
Help info for ConvertAll's install.py:
% python install.py -h
Usage:
python install.py [-h] [-p dir] [-d dir] [-i dir] [-b dir] [-s] [-x]
where:
-h display this help message
-p dir install prefix [default: /usr/local]
-d dir documentaion dir [default: /share/doc/convertall]
-i dir icon dir [default: /share/icons/convertall]
-b dir temporary build root for packagers [default: /]
-s skip language translation files
-x skip all dependency checks (risky)
Any assistance or advice would be greatly appreciated.
Thanks,
Kevin Horton
Re: py-ptyprocess bug - Was: Re: new ipython crash with recent update on Big Sur
On Jan 5, 2021, at 4:22 AM, Jonathan Stickel wrote: > > > Date: Mon, 4 Jan 2021 20:03:53 -0800 > From: Kevin Horton mailto:kevi...@kilohotel.com>> > To: MacPorts Users <mailto:macports-users@lists.macports.org>> > Cc: strom...@macports.org <mailto:strom...@macports.org> > Subject: py-ptyprocess bug - Was: Re: new ipython crash with recent > update on Big Sur > Message-ID: <4529a2fc-4004-4f06-92f6-c6ca29291...@kilohotel.com > <mailto:4529a2fc-4004-4f06-92f6-c6ca29291...@kilohotel.com>> > Content-Type: text/plain; charset=us-ascii > > On Jan 4, 2021, at 7:48 PM, Kevin Horton <mailto:kevi...@kilohotel.com>> wrote: > > > > A recent update has borked py37-ipython and py38-ipython for me on two > > Intel machines on macOS 11.1 with XCode 12.3. > > > > Symptoms: run ipython. In ipython, do the following: > > > > import sys > > sys. # i.e. press the Tab key. This should show a list of > > functions and attributes of sys. If ipython is borked it returns nothing > > sys.argv? > > sys. # this produces a ipython crash. > > > > > > At first I only had this on the laptop where I had updated to Big Sur a > > couple of days ago, and then followed the migration steps, which updated > > all ports to the latest versions. The iMac, which had been updated to Big > > Sur several weeks ago, did not exhibit the issue. I suspected some issue > > unique to the laptop, so did the usual troubleshooting steps. Then I did a > > port selfupdate on the iMac and it now had the same problem. I used Time > > Machine to roll back to before the port selfupdate, and ipython is working > > correctly again. > > > > I'd file a bug, but I don't know which port is the problem yet. > > It looks like the problem is with py-ptyprocess 0.7.0_0 . The problem goes > away if I downgrade to py37-ptyprocess 0.6.0_0 and then rebuild py37-ipython > > Kevin > > > Maybe it is related to this: > > https://github.com/ipython/ipython/issues/12121 > <https://github.com/ipython/ipython/issues/12121> > > I think there was also a macports ticket that was closed when a version of > some dependency was incremented. Anyway, the same workaround works for me: > > `ipython --IPCompleter.use_jedi=False` > > I am on Catalina. Thanks! This same workaround works on Big Sig. Kevin
py-ptyprocess bug - Was: Re: new ipython crash with recent update on Big Sur
On Jan 4, 2021, at 7:48 PM, Kevin Horton wrote: > > A recent update has borked py37-ipython and py38-ipython for me on two Intel > machines on macOS 11.1 with XCode 12.3. > > Symptoms: run ipython. In ipython, do the following: > > import sys > sys. # i.e. press the Tab key. This should show a list of functions > and attributes of sys. If ipython is borked it returns nothing > sys.argv? > sys. # this produces a ipython crash. > > > At first I only had this on the laptop where I had updated to Big Sur a > couple of days ago, and then followed the migration steps, which updated all > ports to the latest versions. The iMac, which had been updated to Big Sur > several weeks ago, did not exhibit the issue. I suspected some issue unique > to the laptop, so did the usual troubleshooting steps. Then I did a port > selfupdate on the iMac and it now had the same problem. I used Time Machine > to roll back to before the port selfupdate, and ipython is working correctly > again. > > I'd file a bug, but I don't know which port is the problem yet. It looks like the problem is with py-ptyprocess 0.7.0_0 . The problem goes away if I downgrade to py37-ptyprocess 0.6.0_0 and then rebuild py37-ipython Kevin
new ipython crash with recent update on Big Sur
A recent update has borked py37-ipython and py38-ipython for me on two Intel machines on macOS 11.1 with XCode 12.3. Symptoms: run ipython. In ipython, do the following: import sys sys. # i.e. press the Tab key. This should show a list of functions and attributes of sys. If ipython is borked it returns nothing sys.argv? sys. # this produces a ipython crash. At first I only had this on the laptop where I had updated to Big Sur a couple of days ago, and then followed the migration steps, which updated all ports to the latest versions. The iMac, which had been updated to Big Sur several weeks ago, did not exhibit the issue. I suspected some issue unique to the laptop, so did the usual troubleshooting steps. Then I did a port selfupdate on the iMac and it now had the same problem. I used Time Machine to roll back to before the port selfupdate, and ipython is working correctly again. I'd file a bug, but I don't know which port is the problem yet. Best regards, Kevin
Re: wxWidgets-3.0 warnings with Big Sur
> On Dec 29, 2020, at 9:18 PM, Ken Cunningham > wrote: > > > >> On Dec 29, 2020, at 8:47 PM, Kevin Horton wrote: >> >> I moved libwx_osx_cocoau_core-3.0.0.dylib and >> libwx_osx_cocoau_core-3.0.dylib aside and symlinked those names to >> /libwx_osx_cocoau_core-3.0.0.4.0.dylib >> >> ls -al *core* >> -rwxr-xr-x 1 root wheel 4743504 Nov 23 00:52 >> libwx_osx_cocoau_core-3.0.0.4.0.dylib >> lrwxr-xr-x 1 root wheel 37 Dec 29 20:44 >> libwx_osx_cocoau_core-3.0.0.dylib -> libwx_osx_cocoau_core-3.0.0.4.0.dylib >> lrwxr-xr-x 1 root wheel 37 Dec 29 20:44 >> libwx_osx_cocoau_core-3.0.dylib -> libwx_osx_cocoau_core-3.0.0.4.0.dylib >> >> I rebuilt gnuplot, but still get the same errors: >> >> objc[90874]: Class wxNSAppController is implemented in both >> /opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxWidgets/3.0/lib/libwx_osx_cocoau_core-3.0.0.4.0.dylib >> (0x10c39fc40) and >> /opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxWidgets/3.0/lib/libwx_osx_cocoau_core-3.0.dylib >> (0x10b1fbc40). One of the two will be used. Which one is undefined. >> objc[90874]: Class ModalDialogDelegate is implemented in both >> /opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxWidgets/3.0/lib/libwx_osx_cocoau_core-3.0.0.4.0.dylib >> (0x10c39fc68) and >> /opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxWidgets/3.0/lib/libwx_osx_cocoau_core-3.0.dylib >> (0x10b1fbc68). One of the two will be used. Which one is undefined. >> objc[90874]: Class wxNSApplication is implemented in both >> /opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxWidgets/3.0/lib/libwx_osx_cocoau_core-3.0.0.4.0.dylib >> (0x10c39fcb8) and >> /opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxWidgets/3.0/lib/libwx_osx_cocoau_core-3.0.dylib >> (0x10b1fbcb8). One of the two will be used. Which one is undefined. >> >> Anything else to try to learn something useful? > > Nah — turns out it’s a known bug, so add another vote to Ryan’s radar if you > can. > > Make the symlinks yourself, and then you’re good. > > Nothing wrong with wxWidgets-3.0. Not worth rewriting the scripts in > wxWidgets for this Apple bug, IMHO. > > K I needed to make the symlinks for all sets of libraries in /opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxWidgets/3.0/lib. After that gnuplot runs without the wall of warnings. I'll have a go at filing a feedback with Apple. Thanks, Kevin
Re: wxWidgets-3.0 warnings with Big Sur
> On Dec 29, 2020, at 20:13, Ryan Schmidt wrote: > > On Dec 29, 2020, at 20:12, Kevin Horton wrote: > >> On Dec 29, 2020, at 17:20, Ken Cunningham wrote: >>> >>> Interesting. >>> >>> /opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxWidgets/3.0/lib/libwx_osx_cocoau_core-3.0.0.4.0.dylib >>> and >>> /opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxWidgets/3.0/lib/libwx_osx_cocoau_core-3.0.dylib >>> are actually the same library; one is just a symlink to the other: >>> >>> % ls -la >>> /opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxWidgets/3.0/lib/libwx_osx_cocoau_core-3.0* >>> >>> -rwxr-xr-x 1 macports wheel 4563192 31 Oct 2019 >>> /opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxWidgets/3.0/lib/libwx_osx_cocoau_core-3.0.0.4.0.dylib >>> lrwxr-xr-x 1 root wheel 37 31 Oct 2019 >>> /opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxWidgets/3.0/lib/libwx_osx_cocoau_core-3.0.0.dylib >>> -> libwx_osx_cocoau_core-3.0.0.4.0.dylib >>> lrwxr-xr-x 1 root wheel 33 31 Oct 2019 >>> /opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxWidgets/3.0/lib/libwx_osx_cocoau_core-3.0.dylib >>> -> libwx_osx_cocoau_core-3.0.0.dylib >>> >>> I have only one referenced: >>> >>> % otool -L /opt/local/bin/gnuplot | grep core >>> >>> /opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxWidgets/3.0/lib/libwx_osx_cocoau_core-3.0.dylib >>> (compatibility version 5.0.0, current version 5.0.0) >>> >>> and I see no such warnings on Catalina, but perhaps this is related to the >>> new way that dylibs are found on BigSur, and it’s getting confused by the >>> symlink… >>> >>> It’s very hard to imagine nobody would have ever noticed that before, >>> though. >>> >>> Ken >> >> Things seem different on Big Sur. I don't see any symlinks here: >> >> % ls -la >> /opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxWidgets/3.0/lib/libwx_osx_cocoau_core-3.0* >> -rwxr-xr-x 1 root wheel 4743504 Nov 23 00:52 >> /opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxWidgets/3.0/lib/libwx_osx_cocoau_core-3.0.0.4.0.dylib >> -rwxr-xr-x 1 root wheel 4743504 Nov 23 00:52 >> /opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxWidgets/3.0/lib/libwx_osx_cocoau_core-3.0.0.dylib >> -rwxr-xr-x 1 root wheel 4743504 Nov 23 00:52 >> /opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxWidgets/3.0/lib/libwx_osx_cocoau_core-3.0.dylib > > I suspect this is because of this Apple bug that I have mentioned before: > > https://lists.macports.org/pipermail/macports-dev/2020-November/042641.html > > Please check if Xcode 12.3 still has the problem. If it does, please file > additional bug reports with Apple about this and mention that it is a > duplicate of FB8915358 so that they realize how many people it affects so > that they fix it. > This is with XCode 12.3. I moved libwx_osx_cocoau_core-3.0.0.dylib and libwx_osx_cocoau_core-3.0.dylib aside and symlinked those names to /libwx_osx_cocoau_core-3.0.0.4.0.dylib ls -al *core* -rwxr-xr-x 1 root wheel 4743504 Nov 23 00:52 libwx_osx_cocoau_core-3.0.0.4.0.dylib lrwxr-xr-x 1 root wheel 37 Dec 29 20:44 libwx_osx_cocoau_core-3.0.0.dylib -> libwx_osx_cocoau_core-3.0.0.4.0.dylib lrwxr-xr-x 1 root wheel 37 Dec 29 20:44 libwx_osx_cocoau_core-3.0.dylib -> libwx_osx_cocoau_core-3.0.0.4.0.dylib I rebuilt gnuplot, but still get the same errors: objc[90874]: Class wxNSAppController is implemented in both /opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxWidgets/3.0/lib/libwx_osx_cocoau_core-3.0.0.4.0.dylib (0x10c39fc40) and /opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxWidgets/3.0/lib/libwx_osx_cocoau_core-3.0.dylib (0x10b1fbc40). One of the two will be used. Which one is undefined. objc[90874]: Class ModalDialogDelegate is implemented in both /opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxWidgets/3.0/lib/libwx_osx_cocoau_core-3.0.0.4.0.dylib (0x10c39fc68) and /opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxWidgets/3.0/lib/libwx_osx_cocoau_core-3.0.dylib (0x10b1fbc68). One of the two will be used. Which one is undefined. objc[90874]: Class wxNSApplication is implemented in both /opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxWidgets/3.0/lib/libwx_osx_cocoau_core-3.0.0.4.0.dylib (0x10c39fcb8) and /opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxWidgets/3.0/lib/libwx_osx_cocoau_core-3.0.dylib (0x10b1fbcb8). One of the two will be used. Which one is undefined. Anything else to try to learn something useful? Thanks, Kevin
Re: wxWidgets-3.0 warnings with Big Sur
On Dec 29, 2020, at 17:20, Ken Cunningham wrote: > > Interesting. > > /opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxWidgets/3.0/lib/libwx_osx_cocoau_core-3.0.0.4.0.dylib > and > /opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxWidgets/3.0/lib/libwx_osx_cocoau_core-3.0.dylib > are actually the same library; one is just a symlink to the other: > > % ls -la > /opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxWidgets/3.0/lib/libwx_osx_cocoau_core-3.0* > > -rwxr-xr-x 1 macports wheel 4563192 31 Oct 2019 > /opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxWidgets/3.0/lib/libwx_osx_cocoau_core-3.0.0.4.0.dylib > lrwxr-xr-x 1 root wheel 37 31 Oct 2019 > /opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxWidgets/3.0/lib/libwx_osx_cocoau_core-3.0.0.dylib > -> libwx_osx_cocoau_core-3.0.0.4.0.dylib > lrwxr-xr-x 1 root wheel 33 31 Oct 2019 > /opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxWidgets/3.0/lib/libwx_osx_cocoau_core-3.0.dylib > -> libwx_osx_cocoau_core-3.0.0.dylib > > I have only one referenced: > > % otool -L /opt/local/bin/gnuplot | grep core > > /opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxWidgets/3.0/lib/libwx_osx_cocoau_core-3.0.dylib > (compatibility version 5.0.0, current version 5.0.0) > > and I see no such warnings on Catalina, but perhaps this is related to the > new way that dylibs are found on BigSur, and it’s getting confused by the > symlink… > > It’s very hard to imagine nobody would have ever noticed that before, though. > > Ken Things seem different on Big Sur. I don't see any symlinks here: % ls -la /opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxWidgets/3.0/lib/libwx_osx_cocoau_core-3.0* -rwxr-xr-x 1 root wheel 4743504 Nov 23 00:52 /opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxWidgets/3.0/lib/libwx_osx_cocoau_core-3.0.0.4.0.dylib -rwxr-xr-x 1 root wheel 4743504 Nov 23 00:52 /opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxWidgets/3.0/lib/libwx_osx_cocoau_core-3.0.0.dylib -rwxr-xr-x 1 root wheel 4743504 Nov 23 00:52 /opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxWidgets/3.0/lib/libwx_osx_cocoau_core-3.0.dylib And the files have different inodes, so not hard links either: % ls -il *core* 68952234 -rwxr-xr-x 1 root wheel 4743504 Nov 23 00:52 libwx_osx_cocoau_core-3.0.0.4.0.dylib 68952250 -rwxr-xr-x 1 root wheel 4743504 Nov 23 00:52 libwx_osx_cocoau_core-3.0.0.dylib 68952220 -rwxr-xr-x 1 root wheel 4743504 Nov 23 00:52 libwx_osx_cocoau_core-3.0.dylib But only one is found by otool % otool -L /opt/local/bin/gnuplot | grep core /opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxWidgets/3.0/lib/libwx_osx_cocoau_core-3.0.dylib (compatibility version 5.0.0, current version 5.0.0) Everything seems to work correctly, if you ignore the spewage, so this likely sits low on the priority list. Kevin
wxWidgets-3.0 warnings with Big Sur
I'm running macOS 11.1 and followed the migration instructions. Today I ran gnuplot for the first time, and the CLI spewed out over 400 lines of warnings related to wxWidgets. The first few lines were: objc[53143]: Class wxNSAppController is implemented in both /opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxWidgets/3.0/lib/libwx_osx_cocoau_core-3.0.0.4.0.dylib (0x10bf24c40) and /opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxWidgets/3.0/lib/libwx_osx_cocoau_core-3.0.dylib (0x10ad85c40). One of the two will be used. Which one is undefined. objc[53143]: Class ModalDialogDelegate is implemented in both /opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxWidgets/3.0/lib/libwx_osx_cocoau_core-3.0.0.4.0.dylib (0x10bf24c68) and /opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxWidgets/3.0/lib/libwx_osx_cocoau_core-3.0.dylib (0x10ad85c68). One of the two will be used. Which one is undefined. objc[53143]: Class wxNSApplication is implemented in both /opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxWidgets/3.0/lib/libwx_osx_cocoau_core-3.0.0.4.0.dylib (0x10bf24cb8) and /opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxWidgets/3.0/lib/libwx_osx_cocoau_core-3.0.dylib (0x10ad85cb8). One of the two will be used. Which one is undefined. I uninstalled gnuplot, wxWidgets-3.0, wxWidgets-common and wxWidgets_select and then installed them to force a rebuild. No change. Gnuplot appears to work normally, so no panic. Is there anything else I should try before filing a bug? Thanks, Kevin
Re: Migration doc suggestion - chsh
> On Nov 28, 2020, at 6:40 AM, Joshua Root wrote: > > Ryan Schmidt wrote: >> On Nov 27, 2020, at 15:50, Kevin Horton wrote: >> >>> I'm apparently a slow learner, but once again I forgot to change my login >>> shell back to one supplied by Apple before migrating to Big Sur (I had been >>> using. >>> >>> Suggestion - add a step to the Migration docs, before the step that removes >>> all ports. If the user is using a default shell provided by Macports, do a >>> 'chsh -s /bin/bash' (or other Apple supplied shell) before removing all >>> ports. >> >> The wiki can be edited by anyone. > > I would go further and recommend never setting your login shell to > anything but the shells shipped with the OS. If you set it to a > MacPorts-provided shell, all it takes is one bug (or even ABI change) in > the shell port or one of its dependencies to seriously break your system > when you try to upgrade. > > You can configure Terminal to use a different shell without changing > your actual login shell, and that, along with having /opt/local/bin > early in your path, is usually all you need. Thanks for the excellent advice. Kevin
Migration doc suggestion - chsh
I'm apparently a slow learner, but once again I forgot to change my login shell back to one supplied by Apple before migrating to Big Sur (I had been using. Suggestion - add a step to the Migration docs, before the step that removes all ports. If the user is using a default shell provided by Macports, do a 'chsh -s /bin/bash' (or other Apple supplied shell) before removing all ports. Thanks for MacPorts. Kevin
Re: xephem seg faults on Mojave
On Oct 10, 2018, at 3:36 PM, Ryan Schmidt wrote: > > > > On Oct 10, 2018, at 09:55, Kevin Horton wrote: > >> on Mojave, with Xcode 10.0: >> >> $ xephem >> Warning: Fatal Error: >> _XmGetDefaultDisplay cannot be used prior to VendorS.Initialize, returns NULL >> [1]34379 segmentation fault xephem >> >> Any troubleshooting advice is appreciated. > > Sounds like a bug in the software. Have you reported it to the developer? > > The same version of Xephem ran fine on 10.13 when using the Fink packaging system, so I’m far from convinced it is a bug in Xephem.
xephem seg faults on Mojave
on Mojave, with Xcode 10.0: $ xephem Warning: Fatal Error: _XmGetDefaultDisplay cannot be used prior to VendorS.Initialize, returns NULL [1]34379 segmentation fault xephem Any troubleshooting advice is appreciated. Thanks, Kevin Horton
