Arch Linux User Repository

Funami, thank you for your effort! Now it compiles, launches and works successfully.

Thank you for your investigation, visad! This should now be fixed by using ffmpeg7.1 from the AUR.

Build fails with this error:

[11/425] Compiling C++ object subprojects/bestsource/libbestsource.a.p/src_audiosource.cpp.o
FAILED: subprojects/bestsource/libbestsource.a.p/src_audiosource.cpp.o
c++ -Isubprojects/bestsource/libbestsource.a.p -Isubprojects/bestsource -I../subprojects/bestsource -flto=auto -fdiagnostics-color=always -DNDEBUG -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -std=c++17 -O3 -fPIC -MD -MQ subprojects/bestsource/libbestsource.a.p/src_audiosource.cpp.o -MF subprojects/bestsource/libbestsource.a.p/src_audiosource.cpp.o.d -o subprojects/bestsource/libbestsource.a.p/src_audiosource.cpp.o -c ../subprojects/bestsource/src/audiosource.cpp
../subprojects/bestsource/src/audiosource.cpp: In member function «void LWAudioDecoder::OpenFile(const std::filesystem::__cxx11::path&, int, bool, int, const std::map<std::__cxx11::basic_string<char>, std::__cxx11::basic_string<char> >&, double)»:
../subprojects/bestsource/src/audiosource.cpp:140:32: error: «AV_CODEC_FLAG_DROPCHANGED» was not declared in this scope; did you mean «AV_CODEC_FLAG_UNALIGNED»?
  140 |         CodecContext->flags |= AV_CODEC_FLAG_DROPCHANGED;
      |                                ^~~~~~~~~~~~~~~~~~~~~~~~~
      |                                AV_CODEC_FLAG_UNALIGNED

Let's break down the problem:

1. Looks like your PKGBUILD uses system-wide ffmpeg, which is 8.0 for now;

2. arch1t3cht pinned bestsource (dep) to R8;

