Re: problem with reactivating ports

[Werner LEMBERG]

Hello Ryan!


> Do you need those old inactive versions?  If not, you could
> uninstall the inactive ports before beginning the exercise.

Is there a safe command to uninstall all inactive ports in one rush?

>> Irrespective of the problems I wonder whether it is a valid
>> approach to deactivate everything – since `port' started with zero
>> packages at the very beginning, it should work, right?
> 
> Yes, deactivating all ports should work successfully. We do that on
> the buildbot workers after every build.

Verified thanks, after building `port' with an external curl library
(I used https://try.gitea.io/donbright/lm for my Lion box).

>> Ah, my fault, I was imprecise: `port' complained not being able to
>> deactivate `libgcc8' because it wasn't active.  This implies that
>> `port' has implicitly already deactivated it and then stumbled over
>> the direct command to deactivate.
> 
> I have seen this error with libgcc8 on the buildbot workers as well.
> I think we probably forgot a step back when the libgcc7/libgcc8
> ports were introduced.  For example, we may have forgotten to
> increase the revision of all the ports that depend on those ports.

OK, thanks for the info.

> Of course, macOS is not GNU/Linux and there are some differences.
> For example, whereas GNU/Linux uses its package manager to install
> everything, macOS comes with libraries like libcurl that are not
> managed by a package manager and we use them.  There is no need to
> link with them statically, nor do we want to, for all the usual
> reasons: If that library is ever updated by Apple, we would not
> benefit from that update.

Well, this is true for MacOS versions still supported by Apple, but
not for older ones.  I'm glad that MacPorts is on the conservative
side.  For the young kids who always use the newest stuff there is
Homebrew...

> The problem only arises when you do something unsupported, like
> linking MacPorts to libraries it itself installed. Please don't do
> that! :)

Lesson learned :-)

> I continue to believe that we should bundle a recent version of curl
> and libressl with MacPorts to avoid the too-old-openssl problem that
> we see on older macOS systems, but we have not reached consensus
> that we want to do that.  See https://trac.macports.org/ticket/51516

Yes!  Actually, I don't understand the many objections raised in the
ticket.  For older MacOS versions, `macports-base' could be configured
to build private, statically linked libcurl & ssl versions only once,
namely for `port' itself – let's call the resulting binary
`port-bootstrap' –, and there would be no need to always use the most
recent and most secure versions since you only use it to start
MacPorts package management.  The first action could be then to
download a `port' package (which doesn't exist yet) that uses the most
recent libraries, and which receives the usual updates.  If someone is
going to delete that `port' package accidentally, the original
`port-bootstrap' binary would be still available as a backup.

>> I want to document how to build.  Compiling all lilypond flavours
>> from scratch (including documentation) takes almost a day (using
>> approx. 20GByte of disk space), so it is quite important to know
>> what MacPorts packages must be installed before starting
>> compilation for obvious reasons.  [...]
> 
> I don't think there's a good way to figure that out automatically.
> [...]

OK, thanks.


Werner

Re: conflicting variants while rebuilding a dependency

[Joshua Root]

On 2019-1-14 09:59 , Riccardo Mottola wrote:
> Hi Joshua,
> 
> On 2019-01-13 02:04:30 +0100 Joshua Root  wrote:
> 
>>
>>> The following ports are currently installed:
>>>     gexiv2 @0.10.8_1+python27+python36 (active)
>>
>>> So, I suppose that when it was installed, the two python variants
>>> were possible, but now now anymore?
>>
>> It's boost complaining about conflicting variants, not gexiv2.
>>
>> What variants is boost installed with? Do you have anything in
>> variants.conf?
> 
> I dont't currently have boost installed so it is a new dependency for me.
> 
> $ port installed boost
> None of the specified ports are installed.
> 
> You can see that from here:
> 
> --->  Computing dependencies for gexiv2
> The following dependencies will be installed:
>  boost
>  ctags
>  gtk-doc
>  py36-anytree
>  py36-lxml
>  py36-pygments
>  py36-setuptools
>  py36-six
>  pygments_select
>  source-highlight

Hmm. I assumed all the dependencies must have already been installed,
since gexiv2 must itself be installed for rev-upgrade to be operating on
it. In that case the installed variants from gexiv2 must be getting
passed down to its dependencies? I'm not sure that ought to happen.

In any case, that should mean if you install boost first, the issue will
be circumvented.

- Josh

Re: conflicting variants while rebuilding a dependency

[Ryan Schmidt]

Remember to use our list addresses at lists.macports.org, not any other 
hostname that we may have used in the past.


On Jan 13, 2019, at 16:54, Riccardo Mottola wrote:

> gexiv2 is a dependency for me, I never installed it directly.
> 
>> gexiv2 still has both variants enabled by default. In some ports this
>> is allowed, but in many it is not, if nothing else because one cannot
>> run a single configure step that would enable two python versions.
>> I didn't test, but I assume that you might be able to do
>>sudo port install gexiv2
> 
> I suppose it would work, since:
> 
> sudo port install gexiv2
> Password:
> --->  Computing dependencies for gexiv2
> The following dependencies will be installed:
> boost
> ctags
> gtk-doc
> py36-anytree
> py36-lxml
> py36-pygments
> py36-setuptools
> py36-six
> pygments_select
> source-highlight
> Continue? [Y/n]: n
> 
>> but not
>>sudo port install gexiv2 +python27 +python36
>> if some of the dependencies with python variants are not yet
>> installed, or waiting for update.
> 
> If I issue that it will ineed fails.
> 
>> This might well be a bug, or rather an unfortunate coincidence with no
>> easy workaround.
>> What happens if you clean all the ports and run
>>sudo port install gexiv2
>> manually instead of waiting for rev-upgrade?
> 
> sudo port clean all!
> that is a long command to run, even on a SSD!
> 
> I did a full clean and tried to install
> sudo port install gexiv2 +python27 +python36
> 
> again but it did not help!

If the boost port is not yet installed (as the above output suggests it is 
not), then that failure is expected. MacPorts passes the variant selection down 
to ports that are not yet installed. If you tell gexiv2 to install with 
variants +python27 and +python36, MacPorts will tell any ports in the recursive 
dependency tree of gexiv2 that are not yet installed to install with those 
variants as well. gexiv2 supports building with one python2x variant and one 
python3x variant, but boost only supports building with a single python variant 
regardless of version, hence the error message you received.

Re: conflicting variants while rebuilding a dependency

[Riccardo Mottola via macports-users]

Hi Joshua,

On 2019-01-13 02:04:30 +0100 Joshua Root  wrote:




The following ports are currently installed:
gexiv2 @0.10.8_1+python27+python36 (active)


So, I suppose that when it was installed, the two python variants 
were 
possible, but now now anymore?


It's boost complaining about conflicting variants, not gexiv2.

What variants is boost installed with? Do you have anything in
variants.conf?


I dont't currently have boost installed so it is a new dependency for 
me.


$ port installed boost
None of the specified ports are installed.

You can see that from here:

--->  Computing dependencies for gexiv2
The following dependencies will be installed:
 boost
 ctags
 gtk-doc
 py36-anytree
 py36-lxml
 py36-pygments
 py36-setuptools
 py36-six
 pygments_select
 source-highlight


Riccardo

Re: problem with reactivating ports

[Ryan Schmidt]

On Jan 13, 2019, at 10:03, Werner LEMBERG wrote:

> It's simpler, yes, but why is it `much better'?  As far as I
> understand, later on I can't simply say
> 
>  sudo port activate inactive
> 
> since the list of inactive ports is much larger due to updates.  In
> other words, I have to store the list of active packages somewhere.

What you did -- recording active files into a text file for later reactivation 
-- is fine, and is similar to what we recommend users do in our migration 
instructions.

Do you need those old inactive versions? If not, you could uninstall the 
inactive ports before beginning the exercise. However, keeping a record in a 
text file, as you did, is still a good idea, in case anything goes wrong and 
the complete set of ports doesn't get reactivated.


>>> It seems now that this was actually a bad idea.  First of all,
>>> `port' aborted in the middle, talking about not being able to
>>> deactivate `libgcc8' (which is on the `macports.active' list).
>> 
>> I'm not really sure, but one thing that might happen is that the
>> list of ports to be deactivated comes in wrong order.  If B depends
>> on A and you call
>> 
>>sudo port deactivate A B
>> 
>> then I might fail to deactivate since port is processing them in the
>> same order as they are written and complains that B depends on A, so
>> A cannot be deactivated unless you force it or run it in a recursive
>> way.
> 
> Hmm.  Shouldn't `port' handle such situations gracefully?  It gets all
> packages to be deactivated as a single call, it thus can reorder as
> necessary.

