Re: Is fc-cache broken on -current?
walt wrote: Joerg Sonnenberger wrote: On Sun, Sep 24, 2006 at 03:05:44PM -0700, walt wrote: Can anyone confirm this error with the latest fontconfig from pkgsrc? # fc-cache -v /usr/pkg/xorg/lib/X11/fonts/TTF /usr/pkg/xorg/lib/X11/fonts/TTF: caching, 22 fonts, 0 dirs /usr/pkg/xorg/lib/X11/fonts/TTF: failed to write cache fc-cache: failed Works fine here. Can you delete all old font caches just to make sure that it doesn't try to reuse those? Bah. The problem was the old fontconfig config-files in /usr/pkg/etc. I noticed that the update announced that there were existing config files so they were not touched. The problem was that those config files should have been replaced during the update! Ordinarily NOT by the 'update'. But by the 'updater', .. with care to preserve whatever customization is still appropriate, if any. That's why the general rule is to produce a message and NOT over-write. Easy to get the new set that had been skipped spit-out again. Much harder to recover lost ones automatically, and silently, over-written. Bill
Re: Is fc-cache broken on -current?
On Thu, 28 Sep 2006, Bill Hacker wrote: walt wrote: Joerg Sonnenberger wrote: On Sun, Sep 24, 2006 at 03:05:44PM -0700, walt wrote: Can anyone confirm this error with the latest fontconfig from pkgsrc? # fc-cache -v /usr/pkg/xorg/lib/X11/fonts/TTF /usr/pkg/xorg/lib/X11/fonts/TTF: caching, 22 fonts, 0 dirs /usr/pkg/xorg/lib/X11/fonts/TTF: failed to write cache fc-cache: failed Works fine here. Can you delete all old font caches just to make sure that it doesn't try to reuse those? Bah. The problem was the old fontconfig config-files in /usr/pkg/etc. I noticed that the update announced that there were existing config files so they were not touched. The problem was that those config files should have been replaced during the update! Ordinarily NOT by the 'update'. But by the 'updater', .. with care to preserve whatever customization is still appropriate, if any. That's why the general rule is to produce a message and NOT over-write. Easy to get the new set that had been skipped spit-out again. Much harder to recover lost ones automatically, and silently, over-written. On deinstallation of a package, the package's registered configurations are compared with the versions in the share/examples directory. If different, then it is removed. On a package installation, if the configuration does not exist, it will be copied into place from the (newly installed) share/examples version. In the case of fontconfig, the fonts.conf file should not be manually edited by the admin as the customizations should be in local.conf.
Re: Is fc-cache broken on -current?
Jeremy C. Reed wrote: On Thu, 28 Sep 2006, Bill Hacker wrote: *snip* Ordinarily NOT by the 'update'. But by the 'updater', (person, not process...) On deinstallation of a package, the package's registered configurations are compared with the versions in the share/examples directory. If different, then it is removed. On a package installation, if the configuration does not exist, it will be copied into place from the (newly installed) share/examples version. All well and good, but what you have NOT mentioned is what has been done vs should have been done if the configuration DOES exist. whyzat ? In the case of fontconfig, the fonts.conf file should not be manually edited by the admin as the customizations should be in local.conf. OK - why then was the old fontconfig defaults? NOT removed or replaced? Reality doesn't seem to be following either my preferences or your 'should have' (standard?) here. Not a who is right/wrong issue to me. More one of expectations/predictability - and what is presently in the code Bill
Re: Is fc-cache broken on -current?
Jeremy C. Reed wrote: On Thu, 28 Sep 2006, Bill Hacker wrote: walt wrote: The problem was that those config files should have been replaced during the update! Ordinarily NOT by the 'update'. But by the 'updater', .. with care to preserve whatever customization... In the case of fontconfig, the fonts.conf file should not be manually edited by the admin as the customizations should be in local.conf. Right. 'fonts.conf' has a big banner at the top, cautioning the admin *not* to edit the file. The concept of a 'config' file which must not be edited is a bit bizarre, IMO. That sort of 'config' is done at compile-time (usually). This means that the fontconfig package *should* replace at least those 'do-not-edit' config files without asking.
Re: Is fc-cache broken on -current?
Does the problem still exist? Can you install and deinstall the package and install again and the configuration files are handled correctly? It is possible the problem with the configurations was due to a broken INSTALL/DEINSTALL script that was included with the previously installed version. It has been proposed for future package installation tools to handle the configuration file processing. This means that improvements can be made to the tool instead of thousands of previously-created packages. (The way it is now means that any time a there is some bug or an improvement for this, then all packages that hve configurations would have to be rebuilt.)
Re: Is fc-cache broken on -current?
walt wrote: Jeremy C. Reed wrote: On Thu, 28 Sep 2006, Bill Hacker wrote: walt wrote: The problem was that those config files should have been replaced during the update! Ordinarily NOT by the 'update'. But by the 'updater', .. with care to preserve whatever customization... In the case of fontconfig, the fonts.conf file should not be manually edited by the admin as the customizations should be in local.conf. Right. 'fonts.conf' has a big banner at the top, cautioning the admin *not* to edit the file. The concept of a 'config' file which must not be edited is a bit bizarre, IMO. That sort of 'config' is done at compile-time (usually). This means that the fontconfig package *should* replace at least those 'do-not-edit' config files without asking. Despite the fact that I am personally a 'worst-case offender' and regularly say 'sod that, if it isn't to be altered it should be a binary' - and edit the core files rather than make chained exceptions - I do agree 100% that this should be the 'expectation'. *however* - if the fingerprint DOES NOT MATCH, I would still far rather have the installation/upgrade process throw a flag and leave it for manual action. Regardless of cause. It is just less 'damaging'. It may not be that the 'luser' has messed with it, but that it is not even from the same rev level or *architecture* (think FreeBSD 6.1 i386 vs 6.1 AMD-64 SMP - either of which will run on Intel Dual-core as well as AMD Only problem is an ancient one - those inlined warnings are almost always missed, even if you DO watch the screen - 'specially wityh fast systesm A broader 'fix' DFLY might be able to convey to the POSIX world is a way to separate-out such message types from the spew of '-WALL ' .. ACK... 'dream on, Bill'... Bill
Re: Is fc-cache broken on -current?
= Running POST-INSTALL script actions === Installing files needed by fontconfig-2.4.0nb1: /usr/pkg/etc/fontconfig/conf.d/20-fix-globaladvance.conf many similar lines snipped for brevity /usr/pkg/etc/fontconfig/fonts.conf already exists. --- /usr/pkg/etc/fontconfig/fonts.dtd already exists. --- When you deinstall (pkg_delete) fontconfig, what does it tell you? You may want to diff these two files with the share/examples versions. Are they just old leftovers from some old broken fontconfig package? If you have not customizations, remove these files manually. Once they are gone, does the deinstall/reinstall create the problem again?
Re: Is fc-cache broken on -current?
On Wed, 27 Sep 2006, Jeremy C. Reed wrote: = Running POST-INSTALL script actions === Installing files needed by fontconfig-2.4.0nb1: /usr/pkg/etc/fontconfig/conf.d/20-fix-globaladvance.conf many similar lines snipped for brevity /usr/pkg/etc/fontconfig/fonts.conf already exists. --- /usr/pkg/etc/fontconfig/fonts.dtd already exists. --- When you deinstall (pkg_delete) fontconfig, what does it tell you? === The following files are no longer being used by fontconfig-2.4.0nb1, and they can be removed if no other packages are using them: /usr/pkg/etc/fontconfig/fonts.dtd /usr/pkg/etc/fontconfig/fonts.conf === You may want to diff these two files with the share/examples versions. Are they just old leftovers from some old broken fontconfig package? They are dated Aug 30, 2005 and they were certainly installed by a previous pkgsrc version of fontconfig -- I dunno about 'broken'. If you have not customizations, remove these files manually. Once they are gone, does the deinstall/reinstall create the problem again? No -- in that case, the 'old' files are the same as the 'new' files, so no problem. BTW, if I haven't mentioned it recently (and I haven't) I'm glad that you are keeping an eye on our DFly mail lists for pkgsrc problems. I thank you on behalf of our entire staff! (Disclaimer: I'm not one of the DFly staff, but I still thank you anyway ;o)
Re: Is fc-cache broken on -current?
On Sun, Sep 24, 2006 at 03:05:44PM -0700, walt wrote: Can anyone confirm this error with the latest fontconfig from pkgsrc? # fc-cache -v /usr/pkg/xorg/lib/X11/fonts/TTF /usr/pkg/xorg/lib/X11/fonts/TTF: caching, 22 fonts, 0 dirs /usr/pkg/xorg/lib/X11/fonts/TTF: failed to write cache fc-cache: failed Works fine here. Can you delete all old font caches just to make sure that it doesn't try to reuse those? build# fc-cache -v /usr/pkg/xorg/lib/X11/fonts/TTF /usr/pkg/xorg/lib/X11/fonts/TTF: skipping, 22 fonts, 0 dirs /var/cache/fontconfig: cleaning cache directory /root/.fontconfig: not cleaning unwritable cache directory fc-cache: succeeded Joerg
Is fc-cache broken on -current?
Can anyone confirm this error with the latest fontconfig from pkgsrc? # fc-cache -v /usr/pkg/xorg/lib/X11/fonts/TTF /usr/pkg/xorg/lib/X11/fonts/TTF: caching, 22 fonts, 0 dirs /usr/pkg/xorg/lib/X11/fonts/TTF: failed to write cache fc-cache: failed I get the same error for all font directories.
