I guess rebuilding against python 3.12 wouldn't help, as Ubuntu Noble 24.04 gets shipped with python 3.12 and has the issue as well. (Though maybe it's still worth to have a closer look, maybe something else is not up to date.)
Some of the issue reports mention a work around: Onboard Settings -> Keyboard -> tab Advanced -> Input event source: Change from "Xinput" to "GTK". For me, tried on Xfce4, this avoids onboard to crash, but causes other strange behavior instead (e.g. keys being stuck).
In the first Ubuntu link, in the first comment, there is a reference to a possible patch (link below). Further down in the Ubuntu issue the comment No. 11 says that the patch didn't solve the problem.
In Debian, some work on patches have been done (from Jun 24, 2024 to Jul 10, 2024) but as far as I can see they are not related to the issue. However, the issue was now reported to the Debian bug tracker, causing investigations on this:
For Fedora there is a bug report at Red Hat. There is a proposed patch in comment No. 30. I'm not familiar with the package building at Fedora but it looks to me like "onboard" was removed after Fedora 39 with comment "Orphaned for 6+ weeks", likely due to unmaintained upstream onboard repository.
The proposed patch at Fedora / Red Hat bug No. 2227390 seems to be the same like the one I mentioned further up, which is in the Ubuntu bug No. 2063041 in its first comment:
Whereas the patches proposed in the Arch Linux issue No. 2 mentioned above, the first one goes into a similar direction but the second patch seems to do something else.
As the upstream onboard repository is unmaintained, we'll need to add a patch to Alpine Linux packaging.
There is no issue report on this in Alpine yet.
Unfortunately, I'm short on capacity and time since a while already.
Basically a backtrace of the crash should be done. However, some of the other issue reports already contain one. Therefore we maybe can skip this step.
Testing the different proposed patches mentioned above would be worthwhile. The one mentioned in Ubuntu / Fedora / Red Hat looks preferable. I'd say the two patches proposed in Arch Linux would be second choice. If one of those patches solves the issue, it could be added to Alpine Linux via a merge request. Maybe it would also be worth waiting to see how the issue is going to be solved in Debian, not sure how long it will take. Supporting the Debian issue by e.g. providing hints to the proposed patches might speed it up, unfortunately I'm not familiar with Debian bug reporting system und currently don't have the time to do that.
On the postmarketOS wiki I added a note to the user interfaces Xfce4, MATE and LXQt pointing to this issue report here.
There are two temporary work arounds, which both look not very satisfying to me:
As mentioned further up and in some of the issue reports: Onboard Settings -> Keyboard -> tab Advanced -> Input event source: Change from "Xinput" to "GTK". For me this caused some other issues in behavior (sticking keys). Also I guess this doesn't apply to the lock screen and (if disabling autologin) at LightDM login screen.
Moving to another virtual keyboard until the issue is solved. The easiest possibility is likely "matchbox-keyboard", though it's not as nice as "onboard". After installation, it would need to be added to the autostart applications. For lock screen and LighDM login screen it needs to be used in embedded mode matchbox-keyboard --xid. The wiki pages of Xfce4 and MATE explain in section "Lock screen" how to change the lock screen keyboard. In LXQt it's currently the same like in Xfce4. For LightDM login screen (if autologin is disabled) I'm not fully sure, it should roughly work with greeter "lightdm-gtk-greeter" setting keyboard=matchbox-keyboard --xid in "/etc/lightdm/lightdm-gtk-greeter.conf", see wiki page "Display manager" (edit: without the "keyboard-position" option, this doesn't work with "matchbox-keyboard" as far as I know).
I think that patch would be more preferable to submit to Alpine Linux. The one from Void Linux would be a patchset consisting of 2 patches, whereas we seem to need only the first one of it (which makes things more complicated to discusss). Also it slightly changes the structure of an error return at the beginning (with the same result, still a bit intruding). The patch proposed in the Ubuntu issue (and Fedora / Red Hat issue) looks more clear and consistent to me.
Though, as long as it works, I'm also fine with the Void Linux patch.
I now also had a try with the patch (on LXQt but that shouldn't matter). onboard doesn't crash anymore. However, I have issues with special characters like -, /, etc. When hitting those keys, they get "stuck" and the character doesn't get printed.
For comparison I also tried with the Void Linux patch. It doesn't make a difference, the behavior is the same.
I observed that sticking keys behavior also without patch when trying the workaround changing the "Input event source" from "Xinput" to "GTK" in the onboard settings (see further above). Thus, that sticking keys issue might be a separate issue with another cause. It will need further investigation.
The MR at Alpine should be continued. It prevents onboard from crashing, which improves the situation by a lot already. This will also ease the further investigation on the sticking keys issue.
I'm not familiar with that but as far as I understand in both cases it ends up at:
File "/usr/lib/python3.12/site-packages/Onboard/Keyboard.py", line 189, in press_unicode keysym = self._vk.keysym_from_unicode(char) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
The current Debian patches 1005-1008 (1009 recently got merged into 1005) have been added with comment "Mostly syntax fixes". Also the second Void Linux patch fixes syntax. I would have assumed that this is just some cosmetic fix. Although, as the word UNICODE shows up in those syntax things, they might be related to the sticking keys issue.
Also I looked through onboard upstream, Ubuntu, Debian, Arch Linux, Fedora issues and packaging, it bothers me that nowhere the sticking keys issue gets mentioned. Also everyone at other distirbutions seem to be fine with the workaround changing the input event source from "Xinput" to "GTK" while this caused the sticking keys issue for me as well. I wonder whether that sticking keys issue is still covered behind the segfault issue in other distributions or if it might be a specific issue to Alpine in some way.
Still I would say the MR at Alpine should go on as it is, because it fixes the segfaulting, which would be a big step forward. The MR seems to wait for an approval by @danct12.
There is a fix for the sticking keys issue by Linux Mint developper "mtwebster". (I haven't tested.)
I websearched for "onboard self._vk.keysym_from_unicode(char)" and found the following issue report for Linux Mint (based on Debian->Ubuntu). Developper "clefebvre" commented yesterday "It's to do with the removal of Py_Unicode in Python 3.12." and added today "Fixed in 1.4.1+mint4.".
The one "LayoutLoaderSVG.py: Fix bad exception string." is similar to the Debian patch "1006_fix-str-not-callable-in-LayoutLoaderSVG-py.patch" in Debian onboard version 1.4.1-8. I don't know what it fixes and if we neccessarily need it.
However, the patch supposed to fix the sticking keys issue is "osk_virtkey.c: Don't use legacy Py_UNICODE for converting utf8 to keysyms.":
@xtex could you test that patch "osk_virtkey.c: Don't use legacy Py_UNICODE for converting utf8 to keysyms." and, if it indeed solves the sicking key issue, could you add it to the Alpine MR? I'm not sure if we need the other patch for LayoutLoaderSVG.py, I think I wouldn't add it if it's not directly needed for fixing the sticking keys issue (but that's just my assessment, feel free to do it your way).
The fix has been merged to Alpine "edge", onboard-1.4.1-r12 contains the patches. The packages for architectures armv7, x86 and riscv64 have not been built yet but that's just a matter of time.
As stable postmarketOS v24.06 is affected too, the fix needs to be backported to Alpine 3.20. @xtex: Would you be up to do this MR as well? It would be again an MR with the same two commits but this time onto the "3.20-stable" branch in Alpine. The MR title needs to be prepended by "[3.20] community/onboard: ..." and as MR decription it's sufficient to refer to the first MR.
You can check the available package versions at https://pkgs.alpinelinux.org by looking for package version "onboard", leaving branch at "edge" and not selecting any "Arch":
Currently on "edge" the architectures armhf, s390x, x86_64, aarch64, ppc64le are at package version 1.4.1-r12. The remaining armv7, x86, riscv64 are still at 1.4.1-r11.
The riscv64 packages are built irregular to my knowlegde because they are built on special hardware.
The packages for armv7 and x86 would supposed to be built already but there currently seems to be a problem with the builder. At https://build.alpinelinux.org those two are stuck at an error of building package "community/qt6-qtwebengine" right now.
the build of onboard seems to be blocked by qt6-qtwebengine. therefore it is likely that all x86/armv7/rv64 packages in alpine has been blocked for ~4 days.