As far as I know, MacPorts does reorder the ports into the correct order.


> Irrespective of the problems I wonder whether it is a valid approach
> to deactivate everything – since `port' started with zero packages at
> the very beginning, it should work, right?

Yes, deactivating all ports should work successfully. We do that on the 
buildbot workers after every build.


>> (Reading further, another reason could be that the ports you tried
>> to deactivate cannot be deactivated as they are needed for the port
>> command itself.)
> 
> Ah, my fault, I was imprecise: `port' complained not being able to
> deactivate `libgcc8' because it wasn't active.  This implies that
> `port' has implicitly already deactivated it and then stumbled over
> the direct command to deactivate.

I have seen this error with libgcc8 on the buildbot workers as well. I think we 
probably forgot a step back when the libgcc7/libgcc8 ports were introduced. For 
example, we may have forgotten to increase the revision of all the ports that 
depend on those ports.


>> If you want to use a different libcurl, you could install that
>> libcurl somewhere else.  You can install two parallel macports (just
>> make sure that you configure it properly to avoid clashes in
>> /Applications/MacPorts, disable the services etc.) and then use one
>> of them just as "supporting system" for the other one.  We would
>> have fixed this long ago if it wasn't for the chicken-and-egg issue
>> :)
> 
> Yes, this was explained to me on the list, but I was too lazy to go
> that route.  Now the issue knocked me down :-) IMHO, the best solution
> would be to build a statically linked `port' program that is immune to
> DLL problems – AFAIK, most GNU/Linux distributions do exactly that for
> the central package manager (zypper, apt, rpm, etc.)

Of course, macOS is not GNU/Linux and there are some differences. For example, 
whereas GNU/Linux uses its package manager to install everything, macOS comes 
with libraries like libcurl that are not managed by a package manager and we 
use them. There is no need to link with them statically, nor do we want to, for 
all the usual reasons: If that library is ever updated by Apple, we would not 
benefit from that update.

The problem only arises when you do something unsupported, like linking 
MacPorts to libraries it itself installed. Please don't do that! :)

I continue to believe that we should bundle a recent version of curl and 
libressl with MacPorts to avoid the too-old-openssl problem that we see on 
older macOS systems, but we have not reached consensus that we want to do that. 
See https://trac.macports.org/ticket/51516


>>> * Is there a simple way to protocol needed MacPorts packages?
>> 
>> Needed by/for what? You can list recursive dependencies, inside the
>> port you can run trace mode to make sure that no other files are
>> used, listing active packages is possible (but note that you'll
>> probably end up with build dependencies as well if you are building
>> from source ...)
> 
> I want to build `gub', the lilypond packager.  Assuming that it works
> I want to document how to build.  Compiling all lilypond flavours from
> scratch (including documentation) takes almost a day (using
> approx. 20GByte of disk space), so it is quite important to know what
> MacPorts packages must be installed before starting compilation for
> obvious reasons.
> 
> As an example, I can't 

