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

[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.