Bug#1057628: im-config: support zsh as login shell and wayland env

[Gunnar Hjalmarsson]

On 2023-12-06 05:53, YunQiang Su wrote:

1. For wayland, gnome-session use $SHELL to restart.
https://salsa.debian.org/gnome-team/gnome-session/-/commit/5fee64f74925291f211f289dcfb3f1cf522c1546
2. im-config contains a file: /etc/profile.d/im-config_wayland.sh
to start input method in wayland env.
3. If zsh is set to login shell, the input method won't start,
since zsh doesn't use /etc/profile.


Please put a symlink of /etc/profile.d/im-config_wayland.sh
to /etc/zsh/zlogin.d/im-config_wayland.sh


Thanks for your report! Your proposal makes sense to me if 
<https://bugs.debian.org/1057627> gets fixed as suggested.


--
Cheers,
Gunnar Hjalmarsson

Bug#1057627: zsh: add /etc/zsh/zlogin.d directory

[Gunnar Hjalmarsson]

Related bugs:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=776663

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=983116

Bug#1051243: tex-common: fmtutil failed on tex-common upgrade

[Gunnar Hjalmarsson]

X-Debbugs-Cc: debian-input-met...@lists.debian.org

On 2023-11-18 21:20, Gunnar Hjalmarsson wrote:
This problem prevents the ibus-table package, where tex-common is 
indirectly in Build-Depends, from building in unstable.


https://buildd.debian.org/status/logs.php?pkg=ibus-table=1.17.4-2=all


FTR I can confirm that the latest version of texlive-bin fixed that 
problem, and ibus-table has been successfully built now.


--
Gunnar

Bug#1051243: tex-common: fmtutil failed on tex-common upgrade

[Gunnar Hjalmarsson]

Control: affects -1 ibus-table
Control: severity -1 serious
X-Debbugs-Cc: debian-input-met...@lists.debian.org

This problem prevents the ibus-table package, where tex-common is 
indirectly in Build-Depends, from building in unstable.


https://buildd.debian.org/status/logs.php?pkg=ibus-table=1.17.4-2=all

I haven't been able to reproduce the failure locally, and ibus-table 
builds successfully in Ubuntu:


https://launchpad.net/ubuntu/+source/ibus-table/1.17.4-1

I'm aware of the case where fmtutil failed under a broken locale, but 
that does reasonably not apply when building for unstable.


debian/postinst includes this line:

FMTUTIL="fmtutil --sys --strict 
--no-error-if-no-engine=luajittex,mfluajit,luajithbtex"


One thought is to replace "--strict" with "--no-strict" as a workaround 
while awaiting a proper fix. That idea is untested, though.


--
Cheers,
Gunnar Hjalmarsson

Bug#1054622: im-config: can set GTK_IM_MODULE to xim, which causes GTK 4 to complain

[Gunnar Hjalmarsson]

On 2023-10-26 23:51, brian m. carlson wrote:

I have a system with Zoom installed, which necessitates installing
ibus, which I don't want to use (because it overrides my shortcut
keys without consent).  Thus, the advice I've received is to install
im-config and use to set the module to "xim".


That's bad advice. Where did you get it?

Don't set it to "xim", set it to "none" instead, which means that 
im-config does not touch any environment variables (and does not launch 
ibus-daemon).


im-config -n none


I don't think, given that GTK+ 4 is used for a wide variety of
software in Debian, that it's safe to set GTK_IM_MODULE to "xim"
anymore, and im-config needs to not do that.


Your observation is not a sufficient reason to conclude that "xim" is 
never useful and should be removed as an option. im-config does not set 
that option automatically, but only if the user chooses it explicitly. 
In your case due to a bad advice. ;)


So I'm inclined to close this bug as a "wontfix", but await possible 
further input on the matter.


--
Cheers,
Gunnar Hjalmarsson

Bug#1052502: ibus crashed and refuses to restart

[Gunnar Hjalmarsson]

Control: tags -1 + moreinfo

Hi Nicolas,

Since you are on LXDE it's not clear to me why you use IBus at all. You 
don't need IBus to use dead keys and a compose key.


If you run

im-config -n none

and reboot, you will enter a session without ibus-daemon running and 
without environment variables telling your apps to use IBus.


Can you please try that and let us know if you are able to make sense of 
your keyboard that way.


--
Rgds,
Gunnar Hjalmarsson

Bug#1053242: ibus: Keyboard input gets jumbled when typing fast

[Gunnar Hjalmarsson]

Control: tags -1 + bookworm
Control: fixed -1 ibus/1.5.28-6
Control: severity -1 wishlist

Hi Billy,

On 2023-09-29 22:23, Billy Croan wrote:

I am requesting a backport of ibus' fix to stable/bookworm:
https://github.com/ibus/ibus/pull/2532/commits


There have been quite a few improvements between ibus 1.5.27-5 in 
bookworm and 1.5.29~rc1-1 in trixie, and I think a backport to bookworm 
would be a reasonable measure. That would include many other things 
besides the PR you mention.


I prepared such an upload here:

https://salsa.debian.org/debian/ibus/-/commits/bookworm-bpo

I have successfully used that branch to build and install ibus locally 
in Debian 12 (amd64), and confirmed with some basic checks that it runs 
as expected. If you know how to build, it would be good if you too could 
build and test it.


--
Rgds,
Gunnar Hjalmarsson

Bug#1052005: KDE Plasma with IBus: im-config changes needed

[Gunnar Hjalmarsson]

Package: im-config
Version: 0.57-2
Severity: important

If you use IBus in a Plasma (Wayland) session, the intention seems to be 
that you apply an "IBus Wayland" virtual keyboard and let Wayland handle 
everything internally. Otherwise the suggestion window does not show up, 
for instance. OTOH, with the virtual keyboard enabled im-config should 
better be disabled.


In a Plasma (X11) session im-config keeps dealing with IBus as intended.

Probably we should change im-config so it doesn't do anything in case of 
a Plasma (Wayland) session. However, during my tests things get 
extremely slow with that "IBus Wayland" virtual keyboard enabled, which 
may be a bug or a "user error" from my side.


In any case it's highly desirable that any changes are made in 
consultation with somebody who actually uses IBus together with Plasma.


--
Gunnar Hjalmarsson

Bug#1051707: [INTL:es] Spanish translation of fontconfig debconf template

[Gunnar Hjalmarsson]

Thanks for your update!

Due to this revert:

https://salsa.debian.org/freedesktop-team/fontconfig/-/commit/f35af06b

I only kept the typo correction part of your change:

https://salsa.debian.org/freedesktop-team/fontconfig/-/commit/20b04fea

Sorry for the noise.

--
Gunnar Hjalmarsson

Bug#1051314: fonts-recommended: recognise noto-core as alternative to dejavu-core

[Gunnar Hjalmarsson]

On 2023-09-10 13:53, Adam Borowski wrote:

On Sat, Sep 09, 2023 at 11:24:04PM +0200, Gunnar Hjalmarsson wrote:

After our conversation I made two installs for test purposes:

1. Debian 12 with GNOME
Result: fonts-noto-core was not included by default.

2. Debian trixie with GNOME
Result: fonts-noto-core was included by default.

I suspect that the change can be explained by this commit:
https://salsa.debian.org/freedesktop-team/fontconfig/-/commit/5aa10dde


There's a lot of Debian outside GNOME -- and in fact, if you are already
using their metapackages, you don't need more.  I'd prefer for non-GNOME
metapackages to be universal, and thus what a particular desktop already
depends or does not depend on is not a concern for me.


I used GNOME as an example, since we had talked about the GNOME desktop 
at the debian-l10n-english mailing list.


I installed Debian trixie again, but chose Xfce this time instead of 
GNOME. fonts-noto-core is there.


$ fc-match
NotoSans-Regular.ttf: "Noto Sans" "Regular"

And fonts-dejavu-core is *not* there. The task-* meta packages are 
apparently of limited importance in this context, at least for latin 
scripts.


So the linked fontconfig change seems to affect the whole Debian 
irrespective of desktop environment. fontconfig-config is included in 
the base install, before the desktop components are selected and installed.



Alas, noto has the downside of making font pickers next to useless,
as it declares every single of languages it supports as a separate
font family. So instead off just "Noto Sans" "Noto Mono" "Noto
Slightly Serifed", you have "Noto Western Klingon" "Noto Eastern
Klingon" and so on, making the list of available fonts one big noto
fest.


If you assume that users often want to change much, I can understand that
you see that as a disadvantage. OTOH, a user who wants to do it differently
can uninstall fonts-noto-core and with that get a significantly shorter
list.


Noted.  You don't care about fonts just whether a particular character is
covered, me and other people in the Fonts Team obviously have more interest
in distinct fonts.  That's the diff between eg. linguists vs layout
designers, different people have different priorities.


True. Personal preferences play an important role, and discussions on 
this topic tend to be complex for that reason.



https://lists.debian.org/debian-devel/2023/09/msg00053.html


I'm behind reading mailing lists, but I agree 100% with what other members
of the Fonts Team said.  Noto is ugly, a bit too disk heavy for 60% of
keyboard-attached boxen I use, and pollutes font lists too much.


Noted. I will post to debian-devel soon again with some clarifications. 
The initial reactions are not overwhelmingly positive. :/



Besides, Noto can be said to be a metapackage by itself, providing a large
set of fonts -- even if it claims to be a single font, it presents hundreds
of them to the system and UI interfaces.


That's entirely a result of the way the Noto fonts are packaged in 
Debian, and not something that should be attributed to Noto itself. 
Discussed at https://bugs.debian.org/983291 .


--
Gunnar

Bug#1051314: fonts-recommended: recognise noto-core as alternative to dejavu-core

[Gunnar Hjalmarsson]

Adam Borowski wrote:

On Wed, Sep 06, 2023 at 07:22:36AM +0100, Justin B Rye wrote:

Various major desktops now default to fonts-noto-core instead of
fonts-dejavu-core.   During a conversation with a
fontconfig-config maintainer on debian-l10n-english about the
knock-on effects
("https://lists.debian.org/debian-l10n-english/2023/09/msg1.html;)
I noticed that the dependency chains ensuring that fonts-noto-core
is actually installed at all are surprisingly weak.


After our conversation I made two installs for test purposes:

1. Debian 12 with GNOME
   Result: fonts-noto-core was not included by default.

2. Debian trixie with GNOME
   Result: fonts-noto-core was included by default.

I suspect that the change can be explained by this commit:
https://salsa.debian.org/freedesktop-team/fontconfig/-/commit/5aa10dde


Alas, noto has the downside of making font pickers next to useless,
as it declares every single of languages it supports as a separate
font family. So instead off just "Noto Sans" "Noto Mono" "Noto
Slightly Serifed", you have "Noto Western Klingon" "Noto Eastern
Klingon" and so on, making the list of available fonts one big noto
fest.


If you assume that users often want to change much, I can understand 
that you see that as a disadvantage. OTOH, a user who wants to do it 
differently can uninstall fonts-noto-core and with that get a 
significantly shorter list.


Myself is involved in changing the default selection of fonts and font 
configuration for Ubuntu. In that context we focus on offering the users 
a sensible default, which most users are comfortable with, and the way 
Noto provides different fonts for different scripts and purposes is an 
advantage to achieve that. Ubuntu is about to prefer Noto for most 
scripts, but to the extent exceptions proves to be motivated, that can 
be handled relatively easy via font configuration. Something that would 
have been harder with DejaVu Sans as the preferred font.



I have no firm opinion, at least not yet, on the role of 
fonts-recommended and whether the proposed change is motivated. But I 
just posted a list message about the ongoing transition from DejaVu to 
Noto, to reach a broader audience:


https://lists.debian.org/debian-devel/2023/09/msg00053.html

Do feel encouraged to respond to it.

--
Cheers,
Gunnar Hjalmarsson

Bug#978401: ibus-libpinyin: FTBFS on armel, armhf and mipsel: lua test failure

[Gunnar Hjalmarsson]

At last lua5.4 is included in Ubuntu's main, so I'm preparing the source 
for being suitable for Ubuntu to sync.


* As a first step I tried an upload to experimental with lua support 
enabled on all archs. So far it has refused to build on the particular 
archs I'm interested in (armhf and armel), though.


* If it would fail on any of those archs, I plan to enable LTO in the 
package. The rationale for that is that it builds fine in Ubuntu on 
armhf also with lua5.4 support, and Ubuntu builds with LTO enabled.


* As a last resort, if the armhf build still fails due to lua, I'm 
thinking of a conditional in d/rules rather than changing b-d in 
d/control, so we can distinguish between Debian and Ubuntu in this respect.


Please let me know if you have any doubts.

--
Gunnar

Bug#1050660: fontconfig-config: dangling symlink /etc/fonts/conf.d/10-no-sub-pixel.conf

[Gunnar Hjalmarsson]

On 2023-09-01 20:29, Gunnar Hjalmarsson wrote:

I have submitted this merge request:

https://salsa.debian.org/freedesktop-team/fontconfig/-/merge_requests/12

While it doesn't remove the obsolete symlink, it ought to create the
correct symlink going forward.


After some additions to the MR, it now does both.

--
Gunnar

Bug#1050660: fontconfig-config: dangling symlink /etc/fonts/conf.d/10-no-sub-pixel.conf

[Gunnar Hjalmarsson]

Jörg-Volker Peetz wrote:

the removal of /usr/share/fontconfig/conf.avail/10-no-sub-pixel.conf
left a dangling symlink:

/etc/fonts/conf.d/10-no-sub-pixel.conf


Thanks for your report! This commit:

https://gitlab.freedesktop.org/fontconfig/fontconfig/-/commit/030759b7

includes a filename change from 10-no-sub-pixel.conf to 
10-sub-pixel-none.conf. These files:


debian/fontconfig-config.config
debian/fontconfig-config.postinst
debian/fontconfig-config.postrm

include the old name, so there is indeed a need to adapt to the name 
change. And I suspect that your observation is a result of my omission 
to adjust it when upgrading to fontconfig 2.14.2.


I have submitted this merge request:

https://salsa.debian.org/freedesktop-team/fontconfig/-/merge_requests/12

While it doesn't remove the obsolete symlink, it ought to create the 
correct symlink going forward.


--
Rgds,
Gunnar Hjalmarsson

Bug#1042513: fontconfig-config: wrong advice from dpkg-reconfigure

[Gunnar Hjalmarsson]

Control: tags -1 + pending

Thanks for your report!

I pushed a commit where I dropped the "(the default in Debian)" part:

https://salsa.debian.org/freedesktop-team/fontconfig/-/commit/45d8eda0

I consider a possible rewrite of the advice in other respects a separate 
thing. That would require a font expert (which I am not).


--
Cheers,
Gunnar Hjalmarsson

Bug#1040802: xkb-data: Breaks altgr in Norwegian layout

[Gunnar Hjalmarsson]

On 2023-08-28 13:42, Tollef Fog Heen wrote:

]] Gunnar Hjalmarsson


