Re: MacPorts 2.7.0 has been released
On May 20, 2021, at 17:22, raf wrote:
>
> When I disable /usr/lib/libsqlite3.dylib by renaming it,
> the error changes to a symbol lookup failure:
>
>> port help
> dlopen(/opt/local/libexec/macports/lib/macports1.0/MacPorts.dylib, 6): can't
> resolve symbol _kDADiskDescriptionMediaBSDNameKey in
> /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation because
> dependent dylib #2 could not be loaded in
> /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation
> while executing
> "load /opt/local/libexec/macports/lib/macports1.0/MacPorts.dylib"
> ("package ifneeded macports 1.0" script)
> invoked from within
> "package require macports"
> (file "/opt/local/bin/port" line 46)
>
> Oops. And now PAM/su/sudo are now broken. I shouldn't have done that. :-)
>
Correct. Don't modify things in /usr/lib or other locations reserved for use by
Apple. OS X 10.11 and later will prevent you from doing so via System Integrity
Protection. On earlier OS versions, you'll just have to remember not to touch
those parts of the system.
Re: Command line glob expansion broken-ish
On May 20, 2021, at 08:28, Bill Cole wrote: > 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...) I don't think it's necessarily about efficiency. It's just how MacPorts works, how it has always worked. I'm not sure anybody has ever suggested or requested that it should work differently. The port command accepts global flags, an action name, action-specific flags, and then a port name or pseudo-portname or port expression or port URL. The manual documents what those things mean. https://man.macports.org/port.1.html It says: "portnames containing valid UNIX glob patterns will also expand to the set of matching ports." It doesn't say right there that it's matching against the ports trees only (and not also any installed ports that are not (or no longer) in the ports trees), but it does say earlier when describing pseudo-portnames: "port recognizes various pseudo-portnames that will expand to the specified set of ports from the available port tree(s)." I guess the section on glob patterns could be updated to add such clarification. >> 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. Ok. If you've requested all ports, then reclaim will not uninstall them. Simple as that.
Re: MacPorts 2.7.0 has been released
On Thu, May 20, 2021 at 01:15:05AM -0500, Ryan Schmidt wrote: > On May 19, 2021, at 18:43, raf wrote: > > > I have the same problem on 10.14.6 > > Thanks for confirming. So far everyone affected has been on 10.14. I suspect > the difference between the 10.15 SDK SQLite version and the 10.14 runtime > SQLite version is the issue. > > > >> sqlite3 --version > > 3.35.5 2021-04-19 18:32:05 > > 1b256d97b553a9611efca188a3d995a2fff712759044ba480f9a0c9e98fae886 > >> /usr/bin/sqlite3 --version > > 3.24.0 2018-06-04 14:10:15 > > 95fbac39baaab1c3a84fdfc82ccb7f42398b2e92f18a2a57bce1d4a713cbaapl > > > > And every attempt to use the port command gives an error: > > > >> port help > > sqlite error: near "COLUMN": syntax error (1) while executing query: ALTER > > TABLE registry.ports RENAME COLUMN negated_variants TO requested_variants > > while executing > > "registry::open $db_path" > > (procedure "mportinit" line 712) > > invoked from within > > "mportinit ui_options global_options global_variations" > > Error: /opt/local/bin/port: Failed to initialize MacPorts, sqlite error: > > near "COLUMN": syntax error (1) while executing query: ALTER TABLE > > registry.ports RENAME COLUMN negated_variants TO requested_variants > > > > It won't even selfupdate. Do I need to disable SIP and fiddle with > > /usr/bin/sqlite3? > > Nope. Visit the ticket, share what you've done there, help us find the > solution there. Thanks. Will do. cheers, raf
Re: MacPorts 2.7.0 has been released
On Thu, May 20, 2021 at 01:13:51AM -0500, Ryan Schmidt
wrote:
> On May 19, 2021, at 18:31, Bjarne D Mathiesen wrote:
>
> > Ryan Schmidt wrote:
> >> Looks like support for the "ALTER TABLE ... RENAME COLUMN" syntax
> >> first appeared in SQLite 3.25.0, and MacPorts base is coded only to
> >> use the "RENAME COLUMN" syntax with SQLite 3.25.0 and later; for
> >> earlier versions, a different method is used:
> >>
> >> What version of SQLite does your version of macOS have? Run:
> >>
> >> /usr/bin/sqlite3 --version
> >>
> >> I'm on macOS High Sierra with SQLite 3.19.3 and I haven't seen that
> >> problem.
> >
> > Qs:
> > 1) does MacPorts !explicitly! request /usr/bin/sqlite3
>
> MacPorts uses /usr/lib/libsqlite3.dylib.
>
> > -or- does MacPorts use the one found in ${PATH}
>
> > 2) is it advantagerous for MacPorts to use sqlite3 >= 3.25.0
> >
> > eg for 10.6.8 I've got :
> >
> > #=> /usr/bin/sqlite3 --version
> > 3.6.12
> > #=> which sqlite3
> > /opt/local/bin/sqlite3
> > #=> sqlite3 --version
> > 3.35.5 2021-04-19 18:32:05 1b256d97b ... e98fae886
>
> MacPorts by default uses the version of SQLite included with macOS. MacPorts
> 2.7.0 is compatible with every version of SQLite that comes with every
> supported version of macOS (10.4 and later including 11).
>
> The problem here may be that the version of SQLite whose headers were found
> at build time is different from the version of SQLite whose library was found
> at runtime. See the ticket.
When I disable /usr/lib/libsqlite3.dylib by renaming it,
the error changes to a symbol lookup failure:
> port help
dlopen(/opt/local/libexec/macports/lib/macports1.0/MacPorts.dylib, 6): can't
resolve symbol _kDADiskDescriptionMediaBSDNameKey in
/System/Library/Frameworks/Foundation.framework/Versions/C/Foundation because
dependent dylib #2 could not be loaded in
/System/Library/Frameworks/Foundation.framework/Versions/C/Foundation
while executing
"load /opt/local/libexec/macports/lib/macports1.0/MacPorts.dylib"
("package ifneeded macports 1.0" script)
invoked from within
"package require macports"
(file "/opt/local/bin/port" line 46)
Oops. And now PAM/su/sudo are now broken. I shouldn't have done that. :-)
cheers,
raf
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
Re: MacPorts 2.7.0 Warning
> On May 20, 2021, at 3:13 AM, Christopher Jones > wrote: > >>> >>> What is the output of: >>> >>> grep -F universal_arch /opt/local/etc/macports/macports.conf >>> >>> ? >>> >>> Are you on an M1 system? >>> >>> The default setting is "arm64 x86_64" (without quotes). You can comment out >>> the universal_archs line with # to get the default. >> >> The output of the grep command is "universal_archs x86_64”. I am >> not on an M1 system (I have a 2017 MacBook). > > You must have changed that at some point, as that is not the default. The > easiest fix is to edit /opt/local/etc/macports/macports.conf and comment out > that setting, and thus fallback to the (correct) defaults. I don’t remember ever changing it, but I did comment out that setting and that fixed the problem. Emily
Re: MacPorts 2.7.0 Warning
>> >> What is the output of: >> >> grep -F universal_arch /opt/local/etc/macports/macports.conf >> >> ? >> >> Are you on an M1 system? >> >> The default setting is "arm64 x86_64" (without quotes). You can comment out >> the universal_archs line with # to get the default. > > The output of the grep command is "universal_archsx86_64”. I am > not on an M1 system (I have a 2017 MacBook). You must have changed that at some point, as that is not the default. The easiest fix is to edit /opt/local/etc/macports/macports.conf and comment out that setting, and thus fallback to the (correct) defaults. Chris smime.p7s Description: S/MIME cryptographic signature
Re: MacPorts 2.7.0 Warning
> On May 20, 2021, at 1:42 AM, Andrew Udvare wrote: > > >> On 2021-05-20, at 02:30, Emily Jackson wrote: >> >> Every time I run a “port” command, this warning appears: >> >> Warning: invalid universal_archs configured (should contain at least 2 archs) >> >> MacPorts then goes on to work normally, but I wonder what is causing this >> warning and how it could be stopped. I am running macOS 11.4 RC 1 with the >> latest version of Xcode. > > What is the output of: > > grep -F universal_arch /opt/local/etc/macports/macports.conf > > ? > > Are you on an M1 system? > > The default setting is "arm64 x86_64" (without quotes). You can comment out > the universal_archs line with # to get the default. The output of the grep command is "universal_archs x86_64”. I am not on an M1 system (I have a 2017 MacBook). Thanks, Emily
Re: MacPorts 2.7.0 Warning
> On 2021-05-20, at 02:30, Emily Jackson wrote: > > Every time I run a “port” command, this warning appears: > > Warning: invalid universal_archs configured (should contain at least 2 archs) > > MacPorts then goes on to work normally, but I wonder what is causing this > warning and how it could be stopped. I am running macOS 11.4 RC 1 with the > latest version of Xcode. What is the output of: grep -F universal_arch /opt/local/etc/macports/macports.conf ? Are you on an M1 system? The default setting is "arm64 x86_64" (without quotes). You can comment out the universal_archs line with # to get the default.
MacPorts 2.7.0 Warning
Every time I run a “port” command, this warning appears: Warning: invalid universal_archs configured (should contain at least 2 archs) MacPorts then goes on to work normally, but I wonder what is causing this warning and how it could be stopped. I am running macOS 11.4 RC 1 with the latest version of Xcode. Thanks, Emily
Re: MacPorts 2.7.0 has been released
On May 19, 2021, at 18:43, raf wrote: > I have the same problem on 10.14.6 Thanks for confirming. So far everyone affected has been on 10.14. I suspect the difference between the 10.15 SDK SQLite version and the 10.14 runtime SQLite version is the issue. >> sqlite3 --version > 3.35.5 2021-04-19 18:32:05 > 1b256d97b553a9611efca188a3d995a2fff712759044ba480f9a0c9e98fae886 >> /usr/bin/sqlite3 --version > 3.24.0 2018-06-04 14:10:15 > 95fbac39baaab1c3a84fdfc82ccb7f42398b2e92f18a2a57bce1d4a713cbaapl > > And every attempt to use the port command gives an error: > >> port help > sqlite error: near "COLUMN": syntax error (1) while executing query: ALTER > TABLE registry.ports RENAME COLUMN negated_variants TO requested_variants > while executing > "registry::open $db_path" > (procedure "mportinit" line 712) > invoked from within > "mportinit ui_options global_options global_variations" > Error: /opt/local/bin/port: Failed to initialize MacPorts, sqlite error: > near "COLUMN": syntax error (1) while executing query: ALTER TABLE > registry.ports RENAME COLUMN negated_variants TO requested_variants > > It won't even selfupdate. Do I need to disable SIP and fiddle with > /usr/bin/sqlite3? Nope. Visit the ticket, share what you've done there, help us find the solution there.
Re: MacPorts 2.7.0 has been released
On May 19, 2021, at 18:31, Bjarne D Mathiesen wrote:
> Ryan Schmidt wrote:
>> Looks like support for the "ALTER TABLE ... RENAME COLUMN" syntax
>> first appeared in SQLite 3.25.0, and MacPorts base is coded only to
>> use the "RENAME COLUMN" syntax with SQLite 3.25.0 and later; for
>> earlier versions, a different method is used:
>>
>> What version of SQLite does your version of macOS have? Run:
>>
>> /usr/bin/sqlite3 --version
>>
>> I'm on macOS High Sierra with SQLite 3.19.3 and I haven't seen that problem.
>
> Qs:
> 1) does MacPorts !explicitly! request /usr/bin/sqlite3
MacPorts uses /usr/lib/libsqlite3.dylib.
> -or- does MacPorts use the one found in ${PATH}
> 2) is it advantagerous for MacPorts to use sqlite3 >= 3.25.0
>
> eg for 10.6.8 I've got :
>
> #=> /usr/bin/sqlite3 --version
> 3.6.12
> #=> which sqlite3
> /opt/local/bin/sqlite3
> #=> sqlite3 --version
> 3.35.5 2021-04-19 18:32:05 1b256d97b ... e98fae886
MacPorts by default uses the version of SQLite included with macOS. MacPorts
2.7.0 is compatible with every version of SQLite that comes with every
supported version of macOS (10.4 and later including 11).
The problem here may be that the version of SQLite whose headers were found at
build time is different from the version of SQLite whose library was found at
runtime. See the ticket.
Re: Command line glob expansion broken-ish
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. You can identify what you call zombie ports and what we call obsolete ports with: port installed obsolete 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.
Re: 'doctor' script
On May 20, 2021, at 00:05, Werner LEMBERG wrote: > is there a 'doctor' script that walks over all installed MacPorts > ports and checks whether its dependencies are installed, too? In > general, what's the right action(s) to thoroughly check the integrity > of a MacPorts installation? > > I have forcibly uninstalled some ports by accident, and due to using > mosh I can't scroll backwards to see which they are... sudo port rev-upgrade https://man.macports.org/port-rev-upgrade.1.html MacPorts also runs this automatically every time you install or upgrade a port, unless you've disabled that functionality. There's also port diagnose which was intended to be analogous to Homebrew's doctor. https://man.macports.org/port-diagnose.1.html
Re: Warning: -Wimplicit-function-declaration
On May 19, 2021, at 19:21, Bjarne D Mathiesen wrote: > > MacPorts 2.7.0 > I've just done my usual : > port -dN selfupdate > port outdated > port clean --all outdated > port -upN upgrade outdated > port -pN clean --work installed > > & I got this : > > ---> Configuring snort > Warning: Configuration logfiles contain indications of > -Wimplicit-function-declaration; check that features were not > accidentally disabled: > pcap_lex_destroy: found in snort-2.9.17.1/config.log > ---> Building snort > > > ---> Configuring wget > Warning: Configuration logfiles contain indications of > -Wimplicit-function-declaration; check that features were not > accidentally disabled: > MIN: found in wget-1.21.1/config.log > strchr: found in wget-1.21.1/config.log > ---> Building wget > > I've never seen this before !?! > Is it something I have to worry about ?!? > And if so : how do I fix it ?!? Sometimes programs are written to use functions before declaring them. This has not been correct ever since the introduction of the 1999 version of the C standard decades ago, but because it was allowed by the earlier 1989 C standard many C99 compilers still allowed this with a warning. But it can cause programs to crash or behave incorrectly on ARM processors, therefore to avoid problems on Apple Silicon Macs, the version of clang in included with Xcode 12 and later considers this to be an error. This causes some ports to fail to build. Worse, many configure tests have this problem, but when they fail, it doesn't cause configure to immediately fail and tell you that; instead, configure just makes wrong determinations about your system. In the best case, the build still succeeds and works fine. Or, the build fails with a bizarre error later. Or the build succeeds but is wrong. The message you're quoting is a new feature of MacPorts 2.7.0. It now notices when an implicit declaration of function error occurred during configuration, so that the port maintainer can investigate whether this is a problem. The port maintainer can then either fix the problem, or can mark the port to indicate that that particular implicit declaration of function does not represent a problem. If many programs check for functions which we know are not ever present on certain versions of macOS, then we can mark that in a central location rather than individually in each affected port.
