https://bugzilla.novell.com/show_bug.cgi?id=858842 https://bugzilla.novell.com/show_bug.cgi?id=858842#c2 L. A. Walsh <suse@tlinx.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED CC| |suse@tlinx.org Resolution|DUPLICATE | --- Comment #2 from L. A. Walsh <suse@tlinx.org> 2014-01-15 11:58:15 PST --- Stefan, the bug you are reporting is not a duplicate of 853225. Neither it is a duplicate of related bug 856476. Besides those two bugs, there are at least 2 other bugs related to the new font-config system, that I didn't report and are not reported AFAIK (AsFarAsIKnow) 1) the one you mention where the entire cache is rebuilt with each font installed: pointless. It should should be done, at MOST, once -- if user is informed of delay and NEEDS the new font immediately after install, OR should be scheduled for reboot asynchronously after all fonts are installed, in background -- either immediately after all installs are done and system is mostly quiescent (i.e. when system load <.1), OR at night during system maintenance. (this is the bug you reported). 2) 2nd bug doubling the pain is only on 64-bit systems. If you have a 64-bit system and have 32-bit font-rendering libraries installed -- as it runs the *same program* in both a 64 and a 32 bit version(fc-cache & fc-cache32 I believe -- though on 32-bit only sys, likely there is only fc-cache == 32bit). The 32-bit version takes noticeably longer on a 64-bit system. I may have mentioned both of the above issues, in bug #856476 -- but solving that bug (don't regen font cache in foreground while user is waiting) doesn't stop both fc-cache versions from running (they shouldn't), nor multiple runs of 'fc-cache'. Note -- this isn't a suse-only problem. I updated SW on a *windows-Cygwin*. It tried to do a regen of the fc-cache (or fc-config?) w/each font AND it also called fc-config, as part of gvim startup -- which took *9 minutes* to run on a 6-core 3.4GHz, (fc-config is only single threaded -- don't see why as much time is spent reading each file and compiling result), running in 64-bit mode on a 4-way RAID0 using SSD's with 96G system memory. 2nd note... I can think of a 3rd bug, but low priority -- in the fontconfig stuff in that it doesn't detect duplicate fonts and process them only once (i.e. some broken versions of fc-config add symlinks with underscores in the names -- unnecessary for linux (gvim, terminals et al) or Windows), and I, personally, to save space, run a hard-linking dedup util (perl) on my font dir -- bringing 34918 fonts down to 21467 uniq fonts -- which would save ~40% in execution time if it was recognized. Recognizing _existing_ duplicates (hard links) takes < 1 minute (usually alot less) on my sys. Certainly a small amount of time compared to 5 or 10 minutes used by fc-cache[32]. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=858842 https://bugzilla.novell.com/show_bug.cgi?id=858842#c4 --- Comment #4 from L. A. Walsh <suse@tlinx.org> 2014-01-16 16:08:48 PST --- (In reply to comment #3)

...

1) the one you mention where the entire cache is rebuilt with each font installed: pointless. It should should be done, at MOST, once -- if user is

Correct. This is related to dropping suseconfig.* scripts, see bug 773575 for details.

...

2) 2nd bug doubling the pain is only on 64-bit systems. Linda, please stop discussing this in three different bugs. Thanks.

Please realize the fix you claim is in for 13.2 doesn't fix issue #2 nor does it address issue/bug #856476. fc-cache will still be run twice -- for 32&64 bit archs (#2) fc-cache runs synchronously in foreground as regular user and again as root, taking ~5 minutes each each time the /usr/share/fonts dir is touched (which is often as my font-libs are 3-way synchronized between machines). (bug856476) Having been dealt with QA for decades and having been in QA -- bug reporters are always advised NOT to combine bugs unless they absolutely know they are the same root cause --- In this case, you have advised me not to file 3 separate bugs because you don't seem to realize that the other two issues won't be solved by rpm post-install scripts being accumulated into suseconfig-post install scripts. On top of that -- suseconfig has had this bug in the past when they were rolled in -- If I installed a new font via rpm, I had to wait through a suse config for tex-caching scripts -- which I never used (and have attempted to make sure are not on my system (unless I am specifically using them)). The bug "fix" you think solves the other 2 issues mentioned, doesn't. And the fix you think fixes it is itself a problem in the same class as bug856476 -- updating all that stuff in foreground while the user is waiting). Please don't presume that a user describing 3 or more different problems with a product should roll all the problems into 1 bug. That's not good QA practice. all be rolled into 1 bug -- it helps things get lost. Example: if someone presumed that a mitigation fix for this bug (moving the cache runs into 1 run) would also, automatically address #2 (bug #853225), and bug #856476 (running fc-cache for regular users and root separate -- and making both wait, synchronously when usually not needed), then those bugs might not get addressed or be marked as "low priority".... ;-) -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.