Posts on NakuRei's Notes

Notes on Migrating from Volta to mise

Sat, 17 Oct 2026 10:04:13 +0900

What is this

Notes on migrating from Volta to mise.

I knew that Volta is no longer maintained, but it was still sitting on a PC I had not booted up in a while, so I migrated to mise.

Removing Volta

Follow the official instructions.

Uninstalling Volta | Volta

Uninstalling Volta

docs.volta.sh

Before you start, check what you had installed with volta list.

volta list

Log from the time

$ volta list
⚡️ Currently active tools:

 Node: v22.21.0 (default)
 Tool binaries available:
 codex (default)

See options for more detailed reports by running `volta list --help`.

Then uninstall it. First, delete the whole directory with rm -rf ~/.volta.

rm -rf ~/.volta

Next, remove the Volta-related lines from your shell profile, such as .bashrc or .bash_profile. In my environment, I removed the following from .bashrc and .profile.

export VOLTA_HOME="$HOME/.volta"
export PATH="$VOLTA_HOME/bin:$PATH"

If needed, restart your shell or run something like source ~/.bashrc to apply the changes.

Installing mise

Follow the official instructions.

Installing mise | mise-en-place

Install mise on macOS, Linux, or Windows, verify the executable, and keep it up to date.

mise.jdx.dev

Install mise.

curl -fsSL https://mise.run | sh

Log from the time

$ curl -fsSL https://mise.run | sh
mise: selected 2026.10.11 (minimum release age: 24h)
mise: installing mise...
######################################################################## 100.0%
mise: installed successfully to /home/user/.local/bin/mise
mise: run the following to activate mise in your shell:
echo "eval \"\$(/home/user/.local/bin/mise activate bash)\"" >> ~/.bashrc

mise: run `mise doctor` to verify this is set up correctly

The installation log says run the following to activate mise in your shell:, so run that too.

echo "eval \"\$(/home/user/.local/bin/mise activate bash)\"" >> ~/.bashrc

Since .bashrc has been edited, apply the changes.

source ~/.bashrc

After that, run mise doctor to check the setup. If it prints No problems found, you are good to go.

Installing global tools

Reinstall the global tools you had under Volta with mise.

For example, to install node, do the following.

mise use -g node@latest

You can check the installed global tools with mise list.

mise list

For example, it looks like this.

$ mise list
Tool Version Source Requested
codex 0.163.0 ~/.config/mise/config.toml latest
node 26.12.0 ~/.config/mise/config.toml latest

References and URLs

Uninstalling Volta | Volta

Uninstalling Volta

docs.volta.sh

Installing mise | mise-en-place

Install mise on macOS, Linux, or Windows, verify the executable, and keep it up to date.

mise.jdx.dev

Fixing Voicemeeter Banana's AUX Input Showing "no driver present" and Producing No Sound

Sat, 26 Sep 2026 16:29:38 +0900

What this is

This is a note on how I fixed an issue with Voicemeeter Banana where its virtual audio I/O, Voicemeeter AUX Input, suddenly started showing “no driver present” in red and stopped producing any sound.

Environment

OS: Windows 11 Pro 25H2
Voicemeeter Banana: I don’t remember the exact version

Symptoms

As shown in the screenshot above, “no driver present” appeared in red under Voicemeeter AUX Input.
No sound came through Voicemeeter AUX Input, regardless of what I routed to it.
The Voicemeeter application itself remained responsive and could be operated normally.
Voicemeeter Input, the other Virtual Input, continued to work normally and produced audio without any issues.
The HARDWARE INPUT section also worked normally and received audio as expected.
I could run Restart Audio Engine, but it did not resolve the issue.

Cause

The issue appears to have been caused by an incomplete Voicemeeter Banana update, which left the old VAIO drivers installed alongside the current Voicemeeter configuration.

In other words, the application and its virtual audio drivers were no longer in a consistent state.

What I checked

I opened the Sound control panel by pressing Windows + R and running mmsys.cpl¹, then checked the Playback tab to see whether both “VoiceMeeter Input” and “VoiceMeeter Aux Input” were present.

At this point, only “VoiceMeeter Input” was listed. “VoiceMeeter Aux Input” was completely missing.

I also confirmed that the device was not simply hidden because it was disabled or disconnected.

This indicated that Windows was not recognizing the virtual audio device for Voicemeeter AUX Input at all, which suggested that the problem was caused by an inconsistency in the virtual audio drivers.

Research

After looking into the issue, I found that Voicemeeter changed the architecture of its VAIO drivers in 2024.

