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