Package Details: zoneminder 1.36.35-1

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: 72
Popularity: 0.049343
First Submitted: 2008-03-21 00:09 (UTC)
Last Updated: 2024-10-22 17:14 (UTC)

Dependencies (45)

Sources (8)

Latest Comments

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

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.

grepfor commented on 2024-01-15 15:23 (UTC) (edited on 2024-01-15 15:23 (UTC) by grepfor)

@nocifer Out of curiosity for my own education, re your 2023-12-19 13:36 comment: I would like to understand why pkgrel was not incremented as a consequence of the PKGBUILD modification suggested by @synthead that you incorporated.

By my reading of https://wiki.archlinux.org/title/PKGBUILD#pkgrel it seems to me that pkgrel should have been incremented in a case like this, but perhaps my understanding is wrong and there is some advantage (unappreciated by me) in avoiding the incrementation. Please comment.

From my POV as a lowly user, integers are are free and there are lots of 'em, so why not bump the pkgrel just as a matter of routine administrative procedure, so that downloaders of snapshots having a given pkgrel can be assured that the corresponding PKGBUILDs are identical?

Not trying to pick a fight about it, just want to understand why it was done this way.

Nocifer commented on 2023-12-19 13:36 (UTC)

@synthead Smart solution, thanks. Implemented without changing the pkgrel.

@vinibali Sorry, I have never built ZM for anything other than x86_64. Hopefully you've managed to solve your issue in the meantime!

synthead commented on 2023-12-19 09:28 (UTC)

In your PKGBUILD, https://github.com/ZoneMinder/RtspServer/archive/refs/heads/master.zip pulls the master branch of a repo, and the SKIP entry in the sha256sum skips the integrity check for master.zip. This is bad because:

  • It allows this PKGBUILD to be an entrypoint for malicious code via the RtspServer repo
  • Any updates to RtspServer may break this package without warning

Since this repo has no releases or tags, please pick an arbitrary explicit commit (the latest is fine), then download the zip archive of this commit. Then you can add a correct sha256sum to your PKGBUILD. This will mitigate the two concerns above.

vinibali commented on 2023-05-20 03:41 (UTC)

Hi! The ${pkgdir}/usr/share/polkit-1/rules.d was missing on the ARMV7h architecture. I had to disable those command in the package build. Really strage, have you seen this before?

Nocifer commented on 2023-04-19 11:13 (UTC)

@dantob You're right, as per official guidelines 'any' is only meant to signify runtime architecture-independency, and I should be manually specifying the architectures this package can be compiled for. I'll update the PKGBUILD whenever the next upstream update comes out.

dantob commented on 2023-04-18 20:40 (UTC) (edited on 2023-04-18 20:41 (UTC) by dantob)

Please properly set an architecture for this package, 'any' is supposed to only be used when the built package can run on 'any architecture'. That is not the case here.

Separate these into another package if you want to keep 'any'

/usr/bin/zmc: ELF 64-bit LSB pie executable, x86-64
/usr/bin/zmu: ELF 64-bit LSB pie executable, x86-64
/usr/bin/zm_rtsp_server: ELF 64-bit LSB pie executable, x86-64

TeslaZap commented on 2023-03-12 10:21 (UTC)

downgrading ffmpeg works for the missing libs error and it is the recommended workaround.

for those who have many packages depending on the new version of ffmpeg and don't want to downgrade them all, they can extract the 4 missing libs from the previous ffmpeg package version, put them in /usr/local/lib and symlink them. it's not recommended and it must be manually cleaned up once zoneminder package is properly updated.

my affected libs were: libavcodec.so.59 libavformat.so.59 libavutil.so.57 libswscale.so.6 they can be found in /var/cache/pacman/pkg/ffmpeg-2:5.1.2-2-x86_64.pkg.tar.zst

tropicalgrating commented on 2023-03-11 20:38 (UTC)

Hello, just for anyone doing a full system update. FFMPEG gets updated to 6.0.3 and will break the zmc video portion. When you update and then try to view your cameras they all come up with nothing and the log files gives a 127 error. When you try to open the cameras in the terminal like zmc -m# it throws an error in relation to libavformat.so.59 does not exist. Searching the system it looks like libavformat gets updated to 60 and zoneminder has no clue how to use this file. I downgraded back to ffmpeg 5.1.2 and this fixed the issue temporarily. Hope this helps

Nocifer commented on 2023-01-13 08:23 (UTC)

@synthead Do you really think that's necessary? It builds and runs fine in non-Docker environments, and pod2man is already an optional dependency for anyone who may need it for Docker, so adding it as a hard dependency would mean that most users would be installing a package they do not need.

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