yaya | error: hash mismatch in fixed-output derivation '/nix/store/b5s2gx9yj2rchx9wfj4iihswp9yl5938-akkoma.drv':
 yaya |          specified: sha256-mJtgBkoENgDE8KAhtwm4ual8pQnGQRJMvPgkubVTPQM=
 yaya |             got:    sha256-TGC7pxUoK6krgEB7Mz9pd5QMl2VFRJ3robaz4c+kqFE=

I’ll correct the mistake and push the corrections after running the tests successfully.

Unlike pleroma, they don't ship a pre-built frontend. I think that's good, but also means that we should probably provide users with a way of installing a frontend, and possibly even add Akkoma's soft-fork of pleroma-fe as a source-built package.

It is a bit unfortunate that their mix.exs still specifies "pleroma" and they don't properly update the version attribute either. mixRelease requires the pname and version to match what's in the mix.exs. Would be nice if we could find a way around that. The latest upstream release is tagged as stable-202209.

I could adjust mix.exs automatically to correspond to the tagged version number. I tried that successfully for 3.2.0.

Unlike pleroma, they don't ship a pre-built frontend. I think that's good, but also means that we should probably provide users with a way of installing a frontend, and possibly even add Akkoma's soft-fork of pleroma-fe as a source-built package.

Installing a frontend can be done with pleroma_ctl, but the RELEASE_COOKIE environment variable has to be set manually.

Frontends could also be included as bind mounts into the Nix store.

I could adjust mix.exs automatically to correspond to the tagged version number. I tried that successfully for 3.2.

That could work for now, but maybe someone should talk to upstream about matching the version in mix.exs to the tag name for future releases.

While there are also tagged versions with version numbers, the actual stable releases with changelogs etc. are named after by the month they were released in:
https://meta.akkoma.dev/c/releases/7

Installing a frontend can be done with pleroma_ctl, but the RELEASE_COOKIE environment variable has to be set manually.

Well, yeah, that works. But it is not really great that the user has to set up the state to get a usable setup.

I could adjust mix.exs automatically to correspond to the tagged version number. I tried that successfully for 3.2.

That could work for now, but maybe someone should talk to upstream about matching the version in mix.exs to the tag name for future releases.

While there are also tagged versions with version numbers, the actual stable releases with changelogs etc. are named after by the month they were released in: https://meta.akkoma.dev/c/releases/7

It looks to me that the stable tags just point to the commit that merges the release from the develop branch into the stable branch. So stable-202209 essentially points to the same code as v3.2.0. In that sense the versions already match the tag names.

Installing a frontend can be done with pleroma_ctl, but the RELEASE_COOKIE environment variable has to be set manually.

Well, yeah, that works. But it is not really great that the user has to set up the state to get a usable setup.

This problem might be difficult to solve without adding a new module for Akkoma.

Such a module could allow the user to specify the frontends, defaulting to pleroma-fe and admin-fe as built from the store.

Installing a frontend can be done with pleroma_ctl, but the RELEASE_COOKIE environment variable has to be set manually.

Well, yeah, that works. But it is not really great that the user has to set up the state to get a usable setup.

This problem might be difficult to solve without adding a new module for Akkoma.

Such a module could allow the user to specify the frontends, defaulting to pleroma-fe and admin-fe as built from the store.

My first attempt at packaging the frontend: illdefined@b9ed43e

I was not sure about the canonical way of integrating it with the rest of the Nix packages.

admin-fe appears to be built‐in, but there is masto-fe and firebird-fe.

Instead of relying on the pleroma module, this PR now introduces a dedicated akkoma module that uses elixirConf to generate the configuration file from an attribute set, supporting secrets through replace-secret. I copy‐edited the pleroma test to make use of it.

Since Akkoma does not bundle a frontend, the module takes care of that and includes a few options to override its default settings, styles and themes.

I wasn’t sure about the proper way to integrate the (primary) frontend with the rest of nixpkgs. It is currently available at akkoma-frontends.pleroma-fe.

What's the migration path from a running pleroma instance? Is it mentioned in the docs somewhere I couldn't find?

What's the migration path from a running pleroma instance? Is it mentioned in the docs somewhere I couldn't find?

https://docs.akkoma.dev/stable/installation/migrating_to_akkoma/ I'd assume that someone would need to create a NixOS specific migration path though

What's the migration path from a running pleroma instance? Is it mentioned in the docs somewhere I couldn't find?

https://docs.akkoma.dev/stable/installation/migrating_to_akkoma/ I'd assume that someone would need to create a NixOS specific migration path though

yeah some of these things are not applicable to a nix-based setup. you certainly don't want to use pleroma_ctl to directly manage your pleroma install...

What's the migration path from a running pleroma instance? Is it mentioned in the docs somewhere I couldn't find?

https://docs.akkoma.dev/stable/installation/migrating_to_akkoma/ I'd assume that someone would need to create a NixOS specific migration path though

It should be as easy as copying the database and the upload directory or pointing Akkoma to the existing ones, and enabling the service. The database migrations are run automatically during startup of the service.

Should I add a chapter to the manual?

I've migrated an existing non-NixOS Pleroma install to this module by doing pretty much that, plus rewriting the config in Nix.

The only problem was that the initial migration takes a while, and because it's run in ExecStartPre, it's subject to getting killed by Systemd before completion. Upping TimeoutStartSec might be a good idea in this module.

K900@8680298 seems to fix it, but also maybe we should just symlink that stuff instead of copying it?

Looks like frontend building is currently broken - the built files end up in ...akkoma-static/frontends/$name/stable/$storepath/ instead of ...akkoma-static/frontends/$name/stable.

I’ll fix it.

K900@8680298 seems to fix it, but also maybe we should just symlink that stuff instead of copying it?

Symlinking would be an option, but that might break confinement.

K900@8680298 seems to fix it, but also maybe we should just symlink that stuff instead of copying it?

Symlinking would be an option, but that might break confinement.

Couldn't the store paths for the frontends be allowed into the sandbox? Presumably we know them already.

K900@8680298 seems to fix it, but also maybe we should just symlink that stuff instead of copying it?

Symlinking would be an option, but that might break confinement.

Couldn't the store paths for the frontends be allowed into the sandbox? Presumably we know them already.

Is there a canonical way to recursively collect all dependencies of a derivation? That would allow us to construct a list of store paths to include, even with a custom derivation.

The static directory is now built by symlinking all the configured frontends etc.

With confinement enabled, all store paths in the closure are bind‐mounted to make them accessible. I used pkgs.closureInfo to collect the list of paths, but I am not sure if that is the best way to do it.

This is on track to become the most thoroughly reviewed PR in existence 😀

Let's get this in then. We can always add more later.

I just noticed that running both akkoma and pleroma still fails as described in #192285 (review). (I forgot to comment out my workaround)

Opened #208027 to track this issue.