Bug#884466: mesa: firefox, thunderbird, chromium work again with mesa 17.3.0-1
Followup-For: Bug #884466 Package: libglx-mesa0 Dear Maintainer, With this version, it's seems that the bug is fixed for me =) DRM Information from dmesg: --- -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.14.0-3-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libglx-mesa0 depends on: ii libc6 2.26-6 ii libdrm2 2.4.89-1 ii libexpat1 2.2.5-3 ii libgl1-mesa-dri 17.3.4-1 ii libglapi-mesa 17.3.4-1 ii libx11-6 2:1.6.4-3 ii libx11-xcb1 2:1.6.4-3 ii libxcb-dri2-0 1.12-1 ii libxcb-dri3-0 1.12-1 ii libxcb-glx0 1.12-1 ii libxcb-present0 1.12-1 ii libxcb-sync1 1.12-1 ii libxcb-xfixes0 1.12-1 ii libxcb1 1.12-1 ii libxdamage1 1:1.1.4-3 ii libxext6 2:1.3.3-1+b2 ii libxfixes3 1:5.0.3-1 ii libxshmfence1 1.2-1+b2 ii libxxf86vm1 1:1.1.4-1+b2 ii zlib1g 1:1.2.8.dfsg-5 libglx-mesa0 recommends no packages. libglx-mesa0 suggests no packages. Versions of packages xserver-xorg depends on: ii x11-xkb-utils 7.7+3+b1 ii xkb-data 2.23.1-1 ii xserver-xorg-core 2:1.19.6-1 ii xserver-xorg-input-all 1:7.7+19 ii xserver-xorg-input-libinput [xorg-driver-input] 0.26.0-1 ii xserver-xorg-input-wacom [xorg-driver-input] 0.34.99.1-1 ii xserver-xorg-video-all 1:7.7+19 ii xserver-xorg-video-amdgpu [xorg-driver-video] 1.4.0-1 ii xserver-xorg-video-ati [xorg-driver-video] 1:7.10.0-1 ii xserver-xorg-video-fbdev [xorg-driver-video] 1:0.4.4-1+b5 ii xserver-xorg-video-intel [xorg-driver-video] 2:2.99.917+git20171229-1 ii xserver-xorg-video-nouveau [xorg-driver-video] 1:1.0.15-2 ii xserver-xorg-video-qxl [xorg-driver-video] 0.1.5-2 ii xserver-xorg-video-radeon [xorg-driver-video] 1:7.10.0-1 ii xserver-xorg-video-vesa [xorg-driver-video] 1:2.3.4-1+b2 ii xserver-xorg-video-vmware [xorg-driver-video] 1:13.2.1-1+b1 Versions of packages xserver-xorg recommends: ii libgl1-mesa-dri 17.3.4-1 ii xserver-xorg-legacy 2:1.19.6-1 Versions of packages xserver-xorg-core depends on: ii keyboard-configuration 1.178 ii libaudit1 1:2.8.2-1 ii libbsd0 0.8.7-1 ii libc6 2.26-6 ii libdbus-1-3 1.12.4-1 ii libdrm2 2.4.89-1 ii libegl1 1.0.0-2 ii libegl1-mesa 17.3.4-1 ii libepoxy0 1.4.3-1 ii libgbm1 17.3.4-1 ii libgcrypt20 1.8.1-4 ii libgl1 1.0.0-2 ii libpciaccess0 0.13.4-1+b2 ii libpixman-1-0 0.34.0-2 ii libselinux1 2.7-2+b1 ii libsystemd0 237-3 ii libudev1 237-3 ii libxau6 1:1.0.8-1+b2 ii libxdmcp6 1:1.1.2-3 ii libxfont2 1:2.0.1-4 ii libxshmfence1 1.2-1+b2 ii udev 237-3 ii xserver-common 2:1.19.6-1 Versions of packages xserver-xorg-core recommends: ii libgl1-mesa-dri 17.3.4-1 ii libpam-systemd 237-3 Versions of packages xserver-xorg-core suggests: ii xfonts-100dpi 1:1.0.4+nmu1 ii xfonts-75dpi 1:1.0.4+nmu1 ii xfonts-scalable 1:1.0.3-1.1 -- no debconf information
Bug#890679: libxshmfence: FTBFS with glibc 2.27: error: implicit declaration of function 'memfd_create'
Source: libxshmfence
Version: 1.2-1
Severity: important
Tags: upstream patch
User: debian-gl...@lists.debian.org
Usertags: 2.27
libxshmfence 1.2-1 fails to build with glibc 2.27 (2.27-0experimental0 from
experimental):
| libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../../src -I.. -Wdate-time
-D_FORTIFY_SOURCE=2 -Wall -Wpointer-arith -Wmissing-declarations -Wformat=2
-Wstrict-prototypes -Wmissing-prototypes -Wnested-externs -Wbad-function-cast
-Wold-style-definition -Wdeclaration-after-statement -Wunused -Wuninitialized
-Wshadow -Wmissing-noreturn -Wmissing-format-attribute -Wredundant-decls
-Wlogical-op -Werror=implicit -Werror=nonnull -Werror=init-self -Werror=main
-Werror=missing-braces -Werror=sequence-point -Werror=return-type
-Werror=trigraphs -Werror=array-bounds -Werror=write-strings -Werror=address
-Werror=int-to-pointer-cast -Werror=pointer-to-int-cast -fno-strict-aliasing -g
-O2 -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat
-Werror=format-security -fvisibility=hidden -c ../../src/xshmfence_alloc.c
-fPIC -DPIC -o .libs/xshmfence_alloc.o
| ../../src/xshmfence_alloc.c: In function 'xshmfence_alloc_shm':
| ../../src/xshmfence_alloc.c:73:7: error: implicit declaration of function
'memfd_create'; did you mean 'SYS_memfd_create'?
[-Werror=implicit-function-declaration]
| fd = memfd_create("xshmfence", MFD_CLOEXEC|MFD_ALLOW_SEALING);
|^~~~
|SYS_memfd_create
| ../../src/xshmfence_alloc.c:73:7: warning: nested extern declaration of
'memfd_create' [-Wnested-externs]
| cc1: some warnings being treated as errors
| Makefile:474: recipe for target 'xshmfence_alloc.lo' faile
A full build logs is available there:
http://aws-logs.debian.net/2018/02/07/glibc-exp/libxshmfence_1.2-1_unstable_glibc-exp.log
glibc 2.27 added support for memfd_create. libxshmfence correctly
detects in its configure script the availability of this function and
consequently disables its own syscall wrapper. Unfortunately this is
not enough as memfd_create as a GNU extension and thus needs to be built
with _GNU_SOURCE.
The problem has been fixed in upstream commit 0b550a4e. I have also
attached it as a patch to this mail.
--- libxshmfence-1.2.orig/debian/patches/memfd_create.patch
+++ libxshmfence-1.2/debian/patches/memfd_create.patch
@@ -0,0 +1,29 @@
+From 0b550a4e7acf02d3478602848f6afbfcbfb0d4b2 Mon Sep 17 00:00:00 2001
+From: Ross Burton
+Date: Mon, 29 Jan 2018 16:24:36 +
+Subject: configure.ac: call AC_USE_SYSTEM_EXTENSIONS
+
+With glibc 2.27 memfd_create() is inside a _GNU_SOURCE guard, so call
+AC_USE_SYSTEM_EXTENSIONS to get this defined.
+
+Signed-off-by: Ross Burton
+---
+ configure.ac | 2 ++
+ 1 file changed, 2 insertions(+)
+
+diff --git a/configure.ac b/configure.ac
+index 55772d0..ed77e6d 100644
+--- a/configure.ac
b/configure.ac
+@@ -28,6 +28,8 @@ AC_INIT([libxshmfence], [1.2],
+ AC_CONFIG_SRCDIR([Makefile.am])
+ AC_CONFIG_HEADERS([config.h])
+
++AC_USE_SYSTEM_EXTENSIONS
++
+ # Initialize Automake
+ AM_INIT_AUTOMAKE([foreign dist-bzip2])
+
+--
+cgit v1.1
+
--- libxshmfence-1.2.orig/debian/patches/series
+++ libxshmfence-1.2/debian/patches/series
@@ -0,0 +1 @@
+memfd_create.patch
Bug#856351: ditto from screen
Hi, I saw this error message when I accidentally ran startx on tty1 from a screen(1) session. For some reason, there's a root-owned /dev/tty0 on the machine. Should there be one? I certainly don't seem to see it - I have six VTs set up, and e.g. /dev/tty1 where I'm running that startx is owned by my user. The only non-comment content of Xwrapper.config is "allowed_users=console" man Xwrapper.config fails to run, oddly enough -- 2. That which causes joy or happiness.
Bug#833182: ditto, but different resolution
Hi, I observed something very similar this after a jessie -> stretch dist-upgrade. My whole failing logfile is attached, and the gist of the problem was in these errors: [...] [ 5115.028] (EE) systemd-logind: failed to get session: PID 4398 does not belong to any known session [...] [ 5116.097] (EE) modeset(0): drmSetMaster failed: Permission denied [ 5116.097] (EE) [ 5116.097] (EE) AddScreen/ScreenInit failed for driver 0 [...] The first error appeared to be the root cause - it was caused by not reading through https://www.debian.org/releases/stable/amd64/release-notes/ch-whats-new.en.html#x-no-longer-requires-root where it said that the new way needs libpam-systemd Nothing had installed that package in my dist-upgrade, probably because I didn't choose to observe Recommends. After installing that and rebooting, everything was fine and Xorg runs as my own user, yay. I'll also note here that my first searches for the latter error message had produced a workaround - installing xserver-xorg-legacy and setting needs_root_rights=yes in Xwrapper.config. But that result is obviously inferior. It would be much better if the Xorg modesetting error messages were somewhat clearer as to what actually went wrong. It looks like the defaults excluded the intel driver as such: [ 5115.616] (==) Matched nouveau as autoconfigured driver 0 [ 5115.616] (==) Matched nv as autoconfigured driver 1 [ 5115.616] (==) Matched modesetting as autoconfigured driver 2 [ 5115.616] (==) Matched fbdev as autoconfigured driver 3 [ 5115.616] (==) Matched vesa as autoconfigured driver 4 When it worked, driver 2 actually seems to have reported: [20.775] (II) modeset(0): [DRI2] Setup complete [20.775] (II) modeset(0): [DRI2] DRI driver: i965 [20.775] (II) modeset(0): [DRI2] VDPAU driver: i965 This is counterintuitive given that I have xserver-xorg-video-intel installed. If the intel driver is installed, that should provide at least some sort of a hint to the Xorg server on runtime. Maybe to include it in the list of defaults? I don't have several of the above drivers installed and these particular wrong defaults merely lead to more redundant error output... If not that, then perhaps the modesetting driver should tell the user that it tried to take command over these drivers, but that perhaps its failure should not be completely fatal? Arguably the situation is made complex by the fact that these laptops have two GPUs, the Intel and the Nvidia one, and so both the users and the software are more likely to be confused by default. -- 2. That which causes joy or happiness. Xorg.0.log.old Description: application/trash
