Have you been waiting for Armory-Beta? Help me release it!

[etotheipi]

I'm sure most of you have at least heard of Armory by now.  Many folks donated to the Armory call for crowdfunding back in March.  And many other folks claimed they would try it when it was no longer alpha.   And even while it has been alpha,  Armory has been getting about 1,500 downloads per month!  

Well, after 8 months and probably another 1,000 hours of development, I believe that Armory is about ready for its official Beta release!  

However, I want to release the latest release candidate to a smaller crowd of people, before doing it officially -- Armory now has so many features, that no level of personal testing is sufficient for such a major release.  I just need people to get out there and use it!  If you've always wanted to try it, then please use it and give me feedback!


Get Armory version 0.84.5-almost-beta
(there's a very good chance that this will be the final beta release)



For those who like to compile their own, you can check it out from the github repo:  "git clone git://github.com/etotheipi/BitcoinArmory.git" and the switch to the threading branch "git checkout threading".  It will be merged into master when the release is official.  (more detailed instructions at the Building Armory from Source page)

What's new since crowdfunding phase?   (Answer: everything)

• Armory now works on 32-bit and 64-bit Windows and Linux (Mac/OSX users have been successful at compiling it themselves, but I have failed at packaging it properly; there are links on the "Get Armory" page linked above)
• Installers with uninstallers for both Windows and Linux
• Bulk address importing/sweeping
• Multi-threaded blockchain scanning so you can still user Armory while it is scanning.
• System tray icon, with notifications!
• Full "bitcoin:" URL handling in both Windows and Linux (and a place to enter the URL manually if clicking the links don't work for some reason)
• Create clickable payment requests to be copied into emails or wepages.
• GPG-signed installers for using the Armory Signing Key (the first link on that page)
• Export your transaction histories
• Minimize to system tray
• Manually pecify change address for each transaction (expert usermode only)
• Version checking and notification
• Endless polishing (table sorting, formatting, preferences, filtering, warning windows, action verification checks, tooltips/mouseover text on everything, etc)

And of course, that is only what is new to Armory!  Don't forget that Armory gives you:

• Painless offline wallets (cold storage)
• Multiple-wallet interface
• GPU-resistant wallet encryption
• Deterministic wallets
• Only-one-time-needed-ever backups!  Print one off when you create the wallet, protect it forever!
• Watching-only wallets
• Key importing and sweeping
• Message signing
• And lots more I can't even remember!

If you haven't tried Armory in a while, it probably looks completely different.

Remaining issues (what you can expect):

• Still requires Bitcoin-Qt to be running.  But I made a page explaining why
• Still long load times, but at least Armory is running while it is loading
• RAM usage is dramatically reduced from the original, full-blockchain-in-RAM implementation.  But SatoshiDice has bloated the blockchain so much, that even my indexing scheme consumes a lot of RAM (>=1.0GB).  After Beta, I will be switching to having Armory manage its own blockchain data using LevelDB, which will trade RAM consumption for HDD consumption.  However, I wanted beta to be a stable release with the current HDD-lite architecture.  (a lot of power users have a lot of RAM and like the small HDD footprint)
• Windows 32-bit still sometimes has issues.  Until the upgrade mentioned above, Win32 users may not have a pleasant ride.
• Some crashes may still exist under combinations of events.  If you experience this, please send me a log file
• Compressed public keys not supported.

P.S. - In case anyone is wondering:  There have only been two reports, ever, of users losing money with Armory.  Both cases were due to users side-stepping Armory's built-in protections -- they manually deleted files in the application directory -- and both would've been prevented if they had made paper backups! (a digital backup would've been fine, too)  

Make a paper backup of your wallet and keep it safe!  Only one backup is necessary to protect all private keys, forever! (except private keys, back those up separately).   Even if you later decide you don't like Armory, you can use the "Backup Individual Keys" dialog to export all private keys to be imported into another application or service.

[1715673562]

1715673562

[1715673562]

1715673562

[1715673562]

1715673562

[bitbutter]

As soon as there's an OSX installer suitable for command-line-o-phobes I'll be installing this quickly. It looks like exactly what I've been waiting. Thanks for all the work so far.

[etotheipi]

As soon as there's an OSX installer suitable for command-line-o-phobes I'll be installing this quickly. It looks like exactly what I've been waiting. Thanks for all the work so far.

Unfortunately, my Mac-fu is really weak.  Before a 2 months ago, I had never even seen what OSX looks like.  After doing some research, I determined that creating an official package is a lot of work, and probably a bit of money (for the code-signing key). 

However, I have received some tips from others, about creating .dmg/.app bundles.  The problem is the dependencies -- I might have to do something creative to make it work as a standalone application without the users installing a bunch of stuff.  On the other hand, RedEmerald's instructions involving brew have been good enough that it worked on my first try when I finally got a 10.7.4 OSX VM running (it does download and install all the dependencies, which is why it's not terribly difficult).  There's more here in case you want to try it.

On the other hand, maybe Red Emerald would like to respond here with his latest walk-thru, to make sure that those users who want to try it, can see it.  While I've had reasonably good response to people compiling in OSX, I have personally tested it very little there.  Again, maybe RE would comment on its limitations (if any) compared to the Windows/Linux.

[gweedo]

Also Red Emerald has a brew formula that makes installing it for mac insanely easy.
https://bitcointalk.org/index.php?topic=73648.msg1136230#msg1136230

[Red Emerald]

Also Red Emerald has a brew formula that makes installing it for mac insanely easy.
https://bitcointalk.org/index.php?topic=73648.msg1136230#msg1136230

Glad you found the tap useful.  As soon as treading is on master, I'll update the tap. This makes it essentially 2 commands that can be copy/pasted to install. I've been experimenting with the "--framework" flag when installing python with brew and hoping this makes building a .app work. I tried doing something similar to electrum's Mac steps, but kept getting errors. I've been really busy with non-btc stuff, but I should have some time this weekend to play more.

[xcsler]

Newbie type question...

The private key fields are empty in the watching only wallet for both BE and LE formats but why are there a few numbers/letters listed for my Private Key (Plain Base58) in my watching only wallet for all of the addresses?

I compared these numbers/letters to the Private Key (Plain Base 58) listed in my offline wallet and they are different.

I am confident that the offline wallet has the actual Private Key but got a bit spooked when I saw a combination of numbers/letters listed in the watching only version.

Thanks,
xcsler



 

[etotheipi]

Newbie type question...

The private key fields are empty in the watching only wallet for both BE and LE formats but why are there a few numbers/letters listed for my Private Key (Plain Base58) in my watching only wallet for all of the addresses?

I compared these numbers/letters to the Private Key (Plain Base 58) listed in my offline wallet and they are different.

I am confident that the offline wallet has the actual Private Key but got a bit spooked when I saw a combination of numbers/letters listed in the watching only version.

Thanks,
xcsler

Oh, I guess I missed some polishing... "Private Key" options are supposed to be disabled for watching-only wallets.  Private keys are always displayed with a 4-byte checksum after them, so it's easy for the system reading it to recognize if it was copied correctly.  In this case, since the wallet doesn't have private keys, it's showing you a zero-byte private key (i.e. nothing) with a four-byte checksum after it (checksum of an empty string).  That's why it's the same few characters for all private keys on that screen -- they're all the same empty string.   Don't worry, there's no private key data in the wallet to be leaked

If you're really interested, I documented the wallet format:  http://bitcoinarmory.com/index.php/armory-wallet-files.  You can use it to manually check your watching-only wallet file... you can dig through the binary and verify that the private-key fields are really empty.

I'll add that to my list of things to polish for the official beta release.

[xcsler]

Thanks for the explanation.
Concerns alleviated.

[etotheipi]

I just added the "Ubuntu 10.04 Offline Bundle" to the "Get Armory" page.  Or here's the direct link:

Armory 0.84.5-alpha offline bundle for Ubuntu 10.04 32bit and
Detached GPG signature for offline bundle.

It should be exactly everything you to install and run offline Armory on the first boot of a fresh Ubuntu 10.04 32-bit installation.  I have tested this with a fresh VM, but I do need others to try it to make sure that I didn't "cheat" by accident while testing it




P.S. - I just realized that the webpage (and the links above) suggest that they only way to have an offline computer is through Ubuntu 10.04 32-bit.  I should clarify that any offline system running Armory without an internet connection is an "offline system," and as long as Armory runs, it will serve its purpose.  This means that you can use a Windows machine and just copy the installer over there, detach it from the internet, and you're good to go.  The only reason why there's a special bundle for Linux is because Armory requires some dependencies to be installed -- which are downloaded and installed automatically when Armory is installed -- but those dependencies are not accessible if you do a fresh offline-installation of Linux without it ever touching the internet.

So, don't think that you need any special version of Armory to run offline.  The bundle only helps you get it setup on an Ubuntu machine that started offline and can't get the dependencies.  Without it, if you install Ubuntu, you might want to put it online long enough to install Armory and its dependencies, then detach the network cable... but it's clearly much better if you can do a fresh Ubuntu installation without ever touching the internet, even at the start.  

I'm actually out of town right now and can't update the webpage yet.  So I wanted to clarify this for users before then.

[Daily Anarchist]

As soon as there is an RPM Satoshi Client and RMP Armory client available, I'll be all over it.

[etotheipi]

As soon as there is an RPM Satoshi Client and RMP Armory client available, I'll be all over it.

To be fair, the compilation instructions are very easily translated to other *nix OS'es.  I have a few RH users who said it was quite easy to compile.  Unfortunately, my experience with other Linux distros is slim, but if you are using other distros, you're probably already familiar with copying a few commands into a terminal to get things to work.  However, I don't know if Bitcoin-Qt is the same...

FYI, I am the Armory developer.  I am the only one.  So, not only am I short on time, but my experience is limited to what I use.  I've spent quite a bit of time trying to accommodate other OS'es, but I really need other people (like you?) to help me figure out how to prepare it for other OS & architectures.  Red Emerald has basically taken the helm like this for OSX, and I would be thrilled if someone helped me figure out how to make an RPM, etc.

I know that's not the answer you're looking, but it's the best I can do by myself, at the moment...

[Daily Anarchist]

As soon as there is an RPM Satoshi Client and RMP Armory client available, I'll be all over it.

To be fair, the compilation instructions are very easily translated to other *nix OS'es.  I have a few RH users who said it was quite easy to compile.  Unfortunately, my experience with other Linux distros is slim, but if you are using other distros, you're probably already familiar with copying a few commands into a terminal to get things to work.  However, I don't know if Bitcoin-Qt is the same...

FYI, I am the Armory developer.  I am the only one.  So, not only am I short on time, but my experience is limited to what I use.  I've spent quite a bit of time trying to accommodate other OS'es, but I really need other people (like you?) to help me figure out how to prepare it for other OS & architectures.  Red Emerald has basically taken the helm like this for OSX, and I would be thrilled if someone helped me figure out how to make an RPM, etc.

I know that's not the answer you're looking, but it's the best I can do by myself, at the moment...

I'd really like to get in touch with these fellow RH users who compiled your software, because I've been completely unable to compile the Satoshi client on Fedora. There have been people who *claimed* it "could" be done, but none of them were people who actually DID it. There is one fellow who offered an RPM of the Satoshi client from his repository, but I never could get it to work. So, if you actually know people who could help me get the most recent stable version of the Satoshi client, and the mos recent version of the Armory client installed on Fedora, I'd be ecstatic.

On a side, I'm teaching myself programming right now. I got tired of not knowing how to do shit. Besides, it seems like a good career path. May be a long time though before I can produce anything of value.

[jimbobway]

Good decision on keeping the Satoshi client for networking.

[etotheipi]

I'd really like to get in touch with these fellow RH users who compiled your software, because I've been completely unable to compile the Satoshi client on Fedora. There have been people who *claimed* it "could" be done, but none of them were people who actually DID it. There is one fellow who offered an RPM of the Satoshi client from his repository, but I never could get it to work. So, if you actually know people who could help me get the most recent stable version of the Satoshi client, and the mos recent version of the Armory client installed on Fedora, I'd be ecstatic.

On a side, I'm teaching myself programming right now. I got tired of not knowing how to do shit. Besides, it seems like a good career path. May be a long time though before I can produce anything of value.

If you have the dependencies installed, then you might have to change two characters in the makefile, then type "make".  Then it's done.  The dependencies are usually where the issues are, but Armory's dependencies are totally standard and not picky about version.  And I'm working on how to autodetect the condition when you have to change the two characters (I'm really bad with makefiles).

Please make a post in the discussion thread and I'm sure someone will give you step-by-step instructions, and my guess is it will only be a couple commands.  And when they do, I'll post them on the website.

On the other side, Bitcoin-Qt is a royal P.I.T.A to compile.  I believe it's very picky about versions, and trying to get those versions installed are likely to fail and/or break other things on your system.  While I can't help you compile it, you don't need to compile it yourself to use Armory (I assume since you are here that you have a pre-compiled version you are using already).

  

[justusranvier]

I'd really like to get in touch with these fellow RH users who compiled your software, because I've been completely unable to compile the Satoshi client on Fedora. There have been people who *claimed* it "could" be done, but none of them were people who actually DID it. There is one fellow who offered an RPM of the Satoshi client from his repository, but I never could get it to work. So, if you actually know people who could help me get the most recent stable version of the Satoshi client, and the mos recent version of the Armory client installed on Fedora, I'd be ecstatic.

On a side, I'm teaching myself programming right now. I got tired of not knowing how to do shit. Besides, it seems like a good career path. May be a long time though before I can produce anything of value.

If this is your goal you might be better served by Gentoo or Linux From Scratch as opposed to Fedora.

[Daily Anarchist]

I'd really like to get in touch with these fellow RH users who compiled your software, because I've been completely unable to compile the Satoshi client on Fedora. There have been people who *claimed* it "could" be done, but none of them were people who actually DID it. There is one fellow who offered an RPM of the Satoshi client from his repository, but I never could get it to work. So, if you actually know people who could help me get the most recent stable version of the Satoshi client, and the mos recent version of the Armory client installed on Fedora, I'd be ecstatic.

On a side, I'm teaching myself programming right now. I got tired of not knowing how to do shit. Besides, it seems like a good career path. May be a long time though before I can produce anything of value.

If this is your goal you might be better served by Gentoo or Linux From Scratch as opposed to Fedora.

I'm happy with Fedora. Also, I don't have the Satoshi client running on my system. I couldn't install the RPM offered or compile it or anything. Somebody claimed that Fedora has restrictive licensing that prevents the use of the Satoshi client because the Satoshi client requires some sort of software that Fedora won't allow.

It's a real drag and it may be a while before that issue gets solved.

I'm hoping some day there's an Anarchy Linux that doesn't pay attention to licenses at all, period.

[gmaxwell]

I'd really like to get in touch with these fellow RH users who compiled your software, because I've been completely unable to compile the Satoshi client on Fedora. There have been people who *claimed* it "could" be done, but none of them were people who actually DID it. There is one fellow who offered an RPM of the Satoshi client from his repository, but I never could get it to work.

Um. Because it's utterly trivial to do it I expect a lot of people don't talk about it much.

Fedora removes ECC support from OpenSSL because OpenSSL doesn't distinguish the stuff that no one argues isn't covered by valid patents and the stuff that no one argues is patented. RedHat's response was just to disable it all and let god sort it out.  So you need OpenSSL recompiled with the removed ECDSA re-added.  Once you have this it works like anywhere else (e.g. you need the suitable dependencies and development headers).

I've maintained suitable RPMs for my own usage for some time: https://people.xiph.org/~greg/openssl/

[Daily Anarchist]

I'd really like to get in touch with these fellow RH users who compiled your software, because I've been completely unable to compile the Satoshi client on Fedora. There have been people who *claimed* it "could" be done, but none of them were people who actually DID it. There is one fellow who offered an RPM of the Satoshi client from his repository, but I never could get it to work.

Um. Because it's utterly trivial to do it I expect a lot of people don't talk about it much.

Trivial if you know what you're doing. Care to start a thread where you walk me step by step through the installation process? I'm sure somebody else down the road will get some use out of it.

[justusranvier]

0.82.4 worked, but now with 0.85 I get this:

Setting netmode: 1
(ERROR) armoryengine.py:11323 - Error processing BDM input
(ERROR) armoryengine.py:11324 - Received inputTuple: GoOnlineRequested [13, 30068791, False]
(ERROR) armoryengine.py:11325 - Error processing ID (30068791)

[etotheipi]

0.82.4 worked, but now with 0.85 I get this:

Setting netmode: 1
(ERROR) armoryengine.py:11323 - Error processing BDM input
(ERROR) armoryengine.py:11324 - Received inputTuple: GoOnlineRequested [13, 30068791, False]
(ERROR) armoryengine.py:11325 - Error processing ID (30068791)

Recompile the C++ utilities.  That's the error I see when users upgrade the python code (via git pull), but don't recompile the C++ changes.   (just 'make' from the base directory)

[justusranvier]

That was it. I had forgotten there was anything to compile.

If I wanted to write an ebuild for Armory to automate the compilation and install it to a standard location like a real Linux application what files would I need from the source directory?

[etotheipi]

That was it. I had forgotten there was anything to compile.

If I wanted to write an ebuild for Armory to automate the compilation and install it to a standard location like a real Linux application what files would I need from the source directory?

Armory runs from:

-- All *.py files in the base directory
-- _CppBlockUtils.so 

CppBlockUtils.py, _CppBlockUtils.so, and qrc_img_resources.py are created from the compilation procedure.  That should be all you need.  I just noticed that I packaged the "img" directory, but it's not necessary:  all the img files are encoded into the qrc_img_resources.py file.

[justusranvier]

It turned out to be easier than I thought. Here is a working ebuild for net-p2p/armory-0.85:

EAPI=4

inherit git-2

DESCRIPTION="Armory is a full-featured Bitcoin client, offering a dozen innovative features not found in any other client software!"
HOMEPAGE="http://bitcoinarmory.com/"

EGIT_REPO_URI="git://github.com/etotheipi/BitcoinArmory.git"
EGIT_COMMIT="v0.85-beta"

LICENSE="AGPL-3"
SLOT="0"
KEYWORDS="~x86 ~amd64"

RDEPEND="net-p2p/bitcoin-qt"

DEPEND="dev-python/PyQt4
        dev-lang/swig
        dev-python/twisted"

src_install() {
    emake DESTDIR="${D}" install

    dodoc README
}

A few things I noticed:

1. There is no icon for the associated .desktop files.
2. The build process doesn't appear to honor CXXFLAGS or MAKEOPTS.
3. Do you have any suggestions about the minimum (maximum?) required versions for the build dependencies?

[etotheipi]

One of the reasons why Armory has been so "delightful" for users to compile is that I don't rely on any particular versions of the underlying packages.  Rather, I only use features that have been a stable part of those packages for a long time, and should be in all modern versions.

There are .desktop files in the dpkgfiles directory. 

As for CXXFLAGS and MAKEOPTS -- I'm not very good with makefiles.  I put together whatever I could to make it work.  If you have recommendations for improving it, or making it more versatile, I'll be happy to update it.

[justusranvier]

There are .desktop files in the dpkgfiles directory.

They get installed but there is no icon for them.

As for CXXFLAGS and MAKEOPTS -- I'm not very good with makefiles.  I put together whatever I could to make it work.  If you have recommendations for improving it, or making it more versatile, I'll be happy to update it.

I know even less about writing makefiles.

[etotheipi]

Oh, the img directory does matter here (though it could be separated out...)

In dpkgfiles/postinst, here are the 6 lines that are run to setup the icons:

Code:

execAndWait('xdg-icon-resource install --novendor --context apps --size 64 /usr/share/armory/img/armory_icon_64x64.png armoryicon')
execAndWait('xdg-icon-resource install --novendor --context apps --size 64 /usr/share/armory/img/armory_icon_64x64.png armoryofflineicon')
execAndWait('xdg-icon-resource install --novendor --context apps --size 64 /usr/share/armory/img/armory_icon_green_64x64.png armorytestneticon')
execAndWait('xdg-desktop-menu  install --novendor /usr/share/applications/armory.desktop')
execAndWait('xdg-desktop-menu  install --novendor /usr/share/applications/armorytestnet.desktop')
execAndWait('xdg-desktop-menu  install --novendor /usr/share/applications/armoryoffline.desktop')

So it registers the icons with xdg-icon-resource using the names "armoryicon", "armoryofflineicon" and "armorytestneticon", and then references those names in the .desktop files.  That's the way I determined was the "correct" way to install a program on a Linux system (at least, Ubuntu/Gnome).

[justusranvier]

Adding the commands to register the icons fixes the issue I was seeing before. The other commands don't appear to be necessary on my KDE setup because your makefile already installs the .desktop files in the right place.

EAPI=4

inherit git-2

DESCRIPTION="Armory is a full-featured Bitcoin client, offering a dozen innovative features not found in any other client software!"
HOMEPAGE="http://bitcoinarmory.com/"

EGIT_REPO_URI="git://github.com/etotheipi/BitcoinArmory.git"
EGIT_COMMIT="v0.85-beta"

LICENSE="AGPL-3"
SLOT="0"
KEYWORDS="~x86 ~amd64"

RDEPEND="net-p2p/bitcoin-qt"

DEPEND="dev-python/PyQt4
        dev-lang/swig
        dev-python/twisted
        x11-misc/xdg-utils"

src_install() {
    emake DESTDIR="${D}" install

    dodoc README
}


pkg_postinst() {
        xdg-icon-resource install --novendor --context apps --size 64 /usr/share/armory/img/armory_icon_64x64.png armoryicon
        xdg-icon-resource install --novendor --context apps --size 64 /usr/share/armory/img/armory_icon_64x64.png armoryofflineicon
        xdg-icon-resource install --novendor --context apps --size 64 /usr/share/armory/img/armory_icon_green_64x64.png armorytestneticon
}

[etotheipi]

EAPI=4
...
EGIT_REPO_URI="git://github.com/etotheipi/BitcoinArmory.git"
EGIT_COMMIT="v0.85-beta"
...

Is the reference to the specific version necessary?  "v0.85-beta"?  Couldn't you just use "master", and then the ebuild will always access the latest version only?  For reference, the master branch is specifically, only for final releases.  All development and testing versions stay on their branch until it's ready for release.  In fact, the act of merging it into master is what notifies users that an official new version is available:  the software checks the master-branch copy of versions.txt to determine the latest version.

[justusranvier]

Is the reference to the specific version necessary?  "v0.85-beta"?  Couldn't you just use "master", and then the ebuild will always access the latest version only?

The EGIT_COMMIT line could be deleted entirely and it would have the behavior you describe.

By convention ebuilds like that are given a version number of -9999 but I don't like that method because the package manager itself doesn't know when an update is available.

[justusranvier]

It would also be good if you would use git's tag signing feature so those who compile Armory would also have the ability to use your public PGP key to verify the sources.

[etotheipi]

It would also be good if you would use git's tag signing feature so those who compile Armory would also have the ability to use your public PGP key to verify the sources.

Of course, I forgot that git supported that! 

However, my signing key is on my offline computer, I'm going to have to get creative... I'm not sure exactly how to pull that off.  I think I know how...

[Red Emerald]

It would also be good if you would use git's tag signing feature so those who compile Armory would also have the ability to use your public PGP key to verify the sources.

Of course, I forgot that git supported that! 

However, my signing key is on my offline computer, I'm going to have to get creative... I'm not sure exactly how to pull that off.  I think I know how...

+1

Let me know if you need help with git.  I'm sure you'll figure it out though.

[etotheipi]

It would also be good if you would use git's tag signing feature so those who compile Armory would also have the ability to use your public PGP key to verify the sources.

Of course, I forgot that git supported that! 

However, my signing key is on my offline computer, I'm going to have to get creative... I'm not sure exactly how to pull that off.  I think I know how...

+1

Let me know if you need help with git.  I'm sure you'll figure it out though.

I'll have to defer until tomorrow, but if I had to guess right now,  Is'd say I could simply clone the repo onto a USB drive,  and then create a new signed tag in the clone while plugged into the offline system.  Do a git push <tag> when I get it back to the online system.

How does that sound?  (besides the fact I may not even have git installed on that system... But i can take care of that)

[Red Emerald]

It would also be good if you would use git's tag signing feature so those who compile Armory would also have the ability to use your public PGP key to verify the sources.

Of course, I forgot that git supported that! 

However, my signing key is on my offline computer, I'm going to have to get creative... I'm not sure exactly how to pull that off.  I think I know how...

+1

Let me know if you need help with git.  I'm sure you'll figure it out though.

I'll have to defer until tomorrow, but if I had to guess right now,  Is'd say I could simply clone the repo onto a USB drive,  and then create a new signed tag in the clone while plugged into the offline system.  Do a git push <tag> when I get it back to the online system.

How does that sound?  (besides the fact I may not even have git installed on that system... But i can take care of that)

That sounds perfect (assuming you have git on your offline system).

I do something similar to get armory onto my offline system.  I clone the repo to a USB drive and then plug that into my offline computer.  My offline computer has it's origin remote set to the USB drive, so I just `cd ~/src/BitcoinArmory && git pull && make clean && make && make install` and my offline system is up to date.

[justusranvier]

I created a new wallet and then imported a single private key into it without sweeping funds.

After rescanning the blockchain the Balance shown in the "Available Wallets" area is correct, but on the Transactions tab every transaction is shown twice, and the "Spendable Funds" displays double the value it should.

Closing and restarting Armory fixes the problem.

[etotheipi]

I created a new wallet and then imported a single private key into it without sweeping funds.

After rescanning the blockchain the Balance shown in the "Available Wallets" area is correct, but on the Transactions tab every transaction is shown twice, and the "Spendable Funds" displays double the value it should.

Closing and restarting Armory fixes the problem.

Ay, third time that bug has been reported in the last 24 hours!  The other users experienced that when sending funds to Armory from Bitcoin-Qt.  I will investigate. 

Also, for future, let's divert bug reports to the discussion thread:  https://bitcointalk.org/index.php?topic=56424

[justusranvier]

I got a user overlay set up on overlays.gentoo.org, so you can use the following installation instructions to install Armory on Gentoo:

Ebuilds for Armory are available in the jranvier user overlay.

1. Install the overlay using Layman:

Code:

layman -a jranvier

2. Add Armory to package.keywords:

Code:

echo net-p2p/armory >> /etc/portage/package.keywords

3. Install Armory:

Code:

emerge armory

[etotheipi]

I got a user overlay set up on overlays.gentoo.org, so you can use the following installation instructions to install Armory on Gentoo:

Ebuilds for Armory are available in the jranvier user overlay.

1. Install the overlay using Layman:

Code:

layman -a jranvier

2. Add Armory to package.keywords:

Code:

echo net-p2p/armory >> /etc/portage/package.keywords

3. Install Armory:

Code:

emerge armory

Just a question, because I don't know much about Gentoo.  As might be expected, I'm uncomfortable promoting opaque installation instructions based on any particular user's efforts.  I've been very hesitant even with RedEmerald's OSX solution, simply because I can't vouch for the authenticity of what is in the build scripts.  In his case, I should be able to check one particular snapshot of his solution and sign it.  I don't like it, but there's not any other good options

Don't get me wrong, I will post your instructions, with a statement clarifying its origin.  And users can take that information into account whlie deciding how to access Armory.  But I bring it up, because your previous method was actually quite transparent: the .ebuild was cleartext, obviously referenced the github project, and gentoo users are going to find it trivial to copy that text into an .ebuild file and run it.  This one is a lot more opaque.  Is there at least a way for the user to check the .ebuild they got?

[justusranvier]

Is there at least a way for the user to check the .ebuild they got?

Of course.

The Layman command will clone the contents of this repository: http://git.overlays.gentoo.org/gitweb/?p=user/jranvier.git;a=summary into /var/lib/layman/jranvier. They'll have access to the entire git history.

The reason I made an overlay is because working with bare ebuilds is a PITA. Portage doesn't want to manipulate ebuilds unless they are in a properly-formatted repository so the user would need to have made their own overlay anyway. This way saves them a few steps.

Another thing that may be possible is adding an additional SSH key to the overlays.gentoo.org account so that you could clone the repository and update it yourself.