Package Details: mastodon 4.2.9-1

Git Clone URL: https://aur.archlinux.org/mastodon.git (read-only, click to copy)
Package Base: mastodon
Description: Your self-hosted, globally interconnected microblogging community
Upstream URL: https://github.com/mastodon/mastodon
Keywords: activitypub fediverse mastodon server
Licenses: AGPL3
Submitter: flacks
Maintainer: dodecahedron
Last Packager: dodecahedron
Votes: 21
Popularity: 1.08
First Submitted: 2018-06-19 19:35 (UTC)
Last Updated: 2024-05-30 22:45 (UTC)

Latest Comments

1 2 3 4 5 6 .. 9 Next › Last »

dodecahedron commented on 2024-06-13 14:20 (UTC)

@gaboflowers I think makepkg now generates debug symbols by default, so you might want to disable that in /etc/makepkg.conf since this package is huge so generation will take a long time and unless you're a Mastodon dev, you probably don't need debug symbols.

gaboflowers commented on 2024-06-13 07:45 (UTC) (edited on 2024-06-13 07:49 (UTC) by gaboflowers)

I tried to install it, but got stuck at one step. This is the last printed:

[5/6] Building fresh packages...
[6/6] Cleaning modules...
Done in 22.37s.
==> Entering fakeroot environment...
==> Starting package()...
==> Tidying install...
  -> Removing libtool files...
  -> Purging unwanted files...
  -> Removing static library files...
  -> Copying source files needed for debug symbols...

I googled, and it seems like "Copying source files needed for debug symbols" is a niche-popular step to get stuck at. Any ideas on what could be the reason here?

EDIT: Retried and it worked. I'm leaving this in case anyone goes through the same.

dodecahedron commented on 2024-05-26 16:06 (UTC)

@Sandwich Thanks for reporting this. It seems to be caused by the recent GCC 14 and ICU 75 updates, and has also been reported upstream: https://github.com/brianmario/charlock_holmes/issues/173 https://github.com/brianmario/charlock_holmes/issues/172

I pushed a commit to this PKGBUILD implementing one of the fixes suggested in those issues.

Sandwich commented on 2024-05-26 14:42 (UTC)

I was able to fix the compile issue by deleting .bundler .yarn .cache/yarn

Sandwich commented on 2024-05-25 17:33 (UTC) (edited on 2024-05-25 17:41 (UTC) by Sandwich)

Till last week's update, everything was fine.

I can see that he is using a different bundler version Bundler 2.5.4 is running, but your lockfile was generated with 2.4.13. Installing Bundler 2.4.13 and restarting using that version.

Deleting .bundler does not change this.

Compile error:

compiling transliterator.cpp
In file included from /usr/include/unicode/unistr.h:39,
                 from /usr/include/unicode/translit.h:27,
                 from transliterator.cpp:5:
/usr/include/unicode/stringpiece.h:133:29: error: ‘enable_if_t’ in namespace ‘std’ does not name a template type
  133 |             typename = std::enable_if_t<
      |                             ^~~~~~~~~~~
/usr/include/unicode/stringpiece.h:133:24: note: ‘std::enable_if_t’ is only available from C++14 onwards
  133 |             typename = std::enable_if_t<
      |                        ^~~
/usr/include/unicode/stringpiece.h:133:40: error: expected ‘>’ before ‘<’ token
  133 |             typename = std::enable_if_t<
      |                                        ^
In file included from /usr/include/unicode/uenum.h:25,
                 from /usr/include/unicode/utrans.h:22,
                 from /usr/include/unicode/translit.h:29:
/usr/include/unicode/localpointer.h:561:26: error: parameter declared ‘auto’
  561 | template <typename Type, auto closeFunction>
      |                          ^~~~
/usr/include/unicode/localpointer.h:573:76: error: template argument 2 is invalid
  573 |     explicit LocalOpenPointer(std::unique_ptr<Type, decltype(closeFunction)> &&p)
      |                                                                            ^
