Welcome to johnbintz.com

Resurrecting dokuwiki-sandstorm & How to Take Over Sandstorm App Packaging

Jul 06, 2020

I’m now maintaining the Sandstorm App Store version of DokuWiki, a nice, lightweight wiki webapp.

I use DokuWiki along with Wekan to organize my comic and animation projects. Both The Wizard and The Metalsmith and Rabbit with 1000 Repos have a combo of DokuWiki for scripts, marketing details, links/reference material, and other long-form text content, and Wekan is my big ol’ kanban board for managing work.

Since the original DokiWiki was a few years out of date, and a lot has changed both in DokuWiki and the PHP world in general, the app’s going to be updated slowly to the latest revision, so those folks with plugins installed that may fail on newer DokuWikis have time to get that resolved before new versions come along. Check the GitHub Repo for more information on that process, and if you have PRs/questions/etc.

I want to take over a Sandstorm app! How do?

So you have a favorite app you want to start maintaining, and it might even be one of mine if I decide to stop maintaining Hugo or DokuWiki. How do you take it over? Well, here’s the process I went through with taking over Hugo and DokuWiki. This is current as of July 2020.

  1. You’ll need a Keybase account. Depending on what Zoom does with Keybase, this info may become out of date.
  2. Install Vagrant and vagrant-spk.
  3. Get the project running locally, in its current state and at the version matching what’s in the App Store. Depending on the quality of the project’s repository and the project itself, this may be very easy or very hard. This might also require a lot of internet searching, lots of machine provisioning and reprovisioning using Vagrant, learning how to log debug output to stdout and stderr from whatever services encompass the app, and poking around a running grain using vagrant-spk enter-grain. Unless something is truly broken, this is not the time to fix up minor annoyances.
  4. Export this unupdated app to a .pkg file via vagrant-spk pack. You’ll have to do the GPG and Keybase dance to be able to sign the package, so create a GPG key if you don’t already have one. Commit and push a new branch with this set of modifications so you can roll back to this state easily.
  5. Upgrade the app. Depending on the application, this may involve a small upgrade at first, or may involve going straight to the latest version. I went to the latest version with Hugo and added a note about breaking changes in the admin area of the app as well as on the app’s app store page. With DokuWiki, I planned a set of smaller upgrades, taking a few weeks to get up to the latest version, since DokuWiki is a much more complicated piece of software to upgrade than Hugo.
  6. Get the updated app running correctly, and export it to a different .pkg file via vagrant-spk pack.
  7. Create a fake Sandstorm project that doesn’t have an app associated with it using vagrant-spk init in an empty folder. Install the unupdated app via direct upload of the .pkg file into this fake project and make sure it works correctly, spawning whatever grains you need to for testing. You do not need to use vagrant-spk dev for this part. Starting the VM gives you a sandboxed Sandstorm to mess with without doing anything else.
  8. Upload the updated app .pkg and upgrade your test grains in this VM. Make sure a grain upgrade works correctly.
  9. If the original repo has a message about looking for a new maintainer, try asking there if they want to turn it over to you. Otherwise, head to the sandstorm-dev mailing list and state your intent to take over maintenance.
  10. You’ll eventually be given a keyfile to cat onto your Sandstorm keyring. Do just that: cat < provided-key >> ~/.sandstorm/sandstorm-keyring. Ensure the app ID for the original app shows up with vagrant-spk listkeys. Back up your keyring before doing the cat just in case!
  11. Publish your app to the app store and wait for feedback. Depending on the level of changes, it can be a while to get feedback and to get the updated app to the quality level it needs to be at.
  12. After your app has made it onto the store and you’ve successfully done a release or two, consider automating the upgrade process as much as you can, where you can, to reduce the friction of putting out new releases. I do this with hugo-sandstorm and dokuwiki-sandstorm.
  13. Wherever you’re hosting the repo, ensure you can get feedback from users, and, more importantly, code from contributors.
  14. Once you have a few releases out, and can maintain a release schedule, then worry about fixing minor annoyances or edge case bugs. Remember, you’re spending your free time on this, so choose wisely what you work on, and ask for help when possible!
  15. If you ever decide to give up maintenance, let sandstorm-dev know, put a notice on the README for the repository, and (optionally) make the repo read-only so that no new issues can be posted. If someone else wants to take it over, they can fork it and repeat this very process!

