Re: MacPorts 2.7.0 Warning

[Emily Jackson]

> 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

[Andrew Udvare]

> 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

[Emily Jackson]

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

[Ryan Schmidt]

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

[Ryan Schmidt]

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

[Ryan Schmidt]

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

[Ryan Schmidt]

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

[Ryan Schmidt]

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.

'doctor' script

[Werner LEMBERG]

Folks,


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...


Werner

Re: Warning: -Wimplicit-function-declaration

[Andrew Udvare]

-- 
Andrew Udvare


> On 2021-05-19, at 20: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 ?!?

This is a warning for the upstream developers of the package. You could file a 
bug report with upstream and/or MacPorts.

Command line glob expansion broken-ish

[Bill Cole]

Example:

shiny:~ root# port installed *proto
The following ports are currently installed:
  xorg-xorgproto @2021.4_0
shiny:~ root# port installed |fgrep proto
  xorg-compositeproto @0.4.2_0 (active)
  xorg-damageproto @1.2.1_0 (active)
  xorg-fixesproto @5.0_0 (active)
  xorg-kbproto @1.0.7_0 (active)
  xorg-randrproto @1.5.0_0 (active)
  xorg-renderproto @0.11.1_0 (active)
  xorg-xineramaproto @1.2.1_0 (active)
  xorg-xorgproto @2021.4_0

I do understand the issue, I think: the glob is being expanded against 
the names of ports that still exist in the current ports tree, not the 
ones that have been installed but have been superseded by (in this case) 
an omnibus port that won't activate because of the existing 
installations.


The obvious workaround was to manually uninstall each of the zombie 
ports individually. I wonder if anyone else considers this a bug?





--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire

Warning: -Wimplicit-function-declaration

[Bjarne D Mathiesen]

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 ?!?

-- 
Bjarne D Mathiesen
Korsør ; Danmark ; Europa
---
denne besked er skrevet i et totalt M$-frit miljø
OpenCore + macOS 10.15.7 Catalina
MacPro 2010 ; 2 x 3,46 GHz 6-Core Intel Xeon ; 256 GB 1333 MHz DDR3 ECC
ATI Radeon RX 590 8 GB

Re: MacPorts 2.7.0 has been released

[raf]

On Thu, May 20, 2021 at 01:31:18AM +0200, 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
>-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
> 
> -- 
> Bjarne D Mathiesen
> Korsør ; Danmark ; Europa

I have the same problem on 10.14.6:

  > 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?

cheers,
raf

Re: MacPorts 2.7.0 has been released

[Bjarne D Mathiesen]

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
   -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

-- 
Bjarne D Mathiesen
Korsør ; Danmark ; Europa
---
denne besked er skrevet i et totalt M$-frit miljø
OpenCore + macOS 10.15.7 Catalina
MacPro 2010 ; 2 x 3,46 GHz 6-Core Intel Xeon ; 256 GB 1333 MHz DDR3 ECC
ATI Radeon RX 590 8 GB

Re: MacPorts 2.7.0 has been released

[Ryan Schmidt]

On May 19, 2021, at 18:08, Ryan Schmidt wrote:
> 
> On May 19, 2021, at 11:04, Henning Hraban Ramm wrote:
> 
>> $ sudo port upgrade outdated
>> Password:
>> 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
>> 
>> 
>> What can I do to fix this?
> 
> 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:
> 
> https://github.com/macports/macports-base/commit/19c933969bc62ee54c86fbadaf4d98252b3df5ee#diff-780a9c883e001748860d3ed6b65f88c3be24a21feb1e71a408898f6243149b18R752-R753
> 
> 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.

And I see we already have a ticket for this:

https://trac.macports.org/ticket/62929

So it would be best to add your information there, and Cc yourself there if you 
would like updates about this issue.

Re: MacPorts 2.7.0 has been released

[Ryan Schmidt]

On May 19, 2021, at 11:04, Henning Hraban Ramm wrote:

> $ sudo port upgrade outdated
> Password:
> 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
> 
> 
> What can I do to fix this?

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:

