Magically expressive social media
Go to file
Ilja 8b843be03e Fix test get_user_apps/1
For some reason I had a test who suddenly failed, mix test test/pleroma/web/o_auth/app_test.exs:54. A user has a list of applications and this test adds them and then sees if the list it gets back is the same as the apps it added.

When I ran mix test a day before I didn't have this problem and when I pushed code today in a different MR, the pipeline succeeded (see https://git.pleroma.social/ilja/pleroma/-/jobs/205827), yet locally it failed. So it seems the test can sometimes succeed and sometimes fail, which makes it untrustworthy.

The failure I see is because the returned list is in reverse order. I assume that's not per sé wrong. You just want to know if the apps you added are actually there. I fixed the test by first ordering the lists before comparing.

AFAICT (and as far as that's relevant) the test got introduced in commit cb2a072e62
2022-06-29 20:43:41 +01:00
.gitlab release MR template: add a note about merging stable changes back to 2020-08-26 07:09:28 +03:00
.woodpecker Add visibility check in context path (#26) 2022-06-29 09:33:57 +00:00
benchmarks Benchmarks: fix user timeline and tags benchmarks 2021-12-12 17:35:02 +00:00
ci CI: Use own package as base 2021-12-26 18:05:42 +01:00
config Add visibility check in context path (#26) 2022-06-29 09:33:57 +00:00
docs Purge gopher frontend 2022-06-27 17:31:16 +01:00
installation Revert "Merge branch 'remove/mastofe' into 'develop'" 2022-01-08 21:44:37 +00:00
lib Add unicode 14 support 2022-06-29 20:43:41 +01:00
priv update adminfe 2022-06-14 19:04:22 +01:00
rel allow %{source} dict in no_empty 2022-06-14 17:41:25 +01:00
restarter Merge branch 'develop' into gun 2020-03-07 12:41:37 +03:00
test Fix test get_user_apps/1 2022-06-29 20:43:41 +01:00
uploads fix issues with the uploads directory 2019-04-28 06:43:00 +02:00
.buildpacks CI: Add auto-deployment via dokku. 2019-05-31 10:55:35 +02:00
.credo.exs Move Consistency.FileLocation to ./test 2020-10-13 19:57:45 +02:00
.dockerignore remove docs/ from .dockerignore 2019-11-20 00:09:07 +09:00
.formatter.exs .formatter.exs: Format optional migrations 2021-01-10 11:28:41 +03:00
.gitattributes [#3112] .gitattributes fix. 2020-12-09 18:43:20 +03:00
.gitignore don't track vmargs 2021-12-06 10:23:02 +00:00
.gitlab-ci.yml CI: Fix the broken tasks. 2021-12-26 18:54:54 +01:00
.mailmap Add myself to .mailmap 2021-02-15 13:19:44 +03:00
AGPL-3 LICENSE → AGPL-3 2019-04-01 00:31:21 +02:00
CC-BY-4.0 Add a copy of CC-BY-4.0 to the repo 2020-09-06 11:38:38 +03:00
CC-BY-SA-4.0 CC-BY-SA-4.0: Add a copy of the CC-BY-SA-4.0 license 2019-04-01 00:30:21 +02:00
CHANGELOG.md Purge gopher frontend 2022-06-27 17:31:16 +01:00
COPYING Relicense documentation under CC-BY-4.0 2021-02-16 13:10:58 +03:00
coveralls.json exclude file_location check from coveralls 2020-10-13 16:44:01 +03:00
docker-entrypoint.sh Create docker.exs and docker-entrypoint + round out Dockerfile 2019-08-03 00:21:54 -04:00
Dockerfile Bump alpine to 3.14 2021-12-17 18:03:06 -05:00
elixir_buildpack.config Upgrade to Elixir 1.9 2020-06-16 13:18:29 +00:00
mix.exs Purge SSH frontend (#23) 2022-06-27 11:32:06 +00:00
mix.lock cherry-pick security from upstream 2022-06-22 16:25:05 +01:00
Procfile CI: Add auto-deployment via dokku. 2019-05-31 10:55:35 +02:00
README.md ensure tests pass 2022-06-14 16:24:03 +01:00
SECURITY.md SECURITY.md: update supported versions to only 2.2 2020-10-15 21:45:31 +03:00

akkoma

a smallish microblogging platform, aka the cooler pleroma

Why though?

pleroma as a project has stagnated of late. after a spat between developers led to a fork (which died due to chronic lack of direction), nearly nobody seems to want to work on it. this in addition to the BDFL being AWOL whenever needed, means that the entire project is nought but a power vacuum waiting for someone to step in. and with the track record pleroma has, i do not trust that whoever steps in will be good for the project.

thus, i am striking out on my own. i already had a few modifications on my instance, so it wasn't a particularly large leap to assume direct control.

But really, why should I migrate to your thing?

aside from me actually being responsive? let's lookie here, we've got

  • custom emoji reactions
  • misskey markdown (MFM) rendering and posting support
  • elasticsearch support (because pleroma search is GARBAGE)
  • latest develop pleroma-fe additions
  • local-only posting
  • probably more, this is like 3.5 years of IHBA additions finally compiled

Upgrading to Akkoma

From source

git remote set-url origin https://akkoma.dev/AkkomaGang/akkoma.git/
git fetch origin
git pull -r

Then compile, migrate and restart as usual.

Then if you've done anything fancy to the frontend, you'll want to get the updates for that as well. This won't be the same for any two instances, so https://akkoma.dev/AkkomaGang/pleroma-fe is the repo you need.

From OTP

export FLAVOUR=$(arch="$(uname -m)";if [ "$arch" = "x86_64" ];then arch="amd64";elif [ "$arch" = "armv7l" ];then arch="arm";elif [ "$arch" = "aarch64" ];then arch="arm64";else echo "Unsupported arch: $arch">&2;fi;if getconf GNU_LIBC_VERSION>/dev/null;then libc_postfix="";elif [ "$(ldd 2>&1|head -c 9)" = "musl libc" ];then libc_postfix="-musl";elif [ "$(find /lib/libc.musl*|wc -l)" ];then libc_postfix="-musl";else echo "Unsupported libc">&2;fi;echo "$arch$libc_postfix")

./bin/pleroma_ctl update --zip-url https://akkoma-updates.s3-website.fr-par.scw.cloud/develop/akkoma-$FLAVOUR.zip
./bin/pleroma_ctl migrate

Then restart. When updating in the future, can just use

./bin/pleroma_ctl update --branch develop

Old readme follows

About

Pleroma is a microblogging server software that can federate (= exchange messages with) other servers that support ActivityPub. What that means is that you can host a server for yourself or your friends and stay in control of your online identity, but still exchange messages with people on larger servers. Pleroma will federate with all servers that implement ActivityPub, like Friendica, GNU Social, Hubzilla, Mastodon, Misskey, Peertube, and Pixelfed.

Pleroma is written in Elixir and uses PostgresSQL for data storage. It's efficient enough to be ran on low-power devices like Raspberry Pi (though we wouldn't recommend storing the database on the internal SD card ;) but can scale well when ran on more powerful hardware (albeit only single-node for now).

For clients it supports the Mastodon client API with Pleroma extensions (see the API section on https://docs-develop.pleroma.social).

Installation

If you are running Linux (glibc or musl) on x86/arm, the recommended way to install Pleroma is by using OTP releases. OTP releases are as close as you can get to binary releases with Erlang/Elixir. The release is self-contained, and provides everything needed to boot it. The installation instructions are available here.

From Source

If your platform is not supported, or you just want to be able to edit the source code easily, you may install Pleroma from source.

OS/Distro packages

Currently Pleroma is packaged for YunoHost. If you want to package Pleroma for any OS/Distros, we can guide you through the process on our community channels. If you want to change default options in your Pleroma package, please discuss it with us first.

Docker

While we dont provide docker files, other people have written very good ones. Take a look at https://github.com/angristan/docker-pleroma or https://glitch.sh/sn0w/pleroma-docker.

Raspberry Pi

Community maintained Raspberry Pi image that you can flash and run Pleroma on your Raspberry Pi. Available here https://github.com/guysoft/PleromaPi.

Compilation Troubleshooting

If you ever encounter compilation issues during the updating of Pleroma, you can try these commands and see if they fix things:

  • mix deps.clean --all
  • mix local.rebar
  • mix local.hex
  • rm -r _build

If you are not developing Pleroma, it is better to use the OTP release, which comes with everything precompiled.

Documentation

Community Channels