Re: gmp's archive_site in Portfile disables custom archive_sites

[Christopher Jones]

> On 5 Jan 2017, at 9:46 pm, Peter Brommer  wrote:
> 
> Hi Chris, 
> 
> thanks for your reply.
> 
>> On 5 Jan 2017, at 16:08, Chris Jones  wrote:
> 
>> Presumably the first machine, that creates the local binaries runs just 
>> fine, but then the second doesn't use these for this one port, and attempts 
>> to build again from source ? If correct, is this really a problem ? From the 
>> discussion in the ticket this is exactly what is wanted for this port, as it 
>> compiles very specifically for the machine it is to be used on. You *want* 
>> it to therefore build from source on each and every machine.
> 
> Yes, that indeed is not ideal, but probably necessary for this port. I don’t 
> object to this.
> 
> The point is that after doing that, macports has “forgotten” about my local 
> source for all further ports to upgrade and falls back to the default 
> macports source. It’s not a big issue indeed (as cancelling and restarting 
> the port upgrade outdated fixes it), but it might be a symptom of a bug, 
> which I don’t have the energy to track down. 
> 
> Unfortunately, after I noticed this behaviour (not using my private archive 
> site as first instance), I aborted the operation, before I got to a port 
> where binaries are not available from macports. So I don’t know if it just 
> got the priorities wrong (using default macports binaries before local 
> archive), or had forgotten about my archive sites completely.


Ah right, I see the issue. I wouldn’t have guess that *all* ports would avoid 
the local tar balls….

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.

Chris

> 
> Sorry for not making this clearer initially, I hope you see my point now.
> 
> Peter
> 
> 
>> 
>> Chris
>> 
>> On 05/01/17 14:23, Peter Brommer wrote:
>>> Hi,
>>> 
>>> it appears that gmp @6.1.2_0 breaks my macports setup, due to its use of 
>>> “archive_sites” in the Portfile (to avoid installing from precompiled 
>>> binaries).
>>> 
>>> I have two Macs, and I use the setup described in 
>>> https://trac.macports.org/wiki/howto/ShareArchives2 - one machine creates 
>>> the local binaries not available from macports, the other one uses them via 
>>> a customised archive_sites.conf.
>>> 
>>> gmp (and maybe other ports) unsets archive_sites to avoid installing from 
>>> binaries (as discussed in https://trac.macports.org/ticket/41614), so it 
>>> ignores my custom archive_site (aside: in principle, it should fail as I 
>>> request binary-only with port -b upgrade, but if I read 
>>> https://trac.macports.org/ticket/50885 correctly that will be addressed in 
>>> a future macports release). However, after building, installing and 
>>> activating gmp, macports no longer used my local archive_site, but falls 
>>> back to the default archive_sites.
>>> 
>>> I’m not sure if this is a bug, and I have a hard time reproducing it, as 
>>> the second time I run the command, gmp is already upgraded, and it keeps 
>>> using my local archive_site. Should I still file this as a bug? And against 
>>> what?
>>> 
>>> Cheers,
>>> 
>>> Peter
>>> 
> 



smime.p7s
Description: S/MIME cryptographic signature

Re: Prevent MacPorts editing .bash_profile over and over again...

[Christopher Jones]

Hi,

It would be better yet if whatever it is that does this first checks to see in 
the path it is about to add is already in the users PATH, and does not add it 
again if already there…

Chris

> On 28 Jan 2017, at 4:31 pm, Barry Scott  wrote:
> 
> I want to be able to stop MacPorts Installation from editing my .bash_profile.
> As it happens I already set all the env var that are needed my self.
> 
> Is there a “do-not-edit-bash-profile” settings somewhere?
> 
> So far I have 3 sets of the settings in the same file.
> 
> Barry
> 



smime.p7s
Description: S/MIME cryptographic signature

Re: Will using only dolphin be too much overhead?

[Christopher Jones]

Hi,

There is no port called ‘kdebase4’. If you want Dolphin the minimum you need to 
install is

> sudo port install kde4-baseapps

Thats the minimum proving the core KD4 libraries plus a few basic applications, 
that includes Dolphin.

Chris

> On 5 Feb 2017, at 3:21 pm, Dorien Herremans  
> wrote:
> 
> 
> down vote
>  <>favorite
>  
> 
>  
> I am struggling with Finder after switching to Mac from linux. Dolphin was 
> just a much more powerful file manager.
> 
> Features I miss: - easily editable URL to navigate (although fixed that with 
> Finder Path). - embedded terminal window (very important to me) - tree view - 
> ability to navigate easily without using the mouse - stay on top feature by 
> KDE window manager
> 
> I've tried Double Commander, but I still don't find it very intuitive, e.g. 
> see no way to just type/edit the url to where I want to go.
> 
> So I did read 
>  
> that I could run Dolphin via Macports:
> 
> dolphin is a rather nice file browser. the impression that i get from here 
> http://dolphin.kde.org/ is that one is to install 
> kdebase4. done. so where is dolphin?
> According to "port contents kdebase4 | grep -i dolphin", there is a 
> dolphin.app in /Applications/MacPorts/KDE4.
> My question though: If I have to install kdebase4, doesn't that mean a huge 
> amount of overhead just for a file manager? Will it actually run X? Does the 
> installation command above install the whole thing?
> 
> 
> -- 
> Dorien Herremans, PhD
> Marie-Curie Fellow
> http://dorienherremans.com 
> 
> Queen Mary University of London
> School of Electronic Engineering and Computer Science
> C4DM - Centre for Digital Music, London
> 
> Workshop on Deep Learning and Music , 
> May'17 Anchorage, Alaska. 
>  



smime.p7s
Description: S/MIME cryptographic signature

Re: Prevent MacPorts editing .bash_profile over and over again...

[Christopher Jones]

> On 22 Mar 2017, at 1:32 pm, Jan Stary  wrote:
> 
> On Mar 22 12:53:15, rai...@macports.org wrote:
>> On 2017-03-21 21:43, Jan Stary wrote:
>>> +echo "Remember to set your environment:"
>>> +echo "Prepend ${BINPATH} and ${SBINPATH} to PATH."
>>> +echo "Prepend ${MANPAGES} to MANPATH if you use MANPATH."
>>> +echo "Remember to set DISPLAY if you are on 10.4 or older."
>>> +echo "See https://guide.macports.org/#installing.shell for details."
>> 
>> Where do you think users would see this?
> 
> The same place where all the other echo's go.
> 
>> I am quite sure the installer
>> does not show any output of the postflight script.
> 
> Does it go to a log?

Frankly, it does not matter where the message may or may not go. It could be 
flashed on the screen in huge red letters, some users will still ignore it and 
then complain that MacPorts does not work because $prefix is not in their 
paths… 

This is why a proposal to remove this from the installer is (IMHO) a non 
starter. Now, if you where instead to propose extending the installer with a 
page, that clearly explained why editing the users path is needed, and offered 
an option to opt out (the default would have to stay yes) then I think you 
stand a better chance of getting something included. But as it stands just 
removing this feature isn’t going to fly, in my view.

Chris


> 
>   Jan
> 



smime.p7s
Description: S/MIME cryptographic signature

Re: attach a diff or request a pull?

[Christopher Jones]

> On 1 Jul 2017, at 3:01 pm, Jan Stary  wrote:
> 
> There seem to be two way to send a patch to a port:
> 
>  1. create a ticket in trac and attach a diff
>  2. create a pull request on github
> 
> Is any of the two preferred by the MP developers?

The second for me, by far.

Chris

> 
>   Jan
> 



smime.p7s
Description: S/MIME cryptographic signature

Re: MacPorts shell mode

[Christopher Jones]

> If you really want to run a command without typing your password,
> configure the sudoers file accordingly. There are plenty of guides on
> the web on how to do this, or see 'man sudoers' and 'man visudo'.
> 
> Be aware of the security implications such a configuration has. Allowing
> to run port without sudo effectively allows to run any command as root,
> as it is trivial to execute other binaries.

Not true. In fact it is the exact opposite, more secure, if configured 
correctly.

You can configure sudo so *only* /opt/local/bin/port is allowed to run without 
a password. Any other use of sudo still requires the password. 

The reason doing this is more secure is because you can run ‘sudo port XYZ’ 
without entering any password, which means any subsequent sudo command will 
require authentication with a password. As a example

> sudo port XYZ
> sudo rm -rf /opt/local

has a very different outcome in the two cases… If you have configured sudo to 
allow the first to run without a password, the second will prompt you, at which 
point you might reconsider what you are doing… 

To enable this update your sudoers file with the last line below

##
## User privilege specification
##
rootALL=(ALL) ALL
%admin  ALL=(ALL) ALL
chris   ALL=(ALL) NOPASSWD: /opt/local/bin/port

Chris

> 
> Rainer

Re: installation failure because can't fetch the file (10.6.8)

[Christopher Jones]

Hi,

So indeed the issue is

--->  Attempting to fetch decorator-4.2.1.tar.gz from 
https://files.pythonhosted.org/packages/source/d/decorator

  % Total% Received % Xferd  Average Speed   TimeTime Time  Current
 Dload  Upload   Total   SpentLeft  Speed
  0 00 00 0  0  0 --:--:--  0:00:01 --:--:-- 
0DEBUG: Fetching distfile failed: error:1407742E:SSL 
routines:SSL23_GET_SERVER_HELLO:tlsv1 alert protocol version

so the upstream server providing the source rejected your connection.

the SSL requirement is not a per port thing, per se, but varies according the 
policies of the upstream web server hosting the ports source code. For the 
other ports you have installed you most probably just got them from the binary 
tar balls, via the macports servers, which did not reject your connection. This 
just happens to be the first you have hit which does.

Chris

> On 19 Jan 2018, at 5:46 pm, Franco Vaccari  wrote:
> 
> Hi,
> 
> Here it is, but I wonder whether such a SSL version requirement is 
> per-package, because I had no problem in installing a large number of 
> packages before finding this issue.
> 
> Thanks for looking into it!
> 
> Franco
> 
> 
> 
>> On 19 Jan 2018, at 17:34, Chris Jones  wrote:
>> 
>> Hi,
>> 
>> I think you cut from the list of responses the useful ones. Most probably 
>> one of the ones you cut was showing that the connection was rejected due to 
>> the use of an insecure SSL version, or similar.
>> 
>> Please post the complete log, compressed to save space.
>> 
>> cheers Chris
>> 
>> On 19/01/18 15:59, Franco Vaccari wrote:
>>> I’m trying to update MacPorts on some old computers running 10.6.8. I 
>>> decided to go with a fresh installation on a test machine, removing the 
>>> existing /opt/local, before hopefully do the same on the main server.
>>> I successfully installed many of the packages my group use routinely, but 
>>> with several packages the process fails as it can’t get the required files. 
>>> One example is py36-decorator, that I could successfully install on a more 
>>> modern computer running 10.12.
>>> The network connection is the same, both computers live in a private 
>>> network and get to the outside world through the same server, there is no 
>>> specific firewall rule that could interfere.
>>> I’ve run the command on both computers in debug mode. The error comes out 
>>> like this on the 10.6.8 machine
>>> DEBUG: Searching for dependency: py36-setuptools
>>> DEBUG: Found Dependency: receipt exists for py36-setuptools
>>> DEBUG: Searching for dependency: python36
>>> DEBUG: Found Dependency: receipt exists for python36
>>> DEBUG: Executing org.macports.main (py36-decorator)
>>> DEBUG: dropping privileges: euid changed to 504, egid changed to 501.
>>> DEBUG: archivefetch phase started at Fri Jan 19 15:57:33 CET 2018
>>> --->  Fetching archive for py36-decorator
>>> DEBUG: Executing org.macports.archivefetch (py36-decorator)
>>> DEBUG: euid/egid changed to: 0/0
>>> DEBUG: chowned /opt/local/var/macports/incoming to macports
>>> DEBUG: euid/egid changed to: 504/501
>>> --->  py36-decorator-4.2.1_0.darwin_10.noarch.tbz2 doesn't seem to exist in 
>>> /opt/local/var/macports/incoming/verified
>>> --->  Attempting to fetch py36-decorator-4.2.1_0.darwin_10.noarch.tbz2 from 
>>> http://fco.it.packages.macports.org/mirrors/macports-packages/py36-decorator
>>>  % Total% Received % Xferd  Average Speed   TimeTime Time  
>>> Current
>>> Dload  Upload   Total   SpentLeft  Speed
>>>  0 00 00 0  0  0 --:--:--  0:00:01 --:--:-- 
>>> 0DEBUG: Fetching archive failed: The requested URL returned error: 404
>>> --->  Attempting to fetch py36-decorator-4.2.1_0.darwin_10.noarch.tbz2 from 
>>> https://packages.macports.org/py36-decorator
>>>  % Total% Received % Xferd  Average Speed   TimeTime Time  
>>> Current
>>> Dload  Upload   Total   SpentLeft  Speed
>>>  0 00 00 0  0  0 --:--:--  0:00:01 --:--:-- 
>>> 0DEBUG: Fetching archive failed: The requested URL returned error: 404
>>> --->  Attempting to fetch py36-decorator-4.2.1_0.darwin_10.noarch.tbz2 from 
>>> http://lil.fr.packages.macports.org/py36-decorator
>>>  % Total% Received % Xferd  Average Speed   TimeTime Time  
>>> Current
>>> Dload  Upload   Total   SpentLeft  Speed
>>>  0 00 00 0  0  0 --:--:--  0:00:01 --:--:-- 
>>> 0DEBUG: Fetching archive failed: The requested URL returned error: 404
>>> DEBUG: Privilege de-escalation not attempted as not running as root.
>>> DEBUG: fetch phase started at Fri Jan 19 15:57:36 CET 2018
>>> --->  Fetching distfiles for py36-decorator
>>> DEBUG: Executing org.macports.fetch (py36-decorator)
>>> --->  decorator-4.2.1.tar.gz does not exist in 
>>> /opt/local/var/macports/distfiles

Re: issue upgrading libcxxabi

[Christopher Jones]

Do what it says. uninstall libcxxabi….

> On 30 Jan 2018, at 5:44 pm, Riccardo Mottola via macports-users 
>  wrote:
> 
> Hi,
> 
> I wanted to update all my outdated packages, but I fail with:
> 
> --->  Cleaning git
> --->  Fetching distfiles for libcxxabi
> --->  Verifying checksums for libcxxabi
> --->  Extracting libcxxabi
> --->  Configuring libcxxabi
> Error: libcxxabi is obsolete; please uninstall it.
> Error: Failed to configure libcxxabi: obsolete port
> Error: See 
> /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_libcxxabi/libcxxabi/main.log
>  for details.
> Error: Follow https://guide.macports.org/#project.tickets to report a bug.
> 
> 
> before filing a bug, maybe this is expected and there is a stragey for 
> updating it or replacing it with something?
> This is on 10.6 Snow Leopard, btw.
> 
> Riccardo
> 



smime.p7s
Description: S/MIME cryptographic signature

Re: Installing gcc6 on a PPC Mac Mini 10.4 gives me hell

[Christopher Jones]

Hi

> On 22 Mar 2018, at 5:21 pm, Andreas Falkenhahn  wrote:
> 
> On 20.03.2018 at 23:59 Chris Jones wrote:
> 
>> You can call these OSes ‘retro’ if you want, to make it sound good,
>> but all they really are, are outdated and insecure.
> 
> By the way, another reason to use "outdated and insecure" operating
> systems from a programmer's point of view is backwards compatibility.
> Of course, the latest Xcode versions allow you to target older Mac OS
> versions with just a mouse click but this stuff is often hardly tested
> and I've seen the strangest things happen when building for 10.6 on
> 10.13 let's say.

No one should still be targeting such an outdated OS as 10.6, so this argument 
is moot, in my opinion.

Look, if you want to run insecure OSes like this, that is your choice, and I 
would not want to try and suggest you should not have the free will to do so. I 
just hope our digital paths never cross… I also still maintain MacPorts should 
not be going out of its way to promote the idea its OK to use such OSes. If it 
where my choice, I would drop OSX releases < say 10.10… It isn’t, and thats 
fine, but thats just my opinion.

Lets leave this here, as we aren’t going to agree on this it seems.

Chris

> 
> Upwards compatibility, however, is a completely different case
> because there are lots of binaries compiled on 10.6 or even older
> versions around and Apple usually tries hard to keep binary
> compatibility. They even support real ancient stuff like QuickDraw
> in binaries which have long been removed from the SDKs.
> 
> So it's a much better idea to keep older versions of the operating
> system and build on these than trying to build for older versions on
> newer versions.
> 
> It's also worth mentioning that APIs declared obsolete are often
> quickly removed from the SDK. So the only chance to be able to
> use APIs declared obsolete often is to keep your old installation.
> 
> -- 
> Best regards,
> Andreas Falkenhahnmailto:andr...@falkenhahn.com
> 



smime.p7s
Description: S/MIME cryptographic signature

Re: OpenOffice available?

[Christopher Jones]

> On 23 May 2018, at 12:28 am, Merton Campbell Crockett 
>  wrote:
> 
> 
>> On 2018-05-11, at 07:01, Dave Horsfall > > wrote:
>> 
>> Is there a port of OpenOffice available for the Mac?  I used to use it many 
>> moons ago on BSDi (a predecessor to FreeBSD), and quite liked it.
>> 
>> I'm particularly interested in using Impress, but a few searches have been 
>> less than successful,
> 
> 
> I’m also a former BSDi user.  When I started evaluating Apple hardware and 
> the OS X operating system as a possible replacement for Suipermicro hardware 
> and the BSD/OS operating system, I discovered NeoOffice.  It was a derivative 
> of OpenOffice that had been modified to run as a native OS X application.  I 
> found it to be much better than the early OpenOffice.org 
>  attempts to develop OpenOffice for OS X.
> 
> NeoOffice is available from NeoOffice.org  and from 
> Apple’s App Store.

Sorry, but there is nothing to justify paying for neoOffice over LibreOffice. 
It may have offered added benefit in the past, but those days are long since 
past.



smime.p7s
Description: S/MIME cryptographic signature

Re: gcc49 fails to build

[Christopher Jones]

> On 5 Jun 2018, at 5:42 pm, Dave Horsfall  wrote:
> 
> On Mon, 4 Jun 2018, Ryan Schmidt wrote:
> 
>> Here is the bug report corresponding to that problem:
>> https://trac.macports.org/ticket/56511
> 
> Ooh - a utility called "sw_vers"!  I wonder what other hidden gems are 
> lurking, essentially undocumented, on one of Apple's finest products?
> 
> After over 40 years of Unix programming, this Mac never ceases to astonish 
> me...  No, I'm not being sarcastic (for once).
> 
> Anyway...
> 
>> gcc4x is not compatible with Xcode 9.2. It may not be compatible with any 
>> Xcode 9.x. Use gcc5 or later if possible. We don't plan to backport the 
>> fixes to make gcc4x compatible with newer Xcode.
> 
> And, err, how do I achieve that?  I have this odd expectation that MacPorts 
> "just works" i.e. the dependencies have been taken care of for me.

What port are you installing/updating that requires gcc49 ? I.e. in your first 
message what was printed prior to

--->  Building gcc49
Error: Failed to build gcc49: command execution failed

??

Its possible you have a port installed using a gcc49 variant, and when you 
update this choice is maintained, even if the default has switched to a newer 
gcc. In these cases you need to manually remove the port and reinstall it with 
the newer defaults. What does

 > port installed | grep gcc

give you ?

Chris

> 
> Speaking of Xcode, I keep being offered to upgrade it, but it will only run 
> on High Sierra.  The first time I tried that, I got a message about something 
> being incompatible with this box which I couldn't write down fast enough 
> before it reverted to Sierra.  The next time I tried (paying more attention 
> this time), it bombed out because a critical file was missing...  I suppose 
> I'd better start putting money aside from my old age pension (yes, I'm a 
> pensioner) to buy an Air or something.
> 
> -- Dave, the iconoclast



smime.p7s
Description: S/MIME cryptographic signature

Re: Official Gnucash and macports conflicting libgio-2.0.0.dylib

[Christopher Jones]

> On 30 Jun 2018, at 3:28 pm, nb via macports-users 
>  wrote:
> 
> Hi,
> 
> I have macports 2.5.2 already installed.
> I have then installed Gnucash 3.2 dmg from gnucash.org.
> When I run gnucash, I have the error:
> 
> objc[93365]: Class GNotificationCenterDelegate is implemented in both 
> /Applications/Gnucash.app/Contents/Resources/lib/libgio-2.0.0.dylib 
> (0x10c333670) and /opt/local/lib/libgio-2.0.0.dylib (0x117a41620). One of the 
> two will be used. Which one is undefined.
> Segmentation fault: 11
> /opt/local/lib/libgio-2.0.0.dylib belongs to glib2 macports package.
> 
> If I rename /opt/local/lib/libgio-2.0.0.dylib, gnucash works fine. But this 
> can't be a solution.
> 
> I've also tried to set DYLB_LIBRARY_PATH to
> 
> /Applications/Gnucash.app/Contents/Resources/lib
> But this way I have the error
> 
> Segmentation fault: 11
> Is there a way to run gnucash while macports installed ?


why not just install the MacPorts version of Gnucash ??

Oberon ~ > port search gnucash
abtransfers @0.0.5.0_5 (finance)
AB-Transfers allows to carry out bank transactions online. It is meant to 
complement KMyMoney and GnuCash.

gnucash @3.2 (gnome, x11)
a personal and small-business financial-accounting software

gnucash-devel @3.2 (gnome, x11)
a personal and small-business financial-accounting software

gnucash-docs @3.2 (gnome, x11)
docs for gnucash

Found 4 ports.



smime.p7s
Description: S/MIME cryptographic signature

Re: Official Gnucash and macports conflicting libgio-2.0.0.dylib

[Christopher Jones]

The Gnucash application from gnucash.org <http://gnucash.org/> shouldn’t be 
able to find anything from /opt/local. It simply should not know about this 
path. If it is then it is either an issue with your setup in someway, or if 
that isn’t the case an issue with the application that you should report to the 
maintainers of it.

Chris

> On 30 Jun 2018, at 3:51 pm, nb  wrote:
> 
> Hi Christopher,
> 
> I did in the past, but since Gnucash 3 build fails.
> I’ve opened ticket #56675.
> But until the problem is solved I need to use the app. So I’ve downloaded the 
> dmg.
> Unfortunately there’s a conflict with macports glib2
> 
> 
> 
>> Le 30 juin 2018 à 16:35, Christopher Jones  a 
>> écrit :
>> 
>> 
>>> On 30 Jun 2018, at 3:28 pm, nb via macports-users 
>>>  wrote:
>>> 
>>> Hi,
>>> 
>>> I have macports 2.5.2 already installed.
>>> I have then installed Gnucash 3.2 dmg from gnucash.org.
>>> When I run gnucash, I have the error:
>>> 
>>> objc[93365]: Class GNotificationCenterDelegate is implemented in both 
>>> /Applications/Gnucash.app/Contents/Resources/lib/libgio-2.0.0.dylib 
>>> (0x10c333670) and /opt/local/lib/libgio-2.0.0.dylib (0x117a41620). One of 
>>> the two will be used. Which one is undefined.
>>> Segmentation fault: 11
>>> /opt/local/lib/libgio-2.0.0.dylib belongs to glib2 macports package.
>>> 
>>> If I rename /opt/local/lib/libgio-2.0.0.dylib, gnucash works fine. But this 
>>> can't be a solution.
>>> 
>>> I've also tried to set DYLB_LIBRARY_PATH to
>>> 
>>> /Applications/Gnucash.app/Contents/Resources/lib
>>> But this way I have the error
>>> 
>>> Segmentation fault: 11
>>> Is there a way to run gnucash while macports installed ?
>> 
>> 
>> why not just install the MacPorts version of Gnucash ??
>> 
>> Oberon ~ > port search gnucash
>> abtransfers @0.0.5.0_5 (finance)
>>AB-Transfers allows to carry out bank transactions online. It is meant to 
>> complement KMyMoney and GnuCash.
>> 
>> gnucash @3.2 (gnome, x11)
>>a personal and small-business financial-accounting software
>> 
>> gnucash-devel @3.2 (gnome, x11)
>>a personal and small-business financial-accounting software
>> 
>> gnucash-docs @3.2 (gnome, x11)
>>docs for gnucash
>> 
>> Found 4 ports.
>> 
> 



smime.p7s
Description: S/MIME cryptographic signature

Re: aquaterm package installation error

[Christopher Jones]

Taken this off list, as it relates to a beta version of macOS. Please don’t 
respond directly here...

> On 19 Jul 2018, at 9:24 pm, Manav Bhatia  wrote:
> 
> Hi, 
> 
>I am getting error with the aquaterm packages here: 
> http://packages.macports.org/aquaterm/ 
>  
> 
>   I have tried the *_10* and *_17* with the same issues. The readme files are 
> the ones causing issues. 
> 
> Blackbird-2:~ manav$ sudo /usr/bin/bzip2 -d -c 
> ~/Downloads/aquaterm-1.1.1_0.darwin_10.x86_64.tbz2 | ( bsdtar -xvp 
> --hfsCompression -f - )
> x ./
> x ./+COMMENT
> x ./+CONTENTS
> x ./+DESC
> x ./+PORTFILE
> x ./+STATE
> x ./Applications/
> x ./opt/
> x ./opt/local/
> x ./opt/local/Library/
> x ./opt/local/share/
> x ./opt/local/share/AquaTerm/
> x ./opt/local/share/AquaTerm/adapters/
> x ./opt/local/share/AquaTerm/adapters/ada/
> x ./opt/local/share/AquaTerm/adapters/c/
> x ./opt/local/share/AquaTerm/adapters/fortran/
> x ./opt/local/share/AquaTerm/adapters/gnuplot/
> x ./opt/local/share/AquaTerm/adapters/lisp/
> x ./opt/local/share/AquaTerm/adapters/pascal/
> x ./opt/local/share/AquaTerm/adapters/perl/
> x ./opt/local/share/AquaTerm/adapters/pgplot/
> x ./opt/local/share/AquaTerm/adapters/plplot/
> x ./opt/local/share/AquaTerm/adapters/python/
> x ./opt/local/share/AquaTerm/adapters/ruby/
> x ./opt/local/share/AquaTerm/adapters/ruby/demo_bridgesupport.rb
> x ./opt/local/share/AquaTerm/adapters/ruby/ReadMe
> x ./opt/local/share/AquaTerm/adapters/python/ChangeLog
> x ./opt/local/share/AquaTerm/adapters/python/demo.py
> x ./opt/local/share/AquaTerm/adapters/python/demo_bridgesupport.py
> x ./opt/local/share/AquaTerm/adapters/python/ReadMe
> x ./opt/local/share/AquaTerm/adapters/python/ReleaseNotes
> x ./opt/local/share/AquaTerm/adapters/plplot/ChangeLog
> x ./opt/local/share/AquaTerm/adapters/plplot/Readme: Can't unlink 
> already-existing object
> x ./opt/local/share/AquaTerm/adapters/plplot/ReleaseNotes
> x ./opt/local/share/AquaTerm/adapters/pgplot/aqdriv.m
> x ./opt/local/share/AquaTerm/adapters/pgplot/ChangeLog
> x ./opt/local/share/AquaTerm/adapters/pgplot/g77_cc_AQT.conf
> x ./opt/local/share/AquaTerm/adapters/pgplot/g77_gcc_AQT.conf
> x ./opt/local/share/AquaTerm/adapters/pgplot/iand.c
> x ./opt/local/share/AquaTerm/adapters/pgplot/ReadMe: Can't unlink 
> already-existing object
> x ./opt/local/share/AquaTerm/adapters/pgplot/ReleaseNotes
> x ./opt/local/share/AquaTerm/adapters/pgplot/xlf_gcc_AQT.conf
> x ./opt/local/share/AquaTerm/adapters/perl/AquaTerm.pm
> x ./opt/local/share/AquaTerm/adapters/perl/AquaTerm.xs
> x ./opt/local/share/AquaTerm/adapters/perl/ChangeLog
> x ./opt/local/share/AquaTerm/adapters/perl/Changes
> x ./opt/local/share/AquaTerm/adapters/perl/HOW_TO_USE
> x ./opt/local/share/AquaTerm/adapters/perl/Makefile.PL
> x ./opt/local/share/AquaTerm/adapters/perl/MANIFEST
> x ./opt/local/share/AquaTerm/adapters/perl/ppport.h
> x ./opt/local/share/AquaTerm/adapters/perl/README
> x ./opt/local/share/AquaTerm/adapters/perl/typemap
> x ./opt/local/share/AquaTerm/adapters/pascal/aquaterm.pp
> x ./opt/local/share/AquaTerm/adapters/pascal/ChangeLog
> x ./opt/local/share/AquaTerm/adapters/pascal/demo.pp
> x ./opt/local/share/AquaTerm/adapters/pascal/eventdemo1.pp
> x ./opt/local/share/AquaTerm/adapters/pascal/eventdemo2.pp
> x ./opt/local/share/AquaTerm/adapters/pascal/Makefile
> x ./opt/local/share/AquaTerm/adapters/pascal/README
> x ./opt/local/share/AquaTerm/adapters/lisp/cl-aqt.asd
> x ./opt/local/share/AquaTerm/adapters/lisp/cl-aqt.lisp
> x ./opt/local/share/AquaTerm/adapters/lisp/README
> x ./opt/local/share/AquaTerm/adapters/gnuplot/ChangeLog
> x ./opt/local/share/AquaTerm/adapters/gnuplot/ReadMe
> x ./opt/local/share/AquaTerm/adapters/gnuplot/ReleaseNotes
> x ./opt/local/share/AquaTerm/adapters/fortran/ChangeLog
> x ./opt/local/share/AquaTerm/adapters/fortran/demo.f
> x ./opt/local/share/AquaTerm/adapters/fortran/eventdemo1.f
> x ./opt/local/share/AquaTerm/adapters/fortran/f2aquaterm.m
> x ./opt/local/share/AquaTerm/adapters/fortran/Makefile
> x ./opt/local/share/AquaTerm/adapters/fortran/ReadMe: Can't unlink 
> already-existing object
> x ./opt/local/share/AquaTerm/adapters/fortran/ReleaseNotes
> x ./opt/local/share/AquaTerm/adapters/c/ChangeLog
> x ./opt/local/share/AquaTerm/adapters/c/demo.c
> x ./opt/local/share/AquaTerm/adapters/c/eventdemo1.c
> x ./opt/local/share/AquaTerm/adapters/c/eventdemo2.c
> x ./opt/local/share/AquaTerm/adapters/c/Makefile
> x ./opt/local/share/AquaTerm/adapters/c/ReadMe: Can't unlink already-existing 
> object
> x ./opt/local/share/AquaTerm/adapters/c/ReleaseNotes
> x ./opt/local/share/AquaTerm/adapters/ada/aquaterm.adb
> x ./opt/local/share/AquaTerm/adapters/ada/aquaterm.ads
> x ./opt/local/share/AquaTerm/adapters/ada/aquaterm_c.ads
> x ./opt/local/share/AquaTerm/adapters/ada/demo.adb
> x ./opt/local/share/AquaTerm/adapters/ada/demo_thin.adb
> x ./opt/local/share/AquaTerm/adapters/ada/dump_c_interface.adb
> x ./opt/local/share/AquaTe

