Added Fedora patch to fix compilation.
Added python3 dependency as it seems it's needed now.
Replaced custom boost 1.73 patch with upstream one. Removed CFLAG that
was supposed to fix this but didn't do anything.
Removed nls.mk. telldus-core was fixed to not require iconv.
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Drop upstreamed patches.
The file appversion.default was removed from Domoticz, causing the hacks
to inject APPVERSION, APPDATE and APPHASH to fail. As the appversion.h
is generated during compile time, implementing a new way to inject these
defines is non-trivial, so simply drop them.
As the minor version for this release is no longer based on the number
of commits, the package versioning needs to be revised if we want to
build a git snapshot instead of stable release. Leave this for another
day and drop that logic for now.
Signed-off-by: Stijn Tintel <stijn@linux-ipv6.be>
The files in ozwcp/ shouldn't be compressed as there's no gzip handling
for those.
Also enable Python support — since it can dynamically link with
libpython optionally, it's harmless to enable it. Those who want Python
plugins can use it. I still want lua-based hardware plugins though.
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Upstream has merged a simplified version of the FHS patch, with a few
changes...
Scripts are actually configuration. There are examples, but the point is
that you write your own.
So they should live in the data directory (e.g. /var/lib/domoticz) not
in /usr/share/domoticz. The only exception is the dzVents runtime.
So.... the upstream patch handles the dzVents runtime bit. Drop the part
of our patch which added -scripts, because it can just be based in the
userdata directory and we don't need to change that.
Ship the default scripts/ directory in /etc/domoticz/scripts, and on
startup make a *symlink* to it from /var/lib/domoticz/scripts.
Symlink from /etc/domoticz/scripts/dzVents{data,generated_scripts} to
temporary directories under /var/lib/domoticz/dzVents so that those
directories (which are written to by Domoticz) don't land on the root
file system. Anyone with a writeable file system who *wants* the data/
directory to be persistent, can change that. Just as they can change
the userdata config option to point to a real file system somewhere.
Also drop the renaming of the OpenZWave Config/ directory. It's purely
cosmetric so there's no need for us to carry that change. It can go
upstream first, if it really offends anyone.
Drop the patches which are now merged upstream, and turn off the newly
added USE_OPENSSL_STATIC. Add -noupdates to the command line.
Finally, gzip the static www files to save space. In the common case,
clients will use "Accept-Encodiong: gzip" and Domoticz will serve them
as-is. It can also decompress on the fly if it really has to, but now we
aren't asking it to *compress* on the fly, which is probably a losing
proposition on an OpenWRT box.
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Domoticz 3.8153 introduced support for dzVents. Unfortunately this was
broken by the 902_add-scripts-path, which attempts to make Domoticz more
FHS-compliant instead of throwing everything under /opt/domoticz.
The problem is that dzVents scripts added via the webinterface will be
generated on the filesystem. With the 902_add-scripts-path patch,
Domoticz tried to write this to "scriptsdir/dzVents/generated_scripts".
As the scriptsdir contains scripts that come with upstream, and are not
meant to be changed, this defaults to /usr/share/domoticz/scripts, which
is not writeable, so Domoticz is unable to write the script to the
filesystem. What is worse is that this silently fails.
Fix this by moving the generated_scripts dir to
"userdatadir/generated_scripts". The userdatadir defaults to
/var/lib/domoticz, which is writeable.
Additionally, since this patch does more than just adding the scripts
path, rename it to something more appropriate.
Signed-off-by: Stijn Tintel <stijn@linux-ipv6.be>