Archive for the ‘Technical Training’ Category

A Little Bit of TinyScheme, a Lot of Cozonac

Monday, November 25th, 2019

There are few things as quintessentially Romanian, to my mind, as cozonac; the golden, nut-swirled, babka-like pastry dolled up and drummed out into the daylight for the two major Eastern Orthodox holidays. Then again, I'm not even so sure it's actually Romanian. Cozonac's one of those things that most states in the region boast as being their own, right up there with moussaka, smoked eggplant salad, goulash, and stuffed cabbage rolls. The diacritics and thus pronunciations may change, but not much else does. I guess it's proper, then, to introduce cozonac as an Eastern European thing, and to point out its specific spelling is Romanian.

Now that we've gotten there, we can promptly throw out a good half of what Romanians, and Eastern Europeans at large for that matter, think they know about cozonac. There are two main problems: the first's that folks don't put nearly as much of the awesome chocolate-walnut filling in their loaves of cozonac as they ought to1, and the second's that they put way, way, WAY too much sugar in it. A fairly common artifact of modern processed diets, the whole "dessert means heaps of sugar laced with occasional other ingredients" fanaticism is a hoary old positive feedback loop.

Thus armed with spite and sparseness, we can proceed to actually make some of this stuff. Except that I wanted to try out Mircea Popescu's image processor for blog articles, and also jfw's version of the same. Except! It turns out the box I'm using for publishing doesn't have Image Magick, required for both tools. An' I'm not happy about installing things --at all, much less things I don't know much about to "just get it to work". I do have Gimp, though, which was what I'd been using to process my pictures manually. And! It turns out Gimp uses TinyScheme, which wouldn't be a total waste of time to muck in a little as it's an interpreter of a dialect of Lisp, and maybe not too many layers removed from relevancy to learning to use some tools likely to survive the Republic's reckoning, thereby.

The following gets saved as batch-scaler.scm, to be placed in the ~/.gimp2/scripts directory:

(define (batch-scaler pattern
			new-width
			new-height)
	(let* ((filelist (cadr (file-glob pattern 1))))
		(while (not (null? filelist))
			(let* ((filename (car filelist))
				(image (car (gimp-file-load RUN-NONINTERACTIVE
								filename filename)))
				(drawable (car (gimp-image-get-active-layer image))))
			(gimp-image-scale image new-width new-height)
			(gimp-file-save RUN-NONINTERACTIVE image drawable filename filename)
			(gimp-image-delete image))
		(set! filelist (cdr filelist)))))

Note that I've put extraneous spaces between all multiple parentheses; you'll have to take these out. If someone has a better idea for preventing MPWP's cannonical footnote plugin from interpreting lisp parentheses as footnotes, please write in. The very MP in question has a fix for this in the comments, works splendidly.

Running it goes like so, from the directory where your selected but otherwise raw pictures are:

gimp -i -b '(batch-scaler "*.JPG" 1024 638)' -b '(gimp-quit 0)'