What's the output of this command:

gsettings get org.gnome.desktop.input-sources xkb-options


$ gsettings get org.gnome.desktop.input-sources xkb-options
['compose:caps', 'compose:caps', 'grp:alts_toggle', 'lv3:ralt_switch']


Then run this command:

gsettings set org.gnome.desktop.input-sources xkb-options "['compose:caps']"

Bug#1040802: xkb-data: Breaks altgr in Norwegian layout

[Gunnar Hjalmarsson]

What's the output of this command:

gsettings get org.gnome.desktop.input-sources xkb-options

Bug#1040802: xkb-data: Breaks altgr in Norwegian layout

[Gunnar Hjalmarsson]

Hi again,

On 2023-08-28 06:28, Tollef Fog Heen wrote:

]] Gunnar Hjalmarsson

I can't help asking why you set the "group(alts_toggle)" option at
all. You don't seem to use any other keyboard layout but Norwegian
anyway. So even before you have answered, my advice would be to just
drop that option wherever you set it and move on. ;)


I'm not setting it intentionally, but I suspect somewhere in the xkb
stack.  If I choose just Norwegian as my layout in gnome control center,
I get:

$ setxkbmap -print
xkb_keymap {
 xkb_keycodes  { include "evdev+aliases(qwerty)" };
 xkb_types { include "complete"  };
 xkb_compat{ include "complete"  };
 xkb_symbols   { include 
"pc+no+us:2+inet(evdev)+level3(ralt_switch)+compose(caps)+group(alts_toggle):1+group(alts_toggle):2"
   };
 xkb_geometry  { include "pc(pc105)" };
};

Which looks pretty bizarre to me, and I have no idea what «us» does
there.


Don't worry about 'us' — it's always there as some sort of default.

But you must have set that group(alts_toggle) option somewhere, and on a 
Debian system the /etc/default/keyboard file is a suspect.


Otherwise it may depend on which desktop environment you use. You never 
told us that, did you?


--
Gunnar

Bug#1040802: xkb-data: Breaks altgr in Norwegian layout

[Gunnar Hjalmarsson]

Control: severity -1 normal
Control: tags -1 + moreinfo

Thanks for your report!

Tollef Fog Heen wrote:

With commit 0fb34101788d84e9a1d98b3730cc7b9295e0f19b in
xkeyboard-config, `group(alts_toggle)` changed behaviour in a way
such that the right alt no longer generates altgr.


Apparently the purpose of the change was to make the "Both Alts" 
shortcut work again, after a long period when it didn't work.


https://salsa.debian.org/xorg-team/data/xkeyboard-config/-/commit/0fb34101

And in a working state, I'm not surprised to hear that "Both Alts" 
conflicts with the use of Right Alt for accessing 3rd and 4th level symbols.


I can't help asking why you set the "group(alts_toggle)" option at all. 
You don't seem to use any other keyboard layout but Norwegian anyway. So 
even before you have answered, my advice would be to just drop that 
option wherever you set it and move on. ;)


In any case the issue is not severity "serious", especially not in a 
Debian distro context.


--
Regards,
Gunnar Hjalmarsson

Bug#1049135: m17n-db: Fails to build source after successful build

[Gunnar Hjalmarsson]

Control: tags -1 + pending

Fixed in repo:

https://salsa.debian.org/input-method-team/m17n-db/-/commit/d283ffbf

Bug#1048110: sunpinyin: Fails to build source after successful build

[Gunnar Hjalmarsson]

Control: tags -1 + pending

Fixed in repo:

https://salsa.debian.org/debian/sunpinyin/-/commit/aaef82a5

Bug#1047346: ibus-table-chinese: Fails to build source after successful build

[Gunnar Hjalmarsson]

Control: tags -1 + pending

Fixed in repo:

https://salsa.debian.org/input-method-team/ibus-table-chinese/-/commit/3d8e4789

Bug#1050410: gcin: Can't access KDE after installing gcin and hime on Debian 12.

[Gunnar Hjalmarsson]

On 2023-08-24 18:22, zendas wrote:

Dear Gunnar Hjalmarsson,

Thank you for your prompt response regarding the GCIN error. I have
followed the instructions provided in your email and manually
executed the necessary steps. As a result, I have collected some log
and record information that might help in diagnosing the issue.

Please find the attached document which contains the detailed records
and logs. I hope this information will assist in resolving the GCIN
error swiftly.

I appreciate your continuous support and assistance. Please let me
know if you require any additional information or if there are
further steps I should take.

Thank you and looking forward to your feedback.


Thanks for the log snippets! While they might be useful, my technical 
skill is not sufficient to make sense of them. Hopefully some more 
experienced developer chimes in.


But in any case we should try to narrow the scope of this bug report. 
First, let's focus on gcin (which this bug was reported against) and 
leave hime aside for now.


As regards gcin I can trigger a segfault when playing around in Debian 
testing. It segfaults for me in Wayland sessions:


$ env | grep -i type
XDG_SESSION_TYPE=wayland
$ gcin &
[1] 2567
$ ^C
[1]+  Segmentation fault  (core dumped) gcin
$

But not in X11 sessions:

$ env | grep -i type
XDG_SESSION_TYPE=x11
$ gcin &
[1] 2565
$ ^C
$

And rebuilding gcin does not help against the segfault on Wayland.

But I still do not understand how it prevents you from being able to log 
in to the session.


So in the light of that I have some specific questions:

1. Is it in Plasma (Wayland) sessions you observe the issues?

2. Does gcin work as expected if you log in to a Plasma (X11) session 
instead?


3. Which display manager do you use? (I used sddm when testing.)

--
Rgds,
Gunnar(gcin:1283): GLib-GObject-WARNING **: 00:07:31.783: invalid cast from 
'GdkWaylandDisplay' to 'GdkX11Display'
程式記憶體區段錯誤 (核心已傾印)
[5.411281] kauditd_printk_skb: 14 callbacks suppressed
[5.411284] audit: type=1400 audit(1692893581.151:25): apparmor="DENIED" 
operation="capable" profile="/usr/sbin/cupsd" pid=672 comm="cupsd" 
capability=12  capname="net_admin"
[5.412992] NET: Registered PF_QIPCRTR protocol family
[5.675424] e1000: ens33 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: 
None
[5.684463] IPv6: ADDRCONF(NETDEV_CHANGE): ens33: link becomes ready
[6.354811] vmwgfx :00:0f.0: [drm] Using CursorMob mobid 3, max 
dimension 2048
[6.358025] vmwgfx :00:0f.0: [drm] Using CursorMob mobid 4, max 
dimension 2048
[   19.498707] input: VMware DnD UInput pointer as /devices/virtual/input/input7
[   30.495969] gcin[1279]: segfault at 55848f4a2970 ip 55a83be06055 sp 
7ffc49ac6160 error 4 in gcin[55a83be04000+3] likely on CPU 0 (core 0, 
socket 0)
[   30.495982] Code: 00 e8 ef e9 ff ff 48 89 c7 e8 e7 f5 ff ff 48 89 c2 48 89 
05 e5 2b 04 00 48 63 80 e0 00 00 00 48 c1 e0 07 48 03 82 e8 00 00 00 <48> 8b 40 
10 48 89 05 e8 2b 04 00 b8 00 00 00 00 e8 de fd ff ff e8
Hint: You are currently not seeing messages from other users and the system.
  Users in groups 'adm', 'systemd-journal' can see all messages.
  Pass -q to turn off this notice.
   PID: 1283 (gcin)
   UID: 1000 (zendas)
   GID: 1000 (zendas)
Signal: 11 (SEGV)
 Timestamp: Fri 2023-08-25 00:07:31 CST (6min ago)
  Command Line: gcin
Executable: /usr/bin/gcin
 Control Group: 
/user.slice/user-1000.slice/user@1000.service/app.slice/app-org.kde.konsole-086cf5af2cba4655a9e0bdc56020187d.scope
  Unit: user@1000.service
 User Unit: app-org.kde.konsole-086cf5af2cba4655a9e0bdc56020187d.scope
 Slice: user-1000.slice
 Owner UID: 1000 (zendas)
   Boot ID: 97ac1ee1e63340afb8897e43a2c9907c
Machine ID: ebc50bcff6434971bf6f226dd3ff2113
  Hostname: debian
   Storage: 
/var/lib/systemd/coredump/core.gcin.1000.97ac1ee1e63340afb8897e43a2c9907c.1283.169289325100.zst
 (present)
  Size on Disk: 843.9K
   Message: Process 1283 (gcin) of user 1000 dumped core.

Module libsystemd.so.0 from deb systemd-252.12-1~deb12u1.amd64
Stack trace of thread 1283:
#0  0x562d5c4e3055 n/a (gcin + 0xd055)
#1  0x7f60ae96a1ca n/a (libc.so.6 + 0x271ca)
#2  0x7f60ae96a285 __libc_start_main (libc.so.6 + 0x27285)
#3  0x562d5c4e2731 n/a (gcin + 0xc731)

Stack trace of thread 1284:
#0  0x7f60aea3f03f __poll (libc.so.6 + 0xfc03f)
#1  0x7f60aed999ae n/a (libglib-2.0.so.0 + 0x549ae)
#2  0x7f60aed99acc g_main_context_iteration 
(libglib-2.0.so.0 + 0x54acc)
#3  0x7f60aed99b11 n/a (libglib-2.0.so.0 + 0x54b11)
#4  0x7f60aedc3cfd n/a (libglib-2.0.so.0 + 0x7ecfd)
#5  0x7f60ae9cc044 n/

Bug#1050410: gcin: Can't access KDE after installing gcin and hime on Debian 12.

[Gunnar Hjalmarsson]

Control: tags -1 + moreinfo

Thanks for your report.

I used my Kubuntu 23.04 installation to test, but neither with gcin nor 
hime I could reproduce the problem with not being able to enter the 
Plasma session.


I did encounter a problem with gcin refusing to start in Plasma 
(Wayland), but that's a separate thing which is said to be fixed in 
Debian 12.


So since the issue you reported is not easily reproducible, we need more 
info to be able to address this bug report. Are you able to provide a 
log file showing a failed login attempt?


Another thing is that you can run:

im-config -n none

and with that prevent im-config from automatically starting and 
configuring gcin or hime at login. Doing so should reasonably allow you 
to log in and study what happens when you try to start gcin/hime manually.


--
Regards,
Gunnar Hjalmarsson

Bug#1028897: fontconfig: wrong name for the Noto monospace font

[Gunnar Hjalmarsson]

On 2023-08-21 08:52, fab...@greffrath.com wrote:

However, we, in Debian, as a distribution, have all the rights to aim
for the most aesthetically pleasing view of our default installation
and thus I support the change back to DejaVu Sans Mono as the default
monospace font. This, and we already support a localized
installation and install some additional font packages based on the
locale set during D-I. So, in the end, we always end up with more
than just the default font, and thus can prefer one that "looks
better" and gets supported by other fonts for additional glyph
coverage.


Thanks for your comment, Fabian. Since you have managed font packages in 
Debian for several years, your blessing of the change is important to 
me. The quoted part above put it into context.


--
Cheers,
Gunnar

Bug#1028897: fontconfig: wrong name for the Noto monospace font

[Gunnar Hjalmarsson]

On 2023-08-20 21:34, Raphaël Halimi wrote:

As I understand it, this will make fontconfig select DejaVu Sans Mono
on most desktop installations (since libreoffice depends on both
sets), and Noto Mono on a handful of installations, namely, minimal
installations which will have only fonts-noto-{core,mono} installed,
and not fonts-dejavu-{core,mono}.


That's my understanding too.


Thus, the default font for the "Monospace" alias will depend on the
installed packages.


That's always the case, isn't it? The output of "fc-match" or "fc-match 
mono" depends on a combo of available fonts and the font configuration.


As an example, and since I work with Ubuntu as well, Ubuntu 23.04 also 
has fontconfig 2.14, but most users haven't noticed since 
fonts-noto-core is not installed by default (neither is the libreoffice 
binary, which explains the difference to Debian in this respect). Ubuntu 
23.10 will include fonts-noto-core, though, so there is an ongoing work 
with deciding both the set of pre-installed font packages and possible 
adjustments of the configuration.



I'm okay with that.


Good. :)


Thanks for fixing it :)


N.p.


Yes, let's see what users think of the change. I have good hope that
most people will be satisfied.


Let's keep our fingers crossed.

/ Gunnar

Bug#1028643: fontconfig: default latin fonts changed from DejaVu to Noto

[Gunnar Hjalmarsson]

I think this change:

https://salsa.debian.org/freedesktop-team/fontconfig/-/commit/6fae069d

is relevant to this discussion.

--
Cheers,
Gunnar Hjalmarsson

Bug#1044293: fontconfig: Fails to build source after successful build

[Gunnar Hjalmarsson]

Control: tags -1 + pending

Fixed in repo:

https://salsa.debian.org/freedesktop-team/fontconfig/-/commit/409318ef

Bug#1028897: fontconfig: wrong name for the Noto monospace font

[Gunnar Hjalmarsson]

Control: owner -1 gunna...@debian.org
Control: tags -1 + pending

On 2023-08-19 17:01, Raphaël Halimi wrote:

Le 19/08/2023 à 16:04, Gunnar Hjalmarsson a écrit :

It's worth mentioning that the fonts-noto packages in Debian ship
almost 3 years old fonts. An update to latest upstream would be
highly desirable. Possibly Noto Sans Mono has improved.


I didn't know that. Thanks for mentioning it.

So, I just downloaded NotoSansMono-Regular.ttf from its new home [1]
(the old repository in the Debian copyright file has been archived),
opened it in font-viewer and... Sadly, the spacing is still
"Proportional" and not "Monospace" :(


Thanks for doing that. So we will probably need to live with it for the 
foreseeable future. And yes, it's a bit sad.


Anyway, I'm now convinced that the status of Noto Sans Moto motivates a 
change of the default monospace font in Debian. Well, you and I haven't 
agreed on what to put there instead, so how about a compromise where we 
pick both? :)


https://salsa.debian.org/freedesktop-team/fontconfig/-/commit/6fae069d

While I still hesitate, since the change affects so many users, I have 
decided to act. After all we are in the beginning of the trixie 
development cycle, so there is plenty of time to change it later. By 
making the change in unstable and testing, we expose it to the users. 
Many will probably not even notice and some will like it. And if some 
users disapprove of the change, the broader discussion we haven't had 
may happen later.


Thanks for your perseverance!

