Bug#1077077: xutils-dev: Fix spurious ar clq command

[Samuel Thibault]

Package: xutils-dev
Version: 1:7.7+6.2
Severity: important
Tags: patch

Hello,

As applied upstream, on GNU OSes, we now need to use "ar cq" instead of
"ar clq". The attached upstream patch fixes this, could you add it?

Thanks,
Samuel

-- System Information:
Debian Release: trixie/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 'unreleased'), 
(500, 'testing-debug'), (500, 'stable-security'), (500, 'stable-debug'), (500, 
'oldstable-proposed-updates-debug'), (500, 'oldstable-proposed-updates'), (500, 
'oldoldstable'), (500, 'buildd-unstable'), (500, 'unstable'), (500, 'stable'), 
(500, 'oldstable'), (1, 'experimental-debug'), (1, 'buildd-experimental'), (1, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, arm64

Kernel: Linux 6.9.8-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages xutils-dev depends on:
ii  cpp4:13.2.0-7
ii  libc6  2.38-14

xutils-dev recommends no packages.

xutils-dev suggests no packages.

-- no debconf information

-- 
Samuel
 ya(ka|ma|to)* ca existe une fois sur 2 au japon, c'est facile ;-)
 -+- #ens-mim au japon -+-
commit 90b66dc73deb9ef303690370395cf831425547c7
Author: Yasuhiro Kimura 
Date:   Thu Oct 13 15:22:02 2022 +0900

Fix incompatibility issue of GNU binutils 2.36 and later on FreeBSD.

Commit a6d4d6223ef75119d5373fa4cc04161bcdb4e769 fixes incompatibility
issue of GNU binutils 2.36 and later. If I check the diff of the
commit, there seems to be asumption that the issue is specific to
Linux. But it also happens on FreeBSD if user installs GNU binutils
from FreeBSD ports/packages collections and '/usr/local/bin' comes
before '/usr/bin' in the value of PATH enviroment variable. So fix the
issue also on FreeBSD with following way.

1. Introduce new macro 'HasGnuAr'.
2. Change Imake.tmpl so it defines 'ArCmd' as 'ArCmdBase cq' if
   'HasGnuAr' is defined.
3. Define 'HasGnuAr' in both FreeBSD.cf and linux.cf.

Since 'ar' command of FreeBSD base system simply ignores 'l' option,
it also works fine even if GNU binutils isn't installed.

commit 26b383ac4a5b65f808d1a159864fac266f136c84
Author: Samuel Thibault 
Date:   Thu Jul 25 22:48:36 2024 +0200

Also fix incompatibility issue of GNU binutils 2.36 and later on GNU/Hurd

Just like 90b66dc73deb ("Fix incompatibility issue of GNU binutils 2.36
and later on FreeBSD.") did.

Index: xutils-dev-7.7+6.2+hurd.1/xorg-cf-files/FreeBSD.cf
===
--- xutils-dev-7.7+6.2+hurd.1.orig/xorg-cf-files/FreeBSD.cf
+++ xutils-dev-7.7+6.2+hurd.1/xorg-cf-files/FreeBSD.cf
@@ -153,6 +153,9 @@ XCOMM operating system:  OSName (OSMajor
 #ifndef HasFlex
 #define HasFlexYES
 #endif
+#ifndef HasGnuAr
+#define HasGnuAr   YES
+#endif
 
 #ifndef HasMktemp
 #if (OSMajorVersion >= 4) || (OSMajorVersion == 3 && OSMinorVersion >= 1) || \
Index: xutils-dev-7.7+6.2+hurd.1/xorg-cf-files/Imake.tmpl
===
--- xutils-dev-7.7+6.2+hurd.1.orig/xorg-cf-files/Imake.tmpl
+++ xutils-dev-7.7+6.2+hurd.1/xorg-cf-files/Imake.tmpl
@@ -1140,7 +1140,7 @@ TCLIBDIR = TclLibDir
 #define ArCmdBase ar
 #endif
 #ifndef ArCmd
-#if HasLargeTmp || SystemV4 || LinuxBinUtilsMajorVersion
+#if HasLargeTmp || SystemV4 || HasGnuAr
 #define ArCmd ArCmdBase cq
 #else
 #define ArCmd ArCmdBase clq
Index: xutils-dev-7.7+6.2+hurd.1/xorg-cf-files/linux.cf
===
--- xutils-dev-7.7+6.2+hurd.1.orig/xorg-cf-files/linux.cf
+++ xutils-dev-7.7+6.2+hurd.1/xorg-cf-files/linux.cf
@@ -103,6 +103,10 @@ XCOMM platform:  $XFree86: xc/config/cf/
 # define LinuxBinUtilsMajorVersion DefaultLinuxBinUtilsMajorVersion
 #endif
 
+#ifndef HasGnuAr
+#define HasGnuAr   YES
+#endif
+
 XCOMM operating system:  OSName 
(OSMajorVersion./**/OSMinorVersion./**/OSTeenyVersion)
 XCOMM libc:
(LinuxCLibMajorVersion./**/LinuxCLibMinorVersion./**/LinuxCLibTeenyVersion)
 XCOMM binutils:(LinuxBinUtilsMajorVersion)
Index: xutils-dev-7.7+6.2+hurd.1/xorg-cf-files/gnu.cf
===
--- xutils-dev-7.7+6.2+hurd.1.orig/xorg-cf-files/gnu.cf
+++ xutils-dev-7.7+6.2+hurd.1/xorg-cf-files/gnu.cf
@@ -35,6 +35,9 @@ XCOMM $XdotOrg: xc/config/cf/gnu.cf,v 1.
 #ifndef ManDirectoryRoot
 # define ManDirectoryRoot  /usr/share/man
 #endif
+#ifndef HasGnuAr
+#define HasGnuAr   YES
+#endif
 
 XCOMM operating system:  OSName 
(OSMajorVersion./**/OSMinorVersion./**/OSTeenyVersion)
 XCOMM libc:
(GnuCLibMajorVersion./**/GnuCLibMinorVersion./**/GnuCLibTeenyVersion)

Bug#1077076: xutils-dev: Add hurd-amd64 definitions

[Samuel Thibault]

Samuel Thibault, le jeu. 25 juil. 2024 22:54:35 +0200, a ecrit:
> gnu.cf is missing the definitions for hurd-amd64, could you apply the
> attached patch to update it?

Sorry, some part was missing, please use this patch instead.

Samuel
--- debian/patches/04_xutils-dev-debian.diff.orig   2023-08-08 
13:36:41.0 +0200
+++ debian/patches/04_xutils-dev-debian.diff2024-07-25 23:03:11.749759074 
+0200
@@ -497,23 +501,27 @@
  #define YaccCmd   bison -y
  #define LexCmdflex -l
  #define HasFlex   YES
-@@ -125,50 +469,68 @@
+@@ -125,50 +469,77 @@ XCOMM Not implemented and will always fa
  #define StandardCppDefinesStandardDefines
  
  #define HasVarRun YES
 +#ifndef VarDbDirectory
  #define VarDbDirectory$(VARDIR)/lib
 +#endif
-+
+ 
+-XCOMM i386Architecture
+-#define OptimizedCDebugFlags  DefaultGcc2i386Opt
+-#define GNUMachineDefines -D__i386__
+-#define ServerOSDefines   XFree86ServerOSDefines -DDDXTIME
+-#define ServerExtraDefines-DGCCUSESGAS XFree86ServerDefines
+-#define HasPlugin YES
+-#define VendorHasX11R6_3libXext   YES
 +#ifndef OSXInputDrivers
 +# define OSXInputDrivers1 /**/
 +# define OSXInputDrivers2 /**/
 +# define OSXInputDrivers  OSXInputDrivers1 OSXInputDrivers2
 +#endif
- 
--XCOMM i386Architecture
--#define OptimizedCDebugFlags  DefaultGcc2i386Opt
--#define GNUMachineDefines -D__i386__
++
 +#define HasPlugin YES
 +#define VendorHasX11R6_3libXext   YES /* XC or XFree86 >= 3.3.1 */
 +
@@ -522,11 +530,18 @@
 +#  define OptimizedCDebugFlagsDefaultGcc2DebugOpt 
DefaultGcc2OptimizeOpt GccAliasingArgs
 +# endif
 +# define GnuMachineDefines-D__i386__
- #define ServerOSDefines   XFree86ServerOSDefines -DDDXTIME
- #define ServerExtraDefines-DGCCUSESGAS XFree86ServerDefines
--#define HasPlugin YES
--#define VendorHasX11R6_3libXext   YES
++# define ServerOSDefines  XFree86ServerOSDefines -DDDXTIME
++# define ServerExtraDefines   -DGCCUSESGAS XFree86ServerDefines
 +#endif /* i386Architecture */
++
++#ifdef AMD64Architecture
++# ifndef OptimizedCDebugFlags
++#  define OptimizedCDebugFlagsDefaultGcc2DebugOpt 
DefaultGcc2OptimizeOpt GccAliasingArgs
++# endif
++# define GnuMachineDefines-D__amd64__
++# define ServerOSDefines  XFree86ServerOSDefines -DDDXTIME
++# define ServerExtraDefines   -DGCCUSESGAS XFree86ServerDefines -D_XSERVER64
++#endif /* AMD64Architecture */
  
  #ifndef StandardDefines
 -#define StandardDefines   GNUMachineDefines GNUSourceDefines
@@ -2652,3 +2691,19 @@
  # endif
  #endif
  
+Index: xutils-dev-7.7+6.2+hurd.1/xorg-cf-files/Imake.cf
+===
+--- xutils-dev-7.7+6.2+hurd.1.orig/xorg-cf-files/Imake.cf
 xutils-dev-7.7+6.2+hurd.1/xorg-cf-files/Imake.cf
+@@ -1122,7 +1122,10 @@ XCOMM Keep cpp from replacing path eleme
+ #define MacroIncludeFile 
+ #define MacroFile gnu.cf
+ #ifdef __i386__
+-#define i386Architecture
++# define i386Architecture
++#endif
++#if defined(__amd64__) || defined(__x86_64__)
++# define AMD64Architecture
+ #endif
+ #endif
+ 

Bug#1077076: xutils-dev: Add hurd-amd64 definitions

[Samuel Thibault]

Package: xutils-dev
Version: 1:7.7+6.2
Severity: important
Tags: patch

Hello,

gnu.cf is missing the definitions for hurd-amd64, could you apply the
attached patch to update it?

Thanks,
Samuel

-- System Information:
Debian Release: trixie/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 'unreleased'), 
(500, 'testing-debug'), (500, 'stable-security'), (500, 'stable-debug'), (500, 
'oldstable-proposed-updates-debug'), (500, 'oldstable-proposed-updates'), (500, 
'oldoldstable'), (500, 'buildd-unstable'), (500, 'unstable'), (500, 'stable'), 
(500, 'oldstable'), (1, 'experimental-debug'), (1, 'buildd-experimental'), (1, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, arm64

Kernel: Linux 6.9.8-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages xutils-dev depends on:
ii  cpp4:13.2.0-7
ii  libc6  2.38-14

xutils-dev recommends no packages.

xutils-dev suggests no packages.

-- no debconf information

-- 
Samuel
As usual, this being a 1.3.x release, I haven't even compiled this
kernel yet.  So if it works, you should be doubly impressed.
(Linus Torvalds, announcing kernel 1.3.3 on the linux-kernel mailing list.)
--- debian/patches/04_xutils-dev-debian.diff.orig   2023-08-08 
13:36:41.0 +0200
+++ debian/patches/04_xutils-dev-debian.diff2024-07-25 22:53:18.993767815 
+0200
@@ -497,23 +501,27 @@
  #define YaccCmd   bison -y
  #define LexCmdflex -l
  #define HasFlex   YES
-@@ -125,50 +469,68 @@
+@@ -125,50 +469,77 @@ XCOMM Not implemented and will always fa
  #define StandardCppDefinesStandardDefines
  
  #define HasVarRun YES
 +#ifndef VarDbDirectory
  #define VarDbDirectory$(VARDIR)/lib
 +#endif
-+
+ 
+-XCOMM i386Architecture
+-#define OptimizedCDebugFlags  DefaultGcc2i386Opt
+-#define GNUMachineDefines -D__i386__
+-#define ServerOSDefines   XFree86ServerOSDefines -DDDXTIME
+-#define ServerExtraDefines-DGCCUSESGAS XFree86ServerDefines
+-#define HasPlugin YES
+-#define VendorHasX11R6_3libXext   YES
 +#ifndef OSXInputDrivers
 +# define OSXInputDrivers1 /**/
 +# define OSXInputDrivers2 /**/
 +# define OSXInputDrivers  OSXInputDrivers1 OSXInputDrivers2
 +#endif
- 
--XCOMM i386Architecture
--#define OptimizedCDebugFlags  DefaultGcc2i386Opt
--#define GNUMachineDefines -D__i386__
++
 +#define HasPlugin YES
 +#define VendorHasX11R6_3libXext   YES /* XC or XFree86 >= 3.3.1 */
 +
@@ -522,11 +530,18 @@
 +#  define OptimizedCDebugFlagsDefaultGcc2DebugOpt 
DefaultGcc2OptimizeOpt GccAliasingArgs
 +# endif
 +# define GnuMachineDefines-D__i386__
- #define ServerOSDefines   XFree86ServerOSDefines -DDDXTIME
- #define ServerExtraDefines-DGCCUSESGAS XFree86ServerDefines
--#define HasPlugin YES
--#define VendorHasX11R6_3libXext   YES
++# define ServerOSDefines  XFree86ServerOSDefines -DDDXTIME
++# define ServerExtraDefines   -DGCCUSESGAS XFree86ServerDefines
 +#endif /* i386Architecture */
++
++#ifdef AMD64Architecture
++# ifndef OptimizedCDebugFlags
++#  define OptimizedCDebugFlagsDefaultGcc2DebugOpt 
DefaultGcc2OptimizeOpt GccAliasingArgs
++# endif
++# define GnuMachineDefines-D__amd64__
++# define ServerOSDefines  XFree86ServerOSDefines -DDDXTIME
++# define ServerExtraDefines   -DGCCUSESGAS XFree86ServerDefines -D_XSERVER64
++#endif /* AMD64Architecture */
  
  #ifndef StandardDefines
 -#define StandardDefines   GNUMachineDefines GNUSourceDefines

Bug#1065666: mesa: Upgrading to mesa from testing breaks compiz

[Samuel Thibault]

Source: mesa
Version: 23.3.5-1
Severity: serious
Tags: a11y
Justification: breaks compiz

Hello,

When upgrading mesa to the version from testing, compiz does not start
any more. I tried both upgrading only mesa (and deps), as well as mesa
and the rest of the system, with the same result. compiz gets stuck
here:


 #0  0x7f15fadefa80 in __GI___poll (fds=fds@entry=0x7ffc95974370, 
nfds=nfds@entry=1, timeout=timeout@entry=-1) at 
../sysdeps/unix/sysv/linux/poll.c:29
 #1  0x7f15facd94d3 in poll (__timeout=-1, __nfds=1, __fds=0x7ffc95974370) 
at /usr/include/x86_64-linux-gnu/bits/poll2.h:47
 #2  read_block (len=8, buf=0x56080e7564e0, fd=4) at ../../src/xcb_in.c:394
 #3  _xcb_in_read_block (c=c@entry=0x56080e75ebb0, buf=0x56080e7564e0, 
len=len@entry=8) at ../../src/xcb_in.c:1087
 #4  0x7f15facd6b56 in read_setup (c=0x56080e75ebb0) at 
../../src/xcb_conn.c:180
 #5  xcb_connect_to_fd (fd=fd@entry=4, 
auth_info=auth_info@entry=0x7ffc959744b0) at ../../src/xcb_conn.c:384
 #6  0x7f15facdb192 in xcb_connect_to_display_with_auth_info 
(displayname=displayname@entry=0x0, auth=auth@entry=0x0, 
screenp=screenp@entry=0x7ffc959745ac)
 at ../../src/xcb_util.c:536
 #7  0x7f15facdb30a in xcb_connect (displayname=displayname@entry=0x0, 
screenp=screenp@entry=0x7ffc959745ac) at ../../src/xcb_util.c:493
 #8  0x7f15f83081cd in device_select_find_xcb_pci_default 
(devices=devices@entry=0x56080e7564c0, device_count=device_count@entry=1)
 at ../src/vulkan/device-select-layer/device_select_x11.c:72
 #9  0x7f15f8307cfb in get_default_device (expose_only_one_dev=, pPhysicalDevices=, physical_device_count=1, 
 selection=, info=) at 
../src/vulkan/device-select-layer/device_select_layer.c:498
 #10 device_select_EnumeratePhysicalDevices (instance=, 
pPhysicalDeviceCount=0x7ffc95974740, pPhysicalDevices=0x7ffc95974760)
 at ../src/vulkan/device-select-layer/device_select_layer.c:594
 #11 0x7f15f8350a9c in vkEnumeratePhysicalDevices () from 
/lib/x86_64-linux-gnu/libvulkan.so.1
 #12 0x7f15f64aa37e in choose_pdev (dev_minor=-1, dev_major=-1, 
screen=0x56080e732cc0) at ../src/gallium/drivers/zink/zink_screen.c:1637
 #13 zink_internal_create_screen (config=, 
dev_major=dev_major@entry=-1, dev_minor=dev_minor@entry=-1)
 at ../src/gallium/drivers/zink/zink_screen.c:3210
 #14 0x7f15f64ab73e in zink_create_screen (winsys=, 
config=) at ../src/gallium/drivers/zink/zink_screen.c:3557
 #15 0x7f15f611a2d5 in pipe_loader_sw_create_screen (dev=, 
config=, sw_vk=)
 at ../src/gallium/auxiliary/pipe-loader/pipe_loader_sw.c:426
 #16 0x7f15f611a218 in pipe_loader_create_screen_vk (dev=0x56080e72ce20, 
sw_vk=sw_vk@entry=false) at 
../src/gallium/auxiliary/pipe-loader/pipe_loader.c:184
 #17 0x7f15f611a24b in pipe_loader_create_screen (dev=) at 
../src/gallium/auxiliary/pipe-loader/pipe_loader.c:190
 #18 0x7f15f5ab6c2e in kopper_init_screen (screen=0x56080e729360) at 
../src/gallium/frontends/dri/kopper.c:134
 #19 0x7f15f5abb6dc in driCreateNewScreen2 (scrn=0, fd=-1, 
loader_extensions=0x7f15fa8e47e0 , 
driver_extensions=, 
 driver_configs=0x7ffc95975370, data=0x56080e696910) at 
../src/gallium/frontends/dri/dri_util.c:139
 #20 0x7f15fa8a3523 in driswCreateScreenDriver (screen=0, 
priv=0x56080e694430, driver=0x7f15fa8cc31b "zink") at ../src/glx/drisw_glx.c:979
 #21 0x7f15fa8a8401 in AllocAndFetchScreenConfigs 
(dpy=dpy@entry=0x56080e3c0270, priv=priv@entry=0x56080e694430, 
zink=zink@entry=1) at ../src/glx/glxext.c:798
 #22 0x7f15fa8a9385 in __glXInitialize (dpy=dpy@entry=0x56080e3c0270) at 
../src/glx/glxext.c:928
 #23 0x7f15fa8a61d6 in GetGLXPrivScreenConfig (ppsc=, 
ppriv=, scrn=0, dpy=0x56080e3c0270) at 
../src/glx/glxcmds.c:147
 #24 glXGetConfig (dpy=0x56080e3c0270, vis=0x56080e676820, attribute=1, 
value_return=0x7ffc959754ec) at ../src/glx/glxcmds.c:722
 #25 0x56080c4764e2 in addScreen (display=display@entry=0x56080e3beef0, 
screenNum=screenNum@entry=0, 
wmSnSelectionWindow=wmSnSelectionWindow@entry=6291457, 
 wmSnAtom=wmSnAtom@entry=436, wmSnTimestamp=wmSnTimestamp@entry=244386) at 
./src/screen.c:1984
 #26 0x56080c471407 in addDisplay (name=name@entry=0x0) at 
./src/display.c:2755
 #27 0x56080c46b8e2 in main (argc=, argv=0x7ffc95976278) at 
./src/main.c:519
 (gdb) info thread
   Id   Target Id Frame 
 * 1Thread 0x7f15fac147c0 (LWP 1034) "compiz" 0x7f15fadefa80 in 
__GI___poll (fds=fds@entry=0x7ffc95974370, nfds=nfds@entry=1, 
timeout=timeout@entry=-1)
 at ../sysdeps/unix/sysv/linux/poll.c:29

(I'll bounce to this bts the original report from a compiz user)

Samuel

-- System Information:
Debian Release: trixie/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 'unreleased'), 
(500, 'testing-debug'), (500, 'stable-security'), (500, 'stable-debug'), (500, 
'oldstable-proposed-updates-debug'), (500, 'oldstable-proposed-updates'), (500, 

Bug#1055420: libxi: Separate out documentation build

[Samuel Thibault]

Source: libxi
Version: 1.8-1
Severity: normal
Tags: patch

Hello,

libxi currently build-depends on w3m, which makes it part of a long
build dependency through imlib and whatnot image libraries. The w3m
dependency is actually only for building documentation. The attached
patch adds a nodoc build profile. This makes bootstraping a new Debian
port much easier.

Note that

chmod +x debian/libxi-dev.install

needs to be done to complete the patch.

Also, the patch is not working yet because the package has not been
converted to the quilt source format yet, and thus the +x is lost in the
.diff.gz format, but I guess there is no reason left for keeping using
the native source format?

Samuel

-- System Information:
Debian Release: trixie/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 
'testing-debug'), (500, 'stable-security'), (500, 'stable-debug'), (500, 
'oldstable-proposed-updates-debug'), (500, 'oldstable-proposed-updates'), (500, 
'oldoldstable-proposed-updates'), (500, 'oldoldstable'), (500, 
'buildd-unstable'), (500, 'unstable'), (500, 'stable'), (500, 'oldstable'), (1, 
'experimental-debug'), (1, 'buildd-experimental'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, arm64

Kernel: Linux 6.5.0-1-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
--- debian/control.original 2023-11-05 02:54:27.0 +
+++ debian/control  2023-11-05 16:55:42.0 +
@@ -4,6 +4,7 @@
 Maintainer: Debian X Strike Force 
 Build-Depends:
  debhelper-compat (= 12),
+ dh-exec,
  quilt,
  x11proto-dev (>= 2021.5),
  libx11-dev (>= 2:1.4.99.1),
@@ -15,10 +16,10 @@
  quilt,
  xutils-dev (>= 1:7.6+2),
 # specs
- xmlto,
- xorg-sgml-doctools (>= 1:1.8),
- xsltproc,
- w3m,
+ xmlto ,
+ xorg-sgml-doctools (>= 1:1.8) ,
+ xsltproc ,
+ w3m ,
 Standards-Version: 4.5.0
 Vcs-Git: https://salsa.debian.org/xorg-team/lib/libxi.git
 Vcs-Browser: https://salsa.debian.org/xorg-team/lib/libxi
--- debian/rules.original   2023-11-05 02:54:35.0 +
+++ debian/rules2023-11-05 16:53:05.0 +
@@ -10,12 +10,18 @@
 # set this to the name of the main shlib's binary package
 PACKAGE = libxi6
 
+ifeq (,$(filter nodoc,$(DEB_BUILD_PROFILES)))
+DOC = --with-xmlto
+else
+DOC = --disable-specs
+endif
+
 %:
dh $@ --with quilt --builddirectory=build/
 
 override_dh_auto_configure:
dh_auto_configure -- \
-   --with-xmlto \
+   $(DOC) \
--without-fop
 
 override_dh_install:
--- debian/libxi-dev.install.original   2023-11-05 16:54:25.0 +
+++ debian/libxi-dev.install2023-11-05 16:57:28.0 +
@@ -1,7 +1,8 @@
+#! /usr/bin/dh-exec
 usr/lib/*/libXi.a
 usr/lib/*/libXi.so
 usr/lib/*/pkgconfig/xi.pc
 usr/include/X11/extensions/
-usr/share/doc/libXi/*.html usr/share/doc/libxi-dev
-usr/share/doc/libXi/*.txt  usr/share/doc/libxi-dev
+ usr/share/doc/libXi/*.html usr/share/doc/libxi-dev
+ usr/share/doc/libXi/*.txt  usr/share/doc/libxi-dev
 usr/share/man/man3

Bug#1055412: xorg-server: Fix hurd-amd64 build

[Samuel Thibault]

Source: xorg-server
Version: 2:21.1.9-1
Severity: important
Tags: patch

Hello,

hurd-amd64 has the same constraint as hurd-i386, could you please apply
the attached patch?

Samuel

-- System Information:
Debian Release: trixie/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 
'testing-debug'), (500, 'stable-security'), (500, 'stable-debug'), (500, 
'oldstable-proposed-updates-debug'), (500, 'oldstable-proposed-updates'), (500, 
'oldoldstable-proposed-updates'), (500, 'oldoldstable'), (500, 
'buildd-unstable'), (500, 'unstable'), (500, 'stable'), (500, 'oldstable'), (1, 
'experimental-debug'), (1, 'buildd-experimental'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, arm64

Kernel: Linux 6.5.0-1-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

-- 
Samuel
---
Pour une évaluation indépendante, transparente et rigoureuse !
Je soutiens la Commission d'Évaluation de l'Inria.
--- debian/control.original 2023-11-05 10:38:47.0 +
+++ debian/control  2023-11-05 10:38:52.0 +
@@ -25,7 +25,7 @@
  libudev-dev (>= 151-3) [linux-any],
  libselinux1-dev (>= 2.0.80) [linux-any],
  libaudit-dev [linux-any],
- libdrm-dev (>= 2.4.107-5~) [!hurd-i386],
+ libdrm-dev (>= 2.4.107-5~) [!hurd-any],
  libgl1-mesa-dev (>= 9.2),
  mesa-common-dev,
  libunwind-dev [amd64 arm64 armel armhf hppa i386 ia64 mips64 mips64el mipsel 
powerpc powerpcspe ppc64 ppc64el sh4],
@@ -43,7 +43,7 @@
  libxfixes-dev (>= 1:3.0.0),
  libxv-dev,
  libxinerama-dev,
- libxshmfence-dev (>= 1.1) [!hurd-i386],
+ libxshmfence-dev (>= 1.1) [!hurd-any],
 # glamor
  libepoxy-dev [linux-any kfreebsd-any],
  libegl1-mesa-dev [linux-any kfreebsd-any],

Bug#1055396: libxaw: Separate out documentation build

[Samuel Thibault]

Source: libxaw
Version: 2:1.0.14-1
Severity: normal
Tags: patch

Hello,

libxaw currently build-depends on w3m, which makes it part of a long
build dependency through imlib and whatnot image libraries. The w3m
dependency is actually only for building documentation, which is already
separated into an arch:all binary package. The attached patch completes
the separation by separating out the build dependencies. This makes
bootstraping a new Debian port much easier.

Samuel

-- System Information:
Debian Release: trixie/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 
'testing-debug'), (500, 'stable-security'), (500, 'stable-debug'), (500, 
'oldstable-proposed-updates-debug'), (500, 'oldstable-proposed-updates'), (500, 
'oldoldstable-proposed-updates'), (500, 'oldoldstable'), (500, 
'buildd-unstable'), (500, 'unstable'), (500, 'stable'), (500, 'oldstable'), (1, 
'experimental-debug'), (1, 'buildd-experimental'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, arm64

Kernel: Linux 6.5.0-1-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

-- 
Samuel
---
Pour une évaluation indépendante, transparente et rigoureuse !
Je soutiens la Commission d'Évaluation de l'Inria.
--- debian/control.original 2023-11-05 13:00:42.0 +
+++ debian/control  2023-11-05 13:00:47.0 +
@@ -14,7 +14,7 @@
  quilt,
  dpkg-dev (>= 1.13.19),
  xutils-dev (>= 1:7.5+4),
-# specs:
+Build-Depends-Indep:
  xmlto, xorg-sgml-doctools (>= 1:1.5), w3m,
 Standards-Version: 4.6.0
 Vcs-Git: https://salsa.debian.org/xorg-team/lib/libxaw.git
--- debian/rules.original   2023-11-05 13:01:47.0 +
+++ debian/rules2023-11-05 13:02:06.0 +
@@ -15,11 +15,12 @@
 docflags = --enable-specs
 
 override_dh_auto_configure-arch: docflags = --disable-specs
+override_dh_auto_configure-indep: docflags = --with-xmlto
 override_dh_auto_configure-arch override_dh_auto_configure-indep:
dh_auto_configure -- \
--docdir=\$${datadir}/doc/libxaw7-dev \
--disable-xaw6 \
-   --with-xmlto --without-fop \
+   --without-fop \
--disable-silent-rules \
$(docflags)
 

Bug#1055384: libxtst: Separate out documentation build

[Samuel Thibault]

Source: libxtst
Version: 2:1.2.3-1.1
Severity: normal
Tags: patch

Hello,

libxtst currently build-depends on w3m, which makes it part of a long
build dependency through imlib and whatnot image libraries. The w3m
dependency is actually only for building documentation, which is already
separated into an arch:all binary package. The attached patch completes
the separation by separating out the build dependencies. This makes
bootstraping a new Debian port much easier.

Samuel

-- System Information:
Debian Release: trixie/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 
'testing-debug'), (500, 'stable-security'), (500, 'stable-debug'), (500, 
'oldstable-proposed-updates-debug'), (500, 'oldstable-proposed-updates'), (500, 
'oldoldstable-proposed-updates'), (500, 'oldoldstable'), (500, 
'buildd-unstable'), (500, 'unstable'), (500, 'stable'), (500, 'oldstable'), (1, 
'experimental-debug'), (1, 'buildd-experimental'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, arm64

Kernel: Linux 6.5.0-1-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

-- 
Samuel
---
Pour une évaluation indépendante, transparente et rigoureuse !
Je soutiens la Commission d'Évaluation de l'Inria.
--- debian/control.original 2023-11-05 10:54:07.0 +
+++ debian/control  2023-11-05 10:54:14.0 +
@@ -15,7 +15,7 @@
  xmlto,
  xutils-dev (>= 1:7.6+2),
  quilt,
-# specs:
+Build-Depends-Indep:
  xmlto (>= 0.0.22),
  xorg-sgml-doctools (>= 1:1.8),
  w3m,

Bug#1055369: libxfont: Separate out documentation build

[Samuel Thibault]

Source: libxfont
Version: 1:2.0.6-1
Severity: normal
Tags: patch

Hello,

libxfont currently build-depends on w3m, which makes it part of a long
build dependency through imlib and whatnot image libraries. The w3m
dependency is actually only for building documentation. The attached
patch adds a nodoc build profile. This makes bootstraping a new Debian
port much easier.

Samuel

-- System Information:
Debian Release: trixie/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 
'testing-debug'), (500, 'stable-security'), (500, 'stable-debug'), (500, 
'oldstable-proposed-updates-debug'), (500, 'oldstable-proposed-updates'), (500, 
'oldoldstable-proposed-updates'), (500, 'oldoldstable'), (500, 
'buildd-unstable'), (500, 'unstable'), (500, 'stable'), (500, 'oldstable'), (1, 
'experimental-debug'), (1, 'buildd-experimental'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, arm64

Kernel: Linux 6.5.0-1-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

-- 
Samuel
---
Pour une évaluation indépendante, transparente et rigoureuse !
Je soutiens la Commission d'Évaluation de l'Inria.
--- debian/control.original 2023-11-05 02:28:23.0 +
+++ debian/control  2023-11-05 02:28:30.0 +
@@ -15,7 +15,7 @@
  libbz2-dev,
  xutils-dev (>= 1:7.5+4),
 # devel-docs
- xmlto, xorg-sgml-doctools (>= 1:1.7), w3m,
+ xmlto , xorg-sgml-doctools (>= 1:1.7) , w3m ,
 Standards-Version: 4.5.0
 Vcs-Git: https://salsa.debian.org/xorg-team/lib/libxfont
 Vcs-Browser: https://salsa.debian.org/xorg-team/lib/libxfont
--- debian/rules.original   2023-11-05 02:31:39.0 +
+++ debian/rules2023-11-05 02:33:48.0 +
@@ -11,12 +11,17 @@
 # Strip -Bsymbolic-functions (set by default on Ubuntu) to avoid breakages:
 LDFLAGS := $(LDFLAGS:-Wl,-Bsymbolic-functions=)
 
+ifeq (,$(filter nodoc,$(DEB_BUILD_PROFILES)))
+DOC = --enable-devel-docs --with-xmlto
+else
+DOC = --disable-devel-docs --without-xmlto
+endif
+
 CONFFLAGS += \
--disable-fc \
--enable-builtins \
--enable-pcfformat \
--enable-bdfformat \
-   --enable-devel-docs \
--without-fop \
--disable-silent-rules \
CFLAGS="$(CFLAGS)" \
@@ -30,8 +35,8 @@
rm -rf build-udeb/ debian/tmp-udeb/
 
 override_dh_auto_configure:
-   dh_auto_configure $(OOT)-main/ -- --with-bzip2--with-xmlto
$(CONFFLAGS)
-   dh_auto_configure $(OOT)-udeb/ -- --without-bzip2 --without-xmlto 
$(CONFFLAGS)
+   dh_auto_configure $(OOT)-main/ -- --with-bzip2$(CONFFLAGS) $(DOC)
+   dh_auto_configure $(OOT)-udeb/ -- --without-bzip2 $(CONFFLAGS)
 
 override_dh_auto_build:
$(MAKE) -C build-main/

Bug#1055368: libxmu: Separate out documentation build

[Samuel Thibault]

Source: libxmu
Version: 1.1.3-3
Severity: normal
Tags: patch

Hello,

libxmu currently build-depends on w3m, which makes it part of a long
build dependency through imlib and whatnot image libraries. The w3m
dependency is actually only for building documentation, which is already
separated into an arch:all binary package. The attached patch completes
the separation by separating out the build dependencies. This makes
bootstraping a new Debian port much easier.

Samuel

-- System Information:
Debian Release: trixie/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 
'testing-debug'), (500, 'stable-security'), (500, 'stable-debug'), (500, 
'oldstable-proposed-updates-debug'), (500, 'oldstable-proposed-updates'), (500, 
'oldoldstable-proposed-updates'), (500, 'oldoldstable'), (500, 
'buildd-unstable'), (500, 'unstable'), (500, 'stable'), (500, 'oldstable'), (1, 
'experimental-debug'), (1, 'buildd-experimental'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, arm64

Kernel: Linux 6.5.0-1-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

-- 
Samuel
---
Pour une évaluation indépendante, transparente et rigoureuse !
Je soutiens la Commission d'Évaluation de l'Inria.
--- debian/control.original 2023-11-05 03:18:06.596293166 +0100
+++ debian/control  2023-11-05 03:18:13.500335188 +0100
@@ -10,7 +10,7 @@
  pkg-config,
  quilt,
  xutils-dev (>= 1:7.6+2),
-# devel-docs:
+Build-Depends-Indep:
  xmlto (>= 0.0.22),
  xorg-sgml-doctools (>= 1:1.8),
  w3m,
--- debian/rules.original   2023-11-05 03:18:57.532603448 +0100
+++ debian/rules2023-11-05 03:19:34.300827775 +0100
@@ -14,11 +14,13 @@
 %:
dh $@ --with quilt --builddirectory=build/
 
-override_dh_auto_configure:
+override_dh_auto_configure-arch: docflags =
+override_dh_auto_configure-indep: docflags = --with-xmlto
+override_dh_auto_configure-arch override_dh_auto_configure-indep::
dh_auto_configure -- \
--disable-silent-rules \
--docdir=\$${prefix}/share/doc/libxmu-headers \
-   --with-xmlto \
+   $(docflags) \
--without-fop
 
 override_dh_auto_install:

Bug#1055365: libsm: Separate out documentation build

[Samuel Thibault]

Source: libsm
Version: 1.2.3-1
Severity: normal
Tags: patch

Hello,

libsm currently build-depends on w3m, which makes it part of a long
build dependency through imlib and whatnot image libraries. The w3m
dependency is actually only for building documentation, which is already
separated into an arch:all binary package. The attached patch completes
the separation by separating out the build dependencies. This makes
bootstraping a new Debian port much easier.

Samuel

-- System Information:
Debian Release: trixie/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 
'testing-debug'), (500, 'stable-security'), (500, 'stable-debug'), (500, 
'oldstable-proposed-updates-debug'), (500, 'oldstable-proposed-updates'), (500, 
'oldoldstable-proposed-updates'), (500, 'oldoldstable'), (500, 
'buildd-unstable'), (500, 'unstable'), (500, 'stable'), (500, 'oldstable'), (1, 
'experimental-debug'), (1, 'buildd-experimental'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, arm64

Kernel: Linux 6.5.0-1-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

-- 
Samuel
---
Pour une évaluation indépendante, transparente et rigoureuse !
Je soutiens la Commission d'Évaluation de l'Inria.
--- debian/control.original 2023-11-05 00:56:09.0 +
+++ debian/control  2023-11-05 01:02:42.0 +
@@ -11,7 +11,7 @@
  uuid-dev,
  xutils-dev (>= 1:7.6+2),
  quilt,
-# doc:
+Build-Depends-Indep:
  xmlto (>= 0.0.22), xorg-sgml-doctools (>= 1:1.8), w3m,
 Standards-Version: 4.3.0
 Homepage: https://www.x.org
--- debian/rules.original   2023-11-05 00:59:57.0 +
+++ debian/rules2023-11-05 01:00:09.0 +
@@ -13,12 +13,12 @@
 %:
dh $@ --with quilt --builddirectory=build/
 
-override_dh_auto_configure-arch: docflags = --disable-docs
-override_dh_auto_configure-indep: docflags = --enable-docs
+override_dh_auto_configure-arch: docflags = --disable-docs
+override_dh_auto_configure-indep: docflags = --enable-docs --with-xmlto
 override_dh_auto_configure-arch override_dh_auto_configure-indep:
dh_auto_configure -- \
--with-libuuid \
-   --with-xmlto --without-fop \
+   --without-fop \
--docdir=\$${datadir}/doc/libsm-dev \
$(docflags)
 

Bug#717843: please provide a staged build for xfonts-utils

[Samuel Thibault]

Hello,

Any news on this? This is posing problem to bootstrap each and every new
Debian port.

Samuel

Bug#1035622: libpciaccess: Add hurd-amd64 symbols

[Samuel Thibault]

Source: libpciaccess
Version: 0.17-2
Severity: important
Tags: patch
User: debian-h...@lists.debian.org
Usertags: hurd

Hello,

The attached patch fixes the symbol list for hurd-amd64.

Samuel

-- System Information:
Debian Release: 12.0
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 
'testing-debug'), (500, 'stable-security'), (500, 'stable-debug'), (500, 
'proposed-updates-debug'), (500, 'proposed-updates'), (500, 
'oldstable-proposed-updates'), (500, 'oldoldstable'), (500, 'buildd-unstable'), 
(500, 'unstable'), (500, 'stable'), (500, 'oldstable'), (1, 
'experimental-debug'), (1, 'buildd-experimental'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, arm64

Kernel: Linux 6.2.0 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
--- debian/libpciaccess0.symbols.original   2023-05-06 18:31:42.923396000 
+
+++ debian/libpciaccess0.symbols2023-05-06 18:31:54.219239521 +
@@ -44,14 +44,14 @@
  pci_device_vgaarb_set_target@Base 0.10.7
  pci_device_vgaarb_trylock@Base 0.10.7
  pci_device_vgaarb_unlock@Base 0.10.7
- (arch=hurd-i386)pci_device_x86_close_io@Base 0.16
- (arch=hurd-i386)pci_device_x86_open_legacy_io@Base 0.16
- (arch=hurd-i386)pci_device_x86_read16@Base 0.16
- (arch=hurd-i386)pci_device_x86_read32@Base 0.16
- (arch=hurd-i386)pci_device_x86_read8@Base 0.16
- (arch=hurd-i386)pci_device_x86_write16@Base 0.16
- (arch=hurd-i386)pci_device_x86_write32@Base 0.16
- (arch=hurd-i386)pci_device_x86_write8@Base 0.16
+ (arch=hurd-any)pci_device_x86_close_io@Base 0.16
+ (arch=hurd-any)pci_device_x86_open_legacy_io@Base 0.16
+ (arch=hurd-any)pci_device_x86_read16@Base 0.16
+ (arch=hurd-any)pci_device_x86_read32@Base 0.16
+ (arch=hurd-any)pci_device_x86_read8@Base 0.16
+ (arch=hurd-any)pci_device_x86_write16@Base 0.16
+ (arch=hurd-any)pci_device_x86_write32@Base 0.16
+ (arch=hurd-any)pci_device_x86_write8@Base 0.16
  pci_get_strings@Base 0
  pci_id_match_iterator_create@Base 0
  pci_io_read16@Base 0.11.0
@@ -67,7 +67,7 @@
  (arch=kfreebsd-any)pci_system_freebsd_init_dev_mem@Base 0.16
  pci_system_init@Base 0
  pci_system_init_dev_mem@Base 0.10.2
- (arch=hurd-i386)pci_system_x86_destroy@Base 0.16
- (arch=hurd-i386)pci_system_x86_map_dev_mem@Base 0.17
- (arch=hurd-i386)x86_disable_io@Base 0.16
- (arch=hurd-i386)x86_enable_io@Base 0.16
+ (arch=hurd-any)pci_system_x86_destroy@Base 0.16
+ (arch=hurd-any)pci_system_x86_map_dev_mem@Base 0.17
+ (arch=hurd-any)x86_disable_io@Base 0.16
+ (arch=hurd-any)x86_enable_io@Base 0.16

Bug#1023418: libpciaccess: FTBFS on hurd-i386: symbol list update

[Samuel Thibault]

Source: libpciaccess
Version: 0.17-1
Severity: important
Tags: patch
User: debian-h...@lists.debian.org
Usertags: hurd

Hello,

The newer libpciaccess doesn't build on hurd-i386 because the newer
upstream version modified some symbols. The attached patch fixes that. I
checked that indeed no package is using the old
pci_device_x86_map/unmap_legacy/range (they were used only internally by
the library).

Could you apply it?

Thanks,
Samuel

-- System Information:
Debian Release: bookworm/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 
'testing-debug'), (500, 'stable-security'), (500, 'stable-debug'), (500, 
'proposed-updates-debug'), (500, 'proposed-updates'), (500, 
'oldstable-proposed-updates'), (500, 'oldoldstable'), (500, 'buildd-unstable'), 
(500, 'unstable'), (500, 'stable'), (500, 'oldstable'), (1, 
'experimental-debug'), (1, 'buildd-experimental'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, arm64

Kernel: Linux 6.0.0-2-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

-- 
Samuel
---
Pour une évaluation indépendante, transparente et rigoureuse !
Je soutiens la Commission d'Évaluation de l'Inria.
--- debian/libpciaccess0.symbols.original   2022-11-03 18:16:21.0 
+
+++ debian/libpciaccess0.symbols2022-11-03 18:17:26.0 +
@@ -45,14 +45,10 @@
  pci_device_vgaarb_trylock@Base 0.10.7
  pci_device_vgaarb_unlock@Base 0.10.7
  (arch=hurd-i386)pci_device_x86_close_io@Base 0.16
- (arch=hurd-i386)pci_device_x86_map_legacy@Base 0.16
- (arch=hurd-i386)pci_device_x86_map_range@Base 0.16
  (arch=hurd-i386)pci_device_x86_open_legacy_io@Base 0.16
  (arch=hurd-i386)pci_device_x86_read16@Base 0.16
  (arch=hurd-i386)pci_device_x86_read32@Base 0.16
  (arch=hurd-i386)pci_device_x86_read8@Base 0.16
- (arch=hurd-i386)pci_device_x86_unmap_legacy@Base 0.16
- (arch=hurd-i386)pci_device_x86_unmap_range@Base 0.16
  (arch=hurd-i386)pci_device_x86_write16@Base 0.16
  (arch=hurd-i386)pci_device_x86_write32@Base 0.16
  (arch=hurd-i386)pci_device_x86_write8@Base 0.16
@@ -72,5 +68,6 @@
  pci_system_init@Base 0
  pci_system_init_dev_mem@Base 0.10.2
  (arch=hurd-i386)pci_system_x86_destroy@Base 0.16
+ (arch=hurd-i386)pci_system_x86_map_dev_mem@Base 0.17
  (arch=hurd-i386)x86_disable_io@Base 0.16
  (arch=hurd-i386)x86_enable_io@Base 0.16

Re: Bug#1020421: /usr/libexec/at-spi-bus-launcher: If I start some programs (i.e. gimp), system gets me out of the session and show me login again

[Samuel Thibault]

Control: reassign -1 mesa
Control: retitle -1 If I start some programs (i.e. gimp), system gets me out of 
the session and show me login again

Roberto, le jeu. 22 sept. 2022 12:33:13 +, a ecrit:
> In the .old file I found:
> --
> [  1450.752] Failed to compile FS: 0:1(10): error: GLSL 1.30 is not supported.
> Supported versions are: 1.10, 1.20, and 1.00 ES
> --
> 
> I think this is the problem...

That's a sign indeed. Thus reassigning to mesa for now.

Samuel

Bug#994276: xutils-dev: imake shouldn't pass l to ar

[Samuel Thibault]

Package: xutils-dev
Version: 1:7.7+5+b1
Severity: serious
Tags: patch
Justification: Makes xtel FTBFS

Hello,

xtel started failing to build in bullseye, e.g.
https://tests.reproducible-builds.org/debian/rbuild/unstable/amd64/xtel_3.3.0-24.rbuild.log.gz
“
ar clq libVideotex.a Videotex.o tvr_jpg.o tvr_hdr.o
ar: libdeps specified more than once
”

That's because imake passes clq to ar, but while the 'l' letter has been
ignored by ar for a long time, ar doesn't ignore it any more, and is
thus getting confused by imake passing it.

The attached patch fixes it by telling imask to use just "ar cq".

Samuel

-- System Information:
Debian Release: bookworm/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 
'testing-debug'), (500, 'stable-security'), (500, 'stable-debug'), (500, 
'proposed-updates-debug'), (500, 'proposed-updates'), (500, 
'oldstable-proposed-updates-debug'), (500, 'oldstable-proposed-updates'), (500, 
'oldoldstable'), (500, 'buildd-unstable'), (500, 'unstable'), (500, 'stable'), 
(500, 'oldstable'), (1, 'experimental-debug'), (1, 'buildd-experimental'), (1, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.14.0 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages xutils-dev depends on:
ii  cpp4:10.2.1-1
ii  libc6  2.31-17

xutils-dev recommends no packages.

xutils-dev suggests no packages.

-- no debconf information

-- 
Samuel
Pour un père, autant mourir que de faire plein de calculs et pas s'occuper
de son fils
 -+- y sur #ens-mim - sombres histoires de zombies -+-
---
 xorg-cf-files/linux.cf |4 
 1 file changed, 4 insertions(+)

--- a/xorg-cf-files/linux.cf
+++ b/xorg-cf-files/linux.cf
@@ -875,6 +875,10 @@ InstallNamedTargetNoClobber(install,file
 # endif
 #endif
 
+#ifndef ArCmd
+# define ArCmd ArCmdBase cq
+#endif
+
 /*
  * Some older distros still need /lib/cpp.  There's probably a better
  * test, but this handles the older Red Hat releases at least.

Bug#909436: libdrm 2.4.102-1: FTBFS on hurd-i386 (updated patches)

[Samuel Thibault]

Svante Signell, le mar. 27 avril 2021 01:04:30 +0200, a ecrit:
> On Mon, 2021-04-26 at 23:43 +0200, Samuel Thibault wrote:
> > For information, your patch got dropped because of #975658
> 
> Yes I know since a long time.

Ok, I hadn't seen it.

> And you did not care or anybody else either.

Well, usually it's the patch author who follows up on its consequences.

> So why bother... Why spend time on worthless issues?

Worthless? Qt5 depends on it.

Samuel

Bug#909436: libdrm 2.4.102-1: FTBFS on hurd-i386 (updated patches)

[Samuel Thibault]

Hello Svante,

For information, your patch got dropped because of #975658

Samuel

Bug#909436: libdrm 2.4.102-1: FTBFS on hurd-i386 (updated patches)

[Samuel Thibault]

Hello,

Svante Signell, le lun. 14 sept. 2020 17:44:24 +0200, a ecrit:
> +#elif defined(__GNU__)
> +#include 
> +#include 
> +#define DRM_IOCTL_NR(n) ((n) & 0xff)

Rather use _IOC_COMMAND, that'll fix it into taking 7 bits only, not 8.

Samuel

Bug#947748: xorg-server: FTBFS in sid (probably due to newer mesa)

[Samuel Thibault]

Source: xorg-server
Version: 2:1.20.6-1
Severity: serious
Tags: patch
Justification: FTBFS

Hello,

Probably since the upload of the newer mesa, xorg-server now FTBFS,
because it misses dri.pc and x11-xcb.pc. The attached patch fixes this.

Samuel

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 
'testing-debug'), (500, 'stable-debug'), (500, 'proposed-updates-debug'), (500, 
'proposed-updates'), (500, 'oldstable-proposed-updates-debug'), (500, 
'oldstable-proposed-updates'), (500, 'oldoldstable'), (500, 'buildd-unstable'), 
(500, 'unstable'), (500, 'stable'), (500, 'oldstable'), (1, 
'experimental-debug'), (1, 'buildd-experimental'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.4.0 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

-- 
Samuel
"c'est pas nous qui sommes à la rue, c'est la rue qui est à nous"
--- debian/control.original 2019-12-29 23:42:11.163003763 +0100
+++ debian/control  2019-12-29 23:42:28.333138832 +0100
@@ -13,6 +13,7 @@
  xutils-dev (>= 1:7.6+4),
  xfonts-utils (>= 1:7.5+1),
  x11proto-dev (>= 2018.4),
+ libx11-xcb-dev,
  xtrans-dev (>= 1.3.5),
  libxau-dev (>= 1:1.0.5-2),
  libxdmcp-dev (>= 1:0.99.1),
@@ -27,6 +28,7 @@
  libaudit-dev [linux-any],
  libdrm-dev (>= 2.4.89) [!hurd-i386],
  libgl1-mesa-dev (>= 9.2),
+ mesa-common-dev,
  libunwind-dev [amd64 arm64 armel armhf hppa i386 ia64 mips64 mips64el mipsel 
powerpc powerpcspe ppc64 ppc64el sh4],
  libxmuu-dev (>= 1:0.99.1),
  libxext-dev (>= 1:0.99.1),

Bug#947746: xorg-server: fix build on hurd-any

[Samuel Thibault]

Source: xorg-server
Version: 2:1.20.1-2
Severity: important
Tags: patch

Hello,

Since 2:1.20.1-2 the non-drm builds (on hurd-any) fail, because
the 07_use-modesetting-driver-by-default-on-GeForce.diff patch
unconditionally includes xf86drm.h. I have attached a patch over the
patch, and the resulting updated patch, whichever you prefer to use :)

Samuel

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 
'testing-debug'), (500, 'stable-debug'), (500, 'proposed-updates-debug'), (500, 
'proposed-updates'), (500, 'oldstable-proposed-updates-debug'), (500, 
'oldstable-proposed-updates'), (500, 'oldoldstable'), (500, 'buildd-unstable'), 
(500, 'unstable'), (500, 'stable'), (500, 'oldstable'), (1, 
'experimental-debug'), (1, 'buildd-experimental'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.4.0 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

-- 
Samuel
>   dvips -o $@ $< 
Faut faire gffe de pas te couper avec ton truc, t'as mis des ciseaux ($<)
partout :))
-+- Dom in Guide du linuxien pervers - "J'aime pas les Makefile !" -+-
--- debian/patches/07_use-modesetting-driver-by-default-on-GeForce.diff.orig
2019-12-29 23:14:56.170075293 +0100
+++ debian/patches/07_use-modesetting-driver-by-default-on-GeForce.diff 
2019-12-29 23:15:09.090178045 +0100
@@ -13,11 +13,13 @@
 index 8158c2b62..78d1c947d 100644
 --- a/hw/xfree86/common/xf86pciBus.c
 +++ b/hw/xfree86/common/xf86pciBus.c
-@@ -37,6 +37,7 @@
+@@ -37,6 +37,9 @@
  #include 
  #include 
  #include 
++#if defined(__linux__) || defined(__NetBSD__)
 +#include 
++#endif
  #include "os.h"
  #include "Pci.h"
  #include "xf86.h"
>From aa2f34d80ef3118eae0cce73b610c36cdcb978fe Mon Sep 17 00:00:00 2001
From: Ben Skeggs 
Date: Sat, 22 Apr 2017 02:26:28 +1000
Subject: [PATCH xserver] xfree86: use modesetting driver by default on GeForce
 8 and newer

Signed-off-by: Ben Skeggs 
---
 hw/xfree86/common/xf86pciBus.c | 20 
 1 file changed, 20 insertions(+)

diff --git a/hw/xfree86/common/xf86pciBus.c b/hw/xfree86/common/xf86pciBus.c
index 8158c2b62..78d1c947d 100644
--- a/hw/xfree86/common/xf86pciBus.c
+++ b/hw/xfree86/common/xf86pciBus.c
@@ -37,6 +37,9 @@
 #include 
 #include 
 #include 
+#if defined(__linux__) || defined(__NetBSD__)
+#include 
+#endif
 #include "os.h"
 #include "Pci.h"
 #include "xf86.h"
@@ -1190,6 +1191,25 @@ xf86VideoPtrToDriverList(struct pci_device *dev,
 int idx = 0;
 
 #if defined(__linux__) || defined(__NetBSD__)
+char busid[32];
+int fd;
+
+snprintf(busid, sizeof(busid), "pci:%04x:%02x:%02x.%d",
+ dev->domain, dev->bus, dev->dev, dev->func);
+
+	/* 'modesetting' is preferred for GeForce 8 and newer GPUs */
+fd = drmOpenWithType("nouveau", busid, DRM_NODE_RENDER);
+if (fd >= 0) {
+uint64_t args[] = { 11 /* NOUVEAU_GETPARAM_CHIPSET_ID */, 0 };
+int ret = drmCommandWriteRead(fd, 0 /* DRM_NOUVEAU_GETPARAM */,
+  , sizeof(args));
+drmClose(fd);
+if (ret == 0) {
+if (args[1] == 0x050 || args[1] >= 0x80)
+break;
+}
+}
+
 driverList[idx++] = "nouveau";
 #endif
 driverList[idx++] = "nv";
-- 
2.12.2

Re: Bug#946118: synaptics touchpad does not work in debian installer graphical mode

[Samuel Thibault]

Hello,

dinar qurbanov, le lun. 09 déc. 2019 21:00:46 +0300, a ecrit:
> "Dinar, could you try the image from
> http://people.debian.org/~sthibault/tmp/mini.iso
> to see whether it helps? "
> 
> i have downloaded it but then become afraid , that malware may be
> there.

You are right to being cautious :)

But you can download through https with

https://people.debian.org/~sthibault/tmp/mini.iso

to make sure that it is coming from the people.debian.org domain,
which only Debian Developers like myself can put data on. And Debian
Developers can already upload anything to the Debian archive, see for
instance your /usr/share/doc/libc6/changelog.Debian.gz to see that you
are already using packages that I have uploaded to Debian. I have signed
this mail, for good measure.

> > "This bug report is unlikely to be actionable unless you specify
> > *exactly* which model of computer you are using.  There are literally
> > hundreds of different touchpad devices out there."
> 
> i was going to write exact laptop model, but i became afraid that this
> information can help somebody to infect my laptop's firmwares.

Not unless they have a way to actually reach your laptop.

> and seems that info is not useful to know out exact touchpad model.

It definitely is! Depending on the laptop brand and manufacture, making
the touchpad work will vary. On my XPS13, it is connected through i2c to
a PCI intel lpss card. On another laptop, exactly the same model of
touchpad could be connected another way, thus requiring another driver.

Samuel


signature.asc
Description: PGP signature

Re: xvfb-run seems to start command too early

[Samuel Thibault]

Hello,

Yannick Schinko, le lun. 04 nov. 2019 14:25:43 +, a ecrit:
> When using xvfb-run (1.19.2-1+deb9u5) to run gource headless I run into the 
> issue that the underlying server does not seem to be ready in time a good 
> 75+% of cases.

Note that the xvfb-run script is a Debian script (thus Cc-ing
maintainers there just for information), but possibly the issue is
inside the Xserver, see below.

> In those cases gource complains:
> gource: SDL initialization failed - Couldn't find matching GLX visual
> 
> Now this suspicion is amplified because when I run it as "xvfb-run  
> bash -c "sleep 1; gource " it works every time.
> 
> Is there some way to work around this issue other than having a sleep before 
> the gource command (which would make working with some scripts a pain)?

It happens that the Debian xvfb-run script takes good care of using
SIGUSR1 to synchronize with Xvfb (see SIGUSR1 in man Xserver), so I'm
surprised that you're running into issues. Perhaps the X server is
sending SIGUSR1 too early?

Samuel

Bug#931332: xserver-xorg-core: X crash on keyboard remapping

[Samuel Thibault]

Just for the record: the patch is commited in master for 1.21, and in
server-1.20-branch for 1.20.6.

Samuel

Bug#931332: xserver-xorg-core: X crash on keyboard remapping

[Samuel Thibault]

Package: xserver-xorg-core
Version: 2:1.20.4-1
Severity: important
Tags: patch a11y
Forwarded: https://gitlab.freedesktop.org/xorg/xserver/issues/574

Hello,

As reported on https://gitlab.freedesktop.org/xorg/xserver/issues/574
X crashes on XkbSetMap. Running the attached patch is enough to crash
the server.

This is notably a concern for people using Braille devices to type text,
because at-spi and xbrlapi use keyboard remapping to be able to simulate
all needed keysyms. Just typing e.g. 'ô' (⢹ in french Braille) is
enough to crash the server.

The attached patch was commited upstream to fix this, could you consider
including it in the next Buster point release?

Stretch does not seem to be affected.

Samuel
#include 
#include 
#include 
#define XK_LATIN1
#include 
#include 

int main(void) {
  Display *dpy;
  dpy = XOpenDisplay("");
  int keycode = 240;
  int keysym = XK_ecircumflex;

  XkbDescPtr desc;
  if (!(desc = XkbGetMap (dpy, XkbAllMapComponentsMask, XkbUseCoreKbd)))
{
  fprintf (stderr, "ERROR getting map\n");
}
  XFlush (dpy);
  XSync (dpy, False);
  if (desc && desc->map)
{
  int offset = desc->map->key_sym_map[keycode].offset;
  desc->map->syms[offset] = keysym; 
}
  else
{
  fprintf (stderr, "Error changing key map: empty server structure\n");
}		
  XkbSetMap (dpy, XkbAllMapComponentsMask, desc);
  /**
   *  FIXME: the use of XkbChangeMap, and the reuse of the priv->xkb_desc structure, 
   * would be far preferable.
   * HOWEVER it does not seem to work using XFree 4.3. 
   **/
  /*	XkbChangeMap (dpy, priv->xkb_desc, priv->changes); */
  XFlush (dpy);
  XSync (dpy, False);
  XkbFreeKeyboard (desc, 0, TRUE);

  return TRUE;
}
commit 8469bfead9515ab3644f1769a1ff51466ba8ffee
Author: Samuel Thibault 
Date:   Mon Jul 1 02:31:02 2019 +0200

Fix crash on XkbSetMap

Some devices may not have keyboard information.

Fixes #574

diff --git a/xkb/xkb.c b/xkb/xkb.c
index 764079506..9bd45a34a 100644
--- a/xkb/xkb.c
+++ b/xkb/xkb.c
@@ -2383,6 +2383,9 @@ _XkbSetMapChecks(ClientPtr client, DeviceIntPtr dev, 
xkbSetMapReq * req,
 XkbSymMapPtr map;
 int i;
 
+if (!dev->key)
+return 0;
+
 xkbi = dev->key->xkbInfo;
 xkb = xkbi->desc;
 
@@ -2495,6 +2498,9 @@ _XkbSetMap(ClientPtr client, DeviceIntPtr dev, 
xkbSetMapReq * req, char *values)
 XkbSrvInfoPtr xkbi;
 XkbDescPtr xkb;
 
+if (!dev->key)
+return Success;
+
 xkbi = dev->key->xkbInfo;
 xkb = xkbi->desc;
 
commit fabc4219622f3c0b41b1cb897c46e092377059e3
Author: Samuel Thibault 
Date:   Mon Jul 1 02:33:26 2019 +0200

Fix crash on XkbSetMap

Since group_info and width are used for the key actions allocations,
when modifying them we need to take care of reallocation key actions if
needed.

diff --git a/xkb/xkb.c b/xkb/xkb.c
index 9bd45a34a..3162574a4 100644
--- a/xkb/xkb.c
+++ b/xkb/xkb.c
@@ -2110,6 +2110,9 @@ SetKeySyms(ClientPtr client,
 }
 }
 }
+if (XkbKeyHasActions(xkb, i + req->firstKeySym))
+XkbResizeKeyActions(xkb, i + req->firstKeySym,
+XkbNumGroups(wire->groupInfo) * wire->width);
 oldMap->kt_index[0] = wire->ktIndex[0];
 oldMap->kt_index[1] = wire->ktIndex[1];
 oldMap->kt_index[2] = wire->ktIndex[2];

Re: Bug#905268: at-spi2-core: key repeat causes a blocked system

[Samuel Thibault]

Control: reassign -1 xorg-server

Hello,

Are you running the orca screen reader?

Michael Becker, le jeu. 02 août 2018 13:00:22 +0200, a ecrit:
> if pressing the cursor up/down keys for two to three seconds the mouse cursor 
> starts moving and neither keyboard nor mouse input is possible

So you only press the PC keyboard up/down keys, and then the mouse
moves?

> this also happens if the keyrepeat functionality is disabled in the xfce4 
> configuration
> /var/log/messages shows the following error:
> 
> org.a11y.Bus[7817]: XIO:  fatal IO error 11 (Resource temporarily 
> unavailable) on X server ":1"
> org.a11y.Bus[7817]:   after 21 requests (21 known processed) with 0 
> events remaining.
> 
> thus I am guessing the problem is related to at-spi2-core

Nope, it's the contrary: at-spi2-core is seeing X unresponsive and just
logs about it. Thus reassigning. You should rather look for the X server
log, in /var/log/Xorg.0.log or ~/.local/share/xorg/Xorg.0.log

Samuel

Bug#900791: xserver-xorg-input-mouse: FTBFS with newer xserver

[Samuel Thibault]

Package: xserver-xorg-input-mouse
Version: 1:1.9.2-1+b1
Severity: serious
Justification: FTBFS
Tags: upstream fixed-upstream patch

Hello,

With the newer xserver, xserver-xorg-input-mouse doesn't build any more:

../../src/mouse.c:824:5: error: implicit declaration of function 'xf86GetOS'; 
did you mean 'xf86SetDpi'? [-Werror=implicit-function-declaration]
 xf86GetOS(, NULL, NULL, NULL);

That got removed from xserver.

Upstream has 3c8f243b750a92d5837a449d344ff884dbd02b57 ("Adapt to removal
of xf86GetOS"), attached here, which can at least be cherry-picked.

Samuel


-- Package-specific info:
X server symlink status:

lrwxrwxrwx 1 root root 13 Aug 24  2015 /etc/X11/X -> /usr/bin/Xorg
-rwxr-xr-x 1 root root 274 Jan 18 13:11 /usr/bin/Xorg

Diversions concerning libGL are in place

diversion of /usr/lib/arm-linux-gnueabihf/libGL.so.1.2.0 to 
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGL.so.1.2.0 by glx-diversions
diversion of /usr/lib/libGL.so.1 to /usr/lib/mesa-diverted/libGL.so.1 by 
glx-diversions
diversion of /usr/lib/arm-linux-gnueabihf/libGLESv2.so.2.0.0 to 
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv2.so.2.0.0 by glx-diversions
diversion of /usr/lib/libGLESv2.so.2 to /usr/lib/mesa-diverted/libGLESv2.so.2 
by glx-diversions
diversion of /usr/lib/arm-linux-gnueabihf/libGL.so to 
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGL.so by glx-diversions
diversion of /usr/lib/x86_64-linux-gnu/libGLESv1_CM.so.1.1.0 to 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv1_CM.so.1.1.0 by glx-diversions
diversion of /usr/lib/arm-linux-gnueabihf/libGLESv1_CM.so to 
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv1_CM.so by glx-diversions
diversion of /usr/lib/i386-linux-gnu/libGLESv2.so.2 to 
/usr/lib/mesa-diverted/i386-linux-gnu/libGLESv2.so.2 by glx-diversions
diversion of /usr/lib/arm-linux-gnueabihf/libGLESv2.so.2.1.0 to 
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv2.so.2.1.0 by glx-diversions
diversion of /usr/lib/i386-linux-gnu/libGLESv2.so.2.1.0 to 
/usr/lib/mesa-diverted/i386-linux-gnu/libGLESv2.so.2.1.0 by glx-diversions
diversion of /usr/lib/x86_64-linux-gnu/libGLESv2.so.2 to 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv2.so.2 by glx-diversions
diversion of /usr/lib/arm-linux-gnueabihf/libGL.so.1.2 to 
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGL.so.1.2 by glx-diversions
diversion of /usr/lib/x86_64-linux-gnu/libGLESv2.so.2.1.0 to 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv2.so.2.1.0 by glx-diversions
diversion of /usr/lib/libGLESv1_CM.so.1.1.0 to 
/usr/lib/mesa-diverted/libGLESv1_CM.so.1.1.0 by glx-diversions
diversion of /usr/lib/i386-linux-gnu/libGLESv1_CM.so.1 to 
/usr/lib/mesa-diverted/i386-linux-gnu/libGLESv1_CM.so.1 by glx-diversions
diversion of /usr/lib/x86_64-linux-gnu/libGLESv1_CM.so to 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv1_CM.so by glx-diversions
diversion of /usr/lib/arm-linux-gnueabihf/libGLESv1_CM.so.1.2.0 to 
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv1_CM.so.1.2.0 by 
glx-diversions
diversion of /usr/lib/arm-linux-gnueabihf/libGLESv1_CM.so.1.1.0 to 
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv1_CM.so.1.1.0 by 
glx-diversions
diversion of /usr/lib/libGL.so.1.2.0 to /usr/lib/mesa-diverted/libGL.so.1.2.0 
by glx-diversions
diversion of /usr/lib/libGLESv1_CM.so.1.2.0 to 
/usr/lib/mesa-diverted/libGLESv1_CM.so.1.2.0 by glx-diversions
diversion of /usr/lib/libGLESv2.so to /usr/lib/mesa-diverted/libGLESv2.so by 
glx-diversions
diversion of /usr/lib/libGL.so.1.2 to /usr/lib/mesa-diverted/libGL.so.1.2 by 
glx-diversions
diversion of /usr/lib/i386-linux-gnu/libGLESv1_CM.so.1.1.0 to 
/usr/lib/mesa-diverted/i386-linux-gnu/libGLESv1_CM.so.1.1.0 by glx-diversions
diversion of /usr/lib/x86_64-linux-gnu/libGL.so.1.2.0 to 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so.1.2.0 by glx-diversions
diversion of /usr/lib/arm-linux-gnueabihf/libGLESv2.so to 
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv2.so by glx-diversions
diversion of /usr/lib/libGL.so to /usr/lib/mesa-diverted/libGL.so by 
glx-diversions
diversion of /usr/lib/arm-linux-gnueabihf/libGLESv2.so.2 to 
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv2.so.2 by glx-diversions
diversion of /usr/lib/i386-linux-gnu/libGL.so.1.7.0 to 
/usr/lib/mesa-diverted/i386-linux-gnu/libGL.so.1.7.0 by glx-diversions
diversion of /usr/lib/i386-linux-gnu/libGL.so.1.0.0 to 
/usr/lib/mesa-diverted/i386-linux-gnu/libGL.so.1.0.0 by glx-diversions
diversion of /usr/lib/x86_64-linux-gnu/libGL.so.1.2 to 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so.1.2 by glx-diversions
diversion of /usr/lib/i386-linux-gnu/libGLESv2.so to 
/usr/lib/mesa-diverted/i386-linux-gnu/libGLESv2.so by glx-diversions
diversion of /usr/lib/libGLESv1_CM.so to /usr/lib/mesa-diverted/libGLESv1_CM.so 
by glx-diversions
diversion of /usr/lib/i386-linux-gnu/libGL.so.1.2.0 to 
/usr/lib/mesa-diverted/i386-linux-gnu/libGL.so.1.2.0 by glx-diversions
diversion of 

Bug#888047: mesa: FTBFS on hurd-i386

[Samuel Thibault]

Source: mesa
Version: 17.3.3-1
Severity: important
Tags: patch

Hello,

mesa currently FTBFS on hurd-i386 for a few upstream and downstream
reasons. The attached patches pthread_setname_np and GetDriverConfig are
cherry-picks from upstream. The attached patch "patch" is for the Debian
changes: the libva dependency is avoided on hurd-any, but --with libva
was still pased, thus failing. Also, surfaceless requires libdrm, which
is not available.

Samuel

-- System Information:
Debian Release: buster/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unreleased'), (500, 
'buildd-unstable'), (500, 'unstable'), (500, 'stable'), (1, 
'experimental-debug'), (1, 'buildd-experimental'), (1, 'experimental')
Architecture: hurd-i386 (i686-AT386)

Kernel: GNU-Mach 1.8+git20171101-486-dbg/Hurd-0.9
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
commit 9131e6d3c2dcc30260e23f2232b44c8cffc6f315
Author: Samuel Thibault <samuel.thiba...@ens-lyon.org>
Date:   Sat Jan 13 12:33:15 2018 +0100

u_thread: Use pthread_setname_np on linux only.

pthread_setname_np was added in glibc 2.12 for the Linux port only, other
ports do not necessarily have it.

Signed-off-by: Jose Fonseca <jfons...@vmware.com>

diff --git a/src/util/u_thread.h b/src/util/u_thread.h
index 26cc0b0934..8c6e0bdc59 100644
--- a/src/util/u_thread.h
+++ b/src/util/u_thread.h
@@ -62,7 +62,8 @@ static inline void u_thread_setname( const char *name )
 {
 #if defined(HAVE_PTHREAD)
 #  if defined(__GNU_LIBRARY__) && defined(__GLIBC__) && 
defined(__GLIBC_MINOR__) && \
-  (__GLIBC__ >= 3 || (__GLIBC__ == 2 && __GLIBC_MINOR__ >= 12))
+  (__GLIBC__ >= 3 || (__GLIBC__ == 2 && __GLIBC_MINOR__ >= 12)) && \
+  defined(__linux__)
pthread_setname_np(pthread_self(), name);
 #  endif
 #endif
commit 47ac11bcf8bd9e4525e0fb4308d0bca87a8900c6
Author: Samuel Thibault <samuel.thiba...@ens-lyon.org>
Date:   Mon Jan 15 15:38:25 2018 +0100

glx: fix non-dri build

glXGetDriverConfig parameters do not provide a context to dynamically
check for the presence of the function, so the dispatcher directly calls
glXGetDriverConfig, but in non-dri builds dri_glx.c didn't provide
glXGetDriverConfig.

This change make it just return NULL in that case.

Fixes: 84f764a7591 "glxglvnddispatch: Add missing dispatch for 
GetDriverConfig
Reviewed-by: Nicolai Hähnle <nicolai.haeh...@amd.com>
Reviewed-by: Hans de Goede <hdego...@redhat.com>
Reviewed-by: Emil Velikov <emil.veli...@collabora.com>

diff --git a/src/glx/g_glxglvnddispatchfuncs.c 
b/src/glx/g_glxglvnddispatchfuncs.c
index 56d894eda7..5b65afc860 100644
--- a/src/glx/g_glxglvnddispatchfuncs.c
+++ b/src/glx/g_glxglvnddispatchfuncs.c
@@ -338,11 +338,15 @@ static Display *dispatch_GetCurrentDisplayEXT(void)
 
 static const char *dispatch_GetDriverConfig(const char *driverName)
 {
+#if defined(GLX_DIRECT_RENDERING) && !defined(GLX_USE_APPLEGL)
 /*
  * The options are constant for a given driverName, so we do not need
  * a context (and apps expect to be able to call this without one).
  */
 return glXGetDriverConfig(driverName);
+#else
+return NULL;
+#endif
 }
 
 
diff -ur mesa-17.3.1.orig/debian/rules mesa-17.3.1/debian/rules
--- mesa-17.3.1.orig/debian/rules   2018-01-13 09:10:32.0 +
+++ mesa-17.3.1/debian/rules2018-01-13 09:52:21.0 +
@@ -26,16 +26,20 @@
 DRI_DRIVERS =
 GALLIUM_DRIVERS =
 VULKAN_DRIVERS =
-EGL_PLATFORMS = x11,surfaceless
 
 confflags_DRI3 = --disable-dri3
 
 # hurd doesn't do direct rendering
 ifeq ($(DEB_HOST_ARCH_OS), hurd)
+   EGL_PLATFORMS = x11
+
confflags_DIRECT_RENDERING = --disable-driglx-direct
confflags_GBM = --disable-gbm
DRI_DRIVERS = swrast
+   with_libva = 
 else
+   EGL_PLATFORMS = x11,surfaceless
+
   ifeq ($(DEB_HOST_ARCH_OS), linux)
confflags_DRI3 = --enable-dri3
# Gallium drivers which require kernel support, not yet ported to 
non-Linux
@@ -108,6 +112,7 @@
confflags_GALLIUM += --enable-va
confflags_GALLIUM += --enable-gallium-extra-hud
confflags_GALLIUM += --enable-lmsensors
+   with_libva = ,libva
 endif
 
 # Disable assembly usage on x32 otherwise Mesa defaults to x86_64 assembly
@@ -227,7 +232,7 @@
dh_makeshlibs -a -- -c4
 
 %:
-   dh $@ --with quilt,autoreconf,libva \
+   dh $@ --with quilt,autoreconf$(with_libva) \
--parallel \
--builddirectory=build/
 

Bug#870445: libglvnd: FTBFS on non-Linux: u_execmem_free undefined

[Samuel Thibault]

Control: tags -1 forwarded https://github.com/NVIDIA/libglvnd/pull/142

Julien Cristau, on sam. 13 janv. 2018 13:34:32 +0100, wrote:
> On Sat, Jan 13, 2018 at 10:35:48 +0100, Samuel Thibault wrote:
> > Andreas Beckmann, on sam. 25 nov. 2017 16:41:41 +0100, wrote:
> > > attached are two patches to fix this FTBFS.
> > > Build-tested on falla and exodar.
> > 
> > I have uploaded the attached debdiff to DELAYED/5.
> > 
> Was the patch ever sent upstream?

The patch was apparently commited to the Debian repository without an
upstream submission.  I have pushed it as a pull request.

Samuel

Bug#870445: libglvnd: FTBFS on non-Linux: u_execmem_free undefined

[Samuel Thibault]

Hello,

Andreas Beckmann, on sam. 25 nov. 2017 16:41:41 +0100, wrote:
> attached are two patches to fix this FTBFS.
> Build-tested on falla and exodar.

I have uploaded the attached debdiff to DELAYED/5.

Thanks,
Samuel
diff -Nru libglvnd-1.0.0/debian/changelog libglvnd-1.0.0/debian/changelog
--- libglvnd-1.0.0/debian/changelog 2018-01-13 09:24:37.0 +
+++ libglvnd-1.0.0/debian/changelog 2018-01-13 09:16:09.0 +
@@ -1,3 +1,15 @@
+libglvnd (1.0.0-1.1) unstable; urgency=medium
+
+  [ Samuel Thibault ]
+  * Non-maintainer upload.
+
+  [ Andreas Beckmann ]
+  * Use source format 3.0 (quilt).
+  * kfreebsd-hurd.patch: New, fix FTBFS on kFreeBSD and Hurd.
+(Closes: #870445)
+
+ -- Samuel Thibault <sthiba...@debian.org>  Sat, 13 Jan 2018 09:16:09 +
+
 libglvnd (1.0.0-1) unstable; urgency=high
 
   [ Andreas Boll ]
diff -Nru libglvnd-1.0.0/debian/patches/kfreebsd-hurd.patch 
libglvnd-1.0.0/debian/patches/kfreebsd-hurd.patch
--- libglvnd-1.0.0/debian/patches/kfreebsd-hurd.patch   1970-01-01 
00:00:00.0 +
+++ libglvnd-1.0.0/debian/patches/kfreebsd-hurd.patch   2018-01-13 
09:16:09.0 +
@@ -0,0 +1,14 @@
+Author: Andreas Beckmann <a...@debian.org>
+Description: fix FTBFS on kFreeBSD and Hurd
+
+--- a/src/GLdispatch/vnd-glapi/u_execmem.c
 b/src/GLdispatch/vnd-glapi/u_execmem.c
+@@ -68,7 +68,7 @@ static unsigned char *exec_mem = NULL;
+ static unsigned char *write_mem = NULL;
+ 
+ 
+-#if defined(__linux__) || defined(__OpenBSD__) || defined(_NetBSD__) || 
defined(__sun) || defined(__HAIKU__)
++#if defined(__linux__) || defined(__OpenBSD__) || defined(_NetBSD__) || 
defined(__sun) || defined(__HAIKU__) || defined(__FreeBSD_kernel__) || 
defined(__GNU__)
+ 
+ #include 
+ #include 
diff -Nru libglvnd-1.0.0/debian/patches/series 
libglvnd-1.0.0/debian/patches/series
--- libglvnd-1.0.0/debian/patches/series1970-01-01 00:00:00.0 
+
+++ libglvnd-1.0.0/debian/patches/series2018-01-13 09:16:09.0 
+
@@ -0,0 +1 @@
+kfreebsd-hurd.patch
diff -Nru libglvnd-1.0.0/debian/source/format 
libglvnd-1.0.0/debian/source/format
--- libglvnd-1.0.0/debian/source/format 2018-01-13 09:24:37.0 +
+++ libglvnd-1.0.0/debian/source/format 2018-01-13 09:16:09.0 +
@@ -1 +1 @@
-1.0
+3.0 (quilt)

Bug#887046: libxext: Please make w3m Build-Depends-Indep

[Samuel Thibault]

Source: libxext
Version: 2:1.3.3-1
Severity: normal

Hello,

w3m ends up depending on mesa, which ends up depending on libxext,
which build-depends on w3m. This is thus making a loop in architecture
bootstrap. Could you move the w3m Build-Dep to Build-Depends-Indep to
avoid this loop? Other depends could be moved there such as xsltproc
etc.

Thanks,
Samuel

-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 
'testing-debug'), (500, 'stable-debug'), (500, 'oldoldstable'), (500, 
'buildd-unstable'), (500, 'unstable'), (500, 'stable'), (500, 'oldstable'), (1, 
'experimental-debug'), (1, 'buildd-experimental'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.14.0-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

-- 
Samuel
 T'as pas de portable ?
 J'ai un nokia, dans le bassin d'arcachon

Bug#825146: libxdmcp-dev: Multi-Arch: same file conflict between rebuilds of the package

[Samuel Thibault]

Helmut Grohne, on mar. 24 mai 2016 07:06:32 +0200, wrote:
> Options for handling this seem dim at this point. We binNMU on all
> architectures and carry on. Or we could split out a tiny libxdmcp-doc
> package. Neither of these options seems particularly attractive.

We happen to face a related issue for the ia64 bootstrap: libxdmcp
depends on w3m which depends on libx11 which depends on libxcb which
depends on libxdmcp :)

Moving the documentation to an arch:all package would solve both issues
:)

Samuel

Bug#829386: xorg: Xorg crashes

[Samuel Thibault]

Control: tags -1 + patch fixed-upstream

Hello,

I have attached the upstream fix for this issue, to be applied to the
xserver-xorg-input-libinput package. Could Jean-Philippe, Sebastien and
Sebastian test it so that we can apply it to Debian before Stretch?

Thanks,
Samuel
commit f47f78eb0bd9fba455f01c8c6dead3bd75242b2b
Author: Peter Hutterer 
Date:   Tue Dec 20 15:36:55 2016 +1000

Ignore LED updates for disabled devices

If an XKB AccessX timeout is set and a VT switch is triggered, the
AccessXTimeoutExpire function may be called after the device has already 
been
disabled. This can cause a null-pointer dereference as our shared libinput
device may have been released by then.

In the legacy drivers this would've simply caused a write to an invalid fd
(-1), not a crash. Here we need to be more careful.

https://bugs.freedesktop.org/show_bug.cgi?id=98464

Signed-off-by: Peter Hutterer 
Reviewed-by: Hans de Goede 

diff --git a/src/xf86libinput.c b/src/xf86libinput.c
index b130a77..fd38c3b 100644
--- a/src/xf86libinput.c
+++ b/src/xf86libinput.c
@@ -785,6 +785,9 @@ xf86libinput_kbd_ctrl(DeviceIntPtr device, KeybdCtrl *ctrl)
 struct xf86libinput *driver_data = pInfo->private;
 struct libinput_device *ldevice = driver_data->shared_device->device;
 
+if (!device->enabled)
+   return;
+
 while (bits[i].xbit) {
if (ctrl->leds & bits[i].xbit)
leds |= bits[i].code;

Bug#838703: libinput10: leads to a crash of X when working in a virtual tty

[Samuel Thibault]

Control: tags -1 + fixed-upstream

Hello,

Could this be backported to Debian for Stretch?

commit f47f78eb0bd9fba455f01c8c6dead3bd75242b2b
Author: Peter Hutterer 
Date:   Tue Dec 20 15:36:55 2016 +1000
  
Ignore LED updates for disabled devices

Thanks,
Samuel

Bug#838703: libinput10: leads to a crash of X when working in a virtual tty

[Samuel Thibault]

Sebastian Humenda, on Wed 14 Dec 2016 11:05:04 +0100, wrote:
> >If that doesn't help, please send a backtrace with debugging symbols to the
> >upstream bug.
> I'd say the issues are unrelated, I have a null pointer in a LED update
> function, the upstream bug fixes something else.

The upstream bug is about a null pointer in a LED update too.

Samuel

Bug#838703: libinput10: leads to a crash of X when working in a virtual tty

[Samuel Thibault]

Control: forwarded -1 https://bugs.freedesktop.org/show_bug.cgi?id=98464

Hello,

This is very likely the same bug as
https://bugs.freedesktop.org/show_bug.cgi?id=98464 which has a proposed
patch, could you check try?

Samuel

Bug#845398: x11-common: Can't configure

[Samuel Thibault]

Package: x11-common
Version: 1:7.7+17
Severity: grave
Justification: renders package unusable

Hello,

x11-common can't be installed any more now that x11-common.postinst has
set -e:

Setting up x11-common (1:7.7+17) ...
dpkg: error processing package x11-common (--configure):
 subprocess installed post-installation script returned error exit status 20
Errors were encountered while processing:
 x11-common
E: Sub-process /usr/bin/dpkg returned an error code (1)

This is because postinst calls

db_purge x11-common/xwrapper/allowed_users
db_purge x11-common/xwrapper/actual_allowed_users

According to debconf-devel(7), the PURGE command doesn't take any
parameter, it is not meant to remove just one entry.

I guess what was meant was rather

db_unregister x11-common/xwrapper/allowed_users
db_unregister x11-common/xwrapper/actual_allowed_users

to remove those old entries.

Samuel

-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 
'testing-debug'), (500, 'buildd-unstable'), (500, 'unstable'), (500, 'stable'), 
(500, 'oldstable'), (1, 'experimental-debug'), (1, 'buildd-experimental'), (1, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.8.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages x11-common depends on:
ii  lsb-base  9.20161101

x11-common recommends no packages.

x11-common suggests no packages.

-- debconf information:
  x11-common/xwrapper/actual_allowed_users: anybody
* x11-common/xwrapper/allowed_users: Anybody

-- 
Samuel
 je viens d'inventer mutt version magritte :D
 ?
 dans mutt
 tape "cceci" return

Bug#843588: mesa: FTBFS on hurd-i386 due to PATH_MAX

[Samuel Thibault]

Source: mesa
Version: 13.0.0-1
Severity: important
Tags: upstream patch
User: debian-h...@lists.debian.org
Usertags: hurd
Control: forwarded https://bugs.freedesktop.org/show_bug.cgi?id=98632

Hello,

Just for information and upstream tracking, probably to be turned into
cherry-pick request when fixed upstream.

Thanks,
Samuel

-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 
'testing-debug'), (500, 'buildd-unstable'), (500, 'unstable'), (500, 'stable'), 
(500, 'oldstable'), (1, 'experimental-debug'), (1, 'buildd-experimental'), (1, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.8.0 (SMP w/4 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

-- 
Samuel
 > Il [e2fsck] a bien démarré, mais il m'a rendu la main aussitot en me
 > disant "houlala, c'est pas beau à voir votre truc, je préfèrerai que
 > vous teniez vous même la tronçonneuse" (traduction libre)
 NC in Guide du linuxien pervers : "Bien configurer sa tronçonneuse."

Bug#841774: mesa: Please make libgbm1 dependency !hurd-any

[Samuel Thibault]

Source: mesa
Version: 12.0.3-2
Severity: important
Tags: patch

Hello,

libegl1-mesa has become uninstallable on hurd-any because it now depends
on libgbm1 even on hurd-any, where that package doesn't exist. The
attached patch should fix the issue.

Samuel

-- System Information:
Debian Release: stretch/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500, 
'buildd-unstable'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (500, 
'oldstable'), (1, 'experimental-debug'), (1, 'buildd-experimental'), (1, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.8.0 (SMP w/4 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
--- debian/control.original 2016-10-23 14:07:55.972688302 +0200
+++ debian/control  2016-10-23 14:07:57.212682105 +0200
@@ -120,7 +120,7 @@
 Depends:
  ${shlibs:Depends},
  ${misc:Depends},
- libgbm1 (= ${binary:Version}),
+ libgbm1 (= ${binary:Version}) [!hurd-any],
  libudev1 [linux-any],
 Provides: libegl1-x11
 Conflicts: libegl1-x11

Bug#838136: libxkbcommon: FTBFS on hurd-i386

[Samuel Thibault]

Source: libxkbcommon
Version: 0.6.1-1
Severity: important
Tags: patch
User: debian-h...@lists.debian.org
Usertags: hurd

Hello,

libxkbcommon currently FTBFS on hurd-i386 because it uses uint64_t
without including stdint.h, please see attached patch.

Thanks,
Samuel

-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 
'buildd-unstable'), (500, 'unstable'), (500, 'stable'), (500, 'oldstable'), (1, 
'experimental-debug'), (1, 'buildd-experimental'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.7.0 (SMP w/4 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

-- 
Samuel
Actually, typing random strings in the Finder does the equivalent of
filename completion.
(Discussion in comp.os.linux.misc on the intuitiveness of commands: file
completion vs. the Mac Finder.)
--- ./bench/bench.c.original2016-09-17 15:41:32.0 +
+++ ./bench/bench.c 2016-09-17 15:41:37.0 +
@@ -35,6 +35,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 
--- ./bench/bench.h.original2016-09-17 15:49:30.0 +
+++ ./bench/bench.h 2016-09-17 15:49:34.0 +
@@ -25,6 +25,8 @@
 #ifndef LIBXKBCOMMON_BENCH_H
 #define LIBXKBCOMMON_BENCH_H
 
+#include 
+
 struct bench_time {
 long seconds;
 long milliseconds;

Bug#822179: xorg: X.Org X Server starts normally, crashes with Segmentation fault on starting any application

[Samuel Thibault]

James Clarke, on Sat 23 Apr 2016 15:08:13 +0100, wrote:
> > On 23 Apr 2016, at 15:06, Samuel Thibault <sthiba...@debian.org> wrote:
> > 
> > James Clarke, on Sat 23 Apr 2016 15:03:29 +0100, wrote:
> >>> AIUI, nothing uses XFD_SETSIZE actually, it's just the default value
> >>> that X uses for FD_SETSIZE in case it's not already defined.
> >> 
> >> No, in e.g. os/WaitFor.c in xorg-server, there are for loops using
> >> howmany(XFD_SETSIZE, NFDBITS) to iterate over each element,
> > 
> > Ergl, ok, so XFD_SETSIZE also needs to be fixed.
> 
> This *is* changing XFD_SETSIZE...

Sure, I was just agreeing with you.

Samuel

Bug#822179: xorg: X.Org X Server starts normally, crashes with Segmentation fault on starting any application

[Samuel Thibault]

James Clarke, on Sat 23 Apr 2016 15:03:29 +0100, wrote:
> > AIUI, nothing uses XFD_SETSIZE actually, it's just the default value
> > that X uses for FD_SETSIZE in case it's not already defined.
> 
> No, in e.g. os/WaitFor.c in xorg-server, there are for loops using
> howmany(XFD_SETSIZE, NFDBITS) to iterate over each element,

Ergl, ok, so XFD_SETSIZE also needs to be fixed.

> These lines are fine; the indexing is guarded by the howmany check, and uses
> the real FD_SETSIZE.

Ah, right.  Overlooked the whole thing too fast.

Sorry for the noise,
Samuel

Bug#822179: xorg: X.Org X Server starts normally, crashes with Segmentation fault on starting any application

[Samuel Thibault]

Hello,

James Clarke, on Sat 23 Apr 2016 14:44:52 +0100, wrote:
> I have attached a proposed patch which ensures XFD_SETSIZE never
> exceeds FD_SETSIZE.

Did you test it?

AIUI, nothing uses XFD_SETSIZE actually, it's just the default value
that X uses for FD_SETSIZE in case it's not already defined. I.e. your
change doesn't actually change anything: if FD_SETSIZE is define on
poll.h inclusion, it'll be used, not 512.  What probably actually breaks
is the

(howmany(FD_SETSIZE, NFDBITS) > 8 && (__XFDS_BITS(p, 8))) ||

lines when FD_SETSIZE is not big enough.  Probably these can be made
conditioned by the value of FD_SETSIZE, something like:

#if FD_SETSIZE >= 512
#define XFD_ANYSET_512(p) \
   ((howmany(FD_SETSIZE, NFDBITS) > 8 && (__XFDS_BITS(p, 8))) || \
(howmany(FD_SETSIZE, NFDBITS) > 9 && (__XFDS_BITS(p, 9))) || \
(howmany(FD_SETSIZE, NFDBITS) > 10 && (__XFDS_BITS(p, 10))) || \
(howmany(FD_SETSIZE, NFDBITS) > 11 && (__XFDS_BITS(p, 11))) || \
(howmany(FD_SETSIZE, NFDBITS) > 12 && (__XFDS_BITS(p, 12))) || \
(howmany(FD_SETSIZE, NFDBITS) > 13 && (__XFDS_BITS(p, 13))) || \
(howmany(FD_SETSIZE, NFDBITS) > 14 && (__XFDS_BITS(p, 14))) || \
(howmany(FD_SETSIZE, NFDBITS) > 15 && (__XFDS_BITS(p, 15
#else
#define XFD_ANYSET_512(p) 0
#endif

#define XFD_ANYSET(p) \
   ((howmany(FD_SETSIZE, NFDBITS) > 0 && (__XFDS_BITS(p, 0))) || \
(howmany(FD_SETSIZE, NFDBITS) > 1 && (__XFDS_BITS(p, 1))) || \
(howmany(FD_SETSIZE, NFDBITS) > 2 && (__XFDS_BITS(p, 2))) || \
(howmany(FD_SETSIZE, NFDBITS) > 3 && (__XFDS_BITS(p, 3))) || \
(howmany(FD_SETSIZE, NFDBITS) > 4 && (__XFDS_BITS(p, 4))) || \
(howmany(FD_SETSIZE, NFDBITS) > 5 && (__XFDS_BITS(p, 5))) || \
(howmany(FD_SETSIZE, NFDBITS) > 6 && (__XFDS_BITS(p, 6))) || \
(howmany(FD_SETSIZE, NFDBITS) > 7 && (__XFDS_BITS(p, 7))) || \
XFD_ANYSET_512(p))

Samuel

Bug#798408: Bug#797816: openscad FTBFS in armhf due to conflict declaration of headers gl3.h and glew.h

[Samuel Thibault]

Hello,

I'm getting the same issue with the "vite" package now that I have
migrated it from qt4 to qt5:

https://buildd.debian.org/status/fetch.php?pkg=vite=armel=1.2%2Bsvn1430-5=1450824398

In file included from /usr/include/arm-linux-gnueabi/qt5/QtGui/qopengl.h:97:0,
 from /usr/include/arm-linux-gnueabi/qt5/QtOpenGL/qgl.h:39,
 from /usr/include/arm-linux-gnueabi/qt5/QtOpenGL/QGLWidget:1,
 from 
/«BUILDDIR»/vite-1.2+svn1430/src/render/Render_opengl.hpp:56,
 from 
/«BUILDDIR»/vite-1.2+svn1430/src/render/Render_opengl.cpp:67:
/usr/include/GLES3/gl3.h:69:25: error: conflicting declaration 'typedef
khronos_ssize_t GLsizeiptr'
 typedef khronos_ssize_t GLsizeiptr;

In file included from /usr/include/GL/gl.h:2055:0,
 from /usr/include/GL/glu.h:38,
 from 
/«BUILDDIR»/vite-1.2+svn1430/src/render/Render_opengl.cpp:52:
/usr/include/GL/glext.h:468:19: note: previous declaration as 'typedef 
ptrdiff_t GLsizeiptr'
 typedef ptrdiff_t GLsizeiptr;

vite just happens to be using both QGLWidget and GL.

Samuel

Bug#794644: xorg-server: FTBFS on hurd-i386

[Samuel Thibault]

Samuel Thibault, le Tue 11 Aug 2015 10:48:53 +0200, a écrit :
 As agreed with Julien, I'll NMU the attached patch (which is current git
 fix)

Grmbl, here is really the patch.

Samuel
diff -u xorg-server-1.17.2/debian/changelog xorg-server-1.17.2/debian/changelog
--- xorg-server-1.17.2/debian/changelog
+++ xorg-server-1.17.2/debian/changelog
@@ -1,3 +1,13 @@
+xorg-server (2:1.17.2-1.1) unstable; urgency=medium
+
+  * Non-Maintainer Upload.
+
+  [ Sven Joachim ]
+  * Install the whole usr/share/man/man4 directory into xserver-xorg-core,
+fixes FTBFS on hurd where modesetting.4 does not exist (Closes: #794644).
+
+ -- Samuel Thibault sthiba...@debian.org  Tue, 11 Aug 2015 10:45:35 +0200
+
 xorg-server (2:1.17.2-1) unstable; urgency=medium
 
   [ Sven Joachim ]
diff -u xorg-server-1.17.2/debian/xserver-xorg-core.install 
xorg-server-1.17.2/debian/xserver-xorg-core.install
--- xorg-server-1.17.2/debian/xserver-xorg-core.install
+++ xorg-server-1.17.2/debian/xserver-xorg-core.install
@@ -3,11 +3,9 @@
 main/usr/share/man/man1/Xorg.1 usr/share/man/man1
-main/usr/share/man/man4/exa.4  usr/share/man/man4
-main/usr/share/man/man4/fbdevhw.4  usr/share/man/man4
+main/usr/share/man/man4usr/share/man/
 main/usr/share/man/man5/xorg.conf.5usr/share/man/man5
 main/usr/share/man/man5/xorg.conf.d.5  usr/share/man/man5
 main/usr/bin/cvt   usr/bin
 main/usr/bin/gtf   usr/bin
 main/usr/share/man/man1/cvt.1  usr/share/man/man1
 main/usr/share/man/man1/gtf.1  usr/share/man/man1
-main/usr/share/man/man4/modesetting.4  usr/share/man/man4
 main/usr/share/X11/xorg.conf.d usr/share/X11/

Bug#794644: xorg-server: FTBFS on hurd-i386

[Samuel Thibault]

As agreed with Julien, I'll NMU the attached patch (which is current git
fix)

Samuel


-- 
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150811084853.ga20...@type.bordeaux.inria.fr

Bug#794644: xorg-server: FTBFS on hurd-i386

[Samuel Thibault]

Svante Signell, le Wed 05 Aug 2015 12:12:58 +0200, a écrit :
 Source: xorg-server
 Version: 1.17.2-1
 Severity: important

As additional information, it's particularly important because the
version currently available on hurd-i386 (2:1.17.1-2) misses the fix
0a78b599b34cc8b5fe6fe82f90e90234e8ab7a56, thus breaking the vesa driver.

Samuel


-- 
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150809182420.ga21...@type.home

Bug#793543: xserver-xorg segmentation fault at startup on testing

[Samuel Thibault]

Hello,

Matthias, could you send the output of

lspci -vv

Thanks,
Samuel


-- 
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150809191250.ga29...@type.home

Bug#793543: xserver-xorg segmentation fault at startup on testing

[Samuel Thibault]

Control: reassign -1 libc0.3

Samuel Thibault, le Sun 09 Aug 2015 21:12:50 +0200, a écrit :
 Matthias, could you send the output of
 
 lspci -vv

My guess is that the BAR is around something like 0xfe00, and it
seems the latest version of libpciaccess uses mmap64, which detects
that this can't hold in an off_t (which is signed) and thus returns
EOVERFLOW.  It happens that the RPC interface is actually using
vm_offset_t (which is unsigned) so it should actually work.  I'll patch
this in libc0.3, thus reassigning.

Samuel


-- 
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150809195531.gp10...@type.home

Re: Bug#769796: systemd: update-rc.d lightdm disable does not work

[Samuel Thibault]

Martin Pitt, le Mon 17 Nov 2014 07:39:20 +0100, a écrit :
 Samuel Thibault [2014-11-16 23:55 +0100]:
  I have run
  
  systemctl disable display-manager
  
  and now lightdm doesn't start any more.
 
 Indeed I'm afraid this is a wontfix. lightdm, gdm, and friends can't
 directly enable/disable their units as this doesn't semantically make
 sense together with /etc/X11/default-display-manager.  With the
 decision/requirement to make multiple display managers installable in
 parallel and selecting them via debconf (none of this is new in
 systemd or related to systemd, BTW) you can't really disable gdm or
 lightdm, you can only disable the display manager.
 
 So I'm closing this. If you disagree and want to keep this open, this
 should be reassigned to lightdm and tagged wontfix.

Well, this used to be working before switching to systemd, and
it's really not obvious to the user that he now has to disable
display-manager too (and that can't be done through update-rc.d).

Perhaps it would be feasible to at least make all the update-rc.d
{xdm,gdm3,lightdm,etc.} emit a warning that this doesn't work when using
systemd, and systemctl disable display-manager should be used instead?
Otherwise I'm afraid we'll again get angry users.

Samuel


-- 
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20141117085526.gn3...@type.youpi.perso.aquilenet.fr

Bug#731441: Templates in xutils-dev cause build-depends on libxp-dev

[Samuel Thibault]

Ping?

Graham Inggs, le Thu 05 Dec 2013 15:36:03 +0200, a écrit :
 The xprint package has been removed from Debian.A related library is
 libxp, which provides an API that enables client programs to access and use
 an Xprint server.  Since we've gotten rid of xprint, one could argue it
 makes sense to get rid of libxp as well. Please see bug #657253 [1].
 
 There are templates in the xutils-dev package which cause other packages to
 build-depends on libxp-dev.
 For example, the template xorg-cf-files/Motif.tmpl contains the following
 lines:
 
 #ifndef XmClientLibs
 # define XmClientLibs $(XMLIB) $(XTOOLLIB) $(XPLIB) $(XLIB) $(XMEXTRA_LIBS)
 #endif
 
 ...which cause '-lXp' to appear in the LDLIBS of package xtel. Please see
 bug #707623 [2].

Samuel


-- 
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20140824213633.ga32...@type.youpi.perso.aquilenet.fr

Bug#672546: [PATCH] openchrome: Do not require libdrm

[Samuel Thibault]

We can build without it.

Proper non-fatal finer libdrm detection is already done below this.

Signed-off-by: Samuel Thibault samuel.thiba...@ens-lyon.org

diff --git a/configure.ac b/configure.ac
index b13cb2c..9e77dc8 100644
--- a/configure.ac
+++ b/configure.ac
@@ -80,7 +80,7 @@ XORG_DRIVER_CHECK_EXT(XF86DRI, xextproto x11)
 XORG_DRIVER_CHECK_EXT(DPMSExtension, xextproto)
 
 # Checks for pkg-config packages
-PKG_CHECK_MODULES(XORG, [xorg-server xproto fontsproto libdrm glproto 
$REQUIRED_MODULES])
+PKG_CHECK_MODULES(XORG, [xorg-server xproto fontsproto glproto 
$REQUIRED_MODULES])
 PKG_CHECK_MODULES(XEXT, [xextproto = 7.0.99.1],
  HAVE_XEXTPROTO_71=yes; AC_DEFINE(HAVE_XEXTPROTO_71, 1, [xextproto 7.1 
available]),
  HAVE_XEXTPROTO_71=no)


-- 
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20140513001559.ga17...@type.youpi.perso.aquilenet.fr

Bug#672546: xserver-xorg-video-openchrome: FTBFS on hurd-i386: unconditional libdrm requirement

[Samuel Thibault]

Gabriele Giacone, le Tue 06 May 2014 17:00:34 +0200, a écrit :
 Attached another version with needed #defines instead of including
 embedded drm header. Cleaner?

copy/pasting code is usually never cleaner than just including a header.

 Or do we want simply not to build it on hurd anymore?

If the inclusion just works, then it's good.

That being said, I checked in the changelog why the drm_fourcc.h header
exists at all.  It is there just for distributions which do not have it
yet, it's not meant as a replacement for the non-DRI case.

At any rate, such changes should very probably be discussed with
upstream directly.

Samuel


-- 
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140506151323.ga20...@type.bordeaux.inria.fr

Bug#672546: xserver-xorg-video-openchrome: FTBFS on hurd-i386: unconditional libdrm requirement

[Samuel Thibault]

Gabriele Giacone, le Tue 06 May 2014 17:34:06 +0200, a écrit :
 On Tue, May 6, 2014 at 5:13 PM, Samuel Thibault sthiba...@debian.org wrote:
  Gabriele Giacone, le Tue 06 May 2014 17:00:34 +0200, a écrit :
  Attached another version with needed #defines instead of including
  embedded drm header. Cleaner?
 
  copy/pasting code is usually never cleaner than just including a header.
 
  Or do we want simply not to build it on hurd anymore?
 
  If the inclusion just works, then it's good.
 
  That being said, I checked in the changelog why the drm_fourcc.h header
  exists at all.  It is there just for distributions which do not have it
  yet, it's not meant as a replacement for the non-DRI case.
 
  At any rate, such changes should very probably be discussed with
  upstream directly.
 
 I'll update upstream bug which could be ignored as it's been so far.

Make sure to also raise the question on the X development mailing lists.

 In the meantime, how about applying it

It's up to X maintainers to decide.

Samuel


-- 
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140506160317.gb20...@type.bordeaux.inria.fr

Bug#672546: xserver-xorg-video-openchrome: FTBFS on hurd-i386: unconditional libdrm requirement

[Samuel Thibault]

Gabriele Giacone, le Mon 05 May 2014 16:55:08 +0200, a écrit :
 +diff --git a/src/via_memmgr.c b/src/via_memmgr.c
 +index 5d4cc3f..e174771 100644
 +--- a/src/via_memmgr.c
  b/src/via_memmgr.c
 +@@ -74,6 +74,7 @@ drm_bo_alloc_surface(ScrnInfoPtr pScrn, unsigned int 
 width, unsigned int height,
 + struct buffer_object *obj = NULL;
 + int pitch;
 + 
 ++#ifdef HAVE_DRI
 + switch (format) {
 + case DRM_FORMAT_C8:
 + pitch = width;
 +@@ -93,6 +94,7 @@ drm_bo_alloc_surface(ScrnInfoPtr pScrn, unsigned int 
 width, unsigned int height,
 + pitch = width * 4;
 + break;
 + }
 ++#endif
 + 
 + pitch = ALIGN_TO(pitch, alignment);

Err, this can not work: pitch becomes completely undefined...

Samuel


-- 
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140505145753.GU18938@type

Bug#672546: xserver-xorg-video-openchrome: FTBFS on hurd-i386: unconditional libdrm requirement

[Samuel Thibault]

Gabriele Giacone, le Mon 05 May 2014 18:02:34 +0200, a écrit :
 On Mon, May 05, 2014 at 04:57:53PM +0200, Samuel Thibault wrote:
   + pitch = ALIGN_TO(pitch, alignment);
  
  Err, this can not work: pitch becomes completely undefined...
 
 Only said it would have built, not also worked ;)

Well, submitting a patch usually means one thinks that it will work, not
just build...

 - libdrm-dev ( 2.0),
 + libdrm-dev ( 2.0) [!hurd-any],

 +--- a/src/via_driver.c
  b/src/via_driver.c
 +@@ -49,6 +49,8 @@
 + 
 + #ifdef HAVE_DRI
 + #include dri.h
 ++#else
 ++#include drm_fourcc.h
 + #endif
 + 

I don't see how that can build: drm_fourcc.h is part of libdrm-dev...

Samuel


-- 
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140505161228.GZ18938@type

Bug#672546: xserver-xorg-video-openchrome: FTBFS on hurd-i386: unconditional libdrm requirement

[Samuel Thibault]

And again, see what I wrote: considering how drm seems to be stuffed
into its source code, I don't think we want to spend more time on the
openchrome driver; the dependency was already dropped from the xorg
package, we can just ask ftpmaster to drop the remaining previous
binaries.

Samuel


-- 
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140505161437.GA18938@type

Bug#672546: xserver-xorg-video-openchrome: FTBFS on hurd-i386: unconditional libdrm requirement

[Samuel Thibault]

Gabriele Giacone, le Mon 05 May 2014 23:50:40 +0200, a écrit :
 On Mon, May 5, 2014 at 6:12 PM, Samuel Thibault sthiba...@debian.org wrote:
  Gabriele Giacone, le Mon 05 May 2014 18:02:34 +0200, a écrit :
  On Mon, May 05, 2014 at 04:57:53PM +0200, Samuel Thibault wrote:
+ pitch = ALIGN_TO(pitch, alignment);
  
   Err, this can not work: pitch becomes completely undefined...
 
  Only said it would have built, not also worked ;)
 
  Well, submitting a patch usually means one thinks that it will work, not
  just build...
 
  - libdrm-dev ( 2.0),
  + libdrm-dev ( 2.0) [!hurd-any],
 
  +--- a/src/via_driver.c
   b/src/via_driver.c
  +@@ -49,6 +49,8 @@
  +
  + #ifdef HAVE_DRI
  + #include dri.h
  ++#else
  ++#include drm_fourcc.h
  + #endif
  +
 
  I don't see how that can build: drm_fourcc.h is part of libdrm-dev...
 
 Not this one:
 http://sources.debian.net/src/xserver-xorg-video-openchrome/1:0.3.3-1/src/drm_fourcc.h

Oh, sorry, I didn't notice that.

This indeed looks like something that would work.

Samuel


-- 
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20140505221309.gh6...@type.wlan.youpi.perso.aquilenet.fr

Bug#745173: xserver-xorg-video-sisusb: Please use arch:linux-any

[Samuel Thibault]

Source: xserver-xorg-video-sisusb
Version: 1:0.9.6-2
Severity: important

Hello,

This package seems Linux-specific, so it should use Architecture:
linux-any in the control file, so its build is not even tried on
non-Linux archs.

Samuel


-- 
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20140418164601.ga15...@type.youpi.perso.aquilenet.fr

Bug#672546: xserver-xorg-video-openchrome: FTBFS on hurd-i386: unconditional libdrm requirement

[Samuel Thibault]

Samuel Thibault, le Sun 30 Jun 2013 11:50:05 +0200, a écrit :
 Pino Toscano, le Sat 12 May 2012 00:18:41 +0200, a écrit :
  The problem is that libdrm is considered an hard requirement (by the
  buildsystem and the Debian packaging), while it is only if the DRI
  support is enabled (and indeed there seems to be only libdrm usage in
  the DRI-related code).
  
  Attached there are patches to fix this:
 
 I guess we could eventually make an NMU to fix this?

Well, in the meanwhile the source code has changed, and would need
to be fixed to be buildable without libdrm, see via_memmgr.c having
a lot of unconditional uses of DRM_*.  Perhaps we should rather give
up with porting openchrome without libdrm, and remove it from hurd's
video-all, as proposed in bug 706889?  I'll probably make a binNMU in
that direction sooner or later.

Samuel


-- 
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20140208210051.ga14...@type.youpi.perso.aquilenet.fr

Bug#735421: xkb-data: fr(oss) has broken right control

[Samuel Thibault]

Control: merge 733757 735421

Julien Cristau, le Sat 18 Jan 2014 20:07:55 +0100, a écrit :
  After upgrading to newer xkb-data, the right control key is not working
  any more at all.
 
 This is a dupe of 733757 afaict.

Indeed, I wonder how I missed it, I did look for ctrl in bug titles.

Samuel


-- 
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20140118192219.gr5...@type.youpi.perso.aquilenet.fr

Bug#735421: xkb-data: fr(oss) has broken right control

[Samuel Thibault]

Package: xkb-data
Version: 2.10.1-1
Severity: normal
Tags: patch upstream

Hello,

After upgrading to newer xkb-data, the right control key is not working
any more at all.  This happens with fr(oss) only, and is due to commit
518c769d in the git tree.  The whole story is on

https://bugs.freedesktop.org/show_bug.cgi?id=15804

but in short, to fix some obscure rightcontrol-space shortcut in a
couple applications, upstream applied a patch that makes right-control
a level5 key, instead of leaving it the standard control key. This has
thus broken all standard control-foo shortcuts for the right control
key.  This is not acceptable, could 518c769d be reverted in Debian until
they settle on a solution which doesn't break very standard behavior?

Samuel

-- System Information:
Debian Release: jessie/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (1, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.12.0 (SMP w/8 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

-- no debconf information

-- 
Samuel
 RR Ce que je cherche à démontrer, c'est qu'il est injuste de faire
 RR l'amalgame entre du bulk mail et du courrier non-solicité très ciblé
 un suppositoire non reclamé, meme tres bien ciblé, reste un suppositoire.
 -+-OS in : Guide du Neuneu d'Usenet - Plein le cul de la pub à neuneu -+-


-- 
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140115093655.ga12...@type.bordeaux.inria.fr

Bug#734764: /usr/share/X11/xkb/compat/default was missing

[Samuel Thibault]

Hello,

Control: reassign -1 hurd
Control: done -1 1:0.5.git20140113-1

Hello,

Cong Zhang, le Thu 09 Jan 2014 18:00:54 +, a écrit :
 After insall debian hurd from mini.iso in qemu with kvm enable, 
 when system boot, it show can't open file compat/default, and X can't start.
 
 I copy one /usr/share/X11/xkb/compat/default from debian wheezy, and then it 
 works.
 
 I view the upstream git, found the file was not there too.
 file was deleted by Sergey V. Udaltsov s...@gnome.org,
 
 I suggest make the file back. 

I'm afraid there is little chance that it comes back, since keymaps and
compat are depreciated.  I have however fixed the issue in the hurd
package itself.

Samuel


-- 
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20140114231129.gm6...@type.youpi.perso.aquilenet.fr

Bug#729260: mesa: Add egl/gles packages on hurd-any

[Samuel Thibault]

Package: mesa
Version: 9.2.2-1
Severity: important
Tags: patch upstream
User: debian-h...@lists.debian.org
Usertags: hurd

Hello,

Some Debian packages now depend on egl/gles packages, which are not
available on hurd-any. Instead of disabling the dependencies there, we
can actually build them on hurd-any without libdrm support.  I have
attached the patch that I have already submitted upstream, and the
debian/ patch that enables the packages.

Samuel

-- System Information:
Debian Release: jessie/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (1, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.12.0 (SMP w/8 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

-- 
Samuel
requests./FONT/SPAN/TD/TR/TBODY/TABLE/DIV/BODY/HTMLagnjo
gj a po  mi
shnthdrdcvallus hsx mvgduwolgfwtq
uzuy
s
p
h
 -+- spams forever ... -+- 
--- src/egl/drivers/dri2/egl_dri2.c.original2013-11-10 15:27:19.0 
+0100
+++ src/egl/drivers/dri2/egl_dri2.c 2013-11-10 15:28:25.0 +0100
@@ -33,8 +33,10 @@
 #include fcntl.h
 #include errno.h
 #include unistd.h
+#ifdef HAVE_DRM_PLATFORM
 #include xf86drm.h
 #include drm_fourcc.h
+#endif
 #include GL/gl.h
 #include GL/internal/dri_interface.h
 #include sys/types.h
@@ -1125,6 +1127,7 @@
return dri2_create_image(disp, dri_image);
 }
 
+#ifdef HAVE_DRM_PLATFORM
 static _EGLImage *
 dri2_create_image_mesa_drm_buffer(_EGLDisplay *disp, _EGLContext *ctx,
  EGLClientBuffer buffer, const EGLint 
*attr_list)
@@ -1169,6 +1172,7 @@
 
return dri2_create_image(disp, dri_image);
 }
+#endif
 
 #ifdef HAVE_WAYLAND_PLATFORM
 
@@ -1358,8 +1362,10 @@
   return dri2_create_image_khr_texture(disp, ctx, target, buffer, 
attr_list);
case EGL_GL_RENDERBUFFER_KHR:
   return dri2_create_image_khr_renderbuffer(disp, ctx, buffer, attr_list);
+#ifdef HAVE_DRM_PLATFORM
case EGL_DRM_BUFFER_MESA:
   return dri2_create_image_mesa_drm_buffer(disp, ctx, buffer, attr_list);
+#endif
 #ifdef HAVE_WAYLAND_PLATFORM
case EGL_WAYLAND_BUFFER_WL:
   return dri2_create_image_wayland_wl_buffer(disp, ctx, buffer, attr_list);
@@ -1384,6 +1390,7 @@
return EGL_TRUE;
 }
 
+#ifdef HAVE_DRM_PLATFORM
 static _EGLImage *
 dri2_create_drm_image_mesa(_EGLDriver *drv, _EGLDisplay *disp,
   const EGLint *attr_list)
@@ -1494,6 +1501,7 @@
 
return EGL_TRUE;
 }
+#endif
 
 #ifdef HAVE_WAYLAND_PLATFORM
 
@@ -1721,8 +1729,10 @@
dri2_drv-base.API.ReleaseTexImage = dri2_release_tex_image;
dri2_drv-base.API.CreateImageKHR = dri2_create_image_khr;
dri2_drv-base.API.DestroyImageKHR = dri2_destroy_image_khr;
+#ifdef HAVE_DRM_PLATFORM
dri2_drv-base.API.CreateDRMImageMESA = dri2_create_drm_image_mesa;
dri2_drv-base.API.ExportDRMImageMESA = dri2_export_drm_image_mesa;
+#endif
 #ifdef HAVE_WAYLAND_PLATFORM
dri2_drv-base.API.BindWaylandDisplayWL = dri2_bind_wayland_display_wl;
dri2_drv-base.API.UnbindWaylandDisplayWL = dri2_unbind_wayland_display_wl;
--- src/egl/drivers/dri2/platform_x11.c.original2013-11-10 
15:41:37.0 +0100
+++ src/egl/drivers/dri2/platform_x11.c 2013-11-10 15:46:52.0 +0100
@@ -33,7 +33,9 @@
 #include fcntl.h
 #include errno.h
 #include unistd.h
+#ifdef HAVE_DRM_PLATFORM
 #include xf86drm.h
+#endif
 #include sys/types.h
 #include sys/stat.h
 
@@ -606,6 +608,7 @@
 static EGLBoolean
 dri2_authenticate(_EGLDisplay *disp)
 {
+#ifdef HAVE_DRM_PLATFORM
struct dri2_egl_display *dri2_dpy = dri2_egl_display(disp);
drm_magic_t magic;
 
@@ -620,6 +623,9 @@
}
 
return EGL_TRUE;
+#else
+   return EGL_FALSE;
+#endif
 }
 
 static EGLBoolean
diff -ur mesa-9.2.2/debian/control ../mesa-9.2.2/debian/control
--- mesa-9.2.2/debian/control   2013-11-10 13:14:22.0 +0100
+++ ../mesa-9.2.2/debian/control2013-11-10 17:36:40.0 +0100
@@ -238,7 +238,7 @@
 
 Package: libegl1-mesa
 Section: libs
-Architecture: linux-any kfreebsd-any
+Architecture: any
 Depends:
  ${shlibs:Depends},
  ${misc:Depends},
@@ -260,7 +260,7 @@
 Package: libegl1-mesa-dbg
 Section: debug
 Priority: extra
-Architecture: linux-any kfreebsd-any
+Architecture: any
 Depends:
  libegl1-mesa (= ${binary:Version}),
  ${misc:Depends},
@@ -274,7 +274,7 @@
 
 Package: libegl1-mesa-dev
 Section: libdevel
-Architecture: linux-any kfreebsd-any
+Architecture: any
 Depends:
  libegl1-mesa (= ${binary:Version}),
  libegl1-mesa-drivers (= ${binary:Version}),
@@ -389,7 +389,7 @@
 
 Package: libgles1-mesa
 Section: libs
-Architecture: linux-any kfreebsd-any
+Architecture: any
 Depends:
  libglapi-mesa (= ${binary:Version}),
  ${shlibs:Depends},
@@ -410,7 +410,7 @@
 Package: libgles1-mesa-dbg
 Section: debug
 Priority: extra
-Architecture: linux-any kfreebsd-any
+Architecture: any
 Depends:
  libgles1-mesa (= ${binary:Version}),
  ${misc:Depends},
@@ -427,7 +427,7 @@
 
 Package: 

Bug#706889: xorg: Please drop openchrome from hurd's video-all

[Samuel Thibault]

Samuel Thibault, le Sun 05 May 2013 22:24:37 +0200, a écrit :
 The openchrome driver can't be built on hurd any more. Please remove it
 from video-all as attached patch does.

Or please apply the patch from #672546 to fix the build.

Samuel


-- 
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20130707085508.ga20...@type.youpi.perso.aquilenet.fr

Bug#672546: xserver-xorg-video-openchrome: FTBFS on hurd-i386: unconditional libdrm requirement

[Samuel Thibault]

Hello,

Pino Toscano, le Sat 12 May 2012 00:18:41 +0200, a écrit :
 The problem is that libdrm is considered an hard requirement (by the
 buildsystem and the Debian packaging), while it is only if the DRI
 support is enabled (and indeed there seems to be only libdrm usage in
 the DRI-related code).
 
 Attached there are patches to fix this:

I guess we could eventually make an NMU to fix this?

Samuel


-- 
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20130630095005.ga1...@type.youpi.perso.aquilenet.fr

Re: HAL and *BSD

[Samuel Thibault]

Steven Chamberlain, le Mon 10 Jun 2013 23:20:54 +0100, a écrit :
 On 05/06/13 02:08, Michael Biebl wrote:
  Afaics, there are basically 3 options:
  
  1/ We drop hal and Xorg is ported to something like devd on *BSD
  
  2/ We drop hal and hal support is simply disabled on non-Linux, which
  means, Xorg needs to be configured manually? Maybe Julien or KiBi can
  provide more info on this.
  
  3/ we keep hal, but only for the non-Linux architectures and I'd need
  someone (from the kfreebsd porters team) to take over maintenance.
 
 I don't see that FreeBSD upstream has a replacement yet so are still
 using HAL in their latest releases and development head.
 
 There was no mention of Hurd here;  how would it be affected by this?

Just the same I guess.

 I guess it is a long way from having something to replace the
 functionality of HAL?

Yes.

Samuel


-- 
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20130610222511.gd5...@type.youpi.perso.aquilenet.fr

Bug#706889: xorg: Please drop openchrome from hurd's video-all

[Samuel Thibault]

Package: xorg
Version: 1:7.7+2
Severity: normal

Hello,

The openchrome driver can't be built on hurd any more. Please remove it
from video-all as attached patch does.

Thanks,
Samuel

-- Package-specific info:
X server symlink status:

lrwxrwxrwx 1 root root 13 Aug  1  2011 /etc/X11/X - /usr/bin/Xorg
-rwxr-xr-x 1 root root 2044664 Apr 17 12:40 /usr/bin/Xorg

Diversions concerning libGL are in place

diversion of /usr/lib/libGL.so to /usr/lib/mesa-diverted/libGL.so by 
glx-diversions
diversion of /usr/lib/libGL.so.1 to /usr/lib/mesa-diverted/libGL.so.1 by 
glx-diversions
diversion of /usr/lib/i386-linux-gnu/libGL.so.1 to 
/usr/lib/mesa-diverted/i386-linux-gnu/libGL.so.1 by glx-diversions
diversion of /usr/lib/x86_64-linux-gnu/libGL.so.1.2 to 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so.1.2 by glx-diversions
diversion of /usr/lib/i386-linux-gnu/libGL.so to 
/usr/lib/mesa-diverted/i386-linux-gnu/libGL.so by glx-diversions
diversion of /usr/lib32/libGL.so to /usr/lib32/nvidia/diversions/libGL.so by 
libgl1-nvidia-alternatives-ia32
diversion of /usr/lib32/libGL.so.1 to /usr/lib32/nvidia/diversions/libGL.so.1 
by libgl1-nvidia-alternatives-ia32
diversion of /usr/lib/i386-linux-gnu/libGL.so.1.2 to 
/usr/lib/mesa-diverted/i386-linux-gnu/libGL.so.1.2 by glx-diversions
diversion of /usr/lib/x86_64-linux-gnu/libGL.so.1 to 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so.1 by glx-diversions
diversion of /usr/lib/libGL.so.1.2 to /usr/lib/mesa-diverted/libGL.so.1.2 by 
glx-diversions
diversion of /usr/lib/x86_64-linux-gnu/libGL.so to 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so by glx-diversions
diversion of /usr/lib32/libGL.so.1.2 to 
/usr/lib32/nvidia/diversions/libGL.so.1.2 by libgl1-nvidia-alternatives-ia32

VGA-compatible devices on PCI bus:
--
00:02.0 VGA compatible controller [0300]: Intel Corporation 2nd Generation Core 
Processor Family Integrated Graphics Controller [8086:0126] (rev 09)
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GF119 [Quadro NVS 
4200M] [10de:1056] (rev a1)

Xorg X server configuration file status:

-rw-r--r-- 1 root root 1179 Jan 20 22:26 /etc/X11/xorg.conf

Contents of /etc/X11/xorg.conf:
---
#Section InputDevice
#   Identifier  Generic Keyboard
#   Driver  evdev
#   #Option XkbRules  evdev
#   Option  XkbModel  geniuskb19e
#   Option  XkbLayout fr,brai
#   Option  XkbVariantoss,
#   Option  XkbOptions
compose:lwin,compose:rwin,nbsp:level3n,grp:shift_caps_toggle
#EndSection

#Section InputDevice
#   Identifier  Configured Mouse
#   Driver  mouse
#   Option  CorePointer
#   Option  Device/dev/gpmdata
#   Option  Protocol  IntelliMouse
#   Option  Emulate3Buttons   true
#EndSection

#Section InputClass
#   Identifier  synaptics mouse
#   MatchIsTouchpad yes
#   Driver synaptics
#   Option VertTwoFingerScroll True
#   Option HorizTwoFingerScroll True
#   Option VertEdgeScroll True
#   Option SpecialScrollAreaRight True
#EndSection

Section Device
Identifier  Configured Video Device
#Driver vesa
#Driver dummy
#Driver nvidia
#BusID  PCI:1:0:0
#Option TwinView
#Option TwinViewOrientation DFP-0 Below DFP-2
#Option ConnectedMonitor DFP-0
#Option UseDisplayDevice DFP-0
#Option OpenConsole False
EndSection

Section Monitor
Identifier  Configured Monitor
EndSection

/etc/X11/xorg.conf.d does not exist.

KMS configuration files:

/etc/modprobe.d/i915-kms.conf:
  options i915 modeset=1
  #options i915 modeset=0

Kernel version (/proc/version):
---
Linux version 3.9.0 (samy@type) (gcc version 4.6.3 (Debian 4.6.3-14) ) #1 SMP 
Mon Apr 29 13:56:55 CEST 2013

Xorg X server log files on system:
--
-rw-r--r-- 1 root root  73019 Aug 21  2012 /var/log/Xorg.2.log
-rw-r--r-- 1 root root  38755 Apr 14 21:46 /var/log/Xorg.1.log
-rw-r--r-- 1 root root  54985 May  5 11:31 /var/log/Xorg.0.log
-rw-r--r-- 1 root bumblebee 10435 May  5 12:11 /var/log/Xorg.8.log

Contents of most recent Xorg X server log file (/var/log/Xorg.8.log):
-
[153456.275] 
X.Org X Server 1.12.4
Release Date: 2012-08-27
[153456.275] X Protocol Version 11, Revision 0
[153456.275] Build Operating System: Linux 3.2.0-4-amd64 x86_64 Debian
[153456.275] Current Operating System: Linux type 3.9.0 #1 SMP Mon Apr 29 
13:56:55 CEST 2013 x86_64
[153456.275] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-3.9.0 
root=UUID=38e6e493-2f5f-4a98-b1d6-a9434f0683cc ro

Bug#696965: [PATCH RFC] xfree86: add option -notty to prevent VT allocation

[Samuel Thibault]

Hello,

Peter Hutterer, le Tue 08 Jan 2013 17:05:16 +1000, a écrit :
 Provided the driver permits it, Xorg -notty will not create a VT on startup.
 Currently this driver list includes dummy and qxl only.

I'd rather call it -novt, just like -novtswitch, -sharevts, vtXX.
Only the -keeptty option is really at the tty level, not the VT.

 This seems to do the job, it restores the original behaviour by default, but
 started with -notty the server skips the VT allocation provided all drivers
 set HW_SKIP_CONSOLE. 

Indeed, it looks fine for me.

Samuel


-- 
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130108114320.gb6...@type.bordeaux.inria.fr

Bug#681781: dummy: Please include sample xorg.conf

[Samuel Thibault]

Michal Suchanek, le Mon 07 Jan 2013 13:33:11 +0100, a écrit :
 How are these devices not configured?

Err, aren't you taking this thread for another one?  See the subject,
this is about providing a sample xorg.conf.  I'm here saying there
is no need for input sections, since they are already automatically
configured.

 It may not lock out the terminal from receiving keyboard input but it
 still configures input drivers and receives input from them.

Sure, that's what I'm saying.  This is independant from the other issue,
which is the VT not being allocated for input to actually happen.

Samuel


-- 
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130107124050.gd12...@type.bordeaux.inria.fr

Bug#681781: dummy: Please include sample xorg.conf

[Samuel Thibault]

Michal Suchanek, le Mon 07 Jan 2013 14:01:35 +0100, a écrit :
 Excerpts from Samuel Thibault's message of Mon Jan 07 13:40:50 +0100 2013:
  Michal Suchanek, le Mon 07 Jan 2013 13:33:11 +0100, a écrit :
   How are these devices not configured?
  
  Err, aren't you taking this thread for another one?  See the subject,
  this is about providing a sample xorg.conf.  I'm here saying there
  is no need for input sections, since they are already automatically
  configured.
 
 And I am saying that there *is* need for input sections to prevent them
 from being automatically configured.

Ooops, sorry, I hadn't understood that input devices were not desired in
this bug report.

I'm however wondering how this use case differs from simply using Xvfb.

Samuel


-- 
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130107132424.gg12...@type.bordeaux.inria.fr

Bug#681781: dummy: Please include sample xorg.conf

[Samuel Thibault]

Michal Suchanek, le Mon 07 Jan 2013 14:38:13 +0100, a écrit :
 Excerpts from Samuel Thibault's message of Mon Jan 07 14:24:24 +0100 2013:
  Michal Suchanek, le Mon 07 Jan 2013 14:01:35 +0100, a écrit :
   Excerpts from Samuel Thibault's message of Mon Jan 07 13:40:50 +0100 2013:
Michal Suchanek, le Mon 07 Jan 2013 13:33:11 +0100, a écrit :
 How are these devices not configured?

Err, aren't you taking this thread for another one?  See the subject,
this is about providing a sample xorg.conf.  I'm here saying there
is no need for input sections, since they are already automatically
configured.
   
   And I am saying that there *is* need for input sections to prevent them
   from being automatically configured.
  
  Ooops, sorry, I hadn't understood that input devices were not desired in
  this bug report.
  
  I'm however wondering how this use case differs from simply using Xvfb.
 
 Xvfb is deprecated, bitrotten, does not support xrandr and other
 extensions, ..

Could it perhaps be replaced by a mere shell script which invokes Xorg,
giving it the sample xorg.conf you provided?  That'd be a way easier
upgrade path for users than knowing about the dummy driver etc.

Samuel


-- 
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130107140128.gi12...@type.bordeaux.inria.fr

Bug#681781: dummy: Please include sample xorg.conf

[Samuel Thibault]

Michal Suchanek, le Mon 07 Jan 2013 15:13:27 +0100, a écrit :
 Excerpts from Samuel Thibault's message of Mon Jan 07 15:01:28 +0100 2013:
  Michal Suchanek, le Mon 07 Jan 2013 14:38:13 +0100, a écrit :
   Excerpts from Samuel Thibault's message of Mon Jan 07 14:24:24 +0100 2013:
Michal Suchanek, le Mon 07 Jan 2013 14:01:35 +0100, a écrit :
 Excerpts from Samuel Thibault's message of Mon Jan 07 13:40:50 +0100 
 2013:
  Michal Suchanek, le Mon 07 Jan 2013 13:33:11 +0100, a écrit :
   How are these devices not configured?
  
  Err, aren't you taking this thread for another one?  See the 
  subject,
  this is about providing a sample xorg.conf.  I'm here saying there
  is no need for input sections, since they are already automatically
  configured.
 
 And I am saying that there *is* need for input sections to prevent 
 them
 from being automatically configured.

Ooops, sorry, I hadn't understood that input devices were not desired in
this bug report.

I'm however wondering how this use case differs from simply using Xvfb.
   
   Xvfb is deprecated, bitrotten, does not support xrandr and other
   extensions, ..
  
  Could it perhaps be replaced by a mere shell script which invokes Xorg,
  giving it the sample xorg.conf you provided?  That'd be a way easier
  upgrade path for users than knowing about the dummy driver etc.
 
 For that the sample config has to live somewhere. It won't live in Xvfb
 package because while it's deprecated upstream it's not a reason for
 Debian to remove it. Or is it?

It can be a reason for removing it. Or better, replacing it with the
proposed script. That said, the xorg.conf would better be maintained
under the xorg umbrella, officially replacing Xvfb.

Samuel


-- 
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130107142144.gl12...@type.bordeaux.inria.fr

Bug#681781: dummy: Please include sample xorg.conf

[Samuel Thibault]

Michal Suchanek, le Mon 07 Jan 2013 15:35:38 +0100, a écrit :
 Some Xvfb options could be emulated with generating xorg.conf on
 the fly perhaps

That would surely be more user-friendly than having to deal with
modelines in xorg.conf :)

 but the shared memory option is not implemented in dummy
 AFAIK and may be used by some automated tests.

That however is a problem indeed. It could be made a /etc/alternative
for Xvfb.

Samuel


-- 
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130107143937.go12...@type.bordeaux.inria.fr

Bug#696965: support for HW_SKIP_CONSOLE breaks use by blind people

[Samuel Thibault]

Michal Suchanek, le Sat 05 Jan 2013 18:55:28 +0100, a écrit :
 On 5 January 2013 02:10, Samuel Thibault sthiba...@debian.org wrote:
  Alan Coopersmith, le Mon 31 Dec 2012 17:46:47 -0800, a écrit :
  On 12/31/12 05:36 PM, Samuel Thibault wrote:
   Michal Suchanek, le Mon 31 Dec 2012 19:22:13 +0100, a écrit :
   why is that patch needed?
  
   It is quite non-obvious why would dummy driver require a console under
   any circumstances. It does not render anything anywhere so does not
   use console for anything.
  
   The console *is* needed for keyboard input.
  
   Again, the use case is blind people who have use of possessing an actual
   screen, and thus don't have any, and thus have to use the dummy driver.
 
  So it sounds like that should be handled by the input driver, not the
  output driver.
 
  Ok, that makes sense. Input drivers however don't currently have a way
  to request the core to callxf86OpenConsole, similar to the absence of
  the HW_SKIP_CONSOLE flag in the case of video drivers.
 
  What do you recommend to add to the InputDriverRec? A driverFunc method
  like video drivers? Something else?
 
 I still don't understand the problem. The evdev driver opens the evdev
 device when loaded and reads input there. That happens even with dummy
 video driver so long as you do not carefully prevent the evdev driver
 from loading, does it not?

It does not. See for instance the attached xorg.conf, then I run from
vt1

xinit /usr/bin/fvwm -- :1

there is no VT switch, and pressing ^C 5s later kills the server (while
we'd want ^C to just go to the server). The resulting Xorg.1.log is
attached.

What I understand is that evedev does open things, but since no VT was
allocated, the evdev driver does not eat keypresses, i.e. from its point
of view it's as if we had switched away from an allocated VT.

So what Alan suggested is that the evdev driver simply tells the core
that it needs a VT to work properly. I'm now just asking which way that
should be done.

Samuel
Section InputDevice
Identifier  Generic Keyboard
Driver  evdev
Option  XkbModel  geniuskb19e
Option  XkbLayout fr,brai
Option  XkbVariantoss,
Option  XkbOptions
compose:lwin,compose:rwin,nbsp:level3n,grp:shift_caps_toggle
EndSection

Section InputDevice
Identifier  Configured Mouse
Driver  mouse
Option  CorePointer
Option  Device/dev/gpmdata
Option  Protocol  IntelliMouse
Option  Emulate3Buttons   true
EndSection

Section Device
Identifier  Configured Video Device
Driver  dummy
EndSection

Section Monitor
Identifier  Configured Monitor
EndSection
[ 66121.842] 
X.Org X Server 1.12.4
Release Date: 2012-08-27
[ 66121.846] X Protocol Version 11, Revision 0
[ 66121.847] Build Operating System: Linux 3.2.0-4.drm-amd64 x86_64 Debian
[ 66121.849] Current Operating System: Linux type 3.7.0 #2 SMP Fri Dec 21 
01:14:41 CET 2012 x86_64
[ 66121.849] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-3.7.0 
root=UUID=38e6e493-2f5f-4a98-b1d6-a9434f0683cc ro
[ 66121.851] Build Date: 29 November 2012  07:18:16PM
[ 66121.852] xorg-server 2:1.12.4-4 (Julien Cristau jcris...@debian.org) 
[ 66121.853] Current version of pixman: 0.26.0
[ 66121.858]Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
[ 66121.858] Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[ 66121.863] (==) Log file: /var/log/Xorg.1.log, Time: Sat Jan  5 19:00:53 
2013
[ 66121.871] (==) Using config file: /etc/X11/xorg.conf
[ 66121.873] (==) Using system config directory /usr/share/X11/xorg.conf.d
[ 66121.876] (==) No Layout section.  Using the first Screen section.
[ 66121.876] (==) No screen section available. Using defaults.
[ 66121.876] (**) |--Screen Default Screen Section (0)
[ 66121.876] (**) |   |--Monitor default monitor
[ 66121.876] (==) No device specified for screen Default Screen Section.
Using the first device section listed.
[ 66121.876] (**) |   |--Device Configured Video Device
[ 66121.876] (==) No monitor specified for screen Default Screen Section.
Using a default monitor configuration.
[ 66121.876] (==) Automatically adding devices
[ 66121.876] (==) Automatically enabling devices
[ 66121.896] (==) FontPath set to:
/usr/share/fonts/X11/misc,
/usr/share/fonts/X11/cyrillic,
/usr/share/fonts/X11/100dpi/:unscaled,
/usr/share/fonts/X11/75dpi/:unscaled,
/usr/share/fonts/X11/Type1,
/usr/share/fonts/X11/100dpi,
/usr/share/fonts/X11/75dpi,
/var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType,
built-ins
[ 66121.896] (==) ModulePath set to /usr

Bug#681781: dummy: Please include sample xorg.conf

[Samuel Thibault]

Michal Suchanek, le Wed 02 Jan 2013 11:27:04 +0100, a écrit :
 Excerpts from Samuel Thibault's message of Sun Dec 30 01:53:55 +0100 2012:
  Section Device
  Identifier Configured Video Device
  Driver dummy
  EndSection
 
 It is exactly because this is NOT sufficient that the sample
 configuration is needed.

I've just tried it, see attached log.

 The X server configures input drivers automagically. The above
 configuration sample avoids that.

The attached log shows it doesn't.

 The default mode list is very insufficient. That is why the additional
 modes are added in the configuration.

Ah, if you want more than 1024x768, yes, of course.  Otherwise my
experience shows 1024x768 does get configured.

Samuel
[ 67138.077] 
X.Org X Server 1.12.4
Release Date: 2012-08-27
[ 67138.083] X Protocol Version 11, Revision 0
[ 67138.084] Build Operating System: Linux 3.2.0-4.drm-amd64 x86_64 Debian
[ 67138.086] Current Operating System: Linux type 3.7.0 #2 SMP Fri Dec 21 
01:14:41 CET 2012 x86_64
[ 67138.086] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-3.7.0 
root=UUID=38e6e493-2f5f-4a98-b1d6-a9434f0683cc ro
[ 67138.089] Build Date: 29 November 2012  07:18:16PM
[ 67138.090] xorg-server 2:1.12.4-4 (Julien Cristau jcris...@debian.org) 
[ 67138.092] Current version of pixman: 0.26.0
[ 67138.095]Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
[ 67138.095] Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[ 67138.101] (==) Log file: /var/log/Xorg.1.log, Time: Sat Jan  5 19:17:50 
2013
[ 67138.102] (==) Using config file: /etc/X11/xorg.conf
[ 67138.104] (==) Using system config directory /usr/share/X11/xorg.conf.d
[ 67138.104] (==) No Layout section.  Using the first Screen section.
[ 67138.104] (==) No screen section available. Using defaults.
[ 67138.104] (**) |--Screen Default Screen Section (0)
[ 67138.104] (**) |   |--Monitor default monitor
[ 67138.104] (==) No device specified for screen Default Screen Section.
Using the first device section listed.
[ 67138.104] (**) |   |--Device Configured Video Device
[ 67138.104] (==) No monitor specified for screen Default Screen Section.
Using a default monitor configuration.
[ 67138.104] (==) Automatically adding devices
[ 67138.104] (==) Automatically enabling devices
[ 67138.104] (==) FontPath set to:
/usr/share/fonts/X11/misc,
/usr/share/fonts/X11/cyrillic,
/usr/share/fonts/X11/100dpi/:unscaled,
/usr/share/fonts/X11/75dpi/:unscaled,
/usr/share/fonts/X11/Type1,
/usr/share/fonts/X11/100dpi,
/usr/share/fonts/X11/75dpi,
/var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType,
built-ins
[ 67138.104] (==) ModulePath set to /usr/lib/xorg/modules
[ 67138.104] (II) The server relies on udev to provide the list of input 
devices.
If no devices become available, reconfigure udev or disable 
AutoAddDevices.
[ 67138.104] (II) Loader magic: 0x7f2da3935ae0
[ 67138.104] (II) Module ABI versions:
[ 67138.104]X.Org ANSI C Emulation: 0.4
[ 67138.104]X.Org Video Driver: 12.1
[ 67138.104]X.Org XInput driver : 16.0
[ 67138.104]X.Org Server Extension : 6.0
[ 67138.106] (--) PCI:*(0:0:2:0) 8086:0126:1028:0493 rev 9, Mem @ 
0xe540/4194304, 0xc000/268435456, I/O @ 0x5000/64
[ 67138.106] (II) Open ACPI successful (/var/run/acpid.socket)
[ 67138.106] (II) LoadModule: extmod
[ 67138.106] (II) Loading /usr/lib/xorg/modules/extensions/libextmod.so
[ 67138.107] (II) Module extmod: vendor=X.Org Foundation
[ 67138.107]compiled for 1.12.4, module version = 1.0.0
[ 67138.107]Module class: X.Org Server Extension
[ 67138.107]ABI class: X.Org Server Extension, version 6.0
[ 67138.107] (II) Loading extension SELinux
[ 67138.107] (II) Loading extension MIT-SCREEN-SAVER
[ 67138.107] (II) Loading extension XFree86-VidModeExtension
[ 67138.107] (II) Loading extension XFree86-DGA
[ 67138.107] (II) Loading extension DPMS
[ 67138.107] (II) Loading extension XVideo
[ 67138.107] (II) Loading extension XVideo-MotionCompensation
[ 67138.107] (II) Loading extension X-Resource
[ 67138.107] (II) LoadModule: dbe
[ 67138.107] (II) Loading /usr/lib/xorg/modules/extensions/libdbe.so
[ 67138.107] (II) Module dbe: vendor=X.Org Foundation
[ 67138.107]compiled for 1.12.4, module version = 1.0.0
[ 67138.107]Module class: X.Org Server Extension
[ 67138.107]ABI class: X.Org Server Extension, version 6.0
[ 67138.107] (II) Loading extension DOUBLE-BUFFER
[ 67138.107] (II) LoadModule: glx
[ 67138.107] (II) Loading /usr/lib/xorg/modules/extensions/libglx.so
[ 67138.107] (II) Module glx: vendor=X.Org Foundation
[ 67138.107]compiled for 1.12.4, module version = 1.0.0
[ 67138.107]ABI class: X.Org Server Extension, version 6.0
[ 67138.107] (==) AIGLX enabled
[ 67138.107] 

Bug#696965: support for HW_SKIP_CONSOLE breaks use by blind people

[Samuel Thibault]

Michal Suchanek, le Sat 05 Jan 2013 22:47:20 +0100, a écrit :
  there is no VT switch, and pressing ^C 5s later kills the server (while
  we'd want ^C to just go to the server). The resulting Xorg.1.log is
  attached.
 
 I don't think that an actual VT switch is required

From the point of the user, it is. There is no reason why it should not
happen just like with other video drivers in the use case at stake.

 It would be quite a few drivers to modify

We can proceed just like video devices: only modify the void input
driver into saying it doesn't need a VT, and the core then avoids
allocating a VT only if *only* the dummy video driver and void input
driver are used.

 On x86 there is always the ACPI button but on some platforms nothing
 like that is present so this flag would have to be set dynamically
 when an input device is plugged in if set bu the input driver. Also
 evdev handles keyboards and mice. Is plugging in a mouse enough to
 warrant locking the tty? Is presence of synaptics or wacom device?

I'm surprised that the discussion ends up with this way of thinking:
shouldn't it be the converse, i.e. a VT is always allocated *except* if
that is explicitly asked for by a special configuration? Otherwise we'll
keep having users saying that their special use does not trigger a VT
allocation...

Samuel


--
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20130105220424.gc5...@type.youpi.perso.aquilenet.fr

Bug#696965: support for HW_SKIP_CONSOLE breaks use by blind people

[Samuel Thibault]

Michal Suchanek, le Sat 05 Jan 2013 23:44:39 +0100, a écrit :
 On 5 January 2013 23:04, Samuel Thibault sthiba...@debian.org wrote:
  Michal Suchanek, le Sat 05 Jan 2013 22:47:20 +0100, a écrit :
   there is no VT switch, and pressing ^C 5s later kills the server (while
   we'd want ^C to just go to the server). The resulting Xorg.1.log is
   attached.
 
  I don't think that an actual VT switch is required
 
  From the point of the user, it is. There is no reason why it should not
  happen just like with other video drivers in the use case at stake.
 
 Those video drivers render graphics. The dummy driver does not.

But input drivers are still the same.

 It's not the same case.

From the user point of view it is: the user simply does not have a
screen to plug to his computer, and does not need any, anway, but the
use case is *exactly* the same: a user sitting in front of his computer,
wants to start an X session.

  It would be quite a few drivers to modify
 
  We can proceed just like video devices: only modify the void input
  driver into saying it doesn't need a VT, and the core then avoids
  allocating a VT only if *only* the dummy video driver and void input
  driver are used.
 
 Indeed, you could possibly say that the dummy driver does not need
 video output which then requires a VT switch and the void driver does
 not need a tty input which would require locking the tty.

The former is already done (and is the whole reason why it broke things
for blind people).  I'm asking which way is recommended to do the
latter.

  On x86 there is always the ACPI button but on some platforms nothing
  like that is present so this flag would have to be set dynamically
  when an input device is plugged in if set bu the input driver. Also
  evdev handles keyboards and mice. Is plugging in a mouse enough to
  warrant locking the tty? Is presence of synaptics or wacom device?
 
  I'm surprised that the discussion ends up with this way of thinking:
  shouldn't it be the converse, i.e. a VT is always allocated *except* if
  that is explicitly asked for by a special configuration? Otherwise we'll
  keep having users saying that their special use does not trigger a VT
  allocation...
 
 But there is the problem. The dummy driver sets the flag because it
 does not need the tty. The evdev driver does need the tty but it has
 no flag to set because opening a tty is the default. The bug comes
 exactly from the thinking that switching tty is the default and only
 an exception to this rule is flagged.

It has been so for decades.  It's hard to call that a bug.

 It would be much saner for the driver to say that it needs the tty if
 and when it needs it.

But as was mentioned, it'd mean patching *all* drivers, since it's a
behavior change. Thus the proposition of continuing the same way as was
done with video devices: not tell in which case it's needed, but in
which cases it's *not* needed.

Now, about the when it needs it, unfortunately it's not so simple ATM:
the core opens the console just once in InitOutput.  I'm a bit afraid of
moving that (and conversely, the dontVTSwitch flag) somewhere else to
make it dynamic: who knows what subtle bug that might introduce.

Samuel


--
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20130105225253.gd5...@type.youpi.perso.aquilenet.fr

Bug#696965: support for HW_SKIP_CONSOLE breaks use by blind people

[Samuel Thibault]

Samuel Thibault, le Sat 05 Jan 2013 23:52:53 +0100, a écrit :
 Michal Suchanek, le Sat 05 Jan 2013 23:44:39 +0100, a écrit :
  On 5 January 2013 23:04, Samuel Thibault sthiba...@debian.org wrote:
   Michal Suchanek, le Sat 05 Jan 2013 22:47:20 +0100, a écrit :
there is no VT switch, and pressing ^C 5s later kills the server (while
we'd want ^C to just go to the server). The resulting Xorg.1.log is
attached.
  
   I don't think that an actual VT switch is required
  
   From the point of the user, it is. There is no reason why it should not
   happen just like with other video drivers in the use case at stake.
  
  Those video drivers render graphics. The dummy driver does not.
 
 But input drivers are still the same.
 
  It's not the same case.
 
 From the user point of view it is: the user simply does not have a
 screen to plug to his computer, and does not need any, anway, but the
 use case is *exactly* the same: a user sitting in front of his computer,
 wants to start an X session.

(and just work with it immediately. Having an actual output or not does
not change the matter).

Samuel


--
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20130105225535.ge5...@type.youpi.perso.aquilenet.fr

Bug#696965: support for HW_SKIP_CONSOLE breaks use by blind people

[Samuel Thibault]

Alan Coopersmith, le Mon 31 Dec 2012 17:46:47 -0800, a écrit :
 On 12/31/12 05:36 PM, Samuel Thibault wrote:
  Michal Suchanek, le Mon 31 Dec 2012 19:22:13 +0100, a écrit :
  why is that patch needed?
 
  It is quite non-obvious why would dummy driver require a console under
  any circumstances. It does not render anything anywhere so does not
  use console for anything.
  
  The console *is* needed for keyboard input.
  
  Again, the use case is blind people who have use of possessing an actual
  screen, and thus don't have any, and thus have to use the dummy driver.
 
 So it sounds like that should be handled by the input driver, not the
 output driver.

Ok, that makes sense. Input drivers however don't currently have a way
to request the core to callxf86OpenConsole, similar to the absence of
the HW_SKIP_CONSOLE flag in the case of video drivers.

What do you recommend to add to the InputDriverRec? A driverFunc method
like video drivers? Something else?

Samuel


--
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20130105011028.gf5...@type.youpi.perso.aquilenet.fr

Bug#696965: [PATCH] support for HW_SKIP_CONSOLE breaks use by blind people

[Samuel Thibault]

Michal Suchanek, le Mon 31 Dec 2012 19:22:13 +0100, a écrit :
 why is that patch needed?
 
 It is quite non-obvious why would dummy driver require a console under
 any circumstances. It does not render anything anywhere so does not
 use console for anything.

The console *is* needed for keyboard input.

Again, the use case is blind people who have use of possessing an actual
screen, and thus don't have any, and thus have to use the dummy driver.

Samuel


--
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20130101013657.ga6...@type.youpi.perso.aquilenet.fr

Bug#696965: support for HW_SKIP_CONSOLE breaks use by blind people

[Samuel Thibault]

Package: xserver-xorg-video-dummy
Version: 1:0.3.3-2
Severity: important
Tags: upstream

Hello,

Unfortunately I've gotten the bug report only now...

In upstream commit e39d9a26

@@ -801,7 +804,7 @@ dummyDriverFunc(ScrnInfoPtr pScrn, xorgDriverFuncOp op, 
pointer ptr)
+   (*flag) = HW_SKIP_CONSOLE;

This has broken the use of Xorg by blind people who don't have a screen:
since drivers tend to abort when no screen is connected, blind people
would use the dummy driver.  But now that the dummy driver itself tells
not to open the console, keypresses are not eaten by the Xorg server,
thus making the whole Xorg session completely unusable.

What was the rationale for the change?  I can understand that in some
situation people would not want to open the console, but I would have
rather made it an option, and have made it not enabled by default,
because the blind people who need the dummy driver do not necessarily
have much technical knowledge beyond use the dummy driver, while
people who want to use the dummy driver with no VT most probably
understand what that means, and would be able to enable the option.

This was unfortunately actually already shipped in Squeeze.  The attached
patch can be used by people for now to avoid the issue, I'll work on
adding an option upstream.

Samuel
commit 1ec9d5adaf753715b78377483a3a2d71a323d43e
Author: Samuel Thibault samuel.thiba...@ens-lyon.org
Date:   Sun Dec 30 00:58:51 2012 +0100

Revert Add support for HW_SKIP_CONSOLE

This reverts commit e39d9a265572c273915f1803a729e7211d7b247b.

diff --git a/src/dummy_driver.c b/src/dummy_driver.c
index 6062c39..566a006 100644
--- a/src/dummy_driver.c
+++ b/src/dummy_driver.c
@@ -801,9 +801,6 @@ DUMMYCreateWindow(WindowPtr pWin)
 return TRUE;
 }
 
-#ifndef HW_SKIP_CONSOLE
-#define HW_SKIP_CONSOLE 4
-#endif
 
 static Bool
 dummyDriverFunc(ScrnInfoPtr pScrn, xorgDriverFuncOp op, pointer ptr)
@@ -813,7 +810,7 @@ dummyDriverFunc(ScrnInfoPtr pScrn, xorgDriverFuncOp op, 
pointer ptr)
 switch (op) {
case GET_REQUIRED_HW_INTERFACES:
flag = (CARD32*)ptr;
-   (*flag) = HW_SKIP_CONSOLE;
+   (*flag) = 0;
return TRUE;
default:
return FALSE;

Bug#681781: dummy: Please include sample xorg.conf

[Samuel Thibault]

Mmm, I believe the following would be enough:

Section Device
Identifier noscreendevice
Driver dummy
EndSection

Samuel


-- 
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20121230005355.GA22276@type

Bug#696965: [PATCH] support for HW_SKIP_CONSOLE breaks use by blind people

[Samuel Thibault]

Control: tags 696965 + patch

Hello,

Samuel Thibault, le Sun 30 Dec 2012 01:07:47 +0100, a écrit :
 I would have rather made it an option, and have made it not enabled
 by default, because the blind people who need the dummy driver do
 not necessarily have much technical knowledge beyond use the dummy
 driver, while people who want to use the dummy driver with no VT most
 probably understand what that means, and would be able to enable the
 option.

Here is a patch proposal.

Samuel



Add OpenConsole option to dummy devices

This permits to choose whether the dummy device wants the console. The
driver will make the core open the console if at least one device wants
it.

Signed-off-by: Samuel Thibault samuel.thiba...@ens-lyon.org

diff --git a/src/dummy_driver.c b/src/dummy_driver.c
index 6062c39..0ec5f4b 100644
--- a/src/dummy_driver.c
+++ b/src/dummy_driver.c
@@ -118,11 +118,13 @@ static SymTabRec DUMMYChipsets[] = {
 };
 
 typedef enum {
-OPTION_SW_CURSOR
+OPTION_SW_CURSOR,
+OPTION_OPEN_CONSOLE
 } DUMMYOpts;
 
 static const OptionInfoRec DUMMYOptions[] = {
 { OPTION_SW_CURSOR,SWcursor, OPTV_BOOLEAN,   {0}, FALSE },
+{ OPTION_OPEN_CONSOLE, OpenConsole,  OPTV_BOOLEAN,   {0}, FALSE },
 { -1,  NULL,   OPTV_NONE,  {0}, FALSE }
 };
 
@@ -812,9 +814,36 @@ dummyDriverFunc(ScrnInfoPtr pScrn, xorgDriverFuncOp op, 
pointer ptr)
 
 switch (op) {
case GET_REQUIRED_HW_INTERFACES:
+   {
+   Bool OpenConsole = FALSE;
+   GDevPtr *devSections;
+   int numDevSections, i;
+
+   /*
+* Find the config file Device sections that match this
+* driver
+*/
+   numDevSections = xf86MatchDevice(DUMMY_DRIVER_NAME, devSections);
+
+   for (i = 0; i  numDevSections; i++) {
+   OptionInfoPtr Options;
+
+   if ((Options = malloc(sizeof(DUMMYOptions
+   {
+   Bool DeviceOpenConsole = TRUE;
+   memcpy(Options, DUMMYOptions, sizeof(DUMMYOptions));
+   xf86ProcessOptions(-1, devSections[i]-options, Options);
+   xf86GetOptValBool(Options, OPTION_OPEN_CONSOLE, 
DeviceOpenConsole);
+   if (DeviceOpenConsole)
+   OpenConsole = TRUE;
+   free(Options);
+   }
+   }
+
flag = (CARD32*)ptr;
-   (*flag) = HW_SKIP_CONSOLE;
+   (*flag) = OpenConsole ? 0 : HW_SKIP_CONSOLE;
return TRUE;
+   }
default:
return FALSE;
 }


--
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20121230030951.GA29624@type

Bug#675289: libpciaccess: Implement legacy map io for hurd-i386

[Samuel Thibault]

tags 675289 + fixed-upstream
thanks

Julien Cristau, le Sat 09 Jun 2012 12:35:50 +0200, a écrit :
 On Fri, Jun  8, 2012 at 03:15:48 +0200, Samuel Thibault wrote:
 
  Samuel Thibault, le Thu 31 May 2012 20:10:25 +0200, a écrit :
   Cyril Brulebois, le Thu 31 May 2012 09:12:37 +0200, a écrit :
Samuel Thibault sthiba...@debian.org (31/05/2012):
 Please rather use the attached patch actually: just like on Linux 
 (e.g.
 on my laptop actually), it does not disable i/o access, otherwise
 several opens and then fewer closes would not leave i/o access 
 enabled.
 E.g. with the cirrus driver.

Please follow this (as usual):
   
   now forwarded.
  
  Without answer
  (http://lists.x.org/archives/xorg-devel/2012-May/031462.html).
  
  AIUI the RepoPolicy, even if I have commit right I need patch review for
  master branch commit, I'm not sure what to do now.
  
 That's only for the server and a couple drivers.  Most other repos are
 open.

Ok, now pushed to upstream.

Samuel



--
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120610152616.go4...@type.famille.thibault.fr

Bug#675289: libpciaccess: Implement legacy map io for hurd-i386

[Samuel Thibault]

Samuel Thibault, le Thu 31 May 2012 20:10:25 +0200, a écrit :
 Cyril Brulebois, le Thu 31 May 2012 09:12:37 +0200, a écrit :
  Samuel Thibault sthiba...@debian.org (31/05/2012):
   Please rather use the attached patch actually: just like on Linux (e.g.
   on my laptop actually), it does not disable i/o access, otherwise
   several opens and then fewer closes would not leave i/o access enabled.
   E.g. with the cirrus driver.
  
  Please follow this (as usual):
 
 now forwarded.

Without answer
(http://lists.x.org/archives/xorg-devel/2012-May/031462.html).

AIUI the RepoPolicy, even if I have commit right I need patch review for
master branch commit, I'm not sure what to do now.

Samuel



--
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120608011548.ga16...@type.famille.thibault.fr

Bug#675289: libpciaccess: Implement legacy map io for hurd-i386

[Samuel Thibault]

forwarded 675289 xorg-de...@lists.x.org
tags 675289 + upstream
thanks

Cyril Brulebois, le Thu 31 May 2012 09:12:37 +0200, a écrit :
 Samuel Thibault sthiba...@debian.org (31/05/2012):
  Please rather use the attached patch actually: just like on Linux (e.g.
  on my laptop actually), it does not disable i/o access, otherwise
  several opens and then fewer closes would not leave i/o access enabled.
  E.g. with the cirrus driver.
 
 Please follow this (as usual):

Well, I had simply used the same way as was done for kFreeBSD in
#669062...  But alright, now forwarded.

Samuel



--
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120531181025.gq4...@type.famille.thibault.fr

Bug#675289: libpciaccess: Implement legacy map io for hurd-i386

[Samuel Thibault]

Package: libpciaccess
Version: 0.13.1-2
Severity: important
Tags: patch
User: debian-h...@lists.debian.org
Usertags: hurd

Hello,

Just like kfreebsd needed in #669062, hurd-i386 needs legacy map  io
support in libpciaccess, otherwise Xorg segfaults, here is a patch.

Samuel

-- System Information:
Debian Release: wheezy/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (1, 
'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 3.0.4 (SMP w/8 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

-- 
Samuel Thibault samuel.thiba...@fnac.net
A  mr  -  remove the home of correct users who accidentally enter mr
Ainstead of rm
--- src/x86_pci.c.original  2012-05-31 03:03:48.0 +
+++ src/x86_pci.c   2012-05-31 03:20:17.0 +
@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 2009 Samuel Thibault
+ * Copyright (c) 2009, 2012 Samuel Thibault
  * Heavily inspired from the freebsd, netbsd, and openbsd backends
  * (C) Copyright Eric Anholt 2006
  * (C) Copyright IBM Corporation 2006
@@ -550,6 +550,92 @@
 x86_disable_io();
 }
 
+static struct pci_io_handle *
+pci_device_x86_open_legacy_io(struct pci_io_handle *ret,
+struct pci_device *dev, pciaddr_t base, pciaddr_t size)
+{
+x86_enable_io();
+
+ret-base = base;
+ret-size = size;
+
+return ret;
+}
+
+static void
+pci_device_x86_close_io(struct pci_device *dev, struct pci_io_handle *handle)
+{
+x86_disable_io();
+}
+
+static uint32_t
+pci_device_x86_read32(struct pci_io_handle *handle, uint32_t reg)
+{
+return inl(reg + handle-base);
+}
+
+static uint16_t
+pci_device_x86_read16(struct pci_io_handle *handle, uint32_t reg)
+{
+return inw(reg + handle-base);
+}
+
+static uint8_t
+pci_device_x86_read8(struct pci_io_handle *handle, uint32_t reg)
+{
+return inb(reg + handle-base);
+}
+
+static void
+pci_device_x86_write32(struct pci_io_handle *handle, uint32_t reg,
+  uint32_t data)
+{
+outl(data, reg + handle-base);
+}
+
+static void
+pci_device_x86_write16(struct pci_io_handle *handle, uint32_t reg,
+  uint16_t data)
+{
+outw(data, reg + handle-base);
+}
+
+static void
+pci_device_x86_write8(struct pci_io_handle *handle, uint32_t reg,
+ uint8_t data)
+{
+outb(data, reg + handle-base);
+}
+
+static int
+pci_device_x86_map_legacy(struct pci_device *dev, pciaddr_t base,
+pciaddr_t size, unsigned map_flags, void **addr)
+{
+struct pci_device_mapping map;
+int err;
+
+map.base = base;
+map.size = size;
+map.flags = map_flags;
+err = pci_device_x86_map_range(dev, map);
+*addr = map.memory;
+
+return err;
+}
+
+static int
+pci_device_x86_unmap_legacy(struct pci_device *dev, void *addr,
+pciaddr_t size)
+{
+struct pci_device_mapping map;
+
+map.size = size;
+map.flags = 0;
+map.memory = addr;
+
+return pci_device_generic_unmap_range(dev, map);
+}
+
 static const struct pci_system_methods x86_pci_methods = {
 .destroy = pci_system_x86_destroy,
 .read_rom = pci_device_x86_read_rom,
@@ -559,6 +645,16 @@
 .read = pci_device_x86_read,
 .write = pci_device_x86_write,
 .fill_capabilities = pci_fill_capabilities_generic,
+.open_legacy_io = pci_device_x86_open_legacy_io,
+.close_io = pci_device_x86_close_io,
+.read32 = pci_device_x86_read32,
+.read16 = pci_device_x86_read16,
+.read8 = pci_device_x86_read8,
+.write32 = pci_device_x86_write32,
+.write16 = pci_device_x86_write16,
+.write8 = pci_device_x86_write8,
+.map_legacy = pci_device_x86_map_legacy,
+.unmap_legacy = pci_device_x86_unmap_legacy,
 };
 
 static int pci_probe(struct pci_system_x86 *pci_sys_x86)

Bug#675289: libpciaccess: Implement legacy map io for hurd-i386

[Samuel Thibault]

Samuel Thibault, le Thu 31 May 2012 03:24:14 +0200, a écrit :
 Just like kfreebsd needed in #669062, hurd-i386 needs legacy map  io
 support in libpciaccess, otherwise Xorg segfaults, here is a patch.

Please rather use the attached patch actually: just like on Linux (e.g.
on my laptop actually), it does not disable i/o access, otherwise
several opens and then fewer closes would not leave i/o access enabled.
E.g. with the cirrus driver.

Samuel
--- libpciaccess-0.13.1.orig/src/x86_pci.c
+++ libpciaccess-0.13.1/src/x86_pci.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 2009 Samuel Thibault
+ * Copyright (c) 2009, 2012 Samuel Thibault
  * Heavily inspired from the freebsd, netbsd, and openbsd backends
  * (C) Copyright Eric Anholt 2006
  * (C) Copyright IBM Corporation 2006
@@ -550,6 +550,94 @@
 x86_disable_io();
 }
 
+static struct pci_io_handle *
+pci_device_x86_open_legacy_io(struct pci_io_handle *ret,
+struct pci_device *dev, pciaddr_t base, pciaddr_t size)
+{
+x86_enable_io();
+
+ret-base = base;
+ret-size = size;
+
+return ret;
+}
+
+static void
+pci_device_x86_close_io(struct pci_device *dev, struct pci_io_handle *handle)
+{
+/* do not disable I/O, as it may be opened several times, and closed
+ * fewer times. */
+/* x86_disable_io(); */
+}
+
+static uint32_t
+pci_device_x86_read32(struct pci_io_handle *handle, uint32_t reg)
+{
+return inl(reg + handle-base);
+}
+
+static uint16_t
+pci_device_x86_read16(struct pci_io_handle *handle, uint32_t reg)
+{
+return inw(reg + handle-base);
+}
+
+static uint8_t
+pci_device_x86_read8(struct pci_io_handle *handle, uint32_t reg)
+{
+return inb(reg + handle-base);
+}
+
+static void
+pci_device_x86_write32(struct pci_io_handle *handle, uint32_t reg,
+  uint32_t data)
+{
+outl(data, reg + handle-base);
+}
+
+static void
+pci_device_x86_write16(struct pci_io_handle *handle, uint32_t reg,
+  uint16_t data)
+{
+outw(data, reg + handle-base);
+}
+
+static void
+pci_device_x86_write8(struct pci_io_handle *handle, uint32_t reg,
+ uint8_t data)
+{
+outb(data, reg + handle-base);
+}
+
+static int
+pci_device_x86_map_legacy(struct pci_device *dev, pciaddr_t base,
+pciaddr_t size, unsigned map_flags, void **addr)
+{
+struct pci_device_mapping map;
+int err;
+
+map.base = base;
+map.size = size;
+map.flags = map_flags;
+err = pci_device_x86_map_range(dev, map);
+*addr = map.memory;
+
+return err;
+}
+
+static int
+pci_device_x86_unmap_legacy(struct pci_device *dev, void *addr,
+pciaddr_t size)
+{
+struct pci_device_mapping map;
+
+map.size = size;
+map.flags = 0;
+map.memory = addr;
+
+return pci_device_generic_unmap_range(dev, map);
+}
+
 static const struct pci_system_methods x86_pci_methods = {
 .destroy = pci_system_x86_destroy,
 .read_rom = pci_device_x86_read_rom,
@@ -559,6 +647,16 @@
 .read = pci_device_x86_read,
 .write = pci_device_x86_write,
 .fill_capabilities = pci_fill_capabilities_generic,
+.open_legacy_io = pci_device_x86_open_legacy_io,
+.close_io = pci_device_x86_close_io,
+.read32 = pci_device_x86_read32,
+.read16 = pci_device_x86_read16,
+.read8 = pci_device_x86_read8,
+.write32 = pci_device_x86_write32,
+.write16 = pci_device_x86_write16,
+.write8 = pci_device_x86_write8,
+.map_legacy = pci_device_x86_map_legacy,
+.unmap_legacy = pci_device_x86_unmap_legacy,
 };
 
 static int pci_probe(struct pci_system_x86 *pci_sys_x86)

Bug#384712: Translation teams should work on Xt applications localization too

[Samuel Thibault]

Jonathan Nieder, le Fri 06 Jan 2012 22:12:46 -0600, a écrit :
 Samuel Thibault wrote:
 
  the attached files are the ones that the xterm
  package should put in /etc/X11/fr_FR@euro/app-defaults/ for
  French localization (some UTF-8 versions should also be put into
  /etc/X11/fr_FR.UTF-8/app-defaults/)
 
 Sounds like a sensible thing to do.  
 
 [...]
  *mainMenu*logging*Label:  Loguer vers un fichier
  *mainMenu*print*Label:  Imprimer la fenêtre
  *mainMenu*print-redirect*Label:  Rediriger vers l'imprimante
 
 I'd like a complete translation to play with and send as a test case
 to go along with a strawman patch to make make install do the right
 thing.  Missing strings, with rough translations en franglais for your
 amusement:
 
   Full Screen - Plein écran
   Print-All Immediately - Enregistrer le contenu de la fenêtre
   Print-All on Error - Enregistrer le contenu de la fenêtre sur erreur
   Termcap Function-Keys - Touches de fonction Termcap
   Keep Selection - N'abandonner pas la sélection 

“Ne pas abandonner la sélection”

why not like in english, that is

“Garder la sélection”

?

   Enable Bell Urgency - Active la conseil d'urgence sur alerte

“Activer l'alerte sonore”

   Packed Font - Caractères compressés
   UTF-8 Fonts - Police UTF-8
   Allow Color Ops - Autoriser opérations sur couleur
   Allow Font Ops - Autoriser opérations sur la police (yech)
   Allow Termcap Ops - Autoriser opérations de termcap
   Allow Title Ops - Autoriser la modification de la titre

Maybe rather keeping it coherent:

“Autoriser opérations sur le titre”

   Allow Window Ops - Autoriser la manipulation de la fenêtre

“Autoriser opérations sur la fenêtre”

Samuel



--
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120107211819.gw4...@type.famille.thibault.fr

Bug#638016: xutils-dev: Fix FTBFS of xxkb on hurd-i386

[Samuel Thibault]

Svante Signell, le Tue 16 Aug 2011 16:54:05 +0200, a écrit :
 The attached patch fixes the FTBFS problem of xxkb-1.11-2.1 for
 GNU/Hurd. ProjectRoot and ManDirectoryRoot are added to gnu.cfg.

And this is to be kept in Debian only, not upstream, because only
the Debian distribution of GNU/Hurd uses a separate /usr, others use
prefix=/

Samuel



--
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110816150537.gk18...@type.famille.thibault.fr

Bug#638016: xutils-dev: Fix FTBFS of xxkb on hurd-i386

[Samuel Thibault]

Svante Signell, le Tue 16 Aug 2011 21:36:31 +0200, a écrit :
 On Tue, 2011-08-16 at 17:05 +0200, Samuel Thibault wrote:
  Svante Signell, le Tue 16 Aug 2011 16:54:05 +0200, a écrit :
   The attached patch fixes the FTBFS problem of xxkb-1.11-2.1 for
   GNU/Hurd. ProjectRoot and ManDirectoryRoot are added to gnu.cfg.
  
  And this is to be kept in Debian only, not upstream, because only
  the Debian distribution of GNU/Hurd uses a separate /usr, others use
  prefix=/
 
 Would the problem be solved by removing ProjectRoot set to /usr?

The same applies to ManDirectoryRoot, since ProjectRoot is a prefix of
ManDirectoryRoot

 In fact only ManDirectoryRoot set to /usr/share/man in needed to fix the
 build problem.

But some other issues might appear in other packages. linux.cf does
define ProjectRoot to /usr, so let's just do the same for Debian
GNU/Hurd.

 Are other GNU distributions using /usr/share/man
 or /usr/man for manpages?

/share/man, simply because prefix is /

 In case /usr/share/man is OK, I can remove
 ProjectRoot from the patch, and it would not be Debian specific.

Keep it as you already submitted. That's what we do in the Linux case,
let's just do the same for Debian GNU/Hurd, even if that is not useful
to xxkb, it'd be useful to other packages.

So in short: please apply Svante's patch, and keep it as Debian-specific
patch.

Samuel



--
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110816212546.ga20...@type.famille.thibault.fr

Bug#632970: cannot set keyboard layout for vserver

[Samuel Thibault]

(I've fixed the reassign typo already)

Samuel Thibault, le Sat 23 Jul 2011 09:04:21 +0200, a écrit :
 Cyril Brulebois, le Fri 22 Jul 2011 20:15:42 +0200, a écrit :
  Samuel Thibault sthiba...@debian.org (22/07/2011):
   KiBi wrote:
Xephyr is not X, and uses us by default.
   
   Why should it be cast into stone?
  
  I didn't say a thing about that.
 
 Ok.

Just to explain: there were three people answering the bug with this
is not a bug in keyboard-configuration, and the bug was closed. So it
really looked like it would be refused to simply reassign the bug to
xserver-xephyr.

Samuel



--
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110723094210.GF6421@const

Bug#632970: cannot set keyboard layout for vserver

[Samuel Thibault]

Julien Cristau, le Sat 23 Jul 2011 23:43:52 +0200, a écrit :
 On Sat, Jul 23, 2011 at 09:35:19 +0200, Samuel Thibault wrote:
 
  Julien Cristau, le Fri 22 Jul 2011 20:21:00 +0200, a écrit :
   On Fri, Jul 22, 2011 at 15:57:11 +0200, Samuel Thibault wrote:
So it'd be a matter of xserver-xephyr defaulting to the underlying X
server layout,
   
   Maybe.  Except there's no reliable way to do that.
  
  Actually I don't see why. Doesn't Xephyr use the underlying X server
  keycodes? It'd be a matter of copying the current X layout into the
  Xephyr server.
  
 Right.  But InitKeyboardDeviceStruct takes rmlvo, not a complete map.  I
 guess you could run XkbGetMap on the host server and the equivalent of
 XkbSetMap on the guest; that might prove messy…

Well, maybe we can just forward upstream and let them decide what they
think.

Samuel



--
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110723220735.gd19...@const.dc0b.debconf.org

hurd-i386 udeb support

[Samuel Thibault]

Package: xorg-server
Version: 1.10.0.902-1

Hello,

Cyril Brulebois, le Mon 04 Apr 2011 03:42:25 +0200, a écrit :
 On the hurd-* side, there's no udeb for the server yet, but tested
 patches to add one would be welcome.

The trivial (attached) patch works fine, thanks!

Samuel
diff -ur xorg-server-1.9.5/debian/control debian/control
--- xorg-server-1.9.5/debian/control2011-04-11 10:17:44.0 +0200
+++ debian/control  2011-04-11 10:24:14.0 +0200
@@ -130,7 +130,7 @@
 XC-Package-Type: udeb
 Section: debian-installer
 # exclude sparc because of linker errors
-Architecture: alpha amd64 armel armhf hppa i386 ia64 kfreebsd-amd64 
kfreebsd-i386 mips mipsel powerpc powerpcspe s390
+Architecture: alpha amd64 armel armhf hppa i386 ia64 kfreebsd-amd64 
kfreebsd-i386 mips mipsel powerpc powerpcspe s390 hurd-i386
 Depends:
 # merged: xserver-common (= ${source:Version}),
  xkb-data-udeb,

Bug#619862: xorg: Drop sisusb and ati from hurd-i386's video-all

[Samuel Thibault]

Julien Cristau, le Fri 01 Apr 2011 09:10:15 +0200, a écrit :
 On Tue, Mar 29, 2011 at 02:46:46 +0200, Samuel Thibault wrote:
 
  Julien Cristau, le Mon 28 Mar 2011 15:58:31 +0200, a écrit :
   ati should still be buildable with --disable-dri.
  
  In principle, yes, in practice, no.
  
  dh_auto_configure -- --disable-dri
  ...
  libtool: compile:  gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I../../src -I.. 
  -I../../src/AtomBios/includes -Wall -fvisibility=hidden -I/usr/include/xorg 
  -I/usr/include/pixman-1 -DDISABLE_EASF -DENABLE_ALL_SERVICE_FUNCTIONS 
  -DATOM_BIOS -DATOM_BIOS_PARSER -DDRIVER_PARSER -g -O2 -c 
  ../../src/radeon_accel.c  -fPIC -DPIC -o .libs/radeon_accel.o
  In file included from ../../src/radeon_accel.c:80:
  ../../src/radeon.h:749: error: expected specifier-qualifier-list before 
  ‘drmBufPtr’
  
 And that can't be fixed?

It probably can, yes.  But sometimes such issues looks to me like
windmills.

Samuel



--
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110401073441.gj5...@const.famille.thibault.fr

Bug#619863: xserver-xorg-video-openchrome: FTBFS on hurd-i386

[Samuel Thibault]

Hello,

Julien Viard de Galbert, le Tue 29 Mar 2011 11:22:18 +0200, a écrit :
 Does this require an upload now, or can it wait for the next version ?

We'd like an upload soon, to make the xorg package installable.

Samuel



--
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20110329092733.gy26...@const.famille.thibault.fr

Bug#620089: xserver-xorg-input-mouse: Fix OSMouse protocol on hurd-i386

[Samuel Thibault]

Package: xserver-xorg-input-mouse
Version: 1:1.5.0-2
Severity: important
Tags: patch

Hello,

Could you please cherry-pick d6e96238 from upstream?

“Fix OSMouse OS-defined protocol support

Fix regression introduced by 0a088df6: in the case of an OS-specific
protocol, the protocol is PROT_UNKNOWN, but should not be rejected: the core
mouse drive just needs to let the OS driver handle it.”

It is needed to get mouse working at all on hurd-i386.

Samuel



--
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20110329232338.ga22...@const.famille.thibault.fr

Bug#620089: xserver-xorg-input-mouse: Fix OSMouse protocol on hurd-i386

[Samuel Thibault]

reopen 620089
notfound 620089 1:1.5.0-2
found 620089 1:1.7.0-1
thanks

Cyril Brulebois, le Wed 30 Mar 2011 01:32:31 +0200, a écrit :
 Samuel Thibault sthiba...@debian.org (30/03/2011):
  Could you please cherry-pick d6e96238 from upstream?
 
 $ git describe 0a088df6
 xf86-input-mouse-1.6.0-29-g0a088df
 
 Sure. Already in sid…

strcmp(0a088df6, d6e96238)
- -1 :)

Sorry for the bug version squew, should be fixed now.

Samuel



--
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110329233754.gj5...@const.famille.thibault.fr

Bug#620089: xserver-xorg-input-mouse: Fix OSMouse protocol on hurd-i386

[Samuel Thibault]

Hello,

Could you also cherry-pick 17806678?

“
Fix Hurd mouse driver with XInput ABI before 12

Commit 7bf22a36 (Use pInfo-options instead of conf-idev.) updated the
xf86CollectInputOptions call into keeping previous options (for ABI before
12). The hurd mouse driver also needs to be updated.
”

?

Samuel



--
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20110330010127.ga25...@const.famille.thibault.fr