3. Bestsource removed the reliance on AV_CODEC_FLAG_UNALIGNED only in this commit (ofc it's newer than pinned R8);

4. FFmpeg removed AV_CODEC_FLAG_UNALIGNED after its deprecation in this commit: it is present in 7.1, but already absent in 8.0.

In fact, arch1t3cht's Aegisub pins ffmpeg to another "meson-compatible" fork, which is 7.1 and thus still contains the needed define. Maybe you should use this too instead of system-wide ffmpeg?

As for the temporary workaround older system-wide ffmpeg could be fine too.

@Jaska it's meson bug, which is fixed in meson-git. You have 2 options, use meson-git or downgrade meson to 1.7.2 https://github.com/arch1t3cht/Aegisub/commit/acd6b161869053ece2969a093f102874d2a3b04c

https://github.com/mesonbuild/meson/issues/14530

The build fails with:

Traceback (most recent call last):
  File "/usr/lib/python3.13/site-packages/mesonbuild/mesonmain.py", line 193, in run
    return options.run_func(options)
           ~~~~~~~~~~~~~~~~^^^^^^^^^
  File "/usr/lib/python3.13/site-packages/mesonbuild/msetup.py", line 391, in run
    app.generate()
    ~~~~~~~~~~~~^^
  File "/usr/lib/python3.13/site-packages/mesonbuild/msetup.py", line 189, in generate
    return self._generate(env, capture, vslite_ctx)
           ~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.13/site-packages/mesonbuild/msetup.py", line 250, in _generate
    intr.run()
    ~~~~~~~~^^
  File "/usr/lib/python3.13/site-packages/mesonbuild/interpreter/interpreter.py", line 3044, in run
    super().run()
    ~~~~~~~~~~~^^
  File "/usr/lib/python3.13/site-packages/mesonbuild/interpreterbase/interpreterbase.py", line 178, in run
    self.evaluate_codeblock(self.ast, start=1)
    ~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.13/site-packages/mesonbuild/interpreterbase/interpreterbase.py", line 203, in evaluate_codeblock
    raise e
  File "/usr/lib/python3.13/site-packages/mesonbuild/interpreterbase/interpreterbase.py", line 195, in evaluate_codeblock
    self.evaluate_statement(cur)
    ~~~~~~~~~~~~~~~~~~~~~~~^^^^^
  File "/usr/lib/python3.13/site-packages/mesonbuild/interpreterbase/interpreterbase.py", line 227, in evaluate_statement
    return self.evaluate_if(cur)
           ~~~~~~~~~~~~~~~~^^^^^
  File "/usr/lib/python3.13/site-packages/mesonbuild/interpreterbase/interpreterbase.py", line 317, in evaluate_if
    self.evaluate_codeblock(i.block)
    ~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^
  File "/usr/lib/python3.13/site-packages/mesonbuild/interpreterbase/interpreterbase.py", line 203, in evaluate_codeblock
    raise e
  File "/usr/lib/python3.13/site-packages/mesonbuild/interpreterbase/interpreterbase.py", line 195, in evaluate_codeblock
    self.evaluate_statement(cur)
    ~~~~~~~~~~~~~~~~~~~~~~~^^^^^
  File "/usr/lib/python3.13/site-packages/mesonbuild/interpreterbase/interpreterbase.py", line 211, in evaluate_statement
    self.evaluate_plusassign(cur)
    ~~~~~~~~~~~~~~~~~~~~~~~~^^^^^
  File "/usr/lib/python3.13/site-packages/mesonbuild/interpreterbase/interpreterbase.py", line 496, in evaluate_plusassign
    addition = self.evaluate_statement(node.value)
  File "/usr/lib/python3.13/site-packages/mesonbuild/interpreterbase/interpreterbase.py", line 215, in evaluate_statement
    return self.method_call(cur)
           ~~~~~~~~~~~~~~~~^^^^^
  File "/usr/lib/python3.13/site-packages/mesonbuild/interpreterbase/interpreterbase.py", line 565, in method_call
    res = obj.method_call(method_name, args, kwargs)
  File "/usr/lib/python3.13/site-packages/mesonbuild/interpreter/interpreterobjects.py", line 890, in method_call
    ret = method(state, args, kwargs)
  File "/usr/lib/python3.13/site-packages/mesonbuild/interpreterbase/decorators.py", line 62, in wrapped
    return f(*wrapped_args, **wrapped_kwargs)
  File "/usr/lib/python3.13/site-packages/mesonbuild/interpreterbase/decorators.py", line 237, in wrapper
    return f(*nargs, **wrapped_kwargs)
  File "/usr/lib/python3.13/site-packages/mesonbuild/modules/cmake.py", line 160, in include_directories
    assert isinstance(inc, build.IncludeDirs), 'for mypy'
           ~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^
AssertionError: for mypy

meson.build:277:20: ERROR: Unhandled python exception

    This is a Meson bug and should be reported!
==> VIRHE: Virhe tapahtui funktiossa prepare().
    Peruutetaan...

@FichteFoll: The submodule issue should now be fixed.

Since the system-provided bestsource is supported now, should this package instead depend on vapoursynth-plugin-bestsource?

No, aegisub-arch1t3cht does not support bestsource R10 right now, i.e. it won't build. But in theory it would be possible I think, but we would have to set PKG_CONFIG_PATH during meson setup as the official package uses a custom location.

The way the submodule setup is done prevents re-using the same source folder because the libp2p symlink is written inside the bestsource git clone. I have to manually remove the libp2p symlink after each build.

==> Extracting sources...
  -> Creating working copy of aegisub-arch1t3cht-git git repo...
Reset branch 'makepkg'
  -> Creating working copy of aegisub-arch1t3cht-git-bestsource git repo...
error: expected submodule path 'libp2p' not to be a symbolic link
==> ERROR: Failure while updating working copy of aegisub-arch1t3cht-git-bestsource git repo
    Aborting...

Since the system-provided bestsource is supported now, should this package instead depend on vapoursynth-plugin-bestsource?

The fork now supports building against system-provided bestsource. https://github.com/arch1t3cht/Aegisub/commit/490fcd929462a148467e19ffc602db0000bc9be6

Thanks for the notice, witchymary! Now fixed!

Compilation currently breaks since latest master requires bestsource R8.