[Fedora-i18n-bugs] [Bug 1401327] New: Finnish (DAS) keyboard layout disappears from base.xml in lastest update
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1401327
Bug ID: 1401327
Summary: Finnish (DAS) keyboard layout disappears from base.xml
in lastest update
Product: Fedora
Version: 25
Component: xkeyboard-config
Severity: urgent
Assignee: peter.hutterer(a)redhat.com
Reporter: iiro.laiho(a)iki.fi
QA Contact: extras-qa(a)fedoraproject.org
CC: i18n-bugs(a)lists.fedoraproject.org,
negativo17(a)gmail.com, peter.hutterer(a)redhat.com
Description of problem:
The Finnish (DAS) keyboard layout disappears after lastest updates on Fedora
25.
Version-Release number of selected component (if applicable):
2.19-1.fc25
How reproducible:
Steps to Reproduce:
1. Install F25, selecting Finnish (DAS) keyboard layout
2. Run dnf update
3. Reboot
Actual results:
It reverts to the ordinary Finnish QWERTY layout
Expected results:
The layout should stay the same
Additional info:
Reproducible on two systems: on a Dell Latitude 6320 and a QEMU/KVM virtual
machine.
Reverting this package to version 2.18-1 fixes the problem.
It is possibly related to this:
https://bugs.freedesktop.org/show_bug.cgi?id=92169
They moved the DAS layout in upstream from base.xml to the base.xml.extras file
as it is less often used. It is however a very bad idea to do breaking changes
to a released distro in such a crucial thing as a keyboard layout.
--
You are receiving this mail because:
You are on the CC list for the bug.
7 years, 3 months
[Fedora-i18n-bugs] [Bug 1377367] fontconfig cache in /var incompatible with ostree model; unable to `rpm-ostree install emacs`
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1377367
--- Comment #18 from Nicolas Mailhot <nicolas.mailhot(a)laposte.net> ---
Well, Fedora font package are one directory per srpm, it would probably not be
too hard to modify the macro to be one package by rpm (the hard part being
filesystem cration which is not automated today). And then rebuild all font
packages.
Though, of course, this may harm fontconfig performance. Not sure it it like
too many directories. And it would transform noarch packages to arch packages
which would be expensive for mirrors, given how bulky unicode fonts are.
On the plus side, installing noto would not kill systems performance for
minutes anymore.
--
You are receiving this mail because:
You are on the CC list for the bug.
7 years, 4 months
[Fedora-i18n-bugs] [Bug 1076945] Arabic Lam-Alef
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1076945
Fedora Update System <updates(a)fedoraproject.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|ON_QA |CLOSED
Fixed In Version| |ibus-m17n-1.3.4-21.fc25
Resolution|--- |ERRATA
Last Closed| |2016-12-22 11:49:50
--- Comment #40 from Fedora Update System <updates(a)fedoraproject.org> ---
ibus-m17n-1.3.4-21.fc25 has been pushed to the Fedora 25 stable repository. If
problems still persist, please make note of it in this bug report.
--
You are receiving this mail because:
You are on the CC list for the bug.
7 years, 4 months
[Fedora-i18n-bugs] [Bug 1377367] fontconfig cache in /var incompatible with ostree model; unable to `rpm-ostree install emacs`
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1377367
--- Comment #14 from Akira TAGOH <tagoh(a)redhat.com> ---
(In reply to Matthew Miller from comment #11)
> Rather than moving the cache around -- or, I guess, in addition to it, but
> obviating an concern about FHS or dyanamic, unmanaged files in /usr, could
> we just pregenerate the cache files at _build_ time rather than install
> time? They appear to be arch specifc (well, word size and order specific)
> but not really host-specific.
At this moment, unfortunately the updates at the install time are required to
update the directory caches. there are two types of the caches in fontconfig.
one is to contain a font meta data to reduce the costs to iterate a font, which
could be generated at the build time (for Fedora at least. generally speaking,
maybe not, because the unit of the cache are per-directories not per-files).
one is to contain a directory meta data to reduce the costs to iterate files in
a directory and detect the updates, which is likely to be changed at the
install time.
--
You are receiving this mail because:
You are on the CC list for the bug.
7 years, 4 months