Re: "port upgrade" error message usability
From a general usability and documentation standpoint (without
attention beyond the average user, as confronting that error seems to be
from the other conversation), the MacPorts Guide addresses this quite well:
* https://guide.macports.org/#using.common-tasks.upgrading
* https://guide.macports.org/#using.port.upgrade
The guide has been indispensable in easily creating my regular install
maintenance scripts and workflows.
Thomas R. Murphy (thomas.russell.mur...@case.edu, tr...@case.edu)
GPG Key ID: 959D48BF
On 2022-01-30 02:24:40, Andrew Janke wrote:
Hi, MacPorts developers,
Long-time Homebrew user and recent MacPorts convert here.
Minor usability issue with the `port` program, I think: I suspect that
a common operation for regular MacPorts users to do is "upgrade all my
stuff to the latest version".
I tried doing this with `port selfupdate`; `port upgrade`, and got
this error message:
[~] $ sudo port selfupdate
---> Updating MacPorts base sources using rsync
MacPorts base version 2.7.1 installed,
MacPorts base version 2.7.1 downloaded.
---> Updating the ports tree
---> MacPorts base is already the latest version
The ports tree has been updated. To upgrade your installed ports, you
should run
port upgrade outdated
[~] $ sudo port upgrade
Can't map the URL 'file://.' to a port description file ("Could not
find Portfile in /Users/janke").
Please verify that the directory and portfile syntax are correct.
To use the current port, you must be in a port's directory.
[~] $
I'm a dev with 25 years of coding and sysadmin experience, and I don't
know what to do with that error message. I dunno what a regular user
is supposed to do with that. (Yes, I saw the "To upgrade your
installed ports" output from the selfupdate command, but still.)
Maybe the error message here could be modified to include a "maybe you
meant `port upgrade outdated`" message or something like that? Where's
the 'file://'" coming from, anyway? Does `port upgrade` operate on
some port definition found in the current working directory by
default? I did not provide a URL as an input to the `port upgrade`
command, so it's a little unexpected that I got an error complaining
about a URL here.
Cheers,
Andrew
OpenPGP_signature
Description: OpenPGP digital signature
Re: Freenode IRC
As continued malicious behavior continues on the current network for #macports, I'm quite interested in seeing a move for the project. Thomas R. Murphy (thomas.russell.mur...@case.edu, tr...@case.edu) GPG Key ID: 959D48BF On 2021-05-19 21:18:01, Joshua Root wrote: > On 2021-5-20 03:51 , Mark Anderson wrote: >> Freenode is currently in the process of self destruction. We really >> should move. > > I sent a project registration request to Libera Chat so we have that > option. Whatever we do, someone needs to hang around Freenode for > quite some time to come in order to point people to the new place. > > - Josh OpenPGP_signature Description: OpenPGP digital signature
Re: WTB Qt 5.12LTS (port:qt512) (attn mcalhoun)
I see this thread from 2016 re: 5.6 LTS vs 5.7: https://lists.macports.org/pipermail/macports-users/2016-September/041450.html Thomas R. Murphy (thomas.russell.mur...@case.edu, tr...@case.edu) GPG Key ID: 959D48BF On 2019-11-17 09:30:36, Marcus Calhoun-Lopez wrote: > >> On Nov 17, 2019, at 8:09 AM, René J.V. Bertin wrote: >> >> On Sunday November 17 2019 07:03:50 Marcus Calhoun-Lopez wrote: >> >>> Unfortunately, I cannot find the reference, but the consensus was >>> essentially: >>> if the newest version works on all the platforms that the LTS does, then >>> there is no reason to keep another Qt port around. >> Hmmm, I think there is. There will probably come a time when the current >> version drops support for OS versions, which will then depend on the LTS >> version for bug fixes and security backports. If the timeline is going to be >> the same as with 5.9LTS that means the OS versions concerned could be >> blocked on 5.13 and/or 5.14 . > I am very sorry I cannot find the reference because this is the same argument > I made. > (I cannot remember if this discussion was on the mailing list, the trac, or > the GitHub comments.) > The rebuttal was that we can port any such changes to the newer Qt. > Just to be clear, this was not my argument, but I went with the consensus. > >>>> And in general, suppose it did exist: how good is the support for >>>> installing port:qt51x manually and then getting the corresponding >>>> dependencies on the correct, corresponding Qt version? >>> If a user, for example, on macOS Mojave installs qt511-qtbase, then all >>> ports that use the qt5 PG should correctly recognize it is a valid Qt5 port >>> that satisfies the dependencies. >> Yes, but will they also pull in qt511-qtwhatever automatically? I know I >> must have given this thought for my own Qt5 ports, but never tested it >> thoroughly as far as I can remember. > Yes, it should pull in all of the necessary dependencies like > qt511-qtwhatever. > >> BTW, I'm getting reports of Qt 5.9.8 build errors on the latest 10.15 OS >> version, errors which suggest C++ dialect issues despite the use of >> `-std=c++11z`. >> >> R. > Thank you for the heads-up. > > -Marcus signature.asc Description: OpenPGP digital signature
"Error: poppler cannot be built while another version of poppler is active." Why?
Is there a reason poppler is setup to disallow in-place updating? This essentially makes port upgrade outdatedrequire manual intervention when a rev-bump of poppler comes by. The end of the build log indicates that this is an intentional prebuild check: :debug:configure Executing proc-pre-org.macports.configure-configure-0 :error:configure poppler cannot be built while another version of poppler is active. :error:configure Please forcibly deactivate the existing copy of poppler, e.g. by running: :error:configure sudo port -f deactivate poppler :error:configure Then try again. :error:configure Failed to configure poppler: poppler is active :debug:configure Error code: NONE -- Thomas R. Murphy (thomas.russell.mur...@case.edu, tr...@case.edu) GPG Key ID: 959D48BF signature.asc Description: OpenPGP digital signature
Re: Upgrade cctools unexpectedly failing
Belatedly created ticket: https://trac.macports.org/ticket/59342 Thomas R. Murphy (thomas.russell.mur...@case.edu, tr...@case.edu) GPG Key ID: 959D48BF On 2019-10-07 23:50:54, Joshua Root wrote: > Interesting, what we're setting in the environment is being ignored and > the -isysroot flag for the nonexistent path is added. I can't reproduce > the problem with default llvm80 variant. I wonder if the SDK path is > baked into llvm-config-mp-7.0? > > Please file a ticket. > > - Josh > > On 2019-10-8 15:37 , Thomas R. Murphy wrote: >> Full log attached. Thanks for looking. >> >> Thomas R. Murphy (thomas.russell.mur...@case.edu, tr...@case.edu) >> GPG Key ID: 959D48BF >> On 2019-10-07 23:30:00, Joshua Root wrote: >>> On 2019-10-8 15:25 , Aaron Madlon-Kay wrote: >>>>> [-Wmissing-sysroot] >>>>> :info:build clang: warning: no such sysroot directory: >>>>> '/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk' >>>> I had the same errors with poppler. I fixed it by copying the >>>> MacOSX10.14.sdk from Xcode 10 into my Xcode 11 installation. >>> There's no way of knowing if it's the same problem without the full log, >>> but I doubt it. Poppler's failure to find the SDK is specific to >>> gobject-introspection. Most ports should be able to use the 10.14 SDK >>> provided by the Command Line Tools. >>> >>> - Josh signature.asc Description: OpenPGP digital signature
Upgrade cctools unexpectedly failing
Trying to upgrade cctools 921_3 < 921_4 macOS 10.14.6 (10G103), Xcode 11.0 (11A420a). I opened Xcode and installed the additional tools as prompted to no effect. Output message snippet from main.log for the build: :info:build /usr/bin/clang -Os -std=gnu99 -Os -DLTO_SUPPORT -g -I../../include -Wall -D_MACH_I386_THREAD_STATUS_FPSTATE_ LEGACY_FIELD_NAMES_ -D_ARCHITECTURE_I386_FPU_FPSTATE_LEGACY_FIELD_NAMES_ -I/opt/local/include -I/opt/local/var/macports/ build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_devel_cctools/cctools/work/cctools-921/. ./ld64-409.12/src/abstraction -I/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release _tarballs_ports_devel_cctools/cctools/work/cctools-921/../ld64-409.12/src/other -I/opt/local/var/macports/build/_opt_loc al_var_macports_sources_rsync.macports.org_release_tarballs_ports_devel_cctools/cctools/work/cctools-921/include -arch x 86_64 -I/opt/local/libexec/llvm-7.0/include -pipe -Os -isysroot/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk -fPIC -Werror=date-time -Werror=unguarded-availability-new -Wall -Wextra -Wno-unused-parameter -Wwrite-strings -Wmissing-field-initializers -pedantic -Wno-long-long -Wcovered-switch-default -Wdelete-non-virtual-dtor -Wstring-conversion -DNDEBUG -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -c -o ./rnd.o ../rnd.c :info:build clang: warning: no such sysroot directory: '/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk' [-Wmissing-sysroot] :info:build clang: warning: no such sysroot directory: '/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk' [-Wmissing-sysroot] :info:build clang: warning: no such sysroot directory: '/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk' [-Wmissing-sysroot] :info:build clang: warning: no such sysroot directory: '/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk' [-Wmissing-sysroot] :info:build clang: warning: no such sysroot directory: '/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk' [-Wmissing-sysroot] :info:build clang: warning: no such sysroot directory: '/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk' [-Wmissing-sysroot] :info:build clang: warning: no such sysroot directory: '/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk' [-Wmissing-sysroot] :info:build clang: warning: no such sysroot directory: '/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk' [-Wmissing-sysroot] :info:build clang: warning: no such sysroot directory: '/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk' [-Wmissing-sysroot] :info:build clang: warning: no such sysroot directory: '/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk' [-Wmissing-sysroot] :info:build clang: warning: no such sysroot directory: '/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk' [-Wmissing-sysroot] :info:build clang: warning: no such sysroot directory: '/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk' [-Wmissing-sysroot] :info:build ../errors.c:24:10: fatal error: 'stdlib.h' file not found :info:build #include :info:build ^~ :info:build ../allocate.c:23:10: fatal error: 'stdlib.h' file not found :info:build #include :info:build ^~ :info:build ../allocate.c:23:10: fatal error: 'stdlib.h' file not found :info:build #include :info:build ^~ :info:build ../arch.c:24:10: fatal error: 'stdio.h' file not found :info:build #include "stdio.h" :info:build ^ :info:build ../bytesex.c:185:10: fatal error: 'string.h' file not found :info:build #include :info:build ^~ :info:build ../errors.c:24:10: fatal error: 'stdlib.h' file not found :info:build #include :info:build ^~ :info:build ../execute.c:24:10: fatal error: 'libc.h' file not found :info:build #include /* first to get rid of pre-comp warning */ :info:build ^~~~ :info:build ../arch.c:24:10: fatal error: 'stdio.h' file not found :info:build #include "stdio.h" :info:build ^ :info:build ../execute.c:24:10: fatal error: 'libc.h' file not found :info:build #include /* first to get rid of pre-comp warning */ :info:b
Re: Default language for GIMP installed by MacPorts
Sounds about right. Doing some experimentation, setting en_US and restarting with Arabic as the second language results in the menus being correct, but with everything formatted in RTL format. Adding English (UK) to my list of languages only in the /second/ rank corrects this. It also makes the interface usable if System Language is re-enabled, since that's what seems to actually take priority. Easy enough to work around, once the effects of system settings are known. Thomas R. Murphy (thomas.russell.mur...@case.edu, tr...@case.edu) GPG Key ID: 959D48BF On 2019-10-03 19:07:25, Andrew Janke wrote: > > On 10/3/19 8:00 PM, Thomas R. Murphy wrote: >> Hello Macports Dev, >> >> I just got around to trying to use my MacPorts intstall of GIMP (gimp >> @2.10.12_0) and encountered the slight difficulty of it starting in >> Arabic using the default "system language" setting. I started it from >> the command line with export LANG=en_US.UTF-8 and switched it to default >> to en_US. My system language settings are "English (US) — Primary" with >> a customized region (for my desired date/time formatting) with Arabic, >> Khmer, and Urdu as alternates in that order (from who knows what >> keyboard fooling around I tried). Any idea what caused GIMP to skip down >> to my second language? >> > I suspect this has to do with how the GNU gettext internationalization > library is being used by GIMP. I've seen this happen with other programs. > > gettext uses the following priorities for choosing a localized translation: > > 1. A localized translation in your primary language > 2. A localized translation in one of your alternate languages, in > priority order > 3. The original language of the program text > > Probably what is happening is that GIMP provides localized translation > files for one or more languages in your alternate language list, but > does not define an English localization translation file (instead > relying on the fallback behavior to get English). In that case, gettext > will find that alternate-language localization in step 2, and it will > take precedence over the default-language fallback of English. > > This could be fixed at the GIMP level by having it provide a dummy empty > localization file for English, which would be matched to your primary > language in step 1. Alternately, your $LANG workaround is effective. > > Cheers, > Andrew
Default language for GIMP installed by MacPorts
Hello Macports Dev, I just got around to trying to use my MacPorts intstall of GIMP (gimp @2.10.12_0) and encountered the slight difficulty of it starting in Arabic using the default "system language" setting. I started it from the command line with export LANG=en_US.UTF-8 and switched it to default to en_US. My system language settings are "English (US) — Primary" with a customized region (for my desired date/time formatting) with Arabic, Khmer, and Urdu as alternates in that order (from who knows what keyboard fooling around I tried). Any idea what caused GIMP to skip down to my second language? -- Thomas R. Murphy (thomas.russell.mur...@case.edu, tr...@case.edu) GPG Key ID: 959D48BF signature.asc Description: OpenPGP digital signature
Re: GSoC 2018: Interested in Improving startup item code
To throw some lack of XCode experience out there, I've been running with only the command line tools installed for a while. I get the warning about possibly failing to build ports each time* I try to install/upgrade something, but it's still working just fine. However, I have had the whole of XCode installed at some point. * Warning text: former is once per run, latter is on every port being processed Warning: xcodebuild exists but failed to execute Warning: Xcode does not appear to be installed; most ports will likely fail to build. Thomas R. Murphy (thomas.russell.mur...@case.edu, tr...@case.edu) GPG Key ID: 959D48BF On 2018-02-22 22:18:18, Jackson Isaac wrote: > On Sun, Feb 18, 2018 at 12:07 AM, Abhishek Singh Bisht > wrote: >> Hi Jackson, >> >> Thanks for taking time, I appreciate it. Will proceed as you said. Also i >> was thinking wether or not it’d be feasible to remove all dependencies on >> Xcode? I mean shouldn’t the command line tools suffice? I read that some >> ports mandatorily require Xcode, but is there any possibility? >> > Yes Xcode-clt should suffice for most of the ports. Some ports may > depend on XCode itself though. > > I am not sure if any port can be built even without xcode itself. But > anyways we would like to minimize the dependency on the XCode package > as such which is 6-7GB for every update they release. > > Probably Clemens can share some insights ? > signature.asc Description: OpenPGP digital signature
Re: [MacPorts] Migration modified
Re-sending to have the message go to the list: Hello all, As a long-time user of MacPorts, I've migrated a few times a memory from one of those times was how disastrously poorly the migration went. Be it my fault in following the directions or a problem with my setup, I ended up hard-uninstalling everything and reinstalling ports from memory/as I re-discovered needing them. Since then, I have actively sought out this set of instructions. My edits were to bring the instructions into a proactive position, knowing that the installed ports need to be logged and reinstalled, versus a reactive position, having MacPorts not work and direct you to the wiki page. Better documenting on the Migration wiki page to express the full context of the instructions would be useful. It may also be valuable to include at least a link to the Migration page as an "Uncommon Tasks" relative to https://guide.macports.org/chunked/using.common-tasks.html . This would give users more exposure to the process *before* they ever needed to use it rather than discovering additional effort as (some?) ports are broken and MacPorts requires a full reinstall to get a functioning system back. Of course, it would be best if MacPorts could handle the majority of the OS-change work and the documentation was almost as short as "Upgrade OS, run `sudo port `, and let everything reinstall." Meanwhile, while writing this email, I found an additional deficiency in the current process in which re-setting the requested status doesn't work reliably. I look forward to continuing to improve the documentation once the overall structure of this page is decided on. Thomas R. Murphy (thomas.russell.mur...@case.edu, tr...@case.edu) GPG Key ID: 959D48BF On 2017-08-29 12:09:14, Umesh Singla wrote: > Hi > > On Tue, Aug 29, 2017 at 8:30 PM, Rainer Müller <mailto:rai...@macports.org>> wrote: > > On 2017-08-29 16:41, Arno Hautala wrote: > > Just as a message is sent to the user list when a new MacPorts > version > > is posted, a message could be sent when a new OS is released that > > reminds users that migration will be required. > > Such a message would probably only reach a small amount of users... > > Before we discuss more workarounds, I still see no reason why it would > be required to run these steps before upgrading the OS. Otherwise I > would prefer to go back to the old order of steps that always work and > are less confusing. > > > Following the use case which it serves currently, I agree that it is > best to go with the original sequence of steps. > Probably, thomasrussellmurphy reinstalled the complete OS and the > guide didn't serve his purpose. > > - Umesh signature.asc Description: OpenPGP digital signature
