Re: os upgrade
On 2024-09-28 at 21:13:52 UTC-0400 (Sat, 28 Sep 2024 21:13:52 -0400) Masha Vecherkovskaya is rumored to have said: Hi all. I’ve been putting off upgading from Mojave for as long as I could. But it seems inevitable at some near point. Which OS would you reccomend? Sonoma has gotten pretty solid. I would not go to Sequoia yet, given how many people are reporting problems. -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo@toad.social and many *@billmail.scconsult.com addresses) Not Currently Available For Hire
Re: building seamonkey - python setup - imp module
On 2024-09-10 at 16:02:06 UTC-0400 (Tue, 10 Sep 2024 22:02:06 +0200) Riccardo Mottola via macports-users is rumored to have said: > I understand it is not finding module “imp”. I wonder if my python 3.12 > misses some module to isntall? any python expert here? I am NOT a python expert. I could not write "Hello World" in python without cribbing... But this was easy to find: https://docs.python.org/3.11/library/imp.html and it seems to indicate that you should backrev your Python to 3.11 at most. -- Bill Cole
Re: Doubly Active PHP
On 2024-09-09 at 10:20:32 UTC-0400 (Mon, 9 Sep 2024 16:20:32 +0200) Bernard via macports-users is rumored to have said: [...] How does the ‘port’ software decide on deactivation of the older version? Is it perhaps done on the basis of some usage algorithm? If you want actual deactivation, you need to do that manually. However, you very likely DO NOT want to deactivate anything. For versioned package families like php, it is fine to have both versions active. Anything from MacPorts using php will be installed for a specific version. You only need to use the php_select port for tools NOT managed by MacPorts, which expect to have a binary named "php". Why is it that php82-gd is installed but not php83-gd? Because some port has a dependency on php82-gd but apparently no port requires php83-gd. And the same with php82-mcrypt vs. php83-mycrypt, the same also with php82-openssl vs. php83-openssl, the same also with php82-zip vs. php83-zip? On the other hand, the reverse happens with the following: php83-apache2handler @8.3.11_0 (active) php83-curl @8.3.11_0 (active) php83-exif @8.3.11_0 (active) php83-iconv @8.3.11_0 (active) php83-imagick @3.7.0_1 (active) php83-pspell @8.3.11_0 (active) None of the corresponding php82 subports are installed. Why this asymmetry? You get to this state because different ports which you've installed specify their different PHP dependencies differently. It will not usually clean itself up. Even if you run 'port reclaim' you won't remove old versions that were installed when a different default version of pHP was selected as the default. Or is this haphazard installation of ports/subports not unusual? It is neither "haphazard" nor unusual. If you want to clean it up manually, you would need to determine whether anything is still depending on php82. To do that you can just look at the full recursive tree of dependents for that port: port rdependents php82 That will show a tree of dependent packages. If any of those packages is something that you know you want to keep, you can check its direct explicit dependencies (port deps portname) to see if it specifies php82 or just a php binary or library. If a specific versioned port is specified in the Portfile, the only way to update that sort of specific port dependency is for the maintainer of the port to validate an update to a newer version. If only a php binary is specified as a dependency, you can remove and reinstall that tree of dependencies to switch to the new version. It is possible to get into a state where you have a tree of php82 packages installed but no longer have any requested packages still depending on them. This can be fixed by running "port uninstall php82" and verifying that the list of ports that will be damaged by that removal does not include anything explicitly wanted. This should be handled by the first step of the "port reclaim" command (which you should run after every update) but sometimes a port gets marked as requested when it should not be, such as if you install a bunch of interdependent ports in one explicit long command line rather than having MacPorts work out the dependencies of a single wanted port. -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo@toad.social and many *@billmail.scconsult.com addresses) Not Currently Available For Hire
Re: 2.10.1 macports SQL error on 10.6
On 2024-09-06 at 22:25:07 UTC-0400 (Sat, 7 Sep 2024 12:25:07 +1000) Joshua Root is rumored to have said: [...] First install the macports.sqlext port. Then run this command (all one line): sqlite3 /opt/local/var/macports/registry/registry.db ".load /opt/local/lib/sqlite3/macports.sqlext" "PRAGMA integrity_check" On Sonoma 14.6.1: skinnyclam:~ root# sqlite3 /opt/local/var/macports/registry/registry.db ".load /opt/local/lib/sqlite3/macports.sqlext" "PRAGMA integrity_check" Error: unknown command or invalid arguments: "load". Enter ".help" for help This can be fixed by installing the sqlite3 port. The version of sqlite3 in the base OS is 3.43, that in the port is 3.46 -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo@toad.social and many *@billmail.scconsult.com addresses) Not Currently Available For Hire
Re: python3 alias or executable
On 2024-08-31 at 11:39:29 UTC-0400 (Sat, 31 Aug 2024 17:39:29 +0200) Nils Breunese is rumored to have said: Riccardo Mottola wrote: I have several python versions installed an dused as dependencies my macports itself. Fine. To build ArcticFox browser, I need python2 and on 10.9 this is no issue, I guess the system python is getting used. Now I want to try do build current SeaMonkey since no binary is provided anymore. Officially it fails, but I wanted to sniff around and maybe with some experts here we can update things. However: Lirr:seamonkey-2.53.18.2 multix$ ./mach build This mach command requires python3, which wasn't found on the system! I suppose this is business for python_select port, right? python_select lets you select the default Python installation to use in your terminal, but generally shouldn’t be necessary to build software that uses Python. It is useful (but maybe not essential, depending on the specific case) if your build demands Python v3.x with the name python3 on a platform where your only installation of anything named python3 is via MacPorts. A wisely designed build system would parameterize that so it could be set up to use whichever python3 one prefers, but not everything is so wisely designed. From what I've heard, the SeaMonkey codebase is not so much designed as it is organically grown. Specifically, the 'mach' build tool is a bespoke python3 package written for Mozilla codebases, which may or may not be adaptable to something other than whatever is in $PATH for python3. [...] SeaMonkey also seems to provide binary releases for macOS x64: https://www.seamonkey-project.org/releases/ In the more detailed documentation, they specify 10.11 or later. -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo@toad.social and many *@billmail.scconsult.com addresses) Not Currently Available For Hire
Re: Using port command to see installation method
On 2024-08-20 at 15:32:44 UTC-0400 (Tue, 20 Aug 2024 15:32:44 -0400) Nate Ijams via macports-users is rumored to have said: And I suppose one follow up, if that is the case: how are upgrades handled by MacPorts when someone has originally installed a package from source vs binary? Take this scenario: – Install package X from source; – Install package Y from binary; – Later, both packages are upgraded in the ports tree; and – I run `port upgrade outdated`. Will X be upgraded from source, and Y from binary, so long as I do not run the command with `-s` or `b`? Or is the history ignored, and both will be upgraded by default from binary? Or is there a different behavior? There is no coherent history of actions maintained by MacPorts. The install/upgrade logs get cleaned up by default when everything goes right. It's more like the FreeBSD Ports system than it is like the major Linux package managers. By default 'port upgrade' tries to use pre-built binaries. Note that there are never pre-built binaries available for non-standard variants, so if you've built from source with a variant, it will always be upgraded from source. -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo@toad.social and many *@billmail.scconsult.com addresses) Not Currently Available For Hire
Re: Strange warning/file when doing a selfupdate
On 2024-08-12 at 08:14:54 UTC-0400 (Mon, 12 Aug 2024 14:14:54 +0200) Bas Jansen via macports-users is rumored to have said: Hi, When doing a self update via Terminal, I get the following warning: ~$ sudo port upgrade outdated Nothing to upgrade. ---> Scanning binaries for linking errors Warning: Error parsing file /opt/local/bin/g[: Error opening or reading file ---> No broken files found. ---> No broken ports found. Emphasis mine, of course. There is no file “g[“ in /opt/local/bin/. I ran this using macports 2.10.0, macOS Sonoma 14.6.1 on an Intel MacBook Pro, late 2019. Anyone know what this means? If you've installed the coreutils package, /opt/local/bin/g[ *should* exist. It is the GNU version of '[' which is better known as 'test'. You may be able to resolve this by reinstalling coreutils. I do not know the history of why '[' exists apart from 'test' but it does, in most systems as a hardlink. The MacPorts coreutils package includes both as distinct files. -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo@toad.social and many *@billmail.scconsult.com addresses) Not Currently Available For Hire
Re: resizing window when using "bc" in interactive mode
On 2024-08-11 at 18:34:30 UTC-0400 (Sun, 11 Aug 2024 18:34:30 -0400) Richard L. Hamilton is rumored to have said: Semi-understandable. The default system action for SIGWINCH is to do nothing; i.e. only programs that catch it are even aware of it. That would usually be programs like text editors that do full-window text handling, and probably need to re-fetch the current size and redraw on window size change. Right. It is clearly a bug. Makes me wonder if they're using libncurses or something like it, but not using it properly. The Apple build uses libedit. If I build the current version source with or without --enable-editline, I cannot reproduce the bug. Looks like an Apple-specific problem. From sigaction(2) on Monterey, the signals that do nothing by default (although in the case of SIGCHLD at least, ignoring it is a bit different from the default): SIGURG discard signal urgent condition present on socket SIGCONT discard signal continue after stop SIGCHLD discard signal child status has changed SIGIO discard signal I/O is possible on a descriptor SIGWINCHdiscard signal Window size change SIGINFO discard signal status request from keyboard Right, but anything that does interactive command line editing like bc needs to handle SIGWINCH. I'm not seeing the problem on Ventura, which uses the Gavin Howard bc (if perhaps not the same version as on Sonoma, which I don't have). Firmly setting the bug in Apple's lap. On Aug 11, 2024, at 10:37, Bill Cole wrote: On 2024-08-11 at 03:08:11 UTC-0400 (Sun, 11 Aug 2024 02:08:11 -0500) Ryan Carsten Schmidt <mailto:ryandes...@macports.org>> is rumored to have said: On Aug 11, 2024, at 00:03, Richard L. Hamilton wrote: The MacPorts version uses MacPorts supplied libraries (other than libSystem). The macOS version uses macOS supplied libraries. (ultimately from the same open source projects, but potentially different versions and build options, so not identical code) It's *not* the same software. MacPorts has GNU bc 1.07 which is licensed GPL-3. macOS used to have GNU bc 1.06 released back in 2000 under GPL-2. Apple has switched to someone else's bc implementation in recent macOS probably because as we know Apple is allergic to GPL-3. The macOS bc is Gavin Howard's version which is also used in FreeBSD. It integrates both the GNU additions to the POSIX-standard bc and its own additions, some of which came from the original BSD bc. There has been a steady trickle of bug fixes since the version Apple ships on Sonoma, some of which reference macOS. Looking at the man page, I'd bet that exiting when the terminal geometry changes is understandable, since making that change sends a WINCH signal and bc resets on signals for which it has no handler. That gap seems like a bug to me, but one to report to the author or Apple. b...@scconsult.com <mailto:b...@scconsult.com> or billc...@apache.org <mailto:billc...@apache.org> (AKA @grumpybozo@toad.social <mailto:grumpybozo@toad.social> and many *@billmail.scconsult.com addresses) Not Currently Available For Hire -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo@toad.social and many *@billmail.scconsult.com addresses) Not Currently Available For Hire
Re: resizing window when using "bc" in interactive mode
On 2024-08-11 at 03:08:11 UTC-0400 (Sun, 11 Aug 2024 02:08:11 -0500) Ryan Carsten Schmidt is rumored to have said: On Aug 11, 2024, at 00:03, Richard L. Hamilton wrote: The MacPorts version uses MacPorts supplied libraries (other than libSystem). The macOS version uses macOS supplied libraries. (ultimately from the same open source projects, but potentially different versions and build options, so not identical code) It's *not* the same software. MacPorts has GNU bc 1.07 which is licensed GPL-3. macOS used to have GNU bc 1.06 released back in 2000 under GPL-2. Apple has switched to someone else's bc implementation in recent macOS probably because as we know Apple is allergic to GPL-3. The macOS bc is Gavin Howard's version which is also used in FreeBSD. It integrates both the GNU additions to the POSIX-standard bc and its own additions, some of which came from the original BSD bc. There has been a steady trickle of bug fixes since the version Apple ships on Sonoma, some of which reference macOS. Looking at the man page, I'd bet that exiting when the terminal geometry changes is understandable, since making that change sends a WINCH signal and bc resets on signals for which it has no handler. That gap seems like a bug to me, but one to report to the author or Apple. -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo@toad.social and many *@billmail.scconsult.com addresses) Not Currently Available For Hire
Re: MacPorts 2.10.0-beta1 now available for testing
On 2024-07-22 at 16:18:31 UTC-0400 (Mon, 22 Jul 2024 16:18:31 -0400) Bill Cole is rumored to have said: On 2024-07-18 at 15:43:27 UTC-0400 (Fri, 19 Jul 2024 05:43:27 +1000) Joshua Root is rumored to have said: Source code and pkgs for MacPorts 2.10.0-beta1 are now available [1]. Testing of either of these install methods is helpful. DATA POINT: Installed from package on a 2018 MBP 13" with Sonoma, freshly updated from Monterey. No problems so far, running 'port -v migrate' and it is currently working on port 353 of 585. Surprisingly few issues, and I like the way this spat out at the end so I didn't need to read the whole scrollback: ---> Note: Migration finished with errors. The following ports could not be restored: - clang-12 Skipped becuase its dependency llvm-12 failed - colima Skipped becuase its dependency colima failed - llvm-13 Skipped becuase its dependency llvm-13 failed - lynx Skipped becuase its dependency lynx failed - macports-libcxx Skipped becuase its dependency llvm-11 failed - openssh Skipped becuase its dependency openssh failed - podofo Skipped becuase its dependency podofo failed The following ports were restored with changes: - openjdk17-zulu state changed from 'installed' to 'inactive' - openjdk21-temurin state changed from 'installed' to 'inactive' (I'm surprised the misspelling made it to a beta...) I haven't dug into solving any of those yet, but some appear to clearly be dependency determination problems. -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo@toad.social and many *@billmail.scconsult.com addresses) Not Currently Available For Hire
Re: MacPorts 2.10.0-beta1 now available for testing
On 2024-07-18 at 15:43:27 UTC-0400 (Fri, 19 Jul 2024 05:43:27 +1000) Joshua Root is rumored to have said: Source code and pkgs for MacPorts 2.10.0-beta1 are now available [1]. Testing of either of these install methods is helpful. DATA POINT: Installed from package on a 2018 MBP 13" with Sonoma, freshly updated from Monterey. No problems so far, running 'port -v migrate' and it is currently working on port 353 of 585. -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo@toad.social and many *@billmail.scconsult.com addresses) Not Currently Available For Hire
Re: Time to delete old PostgreSQL from MacPorts?
On 2024-07-12 at 16:54:18 UTC-0400 (Fri, 12 Jul 2024 16:54:18 -0400) David Gilman is rumored to have said: > Is there any opposition to dropping all unsupported PostgreSQL > versions from MacPorts? That would be any version of PostgreSQL before > 12. Version 12 runs out of support later this year. > > Right now none of the unsupported versions will build in MacPorts > without backporting patches[0]. That sounds like a solid argument for removing the old versions. -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo@toad.social and many *@billmail.scconsult.com addresses) Not Currently Available For Hire
Re: How to report an error?
On 2024-05-29 at 05:27:14 UTC-0400 (Wed, 29 May 2024 12:27:14 +0300) Henrik Mannerström is rumored to have said: Sorry for this newbie question. I have installed proj9 with port install proj9, yet pkg-config --exists proj does not find it. The relevant file is present in /opt/local/lib/proj9/lib/pkgconfig/proj.pc but there is no link in /opt/local/lib/pkgconfig. Should there be a link? Why does not pkg-config find it? I think this is an error. Is the correct way to proceed to open a ticket for the proj9 port? Yes. I think the solution is likely to be removing some of the 6(!) different versions of the package currently in MacPorts and creation of proj_select to handle the link. All of the versioned proj* ports have the same maintainer but the unversioned one (which is v5.2.0) has none. That is odd, and I don't understand how that happens... -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo@toad.social and many *@billmail.scconsult.com addresses) Not Currently Available For Hire
Re: Preventing other software from linking against MacPorts libraries
On 2024-05-09 at 02:03:15 UTC-0400 (Thu, 9 May 2024 00:03:15 -0600) Smith via macports-users is rumored to have said: Hello, I occasionally run into a problem where I'm building software from a tarball or a git clone outside of MacPorts, and the build process somehow ends up linking or trying to link against libraries in the MacPorts space (/opt/local). How can I prevent this from happening? Sometimes I just end up deleting /opt/local to get it to build and then re-install MacPorts, which can be painful or at least tiresome. I have to assume there is a better way or that I'm doing something wrong? Thanks in advance for any thoughts, When building software outside of MacPorts, you should cleanse your environment of any clues that /opt/local/ is a place to look for software. Remove /opt/local/bin and /opt/local/sbin from your PATH when running any 'configure' script (or other GNU auto* tools) that looks for tools and libraries. Any software that is meant to be multiplatform should have some mechanism for explicitly setting where to find libraries, such as options to an autoconf-based configure script. You can use those or (less ideal) just manually obliterate any hints of /opt/local in the Makefiles created by the configure script. -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo@toad.social and many *@billmail.scconsult.com addresses) Not Currently Available For Hire
Re: bash prints errors for every non-existing command
On 2024-04-24 at 12:33:23 UTC-0400 (Wed, 24 Apr 2024 18:33:23 +0200) Baerenblau via macports-users is rumored to have said: > Hi, > > I'm on macOS 14.4.1 (23E224) and continue to experience a long standing > problem with bash from Macports How long-standing? Just on Sonoma? > % which bash > /opt/local/bin/bash > > % bash --version > GNU bash, Version 5.2.26(1)-release (x86_64-apple-darwin23.2.0) Maybe rebuild this from source on the local machine? 14.4.1 is darwin 23.4.0, which *might* cause issues, although it should not, in principle. If you are not on an Apple Silicon Mac, you should definitely reinstall bash because you want your shell to be native code. > For every command which is not found a error similar error like this is > printed: > > $ asdf > objc[1321]: +[__SwiftNativeNSStringBase initialize] may have been in progress > in another thread when fork() was called. > objc[1321]: +[__SwiftNativeNSStringBase initialize] may have been in progress > in another thread when fork() was called. We cannot safely call it or ignore > it in the fork() child process. Crashing instead. Set a breakpoint on > objc_initializeAfterForkError to debug. > Abort trap: 6 > > Xcode has been installed today. Then MacPorts has been updated to the latest > version, machine is rebooted, issue continues to exist. Just as another data point: I have never seen anything like this despite running bash built using MacPorts for many years. The error message is not of a sort that I would expect to come out of bash itself, which I expect knows nothing of the Swift and objc runtimes. Also, you *should* be getting an error like this: $ dsfsfs bash: dsfsfs: command not found Guessing based on those observations, I suspect that you may have something in your bash environment that is causing this only when an executable file is not found in your $PATH because the process of searching for it and launching it hit an abort trap without indicating to bash that the command does not exist. I would start troubleshooting this by minimizing your $PATH (to something like '/opt/local/bin:/opt/local/sbin:/bin:/sbin:/usr/bin:/usr/sbin') and removing or setting to defaults anything in bash's environment that could cause something to be done when you are given an interactive prompt or an error, i.e. $PROMPT_COMMAND, $PS1, $PS2, etc. Look in your .bash_profile, .bashrc, or .profile for anything being set or run that you don't understand. -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not Currently Available For Hire
Re: Latest Apache Segmentation Fault
On 2024-04-24 at 01:34:11 UTC-0400 (Wed, 24 Apr 2024 05:34:11 +) Horst Simon via macports-users is rumored to have said: Hi, I upgraded from MacPorts-2.8.1-13 to MacPorts-2.9.3-10.13 and did port update installed, this updated Apache 2.4.58 to Apache 2.4.59. After the upgrade one URL which connects to the Horde Web server fails with following error in the apache error log: [mpm_prefork:info] [pid 298] AH00162: server seems busy, (you may need to increase StartServers, or Min/MaxSpareServers), spawning 8 children, there are 2 idle, and 4 total children [core:notice] [pid 298] AH00052: child pid 715 exit signal Segmentation fault (11) [core:notice] [pid 298] AH00052: child pid 714 exit signal Segmentation fault (11) Other URL’s cacti and phpkyadmin are working fine. I am not specifically familiar with Horde, but this looks like a failure of whatever Horde uses to run, e.g. php-fpm or mod_php. A common reason for this specific sort of failure is if you have different versions of PHP present and the loader manages to select conflicting versions of libraries I still have MacPorts-2.8.1 on another machine and no updates and this one does not show any errors. Are there changes in the updated apache which could cause this issues or additional parameters need to be changed? Nothing in the Apache httpd 2.4.58->59 update itself is likely to cause trouble per se, but because it is a highly modular program with optional modules linking at run time, you can have mismatches between the core software and modules like mod_php. -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo@toad.social and many *@billmail.scconsult.com addresses) Not Currently Available For Hire
Re: what app on a Mac reads/views ppm files?
On 2024-04-16 at 22:44:22 UTC-0400 (Tue, 16 Apr 2024 19:44:22 -0700) Kenneth Wolcott is rumored to have said: > Hi; > > what app on a Mac reads/views ppm files? > > I've been looking at some code located on Rosetta Code that involves > ppm files... https://rosettacode.org/wiki/Bitmap/Read_a_PPM_file For a very long time, I've relied on GraphicConverter, which opens and saves a huge variety of formats including PPM, according to this page: https://www.lemkesoft.de/en/products/graphicconverter/key-features/import-and-export-formats I have not personally used it with PPMs, but it has given me usable conversions of many other formats. It's a decent general-use graphics editor as well. -- Bill Cole
Re: what MacPorts port would create a TAGS file (looks like a history helper, rlwrap?)
On 2024-04-12 at 02:05:16 UTC-0400 (Thu, 11 Apr 2024 23:05:16 -0700) Kenneth Wolcott is rumored to have said: > I'll look in the emacs manual. Must have been some key I > pressed by accident... This is what I've said every time I've touched emacs... -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not Currently Available For Hire
Re: build of rspamd and amavisd-new not working with High Sierra
On 2024-04-11 at 06:18:58 UTC-0400 (Thu, 11 Apr 2024 20:18:58 +1000) Horst Simon via macports-users is rumored to have said: I understand the wiki information, but at a loss on how to get the patch. Following the link Ryan put in the ticket and navigating the obfuscatory GitHub interface, I got to https://github.com/DCIT/perl-CryptX/pull/99/commits/9568b3e7ce17d9e3ace6ddbfb7df2d2e387aa91f which shows the patch graphically. If you are dedicated to actually using the 'patch' utility with a patchfile, there should be a way to get GitHub to provide that, but I don't see it. It is small enough (3 new lines and 2 changed across 2 header files and crypt.c) that you could make changes to the source by hand AFTER getting it downloaded, extracted, and patched by any pre-existing MacPorts patches, after which MacPorts won't notice your changes: port patch p5.34-cryptx You will then have a copy of the source tree under the port's work directory (`port work p5.34-cryptx`) where you can edit the files and them try 'port build p5.34-cryptx' again. On 11 Apr 2024, at 18:30, contextnerror wrote: You would take the changes from the pull request and follow https://trac.macports.org/wiki/howto/PatchLocal On Apr 11, 2024, at 1:15 AM, Horst Simon via macports-users wrote: Thanks Ryan for the response I prefer to get the p5-cryptx working. Is there a how to or instruction on how to build it using the patch Horst Simon On 11 Apr 2024, at 17:48, Ryan Schmidt wrote: On Apr 10, 2024, at 22:59, Horst Simon wrote: I tried to install amavisd-new on macOS High Sierra but fails in the install of the dependency p5.34-cryptx, after this I tried to change to rspamd, but rspamd too fails to build. I already created request ticket for p5.34cryptx. My question is is it possible to get at least on of these working on High Sierra and what is needed from me. The rspamd problem is https://trac.macports.org/ticket/63785. It currently cannot build for macOS 10.14 or earlier because it uses features from a newer version of C++ than those earlier macOS versions can normally accommodate. The p5-cryptx problem is https://trac.macports.org/ticket/68470. I added a comment there about some similar upstream bug reports and a proposed upstream patch. You could try that patch and see if it solves the problem. If so we can add it to the port. If it doesn't solve the problem then report the problem to the developers so they can develop a fix. -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo@toad.social and many *@billmail.scconsult.com addresses) Not Currently Available For Hire
Re: force rebuild a port
On 2024-03-06 at 14:19:59 UTC-0500 (Wed, 6 Mar 2024 20:19:59 +0100) Riccardo Mottola via macports-users is rumored to have said: Hi! suppose I want to rebuild a port, but it has no version update. 1) e.g. rev-upgrade shows it to be rebuild but "port outdated" doesn't show it. 2) Or I want to rebuild it with a different compiler. How can I do? "port upgrade X" will do nothing because X is not outdated. "port upgrade --force X" will upgrade all dependencies, which is a little too much... 1) in my case has issues because it wants to rebuild many packages and starts with one that breaks, so it never gets to the next one. I tried using "-p" but apparently it is not respected for "port -p rev-upgrade" and still dies. Try it stepwise. I believe that this will work to rebuild and install 'crankyport' and nothing else, provided that none of the dependencies are out of date. port fetch crankyport port build crankyport port uninstall crankyport port install crankyport But you need to understand that if a port has a dependency on another port, that dependency can only be met by the current version of that port. MacPorts has no mechanism to just use whatever version of a p[rt you happen to have installed. -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not Currently Available For Hire
Re: Patch for 'skey' package submitted
On 2024-02-04 at 20:53:36 UTC-0500 (Sun, 4 Feb 2024 20:53:36 -0500) Link Dupont via macports-users is rumored to have said: I think you linked to the wrong Trac ticket. The one you’re referring to is probably https://trac.macports.org/ticket/69280. You are absolutely correct. I copied from the wrong tab. Link On Feb 4, 2024, at 18:12, Bill Cole wrote: They 'skey' package is an implementation of the S/Key algorithm derived from OpenBSD code over 20 years ago. It has not been built by the buildbots for any system after darwin19 because all the modern compilers (including Apple Clang called as 'gcc') enforce the C99 ban on implicit declarations. There's a patch attached to the Trac ticket at https://trac.macports.org/ticket/69210 which adds the requisite #include statements. Sorry for no pull request, but history tells me that putting one together properly takes me (a non-user of git, usually) a solid 10x as long as it should and annoys at least one person (me) and maybe a few more (actual devs seeing my messed-up PR.) -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not Currently Available For Hire -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not Currently Available For Hire
Patch for 'skey' package submitted
They 'skey' package is an implementation of the S/Key algorithm derived from OpenBSD code over 20 years ago. It has not been built by the buildbots for any system after darwin19 because all the modern compilers (including Apple Clang called as 'gcc') enforce the C99 ban on implicit declarations. There's a patch attached to the Trac ticket at https://trac.macports.org/ticket/69210 which adds the requisite #include statements. Sorry for no pull request, but history tells me that putting one together properly takes me (a non-user of git, usually) a solid 10x as long as it should and annoys at least one person (me) and maybe a few more (actual devs seeing my messed-up PR.) -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not Currently Available For Hire
Re: Questions on postfix
On 2023-12-28 at 10:53:06 UTC-0500 (Thu, 28 Dec 2023 07:53:06 -0800) Ubence Quevedo (thatrat) is rumored to have said: Hi, I’ve installed postfix and have configured it similarly to how I have it configured on some Linux systems using this tutorial [https://www.tutorialspoint.com/configure-postfix-with-gmail-on-ubuntu], That's going to be deeply flawed on macOS. Ubuntu (as a Debian downstream) does major violence to the Postfix package and a tutorial won't map directly to macOS. and when I install and configure postfix in macOS [and make some slight changes because everything is in /opt/local/etc/postfix], mail is not sent. Sent by what means? On what version of macOS? What bothers me most is that I can’t find the log files for the macports version of postfix. It's hard to say where you'll find logs, since you haven't mentioned your macOS version. In an older version (10.x, basically,) you will get messages in /var/log/mail.log unless you've done something odd to /etc/syslog.conf and/or /etc/ASL.conf. The logging subsystem mostly worked like classical Unix/Linux syslog. In modern macOS, Apple wrecked logging worse than Linux did with systemd and its rate-limiting. Wietse addressed both platforms' problematic logging by creating a logging subsystem just for Postfix called postlogd. Use that. Like all of Postfix it is well-documented. Can someone point me in the right direction to where I can find them to see why my sending mail isn’t working? The most likely root cause if you are using the standard command line tools is that you're using the Apple tools that expect to talk to the standard system Postfix, with sendmail under /usr, the spool in /var, and config in /etc/postfix. To fix that, you will need to put /opt/local/bin and /opt/local/sbin ahead of the system directories in your PATH environment variable. -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not Currently Available For Hire
Re: Can't build "mpv"
On 2023-12-25 at 15:49:41 UTC-0500 (Tue, 26 Dec 2023 07:49:41 +1100 (EST)) Dave Horsfall is rumored to have said: On Sun, 24 Dec 2023, Ryan Schmidt wrote: That log doesn't seem to say much, other than that the real error may be in the file meson-log.txt. Aha; thanks. I couldn't see the wood for the trees... meson-log.txt: --- stderr --- env: python3: No such file or directory Hmmm... Looks like I lost python3 somehow; well, it's not urgent, so it can wait. FWIW: the MacPorts 'python3' is set by the 'port select' command (and requires python3_select.) -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not Currently Available For Hire
Re: Idiomatic process for handling needed external language modules for which there is no port
On 2023-12-15 at 23:57:47 UTC-0500 (Fri, 15 Dec 2023 20:57:47 -0800) Kenneth Wolcott is rumored to have said: Idiomatic process for handling needed external language modules for which there is no port Hi; I'm trying to understand how to logically handle external modules for a language under MacPorts. TL;DR: How do you do package management on MacPorts for languages which might need modules which MacPorts doesn't have? I have no general answer, but I have not had *substantial* problems with Perl for a small set of projects using your "Scenario A." CPAN installs into functionally correct places in a MacPorts Perl installation, and I don't recall anything from MacPorts that should even be called a warning. This problem exists for many languages supported by MacPorts; ie: Perl, Python, Raku, Julia, etc Scenario A: 1. Install Perl from MacPorts. 2. Need Perl module XYZ. 3. Perl module XYZ does not exist on MaqcPorts. 4. Install (using CPAN, CPANm, or manually) the XYX module locating it under the MacPorts port. 5. MacPorts complains about things installed under /opt/local that it didn't put there (makes sense). Scenario B: 1. Install Perl from MacPorts. 2. Perl script I want to use requires a more recent version of Perl than those found on MacPorts. 3. Install my own version of Perl (usually from source). 4. Need Perl module XYZ. 5. Install Perl module XYZ (trying to match it with my own install location, but frequently screw this up). 6. End up with weird path issues, Perl and/or module(s) all confused. Scenario C: 1. Install Perl from MacPorts. 2. Install Perl from perlbrew. 3. Run into problems with #3-6 from Scenario B. Scenario D: 1 Use a Docker container for Perl exclusively for these experiments that I'm trying to use Perl for (various math learning, etc); 2. Install Perl from source 3. Install all needed external Perl modules myself on the Docker container. Looks like I end up using Scenario D for Perl and Raku. Now considering this for Julia, Python, Rust, etc So one of my problems is that I do not have a foolproof method (understanding) of how to install modules (Perl, Raku, etc) so that the modules are not in conflict with multiple installations of the main language. Bottom-line question: How do you do package management on MacPorts for languages which might need modules which MacPorts doesn't have? Thanks, Ken Wolcott -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not Currently Available For Hire
Re: moar (better than less) conflicts with moarVM (needed for Raku)
On 2023-12-05 at 15:07:56 UTC-0500 (Tue, 5 Dec 2023 12:07:56 -0800) Kenneth Wolcott is rumored to have said: [...] ~: sudo port -v -s install moar ---> Computing dependencies for moar. Error: Can't install moar because conflicting ports are active: MoarVM Error: Follow https://guide.macports.org/#project.tickets if you believe there is a bug. Error: Processing of port moar failed On Tue, Dec 5, 2023 at 11:04 AM Austin Ziegler wrote: `sudo port install moar +pager` should work after an update. Those two command lines are not the same. The "+pager" invokes a variant that fixes the problem by modifying the name of the conflicting executable. -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not Currently Available For Hire
Re: Why all this GARBAGE WARE for one single app?
On 2023-11-25 at 22:37:18 UTC-0500 (Sat, 25 Nov 2023 19:37:18 -0800) Mark Dm is rumored to have said: I am trying to install gedit on mac , installed macports, then the xcode requirements rand the command to install gedit. Now about 209 minutes later I am still seeing GARBAGE like GstreamerXXX and GstreamerYYY still installing . THIS IS NUTS! I NEVER ASKED TO INSTALL GSTREAMER. I know there are dependencies but how can gstreamer be a dependency for a text editor? It is on EL-based Linux as well. 'dnf install gedit' on Alma9 comes back with a list of 170 packages including multiple gstreamer* packages. CentOS7 says it's got 108 dependencies. It's a GUI text editor. It requires a GUI. Complain to GNOME. WTF now it is installing something called "yelp" That's the help browser for the GNOME desktop. I have no idea how essential it is for gedit, but it's deemed a "runtime" dependency, implying that it may be possible to create a variant that does not include help files or require yelp... I remember now I tried MacPorts years ago and ended up having to reformat my Mac to get all the speed back after the couple of apps I installed. I regret trying it again and thing it is all a bunch of GARBAGE Is this juist a method by which you can install garbageware onto a mac for unsuspecting users? I invite you to look at what MacPorts actually does. It's mostly TCL code which is documented and its operations are logged to whatever degree you desire to read. If you deem the GNOME Desktop to be "garbageware" then I suggest that gedit is not the editor you really want. -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not Currently Available For Hire
Re: ruby-select problem - Sonoma
On 2023-10-19 at 18:47:01 UTC-0400 (Fri, 20 Oct 2023 11:47:01 +1300) Chris F is rumored to have said: On 20/10/23 11:17 am, Chris Jones wrote: On 19 Oct 2023, at 10:58 pm, Chris F wrote: I've just migrated to Sonoma 14.0 via a clean OS install plus Migration Assistant and I'm now reinstalling my ports one at a time. Port ruby31 installed without problems but ruby-select doesn't seem to work/be effective - after ruby-select ruby31 runs successfully, command "ruby" still starts the OS default ruby 2.6.10 I've checked /opt/local/bin/ruby and it points (correctly?) to ruby3.1. Any advice would be appreciated. Did you start a new terminal session after run port select for ruby ? Yes I did, Chris - I shut terminal down and restarted it a couple of times as well. Chris F Check the order of directories in your $PATH environment variable. If the sub-directories under /usr are listed before those under /opt/local, you will use the base install executables instead oF those installed by MacPorts. -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not Currently Available For Hire
Re: Unistalling gmic-gimp macport
On 2023-10-11 at 07:22:44 UTC-0400 (Wed, 11 Oct 2023 11:22:44 +) Michal Sidorczyk is rumored to have said: Hi, Very much thanks for very prompt answer. So, I did reinstall the macports to Sonoma version, and then I followed this instruction: https://guide.macports.org/chunked/installing.macports.uninstalling.html to remove macports completely. However, /opt/local still contains data (I assume it is all macports related) and it is 2.7GB big. Then something went wrong. Those instructions include totally removing /opt/local/ in section 2.4.3. Can I just remove it manually safely? If you want MacPorts and everything it ever installed totally gone, yes. Doing so is part of the uninstall instructions. Moreover, it seems the uninstall procedure is pretty far from cleaning everything. As you can see in section 2.4.3 of the guide, removal of /opt/local (along with a list of other possible locations where ports could have left pieces) is explicitly a part of the uninstall procedure. Why that failed to happen on your system is a mystery. As I said installation of gmic-gimp port alone took 10GB. Not even mentioning the other part of macports. Now, after removal of all the ports, only 3GB of disk space was released. Adding 2.7GB from /opt/local makes it 5-6GB the top. Are there any other macports’ leftovers I should remove manually? BR Michal From: Ryan Schmidt Date: Wednesday, 11 October 2023 at 10:49 To: Henning Hraban Ramm Cc: macports-users@lists.macports.org , basileu...@hotmail.com Subject: Re: Unistalling gmic-gimp macport On Oct 11, 2023, at 02:03, Henning Hraban Ramm wrote: Am 11.10.23 um 07:34 schrieb Michal Sidorczyk: I know there are some upgrade instructions, but I did not follow them, I admit. Having the problem with disk space I do not put even more overhead of it, without being certain that eventually I will get rid of this extra 10GB space. Can you help me with my problem to remove gmic-gimp from my drive? The error message you encountered can be overcome by installing MacPorts for macOS Sonoma. It should not need any more disk space than is already being used by MacPorts. Just remove the complete MacPorts installation (/opt/local), you can’t use it anyway on a different platform. Just removing /opt/local is not the correct way to uninstall MacPorts. The correct way is documented in the MacPorts Guide. -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not Currently Available For Hire
Re: perl --version is not at perl5.36 but at perl5.34 yet both are listed as active
On 2023-08-13 at 20:21:23 UTC-0400 (Sun, 13 Aug 2023 17:21:23 -0700) Kenneth Wolcott is rumored to have said: Hi; I'm confused about what Perl I have installed vi MacPorts and what is active and what I can use. The short simple answer is: BOTH. port installed | grep perl5 ack @3.6.0_0+perl5_34 ack @3.7.0_0+perl5_34 (active) docbook2X @0.8.8_11+perl5_34 (active) git @2.39.1_0+credential_osxkeychain+diff_highlight+doc+pcre+perl5_34 git @2.39.2_0+credential_osxkeychain+diff_highlight+doc+pcre+perl5_34 git @2.40.0_0+credential_osxkeychain+diff_highlight+doc+pcre+perl5_34 git @2.40.1_0+credential_osxkeychain+diff_highlight+doc+pcre+perl5_34 git @2.41.0_0+credential_osxkeychain+diff_highlight+doc+pcre+perl5_34 (active) icoutils @0.32.3_1+perl5_34 (active) net-snmp @5.9.1_1+perl5_34+ssl (active) ossp-uuid @1.6.2_13+perl5_34+universal ossp-uuid @1.6.2_13+perl5_34 (active) perl5 @5.34.1_0+perl5_34 (active) perl5.34 @5.34.1_0 (active) perl5.36 @5.36.0_0 perl5.36 @5.36.1_0 (active) po4a @0.66_0+perl5_34 (active) xmltoman @0.4_1+perl5_34 (active) which perl /opt/local/bin/perl perl --version | head -2 | tail -1 This is perl 5, version 34, subversion 1 (v5.34.1) built for darwin-thread-multi-2level Note the illuminating output of "ls -l /opt/local/bin/perl*" Which version is pointed to by the 'perl' symlink is determined by the variant of the perl5 port. It looks like many perl5-based utilities are not yet updated to perl5.36, yet I'd like to use perl5.36 when I'm writing a perl program. The layout of perl's components allows you to have multiple independent versions installed without interfering with each other. In theory. I apparently don't understand enough about how to use "port select" even after several readings. Yeah, I don't think the perl-select port works. -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not Currently Available For Hire
Re: p5-* perl module ports question
On 2023-06-20 at 03:11:46 UTC-0400 (Tue, 20 Jun 2023 17:11:46 +1000) raf via macports-users is rumored to have said: Hi. All of the p5-* perl module ports have: perl5.branches 5.28 5.30 5.32 5.34 Why is that? There's a perl5.36 port, and there are perl5.16-perl5.26 ports. I'm curious. I was expecting to see a branch for all available versions of perl5. Not all modules are compatible with all Perl versions. Not all ports are maintained diligently, so when a new version of Perl is a available, not all ports get updated immediately. Sometimes it's just a formality. For example, Mail::SpamAssassin v4.0.0 was released before Perl 5.36 and so none of us on the SA dev team tested it with 5.36. We do not claim that it works with 5.36, although we expect that it will. Some packagers are very picky about such things. Historically, Mojca has been the SME and the most heroic heavy-lifter in keeping MacPorts' Perl jungle usable. -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not Currently Available For Hire
Re: ports that are outdated but cannot be upgraded.
On 2023-03-29 at 07:49:28 UTC-0400 (Wed, 29 Mar 2023 12:49:28 +0100) Christopher Jones is rumored to have said: Hio, Your problem is precisely what it says at the end Error: Failed to configure libtorrent-rasterbar: boost176 must be installed with +python311. you will likely have it installed with a different python version selected, and port respects this as your ‘choice’. You need to uninstall boost176 and reinstall it with the new default variants. I agree 100%. Simple commands: port uninstall boost176 port install boost176 Beware: building Boost from source is painfully slow. -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not Currently Available For Hire
Re: ports that are outdated but cannot be upgraded.
On 2023-03-28 at 15:03:48 UTC-0400 (Tue, 28 Mar 2023 12:03:48 -0700) Kenneth Wolcott is rumored to have said: HI; I ran a selfupdate successfully today. Then "sudo port -v -s upgrade outdated" seemed successful. But then: ---> Scanning binaries for linking errors Could not open /opt/local/libexec/boost/1.76/lib/libboost_python311-mt.dylib: Error opening or reading file (referenced from /opt/local/Library/Frameworks/Python.framework/Versions/3.11/lib/python3.11/site-packages/libtorrent.cpython-311-darwin.so) ---> Found 1 broken file, matching files to ports ---> Found 1 broken port, determining rebuild order You can always run 'port rev-upgrade' again to fix errors. The following ports will be rebuilt: libtorrent-rasterbar @2.0.8+python311 Continue? [Y/n]: n ~: port diagnose [nothing returned] port outdated No installed ports are outdated. So, this still seems less than ideal. It seems to me that the right answer to rev-upgrade's "Continue?" prompt should always be "y" but I could be wrong. -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not Currently Available For Hire
Re: ports that are outdated but cannot be upgraded.
On 2023-03-27 at 17:54:53 UTC-0400 (Mon, 27 Mar 2023 14:54:53 -0700) Kenneth Wolcott is rumored to have said: Weird. Getting ready to create a ticket for not being able to be upgraded. Now I see it does not show up on the outdated list. Well, the "replaced" ports are still in the outdated list. Guess I'll just ignore that. What happens if you use 'port upgrade' instead of 'port install'? On Mon, Mar 27, 2023 at 2:45 PM Kenneth Wolcott wrote: Just successfully completed a selfupdate and the re-install of: port -n upgrade --enforce-variants openssl3 +universal Now what remains is what follows: port outdated The following installed ports are outdated: libtorrent-rasterbar 2.0.8_0 < 2.0.8_1 py39-pep5170.13.0_0 < 0.13.0_1 py310-pep517 0.13.0_0 < 0.13.0_1 py311-pep517 0.13.0_0 < 0.13.0_1 So: sudo port install libtorrent-rasterbar Password: ---> Computing dependencies for libtorrent-rasterbar ---> Fetching archive for libtorrent-rasterbar ---> Attempting to fetch libtorrent-rasterbar-2.0.8_1+python311.darwin_22.arm64.tbz2 from https://packages.macports.org/libtorrent-rasterbar ---> Attempting to fetch libtorrent-rasterbar-2.0.8_1+python311.darwin_22.arm64.tbz2.rmd160 from https://packages.macports.org/libtorrent-rasterbar ---> Installing libtorrent-rasterbar @2.0.8_1+python311 Warning: boost176 must be installed with +python311. I know that this will fail (tried it before), but to document the failure, here goes: Continue? [Y/n]: y ---> Computing dependencies for libtorrent-rasterbar ---> Cleaning libtorrent-rasterbar ---> Scanning binaries for linking errors ---> Found 1 broken file, matching files to ports ---> Found 1 broken port, determining rebuild order ---> Rebuilding in order libtorrent-rasterbar @2.0.8_1+python311 ---> Computing dependencies for libtorrent-rasterbar ---> Fetching distfiles for libtorrent-rasterbar ---> Verifying checksums for libtorrent-rasterbar ---> Extracting libtorrent-rasterbar ---> Applying patches to libtorrent-rasterbar ---> Configuring libtorrent-rasterbar Error: Failed to configure libtorrent-rasterbar: boost176 must be installed with +python311. Error: See /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_net_libtorrent-rasterbar/libtorrent-rasterbar/main.log for details. Error: rev-upgrade failed: Error rebuilding libtorrent-rasterbar Error: Follow https://guide.macports.org/#project.tickets if you believe there is a bug. So, I'll file a bug for this part. Now what about the other three ports? Why are these ports still on my outdated list if they have been replaced? sudo port -v -s install py39-pep517 py310-pep517 py311-pep517 py39-pep517 is replaced by py39-pyproject_hooks ---> Computing dependencies for py39-pyproject_hooks. ---> Cleaning py39-pyproject_hooks ---> Removing work directory for py39-pyproject_hooks py310-pep517 is replaced by py310-pyproject_hooks ---> Computing dependencies for py310-pyproject_hooks. ---> Cleaning py310-pyproject_hooks ---> Removing work directory for py310-pyproject_hooks py311-pep517 is replaced by py311-pyproject_hooks ---> Computing dependencies for py311-pyproject_hooks. ---> Cleaning py311-pyproject_hooks ---> Removing work directory for py311-pyproject_hooks ---> Scanning binaries for linking errors Could not open /opt/local/libexec/boost/1.76/lib/libboost_python311-mt.dylib: Error opening or reading file (referenced from /opt/local/Library/Frameworks/Python.framework/Versions/3.11/lib/python3.11/site-packages/libtorrent.cpython-311-darwin.so) ---> Found 1 broken file, matching files to ports ---> Found 1 broken port, determining rebuild order You can always run 'port rev-upgrade' again to fix errors. The following ports will be rebuilt: libtorrent-rasterbar @2.0.8+python311 Continue? [Y/n]: n Perhaps I should remove these ports? I'll try that. No, that's NOT a good idea :-( sudo port -v uninstall py39-pep517 py310-pep517 py311-pep517 Note: It is not recommended to uninstall/deactivate a port that has dependents as it breaks the dependents. The following ports will break: py39-build @0.9.0_0 Continue? [y/N]: n ---> Cleaning py39-pep517 ---> Removing work directory for py39-pep517 Note: It is not recommended to uninstall/deactivate a port that has dependents as it breaks the dependents. The following ports will break: py310-build @0.8.0_0 py310-build @0.9.0_0 Continue? [y/N]: n ---> Cleaning py310-pep517 ---> Removing work directory for py310-pep517 Note: It is not recommended to uninstall/deactivate a port that has dependents as it breaks the dependents. The following ports will break: py311-build @0.8.0_0 py311-build @0.9.0_0 Continue? [y/N]: n ---> C
Re: [mysterious owner of 'libc++.1.dylib']
On 2023-03-15 at 14:00:44 UTC-0400 (Wed, 15 Mar 2023 18:00:44 +) Maxim Abalenkov is rumored to have said: Dear all, I need help please. I’m compiling a C/C++ code base with clang++ compiler installed via MacPorts. When I look at the libraries my executable relies on I see: otool -L /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 1300.36.0) What macOS version? I'm guessing Ventura... That file doesn't exist on Big Sur (where there is a libc++.dylib elsewhere) but it does on El Cap, where it is (sensibly) part of the base OS. I suspect that the version there is an indicator of macOS 13. However, when I try to find out what package owns this library: sudo port provides "/usr/lib/libc++.1.dylib" /usr/lib/libc++.1.dylib does not exist. Yes. MacPorts doesn't install libraries into /usr/lib. That would be bad. Further inquiry with ‘pkgutil’ doesn’t shed more light either: pkgutil --file-info "/usr/lib/libc++.1.dylib" volume: / path: /usr/lib/libc++.1.dylib Interesting. On my El Cap machine pkgutil shows that com.apple.pkg.Essentials and multiple com.apple.pkg.update.10.11.* packages included a file with that path. Would you please tell me, who is the mysterious owner of the ‘libc++’? It is part of macOS itself. Specifically, it is the implementation of the standard C++ library developed by the LLVM project, which is used by the clang++ compiler. -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not Currently Available For Hire
Re: ruby
On 2023-03-11 at 13:05:54 UTC-0500 (Sat, 11 Mar 2023 13:05:54 -0500) is rumored to have said: Hi, I need a quick ruby primer, please. I'd like to install this, https://github.com/pedrozath/coltrane sudo gem install coltrane won't work because I'm on Mojave with an an ancient ruby and this requires ruby 2.7 or above. sudo port -vsN install ruby installs ruby18 by default sudo port -vsN install ruby27 sudo port select --set ruby ruby27 installs, but gem still complains. What does 'which ruby' say? How about 'sudo which ruby' ? How about 'sudo which gem' ? Make sure /opt/local/bin comes before /usr/bin in your $PATH. just guessing at this point: port -vsN install rb-rubygems reinstalls ruby18 >< Yes. The "ruby" port appears to be pegged at 1.8.7. Help, please. Worst case: The ruby?? ports each install their executable binaries in /opt/local/bin, so if for some reason reinstalling a recent ruby port and 'port select'ing it doesn't work, you can try: sudo /opt/local/bin/gem3.0 install coltrane Or whatever version of ruby you choose. -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not Currently Available For Hire
Re: Request Alda and ABC packages exist on homebrew but do not exist as ports
On 2023-02-15 at 16:40:00 UTC-0500 (Wed, 15 Feb 2023 13:40:00 -0800) Kenneth Wolcott is rumored to have said: Hi; I'd like to request that the software 'Alda' and 'ABC (notation) be added as ports. They both exist on homebrew. https://abcnotation.com/ It's not clear which of the dozens of programs linked from the 'software' page you are interested in. There's nothing there which makes me think that it is the website for any software, but rather it appears to be for the ABC standard. -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not Currently Available For Hire
Re: Co-existance of MacPorts and Brew?
On 2023-02-15 at 14:54:40 UTC-0500 (Wed, 15 Feb 2023 14:54:40 -0500) André-John Mas is rumored to have said: Hiya, What is the current status of co-existence of Brew and MacPorts on the same machine? Previously this was meant to be a problem. It remains problematic. The conflict is intrinsic, and cannot be solved completely without one of the projects adopting the policies and practices of the other in a fundamentally incompatible way. With that baseline understanding, you can use both never (if you are careful and lucky,) have a problem. I am asking this question, since I am finding more and more recipes pointing towards using Brew, instead of MacPorts. If you try to use both it will *mostly* work and you may never encounter a problem, but if you do run into a conflict, it could be very hard to find a solution. The underlying problem is that many open source packages have /usr/local hardcoded into their build, install, or load, such that even if they are made to live in and use the world under /opt/local (i.e. MacPorts) they may still look for shared libraries under /usr/local first. If you have a Brew world under /usr/local, there's a significant chance that if you build MacPorts packages from source, some configure script will pick stuff in /usr/local/ to use instead of the /opt/local components. That may work, until the next upgrade of the relevant packages on one side or the other. The latest one I ran into was Vagrant, which indicates how to use Brew to install, but nothing for MacPorts: https://developer.hashicorp.com/vagrant/downloads Also, there doesn't seem to a version of Vagrant in MacPorts. If there's a recipe for brew, it shouldn't be terribly hard to create a port for MacPorts. All it takes is someone willing and able to do the work of creating the portfile and porting patches as needed. -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not Currently Available For Hire
Re: what is the MacPorts equivalent of homebrew pinning; freezing an installed version?
On 2022-12-27 at 16:43:18 UTC-0500 (Tue, 27 Dec 2022 13:43:18 -0800) Kenneth Wolcott is rumored to have said: > Hi; > > what is the MacPorts equivalent of homebrew pinning; freezing an > installed version? There is none. Just don't upgrade. -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not Currently Available For Hire
Re: Finding dependents
On 2022-12-23 at 07:49:09 UTC-0500 (Fri, 23 Dec 2022 13:49:09 +0100)
Gerben Wierda via macports-users
is rumored to have said:
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?
# port rdeps postfix @3.7.2_0+dovecot_sasl+pcre+smtputf8+tls
The following ports are dependencies of postfix
@3.7.3_0+dovecot_sasl+pcre+smtputf8+tls:
pcre
bzip2
libedit
ncurses
zlib
xz
gettext
libiconv
gperf
libtextstyle
gettext-runtime
gettext-tools-libs
icu
openssl
openssl3
OR, if you want something that doesn't require you to know the variants:
# port rdeps `port -q installed postfix|cut -d'(' -f1`
The following ports are dependencies of postfix
@3.7.3_0+dovecot_sasl+pcre+smtputf8+tls:
pcre
bzip2
libedit
ncurses
zlib
xz
gettext
libiconv
gperf
libtextstyle
gettext-runtime
gettext-tools-libs
icu
openssl
openssl3
--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
Re: a2ps fails to install (compressed log attached)
On 2022-12-19 at 16:47:41 UTC-0500 (Mon, 19 Dec 2022 13:47:41 -0800) Kenneth Wolcott is rumored to have said: Hi Bill; Here is some more information: ls -ld /opt/local/bin/makeinfo lrwxr-xr-x 1 root admin 8 Dec 9 19:36 /opt/local/bin/makeinfo -> texi2any port list texinfo texinfo@7.0.1 textproc/texinfo ls -ld /opt/local/bin/texi2any -rwxr-xr-x 1 root admin 68708 Dec 9 19:36 /opt/local/bin/texi2any port contents texinfo | grep texi2any /opt/local/bin/texi2any /opt/local/share/info/texi2any_api.info /opt/local/share/info/texi2any_internals.info /opt/local/share/man/man1/texi2any.1.gz I've never created a MacPorts bug report before; guess it is time to learn how to do that :-) Looks like a simple fix. The Portfile for a2ps includes this definition: MAKEINFO=/usr/bin/makeinfo Which would explain why the build failed and why the config didn't bother looking for a working makeinfo. Thanks, Ken On Mon, Dec 19, 2022 at 1:28 PM Bill Cole wrote: On 2022-12-19 at 15:03:35 UTC-0500 (Mon, 19 Dec 2022 12:03:35 -0800) Kenneth Wolcott is rumored to have said: Hi; a2ps fails to install (compressed log attached). one item I noticed (several instances: :info:destroot /bin/sh: /usr/bin/makeinfo: No such file or directory Does this mean that there is a missing dependency? It looks like it's saying that the version of 'makeinfo' that has historically been included in macOS is not present. That seems like something Apple might have done in a recent version, as they have been removing GNU tools pretty aggressively. It was still there in Catalina (which is as far as I've ventured...) If it really is gone, you can get a version by installing the 'texinfo' port, but it won't be at that path and it won't be whatever version Apple last had in the base system. However, it might be noticed and used by the a2ps configure stage and if so, should work. I expect that the proper solution will be to add texinfo as a dependency. -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not Currently Available For Hire -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not Currently Available For Hire
Re: a2ps fails to install (compressed log attached)
On 2022-12-19 at 15:03:35 UTC-0500 (Mon, 19 Dec 2022 12:03:35 -0800) Kenneth Wolcott is rumored to have said: Hi; a2ps fails to install (compressed log attached). one item I noticed (several instances: :info:destroot /bin/sh: /usr/bin/makeinfo: No such file or directory Does this mean that there is a missing dependency? It looks like it's saying that the version of 'makeinfo' that has historically been included in macOS is not present. That seems like something Apple might have done in a recent version, as they have been removing GNU tools pretty aggressively. It was still there in Catalina (which is as far as I've ventured...) If it really is gone, you can get a version by installing the 'texinfo' port, but it won't be at that path and it won't be whatever version Apple last had in the base system. However, it might be noticed and used by the a2ps configure stage and if so, should work. I expect that the proper solution will be to add texinfo as a dependency. -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not Currently Available For Hire
WARNING: Validate your icu dependents.
This is NOT a request for assistance or advice, just a warning from a fellow user of an issue you MAY run into this week that you should be aware of... Recently the 'icu' port got updated and as a result, many dependents need updates after installing the new icu. Most ports will Just Work if you're installing prebuilt binaries or building everything from source. HOWEVER, if you (like me) have MacPorts worlds that support and/or are supported by installations of non-MacPorts packages (e.g. Perl modules lacking ports) you may find that you have weird failures after MacPorts upgrades because of some link problem deep in a call chain somewhere... If the failure involves non-mp pieces, rev-upgrade either won't catch it or won't fix it. I've run into a few of these in the past 3 days, and rather than doing careful analysis I'm currently just rebuilding a few things (e.g. Perl itself and all my non-mp modules) from source locally to clean it up. I needed to do the same with Postfix, but only because I use a bunch of variants. If you cannot afford to put in at least a few minutes of validation and maybe a few hours of rebuild, you may want to postpone your regularly scheduled sync/upgrade cycle until you can watch it more carefully. -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not Currently Available For Hire
Re: Ventura archives?
On 2022-12-01 at 11:10:31 UTC-0500 (Thu, 01 Dec 2022 11:10:31 -0500) Andy Hall is rumored to have said: I've noticed that since the Ventura update in October I've had to build all packages locally instead of downloading archives from packages.macports.org. The logs show that it's looking for darwin_22 versions of each package, but there are none available. Just curious, how long does it usually take for the new archives to become available? I looked around in the wiki and issue tracker, but I couldn't find any hints at how this usually works. My understanding from prior answers on this list to exactly this question is that there is no known date yet and the sticking point is someone contributing a suitable machine to the build farm. So, do not hold your breath waiting... -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not Currently Available For Hire
Re: Running open source 'unix' services via MacPorts on macOS is no longer feasible for me
whole class of malware behaviors that malware authors don't bother trying. But the 'old' way of doing things is less and less supported and certainly not a focus for Apple to keep operational (which is dumb because by not supporting they are flying blind for the kind of resource leak errors I seem to have encountered). So, install unbound, and after boot macOS will ask you 'do you want unbound to accept incoming connections?'. Yes, of course, but that setting doesn't stick. After every next reboot, the same happens. Run the same executable side by side on different ports, and ALF gets confused. So, not only is the old ACL/POSIX way of permissions no longer properly implemented, the new system is not friendly for your own compiled stuff. If you code for Macs outside of Apple's macOS commercial ecosystem and rely on cross-platform compatibility via the use of standard POSIX APIs, you will have trouble with any daemon-like software unless you make special accommodations for the extra security on macOS. The same is true of similar novelties on other platforms (SELinux, systemd, etc.) but Apple has done a very poor job of giving developers the tools and docs to Just Work. [...] Apple turns macOS into a purely consumer appliance, it seems. Yes. That is their good right, but they also starve attention to the old unixy-way of things, leading to weak (certainly not robust) implementations of the unix-side. And that might be the eventual death of MacPorts unless it goes full in on Apple's new security model, signing and all. I expect that much of MacPorts can continue to work just fine, because so many ports are NOT server packages of any sort. And for the time being, Apple's own suggestion to move to open source variants of the macOS Server stuff they abandoned, is not to be taken seriously as they also are not serious about the foundation those open source elements need. Absolutely correct. Apple is not serious about maintaining robust compatibility with the POSIX-compliant world in regards to anything that runs in the background without a UI and talks to the net. They do not want anyone doing that on their devices but them. Whatever they have said about replacing Server is disingenuous lip service. There's nothing for Apple to gain by maintaining the ability to run free software that is not wedded in any exclusive sense to their platform. -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not Currently Available For Hire
Re: Emacs.app does not run after upgrade to macOS 13.0.1
On 2022-11-10 at 12:56:27 UTC-0500 (Thu, 10 Nov 2022 18:56:27 +0100) Artemio González López via macports-users is rumored to have said: > After installing the 13.0.1 update on my M1 MacBook Pro I emacs.app crashes > on launch. Apparently, the problem is that it cannot find a library: > > Crashed Thread:0 > > Exception Type:EXC_CRASH (SIGABRT) > Exception Codes: 0x, 0x > > Termination Reason:Namespace DYLD, Code 1 Library missing > Library not loaded: /opt/local/lib/libicui18n.71.dylib > Referenced from: <45F9A0DF-B06D-34C8-946F-88FFA574E722> > /opt/local/lib/libxml2.2.dylib > Reason: tried: '/opt/local/lib/libicui18n.71.dylib' (no such file), > '/System/Volumes/Preboot/Cryptexes/OS/opt/local/lib/libicui18n.71.dylib' (no > such file), '/opt/local/lib/libicui18n.71.dylib' (no such file), > '/usr/local/lib/libicui18n.71.dylib' (no such file), > '/usr/lib/libicui18n.71.dylib' (no such file, not in dyld cache) > (terminated at launch; ignore backtrace) > > Does anybody know how to fix this? (I depend on Emacs.app for all my LaTeX > editing, so this is quite a problem for me). Did you follow the documented NECESSARY procedure for reinstalling MacPorts after an OS upgrade? -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not Currently Available For Hire
Re: Big Sur on M1 - bind9 named daemon don't run
On 2022-09-22 at 10:55:06 UTC-0400 (Thu, 22 Sep 2022 15:55:06 +0100) Mark Lucas is rumored to have said: Sorry to probably ask the obvious but what command do I use to start it manually? /opt/local/sbin/named -g -u named That will start named in the foreground of your terminal and force all logging to the terminal on the 'standard error' file descriptor, so you'll see anything named emits as an error. You can add a "-d #' option where '#' is a digit with higher numbers giving more detail. If running without that option does not give you anything helpful, start with '-d 1' and if you don't get anything, try 2 then 3 etc. If mem ory serves me, there's a level (4? 5?) where the volume of output precludes eyeball analysis. You should not need that. On 22 Sep 2022, at 15:27, Daniel J. Luke wrote: On Sep 22, 2022, at 8:56 AM, Mark Lucas wrote: I just updated to bind 9.18.7 (Intel mac mini - macOS 12.6 ) and despite checking the config was ok, which it was, bind refuses to start. Looking at the contents of /opt/local/var/named/ mysteriously most of the files were now listed as being owned by non existent user 511. e.g. -rw-r--r-- 1 511named - 3.2K 4 Aug 2021 named.root Tried uninstalling and reinstalling bind9 and changing /opt/local/var/named/ files owner to named but the problem remains. I think the permissions stuff is unrelated to the port - it only installs these files into /opt/local/var/named: % port contents bind9 | grep /opt/local/var/named /opt/local/var/named/db.127.0.0.dist /opt/local/var/named/db.cache.dist /opt/local/var/named/db.localhost.dist You can try to start named by hand with `-g` (and maybe add a -d # option) to try to get more information on why it's not starting for you. -- Daniel J. Luke -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not Currently Available For Hire
Re: Big Sur on M1 - bind9 named daemon don't run
On 2022-09-22 at 10:27:16 UTC-0400 (Thu, 22 Sep 2022 10:27:16 -0400) Daniel J. Luke is rumored to have said: On Sep 22, 2022, at 8:56 AM, Mark Lucas wrote: I just updated to bind 9.18.7 (Intel mac mini - macOS 12.6 ) and despite checking the config was ok, which it was, bind refuses to start. Looking at the contents of /opt/local/var/named/ mysteriously most of the files were now listed as being owned by non existent user 511. e.g. -rw-r--r-- 1 511named - 3.2K 4 Aug 2021 named.root Tried uninstalling and reinstalling bind9 and changing /opt/local/var/named/ files owner to named but the problem remains. named.root is the historical name of the root cache for BIND. Identical to what MacPorts installs as db.cache.dist. The directory /opt/local/var/named/ and everything in it should be owned by user and group 'named' It looks possible that you've somehow had the user 'named' deleted (and it formerly had id 511.) That would cause permission problems. I think the permissions stuff is unrelated to the port - it only installs these files into /opt/local/var/named: % port contents bind9 | grep /opt/local/var/named /opt/local/var/named/db.127.0.0.dist /opt/local/var/named/db.cache.dist /opt/local/var/named/db.localhost.dist You can try to start named by hand with `-g` (and maybe add a -d # option) to try to get more information on why it's not starting for you. -- Daniel J. Luke -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not Currently Available For Hire
Re: Unable to build XV
On 2022-09-18 at 21:33:32 UTC-0400 (Mon, 19 Sep 2022 11:33:32 +1000 (EST)) Dave Horsfall is rumored to have said: > And because XV is broken I can't continue with upgrading following ports You can get around that by explicitly excluding xv, e.g.: port -v upgrade active and not xv -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not Currently Available For Hire
Re: libgcc9 and other ports that will never build on my system
On 2022-09-12 at 15:02:47 UTC-0400 (Mon, 12 Sep 2022 15:02:47 -0400) is rumored to have said: Yes, you got it. How do I command MacPorts to upgrade all outdated ports "and not" this whatever troublesome port? Is there a way? If you just told me, you'll have to be less subtle. 3rd time's a charm maybe? Here's the command on a single line all by itself. enter all of it, hit return, and nothing more: sudo port upgrade outdated and not libgcc9 Really. I was not kidding. This syntax is documented in the port(1) man page. P.S. no need to CC me on anything sent to this list. -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not Currently Available For Hire
Re: libgcc9 and other ports that will never build on my system
On 2022-09-12 at 01:29:31 UTC-0400 (Mon, 12 Sep 2022 01:29:31 -0400) is rumored to have said: With Mojave on Macmini6,1 & XCode 11.3.1 I get this: port -vsN upgrade libgcc9 ---> Computing dependencies for libgcc9. ---> Fetching distfiles for libgcc9 Error: gcc9 9.5.0 is not supported on Darwin 18 i386 Why are you trying to to build it for i386, e.g. 32-bit? Is there some dependent that can't be built for x86_64? That's the proximal issue, but it is probably not addressable by simply re-installing without the universal variant. See below. Error: Failed to fetch libgcc9: incompatible macOS version Error: See /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_gcc9/libgcc9/main.log for details. Error: Follow https://guide.macports.org/#project.tickets if you believe there is a bug. - I saw a bug report was opened, but wasn't paying much attention. This was closed 2 months ago https://trac.macports.org/ticket/65415 Probably more relevant is this closed bug: https://trac.macports.org/ticket/65518 The bottom line there: GCC9 9.5.0 or greater won't work on 10.11 or later. Just will not. Upgrade to a later GCC, if you really need GCC. In a couple or few other bug reports I've opened, most fixed and closed in due course, which is how I have known things to operate for the better part of 2 decades. But occasionally, some tickets are closed without the defect being fixed, with something posted to the effect "you're not using the right version of XCode for your system, and we're not going to support it... " or similar, and I don't know what the heck they're talking about, because XCode 11 requires macOS 10.14 or later, and I don't know what other version of XCode I'm supposed to be using on Mojave. But there's a further port here, which is that some maintainers and bug fixing volunteers, those that usually fix and close bug reports, seem to want to close these tickets even though the problem still exists, as though there is a mean boss somewhere putting pressure on them to close tickets when, sometimes, the defect still exists, as though closing a ticket has some magical effect. This is just an uninformed opinion from mild exasperation. Because MacPorts is downstream of all ports, there are simply some problems that cannot be addressed by the MacPorts Project. Some problems can't be fixed because no one who could fix it (e.g. GCC upstream) considers it a problem or has a motivation to fix it. There is absolutely no benefit in leaving a downstream ticket open for an issue that can only be fixed upstream, but where upstream has decided not to fix it. So there's that. But the other thing is, I just don't care, if something isn't going to work, fine. But how do I get it to stop showing up in my outdated list so that I can just blanket-upgrade the outdated ports without the upgrade command failing when it reaches the problematic port? I'm sure it's in the manual somewhere, but I figured Ryan and a couple others seem to know the manual by heart and may have mercy on me and my bad eyes, and tell me how to stop a port from being reported it is outdated. MacPorts isn't designed to work around ports that have been pinned at an obsolete version. As long as you have libgcc9 installed via MacPorts on Mojave, it will show up as outdated and fail to upgrade. Options: 1. Just remove libgcc9. It is old enough that there's a real chance that every reason you ever had to install it no longer demands that version. 2. Run 'port rdependents libgcc9' to get a list of what must be updated to a modern GCC in order to work. Install a modern libgcc version and rebuild those, then see #1. 3. "sudo port upgrade outdated and not libgcc9" should work, but it will leave everything dependent on libgcc9 at older versions. -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not Currently Available For Hire
Re: x86_64 version of libncurses
On 2022-08-30 at 13:24:41 UTC-0400 (Tue, 30 Aug 2022 13:24:41 -0400) Murray Eisenberg is rumored to have said: Under macOS 12.5.1 on an M1 Mac, I'm trying to use the SageMath system (https://www.sagemath.org <https://www.sagemath.org/>) from the command-line in Terminal, and for that libncurses is required. Under MacPorts 2.7.2 I have: sudo port installed | grep ncurses ncurses @6.3_0 (active) If that was built with +universal, it would say so. And sudo port info ncurses says that it is universal and is for platforms darwin, freebsd. 'port info' tells you about the AVAILABLE port, not the INSTALLED port. 'port installed' tells you about what you actually have installed. -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not Currently Available For Hire
Re: What happens when a port fails to compile (+universal) and there is no maintainer?
On 2022-08-22 at 10:26:14 UTC-0400 (Mon, 22 Aug 2022 15:26:14 +0100) Philip Potter is rumored to have said: Hi, What happens when a port fails to compile (+universal) and there is no maintainer? The failure remains until someone with the right combination of skill and motivation fixes it. I see you opened a bug repoert at https://trac.macports.org/ticket/65671 so at least it is visible. ie jemalloc? <https://ports.macports.org/port/jemalloc/details/> The auto build build either an arm64 or an x86_64, so seems like no one would ever know if a +universal build fails. It's unclear to me why anyone would need a universal build for something so low-level. Looking *cursorily* at the errors in the log in your bug report, I suspect it may be due to the code not having support for a universal build. You may want to also open an upstream bug, if you can analyze it well enough to determine that upstream fixes are required. How or who resolves this kind of issue? Maybe you? Maybe the upstream developers of jemalloc? Maybe no one? MacPorts is run by volunteers and has a very open contribution environment. To the best of my knowledge, there has not been any meaningful corporate support for the project for many years, so no one is really accountable for whether any particular bug is ever fixed. Note that this is not meant as criticism of the MacPorts project in any way. It's the nature of FOSS: much of the work is done by people fixing their own issues and sharing the fixes. -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not Currently Available For Hire
Re: Is there a well-defined way to do "bleeding edge" ports? Should there be one?
On 2022-05-21 at 20:23:49 UTC-0400 (Sat, 21 May 2022 20:23:49 -0400) Andrew Udvare is rumored to have said: If it's off GitHub or GitLab you don't have to create the tarball unless it has submodules (you can also fetch multiple tarballs but this is complex). In this case (and for many ASF projects) the master version control is Subversion, so the only way I'm getting a tarball is making it client-side. I actually have a script to update my ports that are of 'latest version' tarballs. https://github.com/Tatsh/ports/blob/master/_resources/bin/liveupdate That could be useful, thanks. Unfortunately on MacPorts there's no PortGroup to use git or similar to fetch the latest code. I guess it's because it will almost certainly bring more tickets into the system Understood. I see this mostly as a developers tool, with explicit non-support. especially when said latest versions are important dependencies. On Gentoo we do have this feature (provided by eclasses, equivalent of PoetGroup) and you have to make configuration changes to use it when it comes to packages in the main tree. This makes the point that you're on your own when you start doing this to your system. You can write your own PortGroup to do this so the code can be shared among your ports, similar to Gentoo's way: https://gitweb.gentoo.org/repo/gentoo.git/plain/eclass/git-r3.eclass Basically, git clone if the clone isn't there already, update otherwise (replacing fetch phase). Don't forget submodules. Make the clone live somewhere permanent until the package is uninstalled. When installing, copy recursively the clone to the normal build directory (replacing the extract phase) then the rest of the system can work as is. Food for thought. Thanks. On Sat, May 21, 2022, 16:38 Bill Cole < macportsusers-20171...@billmail.scconsult.com> wrote: On 2022-05-21 at 15:24:23 UTC-0400 (Sat, 21 May 2022 15:24:23 -0400) Andrew Udvare is rumored to have said: Rather than pull via version control, Which is MY GOAL, not an incidental mechanical issue. grab a tarball with the SHA you want. Which would mean creating an ad hoc tarball before each (rapid) update. That's how I do 'latest' version ports. Well, that requires: 1. creating a tarball 2. calculating the hashes 3. editing the portfile Which is a lot of fiddling for each new version. My goal is to NOT do all that, but to get the same installation that I would get if I did. It is also to have a way that non-developer users can easily install the actual latest version of the moment, which is sometimes the easiest way to get fixes that don't merit a full release. -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not Currently Available For Hire -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not Currently Available For Hire
Re: Is there a well-defined way to do "bleeding edge" ports? Should there be one?
On 2022-05-21 at 15:24:23 UTC-0400 (Sat, 21 May 2022 15:24:23 -0400) Andrew Udvare is rumored to have said: > Rather than pull via version control, Which is MY GOAL, not an incidental mechanical issue. > grab a tarball with the SHA you want. Which would mean creating an ad hoc tarball before each (rapid) update. > That's how I do 'latest' version ports. Well, that requires: 1. creating a tarball 2. calculating the hashes 3. editing the portfile Which is a lot of fiddling for each new version. My goal is to NOT do all that, but to get the same installation that I would get if I did. It is also to have a way that non-developer users can easily install the actual latest version of the moment, which is sometimes the easiest way to get fixes that don't merit a full release. -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not Currently Available For Hire
Is there a well-defined way to do "bleeding edge" ports? Should there be one?
I'm currently working on a OSS project (SpamAssassin) which is in a pre-release rush and which I ultimately test & deploy via MacPorts. I'd *like* to be able to switch from the current supported release in MacPorts to a fresh build from a Subversion checkout without manually mimicking what MP does (in part because I'm not 100% confident that I am doing it right) so that I can do testing iteration in a more efficient and repeatable fashion. This would be a different level of 'reckless cowboy' beyond the '-devel' ports we already have here and there with prerelease software. I expect that this does not exist (I can't find anything...) but that it could. MP would need to always do a fetch/checkout/update/pull from the source control repo (I presume it would need BOTH svn and git support) and require use of a secure transport to make trusting the code without tarball checksums reasonable. Does anyone else like the idea of this? See a need? Hate it? Already have a private tool for this? -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not Currently Available For Hire
Re: Hello i'm new user on macports and i really don't know how to install all version of chrome
On 2022-05-03 at 12:14:20 UTC-0400 (Tue, 3 May 2022 19:14:20 +0300) Максим Овчаренко is rumored to have said: Can you wrote me instruction about port installation of all ports of chrome There is no port of Chrome (Google's web browser) in MacPorts. You can install Chrome from the Google web site. -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not Currently Available For Hire
Re: Somewhat off topic - keeping older Macs running
On 2022-04-25 at 03:06:25 UTC-0400 (Mon, 25 Apr 2022 15:06:25 +0800) James is rumored to have said: On 25 Apr 2022, at 1:44 pm, Dave Horsfall wrote: On Mon, 25 Apr 2022, James wrote: I too have old macs that cant be updated. I just keep a time machine backup and if ever I get hacked a quick restore will fix. For 10 years I've had no issues !! Your "old macs" are not protected by a firewall? One day... As for backups, consider malware that will not trigger until well and truly embedded into your backups; not much use then, are they? Dave methinks there is lots of hysteria in the arena Yes, but there is also a lot of nasty reality. I have no firewall on my modem and no firewall on any of my machines. Yet the world is full of stories about exploits! Most of those are windows exploits! Most but by no means all. A lot of modern attacks are multi-platform as they start as scripts on web pages that run in any browser, or as abuse of embeded execution mechanisms such as VBA in MS apps and embedded JavaScript in PDFs. Lets consider firewalls: By RFC no router on the internet may route a private IP. So *every* router between you and bad guys is broken! So, this glosses over a couple of things... 1. Enabling NAT in your router (which may also be a modem) is a *form* of a firewall. Without NAT, 'private' (RFC1918) IPs do in fact not route anywhere. With NAT, the world only sees your external non-private address(es) 2. If by chance there was massive external breakage allowing outsiders to route your private network, if your own router isn't badly broken, it will drop private IPs on the public interface anyway. So this is a pointless statement... A firewall allows ESTABLISHED,RELATED traffic back, so if you've got a bad machine then bad guys can get to that machine and from there to your macs. If you have a compromised machine then it is a target. Macs can be compromised. A decade ago one of the anti-virus companies offered $10 000 and a Sony Viao to first person to hack their honeypots. The windows honeypot was hacked in under an hour, the mac in a week (a flaw in safari) and the linux 'pot has never been hacked. They ascribed this to being unkewl to hack linux. Nonsense you'd be a hero for exposing a flaw (as has happened a couple of times.) Urban legend unless you actually identify a reliable source... I've been administering Internet-connected systems for 30 years, including Linux systems back to v0.99 and Macs back to System 7 with MacSLIP. I guarantee you that there is no such thing as an unhackable OS. I don't believe there has been a year since my first use of Linux where there has not been at least one publicly documented RCE vulnerability in core Linux components such as the kernel, core utilities, and Bash. I have not been unlucky enough to have had a machine on the Internet that I was responsible for get taken over, but I recognize that as a function of luck. I did get hit by a couple of Mac viruses back in the 80's and early 90's, but those all came via disk swapping and dialup BBSs. However, in my consulting and sysadmin work I've had to clean up a LOT of compromised boxes, including Mac, Linux, Solaris, Tru64, and BSDOS machines. And a few Windows machines, although I mostly avoid those. If you enjoy playing then by all means, if not then enjoy an icecream, except if you have windows machines on your network forget the icecream. I guess IPV6 will change the landscape somewhat. Not so much, except that some people will take their non-shortage of address space as an excuse to stop NATing at their borders, which would be unwise. The subtle comment about ring 0: linux and mac work in a way that is very limited, what disk?, whereas widows you are not allowed, here is $100, well ok. Query: heresay not allowed, who has ever had a mac hacked? Not my own, but I've cleaned up the mess when others have been careless, thinking they were safe because they had a Mac. Especially of note for older Macs in recent years is the "ShellShock" vulnerability in older Bash, which was directly exploitable via Apache HTTPD through (at least) Snow Leopard. I have seen that hit multiple people who were sure that they were safe because they were running old stable systems. On Macs with humans sitting in front of them, the problem is worse because humans do things like "Updating Flash" when told they need to do so, even when they don't have Flash installed and definitely don't need it. -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not Currently Available For Hire
Re: Somewhat off topic - keeping older Macs running
On 2022-04-25 at 03:06:25 UTC-0400 (Mon, 25 Apr 2022 15:06:25 +0800) James is rumored to have said: On 25 Apr 2022, at 1:44 pm, Dave Horsfall wrote: On Mon, 25 Apr 2022, James wrote: I too have old macs that cant be updated. I just keep a time machine backup and if ever I get hacked a quick restore will fix. For 10 years I've had no issues !! Your "old macs" are not protected by a firewall? One day... As for backups, consider malware that will not trigger until well and truly embedded into your backups; not much use then, are they? Dave methinks there is lots of hysteria in the arena Yes, but there is also a lot of nasty reality. I have no firewall on my modem and no firewall on any of my machines. Yet the world is full of stories about exploits! Most of those are windows exploits! Most but by no means all. A lot of modern attacks are multi-platform as they start as scripts on web pages that run in any browser, or as abuse of embeded execution mechanisms such as VBA in MS apps and embedded JavaScript in PDFs. Lets consider firewalls: By RFC no router on the internet may route a private IP. So *every* router between you and bad guys is broken! So, this glosses over a couple of things... 1. Enabling NAT in your router (which may also be a modem) is a *form* of a firewall. Without NAT, 'private' (RFC1918) IPs do in fact not route anywhere 2. A firewall allows ESTABLISHED,RELATED traffic back, so if you've got a bad machine then bad guys can get to that machine and from there to your macs. If you have a compromised machine then it is a target. A decade ago one of the anti-virus companies offered $10 000 and a Sony Viao to first person to hack their honeypots. The windows honeypot was hacked in under an hour, the mac in a week (a flaw in safari) and the linux 'pot has never been hacked. They ascribed this to being unkewl to hack linux. Nonsense you'd be a hero for exposing a flaw (as has happened a couple of times.) If you enjoy playing then by all means, if not then enjoy an icecream, except if you have windows machines on your network forget the icecream. I guess IPV6 will change the landscape somewhat. The subtle comment about ring 0: linux and mac work in a way that is very limited, what disk?, whereas widows you are not allowed, here is $100, well ok. Query: heresay not allowed, who has ever had a mac hacked? James -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not Currently Available For Hire
Re: Corrupted ports.tar file?
On 2022-04-13 at 00:34:02 UTC-0400 (Tue, 12 Apr 2022 23:34:02 -0500) Ryan Schmidt is rumored to have said: > On Apr 11, 2022, at 17:02, Dave Horsfall wrote: > >> 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). > > I think you did mention it. I was suggesting you run it again, in case > somehow the server files were in a weird state the last time you selfupdated. > There was some intermittent network problem affecting the server that > generates the ports.tar file a few days ago, and again today; although I > thought our rsync updates happened pretty much atomically, maybe it was > possible for a set of files to be published briefly that was not correct. I just now (0600 UTC 2022-04-13) had a similar experience. Ran a selfupdate which suggested I do a reclaim at the end. I said 'y' and it did the leaf trim and the inactive purge, but while "Building list of distfiles still in use" it kicked out a lot of errors about a corrupted PortIndex as Dave reported. I also got a handful of messages like these, interspersed with the others: Warning: Failed to open port libpaper : can't read "portinfo(porturl)": no such element in array Warning: Failed to open port p5.28-http-message : can't read "portinfo(porturl)": no such element in array Running 'port info' for the supposedly "not found" ports gave the normal output. Running 'port reclaim' again (without another update) did NOT trigger the flood of errors. Theory: it's a problem related to running the reclaim from the prompt at the tail end of a selfupdate. Incomplete 'portindex' run perhaps? -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not Currently Available For Hire
Re: Python
On 2022-03-17 at 17:22:51 UTC-0400 (Thu, 17 Mar 2022 22:22:51 +0100) Tom is rumored to have said: Hello people, how do I install a python replacement for macOS 12.3? port install python310 python_select [come back in 20 minutes] port select python python310 If you need an older version, there are ports for them. Unlike Ryan, I urge you to NOT install a 2.x version unless you are absolutely sure that you need such an antique, unsupported, encoding-impaired tool. -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not Currently Available For Hire
Re: Hybrid CDs on Big Sur
On 2022-03-08 at 18:49:50 UTC-0500 (Tue, 8 Mar 2022 15:49:50 -0800) Sriranga Veeraraghavan is rumored to have said: Hi, I have some older CDs that appear to be master with a Mac (HFS/HFS+) partition and a Windows (FAT32?) partition. Under BigSur (on M1), Finder and DiskUtility only seem to want to mount the Mac partition on these CDs and don’t seem to provide a way to access the Windows partition. I’ve been able to access the Windows partition by running on Linux running under an emulator, but this is somewhat clunky. Does anyone know of a way (perhaps through a port in macports) to mount the Windows partition on a hybrid CD? Have you tried using the diskutil command-line tool? -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not Currently Available For Hire
Re: Running a mail server via MacPorts on macOS Monterey
On 2022-03-03 at 08:38:47 UTC-0500 (Thu, 3 Mar 2022 14:38:47 +0100) Gerben Wierda via macports-users is rumored to have said: Apart from Steven Smith, are there other users here that run a mail server setup via MacPorts? And is already someone else running on Monterey? I have run a personal/family mail/web/dns server whose componentry* is almost all built by MacPorts since ~2006. Current platform is El Capitan, because Apple has made macOS increasingly hostile to server use. When running ElCap becomes too much of a hassle (or when that machine dies,) I expect that I will finally move its functionality to a FreeBSD machine. Catalina and later simply are not fit for server duty. The deliberate breaking of standard logging, broad locking of the system, and breakage in the legacy implementation of 'cron' make it clear that Apple doesn't want people fiddling around with their Macs "under the hood" or using them as unattended utility machines. (*) Apache HTTPD, Postfix, Dovecot, BIND, SpamAssassin, and a bunch of tools that I use for administrative/research work on that machine. Also MIMEDefang, which is hand-built because it's got some (originally intentional and explicit) Mac-hostility and there's no port. Yet. -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not Currently Available For Hire
Re: Which port provides protoc?
On 2022-02-07 at 13:16:54 UTC-0500 (Mon, 7 Feb 2022 10:16:54 -0800) Watson Ladd is rumored to have said: > On Mon, Feb 7, 2022 at 9:59 AM Marius Schamschula > wrote: >> >> Watson, >> >> Compiler? > > protoc: the thing that takes the definition and outputs the code. > Apparently something I tried installed it, but I'm now not sure what. # port provides `which protoc` /opt/local/bin/protoc is provided by: protobuf3-cpp -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not Currently Available For Hire
Re: XV/GIMP/etc: Can't open display
On 2022-01-28 at 16:34:29 UTC-0500 (Sat, 29 Jan 2022 08:34:29 +1100 (EST)) Dave Horsfall is rumored to have said: MacBook Pro (13-inch, Mid 2010), saddled with High Sierra 10.13.6 (as far as it will go). Back when I was running Sierra these tools worked just fine; after upgrading to HS (and rebuilding MacPorts that took almost a day) things went pear-shaped: mackie:~ dave$ xv xv: Can't open display mackie:~ dave$ gimp Cannot open display: mackie:~ dave$ echo $DISPLAY mackie:~ dave$ Is this something I forgot to do during the upgrade? Did you reinstall the X server? I believe that you need to. Specifically the xorg-server and xinit ports. I set $DISPLAY to ":0" (an old Unix trick) to no effect, so I guess it's using a named pipe instead but I cannot find it; poking around doesn't seem to uncover anything applicable to this, and I certainly won't trust any "advice" on StackOverflow. Properly installed, it Just Works. At least after a logout/login cycle. If it is correct, you will have a DISPLAY of the form: /private/tmp/com.apple.launchd./org.macports:0 To get that, you need the xinit port. -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not Currently Available For Hire
Re: Sms for text messages in macports
On 2022-01-17 at 16:58:06 UTC-0500 (Tue, 18 Jan 2022 08:58:06 +1100 (EST)) Dave Horsfall is rumored to have said: On Mon, 17 Jan 2022, Richard L. Hamilton wrote: Every cell phone provider, or at least just about every US cell phone provider, has an email to SMS gateway. It's free for someone sending email to it, not necessarily for the recipient. The problem is you have to know the provider for a given number, and AFAIK, there's no particularly easy way to do that automatically and scriptably (so you can generate an email address for the correct gateway). MMS gateways also exist, although the acceptable MIME types and size/complexity limits for attachments may be tedious to discover. I've seen a reference to his before; the receiver pays to receive mobile calls in the USA? That has not been the case for most people for many years. Way back (~2k) some service providers tried to put tolls on SMS and it is still legal, but I don't think any major provider still charges to receive text messages. In Australia it's the sender who pays (of course). Most US providers have stopped charging at all for SMS for most customers. And I believe that mobile phones (what you call cellular phones) don't have their own prefix? Right. It's all country code 1 and the "NANP" system of area codes and local exchanges (leading 3 digits of 7.) Many mobile numbers are in exchanges first allocated to mobile providers, e.g. my number and all others in my area code with the same exchange prefix were first assigned to Sprint customers, but after 20y of churn via number portability has broken that pattern. It also is somewhat true that area codes (which no longer are geographically exclusive) which have the 'traditional' 0 or 1 as the 2nd digit have the bulk of "landlines" and the newest area codes that overlay multiple legacy area codes mostly have mobiles, but that's just timing. We reserve "04" for that; at one time you could even tell which provider it was, but now you get to keep your number when you change providers. We never did that in the US because of the random walk under corporate influence of our telecom & antitrust policy of the past 5 decades. I'd bet that if AT&T had been allowed into mobile service pre-breakup, we'd probably have a special prefix or segregated area codes for mobile numbers. But to bring this back on topic... Alternatives: a service (some free for small volumes only) that can send SMS from a computer. Or Asterisk plus extensions, to set yourself up a full VoIP PBX...except that will need some paid service too, to connect to. But it will do a lot more than just send (or receive) SMS, it could forward phone calls, with proper hardware interfaces drive either old fashioned or VoiP phones, etc. It looks like a lot of work and learning as well as expense, though, and really ought to have a dedicated server, too, although that's not absolutely necessary. We had that in a previous $JOB; if Nagios (a general system monitor) detected something that triggered a rule then a set of users would receive a brief SMS, sent from a GSM modem. I looked at this for my own LAN, but it ain't cheap... One can do similar in the US: get a number from a mobile provider and put a SMS-capable CDMA or GSM modem on it. I've seen this done in multiple places, but all with bespoke custom drivers so I don't have any suggestions for the OP... -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not Currently Available For Hire
Re: Mojave and Macports
On 2022-01-13 at 16:26:01 UTC-0500 (Thu, 13 Jan 2022 15:26:01 -0600) Will Senn is rumored to have said: [...] My question for y'all goes like this - How long will macports continue to "work" on Mojave? No one can actually give a fixed date for that which you could reasonably rely upon. MacPorts still has support for Tiger. That's 10 releases older than Mojave. It is unlikely that the aggregate 'vision' of the people doing the work of keeping MP going will change so much as to drop Mojave before it is simply impossible to continue to support it. If I recall correctly, dropping Panther only happened because the last Panther-capable machine available to the project died. Speaking only as a long-time user and observer of MacPorts, I would be surprised if Mojave support went away in this decade. With that said, "support" in MacPorts' core is not the only thing to be concerned with. One thing I found running Snow Leopard until last February on a 32bit-only CoreDuo was that support in ports I was using or tried to use was slowly crumbling over time, often beyond anything MacPorts could work around. The biggest headaches weren't even rooted in hardware or OS version per se, but in the toolchain (gcc/clang/etc.) and runtime (libgcc/libcxx/etc.) evolution. Re-bootstrapping my whole MacPorts world never became impossible, but by the end it was a multi-day festivity involving building multiple toolchains and learning obscure command-line options for port. It may never become impossible for to keep using MacPorts on Mojave, but it may end up taking so much babysitting that you'd rather not. I hope that's a long time, because my personal machines are staying there for some time as well. -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not Currently Available For Hire
Re: certificate update for old Macs
On 2022-01-04 at 14:37:18 UTC-0500 (Tue, 4 Jan 2022 11:37:18 -0800)
Michael
is rumored to have said:
On 2022-01-03, at 4:12 PM, Richard L. Hamilton
wrote:
The only problem with that or anything similar, is that unless you go
to quite a lot of work to just download rather than install the PEM
file, and convert it into something human readable WITHOUT installing
it, and investigate every certificate in there, you're trusting that
the site you got it from is not only legit, but is secure and hasn't
been hacked to alter the file to provide some very bogus certificates
that could work together with some sort DNS spoofing to get you to
feed sensitive information (ie bank passwords, etc) via an untrusted
site that would capture it.
Makes sense. Now, how do you go about turning a certificate into
something human readable? Serious question, I have *never* seen this
discussed anywhere.
Get the certificate in PEM format, then:
openssl x509 -text < cert.pem
See the man page ('man x509') for all the very gory details.
Everyone just says "As long as the roots are good you can trust the
chain", and that's never made sense to me. The whole "trust what
strangers say" system seems more like "Find a way for companies to
make money" than any good security system.
Well, yes: that's what the public CA system is. It is grounded in the
OSI protocol stack, which is big on hierarchical authority, and no one
has figured out a better model that scales and allows strangers to
establish authenticated private data transport. Ultimately it requires
shared trust anchors of some sort, and the model we've stumbled into has
the advantage of not being subject to a single authority and encouraging
the various CAs and bundlers of trust to keep watch on each other.
A mechanism for eliminating the CA-based hierarchical trust layer
already exists in the DANE (DNS-based Authentication of Named Entities)
standard that is in broad use for validating email trasnsport. It
replaces the CA model by binding the trust chain to DNS, making
certificate trust ultimately dependent on DNSSEC and subject to all of
its risks.
--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
Re: [numpy @ bigsur: multithreading]
On 2022-01-03 at 12:18:23 UTC-0500 (Mon, 3 Jan 2022 19:18:23 +0200) Maxim Abalenkov is rumored to have said: > Either I don’t understand the expected behaviour or my `port variants` > command returns something else. I would expect it to show [+]gfortran and > [+]mkl, not the [+]openblas. As documented, the 'port variants' command returns the AVAILABLE variants, with the '[+]' added to the DEFAULT variants. -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not Currently Available For Hire
Re: Installation location for python code, tools, etc.
On 2022-01-02 at 16:23:34 UTC-0500 (Sun, 2 Jan 2022 16:23:34 -0500) Forrest Aldrich is rumored to have said: 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/ This is how MacPorts supports simultaneous installs of different Python versions. You may note that there are versioned python symlinks in /opt/local/bin pointing to that path and possibly an additional bunch of symlinks making 'python' and 'python3' go there. If you install the python_select and python3_select ports, they will create links in /opt/local/bin if you run 'port select python' or 'port select python3' that ultimately resolve to that versioned path. When you install a Python module outside of MacPorts, its installer is almost certain to not know to create those links. I'm suspecting an environment variable. I believe that *in theory* you should get binaries into /opt/local/(s)bin/ if you set the PYTHONHOME environment variable to '/opt/local/Library/Frameworks/Python.framework/Versions/3.9:/opt/local' when running setup.py or pip. -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not Currently Available For Hire
Re: is macports getting rusty?
On 2021-11-29 at 08:32:46 UTC-0500 (Mon, 29 Nov 2021 13:32:46 +) Chris Jones is rumored to have said: If you find yourself during an port update building rust from source, either just let it finish, or if you don't want your machine tied up building rust for some period, just cancel the build and try again later on, as as others have pointed out eventually the buildbots will provide the binary tarball for it and thus you will just pick that once its available. This raises a question that I cannot find a clear answer to: How are builds prioritized on the buildbots? I would hope that in an ideal world, some priority is given to large, slow, and heavily-depended-upon builds. It's also easier to say that than to actually implement it, but it would help address a real pain point in using MacPorts. -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not Currently Available For Hire
Re: Does MacPorts depend on Spotlight?
On 2021-11-17 at 15:06:23 UTC-0500 (Thu, 18 Nov 2021 07:06:23 +1100 (EST)) Dave Horsfall is rumored to have said: > On Wed, 17 Nov 2021, Peter Hancock wrote: > >> On Catalina, for me the command "sudo mdutil -i off /opt/local/var/macports" >> evokes: > > [...] > > Where are all these obscure commands documented? /usr/share/man/man1/ and /usr/share/man/man8/ mostly... FWIW, 'apropos spotlight' will tell you that mdutil and mddiagnose exist. -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not Currently Available For Hire
Re: libsdl2 port question
On 2021-11-14 at 05:53:21 UTC-0500 (Sun, 14 Nov 2021 11:53:21 +0100) Gerben Wierda via macports-users is rumored to have said: I was just curious: why does the libsdl2 port which is at version 2.0.16 install 2.0.0 libraries? How does that happen? Just learning. I assume you mean the fact that the actual dylib file is named /opt/local/lib/libSDL2-2.0.0.dylib It is a norm for dynamically loaded libraries to include a symlink with their base name (i.e. /opt/local/lib/libSDL2.dylib) and sometimes additional symlinks with partial versions in their names, with the versions being indicators of binary compatibility rather than whole-project code revision. This allows for multiple incompatible versions of the same shared library to be installed simultaneously, with the runtime loader picking which version to attempt to load by the name linked in the executable. This is a pattern/norm, not a fixed standard, so exactly how a specific library handles the possibility of future version incompatibility can vary a bit. The libsdl2 devs have apparently decided to leave the name of the real library with the lowest version that remains compatible with the current version rather than doing anything more complex. Others (e.g. pth) use distinct versioning for their library names. -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not Currently Available For Hire
Re: xorg
On 2021-11-11 at 18:07:45 UTC-0500 (Fri, 12 Nov 2021 00:07:45 +0100) Tom is rumored to have said: Hi, when trying to run an X11 program, I get the following error message: (putty:8198): Gtk-WARNING **: 00:06:49.190: cannot open display: :0 Which means that your environment has the DISPLAY variable set to ":0" which indicates the first display on the local physical machine, or at least it would on most platforms that support X11. On a Mac, it's much more complicated and your DISPLAY should be a pathname to a socket in a subdirectory of /private/tmp/, whose use triggers the startup of the X display server and window manager (/Applications/MacPorts/X11.app.) How can I fix that? Make sure you have the xinit port installed (you should, as the xorg-server port depends on it.) Also make sure you have logged out and back in after installing xorg-server (and its dependencies like xinit.) -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not Currently Available For Hire
Re: port cannot fetch because of expired cert, but cert is OK according to Safari, curl (question related to Mojave / Catalina)
On 2021-11-07 at 16:29:30 UTC-0500 (Mon, 8 Nov 2021 08:29:30 +1100 (EST)) Dave Horsfall is rumored to have said: On Sun, 7 Nov 2021, Bill Cole wrote: I have my own Mojave machines working without a problem after removing the bad certificate from /etc/ssl/cert.pem. The one that starts like this: [...] Intrigued, I checked my own: mackie:~ dave$ grep "Not After" /etc/ssl/cert.pem [... many dates snipped ...] So I wonder how widespread this problem is? The problem in this case is not the existence of the cert in the CA bundle, but the fact that this particular expired cert was used in an alternative validation path and the logic of verification for multi-path certs isn't correct. Normally, expired root CAs should stay in there because that allows positive non-verification of certs supposedly issued by an expired (and maybe compromised) root CA. And I'm not happy with those that are set way in the future; I heard somewhere that 5 years is the recommended max. CAs are special. The current limit on server certs is 397 days. I don't think there's a consensus on CA lifetimes because of the conflicting risks of too-short and too-long lives. -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not Currently Available For Hire
Re: port cannot fetch because of expired cert, but cert is OK according to Safari, curl (question related to Mojave / Catalina)
d" problem described here: https://trac.macports.org/wiki/ProblemHotlist#letsencrypt When you said "curl works but port does not work" that's not quite right. /opt/local/bin/curl and /opt/local/lib/libcurl.dylib work. /usr/bin/curl and /usr/lib/libcurl.dylib (the latter of which MacPorts uses by default) do not work for Let's Encrypt-protected sites anymore. I, on High Sierra, have the same issue, and I have no solution for you. This issue affects High Sierra and Mojave. I recommend upgrading to Catalina or later; I plan to eventually. Well, you could rebuild MacPorts from source, instructing it to use a newer copy of libcurl with a newer copy of openssl or libressl that has a newer certificate bundle. For example, install a bootstrap copy of MacPorts in a separate prefix, install curl in that prefix, then rebuild your primary MacPorts from source, telling it to use the libcurl in the separate prefix. Any future upgrades to MacPorts base probably also have to be done from source; using "sudo port selfupdate" will not preserve your configure arguments and you'll be back to using the System's broken libcurl again. -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not Currently Available For Hire
Re: provide latest OS root certificates via port?
On 2021-10-29 at 11:17:52 UTC-0400 (Fri, 29 Oct 2021 11:17:52 -0400 (EDT)) Richard Bonomo TDS personal is rumored to have said: I don't know what to think about MacPorts, specifically, providing new certificates, but, pertaining to some of the arguments presented against doing this on old Macs generally, it must be kept in mind that some of us -- including yours truly -- have Apple computers that CANNOT use newer operating systems or browsers. Sometimes, one has to work with what one has. Sure, and I am not saying that MP should abandon older systems or that you and I and everyone else still running older systems is doing anything "wrong" but simply that it is risky and cannot be safe without the recognition that you have to understand and manage your risks without vendor support. Some people have expressed more judgmental views here in the past, arguing that older Macs should be relegated to running other, free OSs that have active security maintenance and suggesting that MP deprecate MacOS versions no longer supported by Apple. I'm NOT saying that, but rather that users should understand their risks and MP should not take on the doomed task of de facto trying to maintain OS versions which are by any reasonable definition obsolete. The norm for MP has been to offer parallel tools to those in the OS (e.g. current packages that match what Apple used to include in Server) and leave the issue of whether & how to user them to actually replace Apple's tools up to the user. - Original Message - From: "Bill Cole" To: "macports-users Users" Sent: Friday, October 29, 2021 10:09:45 AM Subject: Re: provide latest OS root certificates via port? On 2021-10-29 at 07:23:38 UTC-0400 (Fri, 29 Oct 2021 07:23:38 -0400) Richard L. Hamilton is rumored to have said: You're (probably - seems plausible but I haven't verified it myself) right that that's annoying and fixable. But there's a big reason to think carefully about whether to do that. If something is old enough that it isn't receiving certificate updates, it probably isn't receiving security updates either. And the same applications and functionality that need current root certificates to work are also likely to be common attack points. So at the very least, anything that makes it easier to take such a risk should come with a prominent warning, IMO. Yes: Anyone running Mojave or earlier is not exactly skydiving without a parachute, but is doing something close. Perhaps it's akin to skydiving with a homemade parachute... Frankly, I don't think MacPorts should attempt to 'fix' this issue or similar future issues diretly, not because it encourages risky behavior but because MacPorts should avoid poking around in the MacOS base at all where it isn't essential for the operation of MacPorts. It's easy enough in principle for MacPorts to stand up and use its own modern OSS-based encryption+PKI stack with its own set of trusted CAs (e.g. curl-ca-bundle and openssl ports) and so keep itself functional without poking around in core functionality of the OS that MacPorts-naive tools need to use. People who need to fix the problem of an expired root cert should be able to understand and repair that problem (which can be done without digging a CA bundle out of a newer system) if they need to, and having the issue unaddressed is not itself a security issue, but a functionality issue. Anyone who actually wants to run Safari & Chrome on an OS that isn't getting basic security maintenance should be thinking very carefully about what they are doing and accept responsibility for making something work which arguably should no longer work because it is too risky. One risk for MacPorts is a slippery slope created by providing support for antique OS versions that include opaque proprietary bits that are probably insecure in ways that no one fully understands. If it is taken too far (which in my opinion includes fixing core components like PKI) MP would be doing a disservice to users who understandably expect a "Just Works" experience on a Mac by enabling the continued use of tools that could well have permanent unrecognized and mostly invisible security flaws. On Oct 29, 2021, at 07:12, René J.V. Bertin wrote: Hi, Users of older Apple OSes that are no longer receiving updates probably noticed that Safari and Chrome-based browsers no longer connect to lots of sites because a crucial root certificate has expired. Answer 1 to https://apple.stackexchange.com/questions/422332/how-do-i-update-my-root-certificates-on-an-older-version-of-mac-os-e-g-el-capi provides an easy solution, but you need access to an up-to-date OS install. These are not proprietary to Apple so I presume it should be possible to provide the suggested `rootcerts.pem` file via a port - possibly even install it in the post-act
Re: provide latest OS root certificates via port?
On 2021-10-29 at 07:23:38 UTC-0400 (Fri, 29 Oct 2021 07:23:38 -0400) Richard L. Hamilton is rumored to have said: You're (probably - seems plausible but I haven't verified it myself) right that that's annoying and fixable. But there's a big reason to think carefully about whether to do that. If something is old enough that it isn't receiving certificate updates, it probably isn't receiving security updates either. And the same applications and functionality that need current root certificates to work are also likely to be common attack points. So at the very least, anything that makes it easier to take such a risk should come with a prominent warning, IMO. Yes: Anyone running Mojave or earlier is not exactly skydiving without a parachute, but is doing something close. Perhaps it's akin to skydiving with a homemade parachute... Frankly, I don't think MacPorts should attempt to 'fix' this issue or similar future issues diretly, not because it encourages risky behavior but because MacPorts should avoid poking around in the MacOS base at all where it isn't essential for the operation of MacPorts. It's easy enough in principle for MacPorts to stand up and use its own modern OSS-based encryption+PKI stack with its own set of trusted CAs (e.g. curl-ca-bundle and openssl ports) and so keep itself functional without poking around in core functionality of the OS that MacPorts-naive tools need to use. People who need to fix the problem of an expired root cert should be able to understand and repair that problem (which can be done without digging a CA bundle out of a newer system) if they need to, and having the issue unaddressed is not itself a security issue, but a functionality issue. Anyone who actually wants to run Safari & Chrome on an OS that isn't getting basic security maintenance should be thinking very carefully about what they are doing and accept responsibility for making something work which arguably should no longer work because it is too risky. One risk for MacPorts is a slippery slope created by providing support for antique OS versions that include opaque proprietary bits that are probably insecure in ways that no one fully understands. If it is taken too far (which in my opinion includes fixing core components like PKI) MP would be doing a disservice to users who understandably expect a "Just Works" experience on a Mac by enabling the continued use of tools that could well have permanent unrecognized and mostly invisible security flaws. On Oct 29, 2021, at 07:12, René J.V. Bertin wrote: Hi, Users of older Apple OSes that are no longer receiving updates probably noticed that Safari and Chrome-based browsers no longer connect to lots of sites because a crucial root certificate has expired. Answer 1 to https://apple.stackexchange.com/questions/422332/how-do-i-update-my-root-certificates-on-an-older-version-of-mac-os-e-g-el-capi provides an easy solution, but you need access to an up-to-date OS install. These are not proprietary to Apple so I presume it should be possible to provide the suggested `rootcerts.pem` file via a port - possibly even install it in the post-activate. I had a look but couldn't find if such a port already exists. I think it'd help for lots of people... I'd propose a draft but I'm running 10.9 ... so thanks to anyone picking this up! R. -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not Currently Available For Hire
Re: Build from local source tree
On 2021-10-24 at 11:23:47 UTC-0400 (Mon, 25 Oct 2021 01:23:47 +1000)
Peter West
is rumored to have said:
What I’m attempting is to drop the bz2-compressed sources into
/opt/local/var/macports/distfiles/gimp2, add
fetch {}
checksum {}
to the local Portfile,
portindex
sudo install gimp2
Even better: update the checksums version number in the gimp2-devel
Portfile and offer it up as a pull request.
--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
Re: Apache httpd 2.4.49 port will not launch on ElCap
On 2021-09-24 at 16:53:21 UTC-0400 (Fri, 24 Sep 2021 16:53:21 -0400)
Bill Cole
is rumored to have said:
On 2021-09-22 at 16:47:41 UTC-0400 (Wed, 22 Sep 2021 22:47:41 +0200)
Bjarne D Mathiesen
is rumored to have said:
Bill Cole wrote:
I'm wondering if anyone else has encountered this and if anyone has
a sense of whether this is really a MacPorts-specific problem or if
it is (as I suspect but have not been able to confirm) a problem
with httpd.
I'm running apache 2.4.49 on
* 10.6.8
* 10.15.7
without any issues
That brackets the problem a bit.
Given the odd failure ("crashed on child side of fork pre-exec" with a
segfault) I suspect it is something specific to the platform, e.g.
compiler version, shared library versions, etc. and I'm experimenting
with rebuilding it in different ways to see if I can find a way to
make it work.
Currently running with '-X' as a workaround (doesn't fork...)
Closing the loop here:
Rebuilding httpd and everything it recursively depends on with clang-10
on the target system didn't touch the problem. Reverting to .48 didn't
touch the problem(!) Limping along and waiting for the .51 update
resolved the problem. I did not test .50, which lasted just a few days.
I'm not up to analyzing all the flux in the httpd code between those
versions, but there are enough core and mpm fixes that I'm satisfied
with vague handwaving about something jostling an optimization in the
wrong/right place and for 2 minor versions breaking it on one obsolete
platform.
--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
Re: ruby_select is broken
On 2021-10-03 at 16:16:55 UTC-0400 (Mon, 4 Oct 2021 07:16:55 +1100) Ian Wadham is rumored to have said: Hi Christopher, In brief, MacPorts’ “port select” command is working fine at the command-line in Catalina… but the problem is with installing ANY version of ruby, not switching between multiple versions of ruby that are already installed. In a machine where no MacPorts Ruby is installed, the command “sudo port install ruby27” is not working fully. It is definitely working as designed. Your complaint is with the design. The package gets installed, but the links /opt/local/bin/ruby -> /opt/local/bin/ruby2.7 and /opt/local/bin/gem -> /opt/local/bin/gem2.7 do not get created automatically. Right. You MUST run 'port select ruby ' to select which binaries under /opt/local/*bin the symlinks point to. That's how *ALL* *_select ports work: they create the generic-name links if you select one version, and remove them if you select the "none" option. So after installing I always get Apple’s Ruby from /usr/bin when I use a “ruby” or “gem” command. Of course I can use “sudo port select” to fix that, and I have done, but it took me several days of frustration and messing around before I discovered that fact. That's a documentation problem, I guess. FWIW, the information is present in ruby_select: # port info ruby_select ruby_select @1.2 (sysutils, lang) Description: This port installs files that allow 'port select' to be used to create links to the preferred default version of Ruby. Homepage: https://www.macports.org/ Platforms:darwin License: BSD Maintainers: Email: kimu...@macports.org, GitHub: kimuraw Policy: openmaintainer I think this is because the port file named “ruby_select”, on which each Ruby port depends, is broken. But it is not broken. The ruby_select port is what provides the information that 'port select' needs to make links to a specific set of Ruby binaries. You can see this port file’s contents using: cat $(port file ruby_select) Compare them to the perl and python “select” files: cat $(port file perl_select) cat $(port file python_select) and I hope you (or someone) will see what the problem is. There is no problem. General rule: the *_select ports support the simultaneous installation of multiple versions of a port (mostly dev tools) with the active version being determined by use of 'port select' commands. Installing a specific version of a port that has a *_select port does not directly set the links to activate that version, you MUST use port select. -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not Currently Available For Hire
Re: MacPorts Only Has ImageMagick 6 not 7?
On 2021-10-02 at 17:02:20 UTC-0400 (Sat, 2 Oct 2021 16:02:20 -0500) Christopher Stone is rumored to have said: Hey Folks, I'm only seeing ImageMagick @6.9.11-60_1 from MacPorts with `port info`. It looks like the most current version is ImageMagick 7.1.0-8. https://imagemagick.org/ Is this correct, or does this have something to do with the Let's Encrypt DST Root CA X3 Expiration issue Ryan reported this morning? It is correct, and is entirely unrelated to the LE cert issue. There's an open ticket for getting v7 into ports (https://trac.macports.org/ticket/51310) that provides insight to the issues behind the delay. -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not Currently Available For Hire
Re: How do i find missing dependents using the port command?
On 2021-09-28 at 10:27:12 UTC-0400 (Tue, 28 Sep 2021 16:27:12 +0200) Gerben Wierda via macports-users is rumored to have said: > A while back I have done a lot of cleanup, using looking at dependents, > reinstalling stuff so it no longer depends on, say, older versions of python, > etc. > > Now, recently I’ve started reaching certbot/letsencrypt warnings that my > certificates are about to expire. I used to have a fully automatic setup that > did the updates in the background. Apparently, that has died. And it turns > out certbot doesn’t work anymore because some part of python is missing: > > Traceback (most recent call last): [...] > > Other than that the cleaning up has removed chardet. Looking at chardet in > what is available, I find: > > py39-cchardet @2.1.7 (python, devel, textproc) > cChardet is high speed universal character encoding detector. > > py39-chardet @4.0.0 (python, devel, textproc) > Universal character encoding detector > > I suspect I need the chardet extension. > > What is the way to find this out using a port command? In principle, 'port rdeps ' will show you a recursive tree of dependencies for any port. Also, 'port rdependents ' will show you all ports that are dependents (recursively) of any *installed* port. In practice, those are sometimes not exactly correct, because they depend on port maintainers noticing dependencies and stating them in the Portfile. For example, the error message you showed implies that certbot depends on chardet indirectly via the acme package, but that is not reflected in the MacPorts dependency map. The Changelog for certbot indicates that this dependency was added upstream in v1.18.0 and removed in 1.19.0, so the current MacPorts dependency map is correct not to show it NOW, but for most of August, that dependency existed in the code but not in the Portfile. -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not Currently Available For Hire
Re: What version of Xcode for High Sierra?
On 2021-09-24 at 19:18:56 UTC-0400 (Sat, 25 Sep 2021 09:18:56 +1000 (EST)) Dave Horsfall is rumored to have said: MacBook Pro, 13", mid-2010, 8GB memory (self-supplied, as the default 4GB is simply not enough), firmware 7,1. Relevance to MacPorts: it needs Xcode... There seems to be many versions of Xcode for High Sierra (I don't want to upgrade further just yet) so which one is known to work for this thing so that I can start using MacPorts again?? I don't want to waste a few hours of download (including Command Line Tools) only to see "xcode-select" spit the dummy because it's the wrong version of the OS or something. 10.1 or 9.4.1 should work. Supposedly one can install 10.2 by hacking some plist and it will work, but that would be silly if all you really need it for is MacPorts. -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not Currently Available For Hire
Re: Apache httpd 2.4.49 port will not launch on ElCap
On 2021-09-22 at 16:47:41 UTC-0400 (Wed, 22 Sep 2021 22:47:41 +0200)
Bjarne D Mathiesen
is rumored to have said:
Bill Cole wrote:
I'm wondering if anyone else has encountered this and if anyone has a
sense of whether this is really a MacPorts-specific problem or if it
is (as I suspect but have not been able to confirm) a problem with
httpd.
I'm running apache 2.4.49 on
* 10.6.8
* 10.15.7
without any issues
That brackets the problem a bit.
Given the odd failure ("crashed on child side of fork pre-exec" with a
segfault) I suspect it is something specific to the platform, e.g.
compiler version, shared library versions, etc. and I'm experimenting
with rebuilding it in different ways to see if I can find a way to make
it work.
Currently running with '-X' as a workaround (doesn't fork...)
--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
Apache httpd 2.4.49 port will not launch on ElCap
I've used the prebuilt binary and done a source build myself, it just won't launch. A few startup messages are in the ErrorLog, but they don't note any reason for the crash. The OS does manage to save crash reports when I try to start, all looking similar to the one below. Googling about various specifics from the crash report (e.g. https://stackoverflow.com/questions/55286016/python-is-crashing-due-to-libdispatch-crashing-child-thread) makes me suspect that this has something to do with how httpd initializes itself. Telling bit is the "crashed on child side of fork pre-exec" I'm wondering if anyone else has encountered this and if anyone has a sense of whether this is really a MacPorts-specific problem or if it is (as I suspect but have not been able to confirm) a problem with httpd. Contents of crash report (/Library/Logs/DiagnosticReports/httpd_2021-09-21-122643_shiny.crash): Process: httpd [2068] Path: /opt/local/sbin/httpd Identifier:httpd Version: 0 Code Type: X86-64 (Native) Parent Process:launchd [1] Responsible: httpd [2068] User ID: 0 Date/Time: 2021-09-21 12:26:37.866 -0400 OS Version:Mac OS X 10.11.6 (15G22010) Report Version:11 Anonymous UUID:DBCB60BF-452B-41AE-45BC-977D8F360144 Time Awake Since Boot: 3400 seconds System Integrity Protection: enabled Crashed Thread:0 Dispatch queue: com.apple.main-thread Exception Type:EXC_BAD_ACCESS (SIGSEGV) Exception Codes: KERN_INVALID_ADDRESS at 0x0110 Exception Note:EXC_CORPSE_NOTIFY VM Regions Near 0x110: --> __TEXT 00010c8a1000-00010c8f6000 [ 340K] r-x/rwx SM=COW /opt/local/sbin/httpd Application Specific Information: crashed on child side of fork pre-exec Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 libdispatch.dylib 0x7fff85630661 _dispatch_queue_push_queue + 345 1 libdispatch.dylib 0x7fff8562eb06 _dispatch_queue_wakeup_with_qos_slow + 126 2 libcorecrypto.dylib 0x7fff8a355ddc ccrng_CommonCrypto_generate + 309 3 libcommonCrypto.dylib 0x7fff8ea8648f CCRandomGenerateBytes + 28 4 libcrypto.1.1.dylib 0x00010f1f2efb rand_pool_acquire_entropy + 69 5 libcrypto.1.1.dylib 0x00010f1f204f rand_drbg_get_entropy + 364 6 libcrypto.1.1.dylib 0x00010f1f1296 RAND_DRBG_reseed + 212 7 libcrypto.1.1.dylib 0x00010f1f16f3 RAND_DRBG_generate + 407 8 libcrypto.1.1.dylib 0x00010f1f1fd5 rand_drbg_get_entropy + 242 9 libcrypto.1.1.dylib 0x00010f1f1296 RAND_DRBG_reseed + 212 10 libcrypto.1.1.dylib 0x00010f1f16f3 RAND_DRBG_generate + 407 11 libcrypto.1.1.dylib 0x00010f1f1819 RAND_DRBG_bytes + 139 12 libssl.1.1.dylib0x00010f0878e1 SSL_CTX_new + 614 13 mod_ssl.so 0x00010f03aca2 ssl_init_ctx + 344 14 mod_ssl.so 0x00010f03a194 ssl_init_proxy_ctx + 85 15 mod_ssl.so 0x00010f039e66 ssl_init_ConfigureServer + 3896 16 mod_ssl.so 0x00010f038a03 ssl_init_Module + 802 17 httpd 0x00010c8a4521 ap_run_post_config + 69 18 httpd 0x00010c8abb68 main + 2112 19 libdyld.dylib 0x7fff92f3f5ad start + 1 [remainder elided, including details of loaded dylibs and memory zone status] -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not Currently Available For Hire
Re: CACKey_0.7.8_Slandup.pkg installation fails
On 2021-07-21 at 15:59:32 UTC-0400 (Wed, 21 Jul 2021 13:59:32 -0600) Tao Zhang is rumored to have said: Hi, I am installing "CACKey_0.7.8_Slandup.pkg" CACKey package. That's not a MacPorts package. You are unlikely to find much help from this mailing list. It failed with the following information: "The installation failed. The installer encountered an error that caused the installation to fail. Contact the software manufacturer for assistance." You should do that. The home site for that software appears to be https://cackey.rkeene.org I just checked two directories in my Mac (OS 10.14.6) "/usr/local/lib" and "/Library", MacPorts ports avoid installing anything in either of those directories. With very few exceptions, MacPorts installs software under /opt/local/ and not in any standard macOS directories to avoid entanglement with system software. There are two folders "pkcs11" and "CACKey" that are created today (7/21). I can not access these two folders because the owner is macports. That is very strange. You should contact the developer about that, and find out if the package is intended to install files owned by 'macports' or if that is some sort of accident. It is possible for software to install itself under a numeric user ID that accidentally collides with the macports user. I am wondering whether the above issues cause the failure of installation of "CACKey_0.7.8_Slandup.pkg"? May I remove those two folders "pkcs11" and "CACKey"? How can I remove them or How can I change the owner? 'sudo chown ' should do the job. Whether that's a solution to your problem or just a way to make it worse, I have no idea. -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not Currently Available For Hire
Re: apache doc folder permissions problem
On 2021-06-18 at 14:33:43 UTC-0400 (Fri, 18 Jun 2021 14:33:43 -0400) Murray Eisenberg is rumored to have said: On 18 Jun2021, at 2:13 PM, Bill Cole wrote: On 2021-06-18 at 10:17:13 UTC-0400 (Fri, 18 Jun 2021 10:17:13 -0400) Murray Eisenberg is rumored to have said: Indeed, sudo chmod a+x /Users /Users/me /Users/me/Sites fixed the permissions access problem. ... The requirement is that the user running httpd must have search access on the whole tree above anywhere httpd is serving files from. The precise meaning of the 'search' permission (i.e. the 'execute' bit on a directory) is not intuitive or even well documented. It is simply the ability to access nodes within the directory based on those nodes' permissions, provided the caller knows the name of the item being accessed. Without search permission it simply does not matter what the permissions on items below the directory might be, they cannot be accessed. If you are concerned with other users (i.e. processes running as other users, such as 'daemon' which runs httpd under MacPorts) you can 'chmod a-r' on those directories to block reading of the directories themselves (i.e. the list of names of sub-nodes.) You can provide the search permission via the basic rwx by user/group/all mechanism or by extended ACLs, but you cannot create a deep space of access without a path from above…. With macOS 11.4 at least, the command chmod a-r /Users and even sudo chmod a-r /Users gives error "chmod: Unable to change file mode on /Users: Operation not permitted”. Which indicates that Apple has decided to add /Users to the creeping expanse of files and directories behind the Iron Curtain of SIP. Consider yourself Protected. (By contrast, making the change for /Users/me and /Users/me/Sites is OK.) I guess they are waiting for OS 12 to lock those down... -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not Currently Available For Hire
Re: mysql8 data dir owner and permissions?
On 2021-06-18 at 12:40:30 UTC-0400 (Fri, 18 Jun 2021 12:40:30 -0400) Murray Eisenberg is rumored to have said: I have a non-default location for the data dir with mysql8, namely, as specified in my.cnf: datadir = /Users/me/Databases/mysql/data What should the ownership of that directory, and its subdirectories and files, be? And with what permissions? The owner needs to be whatever user runs the mysqld process, which creates, deletes, reads, and writes files there as a necessary part of its operation. That's probably _mysql. That user ALSO needs a path up to the root of the filesystem that it can traverse, i.e. that it has search permission for. Assuming this 'me' is the same as that for your httpd issue, you already have that for /Users and /Users/me. No other user needs any access except for whatever is doing your backups, which need read access on files & directories and search (execute) on directories. That is usually going to be root, so you don't need to be concerned about group ownership or other permissions. At the moment, for reasons I do not know, I have: ls -ld /Users/me/Databases/mysql/data drwxr-x--- 91 me staff 2912 Jun 18 10:18 /Users/me/Databases/mysql/data And: [~] % ls -l /Users/me/Databases/mysql/data total 709416 [partial listing] -rw-r- 1 me staff 196608 Apr 6 10:04 #ib_16384_0.dblwr -rw-r- 1 me staff 8585216 Feb 4 12:45 #ib_16384_1.dblwr drwxr-x--- 12 me staff 384 Apr 6 10:02 #innodb_temp -rw-r- 1 me staff 4982504 Oct 3 2020 mymac.local.err -rw-r- 1 me staff 4 Apr 6 10:02 mymac.pid drwxr-x--- 23 me staff 736 Oct 3 2020 Math421Blog -rw-r-@ 1 me staff 56 Oct 25 2018 auto.cnf -rw-r- 1 me staff 179 Mar 7 22:47 binlog.003746 : -rw-r- 1 me staff 864 Apr 6 10:02 binlog.index -rw--- 1 me staff 1680 Jan 2 2020 ca-key.pem -rw-r--r-- 1 me staff 1112 Jan 2 2020 ca.pem -rw-r--r-- 1 me staff 1112 Jan 2 2020 client-cert.pem -rw--- 1 me staff 1676 Jan 2 2020 client-key.pem -rw-r- 1 me staff 5175 Apr 5 23:15 ib_buffer_pool -rw-r- 1 me staff 50331648 Apr 6 10:04 ib_logfile0 -rw-r- 1 me staff 50331648 Feb 5 12:55 ib_logfile1 -rw-r- 1 me staff 79691776 Apr 6 21:01 ibdata1 -rw-r- 1 me staff 12582912 Apr 6 10:02 ibtmp1 drwxr-x--- 8 me staff 256 Feb 4 12:45 mysql -rw-r- 1 me staff 46137344 Apr 6 10:02 mysql.ibd -rw-r- 1 me staff 6 Feb 4 12:45 mysql_upgrade_info drwxr-x--- 111 me staff 3552 Feb 4 12:45 performance_schema drwxr-x--- 21 me staff 672 Oct 3 2020 phpmyadmin -rw--- 1 me staff 1680 Jan 2 2020 private_key.pem -rw-r--r-- 1 me staff 452 Jan 2 2020 public_key.pem drwxr-x--- 29 me staff 928 Oct 3 2020 sakila -rw-r--r-- 1 me staff 1112 Jan 2 2020 server-cert.pem -rw--- 1 me staff 1676 Jan 2 2020 server-key.pem drwxr-x--- 3 me staff 96 Oct 3 2020 sys -rw-r- 1 me staff 80740352 Apr 6 10:04 undo_001 -rw-r- 1 me staff 29360128 Feb 5 21:01 undo_002 So, 'chown -R _mysql /Users/me/Databases' should do the trick. -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not Currently Available For Hire
Re: apache doc folder permissions problem
On 2021-06-18 at 10:17:13 UTC-0400 (Fri, 18 Jun 2021 10:17:13 -0400) Murray Eisenberg is rumored to have said: Indeed, sudo chmod a+x /Users /Users/me /Users/me/Sites fixed the permissions access problem. Is there some alternative way to fix this — by changing the owner of just /Users/me/Sites and its tree of descendents and/or by changing settings in the entries of /opt/local/etc/apache2/extra/httpd-vhosts.conf ? The requirement is that the user running httpd must have search access on the whole tree above anywhere httpd is serving files from. The precise meaning of the 'search' permission (i.e. the 'execute' bit on a directory) is not intuitive or even well documented. It is simply the ability to access nodes within the directory based on those nodes' permissions, provided the caller knows the name of the item being accessed. Without search permission it simply does not matter what the permissions on items below the directory might be, they cannot be accessed. If you are concerned with other users (i.e. processes running as other users, such as 'daemon' which runs httpd under MacPorts) you can 'chmod a-r' on those directories to block reading of the directories themselves (i.e. the list of names of sub-nodes.) You can provide the search permission via the basic rwx by user/group/all mechanism or by extended ACLs, but you cannot create a deep space of access without a path from above. And if there is no such alternative, then why would permissions on /Users, /Users/me, and /Users/me/Sites have changed away from a+x, seemingly without my own intervention, during some macOS upgrade? We do not know if it happened to all 3, as you did not show listings showing those directories' permissions. I only advised you to chmod them all because they all must have the permission and there's no effect of adding a permission that already exists. My guess is that at some point Apple decided to tighten up permissions on home directories because it is simply a standard best practice. They have been getting increasingly unilateral in their security decisions since ~10.9 and removing world read and search/execute permissions from home directories is a harmless tightening for the overwhelming majority of Mac users. -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not Currently Available For Hire
Re: apache doc folder permissions problem
On 2021-06-17 at 15:32:38 UTC-0400 (Thu, 17 Jun 2021 15:32:38 -0400) Murray Eisenberg is rumored to have said: I’m at a loss what to do in response to the reply, below, from Bill Cole. I note that to the best of my knowledge, nothing changed as to the attributes or permissions of any of the user doc folders listed in my httpd-vhosts.conf file except as may have been done without my knowledge in an update to macOS 11.3 or 11.4, or in case of some change in the MacPorts files supporting apache — but I believe I’m still using the very same configuration files, including httpd.conf, httpd-vhosts.conf, and httpd-userdir.conf (and /private/etc/hosts) as I have in the past! 1. What should I do with respect to extended attributes? I get: [~] % ls -le Sites total 32 [some results omitted from list] drwxr-xr-x@ 23 me staff 736 Jul 31 2020 Math421Blog drwxr-xr-x@ 92 me staff 2944 Apr 10 2015 MyHomePage drwxr-xr-x 32 me staff 1024 Jun 12 15:32 RapidWeaver drwxr-xr-x@ 20 me staff 640 Jun 17 10:23 html drwxr-xr-x 10 me staff 320 Aug 27 2017 newsite And: [~] % ls -le Sites/MyHomePage total 541576 [I show only a couple of the files & folders] drwxr-xr-x@ 73 me staff 2336 Jan 31 2015 Math_127 drwxr-xr-x@ 146 me staff 4672 Jan 31 2015 Math_131 -rw-r--r--@ 1 me staff 8331 Apr 10 2015 index.html -rw-r--r--@ 1 me staff 39890 Jun 2 2010 me.jpg -rw-r--r--@ 1 me staff695 Feb 24 2011 site.css -rw-r--r--@ 1 me staff 1385 Feb 24 2011 style.css That's fine as is. If extended ACLs were your issue, the 'e' option to ls would have displayed them. 2. In the vhost-specific error log /opt/local/var/log/apache2/me-MyHomePageerror_log I’m finding entries like this: [Thu Jun 17 15:17:10.509589 2021] [core:error] [pid 13543] (13)Permission denied: [client 127.0.0.1:53851] AH00035: access to / denied (filesystem path '/Users/me/Sites') because search permissions are missing on a component of the path [Thu Jun 17 15:17:10.551868 2021] [core:error] [pid 13543] (13)Permission denied: [client 127.0.0.1:53851] AH00035: access to /favicon.ico denied (filesystem path '/Users/me/Sites') because search permissions are missing on a component of the path, referer: http://myhomepage.local/ [Thu Jun 17 15:19:00.531386 2021] [core:error] [pid 13498] (13)Permission denied: [client 127.0.0.1:53909] AH00035: access to / denied (filesystem path '/Users/me/Sites') because search permissions are missing on a component of the path There's the critical clue! Your home directory is probably not world-searchable. To eliminate the reported error definitively: sudo chmod a+x /Users /Users/me /Users/me/Sites 3. File httpd.conf includes the lines: DocumentRoot "/opt/local/www/apache2/html" Options Indexes FollowSymLinks AllowOverride None Require all granted I don’t think that’s changed. Looks good. 4. The errors are occurring with Opera as well as with Safari. I don’t know if there’s any browser setting that’s upgrading http to https; I am explicitly using the “http:” prefix in “http://MyHomePage.local <http://myhomepage.local/>" So that is probably not an issue On June 13 at 16:21 UTC 2021, Bill Cole wrote: On 2021-06-13 at 11:47:53 UTC-0400 (Sun, 13 Jun 2021 11:47:53 -0400) Murray Eisenberg <https://lists.macports.org/mailman/listinfo/macports-users>> is rumored to have said: ls -ld Sites drwxr-xr-x@ 18 me staff 576 Feb 27 10:37 Sites 4 thoughts: 1. The '@' indicating the existence of extended attributes could be overriding the '+' that is shown on files with extended ACLs, so any level in the directory tree COULD have an ACL blocking the webserver from reading the files or scanning the directories. Check with 'ls -le' to be sure. This would be a simple but unlikely cause of the problem. 2. Check the error logs for details of the failure. There is a vhost-specific error log defined, but there should also be a server-wide error log which may contain illuminating entries. 3. Check the main httpd.conf for Directory or Location directives that may be interfering with the Directory directives in the VirtualHost definition. 4. Make sure you don't have anything automatically 'upgrading' you to HTTPS. This can be in the server config or in a browser setting. On 12 Jun2021, at 8:37 PM, Jeff Greenberg <https://lists.macports.org/mailman/listinfo/macports-users>> wrote: How about the permissions on the Sites folder? On Jun 12, 2021, at 20:24, Murray Eisenberg <https://lists.macports.org/mailman/listinfo/macports-users>> wrote: For the Macports apache2 installation, I’m using a non-default locati
Re: apache doc folder permissions problem
On 2021-06-13 at 11:47:53 UTC-0400 (Sun, 13 Jun 2021 11:47:53 -0400) Murray Eisenberg is rumored to have said: ls -ld Sites drwxr-xr-x@ 18 me staff 576 Feb 27 10:37 Sites 4 thoughts: 1. The '@' indicating the existence of extended attributes could be overriding the '+' that is shown on files with extended ACLs, so any level in the directory tree COULD have an ACL blocking the webserver from reading the files or scanning the directories. Check with 'ls -le' to be sure. This would be a simple but unlikely cause of the problem. 2. Check the error logs for details of the failure. There is a vhost-specific error log defined, but there should also be a server-wide error log which may contain illuminating entries. 3. Check the main httpd.conf for Directory or Location directives that may be interfering with the Directory directives in the VirtualHost definition. 4. Make sure you don't have anything automatically 'upgrading' you to HTTPS. This can be in the server config or in a browser setting. On 12 Jun2021, at 8:37 PM, Jeff Greenberg wrote: How about the permissions on the Sites folder? On Jun 12, 2021, at 20:24, Murray Eisenberg wrote: For the Macports apache2 installation, I’m using a non-default location for my web sites. The httpd.conf includes a httpd-vhosts.conf file, and the latter includes entries such as: DocumentRoot "/Users/me/Sites/MyHomePage" ServerName MyHomePage.local ServerAlias www.MyHomePage.local <http://www.myhomepage.local/> ErrorLog "var/log/apache2/me-MyHomePageerror_log" CustomLog "var/log/apache2/me-MyHomePage-access_log" common Options Indexes FollowSymLinks Require all granted And in my /private/etc/hosts I include the lines: 127.0.0.1 localhost 255.255.255.255 broadcasthost ::1 localhost fe80::1%lo0 localhost 127.0.0.1 me-html.local 127.0.0.1 MyHomePage.local When I start apache and try to open the site MyHomePage.local, i get error: Forbidden You don't have permission to access this resource. The permissions on /Users/me/Sites/MyHomePage are: drwxr-xr-x@ 92 me staff 2944 Apr 10 2015 MyHomePage and the permissions for /Users/me/Sites/MyHomePage/index.html are: -rw-r--r--@ 1 me staff 8331 Apr 10 2015 index.html What’s wrong? -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not Currently Available For Hire
Re: Why don't p5-* ports mark their dependencies?
On 2021-06-12 at 12:55:24 UTC-0400 (Sat, 12 Jun 2021 09:55:24 -0700) Ken Cunningham is rumored to have said: macports recommended perl is still 5.28 Which has been unsupported upstream for just over a year. 5.30 just fell out of support a few weeks ago. They are doing a major release every year and only supporting the current and prior stable releases. "Pace" is all the rage these days, having supplanted "stability." I still have stable production on 5.28.3 because of some known issues in 5.30 and later with code hygiene, but I need to work on those issues so a 5.30 test system (and soon 5.32) is necessary for me. $ port info perl5 perl5 @5.28.3 (lang) Sub-ports:perl5.16, perl5.18, perl5.20, perl5.22, perl5.24, perl5.26, perl5.28, perl5.30, perl5.32 Variants: perl5_26, [+]perl5_28, perl5_30 Odd that perl5.32 is a sub-port but perl5_32 isn't a variant. so that is supposed to be the default perl for everything, until such time as that is changed to perl 5.30. So if you want perl 5.30 for everything, you will be fighting upstream at every turn. I see it more as opening a second front downstream of MacPorts in alliance with the Perl upstream. :) Someone could make a full-time+ job of maintaining just the Perl packages in MacPorts. -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not Currently Available For Hire
Re: Why don't p5-* ports mark their dependencies?
On 2021-06-12 at 12:11:47 UTC-0400 (Sat, 12 Jun 2021 09:11:47 -0700) Kastus Shchuka is rumored to have said: I wish it could be so easy to remove perl5.28. Apparently, I have to keep it because of git: port uninstall git port install git -perl5_28 +perl5_30 -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not Currently Available For Hire
Re: Why don't p5-* ports mark their dependencies?
On 2021-06-09 at 15:51:09 UTC-0400 (Wed, 9 Jun 2021 15:51:09 -0400)
Daniel J. Luke
is rumored to have said:
On Jun 6, 2021, at 1:41 PM, Bill Cole
wrote:
I *think* I've even worked out the right way to use that construct to
make Perl upgrades simpler, so I use the p5-* ports:
I gave up on trying to use this in any useful way a while ago - if
you've got some way that it works, please share.
According to my shell history, this is what I did to clear out all the
old perl5.2[68] and
port deactivate perl5
port install perl5 +perl5_30
port deactivate perl5.26
port deactivate perl5.28
port installed|grep '^ p5\.2.*-' |awk '{print $1}'|while read x; do
y=`echo $x|sed 's/\.2.-/-/'`; port -v -f deactivate $x ; port -v install
$y; done
Adjust to suit whatever versions you're trying to remove/replace.
--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
Why don't p5-* ports mark their dependencies?
Not sure where the bug is here, but it's evident in 'port reclaim'. The p5-* ports are basically placeholders for the p5.##- ports. I *think* I've even worked out the right way to use that construct to make Perl upgrades simpler, so I use the p5-* ports: $ sudo port install p5-net-cidr p5-term-readline p5-test-fatal ---> Computing dependencies for p5-net-cidr The following dependencies will be installed: p5.30-net-cidr Continue? [Y/n]: y ---> Fetching archive for p5.30-net-cidr ---> Attempting to fetch p5.30-net-cidr-0.200.0_0.darwin_18.noarch.tbz2 from https://ywg.ca.packages.macports.org/mirror/macports/packages/p5.30-net-cidr ---> Attempting to fetch p5.30-net-cidr-0.200.0_0.darwin_18.noarch.tbz2.rmd160 from https://ywg.ca.packages.macports.org/mirror/macports/packages/p5.30-net-cidr ---> Installing p5.30-net-cidr @0.200.0_0 ---> Activating p5.30-net-cidr @0.200.0_0 ---> Cleaning p5.30-net-cidr ---> Cleaning p5-net-cidr ---> Computing dependencies for p5-term-readline The following dependencies will be installed: p5.30-term-readline Continue? [Y/n]: y ---> Fetching archive for p5.30-term-readline ---> Attempting to fetch p5.30-term-readline-1.140.0_0.darwin_18.noarch.tbz2 from https://ywg.ca.packages.macports.org/mirror/macports/packages/p5.30-term-readline ---> Attempting to fetch p5.30-term-readline-1.140.0_0.darwin_18.noarch.tbz2.rmd160 from https://ywg.ca.packages.macports.org/mirror/macports/packages/p5.30-term-readline ---> Installing p5.30-term-readline @1.140.0_0 ---> Activating p5.30-term-readline @1.140.0_0 ---> Cleaning p5.30-term-readline ---> Cleaning p5-term-readline ---> Computing dependencies for p5-test-fatal The following dependencies will be installed: p5.30-test-fatal Continue? [Y/n]: y ---> Fetching archive for p5.30-test-fatal ---> Attempting to fetch p5.30-test-fatal-0.16.0_0.darwin_18.noarch.tbz2 from https://ywg.ca.packages.macports.org/mirror/macports/packages/p5.30-test-fatal ---> Attempting to fetch p5.30-test-fatal-0.16.0_0.darwin_18.noarch.tbz2.rmd160 from https://ywg.ca.packages.macports.org/mirror/macports/packages/p5.30-test-fatal ---> Installing p5.30-test-fatal @0.16.0_0 ---> Activating p5.30-test-fatal @0.16.0_0 ---> Cleaning p5.30-test-fatal ---> Cleaning p5-test-fatal ---> Scanning binaries for linking errors ---> No broken files found. ---> No broken ports found. Perfectly normal, right? However, immediately after doing that, I did a reclaim and got a surprise: $ sudo port -v reclaim ---> Checking for unnecessary unrequested ports Unrequested ports without requested dependents found: p5.30-test-fatal @0.16.0_0 p5.30-net-cidr @0.200.0_0 p5.30-term-readline @1.140.0_0 Would you like to uninstall them? [Y/n]: n And the dependency map is not reversible: $ port deps p5-net-cidr Full Name: p5-net-cidr @0.200.0_0 Library Dependencies: p5.30-net-cidr $ port rdependents p5.30-net-cidr p5.30-net-cidr has no dependents. -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not Currently Available For Hire
Re: Xcode for Sierra 10.12.6
On 2021-05-23 at 19:45:17 UTC-0400 (Mon, 24 May 2021 09:45:17 +1000 (EST)) Dave Horsfall is rumored to have said: > So, where can I find Xcode for 10.12.6 https://developer.apple.com/download/more/?=xcode Not sure which version you need, but it will be there. -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not Currently Available For Hire
Re: Command line glob expansion broken-ish
On 2021-05-20 at 02:10:39 UTC-0400 (Thu, 20 May 2021 01:10:39 -0500) Ryan Schmidt is rumored to have said: On May 19, 2021, at 20:43, Bill Cole wrote: Example: shiny:~ root# port installed *proto The following ports are currently installed: xorg-xorgproto @2021.4_0 shiny:~ root# port installed |fgrep proto xorg-compositeproto @0.4.2_0 (active) xorg-damageproto @1.2.1_0 (active) xorg-fixesproto @5.0_0 (active) xorg-kbproto @1.0.7_0 (active) xorg-randrproto @1.5.0_0 (active) xorg-renderproto @0.11.1_0 (active) xorg-xineramaproto @1.2.1_0 (active) xorg-xorgproto @2021.4_0 I do understand the issue, I think: the glob is being expanded against the names of ports that still exist in the current ports tree, not the ones that have been installed but have been superseded by (in this case) an omnibus port that won't activate because of the existing installations. The obvious workaround was to manually uninstall each of the zombie ports individually. I wonder if anyone else considers this a bug? I believe that's behaving as designed, so it's not a bug. OK. I can see how that choice makes port-expression handling more efficient. It is probably worth documenting (I know: PRs welcomed...) You can identify what you call zombie ports and what we call obsolete ports with: port installed obsolete That's the bit of man page I skimmed too loosely. Thanks! You can uninstall them with sudo port uninstall obsolete You can also periodically use sudo port reclaim to reclaim disk space from things that are no longer needed, which might include obsolete ports unless you had explicitly requested them to be installed. This is a machine whose MacPorts world had seen no attention in many months and probably hasn't been installed from scratch in 5+ years, as it was retired to low-attention duties. I may well have 'setrequested' every installed port at the last major OS update. -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not Currently Available For Hire
Command line glob expansion broken-ish
Example: shiny:~ root# port installed *proto The following ports are currently installed: xorg-xorgproto @2021.4_0 shiny:~ root# port installed |fgrep proto xorg-compositeproto @0.4.2_0 (active) xorg-damageproto @1.2.1_0 (active) xorg-fixesproto @5.0_0 (active) xorg-kbproto @1.0.7_0 (active) xorg-randrproto @1.5.0_0 (active) xorg-renderproto @0.11.1_0 (active) xorg-xineramaproto @1.2.1_0 (active) xorg-xorgproto @2021.4_0 I do understand the issue, I think: the glob is being expanded against the names of ports that still exist in the current ports tree, not the ones that have been installed but have been superseded by (in this case) an omnibus port that won't activate because of the existing installations. The obvious workaround was to manually uninstall each of the zombie ports individually. I wonder if anyone else considers this a bug? -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not Currently Available For Hire
Re: Reclaim was not 'safe'
On 2021-05-10 at 12:47:35 UTC-0400 (Mon, 10 May 2021 09:47:35 -0700) Ken Cunningham is rumored to have said: Isn't that just sudo port setrequested installed That’s what I’ve always done to avoid this, also having been burned by it once years ago: sudo port setrequested installed That basically eliminates the first stage of "reclaim" from ever doing anything, which may not be a bad idea as it currently stands. Also, it is probably better to use 'active' rather than 'installed' as there's no point in marking deactivated ports (generally speaking: old versions) as requested. -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not Currently Available For Hire
