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

justusranvier

legendary

Activity: 1400

Merit: 1013

Quote from: etotheipi on December 09, 2012, 01:01:52 PM

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.

etotheipi

legendary

Activity: 1428

Merit: 1093

Core Armory Developer

Quote from: justusranvier on December 09, 2012, 12:33:54 PM

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

Quote

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

legendary

Activity: 1400

Merit: 1013

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

Quote

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

legendary

Activity: 1428

Merit: 1093

Core Armory Developer

Quote from: justusranvier on December 04, 2012, 07:59:23 PM

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://bitcointalksearch.org/topic/armory-discussion-thread-56424

justusranvier

legendary

Activity: 1400

Merit: 1013

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.

Red Emerald

hero member

Activity: 742

Merit: 500

Quote from: etotheipi on December 04, 2012, 01:42:02 PM

Quote from: Red Emerald on December 04, 2012, 01:32:56 PM

Quote from: etotheipi on December 04, 2012, 11:56:20 AM

Quote from: justusranvier on December 04, 2012, 11:20:54 AM

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

etotheipi

legendary

Activity: 1428

Merit: 1093

Core Armory Developer

Quote from: Red Emerald on December 04, 2012, 01:32:56 PM

Quote from: etotheipi on December 04, 2012, 11:56:20 AM

Quote from: justusranvier on December 04, 2012, 11:20:54 AM

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

hero member

Activity: 742

Merit: 500

Quote from: etotheipi on December 04, 2012, 11:56:20 AM

Quote from: justusranvier on December 04, 2012, 11:20:54 AM

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

legendary

Activity: 1428

Merit: 1093

Core Armory Developer

Quote from: justusranvier on December 04, 2012, 11:20:54 AM

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

justusranvier

legendary

Activity: 1400

Merit: 1013

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.

justusranvier

legendary

Activity: 1400

Merit: 1013

Quote from: etotheipi on December 03, 2012, 01:38:17 AM

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.

etotheipi

legendary

Activity: 1428

Merit: 1093

Core Armory Developer

Quote from: justusranvier on December 02, 2012, 10:04:49 PM

Quote from: /usr/local/portage/net-p2p/armory/armory-0.85.ebuild

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

legendary

Activity: 1400

Merit: 1013

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.

Quote from: /usr/local/portage/net-p2p/armory/armory-0.85.ebuild

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

legendary

Activity: 1428

Merit: 1093

Core Armory Developer

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

legendary

Activity: 1400

Merit: 1013

Quote from: etotheipi on December 02, 2012, 09:41:07 PM

There are .desktop files in the dpkgfiles directory.

They get installed but there is no icon for them.

Quote from: etotheipi on December 02, 2012, 09:41:07 PM

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

legendary

Activity: 1428

Merit: 1093

Core Armory Developer

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

legendary

Activity: 1400

Merit: 1013

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

Quote

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

legendary

Activity: 1428

Merit: 1093

Core Armory Developer

Quote from: justusranvier on December 02, 2012, 08:52:22 PM

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

legendary

Activity: 1400

Merit: 1013

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

legendary

Activity: 1428

Merit: 1093

Core Armory Developer

Quote from: justusranvier on December 02, 2012, 08:44:12 PM

0.82.4 worked, but now with 0.85 I get this:

Quote

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)

Topic: Have you been waiting for Armory-Beta? Help me release it! (Read 4368 times)