Xournal++: a binary named Ubuntu-bionic will not run on Ubuntu 20.04

A binary named Ubuntu-bionic will not run on Ubuntu 20.04

The installing section carries a warning that is unusual in its specificity, and it is worth reading twice.

Official binaries are provided for Debian, Ubuntu, macOS and Windows, and each Linux binary is named after one distribution version. The worked example: if you are on Ubuntu 20.04, the binary whose name contains Ubuntu-bionic is only compatible with Ubuntu 18.04.

Bionic is the 18.04 codename. So the file you would grab while searching the release page for something matching your own system name is a binary built for a release two years older, and it will not start on your machine. There is nothing subtle going on here; the filename is the entire compatibility contract.

The guidance for anyone not on a specific supported Debian or Ubuntu version is to use one of three routes instead: the PPA, which the README marks as Ubuntu only, the Flatpak, or the AppImage.

So the practical sequence is: identify your distribution release, find the binary named for it, and if your release is not in the list, stop looking at the binaries entirely and take the Flatpak or the AppImage rather than guessing at a filename.

One related detail in the same section. Alongside the stable releases there is an unstable automated nightly release, described as including the very latest features and bug fixes, linked as a separate tag.

The AppImage is the only artefact with no distribution coupling

Among the official binaries there is one that behaves differently from the rest. The README provides binaries for Debian, Ubuntu, macOS and Windows, and separately notes that for other GNU/Linux distributions, or older and newer ones, an AppImage is provided that is binary compatible with any distribution released around or after Ubuntu 22.04.

That is a meaningfully different promise. The named binaries are tied to one release; the AppImage is tied to a floor. Anything from 22.04 onwards, and anything built on top of it, can run it.

The repository supports that route. There is an appimagecraft.yml at the top level, which is the build recipe AppImage tooling consumes, and the top-level listing also carries debian/ and rpm/ directories, so the project carries Debian and RPM packaging as well as the AppImage recipe. There is also a copy of copyright.txt and a package_description file, both of which packaging formats need.

The consequence for a user is that the AppImage removes the single most common installation failure in this project's distribution. If you are not certain which Debian or Ubuntu version you have, or you are on a distribution the binary list does not mention, this is the artefact to reach for rather than the Flatpak, because it keeps you inside the project's own build.

The cost is the usual one for a self-contained file: it is a single large executable you have to mark as executable and keep current yourself, rather than something your package manager updates.

The rolling nightly tag is dated 2021, which tells you nothing about the build inside it

Look at the release list: v1.3.8, then an entry tagged nightly and named Automated nightly build, then v1.3.7.

The dated versions are current. v1.3.8 was published on 2026-09-26 and v1.3.7 on 2026-08-09. The nightly tag's date reads 2021-07-18, which is five years before either of them and before the project reached this version series.

The date is not wrong so much as it is measuring something else. A rolling tag like nightly is a single tag that is deleted and recreated, or force-moved, on every automated build. The date attached to it is the date the tag was first created, and it stays there while the contents underneath change. So 2021-07-18 tells you when the automation started, not when the artefact was produced.

That matters for anyone automating a build or reporting a problem. If you install from the nightly tag and then file a bug quoting nightly, the maintainer has no version string to work from, and neither do you. The commit hash is the only identifier that means anything for a rolling channel.

The last push to the default branch master was on 2026-11-01, more than a month after v1.3.8, so the branch is ahead of the newest stable tag. For most people that is not a reason to use nightly; it is a reason to know that the stable tag is a few commits behind and that the README's description of nightly as containing the very latest features and bug fixes is literal.

Four install channels with four different stability promises

The Linux story is not one channel but several, and they make different promises.

The most conservative are the distribution repositories. On Debian bookworm and Debian sid, and on distros based on Ubuntu 22.04 Jammy Jellyfish or later, the stable package is in the official repositories:

sudo apt install xournalpp

That is the route with the longest lag between a commit and your machine, and correspondingly the least surprise.

Then there are two PPAs, and the README distinguishes them carefully. The stable PPA is described as unofficial, and the command to add it is:

sudo add-apt-repository ppa:apandada1/xournalpp-stable
sudo apt update
sudo apt install xournalpp

The unstable PPA is different again. It is provided by the Xournal++ team rather than by a volunteer, and it carries an explicit warning: it has the latest features and bug fixes, it has also not been tested thoroughly, and it may break periodically.

