Description of problem: Triggering a repository sync from the web UI can cause an ORA-01878 if an rhnPacakgeFile contains a file mtime timestamp that doesn't exist in the system timezone due to it being during the skipped hour at DST transition. The rhnPackageFile mtime epoch timestamp is being converted to UTC and supplied to the DB, but the DB expects all timestamps to be in local time. The DB interprets the timestamp as localtime, and for some mtime values this corresponds to times that "do not exist" in the system timezone because they are skipped during DST transition. Version-Release number of selected component (if applicable): 2.4 How reproducible: Quite rare. Requires that a file in an RPM be modified during a time that that when translated to UTC is during the non-existent DST transition hour for system timezone. Steps to Reproduce: 1. Set system timezone to one that undergoes DST transition. 2. Create RPM with file mtime that when translated to UTC is during the non-existent DST transition hour for system timezone. 3. Add to repo for sync. 4. Sync repo. Actual results: ORA-01878: specified field not found in datetime or interval Expected results: Successful sync Additional info: This only happens from the web UI because Taskomatic sets the DB session timezone to localtime. When spacewalk-repo-sync is run from the cmdline, it doesn't happen because the DB session timezone is set to the UTC offset, not an Olsen timezone.
System timezone needs to be set to an Olson timezone for this to trigger, simply setting to a UTC offset isn't sufficient because offsets don't have any DST transition information.
https://github.com/spacewalkproject/spacewalk/pull/520
spacewalk.github: b3e707a4f43deee374c7ccea165e75a66038ce60
fixed python 2.4 build issue for rhel5 spacewalk.github: 3b3d14474640374c6a8aa9e2d2dce40c67878983 spacewalk-backend-2.7.87-1
Spacewalk 2.7 has been released. https://github.com/spacewalkproject/spacewalk/wiki/ReleaseNotes27