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

f8df40867700ffba283b34994a7519fd92a5d55fe1691dce9032807f6cd4dbde
a0b5137ae077a7dab89aec45efae59b17d2a9ed61ad5f81553e66c7b53b3b401

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

Fixes

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

Upgrade

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!

Thankies

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!

4 Likes

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~

2 Likes

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.

Thanks!

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

3 Likes