↓Skip to main content
  1. Posts/

j2k25 - OpenBSD Hackathon Japan 2025

·2566 words·13 mins· loading · loading ·
Rafael Sadowski
Author
Rafael Sadowski
Shut up and hack
Table of Contents

Three Weeks in Japan: Ultramarathon, Hackathon, and Sightseeing
#

My trip to Japan started a week before the hackathon, but the planning actually began much earlier. When it became clear that there would be a OpenBSD hackathon in Japan in 2025, I immediately started making preparations. Planning for me means finding the perfect combination of activities - and what could be better than an ultra marathon (Since I am asked again and again: Ultra >= 50K) in a foreign country? Maybe a ultra trail but that was not possible in our time frame.

I quickly discovered the Yatsugatake Nobeyama Highland 100 km Ultramarathon via ahotu.com. It has always been a dream of mine to run an ultra/marathon in a distant location. However, I didn’t want to tackle my first 100K in Japan while dealing with jet lag, so I opted for the 68K distance instead. When my wife heard the combination - Japan, ultramarathon, and hackathon - she was immediately enthusiastic and wanted to join.

We booked our flights, registered for the race, and bought a Lonely Planet guide. We were ready for Japan!

Week 1: Tokyo and the Nobeyama Ultramarathon
#

We had a surprisingly comfortable flight from FRA to NRT with Japan Airlines. Despite flying economy class, we managed to sleep for 5-6 hours during the 13-hour journey. You have to know that you pay a lot of attention to our scarf. Sleep nerds? Upon arriving at NRT, we quickly purchased a Suica card, loaded it with credit, and took the 2-hour train ride into the incredible city of Tokyo.

Our first evening was spent exploring the vibrant Kabukicho district, where we grabbed dinner and enjoyed in the atmosphere. If you enjoy Japanese food, it’s nearly impossible to go wrong - quality is consistently high everywhere. The challenge isn’t finding good food, but discovering the truly exceptional places. Surprisingly, this rarely correlates with price.

The following days were dedicated to discovering Tokyo. We spent most of our time walking and exploring and sightseeing. My wife took care of researching and planning our activities, which allowed me to focus on managing my jet lag. This was crucial since the ultramarathon was scheduled to start at 4:55 AM on Sunday.

I made a critical oversight by forgetting to bring melatonin for this trip. Unfortunately, it’s not available over-the-counter in Japan without a medical prescription - only strong sleeping pills are available without prescription. This resulted in a full week of jet lag struggles.

Tokyo’s highlight for me was the complete experience: my first time in Japan, exploring this massive yet incredibly well-organized metropolis, and the constant sense of discovery around every corner. There’s something deeply relaxing about wandering through a city, experiencing its culture, and always wondering what delicious meal awaits next.

Race Day: The Nobeyama Ultramarathon
#

On Sunday, we met up with goda@, who was also running the race and had confirmed his attendance at the hackathon. We traveled together by train to Nobeyama and collected our race packets. Here I encountered my first translation challenge - I had selected a T-shirt during registration but received a towel instead. This falls into the category of “translation issues in Japan.” While websites aren’t particularly English-friendly and translation tools sometimes struggle, they generally work well enough.

The jet lag situation reached its peak before the race - only 3 hours of sleep before a 68K run. I threw all preconceptions out the window and accepted that this day would be challenging. This was particularly daunting since my wife and I had already completed two ultramarathons in the previous five weeks, with the UTFS being especially brutal for me.

An important lesson learned: when something is called “Ultramarathon” in Japan, it means road running, not trail running. Pack your road shoes, not trail shoes!

The race itself went reasonably well. We were fortunate to have mostly cloudy conditions, though I got a decent sunburn during the final two hours when the sun emerged.

After the race, I slept like a rock from Sunday to Monday. The next morning, we departed for Nara, requiring five different trains to travel from the Japanese Alps. j2k25, here we come!

Week 2: The j2k25 Japan Hackathon
#

We arrived in Nara during the late afternoon. After checking into our hotel, goda@, my wife and I headed straight to the hack room. My initial thought was to finally do some ports hacking to warm up and create a plan for the upcoming week. I hadn’t had much opportunity for focused thinking during our busy week in Tokyo.

