Bug#923454: renderdoc: FTBFS (error: braces around scalar initializer for type 'int')

[Santiago Vila]

Package: src:renderdoc
Version: 1.2+dfsg-1
Severity: serious
Tags: ftbfs

Dear maintainer:

I tried to build this package in buster but it failed:


[...]
 debian/rules build-arch
dh build-arch --buildsystem cmake
   dh_update_autotools_config -a -O--buildsystem=cmake
   dh_autoreconf -a -O--buildsystem=cmake
   debian/rules override_dh_auto_configure
make[1]: Entering directory '/<>/renderdoc-1.2+dfsg'
dh_auto_configure -- \
-DBUILD_VERSION_STABLE=true \
-DBUILD_VERSION_DIST_NAME=Debian \
-DBUILD_VERSION_DIST_VER=1.2+dfsg-1 \

-DBUILD_VERSION_DIST_CONTACT="https://salsa.debian.org/xorg-team/app/renderdoc; 
\
-DVULKAN_LAYER_FOLDER=/usr/share/vulkan/implicit_layer.d \
-DRENDERDOC_SWIG_PACKAGE=/<>/renderdoc-1.2+dfsg/swig \
-DCMAKE_BINARY_DIR=/<>/renderdoc-1.2+dfsg/debian/tmp \

[... snipped ...]

[ 61%] Building CXX object 
renderdoc/driver/vulkan/CMakeFiles/rdoc_vulkan.dir/wrappers/vk_get_funcs.cpp.o
cd 
/<>/renderdoc-1.2+dfsg/obj-x86_64-linux-gnu/renderdoc/driver/vulkan 
&& /usr/bin/c++  
-DDISTRIBUTION_CONTACT=\"https://salsa.debian.org/xorg-team/app/renderdoc\; 
-DDISTRIBUTION_NAME=\"Debian\" -DDISTRIBUTION_VERSION=\"1.2+dfsg-1\" 
-DGIT_COMMIT_HASH=\"NO_GIT_COMMIT_HASH_DEFINED\" -DRENDERDOC_EXPORTS 
-DRENDERDOC_PLATFORM_LINUX -DRENDERDOC_STABLE_BUILD=1 -DRENDERDOC_SUPPORT_GL 
-DRENDERDOC_SUPPORT_GLES -DRENDERDOC_SUPPORT_VULKAN -DRENDERDOC_WINDOWING_XCB 
-DRENDERDOC_WINDOWING_XLIB -DVK_USE_PLATFORM_XCB_KHR -DVK_USE_PLATFORM_XLIB_KHR 
-DVK_USE_PLATFORM_XLIB_XRANDR_EXT -D_RELEASE 
-I/<>/renderdoc-1.2+dfsg/renderdoc 
-I/<>/renderdoc-1.2+dfsg/renderdoc/3rdparty  -g -O2 
-fdebug-prefix-map=/<>/renderdoc-1.2+dfsg=. -fstack-protector-strong 
-Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -std=c++11 
-fstrict-aliasing -fvisibility=hidden -fvisibility-inlines-hidden -Wall -Wextra 
-Wno-unused-variable -Wno-unused-parameter -Wno-unused-result -W
 no-type-limits -Wno-missing-field-initializers -Wno-unknown-pragmas 
