Irregular Expressions

"The Unreasonable Effectiveness of the ArchWiki and Arch Linux Forums, or How I Un-Borked my Thinkpad T440 After Some Battery Troubles"

2026-01-16T00:00:00Z

The ArchWiki stands as a testament to the dedication and care of the Arch Linux user community and has long been the envy of other distros. Although only topics germane to Arch Linux are to be documented, the level of detail and breadth of information have proven to be useful to users of other distros as well. As outlined in the following LWN article, the Debian project invited a pair of ArchWiki maintainers to DebConf25 to discuss the ArchWiki management strategy as a means to revamp the existing Debian wiki.

I've been a sucker for Lenovo Thinkpads since early 2018 when I bought a used T440 on eBay. They're easy to maintain and modify, they're affordable in the used market, and they seem to have great hardware compatibility for Linux. In total, I own the following Thinkpads:

IBM Thinkpad T42 - running Windows 98 SE; among the last models produced by IBM. I bought this to run some childhood software favorites from Windows 95 and 98.
Lenovo T440 Thinkpad - the first Thinkpad I owned, purchased in January 2018. Forgotten in a cabinet until a few months ago. It only has 8Gb of RAM, but that's enough for many tasks in truth.
Lenovo X230 Thinkpad - purchased with Coreboot installed and in a state of experimentation and modding. Unused for years.
Lenovo Thinkpad X380 Yoga - I bought this one in July 2022 after tiring from hardware issues with my System76 Oryx Pro 6 and it's been my daily driver for most of the time since.

I don't need four different Thinkpads, but I don't have any reason to get rid of any either. I believe my first permanent Linux installation was Ubuntu Vivid Vervet in 2015 from a cd in some Linux magazine. For many years I enjoyed using Ubuntu, but I found that as time went on, minor issues became major annoyances. In 2023 I installed Debian Bookworm and it ran like a dream. In late 2022 the Debian project held a vote concerning the nonfree repos and ultimately made them accessible as part of the installer for Bookworm. As an Ubuntu user, I always had great respect and admiration for the Debian project, but I didn't have the patience to workaround some of the driver issues I'd encountered with it on some brief experiments. Bookworm on the other hand worked better out of the box than Ubuntu. I happily upgraded to Trixie when it became stable last year, but lingering in the back of my mind was a desire for something more bleeding edge.

I decided my System76 would be perfect for testing it out and immediately fell in love with it. The volume of AUR packages, the speed of pacman, the simplicity of the Arch build system and PKGBUILD files. I quickly took over an orphaned AUR package for a game launcher I wanted to use for playing Adventure Quest. I have much to learn, but appreciated the ease of getting involved.

After finding my old T440 in a file cabinet a few months back, I quickly installed Arch on it. Until then, I used the X380 Yoga with Debian and my System76 with Arch. I found myself reaching for the T440 to write some code here and there until a week ago when the battery started going on the fritz. It would cycle between charging for a few moments and then nothing. The battery was probably over a decade old, so I found a third-party replacement for cheap on Amazon and ordered it with next-day shipping. I had no troubles for a few days, but after accidentally letting my laptop die while unplugged, I suddenly got an error about my third party battery being unsupported and that the system would not charge it. This is troublesome.

After some very brief research, I reset the BIOS settings in an attempt to fix it. I was able to troubleshoot things with the battery removed and the laptop connected to power directly. Not only did this not fix my issue, but it left my laptop unable to boot into Arch. My inclination was to boot up my Arch installation ISO on a USB drive, but security validation errors prevented even that. After disabling Secure Boot and changing from UEFI to Leacy Boot, I was able to boot up the USB drive in the hopes of mending things. I looked in the Arch forums and found a post titled Arch won't boot after motherboard BIOS update. After some brief discussion in the thread, the poster concluded that the the probable sequence for repairing the issue would be

Update back to latest BIOS version
reboot with a bootable usb with an Arch.iso
boot arch-Linux
Chroot
Re-install bootloader (GRUB)

Another user affirmed that that the fix would largely mirror some steps of the installation in terms of mounting the Linux partition, chrooting into it, installing the kernel and firmware, and configuring a bootloader.

In my case, I mostly followed these instructions, though it was unnecessary for me to update to a particular BIOS version since I merely reset the settings for my given BIOS version.

After connecting to my network with iwctl I viewed my partitions with

fdisk -l

Following the portion of the installation guide for mounting filesystems, I ran

mount /dev/sda3 /mnt

I then used arch-chroot to access my intact Arch system.

arch-chroot /mnt

Following the forum post, I reinstalled the linux, linux-firmware, and grub packages.

 pacman -Sy linux linux-firmware grub

