Re: mysql57, boost and postgresql84

[Michael Newman via macports-users]

I don’t know if it helps at all, but on October 24th I did the first steps of 
MacPorts migration in anticipation of installing Catalina. I never did install 
Catalina, but I saved the myports.txt and requested.txt files. They are here:

https://pastebin.com/cxM85Dq6 

https://pastebin.com/8sJafzKa 

This is before I did the reclaim that removed clamav.

> On Nov 9, 2019, at 09:40, Ryan Schmidt  wrote:
> 
> 
> 
> On Nov 8, 2019, at 20:31, Chris Jones  wrote:
> 
>> On 9 Nov 2019, at 1:39 am, Ryan Schmidt wrote:
>> 
>>> If you ran `sudo port install clamav`, and it was not already installed, 
>>> MacPorts should have marked it as requested. If clamav was automatically 
>>> installed as a dependency of something else, then it would not have been 
>>> marked requested.
>> 
>> That sounds like something we should fix to me. Is it not reasonable to 
>> expect the port in this case, even if it was previously installed as a 
>> dependency, to still be marked as requested in this case, as that is what 
>> the user did by asking for it to be installed. The fact it already was 
>> shouldn’t matter in terms of marking it as requested ?
> 
> If you mean that running `sudo port install` on a port that is already 
> installed should mark it as requested, then that's 
> https://trac.macports.org/ticket/55085.
> 

Re: mysql57, boost and postgresql84

[Ryan Schmidt]

On Nov 8, 2019, at 20:31, Chris Jones  wrote:

> On 9 Nov 2019, at 1:39 am, Ryan Schmidt wrote:
> 
>> If you ran `sudo port install clamav`, and it was not already installed, 
>> MacPorts should have marked it as requested. If clamav was automatically 
>> installed as a dependency of something else, then it would not have been 
>> marked requested.
> 
> That sounds like something we should fix to me. Is it not reasonable to 
> expect the port in this case, even if it was previously installed as a 
> dependency, to still be marked as requested in this case, as that is what the 
> user did by asking for it to be installed. The fact it already was shouldn’t 
> matter in terms of marking it as requested ?

If you mean that running `sudo port install` on a port that is already 
installed should mark it as requested, then that's 
https://trac.macports.org/ticket/55085.

Re: mysql57, boost and postgresql84

[Chris Jones]

> On 9 Nov 2019, at 1:39 am, Ryan Schmidt  wrote:
> 
> 
> 
>> On Nov 8, 2019, at 16:06, Michael Newman wrote:
>> 
>>> On Nov 7, 2019, at 06:34, Ryan Schmidt wrote:
>>> 
>>> If `port installed requested` shows things that you don't actually want, 
>>> tell MacPorts by marking them as not requested:
>>> 
>>> sudo port unsetrequested portname1 portname2 ...
>>> 
>>> Then `sudo port reclaim` will be able to uninstall them, if they're not 
>>> needed for anything else you've installed. Reclaim won't uninstall things 
>>> it thinks you want.
>> 
>> This set a little trap for me. For some reason, clamav, which I did request, 
>> was not shown as requested. So, when I ran reclaim, it was removed. I was 
>> puzzled at first when freshclam started to fail. I’ve reinstalled clamav now 
>> and all is well. Is there some reason why clamav would not be flagged as 
>> requested?
> 
> MacPorts' ability to automatically uninstall ports you don't want and keep 
> the ports you do want is only as good as the metadata recorded in the 
> registry. If it's wrong, you have to fix it.
> 
> If you ran `sudo port install clamav`, and it was not already installed, 
> MacPorts should have marked it as requested. If clamav was automatically 
> installed as a dependency of something else, then it would not have been 
> marked requested.

That sounds like something we should fix to me. Is it not reasonable to expect 
the port in this case, even if it was previously installed as a dependency, to 
still be marked as requested in this case, as that is what the user did by 
asking for it to be installed. The fact it already was shouldn’t matter in 
terms of marking it as requested ?

Chris 

> 
> You can also look through the list of allegedly unrequested ports:
> 
> port installed unrequested
> 
> If you actually do want any of the ports listed, mark them as requested:
> 
> sudo port setrequested portname1 portname2 ...
> 
> 

Re: mysql57, boost and postgresql84

[Ryan Schmidt]

On Nov 8, 2019, at 16:06, Michael Newman wrote:

> On Nov 7, 2019, at 06:34, Ryan Schmidt wrote:
> 
>> If `port installed requested` shows things that you don't actually want, 
>> tell MacPorts by marking them as not requested:
>> 
>> sudo port unsetrequested portname1 portname2 ...
>> 
>> Then `sudo port reclaim` will be able to uninstall them, if they're not 
>> needed for anything else you've installed. Reclaim won't uninstall things it 
>> thinks you want.
> 
> This set a little trap for me. For some reason, clamav, which I did request, 
> was not shown as requested. So, when I ran reclaim, it was removed. I was 
> puzzled at first when freshclam started to fail. I’ve reinstalled clamav now 
> and all is well. Is there some reason why clamav would not be flagged as 
> requested?

MacPorts' ability to automatically uninstall ports you don't want and keep the 
ports you do want is only as good as the metadata recorded in the registry. If 
it's wrong, you have to fix it.

If you ran `sudo port install clamav`, and it was not already installed, 
MacPorts should have marked it as requested. If clamav was automatically 
installed as a dependency of something else, then it would not have been marked 
requested.

You can also look through the list of allegedly unrequested ports:

port installed unrequested

If you actually do want any of the ports listed, mark them as requested:

sudo port setrequested portname1 portname2 ...

Re: mysql57, boost and postgresql84

[Michael Newman via macports-users]

> On Nov 7, 2019, at 06:34, Ryan Schmidt  > wrote:
> 
> If `port installed requested` shows things that you don't actually want, tell 
> MacPorts by marking them as not requested:
> 
> sudo port unsetrequested portname1 portname2 ...
> 
> Then `sudo port reclaim` will be able to uninstall them, if they're not 
> needed for anything else you've installed. Reclaim won't uninstall things it 
> thinks you want.
This set a little trap for me. For some reason, clamav, which I did request, 
was not shown as requested. So, when I ran reclaim, it was removed. I was 
puzzled at first when freshclam started to fail. I’ve reinstalled clamav now 
and all is well. Is there some reason why clamav would not be flagged as 
requested?

Re: installed port wants to rebuild

[Stanton Sanderson]

> On Nov 7, 2019, at 10:39 PM, Ryan Schmidt  wrote:
> 
> 
> 
> On Nov 7, 2019, at 21:23, Stan Sanderson wrote:
> 
>> OS X 10.14, all installed ports up-to-date.
>> Re: kmymoney4-devel
>> 
>> Since the recent problem with kdepimlibs4 was solved (thanks!),  port 
>> upgrade outdated consistently ends with
>> --->  Scanning binaries for linking errors
>> --->  Found 2 broken files, matching files to ports  
>> --->  Found 1 broken port, determining rebuild order
>> You can always run 'port rev-upgrade' again to fix errors.
>> The following ports will be rebuilt: kmymoney4-devel @4.8.1-20171206
>> 
>> port installed kmymon* returns
>> kmymoney4-devel @4.8.1-20171206_2 (active)
>> and, indeed, it is running normally. However, I’m wondering where the “_2” 
>> came from
> 
> 2 is the revision of the port. We increment the revision of a port when we 
> need to push a change out to you without changing the version of the port.
> 
>> , why I am prompted to rebuild each time,
> 
> Because MacPorts has identified that it is broken, in other words it links 
> with libraries which don't exist or aren't working. If you run `sudo port -d 
> rev-upgrade` it will tell you specifically what files are involved.
> 
>> and how to correct it.
> 
> Allowing the rev-upgrade process to rebuild the port should be the 
> correction. If that build is failing, show us the main.log.

Ticket created #59650 - forgot about the size limit for email. I attached an 
excerpt but will provide the entire main.log if necessary. Thanks for the 
response. 
Stan

Re: XCode 11 on Mojave problem, again

[Mojca Miklavec]

Dear Ruben,

This definitely looks like a bug in Xcode. I would suggest you to file
a bug report to Apple.

Can you please try to compile a simple hello world with just the
following contents

// test.cpp:
#include 
int main() { return 0; }

and compile it with:
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++
test.cpp \
-isysroot 
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk

Mojca

On Fri, 8 Nov 2019 at 15:27, Ruben Di Battista
 wrote:
