Arch Linux User Repository

For those looking for something more stable than the alpha/default branch, there's another git pkgbuild for the 2.3 branch (beta), which should be reliable enough for daily use: https://aur.archlinux.org/packages/mixxx_beta-git/

This package will automatically retrieve and build the latest development snapshot of Mixxx from git (default branch).

It does not need to be updated on every release, so please do not flag out of date unless the build breaks or any actual packaging issue.

@Gimmeapill

The proper path for system rules should anyway be /lib/udev/rules.d/, so we will need to eventually change that and disable the auto installation.

Ideally it would install the rules into /usr/lib/udev/rules.d. I opened a PR to fix that: https://github.com/mixxxdj/mixxx/pull/3458

That DCMAKE_INSTALL_PREFIX flag is quite misleading since the application installs under /usr no matter how.

Yes, my upstream PR fixes that, hopefully it gets merged soon.

I was asking about your build flags because the feature related to qt5-declarative & qt5-script doesn't seem to be activated by cmake even if the dependency is present, so maybe they could be moved to the make-depends array or just removed?

Mixxx switched from QScriptEngine (qt5-script) to QJSEngine (qt5-declarative) some time ago: https://github.com/mixxxdj/mixxx/pull/2682 JavaScript controller mapping support is not an optional feature, Mixxx won't build without it. Therefore the qt5-declarative dependency is required, and qt5-script can be removed.

@Holzhaus: Actually I'm blind, the udev path was very wrong (/usr/etc...) until the install prefix was changed back to the root FS rather than /usr. The proper path for system rules should anyway be /lib/udev/rules.d/, so we will need to eventually change that and disable the auto installation.

That DCMAKE_INSTALL_PREFIX flag is quite misleading since the application installs under /usr no matter how. Anyway, I applied the build flags you provided, the namcap output looks a bit better now.

@Holzhaus: I didn't apply the patch as I got wary of the install prefix under the root file system: -DCMAKE_INSTALL_PREFIX=/

That's why I wanted to review step by step (also to try to understand where I got it wrong).

But the build is not broken: those are namcap warnings and are expected. I don't remember Mixxx ever being 100% namcap clean (as far as the 1.7.x era at least).

For example if you want the udev rule to be installed, I don't see how you could get away with the non-standard directory warning. This would maybe cause trouble for an official package, but that's acceptable for a pkgbuild intended to followup closely on the latest developments (while requiring the minimum of maintenance).

Yet those warnings can be improved. I was asking about your build flags because the feature related to qt5-declarative & qt5-script doesn't seem to be activated by cmake even if the dependency is present, so maybe they could be moved to the make-depends array or just removed?

I would ideally prefer to have the simplest build options and just rely on the namcap output to track dependencies (for easier maintenance), but it might also make sense to hardcode all buildflags to see precisely what option are activated or not.

@Gimmeapill: Depends on what you prefer. CMake autodetects what's installed and disables/enables some features accordingly. Hardcoding the flags makes it obvious what is enabled and what isn't, and ensures that the flags don't suddenlty change because you installed or uninstalled another Mixxx dependency that is not listed in the depends array.

Unfortunately, you didn't apply the patch with git am < cmake.patch. Now the package is broken again:

$ namcap mixxx-git-r7689-1-x86_64.pkg.tar.zst
mixxx-git W: ELF file ('usr/bin/mixxx') lacks FULL RELRO, check LDFLAGS.
mixxx-git W: Directory (usr/share/mixxx/fonts) is empty
mixxx-git W: File (usr/etc/) exists in a non-standard directory.
mixxx-git W: File (usr/etc/udev/) exists in a non-standard directory.
mixxx-git W: File (usr/etc/udev/rules.d/) exists in a non-standard directory.
mixxx-git W: File (usr/etc/udev/rules.d/mixxx-usb-uaccess.rules) exists in a non-standard directory.
mixxx-git W: Unused shared library '/usr/lib/libGLX.so.0' by file ('usr/bin/mixxx')
mixxx-git W: Unused shared library '/usr/lib/libOpenGL.so.0' by file ('usr/bin/mixxx')
mixxx-git W: Unused shared library '/usr/lib/libQt5Concurrent.so.5' by file ('usr/bin/mixxx')
mixxx-git W: Unused shared library '/usr/lib/libQt5Test.so.5' by file ('usr/bin/mixxx')
mixxx-git W: Unused shared library '/usr/lib/libSM.so.6' by file ('usr/bin/mixxx')
mixxx-git W: Unused shared library '/usr/lib/libICE.so.6' by file ('usr/bin/mixxx')
mixxx-git W: Unused shared library '/usr/lib/libXext.so.6' by file ('usr/bin/mixxx')
mixxx-git W: Unused shared library '/usr/lib/libglib-2.0.so.0' by file ('usr/bin/mixxx')
mixxx-git E: Dependency qt5-declarative detected and not included (libraries ['usr/lib/libQt5Qml.so.5'] needed in files ['usr/bin/mixxx'])
mixxx-git W: Dependency included and not needed ('qt5-script')

Ok, I eventually figured out that my local repo was corrupted. pkgbuild updated. @Holzhaus: thanks again for your help. are you 100% sure of the build flags?

@Holzhaus: Thanks but I still can't get it to build in clean chroot (path error), which bugs me because the other pkgbuild works fine: https://aur.archlinux.org/packages/mixxx_beta-git/

I updated this PKGBUILD for CMake support, Apply with:

$ git clone https://aur.archlinux.org/mixxx-git.git
$ cd mixxx-git
$ curl -L -o cmake.patch https://gist.githubusercontent.com/Holzhaus/345a0f27a5840c2cd5435daea9b0e2af/raw/a56fa02842fe9599ebc544739d13d146142c91ac/0001-mixxx-git-Switch-build-to-CMake.patch
$ git am < cmake.patch

Then you can build and install with:

$ makepkg -si

@Gimmeapill: Fell free to push this to the AUR git repo.

Support for SCons build system has be dropped in favor of CMake: https://mixxx.org/news/2020-12-14-scons-cmake-migration/

Master has been renamed to main - please update the description. Maybe rather say that it builds the "default" git branch, because that is what the PKGBUILD does.

@Holzhaus: I can't update right away as I don't have my arch box around (for who knows how long...). But if you have an updated pkgbuild and want to step in, please send it and I'll add you as co-maintainer, that will be the fastest.