log☇︎
900+ entries in 0.003s
mod6: s/one/on/
mod6: Heck, for what its worth, I know that there has been some talk about reorganziation of Pizarro's roles/responsibilities since after this latest round, that if I'm causing strife/headaches, I'd even be willing to split my shares between BingoBoingo and asciilifeform, and you guys can continue one.
mod6: TMSR~/The Foundation/Pizarro deserve better.
mod6: This year, I've done what I could with the time I have available, which, indeed, is far less time than I've had in say, '11-'16. I know I haven't produced as much as I would like this year, especially in July. I've had so much secular stuff come up, my head is spinning. But reality is, I barely have enough time to keep up with the logs.
mod6: So I should just do this on my own accord. Shall we make some arragements for someone to take over the Foundation? How can we go about this. I want to see TMSR~/The Foundation/Pizzaro succeed. Even if that means that I'm not a part of these any longer.
mod6: Or tell me to leave.
mod6: It seems like Mr. Popescu feels the same way. That I should be drummed out. We've known each other (all of us) for quite some time now. And I don't want to be a "problem" or "idjit" or whatever. Mainly, I don't want to force you all to kick me out. ☝︎
mod6: I think my head must be broken, because the stress of making a decision wrong is paralyzing.
mod6: I've been pondering mircea_popescu's reponse to the above link since the statement was made. I'm not sure how I went wrong here, but not adding to the existing SHA512 vtree is what I understood my instructions to be. ☝︎
mod6: le, could begin retroactively testing & adding these older submissions into the tree. ☟︎
mod6: http://btcbase.org/log/2019-08-01#1926112 << These go back to this, I did test those ones when they came in. iirc they did work alright when I tested them. I stopped adding these items to the working vtree (SHA512) when mircea_popescu said, and instead started working towards getting the keccak vtree built & then getting it onto cuntoo. Figured once there & stab ☝︎☝︎
mod6: Hey there
mod6: BingoBoingo: hope you feel better soon!
mod6: Seems hard to imagine, ya.
mod6: asciilifeform: ok, cheers.
mod6: yeah, oof. I saw your post re-'M', will try to read through here soon. I did see your benchmark comments above tho.
mod6: In a few days, once I'm caught back up, if still no one has tested this, I'll give it a try.
mod6: In light of recent conversations re: v (large genesis), ebuilds; this needs some review still. ☝︎
mod6: thanks asciilifeform! Just trying to catch up on logs/blogs atm. Been behind all month!
mod6: (My apologies for the delayed response). Anyway, long story short, we're in a bit of a holding pattern on new vpatches atm. ☟︎
mod6: http://btcbase.org/log/2019-07-19#1923606 << This is a neat-o vpatch 'who gave', but it came in just after the 'NO NEW WORK IN SHA PLOX'; so there are a few like this that probably will go into TRB main Vtree once the Lordship reviews/audits the proposed Keccak TRB Vtree; perhaps possibly after TRB has a new home OS/environment. ☝︎☟︎
mod6 re-reads
mod6: was thinking that perhaps you were headed in that direction.
mod6: Yes, it ~should~ depend on the musltronic_tools ebuild, it does need more testing though to ensure I have the proper useage of RDEPEND. Yeah, I did see the earlier discussion of including the source; I agree with that,
mod6: Hi diana_coman! Let me post what I did (simply as a discussion point - example), for those whom are following along: http://www.mod6.net/cuntoo/test/ebuilds/starter_v-99993.ebuild
mod6: (Also, should mention, I did see that diana_coman is working on her own ebuild, which is awesome, will most def. supersede what I was tinkering with last month.)
mod6: (We placed a halt on adding non-keccak vpatches last year.)
mod6: The idea being, once we're moved over to cuntoo, using keccak vtools & a keccak trb vtree, then the Foundation can go back to discussion of various patches that have been waiting in the lobby for some time.
mod6: But overall the focus has been to put forth directed effort into getting us over to cuntoo so we can stop using all of the buildroot things, and supporting debian, et. al.
mod6: I created one for ave1s musltronic tools (which won't fit the bill yet, because of circular dep. of GNAT), one for diana_coman's Vtools (which may not fit the bill 100% either, yet), and one for TRB. ☟︎
mod6: Recently, on workbench, I've been trying to build up TRB on cuntoo; and most recently (last month) dipping my toe into creating ebuilds.
mod6: mp_en_viaje: Yeah, have good intent, wanting to be helpful. However, I need to think through some of these things a bit better. Exercise more restraint and caution on such things.
mod6: http://btcbase.org/log/2019-07-17#1923012 << It's this old thing: http://therealbitcoin.org/ml/btc-dev/2016-November/000241.html ☝︎
mod6: http://btcbase.org/log/2019-07-17#1923008 << My apologies here. It was ill conceived to mention it at all. ☝︎
mod6: cheers, bbl.
mod6: Anyway, just throwing it out there as an alternative for you.
mod6: Then it should tunnel you through that remote host to connect to the bitcoin network and get blocks. Keep in mind that the example above is just that, and it also uses -connect, which is intended for connecting to a single node. You'll want to use -addnode for when connecting to more than one, and standard operation
mod6: LC_ALL=C ./bitcoind -myip=127.0.0.1 -proxy=127.0.0.1:56565 -connect=<SOME_REPUBLICAN_IP> -lows -verifyall &
mod6: Then when you start up TRB, you can do that like so:
mod6: Which will now allow you to tunnel over localhost port 56565...
mod6: ssh -o ServerAliveInterval=5 -o ServerAliveCountMax=3 -i ~/.ssh/key_for_remote_host_id_rsa girlattorney@A.B.C.D -D 127.0.0.1:56565
mod6: This would basically involve one to set up ssh-key based authentication to the remote host, then creating the tunnel with something like this:
mod6: One could connect a TRB node through a SSH tunnel (to a remote endpoint/host with a static IP) so you don't broadcast your IP.
mod6: Couple of other things that I wanted to mention quick, girlattorney: Just be sure to make frequent backups of your entire blockchain. Be aware also that TRB does not handle power-outtages very nicely as BDB can get corrupted; UPS and the like can help to mitigate this. ☟︎☟︎
mod6: an issue the 'stop' command to bitcoind, wait until it closes properly, then start back up with -addnode for a handful of trusted nodes (see command in http://thebitcoin.foundation/trb-howto.html in section 0x23 or at the very bottom 0x0D), which should sync you the rest of the way pretty quickly.
mod6: http://btcbase.org/log/2019-07-16#1922545 << I have found that if you -connect to a single (trusted TMSR~ node, for instnace http://thebitcoin.foundation/trusted-nodes.html) node to get caught up -- it'll get within 5 blocks of the head of the chain, then it'll start going through all of the mempool stuff. Eventually, it should catch up; however, if one is in a hurry to get those last 5 blocks sync'd, you c ☝︎
mod6: http://btcbase.org/log/2019-07-16#1922542 << There is a patch that is not part of the main TRB vtree that does this, but it'll have to be patched in manually. And it most likely would need to be "re-ground" to apply cleanly ontop of your current pressed tree. However, if we can find a time where we could work together on it, I might be able to help you get that part going. ☝︎☟︎
mod6: http://btcbase.org/log/2019-07-16#1922592 << ah! ok, had me worried there for a moment. ☝︎
mod6: Hey there, I've been pretty pinned down with some secular things in the past 10 days or so. Still catching up on logs+blogs here... saw the discussion earlier from girlattorney.
mod6: Good evening, here's this month's State of Bitcoin Address: http://therealbitcoin.org/ml/btc-dev/2019-July/000333.html
mod6: hmm.
mod6 looks
mod6: Anyway, if I could work around this issue, then I can make an ebuild that'll build ave1s stuff with this.
mod6: For completeness, this is what happens when you try to install AdaCore 2016 (binaries) on Cuntoo (keep in mind that the install actually does place the binaries in the expected places...): http://p.bvulpes.com/pastes/vX16f/?raw=true
mod6: http://p.bvulpes.com/pastes/IY76z/?raw=true << this is what I end up with, fwiw.
mod6: yeah, i think this was the issue.
mod6: alright, I'll have to go back and try to get this to build on here.
mod6: If the thinking is that it ~can~ be built on cuntoo, I'd much prefer an ebuild that would do that dance indeed.
mod6: so I never was able to build the ave1 musltronic tools on cuntoo, because no working gnat, I just bundled them up after I built them on a gentoo machine that had a working AdaCore 2016.
mod6: hey, sorry for the delay.
mod6: Anyway, I'm only just getting started with these. If there are glaring mistakes or feedback otherwise, please write in.
mod6: With everything in the right place... (I even needed a '/var/db/repos/mod6/metadata' directory with one file in it, 'layout.conf', that contains one single line: masters = cuntoo) then I was able to run a `ebuild ave1_musltronic_tools_x86_64-20180924.ebuild clean manifest install merge` and end up with the extracted contents in '/ave1_musltronic_tools_x86_64-20180924'.
mod6: To make this work properly, I built all of the ave1 musltronic tools on a gentoo instance with a 2016 AdaCore GNAT, then bundled up all of the binaries myself, and placed 'em on mod6.net for testing purposes.
mod6: trinque: http://p.bvulpes.com/pastes/4YG2X/?raw=true << Here is my **experimental only** ebuild, 'ave1_musltronic_tools_x86_64-20180924.ebuild'. I've been placing this file, while testing in a directory ' /var/db/repos/mod6/app-tmsr/ave1_musltronic_tools_x86_64'.
mod6: There will be a blog post I make about how I want through the ebuild process, but probably closer to month-end.
mod6: I still consider them "in-progress", but will forward what I have along to you here by Monday. (I wanted to get these ones built before the trb one - which I'm just starting on now.)
mod6: trinque: Speaking of an ebuild for ave1's musltronic tools, I've got one that works. I've also got one for diana_coman's keccak V tools package.
mod6: Yikes, week is a long time.
mod6: werd
mod6: Wasn't worth the long lines eh?
mod6: thx BingoBoingo!
mod6: Good evening, Lords and Ladies. Here's this month's Foundation Address, http://therealbitcoin.org/ml/btc-dev/2019-June/000331.html
mod6: Thanks gentlemen. bbs.
mod6: trinque: We'll get there.
mod6: Anyway, I'm gonna grab some food here. I'll work on a write up this weekend among other things. o7
mod6: *nod*
mod6: Otherwise, the 'rotor.sh' and 'rotor_bitcoin_only.sh' are not actually utilized. So we could cut those loose too, if desired.
mod6: I hope I'm not doing anything redundant really. The Makefiles itself take care of the compilation of Boost/BDB/OpenSSL. The one thing that I still need from the rotor.tar.gz is 'openssl-004-musl-termios.patch'
mod6: I've taken notes, I'll write up something on my blog as soon as I can. Just wanted to share the progress here. Obv. bunch more testing, etc.
mod6: it does seem that way, ya.
mod6: asciilifeform: I changed all of the CC, CXX, LD to point at all of the binaries located in the tarball I extracted from the build of Ave1's GNAT, like this one: /opt/20180924/x86_64-linux-musl-native/bin/gcc
mod6: http://p.bvulpes.com/pastes/olwpU/?raw=true
mod6: That seemed to resolve the problem. Let me do a wotpaste of the vpatch so you can see what I've done.
mod6: So I ended up adding '--disable-shared' to the BDB Makefile portion.
mod6: I ran into some trouble with BDB along the way because of a relocation record. '.rodata.values.2406'
mod6: I used diana_coman's vtron build with the same. Pressed the (yet unverified by lord keccak vpatch bundle that I created in January) keccak tree, made the changes in the makefiles, etc. Have a vpatch.
mod6: Evenin'. I've built trb on cuntoo with ave1's 20180924 tools, with rotor only. Quick test shows pulls connects, pulls blocks.
mod6: !!v 9576B7ED0D5102D8E77CB18D961923368E37CFF584872F2D2A6B4F3B56B2D45F
mod6: http://btcbase.org/log/2019-05-02#1910644 << Aha, yes it does. Thanks for the example link to get me thinking. Will switch it up on the next one. ☝︎
mod6: For what it's worth, still probably way out of my element on the whole thing, but can't hurt to read up on it.
mod6: http://104.131.72.249/log/2019-05-01#1910410 << >> http://104.131.72.249/log/2019-04-17#1908744 << I still need to get familiarized with this. I haven't had a chance yet in April. Will try to dig in over the next week.
mod6: Lords and Ladies of TMSR~, The Bitcoin Foundation's monthly State of Bitcoin Address: http://therealbitcoin.org/ml/btc-dev/2019-May/000329.html ☟︎
mod6: Evenin'
mod6: Evening TMSR~: The Bitcoin Foundation, STATE OF BITCOIN Address will be out in two to three days. ty!
mod6: Works! Thanks asciilifeform :]
mod6 checks
mod6: ahh
mod6: I'm not able to see btcbase.org/log either, from at least two different locations.
mod6: However, if it changes, I'll just re-arrange it in my mind.
mod6: Well, fwiw, I'm trying to not load in any Cisms or other pantsuit liquidshit into my understanding of FFA. So when reading it, I'm trying to approach it somewhat like a babe. And I thought that I had it at least, mentally fitting in my head the way it is today.