Builder ffmpeg-solaris10-sparc Build #12426

Results:

Failed shell_2 shell_3 shell_4 shell_5

SourceStamp:

BuildSlave:

Reason:

The SingleBranchScheduler scheduler named 'schedule-ffmpeg-solaris10-sparc' triggered this build

Steps and Logfiles:

1. git update ( 8 secs )
   1. stdio
2. shell 'gsed -i ...' ( 0 secs )
   1. stdio
3. shell_1 'gsed -i ...' ( 0 secs )
   1. stdio
4. shell_2 'gsed -i ...' failed ( 0 secs )
   1. stdio
5. shell_3 './configure --samples="../../../ffmpeg/fate-suite" ...' failed ( 8 secs )
   1. stdio
   2. config.log
6. shell_4 'gmake fate-rsync' failed ( 0 secs )
   1. stdio
7. shell_5 '../../../ffmpeg/fate.sh ../../../ffmpeg/fate_config.sh' failed ( 2 secs )
   1. stdio
   2. configure.log
   3. compile.log
   4. test.log

Build Properties:

Forced Build Properties:

Responsible Users:

1. Martin Storsjö

   martinohnoyoudont@martin.st

Timing:

All Changes:

:

1. Change #242712

   Category	ffmpeg
   Changed by	Martin Storsjö <martinohnoyoudont@martin.st>
   Changed at	Mon 11 Aug 2025 22:14:35
   Repository	https://git.ffmpeg.org/ffmpeg.git
   Project	ffmpeg
   Branch	master
   Revision	13139d6d83e8bdcf8a2c81af14ed2c3e30b5e1c1

   Comments

   fate: Fix the sub-mcc tests on Windows in eastern time zones
   Previously, these tests failed when running on Windows, if the
   system is configured with a time zone east of Greenwich, i.e.
   with a positive GMT offset.
   
   The muxer converts the creation_date given by the user using
   av_parse_time to unix time, as a time_t. The creation_date is
   interpreted as a local time, i.e. according to the current time
   zone. (This time_t value is then converted back to a broken out
   local time form with localtime_r.)
   
   The given reference date/time, "1970-01-01T00:00:00", is the
   origin point for unix time, corresponding to time_t zero. However
   when interpreted as local time, this doesn't map to exactly zero.
   Time zones east of Greenwich reached this time a number of hours
   before the point of zero time_t - so the corresponding time_t
   value essentially is minus the GMT offset, in seconds.
   
   Windows mktime returns an error, returning (time_t)-1, when given
   such a "struct tm", while e.g. glibc mktime happily returns a
   negative time_t. av_parse_time doesn't check the return value of
   mktime for potential errors.
   
   This is observable with the following test snippet:
   
       struct tm tm = { 0 };
       tm.tm_year = 70;
       tm.tm_isdst = -1;
       tm.tm_mday = 1;
       tm.tm_hour = 0;
       time_t t = mktime(&tm);
       printf("%d-%02d-%02d %02d:%02d:%02d\n", tm.tm_year + 1900, tm.tm_mon + 1, tm.tm_mday, tm.tm_hour, tm.tm_min, tm.tm_sec);
       printf("t %d\n", (int)t);
   
   By varying the value of tm_hour and the system time zone, one
   can observe that Windows mktime returns -1 for all time_t values
   that would have been negative.
   
   This range limit is also documented by Microsoft in detail at
   https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/mktime-mktime32-mktime64.
   
   To avoid the issue, pick a different, arbitrary reference time,
   which should have a nonnegative time_t for all time zones.

   Changed files

   • tests/fate/subtitles.mak
   • tests/ref/fate/sub-mcc-remux
   • tests/ref/fate/sub-mcc-remux-eia608
   • tests/ref/fate/sub-mcc-remux-eia608-bsf
   • tests/ref/fate/sub-mcc-remux-eia608-recode