:: Re: [Libbitcoin] libbitcoin stack s…
Top Page
Delete this message
Reply to this message
Author: Amir Taaki
Date:  
To: libbitcoin
Subject: Re: [Libbitcoin] libbitcoin stack status, debian release
Hey, libbitcoin-blockchain should be ready. Now I've locked everything
and simply testing/doing bug fixing.
Final tasks for 2.0 release:
* Make sure both testnet and mainnet chains sync.
* Perform full validation on mainnet and testnet chains from block 0.
* Update gateway for DW to latest changes, and perform few days stress
testing.
Here is all the instructions for building the 2.0 toolchain:
https://wiki.unsystem.net/en/index.php/Install_entire_toolchain

On 01/03/2015 03:51 AM, Eric Voskuil wrote:
> Since it sounds like consensus is that (1) libbitcoin-blockchain will
> not be ready in time, and (2) that accepting Obelisk protocol breaking
> changes will be problematic, we have a clear path.
>
> Given that it will take some effort to get the version1 build up to the
> desired reliability, and that this will likely extend the lifespan of
> version1, I would like to take on a couple of work items that had
> previously been avoided.
>
> The objective would be to (1) achieve a similar level of reliability and
> maintainability as version2, in build, platform support and
> installation, (2) present consistent libbitcoin toolkit names and
> repository locations, and (3) avoid extending maintenance for deprecated
> spesmilo repos.
>
> The changes would be:
>
> 1) Change the libbitcoin-build generation for libbitcoin-server from the
> /protocol feature branch to a /version1 branch. Note that
> libbitcoin-server is a fork of Obelisk, and that Obelisk does not
> require sx or libwallet.
>
> 2) In libbitcoin-server/version1 rename libobelisk to libbitcoin-server
> and obelisk to bitcoin-server. This is already in the roadmap but was
> deferred in anticipation of the blockchain/protocol changes.
>
> 3) Add a libbitcoin-server script to register the server daemon(s). This
> capability can then be generalized into libbitcoin-build so as to
> incorporate it into the generated install script and executed via Travis.
>
> 4) Move libbitcoin/obelisk to spesmilo/obelisk. This is for
> deprecation/archival of the old name. This would result in the first
> consistent set of libbitcoin-* repositories.
>
> Note that BX speaks the original Obelisk protocol. Building BX
> side-by-side with libbitcoin-server would require a prefix build, since
> it builds against libbitcoin/version2 and libbitcoin-server will
> currently require libbitcoin/version1. However there are signed portable
> single file binaries for BX, so there is also the option to not even
> build it. Once we transition libbitcoin-server to libbitcoin/version2
> this issue will go away.
>
> WRT packaging, I would like to incorporate package generation metadata
> into libbitcoin-build. Richard, if you can provide a packaging script,
> or even just a rough outline for starters, I can generalize it into
> libbitcoin-build.
>
> e
>
> On 01/02/2015 03:10 PM, caedes wrote:
>> On 02/01/15 19:49, rdks wrote:
>>>> The goal is to produce an easy-to-install Darkwallet server, so
>>>> there's no point in packaging the version2 stuff if its server part
>>>> isn't ready yet. It would make more sense to package version1 for now.
>>>
>>> That basically is what I would have concluded, too.
>>> So I think the primary goal for Pablo and me would now be to get the
>>> version1 stack packaged so that it will preferably be available along
>>> with darkwallet 1.0.
>>>
>>
>>
>> Ok, we should start by having a page on the wiki for tracking this. I
>> think you should have enough information to start that, or if you
>> prefer, I can start it then you can maintain it.
>> Once we can track versions we need then we can track packaging status.
>> Some packages are really easy to make even if not ready, while others
>> can be painful.
>>
>> I guess we can start with: https://wiki.unsystem.net/en/index.php/Packaging
>>
>> But should be converted to a table format, and have rows for target
>> version and package status.
>>
>> Then we can add a little howto below or somewhere else.
>>
>> Cheers!
>>
>>
>>
>> _______________________________________________
>> Libbitcoin mailing list
>> Libbitcoin@???
>> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/libbitcoin
>>
>
>
>
> _______________________________________________
> Libbitcoin mailing list
> Libbitcoin@???
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/libbitcoin
>