[Fedora-i18n-bugs] [Bug 1226576] New: [abrt] gcin: _IO_vfprintf_internal(): gcin killed by SIGSEGV
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1226576
Bug ID: 1226576
Summary: [abrt] gcin: _IO_vfprintf_internal(): gcin killed by
SIGSEGV
Product: Fedora
Version: 22
Component: gcin
Assignee: i(a)cicku.me
Reporter: spff(a)bitmessage.ch
QA Contact: extras-qa(a)fedoraproject.org
CC: i18n-bugs(a)lists.fedoraproject.org, i(a)cicku.me
Description of problem:
Group install the electronic lab, and it seemed there was confligt.Try again
->crash
Version-Release number of selected component:
gcin-2.8.2-3.fc22
Additional info:
reporter: libreport-2.5.1
backtrace_rating: 4
cmdline: /usr/bin/gcin
crash_function: _IO_vfprintf_internal
executable: /usr/bin/gcin
global_pid: 355
kernel: 4.0.4-301.fc22.x86_64
runlevel: N 5
type: CCpp
uid: 1000
Truncated backtrace:
Thread no. 1 (10 frames)
#0 _IO_vfprintf_internal at vfprintf.c:1642
#1 ___vsprintf_chk at vsprintf_chk.c:85
#2 ___sprintf_chk at sprintf_chk.c:31
#3 sprintf at /usr/include/bits/stdio2.h:33
#4 get_icon_path at gcin-icon.cpp:19
#5 load_tray_icon_win32 at tray-win32.cpp:409
#6 update_in_win_pos at eve.cpp:651
#7 toggle_im_enabled at eve.cpp:801
#8 ProcessKeyPress at eve.cpp:1276
#9 xim_ForwardEventHandler at eve.cpp:1485
--
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=cqJT4haztR&a=cc_unsubscribe
7 years, 10 months
[Fedora-i18n-bugs] [Bug 1223927] New: [abrt] ibus-rime: NextCharLength(): ibus-engine-rime killed by SIGABRT
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1223927
Bug ID: 1223927
Summary: [abrt] ibus-rime: NextCharLength(): ibus-engine-rime
killed by SIGABRT
Product: Fedora
Version: 22
Component: ibus-rime
Assignee: pwu(a)redhat.com
Reporter: iamtaylover(a)gmail.com
QA Contact: extras-qa(a)fedoraproject.org
CC: i18n-bugs(a)lists.fedoraproject.org,
petersen(a)redhat.com, pwu(a)redhat.com
Version-Release number of selected component:
ibus-rime-1.2-1.fc22
Additional info:
reporter: libreport-2.5.1
backtrace_rating: 4
cmdline: /usr/libexec/ibus-engine-rime --ibus
crash_function: NextCharLength
executable: /usr/libexec/ibus-engine-rime
global_pid: 2498
kernel: 4.0.3-300.fc22.x86_64
runlevel: N 5
type: CCpp
uid: 1000
var_log_messages: [System Logs]:\n-- Logs begin at 日 2015-05-17 15:48:40 CST,
end at 四 2015-05-21 23:29:42 CST. --
Truncated backtrace:
Thread no. 1 (10 frames)
#6 NextCharLength at /usr/src/debug/OpenCC-ver.1.0.2/src/UTF8Util.hpp:63
#7 opencc::MaxMatchSegmentation::Segment at
/usr/src/debug/OpenCC-ver.1.0.2/src/MaxMatchSegmentation.cpp:37
#8 opencc::Converter::Convert at
/usr/src/debug/OpenCC-ver.1.0.2/src/Converter.cpp:26
#9 ConvertText at /usr/src/debug/librime/src/gear/simplifier.cc:61
#10 rime::Simplifier::Convert at
/usr/src/debug/librime/src/gear/simplifier.cc:180
#11 rime::Simplifier::Apply at
/usr/src/debug/librime/src/gear/simplifier.cc:140
#12 rime::ConcreteEngine::FilterCandidates at
/usr/src/debug/librime/src/engine.cc:213
#13 operator() at /usr/include/c++/4.9.2/functional:2439
#14 rime::Menu::Prepare at /usr/src/debug/librime/src/menu.cc:47
#15 rime::Menu::GetCandidateAt at /usr/src/debug/librime/src/menu.cc:93
--
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=L9Bkr7RzHW&a=cc_unsubscribe
7 years, 10 months
[Fedora-i18n-bugs] [Bug 1084228] New: Hinting for Liberation Sans inferior at small font size
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1084228
Bug ID: 1084228
Summary: Hinting for Liberation Sans inferior at small font
size
Product: Fedora
Version: 20
Component: liberation-fonts
Assignee: psatpute(a)redhat.com
Reporter: Eduard.Braun2(a)gmx.de
QA Contact: extras-qa(a)fedoraproject.org
CC: fonts-bugs(a)lists.fedoraproject.org,
i18n-bugs(a)lists.fedoraproject.org,
petersen(a)redhat.com, psatpute(a)redhat.com
Created attachment 882473
--> https://bugzilla.redhat.com/attachment.cgi?id=882473&action=edit
testcase with the problematic font charakteristics
Wikipedia recently switched to a predefined CSS font stack for body font so
even Windows users will be served with Liberation Sans if installed (e.g.
because it is distributed with Libre Office).
This made apparent inferior hinting of Liberation Sans with bold weight when
rendered at the specific size of 0.875em (the font size used in MediaWiki's
vector skin).
Most notable "e"s have a very thick lower curve while the upper curve is much
too thin. This also applies for variants like "è é ê ë". Funnily not for "œ æ"
though which is rendered differently.
Also notable is e.g. "s" which has thick upper/lower curves but is thin in the
middle.
A testcase with the described font characteristics set is attached. The
screenshot shows the rendering in Firefox.
The screenshot was created with Firefox 28.0 on Windows 7.
The installed version of the Liberation fonts is 2.00.1
--
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=Msol5goZ6N&a=cc_unsubscribe
7 years, 10 months
[Fedora-i18n-bugs] [Bug 1211208] New: ibus-table-createdb should allow table keys to start with spaces
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1211208
Bug ID: 1211208
Summary: ibus-table-createdb should allow table keys to start
with spaces
Product: Fedora
Version: 22
Component: ibus-table
Assignee: mfabian(a)redhat.com
Reporter: mfabian(a)redhat.com
QA Contact: extras-qa(a)fedoraproject.org
CC: dchen(a)redhat.com, i18n-bugs(a)lists.fedoraproject.org,
kent.neo(a)gmail.com, me(a)kaio.net, mfabian(a)redhat.com,
pwu(a)redhat.com, shawn.p.huang(a)gmail.com
James Wood> I recently came across the problem of not being able to
James Wood> bind to sequences starting with a space. This is caused by
James Wood> applying .strip() on line 209 of engine/tabcreatedb.py (in
James Wood> phrase_parser). I can't see start stripping being helpful,
James Wood> and since it restricts functionality, I think it should be
James Wood> replaced by .rstrip() (as well as possibly some other uses
James Wood> of .strip() in the same file).
--
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=eeKHUXzDQq&a=cc_unsubscribe
7 years, 10 months
[Fedora-i18n-bugs] [Bug 1169979] New: Some fonts not in fontconfig cache on Fedora 21 live images
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1169979
Bug ID: 1169979
Summary: Some fonts not in fontconfig cache on Fedora 21 live
images
Product: Fedora
Version: 21
Component: fontconfig
Assignee: tagoh(a)redhat.com
Reporter: awilliam(a)redhat.com
QA Contact: extras-qa(a)fedoraproject.org
CC: fonts-bugs(a)lists.fedoraproject.org,
i18n-bugs(a)lists.fedoraproject.org, pnemade(a)redhat.com,
tagoh(a)redhat.com
We've spotted an issue with Fedora 21 live images where some installed fonts
appear to be missing from the fontconfig cache in the live environment. An
'fc-cache -f' fixes this. For instance, on the Fedora 21 Final RC2 Workstation
x86_64 live:
[root@localhost liveuser]# fc-list | wc -l
141
[root@localhost liveuser]# fc-cache --force
[root@localhost liveuser]# fc-list | wc -l
159
The specific fonts that are missing on that image are:
/usr/share/fonts/dejavu/DejaVuSansMono-BoldOblique.ttf: DejaVu Sans
Mono:style=Bold Oblique
/usr/share/fonts/dejavu/DejaVuSansMono-Bold.ttf: DejaVu Sans Mono:style=Bold
/usr/share/fonts/dejavu/DejaVuSansMono-Oblique.ttf: DejaVu Sans
Mono:style=Oblique
/usr/share/fonts/dejavu/DejaVuSansMono.ttf: DejaVu Sans Mono:style=Book
/usr/share/fonts/dejavu/DejaVuSerif-BoldItalic.ttf: DejaVu Serif:style=Bold
Italic
/usr/share/fonts/dejavu/DejaVuSerif-Bold.ttf: DejaVu Serif:style=Bold
/usr/share/fonts/dejavu/DejaVuSerifCondensed-BoldItalic.ttf: DejaVu
Serif,DejaVu Serif Condensed:style=Condensed Bold Italic,Bold Italic
/usr/share/fonts/dejavu/DejaVuSerifCondensed.ttf: DejaVu Serif,DejaVu Serif
Condensed:style=Condensed,Book
/usr/share/fonts/dejavu/DejaVuSerif-Italic.ttf: DejaVu Serif:style=Italic
/usr/share/fonts/dejavu/DejaVuSerif.ttf: DejaVu Serif:style=Book
/usr/share/fonts/google-noto/NotoSansTagalog-Regular.ttf: Noto Sans
Tagalog:style=Regular
/usr/share/fonts/google-noto/NotoSansTaiViet-Regular.ttf: Noto Sans Tai
Viet:style=Regular
/usr/share/fonts/liberation/LiberationSerif-BoldItalic.ttf: Liberation
Serif:style=Bold Italic
/usr/share/fonts/liberation/LiberationSerif-Bold.ttf: Liberation
Serif:style=Bold
/usr/share/fonts/liberation/LiberationSerif-Italic.ttf: Liberation
Serif:style=Italic
/usr/share/fonts/liberation/LiberationSerif-Regular.ttf: Liberation
Serif:style=Regular
The log of the compose is here:
https://kojipkgs.fedoraproject.org//work/tasks/5463/8275463/root.log
In comparison, the i686 Workstation live is 'missing' only
/usr/share/fonts/google-noto/NotoSansTaiViet-Regular.ttf: Noto Sans Tai
Viet:style=Regular
its compose log is here:
https://kojipkgs.fedoraproject.org//work/tasks/5460/8275460/root.log
to me, it appears the affected cases are ones where more than one package
contains fonts in the same directory, for packages installed *after* the
fontconfig package. The fontconfig package has an 'fc-cache -f' in its %post,
so any inconsistencies that exist before it's installed get fixed by that.
My first thesis was 'for any given directory, only fonts from the first package
installed after fontconfig will make it to the cache, fonts in the same
directory from subsequently-installed packages won't be added'. But it doesn't
seem to be that simple, because some fonts in /usr/share/fonts/google-noto
*are* added - the first 'noto' package installed is google-noto-sans-lisu-fonts
, and after that several more noto packages are installed. The fonts from
google-noto-sans-mandaic-fonts, google-noto-sans-meeteimayek-fonts , and
google-noto-sans-tai-tham-fonts *do* get added to the cache - but the fonts
from google-noto-sans-tagalog-fonts and google-noto-sans-tai-viet-fonts do
*not* get added. It's quite odd.
This is a fairly bad bug because of its impact on DejaVu Sans Mono: this is the
default monospace font for both Workstation and KDE (and I think the
non-blocking spins too). Its absence from the cache results in them using
Nimbus Mono L as their monospace fonts, which is a pretty crappy font, ugly and
hard to read. The workaround is easy once you know it, but if you don't, you
just think we have a really bad font.
There's an easy big hammer workaround we can use for a quick rebuild of the RC2
lives, if we like:
--- a/fedora-live-base.ks
+++ b/fedora-live-base.ks
@@ -299,6 +299,12 @@ rm -f /core*
# convince readahead not to collect
# FIXME: for systemd
+# forcibly regenerate fontconfig cache (so long as this live image has
+# fontconfig) - see #XXXXXXX
+if [ -x /usr/bin/fc-cache ] ; then
+ fc-cache -f
+fi
+
%end
i.e., just do an fc-cache -f at the end of live generation %post. I've tested
that locally, and it works, the generated Workstation image has 159 fonts in
fc-list (I also generated an image with the exact same config and build host,
but no change to spin-kickstarts, to verify that it reproduced the bug, and it
does).
The real fix should likely be in fc-cache, but the spin-kickstarts workaround
would solve this problem for F21.
I think fc-cache's behaviour must have changed between F20 and F21, as F20
doesn't appear to be affected by this at all, at least not the x86_64 desktop
live. All F21 images I've tested seem to be affected to some extent, though the
exact affected fonts vary depending on the package install order that yum
decided on.
--
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=Ex4RiyuuM1&a=cc_unsubscribe
7 years, 11 months