[Dev] Packaging feathercoind and feathercoin-qt on Linux

Wellenreiter

I’d prefer to keep the 0.11.x versions on the testnet.
Nevertheless @Lizhi ist using 0.11.2 on the prodnet. I asked him to specify his needs for the testnet, e.g. client versions to test compability and switch over to protocol version 4, but he didn’t come back to me.

May be I can spare some time to try the build on ubuntu 16.04… but… it’s my wifes Birthday next Sunday, so probably I’ll have other duties :d

UnklAdM

I’ve got a dev box at home with 14.04 LTS installed on it. Would getting this working on that help at all? If so, what version should I try?

I managed to get my primary wallet running on Centos 7 but that was a totally different scenario.

Just trying to help out, the wife passed 6 weeks ago and I’m trying to keep busy. I’ve been pretty active with Syscoin lately so a lot of this is pretty fresh to me.

- UnklAdM

AcidD

@UnklAdM - all I can say is I’m sorry man…

I’m attempting ubuntu 16.04 now and going with Feathercoin v0.9.3.1

wrapper

@UnklAdM said:

I’ve got a dev box at home with 14.04 LTS installed on it. Would getting this working on that help at all? If so, what version should I try?

- UnklAdM

There isn’t a problem with building on Ubuntu 14.04 or 15.04,

the problems are now finding why Feathercoin 0.9.3.1 doesn’t build for Ubuntu 15.10 (probably a bug in libboost1.58 Ubuntu dependency).

Looking into whether (the Centos problem) solution of upgrading to 1.59 can be done (compile from source) and run on standard installs of Ubuntu …

and testing 0.8.7.3 and 0.9.3.2 builds on Ubuntu 16.04

Source code :
https://github.com/FeatherCoin/Feathercoin

Build Instructions in /doc for wallet (feathercoin-qt) dependencies : multiwallet-qt.md
Build Instructions in /doc for daemon (feathercoind) dependencies : readme-qt.rst (only available in 0.8.3 currently)

Then (remove the --with-incompatible-bdb to retain 4.8 version dB)

make clean
./autogen.sh
autoupdate
./configure --with-incompatible-bdb
qmake -project
make

AcidD

So apparently it compiled…

Feathercoin-qt is 143.2MB

when I try to run it I get an error:
“Could not display Feathercoin-qt”

“There is no application install for “shared library” files. do you want to search for an application to open this file?”

=====
edit: WHOOOP!! IT WORKS
in terminal running sudo ./feathercoin-qt loaded it fine. it’s syncing the block chain now. Screen shots coming.

AcidD

BOOM CITY !!

wrapper

We might as well concentrate on 16.04 builds (for Ununtu) so …
Since 15.10 is soon to end support, there isn’t a great necessity to have a 9.3.1 build, especially since we can now produce 0.8.3.1 with the fixed dependencies.

I’ll upgrade / set up virtual box to confirm the build works.

I’ll start to look at some pushing updates to the build docs, ie can’t build 15.10 and updated dependency condition.

wrapper

@aciddude said:

So apparently it compiled…

Feathercoin-qt is 143.2MB

when I try to run it I get an error:
“Could not display Feathercoin-qt”

“There is no application install for “shared library” files. do you want to search for an application to open this file?”

=====
edit: WHOOOP!! IT WORKS
in terminal running sudo ./feathercoin-qt loaded it fine. it’s syncing the block chain now. Screen shots coming.

1st point - there is a compression method to reduce the size for release binaries

from : https://github.com/FeatherCoin/Feathercoin/blob/0.9.3.1/doc/build-unix.md

The release is built with GCC and then “strip bitcoind” to strip the debug symbols, which reduces the executable size by about 90%.

in Feathercoind case

cd src
strip feathercoind

2nd point - don’t run feathercoin-qt as sudo, otherwise the wallet will be put into root …

try running

cd ~/Feathercoin
./feathercoin-qt

or you need to run make install and run feathercoin-qt directly

