Bug#945444: apt: Man page for apt-helper missing
Package: apt Version: 1.8.2 Severity: normal Dear Maintainer, * What led up to the situation? I noticed that my system was trying to run apt-helper on a daily basis and wanted to know what apt-helper does and peruse descriptions of command line switches and options. * What exactly did you do (or not do) that was effective (or ineffective)? I typed "man apt-helper" in a bash terminal. I also looked in the man page for apt. * What was the outcome of this action? I received the message "No manual entry for apt-helper" * What outcome did you expect instead? I expected the appropriate man page to be opened. -- Package-specific info: -- (no /etc/apt/preferences present) -- -- (/etc/apt/preferences.d/stable.pref present, but not submitted) -- -- /etc/apt/preferences.d/testing.pref -- Package: * Pin: release a=testing Pin-Priority: 795 -- (/etc/apt/sources.list present, but not submitted) -- -- (no /etc/apt/sources.list.d/* present) -- -- System Information: Debian Release: 10.2 APT prefers stable APT policy: (995, 'stable'), (500, 'stable-updates') Architecture: amd64 (x86_64) Kernel: Linux 4.19.85 (SMP w/2 CPU cores; PREEMPT) Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1), LANGUAGE=en_US (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages apt depends on: ii adduser 3.118 ii debian-archive-keyring 2019.1 ii gpgv2.2.12-1+deb10u1 ii libapt-pkg5.0 1.8.2 ii libc6 2.28-10 ii libgcc1 1:8.3.0-6 ii libgnutls30 3.6.7-4 ii libseccomp2 2.3.3-4 ii libstdc++6 8.3.0-6 Versions of packages apt recommends: ii ca-certificates 20190110 Versions of packages apt suggests: pn apt-doc ii aptitude0.8.11-7 ii dpkg-dev1.19.7 ii gnupg 2.2.12-1+deb10u1 ii gnupg2 2.2.12-1+deb10u1 pn powermgmt-base -- Configuration Files: /etc/logrotate.d/apt changed [not included] -- no debconf information
Bug#863114: [Pkg-utopia-maintainers] Bug#863114: policykit-1: pkttyagent does not acquire authentication
On Mon, 22 May 2017 02:40:55 +0200 Michael Biebl <bi...@debian.org> wrote: > Am 22.05.2017 um 02:31 schrieb James Blanford: > > The failure has an auth.log entry "Operator of unix-session:1 > > FAILED to authenticate Error executing command as another user: Not > > Authorized > > .. > > > Init: sysvinit (via /sbin/init) > > Can you reproduce the problem with systemd as your init system? > > Yes, but on a different system, already using systemd as init, for convenience. ls -l /sbin/init lrwxrwxrwx 1 root root 20 Jan 4 16:42 /sbin/init -> /lib/systemd/systemd apt-cache show policykit-1 Package: policykit-1 Version: 0.105-15~deb8u2 auth.log entries for failure with pkttyagent: polkitd(authority=local): Registered Authentication Agent for unix-process:1834:84660 (system bus name :1.14 [/usr/bin/pkexec /], object path /org/freedesktop/PolicyKit1/AuthenticationAgent, locale en_US.UTF-8) polkitd(authority=local): Operator of unix-process:1834:84660 FAILED to authenticate to gain authorization for action com..pkexec. for unix-process:1834:84660 [/bin/bash /] (owned by unix-user:uuu) pkexec[1842]: uuu: Error executing command as another user: Not authorized [USER=root] [TTY=/dev/pts/2] [CWD=/home/uuu] [COMMAND=/] polkitd(authority=local): Unregistered Authentication Agent for unix-process:1834:84660 (system bus name :1.14, object path /org/freedesktop/PolicyKit1/AuthenticationAgent, locale en_US.UTF-8) auth.log entries for success with lxsession polkitd(authority=local): Registered Authentication Agent for unix-session:1 (system bus name :1.22 [lxpolkit], object path /org/freedesktop/PolicyKit1/AuthenticationAgent, locale en_US) polkitd(authority=local): Operator of unix-session:1 successfully authenticated as unix-user:uuu to gain ONE-SHOT authorization for action com..pkexec. for unix-process:2408:159798 [/bin/bash /] (owned by unix-user:uuu) pkexec: pam_unix(polkit-1:session): session opened for user root by uuu(uid=) pkexec[2416]: uuu: Executing command [USER=root] [TTY=/dev/pts/0] [CWD=/home/uuu] [COMMAND=/] -- JBo, the widely declaimed writer from the hinterlands of New Mexico.
Bug#863114: policykit-1: pkttyagent does not acquire authentication
Package: policykit-1 Version: 0.105-17 Severity: important Dear Maintainer, * What led up to the situation? Regression - update from 0.105-11 * What exactly did you do (or not do) that was effective (or ineffective)? Installed gui agent * What was the outcome of this action? Both lxsession and policykit-1-gnome granted expected authentication. The failure has an auth.log entry "Operator of unix-session:1 FAILED to authenticate Error executing command as another user: Not Authorized I would paste in the full errors, but apparently etch's vim no longer supports the cutbuffer. -- System Information: Debian Release: 9.0 APT prefers testing APT policy: (795, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 4.4.69 (SMP w/2 CPU cores; PREEMPT) Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages policykit-1 depends on: ii dbus 1.10.18-1 ii libc6 2.24-10 ii libglib2.0-0 2.50.3-2 ii libpam-systemd 232-23 ii libpam0g 1.1.8-3.5 ii libpolkit-agent-1-00.105-17 ii libpolkit-backend-1-0 0.105-17 ii libpolkit-gobject-1-0 0.105-17 policykit-1 recommends no packages. policykit-1 suggests no packages. -- no debconf information
Bug#743439: lxsession: All work arounds fail
Package: lxsession Version: 0.4.9.2-1 Followup-For: Bug #743439 Dear Maintainer, I tried the listed work arounds, but none worked. I tried Asho Yeh's patch. I got a popup box asking for my password. I entered it and it seemed to accept it, but nothing happened. The errors in my run.log were reduced from: (lxsession-logout:6999): GLib-GIO-CRITICAL **: g_dbus_proxy_call_sync_internal: assertion 'error == NULL || *error == NULL' failed (lxsession-logout:6999): GLib-CRITICAL **: g_variant_unref: assertion 'value != NULL' failed to: (lxsession-logout:7651): GLib-CRITICAL **: g_variant_unref: assertion 'value != NULL' failed I tried Tomek Kowalski's modified xserverrc and it changed: Active=no to: Active=yes Unfortunately, it left me with a system that does not repond to mouse clicks. Is Tomek Kowalski implying that since systemd is the default that it has been implemented and will fix this problem without creating other problems in my system? -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.14.8 (SMP w/1 CPU core) Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/dash Versions of packages lxsession depends on: ii libatk1.0-02.12.0-1 ii libc6 2.19-4 ii libcairo2 1.12.14-4 ii libdbus-1-31.8.4-1 ii libdbus-glib-1-2 0.102-1 ii libfontconfig1 2.11.0-5 ii libfreetype6 2.5.2-1 ii libgdk-pixbuf2.0-0 2.30.7-1 ii libgee20.6.8-1 ii libglib2.0-0 2.40.0-3 ii libgtk2.0-02.24.24-1 ii libpango-1.0-0 1.36.3-1 ii libpangocairo-1.0-01.36.3-1 ii libpangoft2-1.0-0 1.36.3-1 ii libpolkit-agent-1-00.105-6 ii libpolkit-gobject-1-0 0.105-6 ii libx11-6 2:1.6.2-2 Versions of packages lxsession recommends: ii consolekit 0.4.6-4 ii lxde-common 0.5.5-6 ii openbox [x-window-manager] 3.5.2-6 ii openssh-client [ssh-client] 1:6.6p1-5 pn upower none Versions of packages lxsession suggests: ii gpicview 0.2.4-1 ii lxpanel 0.5.12-3 ii pcmanfm 1.2.0-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#748523: lxpanel: RAM monitor shows no RAM use with kernel 3.14
Package: lxpanel Version: 0.5.12-3 Severity: normal Tags: upstream Dear Maintainer, I boot into kernel 3.14.4-1-amd64 and startx to lxde. I glance at the RAM monitor and see it is blank. I hover the pointer over the monitor and its tooltip reads RAM usage: 0.0 MB (0.00%). I click on the monitor and lxtask opens. It reports the correct RAM useage. The cpu monitor works. The RAM monitor works with kernel 3.13. -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.14-1-amd64 (SMP w/1 CPU core) Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/dash Versions of packages lxpanel depends on: ii libasound2 1.0.27.2-3 ii libatk1.0-0 2.12.0-1 ii libc62.18-5 ii libcairo21.12.14-4 ii libfontconfig1 2.11.0-5 ii libfreetype6 2.5.2-1 ii libgdk-pixbuf2.0-0 2.30.7-1 ii libglib2.0-0 2.40.0-3 ii libgtk2.0-0 2.24.23-1 ii libiw30 30~pre9-8 ii libmenu-cache3 0.5.1-1 ii libpango-1.0-0 1.36.3-1 ii libpangocairo-1.0-0 1.36.3-1 ii libpangoft2-1.0-01.36.3-1 ii libwnck222.30.7-1 ii libx11-6 2:1.6.2-1 ii lxmenu-data 0.1.2-2 lxpanel recommends no packages. Versions of packages lxpanel suggests: ii iceweasel [www-browser] 24.5.0esr-1 ii lxsession0.4.9.2-1 ii menu 2.1.46 -- 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#745888: libmtp9: jmtpfs hangs on directory listing
Package: libmtp9 Version: 1.1.6-51-g1a2669c~ds0-1 Followup-For: Bug #745888 Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? * What exactly did you do (or not do) that was effective (or ineffective)? * What was the outcome of this action? * What outcome did you expect instead? *** End of the template - remove these template lines *** After updating to version 1.1.6-51-g1a2669c~ds0-1 I am no longer able to read the directory that my Hisense Sero 7 pro was mounted on by jmtpfs. The ls command hangs until I kill the jmtpfs process. jmtpfs reports: Device 0 (VID=109b and PID=9106) is a Hisense E860 (ID1) Downgrading to libmtp9 version 1.1.6-20-g1b9f164-2 restores all functionality of jmtpfs. -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.12.18 (SMP w/2 CPU cores; PREEMPT) Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/dash Versions of packages libmtp9 depends on: ii dpkg 1.17.6 ii libc6 2.18-4 ii libgcrypt111.5.3-4 ii libmtp-common 1.1.6-51-g1a2669c~ds0-1 ii libusb-1.0-0 2:1.0.18-2 ii multiarch-support 2.18-4 Versions of packages libmtp9 recommends: ii libmtp-runtime 1.1.6-51-g1a2669c~ds0-1 ii udev204-8 libmtp9 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#721311: Digikam loads no images from albums reporting an undefined symbol
This bug is the same as bug #721442. The problem is that when the kde libraries are updated, the kde init services are not restarted, so they don't know where to look for the properly versioned libraries. The solution is to reload the kde services. This bug should not be closed, it should be reclassified as normal and reassigned to libkio5, which should restart kde services when it is updated. Thanks for your support, - Jim -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#721792: mtr fails without IPv6 socket
Package: mtr Version: 0.85-1 Severity: normal Dear Maintainer, On a system without IPv6 support, mtr fails on invocation, such as, mtr localhost or mtr example.com issuing the error, Unable to allocate IPv6 socket for nameserver communication: Address family not supported by protocol I would expect mtr to try IPv4, if IPv6 is not available. Partial functioning can be obtained if resolution of hostnames is not requested by adding the -n command line switch. -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.10.10 (SMP w/2 CPU cores; PREEMPT) Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/dash Versions of packages mtr depends on: ii libatk1.0-0 2.8.0-2 ii libc62.17-92 ii libcairo21.12.14-4 ii libfontconfig1 2.10.2-2 ii libfreetype6 2.4.9-1.1 ii libgdk-pixbuf2.0-0 2.28.2-1 ii libglib2.0-0 2.36.4-1 ii libgtk2.0-0 2.24.20-1 ii libncurses5 5.9+20130608-1 ii libpango-1.0-0 1.32.5-5+b1 ii libpangocairo-1.0-0 1.32.5-5+b1 ii libpangoft2-1.0-01.32.5-5+b1 ii libtinfo55.9+20130608-1 mtr recommends no packages. mtr 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#721311: digikam: Digikam loads no images from albums reporting an undefined symbol
Package: digikam Version: 4:3.1.0-4 Severity: important Dear Maintainer, When I started digikam, no images were loaded into the default album. Selecting a different album resulted in the failure to load images. At the terminal I noticed the following error messages: Could not open library '/usr/lib/kde4/kio_digikamalbums.so'. Cannot load library /usr/lib/kde4/kio_digikamalbums.so: (/usr/lib/libkio.so.5: undefined symbol: _ZN11KListWidget17mouseReleaseEventEP11QMouseEvent) and identical error messages for kio_digikamdates.so and kio_file.so I have no alternative qt or kde libraries on my system. -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.10.9 (SMP w/2 CPU cores; PREEMPT) Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/dash Versions of packages digikam depends on: ii digikam-data 4:3.1.0-4 ii digikam-private-libs 4:3.1.0-4 ii kde-runtime 4:4.10.5-1 ii libc6 2.17-92 ii libgcc1 1:4.8.1-2 ii libgphoto2-2 2.4.14-2+b1 ii libgphoto2-port0 2.4.14-2+b1 ii libkdcraw22 4:4.10.5-1 ii libkdecore5 4:4.10.5-1 ii libkdeui5 4:4.10.5-1 ii libkexiv2-11 4:4.10.5-1 ii libkhtml5 4:4.10.5-1 ii libkio5 4:4.10.5-1 ii libkipi10 4:4.10.5-1 ii libknotifyconfig4 4:4.10.5-1 ii libkparts44:4.10.5-1 ii libphonon44:4.6.0.0-3 ii libqt4-dbus 4:4.8.5+dfsg-2 ii libqt4-sql4:4.8.5+dfsg-2 ii libqt4-sql-sqlite 4:4.8.5+dfsg-2 ii libqt4-xml4:4.8.5+dfsg-2 ii libqtcore44:4.8.5+dfsg-2 ii libqtgui4 4:4.8.5+dfsg-2 ii libsolid4 4:4.10.5-1 ii libstdc++64.8.1-2 ii libthreadweaver4 4:4.10.5-1 ii perl 5.14.2-21 ii phonon4:4.6.0.0-3 Versions of packages digikam recommends: pn ffmpegthumbs | mplayerthumbs none ii iceweasel [www-browser] 24.0~b4-1 pn kipi-plugins none Versions of packages digikam suggests: pn digikam-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#708359: Spice-vdagentd will not start, failing to find .service file
Package: spice-vdagent
Version: 0.10.1-1
Severity: important
Tags: upstream
Dear Maintainer,
This bug was found on a system running as a qemu-kvm virtual machine.
The system does not have systemd or a desktop environment. It has
the fluxbox window manager. When I would run
invoke-rc.d spice-vdagent start the daemon would try but fail to start.
Noting that spice-vdagent-0.14.0 had been released at spice-space.org with a
fix for this problem, I built the 0.14.0 binaries and replaced the 0.10.1-1
binaries. The vdagentd daemon started and worked as expected.
Perhaps it is time to introduce the updated 0.14.0 release to Debian.
-- System Information:
Debian Release: jessie/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 3.8-1-amd64 (SMP w/1 CPU core)
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/dash
Versions of packages spice-vdagent depends on:
ii libc6 2.17-2
ii libdbus-1-31.6.10-1
ii libpciaccess0 0.13.1-2
ii libx11-6 2:1.5.0-1
ii libxfixes3 1:5.0-4
ii libxinerama1 2:1.1.2-1
ii libxrandr2 2:1.3.2-2
spice-vdagent recommends no packages.
spice-vdagent suggests no packages.
-- Configuration Files:
/etc/init.d/spice-vdagent changed:
exec=/usr/sbin/spice-vdagentd
prog=spice-vdagentd
pidfile=/var/run/spice-vdagentd/spice-vdagentd.pid
port=/dev/virtio-ports/com.redhat.spice.0
[ -e /etc/default/$prog ] . /etc/default/$prog
[ ! -d /var/run/spice-vdagentd ] mkdir -p /var/run/spice-vdagentd
.. /lib/lsb/init-functions
lockfile=/var/lock/$prog
start() {
[ -x $exec ] || exit 5
[ -c $port ] || exit 0
modprobe uinput /dev/null 21
# In case the previous running vdagentd crashed
rm -f /var/run/spice-vdagentd/spice-vdagent-sock
log_daemon_msg Starting Agent daemon for Spice guests spice-vdagent
if start-stop-daemon --start --quiet --oknodo --pidfile $pidfile --exec
$exec -- $options; then
log_end_msg 0
else
log_end_msg 1
fi
}
stop() {
log_daemon_msg Stopping Agent daemon for Spice guests spice-vdagent
if start-stop-daemon --stop --quiet --oknodo --pidfile $pidfile; then
log_end_msg 0
else
log_end_msg 1
fi
}
restart() {
stop
start
}
reload() {
restart
}
force_reload() {
restart
}
status() {
status_of_proc -p $pidfile $exec $prog exit 0 || exit $?
}
case $1 in
start)
$1
;;
stop)
$1
;;
restart)
$1
;;
reload)
$1
;;
force-reload)
force_reload
;;
status)
status
;;
condrestart|try-restart)
status || exit 0
restart
;;
*)
echo $Usage: $0
{start|stop|status|restart|condrestart|try-restart|reload|force-reload}
exit 2
esac
exit $?
/etc/xdg/autostart/spice-vdagent.desktop changed:
[Desktop Entry]
Name=Spice vdagent
Comment=Agent for Spice guests
Exec=/usr/bin/spice-vdagent -d
Terminal=false
Type=Application
Categories=
X-GNOME-Autostart-Phase=Initialization
X-GNOME-AutoRestart=true
-- 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#524112: qc-usb-source: linux-2.6.29 provides an equivalent
Back again,
This version of the patch adapts the driver to the new v4l file system
operations API to all versions of the kernel 2.6.29 and above. The
change to the way /proc entry ownership is established is applied only
to kernels 2.6.30 and above. No changes were necessary for 2.6.31.
I've tested it in 2.6.29.6 and 2.6.31-rc7
References are in the patch.
Good luck,
- JimChanges for 2.6.29 reflect the v4l files system operations API changes.
See: http://lwn.net/Articles/320721/
Changes for 2.6.30 reflect a change in the way the kernel establishes the
owner of /proc entries
See: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=99b76233803beab302123d243eea9e41149804f3
--- qc-usb-0.6.6.orig/qc-driver.c 2009-08-25 23:17:04.0 -0400
+++ qc-usb-0.6.6/qc-driver.c 2009-08-25 23:38:31.0 -0400
@@ -996,7 +996,9 @@
PRINTK(KERN_WARNING,Could not register procfs file entry);
return -ENXIO;
}
+#if LINUX_VERSION_CODE KERNEL_VERSION(2,6,30)
entry-owner = THIS_MODULE;
+#endif
entry-data = qc;
entry-read_proc = qc_proc_read;
entry-write_proc = qc_proc_write;
@@ -1034,7 +1036,9 @@
return -ENXIO;
}
}
+#if LINUX_VERSION_CODE KERNEL_VERSION(2,6,30)
qc_proc_entry-owner = THIS_MODULE;
+#endif
return 0;
}
/* }}} */
@@ -2303,7 +2307,11 @@
/* }}} */
/* {{{ [fold] qc_v4l_open(struct video_device *dev, int flags) */
#if LINUX_VERSION_CODE = KERNEL_VERSION(2,6,0)
+#if LINUX_VERSION_CODE = KERNEL_VERSION(2,6,29)
+static int qc_v4l_open(struct file *file)
+#else
static int qc_v4l_open(struct inode *inode, struct file *file)
+#endif
#else
static int qc_v4l_open(struct video_device *dev, int flags)
#endif
@@ -2375,7 +2383,11 @@
/* }}} */
/* {{{ [fold] qc_v4l_close(struct video_device *dev) */
#if LINUX_VERSION_CODE = KERNEL_VERSION(2,6,0)
+#if LINUX_VERSION_CODE = KERNEL_VERSION(2,6,29)
+static int qc_v4l_close(struct file *file)
+#else
static int qc_v4l_close(struct inode *inode, struct file *file)
+#endif
#else
static void qc_v4l_close(struct video_device *dev)
#endif
@@ -2520,7 +2532,11 @@
/* }}} */
/* {{{ [fold] qc_v4l_ioctl(struct video_device *dev, unsigned int cmd, void *arg) */
#if LINUX_VERSION_CODE = KERNEL_VERSION(2,6,0)
+#if LINUX_VERSION_CODE = KERNEL_VERSION(2,6,29)
+static int qc_v4l_ioctl(struct file *file, unsigned int cmd, unsigned long arg)
+#else
static int qc_v4l_ioctl(struct inode *inode, struct file *file, unsigned int cmd, unsigned long arg)
+#endif
#else
static int qc_v4l_ioctl(struct video_device *dev, unsigned int cmd, void *argp)
#endif
@@ -3021,7 +3037,11 @@
#if LINUX_VERSION_CODE = KERNEL_VERSION(2,6,0)
static void qc_v4l_release(struct video_device *vfd) { }
+#if LINUX_VERSION_CODE = KERNEL_VERSION(2,6,29)
+static struct v4l2_file_operations qc_v4l_fops = {
+#else
static struct file_operations qc_v4l_fops = {
+#endif
owner: THIS_MODULE,
open: qc_v4l_open,
release: qc_v4l_close,
Bug#524112: qc-usb-source: linux-2.6.29 provides an equivalent
Howdy, While it's important that the linux kernel developers develop generalized driver frameworks to replace out-of-tree drivers, some still don't fully support all their target hardware. gspca_stv06xx is one of those. I'm working with the kernel maintainer to try improve support for a webcam that he doesn't have access to and is not currently working well with gspca_stv06xx. In the meantime, here's a patch that might get qc-usb working in 2.6.30 and 2.6.31 kernels. It might also work in 2.6.29. I've only tested it in 2.6.31-rc7 and it's fine so far. Good luck. - Jim -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#524112: qc-usb-source: linux-2.6.29 provides an equivalent
Oops. Here's the patch:
- Jim--- qc-usb-0.6.6.orig/qc-driver.c 2009-08-25 23:17:04.0 -0400
+++ qc-usb-0.6.6/qc-driver.c 2009-08-25 23:38:31.0 -0400
@@ -996,7 +996,9 @@
PRINTK(KERN_WARNING,Could not register procfs file entry);
return -ENXIO;
}
+#if LINUX_VERSION_CODE KERNEL_VERSION(2,6,30)
entry-owner = THIS_MODULE;
+#endif
entry-data = qc;
entry-read_proc = qc_proc_read;
entry-write_proc = qc_proc_write;
@@ -1034,7 +1036,9 @@
return -ENXIO;
}
}
+#if LINUX_VERSION_CODE KERNEL_VERSION(2,6,30)
qc_proc_entry-owner = THIS_MODULE;
+#endif
return 0;
}
/* }}} */
@@ -2303,7 +2307,11 @@
/* }}} */
/* {{{ [fold] qc_v4l_open(struct video_device *dev, int flags) */
#if LINUX_VERSION_CODE = KERNEL_VERSION(2,6,0)
+#if LINUX_VERSION_CODE = KERNEL_VERSION(2,6,30)
+static int qc_v4l_open(struct file *file)
+#else
static int qc_v4l_open(struct inode *inode, struct file *file)
+#endif
#else
static int qc_v4l_open(struct video_device *dev, int flags)
#endif
@@ -2375,7 +2383,11 @@
/* }}} */
/* {{{ [fold] qc_v4l_close(struct video_device *dev) */
#if LINUX_VERSION_CODE = KERNEL_VERSION(2,6,0)
+#if LINUX_VERSION_CODE = KERNEL_VERSION(2,6,30)
+static int qc_v4l_close(struct file *file)
+#else
static int qc_v4l_close(struct inode *inode, struct file *file)
+#endif
#else
static void qc_v4l_close(struct video_device *dev)
#endif
@@ -2520,7 +2532,11 @@
/* }}} */
/* {{{ [fold] qc_v4l_ioctl(struct video_device *dev, unsigned int cmd, void *arg) */
#if LINUX_VERSION_CODE = KERNEL_VERSION(2,6,0)
+#if LINUX_VERSION_CODE = KERNEL_VERSION(2,6,30)
+static int qc_v4l_ioctl(struct file *file, unsigned int cmd, unsigned long arg)
+#else
static int qc_v4l_ioctl(struct inode *inode, struct file *file, unsigned int cmd, unsigned long arg)
+#endif
#else
static int qc_v4l_ioctl(struct video_device *dev, unsigned int cmd, void *argp)
#endif
@@ -3021,7 +3037,11 @@
#if LINUX_VERSION_CODE = KERNEL_VERSION(2,6,0)
static void qc_v4l_release(struct video_device *vfd) { }
+#if LINUX_VERSION_CODE = KERNEL_VERSION(2,6,30)
+static struct v4l2_file_operations qc_v4l_fops = {
+#else
static struct file_operations qc_v4l_fops = {
+#endif
owner: THIS_MODULE,
open: qc_v4l_open,
release: qc_v4l_close,
Bug#432793: Masqmail shouldn't call update-inetd during shutdown
Package: masqmail
Version: 0.2.21-1.2
During system shutdown, I get a warning (that I can't trap, because the
screen goes blank a second after I see it) something like Masqmail:
invoke-rc.d called during shutdown - ignoring.
This is caused by line 73 in /etc/init.d/masqmail:
update-inetd --enable smtp
I guess update-inetd calls invoke-rc.d, which refuses to run, because it
is called during the shutdown sequence. I don't know what Debian policy
is, but there are two things I don't like about this.
First, I don't want masqmail to mess with /etc/inetd.conf at all. I
have no services enabled in it and I want it to stay that way. For
example, you could define an environmental variable, MANAGE_INETD, that
users could set to false in /etc/default/masqmail.
Second, I shouldn't be getting warnings in normal operation. I agree
that invoke-rc.d shouldn't be called during shutdown. But we shouldn't
rely on secondary safety features, when it can be done right in the
primary script. You should test if this is a shutdown or just shutting
off the service, before calling update-inetd.
/etc/default/masqmail
#
# better use 'dpkg-reconfigure masqmail'
# instead of editing by hand
#
INIT_SMTP_DAEMON=false
INIT_QUEUE_DAEMON=true
INIT_FETCH_DAEMON=false
#
QUEUE_DAEMON_IVAL=-q30m
FETCH_DAEMON_IVAL=-go5m
#
IPUP_RUNQUEUE=false
IPUP_FETCH=false
IFUP_IFACES=eth0
/etc/masqmail/masqmail.conf
### BEGIN DEBCONF SECTION
# Do not edit within this region if you want your changes to be preserved by
# debconf. Instead, make changes after the ### END DEBCONF SECTION line.
host_name=.localnet.prv
local_hosts=localhost;;.localnet.prv
local_nets=*.localnet.prv
listen_addresses=localhost:25
spool_dir=/var/spool/masqmail
mail_dir=/var/mail
log_dir=/var/log/masqmail
do_queue=false
use_syslog=true
online_detect=file
online_file=/tmp/connect_route
mbox_default=mda
mda=/usr/bin/procmail -Y -d ${rcpt_local}
alias_file=/etc/aliases
alias_local_caseless=false
### END DEBCONF SECTION
#
# include the locations of your route and get configurations here.
# Examples:
# online_routes.default = /etc/masqmail/default.route
# online_gets.default = /etc/masqmail/default.get
# You can have more of those, with '.default' replaced with other
# names. See man 8 masqmail.conf.
#
online_routes.xxx = /etc/masqmail/xxx.route
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#419344: Debconf script incorrectly returns an error on cancellation
Package: tzdata Version: 2007e-3 When I run dpkg-reconfigure tzdata but decide to cancel the operation, an error is returned: echo $? 1 But there was no error. I decided to cancel the operation and nothing was changed. That's a success. It should have returned 0. For example, if I run dpkg-reconfigure debconf and then select cancel: echo $? 0 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#398851: Close bug
Howdy folks, Well, the mozilla developers, after closing the bug with WORKSFORME, promptly fixed it in seamonkey 1.0.6. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#398851: fc-cache adds . to search path with null local.conf
Package: fontconfig Version: 2.4.1-2 I had this in /etc/fonts/local.conf: fontconfig dir/dir /fontconfig It was essentially a template. Starting with the 2.4 series of fontconfig, upgrading stalled at Regenerating fonts cache... while fc-cache tried to search all the devices in /dev for fonts. My investigation revealed that fc-cache was acting as if ., the current directory, had been added to the font search path. Trying various clean system configurations, I found that this behavior went away when I removed the /etc/fonts/local.conf file (above). Since the installation scripts run from the root directory, all my file systems were being searched for fonts. I'm hoping you'll agree that: 1) a local.conf template should not cause . to be added to the font search path. 2) . should never be added to the font search path 3) System directories like /dev, /sys, /proc, /lib/init/rw, /etc etc. should never be added to the font search path. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#398639: Segfault in FcCharSetDestroy () when called by seamonkey-1.0.5 print tasks
Package: libfontconfig1 Version: 2.4.1-2 I get a segfault in seamonkey-1.0.5 _after_ print related tasks, such as print preview, print and page setup. There may be a bug in seamonkey (see bugzilla.mozilla.org #353712), but see the following backtrace: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1488611648 (LWP 12642)] 0xa7a38d17 in FcCharSetDestroy () from /usr/lib/libfontconfig.so.1 (gdb) bt #0 0xa7a38d17 in FcCharSetDestroy () from /usr/lib/libfontconfig.so.1 #1 0xa3884a57 in ?? () from /usr/local/lib/seamonkey-1.0.5/components/libgfxps.so #2 0xa4bdfa48 in ?? () #3 0x0007 in ?? () #4 0x08a79d18 in ?? () #5 0xa725f8f4 in ?? () from /usr/local/lib/seamonkey-1.0.5/libgkgfx.so #6 0x08a79d18 in ?? () #7 0x0001 in ?? () #8 0xaf89c6f0 in ?? () #9 0xa3884b22 in ?? () from /usr/local/lib/seamonkey-1.0.5/components/libgfxps.so #10 0x08a79d18 in ?? () #11 0xaf89c710 in ?? () #12 0xa7251050 in nsFontCache::Flush () from /usr/local/lib/seamonkey-1.0.5/libgkgfx.so Previous frame inner to this frame (corrupt stack?) The problem goes away when I downgrade to version 2.3.1-2 of libfontconfig1. Architecture: i386 Dependencies: fontconfig-config 2.4.1-2 libc6 2.3.6.ds1-8 libexpat1 1.95.8-3.3 libfreetype62.2.1-5 zlib1g 1.2.3-13 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#373977: Python can't be installed nor upgraded from etch - circular dependency
package: python version: 2.3.5-9 I uninstalled and then attempted to reinstall all my python packages. I got the following error: :/home/xxx# apt-get install python Reading package lists... Done Building dependency tree... Done The following NEW packages will be installed: python python-central python2.3 0 upgraded, 3 newly installed, 0 to remove and 14 not upgraded. Need to get 3015kB of archives. After unpacking 10.1MB of additional disk space will be used. Do you want to continue [Y/n]? Get:1 http://ftp.debian.org unstable/main python-central 0.4.16 [20.0kB] Get:2 http://ftp.debian.org unstable/main python2.3 2.3.5-14 [2855kB] Get:3 http://ftp.debian.org unstable/main python 2.3.5-9 [140kB] Fetched 3015kB in 4s (624kB/s) (Reading database ... 35462 files and directories currently installed.) Unpacking python-central (from .../python-central_0.4.16_all.deb) ... Unpacking python2.3 (from .../python2.3_2.3.5-14_i386.deb) ... Unpacking python (from .../python_2.3.5-9_all.deb) ... Setting up python-central (0.4.16) ... Setting up python2.3 (2.3.5-14) ... Traceback (most recent call last): File /usr/bin/pycentral, line 1365, in ? main() File /usr/bin/pycentral, line 1359, in main rv = action.run(global_options) File /usr/bin/pycentral, line 892, in run pkg.set_default_runtime_from_version_info() File /usr/bin/pycentral, line 575, in set_default_runtime_from_version_info self.default_runtime = get_runtime_for_version(versions[0]) TypeError: unindexable object dpkg: error processing python2.3 (--configure): subprocess post-installation script returned error exit status 1 dpkg: dependency problems prevent configuration of python: python depends on python2.3 (= 2.3.5-1); however: Package python2.3 is not configured yet. dpkg: error processing python (--configure): dependency problems - leaving unconfigured Errors were encountered while processing: python2.3 python E: Sub-process /usr/bin/dpkg returned an error code (1) Installing python2.3_2.3.5-9.1_i386.deb and python_2.3.5-5_all.deb from testing works, but runs into the same error while upgrading. Versions of installed packages python2.3 depends on: libbz2-1.0 1.0.3-2 libc6 2.3.6-15 libdb4.34.3.29-5 libncurses5 5.5-2 libreadline55.1-7 libssl0.9.8 0.9.8b-2 zlib1g 1.2.3-11 python-central 0.4.15 is fully installed and configured as a dependency in the install process. Everything upgraded from the previous unstable packages. The error occurred only after a full deinstall reinstall cycle. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#372957: private kernel data type outside of #ifdef __KERNEL__ block
Package: linux-kernel-headers Version: 2.6.16.20-1 I was building libsdl1.2debian from Debian sources when the compilation stopped with the error: gcc -g -O2 -Iinclude -I../../include -D_GNU_SOURCE=1 -DXTHREADS -D_REENTRANT -DHAVE_LINUX_VERSION_H -c ../../src/joystick/linux/SDL_sysjoystick.c -fPIC -DPIC -o build/.libs/SDL_sysjoystick.o In file included from /usr/include/linux/joystick.h:33, from ../../src/joystick/linux/SDL_sysjoystick.c:33: /usr/include/linux/input.h:801: error: syntax error before kernel_ulong_t /usr/include/linux/input.h:805: error: syntax error before evbit /usr/include/linux/input.h:805: error: `BITS_PER_LONG' undeclared here (not in a function) /usr/include/linux/input.h:806: error: syntax error before keybit /usr/include/linux/input.h:807: error: syntax error before relbit /usr/include/linux/input.h:808: error: syntax error before absbit /usr/include/linux/input.h:809: error: syntax error before mscbit /usr/include/linux/input.h:810: error: syntax error before ledbit /usr/include/linux/input.h:811: error: syntax error before sndbit /usr/include/linux/input.h:812: error: syntax error before ffbit /usr/include/linux/input.h:813: error: syntax error before swbit /usr/include/linux/input.h:815: error: syntax error before driver_info /usr/include/linux/input.h:805: error: storage size of `evbit' isn't known /usr/include/linux/input.h:806: error: storage size of `keybit' isn't known /usr/include/linux/input.h:807: error: storage size of `relbit' isn't known /usr/include/linux/input.h:808: error: storage size of `absbit' isn't known /usr/include/linux/input.h:809: error: storage size of `mscbit' isn't known /usr/include/linux/input.h:810: error: storage size of `ledbit' isn't known /usr/include/linux/input.h:811: error: storage size of `sndbit' isn't known /usr/include/linux/input.h:812: error: storage size of `ffbit' isn't known /usr/include/linux/input.h:813: error: storage size of `swbit' isn't known make[1]: *** [build/SDL_sysjoystick.lo] Error 1 make[1]: Leaving directory `/usr/src/sdl/SDL-1.2.10/builddir/all' make: *** [build-stamp] Error 1 Downgrading to the recent version, 2.6.13+0rc3-2.1, fixed the problem. I realize this could be a libsdl1.2 debian problem, but in /usr/include/linux/input.h where the error occurred, it seems that private kernel data types are being used outside of an #ifdef __KERNEL__ #endif block. Oddly in the version that works for me, public data types are being used inside a __KERNEL__ block. I would think that the structure in question should be inside the __KERNEL__ block, where, I suspect, sdl won't even see it. BTW, I'm still using gcc-3.4 for the smaller binaries, if that makes a difference and an unpatched kernel, 2.6.16.19. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#364832: Upgrading fuse-utils fails on dpkg-statoverride --add in postinst
Package: fuse-utils Version: 2.5.3-1 An attempt at upgrading fuse-utils failed with the following error message: Setting up fuse-utils (2.5.3-1) ... creating fuse device... creating fuse group... The group `fuse' already exists as a system group. Exiting... An override for /usr/bin/fusermount already exists, aborting dpkg: error processing fuse-utils (--configure): subprocess post-installation script returned error exit status 3 Errors were encountered while processing: fuse-utils You might want to add a line like: if dpkg-statoverride --quiet --list /usr/bin/fusermount; then dpkg-statoverride --remove /usr/bin/fusermount; fi before line 17 of fuse-utils.postinst Test for the presence of the override first. Then remove it in case it needs to be changed. Finally install the override. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#363579: No, gnome-icon-theme isn't needed
On 20 Apr, Josselin Mouette wrote: libgnomeprintui relies on gnome-icon-theme being present for the icons it uses. The configure.in explicitly checks the presence of this package, that's why I think it is needed. It is probably needed as a build-depends, so that it can take advantage of the icons if they are present. Nevertheless, it seems to work quite fine without the icons when they are not present. I notice that when I select a printer, the descriptions present a default icon. This is a very minor loss and of no concern to me. As a practical consideration, anyone who is running gnome will have the icons as they are a dependency of gnome-core. People who do not have gnome installed are probably not interested in its icon support. Putting it as a Recommends: instead sounds reasonable as we haven't received any reports of a failure without gnome-icon-theme installed. The criterion is not whether anyone reports a bug, it is what Debian policy has to say. Accordingly, if the package retains a significant portion of it's functionality without another package, then it does not depend upon that package. libgnomeprintui2.2-common does everything I expect it to do without gnome-icon-theme. The dependency relationship between libgnomeprintui2.2-common and gnome-icon-theme barely meets the standard of a Suggests let alone a Recommends or Depends. But a suggestion or a recommendation makes no difference to me, so long as I can do without it, if I don't want it. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#363579: No, gnome-icon-theme isn't needed
Package: libgnomeprintui2.2-common Version: 2.12.1-3 While upgrading to the latet version of libgnomeprintui2.2-common, I was informed that I would need to install four new packages, with a total installed size of about 12 megabytes. I looked at the changelog and noticed the entry (referring to gnome-icon-theme), Make it a dependency, after all it's needed. Excuse me for my ignorance (and for being stubborn), but I've been using libgnomeprintui2.2-common for some time now and have never encountered a need for gnome-icon-theme. I certainly have no personal use for them and I don't believe I even have a venue to display them. No, I don't use gnome. I use libgnomeprintui2.2 to provide a WYSIWYG interface for abiword, built without gnome support. My suggested remedy would be to make gnome-icon-theme a Recommends. Anyone installing with the installer, aptitude or apt-get install will have it pulled-in automatically. Stubborn minimalists like myself will know how to avoid it. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#362253: Neither discover1, laptop-detect, mdetect nor xresprobe are needed
On 13 Apr, Daniel Stone wrote: On Wed, Apr 12, 2006 at 05:40:03PM -0700, James Blanford wrote: They bloat the system, clog the harddrive, complicate package management, require continual maintenance, open security holes and worst of all, slow the boot process significantly. I think this is the sentence where I stopped paying attention, to be honest. That's to be expected. My concerns are _user_ concerns not _developer_ concerns. But, really, laptop-detect??? My three year old knows the difference between a laptop and a desktop. I notice you have no response to the Debian policy I quoted. So we've established two things: You stop paying attention when user concerns come up. You aren't interested in Debian policy. I don't think they even meet the requirement of Recommends or Suggests as all these relationships are defined in terms of utility not convenience of configuration. But I won't quibble, if you'll please not make them Depends. You are seriously suggesting that they should be removed as they serve no purpose, and no-one cares about configuration? No, if I had wanted to suggest that, I would have come out and said it. As it turns out, xserver-xorg and all the packages I listed are unnecessary. Close the bug. For all I care you can make it depend on a functioning webcam, so gamma can be adjusted for my interior lighting scheme. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#362253: Neither discover1, laptop-detect, mdetect nor xresprobe are needed
Package: xserver-xorg Version: 1:7.0.10 When I upgraded to this version of xserver-xorg, I was required to also install discover1, discover1-data, libdiscover1, mdetect, xresprobe laptop-detect and dmidecode as dependencies. Debian policy states, The Depends field should be used if the depended-on package is required for the depending package to provide a significant amount of functionality. I submit that 100% of the functionality of xserver-xorg can be obtained without any of these packages. They are conveniences for configuration purposes only. They bloat the system, clog the harddrive, complicate package management, require continual maintenance, open security holes and worst of all, slow the boot process significantly. I don't think they even meet the requirement of Recommends or Suggests as all these relationships are defined in terms of utility not convenience of configuration. But I won't quibble, if you'll please not make them Depends. It's interesting that packages.debian.org lists these as both Recommends and Depends. Perhaps this was just a slip up? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#327435: Seg fault when trying to play CD-audio
I finally got around to building a debian packages of alsaplayer from the debian sources and it works fine with and without 06_cdda_input.dpatch. So, I agree. That's not the problem. I then installed the official alsaplayer -7 packages and I get the same segfault. I'm still using gcc-3.4 for smaller binaries. You don't think it could be a compiler issue, do you? I thought those problems were all worked out. I suppose I could try gcc-4.0 and see if it makes a difference. You might want to try a rebuild and see if it works. Maybe something subtle was broken and then fixed in libc6. - Jim -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#346342: tzconfig should create a copy of timezone data in localtime rather than a symlink
Package: libc6 Version: 2.3.5-11 The kernel, init and boot-up processes don't have access to timezone data until /usr is mounted, thereby creating havoc with file system checks and boot logs. Please see bug #342887 filed against util-linux. The filesystem hierarchy standard requires essential start-up data to be in the root file system. I think it's realistic to describe site-specific timezone data as essential. My suggestion is that tzconfig be changed to create /etc/localtime as a copy of the timezone data rather than a symlink. So whenever the timezone is set or changed or the timezone data itself is changed, tzconfig is run and localtime is updated. It sure would make things simpler. Thanks, - Jim -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#330630: rootok module broken by SELinux checks
On 29 Sep, Steve Langasek wrote: On Wed, Sep 28, 2005 at 09:46:57PM -0700, James Blanford wrote: OK, I was trying to goad you into checking and failed. So I reverted the patch myself and rootok is still broken. I hereby change the bug to rootok module is broken and I don't know why. Going back to 0.76-23 restores rootok's functionality. Which makes even less sense, because the upstream diff between 0.76 and 0.79 for rootok is nil. Are you sure this isn't actually related to the update of login, which briefly caused /etc/pam.d/su to be missing from the package? I know you quoted an /etc/pam.d/su config to me earlier, but I'm not seeing this bug here and if you don't have an SELinux-enabled kernel I really don't have any other ideas why this is broken for you. Well, now I think it's pam_wheel.so that's broken. The problem is exposed by this line in /etc/pam.d/su: auth required pam_wheel.so group=adm If I replace it with: auth required pam_wheel.so functionality is restored. I thought I'd tried it before. What's interesting is that _all_ attempts to su from root fail even with the correct password when the group=adm argument is used. I ltraced the su attempt with the 0.76-23 version and compared it to an attempt with the 0.79-1 version minus the 057 patch. The pam_handle_t identifier passed by pam_authenticate() was different: pam_authenticate(0x8055bc8, 0, 0x804e620, 0x8056958, 0 vs. pam_authenticate(0x8055bc8, 0, 0x804e620, -1, 0 It doesn't matter what group I use. group=users leads to all failures attempting to su from root also. And when I mention root, I always get there using su. I never log in as root. For that matter it's not allowed. So to reproduce it, add the offending line auth required pam_wheel.so group=somegroup to /etc/pam.d/su, su to root from any user belonging to somegroup and then try to su to any other user. Be sure to leave a terminal open as root, in case you can't get to root after making the changes. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#330855: Bug#330630: rootok module broken by SELinux checks
On 30 Sep, Steve Langasek wrote: If you two can confirm that this bug is fixable by adding root to the specified group (adm, foo, whatever), *and* that it is fixable by listing 'auth sufficient pam_rootok.so' *before* pam_wheel, then I'll go ahead and reassign these bugs to the login package, requesting that the examples be reordered to follow the pam_rootok stanza. Thanks, Both cases confirmed here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#330630: rootok module broken by SELinux checks
Package: libpam-modules Version: 0.79-1 I used to be able to su from root to any other account without entering a password. Now a password is requested. This breaks at least the updatedb script. Please revert the SELinux passwd class permissions check. You see, security is better when a task that is running as root can switch to running as a less privileged user. Security suffers with this change. Contents of /etc/pam.d/su: auth required pam_wheel.so group=adm auth sufficient pam_rootok.so auth required pam_env.so @include common-auth @include common-account @include common-session Kernel: 2.6.13.2 - unpatched Dependencies: libc6 2.3.5-6 libcap1 1.10-14 libdb3 3.2.9-22 libgcc1 4.0.1-9 libpam0g0.79-1 libselinux1 1.26-1 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#330630: rootok module broken by SELinux checks
On 28 Sep, Steve Langasek wrote: On Wed, Sep 28, 2005 at 05:14:31PM -0700, James Blanford wrote: Package: libpam-modules Version: 0.79-1 I used to be able to su from root to any other account without entering a password. Now a password is requested. This breaks at least the updatedb script. Please revert the SELinux passwd class permissions check. Please explain why the SELinux patch is to blame. The SELinux changes should have zero impact unless you have an SELinux-enabled kernel, *and* you have SELinux turned on at boot time. I based my conclusion on the Debian changelog, where it states: - make pam_rootok check the SELinux passwd class permissions, not just the uid Note that it doesn't say, make pam_rootok check the SELinux passwd class permissions, _if SELinux is enabled_. Were pam_rootok to check these class permissions and they didn't exist, I would expect them to fail. Bugs resulting from new SELinux features that fail to check whether SELinux is enabled have become pretty common occurences lately. OK, I was trying to goad you into checking and failed. So I reverted the patch myself and rootok is still broken. I hereby change the bug to rootok module is broken and I don't know why. Going back to 0.76-23 restores rootok's functionality. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#328371: Bug#327760: missing dependency on gconf2
This problem is a mistaken fix for bug #327760. Instead of adding an unneeded dependency,libgsf-1 should be built _without_ gconf2 support. Leave the gconf support for the libgsf-gnome-1 package. It can be done. Look at the upstream changelog for version 1.12.3 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#327435: Seg fault when trying to play CD-audio
Package: alsaplayer-common Version: 0.99.76-7 alsaplayer --verbose Left click on left button, select CD Player (CDDA), instead of playing the cd, I get a seg fault. AlsaPlayer 0.99.76 (C) 1999-2003 Andy Lo A Foe [EMAIL PROTECTED] and others. Output plugin: OSS output v1.0 Loading reader plugin: HTTP reader v1.3 Loading reader plugin: File reader v1.1 Loading Input plugin: Ogg Vorbis player v1.2 Loading Input plugin: CDDA player v1.2 Loading Input plugin: libsndfile plugin v0.1 Loading Input plugin: flac player v1.2 Loading Input plugin: MAD MPEG audio plugin v1.01 Loading Input plugin: MikMod player v1.0 Interface plugin: GTK+ interface v1.2 Searching for CDDB entries on /home/jim/.alsaplayer/cddb ... Segmentation fault The problem is not in the cddb lookup - it's successful. It's not in accessing the drive. If I don't have a disc in I get: CDDA: read TOC ioctl failed after the GTK+ interface is loaded, but no seg fault and alsaplayer continues to work. I noticed that a change was made to cdda.h for version 0.99.76-3, so I downgraded to 0.99.76-1 and have no problems. Dependencies: alsaplayer-oss 0.99.76-7 alsaplayer-gtk 0.99.76-7 libc6 2.3.5-6 libflac71.1.2-3 libgcc1 4.0.1-6 libid3tag0 0.15.1b-7 libmad0 0.15.1b-2.1 libmikmod2 3.1.11-a-6 libogg0 1.1.2-1 liboggflac3 1.1.2-3 libsndfile1 1.0.11-1 libstdc++6 4.0.1-6 libvorbis0a 1.1.0-1 libvorbisfile3 1.1.0-1 zlib1g 1.2.3-4 kernel 2.6.13 unpatched -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#326087: Removing debian init script would be better than conflicting with alsa-base and aumix
Package: setmixer Version: 27DEC94ds1-1 Severity: Wishlist I have yet to find any sound mixer application that can properly control all my sound devices. With setmixer conflicting with alsa-base and aumix, I loose functionality. Removing the functionality that saves and restores mixer settings on boot-up and the resulting conflicts would be a better solution than conflicting with similar programs and thereby leaving Debian users with one less option. Just because a program _can_ be run at system startup doesn't mean it _has_ to be. I can have multiple types of web browsers and editors and all manner of programs, why can't I have multiple types of mixers? The result of the recent changes is that one more useful piece of software - one more option - cannot be installed. On the other hand, if the initscripts and conflicts were removed, functionality would be retained and I would still have all my options. If someone wants to run setmixer at boot, it's relatively easy to put a little script in /etc/rc.boot. It's also reasonable to assume that someone wanting to use an obscure commandline program like setmixer would be capable of doing so. An example startup script could even be placed in /usr/share/doc/setmixer/examples. Referencing bug # 202151, if the maintainer believes, ...looks like aumix has improved since I uploaded setmixer, so there is not much specific need for setmixer anymore, he should probably give up the program. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#302498: Should suggest not depend on wget or lynx
Package: usbutils Version: 0.70-4 Usbutils works perfectly well without wget or lynx, in fact I never knew that a script existed to update the usbids. Certainly it could be said that usbutils retains a significant amount of functionality without wget or lynx. Therefore the relationship should not be a Depends. Nor do I think the relationship is as strong as a Recommends. A Suggests is more appropriate. This is how the pciutils package, which also has a script to download appropriate ids, defines its dependency relationships. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#296006: Cryptsetup not installable on sid - missing dependency
Package: cryptsetup Version: 20050111-2 Severity: serious Cryptsetup depends on libdevmapper1.00, which is no longer available in sid. Looks like cryptsetup needs to be rebuilt against libdevmapper1.01. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