-Wno-reorder -Wno-unused-but-set-variable -Wno-maybe-uninitialized 
-Wno-class-memaccess -Wimplicit-fallthrough=2 -O3 -DNDEBUG -fPIC   -o 
CMakeFiles/rdoc_vulkan.dir/wrappers/vk_get_funcs.cpp.o -c 
/<>/renderdoc-1.2+dfsg/renderdoc/driver/vulkan/wrappers/vk_get_funcs.cpp
[ 61%] Building CXX object 
renderdoc/driver/vulkan/CMakeFiles/rdoc_vulkan.dir/wrappers/vk_misc_funcs.cpp.o
cd 
/<>/renderdoc-1.2+dfsg/obj-x86_64-linux-gnu/renderdoc/driver/vulkan 
&& /usr/bin/c++  
-DDISTRIBUTION_CONTACT=\"https://salsa.debian.org/xorg-team/app/renderdoc\; 
-DDISTRIBUTION_NAME=\"Debian\" -DDISTRIBUTION_VERSION=\"1.2+dfsg-1\" 
-DGIT_COMMIT_HASH=\"NO_GIT_COMMIT_HASH_DEFINED\" -DRENDERDOC_EXPORTS 
-DRENDERDOC_PLATFORM_LINUX -DRENDERDOC_STABLE_BUILD=1 -DRENDERDOC_SUPPORT_GL 
-DRENDERDOC_SUPPORT_GLES -DRENDERDOC_SUPPORT_VULKAN -DRENDERDOC_WINDOWING_XCB 
-DRENDERDOC_WINDOWING_XLIB -DVK_USE_PLATFORM_XCB_KHR -DVK_USE_PLATFORM_XLIB_KHR 
-DVK_USE_PLATFORM_XLIB_XRANDR_EXT -D_RELEASE 
-I/<>/renderdoc-1.2+dfsg/renderdoc 
-I/<>/renderdoc-1.2+dfsg/renderdoc/3rdparty  -g -O2 
-fdebug-prefix-map=/<>/renderdoc-1.2+dfsg=. -fstack-protector-strong 
-Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -std=c++11 
-fstrict-aliasing -fvisibility=hidden -fvisibility-inlines-hidden -Wall -Wextra 
-Wno-unused-variable -Wno-unused-parameter -Wno-unused-result -W
 no-type-limits -Wno-missing-field-initializers -Wno-unknown-pragmas 
-Wno-reorder -Wno-unused-but-set-variable -Wno-maybe-uninitialized 
-Wno-class-memaccess -Wimplicit-fallthrough=2 -O3 -DNDEBUG -fPIC   -o 
CMakeFiles/rdoc_vulkan.dir/wrappers/vk_misc_funcs.cpp.o -c 
/<>/renderdoc-1.2+dfsg/renderdoc/driver/vulkan/wrappers/vk_misc_funcs.cpp
[ 61%] Building CXX object 
renderdoc/driver/vulkan/CMakeFiles/rdoc_vulkan.dir/wrappers/vk_queue_funcs.cpp.o
cd 
/<>/renderdoc-1.2+dfsg/obj-x86_64-linux-gnu/renderdoc/driver/vulkan 
&& /usr/bin/c++  
-DDISTRIBUTION_CONTACT=\"https://salsa.debian.org/xorg-team/app/renderdoc\; 
-DDISTRIBUTION_NAME=\"Debian\" -DDISTRIBUTION_VERSION=\"1.2+dfsg-1\" 
-DGIT_COMMIT_HASH=\"NO_GIT_COMMIT_HASH_DEFINED\" -DRENDERDOC_EXPORTS 
-DRENDERDOC_PLATFORM_LINUX -DRENDERDOC_STABLE_BUILD=1 -DRENDERDOC_SUPPORT_GL 
-DRENDERDOC_SUPPORT_GLES -DRENDERDOC_SUPPORT_VULKAN -DRENDERDOC_WINDOWING_XCB 
-DRENDERDOC_WINDOWING_XLIB -DVK_USE_PLATFORM_XCB_KHR -DVK_USE_PLATFORM_XLIB_KHR 
-DVK_USE_PLATFORM_XLIB_XRANDR_EXT -D_RELEASE 
-I/<>/renderdoc-1.2+dfsg/renderdoc 
-I/<>/renderdoc-1.2+dfsg/renderdoc/3rdparty  -g -O2 
-fdebug-prefix-map=/<>/renderdoc-1.2+dfsg=. -fstack-protector-strong 
-Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -std=c++11 
-fstrict-aliasing -fvisibility=hidden -fvisibility-inlines-hidden -Wall -Wextra 
-Wno-unused-variable -Wno-unused-parameter -Wno-unused-result -W
 no-type-limits -Wno-missing-field-initializers -Wno-unknown-pragmas 