Re: conflicting variants while rebuilding a dependency

[Riccardo Mottola via macports-users]

Hi Moja,

On 2019-01-12 20:39:08 +0100 Mojca Miklavec  wrote:

I did some "tests" to get further information. It may not be a bug, 
just an inconvenience. I still think users should be able to usually 
just "upgrade".


gexiv2 is a dependency for me, I never installed it directly.



gexiv2 still has both variants enabled by default. In some ports this
is allowed, but in many it is not, if nothing else because one cannot
run a single configure step that would enable two python versions.

I didn't test, but I assume that you might be able to do
sudo port install gexiv2


I suppose it would work, since:

sudo port install gexiv2
Password:
--->  Computing dependencies for gexiv2
The following dependencies will be installed:
 boost
 ctags
 gtk-doc
 py36-anytree
 py36-lxml
 py36-pygments
 py36-setuptools
 py36-six
 pygments_select
 source-highlight
Continue? [Y/n]: n


but not
sudo port install gexiv2 +python27 +python36
if some of the dependencies with python variants are not yet
installed, or waiting for update.


If I issue that it will ineed fails.


This might well be a bug, or rather an unfortunate coincidence with no
easy workaround.
What happens if you clean all the ports and run
sudo port install gexiv2
manually instead of waiting for rev-upgrade?


