Bug#1033571: unblock: keyman/16.0.139-4
Hi Eberhard, On 27-04-2023 16:48, Eberhard Beilharz wrote: After the installation of ibus-keyman the ibus daemon needs to be restarted which is what the `postinst` script tries to do. It restarts or stops ibus-daemon, then checks if ibus-daemon is running - if not it will start it. If any of these steps fail we still want to successfully finish the installation. Since then ibus is not running the user will not be able to see any installed Keyman keyboards and will have to logout or reboot which will start ibus. But without the failure, how will the user know this? Also, please consider policy 10.4 which says: """ Every script should use set -e or check the exit status of every command. """ Which you are moving away from. Is the failure to start happening that often? Is there a bug report about it? If we return with a non-exit code from the postinst script instead the installation of ibus-keyman aborts. The user can then try to install again which might lead into the same error, leaving him with an uninstallable ibus-keyman where the only thing that failed was the failure to (re-)start ibus. It feels weird to use "only" when referring to failure to (re)start a service. Can you elaborate? Shouldn't that have it's own RC bug? Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#1033571: unblock: keyman/16.0.139-4
-set -e +# Don't call `set -e`. Even if some commands should fail, it's still +# worth running the rest of the commands. Can you elaborate? After the installation of ibus-keyman the ibus daemon needs to be restarted which is what the `postinst` script tries to do. It restarts or stops ibus-daemon, then checks if ibus-daemon is running - if not it will start it. If any of these steps fail we still want to successfully finish the installation. Since then ibus is not running the user will not be able to see any installed Keyman keyboards and will have to logout or reboot which will start ibus. If we return with a non-exit code from the postinst script instead the installation of ibus-keyman aborts. The user can then try to install again which might lead into the same error, leaving him with an uninstallable ibus-keyman where the only thing that failed was the failure to (re-)start ibus. Since all of postinst deals with ibus-daemon which is not part of the ibus-keyman package it seems to me that ignoring failures would be acceptable. This means the admin (who in most cases will be an ordinary user) won't be aware of problems with the postinst script, but he might notice ibus-daemon not running. Ignoring these postinst errors makes it harder for the developer to notice and fix errors in the postinst script, but IMO gives a better experience for the ordinary user. Did I miss something but is the *only* change upstream the addition echo? That might well be the only change. New upstream versions get released simultaneously with the same version on all platforms, so it can happen that there is a new version without any changes on a platform. IMO this still has value since it simplifies dealing with help requests (the latest version of the binary is the latest version in the source code). Doesn't feel very appropriate at this stage... That's your call. I still would like to see this version be available in Bookworm, but if you decide that's not an appropriate change I can live with that. Thanks, Eberhard OpenPGP_0xE9140597606020D3.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Bug#1033571: unblock: keyman/16.0.139-4
Hi Eberhard, On 01-04-2023 20:23, Paul Gevers wrote: -set -e +# Don't call `set -e`. Even if some commands should fail, it's still +# worth running the rest of the commands. Can you elaborate? Ping. Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#1033571: unblock: keyman/16.0.139-4
Control: tags -1 moreinfo On 27-03-2023 18:15, Eberhard Beilharz wrote: While keyman has autopkgtests and so would qualify for automatic migration, the tests are skipped on s390x. Ack. Included are only small changes: one is a small fix in the postinst script, -set -e +# Don't call `set -e`. Even if some commands should fail, it's still +# worth running the rest of the commands. Can you elaborate? I could imagine you want to run the rest of the commands, but if there is any failure, shouldn't that be recorded and used as the exit code? With the current change, the admin isn't going to be aware of issues at all, which feels weird (why would you run the postinst then in the first place). See also policy 6.1 [1]. > Another reason why I'd like to get this version approved is that it brings the version in Debian on par with the upstream version which simplifies user help requests. Did I miss something but is the *only* change upstream the addition echo? Doesn't feel very appropriate at this stage... Paul [1] https://www.debian.org/doc/debian-policy/ch-maintainerscripts.html#introduction-to-package-maintainer-scripts OpenPGP_signature Description: OpenPGP digital signature
Bug#1033571: unblock: keyman/16.0.139-4
Package: release.debian.org
Severity: normal
User:release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc:debian-input-met...@lists.debian.org,e...@sil.org
Please unblock package keyman.
[ Reason ]
While keyman has autopkgtests and so would qualify for automatic migration, the
tests are skipped on s390x.
The reason is that Keyman doesn't yet support big endian architecture and so
can't run on s390x (even though it's
possible to build it on that platform it won't work). See upstream
bughttps://github.com/keymanapp/keyman/issues/5111.
Included are only small changes: one is a small fix in the postinst script, the
other is an update of a timestamp in a
locale. It also excludes s390x from building since that makes more sense than
building an unusable library.
Another reason why I'd like to get this version approved is that it brings the
version in Debian on par with the upstream
version which simplifies user help requests.
[ Impact ]
The user won't notice any difference, but it would be helpful for the support
team if the users would use the same version
that is used on the other platforms.
[ Tests ]
Manually installed the binaries and verified that things work as expected.
[ Risks ]
Changes are minimal. I can't think of any negative 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
unblock keyman/16.0.139-4
diff -Nru keyman-16.0.138/core/VERSION.md keyman-16.0.139/core/VERSION.md
--- keyman-16.0.138/core/VERSION.md 2023-02-01 04:55:31.0 +0100
+++ keyman-16.0.139/core/VERSION.md 2023-03-16 08:24:24.0 +0100
@@ -1 +1 @@
-16.0.138
\ No newline at end of file
+16.0.139
\ No newline at end of file
diff -Nru keyman-16.0.138/crowdin.yml keyman-16.0.139/crowdin.yml
--- keyman-16.0.138/crowdin.yml 2023-01-31 19:04:42.0 +0100
+++ keyman-16.0.139/crowdin.yml 2023-03-16 08:22:51.0 +0100
@@ -59,6 +59,7 @@
locale:
de: de
fr: fr
+kn: kn
- source: /windows/src/desktop/setup/locale/en/strings.xml
dest: /windows/setup/strings.xml
@@ -68,6 +69,7 @@
locale:
de: de
fr: fr
+kn: kn
# iOS files
diff -Nru keyman-16.0.138/debian/changelog keyman-16.0.139/debian/changelog
--- keyman-16.0.138/debian/changelog2023-02-11 18:39:13.0 +0100
+++ keyman-16.0.139/debian/changelog2023-03-24 16:05:07.0 +0100
@@ -1,3 +1,29 @@
+keyman (16.0.139-4) unstable; urgency=medium
+
+ * debian/tests: Revert previous change and ignore s390x from autopkgtests
+
+ -- Eberhard Beilharz Fri, 24 Mar 2023 16:05:07 +0100
+
+keyman (16.0.139-3) unstable; urgency=medium
+
+ * debian/tests: Run autopkgtests on s390x but immediately return
+
+ -- Eberhard Beilharz Wed, 22 Mar 2023 19:25:02 +0100
+
+keyman (16.0.139-2) unstable; urgency=medium
+
+ * Don't build on s390x because Keyman doesn't work on big-endian
architectures
+(upstream bug https://github.com/keymanapp/keyman/issues/5111)
+
+ -- Eberhard Beilharz Mon, 20 Mar 2023 19:54:44 +0100
+
+keyman (16.0.139-1) unstable; urgency=medium
+
+ * New upstream release.
+ * Re-release to Debian
+
+ -- Eberhard Beilharz Thu, 16 Mar 2023 08:59:04 +0100
+
keyman (16.0.138-4) unstable; urgency=medium
* Team upload
diff -Nru keyman-16.0.138/debian/control keyman-16.0.139/debian/control
--- keyman-16.0.138/debian/control 2023-02-09 12:17:16.0 +0100
+++ keyman-16.0.139/debian/control 2023-03-20 20:02:09.0 +0100
@@ -105,7 +105,7 @@
information about Keyman keyboard packages.
Package: libkmnkbp-dev
-Architecture: any
+Architecture: amd64 arm64 armel armhf i386 mipsel mips64el ppc64el riscv64
Section: libdevel
Depends:
libkmnkbp0-0 (= ${binary:Version}),
@@ -129,7 +129,7 @@
This package contains development headers and libraries.
Package: libkmnkbp0-0
-Architecture: any
+Architecture: amd64 arm64 armel armhf i386 mipsel mips64el ppc64el riscv64
Section: libs
Pre-Depends:
${misc:Pre-Depends},
@@ -155,7 +155,7 @@
and applies rules from compiled Keyman keyboard files.
Package: ibus-keyman
-Architecture: any
+Architecture: amd64 arm64 armel armhf i386 mipsel mips64el ppc64el riscv64
Depends:
ibus (>= 1.3.7),
sudo,
diff -Nru keyman-16.0.138/debian/ibus-keyman.postinst
keyman-16.0.139/debian/ibus-keyman.postinst
--- keyman-16.0.138/debian/ibus-keyman.postinst 2023-02-09 12:17:16.0
+0100
+++ keyman-16.0.139/debian/ibus-keyman.postinst 2023-03-16 08:57:27.0
+0100
@@ -1,10 +1,13 @@
#!/bin/sh
-set -e
+# Don't call `set -e`. Even if some commands should fail, it's still
+# worth running the rest of the commands.
case "$1" in
configure)
+# (Re-)Start IBus
+
# if don't have sudo and ps then don't attempt to restart ibus
if which sudo > /dev/null && which ps > /dev/null; then
@@ -37,20 +40,20 @@
fi
#
