Arch Linux User Repository

The default config is now patched in the packaging stage to avoid the issue with the PHP DIR macro and uses a variable called "ARCH_BASE_DIR".

@carlenny thanks for letting me know about this issue. I was hoping to avoid modifying the supplied default config, but that default will have to be changed to maintained the standard behavior for webapp packages.

Thank you very much! One more issue: It's very cool and clear that /usr/share/webapps/kanboard/config.php is a symlink to /etc/webapps/kanboard/config.php. However the __DIR__ constants in /etc/webapps/kanboard/config.php resolve to /etc/webapps/kanboard. So with the default config, kanboard tries to upload files to /etc/webapps/kanboard/data instead of /usr/share/webapps/kanboard/data. Would it be a good idea to replace __DIR__ with /usr/share/webapps/kanboard in the default config?

The symlink should now be created automatically and point to the default config supplied by kanboard. The issue with the post_install function is fixed.

Is the symlink still meant to be a manual post install action? I had a look at kanboard.install, and ${pkgname} seems to be not available in post_install(), so the call to ln yields:

$ ls -l /usr/share/webapps/config.php
lrwxrwxrwx 1 root root 24 20. Sep 15:10 /usr/share/webapps/config.php -> /etc/webapps//config.php

Currently the symlink of the config is meant to be a manual post install action to prevent the service from being started without doing the initial required configuration.

Can you add these?

ln -s ${pkgdir}/etc/webapps/${pkgname}/config.php ${pkgdir}/usr/share/webapps/${pkgname}/data/config.php
chown -R http: ${pkgdir}/usr/share/webapps/${pkgname}/data

Looks like I did forget to clean the directory I was building in, the package has been updated.

I can confirm the problem warsh reported. Have you tried redownloading the source zip ?

Odd, I just tried a rebuild and it passed with the current sha256sum for kanboard 1.2.3-1 and failed with the f009051ccd496ac678f5a7532ce2dced58cebec87fe9cb5e69d5059b4ed165ae value. Since I can't reproduce the issue I'm going to leave current value in place unless more people report the same problem.