Fedora and openSUSE have their own shapes. Fedora offers the released version from the main repository with dnf or pkcon, and separately a COPR called luya/xournalpp carrying bleeding edge packages synced to git master daily. openSUSE Tumbleweed carries the released version from the main repository with zypper, while earlier Leap releases go through the X11:Utilities software collection, and a Staging repository carries bleeding edge synced to master weekly.

The consequence is that sync frequency is a per-distro variable. A daily COPR build and a weekly openSUSE staging build are both labelled bleeding edge, and they can be days or weeks apart from master. When you report a problem against a bleeding-edge package, the sync schedule is part of what the maintainer is reasoning about.

LaTeX support needs a LaTeX installation you supply yourself

The feature list includes LaTeX support, and the parenthetical matters: it requires a working LaTeX installation.

That single clause is the boundary of the feature. What the application provides is the integration, not the typesetting engine. The description goes on to say the feature comes with a customizable template and a resizable editor with syntax highlighting, which tells you the experience is an embedded editing surface rather than a separate tool you switch to.

So the parts you get are the authoring environment, the template you can change, and the highlighting. The part you do not get is the compiler and the TeX distribution. If LaTeX is not already on the machine, the feature has nothing to invoke, and you will find that out at the point you try to render rather than when you enable it.

That is not a criticism so much as a deployment note. On a desktop where you already write papers, it is a checkbox. On a locked-down work machine, or in a container, it is an install you have to arrange first.

The same pattern of shipping the shell rather than the dependency appears elsewhere in the list. Audio recording and playback works alongside handwritten notes, and export to SVG, PNG and PDF is available from both the interface and the command line. Plugins use Lua scripting, so the plugin runtime is built in while whatever the plugin itself needs is not.

Adding a language means asking a maintainer, not self-service

Translations are managed through Crowdin, and there is a crowdin.yml at the top of the repository configuring it. The application supports over 20 languages.

The interesting detail is the gate. To translate a language that does not yet exist, the instruction is to discuss it on Matrix or create a new issue in the repository to make that language available on Crowdin.

So the set of languages is not self-service. A translator who wants to add one cannot simply start; the project has to add it first. That is a deliberate choice for a project with a limited translation team, and it is the price of not maintaining a translation platform itself.

The catalogue format underneath is gettext. The top level carries a po/ directory, which is where translation catalogues live, alongside the Crowdin configuration that feeds it. That is the conventional arrangement for a GTK application and it means translators work in the format tooling expects rather than a bespoke one.

For a user, the practical consequence is narrower than it sounds. Over 20 languages is a reasonable coverage for a note-taking application,. For a translator, it means the first contribution for a new language is a request rather than a pull request.

Command line export is claimed and never shown

One feature line makes two promises in a row. Export is available to a variety of formats including SVG, PNG and PDF, and it is available both from the interface and from the command line.

The feature list does not include an example command-line invocation.

What it does establish is that scripting is intended. Export being available headlessly is what lets you build a pipeline: render a document to PNG in a batch job, or convert annotations to SVG for processing afterwards. The formats are the ones that make that useful, since SVG is text and PDF is self-contained.

If you are evaluating this for a scripting workflow, that promise is the thing to test first.

Lua plugins and a .gpl palette format are the two extension points

Two extension mechanisms are named, and they are both more specific than a generic plugin system.

The first is scripting. Plugins use Lua, and the plugin directory is at the top of the repository.

The second is less obvious and more specific: custom colour palettes are supported using the .gpl format. That is the GIMP palette format, which is a plain text list of colour values with names. The repository carries a palettes/ directory, and it also carries resources-templates/ alongside resources/.

The rest of the customisation story is configuration rather than extension. Tools and colours can be mapped to stylus and mouse buttons, the toolbar is customisable with multiple configurations such as one optimised for a portrait page and one for a wide page, and there are page template definitions. Input stabilisation is listed too, which is a renderer setting for smoother writing rather than anything a plugin touches.

Desktop integration is handled by the man/ directory for documentation, desktop/ for the desktop entry, and Doxyfile for generated developer documentation.

Editorial conclusion

Adopt Xournal++ when you need stylus-first note taking with PDF annotation, LaTeX, audio and Lua plugins on Linux, macOS or Windows, and when you will match the binary to your distribution version. Do not download a distribution-named binary on the off version, because the README states it will not run, and use the AppImage when your distribution is not in the supported list. Verify which channel you installed from, because the stable PPA is unofficial while the unstable PPA is team-run and explicitly untested. Confirm a LaTeX installation exists before relying on that feature, since the application does not ship one.

Frequently asked questions

Official sources

1. License: GPL-2.0
2. Project website
3. README
4. Releases
5. xournalpp/xournalpp on GitHub