Logged Conversation (all times UTC)
[00:07] <stellar-slack> :clap:
[01:23] <sacarlson1> @matschaffer oh they have a deb file or repository for the stellar-core? and yes I'm on mint that's a derivitive of Ubuntu/debian I didn't see any deb files but I guess I just wasn't looking for them.
[01:25] <sacarlson> I also looked at your link and the pull/18 changes you made. love to see new docs reflecting the present thanks @matschaffer
[01:26] <stellar-slack> me too, sorry they got a little lax there
[01:26] <stellar-slack> anyway, we don’t have a proper apt repo yet, but we do push debs to a public S3 bucket
[01:26] <stellar-slack> ``` ❯ curl -s https://s3.amazonaws.com/stellar.org/releases/stellar-core/latest stellar-core-0.0.1-76-2ee44180_amd64.deb ```
[01:27] <stellar-slack> so https://s3.amazonaws.com/stellar.org/releases/stellar-core/stellar-core-0.0.1-76-2ee44180_amd64.deb
[01:27] <stellar-slack> just fpm, nothing fancy
[01:27] <stellar-slack> but it’s at least pre-built
[01:28] <sacarlson> wonderfull I'll try that first to see how that goes
[01:28] <sacarlson> see if I have any depedancy problems if so then I will consider docker
[01:32] <stellar-slack> I think libc should be the only dependency, but the version is particular
[01:32] <stellar-slack> or glibc or something along those lines anyway. I can seldom keep that whole chain straight
[01:32] <sacarlson> only 26mb I'm looking at the deb now
[01:36] <sacarlson> It shows all dependencies found but I think it might be missing the dependacy list
[01:36] <sacarlson> i've already installed it
[01:37] <stellar-slack> sweet. I’m still somewhat novice when it comes to deb packaging (always just lean on fpm or something similar) so let me know if there’s something amiss.
[01:38] <stellar-slack> I tried to learn how to repackage nginx months ago. I didn’t turn out well
[01:38] <sacarlson> as I expected stellar-core: /usr/lib/x86_64-linux-gnu/libstdc++.so.6: version `GLIBCXX_3.4.20' not found (required by stellar-core)
[01:39] <sacarlson> I've only done one deb package myself maybe I can add to this one the needed deps
[01:40] <stellar-slack> I’m basically doing this: ``` make install DESTDIR="${DEST}" fpm -s dir -t deb -n stellar-core -v "${STELLAR_CORE_VERSION}" -C "${DEST}" -p stellar-core-VERSION_ARCH.deb usr/local/bin/stellar-core ```
[01:47] <sacarlson> it apears I already have libstdc++-4.8-dev installed on my system but I guess this is looking for the older version 3.4.20? I don't see that available in my repository
[01:54] <sacarlson> I'm reinstalling this sudo apt-get install libstdc++6
[01:56] <sacarlson> nope no go same
[01:57] <stellar-slack> huh… odd. https://github.com/stellar/docker-stellar-core/blob/master/install is the setup we use on top of debian:jessie for the docker containers
[01:57] <stellar-slack> maybe that will help clear up what to do on mint?
[01:58] <sacarlson> debian may use older libs than ubuntu?
[01:58] <sacarlson> ya I'll just try compile it
[01:59] <stellar-slack> https://github.com/matschaffer/docker-stellar-core/tree/containered-build/build might help in that case
[02:00] <stellar-slack> I still haven’t yet sorted out how to get UIDs back to the right value after the build otherwise this would be in the stellar repo, but it does yield a binary
[02:35] <sacarlson> matschaffer I'm giving your install script a try manualy skiping the rm parts at the end
[02:35] <stellar-slack> good move
[02:35] <stellar-slack> that’s all there in service of minimizing the size of the docker container anyway
[02:35] <sacarlson> I'm wondering what parts of the llvm repository is being used
[02:36] <sacarlson> only thing I see maybe is lldb-3.6
[02:36] <sacarlson> I looked at the llvm site to see what it contains but there is a lot
[02:37] <stellar-slack> yeah, we use lldb-3.6 to process any core files that get produced
[02:37] <stellar-slack> but we actually defer installing most of it until after the build to avoid potentially picking up any other 3.6 stuff
[02:37] <sacarlson> it looks to also contain libstdc++6 but I thinking it will be older and my system will still link what's in my repository
[02:38] <sacarlson> ok so lets see what it does on a mint system
[02:39] <sacarlson> The following packages have unmet dependencies:
[02:39] <sacarlson> lldb-3.6 : Depends: liblldb-3.6 but it is not going to be installed
[02:39] <sacarlson> Depends: libstdc++6 (>= 4.9) but 4.8.4-2ubuntu1~14.04 is to be installed
[02:41] <sacarlson> see if there are newer ones in the repository
[02:47] <sacarlson> no it apears the libstdc++6 4.8.4 is the newiest that is available in the standard ubuntu repository. backporting would be required or compiled new version
[02:48] <sacarlson> witch leads me thinking back to looking at docker again, as I for see more of these missing parts to come
[03:00] <sacarlson> I've found the backport method for the 4.8.4 problem above is http://askubuntu.com/questions/428198/getting-installing-gcc-g-4-9-on-ubuntu
[03:23] <sacarlson> I'm now installing this backported 4.9.x above, one last try before moving to docker
[03:30] <sacarlson> ok that seems to have corrected the stellar-core dependancy also as now I get this far with run:
[03:30] <sacarlson> 2015-07-22T10:29:22.635 [] [default] FATAL Got an exception: No config file stellar-core.cfg found [main.cpp:398]
[03:32] <sacarlson> I also skiped the pip installs as I don't think I will need them pip install awscli; pip install boto
[03:43] <stellar-slack> sacarlson: yep, that’s good
[03:44] <stellar-slack> now you just need a config file
[03:44] <stellar-slack> https://github.com/stellar/stellar-core/blob/master/docs/stellar-core_example.cfg has the basic idea
[03:44] <sacarlson> my man thanks
[03:45] <stellar-slack> run `stellar-core -genseed` to make the values that go in PEER_SEED & VALIDATION_SEED, then put the public half of the VALIDATION_SEED into VALIDATORS
[03:45] <stellar-slack> set THRESHOLD to 1
[03:45] <stellar-slack> should be able to leave out the HISTORY.vs section
[03:46] <sacarlson> already ran the -genseed and worked ok with numbers
[03:46] <stellar-slack> you can give it the config file as an arg, or it’ll just look in `pwd`/stellar-core.cfg
[03:46] <stellar-slack> and yeah, boto is for ses
[03:47] <stellar-slack> awscli is for `aws s3 cp` which we use to persist history
[03:47] <stellar-slack> for your purposes, you probably don’t need either
[03:47] <sacarlson> ok
[03:47] <sacarlson> this first example above apears to be a 3 core setup
[03:48] <stellar-slack> good chance, I do a lot of those
[03:48] <stellar-slack> not sure which one you mean exactly though
[03:48] <stellar-slack> https://github.com/stellar/stellar-core/blob/master/docs/stellar-core_example.cfg is set up to peer with testnet
[03:48] <stellar-slack> you probably don’t want that since you’re liable to hit the same sort of XDR errors you did before
[03:49] <stellar-slack> or at least key format errors since testnet is still on base58
[03:49] <sacarlson> oh ok ya
[03:50] <sacarlson> yes I noted your base32 changes reflected in the address and keys
[03:51] <sacarlson> oh this won't work as my ruby libs are still using base58 also
[03:52] <stellar-slack> https://gist.github.com/matschaffer/0c908da5ff464735440f should do the trick (untested)
[03:52] <stellar-slack> I think the base58 rubylib updates may have landed by now
[03:52] <stellar-slack> 32 that is
[03:53] <sacarlson> no I don't think so I have the latist but I can check again
[03:53] <stellar-slack> I see some commits on https://github.com/stellar/ruby-stellar-base/commits/master that seem to reflect that
[03:53] <stellar-slack> looks like 0.1.1 of that particular lib. Not sure if scott pushed to rubygems or not
[03:54] <stellar-slack> but we’re using the ruby stuff in acceptance testing now and some tests are going green so there should be code somewhere you can use
[03:54] <sacarlson> oh 8 hours ago I was still sleeping ha ha
[03:55] <stellar-slack> yeah, it’s been a busy two days trying to land that change
[03:55] <stellar-slack> basically everything needed a bump as a result
[03:55] <sacarlson> but this looks to be base64 not base32 as I was expecting
[03:55] <stellar-slack> well I see “stellarkey” further down
[03:56] <stellar-slack> I think the mention of base64 may just be an option for the transaction encoding
[03:56] <stellar-slack> https://github.com/stellar/ruby-stellar-base/commit/7562ec5d157140ed613472e9c4667ab0c7622d81
[03:56] <stellar-slack> the base32/stellarkey thing was for the validation keys (and possibly account keys, not sure)
[03:56] <stellar-slack> definitely the validation keys though
[03:58] <sacarlson> ok I'll pull these new changes and give it a wack
[04:08] <sacarlson> I note in your stellar config pastebin above you have RUN_STANDALONE=false . don't we want standalone active here?
[04:10] <stellar-slack> you know, not sure actually
[04:11] <sacarlson> but I guess with THRESHOLD=1 it really doesn't mater as it's happy just seeing itself
[04:11] <stellar-slack> every example I can find on this end sets it to false
[04:11] <sacarlson> ok
[04:11] <stellar-slack> yep. Though I find I still need to start it with -forcescp
[04:12] <stellar-slack> --forcescp even
[04:12] <stellar-slack> you’ll also want to run it with --newdb to initialize the sql storage
[04:13] <sacarlson> and I also assume I need to modify the PEER_SEED= to my secret seed, if so what goes into VALIDATION_SEED= ?
[04:13] <stellar-slack> another secret seed from -genseed
[04:13] <sacarlson> ok I just run it two times
[04:13] <stellar-slack> ye
[04:13] <stellar-slack> yep
[04:13] <sacarlson> ok
[04:13] <stellar-slack> doesn’t really matter what the seed/keys are
[04:14] <stellar-slack> so long as they stay consistent and you have them paired up appropriately
[04:14] <stellar-slack> I believe the peer one is mainly used as an ID
[04:14] <stellar-slack> so you can have non-validating peers and still know how to recognize them definitively
[04:16] <sacarlson> oh so I really don't even need to change this to run it but would that conflict with an already running node then?
[04:16] <sacarlson> if they used the same validator codes?
[04:16] <stellar-slack> well it would if anyone happened to use the same keys
[04:16] <stellar-slack> in the same network
[04:16] <sacarlson> ok I'll change them just to be safe
[04:17] <stellar-slack> so basically yeah, you could just use the same ones since you’re only planning on keeping it to your one local node
[04:17] <stellar-slack> I doubt those keys are used anywhere, but pretty easy to run -genseed so I just change them
[04:17] <stellar-slack> our acceptance is driven from https://github.com/stellar/stellar_core_commander which actually generates new sets on every run
[04:19] <sacarlson> can I put comment in the config file with # ? will it handle this?
[04:22] <sacarlson> never mind I missed seeing you already had some in it
[04:26] <stellar-slack> yep
[04:26] <stellar-slack> pretty sure it’s just a TOML interpretter
[04:27] <sacarlson> 2015-07-22T11:26:55.443 [] [default] FATAL Got an exception: Failed to parse './stellar.config' :Unterminated string literal at line 20 [main.cpp:398]
[04:27] <stellar-slack> `"ll?level=debug`
[04:27] <stellar-slack> I missed the closing quote
[04:28] <stellar-slack> was trying to take off the partition in the example so we just get debug logging for everything
[04:28] <stellar-slack> will make it easier to see if we missed anything
[04:28] <sacarlson> almost there 2015-07-22T11:28:13.532 a39808 [] [default] INFO * The database has not yet been initialized. Try --newdb
[04:28] <stellar-slack> yep
[04:29] <stellar-slack> so next is `stellar-core --newdb` then `stellar-core --forcescp`
[04:29] <stellar-slack> then `stellar-core` should get things moving
[04:29] <stellar-slack> once it’s moving you can curl localhost:39132/info to make sure
[04:29] <stellar-slack> and watch logs of course
[04:29] <sacarlson> 2015-07-22T11:29:08.383 a39808 [] [default] INFO * The next launch will catchup from the network afresh.
[04:30] <sacarlson> 2015-07-22T11:30:15.726 a39808 [] [default] INFO * The `force scp` flag has been set in the db.
[04:30] <stellar-slack> so far so goo
[04:30] <stellar-slack> d
[04:31] <sacarlson> 2015-07-22T11:31:01.015 a39808 [] [History] FATAL No readable archives configured, catchup will fail. [HistoryManagerImpl.cpp:157]
[04:32] <stellar-slack> interesting
[04:32] <stellar-slack> does info say it’s synced?
[04:32] <stellar-slack> or did it just die
[04:32] <stellar-slack> anyway adding this should do it ``` [HISTORY.vs] get="cp /tmp/stellar-core/history/vs/{0} {1}" put="cp {0} /tmp/stellar-core/history/vs/{1}" mkdir="mkdir -p /tmp/stellar-core/history/vs/{0}” ```
[04:32] <stellar-slack> feel free to modify paths
[04:33] <stellar-slack> the vs doesn’t mean anything I’m aware of there
[04:33] <stellar-slack> a lot of our configs end up as [HISTORY.main]
[04:33] <stellar-slack> just needs to be some identifier that’s unique among [HISTORY] blocks in the config
[04:35] <sacarlson> http://pastebin.com/3m26PU5H
[04:36] <sacarlson> it ended in destroyed
[04:37] <sacarlson> I'm not sure where to add this history.vs above
[04:41] <stellar-slack> just at the bottom somewhere
[04:44] <stellar-slack> basically just append it to the end of the cfg
[04:44] <sacarlson> 2015-07-22T11:44:18.655 [] [default] FATAL Got an exception: Failed to parse './stellar.config' :Unidentified trailing character p---did you forget a '#'? at line 31 [main.cpp:398]
[04:45] <sacarlson> so maybe I took you line too literaly
[04:45] <sacarlson> take out the ``` ?
[04:46] <sacarlson> ``` [HISTORY.vs] get="cp /tmp/stellar-core/history/vs/{0} {1}" put="cp {0} /tmp/stellar-core/history/vs/{1}" mkdir="mkdir -p /tmp/stellar-core/history/vs/{0}” ```
[04:47] <stellar-slack> oh, we’re losing fidelity in the irc bridge I think
[04:47] <sacarlson> IC
[04:47] <stellar-slack> just look like this https://github.com/stellar/stellar-core/blob/master/docs/stellar-core_example.cfg#L94
[04:49] <sacarlson> 2015-07-22T11:49:14.263 a39808 [] [Herder] DEBUG emitEnvelope s:3 i:4 a:Synced!
[04:53] <stellar-slack> nice!
[04:53] <stellar-slack> so there you have it
[04:53] <stellar-slack> info should also report Synced as well
[04:53] <stellar-slack> and /tx should be able to accept encoded blobs from the ruby or golang client
[04:54] <sacarlson> that remains to be seen. so I'll point my ruby client at it with the corrected ports and see what pops out
[05:01] <stellar-slack> godspeed :)
[05:01] <stellar-slack> and nice work getting this far
[05:03] <sacarlson> couldn't have done it without you matschaffer or it would have probly taken me a year or so ha ha
[05:03] <sacarlson> thanks
[05:05] <stellar-slack> yeah, well here’s hoping the doc push going on right now will help iron some of that out
[05:27] <sacarlson> I'm not sure what I did but stellar-core seems to have frozen at sequence 224 after I started and stoped it a few times to setup a script to start it with
[05:27] <sacarlson> no errors in the logs
[05:28] <sacarlson> maybe there is a proper shutdown method?
[05:30] <stellar-slack> sending it a term is what we usually do
[05:31] <stellar-slack> what’s /info show?
[05:31] <stellar-slack> oh, make sure to -forcescp on the next startup btw
[05:31] <stellar-slack> if you don’t I’m pretty sure what it’ll do is sit there waiting to see SCP messages from a network that doesn’t exist (since it’s one node)
[05:32] <sacarlson> sending a term is that the same as c ?
[05:33] <sacarlson> { "info" : { "ledger" : { "age" : 1575, "closeTime" : 1437541649, "hash" : "55181e41148d591483cb2c60024fd5af91365c67ff255aa3dea27ce3081a6dc1", "num" : 224 }, "numPeers" : 0, "state" : "Joining SCP" } }
[05:34] <sacarlson> ok I'll try the -forcescp
[05:34] <stellar-slack> yeah
[05:35] <stellar-slack> ctrl+c is fine
[05:35] <stellar-slack> yeah, if it’s just sitting in joining scp the force should get it moving
[05:35] <sacarlson> so when I test I have a limited time window before it locks up like this?
[05:36] <stellar-slack> might be worth trying `RUN_STANDALONE=true` but it doesn’t look like I’ve ever used it
[05:36] <sacarlson> ok
[05:36] <stellar-slack> well, when you restart it picks up at the ledger it shut dow on
[05:36] <stellar-slack> but SCP itself usually waits to see other SCP message first
[05:36] <stellar-slack> unless you specify forcescp
[05:36] <sacarlson> so if I put in a transaction might that also start it?
[05:37] <stellar-slack> I suppose it’s possible, but my guess is not. Since it’ll probably just queue the transaction given it knows it’s in “Joining SCP” state
[05:37] <stellar-slack> basically the thing that gets you from “Joining” to “Synced” is either seeing SCP messages on the overlay network or forcing the transition
[05:38] <sacarlson> ya sounds like I need standalone or later just tie it to testnet
[05:39] <sacarlson> but your test look like you run on average 3 nodes so this would never happen to you
[05:40] <stellar-slack> well, it shouldn’t just lock up on its own I don’t think
[05:40] <stellar-slack> we’d probably want to check w/ the core devs to make sure
[05:40] <sacarlson> ya it's running again now after the -forcescp
[05:40] <stellar-slack> if it went to “Joining SCP” on its own then you restarted it, it’s probably worth trying that standalone flag or something
[05:41] <stellar-slack> there should be a way to just have it happily run on its own until it’s stopped or crashes
[05:41] <sacarlson> { "info" : { "ledger" : { "age" : 1, "closeTime" : 1437543679, "hash" : "d46e0831174da25b4c60cc59596ecbaa0aff55f4c381d8253af4f749f83c3790", "num" : 235 }, "numPeers" : 0, "state" : "Synced!" } }
[05:41] <stellar-slack> but yes, the only tests we run on 1 are pretty short
[05:41] <stellar-slack> anything longer than a few minutes is at least 2 nodes, usually 3 or more
[05:42] <sacarlson> ok I'm going to go eat and see when I come back if it's still running
[05:42] <stellar-slack> :thumbsup:
[08:30] <sacarlson> so all I'm getting now from sample create_account {"status"=>"ERROR", "error"=>"AAAAAAAAAAD////4AAAAAA=="}
[08:32] <sacarlson> stellar-core seems to be running ok "state" : "Synced!" seq at 2277
[08:34] <sacarlson> I've already installed the new ruby-stellar-base
[08:37] <sacarlson> this is the b64 I'm sending in blob b64: AAAAAKOYCM92gFQenUO5ROtl35rNw9QtNbvyqxVnJIb2XaJYAAAACgAAAAAAAAACAAAAAAAAAAAAAAABAAAAAAAAAAAAAAAAnOSq5R2Qyc/ymD44nnXBtsc0EqMbCYczmZR14YxO97kAAAAAHc1lAAAAAAAAAAAB9l2iWAAAAEAxzJIJHhPXRScFE032z6sMbc0ogBKicYYHkkkjkj8Lg18uKFDqXbSameS+Ss1T8mmdWsDAfZZX8S1h63l9okYG
[09:24] <sacarlson> first attempt at compile of new stellar-core on linux mint with CXX=gcc++-4.9 ; ./configure ; returns : checking for g++ >= 4.9... configure: error: g++ is < required version 4.9
[09:36] <sacarlson> my /usr/g++ had symlink to g++4.8 , I made new symlink from /usr/g++ to g++4.9 now ./configure ran ok
[09:53] <sacarlson> compiled ok
[10:09] <sacarlson> now running compiled stellar-core commit 2ee441...
[10:14] <sacarlson> but same error pursist on create_account {"status"=>"ERROR", "error"=>"AAAAAAAAAAD////4AAAAAA=="}
[11:01] <stellar-slack> Hello sacarlson
[11:03] <sacarlson> meetreks what's up?
[11:07] <stellar-slack> just finished design for the new gateway I am planning to build with Stellar
[11:08] <stellar-slack> should I now use the Core
[11:08] <stellar-slack> or the old Stellard?
[11:08] <sacarlson> best use the old stelard for now
[11:08] <stellar-slack> any suggestions
[11:08] <stellar-slack> OK
[11:08] <stellar-slack> thanks
[11:08] <stellar-slack> that would be good
[11:08] <stellar-slack> will PM you to discuss design and stuff like that
[11:08] <stellar-slack> is it OK
[11:09] <sacarlson> sure
[11:10] <stellar-slack> but
[11:10] <stellar-slack> looks like you use IRC
[11:10] <stellar-slack> and I cant PM you
[11:12] <stellar-slack> any suggestions?
[11:14] <sacarlson> you should be able to pm
[11:14] <sacarlson> not sure what irc bridge you use but many support pm
[11:15] <sacarlson> there are also 1000's of irc apps for windows
[11:15] <stellar-slack> can you PM me
[11:16] <sacarlson> nope
[11:16] <stellar-slack> why not?
[11:16] <sacarlson> I can pm stelar-slack but that's not you
[11:18] <sacarlson> https://kiwiirc.com/client/irc.freenode.net/#stellar-dev I just pm'ed myself
[11:19] <sacarlson> with kiwiirc.com I can also pm back
[11:19] <stellar-slack> email?
[11:19] <sacarlson> no irc
[11:20] <sacarlson> just click it
[11:20] <sacarlson> put in a nick name
[11:21] <stellar-slack> in now
[11:21] <sacarlson> as who?
[11:22] <stellar-slack> meetreks
[11:22] <sacarlson> nope don't see you
[17:13] <sacarlson> anyone haveing better luck than me with the new git releases
[19:58] <stellar-slack> sacarlson: our tests seem to like it so far. What’s it doing? (or not doing)
About StellarVerse IRC Logger
StellarValue IRC Logger
is part of