Re: macpro burning through hard drives -- ? video card pulling too much power?

[Dave Horsfall]

On Tue, 8 Jan 2019, Ken Cunningham wrote:


Thanks to everyone for your comments, online and offline.


Not a problem - we're all here to help each other :-)

Consensus seems to be that this was a 1/100 x 1/100 x 1/100 coincidence 
rather than a power issue.


Yep; as one with an electronics background, I simply cannot envisage how 
that would happen, unless you has a really Really REALLY dud device.  The 
only other possibility is that your PS spiked under the load, and did not 
crow-bar[*] in time.


Doesn't even have to be 12 volts either; 5 volts on a 3.3 rail will kill 
anything on it, unless they're protected (hint: cheap devices are cheap 
for a reason; there is some really dangerous mains-powered stuff coming 
out of China, for example, that simply would not pass Australian laws, but 
the appropriate logos are easy to print, such as the CE-tick).


I have ordered four more USB 4TB backup external hard drives. I believe 
I will go with all SSD internal drives from now on.


I'm still not comfortable with SSDs that cannot tell you their health 
status until they finally run out of spare blocks...


What's the state of the art here?  Until SSDs report their health in a 
SMART way, I think I'll stick with spinning rust and put up with the seek 
and rotational delays (and the odd head-crash - not very pretty, as that 
was a poor time to find out that my supplier-supplied backup software 
wasn't working).


[*]
Crow-bar protection?  It means pretty much what it implies: if the PS goes 
over-voltage then you get the equivalent of dropping a crow-bar across its 
output rails (and you then hope that the fuse blows first before the Zener 
diode does)...


-- Dave

Re: macpro burning through hard drives -- ? video card pulling too much power?

[Ken Cunningham]

Thanks to everyone for your comments, online and offline.

Consensus seems to be that this was a 1/100 x 1/100 x 1/100 coincidence rather 
than a power issue.

I have ordered four more USB 4TB backup external hard drives. I believe I will 
go with all SSD internal drives from now on.

I’m not getting caught like this again…

Best,

Ken

Re: gdb

[James Linder]

> On 9 Jan 2019, at 12:48 am, Ken Cunningham  
> wrote:
> 
> fyi
> 
> I updated gdb last night, to the current version.
> 
> so it might be worth trying again
> 
> gdb and lldb are both good debuggers, but they are different, and it takes a 
> while to get facile with either.
> 
> K
> 
> 
> On 2019-01-08, at 6:34 AM, Ryan Schmidt wrote:
> 
>> I don't know why gdb isn't working for you. From what I've been able to 
>> find, it should be able to debug programs built by clang.
>> 
>> But have you considered trying lldb instead?

I suspect the codesign but I am confused:

I am using 10.13.6 and have seen the warnings that 8.1 is not compatable, is 
8.2 ok?

[Haycorn] /Users/jam [517]% sudo codesign -s gdb-cert /opt/local/bin/ggdb
Password:
/opt/local/bin/ggdb: is already signed


[Haycorn] /Users/jam [518]% ggdb a.out
GNU gdb (GDB) 8.2.1
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-apple-darwin17.7.0".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from a.out...Reading symbols from 
/Users/jam/a.out.dSYM/Contents/Resources/DWARF/a.out...done.
done.
(gdb) l
1   #include 
2   int main ()
3   {
4   printf ("Hello world\n");
5   }
(gdb) r
Starting program: /Users/jam/a.out
Unable to find Mach task port for process-id 771: (os/kern) failure (0x5).
 (please check gdb is codesigned - see taskgated(8))

James

PS Ryan I will use lldb as a last resort, but baby-duck symdrome does rear it’s 
head. Thanks.

Re: gdb

[Ken Cunningham]

fyi

I updated gdb last night, to the current version.

so it might be worth trying again

gdb and lldb are both good debuggers, but they are different, and it takes a 
while to get facile with either.

K


On 2019-01-08, at 6:34 AM, Ryan Schmidt wrote:

> I don't know why gdb isn't working for you. From what I've been able to find, 
> it should be able to debug programs built by clang.
> 
> But have you considered trying lldb instead?
> 

Re: Gimp crashes when loading png or jpg

[Piet van Oostrum]

Ryan Schmidt wrote:

 > On Dec 31, 2018, at 14:11, Piet van Oostrum wrote:
 > 
 > > Suddenly my gimp crashes when I try to load a PNG or JPG file. It gives 
 > > the error message:
 > > Plug-in crashed: "file-png"
 > > (/Applications/MacPorts/GIMP.app/Contents/Resources/lib/gimp/2.0/plug-ins/file-png/file-png)
 > > 
 > > Plug-in crashed: "file-jpeg"
 > > (/Applications/MacPorts/GIMP.app/Contents/Resources/lib/gimp/2.0/plug-ins/file-jpeg/file-jpeg)
 > > 
 > > This is gimp @2.10.8_0+animation+quartz and gimp2 
 > > @2.10.8_2+python27+quartz on MacOS High Sierra.
 > > I upgraded on 26 december and before that it worked. I also uninstalled 
 > > and reinstalled both gim and gimp2 from source but that did not help.
 > > 
 > > Is this a known issue?
 > 
 > I'm not sure. Did something actually crash? If so, a log should have been 
 > left behind in ~/Library/Logs/DiagnosticReports; if so, showing us that 
 > logfile might help us diagnose the issue.

I found this today:

https://trac.macports.org/ticket/57842

-- 
Piet van Oostrum 
WWW: http://piet.vanoostrum.org/
PGP key: [8DAE142BE17999C4]

Re: gdb

[Mojca Miklavec]

Dear James,

On Sun, 6 Jan 2019 at 01:39, James Linder wrote:
>
> /Applications/Xcode.app/Contents/Developer/usr/bin/make -f Makefile all
> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang++
>  -c -pipe -stdlib=libc++ -g -std=gnu++11  -arch x86_64 -isysroot 
> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk
>  -mmacosx-version-min=10.12 -Wall -W -fPIC -DQT_DEPRECATED_WARNINGS 
> -DQT_GUI_LIB -DQT_CORE_LIB -I. -I. 
> -I/opt/Qt5.12.0/5.12.0/clang_64/lib/QtGui.framework/Headers 
> -I/opt/Qt5.12.0/5.12.0/clang_64/lib/QtCore.framework/Headers -I. 
> -I/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk/System/Library/Frameworks/OpenGL.framework/Headers
>  
> -I/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk/System/Library/Frameworks/AGL.framework/Headers
>  -I/opt/Qt5.12.0/5.12.0/clang_64/mkspecs/macx-clang 
> -F/opt/Qt5.12.0/5.12.0/clang_64/lib -o main.o main.cpp
>
>
> [Haycorn] /Users/jam/nodups [511]% lldb nodups.app/Contents/MacOS/nodups
> (lldb) target create "nodups.app/Contents/MacOS/nodups"
> warning: (x86_64) 
> /Users/jam/nodups/nodups.app/Contents/Frameworks/QtGui.framework/Versions/5/QtGui
>  empty dSYM file detected, dSYM was created with an executable with no debug 
> info.
> warning: (x86_64) 
> /Users/jam/nodups/nodups.app/Contents/Frameworks/QtCore.framework/Versions/5/QtCore
>  empty dSYM file detected, dSYM was created with an executable with no debug 
> info.
> Current executable set to 'nodups.app/Contents/MacOS/nodups' (x86_64).

This merely says:
.../QtGui empty dSYM file detected
that the Qt which you are building against has not been compiled with
debug info.

Did you compile Qt manually (and in debug mode)?

Mojca

Re: Vlc build fail

[Ryan Schmidt]

On Dec 31, 2018, at 01:57, rmgls wrote:

> :info:build Details:  Failed to create workspace arena at 
> :
>  Error Domain=NSCocoaErrorDomain Code=513 "You don’t have permission to save 
> the file “vlc-fafepcbfvuupchemfhqnbdofugwy” in the folder “DerivedData”." 
> UserInfo={NSFilePath=/opt/local/var/macports/home/Library/Developer/Xcode/DerivedData/vlc-fafepcbfvuupchemfhqnbdofugwy,
>  NSUnderlyingError=0x7fe90fceacc0 {Error Domain=NSPOSIXErrorDomain Code=1 
> "Operation not permitted"}}
> :info:build Object:   
> :info:build Method:   -createWorkspaceArenaFolderIfNecessary
> :info:build Thread:   {number = 1, name = main}

I expect this is https://trac.macports.org/ticket/57137. I don't know why 
nobody has tried to fix it yet.

Please use our list addresses at lists.macports.org, not the one you used.

Re: Gimp crashes when loading png or jpg

[Ryan Schmidt]

On Dec 31, 2018, at 14:11, Piet van Oostrum wrote:

> Suddenly my gimp crashes when I try to load a PNG or JPG file. It gives the 
> error message:
> Plug-in crashed: "file-png"
> (/Applications/MacPorts/GIMP.app/Contents/Resources/lib/gimp/2.0/plug-ins/file-png/file-png)
> 
> Plug-in crashed: "file-jpeg"
> (/Applications/MacPorts/GIMP.app/Contents/Resources/lib/gimp/2.0/plug-ins/file-jpeg/file-jpeg)
> 
> This is gimp @2.10.8_0+animation+quartz and gimp2 @2.10.8_2+python27+quartz 
> on MacOS High Sierra.
> I upgraded on 26 december and before that it worked. I also uninstalled and 
> reinstalled both gim and gimp2 from source but that did not help.
> 
> Is this a known issue?

I'm not sure. Did something actually crash? If so, a log should have been left 
behind in ~/Library/Logs/DiagnosticReports; if so, showing us that logfile 
might help us diagnose the issue.

Re: Python/boost problem

[Ryan Schmidt]

On Jan 7, 2019, at 18:18, Dave Horsfall wrote:

> Sierra, latest MacPorts.  Doing the usual "port upgrade outdated"...
> 
>--->  Staging itstool into destroot
>--->  Installing itstool @2.0.2_3
>--->  Activating itstool @2.0.2_3
>--->  Cleaning itstool
>Error: boost: Variant python27 conflicts with python36
>Error: Unable to open port: Error evaluating variants
>Error: Follow https://guide.macports.org/#project.tickets to report a bug.
> 
> No reference to a log, and may not have anything to do with "itstool" 
> (whatever that is), but my limited understanding of Python (which I don't use 
> directly) is that versions 2 and 3 are quite different beasts...
> 
> Is this a reportable bug, or have I stuffed up somewhere?  I don't like
> reporting "bugs" when it turns out to be my fault...

You are evidently asking the boost port to install itself with both the 
python27 and python36 variants. This is easy to reproduce:

$ port info boost +python27 +python36
Error: boost: Variant python27 conflicts with python36
Error: Unable to open port: Error evaluating variants

This is working as intended. These two variants are declared as conflicting 
with one another. You must choose one or the other.

Re: Failed to build Bitkeeper

[Ryan Schmidt]

On Jan 6, 2019, at 14:49, Dave Horsfall wrote:

> Is this a reportable bug in the port, or an up-stream bug?  I happen to know
> the author (if he's still maintaining it) - Larry McVoy.

It is reproducible. I have filed a MacPorts bug:

https://trac.macports.org/attachment/ticket/57874

I expect it is an upstream bug.



On Jan 6, 2019, at 14:56, Dave Horsfall wrote:

> Odd...
> 
>ozzie:~ dave# port upgrade -p outdated
>--->  Computing dependencies for bitkeeper
>--->  Staging bitkeeper into destroot
>--->  Installing bitkeeper @7.3.3_0
>--->  Cleaning bitkeeper
>--->  Computing dependencies for bitkeeper
>--->  Deactivating bitkeeper @7.3.2_1
>--->  Cleaning bitkeeper
>--->  Activating bitkeeper @7.3.3_0
>--->  Cleaning bitkeeper
> 
> Huh?  Did the "-p" flag really make that difference?

No; merely repeating the original command would have "worked" too.

Note that the "-p" flag, and all other single-dash flags, have no effect unless 
placed between the word "port" and the command verb, e.g. "sudo port -p 
upgrade". (Similarly, all double-dash flags are command verb specific and have 
no effect unless placed after the command verb.)

Re: gdb

[Ryan Schmidt]

I don't know why gdb isn't working for you. From what I've been able to find, 
it should be able to debug programs built by clang.

But have you considered trying lldb instead?

Re: Python/boost problem

[Mojca Miklavec]

On Tue, 8 Jan 2019 at 01:18, Dave Horsfall wrote:
>
> Sierra, latest MacPorts.  Doing the usual "port upgrade outdated"...
>
>  --->  Staging itstool into destroot
>  --->  Installing itstool @2.0.2_3
>  --->  Activating itstool @2.0.2_3
>  --->  Cleaning itstool
>  Error: boost: Variant python27 conflicts with python36
>  Error: Unable to open port: Error evaluating variants

This "Unable to open port: Error evaluating variants" is totally
strange in any case.

(I'm totally speculating now, but it could even be a bug in MacPorts
base, but I don't know if you could explain how to reproduce it, and
without having a way to reproduce it, it's super difficult to figure
out what went wrong.)

Other than than, I would probably clean boost (or perhaps clean all
ports), run "port outdated" to check which ports are still in the
queue for update, and then retry.

Mojca

Re: Python/boost problem

[Chris Jones]

Hi,

What variants are you using ? Are they different to the defaults ? Note 
variants can change over time so even if you did not original use any non 
default variants, you might now be doing so.

I would suggest forcibly removing the port in question, then reinstall it from 
scratch using defaults.

Chris

> On 8 Jan 2019, at 12:18 am, Dave Horsfall  wrote:
> 
> Sierra, latest MacPorts.  Doing the usual "port upgrade outdated"...
> 
>--->  Staging itstool into destroot
>--->  Installing itstool @2.0.2_3
>--->  Activating itstool @2.0.2_3
>--->  Cleaning itstool
>Error: boost: Variant python27 conflicts with python36
>Error: Unable to open port: Error evaluating variants
>Error: Follow https://guide.macports.org/#project.tickets to report a bug.
> 
> No reference to a log, and may not have anything to do with "itstool" 
> (whatever that is), but my limited understanding of Python (which I don't use 
> directly) is that versions 2 and 3 are quite different beasts...
> 
> Is this a reportable bug, or have I stuffed up somewhere?  I don't like
> reporting "bugs" when it turns out to be my fault...
> 
> Thanks.
> 
> -- Dave