[Bug 1376476] urw-fonts: new release(20160926) available
by bugzilla@redhat.com
https://bugzilla.redhat.com/show_bug.cgi?id=1376476
--- Comment #8 from David Kaspar [Dee'Kej] <dkaspar(a)redhat.com> ---
Not really, I was doing some pre-liminary investigations during December 2016,
but I hit several problems with my Fedora, which took some time to solve.
Now I'm focusing on something different. I hope to get back to this in
March/April, but I'm not making any promises, because this will have to be
coordinated with fixing of other packages related to ghostscript.
Best regards,
Dee'Kej
--
You are receiving this mail because:
You are on the CC list for the bug.
7 years, 2 months
[Bug 1376476] urw-fonts: new release(20160926) available
by bugzilla@redhat.com
https://bugzilla.redhat.com/show_bug.cgi?id=1376476
Xose Vazquez Perez <xose.vazquez(a)gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Summary|Use internal |urw-fonts: new
|fonts(Resource/Font/) |release(20160926) available
|instead of urw-fonts |
--- Comment #7 from Xose Vazquez Perez <xose.vazquez(a)gmail.com> ---
Is there any news?
--
You are receiving this mail because:
You are on the CC list for the bug.
7 years, 2 months
[Bug 1377367] fontconfig cache in /var incompatible with ostree
model;
unable to `rpm-ostree install emacs`
by bugzilla@redhat.com
https://bugzilla.redhat.com/show_bug.cgi?id=1377367
Daniel Berrange <berrange(a)redhat.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |berrange(a)redhat.com
--- Comment #23 from Daniel Berrange <berrange(a)redhat.com> ---
(In reply to Matthew Miller from comment #22)
> (In reply to Colin Walters from comment #20)
> > One thing that makes this more urgent is that libvirt -> qemu indirectly
> > pulls in fontconfig (and tons of desktop libraries), because qemu links to
> > gtk for bad reasons.
>
> Bad and hard to fix, or bad and fixable reasons?
Bad and hard to fix I'm afraid :-(
QEMU has multiple different frontends it builds support for, SDL, GTK, VNC and
SPICE. While users who run VMs via libvirt will always use VNC or SPICE, users
who run VMs without libvirt will typically use the GTK or SDL frontend. While
we encourage people to use libvirt, we can't simply ignore people who don't use
libvirt as they have valid reasons for their choices.
So we have to enable GTK or SDL or both in Fedora. We could probably make a
case for dropping SDL support in QEMU in Fedora, as GTK frontend is better
these days, but that's going to have negligible impact on the deps pulled in.
There is a desire in QEMU upstream to modularize the codebase so that things
can be split off into separately dlopen()able modules, with the intention that
it will allow distros to ship all features without having to pull in the whole
world at once. This is non-trivial work, especially for UI frontends to QEMU,
so I'm not expecting it to be done any time soon.
--
You are receiving this mail because:
You are on the CC list for the bug.
7 years, 2 months