3rd point found this reference to previous work Wellenreiter did on 0.9.3.1 build.

http://forum.feathercoin.com/topic/8168/building-feathercoin/9

wrapper

Other potential areas to Investigate current Feathercoin build issues :

FTC 0.9.3.1 - Building on Ubuntu 15.10

Possible other issues with rpcrawtransaction.cpp
Possible causes :
Miss match between Qt4 and Qt5 build requirements
rpcrawtransaction.h missing?
Task :
check sources re:
https://trac.macports.org/changeset/136010

Research why no rpcrawtransaction.h?

15.10 build error zxing in snapwidget.cpp:71
Possible causes :
Causes :
missing system path to zxing headers in snapwidget.cpp / snapwidget.h

Task :
Try building without QR codes

Run make clean on a fresh clone of FTC messages

checking for moc-qt5… no
checking for moc5… no
checking for moc… /usr/bin/moc
checking for uic-qt5… no
checking for uic5… no
checking for uic… /usr/bin/uic
checking for rcc-qt5… no
checking for rcc5… no
checking for rcc… /usr/bin/rcc
checking for lrelease-qt5… no
checking for lrelease5… no
checking for lrelease… /usr/bin/lrelease
checking for lupdate-qt5… no
checking for lupdate5… no
checking for lupdate… /usr/bin/lupdate
checking whether to build Feathercoin Core GUI… yes (Qt5)

Task :
Check negative checks

Results :
Moc5 - included in qtbase5-dev-tools
Note: qtbase5-private-tools is not installed try that result build still failed.

Investigate Bitcoin Github issue as cause

http://www.boost.org/users/history/version_1_58_0.html

wrapper

Just noting Commits on Aug 24, 2015
@enlighter @Bushstar
Update rpcrawtransaction.cpp

A fix in 0.8.7 was not transferred/updated at head to 0.9.3

Note: Have we a way of checking all “Feathercoinpatches” have been applied to the new version? Did we check any Litecoin only patches, that we “used” were brought into the Bitcoin Build?

Wellenreiter

We need to maintain release notes, specifying what was implemented in what version. Also the goal must be to have one production release only, which requires a good release planning.

@lizhi : can you add a release notes file, where you specify what you implemented, e.g ‘implemented ACP’ or ‘implemented bib 102’?
I know, that this also is part of a commit comment, so does anybody know a way to create the release notes from the github commit comments?

Wellenreiter

@aciddude said:

So apparently it compiled…

Feathercoin-qt is 143.2MB

when I try to run it I get an error:
“Could not display Feathercoin-qt”

“There is no application install for “shared library” files. do you want to search for an application to open this file?”

=====
edit: WHOOOP!! IT WORKS
in terminal running sudo ./feathercoin-qt loaded it fine. it’s syncing the block chain now. Screen shots coming.

I never had a problem to run feathercoin-qt as non-root user.
Can you tell what you did to get it compiled?
Did you modify the code?
Did you install additional libraries?

Wellenreiter

@wrapper : we should include the strip command in the packaging process and the stripped code NEVER ahould be committed to github, othwise debugging could become a pain.
Also I think that the 143mB binary is a result of static linking, qhwre all libraries are part of the binary. Dynamic linking should reduce the size also and has the advantage, that we don’t need to release a new version, if a library is patched

wrapper

@Lizhi @Ghostlander @Bushstar

Development procedure

@Wellenreiter Thanks for the update, it’s a complex situation and keeping close to Bitcoin development, at least takes advantage of all their testers.

Although, slower than it could be with dedicated paid staff, the open source “chaos” does seem to work. As you say, so far we have tried to make everything backwardly compatible, where that was not possible, members have moved to the new forks pretty well.

The main thing FTC seems deficient at is a guide or methodology for “upgrading” a Bitcoin fork to include all FTC specific enhancements / settings. Particularly as of the extra complexity of moving from Litecoin fork directly to Bitcoin core.

