Arch Linux User Repository

Any and all feedback will be much appreciated. Thanks!

CHANGELOG

Update: 1.32.2-2 -> 1.32.2.3

• Added spawn-fcgi & multiwatch as dependencies. Now fcgiwrap will spawn in multiple instances, so ZoneMinder will be able to utilize more than one CGI threads at the same time and thus show concurrent camera streams, which solves issues like having no image while editing zones, etc. The default number of instances is 10, which should be enough for 2 or 3 cameras, but you can of course edit the provided service file and change the number as you see fit. Big thanks to @chapatt for bringing this to my attention!

Update: 1.32.2-1 -> 1.32.2-2

• Included a /zm/ link inside the /www/ folder that points back to /www/. This fixes pretty much every instance of sloppy hardcoded links within ZM's codebase. Big thanks to @Kubax for the idea!

Update: 1.32.1-3 -> 1.32.2-1

NOTE: There's a bunch of small-ish errors in ZM's operation due to some parts of it having the localhost/zm/ link hardcoded and thus breaking when ZM is run from anywhere else, e.g. localhost:8095. I'm in the process of locating these errors and either reporting them upstream or fixing them myself, but I can't know for sure when or even if they'll be fixed. Big thanks to @Kubax for reporting this.

• Changed temp folder location: /var/lib/zoneminder/temp -> /var/tmp/zoneminder
• Fixed /api/app/tmp to correctly point to the temp folder
• Overhauled how the install script makes the choice between Nginx and Apache, as follows:
  • If Nginx is installed and active, regardless of whether Apache is also installed or active or both, we choose Nginx.
  • If Nginx is installed but inactive, and Apache is not installed, we choose Nginx.
  • If Nginx is installed but inactive, and Apache is installed, we choose Apache.
  • If Nginx is not installed, and Apache is installed, we choose Apache.
  • If neither of them is installed, we simply inform the user about it and do nothing.

It's a fairly simple script and I have tested it as much as I can, but things usually find a way to break apart after introducing such... uhm... breaking changes. If things do break for you, please blame me and not the script itself; and also report here what exactly is broken so I can fix it ;)

Update: 1.32.1-2 -> 1.32.1-3

• MariaDB no longer required (for use with remote databases)
• Apache added as an optional dependency and preferred over Nginx if both are installed

Update: 1.32.1-1 -> 1.32.1-2

• Fixed update process (it erroneously required zoneminder.service to be active while updating its database, when it should rather be the opposite)
• Fixed desktop launcher
• Added logrotate support
• Removed 'perl-module-load-conditional' from dependencies as it is already included in core Perl package
• Other minor fixes (e.g. the license file was being installed in the wrong place)

Thanks for the work on this package!

Please note that the server_name localhost; in nginx config can be problematic. ZM uses SERVER_NAME to build some URLs used in the frontend, so this configuration can cause errors for remote access to ZM (see here ).

==> ВНИМАНИЕ: Пакет содержит ссылку на директорию '$srcdir' usr/bin/zmc usr/bin/zmu usr/bin/zma srv/zoneminder/cgi-bin/zms

# Install Apache conf file
install -Dm644 $srcdir/$pkgname-httpd.conf              $pkgdir/etc/httpd/conf/extra/httpd-$pkgname.conf

@Kubax Hey, sorry for the very late reply. Yes, it's possibly a trizen bug or incompatibility or something, but then again, what you describe (being asked the question correctly after adding that "my" instead of getting an "Unexpected response") sounds equally weird to me. This means that either trizen's bug is inconsistent (which could very well be the case) or it is indeed a bug with ZM itself. Running the updater without trizen on the next upstream update (which should be soon-ish according to the developers) will be a good first step to find out. So, until then :)

@Nocifer

i did just run "trizen -S zoneminder" wihout any other options. But i think the problem is within trizen in this case. sadly i can't reproduce it right now, since the database is allready at version 1.32.2. So i will wait untill next time to see if there is a difference in calling it from trizen, or calling it with makepkg.

at this point i'm pretty sure it will be trizen related. but i'll report back ( if i remember to ^^)

@safety: whoopsie xD that's the price you pay, when you headlessly see a difference and change it... if i recall corectly it asked for if it should make a backup, and when i replyed with "y" it started the backup.

