Description of problem: With minimal install eclipse doesn't display fonts correctly. Installing full GNOME helps, but I would rather not to do that. Version-Release number of selected component (if applicable): 4.2.0-6.fc18.x86_64 How reproducible: always Steps to Reproduce: 1. mock -r fedora-rawhide-x86_64 init 2. mock -r fedora-rawhide-x86_64 install eclipse xauth sudo 3. mock -r fedora-rawhide-x86_64 shell "adduser me" 4. mock -r fedora-rawhide-x86_64 shell "sudo -u me sh -c 'cat >~/.Xauthority'" <~/.Xauthority 5. mock -r fedora-rawhide-x86_64 shell "DISPLAY=$DISPLAY sudo -u me eclipse" Actual results: 1. instead of proper shapes, each character in the window is represented by a rectangle (see attachement) 2. a warning is displayed: (Eclipse:5056): Pango-WARNING **: failed to choose a font, expect ugly output. engine-type='PangoRenderFc', script='common' Expected results: workspace selection window is displayed correctly Additional info: mock -r fedora-rawhide-x86_64 install @'GNOME Desktop Environment' fixes the problem.
Created attachment 602207 [details] screenshot That's how workspace selection window looks like.
Do you happen to know what should be added to dependencies?
(In reply to comment #2) > Do you happen to know what should be added to dependencies? I'm not very familiar with font packages, but installing either @'GNOME Desktop Environment' or 'liberation-*' fixes the problem.
And what about fontconfig? Does installing it help?
Hmm, this warning seems to come from Pango itsel, so maybe it's missing Require on pango itself. I don't see a reason for adding requires on every app using pango if it's somethign required by pango to work properly
Matthias, would you please comment ?
I suppose it is a missing font. The warning is coming from pango so it seems not missing... Does installing @fonts also fix the problem? I am also opposed to apps requiring explicit fonts since typically there are various fonts that work so forcing a particular font on users that is not explicitly required by upstream seems wrong to me. Maybe we should have a @base-fonts group to help people that refuse/don't install @fonts? What desktop are you using?
Citing: <notting> mclasen: i wouldn't push it to the apps - if people insist on installing bare apps w/o desktops, i'd push it to fontconfig
notting suggested that maybe fontconfig should requires dejavu-font to provide basic coverage for people running minimal installs.
(In reply to comment #7) > Maybe we should have a @base-fonts group > to help people that refuse/don't install @fonts? What would be the point? The default packages in @fonts are already those supposed to be vetted by i18n to get the language coverage of a Fedora default install. If we manage @fonts defaults properly, there is no reason to cut down @fonts except if someone wants less than our default coverage, and in that case they can put the font packages they want in their kickstart manually. The nice thing about the current system is that trying to set up a spin or custom install without @fonts is not transparent for technical persons that live in ASCII land all day round. If they remove @fonts they have to select the font packages to replace it or the install is broken for them too, and at this point most realise it's not a good idea to mess with font defaults unless you have a very good idea of the language coverage you target and of the properties of the available fonts. Clean breakage is a lot better than semi-breakage that can only occurs in specific locales, or when rendering people names If we had a latin font fallback somewhere we'd get a lot of broken spins i18n-wise: they'd snip @fonts as part of slimming down, don't notice the breakage for their own use, and by the time the spin was finalised and pushed to users that did need the coverage it would be too late.
I basically agree with what nim-nim says. as the applications might has translations, if we have a specific font in deps of fontconfig, it just works for the specific languages though, it's not a solution for all of languages. i.e. it still happens if one runs applications with the certain locale. we have minimal sets of font packages in @fonts to cover scripts we support in Fedora. I don't see why one don't want to do yum install @fonts. you can get same package sets to what you get on the default install.
I didn't have any desktop environment installed (as original description says, I had only @buildsys-build, eclipse, xauth and sudo installed). I will try with @fonts installed a bit later.
(In reply to comment #7) > Does installing @fonts also fix the problem? Yes, installing @fonts fixes the problem.
This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle. Changing version to '19'. (As we did not run this process for some time, it could affect also pre-Fedora 19 development cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.) More information and reason for this action is here: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19
http://koji.fedoraproject.org/koji/buildinfo?buildID=493525 just pushed the package on rawhide with the above fix. let's see how it affects something, then will push updates for other releases. please test it.
Tested with fontconfig-2.11.1-1.fc21.x86_64 The bug is still reproducible.
Created attachment 882244 [details] Screenshot of eclipse main window
Created attachment 882245 [details] Screenshot of gedit
Did you get any packages providing font(:lang=en) installed?
(In reply to Akira TAGOH from comment #19) > Did you get any packages providing font(:lang=en) installed? Yes. rpm -q --whatprovides 'font(:lang=en)' lyx-fonts-2.0.7-3.fc21.noarch
This message is a notice that Fedora 19 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 19. It is Fedora's policy to close all bug reports from releases that are no longer maintained. Approximately 4 (four) weeks from now this bug will be closed as EOL if it remains open with a Fedora 'version' of '19'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 19 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Does this still happen on even f21?
(In reply to Akira TAGOH from comment #22) > Does this still happen on even f21? I don't know about F21, but this is still reproducible in rawhide (F22).
Hmm, does the above reproducer still work? I can see the splash screen but no window appears after that. $ NO_AT_BRIDGE=1 DISPLAY=:0 eclipse OpenJDK 64-Bit Server VM warning: ignoring option MaxPermSize=256m; support was removed in 8.0 CompilerOracle: exclude org/eclipse/core/internal/dtree/DataTreeNode.forwardDeltaWith CompilerOracle: exclude org/eclipse/jdt/internal/compiler/lookup/ParameterizedMethodBinding.<init> CompilerOracle: exclude org/eclipse/cdt/internal/core/dom/parser/cpp/semantics/CPPTemplates.instantiateTemplate CompilerOracle: exclude org/eclipse/cdt/internal/core/pdom/dom/cpp/PDOMCPPLinkage.addBinding CompilerOracle: exclude org/python/pydev/editor/codecompletion/revisited/PythonPathHelper.isValidSourceFile CompilerOracle: exclude org/eclipse/tycho/core/osgitools/EquinoxResolver.newState Gtk-Message: Failed to load module "pk-gtk-module" Gtk-Message: Failed to load module "canberra-gtk-module" Gtk-Message: Failed to load module "pk-gtk-module" Gtk-Message: Failed to load module "canberra-gtk-module" ** Gtk:ERROR:gtkstylecontext.c:338:gtk_css_node_get_parent_style: assertion failed: (cssnode->parent == NULL || cssnode->parent->values != NULL)
Eclipse currently crashes on rawhide due to bug #1185828. You can work around this bug by downgrading gtk3 package to version 3.15.3.
This message is a reminder that Fedora 20 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 20. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '20'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 20 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
This looks better on f22. can you please check?
Not reproducible in F22 (with DNF), but this problem still exists in F21 (with YUM).
Mikolaj, does it mean this bug can be closed/currentrelease if working proper with dnf?
(In reply to Alexander Kurtakov from comment #29) > Mikolaj, does it mean this bug can be closed/currentrelease if working > proper with dnf? It works for me now, but I left it up to component maintainers to decide whether this bug is resolved and whether it should be closed or not.
This message is a reminder that Fedora 21 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 21. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '21'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 21 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 21 changed to end-of-life (EOL) status on 2015-12-01. Fedora 21 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.