-Wno-reorder -Wno-unused-but-set-variable 

Bug#921763: weston: FTBFS (dh_install: missing files)

[Santiago Vila]

Package: src:weston
Version: 5.0.0-1
Severity: serious
Tags: ftbfs

Dear maintainer:

I tried to build this package in buster but it failed:


[...]
 debian/rules build-arch
dh build-arch --with quilt
   dh_quilt_patch -a
No series file found
   dh_update_autotools_config -a
   dh_autoreconf -a
libtoolize: putting auxiliary files in AC_CONFIG_AUX_DIR, 'build-aux'.
libtoolize: copying file 'build-aux/ltmain.sh'
libtoolize: putting macros in AC_CONFIG_MACRO_DIRS, 'm4'.
libtoolize: copying file 'm4/libtool.m4'
libtoolize: copying file 'm4/ltoptions.m4'
libtoolize: copying file 'm4/ltsugar.m4'
libtoolize: copying file 'm4/ltversion.m4'
libtoolize: copying file 'm4/lt~obsolete.m4'

[... snipped ...]

libtool: install: /usr/bin/install -c .libs/desktop-shell.lai 
/<>/debian/tmp/usr/lib/x86_64-linux-gnu/weston/desktop-shell.la
libtool: warning: relinking 'fullscreen-shell.la'
libtool: install: (cd /<>; /bin/bash "/<>/libtool"  
--tag CC --mode=relink gcc -Wall -Wextra -Wno-unused-parameter 
-Wno-shift-negative-value -Wno-missing-field-initializers -g 
-fvisibility=hidden -Wstrict-prototypes -Wmissing-prototypes -Wsign-compare 
-I/usr/include/pixman-1 -g -O2 -fdebug-prefix-map=/<>=. 
-fstack-protector-strong -Wformat -Werror=format-security -module 
-avoid-version -Wl,-z,relro -o fullscreen-shell.la -rpath 
/usr/lib/x86_64-linux-gnu/weston fullscreen-shell/la-fullscreen-shell.lo 
protocol/fullscreen_shell_la-fullscreen-shell-unstable-v1-protocol.lo 
libweston-5.la -lwayland-server -lpixman-1 -lxkbcommon -inst-prefix-dir 
/<>/debian/tmp)
libtool: relink: gcc -shared  -fPIC -DPIC  
fullscreen-shell/.libs/la-fullscreen-shell.o 
protocol/.libs/fullscreen_shell_la-fullscreen-shell-unstable-v1-protocol.o   
-L/<>/debian/tmp/usr/lib/x86_64-linux-gnu 
-L/usr/lib/x86_64-linux-gnu -lweston-5 -lwayland-server -lpixman-1 -lxkbcommon  
-g -g -O2 -fstack-protector-strong -Wl,-z -Wl,relro   -Wl,-soname 
-Wl,fullscreen-shell.so -o .libs/fullscreen-shell.so
libtool: install: /usr/bin/install -c .libs/fullscreen-shell.soT 
/<>/debian/tmp/usr/lib/x86_64-linux-gnu/weston/fullscreen-shell.so
libtool: install: /usr/bin/install -c .libs/fullscreen-shell.lai 
/<>/debian/tmp/usr/lib/x86_64-linux-gnu/weston/fullscreen-shell.la
libtool: warning: relinking 'ivi-shell.la'
libtool: install: (cd /<>; /bin/bash "/<>/libtool"  
--tag CC --mode=relink gcc -Wall -Wextra -Wno-unused-parameter 
-Wno-shift-negative-value -Wno-missing-field-initializers -g 
-fvisibility=hidden -Wstrict-prototypes -Wmissing-prototypes -Wsign-compare 
-I/usr/include/pixman-1 -g -O2 -fdebug-prefix-map=/<>=. 
-fstack-protector-strong -Wformat -Werror=format-security -module 
-avoid-version -Wl,-z,relro -o ivi-shell.la -rpath 
/usr/lib/x86_64-linux-gnu/weston ivi-shell/la-ivi-layout.lo 
ivi-shell/la-ivi-layout-transition.lo ivi-shell/la-ivi-shell.lo 
ivi-shell/la-input-panel-ivi.lo 
protocol/ivi_shell_la-ivi-application-protocol.lo libshared.la libweston-5.la 
-lwayland-server -lpixman-1 -lxkbcommon -inst-prefix-dir 
/<>/debian/tmp)
libtool: relink: gcc -shared  -fPIC -DPIC  ivi-shell/.libs/la-ivi-layout.o 
ivi-shell/.libs/la-ivi-layout-transition.o ivi-shell/.libs/la-ivi-shell.o 
ivi-shell/.libs/la-input-panel-ivi.o 
protocol/.libs/ivi_shell_la-ivi-application-protocol.o  -Wl,--whole-archive 
./.libs/libshared.a -Wl,--no-whole-archive  
-L/<>/debian/tmp/usr/lib/x86_64-linux-gnu 
-L/usr/lib/x86_64-linux-gnu -lweston-5 -lwayland-server -lpixman-1 -lxkbcommon  
-g -g -O2 -fstack-protector-strong -Wl,-z -Wl,relro   -Wl,-soname 
-Wl,ivi-shell.so -o .libs/ivi-shell.so
libtool: install: /usr/bin/install -c .libs/ivi-shell.soT 
/<>/debian/tmp/usr/lib/x86_64-linux-gnu/weston/ivi-shell.so
libtool: install: /usr/bin/install -c .libs/ivi-shell.lai 
/<>/debian/tmp/usr/lib/x86_64-linux-gnu/weston/ivi-shell.la
libtool: warning: relinking 'hmi-controller.la'
libtool: install: (cd /<>; /bin/bash "/<>/libtool"  
--tag CC --mode=relink gcc -Wall -Wextra -Wno-unused-parameter 
-Wno-shift-negative-value -Wno-missing-field-initializers -g 
-fvisibility=hidden -Wstrict-prototypes -Wmissing-prototypes -Wsign-compare 
-I/usr/include/pixman-1 -g -O2 -fdebug-prefix-map=/<>=. 
-fstack-protector-strong -Wformat -Werror=format-security -module 
-avoid-version -Wl,-z,relro -o hmi-controller.la -rpath 
/usr/lib/x86_64-linux-gnu/weston ivi-shell/hmi_controller_la-hmi-controller.lo 
protocol/hmi_controller_la-ivi-hmi-controller-protocol.lo libshared.la 
libweston-5.la -lwayland-server -lpixman-1 -lxkbcommon -inst-prefix-dir 
/<>/debian/tmp)
libtool: relink: gcc -shared  -fPIC -DPIC  
ivi-shell/.libs/hmi_controller_la-hmi-controller.o 
protocol/.libs/hmi_controller_la-ivi-hmi-controller-protocol.o  
-Wl,--whole-archive ./.libs/libshared.a -Wl,--no-whole-archive  
-L/<>/debian/tmp/usr/lib/x86_64-linux-gnu 
-L/usr/lib/x86_64-linux-gnu -lweston-5 -lwayland-server -lpixman-1 -lxkbcommon  
-g -g -O2 -fstack-protector-strong -Wl,-z 

Bug#770369: Eterm on Jessie, Stretch and Sid does not run shell (fwd)

[Santiago Vila]

severity 770369 serious
thanks

Hello Debian X maintainers.

Would someone here help (me) to debug this?

Follows an email from a user suggesting the bug could be in the
xserver, or anything which is "below" the package, not in the package
itself, but I can't verify that.

Thanks.

-- Forwarded message --
From: Stamatis Mavrogeorgis 
To: 770...@bugs.debian.org
Date: Sun, 4 Oct 2015 13:41:22 +0100
Subject: Bug#770369: Eterm on Jessie, Stretch and Sid does not run shell

Exact same problem here.
I did some investigation and I can confirm the following:

* Eterm (0.9.6-1) runs properly on AntiX-15 which is based on Jessie.

* I installed (with dpkg) on Jessie the Eterm deb package that runs properly on 
AntiX-15 and Eterm still
exhibits the same erratic behaviour [on Jessie].

* I installed on AntiX-15 the Eterm deb package that behaves erratically on 
Jessie, and it runs properly
[on AntiX-15].

* I repeated the latter two above steps between AntiX-15 and Stretch (testing) 
and AntiX-15 and Sid with
identical results as with AntiX-15 and Jessie: - AntiX-15 runs the Stretch and 
Sid Eterm packages
properly, whereas Stretch and Sid exhibit erratic behaviour on the Eterm 
package brought over from
Antix-15.

