Package Details: zoneminder 1.36.33-2

Git Clone URL: https://aur.archlinux.org/zoneminder.git (read-only, click to copy)
Package Base: zoneminder
Description: A full-featured, open source, state-of-the-art video surveillance software system
Upstream URL: https://www.zoneminder.com/
Keywords: camera cctv monitor record security surveillance video zoneminder
Licenses: GPL-2.0-only
Conflicts: zoneminder-git
Submitter: None
Maintainer: Nocifer
Last Packager: Nocifer
Votes: 70
Popularity: 0.25
First Submitted: 2008-03-21 00:09 (UTC)
Last Updated: 2024-02-12 12:50 (UTC)

Dependencies (46)

Sources (8)

Latest Comments

« First ‹ Previous 1 .. 4 5 6 7 8 9 10 11 12 13 14 .. 60 Next › Last »

eriol commented on 2021-05-25 13:20 (UTC)

@Nocifer deleting zm_config_defines.h worked Thank you :D

Nocifer commented on 2021-05-25 12:49 (UTC)

@eriol As far as I can tell there is a class in the C++ code called Config that is supposed to have a property font_file_location that is supposed to be populated when you compile ZM, but which for some reason seems to be missing (or is not properly populated when the object is initialized during compilation, hence is then reported as missing).

I dug through the code some and found that the missing property is supposed to be autogenerated by a perl script just before compilation and stored in a file 'zm_config_defines.h' which is located at the root of ZM's build dir (e.g. in my case it's /tmp/makepkg/zoneminder/src/zoneminder-git/zm_config_defines.h'). This file won't be regenerated if it already exists in the build folder, so TL;DR since you haven't set makepkg's build folder to something volatile like /tmp/makepkg, first thing to do would be to delete your build folder so zm_config_defines.h can be regenerated. Maybe the transition to GCC11 messed something up and this alone could fix your issue.

If this is not the case, check in the first section of zm_config_defines.h if there is a line that reads '#define ZM_FONT_FILE_LOCATION 220', maybe with a different number at the end. If there isn't such a line then for some reason the perl script is not setting up its options properly, and that would probably call for a report to ZM's upstream.

eriol commented on 2021-05-25 10:46 (UTC) (edited on 2021-05-25 10:50 (UTC) by eriol)

Hi, I am having this error while building package

$HOME/zoneminder/src/zoneminder-git/src/zm_image.cpp: In static member function ‘static void Image::Initialise()’:

$HOME/zoneminder/src/zoneminder-git/src/zm_image.cpp:575:48: error: ‘class Config’ has no member named ‘font_file_location’

575 | FontLoadError res = font.LoadFontFile(config.font_file_location);

|

^~~~~~~~~~~~~~~~~~ In file included from $HOME/zoneminder/src/zoneminder-git/src/zm_image.h:25,

from $HOME/zoneminder/src/zoneminder-git/src/zm_image.cpp:20:

$HOME/zoneminder/src/zoneminder-git/src/zm_image.cpp:577:47: error: ‘class Config’ has no member named ‘font_file_location’

577 | Panic("Invalid font location: %s", config.font_file_location);

|

^~~~~~~~~~~~~~~~~~ $HOME/zoneminder/src/zoneminder-git/src/zm_logger.h:200:72: note: in definition of macro ‘logPrintf’