Re: vnc

[Christopher Jones]

What exactly is your question ? The macPorts build of cotvnc is 64-bit and no 
warnings are offered running it. 

Presumably you get the warnings running some other build ?

 If you like this app just bin the one you are using and install the MacPorts 
one.

Chris

> On 24 Jul 2018, at 6:55 am, James  wrote:
> 
> For ages I have used Chicken but High Sierra warns me of it being a 32bit app.
> macports has cotvnc and also vnc
> Any opinions sage words or other
> Thanks
> James
> 
> PS Chicken means ‘Chicken of the VNC’ and cotvnc is a port of it. I assume 
> one can build it in 64bit mode



smime.p7s
Description: S/MIME cryptographic signature

Re: Port Upgrade Outdated Failure

[Christopher Jones]

Hi,

Please try

> sudo port -f uninstall cctools
> sudo port install cctools

cheers Chris

> On 27 Jul 2018, at 5:13 pm, Christopher Stone  
> wrote:
> 
> Hey Folks,
> 
> I just ran `port selfupdate` and then `port upgrade outdated`.
> 
> Self-update seems to have run fine, but the upgrade outdated process is a 
> complete fail.
> 
> I have no idea of how to troubleshoot this and would appreciate some advice.
> 
> --
> Best Regards,
> Chris
> 
> 
> 
> Model Identifier :  MacBookPro6,1
> System Version   :  macOS 10.12.6 (16G1408)
> MacPorts :  2.5.3
> 
> 
> Minerva:~ myUser$ cat 
> /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_devel_cctools/cctools/main.log
> 
> version:1
> :debug:sysinfo macOS 10.12 (darwin/16.7.0) arch i386
> :debug:sysinfo MacPorts 2.5.3
> :debug:sysinfo Xcode 9.2
> :debug:sysinfo SDK 10.12
> :debug:sysinfo MACOSX_DEPLOYMENT_TARGET: 10.12
> :msg:main --->  Computing dependencies for cctools:info:main .:debug:main 
> cctools has no conflicts
> :debug:main Searching for dependency: libunwind-headers
> :debug:main Found Dependency: receipt exists for libunwind-headers
> :debug:main Searching for dependency: llvm-4.0
> :debug:main Found Dependency: receipt exists for llvm-4.0
> :debug:main Executing org.macports.main (cctools)
> :debug:main dropping privileges: euid changed to 502, egid changed to 501.
> :debug:main Skipping completed org.macports.archivefetch (cctools)
> :debug:main Privilege de-escalation not attempted as not running as root.
> :debug:fetch fetch phase started at Fri Jul 27 10:50:23 CDT 2018
> :notice:fetch --->  Fetching distfiles for cctools
> :warn:fetch 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: 
> 
> :debug:fetch Executing org.macports.fetch (cctools)
> :info:fetch --->  ld64-274.1.tar.gz does not exist in 
> /opt/local/var/macports/distfiles/cctools
> :notice:fetch --->  Attempting to fetch ld64-274.1.tar.gz from 
> http://opensource.apple.com/tarballs/cctools
> :debug:fetch Fetching distfile failed: ê¸WÇ
> :notice:fetch --->  Attempting to fetch ld64-274.1.tar.gz from 
> http://opensource.apple.com/tarballs/ld64
> :debug:fetch Fetching distfile failed: ê¸WÇ
> :notice:fetch --->  Attempting to fetch ld64-274.1.tar.gz from 
> https://distfiles.macports.org/cctools
> :debug:fetch Fetching distfile failed: ê¸WÇ
> :notice:fetch --->  Attempting to fetch ld64-274.1.tar.gz from 
> http://ywg.ca.distfiles.macports.org/mirror/macports/distfiles/cctools
> :debug:fetch Fetching distfile failed: ê¸WÇ
> :notice:fetch --->  Attempting to fetch ld64-274.1.tar.gz from 
> http://ykf.ca.distfiles.macports.org/MacPorts/mpdistfiles/cctools
> :debug:fetch Fetching distfile failed: ê¸WÇ
> :notice:fetch --->  Attempting to fetch ld64-274.1.tar.gz from 
> http://mse.uk.distfiles.macports.org/sites/distfiles.macports.org/cctools
> :debug:fetch Fetching distfile failed: ê¸WÇ
> :notice:fetch --->  Attempting to fetch ld64-274.1.tar.gz from 
> http://sea.us.distfiles.macports.org/macports/distfiles/cctools
> :debug:fetch Fetching distfile failed: ê¸WÇ
> :notice:fetch --->  Attempting to fetch ld64-274.1.tar.gz from 
> http://lil.fr.distfiles.macports.org/cctools
> :debug:fetch Fetching distfile failed: ê¸WÇ
> :notice:fetch --->  Attempting to fetch ld64-274.1.tar.gz from 
> http://nue.de.distfiles.macports.org/cctools
> :debug:fetch Fetching distfile failed: ê¸WÇ
> :notice:fetch --->  Attempting to fetch ld64-274.1.tar.gz from 
> http://fco.it.distfiles.macports.org/mirrors/macports-distfiles/cctools
> :debug:fetch Fetching distfile failed: ê¸WÇ
> :notice:fetch --->  Attempting to fetch ld64-274.1.tar.gz from 
> http://kmq.jp.distfiles.macports.org/cctools
> :debug:fetch Fetching distfile failed: ê¸WÇ
> :notice:fetch --->  Attempting to fetch ld64-274.1.tar.gz from 
> http://cjj.kr.distfiles.macports.org/cctools
> :debug:fetch Fetching distfile failed: ê¸WÇ
> :notice:fetch --->  Attempting to fetch ld64-274.1.tar.gz from 
> https://pek.cn.distfiles.macports.org/macports/distfiles/cctools
> :debug:fetch Fetching distfile failed: ê¸WÇ
> :notice:fetch --->  Attempting to fetch ld64-274.1.tar.gz from 
> http://jog.id.distfiles.macports.org/macports/distfiles/cctools
> :debug:fetch Fetching distfile failed: ê¸WÇ
> :notice:fetch --->  Attempting to fetch ld64-274.1.tar.gz from 
> http://aarnet.au.distfiles.macports.org/pub/macports/distfiles/cctools
> :debug:fetch Fetching distfile failed: ê¸WÇ
> :notice:fetch --->  Attempting to fetch ld64-274.1.tar.gz from 
> https://sha.cn.distfiles.macports.org/macports/distfiles/cctools
> :debug:fetch Fetching distfile failed: ê¸WÇ
> :notice:fetch --->  Attempting to fetch ld64-274.1.t

Re: Port Upgrade Outdated Failure

[Christopher Jones]

another idea. Try running self update again. It sometimes needs to be run twice 
to get everything sorted. Also run sudo port sync to make sure your ports are 
up to date.

Chris

> On 27 Jul 2018, at 5:23 pm, Christopher Jones  
> wrote:
> 
> Hi,
> 
> Please try
> 
>> sudo port -f uninstall cctools
>> sudo port install cctools
> 
> cheers Chris
> 
>> On 27 Jul 2018, at 5:13 pm, Christopher Stone 
>>  wrote:
>> 
>> Hey Folks,
>> 
>> I just ran `port selfupdate` and then `port upgrade outdated`.
>> 
>> Self-update seems to have run fine, but the upgrade outdated process is a 
>> complete fail.
>> 
>> I have no idea of how to troubleshoot this and would appreciate some advice.
>> 
>> --
>> Best Regards,
>> Chris
>> 
>> 
>> 
>> Model Identifier :  MacBookPro6,1
>> System Version   :  macOS 10.12.6 (16G1408)
>> MacPorts :  2.5.3
>> 
>> 
>> Minerva:~ myUser$ cat 
>> /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_devel_cctools/cctools/main.log
>> 
>> version:1
>> :debug:sysinfo macOS 10.12 (darwin/16.7.0) arch i386
>> :debug:sysinfo MacPorts 2.5.3
>> :debug:sysinfo Xcode 9.2
>> :debug:sysinfo SDK 10.12
>> :debug:sysinfo MACOSX_DEPLOYMENT_TARGET: 10.12
>> :msg:main --->  Computing dependencies for cctools:info:main .:debug:main 
>> cctools has no conflicts
>> :debug:main Searching for dependency: libunwind-headers
>> :debug:main Found Dependency: receipt exists for libunwind-headers
>> :debug:main Searching for dependency: llvm-4.0
>> :debug:main Found Dependency: receipt exists for llvm-4.0
>> :debug:main Executing org.macports.main (cctools)
>> :debug:main dropping privileges: euid changed to 502, egid changed to 501.
>> :debug:main Skipping completed org.macports.archivefetch (cctools)
>> :debug:main Privilege de-escalation not attempted as not running as root.
>> :debug:fetch fetch phase started at Fri Jul 27 10:50:23 CDT 2018
>> :notice:fetch --->  Fetching distfiles for cctools
>> :warn:fetch 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: 
>> <https://trac.macports.org/wiki/MisbehavingServers>
>> :debug:fetch Executing org.macports.fetch (cctools)
>> :info:fetch --->  ld64-274.1.tar.gz does not exist in 
>> /opt/local/var/macports/distfiles/cctools
>> :notice:fetch --->  Attempting to fetch ld64-274.1.tar.gz from 
>> http://opensource.apple.com/tarballs/cctools
>> :debug:fetch Fetching distfile failed: ê¸WÇ
>> :notice:fetch --->  Attempting to fetch ld64-274.1.tar.gz from 
>> http://opensource.apple.com/tarballs/ld64
>> :debug:fetch Fetching distfile failed: ê¸WÇ
>> :notice:fetch --->  Attempting to fetch ld64-274.1.tar.gz from 
>> https://distfiles.macports.org/cctools
>> :debug:fetch Fetching distfile failed: ê¸WÇ
>> :notice:fetch --->  Attempting to fetch ld64-274.1.tar.gz from 
>> http://ywg.ca.distfiles.macports.org/mirror/macports/distfiles/cctools
>> :debug:fetch Fetching distfile failed: ê¸WÇ
>> :notice:fetch --->  Attempting to fetch ld64-274.1.tar.gz from 
>> http://ykf.ca.distfiles.macports.org/MacPorts/mpdistfiles/cctools
>> :debug:fetch Fetching distfile failed: ê¸WÇ
>> :notice:fetch --->  Attempting to fetch ld64-274.1.tar.gz from 
>> http://mse.uk.distfiles.macports.org/sites/distfiles.macports.org/cctools
>> :debug:fetch Fetching distfile failed: ê¸WÇ
>> :notice:fetch --->  Attempting to fetch ld64-274.1.tar.gz from 
>> http://sea.us.distfiles.macports.org/macports/distfiles/cctools
>> :debug:fetch Fetching distfile failed: ê¸WÇ
>> :notice:fetch --->  Attempting to fetch ld64-274.1.tar.gz from 
>> http://lil.fr.distfiles.macports.org/cctools
>> :debug:fetch Fetching distfile failed: ê¸WÇ
>> :notice:fetch --->  Attempting to fetch ld64-274.1.tar.gz from 
>> http://nue.de.distfiles.macports.org/cctools
>> :debug:fetch Fetching distfile failed: ê¸WÇ
>> :notice:fetch --->  Attempting to fetch ld64-274.1.tar.gz from 
>> http://fco.it.distfiles.macports.org/mirrors/macports-distfiles/cctools
>> :debug:fetch Fetching distfile failed: ê¸WÇ
>> :notice:fetch --->  Attempting to fetch ld64-274.1.tar.gz from 
>> http://kmq.jp.distfiles.macports.org/cctools
>> :debug:fetch Fetching distfile failed: ê

Re: New lynx major upgrade not yet in macports

[Christopher Jones]

> On 28 Jul 2018, at 6:15 pm, dan d.  wrote:
> 
> 
> I brought this up recently and was told to do a "pull request".
> 
> I have no experience with such things.
> 
> On the web they seem to be contributions of new or branches of ports and not 
> updating existing ports.

What exactly are you looking at ?

Git Pull requests can be viewed at

https://github.com/macports/macports-ports/pulls 


and there are certainly examples of both new ports and updates to existing ones.

> Advising the port maintainer of a request was also suggested on the web, I 
> have done so twice in the past weeks with no indication it was ever
> recieved let alone being considered.

In what manner did you ‘advise the port maintainer’. Sending a mail to this 
list is not the way. To do so either submit a pull request with the update 
yourself, or file a ticket in trac requesting an update.

https://guide.macports.org/#project.tickets 


Pull requests are more likely to get acted on quicker. For a guide to that see 
for instance

https://guide.macports.org/chunked/project.github.html 


Chris




smime.p7s
Description: S/MIME cryptographic signature

Re: Problem starting gimp

[Christopher Jones]

Hi,

For starters, try running

> sudo port sync
> sudo port upgrade outdated

and see if that helps.

Chris

> On 29 Jul 2018, at 6:24 pm, Gregory Bonar  wrote:
> 
> I just installed Macports 2.5.3.
> When I try to start gimp I get the following messages:
> dyld: Library not loaded: /opt/local/lib/libpng14.14.dylib
>   Referenced from: /opt/local/bin/gimp
>   Reason: image not found
> Abort trap: 6
> 
> I'm new to Macports.
> I just typed 'gimp' on the command line.
> Can you tell me the correct way to start gimp?
> MacOS 10.13.6
> Thanks



smime.p7s
Description: S/MIME cryptographic signature

Re: Problem starting gimp

[Christopher Jones]

It looks like something is up with your installation. Perhaps the easiest 
solution is to start from scratch, so follow

https://guide.macports.org/chunked/installing.macports.uninstalling.html 
<https://guide.macports.org/chunked/installing.macports.uninstalling.html>

to remove all traces of macports and start again.

Chris

> On 29 Jul 2018, at 7:02 pm, Gregory Bonar  wrote:
> 
> When I type 'sudo port upgrade outdated' I get:
> 
> --->  Computing dependencies for poppler
> --->  Building poppler
> Error: Failed to build poppler: command execution failed
> Error: See 
> /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_graphics_poppler/poppler/main.log
>  for details.
> 
> Main.log.gz is attached
> 
> On Sun, Jul 29, 2018 at 10:33 AM, Christopher Jones  <mailto:jon...@hep.phy.cam.ac.uk>> wrote:
> Hi,
> 
> For starters, try running
> 
> > sudo port sync
> > sudo port upgrade outdated
> 
> and see if that helps.
> 
> Chris
> 
> 
>> On 29 Jul 2018, at 6:24 pm, Gregory Bonar > <mailto:gregorybo...@gmail.com>> wrote:
>> 
>> I just installed Macports 2.5.3.
>> When I try to start gimp I get the following messages:
>> dyld: Library not loaded: /opt/local/lib/libpng14.14.dylib
>>   Referenced from: /opt/local/bin/gimp
>>   Reason: image not found
>> Abort trap: 6
>> 
>> I'm new to Macports.
>> I just typed 'gimp' on the command line.
>> Can you tell me the correct way to start gimp?
>> MacOS 10.13.6
>> Thanks
> 
> 
> 



smime.p7s
Description: S/MIME cryptographic signature

Re: SOS!

[Christopher Jones]

> On 20 Aug 2018, at 4:03 pm, Lee Bast  wrote:
> 
>> On Aug 20, 2018, at 1045 , William Parducci > > wrote:
>> 
>> I am guessing by the urgency of your request you do not have a backup. If 
>> that is the case you are going to need to find a utility that will locate 
>> unlinked files to “undelete” them since command line deletes have no concept 
>> of Trash.
> 
>   Worth noting as well since he's running High Sierra that Time Machine 
> does have a concept of local snapshots, even if no backup drive is attached 
> (though it may have to be on first, I don't use TM myself since I prefer to 
> use ZFS and rsync). If it's been less then 24 hours and is APFS formatted I'd 
> suggest immediately entering TM and see what backups might be available if 
> any. Worth a shot.
>   After that agreed, time to look at undelete options. Also immediately 
> stop using your system, boot off another drive to work on it, because once 
> stuff starts getting overwritten it's definitely gone (though I've never 
> tried recovering from an APFS drive anyway).
>   And yeah, this comes up over and over forever but you need to run 
> backups of some sort.
> 
>> For future reference NEVER issue sudo rm -rf in a multiline command. It is 
>> just asking for stuff like this to happen.
>   The guide (and a lot of MacPorts in general I guess) is more aimed at 
> devs and power users so it kind of assumes everyone is comfortable with the 
> CLI and knows basic footguns, but looking at that page it might be a 
> reasonable idea to not just tell people to run a copy-pasted multiline sudo 
> rm -rf command. It's a dangerous enough thing and it's a low bar to not say 
> "copy and run this" and change it to "here are a list of MacPorts' file and 
> directory locations, delete them for a full manual removal", then leave it to 
> users.

Whilst I have myself pointed people at that page myself in the past, perhaps a 
case could be made that having a public web page with instructions that start 
with “sudo rm -rf “ is perhaps not the best idea. If the user copies the 
command badly, and doesn’t appreciate how powerful it can be, they could (and 
it seems have) run into problems.

Perhaps we should not have that command explicitly written there. Better yet 
perhaps and official ‘uninstaller’ that does the equivalent in a control manner 
would be better.

Chris

> 
>> 
>> I have not used any of these but here are some places to start:
>> 
>> https://www.cleverfiles.com/undelete-mac.html?gclid=EAIaIQobChMItpOT9-373AIVEdbACh1umQgFEAAYASAAEgJ1y_D_BwE
>>  
>> 
>> https://www.ibeesoft.com/data-recovery-software/mac-data-recovery.html 
>> 
>> 
>> 
>> b
>> 
>>> On Aug 20, 2018, at 7:36 AM, LEYSAN GALIULLINA via macports-users 
>>> >> > wrote:
>>> 
>>> HELLO! i need y'all help so much!
>>> I have macOS High Sierra 10.13.6
>>> X Code  9.4.1
>>>  What i did is "2.4. Uninstall" following commands : 
>>> https://guide.macports.org/chunked/installing.macports.uninstalling.html 
>>> 
>>> I did Commands which starts as:  
>>> $ sudo rm -rf \
>>> /opt/local \
>>> etc.
>>> The problem is- i lost everything i had on my desktop, which i made and 
>>> collect for years. It is real important files to me, i am DJ and now i  
>>> have nothing  to work with. Please help to fix my terrible mistake and get 
>>> back everything i had (tones of music, pictures, documents,videos..etc) 
>>> please! I hope it is possible! Please, say we can do it.
>>> Kind regards,
>>> Sunley
>>> 
> 



smime.p7s
Description: S/MIME cryptographic signature

Re: SOS!

[Christopher Jones]

> On 20 Aug 2018, at 6:32 pm, William Parducci  wrote:
> 
> 
>> On Aug 20, 2018, at 10:17 AM, Christopher Jones > <mailto:jon...@hep.phy.cam.ac.uk>> wrote:
>> 
>>> On 20 Aug 2018, at 4:03 pm, Lee Bast >> <mailto:x-li...@asgarda.com>> wrote:
>>> 
>>>> On Aug 20, 2018, at 1045 , William Parducci  wrote:
>>>> 
>>>> For future reference NEVER issue sudo rm -rf in a multiline command. It is 
>>>> just asking for stuff like this to happen.
>>> The guide (and a lot of MacPorts in general I guess) is more aimed at 
>>> devs and power users so it kind of assumes everyone is comfortable with the 
>>> CLI and knows basic footguns, but looking at that page it might be a 
>>> reasonable idea to not just tell people to run a copy-pasted multiline sudo 
>>> rm -rf command. It's a dangerous enough thing and it's a low bar to not say 
>>> "copy and run this" and change it to "here are a list of MacPorts' file and 
>>> directory locations, delete them for a full manual removal", then leave it 
>>> to users.
>> 
>> Whilst I have myself pointed people at that page myself in the past, perhaps 
>> a case could be made that having a public web page with instructions that 
>> start with “sudo rm -rf “ is perhaps not the best idea. If the user copies 
>> the command badly, and doesn’t appreciate how powerful it can be, they could 
>> (and it seems have) run into problems.
>> 
>> Perhaps we should not have that command explicitly written there. Better yet 
>> perhaps and official ‘uninstaller’ that does the equivalent in a control 
>> manner would be better.
> 
> Another option for consideration is to put in a disclaimer along the lines of 
> “DO NOT ATTEMPT UNLESS YOU UNDERSTAND WHAT THIS DOES AND THE RISKS INVOLVED.” 
> on pages that have OS command line executables

That is a easy thing to do, but only helps if people read it and understand. 
Also, if the user is not familiar with doing things at the command line does 
not help prevent cut ’n’ paster errors.

>  and/or recompose the commands to individual lines so as to—in theory—make 
> them less prone to misapplication:
> 
> $ sudo rm -rf /opt/local
> $ sudo rm -rf /Applications/DarwinPorts 
> $ sudo rm -rf /Applications/MacPorts 
> $ sudo rm -rf /Library/LaunchDaemons/org.macports.* 
> $ sudo rm -rf /Library/Receipts/DarwinPorts*.pkg 
> $ sudo rm -rf /Library/Receipts/MacPorts*.pkg 
> $ sudo rm -rf /Library/StartupItems/DarwinPortsStartup 
> $ sudo rm -rf /Library/Tcl/darwinports1.0 
> $ sudo rm -rf /Library/Tcl/macports1.0 
> $ sudo rm -rf ~/.macports

I am not sure that helps. You have replace one cut and paste instance, with 
multiple ones all of which could go wrong.

My best guess as to what happened here is the OP some how got some spaces into 
the above, so effectively ran ‘sudo rm -rf *’ on their home area.

Honestly, I suspect the only safe fix here is to provide an uninstaller (could 
just be a bash script) that does it safely for the user…

Chris

> 
> b



smime.p7s
Description: S/MIME cryptographic signature

Re: cctools fails to build on Snow Leopard

[Christopher Jones]

Re: cctools fails to build on Snow Leopard

[Christopher Jones]

> On 2 Sep 2018, at 9:10 pm, Riccardo Mottola via macports-users 
>  wrote:
> 
> Hi Ken,
> 
> On 09/02/18 16:55, Ken Cunningham wrote:
>>  usr/bin/gcc-4.2 -Os -std=gnu99 -Os -DLTO_SUPPORT -g -I../../include -Wall 
>> -D_MACH_I386_THREAD_STATUS_FPSTATE_LEGACY_FIELD_NAMES_ 
>> -D_ARCHITECTURE_I386_FPU_FPSTATE_LEGACY_FIELD_NAMES_ -I/opt/local/include 
>> -I/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_devel_cctools/cctools/work/cctools-895/../ld64-274.1/src/abstraction
>>  
>> -I/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_devel_cctools/cctools/work/cctools-895/../ld64-274.1/src/other
>>  
>> -I/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_devel_cctools/cctools/work/cctools-895/include
>>  -arch x86_64 -arch i386 -I/opt/local/libexec/llvm-3.9/include -pipe -Os 
>> -fPIC -Wall -W -Wno-unused-parameter -Wwrite-strings 
>> -Wmissing-field-initializers -pedantic -Wno-long-long 
>> -Wcovered-switch-default -Wdelete-non-virtual-dtor -Werror=date-time 
>> -DNDEBUG -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS 
>> -D__STDC_LIMIT_MACROS   -c -o ./allocate.o ../allocate.c
>> 
>> 
>> I just rebuilt cctools on a vanilla 10.6.8 VM, and it built fine.
>> 
>> Your build error occurred because you're trying to force a build against the 
>> llvm-3.9 headers with the ancient gcc-4.2, and it just can't. 
>> 
>> gcc-4.2 can build against the llvm-3.4 headers (as it is set up to do by 
>> default), but I don't know if it can build against any other headers. My 
>> guess is no, but only Jeremy might have tried others.
>> 
>> If you really want to build cctools against the llvm-3.9 headers on 10.6.8 
>> (not sure why, but just sayin'), you can do that if you force a newer 
>> compiler like clang-3.9.
>> 
>> You would type something like this:
>> 
>> sudo port -v install cctools +llvm39 configure.compiler=macports-clang-3.9
>> 
>> Note - you would probably then be the only person on Earth with this 
>> configuration of cctools on 10.6.8. Who knows what kind of problems you 
>> might run into that nobody could figure out?
> 
> I did not "force" this configuration at all - I am just upgrading, so port 
> selected this heade/compiler combination by itself!

Upgrade just respects any previous options you applied, so at some point you 
must have selected these options.

Try

> sudo port -f uninstall cctools

> sudo port install cctools

That should reinstall it with the default options. If you have issues you 
should then look in your global macports config files etc. to see if you have 
changed anything there from the standard defaults.

Chris

> 
> Riccardo
> 



smime.p7s
Description: S/MIME cryptographic signature

Re: compilers on Lion

[Christopher Jones]

Hi,

> On 8 Sep 2018, at 3:08 pm, Werner LEMBERG  wrote:
> 
> 
> Folks,
> 
> 
> macports newbie here :-)

Welcome !!


> 
> I'm running a Lion box and I'm running macports from git, which works
> just fine.  I've followed the advice on LibcxxOnOlderSystems and did
> 
>  cxx_stdlib libc++
>  buildfromsourcealways.
> 
> Attached you can see the list of software that I've installed so far.
> In particular, I've installed `gcc8' and set it up as the default gcc
> compiler, which I think is a good choice later on for lilypond-devel,

What exactly did you do to set it as the ‘default’ gcc compiler ? port select ? 
This setting has no bearing on what ports use to build, its only there as a 
convenience for you, to define what you get as ‘gcc’ at the command line.

Also note that the gcc compilers do not use libc++ as their c++ runtime, but 
gcc default libstdc++. Mixing both runtimes is a very bad idea, so in fact 
using gcc is a bad choice. No ports in MacPorts will use it to build C++ 
sources.

You should instead use one of the clang compilers as your default.

> which doesn't like to be compiled with clang, AFAIK.  As the
> maintainer of FreeType and ttfautohint I'm also curious whether my
> stuff works correctly – there are some glitches here and there which I
> want to fix eventually with macport push requests as soon as I'm more
> acquainted with the system



> * Saying
> 
>port install poppler
> 
>  returns
> 
>--->  Computing dependencies for poppler
>The following dependencies will be installed: 
> clang-3.7
> clang-3.9
> clang-4.0
> clang-5.0
> libomp
> llvm-3.7
> llvm-3.9
> llvm-4.0
> llvm-5.0.
> 
>  For me, this looks like a bad joke!  *Four* compilers are necessary
>  for poppler?

No. Only one is needed for poppler. The others are likely required for the 
dependencies needed first, before you can instance poppler. 

cheers Chris

