Package Details: zoneminder 1.36.33-2

Git Clone URL: (read-only, click to copy)
Package Base: zoneminder
Description: A full-featured, open source, state-of-the-art video surveillance software system
Upstream URL:
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.36
First Submitted: 2008-03-21 00:09 (UTC)
Last Updated: 2024-02-12 12:50 (UTC)

Latest Comments

1 2 3 4 5 6 .. 60 Next › Last »

Nocifer commented on 2024-03-04 16:59 (UTC) (edited on 2024-03-04 18:07 (UTC) by Nocifer)

That's because apparently perl-class-std-fast was removed from the AUR a few days ago, and it's a dependency of perl-soap-wsdl, which is a dependency of Zoneminder.

EDIT: I reuploaded the package to satisfy the dependency. I really wonder who deleted it so thoughtlessly without first making sure that its removal wouldn't break other packages that may need it...

mateusviccari commented on 2024-03-04 13:47 (UTC)

I'm getting a No AUR package found for perl-class-std-fast error

Nocifer commented on 2024-02-22 08:12 (UTC)

For the past few years and up until last year or so, base-devel had been changed from a meta-package that pulls the base-devel packages as dependencies, into a package group that just allows you to batch install them as explicit, independent packages. When it was changed back to a meta-package, we users were supposed to manually install it (and optionally change the base-devel packages from explicitly installed to dependencies) so it would once again be responsible for managing its dependent packages. I think (but I could be remembering this wrong) that debugedit is a new dependency added in the last few months or so, so if you haven't installed the new base-devel meta-package, then it makes sense that debugedit wouldn't have been pulled in when it was added as a new dependency.

You can check to see if the base-devel packages (gcc, pacman, file, make, etc) are installed on your system explicitly or as dependencies; if they're explicit, then this is probably why.

mosh5382 commented on 2024-02-22 04:01 (UTC)

You are correct @Nocifer. I've been installing AUR packages for years on this system but sure enough base-devel isn't currently installed. I didn't have to pull in any dependencies to install it. Apparently some how I managed to remove base-devel and debugedit but nothing else. I really don't know how that could have happened but it's fixed now so no need to spend anymore time on it. Thanks for maintaining this package.

Nocifer commented on 2024-02-17 19:32 (UTC)

That's probably because you're missing the base-devel package, which is a hard prerequisite for using the AUR.

mosh5382 commented on 2024-02-17 13:20 (UTC)

@Nocifer - I think you should add "debugedit" as a build dependency. Without it I get this error:

/usr/share/makepkg/tidy/ line 48: debugedit: command not found

Nocifer commented on 2024-02-12 12:47 (UTC)

@Garlo Nice find! I had experimented a couple of years ago with JWT but the then current libjwt package couldn't satisfy the dependency for some reason, so I had to leave it out and then promptly forgot all about it.

@grepfor You're right, I'm so used to using an AUR helper to manage AUR packages these days that the possibility of using an old(ish) copy of the PKGBUILD to perform a new installation without ever redownloading it never occurred to me. I guess there was a good reason I used to be against doing even minor updates without incrementing the pkgrel in the past, but apparently I've grown careless enough to break my own rule >.>

Garlo commented on 2024-02-11 18:35 (UTC) (edited on 2024-02-11 18:38 (UTC) by Garlo)

I satisfied libjwt dependency adding LIBJWT_LIBRARY variable to PKGBUILD file in this way:

    build() {
      cd ${pkgname}-${pkgver}

      cmake -DCMAKE_INSTALL_PREFIX=/usr \
        -DLIBJWT_LIBRARY=/usr/lib/ \
        -DZM_CONFIG_DIR=/etc/${pkgname} \
        -DZM_CONFIG_SUBDIR=/etc/${pkgname}/conf.d \
        -DZM_RUNDIR=/run/${pkgname} \
        -DZM_SOCKDIR=/run/${pkgname} \
        -DZM_LOGDIR=/var/log/${pkgname} \
        -DZM_TMPDIR=/var/tmp/${pkgname} \
        -DZM_CONTENTDIR=/var/lib/${pkgname} \
        -DZM_CACHEDIR=/var/lib/${pkgname}/cache \
        -DZM_WEBDIR=/usr/share/webapps/${pkgname}/www \
        -DZM_CGIDIR=/usr/share/webapps/${pkgname}/cgi-bin \
        -DZM_WEB_USER=http .


grepfor commented on 2024-01-18 14:15 (UTC) (edited on 2024-01-18 14:24 (UTC) by grepfor)

@nocifer Imo, that reasoning does not capture a good chunk of real-world use cases for many AUR users, especially those who maintain several machines, and propagate packages locally via copying previously downloaded snapshot tarballs, rather than downloading a new one, unless the pgkrel has been updated.

When I locally propagate an AUR package from one host to others, I go to AUR and search the package name to see if the package version or pkgrel has changed relative to the installed version built from the original snapshot. If neither has changed, I propagate the package to other local target machines by just copying the existing snapshot tarball that I already have, expanding it on the target host and running makepkg there. This ensures that the builds across all my local hosts will start from an identical state.

Incrementing pkgrel would serve to alert users that downloading a new snapshot is warranted.

In this particular case, all snapshots downloaded prior to December 19 are effectively broken because they expose the end-user to silent variability of RtspServer as @synthead pointed out. Yet because the pkgrel was not bumped when that vulnerability was fixed, many people will simply propagate zoneminder locally via copying the previously downloaded snapshot tarball, thus propagating the broken PKGBUILD. Those users will not get the benfit of the fix until the pkgrel (or packager version itself) is bumped.

Just my 2c. I do appreciate the voluntary nature of the work that you and all the other Arch packagers do, and I hope that my comments do not discourage you from that.

Nocifer commented on 2024-01-17 12:40 (UTC)

@grepfor Basically, my thinking can be summed up with a quote from that Wiki link: ...fixes and additional features [...] that influence the resulting package.

The change is very minor in scope and it doesn't really influence the resulting package, because the commit that I used had already been the latest master for ~3 months (which is what the PKGBUILD had been pulling in as a dependency) and it contains only minor code formatting changes (which don't impact the binaries' behavior in the slightest), while the immediately previous commit is ~2 years old.

This means that at the time of the update, pretty much everybody would have already been using either a completely identical package (if they'd installed or updated this package within the previous 3 months) or a functionally identical package (if they'd opted out of updating their systems for longer than 3 months, but no longer than 2 years - the latter being an extreme corner case that I'm not really interested in supporting :P).

So if I'd incremented the pkgrel, the resulting update would be a non-update, either literally or functionally, and in both cases a complete waste of time and CPU cycles.

I could have waited for the next upstream release of Zoneminder and perform this change then, but ZM's releases these days are infrequent at best and this is a security-related fix of benefit to new users, but of no benefit to existing users; so I opted not to wait and instead update the PKGBUILD without incrementing the pkgrel, so new users can benefit from it as soon as possible, while existing users can enjoy their peace of mind.