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>
Summary:
This package fails to compile with boost 1.70 when the boost cmake
config gets used.
As far as I can tell, Boost 1.70 introduced
BoostConfigVersion.cmake. In that file, the value of PACKAGE_VERSION is
set to 1.70. This makes CMake auto set the variable Boost_VERSION to
1.70. Historically, Boost_VERSION has been using the format like 170000,
and not 1.70. Some package cmake files still depend on this behavior
and make assertions such as Boost_VERSION > 168000. This is incompatible
with the new scheme.
Test Plan:
`make package/domoticz/compile`
Also compiled all other packages that have a boost dependency, they seem
to be working fine.
tested on nbg6817
Signed-off-by: Amol Bhave <ambhave@fb.com>
[split unrelated change, change commit subject, alphabetical order]
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>
This makes quite a significant difference to the executable size:
text data bss dec hex filename
7921421 87804 31692 8040917 7ab1d5 domoticz
5862321 86180 31212 5979713 5b3e41 domoticz-lto
As an added bonus, it still seems to work.
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
When cross-compiling Domoticz on a system without GPIO, the WITH_GPIO
flag is not set by cmake, and GPIO support is disabled as a result.
Enabling GPIO support by adding the flag to TARGET_CXXFLAGS.
Signed-off-by: Stijn Tintel <stijn@linux-ipv6.be>
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>
Rosen Penev
Stijn Tintel
Amol Bhave
David Woodhouse