dagargo/overwitch

packaging problem (archlinux)

tgirod opened this issue · 10 comments

I'm trying to package overwitch for archlinux, but I'm facing an issue. For reference, this is the PKGBUILD. The important part is the package function.

# Maintainer: Thomas Girod <tgirod@altu.fr>
pkgname=overwitch
pkgver=0.2
pkgrel=1
epoch=
pkgdesc="JACK client for Overbridge devices"
arch=('x86_64')
url="https://github.com/dagargo/overwitch"
#https://github.com/dagargo/overwitch/archive/refs/tags/0.2.tar.gz
license=('GPL')
groups=()
depends=('libusb' 'jack2' 'libsamplerate')
makedepends=('make' 'autoconf')
checkdepends=()
optdepends=()
provides=()
conflicts=()
replaces=()
backup=()
options=()
install=
changelog=
source=("https://github.com/dagargo/$pkgname/archive/refs/tags/$pkgver.tar.gz")
noextract=()
sha256sums=('51a50dac7c5ab4ff6fe0966144bbf9fd6f024130ecae59d7fa8f5b69d7531e5d')
validpgpkeys=()

prepare() {
	cd "$pkgname-$pkgver"
}

build() {
	cd "$pkgname-$pkgver"
	autoreconf --install
	./configure --prefix=/usr
	make
}

check() {
	cd "$pkgname-$pkgver"
}

package() {
	cd "$pkgname-$pkgver"
	make DESTDIR="$pkgdir/" install
}

When I run makepkg the build fails at the make install step with this error log:

Making install in src
make[1]: Entering directory '/home/tom/Build/overwitch/src/overwitch-0.2/src'
make[2]: Entering directory '/home/tom/Build/overwitch/src/overwitch-0.2/src'
 /usr/bin/mkdir -p '/home/tom/Build/overwitch/pkg/overwitch//usr/bin'
  /bin/sh ../libtool   --mode=install /usr/bin/install -c overwitch '/home/tom/Build/overwitch/pkg/overwitch//usr/bin'
libtool: install: /usr/bin/install -c overwitch /home/tom/Build/overwitch/pkg/overwitch//usr/bin/overwitch
make[2]: Nothing to be done for 'install-data-am'.
make[2]: Leaving directory '/home/tom/Build/overwitch/src/overwitch-0.2/src'
make[1]: Leaving directory '/home/tom/Build/overwitch/src/overwitch-0.2/src'
Making install in udev
make[1]: Entering directory '/home/tom/Build/overwitch/src/overwitch-0.2/udev'
make[2]: Entering directory '/home/tom/Build/overwitch/src/overwitch-0.2/udev'
make[2]: Nothing to be done for 'install-exec-am'.
 /usr/bin/mkdir -p '/home/tom/Build/overwitch/pkg/overwitch//etc/udev/hwdb.d'
 /usr/bin/install -c -m 644 20-usb-elektron.hwdb '/home/tom/Build/overwitch/pkg/overwitch//etc/udev/hwdb.d'
 /usr/bin/mkdir -p '/home/tom/Build/overwitch/pkg/overwitch//etc/udev/rules.d'
 /usr/bin/install -c -m 644 20-usb-elektron.rules '/home/tom/Build/overwitch/pkg/overwitch//etc/udev/rules.d'
make  install-data-hook
make[3]: Entering directory '/home/tom/Build/overwitch/src/overwitch-0.2/udev'
Failed to send reload request: Permission denied
make[3]: *** [Makefile:538: update-udev] Error 1
make[3]: Leaving directory '/home/tom/Build/overwitch/src/overwitch-0.2/udev'
make[2]: *** [Makefile:468: install-data-am] Error 2
make[2]: Leaving directory '/home/tom/Build/overwitch/src/overwitch-0.2/udev'
make[1]: *** [Makefile:422: install-am] Error 2
make[1]: Leaving directory '/home/tom/Build/overwitch/src/overwitch-0.2/udev'
make: *** [Makefile:406: install-recursive] Error 1

Apparently the make install step tries to access the udev daemon to inject new rules for overbridge capable devices. The problem is, when running inside a chroot to build a package, the build process does not have access to the system (outside of the packager, the program compiles and runs just fine).

If I understand correctly, overwitch's makefile should only copy the udev files to /usr/lib/udev/rules.d, and inform the user that udev rules has to be reloaded, or leaving that task to the package manager.

dvzrv commented

@dagargo thaf functionality should indeed not be part of the install target.

However, it could easily be exposed as its own target and added to the install instrunctions (with a note, that this is not required for systems packaging):

update-udev:
@udevadm control --reload
@udevadm trigger
@systemd-hwdb update

Thanks a lot. Probably did something wrong there.

I'll take a look at it during the weekend.

@dvzrv thanks for pointing in the right direction!

Also, udev rules are stored in /etc/udev:

udevrulesdir = /etc/udev/rules.d
udevhwdbdir = /etc/udev/hwdb.d

Should it be stored in /usr/lib/udev instead? Looking at my system, a lot of packages are storing hardware descriptions here.

I've been investigating the proper way to fix this; it's not quite clear to me.

  • As noted by @dvzrv, the update-udev target has been renamed and moved to the root Makefile.am.
  • OTOH, following @tgirod advice, udevrulesdir and udevrulesdir now use pkg-config to get the system udevdirectory.

One caveat is that make uninstall does not delete either the rules or the hwdb definition. I'm not sure if this is right.

In the end, none of these things should be inside Overwitch as the OS should provide this but we'll need to deal with this for now.

Please check the code in the build_fixes branch and let me know what you think.

I ended up discarding the branch build_fixes as it was not addressing the issue at all.

Now, udev rules might be installed from its directory but their installation is outside the install target. See 3a71a8d.

Let me know if this works for you.

I haven't tried the software yet, but at least it compiles!

EDIT: I mean I can package it, of course

I will release the PKGBUILD on AUR as soon the fix is shipped with a tagged release.

Thanks for working on this. Love it!

FYI, my plan is to release version 0.3 in the following couple of weeks once #25 and #28 are solved.

FYI, I've just published my package here: https://aur.archlinux.org/packages/overwitch-git - I will replace it with a regular "overwitch" package with the next release.

I also did a stress test with Digitakt + Digitone + PipeWire + 16 tracks record in Reaper, and it worked like a charm ❤️

Thanks a lot for the hard work, I'll finally be able to do proper recordings of my tracks !

You're welcome.

FYI, I've just published my package here: https://aur.archlinux.org/packages/overwitch-git - I will replace it with a regular "overwitch" package with the next release.

Love it. Thanks for packaging it. 👍

I also did a stress test with Digitakt + Digitone + PipeWire + 16 tracks record in Reaper, and it worked like a charm heart

We needed to test it over PipeWire so this is great news. Thanks!