Previously, VAIO, AUX, and VAIO3 were handled as separate drivers. With the newer architecture, a single VAIO driver can provide up to eight Virtual I/O devices.

I suspect this change was related to the problem. The Voicemeeter application itself had been updated, but some of the old VAIO/AUX drivers remained installed, leaving the application and drivers in an inconsistent state.

Fix

Since the application and drivers appeared to be out of sync, I removed both and performed a clean reinstall.

These are the steps I followed:

Save your Voicemeeter settings first if you want to keep them.
Download the latest Voicemeeter Setup from the official website.
Run the downloaded Voicemeeter Setup as administrator, select REMOVE, and uninstall Voicemeeter.
Restart the PC.
Open Device Manager and select View → Show hidden devices.
Check the following categories in Device Manager for any old VB-Audio Voicemeeter devices. If any remain, uninstall them.
- Sound, video and game controllers
- Audio inputs and outputs
Run Voicemeeter Setup as administrator and install Voicemeeter again.
Restart the PC.

After completing these steps, the “no driver present” message disappeared, and Voicemeeter AUX Input started working normally again.

You can also open it from Settings → System → Sound → More sound settings. ↩︎

Fixing the `code` Command Not Opening VS Code in WSL Remote Mode

Wed, 23 Sep 2026 12:29:10 +0900

The problem

When I launched VS Code by running the code command inside WSL2, the folder did not open in WSL Remote mode. Instead, VS Code opened it using a Windows UNC path such as \\wsl.localhost\Ubuntu-24.04\home\user.

As a result, I had to select “Reopen Folder in WSL” in VS Code every time.

The cause

When the code command inside WSL resolves to /mnt/c/Program Files/Microsoft VS Code/bin/code, it first asks the VS Code CLI for the location of the WSL extension. If the extension is found, the folder is opened in WSL Remote mode. If it is not found, VS Code falls back to opening the folder with the Windows Code.exe.

In my case, the problem was that the VS Code CLI could not locate the installed WSL extension.

The WSL extension itself was installed on the Windows side under C:\Users\<username>\.vscode\extensions, but the VS Code CLI apparently only checks the extensions associated with the default profile¹.

This means that even if the WSL extension is installed in another VS Code profile, the code command launched from WSL may not be able to find it unless the extension is also installed in the default profile.

The fix

The solution is simple: install the WSL extension in the default VS Code profile.

More specifically, it appears to only read C:\Users\<username>\.vscode\extensions\extensions.json. ↩︎

Notes from Reviewing My GitHub Repository Security Settings

Tue, 22 Sep 2026 22:28:36 +0900

What is this?

These are some notes on what I did and what I learned while reviewing my GitHub repository security settings, following the article below.

When GitHub itself says these are settings “every GitHub maintainer should enable,” you kind of have to check, right?

6 security settings every GitHub maintainer should enable this week

These six free settings will not make your project unhackable. Nothing will. What they will do is close the easy doors.

github.blog

There are six settings in total, and apparently you can get through all of them in under 30 minutes. Really?

Conclusion

For public repositories, enabling all of the relevant settings under “Security and quality” improves the security of the repository.

For personal private repositories, however, only the following settings are available:

Dependabot alerts
Secret scanning alerts

1. Add a SECURITY.md file

This is mainly useful for public repositories.

A SECURITY.md file is used to tell users how to report security vulnerabilities in your project. According to the official documentation, it lets you “add information about supported versions of your project and how to report a vulnerability.” The article referenced above uses systemd’s security policy as an example.

リポジトリへのセキュリティポリシーの追加 - GitHubドキュメント

セキュリティポリシーをリポジトリに追加することによって、プロジェクト内のセキュリティ脆弱性を報告する方法の手順を示すことができます。

docs.github.com

If vulnerability details are posted in a public issue, malicious users may be able to exploit them. For that reason, it is important to provide a reporting channel separate from public issues. Clearly specifying where vulnerabilities should be reported helps improve the security of the repository.

The SECURITY.md file can be placed in any of the following locations¹:

The .github directory
The repository root
The docs directory

This corresponds to the “Security policy” section under a repository’s “Security and quality” settings. If it shows as Disabled, as in the image below, it means that the repository does not have a SECURITY.md file.

Clicking “Set up a security policy” in the screen above lets you create a SECURITY.md file in the repository root directly from GitHub.

This is just my opinion, but for a personal project, I think a security policy should include at least the following:

Which versions receive security fixes
Where vulnerabilities should be reported
What information should be included in a report
What should not be posted in a public issue
An approximate response time

For vulnerability reports, GitHub’s Private Vulnerability Reporting (PVR) is convenient. I will cover that in the next section.

