Akkoma stable 2024.04 - straight up fixing it in the git... and by it, haha, well, i mean our bhackend

heblo duelists today i have a release of many little things for you. not much flashy today, it’s mostly much-needed fixes and other such fun and games

i do have a fun one though!

New stuff

Image metadata now prefills descriptions


The ExifTool.ReadDescription upload filter has been added! When activated, this will utilise Exiftool to read image metadata and attempt to prefill the description field. Useful :slight_smile:

Please note that if also using ExifTool.StripMetadata, the ordering is important! We can’t read metadata that we’ve already stripped, after all. So ReadDescription has to come before StripMetadata


Heck me we have a lot of these this month

this is the primary content of the release!

I would literally just be repeating the Changelog, and most of it isn’t stuff you’d really notice having been changed, so let me just link you to the changelog if you’re interested


Same as ever! Updating your instance - Akkoma Documentation

There is one database migration this month, so don’t forget to run your ecto.migrate on source or migrate on OTP!


Oneric for many fixes and practically being a co-maintainer these days. wooo
Norm for documentation fixes!
timorl and ilja for the exiftool rework and new upload filter!
erincandescent for compatibility fixes on the AP level!
Helge for fep compliance work!
Snan for .atom display fixes!


i was a little late on the admin-fe builds so if you notice that you don’t have StripMetadata config options in the admin-fe, you updated before the release went out, my apologies~


Thank you very much for your work with Akkoma. I just tried the upgrade and ran into the error below:

 sudo ./docker-resources/manage.sh mix compile 
[+] Creating 1/0
 ✔ Container akkoma-db  Running                                                                                                                                                                              0.0s 
Compiling 333 files (.ex)
Compiling lib/pleroma/web/gettext.ex (it's taking more than 10s)
error: module Pleroma.Web.ActivityPub.Visibility is not loaded and could not be found. This may be happening because the module you are trying to load directly or indirectly depends on the current module
  lib/pleroma/web/mastodon_api/views/status_view.ex:26: Pleroma.Web.MastodonAPI.StatusView (module)

== Compilation error in file lib/pleroma/web/mastodon_api/views/status_view.ex ==
** (CompileError) lib/pleroma/web/mastodon_api/views/status_view.ex: cannot compile module Pleroma.Web.MastodonAPI.StatusView (errors have been logged)

Any idea what might be going on?

are you on a clean git checkout? since it compiles elsewhere without issue, i can only imagine that you’ve made local changes and run into merge issues

Hm, let me reset git and try again…

Had to manually add "config :pleroma, Pleroma.Upload, base_url: “https://example.com/media/” to my config, otherwise the upgrade went smoothly.


this was required in the last update and is prominently noted in both the upgrade notes and the error message you get if you don’t set it

Odd, the previous update went through fine without it. Anyways…

Right. For the first time in a very long time, the update didn’t go smoothly. Now my instance is doing a 502 no matter what I’m doing. I literally followed the instructions for OTP install upgrade, as I have done multiple times before. Trying to work out if I have missed a step in the instructions in here, but if I have, I can’t see it.

The instance (Ubuntu 22.04) has been running for over a year and I usually keep on track with latest release for everything. I do have the config in the database. Would I perhaps need to add something to the config file still? Perhaps it is loaded before the database config kicks in?

The commands I’ve run, as instructed on the upgrade page:

sudo -su akkoma

cd /opt/akkoma

./bin/pleroma_ctl update --branch stable

./bin/pleroma stop

./bin/pleroma_ctl migrate

./bin/pleroma daemon

./bin/pleroma_ctl frontend install pleroma-fe --ref stable

A 502 would indicate permissions are buggered up somewhere, but everywhere I look it looks…fine (as it was yesterday).

If I look at the processes I can see that the beam.smp is VERY busy doing something, but I’m not sure how to work out what/why it is doing.

that is not what a 502 implies, 502 means your reverse proxy cannot connect through to the phoenix server

run in the foreground with start instead of using daemon to see what the logs say

It’s ok, I think I had what @Kris had: somehow we got through the previous update without updating the config file. I didn’t update it at the time as I wasn’t sure if I needed to (as I have the config in the database).

Now, as things weren’t working and I saw that Kris got his stuff to run after adding it, I did too, thinking I had nothing to lose. Turns out it is a good thing indeed, and now my instance is up again.

I’m receiving 502 errors after the update.

When I did the last update I had to add "config :pleroma, Pleroma.Upload, base_url: “https://example.com/media/” like Kris. That’s still in place so I’m not sure what to look at next. Any suggestions would be appreciated.

please look at your logs, as suggested above

no diagnostics are possible without this information

just… as a general rule of thumb always check your logs

we here at akkoma gang incorporated plc GmbH LLC do not install backdoors on your machine and hence we do actually require you to do some basic information gathering before requesting assistance


2024.04.1 security release is out!

standard upgrade procedure (see Updating your instance - Akkoma Documentation)

no manual intervention needed

1 Like

Thanks for the fast update.

One of the things which keeps on confusing me is the nomenclature of Akkoma.
Here we are talking about release 2024.04.1 and the likes, but in the app all I see is Backend version 3.13.2?

Do the version numbers and backend version relate in any way?
I can check the local Changelog.md, but that will only tell me that this file was updated not necessarily what “binary” I am running.

we are forced by elixir to use semantic versioning for the mix project

however these semantic versions are meaningless to most people, which is why we use date-based versions to communicate with people

I see. And because the UIs aren’t controlled by you, the UIs don’t know about your version and pull up the Elixier version.
The consequence is that it’s impossible for a user to determine if his server is running the latest software, and an admin will have to ssh into the Akkoma install directory to check the CHANGELOG file in case he didn’t closely follow your releases.

Anyway, given my two small instances this is a rhetorical conversation rather than a problem for me, and I will happily go with what works best for you.

an admin will have to ssh into the Akkoma install directory to check the CHANGELOG file in case he didn’t closely follow your releases.

ahh that in itself isn’t actually true - a mapping is presented on the releases page