On Apr 18, 2018, at 23:42, Ryan Schmidt wrote:
> Thanks. I think this problem was introduced by a presumably unintentional
> part of this commit:
>
> https://github.com/macports/macports-ports/commit/e3710d6800e803ebaa9528d3bdb38fb2fcade513#diff-5513a677784c8c1520463fedf268a37f
>
> I think
Thanks. I think this problem was introduced by a presumably unintentional part
of this commit:
https://github.com/macports/macports-ports/commit/e3710d6800e803ebaa9528d3bdb38fb2fcade513#diff-5513a677784c8c1520463fedf268a37f
I think that needs to be reverted, and the tk port's revision increased
Hello, I also had tk as a sticking point in my last run of "upgrade
outdated" (after selfupdate to 2.4.3). It came very near the end of
updating everything so I succumbed to temptation and forced it with -f. I
haven't noticed anything going terribly wrong yet, but "tk contents" does
show the X11
Ryan,
I removed explicit tk installation from the myport.txt list, uninstalled tk and
restarted restore_ports.tcl myport.txt and all went through nicely.
Tk has been reinstalled as requested from python ports as dependent port. And
in that case, it does not contain explicitly X.h and other such
later fail because everything has been erased ?
> Or did it fail because I run XEmacs (from opt/local/bin/xemacs) in parallel ?
You should not force the activation.
Since we don't yet know why this problem happened for you, uninstalling and
reinstalling MacPorts again might result i
Due to the numerous failures I had in my upgrade outdated followed by failure
to install py36-jupyter, py36-spyder and py36-gnureadline, I decided to
uninstall Macports following the ”migration” webpage which ends up with :
curl --location --remote-name
