Bug#935969: linux-image-5.2.0-2-amd64: Missing firmware for new driver rtwpci
Package: src:linux Version: 5.2.9-2 Severity: normal Dear Maintainer, My laptop has a Realtek Wifi card identified as such by lspci: 04:00.0 Network controller: Realtek Semiconductor Co., Ltd. RTL8822BE 802.11a/b/g/n/ac WiFi adapter (PCI IDs are 10ec:b822) I'm currnetly using a 5.1.0 kernel compiled from source, under which this card uses the r8822be driver, and works fine. (The reason I'm using a custom kernel is the MMC card reader, whose driver was buggy in the stock kernel previously shipped by Debian, but I'm pretty sure said stock kernel also used the same driver and that the Wifi card worked.) I now upgraded to the 5.2.0-2 kernel in the repos, which appears to be using a new driver for this card, called rtwpci. As indicated in the subject, this driver requires firmware which is not present, and which does not appear to exist in any free or non-free package: Aug 28 15:13:44 wolf kernel: [ 94.051293] rtw_pci :04:00.0: firmware: failed to load rtw88/rtw8822b_fw.bin (-2) Aug 28 15:13:44 wolf kernel: [ 94.052482] rtw_pci :04:00.0: Direct firmware load for rtw88/rtw8822b_fw.bin failed with error -2 Aug 28 15:13:44 wolf kernel: [ 94.053714] rtw_pci :04:00.0: failed to request firmware Aug 28 15:13:44 wolf kernel: [ 94.060506] rtw_pci :04:00.0: failed to load firmware Aug 28 15:13:44 wolf kernel: [ 94.061764] rtw_pci :04:00.0: failed to setup chip efuse info Aug 28 15:13:44 wolf kernel: [ 94.063027] rtw_pci :04:00.0: failed to setup chip information Aug 28 15:13:44 wolf kernel: [ 94.066942] rtw_pci: probe of :04:00.0 failed with error -22 I did find a firmware file by that name on some random site that didn't seem too sketchy, and tried using it, but apparently to no avail: Aug 28 15:33:21 wolf kernel: [ 1217.459956] rtw_pci :04:00.0: firmware: direct-loading firmware rtw88/rtw8822b_fw.bin Aug 28 15:33:21 wolf kernel: [ 1217.463521] rtw_pci :04:00.0: mac power on failed Aug 28 15:33:21 wolf kernel: [ 1217.463530] rtw_pci :04:00.0: failed to power on mac Aug 28 15:33:21 wolf kernel: [ 1217.463532] rtw_pci :04:00.0: failed to setup chip efuse info Aug 28 15:33:21 wolf kernel: [ 1217.463535] rtw_pci :04:00.0: failed to setup chip information Aug 28 15:33:21 wolf kernel: [ 1217.464711] rtw_pci: probe of :04:00.0 failed with error -114 Whether that's due to some other technical issue or because the file I downloaded was the wrong one somehow, I have no way to tell. Anyway, if the appropriate firmware cannot be found or otherwise included, I would suggest disabling this rtwpci driver and revert to the r8822be driver, if possible. -- Fredrik Tolf -- Package-specific info: ** Kernel log: boot messages should be attached ** Model information sys_vendor: LENOVO product_name: 20NECTO1WW product_version: ThinkPad E495 chassis_vendor: LENOVO chassis_version: None bios_vendor: LENOVO bios_version: R11ET25W (1.05 ) board_vendor: LENOVO board_name: 20NECTO1WW board_version: Not Defined ** PCI devices: 00:00.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Raven/Raven2 Root Complex [1022:15d0] Subsystem: Advanced Micro Devices, Inc. [AMD] Raven/Raven2 Root Complex [1022:15d0] Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- SERR- 00:01.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Family 17h (Models 00h-1fh) PCIe Dummy Host Bridge [1022:1452] Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- SERR- TAbort- Reset- FastB2B- PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn- Capabilities: Kernel driver in use: pcieport 00:01.2 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Raven/Raven2 PCIe GPP Bridge [6:0] [1022:15d3] (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- FastB2B- PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn- Capabilities: Kernel driver in use: pcieport 00:01.3 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Raven/Raven2 PCIe GPP Bridge [6:0] [1022:15d3] (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- FastB2B- PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn- Capabilities: Kernel driver in use: pcieport 00:01.6 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Raven/Raven2 PCIe GPP
Bug#794537: 0.112.0-3 introduce unneeded hard dependency
I just wanted to add that I, too, got bitten by this when I recently upgraded one of my systems from Jessie to Stretch. The suggested fix seems reasonable to me. -- Fredrik Tolf
Bug#833182: xserver-xorg-core regression on Intel HD Graphics: drmSetMaster(): Permission denied
Package: xserver-xorg-core Version: 2:1.18.4-1 Severity: important Dear Maintainer, I just upgraded my laptop running Testing, and after the upgrade, the X server would no longer start. The upgrade involved quite a few packages, so I'm admittedly not sure if xserver-xorg-core is the right place to look, but the evidence seems to suggest it. Before the upgrade, Xorg automatically decided to use the intel(4) driver for the built-in graphics in my Core i3 M370, but after the upgrade it instead decided to use the modesetting(4) driver, which in turned failed with the message that drmSetMaster() failed with EACCES. I'm really not proficient enough in the complexity that is Xorg to properly determine what is the "core" error here, but it seems to be one or both of the following: 1) The wrong driver was detected (even if the modesetting driver worked, it seems it would be suboptimal for performance reasons). 2) The modesetting driver doesn't have the privileges it needs. As for modesetting privileges, I'm guessing it would have worked if I had made /usr/bin/Xorg SUID root as it used to be in the past, but since it is no longer installed as SUID root by default, I'm also guessing that the idea is that it shouldn't need to be. I can't tell if this is: 1) A bug in the modesetting driver for requiring permissions it doesn't have; 2) A bug in the kernel for requiring root privileges for DRM_IOCTL_SET_MASTER even though the appropriate /dev/dri files are readable and writable for the user in question; or 3) A bug in the xserver-xorg-core package for not installing Xorg as SUID root. But surely, at least one of the above must be considered a bug since Xorg doesn't work without proper tweaking. In the end, I solved the problem by specifying to use the intel(4) driver via /etc/X11/xorg.conf, but I'm assuming the idea is that that shouldn't be necessary these days. -- Package-specific info: X server symlink status: lrwxrwxrwx 1 root root 13 Dec 29 2010 /etc/X11/X -> /usr/bin/Xorg -rwxr-xr-x 1 root root 274 Jul 20 05:00 /usr/bin/Xorg VGA-compatible devices on PCI bus: -- 00:02.0 VGA compatible controller [0300]: Intel Corporation Core Processor Integrated Graphics Controller [8086:0046] (rev 02) Xorg X server configuration file status: -rw-r--r-- 1 root root 1095 Aug 1 22:00 /etc/X11/xorg.conf Contents of /etc/X11/xorg.conf: --- # xorg.conf (X.Org X Window System server configuration file) # # This file was generated by dexconf, the Debian X Configuration tool, using # values from the debconf database. # # Edit this file with caution, and see the xorg.conf manual page. # (Type "man xorg.conf" at the shell prompt.) # # This file is automatically updated on xserver-xorg package upgrades *only* # if it has not been modified since the last upgrade of the xserver-xorg # package. # # If you have edited this file but would like it to be automatically updated # again, run the following command: # sudo dpkg-reconfigure -phigh xserver-xorg Section "InputDevice" Identifier "Generic Keyboard" Driver "kbd" Option "XkbRules" "xorg" Option "XkbModel" "pc104" Option "XkbLayout" "us" EndSection Section "InputDevice" Identifier "Configured Mouse" Driver "mouse" EndSection Section "Device" Identifier "Configured Video Device" Driver "intel" EndSection Section "Monitor" Identifier "Configured Monitor" EndSection Section "Screen" Identifier "Default Screen" Monitor "Configured Monitor" EndSection /etc/X11/xorg.conf.d does not exist. KMS configuration files: /etc/modprobe.d/i915-kms.conf: options i915 modeset=1 /etc/modprobe.d/radeon-kms.conf: options radeon modeset=1 Kernel version (/proc/version): --- Linux version 4.6.0-1-amd64 (debian-ker...@lists.debian.org) (gcc version 5.4.0 20160609 (Debian 5.4.0-6) ) #1 SMP Debian 4.6.4-1 (2016-07-18) Xorg X server log files on system: -- -rw-r--r-- 1 root root 49671 Jun 21 2011 /var/log/Xorg.1.log -rw-r--r-- 1 root root 40408 Nov 12 2015 /var/log/Xorg.0.log Contents of most recent Xorg X server log file (/var/log/Xorg.0.log): - [ 528.023] X.Org X Server 1.17.3 Release Date: 2015-10-26 [ 528.027] X Protocol Version 11, Revision 0 [ 528.029] Build Operating System: Linux 3.16.0-4-amd64 x86_64 Debian [ 528.030] Current Operating System: Linux wolf 4.2.0-1-amd64 #1 SMP Debian 4.2.5-1 (2015-10-27) x86_64 [ 528.030] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-4.2.0-1-amd64 root=UUID=fabe2750-8f02-413d-9f8e-59e4951fbaa5 ro [ 528.033] Build Date: 27 October 2015 11:41:02PM [
Bug#766707: libgtk-3-0: Mouse scroll wheel not working in GTK 3
Package: libgtk-3-0 Version: 3.14.4-1 Severity: important Dear Maintainer, Since sometime in the GTK-3 series (it's been this way for a while, so I do not remember exactly when it started), mouse wheel scrolling has not been working. I believe this is different from #716959, since it only seems to discuss, mouse-wheel scrolling not working in content areas, while still working with the pointer placed on the scrollbar itself, and also seems to be limited to window-managers using the mouse-wheel to switch workspaces. The problem I'm experiencing is that it isn't working at all, and I don't have the mouse-wheel bound in the window manager anyhow. On the other hand, setting the GDK_CORE_DEVICE_EVENTS environment variable to 1 makes the problem disappear. I cannot say that I know the root cause for this problem, unfortunately. There also seem to be several bugs related to mouse-wheel scrolling in GTK 3 floating around the web, many of them seemingly confused with each other, and I just happened to find this work-around without any sources or reasons cited, at https://bugs.archlinux.org/task/35348. (However, it seems to be confused with a bug in the Oxygen theme, which I do not use.) I'm having this problem both with the Testing and Unstable versions of GTK3. -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing'), (99, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.14-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libgtk-3-0 depends on: ii libatk-bridge2.0-0 2.14.0-2 ii libatk1.0-0 2.14.0-1 ii libc62.19-11 ii libcairo-gobject21.14.0-2 ii libcairo21.14.0-2 ii libcolord2 1.2.1-1+b1 ii libcups2 1.7.5-5 ii libfontconfig1 2.11.0-6.1 ii libfreetype6 2.5.2-2 ii libgdk-pixbuf2.0-0 2.31.1-2+b1 ii libglib2.0-0 2.42.0-2 ii libgtk-3-common 3.14.4-1 ii libjson-glib-1.0-0 1.0.2-1 ii libpango-1.0-0 1.36.8-2 ii libpangocairo-1.0-0 1.36.8-2 ii libpangoft2-1.0-01.36.8-2 ii librest-0.7-00.7.92-1 ii libsoup2.4-1 2.48.0-1 ii libwayland-client0 1.6.0-2 ii libwayland-cursor0 1.6.0-2 ii libx11-6 2:1.6.2-3 ii libxcomposite1 1:0.4.4-1 ii libxcursor1 1:1.1.14-1 ii libxdamage1 1:1.1.4-2 ii libxext6 2:1.3.3-1 ii libxfixes3 1:5.0.1-2 ii libxi6 2:1.7.4-1 ii libxinerama1 2:1.1.3-1 ii libxkbcommon00.4.3-2 ii libxml2 2.9.1+dfsg1-4 ii libxrandr2 2:1.4.2-1 ii multiarch-support2.19-11 ii shared-mime-info 1.3-1 Versions of packages libgtk-3-0 recommends: ii hicolor-icon-theme 0.13-1 ii libgtk-3-bin3.14.3-1 Versions of packages libgtk-3-0 suggests: pn gvfs none ii librsvg2-common 2.40.4-1 -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#763559: libc6: Memory leak with dlopen() and thread-local storage variables
Package: libc6 Version: 2.13-38+deb7u4 Severity: important Dear Maintainer, There is a bug with the eglibc included in Wheezy that causes thread-local variables introduced by dlopen()'ed objects not to be properly freed. This can be a problem in any C program that loads a C++ module and runs threads in it, since libstdc++ introduces a thread-local variable for exception handling. The issue is described at glibc's bugzilla at this URL: https://sourceware.org/bugzilla/show_bug.cgi?id=12650 It includes a working test-case and a link to the commit which fixed the issue: http://repo.or.cz/w/glibc.git/commitdiff/e6c61494125126d2ba77e5d99f83887a2ed49783 This bug report over GCC describes the interaction with libcstd++: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39366 I have confirmed that this bug does not exist in Jessie. It would be a very Nice Thing if the fix could be backported to Wheezy, but I'm not familiar enough with the Policy to tell if this is feasible. In the meantime, I'll be restarting my HTTP server once a day. ;) -- System Information: Debian Release: 7.6 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.10.5 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libc6 depends on: ii libc-bin 2.13-38+deb7u4 ii libgcc1 1:4.7.2-5 libc6 recommends no packages. Versions of packages libc6 suggests: ii debconf [debconf-2.0] 1.5.49 ii glibc-doc 2.13-38+deb7u4 ii locales2.13-38+deb7u4 ii locales-all [locales] 2.13-38+deb7u4 -- debconf information: glibc/upgrade: true glibc/disable-screensaver: glibc/restart-failed: * glibc/restart-services: spamassassin sendmail openbsd-inetd dovecot cups cron atd * libraries/restart-without-asking: false -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#744258: python3.2: importlib breaks on read-only directories
Package: python3.2 Version: 3.2.3-7 Severity: important Dear Maintainer, It appears that the importlib implementation that ships with Python3.2 breaks on directories in which it cannot create a __pycache__ directory. This is unlike the standard import implementation which simply loads the files without caching their compiled versions. Steps to demonstrate: $ mkdir test $ touch test/foo.py $ touch test/__init__.py $ chmod 555 test $ PYTHONPATH=$PWD python3 import importlib importlib.import_module(test.foo) Traceback (most recent call last): File stdin, line 1, in module File /usr/lib/python3.2/importlib/__init__.py, line 124, in import_module return _bootstrap._gcd_import(name[level:], package, level) File /usr/lib/python3.2/importlib/_bootstrap.py, line 807, in _gcd_import _gcd_import(parent) File /usr/lib/python3.2/importlib/_bootstrap.py, line 821, in _gcd_import loader.load_module(name) File /usr/lib/python3.2/importlib/_bootstrap.py, line 436, in load_module return self._load_module(fullname) File /usr/lib/python3.2/importlib/_bootstrap.py, line 141, in decorated return fxn(self, module, *args, **kwargs) File /usr/lib/python3.2/importlib/_bootstrap.py, line 330, in _load_module code_object = self.get_code(name) File /usr/lib/python3.2/importlib/_bootstrap.py, line 423, in get_code self.set_data(bytecode_path, data) File /usr/lib/python3.2/importlib/_bootstrap.py, line 481, in set_data _os.mkdir(parent) OSError: [Errno 13] Permission denied: 'test/__pycache__' As an aside, it also seems that importing importlib makes it install itself over the standard import implementation, therefore making all standard imports fail thereafter, as well. -- Fredrik Tolf -- System Information: Debian Release: 7.4 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.14.0 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages python3.2 depends on: ii libbz2-1.0 1.0.6-4 ii libc6 2.13-38+deb7u1 ii libdb5.1 5.1.29-5+dolda1 ii libffi53.0.10-3 ii libgcc11:4.7.2-5 ii libncursesw5 5.9-10 ii libreadline6 6.2+dfsg-0.1 ii libsqlite3-0 3.7.13-1+deb7u1 ii libssl1.0.01.0.1e-2+deb7u6 ii libtinfo5 5.9-10 ii mime-support 3.52-1 ii python3.2-minimal 3.2.3-7 python3.2 recommends no packages. Versions of packages python3.2 suggests: ii binutils 2.22-8 pn python3.2-doc none -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#740697: libc6: fopencookie() does not work as documented
Just as a simple test-case that the behavior is as I described, I wrote a simple test-case: http://www.dolda2000.com/~fredrik/tmp/fopencookie.c If WRITE_ALL is set to 1, the program correctly indicates that all 65536 bytes have been written properly, but if it is set to 0, only 512 bytes are written. -- Fredrik Tolf -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#740697: libc6: fopencookie() does not work as documented
Source: libc6 Version: 2.17-97 Severity: normal Dear Maintainer, The libc6 manpage on fopencookie() says, with regards to the writer function in the cookie_io_functions_t, that As its function result, the write function should return the number of bytes copied from buf, or 0 on error. Similarly, the Texinfo manual says that Your function should transfer up to SIZE bytes from the buffer, and return the number of bytes written. This seems to imply that the writer function is supposed to work similar to write(2) and may choose to consume less data than is passed to it, and return how much data it did in fact consume. However, when I actually do this, libc seems to consider that an error and the stream stops working. As soon as I change my writer function so that it does consume all the data in the buffer, my program starts working as expected. I can't say I know if it's the code or the documentation which is wrong, but at least one of them seems to be in error. -- Fredrik Tolf -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing'), (99, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.12-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#740131: libc6: Add support for SIGINFO
Source: libc6 Severity: wishlist I'm not entirely sure which package to file this against, but libc seems like a good place to start. FreeBSD has support for the SIGINFO signal which, by default, can be sent to any terminal by typing ^T, akin to how SIGINT is sent by typing ^C. It is ignored by processes by default, but can be used to make an asynchronous request to display info for long-running operations, which is a nice thing. For example, it is used by dd in a manner similar to how GNU dd uses SIGUSR1; but the nice thing is that a) it can be sent easily with a terminal keypress and b) it's there for that purpose, so any program can use it without conflicting with other signal usage. It would be a very Nice Thing if GNU/Linux could support this. I know this is not a Debian-specific issue, but since it's a more OS-wide issue not bound to any particular package, I though this would be a good way to handle it. In the first instance, I'd like to know if there is any resistance against this kind of change. Otherwise, I'll investigate writing the necessary code myself. -- Fredrik Tolf -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing'), (99, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.12-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#737841: libgl1-mesa-swx11: glXGetFBConfigs returns a list of configs that contains NULLs
Package: libgl1-mesa-swx11 Version: 8.0.5-4+deb7u2 Severity: important Dear Maintainer, I discovered that the libGL.so.1 that comes with libgl1-mesa-swx11 contains a bug that may cause it to return a list of GLXFBConfigs that contain NULLs, in violation of the API. The reason is that Fake_glXGetFBConfigs, in src/mesa/drivers/x11/fakeglx.c, maps all the X visuals it gets from XGetVisualInfo via create_glx_visual in order to create its returned list, but create_glx_visual may return NULL if an X visual is unfit for GL. Clearly, it should avoid putting those NULLs in the returned list. You can see the results of this in the output of glxinfo, included below. Some of the GLXFBConfigs (the 1st and 3rd in the list) contain only zeroes for all their attributes, which is the result of glxinfo passing those NULL FBConfigs through glXGetFBConfigAttrib (and not checking its return value). Admittedly, this is on stable, and I can only assume the bug is fixed in later Mesa versions, but I think the bug is grave enough that it should be fixed on stable. I don't see how libgl1-mesa-swx11 can possible be usable under these circumstances, unless one is so lucky so as to only happen to have X visuals that are all usable for GL. -- Fredrik Tolf -- Package-specific info: glxinfo: name of display: :6 display: :6 screen: 0 direct rendering: Yes server glx vendor string: Brian Paul server glx version string: 1.4 Mesa 8.0.5 server glx extensions: GLX_MESA_copy_sub_buffer, GLX_MESA_pixmap_colormap, GLX_MESA_release_buffers, GLX_ARB_get_proc_address, GLX_EXT_texture_from_pixmap, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer client glx vendor string: Brian Paul client glx version string: 1.4 Mesa 8.0.5 client glx extensions: GLX_MESA_copy_sub_buffer, GLX_MESA_pixmap_colormap, GLX_MESA_release_buffers, GLX_ARB_get_proc_address, GLX_EXT_texture_from_pixmap, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer GLX version: 1.4 GLX extensions: GLX_MESA_copy_sub_buffer, GLX_MESA_pixmap_colormap, GLX_MESA_release_buffers, GLX_ARB_get_proc_address, GLX_EXT_texture_from_pixmap, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer OpenGL vendor string: Brian Paul OpenGL renderer string: Mesa X11 OpenGL version string: 2.1 Mesa 8.0.5 OpenGL shading language version string: 1.20 OpenGL extensions: GL_ARB_multisample, GL_EXT_abgr, GL_EXT_bgra, GL_EXT_blend_color, GL_EXT_blend_minmax, GL_EXT_blend_subtract, GL_EXT_copy_texture, GL_EXT_polygon_offset, GL_EXT_subtexture, GL_EXT_texture_object, GL_EXT_vertex_array, GL_EXT_compiled_vertex_array, GL_EXT_texture, GL_EXT_texture3D, GL_IBM_rasterpos_clip, GL_ARB_point_parameters, GL_EXT_draw_range_elements, GL_EXT_packed_pixels, GL_EXT_point_parameters, GL_EXT_rescale_normal, GL_EXT_separate_specular_color, GL_EXT_texture_edge_clamp, GL_SGIS_generate_mipmap, GL_SGIS_texture_border_clamp, GL_SGIS_texture_edge_clamp, GL_SGIS_texture_lod, GL_ARB_multitexture, GL_IBM_multimode_draw_arrays, GL_IBM_texture_mirrored_repeat, GL_3DFX_texture_compression_FXT1, GL_ARB_texture_cube_map, GL_ARB_texture_env_add, GL_ARB_transpose_matrix, GL_EXT_blend_func_separate, GL_EXT_fog_coord, GL_EXT_multi_draw_arrays, GL_EXT_secondary_color, GL_EXT_texture_env_add, GL_EXT_texture_filter_anisotropic, GL_EXT_texture_lod_bias, GL_INGR_blend_func_separate, GL_MESA_resize_buffers, GL_NV_blend_square, GL_NV_light_max_exponent, GL_NV_texgen_reflection, GL_NV_texture_env_combine4, GL_SUN_multi_draw_arrays, GL_ARB_texture_border_clamp, GL_ARB_texture_compression, GL_EXT_framebuffer_object, GL_EXT_texture_env_combine, GL_EXT_texture_env_dot3, GL_MESA_window_pos, GL_NV_packed_depth_stencil, GL_NV_texture_rectangle, GL_NV_vertex_program, GL_ARB_depth_texture, GL_ARB_occlusion_query, GL_ARB_shadow, GL_ARB_shadow_ambient, GL_ARB_texture_env_combine, GL_ARB_texture_env_crossbar, GL_ARB_texture_env_dot3, GL_ARB_texture_mirrored_repeat, GL_ARB_window_pos, GL_ATI_envmap_bumpmap, GL_ATI_fragment_shader, GL_EXT_stencil_two_side, GL_EXT_texture_cube_map, GL_NV_depth_clamp, GL_NV_fragment_program, GL_NV_point_sprite, GL_NV_vertex_program1_1, GL_APPLE_packed_pixels, GL_APPLE_vertex_array_object, GL_ARB_draw_buffers, GL_ARB_fragment_program, GL_ARB_fragment_shader, GL_ARB_shader_objects, GL_ARB_vertex_program, GL_ARB_vertex_shader, GL_ATI_draw_buffers, GL_ATI_texture_env_combine3, GL_EXT_depth_bounds_test, GL_EXT_shadow_funcs, GL_EXT_stencil_wrap, GL_MESA_pack_invert, GL_MESA_ycbcr_texture, GL_ARB_depth_clamp, GL_ARB_fragment_program_shadow, GL_ARB_half_float_pixel, GL_ARB_occlusion_query2, GL_ARB_point_sprite, GL_ARB_shading_language_100, GL_ARB_sync, GL_ARB_texture_non_power_of_two, GL_ARB_vertex_buffer_object, GL_ATI_blend_equation_separate
Bug#737370: mkdir: directories created with weird mode when -p is used
On Sat, 1 Feb 2014, Bob Proulx wrote: Fredrik Tolf wrote: I can't really imagine that this behavior is intended, and it seems to go against any reasonable principle of least surprise. It is intended because that is the way traditional legacy Unix systems have always behaved. And because that is the legacy behavior it is required by POSIX for reasons of legacy portability. http://pubs.opengroup.org/onlinepubs/009695399/utilities/mkdir.html Huh, I was not aware of that. One might argue that it should be mentioned in the manpage then, though; but I see that the texinfo manual does mention it, so perhaps that's intentional. Can you produce a small test case that illustrates the ACL behavior? Sure, here: $ mkdir /tmp/a $ cd /tmp/a $ setfacl -m d:g::rwx . $ mkdir b $ mkdir -p c $ ls -l total 8 drwxrwxr-x+ 2 fredrik users 4096 Feb 2 10:38 b drwxr-xr-x+ 2 fredrik users 4096 Feb 2 10:38 c Ideally, b and c should be created with the same permissions. It should be mentioned that what I would consider the expected behavior, and the behavior specified by POSIX would both be obtained if mkdir simply does not attempt to do anything special with the mode and/or umask whenever ((umask 0300) == 0), the most common case anyway. Or, alternatively, just sets the umask to (umask ~0300) before doing the -p operation. If you wish a behavior change with regards to ACLs would you be so kind as to request it upstream at coreut...@gnu.org? Sure, I could do that, but I was under the impression that Debian generally preferred to handle bug reports internally. Was I mistaken about that? -- Fredrik Tolf -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#737370: mkdir: directories created with weird mode when -p is used
Package: coreutils Version: 8.21-1 Severity: normal Dear Maintainer, Apparently, mkdir uses 0755 when used with the -p option to create multiple levels of directories in one go. Normally, 0777 would be, though masked to 0755 with the default umask. I can't really imagine that this behavior is intended, and it seems to go against any reasonable principle of least surprise. (I discovered this specifically with directories that had been given an ACL with setfacl -m d:g::rwx to make directory trees group-writable by default, and this behavior makes mkdir ignore that ACL modification when -p is used.) -- Fredrik Tolf -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing'), (99, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.12-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages coreutils depends on: ii libacl1 2.2.52-1 ii libattr1 1:2.4.47-1 ii libc62.17-97 ii libselinux1 2.2.2-1 coreutils recommends no packages. coreutils suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#735137: gnucash: Enter/double-click no longer opens account with subaccounts in 2.6.0
On Tue, 28 Jan 2014, Sébastien Villemot wrote: Hi, Hi! Does that make the bug fixed for you? Yes, that works to great effect. Thanks! What is the etiquette in the BTS in these cases, by the way? Should I close the bug with this message, or should I allow you to close it? -- Fredrik Tolf
Bug#735137: gnucash: Enter/double-click no longer opens account with subaccounts in 2.6.0
Package: gnucash Version: 1:2.6.0-1 Severity: normal Dear Maintainer, With the latest update of gnucash in Jessie (from 2.4.2 to 2.6.0), typing Enter or double-clicking in the account list on an account that has subaccounts no longer opens the account, but merely collapses or expands the list of subaccounts. In order to actually open the account, one must instead go via the menu (Edit-Open account), which quickly gets annoying for commonly used accounts. Perhaps I'm mistaken, but I'm imagining this was merely changed by mistake somehow, and if so, it would be nice to have the old behavior back. Perhaps this bug should be considered minor, but I do find it quite disturbing. I trust you'll change it at your own discretion. :) -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing'), (99, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.12-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages gnucash depends on: ii gnucash-common 1:2.6.0-1 ii guile-2.0 2.0.9+1-1 ii guile-2.0-libs 2.0.9+1-1 ii libaqbanking34 5.1.0beta-1 ii libc6 2.17-97 ii libcairo2 1.12.16-2 ii libcrypt-ssleay-perl 0.58-1+b1 ii libdate-manip-perl 6.42-1 ii libdbi10.8.4-6 ii libfinance-quote-perl 1.18-1 ii libgdk-pixbuf2.0-0 2.28.2-1+b1 ii libglib2.0-0 2.36.4-1 ii libgnome-keyring0 3.4.1-1 ii libgnomecanvas2-0 2.30.3-2 ii libgoffice-0.8-8 0.8.17-3 ii libgtk2.0-02.24.22-1 ii libgwengui-gtk2-0 4.8.0beta-1 ii libgwenhywfar604.8.0beta-1 ii libhtml-tableextract-perl 2.11-1 ii libhtml-tree-perl 5.03-1 ii libktoblzcheck1c2a 1.43-1 ii libofx41:0.9.4-2.1 ii libpango-1.0-0 1.36.0-1+b1 ii libpangocairo-1.0-01.36.0-1+b1 ii libpython2.7 2.7.6-4 ii libwebkitgtk-1.0-0 2.2.3-1 ii libwww-perl6.05-2 ii libx11-6 2:1.6.2-1 ii libxml22.9.1+dfsg1-3 ii libxslt1.1 1.1.28-2 ii perl 5.18.1-5 ii zlib1g 1:1.2.8.dfsg-1 Versions of packages gnucash recommends: ii gnucash-docs 2.6.0-1 ii yelp 3.10.1-1 Versions of packages gnucash suggests: pn libdbd-mysqlnone pn libdbd-pgsqlnone pn libdbd-sqlite3 none -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#709525: nfs-common: After upgrade to 1.2.8-2, rpc.gssd segfaults on startup
Package: nfs-common Version: 1:1.2.8-2 Severity: important Dear Maintainer, After upgrading to 1.2.8-2 as part of normal Jessie upkeep, rpc.gssd started segfaulting immediately on startup, and I'm not really able to wrap my head around just why. The crash happens in libgssglue, in __gss_get_mechanism_cred, called by gss_init_sec_context, at g_init_sec_context.c:153 (still in libgssglue). It is rather clear that the crash happens because the copy of mglueP.h that is shipped with the source of libgssglue does not match that which is shipped with libkrb5. In the latter, the struct `gss_union_cred_t' has gained a new field called `loopback', and lost its `auxinfo' field, and when inspecting the gss_union_cred_t that has been passed to __gss_get_mechanism_cred, it clearly matched the definition from libkrb5. However, the fault does not seem to be lying with libgssglue, since the segafult only happens when nfs-common is upgraded, and downgrading nfs-common back to 1.2.6-3 makes it start working again. A simple guess from my side is that nfs-common has (erroneously?) been compiled against libkrb5 in some place where it should be compiled against libgssglue, perhaps? The structure and dependencies between the various packages involved is, however, far from obvious to me. (At the face of it, it seems like a hack, to begin with, that libgssglue has a local copy of a private header file from MIT Kerberos.) Whatever the problem is, it makes rpc.gssd, and therefore Kerberized NFS mounts, entirely unusable. Fix pl0x. :) -- Package-specific info: -- rpcinfo -- program vers proto port service 104 tcp111 portmapper 103 tcp111 portmapper 102 tcp111 portmapper 104 udp111 portmapper 103 udp111 portmapper 102 udp111 portmapper 1000211 udp 33453 nlockmgr 1000213 udp 33453 nlockmgr 1000214 udp 33453 nlockmgr 1000211 tcp 54248 nlockmgr 1000213 tcp 54248 nlockmgr 1000214 tcp 54248 nlockmgr 172 udp708 ypbind 171 udp708 ypbind 172 tcp709 ypbind 171 tcp709 ypbind 1000241 udp 38590 status 1000241 tcp 43595 status -- /etc/default/nfs-common -- NEED_STATD= STATDOPTS= NEED_IDMAPD=yes NEED_GSSD=yes -- /etc/idmapd.conf -- [General] Verbosity = 0 Pipefs-Directory = /var/lib/nfs/rpc_pipefs Domain = dolda2000.com [Mapping] Nobody-User = nobody Nobody-Group = nogroup -- /etc/fstab -- home.nfs:/home /home nfs4sec=krb5i 0 0 home.nfs:/usr/site /usr/site nfs hard,intr,tcp 0 0 home.nfs:/video /home/pub/video nfs4sec=krb5i 0 0 -- /proc/mounts -- home.nfs:/home /home nfs4 rw,relatime,vers=4,rsize=131072,wsize=131072,namlen=255,hard,proto=tcp,port=0,timeo=600,retrans=2,sec=krb5i,clientaddr=192.168.1.181,minorversion=0,local_lock=none,addr=192.168.1.1 0 0 home.nfs:/usr/site /usr/site nfs rw,relatime,vers=3,rsize=131072,wsize=131072,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=192.168.1.1,mountvers=3,mountport=50152,mountproto=tcp,local_lock=none,addr=192.168.1.1 0 0 home.nfs:/video /home/pub/video nfs4 rw,relatime,vers=4,rsize=131072,wsize=131072,namlen=255,hard,proto=tcp,port=0,timeo=600,retrans=2,sec=krb5i,clientaddr=192.168.1.181,minorversion=0,local_lock=none,addr=192.168.1.1 0 0 rpc_pipefs /var/lib/nfs/rpc_pipefs rpc_pipefs rw,relatime 0 0 -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing'), (99, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages nfs-common depends on: ii adduser 3.113+nmu3 ii initscripts 2.88dsf-41 ii libc6 2.17-3 ii libcap2 1:2.22-1.2 ii libcomerr2 1.42.5-1.1 ii libdevmapper1.02.1 2:1.02.74-7 ii libevent-2.0-5 2.0.19-stable-3 ii libgssglue1 0.4-2 ii libk5crypto31.10.1+dfsg-5 ii libkeyutils11.5.5-7 ii libkrb5-3 1.10.1+dfsg-5 ii libmount1 2.20.1-5.4 ii libnfsidmap20.25-4 ii libtirpc1 0.2.2-5 ii libwrap07.6.q-24 ii lsb-base4.1+Debian9 ii rpcbind 0.2.0-8 ii ucf 3.0025+nmu3 Versions of packages nfs-common recommends: ii python 2.7.3-5 Versions of packages nfs-common suggests: pn open-iscsi none pn watchdognone -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#605458: [icedtea6-plugin] NULL pointer exception when starting minecraft
I'm experiencing a similar problem, though since it occurs at a different place in the source code, I'm not sure if it's a different bug or just in some slightly different version of NetX where stuff has been moved around. Either way, I fixed the NPE I was having with the following small patch: --- icedtea-web-1.3.1.orig/netx/net/sourceforge/jnlp/runtime/JNLPClassLoader.java +++ icedtea-web-1.3.1/netx/net/sourceforge/jnlp/runtime/JNLPClassLoader.java @@ -1115,7 +1115,7 @@ public class JNLPClassLoader extends URL } // Class from host X should be allowed to connect to host X -if (cs.getLocation().getHost().length() 0) +if ((cs.getLocation() != null) (cs.getLocation().getHost() != null) (cs.getLocation().getHost().length() 0)) result.add(new SocketPermission(cs.getLocation().getHost(), connect, accept)); As you can see, it's a very simple patch with no other side effects, so I don't think it would hurt applying it until upstream can fix the problem for real. -- Fredrik Tolf -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#681990: icedtea-netx: NetX tries to do applet-style classloading for non-applets
Package: icedtea-netx Version: 1.2-2 Severity: important Tags: upstream When launching normal JNLP applications (not applets), NetX tries to load classes or resources that it does not find over HTTP from the JNLP file's codebase attribute. Since such loading blocks the requesting thread, potentially a long time, that behavior can be quite problematic for programs exhibiting certain access patterns, such as: * Attempting to load resources from a Jar file that may or may not actually be there (normally failure is instantaneous); or * Using nested classloaders, in which case classloader delegation will ensure that *each* class requested will go through the JNLP classloader once and fail there. The problem is compounded when using JNLP extensions, in which case each extension's codebase will be attempted for every requested resource or class. I'm still trying to find my way around NetX's source code so I'm not too sure if this is intended or unintentional behavior; but from what I can see so far, the intention appears to be that it only happen for applets and not stand-alone applications, so I think it's safe to classify as a bug. Either way, other JNLP clients don't do the same thing, so I can't imagine it would hurt any properly built programs if the behavior were removed. -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (500, 'testing'), (99, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages icedtea-netx depends on: ii icedtea-netx-common 1.2-2 ii openjdk-6-jre6b24-1.11.3-2 icedtea-netx recommends no packages. icedtea-netx suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#608459: mount(nfs): no hosts available
For what it's worth, here's a patch which fixes the problem:
diff -ur autofs5-5.0.4-old/lib/rpc_subs.c autofs5-5.0.4/lib/rpc_subs.c
--- autofs5-5.0.4-old/lib/rpc_subs.c2010-12-31 04:59:32.0 +0100
+++ autofs5-5.0.4/lib/rpc_subs.c2010-12-31 05:00:06.0 +0100
@@ -274,7 +274,7 @@
if (*fd 0)
return NULL;
- if (connect_nb(*fd, laddr, slen, info-timeout) 0) {
+ if (bind(*fd, laddr, slen) 0) {
close(*fd);
return NULL;
}
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#622909: Deadlock in libdb4.5
Package: libdb4.5 Version: 4.5.20-13 Severity: normal I'm using db4.5 via the bsddb module in Python in a multithreaded program, and am having problems with deadlocking where, every few days, two or more threads deadlock inside db4.5. I've been over my code (which really isn't very complex at all) many times by now, and I can hardly even imagine anymore that I could be doing anything wrong, so I'm suspecting some kind of bug in libdb4.5 itself. I'm opening the environment the DB_THREAD and DB_INIT_LOCK, and the databases themselves with DB_THREAD, and from all I know, that should be enough to ensure libdb doesn't deadlock. I've been able to make two instances of the program coredump under the deadlock condition, and in both cases there were three threads deadlocking with the exact same call stacks in both instances. They look like this. Thread 1: #0 0x7f027543fd29 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #1 0x7f0271e529be in __db_pthread_mutex_lock () from /usr/lib/libdb-4.5.so #2 0x7f0271f01f4a in __lock_get_internal () from /usr/lib/libdb-4.5.so #3 0x7f0271f02056 in __lock_get () from /usr/lib/libdb-4.5.so #4 0x7f0271eda293 in __db_lget () from /usr/lib/libdb-4.5.so #5 0x7f0271e7cf45 in __ham_get_meta () from /usr/lib/libdb-4.5.so #6 0x7f0271e760dc in ?? () from /usr/lib/libdb-4.5.so #7 0x7f0271ecc84c in __db_c_get () from /usr/lib/libdb-4.5.so #8 0x7f0271ed8002 in __db_get () from /usr/lib/libdb-4.5.so #9 0x7f0271ed82de in __db_get_pp () from /usr/lib/libdb-4.5.so #10 0x7f027216d5ba in DB_subscript (self=0x10f62b0, keyobj=0x144fc48) at /build/buildd-python2.5_2.5.2-15+lenny1-amd64-gBDyED/python2.5-2.5.2/Modules/_bsddb.c:2792 (More frames follow inside the Python interpreter) Thread 2: #0 0x7f027543fd29 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #1 0x7f0271e529be in __db_pthread_mutex_lock () from /usr/lib/libdb-4.5.so #2 0x7f0271f01f4a in __lock_get_internal () from /usr/lib/libdb-4.5.so #3 0x7f0271f02056 in __lock_get () from /usr/lib/libdb-4.5.so #4 0x7f0271eda293 in __db_lget () from /usr/lib/libdb-4.5.so #5 0x7f0271edb80c in __db_new () from /usr/lib/libdb-4.5.so #6 0x7f0271e7e78c in __ham_add_ovflpage () from /usr/lib/libdb-4.5.so #7 0x7f0271e7f103 in __ham_add_el () from /usr/lib/libdb-4.5.so #8 0x7f0271e75905 in ?? () from /usr/lib/libdb-4.5.so #9 0x7f0271eceb8a in __db_c_put () from /usr/lib/libdb-4.5.so #10 0x7f0271ec6b10 in __db_put () from /usr/lib/libdb-4.5.so #11 0x7f0271ed6480 in __db_put_pp () from /usr/lib/libdb-4.5.so #12 0x7f027216db81 in DB_ass_sub (self=0x10f62b0, keyobj=value optimized out, dataobj=0x11ebd00) at /build/buildd-python2.5_2.5.2-15+lenny1-amd64-gBDyED/python2.5-2.5.2/Modules/_bsddb.c:678 Thread 3: #0 0x7f027543fd29 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #1 0x7f0271e529be in __db_pthread_mutex_lock () from /usr/lib/libdb-4.5.so #2 0x7f0271f01f4a in __lock_get_internal () from /usr/lib/libdb-4.5.so #3 0x7f0271f02056 in __lock_get () from /usr/lib/libdb-4.5.so #4 0x7f0271eda293 in __db_lget () from /usr/lib/libdb-4.5.so #5 0x7f0271edb80c in __db_new () from /usr/lib/libdb-4.5.so #6 0x7f0271e7e78c in __ham_add_ovflpage () from /usr/lib/libdb-4.5.so #7 0x7f0271e7f103 in __ham_add_el () from /usr/lib/libdb-4.5.so #8 0x7f0271e75905 in ?? () from /usr/lib/libdb-4.5.so #9 0x7f0271eceb8a in __db_c_put () from /usr/lib/libdb-4.5.so #10 0x7f0271ec6b10 in __db_put () from /usr/lib/libdb-4.5.so #11 0x7f0271ed6480 in __db_put_pp () from /usr/lib/libdb-4.5.so #12 0x7f027216db81 in DB_ass_sub (self=0x10f62b0, keyobj=value optimized out, dataobj=0x194d780) at /build/buildd-python2.5_2.5.2-15+lenny1-amd64-gBDyED/python2.5-2.5.2/Modules/_bsddb.c:678 I suspect that the first thread (in db-get) is just collateral damage, and that it is threads 2 and 3 that cause the deadlock via the __ham_add_ovflpage function. Because it sounds like an important function with global side effects on the database. :-) Of course, the troubleshooting is made harder by the fact that there are no debugging symbols to be had for libdb4.5. -- System Information: Debian Release: 5.0.8 APT prefers oldstable APT policy: (500, 'oldstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.26-2-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages libdb4.5 depends on: ii libc6 2.7-18lenny7 GNU C Library: Shared libraries libdb4.5 recommends no packages. libdb4.5 suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#617313: [Pkg-telepathy-maintainers] Bug#617313: empathy: Empathy becomes inaccessible without a tray dock
On Tue, 2011-03-08 at 08:16 +, Jonny Lamb wrote: Actually there is. If you try to run empathy again from the command line or from some application menu, it will pop up the main window again due to the single-instance nature of the application. Empathy should also start as visible as it was left on the last execution. Oh, I was not aware of that. Sorry. Empathy is a GNOME application. GNOME has a system tray area. I'm tempted to wontfix this bug. I won't hold a grudge against you if you do. :) -- Fredrik Tolf -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#617313: empathy: Empathy becomes inaccessible without a tray dock
Package: empathy Version: 2.30.3-1 Severity: important When running a window manager that does not include a system tray/dock/notification area, the Empathy window becomes inaccessible if closed. It closes the window, assuming the user to be able to reaccess it via the non-existing tray, and also enters that state automatically upon startup, so there's really no way at all of bringing it back other than starting a temporary tray program like stalonetray or trayer. -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (500, 'testing'), (400, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages empathy depends on: ii dbus-x11 1.4.6-1simple interprocess messaging syst ii empathy-common2.30.3-1 GNOME multi-protocol chat and call ii gconf22.28.1-6 GNOME configuration database syste ii geoclue 0.12.0-1 Geographic information framework ii gnome-icon-theme 2.30.3-2 GNOME Desktop icon theme ii libatk1.0-0 1.30.0-1 The ATK accessibility toolkit ii libc6 2.11.2-11 Embedded GNU C Library: Shared lib ii libcairo2 1.8.10-6 The Cairo 2D vector graphics libra ii libcanberra-gtk0 0.24-1 Gtk+ helper for playing widget eve ii libcanberra0 0.24-1 a simple abstract interface for pl ii libchamplain-0.4-00.4.6-2+b1 C library providing ClutterActor t ii libchamplain-gtk-0.4- 0.4.6-2+b1 A Gtk+ widget to display maps ii libclutter-1.0-0 1.2.12-3 Open GL based interactive canvas l ii libclutter-gtk-0.10-0 0.10.4-1 Open GL based interactive canvas l ii libdbus-1-3 1.4.6-1simple interprocess messaging syst ii libdbus-glib-1-2 0.88-2.1 simple interprocess messaging syst ii libebook1.2-9 2.30.3-2 Client library for evolution addre ii libedataserver1.2-13 2.30.3-2 Utility library for evolution data ii libenchant1c2a1.6.0-1a wrapper library for various spel ii libfontconfig12.8.0-2.1 generic font configuration library ii libfreetype6 2.4.2-2.1 FreeType 2 font engine, shared lib ii libgconf2-4 2.28.1-6 GNOME configuration database syste ii libgeoclue0 0.12.0-1 C API for GeoClue ii libgl1-mesa-glx [libg 7.10-4 A free implementation of the OpenG ii libglib2.0-0 2.28.1-1+b1The GLib library of C routines ii libgnome-keyring0 2.30.1-1 GNOME keyring services library ii libgstfarsight0.10-0 0.0.22-1 Audio/Video communications framewo ii libgstreamer-plugins- 0.10.30-1 GStreamer libraries from the base ii libgstreamer0.10-00.10.30-1 Core GStreamer libraries and eleme ii libgtk2.0-0 2.20.1-2 The GTK+ graphical user interface ii libjson-glib-1.0-00.10.2-2 GLib JSON manipulation library ii libnm-glib2 0.8.1-6network management framework (GLib ii libnotify1 [libnotify 0.5.0-2sends desktop notifications to a n ii libpango1.0-0 1.28.3-1+squeeze1 Layout and rendering of internatio ii libsoup2.4-1 2.30.2-1 an HTTP library implementation in ii libtelepathy-farsight 0.0.16+is.0.0.14-1 Glue library between telepathy and ii libtelepathy-glib00.11.11-1 Telepathy framework - GLib library ii libunique-1.0-0 1.1.6-2Library for writing single instanc ii libwebkit-1.0-2 1.2.6-2Web content engine library for Gtk ii libx11-6 2:1.4.1-4 X11 client-side library ii libxcomposite11:0.4.3-1 X11 Composite extension library ii libxdamage1 1:1.1.3-1 X11 damaged region extension libra ii libxext6 2:1.2.0-2 X11 miscellaneous extension librar ii libxfixes31:4.0.5-1 X11 miscellaneous 'fixes' extensio ii libxml2 2.7.8.dfsg-2 GNOME XML library ii telepathy-mission-con 1:5.4.3-1 management daemon for Telepathy re ii zlib1g1:1.2.3.4.dfsg-3 compression library - runtime Versions of packages empathy recommends: ii freedesktop-sound-theme 0.7.dfsg-1 freedesktop.org sound theme ii geoclue-hostip0.12.0-1 Position server for GeoClue (hosti ii geoclue-localnet 0.12.0-1 Position server for GeoClue (GPS) ii geoclue-manual0.12.0-1 Position server for GeoClue (manua ii geoclue-yahoo 0.12.0-1 Map and geocode server for GeoClue ii gvfs-backends 1.6.4-3userspace
Bug#613407: libgl1-mesa-dri: mesa 7.10 should depend on libdrm 2.4.23
Package: libgl1-mesa-dri Version: 7.10-3 Severity: normal I just installed mesa 7.10 (from unstable) on a testing system, and it seems that it also needs libdrm 2.4.23, but it only depends on 2.4.21 (which is what comes with testing). With 2.4.21, all programs that used OpenGL hung before being able to render anything at all. With 2.4.23, everything worked as expected. It should also be noted that mesa 7.10 requires libdrm 2.4.23 to compile successfully, which I guess is probably related. This system uses the i965 driver in case it matters, which I guess it does. It has an Arrandale chipset. -- System Information: Debian Release: 6.0 APT prefers testing APT policy: (500, 'testing'), (400, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libgl1-mesa-dri depends on: ii libc6 2.11.2-10 Embedded GNU C Library: Shared lib ii libdrm-intel1 2.4.23-2 Userspace interface to intel-speci ii libdrm-radeon12.4.23-2 Userspace interface to radeon-spec ii libdrm2 2.4.23-2 Userspace interface to kernel DRM ii libexpat1 2.0.1-7XML parsing C library - runtime li ii libgcc1 1:4.4.5-10 GCC support library ii libstdc++64.4.5-10 The GNU Standard C++ Library v3 ii libtalloc22.0.5-1hierarchical pool based memory all libgl1-mesa-dri recommends no packages. Versions of packages libgl1-mesa-dri suggests: pn libglide3 none (no description available) -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#613407: libgl1-mesa-dri: mesa 7.10 should depend on libdrm 2.4.23
On Mon, 2011-02-14 at 16:59 +0100, Cyril Brulebois wrote: Fredrik Tolf fred...@dolda2000.com (14/02/2011): This system uses the i965 driver in case it matters, which I guess it does. It has an Arrandale chipset. Wild guess, your system needs an updated libdrm, not libgl1-mesa-dri itself. Not quite. My system worked perfectly well with Mesa 7.7 and libdrm-2.4.21. The reason I upgraded to Mesa 7.10 was that Mesa 7.7 has a GLSL linker bug that had been fixed in later versions, but fixed functionality rendering worked perfectly well. So in summary: Mesa 7.7 with libdrm-2.4.21 works for me, Mesa 7.10 with libdrm-2.4.23 also works, but Mesa 7.10 with libdrm 2.4.21 does not. I haven't tried Mesa 7.7 with libdrm-2.4.21. -- Fredrik Tolf -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#613407: libgl1-mesa-dri: mesa 7.10 should depend on libdrm 2.4.23
On Mon, 2011-02-14 at 17:55 +0100, Cyril Brulebois wrote: Rephrasing: maybe you happen to run into a bug due to this particular combination of versions. That doesn't mean mesa 7.10 must depend on 2.4.23 on all systems. Maybe so, but then again, I did try to compile Mesa 7.10 from source code with 2.4.21, and that wasn't possible due to missing constants and stuff in the libdrm header files, so it seems reasonable to assume from that, that Mesa 7.10 depends on something or other in libdrm 2.4.23. So in summary: Mesa 7.7 with libdrm-2.4.21 works for me, Mesa 7.10 with libdrm-2.4.23 also works, but Mesa 7.10 with libdrm 2.4.21 does not. I haven't tried Mesa 7.7 with libdrm-2.4.21. I guess you meant 7.7/2.4.23 Correct. :-) -- Fredrik Tolf -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#612370: krb5-ftpd uses min-delay TOS on data connections rather than max-throughput
Package: krb5-ftpd Version: 1.6.dfsg.4~beta1-5lenny6 Severity: normal Tags: patch As subject says, krb5-ftpd uses IPTOS_MINDELAY instead of IPTOS_THROUGHPUT on its data connections, messing up the quality of service. The fix is very simple, of course: diff -Nurp krb5-1.6.dfsg.4~beta1/src/appl/gssftp/ftpd/ftpd.c krb5-1.6.dfsg.4~beta1-new/src/appl/gssftp/ftpd/ftpd.c --- krb5-1.6.dfsg.4~beta1/src/appl/gssftp/ftpd/ftpd.c 2011-02-08 02:22:16.0 +0100 +++ krb5-1.6.dfsg.4~beta1-new/src/appl/gssftp/ftpd/ftpd.c 2011-02-08 02:22:35.922835766 +0100 @@ -1424,8 +1424,8 @@ dataconn(name, size, fmode) (void) close(pdata); pdata = s; #ifdef IP_TOS -#ifdef IPTOS_LOWDELAY - tos = IPTOS_LOWDELAY; +#ifdef IPTOS_THROUGHPUT + tos = IPTOS_THROUGHPUT; (void) setsockopt(s, IPPROTO_IP, IP_TOS, (char *)tos, sizeof(int)); #endif -- System Information: Debian Release: 5.0.8 APT prefers oldstable APT policy: (500, 'oldstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.24-1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages krb5-ftpd depends on: ii krb5-config 1.22 Configuration files for Kerberos V ii libc6 2.7-18lenny7 GNU C Library: Shared libraries ii libcomerr2 1.41.3-1 common error description library ii libkeyutils11.2-9Linux Key Management Utilities (li ii libkrb531.6.dfsg.4~beta1-5lenny6 MIT Kerberos runtime libraries ii openbsd-inetd [ 0.20080125-2 The OpenBSD Internet Superserver krb5-ftpd recommends no packages. krb5-ftpd suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#608459: mount(nfs): no hosts available
Package: autofs5 Version: 5.0.4-3.2+dolda1 Severity: important Tags: upstream When trying to use a NFSv4 export with automount, it gives me the following error when I try to access the export: attempting to mount entry /net/home mount(nfs): no hosts available My configuration is quite simple. /etc/auto.master: /netfile:/etc/auto.net And /etc/auto.net: home-fstype=nfs4,sec=krb5i nerv.dolda2000.com:/home The mount works fine when I just try to mount it normally, running mount -t nfs4 -o sec=krb5 nerv.dolda2000.com:/home /mnt Having spent some time debugging automount, I actually don't see how NFSv4 (over TCP, at least) could work for anyone at all, ever, with this version of automount. In lib/rpc_subs.c, the rpc_do_create_client (which is called as part of testing the server's availability) tries to connect to 0.0.0.0 -- instead of binding to it! -- and, obviously, fails, causing the server availability test to fail. See line 277, which calls connect_nb on the laddr sockaddr, which (as seen in the preceding test for UDP servers a few lines above) is meant for binding. -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (500, 'testing'), (400, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages autofs5 depends on: ii libc62.11.2-7Embedded GNU C Library: Shared lib ii ucf 3.0025+nmu1 Update Configuration File: preserv Versions of packages autofs5 recommends: ii module-init-tools 3.12-1 tools for managing Linux kernel mo ii nfs-common1:1.2.2-4 NFS support files common to client autofs5 suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#588765: gcc-4.4: internal compiler error in dwarf2out_finish
Package: gcc-4.4 Version: 4.4.4-6 Severity: normal When compiling a certain piece of generated code, GCC crashes for me with the following message: $ gcc-4.4 -save-temps -Wall -g -shared -o test.so cosem-25378.c cosem-25378.c:1322: internal compiler error: in dwarf2out_finish, at dwarf2out.c:16662 Please submit a full bug report, with preprocessed source if appropriate. See file:///usr/share/doc/gcc-4.4/README.Bugs for instructions. I've tried against other versions of GCC, and the crash does not appear on 4.1, 4.2 or 4.3, but with 4.4 and -snapshot. On -snapshot, the crash happens on line 22234 in dwarf2out.c instead, however. I'm using the current default GCC packages from testing (and -snapshot from unstable) on i386, but just in case, gcc -v says the following about itself: Using built-in specs. Target: i486-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 4.4.4-6' --with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared --enable-multiarch --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.4 --program-suffix=-4.4 --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-targets=all --with-arch-32=i586 --with-tune=generic --enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu --target=i486-linux-gnu Thread model: posix gcc version 4.4.4 (Debian 4.4.4-6) I'm guessing you don't want thousands of lines of preprocessed C code in this bug message, so I made it available here: http://www.dolda2000.com/~fredrik/lf/cosem-25378.i -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (500, 'testing'), (400, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.32-3-686 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages gcc-4.4 depends on: ii binutils 2.20.1-11 The GNU assembler, linker and bina ii cpp-4.4 4.4.4-6The GNU C preprocessor ii gcc-4.4-base 4.4.4-6The GNU Compiler Collection (base ii libc6 2.11.2-2 Embedded GNU C Library: Shared lib ii libgcc1 1:4.4.4-6 GCC support library ii libgomp1 4.4.4-6GCC OpenMP (GOMP) support library Versions of packages gcc-4.4 recommends: ii libc6-dev 2.11.2-2 Embedded GNU C Library: Developmen Versions of packages gcc-4.4 suggests: ii gcc-4.4-doc 4.4.4.nf1-1 documentation for the GNU compiler pn gcc-4.4-locales none (no description available) pn gcc-4.4-multilib none (no description available) ii libcloog-ppl00.15.9-1the Chunky Loop Generator (runtime pn libgcc1-dbg none (no description available) pn libgomp1-dbg none (no description available) pn libmudflap0-4.4-dev none (no description available) pn libmudflap0-dbg none (no description available) ii libppl-c20.10.2-6Parma Polyhedra Library (C interfa ii libppl7 0.10.2-6Parma Polyhedra Library (runtime l -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#571999: xserver-xorg-core: config/udev claims all input devices
Package: xserver-xorg-core Version: 2:1.7.4-2 Severity: normal The udev autoconfig claims all my input devices whether I want them or not. This is a problem, because I'm running two X server, one of them just to display stuff on a TV. Obviously, I wouldn't want it to grab keyboard input from my interactive login session and pass it to mplayer. In my opinion, I think automatic configuration like that of config/udev or config/hal should only be used if I haven't specified any input devices explicitly in my xorg.conf, but I'm sure there could be other issues that should be considered as well. It would be nice, at least, with a way to turn off automatic input device detection, though. Looking at the config/udev code, there doesn't seem to be any, seeing how it always adds all input device when it is initialized as a module. -- Package-specific info: /var/lib/x11/X.roster does not exist. /var/lib/x11/X.md5sum does not exist. X server symlink status: lrwxrwxrwx 1 root root 13 Oct 28 2007 /etc/X11/X - /usr/bin/Xorg -rwxr-xr-x 1 root root 1710344 Jan 21 00:01 /usr/bin/Xorg /var/lib/x11/xorg.conf.roster does not exist. VGA-compatible devices on PCI bus: 02:00.0 VGA compatible controller: nVidia Corporation G72 [GeForce 7300 SE/7200 GS] (rev a1) 03:00.0 VGA compatible controller: nVidia Corporation G96 [GeForce 9500 GT] (rev a1) /var/lib/x11/xorg.conf.md5sum does not exist. Xorg X server configuration file status: -rw-r--r-- 1 root root 8575 Feb 28 20:52 /etc/X11/xorg.conf Contents of /etc/X11/xorg.conf: Section ServerLayout Identifier NV Screen 0 S_Main 0 0 #Screen 1 S_TV LeftOf S_Main InputDeviceUSBMouse CorePointer InputDeviceKeyboard1 CoreKeyboard Option SingleCard true EndSection Section ServerLayout Identifier NV_Dual Screen0 S_Main 0 0 Screen1 S_Main2 LeftOf S_Main InputDevice USBMouse CorePointer InputDevice Keyboard1 CoreKeyboard Option SingleCard true EndSection Section ServerLayout Identifier Sec Screen 0 S_Sec 0 0 InputDeviceNullMouse CorePointer #InputDeviceMouse1 CorePointer #InputDeviceWCursor CorePointer #InputDeviceWStylus SendCoreEvents #InputDeviceWEraser SendCoreEvents InputDeviceKeyboard2 CoreKeyboard Option SingleCard true EndSection Section ServerLayout Identifier Log Screen 0 S_Ter 0 0 InputDeviceNullMouse CorePointer InputDeviceNullKeyboard CoreKeyboard Option SingleCard true EndSection Section ServerLayout Identifier TV Screen S_TV 0 0 InputDevice NullMouse CorePointer InputDevice NullKeyboard CoreKeyboard Option SingleCard true EndSection Section ServerLayout # Layout: # /\ # | | | | # | Tertiary | Secondary| Main | # | 17|17 |20 | # | | | | # \--|--|--/ #| | #|TV| #| Many | #| | #\--/ Identifier Desktop Screen 0 S_Main 0 0 Screen 1 S_Sec LeftOf S_Main Screen 2 S_Ter LeftOf S_Sec Screen 3 S_TV Below S_Sec InputDeviceUSBMouse CorePointer InputDeviceConsoleKeyboard CoreKeyboard EndSection Section ServerFlags Option PciOsConfig 1 Option AllowDeactivateGrabs 1 Option AllowClosedownGrabs 1 EndSection Section Files FontPath unix/:7100 EndSection Section Module Load glx Load extmod Load dbe Load record Load xtrap Load type1 Load v4l EndSection Section Extensions # Option Composite Enable EndSection Section InputDevice Identifier ConsoleKeyboard Driver kbd EndSection Section InputDevice Identifier Keyboard1 Driver evdev Option Device /dev/input/by-id/usb-Unicomp_Endura_Keyboard-event-kbd #Option Device /dev/input/by-id/usb-CHESEN_PS2_to_USB_Converter-event-kbd EndSection Section InputDevice Identifier Keyboard2 Driver evdev Option Device /dev/input/by-id/usb-CHESEN_USB_Keyboard-event-kbd EndSection Section InputDevice Identifier PSMouse Driver mouse Option Protocol ExplorerPS/2 Option Device /dev/input/mouse0 Option ZAxisMapping 4 5 EndSection Section InputDevice Identifier USBMouse Driver evdev Option Device /dev/input/by-id/usb-A4Tech_PS_2+USB_Mouse-event-mouse #Driver mouse #Option
Bug#566337: Additional tests
For the record, the same thing happens with a vanilla kernel (I tested on vanilla 2.6.32.7). I also tried installing another Debian system from scratch to eliminate any possibility of external misconfiguration, and the same thing happened there. I also tried a few other things just to be sure, such as connecting the video card to different PCI-express slots, using it with or without another card in the same machine, and various output configurations. What causes it to fail is using the TV output and nothing else (it can drive CRT and DVI monitors without problems, even simultaneously). If it matters, this is my xorg.conf Device section for the TV output: Section Device Identifier D_NV-TV Driver nvidia BusID PCI:2:0:0 Option NoLogo 1 Option UseDisplayDevice TV Option ConnectedMonitor TV Option TVStandard PAL-G Option TVOutFormat SVIDEO EndSection If the original submitter of the bug is reading this, were you also using the TV output? I tried mounting the root filesystem with `-o sync' to get the X-server log synced properly to disk; the last lines before the crash are these: [snip] (==) Feb 15 06:14:33 NVIDIA(0): DPI set to (75, 75); computed from built-in default (==) Feb 15 06:14:33 NVIDIA(0): Enabling 32-bit ARGB GLX visuals. (--) Depth 24 pixmap format is 32 bpp (II) Feb 15 06:14:33 NVIDIA(0): Initialized GPU GART. (II) Feb 15 06:14:33 NVIDIA(0): ACPI: failed to connect to the ACPI event daemon; the daemon (II) Feb 15 06:14:33 NVIDIA(0): may not be running or the AcpidSocketPath X Since that's only half of the message from the nvidia driver telling the it cannot connect to acpid, I guess it must mean that the kernel panics asynchronously while the X server continues to run. I guess that's consistent with the fact that it seems to crash in an ISR, but at least I guess it means that the X server isn't currently running any piece of code that would be waiting for some reponse from the kernel driver. (Or could the log message have avoided getting written to disk despite /var/log being on a `-o sync'-mounted filesystem?) I dunno if that helps though, seeing how the driver source isn't available to look at anyway. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1266251998.3929.13.ca...@pc7.dolda2000.com
Bug#566337: Problem solved
I posted on the nVidia support forum, and it turns out that it was a bug, which has been fixed in the current beta drivers. See http://www.nvnews.net/vbulletin/showthread.php?p=2178512 I patched together Debian packages with the new beta driver, based on the current nvidia-graphics-drivers source package, along with a few modification required for successful compilation. If anyone wants them, feel free to download them from http://www.dolda2000.com/~fredrik/deb/nv/. Fredrik Tolf -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1266274258.4097.4.ca...@pc7.dolda2000.com
Bug#568818: Verified, and workaround
This happens to me too. I am able to work around it be replacing SWANK-LOADER::BINARY-PATHNAME with the following definition: (defun binary-pathname (src-pathname binary-dir) Return the pathname where SRC-PATHNAME's binary should be compiled. (declare (ignore binary-dir)) (let ((cfp (compile-file-pathname src-pathname))) (merge-pathnames (make-pathname :directory `(:relative ,@(cdr (pathname-directory (user-homedir-pathname))) swank fasl ,(unique-dir-name)) :name (pathname-name cfp) :type (pathname-type cfp)) asdf:*default-toplevel-directory*))) While it works, I smell uglyness. I have no better suggestion currently, though, but it seems that the ASDF function OUTPUT-FILES-USING-MAPPINGS or OUTPUT-FILES-FOR-SYSTEM-AND-OPERATION might be usable for constructing a better solution. Fredrik Tolf -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#568194: mount.nfs: new default behavior breaks current /etc/fstab
Package: nfs-common Version: 1:1.2.1-3 Severity: important Since upgrading nfs-common from 1.2.0-4.1 to 1.2.1-3, the default behavior in mount.nfs has changed so that it tries to mount filesystems as NFSv4 as default (when specifying `-t nfs' to mount), rather than NFSv3 as it has always done previously. The fix is trivial (just specify -o vers=3), but since v3 was the previous default, it is common to omit it from /etc/fstab, and since the mount request fails as NFSv4, the init scripts will hang during boot, waiting forever for the NFS mount to become available. It would probably be good to continue mounting as v3 by default, IMHO, since it has always been possible to specify nfs4 as the filesystem type explicitly. Even if you don't agree, it would probably be nice to at least mention the change in the package's NEWS file, so that one can see it before rebooting. -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (500, 'testing'), (400, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.32-trunk-686 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages nfs-common depends on: ii adduser3.112 add and remove users and groups ii initscripts2.87dsf-8 scripts for initializing and shutt ii libc6 2.10.2-2 GNU C Library: Shared libraries ii libcomerr2 1.41.9-1 common error description library ii libevent-1.4-2 1.4.13-stable-1 An asynchronous event notification ii libgssapi-krb5-2 1.8+dfsg~alpha1-5 MIT Kerberos runtime libraries - k ii libgssglue10.1-4 mechanism-switch gssapi library ii libk5crypto3 1.8+dfsg~alpha1-5 MIT Kerberos runtime libraries - C ii libkrb5-3 1.8+dfsg~alpha1-5 MIT Kerberos runtime libraries ii libnfsidmap2 0.23-2An nfs idmapping library ii librpcsecgss3 0.19-2allows secure rpc communication us ii libwrap0 7.6.q-18 Wietse Venema's TCP wrappers libra ii lsb-base 3.2-23Linux Standard Base 3.2 init scrip ii netbase4.40 Basic TCP/IP networking system ii portmap6.0.0-1 RPC port mapper ii ucf3.0025Update Configuration File: preserv nfs-common recommends no packages. nfs-common suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#566337: Verified on i386
] [c1035c80] ? __do_softirq+0xaa/0x151 [ 140.504511] [c1035d58] ? do_softirq+0x31/0x3c [ 140.504511] [c1035e2e] ? irq_exit+0x26/0x58 [ 140.504511] [c1004c91] ? do_IRQ+0x78/0x89 [ 140.504511] [c10037f0] ? common_interrupt+0x30/0x38 [ 140.504511] [c101b0c0] ? native_safe_halt+0x2/0x3 [ 140.504511] [c1008f1f] ? default_idle+0x3c/0x5a [ 140.504511] [c10092fe] ? c1e_idle+0xd2/0xd5 [ 140.504511] [c1002388] ? cpu_idle+0x89/0xa5 [ 140.504511] Code: Bad EIP value. [ 140.504511] EIP: [] 0x0 SS:ESP 0068:f6c79e08 [ 140.504511] CR2: [ 140.825890] ---[ end trace 69027cedbdef896b ]--- [ 140.830564] Kernel panic - not syncing: Fatal exception in interrupt Could the fact that this happens with both versions of the driver by any chance indicate that the flaw is with the kernel configuration or something? I upgraded the kernel and nvidia-kernel-source at the same time, so I can't tell anymore. I cannot get the headers for the old kernels anymore to try and rebuild the new drivers for it, but I'm going to try it with a vanilla kernel as soon as it gets built (compiling it as I'm writing this). Fredrik Tolf -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#567388: Bug#506549: Works with unstable
For what it's worth, upgrading python-wxversion to the version from unstable (2.8.10.1-3) make python-wxgtk2.6 work again. Fredrik Tolf -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#535305: Reverting to old function fixes the problem
For what it's worth, I managed to fix the problem by changing /usr/share/common-lisp/source/common-lisp-controller/post-sysdef-install.lisp so that the line, in the GET-OWNER-AND-MODE function as defined for SBCL, which, in the new version of c-l-c (6.18), reads (sb-impl::native-file-kind (namestring directory))) instead reads (sb-unix:unix-file-kind (namestring directory))) as was the case in the previous version (6.17). Maybe this change had to happen because of some newer version of SBCL in unstable? What I'm not getting is how this slipped past the HANDLER-CASE form in /usr/lib/sbcl/install-clc.lisp. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#526854: hal: HAL should not require PolicyKit
On Mon, 2009-05-04 at 09:52 +0200, Michael Biebl wrote: I have not researched it in detail yet, so I don't really know if it's a good So you are basing your request on FUD? I don't think so. What I meant by not researching was whether the solution of splitting it into two packages would be plausible. As for my wider argument, I may be wrong somewhere along the line, but please correct me if that is so. My argument is this: First, as far as I know, PolicyKit is essentially a system for granting privileges to a user which he would not have without it. In other words, depending on the configuration of PolicyKit, a user may be allowed to do things he would not be allowed to without it [see note 1]. Second, the configuration and operation of PolicyKit is not well-known, unlike normal Unix security. Third, Debian previously used ordinary Unix groups to assign various HAL-related privileges to users. Everyone known how Unix groups work; if a user wasn't a member of any particular groups, he would be granted no unexpected privileges. Thus, I think it is a bad idea to install PolicyKit by default: With PolicyKit, I don't even know how permissions are granted to users. I know that it's supposed to authenticate through PAM, but I have not yet found any information on how it actually authorizes the authenticated users for the various permissions it can grant. Note, also, the following remark from the PolicyKit(8) manpage: TODO: This manual page should contain a simple introduction to PolicyKit for a system administrator audience. Remains to be written. The same manpage points to /usr/share/doc/policykit for more information, but it only contains a README explaining why various policykit programs have the file modes they do, and nothing about how to administer PolicyKit itself. That is my conclusion. Please tell me if I'm wrong somewhere along the line. Fredrik Tolf -- Note 1: Parenthetical remark -- As such, PolicyKit, as a security system, differs from systems like SELinux which only remove privileges a user would otherwise have, and which therefore do not create any new vectors for doing privileged operations, -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#526854: [Pkg-utopia-maintainers] Bug#526854: hal: HAL should not require PolicyKit
On Mon, 2009-05-04 at 21:06 +0200, Michael Biebl wrote: That basically reads, like you are missing proper documentation. Have you installed policykit-doc and read the documentation provided there (best read with devhelp)? [...] We invented groups like plugdev/netdev/powerdev in HAL, to control access to the HAL D-Bus service. Yet the exact meaning of those groups is very vague (or can you tell me which privileges you exactly get by being a member of e.g. group plugdev?) [...] Again, the group-based approach is less flexible, too coarse grained, not dynamic and not scalable. Thus PolicyKit is a definit improvement (security wise). [...] What I miss from your arguments are solid, technical reasons, why PolicyKit is, as you put it, a bad idea. Based on your comments, I think you misunderstand me. I don't think PolicyKit is a bad idea, and I agree that the groups previously used were too coarsely grained and too unclear about what privileges were granted through them. What I do think is a bad idea is installing policykit by default, as a hard dependency of HAL. Even if I don't know exactly what privileges are granted through the `plugdev' group, I do know for sure that without being a member of it, no privileges at all are granted, which is something I cannot necessarily know with PolicyKit. In fact, I installed policykit-doc, as you suggested, and from reading it, it seems that it is the inidividual packages that grant privileges by default simply by installing policy files into /usr/share/PolicyKit/policy. For example, merely by having NetworkManager installed, local users would automatically be granted privilege to change networks, whereas previously, I would have to make them part of the netdev group, explicitly. My point, therefore, is that since the installation of PolicyKit grants privileges to users merely by virtue of being installed, it should not be installed automatically. If it is installed automatically, I should at least have to turn it on explicitly. Fredrik Tolf -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#526854: [Pkg-utopia-maintainers] Bug#526854: hal: HAL should not require PolicyKit
On Mon, 2009-05-04 at 23:12 +0200, Fredrik Tolf wrote: What I do think is a bad idea is installing policykit by default, as a hard dependency of HAL. Just in case I wasn't clear enough, my argument is this: Without PolicyKit, I had to take explicit action in order to grant privileges to users, while with PolicyKit, I have to take explicit action in order to *not* grant privileges to users. Therefore, it should not be installed by default, since the mere act of installing it suddenly gives all my existing users new privileges, without me, the administrator, even being warned of such a thing. Fredrik Tolf -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#526854: hal: HAL should not require PolicyKit
On Mon, 2009-05-04 at 23:57 +0200, Martin Pitt wrote: Fredrik Tolf [2009-05-04 21:37 +]: Just in case I wasn't clear enough, my argument is this: Without PolicyKit, I had to take explicit action in order to grant privileges to users, while with PolicyKit, I have to take explicit action in order to *not* grant privileges to users. That's not an inherent property of PK vs. groups, but a matter of default configuration. E. g. the installer used to put the default user into plugdev, powerdev, etc., and users-admin (from gnome-system-tools) did similar things for a desktop user. Both of those are special cases explicitly designed for usability with weaker security, though. I use neither. The job of us as a distro is to provide a sensible default configuration which provides a good balance between security and usability. Arguably so, but how do you define what is sensible? In my mind, PolicyKit's defaults seem sensible only for desktop setups, which aren't the only places in which HAL is being used. I've used it both in workstation-class setups and embedded special purpose setups (such as a music player computer, where I used it to detect USB storage with media files on), where it cannot reasonably be argued that local users should be granted all those privileges by default. I don't think that it should be assumed that all Debian machines are desktop machines. That's what Ubuntu is for, if you ask me. And apart from that, it would be nice to at least be *able* to create unprivileged users, which you cannot do with PK's defaults. For that matter, it is unclear what PK means by auth_admin, and I have yet found no documentation to explain it. Also, it is very unclear what one should do to avoid these sensible defaults, and if they cannot be avoided, then they aren't just defaults. For example, it doesn't make much sense to deny access to an USB camera or scanner to an user at a local console; he has physical access to those devices, after all. Quite possibly so, but I would expect to be able to leave a USB thumbdrive in the computer and not risk it being written to by any local user who you haven't given any particular privilege to otherwise read it (unlike e.g. pmount, which requires users to be part of the plugdev group). Of course he'd be able to steal it and plug it into some other computer if he has local access, but at least that would be noticed. Thus I am very much against making PK optional. It will only aggravate the confusion, since there will be systems which use PK and some which don't. Well, yeah, there will. I must admit that I don't see the problem with that. There are systems which use NIS, and other which don't. History showed that device access privileges can't be sensibly mapped to and maintained with static group membership, so we should settle to _one_ system of verifying privileges, also to be compatible with the rest of the world. Maybe, maybe not. I, for one, never had any problems with the static group membership solution, so I can't really say that history has showed that it cannot be done... Furthermore, it is precisely *because* there should be exactly one system of verifying privileges that I oppose PK, because POSIX already defines that system. With PK there are two systems, and even worse, any given user gets the union, not the intersection, of the privileges granted by each. If it were the intersection, I wouldn't object. This way, as I've said, users are getting granted privileges without me even knowing it. How about creating a special group for all users that can have privileges granted by PK? As for being compatible with the rest of the world, I resent that statement. There are different distros because not everyone wants to use the exact same thing. To be fair, I had very similar feelings like you when I heared about PK the first time, since it seemed to be that ominous new thing which opened root holes in the background. :-) I don't mean to sound offensive, but why did you change your mind? Surely it wasn't just to be like everyone else? Just my € 0.02, Since I resent the usage of fiat currency, please accept my 1 mg of gold in return. :) Fredrik Tolf -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#526854: hal: HAL should not require PolicyKit
Package: hal Version: 0.5.12~git20090406.46dc48-2 Severity: important I think that it is a bad thing that HAL started depending on PolicyKit in the latest versions. PolicyKit introduces a whole new, parallel security system, and it does not seem to be well-known how it works or how to properly administer it (I, for one, certainly don't know how it works, at least). Therefore, it may introduce security holes unknown to the maintainer of some systems. In particular seeing how HAL is required by so many things (GNOME and KDE, for example), it may even install PolicyKit without the administrator knowing about it (installing GNOME or KDE pulls in so many other packages anyway that it might be hard to spot PolicyKit among them; I almost missed it in the latest dist-upgrade). I have not researched it in detail yet, so I don't really know if it's a good solution, but I would suggest some optional bridge package which integrates HAL and PolicyKit, and which can be installed by those who want PolicyKit. Of course, it is true that the same thing may be said of HAL as well, put since the entire purpose of PolicyKit is to introduce a new layer of security and permissions, I would consider it even more dangerous. -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (500, 'testing'), (400, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.26-1-686 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages hal depends on: ii adduser 3.110 add and remove users and groups ii dbus 1.2.12-1simple interprocess messaging syst pn hal-info none (no description available) ii libc62.9-4 GNU C Library: Shared libraries ii libdbus-1-3 1.2.12-1simple interprocess messaging syst ii libdbus-glib 0.80-3 simple interprocess messaging syst ii libexpat12.0.1-4 XML parsing C library - runtime li ii libgcc1 1:4.3.3-3 GCC support library ii libglib2.0-0 2.20.0-2The GLib library of C routines ii libhal-stora 0.5.12~git20090406.46dc48-2 Hardware Abstraction Layer - share ii libhal1 0.5.12~git20090406.46dc48-2 Hardware Abstraction Layer - share ii libsmbios2 2.0.3.dfsg-1Provide access to (SM)BIOS informa ii libstdc++6 4.3.3-3 The GNU Standard C++ Library v3 ii libusb-0.1-4 2:0.1.12-13 userspace USB programming library ii libvolume-id 0.125-7 libvolume_id shared library ii lsb-base 3.2-22 Linux Standard Base 3.2 init scrip ii mount2.13.1.1-1 Tools for mounting and manipulatin ii pciutils 1:3.1.2-3 Linux PCI Utilities pn pm-utils none (no description available) ii udev 0.141-1 /dev/ and hotplug management daemo ii usbutils 0.73-10 Linux USB utilities Versions of packages hal recommends: ii eject 2.1.5+deb1+cvs20081104-5 ejects CDs and operates CD-Changer pn libsmbios-bin none (no description available) Versions of packages hal suggests: pn gnome-device-manager none (no description available) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#516505: libpam-krb5: fails on account when not used for auth
Package: libpam-krb5
Version: 3.11-4
Severity: important
Ever since I upgraded to Lenny, I cannot use GSSAPI to log in over SSH, and
the problem seems to be with pam_krb5. When I turn on debug logging on it
through PAM, I get the following messages:
Feb 21 23:25:23 sosumi sshd[2506]: Authorized to fredrik, krb5 principal
fred...@dolda2000.com (krb5_kuserok)
Feb 21 23:25:23 sosumi sshd[2506]: (pam_krb5): none: pam_sm_acct_mgmt: entry
(0x0)
Feb 21 23:25:23 sosumi sshd[2506]: (pam_krb5): none: skipping non-Kerberos login
Feb 21 23:25:23 sosumi sshd[2506]: (pam_krb5): none: pam_sm_acct_mgmt: exit
(failure)
Feb 21 23:25:23 sosumi sshd[2507]: fatal: Access denied for user fredrik by PAM
account configuration
This is weird, though, because looking at the source, it seems it should
work differently. Apparently, it does correctly detect that it was not used
for authentication, and the corresponding part of the source looks like
this:
if (pamret != PAM_SUCCESS || args-ctx == NULL) {
pamret = PAM_IGNORE;
pamk5_debug(args, skipping non-Kerberos login);
goto done;
}
[...]
done:
EXIT(args, pamret);
pamk5_args_free(args);
return pamret;
}
The EXIT macro looks like this:
#define EXIT(args, pamret) \
pamk5_debug((args), %s: exit (%s), __func__, \
((pamret) == PAM_SUCCESS) ? success \
: (((pamret) == PAM_IGNORE) ? ignore : failure))
So, apparently, pamret is set to PAM_IGNORE, but even in spite of that,
the function exits with some pamret different from PAM_SUCCESS or
PAM_IGNORE, even though there's no code in between. I have not yet been
able to find it why, but I will continue debugging.
Additionally, this particular output is from a PPC machine, but the same
thing happens on my i386 machines.
-- System Information:
Debian Release: 5.0
APT prefers stable
APT policy: (500, 'stable')
Architecture: powerpc (ppc)
Kernel: Linux 2.6.26-1-powerpc
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages libpam-krb5 depends on:
ii krb5-config 1.22 Configuration files for Kerberos V
ii libc6 2.7-18 GNU C Library: Shared libraries
ii libkrb53 1.6.dfsg.4~beta1-5 MIT Kerberos runtime libraries
ii libpam0g 1.0.1-5Pluggable Authentication Modules l
libpam-krb5 recommends no packages.
libpam-krb5 suggests no packages.
-- no debconf information
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#494444: linux-image-2.6.26-1-686: Another confirmation
Package: linux-image-2.6.26-1-686 Version: 2.6.26-11 Followup-For: Bug #49 I'd just like to file a me too on this bug. I can confirm that kacpid and kacpi_notify take ~90% of my CPU time together after I've had the laptop suspended to RAM, and also that, when I try to suspend to RAM again after that, it will not wake up again. It worked when I was running 2.6.24 (and I only recently upgrade, because previous 2.6.26 kernels had another, unrelated bug). My computer is a Dell Latitude D610. Dmidecode reports the BIOS version as A02. Unfortunately, I have no constructive information to add at this time. I'll try to find something out. -- Package-specific info: ** Version: Linux version 2.6.26-1-686 (Debian 2.6.26-11) ([EMAIL PROTECTED]) (gcc version 4.1.3 20080623 (prerelease) (Debian 4.1.2-23)) #1 SMP Wed Nov 26 19:14:11 UTC 2008 ** Command line: root=/dev/sda6 ro ** Not tainted ** Kernel log: [28249.056071] PM: Writing back config space on device :00:1d.1 at offset f (was 200, writing 20a) [28249.056071] PM: Writing back config space on device :00:1d.1 at offset 8 (was 1, writing bf61) [28249.056071] usb usb2: root hub lost power or was reset [28249.056071] uhci_hcd :00:1d.2: enabling device ( - 0001) [28249.056071] ACPI: PCI Interrupt :00:1d.2[C] - GSI 18 (level, low) - IRQ 18 [28249.056071] PCI: Setting latency timer of device :00:1d.2 to 64 [28249.056071] PM: Writing back config space on device :00:1d.2 at offset f (was 300, writing 309) [28249.056071] PM: Writing back config space on device :00:1d.2 at offset 8 (was 1, writing bf41) [28249.056071] usb usb3: root hub lost power or was reset [28249.056071] uhci_hcd :00:1d.3: enabling device ( - 0001) [28249.056071] ACPI: PCI Interrupt :00:1d.3[D] - GSI 19 (level, low) - IRQ 19 [28249.056071] PCI: Setting latency timer of device :00:1d.3 to 64 [28249.056071] PM: Writing back config space on device :00:1d.3 at offset f (was 400, writing 405) [28249.056071] PM: Writing back config space on device :00:1d.3 at offset 8 (was 1, writing bf21) [28249.056071] usb usb4: root hub lost power or was reset [28249.069391] ACPI: PCI Interrupt :00:1d.7[A] - GSI 16 (level, low) - IRQ 16 [28249.069417] PCI: Setting latency timer of device :00:1d.7 to 64 [28249.069534] usb usb5: root hub lost power or was reset [28249.076160] ehci_hcd :00:1d.7: debug port 1 [28249.076160] PCI: cache line size of 32 is not supported by device :00:1d.7 [28249.076160] PM: Writing back config space on device :00:1e.0 at offset 9 (was 10001, writing 1fff1) [28249.076160] PM: Writing back config space on device :00:1e.0 at offset 8 (was 0, writing dfb0dfb0) [28249.076160] PM: Writing back config space on device :00:1e.0 at offset 7 (was 2280e0f0, writing 22802020) [28249.076160] PM: Writing back config space on device :00:1e.0 at offset 6 (was 20030300, writing 20070300) [28249.076160] PM: Writing back config space on device :00:1e.0 at offset 1 (was 15, writing 100107) [28249.076160] PCI: Setting latency timer of device :00:1e.0 to 64 [28249.076160] PM: Writing back config space on device :00:1e.2 at offset f (was 100, writing 10b) [28249.076160] PM: Writing back config space on device :00:1e.2 at offset 7 (was 0, writing dd00) [28249.076160] PM: Writing back config space on device :00:1e.2 at offset 6 (was 0, writing de00) [28249.076160] PM: Writing back config space on device :00:1e.2 at offset 5 (was 1, writing ec41) [28249.076160] PM: Writing back config space on device :00:1e.2 at offset 4 (was 1, writing ed01) [28249.076160] PM: Writing back config space on device :00:1e.2 at offset 1 (was 290, writing 293) [28249.076160] ACPI: PCI Interrupt :00:1e.2[A] - GSI 16 (level, low) - IRQ 16 [28249.076160] PCI: Setting latency timer of device :00:1e.2 to 64 [28250.170128] PM: Writing back config space on device :00:1e.3 at offset f (was 200, writing 20a) [28250.170184] PM: Writing back config space on device :00:1e.3 at offset 5 (was 1, writing ec81) [28250.170205] PM: Writing back config space on device :00:1e.3 at offset 4 (was 1, writing ee01) [28250.170234] PM: Writing back config space on device :00:1e.3 at offset 1 (was 290, writing 291) [28250.170287] ACPI: PCI Interrupt :00:1e.3[B] - GSI 17 (level, low) - IRQ 17 [28250.170315] PCI: Setting latency timer of device :00:1e.3 to 64 [28251.176343] PM: Writing back config space on device :00:1f.0 at offset 1 (was 207, writing 2000107) [28251.189495] PM: Writing back config space on device :00:1f.2 at offset f (was 200, writing 20a) [28251.189536] PM: Writing back config space on device :00:1f.2 at offset 9 (was d, writing 0) [28251.189618] ACPI: PCI Interrupt :00:1f.2[B] - GSI 17 (level, low) - IRQ 17 [28251.189642] PCI: Setting latency timer of device :00:1f.2 to 64 [28251.189698] PM: Writing back
Bug#506549: suspendorhibernate: dbus-pm method is inherently broken
Package: acpi-support Version: 0.109-9 Severity: normal The dbus-pm suspend method in the suspendorhibernate script (which is enabled by default) is inherently broken and, I think, should be removed altogether. It uses the dbus-send program with the --session option, but since it does not run in the desktop user's session, it will never actually find the right session, and furthermore, will sometimes even create a new session. Every time I suspend my laptop, it will create a new DBus session as root and start gnome-power-manager inside it, running as root, so that I need to kill it every time it wakes up again. For some reason, this appears not to be a problem when running Gnome, however. I can only assume that two g-p-m's can manage to lock out each other or something. -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing'), (400, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.24-1-686 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages acpi-support depends on: ii acpi-support-base 0.109-9scripts for handling base ACPI eve ii acpid 1.0.6-16 Utilities for using ACPI power man ii dmidecode 2.9-1 Dump Desktop Management Interface ii finger0.17-12user information lookup program ii hdparm8.9-2 tune hard disk parameters for high ii laptop-detect 0.13.6 attempt to detect a laptop ii libc6 2.7-16 GNU C Library: Shared libraries ii lsb-base 3.2-20 Linux Standard Base 3.2 init scrip ii powermgmt-base1.30 Common utils and configs for power ii vbetool 1.0-3 run real-mode video BIOS code to a ii x11-xserver-utils 7.3+5 X server utilities Versions of packages acpi-support recommends: ii dbus 1.2.1-4simple interprocess messaging syst ii hal 0.5.11-6 Hardware Abstraction Layer ii nvclock 0.8b3-1Allows you to overclock your nVidi ii pm-utils 1.1.2.4-1 utilities and scripts for power ma ii radeontool1.5-5 utility to control ATI Radeon back ii toshset 1.73-3 Access much of the Toshiba laptop Versions of packages acpi-support suggests: pn laptop-mode-tools none (no description available) -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#506549: suspendorhibernate: dbus-pm method is inherently broken
On Sat, 2008-11-22 at 20:31 +0100, Bart Samwel wrote: Anyway, I don't think the suspend method is inherently broken, although it is broken as it is now. :-) We do things inside X sessions as well (such as locking all screens when suspending), so I expect it should be possible to get dbus-send to run inside a particular session. For instance, by finding the user corresponding to the console X session and by sourcing ~username/.dbus/session-dbus/*. I see. That's interesting -- I did not know of that directory or its significance. However: dbus-pm) if [ -x /usr/bin/dbus-send ] ; then +getXconsole +. $userhome/.dbus/session-bus/* I don't think that it going to work. I've got several files in there (probably stuff left over from some unclean shutdowns) overwriting each other, so it seems very unlikely that the last file will have the correct values. What would be the correct procedure here? Trying all of the files until one is found to work? Also -- I believe that you only meant that code to be used for testing, but I can see at least two large problems with it: 1. This program is running as root, right? I would be very careful with sourcing arbitrary shell commands from a users home directory then. 2. On a system using home directories on Kerberized NFS, the script should be able to handle root not having access to that directory at all. Fredrik Tolf -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#490607: python-cwiid does not follow Python's threading conventions
Package: python-cwiid
Version: 0.6.00-4
Severity: important
Tags: patch
Creating an instance of cwiid.Wiimote is a blocking operation that
can take quite some time. Python's threading conventions (as per
paragraph 8.1 in the Python/C API Reference Manual) states that
such operations should be guarded by a pair of
Py_{BEGIN,END}_ALLOW_THREADS macros, to avoid blocking all other
threads in the interpreter, but python-cwiid does not do so.
-- System Information:
Debian Release: 4.0
APT prefers stable
APT policy: (500, 'stable'), (50, 'testing')
Architecture: amd64 (x86_64)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.24-1-amd64
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
diff -Nurp cwiid-0.6.00/python/Wiimote.c cwiid-0.6.00-mod/python/Wiimote.c
--- cwiid-0.6.00/python/Wiimote.c 2007-06-19 04:28:49.0 +0200
+++ cwiid-0.6.00-mod/python/Wiimote.c 2008-07-13 03:50:55.0 +0200
@@ -232,8 +232,12 @@ static int Wiimote_init(Wiimote* self, P
else {
bdaddr = *BDADDR_ANY;
}
-
- if (!(wiimote = cwiid_open(bdaddr, flags))) {
+
+ Py_BEGIN_ALLOW_THREADS
+ wiimote = cwiid_open(bdaddr, flags);
+ Py_END_ALLOW_THREADS
+
+ if (!wiimote) {
PyErr_SetString(PyExc_RuntimeError,
Error opening wiimote connection);
return -1;
Bug#489995: linux-image-2.6.24-1-amd64: Kernel NULL pointer dereference in NFS server
Package: linux-image-2.6.24-1-amd64 Version: 2.6.24-7 Severity: normal I'm not sure what triggers it (it seems completely random), but every once in a while, my NFS server will log an Oops message in the kernel NFS server. It does seem to be recoverable, but I doubt it's a good thing. The dmesg from the event is as follows: Unable to handle kernel NULL pointer dereference at 0018 RIP: [882b8f7e] :sunrpc:rpc_shutdown_client+0xb5/0xd2 PGD 328c8067 PUD 1eb84067 PMD 0 Oops: [1] SMP CPU 1 Modules linked in: tcp_diag inet_diag des_generic cbc blkcipher nfs nfsd lockd nfs_acl exportfs ppdev parport_pc lp parport wlan_scan_ap sit tunnel4 sch_sfq cls_u32 cls_fw sch_htb ipt_REJECT iptable_filter xt_tcpudp ipt_MASQUERADE iptable_nat nf_conntrack_ipv4 ipt_owner xt_DSCP xt_dscp xt_MARK iptable_mangle ip_tables x_tables xfs reiserfs nf_nat_sip nf_conntrack_sip nf_nat_h323 nf_conntrack_h323 nf_nat_irc nf_conntrack_irc nf_nat_ftp nf_nat nf_conntrack_ftp nf_conntrack ipv6 rpcsec_gss_krb5 auth_rpcgss sunrpc loop snd_hda_intel psmouse ath_rate_sample pcspkr ath_pci wlan ath_hal(P) snd_pcm snd_timer snd soundcore serio_raw k8temp snd_page_alloc i2c_nforce2 i2c_core pl2303 usblp usbserial evdev ext3 jbd mbcache dm_mirror dm_snapshot dm_mod generic sd_mod amd74xx sata_nv ide_core r8169 forcedeth firewire_ohci firewire_core crc_itu_t sata_sil ata_generic ohci_hcd libata scsi_mod ehci_hcd Pid: 16606, comm: nfs4_cb_probe Tainted: P2.6.24-1-amd64 #1 RIP: 0010:[882b8f7e] [882b8f7e] :sunrpc:rpc_shutdown_client+0xb5/0xd2 RSP: 0018:8100018ade90 EFLAGS: 00010246 RAX: fffb RBX: RCX: 810001436fa0 RDX: 0002 RSI: fffb RDI: RBP: 810007482e00 R08: 882e2750 R09: 81000176e000 R10: 81000176e000 R11: 80273a34 R12: 0018 R13: R14: 80578f20 R15: FS: 2b898a7b1270() GS:81003f5e0a40() knlGS: CS: 0010 DS: 0018 ES: 0018 CR0: 8005003b CR2: 0018 CR3: 3a173000 CR4: 06e0 DR0: DR1: DR2: DR3: DR6: 4ff0 DR7: 0400 Process nfs4_cb_probe (pid: 16606, threadinfo 8100018ac000, task 81003d904800) Stack: 80578f20 0282 0282 81003e04c080 882be0ff fffb 810007482ec0 810007482e00 8100399dbbd0 884f34b2 Call Trace: [882be0ff] :sunrpc:rpc_put_task+0x6d/0x81 [884f34b2] :nfsd:do_probe_callback+0x48/0x6a [884f346a] :nfsd:do_probe_callback+0x0/0x6a [80247f03] kthread+0x47/0x74 [8020cc48] child_rip+0xa/0x12 [80247ebc] kthread+0x0/0x74 [8020cc3e] child_rip+0x0/0x12 Code: 4c 39 63 18 0f 85 73 ff ff ff 48 89 df e8 ec fd ff ff 48 83 RIP [882b8f7e] :sunrpc:rpc_shutdown_client+0xb5/0xd2 RSP 8100018ade90 CR2: 0018 ---[ end trace f553cdd2937e7544 ]--- -- Package-specific info: ** Version: Linux version 2.6.24-1-amd64 (Debian 2.6.24-7) ([EMAIL PROTECTED]) (gcc version 4.1.3 20080114 (prerelease) (Debian 4.1.2-19)) #1 SMP Sat May 10 09:28:10 UTC 2008 ** Command line: rw root=/dev/disk/by-label/root console=ttyS0,115200 ** Tainted: P (129) ** Kernel log: doldacond[4805]: segfault at 12615e0 rip 417790 rsp 7fff6c9733b0 error 6 nfs4_cb: server 192.168.2.253 not responding, timed out UDP: bad checksum. From 93.80.151.26:53 to 82.182.133.20:1937 ulen 464 nfs4_cb: server 192.168.2.253 not responding, timed out nfs4_cb: server 192.168.2.253 not responding, timed out Unable to handle kernel NULL pointer dereference at 0018 RIP: [882b8f7e] :sunrpc:rpc_shutdown_client+0xb5/0xd2 PGD 328c8067 PUD 1eb84067 PMD 0 Oops: [1] SMP CPU 1 Modules linked in: tcp_diag inet_diag des_generic cbc blkcipher nfs nfsd lockd nfs_acl exportfs ppdev parport_pc lp parport wlan_scan_ap sit tunnel4 sch_sfq cls_u32 cls_fw sch_htb ipt_REJECT iptable_filter xt_tcpudp ipt_MASQUERADE iptable_nat nf_conntrack_ipv4 ipt_owner xt_DSCP xt_dscp xt_MARK iptable_mangle ip_tables x_tables xfs reiserfs nf_nat_sip nf_conntrack_sip nf_nat_h323 nf_conntrack_h323 nf_nat_irc nf_conntrack_irc nf_nat_ftp nf_nat nf_conntrack_ftp nf_conntrack ipv6 rpcsec_gss_krb5 auth_rpcgss sunrpc loop snd_hda_intel psmouse ath_rate_sample pcspkr ath_pci wlan ath_hal(P) snd_pcm snd_timer snd soundcore serio_raw k8temp snd_page_alloc i2c_nforce2 i2c_core pl2303 usblp usbserial evdev ext3 jbd mbcache dm_mirror dm_snapshot dm_mod generic sd_mod amd74xx sata_nv ide_core r8169 forcedeth firewire_ohci firewire_core crc_itu_t sata_sil ata_generic ohci_hcd libata scsi_mod ehci_hcd Pid: 16606, comm: nfs4_cb_probe Tainted: P2.6.24-1-amd64 #1 RIP: 0010:[882b8f7e] [882b8f7e]
Bug#485444: /etc/cron.daily/webalizer chokes on multiple logfiles
Package: webalizer Version: 2.01.10-32 Severity: normal I have a webalizer config that I've written myself (instead of using Debconf to generate it, that is), and, among other things, it tells Webalizer to use more than one logfile (both access.log and access.log.1, to get immediate updates while avoiding lost record at logfile rollover). However, the webalizer cron script shipped with the Debian package assumes only one logfile in the webalizer config, and will not run webalizer when more than one is specified (it will use the concatenation of all the logfile names in its non-emptiness and readability checks). I would also question whether those checks are really necessary to begin with. After all, what are they for? If the logfile is incorrectly specified, webalizer will say so on stderr and it will be mailed by cron to the sysadmin, which is probably desired behavior anyhow. -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable'), (50, 'testing') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.24-1-amd64 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Versions of packages webalizer depends on: ii debconf [debconf-2.0] 1.5.11etch1 Debian configuration management sy ii libc6 2.3.6.ds1-13etch5 GNU C Library: Shared libraries ii libdb4.2 4.2.52+dfsg-2 Berkeley v4.2 Database Libraries [ ii libgd2-xpm 2.0.33-5.2GD Graphics Library version 2 ii libgeoip1 1.3.17-1.1A non-DNS IP-to-country resolver l ii libpng12-0 1.2.15~beta5-1PNG library - runtime ii zlib1g 1:1.2.3-13compression library - runtime webalizer recommends no packages. -- debconf information excluded -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#483983: libnfsidmap: missing build dep on automake 1.9
Package: libnfsidmap Version: 0.18-0 Severity: serious Justification: no longer builds from source The build process of libnfsidmap calls automake-1.9, but without listing it as a build dependency: # Add here commands to compile the package. /usr/bin/make make[1]: Entering directory `/tmp/libnfsidmap-0.18' cd . automake-1.9 --gnu Makefile /bin/sh: line 11: automake-1.9: command not found make[1]: *** [Makefile.in] Error 127 make[1]: Leaving directory `/tmp/libnfsidmap-0.18' make: *** [build-stamp] Error 2 -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable'), (50, 'testing') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.24-1-amd64 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
