Re: PowerMac download statistics?

[Clemens Lang]

Hi,

On Fri, Jan 06, 2017 at 04:48:37PM -0500, Jeffrey Walton wrote:
> I'm looking for statistics on the number of Macports users and the
> number of PowerMac users.
> 
> Does MacPorts track the statistics? If so, are they publicly
> available?

I think portmgr@ has access to our CDN's statistics, which is probably
the best resource to figure this out.

-- 
Clemens

PowerMac download statistics?

[Jeffrey Walton]

Hi Everyone,

I'm looking for statistics on the number of Macports users and the
number of PowerMac users.

Does MacPorts track the statistics? If so, are they publicly available?

Thanks in advance.

Re: Migration issue

[Brandon Allbery]

On Fri, Jan 6, 2017 at 12:37 PM, Adam Dershowitz  wrote:

> But, this list is from the old machine.  My question is why the new
> machine ended up with a lot more +universal.


Actually, I'm starting to wonder if there is a general option leakage issue
of late (compare the discussion about archive_sites leaking).

-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net

Re: Migration issue

[Adam Dershowitz]

> On Jan 6, 2017, at 9:49 AM, Russell Jones  
> wrote:
> 
> On 06/01/17 14:28, Adam Dershowitz wrote:
>> 
>> 
>> > On Jan 6, 2017, at 9:04 AM, Russell Jones  
>> >  wrote:
>> > 
>> > 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
>> > 
>> 
>> 
>> 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 

Re: Inkscape 0.92.0 now available on MacPorts

[Brandon Allbery]

"Quartz" is not "XQuartz", is the point. XQuartz is X11. Quartz is the old
name for the native OS X 2D graphics API, still used for consistency. If
you tell me you don't want to use X11 but you want XQuartz, you're telling
me you want X11 instead of X11 (huh?).

(X11 is *not* native. OS X graphics is not, and never has been, based on
X11.)

As for native graphics, it depends on the program and what toolkit if any
it uses. As an example, gtk2's native Core Graphics support is buggy: some
things work, some have odd bugs (xchat/hexchat won't autoscroll, for
example), some simply won't build because they explicitly use e.g.
gdk/x11.h instead of the portable Gdk API.

For inkscape, I see a standard gtk2 mode and an experimental gtk3 mode.
This is a problem because currently you can only install gtk2 and/or gtk3
for either native/"Quartz" or X11. (It should be possible to make gtk3 use
pluggable backends, but it doesn't currently. gtk2 is a lost cause in that
regard: you have to pick native or X11 and use it for everything. This is a
problem if one of the programs you want to use only works correctly with
+x11.)

On Fri, Jan 6, 2017 at 10:07 AM, Eneko Gotzon  wrote:

> Hi Brandon, thank you for take time to answer my question
>
> On Thu, Jan 5, 2017 at 11:51 PM, Brandon Allbery 
> wrote:
>>
>>
>> XQuartz = X server under Quartz = X11 for OS X.
>>
>
> I think I understand your statement.
>
>
>> So you *have* it for XQuartz. Do you mean you want it native instead?
>>
>
> I am a little confused. Your "native" naming, applies to macOS ​or to
> the X Window System?
>
> Maybe the more relevant question for me is: what is the difference between
> the *quartz* & *[+]x11* variants of the inkscape port?
>
> ​Thank you very much, and, please, excuse me,
> ​
> I
> ​ am sorry
>
> ​taking
> ​
> your valuable time with this
> ​kind
>  of questions…
> ​ :(​
>
> ​Take care.
> --
> Eneko Gotzon Ares
> enekogot...@gmail.com
>



-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net

Grass wxGUI

[P Kishor]

Now that I have successfully installed Grass 7.2, I am wondering why I didn’t 
get the wxGUI with it.

○ → grass72
Starting GRASS GIS...
ERROR: wxGUI requires wxPython. No module named wxversion
ERROR: Error in GUI startup. See messages above (if any) and if necessary, 
please report this error to the GRASS developers.
On systems with package manager, make sure you have the right GUI package, 
probably named grass-gui, installed.
To run GRASS GIS in text mode use the -text flag.
Use '--help' for further options
 grass72 --help
See also: https://grass.osgeo.org/grass72/manuals/helptext.html
Exiting…


From the Macports definition, it seems it does have wxPython as a dependency. 
Suggestions?

Puneet

Re: Inkscape 0.92.0 now available on MacPorts

[Eneko Gotzon]

Hi Brandon, thank you for take time to answer my question

On Thu, Jan 5, 2017 at 11:51 PM, Brandon Allbery 
wrote:
>
>
> XQuartz = X server under Quartz = X11 for OS X.
>

I think I understand your statement.


> So you *have* it for XQuartz. Do you mean you want it native instead?
>

I am a little confused. Your "native" naming, applies to macOS ​or to the X
Window System?

Maybe the more relevant question for me is: what is the difference between
the *quartz* & *[+]x11* variants of the inkscape port?

​Thank you very much, and, please, excuse me,
​
I
​ am sorry

​taking
​
your valuable time with this
​kind
 of questions…
​ :(​

​Take care.
-- 
Eneko Gotzon Ares
enekogot...@gmail.com

Re: Migration issue

[Russell Jones]

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



> On Jan 6, 2017, at 9:04 AM, Russell Jones 
 wrote:

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


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: pan - start with script.app at the new Pan 0.141

[Craig Treleaven]

> On Jan 6, 2017, at 6:17 AM, FritzS - gmx  wrote:
> 
> Now with only
> do shell script "export PATH=\"/opt/local/bin:$PATH\" && pan“
> it works well.
> 
> PS: I am not a script guru - but now I understand this script line.

Apple has a comprehensive primer on shell scripting:

https://developer.apple.com/library/content/documentation/OpenSource/Conceptual/ShellScripting/ResultCodes,Chaining,andArgumentParsing/ResultCodes,Chaining,andArgumentParsing.html#//apple_ref/doc/uid/TP40004268-CH5-SW1

The only new element in the script is the ‘&&’ operator.  See the section on 
Chaining Execution at the above link.

Craig

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: Migration issue

[Adam Dershowitz]

> 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

Re: Looking for mailing list advice

[Ben Greenfield via macports-users]

Hello Dave,

We use mailman setup a a broadcast only list-serv for big mailings and we 
design them using 

http://equinux.com/us/products/maildesigner2/mail-designer-pro-3/

We also use mail designer pro to send small batches of email. It uses  the 
users Mail.app to send and receive messages but there are other options. We 
send directly to our broadcast only mailman list-srerv from with large mailings.

It is a good program that does it says and doesn’t insist on harvesting all 
your data.

Ben



> On Jan 5, 2017, at 10:22 PM, Dave Horsfall  wrote:
> 
> On Thu, 5 Jan 2017, William H. Magill wrote:
> 
>> I have used mailman in the past, so it is not completely foreign to me, 
>> but I was hoping for something “easier.”
> 
> Don't use EzMLM; it's a pile of steaming dog droppings (its bounce 
> handling is laughable).
> 
> -- 
> Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."

Re: pan - start with script.app at the new Pan 0.141

[FritzS - gmx]

> Am 06.01.2017 um 10:43 schrieb Ryan Schmidt :
> 
> On Jan 6, 2017, at 03:16, FritzS - gmx wrote:
>> 
>> My script pan.app
>> do shell script "export PATH=\"/opt/local/bin:$PATH\" && pan"
>> do shell script "/opt/local/bin/pan“
>> works now (without set the path in script it does’t run too)
>> 
>> Pan 0.141 runs now well - but if I closed pan another error message comes 
>> again:
>> sh: gpg2: command not found
>> sh: gpg2: command not found (1011)
> 
> Use only the "do shell script" command I showed. Remove the "do shell script" 
> command you were using before. 

Ryan,
thanks!

Now with only
do shell script "export PATH=\"/opt/local/bin:$PATH\" && pan“
it works well.

PS: I am not a script guru - but now I understand this script line.

Greetings
Fritz

Re: pan - start with script.app at the new Pan 0.141

[Ryan Schmidt]

On Jan 6, 2017, at 03:16, FritzS - gmx wrote:
> 
> My script pan.app
> do shell script "export PATH=\"/opt/local/bin:$PATH\" && pan"
> do shell script "/opt/local/bin/pan“
> works now (without set the path in script it does’t run too)
> 
> Pan 0.141 runs now well - but if I closed pan another error message comes 
> again:
> sh: gpg2: command not found
> sh: gpg2: command not found (1011)

Use only the "do shell script" command I showed. Remove the "do shell script" 
command you were using before. 

Re: pan - start with script.app at the new Pan 0.141

[FritzS - gmx]

> Am 06.01.2017 um 08:12 schrieb Ryan Schmidt :
> 
> 
>> On Jan 5, 2017, at 07:26, FritzS - gmx  wrote:
>> 
>> Till today I start pan with a  script saved as pan.app
>> do shell script "/opt/local/bin/pan“
>> 
>> this worked well till the update to Pan 0.141 coming out now.
>> 
>> Now it comes the error report:
>> sh: gpg2: command not found
>> error "sh: gpg2: command not found" number 1011
>> 
>> gpg2 is located:
>> /opt/local/bin/gpg2  (macports)
> 
> I guess pan now needs gpg2, and assumes it will be located in the PATH. The 
> PATH you have set in your terminal includes /opt/local/bin, but the PATH that 
> AppleScript runs "do shell script" with does not.
> 
> 
>> and
>> /usr/local/bin/gpg   - is a link to
>> /usr/local/MacGPG2/bin/gpg2 (from MacGPG)
> 
> Having things installed in /usr/local can cause problems for software you 
> install with MacPorts; I recommend you remove what you've installed in 
> /usr/local.
> 
> https://trac.macports.org/wiki/FAQ#usrlocal
> 
> 
>> At the moment I open pan with an double click to pan binary and this open a 
>> shell:
>> $ /opt/local/bin/pan ; exit;
>> 
>> What could I do that the my pan.app would work.
> 
> Add /opt/local/bin to the PATH AppleScript uses:
> 
> 
> do shell script "export PATH=\"/opt/local/bin:$PATH\" && pan“

No I done this:

I uninstalled and reinstalled GPG_Suite
https://gpgtools.org/
GPG_Suite-2016.10_v2.dmg

Installed them without
GPGServices
MacPGP2

For apps which searched gpg or pgp2 hardcoded in /usr/local/bin/
I add symlinks from the macports path
sudo ln -s /opt/local/bin/gpg2 /usr/local/bin/gpg2  
sudo ln -s /opt/local/bin/gpg2 /usr/local/bin/gpg  

My script pan.app
do shell script "export PATH=\"/opt/local/bin:$PATH\" && pan"
do shell script "/opt/local/bin/pan“
works now (without set the path in script it does’t run too)
 
Pan 0.141 runs now well - but if I closed pan another error message comes again:
sh: gpg2: command not found
sh: gpg2: command not found (1011)

My path and other settings:

$ echo "$PATH"
/opt/local/bin:/opt/local/sbin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/opt/X11/bin


$ export $LANGUAGE
declare -x 
DISPLAY="/private/tmp/com.apple.launchd.Pmb3Nt0WvF/org.macosforge.xquartz:0"
declare -x GPG_AGENT_INFO="/private/tmp/com.apple.launchd"
declare -x LANG="de_AT.UTF-8"
declare -x 
PATH="/opt/local/bin:/opt/local/sbin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/opt/X11/bin"
declare -x SHELL="/bin/bash“

Re: gmp's archive_site in Portfile disables custom archive_sites

[Peter Brommer]

> On 5 Jan 2017, at 23:16, Christopher Jones  wrote:
> 
[..]
> One last question, just a thought, but what exactly are you aiming to gain 
> from this setup ? most ports have binaries available direct from macports. I 
> have multiple machines and have never really had any issues with just letting 
> each do its own thing. Are you looking to save downloads, or CPU time 
> building those ports without upstream binaries, or … ? Just seems to me a 
> complicated setup for little return.
> 
Well, one of the two is a Mac Book Air with limited disk space. And this setup 
lets me avoid a full Xcode installation on the MBA. As to why I need it: I 
prefer quartz over x11, and those binaries are rarely available upstream. And 
unfortunately some packages will not compile with command line tools only. So 
it’s me insisting on custom variants on a small hard drive that necessitates 
this manoeuvre (also, packages like gtk3 and inkscape take literally AGES to 
compile).

Peter