Bitcoin RPM packages for Fedora and Red Hat Enterprise Linux

[gmaxwell]

Interesting, how are the Bitcoin devs going to get around the ECDSA patent shit-fight that is causing all these problems in RH-derivative OpenSSL anyway?

The patent situation for ECC is highly over hyped. Mostly it's just optimizations which are patented (and mostly for characteristic 2 curves). In my prior review, it looked like what we were doing was fine.  There is also a lot of ecc patents expiring this year and next, further solidifying the situation.

[error]

Bitcoin 0.9.0 is now available in the repos. Sorry for the delay; this was a very large change and I had to spend extra time testing it and working out issues related to the large code refactoring that took place between 0.8.6 and 0.9.0.

[error]

Several OpenSSL-related security issues were announced today, some of which impact Bitcoin. OpenSSL in the repo has been updated. Please update and then restart bitcoind/bitcoin-qt to apply the updates.

[error]

We are now providing Bitcoin packages for RHEL 7, which was made generally available today.

[Carlton Banks]

Getting this error when trying "sudo yum install bitcoin"

Code:

http://linux.ringingliberty.com/bitcoin/el20/x86_64/repodata/repomd.xml: [Errno 14] HTTP Error 404 - Not Found

It seems the repo isn't where it's expected to be on the ringingliberty.com server.


Manually installing "bitcoin-0.9.2.1-1.fc20.x86_64.rpm" is a problem also, I'm getting:

Code:

error: Failed dependencies:
	libboost_chrono.so.1.54.0()(64bit) is needed by bitcoin-0.9.2.1-1.fc20.x86_64
	libboost_filesystem.so.1.54.0()(64bit) is needed by bitcoin-0.9.2.1-1.fc20.x86_64
	libboost_program_options.so.1.54.0()(64bit) is needed by bitcoin-0.9.2.1-1.fc20.x86_64
	libboost_thread.so.1.54.0()(64bit) is needed by bitcoin-0.9.2.1-1.fc20.x86_64
	libdb_cxx-4.8.so()(64bit) is needed by bitcoin-0.9.2.1-1.fc20.x86_64
	libminiupnpc.so.10()(64bit) is needed by bitcoin-0.9.2.1-1.fc20.x86_64

Which is strange, as I've already used yum to install those packages...

Code:

Installing : boost-program-options-1.54.0-9.fc20.i686                                                                 1/6 
  Installing : boost-thread-1.54.0-9.fc20.i686                                                                          2/6 
  Installing : boost-chrono-1.54.0-9.fc20.i686                                                                          3/6 
  Installing : libdb4-cxx-4.8.30-11.fc20.i686                                                                           4/6 
  Installing : boost-filesystem-1.54.0-9.fc20.i686                                                                      5/6 
  Installing : miniupnpc-1.9-1.fc20.i686                                                                                6/6 
Running post transaction command: /usr/lib/qubes/qubes-trigger-sync-appmenus.sh
  Verifying  : miniupnpc-1.9-1.fc20.i686                                                                                1/6 
  Verifying  : boost-filesystem-1.54.0-9.fc20.i686                                                                      2/6 
  Verifying  : libdb4-cxx-4.8.30-11.fc20.i686                                                                           3/6 
  Verifying  : boost-chrono-1.54.0-9.fc20.i686                                                                          4/6 
  Verifying  : boost-thread-1.54.0-9.fc20.i686                                                                          5/6 
  Verifying  : boost-program-options-1.54.0-9.fc20.i686

...which is making me think I've somehow got the wrong packages.

Has anyone else figured this one out? I'm a little stumped where I am now  

[Carlton Banks]

Well, the supposedly failed dependencies are present in /usr/lib/, and it's difficult to see how they're the wrong libraries, as the filenames are identical to those in the error output from rpm. Very mysterious.

It seems like whenever I try to use Fedora, there's always some teeth pulling job with a sparsely documented or plain cryptic solution!

[AliceWonder]

