<stellar-slack> <lab> :clap:
DomKM has quit [Quit: Connection closed for inactivity]
sacarlson1 has joined #stellar-dev
sacarlson has quit [Ping timeout: 244 seconds]
<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.
sacarlson1 has quit [Quit: Leaving.]
sacarlson has joined #stellar-dev
<sacarlson> I also looked at your link and the pull/18 changes you made. love to see new docs reflecting the present thanks @matschaffer
<stellar-slack> <matschaffer> me too, sorry they got a little lax there
<stellar-slack> <matschaffer> anyway, we don’t have a proper apt repo yet, but we do push debs to a public S3 bucket
<stellar-slack> <matschaffer> ``` ❯ curl -s https://s3.amazonaws.com/stellar.org/releases/stellar-core/latest stellar-core-0.0.1-76-2ee44180_amd64.deb ```
<stellar-slack> <matschaffer> just fpm, nothing fancy
<stellar-slack> <matschaffer> but it’s at least pre-built
<sacarlson> wonderfull I'll try that first to see how that goes
<sacarlson> see if I have any depedancy problems if so then I will consider docker
<stellar-slack> <matschaffer> I think libc should be the only dependency, but the version is particular
<stellar-slack> <matschaffer> or glibc or something along those lines anyway. I can seldom keep that whole chain straight
<sacarlson> only 26mb I'm looking at the deb now
<sacarlson> It shows all dependencies found but I think it might be missing the dependacy list
<sacarlson> i've already installed it
<stellar-slack> <matschaffer> 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.
<stellar-slack> <matschaffer> I tried to learn how to repackage nginx months ago. I didn’t turn out well
<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)
<sacarlson> I've only done one deb package myself maybe I can add to this one the needed deps
<stellar-slack> <matschaffer> 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 ```
<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
<sacarlson> I'm reinstalling this sudo apt-get install libstdc++6
<sacarlson> nope no go same
<stellar-slack> <matschaffer> 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
<stellar-slack> <matschaffer> maybe that will help clear up what to do on mint?
<sacarlson> debian may use older libs than ubuntu?
<sacarlson> ya I'll just try compile it
<stellar-slack> <matschaffer> https://github.com/matschaffer/docker-stellar-core/tree/containered-build/build might help in that case
<stellar-slack> <matschaffer> 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
de_henne has quit [Ping timeout: 264 seconds]
de_henne has joined #stellar-dev
pixelbeat_ has quit [Ping timeout: 260 seconds]
stellar-slack has quit [Remote host closed the connection]
stellar-slack has joined #stellar-dev
sv-logger has quit [Remote host closed the connection]
koolhead17 has joined #stellar-dev
sv-logger has joined #stellar-dev
<sacarlson> matschaffer I'm giving your install script a try manualy skiping the rm parts at the end
<stellar-slack> <matschaffer> good move
<stellar-slack> <matschaffer> that’s all there in service of minimizing the size of the docker container anyway
<sacarlson> I'm wondering what parts of the llvm repository is being used
<sacarlson> only thing I see maybe is lldb-3.6
<sacarlson> I looked at the llvm site to see what it contains but there is a lot
<stellar-slack> <matschaffer> yeah, we use lldb-3.6 to process any core files that get produced
<stellar-slack> <matschaffer> but we actually defer installing most of it until after the build to avoid potentially picking up any other 3.6 stuff
<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
<sacarlson> ok so lets see what it does on a mint system
<sacarlson> The following packages have unmet dependencies:
<sacarlson> lldb-3.6 : Depends: liblldb-3.6 but it is not going to be installed
<sacarlson> Depends: libstdc++6 (>= 4.9) but 4.8.4-2ubuntu1~14.04 is to be installed
<sacarlson> see if there are newer ones in the repository
<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
<sacarlson> witch leads me thinking back to looking at docker again, as I for see more of these missing parts to come
<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
TheSeven has quit [Ping timeout: 246 seconds]
TheSeven has joined #stellar-dev
koolhead17 has quit [Remote host closed the connection]
<sacarlson> I'm now installing this backported 4.9.x above, one last try before moving to docker
<sacarlson> ok that seems to have corrected the stellar-core dependancy also as now I get this far with run:
<sacarlson> 2015-07-22T10:29:22.635 <startup> [] [default] FATAL Got an exception: No config file stellar-core.cfg found [main.cpp:398]
<sacarlson> I also skiped the pip installs as I don't think I will need them pip install awscli; pip install boto
<stellar-slack> <matschaffer> sacarlson: yep, that’s good
<stellar-slack> <matschaffer> now you just need a config file
<sacarlson> my man thanks
<stellar-slack> <matschaffer> 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
<stellar-slack> <matschaffer> set THRESHOLD to 1
<stellar-slack> <matschaffer> should be able to leave out the HISTORY.vs section
<sacarlson> already ran the -genseed and worked ok with numbers
<stellar-slack> <matschaffer> you can give it the config file as an arg, or it’ll just look in `pwd`/stellar-core.cfg
<stellar-slack> <matschaffer> and yeah, boto is for ses
<stellar-slack> <matschaffer> awscli is for `aws s3 cp` which we use to persist history
<stellar-slack> <matschaffer> for your purposes, you probably don’t need either
<sacarlson> ok
<sacarlson> this first example above apears to be a 3 core setup
<stellar-slack> <matschaffer> good chance, I do a lot of those
<stellar-slack> <matschaffer> not sure which one you mean exactly though
<stellar-slack> <matschaffer> https://github.com/stellar/stellar-core/blob/master/docs/stellar-core_example.cfg is set up to peer with testnet
<stellar-slack> <matschaffer> you probably don’t want that since you’re liable to hit the same sort of XDR errors you did before
<stellar-slack> <matschaffer> or at least key format errors since testnet is still on base58
<sacarlson> oh ok ya
<sacarlson> yes I noted your base32 changes reflected in the address and keys
<sacarlson> oh this won't work as my ruby libs are still using base58 also
<stellar-slack> <matschaffer> https://gist.github.com/matschaffer/0c908da5ff464735440f should do the trick (untested)
<stellar-slack> <matschaffer> I think the base58 rubylib updates may have landed by now
<stellar-slack> <matschaffer> 32 that is
<sacarlson> no I don't think so I have the latist but I can check again
<stellar-slack> <matschaffer> I see some commits on https://github.com/stellar/ruby-stellar-base/commits/master that seem to reflect that
<stellar-slack> <matschaffer> looks like 0.1.1 of that particular lib. Not sure if scott pushed to rubygems or not
<stellar-slack> <matschaffer> 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
<sacarlson> oh 8 hours ago I was still sleeping ha ha
<stellar-slack> <matschaffer> yeah, it’s been a busy two days trying to land that change
<stellar-slack> <matschaffer> basically everything needed a bump as a result
<sacarlson> but this looks to be base64 not base32 as I was expecting
<stellar-slack> <matschaffer> well I see “stellarkey” further down
<stellar-slack> <matschaffer> I think the mention of base64 may just be an option for the transaction encoding
<stellar-slack> <matschaffer> the base32/stellarkey thing was for the validation keys (and possibly account keys, not sure)
<stellar-slack> <matschaffer> definitely the validation keys though
<sacarlson> ok I'll pull these new changes and give it a wack
<sacarlson> I note in your stellar config pastebin above you have RUN_STANDALONE=false . don't we want standalone active here?
<stellar-slack> <matschaffer> you know, not sure actually
<sacarlson> but I guess with THRESHOLD=1 it really doesn't mater as it's happy just seeing itself
<stellar-slack> <matschaffer> every example I can find on this end sets it to false
<sacarlson> ok
<stellar-slack> <matschaffer> yep. Though I find I still need to start it with -forcescp
<stellar-slack> <matschaffer> --forcescp even
<stellar-slack> <matschaffer> you’ll also want to run it with --newdb to initialize the sql storage
<sacarlson> and I also assume I need to modify the PEER_SEED= to my secret seed, if so what goes into VALIDATION_SEED= ?
<stellar-slack> <matschaffer> another secret seed from -genseed
<sacarlson> ok I just run it two times
<stellar-slack> <matschaffer> ye
<stellar-slack> <matschaffer> yep
<sacarlson> ok
<stellar-slack> <matschaffer> doesn’t really matter what the seed/keys are
<stellar-slack> <matschaffer> so long as they stay consistent and you have them paired up appropriately
<stellar-slack> <matschaffer> I believe the peer one is mainly used as an ID
<stellar-slack> <matschaffer> so you can have non-validating peers and still know how to recognize them definitively
<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?
<sacarlson> if they used the same validator codes?
<stellar-slack> <matschaffer> well it would if anyone happened to use the same keys
<stellar-slack> <matschaffer> in the same network
<sacarlson> ok I'll change them just to be safe
<stellar-slack> <matschaffer> so basically yeah, you could just use the same ones since you’re only planning on keeping it to your one local node
<stellar-slack> <matschaffer> I doubt those keys are used anywhere, but pretty easy to run -genseed so I just change them
<stellar-slack> <matschaffer> our acceptance is driven from https://github.com/stellar/stellar_core_commander which actually generates new sets on every run
<sacarlson> can I put comment in the config file with # ? will it handle this?
<sacarlson> never mind I missed seeing you already had some in it
<stellar-slack> <matschaffer> yep
<stellar-slack> <matschaffer> pretty sure it’s just a TOML interpretter
<sacarlson> 2015-07-22T11:26:55.443 <startup> [] [default] FATAL Got an exception: Failed to parse './stellar.config' :Unterminated string literal at line 20 [main.cpp:398]
<stellar-slack> <matschaffer> `"ll?level=debug`
<stellar-slack> <matschaffer> I missed the closing quote
<stellar-slack> <matschaffer> was trying to take off the partition in the example so we just get debug logging for everything
<stellar-slack> <matschaffer> will make it easier to see if we missed anything
<sacarlson> almost there 2015-07-22T11:28:13.532 a39808 [] [default] INFO * The database has not yet been initialized. Try --newdb
<stellar-slack> <matschaffer> yep
<stellar-slack> <matschaffer> so next is `stellar-core --newdb` then `stellar-core --forcescp`
<stellar-slack> <matschaffer> then `stellar-core` should get things moving
<stellar-slack> <matschaffer> once it’s moving you can curl localhost:39132/info to make sure
<stellar-slack> <matschaffer> and watch logs of course
<sacarlson> 2015-07-22T11:29:08.383 a39808 [] [default] INFO * The next launch will catchup from the network afresh.
<sacarlson> 2015-07-22T11:30:15.726 a39808 [] [default] INFO * The `force scp` flag has been set in the db.
<stellar-slack> <matschaffer> so far so goo
<stellar-slack> <matschaffer> d
<sacarlson> 2015-07-22T11:31:01.015 a39808 [] [History] FATAL No readable archives configured, catchup will fail. [HistoryManagerImpl.cpp:157]
<stellar-slack> <matschaffer> interesting
<stellar-slack> <matschaffer> does info say it’s synced?
<stellar-slack> <matschaffer> or did it just die
<stellar-slack> <matschaffer> 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}” ```
<stellar-slack> <matschaffer> feel free to modify paths
<stellar-slack> <matschaffer> the vs doesn’t mean anything I’m aware of there
<stellar-slack> <matschaffer> a lot of our configs end up as [HISTORY.main]
<stellar-slack> <matschaffer> just needs to be some identifier that’s unique among [HISTORY] blocks in the config
<sacarlson> it ended in destroyed
<sacarlson> I'm not sure where to add this history.vs above
<stellar-slack> <matschaffer> just at the bottom somewhere
<stellar-slack> <matschaffer> basically just append it to the end of the cfg
<sacarlson> 2015-07-22T11:44:18.655 <startup> [] [default] FATAL Got an exception: Failed to parse './stellar.config' :Unidentified trailing character p---did you forget a '#'? at line 31 [main.cpp:398]
<sacarlson> so maybe I took you line too literaly
<sacarlson> take out the ``` ?
<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}” ```
<stellar-slack> <matschaffer> oh, we’re losing fidelity in the irc bridge I think
<sacarlson> IC
de_henne has quit [Remote host closed the connection]
<sacarlson> 2015-07-22T11:49:14.263 a39808 [] [Herder] DEBUG emitEnvelope s:3 i:4 a:Synced!
de_henne has joined #stellar-dev
<stellar-slack> <matschaffer> nice!
<stellar-slack> <matschaffer> so there you have it
<stellar-slack> <matschaffer> info should also report Synced as well
<stellar-slack> <matschaffer> and /tx should be able to accept encoded blobs from the ruby or golang client
<sacarlson> that remains to be seen. so I'll point my ruby client at it with the corrected ports and see what pops out
<stellar-slack> <matschaffer> godspeed :)
<stellar-slack> <matschaffer> and nice work getting this far
<sacarlson> couldn't have done it without you matschaffer or it would have probly taken me a year or so ha ha
<sacarlson> thanks
<stellar-slack> <matschaffer> yeah, well here’s hoping the doc push going on right now will help iron some of that out
<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
<sacarlson> no errors in the logs
<sacarlson> maybe there is a proper shutdown method?
<stellar-slack> <matschaffer> sending it a term is what we usually do
<stellar-slack> <matschaffer> what’s /info show?
<stellar-slack> <matschaffer> oh, make sure to -forcescp on the next startup btw
<stellar-slack> <matschaffer> 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)
<sacarlson> sending a term is that the same as <ctl> c ?
<sacarlson> { "info" : { "ledger" : { "age" : 1575, "closeTime" : 1437541649, "hash" : "55181e41148d591483cb2c60024fd5af91365c67ff255aa3dea27ce3081a6dc1", "num" : 224 }, "numPeers" : 0, "state" : "Joining SCP" } }
<sacarlson> ok I'll try the -forcescp
<stellar-slack> <matschaffer> yeah
<stellar-slack> <matschaffer> ctrl+c is fine
<stellar-slack> <matschaffer> yeah, if it’s just sitting in joining scp the force should get it moving
<sacarlson> so when I test I have a limited time window before it locks up like this?
<stellar-slack> <matschaffer> might be worth trying `RUN_STANDALONE=true` but it doesn’t look like I’ve ever used it
<sacarlson> ok
<stellar-slack> <matschaffer> well, when you restart it picks up at the ledger it shut dow on
<stellar-slack> <matschaffer> but SCP itself usually waits to see other SCP message first
<stellar-slack> <matschaffer> unless you specify forcescp
<sacarlson> so if I put in a transaction might that also start it?
<stellar-slack> <matschaffer> 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
<stellar-slack> <matschaffer> basically the thing that gets you from “Joining” to “Synced” is either seeing SCP messages on the overlay network or forcing the transition
<sacarlson> ya sounds like I need standalone or later just tie it to testnet
<sacarlson> but your test look like you run on average 3 nodes so this would never happen to you
<stellar-slack> <matschaffer> well, it shouldn’t just lock up on its own I don’t think
<stellar-slack> <matschaffer> we’d probably want to check w/ the core devs to make sure
<sacarlson> ya it's running again now after the -forcescp
<stellar-slack> <matschaffer> if it went to “Joining SCP” on its own then you restarted it, it’s probably worth trying that standalone flag or something
<stellar-slack> <matschaffer> there should be a way to just have it happily run on its own until it’s stopped or crashes
<sacarlson> { "info" : { "ledger" : { "age" : 1, "closeTime" : 1437543679, "hash" : "d46e0831174da25b4c60cc59596ecbaa0aff55f4c381d8253af4f749f83c3790", "num" : 235 }, "numPeers" : 0, "state" : "Synced!" } }
<stellar-slack> <matschaffer> but yes, the only tests we run on 1 are pretty short
<stellar-slack> <matschaffer> anything longer than a few minutes is at least 2 nodes, usually 3 or more
<sacarlson> ok I'm going to go eat and see when I come back if it's still running
<stellar-slack> <matschaffer> :thumbsup:
koolhead17 has joined #stellar-dev
koolhead17 has quit [Remote host closed the connection]
pixelbeat_ has joined #stellar-dev
<sacarlson> so all I'm getting now from sample create_account {"status"=>"ERROR", "error"=>"AAAAAAAAAAD////4AAAAAA=="}
<sacarlson> stellar-core seems to be running ok "state" : "Synced!" seq at 2277
<sacarlson> I've already installed the new ruby-stellar-base
<sacarlson> this is the b64 I'm sending in blob b64: AAAAAKOYCM92gFQenUO5ROtl35rNw9QtNbvyqxVnJIb2XaJYAAAACgAAAAAAAAACAAAAAAAAAAAAAAABAAAAAAAAAAAAAAAAnOSq5R2Qyc/ymD44nnXBtsc0EqMbCYczmZR14YxO97kAAAAAHc1lAAAAAAAAAAAB9l2iWAAAAEAxzJIJHhPXRScFE032z6sMbc0ogBKicYYHkkkjkj8Lg18uKFDqXbSameS+Ss1T8mmdWsDAfZZX8S1h63l9okYG
DomKM has joined #stellar-dev
<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
<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
<sacarlson> compiled ok
sacarlson has left #stellar-dev [#stellar-dev]
sacarlson has joined #stellar-dev
<sacarlson> now running compiled stellar-core commit 2ee441...
<sacarlson> but same error pursist on create_account {"status"=>"ERROR", "error"=>"AAAAAAAAAAD////4AAAAAA=="}
<stellar-slack> <meetreks> Hello sacarlson
<sacarlson> meetreks what's up?
<stellar-slack> <meetreks> just finished design for the new gateway I am planning to build with Stellar
<stellar-slack> <meetreks> should I now use the Core
<stellar-slack> <meetreks> or the old Stellard?
<sacarlson> best use the old stelard for now
<stellar-slack> <meetreks> any suggestions
<stellar-slack> <meetreks> OK
<stellar-slack> <meetreks> thanks
<stellar-slack> <meetreks> that would be good
<stellar-slack> <meetreks> will PM you to discuss design and stuff like that
<stellar-slack> <meetreks> is it OK
<sacarlson> sure
<stellar-slack> <meetreks> but
<stellar-slack> <meetreks> looks like you use IRC
<stellar-slack> <meetreks> and I cant PM you
ewufhu has joined #stellar-dev
<stellar-slack> <meetreks> any suggestions?
ewufhu has quit [Client Quit]
<sacarlson> you should be able to pm
<sacarlson> not sure what irc bridge you use but many support pm
<sacarlson> there are also 1000's of irc apps for windows
<stellar-slack> <meetreks> can you PM me
<sacarlson> nope
<stellar-slack> <meetreks> why not?
<sacarlson> I can pm stelar-slack but that's not you
testkiwiirc has joined #stellar-dev
<sacarlson> with kiwiirc.com I can also pm back
<stellar-slack> <meetreks> email?
<sacarlson> no irc
<sacarlson> just click it
<sacarlson> put in a nick name
<stellar-slack> <meetreks> in now
<sacarlson> as who?
testkiwiirc has quit [Client Quit]
<stellar-slack> <meetreks> meetreks
koolhead17 has joined #stellar-dev
<sacarlson> nope don't see you
Meetreks has joined #stellar-dev
koolhead17 has quit [Remote host closed the connection]
Meetreks has quit [Quit: http://www.kiwiirc.com/ - A hand crafted IRC client]
koolhead17 has joined #stellar-dev
koolhead17 has quit [Remote host closed the connection]
koolhead17 has joined #stellar-dev
koolhead17 has quit [Remote host closed the connection]
koolhead17 has joined #stellar-dev
koolhead17 has quit [Ping timeout: 246 seconds]
pixelbeat_ has quit [Ping timeout: 272 seconds]
<sacarlson> anyone haveing better luck than me with the new git releases
koolhead17 has joined #stellar-dev
pixelbeat_ has joined #stellar-dev
pixelbeat_ has quit [Ping timeout: 264 seconds]
koolhead17 has quit [Remote host closed the connection]
<stellar-slack> <matschaffer> sacarlson: our tests seem to like it so far. What’s it doing? (or not doing)
pixelbeat_ has joined #stellar-dev
Meetreks has joined #stellar-dev
Meetreks has quit [Quit: http://www.kiwiirc.com/ - A hand crafted IRC client]
pixelbeat_ has quit [Ping timeout: 244 seconds]
Kwelstr has quit [Quit: ugh]
pixelbeat_ has joined #stellar-dev
Kwelstr has joined #stellar-dev
DomKM has quit [Quit: Connection closed for inactivity]
pixelbeat_ has quit [Ping timeout: 246 seconds]