Description of problem: Every update to php-ini offers the user the chance to "use rpmnew" for php.ini. If selected this breaks ZoneMinder by removing the "date.timezone" entry in php.ini which is essential for it to run. I think that date.timezone should be set automatically on install of php according to the locale, and users should not be given the opportunity to shoot themselves in the foot in rpmdrake. Our ZoneMinder setup script does check for and create the php.ini date.timezone entry on installation if it is missing, but it can't protect users from accepting rpmnew. Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3.
Assigning to all packagers collectively, since there is no registered maintainer for this package.
CC: (none) => marja11Assignee: bugsquad => pkg-bugs
This isn't so much an rpmdrake problem as an upstream problem. PHP used to read the timezone from the system. Then upstream decided at one point to stop doing that and force you to have to set the variable in php.ini. This was frankly a stupid regression. Furthermore, we really need software to stop relying on a huge configuration file that you're supposed to edit. They should either use two files (one with defaults and one with local settings) or a php.ini.d directory with drop-ins where you can store your local changes without editing a package-owned file. Ideally, config(noreplace) files shouldn't be a thing.
This looks interesting: http://php.net/manual/en/configuration.changes.modes.php
@David: I think the main problem of having a user-specific config is already solved: the /etc/php.d dir is scanned for config settings. First we only have to create these files on install but we can leave them as they are. With this directiv it should be easy to have user settings in php.d and leave php.ini untouched.
CC: (none) => mageia
(In reply to Marja van Waes from comment #1) > Assigning to all packagers collectively, since there is no registered > maintainer for this package. I should have assigned this bug to the php maintainer group instead.
Assignee: pkg-bugs => php
Splitted the ini file into separate files. This should make updates more comfortable and can prevent this error.
Resolution: (none) => FIXEDStatus: NEW => RESOLVED
(In reply to Marc Krämer from comment #6) > Splitted the ini file into separate files. This should make updates more > comfortable and can prevent this error. So we now have /etc/php.d/*.ini files which take precedence over anything in php.ini? Is that correct? Why are random lat/long and azimuth etc. values already written in /etc/php.d/05date.ini when the date.timezone is blank? They are not from my location. I just tried to install zoneminder in cauldron and there was an apparently invalid entry in php.ini of date.timezone=GB:: I have no idea where it came from but it broke the set up, as the zmsetup script assumes that if there is an entry for date.timezone then it will be valid. I will update zmsetup to ignore php.ini and look for an entry in /etc/php.d/05date.ini and if it's missing, write a valid one from the system.
jepp, that is correct.
Thanks, I still get 'invalid timezone' error from zoneminder with "Europe/London" in /etc/php.d/05date.ini :\ I will try to figure out how it arrives at this conclusion.
Here is the php code that checks for a valid date.timezone // Check time zone is set if (!ini_get('date.timezone') || !date_default_timezone_set(ini_get('date.timezone'))) { date_default_timezone_set('UTC'); Fatal( "ZoneMinder is not installed properly: php's date.timezone is not set to a valid timezone" ); } Any clues as to why this fails in current cauldron. It is the same code in Mga6 zoneminder with "Europe/London" which is working fine.
nope, it works fine for me. I assume /etc/php.d/ is not parsed correctly. Are you using php-cli, or anything else?
(In reply to Marc Krämer from comment #11) > nope, it works fine for me. > I assume /etc/php.d/ is not parsed correctly. Are you using php-cli, or > anything else? It's ZoneMinder that checks for the date.timezone in php.ini using the code snippet in #10. That code is from /usr/share/zoneminder/www/index.php. I will attach that file although iirc it is the same in the current version in svn. I have never played with php so any help would be appreciated.
Created attachment 10486 [details] index.php
can you attach the ouput of php -i|grep date
and please attach /etc/php.d/05date.ini, /etc/php.ini and php -v
OK Marc, I found it. There was a file /etc/php.d/05date.ini as well as the correct /etc/php.d/05_date.ini It was created by an intermediate version of zmsetup that I was working on that had a typo in the filename. The GB.. came from the original method of finding the timezone that no longer works correctly. Your php -i|grep date took me straight to it! All working now so I can finish updating and testing the package. Thanks!
ah :) very well. Finnally we've got it working.