The above led me to speculate that there is nothing wrong with the Eterm 
package per se, instead, the
problem seems to lie with Jessie and subsequent (Stretch, Sid) system 
implementations.

Re: Some actions destroy backlite on Lenovo X61s

[Santiago Vila]

reassign 754659 xserver-xorg
severity 754659 normal
thanks

On Sun, 13 Jul 2014, Klaus Ethgen wrote:

> Package: luakit
> Version: 2012.09.13-r1-3
> Severity: critical
> 
> I tagged that bug critical as it has some bad effect to the hardware. I
> am not fully sure where the problem lives in. The only informations that
> I have I will put into this report.
> 
> I use luakit on my laptop, a Lenovo X61s with a intel GM965/GL960
> graphic controller. I am not able to reproduce that bug with any other
> browser or software or any other hardware. As X is involved, I will also
> attach the full Xorg log of a broken session.
> 
> When I use luakit and _load new pages_ it often blanks the screen by
> switching the backlight of. There is no way to switch it back on again
> but with a trick, putting the laptop to sleep and waking it up again, I
> get some backlight back. Some means in this case that only the right
> side is lighted. I have to do a full system restart to get the proper
> backlight back. I do not know if that is good for the hardware or not
> but I do not think that it should be the case that a browser is able to
> destroy hardware.
> 
> I have no idea what does trigger the bug but I fear about using luakit
> on that laptop anymore.
> 
> [...]

luakit is just a web browser and has no direct access to hardware by itself.
I'm reassigning this report to xserver-xorg as the most probably package
to blame, but even in such case, be ready to provide the X maintainers
whatever additional information they might ask you.

Thanks.

Bug#763890: xserver-xorg-video-nouveau: glxinfo crashes my machine

[Santiago Vila]

On Sun, Jan 04, 2015 at 12:46:36PM +0100, Sven Joachim wrote:
 On 2014-10-03 15:26 +0200, Santiago Vila wrote:
 
  Since I upgraded from wheezy to jessie, mesa no longer works ok in my
  machine. When I start stellarium, for example, the screen becomes a
  mosaic and the machine freezes completely.
 
 Sorry for not getting to this bug sooner.  I think it is the same
 problem as #758460, does booting with the nouveau.config=NvMSI=0 kernel
 parameter help?

Looks similar, yes, but unfortunately adding nouveau.config=NvMSI=0
does not make any difference in my case.


-- 
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/20150105124130.ga2...@cantor.unex.es

Bug#763890: xserver-xorg-video-nouveau: glxinfo crashes my machine

[Santiago Vila]

Package: xserver-xorg-video-nouveau
Version: 1:1.0.11-1
Severity: serious

Since I upgraded from wheezy to jessie, mesa no longer works ok in my
machine. When I start stellarium, for example, the screen becomes a
mosaic and the machine freezes completely.