--
Cheers,
Gunnar

Bug#1028897: fontconfig: wrong name for the Noto monospace font

[Gunnar Hjalmarsson]

Hi again,

As you may have seen, I submitted  and 
fixed it. Thanks for mentioning it!


On 2023-08-17 15:34, Raphaël Halimi wrote:

IMHO, if Debian wants to follow the upstream fontconfig default to
use the Noto fonts, the system should work without the DejaVu
packages installed, so it would make more sense to patch fontconfig
to use Noto Mono as a default and keep the "Noto look" across the
whole system, than to go back to DejaVu Sans Mono.


As regards "Noto look", and despite of the name "Noto Mono", personally 
I think that DejaVu Sans Mono aligns better with Noto Sans/Serif than 
Noto Mono does. Look at the letter 'g', for instance.


Also:

* If Debian would change the default monospace font, we would not follow 
upstream. That's true whether we would pick Noto Mono or DejaVu Sans Mono.


* There were reasons why I broke out DejaVu Sans Mono to its own 
package. :) Given that change, it's possible to install 
fonts-dejavu-mono without installing fonts-dejavu-core.


For those reasons I disagree with the quoted statement.

Another question is if the Noto Sans Mono deficiency is important enough 
to motivate a Debian level change in this respect. I don't know. 
@Fabian, I sent this reply to you as well in the hope to broaden the 
discussion a bit.


It's worth mentioning that the fonts-noto packages in Debian ship almost 
3 years old fonts. An update to latest upstream would be highly 
desirable. Possibly Noto Sans Mono has improved.


--
Cheers,
Gunnar

Bug#1050043: fonts-noto-core: Add fonts-noto-mono to Depends

[Gunnar Hjalmarsson]

Package: fonts-noto-core
Version: 20201225-1
X-Debbugs-CC: j...@debian.org, fab...@debian.org, raphael.hal...@gmail.com

Since a while Noto is the default font for latin scripts in 
fontconfig-config:


https://gitlab.freedesktop.org/fontconfig/fontconfig/-/commit/ad70d785

The Debian fontconfig-config package includes an alternative Depends 
list with reasonably complete base font packages, enforcing at least one 
of those packages to be installed in order to prevent a broken system. 
At my suggestion fonts-noto-core was recently prepended to that list:


https://salsa.debian.org/freedesktop-team/fontconfig/-/commit/5aa10dde

However, as was pointed out in <https://bugs.debian.org/1028897#44>, I 
overlooked that fonts-noto-core does not include monospace fonts, i.e. 
it does not really qualify as a complete base font package. To address 
that issue, I suggest that fonts-noto-mono is added to Depends in 
fonts-noto-core.


An alternative solution might be to create a meta package, e.g. 
fonts-noto-base, which would depend on fonts-noto-core and 
fonts-noto-mono, and replace fonts-noto-core with fonts-noto-base in the 
Depends list of fontconfig-config. Personally I think that would be to 
overdo it, though.


--
Rgds,
Gunnar Hjalmarsson

Bug#1028897: fontconfig: wrong name for the Noto monospace font

[Gunnar Hjalmarsson]

Hi Raphaël!

Raphaël Halimi wrote:

