Trapped inside a tölva

Managing nginx

Thu, 01 Jan 2026 00:00:00 +0100

Nginx can be a bit of a bother to configure, especially since I want to buy in the configuration that my distribution provides.

On my Debian box, this is what the configuration layout looked like when I started. In the rest of this post, I will omit parts of the configuration that are not relevant.

# tree -d /etc/nginx/
/etc/nginx/
├── conf.d
├── modules-available
├── modules-enabled
├── sites-available
└── sites-enabled

The configuration was split into directories, and I would modify a single file in a directory. As an example, I added a notfound configuration file for a catch-all website that would be used for mispellings or mistyped URLs. This prevents nginx from redirecting a request for edoput.it to somethingelse.edoput.it.

# tree  /etc/nginx/
/etc/nginx/
├── sites-available
│   ├── default-server.conf
│   └── notfound.conf
└── sites-enabled
    ├── default-server.conf -> /etc/nginx/sites-available/default-server.conf
    └── notfound.conf -> /etc/nginx/sites-available/notfound.conf

The interesting bit about this layout is that there is an available folder and an enabled folder. Configuration files are stored in the available folder and symlinked from the enabled folder. This makes it easy to enable and disable a website without actually changing it. You can either create or delete a symbolic link in the filesystem but the actual configuration is never touched. This is extremely handy.

# rm /etc/nginx/sites-enabled/default-server.conf # disable default-server
# ln -s /etc/nginx/sites-enabled/default-server.conf /etc/nginx/sites-available/default-server.conf # enable default-server

The problem is that these command are a mouthful and could be abstracted. If you think we should take advantage of the available/enabled split then you should be interested in nginxctl. It is similar in spirit to nginx_ensite ¹ but extends to the many kinds of resources that nginx has.

Once copied to /usr/local/bin/nginxctl, you create a new command to manage the resource you are interested in-for example, the configuration files in the sites directory:

# ln -s /usr/local/bin/nginxctl /usr/local/bin/sites

This also means that by replicating the available/enabled pattern for a resource you automatically get the command to work. As an example, I will show my current configuration: I have added directories for maps, streams , and upstreams and created a command for each of them.

# tree -d /etc/nginx
/etc/nginx/
├── conf.d
├── map-available
├── map-enabled
├── modules-available
├── modules-enabled
├── sites-available
├── sites-enabled
├── streams-available
├── streams-enabled
├── upstream-available
└── upstream-enabled
# tree /usr/local/bin
/usr/local/bin/
├── nginxctl
├── maps -> /usr/local/bin/nginxctl
├── sites -> /usr/local/bin/nginxctl
├── streams -> /usr/local/bin/nginxctl
└── upstreams -> /usr/local/bin/nginxctl

I found this extremely helpful for managing the complexity I created for myself. Moreover as you may have intuited by now, these are all commands available to shell scripts, which means you can build upon them to automate even more.

And Apache’s a2ensite a2disite ↩

Immutable Linux is just right (for me)

Tue, 11 Nov 2025 00:00:00 +0100

You should spend some time in immutable Linux land, you might like it. When starting my PhD I got handed a laptop and told to set it up. At the time I chose OpenSUSE Aeon as I was familiar with Tumbleweed. This was a fantastic choice and for the kind of work I do and I don’t regret it. Removing the burden of system administration is a value I can get behind and I think it really paid off.

Each day I get a notification to reboot to update. The system has been updated automatically and it is waiting for me. Each day I ignore it and I know that tomorrow I will boot into the updated system and it will just work. Nothing is lost or non functional. Ever.

Getting software was extremely easy because Flatpak is integrated within the software portal. Day to day life is uneventful as everything I really need I have. The apps I need (Emacs, Firefox, Zotero) are packaged and automatically updated. I can even use my wonky extensions setup without too much hassle.

Distrobox has been my workhorse, mostly unnoticed which is good, and the only time I had to install something on the host system was to get virtualization to work. I could figure it out before the deadlines for artifact review went by so another win.

Other apps I got are Flatseal and Warehouse because truly Flatpak is a bit too much to handle sometimes. If I didn’t care to have a dead-simple, reproducible, can’t-break-it setup I would have used distrobox’s export feature. Anything installed in a container managed by distrobox is also available from the host launcher. Truly magical.

But I did care about dead-simple, reproducible, can’t-break-it setup so I have packaged even more apps and I am happy with the result. This is the first time that I have a disaster recovery plan for my system and my data and I am confident that it will work.