For example, in ticko, a Python package I maintain, I created the following SECURITY.md file.

The example below assumes that PVR, which is explained in the next section, is enabled.

# Security Policy

## Supported Versions

Security updates are provided for the latest major version of ticko.

| Version | Supported |
| ------- | ------------------ |
| 2.x | :white_check_mark: |
| 1.x | :x: |

Users are encouraged to upgrade to the latest release available on PyPI.

## Reporting a Vulnerability

If you discover a security vulnerability in ticko, please do not report it
through a public GitHub issue.

Instead, please report it privately using GitHub's private vulnerability
reporting feature.

When submitting a report, please include as much of the following information
as possible:

- A description of the vulnerability
- The affected version(s) of ticko
- Steps to reproduce the issue
- A minimal proof of concept, if applicable
- The potential security impact
- Any suggested mitigation or fix, if available

You can expect an initial response within 14 days.

Please allow reasonable time for the issue to be investigated and fixed before
publicly disclosing the vulnerability.

## Scope

Security reports should describe issues that have a meaningful security impact
on applications using ticko.

General bugs, timing inaccuracies, performance issues, feature requests, and
other problems without a security impact should be reported through the public
GitHub issue tracker instead.

Writing the SECURITY.md file itself does not take very long, since you can give an LLM the repository URL and have it draft one for you. You can also use security policies from other well-maintained projects as references.

2. Enable PVR (Private Vulnerability Reporting)

This is mainly useful for public repositories.

Private Vulnerability Reporting (PVR) is a GitHub feature that allows vulnerabilities in a repository to be reported privately. If you publish a project on GitHub, vulnerability reports should generally go through PVR rather than public issues.

リポジトリのプライベート脆弱性レポートの構成 - GitHubドキュメント

パブリックリポジトリの所有者と管理者は、プライベート脆弱性レポートを有効にすることで、セキュリティリサーチャーがリポジトリ内の脆弱性を安全に報告できるようにすることができます。

docs.github.com

To use PVR, you need to enable it in the repository settings. This only takes a moment.

First, open the repository’s “Security and quality” settings and find the “Private vulnerability reporting” section. If it shows as Disabled, as in the image below, PVR is currently turned off.

Clicking “Enable vulnerability reporting” opens the configuration screen shown below.

Click “Enable” to turn it on.

Once both steps 1 and 2 are configured, the repository’s “Security and quality” page will show the contents of the SECURITY.md file created in step 1, along with a “Report a vulnerability” button.

3. Enable Secret scanning alerts

This setting is available for public repositories, as well as private or internal repositories owned by an organization.

Secret scanning checks repositories for values that should remain secret, such as API keys and tokens, and alerts you if they have accidentally made their way into the repository. Think of it as one more line of defense against leaked credentials.

About secret scanning alerts - GitHub Docs

Learn about the different types of secret scanning alerts.

docs.github.com

According to the article referenced above, AI-assisted commits leak secrets at roughly twice the usual rate. That’s a little scary.

To enable it, first open the repository’s “Security and quality” settings and find the “Secret scanning alerts” section. If it shows as Enabled, as in the image below, the feature is active.

When this feature is enabled, GitHub will apparently raise an alert if it detects a leaked secret².

If a leaked secret is actually detected, the official documentation below looks like a useful reference for how to respond.

Resolving alerts from secret scanning - GitHub Docs

After reviewing the details of a secret scanning alert, you should fix and then close the alert.

docs.github.com

4. Enable Dependabot

This setting is useful for both public and private repositories.

Dependabot warns you when an external library or package your repository depends on contains a known vulnerability.

For example, it checks dependencies listed in files such as package.json and alerts you when a security issue is found. By default, these alerts are also sent by email.

Dependabot alerts - GitHub Docs

Dependabot alerts help you find and fix vulnerable dependencies before they become security risks.

docs.github.com

At the time of writing, Dependabot has five related features:

Feature	Description
Dependency graph	Allows GitHub to identify and track the repository’s dependencies
Dependabot alerts	Warns you when a known vulnerability is found in a dependency
Dependabot security updates	Automatically opens PRs to update vulnerable dependencies to patched versions
Grouped security updates	Groups multiple security updates into a single PR
Dependabot version updates	Opens PRs periodically to update dependencies to newer versions

Of these, Dependabot version updates is the only one that creates update PRs regardless of whether a vulnerability exists.

Personally, I consider Dependabot alerts to be the bare minimum. Because Dependabot alerts requires the Dependency graph, I decided to enable both.

To configure it, first open the “Security and quality” settings for the repository. If you see an “Enable Dependabot alerts” button like the one below, the feature is not currently enabled.

Clicking the button takes you to the Advanced Security settings page shown below. From there, click “Enable” in the Dependabot alerts section.

If the Dependency graph has not yet been enabled, GitHub will show a warning like the one below. There is no problem with this, so click “Enable.”

If the button now says “Disable,” as shown below, Dependabot alerts has been enabled successfully.

The “Dependabot malware alerts” option shown in the same screen also looked useful, so I enabled that as well.

5. Enable Code scanning

This can be enabled for public repositories or repositories owned by an organization.

Code scanning performs static analysis on the code in your repository to identify security vulnerabilities and coding errors. For example, it can flag issues such as SQL injection vulnerabilities.

コードスキャン - GitHubドキュメント

code scanningを使用して、GitHubのプロジェクトのコードでセキュリティの脆弱性とエラーを見つけることができます。

docs.github.com

Code scanning with CodeQL can also detect insecure GitHub Actions workflows. GitHub now provides a default CodeQL configuration that can be enabled with just a few clicks. Very convenient.

With the default setup, configuration is straightforward. First, check “Code scanning alerts” under “Security and quality” for the repository you want to configure.

If you see a “Set up code scanning” button like the one below, Code scanning has not yet been enabled.

Clicking “Set up code scanning” takes you to the Advanced Security settings page. You can customize the configuration, but the simplest option is to use CodeQL with the default setup. If it has not yet been configured, you should see something like the screen below. Select “Default” from “Set up.”

GitHub then analyzes the repository automatically and generates a default configuration. If anything looks incorrect, you can edit it here.

If the configuration looks correct, click “Enable CodeQL.” Setup takes a few minutes to complete.

Once CodeQL is enabled and the scan has run successfully, the status will be shown in the settings.

You can check the scan results from the Actions tab on GitHub.

6. Protect the default branch

For most repositories, the default branch is probably main. You can protect this branch so that changes cannot be pushed directly to it. For example, you can require changes to go through a pull request and require at least one approval before merging.

Personally, I find this more annoying than useful for private repositories that I work on alone. For public repositories, however, simply preventing direct pushes to the default branch provides a significant benefit.

You can also make security checks part of the merge requirements, allowing Dependabot alerts or code scanning results to block a merge when necessary.

I had already configured this in the past, so see the article below for the details.

GitHubのブランチ保護のルールについて調べたときのメモ

notes.nakurei.com

Wrapping up

It took me a while because I was researching each setting as I went, but in the end, the only parts that really take any time are writing the SECURITY.md file and protecting the default branch. Everything else is mostly just a matter of clicking “Enable” on a settings page.

So yes, apparently you really can get through all of this in under 30 minutes.

Any of these locations is fine. According to the official documentation, GitHub checks them in the following order of precedence: .github directory -> repository root -> docs directory. ↩︎
I say “apparently” because this has never actually happened to me, so I have not seen it firsthand. Better that way, of course. ↩︎

Testing a Linux Tauri App on a Hyper-V Ubuntu VM

Sun, 13 Sep 2026 22:43:26 +0900

What is this

Notes on the steps I follow to try out a Tauri app built on a Windows host machine on an Ubuntu virtual machine (VM) running on Hyper-V.

Environment

Windows 11 Pro
Ubuntu VM on Hyper-V: Ubuntu 26.04 LTS

Preparation

On the Windows host

Build for Linux ahead of time. I use Docker for the build. As long as you end up with a .deb file, you are good to go.

On the Ubuntu VM

Install an SSH server on the Ubuntu VM.

sudo apt update
sudo apt install openssh-server
sudo systemctl enable --now ssh

Check the IP address of the Ubuntu VM.

ip addr

The address like 172.XX.XX.XX shown under inet for eth0 is the VM’s IP.

Installing on the VM

Copy the .deb file from the Windows host to the Ubuntu VM. The easiest way is to run scp from the directory that contains the .deb file. Replace your-app.deb with the name of the .deb file you are copying, username with the user name on the Ubuntu VM, and 172.XX.XX.XX with the IP address of the Ubuntu VM.

Run on the Windows host

scp your-app.deb username@172.XX.XX.XX:/tmp/

If scp asks Are you sure you want to continue connecting (yes/no/[fingerprint])?, answer yes. It then prompts for a password, so enter the login password of the Ubuntu VM.

Once the copy succeeds, you can confirm it with the ls command.

Run on the Ubuntu VM

ls /tmp/

With the file in place, install it.

Run on the Ubuntu VM

sudo apt install /tmp/your-app.deb

If the installation succeeds, you can launch the app and check that it works.

Uninstalling on the VM