The problem is that the monospace Noto font is actually "Noto Mono" and
not "Noto Sans Mono" (probably a typo on upstream's part).

If you use a font manager you'll see that there is indeed a font called
"Noto Sans Mono", but if you filter them out to list only the monospace
fonts, you can see that there's no font called "Noto Sans Mono" among
them, but there is one called "Noto Mono".


That's a misconception, and upstream is to blame for it. Not 
Freedesktop, though, but Google.


Noto Sans Mono is a monospace font shipped by the fonts-noto-mono 
package in Debian. So is Noto Mono (previously named Droid Mono). The 
problem is that Noto Sans Mono does not declare itself as such properly. 
Please see this upstream gnome-terminal issue:


https://gitlab.gnome.org/GNOME/gnome-terminal/-/issues/7960

That should make you understand what it is I'm trying to say. :/


Using this one (which I now believe is the "real" monospace font from
Noto) as default for the monospace family does fix both Xterm and
gnome-terminal (and probably other terminals too).


So you have found that the older Noto Mono font looks better in 
terminals than Noto Sans Mono. That's interesting.


In any case I'm pretty sure that there is no typo in 60-latin.conf, so 
your patch is based on false premises.


But with that said, if other users are of the same opinion as you, it 
may be motivated to consider a Debian patch as regards the default 
monospace font for latin scripts. Personally I can think that going back 
to DejaVu Sans Mono should should be a more natural step, in that case. 
Noto Mono isn't even mentioned in 60-latin.conf.


--
Cheers,
Gunnar Hjalmarsson

Bug#1048552: im-config: Fails to build source after successful build

[Gunnar Hjalmarsson]

On 2023-08-15 20:28, Gunnar Hjalmarsson wrote:

The PO files and the POT file should be updated manually when needed
and not automatically at every build. There is a need to update the
POT only when files with translatable strings have been changed, and
the same is true for PO files update via msgmerge().

Maybe we should create po/Makefile and move the PO/POT stuff there.


I submitted a merge request along those lines:

https://salsa.debian.org/input-method-team/im-config/-/merge_requests/19

Would be good if you could take a look, Osamu.

Bug#1048552: im-config: Fails to build source after successful build

[Gunnar Hjalmarsson]

On 2023-08-13 21:20, Lucas Nussbaum wrote:

dpkg-source: info: local changes detected, the modified files are:
  im-config-0.57/po/bs.po
  im-config-0.57/po/cs.po
  im-config-0.57/po/da.po
  im-config-0.57/po/de.po
  im-config-0.57/po/en_AU.po
  im-config-0.57/po/en_GB.po
  im-config-0.57/po/es.po
  im-config-0.57/po/fr.po
  im-config-0.57/po/gl.po
  im-config-0.57/po/hr.po
  im-config-0.57/po/im-config.pot
  im-config-0.57/po/it.po
  im-config-0.57/po/ja.po
  im-config-0.57/po/ko.po
  im-config-0.57/po/ms.po
  im-config-0.57/po/nb.po
  im-config-0.57/po/nl.po
  im-config-0.57/po/pl.po
  im-config-0.57/po/pt.po
  im-config-0.57/po/pt_BR.po
  im-config-0.57/po/ru.po
  im-config-0.57/po/sl.po
  im-config-0.57/po/sv.po
  im-config-0.57/po/tr.po
  im-config-0.57/po/uk.po
  im-config-0.57/po/vi.po
  im-config-0.57/po/zh_CN.po
  im-config-0.57/po/zh_HK.po
  im-config-0.57/po/zh_TW.po
dpkg-source: error: aborting due to unexpected upstream changes, see 
/tmp/im-config_0.57-2.diff.u5Hfa8


The PO files and the POT file should be updated manually when needed and 
not automatically at every build. There is a need to update the POT only 
when files with translatable strings have been changed, and the same is 
true for PO files update via msgmerge().


Maybe we should create po/Makefile and move the PO/POT stuff there.

--
Rgds,
Gunnar

Bug#1043271: Break out monospace to a fonts-dejavu-mono binary

[Gunnar Hjalmarsson]

This is the merge request:
https://salsa.debian.org/fonts-team/fonts-dejavu/-/merge_requests/4

Bug#1043271: Break out monospace to a fonts-dejavu-mono binary

[Gunnar Hjalmarsson]

Package: src:fonts-dejavu
Version: 2.37-6
Severity: wishlist
X-Debbugs-Cc: gunna...@debian.org

Hi!

The fonts-dejavu-core package covers serif and sans-serif as well as 
monospace fonts. For better flexibility, so you easier can mix fonts 
from different packages, I would like to propose that the monospaced 
variants are broken out into a new fonts-dejavu-mono binary.


The reason for my request is that I'm currently involved in an overhaul 
of the set of font packages which are installed by default in the Ubuntu 
desktop. For several years Ubuntu has shipped fonts-dejavu-core, but now 
fonts-noto-core is about to be shipped by default, and having both is 
not optimal from a fontconfig POV.


I have thought about various ways to deal with this situation, and since 
Ubuntu wants to keep DejaVu Sans Mono for now, creating a new binary for 
the monospaced fonts seems to be a sensible step. The thought is that 
fonts-dejavu-core would recommend fonts-dejavu-mono, so the change 
shouldn't result in any disruption. If a user, who has the old version 
of fonts-dejavu-core installed, upgrades, APT will pull 
fonts-dejavu-mono and with that make sure that previously installed font 
files are not dropped as a result of the upgrade. Similarly, when 
fonts-dejavu-core is a build dependency (example: pango1.0), also 
fonts-dejavu-mono will become included in the build environment.


And, needless to say, the user would have the option to install 
fonts-dejavu-mono only.


I will submit a merge request which details how the proposed breakout 
can be accomplished.


--
Cheers,
Gunnar Hjalmarsson

Bug#1042061: ITP: fonts-atkinson-hyperlegible -- Font focused on legibility and readability

[Gunnar Hjalmarsson]

Package: wnpp
Severity: wishlist

Package name: fonts-atkinson-hyperlegible
Version : 0.0~git20210430.1cb3116-1
Upstream Author : Braille Institute of America, Inc.
URL : https://github.com/googlefonts/atkinson-hyperlegible
License : OFL-1.1
Description : Font focused on legibility and readability

Atkinson Hyperlegible is a typeface created in partnership with Braille 
Institute. It has been developed specifically to increase legibility for 
readers with low vision, and to improve comprehension. It supports Latin 
scripts, and covers accent characters for 27 languages.


The OTF variant of the font is included in the texlive-fonts-extra 
package, but there is a need for a separate Debian package to make it 
conveniently available for common use. Few users want to install all the 
fonts which are installed/pulled if you install texlive-fonts-extra, and 
even if you do, the Atkinson Hyperlegible font won't be seen by fontconfig.


--
Gunnar Hjalmarsson

Bug#1037663: foma: ftbfs with GCC-13

[Gunnar Hjalmarsson]

Control: affects -1 ibus-typing-booster

Thanks for the upstream PR with a fix, Tino. Considering that upstream 
is not so alert, do you plan to add the fix as a patch? I suspect the 
autoremoval 'threat' affects several other packages.


--
Cheers,

Gunnar Hjalmarsson

Bug#1040615: ibus: Misplaced candidate window in gtk4 apps

[Gunnar Hjalmarsson]

Package: ibus
Version: 1.5.27-5
Severity: important
Control: forwarded -1 https://github.com/ibus/ibus/issues/2522

When using an IBus input method in gtk4 applications such as nautilus or 
gnome-text-editor, the candidate window does not show up right below the 
cursor as expected, but rather a bit random.


The issue was originally reported upstream against Debian 12, and I have 
confirmed it in Debian testing. I also see the issue in Ubuntu 22.04 
with ibus 1.5.26 and Ubuntu 23.04 with ibus 1.5.28. The upstream issue 
focuses on ibus-libpinyin, but the problem is present with e.g. 
ibus-mozc and ibus-anthy as well.


In all those cases the issue is only present in x11 sessions, while it 
works as expected in Wayland. However, in Ubuntu's development version 
the issue is present in both x11 and Wayland.


--
Gunnar Hjalmarsson

Bug#1038729: xkb-data: Upgrade wants to remove nVidia drivers

[Gunnar Hjalmarsson]

Control: notfound -1 xkeyboard-config/2.35.1-1
Control: found -1 console-setup/1.221
Control: affects -1 xkeyboard-config

On 2023-06-21 13:41, Cristian Ionescu-Idbohrn wrote:

I'm also affected by this :(

# apt policy xkb-data
xkb-data:
   Installed: 2.35.1-1
   Candidate: 2.38-2
   Version table:
  2.38-2 500
     500 http://deb.debian.org/debian sid/main amd64 Packages
     500 http://deb.debian.org/debian sid/main i386 Packages
  *** 2.35.1-1 100
     100 /var/lib/dpkg/status

# apt install xkb-data
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following packages were automatically installed and are no longer
required:
   libfs6 x11-session-utils x11-xfs-utils xinit
Use 'apt autoremove' to remove them.
The following packages will be REMOVED:
   console-setup console-setup-linux keyboard-configuration
   ...


Thanks, console-setup & friends — then I understand. That's due to an 
ongoing transition and expected behavior. See 
.


--
Gunnar

Bug#1038729: xkb-data: Upgrade wants to remove nVidia drivers

[Gunnar Hjalmarsson]

Control: tags -1 moreinfo

Hi Nicolas,

Nicolas Patrois wrote:

Upgrading xkb-data wants me to remove these automatically installed packages:


Are you talking about upgrading *to* xkb-data 2.35.1-1 or *from* 
xkb-data 2.35.1-1 to xkb-data 2.38-2?


Also, can you please show us the complete output of the command:

apt install xkb-data

--
Rgds,
Gunnar Hjalmarsson

Bug#1038759: console-setup: Build against xkb-data 2.38-2 needed

[Gunnar Hjalmarsson]

Package: src:console-setup
Version: 1.221
Severity: important
X-Debbugs-Cc: debia...@lists.debian.org, gunna...@debian.org
Control: affects -1 src:xkeyboard-config

Dear maintainers,

xkeyboard-config 2.38-2 was recently uploaded to unstable, but it won't 
migrate to testing until console-setup has been (re-)built against the 
new version of xkb-data.


https://release.debian.org/transitions/html/auto-upperlimit-xkb-data.html

So could somebody please do a no-change upload (or an upload for other 
reasons) of console-setup.


--
Cheers,
Gunnar Hjalmarsson

Bug#1038673: nmu: console-setup_1.221

[Gunnar Hjalmarsson]

Control: -1 usertag + transition

On 2023-06-20 03:14, Gunnar Hjalmarsson wrote:

On 2023-06-20 01:18, Gunnar Hjalmarsson wrote:

nmu control-setup_1.221 . all . -m 'Rebuild against xkb-data 2.38-2'


Sorry about the typo. Should better be:

nmu console-setup_1.221 . all . -m 'Rebuild against xkb-data 2.38-2'

(don't do these things when you ought to sleep)


At last I realize that this is strictly a transition, and thus that I 
uploaded to unstable prematurely.


The autogenerated ben tracker looks as expected:

https://release.debian.org/transitions/html/auto-upperlimit-xkb-data.html

But the conclusion stands: Please do a binNMU of console-setup to help 
accomplish the transition.

Bug#1038673: nmu: console-setup_1.221

[Gunnar Hjalmarsson]

On 2023-06-20 01:18, Gunnar Hjalmarsson wrote:

nmu control-setup_1.221 . all . -m 'Rebuild against xkb-data 2.38-2'


Sorry about the typo. Should better be:

nmu console-setup_1.221 . all . -m 'Rebuild against xkb-data 2.38-2'

(don't do these things when you ought to sleep)

/ Gunnar

Bug#1038673: nmu: console-setup_1.221

[Gunnar Hjalmarsson]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu
X-Debbugs-Cc: debia...@lists.debian.org, gunna...@debian.org
Control: affects -1 src:xkeyboard-config src:control-setup

Hi!

I uploaded xkeyboard-config 2.38-2 to unstable (as an NMU), but before 
it can migrate, console-setup needs to be rebuilt against the new 
xkb-data version.


nmu control-setup_1.221 . all . -m 'Rebuild against xkb-data 2.38-2'

--
Thanks!

Gunnar Hjalmarsson

Bug#1037229: ibus-libpinyin: Disable cloud input feature

[Gunnar Hjalmarsson]

On 2023-06-08 17:55, Jeremy Bícha wrote:

It is not urgent for Debian since there are a lot of other affected
packages.

https://release.debian.org/transitions/html/libsoup3.html
https://release.debian.org/transitions/html/webkit2gtk-4.0.html

I did make my proposed change for Ubuntu since ibus-libpinyin is in
main there.


I see. Then let's hope we'll be able to re-enable it before the release 
of Ubuntu 23.10.


--
Rgds,
Gunnar

Bug#1037229: ibus-libpinyin: Disable cloud input feature

[Gunnar Hjalmarsson]

Hi Jeremy,

On 2023-06-08 15:48, Jeremy Bícha wrote:

Please consider disabling the cloud input feature. It depends on
libsoup2.4 but Debian would eventually like to remove libsoup2.4.

I filed a bug upstream requesting that the feature switch to using
libsoup3:
https://github.com/libpinyin/ibus-libpinyin/issues/423


How urgent is it? An option is to wait a few weeks and see if upstream 
accomplishes the migration to libsoup3. If they do we can avoid to 
disable the feature.


--
Gunnar

Bug#1036817: missing simplified version for 'sao' (187.8)

[Gunnar Hjalmarsson]

Hi Toni,

I leave it to others to comment on the traditional/simplified aspect, 
but as regards the rendering I have a theory.


On 2023-05-27 01:54, Toni Mueller wrote:

I am trying to write the character 'sao' (see attached image), but
only get the traditional version of it, which is then mistaken as a
Japanese character.





Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), LANGUAGE=en_US:en


Assuming that you use Noto fonts: A unicode character which is present 
both in Traditional Chinese and Japanese is rendered by Noto Sans CJK JP 
by default. To enforce the use of Noto Sans CJK SC you need to change 
LC_CTYPE to "zh_CN.UTF-8".


--
Gunnar Hjalmarsson

Bug#1036306: unblock: ufw/0.36.2-1

[Gunnar Hjalmarsson]

On 2023-05-23 22:01, Paul Gevers wrote:

On 23-05-2023 18:56, Gunnar Hjalmarsson wrote:

ufw has autopkgtest, so strictly it's not blocked because of the
freeze, but because of a piuparts failure.


That's not true. We're in Hard Freeze, so ufw qualifies to migrate
with passing autopkgtest when it's age is 20 days. However, once
those 20 days are over, we're in Full Freeze so it won't migrate. So
yes, strictly speaking it's *also* blocked by the freeze.


I stand corrected. (And with that I understand wrt ufw why Jamie needs 
to justify the freeze related unblock request.)



As you can see my primary concern is another package, i.e.
ibus-pinyin. That package has already been unblocked from freeze:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1036225


And missed the ignore-piuparts hint. Thanks for bringing that to our
attention, I added that hint.


Thanks! (And I understand from your reply that otherwise I should have
simply submitted a separate unblock request. Or maybe re-opened the 
already submitted bug...)



From tomorrow on, all packages that haven't migrated need an unblock
request or they will not be part of bookworm. Normally we'd spot the
piuparts problem and add the ignore hint if it's caused by the
adduser issue.


Sounds like the release team has it under control, then, so I will stop 
worrying. :)


--
Thanks again!

Gunnar

Bug#1036306: unblock: ufw/0.36.2-1

[Gunnar Hjalmarsson]

Hi Paul,

On 2023-05-23 17:31, Paul Gevers wrote:

On 19-05-2023 05:33, Jamie Strandboge wrote:
It seems that adduser 3.133 has caused problems for a lot of packages 
in sid, including ufw. See:


https://piuparts.debian.org/sid/fail/adduser_3.133.log
https://piuparts.debian.org/sid/fail/
https://piuparts.debian.org/sid/fail/ufw_0.36.2-1.log
https://piuparts.debian.org/sid/fail/...


Yes, known, let's not worry about that.


Well, I do worry a bit.

ufw did not cause adduser to be unremovable, and adduser being 
unremovable

should not affect ufw's migration.


Sure. The migration is currently blocked because the upload happened 
very recently


That description is not quite accurate. ufw has autopkgtest, so strictly 
it's not blocked because of the freeze, but because of a piuparts failure.


and tomorrow we'll enter Full Freeze. So the upload 
happened too late for it to migrate without us unblocking.


Maybe you didn't see my reply to Jamie's initial bug, but it was archived:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1036306#10

As you can see my primary concern is another package, i.e. ibus-pinyin. 
That package has already been unblocked from freeze:


https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1036225

But since it hit the very same adduser/piuparts issue as ufw (and 
probably a bunch of other packages) did, it's still blocked from migration.



Maybe it was wrong of me to comment on this ufw bug, but the 
adduser/piuparts situation is special, and I felt it made sense to 
handle all affected packages together.


Please advice on how uploaders affected by the adduser/piuparts 
situation should act.


--
Rgds,
Gunnar Hjalmarsson

Bug#1036306: unblock: ufw/0.36.2-1

[Gunnar Hjalmarsson]

I'm kind of 'hijacking' this bug instead of submitting an own. Hope you 
don't mind, Jamie. :/


I have the very same problem, i.e. piuparts failing due to the latest 
change in adduser:


https://tracker.debian.org/pkg/ibus-pinyin

So please add ibus-pinyin to the list of packages which probably need 
the release team's attention to resolve the adduser/piuparts situation.


I don't know how to identify other affected packages, but there is a 
related email list thread:


https://alioth-lists.debian.net/pipermail/piuparts-devel/2023-May/009566.html

(And with that I suppose that #1036307, which was mistakenly submitted 
as a new bug, can be closed.)


--
Cheers,
Gunnar Hjalmarsson

Bug#1036225: unblock: ibus-pinyin/1.5.0-10

[Gunnar Hjalmarsson]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: debian-input-met...@lists.debian.org
Control: affects -1 + src:ibus-pinyin

Please unblock package ibus-pinyin.

[ Reason ]

https://bugs.debian.org/1036197 pointed out that a python file includes 
a gettext API which was removed in python3.10. When fixing that I also 
noticed that the Gtk version was not specified, which it needs to be on 
systems where gtk4 is present.


These issues have been fixed in ibus-pinyin 1.5.0-10 through two small 
patches.


[ Impact ]

Without the mentioned patches, the user can't open the Preferences 
window, which significantly reduces the usability of the package.


[ Tests ]

Manually installed the binary built by version 1.5.0-10 of the 
ibus-pinyin source, and confirmed that the issues were fixed as expected.


[ Risks ]

The fixes are standard python3 fixes, and should have been done long 
ago. Can't see any risk for adverse side effects.


[ Checklist ]
  [x] all changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in testing

--
Cheers,
Gunnar Hjalmarssondiff --git a/debian/changelog b/debian/changelog
index e163562..67e8e68 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,19 @@
+ibus-pinyin (1.5.0-10) unstable; urgency=medium
+
+  * Team upload
+  * Upload to unstable
+
+ -- Gunnar Hjalmarsson   Wed, 17 May 2023 19:14:23 +0200
+
+ibus-pinyin (1.5.0-9) experimental; urgency=medium
+
+  * Team upload
+  * Fix removed python gettext API (closes: #1036197, LP: #2019921)
+  * Bump Standards-Version to 4.6.2
+  * Specify Gtk version (LP: #2019921)
+
+ -- Gunnar Hjalmarsson   Wed, 17 May 2023 08:17:28 +0200
+
 ibus-pinyin (1.5.0-8) unstable; urgency=medium
 
   * Team upload
diff --git a/debian/control b/debian/control
index 2a49cc4..630f00a 100644
--- a/debian/control
+++ b/debian/control
@@ -18,7 +18,7 @@ Build-Depends:
  python3-dev,
  sqlite3,
  uuid-dev,
-Standards-Version: 4.6.1
+Standards-Version: 4.6.2
 Homepage: https://github.com/ibus/ibus-pinyin
 Vcs-Git: https://salsa.debian.org/input-method-team/ibus-pinyin.git
 Vcs-Browser: https://salsa.debian.org/input-method-team/ibus-pinyin
diff --git a/debian/patches/Fix-removed-python-gettext-API.patch 
b/debian/patches/Fix-removed-python-gettext-API.patch
new file mode 100644
index 000..f800cd0
--- /dev/null
+++ b/debian/patches/Fix-removed-python-gettext-API.patch
@@ -0,0 +1,28 @@
+From: znwu 
+Date: Sun, 7 May 2023 18:17:11 -0700
+Subject: Fix removed python gettext API
+
+Origin: https://github.com/ibus/ibus-pinyin/commit/e2e10c40
+Bug-Debian: https://bugs.debian.org/1036197
+---
+ setup/main.py | 7 ++-
+ 1 file changed, 6 insertions(+), 1 deletion(-)
+
+diff --git a/setup/main.py b/setup/main.py
+index 3c13c4c..3f153a5 100644
+--- a/setup/main.py
 b/setup/main.py
+@@ -45,7 +45,12 @@ def __init__(self, engine):
+ locale.setlocale(locale.LC_ALL, "")
+ localedir = os.getenv("IBUS_LOCALEDIR")
+ gettext.bindtextdomain("ibus-pinyin", localedir)
+-gettext.bind_textdomain_codeset("ibus-pinyin", "UTF-8")
++# Python's gettext module doesn't provide all methods in
++# new Python version since Python 3.10
++try:
++gettext.bind_textdomain_codeset("ibus-pinyin", "UTF-8")
++except AttributeError:
++pass
+ 
+ self.__bus = IBus.Bus()
+ self.__config = self.__bus.get_config()
diff --git a/debian/patches/Specify-Gtk-version.patch 
b/debian/patches/Specify-Gtk-version.patch
new file mode 100644
index 000..925aaf0
--- /dev/null
+++ b/debian/patches/Specify-Gtk-version.patch
@@ -0,0 +1,15 @@
+Description: Specify Gtk version
+Author: Gunnar Hjalmarsson 
+Applied-Upstream: https://github.com/ibus/ibus-pinyin/commit/61677008
+
+--- a/setup/main.py
 b/setup/main.py
+@@ -27,6 +27,8 @@
+ import os
+ import sys
+ 
++from gi import require_version
++require_version ('Gtk', '3.0')
+ from gi.repository import GLib
+ from gi.repository import Gtk
+ from gi.repository import IBus
diff --git a/debian/patches/series b/debian/patches/series
index d467c09..c483696 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -15,3 +15,6 @@ ibus-pinyin-default-full.patch
 # python3 support
 python3.patch
 lua-5.4.patch
+
+Fix-removed-python-gettext-API.patch
+Specify-Gtk-version.patch

Bug#1034461: unblock: gnome-user-docs/43.0-2

[Gunnar Hjalmarsson]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: gunna...@debian.org
Control: affects -1 + src:gnome-user-docs

Please unblock package gnome-user-docs.

[ Reason ]

Upstream missed to ship two figures in the tarball. They were added via 
a patch in gnome-user-docs 43.0-2.


[ Impact ]

Without the patch it doesn't look so good if you browse this page:

yelp /usr/share/help/C/gnome-help/bluetooth-device-specific-pairing.page

[ Tests ]

Installed the binary built by version 43.0-2 of the gnome-user-docs 
source, and confirmed that the figures showed up as expected.


[ Risks ]

Just two docs figures, not affecting anything else.

[ Checklist ]
 [x] all changes are documented in the d/changelog
 [x] I reviewed all changes and I approve them
 [x] attach debdiff against the package in testing

--
Cheers,
Gunnar Hjalmarssondiff --git a/debian/changelog b/debian/changelog
index f8b94f77a..deff6d0ed 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+gnome-user-docs (43.0-2) unstable; urgency=medium
+
+  * Add-missing-figures.patch
+
+ -- Gunnar Hjalmarsson   Sat, 15 Apr 2023 23:54:03 +0200
+
 gnome-user-docs (43.0-1) unstable; urgency=medium
 
   * New upstream release
diff --git a/debian/patches/Add-missing-figures.patch 
b/debian/patches/Add-missing-figures.patch
new file mode 100644
index 0..ab58c19b0
--- /dev/null
+++ b/debian/patches/Add-missing-figures.patch
@@ -0,0 +1,153 @@
+Description: Add missing figures
+ A consequence of the mistake in gnome-help/Makefile.am is that the
+ figures are not included in the upstream tarball. So this patch also
+ adds the missing figures as such.
+Author: Gunnar Hjalmarsson 
+Forwarded: https://gitlab.gnome.org/GNOME/gnome-user-docs/-/merge_requests/164
+---
+ /dev/null => gnome-help/C/figures/ps-button.svg |  62 +++
+ /dev/null => gnome-help/C/figures/ps-create.svg |  54 ++
+ gnome-help/Makefile.am  |   2 +
+ 3 files changed, 118 insertions(+)
+
+diff --git a/gnome-help/C/figures/ps-button.svg 
b/gnome-help/C/figures/ps-button.svg
+new file mode 100644
+index 000..f65a8f3
+--- /dev/null
 b/gnome-help/C/figures/ps-button.svg
+@@ -0,0 +1,62 @@
++
++
++
++http://www.inkscape.org/namespaces/inkscape;
++   xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd;
++   xmlns="http://www.w3.org/2000/svg;
++   xmlns:svg="http://www.w3.org/2000/svg;>
++  
++  
++  
++
++  
++  
++  
++
++  
++
+diff --git a/gnome-help/C/figures/ps-create.svg 
b/gnome-help/C/figures/ps-create.svg
+new file mode 100644
+index 000..f62dec8
+--- /dev/null
 b/gnome-help/C/figures/ps-create.svg
+@@ -0,0 +1,54 @@
++
++
++
++http://www.inkscape.org/namespaces/inkscape;
++   xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd;
++   xmlns="http://www.w3.org/2000/svg;
++   xmlns:svg="http://www.w3.org/2000/svg;>
++  
++  
++  
++⚟
++  
++
+diff --git a/gnome-help/Makefile.am b/gnome-help/Makefile.am
+index 95000e0..a94470b 100644
+--- a/gnome-help/Makefile.am
 b/gnome-help/Makefile.am
+@@ -83,6 +83,8 @@ HELP_MEDIA = \
+   figures/network-wireless-disabled-symbolic.svg \
+   figures/preferences-desktop-accessibility-symbolic.svg \
+   figures/printing-select.png \
++  figures/ps-button.svg \
++  figures/ps-create.svg \
+   figures/rotation-allowed-symbolic.svg \
+   figures/rotation-locked-symbolic.svg \
+   figures/screenshot-tool.png \
diff --git a/debian/patches/series b/debian/patches/series
index ead8eb86f..b87203895 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -1 +1,2 @@
 drop-experimental-style-for-prefs.page.patch
+Add-missing-figures.patch

Bug#1034090: ibus: FTBFS twice in a row: src/ibusenumtypes.h is regenerated too late

[Gunnar Hjalmarsson]

Control: tags -1 upstream
Control: forwarded -1 https://github.com/ibus/ibus/issues/2501

Thanks for your report!

We use a pre-compiled, kind of, tarball as the upstream source:

https://github.com/ibus/ibus/releases/download/1.5.28/ibus-1.5.28.tar.gz

ibusenumtypes.h has already been generated in that tarball, which 
explains why it works the first time. The file is not present in the 
upstream git source (only the 8 years old src/ibusenumtypes.h.template 
file is).


As an experiment I tried to build with the true source tarball, and then 
it failed already at the first attempt for the same reason.


The behavior has been reported upstream, so let's await the outcome of 
the upstream issue.


Btw, is "serious" an appropriate severity level for this bug?

--
Rgds,
Gunnar

Bug#1034040: How useful is debian/ibus-keyman.postinst?

[Gunnar Hjalmarsson]

Package: ibus-keyman
Version: 16.0.139-4

Hi!

Without being sure I actually found a bug, I would like to raise a 
discussion as a follow-up of  (which 
hasn't been well received so far). The unblock discussion made me aware 
of this script:


https://github.com/keymanapp/keyman/blob/master/linux/debian/ibus-keyman.postinst

The script makes me think of im-config, which sets the applicable 
environment variables and starts ibus-daemon at login.


I suppose the purpose with the script is to make ibus-keyman instantly 
usable in the same session as it is installed. I imagine that may work 
if ibus-daemon was already running and thus the needed environment 
variables already set for the session. But what if ibus was pulled as a 
dependency when installing ibus-keyman? Will keyman work in a meaningful 
way even if the variables are not present?


If the answer to that question is "no", wouldn't it be more 
straightforward to instruct the users to relogin before starting to use 
keyman, and thus drop the postinst script?


I may well have misunderstood it, and if so, I would appreciate a brief 
explanation of the intention with the script.


--
Rgds,
Gunnar

Bug#1034005: ibus-kkc FTCBFS: configures for the build architecture

[Gunnar Hjalmarsson]

Control: tags -1 + pending

Thanks Helmut! Pushed your change to the repo.

--
Rgds,
Gunnar

Bug#1033024: lios hangs when opening Preferences

[Gunnar Hjalmarsson]

Nice fix in 2.7.2-5, Samuel. :) (Why didn't I try that?) That version 
ought to be fine for both Debian 12 and Ubuntu 23.04, and you will be 
able to consider the 'full upstream approach' in experimental later.


--
Cheers,
Gunnar

Bug#1033024: lios hangs when opening Preferences

[Gunnar Hjalmarsson]

On 2023-04-03 00:14, Samuel Thibault wrote:

Gunnar Hjalmarsson, le mer. 15 mars 2023 22:06:23 +0100, a ecrit:

The question to you is if you would like me to add it to the repo
and upload to experimental.


Yes, you're welcome to do it!


Ok, then I'm going to upload what I have. Hopefully it is an overall 
improvement. The patch I added isn't pretty, but proved to be needed for 
me when testing.



Or do you possibly think that the release team would approve also
this for Debian 12?


It depends on the changes size :)


Unfortunately the diff is rather big. Personally I wouldn't want to 
justify it towards the release team...


--
Rgds,
Gunnar

Bug#1033659: ibus-braille: Ibus-braille producing TypeError exception

[Gunnar Hjalmarsson]

On 2023-03-30 12:39, Hammer Attila wrote:

Hi Gunnar,

dpkg-query -W ibus im-config command shows me all packages are
installed right.
Perhaps have problem my migrated config settings


Yeah.. Do you have an ~/.xinputrc file? In that case you can safely 
remove it.


rm ~/.xinputrc

Might make a difference.

--
Gunnar

Bug#1033659: ibus-braille: Ibus-braille producing TypeError exception

[Gunnar Hjalmarsson]

On 2023-03-29 21:05, Gunnar Hjalmarsson wrote:


dpkg-query -W ibus im-config

If both those packages are installed, ibus-daemon ought to be started
automatically at login.


@Samuel: I was about to propose that ibus is added to Depends, but saw 
that you already did that. :)


https://salsa.debian.org/input-method-team/ibus-braille/-/commit/23c40f02

--
Gunnar

Bug#1033659: ibus-braille: Ibus-braille producing TypeError exception

[Gunnar Hjalmarsson]

On 2023-03-29 20:15, Hammer Attila wrote:

I surprised default ibus-daemon not running in X session for example
the Mate session?


I had the same thought. Can you please run this command:

dpkg-query -W ibus im-config

If both those packages are installed, ibus-daemon ought to be started 
automatically at login.


--
Cheers,
Gunnar Hjalmarsson

Bug#1033293: 100% cpu usage for ibus with ardour 1:7.3.0+ds0-1

[Gunnar Hjalmarsson]

Package: ardour
Version: 1:7.3.0+ds0-1
X-Debbugs-CC: enorrm...@gmail.com

Dear maintainer,

This is a forward of the Ubuntu bug 
<https://launchpad.net/bugs/2012146>. After the bug reporter had 
upgraded from Ubuntu 22.10 to 23.04, ibus started to consume a lot of 
cpu when using ardour. The ardour version available in Ubuntu 22.10 is 
1:6.9.0+ds0-2.


It's worth mentioning that the issue is not present with the Ardour 
7.3.0 binary from upstream. That made me wonder if there may be 
something with the packaging — hence this bug report.


--
Rgds,
Gunnar Hjalmarsson

Bug#1033229: unblock: im-config/0.55-2

[Gunnar Hjalmarsson]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: debian-input-met...@lists.debian.org

Please unblock package im-config.

[ Reason ]

The file /etc/xdg/autostart/im-launch.desktop had an Exec line which 
proved to be incompatible with the parser of systemd boot. That Exec 
line has therefore been simplified in im-config 0.55-2.


[ Impact ]

The issue resulted in im-config failing to start the IM framework, e.g. 
fcitx5, when logging in to a Plasma (Wayland) session. That's an 
annoyance which will be fixed with the version in unstable.


[ Tests ]

Manually installed the binary built by version 0.55-2 of the im-config 
source, and confirmed that the bug was fixed as expected.


[ Risks ]

The change is a targeted trivial fix to address the issue at hand. Can't 
think of any adverse side effects.


[ Checklist ]
[x] all changes are documented in the d/changelog
[x] I reviewed all changes and I approve them
[x] attach debdiff against the package in testing

--
Cheers,
Gunnar Hjalmarssondiff --git a/debian/changelog b/debian/changelog
index 
c5ae651c299c0765505947febdacd33e21490a5d..8f623fc6535339c94bee79c31ce9e891a888d3d5
 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+im-config (0.55-2) unstable; urgency=medium
+
+  * systemd boot compatible Exec line in im-launch.desktop
+- Fixes issue with the IM framework not being started automatically
+  when logging in to a Plasma (Wayland) session (closes: #1033097).
+
+ -- Gunnar Hjalmarsson   Mon, 20 Mar 2023 11:47:27 +0100
+
 im-config (0.55-1) unstable; urgency=medium
 
   * Set GTK_IM_MODULE in GNOME on Xorg sessions (closes: #1031227)
diff --git a/debian/patches/series b/debian/patches/series
index 
e69de29bb2d1d6434b8b29ae775ad8c2e48c5391..6639a6d9c04ac850f554da420891f57a857f0275
 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -0,0 +1 @@
+systemd_boot_compatible_Exec_line_in_im-launch.desktop.patch
diff --git 
a/debian/patches/systemd_boot_compatible_Exec_line_in_im-launch.desktop.patch 
b/debian/patches/systemd_boot_compatible_Exec_line_in_im-launch.desktop.patch
new file mode 100644
index 
..1f0fdbc2aeae3757dc77e9f5f673d12c663d8150
--- /dev/null
+++ 
b/debian/patches/systemd_boot_compatible_Exec_line_in_im-launch.desktop.patch
@@ -0,0 +1,55 @@
+From: Gunnar Hjalmarsson 
+Date: Mon, 20 Mar 2023 09:55:59 +0100
+Subject: systemd boot compatible Exec line in im-launch.desktop
+
+im-launch.desktop is autostarted, and the Exec line has up to now
+contained a condition so /usr/bin/im-launch has only been started in
+wayland sessions.
+
+However, as from KDE Plasma 5.25 systemd boot is enabled by default,
+and that feature fails to parse the previous Exec line in
+im-launch.desktop. An example consequence is that fcitx5 is not started
+automatically at login to a KDE Plasma (Wayland) or Kubuntu (Wayland)
+session.
+
+This commit fixes the issue by moving the mentioned condition from
+im-launch.desktop to the top of /usr/bin/im-launch, resulting in an
+Exec line simple enough for systemd boot to parse.
+
+Bug-KDE: https://bugs.kde.org/show_bug.cgi?id=455252
+Bug-Debian: https://bugs.debian.org/1033097
+Origin: https://salsa.debian.org/input-method-team/im-config/-/commit/5a979231
+---
+ im-launch | 6 ++
+ im-launch.desktop | 2 +-
+ 2 files changed, 7 insertions(+), 1 deletion(-)
+
+diff --git a/im-launch b/im-launch
+index 4845f92..721a24a 100755
+--- a/im-launch
 b/im-launch
+@@ -13,6 +13,12 @@ if [ "x$1" = "x-h" ] || [ "x$1" = "x--help" ] || [ "x$1" = 
"x" ]; then
+ exit 1
+ fi
+ 
++if [ "$1" = 'true' ] && [ "$XDG_SESSION_TYPE" != 'wayland' ]; then
++# This program was autostarted, but was already run at the
++# start of an X session, so don't run it now too.
++exit 0
++fi
++
+ if [ "$IM_CONFIG_CHECK_ENV" = 1 ] && \
+[ "$IM_CONFIG_PHASE" = 1 ]; then
+ # If tweaked, keep hands off :-)
+diff --git a/im-launch.desktop b/im-launch.desktop
+index 7e3b624..e8d5e70 100644
+--- a/im-launch.desktop
 b/im-launch.desktop
+@@ -1,6 +1,6 @@
+ [Desktop Entry]
+ Name=im-launch
+-Exec=sh -c 'if [ "x$XDG_SESSION_TYPE" = "xwayland" ] ; then exec env 
IM_CONFIG_CHECK_ENV=1 im-launch true; fi'
++Exec=sh -c 'IM_CONFIG_CHECK_ENV=1 im-launch true'
+ TryExec=im-launch
+ Type=Application
+ NoDisplay=true

Bug#1033097: im-config: Fcitx5 does not start automatically in KDE plasma Wayland

[Gunnar Hjalmarsson]

On 2023-03-19 03:31, Gunnar Hjalmarsson wrote:

Submitted an im-config merge request:

https://salsa.debian.org/input-method-team/im-config/-/merge_requests/18

Feedback welcome!


Since I based the merge request on Kubuntu 23.04 observations, I decided 
to confirm that it also applies in Debian itself. So I installed 
plasma-desktop on my Debian testing installation, and — as expected — 
fcitx5 didn't start when logging in to a Plasma (Wayland) session. I 
confirmed that the same systemd boot issue is present in Debian, so I 
applied the proposed changes to im-config. Result: fcitx5 still didn't 
start.


The remaining problem proved to be the display manager. GDM does not 
source the files in /etc/profile.d when logging in to a Plasma (Wayland) 
session! So I installed sddm and made it the standard DM. That proved to 
be it. When logging in from SDDM to a Plasma (Wayland) session, fcitx5 
starts automatically.


@Jun Nogata: It would be interesting to know which display manager you 
are using.


Not sure what the conclusion of this is. Did I find a GDM bug? Or is GDM 
intended to be used for GNOME sessions only? Or should we reconsider 
im-config's use of /etc/profile.d? Maybe systemd is good enough these days.


But this latter aspect is something to maybe deal with later. Unless 
somebody objects, I will consider the merge request sufficient to fix 
this bug.


--
Gunnar

Bug#1033097: im-config: Fcitx5 does not start automatically in KDE plasma Wayland

[Gunnar Hjalmarsson]

Submitted an im-config merge request:

https://salsa.debian.org/input-method-team/im-config/-/merge_requests/18

Feedback welcome!

Bug#1033097: im-config: Fcitx5 does not start automatically in KDE plasma Wayland

[Gunnar Hjalmarsson]

On 2023-03-18 08:54, Gunnar Hjalmarsson wrote:

Is there some buggy systemd feature, which takes over XDG autostart
files, and which KDE/Plasma makes use of while GNOME does not?


It looks like that's close to the truth. I googled around, and found a 
command which disables the thing:


kwriteconfig5 --file startkderc --group General --key systemdBoot false

(+ reboot)

That made Fcitx5 start automatically for me on Plasma (Wayland).

Source: https://bugs.kde.org/show_bug.cgi?id=455252

So this may well be a KDE bug or a systemd bug — pick your choice.

Should we do something with im-config in the meantime to work around the 
problem?


--
Gunnar

Bug#1033097: im-config: Fcitx5 does not start automatically in KDE plasma Wayland

[Gunnar Hjalmarsson]

On 2023-03-17 21:18, Gunnar Hjalmarsson wrote:

I made some tests with Kubuntu 23.04, and the problem seems to be
with the im-config file /etc/xdg/autostart/im-launch.desktop. I see
this line in the syslog:

2023-03-17T18:46:15.452477+01:00 gunnar-kubuntu-lunar-230317
systemd[865]: 
/run/user/1000/systemd/generator.late/app-im\x2dlaunch@autostart.service:14:

Ignoring unknown escape sequences: "if [ "x\$XDG_SESSION_TYPE" =
"xwayland" ] ; then exec env IM_CONFIG_CHECK_ENV=1 im-launch true;
fi"

How are those escapes added??

Anyway, it works for me in a wayland session if I drop the condition
from the Exec line in /etc/xdg/autostart/im-launch.desktop so it
looks like this:

Exec=sh -c 'exec env IM_CONFIG_CHECK_ENV=1 im-launch true'

But that's not what we want, is it? Suggestions for a proper way to
address this issue are most welcome.


On Ubuntu 23.04 I see the issue in Plasma (Wayland) but not in Ubuntu 
(Wayland). Is there some buggy systemd feature, which takes over XDG 
autostart files, and which KDE/Plasma makes use of while GNOME does not?


@Jun Nogata: Can you please edit /etc/xdg/autostart/im-launch.desktop as 
shown above and let us know if it helps in your case.


--
Gunnar

Bug#1033097: im-config: Fcitx5 does not start automatically in KDE plasma Wayland

[Gunnar Hjalmarsson]

Control: reassign -1 im-config 0.55-1
Control: affects -1 fcitx5
Control: severity -1 important
Control: retitle -1 im-config: Fcitx5 does not start automatically in 
KDE plasma Wayland


On 2023-03-17 10:27, Jun Nogata wrote:

Dear Maintainer,

Fcitx5 will not start in KDE Plasma Wayland.

When I go to KDE System Settings and open Regional Settings -> Input
Methods, I get the message "Cannot connect to Fcitx by DBus, is Fcitx
running?". If I press the "Run Fcitx" button here, Fcitx5 starts and
I can type Japanese.

In KDE Plasma X11, Fcitx5 is automatically started and Japanese can
be input.


Thanks for your report.

I made some tests with Kubuntu 23.04, and the problem seems to be with 
the im-config file /etc/xdg/autostart/im-launch.desktop. I see this line 
in the syslog:


2023-03-17T18:46:15.452477+01:00 gunnar-kubuntu-lunar-230317 
systemd[865]: 
/run/user/1000/systemd/generator.late/app-im\x2dlaunch@autostart.service:14: 
Ignoring unknown escape sequences: "if [ "x\$XDG_SESSION_TYPE" = 
"xwayland" ] ; then exec env IM_CONFIG_CHECK_ENV=1 im-launch true; fi"


How are those escapes added??

Anyway, it works for me in a wayland session if I drop the condition 
from the Exec line in /etc/xdg/autostart/im-launch.desktop so it looks 
like this:


Exec=sh -c 'exec env IM_CONFIG_CHECK_ENV=1 im-launch true'

But that's not what we want, is it? Suggestions for a proper way to 
address this issue are most welcome.


--
Rgds,
Gunnar Hjalmarsson

Bug#1033024: lios hangs when opening Preferences

[Gunnar Hjalmarsson]

Package: lios
Version: 2.7.2-4

Hi again Samuel!

My apologies for a somewhat vague bug report, but here we go:

There seems to be more issues with lios besides not specifying Gtk version.

The reason why I involved myself is that an Ubuntu user asked about the 
lios status on a mailing list. That made me add the patch to specify 
versions of imported libs, but the user keeps complaining. :/ This time 
about a freeze when opening Preferences. And I could reproduce that too.


I see that there are quite a few fixes upstream, and at the same time 
it's apparent that upstream does not care much about conventional 
releases. So I decided to create a new upstream tarball from the git 
repo and see if that improves things. I uploaded it to an Ubuntu PPA for 
now:


https://launchpad.net/~gunnarhj/+archive/ubuntu/lios

And yes, even if I don't really use the application, it no longer 
complains if I open the Preferences menu.


I'll check with the user and hear if they consider that version to be an 
improvement. If they do, I would like to get it into Ubuntu 23.04 at 
least. (Ubuntu is in the equivalent of "soft freeze" ATM.)


The question to you is if you would like me to add it to the repo and 
upload to experimental. Or do you possibly think that the release team 
would approve also this for Debian 12?


Let me know. I won't touch the Debian repo again until I know what you 
think.


--
Cheers,
Gunnar

Bug#1032895: lios crashes on systems where gtk4 is present

[Gunnar Hjalmarsson]

On 2023-03-13 18:09, Samuel Thibault wrote:

Gunnar Hjalmarsson, le lun. 13 mars 2023 17:53:01 +0100, a ecrit:

@Samuel: I'm about to upload a fix in the form of an NMU to
experimental.


I guess something like this is needed:

https://gitlab.com/smc/ibus-braille/-/merge_requests/1/diffs


Yes, precisely. So you upstreamed that ibus-braille fix. Nice! :)

But in this case the fix is already done upstream.


Please consider to fix it in Debian 12.


Yes, I'll have a look.


Great.

--
Gunnar

Bug#1032895: lios crashes on systems where gtk4 is present

[Gunnar Hjalmarsson]

@Samuel: I'm about to upload a fix in the form of an NMU to 
experimental. Please consider to fix it in Debian 12.


--
Cheers,
Gunnar

Bug#1032895: lios crashes on systems where gtk4 is present

[Gunnar Hjalmarsson]

Package: lios
Version: 2.7.2-3
Severity: important

Hi!

lios is broken on systems where gtk4 is present. Example on Ubuntu 22.04:

$ lios
/usr/lib/python3/dist-packages/lios/ui/gtk/text_view.py:21: PyGIWarning: 
Gtk was imported without specifying a version first. Use 
gi.require_version('Gtk', '4.0') before import to ensure that the right 
version gets loaded.

  from gi.repository import Gtk
/usr/lib/python3/dist-packages/lios/ui/gtk/widget.py:24: PyGIWarning: 
Atk was imported without specifying a version first. Use 
gi.require_version('Atk', '1.0') before import to ensure that the right 
version gets loaded.

  from gi.repository import Atk
Traceback (most recent call last):
  File "/usr/bin/lios", line 3, in 
from lios.main import *
  File "/usr/lib/python3/dist-packages/lios/main.py", line 27, in 
from lios import scanner, editor, imageview, cam, ocr, preferences, 
speech, train_tesseract
  File "/usr/lib/python3/dist-packages/lios/editor.py", line 20, in 

from lios.ui.gtk import text_view, tree_view, widget, dialog, 
file_chooser, containers, window
  File "/usr/lib/python3/dist-packages/lios/ui/gtk/widget.py", line 
166, in 

class Separator(Gtk.HSeparator):
  File "/usr/lib/python3/dist-packages/gi/overrides/__init__.py", line 
32, in __getattr__

return getattr(self._introspection_module, name)
  File "/usr/lib/python3/dist-packages/gi/module.py", line 123, in 
__getattr__

raise AttributeError("%r object has no attribute %r" % (
AttributeError: 'gi.repository.Gtk' object has no attribute 'HSeparator'

Bug#1032347: gnome-control-center: Keyboard settings: disabling the 'Compose Key' is not persisted in user dconf settings

[Gunnar Hjalmarsson]

Control: notforwarded -1
Control: tags -1 unreproducible

I tried again.

* Set Left Super as the Compose key

* $ gsettings get org.gnome.desktop.input-sources xkb-options
  ['compose:lwin']

* Disabled the Compose Key control

* $ gsettings get org.gnome.desktop.input-sources xkb-options
  @as []

* Logged out and logged in again

* $ gsettings get org.gnome.desktop.input-sources xkb-options
  @as []

So what is it on your system which causes 'compose:lwin' to be set 
behind the scenes? Since I can't reproduce the issue, I doubt it is 
gnome-control-center.


Probably we should wait for somebody else to do the above steps. In the 
meantime I dropped the forwarding of this bug, so people don't think 
it's being handled upstream, and since I'm pretty sure that the issue is 
not related to that merge request.


--
Gunnar

Bug#1032347: gnome-control-center: Keyboard settings: disabling the 'Compose Key' is not persisted in user dconf settings

[Gunnar Hjalmarsson]

James Addison wrote:

I agree that '@as []' is written to the 'xkb-options' config entry
momentarily after disabling the Compose Key.

However, a divergence/repro does appear (repeatably) on this system:

After logging out and back in again, the entry has been rewritten:

  $ dconf read /org/gnome/desktop/input-sources/xkb-options
  ['compose:lwin']


That indicates a problem with the ~/.config/dconf/user file, doesn't it? 
Maybe try to rename it to e.g. user.bak, relogin, and see how it behaves 
with a fresh ~/.config/dconf/user file.


--
Gunnar

Bug#1032347: gnome-control-center: Keyboard settings: disabling the 'Compose Key' is not persisted in user dconf settings

[Gunnar Hjalmarsson]

James Addison wrote:

However: in the particular case of disabling the 'Compose Key' (which
has a non-empty default), the setting is not persisted.

To explain another way: although disabling the 'Compose Key' using
the keyboard panel takes effect in the current session, it is
restored to the default value ('Left Super' in this case) after the
user logs out and logs back in.


I can't reproduce that behavior on my Debian testing.


This seems to be because when the 'Compose Key' is disabled, there is
no configuration entry for it written to the user's relevant dconf
entry, which is '/org/gnome/desktop/input-sources/xkb-options'.


For me there is. If I choose Left Super as the Compose key I can confirm 
it instantly this way:


$ gsettings get org.gnome.desktop.input-sources xkb-options
['compose:lwin']

And if I disable the Compose Key control:

$ gsettings get org.gnome.desktop.input-sources xkb-options
@as []


As a workaround it is possible to use the 'dconf' command-line
interface to configure an empty mapping for the compose key:

  $ dconf write /org/gnome/desktop/input-sources/xkb-options "['compose:none']"


I don't think "compose:none" is a valid XKB option. And you really 
shouldn't need to do that.



It looks like this could be the same issue as reported in #1027003,
except for a different key within the same settings panel.


Similar indeed, but not same issue I think. Before I added a patch as a 
fix of #1027003, there was no way to disable the Alternate Characters 
Key control. But a way to disable the Compose Key control was and is 
present via code which has been committed upstream.


--
Cheers,

Gunnar Hjalmarsson

Bug#1029821: change gnome-desktop's default choice of Japanese input methods for Debian

[Gunnar Hjalmarsson]

On 2023-03-03 13:21, James Addison wrote:

I also noticed that some of gnome-desktop's default locale-to-input-source
mappings provide multiple entries, delimited by the '+' character:

https://gitlab.gnome.org/GNOME/gnome-desktop/-/blob/43.2/libgnome-desktop/default-input-sources.h#L31


That's a misconception. The '+' character is there to specify a layout 
variant. So "ch+fr" means the "French (Switzerland)" keyboard layout.


--
Gunnar

Bug#1029821: change gnome-desktop's default choice of Japanese input methods for Debian

[Gunnar Hjalmarsson]

X-Debbugs-CC: s...@debian.org, z...@debian.org, ken...@xdump.org, 
yy.y.ja...@gmail.com, iwama...@debian.org, debian-i...@lists.debian.org, 
debian-japan...@lists.debian.org, m...@packages.debian.org, 
ibus-an...@packages.debian.org


On 2023-03-03 12:52, James Addison wrote:

If it's true that the cause is that 'tasksel' and 'gnome-initial-setup'
are mismatched, then we could apply a fix in either one.

Given that we have an existing patch available for 'gnome-initial-desktop',
I've opened a corresponding 'tasksel' changeset with the mirrored side of
the fix at:

https://salsa.debian.org/installer-team/tasksel/-/merge_requests/25


While either one would address the inconsistency, most Japanese users 
seem to prefer mozc over anthy. So the two routes are not equally good.


Please do not ignore the user preferences.

--
Gunnar Hjalmarsson

Bug#1029821: change gnome-desktop's default choice of Japanese input methods for Debian

[Gunnar Hjalmarsson]

Hi!

I'm commenting on this with my Ubuntu glasses on. :/

On 2023-03-02 10:42, Simon McVittie wrote:

Is there consensus among Japanese-speaking users of Debian that mozc
is a better default for all Japanese speakers, including new users
who are not familiar with GNOME or Debian?

I want to avoid changing this from anthy to mozc-jp, and then getting
a second bug report from a different Japanese user saying that we
need to change it back!


My impression from the Ubuntu side is that there is a consensus. 
ibus-mozc has been preferred over ibus-anthy since Ubuntu 16.04 at the 
request of Japanese Ubuntu users. I can't recall any user request since 
then to change the default Japanese IBus IM.


There is a point of concern, though: mozc upstream seems to be moving 
towards replacing gtk with qt. Since the main Ubuntu ISO does not 
include qt, that may result in an undesired change of Ubuntu's default 
in the end. Not sure if qt would be a problem for Debian.


But even if there is a risk that Debian would need to change again in a 
later release, the current situation is an inconsistency between the 
installer and gnome-initial-setup. So to me it sounds reasonable to make 
the suggested change to mozc-jp in Debian 12. Doing it the other way 
around wouldn't have much user support AFAICT.



Looking at #984875 and #983653, I also see a mention of mozc only
being available on certain architectures: it's available on x86, ARM
and riscv64, but not on mips*el, ppc64el or s390x.


I don't know the reasoning behind that. Not long ago riscv64 was added 
to the list due to , and it proved to 
build on that arch without issues. So possibly mozc can be built on more 
architectures without a hassle, if that is desired.



I'm also concerned that mozc still depends on GTK 2 (a switch to GTK
3 was tried and then reverted, see #967641).


I did that reversal, sorry. But it was for a good reason. The patch is 
still in the source (but disabled), and maybe just needs a bit more work.


--
Gunnar

Bug#1031901: Stop setting GTK_IM_MODULE in GNOME on Xorg sessions

[Gunnar Hjalmarsson]

Package: im-config
Version: 0.55-1
Tags: trixie

Soon after the release of gnome-settings-daemon 43.0 (which I assume 
will be the version used in Debian 12), upstream pushed this commit to 
master:


https://gitlab.gnome.org/GNOME/gnome-settings-daemon/-/commit/27bc0889

When submitting (and fixing) https://bugs.debian.org/1031227 I wasn't 
aware of that g-s-d commit.


Anyway, letting im-config set GTK_IM_MODULE=ibus in GNOME on Xorg 
sessions is motivated in Debian 12. The news is that we can stop it from 
doing so once g-s-d 44 makes it to unstable/testing.


--
Gunnar

Bug#1014052: ibus:After rebooted, I must do `ibus-daemon -rxd` change japanese to anthy with kanji key.

[Gunnar Hjalmarsson]

Control: affects -1 i3

For the record I installed gdm3 (and a lot of dependencies) on my 
Xubuntu test installation, and accomplished these steps:


On 2022-09-11 01:44, Gunnar Hjalmarsson wrote:

1. Change your ~/.xinput file to "none" using this command:

   im-config -n none

2. Change your default display manager to GDM3.

3. Reboot and log in.

4. Find out if ibus-daemon is still running:

   ps aux | grep ibus


Found that ibus-daemon was not started. Tested with logging in to both a 
Xubuntu and a Cinnamon session.


Actually I tried to use i3 too, but the barrier to set it up proved to 
be high, and I'm not willing to spend the time needed for that.


So even if GDM is used as login manager, it's unlikely that the presence 
of the systemd service files interferes with the IBus setup for 
non-GNOME sessions.


It's possible that there is some issue with how i3 interacts with ibus 
or im-config or both, and I'd say that the i3 maintainers should better 
get involved if the intention is that input methods can be conveniently 
configured also with i3. Marked this bug as affecting i3.


--
Rgds,
Gunnar

Bug#1031227: GTK_IM_MODULE in GNOME on Xorg sessions again

[Gunnar Hjalmarsson]

Package: im-config
Version: 0.54-1

It looks like this commit:

https://salsa.debian.org/input-method-team/im-config/-/commit/70ae9066

was reverted prematurely.

In Debian 11 it works fine to not set GTK_IM_MODULE in GNOME on Xorg 
sessions. Then this issue showed up:


https://gitlab.gnome.org/GNOME/gnome-settings-daemon/-/issues/682

and we chose to set GTK_IM_MODULE=ibus temporarily until the claimed 
gnome-settings-daemon fix had made it to Debian. But the discussion at 
that upstream issue left some doubts about the need to keep doing 
something to compensate for the code refactoring in 
gnome-settings-daemon 42. And yes, there is a reason to still set 
GTK_IM_MODULE=ibus in GNOME on Xorg sessions.


On a GNOME desktop with only non-IBus input sources enabled but some 
IBus IM installed:


* Log in to a GNOME on Xorg session
* Go to Settings -> Keyboard and add some IBus IM to the input sources
* Switch to the IBus IM
* Find that you can't input anything but latin letters
* Log out and log in again
* Find that you now can use the IBus IM as expected

The need to relogin in this situation is a bug IMO. With 
GTK_IM_MODULE=ibus set, there is no such need.


--
Gunnar

Bug#1029707: Maybe set DejaVu Sans Mono as default font for Arabic

[Gunnar Hjalmarsson]

On 2023-02-03 17:20, Simon McVittie wrote:

On Fri, 03 Feb 2023 at 11:49:34 +0100, Gunnar Hjalmarsson wrote:

I chose to set "Monospace" when needed instead of specifying "DejaVu Sans
Mono" explicitly.


You said in the new patch that fontconfig prefers DejaVu Sans Mono as
its implementation of Monospace in Arabic-script locales. To confirm,
is that true upstream, or just in Debian/Ubuntu, or just in Ubuntu?


It's upstream, more specifically /etc/fonts/conf.d/60-latin.conf. And 
you get this result:


$ LC_CTYPE=ar_EG.UTF-8 fc-match monospace
DejaVuSansMono.ttf: "DejaVu Sans Mono" "Book"

also with fontconfig 2.14 even if 60-latin.conf now prefers Noto for 
most other locales.



* Consider an Arabic Debian user who opens Tweaks and picks some beautiful
monospace font with e.g. the text editor in mind. With the patch applied,
that user would not screw up the rendering of Arabic in gnome-terminal
unknowingly.


Equally, if another Arabic-speaking Debian user opens Tweaks and picks
a monospace font that *does* work OK in vte terminals, they would be
surprised and probably consider it to be a bug for gnome-terminal not to
respect that preference?


Fair enough. This hack to fix a known issue comes with a cost. Thanks to 
your input we no longer override the font size at least. But note that 
the Arabic speaking reporter of the Ubuntu bug sees the issue in VTE 
terminals with all other fonts he has tested.



* With the patch also in Debian, we avoid to add to the Ubuntu/Debian delta,
which is always desirable. :)


If it's good enough for Debian, is it good enough for upstream?


The approach to special case Arabic might be, but probably not that 
particular code. Doing it all in one single block of code makes sense in 
a patch since it makes maintenance easier. But I imagine that it would 
be a rather time consuming exercise to get some equivalent change into 
upstream, and am not inclined ATM to do that. Maybe better to do it for 
gnome-console later, if a decision is made to make that terminal the 
default.



Avoiding adding to the Debian/upstream delta is at least as valuable
as avoiding adding to the Ubuntu/Debian delta.

Or if it's not suitable for upstream, I think we should only apply it
in Debian if the benefit *to Debian* is worth the cost of divergence
from upstream.  The GNOME team already has too many places where someone
applied a patch several years ago, none of us know whether it's safe
to remove, and it's adding maintenance cost every time we update to a
upstream release.


I'm familiar with that problem...

On the Ubuntu side the benefit of having this patch is worth the cost 
without doubt, since we have a *default* which triggers the issue for 
Arabic. I guess you will need to take the decision for Debian. ;)



This is particularly problematic for areas like localization into a
specific language or script, which relatively few people understand in
detail. I spent a significant amount of time doing the research that
led to https://gitlab.gnome.org/GNOME/gtk/-/issues/183 eventually being
fixed upstream, 10+ years after the change was made in Debian... but I
wouldn't have had to spend time digging up the reasoning if the change
had been proposed upstream at the time!


So you mean that doing it only in Ubuntu and possibly Debian would be to 
do a similar mistake? Maybe. But at least the patch header is now clear 
about the background.


--
Rgds,
Gunnar

Bug#1029707: Maybe set DejaVu Sans Mono as default font for Arabic

[Gunnar Hjalmarsson]

Control: tags -1 - moreinfo

Hi again, Simon!

On 2023-01-26 15:50, Simon McVittie wrote:

Another option would be to change the gnome-terminal patch so that if
the locale is Arabic *and* the default font is either "Monospace" or
"Ubuntu Mono", we replace it with "DejaVu Sans Mono" of the same
size. That would be a more narrowly-scoped version that at least
doesn't interfere with users' ability to set a different size,
although it would still require non-upstreamable patches in multiple
packages.


I like that approach and have now rewritten the patch:

https://salsa.debian.org/gnome-team/gnome-terminal/-/merge_requests/9

I chose to set "Monospace" when needed instead of specifying "DejaVu 
Sans Mono" explicitly.


As regards other packages, my thought is to limit this kind of tweak to 
the terminals we ship by default, i.e. gnome-terminal currently and 
maybe gnome-console later.


While the importance of the patch is much greater in Ubuntu (with Ubuntu 
Mono as default), personally I think it may be useful in Debian too 
after all:


* Consider an Arabic Debian user who opens Tweaks and picks some 
beautiful monospace font with e.g. the text editor in mind. With the 
patch applied, that user would not screw up the rendering of Arabic in 
gnome-terminal unknowingly.


* With the patch also in Debian, we avoid to add to the Ubuntu/Debian 
delta, which is always desirable. :)


