On Jun 26, 2018, at 07:32, Ubence Quevedo wrote:
> Ubences-MacBook-Pro:ata uquevedo$ smartctl -t long /dev/disk2
> smartctl 6.6 2017-11-05 r4594 [Darwin 17.6.0 x86_64] (local build)
> Copyright (C) 2002-17, Bruce Allen, Christian Franke, www.smartmontools.org
>
> === START OF OFFLINE IMMEDIATE
On Jun 26, 2018, at 10:07, Langer, Stephen A. (Fed) wrote:
> That's what I don't understand. When not using MacPorts, we use
> install_name_tool to fix the libraries. They're built in
> $HOME/project/build/{lib, include, etc} and moved to $PREFIX /{lib, include,
> etc}, at which point
On 2018-6-27 01:07 , Langer, Stephen A. (Fed) wrote:
> That's what I don't understand. When not using MacPorts, we use
> install_name_tool to fix the libraries. They're built in
> $HOME/project/build/{lib, include, etc} and moved to $PREFIX /{lib, include,
> etc}, at which point
Hi Ryan!
On 2018-06-25 21:25:02 +0200 Ryan Schmidt
wrote:
I suppose python is acting up, since this always worked.
Can you tell if it is core python or some modules acting up?
While not all packages I have are up-to-date since I have some
issues to
fix, all python modules look to be
On 6/25/18, 8:42 PM, "Joshua Root" wrote:
> I still have at least one problem. We had to extend distutils so that it
builds a few .dylib shared libraries that are linked to by the more standardly
built python extension modules, which are all .so bundles. All of them are
being
Hi,
This is not a pure MacPorts issue, as I'm doing the build manually and not
through MacPorts, but I'm guessing that maybe you experienced this very
same issue in recent LLVM versions, or that maybe you'll face it when you
update to 6.0.1 (not released yet, but I'm trying release candidate #3,
Curses, I was really hoping to leverage that feature since a three and a half
hour long test is not ideal [below test started at 5:22AM]:
Ubences-MacBook-Pro:ata uquevedo$ smartctl -t long /dev/disk2
smartctl 6.6 2017-11-05 r4594 [Darwin 17.6.0 x86_64] (local build)
Copyright (C) 2002-17, Bruce
