448600+ entries in 0.284s
mod6: and really, if you wanna follow along, it helps
to have
the historical
timeline 'in head' as well by reading
the logs since last October.
phf: i was actually
taking a harder position, if somebody wants
to follow along
they should read
the mailing list from
the beginning, and having it all accessible in one place for offline reading helps
phf: jurov: i don't
think
there's complete understanding as
to what should go into patchlist yet.
the one we have now is fine, and i'm sure it will be improved
mod6: a wise man
told me once: life is short and art is long.
mod6: anyway, we'll get
there.
shinohai: I have little better
that piques
the imagination
mod6: but pre-milestone release, it does get hard
to follow. and since I do believe it'll still be some
time before we get
the next milestone cut, I should prepare some sort of document so individuals can help
test. (we very much appreciate
the enthusiasm and
the help!)
shinohai: That would be
the easiest, releases
jurov: phf, if you can make better patchlist, are you willing
to contribute your script?
mod6: yah. we would certainly put all
the patches applied
to a specific baseline into RELEASE_NOTES.txt as it was for v0.5.3.1
ascii_field: (iirc
this was
the case in 5.3.1 actually)
ascii_field: mod6: i kinda assumed you and ben_vulpes would roll
the patch sequence docs into releases
mod6: i'm not sure what
to do about
this as far as
the email list is concerened, yet.
mod6: there are a number of different directions
these emails go in; patching for v0.5.3.1, pogotronic, gentoo, etc, etc. so I'll
try my best
to make
this apparent when I write up a patch list, etc.
mod6: so phf brings
to light a good point, reading
through
the email list, especially if you haven't read
the b-a logs from oct-14 on is probably more
than a bit hard
to follow. ascii_field brings up a good point about having a 'family
tree'
mod6: and
trinque, did you hvae
that -fPIC issue on gentoo with uClibC?
that's
the same error I was
talking about all last month and in
the SoBA
trinque: I wanna do some gcov work
this weekend
mod6: ascii_field: i did have a problem with it a number of days ago when I first
tried it, but it was just an environment related issue.
this build, I literally just did it, worked fine.
assbot: Logged on 03-07-2015 20:09:32;
trinque: ascii_field: got a barf about fPIC in boost, which iirc is already known
jurov: <mod6> one of
the
things
that pains me with
the SHA1s re-written into
the filenames, is if you pull
these files with curl, you have
to rename
them
to
their original names before you can verify
the signatures. << good point
jurov: <trinque> jurov: could
the btc-dev mailing list send mail via
tls? ok, considered
mod6: it should allow you
to sync off of mp's blockchain w/the appropriate cmdline params and
then do dumpblock/eatblock when it's finished or whatever you like.
ascii_field: but presently haven't
the
time
to do a proper job of it
mod6: i saw
that comment yesterday, I briefly looked at it's page ascii_field, I'll
take a deeper look at musl soon. hopefully
that'll get us further?
ascii_field: (author explicitly subscribes
to
the 'short, readable, and compatible'
thing)
phf: jurov: i'm not in a position
to make suggestions
to
the way
things are done in
the republic :) i used patches.html, i found some issues with it from
the perspective of figuring out what
transpired before i started paying attention, so i did extra work on
top. cura
te ipsum. i figured having mailbox available will make
the works of others after me easier
ascii_field: presently i suspect
that 'musl' is
the only glibc replacement
that has any promise
trinque: I'll restart from
the beginning and paste
the whole
thing
Jautenim: I coaxed it
to compile
the
turd but segfaults straight away
ascii_field: it was meant
to be a picture of my (at
the
time) set
assbot: Logged on 03-07-2015 19:03:32;
trinque: is
this stator archive meant
to be untarred overtop 0.5.3-RELEASE ?
mats: 0.25
to buy pogo for purpose of setting up node, if you are L1/L2
shinohai: @ mats O.o 0.1
to buy pogo wid ?
ascii_field: mats: iirc danielpbarron established
that it ~has~
to use ssd
☟︎☟︎ mats: ill bump it up
to 0.25
to subsidize purchase of 1tb spinning disk or a SSD
mats: no
takers for 0.1BTC
to pick up a pogo so far huh
ascii_field: probably
the most dire omission is any 'family
tree' for
the patches
phf: ascii_field: having a
turnkey solution is not
the intent behind my request (though i prefer
tools in my mail client
to messing around with lynx/wget.) i'm interested in having a "take
to mars" copy of bitcoind history. right now it's a bit all over
the place. patches here, email
text
there, etc.
trinque: but I see
the point clearly
trinque respects
the various buttons he's created for himself
to do all kinds of destructive
things
jurov: i have nothing against publishing
the mailbox
☟︎ ascii_field: my point is
that
this is Not Like Other Projects
shinohai: I don't
think I would want an automatic solution in
that regard.
phf: jurov: i only joined
the conversation recently, so i don't have a complete history of emails. of course i'm getting complete emails now, but not
the past ones
ascii_field: if
they loom large, it is because you are not spending
the requisite effort
ascii_field: the point, which i've been
trying and apparently failing
to make for ages, is
that if you are
thinking about automating
this, you are 'doing
things wrong'
trinque: could refine
that
to "and
then presents me a buffer of
the diff"
☟︎ assbot: Logged on 03-07-2015 19:44:53; phf: mod6: well, lets say you have something like mutt open with
the current email. it's pretty easy
to write a script
that
takes current email and feeds it
to an external script,
that splits out patch, verifies it with
the provided sig, and
then applies it
to
the codebase (or pushes it into some queue of patches as a case may be). i.e. you read
the email, push "p"
to do everything for you, and
then move on
to
the n
shinohai: ikr, I get it all in
the mailing list, no confusion
there.
jurov: um...er... if you want whole emails..then just receive
them?
ascii_field: put it
this way, if
tomorrow you are shipped
to alpha centauri with just
the reference client, you must be able
to set up bitcoin
there.
assbot: Logged on 03-07-2015 18:54:52; punkman: mod6, let me know if you want me
to rebase/resubmit cpuminer-snip or guicruft-snip before
the next release
mod6: [jurov run's
the mailman stuff, so he'd be probably more apt
to grok whatever your asking for ]
mod6: jurov: can you parse
this and understand what he's
talking about?? ^^^
ascii_field: ('disk' in
the broad sense of relatively slow, inexpensive place
to park bits)
phf: mod6: sorry, i wasn't really prepared
to explain what i mean, i
thought you would just grok
the request as an obvious one. we probably just have very different workflows
☟︎ assbot: Logged on 03-07-2015 18:49:20; mircea_popescu: ascii_field in practice
this may not be a problem.
the gavincoin insanities aside, growing by 300 bytes every
ten minutes may well be sustainable indefinitely into
the future.
mod6: phf:
there are specific reasons why
the attachments are split into separate files.
shinohai: mod6: if you want another auto.sh, I'll
try and help you when I understand
this new build xD
☟︎☟︎ mod6: But as I get
through more of
these and
test more of
these, I'll put something
together
to make
this process easier.
mod6: But I've only started scratching
the surface with alf's latest, so
this hasn't been done yet. All of
these are still in my "Highly Experemental" category. AKA: use at your own risk.
mod6: basically, instead of me making a whole bunch of different one-off scripts for peoples seperate clients and whatever stack
they've got, I just create one script
that will patch in & verify all
the scripts at once. usually after I've
tried and
tested
them all myself, peronsally.
mod6: are you asking me
to write an email client script?
phf: mod6: well, lets say you have something like mutt open with
the current email. it's pretty easy
to write a script
that
takes current email and feeds it
to an external script,
that splits out patch, verifies it with
the provided sig, and
then applies it
to
the codebase (or pushes it into some queue of patches as a case may be). i.e. you read
the email, push "p"
to do everything for you, and
then move on
to
the next email
☟︎ funkenstein_: "southern pride" spamming qntra in an effort
to discredit
the site methinks
☟︎ mod6: <+phf> mod6: no no each email. i
thought
that was
the whole point of ascii's approach, i.e. linux kernel style "read email,
think, apply
the patch" << im not sure what
their process is.
mod6: plus, create a How-To guide. Both of which need updating for
the flurry of recent patches
that have been submitted. Just haven't had a chance yet.
mod6: <+phf>
the process was needlessly complicated since my mail client lets me do a bunch of
those steps (patching, gpg verifying, etc) with a single key, so if i had an mbox, i could just import it, and
then use a more familiar interface << so, what I've done in
the past was; create a perl script
that pulls down and verifies all
the patches and applies
them
to a common baseline.
phf: mod6: no no each email. i
thought
that was
the whole point of ascii's approach, i.e. linux kernel style "read email,
think, apply
the patch"
mod6: so wait, you're just going
through each email and pulling out patches? or are you on
that part of jurov's website with
the signed patches?
mod6: ahh. im not sure i remember mbox. and yeah,
the whole
thing is a bit... unwieldly
phf: the process was needlessly complicated since my mail client lets me do a bunch of
those steps (patching, gpg verifying, etc) with a single key, so if i had an mbox, i could just import it, and
then use a more familiar interface
mod6: can you point me
to
the web-archive you're using? just curious.
phf: mod6: i don't necessarily have problems, i have a bitcoind with all
the patches up
to eatblock (haven't looked at stator yet, but
then i'm building with enemy
tools).
the way i assembled patches is by reading
through web archive and saving/verifying each patch as i saw it
shinohai: Then when I get
this new build up, I can sync up
to
the correct nodes, and .torrent dat chain.
mod6: heh,
this boost compile is
taking a while, because i'm also syncing at
the same
time haha
mod6: I'm creating a log of
this, and will post for everyone
to look at once complete.
mod6: which, btw,
they hvae patched in just fine... building
the whole
thing now.
trinque puts
the laptop in
the freezer while it builds boost
mod6: ex: are you
trying
to patch v0.5.3
to get
to v0.5.3.1? (You can just download
the release
tarball). Are you
trying
to patch v0.5.3.1-RELEASE with alf's patches? (must read emails
to figure out
the deps, OR you can just build
the stator which includes all of alf's patches with exception of dumpblock & eatblock),
those must be patched post extraction of
the stator
tarball -- of which im actually
testing now.
shinohai: The same
thing we do every night, Pinky.
Try and
take over
the world!
mod6: phf: anyway, what exactly is it
that you're
trying
to achieve?
BingoBoingo: On
that note, I'll brb in a few units of
time.