Archive for February, 2019

hanbot's Cuntoo Bake Test Notes - Part II

Sunday, 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. []

hanbot's Cuntoo Bake Test Notes - Part I

Saturday, February 9th, 2019

This is the first of what promises to be multiple posts on my progress against MP's gentoo to cuntoo bridge testing task.

First order of business: install heathen gentoo. BingoBoingo and asciilifeform of Pizarro swiftly and graciously set me up with an appropriate box once it was discovered this experiment wouldn't work on any of the 32-bit laptops laying around these parts.

I've been working with mod6's gentoo installation guide.

As Pizarro included a Gentoo LiveUSB for me, I skipped past 0x01, "Create LiveCD", to 0x02, "Setup Disk Partition Table". This section mentions a "Part B" with partition creation instructions that is not actually included, so I referred to the Handbook's guide. Here's how my partition table ended up before saving:


Device Boot Start End Blocks Id System
/dev/sdb1 2048 6143 2048 83 Linux
/dev/sdb2 * 6144 268287 131072 83 Linux
/dev/sdb3 268288 1316863 524288 82 Linux swap / Solaris
/dev/sdb4 1316864 312477695 155580416 83 Linux

I formatted the above partitions with filesystems as per mod6's guide, and then I followed the mounting steps remaining.

Downloading the Stage3 failed unexpectedly (a pattern that repeated itself with an exasperating insistence worthy of greater glories than a goddamned OS install).

Upon painstaking examination it came to the fore that the domain failed to resolve. I tried IP addressing directly via curl but of course the gentoo mirror's too clever for anything like that. In the end I was reduced to populating my hosts file with their intricate pattern of name allotments. Adding in all other various patches I ended up forced to put on it, my hosts file now reads:


64.50.236.52 gentoo.osuosl.org
140.211.166.134 gentoo.osuosl.org
64.50.233.100 ftp.osuosl.org

192.146.137.98 pool.sks-keyservers.net

64.50.236.52 distfiles.gentoo.org
140.211.166.134 distfiles.gentoo.org

During the tarball extraction stage in 0x03 I had to change the tar command's options as our source's current tarball is in .xz rather than .bz2 format; this means using tar xJpf rather than xjpf1 .

Moving on to 0x04, I entered the chroot as instructed. Then, on first running emerge-webrsync, I got a friendly eggog:


!!! Section 'gentoo' in repos.conf has location attribute set to nonexistent directory: '/usr/portage'
!!! Invalid Repository Location (not a dir): '/usr/portage'

Which did not reappear on running said command the necessary second time once distfiles.gentoo.org was added to my hostfile. Why domain resolution should affect directory problems is beyond me. At any rate, the second run of emerge-webrsync reportedly completed successfully.

I entered the mysterious mkdir -p /etc/ld.so.conf.d command to avoid the "problems" promised without it2 , at which point I went to cat /etc/fstab and discovered it's a 0-length file, completely empty. How this is possible I've no idea given the partition setup described above. I've elected to close this three-hour session of disappointment on the heels of searching for others' rants about empty fstab files, hoping for any notion of how this could be, and watching my browser grey over and crash.

***

  1. As tar ran this it spit out "tar:Xattr support requested, but not available", which makes me suspect this set of options may not, in fact, have done all that was intended. []
  2. I can't help but think that in this case my confidence in the Republic, which allows me to "just do it" like this comes at a possibly too-high cost of having not the first clue what this step was about. If this wasn't in-WoT I'd abandon the guide right there, you know? []