sudo port clean all!
that is a long command to run, even on a SSD!

I did a full clean and tried to install
sudo port install gexiv2 +python27 +python36

again but it did not help!

Riccardo

Re: Wine-devel build failed

[Ryan Schmidt]

On Jan 12, 2019, at 05:24, Giuseppe Di Matteo wrote:

> Le 11 janv. 2019 à 07:13, Ryan Schmidta écrit :
> 
>> On Jan 10, 2019, at 12:35, Giuseppe Di Matteo wrote:
>> 
>>> The wine-level install failed at xattr dependency build.
>>> High Sierra (10.13.6). Xcode 10.1 MacPorts 2.5.4
>> 
>> The xattr port is needed on Mac OS X 10.4 Tiger only. On Mac OS X 10.5 
>> Leopard and later, xattr is included with the operating system. So I don't 
>> understand why an installation of the xattr port is being attempted in your 
>> case on High Sierra which doesn't need it. What command did you run that 
>> caused this to happen? And does /usr/bin/xattr exist?
> 
> I’ve ran this command: sudo port install -v rdepof:wine-devel as from 
> https://wiki.winehq.org/MacOS/Building.

Ok, don't do that. :)

Looks like they're suggesting that as a way to get the dependencies of wine 
using MacPorts, if you want to install wine outside of MacPorts. For that use 
case, we may want to consider modifying the xattr port to just be a shim around 
the macOS copy of xattr, since this is not the first time this problem has been 
brought to our attention.


> But just sudo port install wine-devel is okay.

Yes that's what you should do if you want to use wine from MacPorts.

Re: Some glitches while porting Ola (openlighting.org) - autoreconf not found

[Mojca Miklavec]

On Sun, 13 Jan 2019 at 10:07, Christoph Kukulies wrote:
>
> I got it working (port install ola) finally by following the latest 
> suggestion in the port output (deactivate py27-protobuf)

Thanks for the logs. I added the missing conflict between
py27-protobuf and py27-protobuf3:
https://github.com/macports/macports-ports/pull/3415

> Looking forward to what else might be broken after this :-(
> At least port install ola went through now.

I'm glad that it worked. Let us know if anything else needs to be
fixed. I would suggest to ask the ola developers to change the
instructions, at least in the way that won't ask users to install the
ports that are not conflicting with the real dependencies.

Mojca

Re: problem with reactivating ports

[Werner LEMBERG]

Hello Mojca,


thanks for replying!

>>   port echo active > macports.active
>>   sudo port deactivate `cat macports.active`
>>
>> to deactivate all MacPorts packages.  I tried with the `-y' flag in
>> advance, just to be sure...
> 
> I understand the first command, but a much better way for the second
> one would be
>
> sudo port deactivate active

It's simpler, yes, but why is it `much better'?  As far as I
understand, later on I can't simply say

  sudo port activate inactive

since the list of inactive ports is much larger due to updates.  In
other words, I have to store the list of active packages somewhere.

>> It seems now that this was actually a bad idea.  First of all,
>> `port' aborted in the middle, talking about not being able to
>> deactivate `libgcc8' (which is on the `macports.active' list).
> 
> I'm not really sure, but one thing that might happen is that the
> list of ports to be deactivated comes in wrong order.  If B depends
> on A and you call
>
> sudo port deactivate A B
>
> then I might fail to deactivate since port is processing them in the
> same order as they are written and complains that B depends on A, so
> A cannot be deactivated unless you force it or run it in a recursive
> way.

Hmm.  Shouldn't `port' handle such situations gracefully?  It gets all
packages to be deactivated as a single call, it thus can reorder as
necessary.

Irrespective of the problems I wonder whether it is a valid approach
to deactivate everything – since `port' started with zero packages at
the very beginning, it should work, right?

> (Reading further, another reason could be that the ports you tried
> to deactivate cannot be deactivated as they are needed for the port
> command itself.)

Ah, my fault, I was imprecise: `port' complained not being able to
deactivate `libgcc8' because it wasn't active.  This implies that
`port' has implicitly already deactivated it and then stumbled over
the direct command to deactivate.