200 | er::fetch()->logPrint(false, FILE, LINE, logLevel, ##params); \ |

^~~~~~

$HOME/zoneminder/src/zoneminder-git/src/zm_image.cpp:577:5: note: in expansion of macro ‘Panic’

577 | Panic("Invalid font location: %s", config.font_file_location);

| ^~~~~

make[2]: [src/CMakeFiles/zm.dir/build.make:370: src/CMakeFiles/zm.dir/zm_image.cpp.o] Errore 1

make[1]:
[CMakeFiles/Makefile2:484: src/CMakeFiles/zm.dir/all] Errore 2 make: *** [Makefile:156: all] Errore 2

==> ERRORE: Si è verificato un errore in build().

L'operazione sta per essere interrotta...

What am I missing?

Nocifer commented on 2021-05-20 10:18 (UTC)

@sanerb Hmm, that's the first I've heard about this. If it's true, it would mean that this missing dependency has gone unnoticed for more than 2 years, and in the meantime no one else has attempted to use ONVIF (or the error would have probably been already reported).

On the other hand, I can't find any mention of a libxml dependency in ZM's list of requirements. Also, there is already perl-xml-parser which is supposed to act as the XML parser for ONVIF (fun fact, I can't find any mention of perl-xml-parser as a requirement either, but I'm 100% sure I didn't put it in the PKGBUILD by accident).

I don't have an ONVIF camera at hand in order to test it myself, and it could be some time before I do, so could you please post the error you're getting? Also, is there anyone else out there with an ONVIF camera who'd be willing to test this for us?

sanerb commented on 2021-05-19 19:54 (UTC)

include perl-xml-libxml as a dependency, possibly optional - i don't know what else is broken if anything, but ONVIF will not work without it.

Nocifer commented on 2021-05-18 21:09 (UTC) (edited on 2021-05-18 22:00 (UTC) by Nocifer)

It seems Zoneminder is incompatible with GCC11 for the time being.

EDIT: Uploaded new release that includes a commit which fixes the issue.

billyburly commented on 2021-05-18 20:21 (UTC)

Doesn't compile

In file included from /home/durrw/zoneminder/src/zoneminder-git/src/zm_image.cpp:24:
/home/durrw/zoneminder/src/zoneminder-git/src/zm_utils.h: In instantiation of ‘constexpr const T& ZM::clamp(const T&, const T&, const T&) [with T = unsigned int]’:
/home/durrw/zoneminder/src/zoneminder-git/src/zm_image.cpp:2034:24:   required from here
/home/durrw/zoneminder/src/zoneminder-git/src/zm_utils.h:99:15: error: call of overloaded ‘clamp(const unsigned int&, const unsigned int&, const unsigned int&, std::less<unsigned int>)’ is ambiguous
   99 |   return clamp(v, lo, hi, std::less<T>{});
      |          ~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/durrw/zoneminder/src/zoneminder-git/src/zm_utils.h:93:20: note: candidate: ‘constexpr const T& ZM::clamp(const T&, const T&, const T&, Compare) [with T = unsigned int; Compare = std::less<unsigned int>]’
   93 | constexpr const T &clamp(const T &v, const T &lo, const T &hi, Compare comp) {
      |                    ^~~~~
In file included from /usr/include/c++/11.1.0/algorithm:62,
                 from /home/durrw/zoneminder/src/zoneminder-git/dep/span-lite/include/span.hpp:225,
                 from /home/durrw/zoneminder/src/zoneminder-git/src/zm_font.h:24,
                 from /home/durrw/zoneminder/src/zoneminder-git/src/zm_image.cpp:22:
/usr/include/c++/11.1.0/bits/stl_algo.h:3674:5: note: candidate: ‘constexpr const _Tp& std::clamp(const _Tp&, const _Tp&, const _Tp&, _Compare) [with _Tp = unsigned int; _Compare = std::less<unsigned int>]’
 3674 |     clamp(const _Tp& __val, const _Tp& __lo, const _Tp& __hi, _Compare __comp)
      |     ^~~~~
Manifying 23 pod documents
Manifying 24 pod documents
make[2]: *** [src/CMakeFiles/zm.dir/build.make:398: src/CMakeFiles/zm.dir/zm_image.cpp.o] Error 1

Nocifer commented on 2021-05-14 10:14 (UTC)

Lol, talk about the perfect timing... OK folks, crisis averted, nothing to see here, move along :P

Nocifer commented on 2021-05-13 08:55 (UTC) (edited on 2021-05-13 09:14 (UTC) by Nocifer)

@baslking thanks, your proposed fix does indeed work nicely. I was about to write a reply asking you to kindly provide some more info (if you have it) on what exactly it is that has introduced this issue, and whether it's something that should be reported to the libmp4v2 Arch package maintainers, or to mp4v2's upstream, or to Zoneminder's upstream...

But then on a hunch I tried to build Zoneminder from the latest master (instead of using the outdated 1.34.xx tagged releases) and what do you know, it actually built without a hitch.

As a result, because this is just the latest in a long list of issues that in these past few months have been traced back to the 1.34.xx codebase itself, I've found an IMHO better solution: for the time being I'm switching this package to using a git(-ish) versioning scheme instead of following the 1.34.xx tagged releases. This should help, as Zoneminder as a project seems to be in a state of flux lately, and Arch is not like Debian where changes in accompanying libraries are slow to come, so using "ancient" releases will just not cut it for us.

If anyone has a better solution to propose (I can understand why this could be an upsetting change for a server acting as an NVR for security purposes) please say so. Also, if anyone finds that this change makes Zoneminder noticeably more buggy (as git-master releases are prone to be) please report it here and if there's no easy fix, I'll switch back to 1.34.xx and use the hack provided by @baslking instead. EDIT: Just realized that after the update to 1.35.xx it will probably be impossible to downgrade your setup back to 1.34.xx due to the database scheme updates, so please MAKE SURE TO BACKUP YOUR DATABASE before updating.

@DaMadOne thanks ;-)

baslking commented on 2021-05-11 21:17 (UTC) (edited on 2021-05-11 21:22 (UTC) by baslking)

For the build problem of: @zazenhei, I had the same issue. It seems there's an error in the cmake file logic that doesn't handle the /usr/include/mp4v2/mp4v2.h nested include files in the place of /usr/include/mp4v2.h You see it comment that if does not find the header files but it carries on and the compile fails when the header file is needed. Since it never asks to include the header file its normal that the compile fails. A really simple hack to force cmake to chose the right option for the include in the PKGBUILD file in the build section for cmake if you add the define: -DHAVE_MP4V2_MP4V2_H=1 \ The build continues to the end, or it did for me. I'm new to zoneminder and built on a RPI-400 with aarch64 and libpm4v2 4.1.6-1 your mileage may vary.