So even if the target branch of the MR is ubuntu/master, it would be 
great if you could review it with Debian in mind. If I get a green light 
from you, I will add the patch to Debian instead.


--
Cheers,
Gunnar

Bug#1029707: Maybe set DejaVu Sans Mono as default font for Arabic

[Gunnar Hjalmarsson]

On 2023-01-27 00:55, Jeremy Bicha wrote:

On Thu, Jan 26, 2023 at 5:39 PM Gunnar Hjalmarsson
 wrote:

That detail made me curious. I suppose it's related to this
commit:

https://gitlab.freedesktop.org/fontconfig/fontconfig/-/commit/ad70d785

Which is not only about monospace, but affects most Debian users, >> also for 
sans-serif and serif, and also for web browsing, since
fonts-noto-core is installed by default (probably due to the meta
package libreoffice).

That's a pretty radical change to come from fontconfig upstream.
Hello Noto, goodbye DejaVu. Was it even discussed anywhere?


The individual who made the change upstream started this discussion:
https://fedoraproject.org/wiki/Changes/DefaultToNotoFonts


Not much of discussion, though. ;) But thanks for the link with the 
rationale from a Fedora POV.


Again, I support the change, and my question about a possible discussion 
was merely out of curiosity.


--
Gunnar

Bug#1029707: Maybe set DejaVu Sans Mono as default font for Arabic

