https://bugzilla.redhat.com/show_bug.cgi?id=1689037
Jerry James <loganjerry(a)gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |loganjerry(a)gmail.com
--- Comment #48 from Jerry James <loganjerry(a)gmail.com> ---
If I understand correctly, you are not looking for a memory leak, but rather
for memory corruption. It may very well be that, with the options in comment
47, it is running so slowly as to be useless. Try this:
new-session -d -s anaconda -n main "LD_PRELOAD=libgomp.so.1 valgrind
--tool=memcheck --leak-check=no --num-callers=10 --log-file=/tmp/vgdump.log
anaconda"
If that finds a problem and 10 callers is not enough to diagnose the issue,
repeat with --num-callers set to a higher value.
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=1823637
--- Comment #40 from Nicolas Mailhot <nicolas.mailhot(a)laposte.net> ---
Peng Wu,
Thank you for working on this.
If Medium has been abused as a Regular synonym in BDF files (to the point that
XLFD treats them the same) that is the correct thing to do *for* *BDF* *files*.
However, it is not sufficient to get a safe OpenType result.
Medium and Regular are most definitely *not* synonyms in the OpenType and CSS
specs.
And, because various generations of software will select fonts by Name *or*
Weight, or some mix of both (and various iterations of the CSS and OpneType
specs have encouraged one mode at the expense of the other, then changed their
mind), it is not sufficient to adjust Weight value only. You need to adjust the
Weight value *and* the style name and make sure they are coherent with one
another, or bad things will happen®.
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=1823637
Fedora Update System <updates(a)fedoraproject.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Fixed In Version|terminus-fonts-4.48-7.fc31 |terminus-fonts-4.48-7.fc31
| |terminus-fonts-4.48-7.fc32
--- Comment #39 from Fedora Update System <updates(a)fedoraproject.org> ---
terminus-fonts-4.48-7.fc32 has been pushed to the Fedora 32 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.
https://bugzilla.redhat.com/show_bug.cgi?id=1823637
Fedora Update System <updates(a)fedoraproject.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|ON_QA |CLOSED
Fixed In Version| |terminus-fonts-4.48-7.fc31
Resolution|--- |ERRATA
Last Closed| |2020-06-11 18:59:26
--- Comment #38 from Fedora Update System <updates(a)fedoraproject.org> ---
terminus-fonts-4.48-7.fc31 has been pushed to the Fedora 31 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.
https://bugzilla.redhat.com/show_bug.cgi?id=683325
--- Comment #24 from Andrew Travneff <travneff(a)gmail.com> ---
Still present for pidgin-2.13.0-18.fc32.x86_64
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=1647043
errata-xmlrpc <errata-xmlrpc(a)redhat.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Link ID| |Red Hat Product Errata
| |RHSA-2020:2485
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=1473715
--- Comment #25 from agents(a)meddatainc.com ---
This was not an upgrade but an installation on a new computer, hence I did not
access epel-release. This is what rpm -qa reports:
rpm -qa | grep fcitx
fcitx-pinyin-4.2.9.6-1.el7.x86_64
fcitx-data-4.2.9.6-1.el7.noarch
fcitx-table-4.2.9.6-1.el7.x86_64
fcitx-configtool-0.4.10-1.el7.x86_64
fcitx-4.2.9.6-1.el7.x86_64
fcitx-qt5-1.2.3-10.el7.x86_64
fcitx-gtk3-4.2.9.6-1.el7.x86_64
fcitx-qt4-4.2.9.6-1.el7.x86_64
fcitx-libs-4.2.9.6-1.el7.x86_64
fcitx-table-chinese-4.2.9.6-1.el7.noarch
fcitx-gtk2-4.2.9.6-1.el7.x86_64
Yet when I run fcitx-diagnose it reports fcitx 4.2.9.5? Unless I have made any
errors installing, I still have the same issue I reported earlier, ie choosing
another keyboard using the MATE keyboard switcher does not stick even in one
single application such as firefox, chromium. Hitting TAB in Firefox entry
fields switches me back to the default keyboard (I use RIGHT-CTRL+RIGHT-SHIFT
to switch among keyboards (two western ones and a Chinese keyboard layout),
CTRL-SPACE to switch between Pinyin and non-Pinyin. The Pinyin/non-Pinyin seems
to stick though between apps whereas switching the keyboard layout using the
RIGHT-CTRL+RIGHT-SHIFT switches back to the default keyboard when hitting ENTER
in chromium but remains when hitting ENTER in Firefox. Switching between
different entry fields in either switches me back to the default keyboard in
both apps.
So, to make a long story short, there might be two issues:
- fcitx-diagnose seems to reports fcitx 4.2.9.5 even though 4.2.9.6 is
installed. Can you confirm this?
- using the keyboard layout switcher in MATE does not seem to work as expected
in chromium and firefox (only apps I tried now) whereas it does seem to work
when switching between MATE terminals. Just tried firefox as well and Pinyin
switching seems OK here as well whereas keyboard layout switching using the
other keyboard combo gets lost when switching between different entry fields
etc.
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=1473715
--- Comment #24 from Robin Lee <robinlee.sysu(a)gmail.com> ---
Did you restart the desktop session after upgrade of fcitx?
--
You are receiving this mail because:
You are on the CC list for the bug.