The most important endorsement I can give to this way of life was reading Aeon: openSUSE for the lazy developers when it came out in June 2024 and thinking “I have used a release-candidate all this time without an issue. I didn’t even notice it .”.

Isabelle/ML starting tips

Sun, 02 Nov 2025 00:00:00 +0100

Isabelle/HOL is an interative theorem prover. To be extremely precise Isabelle is a distribution of a the theorem prover and HOL is an object logic embedded in the ambient logic. If this is confusing don’t sweat about it, it’s only to make the next distinction a little clearer.

I have recently started a project using Isabelle/ML, the part of the Isabelle distribution where you write Standard ML code to extend what Isabelle can do on the logic side. These are small tips that made me more productive because the experience of using Isabelle/ML is really subpar to using Isabelle and Isabelle/HOL.

Can’t click X

Isabelle has a neat feature where you can Ctrl-Click anything and it will bring you to where it is defined. This does not work as well in Isabelle/ML, especially with the output buffer. This breaks the flows a lot because I cannot find my way to a type or a module fast.

Let’s see an example where we want to see the type of Object_Logic.atomize. In my theory file I write the following.

ML_val <
  Object_Logic.atomize
>

In the output buffer I can then read the following but I cannot click anything. I can copy this signature to the previous block and click it though.

val it = fn : Proof.context -> conv

In general though if you know where you want to go there are two ways to get there fast. For types it is easy to define a newtype and the right-hand-side will be clickable, for modules it is always possible to open them. In the following snippet both Proof.context and Proof are targets that you can Ctrl-Click and you will land where they are defined.

ML_val <
  type A = Proof.context;
  open Proof;
>

Syntax and type errors

Everybody starts with the embedded ML because it is easy. The errors though could be better. The syntax and type errors may mix though making it hard to understand what is the problem and how do you fix it.

As always the way out is kind of boring and obvious when you think about it.

Always start with a complete ML expression which produces no syntax error and then start adding stuff.

The following snippet is an example of many things that could go wrong. Am I getting an error because there is a type mismatch or because the term is not parsable? I cannot tell.

ML_val <
let
  val an_id : a_type_signature = an_expression
>

Small incremental steps instead bring you there. First a parsable term

ML_ <
let
in
  ()
end
>

Then a name and type for your binding.

ML_ <
let
  val a_name : a_type = error "TODO"
in
  ()
end
>

Then a body for your binding.

ML_ <
let
  val a_name : a_type = error "TODO"
in
  body
end
>

Then a value

ML_ <
let
  val a_name : a_type = a_value
in
  body
end
>

Each small step is either a syntax error or a type error and you can always tell.

Error is surprisingly useful

Just like you would use undefined in your inner syntax to have a hole you can fill in later I think error is a fantastic hole for your ML sources.

Finding other stuff

We do not have access to find_theorems and find_consts so the way forward is textual seach. Lucky us that this is already available.

Where to find stuff

We have stuff already

The Isabelle distribution comes with a bunch of stuff already. You most likely know that Isabelle/HOL is defined in the HOL directory of the Isabelle distribution. There are other developments there such as FOL, LCF, Pure, ZF.

I like to interactively explore this root directory using the builtin search.

I always start with filtering out the ML files because I am looking for examples of how to use the outer syntax. If I am looking for examples of Isabelle/ML I also start with the theory files because it’s likely that I am reinventing the wheel.

Then when I’m done with theory files I start searching through the ML sources.

The Archive of Formal Proofs

The AFP is another good source of examples you should comb. Instead of looking at the web frontend you should download it and use the builtin search as described before.

Starred forms

Sat, 25 Oct 2025 00:00:00 +0200

Bob complains that starred commands in LaTeX can have a better user-experience. This actually sent me back in time to younger edoput trying to understand why some scheme functions are suffixed with ‘*’, e.g. append*.

Two instances don’t make a pattern but I’m wondering if there’s a third programming language where * is also used in identifiers with the same intent, “like this other thing, but a little bit different”. Then the next question would be did LaTeX steal this from scheme or vice-versa? Also is this a LaTeXism or is this already in TeX?

Better Koreader plugin debugging

Tue, 07 Oct 2025 00:00:00 +0200

There was one huge pain point during the development of gotobed: I would put in bugs without knowing and things would go bad. A plugin is effectively a smaller application that is embedded into Koreader but Koreader did very little to point out what went wrong in case something goes wrong.