[Gunnar Hjalmarsson]

On 2023-01-26 15:50, Simon McVittie wrote:

* "Monospace" is a fontconfig alias intended to point to a generic monospace
   font, which until recently was resolved to DejaVu Sans Mono by
   fontconfig. Since the recent upgrade to fontconfig 2.14, "Monospace"
   now prefers Noto Sans Mono instead, if available.


That detail made me curious. I suppose it's related to this commit:

https://gitlab.freedesktop.org/fontconfig/fontconfig/-/commit/ad70d785

Which is not only about monospace, but affects most Debian users, also 
for sans-serif and serif, and also for web browsing, since 
fonts-noto-core is installed by default (probably due to the meta 
package libreoffice).


That's a pretty radical change to come from fontconfig upstream. Hello 
Noto, goodbye DejaVu. Was it even discussed anywhere?


Ubuntu does not install the libreoffice meta package and fonts-noto-core 
by default, at least not yet. But the new version of 60-latin.conf will 
be noticed also in Ubuntu: As soon as you install fonts-noto-core for 
some reason, your main font for web browsing will be switched from 
DejaVu to Noto.


Personally I think it's a step in the right direction. Using Noto as 
default font opens doors to much easier handling of font configuration 
for several non-latin languages. And that would be even easier if the 
packaging of fonts-noto-core could be split, so we at least separate the 
basic latin fonts from the rest. (But this gnome-terminal bug is really 
the wrong place to talk about that.)


