Arch Linux User Repository

Since version v1.7.0 the Qt5 backend is no longer actively maintained and supported.

Control environment variable can be used to force build against qt5

• ENABLE_QT5=1 to build against qt5 (default:off)

Usage cases:

• makepkg ENABLE_QT5=1
• yay -S openboard --mflags="ENABLE_QT5=1"

Yay users warning:

If you want to build against qt5, you have to call pacman -S qt5-{base,declarative,multimedia,tools,svg,webchannel,webengine} beforehand.

@unphysicalix: That's correct, you have to rebuild after dependency packages are updated. Let me make this post sticky to avoid people running into this again and again.

If OpenBoard stops working and when starting it from the command line you get an error message of the type:

openboard: error while loading shared libraries: *.so.1.1: cannot open shared object 

Then you most likely just need to rebuild OpenBoard (either with makepkg or with your favourite AUR helper) because a dependency package has been updated.

(That's the one disadvantage of AUR packages. I don't know what the threshold is for the package to be migrated into the community repository instead.)

The compile error is a known issue in OpenBoard: https://github.com/OpenBoard-org/OpenBoard/issues/958.

A fix is in the works. Update: Fix is merged upstream and backported.

I get the same error as @kbk. I tried adding -DCMAKE_CXX_FLAGS="-std=c++20", I even tried compiling with clang using -DCMAKE_CXX_COMPILER=clang++ but none of that helped.

facing this error

[ 19%] Building CXX object CMakeFiles/openboard.dir/openboard_autogen/mocs_compilation.cpp.o
In file included from /usr/include/poppler/Object.h:44,
                 from /home/kbk/.cache/yay/openboard/src/build/openboard_autogen/QM7XBKFLFB/../../../OpenBoard-1.7.1/src/pdf/XPDFRenderer.h:41,
                 from /home/kbk/.cache/yay/openboard/src/build/openboard_autogen/QM7XBKFLFB/moc_XPDFRenderer.cpp:9,
                 from /home/kbk/.cache/yay/openboard/src/build/openboard_autogen/mocs_compilation.cpp:108:
/usr/include/poppler/goo/GooString.h:241:24: error: ‘starts_with’ has not been declared in ‘std::string’
  241 |     using std::string::starts_with;
      |                        ^~~~~~~~~~~
/usr/include/poppler/goo/GooString.h:244:24: error: ‘ends_with’ has not been declared in ‘std::string’
  244 |     using std::string::ends_with;
      |                        ^~~~~~~~~
make[2]: *** [CMakeFiles/openboard.dir/build.make:626: CMakeFiles/openboard.dir/openboard_autogen/mocs_compilation.cpp.o] Error 1
make[1]: *** [CMakeFiles/Makefile2:430: CMakeFiles/openboard.dir/all] Error 2
make: *** [Makefile:156: all] Error 2
==> ERROR: A failure occurred in build().
    Aborting...
 -> error making: openboard-exit status 4
 -> Failed to install the following packages. Manual intervention is required:
openboard - exit status 4

OpenBoard 1.7.1 introduces the cmake-based community build which is more closely aligned to Arch principles and broader Linux conventions (FHS in particular). As it is, it makes the build process much simpler. No breakage is expected (indeed it should be more robust).

I would have waited until 1.7.1 since the cmake community build needs changes anyway and better supports building with both Qt versions, but I don't object to this change. I'll note that upstream still supports Qt 5.15, to avoid confusion.

Since version v1.7.0 the Qt5 backend is no longer actively maintained and supported.

Control environment variable can be used to force build against qt5

• ENABLE_QT5=1 to build against qt5 (default:off)

Usage cases:

• makepkg ENABLE_QT5=1
• yay -S openboard --mflags="ENABLE_QT5=1"

Yay users warning:

If you want to build against qt5, you have to call pacman -S qt5-{base,declarative,multimedia,tools,svg,webchannel,webengine} beforehand.

I just built and Installed openbaord with qt6 and it seems to work fine. No error so far.

I modified just one line in PKGBUILD:

depends=('qt6-base' 'qt6-multimedia' 'qt6-svg' 'qt6-webchannel' 'qt6-webengine' 'qt6-positioning' 'qt6-multimedia' 'libpaper' 'bzip2' 'openssl' 'libfdk-aac' 'sdl' 'ffmpeg')

then makepkg -si.

I think it's OK if you stay as maintainer. I don't think the AUR makes a distinction between maintainer and co-maintainer in any packaging related matter.
As you say, you can always chime in if you find something noteworthy or help is requested. Also bus factor and stuff.

Overall, the current structure is good by me. If and when you decide to step down for one reason or another, I'm sure we can deal with it at that time.

Thanks for the privileges I now enjoy to continue OpenBoard on Arch.

Dear @Vekhir, sorry about the delay! I've added you as co-maintainer for now. In case you want to take over completely alone I'm also happy to step down as maintainer (but I guess you should already now have all permissions?).

It sounds great that you can contribute with your upstream expertise, and I'll then just linger in the background (if you want) in case something comes up that I can help with, ok?

@fsiegert Thanks for the offer! I am already working with the upstream devs to improve both OpenBoard in general, as well as Arch issues specifically. One notable improvement I was involved with and ensured proper Arch support for is the upcoming option to use the CMake build system. In the AUR, I maintain a few packages, which gave me experience with packaging for the AUR specifically and resolving issues users were encountering. I'd gladly help to maintain openboard if you decide to make me a co-maintainer.