This behavior is actually implemented by the following piece of code. At plugin load time the function sandboxPluginEventHandlers would be called with the plugin table. This table is inspected for key,value pairs that match an event handler: the key matches the prefix "on" and the value is of type function. For each pair that matches, the event handler is wrapped into an anonymous function that executes a protected call. Errors are logged as is without further processing.

-- koreader/frontend/pluginloader.lua

local function sandboxPluginEventHandlers(plugin)
    for key, value in pairs(plugin) do
        if key:sub(1, 2) == "on" and type(value) == "function" then
            plugin[key] = function(self, ...)
                local ok, re = pcall(value, self, ...)
                if ok then
                    return re
                else
                    logger.err("failed to call event handler", key, re)
                    return false
                end
            end
        end
    end
end

This implementation works but does not make me, the plugin developer, happy. Let’s break it down.

This is the behavior of pcall.

If there are no errors, pcall returns true, plus any values returned by the call. Otherwise, it returns false, plus the error message.
Programming in Lua - Error Handling and Exceptions

Moreover, anything can be an error but it’s most likely an error message. If it’s an internal error, Lua will generate the error message. As an example consider the following errors.

Lua 5.1.5  Copyright (C) 1994-2012 Lua.org, PUC-Rio
> 1 + "a"
stdin:1: unexpected symbol near '1'
> error ("I am a naughty bug") 
stdin:1: I am a naughty bug
stack traceback:
	[C]: in function 'error'
	stdin:1: in main chunk
	[C]: ?

The first error message is quite simple but the second is much more detailed: there is a stack-trace that tells me what happened and where, meaning I can actually debug this.

If I could get a description for the first error that is as detailed as the second one I would be happy. Internal errors have been the majority during my delelopment, which means that having good stack-traces would improve much my experience. Moreover a short investigation reveals that, at the time of writing, there are only 6 instances of error calls in the plugin shipped with Koreader. This means that they are on the same boat and would benefit from stack-traces on internal errors.

Because the handlers in the plugin are only invocked in a protected call, errors raised in the plugin will not bubble up to Koreader. Our problem is the following:

Frequently, when an error happens, we want more debug information than only the location where the error occurred. At least, we want a traceback, showing the complete stack of calls leading to the error. When pcall returns its error message, it destroys part of the stack (the part that went from it to the error point). Consequently, if we want a traceback, we must build it before pcall returns.
Programming in Lua - Error Messages and Tracebacks

So either I, the plugin developer, build the stack-trace and stuff it in the error message myself or there is no stack-trace. Lucky me that error does this implicitly. Unlucky me that internal Lua errors do not do so.

Turns out that if we ask nicely Lua will not throw away the stack information.

To do that, Lua provides the xpcall function. Besides the function to be called, it receives a second argument, an error handler function. In case of errors, Lua calls that error handler before the stack unwinds, so that it can use the debug library to gather any extra information it wants about the error.
Programming in Lua - Error Messages and Tracebacks

So that’s what I implemented recently in plugin handlers tracebacks.

Have a better debugging experience!

Minibuffer and input method

Sun, 31 Aug 2025 00:00:00 +0200

I really like typesetting with unicode math symbols. I use them in my notes, sometimes even in LaTeX as we get the unicode-math package. To input unicode symbols in Emacs I use the unicode-math package and before that my own-grown input method. The input method is bound to a buffer so when you switch (intentionally or not) to another buffer typing \alpha will not result in a pretty α being rendered. I can live with this. Except when switching to the minibuffer!

The minibuffer better be aware of my current input method! So be it!

