Now I see we were doing an upgrade. This means that fc-cache should be already present on the system.

The scripts in the new packages did not change.  Something else must be going on.

I am trying to reproduce the bug. The odd is that, first, the fontconfig should have been present as it is an upgrade, second even if  it was not, each of these font packages have a dependency for fontconfig.So, it should be able to pull it in any case. Also the scripts have been used since last two updates. Unless there is a problem with the binary path or the cached files. Need to investigate further, as a general update via yum did not reproduce the problem(with and without fontconfig).

The above test reveal that the bug is not only affecting fonts-indic subpackages. It seems its a generic bug concerned with fontconfig or something else. I am not sure what can be written in the release notes for 5.3. But certainly not a bug for fonts-indic.

Reassign component.

This bugzilla was reviewed by QE as a non-FasTrack request.
It has since been proposed for FasTrack. The qa_ack has 
been reset. QE needs to re-review this bugzilla for FasTrack.

Hi,
I'm seeing the following error with latesr builds:

Error(s): Installing fontconfig-2.4.1-7.el5.i386
/usr/share/fonts: failed to write cacheerror: %post(fontconfig-2.4.1-7.el5.i386) scriptlet failed, exit status 1


It seems related but the error message is a bit different.

Can someone confirm that bug #248125 is a duplicate of this one or not?

Created attachment 451645 [details]
Proposed patch based on upstream git commit db6f19f1

How reproducible:

Always with the reproducer below

Steps to Reproduce:

1. Set the mtime in the future on the font directory:

    # touch -mt 202011050000 /usr/share/fonts/bitstream-vera 

2. Run "fc-cache -f" just like the %post scriptlet does

    # fc-cache -f 

Actual results:

    fc-cache fails with: /usr/share/fonts/bitstream-vera: failed to write cache 

Expected results:

    No failure

Additional info:

The following analysis comes from a strace captured on one of the system where the issue occurred (provided by our customer).

Here follows the relevant part:

  13824 stat("/usr/share/fonts/bitstream-vera", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
  13824 open("/var/cache/fontconfig/e3ead4b767b8819993a6fa3ae306afa9-x86-64.cache-2", O_RDONLY) = 3
  13824 fstat(3, {st_mode=S_IFREG|0644, st_size=10136, ...}) = 0
  13824 close(3)                          = 0
  13824 open("/root/.fontconfig/e3ead4b767b8819993a6fa3ae306afa9-x86-64.cache-2", O_RDONLY) = -1 ENOENT (No such file or directory)
  13824 write(2, "/usr/share/fonts/bitstream-vera: failed to write cache\n", 55) = 55

The message "failed to write cache" comes from scanDirs() if FcDirCacheValid returns FcFalse.

All of this code is conveniently located in a single source file fontconfig/src/fccache.c

FcDirCacheValid() returns the value from FcDirCacheValidConfig() which calls FcDirCacheProcess() using FcDirCacheValidateHelper() as callback.

FcDirCacheProcess() will return FcFalse if:

- stat ((char *) dir, &dir_stat) < 0

  Not the case as seen in the strace.
  
- FcStrListCreate() returns no list

  Not the case, because we do open/stat files (see below)!
  
- FcDirCacheOpenFile() will do a open() and fstat(), I think this is what we see here in the trace:

  13824 open("/var/cache/fontconfig/e3ead4b767b8819993a6fa3ae306afa9-x86-64.cache-2", O_RDONLY) = 3
  13824 fstat(3, {st_mode=S_IFREG|0644, st_size=10136, ...}) = 0

  Since the open() succeeded and fstat() returns 0, it is safe to assume that FcDirCacheOpenFile worked.
  
- (*callback) (fd, &file_stat, closure) returns FcFalse

  Here callback == FcDirCacheValidateHelper and the first thing that function does is a read() and we have no trace of that in the strace, so it's clear that the callback has not been called.

Let's take a look at FcDirCacheProcess() again, from src/fccache.c:

136 static FcBool
 137 FcDirCacheProcess (FcConfig *config, const FcChar8 *dir,
 138                    FcBool (*callback) (int fd, struct stat *stat, void *closure),
 139                    void *closure, FcChar8 **cache_file_ret)
 ...
 157     while ((cache_dir = FcStrListNext (list)))
 158     {
 159         FcChar8 *cache_hashed = FcStrPlus (cache_dir, cache_base);
 160         if (!cache_hashed)
 161             break;
 162         fd = FcDirCacheOpenFile (cache_hashed, &file_stat);
 163         if (fd >= 0) {
 164             if (dir_stat.st_mtime <= file_stat.st_mtime)

Here ^^^

 165             {
 166                 ret = (*callback) (fd, &file_stat, closure);
 167                 if (ret)
 168                 {
 169                     if (cache_file_ret)
 170                         *cache_file_ret = cache_hashed;
 171                     else
 172                         FcStrFree (cache_hashed);
 173                     close (fd);
 174                     break;
 175                 }
 176             }
 177             close (fd);
 178         }
 179         FcStrFree (cache_hashed);
 180     }
 181     FcStrListDone (list);
 182 
 183     return ret;
 184 }

So *if* the modification time on the directory is the same or later than the modification time on the cache file, then, the callback is not even called. The ret value being initialised to FcFalse, it's the value returned to the caller, thus causing the error.

I believe this is git commit db6f19f1 upstream: 

    http://cgit.freedesktop.org/fontconfig/commit/?id=db6f19f13b1719617c54a1658b8faa31da56e1d4 

The attached patch is a (pretty straightforward) backport of this commit upstream.

With this patch, the test case does not fail anymore:

    # touch -mt 202011050000 /usr/share/fonts/bitstream-vera
    # fc-cache -f 
    #

*** Bug 703141 has been marked as a duplicate of this bug. ***

I have given patch for this issue in Bug 703141, i think better to proceed for Bug 703141 even errata is ready for same.  built with fix is fonts-indic-2.3.1.1-2.el5. please test and check is it working or not

This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated in the
current release, Red Hat is unfortunately unable to address this
request at this time. Red Hat invites you to ask your support
representative to propose this request, if appropriate and relevant,
in the next release of Red Hat Enterprise Linux.

Development Management has reviewed and declined this request.  You may appeal
this decision by reopening this request.

*** Bug 248125 has been marked as a duplicate of this bug. ***