I scale my images when I re-size them, so I grabbed gimp-image-scale from the "Script-Fu Procedure Browser" and worked it into a batch processor, which goes through a glob of files according to the pattern given when running it (as long as the glob isn't empty) and then without loading the Gimp GUI, loads the pictures themselves, selects the drawable part, scales them according to whatever's set when running, saves them, and deletes the originals.

Some important problems: this only works for landscape-oriented images; you could pick out portraits, put them in a different folder and run this on them with different size parameters, but that's not so efficient. If I figure it out, I'll update this article, otherwise if anyone would care to modify this, please do. Ideally the width should be set to 1024 while preserving the aspect ratio, rather than manually specifying the length, too, regardless of orientation. Another thing to consider is that this creates one set of images, not a display size and larger size pair as in MP's process. Further, this just overwrites the images and saves them as such; the file-jpeg-save function takes fourteen, FOURTEEN, parameters, and I really can't be assed. So once the above is done,

ls -v | cat -n | while read n f; do mv -n "$f" "cozo-$n.jpg"; done

Then you can proceed to upload them as normal.

Anyway, I was saying: let's make cozonac. The instructions below are for two loaves, because who does this laborious stuff one output item at a time?!

First comes the filling. I typically make the filling the night before as it needs to cool completely before being used, otherwise it'll make steam pockets in the dough and fuck up the whole thing. Grind about a half kilogram of walnuts3 and add them to a saucepan in which you've dissolved about a tablespoon of brown sugar into 150ml or so of milk over low heat. Keep stirring; you want a paste-like consistency, for which reason you may use a little more or a little less milk. After it's thickened admirably, stir in a little rum.

cozo-1

And five or six tablespoons of unsweetened dark cocoa. Zest an orange or three and stir in the zest, too. Your mixture should be fairly thick, and very nicely scented. Set it aside, or put it in the fridge if you're saving the rest 'til tomorrow.

cozo-2

For the dough, melt 150 or so grams of butter into another 150ml or so of milk. Dump two more tablespoons of brown sugar in there, and once everything's dissolved and incorporated take it off the heat and zest two oranges and a lemon into it, and add some vanilla; either scrape the seeds into it or steep a pod in the milk while it heats, or better yet, do both.

cozo-3

Also while you're waiting for the temperature to drop, get something like 2/3rds of a kilogram of bread flour into a big bowl, add a pinch of salt, a teaspoon each of cinnamon and nutmeg, a handful or so of the best raisins you can find, and plenty --that's around 6 grams-- of dry yeast, and distribute it all evenly.4

cozo-4

Once this concoction's cool enough to touch but still warm, break three eggs into it and stir.

cozo-5

Now dump the wet stuff into the dry stuff, and knead it until it's pliable and doesn't stick to your hands too much. You might need to add a little more flour; not too much though, or your dough will be too tough. Once you're done kneading form the dough into a ball and let it rest in a warm kitchen under a slightly damp towel.

cozo-6

If your kitchen is cold, heat your oven for a few minutes, then turn it off and put the bowl in there. Leaving dough to rise in a cold place is begging for disappointment.

cozo-7

Once your dough has doubled, which should take anywhere from 45 minutes to an hour and a half or so, prepare a workspace for rolling. Your filling should be room temperature, either because you've let it cool for several hours or you've taken it out of the fridge a few hours before --note that very cold filling is no good here, as it'll cool the dough for its second rise and you'll be stuck waiting f o r e v e r to get your loaves in the oven.

cozo-8

Oil your countertop/foil-lined table/friend's back/whatever surface, and do the same with your rolling pin/wine bottle. Generously butter two loaf pans and sprinkle them with flour.

Divide your dough into quarters. For each loaf, roll out first one quarter and then the other into rectangles, until they're quite thin but not too thin to pick up. Spread each with a quarter of your filling, leaving small margins at the edges.

cozo-9

Roll these up lengthwise, then twist them together to make a floppy, unwieldy helix; immediately plonk them into the loaf pans before they get any unwieldier.

cozo-10

Brush them with an egg yolk beaten with a bit of milk, and let them rise another hour or two, until they've started to threaten the edges of the pans. Then bake at 200C, preheated if you're stuck with an electric oven, for just about an hour. After fifteen minutes or so in the oven, lightly cover the loaves with aluminum foil to keep the tops from burning.

cozo-11

Let them cool for a few minutes after taking them out, then remove them from the pans and cool them completely, resting on their sides, and switching sides occasionally. There's a delicate juxtaposition of dense chocolaty nuts and light, puffy dough inside --it has to cool down gently and evenly, hence all the elaborate dancing.

cozo-12

Once they're cool, slice and enjoy. Cozonac also freezes very well, and can even be eaten as frozonac, for the adventurous. All in all this is a rather heathen recipe, unlikely to be approved of by most Romanian cooks, who tend towards the strict and unexaminedly-traditional side. It is however highly praised by those whose opinions I actually care about, and owes something to the instruction of Ellie, whose basic discussion of procedure managed to somehow break through very heavy Hallmark-isms, Jesus worship, cups and cups of sugar, and other incompatibles to teach me something.

  1. "Ought to" maps, of course, to as much as MP would like, here. []
  2. I'm using 2.8, fwiw. []
  3. You can also add some measure of pecans, almonds, pistachios, or macadamias, though walnuts are the traditional, and really the best for this recipe. []
  4. You can also use fresh yeast, which imparts a pleasant flavor for those with a taste for it. It'll also cause your dough to rise a little faster, which isn't a bad thing. To do this, mix eight to ten grams of crumbled fresh yeast into the warm milk mixture after you mix in the eggs, which are coming. []

MP-WP Patch for Enabling HTML Comments

Monday, March 25th, 2019

...among other innocuous tags like bold, blockquote, and so forth.

This patch implements Daniel P. Barron's simple fix. Also included is a revision of the trilema-specific database interaction in wp-comments-post.php to the default wp_comments table as pointed out by diana_coman.

*Edit March 26th 2019: My first regrind was still fucked up, as Daniel P. Barron graciously pointed out yet again. I've reground again using correct syntax. So then:

The secondly-reground patch:
mp-wp_html-comments-regrind.vpatch

The corresponding sig:
mp-wp_html-comments-regrind.vpatch.hanbot.sig

---fuxed files, for posterior---

*Edit March 25th 2019: I've reground this patch based on Daniel P. Barron's catch of my incorrect use of a default rather than a variable table name. The reground versions are:

Reground patch:
mp-wp_html-comments-fixed.vpatch

Reground sig:
mp-wp_html-comments-fixed.vpatch.hanbot.sig

The old patch:
mp-wp_html-comments-enabled.vpatch

My old sig:
mp-wp_html-comments-enabled.vpatch.hanbot.sig

Grab my pubkey, if needed, on the about page, or send !!key hanbot to deedbot on Freenode IRC, while ye may.

hanbot's Cuntoo Bake Test Notes - Part IV

Sunday, March 17th, 2019

On the tail end of part III we were awaitin' the bootstrapper to finish its long and arduous whizzing.

I woke to find that a lot of kernel configuration awaited me as the result of "professional" negligence somewhere deep upstream. asciilifeform kindly provided a standard configuration to work against, so I set myself to y-in', n-in, and occasionally m-in'.

During which my hand-eye coordination got a little wobbly, and I killed the entire run with an unhappy hit of ctrl + c on the wrong keyboard. Because totally, this failure mode was thought about at some point, and it was decided in a stroke of genius that this innocuous operation oughta be capable of murdering arbitrary layers of a process.

Anyway, I proved to myself the value of the script produced in part III, as I had to run it yet again. I can't describe the second kernel configuration walkthrough as anything but pedantic white-knuckling. I kept a list of what trinque's kernel asked for that asciilifeform's configuration file didn't know about; interested parties can grab it here.

Sadly enough, I find that at the end of the config q&a, and hence the end of the bootstrapper script, I'm still left without a genesis with which to compare trinque's signature. Given which vdiff for instance shows vdiff in my path, I'm at a loss as to why no patch was produced. I also note that I lack even a cuntoo/portage directory.

The next steps being review of the script's record during the run, and deferment to the wisdom of the forum, I ask you: wtf?

hanbot's Cuntoo Bake Test Notes - Part III, with Prep Script

Friday, March 8th, 2019

Following Part II, I had my machine rebooted and re-attempted preparation for Cuntoo from scratch. I managed to wrap my head around the admittedly simple path problem previously encountered, and ran trinque's bootstrap.sh. As reported in #trilema, the process fell over on looking for the expected kernel configuration file. I'd used the default config/4.9.94-apu2 parameter. Apparently there's more to this than "preferring" your own. Whoops.

I went through both lobbes' and mod6's recent cuntoo adventure reports to look for clues on kernel configuration, and found I could replicate mod6's process of copying the .config file in /usr/src/linux into the cuntoo/config directory.

The bootstrapper's running now; I'm looking forward to seeing what it has to say in the morning.

Meanwhile, the multiple reboots throughout the process thus far meant I had to prepare my machine for the bootstrapper multiple times, which process naturally became easier but still took up a lot of time copypasting and filling in holes in my notes.

I threw the steps into a script, cuntoo-prepper.sh, with signature. Installation of gnat, V, vtools, and associated pressing and setup is included, along with signature and sha512sum checking where relevant. Depending on your setup, you may need to edit your /etc/hosts file to include the various domains involved before running the script1 :

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

Go with defaults during the gnat installation lest you end up tangled in directory confusion.

You'll have to manipulate your path a couple of times once the script's finished:


PATH="/usr/gnat/bin:$PATH"; export PATH
export PATH="/usr/gnat/vtoolsp1/vtools:$PATH"

Then do any futzing required for your kernel config, cd to your cuntoo directory, and hit it.

  1. Obviously if you need to enter 161.0.121.247 thewhet.net just to get the prep script, you'll need alla these too. []

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? []

hanbot's ZNC bouncer notes

Friday, August 31st, 2018

My current ISP, cavalcade of dipshits that they are, has taken to peppering my daily routine with disconnects, making an IRC bouncer necessary in the stew of damage control on my stove1.

ZNC's installation and initial configuration processes are painless enough. Make yourself a dir, cd into it, and grab source:


curl -s https://znc.in/releases/znc-1.7.1.tar.gz -o znc-1.7.1.tar.gz

Unpack, cmake, and install:


tar -xzvf znc-1.7.1.tar.gz
cd znc-1.7.1
cmake -DCMAKE_INSTALL_PREFIX="$HOME/where/you/want/it" -DOPENSSL_ROOT_DIR=/usr/bin2
make
make install

Then create a config file by specifying the full path of your installation in the prefix above followed by --makeconf . ZNC's docs suggest znc --makeconf alone will do this; ten wasted minutes of my life suggest otherwise.

You'll have to pick a port for ZNC to listen on among the prompts that follow. Otherwise, default options've proven fine for me. Launch ZNC when prompted at the end of the configuration dialogue.

Now all that's squared away, official docs and search result flotsam step in with the true timewasting bullshit of dropping anything resembling actionable steps, sense, or the English fucking language. All IRC users are also goats of the same age and gender, right? No need to declare antecedents for "the" password, just dandy to specify "server" password in some forms but not others, certainly no problem to be explicit to the degree of telling folks to cd to a fucking directory but neglecting to mention which network components need what information, and where.

So then, first tell ZNC where you want it to connect via the same's webadmin. Point your browser to http://your.server's.ip:portyouspecified/ . Log in, mosey to "Your settings" on the right-hand menu, and add a network with irc.freenode.net, port 6697. Check the SSL box. Put something you like in the "network name" field up top. Hit "save and return" at the very bottom of the page.

Now, tell your IRC client how to connect to ZNC. I used xchat, where this stuff is accessed under xchat/network list. Click "Add", highlight the stupid default server name that pops up, and enter your.ZNC.server's.ip:portyouspecified . Yes, the separator shows in established server details as a forward slash. Yes, the syntax is actually a forward slash. No, entering the same forward slash will not fucking work, it'll overwrite what you entered with the original default bullshit. Give it a colon; it'll convert it into a forward slash on return. This shit's so enraging they ought to market it as a depilation treatment.

Anyway, in the User name field, enter your ZNC admin name, forward slash (no kidding, it works on its own now), network name from the ZNC webadmin network settings (that very same something you like). The server password is the same as your ZNC webadmin password. Feed it your Nickserv password if it makes you happy. Close the dialogue and connect.

***

  1. Shitty mixed metaphors brought to you by hours of enraged wrangling; may this guide spare you similar emissions. []
  2. This is the Pizarro shared box's openssl path at the time of this writing, change as needed. []

MP-WP: Genesis Regrind

Monday, June 11th, 2018

Cause for this regrind consists of the lack of a proper manifest file as per the official Republican spec, along with the incorrect directory structure, both of which have been addressed in this new genesis vpatch.

The recently-released patch for comments has been included, as has a minor cosmetic/derpatic change to image files, the names of which no longer contain spurious remnants of their pre-svgization filetypes.

Files:
* mp-wp_genesis.vpatch
* mp-wp_genesis.vpatch.hanbot.sig

Note: this genesis was built and press-tested with phf's vtools, via its keccak head.

MP-WP: Fix for Comments vpatch

Tuesday, May 29th, 2018

Previously, fresh installs of MP-WP required a fair amount of futzing1 before comments would work.

This vpatch modifies /blog/wp-comments-post.php and the comments.php files in both themes' subdirectories such that commenting should work without any configuration requirements upon instalation, keeping MP's antispam functionality intact, naturally.

Files:
mp-wp_comments-fix.vpatch
mp-wp_comments-fix.vpatch.hanbot.sig

This patch is just shy of three weeks late, the fact of which is about as embarrassing as why: I still retain certain cockroaches. Three weeks' worth of "dude I still haven't made that patch" sessions is how long it took me to realize the only way this was getting done, by me anyway, was with a fucking pen and a sheet of paper, and writing out a "stupid" "unnecessary" graph of the problems and the attempted solutions, with their results. 'Cause I oughta be able to just do it, right? Harr.

Anyway, next up is MP's request for a mass file uploader.

  1. Copy-pasting the $suffix string between one of the two included themes' comments handler and the top-level post file in the case of the "Default" theme, and modifying both said string and comment field variables when using "Classic". []

MP-WP Genesis

Friday, April 13th, 2018

If you'd like to use Mircea Popescu's modified Wordpress (as used on Trilema, here, and many blogs of the Republic), I've made a V genesis to be maintained in perpetuity, with patches shortly to come.

Available files:

* mp-wp_genesis.vpatch
* mp-wp_genesis.vpatch.hanbot.sig

Mosey over to the about page if you need my pubkey.

Many thanks to mod6 for his indispensible Vtron, phf for his vpatcher and tools, spyked for his patches of same, asciilifeform for V in general, diana_coman for her help getting started with gnat, and of course Mr. P for the eponymous codebase and support.