Help me understand dependents of libgcc-devel vs gcc13?
Hi folks: My "port upgrade outdated" commands were being blocked for a couple of weeks because a) port libgcc-devel was failing to build (see ticket #68421 [1]), and b) several ports were dependents of libgcc-devel for reasons I don't understand, and c) I had port libgcc-devel and not port gcc13 installed, for reasons I don't understand. I blundered around until I fixed the problem (I think) by 1. deactivating libgcc-devel, blasting past the warning that five ports would break; then 2. installing port gcc13, which seemed to fill the hole left by libgcc-devel. Could someone please help me understand: Q: why are ports like fftw-3 reported as dependents of port libgcc-devel? I don't see anything in fftw-3's portfile[2] which mentions port libgcc-devel, or indeed any gcc or libgcc, are dependencies. I suspect there is some behind-the-scenes dependency addition. Maybe it is behind the scenes because so many ports depend on C or C++ compilers. Where is this dependence addition documented? How should I as a user think of it? Q: Why would I have libgcc-devel installed, and not have gcc13 (which has dependencies on ports libgcc and libgcc13) installed? What sort of things cause the oblivious user to install libgcc-devel? Q: was deactivating libgcc-devel and explicitly installing gcc13 the right way to fix this problem? (I am using macOS 12.6 Monterey, so I think the portfiles tell me that gcc13 is the correct version.) Note that the details of the breakage of port libgcc-devel don't matter to me if I don't need it, and can use something else instead. Thanks in advance for helping me understand, —Jim DeLaHunt [1] <https://trac.macports.org/ticket/68421>, ' libgcc-devel @14-20231001_0: build fails on arm64 "Configuration aarch64-apple-darwin21 not supported"' [2] <https://github.com/macports/macports-ports/blob/4bafaba8c01a85cbc757cc75c8327ec2ea2a95f6/math/fftw-3/Portfile> -- .--Jim DeLaHunt, Vancouver, Canada
Re: Help me understand dependents of libgcc-devel vs gcc13?
Ken: Thank you for your explanation. I can imagine this is how my ports collection came to include gcc-devel/libgcc-devel. On 2023-10-17 00:36, Ken Cunningham wrote: There was a time when the only version of gcc that built on arm64 was gcc-devel/libgcc-devel. So ports put a specific dependency on that on arm. This was a long time ago now. It got things built. Then various gcc versions came out, gcc-12, gcc-13 that would build on arm64 (with extra patches, but would build). So the dependency on gcc-devel/libgcc-devel was removed. But there are situations where if you had already installed some ports, you were stuck in the gcc-devel loop due to recorded variant history. Or if you had gcc-devel installed / libgcc-devel, it just kept on getting updated. None of this is ideal... It was just "expedient" as a Way To Get Things Done when things are imperfect. Same thing happens with perl and python and other supporting ports. MacPorts has been trying to purge all this kind of stuff out of the ports tree -- but it's hard, and complicated, and there is still lots and lots of it in there. Josh has made specific changes to try to reduce this recorded clutter. This is very helpful information. I am trying to figure out a way to package it into a wiki article, so that it can help the next person who has my question. For now, it is in the macports-users list archives, where searches can find it. One of my questions was, "was deactivating libgcc-devel and explicitly installing gcc13 the right way to fix this problem?" From your mention of "gcc-12, gcc-13 [coming out] which would build on arm64, I infer that it was an acceptable way to fix the problem. But you seem to have a different way to solve it: What I do is keep track of the ports I actually want installed by using "requested". Then every so often I delete all my ports, and reinstall them all freshly (not using the restore script, as that records the old variants I'm trying to get rid of) to pick up all the new defaults that have crept in over the period of time since I did it last. By doing that, you get all the new perl versions, python versions, gcc versions, etc. Clever! One question of mine which did not get answered: "Q: why are ports like fftw-3 reported as dependents of port libgcc-devel? I don't see anything in fftw-3's portfile[2] which mentions port libgcc-devel, or indeed any gcc or libgcc, are dependencies. "I suspect there is some behind-the-scenes dependency addition. Maybe it is behind the scenes because so many ports depend on C or C++ compilers. Where is this dependence addition documented? How should I as a user think of it?" Best regards, —Jim DeLaHunt
Re: Doubly Active PHP
On 2024-09-08 23:27, Bernard via macports-users wrote: When I type ‘port installed’, I notice I have 2 php8* ports (php82 @8.2.23_0 and php83 @8.3.11_0) and both are active. ...[detail elided]... Why do I have 2 php8* ports? Should I do anything at all? Only two PHP8* ports? That's nothing! I have 8 Python* ports installed! Seriously, it is common in macports to have distinct ports or subports for different versions of software where users might want to keep multiple versions on hand for easy use. The `port select` command lets you switch between these versioned ports. Type `port help select` in your shell to find out more. Unfortunately, I do not see it described in the MacPorts Guide <https://guide.macports.org/> or the MacPorts wiki <https://trac.macports.org/search?q=%22port+select%22&noquickjump=1&wiki=on>. Does this answer your question? —Jim DeLaHunt
Re: rsync and different UTF normalization in APFS vs HFS+ (macports-users Digest, Vol 167, Issue 3)
her purposes, including normalisation. See UAX #15 /Unicode
Normalization Forms/ <http://www.unicode.org/reports/tr15/>.
* NFD: a normalisation algorithm which mostly decomposes compound
characters: U+00C5 (Å) becomes U+0041 U+030A (Å, i.e. A˚).
* Sensitive and insensitive: whether a difference between characters
is significant or not significant when testing for "is the same".
File systems can be case-sensitive, in which case Case.txt and
cAsE.Txt are different; or they can be case-insensitive, in which
case the two names are the same. Similarly, file systems can be
normalisation-sensitive, in which case 5Å.svg and 5Å.svg are
different, or they can be normalisation-insensitive, in which case
they are the same.
* Preserving and not-preserving: whether a difference between
characters, present when names are written to a file system, is
still present when the file names are read back out of the file
system. DOS 8.3 FAT filesystems are case-insenstive and
case-non-preserving: write "case.txt", and you get back "CASE.TXT".
Similarly, file systems can be normalisation-preserving or
normalisation-non-preserving. If you write 5Å.svg and 5Å.svg to
HFS+, which is normalisation-insenstive and
normalisation-non-preserving, you get back 5Å.svg. If you write
them to APFS, which is normalisation-/preserving/, though
normalisation-insenstive, you get back the same 5Å.svg and 5Å.svg.
So, the challenge which Ces VLC is giving to rsync is, read a filename
{Na} from APFS filesystem A as Unicode characters from A's API, convert
the name to UTF-8 code units, don't touch normalisation, convert to a
name {Nb} on HFS+ filesystem B using B's API, and save the file in B.
HFS+ on B normalises it to {Nb_norm}. Later, read filename {Na} from A,
convert it to UTF-8, convert it to name {Nb} on B; is this the "same" as
the existing filename {Nb_norm} on B?
There is an Rsync FAQ which might be relevant: "rsync recopies the same
files" <https://rsync.samba.org/FAQ.html#2>. it suggests fixing the
problem using --iconv to specify filename conversions. I haven't looked
into rsync enough to know if it will solve the problem. The impression I
get is that rsync will not "first detect the disk FS, then choose proper
flags". I suspect you will have to do that when you invoke rsync, using
your knowledge of the source and destination filesystems.
I'm sorry this is so wordy, and I hope you see the distinctions I'm
trying to explain. And, I hope this helps you figure out a solution.
Please let the list know what you find out.
Best regards,
—Jim DeLaHunt, software engineer, Vancouver, Canada
Protocol for updating wiki pages at trac.macports.org?
Hello, MacPorts folks: Is there a protocol for making improvements to wiki pages at trac.macports.org beyond, "log in, press the edit button, and make the change"? I have a documentation improvement that will make my life easier, but I don't want to make a mess that someone needs to unwind. What I want to document is use of links of the form, [changeset:bd5d6800828a3dcda1b65f3999fa748a365b168e/macports-ports] and [changeset:bd5d6800828a3dcda1b65f3999fa748a365b168e/macports-ports link text here] . These are apparently preferred over links of the form: [https://github.com/macports/macports-ports/commit/bd5d6800828a3dcda1b65f3999fa748a365b168e] and [https://github.com/macports/macports-ports/commit/bd5d6800828a3dcda1b65f3999fa748a365b168e link text here] . I would like to see this mentioned as examples at <https://trac.macports.org/wiki/WikiFormatting> and at <https://trac.macports.org/wiki/WikiFormatting#TracLinks> and at <https://trac.macports.org/wiki/TracLinks>. What will help me is mention of "GitHub commits" as well as "changesets". My underlying problem is that I file bug reports with just enough diligence to want to link to supporting information, and just often enough to remember that there is a right way to do it, but not often enough to remember what that right way is. If I don't hear objections, I'll go ahead and use the edit button on those pages, and trust that the wiki mechanisms will protect the content from too much of my damage. My thanks to everyone who maintains this machinery, and to the maintainers who swoop in and fix the things I file tickets about. I appreciate your work. —Jim DeLaHunt P.S. maybe I should add a HOWTO <https://trac.macports.org/wiki/howto> encouraging contributions to the wiki?
Re: [MacPorts] WikiFormatting modified
On 2020-09-25 17:55, Ryan Schmidt wrote: On Sep 25, 2020, at 18:50, MacPorts Wiki wrote: Page "WikiFormatting" was changed by JDLH Diff URL: <https://trac.macports.org/wiki/WikiFormatting?action=diff&version=7> Revision 7 Comment: Add example of GitHub commit link with abbreviation On Sep 25, 2020, at 19:33, MacPorts Wiki wrote: Page "TracLinks" was changed by JDLH Diff URL: <https://trac.macports.org/wiki/TracLinks?action=diff&version=8> Revision 8 Comment: Describe GitHub commit links including abbreviation in link text. New section "Links to MacPorts on GitHub" Jim, as I mentioned when you asked on the list a couple weeks ago, we should not edit the standard Trac documentation pages. Your changes will be lost the next time we update Trac: https://trac.edgewall.org/wiki/TracUpgrade#UpdatetheTracDocumentation We should delete your changed versions and mark the pages as read-only, which is apparently a thing that can be done and is done by default on new Trac installs these days. Thank you for your prompt reply, Ryan. (An example of the huge amount of attention and effort you put into MacPorts overall, for which we are all grateful.) I thought about this, and was about to reply to my macports-users message with a report on what I did and why. I think making these changes is the best way forward overall. I agree that these changes will be overwritten (not lost, they should be in the edit history) when the Trac documentation gets updated, probably when the next Trac upgrade gets deployed. But, 1) how long until that happens? From the edit history, it might be months or years. 2) until that happens, these changes benefit people who look at the wiki pages WikiFormatting and TracLinks. The other part of the change, which I wanted to make, is to create a new wiki page LocalTracGuideChanges . I apparently don't have authority to create this page. I would propose that this page has a record of all edits made to the Trac Guide wiki pages, so that when an upgrade happens and the installer overwrites these pages, we have a concise list from which to re-apply the customisations. LocalTracGuideChanges can link to Trac wiki diff URLs, or have the literal wiki text of the change. I wrote the changes so that they occupy complete lines of wiki text. That should make the changes easier to apply (though it doesn't protect us if Trac changes the content structure in the new version). The drawback to the way Trac structures the Guide is that the Trac software affords local ajustment of features, e.g. GitHub support, but does not afford local adjustment of the documentation describing those features. As an alternative, we could make our own pages WikiFormattingMacPorts and TracLinksMacPorts, with our customisations, and links to the Trac-supplied WikiFormatting and TracLinks pages. We could change the MacPorts Guide to refer to our own pages. I don't know if we can change the New Ticket window to refer to our own pages instead of the Trac standard pages. As another path to getting the word out about changeset references to GitHub, I also created PR#41 /Describe GitHub changeset links in 7.1.3 Trac Ticket Guidelines/ <https://github.com/macports/macports-guide/pull/41>. This mentions the GitHub changeset link syntax concisely. It would still be nice to link to some documentation somewhere with more detail. The current PR links to wiki page TracLinks. Maybe put all the detail somewhere in the Guide? So, while I understand your concern about the content getting overwritten, I think it's also important to put the content somewhere where people can see it. Trac has blocked off the best structures, so we are left with second-best. Cheers, —Jim DeLaHunt
Re: Protocol for updating wiki pages at trac.macports.org?
On 2020-09-08 09:14, Ryan Schmidt wrote: On Sep 7, 2020, at 18:24, Jim DeLaHunt wrote: Hello, MacPorts folks: Is there a protocol for making improvements to wiki pages at trac.macports.org beyond, "log in, press the edit button, and make the change"? I have a documentation improvement that will make my life easier, but I don't want to make a mess that someone needs to unwind. What I want to document is use of links of the form, [changeset:bd5d6800828a3dcda1b65f3999fa748a365b168e/macports-ports] and [changeset:bd5d6800828a3dcda1b65f3999fa748a365b168e/macports-ports link text here] . […snip…] Please do edit the wiki, but we probably should not edit pages (including WikiFormatting and TracLinks) that are part of the Trac default documentation, as I don't know what would happen when we update to a newer version of Trac. […snip…] I made some changes. See thread, /[MacPorts] WikiFormatting modified/, on Fri, 25 Sep 2020 19:55:25 -0500 and beyond, for a list of the changes, and the issues presented by that. <https://lists.macports.org/pipermail/macports-users/2020-September/048834.html> If we continue the discussion in that thread, then it's probably better not to continue this thread. Or vice versa. Best regards, —Jim DeLaHunt
What does "Warning: No port … found in index" mean?
Hi, folks: In doing my daily `sudo port selfupdate` on 16 November UTC, I encountered a warning which is new to me: "Warning: No port […portname…] found in index" In redoing `sudo port selfupdate`, this warning did not reoccur. What is the significance of this warning? What, if anything, should I do about it? The MacPorts output was something like this: % sudo port selfupdate Password: Warning: No port libiconv found in the index. Warning: No port libiconv found in the index. Warning: No port expat found in the index. Warning: No port libiconv found in the index. ---> Fetching archive for jbig2dec …[elided remaining 170 lines]… The set of ports mentioned in the warnings were: expat, fribidi, libiconv, libunistring, libxml2, p11-kit, pango, python_select, python3_select, urw-fonts, xorg-libsm, xorg-libX11, xorg-libXaw, xorg-libxcb, xorg-libXcursor, xorg-libXext, xorg-libXfixes, xorg-libXi, xorg-libXinerama, xorg-libXrandr, xorg-libXScrnSaver, xorg-libXt, xorg-libXxf86vm, xorg-xcb-util, xpm, xrender. I spot-checked a few of the ports. They are currently valid, installed ports, with one version active and one older version inactive. What is this "index"? Is this warning related to the upgrade of MacPorts base recently? What is the significance of this warning? What, if anything, should I do about it? Thank you for your insight, —Jim DeLaHunt
Re: What does "Warning: No port … found in index" mean?
On 2020-11-17 20:23, Ryan Schmidt wrote: On Nov 17, 2020, at 20:04, Jim DeLaHunt wrote: Hi, folks: In doing my daily `sudo port selfupdate` on 16 November UTC, I encountered a warning which is new to me: "Warning: No port […portname…] found in index" In redoing `sudo port selfupdate`, this warning did not reoccur. What is the significance of this warning? What, if anything, should I do about it? …[elided]… MacPorts uses a file on your computer called PortIndex to know what ports exist. When you run "port info" or "sudo port install" or any other command that refers to a port, MacPorts looks the port up in the index. When you sync or selfupdate, you receive updated Portfiles from our server, and you receive a PortIndex that we generated on our server for your OS version. Yesterday we had server problems that caused some of the PortIndex files we generated to be empty or incomplete, which would cause the warnings you experienced. The consequence is that you would not be able to install or upgrade those ports at that time. It has no effect on ports you have already installed. We solved the server problem later in the day, so if you synced or selfupdated after we fixed it, that would have given you a correct PortIndex again. See https://trac.macports.org/ticket/61507 Thank you for the explanation, Ryan. Thank you also for all the work you do to keep MacPorts running. Now, the error message and the explanation are in the list archives. If the problem happens again, maybe people will find this thread, and be informed. Best regards, —Jim DeLaHunt
trac.macports.org appears to be malfunctioning
https://trac.macports.org/ appears to be malfunctioning right now. When I take my browser to that page, I get a message: Warning: Authentication error. Please contact your administrator. Trac Error Unable to get database connection within 0 seconds. (OperationalError: could not connect to server: No such file or directory Is the server running locally and accepting connections on Unix domain socket "/var/run/postgresql/.s.PGSQL.5432"? ) I am unable to login. Clicking the "GitHub Login" link gives this error: Warning: Authentication error. Please contact your administrator. Error with navigation contributor "BrowserModule" Trac Error Unable to get database connection within 0 seconds. (OperationalError: could not connect to server: No such file or directory Is the server running locally and accepting connections on Unix domain socket "/var/run/postgresql/.s.PGSQL.5432"? ) Observed on Monday 2021-07-12 at 06:20h UTC (2021-07-11 at 23:20h PDT). It was working 2 hours ago. -- . --Jim DeLaHunt, j...@jdlh.com http://blog.jdlh.com/ (http://jdlh.com/) multilingual websites consultant 2201-1000 Beach Ave, Vancouver BC V6E 4M2, Canada Canada mobile +1-604-376-8953
Port clean, but just for destroot?
Is there a command like "port clean", but which just reverses the effect of "port destroot" but does not reverse the effect of "port build"? I am developing a portfile, and I'm at the stage where I debug the destroot and post-destroot activities. I want a way to be able to change the Portfile and retry "port destroot", without having to do the configure and build phases over again. Here is what has not worked: 1. Edit Portfile, then command "sudo port destroot myport". MacPorts notices that the Portfile has changed, does a "port clean", and then redoes the configure and build phases unnecessarily. 2. Edit Portfile, then command "sudo port -o destroot myport". MacPorts disregards the change to the Portfile, but also thinks that the destroot is complete, so does nothing. 3. Delete $(port work myport)/destroot/ dir, then command "sudo port destroot myport". MacPorts appears not to notice that the destroot/ dir is gone. 4. Edit Portfile, then command "sudo port clean --archive myport", then command "sudo port -o destroot myport". Same MacPorts behaviour as without the "port clean --archive". Is there a way to avoid the tedium of unnecessary configure and build phases? Best regards, —Jim DeLaHunt
Re: trac.macports.org appears to be malfunctioning
On 2021-07-12 17:23, Ryan Schmidt wrote: On Jul 12, 2021, at 01:22, Jim DeLaHunt wrote: https://trac.macports.org/ appears to be malfunctioning right now. When I take my browser to that page, I get a message: Warning: Authentication error. Please contact your administrator. Trac Error Unable to get database connection within 0 seconds. (OperationalError: could not connect to server: No such file or directory Is the server running locally and accepting connections on Unix domain socket "/var/run/postgresql/.s.PGSQL.5432"? ) It seems to be working correctly for me when I try it now. Is it working for you as well? Yes, Ryan. When I tried trac.macports.org again, some 8 hours after the above report, and about 8 hours ago, it was working again. Thank you for checking.
Re: Port clean, but just for destroot?
On 2021-07-12 17:21, Ryan Schmidt wrote: Correct, it's best to delete $(port work myport)/destroot prior to re-attempting the destroot phase, since portfile authors do not typically expect a destroot phase to be re-attempted and may not have written such destroot phases to work correctly if you do. If the destroot phase did not error but has instead been marked as completed, you can unmark that completion by editing the file $(port work myport)/.macports.myport.state and delete the line that reads "target: org.macports.destroot". I do these steps often. Awesome, Ryan! That is exactly what I was looking for. port -o -k install myport is my friend right now. bbedit $(port work myport)/.macports.myport.state is my new friend. Thank you! —Jim DeLaHunt
Re: Can?t Install FFMpeg
On 2021-08-19 21:16 -0700, Richard Fairbanks wrote: < 3.5 GHz, 6-Core Mac Pro (MacPro6,1) with 16GB RAM and D700 GPUs, running macOS 10.14.6 > Greetings, folks! I just updated to MacPorts-2.7.1-10.14-Mojave.pkg, default install. Terminal calls and results appended below sig. Any advice would be appreciated! Blessings, and thank you!, Richard Fairbanks In Terminal $ sudo port install ffmpeg Error: Unable to execute port: couldn't open "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_multimedia_ffmpeg/ffmpeg/work/.macports.ffmpeg.state": permission denied $ sudo port clean ffmpeg $ sudo port install ffmpeg Computing dependencies for ffmpeg The following dependencies will be installed: Continue? [Y/n]: y It's a pity you cut out the list of dependencies to be installed. The problem seems to have happened there. Error: See /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_multimedia_XviD/XviD/main.log for details. Error: Follow https://guide.macports.org/#project.tickets if you believe there is a bug. Error: Processing of port ffmpeg failed It looks like port "ffmpeg" depends on port "XviD", and the error occurred when trying to install port "XviD". So, think of this as a problem installing XviD rather than a problem installing ffmpeg. Try doing `sudo port install XviD` by itself. Get that to work. Then return to `sudo port install ffmpeg`. $ port clean --dist ffmpeg ---> Cleaning ffmpeg Error: error deleting "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_multimedia_ffmpeg/ffmpeg": not owner Error: error deleting "/opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_multimedia_ffmpeg/ffmpeg": not owner # It looks like you did not use `sudo` when cleaning ffmpeg. Perhaps try again with `sudo`? The full, above-referenced log file, XviD/main.log, states: version:1 :debug:main Starting logging for XviD @1.3.7_0 :debug:sysinfo macOS 10.14.6 (darwin/18.7.0) arch i386 :debug:sysinfo MacPorts 2.7.1 :debug:sysinfo Xcode 11.3.1 :debug:sysinfo SDK 10.14 :debug:sysinfo MACOSX_DEPLOYMENT_TARGET: 10.14 :debug:main dropping privileges: euid changed to 502, egid changed to 501. :error:main See /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_multimedia_XviD/XviD/main.log for details. ?> the last line ?:error:main See?.?.?.?? refers to this same file! So, XviD/main.log is only 9 lines long? That is interesting. That says it failed soon after starting the task. It's not surprising that the final line of XviD/main.log mentions XviD/main.log. As I understand it, the system writes to the log every message it prints on the terminal. You should expect to see every line from the terminal repeated in the log file. I hope this helps you get a step farther, —Jim DeLaHunt
requested_variants='+universal' for port with no +universal variant?
Hello, folks: I am working through the Migration[1] procedure after upgrading my macOS version. I made a list of my installed ports using `port -qv installed`. Curiously, a number of the ports in that list include the notation `requested_variants='+universal'`, even though the port appears to have no +universal variant. For example, bison @3.7.6_1+universal requested_variants='+universal' platform='darwin 17' archs='x86_64' date='2021-07-04T14:08:44-0700' bison @3.7.6_2+universal (active) requested_variants='+universal' platform='darwin 17' archs='x86_64' date='2021-08-12T18:44:11-0700' But there appars to be no +universal variant: % port info bison bison @3.7.6_2 (devel) Sub-ports: bison-runtime Description: Bison is a general-purpose parser generator that converts an annotated context-free grammar into a deterministic LR or generalized LR (GLR) parser employing LALR(1) parser tables. As an experimental feature, Bison can also generate IELR(1) or canonical LR(1) parser tables. Once you are proficient with Bison, you can use it to develop a wide range of language parsers, from those used in simple desk calculators to complex programming languages. Homepage: https://www.gnu.org/software/bison Extract Dependencies: xz Library Dependencies: gettext, libiconv, m4 Runtime Dependencies: bison-runtime Platforms: darwin License: (GPL-3+ or Permissive) Maintainers: none % port info --variants bison variants: Perhaps these +universal request are a relic of the distant past? I have migrated this MacPorts installation forward through several OS versions and multiple computers. It might be that some data originated on a PowerPC mac long ago, when +universal was significant. I have on MacPorts 2.7.1 and macOS 10.14 Mojave (just upgrade from 10.13 High Sierra) and a 7-year-old Mac with an intel CPU. The buildUniversal wiki page[2] seems to be 8 years old and not relevant to my situation. Q1. What does a `+universal` variant request do, on MacPorts 2.7.1 and macOS 10.14 Mojave and a Mac with an intel CPU, if the port does not advertise a `+universal` variant? Q2. Is there a `+universal` variant which is built in to MacPorts, even if the port does not advertise a `+universal` variant? MacPorts Guide, 5. Portfile Reference, 5.5.1. User-Selected Variants[3] seems to imply "yes". Q3. Are there ports which have a `+universal` variant which is important for my system? How do I find this out, and understand the significance? Q4. Should I edit my list of installed ports to remove the `+universal` from the port identifier and requested_variants keyword? For instance, should I change the bison entry from: bison @3.7.6_1+universal requested_variants='+universal' platform='darwin 17' archs='x86_64' date='2021-07-04T14:08:44-0700' bison @3.7.6_2+universal (active) requested_variants='+universal' platform='darwin 17' archs='x86_64' date='2021-08-12T18:44:11-0700' into: bison @3.7.6_1 requested_variants='' platform='darwin 17' archs='x86_64' date='2021-07-04T14:08:44-0700' bison @3.7.6_2 (active) requested_variants='' platform='darwin 17' archs='x86_64' date='2021-08-12T18:44:11-0700' Note: this list of installed ports had some entries with `archs='i386 x86_64'`. I already got rid of the `i386` arch entry. [1] https://trac.macports.org/wiki/Migration [2] https://trac.macports.org/wiki/howto/buildUniversal [3] https://guide.macports.org/chunked/reference.variants.html Thank you in advance for your help. —Jim DeLaHunt
During Migration to Arm64 mac, should I null out archs='x86_64' from installed ports list?
Hello, MacPorts folks: I am following the MacPorts wiki "Migration"[1] instructions as I move from a macOS 10.14.6 Mojave machine with an intel CPU to a macOS 13.1 Monterey machine with an arm64 CPU. I got stuck with a bug in the tiff port, which fails during destroot under the +universal variant. I opened a ticket[2] against tiff +universal on arm64, but that is not my question here. I don't know why MacPorts was trying to install tiff with the +universal variant. I am following the Migration instructions. They have me make a list of installed ports using `port -qv installed`. None of these entries mention "requested_variants='+universal'". 91% have an empty string for requested variants. 9% request some other variant. However, two-thirds mention "archs='x86_64'", while the other one-third mention "archs='noarch'", and none have empty strings or some other value for "archs". I use the restore_ports.tcl script to install the ports on the new computer. Here are four representative entries from my list of installed ports: aalib @1.4rc5_5 (active) requested_variants='' platform='darwin 18' archs='x86_64' date='2021-08-30T13:16:05-0700' abcde @2.9.3_1 (active) requested_variants='' platform='darwin 18' archs='noarch' date='2022-01-23T21:52:02-0800' apr-util @1.6.1_2+no_bdb (active) requested_variants='+no_bdb' platform='darwin 18' archs='x86_64' date='2021-08-30T13:16:21-0700' aspell @0.60.8_1 (active) requested_variants='-nls' platform='darwin 18' archs='x86_64' date='2021-08-30T13:34:34-0700' Might the presence of "archs='x86_64'" cause the restore_ports.tcl script to ask for +universal variants on the new computer? Should I perhaps null out the value "x86_64" from the archs entries in my installed ports list? i.e. turn them into "archs='' "? Or should I replace them with the value "arm64"? I don't see any mention in the Migration instructions about modifying "archs" entries when migrating from one architecture to another. [1] <https://trac.macports.org/wiki/Migration> [2] <https://trac.macports.org/ticket/64933>, tiff@4.3.0_0+universal: Failed to destroot tiff, "libtiff-4.pc differs" -- .--Jim DeLaHunt, Vancouver, Canada
Re: During Migration to Arm64 mac, should I null out archs='x86_64' from installed ports list?
On 2022-04-11 19:10, Jim DeLaHunt wrote: Hello, MacPorts folks: I am following the MacPorts wiki "Migration"[1] instructions as I move from a macOS 10.14.6 Mojave machine with an intel CPU to a macOS 13.1 Monterey machine with an arm64 CPU.… Ahem. The new machine is of course macOS 12.3.1 Monterey, not 13.1. You can stop polling Software Update looking for macOS 13. :-) I don't know why MacPorts was trying to install tiff with the +universal variant.… I found out the cause of the +universal variant. My list of installed ports includes port qt4-mac. This port does not support arm64, so it complies for x86_64. Thus it forces all its dependencies to be re-installed with the +universal variant. This is a surprisingly long list, and includes port tiff +universal. I no longer need qt4-mac, so I dropped it from the list of ports to restore. After this, the restore_ports.tcl script no longer installed +universal variants. Here are four representative entries from my list of installed ports: aalib @1.4rc5_5 (active) requested_variants='' platform='darwin 18' archs='x86_64' date='2021-08-30T13:16:05-0700' abcde @2.9.3_1 (active) requested_variants='' platform='darwin 18' archs='noarch' date='2022-01-23T21:52:02-0800' apr-util @1.6.1_2+no_bdb (active) requested_variants='+no_bdb' platform='darwin 18' archs='x86_64' date='2021-08-30T13:16:21-0700' aspell @0.60.8_1 (active) requested_variants='-nls' platform='darwin 18' archs='x86_64' date='2021-08-30T13:34:34-0700' Might the presence of "archs='x86_64'" cause the restore_ports.tcl script to ask for +universal variants on the new computer? Should I perhaps null out the value "x86_64" from the archs entries in my installed ports list? i.e. turn them into "archs='' "? Or should I replace them with the value "arm64"? Based on Ryan's helpful response on this thread, I think the answers to these questions are "No" and "No". The values for "archs" (and for "platform", which does not match the destination systems's 'darwin 21') are no obstacle to the restore_ports.tcl script succeeding with its migration. Thanks to everyone for the help. -- .--Jim DeLaHunt, Vancouver, Canada
Should I expect a +quartz variant to propagate to dependencies, and overrule existing variants?
Should I expect a +quartz variant to propagate to dependencies, and overrule existing variants? I just tried to `install gimp +quartz`. This failed several times, each time with errors about some recursive dependency of gimp requiring its own dependency to be installed with a +quartz variant, but the port was already installed without the +quartz variant` commands explicitly. The specific ports in question are: gimp +quartz, which depends on gimp-lqr-plugin, which depends on gimp2 +quartz — but it was installed without that variant, which depends on gtk-osx-application-gtk2, and depends on gtk2 +quartz — but it was installed without that variant, and depends on py27-pygtk +quartz — but it was installed without that variant, which depends on libglade2, which also depends on gtk2 +quartz So concretely, install gimp +quartz failed because gimp2 was installed without +quartz. A manual install gimp2 +quartz failed because gtk2 was installed without +quartz. A manual install gtk2 +quartz succeeded, but led to 5 broken ports. Rebuilding those broken ports failed at py27-pygtk because an in-progress build of gimp2 had conflicting variants "+python27" vs "+python27+quartz". A clean of gimp2, followed by a second manual install gimp2 +quartz succeeded, but led to 4 broken ports. Rebuilding those broken ports failed at py27-pygtk because gtk2 was installed *with* +quartz (actually, without the conflicting variant +x11). An uninstall py27-pygtk (despite gimp2 depending on it), followed by a clean py27-pygtk, succeeded. A manual install py27-pygtk +quartz succeeded, but led to 2 broken ports. Rebuilding those broken ports succeeded. Thus I succeeded in fumbling my way through installing gimp +quartz despite dependencies already present with the wrong variants, but it was a bit messy and confusing. Should I expect MacPorts to do a better job with this situation? If so, maybe I should file a ticket against some of these ports, to see if portfile changes would avoid the problems. Thank you for your advice! —Jim DeLaHunt -- .--Jim DeLaHunt, Vancouver, Canada
Re: Should I expect a +quartz variant to propagate to dependencies, and overrule existing variants?
Thank you for the reply, Ryan. This is very helpful. On 2022-06-02 19:33, Ryan Schmidt wrote: On Jun 1, 2022, at 17:31, Jim DeLaHunt wrote: Should I expect a +quartz variant to propagate to dependencies, and overrule existing variants? Variants specified on the command line when installing a port propagate to any dependencies that have not yet been installed. They do not propagate to any dependencies that have already been installed. That is good to know, thanks. I looked at the Guide to see if this behaviour was described. In my opinion it is not described adequately. I've opened a ticket against the Guide, " Guide 3.2.1: Say that variant specification on port install does not overrule existing ports" <https://trac.macports.org/ticket/65299>. You can add a variant to an already-installed port by using "sudo port upgrade --enforce-dependencies someport +somevariant". Clever! I see that this is documented in <https://guide.macports.org/#using.port.upgrade>. I had not noticed that. I guess I have not read the Guide diligently. …Thus I succeeded in fumbling my way through installing gimp +quartz despite dependencies already present with the wrong variants, but it was a bit messy and confusing. Should I expect MacPorts to do a better job with this situation? If so, maybe I should file a ticket against some of these ports, to see if portfile changes would avoid the problems. This undesirable experience is why we recommend users choose whether to use +x11 or +quartz before installing any ports, or uninstall all ports and reinstall them if changing one's mind after having installed ports. Interesting! Where is this advice documented? I certainly did not know it before. (But them, I guess I have not read the Guide diligently.) The place where these instructions would have done me good is in the Migration instructions: <https://trac.macports.org/wiki/Migration>. I just looked. I have 27 ports with +x11 variants specified. 4 of those ports have +quartz+x11: cairo, cairomm, pango, pangomm. For all 4 of them, +x11 and +quartz appear to be default variants, so I suppose they can coexist. But that leaves me with 23 ports with +x11 to deal with. At least some of them (e.g. ffmpeg) have no +quartz variant. Can such ports coexist as +x11 variants with the rest of a collection of +quartz variant ports? I see my port gtk3 is installed as +x11 but not as +quartz. I suspect that is not what I want. Thank you for the heads-up. Thank you again for the explanation. Best regards, —Jim DeLaHunt
Re: Disk capacity unchanged after deleting 21 GB MacPorts
Jerry: On 2024-11-26 12:03, list_email--- via macports-users wrote: As a first step in re-installing MacPorts (long story), I ran $ sudo port -fp uninstall installed ...Before uninstalling, the Finder indicated that /opt/local contained 21 GB. After, /opt/local was nearly empty, as expected. I completed the steps indicated to complete the uninstallation. I happened to check the “Used” quantity, as indicated by Finder on Get Info on my boot volume (which contained /opt/local) before uninstalling, and again after uninstalling. I expected to see this quantity reduced by 21 GB. But there was no change! Why was the “Used” number unchanged after deleting 21 GB? I am not an expert and don't have a definitive answer. But my first guess is: the APFS file system, and snapshots. If something made a snapshot of the file system contents before you deleted everything in /opt/local, then maybe those file system contents are still present and occupying space in the snapshot. Time Machine is one system which can create snapshots; there are probably others. And, you should ask yourself the question, what exactly is Finder's formula for its "Used" quantity? Howard Oakley's excellent Eclectic Light Company blog has a steady stream of interesting details on the behaviour of Macs and macOS. The post, "Explainer: Disk free space" from 2021-12-04 <https://eclecticlight.co/2021/12/04/explainer-disk-free-space/> may answer your question. There might be more insight in the blog posts tagged with "free space" <https://eclecticlight.co/tag/free-space/>. TL;DR: File systems aren't as simple as they used to be. I hope this is helpful, --Jim DeLaHunt
Re: What, if homebrew is the only choice?
Hello, Christoph: On 2025-07-22 00:48, Christoph Kukulies via macports-users wrote: I'm in the situation - maybe there is a solution using macports - that I need the | Toolchain [*] | | -- | | Build | Host| Target | | -- | ...[detail left out]... | macOS (x86_64) | macOS (x86_64) | aarch64-none-elf | | macOS (x86_64) | macOS (x86_64) | arm-none-eabi <<<<<<<<<<<<< |<<<<*** | macOS (Apple silicon) | macOS (Apple silicon) | aarch64-none-elf | ...[detail left out]... | -- | toolchain. I'm not entirely sure I understand what you are asking. Let me see if I can figure it out. You include this big table, but from the "<<<" arrow, I think you are asking, how do I build the "gnu-devtools-for-arm" project for just the one combination of: Build: macOS (x86_64), Host: macOS (x86_64), Target: arm-none-eabi And, As of https://gitlab.arm.com/tooling/gnu-devtools-for-arm/-/blob/main/ README.md homebrew is heavily involved. What choices are there? You see that the "gnu-devtools-for-arm" project supplies build instructions, which require you to gather a lot of tools, from autoconf to zlib1g-dev. But the macOS part of the instructions only say how to gather those tools using homebrew. I think you are asking, can I gather those tools using MacPorts? If so, how? If I understand you correctly, then I think the answer is: Maybe, probably, but you will have to figure out how. Maybe there will be some obstacles which you have to figure out. You are in the same situation as the person who wrote those instructions for macOS. Except they had to figure out how to gather the tools using homebrew, and you have to figure out how to gather the tools musing MacPorts. I would suggest you go through the list of homebrew recipes in the instructions. See which tools each of those recipes installs. Find out which port in MacPorts installs the same tool. Install that port from MacPorts. When you have installed all the tools, try to do the build. If it works, great. If it doesn't work, then you have a puzzle to solve. Does that help? Best regards, --Jim DeLaHunt
