Re: Problems with not finding Framework header files on Mojave 10.14.6

[Ryan Schmidt]

On Feb 22, 2020, at 03:29, Greg Earle wrote:

> --
> Force re-install the header files:
> 
> $ sudo installer -pkg 
> /Library/Developer/CommandLineTools/Packages/macOS_SDK_headers_for_macOS_10.14.pkg
>  -target /
> --
> 
> Neither my work dev system or my work desktop system (both Mojave) had the 
> headers installed under /System/Library/Frameworks like they were supposed to 
> be.  I guess the Command Line Tools installer didn't put them there.  No idea 
> why not.

That pkg installs the headers in /usr/include. In macOS 10.13, the command line 
tools installed the headers in /usr/include automatically. In 10.14 and later, 
they do not, and installing them is deprecated. MacPorts should work on 10.14 
and later without the headers in /usr/include. You should not have needed to 
install them. Installing them may have bypassed the warning you saw, but that 
only masks whatever the real problem was (e.g. perhaps the MacOSX10.14.sdk not 
existing in your Xcode application bundle).

Re: Problems with not finding Framework header files on Mojave 10.14.6

[Ryan Schmidt]

On Feb 21, 2020, at 15:59, Greg Earle wrote:

> --
> mojavemac:/ root# port install mercurial
> Warning: The macOS 10.14 SDK does not appear to be installed. Ports may not 
> build correctly.
> Warning: You can install it as part of the Xcode Command Line Tools package 
> by running `xcode-select --install'.
> --->  Computing dependencies for mercurial
> --->  Fetching archive for mercurial
> --->  Attempting to fetch mercurial-5.3_1.darwin_18.x86_64.tbz2 from 
> https://packages.macports.org/mercurial
> --->  Attempting to fetch mercurial-5.3_1.darwin_18.x86_64.tbz2 from 
> https://ywg.ca.packages.macports.org/mirror/macports/packages/mercurial
> --->  Attempting to fetch mercurial-5.3_1.darwin_18.x86_64.tbz2 from 
> http://aus.us.packages.macports.org/macports/packages/mercurial
> --->  Fetching distfiles for mercurial
> --->  Verifying checksums for mercurial
> --->  Extracting mercurial
> --->  Applying patches to mercurial
> --->  Configuring mercurial
> --->  Building mercurial
> Error: Failed to build mercurial: command execution failed
> Error: See 
> /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_devel_mercurial/mercurial/main.log
>  for details.
> Error: Follow https://guide.macports.org/#project.tickets to report a bug.
> Error: Processing of port mercurial failed
> --
> 
> I don't understand why I get complaints about the SDK when it's most 
> definitely installed.
> 
> --
> mojavemac:/ root# xcode-select --install
> xcode-select: error: command line tools are already installed, use "Software 
> Update" to install updates
> --
> 
> I verified that both 
> "/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk"
>  and "/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk" have a 10.14.6 SDK 
> installed in them.
> 
> (I get the same complaints on my office Mac but that has Xcode 11.3.1 on it.  
> I figured it was because that version installs a Catalina SDK.)
> 
> Anyway, the mercurial port install log file says
> 
> --
> [...]
> :info:build building 'mercurial.cext.osutil' extension
> :info:build /usr/bin/clang -fno-strict-aliasing -fno-common -dynamic -pipe 
> -Os 
> -isysroot/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk
>  -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -arch x86_64 -isysroot/ 
> -Imercurial 
> -I/opt/local/Library/Frameworks/Python.framework/Versions/2.7/include/python2.7
>  -c mercurial/cext/osutil.c -o 
> build/temp.macosx-10.14-x86_64-2.7/mercurial/cext/osutil.o -DHAVE_BSD_STATFS
> :info:build mercurial/cext/osutil.c:1334:10: fatal error: 
> 'ApplicationServices/ApplicationServices.h' file not found
> :info:build #include 
> :info:build  ^~~
> :info:build 1 error generated.

I guess you do not have 
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk.
 I don't know why; that should be part of Xcode 10.x.

Re: Dovecot port changes

[Ryan Schmidt]

On Feb 22, 2020, at 07:43, Gerben Wierda wrote:

> On 22 Feb 2020, at 14:31, Rainer Müller wrote:
> 
>> On 22.02.20 12:41, Gerben Wierda wrote:
>>> port dovecot is now installing dovecot 2
>>> port dovecot2 is now installing dovecot 1
>> 
>> No, there is no Dovecot 1.x i the ports tree any more.
>> 
>> dovecot2 is a port that has been marked as replaced_by dovecot. As the
>> epoch was increased, it will be considered more recent than the old 2.x
>> version, although it reads 1.x. I agree this might be a bit confusing,
>> but it should work as intended.
>> 
>> This is the usual way port removal or renames are handled and eventually
>> the dovecot port will be removed completely as already noted in the
> 
> The dovecot2 port will be removed, I hope ;-)

That would be the plan, after a suitable period of time has elapsed to allow 
users of dovecot2 to transition automatically to the new dovecot port. (I don't 
know why that automatic transition did not work smoothly for you.) We usually 
recommend that this period of time is no shorter than one year, since not 
everyone updates their ports in a timely manner.


> This is what it has
> 
> namedovecot2
> replaced_by dovecot
> epoch   20060722
> # This is actually the old dovecot version
> version 1.2.17
> 
> And thus it is reported as ‘port dovecot2 with version 1.2.17’
> 
> albus:dovecot2 sysbh$ port list dovecot2
> dovecot2   @1.2.17 mail/dovecot2
> dovecot2   @1.2.17 mail/dovecot2
> 
> Which is also confusing as it seems to say that port dovecot2 will install 
> dovecot 1.2.17

I agree that is confusing. I don't know why the version of the dovecot2 port 
was not set to the current version of the dovecot port. That would be less 
confusing. That could still be changed.

Re: Why are my por definitions still out of date after this?

[Gerben Wierda]

> On 22 Feb 2020, at 14:43, Christopher Jones  wrote:
> 
> 
> 
>> On 22 Feb 2020, at 1:39 pm, Gerben Wierda > > wrote:
>> 
>> 
>> 
>>> On 22 Feb 2020, at 13:32, Christopher Jones >> > wrote:
>>> 
>>> Have you told macports to use your git clone ?
>>> 
>>> i.e. 
>>> 
>>>  > cat /opt/local/etc/macports/sources.conf
>>> 
>>> #rsync://rsync.macports.org/macports/release/tarballs/ports.tar 
>>>  [default]
>>> file:///Users/chris/Projects/MacPorts/ports 
>>>  [default]
>>> 
>>> where for me /Users/chris/Projects/MacPorts/ports is my local git clone.
>> 
>> Yes.
>> 
>> file:///Users/sysbh/MacPortsDev/macports-ports 
>> 
>> rsync://rsync.macports.org/macports/release/tarballs/ports.tar 
>>  [default]
> 
> thats not the same. I recommend making your git clone the default, and just 
> comment out the other one.

I see. I missed that. Thanks!

> 
>> 
>>> b.t.w. Once you have done this, you don’t need to run all the git commands 
>>> below. just running
>>> 
>>> > sudo port sync
>>> 
>>> will update your git clone, and run the portindex, for you.
>> 
>> With rsync, not with git.
> 
> once you make your git checkout the default, port sync will update with git, 
> not rsync.
> 
>> So what about branches etc? Suppose I create a branch in my fork to work in? 
>> And I want update my master to reflect the latest situation of the official 
>> repo?
> 
> generally works fine.
> 
> run with
> 
> > sudo port -d sync
> 
> if you want to check what is happening under the hood.
> 
> Chris
> 
>> 
>> G
>> 
>>> 
>>> Chris
>>> 
 On 22 Feb 2020, at 11:43 am, Gerben Wierda >>> > wrote:
 
 I have my own fork of the macports-ports repository on GitHub so I can do 
 maintenance. I have a local clone of that fork
 
 When I want to update ports I do not maintain, do the following. First I 
 make sure my clone is up to date with the upstream original, then I push 
 the clone back to my GitHub fork. Then I run portindex. ‘upstream’ is the 
 official repo, origin is my fork
 git fetch upstream
 git checkout master
 git reset --hard upstream/master
 git push origin master --force
 portindex
  
 But when I do that, I still get:
 
 albus:macports-ports sysbh$ port list updated
 Warning: port definitions are more than two weeks old, consider updating 
 them by running 'port selfupdate'.
 
 (Should have said ‘outdated’ of course, this doesn’t give me a warning)
 
 But port self update overwrites everything using rsync and doesn’t go via 
 git. So, it is a parallel and possibly trouble-creating route. I want 
 update my local tree entirely via git.
 
 Still, with a clean clone of of an up-to-date fork, I can do it:
 
 sudo port selfupdate
 Password:
 --->  Updating MacPorts base sources using rsync
 MacPorts base version 2.6.2 installed,
 MacPorts base version 2.6.2 downloaded.
 --->  Updating the ports tree
 --->  MacPorts base is already the latest version
 
 What is the way to go when updating, using your own clone of your own fork 
 of the git repo?
 
 G

Re: Why are my por definitions still out of date after this?

[Christopher Jones]

> On 22 Feb 2020, at 1:39 pm, Gerben Wierda  wrote:
> 
> 
> 
>> On 22 Feb 2020, at 13:32, Christopher Jones > > wrote:
>> 
>> Have you told macports to use your git clone ?
>> 
>> i.e. 
>> 
>>  > cat /opt/local/etc/macports/sources.conf
>> 
>> #rsync://rsync.macports.org/macports/release/tarballs/ports.tar 
>>  [default]
>> file:///Users/chris/Projects/MacPorts/ports 
>>  [default]
>> 
>> where for me /Users/chris/Projects/MacPorts/ports is my local git clone.
> 
> Yes.
> 
> file:///Users/sysbh/MacPortsDev/macports-ports 
> 
> rsync://rsync.macports.org/macports/release/tarballs/ports.tar 
>  [default]

thats not the same. I recommend making your git clone the default, and just 
comment out the other one.

> 
>> b.t.w. Once you have done this, you don’t need to run all the git commands 
>> below. just running
>> 
>> > sudo port sync
>> 
>> will update your git clone, and run the portindex, for you.
> 
> With rsync, not with git.

once you make your git checkout the default, port sync will update with git, 
not rsync.

> So what about branches etc? Suppose I create a branch in my fork to work in? 
> And I want update my master to reflect the latest situation of the official 
> repo?

generally works fine.

run with

> sudo port -d sync

if you want to check what is happening under the hood.

Chris

> 
> G
> 
>> 
>> Chris
>> 
>>> On 22 Feb 2020, at 11:43 am, Gerben Wierda >> > wrote:
>>> 
>>> I have my own fork of the macports-ports repository on GitHub so I can do 
>>> maintenance. I have a local clone of that fork
>>> 
>>> When I want to update ports I do not maintain, do the following. First I 
>>> make sure my clone is up to date with the upstream original, then I push 
>>> the clone back to my GitHub fork. Then I run portindex. ‘upstream’ is the 
>>> official repo, origin is my fork
>>> git fetch upstream
>>> git checkout master
>>> git reset --hard upstream/master
>>> git push origin master --force
>>> portindex
>>>  
>>> But when I do that, I still get:
>>> 
>>> albus:macports-ports sysbh$ port list updated
>>> Warning: port definitions are more than two weeks old, consider updating 
>>> them by running 'port selfupdate'.
>>> 
>>> (Should have said ‘outdated’ of course, this doesn’t give me a warning)
>>> 
>>> But port self update overwrites everything using rsync and doesn’t go via 
>>> git. So, it is a parallel and possibly trouble-creating route. I want 
>>> update my local tree entirely via git.
>>> 
>>> Still, with a clean clone of of an up-to-date fork, I can do it:
>>> 
>>> sudo port selfupdate
>>> Password:
>>> --->  Updating MacPorts base sources using rsync
>>> MacPorts base version 2.6.2 installed,
>>> MacPorts base version 2.6.2 downloaded.
>>> --->  Updating the ports tree
>>> --->  MacPorts base is already the latest version
>>> 
>>> What is the way to go when updating, using your own clone of your own fork 
>>> of the git repo?
>>> 
>>> G



smime.p7s
Description: S/MIME cryptographic signature

Re: Dovecot port changes

[Gerben Wierda]

> On 22 Feb 2020, at 14:31, Rainer Müller  wrote:
> 
> On 22.02.20 12:41, Gerben Wierda wrote:
>> port dovecot is now installing dovecot 2
>> port dovecot2 is now installing dovecot 1
> 
> No, there is no Dovecot 1.x i the ports tree any more.
> 
> dovecot2 is a port that has been marked as replaced_by dovecot. As the
> epoch was increased, it will be considered more recent than the old 2.x
> version, although it reads 1.x. I agree this might be a bit confusing,
> but it should work as intended.
> 
> This is the usual way port removal or renames are handled and eventually
> the dovecot port will be removed completely as already noted in the

The dovecot2 port will be removed, I hope ;-)

This is what it has

namedovecot2
replaced_by dovecot
epoch   20060722
# This is actually the old dovecot version
version 1.2.17

And thus it is reported as ‘port dovecot2 with version 1.2.17’

albus:dovecot2 sysbh$ port list dovecot2
dovecot2   @1.2.17 mail/dovecot2
dovecot2   @1.2.17 mail/dovecot2

Which is also confusing as it seems to say that port dovecot2 will install 
dovecot 1.2.17

> Portfile.
> 
> Rainer

Re: catalena

[Christopher Jones]

Generally speaking mac OS 10.15 works just as well as any other, and as with 
other OSes there are some known issues. Like 32 bit support (not possible on 
10.15). Only you know which ports you use, and without this it is impossible to 
be any more specific.

note though, if you new machine was released with 10.15, you anyway will not be 
able to install an older OS on it. Macs only support the OS they where 
originally released with, and newer. So most likely you are stuck with 10.15 
anyway.

Chris

> On 22 Feb 2020, at 1:13 pm, James Linder  wrote:
> 
> Hi All
> 
> After 6 years my macbook battery is really past it’s use-by.
> The keyboard has become a sea of 
> won’t-push-this-week-and-hard-to-get-a-keypush so I decided to get a new 
> laptop, but of course it comes with catalena.
> I’ve been using high sierra and all my ports are good. Is catalena now stable 
> enough to ‘just work’ or need I consider installing (say) high sierra.
> 
> James
> 



smime.p7s
Description: S/MIME cryptographic signature

Re: Why are my por definitions still out of date after this?

[Gerben Wierda]

> On 22 Feb 2020, at 13:32, Christopher Jones  wrote:
> 
> Have you told macports to use your git clone ?
> 
> i.e. 
> 
>  > cat /opt/local/etc/macports/sources.conf
> 
> #rsync://rsync.macports.org/macports/release/tarballs/ports.tar 
>  [default]
> file:///Users/chris/Projects/MacPorts/ports 
>  [default]
> 
> where for me /Users/chris/Projects/MacPorts/ports is my local git clone.

Yes.

file:///Users/sysbh/MacPortsDev/macports-ports
rsync://rsync.macports.org/macports/release/tarballs/ports.tar [default]

> b.t.w. Once you have done this, you don’t need to run all the git commands 
> below. just running
> 
> > sudo port sync
> 
> will update your git clone, and run the portindex, for you.

With rsync, not with git. So what about branches etc? Suppose I create a branch 
in my fork to work in? And I want update my master to reflect the latest 
situation of the official repo?

G

> 
> Chris
> 
>> On 22 Feb 2020, at 11:43 am, Gerben Wierda > > wrote:
>> 
>> I have my own fork of the macports-ports repository on GitHub so I can do 
>> maintenance. I have a local clone of that fork
>> 
>> When I want to update ports I do not maintain, do the following. First I 
>> make sure my clone is up to date with the upstream original, then I push the 
>> clone back to my GitHub fork. Then I run portindex. ‘upstream’ is the 
>> official repo, origin is my fork
>> git fetch upstream
>> git checkout master
>> git reset --hard upstream/master
>> git push origin master --force
>> portindex
>>  
>> But when I do that, I still get:
>> 
>> albus:macports-ports sysbh$ port list updated
>> Warning: port definitions are more than two weeks old, consider updating 
>> them by running 'port selfupdate'.
>> 
>> (Should have said ‘outdated’ of course, this doesn’t give me a warning)
>> 
>> But port self update overwrites everything using rsync and doesn’t go via 
>> git. So, it is a parallel and possibly trouble-creating route. I want update 
>> my local tree entirely via git.
>> 
>> Still, with a clean clone of of an up-to-date fork, I can do it:
>> 
>> sudo port selfupdate
>> Password:
>> --->  Updating MacPorts base sources using rsync
>> MacPorts base version 2.6.2 installed,
>> MacPorts base version 2.6.2 downloaded.
>> --->  Updating the ports tree
>> --->  MacPorts base is already the latest version
>> 
>> What is the way to go when updating, using your own clone of your own fork 
>> of the git repo?
>> 
>> G
> 

Re: Dovecot port changes

[Rainer Müller]

On 22.02.20 12:41, Gerben Wierda wrote:
> port dovecot is now installing dovecot 2
> port dovecot2 is now installing dovecot 1

No, there is no Dovecot 1.x i the ports tree any more.

dovecot2 is a port that has been marked as replaced_by dovecot. As the
epoch was increased, it will be considered more recent than the old 2.x
version, although it reads 1.x. I agree this might be a bit confusing,
but it should work as intended.

This is the usual way port removal or renames are handled and eventually
the dovecot port will be removed completely as already noted in the
Portfile.

Rainer

Re: Dovecot port changes

[Steven Smith]

Just do:

port uninstall dovecot2 dovecot2-sieve
port clean --all dovecot2 dovecot2-sieve
port install dovecot +solr +…
port install dovecot-sieve

A strong downvote to anything named “dovecot3” when and if version 3 ever 
appears. At that time dovecot version 2 will be obsolete, which is how we got 
painted into this port naming corner in the first place.

Dovecot version 1 is unsupported and unsafe to expose.

> On Feb 22, 2020, at 07:00, Gerben Wierda  wrote:
> 
> Follow-up suggestion:
> 
> Clone port dovecot2 to a new port dovecot1 now
> 
> Whenever dovecot major release 3 appears:
> 
> Clone the existing dovecot to new port dovecot2
> Update dovecot port to dovecot 3
> 
> Is there a mechanism in MacPorts to block automatic update activations when 
> new versions of software require a different configuration and automatic 
> conversion is not possible? Should there be one?
> 
>> On 22 Feb 2020, at 12:41, Gerben Wierda  wrote:
>> 
>> port dovecot is now installing dovecot 2
>> port dovecot2 is now installing dovecot 1
>> 
>> The change breaks ‘port update outdated’ as the existence of a dovecot2 
>> install will prevent the installation of dovecot which now has become a 
>> dependency for other ports instead of dovecot2. dovecot2-sive is likewise 
>> replaced by dovecot-sieve with identical issues.
>> 
>> The only luck I have now is that the update failed so my existing dovecot2 
>> is still running and I can thus I can still read mail (including replies to 
>> this).
>> 
>> Yes, making sure that the port dovecot installs dovecot 2 (current) is 
>> cleaner (letting port dovecot2 install dovecot 1 is bad). But is that worth 
>> this mess? Instead of a nice and simple update, I have (unexpectedly, if I 
>> had known I could have prepared) to figure out the new setup, variants, etc. 
>> And given that the upgrade failed halfway, I have a messed up MacPorts 
>> landscape and I (unexpectedly) have to spend (unplanned) time on this. 
>> Spending time on it is  not the problem. Unexpected, because of a strictly 
>> sproken unnecessary cosmetic change, is.
>> 
>> G
> 


smime.p7s
Description: S/MIME cryptographic signature

catalena

[James Linder]

Hi All

After 6 years my macbook battery is really past it’s use-by.
The keyboard has become a sea of won’t-push-this-week-and-hard-to-get-a-keypush 
so I decided to get a new laptop, but of course it comes with catalena.
I’ve been using high sierra and all my ports are good. Is catalena now stable 
enough to ‘just work’ or need I consider installing (say) high sierra.

James

Re: Why are my por definitions still out of date after this?

[Christopher Jones]

Have you told macports to use your git clone ?

i.e. 

 > cat /opt/local/etc/macports/sources.conf

#rsync://rsync.macports.org/macports/release/tarballs/ports.tar [default]
file:///Users/chris/Projects/MacPorts/ports [default]

where for me /Users/chris/Projects/MacPorts/ports is my local git clone.

b.t.w. Once you have done this, you don’t need to run all the git commands 
below. just running

> sudo port sync

will update your git clone, and run the portindex, for you.

Chris

> On 22 Feb 2020, at 11:43 am, Gerben Wierda  wrote:
> 
> I have my own fork of the macports-ports repository on GitHub so I can do 
> maintenance. I have a local clone of that fork
> 
> When I want to update ports I do not maintain, do the following. First I make 
> sure my clone is up to date with the upstream original, then I push the clone 
> back to my GitHub fork. Then I run portindex. ‘upstream’ is the official 
> repo, origin is my fork
> git fetch upstream
> git checkout master
> git reset --hard upstream/master
> git push origin master --force
> portindex
>  
> But when I do that, I still get:
> 
> albus:macports-ports sysbh$ port list updated
> Warning: port definitions are more than two weeks old, consider updating them 
> by running 'port selfupdate'.
> 
> (Should have said ‘outdated’ of course, this doesn’t give me a warning)
> 
> But port self update overwrites everything using rsync and doesn’t go via 
> git. So, it is a parallel and possibly trouble-creating route. I want update 
> my local tree entirely via git.
> 
> Still, with a clean clone of of an up-to-date fork, I can do it:
> 
> sudo port selfupdate
> Password:
> --->  Updating MacPorts base sources using rsync
> MacPorts base version 2.6.2 installed,
> MacPorts base version 2.6.2 downloaded.
> --->  Updating the ports tree
> --->  MacPorts base is already the latest version
> 
> What is the way to go when updating, using your own clone of your own fork of 
> the git repo?
> 
> G



smime.p7s
Description: S/MIME cryptographic signature

Re: Dovecot port changes

[Gerben Wierda]

Follow-up suggestion:

Clone port dovecot2 to a new port dovecot1 now

Whenever dovecot major release 3 appears:

Clone the existing dovecot to new port dovecot2
Update dovecot port to dovecot 3

Is there a mechanism in MacPorts to block automatic update activations when new 
versions of software require a different configuration and automatic conversion 
is not possible? Should there be one?

> On 22 Feb 2020, at 12:41, Gerben Wierda  wrote:
> 
> port dovecot is now installing dovecot 2
> port dovecot2 is now installing dovecot 1
> 
> The change breaks ‘port update outdated’ as the existence of a dovecot2 
> install will prevent the installation of dovecot which now has become a 
> dependency for other ports instead of dovecot2. dovecot2-sive is likewise 
> replaced by dovecot-sieve with identical issues.
> 
> The only luck I have now is that the update failed so my existing dovecot2 is 
> still running and I can thus I can still read mail (including replies to 
> this).
> 
> Yes, making sure that the port dovecot installs dovecot 2 (current) is 
> cleaner (letting port dovecot2 install dovecot 1 is bad). But is that worth 
> this mess? Instead of a nice and simple update, I have (unexpectedly, if I 
> had known I could have prepared) to figure out the new setup, variants, etc. 
> And given that the upgrade failed halfway, I have a messed up MacPorts 
> landscape and I (unexpectedly) have to spend (unplanned) time on this. 
> Spending time on it is  not the problem. Unexpected, because of a strictly 
> sproken unnecessary cosmetic change, is.
> 
> G

Why are my por definitions still out of date after this?

[Gerben Wierda]

I have my own fork of the macports-ports repository on GitHub so I can do 
maintenance. I have a local clone of that fork

When I want to update ports I do not maintain, do the following. First I make 
sure my clone is up to date with the upstream original, then I push the clone 
back to my GitHub fork. Then I run portindex. ‘upstream’ is the official repo, 
origin is my fork
git fetch upstream
git checkout master
git reset --hard upstream/master
git push origin master --force
portindex
 
But when I do that, I still get:

albus:macports-ports sysbh$ port list updated
Warning: port definitions are more than two weeks old, consider updating them 
by running 'port selfupdate'.

(Should have said ‘outdated’ of course, this doesn’t give me a warning)

But port self update overwrites everything using rsync and doesn’t go via git. 
So, it is a parallel and possibly trouble-creating route. I want update my 
local tree entirely via git.

Still, with a clean clone of of an up-to-date fork, I can do it:

sudo port selfupdate
Password:
--->  Updating MacPorts base sources using rsync
MacPorts base version 2.6.2 installed,
MacPorts base version 2.6.2 downloaded.
--->  Updating the ports tree
--->  MacPorts base is already the latest version

What is the way to go when updating, using your own clone of your own fork of 
the git repo?

G

Dovecot port changes

[Gerben Wierda]

port dovecot is now installing dovecot 2
port dovecot2 is now installing dovecot 1

The change breaks ‘port update outdated’ as the existence of a dovecot2 install 
will prevent the installation of dovecot which now has become a dependency for 
other ports instead of dovecot2. dovecot2-sive is likewise replaced by 
dovecot-sieve with identical issues.

The only luck I have now is that the update failed so my existing dovecot2 is 
still running and I can thus I can still read mail (including replies to this).

Yes, making sure that the port dovecot installs dovecot 2 (current) is cleaner 
(letting port dovecot2 install dovecot 1 is bad). But is that worth this mess? 
Instead of a nice and simple update, I have (unexpectedly, if I had known I 
could have prepared) to figure out the new setup, variants, etc. And given that 
the upgrade failed halfway, I have a messed up MacPorts landscape and I 
(unexpectedly) have to spend (unplanned) time on this. Spending time on it is  
not the problem. Unexpected, because of a strictly sproken unnecessary cosmetic 
change, is.

G

Re: Problems with not finding Framework header files on Mojave 10.14.6

[Greg Earle]

On 22 Feb 2020, at 0:46, Joshua Root wrote:


Greg Earle wrote:


I have Xcode 10.3 installed on it (to ensure it installed the 10.14.6
SDK).


Xcode 11 should also be OK as long as you have the Command Line Tools
installed, which will provide the 10.14 SDK.

Warning: The macOS 10.14 SDK does not appear to be installed. Ports 
may

not build correctly.


This warning is generated by this code:


It's triggered by the SDK that was found not being called
"MacOSX10.14.sdk".  We always try to use an SDK with the version in 
its
name if at all possible, since we don't know which version 
"MacOSX.sdk"

actually is.

On my 10.14 system, this is the situation in the CLTs' SDKs directory:

% ls -l /Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk
lrwxr-xr-x  1 root  wheel  10  4 Oct 13:30
/Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk -> MacOSX.sdk

i.e. MacOSX10.14.sdk exists as a symlink.

The log likely contains more relevant information; please post the 
whole

thing to a pastebin so we can take a look.


Thanks "Joshua".  ;-)  I actually do have the "MacOSX10.14.sdk" 
symlink(s).


I found the problem.  Got lucky with a random set of search strings, I 
guess.


The problem is described on this page:

https://donatstudios.com/MojaveMissingHeaderFiles

--
Force re-install the header files:

$ sudo installer -pkg 
/Library/Developer/CommandLineTools/Packages/macOS_SDK_headers_for_macOS_10.14.pkg 
-target /

--

Neither my work dev system or my work desktop system (both Mojave) had 
the headers installed under /System/Library/Frameworks like they were 
supposed to be.  I guess the Command Line Tools installer didn't put 
them there.  No idea why not.


Running the above command fixed both my non-MacPorts build issues as 
well as not being able to do a "port install mercurial".  (Now if 
someone would just fix the busted mozjs60 port so I could upgrade 
policykit ... )


Thanks and sorry for the long/noise OP,

- Greg

Re: Problems with not finding Framework header files on Mojave 10.14.6

[Joshua Root]

Greg Earle wrote:
> I have Xcode 10.3 installed on it (to ensure it installed the 10.14.6 
> SDK).

Xcode 11 should also be OK as long as you have the Command Line Tools
installed, which will provide the 10.14 SDK.

> Warning: The macOS 10.14 SDK does not appear to be installed. Ports may 
> not build correctly.

This warning is generated by this code:


It's triggered by the SDK that was found not being called
"MacOSX10.14.sdk". We always try to use an SDK with the version in its
name if at all possible, since we don't know which version "MacOSX.sdk"
actually is.

On my 10.14 system, this is the situation in the CLTs' SDKs directory:

% ls -l /Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk
lrwxr-xr-x  1 root  wheel  10  4 Oct 13:30
/Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk -> MacOSX.sdk

i.e. MacOSX10.14.sdk exists as a symlink.

The log likely contains more relevant information; please post the whole
thing to a pastebin so we can take a look.

- Josh