@no report: that's fine, as you allready mentions, seems to be a problem on my side :)

P.s.: seems about right ^^ Anyway, it is / was a good training for when i got time (and money) to place some cam's around "my" house :)

@Kubax

Alright, my bad, I'd read the code incorrectly; you don't need to run the updater manually and with the -interactive flag on in order to reach that part of the code.

Anyway, that prompt is supposed to wait for user input and only repeat itself in case that user input is anything other that 'y', 'Y', 'n' or 'N'. So this sounds like something (yup, probably your package manager, though I guess it could also be a faulty keyboard or sth) interfered with the prompt without giving you the chance to reply properly. Could you be running trizen with the --noconfirm flag? If not, then something else got in the way and kept giving the wrong answer again and again and again ad infinitum, which resulted in the loop. And if I read the code correctly, by changing '$response' to 'my $response', you actually bypassed the script's safety measure (in other words: you broke it :P) and made it disregard the wrong input and proceed anyway. What happened after you did that? Did the script back up the database? Or did you maybe get an "Unexpected response" result?

I'll not report it upstream for the time being, because it seems that the problem is not the code but something else. Let's investigate a little further first :)

PS - I'd be willing to bet there's a bunch of people out there who need ZoneMinder and CCTV in general for the same reason as us. If you visit the websites of various CCTV software/hardware or camera vendors, most all of them have "See what your pets are doing when you're not home" in the top 3 "reasons to buy" of their sales pitch :P

@Nocifer sorry, for the late answer, i forgot to enable notification (fixed it now :)

the zmupdate.pl was called from the package after installation ( i use trizen, so it could also be trizen related ). The loop didn't stop until heavily mashing strg+c (over ssh) i then edited the perl file like i mentioned, an then run it manually. so i'm not (anymore) completely sure if it wasn't my fault.

Oh, the loop was posting the error mentioned constantly without user interaction.

@P.S.: that's funny (not the reason, but the fact that you had the same idea of recording what happens when you are not home). My coworkers at work just had laughter for me, when i told them i'm recording what happens in my livingroom because of that reason ^^

@Kubax

I can't reproduce the error (probably because I'm not running zmupdater.pl in interactive mode, which I presume is what you did?) but I checked the source code and found the line. The thing is, it really doesn't seem wrong to me. "my" is simply Perl-speak for "local variable", which in so many words means a lack of it shouldn't produce this kind of error.

I'll report it upstream, but before I do that please verify the following for me:

• You were asked the question "Do you wish to take a backup of your database prior to upgrading? This may result in a large file in /var/tmp/zoneminder if you have a lot of events. Press 'y' for a backup or 'n' to continue :"
• You answered with either 'y' or 'n'
• You were prompted again with "Please press 'y' for a backup or 'n' to continue only :"
• Either you replied with 'y' or 'n' and the prompt kept repeating itself every time you replied, or it kept repeating anyway without waiting for an answer.

Is that correct?

P.S. - Believe it or not, the reason I decided to get involved with this AUR package and subsequently with ZoneMinder itself, is the exact same reason as yours if you just replace the word "couch" with the word "carpet" :P

there seems to be another upstream error.

when zoneminder.install calles /usr/bin/zmupdate.pl it get's stuck in a loop with this error.

Please press 'y' for a backup or 'n' to continue only : Use of uninitialized value $response in scalar chomp at /usr/bin/zmupdate.pl line 376.
Use of uninitialized value $response in pattern match (m//) at /usr/bin/zmupdate.pl line 376.

changing this line from

376:       $response = <STDIN>;

to

376:       my $response = <STDIN>;

fixes this.

Totaly forgot... thanks for this aur. It would have been a realy hard way of installing zoneminder, just to figure out wich cat is using our couch instead of the cat litter -.-

@dimytch

If I'm not mistaken, this error must have happened after you'd already built the package. So did it build correctly after all, or not? If not, then since multiwatch is an AUR package, try adding armv7 to the list of supported architectures in the PKGBUILD and then try to build the package again.

If it will still not build, I will try to find an alternative for it.

And no, unfortunately I don't have a Pi or any other SBC on which to test this PKGBUILD.