I see your problem.

You installed the RHEL/CentOS repo file instead of the fedora - so it is looking for el20 (enterprise linux 20) which doesn't exist.

Install the fedora repo file and it should work.

[Carlton Banks]

I see your problem.

You installed the RHEL/CentOS repo file instead of the fedora - so it is looking for el20 (enterprise linux 20) which doesn't exist.

Install the fedora repo file and it should work.

Legendary. Did the names of the failed dependencies give it away? Thanks for the help  

Still issues though. An error is thrown complaining that /var/lib/bitcoin cannot be created as the datadir. Running it from the commmand line as root has a different issue, it doesn't write the blocks it downloads to disk, and then refuses to shutdown. /var/lib/bitcoin doesn't get created, but /etc/bitcoin does.

[Carlton Banks]

Tried creating /var/lib/bitcoin as root before launching Bitcoin from the App Menu, here is the encouraging result:

Runaway exception

Exception: N5boot12interprocess22interprocess_exceptionE
No such file or directory

[AliceWonder]

I think it wants /var/lib/bitcoin/username

where username is your user and owned by your user.

I moved mine to /misc/bitcoin/username because I didn't want it on /var (/misc is a mount point I created for an additional drive) - I'm out of town until August so I can't look at my config unfortunately.

[error]

Huh. I don't think notifications are working because I didn't get any.

Anyway the GUI shouldn't be prompting you to create /var/lib/bitcoin, it should be $HOME/.bitcoin instead, so I think that's a bug. I'll take a look at that this evening. /var/lib/bitcoin is meant to be used by the server.

[Carlton Banks]

Huh. I don't think notifications are working because I didn't get any.

Anyway the GUI shouldn't be prompting you to create /var/lib/bitcoin, it should be $HOME/.bitcoin instead, so I think that's a bug. I'll take a look at that this evening. /var/lib/bitcoin is meant to be used by the server.

Yes, I've set ~/.bitcoin for the datadir. bitcoind still wants to use /var/lib/bitcoin even once bitcoin-qt has set datadir to ~/.bitcoin, and Armory reports stderr output from bitcoind that bitcoin.conf should be created at /var/lib/bitcoin/ with RPC user and password set. So I'm currently using Armory with bitcoin-qt to serve the blocks to it, instead of Armory launching bitcoind itself from /usr/sbin.

What's the purpose of /etc/bitcoin and /var/lib/bitcoin? bitcoind wallet in one and block data in the other?

[error]

Huh. I don't think notifications are working because I didn't get any.

Anyway the GUI shouldn't be prompting you to create /var/lib/bitcoin, it should be $HOME/.bitcoin instead, so I think that's a bug. I'll take a look at that this evening. /var/lib/bitcoin is meant to be used by the server.

Yes, I've set ~/.bitcoin for the datadir. bitcoind still wants to use /var/lib/bitcoin even once bitcoin-qt has set datadir to ~/.bitcoin, and Armory reports stderr output from bitcoind that bitcoin.conf should be created at /var/lib/bitcoin/ with RPC user and password set. So I'm currently using Armory with bitcoin-qt to serve the blocks to it, instead of Armory launching bitcoind itself from /usr/sbin.

What's the purpose of /etc/bitcoin and /var/lib/bitcoin? bitcoind wallet in one and block data in the other?

The (no-GUI) server uses these directories so that SELinux policies can be applied to restrict access to the Bitcoin configuration and wallet in server scenarios. This can't be done effectively if Bitcoin's data is in a user home directory.

Anyway I found the bug (it was something really obvious and stupid) and I'm rebuilding Bitcoin now. Though it will take a couple of hours before all the builds finish.

[Carlton Banks]

The (no-GUI) server uses these directories so that SELinux policies can be applied to restrict access to the Bitcoin configuration and wallet in server scenarios. This can't be done effectively if Bitcoin's data is in a user home directory.

The blockchain data is written to $HOME/.bitcoin with the setup you're describing, right?

