FYI, I'm hard at work plotting out my move to reduce RAM usage...
But I'm also working on having Armory manage bitcoind/-qt for the user. I'm fairly confident I can have Armory find Bitcoin-Qt and run it in the background in Linux and Windows, but I don't have a clue in OSX. And since upgrading my OS, I no longer can get VMware running in order to load my OSX VM (which I spent so much time finally getting working!).
There will be an option to use Armory the old way (run Bitcoin-Qt yourself, and wait for it to sync), but I want to make that the non-default setting, and just manage it automatically for the user if I can find it.
So, is there a semi-standard location that I can use to go find the Bitcoin installation? It doesn't have to be precise, I can search directory trees pretty easily with python, but I need a hint of where to go.
Topic: Building Armory on OSX - page 2. (Read 32312 times)
I'm quite sure now that it is a resources problem. I did a fresh Mountain Lion install and now everything is running smoother, including Armory.
Start up takes 40 minutes, and then it runs flawlessly. Is RAM hungry in any case: with OSX Mail, Chrome, Skype and Bitcoin-QT running there's barely enough RAM for Armory to run. Makes all the system very sluggish, and it looses connection with Bitcoin and crashes if I open too many tabs in Chrome.
Start up takes 40 minutes, and then it runs flawlessly. Is RAM hungry in any case: with OSX Mail, Chrome, Skype and Bitcoin-QT running there's barely enough RAM for Armory to run. Makes all the system very sluggish, and it looses connection with Bitcoin and crashes if I open too many tabs in Chrome.
You can also use pastebin and then paste that link here 
Having some issues with Armory lately and new bitcoin 0.8.0, on OSX 10.8.2 (Macbook Pro 5,4 / 2.53 GHz Intel Core 2 Dup / 4 GB RAM
- it takes forever to scan the block chain every time I start it (30/40 minutes)
That is certainly unreasonable. Start Activity Monitor and look for memory usage and swap usage. I would think 4 GB is enough, but if you have something else that is memory expensive it may not be.- it takes forever to scan the block chain every time I start it (30/40 minutes)
Quote
- after some time running flawlessly, it crashes
I get this message "Python closed unexpectedly while running _CppBlockUtils.so.)
I also get a lot of errors in the Terminal (I could copy them here if they may help)
You probably should. Without that info etotheipi has no chance to guess what went wrong.I get this message "Python closed unexpectedly while running _CppBlockUtils.so.)
I also get a lot of errors in the Terminal (I could copy them here if they may help)
Having some issues with Armory lately and new bitcoin 0.8.0, on OSX 10.8.2 (Macbook Pro 5,4 / 2.53 GHz Intel Core 2 Dup / 4 GB RAM
- it takes forever to scan the block chain every time I start it (30/40 minutes)
- after some time running flawlessly, it crashes
I get this message "Python closed unexpectedly while running _CppBlockUtils.so.)
I also get a lot of errors in the Terminal (I could copy them here if they may help)
- it takes forever to scan the block chain every time I start it (30/40 minutes)
- after some time running flawlessly, it crashes
I get this message "Python closed unexpectedly while running _CppBlockUtils.so.)
I also get a lot of errors in the Terminal (I could copy them here if they may help)
So the auto-key-locate line at the very bottom looks fine, but I think the "comment GPGTools..." part might be breaking it. Try making it look like this:
Done. What should I do to check that now is working?
Code:
Downloading ftp://ftp.gnupg.org/gcrypt/gnupg/gnupg-1.4.12.tar.bz2
curl: (56) Recv failure: Operation timed out
Error: Download failed: ftp://ftp.gnupg.org/gcrypt/gnupg/gnupg-1.4.12.tar.bz2
curl: (56) Recv failure: Operation timed out
Error: Download failed: ftp://ftp.gnupg.org/gcrypt/gnupg/gnupg-1.4.12.tar.bz2
I keep getting this error anyway to bypass this? Even in my browser that FTP timesout
Maybe they were down for a bit and you got unlucky.
So the auto-key-locate line at the very bottom looks fine, but I think the "comment GPGTools..." part might be breaking it. Try making it look like this:
Done. What should I do to check that now is working?
# Automatic key location
#
# GnuPG can automatically locate and retrieve keys as needed using the
# auto-key-locate option. This happens when encrypting to an email
# address (in the "[email protected]" form), and there are no
# [email protected] keys on the local keyring. This option takes the
# following arguments, in the order they are to be tried:
#
# cert = locate a key using DNS CERT, as specified in RFC-4398.
# GnuPG can handle both the PGP (key) and IPGP (URL + fingerprint)
# CERT methods.
#
# pka = locate a key using DNS PKA.
#
# ldap = locate a key using the PGP Universal method of checking
# "ldap://keys.(thedomain)". For example, encrypting to
# [email protected] will check ldap://keys.example.com.
#
# keyserver = locate a key using whatever keyserver is defined using
# the keyserver option.
#
# You may also list arbitrary keyservers here by URL.
#
# Try CERT, then PKA, then LDAP, then hkp://keys.gnupg.net:
auto-key-locate cert pka ldap hkp://keys.gnupg.net
comment GPGTools - http://gpgtools.org
[/quote]#
# GnuPG can automatically locate and retrieve keys as needed using the
# auto-key-locate option. This happens when encrypting to an email
# address (in the "[email protected]" form), and there are no
# [email protected] keys on the local keyring. This option takes the
# following arguments, in the order they are to be tried:
#
# cert = locate a key using DNS CERT, as specified in RFC-4398.
# GnuPG can handle both the PGP (key) and IPGP (URL + fingerprint)
# CERT methods.
#
# pka = locate a key using DNS PKA.
#
# ldap = locate a key using the PGP Universal method of checking
# "ldap://keys.(thedomain)". For example, encrypting to
# [email protected] will check ldap://keys.example.com.
#
# keyserver = locate a key using whatever keyserver is defined using
# the keyserver option.
#
# You may also list arbitrary keyservers here by URL.
#
# Try CERT, then PKA, then LDAP, then hkp://keys.gnupg.net:
auto-key-locate cert pka ldap hkp://keys.gnupg.net
comment GPGTools - http://gpgtools.org
So the auto-key-locate line at the very bottom looks fine, but I think the "comment GPGTools..." part might be breaking it. Try making it look like this:
Quote
# You may also list arbitrary keyservers here by URL.
#
# Try CERT, then PKA, then LDAP, then hkp://keys.gnupg.net:
auto-key-locate cert pka ldap hkp://keys.gnupg.net
#comment GPGTools - http://gpgtools.org
[/quote] #
# Try CERT, then PKA, then LDAP, then hkp://keys.gnupg.net:
auto-key-locate cert pka ldap hkp://keys.gnupg.net
#comment GPGTools - http://gpgtools.org
I've tweaked the formula, and it should work better now.
That did it! Genius! It's scanning the blockchain at the moment
I just realized that this process is not going to work on the old offline computer I was going to use for cold storage, which is also an old macbook pro... I think I will just format it and install Ubuntu then.
This error means there is more than likely an error in your gpg.conf. Can you make sure nothing is sensitive in there and then post the contents here? I don't think this is a problem with brew.
In the mean time, read my post above for working around gpg.
Well, the truth is that i have NO gpg.conf on my computer
EDIT: I found the file, but OSX's finder took forever to find it. Here are the contents:
Quote
# These first three lines are not copied to the gpg.conf file in
# the users home directory.
# $Id$
# Options for GnuPG
# Copyright 1998, 1999, 2000, 2001, 2002, 2003,
# 2010 Free Software Foundation, Inc.
#
# This file is free software; as a special exception the author gives
# unlimited permission to copy and/or distribute it, with or without
# modifications, as long as this notice is preserved.
#
# This file is distributed in the hope that it will be useful, but
# WITHOUT ANY WARRANTY, to the extent permitted by law; without even the
# implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
#
# Unless you specify which option file to use (with the command line
# option "--options filename"), GnuPG uses the file ~/.gnupg/gpg.conf
# by default.
#
# An options file can contain any long options which are available in
# GnuPG. If the first non white space character of a line is a '#',
# this line is ignored. Empty lines are also ignored.
#
# See the man page for a list of options.
# Uncomment the following option to get rid of the copyright notice
#no-greeting
# If you have more than 1 secret key in your keyring, you may want to
# uncomment the following option and set your preferred keyid.
#default-key
# If you do not pass a recipient to gpg, it will ask for one. Using
# this option you can encrypt to a default key. Key validation will
# not be done in this case. The second form uses the default key as
# default recipient.
#default-recipient some-user-id
#default-recipient-self
# By default GnuPG creates version 4 signatures for data files as
# specified by OpenPGP. Some earlier (PGP 6, PGP 7) versions of PGP
# require the older version 3 signatures. Setting this option forces
# GnuPG to create version 3 signatures.
#force-v3-sigs
# Because some mailers change lines starting with "From " to ">From "
# it is good to handle such lines in a special way when creating
# cleartext signatures; all other PGP versions do it this way too.
# To enable full OpenPGP compliance you may want to use this option.
#no-escape-from-lines
# When verifying a signature made from a subkey, ensure that the cross
# certification "back signature" on the subkey is present and valid.
# This protects against a subtle attack against subkeys that can sign.
# Defaults to --no-require-cross-certification. However for new
# installations it should be enabled.
require-cross-certification
# If you do not use the Latin-1 (ISO-8859-1) charset, you should tell
# GnuPG which is the native character set. Please check the man page
# for supported character sets. This character set is only used for
# metadata and not for the actual message which does not undergo any
# translation. Note that future version of GnuPG will change to UTF-8
# as default character set.
#charset utf-8
# Group names may be defined like this:
# group mynames = paige 0x12345678 joe patti
#
# Any time "mynames" is a recipient (-r or --recipient), it will be
# expanded to the names "paige", "joe", and "patti", and the key ID
# "0x12345678". Note there is only one level of expansion - you
# cannot make an group that points to another group. Note also that
# if there are spaces in the recipient name, this will appear as two
# recipients. In these cases it is better to use the key ID.
#group mynames = paige 0x12345678 joe patti
# Some old Windows platforms require 8.3 filenames. If your system
# can handle long filenames, uncomment this.
#no-mangle-dos-filenames
# Lock the file only once for the lifetime of a process. If you do
# not define this, the lock will be obtained and released every time
# it is needed - normally this is not needed.
#lock-once
# GnuPG can send and receive keys to and from a keyserver. These
# servers can be HKP, email, or LDAP (if GnuPG is built with LDAP
# support).
#
# Example HKP keyservers:
# hkp://keys.gnupg.net
# hkp://subkeys.pgp.net
#
# Example email keyserver:
# mailto:[email protected]
#
# Example LDAP keyservers:
# ldap://pgp.surfnet.nl:11370
# ldap://keyserver.pgp.com
#
# Regular URL syntax applies, and you can set an alternate port
# through the usual method:
# hkp://keyserver.example.net:22742
#
# If you have problems connecting to a HKP server through a buggy http
# proxy, you can use keyserver option broken-http-proxy (see below),
# but first you should make sure that you have read the man page
# regarding proxies (keyserver option honor-http-proxy)
#
# Most users just set the name and type of their preferred keyserver.
# Note that most servers (with the notable exception of
# ldap://keyserver.pgp.com) synchronize changes with each other. Note
# also that a single server name may actually point to multiple
# servers via DNS round-robin. hkp://keys.gnupg.net is an example of
# such a "server", which spreads the load over a number of physical
# servers. To see the IP address of the server actually used, you may use
# the "--keyserver-options debug".
keyserver hkp://keys.gnupg.net
#keyserver http://http-keys.gnupg.net
#keyserver mailto:[email protected]
#keyserver ldap://pgp.surfnet.nl:11370
#keyserver ldap://keyserver.pgp.com
# Common options for keyserver functions:
#
# include-disabled = when searching, include keys marked as "disabled"
# on the keyserver (not all keyservers support this).
#
# no-include-revoked = when searching, do not include keys marked as
# "revoked" on the keyserver.
#
# verbose = show more information as the keys are fetched.
# Can be used more than once to increase the amount
# of information shown.
#
# use-temp-files = use temporary files instead of a pipe to talk to the
# keyserver. Some platforms (Win32 for one) always
# have this on.
#
# keep-temp-files = do not delete temporary files after using them
# (really only useful for debugging)
#
# honor-http-proxy = if the keyserver uses HTTP, honor the http_proxy
# environment variable
#
# broken-http-proxy = try to work around a buggy HTTP proxy
#
# auto-key-retrieve = automatically fetch keys as needed from the keyserver
# when verifying signatures or when importing keys that
# have been revoked by a revocation key that is not
# present on the keyring.
#
# no-include-attributes = do not include attribute IDs (aka "photo IDs")
# when sending keys to the keyserver.
keyserver-options auto-key-retrieve
# Uncomment this line to display photo user IDs in key listings and
# when a signature from a key with a photo is verified.
#show-photos
# Use this program to display photo user IDs
#
# %i is expanded to a temporary file that contains the photo.
# %I is the same as %i, but the file isn't deleted afterwards by GnuPG.
# %k is expanded to the key ID of the key.
# %K is expanded to the long OpenPGP key ID of the key.
# %t is expanded to the extension of the image (e.g. "jpg").
# %T is expanded to the MIME type of the image (e.g. "image/jpeg").
# %f is expanded to the fingerprint of the key.
# %% is %, of course.
#
# If %i or %I are not present, then the photo is supplied to the
# viewer on standard input. If your platform supports it, standard
# input is the best way to do this as it avoids the time and effort in
# generating and then cleaning up a secure temp file.
#
# The default program is "xloadimage -fork -quiet -title 'KeyID 0x%k' stdin"
# On Mac OS X and Windows, the default is to use your regular JPEG image
# viewer.
#
# Some other viewers:
# photo-viewer "qiv %i"
# photo-viewer "ee %i"
# photo-viewer "display -title 'KeyID 0x%k'"
#
# This one saves a copy of the photo ID in your home directory:
# photo-viewer "cat > ~/photoid-for-key-%k.%t"
#
# Use your MIME handler to view photos:
# photo-viewer "metamail -q -d -b -c %T -s 'KeyID 0x%k' -f GnuPG"
# *** Options for GPGTools ***
# Automatic key location
#
# GnuPG can automatically locate and retrieve keys as needed using the
# auto-key-locate option. This happens when encrypting to an email
# address (in the "[email protected]" form), and there are no
# [email protected] keys on the local keyring. This option takes the
# following arguments, in the order they are to be tried:
#
# cert = locate a key using DNS CERT, as specified in RFC-4398.
# GnuPG can handle both the PGP (key) and IPGP (URL + fingerprint)
# CERT methods.
#
# pka = locate a key using DNS PKA.
#
# ldap = locate a key using the PGP Universal method of checking
# "ldap://keys.(thedomain)". For example, encrypting to
# [email protected] will check ldap://keys.example.com.
#
# keyserver = locate a key using whatever keyserver is defined using
# the keyserver option.
#
# You may also list arbitrary keyservers here by URL.
#
# Try CERT, then PKA, then LDAP, then hkp://keys.gnupg.net:
auto-key-locate cert pka ldap hkp://keys.gnupg.net
comment GPGTools - http://gpgtools.org
# the users home directory.
# $Id$
# Options for GnuPG
# Copyright 1998, 1999, 2000, 2001, 2002, 2003,
# 2010 Free Software Foundation, Inc.
#
# This file is free software; as a special exception the author gives
# unlimited permission to copy and/or distribute it, with or without
# modifications, as long as this notice is preserved.
#
# This file is distributed in the hope that it will be useful, but
# WITHOUT ANY WARRANTY, to the extent permitted by law; without even the
# implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
#
# Unless you specify which option file to use (with the command line
# option "--options filename"), GnuPG uses the file ~/.gnupg/gpg.conf
# by default.
#
# An options file can contain any long options which are available in
# GnuPG. If the first non white space character of a line is a '#',
# this line is ignored. Empty lines are also ignored.
#
# See the man page for a list of options.
# Uncomment the following option to get rid of the copyright notice
#no-greeting
# If you have more than 1 secret key in your keyring, you may want to
# uncomment the following option and set your preferred keyid.
#default-key
# If you do not pass a recipient to gpg, it will ask for one. Using
# this option you can encrypt to a default key. Key validation will
# not be done in this case. The second form uses the default key as
# default recipient.
#default-recipient some-user-id
#default-recipient-self
# By default GnuPG creates version 4 signatures for data files as
# specified by OpenPGP. Some earlier (PGP 6, PGP 7) versions of PGP
# require the older version 3 signatures. Setting this option forces
# GnuPG to create version 3 signatures.
#force-v3-sigs
# Because some mailers change lines starting with "From " to ">From "
# it is good to handle such lines in a special way when creating
# cleartext signatures; all other PGP versions do it this way too.
# To enable full OpenPGP compliance you may want to use this option.
#no-escape-from-lines
# When verifying a signature made from a subkey, ensure that the cross
# certification "back signature" on the subkey is present and valid.
# This protects against a subtle attack against subkeys that can sign.
# Defaults to --no-require-cross-certification. However for new
# installations it should be enabled.
require-cross-certification
# If you do not use the Latin-1 (ISO-8859-1) charset, you should tell
# GnuPG which is the native character set. Please check the man page
# for supported character sets. This character set is only used for
# metadata and not for the actual message which does not undergo any
# translation. Note that future version of GnuPG will change to UTF-8
# as default character set.
#charset utf-8
# Group names may be defined like this:
# group mynames = paige 0x12345678 joe patti
#
# Any time "mynames" is a recipient (-r or --recipient), it will be
# expanded to the names "paige", "joe", and "patti", and the key ID
# "0x12345678". Note there is only one level of expansion - you
# cannot make an group that points to another group. Note also that
# if there are spaces in the recipient name, this will appear as two
# recipients. In these cases it is better to use the key ID.
#group mynames = paige 0x12345678 joe patti
# Some old Windows platforms require 8.3 filenames. If your system
# can handle long filenames, uncomment this.
#no-mangle-dos-filenames
# Lock the file only once for the lifetime of a process. If you do
# not define this, the lock will be obtained and released every time
# it is needed - normally this is not needed.
#lock-once
# GnuPG can send and receive keys to and from a keyserver. These
# servers can be HKP, email, or LDAP (if GnuPG is built with LDAP
# support).
#
# Example HKP keyservers:
# hkp://keys.gnupg.net
# hkp://subkeys.pgp.net
#
# Example email keyserver:
# mailto:[email protected]
#
# Example LDAP keyservers:
# ldap://pgp.surfnet.nl:11370
# ldap://keyserver.pgp.com
#
# Regular URL syntax applies, and you can set an alternate port
# through the usual method:
# hkp://keyserver.example.net:22742
#
# If you have problems connecting to a HKP server through a buggy http
# proxy, you can use keyserver option broken-http-proxy (see below),
# but first you should make sure that you have read the man page
# regarding proxies (keyserver option honor-http-proxy)
#
# Most users just set the name and type of their preferred keyserver.
# Note that most servers (with the notable exception of
# ldap://keyserver.pgp.com) synchronize changes with each other. Note
# also that a single server name may actually point to multiple
# servers via DNS round-robin. hkp://keys.gnupg.net is an example of
# such a "server", which spreads the load over a number of physical
# servers. To see the IP address of the server actually used, you may use
# the "--keyserver-options debug".
keyserver hkp://keys.gnupg.net
#keyserver http://http-keys.gnupg.net
#keyserver mailto:[email protected]
#keyserver ldap://pgp.surfnet.nl:11370
#keyserver ldap://keyserver.pgp.com
# Common options for keyserver functions:
#
# include-disabled = when searching, include keys marked as "disabled"
# on the keyserver (not all keyservers support this).
#
# no-include-revoked = when searching, do not include keys marked as
# "revoked" on the keyserver.
#
# verbose = show more information as the keys are fetched.
# Can be used more than once to increase the amount
# of information shown.
#
# use-temp-files = use temporary files instead of a pipe to talk to the
# keyserver. Some platforms (Win32 for one) always
# have this on.
#
# keep-temp-files = do not delete temporary files after using them
# (really only useful for debugging)
#
# honor-http-proxy = if the keyserver uses HTTP, honor the http_proxy
# environment variable
#
# broken-http-proxy = try to work around a buggy HTTP proxy
#
# auto-key-retrieve = automatically fetch keys as needed from the keyserver
# when verifying signatures or when importing keys that
# have been revoked by a revocation key that is not
# present on the keyring.
#
# no-include-attributes = do not include attribute IDs (aka "photo IDs")
# when sending keys to the keyserver.
keyserver-options auto-key-retrieve
# Uncomment this line to display photo user IDs in key listings and
# when a signature from a key with a photo is verified.
#show-photos
# Use this program to display photo user IDs
#
# %i is expanded to a temporary file that contains the photo.
# %I is the same as %i, but the file isn't deleted afterwards by GnuPG.
# %k is expanded to the key ID of the key.
# %K is expanded to the long OpenPGP key ID of the key.
# %t is expanded to the extension of the image (e.g. "jpg").
# %T is expanded to the MIME type of the image (e.g. "image/jpeg").
# %f is expanded to the fingerprint of the key.
# %% is %, of course.
#
# If %i or %I are not present, then the photo is supplied to the
# viewer on standard input. If your platform supports it, standard
# input is the best way to do this as it avoids the time and effort in
# generating and then cleaning up a secure temp file.
#
# The default program is "xloadimage -fork -quiet -title 'KeyID 0x%k' stdin"
# On Mac OS X and Windows, the default is to use your regular JPEG image
# viewer.
#
# Some other viewers:
# photo-viewer "qiv %i"
# photo-viewer "ee %i"
# photo-viewer "display -title 'KeyID 0x%k'"
#
# This one saves a copy of the photo ID in your home directory:
# photo-viewer "cat > ~/photoid-for-key-%k.%t"
#
# Use your MIME handler to view photos:
# photo-viewer "metamail -q -d -b -c %T -s 'KeyID 0x%k' -f GnuPG"
# *** Options for GPGTools ***
# Automatic key location
#
# GnuPG can automatically locate and retrieve keys as needed using the
# auto-key-locate option. This happens when encrypting to an email
# address (in the "[email protected]" form), and there are no
# [email protected] keys on the local keyring. This option takes the
# following arguments, in the order they are to be tried:
#
# cert = locate a key using DNS CERT, as specified in RFC-4398.
# GnuPG can handle both the PGP (key) and IPGP (URL + fingerprint)
# CERT methods.
#
# pka = locate a key using DNS PKA.
#
# ldap = locate a key using the PGP Universal method of checking
# "ldap://keys.(thedomain)". For example, encrypting to
# [email protected] will check ldap://keys.example.com.
#
# keyserver = locate a key using whatever keyserver is defined using
# the keyserver option.
#
# You may also list arbitrary keyservers here by URL.
#
# Try CERT, then PKA, then LDAP, then hkp://keys.gnupg.net:
auto-key-locate cert pka ldap hkp://keys.gnupg.net
comment GPGTools - http://gpgtools.org
Do you think it's safe to disable the GPG check? Armory handles sensitive stuff
You can always download first, and check signatures manually. But if you are really paranoid: no. But have you checked that the homebrew script actually checks the gpg signatures instead of just pretending to do so and install something nasty? 
I also recommend that you read the source for everything you install, but that is probably more difficult for non-programmers and programmers with not-enough time (e.g. all programmers). The formula is really strait forward.
Code:
cat `brew --prefix`/Library/Taps/wysenynja-bitcoin/armory-qt.rb
Or read it on github.
I'm trying just now to install Armory on a Macbook Pro running 10.8.2. I installed brew and downloading last version of XCODE and Xcode command line tools.
Will update later
EDIT: everything was going smooth, until I got this errors:
==> ./configure --prefix=/usr/local/Cellar/gnupg/1.4.12 --disable-asm
==> make CFLAGS= -std=gnu89 -fheinous-gnu-extensions
==> make check
==> make install
Warning: Could not link gnupg. Unlinking...
Error: The `brew link` step did not complete successfully
The formula built, but is not symlinked into /usr/local
You can try again using `brew link gnupg'
==> Summary
🍺 /usr/local/Cellar/gnupg/1.4.12: 54 files, 5,0M, built in 2.1 minutes
==> Installing armory-qt
==> Cloning https://github.com/etotheipi/BitcoinArmory.git
Updating /Library/Caches/Homebrew/armory-qt--git
==> Checking out tag v0.86.3-beta
==> Patching
patching file ArmoryQt.command
==> git verify-tag v0.86.3-beta
gpg: /Users/xxxxxx/.gnupg/gpg.conf:233: invalid auto-key-locate list
and then, when I try to run the client:
MacBook-Pro:~ mr$ ArmoryQt.command
-bash: ArmoryQt.command: command not found
Well of course you can't run "ArmoryQt.command" if the install fails Will update later
EDIT: everything was going smooth, until I got this errors:
==> ./configure --prefix=/usr/local/Cellar/gnupg/1.4.12 --disable-asm
==> make CFLAGS= -std=gnu89 -fheinous-gnu-extensions
==> make check
==> make install
Warning: Could not link gnupg. Unlinking...
Error: The `brew link` step did not complete successfully
The formula built, but is not symlinked into /usr/local
You can try again using `brew link gnupg'
==> Summary
🍺 /usr/local/Cellar/gnupg/1.4.12: 54 files, 5,0M, built in 2.1 minutes
==> Installing armory-qt
==> Cloning https://github.com/etotheipi/BitcoinArmory.git
Updating /Library/Caches/Homebrew/armory-qt--git
==> Checking out tag v0.86.3-beta
==> Patching
patching file ArmoryQt.command
==> git verify-tag v0.86.3-beta
gpg: /Users/xxxxxx/.gnupg/gpg.conf:233: invalid auto-key-locate list
and then, when I try to run the client:
MacBook-Pro:~ mr$ ArmoryQt.command
-bash: ArmoryQt.command: command not found
This error means there is more than likely an error in your gpg.conf. Can you make sure nothing is sensitive in there and then post the contents here? I don't think this is a problem with brew.
In the mean time, read my post above for working around gpg.
The GPG stuff is only used to validate the downloads. In a previous post in this thread he gives a command line option to disable the check, hopefully that will also disable the dependency of gnupg.
I tried
brew install --skip-verify wysenynja/bitcoin/armory-qt
I still get:
Error: You must `brew link gnupg' before armory-qt can be installed
Sorry about that.
I've tweaked the formula, and it should work better now.
Instead of "--skip-verify," now you can use "--without-gpg" and brew should be smart enough to skip the installation step.
Additionally, I just bumped the version to 0.87-beta. As always, you can use "--devel" to install the testing branch.
Code:
brew update
brew install wysenynja/bitcoin/armory-qt --without-gpg
brew install wysenynja/bitcoin/armory-qt --without-gpg
About gpgtools and OSX Mountain Lion. If you donate (hint: they accept bitcoin), you can get early access to the beta. Just send them an email with a signed txid and a message saying how awesome they are. I have had both brew's gpg and gpgtools beta installed without problem for months now.
Do you think it's safe to disable the GPG check? Armory handles sensitive stuff
You can always download first, and check signatures manually. But if you are really paranoid: no. But have you checked that the homebrew script actually checks the gpg signatures instead of just pretending to do so and install something nasty? The GPG stuff is only used to validate the downloads. In a previous post in this thread he gives a command line option to disable the check, hopefully that will also disable the dependency of gnupg.
I tried
brew install --skip-verify wysenynja/bitcoin/armory-qt
AND
brew install wysenynja/bitcoin/armory-qt --skip-verify
I still get:
Error: You must `brew link gnupg' before armory-qt can be installed
The GPG stuff is only used to validate the downloads. In a previous post in this thread he gives a command line option to disable the check, hopefully that will also disable the dependency of gnupg.
Do you think it's safe to disable the GPG check? Armory handles sensitive stuff
The GPG stuff is only used to validate the downloads. In a previous post in this thread he gives a command line option to disable the check, hopefully that will also disable the dependency of gnupg.
Yes, a sufficiently old MacGPG will cause that kind of problems. I uninstalled mine and allowed Homebrew's gnupg to install, but then I have never been able to get MacGPG to work even in a remotely satisfactory way, and the newest version does not yet support Mountain Lion.
Do not worry about your private GPG keys, surely you have them backed up in three different places already.
Joking aside, uninstalling MacGPG should not uninstall them, they should be kept in ~/.gnupg but you certainly want to back up that directory before experimenting!
Do not worry about your private GPG keys, surely you have them backed up in three different places already.
Joking aside, uninstalling MacGPG should not uninstall them, they should be kept in ~/.gnupg but you certainly want to back up that directory before experimenting!
This seems like a serious problem. I use GPG daily, mostly to encrypt files... I cannot risk to not being able to use it again
I had all sort of troubles caused by MacGPG, even after I uninstalled it. I think I ven had to force brew to link the files to move on.
I tried the brew link gnupg" and I got this error:
MacBook-Pro:~ mr$ brew link gnupg
Linking /usr/local/Cellar/gnupg/1.4.12... Warning: Could not link gnupg. Unlinking...
Error: Could not symlink file: /usr/local/Cellar/gnupg/1.4.12/bin/gpg
Target /usr/local/bin/gpg already exists. You may need to delete it.
To force the link and delete this file, do:
brew link --overwrite formula_name
To list all files that would be deleted:
brew link --overwrite --dry-run formula_name
MacBook-Pro:~ mr$ brew link --overwrite --dry-run formula_name
Error: No such keg: /usr/local/Cellar/formula_name
I really hope Red Emerald could find a workaround for this
I had all sort of troubles caused by MacGPG, even after I uninstalled it. I think I ven had to force brew to link the files to move on.
Yes, a sufficiently old MacGPG will cause that kind of problems. I uninstalled mine and allowed Homebrew's gnupg to install, but then I have never been able to get MacGPG to work even in a remotely satisfactory way, and the newest version does not yet support Mountain Lion.
Do not worry about your private GPG keys, surely you have them backed up in three different places already.
Joking aside, uninstalling MacGPG should not uninstall them, they should be kept in ~/.gnupg but you certainly want to back up that directory before experimenting!
Do not worry about your private GPG keys, surely you have them backed up in three different places already.
Joking aside, uninstalling MacGPG should not uninstall them, they should be kept in ~/.gnupg but you certainly want to back up that directory before experimenting!
Jump to: