Package: putty / 0.70-4
Patch seriesview the series file
|pipe buf.patch | (download)||
3 3 + 0 - 0 !
fix build failure on gnu/hurd putty FTBFS on GNU/Hurd due to a missing definition of PIPE_BUF in <limits.h>. This is solved by using the _POSIX_PIPE_BUF defined value of 512 instead. (In fact the assertion will never happen, SALT_SIZE is defined to 64 and PIPE_BUF is always larger than that, e.g. for Linux 4096, and so is _POSIX_PIPE_BUF.) Bug-Debian: https://bugs.debian.org/805505
|gdk display beep.patch | (download)||
use gdk_display_beep() in place of obsolete gdk_beep(). Except in GTK1 (which doesn't have the former), via a gtkcompat.h workaround. Up-to-date GTK3 has deprecated gdk_beep(), causing build failures due to the default -Werror setting.
|gdk backend x11.patch | (download)||
9 9 + 0 - 0 !
use gdk_backend x11 when built with x support When putty gets built with X Window System support it enables code that does direct X11 calls via Xlib. This will crash when not running under X11, eg. wayland, broadway, etc. To make it possible for a generic binary that's been built with X11 enabled to also work in wayland, tell GDK to use the x11 backend (unless the user has explicitly requested something else by setting GDK_BACKEND environment variable, but that will likely just make it crash again so maybe the 'override' argument to setenv should be 1 instead). This means putty should run under xwayland by default when built with X11 support and started in a wayland session like GNOME, etc. (For other backends like broadway, this will still likely not work as they don't have any equivalent to xwayland.) Bug-Debian: https://bugs.debian.org/861603
|ignore spurious configure area events.patch | (download)||
11 11 + 0 - 0 !
ignore spurious configure_area events. Colin Watson reports that on pre-releases of Ubuntu 18.04, configure events which don't actually involve a change of window size show up annoyingly often. Our handling of configure events involves throwing away the backing Cairo surface, making a fresh blank one, and scheduling a top-level callback to get terminal.c to do a repaint and populate the new surface; so a draw event before that callback occurs causes the window contents to flicker off and on again, not to mention wasting a lot of time. The simplest solution is to spot spurious configures, and respond by not throwing away the previous Cairo surface in the first place.