--
Gunnar

Bug#1029707: Maybe set DejaVu Sans Mono as default font for Arabic

[Gunnar Hjalmarsson]

Thanks for your reply, Simon. It helped me realize a significant 
difference between Ubuntu and Debian with respect to desktop configuration:


While Ubuntu sets a *specific* font (Ubuntu Mono) as the default 
monospace font, Debian just sets "Monospace" and with that defers to 
fontconfig.


To summarize: I no longer think that the issue affects Debian. It seems 
to be an Ubuntu specific thing.


On 2023-01-26 15:50, Simon McVittie wrote:

Is this the patch you mean?
https://salsa.debian.org/gnome-team/gnome-terminal/-/merge_requests/8/diffs


Yes.


I notice that it overrules the desktop-wide user preference for the font
and font size, and sets 12pt DejaVu Sans Mono unconditionally. That
doesn't seem ideal, and in particular I could see it being an
accessibility problem for users who have difficulty reading monospaced
text at 12pt size and have configured a larger font desktop-wide.


It does so for Arabic users only. And the primary problem for those 
users is not the font size, but other gnome-terminal rendering issues.


At the same time, please note that all users of gnome-terminal, 
including the Arabic ones, can set a custom font in Preferences, and 
there also determine a font size specific for gnome-terminal.



I don't think this patch would be upstreamable,


Neither do I.


So that we can get the requirements right, is this a fair summary of the
situation?

* gnome-terminal uses the equivalent of
   `gsettings get org.gnome.desktop.interface monospace-font-name`
   as its default font.

* Upstream, GNOME has "Source Code Pro 10" as the default for that
   settings key.