>>  Secondly, restarting `port' no longer works; [...]
>
> This is somewhat strange.  This is my blind guess [...]

Yes, this is it, I presume.  Will work on that soon.

> If you want to use a different libcurl, you could install that
> libcurl somewhere else.  You can install two parallel macports (just
> make sure that you configure it properly to avoid clashes in
> /Applications/MacPorts, disable the services etc.) and then use one
> of them just as "supporting system" for the other one.  We would
> have fixed this long ago if it wasn't for the chicken-and-egg issue
> :)

Yes, this was explained to me on the list, but I was too lazy to go
that route.  Now the issue knocked me down :-) IMHO, the best solution
would be to build a statically linked `port' program that is immune to
DLL problems – AFAIK, most GNU/Linux distributions do exactly that for
the central package manager (zypper, apt, rpm, etc.)

>> * Is there a simple way to protocol needed MacPorts packages?
> 
> Needed by/for what? You can list recursive dependencies, inside the
> port you can run trace mode to make sure that no other files are
> used, listing active packages is possible (but note that you'll
> probably end up with build dependencies as well if you are building
> from source ...)

I want to build `gub', the lilypond packager.  Assuming that it works
I want to document how to build.  Compiling all lilypond flavours from
scratch (including documentation) takes almost a day (using
approx. 20GByte of disk space), so it is quite important to know what
MacPorts packages must be installed before starting compilation for
obvious reasons.

As an example, I can't directly start `gub' because Lion's python
version is too old.  I thus have to install `python' via MacPorts
before I can explore what else is missing.


Werner

Re: problem with reactivating ports

[Mojca Miklavec]

Dear Werner,

On Sun, 13 Jan 2019 at 14:26, Werner LEMBERG wrote:
>
> I wanted to compile a project under MacPorts, and at the same time I
> wanted to protocol what MacPorts packages must be installed in advance
> before starting compilation.  My glorious idea was to say
>
>   port echo active > macports.active
>   sudo port deactivate `cat macports.active`
>
> to deactivate all MacPorts packages.  I tried with the `-y' flag in
> advance, just to be sure...

I understand the first command, but a much better way for the second
one would be
sudo port deactivate active

> It seems now that this was actually a bad idea.  First of all, `port'
> aborted in the middle, talking about not being able to deactivate
> `libgcc8' (which is on the `macports.active' list).

I'm not really sure, but one thing that might happen is that the list
of ports to be deactivated comes in wrong order. If B depends on A and
you call
sudo port deactivate A B
then I might fail to deactivate since port is processing them in the
same order as they are written and complains that B depends on A, so A
cannot be deactivated unless you force it or run it in a recursive
way.

(Reading further, another reason could be that the ports you tried to
deactivate cannot be deactivated as they are needed for the port
command itself.)

>  Secondly,
> restarting `port' no longer works; it complains as follows
>
>   dlopen(/opt/local/libexec/macports/lib/pextlib1.0/Pextlib.dylib, 6):
> Library not loaded: /opt/local/lib/libcurl.4.dylib
>   Referenced from: /opt/local/libexec/macports/lib/pextlib1.0/Pextlib.dylib
>   Reason: Incompatible library version:
> Pextlib.dylib requires version 10.0.0 or later,
> but libcurl.4.dylib provides version 7.0.0

This is somewhat strange. This is my blind guess / speculation of what
you did (I might be wrong). 10.7 became nearly hopeless with respect
to fetching the sources (distfiles) after the servers started
requiring a newer version of SSL protocol than what 10.7 can handle by
default. So you probably recompiled MacPorts with something like
--with-curl=/opt/local, but making a self-reference, and you ended up
with a chicken-and-egg problem?

> As a first aid I tried to re-install `port' from `macports-base', but
> I still get this error.
>
> My questions.
>
> * How can I restore (i.e., re-activate) all installed MacPorts
>   packages?  Given that I'm on Lion, I would *really* avoid
>   recompiling everything from scratch...

If you want to avoid recompiling the ports themselves, it would
probably make most sense to recompile macports (without
--with-curl=/opt/local, or perhaps with another curl that's installed
elsewhere) and run the port command again.

If you want to use a different libcurl, you could install that libcurl
somewhere else. You can install two parallel macports (just make sure
that you configure it properly to avoid clashes in
/Applications/MacPorts, disable the services etc.) and then use one of
them just as "supporting system" for the other one. We would have
fixed this long ago if it wasn't for the chicken-and-egg issue :)