>  Additionally, it seems that since clang 3.8 it is no
>  longer necessary to have a separate `libomp' package at all, cf.
> 
>https://openmp.llvm.org/.
> 
>  Theoretically, my already installed gcc8 should compile this package
>  just fine, right?  Why doesn't `port' consider it?  Looking into
>  poppler's Portfile I don't see any compilers blacklisted.
> 
>  Please advise how to escape this dependency hell...
> 
> * Where can I get a concise and up-to-date description of portfiles?
>  `portfiles.7' seems to be heavily out of date...
> 
> I will certainly find more issues soon, but this e-mail is already too
> long :-)
> 
> 
>Werner
> 
> autoconf @2.69_5 (active)
> autoconf-archive @2018.03.13_0 (active)
> automake @1.16.1_0 (active)
> bison @3.1_0 (active)
> bison-runtime @3.1_0 (active)
> bzip2 @1.0.6_0 (active)
> cairo @1.14.12_0+quartz+x11 (active)
> cctools @895_7+llvm34 (active)
> clang-3.4 @3.4.2_12+analyzer+arm_runtime (active)
> clang_select @2_0 (active)
> cmake @3.12.1_0 (active)
> curl @7.61.1_0+ssl (active)
> curl-ca-bundle @7.61.1_1 (active)
> db48 @4.8.30_4 (active)
> dejavu-fonts @2.37_0 (active)
> djvulibre @3.5.27_0 (active)
> docbook-xml @5.0_3 (active)
> docbook-xml-4.1.2 @5.0_1 (active)
> docbook-xml-4.2 @5.0_1 (active)
> docbook-xml-4.3 @5.0_1 (active)
> docbook-xml-4.4 @5.0_1 (active)
> docbook-xml-4.5 @5.0_1 (active)
> docbook-xml-5.0 @5.0_1 (active)
> emacs @26.1_2 (active)
> emacs-app @26.1_3 (active)
> expat @2.2.6_1 (active)
> fftw-3 @3.3.8_0 (active)
> flex @2.6.4_0 (active)
> fontconfig @2.13.1_0 (active)
> fontforge @20120731_3 (active)
> freetype @2.9.1_0 (active)
> fribidi @0.19.7_1 (active)
> gcc8 @8.2.0_0 (active)
> gcc_select @0.1_8 (active)
> gd2 @2.2.5_0+x11 (active)
> gdbm @1.16_0 (active)
> gdk-pixbuf2 @2.36.12_0+x11 (active)
> gettext @0.19.8.1_0 (active)
> ghostscript @9.24_0+x11
> ghostscript @9.24_1+x11 (active)
> giflib @4.2.3_0+x11 (active)
> git @2.18.0_0+credential_osxkeychain+doc+pcre+perl5_26 (active)
> glib2 @2.56.2_0+x11 (active)
> gmp @6.1.2_1 (active)
> gnome-common @3.18.0_0 (active)
> gnutls @3.5.19_0+doc (active)
> gobject-introspection @1.56.1_1 (active)
> gperf @3.1_0 (active)
> graphite2 @1.3.9_0 (active)
> graphviz @2.40.1_1+pangocairo+x11 (active)
> groff @1.22.3_5 (active)
> gts @0.7.6_3 (active)
> guile18 @1.8.8_6 (active)
> harfbuzz @1.8.8_0 (active)
> harfbuzz-icu @1.8.8_0 (active)
> help2man @1.47.6_0 (active)
> icu @58.2_2 (active)
> ilmbase @2.2.1_0 (active)
> ImageMagick @6.9.9-40_2+x11 (active)
> intltool @0.51.0_4 (active)
> isl @0.18_0 (active)
> jasper @2.0.14_0 (active)
> jbig2dec @0.14_0
> jbig2dec @0.15_0 (active)
> jbigkit @2.1_0 (active)
> joe @4.6_0 (active)
> jpeg @9c_0 (active)
> kerberos5 @1.16.1_0 (active)
> lcms2 @2.9_1 (active)
> ld64 @3_1 (active)
> ld64-latest @274.2_2+llvm34 (active)
> libarchive @3.3.2_1 (active)
> libcomerr @1.44.3_0 (active)
> libcroco @0.6.12_0 (active)
> libcxx @5.0.1_2+universal (active)
> libedit @20170329-3.1_2 (active)
> libffi @3.2.1_0 (active)
> libgcc @1.0_0 (active)
> li

Re: compilers on Lion

[Christopher Jones]

Hi,

> On 8 Sep 2018, at 4:46 pm, Werner LEMBERG  wrote:
> 
> 
>> What exactly did you do to set it as the ‘default’ gcc compiler ?
>> port select ?
> 
> Yep.
> 
>> This setting has no bearing on what ports use to build, its only
>> there as a convenience for you, to define what you get as ‘gcc’ at
>> the command line.
> 
> OK, thanks.
> 
>> Also note that the gcc compilers do not use libc++ as their c++
>> runtime, but gcc default libstdc++.  Mixing both runtimes is a very
>> bad idea, so in fact using gcc is a bad choice.  No ports in
>> MacPorts will use it to build C++ sources.
> 
> OK.  BTW, I see on
> 
>  https://libcxx.llvm.org/docs/UsingLibcxx.html#using-libc-with-gcc
> 
> that gcc on MacOS actually *can* use libc++…

Oh yes. But MacPorts is not setup at all to do that, as frankly there is little 
need. clang is the default compiler on macOS since quite a while, and thus the 
focus is on using this rather than gcc.

>> No. Only one is needed for poppler.  The others are likely required
>> for the dependencies needed first, before you can instance poppler.
> 
> Indeed.  Building clang-5.0 needs three previous versions!  This is
> bad…


Not really. Each port in MacPorts is free to define which compiler it wants to 
use. Most work fine with the defaults on a given system, but sometimes they 
need to change this and for this they use the compilers blacklists and 
fallbacks options.

its perfectly fine for a mixture of compilers to be used by various ports, as 
they feel fit. The only things that matters, for c++ sources, is they all share 
the same c++ runtime.

For most users this is a non issue, as they get pre-built binaries made by the 
MacPorts builbots. Building from source is in fact rare. In your case though 
you are forcing this for everything, so you are going to just have to except 
the consequences, which is a number of different compilers will be required.

> 
> BTW, looking at
> 
>  http://llvm.org/docs/GettingStarted.html#requirements
> 
> I see that llvm can be built with gcc > 4.8 – for this I can
> definitely use my already installed gcc8, right?  It's funny that the
> native Lion compiler can build gcc8 (since it only needs a C++98
> compiler) but not the older clang-5.0…

the clang sources have always used more up to date C++ features than gcc, so 
this is not really so surprising.

> 
> So: What is the right option to enforce gcc8 for building clang-5.0?

There isn’t one. Sorry, but using gcc to build c++ sources is really not a 
focus for MacPorts.

> And what about installing clang-7.0 instead of 5.0?  Will `port'
> accept that for C++11 stuff as a default?

clang-7.0 is very very new, and as such MacPorts will not (yet) considered it 
as a fallback compiler. clang 6.0 is the newest used for that.

Chris

> 
> I can also imagine to follow this route in general (at least on Lion):
> First, you build a recent gcc version with the native Apple compiler,
> then you use it to build a recent clang version.  This would avoid the
> compilation of three intermediate clang versions that probably nobody
> needs later on.
> 
> 
>Werner



smime.p7s
Description: S/MIME cryptographic signature

Re: TeXLive distribution and macports

[Christopher Jones]

Hi,

If I understand what you are asking correctly, you are asking how to setup a 
port that does nothing other than depend on other ports, so installing it drags 
in all the dependencies, in one go ? If so we have plenty of these in MacPorts. 
The first that springs to mind for instance is

https://github.com/macports/macports-ports/blob/master/x11/xorg-proto/Portfile 


One trick is the port has to install *something* in order to work, for instance 
with the binary tarballs. A common trick is to create a README or similar…

cheers Chris

> On 9 Sep 2018, at 3:16 pm, Werner LEMBERG  wrote:
> 
> 
> My computer for daily use is an openSuSE GNU/Linux box; for TeX
> processing, however, I'm directly using tlmgr.[*] Regardless of this I
> don't have any dependency issues with `zypper', openSuSE's package
> manager, since I'm using the nifty `texlive-dummy-opensuse' package,
> 
>  https://github.com/rolfn/texlive-dummy-opensuse.git   .
> 
> This package tells zypper that all TeXLive packages provided by
> openSuSE are installed, without installing them actually.
> 
> I would like to have something similar for MacPorts.  My questions:
> 
> * Has anyone already written such a dummy package?
> 
> * If not, how can I construct `empty packages' that only exist to
>  fulfill package dependencies?
> 
> 
>Werner
> 
> 
> [*] To be more precise, I don't use tlmgr at all but directly
>TeXLive's SVN repository.  However, this distinction doesn't
>matter here.



smime.p7s
Description: S/MIME cryptographic signature

Re: TeXLive distribution and macports

[Christopher Jones]

Hi,

Then I am not sure what you intention here is.

Note that MacPorts has a policy of not using external libraries, as far as 
possible (apart from obvious system ones) so if you aim is to have a port that 
basically allows something externally externally to pretend to be something 
MacPorts provides, then no this is strictly not allowed. See for instance

https://trac.macports.org/wiki/FAQ#ownlibs 


its the same deal as why we do not support using anything installed outside of 
MacPorts, from /usr/local

cheers Chris


> On 9 Sep 2018, at 3:46 pm, Werner LEMBERG  wrote:
> 
> 
>> If I understand what you are asking correctly, you are asking how to
>> setup a port that does nothing other than depend on other ports, so
>> installing it drags in all the dependencies, in one go?
> 
> No, I want the opposite.  For example, I want to create a replacement
> for `texlive-basic' that does nothing except fulfilling the
> dependency.  This is, after installing this dummy `texlive-basic',
> `port' shall believe that `texlive-basic' is indeed installed.
> 
> Ditto for all other `texlive-*' ports.  Ideally, I would like to have
> all this stuff in a single file, to be automatically created from the
> actual list of `texlive-*' ports as in texlive-dummy-opensuse,
> cf. 
> https://github.com/rolfn/texlive-dummy-opensuse/blob/ba0bc1e2f866c379f750046439b6f4e40725805f/Makefile#L61
> and following lines.
> 
>> If so we have plenty of these in MacPorts.  [...]
> 
> Thanks; I've already seen such meta-packages.  One of them is actually
> `texlive' itself :-)
> 
> 
>Werner



smime.p7s
Description: S/MIME cryptographic signature

Re: TeXLive distribution and macports

[Christopher Jones]

> On 9 Sep 2018, at 4:46 pm, Werner LEMBERG  wrote:
> 
> 
>>> [...] For example, I want to create a replacement for
>>> `texlive-basic' that does nothing except fulfilling the dependency.
>>> This is, after installing this dummy `texlive-basic', `port' shall
>>> believe that `texlive-basic' is indeed installed.
>>> 
>>> Ditto for all other `texlive-*' ports.  Ideally, I would like to
>>> have all this stuff in a single file, to be automatically created
>>> from the actual list of `texlive-*' ports as in
>>> texlive-dummy-opensuse,
>>> cf. 
>>> https://github.com/rolfn/texlive-dummy-opensuse/blob/ba0bc1e2f866c379f750046439b6f4e40725805f/Makefile#L61
>>> and following lines.
>> 
>> Then I am not sure what you intention here is.
>> 
>> Note that MacPorts has a policy of not using external libraries, as
>> far as possible (apart from obvious system ones) so if you aim is to
>> have a port that basically allows something externally externally to
>> pretend to be something MacPorts provides, then no this is strictly
>> not allowed. See for instance
>> 
>> https://trac.macports.org/wiki/FAQ#ownlibs 
>> 
>> 
>> its the same deal as why we do not support using anything installed
>> outside of MacPorts, from /usr/local
> 
> Ah, I assumed too much knowledge, sorry.  TeXLive itself comes with
> binaries for MacOS (both legacy platforms, i.e., 10.6-10.10, and
> recent versions, i.e., 10.10-10.13).  By simply prepending the path to
> those binaries to PATH, the `texlive-*' ports from MacPorts would be
> completely hidden and thus useless, more or less: TeXLive wouldn't use
> any data, binaries, or libraries from MacPorts.
> 
> However, to build various packages like `lilypond', `port' needs to
> believe that some `texlive-*' ports are installed.  What certainly
> works is to create a small port repository similar to René Bertin's
> `macstrop' repository to override MacPorts with dummy ports.  My
> question was whether macports itself provides a simpler solution
> similar to `texlive-dummy-opensuse', where I have to install just a
> single .rpm file...  I guess the answer is no.

Its quite simple. The macports build of lilypond should be configured to use 
the MacPorts provided builds of TexLive. If these ports do not provide what is 
needed, then just provide an additional port for what is missing.

Chris

> 
> 
>Werner



smime.p7s
Description: S/MIME cryptographic signature

Re: Requesting new variant for octave and arpack

[Christopher Jones]

Hi,

For feature requests please either file a feature request in MacPorts Trac, or 
even better implement the change yourself and submit a Pull Request to GiHub 
with the changes. mails to this list are far from guaranteed to have any impact 
in these cases.

Chris

> On 9 Sep 2018, at 5:49 pm, Manav Bhatia  wrote:
> 
> Greetings! 
> 
>Please see the discussion here: 
> https://github.com/opencollab/arpack-ng/issues/149#issuecomment-419715128 
> 
> http://octave.1599824.n4.nabble.com/Issues-with-eigs-td4689314.html#a4689334 
> 
> 
>We have identified a bug in system lapack provided by the accelerate 
> framework that prevents proper functioning of arpack. 
> 
>I am writing to request the addition of a new variant in installation of 
> arpack and octave to use lapack installed from macports. Something like: 
> 
> $ port install octave +lapack 
> 
>Currently the only two variants for lapack are accelerate and atlas. 
> 
> Regards,
> Manav
> 
> 



smime.p7s
Description: S/MIME cryptographic signature

Re: git stash problem with `port sync'

[Christopher Jones]

Hi,

Mostly likely because the global settings are under your home area, whilst the 
checkout below is not.

Just go to  /opt/macports/macports-ports and set the local settings for that 
area as well.

Or, move your ports checkout to somewhere in your home area.

Chris

> On 15 Sep 2018, at 11:49 am, Werner LEMBERG  wrote:
> 
> 
> Folks,
> 
> 
> after doing various network hacks, calling `port -d sync' now fails.
> 
>  --->  Updating the ports tree
>  Synchronizing local ports tree from file:///opt/macports/macports-ports
>  DEBUG: /opt/local/bin/git pull --rebase --autostash
>  DEBUG: system -W /opt/macports/macports-ports: /opt/local/bin/git pull 
> --rebase --autostash
> 
>  *** Please tell me who you are.
> 
>  Run
> 
>git config --global user.email "y...@example.com"
>git config --global user.name "Your Name"
> 
>  to set your account's default identity.
>  Omit --global to set the identity only in this repository.
> 
>  fatal: unable to auto-detect email address (got '...@...')
>  Cannot save the current index state
>  Cannot autostash
>  Command failed: /opt/local/bin/git pull --rebase --autostash
>  Exit code: 1
> 
> Note that I already have set user name and e-mail adress globally, but
> the error persists.  Manually calling `git stash' works also just fine.
> 
> Any ideas how to solve this?
> 
> 
>Werner



smime.p7s
Description: S/MIME cryptographic signature

Re: Mojave port install p5.26-mail-clamav fails

[Christopher Jones]

Hi,

Please at least try and look for the relevant message instead of just dumping 
everything into a mail.

info:configure The clamav version you are using is too old. Please upgrade to 
at least 0.95.1

So, follow the instructions below.

Error: Follow https://guide.macports.org/#project.tickets 
 to report a bug.

If you cannot find a ticket, create one.

Chris

> On 27 Oct 2018, at 1:12 pm, Steve Wardle via macports-users 
>  wrote:
> 
> Hi,
> 
> 572 ports successfully installed but as subject:
> 
> # port install p5.26-mail-clamav
> --->  Computing dependencies for p5.26-mail-clamav
> --->  Fetching archive for p5.26-mail-clamav
> --->  Attempting to fetch p5.26-mail-clamav-0.290.0_6.darwin_18.x86_64.tbz2 
> from https://packages.macports.org/p5.26-mail-clamav
> --->  Attempting to fetch p5.26-mail-clamav-0.290.0_6.darwin_18.x86_64.tbz2 
> from 
> http://mse.uk.packages.macports.org/sites/packages.macports.org/p5.26-mail-clamav
> --->  Attempting to fetch p5.26-mail-clamav-0.290.0_6.darwin_18.x86_64.tbz2 
> from http://lil.fr.packages.macports.org/p5.26-mail-clamav
> --->  Fetching distfiles for p5.26-mail-clamav
> --->  Verifying checksums for p5.26-mail-clamav
> --->  Extracting p5.26-mail-clamav
> --->  Applying patches to p5.26-mail-clamav
> --->  Configuring p5.26-mail-clamav
> --->  Building p5.26-mail-clamav
> Error: Failed to build p5.26-mail-clamav: command execution failed
> Error: See 
> /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_perl_p5-mail-clamav/p5.26-mail-clamav/main.log
>  for details.
> Error: Follow https://guide.macports.org/#project.tickets to report a bug.
> Error: Processing of port p5.26-mail-clamav failed
> 
> Log file:
> 
> version:1
> :debug:sysinfo macOS 10.14 (darwin/18.0.0) arch i386
> :debug:sysinfo MacPorts 2.5.4
> :debug:sysinfo Xcode 10.0
> :debug:sysinfo SDK 10.14
> :debug:sysinfo MACOSX_DEPLOYMENT_TARGET: 10.14
> :debug:main epoch: in tree: 0 installed: 0
> :debug:main perl5.26 5.26.2_1 exists in the ports tree
> :debug:main perl5.26 5.26.2_1  is the latest installed
> :debug:main perl5.26 5.26.2_1  is active
> :debug:main Merging existing variants '' into variants
> :debug:main new fully merged portvariants: 
> :debug:main Changing to port directory: 
> /opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/ports/lang/perl5
> :debug:main OS darwin/18.0.0 (Mac OS X 10.14) arch i386
> :debug:main Re-registering default for configure.universal_args
> :debug:main Sourcing PortGroup perl5 1.0 from 
> /opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/ports/_resources/port1.0/group/perl5-1.0.tcl
> :debug:main adding the default universal variant
> :debug:main Reading variant descriptions from 
> /opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/ports/_resources/port1.0/variant_descriptions.conf
> :debug:main Running callback 
> portconfigure::add_automatic_compiler_dependencies
> :debug:main Finished running callback 
> portconfigure::add_automatic_compiler_dependencies
> :debug:main Running callback portbuild::add_automatic_buildsystem_dependencies
> :debug:main Finished running callback 
> portbuild::add_automatic_buildsystem_dependencies
> :debug:main Running callback portstartupitem::add_notes
> :debug:main Finished running callback portstartupitem::add_notes
> :debug:main No need to upgrade! perl5.26 5.26.2_1 >= perl5.26 5.26.2_1
> :debug:main epoch: in tree: 0 installed: 0
> :debug:main gdbm 1.16_0 exists in the ports tree
> :debug:main gdbm 1.16_0  is the latest installed
> :debug:main gdbm 1.16_0  is active
> :debug:main Merging existing variants '' into variants
> :debug:main new fully merged portvariants: 
> :debug:main Changing to port directory: 
> /opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/ports/databases/gdbm
> :debug:main OS darwin/18.0.0 (Mac OS X 10.14) arch i386
> :debug:main adding the default universal variant
> :debug:main Reading variant descriptions from 
> /opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/ports/_resources/port1.0/variant_descriptions.conf
> :debug:main Running callback 
> portconfigure::add_automatic_compiler_dependencies
> :debug:main Finished running callback 
> portconfigure::add_automatic_compiler_dependencies
> :debug:main Running callback portbuild::add_automatic_buildsystem_dependencies
> :debug:main Finished running callback 
> portbuild::add_automatic_buildsystem_dependencies
> :debug:main Running callback portstartupitem::add_notes
> :debug:main Finished running callback portstartupitem::add_notes
> :debug:main No need to upgrade! gdbm 1.16_0 >= gdbm 1.16_0
> :debug:main epoch: in tree: 2 installed: 2
> :debug:main gettext 0.19.8.1_0 exists in the ports tree
> :debug:main gettext 0.19.8.1_0  is the latest installed
> :debug:main gettext 0.19.8.1_0  is active
> :debug:main Mer

Re: extractpdfmark build failure on 10.6

[Christopher Jones]

> On 28 Oct 2018, at 7:24 am, Ken Cunningham  
> wrote:
> 
> something like this from another port earlier today should do, until this 
> issue finally gets fixed in the compiler run deps.
> 
>   
> >

Small comment, but cctools works fine on all OSes versions, so there is really 
no need to put it inside a Darwin version check. In fact, for all OSes using 
Xcode 7 or older it provides a newer toolchain. I would just remove the Darwin 
version check..

Chris

> 
> On Oct 27, 2018, at 23:55, Werner LEMBERG  > wrote:
> 
>> 
>> Folks,
>> 
>> 
>> please have a look at this build log
>> 
>>  
>> https://build.macports.org/builders/ports-10.6_x86_64_legacy-builder/builds/83428
>>  
>> 
>> 
>> It fails with
>> 
>>  /usr/bin/ranlib: object:
>>
>> libextractpdfmark-poppler-core.a(libextractpdfmark_poppler_core_a-pagemode.o)
>>malformed object (unknown load command 2)
>> 
>> Searching in the web, I've found a similar report w.r.t. ranlib:
>> 
>>  
>> https://lists.macports.org/pipermail/macports-dev/2018-September/039282.html 
>> 
>> 
>> It essentially says that `cctools' needs to be installed.  Is this a
>> dependency that I should add to extrapdfmark's Portfile?  Looking into
>> other Portfiles, maybe
>> 
>>  platform darwin 10 {
>>  depends_build-append   port:cctools
>>  }
>> 
>> is the right fix – is this sufficient to make macports use the newer
>> `ranlib' binary?
>> 
>> Another issue: extractpdfmark doesn't really need GhostScript for
>> compilation and execution; however, it will be optionally used for
>> some `make check' tests.  On the other hand, using the program makes
>> only sense if the calling Makefile (or whatever) feeds
>> extractpdfmark's output into GS.  Shall this be somehow reflected in
>> the Portfile, maybe an `optional dependency'?  If yes, how do I do
>> that?
>> 
>> 
>>Werner



smime.p7s
Description: S/MIME cryptographic signature

Re: problems with MP version of gfortran

[Christopher Jones]

Hi,

cctools was updated recently, changing the default variants it was built with. 
This caused issues with the gcc compilers, so those where rev-bumped last week 
to adapt.

The issue though is users on 10.2+  who had cctools installed would have done 
so with the xcode variant installed. The recent update that was pushed change 
this, and users need to make sure they update their installation to get this as 
by default, port will retain the previously requested variants a port was 
installed with, so would retain the now non-default Xcode variant. 

So you need to force reinstall cctools.

> sudo port uninstall cctools

ignore the warnings, then

> sudo port install cctools

you should then have the new defaults.

Unfortunately, the author of the recent cctools change did not put in code to 
automatic upgrade users from the xcode variant to the llvm70 variant (which is 
now the default). This should have been done.

https://github.com/macports/macports-ports/commit/78b67f819222a83f7a198213fb8a1d0758cb7753#diff-8680d6e0db3e1a08c29d7699d58be6b7
 


When the Xcode variant was added a while back (to fix issues with the old 
cctools on Xcode 9 systems) code was added to automatically migrate users to 
it, see the removed line 64-75 above. Similar should have now have been added 
to put them back on the llvm70 variant.

cheers Chris

> On 10 Nov 2018, at 3:34 pm, pagani laurent via macports-users 
>  wrote:
> 
> Hi,
> 
> I am running OSX10.12.
> 
> I had gcc 7.3 and gcc 5.5.0_1 installed.
> 
> When trying to compile a simple .f90 code (simpling printing some double 
> precision complex, a ”hello world” for complex numbers),
> I get this error message :
> 
> SIGMA>which gfortran
> /opt/local/bin/gfortran
> SIGMA>gfortran -o essai essai.f90
> FATAL:/opt/local/bin/../libexec/as/x86_64/as: I don't understand 'm' flag!
> 
> Then I selected the gcc5 version and the FATAL error disappeared. 
> I selfupdated MP which moved from 2.5.3 to 2.5.4, and I upgraded outdated.
> 
> gcc7.3 still shows the error and gcc5.5.0_3 which was installed in the 
> upgrade started to show the same FATAL error !
> I tried to return to gcc5.5.0_1 but failed (probably did not do the right 
> thing…)
> 
> I installed gfortran directly in /usr/local/bin, the version 8.1, and I have 
> no FATAL error! I have not yet tried to install gcc8 via Macport but googling 
> a little, people with the same problem seem to end up removing macport 
> (/opt/local/bin) from their PATH, which is a bit extreme…
> 
> Is the problem known and solvable more cleanly ? I’d rather have a single 
> gfortran on my laptop.
> 
> Thanks,
> Laurent
> 
> "S'il n'y a pas de solution, c'est qu'il n'y a pas de problème" (devise 
> Shadok)
> 



smime.p7s
Description: S/MIME cryptographic signature

Re: problems with MP version of gfortran

[Christopher Jones]

> On 10 Nov 2018, at 7:09 pm, Christopher Jones  
> wrote:
> 
> Hi,
> 
> cctools was updated recently, changing the default variants it was built 
> with. This caused issues with the gcc compilers, so those where rev-bumped 
> last week to adapt.
> 
> The issue though is users on 10.2+  who had cctools installed would have done 
> so with the xcode variant installed. The recent update that was pushed change 
> this, and users need to make sure they update their installation to get this 
> as by default, port will retain the previously requested variants a port was 
> installed with, so would retain the now non-default Xcode variant. 
> 
> So you need to force reinstall cctools.
> 
> > sudo port uninstall cctools
> 
> ignore the warnings, then
> 
> > sudo port install cctools
> 
> you should then have the new defaults.

also, please run

> sudo  port sync
> sudo port upgrade outdated

to make sure you then have everything in sync.

> 
> Unfortunately, the author of the recent cctools change did not put in code to 
> automatic upgrade users from the xcode variant to the llvm70 variant (which 
> is now the default). This should have been done.
> 
> https://github.com/macports/macports-ports/commit/78b67f819222a83f7a198213fb8a1d0758cb7753#diff-8680d6e0db3e1a08c29d7699d58be6b7
>  
> <https://github.com/macports/macports-ports/commit/78b67f819222a83f7a198213fb8a1d0758cb7753#diff-8680d6e0db3e1a08c29d7699d58be6b7>
> 
> When the Xcode variant was added a while back (to fix issues with the old 
> cctools on Xcode 9 systems) code was added to automatically migrate users to 
> it, see the removed line 64-75 above. Similar should have now have been added 
> to put them back on the llvm70 variant.
> 
> cheers Chris
> 
>> On 10 Nov 2018, at 3:34 pm, pagani laurent via macports-users 
>> > <mailto:macports-users@lists.macports.org>> wrote:
>> 
>> Hi,
>> 
>> I am running OSX10.12.
>> 
>> I had gcc 7.3 and gcc 5.5.0_1 installed.
>> 
>> When trying to compile a simple .f90 code (simpling printing some double 
>> precision complex, a ”hello world” for complex numbers),
>> I get this error message :
>> 
>> SIGMA>which gfortran
>> /opt/local/bin/gfortran
>> SIGMA>gfortran -o essai essai.f90
>> FATAL:/opt/local/bin/../libexec/as/x86_64/as: I don't understand 'm' flag!
>> 
>> Then I selected the gcc5 version and the FATAL error disappeared. 
>> I selfupdated MP which moved from 2.5.3 to 2.5.4, and I upgraded outdated.
>> 
>> gcc7.3 still shows the error and gcc5.5.0_3 which was installed in the 
>> upgrade started to show the same FATAL error !
>> I tried to return to gcc5.5.0_1 but failed (probably did not do the right 
>> thing…)
>> 
>> I installed gfortran directly in /usr/local/bin, the version 8.1, and I have 
>> no FATAL error! I have not yet tried to install gcc8 via Macport but 
>> googling a little, people with the same problem seem to end up removing 
>> macport (/opt/local/bin) from their PATH, which is a bit extreme…
>> 
>> Is the problem known and solvable more cleanly ? I’d rather have a single 
>> gfortran on my laptop.
>> 
>> Thanks,
>> Laurent
>> 
>> "S'il n'y a pas de solution, c'est qu'il n'y a pas de problème" (devise 
>> Shadok)
>> 
> 



smime.p7s
Description: S/MIME cryptographic signature

Re: problems with MP version of gfortran

[Christopher Jones]

See

https://github.com/macports/macports-ports/pull/2980 
<https://github.com/macports/macports-ports/pull/2980>

Chris

> On 10 Nov 2018, at 7:13 pm, Christopher Jones  
> wrote:
> 
> 
> 
>> On 10 Nov 2018, at 7:09 pm, Christopher Jones > <mailto:jon...@hep.phy.cam.ac.uk>> wrote:
>> 
>> Hi,
>> 
>> cctools was updated recently, changing the default variants it was built 
>> with. This caused issues with the gcc compilers, so those where rev-bumped 
>> last week to adapt.
>> 
>> The issue though is users on 10.2+  who had cctools installed would have 
>> done so with the xcode variant installed. The recent update that was pushed 
>> change this, and users need to make sure they update their installation to 
>> get this as by default, port will retain the previously requested variants a 
>> port was installed with, so would retain the now non-default Xcode variant. 
>> 
>> So you need to force reinstall cctools.
>> 
>> > sudo port uninstall cctools
>> 
>> ignore the warnings, then
>> 
>> > sudo port install cctools
>> 
>> you should then have the new defaults.
> 
> also, please run
> 
> > sudo  port sync
> > sudo port upgrade outdated
> 
> to make sure you then have everything in sync.
> 
>> 
>> Unfortunately, the author of the recent cctools change did not put in code 
>> to automatic upgrade users from the xcode variant to the llvm70 variant 
>> (which is now the default). This should have been done.
>> 
>> https://github.com/macports/macports-ports/commit/78b67f819222a83f7a198213fb8a1d0758cb7753#diff-8680d6e0db3e1a08c29d7699d58be6b7
>>  
>> <https://github.com/macports/macports-ports/commit/78b67f819222a83f7a198213fb8a1d0758cb7753#diff-8680d6e0db3e1a08c29d7699d58be6b7>
>> 
>> When the Xcode variant was added a while back (to fix issues with the old 
>> cctools on Xcode 9 systems) code was added to automatically migrate users to 
>> it, see the removed line 64-75 above. Similar should have now have been 
>> added to put them back on the llvm70 variant.
>> 
>> cheers Chris
>> 
>>> On 10 Nov 2018, at 3:34 pm, pagani laurent via macports-users 
>>> >> <mailto:macports-users@lists.macports.org>> wrote:
>>> 
>>> Hi,
>>> 
>>> I am running OSX10.12.
>>> 
>>> I had gcc 7.3 and gcc 5.5.0_1 installed.
>>> 
>>> When trying to compile a simple .f90 code (simpling printing some double 
>>> precision complex, a ”hello world” for complex numbers),
>>> I get this error message :
>>> 
>>> SIGMA>which gfortran
>>> /opt/local/bin/gfortran
>>> SIGMA>gfortran -o essai essai.f90
>>> FATAL:/opt/local/bin/../libexec/as/x86_64/as: I don't understand 'm' flag!
>>> 
>>> Then I selected the gcc5 version and the FATAL error disappeared. 
>>> I selfupdated MP which moved from 2.5.3 to 2.5.4, and I upgraded outdated.
>>> 
>>> gcc7.3 still shows the error and gcc5.5.0_3 which was installed in the 
>>> upgrade started to show the same FATAL error !
>>> I tried to return to gcc5.5.0_1 but failed (probably did not do the right 
>>> thing…)
>>> 
>>> I installed gfortran directly in /usr/local/bin, the version 8.1, and I 
>>> have no FATAL error! I have not yet tried to install gcc8 via Macport but 
>>> googling a little, people with the same problem seem to end up removing 
>>> macport (/opt/local/bin) from their PATH, which is a bit extreme…
>>> 
>>> Is the problem known and solvable more cleanly ? I’d rather have a single 
>>> gfortran on my laptop.
>>> 
>>> Thanks,
>>> Laurent
>>> 
>>> "S'il n'y a pas de solution, c'est qu'il n'y a pas de problème" (devise 
>>> Shadok)



