kio 6.3.0 偷偷 把默认的启动程序方式改成了
在尝试修复这个问题的时候的时候发现了另一个问题,dump 整个 env 传给 systemd 并不是总能工作,因为 systemd 只接受只含有字母数字和
最后 kio 上游开发者实现了一个比较基础的 filtering。
https://invent.kde.org/frameworks/kio/-/issues/33
https://invent.kde.org/frameworks/kio/-/merge_requests/1649
systemd-run --user 等价物,导致调用 kio 的程序设置的 XDG_ACTIVATION_TOKEN 在一些情况下没能被传递到被启动程序的环境变量中,可能导致焦点不能自动切换到被启动的程序。在尝试修复这个问题的时候的时候发现了另一个问题,dump 整个 env 传给 systemd 并不是总能工作,因为 systemd 只接受只含有字母数字和
_ 的环境变量名而比如 pulseaudio 就 用到了 带有 . 的环境变量名。最后 kio 上游开发者实现了一个比较基础的 filtering。
https://invent.kde.org/frameworks/kio/-/issues/33
https://invent.kde.org/frameworks/kio/-/merge_requests/1649
❤1
qty 和 *nix desktop 的迷惑故事
偷偷
用这个词是因为实际上 startplasma 一直在设置
KDE_APPLICATIONS_AS_SCOPE=1 而这个提交的 commit message 完全没提到这一点,甚至让人觉得原先的默认就是 SystemdProcessRunner (确实是,只是 Plasma 一直在 override 这个默认🥰5
qty 和 *nix desktop 的迷惑故事
用这个词是因为实际上 startplasma 一直在设置 KDE_APPLICATIONS_AS_SCOPE=1 而这个提交的 commit message 完全没提到这一点,甚至让人觉得原先的默认就是 SystemdProcessRunner (确实是,只是 Plasma 一直在 override 这个默认
感觉
SystemdProcessRunner 比 ScopedProcessRunner 慢挺多(后者是 kio 自己 fork+exec 然后再交给 systemd 管理,虽然有 race 但是 exec 本身非常快(Forwarded from Rong布星球 🧶 (Rongron🧊 | g𝐝𝐛)
如果你正在使用 Debian sid,请不要更新
这会导致某些 Wayland 混成器(compositor)无法正确启动(已知
使用以下命令 hold
一旦该 bug 被修复,将
如果已经不幸升级了,又没有可回滚的 snapshot,可以按如下步骤救援:
1) 取得 shell access。注意此时 ssh 仍是可用的,你也可以使用串口。亦可使用 SysRq。否则可先短按电源键关机,重新启动后登录到其他 session,也可以修改 cmdline 增加
2) 降级
3) 执行前面的命令以 hold 住受影响的二进制包。
libwayland,否则会导致 Xwayland 在早期启动过程就发生 Segmentation fault,从而引发严重的连锁反应。这会导致某些 Wayland 混成器(compositor)无法正确启动(已知
kwin_wayland 会这样),导致鼠标键盘事件均无法被响应。即使是 Caps Lock 以及切换到 VT (tty) 的组合键(Ctrl-Alt-F*)也会无法响应。此时仍可通过短按电源键来关机。使用以下命令 hold
libwayland (即 Wayland 协议库) 打出的所有二进制包以暂时阻止升级:sudo apt-mark hold libwayland-bin libwayland-client0 libwayland-cursor0 libwayland-dev libwayland-doc libwayland-egl1 libwayland-egl-backend-dev libwayland-server0
一旦该 bug 被修复,将
hold 改为 unhold 即可取消 hold 状态。如果已经不幸升级了,又没有可回滚的 snapshot,可以按如下步骤救援:
1) 取得 shell access。注意此时 ssh 仍是可用的,你也可以使用串口。亦可使用 SysRq。否则可先短按电源键关机,重新启动后登录到其他 session,也可以修改 cmdline 增加
systemd.unit=multi-user.target 来阻止默认进入 graphical.target ,再启动到 VT。2) 降级
libwayland (需要已配置 Debian testing repo)。建议使用 aptitude 以正确处理 multiarch 的情形并防止修改软件包安装状态为 manual 。如果不能使用 aptitude ,也可使用 apt 。sudo aptitude install $(apt list -ai 'libwayland-*' | grep -P '\S+\s+1.22' | grep -Po '^[^\s,]+' | sort -u)
3) 执行前面的命令以 hold 住受影响的二进制包。
Forwarded from q234rty 🍓
Rong布星球 🧶
如果你正在使用 Debian sid,请不要更新 libwayland,否则会导致 Xwayland 在早期启动过程就发生 Segmentation fault,从而引发严重的连锁反应。 这会导致某些 Wayland 混成器(compositor)无法正确启动(已知 kwin_wayland 会这样),导致鼠标键盘事件均无法被响应。即使是 Caps Lock 以及切换到 VT (tty) 的组合键(Ctrl-Alt-F*)也会无法响应。此时仍可通过短按电源键来关机。 使用以下命令 hold libwayland…
要细节的话就是,我理解 https://gitlab.freedesktop.org/wayland/wayland/-/commit/fd42f70bafa26fcf6f39f034b581b35838be71aa 这个提交假设了 wl_shm 的 version 2 是被定义的(libwayland 自带的 wayland.xml 里定义了),但 qt vendor 了一份自己的 wayland.xml,导致这个提交修改的函数失败了
GitLab
shm: implement version 2 (fd42f70b) · Commits · wayland / wayland · GitLab
This version adds a release request. Signed-off-by: Simon Ser
Forwarded from q234rty 🍓
q234rty 🍓
要细节的话就是,我理解 https://gitlab.freedesktop.org/wayland/wayland/-/commit/fd42f70bafa26fcf6f39f034b581b35838be71aa 这个提交假设了 wl_shm 的 version 2 是被定义的(libwayland 自带的 wayland.xml 里定义了),但 qt vendor 了一份自己的 wayland.xml,导致这个提交修改的函数失败了
kwin 6 不再调用 wl_display_init_shm 了所以不受影响
但其实 qtwaylandcompositor 也被这个搞坏了(是 qt 内部的混成器实现,和 kwin 无关)
arch 的解决方法是直接把 qt6 vendor 的 wayland.xml 更新了(
另:telegram-desktop 的小程序在 wayland 下是用 qtwaylandcompositor 实现了一个嵌套 wayland 混成器,再在这个嵌套混成器里跑 webkit2gtk
但其实 qtwaylandcompositor 也被这个搞坏了(是 qt 内部的混成器实现,和 kwin 无关)
arch 的解决方法是直接把 qt6 vendor 的 wayland.xml 更新了(
另:telegram-desktop 的小程序在 wayland 下是用 qtwaylandcompositor 实现了一个嵌套 wayland 混成器,再在这个嵌套混成器里跑 webkit2gtk
q234rty 🍓
这个提交假设了 wl_shm 的 version 2 是被定义的(libwayland 自带的 wayland.xml 里定义了),但 qt vendor 了一份自己的 wayland.xml,导致这个提交修改的函数失败了
具体来说,用到 wayland 协议的项目编译时往往会用到 wayland-scanner 或者其类似物,其会从 xml 格式的协议里生成头文件和一些胶水代码,而 wayland.xml 生成的代码里面就定义了
wl_shm_interface 的版本;但在使用了 qt 的混成器里这被 qtwayland 自带的老版本 wayland.xml 生成的代码覆盖了,导致了这个问题。
q234rty 🍓
telegram-desktop 的小程序在 wayland 下是用 qtwaylandcompositor 实现了一个嵌套 wayland 混成器,再在这个嵌套混成器里跑 webkit2gtk
至于 telegram-desktop 为何采用这种技术路线而不是直接使用 qtwebengine,我猜想是为了减小其官方发布的二进制大小(目前 telegram-desktop 会尝试 dlopen 系统上的
libwebkitgtk-6.0.so 等)Forwarded from Rong布星球 🧶 (Rongron🧊 | g𝐝𝐛)
Debian 的 kwin 软件包已被 rebuild against libwayland 1.23,rebuild 后修复了上述问题。
比较两个版本的 kwin 软件包源代码,可以看到没有任何源代码变更,这是纯粹的 rebuild。
根据 Debian BTS 里的推测,这个 bug 的成因可能是 symbol 冲突:
新版
kwin5 会调用
kwin6 不调用
Rebuild 尽管没有从根本上解决上述问题,但是使得
Debian Qt/KDE Maintainers 没有考虑从根本上解决这个问题应该是因为没有必要,毕竟到 KDE Plasma 6.1 的 migration 迟早要发生。
目前似乎没有其他 Wayland 混成器(compositor)受影响。
确保你使用的镜像已同步了
比较两个版本的 kwin 软件包源代码,可以看到没有任何源代码变更,这是纯粹的 rebuild。
根据 Debian BTS 里的推测,这个 bug 的成因可能是 symbol 冲突:
libkwin 携带了过时的 wl_shm_interface symbol (在 build against 旧版 libwayland 时由 qtwaylandscanner 生成)并且错误地没有 make it private (产生了 symbol leak);新版
libwayland 携带了更新的 wl_shm_interface ,携带了新的 symbol ;kwin5 会调用
wl_display_init_shm() ,后者不幸地使用了 libkwin leak 出来的过时的 wl_shm_interface 。kwin6 不调用
wl_display_init_shm() ,因此不受影响(并不意味着它一定不 leak symbol,这个问题在两周前才被修复)。Rebuild 尽管没有从根本上解决上述问题,但是使得
libkwin 携带的将会 leak 的 wl_shm_interface symbol 与 libwayland 携带的 up-to-date 版本一致了,因此不会再触发 segmentation fault 然后 hang 了。Debian Qt/KDE Maintainers 没有考虑从根本上解决这个问题应该是因为没有必要,毕竟到 KDE Plasma 6.1 的 migration 迟早要发生。
目前似乎没有其他 Wayland 混成器(compositor)受影响。
确保你使用的镜像已同步了
kwin-wayland 4:5.27.11-2 ,然后可以 unhold libwayland 并更新它们了。Forwarded from q234rty 🍓
Rong布星球 🧶
Debian 的 kwin 软件包已被 rebuild against libwayland 1.23,rebuild 后修复了上述问题。 比较两个版本的 kwin 软件包源代码,可以看到没有任何源代码变更,这是纯粹的 rebuild。 根据 Debian BTS 里的推测,这个 bug 的成因可能是 symbol 冲突: libkwin 携带了过时的 wl_shm_interface symbol (在 build against 旧版 libwayland 时由 qtwaylandscanner 生成)并且错误地没有…
确实,后来发现我之前的说法误导了(
kwin 用的是 extra-cmake-modules 来处理 wayland 协议,没有直接链接到 qtwayland,也没有用到 qtwayland 自带的 wayland.xml,所以确实只需要 rebuild
和 telegram-desktop 的情况不一样,后者链接的
kwin 用的是 extra-cmake-modules 来处理 wayland 协议,没有直接链接到 qtwayland,也没有用到 qtwayland 自带的 wayland.xml,所以确实只需要 rebuild
和 telegram-desktop 的情况不一样,后者链接的
libQt6WaylandCompositor.so 里的 wl_shm_interface 符号是由 qtwayland 内置的旧版的 wayland.xml 生成的,所以单纯 rebuild 并不足以修复https://freebsdfoundation.org/blog/why-laptop-support-why-now-freebsds-strategic-move-toward-broader-adoption #火星救援
FreeBSD Foundation | A non-profit organization dedicated to supporting and building the FreeBSD Project
Why laptop support, why now: FreeBSD’s strategic move toward broader adoption | FreeBSD Foundation
FreeBSD has long been a top choice for IT professionals and organizations focused on servers and networking, and it is known for its unmatched stability, performance, and security. However, as technology evolves, FreeBSD faces a significant challenge: supporting…