[error]

The (no-GUI) server uses these directories so that SELinux policies can be applied to restrict access to the Bitcoin configuration and wallet in server scenarios. This can't be done effectively if Bitcoin's data is in a user home directory.

The blockchain data is written to $HOME/.bitcoin with the setup you're describing, right?

Only for the GUI (when the fixed builds are done). The server never uses anything in $HOME by default.

[Carlton Banks]

Anyway I found the bug (it was something really obvious and stupid) and I'm rebuilding Bitcoin now. Though it will take a couple of hours before all the builds finish.

So, your update has stopped bitcoin-qt working, stderror says:

EXCEPTION: N5boost12interprocess22interprocess_exceptionE       
Permission denied       
bitcoin in Runaway exception

Where is the config that tells Bitcoin-Qt to use /var/lib/bitcoin? How can I find out the contents of /var/lib/bitcoin and /etc/bitcoin if I can't access them as root?

[error]

Anyway I found the bug (it was something really obvious and stupid) and I'm rebuilding Bitcoin now. Though it will take a couple of hours before all the builds finish.

So, your update has stopped bitcoin-qt working, stderror says:

EXCEPTION: N5boost12interprocess22interprocess_exceptionE       
Permission denied       
bitcoin in Runaway exception

Where is the config that tells Bitcoin-Qt to use /var/lib/bitcoin? How can I find out the contents of /var/lib/bitcoin and /etc/bitcoin if I can't access them as root?

The Qt config is hidden in the $HOME/.config/Bitcoin directory.

For you, I would recover this way:

* Stop Bitcoin (you probably already have).
* Make sure the user .bitcoin directory exists, e.g. mkdir $HOME/.bitcoin
* (as root) Move your wallet and blockchain back to $HOME/.bitcoin, e.g. mv /var/lib/bitcoin/* /home/username/.bitcoin
* (as root) Reset the ownership for $HOME/.bitcoin recursively to your own user, e.g. chmod -R username.groupname /home/username/.bitcoin
* Fix SELinux security contexts, e.g. restorecon -r -v $HOME/.bitcoin
* Edit the $HOME/.config/Bitcoin-Qt.conf file and $HOME/.config/Bitcoin-Qt-testnet.conf file if it exists. and fix the path.
* Start Bitcoin-Qt.

[Carlton Banks]

[user@bitcoin .bitcoin]$ find Bitcoin-Qt.conf
find: 'Bitcoin-Qt.conf': No such file or directory
[user@bitcoin .bitcoin]$ sudo find /var/lib/bitcoin/Bitcoin-Qt.conf
find: '/var/lib/bitcoin/Bitcoin-Qt.conf': No such file or directory
[user@bitcoin .bitcoin]$ sudo find /etc/bitcoin/Bitcoin-Qt.conf
find: '/etc/bitcoin/Bitcoin-Qt.conf': No such file or directory

So apparently it's not in any of those locations... unless running find as root works as well as the other commands I've tried to use involving the system directories

Edit: found it...

[error]

[user@bitcoin .bitcoin]$ find Bitcoin-Qt.conf
find: 'Bitcoin-Qt.conf': No such file or directory
[user@bitcoin .bitcoin]$ sudo find /var/lib/bitcoin/Bitcoin-Qt.conf
find: '/var/lib/bitcoin/Bitcoin-Qt.conf': No such file or directory
[user@bitcoin .bitcoin]$ sudo find /etc/bitcoin/Bitcoin-Qt.conf
find: '/etc/bitcoin/Bitcoin-Qt.conf': No such file or directory

So apparently it's not in any of those locations... unless running find as root works as well as the other commands I've tried to use involving the system directories

I never said it was in any of those locations.

[error]

Anyway I've pulled this build as it's exposed an upstream bug that needs to be fixed. For now just do the manual recovery described in #57. And if you happened to install the bad GUI build, run

Code:

yum clean all; yum distro-sync

to back it out.