https://github.com/macports/macports-base/commit/19c933969bc62ee54c86fbadaf4d98252b3df5ee#diff-780a9c883e001748860d3ed6b65f88c3be24a21feb1e71a408898f6243149b18R752-R753

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.

Re: MacPorts 2.7.0 has been released

[Bjarne D Mathiesen]

Ken Cunningham wrote:
> I seem to remember something about a bunch of symlinks you made from cctools 
> things into macports cctools in the past (perhaps I recall wrong).

You were recalling partially correctly : I didn't symlink cctools into
/usr/bin - I pushed the Apple stuff common with cctools aside in order
to be able to compile mysql57 :

* https://trac.macports.org/ticket/59072#comment:1
* '[workaround] 10.6.8 & mysql57'

The promised forwardported fix from mysql56 -> mysql57 never seemed to
materialise itself [thinking]

But I think I'll (also) keep my :
/usr/bin/cc.apple -> ../llvm-gcc-4.2/bin/llvm-gcc-4.2
/usr/bin/cc -> /opt/local/bin/clang
fix

-- 
Bjarne D Mathiesen
Korsør ; Danmark ; Europa
---
denne besked er skrevet i et totalt M$-frit miljø
OpenCore + macOS 10.15.7 Catalina
MacPro 2010 ; 2 x 3,46 GHz 6-Core Intel Xeon ; 256 GB 1333 MHz DDR3 ECC
ATI Radeon RX 590 8 GB

Re: MacPorts 2.7.0 has been released

[Bjarne D Mathiesen]

OK - I can see what the problem is :

It can't find at valid assembler - and checking I get :
root@MiniWeb 18:10:20 /usr
#=> find . -name 'as.*'
./bin/as.orig
./share/aclocal-1.10/as.m4
./share/man/man1/as.1

so at some point in time I've moved the Apple assembler aside to solve a
MacPorts problem [thinking] - in particular I think it's this :
https://trac.macports.org/ticket/59072#comment:1
It was discussed in the thread '[workaround] 10.6.8 & mysql57'
on 28/01/2021

-- 
Bjarne D Mathiesen
Korsør ; Danmark ; Europa
---
denne besked er skrevet i et totalt M$-frit miljø
OpenCore + macOS 10.15.7 Catalina
MacPro 2010 ; 2 x 3,46 GHz 6-Core Intel Xeon ; 256 GB 1333 MHz DDR3 ECC
ATI Radeon RX 590 8 GB

Re: MacPorts 2.7.0 has been released

[Bjarne D Mathiesen]

Chris Jones wrote:
> See `config.log' for more details
> 
> We need to see what is in this file… (from the messages you posted below).
> 
re-instaling from source with :

./configure --prefix=/opt/local
make
make install

gives :

checking build system type... x86_64-apple-darwin10.8.0
checking host system type... x86_64-apple-darwin10.8.0
checking target system type... x86_64-apple-darwin10.8.0
checking MacPorts version... 2.7.0
checking for sw_vers... /usr/bin/sw_vers
checking for defaults... /usr/bin/defaults
checking for xcode-select... /usr/bin/xcode-select
checking macOS version... 10.6.8
checking Xcode location... /Developer
checking Xcode version... 4.0.1
checking for clang... clang

& no problems [thumbsup]

but emulating the selfupdate process with
CC=/usr/bin/cc ./configure \
 --prefix=/opt/local \
 --with-install-user=root \
 --with-install-group=admin \
 --with-directory-mode=0755 \
 --enable-readline \
&& make SELFUPDATING=1 \
&& make install SELFUPDATING=1

gives the following log :
https://macports.mathiesen.info/logs/MacPorts-2.7.0/config.log

-- 
Bjarne D Mathiesen
Korsør ; Danmark ; Europa
---
denne besked er skrevet i et totalt M$-frit miljø
OpenCore + macOS 10.15.7 Catalina
MacPro 2010 ; 2 x 3,46 GHz 6-Core Intel Xeon ; 256 GB 1333 MHz DDR3 ECC
ATI Radeon RX 590 8 GB

Re: MacPorts 2.7.0 has been released

[Henning Hraban Ramm]

> Am 19.05.2021 um 12:15 schrieb Joshua Root :
> 
> The MacPorts Project is happy to announce that the 2.7.0 version has now
> been released. It is available via the usual methods:

$ sudo port selfupdate
Password:
--->  Updating MacPorts base sources using rsync
MacPorts base version 2.6.4 installed,
MacPorts base version 2.7.0 downloaded.
--->  Updating the ports tree
--->  MacPorts base is outdated, installing new version 2.7.0
Installing new MacPorts release in /opt/local as root:wheel; permissions 0755

$ sudo port upgrade outdated
Password:
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


What can I do to fix this?
I used "port upgrade outdated" just yesterday, so everything should be quite 
recent.

(macOS 10.14.6)

Hraban


signature.asc
Description: Message signed with OpenPGP

Re: MacPorts 2.7.0 has been released

[Ken Cunningham]

my SnowLeopard macports-base built and installed just fine.

As Chris says, post up your config log and we might see the error.

Or — simpler perhaps -- just try to build any “hello_world.c” program at all 
with your llvm-gcc-4.2 compiler and you might find out how it is broken.

I seem to remember something about a bunch of symlinks you made from cctools 
things into macports cctools in the past (perhaps I recall wrong).

K

Re: MacPorts 2.7.0 has been released

[Chris Jones]

See `config.log' for more details

We need to see what is in this file… (from the messages you posted below).

Chris

> On 19 May 2021, at 3:06 pm, Bjarne D Mathiesen  
> wrote:
> 
> OK -
> 
> on 10.6.8 I get :
> 
> #=> ls -l /usr/bin/cc
> lrwxr-xr-x  1 root  wheel  32  4 Jan 14:50 /usr/bin/cc ->
> ../llvm-gcc-4.2/bin/llvm-gcc-4.2
> #=> ls -l /usr/llvm-gcc-4.2/bin/llvm-gcc-4.2
> -rwxrwxr-x  1 root  admin  116992 12 Feb  2011
> /usr/llvm-gcc-4.2/bin/llvm-gcc-4.2
> 
> 
> on 10.15.7 I get :
> 
> #=> ls -l /usr/bin/cc
> lrwxr-xr-x  1 root  wheel  5  1 Mar 13:06 /usr/bin/cc -> clang
> #=> ll /usr/bin/clang
> -rwxr-xr-x  1 root  wheel  31488 21 Sep  2020 /usr/bin/clang
> 
> 
> So the (temporary) fix for me on 10.6.8 is :
> 
> #=> which clang
> /opt/local/bin/clang
> #=> mv /usr/bin/cc /usr/bin/cc.apple
> #=> ln -s $( which clang ) /usr/bin/cc
> #=> ll /usr/bin/cc
> lrwxr-xr-x  1 root  wheel  20 19 Maj 15:53 /usr/bin/cc ->
> /opt/local/bin/clang
> 
> 
> -- 
> Bjarne D Mathiesen
> Korsør ; Danmark ; Europa
> ---
> denne besked er skrevet i et totalt M$-frit miljø
> OpenCore + macOS 10.15.7 Catalina
> MacPro 2010 ; 2 x 3,46 GHz 6-Core Intel Xeon ; 256 GB 1333 MHz DDR3 ECC
> ATI Radeon RX 590 8 GB

Re: MacPorts 2.7.0 has been released

[Bjarne D Mathiesen]

OK -

on 10.6.8 I get :

#=> ls -l /usr/bin/cc
lrwxr-xr-x  1 root  wheel  32  4 Jan 14:50 /usr/bin/cc ->
../llvm-gcc-4.2/bin/llvm-gcc-4.2
#=> ls -l /usr/llvm-gcc-4.2/bin/llvm-gcc-4.2
-rwxrwxr-x  1 root  admin  116992 12 Feb  2011
/usr/llvm-gcc-4.2/bin/llvm-gcc-4.2


on 10.15.7 I get :

#=> ls -l /usr/bin/cc
lrwxr-xr-x  1 root  wheel  5  1 Mar 13:06 /usr/bin/cc -> clang
#=> ll /usr/bin/clang
-rwxr-xr-x  1 root  wheel  31488 21 Sep  2020 /usr/bin/clang


So the (temporary) fix for me on 10.6.8 is :

