https://bugzilla.redhat.com/show_bug.cgi?id=1923676
Bug ID: 1923676
Summary: emacs-lookup: FTBFS in Fedora rawhide/f34
Product: Fedora
Version: rawhide
Status: NEW
Component: emacs-lookup
Assignee: dueno(a)redhat.com
Reporter: releng(a)fedoraproject.org
QA Contact: extras-qa(a)fedoraproject.org
CC: dueno(a)redhat.com, i18n-bugs(a)lists.fedoraproject.org
Blocks: 1868278 (F34FTBFS)
Target Milestone: ---
Classification: Fedora
emacs-lookup failed to build from source in Fedora rawhide/f34
https://koji.fedoraproject.org/koji/taskinfo?taskID=60913717
For details on the mass rebuild see:
https://fedoraproject.org/wiki/Fedora_34_Mass_Rebuild
Please fix emacs-lookup at your earliest convenience and set the bug's status
to
ASSIGNED when you start fixing it. If the bug remains in NEW state for 8 weeks,
emacs-lookup will be orphaned. Before branching of Fedora 35,
emacs-lookup will be retired, if it still fails to build.
For more details on the FTBFS policy, please visit:
https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fails…
Referenced Bugs:
https://bugzilla.redhat.com/show_bug.cgi?id=1868278
[Bug 1868278] (F34FTBFS) - Fedora 34 FTBFS Tracker
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2035584
Bug ID: 2035584
Summary: IBus japanese input method, Anthy, doesn't show
suggestions as one types
Product: Fedora
Version: 35
Hardware: x86_64
OS: Linux
Status: NEW
Component: ibus-anthy
Assignee: tfujiwar(a)redhat.com
Reporter: sameyepatch(a)protonmail.com
QA Contact: extras-qa(a)fedoraproject.org
CC: i18n-bugs(a)lists.fedoraproject.org,
shawn.p.huang(a)gmail.com, tagoh(a)redhat.com,
tfujiwar(a)redhat.com
Target Milestone: ---
Classification: Fedora
Created attachment 1847739
--> https://bugzilla.redhat.com/attachment.cgi?id=1847739&action=edit
Difference between anthy & mozc
Description of problem:
Anthy doesn't show suggestions when typing. IBus-anthy preferences have been
kept as default since installed, and the "Candidate Window Page Size" setting
has 10, so it should suggest words as one types.
Mozc for IBus, on the other hand, does show candidates as intended.
Version-Release number of selected component (if applicable):
anthy-unicode-1.0.0.20201109-10.fc35.x86_64
ibus-anthy-python-1.5.13-3.fc35.noarch
ibus-anthy-1.5.13-3.fc35.x86_64
ibus-1.5.25-6.fc35.x86_64
How reproducible:
Always
Steps to Reproduce:
1. Enable IBus, and anthy in the IBus preferences as input method for Japanese
2. Switch to the Japanese IME then start typing in a window that expects an
input
Actual results:
Word suggestions don't appear below typed words, so there's no way to use words
with Kanji or Katakana, only Hiragana.
Expected results:
As one begins typing each word, suggestions should start appearing below that
can be navigated with the arrow keys and selected with the Intro key
Additional info:
Fedora Linux 35 (Xfce) x86_64
Kernel 5.15.10-200.fc35.x86_64
Xfce 4.16 Xfwm4
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2035584
https://bugzilla.redhat.com/show_bug.cgi?id=2031477
Bug ID: 2031477
Summary: ibus-mozc is not loaded automatically
Product: Fedora
Version: 35
OS: Linux
Status: NEW
Component: mozc
Severity: medium
Assignee: tagoh(a)redhat.com
Reporter: abetakehiko(a)gmail.com
QA Contact: extras-qa(a)fedoraproject.org
CC: i18n-bugs(a)lists.fedoraproject.org,
robinlee.sysu(a)gmail.com, tagoh(a)redhat.com,
tfujiwar(a)redhat.com
Target Milestone: ---
Classification: Fedora
Description of problem:
ibus-mozc is not loaded automatically after booting and logging in to Gnome.
Version-Release number of selected component (if applicable):
ibus-mozc-2.25.4190.102-7.fc35.x86_64
How reproducible:
Every boot and login.
Steps to Reproduce:
1. Reboot Fedora Gnome.
2. Login.
3. Select mozc from the input source selector.
Actual results:
The input source indicator is set to 'あ'. But the input source remains English.
(If ibus-kkc is present in the input source, kkc is activated instead of mozc.)
Expected results:
mozc is activated.
Additional info:
To activate mozc, I need to do either:
a). restart ibus-daemon.
b). activate emacs mozc inside emacs.
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2031477
https://bugzilla.redhat.com/show_bug.cgi?id=1993670
Bug ID: 1993670
Summary: segfault with pango-view assert in cairo
Product: Fedora
Version: 34
Hardware: x86_64
OS: Linux
Status: NEW
Component: pango
Severity: high
Assignee: pwu(a)redhat.com
Reporter: andre.maute(a)gmx.de
QA Contact: extras-qa(a)fedoraproject.org
CC: caillon+fedoraproject(a)gmail.com,
fonts-bugs(a)lists.fedoraproject.org,
gnome-sig(a)lists.fedoraproject.org,
i18n-bugs(a)lists.fedoraproject.org, mclasen(a)redhat.com,
pwu(a)redhat.com, rhughes(a)redhat.com,
rstrode(a)redhat.com, sandmann(a)redhat.com,
tagoh(a)redhat.com
Target Milestone: ---
Classification: Fedora
Description of problem:
1. This one works
$ pango-view --nodisplay --text "abc"
2. This one doesn't
$ pango-view --no-display --text "abc"
pango-view: cairo-hash.c:217: _cairo_hash_table_destroy: Assertion
`hash_table->live_entries == 0' failed.
Aborted (core dumped)
So pango-view triggers an assertion in Cairo.
Version-Release number of selected component (if applicable):
$ dnf repoquery --installed pango
pango-0:1.48.7-1.fc34.i686
pango-0:1.48.7-1.fc34.x86_64
How reproducible:
always
Steps to Reproduce:
1. see 1. of description above
2. see 2. of description above
Actual results:
segfault
Expected results:
no segfault
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=2029984
Bug ID: 2029984
Summary: Please branch and build libchewing in epel9
Product: Fedora EPEL
Version: epel9
Status: NEW
Component: libchewing
Assignee: robinlee.sysu(a)gmail.com
Reporter: tdawson(a)redhat.com
QA Contact: extras-qa(a)fedoraproject.org
CC: dchen(a)redhat.com, i18n-bugs(a)lists.fedoraproject.org,
robinlee.sysu(a)gmail.com
Target Milestone: ---
Classification: Fedora
Please branch and build libchewing in epel9.
If you do not wish to maintain libchewing in epel9,
or do not think you will be able to do this in a timely manner,
I would be happy to be a co-maintainer of the package.
I have tested and the rawhide package builds in EPEL9 without any changes.
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2029984
https://bugzilla.redhat.com/show_bug.cgi?id=2031877
Bug ID: 2031877
Summary: pango 1.50.0-1.fc35 makes darktable crash
Product: Fedora
Version: 35
Hardware: x86_64
OS: Linux
Status: NEW
Component: pango
Severity: low
Assignee: pwu(a)redhat.com
Reporter: thommy.m.malmstrom(a)gmail.com
QA Contact: extras-qa(a)fedoraproject.org
CC: caillon+fedoraproject(a)gmail.com,
fonts-bugs(a)lists.fedoraproject.org,
gnome-sig(a)lists.fedoraproject.org,
i18n-bugs(a)lists.fedoraproject.org, mclasen(a)redhat.com,
pwu(a)redhat.com, rhughes(a)redhat.com,
rstrode(a)redhat.com, sandmann(a)redhat.com,
tagoh(a)redhat.com
Target Milestone: ---
Classification: Fedora
Description of problem:
After a "sudo dnf upgrade --refresh" pango version 1.50.0-1.fc35 was installed.
Then darktable started to crash repeatedly.
Version-Release number of selected component (if applicable):
1.50.0-1.fc35
How reproducible:
Steps to Reproduce:
1. Start darktable
2. Try to do a crop&rotate
3.
Actual results:
darktable crashes
Expected results:
darktable to crop the image
Additional info:
I downgrade pango to previous version 1.49.1-1.fc35 and then darktable works as
expected.
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2031877
https://bugzilla.redhat.com/show_bug.cgi?id=2031525
Bug ID: 2031525
Summary: harfbuzz-3.2.0 is available
Product: Fedora
Version: rawhide
Status: NEW
Component: harfbuzz
Keywords: FutureFeature, Triaged
Assignee: pnemade(a)redhat.com
Reporter: upstream-release-monitoring(a)fedoraproject.org
QA Contact: extras-qa(a)fedoraproject.org
CC: i18n-bugs(a)lists.fedoraproject.org, klember(a)redhat.com,
moceap(a)hotmail.com, pnemade(a)redhat.com,
psatpute(a)redhat.com
Target Milestone: ---
Classification: Fedora
Latest upstream release: 3.2.0
Current version/release in rawhide: 3.1.2-1.fc36
URL: https://harfbuzz.github.io/
Please consult the package updates policy before you issue an update to a
stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/
More information about the service that created this bug can be found at:
https://fedoraproject.org/wiki/Upstream_release_monitoring
Please keep in mind that with any upstream change, there may also be packaging
changes that need to be made. Specifically, please remember that it is your
responsibility to review the new version to ensure that the licensing is still
correct and that no non-free or legally problematic items have been added
upstream.
Based on the information from Anitya:
https://release-monitoring.org/project/1299/
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2031525
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