With the GRUB package installed, I followed the instructions to install GRUB to my boot partition

grub-install --target=i386-pc /dev/sda

I followed the instructions for my setup, GPT/BIOS, in order to generate the GRUB main configuration file.

grub-mkconfig -o /boot/grub/grub.cfg

After completing those steps, I rebooted, removed the USB drive, and was thilled to see the GRUB splash screen with Arch listed, followed quickly by my GNOME login screen. I re-inserted my battery and rebooted to success. No more battery issues! If this happens in the future, I'll try the Lenovo Thinkpad Emergency Reset Hole first. It disengages both the main battery and cmos battery, then restarts the laptop. I learned a valuable lesson about fiddling with BIOS settings based on insufficient research, but also engaged in the troubleshooting made simple by the the resources afforded to Arch users.

"Using Guix Docker Images for Gitlab CI/CD"

2026-01-16T00:00:00Z

Over the years I've made several changes to how this website is hosted and deployed. In its original incarnation, it was a Jekyll site hosted with GitHub Pages. Eventually I felt the need to move the repository and its deployment to GitLab for one or more reasons. GitLab offers a Jekyll project for getting started with GitLab Pages. I ended up forking the Build Jekyll with Bundler repo as a starting point, migrating my styling and markdown posts afterwards.

As many others have, I felt the need to fiddle around with the choice of framework for my blog and learned about Haunt, a static site generator written in Guile, one of the GNU Scheme implementations. Haunt doesn't require markdown files as a source, offering several types of readers and allowing customization. By making a few small tweaks to my posts, mostly around my use of inline HTML which one of Haunt's dependencies didn't seem to like, I was able to migrate my blog to Haunt without too much fuss. I previously implemented a tags system in Jekyll to allow generating dedicated tag pages on build in addition to the aggregate tags page, but I found the approach cumbersome. Creating this functionality for my blog in Guile on the other hand was straighforward and cleaner.

Generating your site is done with

haunt build

transforming your underlying files into a static site with styling. The Haunt website offers two pathways to get the package. Either build from source, or do

guix install haunt

Guix (pronounced like geeks) bills itself as "a package manager for GNU/Linux systems".. "designed to give users more control over their general-purpose and specialized computing environments, and make these easier to reproduce over time and deploy to one or many devices." That package manager shares a lineage with Nix, and like Nix, there is also a proper distro centered on Guix as a package manager are core OS utility. Guix is also notable for using the GNU Shepherd as its init system and service manager. Guix and Shepherd are both written in Guile, with the Guix System using Guile for total configuration of the OS.

I thought it'd be interesting to make use of Guix to build my site directly on my CI/CD pipeline. After some searching, I came across a Docker image for using Guix in CI/CD. I have some initial challenges getting the build to work related to locale settings on the image, but landed on the gitlab-ci.yml file shown below that identifies needed dependencies from my project manifest file. With that in place, it runs haunt build, moves the generated site to the expected path, and GitLab Pages takes care of the rest.

# requiring the environment of GNU Guix for Haunt
image: metacall/guix


# the 'pages' job will deploy and build your site to the 'public' path
pages:
  stage: deploy
  script:
    - guix package -m manifest.scm
    - export GUIX_PROFILE="/root/.guix-profile"
    - source "$GUIX_PROFILE/etc/profile"
    - export GUIX_LOCPATH="$GUIX_PROFILE/lib/locale"
    - export LANG="en_US.UTF-8"
    - export LC_ALL="en_US.UTF-8"
    - haunt build
    - mv site public
  artifacts:
    paths:
      - public
  only:
    - master # this job will affect only the 'master' branch

Without a little further digging, I'm not fully sure what could be attributed to user error vs opportunities to customize the base Docker image, but I think it's an interesting way to customize and deploy my website.

"Publishing Data Online with Datasette - ETP"

2025-07-31T00:00:00Z

Note - This post was originally published on my Etruscan Studies Blog at the following link on 2024-02-13

In my previous post, I mentioned a tool called Datasette, a neat open-source tool for exploring and publishing data. I explained how I scraped an archived copy of the Etruscan Texts Project (ETP) and ultimately populated it into a SQLite DB using a Python script I wrote. Following up on that, I wanted to explore the easiest ways to surface the data online in a browsable way. Reading further about Datasette, I realized that Datasette itself fits my use-case perfectly.

To get started, all you need to do is create a Heroku account and an application. Configure your application to use Heroku CLI and install it on your computer. To use Datasette, you’ll need to install Python 3 on your personal computer and install the datasette package. On my Debian box, I installed it using pipx, to manage it in an isolated environment.