Lenovo ThinkPad Pen Pro Troubleshooting

Jun 08, 2020

Some of these instructions are specific for Linux. All of them are the process I need to remember to walk through to get the pen working correctly. I also have 8 rechargeable AAAA batteries and two Pen Pros.

I really hate needing styluses that take or contain batteries. Older Wacoms (and Samsung S-Pens) were fine without them. :/ And I hate the idea of buying a bunch of AAAA alkaline batteries and throwing them away just to draw.

Papagayo: All the fixes

Jun 05, 2020

With the animation I’m working on I want some help breaking down the lip movements that Bamboo is going to have to make while talking. I saw that Synfig has support for loading Papagayo lip sync files so I took a look at the 2.0, C++ version of the project and saw it was quite abandoned.

I decided to incorporate a bunch of the great fixes to the software over the years, as well as a tweak of my own, to the all-the-fixes branch on my forked repo. And, to make sure it’s working as intended, I created a lip sync from my animatic audio in the forked version:

animatic audio save it

…and loaded it into Synfig:

load it see in properties

I’m not looking to become a hardcore maintainer of Papagayo. I just want it working well enough for my animation work. If you want to help keep it going, pull requests are best!

Update: I found the Python-based 1.x fork called Papagayo-NG which seems better maintained and has AppImages. I may try this one out as well. The project is also more active than the original one.

Synfig/Krita/Kdenlive Animation Notes

Jun 03, 2020

So you want to do hand-drawn animation on Linux and/or entirely with Free Open Source Software, and that animation involves lip syncing? Well, here’s some notes as I work on my first decent sized animation in Synfig/Krita/Kdenlive and I get my pipeline ready to go for smooth production work on future animation.

All in all, the process was pretty decent. It took some time to figure out the Synfig way of doing things, but once I got that, the actual pipeline of Krita -> Synfig -> Kdenlive was very smooth. Expect something way more substantial describing the process in the coming months.

Sandstorm static hosting proxying and Not Found handling with nginx

May 09, 2020

I host all my sites on Sandstorm using Hugo and hugo-sandstorm. This is super convenient for a couple reasons:

However, there are limitations:

I was solving the latter 2 for a while with HAProxy, but after setting up the site for Rabbit with 1000 Repos and realizing I wanted to shift pages and sections around as the dust settles on this hit new comic, I wanted 404 pages so folks could still find what they were looking for.

Here’s the nginx config I eventually came up with. You’ll still have to put the site’s public ID as a TXT record into your domain name as indicated in your static config setup, and make sure the Host header is sent along correctly so Sandstorm can do the DNS lookup correctly:

# redirect http to https without wildcards
server {
  listen 80;

  server_name ~^.*\.johnbintz.com$;

  return 301 https://johnbintz.com$request_uri;
}

# serve subdomainless from sandstorm
server {
  listen 443 ssl;

  # let's encrypt certificates go here

  server_name ~^johnbintz.com$;

  location / {
    proxy_set_header Host johnbintz.com;
    proxy_pass https://the-sandcats-url-sandstorm-static-publishing-gives-you;
    proxy_intercept_errors on;
    error_page 404 /404/;
 }
}

Then, if you’re using Hugo, create content/404.md with the contents of your 404 page. In the event of a missing page, the user will be handed the content of this 404 page, and receive an HTTP 404 Not Found header in response, so search engines will do the right thing, and it’s way better than the blank Cannot GET /this-page-does-not-exist page you get normally with Sandstorm static publishing.