> * Is there a simple way to protocol needed MacPorts packages?

Needed by/for what? You can list recursive dependencies, inside the
port you can run trace mode to make sure that no other files are used,
listing active packages is possible (but note that you'll probably end
up with build dependencies as well if you are building from source
...)

Mojca

problem with reactivating ports

[Werner LEMBERG]

[macports running from git]


Folks,


I wanted to compile a project under MacPorts, and at the same time I
wanted to protocol what MacPorts packages must be installed in advance
before starting compilation.  My glorious idea was to say

  port echo active > macports.active
  sudo port deactivate `cat macports.active`

to deactivate all MacPorts packages.  I tried with the `-y' flag in
advance, just to be sure...

It seems now that this was actually a bad idea.  First of all, `port'
aborted in the middle, talking about not being able to deactivate
`libgcc8' (which is on the `macports.active' list).  Secondly,
restarting `port' no longer works; it complains as follows

  dlopen(/opt/local/libexec/macports/lib/pextlib1.0/Pextlib.dylib, 6):
Library not loaded: /opt/local/lib/libcurl.4.dylib
  Referenced from: /opt/local/libexec/macports/lib/pextlib1.0/Pextlib.dylib
  Reason: Incompatible library version:
Pextlib.dylib requires version 10.0.0 or later,
but libcurl.4.dylib provides version 7.0.0

As a first aid I tried to re-install `port' from `macports-base', but
I still get this error.

My questions.

* How can I restore (i.e., re-activate) all installed MacPorts
  packages?  Given that I'm on Lion, I would *really* avoid
  recompiling everything from scratch...

* Is there a simple way to protocol needed MacPorts packages?


Werner

Re: Some glitches while porting Ola (openlighting.org) - autoreconf not found

[Christoph Kukulies]