From there, I simply used the following command to use my SQLite db file as the source for Datasette to publish, having already logged into Heroku using the CLI.

datasette publish heroku etruscan-texts.db --name "etruscan-texts"

Running this command will serve up a website with the name you provide, which will be displayed in the console. You can click on the following link to view my published copy of the ETP.

This is such a great way to get a data set online without needing to provide your own web server, view engine, tables + filtering in code. Now that this copy of the ETP is available online, anyone is welcome to use it or recommend fixes and additions. I’m aware that ETP 406 was omitted, causing the assigned numbers after that to no longer be a correct sequence. I’ll provide a fix for that in the near future and document what follows.

"Opportunities for Digitization in the Humanities - The Etruscan Texts Project"

2025-07-31T00:00:00Z

Note - This post was originally published on my Etruscan Studies Blog at the following link on 2024-02-10

In my recent foray into researching the Etruscan language, I came across the the Etruscan Texts Project (ETP), which served as a searchable online repository of Etruscan inscriptions. I found references and links to the website on active UMass Amherst webpages and elsewhere, but the links themselves were dead. With a bit of sleuthing on the Wayback Machine, the most recently indexed working copy of the ETP site I could find was dated to late 2009. Copies indexed from 2011 onward return 404 errors, and reveal that the server hosting the ETP was migrated from Ubuntu to Unix. The linked version of the ETP has entries labelled up to #430, though the jump from ETP 405 to ETP 407 omitted 406, for a total of 429 records.

Details available from the following PDF, sourced from Etruscan News 5 (2006), note that the ETP was in the process of migrating its existing catalog to EpiDoc, an XML format for encoding scholarly and educational editions of ancient documents. It’s not clear to me from the outside what the current state of the project is, but I took it upon myself to experiment with the data available. After downloading a copy of the archived website, I wrote this little Python script using Beautiful Soup, a package for pulling data out of XML and HTML files.

from bs4 import BeautifulSoup

inputFile = open("/path/to/file.html", "r")
outputFile = open('/path/to/output.csv', 'w')
content = inputFile.read()
soup = BeautifulSoup(content, 'html.parser')

# array to hold list of ETP entries
outputFileEntries = []

for entry in soup.find_all("div", class_="document"):
    # string to hold a tentative CSV file single-line for an entry
    outputFileLine = ''
    for tag in entry:
    	if tag.name is not None:
    		formattedTagText = '\t'.join([line.strip() for line in tag.text.split('\n')])
    		outputFileLine = outputFileLine + "\"" + formattedTagText + "\"" +  ', '
    outputFileEntries.append(outputFileLine)

for line in outputFileEntries:
    outputFile.write(line + "\n") 

inputFile.close()
outputFile.close()

This code looks for a div tag specific to the archived ETP page, writing each of its attributes as quoted and comma-separated values, forming lines of a CSV file (available here). Using LibreOffice Calc, I fixed some of the formatting present in the data by default, and used DB Browser for SQLite to convert the CSV file into a SQLite database file (available here). SQLite is a great little database engine that allows embedding a DB in an application as a single file. It may not be a perfect fit for all use-cases, but for surfacing a small amount of catalog data, it’s a nice quick hit for little projects.

While considering options, I learned of a tool called Datasette, which frames itself as “a tool for exploring and publishing data…aimed at data journalists, museum curators, archivists, local governments, scientists, researchers and anyone else who has data that they wish to share with the world.” I was able to find the easiest way to interact with Datasette, as a Glitch webapp. I forked the app, inserting my own CSV file for the ETP catalog data, and have it running here (Note: as of July 8, 2025, Glitch has decommed all its hosting. I'll need to move it to my own hosting at some point). The README provides instructions on getting it running. The screenshot below demonstrates running a simple query of the ETP data inside the terminal provided by the app. For those unfamiliar with some of the tooling involved with generating databases or surfacing them via APIs, this is a great toolkit!

Next Steps

I’ve scraped a (possibly very) outdated version of the ETP catalog from the Wayback Machine and migrated it to a database. I’d like to learn more about the need or desire for data like this to remain easily and publicly accessible. It would be straightforward to create a new website that hosts the database, but questions remain about the format of the data, its accuracy, and the best way to enter new inscriptions. Although it remains popular in certain domains, in many cases, XML has been largely obsoleted by JSON, which some may consider an easier format to work with. There may be alternatives to EpiDoc that are more accessible to current tooling. Ultimately, I would love to be involved in any efforts related to digitally cataloging Etruscan inscriptions (or similar needs for other historical languages). If you work in the field and would like to partner with me as an independent researcher or assistant on a part-time basis, please consider getting in touch with me either by comment here or via my email (chaseleinart at proton dot me).