Re: p7zip Fails to Build on Sierra

[Russell Jones]

On 14/01/17 07:32, Christopher Stone wrote:

On Jan 14, 2017, at 01:11, Ryan Schmidt  wrote:

On Jan 14, 2017, at 00:38, Christopher Stone wrote:


When I try to install p7zip on Sierra the port file runs and appears to 
complete, but I don't get a viable executable.

Can someone confirm this?

Could you describe in what way the executable is not viable?

__

Hey Ryan,

Thanks for the quick response.

It slipped my mind that p7zip installs 3 executables:

7z
7za
7zr

I was looking for “p7zip” and of course didn't find it.

--
Take Care,
Chris


Hi Chris,

"port contents (portname)" is handy for this kind of thing, just in case 
you hadn't already noticed it.


Russell

Re: Migration issue

[Russell Jones]

On 06/01/17 17:37, Adam Dershowitz wrote:



On Jan 6, 2017, at 9:49 AM, Russell Jones 
<russell.jo...@physics.ox.ac.uk 
<mailto:russell.jo...@physics.ox.ac.uk>> wrote:


On 06/01/17 14:28, Adam Dershowitz wrote:



> On Jan 6, 2017, at 9:04 AM, Russell Jones 
<russell.jo...@physics.ox.ac.uk> wrote:

>
> On 06/01/17 13:22, Adam Dershowitz wrote:
>> On Jan 6, 2017, at 2:20 AM, Ryan Schmidt 
<ryandes...@macports.org> wrote:

>>> On Jan 5, 2017, at 09:26, Adam Dershowitz wrote:
>>>> I just tried what you suggested for py27-numpy and it just 
activated without any error.
>>> Yes, there will not be an error at activation time. However, if 
you have anything installed that required py27-numpy to be 
universal, it will now be broken.

>>>> So, myports.txt has
>>>>  py27-numpy @1.11.3_0+gfortran (active) platform='darwin 15' 
archs='x86_64'

>>>>
>>>> And, after the migration it had installed both that and the 
+universal variant.
>>>> Yet, when I tried to activate the non-universal version it did 
it without complaint.  So, I really don’t understand why the 
+universal got built at all.

>>>> Any suggestions?
>>> I don't have any answers for you, beyond the usual reasons why a 
port is installed universal, which are:

>>>
>>> - you explicitly asked for it to be installed universal
>>> - you installed another port universal that depends on this port
>>> - you installed another port that is 32-bit only, and you are on 
a 64-bit machine, and the other port depends on this port (You can 
check if the other port says "supported_archs i386 ppc" (or the 
other way around))
>>> - it enables the universal by default, and possibly requires the 
universal variant to be used (You can check the portfile to see if 
"default_variants +universal" appears)
>> What seems really odd to me that I took I moved my myports.txt 
from one machine to another.  So, I used one machine to generate 
that list, and brought it to another machine to build.
>> Both are MacBook pros (one new and one old) and that same list, 
on the new machine, added a bunch of universal ports.  So, I don’t 
see how any of the items in the list above could do that.  If it was 
not universal on the old machine, why would it end up universal on 
the new machine?
>> Could going from 10.11 to 10.12 make something required to be 
universal?  Or could going from Xcode 7 to 8 make a port universal? 
Because otherwise, I just don’t see why they should be different.
>> If anything, I would expect that the newer OS and newer hardware 
should be able to do more things as 64 bit, so would require less 
universal stuff.

>>
>> —Adam
> Could you gzip and attach the list of ports from the old machine 
and the output of "port installed requested"?

>
> The approach I suggested can't work, I now realize, as variants 
aren't used for working out dependencies ( 
https://trac.macports.org/wiki/FAQ#dependonvariant )

>
> Russell
>


Here are the two files.

I don’t believe that I have ever intentionally installed anything 
+universal.  So, I’m fairly sure that anything in this list that is 
universal is because of 3, or 4 above.  But, when I then moved to 
the new machine, it proceeded to make a bunch more things universal.


As far as I’m concerned pretty much all of my ports should just be 
installed with default variants, so few, if any, should be 
universal. As everything is now working, this is not a big deal.  
But, it does mean that upgrades often must be built, instead of 
using the binary, which would be much faster and use less drive space.




thanks,