I got it working (port install ola) finally by following the latest suggestion 
in the port output (deactivate py27-protobuf)
Looking forward to what else might be broken after this :-(
At least port install ola went through now.

Thanks again,

Christoph



> Am 13.01.2019 um 09:58 schrieb Christoph Kukulies :
> 
> I did as you suggested: sudo port deactivate protobuf-cpp
> which worked
> 
> Christophs-MacBook-Pro: kuku$ sudo port deactivate protobuf-cpp
> Note: It is not recommended to uninstall/deactivate a port that has 
> dependents as it breaks the dependents.
> The following ports will break: py27-protobuf @2.6.1_2
> Continue? [y/N]: y
> Warning: Deactivate forced.  Proceeding despite dependencies.
> --->  Deactivating protobuf-cpp @2.6.1_0
> --->  Cleaning protobuf-cpp
> Christophs-MacBook-Pro:
> 
> 
> Then I’m getting:
> 
> Christophs-MacBook-Pro: kuku$ sudo port install ola
> --->  Computing dependencies for ola
> The following dependencies will be installed: 
>  automake
>  libftdi0
>  liblo
>  libtool
>  libusb-compat
>  protobuf3-cpp
>  py27-protobuf3
> Continue? [Y/n]: 
> --->  Fetching archive for automake
> Warning: Your DNS servers incorrectly claim to know the address of 
> nonexistent hosts. This may cause checksum mismatches for some ports. See 
> this page for more information: 
>  >
> --->  Attempting to fetch automake-1.16.1_0.darwin_18.noarch.tbz2 from 
> https://packages.macports.org/automake 
> 
> --->  Attempting to fetch automake-1.16.1_0.darwin_18.noarch.tbz2.rmd160 from 
> https://packages.macports.org/automake 
> 
> --->  Installing automake @1.16.1_0
> --->  Activating automake @1.16.1_0
> --->  Cleaning automake
> --->  Fetching archive for libusb-compat
> --->  Attempting to fetch libusb-compat-0.1.5_0.darwin_18.x86_64.tbz2 from 
> https://packages.macports.org/libusb-compat 
> 
> --->  Attempting to fetch libusb-compat-0.1.5_0.darwin_18.x86_64.tbz2.rmd160 
> from https://packages.macports.org/libusb-compat 
> 
> --->  Installing libusb-compat @0.1.5_0
> --->  Activating libusb-compat @0.1.5_0
> --->  Cleaning libusb-compat
> --->  Fetching archive for libftdi0
> --->  Attempting to fetch libftdi0-0.20_1.darwin_18.x86_64.tbz2 from 
> https://packages.macports.org/libftdi0 
> 
> --->  Attempting to fetch libftdi0-0.20_1.darwin_18.x86_64.tbz2.rmd160 from 
> https://packages.macports.org/libftdi0 
> 
> --->  Installing libftdi0 @0.20_1
> --->  Activating libftdi0 @0.20_1
> --->  Cleaning libftdi0
> --->  Fetching archive for liblo
> --->  Attempting to fetch liblo-0.28_0.darwin_18.x86_64.tbz2 from 
> https://packages.macports.org/liblo 
> --->  Attempting to fetch liblo-0.28_0.darwin_18.x86_64.tbz2.rmd160 from 
> https://packages.macports.org/liblo 
> --->  Installing liblo @0.28_0
> --->  Activating liblo @0.28_0
> --->  Cleaning liblo
> --->  Fetching archive for libtool
> --->  Attempting to fetch libtool-2.4.6_5.darwin_18.x86_64.tbz2 from 
> https://packages.macports.org/libtool 
> --->  Attempting to fetch libtool-2.4.6_5.darwin_18.x86_64.tbz2.rmd160 from 
> https://packages.macports.org/libtool 
> --->  Installing libtool @2.4.6_5
> --->  Activating libtool @2.4.6_5
> --->  Cleaning libtool
> --->  Fetching archive for protobuf3-cpp
> --->  Attempting to fetch protobuf3-cpp-3.6.1_0.darwin_18.x86_64.tbz2 from 
> https://packages.macports.org/protobuf3-cpp 
> 
> --->  Attempting to fetch protobuf3-cpp-3.6.1_0.darwin_18.x86_64.tbz2.rmd160 
> from https://packages.macports.org/protobuf3-cpp 
> 
> --->  Installing protobuf3-cpp @3.6.1_0
> --->  Activating protobuf3-cpp @3.6.1_0
> --->  Cleaning protobuf3-cpp
> --->  Fetching archive for py27-protobuf3
> --->  Attempting to fetch py27-protobuf3-3.6.1_0.darwin_18.x86_64.tbz2 from 
> https://packages.macports.org/py27-protobuf3 
> 
> --->  Attempting to fetch py27-protobuf3-3.6.1_0.darwin_18.x86_64.tbz2.rmd160 
> from https://packages.macports.org/py27-protobuf3 
> 
> --->  Installing py27-protobuf3 @3.6.1_0
> --->  Activating py27-protobuf3 @3.6.1_0
> Error: Failed to activate py27-protobuf3: Image error: 
> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/google/protobuf/__init__.py
>  is being used by the active py27-protobuf port.  Please deactivate this port 
> first, or use 'port -f activate py27-protobuf3' 

Re: Some glitches while porting Ola (openlighting.org) - autoreconf not found

[Christoph Kukulies]

I did as you suggested: sudo port deactivate protobuf-cpp
which worked

Christophs-MacBook-Pro: kuku$ sudo port deactivate protobuf-cpp
Note: It is not recommended to uninstall/deactivate a port that has dependents 
as it breaks the dependents.
The following ports will break: py27-protobuf @2.6.1_2
Continue? [y/N]: y
Warning: Deactivate forced.  Proceeding despite dependencies.
--->  Deactivating protobuf-cpp @2.6.1_0
--->  Cleaning protobuf-cpp
Christophs-MacBook-Pro:


Then I’m getting:

Christophs-MacBook-Pro: kuku$ sudo port install ola
--->  Computing dependencies for ola
The following dependencies will be installed: 
 automake
 libftdi0
 liblo
 libtool
 libusb-compat
 protobuf3-cpp
 py27-protobuf3
Continue? [Y/n]: 
--->  Fetching archive for automake
Warning: Your DNS servers incorrectly claim to know the address of nonexistent 
hosts. This may cause checksum mismatches for some ports. See this page for 
more information: 
--->  Attempting to fetch automake-1.16.1_0.darwin_18.noarch.tbz2 from 
https://packages.macports.org/automake
--->  Attempting to fetch automake-1.16.1_0.darwin_18.noarch.tbz2.rmd160 from 
https://packages.macports.org/automake
--->  Installing automake @1.16.1_0
--->  Activating automake @1.16.1_0
--->  Cleaning automake
--->  Fetching archive for libusb-compat
--->  Attempting to fetch libusb-compat-0.1.5_0.darwin_18.x86_64.tbz2 from 
https://packages.macports.org/libusb-compat
--->  Attempting to fetch libusb-compat-0.1.5_0.darwin_18.x86_64.tbz2.rmd160 
from https://packages.macports.org/libusb-compat
--->  Installing libusb-compat @0.1.5_0
--->  Activating libusb-compat @0.1.5_0
--->  Cleaning libusb-compat
--->  Fetching archive for libftdi0
--->  Attempting to fetch libftdi0-0.20_1.darwin_18.x86_64.tbz2 from 
https://packages.macports.org/libftdi0
--->  Attempting to fetch libftdi0-0.20_1.darwin_18.x86_64.tbz2.rmd160 from 
https://packages.macports.org/libftdi0
--->  Installing libftdi0 @0.20_1
--->  Activating libftdi0 @0.20_1
--->  Cleaning libftdi0
--->  Fetching archive for liblo
--->  Attempting to fetch liblo-0.28_0.darwin_18.x86_64.tbz2 from 
https://packages.macports.org/liblo
--->  Attempting to fetch liblo-0.28_0.darwin_18.x86_64.tbz2.rmd160 from 
https://packages.macports.org/liblo
--->  Installing liblo @0.28_0
--->  Activating liblo @0.28_0
--->  Cleaning liblo
--->  Fetching archive for libtool
--->  Attempting to fetch libtool-2.4.6_5.darwin_18.x86_64.tbz2 from 
https://packages.macports.org/libtool
--->  Attempting to fetch libtool-2.4.6_5.darwin_18.x86_64.tbz2.rmd160 from 
https://packages.macports.org/libtool
--->  Installing libtool @2.4.6_5
--->  Activating libtool @2.4.6_5
--->  Cleaning libtool
--->  Fetching archive for protobuf3-cpp
--->  Attempting to fetch protobuf3-cpp-3.6.1_0.darwin_18.x86_64.tbz2 from 
https://packages.macports.org/protobuf3-cpp
--->  Attempting to fetch protobuf3-cpp-3.6.1_0.darwin_18.x86_64.tbz2.rmd160 
from https://packages.macports.org/protobuf3-cpp
--->  Installing protobuf3-cpp @3.6.1_0
--->  Activating protobuf3-cpp @3.6.1_0
--->  Cleaning protobuf3-cpp
--->  Fetching archive for py27-protobuf3
--->  Attempting to fetch py27-protobuf3-3.6.1_0.darwin_18.x86_64.tbz2 from 
https://packages.macports.org/py27-protobuf3
--->  Attempting to fetch py27-protobuf3-3.6.1_0.darwin_18.x86_64.tbz2.rmd160 
from https://packages.macports.org/py27-protobuf3
--->  Installing py27-protobuf3 @3.6.1_0
--->  Activating py27-protobuf3 @3.6.1_0
Error: Failed to activate py27-protobuf3: Image error: 
/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/google/protobuf/__init__.py
 is being used by the active py27-protobuf port.  Please deactivate this port 
first, or use 'port -f activate py27-protobuf3' to force the activation.
Error: See 
/opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_python_py-protobuf3/py27-protobuf3/main.log
 for details.
Error: Follow https://guide.macports.org/#project.tickets to report a bug.
Error: Processing of port ola failed
Christophs-MacBook-Pro: kuku$ 


> Am 12.01.2019 um 19:09 schrieb Mojca Miklavec :
> 
> On Sat, 12 Jan 2019 at 17:45, Christoph Kukulies wrote:
>> 
>> Finally I tried:
>> 
>> Christophs-MBP:ola kuku$ sudo port install ola
>> Password:
>> --->  Computing dependencies for ola
>> Error: Can't install protobuf3-cpp because conflicting ports are active: 
>> protobuf-cpp
> 
> That's most likely the result of the manual installation of that port
> when you followed the installation instructions:
> 
># not asking you to repeat this!
>sudo port install pkgconfig cppunit protobuf-cpp libmicrohttpd
> libusb py27-protobuf
> 
> So most likely
>sudo port deactivate protobuf-cpp
> should solve the problem. If it doesn't, it will tell you which other
> ports depend on protobuf-cpp, and then you can check whether you can
> deactivate/uninstall those.
>