smime.p7s
Description: S/MIME cryptographic signature

Re: How Mojave-ready is MacPorts?

[Christopher Jones]

Hi,

MacPorts was 'more or less’ ready for Mojave from when it was first released. 

If what you are asking is are binaries available for the ports I care about, 
only you can check that as no one else knows what you intend to install. 

Go to

http://packages.macports.org 

and check to see if the ports you care about most have binary tarballs 
available. Most probably do by now, but there are likely still some the 
builedbot is working through.

Chris

> On 10 Nov 2018, at 8:37 pm, Dave Horsfall  wrote:
> 
> I ask because assuming I give High Sierra a miss (which failed twice on my 
> early 2009 13" MacBook for different reasons) and try Mojave instead, are the 
> binaries more or less ready to go?  Mass compilations will render this thing 
> unusable (we're talking typing echoes measured in *seconds*), and it's the 
> main client on my LAN.
> 
> Thanks.
> 
> -- Dave



smime.p7s
Description: S/MIME cryptographic signature

Re: Mojave migration

[Christopher Jones]

Personally, I always recommend *not* using the ./restore_ports.tcl script but 
instead look at the requested ports file you created, and then install by hand 
those you still want. The problem with the restore script is it attempts to 
restore everything, exactly was it was, which is not always want you want. 
dependencies can sometimes change between OSes versions for instance.

In this case, doing this one by one will also let you find out which port is 
giving you problems.

Chris

> On 12 Nov 2018, at 9:52 pm, Ken G. Brown via macports-users 
>  wrote:
> 
> Following https://trac.macports.org/wiki/Migration
> 
> Got to sudo ./restore_ports.tcl myports.txt
> then:
>> sudo ./restore_ports.tcl myports.txt
>> Error: we appear to be stuck, exiting...
>> infinite loop
>>while executing
>> "sort_ports $portList"
>>invoked from within
>> "set operationList [sort_ports $portList]"
>>(file "./restore_ports.tcl" line 285)
> 
> macOS 10.14.2 Beta (18C38b)
> 
> What should I do next?
> Thx for any tips.
> Ken G. Brown



smime.p7s
Description: S/MIME cryptographic signature

Re: What installs "pip"?

[Christopher Jones]

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

No, not odd at all.

What you showed is

> keybounceMBP:js-beautify michael$ port select --summary
> Name   Selected  Options
>      ===
> pipnone  pip36 none

so pip36 and none are valid available options, but the one you had active at 
the time was none. i,e. nothing was selected, which is exactly what you found.

> (Equally odd -- installing python36 in the first place did not install a pip 
> if it is part of the python system).

It was installed, as ‘pip-3.6’.

You have to manually decide to ‘port select’ it if you want to use that version 
as ‘pip’ or ‘pip3’.

> 
> Side question: Why is there not just a "python3", why do we have to 
> specifically select one of several versions?

Because macPorts offers various different 3.x versions, so gives use the 
ability to pick which they want by default themselves.

Chris



smime.p7s
Description: S/MIME cryptographic signature

Re: Anyone running X11 apps on Mojave?

[Christopher Jones]

> 
>> On Nov 23, 2018, at 10:13 PM, Randolph M. Fritz > > wrote:
>> 
>> No, they don't. It's been open-sourced. Up to High Sierra, at least, it 
>> works. There hasn't been a formal release since two years ago October, so 
>> I'm wondering about Mojave.
>> -- 


Apple have not supported (i.e. shipped with the OS) X11 or Xquartz for some 
time now.

Note that the version of Xquartz from 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.

I have exclusively used the MacPorts port for a number of years now, and it 
works flawlessly, on all OSes including 10.14. I recommend switching to it, if 
you currently are running the Xquartz installer version.

Chris

>> Randolph M. Fritz || +1 206 659-8617 || rmfri...@gmail.com 
>> 
>> 
>> On Fri, Nov 23, 2018 at 9:59 PM Fred Weinhaus > > wrote:
>> I use Xquartz on my Mac OSX Sierra just fine. But I got it from 
>> https://www.xquartz.org . I do not think Apple 
>> supports X11 any longer, only Quartz.
>> 
>> 
>> 
>> 
>> 
>>> On Nov 23, 2018, at 9:52 PM, Randolph M. Fritz >> > wrote:
>>> 
>>> Does Xquartz still work? or MacPorts X11? Or…?
>>> -- 
>>> Randolph M. Fritz || +1 206 659-8617 || rmfri...@gmail.com 
>>> 
> 



smime.p7s
Description: S/MIME cryptographic signature

Re: Anyone running X11 apps on Mojave?

[Christopher Jones]

> On 24 Nov 2018, at 4:22 pm, Richard L. Hamilton  wrote:
> 
> One might suppose there are still people for which the standalone packaging 
> of Xquartz might be preferable - people that for whatever reason, don't want 
> to deal with the extra steps involved in installing MacPorts (including 
> installing Xcode plus command line tools), let alone updating it, and don't 
> think they'd want any of the other packages it offers.

I am simply stating what the maintainer himself has stated on the Xquartz 
mailing lists. 

I don’t disagree, but also I made the comment on this list on the assumption 
everything here does have MP installed. In that case I would suggest using the 
port is the better option.

The maintainer has also stated if someone wanted to do the work to simplify the 
task of creating a standalone installer from the MP installation, he would 
welcome it, as he has very limited time to devote to maintaining X11 on macOS 
(which is why he might only focus on MP going forward).

Chris

smime.p7s
Description: S/MIME cryptographic signature

Re: Anyone running X11 apps on Mojave?

[Christopher Jones]

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


> 
> -- 
> Dr Martin J Carter
> Computer System Administrator
> Astrophysics, University of Oxford



smime.p7s
Description: S/MIME cryptographic signature

Re: Unable to install ports from git source as root : Could not open file

[Christopher Jones]

Hi,
> 
> Any location inside your home directory is not a suitable location for a 
> ports tree, because macOS configures the permissions of your home directory 
> so that other users cannot access it; that includes the macports user that 
> MacPorts uses when you install it as root. Either move your git checkout of 
> the ports tree outside of your home directory, or else change the permissions 
> of your home directory to give other users access to it (understanding the 
> possible security implications of doing that).

Its not necessary to change the permissions of your entire home area to do 
this, which I agree is a bad idea. It is enough to just clone the git ports 
tree in a sub-dir that has read access for all. Just create a directory in your 
home area (say Foo) and then clone the git ports tree into that. By default 
that new sub-dir will have read access

Oberon ~ > mkdir Foo
Oberon ~ > ls -lth | grep Foo
drwxr-xr-x   2 chris  staff64B 14 Jan 19:35 Foo

I have been doing this for years and have no troubles…

Chris




smime.p7s
Description: S/MIME cryptographic signature

Re: Anyone running X11 apps on Mojave?

[Christopher Jones]

The logs below indicate problems with DISPLAY. They also suggest you have some 
residual parts of the non-macports Xquartz installed.

Do you set DISPLAY at all in any of your shell login scripts. If so remove 
this. Try creating a new test user on your system, log in as that and see if it 
works from there. If so it would indicate something in your user environment.

Make sure you have all parts of the other Xquartz removed. In particlar make 
sure all the plist entries under Library are removed.

cheers Chris

> On 19 Jan 2019, at 10:58 am, Pierre Malard  wrote:
> 
> Thanks again,
> 
> There is no crash but here are the only logs I found. I don’t understand why 
> it doesn’t work. The log file « ~/Library/Logs/X11/org.macports.log » is 
> generate when I launch X11.bin directly on a Terminal. When I try to open 
> App, there is nothing neither logs.
> However, I have the same trouble on all my Mac on Mojave. Is it a new « 
> security » mesure from Apple?
> 
> piotr@Rascasse:~/Library/Logs/X11$ cat org.macosforge.xquartz.log
> X11.app: DISPLAY does not look like a launchd set variable, unsetting.
> X11.app: main(): argc=1
>   argv[0] = /Applications/Utilities/XQuartz.app/Contents/MacOS/X11.bin
> Waiting for startup parameters via Mach IPC.
> X11.app: No launchd socket handed off, unsetting DISPLAY
> X11.app: do_start_x11_server(): argc=7
>   argv[0] = /opt/X11/bin/X
>   argv[1] = :0
>   argv[2] = -listen
>   argv[3] = tcp
>   argv[4] = -iglx
>   argv[5] = -auth
>   argv[6] = /Users/piotr/.serverauth.38793
> [1706135.851] Xquartz starting:
> [1706135.851] X.Org X Server 1.18.4
> [1706135.851] Build Date: 20161025
> [1706135.870] x: 0, y: 0, w: 2560, h: 1418
> [1706135.883] (II) GLX: Initialized Core OpenGL GL provider for screen 0
> [1706135.965] X11.app: DarwinProcessFDAdditionQueue_thread: Sleeping to allow 
> xinitrc to catchup.
> [1706135.982] (EE) Error loading keymap /tmp/server-0.xkm
> [1706135.982] (EE) XKB: Failed to load keymap. Loading default keymap instead.
> [1706137.861] noPseudoramiXExtension=0, pseudoramiXNumScreens=1
> [1706160.556] (II) Server terminated successfully (0). Closing log file.
> 
> 
> 
> piotr@Rascasse:~/Library/Logs/X11$ cat org.macports.log
> X11.app: DISPLAY 
> ("/private/tmp/com.apple.launchd.SKs4xIJJVq/org.macosforge.xquartz:0") does 
> not match our id ("org.macports"), unsetting.
> X11.app: main(): argc=2
>   argv[0] = /Applications/MacPorts/X11.app/Contents/MacOS/X11.bin
>   argv[1] = -psn_0_340051
> Waiting for startup parameters via Mach IPC.
> X11.app: No launchd socket handed off, unsetting DISPLAY
> X11.app: do_start_x11_server(): argc=7
>   argv[0] = /opt/local/bin/Xquartz
>   argv[1] = :0
>   argv[2] = -nolisten
>   argv[3] = tcp
>   argv[4] = -iglx
>   argv[5] = -auth
>   argv[6] = /Users/piotr/.serverauth.1026
> [   227.231] Xquartz starting:
> [   227.231] X.Org X Server 1.18.4
> [   227.231] Build Date: 20180831
> [   227.238] x: 0, y: 0, w: 2560, h: 1418
> [   227.303] (II) GLX: Initialized Core OpenGL GL provider for screen 0
> [   229.063] X11.app: DarwinProcessFDAdditionQueue_thread: Sleeping to allow 
> xinitrc to catchup.
> [   229.087] (EE) Error loading keymap /tmp/server-0.xkm
> [   229.087] (EE) XKB: Failed to load keymap. Loading default keymap instead.
> [   229.872] noPseudoramiXExtension=0, pseudoramiXNumScreens=1
> [ 25122.470] x: 0, y: 0, w: 2560, h: 1418
> [ 25122.522] noPseudoramiXExtension=0, pseudoramiXNumScreens=1
> [ 25122.522] noPseudoramiXExtension=0, pseudoramiXNumScreens=1
> [ 26144.274] x: 0, y: 0, w: 2560, h: 1418
> [ 26144.278] noPseudoramiXExtension=0, pseudoramiXNumScreens=1
> [ 31657.125] x: 0, y: 0, w: 2560, h: 1418
> [ 31657.128] noPseudoramiXExtension=0, pseudoramiXNumScreens=1
> [ 63133.955] x: 0, y: 0, w: 2560, h: 1418
> [ 63133.960] noPseudoramiXExtension=0, pseudoramiXNumScreens=1
> [ 70910.981] x: 0, y: 0, w: 2560, h: 1418
> [ 70910.985] noPseudoramiXExtension=0, pseudoramiXNumScreens=1
> [ 83867.215] x: 0, y: 0, w: 2560, h: 1418
> [ 83867.229] noPseudoramiXExtension=0, pseudoramiXNumScreens=1
> [110886.434] x: 0, y: 0, w: 2560, h: 1418
> [110886.438] noPseudoramiXExtension=0, pseudoramiXNumScreens=1
> [153571.180] x: 0, y: 0, w: 2560, h: 1418
> [153571.188] noPseudoramiXExtension=0, pseudoramiXNumScreens=1
> [162162.765] x: 0, y: 0, w: 2560, h: 1418
> [162162.769] noPseudoramiXExtension=0, pseudoramiXNumScreens=1
> [197919.300] x: 0, y: 0, w: 2560, h: 1418
> [197919.305] noPseudoramiXExtension=0, pseudoramiXNumScreens=1
> [198637.899] x: 0, y: 0, w: 2560, h: 1418
> [198637.907] noPseudoramiXExtension=0, pseudoramiXNumScreens=1
> [242705.063] x: 0, y: 0, w: 2560, h: 1418
> [242705.068] noPseudoramiXExtension=0, pseudoramiXNumScreens=1
> [250616.473] x: 0, y: 0, w: 2560, h: 1418
> [250616.478] noPseudoramiXExtension=0, pseudoramiXNumScreens=1
> [257996.670] x: 0, y: 0, w: 2560, h: 1418
> [257996.699] noPseudoramiXExtension=0, pseudoramiXNumScreens=1
>

Re: Macports Installation Error

[Christopher Jones]

Hi,

Have you tried restarting Terminal, to get a clean new bash prompt ?

If it still does not work what does

> echo $PATH

> ls /opt/local/ /opt/local/bin

give ?

Chris

> On 2 Mar 2019, at 11:54 pm, Ryan Grow  wrote:
> 
> I installed macports today and did not preload xcode before installing. 
> Before testing any commands in the terminal, I installed xcode. But then when 
> I tried the $ port version command in the terminal, and received 'bash: $: 
> command not found' as a response. I added "export 
> PATH=/opt/local/bin:/opt/local/sbin:$PATH" and it did not change anything.
> 
> I tried uninstalling - but terminal does not appear to recognize any 'port' 
> commands. Thoughts?
> 
> Ryan G



smime.p7s
Description: S/MIME cryptographic signature

Re: XTerm scrolling in xorg-server @1.20.4_0

[Christopher Jones]

Hi,

I see no problems with remote terms, forwarding them through an ssh tunnel 
works fine and I see no evidence of any slowdowns or schilling issues. What 
system version, xterm version etc., is the remote machine running ?

As for local Tcl/Tk, I have no idea, I do not use any of them. You will need 
though to file tickets etc. with more information if you want any chance of any 
of them looking into.

cheers Chris

> On 3 Apr 2019, at 3:29 am, Ken Preslan  wrote:
> 
> The new xterm does indeed make xterms running natively on my Mac run
> faster than they were yesterday.  However, it does not help the
> performance regression for remote xterms running over X11/ssh forwarding.
> Those are still majorly slower than they were last week.  Local and remote
> Tcl/Tk apps are slower too.  Interestingly, scrolling in the "emacs +x11"
> port is unaffected and seems just as fast as it was.
> 
> Thanks for looking into this.
> 
> 
> On Tue, Apr 02, 2019 at 04:25:38PM +0100, Chris Jones wrote:
>> Hi,
>> 
>> I've just pushed an update to xterm enabling the double buffer option in its
>> configuration step. Could those affected please update to 344_1 and report
>> back how that goes.
>> 
>> cheers Chris
>> 
>> On 02/04/2019 3:29 pm, Ken Cunningham wrote:
>>> looks like the double buffering is not enabled or functioning and xterm is 
>>> writing directly into the display buffer rather than into the back buffer 
>>> and blitting it.
>>> 
 On Apr 2, 2019, at 04:28, Michael Dickens  wrote:
 
 This issue started with the prior "xorg-server-devel" bump a while back. I 
 just moved to iTerm2 for the interim; -very- impressed with that terminal 
 manager! I still need Xterm for some things though ... sigh ... - MLD
 
 On Mon, Apr 1, 2019, at 11:37 PM, Ken Cunningham wrote:
>> Has anybody else noticed that text scrolling in a xterm is now glacially
>> slow since xorg-server was upgraded to @1.20.4_0 over the weekend?
>> X11 is really painful to use now.
> 
> It certainly is. There is something wrong with the screen redrawing in
> xterm now, it seems.
> 
> Ken
> 
> -- 
> Ken Preslan 
> 



smime.p7s
Description: S/MIME cryptographic signature

Re: XTerm scrolling in xorg-server @1.20.4_0

[Christopher Jones]

Hi,

In order to compare the 1.18.x server version to 1.20.x I have put together a 
new port xorg-server-1.18 than is just a clone of xorg-server prior to the 
recent update. (So far I am not planning on committing this, it is just to 
allow some quick tests, but if there is significant interest it could be 
considered. I would prefer not to though).

So far all I have done is check the initialisation logs for the two versions. 
Attached. There are some differences, but whether these are just changes in the 
printout level, or something significant, I have no idea… 1.20.x does though 
explicitly mention DOUBLE-BUFFER which 1.18 doesn’t, which might mean 
something...

cheers Chris




1.20.4-org.macports.log.bz2
Description: BZip2 compressed data


1.18.4-org.macports.log.bz2
Description: BZip2 compressed data

> On 3 Apr 2019, at 7:47 am, Christopher Jones  wrote:
> 
> Hi,
> 
> I see no problems with remote terms, forwarding them through an ssh tunnel 
> works fine and I see no evidence of any slowdowns or schilling issues. What 
> system version, xterm version etc., is the remote machine running ?
> 
> As for local Tcl/Tk, I have no idea, I do not use any of them. You will need 
> though to file tickets etc. with more information if you want any chance of 
> any of them looking into.
> 
> cheers Chris
> 
>> On 3 Apr 2019, at 3:29 am, Ken Preslan  wrote:
>> 
>> The new xterm does indeed make xterms running natively on my Mac run
>> faster than they were yesterday.  However, it does not help the
>> performance regression for remote xterms running over X11/ssh forwarding.
>> Those are still majorly slower than they were last week.  Local and remote
>> Tcl/Tk apps are slower too.  Interestingly, scrolling in the "emacs +x11"
>> port is unaffected and seems just as fast as it was.
>> 
>> Thanks for looking into this.
>> 
>> 
>> On Tue, Apr 02, 2019 at 04:25:38PM +0100, Chris Jones wrote:
>>> Hi,
>>> 
>>> I've just pushed an update to xterm enabling the double buffer option in its
>>> configuration step. Could those affected please update to 344_1 and report
>>> back how that goes.
>>> 
>>> cheers Chris
>>> 
>>> On 02/04/2019 3:29 pm, Ken Cunningham wrote:
>>>> looks like the double buffering is not enabled or functioning and xterm is 
>>>> writing directly into the display buffer rather than into the back buffer 
>>>> and blitting it.
>>>> 
>>>>> On Apr 2, 2019, at 04:28, Michael Dickens  wrote:
>>>>> 
>>>>> This issue started with the prior "xorg-server-devel" bump a while back. 
>>>>> I just moved to iTerm2 for the interim; -very- impressed with that 
>>>>> terminal manager! I still need Xterm for some things though ... sigh ... 
>>>>> - MLD
>>>>> 
>>>>> On Mon, Apr 1, 2019, at 11:37 PM, Ken Cunningham wrote:
>>>>>>> Has anybody else noticed that text scrolling in a xterm is now glacially
>>>>>>> slow since xorg-server was upgraded to @1.20.4_0 over the weekend?
>>>>>>> X11 is really painful to use now.
>>>>>> 
>>>>>> It certainly is. There is something wrong with the screen redrawing in
>>>>>> xterm now, it seems.
>>>>>> 
>>>>>> Ken
>> 
>> -- 
>> Ken Preslan 
>> 
> 

Re: Wireshark, Qt5 and El Capitan

[Christopher Jones]

Hi,

Just to finish up, as the fix seemed trivial (us the PG to set the deps) I have 
pushed an update doing just this. So update and try again.

Chris

> On 21 Apr 2019, at 5:23 am, Chris Jones  wrote:
> 
> Hi,
> 
> I was curious, so I fired off a build using the buildbots, just to see what 
> would happen in a clean environment.
> 
> https://build.macports.org/builders/ports-10.11_x86_64-builder/builds/84721/steps/install-dependencies/logs/stdio
>  
> 
> 
> And indeed I see the dep on qt5-XYZ there. Interestingly, qt511-base, the 
> version I would expect, is also there.
> 
> So, looking again at 
> 
> https://github.com/macports/macports-ports/blob/master/net/wireshark3/Portfile
>  
> 
> 
> If you look at the qt5 variant, defined at line 63, the issue is actually 
> obvious really. The qt5 portgroup is correctly used, to pick the right qt5 
> build, but then at line 68 there are hardcoded deps on specific ‘qt5’ 
> versions, which undoes the good work of the qt5 PG. This is a bug in the 
> wireshark port, which should be looked into. I suggest you file a trac ticket 
> to ask the maintainer to take a look.
> 
> Chris
> 
> On 21 Apr 2019, at 4:47 am, Chris Jones  > wrote:
> 
>> Hi,
>> 
>> There is a qt5 port group specifically designed to handle picking the 
>> correct qt5 version for a given platform. See
>> 
>> https://github.com/macports/macports-ports/blob/master/_resources/port1.0/group/qt5-1.0.tcl
>>  
>> 
>> 
>> In your case, on osx 10.11 it should be using the qt511 ports, which use 
>> 5.11, rather than the main qt5 ports, which currently install 5.12.
>> 
>> So it is strange that you are trying to install qt5-base, as qt511-base 
>> should be used instead in your case. 
>> 
>> I assume your ports are fully up to date ? 
>> 
>> Please run
>> 
>> > sudo port sync
>> > sudo port upgrade outdated
>> > sudo port clean all
>> 
>> Then try again installing the particular wireshark version you want (there 
>> are numerous) and if it still fails post the complete log file.
>> 
>> Chris
>> 
>> On 20 Apr 2019, at 11:30 pm, Greg Earle > > wrote:
>> 
>>> I've got a Mac mini running El Capitan 10.11.6.  I've held the OS back 
>>> because I have a FireWire audio interface on it and FireWire is deprecated 
>>> in more recent OSes.
>>> 
>>> I am having a problem with my Blu-ray player not recognizing NFS shares on 
>>> the same Mac mini.  I went to install Wireshark to debug the NFS traffic 
>>> but it won't install because the current "qt5-qtbase" port is only for 
>>> Sierra or newer:
>>> 
>>> --
>>> Mac-mini:~ admin$ sudo port install qt5-qtbase
>>> --->  Computing dependencies for qt5-qtbase
>>> --->  Fetching distfiles for qt5-qtbase
>>> Error: qt5-qtbase requires macOS 10.12 or later
>>> Error: Failed to fetch qt5-qtbase: incompatible OS version
>>> Error: See 
>>> /opt/local/var/macports/logs/_private_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_aqua_qt5/qt5-qtbase/main.log
>>>  for details.
>>> Error: Follow https://guide.macports.org/#project.tickets 
>>>  to report a bug.
>>> Error: Processing of port qt5-qtbase failed
>>> --
>>> 
>>> Is there any way to build/install an older Wireshark/Qt5 port combo that 
>>> will still work on El Capitan?
>>> 
>>> My impression of MacPorts has always been that you can only build/install 
>>> whatever port happens to be installed after you last did a "port self 
>>> update".  I can't really risk going to Sierra and have this audio interface 
>>> stop working.  :-/
>>> 
>>>- Greg



smime.p7s
Description: S/MIME cryptographic signature

Re: X11 app - unable to open display ""

[Christopher Jones]

Hi,

I think it is related to the x11 server version, as I saw the same issues with 
the main xorg-server port (1.20.x) but if I switch back to 1.18 gv behaves 
better.

As this isn’t the first time so issues with the 1.20 server have been reported 
since it was made the default version, I have just submitted 

https://github.com/macports/macports-ports/pull/4135 


which adds back a ‘legacy’ xorg-server-1.18 port. I was a little reticent to do 
this, but if if provides a fallback solution to these issues until whatever is 
affecting the 1.20 build can be addressed (I don’t personally currently have a 
clue) then fine.

those affected can just do

> sudo port uninstall xorg-server
> sudo port install xorg-server-1.18

once the above is merged into master.

Chris

> On 22 Apr 2019, at 11:21 am, Ryan Schmidt  wrote:
> 
> 
> 
> On Apr 19, 2019, at 05:01, Christoph Kukulies wrote:
> 
>> Thanks. That did the job. I can now start the „gv“ (ghostview) port. But it 
>> illbehaves.
>> Some problem with the event queue maybe. Looks like lots ov expose events 
>> are generated.
>> Textfield in the left is flickering and is counting through all papersizes 
>> there are. Then the fileselector box
>> is flickering slowly. Hardly to operate.
>> 
>> Well, the application isn’t attractive anyway compared to what one is used 
>> of gsview64/32.
>> Not that the letter is the cream of GUI programs but it is usable and 
>> practical. Not more, not less.
> 
> Hmm, sorry to hear that. I'm not seeing those problems (on High Sierra), but 
> I am using an older version of xorg-server at least:
> 
> $ port installed xorg-server gv
> The following ports are currently installed:
>  gv @3.7.4_0+universal (active)
>  xorg-server @1.18.4_3+universal (active)
> 
> 



smime.p7s
Description: S/MIME cryptographic signature

Re: where did old clang compilers go?

[Christopher Jones]

Hi,

llvm-3.9 has been removed by its maintainer

https://github.com/macports/macports-ports/commit/8470ccfcdae5c31638c4c5bc2b24ee05e4a2a95b#diff-97ff44bf54510d4cdb81b823e6bfe97c
 


clang 8 is marked as the replacement.

If you disagree with this, you need to follow up with the maintainer via trac 
tickets etc.

Chris

> On 21 Jul 2019, at 8:11 am, Riccardo Mottola via macports-users 
>  wrote:
> 
> Hi all!
> 
> 
> I did an upgrade on my 10.6 MacBook ... I am stuck on a few remaining 
> packages, but I did accept "reclaim" since there were many many packages 
> apparently.
> 
> This operation removed clang 3.4, 3.9, 4.0 and 5.0 ! Now... I need those 
> compilers to compile code (currently not in MacPorts, but hopefully soon) 
> like TenFourFox and ArcticFox.
> 
> if I try to reinstall 3.9, I get that the port is obsoleted! I cannot even 
> reactivated it.
> 
> Newer clang compiler, e.g. 8, fail to compile code for Mac 10.6 because of 
> old headers.
> 
> How can I get it back? and, generally, I don't think it was good idea to 
> remove them: MacPorts is very useful to get development tools, not just 
> "end-apps" which might in the meanwhile all be migrated to newer compilers.
> 
> 
> Riccardo
> 



smime.p7s
Description: S/MIME cryptographic signature

Re: To root or not to root?

[Christopher Jones]

> On 12 Aug 2019, at 9:40 pm, Gerben Wierda  wrote:
> 
> As I’m working my way to somewhat knowing what I’m doing, I have a question.
> 
> I always set the timeout on sudo on my systems to 0 seconds. So, for every 
> sudo command I enter, I have to type the password. This is somewhat safer 
> than having a timeout (normally 300sec).

What I do is allow ${prefix}/bin/port to run through sudo without requiring a 
password. you can do this by adding

chris   ALL=(ALL) NOPASSWD: /opt/local/bin/port

this in my opinion has two advantages

1. I never have to type my passport for running port
2. Because of 1., sudo never fully authenticates, so if I was to run another 
command through sudo immediately after port, that command will ask for my 
password.

In my view, the above is more convenient, and also safer against my accidental 
bad usage of sudo.

Chris

> 
> This becomes tedious when there are many sudo commands to perform, so in that 
> case, I often revert to running sudo -s or sudo -i, do my work as root and 
> kill the subshell. This has risks too (e.g. doing a wrong rm command, but I’m 
> pretty paranoiac about stuff like rm)
> 
> For my first steps with macports, I’ve run everything as root that way, 
> because I expected there would be changes in /Library/LaunchDaemons etc and I 
> did not want toe be typing my password all the time.
> 
> But I’m wondering if I should move back to running everything as ordinary 
> user.
> 
> Are there disadvantages to running to port commands as root?
> 
> If I want to revert, what should I chown to that user? How should ownership 
> in /opt be?
> 
> Gerben Wierda
> Chess and the Art of Enterprise Architecture 
> Mastering ArchiMate 
> Architecture for Real Enterprises 
>  at 
> InfoWorld
> On Slippery Ice  at EAPJ
> 



smime.p7s
Description: S/MIME cryptographic signature

Re: What am I forgetting?

[Christopher Jones]

> On 13 Aug 2019, at 9:25 am, Gerben Wierda  wrote:
> 
> Thanks Mojca,
> 
>> On 13 Aug 2019, at 03:22, Mojca Miklavec > > wrote:
>> 
>> On Tue, 13 Aug 2019 at 01:24, Gerben Wierda > > wrote:
>>> 
>>> I have my own cloud git directory tree
>>> I cd to $thattree/net/unbound
>>> I edit the Portfile (startupitem), set revision to 1 (there was no revision)
>>> I run sudo port install unbound
>>> It is not built and installed as nothing has changed (but there has)
>>> 
>>> What am I forgetting?
>> 
>> Did you add your local git checkout to configuration as your local
>> repository with higher preference?
>>https://guide.macports.org/chunked/development.local-repositories.html 
>> 
>> Check this with
>>port dir unbound
> 
> I did edit sources.conf. It contains:
> 
> file:///Users/sysbh/MacPortsDev 
> rsync://rsync.macports.org/macports/release/tarballs/ports.tar 
>  [default]
> 
> But whatever is in there, port dir unbound gets met the standard repository.
> 
> Albus:nsd sysbh$ port dir unbound
> /opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/ports/net/unbound
>  
> 
> So, als with
> 
> file:// 
> /Users/sysbh/MacPortsDev/macports-port
>  
> rsync://rsync.macports.org/macports/release/tarballs/ports.tar 
>  [default]


just comment out the old tarball default, and make you area the default…

Chris

> 
> 
>> If not, "sudo port install" or "sudo port upgrade" (without port name)
>> or "sudo port install subport=unbound" should take the port from the
>> current dir, 
> 
> I edited the Portfile /Users/sysbh/MacPortsDev/macports-port/net/nsd/Portfile 
> again, set the revision to 6 and ran ’sudo port install’ while in directory 
> /Users/sysbh/MacPortsDev/macports-port/net/nsd and this worked.
> 
>> but "sudo port install unbound" will probably take the
>> one that's configured globally and returned by "port dir unbound”.
> 
> That seems to be the case.
> 
> Albus:nsd sysbh$ pwd
> /Users/sysbh/MacPortsDev/macports-ports/net/nsd
> Albus:nsd sysbh$ port dir
> /Users/sysbh/MacPortsDev/macports-ports/net/nsd
> Albus:nsd sysbh$ port dir nsd
> /opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/ports/net/nsd
>  
> 
> So, if you give the name of the port, it will use the main repository. You 
> need to explicitly not give the name to get the local Portfile. This is 
> somewhat surprising behaviour (for me at last) that I have to leave out the 
> name of the thing to get the thing.
> 
> Now, the only thing I have to do is to find a way to get my local revision 
> back to 1, before I submit the patch. I have installed
> 
> Albus:nsd sysbh$ port installed
> The following ports are currently installed:
>   expat @2.2.7_0 (active)
>   flex @2.6.4_0 (active)
>   gettext @0.19.8.1_2 (active)
>   libevent @2.1.10_0 (active)
>   libiconv @1.16_0 (active)
>   m4 @1.4.18_2 (active)
>   ncurses @6.1_0 (active)
>   nsd @4.1.22_0
>   nsd @4.1.22_1
>   nsd @4.2.1_0
>   nsd @4.2.1_1
>   nsd @4.2.1_2
>   nsd @4.2.1_3
>   nsd @4.2.1_5
>   nsd @4.2.1_6 (active)
>   openssl @1.0.2s_0 (active)
>   unbound @1.9.2_0
>   unbound @1.9.2_1 (active)
>   zlib @1.2.11_0 (active)
> 
> If my update gets accepted, that would mean it would be revision 6. Is that 
> bad? The revisions all come from my local tinkering because I know not how to 
> force a build without changing revision.
> 
> I also want to clean up my installed versions. So nsd becomes
> 
>   nsd @4.2.1_0
>   nsd @4.2.1_1 (active)
> 
> with that last one actually the current revision 6. How do I do that?
> 
> G
> 
> 
>> 
>> Mojca



smime.p7s
Description: S/MIME cryptographic signature

Re: To root or not to root?

[Christopher Jones]

> On 13 Aug 2019, at 9:03 am, Christopher Jones  
> wrote:
> 
> 
> 
>> On 12 Aug 2019, at 9:40 pm, Gerben Wierda > <mailto:gerben.wie...@rna.nl>> wrote:
>> 
>> As I’m working my way to somewhat knowing what I’m doing, I have a question.
>> 
>> I always set the timeout on sudo on my systems to 0 seconds. So, for every 
>> sudo command I enter, I have to type the password. This is somewhat safer 
>> than having a timeout (normally 300sec).
> 
> What I do is allow ${prefix}/bin/port to run through sudo without requiring a 
> password. you can do this by adding
> 
> chris   ALL=(ALL) NOPASSWD: /opt/local/bin/port

should have added here the above is added via ‘visudo'

Chris

> 
> this in my opinion has two advantages
> 
> 1. I never have to type my passport for running port
> 2. Because of 1., sudo never fully authenticates, so if I was to run another 
> command through sudo immediately after port, that command will ask for my 
> password.
> 
> In my view, the above is more convenient, and also safer against my 
> accidental bad usage of sudo.
> 
> Chris
> 
>> 
>> This becomes tedious when there are many sudo commands to perform, so in 
>> that case, I often revert to running sudo -s or sudo -i, do my work as root 
>> and kill the subshell. This has risks too (e.g. doing a wrong rm command, 
>> but I’m pretty paranoiac about stuff like rm)
>> 
>> For my first steps with macports, I’ve run everything as root that way, 
>> because I expected there would be changes in /Library/LaunchDaemons etc and 
>> I did not want toe be typing my password all the time.
>> 
>> But I’m wondering if I should move back to running everything as ordinary 
>> user.
>> 
>> Are there disadvantages to running to port commands as root?
>> 
>> If I want to revert, what should I chown to that user? How should ownership 
>> in /opt be?
>> 
>> Gerben Wierda
>> Chess and the Art of Enterprise Architecture <http://enterprisechess.com/>
>> Mastering ArchiMate <http://masteringarchimate.com/>
>> Architecture for Real Enterprises 
>> <https://www.infoworld.com/blog/architecture-for-real-enterprises/> at 
>> InfoWorld
>> On Slippery Ice <https://eapj.org/on-slippery-ice/> at EAPJ
>> 
> 



smime.p7s
Description: S/MIME cryptographic signature

Re: ledger fails to build after boost upgrade to 1.70.0

[Christopher Jones]

Hi,

Looks like ledger does not yet support the updated boost.

please look for an open ticket at

https://trac.macports.org/wiki/Tickets 

and if there is none for this issue, open one.

cheers Chris

> On 14 Aug 2019, at 6:40 am, Kastus Shchuka  wrote:
> 
> Hi,
> 
> After doing “port upgrade outdated” boost was upgraded to 1.70.0_0, and it 
> triggered rebuild of ledger @3.1.1_4.
> 
> The error in 
> /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_finance_ledger/ledger/main.log
>  is this:
> 
> :info:configure -- Found PythonInterp: /opt/local/bin/python2.7 (found 
> version "2.7.16") 
> :info:configure -- Found PythonLibs: /opt/local/lib/libpython2.7.dylib (found 
> version "2.7.10") 
> :info:configure CMake Error at 
> /opt/local/share/cmake-3.15/Modules/FindPackageHandleStandardArgs.cmake:137 
> (message):
> :info:configure   Could NOT find Boost (missing: python) (found suitable 
> version "1.70.0",
> :info:configure   minimum required is "1.49.0”)
> 
> This is the version of boost that I have after upgrade:
> 
>  boost @1.70.0_0+no_single+no_static+python27 (active)
> 
> Am I missing something obvious here?
> 
> Thanks,
> 
> Kastus
> 
> 



smime.p7s
Description: S/MIME cryptographic signature

Re: ledger fails to build after boost upgrade to 1.70.0

[Christopher Jones]

Actually, fix was trivial.

https://github.com/macports/macports-ports/commit/087140b0f4e960a304d3d56708aa77989b441b16
 
<https://github.com/macports/macports-ports/commit/087140b0f4e960a304d3d56708aa77989b441b16>

> On 14 Aug 2019, at 11:02 am, Christopher Jones  
> wrote:
> 
> Hi,
> 
> Looks like ledger does not yet support the updated boost.
> 
> please look for an open ticket at
> 
> https://trac.macports.org/wiki/Tickets 
> <https://trac.macports.org/wiki/Tickets>
> 
> and if there is none for this issue, open one.
> 
> cheers Chris
> 
>> On 14 Aug 2019, at 6:40 am, Kastus Shchuka > <mailto:macpo...@tprfct.net>> wrote:
>> 
>> Hi,
>> 
>> After doing “port upgrade outdated” boost was upgraded to 1.70.0_0, and it 
>> triggered rebuild of ledger @3.1.1_4.
>> 
>> The error in 
>> /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_finance_ledger/ledger/main.log
>>  is this:
>> 
>> :info:configure -- Found PythonInterp: /opt/local/bin/python2.7 (found 
>> version "2.7.16") 
>> :info:configure -- Found PythonLibs: /opt/local/lib/libpython2.7.dylib 
>> (found version "2.7.10") 
>> :info:configure CMake Error at 
>> /opt/local/share/cmake-3.15/Modules/FindPackageHandleStandardArgs.cmake:137 
>> (message):
>> :info:configure   Could NOT find Boost (missing: python) (found suitable 
>> version "1.70.0",
>> :info:configure   minimum required is "1.49.0”)
>> 
>> This is the version of boost that I have after upgrade:
>> 
>>  boost @1.70.0_0+no_single+no_static+python27 (active)
>> 
>> Am I missing something obvious here?
>> 
>> Thanks,
>> 
>> Kastus
>> 
>> 
> 



smime.p7s
Description: S/MIME cryptographic signature

Re: [mysql8] build error on 10.6 Snow Leopard i386

[Christopher Jones]

Hi,

You missed the important errors in that log

/macports/var/macports/build/_macports_var_macports_sources_rsync.macports.org_release_tarballs_ports_databases_mysql8/mysql8/work/build/archive_output_directory/libclientlib.a(libmysql.cc.o)
 malformed object (unknown load command 2)
:info:build /usr/bin/libtool: object: 

/usr/bin/libtool will be the system one, which on your ancient system will be 
very very out of date.

The cctools port should be providing a more up to date alternative. Do you have 
cctools installed ? If so, what variants etc. ? Try installing it with the 
default variants, if you don’t already have it, and then try again.

Chris

> On 16 Aug 2019, at 5:22 pm, Bjarne D Mathiesen  
> wrote:
> 
> :info:build [ 43%] Built target perfschema
> :info:build make[1]: Leaving directory
> `/macports/var/macports/build/_macports_var_macports_sources_rsync.macports.org_release_tarballs_ports_databases_mysql8/mysql8/work/build'
> :info:build make: *** [all] Error 2
> :info:build make: Leaving directory
> `/macports/var/macports/build/_macports_var_macports_sources_rsync.macports.org_release_tarballs_ports_databases_mysql8/mysql8/work/build'
> :info:build Command failed:  cd
> "/macports/var/macports/build/_macports_var_macports_sources_rsync.macports.org_release_tarballs_ports_databases_mysql8/mysql8/work/build"
> && /usr/bin/make -j2 -w all VERBOSE=ON
> :info:build Exit code: 2
> :error:build Failed to build mysql8: command execution failed
> :debug:build Error code: CHILDSTATUS 13266 2
> :debug:build Backtrace: command execution failed
> :debug:build while executing
> :debug:build "system {*}$notty {*}$nice $fullcmdstring"
> :debug:build invoked from within
> :debug:build "command_exec build"
> :debug:build (procedure "portbuild::build_main" line 8)
> :debug:build invoked from within
> :debug:build "$procedure $targetname"
> 
> see : https://macports.mathiesen.info/10.6-i386/mysql8-main.log
> 
> bug ? can I fix it myself ?
> 
> -- 
> Bjarne D Mathiesen
> Korsør ; Danmark ; Europa
> --
> denne besked er skrevet i et totalt M$-frit miljø
> MacOS X 10.11 El Capitan ; 2.8GHz Intel Core i7 ; 16GB 1067MHz DDR3



smime.p7s
Description: S/MIME cryptographic signature

Re: libuv fails to build on 10.8.5

[Christopher Jones]

Hi,

I have commented on both tickets. They are in essence the same problem, the out 
of date SSL support in macOS10.8 that is causing you https fetch issues.

cheers Chris

> On 17 Aug 2019, at 11:06 am, Dmitri Zaitsev  wrote:
> 
> Please see 
> https://trac.macports.org/ticket/58847 
> 
> https://trac.macports.org/ticket/58848 
> 
> 
> I have managed to get around the first one by manually downloading the file, 
> but have no idea what to do about the second, which might have the same cause 
> (failed downloads).
> 
> Any hint is appreciated.
> 
> 
> On Saturday, August 17, 2019, Ryan Schmidt  > wrote:
> 
> 
> On Aug 16, 2019, at 02:14, Dmitri Zaitsev wrote:
> 
> > Unfortunately it got worse, I can't install any port at all now. :(
> 
> Sorry to hear that... can you provide any more details?
> 
> 
> 
> -- 
> Dmitri Zaitsev
> School of Mathematics
> Trinity College Dublin
> 
> WWW:  http://www.maths.tcd.ie/~zaitsev/ 
> 



smime.p7s
Description: S/MIME cryptographic signature

Re: libuv fails to build on 10.8.5

[Christopher Jones]

Hi,

First, please keep the discussion on the mailing list.

just installing the up to date ports for openssl etc. is not enough, as by 
default the fetches macports performs will not use these. 

I believe there are ways to bootstrap macports to do this, but as I have no 
need of it (I don’t run such old OSes myself, apart from in VMs for test 
purposes) I cannot comment on how that is done.

( Updating your OS is really the best option, if your hardware supports a new 
OSes. 10.8 hs not received any security updates for quite a while now…. )

cheers Chris 

> On 17 Aug 2019, at 11:48 am, Dmitri Zaitsev  wrote:
> 
> Thank you!
> 
> I am trying to understand the cause and it seems my both openssl and ssh are 
> recent.
> Any other idea where to look for (other than OS upgrading :-)?
> 
> https://trac.macports.org/ticket/58848#comment:4 
> <https://trac.macports.org/ticket/58848#comment:4>
> 
> 
> On Saturday, August 17, 2019, Christopher Jones  <mailto:jon...@hep.phy.cam.ac.uk>> wrote:
> Hi,
> 
> I have commented on both tickets. They are in essence the same problem, the 
> out of date SSL support in macOS10.8 that is causing you https fetch issues.
> 
> cheers Chris
> 
>> On 17 Aug 2019, at 11:06 am, Dmitri Zaitsev > <mailto:zait...@maths.tcd.ie>> wrote:
>> 
>> Please see 
>> https://trac.macports.org/ticket/58847 
>> <https://trac.macports.org/ticket/58847>
>> https://trac.macports.org/ticket/58848 
>> <https://trac.macports.org/ticket/58848>
>> 
>> I have managed to get around the first one by manually downloading the file, 
>> but have no idea what to do about the second, which might have the same 
>> cause (failed downloads).
>> 
>> Any hint is appreciated.
>> 
>> 
>> On Saturday, August 17, 2019, Ryan Schmidt > <mailto:ryandes...@macports.org>> wrote:
>> 
>> 
>> On Aug 16, 2019, at 02:14, Dmitri Zaitsev wrote:
>> 
>> > Unfortunately it got worse, I can't install any port at all now. :(
>> 
>> Sorry to hear that... can you provide any more details?
>> 
>> 
>> 
>> -- 
>> Dmitri Zaitsev
>> School of Mathematics
>> Trinity College Dublin
>> 
>> WWW:  http://www.maths.tcd.ie/~zaitsev/ <http://www.maths.tcd.ie/~zaitsev/>
>> 
> 
> 
> 
> -- 
> Dmitri Zaitsev
> School of Mathematics
> Trinity College Dublin
> 
> WWW:  http://www.maths.tcd.ie/~zaitsev/ <http://www.maths.tcd.ie/~zaitsev/>
> 



smime.p7s
Description: S/MIME cryptographic signature

Re: libuv fails to build on 10.8.5

[Christopher Jones]

Hi,

> On 17 Aug 2019, at 12:09 pm, Dmitri Zaitsev  wrote:
> 
> Hi Chris,
> 
> I understand that MacPorts are supporting old versions going back to Tiger 
> and some of the stats confirm users' downloads. I do appreciate the advice to 
> upgrade but there can be many personal reasons why people prefer to stay with 
> their older systems. It is however not at all obvious that a plain upgrade to 
> some later supported OS would actually fix that problem, so having an 
> alternative would help all these users, and as you mention it is entirely 
> within the MacPorts system that some older `ssl` is used internally for some 
> reason, instead of the more recent available one that could have been used 
> instead, in which case the problem might have not existed.

what OS you run is of course your choice. I gave my advice and you are free to 
take or leave it.

In this case though, upgrading your OS would absolutely 100% fix your SSL 
problems though, as these are completely specific to running out-of-date 
systems.

Chris

> 
> I do appreciate your time and fully understand that this is not your concern 
> but would be still thankful if anyone could advice on how to configure 
> MacPorts to use the recent ssl.
> 
> Cheers,
> Dmitri.
> 
> 
> 
> 
> On Saturday, August 17, 2019, Christopher Jones  <mailto:jon...@hep.phy.cam.ac.uk>> wrote:
> Hi,
> 
> First, please keep the discussion on the mailing list.
> 
> just installing the up to date ports for openssl etc. is not enough, as by 
> default the fetches macports performs will not use these. 
> 
> I believe there are ways to bootstrap macports to do this, but as I have no 
> need of it (I don’t run such old OSes myself, apart from in VMs for test 
> purposes) I cannot comment on how that is done.
> 
> ( Updating your OS is really the best option, if your hardware supports a new 
> OSes. 10.8 hs not received any security updates for quite a while now…. )
> 
> cheers Chris 
> 
>> On 17 Aug 2019, at 11:48 am, Dmitri Zaitsev > <mailto:zait...@maths.tcd.ie>> wrote:
>> 
>> Thank you!
>> 
>> I am trying to understand the cause and it seems my both openssl and ssh are 
>> recent.
>> Any other idea where to look for (other than OS upgrading :-)?
>> 
>> https://trac.macports.org/ticket/58848#comment:4 
>> <https://trac.macports.org/ticket/58848#comment:4>
>> 
>> 
>> On Saturday, August 17, 2019, Christopher Jones > <mailto:jon...@hep.phy.cam.ac.uk>> wrote:
>> Hi,
>> 
>> I have commented on both tickets. They are in essence the same problem, the 
>> out of date SSL support in macOS10.8 that is causing you https fetch issues.
>> 
>> cheers Chris
>> 
>>> On 17 Aug 2019, at 11:06 am, Dmitri Zaitsev >> <mailto:zait...@maths.tcd.ie>> wrote:
>>> 
>>> Please see 
>>> https://trac.macports.org/ticket/58847 
>>> <https://trac.macports.org/ticket/58847>
>>> https://trac.macports.org/ticket/58848 
>>> <https://trac.macports.org/ticket/58848>
>>> 
>>> I have managed to get around the first one by manually downloading the 
>>> file, but have no idea what to do about the second, which might have the 
>>> same cause (failed downloads).
>>> 
>>> Any hint is appreciated.
>>> 
>>> 
>>> On Saturday, August 17, 2019, Ryan Schmidt >> <mailto:ryandes...@macports.org>> wrote:
>>> 
>>> 
>>> On Aug 16, 2019, at 02:14, Dmitri Zaitsev wrote:
>>> 
>>> > Unfortunately it got worse, I can't install any port at all now. :(
>>> 
>>> Sorry to hear that... can you provide any more details?
>>> 
>>> 
>>> 
>>> -- 
>>> Dmitri Zaitsev
>>> School of Mathematics
>>> Trinity College Dublin
>>> 
>>> WWW:  http://www.maths.tcd.ie/~zaitsev/ <http://www.maths.tcd.ie/~zaitsev/>
>>> 
>> 
>> 
>> 
>> -- 
>> Dmitri Zaitsev
>> School of Mathematics
>> Trinity College Dublin
>> 
>> WWW:  http://www.maths.tcd.ie/~zaitsev/ <http://www.maths.tcd.ie/~zaitsev/>
>> 
> 
> 
> 
> -- 
> Dmitri Zaitsev
> School of Mathematics
> Trinity College Dublin
> 
> WWW:  http://www.maths.tcd.ie/~zaitsev/ <http://www.maths.tcd.ie/~zaitsev/>
> 



smime.p7s
Description: S/MIME cryptographic signature

Re: libuv fails to build on 10.8.5

[Christopher Jones]

> On 17 Aug 2019, at 12:16 pm, Dmitri Zaitsev  wrote:
> 
> On Saturday, August 17, 2019, Christopher Jones  <mailto:jon...@hep.phy.cam.ac.uk>> wrote:
> Hi,
> 
>> On 17 Aug 2019, at 12:09 pm, Dmitri Zaitsev > <mailto:zait...@maths.tcd.ie>> wrote:
>> 
>> Hi Chris,
>> 
>> I understand that MacPorts are supporting old versions going back to Tiger 
>> and some of the stats confirm users' downloads. I do appreciate the advice 
>> to upgrade but there can be many personal reasons why people prefer to stay 
>> with their older systems. It is however not at all obvious that a plain 
>> upgrade to some later supported OS would actually fix that problem, so 
>> having an alternative would help all these users, and as you mention it is 
>> entirely within the MacPorts system that some older `ssl` is used internally 
>> for some reason, instead of the more recent available one that could have 
>> been used instead, in which case the problem might have not existed.
> 
> what OS you run is of course your choice. I gave my advice and you are free 
> to take or leave it.
> 
> In this case though, upgrading your OS would absolutely 100% fix your SSL 
> problems though, as these are completely specific to running out-of-date 
> systems.
> 
> 
> Are you referring to any specific OS version here?

I cannot give you OS versions, but the core issue is a lot of sites have turned 
off support for old insecure SSL/TLS versions, and macOS10.8 does not have 
support for the newer ones they now require.

> 
>  
> 
> Chris
> 
>> 
>> I do appreciate your time and fully understand that this is not your concern 
>> but would be still thankful if anyone could advice on how to configure 
>> MacPorts to use the recent ssl.
>> 
>> Cheers,
>> Dmitri.
>> 
>> 
>> 
>> 
>> On Saturday, August 17, 2019, Christopher Jones > <mailto:jon...@hep.phy.cam.ac.uk>> wrote:
>> Hi,
>> 
>> First, please keep the discussion on the mailing list.
>> 
>> just installing the up to date ports for openssl etc. is not enough, as by 
>> default the fetches macports performs will not use these. 
>> 
>> I believe there are ways to bootstrap macports to do this, but as I have no 
>> need of it (I don’t run such old OSes myself, apart from in VMs for test 
>> purposes) I cannot comment on how that is done.
>> 
>> ( Updating your OS is really the best option, if your hardware supports a 
>> new OSes. 10.8 hs not received any security updates for quite a while now…. )
>> 
>> cheers Chris 
>> 
>>> On 17 Aug 2019, at 11:48 am, Dmitri Zaitsev >> <mailto:zait...@maths.tcd.ie>> wrote:
>>> 
>>> Thank you!
>>> 
>>> I am trying to understand the cause and it seems my both openssl and ssh 
>>> are recent.
>>> Any other idea where to look for (other than OS upgrading :-)?
>>> 
>>> https://trac.macports.org/ticket/58848#comment:4 
>>> <https://trac.macports.org/ticket/58848#comment:4>
>>> 
>>> 
>>> On Saturday, August 17, 2019, Christopher Jones >> <mailto:jon...@hep.phy.cam.ac.uk>> wrote:
>>> Hi,
>>> 
>>> I have commented on both tickets. They are in essence the same problem, the 
>>> out of date SSL support in macOS10.8 that is causing you https fetch issues.
>>> 
>>> cheers Chris
>>> 
>>>> On 17 Aug 2019, at 11:06 am, Dmitri Zaitsev >>> <mailto:zait...@maths.tcd.ie>> wrote:
>>>> 
>>>> Please see 
>>>> https://trac.macports.org/ticket/58847 
>>>> <https://trac.macports.org/ticket/58847>
>>>> https://trac.macports.org/ticket/58848 
>>>> <https://trac.macports.org/ticket/58848>
>>>> 
>>>> I have managed to get around the first one by manually downloading the 
>>>> file, but have no idea what to do about the second, which might have the 
>>>> same cause (failed downloads).
>>>> 
>>>> Any hint is appreciated.
>>>> 
>>>> 
>>>> On Saturday, August 17, 2019, Ryan Schmidt >>> <mailto:ryandes...@macports.org>> wrote:
>>>> 
>>>> 
>>>> On Aug 16, 2019, at 02:14, Dmitri Zaitsev wrote:
>>>> 
>>>> > Unfortunately it got worse, I can't install any port at all now. :(
>>>> 
>>>> Sorry to hear that... can you provide any more details?
>>>> 
>>>> 
>>>> 
>>>> -- 
>>>> Dmitri Zaitsev
>>>> School of Mathematics
>>>> Trinity College Dublin
>>>> 
>>>> WWW:  http://www.maths.tcd.ie/~zaitsev/ <http://www.maths.tcd.ie/~zaitsev/>
>>>> 
>>> 
>>> 
>>> 
>>> -- 
>>> Dmitri Zaitsev
>>> School of Mathematics
>>> Trinity College Dublin
>>> 
>>> WWW:  http://www.maths.tcd.ie/~zaitsev/ <http://www.maths.tcd.ie/~zaitsev/>
>>> 
>> 
>> 
>> 
>> -- 
>> Dmitri Zaitsev
>> School of Mathematics
>> Trinity College Dublin
>> 
>> WWW:  http://www.maths.tcd.ie/~zaitsev/ <http://www.maths.tcd.ie/~zaitsev/>
>> 
> 
> 
> 
> -- 
> Dmitri Zaitsev
> School of Mathematics
> Trinity College Dublin
> 
> WWW:  http://www.maths.tcd.ie/~zaitsev/ <http://www.maths.tcd.ie/~zaitsev/>


smime.p7s
Description: S/MIME cryptographic signature

Re: libuv fails to build on 10.8.5

[Christopher Jones]

Hi,

sites do not care specifically about the OS version, but the SSL/TLS levels 
that are supported. When a connection is opened the server and client first 
negotiate what to use, based on what the client supports and what the server 
requires. If the client cannot provide what the server requires, the connection 
is denied.

If you want more information on this, you need to do your own research. A web 
search for SSL/TLS should be a good start.

Chris

> On 17 Aug 2019, at 12:30 pm, Dmitri Zaitsev  wrote:
> 
> It would be critical for me to know which versions are supported and 
> compatible with my old hardware to run without issues.
> Otherwise I might end up dealing with problems much worse than this one.
> 
> Are you saying these site explicitly deny connections based on the OS version 
> number, regardless of the actual client I am using?
> I find this puzzling as I only need the read access via my client that should 
> not need to pass any details such as OS version to the site.
> 
> Is there anywhere I could find some information about this issue?
> 
> Thank you,
> Dmitri.
>  
> I cannot give you OS versions, but the core issue is a lot of sites have 
> turned off support for old insecure SSL/TLS versions, and macOS10.8 does not 
> have support for the newer ones they now require.
> 
>> 
>>  
>> 
>> Chris
>> 
>>> 
>>> I do appreciate your time and fully understand that this is not your 
>>> concern but would be still thankful if anyone could advice on how to 
>>> configure MacPorts to use the recent ssl.
>>> 
>>> Cheers,
>>> Dmitri.
>>> 
>>> 
>>> 
>>> 
>>> On Saturday, August 17, 2019, Christopher Jones >> <mailto:jon...@hep.phy.cam.ac.uk>> wrote:
>>> Hi,
>>> 
>>> First, please keep the discussion on the mailing list.
>>> 
>>> just installing the up to date ports for openssl etc. is not enough, as by 
>>> default the fetches macports performs will not use these. 
>>> 
>>> I believe there are ways to bootstrap macports to do this, but as I have no 
>>> need of it (I don’t run such old OSes myself, apart from in VMs for test 
>>> purposes) I cannot comment on how that is done.
>>> 
>>> ( Updating your OS is really the best option, if your hardware supports a 
>>> new OSes. 10.8 hs not received any security updates for quite a while now…. 
>>> )
>>> 
>>> cheers Chris 
>>> 
>>>> On 17 Aug 2019, at 11:48 am, Dmitri Zaitsev >>> <mailto:zait...@maths.tcd.ie>> wrote:
>>>> 
>>>> Thank you!
>>>> 
>>>> I am trying to understand the cause and it seems my both openssl and ssh 
>>>> are recent.
>>>> Any other idea where to look for (other than OS upgrading :-)?
>>>> 
>>>> https://trac.macports.org/ticket/58848#comment:4 
>>>> <https://trac.macports.org/ticket/58848#comment:4>
>>>> 
>>>> 
>>>> On Saturday, August 17, 2019, Christopher Jones >>> <mailto:jon...@hep.phy.cam.ac.uk>> wrote:
>>>> Hi,
>>>> 
>>>> I have commented on both tickets. They are in essence the same problem, 
>>>> the out of date SSL support in macOS10.8 that is causing you https fetch 
>>>> issues.
>>>> 
>>>> cheers Chris
>>>> 
>>>>> On 17 Aug 2019, at 11:06 am, Dmitri Zaitsev >>>> <mailto:zait...@maths.tcd.ie>> wrote:
>>>>> 
>>>>> Please see 
>>>>> https://trac.macports.org/ticket/58847 
>>>>> <https://trac.macports.org/ticket/58847>
>>>>> https://trac.macports.org/ticket/58848 
>>>>> <https://trac.macports.org/ticket/58848>
>>>>> 
>>>>> I have managed to get around the first one by manually downloading the 
>>>>> file, but have no idea what to do about the second, which might have the 
>>>>> same cause (failed downloads).
>>>>> 
>>>>> Any hint is appreciated.
>>>>> 
>>>>> 
>>>>> On Saturday, August 17, 2019, Ryan Schmidt >>>> <mailto:ryandes...@macports.org>> wrote:
>>>>> 
>>>>> 
>>>>> On Aug 16, 2019, at 02:14, Dmitri Zaitsev wrote:
>>>>> 
>>>>> > Unfortunately it got worse, I can't install any port at all now. :(
>>>>> 
>>>>> Sorry to hear that... can you provide any more details?
>>>>> 
>>>>> 
>>>>> 
>>>>> -- 
>>>>> Dmitri Zaitsev
>>>>> School of Mathematics
>>>>> Trinity College Dublin
>>>>> 
>>>>> WWW:  http://www.maths.tcd.ie/~zaitsev/ 
>>>>> <http://www.maths.tcd.ie/%7Ezaitsev/>
>>>>> 
>>>> 
>>>> 
>>>> 
>>>> -- 
>>>> Dmitri Zaitsev
>>>> School of Mathematics
>>>> Trinity College Dublin
>>>> 
>>>> WWW:  http://www.maths.tcd.ie/~zaitsev/ 
>>>> <http://www.maths.tcd.ie/%7Ezaitsev/>
>>>> 
>>> 
>>> 
>>> 
>>> -- 
>>> Dmitri Zaitsev
>>> School of Mathematics
>>> Trinity College Dublin
>>> 
>>> WWW:  http://www.maths.tcd.ie/~zaitsev/ 
>>> <http://www.maths.tcd.ie/%7Ezaitsev/>
>>> 
>> 
>> 
>> 
>> -- 
>> Dmitri Zaitsev
>> School of Mathematics
>> Trinity College Dublin
>> 
>> WWW:  http://www.maths.tcd.ie/~zaitsev/ <http://www.maths.tcd.ie/%7Ezaitsev/>
> 
> -- 
> Dmitri Zaitsev
> School of Mathematics
> Trinity College Dublin
> 
> WWW:  http://www.maths.tcd.ie/~zaitsev/ <http://www.maths.tcd.ie/%7Ezaitsev/>


smime.p7s
Description: S/MIME cryptographic signature

Re: libuv fails to build on 10.8.5

[Christopher Jones]

Indeed macports does not care about what web browser you use. The fact you can 
download with that does not matter. 

What matters is what macports ‘port’ command uses. It is this you need to 
bootstrap.

Chris

> On 17 Aug 2019, at 12:50 pm, Dmitri Zaitsev  wrote:
> 
> Maybe I should add that this issue is not due to my system's curl and git 
> clients,
> both are up-to-date and work fine without the issues mentioned there.
> 
> Also I can easily access the same URL and download the files manually.
> 
> The issue seems to be only with MacPorts apparently not using my newer 
> clients.
> 
> 
> On Saturday, August 17, 2019, Dmitri Zaitsev  > wrote:
> Hi Werner,
> 
> Many thanks!
> 
> However, it says:
> > This is an extremely minimal, bare bootstrap of curl, and git, and little 
> > else, specifically targeted at OSX 10.7.5.
> 
> I am on 10.8.5.
> 
> 
> On Saturday, August 17, 2019, Werner LEMBERG  > wrote:
> 
> > I do appreciate your time and fully understand that this is not your
> > concern but would be still thankful if anyone could advice on how to
> > configure MacPorts to use the recent ssl.
> 
> Try this for bootstrapping:
> 
>   https://try.gitea.io/donbright/lm 
> 
> 
> Werner
> 
> 
> -- 
> Dmitri Zaitsev
> School of Mathematics
> Trinity College Dublin
> 
> WWW:  http://www.maths.tcd.ie/~zaitsev/ 
> 
> 
> 
> -- 
> Dmitri Zaitsev
> School of Mathematics
> Trinity College Dublin
> 
> WWW:  http://www.maths.tcd.ie/~zaitsev/ 
> 



smime.p7s
Description: S/MIME cryptographic signature

Re: [mariadb-10.1] missing file in installation

[Christopher Jones]

> This file is missing in the installation on three different computers.
> It's also not present in mariadb-10.0
> 
> How do I fix this ?

File a trac ticket at 

https://trac.macports.org/wiki/Tickets 

making sure to cc the port maintainer.

Chris

smime.p7s
Description: S/MIME cryptographic signature

Re: How do I merge my own fork with updates from the main fork

[Christopher Jones]

Hi,

If you have unstated changes, you have to stash them before rebasing.

That is why I suggested to use 

sudo port sync

as it handles all this for you. Under the hood it does

git pull —rebase —autostash origin master

assuming origin is the primary MacPorts repo.

Chris

> On 24 Aug 2019, at 12:38 pm, Gerben Wierda  wrote:
> 
> This was helpful, except that the rebase failed. There were changes. I tried 
> to repair but failed.
> 
> Albus:macports-ports sysbh$ git fetch --all --prune
> Fetching origin
> Fetching upstream
> remote: Enumerating objects: 33, done.
> remote: Counting objects: 100% (33/33), done.
> remote: Compressing objects: 100% (5/5), done.
> remote: Total 20 (delta 12), reused 20 (delta 12), pack-reused 0
> Unpacking objects: 100% (20/20), done.
> From https://github.com/macports/macports-ports 
> 
>f9f924a097b..a825aeb3efc  master -> upstream/master
> Albus:macports-ports sysbh$ git status
> On branch master
> Your branch is up to date with 'origin/master'.
> 
> Changes not staged for commit:
>   (use "git add ..." to update what will be committed)
>   (use "git checkout -- ..." to discard changes in working directory)
> 
>   modified:   net/nsd/Portfile
> 
> Untracked files:
>   (use "git add ..." to include in what will be committed)
> 
>   net/nsd/%Portfile
>   net/nsd/Portfile-gw-20190817
>   net/nsd/Portfile.orig
>   net/unbound/%Portfile
>   net/unbound/Portfile-gw-20190817
>   net/unbound/Portfile.orig
> 
> no changes added to commit (use "git add" and/or "git commit -a")
> Albus:macports-ports sysbh$ git checkout master
> M net/nsd/Portfile
> Already on 'master'
> Your branch is up to date with 'origin/master'.
> Albus:macports-ports sysbh$ git rebase upstream/master
> error: cannot rebase: You have unstaged changes.
> error: Please commit or stash them.
> Albus:macports-ports sysbh$ git reset
> Unstaged changes after reset:
> M net/nsd/Portfile
> Albus:macports-ports sysbh$ git checkout .
> Albus:macports-ports sysbh$ git status
> On branch master
> Your branch is up to date with 'origin/master'.
> 
> Untracked files:
>   (use "git add ..." to include in what will be committed)
> 
>   net/nsd/%Portfile
>   net/nsd/Portfile-gw-20190817
>   net/nsd/Portfile.orig
>   net/unbound/%Portfile
>   net/unbound/Portfile-gw-20190817
>   net/unbound/Portfile.orig
> 
> nothing added to commit but untracked files present (use "git add" to track)
> Albus:macports-ports sysbh$ git rebase upstream/master
> First, rewinding head to replay your work on top of it...
> Applying: Updated nsd to 4.2.1, added startupitem to nsd, added @gctwnl as 
> maintainer
> Using index info to reconstruct a base tree...
> M net/nsd/Portfile
> M net/unbound/Portfile
> Falling back to patching base and 3-way merge...
> Auto-merging net/unbound/Portfile
> CONFLICT (content): Merge conflict in net/unbound/Portfile
> Auto-merging net/nsd/Portfile
> CONFLICT (content): Merge conflict in net/nsd/Portfile
> error: Failed to merge in the changes.
> Patch failed at 0001 Updated nsd to 4.2.1, added startupitem to nsd, added 
> @gctwnl as maintainer
> hint: Use 'git am --show-current-patch' to see the failed patch
> 
> Resolve all conflicts manually, mark them as resolved with
> "git add/rm ", then run "git rebase --continue".
> You can instead skip this commit: run "git rebase --skip".
> To abort and get back to the state before "git rebase", run "git rebase 
> --abort".
> 
> Albus:macports-ports sysbh$ cd net/unbound/
> Albus:unbound sysbh$ ls -l
> total 40
> -rw-r--r--  1 sysbh  staff  3957 Aug 17 14:35 %Portfile
> -rw-r--r--  1 sysbh  staff  4106 Aug 24 13:29 Portfile
> -rw-r--r--  1 sysbh  staff  3979 Aug 17 14:23 Portfile-gw-20190817
> -rw-r--r--  1 sysbh  staff  3487 Aug 14 21:20 Portfile.orig
> Albus:unbound sysbh$ rm %Portfile Portfile Portfile-gw-20190817 
> Albus:unbound sysbh$ mv Portfile.orig Portfile
> Albus:unbound sysbh$ cd ../nsd
> Albus:nsd sysbh$ rm %Portfile Portfile Portfile-gw-20190817 
> Albus:nsd sysbh$ mv Portfile.orig Portfile
> Albus:nsd sysbh$ ls -l
> total 8
> -rw-r--r--  1 sysbh  staff  2052 Aug 14 21:20 Portfile
> Albus:nsd sysbh$ cd ../..
> Albus:macports-ports sysbh$ git rebase upstream/master
> fatal: It seems that there is already a rebase-apply directory, and
> I wonder if you are in the middle of another rebase.  If that is the
> case, please try
>   git rebase (--continue | --abort | --skip)
> If that is not the case, please
>   rm -fr ".git/rebase-apply"
> and run me again.  I am stopping in case you still have something
> valuable there.
> 
> Albus:macports-ports sysbh$ git rebase --continue
> net/nsd/Portfile: needs merge
> net/unbound/Portfile: needs merge
> You must edit all merge conflicts and then
> mark them as resolved using git add
> Albus:macports-ports sysbh$ rm -fr ".git/rebase-apply"
> Albus:macports-ports sysbh$ git rebase upstream/master
> net

Re: How do I merge my own fork with updates from the main fork

[Christopher Jones]

> On 24 Aug 2019, at 1:28 pm, Christopher Jones  
> wrote:
> 
> Hi,
> 
> If you have unstated changes, you have to stash them before rebasing.

unstated -> unstaged ….

> 
> That is why I suggested to use 
> 
> sudo port sync
> 
> as it handles all this for you. Under the hood it does
> 
> git pull —rebase —autostash origin master
> 
> assuming origin is the primary MacPorts repo.
> 
> Chris
> 
>> On 24 Aug 2019, at 12:38 pm, Gerben Wierda > <mailto:gerben.wie...@rna.nl>> wrote:
>> 
>> This was helpful, except that the rebase failed. There were changes. I tried 
>> to repair but failed.
>> 
>> Albus:macports-ports sysbh$ git fetch --all --prune
>> Fetching origin
>> Fetching upstream
>> remote: Enumerating objects: 33, done.
>> remote: Counting objects: 100% (33/33), done.
>> remote: Compressing objects: 100% (5/5), done.
>> remote: Total 20 (delta 12), reused 20 (delta 12), pack-reused 0
>> Unpacking objects: 100% (20/20), done.
>> From https://github.com/macports/macports-ports 
>> <https://github.com/macports/macports-ports>
>>f9f924a097b..a825aeb3efc  master -> upstream/master
>> Albus:macports-ports sysbh$ git status
>> On branch master
>> Your branch is up to date with 'origin/master'.
>> 
>> Changes not staged for commit:
>>   (use "git add ..." to update what will be committed)
>>   (use "git checkout -- ..." to discard changes in working directory)
>> 
>>  modified:   net/nsd/Portfile
>> 
>> Untracked files:
>>   (use "git add ..." to include in what will be committed)
>> 
>>  net/nsd/%Portfile
>>  net/nsd/Portfile-gw-20190817
>>  net/nsd/Portfile.orig
>>  net/unbound/%Portfile
>>  net/unbound/Portfile-gw-20190817
>>  net/unbound/Portfile.orig
>> 
>> no changes added to commit (use "git add" and/or "git commit -a")
>> Albus:macports-ports sysbh$ git checkout master
>> Mnet/nsd/Portfile
>> Already on 'master'
>> Your branch is up to date with 'origin/master'.
>> Albus:macports-ports sysbh$ git rebase upstream/master
>> error: cannot rebase: You have unstaged changes.
>> error: Please commit or stash them.
>> Albus:macports-ports sysbh$ git reset
>> Unstaged changes after reset:
>> Mnet/nsd/Portfile
>> Albus:macports-ports sysbh$ git checkout .
>> Albus:macports-ports sysbh$ git status
>> On branch master
>> Your branch is up to date with 'origin/master'.
>> 
>> Untracked files:
>>   (use "git add ..." to include in what will be committed)
>> 
>>  net/nsd/%Portfile
>>  net/nsd/Portfile-gw-20190817
>>  net/nsd/Portfile.orig
>>  net/unbound/%Portfile
>>  net/unbound/Portfile-gw-20190817
>>  net/unbound/Portfile.orig
>> 
>> nothing added to commit but untracked files present (use "git add" to track)
>> Albus:macports-ports sysbh$ git rebase upstream/master
>> First, rewinding head to replay your work on top of it...
>> Applying: Updated nsd to 4.2.1, added startupitem to nsd, added @gctwnl as 
>> maintainer
>> Using index info to reconstruct a base tree...
>> Mnet/nsd/Portfile
>> Mnet/unbound/Portfile
>> Falling back to patching base and 3-way merge...
>> Auto-merging net/unbound/Portfile
>> CONFLICT (content): Merge conflict in net/unbound/Portfile
>> Auto-merging net/nsd/Portfile
>> CONFLICT (content): Merge conflict in net/nsd/Portfile
>> error: Failed to merge in the changes.
>> Patch failed at 0001 Updated nsd to 4.2.1, added startupitem to nsd, added 
>> @gctwnl as maintainer
>> hint: Use 'git am --show-current-patch' to see the failed patch
>> 
>> Resolve all conflicts manually, mark them as resolved with
>> "git add/rm ", then run "git rebase --continue".
>> You can instead skip this commit: run "git rebase --skip".
>> To abort and get back to the state before "git rebase", run "git rebase 
>> --abort".
>> 
>> Albus:macports-ports sysbh$ cd net/unbound/
>> Albus:unbound sysbh$ ls -l
>> total 40
>> -rw-r--r--  1 sysbh  staff  3957 Aug 17 14:35 %Portfile
>> -rw-r--r--  1 sysbh  staff  4106 Aug 24 13:29 Portfile
>> -rw-r--r--  1 sysbh  staff  3979 Aug 17 14:23 Portfile-gw-20190817
>> -rw-r--r--  1 sysbh  staff  3487 Aug 14 21:20 Portfile.orig
>> Albus:unbound sysbh$ rm %Portfile Portfile Portfile-gw-20190817 
>> 

Re: How do I merge my own fork with updates from the main fork

[Christopher Jones]

Hi,

> On 24 Aug 2019, at 1:55 pm, Gerben Wierda  wrote:
> 
> Thanks.
> 
>> On 24 Aug 2019, at 12:40, Chris Jones > > wrote:
>> 
>> I recommend changing [the setup] so the primary macports repo is called 
>> origin, and you call your fork something. Things tend to work more smoothly 
>> this way.
> 
> OK. So how do I rename these? Or how should I have created them in the first 
> place? I can of course throw everything away and start anew. At this point, I 
> need to find out how to get back to a working situation.

You can rename remotes. See

git remote —help


> 
>> If you have unstated changes, you have to stash them before rebasing.
> 
> ’stash’ is just ‘move them out of the way’ or is it something git?

its way more than just moving them out the way.  Mote like a temporary commit. 
again, see

git stash —help

cheers Chris

> 
>> That is why I suggested to use 
>> 
>> sudo port sync
>> 
>> as it handles all this for you. Under the hood it does
>> 
>> git pull —rebase —autostash origin master
>> 
>> assuming origin is the primary MacPorts repo.
> 
> Aha.
> 
> I have of course two repos:
> 
> /opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/ports
>  
> ~/MacPortsDev/macports-ports
> 
> And my sources.conf says:
> 
> file:///Users/sysbh/MacPortsDev/macports-ports 
> 
> rsync://rsync.macports.org/macports/release/tarballs/ports.tar 
>  [default]
> 
> So that ~/MacPortsDev/macports-ports is the tree used for the port install 
> etc. commands
> 
>> B.t.w. Its very much bad practise to make new commits directly to the master 
>> branch of your own fork. You should keep your master clean and only pull 
>> into it from the primary macports master, using the commands I just sent 
>> around.
> 
> Yeah, I understand. It was the current status though.
> 
> I have been trying to follow instructions but I am trying to prevent to have 
> to become a git expert (there is insufficient time for that available, such 
> as studying a whole git book). Just knowing some basic recipes for 
> actions/steps lets me concentrate on the actual stuff I want to do that is 
> potentially contributing to ports.
> 
> G



smime.p7s
Description: S/MIME cryptographic signature

Re: How do I merge my own fork with updates from the main fork

[Christopher Jones]

Hi,

The names remotes are given are completely arbitrary. It s normal to have one 
called origin, and the rest something else, but it is not mandatory to have 
that.

It is true the instructions below in places assume you will call your fork 
origin and the main MP one something else, and I tend to recommend the 
opposite. But, as long as you know what *you* called your remotes its easy to 
adapt any instructions to your situation.

If you have not called the main MP repo origin, then you can still sync with it.

> git pull —rebase —autostash  master
> sudo portindex

replace  with whatever you have called the remote in your checkout for the 
main MP repo.

The above is in effect what 'sudo port sync’  does, if you have set things up 
such that port uses your checkout as its main source. However, it is not 
mandatory to use port sync, the above has the same result.

Chris

> On 24 Aug 2019, at 4:06 pm, Gerben Wierda  wrote:
> 
> Yes, those were among the instructions I followed. But that gets me the 
> situation of which now is said doesn’t fit with port sync. e.g. those 
> instructions means my own fork is called origin and the macports fork is 
> called upstream. But port sync assumes differently (if I understand it 
> correctly)
> 
> As I understand it, I need my own fork gctwnl/macports-ports because I am not 
> allowed to push to macports/macports-ports and I need to work with branches 
> inside my own fork. But how that whole landscape (a) keeps synchronised and 
> (b) works with the port command is unclear, also after reading that info.
> 
> Gerben Wierda
> Chess and the Art of Enterprise Architecture 
> Mastering ArchiMate 
> Architecture for Real Enterprises 
>  at 
> InfoWorld
> On Slippery Ice  at EAPJ
> 
>> On 24 Aug 2019, at 16:47, Ryan Schmidt > > wrote:
>> 
>> 
>> 
>> On Aug 24, 2019, at 07:55, Gerben Wierda wrote:
>> 
>>> I have been trying to follow instructions but I am trying to prevent to 
>>> have to become a git expert (there is insufficient time for that available, 
>>> such as studying a whole git book). Just knowing some basic recipes for 
>>> actions/steps lets me concentrate on the actual stuff I want to do that is 
>>> potentially contributing to ports.
>>> 
>> 
>> We have some help available here:
>> 
>> https://trac.macports.org/wiki/WorkingWithGit 
>> 
>> 
>> We needed a cheat sheet for people like you and me who don't have time to 
>> learn git, and other developers more familiar with git thankfully pitched in 
>> to write that. If it's missing anything you'd find helpful, please add it or 
>> suggest what should be added.
>> 
> 



smime.p7s
Description: S/MIME cryptographic signature

Re: libraw updates because fetch gives 404

[Christopher Jones]

Hi,

> On 26 Aug 2019, at 8:49 am, Riccardo Mottola via macports-users 
>  wrote:
> 
> Hi,
> 
> since yesterday I am trying to update... but...
> 
> Is something wrong with our mirrors?

The mirrors themselves seem fine. Just looks like the 0.19.5 update dist file 
was never mirrored for some reason…

Chris

> 
> 
> Riccardo
> 
> 
> --->  Fetching distfiles for libraw
> 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: 
> 
> --->  LibRaw-0.19.5.tar.gz does not exist in 
> /opt/local/var/macports/distfiles/libraw
> --->  Attempting to fetch LibRaw-0.19.5.tar.gz from 
> http://lil.fr.distfiles.macports.org/libraw
> 
>   % Total% Received % Xferd  Average Speed   TimeTime Time  Current
>  Dload  Upload   Total   Spent Left  Speed
>   0 00 00 0  0  0 --:--:--  0:00:04 --:--:-- 
> 0--->  Attempting to fetch LibRaw-0.19.5.tar.gz from 
> http://nue.de.distfiles.macports.org/libraw
> 
>   % Total% Received % Xferd  Average Speed   TimeTime Time  Current
>  Dload  Upload   Total   Spent Left  Speed
>   0 00 00 0  0  0 --:--:--  0:00:04 --:--:-- 
> 0--->  Attempting to fetch LibRaw-0.19.5.tar.gz from 
> http://mse.uk.distfiles.macports.org/sites/distfiles.macports.org/libraw
>   % Total% Received % Xferd  Average Speed   TimeTime Time  Current
>  Dload  Upload   Total   Spent Left  Speed
> 100   269  100   2690 0 66  0  0:00:04  0:00:04 --:--:--66
> 100   269  100   2690 0 66  0  0:00:04  0:00:04 --:--:-- 0
>   0   2690 00 0  0  0 --:--:--  0:00:08 --:--:-- 
> 0--->  Attempting to fetch LibRaw-0.19.5.tar.gz from 
> http://fco.it.distfiles.macports.org/mirrors/macports-distfiles/libraw
> 
>   % Total% Received % Xferd  Average Speed   TimeTime Time  Current
>  Dload  Upload   Total   Spent Left  Speed
>   0 00 00 0  0  0 --:--:--  0:00:04 --:--:-- 
> 0--->  Attempting to fetch LibRaw-0.19.5.tar.gz from 
> http://distfiles.macports.org/libraw
> 
>   % Total% Received % Xferd  Average Speed   TimeTime Time  Current
>  Dload  Upload   Total   Spent Left  Speed
>   0 00 00 0  0  0 --:--:--  0:00:04 --:--:-- 
> 0--->  Attempting to fetch LibRaw-0.19.5.tar.gz from 
> http://ykf.ca.distfiles.macports.org/MacPorts/mpdistfiles/libraw
> 
>   % Total% Received % Xferd  Average Speed   TimeTime Time  Current
>  Dload  Upload   Total   Spent Left  Speed
>   0 00 00 0  0  0 --:--:--  0:00:04 --:--:-- 
> 0--->  Attempting to fetch LibRaw-0.19.5.tar.gz from 
> http://ywg.ca.distfiles.macports.org/mirror/macports/distfiles/libraw
> 
>   % Total% Received % Xferd  Average Speed   TimeTime Time  Current
>  Dload  Upload   Total   Spent Left  Speed
>   0 00 00 0  0  0 --:--:--  0:00:04 --:--:-- 
> 0--->  Attempting to fetch LibRaw-0.19.5.tar.gz from 
> https://www.libraw.org/data/
> 
>   % Total% Received % Xferd  Average Speed   TimeTime Time  Current
>  Dload  Upload   Total   Spent Left  Speed
>   0 00 00 0  0  0 --:--:--  0:00:01 --:--:-- 
> 0--->  Attempting to fetch LibRaw-0.19.5.tar.gz from 
> http://jnb.za.distfiles.macports.org/distfiles/libraw
> 
>   % Total% Received % Xferd  Average Speed   TimeTime Time  Current
>  Dload  Upload   Total   Spent Left  Speed
>   0 00 00 0  0  0 --:--:--  0:00:04 --:--:-- 
> 0--->  Attempting to fetch LibRaw-0.19.5.tar.gz from 
> http://cjj.kr.distfiles.macports.org/libraw
> 
>   % Total% Received % Xferd  Average Speed   TimeTime Time  Current
>  Dload  Upload   Total   Spent Left  Speed
>   0 00 00 0  0  0 --:--:--  0:00:04 --:--:-- 
> 0--->  Attempting to fetch LibRaw-0.19.5.tar.gz from 
> http://aarnet.au.distfiles.macports.org/pub/macports/distfiles/libraw
> 
>   % Total% Received % Xferd  Average Speed   TimeTime Time  Current
>  Dload  Upload   Total   Spent Left  Speed
>   0 00 00 0  0  0 --:--:--  0:00:04 --:--:-- 
> 0--->  Attempting to fetch LibRaw-0.19.5.tar.gz from 
> http://aus.us.distfiles.macports.org/macports/distfiles/libraw
> 
>   % Total% Received % Xferd  Average Speed   TimeTime Time  Current
>  Dload  Upload   Total   Spent Left  Speed
>   0  

Re: [?bug?] PortGroup python 1.0

[Christopher Jones]

Hi,

Your port file is incorrectly set up. Compare to the original

https://github.com/macports/macports-ports/blob/master/python/py-acme/Portfile 


you are missing the subport bits. This part is not optional, its part of how 
the python PG works. ${python.version} is only defined within each subport the 
PG sets up.

Chris

> On 2 Sep 2019, at 9:10 pm, Bjarne D Mathiesen  
> wrote:
> 
> I've got this :
> 
> file:///Volumes/Bjarne/WebServer/MacPorts/newPorts
> rsync://rsync.macports.org/release/tarballs/ports.tar [default]
> 
> in my sources.conf
> 
> Now, if I put my py-acme Portfile
>https://macports.mathiesen.info/portfiles/python/py-acme/Portfile
> into my own port tree, I get this :
> 
> #=> port -d sync
> [standard stuff]...
> Failed to parse file python/py-acme/Portfile: can't read
> "python.version": no such variable
> 
> Total number of ports parsed: 1
> Ports successfully parsed:0
> Ports failed: 1
> Up-to-date ports skipped: 17
> 
> +++
> I've "rsync -a" the '_resources' directory into my ports tree.
> 
> I have to explicitly set "python.version 37" in the Portfile in order
> for macports to accept it.
> 
> Am I doing something wrong here ?!?
> The original macports portfile doesn't explicitly set this value.
> 
> -- 
> Bjarne D Mathiesen
> Korsør ; Danmark ; Europa
> --
> denne besked er skrevet i et (næsten) M$-frit miljø
> MacOS X 10.13.6 High Sierra :
>   17" 2011 MacBook Pro ; 2.8GHz Intel Core i7 ; 16GB 1067MHz DDR3
>   2012 Mac Pro ; 2 x 3.46GHz 6-Core Xeon ; 48GB
> MacOS X 10.6.8 Snow Leopard :
>   Mac Mini ; 2GHz Core 2 Duo (64 bit) ; 4GB (3GB actual) 667MHz
>   Mac Mini ; 1.83GHz Core Duo (32 bit) ; 2GB 667Mhz



smime.p7s
Description: S/MIME cryptographic signature

Re: [?bug?] PortGroup python 1.0

[Christopher Jones]

b.t.w. its also far from obvious (to me at least) why you have altered the port 
file in the way you have ? Whats you aim here… ?

Chris

> On 2 Sep 2019, at 9:40 pm, Christopher Jones  wrote:
> 
> Hi,
> 
> Your port file is incorrectly set up. Compare to the original
> 
> https://github.com/macports/macports-ports/blob/master/python/py-acme/Portfile
>  
> <https://github.com/macports/macports-ports/blob/master/python/py-acme/Portfile>
> 
> you are missing the subport bits. This part is not optional, its part of how 
> the python PG works. ${python.version} is only defined within each subport 
> the PG sets up.
> 
> Chris
> 
>> On 2 Sep 2019, at 9:10 pm, Bjarne D Mathiesen > <mailto:macint...@mathiesen.info>> wrote:
>> 
>> I've got this :
>> 
>> file:///Volumes/Bjarne/WebServer/MacPorts/newPorts 
>> 
>> rsync://rsync.macports.org/release/tarballs/ports.tar [default]
>> 
>> in my sources.conf
>> 
>> Now, if I put my py-acme Portfile
>>https://macports.mathiesen.info/portfiles/python/py-acme/Portfile
>> into my own port tree, I get this :
>> 
>> #=> port -d sync
>> [standard stuff]...
>> Failed to parse file python/py-acme/Portfile: can't read
>> "python.version": no such variable
>> 
>> Total number of ports parsed:1
>> Ports successfully parsed:   0
>> Ports failed:1
>> Up-to-date ports skipped:17
>> 
>> +++
>> I've "rsync -a" the '_resources' directory into my ports tree.
>> 
>> I have to explicitly set "python.version 37" in the Portfile in order
>> for macports to accept it.
>> 
>> Am I doing something wrong here ?!?
>> The original macports portfile doesn't explicitly set this value.
>> 
>> -- 
>> Bjarne D Mathiesen
>> Korsør ; Danmark ; Europa
>> --
>> denne besked er skrevet i et (næsten) M$-frit miljø
>> MacOS X 10.13.6 High Sierra :
>>   17" 2011 MacBook Pro ; 2.8GHz Intel Core i7 ; 16GB 1067MHz DDR3
>>   2012 Mac Pro ; 2 x 3.46GHz 6-Core Xeon ; 48GB
>> MacOS X 10.6.8 Snow Leopard :
>>   Mac Mini ; 2GHz Core 2 Duo (64 bit) ; 4GB (3GB actual) 667MHz
>>   Mac Mini ; 1.83GHz Core Duo (32 bit) ; 2GB 667Mhz
> 



smime.p7s
Description: S/MIME cryptographic signature

Re: [portgroups] Python

[Christopher Jones]

Depends what you are thinking of by ‘officially support’.

We have ports for

python26 @2.6.9_7 (lang)
An interpreted, object-oriented programming language

python27 @2.7.16_2 (lang)
An interpreted, object-oriented programming language

python27-bootstrap @2.7.16_2 (lang)
An interpreted, object-oriented programming language

python32 @3.2.6_8 (lang)
An interpreted, object-oriented programming language

python33 @3.3.7_3 (lang)
An interpreted, object-oriented programming language

python34 @3.4.10_2 (lang)
An interpreted, object-oriented programming language

python35 @3.5.7_1 (lang)
An interpreted, object-oriented programming language

python36 @3.6.9_1 (lang)
An interpreted, object-oriented programming language

python37 @3.7.4_1 (lang)
An interpreted, object-oriented programming language

However, that does not mean each of the various ‘py’ ports support all of the 
above..

Chris



> On 12 Sep 2019, at 9:09 pm, Bjarne D Mathiesen  
> wrote:
> 
> Which versions of Python do macports still officially support ?!?
> 
> -- 
> Bjarne D Mathiesen
> Korsør ; Danmark ; Europa
> --
> denne besked er skrevet i et (næsten) M$-frit miljø
> MacOS X 10.13.6 High Sierra :
>   17" 2011 MacBook Pro ; 2.8GHz Intel Core i7 ; 16GB 1067MHz DDR3
>   2012 Mac Pro ; 2 x 3.46GHz 6-Core Xeon ; 48GB
> MacOS X 10.6.8 Snow Leopard :
>   Mac Mini ; 2GHz Core 2 Duo (64 bit) ; 4GB (3GB actual) 667MHz
>   Mac Mini ; 1.83GHz Core Duo (32 bit) ; 2GB 667Mhz



smime.p7s
Description: S/MIME cryptographic signature

Re: MacPorts 2.6.0 has been released

[Christopher Jones]

run

> sudo port -d selfupdate

again, and report what it returns.

Chris

> On 22 Sep 2019, at 4:06 pm, Gerben Wierda  wrote:
> 
> Ran 'sudo port selfupdate’ 
> 
> albus:~ sysbh$ sudo port selfupdate
> --->  Updating MacPorts base sources using rsync
> MacPorts base version 2.5.4 installed,
> MacPorts base version 2.6.0 downloaded.
> --->  Updating the ports tree
> --->  MacPorts base is outdated, installing new version 2.6.0
> Installing new MacPorts release in /opt/local as root:wheel; permissions 0755
> 
> after which:
> 
> port version
> 
> still says
> 
> albus:~ sysbh$ port version
> Version: 2.5.4
> albus:~ sysbh$ which port
> /opt/local/bin/port
> 
> Where does this go wrong?
> 
> Gerben Wierda
> Chess and the Art of Enterprise Architecture 
> Mastering ArchiMate 
> Architecture for Real Enterprises 
>  at 
> InfoWorld
> On Slippery Ice  at EAPJ
> 
>> On 21 Sep 2019, at 05:30, Joshua Root > > wrote:
>> 
>> The MacPorts Project is happy to announce that the 2.6.0 version has now
>> been released. It is available via the usual methods:
>> 
>> - selfupdate if you already have MacPorts installed
>> - package installers for 10.14 [1], 10.13 [2], 10.12 [3], 10.11 [4],
>>   10.10 [5], 10.9 [6], 10.8 [7], 10.7 [8], 10.6 [9], 10.5 [10] and
>>   10.4 [11] (universal i386/ppc for 10.4 and 10.5, i386/x86_64 for
>>   10.6, and the rest x86_64)
>> - source tarballs, both .tar.bz2 [12] and .tar.gz [13]
>> - git tag [14]
>> 
>> The list of what's new in 2.6.0 can be found in the ChangeLog [15].
>> 
>> Of special note for users of 10.6-10.8: The default C++ stdlib has
>> changed from libstdc++ to libc++. This will enable building ports that
>> require C++11 and beyond much more easily. All C++-based ports using the
>> old stdlib will need to be rebuilt, so we recommend that you run 'sudo
>> port rev-upgrade' after updating to MacPorts 2.6.0.
>> 
>> We are currently in the process of switching the packages server over
>> to the new stdlib, so availability of binary packages for 10.6-10.8 will
>> be reduced for a time until the builds catch up. (There will initially
>> be no availability for a hopefully very short time until we flip the
>> switch to mark the archives as libc++.)
>> 
>> If you previously followed the LibcxxOnOlderSystems instructions on the
>> wiki, you should revert the changes to macports.conf that the
>> instructions specify. In particular, default_compilers should not be set
>> so that the new MacPorts version can pick the compilers itself. You also
>> probably want buildfromsource to be its default value ("ifneeded") so
>> that you will use binaries once they are available.
>> 
>> A big thanks to the developers for their hard work with all of the
>> various features and bug fixes in 2.6.0, and to all those who helped out
>> by reporting bugs or testing.
>> 
>> Detached PGP signatures for the pkg/dmgs and source tarballs have been
>> made with my key, which is available on the keyservers and my MacPorts
>> wiki page [16].
>> 
>> - Josh
>> 
>> [1]
>> >  
>> >
>> [2]
>> >  
>> >
>> [3]
>> >  
>> >
>> [4]
>> >  
>> >
>> [5]
>> >  
>> >
>> [6]
>> >  
>> >
>> [7]
>> >  
>> >
>> [8]
>> >  
>> >
>> [9]
>> 

Re: MacPorts 2.6 - Leopard 20.6 and libgcc8

[Christopher Jones]

Hi,

From the output it appears cmake has a dependency on both libgcc and libgcc8. 
This is not correct on 10.5.

You should file a ticket against cmake to bring it to the attention of the 
maintainer.

Chris

> On 26 Sep 2019, at 8:54 pm, Riccardo Mottola  
> wrote:
> 
> Hi,
> 
> Joshua Root wrote:
>> Actually it looks like that's not the case on Leopard. Could you show
>> the 'port rdeps' output for whatever you're trying to build?
> 
> it shows both versions of libgcc
> I appear to have only one outdated port, harfbuzz, this is the tree:
> 
> 
> The following ports are dependencies of harfbuzz @2.6.1_0:
>   xz
> libiconv
>   gperf
> gettext
>   ncurses
>   pkgconfig
>   gcc6
> cctools
>   libunwind-headers
> gmp
> isl
> ld64
>   ld64-127
> libmacho-headers
> llvm-3.3
>   libffi
>   perl5
> perl5.28
>   db48
>   gdbm
> readline
>   llvm_select
> zlib
> libmpc
>   mpfr
> gcc_select
> libgcc6
>   libgcc7
>   cairo
> libpixman
> glib2
>   autoconf
>   automake
>   libtool
> xattr
>   unzip
>   libxml2
> icu
>   pcre
> bzip2
> libedit
>   python27
> expat
> openssl
> sqlite3
> python_select
> python2_select
> fontconfig
>   freetype
> libpng
>   ossp-uuid
> xrender
>   xorg-libX11
> xorg-xtrans
> xorg-xorgproto
> xorg-util-macros
> clang-8.0
>   cmake
> legacy-support
> curl
>   libidn2
> libunistring
>   texinfo
> help2man
>   p5.28-locale-gettext
>   libpsl
> python37
>   python3_select
>   curl-ca-bundle
> libarchive
>   lzo2
>   lz4
>   zstd
> libuv
> libgcc8
> libgcc
>   clang-5.0
> libomp
> llvm-5.0
>   xar
>   libcxx
> clang_select
>   llvm-8.0
> xorg-libXdmcp
> xorg-libXau
> xorg-libxcb
>   xorg-xcb-proto
>   xorg-libpthread-stubs
> xorg-libXext
> xorg-xcb-util
>   graphite2
> fonttools
>   py37-setuptools
>   py37-brotli
> python36
> 



smime.p7s
Description: S/MIME cryptographic signature

Re: MacPorts 2.6 - Leopard 20.6 and libgcc8

[Christopher Jones]

Hi,

Hmm, yeah. Now I look at that again its clear the deps are not really right for 
older systems that do not support all the various gcc versions.

I think the fix is to not explicitly list all the libgcc versions for each 
older gcc, but just rely on the fact each libgcc port knows what newer libgcc 
deps it needs. e.g. libgcc6 knows it needs libgcc7, and so on. so change gcc 
libgcc7

 set libgccs "path:lib/libgcc/libgcc_s.1.dylib:libgcc port:libgcc8 port:libgcc7 
port:libgcc6”

to just

 set libgccs "path:lib/libgcc/libgcc_s.1.dylib:libgcc  port:libgcc6"

so on newer systems, the libgcc6 will also implicitly bring in libgcc7, 
libgcc8, and libgcc9, but on older systems it will stop on the last supported.

Chris

> set libgccs "path:lib/libgcc/libgcc_s.1.dylib:libgcc port:libgcc8 
> port:libgcc7 port:libgcc6 port:libgcc45"On 26 Sep 2019, at 10:04 pm, Joshua 
> Root  wrote:
> 
> On 2019-9-27 06:01 , Christopher Jones wrote:
>> Hi,
>> 
>> From the output it appears cmake has a dependency on both libgcc and 
>> libgcc8. This is not correct on 10.5.
>> 
>> You should file a ticket against cmake to bring it to the attention of the 
>> maintainer.
> 
> It's not cmake doing it. The problem is actually this:
> <https://github.com/macports/macports-ports/commit/3e21e859b6b935b3413a1c357d39041cdeb03921#diff-4061bdcd5b9dd81cb5a85dccd8def8ab>
> 
> - Josh



smime.p7s
Description: S/MIME cryptographic signature

Re: Octave.app 64-bit?

[Christopher Jones]

Unless you are installing something universal, or i386, it will be 64 bit (i.e. 
x86_64 arch).

( Also, by construction, if the port finds and runs on macOS 10.15 it will have 
to be 64 bit… )

> On 10 Oct 2019, at 10:12 pm, Murray Eisenberg  
> wrote:
> 
> Is the current version of octave.app, installed with octave+app, 64-bit and 
> hence compatible with Catalina?
> 
> if not, what are the prospects?
> 
> In general, is there any way to tell which macports ports are, or are not, 
> 64-bit?
> 
> ---
> Murray Eisenberg  murrayeisenb...@gmail.com
> 503 King Farm Blvd #101   Home (240)-246-7240
> Rockville, MD 20850-6667  Mobile (413)-427-5334
> 
> 



smime.p7s
Description: S/MIME cryptographic signature

Re: gcc/gfortran can't find system library in latest Xcode/Mojave

[Christopher Jones]

Hi,

Apple has been depreciating shipping the SDK  under /usr/include for some time 
now, and come Xcode11/macOS10.15 they are gone (with Xcode10 they where gone by 
default but you could add them back).

You need to specify the SDK root you need to use. See

https://www.mail-archive.com/macports-dev@lists.macports.org/msg06711.html 


for a previous discussion.

Chris

> On 10 Oct 2019, at 11:20 pm, David Nicholls  wrote:
> 
> Something Apple did in either the latest update to Mojave or the latest Xcode 
> breaks gfortran's (8.3.0) ability to find the system library. I updated to 
> the latest macports recently, too.  gfortran 8.3.0 that compiled code easily 
> under previous versions of Mojave/Xcode/macports now throws an error:
> 
> M5118 error on build:
> ld: library not found for -lSystem
> collect2: error: ld returned 1 exit status
> make[1]: *** [../lab/map51] Error 1
> make: *** [build] Error 2 with gfortran 8.3.0
> 
> Does anyone know anything about this?
> 
> DN
> 
> David C Nicholls,
> Research School of Astronomy & Astrophysics
> Australian National University
> 
> 



smime.p7s
Description: S/MIME cryptographic signature

Re: gcc/gfortran can't find system library in latest Xcode/Mojave

[Christopher Jones]

Hi,

Just to add one detail to that below. Part of the problem is Xcode 11 even on 
maOS10.14 only supplies the 10.15 SDK. gcc when built gets the SDK baked into 
the default search paths it will use, and because you are  (I presume) using 
gcc binary install it is using the one built on the buildbot which is still 
using Xcode 10 and thus the 10.14 SDK. If you want to see what gcc is doing, 
try building with the -v option added….

So, additional solutions, if you want to avoid having to manually set the SDK 
root as you use gcc, are :-

1. revert back to Xcode 10 on mac OS 10.14, to match the buildbot.
2. rebuild gcc/libgcc from source yourself, so then the SDK will (I think…) 
match what you now have.

I would go with 1. as that will likely fix other residual issues with Xcode 11 
on mac OS 10.14..

cheers Chris

3. I guess a third option is to update you OS to 10.15….

> On 10 Oct 2019, at 11:35 pm, Christopher Jones  
> wrote:
> 
> Hi,
> 
> Apple has been depreciating shipping the SDK  under /usr/include for some 
> time now, and come Xcode11/macOS10.15 they are gone (with Xcode10 they where 
> gone by default but you could add them back).
> 
> You need to specify the SDK root you need to use. See
> 
> https://www.mail-archive.com/macports-dev@lists.macports.org/msg06711.html 
> <https://www.mail-archive.com/macports-dev@lists.macports.org/msg06711.html>
> 
> for a previous discussion.
> 
> Chris
> 
>> On 10 Oct 2019, at 11:20 pm, David Nicholls > <mailto:david.nicho...@anu.edu.au>> wrote:
>> 
>> Something Apple did in either the latest update to Mojave or the latest 
>> Xcode breaks gfortran's (8.3.0) ability to find the system library. I 
>> updated to the latest macports recently, too.  gfortran 8.3.0 that compiled 
>> code easily under previous versions of Mojave/Xcode/macports now throws an 
>> error:
>> 
>> M5118 error on build:
>> ld: library not found for -lSystem
>> collect2: error: ld returned 1 exit status
>> make[1]: *** [../lab/map51] Error 1
>> make: *** [build] Error 2 with gfortran 8.3.0
>> 
>> Does anyone know anything about this?
>> 
>> DN
>> 
>> David C Nicholls,
>> Research School of Astronomy & Astrophysics
>> Australian National University
>> 
>> 
> 



smime.p7s
Description: S/MIME cryptographic signature

Re: mpv, ffmpeg seg fault in macOS catalina

[Christopher Jones]

Hi,

10.15 issues are worked around in

https://github.com/macports/macports-ports/commit/36c3a9a2844ab979be1388280922b25d1f7b56ce
 


https://github.com/macports/macports-ports/commit/2de6959b098cb95883863a2cf46575dfcf4c211c
 


They blacklist Xcode 11 clang, and thus the builds fallback to one of MacPorts 
MP’s clang compilers (9.0). 

Running Xcode 10 on macOS10.15 is unnecessary, and not really a good idea.

For ‘Part B’ difficult to say as long as Xcode has issues (which I understand 
as off 11.1 it does). Until those are addressed hard to say if the project 
themselves also have issues to address.

Chris

> On 17 Oct 2019, at 9:58 pm, Gill Bates  wrote:
> 
> I recently updated to catalina (10.15) and Xcode (11.1), installed MacPorts 
> from source (2.6.1) and had it build mpv and its dependencies. However, mpv 
> (and ffmpeg for example) do not run apparently related to some new default 
> compiler option enforcing 16 byte stack alignment? See:
> https://trac.ffmpeg.org/ticket/8073 
> https://github.com/mpv-player/mpv/issues/7053 
> 
> https://forums.developer.apple.com/thread/121887 
> 
> 
> The advice seems to be to revert Xcode but will rebuilding everything with 
> Xcode 10.3 on macos 10.15 really be a workaround? Or is a better choice to 
> modify portfiles to include the CFLAG option to disable stack checks as 
> mentioned in the linked posts and use Xcode 11.1?
> 
> "Part B" is a question for my understanding, is this a really an 
> Xcode/compiler issue or a problem with the source software packages?
> 
> Thanks in advance for any advice.



smime.p7s
Description: S/MIME cryptographic signature

Re: dmgbuild ports disappeared

[Christopher Jones]

Hi,

Running

 git log -Sdmgbuild

on my clone of the ports repo returns nothing. I hate to disagree with you, but 
think this means there has never been any relating the dmgbuild in the ports 
tree, at least as far as the current git history goes back.

Chris

> On 20 Oct 2019, at 1:26 pm, Henning Hraban Ramm  wrote:
> 
>> Am 2019-10-20 um 13:51 schrieb Ryan Schmidt :
>> 
>> On Oct 20, 2019, at 05:42, Henning Hraban Ramm wrote:
>> 
>>> Hi, I’m using MacPorts for many years, but I’m new on this list.
>>> 
>>> A few days ago I was building SCM Workbench[1] on MacPorts Python 3.7 
>>> (because the binary package was expecting python.org Frameworks to be 
>>> installed). The project uses dmgbuild[2], and there were ports for all(?) 
>>> versions of Python.
>>> 
>>> py37-dmgbuild didn’t work, because the port used an old state of dmgbuild 
>>> that was Py2 only, but py27-dmgbuild did the job.
>>> 
>>> Today I wanted to document the process – and the ports were gone!
>>> 
>>> I looked for "dmgbuild" in all mailing list, tracker and github commit 
>>> messages and found only:
>>> 
>>> * https://trac.macports.org/attachment/ticket/56662/main.log (dmgbuild used 
>>> as an external tool)
>>> * 
>>> https://trac.macports.org/attachment/ticket/59137/vlc_build_log_clang8.log 
>>> (dmgbuild not found)
>>> 
>>> (I used Google with "site:" as well as site searches.)
>>> 
>>> Does anyone know why these ports were removed (instead of updated maybe) or 
>>> how I could find out more?
>>> 
>>> Best regards, Hraban
>>> 
>>> [1] https://github.com/barry-scott/scm-workbench
>>> [2] https://github.com/al45tair/dmgbuild
>> 
>> I also can't find any trace of a py-dmgbuild in MacPorts. Are you sure it 
>> existed? If you had a py-dmgbuild portfile, is it possible you wrote it 
>> yourself, or downloaded it from some place other than MacPorts?
> 
> No, I didn’t write it myself, and I’m sure it was there 3 days ago (see 
> https://github.com/barry-scott/scm-workbench/issues/12), since I installed 
> py37-dmgbuild first and then py27-dmgbuild.
> Strange. Seems like my Mac is infested...
> 
> Best regards, Hraban
> 
> BTW updating MacPorts today fixed poppler-qt5 again, yay! (That one makes 
> trouble all the time.)
> But it destroyed all of my pips (py37-pip,py36-pip and py27-pip), I needed to 
> reinstall them.



smime.p7s
Description: S/MIME cryptographic signature

Re: failure to get gcc9 running

[Christopher Jones]

> 
> --->  Computing dependencies for gdbm
> --->  Fetching distfiles for gdbm
> --->  Verifying checksums for gdbm
> --->  Extracting gdbm
> --->  Applying patches to gdbm
> --->  Configuring gdbm
> Error: Failed to configure gdbm, consult 
> /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_databases_gdbm/gdbm/work/gdbm-1.18.1/config.log
> Error: Failed to configure gdbm: configure failure: command execution failed
> Error: See 
> /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_databases_gdbm/gdbm/main.log
>  for details.
> Error: rev-upgrade failed: Error rebuilding gdbm
> Error: Follow https://guide.macports.org/#project.tickets 
>  to report a bug.
> --​
> 
> It all leads me nowhere. Was it a mistake to upgrade to macOS 1014 for this 
> MacBook? It all worked nicely before with the Fortran compiler g95. However, 
> that does not work anymore with the new system, so I had to download gcc9. 
> Gave me this enormous sequence of errors which I do not know how to fix. I 
> will greatly appreciate assistance on this. 

gcc9 works just fine on 10.14 so whatever you did to get into the state above, 
it is not normal. 

A few comments.

- Did you *really* correctly follow the migration instructions at

https://trac.macports.org/wiki/Migration 


? 

as I am not sure how you could get into such a mess if you had. Did you really 
remove *all* ports in order to reinstall them ?

- When you get errors like those above, you have to look into the log file that 
is referenced. e.g.

> Error: Failed to configure gdbm, consult 
> /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_databases_gdbm/gdbm/work/gdbm-1.18.1/config.log

so, what does that log say ?

Honestly, the simplest solution might be to start again, as if you are doing an 
OS migration. So follow the instructions above, making sure to remove 
everything.

I would also suggest *not* just blinding reinstalling everything you previously 
had, so once you get to a point where you have an empty vanilla MacPOrts 
installation, please just run

> sudo port sync
> sudo port install gcc9

that, should work just fine. Then you can go from there adding what else you 
want.

Chris

smime.p7s
Description: S/MIME cryptographic signature

Re: rxvt-unicode install fails

[Christopher Jones]

Hi,

If a ticket does not currently exist for your issue, then you should open one at

https://trac.macports.org/wiki/Tickets 

cheers Chris

> On 5 Nov 2019, at 4:20 pm, 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.
> 
> thank you,
> joerg
> 
> PS:
> #
> tail of logfile:
> ...
> :debug:build Executing org.macports.build (rxvt-unicode)
> :debug:build Environment:
> :debug:build CC_PRINT_OPTIONS='YES'
> :debug:build 
> CC_PRINT_OPTIONS_FILE='/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_x11_rxvt-unicode/rxvt-unicode/work/.CC_PRINT_OPTIONS'
> :debug:build CPATH='/opt/local/include'
> :debug:build DEVELOPER_DIR='/Library/Developer/CommandLineTools'
> :debug:build LIBRARY_PATH='/opt/local/lib'
> :debug:build MACOSX_DEPLOYMENT_TARGET='10.14'
> :debug:build 
> SDKROOT='/Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk'
> :info:build Executing:  cd 
> "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_x11_rxvt-unicode/rxvt-unicode/work/rxvt-unicode-9.22"
>  && /usr/bin/make -j12 -w >
> :debug:build system:  cd 
> "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_x11_rxvt-unicode/rxvt-unicode/work/rxvt-unicode-9.22"
>  && /usr/bin/make -j12 -w al>
> :info:build make: Entering directory 
> `/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_x11_rxvt-unicode/rxvt-unicode/work/rxvt-unicode-9.22'
> :info:build make[1]: Entering directory 
> `/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_x11_rxvt-unicode/rxvt-unicode/work/rxvt-unicode-9.22/src'
> :info:build /usr/bin/clang++ -I.. -I. -I. -I./../libev -I./../libptytty/src 
> -DHAVE_CONFIG_H -I/opt/local/include 
> -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk 
> -I/opt/local/include/ossp -I/o>
> :info:build In file included from ./rxvtperl.xs:25:
> :info:build 
> /opt/local/lib/perl5/5.28/darwin-thread-multi-2level/CORE/perl.h:684:10: 
> fatal error: 'sys/types.h' file not found
> :info:build #include 
> :info:build  ^
> :info:build 1 error generated.
> :info:build make[1]: *** [rxvtperl.o] Error 1
> :info:build make[1]: Leaving directory 
> `/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_x11_rxvt-unicode/rxvt-unicode/work/rxvt-unicode-9.22/src'
> :info:build make: *** [all] Error 1
> :info:build make: Leaving directory 
> `/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_x11_rxvt-unicode/rxvt-unicode/work/rxvt-unicode-9.22'
> :info:build Command failed:  cd 
> "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_x11_rxvt-unicode/rxvt-unicode/work/rxvt-unicode-9.22"
>  && /usr/bin/make -j1>
> :info:build Exit code: 2
> :error:build Failed to build rxvt-unicode: command execution failed
> :debug:build Error code: CHILDSTATUS 98834 2
> :debug:build Backtrace: command execution failed
> :debug:build while executing
> :debug:build "system {*}$notty {*}$nice $fullcmdstring"
> :debug:build invoked from within
> :debug:build "command_exec build"
> :debug:build (procedure "portbuild::build_main" line 8)
> :debug:build invoked from within
> :debug:build "$procedure $targetname"
> #===



smime.p7s
Description: S/MIME cryptographic signature

Re: Xcode 11.2 on Mojave and gcc7 or gcc9

[Christopher Jones]

> On 10 Nov 2019, at 6:33 pm, Fielding, Eric J (US 329A) via macports-users 
>  wrote:
> 
> My employer automatically installs the latest versions of MacOS software, 
> including now Xcode 11.2. I have been seeing several suggestions that we 
> should go back to Xcode 10.3, which I tried a few weeks ago when I was on 
> Xcode 11.1. That was OK and all my ports were working until they upgraded my 
> machine to Xcode 11.2. At first, there was an incompatibility between the 
> version of the Swift library from my 10.3 installation that was still in the 
> Xcode directories and the system Swift library so nothing in the compiler 
> would work. I deleted my whole Xcode.app directory and reinstalled Xcode 
> 11.2. Now that I have a clean Xcode 11.2, it does not have the 
> MacOSX10.14.sdk installed and the gcc7 and gcc9 installations from MacPorts 
> are still depending on that. I tried reinstalling the command-line tools, as 
> someone suggested yesterday, but it tells me that they are already installed.

You might need to manually force a CLT update, as its possible it is not being 
correctly updated. See

https://trac.macports.org/wiki/ProblemHotlist#reinstall-clt

>  
> I uninstalled my gcc7 port and reinstalled it to see if it would update the 
> libraries. The port install command installed the precompiled binaries that 
> are linked to the MacOSX10.14.sdk, so it won’t run correctly. Can I force 
> MacPorts to recompile gcc7 instead of using the precompiled binaries?

Yes. Use the ‘-s’ option with port.

Chris

>  
> This is the output of ‘cpp -v’ from gcc7 (it is similar if I select gcc9):
> Using built-in specs.
> COLLECT_GCC=cpp
> Target: x86_64-apple-darwin18
> Configured with: 
> /opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_lang_gcc7/gcc7/work/gcc-7.4.0/configure
>  --prefix=/opt/local --build=x86_64-apple-darwin18 
> --enable-languages=c,c++,objc,obj-c++,lto,fortran 
> --libdir=/opt/local/lib/gcc7 --includedir=/opt/local/include/gcc7 
> --infodir=/opt/local/share/info --mandir=/opt/local/share/man 
> --datarootdir=/opt/local/share/gcc-7 --with-local-prefix=/opt/local 
> --with-system-zlib --disable-nls --program-suffix=-mp-7 
> --with-gxx-include-dir=/opt/local/include/gcc7/c++/ --with-gmp=/opt/local 
> --with-mpfr=/opt/local --with-mpc=/opt/local --with-isl=/opt/local 
> --enable-stage1-checking --disable-multilib --enable-lto 
> --enable-libstdcxx-time --with-build-config=bootstrap-debug 
> --with-as=/opt/local/bin/as --with-ld=/opt/local/bin/ld 
> --with-ar=/opt/local/bin/ar --with-bugurl=https://trac.macports.org/newticket 
>  --disable-tls 
> --with-pkgversion='MacPorts gcc7 7.4.0_3' 
> --with-sysroot=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk
> Thread model: posix
> gcc version 7.4.0 (MacPorts gcc7 7.4.0_3)
> COLLECT_GCC_OPTIONS='-E' '-v' '-mmacosx-version-min=10.14.7' 
> '-asm_macosx_version_min=10.14' '-mtune=core2'
> /opt/local/libexec/gcc/x86_64-apple-darwin18/7.4.0/cc1 -E -quiet -v 
> -D__DYNAMIC__ - -fPIC -mmacosx-version-min=10.14.7 -mtune=core2
> ignoring nonexistent directory 
> "/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/opt/local/include"
> ignoring nonexistent directory 
> "/opt/local/lib/gcc7/gcc/x86_64-apple-darwin18/7.4.0/../../../../../x86_64-apple-darwin18/include"
> ignoring nonexistent directory 
> "/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/usr/include"
> ignoring nonexistent directory 
> "/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/System/Library/Frameworks"
> ignoring nonexistent directory 
> "/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/Library/Frameworks"
> #include "..." search starts here:
> #include <...> search starts here:
> /opt/local/lib/gcc7/gcc/x86_64-apple-darwin18/7.4.0/include
> /opt/local/lib/gcc7/gcc/x86_64-apple-darwin18/7.4.0/include-fixed
> End of search list.



smime.p7s
Description: S/MIME cryptographic signature

Re: ksh93

[Christopher Jones]

> Hello,
>   If you put in a ticket to https://trac.macports.org/wiki/Tickets 
>  it can be monitored.  It is up to 
> the maintainer or someone else to update.

or, even better, submit a PR with the update yourself at

https://github.com/macports/macports-ports/pulls 





smime.p7s
Description: S/MIME cryptographic signature

Re: Configuring Python3 on MacOS Macports

[Christopher Jones]

When you say " vs /usr/bin/python that does the right thing and places the 
commands in proper places “  where exactly are you referring to ? Where exactly 
do you want the macports provided python to install things to ?

> On 2 Dec 2019, at 7:50 pm, Forrest  wrote:
> 
> I'm new to Python and I'm trying to figure out why, for example, when I 
> install aws-cli (from source) using Macports, it doesn't install properly vs 
> /usr/bin/python that does the right thing and places the commands in proper 
> places.   When I run "/opt/local/bin/python setup.py install" it ends up 
> buried in directories under the Macports directory structure, which isn't 
> usable.   Maybe I am missing some ENV variables?
> 
> 
> 
> F
> 



smime.p7s
Description: S/MIME cryptographic signature

Re: Configuring Python3 on MacOS Macports

[Christopher Jones]

OK.

So when you say build from source, do you mean using MacPorts port for this, or 
are you building directly yourself (and if the later, any reason why you are 
not using the port ?)

https://github.com/macports/macports-ports/blob/master/python/py-awscli/Portfile
 
<https://github.com/macports/macports-ports/blob/master/python/py-awscli/Portfile>


> crjoberon ~ > port search awscli
> awscli_select @0.1 (python, sysutils)
> common files for selecting default awscli version
> 
> py-awscli @1.16.292 (python)
> Universal Command Line Environment for AWS.
> 
> py27-awscli @1.16.292 (python)
> Universal Command Line Environment for AWS.
> 
> py35-awscli @1.16.292 (python)
> Universal Command Line Environment for AWS.
> 
> py36-awscli @1.16.292 (python)
> Universal Command Line Environment for AWS.
> 
> py37-awscli @1.16.292 (python)
> Universal Command Line Environment for AWS.



> On 2 Dec 2019, at 8:43 pm, Forrest  ie.com> wrote:
> 
> The /usr/bin/python installs the executable into /usr/local/bin. I'd be fine 
> if the Macports installed it in /opt/local/bin -- this makes me believe there 
> is a config directive I'm missing somewhere.
> 
> 
> 
> On 12/2/19 2:38 PM, Christopher Jones wrote:
>> When you say " vs /usr/bin/python that does the right thing and places the 
>> commands in proper places “  where exactly are you referring to ? Where 
>> exactly do you want the macports provided python to install things to ?
>> 
>>> On 2 Dec 2019, at 7:50 pm, Forrest  wrote:
>>> 
>>> I'm new to Python and I'm trying to figure out why, for example, when I 
>>> install aws-cli (from source) using Macports, it doesn't install properly 
>>> vs /usr/bin/python that does the right thing and places the commands in 
>>> proper places.   When I run "/opt/local/bin/python setup.py install" it 
>>> ends up buried in directories under the Macports directory structure, which 
>>> isn't usable.   Maybe I am missing some ENV variables?
>>> 
>>> 
>>> 
>>> F
>>> 
> 



smime.p7s
Description: S/MIME cryptographic signature

Re: Configuring Python3 on MacOS Macports

[Christopher Jones]

OK, I see.

Maybe though you could learn from what the macports port does, and try and 
replicate it. Note it does install stuff to ${prefix}/bin, as you want. e.g.

> port contents py37-awscli

  /opt/local/bin/aws-3.7
  /opt/local/bin/aws.cmd-3.7
  /opt/local/bin/aws_bash_completer-3.7
  /opt/local/bin/aws_completer-3.7
  /opt/local/bin/aws_zsh_completer.sh-3.7


so you should take a look into how it achieves that.

sudo port -s -d install py37-awscli

will force a build from source, with full debug output.

Another possibility is you clone the port and make a new ‘devel’ version of it, 
that takes the nightly snapshot you want instead of the released version, but 
uses the rest of the infrastructure just the same.

Chris

> On 2 Dec 2019, at 9:11 pm, Forrest  wrote:
> 
> I have a need to run the latest GIT of the aws-cli, so while the port is 
> there, I need to be able to compile and install the nightly code updates for 
> testing.
> 
> So I am building aws-cli from the GIT repository.
> 
> 
> Thanks.
> 
> 
> On 12/2/19 3:07 PM, Christopher Jones wrote:
>> 
>> OK.
>> 
>> So when you say build from source, do you mean using MacPorts port for this, 
>> or are you building directly yourself (and if the later, any reason why you 
>> are not using the port ?)
>> 
>> https://github.com/macports/macports-ports/blob/master/python/py-awscli/Portfile
>>  
>> <https://github.com/macports/macports-ports/blob/master/python/py-awscli/Portfile>
>> 
>> 
>>> crjoberon ~ > port search awscli
>>> awscli_select @0.1 (python, sysutils)
>>> common files for selecting default awscli version
>>> 
>>> py-awscli @1.16.292 (python)
>>> Universal Command Line Environment for AWS.
>>> 
>>> py27-awscli @1.16.292 (python)
>>> Universal Command Line Environment for AWS.
>>> 
>>> py35-awscli @1.16.292 (python)
>>> Universal Command Line Environment for AWS.
>>> 
>>> py36-awscli @1.16.292 (python)
>>> Universal Command Line Environment for AWS.
>>> 
>>> py37-awscli @1.16.292 (python)
>>> Universal Command Line Environment for AWS.
>> 
>> 
>> 
>>> On 2 Dec 2019, at 8:43 pm, Forrest > 
>>> ie.com <http://ie.com/>> wrote:
>>> 
>>> The /usr/bin/python installs the executable into /usr/local/bin. I'd be 
>>> fine if the Macports installed it in /opt/local/bin -- this makes me 
>>> believe there is a config directive I'm missing somewhere.
>>> 
>>> 
>>> 
>>> On 12/2/19 2:38 PM, Christopher Jones wrote:
>>>> When you say " vs /usr/bin/python that does the right thing and places the 
>>>> commands in proper places “  where exactly are you referring to ? Where 
>>>> exactly do you want the macports provided python to install things to ?
>>>> 
>>>>> On 2 Dec 2019, at 7:50 pm, Forrest >>>> <mailto:for...@forrie.com>> wrote:
>>>>> 
>>>>> I'm new to Python and I'm trying to figure out why, for example, when I 
>>>>> install aws-cli (from source) using Macports, it doesn't install properly 
>>>>> vs /usr/bin/python that does the right thing and places the commands in 
>>>>> proper places.   When I run "/opt/local/bin/python setup.py install" it 
>>>>> ends up buried in directories under the Macports directory structure, 
>>>>> which isn't usable.   Maybe I am missing some ENV variables?
>>>>> 
>>>>> 
>>>>> 
>>>>> F
>>>>> 
>>> 
>> 
> 



smime.p7s
Description: S/MIME cryptographic signature

Re: Git question

[Christopher Jones]

> On 10 Jan 2020, at 9:34 am, Gerben Wierda  wrote:
> 
> OK. I'm back in git hell (suggestions made on this list, tips on 
> stackexchange, git documentation, nothing gives me the answer)
> 
> I have 
> albus:macports-ports sysbh$ git remote -v
> local https://github.com/gctwnl/macports-ports.git 
>  (fetch)
> local https://github.com/gctwnl/macports-ports.git 
>  (push)
> originhttps://github.com/macports/macports-ports.git 
>  (fetch)
> originhttps://github.com/macports/macports-ports.git 
>  (push)
> 
> So, my clone is ‘local’, the upstream repository is ‘origin’ (some 
> instructions tend to call this ‘upstream’, others ‘origin’, there seem to be 
> two ’sops’ on this in gitland. I think now that using ‘upstream’ is the 
> better choice as git defaults to ‘origin’ when no argument is given. So, I 
> need to rename too. But first let’s see if I can get this thing working in 
> the first place).
> 
> If I produce a pull request and I’m rebuffed because of an error I make, I 
> need to go back to testate of the official repository before proceeding 
> again. At such a point my own clone is both commits ahead and commits behind 
> the official repository. I need to lose my commits (as I am rebuffed by 
> macports maintainers if I have multiple ‘working’ commits in my pull 
> request). So, I need to reset my clone to the current state of the official 
> repository.
> 
> So, my clone is now two commits ahead of the official macports repository and 
> 343 commits behind. I need to reset my clone to be the same as the official 
> repository. The result of which is:
> 
> albus:macports-ports sysbh$ git fetch origin
> albus:macports-ports sysbh$ git reset --hard origin/master
> HEAD is now at dfb14de3eb5 pypy*-tkinter: ensure UsingTheRightCompiler
> albus:macports-ports sysbh$ git push
> Username for 'https://github.com':  
> gerben.wie...@rna.nl 
> Password for 'https://gerben.wie...@rna.nl@github.com': 
>  
> To https://github.com/gctwnl/macports-ports.git 
> 
>  ! [rejected]master -> master (non-fast-forward)
> error: failed to push some refs to 
> 'https://github.com/gctwnl/macports-ports.git 
> '
> hint: Updates were rejected because the tip of your current branch is behind
> hint: its remote counterpart. Integrate the remote changes (e.g.
> hint: 'git pull ...') before pushing again.
> hint: See the 'Note about fast-forwards' in 'git push --help' for details.
> 
> I don’t want to “Integrate the remote changes”, I want to lose them. How??


In this case because you changed history in your local master branch (by 
resetting) you need to force push

git push —force local master

> 
> G
> 
>> On 10 Jan 2020, at 08:57, Michael > > wrote:
>> 
>> 
>> On 2020-01-09, at 2:33 PM, Steven Smith > > wrote:
>> 
>>> Me too. We’re discussing MacPorts-relevant git commands in 
>>> https://github.com/macports/macports-ports/pull/6106 
>>>  .
>>> 
>>> Easiest, most destructive to local:
>>> 
>>> # save all local files changed outside the git repo
>>> 
>>> git fetch --all
>>> git reset --hard upstream/master
>>> 
>>> # restore all local files
>> 
>> I'm sorry, I just have to follow up with this xkcd ...
>> 
>> https://xkcd.com/1597/ 
>> 
> 



smime.p7s
Description: S/MIME cryptographic signature

Re: Test in local repository without privileges

[Christopher Jones]

Hi,

I might be wrong, but I do not believe it is possible to temporarily change the 
install prefix, for a single port.

Most probably you will need to start a new installation, using a custom 
installation prefix, from scratch. see

https://www.macports.org/install.php#source 


on installing from source, which you will need to do to change the installation 
prefix, as its a configure time option.

Chris

> On 17 Jan 2020, at 9:33 pm, Dave Allured - NOAA Affiliate via macports-users 
>  wrote:
> 
> I am on a corporate network with ports installed normally in /opt/local, 
> controlled by system admins.  Users do not have any write access into system 
> directories.  I would like to use a local portfile repository in user space, 
> as described in Macports guide 4.6.
> 
> How can I test ports in the local repository?  The "portindex" command works 
> as expected in this directory.  However, "port install" fails with 
> "Insufficient privileges to write to MacPorts install prefix".  I need a way 
> to tell "port install" to use a local prefix, rather than the default system 
> prefix, for only the port under test.
> 
> I figured that I could avoid tampering with the protected sources.conf, by 
> manually pre-staging the desired distfiles in the local repository.  Here is 
> my embryonic directory structure:
> 
> $HOME/portx/science/netcdf-fortran/Portfile
> $HOME/portx/science/netcdf-fortran/files/patch-Makefile.in.diff
> $HOME/portx/var/macports/distfiles/netcdf-fortran/netcdf-fortran-4.5.2.tar.gz
> 
> Thank you for any advice.



smime.p7s
Description: S/MIME cryptographic signature

Re: Test in local repository without privileges

[Christopher Jones]

> On 17 Jan 2020, at 10:36 pm, Dave Allured - NOAA Affiliate via macports-users 
>  wrote:
> 
> Chris, thanks for the quick reply.  You are correct, a private macports 
> installation would enable testing ports without special privilege.  Actually 
> I have already done this many times for testing and debugging other cases.
> 
> However, I would like to find an intermediate solution that avoids full 
> build-up from sources.  My main reasons are (1) test sensitivity to installed 
> ports in the system prefix; (2) save time and effort; and (3) be able to 
> provide compact, uncomplicated reproducers to third parties.
> 
> If not currently possible, it would be nice to have a new feature to enable 
> local repository testing, with fallback to the system prefix for everything 
> not found in the local repository.

What you are asking for is I am afraid really not possible, I suspect. The 
installation prefix is a fundamental parameter in most port builds. Many 
directly use this via the ${prefix} variable, which is a single valued path. 
What you are asking for is for a port use to use one location for some ports 
and a second one from others. I just don’t see how that could work.

I think your only option is really to go with a second installation using a 
custom prefix.

Chris

> 
> 
> On Fri, Jan 17, 2020 at 3:09 PM Christopher Jones  <mailto:jon...@hep.phy.cam.ac.uk>> wrote:
> Hi,
> 
> I might be wrong, but I do not believe it is possible to temporarily change 
> the install prefix, for a single port.
> 
> Most probably you will need to start a new installation, using a custom 
> installation prefix, from scratch. see
> 
> https://www.macports.org/install.php#source 
> <https://www.macports.org/install.php#source>
> 
> on installing from source, which you will need to do to change the 
> installation prefix, as its a configure time option.
> 
> Chris
> 
>> On 17 Jan 2020, at 9:33 pm, Dave Allured - NOAA Affiliate via macports-users 
>> > <mailto:macports-users@lists.macports.org>> wrote:
>> 
>> I am on a corporate network with ports installed normally in /opt/local, 
>> controlled by system admins.  Users do not have any write access into system 
>> directories.  I would like to use a local portfile repository in user space, 
>> as described in Macports guide 4.6.
>> 
>> How can I test ports in the local repository?  The "portindex" command works 
>> as expected in this directory.  However, "port install" fails with 
>> "Insufficient privileges to write to MacPorts install prefix".  I need a way 
>> to tell "port install" to use a local prefix, rather than the default system 
>> prefix, for only the port under test.
>> 
>> I figured that I could avoid tampering with the protected sources.conf, by 
>> manually pre-staging the desired distfiles in the local repository.  Here is 
>> my embryonic directory structure:
>> 
>> $HOME/portx/science/netcdf-fortran/Portfile
>> $HOME/portx/science/netcdf-fortran/files/patch-Makefile.in.diff
>> $HOME/portx/var/macports/distfiles/netcdf-fortran/netcdf-fortran-4.5.2.tar.gz
>> 
>> Thank you for any advice.



smime.p7s
Description: S/MIME cryptographic signature

Re: Dependency untangling riddle

[Christopher Jones]

 > port rdeps LyX
The following ports are dependencies of LyX @2.3.3_1+python27+qt5:
  xz
libiconv
  gperf
gettext
  ncurses
  bison
bison-runtime
m4
  gawk
  cctools
libunwind-headers
llvm-9.0
  cmake
libcxx
curl
  pkgconfig
  libidn2
autoconf
automake
libtool
  xattr
unzip
libunistring
  perl5
perl5.28
  db48
  gdbm
readline
  texinfo
help2man
  p5.28-locale-gettext
  libpsl
python37
  bzip2
  expat
  libedit
  libffi
  openssl
zlib
  sqlite3
  python_select
  python3_select
glib2
  libxml2
icu
  pcre
  curl-ca-bundle
libarchive
  lzo2
  lz4
  zstd
libuv
  xar
  llvm_select
  python27
python2_select
  enchant
  texlive
texlive-basic
  texlive-common
  texlive-bin
fontconfig
  freetype
libpng
  ossp-uuid
libzzip
cairo
  libpixman
  xrender
xorg-libX11
  xorg-xtrans
  xorg-xorgproto
  xorg-util-macros
  xorg-libXdmcp
  xorg-libXau
  xorg-libxcb
xorg-xcb-proto
xorg-libpthread-stubs
  xorg-libXext
  xorg-xcb-util
graphite2
  fonttools
py37-setuptools
py37-brotli
harfbuzz
harfbuzz-icu
libpaper
gmp
mpfr
potrace
xorg-libXp
xpm
  xorg-libXt
xorg-libsm
  xorg-libice
xorg-libXaw
  groff
ghostscript
  jbig2dec
  jpeg
  libidn
  tiff
  lcms2
psutils
netpbm
  jasper
  jbigkit
  libnetpbm
  xorg-libXmu
xorg-libXi
  xorg-libXfixes
texlive-bin-extra
  latexmk
texlive-latex
  detex
  latexdiff
p5.28-algorithm-diff
  pdfjam
texlive-latex-recommended
  pgf
  dvipng
gd2
  webp
giflib
t1lib
  dvisvgm
asciidoc
  docbook-xml-4.5
xmlcatmgr
  fop
  libxslt
brotli
woff2
texlive-context
  texlive-metapost
  texlive-xetex
texlive-plain-generic
  texlive-fonts-recommended
  texlive-math-science
texlive-fontutils
  lcdf-typetools
  ps2eps
  t1utils
texlive-lang-czechslovak
texlive-lang-english
texlive-lang-european
texlive-lang-french
texlive-lang-german
texlive-lang-italian
texlive-lang-polish
texlive-lang-portuguese
texlive-lang-spanish
texlive-luatex
  ImageMagick
djvulibre
  librsvg
rust
cargo
  cargo-bootstrap
  libssh2
pango
  fribidi
  gobject-introspection
autoconf-archive
py37-mako
  py37-beaker
  py37-markupsafe
py37-pytest
  py37-setuptools_scm
  py37-py
  py37-packaging
py37-attrs
  py37-hypothesis
py37-sortedcontainers
  py37-six
  py37-zopeinterface
py37-parsing
  py37-more-itertools
  py37-atomicwrites
  py37-pluggy
py37-importlib-metadata
  py37-zipp
py37-toml
  py37-wcwidth
  pytest_select
py37-markdown
  Xft2
libcroco
gdk-pixbuf2
  shared-mime-info
intltool
  gnome-common
  p5.28-getopt-long
  p5.28-pathtools
  p5.28-scalar-list-utils
  p5.28-xml-parser
p5.28-libwww-perl
  p5.28-test-fatal
p5.28-try-tiny
  p5.28-capture-tiny
  p5.28-sub-name
p5.28-devel-checkbin
  p5.28-extutils-makemaker
p5.28-cpan-meta-requirements
p5.28-extutils-manifest
  p5.28-test-leaktrace
  p5.28-test-needs
  p5.28-test-requiresinternet
  p5.28-data-dump
  p5.28-encode-locale
  p5.28-file-listing
p5.28-http-date
  p5.28

Re: Dependency untangling riddle

[Christopher Jones]

> On 5 Feb 2020, at 6:19 pm, Ryan Schmidt  wrote:
> 
> 
> 
> On Feb 5, 2020, at 11:48, Vincent Habchi wrote:
> 
>> this time, I have another interesting quandary. When I try to install LyX, I 
>> get this message:
>> 
>> —
>> Air > sudo port install LyX +python38
>> --->  Computing dependencies for LyX
>> The following dependencies will be installed: 
>> […]
>> py37-beaker
>> py37-mako
>> py37-markdown
>> py37-markupsafe
>> py37-setuptools
>> python37
>> […]
>> Continue? [Y/n]: 
>> —
>> 
>> So basically I have a long list of dependents to install, one (or more) of 
>> which itself/themselves depend(s) on python 3.7, at least in its/their 
>> default version(s). Since I don’t want to have python3.7 installed alongside 
>> python3.8, how can I find out (easily) which port(s) in the list is/are 
>> requiring python37?
> 
> Just let MacPorts install what it wants to and the port should work. It is 
> normal for ports to have dependencies on things that you don't otherwise wish 
> to use yourself. That is ok.
> 
> For some reason many port maintainers are selecting python37 when they need a 
> python3. I wish they would use the latest stable version, python38, instead.

The problem of course is a number of ports probably have not been touched since 
when python37 *was* the latest stable version. The issue really is we don’t 
have a good way to dump all ports in one going when our definition of the 
‘latest stable' version is bumped ...



smime.p7s
Description: S/MIME cryptographic signature

Re: Dependency untangling riddle

[Christopher Jones]

> On 5 Feb 2020, at 6:35 pm, Ryan Schmidt  wrote:
> 
> 
> 
> On Feb 5, 2020, at 12:34, Christopher Jones wrote:
> 
>> On 5 Feb 2020, at 6:19 pm, Ryan Schmidt wrote:
>> 
>>> On Feb 5, 2020, at 11:48, Vincent Habchi wrote:
>>> 
>>>> this time, I have another interesting quandary. When I try to install LyX, 
>>>> I get this message:
>>>> 
>>>> —
>>>> Air > sudo port install LyX +python38
>>>> --->  Computing dependencies for LyX
>>>> The following dependencies will be installed: 
>>>> […]
>>>> py37-beaker
>>>> py37-mako
>>>> py37-markdown
>>>> py37-markupsafe
>>>> py37-setuptools
>>>> python37
>>>> […]
>>>> Continue? [Y/n]: 
>>>> —
>>>> 
>>>> So basically I have a long list of dependents to install, one (or more) of 
>>>> which itself/themselves depend(s) on python 3.7, at least in its/their 
>>>> default version(s). Since I don’t want to have python3.7 installed 
>>>> alongside python3.8, how can I find out (easily) which port(s) in the list 
>>>> is/are requiring python37?
>>> 
>>> Just let MacPorts install what it wants to and the port should work. It is 
>>> normal for ports to have dependencies on things that you don't otherwise 
>>> wish to use yourself. That is ok.
>>> 
>>> For some reason many port maintainers are selecting python37 when they need 
>>> a python3. I wish they would use the latest stable version, python38, 
>>> instead.
>> 
>> The problem of course is a number of ports probably have not been touched 
>> since when python37 *was* the latest stable version. The issue really is we 
>> don’t have a good way to dump all ports in one going when our definition of 
>> the ‘latest stable' version is bumped ...
> 
> Yes that is part of the problem but I have also seen plenty of commits since 
> python38 became stable in which python37 was still preferred and I don't know 
> why people are doing that.

I suspect in most cases those committing the changes simply don’t think about 
updating the version. 

smime.p7s
Description: S/MIME cryptographic signature

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

[Christopher Jones]

Have you told macports to use your git clone ?

i.e. 

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

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

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

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

> sudo port sync

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

Chris

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



smime.p7s
Description: S/MIME cryptographic signature

Re: catalena

[Christopher Jones]

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

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

Chris

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



smime.p7s
Description: S/MIME cryptographic signature

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

[Christopher Jones]

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

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

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

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

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

generally works fine.

run with

> sudo port -d sync

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

Chris

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



smime.p7s
Description: S/MIME cryptographic signature

Re: macports-users Digest, Vol 163, Issue 12

[Christopher Jones]

> On 17 Mar 2020, at 3:04 pm, Murray Eisenberg  
> wrote:
> 
> I did that: used mode 755 for directories, mode 644 for files there. 
> 
> Still, same error Unable to execute port: Could not open file: 
> /Users/murray/macports/myports/kde/okular/Portfile
> 
> Did you get this to work with your own version of a port already included in 
> MacPorts?

Yes. My primary (only) ports tree is a clone of the git repo. in a 
sub-directory of my home area.

Oberon ~/Projects > ls -lth 
total 0
drwxr-xr-x   8 chris  staff   256B  8 Oct 22:01 MacPorts


Oberon ~/Projects > cd MacPorts 

Oberon ~/Projects/MacPorts > ls -lth
total 0
drwxr-xr-x  64 chris  staff   2.0K 17 Mar 14:42 ports
drwxr-xr-x  30 chris  staff   960B 10 Oct 10:09 base
drwxr-xr-x   5 chris  staff   160B  8 Oct 22:03 info
drwxr-xr-x  12 chris  staff   384B 11 Aug  2019 legacy-support
drwxr-xr-x  10 chris  staff   320B 15 Nov  2018 guide

Oberon ~/Projects/MacPorts > ls -lth ports/science/root6/Portfile 
-rw-r--r--  1 chris  staff23K 17 Mar 14:43 ports/science/root6/Portfile

Oberon ~/Projects/MacPorts > cat /opt/local/etc/macports/sources.conf
# MacPorts system-wide configuration file for ports tree sources.

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


Works just fine. e.g.

Oberon ~/Projects/MacPorts > sudo port -d sync
DEBUG: Copying /Users/chris/Library/Preferences/com.apple.dt.Xcode.plist to 
/opt/local/var/macports/home/Library/Preferences
--->  Updating the ports tree
Synchronizing local ports tree from file:///Users/chris/Projects/MacPorts/ports
DEBUG: euid/egid changed to: 501/20, env: HOME=/Users/chris 
SSH_AUTH_SOCK=/private/tmp/com.apple.launchd.tBWSQExnkO/Listeners
DEBUG: /opt/local/bin/git pull --rebase --autostash
DEBUG: system -W /Users/chris/Projects/MacPorts/ports: /opt/local/bin/git pull 
--rebase --autostash
Created autostash: f6afbb3fb96
Current branch master is up to date.
Applied autostash.
DEBUG: euid/egid restored to: 0/0, env restored
DEBUG: system: /opt/local/bin/portindex /Users/chris/Projects/MacPorts/ports
Creating port index in /Users/chris/Projects/MacPorts/ports
Adding port science/root6

Total number of ports parsed:   1 
Ports successfully parsed:  1 
Ports failed:   0 
Up-to-date ports skipped:   23266

I can edit, maintain, interact with git,  the ports under 
~/Projects/Macports/ports using my regular user account, no sudo required.

Oberon ~/Projects/MacPorts/ports > git status
On branch master
Your branch is up to date with 'origin/master'.

Changes not staged for commit:
  (use "git add ..." to update what will be committed)
  (use "git restore ..." to discard changes in working directory)
modified:   science/root6/Portfile

no changes added to commit (use "git add" and/or "git commit -a")

> 
>> On16 Mar 2020 21:13:58 +0100,Pieter van Oostrum > > wrote:
>> 
>> Subject: Re: installing patched okular: cannot open Portfile
>> 
>> Ken Cunningham > > writes:
>> 
>>>gives error:
>>> 
>>>Unable to execute port: Could not open file: 
>>> /Users/murray/macports/myports/kde/okular/Portfile
>>> 
>>>Could it still be a permissions or ownership issue?
>>> 
>>> It is a permissions error. Although Chris and others seem to make this 
>>> work, it has never worked
>>> for me to put a macports repo in my home folder. I don’t know why, and I 
>>> gave up trying to fix it.
>>> 
>>> Just put it in /Users/Shared/MacPorts or, what I do, is put them all in 
>>> /opt (but then you have to
>>> be careful with sudo, which I always am).
>>> 
>> Very strange. I have been using this construction for years. I have all my 
>> directories in my private repository with mode 755, and the files 644.
>> -- 
>> Pieter van Oostrum
> 
> ---
> Murray Eisenberg  murrayeisenb...@gmail.com 
> 
> 503 King Farm Blvd #101   Home (240)-246-7240
> Rockville, MD 20850-6667  Mobile (413)-427-5334
> 
> 



smime.p7s
Description: S/MIME cryptographic signature

Re: installing patched okular: cannot open Portfile

[Christopher Jones]

> On 17 Mar 2020, at 6:11 pm, Ryan Schmidt  wrote:
> 
> 
> 
> On Mar 16, 2020, at 14:53, Ken Cunningham wrote:
> 
>> It is a permissions error. Although Chris and others seem to make this work, 
>> it has never worked for me to put a macports repo in my home folder. I don’t 
>> know why, and I gave up trying to fix it.
>> 
>> Just put it in /Users/Shared/MacPorts or, what I do, is put them all in /opt 
>> (but then you have to be careful with sudo, which I always am).
> 
> As far as I remember, this is the correct answer. The macports user (and any 
> user other than you) cannot read the contents of your home directory. So your 
> options are to either put the new ports tree outside of your home directory, 
> or else modify the permissions of your home directory to allow other users to 
> read its contents. The latter may be fine if you are the only user of your 
> computer but is not recommended if you share your computer with other users 
> who have their own accounts.

Its not necessary to give other users read access to your entire home area.

You just need to create a directory, give that read access, and then clone the 
git ports tree into that. Allowing other users to read *only* the ports git 
tree does not seem to me a security issue.

In fact, at least on my 10.15 machine I don’t need to give the new directory 
any new permissions, the defaults are exactly what I posted in my other mail. 
e.g.

Oberon ~ > mkdir ~/MPTest
Oberon ~ > ls -l

drwxr-xr-x   2 chris  staff64 17 Mar 18:36 MPTest


This tallies with what I recall setting up numerous MP installations in this 
way, as I do not recall ever having to set permissions of these sub-dirs to 
make it work. 

Chris

smime.p7s
Description: S/MIME cryptographic signature

Re: Is SSL really a dependant of everything?

[Christopher Jones]

> On 6 Apr 2020, at 8:42 am, Dave Horsfall  wrote:
> 
> On Mon, 6 Apr 2020, Ryan Schmidt wrote:
> 
>> You should not routinely use the -p flag like this.
> 
> I did that following advice on this list about a year ago, when some port 
> ("guile"?) that I'd never even heard of would not build.
> 
>> Do you mean openssl? or libressl? or something else?
> 
> openssl-1.1.1f_0+universal.darwin_16.i386-x86_64

So from the above you can tell you are using the universal variant of the 
package.

Looking at

http://packages.macports.org/openssl/

you can see these variants used to be built by the buildbots and thus 
distributed in binary form, however this appears to have stopped for the more 
recent versions. This is why you had to build it from source, and likely why 
you are having to build a lot of dependencies from source.

Why this was done, intentionally or otherwise, I do not know.

Chris

> All the same to me, and I don't touch any config files except under advice 
> (such as using Australian repositories etc); when it comes to the Mac I'm 
> just a dumb end-user (except for the Unix-like bits, in which case not many 
> people can match me...).
> 
> I'm about to go to bed (been a long day for me, and not because of this) so 
> I'll likely not reply in turn right away; yawn...
> 
> Current CPU temp is 81˚ C (I could have boiled an egg on the older MacBook by 
> now; this one has much better cooling).
> 
> -- Dave



smime.p7s
Description: S/MIME cryptographic signature

Re: Python 3.8.2 - Macports configuration problem

[Christopher Jones]

> On 1 May 2020, at 9:17 am, Dr M J Carter  
> wrote:
> 
> On Thu, Apr 30, 2020 at 11:13:45PM +0200, Max Anglad wrote:
> 
>> Note that pip (python package installer) must apparently be used via
>> sudo if you want the packages to be installed in the right place
>> (/opt/local/Library/Frameworks/Python.framework/Versions/3.8/lib/python3.8/site-packages)
> 
> That'll break Python and/or MacPorts: consider if one of the Python
> packages in MacPorts gets updated, or if you happen to later install a
> MacPorts port which pulls in a Python package which conflicts with one
> you've hand-installed.  There's better ways to layer your own packages
> on top of a Python installation without using sudo, of which setting
> up a virtual Python under your home directory is the newest and most
> highly recommended.  A web search for "virtual python" should be most
> fruitful.

I completely second the above. Do not use pip to install into the MacPorts 
prefix, you will run into a lot of problems doing this.

In addition to the virtual env. approach, also note macports has its own ports 
for most of the commonly used python packages. Just run

> port search py38-

to list them. Its quite probable that all you need is available in macports 
already.

Chris

> 
> Apologies if I come across as strident: I've seen the same mistakes
> being made by postgrads for entirely too long, and this bear trap in
> particular seems to claim more of them than most.  Good luck in your
> Python endeavours.
> 
> -- 
> Dr Martin J Carter
> Computer System Administrator (WFH)
> Astrophysics, University of Oxford



smime.p7s
Description: S/MIME cryptographic signature

Re: Python 3.8.2 - Macports configuration problem

[Christopher Jones]

> On 1 May 2020, at 12:52 pm, Max Anglad  wrote:
> 
>> 
>> On 1 May 2020 at 10:28, Christopher Jones  wrote :
>> 
>>> On 1 May 2020, at 9:17 am, Dr M J Carter  
>>> wrote:
>>> 
>>> On Thu, Apr 30, 2020 at 11:13:45PM +0200, Max Anglad wrote:
>>> 
>>>> Note that pip (python package installer) must apparently be used via
>>>> sudo if you want the packages to be installed in the right place
>>>> (/opt/local/Library/Frameworks/Python.framework/Versions/3.8/lib/python3.8/site-packages)
>>> 
>>> That'll break Python and/or MacPorts: consider if one of the Python
>>> packages in MacPorts gets updated, or if you happen to later install a
>>> MacPorts port which pulls in a Python package which conflicts with one
>>> you've hand-installed.  
> 
> Ok, I understand,  and I didn't realize that most of the Python packages had 
> also been "Macported".
> 
> (Note that I only use standard Python packages like matplotlib, scipy, 
> pandas, jupyter,...)
> 
> But I see that there is however a port of the pip installer : 
> https://ports.macports.org/port/py38-pip/summary 
> <https://ports.macports.org/port/py38-pip/summary>
> 
> Do you also advise against using it ? Does it not install Macported Python 
> packages in the right place ?

As an end user you should not use pip, any version of it, to install packages 
directly into the MacPorts prefix. period.

As previously noted, you can though use it for instance inside a virtual env. 
that is just fine.

( Also, the macports pip package is also there to help certain macports ports 
internally on how they build themselves, and install into the macports prefix. )

Chris

> 
> I find that documentation is missing on the correct way to use Python and its 
> packages via Macports, or I did not find it
> 
> 
>> I completely second the above. Do not use pip to install into the MacPorts 
>> prefix, you will run into a lot of problems doing this.
>> 
>> In addition to the virtual env. approach, also note macports has its own 
>> ports for most of the commonly used python packages. Just run port search 
>> py38-
>> 
>> to list them. Its quite probable that all you need is available in macports 
>> already.
>> 
>> Chris
> 
> Ok, but these Macported packages I install them with py38-pip (python3 -m pip 
> install ) 
> or conventionally with : sudo port install  ?
> 
> 
>>> Apologies if I come across as strident: I've seen the same mistakes
>>> being made by postgrads for entirely too long, and this bear trap in
>>> particular seems to claim more of them than most.  Good luck in your
>>> Python endeavours.
> 
> In software development I have a long experience in C/C++ and shells under 
> Unix, but I am still a beginner in Python and its mechanisms
> 
> Thank you all for your valuable advice.



smime.p7s
Description: S/MIME cryptographic signature