436100+ entries in 0.293s
mod6: ok i
think i fixed
the dumpblock param issue, but it'll hvae
to wait until
tomorrow or when i have a bit more
time
to
test
trinque: I suppose he forgot
to unload it, bad luck.
ben_vulpes: i wrote
the kalash because it addresses needs of mine: being able
to run arbitrary bits of
the whole process
ben_vulpes: all of
these "do
this and
then do
that and
then do
the other
thing" shell scripts
that a) don't bail on error and b) aren't easily
twiddled drive me up a wall.
mod6: trinque: we're
talking about
the origina barf on 168`001
assbot: Logged on 23-07-2015 01:16:30; mod6: it barfs on
tx fb0a1d8d34fa5537e461ac384bac761125e1bfa7fec286fa72511240fa66864d in block 124`276
trinque: asciilifeform:
there's my debug.log a few lines up
decimation: my node (connected
to 'zoolog' is almost
to 316k, going faster now it seems)
assbot: Logged on 22-07-2015 22:16:20; mod6: so for
the record,
this is a "VerifySignature" failure, similar
to
that seen in February with 168`001
ben_vulpes: there is working on
the
thing and distributing
the
thing
hanbot: yeah, i
think i'll user yer kalash
to just get dependencies sussed before i revisit
this notion.
hanbot: right. but
then my question
to you (& mod6 ) would be, if
this is -the- way
to get it done, should
the RI be re-released
to reflect
that?
though again, if
the pain is in (reasonably straightforward) dependencies, rather
than
the release itself, i'd imagine
that's another matter.
ben_vulpes: i now have a kalash
that i can point at most linuxes, fire, and produce a static build
ben_vulpes: hanbot: i wrote it entirely fed up with doing
this dance every. single.
time.
hanbot: ben_vulpes ofc,
the dependencies arguably sh/could be handled before someone lands on RI stuff. hm. i guess i'll have
to self-debate a while.
BingoBoingo: ^ People demand knob with which
to hang self from. Get hung from knob.
hanbot: which i'm not sure will work out, but gotta
try
hanbot: ben_vulpes very cool. as said earlier, i'm explicitly going
the "painful" route 'cause
that's what stator ml post describes. i'd love
to use
the
tools you & mod6 have put up --just, not
the point of
this specific exercise
ben_vulpes: hanbot: i put my little kalash
together
to address some of
the pain you're experiencing
trinque: which are coming from
the compiler
trinque: hanbot: yep, because
those messages are coming from commands in
the build script, whereas further down
there are warnings galore of missing headers
hanbot: <trinque> hanbot: explosions suggest you are missing (or it can't find) boost openssl and db <<
this, despite " Found 'openssl-1.0.1g', skipping... Found 'db-4.8.30', skipping... Found 'boost_1_52_0', skipping..." ?
mod6: that /should/
tell
the
tale
mod6: if you need
to check
that you have indeed statically linked in openssl 1.0.1g into your binary, you can do
this: hexdump -C bitcoind | grep "1.0.1g"
trinque: it will
then at least bail out at
the first error, will otherwise happily derp past errors
to
the next command
trinque: hanbot: it may be helpful
to change
the script at
the
top, where it says /bin/sh, changing
to /bin/sh -e
mod6: well, if you see it again, let us know.
thanks!
mod6: im sure it didn't.
that's really bad.
gernika: mod6 restarting on
the same blockchain didn't help
mod6: This goes for all: If you get wedged for some reason while running
the R.I. please stop in and ask right away. Back up
the debug.log for us
too plz.
trinque: hanbot: dunno, I
tend
to stick
to gentoo
mod6: and in your memory you don't remember seeing
the "Verify Signature failure" in
there?
hanbot: so .deb package checked against .rpm file list shows libc_stubs.a missing,
the other eleven are present. debian says no .deb packages contain
this guy. i'm assuming i need it. auto.sh still errorful after grabbing everything else here
http://log.bitcoin-assets.com/?date=22-07-2015#1209888 (errorflurry:
http://dpaste.com/26ZEG17 ). doesn't look like
that missing library has anything
to do with it, but prolly problematic down
the line?
☝︎☟︎ mod6: you got wedged on
the 168`001 block? aka: you were stuck on block 168`000 according
to
this.. although, i dont' as of yet see a Verify Signature failure in here...
ben_vulpes: ;;later
tell pete_dushenski congrats, frere
mod6: gernika: sure, we should be beyond
that now with 1.0.1g but, we'll see.
mod6: my one gentoo (all ascii's patches
through verifyall x86-64/glibc) build got all
the way up
to where nsl is wedged. but my openbsd one is crawling along on verify all also... so far: height=220047
☟︎ mod6: for us we
thought
that
the 168`001 verify signature issue at first was due
to
the fact
that 168`000 is
the last checkpoint. but
totally unrelated.
threw us off for a bit
though.
punkman: trinque, you could recompile and make it skip
that one, find
the next weird one
trinque: I can
try a few other libressl versions later
tonight, I
think
mod6: it barfs on
tx fb0a1d8d34fa5537e461ac384bac761125e1bfa7fec286fa72511240fa66864d in block 124`276
☟︎ trinque: mod6: right,
that was
the last
that worked
punkman: trinque: yeah I
think I got stuck at
the same block using some other openssl version
gernika: mod6 let me know if
there's anything else I can do
to help with
this. Would suck if x% of pogos wedged at 168001
☟︎ mod6: <+mod6>
this
tx: fb0a1d8d34fa5537e461ac384bac761125e1bfa7fec286fa72511240fa66864d
mod6: <+mod6> ok so
those happen a bit...
then you hit block 124`275 and
then fail
to verify a
tx in block 124`276
to no avail
mod6: nice. put it somewhere for me
to look at.
mod6: do you hvae
the log?
gernika: Not sure how
to get
the
txid
mod6: any idea what block number it was? or
txid?
mod6: we saw stuff like
that before with
the 168`001 Verify Signature fail
too. most of
the
time it failed for us...
the
three of us who were independantly
testing it. But sometimes, it'd pass. Maybe 30% of
the
time. I was pulling my hair out.
☟︎ mod6: gernika: you just restarted it and
then it it verified
the sig?
ben_vulpes: i'm down
to a single finger and i intend
to kepe it
trinque: yup, keeps one from littering information about path structure
throughout
the script
ben_vulpes: only sane way
to manage implicit state of shell imho
trinque: mind if I bolt my gcov stuff
to it later in
the week?
mod6: <+gernika> mod6 stator, openssl-1.0.1g. << what did you do
to get around
this?
shinohai: I have rebuilt boost, made symlinks, and recited pages from
The Necronomicon, but still cannot get rid of /usr/bin/ld: cannot find -lboost_filesystem
hanbot: aha,
that link is a great lead, bless you
trinque.
trinque: build-essential is a big meta-package which only serves
to depend on many of
the other packages necessary for compiling
things
hanbot: if glibc on its own is insufficent
tho, i have little faith libc6-dev without
the -static moniker would work
hanbot: trinque have libc6-dev, no idea if
that's sufficient for ref imp building purposes. build-essential doesn't seem
to have any explicit reference
to static flavoring either.
trinque: probably pulled in by
that build-essential package
trinque: you'll need libc6-dev for
the headers and whatnot
trinque: I want
to say it's called libc6 on debian, and I don't see a separate static pkg
trinque: that said I could be wrong, and perhaps
the files required
to statically link are in a separate package
trinque: "static" would be in reference
to how your bitcoind is built against it and other libraries
trinque: hanbot: glibc should already be on
there; it is
the C standard library most commonly in use on linux
hanbot: mazel
tov pete_dushenski