—Adam
It looks like the extra +universal stuff comes from the things that 
were marked +universal installing all their dependencies +universal, 
which is expected behaviour. It looks like the restore script just 
installs the things listed in the order given, so doesn't preserve 
the variants exactly (+universal satisfies a request to install with 
no variants, I think, though I'm unsure). You could search and 
replace +universal (i.e. remove all instances of it) in myports, then 
tear-down and redo the install, I guess.


Russell

But, this list is from the old machine.  My question is why the new 
machine ended up with a lot more +universal.  For example, the list 
that I sent does not have +universal for py27-numpy, while the new 
machine, that I used the above list to install, did end up with 
+universal.
If the prior machine did not require +universal, based on the 
dependency tree, why would the new machine require it?  Or was 
something broken on the old machine, where it really did require 
+universal, but never actually installed it that way, and I happened 
never to hit that bug?


—Adam
Well, in the scenario I'm thinking of, it would

Re: Migration issue

[Russell Jones]

You could try activating the non +universal version to get a dependency 
error. Then do the same for the dependency, and so on back to the first 
port built +universal.


Russell


On 05/01/17 14:56, Adam Dershowitz wrote:



On Jan 5, 2017, at 9:44 AM, Rainer Müller > wrote:


On 2017-01-05 14:51, Adam Dershowitz wrote:



On Jan 4, 2017, at 10:02 PM, Ryan Schmidt > wrote:


On Jan 4, 2017, at 07:52, Adam Dershowitz wrote:

So, yes it seems that the on the new machine I ended up with gcc6 
being universal, so then cctools, ld64-latest, llvm-3.9 etc are 
all universal.  But, the strange thing is that gcc6 has no 
dependents, and I didn’t explicitly install it.  So, I’m not sure 
what caused it to be installed.  And, on the new machine it, and 
the chain down, installed +universal, while on the older machine 
it installed the default variant.  Both computers installed gcc6 
6.2.0_2.
So, my academic question is why did this happen?  And, the related 
questions are what port would have installed gcc6? Since I see this:

$port dependents gcc6
gcc6 has no dependents.


I don't know. If you don't need gcc6, don't install it / uninstall it.


It appears that build dependencies don’t show up with the 
dependencies command?  So, some installed port might have required 
gcc6 to install, but doesn’t need it for runtime.


Try with this:

 port echo depends_build:gcc6 and installed

This is only using the information from the latest ports tree, but could
probably answer your question.

Rainer


Thanks that helps.  It is a step in the right direction, but still 
leaves my question about what generates all the extra universal builds 
on the new machine, when the old machine had mostly default.
For example, on the new machine the above shows that py27-numpy has 
two installs, with the active one being +universal.  So, the migrate 
script first installed it default, then due to yet another port, must 
have rebuilt it +universal.  But, I don’t know how to trace those back 
to the root of it.
Perhaps the least effort would be to remove +universal completely from 
myports.txt then uninstall everything, and then reinstall with the 
migrate script?  Would anything that needs to be universal then end up 
getting put back that way?

Re: Migration issue

[Russell Jones]

On 06/01/17 14:28, Adam Dershowitz wrote:



> On Jan 6, 2017, at 9:04 AM, Russell Jones 
<russell.jo...@physics.ox.ac.uk> wrote:

>
> On 06/01/17 13:22, Adam Dershowitz wrote:
>> On Jan 6, 2017, at 2:20 AM, Ryan Schmidt <ryandes...@macports.org> 
wrote:

>>> On Jan 5, 2017, at 09:26, Adam Dershowitz wrote:
>>>> I just tried what you suggested for py27-numpy and it just 
activated without any error.
>>> Yes, there will not be an error at activation time. However, if 
you have anything installed that required py27-numpy to be universal, 
it will now be broken.

>>>> So, myports.txt has
>>>>  py27-numpy @1.11.3_0+gfortran (active) platform='darwin 15' 
archs='x86_64'

>>>>
>>>> And, after the migration it had installed both that and the 
+universal variant.
>>>> Yet, when I tried to activate the non-universal version it did it 
without complaint.  So, I really don’t understand why the +universal 
got built at all.

>>>> Any suggestions?
>>> I don't have any answers for you, beyond the usual reasons why a 
port is installed universal, which are:

>>>
>>> - you explicitly asked for it to be installed universal
>>> - you installed another port universal that depends on this port
>>> - you installed another port that is 32-bit only, and you are on a 
64-bit machine, and the other port depends on this port (You can check 
if the other port says "supported_archs i386 ppc" (or the other way 
around))
>>> - it enables the universal by default, and possibly requires the 
universal variant to be used (You can check the portfile to see if 
"default_variants +universal" appears)
>> What seems really odd to me that I took I moved my myports.txt from 
one machine to another.  So, I used one machine to generate that list, 
and brought it to another machine to build.
>> Both are MacBook pros (one new and one old) and that same list, on 
the new machine, added a bunch of universal ports.  So, I don’t see 
how any of the items in the list above could do that.  If it was not 
universal on the old machine, why would it end up universal on the new 
machine?
>> Could going from 10.11 to 10.12 make something required to be 
universal?  Or could going from Xcode 7 to 8 make a port universal?  
Because otherwise, I just don’t see why they should be different.
>> If anything, I would expect that the newer OS and newer hardware 
should be able to do more things as 64 bit, so would require less 
universal stuff.

>>
>> —Adam
> Could you gzip and attach the list of ports from the old machine and 
the output of "port installed requested"?

>
> The approach I suggested can't work, I now realize, as variants 
aren't used for working out dependencies ( 
https://trac.macports.org/wiki/FAQ#dependonvariant )

>
> Russell
>


Here are the two files.

I don’t believe that I have ever intentionally installed anything 
+universal.  So, I’m fairly sure that anything in this list that is 
universal is because of 3, or 4 above. But, when I then moved to the 
new machine, it proceeded to make a bunch more things universal.


As far as I’m concerned pretty much all of my ports should just be 
installed with default variants, so few, if any, should be universal.  
As everything is now working, this is not a big deal.  But, it does 
mean that upgrades often must be built, instead of using the binary, 
which would be much faster and use less drive space.




thanks,

—Adam
It looks like the extra +universal stuff comes from the things that were 
marked +universal installing all their dependencies +universal, which is 
expected behaviour. It looks like the restore script just installs the 
things listed in the order given, so doesn't preserve the variants 
exactly (+universal satisfies a request to install with no variants, I 
think, though I'm unsure). You could search and replace +universal (i.e. 
remove all instances of it) in myports, then tear-down and redo the 
install, I guess.


Russell

Re: Migration issue

[Russell Jones]

On 06/01/17 13:22, Adam Dershowitz wrote:

On Jan 6, 2017, at 2:20 AM, Ryan Schmidt  wrote:

On Jan 5, 2017, at 09:26, Adam Dershowitz wrote:

I just tried what you suggested for py27-numpy and it just activated without 
any error.

Yes, there will not be an error at activation time. However, if you have 
anything installed that required py27-numpy to be universal, it will now be 
broken.

So, myports.txt has
  py27-numpy @1.11.3_0+gfortran (active) platform='darwin 15' archs='x86_64'

And, after the migration it had installed both that and the +universal variant.
Yet, when I tried to activate the non-universal version it did it without 
complaint.  So, I really don’t understand why the +universal got built at all.
Any suggestions?

I don't have any answers for you, beyond the usual reasons why a port is 
installed universal, which are:

- you explicitly asked for it to be installed universal
- you installed another port universal that depends on this port
- you installed another port that is 32-bit only, and you are on a 64-bit machine, and 
the other port depends on this port (You can check if the other port says 
"supported_archs i386 ppc" (or the other way around))
- it enables the universal by default, and possibly requires the universal variant to be 
used (You can check the portfile to see if "default_variants +universal" 
appears)

What seems really odd to me that I took I moved my myports.txt from one machine 
to another.  So, I used one machine to generate that list, and brought it to 
another machine to build.
Both are MacBook pros (one new and one old) and that same list, on the new 
machine, added a bunch of universal ports.  So, I don’t see how any of the 
items in the list above could do that.  If it was not universal on the old 
machine, why would it end up universal on the new machine?
Could going from 10.11 to 10.12 make something required to be universal?  Or 
could going from Xcode 7 to 8 make a port universal?  Because otherwise, I just 
don’t see why they should be different.
If anything, I would expect that the newer OS and newer hardware should be able 
to do more things as 64 bit, so would require less universal stuff.

—Adam
Could you gzip and attach the list of ports from the old machine and the 
output of "port installed requested"?


The approach I suggested can't work, I now realize, as variants aren't 
used for working out dependencies ( 
https://trac.macports.org/wiki/FAQ#dependonvariant )


Russell

Re: gegl fails to build

[Russell Jones]

https://github.com/GNOME/glib/commit/dbf0a566703586db9777c3d56e01aa40c02ab9ac

https://bugzilla.gnome.org/show_bug.cgi?id=779332

Possibly?


On 15/09/17 16:50, Michael Parson wrote:
KeyError: u'nick' 

Re: Differences in binary and compiled port

[Russell Jones]

On 03/11/17 21:30, Mojca Miklavec wrote:

On 3 November 2017 at 19:30, dan d. wrote:

Hello macporters,

I got the web browser lynx both by downloading the binary version and compiling 
one locally.

Without going into much detail, there are some minor differences in how it 
works with speech using a screen reader.

In the binary version it reads each link as I arrow up or down.

The compiled version does not, I must read the line manually to have it spoken.

Any idea why there is this difference?

Can you please try to recompile with

 sudo port -ts install lynx

and check whether it's still different?

One thing that's easy to explain would be opportunistic linking: when
a library is used despite not being defined as a dependency. But
that's a blind guess. Usually the two should be the same. If they are
not, that's a bug worth reporting.

Mojca

You could also compare the output of "otool -L /opt/local/bin/lynx"

Russell

Re: Search for a MacPorts Mascot: looking for talented artists

[Russell Jones]

https://en.wikipedia.org/wiki/Port_of_Oakland#/media/File:USA-Oakland-Port-View_from_Alameda-4.jpg


On 21/02/18 21:56, Dave Horsfall wrote:

On Wed, 21 Feb 2018, Arno Hautala wrote:

https://www.tripadvisor.com/LocationPhotoDirectLink-g32810-i36315229-Oakland_California.html 



I nominate "Portia McCrane - the MacPorts Port Crane". She'll be on 
shelves in time for the holidays and the hit plush toy craze of the 
season!


Please take careful note of the copyright notice for that image.

Re: What installs "pip"?

[Russell Jones]

On 18/11/2018 17:41, Michael wrote:
> Which port actually installs pip?
>
> keybounceMBP:js-beautify michael$ port select --summary
> Name   Selected  Options
>      ===
> cython none  cython27 none
> db none  db46 db48 none
> llvm   none  mp-llvm-3.5 mp-llvm-3.7 mp-llvm-4.0 mp-llvm-5.0 
> mp-llvm-6.0 none
> nosetests  none  nosetests27 none
> pipnone  pip36 none
> pygments   none  py36-pygments none
> python python36  python25-apple python26 python26-apple python27 
> python27-apple python36 none
> python2none  python25-apple python26 python26-apple python27 
> python27-apple none
> python3none  python36 none
> keybounceMBP:js-beautify michael$ ls /opt/local/bin/pip*
> 4 /opt/local/bin/pip-3.6@
> keybounceMBP:js-beautify michael$
>
>
> ---
> Entertaining minecraft videos
> http://YouTube.com/keybounce
>
In python 3.4+, the pip module is built in. So in python3.7, for 
instance, you can use python3.7 -m pip. Alternatively, use the port 
select system, so pip and pip3 are set to pip3.6

In python2, you need py27-pip, and I guess it shows up in port select 
similarly.

Russell

Re: Anyone running X11 apps on Mojave?

[Russell Jones]

On 01/12/2018 15:05, Christopher Jones wrote:



On 26 Nov 2018, at 9:36 am, Dr M J Carter  
wrote:

On Sat, Nov 24, 2018 at 11:58:16AM +, Christopher Jones wrote:


Note that the version of Xquartz from [2]www.xquartz.com is in fact
just a packaging of the MacPorts version ! In fact, the maintainer
of the Xquartz releases has stated that they may well no longer make
releases there, and only maintain the MacPorts provided version (via
the xorg-server port) going forward.

That's going to prove interesting for those of us using MacTeX: its
copy of gs-X11 seems to request and require libraries in /opt/X11 at
runtime, not just at setup.  (In our setups, /usr/local/bin comes
before /opt/local/bin, for reasons I can be tedious about on request,
so MacTeX's gs preempts MacPorts's.)

well, the easy solution is to use macPorts provided TexLive ports.. These are 
built against MacPorts X11 dependencies….


Except where they're in TeXLive and not in MacPorts, or not on the 
MacPorts build server and take a while to build.


Russell

Re: Help please

[Russell Jones]

On 16/11/2018 04:28, James Linder wrote:
>
>> On 16 Nov 2018, at 11:14 am, Ryan Schmidt  wrote:
>>
>>
>>
>> On Nov 15, 2018, at 00:51, j...@tigger.ws wrote:
>>
>>> The new bit is a Telstra NBN modem (for Aus’s new high speed broadband.) If 
>>> any Aus user has tamed the Telstra NBN modem please tell me what and how.
>> Have you tried using a closer mirror instead of the master (which is in 
>> Germany)?
>>
>> https://trac.macports.org/wiki/Mirrors
>>
>> You can separately configure where base is downloaded from during selfupdate 
>> (macports.conf) and where ports are downloaded from during selfupdate or 
>> sync (sources.conf).
>>
>> We have a mirror in Australia, unfortunately for some reason they don't 
>> mirror base. I'll have to have a word with them about that. Maybe there is 
>> another mirror that's closer to you than the master. Maybe try the one in 
>> New Caledonia.
>>
>> The Australian mirror does mirror ports, so you could use it for that.
>>
>> Trying different servers could also be a troubleshooting step to narrow down 
>> whether it's a problem with all rsync traffic or just with reaching specific 
>> servers.
> Ryan thanks.
> The problem is definately the modem. I turned OFF the firewall (actually I 
> need to think thru, why would the modem have a firewall at all, unless bad 
> guys can login to the modem …) and rsync ran perfectly. I tried but was not 
> able to make a modem firewall rule for rsync.
> So turn off firewall, selfupdate, turn on is pretty painless.
>
> James

Have you tried explicitly opening 873/tcp outgoing?

Have you tried using iftop or wireshark to see what is/isn't being 
connected to?

Russell

Re: What installs "pip"?

[Russell Jones]

On 18/11/2018 17:59, Michael wrote:
> On 2018-11-18, at 9:55 AM, Russell Jones  
> wrote:
>
>> On 18/11/2018 17:41, Michael wrote:
>>> Which port actually installs pip?
>>>
>>> keybounceMBP:js-beautify michael$ port select --summary
>>> Name   Selected  Options
>>>      ===
>>> cython none  cython27 none
>>> db none  db46 db48 none
>>> llvm   none  mp-llvm-3.5 mp-llvm-3.7 mp-llvm-4.0 mp-llvm-5.0 
>>> mp-llvm-6.0 none
>>> nosetests  none  nosetests27 none
>>> pipnone  pip36 none
>>> pygments   none  py36-pygments none
>>> python python36  python25-apple python26 python26-apple python27 
>>> python27-apple python36 none
>>> python2none  python25-apple python26 python26-apple python27 
>>> python27-apple none
>>> python3none  python36 none
>>> keybounceMBP:js-beautify michael$ ls /opt/local/bin/pip*
>>> 4 /opt/local/bin/pip-3.6@
>>> keybounceMBP:js-beautify michael$
>>>
>>>
>>> ---
>>> Entertaining minecraft videos
>>> http://YouTube.com/keybounce
>>>
>> In python 3.4+, the pip module is built in. So in python3.7, for
>> instance, you can use python3.7 -m pip. Alternatively, use the port
>> select system, so pip and pip3 are set to pip3.6
>>
>> In python2, you need py27-pip, and I guess it shows up in port select
>> similarly.
>>
>> Russell
> Aha. So,
>
> keybounceMBP:js-beautify michael$ port select pip pip36
> Selecting 'pip36' for 'pip' failed: could not create new link 
> "/opt/local/bin/pip" pointing to 
> "/opt/local/Library/Frameworks/Python.framework/Versions/3.6/bin/pip": 
> permission denied
> keybounceMBP:js-beautify michael$ sudo !!
> sudo port select pip pip36
> Password:
> Selecting 'pip36' for 'pip' succeeded. 'pip36' is now active.
> keybounceMBP:js-beautify michael$
>
> While installing pip36 does result in "port select --summary" showing that it 
> is active, it actually is NOT until you run the port select command. Odd.
>
> (Equally odd -- installing python36 in the first place did not install a pip 
> if it is part of the python system).
>
> Side question: Why is there not just a "python3", why do we have to 
> specifically select one of several versions?
>
> ---
> Entertaining minecraft videos
> http://YouTube.com/keybounce
>
I think pip-3.6, etc, are always available.

I guess the Python 3 port file (python3.6, etc, are sub-ports, IIRC) 
can't tell if a python3 is already installed, so it doesn't try to guess 
for you which you want. Similarly pip/pip3, etc.

Russell