#=> which clang
/opt/local/bin/clang
#=> mv /usr/bin/cc /usr/bin/cc.apple
#=> ln -s $( which clang ) /usr/bin/cc
#=> ll /usr/bin/cc
lrwxr-xr-x  1 root  wheel  20 19 Maj 15:53 /usr/bin/cc ->
/opt/local/bin/clang


-- 
Bjarne D Mathiesen
Korsør ; Danmark ; Europa
---
denne besked er skrevet i et totalt M$-frit miljø
OpenCore + macOS 10.15.7 Catalina
MacPro 2010 ; 2 x 3,46 GHz 6-Core Intel Xeon ; 256 GB 1333 MHz DDR3 ECC
ATI Radeon RX 590 8 GB

Re: MacPorts 2.7.0 has been released

[Bjarne D Mathiesen]

I'm getting this on 10.6.8

Joshua Root wrote:
> The MacPorts Project is happy to announce that the 2.7.0 version has now
> been released. It is available via the usual methods:
> 
>  - selfupdate if you already have MacPorts installed

Installing new MacPorts release in /opt/local as root:admin; permissions
0755

DEBUG: system -W
/opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/base:
CC=/usr/bin/cc ./configure --prefix=/opt/local --with-install-user=root
--with-install-group=admin --with-directory-mode=0755 --enable-readline
&& make SELFUPDATING=1 && make install SELFUPDATING=1
checking build system type... x86_64-apple-darwin10.8.0
checking host system type... x86_64-apple-darwin10.8.0
checking target system type... x86_64-apple-darwin10.8.0
checking MacPorts version... 2.7.0
checking for sw_vers... /usr/bin/sw_vers
checking for defaults... /usr/bin/defaults
checking for xcode-select... /usr/bin/xcode-select
checking macOS version... 10.6.8
checking Xcode location... /Developer
checking Xcode version... 4.0.1
checking whether the C compiler works... no
configure: error: in
`/opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/base':
configure: error: C compiler cannot create executables
See `config.log' for more details
Command failed: CC=/usr/bin/cc ./configure --prefix=/opt/local
--with-install-user=root --with-install-group=admin
--with-directory-mode=0755 --enable-readline && make SELFUPDATING=1 &&
make install SELFUPDATING=1

-- 
Bjarne D Mathiesen
Korsør ; Danmark ; Europa
---
denne besked er skrevet i et totalt M$-frit miljø
OpenCore + macOS 10.15.7 Catalina
MacPro 2010 ; 2 x 3,46 GHz 6-Core Intel Xeon ; 256 GB 1333 MHz DDR3 ECC
ATI Radeon RX 590 8 GB

Note if you installed 2.7.0-rc1

[Joshua Root]

There was one small fix that went in to the final release that was not 
in the release candidate. So you may want to ensure you have the final 
release by either running the package installer, or 'sudo port -f 
selfupdate', or installing from source manually.


- Josh

MacPorts 2.7.0 has been released

[Joshua Root]

The MacPorts Project is happy to announce that the 2.7.0 version has now
been released. It is available via the usual methods:

 - selfupdate if you already have MacPorts installed
 - package installers [1] for macOS 11 Big Sur and all older releases
   back to Mac OS X 10.4 Tiger  (universal arm64/x86_64 for macOS 11,
   i386/x86_64 for 10.6, i386/ppc for 10.4 and 10.5, and the rest
   x86_64)
 - source tarballs, both .tar.bz2 [2] and .tar.gz [3]
 - git tag [4]

The list of what's new in 2.7.0 can be found in the ChangeLog [5].

A big thanks to the developers for their hard work with all of the
various features and bug fixes in 2.7.0, and to all those who helped out
by reporting bugs or testing.

Detached PGP signatures for the pkg/dmgs and source tarballs have been
made with my key, which is available on the keyservers and my MacPorts
wiki page [6].

- Josh

[1] 
[2] 

[3] 


[4] 
[5] 
[6] 

PS, my PGP key ID is 0x01FF673FB4AAE6CD,
fingerprint C403 7936 5723 6DCF 2E58  0C02 01FF 673F B4AA E6CD




OpenPGP_signature
Description: OpenPGP digital signature