* Downstream, neither Debian nor Ubuntu has Source Code Pro available, so
   we both override it. Ubuntu uses "Ubuntu Mono" at some suitable size
   (I don't know what size). Debian uses "Monospace 11".

* "Monospace" is a fontconfig alias intended to point to a generic monospace
   font, which until recently was resolved to DejaVu Sans Mono by
   fontconfig. Since the recent upgrade to fontconfig 2.14, "Monospace"
   now prefers Noto Sans Mono instead, if available.

* Both Ubuntu Mono and Noto Sans Mono are perfectly acceptable fonts for
   most uses of both Arabic and non-Arabic monospace text (e.g. in
   gedit) and are generally considered preferable to DejaVu, but as
   a result of some special properties of terminal emulation, vte-based
   terminals specifically (like gnome-terminal and gnome-console) cannot
   produce good Arabic text rendering with Ubuntu Mono or Noto Sans Mono.


Well, I no longer think that Noto Sans Mono has so much to do with it 
for monospace rendering of Arabic. See more below.



* Therefore, you want to continue to use Ubuntu Mono (on Ubuntu)
   or Noto Sans Mono (on Debian) as the default monospace font for ordinary
   text (such as in web browsers, devhelp and gedit), but you also want to
   replace those fonts with DejaVu Sans Mono for the specific use-case of
   vte-based terminal emulators running in an Arabic locale.


The Ubuntu and Ubuntu Mono fonts are not used by default for web 
browsing, but only for the Ubuntu desktop.


Besides those comments, your bullet points summarize my understanding of 
the situation.



Looking at codesearch, I see that gedit-plugins, pluma, eog-plugins,
anjuta, gnome-console, xfce4-terminal, tilix, guake and terminator also
have approximately the same behaviour as gnome-terminal for something
that looks at a glance as though it might be a vte-based terminal
emulator. Presumably we don't want to apply non-upstreamable patches to
all of those...?


That's a good point, but probably an Ubuntu only problem. At least we 
have now addressed the terminal which is currently shipped by default.



One option for avoiding this issue in Debian would be to revert the
fontconfig change that made fontconfig prefer Noto Sans Mono, which
would take it back to resolving Monospace to DejaVu Sans Mono by default,
as it did until shortly before the bookworm freeze. That wouldn't solve
anything in Ubuntu, though.


Actually I'm not sure that would be needed in Debian either. If you run:

fc-list :lang=ar | grep -i mono

you'll find that Noto fonts are absent in the resulting list. And that 
is reflected in the fontconfig behavior for an Arabic user:


$ LC_CTYPE=ar_EG.UTF-8 fc-match -s monospace | head -2
DejaVuSansMono.ttf: "DejaVu Sans Mono" "Book"
NotoSansMono-Regular.ttf: "Noto Sans Mono" "Regular"

So the issue may not be present in Debian at all. (Any Arabic speaking 
user who can confirm that?)



Or does the fontconfig configuration language allow locale-sensitive
font choices to be made, so that we could prefer DejaVu Sans Mono over
Noto Sans Mono, but only for Arabic locales?


Yes, indeed it does, but that would probably not be necessary either.


Another option would be to change the gnome-terminal patch so that if the
locale is Arabic *and* the default font is either "Monospace" or "Ubuntu
Mono", we replace it with "DejaVu Sans Mono" of the same size. That would

Bug#1029707: Maybe set DejaVu Sans Mono as default font for Arabic

[Gunnar Hjalmarsson]

Package: src:gnome-terminal
Version: 3.46.7-1

Ubuntu just added a patch to set DejaVu Sans Mono as the default font in 
gnome-terminal for Arabic users. Related discussions:


https://discourse.ubuntu.com/t/33413

https://launchpad.net/bugs/2002290

For other users and applications Ubuntu uses Ubuntu Mono by default for 
the desktop, but that font has proved to result in poor rendering in 
terminal of Arabic script. Even if Debian does not have Ubuntu Mono, it 
struck me that there may still be a need to include the patch in Debian.


Debian currently uses "Monospace" by default, which means — if I 
understand it correctly — that it queries fontconfig:


$ fc-match monospace
NotoSansMono-Regular.ttf: "Noto Sans Mono" "Regular"

It looks like the Noto fonts are present in Debian since they are pulled 
by libreoffice, and Noto is given higher precedence than DejaVu by the 
font configuration.


In the above linked discourse topic M.Hanny Sabbagh let us know that he 
has tested multiple monospace fonts in gnome-terminal, and that all of 
them — except for DejaVu Sans Mono — suffer from the rendering issue 
(spaces between letters + overlapping of some letters). I have asked if 
Noto Sans Mono was one of the fonts he tested.


If the issue is present also with Noto Sans Mono, I would recommend that 
we include the above mentioned gnome-terminal patch in Debian too.


--
Cheers,
Gunnar

Bug#1029112: Surprise build issue with ibus-libzhuyin

[Gunnar Hjalmarsson]

On 2023-01-18 02:07, Osamu Aoki wrote:

Debian official packages are required to build without downloading
external files during their build.  (Builddd is in isolated network
environment only with access to the Debian package repository.


Yeah, that's what I thought — thanks for confirming. Which made my 
confusion even worse...


But the explanation proved to be that debian/watch made uscan download 
another upstream tarball than the one we need to use. Boyuan spotted 
that issue and fixed it. Thanks Boyuan!


--
Gunnar

Bug#1029112: Surprise build issue with ibus-libzhuyin

[Gunnar Hjalmarsson]

Package: src:ibus-libzhuyin
Version: 1.10.2-1
Severity: serious
Tags: ftbfs

Hello!

ibus-libzhuyin 1.10.2-1 failed to build. This is the relevant part of 
the buildlog:


Making all in model
make[4]: Entering directory '/<>/data/model'
wget http://downloads.sourceforge.net/libzhuyin/models/model13.text.tar.gz
/bin/bash: line 1: wget: command not found

And yes, it's true that wget is not included in Build-Depends. But 
previously that has not been needed. This is from the buildlog for the 
latest successful build:


Making all in model
make[4]: Entering directory '/<>/data/model'
rm -f phrase_index.bin pinyin_index.bin addon_phrase_index.bin 
addon_pinyin_index.bin bigram.db tsi.bin

gen_binary_files --table-dir ../../data/model
import_interpolation --table-dir ../../data/model < 
../../data/model/interpolation2.text

gen_unigram --table-dir ../../data/model

or just:

Making check in model
make[3]: Entering directory '/<>/data/model'
make[3]: Nothing to be done for 'check'.

I have not found any code changes which would explain the new behavior. 
And when trying (in an Ubuntu PPA) to add wget to Build-Depends, it 
failed to resolve the download URL. (It builds fine on my harddisk, though.)


I figured out that this patch would help it build successfully:

--- a/data/Makefile.am
+++ b/data/Makefile.am
@@ -27,7 +27,6 @@

  SUBDIRS = \
  icons \
-model \
  $(NULL)

  appdatadir = @datadir@/appdata

But since I don't know how that would affect the functionality of the 
package, I have left it in its failed state for now.


In other words: I need help to solve this.

--
Rgds,
Gunnar

Bug#1028963: Surprise restriction of the qx_cmd() function in Dh_Lib.pm

[Gunnar Hjalmarsson]

Package: debhelper
Version: 13.11.1

Hello!

The fix of https://bugs.debian.org/1016354 resulted in a regression so 
Ubuntu's debhelper extension dh-translations stopped working.


This is the commit:

https://salsa.debian.org/debian/debhelper/-/commit/62a8608e

The qx_cmd() function has been used conveniently in dh_translations to 
grab the output from a few commands which make use of pipes. Now that 
doesn't work any longer. It was resolved for now by copying the qx_cmd() 
function as it looked like before commit 62a8608e into dh_translations. 
Please see the attached diff.


This raises the question if there is a need also for a 'cleaner' qx_cmd 
function. Maybe "complex_qx_cmd" (compare complex_doit).


--
Cheers,

Gunnar Hjalmarsson--- /usr/bin/dh_translations.orig	2019-02-05 16:05:37.0 +0100
+++ /usr/bin/dh_translations	2023-01-14 09:15:08.190676370 +0100
@@ -55,6 +55,26 @@
 
 my ($domain, $use_intltool, $meson_builddir);
 
+# This is the version of the qx_cmd() function in Dh_Lib.pm before
+# https://salsa.debian.org/debian/debhelper/-/commit/62a8608
+sub qx_meson_cmd {
+	my (@cmd) = @_;
+	my ($output, @output);
+	open(my $fd, '-|', @cmd) or error('fork+exec (' . escape_shell(@cmd) . "): $!");
+	if (wantarray) {
+		@output = <$fd>;
+	} else {
+		local $/ = undef;
+		$output = <$fd>;
+	}
+	if (not close($fd)) {
+		error("close pipe failed: $!") if $!;
+		error_exitcode(escape_shell(@cmd));
+	}
+	return @output if wantarray;
+	return $output;
+}
+
 # figure out intltool usage and domain
 sub check_buildsystem {
 $use_intltool = 0;
@@ -88,7 +108,7 @@
 
 $meson_builddir = File::Spec->rel2abs($dirs[0]);
 
-my $all_domains = qx_cmd ("meson introspect '$meson_builddir' --targets | jq -r -M '.[].name | select(endswith(\"-pot\")) | sub(\"-pot\"; \"\")'");
+my $all_domains = qx_meson_cmd ("meson introspect '$meson_builddir' --targets | jq -r -M '.[].name | select(endswith(\"-pot\")) | sub(\"-pot\"; \"\")'");
 
 my @domains = split (' ', $all_domains);
 
@@ -101,10 +121,10 @@
 } else {
 # meson 0.49 changed the property name from 'name' to 'descriptive_name'
 # prevent confusion due to possible help-* domain
-my $project = qx_cmd ("meson introspect '$meson_builddir' --projectinfo | jq -r '.descriptive_name'");
+my $project = qx_meson_cmd ("meson introspect '$meson_builddir' --projectinfo | jq -r '.descriptive_name'");
 chomp $project;
 if ($project eq "null") {
-$project = qx_cmd ("meson introspect '$meson_builddir' --projectinfo | jq -r '.name'");
+$project = qx_meson_cmd ("meson introspect '$meson_builddir' --projectinfo | jq -r '.name'");
 chomp $project;
 }
 @domains = grep { $_ ne 'help-'.$project } @domains;

Bug#1028071: im-config: Does not start using startx

[Gunnar Hjalmarsson]

On 2023-01-06 14:55, wsy wrote:

Since 0.53-1, /etc/X11/Xsession.d/70im-config_launch checks
"$XDG_SESSION_TYPE" = "x11" before launch. I use startx from console
to start awesome wm, but $XDG_SESSION_TYPE is set to "tty" using
startx. So no ime for me since this version.


Thanks for reporting that so fast! I think I will change it to

[ "$XDG_SESSION_TYPE" != "wayland" ]

and upload instantly so the mistake doesn't make it to testing.

--
Rgds,

Gunnar Hjalmarsson

Bug#1027295: test-network-panel times out on riscv64

[Gunnar Hjalmarsson]

On 2022-12-31 00:08, Jeremy Bicha wrote:

On Thu, Dec 29, 2022, 14:21 Gunnar Hjalmarsson 
wrote:

(FWIW it builds on riscv64 in Ubuntu.)


Ubuntu doesn't run dh_auto_test for riscv64.


Hmm.. That seems to be an Ubuntu exception in dpkg which I wasn't aware of.

Thanks for pointing it out, Jeremy.

Bug#1027295: test-network-panel times out on riscv64

[Gunnar Hjalmarsson]

Package: src:gnome-control-center
Version: 1:43.2-1
Severity: important
Tags: ftbfs
X-Debbugs-CC: gunna...@debian.org

g-c-c 1:43.2-1 fails to build on riscv64:

https://buildd.debian.org/status/logs.php?pkg=gnome-control-center=riscv64

It's some kind of test timeout for test-network-panel.

While this is not an RC bug — riscv64 is not an official arch in Debian 
— it's a regression from g-c-c 1:43.1-2, so it may be worth looking at 
if we want to keep g-c-c available on riscv64. (FWIW it builds on 
riscv64 in Ubuntu.)

Bug#1027003: gnome-control-center: Pls consider keyboard patches from upstream MR

[Gunnar Hjalmarsson]

I'm about to update g-c-c to version 43.2, and will then include 
keyboard-Allow-disabling-alternate-characters-key.patch.


Let's consider this bug fixed with that. If somebody wants to improve 
the "Alternate Characters Key" control further through the other two 
patches, that can be done later.


--
Gunnar

Bug#1027003: gnome-control-center: Pls consider keyboard patches from upstream MR

[Gunnar Hjalmarsson]

Package: src:gnome-control-center
Version: 1:43.1-2
X-Debian-CC: gunna...@debian.org

Hello!

This upstream MR:

https://gitlab.gnome.org/GNOME/gnome-control-center/-/merge_requests/910

improves the Special Character Entry section in Settings -> Keyboard. 
Ubuntu applies patches with the three commits in that MR. The patches 
would apply in Debian, and I would like to find out the interest in 
adding them to debian/master as a preparation for Debian 12.


First and foremost there is this very small patch:

https://salsa.debian.org/gnome-team/gnome-control-center/-/blob/ubuntu/master/debian/patches/keyboard-Allow-disabling-alternate-characters-key.patch

Currently, by just opening the "Alternate Characters Key" window (maybe 
out of curiosity), you add lv3:ralt_switch to xkb-options. If you have a 
European keyboard layout, that particular value is probably set via the 
layout anyway, and in that case you may not even notice. But if you have 
for instance the "English (US)" or "Russian" layout, you may find that 
your Right Alt key no longer works as expected. And on top of that: The 
UI offers no way to change it back. The issue is similar to this 
upstream one:


https://gitlab.gnome.org/GNOME/gnome-control-center/-/issues/918

keyboard-Allow-disabling-alternate-characters-key.patch adds a switch to 
enable/disable the thing, and personally I think we should apply that 
patch in debian/master.


Then we have two more patches:

https://salsa.debian.org/gnome-team/gnome-control-center/-/blob/ubuntu/master/debian/patches/keyboard-For-xkb-options-have-Layout-default-toggle-and-N.patch

https://salsa.debian.org/gnome-team/gnome-control-center/-/blob/ubuntu/master/debian/patches/keyboard-Avoid-modifying-xkb-options-when-user-changes-n.patch

In short they make the "Alternate Characters Key" control smarter. A 
"None" option is added, and if you pick some other key but "Right Alt" 
to serve as the "Alternate Characters Key", "Right Alt" is automatically 
turned into a regular "Alt" key.


A problem is that one of the two latter patches adds some translatable 
strings: "Layout default", "Use layout default" and "None". So if we 
would choose to improve the functionality using those patches, we would 
end up with some strings shown untranslated in the UI for now, since the 
upstream MR !910 has not been merged yet.


It would of course be best if some GNOME dev could merge !910, so the 
new strings are passed to the GNOME translators. I don't know how to 
make that happen, though. Issue #918 was submitted almost 3 years ago.


Let me know what you think.

--
Cheers,
Gunnar Hjalmarsson

Bug#1024898: mozc: FTBFS on armel

[Gunnar Hjalmarsson]

Hi Nobuhiro,

On 2022-12-09 01:52, Nobuhiro Iwamatsu wrote:

Thanks for your help!

2022年12月9日(金) 9:03 Gunnar Hjalmarsson :

Under the assumption that it's better to have mozc without the
armel arch in testing than seeing mozc go away (see
<https://bugs.debian.org/1024829>), I'm about to do an NMU to
unstable where armel has been dropped from the lists of supported
architectures in d/control.


From the build log, the cause is Libatomic's link error. It is
possible to fix this.


Ah, great!


I will return Armel.


Ok. Since I uploaded in the meantime, I suppose that adding back armel 
may need to pass the NEW queue... Sorry for that inconvenience.


--
Cheers,
Gunnar

Bug#967641: mozc: depends on deprecated GTK 2

[Gunnar Hjalmarsson]

Control: reopen -1

The fix of this bug was reverted in mozc 2.28.4715.102+dfsg-2.1 due to 
<https://bugs.debian.org/1023525>, so reopening.


--
Gunnar Hjalmarsson

Bug#1024898: mozc: FTBFS on armel

[Gunnar Hjalmarsson]

On 2022-12-01 11:28, Gunnar Hjalmarsson wrote:

How important is it that mozc is available on armel? Would it be an
option to drop the armel support in bookworm?


Under the assumption that it's better to have mozc without the armel 
arch in testing than seeing mozc go away (see 
<https://bugs.debian.org/1024829>), I'm about to do an NMU to unstable 
where armel has been dropped from the lists of supported architectures 
in d/control.


--
Gunnar

Bug#1025332: Subtle build failure

[Gunnar Hjalmarsson]

On 2022-12-02 18:46, Shengjing Zhu wrote:

On Sat, Dec 3, 2022 at 1:09 AM Gunnar Hjalmarsson  wrote:


make[1]: *** [debian/rules:23: override_dh_auto_test] Error 1



I can't reproduce the build failure locally in Debian testing or
Ubuntu development environments.


See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1025312


Nice catch, Shengjing Zhu. Thanks!

--
Gunnar

Bug#1025332: Subtle build failure

[Gunnar Hjalmarsson]

package: src:ibus-cangjie
version: 2.4-6
severity: serious
tags: ftbfs

The buildlog in unstable (on all) states:

make[1]: *** [debian/rules:23: override_dh_auto_test] Error 1

Tail log to give context:

# SKIP:  0
# XFAIL: 0
# FAIL:  0
# XPASS: 0
# ERROR: 0
=
make[6]: Leaving directory '/<>'
make[5]: Leaving directory '/<>'
make[4]: Leaving directory '/<>'
make[3]: Leaving directory '/<>'
make[2]: Leaving directory '/<>'
rm -fr -- /tmp/dh-xdg-rundir-1fkxdzYs
make[1]: *** [debian/rules:23: override_dh_auto_test] Error 1
make[1]: Leaving directory '/<>'
make: *** [debian/rules:17: build-indep] Error 2

ibus-cangjie 2.4-5 built successfully in September, and the only
package file which has changed since then is debian/watch.

I can't reproduce the build failure locally in Debian testing or
Ubuntu development environments.

--
Gunnar Hjalmarsson