/usr/include/unicode/localpointer.h:583:78: error: template argument 2 is invalid
  583 |     LocalOpenPointer &operator=(std::unique_ptr<Type, decltype(closeFunction)> &&p) {
      |                                                                              ^
/usr/include/unicode/localpointer.h:599:59: error: template argument 2 is invalid
  599 |     operator std::unique_ptr<Type, decltype(closeFunction)> () && {
      |                                                           ^
/usr/include/unicode/uenum.h:69:1: note: invalid template non-type parameter
   69 | U_DEFINE_LOCAL_OPEN_POINTER(LocalUEnumerationPointer, UEnumeration, uenum_close);
      | ^~~~~~~~~~~~~~~~~~~~~~~~~~~
/usr/include/unicode/uset.h:358:1: note: invalid template non-type parameter
  358 | U_DEFINE_LOCAL_OPEN_POINTER(LocalUSetPointer, USet, uset_close);
      | ^~~~~~~~~~~~~~~~~~~~~~~~~~~
/usr/include/unicode/utrans.h:258:1: note: invalid template non-type parameter
  258 | U_DEFINE_LOCAL_OPEN_POINTER(LocalUTransliteratorPointer, UTransliterator, utrans_close);
      | ^~~~~~~~~~~~~~~~~~~~~~~~~~~
make: *** [Makefile:238: transliterator.o] Error 1

make failed, exit code 2

dodecahedron commented on 2024-05-17 19:37 (UTC)

Hi @aoneko, thanks for reporting that error. For me, both cbor and posix-spawn are failing to compile, and it seems to be due to Arch's recent GCC upgrade from 13.2 to 14.1. Both libraries are very old and not really maintained anymore (actually Mastodon is removing their dependency on posix-spawn), so in the meantime, I added a CFLAGS to ignore these errors. For more info, see https://github.com/rtomayko/posix-spawn/issues/91

aoneko commented on 2024-05-17 17:44 (UTC)

aur/mastodon/src/mastodon-4.2.8/vendor/bundle/ruby/3.0.0/gems/cbor-0.5.9.6/ext/cbor
make DESTDIR\= sitearchdir\=./.gem.20240518-11265-869ort sitelibdir\=./.gem.20240518-11265-869ort
compiling buffer.c
compiling buffer_class.c
buffer_class.c: In function ‘read_until_eof’:
buffer_class.c:270:17: error: passing argument 3 of ‘rb_rescue2’ from incompatible pointer type
[-Wincompatible-pointer-types]
  270 |                 read_until_eof_error, (VALUE)(void*) args,
      |                 ^~~~~~~~~~~~~~~~~~~~
      |                 |
      |                 VALUE (*)(VALUE) {aka long unsigned int (*)(long unsigned int)}
In file included from /usr/include/ruby-3.0.0/ruby/ruby.h:38,
                 from /usr/include/ruby-3.0.0/ruby.h:38,
                 from compat.h:30,
                 from buffer_class.c:28:
/usr/include/ruby-3.0.0/ruby/internal/iterator.h:51:40: note: expected ‘VALUE (*)(VALUE,  VALUE)’ {aka ‘long
unsigned int (*)(long unsigned int,  long unsigned int)’} but argument is of type ‘VALUE (*)(VALUE)’ {aka
‘long unsigned int (*)(long unsigned int)’}
   51 | VALUE rb_rescue2(VALUE(*)(VALUE),VALUE,VALUE(*)(VALUE,VALUE),VALUE,...);
      |                                        ^~~~~~~~~~~~~~~~~~~~~
make: *** [Makefile:246: buffer_class.o] Error 1

This type of error tends to depends on the Ruby version which installed in your system. But you know that the Ruby version in Arch Linux distro is lower than the minimum requirement. I guess this might be the reason that caused the problem. Just for a reference.

dodecahedron commented on 2024-05-11 17:23 (UTC)

This package uses Ruby from the official Arch repos, which hasn't been updated in a long time. However, I haven't had any problems running Mastodon with this old version of Ruby.

jimchen commented on 2024-05-11 06:02 (UTC)

The ruby version seem to be outdated Here it requires 3.2.3 but the ruby bundler is 3.0.6

dodecahedron commented on 2024-01-15 02:38 (UTC) (edited on 2024-01-15 02:44 (UTC) by dodecahedron)

Is anyone else experiencing segfaults with an error message like /var/lib/mastodon/vendor/bundle/ruby/3.0.0/gems/blurhash-0.1.7/lib/blurhash.rb:9: [BUG] Segmentation fault at 0x00007f827fafd000? There's an issue on the Mastodon repo about a similar bug, but it's claimed to be fixed. One remedy is to comment out Environment="LD_PRELOAD=libjemalloc.so" in the systemd service files for mastodon-web and mastodon-streaming or add Environment="LD_PRELOAD=" to the override files, but that leads to increased memory usage.