Package Details: zoneminder 1.36.35-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://zoneminder.com/
Keywords: camera cctv monitor record security surveillance video zoneminder
Licenses: GPL-2.0-only
Submitter: None
Maintainer: Nocifer
Last Packager: Nocifer
Votes: 73
Popularity: 0.64
First Submitted: 2008-03-21 00:09 (UTC)
Last Updated: 2025-06-05 21:26 (UTC)

Dependencies (45)

Sources (8)

Latest Comments

« First ‹ Previous 1 2 3 4 5 6 7 .. 63 Next › Last »

Nocifer commented on 2024-09-29 09:27 (UTC) (edited on 2024-09-29 12:33 (UTC) by Nocifer)

@baudneo There is no resentment on my part, just fact observation.

Has FFmpeg 7.0 been out since April? Yes.

Is ZM still incompatible with it 6 months later? Yes.

Have I and other people made multiple reports about it? Yes.

Did we get any response before @SteveGilvarry (one of ZM's contributors) kindly replied to me some 10 days ago about an oncoming 1.36.35 that will have the FFmpeg 7.0 fixes backported from 1.37? No.

Has ZM's dev been very active during all this time, pushing many commits and also replying to other reported issues? Yes.

Is the fix for FFmpeg 7.0 simple to implement, which means it shouldn't have been 6 whole months before we get it? Well, judging by the patch that @shella has made I'll have to go with "yes", although I can't know for certain how that patch would fare during runtime (ZM could prove to be buggy as hell and need more patches to actually run properly). So this should probably be a "maybe".

To me, all this simply means what I've already said: that even 6 months down the road, compatibility with FFmpeg 7.0 is not a priority.

On the other hand, should it be a priority? If you ask me, it's both yes and no. Yes, because the fix seems easy enough to implement and (if that's the case) there is no real reason to delay it for so long. No, because ZM is server software and it only really supports LTS distros and docker containers, which do not have this problem with new versions of major dependencies like FFmpeg hitting the repos before ZM is ready for them; and it is even explicitly mentioned in the README that building from source is discouraged exactly for this reason.

Personally, nowadays I would never use ZM on anything other than a docker container, let alone on a rolling distro. So for the few brave souls that still choose to build, install and run it on Arch, well, caveat emptor. But even so, it would still be nice of the dev(s) to more promptly provide compatibility fixes for such "corner" cases, if and when these fixes are simple and not too time-consuming to implement.

As to your other questions:

1) I did propose to @shella that they make a PR for their patch.

2) I've thought before about creating a zoneminder-git package, especially during these last couple of months, but I've always concluded that running a git snapshot of complex server software on top of an officially unsupported rolling distro would probably be too much. But to be honest, the real reason is that I never expected a stable 1.37 to take so long to be released, neither did I expect 1.36.33/34 to be broken for so long after FFmpeg 7.0 came out. So I think I will create zoneminder-git after all, since it wouldn't be too much work to maintain it (it would just be a modified PKGBUILD of this package) and it could be a good testbed for users to catch and report bugs to upstream as well.

P.S. Hmm, it seems my reply turned out a bit too lengthy. Oh well :P

baudneo commented on 2024-09-26 14:48 (UTC)

@Nocifer

Zm Dev (singular) does work on these things when time allows. Man still needs to feed his family while giving thankless hours to the zm project.

I would be more interested in why patches are being created and not shared with upstream? We could collaborate and fix issues together rather than having resentment to a person who is doing their best. End of day, this is OSS and we could all use a little help from time to time.

Please join our slack/discord channels and join the conversation. I think you'll find were more than open to solve issues and make everyone's experience better.

1.37 has MANY fixes for issues plaguing 1.36, is there a reason there is no zm-git pkg available to build master snapshots?

Nocifer commented on 2024-09-11 08:58 (UTC)

@shella Why oh why can't the upstream devs do what you've done? Especially when they've already done a similar thing for the FFmpeg 5 -> 6 transition. It seems that keeping their codebase up to date with current FFmpeg versions is not even a remote priority for them: it's been months since FFmpeg 7 was released, and it's even been a month since I reported that 1.36.34 (which was supposed to tackle this) is still broken on FFmpeg 7, and there hasn't been a single reply on that report thread to even acknowledge the fact, let alone a 1.36.35 release to address it. Thanks for your effort, and please consider making a PR with your fixes.

On the other hand, I'm now hitting a new error:

CMake Error at scripts/ZoneMinder/cmake_install.cmake:54 (file):
  file INSTALL cannot find
  "/build/zoneminder/src/zoneminder-1.36.34/scripts/ZoneMinder/output": No
  such file or directory.
Call Stack (most recent call first):
  scripts/cmake_install.cmake:172 (include)
  cmake_install.cmake:77 (include)


make: *** [Makefile:100: install] Error 1

@everyone Regarding your Perl module issues, FWIW I've just tried every single module and they all build successfully on my end, so these issues have probably something to do with your end. Perl was recently updated to 5.40, and some of these modules could be failing to build due to local caches ($pkgdir, $srcdir, etc) pointing to the old 5.38, so if you haven't already done so I'd try clearing those before building. Also, I have to agree that posting about your errors without providing your logs will hardly get you anywhere.

blinx commented on 2024-09-11 07:44 (UTC)

@shella It was basically during "Checks", it didn't run all expected tests, but your comment about "having a new clean env" gave me the idea of removing everything related to perl (and perl itself) and retry it, now I was able to build it successfully.

simona commented on 2024-09-10 20:08 (UTC)

I have problem with perl-data-entropy

shella commented on 2024-09-10 19:58 (UTC)

@blinx I installed Arch Linux in a new virtual machine to try to reproduce your problem. The perl-soap-wsdl package installed without problems. Please clarify which error you're experiencing.

blinx commented on 2024-09-10 14:11 (UTC)

@shella I can confirm that those packages can be built, but the one giving me problems is perl-soap-wsdl

shella commented on 2024-09-08 06:23 (UTC)

@wolfsilver00 Packages perl-crypt-eksblowfish and perl-io-socket-multicast, perl-io-interface and perl-data-entropy built successfully on my computer. Problem may not be relevant.

shella commented on 2024-09-07 12:50 (UTC)

My build for version 1.36.34 (with ffmpeg7 patch) https://github.com/oxbob/aur_zoneminder/blob/main/PKGBUILD https://github.com/oxbob/aur_zoneminder/blob/main/more_handle_ffmpeg7_deprecations.patch

wolfsilver00 commented on 2024-09-06 01:09 (UTC) (edited on 2024-09-06 01:16 (UTC) by wolfsilver00)

There does not seem to be activity on some of the dependencies, if someone could help out, perl-crypt-eksblowfish and perl-io-socket-multicast, perl-io-interface and perl-data-entropy fail to build

« First ‹ Previous 1 2 3 4 5 6 7 .. 63 Next › Last »