Arch Linux User Repository

I won't change distros to please the zoneminder development staff, let's be clear. linux is linux.

zoneminder-git is up for anyone who may want it. Of course, here be dragons and all that jazz.

Also, seeing as the 1.36.35 hotfix has been taking a while, I've just pushed an update for 1.36.34 with the FFmpeg 7.0 patch by @shella included. I don't know how well it will run, but at least now it will build.

@simona They're thinking that deploying ZM on an unsupported rolling distro is not a priority use case for them to fix potential regressions. Upstream explicitly supports only LTS distros (e.g. Redhat, Ubuntu LTS, etc) and docker containers, which would not be affected by the FFmpeg 7.0 issue (LTS distros will take years to upgrade from 6.0 or even 5.0, and containers are a controlled environment where you can ship/bundle whatever library version you require/support).

but excuse me... you keep the system constantly updated and you have to uninstall and give up the sw and it wouldn't be a priority? but how do they think?

@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

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

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

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

I have problem with perl-data-entropy

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

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