* Package name : domoticz Version : 3.8153 Upstream Author : https://github.com/domoticz/domoticz/graphs/contributors * URL : http://www.domoticz.com/ * License : GPLv3 Programming Lang: C, C++, JavaScript Description : Home automation system Domoticz is a Home Automation System that lets you monitor and configure various devices like: Lights, Switches, various sensors/meters like Temperature, Rain, Wind, UV, Electra, Gas, Water and much more. Notifications/Alerts can be sent to any mobile device. The package will be maintained at https://salsa.debian.org/debian/domoticz It might be used in FreedomBox as there are no other home automation packages currently in Debian. Co-maintainers are welcome.
Dear Federico, great. Others have tried before you, you may find the state of the previous attemps on alioth in /git/debian-iot/domoticz.git/, in case that helps. Feel free to not use it, though. The debian-iot team (debian-iot-maintainers alioth list) should be interested in co-maintaining. Regards, Thibaut. Le 18/05/2018 à 20:33, Federico Ceratto a écrit :
Hello Federico Ceratto, [...] [...] Thanks for packaging domoticz. I've not used it myself but I hear good things about it and think it'll be a great addition to the debian archive. I had a quick look at the packaging bits in your git repo and have some questions and comments. Maybe something can be useful for you, but maybe not. Anyway... I see you're using alot of the security features in your service file, great! I wish more packages where better at using these features. I can't help but wonder though if it's not possible for you to use DynamicUser=yes ? You seem to already use some of the strict limitations implied by DynamicUser=yes anyway. Using it would allow you to get away without creating a static system user for your service, but your service also won't be able to create any persistent files (which I don't know if you might need). You also added a 'default' file. Personally I think the only good usage for a default file is with init scripts. Unless I missed something you seem to not have any init script so I don't think that argument applies here. Thus I'd suggest you switch from EnvironmentFile to plainly setting the variables via Environment=. That way users can easily ports via 'systemctl edit ...' the same way they would override any other thing in the service. (Fwiw, I think splitting out the port numbers to an environment variable like you did can be useful even when not using a default file. If the ExecStart line is long and has many different arguments overriding the entire line completely for just a simple port change might be suboptimal for upgrades where you might add, remove or change another unrelated command line argument. Thus being able to just override the environment variable is safer.) Not really willing to take on any (co-)maintainership, but if there's a limited task you think I can help out with don't be shy to ask. (Ofcourse since I'm not a user myself, yet, I'll need help from someone who is to test whatever I implement though.....) Regards, Andreas Henriksson PS. You already seem to be very well versed with systemd services but in case you're not already familiar with DynamicUser=yes information about it can be found, except from the systemd documentation ofcourse, at http://0pointer.net/blog/dynamic-users-with-systemd.html
Dear Federico, I've had some success building domoticz on buster using your git repository with some modifications (see attached patch): - in order to use Z-Wave hardware, add libopenzwave1.5-dev as a build-dependency, provide a dummy libopenzwave.pc file and set PKG_CONFIG_PATH to find it. Ideally one would prefer the libopenzwave package to provide this file. - in order to have dzVents to work at all, change ExecStart path from /usr/sbin to /usr/lib/domoticz. - Change dependency from liblua5.2 (which does not seem to exist in the archive?) to liblua5.2-1. Further experiments not included in patch: In order to get persistence working in dzVents, I actually had to copy all of /usr/lib/domoticz/scripts to /var/lib/domoticz/scripts and add -userdata /var/lib/domoticz/ to ExecStart. I think this removes the need to change the executable path, but it would need some care to be done properly in the package. Strangely, this build of domoticz advertises itself as Version: 3.2112 in http://localhost:8080/#/About, not 3.8153. dzVents is outdated in it and some of the scripts I've been running for months on a community-provided build of 3.8153 on a Synology NAS don't work with this version. Kind regards, Thibaut.
Le 07/06/2018 à 19:03, Thibaut Paumard a écrit : Dear Federico, It turns out that the version string is determined at build-time based on the git history. We should patch the build system to advertise the revision number we think we are packaging (see getgit.cmake). Turns out I'm actually running a build of the development branch, precisely because I wanted a more advanced version of dzVents. Kind regards, Thibaut.
Has anybody tried to build the package for Raspbian on the Raspberry Pi already? Are all the dependencies already available there?
The binary appears to be compiled with the relative path "plugins/" for plugins The working directory is /usr/sbin and it creates an empty directory /usr/sbin/plugins at startup It doesn't use /usr/lib/domoticz/plugins so it doesn't discover any plugins installed there. As a workround, I created a symlink before starting the process, ln -s /usr/lib/domoticz/plugins /usr/sbin/plugins but that is only a hack
There is a popup in the web interface announcing new upstream versions, the text is "A new version of Domoticz is Available!" This should probably be disabled for the package, as updates are managed through Debian. Is there a config option to disable the update check or does it require a patch? From a privacy perspective it is also not a good idea for a package to make un-necessary connections to upstream Regards, Daniel
Here are the steps I followed to build Domoticz for Raspbian stretch using a Debian workstation Trying to compile on the Raspberry Pi fails due to insufficient RAM. The workstation has more RAM and cores for a much faster compile. sudo apt install sbuild ubuntu-dev-tools qemu-user-static binfmt-support aufs-dkms If the aufs-dkms module fails to build with dkms, obtain it from Git. For example, if running a backports kernel 4.17: mkdir -p ~/ws/aufs && cd ~/ws/aufs git clone https://salsa.debian.org/janluca-guest/aufs-debian git checkout debian/4.17+20180827-1 dpkg-buildpackage -rfakeroot -i.git -j24 -b --no-sign sudo dpkg -i ../aufs-dkms_4.17+20180827-1_amd64.deb Now the tools are ready: mk-sbuild --arch=armhf --debootstrap-no-check-gpg --debootstrap-mirror=http://archive.raspbian.org/raspbian stretch su - $USER mk-sbuild --arch=armhf --debootstrap-no-check-gpg --debootstrap-mirror=http://archive.raspbian.org/raspbian stretch mkdir -p ~/ws/domoticz cd ~/ws/domoticz wget https://archive.raspbian.org/raspbian.public.key wget https://github.com/domoticz/domoticz/archive/4.9700.tar.gz ln -s 4.9700.tar.gz domoticz_4.9700.orig.tar.gz git clone https://gitlab.com/dpocock/domoticz-debian-raspbian/ cd domoticz-debian-raspbian git checkout debian/backports/stretch sbuild -A -d stretch-armhf --host=armhf --build=armhf --extra-repository-key=`readlink -f ../raspbian.public.key` --no-apt-update --no-apt-distupgrade -j24 . To install the package on the Pi: scp ../domoticz_4.9700-1_armhf.deb raspberrypi:/root ssh pi@raspberrypi sudo dpkg -i /root/domoticz_4.9700-1_armhf.deb To install the Zigate plugin on the Pi: sudo rm /usr/sbin/plugins sudo ln -s /usr/lib/domoticz/plugins /usr/sbin/plugins (Bug workaround, or use the patch mentioned above) cd /usr/lib/domoticz/plugins git clone https://github.com/sasu-drooz/Domoticz-Zigate cd Domoticz-Zigate git checkout stable Regards, Daniel
On another installation today, couldn't find the Zigate (Python-based) plugin in the Add Hardware pulldown I looked at /var/log/daemon.log domoticz[55195]: Status: EventSystem - Python: Failed dynamic library load, install the latest libpython3.x library that is available for your platform. Resolved by $ sudo apt install libpython3-dev which installed libpython3.5-dev. A -dev package probably shouldn't be a runtime dependency though, is it needed for plugins, or can this be satisfied in another way?
For the Zigate and maybe some other devices, the domoticz user needs to be added to the group dialout Should the postinst script for the relevant plugins do this, or should it be done by domoticz.postinst?