Arch Linux User Repository

Hi, I am having this error while building package

@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?

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.

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

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

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

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

@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 ;-)

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.

Thanks @Nocifier. Downgrading libmp4v2 to 4.1.3 and then clean building ZoneMinder fixed it. I am greatly appreciative of your work and I thank you for what you do.

I run Proxmox with various VM/containers and I could only imagine the frustration of those without an easy backup/restore solution. Many of my VMs are Arch based which I prefer because of the control over them. However ZM has been a PITA on Arch for a long time. Thank you for being very tentative of this package!

Updated package to 1.34.24, tried to test build, got the MP4 errors previously reported by @zazenhei, downgraded libmp4v2, got the same errors, decided to not bother and uploaded the new version anyway.

If anyone has found a solution for these errors (as I said, downgrading libmp4v2 didn't work for me) I'd be grateful if they'd post it here, otherwise I'll just bear with it until 1.35 hopefully resolves the issue(s). Well, at least this release should be compatible with PHP 8 according to the changelog.

EDIT: Actually scratch that, turns out that downgrading libmp4v2 to 4.1.3 does fix the issue, it's just that I had to clean my working environment after having already tried to build with 4.1.4. So yeah, downgrading works.