To uninstall the app you installed, run the following command. Replace your-app with the name of the app you installed.

Run on the Ubuntu VM

sudo apt remove your-app

If you also want to remove the configuration files, use purge instead.

Run on the Ubuntu VM

sudo apt purge your-app

After that, run the following command to remove dependency packages that are no longer needed.

Run on the Ubuntu VM

sudo apt autoremove

The installer can be deleted with rm.

Run on the Ubuntu VM

rm /tmp/your-app.deb

When Paste Suddenly Stopped Working in tmux on WSL: Notes on the Fix

Mon, 07 Sep 2026 23:03:16 +0900

What this is

Some notes on how I fixed an issue where I couldn’t paste text into tmux on WSL.

What happened

When I tried to paste text copied from Notepad on Windows into tmux on WSL, nothing would paste, no matter what I copied.

Environment

Windows 11 + WSL2 (Ubuntu 24.04) + tmux
I was using the VS Code integrated terminal

Cause

The cause turned out to be broken WSL interop.

Investigating the cause

I tried a test where I put a known string on the clipboard and then pasted it.

printf 'PASTE_TEST_OK_123' | clip.exe # Put a known value on the clipboard
# Press Ctrl+V immediately afterward. If everything is working,
# PASTE_TEST_OK_123 should be pasted.

The result was that something completely different was pasted. From this behavior, I suspected that the problem was with writing to the clipboard, before the paste operation itself.

After some investigation, I found that while this problem was occurring, Windows executables in WSL were all failing like this:

$ powershell.exe
/mnt/c/.../powershell.exe: 1: MZ����: not found
/mnt/c/.../powershell.exe: 9: Syntax error: "(" unexpected

I asked an AI about this, and apparently MZ is the magic number used by Windows executables.An error like MZ��: not found apparently means that the exe file is being interpreted and executed as a shell script. According to the AI, this is a characteristic symptom of the WSL interop execution handler having disappeared.

Apparently, the reason Windows binaries can be launched from within WSL in the first place is that the Linux kernel’s binfmt_misc mechanism has a registration rule that says, roughly, “if the first bytes of a file match this particular magic number, pass it to this particular interpreter.” Normally, when a file starts with MZ, it’s handed to the WSL interop bridge, which starts the process on the Windows side. This time, however, that registration had disappeared, so clip.exe was being interpreted as a shell script, which is why pasting stopped working.

I wasn’t able to determine exactly why the registration disappeared. The registrations under /proc/sys/fs/binfmt_misc/, which are used by binfmt_misc, are not persistent. At least in my environment, I found the following in the logs:

A Docker Desktop crash followed by the WSL integration distro being unmounted
Repeated Clock change detected messages, which I assume were traces of the system waking from sleep
A cannot create /proc/sys/fs/binfmt_misc/WSLInterop: Permission denied message, apparently from a failed registration attempt caused by a conflict

Personally, I suspect the Docker Desktop crash was the cause.

Solution

You can use the following commands to check whether broken WSL interop is really the cause.

Commands for diagnosing the cause

# Check whether the registration exists:
# if WSLInterop is listed, it is registered
ls /proc/sys/fs/binfmt_misc/

# Check whether it actually works:
# if interop-alive is printed, everything is working
cmd.exe /c "echo interop-alive"

If the second command fails with an MZ...: not found error, restoring the registration is enough to fix the problem. Since all you’re doing is restoring the registration, pasting starts working again without restarting the shell.

Command to write the registration back

sudo sh -c "echo ':WSLInterop:M::MZ::/init:PF' > /proc/sys/fs/binfmt_misc/register"

If you run this command when everything is working normally, it will fail with an echo: I/O error. This is because writing to the register rejects a duplicate entry with the same name, so the error does not indicate that anything is wrong.

By the way, you can combine the check and the fix into a single line like this:

[ -e /proc/sys/fs/binfmt_misc/WSLInterop ] && echo "No repair needed" || sudo sh -c "echo ':WSLInterop:M::MZ::/init:PF' > /proc/sys/fs/binfmt_misc/register"

Wrapping up

Thanks, Claude Code.

Notes on Migrating the Hugo Stack Theme from v3 to v4

Thu, 03 Sep 2026 23:32:21 +0900

Overview

Notes on the changes I made and the issues I ran into while migrating the Hugo Stack theme used on this site from v3 to v4.

I mostly followed the official migration guide below.

Upgrade to v4 | Stack

Card-style Hugo theme designed for bloggers

stack.cai.im

Environment

OS: Windows 11 Pro 25H2
Hugo: v0.155.3 → v0.165.0
hugo-theme-stack: v3.31.0 → v4.0.3

