Emacs 31.1, GNOME Boxes rewrite, DRM and Rust graphics work

Emacs 31.1 shipped with source and Windows binaries while GNOME Boxes outlined a multi-year Flatpak-only redesign. Separate threads covered LLM agent guidance in Emacs, long-term binary compatibility, a GNOME RFC process, and kernel DRM helpers for fences and Rust conversions.

Emacs 31.1 released

Emacs 31.1 source tarballs and Windows binaries were announced on emacs-devel. The thread also recorded a minor build bug report and clarifications around terminology for package addition. Desktop users and packagers gain a new stable baseline with the usual mix of fixes and incremental features.

GNOME Boxes rewrite plans

Maintainer Felipe Borges described a two-year rewrite that turns GNOME Boxes into a Flatpak-only GTK4 and Libadwaita application. The plan replaces the SPICE display path with Libmks. Virtualization users on GNOME should expect a narrower, more modern stack and a longer transition window.

AGENTS.md debate in Emacs

Emacs developers debated adding an AGENTS.md file to steer LLM agents away from generating code, offered as an alternative to hooks. The discussion ran long and heated across more than a hundred messages. The outcome matters for how Emacs projects handle automated code contributions going forward.

Compatibility after system upgrades

Richard Stallman opened a thread examining concrete GCC and Glibc changes that break older Emacs builds after GNU/Linux upgrades. Participants sought adjustments in both distribution practices and Emacs packaging to improve long-term compatibility. The exchange highlights recurring friction between rolling toolchain updates and stable application binaries.

GNOME RFC process proposal

GNOME contributors discussed and iterated on a formal RFC process for governance and technical decisions. The thread refined how proposals would be submitted, reviewed, and recorded. A clearer decision path would affect anyone tracking or contributing to GNOME architecture changes.

Common drm_user_fence helper

AMD posted patches adding a common drm_user_fence helper intended to deduplicate the dma-fence-to-workqueue and mm pattern already used by XE and planned for AMDGPU. Review focused on making the shared path correct for multiple drivers. Kernel graphics maintainers gain a chance to reduce duplicated fence handling code.

Rust cv! macro for const conversions

A patch series introduced a cv! macro for ergonomic const conversions of NonZero and Bounded integer-like types in Rust kernel code. Reviewers commented and briefly noted upstream discussion. The change aims to simplify safe const handling in drivers that already use these wrapper types.

Nova-core parameter export to nova-drm

Version 5 of a patch series covering the nova-core to nova-drm API received further review. Topics included the GPU info ioctl, lifetime variance, and registration_data helpers. Progress here advances the open NVIDIA GPU driver stack toward usable userspace interfaces.