hanbot's Cuntoo Bake Test Notes - Part II

February 24th, 2019

See here for Part I of this adventure.

Part II could otherwise be dubbed "let me tell you how computers pissed me the fuck off today", and finds me back at square one with a LiveUSB in virginal state, utterly uncontaminated by the hours1 of time poured into it since last I ranted.

Given as I abandoned dicking about with heathen gentoo until such time as a Republican freeze is clearly available, my goal was simplified into bridging Pizarro's provided Gentoo USB with trinque's cuntoo.

Part I noted my sad fate of having to update /etc/hosts for every goddamned domain involved in grabbing working parts; by the end of the installment herein covered, I had to add:


161.0.121.198 ossassepia.com
104.131.72.249 btcbase.org
45.32.123.240 wot.deedbot.org
161.0.121.248 thebitcoin.foundation
161.0.121.247 trinque.org

As trinque pointed out, I'd require a working vtools. When I went to handle installation thereof, I found myself bootstrap-propelled to the center of the earth, at least theoretically. Having had a version of V on my local machines since asciilifeform's original release, I'd been enjoying a silent luxury in terms of adding on each block required to press a useful patch as they were available. Untangling the mess of what requires whichelse and in what order isn't especially helped by the fact that keccak-flavored vtools as discussed in the logs, my own site, etc, lived at this url, yet the post at that url is titled differently, namely as "vtools complete keccak prerelease". I also remembered having used gnat's gprbuild to get keccak vtools going, yet instructions for same appear in yet a different post.

Not having touched any of this in several months is, I'm sure, part of the problem I had, but let it be stated that getting a currently-useful vtools going without its precursors on board is currently more spaghetti than sandwich.

Anyway, as my working notes say, chill out, grab gnat, then all patches in the keccak-regrind or prerelease post depending on what we're calling it, press to the keccak head with an old V.

Though ave1's gnat is the current cannonical version, I decided to try diana_coman's adacore gnat alone to see if it'd work. This much was as straightforward as I remember, having needed it for phf's keccak vtools during the MP-WP regrind.


curl -v http://ossasepia.com/available_resources/gnat-gpl-2016-x86_64-linux-bin.tar.gz > adacore-gnat.tar.gz
sha512sum adacore-gnat.tar.gz
cat sha512sum-gnat.txt
tar -xvf adacore-gnat.tar.gz
cd gnat-gpl-2016-x86_64-linux-bin
./doinstall
...
cd /usr/gnat
PATH="/usr/gnat/bin:$PATH"; export PATH

...at which point gnatmake -v returns


GNATMAKE GPL 2016 (20160515-49)
herp derp FSF posturing

Then I was ready for V; I'm partial to mod6's ol' v.pl, principally because of his excellent documentation thereof.


curl -v http://thebitcoin.foundation/v/V-20180222.tar.gz > V-20180222.tar.gz
curl -v http://thebitcoin.foundation/v/V-20180222.tar.gz.mod6.sig > V-20180222.tar.gz.mod6.sig
gpg --verify V-20180222.tar.gz.mod6.sig V-20180222.tar.gz
tar -xvf V-20180222.tar.gz
mkdir .seals
mkdir .wot
mkdir patches

Now for vtools:


cd patches
curl -v http://btcbase.org/data/vtools/vdiff_fixes_newline_gcc.vpatch > vdiff_fixes_newline_gcc.vpatch
curl -v http://btcbase.org/data/vtools/keccak.vpatch > keccak.vpatch
curl -v http://btcbase.org/data/vtools/vdiff_keccak.vpatch > vdiff_keccak.vpatch
curl -v http://btcbase.org/data/vtools/vtools_fixes_bitrate_char_array.vpatch > vtools_fixes_bitrate_char_array.vpatch
curl -v http://btcbase.org/data/vtools/vtools_vpatch.vpatch > vtools_vpatch.vpatch
curl -v http://btcbase.org/data/vtools/vtools_fixes_static_tohex.vpatch > vtools_fixes_static_tohex.vpatch
curl -v http://btcbase.org/data/vtools/vtools_vpatch_newline.vpatch > vtools_vpatch_newline.vpatch

cd ..
cd .seals
curl -v http://btcbase.org/data/vtools/vtools_vpatch_newline.vpatch.phf.sig > vtools_vpatch_newline.vpatch.phf.sig
curl -v http://btcbase.org/data/vtools/vtools_fixes_static_tohex.vpatch.phf.sig > vtools_fixes_static_tohex.vpatch.phf.sig
curl -v http://btcbase.org/data/vtools/vtools_vpatch.vpatch.phf.sig > vtools_vpatch.vpatch.phf.sig
curl -v http://btcbase.org/data/vtools/vtools_fixes_bitrate_char_array.vpatch.phf.sig > vtools_fixes_bitrate_char_array.vpatch.phf.sig
curl -v http://btcbase.org/data/vtools/vdiff_keccak.vpatch.phf.sig > vdiff_keccak.vpatch.phf.sig
curl -v http://btcbase.org/data/vtools/keccak.vpatch.phf.sig > keccak.vpatch.phf.sig
curl -v http://btcbase.org/data/vtools/vdiff_fixes_newline_gcc.vpatch.phf.sig > vdiff_fixes