Upgrade Hugo

Stack v4 requires Hugo v0.157.0 or later. My local version was v0.155.3, so I had to upgrade. I went with the latest version at the time (v0.165.0).

Hugo binaries are available from Hugo’s GitHub releases page.

Releases · gohugoio/hugo

The world’s fastest framework for building websites. - gohugoio/hugo

github.com

Stack requires the extended version of Hugo in both v3 and v4, so download a release with extended in its name. Extract the downloaded file and put its contents somewhere on your PATH. I’m on Windows, so I put it in C:\HugoExtended\bin and added C:\HugoExtended\bin to the PATH environment variable.

Checking the Hugo version

$ hugo version
hugo v0.165.0-76a5e1880ab46688155b02e99bab9be2a6134492+extended windows/amd64 BuildDate=2026-08-12T14:26:28Z VendorInfo=gohugoio

This site is hosted on Netlify, so I also had to bump Netlify’s build environment to Hugo v0.165.0. If you set HUGO_VERSION in netlify.toml, or as an environment variable in the Netlify dashboard, change that too.

Fix the X shortcode

This one comes from upgrading Hugo rather than from the Stack theme itself: Hugo’s built-in tweet shortcode was removed in Hugo v0.156. Use the x shortcode instead.

Example of the shortcode change

- {{< tweet user="username" id="1234567890" >}}
+ {{< x user="username" id="1234567890" >}}

Replace `.Site.Data` with `hugo.Data`

This is another change caused by the Hugo upgrade: Hugo’s built-in .Site.Data was deprecated in Hugo v0.156. Use hugo.Data instead. In my case a custom shortcode I had written used .Site.Data, so I replaced it.

Temporarily move custom files aside

Going from v3 to v4, the way the theme is written and how its files are split up have both changed. So if you have layouts or assets directories that override the theme, move them aside temporarily.

One caveat: shortcodes (layouts/shortcodes in v3) must exist or the build will fail, so if you want builds to keep succeeding during the migration, move just the shortcodes to layouts/_shortcodes/.

Migrate the config files

The config files were YAML in v3, but v4 switched to TOML. Hugo converts YAML automatically, so it seems that sticking with YAML should be fine. Since I was going to review the settings anyway, I took the opportunity to switch to TOML.

hugo-theme-stack-starter is a good reference for how to write the config. The Stack theme demo works too. Judging by Stack’s Getting Started, hugo-theme-stack-starter seems to be the official template, so that’s what I used as my reference. Create a config/_default directory and put the following files in it.

config.toml

config.toml holds the basic information about the site. I changed the following from the official template.

Added theme = "hugo-theme-stack"
Changed baseurl to my own site’s URL
Changed locale and defaultContentLanguage to Japanese, and accordingly set hasCJKLanguage to true

I manage the Hugo theme as a Git Submodule rather than a Hugo Module, which is why theme = "hugo-theme-stack" is needed. If you manage it as a Hugo Module, you don’t need theme.

In TOML, settings that don’t belong to any table won’t take effect unless you write them first.

config.toml after the changes

config.toml

theme = "hugo-theme-stack"
baseurl = "https://notes.nakurei.com/"
locale = "ja-JP"
title = "NakuRei's Notes"
copyright = "NakuRei"

# Theme i18n support
# See all available values at https://github.com/CaiJimmy/hugo-theme-stack/tree/master/i18n
defaultContentLanguage = "ja"

# Set hasCJKLanguage to true if DefaultContentLanguage is in [zh-cn ja ko]
# This will make .Summary and .WordCount behave correctly for CJK languages.
hasCJKLanguage = true

enableRobotsTXT = true
enableGitInfo = true

timeout = "300s"

[services.googleAnalytics]
 ID = "G-XXXXXXXXXX"

[pagination]
 pagerSize = 10

[frontmatter]
 lastmod = ["lastmod", ":git", "date", "publishDate"]

languages.toml

languages.toml holds the multilingual settings. These options are the same as languages in v3.

In the hugo-theme-stack-starter template the file is named _languages.toml; the leading underscore is there to keep the settings from being applied. So when you actually configure this, create it as languages.toml with the underscore removed.

languages.toml after the changes

languages.toml

[ja]
 label = "日本語"
 locale = "ja"
 weight = 1

 [ja.params]
 description = "努力の積み重ねを記録しておくためのサイト。"

 [ja.params.sidebar]
 subtitle = "努力の積み重ねを記録しておくだけ"

[en]
 label = "English"
 locale = "en"
 weight = 2

 [en.params]
 description = "A website to keep track of my efforts."

 [en.params.sidebar]
 subtitle = "Just keep track of my efforts."