>
> Hello people,
>
> I saw this kind of errors quite often lately around. But this times I’m 
> hitting this with a local project, not a port in Macports. A project that 
> used to build correctly with Xcode 10, now it seems to miss stuff in  
> header.
>
> ninja -j 1
> [1/48] Building CXX object src/libs/CMakeFiles/Mercurve.dir/BlockMerger.cxx.o
> FAILED: src/libs/CMakeFiles/Mercurve.dir/BlockMerger.cxx.o
> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++
>   -DMercurve_EXPORTS -I../src/libs -isystem /opt/local/include/vtk-8.1 
> -isystem /opt/local/include -isystem /opt/local/include/mpich-mp -isystem 
> /opt/local/include/libxml2 -g -isysroot 
> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk
>  -mmacosx-version-min=10.14 -fPIC   -Wall -Wno-long-long -pedantic 
> -fcolor-diagnostics -std=gnu++11 -MD -MT 
> src/libs/CMakeFiles/Mercurve.dir/BlockMerger.cxx.o -MF 
> src/libs/CMakeFiles/Mercurve.dir/BlockMerger.cxx.o.d -o 
> src/libs/CMakeFiles/Mercurve.dir/BlockMerger.cxx.o -c 
> ../src/libs/BlockMerger.cxx
> In file included from ../src/libs/BlockMerger.cxx:21:
> In file included from ../src/libs/BlockMerger.h:28:
> In file included from ../src/libs/types.h:25:
> In file included from 
> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/unordered_set:363:
> In file included from 
> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/__hash_table:19:
> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/cmath:314:9:
>  error: no member named 'signbit' in the global namespace
> […]
>
> I read a bit the tickets of other ports, but they don’t fit exactly with what 
> I have. Any fast hint? Do I need to downgrade Xcode?
>
>   _
> -. .´  |
>   ',  ;|∞∞
> ˜˜ |∞ RdB
> ,.,|∞∞
>   .'   '.  |
> -'   `’
>
> https://rdb.is

XCode 11 on Mojave problem, again

[Ruben Di Battista]

Hello people, 

I saw this kind of errors quite often lately around. But this times I’m hitting 
this with a local project, not a port in Macports. A project that used to build 
correctly with Xcode 10, now it seems to miss stuff in  header.

ninja -j 1
[1/48] Building CXX object src/libs/CMakeFiles/Mercurve.dir/BlockMerger.cxx.o
FAILED: src/libs/CMakeFiles/Mercurve.dir/BlockMerger.cxx.o
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++
  -DMercurve_EXPORTS -I../src/libs -isystem /opt/local/include/vtk-8.1 -isystem 
/opt/local/include -isystem /opt/local/include/mpich-mp -isystem 
/opt/local/include/libxml2 -g -isysroot 
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk
 -mmacosx-version-min=10.14 -fPIC   -Wall -Wno-long-long -pedantic 
-fcolor-diagnostics -std=gnu++11 -MD -MT 
src/libs/CMakeFiles/Mercurve.dir/BlockMerger.cxx.o -MF 
src/libs/CMakeFiles/Mercurve.dir/BlockMerger.cxx.o.d -o 
src/libs/CMakeFiles/Mercurve.dir/BlockMerger.cxx.o -c 
../src/libs/BlockMerger.cxx
In file included from ../src/libs/BlockMerger.cxx:21:
In file included from ../src/libs/BlockMerger.h:28:
In file included from ../src/libs/types.h:25:
In file included from 
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/unordered_set:363:
In file included from 
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/__hash_table:19:
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/cmath:314:9:
 error: no member named 'signbit' in the global namespace
[…]

I read a bit the tickets of other ports, but they don’t fit exactly with what I 
have. Any fast hint? Do I need to downgrade Xcode?

  _   
-. .´  |
  ',  ;|∞∞
˜˜ |∞ RdB
,.,|∞∞
  .'   '.  |
-'   `’

https://rdb.is


signature.asc
Description: Message signed with OpenPGP using AMPGpg

Re: package version and variant info in `main.log`

[Werner LEMBERG]

 I've noticed that in `main.log` files there is no information
 what version and variants have been requested – for example,
 
 ImageMagick @6.9.9-40_7+x11
 
 Wouldn't it make sense to make `port` add this information to the
 very top of `main.log`? This would also help identify various
 `make.log` files more easily.
>>
>> OK.  Shall I open a ticket?
> 
> Sure

Here it is.

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


Werner

Re: rxvt-unicode install fails

[Ryan Schmidt]

On Nov 6, 2019, at 05:54, joerg van den hoff wrote:

> On 05.11.19 20:41 , Ryan Schmidt wrote:
>> On Nov 5, 2019, at 10:20, joerg van den hoff wrote:
>>> this is on OSX 10.14.6 and with current macports 2.6.2.
>>> 
>>> it does not find  it seems. I don't find anything related to 
>>> this in the bug tracker, so any hint appreciated how to proceed.
>> sys/types.h is a standard OS header. It should be there, if you have 
>> installed Xcode or the command line tools.
>>> :debug:build 
>>> SDKROOT='/Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk'
>> Does the directory /Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk 
>> exist?
> 
> yes
> 
>> Does the file 
>> /Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk/usr/include/sys/types.h
>>  exist?
> 
> yes.
> 
>> They should. If they don't, reinstall the command line tools.
>> If you have Xcode installed, what version? If you've upgraded to Xcode 11, 
>> since you're on Mojave, you may have fewer problems by downgrading 
> 
> I upgraded to Xcode 11 prior to taking note of the macports caveat. I've 
> therefore downgraded as recommended (i.e. downloaded/installed 
> "Command_Line_Tools_macOS_10.14_for_Xcode_10.3.dmg") but did not do so for 
> the full Xcode 10 toolbox (trusting this is not required?).

Having mismatched versions of Xcode and the command line tools is not 
recommended, but I can't see how it would cause this specific problem.


>> to Xcode 10. This is just general advice for Mojave users, and probably does 
>> not relate to this problem you're experiencing now.
> 
> so the problem persists (rxvt-unicode being the _only_ package which choked 
> during the `port upgrade outdated' run) on two machines. in the meantime I 
> did the update on a third one with supposedly basically identical setup (OS 
> version, /opt/local content etc.) where I did *not* have the described 
> problem.
> 
> any idea where should I look now?

I think we'll have to see your main.log file and compare it to a system where 
it works to see what's different. Could you file a ticket and attach it there?

Re: libunwind-headers issue

[Ryan Schmidt]

On Nov 8, 2019, at 02:36, Werner LEMBERG wrote:

> On Mac Lion, installing a fresh MacPorts from scratch, then calling
> 
>  port -N mpkg lilypond-devel +mactex +perl5_28 +python37
> 
> always causes a (harmless) abort.  The reason is that
> `libunwind-headers' gets installed as part of the dependencies rather
> early, but one of the very last steps is installation of `libgcc9',
> which doesn't work with activated `libunwind-headers'.

Yes.

I don't know why anything requires libunwind-headers.

If libunwind-headers is installed, many other ports (not just libgcc9) will 
fail to build. I wish it didn't exist.

> Is it possible to somehow tell `port' in the above command that
> `libunwind-headers' has to be deactivated before building `libgcc9'?

No.

Re: package version and variant info in `main.log`

[Werner LEMBERG]

>> I've noticed that in `main.log` files there is no information what
>> version and variants have been requested – for example,
>> 
>>  ImageMagick @6.9.9-40_7+x11
>> 
>> Wouldn't it make sense to make `port` add this information to the
>> very top of `main.log`? This would also help identify various
>> `make.log` files more easily.
> 
> If that's not already in there,

It seems so.

> then yes, that would be good to have.

OK.  Shall I open a ticket?


Werner

Re: package version and variant info in `main.log`

[Ryan Schmidt]

> On Nov 8, 2019, at 02:39, Werner LEMBERG wrote:
> 
>>> I've noticed that in `main.log` files there is no information what
>>> version and variants have been requested – for example,
>>> 
>>> ImageMagick @6.9.9-40_7+x11
>>> 
>>> Wouldn't it make sense to make `port` add this information to the
>>> very top of `main.log`? This would also help identify various
>>> `make.log` files more easily.
>> 
>> If that's not already in there,
> 
> It seems so.
> 
>> then yes, that would be good to have.
> 
> OK.  Shall I open a ticket?

Sure

libunwind-headers issue

[Werner LEMBERG]

On Mac Lion, installing a fresh MacPorts from scratch, then calling

  port -N mpkg lilypond-devel +mactex +perl5_28 +python37

always causes a (harmless) abort.  The reason is that
`libunwind-headers' gets installed as part of the dependencies rather
early, but one of the very last steps is installation of `libgcc9',
which doesn't work with activated `libunwind-headers'.

Is it possible to somehow tell `port' in the above command that
`libunwind-headers' has to be deactivated before building `libgcc9'?


Werner