As soon as I booted OpenBSD, kn@ appeared. I was genuinely happy to see him again, and we spent the first half hour catching up. Then he mentioned we were about to head to the team event. This completely derailed my planned “first day” approach - instead of keyboard and OpenBSD work, the evening was filled with excellent food, beer, and funny conversations.

At breakfast, I met with tb@ and had an interesting conversation. He asked if I could update graphics/blender, which appeared to be broken but was requested by users. I added Blender 4.4 to my (unpredictable) hackathon task list.

I also received 1-2 emails about KDE Plasma during the last weeks. The main issue was that it kept crashing when users entered text in the application launcher. After the first day, I realized the need for a KDE Plasma README that was both up-to-date and more robust for typical use cases and new users. Having used KDE Plasma as my daily driver under OpenBSD, I had become blind to potential user experience issues.

I spent considerable time reading ports@ mailing list entries and reviewing/testing new submissions. I found several interesting new ports, including print/pdf4qt from landry@ and sysutils/piknik from volker@. When ports are well-prepared, the review process is straightforward: review, build, and test.

KDE Development Progress
#

kn@ was kind enough to review several new KDE ports I had been working on:

We’re gradually building out the complete KDE Gear stack in OpenBSD. Some components are still missing, but I don’t see a need to port KDE Mobile Plasma-only applications. Itinerary remains on my TODO list.

To address the search-related crashes, I created a fresh KDE user account to ensure no existing configurations were interfering with the testing process. Since I typically have all KDE applications installed, I was able to reproduce the crash quickly.

The issue occurs when entering text in the KDE search menu from the application launcher - it attempts to search everything (applications, home directory, etc.) simultaneously. This quickly overwhelms OpenBSD’s restrictive default limits, and since no error handling exists for this scenario, the application crashes.

The solution is straightforward: increase the restrictive limits for KDE users. As a result, kde-plasma (pkg_add kde-plasma) now ships with a kde login class. This can be easily applied to KDE users with usermod -L kde your-user-name.

System Tuning Recommendations
#

I recommend the following system tuning for all KDE Gear/KDE Plasma users:

You might want to consider increasing the kern.maxfiles tunable. Many services
and applications need to monitor activity of a lot of files.

# sysctl kern.maxfiles=65535
# echo "kern.maxfiles=65535" >> /etc/sysctl.conf

KDE PIM and Akonadi Configuration
#

A new section has been added to the README for KDE PIM users, based on insights from FreeBSD documentation:

KDE PIM and Akonadi
===================
KDE PIM applications like Akonadi, KMail, and Kontact use large messages on the
local machine. The default size on OpenBSD is too small, which causes local
connection issues, and Akonadi-based applications will be flaky (e.g. mailboxes
do not display, messages cannot be found).

Increasing the buffer size is recommended:

# sysctl net.unix.stream.recvspace=65536
# echo "net.unix.stream.recvspace=65536" >> /etc/sysctl.conf

# sysctl net.unix.stream.sendspace=65536
# echo "net.unix.stream.sendspace=65536" >> /etc/sysctl.conf

Unfortunately, several Akonadi modules continue to crash when loading models:

  • akonadi_followupreminde
  • akonadi_ical_resource
  • akonadi_maildispatcher_
  • akonadi_mailmerge_agent
  • akonadi_sendlater_agent

I’ve submitted a bug report but haven’t received a response yet. I’m considering temporarily disabling these modules in our ports while continuing to investigate the root cause.

KDE session Management Improvements
#

Another insight from the hackathon is that we can continue to clean up our KDE related .xsession, but should add a dbus-launch to it. The following is now recommended until sddm is ported and does it all for us.

export XDG_RUNTIME_DIR=/tmp/run/$(id -u)
if [ ! -d $XDG_RUNTIME_DIR ]; then
    mkdir -m 700 -p $XDG_RUNTIME_DIR
fi

if [ -x /usr/local/bin/dbus-launch -a -z "${DBUS_SESSION_BUS_ADDRESS}" ]; then
    eval `dbus-launch --sh-syntax --exit-with-x11`
fi

${LOCALBASE}/bin/ck-launch-session ${LOCALBASE}/bin/startplasma-x11

This setup has worked well and received positive feedback from other users.

ck-session-notify - ConsoleKit session notifications
#

Since I brought a new notebook (ThinkPad T14 AMD Gen5) to the hackathon, I spent time configuring KDE Plasma. I particularly enjoy the tiling functions in KDE6, along with customizing various shortcuts and features.

I had an idea to display hotplugd(8) notifications in KDE Plasma and began writing a shell script that could be called from /etc/hotplugd/{attach,detach}. Here’s the resulting concept:

#!/bin/sh

# Send notifications to all active ConsoleKit sessions

# XXX
# You have to allow root access to all session buses. /etc/dbus-1/session.conf:
# <busconfig>
#   <policy context="mandatory">
#     <allow user="root"/>
#   </policy>
# </busconfig>

# Usage: ck-session-notify [app_name] [icon] [title] [message] [timeout_ms]

# Examples:
# ck-session-notify "hotplugd" "emblem-important" "Attached" "New fido dev" 8000

PATH="/usr/bin:/bin:/usr/local/bin"

if [ "$(id -u)" -ne 0 ]; then
	exit 1
fi

if ! command -v ck-list-sessions >/dev/null 2>&1; then
	echo "Error: ck-list-sessions not found" >&2
	exit 1
fi

if ! command -v gdbus >/dev/null 2>&1; then
	echo "Error: gdbus not found" >&2
	exit 1
fi

ck-list-sessions | grep -G7 -A9 "active = TRUE" | while read -r line; do
	case "$line" in
	*"unix-user = "*)
		user_id=$(echo "$line" | cut -d"'" -f2)
		;;
	*"x11-display = "*)
		display=$(echo "$line" | cut -d"'" -f2)
		username=$(id -nu "$user_id")

		dbus_socket=$(find /tmp -name "dbus-*" -user "$username" \
			-type s 2>/dev/null | head -1)

		if test -n "$username" && test -S "$dbus_socket"; then
			USER=$username \
				DISPLAY="${display:-:0}" \
				DBUS_SESSION_BUS_ADDRESS="unix:path=$dbus_socket" \
				gdbus call --session \
				--dest org.freedesktop.Notifications \
				--object-path /org/freedesktop/Notifications \
				--method org.freedesktop.Notifications.Notify \
				"${1:-System}" 0 "${2:-dialog-information}" \
				"${3:-Message}" "${4:-Broadcast}" "[]" "{}" "${5:-3000}" \
				>/dev/null
		fi
		;;
	esac
done

YubiKey Integration Example
#

To access my YubiKey from Keepasscx (security/keepassxc), my user needs access to the usb devies. I also use ck-list-sessions to determine the current user. This should work under all WM that are started with ${LOCALBASE}/bin/ck-launch-session.

/etc/hotplug/attach:


#!/bin/sh

DEVCLASS=$1
DEVNAME=$2

case $DEVCLASS in
0) DEVCLASS_NAME="generic" ;;
1) DEVCLASS_NAME="CPU" ;;
2) DEVCLASS_NAME="disk drive" ;;
3) DEVCLASS_NAME="network interface" ;;
4) DEVCLASS_NAME="tape device" ;;
5) DEVCLASS_NAME="serial interface" ;;
esac

case $DEVNAME in
uaudio*)
	pkill -HUP sndiod
	;;
fido*)
	/etc/hotplug/ck-session-notify "hotplugd" "" \
		"Attachment" "$DEVCLASS_NAME: Yubico YubiKey OTP+FIDO+CCID" 5000
	USER="$(ck-list-sessions | grep -B7 "active = TRUE" | grep "unix-user" |
		head -1 | sed "s/.*unix-user = '//; s/'.*//" | xargs id -nu)"
	if test -n "$USER"; then
		chown $USER /dev/ugen*.*
		chown $USER /dev/usb2
		chown $USER /dev/usb1
		chown $USER /dev/usb0
	fi
	;;
*) ;;
esac

/etc/hotplug/detach:

case $DEVNAME in
uaudio*)
	pkill -HUP sndiod
	;;
fido*)
	/etc/hotplug/ck-session-notify "hotplugd" "" "Detachment" \
		"$DEVCLASS_NAME: Yubico YubiKey OTP+FIDO+CCID" 5000
	chown root /dev/ugen*.*
	chown root /dev/usb2
	chown root /dev/usb1
	chown root /dev/usb0
	;;
*) ;;
esac

Security Note: Anyone who uses this useful approach should be aware that there is also a risk here if USER applications have unrestricted access to the USB stack. Another possibility would be to create a group for this and set the group rights to the corresponding devies. This has the tradeoff that it has to be renewed with every sysupgrade. Choose your heavy, the risk remains.

Hardware Fixes: AMD ThinkPad Power Button
#

I haven’t found the time to write a blog post about my new Thinkpad T14 AMD Gen5 yet. In short, it works more than it doesn’t work. What unfortunately doesn’t work is suspend/resume (S0ix) or and the power button doesn’t work either (so that you can shutdown the system if you press it longer and the kernel handles the corresponding interrupt). During the hackathon mlarkin@ found out the corresponding gpio interruptand kettenis@ had a patch ready in no time. In the meantime the patch has been committed and the power button works as usual under OpenBSD.

Port Updates: Blender and Dependencies
#

The graphics/blender update mentioned by tb@ turned out to be manageable. I appreciate working on CMake ports - they’re generally well-structured and straightforward to handle for me.

The missing brotli support for woff2 in our Xenocara FreeType version wasn’t problematic. My pragmatic solution was to decompress the fonts and force blender use TTF fonts directly. This required tools that weren’t available in our archivers/woff2 package.

The Blender port modification was implemented quickly:

post-install:
        ${MODPY_COMPILEALL} ${PREFIX}/share/blender/
        # Replace woff2 with ttf
        find ${PREFIX}/share/blender/4.4/datafiles/fonts -name '*.woff2' \
                -exec ${LOCALBASE}/bin/woff2_decompress {} \;
        rm ${PREFIX}/share/blender/4.4/datafiles/fonts/*.woff2

I updated the entire Blender dependency chain to the current state and ran it through an amd64 bulk-build to ensure no negative impacts before committing.

Port Maintenance: Taglib2 Update
#

Last but not least I worked on the taglib2 update. Also not a big deal if it wasn’t our really badly maintained ports audio tree. If you have the time and desire you should update the ports in audio. There is so much old stuff in there. Spooky old!

Week 3: Relaxation and Sightseeing
#

During the final week in Japan, my OpenBSD-related activities were limited to completing the taglib2 update and writing this trip report. The remainder of the time was dedicated to exploring Japan’s cultural offerings.

Our itinerary took us from Nara to Kyoto, then to Nagoya, and finally back to Kyoto. This was generally a relaxing period filled with entertainment and exceptional food experiences.

In Kyoto, we visited two extremely popular sightseeing locations that deserve specific mention:

Senbon Torii (Thousand Torii Gates)
#

Initially, I approached this with typical tourist skepticism - planning to look for five minutes, take a photo, and leave immediately. My wife convinced me that we should hike all the way to the top, where it would likely be less crowded. I remembered that again that elevation gain is the most effective filter for casual tourists. The experience was rewarding, and we enjoyed peaceful moments during the ascent. I definitely recommend making the full journey to the summit.

Arashiyama Bamboo Forest
#

The Kyoto Arashiyama Bamboo Forest was as crowded as Senbon Torii, but since there was no elevation involved as a natural filter, we took a pleasant hike along the river instead. Here, distance from the main attraction served as the filter. We were even fortunate enough to encounter some polite monkeys (we were in Japan, after all) who were curious but not overly shy.

Final Days in Tokyo
#

I had no particular expectations for Nagoya and was surprised by its beautiful castle and the relative absence of crowds. This made for a much more relaxed sightseeing experience.

We spent our last three days back in Tokyo, where we were greeted by several hours of rain. Despite this minor setback, the overall experience was exceptional.

I’m certain that we’ll return to Japan in the future. The next visit will likely focus on hiking opportunities and hopefully another excellent OpenBSD hackathon. The combination of technical work, physical challenges, and cultural exploration made this trip uniquely rewarding and memorable.

Thanks
#

A big thank you goes out to Yasuoka Masahiko the OpenBSD Foundation for making this happen! A special thanks to all who support my work.