markup.toml

markup.toml holds the settings for Markdown rendering. There’s no change from what I had under markup in v3, so it ports over as-is.

markup.toml after the changes

markup.toml

# Markdown renderer configuration
[goldmark.renderer]
 unsafe = false

[goldmark.extensions.passthrough]
 enable = true

 [goldmark.extensions.passthrough.delimiters]
 block = [['\[', '\]'], ['$$', '$$']]
 inline = [['\(', '\)']]

[tableOfContents]
 endLevel = 4
 ordered = true
 startLevel = 2

[highlight]
 noClasses = false
 codeFences = true
 guessSyntax = true
 lineNoStart = 1
 lineNos = false
 lineNumbersInTable = true
 tabWidth = 4

menu.toml

menu.toml holds the settings for the main menu and the social menu. I only configure the social menu on this site, but at least for that menu, the options are the same as in v3.

menu.toml after the changes

menu.toml

[[social]]
 identifier = "github"
 name = "GitHub"
 url = "https://github.com/NakuRei"

 [social.params]
 icon = "brand-github"

[[social]]
 identifier = "x"
 name = "X"
 url = "https://x.com/nakurei7901"

 [social.params]
 icon = "brand-twitter"

[[social]]
 identifier = "rss"
 name = "RSS"
 url = "https://notes.nakurei.com/index.xml"

 [social.params]
 icon = "rss"

[[social]]
 identifier = "zenn"
 name = "Zenn"
 url = "https://zenn.dev/nakurei"

 [social.params]
 icon = "link"

module.toml

module.toml holds the Hugo Module settings. I manage the theme as a Git Submodule rather than a Hugo Module, so I didn’t create module.toml.

params.toml

params.toml holds site-wide parameters — what used to live under params in v3. The following params changed in v4.

dateFormat moved from Go format strings like Jan 02, 2006 to Hugo format strings like :date_full and :date_medium
SortBy was added
featuredImageField was removed: v4 always uses image
defaultImage.opengraph was removed

params.toml after the changes

params.toml

# Pages placed under these sections will be shown on homepage and archive page.
mainSections = ["post"]
# Output page's full content in RSS.
rssFullContent = true
favicon = "img/favicon.png"

# Accepted values: "default", "lastmod"
# default = see https://gohugo.io/quick-reference/glossary/#default-sort-order
# lastmod = sort by last modified date, in descending order
SortBy = "lastmod"

[author]
 name = "NakuRei"
 url = "https://notes.nakurei.com/"

[footer]
 since = 2022
 customText = ""

[dateFormat]
 published = ":date_medium"
 lastUpdated = ":date_medium"

[sidebar]
 compact = false
 emoji = "🐢"
 subtitle = ""
 avatar = "img/avatar.png"

[article]
 headingAnchor = true
 math = false
 toc = true
 readingTime = true

 [article.license]
 enabled = true
 default = "Licensed under CC BY-NC-SA 4.0"

[widgets]
 homepage = [
 { type = "search" },
 { type = "categories", params = { limit = 10 } },
 { type = "tag-cloud", params = { limit = 10 } },
 { type = "archives", params = { limit = 5 } },
 ]
 page = [
 { type = "toc" },
 { type = "categories", params = { limit = 10 } },
 { type = "tag-cloud", params = { limit = 10 } },
 ]

[opengraph.twitter]
 site = "nakurei7901"
 card = "summary_large_image"

[colorScheme]
 toggle = true
 default = "auto"

## Comments
[comments]
 enabled = false
 provider = "disqus"

 # See all the available configurations at https://github.com/CaiJimmy/hugo-theme-stack/blob/master/config/_default/params.toml
 # Copy the configurations you need from there and paste it here.

## Original url-card shortcode
defaultNoImage = "icons/photo-off.svg"
defaultNoLinkImage = "/icons/link-off.svg"
imageQuality = 80

permalinks.toml

permalinks.toml contains the same settings that were under permalinks in v3.

permalinks.toml after the changes

permalinks.toml

post = "/post/:slug/"
page = "/:slug/"

related.toml

related.toml contains the same settings that were under related in v3. There are no new options.

related.toml after the changes

related.toml

# Related contents configuration
includeNewer = true
threshold = 60
toLower = false

indices = [
 { name = "tags", weight = 100 },
 { name = "categories", weight = 200 },
]

Move the favicon

The favicon and avatar images lived in static/ in v3, but v4 expects them in assets/. On this site the avatar was already in assets/img/, but the favicon was in static/img/, so I moved the favicon image to assets/img/.

