[Bug 2023222] New: ibus cannot open display via imsettings in Plasma
Wayland
by bugzilla＠redhat.com
https://bugzilla.redhat.com/show_bug.cgi?id=2023222
Bug ID: 2023222
Summary: ibus cannot open display via imsettings in Plasma
Wayland
Product: Fedora
Version: 35
Status: NEW
Component: imsettings
Assignee: tagoh(a)redhat.com
Reporter: tfujiwar(a)redhat.com
QA Contact: extras-qa(a)fedoraproject.org
CC: i18n-bugs(a)lists.fedoraproject.org, tagoh(a)redhat.com
Target Milestone: ---
Classification: Fedora
Description of problem:
im-chooser can launch imsettings-daemon and ibus-daemon and imsettings-daemon
launches ibus-daemon again when user log into the Plasma Wayland session but
ibus-ui-gtk3 fails to be launched because ibus-ui-gtk3 fails to open Display
with XOpenDisplay(NULL) via imsettings-daemon while I confirmed ibus-ui-gtk3
got DISPLAY=:0 environment variable.
If I invoke ibus-daemon by manual ibus-daemon can launch ibus-ui-gtk3
successfully so this issue would be imsettings in Plasma Wayland.
Version-Release number of selected component (if applicable):
imsettings-1.8.2-4.fc35.x86_64
ibus-1.5.25-4.fc35.x86_64
plasma-workspace-wayland-5.22.5-2.fc35.x86_64
How reproducible:
Steps to Reproduce:
1. Log into Plasma Wayland session
2. Run im-chooser and select IBus and ibus-daemon runs
3. Log out the session and imsettings-daemon is still running
4. Log into Plasma Wayland session again
or
5. Run im-chooser again and select IBus -> No input method -> IBus
Actual results:
ibus-ui-gtk3 and ibus-x11 are not running and no IBus panel icon in the Plasma
desktop
Expected results:
ibus-ui-gtk3 and ibus-x11 are running and users can switch IBus engines from
IBus panel icon in the Plasma desktop
Additional info:
I'm thinking to launch imsettings-daemon from
/usr/libexec/plasma-dbus-run-session-if-needed until Plasma Wayland can manage
IBus input contexts with D-Bus likes GNOME Wayland so I'm fine to terminate
imsettings-daemon by logging out the desktop session.
--- /usr/libexec/plasma-dbus-run-session-if-needed.orig07:11:14.936606871 +0900
+++ /usr/libexec/plasma-dbus-run-session-if-needed
@@ -2,6 +2,10 @@
# Usage: plasma-dbus-run-session-if-needed PROGRAM [ARGUMENTS]
# If the session bus is not available it is spawned and wrapper round our
program
# Otherwise we spawn our program directly
+if [ -x /usr/libexec/xinput-run-in-session ] ; then
+ nohup /usr/libexec/xinput-run-in-session &
+fi
+
drs=
if [ -z "${DBUS_SESSION_BUS_ADDRESS}" ]
then
# cat /usr/libexec/xinput-run-in-session
#!/bin/sh
# Wait for running a desktop session with D-Bus
sleep 180
if [ -x /etc/X11/xinit/xinitrc.d/50-xinput.sh ] ; then
/etc/X11/xinit/xinitrc.d/50-xinput.sh
ibus exit
imsettings-switch -n -q -x
fi
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2023222
2 years, 4 months
[Bug 2021739] New: no fonts available in this package
by bugzilla＠redhat.com
https://bugzilla.redhat.com/show_bug.cgi?id=2021739
Bug ID: 2021739
Summary: no fonts available in this package
Product: Fedora
Version: 35
Hardware: noarch
OS: Linux
Status: NEW
Component: japanese-bitmap-fonts
Assignee: tagoh(a)redhat.com
Reporter: takemurafedora(a)gmail.com
QA Contact: extras-qa(a)fedoraproject.org
CC: i18n-bugs(a)lists.fedoraproject.org, tagoh(a)redhat.com
Target Milestone: ---
Classification: Fedora
Description of problem:
The size of all the font files (*.pcf.gz) are only 20 bites which are gziped
empty files. fonts.dir shows the number of fonts included in the directory is
0.
Version-Release number of selected component (if applicable):
0.20080710-29.fc35
How reproducible:
always
Steps to Reproduce:
1. check to see the fonts that should be proveded with xfontsel, xlsfonts, etc.
2.
3.
Actual results:
No fonts are available.
Expected results:
Many japanese fonts should be availabe from X.
Additional info:
Rebuilding failed with "Missing build dependency: perl", as perl-interpreter
does not provides perl, but /usr/bin/perl.
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2021739
2 years, 4 months
[Bug 2026540] New: ibus should own /var/cache/ibus
by bugzilla＠redhat.com
https://bugzilla.redhat.com/show_bug.cgi?id=2026540
Bug ID: 2026540
Summary: ibus should own /var/cache/ibus
Product: Fedora
Version: 35
Status: NEW
Component: ibus
Assignee: tfujiwar(a)redhat.com
Reporter: petersen(a)redhat.com
QA Contact: extras-qa(a)fedoraproject.org
CC: i18n-bugs(a)lists.fedoraproject.org,
shawn.p.huang(a)gmail.com, tfujiwar(a)redhat.com
Target Milestone: ---
Classification: Fedora
Description of problem:
Currently it seems /var/cache/ibus is not owned by any package.
I guess it is created at install time or runtime by ibus write-cache.
So either ibus could just include the directly explicitly or
%ghost it, so that it would be owned.
See
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.o...
about unowned /var/cache/ dirs, which prompted this report.
Steps to Reproduce:
1. rpm -qf /var/cache/ibus
Actual results:
file /var/cache/ibus is not owned by any package
Expected results:
owned by ibus
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2026540
2 years, 4 months
[Fedora-i18n-bugs] [Bug 1919760] New: [abrt] ibus: invoke_get_property_in_idle_cb(): ibus-ui-gtk3 killed by SIGABRT
by bugzilla＠redhat.com
https://bugzilla.redhat.com/show_bug.cgi?id=1919760
Bug ID: 1919760
Summary: [abrt] ibus: invoke_get_property_in_idle_cb():
ibus-ui-gtk3 killed by SIGABRT
Product: Fedora
Version: 33
Hardware: x86_64
Status: NEW
Whiteboard: abrt_hash:1550d568515be5da0d8fa0ca9eb0b2e4d8db85bc;
Component: ibus
Assignee: tfujiwar(a)redhat.com
Reporter: alain.thiaville(a)sfr.fr
QA Contact: extras-qa(a)fedoraproject.org
CC: i18n-bugs(a)lists.fedoraproject.org,
shawn.p.huang(a)gmail.com, tfujiwar(a)redhat.com
Target Milestone: ---
Classification: Fedora
Version-Release number of selected component:
ibus-1.5.23-2.fc33
Additional info:
reporter: libreport-2.14.0
backtrace_rating: 4
cgroup:
0::/user.slice/user-1001.slice/user@1001.service/dbus\x2d:1.3\x2dcom.redhat.imsettings.slice/dbus-:1.3-com.redhat.imsettings@0.service
cmdline: /usr/libexec/ibus-ui-gtk3
crash_function: invoke_get_property_in_idle_cb
executable: /usr/libexec/ibus-ui-gtk3
journald_cursor:
s=9fdab79de00a4521972b23b84b3df8a6;i=9604;b=1a89d997ec324b54ade433d343bd315b;m=b4c8678a9;t=5b9b18c4cc4b5;x=749fe5d392007729
kernel: 5.10.9-201.fc33.x86_64
rootdir: /
runlevel: N 5
type: CCpp
uid: 1001
xsession_errors:
--
You are receiving this mail because:
You are on the CC list for the bug.
2 years, 4 months
[Fedora-i18n-bugs] [Bug 1910907] New: [abrt] ibus-kkc: gee_array_list_real_get(): ibus-engine-kkc killed by SIGABRT
by bugzilla＠redhat.com
https://bugzilla.redhat.com/show_bug.cgi?id=1910907
Bug ID: 1910907
Summary: [abrt] ibus-kkc: gee_array_list_real_get():
ibus-engine-kkc killed by SIGABRT
Product: Fedora
Version: 33
Hardware: x86_64
Status: NEW
Whiteboard: abrt_hash:88de9664ac0f50184e02ce3df98d857f4c9334f0;VAR
IANT_ID=workstation;
Component: ibus-kkc
Assignee: dueno(a)redhat.com
Reporter: ramot(a)ramottamado.dev
QA Contact: extras-qa(a)fedoraproject.org
CC: dueno(a)redhat.com, i18n-bugs(a)lists.fedoraproject.org
Target Milestone: ---
Classification: Fedora
Version-Release number of selected component:
ibus-kkc-1.5.22-14.fc33
Additional info:
reporter: libreport-2.14.0
backtrace_rating: 4
cgroup:
0::/user.slice/user-1000.slice/user@1000.service/session.slice/org.gnome.Shell@wayland.service
cmdline: /usr/libexec/ibus-engine-kkc --ibus
crash_function: gee_array_list_real_get
executable: /usr/libexec/ibus-engine-kkc
journald_cursor:
s=b9a02946f72241c5826b5804d8ded9b6;i=13b91a;b=f6f1121902224e3c95d41e6edabda311;m=72e3e2286;t=5b749367c7aab;x=4eeb00e5e71d231f
kernel: 5.9.14-200.fc33.x86_64
rootdir: /
runlevel: N 5
type: CCpp
uid: 1000
--
You are receiving this mail because:
You are on the CC list for the bug.
2 years, 4 months
[Fedora-i18n-bugs] [Bug 1919932] New: Culmus Hebrew fonts aren't usable by TeXLive after installation
by bugzilla＠redhat.com
https://bugzilla.redhat.com/show_bug.cgi?id=1919932
Bug ID: 1919932
Summary: Culmus Hebrew fonts aren't usable by TeXLive after
installation
Product: Fedora
Version: 33
Status: NEW
Component: culmus-fonts
Assignee: petersen(a)redhat.com
Reporter: nikita(a)leshenko.net
QA Contact: extras-qa(a)fedoraproject.org
CC: i18n-bugs(a)lists.fedoraproject.org,
petersen(a)redhat.com, pnemade(a)redhat.com,
psatpute(a)redhat.com, vishalvijayraghavan(a)gmail.com
Target Milestone: ---
Classification: Fedora
Created attachment 1750496
--> https://bugzilla.redhat.com/attachment.cgi?id=1750496&action=edit
Basic Hebrew document
Description of problem:
On a clean Fedora 33 after installing texlive, babel-hebrew, and
tex-fonts-hebrew, I
can't use pdflatex to render a Hebrew document. Detailed steps to reproduce and
a possible fix are provided below.
Version-Release number of selected component (if applicable):
texlive 9:2020-34.fc33
texlive-babel-hebrew 9:svn30273.2.3h-34.fc33
tex-fonts-hebrew 0.1-33.fc33
How reproducible: Always
Steps to Reproduce:
1. Start a new Fedora 33 container: podman run -it fedora:33
2. dnf install texlive texlive-babel-hebrew tex-fonts-hebrew
3. Try to render hello.tex document attached to this bug report (this is a
basic
Hebrew document).
\documentclass{article}
\usepackage[utf8x]{inputenc}
\usepackage[english,hebrew]{babel}
\begin{document}
שלום!
\end{document}
Actual results:
We get the following error message:
!pdfTeX error: pdflatex (file rdavid): Font rdavid at 600 not found
==> Fatal error occurred, no output PDF file produced!
Full log is at first.log.
Expected results:
Document is rendered :)
Additional info:
We need two steps to resolve the problem here. I'm not sure if these steps are
the idiomatic way to fix the issue, but it worked for me...
The first issue that that culmus.map is not included in the pdflatex.map, even
though culmus.map is enabled in /etc/texlive/web2c/updmap.cfg. I was able to
solve it with
- updmap-sys --syncwithtrees
- updmap-sys
to recreate the map file. It would be nice the Culmus will do this by default
as
part of the installation. (Another temporary per-document solution is to add
\pdfmapfile{culmus.map} to the Hebrew document.)
Now if we re-run pdflatex we get a new error:
!pdfTeX error: pdflatex (file DavidCLM-Medium.pfa): cannot open Type 1 font
file for reading
==> Fatal error occurred, no output PDF file produced!
The full log is in second.log.
There are multiple ways around this problem:
1. Note that /usr/share/texmf/fonts/type1/public/ has a broken symlink to
culmus. Even if we fix the symlink to point to /usr/share/fonts/culmus/, it
doesn't work because pdflatex doesn't seem to follow directory symlinks. But
if we actually create a directory and symlink fonts individually, it will
work, like this:
mkdir /usr/share/texmf/fonts/type1/public/culmus2
for i in /usr/share/fonts/culmus/*; do ln $i
/usr/share/texmf/fonts/type1/public/culmus2/${i##*/}; done
2. A more "general" fix is to edit /etc/texlive/web2c/texmf.cnf instead and set
OSFONTDIR to /usr/share/fonts/, but it seems like this change extends beyond
Culmus so I'm not sure how practical is it to edit OSFONTDIR as part of
installation.
After building the map file and teaching latex to find Type1 Culmus fonts the
Hebrew document can compile successfully.
I hope that it will be possible to adjust the Culmus package so that Hebrew
latex works out of the box.
Thanks! I'm available for questions and clarifications.
--
You are receiving this mail because:
You are on the CC list for the bug.
2 years, 4 months