Bug 910749 - Fontconfig warning: "/etc/fonts/conf.d/50-user.conf", line 9: reading configurations from ~/.fonts.conf is deprecated
Summary: Fontconfig warning: "/etc/fonts/conf.d/50-user.conf", line 9: reading configu...
Keywords:
Status: CLOSED DUPLICATE of bug 882267
Alias: None
Product: Fedora
Classification: Fedora
Component: fontconfig
Version: 18
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Akira TAGOH
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-02-13 13:27 UTC by Harald Reindl
Modified: 2013-06-24 09:37 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-06-24 09:37:56 UTC


Attachments (Terms of Use)

Description Harald Reindl 2013-02-13 13:27:46 UTC
Fontconfig warning: "/etc/fonts/conf.d/50-user.conf", line 9: reading configurations from ~/.fonts.conf is deprecated

what about fix this file instead overwrite already fixed on yum-updates while bailing at the same moment that is deprecated as also while opening ANY graphical application in a terminal?

Comment 1 Akira TAGOH 2013-02-14 02:24:31 UTC
So what would you suggest?

that encourage you to move them from the deprecated place to new one. you can find it out from the release notes: http://docs.fedoraproject.org/en-US/Fedora/18/html/Release_Notes/sect-Release_Notes-Changes_for_Desktop.html#idm33339648

Comment 2 Frank Ch. Eigler 2013-03-13 15:59:29 UTC
How about simply not deprecating the old place, by dropping the deprecated="yes" part from the 50-user.conf config file, and otherwise just leaving it alone?  What absolute requirement exists to force users to change their working setup?

Comment 3 Harald Reindl 2013-03-13 16:24:29 UTC
whatever - but i expect as user that package-maintainers read such messages which i face due the update, permanently by startign any graphical app from a konsole in the development cycle and fix such issues

Comment 4 Akira TAGOH 2013-03-14 02:42:56 UTC
Well, maintaining multiple places to customize makes complicated and hard to track issues down when something happened. the way to shut it up is indeed simple. but investigating issues isn't simple then. one who is responsible/helping your issues always needs to care about both places. that's why old one *is* deprecated.

Aside from that, there are no way to fix that with scriptlet in the package once it has been completely gone. in fact it's not a part of file in the package. you have to manage it yourself.

I see it's not an user-friendly reminder since it doesn't mention where is new place. so that is what only thing I can improve, I think so far.

Comment 5 Frank Ch. Eigler 2013-03-14 02:48:17 UTC
(In reply to comment #4)
> [...] one who is responsible/helping your issues always needs to care about 
> both places. that's why old one *is* deprecated. [...]

Can you give an example of a problem (maybe a bz?) where helping someone with
a font issue was made simpler by saying "check some $XDG_FOO subdirectory under $HOME", but where adding "... or $HOME/.fonts" would have been too complicated?

Comment 6 Akira TAGOH 2013-03-14 03:02:03 UTC
You are just assuming one knows something broken in fontconfig recipes. there should be some possibilities in other areas if an issue is just "rendering is broken" say. and also assuming one knows fontconfig deals with both places. reporter may says "I don't have any custom recipes in my $HOME" but any tools or something like that may care.

Comment 7 Luigi Toscano 2013-04-12 10:17:34 UTC
Isn't this a duplicate of https://bugzilla.redhat.com/show_bug.cgi?id=882267 ?

Comment 8 Akira TAGOH 2013-06-24 09:37:56 UTC
Yes.

*** This bug has been marked as a duplicate of bug 882267 ***


Note You need to log in before you can comment on or make changes to this bug.