(defun minibuffer-input-method-initialize ()
  "Initialize input method from `minibuffer-selected-window'."
  (let* ((win (minibuffer-selected-window))
         (buf (and win (window-buffer win))))
    (when buf
      (activate-input-method (buffer-local-value 'current-input-method buf)))))

 (use-package emacs
   :ensure nil
   ...
   :hook ((minibuffer-setup-hook . minibuffer-input-method-initialize)))

Emacs: a paradigm shift

Wed, 16 Apr 2025 00:00:00 +0200

Recently I read this beginners guide to extend Emacs. The guide is perfect for starting out with elisp and it shows a lot of care in teaching how to interact with Emacs.

To me, the most important bit though is this one, from the section aptly named Emacs Wants You to Extend It.

I haven’t written plugins for other editors extensively, but I can tell you this: emacs doesn’t just make deep customization available, but it actively encourages you to make an absolute customization messes masterpieces. Core editor functions aren’t just documented, but often include tidbits about “you probably want to see this other variable” or “here’s how you should use this”.

Not only that, but emacs happily hands you functions shaped like nuclear warheads like advice-add (that let you override any function) that can absolutely obliterate your editor if you hold it the wrong way. Of course, this also grants you unlimited power.

Remember that emacs is designed to be torn apart and rearranged.

This is the core bit of the argument. Emacs, as a system, wants you to extend it and it gives you all the means to do so. This is in contrast with systems that can be extended through scripting and instead don’t give you all the means to do so!

I think the tutorial is a fantastic example of doing things right. There is a well-thought example, a constructive approach where the solution grows to a full package.

This is problematic. You may get the impression that extending Emacs is only possible if you do things right and that is definitely not true.

To make my point I want to walk you through an example. I will show you how I used standard Emacs extension-points to extend org-mode to sort my reading lists automatically.

What do I want?

The behavior I want is that when I save an org file the entries are ordered automatically. I keep a timeline of the papers I am reading and it is annoying to keep them kind of ordered.

This is the content of an example buffer.

#+TITLE: My thematic reading list

* Paper which is old but not too old
:PROPERTY:
:year: 2002
:END:

* Definitely older paper but unfortunately it's later in the list
:PROPERTY:
:year: 1998
:END:

When I add a paper to my reading list I run org-sort-entries and interactively select to order the entries by the value in the property year. Initally this was nice to have but now it’s just annoying that I have to keep doing it. Let’s extend org-mode so that this is done automatically.

A simple solution

The first step is to automate the interactive part. Lucky for me this is easy as org-sort-entries is both a function and a command. I can call it in a script just as I can run it as a command.

(defvar org-sort-option "year")

(defun org-sort-run ()
  (when (and (derived-mode-p 'org-mode) org-sort-option)
    (let ((case-sensitive nil)
	  (sorting-type ?r)
	  (getkey-func nil)
	  (compare-func nil)
	  (property org-sort-option)
	  (interactive? nil))
      (org-sort-entries case-sensitive sorting-type getkey-func compare-func property interactive?))))

This solves one part of the problem. Let’s solve the other one, automatically calling org-sort-run whenever an org-mode buffer is saved.

Emacs already has support for this use-case through the use of hooks. We can run org-sort-run all the times we want to save a buffer.

(add-hook 'before-save-hook #'org-sort-run)

These two together solve the problem but the solution presented is “just more code”. We tapped into the hook extension point but this would be possible in any scriptable system that exposes well-defined extension points such as hooks and commands.

Leveraging Emacs’ extensibility to extend org-mode

I want to show that even if something is not thought with extensibility in mind Emacs allow us to extend it. Most importantly, while we want to extend org-mode’s behavior we would like this not to be an extension to org-mode’s code.

Here’s the updated problem statement. Have the buffer be automatically sorted and have the sorting criteria be in the buffer itself. We will specify the sorting as a in-buffer setting and use Emacs to support this never thought before org-mode behavior.

Our example buffer changes to the following.

 #+TITLE: My thematic reading list
+#+SORT: year
 
 * Paper which is old but not too old
 :PROPERTY:
 :year: 2002
 :END:
 
 * Definitely older paper but unfortunately it's later in the list
 :PROPERTY:
 :year: 1998
 :END:

The hard part of this is to find how org-mode reads in-buffer settings from the header. A M-x find-library later we are in org’s sources.

Searching for +STARTUP (Ctrl+s +STARTUP), one of the supported settings, leads us to org-startup-folded and that in turn (Ctrl+s org-startup-folded) leads us to org-startup-options.

org-startup-options is then used by (again Ctrl+s org-startup-option) org-set-regexps-and-options.

While the documentation for this function is not very convincing, its code does make sense for what we are after. I copied it here for reference.

  (when (derived-mode-p 'org-mode)
    (let ((alist (org-collect-keyword
		  (append '("FILETAGS" "TAGS")
			  (and (not tags-only)
			       '("ARCHIVE" "CATEGORY" "COLUMNS" "CONSTANTS"
				 "LINK" "OPTIONS" "PRIORITIES" "PROPERTY"
				 "SEQ_TODO" "STARTUP" "TODO" "TYP_TODO")))
		  '("ARCHIVE" "CATEGORY" "COLUMNS" "PRIORITIES"))))
      ;; Startup options.  Get this early since it does change
      ;; behavior for other options (e.g., tags).
      (let ((startup (cl-mapcan (lambda (value) (split-string value))
				(cdr (assoc "STARTUP" alist)))))
	     ...)

Unfortunately this function calls org-collect-keyword with a list that we cannot touch. There is no custom variable to set to pass our own keyword.

If this was a “normal programming environment” we would make our changes to this function body and forever maintain a fork of org-mode. As this is elisp instead we have choices.

I think the best choice is to use advice-add and have Emacs call our advice code every time org-set-regexps-and-options is called. We will copy what we need from the function body but that will be all.

This is what I ended up with.

(defvar org-sort-option nil)

(defun org-sort-set-option (&rest r)
  "Read the +SORT: spec value into variable `org-sort-option'."
  (when (derived-mode-p 'org-mode)
    (let ((alist (org-collect-keywords '("SORT"))))
      (let ((sort (cdr (assoc "SORT" alist))))
	(let ((sort-spec (car (read-from-string (car sort)))))
	  (setq-local org-sort-option sort-spec))))))

(advice-add 'org-set-regexps-and-options :after #'org-sort-set-option)

(defun org-sort-run ()
  (when (and (derived-mode-p 'org-mode) org-sort-option)
    (let ((case-sensitive nil)
	  (sorting-type ?r)
	  (getkey-func nil)
	  (compare-func nil)
	  (property org-sort-option)
	  (interactive? nil))
      (org-sort-entries case-sensitive sorting-type getkey-func compare-func property interactive?))))

(add-hook 'before-save-hook #'org-sort-run)

We keep a buffer-local variable org-sort-option around to store the property name read from #+SORT: property-name. This variable is initially nil and will be set from the property name in #+SORT: property-name. To do so we have a function org-sort-set-option.

But when to call org-sort-set-option? The easy way out is to have Emacs call it whenever org-set-regexps-and-options is called on a file visit. To achieve this we tap into advice-add and ask Emacs to run org-sort-set-option after org-sort-regexps-and-options.

We have now succesfully interposed ourselves in the control flow of the org-mode library.

Org-mode did not provide any interposition point for us, there is no thought ahead extension-point or configuration variable we can use to achieve our goal an yet here we are with a sorted buffer.

We succeeded in our effort because Emacs wants you to extend it and it gives you all the means to do so.

Conclusions

I have made a horrible hack and it works. I have learnt nothing about how org-mode works or Emacs’ file-visiting extension-points.

RE: your application environment variables

Mon, 18 Nov 2024 00:00:00 +0100

Loading values from the environment into variables is a way to configure processes at startup. Alternatives are to define a command-line interface or parsing configuration files.

Each of these methods has its advantage but loading values from the environment has a shortcoming. As an operator you have to refer to the documentation of the tool as there is no interface to query what the process expects.

This is possible when using a command line interface as libraries have implemented a default -h/--help flag that will print what is expected. It is also possible to use a format for configuration files that supports comments to document the values supported.

I have published another environment variable parser package that fills this void as follows.

It is possible to define program variables that will hold the associated environment values.
It is possible to define different sets of environment variables in the same application. This allows subcommands to have their own environment variables.
It is possible to get a description of the set of environment variables that includes the name, type, default value, and a short description.

I have adapted the flag package for this purpose and it is available here. I would like to thank the Go authors for the flag package’s design. It was fairly easy to adapt it and all the errors you may find are my own.

This is a minimal example to see how the package can be used to load values from the environment in program variables and get a description of the variables the program expects.

package main

import (
  "github.com/edoput/env"
)

func main() {
  var _ = env.Bool("BLEP", false, "Should we blep?") // do gophers blep?
  env.Parse()
}

And the corresponding usage as an operator.

$ main # no output
$ HELP= main # setting HELP or H will trigger the usage message
Environment of main:
  BLEP  boolean
    	Should we blep?

Is this good? Is this bad? I’m not sure but I’m not going back.

Previous art in environment loading

There are many packages dedicated to parsing values from environment variables. Here is an incomplete list along with their pros.

Most of these packages focus on loading environment variables into one config structure as a program variable. All provide a procedural API and almost all support some sort of reflection driven by struct tags. One of these packages introspect on the environment variables the program declares to do something meaningful.

kelseyhightowers/envconfig

Package envconfig implements decoding of environment variables based on a user defined specification.

This package is by far the most popular I can find. It supports loading values into a structure, struct tags to make that easy, and custom decoders. There are many other reimplementations but none has the same reach.
olivere/env

The env package is to simplify reading environment variables with e.g. the flag package.

This package actually implements a similar API but focuses on using environment variables as fallbacks for flag variables.
code.cloudfoundry.org/go-envstruct

envstruct is a simple library for populating values on structs from environment variables.

This package is the first that implements the missing feature. The WriteReport function can be used to give a description of the environment variables the program defines but is not wired up by default.

Flatpak: how to keep your development tools at runtime

Tue, 01 Oct 2024 00:00:00 +0200

Running MicroOS as my daily on the work laptop is quite the experience. Nothing ever breaks but at the same time there is very little that can. This is because the apps I need are not packaged. Sad.

Over time I have packaged what I need but one of them took some time. VisualVM is a GUI to troubleshoot your Java processes, as it requires the Java SDK and Java SRE at runtime I was not sure how to package it.

Development tools and libraries are available at build time but applications are not shipped with them. Turns out that it was easy but almost undocumented so here we are. I will give bits and pieces of the manifest I made and explain what parts where necessary to have access to the Java SDK and Java JRE at runtime so that others may do the same.

The Flatpak build process is isolated in a sandbox and this means that we have access to almost nothing. What we need to build the app must be brough into the sandbox. This is where the sdk image comes in. The sdk image is a file-system with lots of development tools that can be used by flatpak at build times. The problem for us is that it does not have /all the tools/.

The sdk image does not provide a Java SDK and Java JRE so you cannot build your Java applications as is. The sanctioned way to do build a Java app is to use a sdk image extension. Following is the incantation to use the openjdk extension.

sdk-extensions:
  - org.freedesktop.Sdk.Extension.openjdk

The extension provides the (Java) tools and libraries we need at build time but we also want them available at runtime. As this is a sensible use-case the publishers of the sdk extension have included a script to install everything in the final artifact that we produce. Following is the incanation to do so.

modules:
  - name: install-openjdk
    buildsystem: simple
    build-commands:
      - /usr/lib/sdk/openjdk/install.sh

Now tools like javac will be available both at build time and runtime. Everything we need will be copied in the /app directory. If the packaged app requires the tools we can point it there and everything will work as expected.

Following is the manifest that I have used to package VisualVM.

id: io.github.visualvm
branch: '2.1.10'
runtime: org.freedesktop.Platform
runtime-version: '24.08'
sdk: org.freedesktop.Sdk
sdk-extensions:
  - org.freedesktop.Sdk.Extension.openjdk
finish-args:
  # setup JRE and JDK path
  - --env=PATH=/app/jre/bin:/usr/bin
  # X11 + XShm access
  - --share=ipc
  - --socket=x11
  # GPU acceleration if needed
  - --device=dri
  # Needs to talk to the network:
  - --share=network
  - --persist=.visualvm
command: /app/visualvm/bin/visualvm
modules:
  - name: install-openjdk
    buildsystem: simple
    build-commands:
      - /usr/lib/sdk/openjdk/install.sh
  - name: install-visualvm
    sources:
      - type: archive
        url: 'https://github.com/oracle/visualvm/releases/download/2.1.10/visualvm_2110.zip'
        archive-type: 'zip'
        sha256: 87850af9e9873c690cbb76056627e73dfbfd1e1d95279a9031722a85ac36d999
    buildsystem: simple
    build-commands:
      - mkdir -p ${FLATPAK_DEST}/visualvm
      - cp -ar * ${FLATPAK_DEST}/visualvm
    build-options:
      strip: true # debugedit craps otherwise
  - name: install-desktop-app
    sources:
      - type: file
        path: io.github.visualvm.desktop
    buildsystem: simple
    build-commands:
      - install -D --target-directory=${FLATPAK_DEST}/share/applications -m444 ${FLATPAK_ID}.desktop

Redux: Running zotero in background

Mon, 23 Sep 2024 00:00:00 +0200

For the last years I have been runnning Zotero headlessly. It starts as a user service when I log in and provides the same features except for the GUI. Other programs, e.g. browser, word processor, can interact with it without fault.

In the previous setup I was managing Zotero but today I need to use Flatpak. So let’s update this setup and have it work as well.

The major change is that we do not interact with the Zotero process directly but with wrapper processes, i.e. the bubblewrap sandboxing.

# ~/.config/systemd/user/zotero.service
[Unit]
Description=Run zotero in background

[Service]
# flatpak manages the lifecycle of zotero now, got to delegate
ExecStart=flatpak run org.zotero.Zotero --headless
ExecStop=flatpak kill org.zotero.Zotero
Restart=on-failure
RestartSec=30s

[Install]
# actually starts this service when I log in
WantedBy=default.target