https://bugzilla.redhat.com/show_bug.cgi?id=2368622
Bug ID: 2368622
Summary: ibus-daemon uses insane amounts of CPU and causes a
laggy experience
Product: Fedora
Version: 42
Hardware: x86_64
OS: Linux
Status: NEW
Component: ibus
Keywords: Desktop
Severity: high
Assignee: tfujiwar(a)redhat.com
Reporter: torvalds(a)linux-foundation.org
QA Contact: extras-qa(a)fedoraproject.org
CC: i18n-bugs(a)lists.fedoraproject.org, tfujiwar(a)redhat.com
Target Milestone: ---
Classification: Fedora
Not a lot of details here, but I decided that instead of just fixing it with
killall ibus-daemon
which gets rid of that broken thing, I would at least open a bug report to see
if there is some official fix for this.
Google shows a lot of people complaining about this going back years, so it's
not me.
There's no crash, and no obvious system logs either. All I see in system logs
is gdm-wayland-session activating, and when I kill it systemd seems to log
consumtion information like
org.freedesktop.IBus.session.GNOME.service: Consumed 26min 22.196s CPU
time, 125.1M memory peak.
(That was after the system had been up for one day, so 26 min of CPU time seems
pretty excessive)
Reproducible: Sometimes
Steps to Reproduce:
1. Boot the system
2. Be happy
3. Some time randomly later, notice laggy behavior and ibus-daemon using 100%
CPU in top
Actual Results:
Slow keyboard response on a fast system
Expected Results:
Snappy action
Additional Information:
Sorry for the horrible bug report, but can we please just disable ibus-daemon
by default as a useless problem-causing thing?
When google shows this problem going back AT LEAST to 2020 (and probably
longer), with the solution invariably being "kill, restart or disable
ibus-daemon to fix the problem temporarily", why is that thing enabled by
default in the first place?
Please at least give a good setting for this, so that the answer can be for
people to not enable that thing.
And if somebody has "please debug this next time it happens by doing Xyz", I'll
happily do that. But you need to tell me what Xyz is, because I don't know the
first thing about ibus-daemon.
I know that the "i" is supposed to stand for "intelligent". But honestly, I can
come up with a lot better suggestions for what that "i" might stand for. And
absolutely *none* of them are polite.
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2368622
Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla&format=report-sp…
https://bugzilla.redhat.com/show_bug.cgi?id=2062407
Bug ID: 2062407
Summary: msgfmt cannot invoke javac
Product: Fedora
Version: rawhide
Hardware: All
OS: Linux
Status: NEW
Component: gettext
Severity: low
Assignee: suanand(a)redhat.com
Reporter: loganjerry(a)gmail.com
QA Contact: extras-qa(a)fedoraproject.org
CC: dueno(a)redhat.com, i18n-bugs(a)lists.fedoraproject.org,
jjanco(a)redhat.com, nphilipp(a)redhat.com,
petersen(a)redhat.com, praiskup(a)redhat.com,
suanand(a)redhat.com
Target Milestone: ---
Classification: Fedora
Description of problem:
I noticed while building jmol that every invocation of msgfmt failed, e.g.:
update-application-catalog-lang:
[echo] msgfmt Updating messages_ar.class file for Jmol ...
[exec] msgfmt: Java compiler not found, try installing gcj or set $JAVAC
[exec] msgfmt: compilation of Java class failed, please try --verbose or
set $JAVAC
[exec] 65 translated messages, 3 fuzzy translations, 380 untranslated
messages.
[exec] Result: 1
Setting JAVAC does *not* help. I used strace to see how javac is invoked and
found the problem: msgfmt passes -target 1.6, and sometimes -source 1.6, to
javac. Now that OpenJDK 17 is the default in Fedora, those arguments are no
longer valid. I don't remember if the minimum allowed is 1.7 or 1.8, but it is
one of the two. Since Fedora doesn't ship a JDK lower than 1.8, then 1.8 might
as well be used.
Version-Release number of selected component (if applicable):
gettext-0.21-11.fc37.0.20220228
How reproducible:
Always
Steps to Reproduce:
1. fedpkg clone jmol
2. cd jmol
3. fedpkg srpm
4. mock -r fedora-rawhide-x86_64 --rebuild jmol-14.32.22-1.fc37.src.rpm
Actual results:
The msgfmt invocations all fail.
Expected results:
The msgfmt invocations should succeed.
Additional info:
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2062407
https://bugzilla.redhat.com/show_bug.cgi?id=2368701
Bug ID: 2368701
Summary: msgfmt: Java compiler not found, try installing gcj or
set $JAVAC
Product: Fedora
Version: rawhide
Hardware: x86_64
OS: Linux
Status: NEW
Component: gettext
Severity: high
Assignee: matiwari(a)redhat.com
Reporter: mail(a)tim-greller.de
QA Contact: extras-qa(a)fedoraproject.org
CC: dueno(a)redhat.com, i18n-bugs(a)lists.fedoraproject.org,
matiwari(a)redhat.com, nphilipp(a)redhat.com,
petersen(a)redhat.com, sundeep_anand(a)yahoo.com
Target Milestone: ---
Classification: Fedora
When I execute msgfmt with --java2, I get the following error:
msgfmt: Java compiler not found, try installing gcj or set $JAVAC
msgfmt: compilation of Java class failed, please try --verbose or set $JAVAC
--verbose only shows the additional line with x translated messages, ...
If I run javac -version, I get: javac 17.0.7
And for java -version, I get:
openjdk version "17.0.7" 2023-04-18
OpenJDK Runtime Environment (build 17.0.7+7-Debian-1deb11u1)
OpenJDK 64-Bit Server VM (build 17.0.7+7-Debian-1deb11u1, mixed mode, sharing)
As suggested in the error message, I tried setting $JAVAC. It's now set to
/usr/lib/jvm/java-17-openjdk-amd64/bin
but I still get the same error.
Reproducible: Always
Steps to Reproduce:
1. Create a de.po file (e.g. using xgettext and poedit)
2. Run msgfmt --java2 -d src/conf -r app.i18n.Messages -l de po/de.po
Actual Results:
msgfmt: Java compiler not found, try installing gcj or set $JAVAC
msgfmt: compilation of Java class failed, please try --verbose or set $JAVAC
Expected Results:
No error, but a ResourceBundle class
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2368701
Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla&format=report-sp…
https://bugzilla.redhat.com/show_bug.cgi?id=1658174
--- Comment #7 from fujiwara <tfujiwar(a)redhat.com> ---
(In reply to fujiwara from comment #1)
> > If the window is nearly an edge it may get moved because of the resizing.
>
> My suggestion was not to move the window when the cursor is moved in the
> same page even if the resize happens. But seems you found a case the window
> is moved.
> Could you give an example of a category and which emojis your cursor is over?
Probably I think this is the main issue for you.
I think now the position of the candidate popup is better fixed in Xorg and the
position is always center in GNOME Wayland so this can be closed?
(In reply to Jens Petersen from comment #4)
> Maybe by eliding some text if it is too long?
> It could be shown in a tooltip say.
The concept is to handle the popup with the keyboard shortcut only and the
popup also includes the tooltip function.
I think how to elide the number of the annotations is hard. E.g. the "crying"
annotation is located at the last order.
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=1658174
Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla&format=report-sp…