Description of problem: For a while now I have been experiencing what seemed to be random freezes of the desktop soon after installation but it has become apparent that the freezes (no mouse or keyboard response) occur only when there is access to the fonts directories in /usr/share. As far as I can tell, generalising from two other share directories everything else is normal. One of my housekeeping tasks after an install is to populate the fonts/default/ghostscript directory with a number of Type1 files for use with Postscript, usually via a tar file operating as root. The cp or tar xf commands appear to work and then the freeze happens. Crash reboot and the journal file is wiped out. Nothing in dmesg. Logged back in the user can see the new file(s). To find out how widespread this behaviour is I copied a dummy text file to /, /usr, /usr/share and /usr/share/fonts. Only the last one caused the freeze and after reboot removing it also caused the freeze. My guess is that Cauldron is enforcing some kind of censorship at a level users do not know about, although it is puzzling that the action succeeds and then the system falls over. The fault occurs with su or sudo. Version-Release number of selected component (if applicable): 5 final, but rc versions as well How reproducible: Every time there is a write or removal in the /usr/share/fonts tree. Steps to Reproduce: 1. Copy any file to /usr/share/fonts/.... 2. 3. Reproducible: Steps to Reproduce:
This happens with drakfont also. A whole folder-full of TTFs installed and the system froze. Using drakfont with a single file install had the same result. This does not occur in Mageia 4. Now, I should test this on other machines.
Corrupted font...?
CC: (none) => thierry.vignaud
No. All the newly installed fonts come up correctly in X. The sort of errors which came out of ttf2pt1 on Mageia 4 installs also show up in Cauldron but the fonts are usable. type1inst works and the dummy text file I used has nothing to do with fonts but still caused the freeze. The procedure I use has not varied over many dozens of installations going back years.
Then the latest fontconfig doesn't like what happens. Are you sure you do not overwrite some files? fontconfig historically doesn't like it
Source RPM: (none) => fontconfig?
Aha! Yes, the tar file is a snapshot of the ghostscript directory including the fonts installed by the system. It looks like I need to prune the tar file or maybe install a few fonts at a time via drakfont or copying on a virgin install.
overwritting font files mapped by fontconfig is a known crasher...
Status: NEW => RESOLVEDResolution: (none) => INVALID
So fontfig lurks in the background and expects any new file to be something to do with fonts? I wonder how it interprets dummy.txt? That certainly does not overwrite any font files.
Resolution: INVALID => FIXED
What would be preferable would be to use the processed fonts (*.afm *.pfb) from the user directory. Initially I tried that with GS_FONTDIR pointing to my local font files but they were not seen even after type1inst. Don't know what else has to be done.
Since this problem is caused by a known (and accepted) behaviour of fontconfig this bug should be closed as invalid.
Which I did but you reversed it...
Resolution: FIXED => INVALID