Itams got!


./v.pl p vtoolsp1 vtools_vpatch_newline.vpatch
cd vtoolsp1/vtools
gprbuild vpatch.gpr
gprbuild vdiff.gpr

I'd thought I would hereafter need phf's updated v.py, but on reflection it wasn't clear if or why this was actually needed. Moreover, trying emerge python-gnupg as specified by said update suggested this'd be fairly gnarly to install, so I decided to skip it for now.2

At this point all looked ripe for grabbing the actual cuntoo tarball & sig at long last.


curl -v http://trinque.org/cuntoo.tar > cuntoo.tar
curl -v http://trinque.org/cuntoo.tar.sig > cuntoo.tar.sig
gpg --verify cuntoo.tar.sig cuntoo.tar
tar -xvf cuntoo.tar

Which produced a bootstrap.sh and friends exactly as promised. We read, from the source, "make sure that you have a vdiff in your $PATH".

With the exception of the exportation in the gnat installation above, I have never run into $PATH operations without ending up in some sort of shitsoup. I would dearly love to comprehend what the fuck $PATH is for; what a path variable actually is; why some instructions specify a certain path variable and others not; how a path variable name is agreed upon; what exact file must be edited in order to add a directory to one's path; and so forth. I suppose it must be intuitive to others, because every attempt at explanation I've come across seems rooted in priors I simply don't have.

I edited ~/.profile to include export PATH=$PATH:/usr/gnat/bin/vtoolsp1/vtools3. After which which vtools reported t'wasn't none, and moreover said directory wasn't listed in my path. I tried editing ~/.bash_rc, no dice. I tried eliding the export part. Nada. I went over to Eulorum to review my notes on exporting path for a Eulora install, but was at a loss for what to replace the "CRYSTAL" and "LD_LIBRARY_PATH" items with. In multiple instances of bitching and moaning about paths I drudged up online, anonymous squawkers suggested the bash session had to be restarted in order for a path exportation and/or addition of a directory to the path to take effect.

To be honest, I had a feeling that killing my terminal and reconnecting wasn't a splendid idea, but I couldn't have told you why beyond a vague sense of "what if this fucks shit up". Well, I killed it. And reconnected. And found the LiveUSB fresh as a daisy, devoid of gnat, devoid of vtools, sans keys, pretty much ignorant of me.

For reasons I utterly fail to comprehend, there *does* remain a typescript log4 I'd started on day one or two of the whole shebang. That's it.

Yes, I'd had the same session going since I originally logged in around the 8th of this month. No, I hadn't been running it in a screen session. Yes, I'm going to start over, and in screen.

But we're going to need more vodka.

* * *

  1. Somewhere in the neighborhood of ten, about eighty percent of which I'd chalk up to mental wrestling with my own noobishness. []
  2. Specifically,
    Calculating dependencies... done!
    [ebuild N ~] dev-python/python-gnupg-0.4.3 PYTHON_TARGETS="python2_7 python3_6 -pypy -pypy3 -python3_4 -python3_5 -python3_7"

    The following keyword changes are necessary to proceed:
    (see "package.accept_keywords" in the portage(5) man page for more details)
    # required by python-gnupg (argument)
    =dev-python/python-gnupg-0.4.3 ~amd64

    Use --autounmask-write to write changes to config files (honoring
    CONFIG_PROTECT). Carefully examine the list of proposed changes,
    paying special attention to mask or keyword changes that may expose
    experimental or unstable packages.
    . []

  3. Yes, that's actually where I installed it, lazy as it may've been. []
  4. 2.7MB; I'll post this if anyone actually wants to go spelunking, please write in if so. []

5 Responses to “hanbot's Cuntoo Bake Test Notes - Part II”

  1. PeterL says:

    When you run a command in linux, $PATH is the path it takes trying to find your command, it is a list of directories that get looked in to find the executable.

    Make sure you are using the directory where vtools lives, not the name of the program itself.

    You shouldn't have to restart your session, you could either just enter "export $PATH=dir_to_add:$PATH" like you did with gnat, or since you put it in your profile script you could run that, ./.bash_rc

    Hopefully this helps?

  2. [...] of Cuntoo scripts continues. I am grateful bolder pioneers, especially hanbot, are running out ahead of me and taking ample [...]

  3. hanbot says:

    Okay, but check out the steps in e.g. 7 here: http://www.eulorum.org/Ubuntu ; if "CRYSTAL" is an "environment variable", why do some programs seem to require stating one whereas others don't? How's one to know whether such a thing is even necessary?

    I suppose I royally misunderstood the difference between runningbash_rc and restarting the bash terminal, at least --that makes sense.

  4. [...] Part II, I had my machine rebooted and re-attempted preparation for Cuntoo from scratch. I managed to wrap [...]

Leave a Reply