(I'm using severity: serious because this is a regression).

I'm not sure which package is the good one to report this. It could be
mesa-utils, since glxinfo already crashes my machine, but AFAIK the
X server is to blame here.

This is what lspci -v says about my system:

00:0d.0 VGA compatible controller: NVIDIA Corporation C61 [GeForce 6150SE 
nForce 430] (rev a2) (prog-if 00 [VGA controller])
Subsystem: ASUSTeK Computer Inc. Device 8234
Flags: bus master, 66MHz, fast devsel, latency 0, IRQ 43
Memory at de00 (32-bit, non-prefetchable) [size=16M]
Memory at c000 (64-bit, prefetchable) [size=256M]
Memory at dd00 (64-bit, non-prefetchable) [size=16M]
Expansion ROM at dfec [disabled] [size=128K]
Capabilities: [48] Power Management version 2
Capabilities: [50] MSI: Enable+ Count=1/1 Maskable- 64bit+
Kernel driver in use: nouveau

I attach Xorg.0.log as well.

Feel free to ask me whatever additional info you might need to debug this.

Thanks.[28.173] 
X.Org X Server 1.16.1
Release Date: 2014-09-21
[28.173] X Protocol Version 11, Revision 0
[28.173] Build Operating System: Linux 3.2.0-4-amd64 x86_64 Debian
[28.173] Current Operating System: Linux mymachine 3.16-2-amd64 #1 SMP 
Debian 3.16.3-2 (2014-09-20) x86_64
[28.173] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-3.16-2-amd64 
root=UUID=---- ro
[28.173] Build Date: 22 September 2014  09:45:37PM
[28.173] xorg-server 2:1.16.1-1 (http://www.debian.org/support) 
[28.173] Current version of pixman: 0.32.6
[28.173]Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
[28.173] Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[28.173] (==) Log file: /var/log/Xorg.0.log, Time: Fri Oct  3 15:08:50 
2014
[28.189] (==) Using system config directory /usr/share/X11/xorg.conf.d
[28.202] (==) No Layout section.  Using the first Screen section.
[28.202] (==) No screen section available. Using defaults.
[28.202] (**) |--Screen Default Screen Section (0)
[28.202] (**) |   |--Monitor default monitor
[28.202] (==) No monitor specified for screen Default Screen Section.
Using a default monitor configuration.
[28.202] (==) Automatically adding devices
[28.202] (==) Automatically enabling devices
[28.202] (==) Automatically adding GPU devices
[28.232] (WW) The directory /usr/share/fonts/X11/cyrillic does not exist.
[28.232]Entry deleted from font path.
[28.235] (==) FontPath set to:
/usr/share/fonts/X11/misc,
/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,
built-ins
[28.235] (==) ModulePath set to /usr/lib/xorg/modules
[28.235] (II) The server relies on udev to provide the list of input 
devices.
If no devices become available, reconfigure udev or disable 
AutoAddDevices.
[28.235] (II) Loader magic: 0x7f5b165e4d80
[28.235] (II) Module ABI versions:
[28.235]X.Org ANSI C Emulation: 0.4
[28.235]X.Org Video Driver: 18.0
[28.235]X.Org XInput driver : 21.0
[28.235]X.Org Server Extension : 8.0
[28.235] (II) xfree86: Adding drm device (/dev/dri/card0)
[28.236] (--) PCI:*(0:0:13:0) 10de:03d0:1043:8234 rev 162, Mem @ 
0xde00/16777216, 0xc000/268435456, 0xdd00/16777216, BIOS @ 
0x/131072
[28.239] (II) LoadModule: glx
[28.257] (II) Loading /usr/lib/xorg/modules/extensions/libglx.so
[28.507] (II) Module glx: vendor=X.Org Foundation
[28.507]compiled for 1.16.1, module version = 1.0.0
[28.507]ABI class: X.Org Server Extension, version 8.0
[28.507] (==) AIGLX enabled
[28.507] (==) Matched nouveau as autoconfigured driver 0
[28.507] (==) Matched nv as autoconfigured driver 1
[28.507] (==) Matched nouveau as autoconfigured driver 2
[28.507] (==) Matched nv as autoconfigured driver 3
[28.507] (==) Matched modesetting as autoconfigured driver 4
[28.507] (==) Matched fbdev as autoconfigured driver 5
[28.507] (==) Matched vesa as autoconfigured driver 6
[28.507] (==) Assigned the driver to the xf86ConfigLayout
[28.507] (II) LoadModule: nouveau
[28.507] (II) Loading /usr/lib/xorg/modules/drivers/nouveau_drv.so
[28.529] (II) Module nouveau: vendor=X.Org Foundation
[28.529]compiled for 1.16.0, 

Bug#145797: xserver-xfree86 changes keyboard repeat settings

[Santiago Vila]

On Sat, 22 Dec 2007, Brice Goglin wrote:

 Santiago Vila wrote:
  Last time I checked (etch) the bug was still there.
  
  The fact that I didn't have a system running lenny to check this bug
  does not make the bug to disappear. So please don't close bugs 
  gratuitously. 
 
 The fact that you never replier to Julien's question 5 months ago
 and the message I used to close were perfectly fine here. If you want
 us to take good care of your reports, you have to help us too.

No, it's not fine to close a bug without doing anything at all to fix it.

It's the duty of the maintainer to reproduce the bug, and it seems you
have not even tried to. You seem to have the perfect recipe for
closing all your bugs without doing anythhing:

1. A bug is received.
2. You wait five years without doing anything at all.
3. After five years you ask the submitter is it still the case?
4. The submitter does not reply in five months, and you take this as
a (very poor, IMHO) excuse to close the bug.

For someone who took the time to write a bug report, it is irritating
to see how little work the maintainer did on his side.

  At the very minimum, you should
  try to reproduce the bug yourself (which is not specially difficult in
  this case)
 
 I don't see any problem on my machines running unstable. But this kind
 of things might well depend on the hardware.

Well, I have been able to reproduce it on almost every computer I have
had access to (i.e. on every new etch install I remember).

I'll try to reproduce this on lenny, if I have a little bit of time,
but I think this bug is not particularly difficult to reproduce and I
expected the maintainers to do so.



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#145797: xserver-xfree86 changes keyboard repeat settings

[Santiago Vila]

On Sun, 23 Dec 2007, Julien Cristau wrote:

 On Sun, Dec 23, 2007 at 13:47:44 +0100, Santiago Vila wrote:
 
  No, it's not fine to close a bug without doing anything at all to fix it.

 If you're the only one who reproduces this and cares about it, and you
 don't reply to queries about the bug's status, then it's perfectly fine
 to close it imo.

If I'm the only one who reproduces this it's not because my machine is
special, it's because the maintainer never bothered to reproduce it by
himself. That's not perfectly fine, it's wrong. The very first thing a
maintainer should do is to reproduce bugs, not wait five years before
asking the submitter do you still reproduce it?.

 Keeping very old bugs open simply because the submitter doesn't
 reply is utterly pointless.

You seem to imply that bugs which are old enough are magically fixed by
themselves, which is wrong.

I don't want to mean that a bug should be kept open because the submitter
does not reply, I mean that a bug should be closed when it's *fixed*.


Did you ever heard about the scientific method?

The bug was present when it was submitted. If you want to close it,
you should prove in some way that it's fixed, not me.



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#145797: xserver-xfree86 changes keyboard repeat settings

[Santiago Vila]

On Sun, 23 Dec 2007, Brice Goglin wrote:

 Santiago Vila wrote:
  No, it's not fine to close a bug without doing anything at all to fix it.
  It's the duty of the maintainer to reproduce the bug,

 
 You are not going to tell me what I need to do. I am not paid to do this, I
 try to do my best in my free time and I have several hundreds of bugs to take
 care of. If you are not happy with this I am not going to cry, I can leave
 with it. If you think it is so easy to fix the bug, just go ahead and write a
 patch instead of complaining like this and not bringing any single piece of
 help.

Please calm down and don't put things in my mouth which I never said.
I never said it would be easy to fix this bug. I just believe it would be
easy to *reproduce* (but I can be wrong, of course).

Bear in mind that I am not paid to report bugs either, or to fix bugs
in my own packages, and I also have a lot of bugs to fix. I just think we
should only close a bug after checking that it's fixed, that's all.

 Given how you consider my work, it is clear that I am not going to
 spend a lot of my time for your bug report.

That's ok, as everybody decides what to do in his free time, and I was
not asking you to fix the bug, only to leave it open until it's fixed.

 We have a lot of people
 with a completely broken X server and they are still nice with me
 when I ask them to test a lot of things. Obviously, trying to help
 them is much more interesting than trying to explain you how you
 deal with bug reports (which obviously you don't know at all).

Sorry, I don't understand the word obviously here. A bug is normally
closed when it's fixed, not before. If we (Debian) can't agree on such
elementary principle, we have a problem (maybe not bigger than a
broken X server, agreed, but an important one).

In either case, please go ahead and prioritize your tasks as you see
they fit. I'll try to do the same.

Thanks.



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#145797: closed by Brice Goglin [EMAIL PROTECTED] (Re: Bug#145797: xserver-xfree86 changes keyboard repeat settings)

[Santiago Vila]

reopen 145797
thanks

Last time I checked (etch) the bug was still there.

The fact that I didn't have a system running lenny to check this bug
does not make the bug to disappear.

So please don't close bugs gratuitously. At the very minimum, you should
try to reproduce the bug yourself (which is not specially difficult in
this case) and you should also know what version and how the bug was
fixed, if it was fixed at all, which is yet to be seen.



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

/usr/X11R6/lib64 symlink for amd64

[Santiago Vila]

Hello.

The amd64 porters have asked me that I add several symlinks to base-files
(see Bug #259302) for the amd64 architecture. As base-files itself does
not even contain the /usr/X11R6/lib directory on the other architectures,
I consider adding /usr/X11R6/lib64 to base-files an ugly hack.

Would the X maintainers be willing to add the /usr/X11R6/lib64 symlink
to the xfree86-common package? I think it would be much more suitable.

Thanks.

Re: potato's apt makes the wrong decisions on dist-upgrade

[Santiago Vila]

Colin Watson wrote:
 There've been quite a few people coming to the debian-user list recently
 with the problem that packages like man-db and xbase-clients go missing
 when upgrading from potato to woody using 'apt-get dist-upgrade' with
 potato's apt. I had been advising people to upgrade dpkg and apt to the
 versions in woody first, which does seem to fix those problems, but at
 the cost of removing other packages along the way which the user will
 have to reinstall - so it only helps to some extent, and may not be
 something we can recommend.

 What can we do about this? [...]

In the CD1 for potato there is an `upgrade' directory containing a
recent dpkg and a recent apt.

We can (and probably should) do the same for woody CDs, i.e. provide
a recent version of apt compiled under potato. This would be much
better than nothing.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: potato's apt makes the wrong decisions on dist-upgrade

[Santiago Vila]

Colin Watson wrote:
 There've been quite a few people coming to the debian-user list recently
 with the problem that packages like man-db and xbase-clients go missing
 when upgrading from potato to woody using 'apt-get dist-upgrade' with
 potato's apt. I had been advising people to upgrade dpkg and apt to the
 versions in woody first, which does seem to fix those problems, but at
 the cost of removing other packages along the way which the user will
 have to reinstall - so it only helps to some extent, and may not be
 something we can recommend.

 What can we do about this? [...]

In the CD1 for potato there is an `upgrade' directory containing a
recent dpkg and a recent apt.

We can (and probably should) do the same for woody CDs, i.e. provide
a recent version of apt compiled under potato. This would be much
better than nothing.

Re: dialog version dependency for dexter

[Santiago Vila]

On Thu, 2 Nov 2000, Branden Robinson wrote:

 On Thu, Nov 02, 2000 at 03:01:12PM -0500, David I. Lehn wrote:
  dexter needs to depend on a recent version of dialog.  I was installing
  on a machine with an old dialog version (sorry, not sure which) that
  didn't have the --nocancel option and dexter dies on this.  An upgrade
  of dialog fixed it.
 
 Okay, thanks for mentioning this.
 
 I *think* the proper version to depend on is 0.9a-2425-1.
 
 Santiago, can you confirm this, please?

Yes, this is correct.