I could be wrong and Bush, Wellenreiter or Lizhi have a way of doing it but it would assist in finding members who could help, if we get everything documented now.

As far as testing 0.9.3.1 and above, the main thing we must do is test all FTC specific features have been included a work. Even if that is a simple as being “double checked” by someone …

That is the main effort should be in maintaining the fork difference.

We could have a Development thread called FTC additional packages, with each as a post, updated with “install in version” and checked by …

created by the first checker. From a list of commits to 0.6 to 0.8 Feathercoin Github?

List of FTC Pages and system settings / additional files

ACP
Name changes : Bitcoind changed to Feathercoind
images and icons
splash screen
eHRC
neoscrypt
Transaction fees
Block times
checkpoints

etc

Release procedure

To keep things simple and to allow others to help get involved, we also need an updated release procedure post.

It again would be a simple check list, from the git hub readme, so a checker can be allocated and sign of the release steps.

We could of course just point the forum to slight update to the Feathercoin readme, but having it on the forum would help members get involved, reduce errors and spread the development load from staff.

AcidD

@Wellenreiter said:

I never had a problem to run feathercoin-qt as non-root user.
Can you tell what you did to get it compiled?
Did you modify the code?
Did you install additional libraries?

:Edit, removed my rough draft.

see here
http://forum.feathercoin.com/topic/8556/guide-ubuntu-16-04-lts-compile-feathercoin-0-9-3-1-with-gui

Wellenreiter

I have added 32 bit packages for Ubuntu 15.10 and 16.04 to the ropsitory at https://software.opensuse.org/package/feathercoin

As usual the packages are under the ‘unstable’ branch, as they are not supported by the distribution owners.

wrapper

I am trying to learn about the OpenSuse build service and who owns what and what is where. Pretty mind blowing.

I noted that : the 9.3.1 build is complex because of bringing in and compiling associated dependencies.

Does this work with the straight 16.04 dev install, without compiling outside dependencies?. (probably not in case of zxing)
If not, it is OpenSuse suggested policy to build (such as zxing or BerkleyDB) as separate repositories, so others could use them and bring the binaries in from there (on the final “release” build). I have searched and no zxing is currently up.
I have registered Feathercoin-qt Opensuse build service name, for consideration as the official name, can pass it over appropriately.
I have researched becoming the Offical FTC openSuse package and have been given and possible way forward, to be assesd by the Factory as the official package. Passed on to Wellenreiter try that angle.

Wellenreiter

@wrapper said:

I am trying to learn about the OpenSuse build service and who owns what and what is where. Pretty mind blowing.

I noted that : the 9.3.1 build is complex because of bringing in and compiling associated dependencies.

Does this work with the straight 16.04 dev install, without compiling outside dependencies?. (probably not in case of zxing)

If you follow the guide I made for debian/ubuntu installs it should solve all dependencies, as you add my repository as package source and I’ve a xzing package for ubuntu there.

If not, it is OpenSuse suggested policy to build (such as zxing or BerkleyDB) as separate repositories, so others could use them and bring the binaries in from there (on the final “release” build). I have searched and no zxing is currently up.

The package name is ‘libzxing’ ;)

I have registered Feathercoin-qt Opensuse build service name, for consideration as the official name, can pass it over appropriately.

I have researched becoming the Offical FTC openSuse package and have been given and possible way forward, to be assesd by the Factory as the official package. Passed on to Wellenreiter try that angle.

AcidD

Random idea semi related. Now that Ubuntu builds have been done… maybe posting that on bitcointalk just to make people aware.

Ubuntu is a popular distro, makes sense no ?

wrapper

@Aciddude Re : To Announce all the builds available — That’s a great idea.

I would look better if we get all the links sorted so we/Wellenreiter are the official builds on OpenSuse.

There is a procedure, hopefully short, to apply to the Factory project maintainer. It would look better, especially announcing it.

I suppose the author could specify each of the "official " builds in a link - and go back later and update them if we end up adjusting the links to release builds.