Fix the front matter of your pages

The front matter of articles changed between v3 and v4. What was hidden in v3 became build.list in v4. So if you were setting hidden = true, you need to change build.list to never like this.

Example of the front matter change

---
- hidden: true
+ build:
+ list: never
---

If you were setting hidden = false, set build.list to always.

Example of the front matter change

---
- hidden: false
+ build:
+ list: always
---

Migrate your layout customizations

In Hugo, you can override a theme’s files by placing a file with the same name in the same location. Between v3 and v4, the Stack theme changed both how the theme is written and how its files are split up. So if you customized the theme, you need to fix the location, name and content of your customized files to match v4.

Move the contents of `layouts/_default/` into `layouts/`

With the Modern Template System introduced in Hugo v0.146.0, organizing files under a layouts/_default/ folder was deprecated and consolidated into placing them directly under layouts/. The Stack theme followed suit: in v4 the contents of layouts/_default/ moved into layouts/. So if you were using layouts/_default/, move it to layouts/.

In my case I had modified the theme’s layouts/_default/_markup, so I moved layouts/_default/_markup to layouts/_markup.

Move the contents of `layouts/partials` into `layouts/_partials`

This is another consequence of the Modern Template System introduced in Hugo v0.146.0. Stack v4 follows it and changed layouts/partials to layouts/_partials. So if you customized the theme, you need to move the contents of layouts/partials into layouts/_partials.

Change the header image height

In Stack v4 you can change the header image height in assets/scss/custom.scss¹. The defaults are 150px on mobile, 200px in between, and 250px on large screens. In v3 I had customized these to 100px on mobile, 150px in between and 150px on large screens, so I created assets/scss/custom.scss with the following.

assets/scss/custom.scss

:root {
 --article-image-height: 100px;

 @include respond(md) {
 --article-image-height: 150px;
 }

 @include respond(xl) {
 --article-image-height: 150px;
 }
}

Remove `var(--zh-font-family)`

In v3 I had customized the CSS on this site to change the font, but Stack v4 removed var(--zh-font-family), so my existing setting was ignored if left as-is. I removed var(--zh-font-family). Referencing an undefined CSS variable invalidates the whole property, so just deleting it brought my customization back.

References and URLs

Upgrade to v4 | Stack

Card-style Hugo theme designed for bloggers

stack.cai.im

hugo-theme-stack-starter/config/_default at master · CaiJimmy/hugo-theme-stack-starter

A quickstart template to create a Hugo blog using hugo-theme-stack - CaiJimmy/hugo-theme-stack-starter

github.com

In Stack v3 you had to override assets/scss/partials/article.scss to change this, so personally I’m glad about this change. ↩︎

Posts on NakuRei's Notes

Notes on Migrating from Volta to mise

What is this

Removing Volta

Installing mise

Installing global tools

References and URLs

Fixing Voicemeeter Banana's AUX Input Showing "no driver present" and Producing No Sound

What this is

Environment

Symptoms

Cause

What I checked

Research

Fix

Fixing the `code` Command Not Opening VS Code in WSL Remote Mode

The problem

The cause

The fix

Notes from Reviewing My GitHub Repository Security Settings

What is this?

Conclusion

1. Add a SECURITY.md file

2. Enable PVR (Private Vulnerability Reporting)

3. Enable Secret scanning alerts

4. Enable Dependabot

5. Enable Code scanning

6. Protect the default branch

Wrapping up

Testing a Linux Tauri App on a Hyper-V Ubuntu VM

What is this

Environment

Preparation

On the Windows host

On the Ubuntu VM

Installing on the VM

Uninstalling on the VM

When Paste Suddenly Stopped Working in tmux on WSL: Notes on the Fix

What this is

What happened

Environment

Cause

Investigating the cause

Solution

Wrapping up

Notes on Migrating the Hugo Stack Theme from v3 to v4

Overview

Environment

Upgrade Hugo

Fix the X shortcode

Replace .Site.Data with hugo.Data

Temporarily move custom files aside

Migrate the config files

config.toml

languages.toml

markup.toml

menu.toml

module.toml

params.toml

permalinks.toml

related.toml

Move the favicon

Fix the front matter of your pages

Migrate your layout customizations

Move the contents of layouts/_default/ into layouts/

Move the contents of layouts/partials into layouts/_partials

Change the header image height

Remove var(--zh-font-family)

References and URLs

Replace `.Site.Data` with `hugo.Data`

Move the contents of `layouts/_default/` into `layouts/`

Move the contents of `layouts/partials` into `layouts/_partials`

Remove `var(--zh-font-family)`